AdministrationGuide Ioa514ag

N E W
D I ME N S I O N
S O F T WA R E
R
E
L
.
5
.
1
.
4
I OA
ADMINISTRATOR
GUIDE
I
-
5
1
4
G
-
A
9
9
0
1
A
Copyright 1999 by New Dimension Software Ltd. All rights reserved.
First Edition.
The software described in this document is furnished under a license agreement, and may
be used or copied only in accordance with the terms of the agreement.
All New Dimension Software products are trademarks or registered trademarks of New
Dimension Software Ltd. Other brand and product names are trademarks or registered
trademarks of their respective holders.
The information in this document is subject to change without prior notice and does not
represent a commitment on the part of New Dimension Software Ltd.
New Dimension Software Ltd. assumes no responsibility for any errors that may appear in
this document.
I-514G-A9901A
20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2
IOA Rel. 5.1.4 Administrator Guide iii
About This Manual
This guide contains the information necessary for IOA administrators who are responsible
for customizing and maintaining the IOA family of products.
Basic information about how IOA products operate is provided in user manuals for each
product.
Most administration information for each product is found in the section devoted to that
product. However, all IOA administrators should read Sections 1 and 2 before continuing
with the rest of this guide. Section 1 contains an overview of the key IOA concepts which
apply to all IOA products. Section 2 describes how to customize the IOA environment.
This guide contains the following sections:
Section 1 IOA Concepts and Components
Overview of the IOA environment and a description of key IOA concepts and components.
Section 2 Customizing and Administering IOA
How to customize and maintain the IOA environment.
Sections 3 to 7 Customizing and Administering CONTROL-x
Information about administrative tasks for each IOA product. Each section includes
information on the products New Day processing and work flow, as well as information
about how the relevant product can be used to perform specific tasks. These sections also
include information about the structure of relevant files, operator commands, etc.
Notes CONTROLR is described together with CONTROL-M in Section 3.
CONTROLV is described together with CONTROL-D in Section 4.
Section 8 Maintaining IOA Products
Information about maintaining and updating IOA products.
Section 9 Utilities
Special features designed to help you perform specific tasks. This section contains an
alphabetized reference guide for all available utilities for each IOA product.
Section 10 Exits
Information on exits available with each IOA product which can be used to modify
operations.
iv IOA Rel. 5.1.4 Administrator Guide
Section 11 CONTROL-M/WorkLoad
Information about administrative tasks for CONTROL-M/WorkLoad. This section also
includes information about the structure of relevant files, operator commands, etc.
Section 12 ECSGATE
Information about implementing and customizing ECSGATE.
Appendix A IOA Application Program Names
Appendix B Dataset Formatting Utilities for IOA Products
Appendix C Modifying IOA Online Facility Commands
Appendix D Logical Field Names for the CONTROL-T Repository
Appendix E IOA Online Options Cross-Reference
Appendix F IOAMEM Module
Appendix G Customizing the CONTROL-M Status Screen
Appendix H CONTROL-O Modify Commands
IOA Rel. 5.1.4 Administrator Guide v
Related Publications
IOA Installation Guide
A step-by-step guide to installing IOA products using the IOA Customization and
Installation Engine (ICE) application.
IOA Security Guides
Step-by-step guides to implementing security in IOA products using the IOA
Customization and Installation Engine (ICE) application. Security guides are currently
available for IOA interaction with RACF, CA-TOP SECRET and CA-ACF2.
User Manuals
Product-specific manuals containing comprehensive information about the operation and
implementation of each IOA product.
IOA Messages and Codes
A comprehensive listing and explanation of all IOA messages and codes.
Information New in This Release
Information which is new in releases 5.0.4 and 5.1.4 is indicated by an update line | in the
left margin of the page.
We Want to Hear From You
If you have any comments or opinions regarding this publication, we want to hear them.
Your feedback will help us improve our documentation to our mutual benefit. Send your
remarks by email to publications@ndsoft.com. Please include the name and version
number of the publication in your email.
vi IOA Rel. 5.1.4 Administrator Guide
This page intentionally left blank.
Table of Contents
IOA Rel. 5.1.4 Administrator Guide vii
Table of Contents
Section 1: IOA Concepts and Components
Introduction..................................................................................................................................1-1
IOA Products.................................................................................................................................1-1
Installation and Maintenance...................................................................................................1-3
Installation and Customization Engine (ICE) ..........................................................................1-3
Product Maintenance .................................................................................................................1-3
Online Facility ..............................................................................................................................1-3
Primary Option Menu ................................................................................................................1-4
Logic................................................................................................................................................1-4
Automated Processing Definitions ............................................................................................1-4
Jobs.........................................................................................................................................1-5
Missions .................................................................................................................................1-5
Rules.......................................................................................................................................1-5
Monitors ......................................................................................................................................1-5
IOA Monitors .........................................................................................................................1-6
Product-Specific Monitors.....................................................................................................1-6
Daily Processing/New Day Processing ......................................................................................1-7
File Management........................................................................................................................1-8
IOA Access Method................................................................................................................1-8
IOA Core ................................................................................................................................1-8
Product Repositories............................................................................................................1-10
IOA and Product PARM Libraries .....................................................................................1-13
Miscellaneous............................................................................................................................1-13
Dynamic Destination Table ................................................................................................1-13
AutoEdit Facility .................................................................................................................1-13
Security Implementation ....................................................................................................1-14
User Exits ............................................................................................................................1-14
Utilities ................................................................................................................................1-14
Simulation............................................................................................................................1-14
Cross-Product Communication...........................................................................................1-15
Inter-System Communications Facility .............................................................................1-16
Table of Contents
viii IOA Rel. 5.1.4 Administrator Guide
Section 2: IOA Administration
Introduction ................................................................................................................................. 2-1
IOA Online Environment........................................................................................................... 2-1
Entering the IOA Online Facility ............................................................................................. 2-2
IOA Online Monitor................................................................................................................... 2-3
Principles of Operation......................................................................................................... 2-3
Activating the IOA Online Monitor (IOAOMON)............................................................... 2-4
Displaying a List of All Active Users................................................................................... 2-5
Deactivating the IOA Online Monitor ................................................................................. 2-6
Problem Determination........................................................................................................ 2-6
VTAM Monitor (IOAVMON) ..................................................................................................... 2-7
Activating the VTAM Monitor (IOAVMON) ....................................................................... 2-7
Deactivating the VTAM Monitor ......................................................................................... 2-7
Displaying a List of All Active Users................................................................................... 2-7
Canceling an IOA Online Monitor User.............................................................................. 2-7
Customizing the IOA Online Environment........................................................................... 2-8
Transaction Members ................................................................................................................ 2-8
Program List Members.............................................................................................................. 2-9
Allocation Members ................................................................................................................. 2-10
Modifying IOA Online Facility Commands............................................................................ 2-13
Modifying IOA Online Facility PFKey Definitions................................................................ 2-13
IOA Primary Option Menu...................................................................................................... 2-14
Line Format Display........................................................................................................... 2-14
Box Format Display............................................................................................................ 2-15
Customizing the Menu ....................................................................................................... 2-15
Customizing IOA Screens........................................................................................................ 2-17
Modifying IOA Screens and Constants ............................................................................. 2-17
Constant Blocks .................................................................................................................. 2-19
Recommended Steps for Screen Modification ................................................................... 2-19
Customizing IOA Display Format Members.......................................................................... 2-20
@STYLE............................................................................................................................... 2-21
@HEADER .......................................................................................................................... 2-22
@LINE................................................................................................................................. 2-22
@FIELD............................................................................................................................... 2-23
@VAL................................................................................................................................... 2-24
@END.................................................................................................................................. 2-24
@DLM.................................................................................................................................. 2-24
Color, Highlight and Intensity Parameters ...................................................................... 2-25
Table of Contents
IOA Rel. 5.1.4 Administrator Guide ix
Extended Color Support ...........................................................................................................2-26
ISPF Characteristics ...........................................................................................................2-26
IMS/DC and IDMS/DC........................................................................................................2-26
IRMA PC Terminal Emulator Users..................................................................................2-26
Customizing Extended Color Support.....................................................................................2-26
IOA Access Method ................................................................................................................... 2-28
File Structure............................................................................................................................2-28
IOA Access Method Naming Conventions .........................................................................2-29
Files Supported by the IOA Access Method.......................................................................2-30
File Utilities ..............................................................................................................................2-31
File Definition Statements.......................................................................................................2-31
Dual Mirror Image File Support..............................................................................................2-32
Dual Mirror Image File Parameters ..................................................................................2-32
Recovering From a Damaged IOA Access Method File.....................................................2-32
IOA Profiles ................................................................................................................................ 2-33
Profile Members........................................................................................................................2-33
Profile Contents ........................................................................................................................2-34
Considerations for Profile Symbol Lines............................................................................2-35
SHOW Window Filters........................................................................................................2-35
Profile Attribute in the Screen Definition..........................................................................2-36
Saving a Profile....................................................................................................................2-36
Profile Variables .......................................................................................................................2-36
Window Display Variables..................................................................................................2-37
Color Variables ....................................................................................................................2-40
Work Mode Variables ..........................................................................................................2-42
Presentation Mode Variables..............................................................................................2-44
Miscellaneous Variables......................................................................................................2-47
Other Types of Profile Variables ........................................................................................2-48
Modifying IOA Product Defaults........................................................................................... 2-48
Modifying IOA Messages ......................................................................................................... 2-49
Recommended Steps for Message Modification ......................................................................2-50
Dynamic Destination Table.................................................................................................... 2-51
Replacing the Current Dynamic Destination Table ...............................................................2-51
Expanding the IOA Conditions/Resource File (RES) ....................................................... 2-52
Expanding the IOA LOG File (LOG) ..................................................................................... 2-52
Table of Contents
x IOA Rel. 5.1.4 Administrator Guide
Section 3: CONTROL-M
General........................................................................................................................................... 3-1
Activating the CONTROL-M Monitor ...................................................................................... 3-1
Shutting Down the CONTROL-M Monitor .............................................................................. 3-1
Starting the CONTROL-M EVENT MANAGER (CMEM) Facility........................................ 3-2
Shutting Down the CMEM Facility.......................................................................................... 3-2
Replacing an Active CMEM Monitor........................................................................................ 3-3
Modifying the CONTROL-M Sleeping Interval ..................................................................... 3-3
Refreshing the CONTROL-M Security Cache.......................................................................... 3-4
Refresh Deadline Scheduling and Job Network Dependencies................................................. 3-4
Shift DUE OUT Times for CONTROL-M Jobs ........................................................................ 3-5
Sending a Jobs SYSDATA to a Held Output Class................................................................. 3-5
Accumulating Job Execution Statistics .................................................................................... 3-6
Expanding CONTROL-M Files................................................................................................. 3-7
Expanding the Active Jobs File (CKP) ................................................................................ 3-7
Expanding the CONTROL-M Jobs Dependency Network File (GRF)............................... 3-7
Expanding the CONTROL-M Statistics File (STAT) ......................................................... 3-7
Expanding the IOA Manual Conditions File (NRS) ........................................................... 3-8
CDAM Files................................................................................................................................ 3-8
Display CONTROL-M Installation Parameters....................................................................... 3-8
Switching from SAPI to PSO support....................................................................................... 3-8
Problem Determination............................................................................................................. 3-9
Job Ordering via New Day Processing ................................................................................ 3-10
Overview................................................................................................................................... 3-10
Sample New Day Processing................................................................................................... 3-12
How the Sample Components Perform New Day Processing .......................................... 3-13
Date Control Records and Enhanced Daily Checkpointing .................................................. 3-15
Implementing New Day Processing........................................................................................ 3-16
Programs Called During New Day Processing ...................................................................... 3-23
Use of the Date Control Record by User Daily Jobs .............................................................. 3-25
New Day Procedure Flow........................................................................................................ 3-27
Considerations for Job Ordering and Submission ................................................................. 3-28
Library Compression.......................................................................................................... 3-28
JCL Parameter MSGLEVEL ............................................................................................. 3-28
Comment Lines Added During Job Submission ............................................................... 3-28
End User Job Order Interface Defining Job Lists for Each User ...................................... 3-29
TSO User ID Masking ........................................................................................................ 3-29
CONNECT DIRECT Support.................................................................................................. 3-30
Table of Contents
IOA Rel. 5.1.4 Administrator Guide xi
Activation of Started Tasks .................................................................................................... 3-32
Daylight Savings Time Considerations ............................................................................... 3-32
Advancing the Clock Forward .................................................................................................3-32
New Day Procedure.............................................................................................................3-33
Time-Dependent Shouts......................................................................................................3-33
Time-Dependent Schedules (FROM-UNTIL) ....................................................................3-33
Cyclic Jobs............................................................................................................................3-33
IOA Log File.........................................................................................................................3-33
Moving the Clock Backwards...................................................................................................3-34
New Day Procedure.............................................................................................................3-34
Time-Dependent Shouts......................................................................................................3-34
Time-Dependent Schedules (FROM-UNTIL) ....................................................................3-34
Cyclic Jobs............................................................................................................................3-34
IOA Log File.........................................................................................................................3-34
Managing the CMEM Facility ................................................................................................ 3-35
Automatic Loading of Rules.....................................................................................................3-35
Deleting (Deactivating) an Active Rule Table ........................................................................3-37
Displaying Active Rules ...........................................................................................................3-37
Controlling CMEM Rule Operation Mode...............................................................................3-38
Modifying the CMEM Sleeping Interval .................................................................................3-38
Refreshing the CMEM Security Cache ...................................................................................3-39
Virtual Storage Requirements of the CMEM Monitor ...........................................................3-39
Calculating Region Size ......................................................................................................3-39
Troubleshooting...................................................................................................................3-40
Storage Allocation................................................................................................................3-40
CMEM Usage of the Common Storage Area (E/CSA) ............................................................3-41
Extended CSA Usage (Above 16M Line) ............................................................................3-41
CSA Usage (Below the 16M Line) ......................................................................................3-41
CMEM CONTROL-M Communication ................................................................................3-42
Coupling Facility and Coupling Facility Resource Management .....................................3-42
MVS System Logger Sysplex Interface ..............................................................................3-43
Problem Determination.......................................................................................................3-43
CONTROL-M Tuning Recommendations ............................................................................ 3-45
General Tuning Issues .............................................................................................................3-45
Placing the IOA LOAD Library in the MVS Linklist (MVS/XA Sites).............................3-45
Placing CONTROL-M/IOA Files on Appropriate Disk Packs...........................................3-46
Placing Certain CONTROL-M/IOA Files on Special Disk Devices ..................................3-46
Enlarging CONTROL-M/IOA File Blocksize .....................................................................3-47
CONTROL-M Monitor and MVS/JES Considerations ...........................................................3-48
Table of Contents
xii IOA Rel. 5.1.4 Administrator Guide
Special Considerations ....................................................................................................... 3-48
Run CONTROL-M on the Global Processor in a JES3 Complex ..................................... 3-49
Run CONTROL-M on the CPU Where Most JES2 Activity is Performed......................... 3-50
JES2PARM Tuning Considerations .................................................................................. 3-50
Assign Appropriate Priority to the CONTROL-M Monitor ................................................... 3-51
Run the CONTROL-M Monitor as Non-swappable.......................................................... 3-51
Choose an Appropriate Sleeping Interval ......................................................................... 3-51
Storage Isolation................................................................................................................. 3-52
Tuning the Online Facility...................................................................................................... 3-53
Preallocate Required CONTROL-M/IOA Files in TSO Logon Procedures ........................... 3-53
Try to Eliminate TSO STEPLIBs ...................................................................................... 3-53
Use the IOA Server Mechanism When Required ............................................................. 3-53
Mirror File (Dual Checkpointing Mode) Considerations....................................................... 3-53
CONTROL-M Event Manager (CMEM) Considerations....................................................... 3-54
CONTROL-M Optional Wishes............................................................................................... 3-54
CONTROL-M Multi-CPU Support.......................................................................................... 3-54
Introduction.............................................................................................................................. 3-54
Single-CPU Configuration with Multiple CONTROL-M Systems .................................. 3-56
Multi-CPU Configuration........................................................................................................ 3-57
Shared-Spool Configuration With an ENQ-Handling Product ..................................... 3-57
Shared Spool Configuration Without an ENQ-Handling Product................................ 3-60
Shared-Spool Configuration with Multiple CONTROL-M Production Systems............. 3-61
Multi-CPU Configuration With Shared-DASD Only........................................................ 3-63
NJE Network of MVS Nodes.............................................................................................. 3-64
Special Considerations ............................................................................................................ 3-66
Mainframe with PR/SM (or MDF or MLPF) ..................................................................... 3-66
Operating MVS System(s) Under VM............................................................................... 3-67
Support of Other Platforms (VM, DOS/VSE, AS/400, DEC, HP, etc.)............................. 3-67
Support of Network Software............................................................................................. 3-69
CONTROL-M

VM Support ....................................................................................................... 3-71
Introduction.............................................................................................................................. 3-71
VM Configurations................................................................................................................... 3-71
MVS Running Under VM........................................................................................................ 3-72
MVS and VM Running on Separate Computers .................................................................... 3-73
MVS and VM Running Under PR/SM, MDF or MLPF ......................................................... 3-74
Invoking the IOA Online Facility From a VM Terminal....................................................... 3-74
Dialing Into the MVS Machine (MVS Under VM Only)........................................................ 3-75
Using VM/VTAM...................................................................................................................... 3-75
Using IOAs Logical Terminal Emulator................................................................................ 3-75
Table of Contents
IOA Rel. 5.1.4 Administrator Guide xiii
Using a Session Handling Product ..........................................................................................3-75
File Transfer From MVS to VM...............................................................................................3-75
General.................................................................................................................................3-75
Routing the Production Jobs Report to VM via JCL ........................................................3-76
Routing Production Job Sysout to VM via JCL .................................................................3-76
Routing Production Job Sysout to VM via CONTROL-M Sysout Functions.........................3-77
Sending a File to VM in the Form of a Sysout...................................................................3-77
File Transfer Products..............................................................................................................3-77
Utilize a Shared Disk Between MVS and VM........................................................................3-78
Triggering an Event in CONTROL-M by a VM User.............................................................3-78
Submitting a Job to MVS to Execute a CONTROL-M Utility ..........................................3-78
Submitting a Job to MVS to be Monitored by CMEM.......................................................3-78
CONTROL-M Triggering of Events in VM.............................................................................3-79
Issuing a VM CP Command via IOAOPR (MVS Under VM only) ...................................3-80
Executing VM Commands via the IOAVAUTO Machine .................................................3-81
Issuing a SHOUT Message to a VM User ...............................................................................3-82
General.................................................................................................................................3-82
Using Utility IOAOPR ........................................................................................................3-83
Using the VM IOAVAUTO Machine ..................................................................................3-83
Other IOA Options ..............................................................................................................3-83
IOA An Integrated Solution..................................................................................................3-83
General.................................................................................................................................3-83
CONTROL-O .......................................................................................................................3-84
CONTROL-O/PC .................................................................................................................3-84
CONTROL-D .......................................................................................................................3-84
Disaster Recovery Planning................................................................................................... 3-85
Overview ...................................................................................................................................3-85
Recovery Tools ..........................................................................................................................3-85
Dual Checkpoint Mode........................................................................................................3-85
Journaling............................................................................................................................3-86
Restoration...........................................................................................................................3-87
Planning and Creating a Disaster Recovery Plan..................................................................3-88
MVS, JES, Exits and Other Definitions.............................................................................3-88
Security Considerations ......................................................................................................3-88
Scheduling Libraries and Other Production Libraries......................................................3-88
Backup Procedures..............................................................................................................3-89
CONTROL-M Parameter Definitions.................................................................................3-89
Catalog Considerations .......................................................................................................3-90
Defining an Authorized TSO User .....................................................................................3-90
Table of Contents
xiv IOA Rel. 5.1.4 Administrator Guide
Problem Resolution.................................................................................................................. 3-90
General ................................................................................................................................ 3-90
AutoEdit Simulation Facility............................................................................................. 3-92
Disaster Relocation............................................................................................................. 3-93
Manual Recovery Procedures............................................................................................. 3-94
Automatic Recovery after a System Crash........................................................................ 3-95
Section 4: CONTROL-D and CONTROL-V
General........................................................................................................................................... 4-1
Activating the CONTROL-D Monitor....................................................................................... 4-1
Activating Generic Processing .................................................................................................. 4-1
Activating the Compressed Dataset Access Method................................................................ 4-2
Activating the IOA Archive Server (CONTROL-V) ................................................................. 4-2
Modifying the CONTROL-D Sleeping Interval........................................................................ 4-2
Loading the Recipient Tree ....................................................................................................... 4-3
Loading the Recipient Tree into the CONTROL-D Monitor .............................................. 4-3
Loading the Recipient Tree into the IOA Online Monitor.................................................. 4-3
Loading the Recipient Tree into CONTROL-D Application Server................................... 4-4
Loading the Recipient Tree into File Transfer Monitor ..................................................... 4-4
Reloading the Manual Conditions File..................................................................................... 4-4
Deactivating the CONTROL-D Monitor................................................................................... 4-4
Deactivating Generic Processing .............................................................................................. 4-5
Automatic Warning .............................................................................................................. 4-5
Deactivating the Compressed Dataset Access Method............................................................ 4-5
Deactivating the IOA Archive Server (CONTROL-V) ............................................................. 4-6
CONTROL-D/Decollation Server Integration.......................................................................... 4-6
New Day Processing ................................................................................................................... 4-6
Overview..................................................................................................................................... 4-6
Starting the New Day Procedure.............................................................................................. 4-7
New Day Procedure Workflow.................................................................................................. 4-7
User Daily Job............................................................................................................................ 4-8
Date Control Record .................................................................................................................. 4-8
Use of the Date Control Record by the User Daily Job ...................................................... 4-9
Use of the Date Control Record by the New Day Procedure............................................ 4-10
Programs Called During New Day Processing ...................................................................... 4-10
Parameters of the New Day Procedure .................................................................................. 4-12
Mission Scheduling................................................................................................................... 4-13
Overview................................................................................................................................... 4-13
Table of Contents
IOA Rel. 5.1.4 Administrator Guide xv
Scheduling Methods .................................................................................................................4-13
Scheduling Missions Via the New Day Procedure (CTDNDAY) ................................................4-14
Supplied Mission List Members .........................................................................................4-15
Scheduling Missions Via a User Daily Procedure ..................................................................4-16
Scheduling a Mission Manually...............................................................................................4-16
Scheduling Workflow................................................................................................................4-17
Decollation Mission Management......................................................................................... 4-19
Overview ...................................................................................................................................4-19
Generic Decollating Missions...................................................................................................4-19
Generic Decollating Mission Workflow..............................................................................4-19
Additional Considerations ..................................................................................................4-20
Scheduling Generic Decollating Missions Via the New Day Procedure...........................4-21
Controlling the Generic Process .........................................................................................4-21
Defining a Generic User Name List ...................................................................................4-22
Interfaces to Production Control Systems...............................................................................4-22
Overview of CONTROL-M Scheduling With CONTROL-D .............................................4-23
Job-Report Dependency ......................................................................................................4-25
Scheduling via the CONTROL-M Production Control System.........................................4-25
Scheduling via a Non-CONTROL-M Production Control System....................................4-27
Considerations for When CONTROL-M and CONTROL-D Are Installed.......................4-29
Printing Mission Management............................................................................................... 4-30
Printing Mission Workflow......................................................................................................4-31
Printing Mission Definition ................................................................................................4-31
Preparing the Skeleton .......................................................................................................4-33
Advanced Scheduling Issues....................................................................................................4-34
Distribution According to Scheduling Dates......................................................................4-34
Report Decollating and Printing Mission Dependency .....................................................4-35
Printer Control..........................................................................................................................4-35
One-Chunk Method.............................................................................................................4-35
Multi-Chunk Method...........................................................................................................4-36
One-Outgroup Method (JES2 Only) ...................................................................................4-37
Opening/Closing Printers....................................................................................................4-37
Printing Process...................................................................................................................4-38
Identifying CONTROL-D Chunks on Spool (JES2 Only) ......................................................4-39
CONTROL-D/Writer Facility...................................................................................................4-40
Activating the CONTROL-D/Writer Facility.....................................................................4-40
Printing on AFP (APA) Printers..............................................................................................4-42
Using CDAM PAGEDEF/FORMDEF Parameters............................................................4-43
Using a Specified OUTPUT Statement..............................................................................4-43
Table of Contents
xvi IOA Rel. 5.1.4 Administrator Guide
AFP Page Mode Output...................................................................................................... 4-44
Page Markers Under AFP.................................................................................................. 4-44
In-Stream AFP Control Statements .................................................................................. 4-44
Printing Using XEROX LCDS (DJDE) Parameters .............................................................. 4-46
Using OUTPARMS for Global Control of Printing Characteristics ................................................ 4-48
Printing to a File...................................................................................................................... 4-49
Tailoring Exit CTDX005..................................................................................................... 4-50
Advanced ACIF Interface Facility......................................................................................... 4-52
ACIF Utility Benefits............................................................................................................... 4-52
Making ACIF Accessible to CONTROL-D.............................................................................. 4-53
Activating the Advanced ACIF Interface ............................................................................... 4-53
ACIF Execution Parameters .............................................................................................. 4-53
ACIFPARM Library............................................................................................................ 4-54
WYSIWYG Viewing of XEROX Reports................................................................................. 4-56
Overview................................................................................................................................... 4-56
Initial Preparations ................................................................................................................. 4-56
Processing XEROX Reports..................................................................................................... 4-56
Parameters for the DVS Printer Emulator ............................................................................ 4-57
Activating the DVS Printer Emulator............................................................................... 4-57
CCIFPARM Library................................................................................................................. 4-57
Page On Demand....................................................................................................................... 4-59
Introduction.............................................................................................................................. 4-59
Page On Demand Components ............................................................................................... 4-59
Viewing AFP/CCIF Reports Under Page On Demand .......................................................... 4-61
Preparation for AFP Reports ............................................................................................. 4-61
Preparation for CCIF Reports............................................................................................ 4-61
Parameter STORE of Printing Mission Definition........................................................... 4-62
Starting Page On Demand on the Mainframe ....................................................................... 4-63
Displaying a List of All Active Users................................................................................. 4-63
Displaying Active Application Server Address Spaces..................................................... 4-64
Reloading the Recipient Tree............................................................................................. 4-64
Problem Determination........................................................................................................... 4-64
Mainframe PC File Transfer................................................................................................ 4-65
File Transfer Monitor .............................................................................................................. 4-65
File Transfer Protocols ............................................................................................................ 4-65
File Transfer Process ............................................................................................................... 4-65
Activating and Stopping the File Transfer Monitor ......................................................... 4-66
Reawakening the File Transfer Monitor ........................................................................... 4-66
Reloading the Recipient Tree............................................................................................. 4-66
Table of Contents
IOA Rel. 5.1.4 Administrator Guide xvii
File Transfer Monitor Parameters .....................................................................................4-66
CONTROL-D/Image................................................................................................................... 4-67
Sample Files..............................................................................................................................4-67
Implementing CONTROL-D/Image.........................................................................................4-68
Packing and Transferring CONTROL-D/Image Files............................................................4-68
Decollating and Indexing CONTROL-D/Image Files.............................................................4-68
Viewing CONTROL-D/Image Files .........................................................................................4-70
Backup Mission Management ................................................................................................ 4-71
Overview ...................................................................................................................................4-71
Backup According to Scheduling Dates .............................................................................4-71
Report Decollating and Backup Mission Dependency.......................................................4-72
Backup Mission Workflow........................................................................................................4-73
Exception Handling.............................................................................................................4-75
Changing the Backup Mission Retention Period....................................................................4-75
Backup Mission Considerations...............................................................................................4-76
Restore Mission Management ................................................................................................ 4-77
Overview ...................................................................................................................................4-77
Restoring According to Scheduling Dates..........................................................................4-77
Restore Mission Workflow........................................................................................................4-78
Exception Handling.............................................................................................................4-81
Restoring With the Original Backup Utility......................................................................4-81
Migration Mission Management (CONTROL-V Only) ...................................................... 4-82
Overview ...................................................................................................................................4-82
Migrating Reports.....................................................................................................................4-82
Multi-stage Migration ..............................................................................................................4-83
Migration Mission Report Correspondence .........................................................................4-83
MIG and MSM Migration Types..............................................................................................4-83
Scheduling Criteria ..................................................................................................................4-84
Primary and Secondary Migration..........................................................................................4-84
Migration Mission Skeleton Jobs.............................................................................................4-85
Sample Skeleton Job ...........................................................................................................4-86
Target Media Types..................................................................................................................4-88
Migration to Cartridge (CART) ..........................................................................................4-88
Migration to ROSs/OSS.......................................................................................................4-88
Migration to Disk, Fat-DASD, and IBM 3995 Optical Library Dataserver (in 3390
Emulation Mode) .................................................................................................................4-89
Migration to FileTek Storage Machine ..............................................................................4-89
Table of Contents
xviii IOA Rel. 5.1.4 Administrator Guide
Migration to OAM............................................................................................................... 4-90
Naming Conventions ............................................................................................................... 4-91
CDAM Datasets .................................................................................................................. 4-91
Indexes ................................................................................................................................ 4-92
Migration Mission Workflow................................................................................................... 4-93
Example: Multi-stage Migration Mission Workflow......................................................... 4-95
Exception Handling ................................................................................................................. 4-97
Job Archiving............................................................................................................................. 4-98
IOA Archive Server................................................................................................................. 4-100
General ................................................................................................................................... 4-100
Device Definition and Usage................................................................................................. 4-100
Cartridge (CART) Media .................................................................................................. 4-100
DataWare/ROSs/OSS Usage ............................................................................................ 4-101
Updating the OSS Database ............................................................................................ 4-101
FileTek Storage Machine Media Definition .................................................................... 4-102
Object Access Method (OAM) Usage ............................................................................... 4-103
Media and Resource Control ................................................................................................. 4-103
Media Control ................................................................................................................... 4-103
Resource Control............................................................................................................... 4-103
ROSs/OSS Media DataWare/ROSs/OSS Storage Subsystem...................................... 4-104
CART Media 3480/3490/3490E/3590 Tape Cartridge Subsystem............................... 4-104
FTK FileTek Storage Machine (SM) or OAM Object Access Method Media........... 4-105
Logical Device Status ....................................................................................................... 4-105
Reducing/Increasing the Number of Usable Devices...................................................... 4-106
Displaying Media Information.............................................................................................. 4-107
Problem Determination......................................................................................................... 4-108
User Report List File Management..................................................................................... 4-109
Overview................................................................................................................................. 4-109
Permanent User Report List File.......................................................................................... 4-110
Active User Report List File.................................................................................................. 4-112
Migrated User Report List File............................................................................................. 4-113
History User Report List File................................................................................................ 4-113
User Report List File Maintenance ...................................................................................... 4-115
Repository Maintenance........................................................................................................ 4-116
General ................................................................................................................................... 4-116
Expanding the Active Missions File ..................................................................................... 4-116
Expanding the Active Transfer File ..................................................................................... 4-117
User Report List File Housekeeping..................................................................................... 4-117
Reorganizing the Files...................................................................................................... 4-118
Table of Contents
IOA Rel. 5.1.4 Administrator Guide xix
Dynamic Sorting of the Active User Report List File......................................................4-118
Rebuilding the Index Component.....................................................................................4-119
Recovering a Damaged File ..............................................................................................4-119
SMF Accounting ...................................................................................................................... 4-120
Section 5: CONTROL-O
General ...........................................................................................................................................5-1
Starting CONTROL-O................................................................................................................5-1
Shutting Down CONTROL-O....................................................................................................5-2
Replacing an Active CONTROL-O Monitor ..............................................................................5-2
Replacing the Active CONTROL-O Executor Module (CTOWTO).....................................5-2
Replacing the Active CMEM Executor Module (CTOAIDT)...............................................5-2
Rule Types...................................................................................................................................5-3
Automatic Loading of Rules.......................................................................................................5-4
Manual Loading of Rules ...........................................................................................................5-5
Manual Loading of CMEM Rules ..............................................................................................5-6
Deleting (Deactivating) an Active Rule Table ..........................................................................5-7
Rule Loading Errors Related to Type of Table..........................................................................5-7
Virtual Storage Requirements of the CONTROL-O Monitor.............................................5-9
Calculating Region Size .............................................................................................................5-9
Troubleshooting ........................................................................................................................5-10
Storage Allocation.....................................................................................................................5-10
Structure of the IOA Conditions/Resources File.....................................................................5-10
CONTROL-O Usage of the Common Storage Area (E/CSA)............................................. 5-11
Extended CSA Usage (Above the 16M Line)...........................................................................5-11
CSA Usage (Below the 16M Line)............................................................................................5-11
Recommended Organization Method................................................................................... 5-12
Replacing the IPL CONTROL-O .............................................................................................5-14
Rule Scheduling........................................................................................................................5-15
Displaying Active Rules ......................................................................................................5-15
Management of CONTROL-O Facilities............................................................................... 5-16
Controlling the Message Statistics Facility ............................................................................5-16
Preventing Unnecessary Enlargement of Statistics Files.................................................5-17
Handling Near-Full and Full Conditions for the Statistics File.......................................5-17
Controlling the Automation Log Facility ................................................................................5-18
Determining the Size of the Log.........................................................................................5-18
Preventing Logging of Unnecessary Messages..................................................................5-19
Management of the CONTROL-O Status Monitoring System (COSMOS)...........................5-19
Table of Contents
xx IOA Rel. 5.1.4 Administrator Guide
Controlling Rule Operation Mode........................................................................................... 5-20
Controlling OpenEdition (UNIX for MVS) Support............................................................... 5-21
Global AutoEdit Variables ...................................................................................................... 5-23
Defining a New Global Member or Variable Database .................................................... 5-25
Automatic Compression of the Global AutoEdit Library ................................................. 5-27
Modifying the CONTROL-O Sleeping Interval...................................................................... 5-28
Refreshing the CONTROL-O Security Cache ........................................................................ 5-29
Customization of Automation Options................................................................................. 5-34
AOP Overview.......................................................................................................................... 5-34
Menus ....................................................................................................................................... 5-35
Menu Member Syntax ........................................................................................................ 5-35
Parameters.......................................................................................................................... 5-35
Format Members...................................................................................................................... 5-39
Client Programs....................................................................................................................... 5-39
Program Input.......................................................................................................................... 5-40
Execution Process .................................................................................................................... 5-40
Client Program Linkage Conventions .................................................................................... 5-40
Considerations for When CONTROL-M and CONTROL-O Are Installed..................... 5-41
CONTROL-O/CICS Interface .................................................................................................. 5-42
CONTROL-O Interface for the CICS Environment............................................................... 5-42
CONTROL-O/IMS Interface..................................................................................................... 5-43
Operating the CONTROL-O/IMS Interface ........................................................................... 5-43
CONTROL-O/IMS Commands................................................................................................ 5-43
Starting CONTROL-O Communication Support (CTOGATE)............................................... 5-44
Displaying a List of All Active Users...................................................................................... 5-44
Table of Contents
IOA Rel. 5.1.4 Administrator Guide xxi
Section 6: CONTROL-B
General ...........................................................................................................................................6-1
CONTROL-B New Day Procedure............................................................................................6-1
Reformatting the Active Balancing File Utility CTBFRM....................................................6-2
Scheduling Balancing Missions .................................................................................................6-2
Date Control Record ...................................................................................................................6-2
Format of the Date Control Record ...........................................................................................6-3
Use of the Date Control Record by the New Day Procedure....................................................6-3
Invoking CONTROL-B (Runtime Environment) ..................................................................6-5
Passing Arguments While Invoking CONTROL-B ..................................................................6-5
Invoking CONTROL-B Via a Direct Call ..................................................................................6-7
Invoking CONTROL-B From a Job Step or Application Program ..........................................6-8
Invoking CONTROL-B by CONTROL-M..................................................................................6-9
Invoking CONTROL-B by CONTROL-D..................................................................................6-9
Invoking CONTROL-B With Balancing Missions ..................................................................6-10
Section 7: CONTROL-T
General ...........................................................................................................................................7-1
CONTROL-T Real-Time Environment ....................................................................................7-2
Initialization ...............................................................................................................................7-2
Procedure CTTINIT....................................................................................................................7-3
Loading of Rules .........................................................................................................................7-6
Termination ................................................................................................................................7-6
New Day Procedure.....................................................................................................................7-7
New Day Functions ....................................................................................................................7-7
New Day Processing..............................................................................................................7-7
Repository Structure...................................................................................................................7-9
Media Database Structure .........................................................................................................7-9
Data File Contents ..............................................................................................................7-10
Fields in the Data File.........................................................................................................7-11
Index File Contents .............................................................................................................7-12
Structure of the Trace File.......................................................................................................7-17
Structure of the Stacking Database ........................................................................................7-18
Repository Maintenance ......................................................................................................... 7-19
Verifying Data Integrity of Media Databases.........................................................................7-19
Manual Update of the Media Database...................................................................................7-21
Enlarging the Media Database................................................................................................7-21
Table of Contents
xxii IOA Rel. 5.1.4 Administrator Guide
Enlarging the Trace File ......................................................................................................... 7-22
Enlarging the Stacking Database........................................................................................... 7-24
Repository Backup and Recovery......................................................................................... 7-25
General ..................................................................................................................................... 7-25
Media Database Backup.......................................................................................................... 7-25
Media Database Recovery ....................................................................................................... 7-25
Disaster Recovery .................................................................................................................... 7-26
Selective Recovery.................................................................................................................... 7-27
Cartridge Message Display Customization......................................................................... 7-27
CONTROL-R Support for CONTROL-T................................................................................ 7-29
CONTROL-R Driver Exit CTRX001G.................................................................................... 7-29
Installing the CONTROL-R Interface .................................................................................... 7-29
CONTROL-T Application Programming Interface ........................................................... 7-30
Background Information......................................................................................................... 7-31
CONTROL-T Control Table (TCT).......................................................................................... 7-31
Creating a Local TCT .............................................................................................................. 7-32
Obtaining the Address of the Real-Time TCT........................................................................ 7-33
Media Database Structure ...................................................................................................... 7-34
Base Level vs. High Level API ................................................................................................ 7-34
Base Level API ........................................................................................................................... 7-35
Record Access by the Base Level API ..................................................................................... 7-35
Macro CTTIOS......................................................................................................................... 7-36
Base Level API Access of the Media Database....................................................................... 7-40
Examples for Base Level API.................................................................................................. 7-42
Macro CTTACCDB .................................................................................................................. 7-54
Macro CTTCHKDB.................................................................................................................. 7-55
Media Database Error Handling Routine .............................................................................. 7-56
Example for High Level API ................................................................................................... 7-57
Input ......................................................................................................................................... 7-61
Output ...................................................................................................................................... 7-61
Invoking the Rule Search API................................................................................................. 7-63
Sample Call to the Rule Search API.................................................................................. 7-64
Return Codes....................................................................................................................... 7-64
Sample For Using the Rule Search API ................................................................................. 7-65
Table of Contents
IOA Rel. 5.1.4 Administrator Guide xxiii
Section 8: Maintaining IOA Products
Introduction..................................................................................................................................8-1
IOA Release 5.1.4 Packaging .....................................................................................................8-1
Product Packaging......................................................................................................................8-1
Language Support ......................................................................................................................8-2
Applying Periodic Maintenance...............................................................................................8-4
Preliminary Steps.......................................................................................................................8-4
Installation Steps........................................................................................................................8-4
Step 1 Apply Periodic Maintenance ....................................................................................8-4
Applying Ad Hoc Maintenance .................................................................................................8-5
Introduction ................................................................................................................................8-5
Step 1 Run SMP/E to RECEIVE, APPLY CHECK and APPLY the Fix ...........................8-5
Step 2 Customize and Propagate Fix Elements to Working Libraries..............................8-7
Processing Elements with DEFPARMx Members or a SYSLIB Library of GENERAL....8-9
Step 3 Enable Fixes Applied to ICE..................................................................................8-11
Step 4 Copy JCL Procedures and ISPF Elements to System Libraries (Optional) ........8-11
Section 9: Utilities
General ...........................................................................................................................................9-1
Summary of Utilities ...................................................................................................................9-1
IOA Utilities................................................................................................................................9-1
CONTROL-M Utilities ...............................................................................................................9-2
CONTROL-D/V Utilities ............................................................................................................9-3
CONTROL-O Utilities................................................................................................................9-4
CONTROL-B Utilities ................................................................................................................9-4
CONTROL-T Utilities ................................................................................................................9-5
IOA Utilities...................................................................................................................................9-7
IOABLCAL Build Calendars ..................................................................................................9-7
IOACLRES Clean IOA Conditions/Resources File..............................................................9-13
IOACND Perform IOA Condition/Resource Adjustments...................................................9-16
IOACOPRS Copy/Resize IOA Conditions/Resources File ...................................................9-20
IOACPLOG Copy the IOA Log File......................................................................................9-21
IOADBF Allocate/Format an IOA Access Method File........................................................9-23
IOADBSR Sort Records in an IOA Access Method Data Component ................................9-31
IOADCPY Recover an IOA Access Method File...................................................................9-33
IOADIG Verify Integrity of an IOA Access Method File Data Component........................9-35
Table of Contents
xxiv IOA Rel. 5.1.4 Administrator Guide
IOADII Verify Integrity of an IOA Access Method File Index Component....................... 9-36
IOADLD Load IOA Access Method File Contents .............................................................. 9-37
IOADPT Print IOA Access Method File Content................................................................ 9-39
IOADUL Unload IOA Access Method File Contents .......................................................... 9-40
IOAFRLOG Allocate and Format the IOA Log File............................................................ 9-42
IOAFRNRS Allocate and Format the IOA Manual Conditions File.................................. 9-43
IOAFRRES Allocate and Format the IOA Conditions/Resources File.................................... 9-44
IOALDNRS Load IOA Manual Conditions File.................................................................. 9-46
IOANOTE Write a Message to the IOA Log File ................................................................ 9-49
IOAOPR - Issue Operator Commands Via a Job or STC....................................................... 9-50
IOATEST Simulate Production Environment Events........................................................ 9-51
IOAVERFY Verify IOA File Installation and Status ......................................................... 9-53
CONTROL-M Utilities............................................................................................................... 9-59
CTMBGRP Convert Regular Scheduling Tables to Group Scheduling Tables ................. 9-59
CTMCAJF Maintain the Active Jobs File or History File.................................................. 9-62
CTMFRCKP Allocate and Format the Active Jobs File ..................................................... 9-68
CTMFRJNL Allocate and Format the Journal File............................................................ 9-69
CTMJSA Job Statistics Accumulation................................................................................. 9-70
CTMRSTR Restore the CONTROL-M Active Jobs File...................................................... 9-73
CONTROL-B Utilities ............................................................................................................... 9-75
CTBABI Initialize Active Balancing File ............................................................................ 9-75
CTBCMP Compile Rule Definitions..................................................................................... 9-76
CTBDBCP Increase Size of a Database File ....................................................................... 9-77
CTBDBIB Rebuild a CONTROL-B Index File.................................................................... 9-79
CTBDBVCG Change Number of Variable Generations ..................................................... 9-81
CTBDBVCP Copy Variables or Groups to Another File..................................................... 9-83
CTBDBVDL Delete Variables/Groups from Variable/Group Files .................................... 9-86
CTBDBVIG Check the Integrity of Variable/Group Files.................................................. 9-88
CTBFRM Compress the Active Balancing File................................................................... 9-89
CTBJAFCP Copies Entries in Rule Activity/Report Files.................................................. 9-90
INCLUDE/EXCLUDE Statements.................................................................................... 9-90
CTBJAFDL Deletes Entries From Rule Activity/Report Files........................................... 9-92
CTBJAFIG Check the Integrity of Rule Activity/Report Files........................................... 9-94
CONTROL-D/V Utilities ........................................................................................................... 9-95
CTDBLXRP Rebuild Print Control Records in the Active User File ................................. 9-95
CTDCAMF Compress Active Missions File......................................................................... 9-96
CTDCATF Compress Active Transfer File.......................................................................... 9-98
CTDCA2P Copy Active User Report File to Permanent..................................................... 9-99
Table of Contents
IOA Rel. 5.1.4 Administrator Guide xxv
CTDCCU Delete Unneeded CDAM Files ...........................................................................9-101
CTDCLHIS Clean History User Report List File ..............................................................9-103
CTDCP2A Copy Permanent User Report File to Active ...................................................9-104
INCLUDE/EXCLUDE Statements...................................................................................9-104
CTDDELRP Delete Reports Which Are Not Needed.........................................................9-106
Examples............................................................................................................................9-111
CTDDIB Rebuild Index Component of a User Report List File........................................9-114
CTDDIG User Report List File Integrity Check................................................................9-115
CTDULD User File Report List Load.................................................................................9-116
CTDUPBKP Update Backup/Migration Details................................................................9-117
CTVCLMIG Clean Migrated CDAM Files .........................................................................9-123
CTVDELI Delete Index Files from DASD..........................................................................9-125
CTVJAR Job Archiving Utility ...........................................................................................9-129
CTVUNMIG Unmigrate Utility..........................................................................................9-132
CONTROL-O Utilities............................................................................................................. 9-133
CTOCSF Copy the Message Statistics File........................................................................9-133
CTOCTA List Programs Running in an Address Space....................................................9-134
CTOCTI Generate Input for the SYSIMAGE Facility ......................................................9-135
CTODBIB Rebuild a CONTROL-O Index File ..................................................................9-138
CTORSTM Statistics Report Utility...................................................................................9-140
CTOTEST Simulate Messages and/or Commands ............................................................9-141
CTOALOCP Backing Up the Automation Log...................................................................9-144
CONTROL-T Utilities ............................................................................................................. 9-146
Control Statement Syntax .....................................................................................................9-146
Record Selection Logic (INCLUDE/EXCLUDE Statements) ...............................................9-146
INCLUDE Statements ......................................................................................................9-147
EXCLUDE Statements .....................................................................................................9-148
INCLUDE/EXCLUDE Examples .....................................................................................9-151
CTTACP Copy Trace File....................................................................................................9-152
CTTAFR Format and Initialize Trace File.........................................................................9-155
CTTBIX Rebuild Media Database Index............................................................................9-156
CTTCRDF Allocate and Format Data/Index Files ............................................................9-158
CTTCTRC Allocate and Format Trace File........................................................................9-160
CTTDBDLD Load Media Database/Stacking Database Data Components.....................9-161
CTTDBDUL Unload Media Database/Stacking Database Data Components.................9-162
CTTDBF Format Existing Data/Index Files......................................................................9-163
Table of Contents
xxvi IOA Rel. 5.1.4 Administrator Guide
CTTDBIB Rebuild Indexes of Stacking Database ............................................................ 9-164
CTTDBID Check Integrity of Data File ............................................................................ 9-165
CTTDBII Check Integrity of Index File ............................................................................ 9-166
CTTDBPRT Print Data Records ........................................................................................ 9-167
CTTDLD Add/Delete/Convert Volumes............................................................................. 9-169
CTTGVL User Interface to Stacking Facility.................................................................... 9-173
CTTIDB Check Integrity of the Media Database ............................................................. 9-175
CTTMER Merge Records Into the Media Database.......................................................... 9-177
CTTMUP Manually Update the CONTROL-T Repository............................................... 9-180
CTTRCV Recover the Media Database Using Trace File................................................. 9-191
CTTRPT Database Extraction and Report Utility............................................................ 9-195
INCLUDE/EXCLUDE Statements.................................................................................. 9-197
CTTRSM Recover Tape Activity From SMF Records ....................................................... 9-214
CTTRTM Perform Retention Management....................................................................... 9-218
CTTSBD Perform Dataset Stacking in Batch Mode......................................................... 9-234
CTTSCA Dataset Contention Detection............................................................................ 9-264
CTTSPL Copies or Moves Media Database Records......................................................... 9-271
CTTSTK Build and Update Stacking Database ............................................................... 9-276
INCLUDE/EXCLUDE...................................................................................................... 9-277
CTTSTKR Stacking Statistics Report Utility ................................................................... 9-279
CTTSYNC Synchronize Robot Database & Media Database........................................... 9-283
CTTTPI Tape Initialization, Information Mapping, and Tape Erasure.......................... 9-285
CTTTRB Synchronize Trace File and Media Database Backup ...................................... 9-300
CTTVTM Perform Vault Management.............................................................................. 9-301
Section 10: Exits
General......................................................................................................................................... 10-1
USERMODs ............................................................................................................................. 10-1
USERMOD Installation Jobs............................................................................................. 10-1
Definitions........................................................................................................................... 10-2
ID Check.............................................................................................................................. 10-3
Element Status NOT SEL During APPLY........................................................................ 10-3
Link-edit Updates............................................................................................................... 10-3
Including Local CSECTs in IOA Exits .............................................................................. 10-4
Summary USERMOD Jobs............................................................................................. 10-4
IOA Exits...................................................................................................................................... 10-5
CONTROL-M Exits .................................................................................................................... 10-9
CMEM Exits...................................................................................................................... 10-11
Table of Contents
IOA Rel. 5.1.4 Administrator Guide xxvii
CONTROL-R Exits................................................................................................................... 10-12
CONTROL-D/V Exits............................................................................................................... 10-14
Replacing CONTROL-D User Exits ......................................................................................10-20
Tailoring CONTROL-D Banner Exit.....................................................................................10-21
General...............................................................................................................................10-21
Banner Pages..........................................................................................................................10-21
Format of Banner Pages ...................................................................................................10-22
Printing User Address in Bundle Banner........................................................................10-24
Eliminate Banners ............................................................................................................10-25
INDEX Printing Control ...................................................................................................10-25
Banner Printing Options...................................................................................................10-26
OUTPARM Options...........................................................................................................10-27
AFP (APA) Support ...........................................................................................................10-27
XEROX (DJDE) Support...................................................................................................10-27
Summary............................................................................................................................10-27
CONTROL-B Exits................................................................................................................... 10-28
CONTROL-T Exits................................................................................................................... 10-29
CONTROL-O Exits................................................................................................................... 10-31
Section 11: CONTROL-M/WorkLoad
Activating the CONTROL-M/WorkLoad Monitor .............................................................. 11-1
Shutting Down the CONTROL-M/WorkLoad Monitor...................................................... 11-1
Command Scope ........................................................................................................................ 11-2
Monitor Control Commands................................................................................................... 11-3
Modifying the CONTROL-M/WorkLoad Operation Mode......................................................11-3
Modifying the CONTROL-M/WorkLoad Sleeping Interval....................................................11-4
Reloading the Installation Parameters ...................................................................................11-4
Reloading CONTROL-M/WorkLoad Programs.......................................................................11-5
Rule Management ..................................................................................................................... 11-6
Manual Loading of Rules to the Active Environment ............................................................11-6
Deleting a Rule Table From the Active Environment ............................................................11-7
Holding/Releasing a Loaded Rule............................................................................................11-8
Displaying Rules.....................................................................................................................11-10
Pipe Control Commands........................................................................................................ 11-10
Displaying the Pipe Information Summary..........................................................................11-10
Displaying Pipe Information..................................................................................................11-11
Forcing End-Of-File Indication on a Pipe .............................................................................11-12
Canceling an Active Pipe .......................................................................................................11-12
Table of Contents
xxviii IOA Rel. 5.1.4 Administrator Guide
Unlocking a Pipe.................................................................................................................... 11-13
Participant Control Commands........................................................................................... 11-13
Displaying Participant Information ..................................................................................... 11-13
Job Control Commands ......................................................................................................... 11-14
Displaying the Parallel Job Information Summary............................................................. 11-14
Displaying Parallel Job Information .................................................................................... 11-14
Cancel Active Job/Step .......................................................................................................... 11-15
Unlocking a JOB.................................................................................................................... 11-15
Problem Determination Commands ................................................................................... 11-16
Internal Trace Management ................................................................................................. 11-16
Activating the Internal Trace .......................................................................................... 11-16
Stopping the Internal Trace............................................................................................. 11-18
Displaying the Internal Trace Setting............................................................................. 11-18
Displaying Pipe and Participant Information...................................................................... 11-18
Displaying Data Space Information ..................................................................................... 11-19
Printing Internal Data .......................................................................................................... 11-19
Printing Pipe-Related Tables........................................................................................... 11-19
Printing Participant (ASID) Related Tables................................................................... 11-20
Printing Data Space (CLPOOL) Contents ...................................................................... 11-20
Printing General Data Areas ........................................................................................... 11-20
Display Command Output Formats .................................................................................... 11-21
Display Rules ......................................................................................................................... 11-21
Display All Pipes.................................................................................................................... 11-22
Display Specific Pipe Information ........................................................................................ 11-23
General Pipe Information................................................................................................. 11-24
Pipe I/O Information......................................................................................................... 11-26
General Participant Information..................................................................................... 11-26
Participant I/O Information............................................................................................. 11-28
Display Participant Information........................................................................................... 11-29
Address Space Information.............................................................................................. 11-29
Pipe Information............................................................................................................... 11-29
Display Parallel Job Information Summary ........................................................................ 11-31
Display Parallel Job Information.......................................................................................... 11-32
Job Information................................................................................................................. 11-32
Step Information............................................................................................................... 11-33
Table of Contents
IOA Rel. 5.1.4 Administrator Guide xxix
Section 12: ECSGATE
CONTROL-M-to-ECSGATE Communications Dataset ..................................................... 12-1
Defining Applications .............................................................................................................. 12-1
Appendixes
Appendix A: IOA Application Program Names ................................................................... A-1
Appendix B: Dataset Formatting Utilities for IOA Products...........................................B-1
Appendix C: Modifying IOA Online Facility Commands ..................................................C-1
Modifying IOA Online Facility PFKey Definitions.................................................................. C-1
Appendix D: Logical Field Names for the CONTROL-T Repository .................................D-1
Appendix E: IOA Online Options Cross-Reference............................................................ E-1
Appendix F: IOAMEM Module................................................................................................. F-1
Appendix G: Customizing the CONTROL-M Status Screen.............................................G-1
Appendix H: CONTROL-O Modify Commands................................................................... H-1
Index
IOA Rel. 5.1.4 Administrator Guide
Introduction..................................................................................................................................1-1
IOA Products.................................................................................................................................1-1
Installation and Maintenance...................................................................................................1-3
Installation and Customization Engine (ICE) ..........................................................................1-3
Product Maintenance .................................................................................................................1-3
Online Facility ..............................................................................................................................1-3
Primary Option Menu ................................................................................................................1-4
Logic................................................................................................................................................1-4
Automated Processing Definitions ............................................................................................1-4
Jobs.........................................................................................................................................1-5
Missions .................................................................................................................................1-5
Rules.......................................................................................................................................1-5
Monitors ......................................................................................................................................1-5
IOA Monitors .........................................................................................................................1-6
Product-Specific Monitors.....................................................................................................1-6
Daily Processing/New Day Processing ......................................................................................1-7
File Management........................................................................................................................1-8
IOA Access Method................................................................................................................1-8
IOA Core ................................................................................................................................1-8
Product Repositories............................................................................................................1-10
IOA and Product PARM Libraries .....................................................................................1-13
Miscellaneous............................................................................................................................1-13
Dynamic Destination Table ................................................................................................1-13
AutoEdit Facility .................................................................................................................1-13
Security Implementation ....................................................................................................1-14
User Exits ............................................................................................................................1-14
Utilities ................................................................................................................................1-14
Simulation............................................................................................................................1-14
Cross-Product Communication...........................................................................................1-15
Inter-System Communications Facility .............................................................................1-16
IOA Rel. 5.1.4 Administrator Guide 1 1
Introduction
IOA (Integrated Operations Architecture) is a fully integrated family of products designed
to help you streamline and automate your mainframe operations.
IOA provides you with the capability of implementing unattended, lights out operations.
The IOA family of products share a set of common components and concepts. This section
contains an introduction to the IOA products and the basic concepts and components used
in IOA processing.
IOA Products
The IOA products, which can be used to automatically manage the functioning of an MVS
data center are:
CONTROL-M Automated Production Control and Scheduling System
Manages and automates the setup, scheduling, and execution of jobs
in your MVS data center.
CONTROL-R Restart Management System
Automates the activities which must be performed when restarting
failed jobs, including the scratching and uncataloging of datasets
created by failed jobs.
CONTROL-D Output Management System
Automatically schedules and controls every aspect of report processing
and distribution, including report decollating, bundling, printing,
online viewing and backup.
CONTROL-V Quick Access Archive Viewing System
Replaces microfiche and provides online access to archived data via
indexed data retrieval.
CONTROL-D/PC Online Viewing and Manipulation of Mainframe Reports
Enables viewing, editing and printing of mainframe reports from
the PC.
CONTROL-O Console Automation System
Monitors and automatically responds to messages, commands and
dataset events.
CONTROL-O/
COSMOS
Status Monitoring System
Monitors objects in the system and maintains them in specified
desired statuses.
CONTROL-O/
Server
Outboard Console Automation
Allows outboard console automation of multiple platforms via a PC,
and provides consolidation and management of messages from
multiple consoles via a single point of control.
CONTROL-T Removable Media Management System
Increases removable media utilization, controls retention periods,
prevents misuse of media, and provides tape library and vault control.
1 2 IOA Rel. 5.1.4 Administrator Guide
CONTROL-B Automated Information Integrity System
Performs in-stream validation, and accuracy/reasonability checks on
information used by data center production tasks (e.g., reports, files,
databases).
CONTROL-I/2000 Year 2000 Automated Testing and Data Validation Solution
Provides a Year 2000 Solution Set that addresses data validation
issues, covers the Year 2000 testing lifecycle, and forms the basis for a
permanent enterprise-wide automated quality control system.
CONTROL-M/
WorkLoad
Batch Optimization System
Uses pipes to replace sequential processing with parallel processing
and to optimize resource utilization.
IOA/Pathfinder IOA Cross-Reference
Facilitates impact analysis, change management, and the
enhancement of IOA product performance by collecting and analyzing
data from IOA and non-IOA resources (such as JCL libraries, load
module libraries, and source libraries). Automatically locates all
references to IOA components, and reports JCL-IOA relationships,
IOA-MVS object relationships, and IOA component interrelationships.
Related to the IOA family of products are the IOA for the Enterprise family of client/server
products for automation of MVS and non-MVS platforms.
A number of common components are shared by IOA products. Furthermore, various IOA
products use similar operating procedures. The remainder of this section contains a brief
description of components and features common to IOA products, followed by references
indicating where more detailed information can be found.
Installation and Maintenance
IOA installation is performed using an ISPF menu-driven interface (Installation and
Customization Engine).
Maintenance is performed periodically using SMP/E.
Installation and Customization Engine (ICE)
ICE is an ISPF application used to install and customize IOA products. It consists of a
series of dialog screens that provide a simple method to enter data and to create and
submit installation jobs.
Tasks in ICE are organized in a hierarchical manner.
ICE displays the IOA installation online activities in the IOA Installation Main menu.
Each menu option represents a key activity related to installing and maintaining IOA
(e.g., INSTALL IOA, INSTALL CTx, SECURIT Y, and CUSTOMIZE).
Each activity is organized as a list of major steps. Each major step consists of a one or
more minor steps.
Each minor step allows the user to specify parameters, submit jobs, or perform other
tasks related to the installation process.
The ICE application is described in detail in the IOA Installation Guide.
Product Maintenance
Product maintenance is the process by which updates are implemented between releases.
In IOA Release 5.1.4, these updates are implemented via SMP/E only.
Product maintenance consists of periodic maintenance and ad hoc maintenance:
Periodic maintenance contains improvements to the software and solutions to problems
that were discovered during day-to-day product use. As the name suggests, this kind of
maintenance is distributed periodically to the users.
See Section 8 for a detailed description of maintenance implementation.
Online Facility
The IOA Online facility is a set of interactive applications which facilitate communication
with IOA. The IOA Online facility generates all IOA screens and handles all IOA online
functions.
The IOA Online facility can be accessed directly under TSO, ISPF, TSO/ISPF and
ROSCOE. In addition, the IOA Online facility (IOAOMON) can be accessed via CICS, IMS,
IDMS, VTAM, ROSCOE, TSO, COM-PLETE or VM under the IOA Online monitor.
When a user enters the IOA Online environment via a communication monitor or
TSO/ISPF, the IOA Primary Option menu is displayed. This menu lists the options
available to the user.
The IOA Online facility is described later in this section and in Section 2 of this guide.
Primary Option Menu
The IOA Primary Option menu displays IOA product options and facilities available to the
user.
The IOA Primary Option menu is dynamically generated according to the products and options
available to the user. The IOA administrator can optionally customize the environment so that
specific products and options are available only to certain users or user groups.
The IOA Primary Option menu is displayed in one of two formats, depending on the
number of options available to the user.
Line Format Options are listed one per line with a description of each option.
Box Format Options are grouped according to product. Descriptions are not
displayed.
Reducing or increasing the number of available options may change the format in which
the IOA Primary Option menu is displayed.
Menu format and customization are described in detail in Customizing the IOA Online
Environment in Section 2 of this guide.
Logic
Listed below are various components of IOA products.
Automated Processing Definitions
Automated processing definitions enable the user to define the tasks to perform and when
to perform them. Automated processing definitions contain statements that describe
actions to be performed and criteria which define when and/or under what conditions the
actions should be performed. Each IOA product contains a definition facility by which
automated processing is defined.
Automated processing definitions are referred to as jobs, rules, or missions depending on
the IOA product and type of definition.
Online methods for creating automated processing definitions are described in Section 2 of
each IOA product user manual.
Job/rule/mission definitions are stored in tables (members) in partitioned datasets.
Definitions are activated by scheduling (ordering) them to an active environment (file or
memory, depending on the product). Only then can the product process these definitions.
The different types of automated processing definitions are described in the following
paragraphs.
Jobs
Job scheduling definitions are used by CONTROL-M to handle job processing. They can be
defined for jobs, started tasks, etc. Each job scheduling definition indicates scheduling
criteria and/or conditions to be met before CONTROL-M schedules or submits a particular
job. Each definition also indicates actions to be performed by CONTROL-M after the job
terminates. CONTROL-M can perform different post-processing actions, depending on the
execution results.
CONTROL-R parameters and statements are also defined in CONTROL-M job scheduling
definitions.
Missions
Missions are used by CONTROL-D/CONTROL-V to determine actions to be performed on
job output. When a mission s scheduling criteria are met, the actions indicated by the
statements in the mission definition are performed.
Missions are used by CONTROL-B to define scheduling criteria to be applied to
CONTROL-B rules which indicate actions to be performed.
Rules
Rules are used by CONTROL-O, CONTROL-T, the CONTROL-M Event Manager (CMEM),
and CONTROL-B to respond to specified events (e.g., the detection of a message by
CONTROL-O). The occurrence of the specified event triggers the rule which results in the
performance of the actions specified in the rule.
Rules are used by CONTROL-M/WorkLoad to determine when parallel processing via pipes
can be substituted for sequential processing via standard datasets.
Scheduled rules remain active in memory after the performance of the rule. They can be
triggered each time an occurrence of the specified event is detected. There is no limit to the
number of times a rule can be triggered.
Note CONTROL-B rule definitions contain only action statements. CONTROL-B rules are
either executed upon request without regard to scheduling criteria, or according to
scheduling criteria specified in a CONTROL-B mission described above.
Monitors
Monitors are started tasks which perform IOA functions. There are two types of monitors:
IOA monitors and product monitors.
Instructions for activating and deactivating each monitor are provided in the section of this
guide for the relevant product.
Each monitor and its functions are briefly described below.
IOA Monitors
IOA monitors perform tasks which cab be initiated from any of the IOA products.
IOA Online Monitor (IOAOMON)
The IOA Online monitor interacts with various environments (e.g., CICS) to provide the
online interface for IOA applications. The IOA Online monitor generates the IOA product
screens and handles all IOA Online functions.
The IOA Online monitor usually operates 24 hours a day as a started task is usually
activated automatically as part of the IPL process.
See The IOA Online Environment in Section 2 of this guide for more information.
IOA VTAM Monitor (IOAVMON)
The VTAM monitor (IOAVMON) enables access to the IOA Online monitor for VTAM users
without passing though any TP monitors (e.g., CICS, IMS/DC).
IOA Functional Monitor (IOAFMON)
CONTROL-T uses the IOA Functional monitor to process certain action statements (e.g.,
DO CONDITION and DO SHOUT).
When an event occurs (e.g., volume checked in, dataset created) which requires execution
of an action statement via the Functional monitor, the CONTROL-T component writes a
trace record that describes the needed action. The IOA Functional monitor reads the
CONTROL-T Trace file and processes the specified records.
The IOA Functional monitor is described in the CONTROL-T User Manual and in
Section 2 of the IOA Installation Guide.
IOA Archive Server Monitor (IOASMON)
The Archive server enables CONTROL-V users to view and print reports which have
migrated to non-DASD media.
IOA Gateway Monitor (IOAGATE)
The IOA Gateway is used by the CONTROL-D Page-On-Demand facility (CTDAS) and the
CONTROL-O Communication Gateway (CTOGATE). See Section 2 of the IOA Installation
Guide for information about IOAGATE hardware and software requirements and about
installing IOAGATE for communication support to CONTROL-D and/or CONTROL-O.
Product-Specific Monitors
Specific product monitors are responsible for many of the automated operations performed
by each product.
CONTROL-M
The CONTROL-M monitor scans its active environment (file) and other files to determine when
jobs should be submitted. It submits jobs, tracks their execution and analyzes the results.
If CONTROL-O is not installed and the CONTROL-M CMEM facility is active, a CMEM
monitor is activated which processes CMEM rules that were triggered by events in the system.
CONTROL-O
The CONTROL-O monitor processes rules that were triggered by events in the system and
records statistics on rule activation and message detection.
If CONTROL-M is installed, the CONTROL-O monitor also assumes responsibility for
processing CMEM rules.
CONTROL-D/V
CONTROL-D activates two monitors, the CONTROL-D monitor and the Printers Control
monitor. The CONTROL-D monitor scans its active environment (file) and other files to
determine when missions should be processed. It processes missions, tracks their execution
and analyzes the results.
If CONTROL-V is installed, this monitor also handles indexing of reports and their
migration to other storage media (e.g., Optical Storage, cartridges).
The CONTROL-D Printers Control monitor creates subtasks for each print mission, thus
enabling parallel execution of print missions.
If CONTROL-D/PC is installed, the CONTROL-D File Transfer monitor can transfer
CONTROL-D/PC packets from the mainframe to the PC. This monitor scans the Active
Transfer file and determines which packets should be transferred. The File Transfer
monitor is described in Section 4 of this guide.
The CONTROL-D Application server provides access to CONTROL-D/V User Report files
by CONTROL-D/PC Page On Demand. It is activated by the IOA Gateway monitor. Page
On Demand is described in Section 4 of this guide.
Daily Processing/New Day Processing
For most IOA products, there are a number of tasks that should be performed each day.
Typical daily tasks are:
Updating the active environment (file or memory) with definitions for the new day.
Checking files for integrity and validity.
Producing general reports that describe the actions taken during the previous day.
Housekeeping and cleaning unneeded information from product and IOA files.
These tasks are performed automatically via the New Day procedure for each product. The
New Day procedure is a program used to automate daily maintenance tasks and
automatically schedule processing definitions for each day.
New Day procedures and User Daily jobs are described in sections for the relevant
products in this guide (e.g., Section 3 for CONTROL-M).
File Management
There are two major ways to classify files used by IOA products:
According to access method
Files managed using a common internal access process called the IOA Access
Method.
Files managed using standard access methods.
According to usage
IOA Core files which are shared among IOA products.
Product repository files which are exclusively used by a particular IOA product.
IOA Access Method
Certain IOA products have files that are managed using an internal file access process
called the IOA Access Method.
IOA Access Method files are sequential datasets with an indexed (keyed) file structure that
offers enhanced data integrity. IOA Access Method files are managed (e.g., allocated,
formatted and accessed) via a special set of IOA utilities (described in Section 9 of this
guide).
Most IOA Access Method files consist of two separate sequential datasets:
A data component, where the actual information resides.
An index component, which provides keyed access to records in the data component.
Some IOA Access Method files contain only an index or data component.
Both index and data information are stored in a compressed format that reduces I/O
processing overhead and improves disk space utilization.
The IOA Access Method is described in greater detail in Section 2 of this guide.
IOA Core
The IOA Core is a collection of files which are shared by all IOA products at your site. The
following files comprise the IOA Core:
IOA Log File
Contains messages generated by IOA products. Messages can be viewed via option 5 in the
IOA Primary Option menu. The IOA Log file is cyclic. The maximum number of messages
that can be stored in (specified in an installation parameter). Each new entry in the IOA
Log file overwrites the oldest existing entry if required.
The IOA Log file is described in detail in Section 2 of each product-specific user manual.
IOA Conditions/Resources File
The IOA Conditions/Resources file contains information on the status and availability of
resources system wide. IOA conditions and resources can be viewed via option 4 in the IOA
Primary Option menu. The following types of information are included in this file:
Prerequisite conditions User-defined conditions set as in conditions (via IN
statements) or out conditions (via OUT and/or DO COND
statements) in job/rule/mission definitions.
When a condition is defined as an out condition, it is set (in
the IOA Conditions/Resources file) during or following the
processing of the job/rule/mission.
When a condition is specified as an in condition, the
condition must exist in the IOA Conditions/Resources file
before the job/rule/mission can be processed.
Prerequisite conditions can be used to make the execution of
one job/rule/mission dependent on the execution of another.
For example, a job with a particular in condition cannot be
submitted until a job with the same condition specified as an
out condition was executed and set the condition.
Prerequisite conditions can also be used to indicate that a
required manual operation has been performed.
Quantitative resources Quantity of a resource in the system. Different jobs may require
different quantities of specific resources (e.g., a job may require
two tape drives).
Specification of Quantitative resource requirements for a job
provides a solution for the allocation of quantitative computer
resources (e.g., cartridge drives, CPU utilization, database
access rate). Specification of Quantitative resource requirements
increases computer throughput by controlling access to these
resources, thus preventing execution bottlenecks.
Control resources Usage (Shared/Exclusive) of a specific resource. Some jobs may
require a resource to be in a specific mode (e.g., a backup job
may require exclusive access to a specific dataset).
Specification of Control resource requirements for a job/mission
provides a solution for the problem of resource sharing between
different jobs. The Exclusive or Shared mode in which a Control
resource is required by a job is also specified.
IOA considers the mode of resource usage required when
allocating Control resources and prevents jobs whose resource
usage is incompatible from executing simultaneously.
See Section 2 in the appropriate user manual for more information regarding the use of the
IOA Conditions/Resources file.
Manual Conditions File
This file contains prerequisite conditions that must be added manually (e.g., they are
required by jobs in the active environment but are not automatically added by other jobs in
the active environment). Typical manual conditions are based on events such as tape has
arrived or input has been verified.
Calendar Tables
Calendars determine on which days automated process definitions (jobs/rules/missions)
should be processed. Calendars can be used to simplify the definition of scheduling criteria.
IOA calendars are organized on a yearly basis. Each calendar lists all the days in a
specified year with an indication that an automated definition should or should not be
processed that day.
Each calendar is assigned a unique name. The calendar name can be specified via Basic
Scheduling parameters of an automated processing definition.
Calendars can be defined as either regular or periodic:
Regular calendars contain schedules that can be easily defined using Basic Scheduling
parameters. These calendars consist of scheduling dates or days (of the week) which
can be fixed according to monthly patterns.
Regular calendars are especially useful when a large number of jobs have the same
schedule. Defining the schedule once in a calendar and specifying the calendar name in
the automated processing definitions with that schedule makes it unnecessary to
individually define that schedule in each definition.
Periodic calendars are especially useful when basic scheduling criteria do not conform
to fixed date/day of the week/month breakdowns. For example, you may need to
schedule a particular job every ten days regardless of date.
The IOA Calendar facility is described in Section 2 of each product-specific user manual.
Product Repositories
Each IOA product uses a variety of different files to accumulate information about its
operations. These files are referred to collectively as product repositories (regardless of
their access method). Some of the files in each IOA products repository as described below.
More information about each products repository can be found in Section 1 of each
product-specific user manual.
Note In addition to the following list, libraries and tables which contain automated process
definitions for each IOA product are also part of each IOA product repository.
CONTROL-M
Active Jobs file The CONTROL-M active environment contains copies of the
ordered job scheduling definitions and the status of those jobs.
Accessible via option 3 in the IOA Primary Option menu.
Job Statistics file Job execution statistics (e.g., elapsed time for each job). Updated
via utility CTMJSA. Accessible via option S in the Status screen
(which is accessed via option 3 in the IOA Primary Option menu).
Job Network file Dependency information about jobs in the Active Jobs file.
Accessible via option N in the Status screen (which is accessed
via option 3 in the IOA Primary Option menu).
CONTROL-D/V
Active Missions file The CONTROL-D/V active environment contains copies of
pending, executing and recently executed missions, and mission
status. Accessible via option A in the IOA Primary Option menu.
Managed by the IOA Access Method.
User Report List files Information about reports sent to a specific user. Reports can be
selected for Online Viewing, deleted, and transferred to other
users. Accessible via option U in the IOA Primary Option menu.
Managed by the IOA Access Method.
Types of User Report List files:
Permanent A list of all reports defined to CONTROL-D.
Active Recently (and/or soon to be) processed reports.
Migrated Reports migrated from DASD to various storage
devices (CONTROL-V only).
History Reports backed up on tape or cartridge.
Active Transfer file Information about packets that are scheduled for transfer to a
PC. Only relevant for sites with CONTROL-D/PC. Accessible via
option F in the IOA Primary Option menu.
CONTROL-O
Message Statistics file List of all messages and commands detected in the system, and
various information about messages (e.g., frequency and
whether or not they were suppressed). Accessible via option OM
in the IOA Primary Option menu.
Automation log Automation information about all input available to CONTROL-O:
Console, IMS, and CICS messages and commands.
CONTROL-O internal messages.
CONTROL-O rule traces.
The Automation log can be accessed via option OL in the IOA
Primary Option menu.
Global Variables library List of all user-defined Global variables. The members of this
library are loaded when CONTROL-O is started These members
can be defined or updated via various operator commands.
Variable Database files Set of three files describing information in CONTROL-O
variable databases (accessible via option OV in the IOA Primary
Option menu) and in databases used by the CONTROL-O Status
Monitoring System (COSMOS). CONTROL-O variable database
files are managed via the IOA Access Method.
CONTROL-B
Active Balancing file List of all CONTROL-B missions loaded during the CONTROL-B
New Day procedure and information about rule status.
Accessible via option BB in the IOA Primary Option menu.
CONTROL-B Report file Detailed information (Balancing report) about each invoked
CONTROL-B rule. Accessed via option R in the Rule Activity
screen (option BA).
Database files Information about each CONTROL-B Database variable. The
Database tracks the generations (previous and current values) of
each variable.
CONTROL-T
Media Database Information on all datasets and volumes managed by CONTROL-T.
Trace file Record of activities in the CONTROL-T environment. Used
primarily for recovery of the Media Database.
Stacking Database Statistical information on each dataset which is used by
CONTROL-T to estimate the amount of space required for that
dataset. Information about previous generations of the dataset is
used to calculate space requirements for storage of each dataset.
Statistical information can be extracted from repository files via various utilities and
KeyStroke Language (KSL) reports:
Utilities are described in Section 9 of this guide.
Information extraction via KSL reports and/or sample KSL reports are described in
detail in the product-specific user manuals.
IOA and Product PARM Libraries
A wide variety of IOA and IOA product features utilize PARM libraries. Members of these
PARM libraries should not contain sequential line numbers in columns 7280.
Miscellaneous
Dynamic Destination Table
The IOA Shout facility allows the user to specify messages to be sent to particular
destinations upon the occurrence of specified events. However, it may be necessary to send
a particular message to several destinations, and/or a particular physical destination may
vary depending on time of day or other factors (e.g., the TSO logon ID of the shift manager
may be different for each shift).
These situations are handled by defining groups of destinations in a Dynamic Destination table.
The Dynamic Destination table consists of a site-defined list of logical destination names. For
each logical (i.e., group) destination name, a list of physical destinations is defined.
A logical destination name can be specified for a Shout message. The message, when
shouted, is sent to each physical destination defined to the logical location. If the physical
location is logged on, it will receive the message.
Multiple Dynamic Destination tables can be defined, one of which is defined as the default.
This Dynamic Destination Table is loaded when the product-specific monitor (e.g., the
CONTROL-M monitor) is started. A different Dynamic Destination table can be loaded via
operator command. (Shout messages are directed by the product-specific monitor to the
Dynamic Destination table in memory.)
When a change is made to the Dynamic Destination Table in memory, and it is desired that
the change be implemented immediately, the table should be reloaded into each products
memory. (For information about loading and reloading Dynamic Destination tables in
memory, see Dynamic Destination Table in Section 2 of this guide.)
AutoEdit Facility
The AutoEdit facility allows symbolic representation (via AutoEdit variables) of dynamic values
(e.g., values which change from execution to execution, or from day to day). Each variable is
resolved at the appropriate time, and the resolved value is substituted for the variable. Special
AutoEdit functions and control statements enable manipulation of values specified for these
variables. The variables can be used in job/rule/mission definitions in various ways allowing
flexibility and high level logic in automation of your work environment.
In addition, AutoEdit variables and functions can be used in different ways for each IOA
product. The AutoEdit facility can be especially useful in the following:
JCL setup of jobs submitted under CONTROL-M.
Messages issued with the IOA Shout facility.
Report scripts written in the KeyStroke Language (KSL).
KeyStroke OpenAccess scripts used by CONTROL-O and CONTROL-I/2000 to interact
with VTAM applications.
See relevant user manuals for how the AutoEdit facility can be used with the products at
your site.
Note The dollar sign ($) is a reserved prefix of IOA AutoEdit variable names.
Security Implementation
IOA products can be protected just like any other data center application. IOA has built-in
interfaces to widely used security environments (e.g., RACF, CA-ACF2 and
CA-TOP SECRET). Each IOA function is associated with a security module. These security
modules are used to check user authorization for requested actions, and to permit or deny
the actions accordingly. User exits are invoked before the security modules to allow the
user to perform required user functions that are not related to security.
IOA security is described in detail in the IOA Security Guide.
User Exits
IOA user exits can influence the continued operation of an IOA product at specific points in
processing. For example, an exit can check user authorization for a specific action or
modify report banners and indexing before printing.
Exits are described in Section 10 of this guide. Detailed information about each exit is
provided in the IOA SECUDATA library.
Utilities
Utilities are specialized programs designed to perform specific tasks in the IOA product
environment. Some utilities are used with all IOA products and some are product specific.
A list of IOA product utilities is provided in the beginning of Section 9 of this guide. Unless
otherwise indicated, these utilities are described in detail in of Section 9. Some utilities are
described in the user manual for the relevant product. Online utilities are described in
Section 2 of the relevant User Manual.
Simulation
Prior to running a complex task for the first time, or during a conversion from another
product, it is often useful to be able to first perform the task (or conversion) in simulation
mode. For this reason, certain IOA products and utilities can be run in simulation (TEST)
mode.
In simulation mode, the IOA product or utility does not affect your system. but does
generate information which is useful for checking performance.
Cross-Product Communication
Certain IOA products can perform actions in response to information received from another
IOA product.
Some ways in which IOA products can interact are described below:
File Access
IOA Core files are accessed by more than one product. A change made in one of these files
by one product can then be read by another IOA product. See the description of the IOA
Core earlier in this section for more information on files shared by IOA products.
Example
A prerequisite condition set by CONTROL-O is detected by CONTROL-M during its next
scan of the IOA Conditions/Resources file. As a result of the detected condition,
CONTROL-M can then run a job whose execution is dependent on this condition (i.e., the
condition is specified in the jobs IN parameter).
Automated Processing Definition Statements
Some statements in automated processing definitions (e.g., job scheduling definitions) can
be used by one IOA product to directly influence the operation of another IOA product.
Examples
The DO FORCEJOB statement can be used by other IOA products to instruct
CONTROL-M to force (unconditionally schedule) a specified job.
Parameter CTB STEP specified in a job scheduling definition can trigger a CONTROL-B
rule.
Special Cross-Product Interfaces
Some IOA products have special interfaces to other IOA products installed at the same
site. Interfaces for specific combinations of IOA products are discussed in the relevant
product-specific sections of this guide.
Example
CONTROL-R has a special driver exit which it uses to interface with CONTROL-T.
Inter-System Communications Facility
The CONTROL-M Inter-System Communications facility enables communication between
multiple IOA monitors in different computers, providing there is a shared disk between
them. This facility can also be used to enable communication between different releases of
IOA products on the same CPU or LPAR (logical partition).
Note This facility is supported for reasons of upward compatibility. Other methods of
system-to-system communication are recommended for most purposes. In the IOA
Installation Guide, see Activating More Than One Monitor in Section 3 and
Activating More Than One Monitor (Test/Production) in Section 5.
The CONTROL-M Inter-System Communications facility can be used in multi-CPU sites
which run in the following environment:
CPUs which do not employ a shared Spool (i.e., each CPU runs its own CONTROL-M
monitor).
CPUs which employ a shared DASD but have a global ENQ manager (such as GRS,
SDSI, MSX or MIM).
Method of Operation
When a prerequisite condition is added to or deleted from the IOA Conditions/Resources
file, a request to add/delete that condition is also written to an Inter-System
communications file (a sequential file residing on a shared disk).
The CONTROL-M Inter-System communications monitor (residing in the other CPU) reads
the conditions from the Communications file and updates the IOA Conditions/Resources file
of the other computer. After the IOA Conditions/Resources file is updated, the Inter-System
communications file is emptied and is ready to receive new conditions.
An Inter-System Communications monitor should reside in every CPU which is to be
connected. A communications file must be created for each communication direction.
In the example below, conditions from CPUA are written to CPUB via communications file
CTM.V514.COM2CPUB. Communication is also available in the reverse direction via
communications file CTM.V514.COM2CPUA.
To write requests to the communications file, additional program code must be applied to
user exit IOAX007. A routine invoked by exit IOAX007 receives control when adding or
deleting a condition and writes the condition name to a sequential file residing on a shared
DASD. Not all conditions need to be communicated between computers. Therefore, the
routine uses a condition selection list which is created by the user (described below). Only
conditions which fit the selection list are passed to the communications file.
Create Inter-System Communication Files
Edit member ISCALLOC in the IOA INSTCTM library. Correct the job card, dataset
names, etc., submit the job and save the member. The job allocates two sequential datasets
(one for each CPU).
Note The files should be allocated on shared DASD accessible for update from both CPUs.
Prepare the Condition Selection List
Create a member named ISCPARM in the CONTROL-M PARM library. The member
should contain a list of prerequisite conditions which should be communicated (passed)
between the computers. The condition name can contain the following special characters:
* can be used to substitute a string of any length.
? can be used to substitute for any one character.
Example
COND=PAYROLL
COND=J*ENDED
The following is passed:
Condition PAYROLL
All conditions whose names start with J and end with ENDED
Modify JCL Procedures and CLISTs
Allocate the DDNAMEs listed below in both computers according to the following rules:
For all procedures/CLISTs running in CPUA:
//DAISCOUT DD DISP=SHR,DSN=prefix.version.COM2CPUB
//DAISCPRM DD DISP=SHR,DSN=prefix.version.PARM(ISCPARM)
For all procedures/CLISTs running in CPUB:
//DAISCOUT DD DISP=SHR,DSN=prefix.version.COM2CPUA
//DAISCPRM DD DISP=SHR,DSN=prefix.version.PARM(ISCPARM)
Add two new DDNAMEs (described above) to the following JCL procedures:
CONTROLM The CONTROL-M monitor
IOAOMON1 The Online monitor(s)
IOACND The IOACND Utility
IOARKSLx For all KeyStroke Language procedures
Logon Procedures For TSO and ISPF users
Add two new DDNAMEs (described above) to the following CLISTs:
IOACND CTMCND Utility under TSO
IOACCND CTMCND Utility under TSO/ISPF
IOAONL Main IOA Online facility
Copy JCL to Procedures Library
Edit members CTMISCA and CTMISCB in the IOA PROCLIB library, adapt them to your data
center naming conventions, copy them to your procedures library, and save the members.
CTMISCA should be copied to CPUA. CTMISCB should be copied to CPUB.
The PARM value in members CTMISCA and CTMISCB specifies the interval (in seconds)
after which the Inter-System Communications monitor should wake up to receive
prerequisite conditions from the second CPU.
Verify that procedure CTMISCA (running in CPUA) has the communications file (for
conditions coming from CPUB) defined to DDNAME=DAISCIN1.
//DAISCIN1 DD DISP=SHR,DSN=prefix.version.COM2CPUA
Verify that procedure CTMISCB (running in CPUB) has the communications file (for
conditions coming from CPUA) defined to DDNAME=DAISCIN1.
//DAISCIN1 DD DISP=SHR,DSN=prefix.version.COM2CPUB
The access to the communications files from both CPUs is serialized by the ENQ
mechanism with SCOPE=SYSTEMS.
The QNAME is CTM.
The RNAME is the file name allocated to DAISCINn or DAISCOUT.
Verify that the above names are included in the list of QNAMES/RNAMES managed by
your global resource serialization product (GRS, SDSI, MSX, MIM, etc.).
Customize the Exits
Member IOAX007I in the IOA SECUDATA library is a sample of user exit IOAX007. This
exit invokes routine CTMISR to write the conditions to the communications file. If you do not
use exit IOAX007 at your site (i.e., the default dummy exit is used), you can use the provided
IOAX007 sample as is. If you already use exit IOAX007, you can use the sample exit as an
example of how to include a call to CTMISR in exit IOAX007.
Modify user exit IOAX007 or use the provided sample. Assemble and link-edit the exit.
If different IOA Load libraries are used in each computer, the assemble and link-edit
should also be performed in the second CPU.
Start the Communication Monitors
Start the CTMISCA communication monitor in CPUA and the CTMISCB communication
monitor in CPUB. Check that they are up and running and that there are no error messages.
Shut down and start the CONTROL-M monitor, the IOA Online monitor, and TSO
sessions.
Enter option 4 of the IOA Online facility. Add a condition which should be communicated
between the computers. Verify that it was added in the other computers IOA
Conditions/Resources file.
This page is intentionally left blank.
Introduction..................................................................................................................................2-1
IOA Online Environment ...........................................................................................................2-1
Entering the IOA Online Facility..............................................................................................2-2
IOA Online Monitor....................................................................................................................2-3
Principles of Operation..........................................................................................................2-3
Activating the IOA Online Monitor (IOAOMON) ...............................................................2-4
Displaying a List of All Active Users ...................................................................................2-5
Deactivating the IOA Online Monitor..................................................................................2-6
Problem Determination.........................................................................................................2-6
VTAM Monitor (IOAVMON)......................................................................................................2-7
Activating the VTAM Monitor (IOAVMON) ........................................................................2-7
Deactivating the VTAM Monitor ..........................................................................................2-7
Displaying a List of All Active Users ...................................................................................2-7
Canceling an IOA Online Monitor User...............................................................................2-7
Customizing the IOA Online Environment............................................................................2-8
Transaction Members.................................................................................................................2-8
Program List Members...............................................................................................................2-9
Allocation Members..................................................................................................................2-10
Modifying IOA Online Facility Commands.............................................................................2-13
Modifying IOA Online Facility PFKey Definitions.................................................................2-13
IOA Primary Option Menu ......................................................................................................2-14
Line Format Display ...........................................................................................................2-14
Box Format Display.............................................................................................................2-14
Customizing the Menu........................................................................................................2-15
Customizing IOA Screens ........................................................................................................2-17
Modifying IOA Screens and Constants ..............................................................................2-17
Constant Blocks...................................................................................................................2-19
Recommended Steps for Screen Modification....................................................................2-19
Customizing IOA Display Format Members...........................................................................2-20
@STYLE...............................................................................................................................2-21
@HEADER...........................................................................................................................2-22
@LINE..................................................................................................................................2-22
@FIELD................................................................................................................................2-23
@VAL....................................................................................................................................2-24
@END...................................................................................................................................2-24
@DLM...................................................................................................................................2-24
Color, Highlight and Intensity Parameters .......................................................................2-25
Extended Color Support .......................................................................................................... 2-26
ISPF Characteristics .......................................................................................................... 2-26
IMS/DC and IDMS/DC....................................................................................................... 2-26
IRMA PC Terminal Emulator Users ................................................................................. 2-26
Customizing Extended Color Support .................................................................................... 2-26
IOA Access Method.................................................................................................................... 2-28
File Structure........................................................................................................................... 2-28
IOA Access Method Naming Conventions......................................................................... 2-29
Files Supported by the IOA Access Method ...................................................................... 2-30
File Utilities ............................................................................................................................. 2-31
File Definition Statements ...................................................................................................... 2-31
Dual Mirror Image File Support............................................................................................. 2-32
Dual Mirror Image File Parameters.................................................................................. 2-32
Recovering From a Damaged IOA Access Method File .................................................... 2-32
IOA Profiles................................................................................................................................. 2-33
Profile Members....................................................................................................................... 2-33
Profile Contents ....................................................................................................................... 2-34
Considerations for Profile Symbol Lines ........................................................................... 2-35
SHOW Window Filters ....................................................................................................... 2-35
Profile Attribute in the Screen Definition......................................................................... 2-36
Saving a Profile................................................................................................................... 2-36
Profile Variables....................................................................................................................... 2-36
Window Display Variables ................................................................................................. 2-37
Color Variables.................................................................................................................... 2-40
Work Mode Variables ......................................................................................................... 2-42
Presentation Mode Variables ............................................................................................. 2-44
Miscellaneous Variables..................................................................................................... 2-47
Other Types of Profile Variables........................................................................................ 2-48
Modifying IOA Product Defaults ........................................................................................... 2-48
Modifying IOA Messages.......................................................................................................... 2-49
Recommended Steps for Message Modification ..................................................................... 2-50
Dynamic Destination Table .................................................................................................... 2-51
Replacing the Current Dynamic Destination Table .............................................................. 2-51
Expanding the IOA Conditions/Resource File (RES) ....................................................... 2-52
Expanding the IOA LOG File (LOG) ..................................................................................... 2-52
Introduction
This section describes the customization facilities available within IOA. The following
topics are described:
IOA Online Environment
Customizing the IOA Online Environment
IOA Access Method
IOA Profiles
Modifying IOA Product Defaults
Modifying IOA Messages
Expanding the IOA Resource File (RES)
Expanding the IOA Log File (LOG)
IOA Online Environment
The Online facility can be activated under the following environments:
TSO (native) VTAM
TSO/ISPF IMS/DC
ROSCOE/ETSO IDMS/DC
CICS CA-COM-PLETE
Options for Cross-Memory interfaces to the Online monitor address space are available
under native TSO and ROSCOE/ETSO.
There are slight differences in the operation of the Online facility under different
environments.
The following paragraphs describe how the IOA Online monitor facility provides support
for various environments using CICS as a model scenario. The description also applies to
the following environments:
IMS/DC
VTAM
CA-COM-PLETE
IDMS/DC
ROSCOE Cross-Memory Interface
TSO Cross-Memory Interface
Entering the IOA Online Facility
In TSO and ISPF, the IOA Online facility is entered by running a CLIST (located in the
IOA CLIST library). The CLIST calls IOAONL, which is the main CLIST that activates the
Online facility in the specified environment.
The following CLISTs are provided for activating the IOA Online facility in the indicated
environment:
IOATSO TSO environment.
IOAISPF ISPF environment.
IOAXTSO TSO through Cross-Memory services.
The CLIST format used to activate the IOA Online environment under ISPF or TSO is:
IOAONL APPLTYPE(atype) [TRANID(transmem)]
where:
atype Type of environment under which IOA is run. Valid values:
I ISPF
S TSO
X Online monitor
transmem Name of the relevant transaction member in the IOA PARM library.
Maximum length: four characters. Optional.
If no transaction member is specified, a full list of all options for the
installed products is displayed.
For more information see Transaction Members later in this section.
Example
At a site where CONTROL-M and CONTROL-D are installed, the following CLIST enables
all options for CONTROL-M and CONTROL-D under TSO:
%IOAONL APPLTYPE(S)
Note Dataset allocation for the IOA Online environment can be customized via specification of
overriding or alternative allocation members in the CLIST used to activate the IOA
Online environment. For more information, see Allocation Members later in this section.
It is possible to pass a transaction ID directly as a positional parameter to either the
IOATSO or IOAISPF CLISTs. For example:
IOATSO DMAN
will activate the IOA environment under TSO, setting up only the IOA and CONTROL-D
options regardless of other products installed at the site (where transaction member
DMAN contains the appropriate statements).
Example
The following CLIST and transaction member combination enables only option U of
CONTROL-D under ISPF (where transaction member DOLV contains the appropriate
statements).
In the CLIST library:
%IOAONL APPLTYPE(I) TRANID(DOLV)
See Transaction Members later in this section for more information.
IOA Online Monitor
The IOA Online monitor interacts with different environments (e.g., CICS) to provide an
online interface for the various IOA applications. The IOA Online monitor generates the
IOA product screens which are available to users signed on to the monitor and handles all
IOA online functions.
Each IOA Online monitor usually operates 24 hours a day as a started task. The IOA
Online monitor is usually activated automatically as part of the IPL process.
Principles of Operation
To enable the same user interface to be activated by users under different environments, a
virtual environment is built for each user. This virtual environment handles all actions a
user requests to perform in the IOA environment. Therefore, any environment being used
at a site can be supported by adding a customized routine to convert the virtual
environment to the sites environment.
A special started task, named the IOA Online monitor (IOAOMON), provides an
environment for executing IOA applications. One or more IOA Online monitors can be
started and each monitor can support several virtual environments (signed-on users).
Each monitor can customize IOA product screens, constants, messages, colors, commands
and PFKey definitions to adapt them to the sites requirements. It is recommended that the
same prefix be used for each group of monitors which are customized for specific functions.
See the description of parameter IOAXPARM in the IOA Installation Guide for more
information.
In addition to site-wide Global profile customization, each IOA product can be customized
to respond differently to individual users signed on to the IOA Online monitor through
variables specified in User profiles.
In the CICS environment, a small conversational transaction communicates with the IOA
Online monitor using cross-memory services. The CICS transaction receives a screen from
the user terminal and passes the screen to the IOA Online monitor for processing. The IOA
Online monitor returns a screen (to be displayed) to the CICS transaction which in turn
sends this screen to the CICS user at the terminal. Using this method, the IOA application
is performed outside CICS and the normal CICS function is uninterrupted. The memory
requirement of each user in the CICS region is approximately the size of the screen (i.e.,
2x24x80=3840 bytes).
The IOA Online monitor activates each user as a subtask. Therefore, in the event of an error or
abend of a user application, other users working under the IOA Online monitor are not affected.
IOA applications work above and below the 16MB line. Therefore, region size limits may
restrict the number of users who can work concurrently under the same Online monitor.
However, it is possible to open any number of additional IOA Online monitors. When a
user enters the IOA CICS transaction code, the IOA CICS application searches for a free
space in one of the currently active IOA Online monitors. The process of choosing a monitor
is transparent to the CICS user. Using this method, there is no limitation on the number of
users signing on to IOA.
It is possible to balance the workload of two or more IOA Online monitors. See parameter
BALANCE in the Install IOA Online Monitor step of the IOA installation procedure.
The actual number of users under one monitor varies according to their memory
requirements (influenced by how many screens they use concurrently, what type of IOA
options they are using, etc.). Many options exist in the IOA Primary Option menu.
However, there is no reason for every user to access all options of each product. It may be
desirable to limit access to certain options to only a selected group of users. This is done by
passing a transaction code to the Online monitor. See Transaction Members later in this
section for more information. It is also possible to determine that certain monitors allow
users to sign on only with specific transactions thus enabling monitors to be specialized for
different groups and numbers of users.
Note The CONTROL-D Online Viewing facility runs mostly above the 16MB line.
Therefore, it is possible to activate about 70 Online Viewing users under one monitor.
However, these users should be limited to Online Viewing transactions only. This can
be done by forcing users to sign on with the transaction ID DOLV.
A data center can run more than one CICS in the same computer. From the IOA point of
view, this is transparent to the user. The IOA Online monitor always returns the screen to
the CICS which issued the request. It is possible to define additional transaction IDs for
local use (e.g., a transaction ID offering all options of the menu except for the IOA
Conditions/Resources screen). See Customizing the IOA Online Environment later in this
section for more information.
Activating the IOA Online Monitor (IOAOMON)
Each IOA Online monitor usually operates 24 hours a day as a started task. Usually the
IOA Online monitor is automatically activated as part of the IPL process by the following
operator command.
S monitor_name
The names of the online monitors available in a site are defined in member IOAXPARM in
the IOA PARM library (described later in this section).
If the IOA Online monitor is successfully activated, the following message is displayed on
the operator console:
CTM777I monitor-name ONLINE MONITOR INITIALIZATION STARTED
After a few seconds the following message is displayed:
CTM778I monitor-name ONLINE MONITOR INITIALIZATION COMPLETED
If you try to activate more than one monitor with the same monitor ID in the same
computer, the newly-activated monitor immediately shuts down and a relevant message is
issued.
Notes The IOA Online monitor uses cross-memory services to communicate with other
address spaces requesting services. Like other address spaces using cross-memory
services, whenever the IOA Online monitor is shut down, the address space entry in the
MVS Address Space Vector Table (ASVT) remains non-reusable until the next IPL, and
the message IEF352I is issued (in some MVS releases). If the IOA Online monitor is
brought up and down many times, the ASVT may become full. New address spaces will
not start, and an immediate IPL may be required.
To prevent this problem, specify a large enough value in MVS initialization parameters
MAXUSER, RSVSTRT and RSVNONR in member IEASYSXX in the SYS1.PARMLIB
library.
Information about these parameters can be found in the MVS Initialization and
Tuning Reference manual.
Displaying a List of All Active Users
Specify the following operator command:
F monitor_name,DISPLAY
The following list appears on the operator console from which the modify command was issued:
CTM645I MONITOR USER PGM TRANID TERMINAL START LASTUSED ST
CTM646I monitor user pgm tranid terminal start last status
Message CTM646I contains the following data for each user in the IOA Online monitor:
MONITOR Name of the IOA Online monitor
USER User ID
PGM Name of the program which is active
TRANID Transaction ID (see the IOA Installation Guide for an explanation)
TERMINAL Terminal ID under the IOA Online monitor
START Start time (hour and minute the user entered the Online facility)
LASTUSED The last time the user performed an action with the Online facility
(hour.minute.second)
ST Status:
W Waiting for input (from the terminal)
A Active working
Deactivating the IOA Online Monitor
To deactivate the IOA Online monitor, use operator command:
P monitor_name
Problem Determination
If users cannot access the IOA Online Monitor, error message CTM011E is displayed by
program CTMCINT. The reason may be that no IOA Online monitor is active, or IOA
cannot access an active monitor due to one of the following reasons:
The name of the Online monitor is not found in the list of active Online monitors. This
may occur if:
Exit 9 is not passing a correct name. Exit 9 can determine the name of the Online
monitor to be accessed. It is possible that the exit was not customized as required,
or the wrong version of exit 9 is being used, or a faulty version of member
IOAPARM and/or IOAXPARM exists in the IOA LOAD library.
There is no active IOA Online monitor. There may be other monitors active, but
they are not the correct ones.
Whenever the user attempts to connect under TSO Cross-Memory, both the IOA
Online monitor and the TSO user must be running on the same CPU. TSO
Cross-Memory services cannot recognize an active Online monitor running on a
different CPU.
The subsystem does not match the subsystem name specified in member IOAXPARM.
This may occur if a different subsystem is active, or a wrong version of member
IOAXPARM is being used.
A problem is identified in the subsystem chains. The address of the IOA Online monitor
chain cannot be found. This may occur if:
Modules from different IOA releases were activated together (e.g., the wrong library
is concatenated or the library contains faulty programs).
When signing on from TSO Cross-Memory, the IOA Online monitor is not running
on the same CPU as the one from which an attempt was made to sign on.
VTAM Monitor (IOAVMON)
The VTAM monitor (IOAVMON) enables access to the IOA Online monitor for VTAM users
without passing though any TP monitors (e.g., CICS, IMS/DC). Only one VTAM monitor
can be activated at a time.
Activating the VTAM Monitor (IOAVMON)
The VTAM monitor usually operates 24 hours a day as a started task. The monitor is
usually automatically activated as part of the IPL process by operator command:
S IOAVMON
The VTAM application should be active before starting the VTAM monitor. To activate the
VTAM application manually, use VTAM command:
V NET,ACT,ID=ioaappl
where ioaappl is the VTAM major node containing the IOAVMON acbname.
If the VTAM monitor is successfully activated, the following message appears on the
operator console:
CTM7A0I monitor-name VTAM MONITOR INITIALIZATION STARTED
After a few seconds, the following messages are displayed:
CTM7A1I monitor-name VTAM MONITOR INITIALIZATION COMPLETED
CTM7ACI monitor-name ACCEPTING LOGONS TO acbname
Deactivating the VTAM Monitor
To deactivate the VTAM monitor, use operator command:
P IOAVMON
To display the list of users logged on to IOAVMON, enter operator command:
F IOAVMON,D
The following list appears on the console from which the operator command was issued:
CTM7B0I monitor - TERMINAL TRANSID
CTM7B1I monitor - LUname transid
Canceling an IOA Online Monitor User
To cancel an active IOAVMON user, enter operator command:
F monitor-name,CANCEL USER=transid
Customizing the IOA Online Environment
All IOA products are accessed via the IOA Online environment. This environment can be
customized to meet your sites needs. Using the methods described below, you can, for
example, modify menus and allocation tables, and control users access to the various
features of the IOA products installed at your site.
Transaction Members
Transaction members are line-oriented of a transaction member. Each line contains
customization information for one of the IOA products installed at the site.
Transaction members can be used to determine:
Which products are available to the user.
Which options of each product are available to the user.
What program member is to be used by the transaction.
The format for each line in a transaction member is:
product [optiona, optionb,...optionx] [PGM=pgmlist]
where:
product IOA product described in the line. Valid values: IOA, CTM, CTR, CTD,
CTV, CTT, CTO, CTB, and IOX.
Products do not need to be listed in any specific order. Only products
listed in the transaction member are made available to the user.
optiona, optionx Option codes of options to be displayed, or ALL. The option codes are
the one or two character codes that are entered in the command line to
indicate choice of a specific option. If ALL is specified, all options of
the product described in the line are displayed.
pgmlist Name of the Program List member used to activate the IOA product
described in this line. See Program List Members later in this
section for more information.
Notes Transaction members corresponding to transactions (application IDs) used in releases
prior to IOA Release 5.0.0 are included in the IOA PARM library for your convenience.
Certain transaction names cannot be used for user-defined transaction members.
Reserved transaction names are: IOAX, DOLV, KOA, VK, IALL and ECS.
Example
Member DOLV in the IOA PARM library specifies option U of CONTROL-D:
CTD U
Member DMAN in the IOA PARM library specifies all options of IOA and CONTROL-D:
IOA ALL
CTD ALL
A transaction member that will contain only option 3 of CONTROL-M and options 4 and 5
of IOA will look like this:
CTM 3
IOA 4,5
If a transaction member specifies only one option, once activated, the option will be
accessed directly without displaying a menu panel. If more than one option is specified, the
following options will automatically be added to the menu: 0, 1 (in some menus) and X.
Therefore, the minimum number of options that will appear in a menu member is 4 or 5.
Options 0,1 and X do not need to be specified in transaction members and should not be
specified in PGM members (described below).
Program List Members
A Program list specifies a member containing a list of programs to be activated for the
options of an IOA product. A Program List member exists for each IOA product
(including IOA).
The naming convention for Program List members is PGMxxx, where xxx is the product
suffix (e.g., PGMCTM is the Program List member for CONTROL-M).
Each product has its own program list member which contains all the options of the
product. Unless specified otherwise in a transaction member, the product s program list
member is used to specify which options of the product are available for users. The PGM
list member is used only if the product is installed as specified in member IOAPARM in the
IOA PARM library.
Program List members are line-oriented. Each line describes a program in the relevant
product.
The format for each line in a Program List member is:
program DELETE envir [=]optioncode
where:
program Program described in the line. If the program has been modified, the
name of the new (modified) program should be specified here.
envir One-character designation of the environment(s) in which the program
option is to be available. Valid values:
I ISPF
R KSL
S TSO
X Online monitor
* All environments
blank No environments
= If specified, the equal sign indicates that this option will be accessible
from all screens in the IOA environment using the transfer command
(e.g., =5 transfers the user to the IOA Log screen). If no equal sign is
specified, the option is only available from the IOA Primary Option menu.
optioncode A one or two-character option code used to activate the specified
program. To specify a different option code for a program, specify the
new option code here. More than one option code can be specified for
each program. No two programs can have the same option code.
Notes Changing the option code listed in the Program List member affects only the operation
of the program. To ensure that the display shows the new option code, it is necessary to
update member MENU in the MSG library (described later in this section).
Option codes for options 0, 1, and X are reserved and cannot be changed.
The following default Program List members are located in the IOA PARM library:
PGMCTB PGMCTD
PGMCTM PGMCTT
PGMCTO PGMCTR
PGMCTV PGMIOA
Sample Program List member for CONTROL-O (member PGMCTO):
CTOTOMP DELETE * =OR
CTOTMSC DELETE * =OM
CTOTARF DELETE * =OS
CTOTAOP DELETE * =OA
CTOTALO DELETE * =OL
An alternate Program List member can be used to specify a modified version of a specific
program (or programs) to be activated for a specific option(s).
Alternate program lists must contain programs for all available options of the relevant
product available to the user.
Allocation Members
Allocation of files and datasets for each IOA product are specified in Allocation members.
The naming convention for Allocation members is ALCxxx, where xxx is the product suffix.
Each product has its own Allocation List member which contains all the allocations that
need to be made to access the product using the Online facility. The datasets which are
specified in a product allocation member list ware only allocated if the product is installed
as specified in member IOAPARM in the IOA PARM library.
The following allocation members are located in the IOA PARM library:
ALCIOA ALCCTM
ALCCTD ALCCTB
ALCCTT ALCCTO
ALCCTR ALCCTV
The format for each line is an Allocation member is as follows:
product(s) DD=ddname,DSN=dsname,M=member_name,DISP=disposition
where:
product(s) One letter product code specified for each product in columns 1-9. If a
blank is specified, the format applies to all products.
ddname Should appear between columns 10-80. Mandatory.
dsname Should appear between columns 10-80. Mandatory.
member_name Should appear between columns 10-80. Optional.
Note If you do not use member_name, do not specify M= in an
Allocation member.
disposition Should appear between columns 10-80. The default is SHR. Optional.
Note If you do not use disposition, do not specify DISP= in an
Allocation member.
* In column 1, represents a comment line.
Example
CTMHELP should be allocated if any IOA product is installed:
DD=CTMHELP,DSN=IOA.V500.MSG
To customize allocation at your site, specify one of the following DD statements in the CLIST
(or the Online monitor procedure or the KSL) used to activate the IOA Online facility:
DAOVRALC Specifies a member containing allocations that override corresponding
allocations in the Allocation member list for the relevant product.
The datasets specified in the appropriate products in the allocation
member are all allocated. However, any allocations for datasets
specified in the overriding member are also allocated and they will
override the corresponding allocations.
CLIST with an overriding Allocation member:
PROC 0 APPLTYPE(S) -
TRANID(TRANSACTION_ID_MEMBER)
ALLOC DD(DAOVRALC) -
DSN(IOA.V500.PARM(ALCOVR)) SHR REU
%IOAONL APPLTYPE(&APPLTYPE) TRANID(&TRANID)
FREE DD(DAOVRALC)
END:END
DAALTALC Specifies a member containing allocations to replace the allocations in
the Allocation members for all products at the site.
The alternate list must contain all necessary allocations to the
environment because none of the default Allocation members are used.
CLIST with an alternate Allocation member:
PROC 0 APPLTYPE(S) -
TRANID(TRANSACTION_ID_MEMBER)
ALLOC DD(DAALTALC) -
DSN(IOA.V500.PARM(ALCALT)) SHR REU
%IOAONL APPLTYPE(&APPLTYPE) TRANID(&TRANID)
FREE DD(DAALTALC)
END:END
If neither an overriding Allocation member nor an alternate Allocation member is
specified, the default Allocation members are used. Overriding and alternate Allocation
members can be stored in the IOA PARM library.
Only one overriding or alternate Allocation member can be specified in a procedure (e.g., a
CLIST). However, multiple overriding and alternate Allocation members can be created at
a site for use with different CLISTs and Online monitor procedures.
Sample ALC Member (ALCCTO)
DD=DAPASCTO,DSN=%ILPREFA%.PARM,M=PASCTO
DD=DALOAD,DSN=%STEPLIB%%LANG%
Note If a concatenated allocation is required, delete the original allocation from the
appropriate ALCxxx member and add it to the users procedure, CLIST, JCL, etc.
Modifying IOA Online Facility Commands
Every screen of the IOA Online facility supports a set of commands. It is possible to change
the names of these commands or to create synonyms. The commands reside in the IOA
PARM library in members with the following naming conventions:
TxxxCMD1 Active commands member.
where xxx is the screen identifier. Appendix E contains a list of all options, screens and
their corresponding command members.
A command member is composed of one header line and any number of command lines. The
number at the left of the header line is the total number of command lines in the member.
It must be updated when lines are added to or deleted from the command member.
The structure of the command line is:
Columns Description
1-8 Command name.
25-28 Reserved hexadecimal (unprintable) value. Do not modify.
29-68 Description of the command.
69-72 Reserved hexadecimal (unprintable) value representing the internal
command number. Do not modify.
It is possible to change the command name and/or the description by typing in the change.
To add a synonym (a command that is to have the same effect as an existing command),
duplicate the command line, modify the command name on the duplicated line, and add
one to the command line counter at the left side of the header line. To delete a command,
delete the command line in the member and decrease the counter by one.
Modifying IOA Online Facility PFKey Definitions
Every screen of the IOA Online facility is associated with a set of PFKeys with
pre-assigned commands. It is possible to change these PFKey definitions. The PFKey
assignments reside in the IOA PARM library in members with the following naming
convention:
TxxxPF1 Active PFKey definition member.
where xxx is the screen identifier. Appendix E contains a detailed list of all screens and
their corresponding PFKey members.
A PFKey member is composed of one header line and any number of PFKey definition
lines.
The structure of the PFKey definition line is:
Columns Description
1-8 The PFKey or <ENTER>.
9-22 The command assigned to the PFKey.
At least one PFKey/Enter key must be defined as the <ENTER> command.
IOA Primary Option Menu
The IOA Primary Option menu displays IOA product options and facilities available to the
user. Customizing the menu is usually not required since the menu is dynamically
generated according to the options available to the user.
The IOA Primary Option menu is displayed in one of the following formats:
When less than a threshold number of options is available, options are displayed in Line
format. Options are listed one per line on the screen. An option code, the name of the
option, and a brief description is listed for each option Information about the IOA
products installed at the site is displayed in the upper right corner of the screen.
When more than the threshold number of options is available, options are grouped
according to product in Box format. In Box format only option codes and option names
are displayed. This format enables displaying all IOA products and their options on one
screen. Information about IOA products installed at the site is available via option 0.
Reducing or increasing the number of available options may change the format in which
the Primary Option menu is displayed.
Line Format Display
--------------------- IOA PRIMARY OPTION MENU ------------------(1)
OPTION ===> USER M21
DATE 12.12.98
0 IOA INFO IOA Version Information M Version 5.1.4-9901
1 MAIN MENU IOA Primary Option Menu
2 JOB SCHEDULE DEF CTM Job Scheduling Definition
3 JOB STATUS CTM Job Status Display
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
C CMEM DEFINITION CTM Event Manager Rule Definition
IP IOA/PATHFINDER IOA/Pathfinder Cross Reference
X EXIT Terminate Session
PLEASE SELECT OPTION AND PRESS ENTER OR PRESS THE OPTIONS PFK 17.17.59
Box Format Display
--------------------- IOA PRIMARY OPTION MENU ------------------(1)
OPTION ===> USER N44
IOA CONTROL-D/V CONTROL-O
0 IOA INFO A MISSION STATUS OR RULE DEFINITION
4 COND/RES M MISSION DEF OM MSG STATISTICS
5 LOG R REPORT DEF OS RULE STATUS
6 TSO T RECIPIENT TREE OL AUTOMATION LOG
7 MANUAL COND U USER REPORTS OA AUTOMATION OPTS
8 CALENDAR DEF F PC PACKET STATUS OV VARIABLE DATABASE
IP IOA/PATHFINDER OC COSMOS STATUS
X EXIT OK KOA RECORDER
CONTROL-M/R/L CONTROL-B/I-2000 CONTROL-T
2 JOB SCHEDULE DEF BB BALANCING STATUS TR RULE DEFINITION
3 JOB STATUS BM MISSION DEF TP POOL DEFINITION
C CMEM DEFINITION BV DB VARIABLE DEF TV VAULT DEFINITION
LR CTM WORKLOAD DEF BR RULE DEFINITION TI INQ/UPD MEDIA DB
LA JOB/PIPE ACTIVITY BA RULE ACTIVITY TC CHECK IN EXT VOL
LS RULE STATUS BK KOA RECORDER
PLEASE SELECT OPTION AND PRESS ENTER OR PRESS THE OPTIONS PFK 07.58.38
The menu is displayed according to the order of appearance of each product in the menu
table (described later in this section). The IOA menu is always displayed on the left side of
the screen (displayed only in Box format). However, changes to other menus affect the
arrangement of the options of other products in the menu.
Customizing the Menu
Options for the IOA Primary Option menu are listed in member MENU in the IOA MSG
library. This member can be used to modify the information that appears in the menu
display. The lines in this member look like this:
* Comment
T* IOA
T*X IOA
TM CONTROL-M
TMR CONTROL-M/R
TMRL CONTROL-M/R/L
TML CONTROL-M/L
TD CONTROL-D
TDV CONTROL-D/V
TO CONTROL-O
TB CONTROL-B
TB2 CONTROL-B/I-2000
TT CONTROL-T
L* * 0IOA INFO IOA Version Information
L* * 1MAIN MENU IOA Primary Option Menu
where:
T Lines which begin with the letter T indicate titles which appear at the
top of each box in the Box Display Type for the IOA Primary Option
menu. Following the letter T is the one letter code(s) of the product(s)
whose options are to be displayed in the box with this title.
Example
The line shown below indicates the title to be displayed at the top of
the box containing CONTROL-M options.
TM CONTROL-M
L Lines beginning with the letter L indicate menu options. The format
for an option line in the menu member is as follows:
Lproduct environment optcode optname opt-description
where:
product IOA product that must be installed for this option to
be displayed in the menu. For example, M indicates
that the option is displayed when CONTROL-M is
installed at the site. I is for IOA.
environment Environment that IOA must operate under for this
option to be displayed. Valid environment
specifications are:
T TSO
I ISPF
0 no environment
* all environments
optcode Option code used to activate (choose) the option. The
option code can be one or two characters in length
and must be the same as the option code for this
option in the Program List member in use at your
site.
optname Option name. Displayed to the right of to the option
code in Box format, and between the option code and
the description in Line format.
opt-description Option description. Displayed only in Line format.
The description can be modified to aid option
identification at your site (e.g., it can be translated).
For more information, see the description in member MENU in the IOA MSG library.
Customizing IOA Screens
Customization of IOA screens can be accomplished in a number of different ways. In this
section the following topics are described:
Modifying IOA Screens and Constants.
Customizing IOA Display Format Members.
Customizing Extended Color support.
Note It is recommended to back up members before modifying them for customization of IOA
screens, and to use these backups for KSL scripts.
Modifying IOA Screens and Constants
IOA screens and constants can be adapted by the user for local language, local site
terminology, ease of use, etc.
IOA screen and constant members are stored in the IOA MSG library. The naming
convention for these members is:
CTxSyyy
where:
x Single character indicating the product (e.g., M for a CONTROL-M
screen).
yyy Three-character screen identifier.
Each member contains definitions for either a screen and its constants, or a set of
constants. Definitions are specified as Assembler macro instructions. Each member must
be assembled and link-edited to create a CSECT and module with a name identical to the
screen member name. The load module containing the screen replaces an existing CSECT
in one or more load modules in the IOA LOAD library.
A screen is defined by the following macros in the IOA library:
CTMSSTA Start screen/constants definition (one CTMSSTA macro for each
screen definition).
CTMSBLK Start a block of fields/constants.
CTMSFLD Define a field in the screen/constant.
CTMSEND End screen/constant definition (one CTMSEND macro for each screen
definition).
Each unit of data in an IOA screen is called a block. A block can contain one or more fields.
Examples
The header block is composed of two or more lines which contain the header line, the
command field, the scroll field, etc.
The following line which appears at the top of the CONTROL-M Job List screen is a
block.
====>>>>>> TOP OF ACTIVE JOBS LIST <<<<<<====
Within each block, the location of the fields can be changed. It is possible to change the
length of fields which are defined as skip protected and contain constants. Do not change
the length of unprotected data fields unless specifically permitted in the member. The
length of a field does not include the attribute byte. The total accumulated length of the
fields within a block which describes screen line(s) should remain the same after
modifications have been made. This restriction does not apply to blocks used for defining
constants.
Each block is line-oriented. The total length of each block must be the number of lines in
the block multiplied by the length of the line.
Do not change the location and contents of macros CTMSSTA, CTMSBLK, and CTMSEND.
Changes can be applied only in the contents (parameters) of macro CTMSFLD.
Macro CTMSFLD defines a field in the screen. The format is:
CTMSFLD
NAME = field name If a name has been specified, do not change it.
ATTR = code, Field attributes. Refer to macro CTMSATT in the IOA MAC library.
LTH = m, Length without attribute byte. If not specified, the length of the DATA
text will be used. The real length of the field is always one more than
that specified in the LTH field to account for the attribute byte.
DATA = text The data in the field (if any) in quotes.
PROF = Y | N Indicates whether or not the value of the field (when exiting the
Online environment) is saved in the users profile member and used at
the next invocation of the environment. Optional.
Valid values: Y, N. Default: N.
Note Not all fields can use profiled values.
COLOR=color Color of the field.
Valid Values: RED, BLUE, PINK, GREEN, TURQUOISE, YELLOW<
WHITE< TURQ and NO.
HILITE=hilite Highlight technique for the field.
Valid values: BLINK, REVERSE, USCORE, and NO.
Constant Blocks
Blocks used to define constants in SYSIN input DD statements, as part of a message, or as
statuses on screens, are different from screen field blocks. You can change the length of the
fields, disregarding the total block length rule. An example is member CTMSAES, which is
used to define parameter syntax of the CONTROL-M AutoEdit Simulation facility.
Recommended Steps for Screen Modification
Sources (screen members) of IOA products are modified via an SMP/E USERMOD. Use the
following steps to perform this task:
1. Choose a name for a new USERMOD (to be built in the following steps). The name of
the USERMOD must be 7 characters in length, must begin with an alphabetic
character (i.e., not a number or symbol), and must be unique.
2. Create a new member in the IOA MAINTLIB library with the same name as the
USERMOD created in Step 1.
3. Copy the contents of member UMODSRC in the IOA JCL library to the newly-created
member. This member contains a skeleton sample for the USERMOD (to be customized
in the following steps).
4. Specify the name of the new USERMOD in the ++USERMOD statement.
5. Determine the FMID and the RMID of the screen source via SMP/E Online option 3.2.
Specify SRC as the entry-type, and the name of the screen source as the entry-name.
Specify the FMID in the ++VER statement.
If the RMID value is not the same as the FMID value, add the RMID value to the
++VER statement via the PRE(rmid-value) parameter.
6. Specify the screen source-name in the ++SRC statement.
7. Copy the contents of the source member to the line immediately after the ++SRC
statement. Update the copy to meet your needs.
8. Specify the name of the USERMOD in job UMODRACK in the IOA JCL library. Run the
job. This job RECEIVEs and APPLY-CHECKs the USERMOD.
Job UMODRACK must end with a completion code of 0.
9. Specify the name of the USERMOD in job UMODAPP in the IOA JCL library. Run the
job. This job applies the USERMOD.
Job UMODAPP must end with a completion code of 0.
Customizing IOA Display Format Members
In certain IOA product screens, it is possible to specify the display type (or format) of the
screen. A wide selection of predefined display types is provided. For example, in the
CONTROL-D User Report list, display type S is similar to IBMs SDSF, while display type
J can be used for production control and by programmers. Refer to the appropriate User
Manual for details.
If the predefined display types are not adequate, users may define their own display types
using the Display Type Editing facility. The following pages describe parameters which
define new display types or modify existing display types.
All of the display formats are defined in members in the IOA MSG library. For a list of
these members, refer to Appendix E which contains a list of all the options of IOA and the
screen member and/or format members which are used to build the IOA panels. For
example, in CONTROL-D, the display formats of option U are defined in members $$FRM
and $$USR in the IOA MSG library. These members contain sets of predefined display
formats. The user can add new formats in these members, or modify existing ones. When a
display type is activated, it first checks for any errors, which are displayed in an
appropriate screen.
Each line in a format member is one of the line types listed below. The line type must be
written in positions 1-10 of the line.
The permitted line types are:
@STYLE
@HEADER
@LINE
@FIELD
@VAL
@END
@DLM
A line starting with an asterisk (*) is a comment line.
The parameters on the line characterize the lines attributes. Parameters can be written in
positions 11-72 of the line. A continuation line is created by leaving the line type area
blank and using positions 11-72 for parameters describing the lines attributes.
Each line type and its parameters are described on the following pages.
@STYLE
@STYLE is a line type used to start a new display format. The format for a @STYLE line is:
@STYLE ID=id; TYPE=type; CLASS=class; [IDLIKE=idlike;
TYPELIKE=typelike; CLASSLIKE=classlike;] LTH=n;
where:
ID Name of the display type. This value can be used to identify the
DISPLAY TYPE field in an opti on s entry panel (if one exists) or
when changing the Display Type by specifying the command DISPLAY
x (where x is the display type) from the command line. This field must
be one character in length only. The value can be any printable
character. A blank is not valid. The character 1 is reserved for
internal use and should not be used.
TYPE Logical type of the display type (second level qualifier). Valid values
depend on the screen in which the display type is used. For example,
display types of the CONTROL-D User Report List screen use this
field for the following file types:
P Permanent file
A Active file
H History file
* All file types
CLASS Class of record for which this display type is used. Valid values
depend on the screen in which the display type is used. For example,
display types of the CONTROL-D User Report List screen have the
following record classes:
U User records
S Sysdata records
R Ruler records
* All record classes
IDLIKE Name of the display type to which the current ID is identical.
TYPELIKE and CLASSLIKE must also be specified. The definition of
the display type specified via parameter IDLIKE must precede the
current line. When this parameter is specified the current display
format should have only a @STYLE line, and take its definition from the
specified display format. This field must be one character in length only.
TYPELIKE Type of the display type to which the current ID is identical. Valid
values are the same as in the TYPE parameter (described above).
CLASSLIKE Class of record for which this display type is used. Valid values are the
same as in the CLASS parameter (described above).
LTH Length of the line to be displayed. Valid values are 80 or 132.
Color, highlight and intensity parameters can also be modified. See Color, Highlight and
Intensity Parameters below.
@HEADER
@HEADER is a line type used to describe the header line of the current display format.
The format for a @HEADER line is:
@HEADER DATA=data;
where:
DATA Actual header data to be displayed as the header line of the screen in
which the display type is shown. The header data can be a maximum
of 80 (or 132) characters in length. If less data is specified, it is padded
with blanks to fill the physical line.
Color parameters can also be modified. Refer to Color, Highlight and Intensity
Parameters below.
@LINE
@LINE is a line type used to start a new line in the current display format. The format for
a @LINE line is:
@LINE LONG={Y|N}; SHOWBLINE={Y|N};
where:
LONG Whether or not the line should be displayed in regular screen format
(i.e., when Additional Information is not requested on the line).
Y (Yes) Display the line only when ADDITIONAL INFO is
selected on the displayed line. (ADDITIONAL INFO is
requested by entering A in the lines option field.)
N (No) Always display the line. Default.
SHOWBLINE Whether or not the line should be displayed when all fields in it are
blank.
Y (Yes) Show the line. Default.
N (No) Do not show the line.
Parameters below.
@FIELD
@FIELD is a line type used to start a new field in the current line in the current display
format. The format for a @FIELD line is:
@FIELD NAME=name; DATA=data; LTH=ln; PREF=pref; KANJI={Y|N};
OFFSET=ofst; EDIT={Y|N}; DEFAULTEDIT={Y|N}; DFLT=dflt;
where:
NAME Field to be displayed. Valid names are listed in the description of the
display types of each product.
DATA Constant data to be displayed. This is useful, for example, for displaying a
field descriptor. Either NAME or DATA must be present, but not both.
LTH Display length of the information of the field specified in the NAME
parameter, or the display length of the constant information in the
DATA parameter. If the actual information provided by NAME or
DATA is too short, it is padded with blanks on the right. If the
information is too long, it is truncated on the right.
PREF Prefix to be added to the left of the displayed data specified by NAME
or DATA.
KANJI Specifies if Kanji (Japanese writing using Chinese characters) input is
allowed.
Y (Yes) The current field allows input in Kanji format.
N (No) The current field does not allow input in Kanji format.
Default.
OFFSET Offset in the data field from which data should be taken for screen
display purposes. This mechanism allows the user to split a long data
field between several display fields (maybe on several different lines).
ofst is the offset from which to start.
EDIT Whether or not the user can change the displayed field. Valid only if
NAME is specified.
Y (Yes) The user can change the displayed field.
N (No) The field is displayed in a protected form. It cannot be
modified. Default.
DEFAULTEDIT Whether or not the user should be able to edit an insert record. Valid
only if NAME is specified.
Y (Yes) For an Insert record, the field is displayed so that the
user can enter initial information for it.
N (No) The field is displayed in a protected (cannot be
modified) form. Default.
DFLT Default value for the field in an insert line. Valid only if NAME is
specified. The data specified is displayed in the field. If DFLT is
omitted, the initial value of the field is blank.
Parameters below.
@VAL
@VAL is a line type used to set the color of the current field according to the value of the
field. More than one @VAL line type can be specified for different values of the current
field. The first match found between the fields value and the value specified in the @VAL
line determines the color of the field. The format for a @VAL line is:
@VAL DATA=data
where:
data Specifies a data string which is be compared to the current value of
the field. The data string may contain * and ? mask characters.
Color parameters must also be specified in the line. In case of a match between the fields
current value and data in the @VAL line, the colors specified in the @VAL line will
override the colors specified in the @FIELD line.
@END
The @END line type is used to end the definition of the current display format.
@DLM
The @DLM line type is used to change the currently used delimiter in this member to a
new one. The default delimiter is; This line can be inserted anywhere in the member. The
format for a @DLM line is:
@DLM=newold
where:
new New delimiter.
old Old delimiter.
In the @DLM line the new delimiter is specified as the value for the DLM keyword but it is
delimited by the old delimiter.
Example
@DLM=,; <<----- delimiter first set to ,
@DLM=&, <<----- delimiter then set to &
@DLM=;& <<----- delimiter set back to ;
Color, Highlight and Intensity Parameters
The @STYLE, @LINE, @FIELD and @HEADER line types support COLOR, HILITE and
INTENS parameters. Color takes effect on color monitors only. Highlight takes effect on
both color and monochrome monitors. Intensity takes effect on monochrome monitors only.
Valid colors:
NONE (Default)
WHITE
BLUE
GREEN
TURQ
RED
PINK
YELLOW
Valid highlights:
NONE (Default)
BLINK
USCORE
REVERSE
DARK
For of monochrome monitors, users can add the INTENS parameter to the @FIELD line
type.
Valid intensities:
LOW (Default)
HIGH
Users can create a combination of color and highlight or highlight and intensity for each
field by specifying COLOR, HILITE and INTENS parameters on the same @FIELD line.
The COLOR, HILITE, and INTENS parameters can all be specified on a line. Each takes
effect when appropriate.
If the above parameters are omitted on the @FIELD line, the field inherits those
parameters from the @LINE preceding it.
If these parameters are omitted on the @LINE line, the line inherits those parameters from
the @STYLE preceding it.
If these parameters are omitted on the @STYLE line, they are set to their default values.
@STYLE, @LINE and @FIELD also accept COLORA and HILITEA parameters that have
the same values as COLOR and HILITE, respectively. These parameters can be used to
specify a set of alternate colors when displaying records: the first record on the screen is
displayed with COLOR and HILITE; the second record is displayed with COLORA and
HILITEA; the third record with COLOR and HILITE, and so on. This causes an
alternating color effect. If COLORA and HILITEA are omitted, the alternate colors are set
to the standard color values.
Extended Color Support
The following should be considered when using the extended color feature of the IOA
Online facility:
ISPF Characteristics
Due to ISPF characteristics, adjacent fields with different colors are separated by a byte
without color (black). Therefore, some IOA screens have a different appearance under ISPF
than under other Online environments (e.g., native TSO, CICS).
IMS/DC and IDMS/DC
IOA does not automatically recognize an IMS/DC or IDMS/DC terminal as supporting
extended color attributes. If the IMS/DC or IDMS/DC terminal supports extended color
attributes, the ICOLOR=YES parameter must be added to the users profile. For details on
modifying the users profile, refer to Profile Variables later in this section.
It is important not to use parameter ICOLOR=YES for non-color terminals. Doing so will
cause an error and the terminal will be inhibited.
IRMA PC Terminal Emulator Users
Early versions of IRMA (from DCA
) have a problem interpreting the 3270 color stream.

As a result, IOA screens may appear with incorrect coloration. If you encounter this
problem, call your local IRMA representative and request a later version of IRMA that
corrects this problem.
Customizing Extended Color Support
The IOA environment uses extended color support if the terminal is capable of supporting it.
Various defaults are set so that if no changes are made, extended color is used wherever possible.
Two VTAM commands can be used to help determine whether or not a particular terminal
supports color:
RPQ
When this VTAM command is issued to a terminal, the terminal responds with an
indication whether or not it supports extended color.
Note RPQ is a physical command, that is not supported by some older control units.
LOGMODE
LOGMODE is an entry in a VTAM table which logically defines the capabilities of a
terminal. The following table indicates whether or not the capability of the terminal to
support extended color is determined by the contents of the VTAM LOGMODE entry:
Environment
RPQ
Default
Suppress
Issued By Force Issuing RPQ
No Extended
Color
Native TSO and
ROSCOE
RPQ IOA, if TCOLOR=
TERMINAL
TCOLOR=YES or NO TCOLOR=NO
TSO and
ROSCOE
(Cross-Memory)
RPQ IOA ICOLOR=NO
ISPF RPQ ISPF N/A LOGMODE
IOAVMON RPQ IOAVMON LOGMODE
IMS/DC and
IDMS
ICOLOR not issued ICOLOR=NO
CICS RPQ IOACICS ICOLOR=NO
In this table, TCOLOR and ICOLOR are IOA Profile variables. See IOA Profiles later
in this section for more information about these variables.
Note For TSO/ROSCOE Cross-Memory and CICS, the appropriate change must be applied
before the ICOLOR variable is activated.
IOA Access Method
Several IOA products include files that are processed using an internal component called
the IOA Access Method.
The IOA Access Method is used to create indexed (keyed) file structures that offer enhanced
data integrity. IOA Access Method files are physical sets of sequential datasets which are
allocated, formatted and accessed by IOA products via IOA Access Method utilities.
Most IOA Access Method files consist of two separate sequential datasets:
A data component, where the actual record information resides.
An index component, which provides keyed access to records in the data component.
Some IOA Access Method files may contain only an index or data component.
Both index and data information are stored in compressed format, resulting in reduced I/O
processing overhead and optimum disk space utilization.
The IOA Access Method provides dual mirror image file support. This mechanism enables a
quick recovery of IOA Access Method files if a disk crash occurs on a disk that contains
IOA Access Method primary files.
File Structure
IOA Access Method index component records are fixed length. IOA Access Method file data
component records can be fixed or variable length.
The first block in each IOA Access Method file extent consists of a control record. The control
record contains a bit table indicating the blocks within the extent that contain free space for
additional records.
IOA Access Method index files function as balanced tree index structures.
In addition to index (key) and data record pointer fields, IOA Access Method file index
component records can contain non-key data, enabling non-key selection criteria to be used
without accessing the associated IOA Access Method file data component. Non-key data fields
in index records can be stored in compressed format, providing maximum space utilization
benefits.
Examples
CONTROL-D User Report List files are indexed by recipient name, job name and record
creation timestamp.
CONTROL-B Group Definition files are indexed by group name.
Data and index components may extend beyond one physical dataset. Initially, however, a
component is allocated as a single physical dataset called the primary extent.
To increase an IOA Access Method file components capacity, a maximum of 255 secondary
extent datasets can be allocated and formatted. Using an IOA Access Method definition
option, secondary extent allocation and formatting can automatically be performed when
an out-of-space condition occurs.
Note Currently, secondary extents are supported only in CONTROL-D, CONTROL-V,
and CONTROL-O.
Deleting Records in IOA Access Method Files
If a record is deleted from an IOA Access Method file, the space previously required for
that record is reusable for other records. The block which contained the deleted record is
reorganized during the deletion process to consolidate all free space of the block in one
piece.
IOA Access Method Naming Conventions
IOA Access Method files which are allocated during CONTROL-D, CONTROL-V,
CONTROL-B, and CONTROL-O installation are listed below and use the following naming
convention:
prefix.dbname.Ennn
where:
prefix IOA Access Method file name prefix. The prefix is specified during
product installation by setting relevant installation variables
(e.g., DBPREFB for CONTROL-B, and DBPREFD for CONTROL-D
and CONTROL-V).
Example: CTD.PROD
Note The prefix may contain more than one qualifier.
dbname IOA Access Method file identifier name. The identifier name is
specified during product installation as part of the name assigned by
parameter DSN in the IOA Access Method files definition statements.
For example, identifier name ACT is assigned to the CONTROL-D
Active User Report list data component while ACTI is assigned to the
CONTROL-D Active User Report list index component. The identifier
name of an IOA Access Method file should never be modified.
Ennn Extent sequence number suffix generated internally by IOA Access
Method management routines whenever an IOA Access Method file
component is allocated. The suffix consists of the letter E followed by
nnn, a number from 000 to 255, indicating an IOA Access Method files
extent sequence number. A maximum of 255 additional file extents
can be associated with each IOA Access Method file.
Files Supported by the IOA Access Method
CONTROL-B Files
CTB.PROD.GRPD.E000 Group Definition file data component.
CTB.PROD.GRPI.E000 Group Definition file index component.
CTB.PROD.JAFD.E000 Rule Activity file data component.
CTB.PROD.JAFI.E000 Rule Activity file index component.
CTB.PROD.MODD.E000 Basic Parameters file data component.
CTB.PROD.MODI.E000 Basic Parameters file index component.
CTB.PROD.REPD.E000 Report file data component.
CTB.PROD.REPI.E000 Report file index component.
CTB.PROD.VARD.E000 Variables Generation file data component.
CTB.PROD.VARI.E000 Variables Generation file index component.
CTB.PROD.ABF.E000 Active Balancing file data component.
CTB.PROD.ABFBKP.E000 Backup Active Balancing file data component.
CONTROL-D Files
CTD.PROD.HST.E000 History User Report list data component.
CTD.PROD.HSTI.E000 History User Report list index component.
CTD.PROD.ACT.E000 Active User Report list data component.
CTD.PROD.ACTI.E000 Active User Report list index component.
CTD.PROD.PRM.E000 Permanent User Report list data component.
CTD.PROD.PRMI.E000 Permanent User Report list index component.
CONTROL-V Files
CTD.PROD.MIG.E000 CONTROL-V Migrated User Report list data component.
CTD.PROD.MIGI.E000 CONTROL-V Migrated User Report list index component.
CONTROL-O Files
CTO.PROD.DBSD.E000 Variable Database Definition file data component.
CTO.PROD.DBSI.E000 Variable Database Definition file index component.
CTO.PROD.COLD.E000 Variable Database Column file data component.
CTO.PROD.COLI.E000 Variable Database Column file index component.
CTO.PROD.VARD.E000 Variable Database Variables file data component.
CTO.PROD.VARI.E000 Variable Database Variables file index component.
Note Jobs or procedures using IOA Access Method files should contain a DD statement only
for the first extent of the primary file. All other extents are dynamically allocated when
the IOA Access Method file is opened.
File Utilities
A comprehensive set of utilities is provided for IOA products which use IOA Access Method
files. These utilities are used to create and maintain IOA Access Method files.
IOADBF Allocates and formats an IOA Access Method files index or data component.
IOADIG Verifies the integrity of an IOA Access Method files data component.
IOADII Verifies the integrity of an IOA Access Method files index component.
IOADPT Prints an IOA Access Method files data and index component records
in SNAP dump format.
IOADCPY Copies an IOA Access Method file from the dual mirror image file to the
primary, as well as from the primary file to the dual mirror image file.
IOADLD Loads an IOA Access Method files contents from a sequential file.
IOADUL Unloads an IOA Access Method files contents to a sequential file.
Note Products which use the IOA Access Method contain additional utilities which are
specific to the product. For more details about additional IOA Access Method utilities,
see the summary list of utilities in Section 9.
File Definition Statements
When allocating and formatting an IOA Access Method file (i.e., via utility IOADBF), a
library member containing IOA Access Method File Definition statements is read.
These statements define an IOA Access Method files physical and logical attributes, such
as dataset name, unit, volume parameters, space parameters, record key length (for IOA
Access Method file index components), and whether additional file extents are allocated
automatically or manually when the current file extent is full. The members reside in the
IOA INSTCTx library, where x is a one-letter product ID code.
Examples
The IOA Access Method File Definition statement for CONTROL-Ds History User
Report list components can be found in the DEFHST and DEFHSTI members in the
IOA INSTCTD library.
The IOA Access Method File Definition statement for CONTROL-Bs Group Definition
components are the DEFGRPD and DEFGRPI members in the IOA INSTCTB library.
The IOA Access Method files attributes are kept in the files control block. If you need to
change these parameters after the file is created, modify the Definition Statements
member and run utility IOADBF with FUNC=CHANGE.
For more information on IOA Access Method File Definition statements, refer to Utility
IOADBF in Section 9.
Dual Mirror Image File Support
Each IOA Access Method file can be created with dual mirror image file support. For each
logical extent of the file, the IOA Access Method automatically allocates a dual extent of
the same size. The name of the dual extent is identical to that of the corresponding
primary extent, except for the first character of the last qualifier which is set to D instead
of E (e.g., prefix.dbname.Dnnn).
The dual mirror image file is created if parameter DUAL in the IOA Access Method
definition member is set to Y. (See the description of utility IOADBF in Section 9 for more
information.) The definition member also specifies the unit and volume names for the dual
file allocation.
The IOA Access Method synchronizes the primary and dual files. All read operations are
performed only from the primary file, and all write operations are performed in parallel to
both files. The dual file is allocated dynamically.
Note Different volumes must be used for the primary and dual files for improved
performance and recovery capability.
It is recommended to activate dual mirror image support for only the data component
and not the index component of the IOA Access Method files.
Dual Mirror Image File Parameters
The following parameters are used to manage the dual mirror image file:
DUALM
If parameter DUALM is set to Y and an error occurs in the dual mirror image file, the
current operation fails for the primary file as well. A manual correction should be made
before any further processing is done. If parameter DUALM is set to N, processing
continues for the primary file only, without dual mirror image file support.
DUALST
An additional dual mirror image option is an internal timestamp checkpoint to ensure
that the primary and dual copies are fully synchronized. This ensures greater data
integrity but increases I/O processing overhead.
This option is activated if parameter DUALST in the IOA Access Method definition
member is set to Y during file creation. If the timestamp values are not synchronized
between the primary and dual files, the dual file should be rebuilt. See the description
of utility IOADBF in Section 9 for additional information.
Recovering From a Damaged IOA Access Method File
If the IOA Access Method is used with dual file support and one of the two copies corrupt, the
damaged file can be restored by using utility IOADCPY. This utility copies all the extents of
the working copy to the corresponding extents of the corrupted copy. See Section 9 of this
guide for more information about this utility.
IOA Profiles
A profile is a set of values to be used as default values for certain fields in IOA screens
during sessions of a specific user or group of users (e.g., the library name field in the Job
Scheduling Definition entry panel, or a show screen filter).
The IOA Online environment provides the following types of profiles.
The Global profile, which can be customized by the system administrator only. This
profile serves as the default setting for all users in the Online environment. If the user
profile does not indicate a setting for a specific field, or does not provide a value for a
specific variable, the value specified in the Global profile is used.
The Global Profile also contains screen filter definitions that can be used by any user in
addition to the filter definitions defined in his/her User profile.
The Global profile is a combination of the default values in member $PROFFLD and
the overriding specifications in member $PROFMOD. (See Profile Members below.)
User profiles are defined for users or specific groups of users. These profiles can include
menu definitions and user-defined filters (described below). Settings in the User profile
override the settings in the Global profile.
Profile Members
Global profile information is stored in the following members in the IOA PARM library.
$PROFFLD Contains the default settings for the IOA Online environment. These
default settings should not be changed. This member also contains a
line that indicates the location of the User Profile members.
$PROFMOD Contains global customization information. The member can contain
the following types of information.
Global filter definitions.
User profile locations. If specified, these override the User profile
location specified in member $PROFFLD.
Values to override the default values for fields specified in member
$PROFFLD.
This member can be copied so that customization need not be
redefined when upgrading from a previous release.
$PROFVAR Contains the values specified for profile variables (runtime
parameters). The values of all profile variables are maintained via
ICE (Installation and Customization Engine). See Profile Variables
later in this section for more information about the variables in this
member.
User profile members are located in libraries specified in member $PROFFLD and,
optionally, in $PROFMOD. These libraries are listed in the lines beginning with a dollar sign
($) in the $PROFFLD member. For example, the following lines indicate that the user profile
for user M89 is in library IOAP.V51M.PROF and that all other user profiles are in library
IOAP.V514.PROF.
000059 * POINTERS TO USERS PROFILE LIBRARIES. *
000060 *--------------------------------------------------*
000061 $M89 =IOAP.V51M.PROF
000062 $* =IOAP.V514.PROF
By default, the following line is included in member $PROFFLD:
$* =%OLPREFA%.PROF
This line indicates that all user profiles are found in the PROF library with the prefix of
the dataset in which IOA was installed.
User profiles can be divided into more than one library. For example,
$M* =%OLPREFA%.PROFM
$N* =%OLPREFA%.PROFN
can be used to direct all User profiles beginning with M to be stored in the PROFM library
and User profiles beginning with N to be stored in the PROFN library.
Mask characters (* and ?) can be used in the specification of the user names (profiles) to be
stored in a specific library.
Profile Contents
The following types of lines can appear in a profile member:
Lines that contain an asterisk (*) in column one are remark lines.
Lines that contain a dollar sign ($) in column one indicate user profile libraries
(described above).
Lines describing either variables, fields or filter fields. These are called Profile Symbol
lines.
The format for Profile Symbol lines is:
Columns 1-8 Profile symbol (field) name. Mandatory.
Column 9 Period. (Mandatory only if a Filter name follows.)
Columns 10-17 Filter name. Optional. Default: blank.
Column 18 Equal sign (=). Mandatory.
Columns 19-72 Profile symbol value. Blank is a valid value.
Examples
The line shown below is a regular field line (not a filter).
SRLBLIB =%OLPREFB%.RULES
The following lines describe global filter ENDNOTOK which, when activated, displays all
ended NOTOK jobs from option 3 (Job Status).
SSTA700 .ENDNOTOK=N
SSTA704 .ENDNOTOK=N
Considerations for Profile Symbol Lines
Values for Profile variables are specified in ICE (using the CUSTOMIZE option for IOA
in the IOA Installation Main Menu). The values are stored in member $PROFVAR in
the IOA PARM library. See Profile Variables later in this section for details on what
values to specify for the Profile variables via ICE.
Field lines contain values to be used for fields in IOA that are not part of a SHOW
window (e.g., a library name in a rule/job/mission definition entry panel). Field lines
can be located in any of the following members:
$PROFFLD The field line indicates the default value supplied with the IOA
installation.
$PROFMOD The field line indicates a value specified as part of on-site
customization of the Global profile. Field line specifications in
$PROFMOD override specifications in $PROFFLD.
$userid The field line indicates a value specified as part of a user profile.
Filter field lines specify values for selection criteria fields in Show Window filters (For
example, Y or N for field UTILITIES in the IOA Log Show Screen Filter window
indicates whether or not messages from CONTROL-T utilities should be displayed).
SHOW Window Filters
A filter is a set of values for fields in a show window. The user can name a set of values
and activate a filter at a later time by specifying the following command in the command
line of the relevant screen:
SHOW filtername
Filters that are saved by a specific user are stored in that users User Profile member. To
add a filter to the Global profile, perform the following steps:
1. Create and save the filter in your User Profile member.
2. Copy the lines containing the name of the filter from your User Profile member to the
Global Profile member ($PROFMOD).
Some default filters are provided in member $PROFFLD.
Note IOA filters are provided for options 3 and 5 in the IOA Primary Option menu. See the
descriptions of these options in the product-specific user manual(s) for more
information about IOA filters.
Profile Attribute in the Screen Definition
IOA is installed with default profile attributes assigned to various fields. You can change
these defaults as follows:
A field can be defined with a profile attribute by adding parameter PROF=YES to the field
macro definition in the screen definition member in the MSG library. For example:
CTMSFLD NAME=SSCHROL,ATTR=UH,LTH=4,PROF=YES
For instructions on how to change the screen format, see Recommended Steps For Screen
Modification earlier in this section.
Under certain screens, parameter PROF designates the name of the profile variable. When
YES is specified, the field name is used as the Profile Variable name. If you want to change
the profile attributes of these screens, consult your IOA representative.
Note IOA profile capability can be applied to fields in the header, footer, and windows of
each screen, but not to fields which appear as part of a scrollable area on the screen. If
you wish to apply the profile capability to a field in a scrollable area, consult your IOA
representative.
Saving a Profile
A profile is saved by writing it to the user profile library in a member whose name is
identical to the user ID (the Online environment session ID, e.g., TSO user ID). However, a
profile is saved only when the user exits the IOA Online facility, and only in case of normal
termination.
Note If the profile library is full, the attempt to save a User profile fails with a D37 abend.
It is recommended that the profile library be compressed regularly.
Profile Variables
Follow the Major and Minor steps in ICE to specify values for the Profile Variables. If you
are not familiar with the ICE application, refer to the IOA Installation Guide.
To change the value of a Profile variable, use the CUSTOMIZE option in the IOA
Installation Main menu.
When IOA is installed, all Profile variables receive a value. Values for Profile variables are
first stored in ICE tables (ISPF tables). These values are copied from the ICE tables into
the parameter members once all ICE steps are performed.
ICE allows referencing of previous settings of Profile variables specified in other (previous
or current) environments of IOA. When installing a new IOA environment, it is possible to
automatically retrieve the predefined settings at your site. A default value is provided for
any new profile variables that are not retrieved.
When updating the parameter values, ICE verifies that the values stored in the ICE tables are
the most current values. The values are verified using an internal comparison mechanism that
compares the values in ICE and the values in the target parameter members.
If all values are identical, processing continues. If conflicts are identified, a screen is
displayed listing the parameters for which the values in ICE are different than the values
specified in the parameter members. You can select which version of the parameters is
required, and either retain the current values in ICE or copy the values from the
parameter member into ICE.
Notes Differences between ICE tables and parameter members can occur when the user
updates values in ICE and exits without updating the parameter member, or when the
user updates the parameter member outside ICE.
If no value is specified, a default value is provided for each profile variable. All of the
Profile variables and their defaults are listed below.
To change the value of a Profile variable, perform the following steps in ICE:
1. Specify IOA as the Product ID.
2. Select CUSTOMIZE (Option 7) from the Main menu.
3. Select Major Step 3, Profile Variables.
4. Select the type of variable.
5. Locate the desired variable and specify the required value.
Note Online help is available for each variable specified via ICE. A description of each
variable is provided below.
Window Display Variables
SABKWND Controls whether or not to display the Save confirmation window
when a request is made to update a backup mission from the
CONTROL-D Active Mission Zoom screen (screen A.Z).
Y (Yes) The confirmation window is displayed.
N (No) The backup mission is updated without prompting the
user for confirmation. Default.
SACTCNF Controls whether or not a confirmation window is opened when a
request is made to rerun a job in the Active Jobs file (screen 3) with
the status WAIT CONFIRMATION (CONTROL-M without
CONTROL-R). Called SSTACNS prior to IOA Release 5.0.4.
Y (Yes) A confirmation window is displayed. Default.
N (No) An attempt is made to rerun the job without prompting
the user for confirmation.
SACTDEL Controls whether or not a confirmation window is opened when a
request is made to delete an entry from the CONTROL-M Status
screen (screen 3). Called SSTDEL1 prior to IOA Release 5.0.4.
Y (Yes) A confirmation window is displayed.
N (No) The delete request is processed without prompting the
SACTRER Controls whether or not a confirmation window is opened when a
request is made to rerun a job (CONTROL-M without CONTROL-R).
Called SSTAWND prior to IOA Release 5.0.4.
N (No) An attempt is made to rerun the job without prompting
the user for confirmation.
SAMAWND Controls whether or not a confirmation window is displayed when a
request is made to rerun a mission from the CONTROL-D Active
Missions screen (screen A).
N (No) The request to rerun a mission is processed without
prompting the user for confirmation.
SAMDEL1 Controls whether or not a confirmation window is opened when a
request is made to delete an entry from the CONTROL-D Active
Missions screen (screen A).
N (No) The request to delete an entry from the Active Missions
screen is processed without prompting the user for
confirmation. Default.
SAPRWND Controls whether or not to display the Save confirmation window
when a request is made to update a printing mission from the
CONTROL-D Active Mission Zoom screen (screen A.Z).
N (No) The printing mission is updated without prompting the
SARSWND Controls whether or not to display the Save confirmation window
when a request is made to update a restore mission from the
CONTROL-D Active Mission zoom screen (screen A.Z).
N (No) The restore mission is updated without prompting the
SDECWND Controls whether or not to display the Save confirmation window
when a request is made to update a decollation mission from the
CONTROL-D Active Missions zoom screen (screen A.Z).
N (No) The decollation mission is updated without prompting
the user for confirmation. Default.
SDWYCNA Controls whether or not a confirmation window is displayed when a
request is made to add a prerequisite condition via the CONTROL-D
Why screen (screen A.?).
N (No) The add request is processed without prompting the
SMSCWND Controls whether or not the Reset confirmation window is displayed in
the CONTROL-O Message Statistics screen (screen OM).
Y (Yes) The confirmation window is displayed. Default.
N (No) The Reset is processed without prompting the user for
confirmation.
SNRSCNE Controls whether or not a confirmation window is displayed when a
request is made to erase a condition from the IOA Manual Conditions
list (screen 7).
N (No) The erase request is processed without prompting the
SRESCND Controls whether or not a confirmation window is displayed when a
request is made to delete a condition/resource from the IOA
Conditions/Resources file (screen 4).
SSZMWND Controls the method of exiting the CONTROL-M Zoom screen
(screen 3.Z) when the user has made changes.
Y (Yes) The PF03/END command is interpreted as a SAVE
request and a SAVE confirmation window is displayed
to prompt the user for confirmation.
If SAVE is specified in the command line, changes to
the job entry are made without displaying the SAVE
confirmation window.
N (No) SAVE must be specified in the command line to request
that changes be kept. No SAVE confirmation window is
displayed. Default.
SUSRDELW Controls whether or not a confirmation window is displayed when a
request is made to delete a report in the User Report List screen
(screen U) of CONTROL-D.
SUSRUPDW Controls whether or not a confirmation window is displayed when a
request is made to update a report in the User Report List screen
(screen U) of CONTROL-D.
N (No) The update request is processed without prompting the
SWHYCNA Controls whether or not a confirmation window is displayed when a
request is made to add a prerequisite condition via the CONTROL-M
Why screen (screen 3.?).
N (No) The add request is processed without prompting the
user for confirmation.
Color Variables
A color and highlight value can be specified for each of the profile variables described
below. Each profile variable has its own default color and highlight value. The format for
specification of color and highlight is:
profile-variable=color,highlight
where:
profile-variable Name of the profile variable for which color and highlight values are
being specified. Profile variables used to specify color for elements in
the IOA environment are listed below.
color Color of the relevant element. Valid values:
BLUE
RED
PINK
GREEN
TURQ
YELLOW
WHITE
highlight Type of display for the element. Valid values:
BLINK
USCORE
REVERSE
The following profile variables are used to determine the color and highlight attributes of
specific elements in the IOA environment:
SLNFPAG Attribute for the sample lines when editing a report to create a ruler
in the CONTROL-D Online Viewing screen (screen U.E).
Default: RED,REVERSE.
SMSGERR Attribute for ERROR messages (whose codes end with E).
Default: PINK,REVERSE.
SMSGINF Attribute for INFORMATION messages (whose codes end with I).
Default: TURQ,REVERSE.
SMSGSVR Attribute for SEVERE error messages (whose codes end with S).
SMSGWRN Attribute for WARNING messages (whose codes end with W).
Default: YELLOW,REVERSE.
SNTPCBR Attribute for the Notepad Window in screen U when a note is being browsed.
Default: BLUE.
SNTPCED Attribute for the Notepad Window in screen U when a note is being
edited/created.
Default: YELLOW.
On color terminals, the lines of the record-level index value are displayed in the color
specified in the first parameter.
On monochrome terminals, the record level index lines are highlighted (in either
REVERSE, BLINK or USCORE) as specified in the second parameter.
SOLVHFC Attribute for the header area in Online Viewing screens (screens U.V
and 3.V).
Default: PINK,REVERSE.
SOLVICL Attribute for lines containing record level index values when viewing a
CONTROL-V report via the U.S.X screen.
Default: GREEN,REVERSE.
SOLVLVC Controls report display via a record level index.
Y (Yes) When viewing a report via a record level index, the first
line containing the record level index value is displayed
at the top of the screen.
N (No) The report is viewed from the beginning of the first
page that contains the record level index values.
Default.
SOLVOCL Attribute for the overlay line in Online Viewing screens (screens U.V
and 3.V).
SOLVSCL Attribute for the scrollable area in Online Viewing screens (screens
U.V and 3.V).
Default: BLUE,REVERSE.
SSYVSCL Attribute for the Sysout viewed from screens U.V and 3.V.
This parameter is effective only for sites with CONTROL-R installed.
Default: WHITE, REVERSE.
Work Mode Variables
IFLTSTA Specifies the name of an optional initial filter when entering the
CONTROL-M Job Status screen (screen 3). If a valid filter name is
specified, it becomes the default of the initial SHOW filter of screen 3.
EXEC Filter EXEC is displayed as the initial SHOW filter,
until the user changes it using the SHOW xxx
command, regardless of the last filter that was used.
blank No initial filter is used. The filter that was used the last
time screen 3 was entered is displayed. Otherwise, the
default filter is used as the initial filter. Default.
PDATELTH Date format length (does not affect all IOA date references). Valid values:
6 digits. The format is ddmmyy. Default.
8 digits. The format is ddmmyyyy.
Note This variable affects only MDY and DMY date formats.
PNRSDTYP Defines the default value of the date field in the window opened as a
result of adding a new manual condition (ADD NEW command) in the
IOA Manual Conditions file (screen 7). Valid Values:
DATE The current MVS system date is inserted in the
window. Default.
ODAT The ODAT (the original scheduling date) is inserted in
the window.
PSCHDTYP Defines the default value of the date field in the confirmation window
opened as a result of ordering or forcing a job/rule/mission from a
Definition List screen (screens 2, R, M, OR, TR, and BM). The same
default is used for CONTROL-M job ordering via CLIST CTMCJOBS.
DATE Current system date is inserted in the window. Default.
ODAT The original scheduling date is inserted in the window.
PZUMFAPP Controls whether or not the user is required to enter a value in the
APPLICATION field in the Job Scheduling Definition screen (screen 2).
Y (Yes) The user is required to enter a value in the
APPLICATION field.
N (No) The user is not required to enter a value in the
APPLICATION field. Default.
PZUMFGRP Controls whether or not the user is required to enter a value in the
GROUP field in the Job Scheduling Definition screen (screen 2).
Y (Yes) The user is required to enter a value in the GROUP field.
N (No) The user is not required to enter a value in the GROUP
field. Default.
RESWPF3 Specifies whether PF3 is used in addition to PF4 in the Show window
of the Job Status screen (screen 3) to reset (i.e., exit the window with
no action). Valid values:
Y (Yes) PF3 will reset the window.
N (No) PF3 will not reset the window. Default.
SINSLMT Limits the lines to be read in the CONTROL-T Media Database list
(screen TI).
The search limit is a number from 1 to 999,999. Default: 100,000.
SNRSDRNG Determines the DATE range for the IOA Manual Conditions file
(screen 7). Valid values:
ALL
YEAR
MONTH
nnn Sets FROM to nnn days from today and UNTIL to the
current date. Default: 3.
SRCHLMT Specifies the search limit for the IOA Log file and the Automation Log
file (screens 5 and OL). Default: 010000.
SRESDRNG Determines date range for the IOA Conditions/Resources file (screen 4).
Valid values:
ALL
YEAR
MONTH
nnn Sets FROM to nnn days from today, and UNTIL to the
current date. Default: 3.
SROLFDL Limits the number of lines searched via the FIND command in the
CONTROL-D User Reports facility. This parameter must contain five
valid digits (including leading zeroes if necessary). Default: 05000
(i.e., 5000 lines).
SSCHBRO Controls whether or not a user is forced into BROWSE mode when a
job/mission/rule definition selected from an IOA definition screen is in
use by another user. Valid values:
Y (Yes) Force the user into BROWSE mode.
N (No) Display message CTM717E and reject the option. Default.
SSYVORD Controls the order of jobs displayed in screen 3.V of the CONTROL-M/R
Online interface (Sysout Viewing screen). This parameter is relevant only
for sites with CONTROL-R installed. Valid values:
FIFO Sysouts are displayed in FIFO (first in, first out) order.
The oldest jobs Sysout is displayed first. Default.
LIFO Sysouts are displayed in LIFO (last in, first out) order.
The most recent job s Sysout is displayed first.
SUS2LMT Limits the lines to be read in screen U.
The search limit is a number from 1 to 999,999. Default: 500.
A value of 999999 specifies an unlimited search.
SUS2SRTI Controls whether or not to activate the SORT command in screen U.
(CONTROL-D/V User Report List).
Valid values:
Y (Yes) Automatically activate the SORT command upon
accessing screen U.
N (No) The SORT command is not activated when accessing
screen U. Default.
See Section 2 of the CONTROL-D or CONTROL-D User Manual for
details about the SORT command in screen U.
SUS2TRE Controls whether or not to check if a user name exists in the
CONTROL-D Recipient Tree when using the GIVETO command and
when adding an additional user via the ADD INFO option in the
CONTROL-D/V User Report List screen. Valid values:
Y (Yes) Check if the user name exists in the CONTROL-D
Recipient Tree.
N (No) Do not check if the user name exists in the Recipient
Tree.
SVEWFFI Controls whether or not to use a fast find algorithm when using the
FIND command in CONTROL-D/V screen U.V and CONTROL-M
screen 3.V. Valid values:
Y (Yes) Activate a fast find algorithm which requires up to 50%
less CPU time when searching forward. Supports only
all uppercase and all lowercase search strings. Mixed
case strings are not supported.
N (No) The regular FIND command is activated when viewing
reports/sysouts. Supports uppercase, lowercase and
mixed case search strings. Default.
The line where the string is found is always displayed as the first line
on the screen. In CONTROL-D and CONTROL-V, the fast find
algorithm is used only when viewing reports without rulers.
Presentation Mode Variables
ISPFBOTL Controls the position of the last screen line when the IOA Online
interface operates under ISPF. Valid values:
L1 The last IOA screen line is displayed on the bottom line
of the physical screen. Default.
L2 The last IOA screen line is displayed on the second line
from the bottom of the physical screen.
SACTFOK Controls whether or not a confirmation window is displayed when the
O (Force OK) option is specified in the CONTROL-M Status screen
(screen 3). Valid values:
Y (Yes) Display a confirmation window. Default.
N (No) Do not display a confirmation window.
SACTLTO Controls whether or not late jobs are combined with all other jobs in the
Show Screen Filter window of the CONTROL-M Status screen
(screen 3). Called SSTALTO prior to IOA Release 5.0.4. Valid values are:
ONLY Late jobs are not combined with all other jobs (i.e., only
late jobs are displayed, regardless of what other
selection criteria are specified). Default.
blank Late jobs are combined with jobs that conform to other
selection criteria.
SACTMOD Controls the starting point and direction of data flow in the
CONTROL-M Status screen (screen 3). Valid values:
BOT On entering the Status screen, jobs at the bottom of the
Active Jobs file (i.e., the newest jobs) are displayed. The
user can use scrolling commands and PFKeys to scroll
upward (to the oldest jobs). Prior to IOA Release 5.0.4,
the Status screen was always displayed this way.
Default.
TOP On entering the Status screen, jobs at the top of the
Active Jobs file (i.e., the oldest jobs) are displayed. The
user can use scrolling commands and PFKeys to scroll
downward (to the newest jobs).
SBALTBO Controls whether a single or double confirmation window is opened
when a mission is ordered or forced in the CONTROL-B Mission List
screen (screen BM). Valid values:
Y (Yes) A single double confirmation window is opened when a
mission is ordered or forced.
N (No) A confirmation window is opened when a mission is
ordered or forced. Default.
SMISTBO Controls whether a single or double confirmation window is opened
when a mission is ordered or forced in the CONTROL-D
Printing/Backup/Restore Mission list (screen M).
Y (Yes) A double confirmation window is opened when a
N (No) A single confirmation window is opened when a mission
is ordered or forced. Default.
SOMPTBO Controls whether a confirmation window or a double confirmation
window is opened when an entire table is ordered or forced in the
CONTROL-O Rule Table list (screen OR).
Y (Yes) A double confirmation window is opened when a table is
ordered or forced.
N (No) A confirmation window is opened when a table is
SRCMTBO Controls whether a single or double confirmation window is opened
when a rule is ordered or forced in the CMEM Rule list (screen C).
Y (Yes) A double confirmation window is opened when a
N (No) A single confirmation window is opened when a mission
is ordered or forced. Default.
SREPTBO Controls whether a single or double confirmation window is opened
when a mission is ordered or forced in the CONTROL-D Mission list
(screen R).
Y (Yes) A double confirmation window is opened when a job is
ordered or forced.
N (No) A single confirmation window is opened when a job is
SRLDATO Controls whether Rule Description or Rule Data is displayed by
default in the CONTROL-T Rule list (screen TR).
Y (Yes) Display the Rule Description by default.
N (No) Display the Rule Data by default.
SSCHTBO Controls whether a single or double confirmation window is opened
when a table is ordered or forced in the CONTROL-M Table list
(screen 2).
Y (Yes) A double confirmation window is opened when a table is
ordered or forced.
N (No) A single confirmation window is opened when a table is
SUSRFTR Controls the default display type of the footer of the User Report entry panel.
Default: blank. When a blank is encountered, the following values are used:
When only CONTROL-D is installed: display type D.
When CONTROL-V is installed: display type V.
SUSRHDR Controls the default display type of the header of the User Report
entry panel. Default: blank. When a blank is encountered, the
following values are used:
When only CONTROL-D is installed display type D.
When CONTROL-V is installed display type V.
SUSRVEW Controls whether or not the view indicator in the CONTROL-D/V
Report List screen (screen U) is displayed, and if it is displayed, what
the format is.
Y (Yes) The view indicator is blank if the report has not yet been
viewed and V if the report has been viewed. Default.
N (No) The view indicator is not displayed and not saved.
A The view indicator indicates the number of times
(maximum: 255) the report has been viewed. If the
number is too large to fit into the display field, an
asterisk (*) is displayed.
Note By default, the view indicator is one column wide.
Miscellaneous Variables
EDIMACNM Name of the optional ISPF EDIT IMACRO to be used when editing a
jobs JCL in CONTROL-M screens 2.J and 3.J.
macro name The specified IMACRO is invoked at entry to ISPF EDIT.
blank No IMACRO is invoked at entry to ISPF EDIT. Default.
ICOLOR Specifies whether or not extended color support should be used for
terminals accessing the IOA Online facility from IMS, IDMS, and
other systems that do not allow determination of terminal
characteristics.
Y (Yes) Use extended color support for this terminal.
N (No) Do not use extended color support for this terminal. Default.
IDBCS Specifies whether or not Double Byte Character Set support should be
used for terminals accessing the IOA Online facility from IMS, IDMS,
and other systems that do not allow determination of terminal
characteristics.
Y (Yes) Use Double Byte Character Set support for this terminal.
N (No) Do not use Double Byte Character Set support for this
terminal. Default.
TCOLOR Specifies whether or not extended color support should be used for
terminals accessing the IOA Online facility from TSO or ROSCOE.
TERMINAL Query the hardware to determine whether or not to use
extended color support for this terminal. Default.
Y (Yes) Use extended color support for this terminal.
N (No) Do not use extended color support for this terminal.
TDBCS Specifies whether or not Double Byte Character Set support should be
used for terminals accessing the IOA Online facility from TSO or
ROSCOE.
TERMINAL Query the hardware to determine whether or not to use
Double Byte Character Set support for this terminal. Default.
Y (Yes) Use Double Byte Character Set support for this terminal.
N (No) Do not use Double Byte Character Set support for this
terminal.
USCORE Controls whether or the UNDERSCORE attribute for terminal fields should
be suppressed or honored. Some terminals and terminal emulator programs
display underscored fields with incorrect colors and/or reverse video.
Y (Yes) Honor the UNDERSCORE attribute.
N (No) Suppress the UNDERSCORE attribute. Default.
Other Types of Profile Variables
TERMTYPE Specifies the terminal type used to access the IOA Online
environment. Valid value:
3270 IBM 3270 or 3270 Emulation terminal. Default value
for MVS users.
Modifying IOA Product Defaults
After one or more IOA products are installed and running, certain defaults can be modified
within the product. For example, increase the number of CONTROL-M attempts to read a
job s sysout.
1. Review documentation member IOADFLTS which lists explaining the defaults that can
be modified. This member resides in the IOA SECUDATA library.
2. Update member IOADFLTC in the IOA MAC library using member UMIDFLTU in the
SECUDATA library. Modify one or more default values as detailed in documentation
member xxxDFLTS (where xxx is a product code). The parameters are in Assembler
Macro format, and are therefore restricted to Assembler Macro syntax (continuation
marker in column 72, continuation line starts at column 16, etc.).
Note Line number columns 73-80 must remain the same as in member IOADFLTC in the
IOA MAC library.
3. In addition to member IOADFLTC, there may be user exits in the IOA SECUDATA
library which can be applied to modify default processing within a specific product. See
member $DOISECU in the IOA SECUDATA library for more information.
Note Once all the required changes are made to the IOA product defaults, it is necessary to
restart all the monitors and users of the modified products by shutting down and
restarting the monitors and logging users off and on.
Modifying IOA Messages
IOA messages can be adapted for local languages, site-specific terminology, etc.
IOA messages are stored in the IOA MSG library. The messages are organized in members
with the following naming convention:
CTxAMyyy
CTxMyyy
CTxRMyyy
CTxTMyyy
CTxCMyyy
where:
x A single character indicating the product (e.g., M for a CONTROL-M
screen).
yyy A 3-character message member identifier.
Each member contains definitions for one or more messages. The definitions are specified
as Assembler macro instructions. Each member must be assembled and link-edited to
create a CSECT and module with a name identical to the message member name. The load
module containing the messages replaces an existing CSECT in one or more load modules
in the IOA LOAD library.
The message member must contain a CTMLEVEL macro prior to the first message
definition. If this macro is omitted, results can be unpredictable.
Each message is defined by macro CTMMMSG. This macro has the following parameters:
CODE Code of the message. Do not change this code because it connects the
message to the application program.
MESSAGE Text of the message (in quotes).
PARM Length and position of the text inserted into the message by the IOA
application. The format of this parameter is:
PARM=(pos1,length1[,...])
pos is the position of the inserted text in the message +6.
length is the length of the text to be inserted. Do not change it.
Parameter PARM is optional, but must be used whenever it already appears in the
message definition. When the contents of a message are modified, the position of the
application generated area in the message may change, so the PARM field must be
modified accordingly. The order of the fields in the PARM should not be changed, but it is
possible to change the order of appearance in the message by changing the positions.
Example
The original message (from member CTMMSEL):
CTMMMSG CODE=SEL206W,PARM=(18,5,29,16),
MESSAGE=ABENDED CC XXXXX STEP YYYYYYYYYYYYYYYY
The modified message:
CTMMMSG CODE=SEL206W,PARM=(45,5,23,16),
MESSAGE=ABENDED ON STEP YYYYYYYYYYYYYYYY CODE XXXXX
Recommended Steps for Message Modification
Sources (message members) of IOA products are modified via an SMP/E USERMOD. Use
the following steps to perform this task:
1. Choose a name for the USERMOD (to be built in the following steps). The name of the
USERMOD must be 7 characters in length, must begin with an alphabetic character
(i.e., not a number or symbol), and must be unique.
2. Create a new member in the IOA MAINTLIB library with the same name as the
USERMOD created in Step 1.
3. Copy the contents of member UMODSRC in the IOA JCL library to the newly-created
member. This member contains a skeleton sample for the USERMOD (to be customized
in the following steps).
4. Specify the name of the new USERMOD in the ++USERMOD statement.
5. Determine the FMID and the RMID of the message source via SMP/E Option 3.2.
Specify SRC as the entry-type and the name of the message source as the entry-name.
Specify the FMID in the ++VER statement.
If the RMID value is not the same as the FMID value, add the RMID value to the
++VER statement via the PRE(rmid-value) parameter.
6. Specify the source-name in the ++SRC statement.
7. Copy the contents of the source member to the line immediately after the ++SRC
statement. Update the copy to meet your needs.
8. Specify the name of the USERMOD in job UMODRACK in the IOA JCL library. Run the
job. This job RECEIVEs and APPLY-CHECKs the USERMOD.
Job UMODRACK must end with a completion code of 0.
9. Specify the name of the USERMOD in job UMODAPP in the IOA JCL library. Run the
job. This job applies the USERMOD.
Job UMODAPP must end with a completion code of 0.
The IOA Shout facility enables the user to specify messages to be sent to specified
destinations upon the occurrence of various events.
Destinations in a production environment are not necessarily fixed. For example, the TSO
logon ID of the shift manager may be different for every shift. The Dynamic Destination
table allows the user to specify a logical destination name for a group of destinations.
When the logical destination name is specified as the destination of a Shouted message, the
message is sent to each destination in the group.
Member IOADEST in the SECUDATA library contains an example of a Dynamic
Destination table. To update the Dynamic Destination table, assemble and link-edit load
module CTMDEST using member IOADESTJ in the IOA INSTALL library, and then
reload the table into memory for each of the IOA products installed at your site. For
more information about Dynamic Destination tables, see Dynamic Destination Table in
Section 1 of this guide.
Example
The following are sample lines from a Dynamic Destination table:
CTMGDEST TSO-SHIFT-MNGR,DEST=(TSO-Q04,OPER,U-Q04)
CTMGDEST TSO-DBA,DEST=(TSO-S08,TSO-S09)
Replacing the Current Dynamic Destination Table
The Dynamic Destination table is loaded when the IOA product monitor is started. To
replace the current Dynamic Destination table with a new one, use the appropriate
operator command for each IOA product installed at your site.
F CONTROLM,NEWDEST (for CONTROL-M)
F CONTROLD,NEWDEST (for CONTROL-D)
F CONTROLO,NEWDEST (for CONTROL-O)
F IOAFMON,NEWDEST (for the IOA Functional monitor used by CONTROL-T)
After a few seconds, a message about the result of the operation is displayed on the
operator console from which the modify command was issued.
Expanding the IOA Conditions/Resource File (RES)
1. Close all the monitors and IOA activities.
2. Rename the old RES and SNC files.
3. Select major step Customize Dataset Parameters from the CUSTOMIZE activity in
ICE. Change the value of parameters RESREC# and RESLREC to the required values
(a maximum of 32 for parameter RESREC#, and a maximum of 32760 for parameter
RESLREC). Complete the remainder of the minor steps for this step to update and
compile member IOAPARM, and customize the formatting jobs.
4. Edit member FORMRES in the IOA INSTALL library. Check that the value of parameter
LRECL is identical to the value of parameter RESLREC in member IOAPARM, and that
the value of parameter RECNUM is equal to: (RESREC# * 32) + 2. Submit this job. This
job will allocate and format a new set of RES/SNC files with the new size.
5. If you do not use a dual resource file, skip to step 7 below.
6. Edit member FORMDRES in the IOA INSTALL library. Check that the value of
parameter LRECL is identical to the value of RESLREC in IOAPARM, and that
parameter RECNUM is equal to: (RESREC# * 32) + 2.
Submit the job. This job will allocate and format a new set of ALTRES/ALTSNC files
with the new size.
7. Copy the old resource file(s) into the new one(s) using utility IOACOPRS. See Section 9
of this guide for information about utility IOACOPRS.
8. Start the monitors.
Expanding the IOA LOG File (LOG)
1. Close all the monitors and IOA activities.
2. Rename the old LOG file.
3. Select major step Customize Dataset Parameters from the CUSTOMIZE option in
ICE. Recalculate the LOGSIZE parameter. Complete the remainder of the minor steps
in this step to update and compile member IOAPARM, and customize the formatting
jobs.
4. Submit member FORMLOG in the IOA INSTALL library. This job allocates and
formats a new LOG file with the new size.
5. Copy the old LOG file into the new file using job IOACPLOG in the IOA JCL library.
6. Start the monitors.
General ...........................................................................................................................................3-1
Activating the CONTROL-M Monitor.......................................................................................3-1
Shutting Down the CONTROL-M Monitor...............................................................................3-1
Starting the CONTROL-M EVENT MANAGER (CMEM) Facility.........................................3-2
Shutting Down the CMEM Facility...........................................................................................3-2
Replacing an Active CMEM Monitor.........................................................................................3-3
Modifying the CONTROL-M Sleeping Interval ......................................................................3-3
Refreshing the CONTROL-M Security Cache ..........................................................................3-4
Refresh Deadline Scheduling and Job Network Dependencies..................................................3-4
Shift DUE OUT Times for CONTROL-M Jobs.........................................................................3-5
Sending a Jobs SYSDATA to a Held Output Class..................................................................3-5
Accumulating Job Execution Statistics.....................................................................................3-6
Expanding CONTROL-M Files..................................................................................................3-7
Expanding the Active Jobs File (CKP).................................................................................3-7
Expanding the CONTROL-M Jobs Dependency Network File (GRF) ...............................3-7
Expanding the CONTROL-M Statistics File (STAT) ..........................................................3-7
Expanding the IOA Manual Conditions File (NRS) ............................................................3-8
CDAM Files.................................................................................................................................3-8
Display CONTROL-M Installation Parameters .......................................................................3-8
Switching from SAPI to PSO support .......................................................................................3-8
Problem Determination..............................................................................................................3-9
Job Ordering via New Day Processing................................................................................ 3-10
Overview ...................................................................................................................................3-10
Sample New Day Processing....................................................................................................3-12
How the Sample Components Perform New Day Processing ...........................................3-13
Date Control Records and Enhanced Daily Checkpointing ...................................................3-15
Implementing New Day Processing ........................................................................................3-16
Programs Called During New Day Processing .......................................................................3-23
Use of the Date Control Record by User Daily Jobs...............................................................3-25
New Day Procedure Flow.........................................................................................................3-27
Considerations for Job Ordering and Submission..................................................................3-28
Library Compression...........................................................................................................3-28
JCL Parameter MSGLEVEL..............................................................................................3-28
Comment Lines Added During Job Submission................................................................3-28
End User Job Order Interface Defining Job Lists for Each User .......................................3-29
TSO User ID Masking.........................................................................................................3-29
CONNECT DIRECT Support ..................................................................................................3-30
IOA Rel. 5.1.4 - Administrator Guide
Activation of Started Tasks..................................................................................................... 3-32
Daylight Savings Time Considerations................................................................................ 3-32
Advancing the Clock Forward................................................................................................. 3-32
New Day Procedure ............................................................................................................ 3-33
Time-Dependent Shouts..................................................................................................... 3-33
Time-Dependent Schedules (FROM-UNTIL).................................................................... 3-33
Cyclic Jobs........................................................................................................................... 3-33
IOA Log File........................................................................................................................ 3-33
Moving the Clock Backwards.................................................................................................. 3-34
New Day Procedure ............................................................................................................ 3-34
Time-Dependent Shouts..................................................................................................... 3-34
Time-Dependent Schedules (FROM-UNTIL).................................................................... 3-34
Cyclic Jobs........................................................................................................................... 3-34
IOA Log File........................................................................................................................ 3-34
Managing the CMEM Facility................................................................................................. 3-35
Automatic Loading of Rules .................................................................................................... 3-35
Deleting (Deactivating) an Active Rule Table........................................................................ 3-37
Displaying Active Rules........................................................................................................... 3-37
Controlling CMEM Rule Operation Mode.............................................................................. 3-38
Modifying the CMEM Sleeping Interval ................................................................................ 3-38
Refreshing the CMEM Security Cache................................................................................... 3-39
Virtual Storage Requirements of the CMEM Monitor........................................................... 3-39
Calculating Region Size...................................................................................................... 3-39
Troubleshooting .................................................................................................................. 3-40
Storage Allocation............................................................................................................... 3-40
CMEM Usage of the Common Storage Area (E/CSA)............................................................ 3-41
Extended CSA Usage (Above 16M Line) ........................................................................... 3-41
CSA Usage (Below the 16M Line)...................................................................................... 3-41
CMEM CONTROL-M Communication................................................................................ 3-42
Coupling Facility and Coupling Facility Resource Management .................................... 3-42
MVS System Logger Sysplex Interface ............................................................................. 3-43
Problem Determination...................................................................................................... 3-43
CONTROL-M Tuning Recommendations ............................................................................ 3-45
General Tuning Issues .............................................................................................................3-45
Placing the IOA LOAD Library in the MVS Linklist (MVS/XA Sites).............................3-45
Placing CONTROL-M/IOA Files on Appropriate Disk Packs...........................................3-46
Placing Certain CONTROL-M/IOA Files on Special Disk Devices ..................................3-46
Enlarging CONTROL-M/IOA File Blocksize .....................................................................3-47
CONTROL-M Monitor and MVS/JES Considerations ...........................................................3-48
Special Considerations ........................................................................................................3-48
Run CONTROL-M on the Global Processor in a JES3 Complex......................................3-49
Run CONTROL-M on the CPU Where Most JES2 Activity is Performed..........................3-50
JES2PARM Tuning Considerations ...................................................................................3-50
Assign Appropriate Priority to the CONTROL-M Monitor....................................................3-51
Run the CONTROL-M Monitor as Non-swappable...........................................................3-51
Choose an Appropriate Sleeping Interval ..........................................................................3-51
Storage Isolation..................................................................................................................3-52
Tuning the Online Facility.......................................................................................................3-53
Preallocate Required CONTROL-M/IOA Files in TSO Logon Procedures ............................3-53
Try to Eliminate TSO STEPLIBs .......................................................................................3-53
Use the IOA Server Mechanism When Required ..............................................................3-53
Mirror File (Dual Checkpointing Mode) Considerations........................................................3-53
CONTROL-M Event Manager (CMEM) Considerations........................................................3-54
CONTROL-M Optional Wishes ...............................................................................................3-54
CONTROL-M Multi-CPU Support ......................................................................................... 3-54
Introduction ..............................................................................................................................3-54
Single-CPU Configuration with Multiple CONTROL-M Systems ...................................3-56
Multi-CPU Configuration.........................................................................................................3-57
Shared-Spool Configuration With an ENQ-Handling Product......................................3-57
Shared Spool Configuration Without an ENQ-Handling Product.................................3-60
Shared-Spool Configuration with Multiple CONTROL-M Production Systems .............3-61
Multi-CPU Configuration With Shared-DASD Only ........................................................3-63
NJE Network of MVS Nodes...............................................................................................3-64
Special Considerations .............................................................................................................3-66
Mainframe with PR/SM (or MDF or MLPF) ......................................................................3-66
Operating MVS System(s) Under VM................................................................................3-67
Support of Other Platforms (VM, DOS/VSE, AS/400, DEC, HP, etc.)..............................3-67
Support of Network Software .............................................................................................3-69
IOA Rel. 5.1.4 - Administrator Guide
CONTROL-M

VM Support ....................................................................................................... 3-71
Introduction.............................................................................................................................. 3-71
VM Configurations................................................................................................................... 3-71
MVS Running Under VM........................................................................................................ 3-72
MVS and VM Running on Separate Computers .................................................................... 3-73
MVS and VM Running Under PR/SM, MDF or MLPF ......................................................... 3-74
Invoking the IOA Online Facility From a VM Terminal....................................................... 3-74
Dialing Into the MVS Machine (MVS Under VM Only)........................................................ 3-75
Using VM/VTAM...................................................................................................................... 3-75
Using IOAs Logical Terminal Emulator................................................................................ 3-75
Using a Session Handling Product ......................................................................................... 3-75
File Transfer From MVS to VM.............................................................................................. 3-75
General ................................................................................................................................ 3-75
Routing the Production Jobs Report to VM via JCL........................................................ 3-76
Routing Production Job Sysout to VM via JCL................................................................. 3-76
Routing Production Job Sysout to VM via CONTROL-M Sysout Functions ........................ 3-77
Sending a File to VM in the Form of a Sysout .................................................................. 3-77
File Transfer Products............................................................................................................. 3-77
Utilize a Shared Disk Between MVS and VM........................................................................ 3-78
Triggering an Event in CONTROL-M by a VM User ............................................................ 3-78
Submitting a Job to MVS to Execute a CONTROL-M Utility ......................................... 3-78
Submitting a Job to MVS to be Monitored by CMEM...................................................... 3-78
CONTROL-M Triggering of Events in VM............................................................................. 3-79
Issuing a VM CP Command via IOAOPR (MVS Under VM only)................................... 3-80
Executing VM Commands via the IOAVAUTO Machine................................................. 3-81
Issuing a SHOUT Message to a VM User .............................................................................. 3-82
General ................................................................................................................................ 3-82
Using Utility IOAOPR........................................................................................................ 3-83
Using the VM IOAVAUTO Machine ................................................................................. 3-83
Other IOA Options.............................................................................................................. 3-83
IOA An Integrated Solution................................................................................................. 3-83
General ................................................................................................................................ 3-83
CONTROL-O....................................................................................................................... 3-84
CONTROL-O/PC................................................................................................................. 3-84
CONTROL-D....................................................................................................................... 3-84
Disaster Recovery Planning................................................................................................... 3-85
Overview ...................................................................................................................................3-85
Recovery Tools ..........................................................................................................................3-85
Dual Checkpoint Mode........................................................................................................3-85
Journaling............................................................................................................................3-86
Restoration...........................................................................................................................3-87
Planning and Creating a Disaster Recovery Plan..................................................................3-88
MVS, JES, Exits and Other Definitions.............................................................................3-88
Security Considerations ......................................................................................................3-88
Scheduling Libraries and Other Production Libraries......................................................3-88
Backup Procedures..............................................................................................................3-89
CONTROL-M Parameter Definitions.................................................................................3-89
Catalog Considerations .......................................................................................................3-90
Defining an Authorized TSO User .....................................................................................3-90
Problem Resolution...................................................................................................................3-90
General.................................................................................................................................3-90
AutoEdit Simulation Facility..............................................................................................3-92
Disaster Relocation..............................................................................................................3-93
Manual Recovery Procedures..............................................................................................3-94
Automatic Recovery after a System Crash ........................................................................3-95
General
This section describes the initialization, customization and administration features that
are available for CONTROL-M.
Activating the CONTROL-M Monitor
The CONTROL-M monitor usually operates 24 hours a day as a started task (STC).
Usually the monitor is automatically activated as part of the IPL process. To activate the
monitor manually, use operator command:
S CONTROLM
If the monitor is successfully activated, the following message appears on the operator
console:
CTM100I CONTROL-M MONITOR STARTED
Once the CONTROL-M monitor is active, if you try to activate an additional CONTROL-M
monitor with the same IOA components in the same computer, the new (i.e., additional)
monitor immediately shuts down and an appropriate message is issued.
Note It is possible to activate more than one CONTROL-M monitor in the same computer
environment (e.g., PROD and TEST version) by defining a different IOA environment
(and a different QNAME) for each monitor. See Installation Considerations in the
CONTROL-M installation procedure in the IOA Installation Guide.
Shutting Down the CONTROL-M Monitor
If for some reason it is necessary to shut down the CONTROL-M monitor, use operator
command:
P CONTROLM
After a few seconds (a maximum of a minute), the CONTROL-M monitor shuts down and
the following messages appear on the operator console:
CTM107I SHUT DOWN UPON REQUEST FROM OPERATOR (not highlighted)
CTM120I CONTROL-M MONITOR SHUTTING DOWN (highlighted, unrollable)
In case of emergency, the CONTROL-M monitor can be cancelled. However, this is not
recommended. If the monitor is cancelled, reports produced from the IOA Log file may not
be complete and certain jobs which have already run may be reordered (when the monitor
is restarted).
Note When you shut down the CONTROL-M monitor, all other CONTROL-M facilities
(e.g., CMEM), IOA Online monitors and Online facility sessions can remain active.
Starting the CONTROL-M EVENT MANAGER (CMEM)
Facility
The CONTROL-M Event manager (CMEM) is designed to handle events occurring outside
the control of the CONTROL-M monitor. CMEM consists of a monitor which uses the IOA
subsystem and performs predefined actions in response to system events (e.g., arrival of a
specified job on the JES spool).
Note This description of the CMEM facility is not relevant when CONTROL-O is installed at
your site. Instead, refer to Section 5 in this guide for information on how to manage the
CMEM facility when CONTROL-O is installed.
The CMEM monitor must operate 24 hours a day. The usual way to ensure this is to
automatically initialize the CMEM monitor during the IPL process.
To start CMEM as part of the IPL, add the following command to member COMMNDnn in
library SYS1.PARMLIB (where nn is either the number specified in member IEASYS in
library SYS1.PARMLIB, or defaults to 00 if not specified in IEASYS):
S CTMCMEM
The same operator command can be used to activate the CMEM monitor manually.
Shutting Down the CMEM Facility
Under normal circumstances, the CMEM monitor is not shut down. However, CMEM
shutdown might be necessary for the following reasons.
To resolve a problem that cannot otherwise be resolved. In this case, the monitor should
be immediately restarted after the problem is solved to minimize the impact of the
shutdown on the work environment.
To clean up (erase) all loaded CMEM tables from memory, or stop all CMEM
functionality (e.g., for a system shutdown).
To stop and immediately restart the CMEM facility, replace the active CMEM monitor by
starting a new CMEM monitor. (See Replacing an Active CMEM Monitor below.)
When the monitor replacement method is not applicable and a complete shutdown is
required, issue one of the following operator commands:
F CTMCMEM,STOP
-or-
P CTMCMEM
CMEM shuts down after a few minutes.
Note CMEM rules are not triggered for dataset events and step termination events caused by
jobs that start while CMEM is down.
Replacing an Active CMEM Monitor
If a CMEM monitor is currently active and a new CMEM monitor is started (via operator
command S CTMCMEM), the current CMEM monitor passes execution control to the new
CMEM monitor and then shuts down. It is not necessary to reload the rule tables. They are
passed from the current monitor to the new one. Therefore, to stop and immediately restart
the CMEM monitor with minimum interference to on-going work, issue the following
operator command:
S CTMCMEM
Modifying the CONTROL-M Sleeping Interval
Periodically, at a predefined interval, CONTROL-M wakes up and checks what it has to
do. This interval is set via a CONTROL-M installation parameter and can be changed by
the system administrator. In addition, the interval can be altered by operator command:
F CONTROLM,INTERVAL=xx
where xx represents the interval in seconds.
It is recommended that the interval be modified by automatic commands invoked by the
CONTROL-M monitor itself according to set conditions and time ranges and not manually
by the operator.
At most sites, the interval should be longer during the day (when fewer batch production
jobs are executing) and shorter during the night.
The optimal sleeping interval depends on the processing power of the machine. Depending
on the processing power of the machine indicated below, the sleeping interval should
usually not be less than the number of seconds indicated:
For machines with less than 20 MIPS 10 seconds
For machines with 20-50 MIPS 5-6 seconds
For machines with over 50 MIPS 4 seconds
There is no practical benefit in setting the interval to less than these minimums. Doing so
could slow down CONTROL-M operation.
When the modification is received by CONTROL-M, the following message is displayed on
the operator console from which the modify command was issued:
CTM123I CONTROL-M INTERVAL IS SET TO nn SECONDS
Refreshing the CONTROL-M Security Cache
CONTROL-M security modules use a security block to identify each user for which an
authority check is performed. The first time a users security authorization is checked,
CONTROL-M creates a security block for that user. The security block can then optionally
be saved for the next time the users security authorization is checked.
Security blocks saved for subsequent checks are kept in the CONTROL-M security cache.
The CONTROL-M security cache holds security blocks for the last 30 users to have their
security authorization checked.
Changes made to a users security authorization (since the last time that users security
block was created) are not automatically included in the information in the users security
block in the CONTROL-M security cache. However if a users security authorization has
been changed and there is no security block in the CONTROL-M security cache for that
user, changes made to the users security authorization will be in effect the next time that
users security authorization is checked.
To immediately include new user authorization information in the CONTROL-M security
cache, refresh the security cache via the following operator command:
F CONTROLM,NEWSECDEF
This command refreshes all user authorization information in the CONTROL-M security cache.
Refresh Deadline Scheduling and Job Network Dependencies
It is possible that within a network of predecessor/successor jobs, the combination of
DUE OUT criteria will not be satisfied (i.e., a job is DUE OUT before it can be submitted or
finish executing), or a high priority job will be delayed because of a low priority predecessor.
To handle these cases, the operator can request automatic adjustment of DUE OUT and/or
PRIORITY values of all jobs. In addition, the operator can refresh logical dependencies for all
job orders in the Active Jobs file and update the Job Dependency Network file (GRF).
To refresh DUE OUT times, issue the command:
F CONTROLM,DEADLINE
To refresh PRIORITY values, issue the command:
F CONTROLM,PROP
To refresh the list of dependent jobs in the Job Dependency Network file, issue the
command:
F CONTROLM,NET
The following command performs all the processes described above (DEADLINE, PROP
and NET) simultaneously in the CONTROL-M monitor.
F CONTROLM,REFALL
Note The commands listed above (DEADLINE, PROP, NET and REFALL) perform the
same functions as command REFRESH of the Job Dependency Network screen
(described in Section 2 of the CONTROL-M User Manual).
Shift DUE OUT Times for CONTROL-M Jobs
If SHOUT WHEN LATE * is specified in a CONTROL-M job scheduling definition, a
message is issued if the job does not finish executing by the specified DUE OUT time.
A large number of such messages may be issued if CONTROL-M is brought up after it (or
MVS) was down for a significant amount of time.
These messages can be avoided by shifting the DUE OUT time forward an appropriate
amount of time (e.g., if CONTROL-M was down for two hours, shift the DUE OUT time 120
minutes forward).
Use the following operator command to shift the DUE OUT time:
F CONTROLM,SDOUT=+nnn
where:
nnn is the number of minutes to shift the DUE OUT time. From 1 to 999 minutes can be
specified.
To shift the DUE OUT time backward (e.g., to undo the SDOUT=+nnn command), use the
following operator command:
F CONTROLM,SDOUT=-nnn
where:
nnn is the number of minutes to shift the DUE OUT time.
Note Jobs with a HELD status are not shifted by the SDOUT operator command.
Sending a Jobs SYSDATA to a Held Output Class
CONTROL-M analyzes job execution results by reading the jobs sysout. Therefore, the
SYSDATA
1
portion of the job must be sent to a held output class to prevent it from being
printed accidentally before the CONTROL-M monitor manages to read it.
HLDCLAS is the automatic held output class to which CONTROL-M sends the jobs
SYSDATA output.
When a job is submitted by CONTROL-M, CONTROL-M either adds a MSGCLASS
parameter to the job card or overrides the existing MSGCLASS parameter. The sysout is
directed to the class designated in the HLDCLAS installation parameter. (A regular
automatic held output class must be specified during installation.)
Note If JOB2 with no specified MSGCLASS is submitted by JOB1, JOB2 inherits the
MSGCLASS of JOB1.
If JOB1 was submitted by CONTROL-M, its MSGCLASS is replaced with the class specified
in parameter HLDCLAS. As a result, JOB2 is assigned the HLDCLAS class as well.
1
SYSDATA is an IOA term used to designate the data in the following job sysout datasets: job log (console
messages), expanded JCL, and system output messages
Special precautions should be taken so that the jobs sysout is not accidentally purged or
released for printing. In some installations, all jobs in the automatic held class are purged
by an operator command at least once a day. To prevent deletion before CONTROL-M
reads the jobs sysout, the following procedure can be used:
A special automatic held output class is dedicated to CONTROL-M.
The sysouts in this class are protected from any change (e.g., by SDSF exits).
This procedure ensures that CONTROL-M will be able to read the sysout.
If other users are to access the sysout, the following sample parameters should be defined
in any job production parameters definition:
ON PGMSTEP ANYSTEP CODES *****
DO SYSOUT OPT C PRM A FRM X
When CONTROL-M finishes reading the jobs sysout, it transfers the sysout to the
designated output class where any user can access it.
Special care should be taken when a system programmer formats the JES queue. This
procedure usually involves unloading the output queues to a tape, formatting the spool and
then reloading the queues. The monitor should be shut down before the queue is unloaded
to a tape and brought up again only after the queues have been loaded from the tape back
to the spool. If this procedure is not followed, CONTROL-M can assume that the job is lost
(purged by an operator) and act accordingly.
When you change the HLDCLAS parameter after CONTROL-M installation, you should
also change the class in DD statement INTRDR of the CONTROL-M monitor and of JCL
procedures CTMAESIM and CTMTAPUL.
Accumulating Job Execution Statistics
CONTROL-M allows accumulation of job execution information via its Statistics file. The
accumulated information can then easily be viewed via option S in the Status screen.
CONTROL-M manages statistical information for the most recent job runs that ended OK
(up to a maximum of 20). In a multi-CPU environment, CONTROL-M keeps this
information for each CPU (SMF ID) in which the job executes.
The Statistics file is updated by CONTROL-M utility CTMJSA. For more information
about this utility, see Section 9 in this guide.
It is strongly recommended that you include this utility in the New Day procedure. It
should be executed before executing the User Daily(ies). This ensures that production jobs
always use the most up-to-date information.
In addition to viewing statistical information online, a number of optional facilities can be
employed. These optional facilities can significantly enhance production flow and
management. These facilities all rely on the information accumulated in the Statistics file.
After proper management of the Statistics file is implemented, information in the file can
be effectively used for the following reports and facilities:
Simulation and Forecasting
Dataset Job Cross-reference
Automatic Tape Drive Resource Adjustment
Deadline Scheduling
Enterprise Controlstation Live Simulation
Note Set parameter STAT to Y in member CTMPARM if statistics-related facilities are to be used.
Expanding CONTROL-M Files
Follow the steps below to expand CONTROL-M files.
Expanding the Active Jobs File (CKP)
To increase the size of the Active Jobs file, see the topic Changing the Size of the Active
Jobs File in utility CTMCAJF in Section 9 of this guide.
Expanding the CONTROL-M Jobs Dependency Network File (GRF)
1. Shut down the monitor via the following operator command:
P CONTROLM
2. Rename the old GRF file.
3. Edit member FORMGRF in the IOA INSTCTM library, change parameter SIZE to the new
requested size and submit the job. This job will allocate and format a new GRF file.
4. Start the monitor via the following operator command:
S CONTROLM
5. Once the monitor is up, issue a modify command to re-calculate files dependency:
F CONTROLM,NET
Expanding the CONTROL-M Statistics File (STAT)
1. Shut down the monitor via the following operator command:
P CONTROLM
2. Rename the old STAT file.
3. Edit member DEFSTAT in the IOA INSTCTM library. Change parameter cylinders to
the new requested size CI size.
4. Submit job FORMSTT in the INSTCTM library.
5. Copy the old STAT file into the new file using IDCAMS REPRO.
6. Start the monitor via the following operator command:
S CONTROLM
Expanding the IOA Manual Conditions File (NRS)
To increase the size of the IOA Manual Conditions file, see the topic Expanding the IOA
Manual Conditions File (NRS) in Section 2 of this guide.
CDAM Files
CONTROL-M attempts to use the unused space on Compressed Data Access Method
(CDAM) files. Therefore, the unused space on CDAM files must not be released by any
product which releases unused space (e.g., products which perform disk defragmentation).
If CDAM files are allocated on SMS volumes, these volumes must be defined with
PARTIAL RELEASE=NO.
Display CONTROL-M Installation Parameters
CONTROL-M installation parameters contain general information about your system.
To display the values of some of the more important parameters, issue the following
operator command:
F CONTROLM,SHOWPARM
The parameters and their values are displayed on your console and written to the
SYSDATA of the CONTROL-M started task.
Switching from SAPI to PSO support
SAPI is IBMs new SYSOUT processing utility. It is the default SYSOUT processing utility
for CONTROL-M when CONTROL-M is operating under OS/390 version 1.3 and higher.
However, CONTROL-M continues to maintain support for PSO.
If you encounter a problem associated with job post-processing (e.g., jobs not properly
identified, unpredictable errors), you can switch from SAPI support to PSO support.
To switch from SAPI support to PSO support, specify operator command:
F CONTROLM,SAPI=NO
To switch to SAPI support from PSO support, specify operator command:
F CONTROLM,SAPI=YES
For more information about post-processing, see Automated Job Post-Processing in
Section 1 of the CONTROL-M User Manual.
CONTROL-M has an internal Trace facility which can print internal tracing records and
the contents of internal data areas. Under normal circumstances, the Trace facility is
dormant. However, if required (i.e., your IOA representative has requested tracing
information), the Trace facility can be activated.
To use the CONTROL-M internal Trace facility, issue the following operator command:
F CONTROLM,TRACE=level
where:
level Trace level(s) to be activated/deactivated. The CONTROL-M Trace facility
has 128 levels (i.e., 1-128). Any number of these levels can be on at a given
time. Valid values are:
x Trace level to turn on
Example: TRACE=3 turns on trace level 3.
-x Trace level to turn off
Example: TRACE=-3 turns off trace level 3.
(x:y) Range of trace levels to turn on, where x is the first level in the
range and y is the last level in the range.
Example: TRACE=(1:10) turns on trace levels 1 through 10.
(-x:-y) Range of trace levels to turn off, where x is the first level in the
range and y is the last level in the range.
Example: TRACE=(-1:-10) turns off trace levels 1 through 10.
(x,y,z,...) Multiple trace levels to turn on.
Example: TRACE=(3,5,29) turns on trace levels 3, 5 and 29.
(-x,-y,-z,...) Multiple trace levels to turn off.
Example: TRACE=(-3,-5,-29) turns off trace levels 3, 5 and 29.
SHOW Shows the current status of all trace levels.
Tracing information is written to one or more of the following locations, depending on
which trace levels were turned on:
DD statement PRTDBG of the CONTROL-M procedure.
DD statement DADUMP of the CONTROL-M procedure.
SYSDATA of the CONTROL-M started task.
When you finish performing the problem determination procedures, use the following
operator command to turn off all trace levels:
F CONTROLM,TRACE=(-1:-128)
Job Ordering via New Day Processing
Overview
The CONTROL-M monitor is usually activated as a started task and remains active 24
hours a day. At a set time each day (defined via installation parameters), New Day
processing is performed by the CONTROL-M monitor.
New Day processing consists of both automatic cleanup from the previous days job
ordering and automatic ordering of jobs for the New Day.
The main components related to New Day processing are:
Scheduling tables and job scheduling definitions.
New Day procedure and User Daily jobs.
Date Control records.
Active Jobs file.
New Day processing is completely automated through the use of the New Day procedure
2
and User Daily jobs. The main purpose of the New Day procedure and User Daily jobs is to
call programs that:
Scan scheduling tables to select jobs for scheduling.
Schedule the selected jobs (i.e., place copies of the selected job scheduling definitions as
job orders in the Active Jobs file).
The New Day procedure and each User Daily job must have its own Date Control record. A Date
Control record is a member in the CONTROL-M PARM library in which relevant date information
is placed during New Day processing. This date information is used to manage job orders.
2
Called the General Daily prior to IOA Release 5.0.0.
Selection of jobs is based on the Date Control record, the current date and the Basic
Scheduling parameters of the jobs in the scheduling tables. Any time the User Daily job is
run, the current working date is placed in the Date Control record. The Basic Scheduling
parameters of each job in the scheduling table are checked against this date to see if the
job should be placed in the Active Jobs file.
New Day processing generally works as follows:
The New Day procedure is performed each day at its predefined time. The New Day procedure:
Schedules User Daily jobs.
Schedules maintenance jobs. These jobs call programs which perform cleanup after
the previous days processing.
Notes If a cyclic job is executing at the time the New Day procedure is run, the New Day
procedure changes the job to a non-cyclic job and handles the job accordingly.
If a job which was not submitted on its original scheduling date contains a >
specification in its TIME UNTIL field, when the New Day procedure is next run, the
procedure deletes the > and TIME FROM specification from the job order, making the
job immediately eligible for execution.
If CONTROL-R is installed and the History Jobs file is active, jobs deleted from the
Active Jobs file during cleanup can be placed in the History Jobs file.
User Daily jobs (scheduled by the New Day procedure) select and schedule all other
jobs for that day.
Sample New Day Processing
CONTROL-M is supplied with samples of several of the above mentioned components.
To effectively implement New Day processing at your site, you should first understand how
the sample components operate. Once the operation of the sample components is
understood, you can then customize New Day processing based on site requirements.
Sample New Day processing components are described below.
Sample Components Provided With CONTROL-M
At time of installation, each site is provided with the following:
New Day Procedure
A single New Day procedure is provided. Its default name is CONTDAY (the name can
be changed). This procedure should have wide authorization for accessing scheduling
tables and jobs.
User Daily Jobs
The following sample User Daily jobs are provided:
DAILYPRD Contains sample JCL for scheduling production jobs.
DAILYSYS Contains sample JCL for scheduling system jobs.
These sample User Daily jobs are defined in table MAINDAY in the SCHEDULE
Library. These jobs activate User Daily procedure CTMDAILY which is responsible for
ordering the production jobs.
It is generally advisable to use these sample User Daily jobs to create separate User
Daily jobs according to department (or other functional entity) and according to
authorization. This is described later in this section.
Maintenance Jobs
The following maintenance jobs are provided:
CTMCLRES Activates utility IOACLRES which cleans the IOA
Note IOACLRES does not delete conditions with a date reference of
STAT.
CTMLDNRS Activates utility IOALDNRS which creates and loads the Manual
Conditions file. (This utility is normally run after all User Daily jobs
have executed.)
These maintenance jobs are defined in table MAINDAY in the SCHEDULE library.
Utilities IOALDNRS and IOACLRES are described in Section 9 of this guide.
Scheduling Table: MAINDAY
A scheduling table called MAINDAY is provided in the SCHEDULE library. This table
contains User Daily jobs DAILYSYS and DAILYPRD and maintenance jobs
CTMCLRES and CTMLDNRS.
Date Control Records
The following Date Control records (members) are supplied in the CONTROL-M PARM
library:
DATEREC Defined for New Day procedure CONTDAY.
DATERECU Sample Date Control record for User Daily jobs.
Called Programs
The New Day procedure and User Daily jobs call programs which perform various steps
of New Day processing (checking the Date Control record, selecting job orders, etc.).
These programs are described in Programs Called During New Day Processing later
in this section.
How the Sample Components Perform New Day Processing
New Day processing performed with the sample components works as follows:
During New Day processing, the New Day procedure accesses its Date Control record,
scans table MAINDAY and selects and loads the maintenance jobs and User Daily jobs to
the Active Jobs file.
The User Daily and maintenance jobs placed in the Active Jobs file are submitted by
CONTROL-M according to their runtime scheduling criteria. When a User Daily job is
executed, it accesses its own Date Control record, scans the scheduling tables defined to it,
selects jobs and places the selected job orders in the Active Jobs file. (User Daily jobs can
also schedule maintenance jobs as required.)
Because User Dailies are jobs, their use is not restricted to New Day processing. Although
User Daily jobs are normally executed immediately after they are ordered by the New Day
procedure, they can be executed at any time defined in their Runtime Scheduling
parameters. Furthermore, they can be ordered at any time by any of the methods described
in Alternative Methods of Job Ordering in Section 6 of the CONTROL-M User Manual.
Date Control Records and Enhanced Daily Checkpointing
A Date Control record must be defined for each User Daily job. This record is usually
defined by the IOA administrator.
The Date Control record for User Daily jobs consists of six fields. At different stages in
New Day processing (i.e., before or after the execution of specific called programs which
perform New Day processing), the current original scheduling date is placed in one of these
date fields.
This enables CONTROL-M to manage the process of job ordering. Furthermore, if New Day
processing is interrupted at any point, the values in these fields can indicate which called
program was in use when the interruption occurred.
If the interruption occurred during job ordering, it is also desirable to identify the last job
ordered so that ordering can continue from that point to enable automatic rerun of the job
ordering process. An optional second record in the Date Control member, the Enhanced
Daily Checkpoint record, enables this identification.
The Enhanced Daily Checkpoint record contains fields which store information about the
last ordered job: JCL member name, internal sequence number, order ID and the group to
which the job belongs:
If Enhanced Daily Checkpointing is implemented, this information pinpoints
( identifies) from where job ordering left off and job ordering continues from that point
during recovery.
If Enhanced Daily Checkpointing is not implemented, when the User Daily is rerun, all
jobs in the scheduling table are considered for scheduling (including those jobs already
scheduled by the interrupted run).
If the job belongs to a group, the recovery procedure will again order the entire group.
The original group entity remains in the Active Jobs file, together with the jobs that
were ordered prior to abnormal termination. However, the status of the original group
entity is set to HELD WAIT SCHEDULE to prevent the jobs in that group from being
submitted. Changing the status of the original group entity via the Online facility is
blocked.
Before the ordering process starts, the program checks if the checkpoint fields in Record 2
are blank.
If the checkpoint fields are blank, the User Daily job continues normal processing. Before
each job is ordered, the fields in Record 2 are updated (overwritten) with information
identifying the current job being ordered. Only upon successful completion of the User
Daily job is the information in the checkpoint fields erased.
If the checkpoint fields are not blank, the recovery procedure is activated.
Recovery Procedure
The program passes over the jobs in the input tables, counting the jobs and comparing the
count to the value in the SERIAL_NO field, until the count and serial number match.
The matching job is selected.
The program then compares the values in the JOB and GROUP fields to the values
belonging to the selected job. If the fields do not match, error message CTMD67S is issued
and processing terminates.
If the fields match, the program checks the Active Jobs file for a job with an order ID
matching the order ID recorded in Record 2. If the match is found, an additional check
is performed to verify that the jobs MEMNAME and GROUP values match the
checkpoint JOB and GROUP values.
If the Active Jobs file already contains the job, the job is not ordered again and the
program switches to normal processing starting with the next job.
If the Active Jobs file does not contain the job, the job is ordered. The program then
switches to normal processing.
Both the Date Control record and the Enhanced Daily Checkpoint record have a fixed
format, discussed below in Implementing New Day Processing.
Note If input scheduling tables are modified prior to rerunning User Daily jobs (or the New
Day procedure), the checkpointed job and internal sequence number might not match.
In this case, rerun of the User Daily job(s) is terminated and manual intervention is
required.
Implementing New Day Processing
As indicated earlier, sample User Daily jobs DAILYSYS and DAILYPRD are supplied with
CONTROL-M in scheduling table MAINDAY.
In theory, it is not necessary to use User Daily jobs. It is possible (but not recommended) to
place all job scheduling definitions in one or more tables and have them scheduled by the
New Day procedure. It is also possible (and also not recommended) to maintain only the
two sample User Daily jobs provided with CONTROL-M and to order all user jobs through
the User Daily DAILYPRD.
The recommended method to automate the production environment via New Day
Processing is by:
Defining a different scheduling table for each group of related jobs.
Defining a different User Daily job for each department, application or comparable
entity.
This method provides the following advantages:
Improved performance Many User Daily jobs running in parallel can order the full
days production jobs in significantly less time than it would
take one User Daily to order all jobs one at a time.
Ease of administration The IOA administrator can make each department
responsible for its own User Daily job(s) and scheduling
table(s) and for controlling its own job ordering.
Increased security While maintaining exclusive authorization for the New Day
procedure, the IOA administrator can limit each departments
authorization to its own User Daily jobs.
Minimization of problems Problems encountered in one User Daily do not necessarily
affect the job ordering of other User Daily jobs.
Differences Between the New Day Procedure and User Daily Jobs
The New Day procedure uses the program list in member PROGUSR. User Daily jobs use
the program list in member PROGDAYM.
The New Day procedure uses Date Control record DATEREC (which contains the last
Active Jobs file format date in columns 60-65). User Daily jobs use Date Control record
DATERECU (which contains blanks in columns 60-65). Using the wrong Date Control
record causes message CTM916W to be generated.
User Daily jobs can be run manually (i.e., not initiated by the CONTROL-M monitor.) The
New Day procedure should be initiated by the CONTROL-M monitor. If an attempt is
made to run the New Day procedure manually, problems may be caused by failure of the
CONTROL-M monitor to free the Active Jobs file for use by the New Day procedure.
Implementation Tasks
It is recommended that the following tasks (described below) be performed when
implementing New Day processing:
Decide which User Daily jobs are needed (and for which tables)
Use Program CTMFRM to Delete Old Prerequisite Conditions
Use the sample JCL to create JCL for each User Daily job
Create User Daily job scheduling definitions and customize table MAINDAY
Decide whether or not Enhanced Daily Checkpointing will be used
Create Date Control records
Notes Date Control records cannot be contained in a PDSE-type library.
The New Day procedure and its accompanying Date Control record are defined at time
of installation. They require no further implementation.
Ensure subsequent runs of utility IOALDNRS if necessary
Decide Which User Daily Jobs Are Needed (and for Which Tables)
A job scheduling definition is defined for each job and each job scheduling definition is
placed within a scheduling table. Usually, related job scheduling definitions are grouped
into their own scheduling table.
Based on the scheduling tables defined at your site, and the jobs they contain, decide what
User Daily jobs you require, and which scheduling tables each User Daily job will scan.
Use Program CTMFRM to Delete Old Prerequisite Conditions
If old prerequisite conditions are not deleted from the IOA Conditions/Resources file, jobs
can be incorrectly triggered by prerequisite conditions with the same date reference from
the previous year. To prevent this problem, program CTMFRM is activated as part of the
New Day procedure. Program CTMFRM erases from the IOA Conditions/Resources file all
prerequisite conditions from the previous year which have the same date reference as the
forthcoming execution date.
SELECT/IGNORE Statements
Often, prerequisite conditions which are not date-related (e.g., IMS-IS-UP, AR-FILE-OK).
must not be erased. A list of jobs/conditions which are not to be erased can be supplied via
DD statement DAFRMIN.
SELECT/IGNORE statements identify jobs/conditions which should or should not be deleted.
One or more parameters can be specified in any SELECT/IGNORE statement (in any
order). These parameters (GROUP, JOBNAME, MEMBER, STATUS, FROM and TO) are
documented under the topic SELECT/IGNORE Statements in the description of utility
CTMCAJF in Section 9 of this guide.
Notes A job specified for deletion via a SELECT statement will be deleted unconditionally
even if the job is currently executing.
Conditions that are not date-related can be defined with a date reference of STAT
which eliminates the need for including SELECT/IGNORE statements in procedure
CONTDAY.
When a Group entity is marked for deletion, it is not physically deleted from the Active
Jobs file until the following days New Day process. For more information about Group
entities, see Handling Job Groups in Section 2 of the CONTROL-M User Manual.
Example 1
To suppress the erasure of the next days conditions by the New Day procedure, specify one
definition:
IGNORE COND *
When suppressing the function, remember to delete conditions (via utility CTMCLRES).
If this is not done, jobs in the next years schedule will be triggered because of todays
conditions.
Example 2
IGNORE JOBNAME OPER*
IGNORE JOBNAME PROD* STATUS ENDNOTOK
SELECT GROUP TEST
In this example, no jobs whose names begin with prefix OPER are deleted. Also no jobs
whose names begin with prefix PROD that ended NOTOK are deleted. Of the remaining
jobs, those belonging to group TEST are deleted. In addition, the default action is also
taken. All jobs which ended OK and all jobs whose MAXWAIT interval is exceeded are also
deleted even though they are not part of group TEST.
Example 3
IGNORE STATUS ACTIVE
SELECT JOB OPER*
In this example, jobs whose names begin with prefix OPER are deleted if they are in
WAITSCHED, ENDOK or ENDNOTOK status (i.e., jobs whose status is ACTIVE are not
deleted). In addition, the default action is also taken. All jobs which ended OK and all jobs
whose MAXWAIT interval is exceeded are also deleted even though they do not begin with
prefix OPER.
AutoEdit variables and functions are supported in the SELECT/IGNORE statements. See
Specifying AutoEdit Variables and Functions in utility CTMCAJF in Section 9 of this guide.
Use the Sample JCL to Create JCL for Each User Daily Job
Create the JCL for each User Daily job by selecting one of the alternative methods of
identifying scheduling tables (below) and customizing the JCL accordingly.
Method 1 DSN=sched_library(table)
This method requires that the user specify the name of a scheduling table and library
directly in the JCL.
//DAILY EXEC CTMDAILY
//DACHK DD DISP=SHR,DSN=parm_lib(date_control_record)
//DAJOB DD DISP=SHR,DSN=sched_library(table1)
// DD DISP=SHR,DSN=sched_library(table2)
// DD DISP=SHR,DSN=sched_library(table3)
Method 2 DSN=parm_library(member)
//DAILY EXEC CTMDAILY
//DACHK DD DISP=SHR,DSN=parm_lib(date_control_record)
//DAJOB DD DISP=SHR,DSN=parm_library(member)
This method requires that the user specify a parm_library and member containing
ORDER requests which identify scheduling libraries, scheduling tables and jobs to
schedule and/or in-stream ORDER requests following //DAJOB DD *
Method 2 provides the following advantages over Method 1:
Changes required can be made to the member in the parm_library without changing
the JCL of the User Daily job.
Individual jobs can be specified.
When using Method 2, specify at least one ORDER statement and, optionally,
SELECT/IGNORE statements.
The Date Control record is referenced by DD statement DACHK.
See utility CTMJOB in Section 6 of the CONTROL-M User Manual for the syntax,
parameter descriptions and functionality of the ORDER, SELECT and IGNORE
statements.
Create User Daily Job Scheduling Definitions and Customize Table MAINDAY
The supplied sample User Daily jobs, DAILYPRD and DAILYSYS, scan the scheduling
tables referenced by DD statement DAJOB. However, different authorization is granted to
each of these User Daily jobs.
Use these sample User Daily jobs to create a User Daily job for each department in table
MAINDAY. Assign the authorizations accordingly. Each User Daily job should scan a
different set of scheduling tables than the other User Daily jobs.
It is common in many sites for the IOA administrator to create a customized User Daily job
for each department and then turn the scheduling table over to the control of the
department. The department can then modify the scheduling table (and job scheduling
definitions) as necessary.
Although User Daily jobs can execute immediately after the jobs have been placed in the
Active Jobs file, a site may choose to delay execution of a User Daily. To delay the
submission of a User Daily, the User Dailys runtime scheduling criteria should be defined
accordingly.
Note If groups of User Daily jobs are executed at different times, IOALDNRS should be run
again after each group of User Daily jobs is run.
Additional maintenance jobs can be added to table MAINDAY as necessary.
Decide Whether or Not Enhanced Daily Checkpointing Will Be Used
Enhanced Daily Checkpointing enables automatic rerun of the job ordering process to
resume from the unsuccessfully ordered job, if New Day processing terminates during job
ordering (due to system crash, etc.).
The decision of whether or not to implement Enhanced Daily Checkpointing can be made
separately for each User Daily job (i.e., the same decision does not have to be made for all
User Daily jobs).
Implementation of Enhanced Daily Checkpointing requires definition of a second date
control record in the Date Control record member. (The format of this record is described
below in Create Date Control records.) This second record stores information which
identifies jobs already ordered to the Active Jobs file. This, in turn, allows New Day
processing to continue ordering jobs without redundancy.
Create Date Control Records
Date Control records are members in the CONTROL-M PARM library. A different Date
Control record must be defined for each User Daily job. It is usually defined only once for
each job and from then on it is usually updated by the User Daily job.
If Enhanced Daily Checkpointing is implemented, a second Date Control record must be
defined for each User Daily job.
The length of the User Daily Date Control record is 80 characters. The format of the dates
in the record is mmddyy, ddmmyy or yymmdd, depending on the site standard.
The following chart shows the format of the Date Control record and indicates when the
User Daily adds the original scheduling date values to the fields in the record:
Column Value Added Description
01-06 date1 User Daily adds the ODATE before the User Daily
procedure is begun.
18-23 date2 User Daily adds the ODATE before the job
ordering process begins for jobs being scheduled
based on DATES, DAYS and/or DCAL parameters.
25-30 date3 User Daily adds the ODATE after the job ordering
process ends for jobs being scheduled based on
DATES, DAYS and/or DCAL parameters.
43-48 date4 User Daily adds the ODATE before the job
ordering process begins for jobs being scheduled
based on WDAYS and/or WCAL parameters.
50-55 date5 User Daily adds the ODATE after the job ordering
process ends for jobs being scheduled based on
WDAYS and/or WCAL parameters.
60-65 blank
(date7)
In the User Daily Date Control records, these
columns are blank.
In the New Day procedure Date Control record,
these columns are the last formatting date, date7,
of the Active Jobs file (used by program
CTMFRM). This field prevents formatting from
being carried out twice on the same day. When
this date is in a record, program CTMCHK
recognizes the record as a New Day procedure
Date Control record. If there are any problems
concerning the date, the program presents the
operator with a series of prompts.
67-72 date6 User Daily adds the ODATE upon completion of all
processing.
The format of the second Date Control record, which is required only if Enhanced Daily
Checkpointing is used, is shown below.
Column
Constant or
Value Added Description
01-04 JOB= Constant.
05-12 blank In this area, CONTROL-M stores the MEMNAME
value of the last ordered job.
13-23 ,SERIAL_NO= Constant (note the comma before the S).
24-28 blank In this area, CONTROL-M stores its internal
sequence number of the last ordered job.
29-37 ,ORDERID= Constant (note the comma before the O).
38-42 blank In this area, CONTROL-M stores the order ID of
the last ordered job.
43-49 ,GROUP= Constant (note the comma before the G).
50-69 blank In this area, CONTROL-M stores the group name
of the last ordered job.
When creating this record, the user should:
Specify the indicated constants (e.g., JOB=) in the appropriate columns.
Leave blank the columns indicated as blank. These columns are filled in by the User
Daily during processing.
Ensure Subsequent Runs of Utility IOALDNRS if Necessary
If all User Daily jobs are scheduled to run in parallel, utility IOALDNRS only needs to run
once, after the User Daily jobs have finished execution. However, if User Daily jobs are
executed at various times during the day, utility IOALDNRS should run after each group
of User Daily jobs is executed. This can be ensured by having each group of User Daily jobs
set the appropriate prerequisite conditions to ensure the execution of IOALDNRS.
Programs Called During New Day Processing
The most important programs in New Day processing are CTMILY and CTMILU.
The New Day procedure executes program CTMILY.
Each User Daily calls procedure CTMDAILY which executes program CTMILU.
Programs CTMILY and CTMILU both execute other programs which implement New Day
processing. The programs called by CTMILY and CTMILU are listed in the table below.
Both CTMILY and CTMILU read the member referenced by DD statement DAPROG and
activate the programs listed in the member.
The format for each record in the program list is:
Columns
01-08 Program name.
10-11 Maximum return code allowable in the preceding program. If a higher
return code is encountered in the preceding program, the current
program is not executed.
13-72 Program arguments.
The programs called by program CTMILY (the New Day procedure) and by program
CTMILU (User Daily jobs) are shown in the following chart:
Called By:
Program CTMILY CTMILU Purpose
CTMCHK
[ [
Checks the current date and its relation to the
Date Control record (see below). When called by
CTMILY, the program always asks the computer
operator to verify that CONTROL-M is activated
on the correct date. When called by CTMILU,
the program asks the computer operator to verify
that CONTROL-M is activated on the correct
date only if value CONFIRM is specified as the
argument (anywhere within columns 13-72).
Called By:
CTMFRM
[
Reformats the CONTROL-M Active Jobs file and
the IOA Conditions/Resources file:
CONTROL-M Active Jobs File
By default (i.e., if no SELECT/IGNORE
statements are specified), the following jobs are
erased from the Active Jobs file and the file is
compressed:
Jobs which have already executed and ended OK
(regardless of parameter MAXWAIT).
Job whose MAXWAIT parameter has been
exceeded.
Emergency jobs which are not needed.
Jobs for which MAXWAIT=99 is specified are not
automatically erased from the Active Jobs file.
(See SELECT/IGNORE Statements above for
more information.)
IOA Conditions/Resources File
This program erases all prerequisite conditions of
the coming execution date.
(Prerequisite conditions should not be kept in the
IOA Conditions/Resources file for more than one
year. Otherwise, jobs may be submitted for
execution due to prerequisite conditions set on
the same date in the preceding year.)
At start of execution, this program creates a
backup copy of the Active Jobs file for recovery
purposes (BKP file).
CTMEDA
[
Signals to the CONTROL-M monitor that the
Active Jobs file was successfully formatted.
CTMJOB
[ [
Places job orders in the Active Jobs file according
to the date in the Date Control record and the
data in the scheduling table(s) supplied.
CTMPDA
[ [
Marks the end of the Daily run.
If CONTROL-R is installed and the History Jobs file is active, program CTMFRM is run
again via CTMILY, this time against the History Jobs file:
Called By:
CTMFRM
[
Compresses the CONTROL-M History Jobs file
by removing jobs whose retention criteria
(RETENTION # OF DAYS/GENERATIONS TO
KEEP) are no longer satisfied.
If CONTROL-R is installed, step DELARCH is run after the conclusion of program
CTMILY. This step runs the following:
Called By:
CTMDAS
[
Deletes archived SYSDATA of jobs that were
deleted from the Active Jobs file by program
CTMFRM.
Use of the Date Control Record by User Daily Jobs
The work flow of User Daily jobs is dependent on the Date Control record. The main steps
of a User Daily job are:
Checking the last running date of the User Daily job (via internal program CTMCHK).
The first date in the Date Control record (column 1-6) is compared to the current
working date (at the time of the run).
If they match, the User Daily job has already run today. An appropriate message is
issued and the condition code is set to 0004.
If the current working date is earlier than the first date of the Date Control record,
a User Daily job run has been attempted before its time. The User Daily job stops
executing and notifies the user accordingly.
If the current working date is later than the first date of the Date Control record
(the normal situation), the first date of the Date Control record (columns 1-6) is
updated to the current working date. This date is then used as the current
scheduling date.
If the User Daily job did not run for more than one day, a warning message is issued
and the User Daily job tries to schedule the jobs for all of the days which have passed
since the last scheduling date (according to the production parameters). However, if the
program list record for program CTMCHK contains the program argument CONFIRM,
then the User Daily will issue the following WTOR messages:
CTM426W job-name "DAILY" DID NOT RUN FOR nnnnnn DAYS
CTM427W IS IT TRUE? (ANSWER "YES" OR "NO")
CTM428W YOUR ANSWER IS:
See New Day Procedure Flow below for a discussion about operator responses to these
messages.
The New Day procedure asks the operator a series of questions regarding the current
system date (see New Day Procedure Flow, below). This verifies that an incorrect date
was not inadvertently entered during the IPL process.
Placing job orders in the Active Jobs file according to the current scheduling date and
the last running date (via utility CTMJOB).
There are two methods for placing job orders in the Active Jobs file via utility
CTMJOB. Both methods are described under the topic Use the Sample JCL to Create
JCL for Each User Daily Job earlier in this section.
For each job, the program checks whether the job should be scheduled on one or all of
the days that have passed since the last original scheduling date (date3 or date5) until
the working date in the record (date1). If the job should be scheduled, a job order is
placed in the Active Jobs file.
When the program finishes processing the user scheduling tables(s), the finish
indicator dates (date3 and date5) are updated to the working date (date1) calculated by
program CTMCHK.
Before program CTMJOB starts operating, it compares date2 with date3 (and date4
with date5). If they do not match, a previous run of program CTMJOB of the same User
Daily job has probably abended. The user is notified and the program terminates. To
correct the error, adjust the date values in the user Date Control record (using a
standard editor).
Note When manually modifying the Date Control record, make sure that jobs are not
scheduled to run twice on the same day.
Indicating that the User Daily job has ended (via program CTMPDA).
Program CTMPDA updates the finish indicator date (date6) by setting it to the value of
the running date (date1). This indicates that the User Daily job finished successfully.
Rerunning the User Daily job after a failure.
See Date Control Records and Enhanced Daily Checkpointing earlier in this section.
New Day Procedure Flow
Once a day, at a time set by the IOA administrator, the CONTROL-M monitor begins New
Day processing by going into a suspended state and issuing the following messages (the
first is a highlighted, unrollable message):
CTM113I CONTROL-M MONITOR monitor NEW DAY PROCESSING STARTED
CTML00I CONTROL-M MONITOR monitor PROCESSING SUSPENDED
CTML07W CONTROL-M MONITOR monitor WAITING FOR NEW DAY PROCEDURE
Shortly after that last message is issued, started task CONTDAY (the New Day procedure)
is automatically activated.
When CONTDAY finishes executing without any problems, the following messages are
issued and the CONTROL-M monitor ends its suspended state and resumes processing:
CTML01I CONTROL-M MONITOR monitor PROCESSING RESUMED
CTML02I CONTROL-M MONITOR monitor NEW DAY PROCESSING COMPLETE
If a problem occurs during CONTDAY processing, the CONTROL-M monitor prompts
the operator for an appropriate response via the following messages:
CTML05W NEW DAY PROCESSING ERROR DETECTED
CTML06W REPLY "R" FOR RETRY OR "E" FOR END
The operator should try to correct the problem and request that CONTROL-M retry
New Day processing. Halting New Day processing (option E) should only be requested if
the problem cannot be corrected.
During New Day processing, CONTDAY checks the system date and time against what
it expects to find in the CONTROL-M control files. If for some reason they do not
match, the operator is prompted with the following messages:
CTM426W GENERAL "DAILY" DID NOT RUN FOR nnnnnn DAYS
CTM427W IS IT TRUE? (ANSWER "YES" OR "NO")
CTM428W YOUR ANSWER IS:
If this situation occurs after the computer has not been working for a few days (e.g., a
hardware failure or holiday), your response should be YES. If this is not the case, the
computer probably was IPLed with the wrong date. Your response should be NO and
the system date should be checked and corrected. Then restart CONTDAY. If the date
was correct, the IOA administrator should check the cause of the problem.
Notes To rerun User daily jobs from the beginning (after a failure), all dates (1-6) must
restored to their previous value before attempting the rerun.
If the CONTROL-M monitor has been down for more than 28 days, the previous
working date (i.e., the current working date minus 1) should be manually specified as
values for date1-date6.
Considerations for Job Ordering and Submission
Library Compression
If a job is ordered or submitted while certain libraries are being compressed, the member
may not be found or the wrong job may be submitted. To avoid this problem, compress a
library only when CONTROL-M is down, or no jobs contained in or referencing the library
are being submitted. The following libraries are relevant to this issue:
The JCL library
CONTROL-M job scheduling libraries
IOA calendar libraries
JCL Parameter MSGLEVEL
Output of a CONTROL-M job is written to the CONTROL-M SYSDATA only if a
MSGLEVEL of (1,1) is specified. If optional wish WM0735 is applied at your site and no
MSGLEVEL, or a MSGLEVEL other than (1,1) is specified, CONTROL-M automatically
changes the MSGLEVEL to (1,1).
Comment Lines Added During Job Submission
CONTROL-M adds three comment lines to the JCL output of each job executed via
CONTROL-M:
//*---- SUBMITTED BY CONTROL-M (FROM lib)
//*--SCHED FROM schedlib(sched-table)
//*--JCL FORM jcllib(jclmembr)
where:
lib MEMLIB or OVERLIB
schedlib Scheduling library from which the job was ordered.
sched-table Scheduling table from which the job was ordered.
jcllib JCL library from which the job was submitted.
jclmembr JCL member from which the job was submitted.
Notes If CONTROL-M is upgraded to release 5.1.4, the Active Jobs file will indicate that the
scheduling library, scheduling table, JCL library and JCL member are unknown for
jobs ordered before the upgrade.
The JCL output for jobs that use utility CTMBLT with immediate ordering will also
indicate that the value for these fields is unknown.
End User Job Order Interface Defining Job Lists for Each
User
When an end user orders jobs via the End User Job Order Interface utility, the list of jobs
which that end user may order is displayed. (See End User Job Order Interface in Section
2 of the CONTROL-M User Manual.)
When using the End User Job Order interface, a user is permitted to order the jobs in one
scheduling table. The IOA administrator determines which scheduling table a user is
permitted to utilize. Multiple users can utilize the same table.
To identify which table each user can utilize, the IOA administrator defines a special
control member. This control member lists users and the available table for each user.
The control member must be defined in a PDS with LRECL=80, RECFM=F or FB.
The default location is member @@USRTBL in the CONTROL-M SCHEDULE library, but
these values are parameters to CLIST CTMJBINT and can be modified according to site
requirements. This member contains one line for each user ID/mask (see below).
This control member is maintained by the IOA administrator.
Each line is formatted as follows:
Cols 1-8 TSO user ID or mask (see below).
Col 9 Blank.
Cols 10-17 Table name in the scheduling table library.
Cols 18-21 Blank.
Cols 20-63 Name of the scheduling table library (required only if different from the
library where the control member is located). If this entry is non-blank, it
must contain a fully qualified dataset name including the high-level
qualifier and must not be enclosed in quotes.
Any line containing an asterisk in the first column is treated as a comment and is not
processed.
TSO User ID Masking
An asterisk (*) specified as the final non-blank character represents any number of
characters (including no characters). For example, if columns 1-8 on the control card
contain the value ABC*.
User ID ABC or ABCDEF will result in a match.
User ID AB or XABC will not result in a match.
Security considerations:
1. Users who use the CLIST must have READ access to both the library containing the
control member and the library in which the scheduling table is located.
2. The IOA administrator must have UPDATE access to the library containing the control
member.
CONNECT DIRECT Support
CONTROL-M supports CONNECT DIRECT software which creates dataset events (i.e., the
appearance of a dataset) on the system. CONNECT DIRECT support enables dataset
events to automatically trigger CONTROL-M operations (i.e., the adding and/or deleting of
prerequisite conditions, and/or the triggering of jobs) to handle these events.
Note CONNECT DIRECT Support was formerly called NDM Support. See CONNECT
DIRECT Support in Section 6 of the CONTROL-M User Manual for information
about the online definition and maintenance of dataset events.
CONNECT DIRECT support consists of the following phases:
Implementation and Customization
1. Create a Rules library with the following attributes:
LRECL=132,BLKSIZE=13200,DSORG=PO,RECFM=FB
2. Add member @@IDCNTL to the CONTROL-M PARM library. This member should
contain a single line (in the format shown in the table below) for each user who is
going to use this facility.
Columns Description
01 08 User ID
09 52 Name of the Rules library
53 60 Member name (user ID recommended)
Example
The sample CONNECT DIRECT script shown below calls dataset driver IOADDR to set
a different prerequisite condition upon successful or unsuccessful completion of a file
transfer.
IOADDSTR PROCESS PNODE=PRIMNODE
SNODE=SECDNODE
STEP01 COPY FROM (PNODE DSN=INDSN DISP=SHR) -
TO (SNODE DSN=OUTDSN DISP=SHR)
STEP02 IF (STEP01 = 0) THEN
RUN TASK (PGM=IOADDR, -
PARM=(OUTDSN.COPY.GOOD)) SNODE
ELSE
RUN TASK (PGM=IOADDR, -
PARM=(OUTDSN.COPY.FAILED)) SNODE
EIF
When preparing CONNECT DIRECT to work with started task IOADDS, replace calls
to module IOADDR with calls to module IOADDC, which will transfer the dataset
names which need to be checked to started task IOADDS.
Dataset Event Definition (REXX Procedure IOACDDR)
Dataset event definitions are created and modified by the CONTROL-M user via online
Event Definition and Event List screens. The user must define at least one Event list.
An Event list is composed of dataset names and, for each dataset name, the operations
which should be triggered by the dataset event.
Event lists are defined/modified in the Dataset Event Definition facility which is
activated via REXX procedure IOACDDR (described in Section 6 of the CONTROL-M
User Manual).
Automatic Operation Triggering Upon Dataset Appearance (Module IOADDR)
Once Event lists are defined, they can be used to trigger operations which are based on
dataset events. The main module involved is module IOADDR.
Whenever a dataset event occurs, module IOADDR should be invoked, and the name of
the dataset should be passed to it as a standard parameter. Module IOADDR looks for
the passed dataset name in the Event lists. If it finds the dataset name in a list, it
initiates the corresponding action.
Module IOADDR can be called from any calling environment (job, TSO, CONNECT
DIRECT, etc.). Before the module can be called, certain files must be allocated to the
module.
In most cases, the calling environment allocates the required files and calls module
IOADDR directly.
If the calling environment cannot allocate the files, it cannot directly call module
IOADDR. Instead, it must utilize module IOADDC and started task IOADDS to call
module IOADDR. In this case, the process is as follows:
The calling environment calls module IOADDC and passes the dataset name as an
argument. Module IOADDC attempts to issue an MVS modify command to started task
IOADDS.
The modify command format is:
F IOADDS,dsn
where:
dsn Dataset name
Started task IOADDS is a complete, predefined environment under which module
IOADDR can function. Under IOADDS, special allocation of files by the calling
environment is unnecessary.
Started task IOADDS then calls module IOADDR, and passes the dataset name as an
argument. Module IOADDR checks the Dataset/Event table as described earlier and
triggers the corresponding event.
If for some reason (e.g., no authorization) module IOADDC cannot issue the modify
command to start started task IOADDS, it issues error message CTMJA1S which
contains the dataset name. This message can be intercepted by CONTROL-O (or
another console automation product) which can then issue the modify command to call
started task IOADDC.
Activation of Started Tasks
CONTROL-M can activate started tasks as well as jobs. The JES2/JES3 definitions
required to support started tasks are described in the CONTROL-M section of the IOA
Installation Guide.
When working in a multi-CPU environment, CONTROL-M can also activate started tasks
in CPUs other than the one in which the CONTROL-M monitor is active.
Under JES2, the CONTROL-M monitor activates started tasks in other CPUs by using
command $Mm, where m is the appropriate system ID. This system ID is defined in the
JES2 initialization check as follows:
MASDEF SID(n)=cccc
-or-
Sn SID=cccc (under older releases)
For further details, refer to IBMs publication JES2 Initialization and Tuning (SC23-0046
or equivalent).
JES2 will fail a $Mm command if m is the ID of the system ID in which the CONTROL-M
monitor itself is working. Therefore, when CONTROL-M is ordered to activate a started
task in a specific system, it checks whether a $Mm command or a regular MVS START
command should be issued. To ensure that this check is performed correctly, all the CPUs
in your computer complex must be defined in installation parameter CPUS
(in CTMPARM).
Under JES3, the CONTROL-M monitor activates started tasks in other CPUs by issuing a
*T cccc JES3 command, where * is the JES3 command prefix and cccc is the required system
ID. This system ID is defined in the JES3 initialization deck (INISHDECK) as follows:
MAINPROC,NAME=cccc,SYSTEM=JES3,...
For OS/390, JES3 command RO cccc is issued.
Daylight Savings Time Considerations
Daylight savings time considerations are described in the following paragraphs. All
examples assume 02:00 a.m. as the time of change.
Advancing the Clock Forward
The following examples assume that the clock is moved ahead at 2:00 a.m. (i.e., 2:00 a.m.
becomes 3:00 a.m.). If the computer is capable of changing the clock without restarting the
system, do not bring down the CONTROL-M monitor when the clock is being advanced.
New Day Procedure
No special action should be taken once the clock is advanced.
If the New Day procedure starts before you reset the clock, the New Day procedure will
start working before the clock is advanced and will continue normally (even if the clock
is advanced while the New Day procedure is in process).
If the New Day procedure is scheduled to begin at exactly 2:00 a.m., the same considerations
apply. It is possible that the New Day procedure will start execution before the clock is
manually changed. Otherwise, changing the clock will initiate New Day processing.
If the New Day procedure is scheduled to begin between 2:00 a.m. and 3:00 a.m., once
the computer clock is advanced, the monitor will start the normal New Day processing.
If the New Day procedure is scheduled to begin after 3:00 a.m., no action is required.
The monitor will start the standard New Day procedure.
Time-Dependent Shouts
Shout messages scheduled before 2:00 a.m. do not require any action.
Shout messages scheduled between 2:00 a.m. and 3:00 a.m. will be issued, even though
there may not be a delay in production since the time frame for production is smaller.
The above also applies to jobs which have shout messages scheduled at a later time
(e.g., 6:00 a.m.). These jobs may be considered late because of the tighter production
time frame.
Time-Dependent Schedules (FROM-UNTIL)
Jobs whose scheduled time overlaps the time gap created by the clock shift may need
manual intervention. For example, it is possible that a job with a FROM value of 2:15 a.m.
and an UNTIL value of 2:45 a.m. may not be submitted at all. These jobs should be
manually adjusted.
Cyclic Jobs
The next run of Cyclic jobs with an interval of more than one hour will run one hour sooner
than they would have run. Cyclic jobs with an interval of less than one hour will run
immediately.
IOA Log File
The IOA Log file will not contain entries with timestamps between 2:00 a.m. and 3:00 a.m.
Any KSL scripts and/or programs that rely on log entry time should be checked for possible
discrepancies as a result of advancing the clock.
Moving the Clock Backwards
The following examples assume that the clock is moved back at 2:00 a.m. (i.e., 2:00 a.m.
becomes 1:00 a.m.).
New Day Procedure
If the New Day procedure starts before 1:00 am, no special action should be taken. The
New Day procedure will run only once.
If the New Day procedure starts exactly at 1:00 a.m., computer time should not be
turned back to 1:00 a.m. to avoid another New Day process. A second New Day
procedure requires manual intervention. It is advisable to wait a few minutes (until
2:05 a.m., for example) and then turn the clock back an hour earlier.
If the New Day procedure is scheduled to begin between 1:00 a.m. and 2:00 a.m., do one
of the following:
Wait at least a full hour after the daily run begins and then turn the clock back as
needed; the New Day procedure will have ended.
-or-
Update the clock before New Day processing begins.
For example, if the New Day procedure is scheduled to begin at 1:45 a.m., move the
clock back one hour at about 1:40 a.m. If this is not done by 1:40 a.m., wait until about
2:50 a.m. and then turn the clock back.
If the New Day procedure is scheduled to begin after 2:00 a.m., no special action should
be taken.
Time-Dependent Shouts
Shout messages scheduled between 1:00 a.m. and 2:00 a.m. may be issued twice.
Time-Dependent Schedules (FROM-UNTIL)
No special action should be taken for jobs with FROM-UNTIL schedules. Jobs scheduled to
start between 1:00 a.m. and 2:00 a.m. will start at the first occurrence of that hour
(provided that other conditions, such as input conditions, resources, etc., are met).
However, they may be restarted once the clock is moved back.
Cyclic Jobs
The next run of Cyclic jobs will run one hour later than they would have run.
IOA Log File
The IOA Log file may contain entries with times earlier than previous entries, due to the
time shift. Apply the same considerations when advancing the clock forward, that are
applied when moving the clock backwards.
Managing the CMEM Facility
The CONTROL-M Event manager (CMEM) is designed to handle events occurring outside
the control of the CONTROL-M monitor. CMEM consists of a monitor which uses the IOA
subsystem and performs predefined actions in response to system events (e.g., arrival of a
specified job on the job spool).
Note If CONTROL-O is installed the CONTROL-O monitor assumes control of the CMEM
facility and this description of the CMEM facility is not relevant. Instead, refer to
Section 5 in this guide for information about how to manage the CMEM facility when
CONTROL-O is installed.
Automatic Loading of Rules
When the CMEM facility is started (and is not replacing an active CMEM monitor), it loads
CMEM rule tables specified in the CMEM list. The CMEM list is a partitioned dataset
(PDS) containing the names of the tables to be ordered. A default CMEM list is located in
member IOACMEML in the IOA PARM library (referenced by DD statement DACTMLST).
The default list can be overridden by specifying the ORDER parameter in command
S CTMCMEM, which references a different CMEM list.
Each line in the CMEM list has the following format:
* library table
where:
* Must be included as a constant.
library Rule library name.
table Rule table name (or mask).
Manual Loading of Rules
The CMEM list specified during startup contains a list of rule tables to be activated by
CMEM when it is started.
To load additional tables, or to replace a currently active table with a new (updated) copy
of the rules in the table, use one of the following options:
Option 1
Enter the CMEM Online facility (=C) and use the FORCE option in the Table List screen.
Option 2
Issue the following operator command:
F CTMCMEM,C=library(table)
where:
C= Load a CMEM rule. Each rule is loaded by the CMEM monitor and is activated.
Examples
F CTMCMEM,C=CTM.PROD.RULES(DATASET)
Loads table DATASET from CTM.PROD.RULES
F CTMCMEM,C=CTM.PROD.RULES(*)
Loads all tables from CTM.PROD.RULES
F CTMCMEM,C=CTM.PROD.RULES(PROD*)
Loads tables starting with PROD from CTM.PROD.RULES
Replacing All CMEM Rule Tables in One CPU
To replace all loaded CMEM tables with those in the CMEM list (referenced by DD
statement DACTMLST) use the following operator command:
F CTMCMEM,C=ALL[,REBUILD]
If the REBUILD option is specified, CMEM rule tables not listed in the CMEM list are deleted.
If the REBUILD option is not specified, previously loaded CMEM rule tables are replaced
by a new copy of the rule table and unchanged tables are left intact.
Replacing All CMEM Rule Tables in All CPUs
All CMEM rules in all CPUs where the CMEM monitor is active can be reloaded at the
same time. The reload process is performed in the same way as the automatic loading is
performed during startup of the CMEM monitor. All active rules are deleted and all rule
tables specified in the CMEM list referenced by DD statement DACTMLST are loaded.
To replace all rules in all CPUs, issue the following command:
F CONTROLM,NEWCONLIST
Specifying this command is the same as specifying F CTMCMEM,C=ALL,REBUILD in all CPUs.
CONTROL-M informs the CMEM monitor running in each CPU about this command request.
Rule tables that were manually loaded and/or do not appear in the CMEM list are deleted
during execution of this operator command.
Deleting (Deactivating) an Active Rule Table
An active CMEM rule table can be manually deactivated via the following operator command:
F CTMCMEM,D=library(table)
where:
D= Deactivate a CMEM rule. Each rule is deactivated by the CMEM monitor.
Example
F CTMCMEM,D=CTM.PROD.RULES(PRODTAB1)
Displaying Active Rules
A list of the active CMEM rules (up to a maximum of 1000 rules) can be displayed on the
operator console. To display the list, enter operator command:
F CTMCMEM,DISPLAY
This command displays a list of all active rules in the CMEM facility with the following
information:
Rule Rule name (i.e., the name which appears in the first ON statement in the rule
definition).
Type Rule type. Valid types:
R JOBARRIVAL
X JOBEND
D DSNEVENT
Z STEP
Table Name of the table containing the rule.
Status Rule status. The only valid status is ACTIVE.
Library Name of the library containing the rule member.
Priority Internal CMEM rule scanning priority.
Controlling CMEM Rule Operation Mode
The mode of operation (i.e., the trace mode) for a rule is determined by parameter MODE
in its rule definition. Sometimes it is useful to override the operation mode of all active
rules and verify that events and actions are recorded in a particular way. For example:
Ensure a full trace of all rules (i.e., all events and actions are recorded) to facilitate
analysis of the interaction between rules.
Record (trace) only the triggering of every rule.
Global trace operations are requested via operator commands, as follows:
1. Activate a full trace:
F CTMCMEM,LOG=ALL
All rules are fully traced as if they were defined with mode LOG. This operator
command should only be used temporarily for specific tests because extended use of full
trace mode can adversely affect CMEM performance.
2. Trace rule triggering only:
F CTMCMEM,LOG=TRIGGER
Only rule triggering is traced for all rules. However, rules defined with mode LOG are
fully recorded.
3. Restore the default operation mode (as defined in the rule definition) for each rule:
F CTMCMEM,LOG=DEFAULT
Modifying the CMEM Sleeping Interval
CMEM wakes up every few seconds. This time interval is defined in the CONTROL-M
installation parameters and can be changed by the system administrator. In addition, the
interval can be modified by the operator command:
F CTMCMEM,INTERVAL=nn
where nn represents the interval in seconds.
When the modification is accepted by CMEM, the following message appears on the
operator console:
CME123I CMEM INTERVAL IS SET TO nn SECONDS
Refreshing the CMEM Security Cache
CMEM security modules use a security block to identify each user for which an authority
check is performed. The first time a users security authorization is checked, CMEM
creates a security block for that user. The security block can then optionally be saved in
the CMEM security cache for the next time the users security authorization is checked.
The CMEM security cache holds security blocks for the last 30 users to have their security
authorization checked.
Changes made to a users security authorization (since the last time that users security
block was created) are not automatically included in the information in the users security
block in the CMEM security cache. However if a users security authorization has been
changed and there is no security block in the CMEM security cache for that user, changes
made to the users security authorization will be in effect the next time that users security
authorization is checked.
To immediately include new user authorization information in the CMEM security cache,
refresh the security cache via operator command:
F CTMCMEM,NEWSECDEF
This command refreshes all user authorization information in the CMEM security cache.
When the modification is accepted, the following message appears on the operator console:
CME251I RUNTIME SECURITY REFRESH ENDED OK
Virtual Storage Requirements of the CMEM Monitor
CMEM monitor procedure CTMCMEM is supplied with a default region size of 5 MB. The
region size can optionally be increased up to a maximum of 2 GB.
Calculating Region Size
The items described below should be included in your calculation of the amount of virtual
storage needed by the CMEM monitor:
Block size of the IOA Conditions/Resources file, specified in parameter RESLREC in
member IOAPARM. See Appendix D: Structure of the IOA Conditions/Resources File
in the IOA Installation Guide for information about how to calculate this block size.
CMEM monitor working buffers require approximately 750 K of virtual storage.
CMEM monitor software requires approximately 500 K of virtual storage, depending on
the environment and the functions used.
Site-defined work areas and programs (e.g., user exits). These items usually require a
small amount of virtual storage. Therefore, it is usually not necessary to calculate the
requirements of site-defined components precisely. However, it is important that you
allow some storage space for these components.
Note It is recommended that you specify a larger than necessary region size to ensure
sufficient storage space for CMEM and related MVS activities.
Example
At a site with:
A block size (RESLREC) of 32760 for the IOA Conditions/Resources file.
One slot per block (RESREC#).
5000 records in the Message Statistics file.
Site defined components requiring approximately 0.20 MB of virtual storage.
Calculate virtual storage for the CMEM monitor as follows:
IOA Conditions/Resources file 1.10 MB (32,760 * 32 * 1) + 64 K
CMEM software 0.50 MB
CMEM working buffers 0.75 MB
Site Defined components 0.20 MB
Extra space for MVS activities 0.20 MB
________
Total 2.75 MB
Troubleshooting
MVS allocates the region size specified for the CMEM monitor unless a local exit (e.g.,
IEALIMIT, IEFUSI, or another MVS or JES exit) is used to limit the region size of jobs
and/or started tasks at the site.
Message IEF374I in the third SYSOUT of the CMEM monitor indicates the amount of
virtual storage used by the CMEM monitor. Compare the information in this message with
the existing region size definition.
If sufficient virtual storage is not available for the CMEM monitor, use on-site performance
tools to determine if the specified region size was rejected by MVS (e.g., via a local exit).
If MVS accepted the specified region, recalculate the CMEM monitors virtual storage
requirements, as shown above, and modify the region size in the EXEC statement of the
CMEM monitor procedure accordingly.
If an MVS procedure rejected the specified region size, consult your system
administrator.
Storage Allocation
At start-up time, the CMEM monitor allocates working storage. CMEM can allocate virtual
storage above the 16 MB line. The decision as to whether to allocate above or below the
16MB line is made by MVS (which considers the specified job, the amount of requested
storage, MVS exits, etc.).
CMEM Usage of the Common Storage Area (E/CSA)
CMEM receives control of a message under the user TCB (i.e., CMEM acts as part of the
job that issued the message). Therefore, CMEM allocates storage from the Extended
Common Storage Area (ECSA).
Due to MVS Services requirements, only a small part of the Common System Area (CSA) is
used by CMEM.
Use the information below to calculate CMEM ECSA and CSA storage requirements.
Extended CSA Usage (Above 16M Line)
The following CMEM components use Extended CSA:
Subsystem executor 160 K
Work Buffers 75 K If the system on which CMEM is working has only one or
two CPUs, a minimum of 75 K is required. If the system
has three or more CPUs, each CPU requires 30 K.
Rules 30 K This amount assumes 500 rules and an average of 60
bytes per rule.
_____
Total 265 K
Note Converting the CMEM ONSPOOL table to a CMEM rule table can create thousands of
rules in the new table. (Each entry of CTMEVENT becomes a CMEM rule.) If old
CMEM definitions were converted at your site, modify the above calculation to include
a suitably larger amount of storage for CMEM rules.
CSA Usage (Below the 16M Line)
SWT and other
system control blocks
1.5 K
Dataset triggering
executor
30.0 K
______
Total 31.5 K
CMEM CONTROL-M Communication
Section 3 of the IOA Installation Guide describes the installation and implementation of
the two methods used by the CONTROL-M Event Manager (CMEM) to communicate with
CONTROL-M. These methods are:
subsystem-to-monitor (S2M) communication files
MVS System Logger sysplex interface
Advantages of the MVS System Logger sysplex interface are described under the topic
CMEM Considerations for Sysplex & Non-Sysplex Environments in Section 3 of the IOA
Installation Guide.
The MVS System Logger sysplex interface first became available under MVS/ESA SP
Version 5. The coupling facility, the coupling facility resource manager, and the MVS
System Logger sysplex interface are discussed below.
Coupling Facility and Coupling Facility Resource Management
A coupling facility is a shareable storage medium (not a shared storage device) that
facilitates high-speed access to shared data across applications and subsystems running on
the same or different MVS systems. It is licensed internal code running in a special PR/SM
logical partition (LPAR) in certain ES/9000 and S/390 processors.
A coupling facility can be shared by the systems in one sysplex only. It enables data to be
shared by all users in a sysplex while ensuring data integrity and consistency. To share data,
systems in the sysplex must be connected to the coupling facility via coupling facility channels
and must have access to the coupling facility resource management (CFRM) couple dataset.
Storage in a coupling facility is divided into distinct objects called structures. Structures
are used by authorized programs to implement data sharing and high-speed serialization.
Structure types are cache, list and lock, each providing a specific function to the
application. MVS System Logger is a set of standard services that allows an application to
write to, browse in, and delete from a coupling facility structure.
A coupling facility is managed via the coupling facility resource management (CFRM)
policy. The CFRM policy allows a user to specify how a coupling facility and its resources
are to be used at the site. In a CFRM policy, a user supplies information about each
coupling facility and each coupling facility structure at the site. The planning of a CFRM
policy is described under the topic Planning a Coupling Facility Policy in IBM publication
MVS/ESA Setting Up a Sysplex.
To set up a CFRM policy:
Format a CFRM couple dataset by using the IXCL1DSU format utility program. For
more information, see Format Utility for Couple Data Sets in IBM publication
MVS/ESA Setting Up a Sysplex.
Define one or more CFRM administrative policies by using the IXCMIAPU
administrative data utility. For more information, see Administrative Data Utility in
IBM publication MVS/ESA Setting Up a Sysplex.
Make one of the defined CFRM policies the active administrative policy for the sysplex.
Start it by using operator command SETXCF START,POLICY,TYPE=CFRM. For more
information, see Transitioning to a New CFRM Policy in IBM publication MVS/ESA
Setting Up a Sysplex.
MVS System Logger Sysplex Interface
MVS System Logger is a robust set of standard MVS services that allows an application to
write to, browse in, and delete from a coupling facility structure. This set of MVS services
has been chosen to implement CONTROL-M Event Manager (CMEM) CONTROL-M
communications and to replace the subsystem-to-monitor communication files. The write,
browse and delete functions of the MVS System Logger are tailor-made for CMEM writing
to the coupling facility and CONTROL-M reading from the coupling facility. Internal
details of MVS System Logger services are described in Using System Logger Services in
IBM publication MVS/ESA Assembler Services Guide. Because these services are
transparent to the user, they are not described here.
To install and implement the MVS System Logger sysplex interface:
1. Follow the instructions to set up a CFRM policy (summarized above).
2. Specify CONTROL-M sysplex configuration parameters (as described in Section 3 of the
IOA Installation Guide).
The advantages and other implementation-related details of the MVS System Logger
sysplex interface are discussed under the topic CMEM Considerations for Sysplex & Non-
Sysplex Environments in Section 3 of the IOA Installation Guide.
CMEM is supplied with the following internal debugging facilities:
The ability to print an internal debugging trace.
The ability to print the contents of the CMEM internal data areas.
Under normal circumstances, the debugging facilities are dormant. However, if required
(i.e., your IOA representative has requested debugging information), it is possible to
activate the debugging facilities as follows:
Activate the CMEM internal trace:
1. Perform either step A or B below.
A. Start a new CMEM monitor with the following operator command:
S CTMCMEM,DEBUG=nn
The current CMEM monitor passes control to the new CMEM monitor and shuts
down.
-or-
B. Issue the following operator command:
F CTMCMEM,DEBUG=level
The required debugging level will be supplied by your IOA representative. It can be
any value from 000 to 255. (000 specifies no debugging.)
Note It is recommended not to activate CMEM with the DEBUG parameter on a regular
basis because in case of a JES problem, CMEM may get hung up waiting for JES.
2. The debugging information is printed to DD statements PRTDBG and DADUMP of the
CMEM procedure.
3. When you have finished your problem determination procedures, start a new CMEM
using the following operator command:
S CTMCMEM
or specify the operator command:
F CTMCMEM,DEBUG=000
Print CMEM Internal Data Areas
To print CMEM internal data areas, issue the following operator command:
F CTMCMEM,SNAP[=name1,name2 ...,namen]
where:
name1, name2,... namen are the names of the CMEM internal data areas.
When no name is specified, all data areas are printed. Your IOA representative can provide
the list of data area names. Which data areas should be printed depends on the problem
encountered.
Valid values:
ALL LINK MTOPLB OMT RQCEXO RQC SSVT
ALO MAIN MTOPND OPR RQCFREE RQH STO
CAS MCT MTOPNX PARM RQCMTO RULES SWT
CONLIST MTO MTOSRV PND RQCRFR SEC UCM
CONS MTOINX MTOSRVA RFR RQCSLO SLO VARS
CONSOLE MTOLNK MTOWSC RQCALO RQCSRV SRV WISHES
DLY MTOMIX MVS RQCDLY RQCSTO SSCT WSC
EXO MTOMPT
When the snap is completed, the following message appears on the console:
CME150I SNAP COMMAND WAS PERFORMED SNAPID=xxxx
where:
xxxx is the snap identifying number which appears on the lower right of the screen after
the snap is completed.
Displaying Internal Resource Utilization
To obtain information on internal resource utilization, issue the following operator
command:
F CTMCMEM,WATERMARKS
The response to this command is displayed as message CME15DI. See the IOA Messages
and Codes manual for an explanation of this message.
CONTROL-M Tuning Recommendations
The following recommendations are made with tuning as the primary consideration during
the installation of CONTROL-M. However, some of these recommendations may not be
suitable for your site. If necessary, you can make changes at a later stage.
General Tuning Issues
Placing the IOA LOAD Library in the MVS Linklist (MVS/XA Sites)
Consider placing the IOA LOAD library in the MVS Linklist.
The LLA (Linklist Lookaside) function of MVS/XA maintains direct pointers to all load
modules residing in the Linklist. These direct pointers eliminate the I/O operations and
time required to search the PDS directories of Linklist libraries. Therefore, load modules
located in the MVS Linklist can usually be fetched quicker than modules coming from
libraries referenced by the STEPLIB DD statement.
The advantage of placing the IOA LOAD library in the MVS Linklist is even greater if the
CONTROL-M JCL procedures and the TSO logons which operate the IOA Online interface
do not contain a STEPLIB DD statement. In this case, only the MVS Linklist will be
searched.
When some modules come from libraries referenced by DD statement STEPLIB and others
come from the MVS Linklist, the required modules are first searched for in libraries
referenced by DD statement STEPLIB and afterwards searched for in the MVS Linklist.
Implementation of LLA/VLF to Control Load Module Fetching
(MVS/ESA Sites)
3
The LLA (Library Lookaside) function of MVS/ESA manages both Linklist and non-Linklist
libraries. Therefore, it is not necessary to place the IOA LOAD library in the Linklist in
order to benefit from LLA. Without VLF (Virtual Lookaside Facility), the LLA only
maintains direct pointers to modules residing in LLA controlled libraries. The combination
of LLA and VLF improves module fetching by keeping modules in virtual storage. If VLF
has a copy of a module that is controlled by LLA, no I/O operations are required to locate or
retrieve the module from a PDS library.
Using Program Fetch Optimization Products
These products can usually speed up the process of locating and/or fetching load modules
(even when working with a STEPLIB DD statement). If your data center operates a
program fetch optimization product (e.g., PDSMAN, PMO, QUICKFETCH), this product
can control CONTROL-M load module fetching.
3
Fast location of modules required by CONTROL-M may significantly impact IOA Online facility response
time. However, the impact on the CONTROL-M monitor is limited because the monitor loads most of the
required modules into storage only once (for added performance).
Placing CONTROL-M/IOA Files on Appropriate Disk Packs
The following disk/file characteristics enable CONTROL-M to perform optimally:
Disks which are not very active and are not connected to heavily utilized disk strings
and disk channels.
Disks which do not contain MVS system files.
Disks which do not contain a PAGE/SWAP dataset.
At a multi-CPU site: disks which are not physically reserved (and therefore cannot be
physically locked) by other CPUs.
Disks whose head movement is minimized by placing CONTROL-M/IOA files near the
VTOC.
Files (IOA RES, IOA SNC, IOA LOG, CONTROL-M AJF and History file) which are
split over several disks (after installation).
Disk types which are newer, e.g., 3390 or 3380 (see exceptions mentioned below).
Placing Certain CONTROL-M/IOA Files on Special Disk Devices
Some sites have special disk devices such as:
Solid state (semiconductor) disk devices
Disks with fixed heads
Disk controllers with cache memory
Several CONTROL-M/IOA files are good candidates for placement on these devices.
The (usually temporary) file referenced by DD statement OUT180 is a good example. The
first three sysout files of a job submitted by CONTROL-M are read from spool and written
to this file for later analysis. A permanent file can be allocated on an appropriate device
and defined in DD statement OUT180 to control the placement of this file.
Note This file is obsolete if CONTROL-R has been installed.
In DD statement OUT180, some customers specify UNIT=VIO (i.e., Virtual I/O) in order to
gain I/O performance improvement through the MVS paging mechanism. We suggest
measuring your systems paging performance before considering this.
Active Jobs File (AJF)
The Active Jobs file is updated whenever CONTROL-M orders a job and whenever the
status of a job is changed by the CONTROL-M monitor. In addition, the CONTROL-M
monitor reads record zero of this file after each sleeping interval to search for new job
orders. This file is also accessed by the IOA Online facility.
SNC File
The SNC file synchronizes the CONTROL-M monitor and other CONTROL-M/IOA
components with regard to changes made in the IOA Conditions/Resources file (RES). The
monitor reads the first block of this file after each sleeping interval to determine if changes
have been made.
IOA Conditions/Resources File (RES)
The IOA Conditions/Resources file is updated whenever a prerequisite condition, control
resource or quantitative resource is added/deleted/updated.
IOA Log File
The IOA Log file contains an audit trail of events that occurred in the IOA system. The
first block of the file contains pointers that enable direct access into the IOA Log file.
If disks with fixed heads are available (e.g., 3350 disks with fixed-heads, or equivalent), it
may be advantageous to place the SNC file, the first track of the Active Jobs file, and/or
the first track of the IOA Log file under the fixed-head area(s).
If solid-state semiconductor devices are available, it may be advantageous to place the
OUT180 file, the SNC file, and/or the RES file on them. Other files can also be considered,
depending on the capacity of the devices.
If disk controllers with cache memory are available, it may be advantageous to place active
CONTROL-M/IOA files on disk packs connected to such controllers. We suggest performing
tests in order to determine whether or not the hit rate observed at your site justifies
implementing this recommendation. These tests should be performed after choosing the
optimal sleeping interval. See Choose an Appropriate Sleeping Interval below.
All of the above suggestions have a positive impact on the performance of the CONTROL-M
monitor and other CONTROL-M components. They also minimize the likelihood of two
CONTROL-M components attempting to access the same resource at the same time.
The above suggestions also have a positive impact on the performance of some IOA Online
facility screens. For example, optimizing Active Jobs file placement speeds up performance
when using screen 3 of the Online facility. Optimizing IOA Log file placement speeds up
performance when using the screens 5 and 3.L of the Online facility.
Enlarging CONTROL-M/IOA File Blocksize
Most CONTROL-M/IOA files are created with a predefined blocksize that cannot be
changed. The IOA Conditions/Resources file (RES) and the IOA Manual Conditions file
(NRS) are exceptions to this rule. Their blocksizes can be controlled at time of installation
through IOAPARM. We suggest using the maximum blocksize (32760 for 3380 and 3390
disk devices) even if this wastes a slight amount of DASD space.
CONTROL-M/IOA LOAD libraries are supplied with a blocksize of 6144. CONTROL-M/IOA
source-like libraries are supplied with a blocksize of 3120. These libraries can be reblocked
to suit the standards employed at your site. Larger blocksizes will reduce I/O, CPU time
and elapsed time. However, this will not have a significant impact on the major
components of CONTROL-M.
CONTROL-M Monitor and MVS/JES Considerations
The CONTROL-M monitor uses JES services to receive information about the status of the
jobs running in the system. If CONTROL-M detects a critical error in JES operation, it
shuts itself down. This prevents the incorrect submission of jobs due to a JES malfunction.
One of the following highlighted, unrollable messages is displayed on the operator console:
CTM168S CONTROL-M SHUTTING DOWN - COMMUNICATION TO "JES" NOT AVAILABLE
CTM256S CONTROL-M SHUTTING DOWN - COMMUNICATION TO "JES" NOT AVAILABLE
Special Considerations
To analyze how a job finished executing, CONTROL-M uses JES services to read the jobs
output. Therefore, the following limitations should be considered:
Jobs submitted by CONTROL-M can be canceled by the operator. It is important,
however, not to purge their outputs (i.e., JES commands $PJnnn, $CJnnn, P and
similar commands must not be used).
Job output for jobs submitted by CONTROL-M should not be released for printing other
than by CONTROL-M (i.e., MVS JES2 command $TO, MSP JES command $0 and
similar commands should not be activated on the jobs output).
If JES operator command $HJ is issued for the job, the job must be released from held
status before CONTROL-M can read the jobs output. Otherwise, the job status is
changed to EXECUTING (SYSOUT IN HOLD STATUS).
Whenever the CONTROL-M Monitor does not succeed in reading job sysout, the following
rollable message appears on the operator console:
CTM262W n UNSUCCESSFUL ATTEMPTS TO READ JOB DATA BY SUBSYSTEM REQUEST. RETRY
CONTINUES
Message CTM262W does not necessarily indicate a serious problem.
Examples
When a job is not run due to a JCL error, only two sysout datasets exist for the job.
Therefore CONTROL-M cannot read the third sysout dataset and the above message is
displayed.
When JES is very busy, a period of up to a minute (in extreme cases) may pass between
the time the job has finished executing and the time JES enables CONTROL-M to read
its sysout (i.e., JES is stuck in the Output Processing stage).
By default, CTM262W is displayed every 5 times the CONTROL-M monitor attempts to
read the job sysout and does not succeed. If after 20 attempts the CONTROL-M monitor
still does not succeed in reading the sysout, the following message is displayed:
CTMD50S READING JOB DATA BY SUBSYSTEM REQUEST FAILED AFTER n ATTEMPTS. LAST
RC code FILE n jobname/jobid
The above two default values can be changed in the installation parameter.
On the other hand, message CTM262W can indicate serious problems with the jobs sysout.
Below is a list of typical problems which can cause this message to appear.
When a jobs output has been released for print (i.e., no longer in held output), the jobs
output should be printed or purged.
In a multi-computer environment the following chain of events may occur:
CONTROL-M monitor submits the job from computer A.
Computer A crashes (or is shut down).
CONTROL-M monitor is activated on computer B and the job executes in computer
B. When the job finishes executing CONTROL-M cannot read the jobs output and
message CTM262W appears.
This is caused by the job waiting to be handled by the JES of computer A.
This problem can be overcome by assigning the job to computer B (using JES
command $TJnnn,S=sysid). CONTROL-M then reads the output and the message
disappears from the operator console.
Message CTM262W Summary
Whenever message CTM262W appears, wait a minute or two. If the message continues to
appear every few seconds for the same job, try to resolve the problem by following these
steps:
Note To stop the message from appearing on the operator console while you are checking the
problem, hold the job order in the CONTROL-M Status screen (screen 3). Release it
when you have resolved the problem.
Issue JES2 commands $Djnnn and $LJnnn. Scan the results.
Check whether or not the jobs output is in held class (the job waits for print). If yes,
the CONTROL-M monitor cannot analyze the output, so you must analyze it manually.
Print or purge the output of the job. Make sure that the job order in CONTROL-M is
not HELD. Wait for a minute until the status of the job changes to DISAPPEARED.
Manually ADD/DELETE prerequisite conditions according to the result of the run in
the IOA Conditions/Resources screen (Screen 4).
If the job is waiting for output processing, check whether or not the job (not the
output) is held (by a previously issued $HJ command). If the job is held, release it using
JES2 command $AJnn.
If the job is waiting for output processing by a system ID which is currently not
active, try to resolve the problem as described above using command JES $TJnnR.
Run CONTROL-M on the Global Processor in a JES3 Complex
When accessing the JES3 status areas and spool queues, access via the global processor is
faster and less expensive than through a local processor. Therefore, we strongly
recommend running the CONTROL-M monitor on the global processor in a JES3 complex.
Run CONTROL-M on the CPU Where Most JES2 Activity is Performed
In a Shared-Spool complex (MAS), one CPU may perform most of the accesses to JES. For
example, this may happen when:
All/most of the printers are physically connected to one CPU.
All/most of the jobs are submitted through one CPU.
All/most of the reports are created on one CPU.
All/most of the NJE or RJE lines are connected to one CPU.
One CPU is much stronger (in terms of MIPs) than the other(s) and it effectively
monopolizes access to the JES files.
If this is the situation at your data center, we recommend running the CONTROL-M
monitor on the CPU where most of the JES activity is performed. This optimizes the
CONTROL-M monitors communication with JES2.
In general, non-balanced access by different CPUs to JES files can be controlled and
balanced through appropriate JES2 parameters.
JES2PARM Tuning Considerations
In the CPU on which the CONTROL-M monitor runs, increase the IBM-supplied
default (or current) value of PSONUM (number of Process Sysout processors) by 2 or 3.
In order to avoid performance degradation of CONTROL-M in a MAS (Multi-Access
Spool) environment, the following MASDEF (MAS Definition) parameters should be
adjusted and tuned, as follows:
In the CPU on which the CONTROL-M monitor runs, HOLD should be increased
and DORMANCY should be decreased. In all other CPUs, HOLD should be
decreased and DORMANCY should be increased.
The values recommended below are approximations which do not take into account
other products that may be sensitive to JES2 utilization rates resulting from
changing the current values. The Systems Programmer may wish to do further
tuning.
On the CPU on which CONTROL-M runs, set the following values:
PSONUM=5
MASDEF HOLD=45,DORMANCY=(30,150)
On the other CPUs, set the following values:
MASDEF HOLD=15,DORMANCY=(150,500)
Note The HOLD and DORMANCY parameters can by dynamically changed using the
following JES2 command: $T MASDEF,HOLD=nnnnnnnn,DORMANCY=(mmmm,nnnn)
This change enables the JES on the CPU on which CONTROL-M runs to handle
CONTROL-M requests more efficiently and thereby avoid delays in CONTROL-Ms
analyzing a jobs ending status.
Assign Appropriate Priority to the CONTROL-M Monitor
Use MVS SRM (System Resources Manager) parameters to assign an appropriate priority
so the CONTROL-M monitor can receive enough CPU and other computer resources to
perform the necessary tasks.
Appropriate priority should also be assigned to JES because the CONTROL-M monitor
communicates extensively with JES.
Note Online-oriented sites that run JES with low priority during service hours should
increase the priority of JES before main batch processing begins. This can be done
automatically by scheduling a CTMOPR started task at the appropriate time to issue
an appropriate SET ICS and/or SET IPS command.
Run the CONTROL-M Monitor as Non-swappable
Set parameter NONSWAP to Y in member CTMPARM in order to activate the
CONTROL-M monitor as non-swappable. (For more information, see Section 3 of the IOA
Installation Guide.)
This causes CONTROL-M to be paged-in and paged-out according to a more economical
algorithm. In addition, this speeds up the paging process by causing some basic address-
space related pages to remain in virtual storage. Non-swapping mode ensures good
response for the CONTROL-M monitor, as well as the best overall performance.
If the CONTROL-M monitor is run as swappable, the CONTROL-M status tracking task
may get stuck waiting for a JES response. This can happen if the monitor communicates
with an overloaded JES.
Choose an Appropriate Sleeping Interval
The CONTROL-M monitor wakes up according to the sleeping interval specified via
parameter INTERVL in member CTMPARM.
The CONTROL-M Installation Guide contains guidelines for specifying parameter
INTERVL. These guidelines should be used as a starting value. The recommended values
do not distinguish between different models in each CPU family and do not take into
account site-related requirements. The value chosen should be the one best suited to your
data center requirements.
As the value specified for the sleeping interval increases, CONTROL-M uses less CPU and
I/O for the following reasons:
The job selection routine is invoked after longer intervals.
The CONTROL-M monitor checks the status of submitted jobs after longer intervals.
The CONTROL-M monitor interrogates the Active Jobs file (AJF) after longer intervals
for additions/changes that may have been performed from batch or from the IOA Online
facility.
However, if the value specified for the sleeping interval is too high, the following may
result:
Jobs may be scheduled with a delay.
Processing a command entered via the IOA Online facility (e.g., to hold a job) may take
more time because the CONTROL-M monitor performs the command.
The importance of job-scheduling delay should not be overrated. In many cases, increasing
parameter INTERVL from three seconds to six seconds may actually provide the same
throughput because many jobs which have been submitted by CONTROL-M must wait for
an initiator to become available.
The sleeping interval is not a fixed installation parameter. It can be changed dynamically
during standard production hours (e.g., according to hours, shifts, etc.) by scheduling a
CTMOPR started task at the appropriate time. The started task issues the command
F CONTROLM, INTERVAL=ss, where ss is the new interval in seconds.
Another aspect to consider when deciding on the value of parameter INTERVL is avoiding
situations where the CONTROL-M monitor is faster than the local JES. This can be
recognized when one of the following events occurs:
Many CTM262S/JES262S messages are issued by the CONTROL-M monitor for different
jobs. This happens when the jobs sysout is already on the JES output queue, but JES does
not allow access to it.
The CONTROL-M monitor successfully submits a job to MVS, but the job does not appear
in any JES queue for a long time causing the job to receive a status of disappeared. This
situation is rare and only happens if JES is heavily overloaded.
Note This does not refer to a situation where JES is stuck. CONTROL-M would recognize
such a situation and would not submit the job.
If this happens at your site, consider increasing the value of parameter INTERVL.
Storage Isolation
Storage isolation (also called storage fencing) limits the number of page frames which can
be stolen from an address space. You can specify a minimum/maximum WSS (working set
size), a minimum/maximum paging rate, or a combination of the two. The related MVS
SRM parameters are: CPGRT, CWSS, PPGRT, PPGRTR and PWSS.
Improper specifications can degrade the CONTROL-M monitors performance and/or
overall system performance. For instance, if the maximum WSS is too low, the
CONTROL-M monitors performance may be hurt.
Storage isolation should only be considered if you experience a serious paging problem in
the CONTROL-M monitor address space, causing delays in job scheduling.
In any case, we recommend not specifying a maximum WSS and continuing to monitor
performance on a periodic basis.
Tuning the Online Facility
Preallocate Required CONTROL-M/IOA Files in TSO Logon Procedures
If entry to the Online facility is slow due to allocation problems, consider pre-allocating the
required CONTROL-M/IOA files in the TSO Logon JCL procedure instead of in the
CONTROL-M/IOA CLISTs. JCL allocations are faster than TSO dynamic allocations.
However, this should only be considered if there is no other way to speed up MVS
allocations at your site.
Try to Eliminate TSO STEPLIBs
In general, TSO STEPLIBs may cause performance problems. Whenever a program is to be
fetched, CPU cycles and I/O are used to search the STEPLIB directories for the program to
be fetched. If the program is not located, an additional search is performed in Linklist. See
General Tuning Issues above.
Use the IOA Server Mechanism When Required
If you need to assign different performance groups for word done under the IOA Online facility
and other online work, use the IOA Server mechanism via the IOA Online monitor (for TSO or
ROSCOE). For additional information see Section 2 of the IOA Installation Guide.
When using the IOA Server mechanism, only terminal-related issues are performed under
TSO/ROSCOE. All other work is performed in the external server address space.
TSO or ROSCOE users are given their standard performance definitions. The external
server address space definition can differ from the MVS SRM (e.g., it can have a higher
priority).
Mirror File (Dual Checkpointing Mode) Considerations
The CONTROL-M monitor can work in dual mode. Under this mode, the CONTROL-M
monitor maintains duplicate copies of the CONTROL-M Active Jobs file and the IOA
Conditions/Resources File. If a disk crash makes the files inaccessible, the mirror files can
immediately replace them.
Using the optional CONTROL-M mirror file mechanism causes a modest increase in resource
consumption, but the number of I/O operations is only slightly increased (not doubled).
Record zero, a special control record defined in the Active Jobs file, is read by the
CONTROL-M monitor after each sleeping interval to check whether the Active Jobs file
has been updated. If there have been changes, the appropriate Active Jobs file entries are
read into the CONTROL-M monitors address space and record zero is cleared. In addition,
any entry which has been modified in the CONTROL-M monitors address space to reflect a
change in job status is written back to the Active Jobs file.
I/O operations connected to record zero of the Active Jobs file are not performed for the
mirror Active Jobs file. However, entries which have been modified in the CONTROL-M
monitors address space are written to the mirror file.
A similar algorithm is used for the IOA Conditions/Resources file and its mirror file.
CONTROL-M Event Manager (CMEM) Considerations
The overhead required to operate CMEM is insignificant because:
Every WTO message is passed to CMEM by MVS.
CMEM only tracks $HASP001, $HASP100 and $HASP395 messages (under JES2) or
IAT6101, IAT6108, IEF403I, IEF404I, IEF450I, and IEF4531 messages (under JES3).
In addition, all MVS and JES messages of jobs to be controlled by the above facilities
will be tracked as well. All other messages are immediately passed back to MVS. When
a relevant message is encountered, the following actions are performed:
CMEM checks whether the related job or event has been defined in a CMEM table.
This search is performed in storage because the CMEM table is loaded into storage
when CMEM is initialized.
If the job or event has not been defined in a CMEM table, CMEM passes the
message back to MVS.
If a relevant event is encountered, the CMEM rule is passed to the CONTROL-M
monitor, which performs the request.
All CMEM activities (except the last item above) are performed in storage. No I/O or
supervisor calls are required. Therefore, no special tuning activities have to be performed
and there is no reason to monitor CMEM performance.
CONTROL-M monitor overhead can easily be monitored by any locally employed
performance tool.
CONTROL-M Optional Wishes
Many CONTROL-M optional wishes directly affect CONTROL-M performance in various
areas. See member CTMDFLTS in the IOA SECUDATA library and member IOADFLTC in
the IOA MAC library for information about these wishes.
CONTROL-M Multi-CPU Support
Introduction
This section demonstrates how CONTROL-M can be implemented under different
hardware and software configurations. A number of scenarios are provided, relating to
specific hardware connections or to specific enterprise connections.
This section also demonstrates the scope of production workload control and various
CONTROL-M options which can be used. It does not cover CONTROL-Ms entire range of
methods and possibilities, but just the most common ones.
The CONTROL M System as discussed in this section, consists of the following major
components:
Monitor
Online facility
The Online monitor (optional)
Utilities
KSL facility
CMEM facility (optional)
Basic Single-CPU Configuration
Basic Single-CPU Configuration
Basic Hardware Configuration
In this configuration, CONTROL-M is running on one mainframe computer.
One or more disk volumes containing the JES Spool.
One or more disk volumes containing the IOA/CONTROL-M Core and Repository.
One or more terminals which are capable of operating the lOA/CONTROL-M Online
facility.
Standard terminals of the 3270 family are supported as well as other devices which
emulate a 3270 terminal (such as a PC with 3270 simulation or a, VT100 with 3270
simulation).
IBM DBCS terminals (or equivalent), which provide Japanese language (Kanji) capability,
are supported as well.
Optionally, an RJE (Remote Job Entry) workstation (or an intelligent system which
emulates an RJE station) can be connected to the mainframe. Under JES3, the same
facility is called RJP (Remote Job Processing).
The following CONTROL-M options support RJE:
The CONTROL-M Event Manager (CMEM) can be used to acknowledge and handle jobs
submitted from RJE to MVS.
CMEM can be used to acknowledge the creation/deletion of datasets by jobs which
originated from RJE.
CONTROL-M SYSOUT options support the routing of sysouts to RJE.
RJE jobs can invoke utility IOACND or other IOA/CONTROL-M utilities via a JCL step
to communicate with CONTROL-M
Single-CPU Configuration with Multiple CONTROL-M Systems
In this configuration, two CONTROL-M systems are operated.
Single-CPU Configuration with Multiple CONTROL-M Systems
This configuration is common because many sites install a CONTROL-M production system
and a CONTROL-M test system. We recommend operating a separate CONTROL-M test
system for testing new versions or options before applying them in the CONTROL-M
production system.
Usually, the CONTROL-M production system and CONTROL-M test system are separate
systems which use separate libraries, separate databases, different JCL procedures, etc.
In some cases, there may be good reasons for operating two or more CONTROL-M
production systems. For example, a service bureau may need to provide distributed
scheduling for two or more clients.
Two CONTROL-M systems can communicate with each other by scheduling special jobs.
For instance, CONTROL-M system A may schedule a special job which invokes utility
IOACND to add a prerequisite condition in the IOA Conditions/Resources file base of
CONTROL-M system B. This prerequisite condition can, in turn, trigger the submission of
a job by CONTROL-M system B.
Subject to system resource limitations any number of CONTROL-M systems can be
operated concurrently on a single mainframe.
For additional information about how to activate more than one CONTROL-M monitor, see
Activating More Than One Monitor in Section 3 of the IOA Installation Guide.
Note Each CONTROL-M system can use a separate CMEM subsystem. Subject to system
resource limitations, any number of CMEM subsystems can be operated concurrently.
Different (i.e., several) CMEMs can be used to acknowledge job-arrival or job-ended events
for a job. However, only one CMEM should be used to gain control of a job, or check a jobs
dataset disposition.
Multi-CPU Configuration
Shared-Spool Configuration With an ENQ-Handling Product
Shared Spool Configuration with ENQ-Handling Product
The term Shared-Spool refers to JES2 Multi-Access Spool (MAS) or JES3 Complex
connections between two or more MVS systems.
A Shared-Spool configuration consists of two or more JES systems sharing JES input, job,
and output queues. The Shared-Spool must reside on one or more disk volumes which are
shared by (i.e., connected to) all relevant mainframes.
The above diagram shows a basic Shared-Spool configuration consisting of two
mainframes.
The following discussion also applies to Shared-Spool configurations with more than two
mainframes.
A single CONTROL-M monitor is sufficient for handling the entire Shared-Spool complex.
The monitor submits all jobs to CPU A but the jobs run under the appropriate CPU (i.e.,
CPU A or CPU B).
A job can be designated to run on a specific CPU based on the value of parameter CLASS
in the JOB statement. If a job submitted by the CONTROL-M monitor specifies a CLASS
which is only served by CPU B, JES will automatically designate the job to run on CPU B.
A job can also be designated a job to run on a specific CPU through an appropriate JES
statement:
/*JOBPARM SYSAFF for JES2;
//*MAIN SYSTEM for JES3.
If a job submitted by the CONTROL-M monitor requests (through such a statement) to run
on CPU B, JES will automatically send the job to CPU B.
CLASS and/or SYSAFF/SYSTEM specifications can be hard-coded in the jobs JCL, or can
be determined dynamically and set by the CONTROL-M monitor during job submission.
Section 5 of the CONTROL-M User Manual gives two examples of how to dynamically set
up CLASS and/or SYSAFF/SYSTEM specifications via the Auto-Edit facility. See
Controlling the Target Computer by Class and Controlling the Target Computer by
System Affinity in Section 5 of the CONTROL-M User Manual.
Note CONTROL-M supports dynamic CPU workload balancing. This type of balancing is
achieved through the use of quantitative resources and the Automated Tape
Adjustment Facility. See the description of the RESOURCE Runtime scheduling
parameter in Section 3 of the CONTROL-M User Manual.
Assuming that the IOA/CONTROL-M software, Core and Repository reside on a disk which
is shared by the two CPUs, the Online facility can be invoked under both CPUs. For the
same reason, the various IOA/CONTROL-M utilities and reports can be operated on both
CPUs.
Special steps must be taken in order to simultaneously update a file from two CPUs. Before
CONTROL-M updates the Repository, it issues a special ENQ with a scope of SYSTEMS.
An ENQ-handling product (such as GRS or MIM) must be employed in order to pass the
ENQs to all CPUs and synchronize the updates. If no ENQ- handling product is employed,
data integrity is jeopardized.
Ensure that the ENQ-handling product actually handles the CONTROL-M ENQs. The
easiest way to verify this is to enter Screen 3 of the CONTROL-M Online facility under
CPU B and look at the upper right-hand corner. If the CONTROL-M monitor is up under
CPU A, the status UP should appear.
The CONTROL-M Event Manager (CMEM) can acknowledge the arrival/ending, of jobs or
started tasks, accesses to dataset, and changes to dataset disposition (i.e., allocation,
deletion, cataloging and uncataloging) performed by jobs or started tasks. If you want to
receive these acknowledgments on both CPU A and CPU B, the CMEM component must
operate on both CPUs.
Additional CONTROL-M options provide special support for the Shared-Spool
environment:
SHOUT (notification) messages can be issued to users on any CPU. (See parameter
SHOUT in Section 3 of the CONTROL-M User Manual.)
A started task (STC) can be scheduled on any CPU. (See parameter MEMLIB in Section 3
of the CONTROL-M User Manual.)
Operator commands can be issued in any CPU (See utility IOAOPR in Section 9 of this
guide.)
Assuming that the CONTROL-M monitor runs on CPU A and a command is to be issued to
CPU B, any of the following methods can he used:
The monitor can schedule a job or started task to run on CPU B and invoke procedure
IOAOPR to issue the command.
The monitor can schedule the IOAOPR STC (or job) to run on CPU A and issue the
command in such a way that it will be passed to CPU B (Under JES2, use the $M
command. Under JES3, use the *T command.)
Sample exit CTMX011A in the IOA SECUDATA library enables the user to issue
operator commands by running a dummy job without scheduling a job or a started task
via SHOUT requests.
This sample exit is suitable for all JES2 releases and for JES3 release 2.2.0 and up
(assuming that the CONTROL-M Monitor runs under the global JES3 processor).
We recommend the first method described above because:
The command always reaches CPU B.
CONTROL-M analyzes the sysout of the scheduled job or started task.
Checks whether the job or started task ran successfully or not.
This method provides advantages from a security point of view.
CONTROL-M job statistics are maintained separately for each CPU These job statistics are
used as input for the CONTROL-M Simulation and Forecasting facility. These statistics
can be viewed in screen 3.S.
From a technical point of view, the CONTROL-M monitor can run under any CPU. For
performance considerations, see CONTROL-M Tuning Recommendations earlier in this
section.
Shared Spool Configuration Without an ENQ-Handling Product
This environment is identical to the previous environment except that no ENQ handling
product is employed. Another difference is that the shared Spool may or may not be
connected to CPU B.
Shared Spool Configuration Without an ENQ-Handling Product
Aside from the restrictions listed below, all the capabilities described above also apply to
this configuration. Like the configuration described above, only one CONTROL-M monitor
is required for handling the entire shared SPOOL complex.
In order not to jeopardize data integrity, the IOA CONTROL-M Repository must not be
updated from CPU B. Therefore, all CONTROL-M components (Monitor, CONTDAY,
utilities, KSLs which update IOA/CONTROL-M files, etc.) should run exclusively on
CPU A.
To make sure that CONTROL-M files are not updated from CPU B, one or both of the
following options should be implemented:
Option 1: Use your sites security product (RACF, ACF2 or Top Secret) to deny
write/update access to the IOA/CONTROL-M files from CPU B.
Option 2: Vary off-line (under CPU B) the disk(s) on which IOA/CONTROL-M
files reside. This method is applicable only if the disk(s) do not contain other
files. There may also be a problem if CMEM is operated (see below).
Option 2 is the most effective method, but may be difficult to implement at most sites
because CONTROL-M uses only a portion of a disk and does not require a dedicated disk.
Option 1 is the easiest to implement at most sites.
If the optional CMEM facility is operated on both CPU A and CPU B CMEM must be
given read access to the IOA LOAD library and CONTROL-M monitor to-subsystem
Communication file plus write access to the subsystem-to-CONTROL-M monitor
Communication file. All files which are required by CMEM must reside on a shared
disk. This shared disk does not need to contain general IOA/CONTROL-M files. (CMEM
can operate in a multi-CPU environment without an ENQ handling product.)
As illustrated in the diagram above, terminal TERM 2 is physically connected to CPU B.
However, this terminal can be used to operate the lOA/CONTROL-M Online Facility.
If CPU A and CPU B maintain an appropriate cross-domain SNA connection through a
CTC, 37xx communication controller (or equivalent) or Token Ring connection, then the
terminal user can log on to VTAM application running in CPU A and invoke the
IOA/CONTROL-M Online Interface. Relevant VTAM applications are: TSO, ROSCOE, IOA
VTAM monitor, CICS, IMS/DC, and any VTAM application which supports the
IOA/CONTROL-M Online facility.
Shared-Spool Configuration with Multiple CONTROL-M Production
Systems
This environment may or may not use an ENQ-handling product. DISK 1 may or may not
be connected to CPU B. DISK 2 may or may not be connected to CPU A.
Shared-Spool Configuration With Multiple CONTROL-M Production Systems
Some users employ two CONTROL-M production systems in a Shared-Spool environment.
Each system employs a separate Repository. Because a single CONTROL-M system is
sufficient for controlling the whole Shared-Spool environment, two production systems are
not required and, in fact, increase the requirement for disk space, resource consumption
and maintenance. However, the following examples describe situations that could justify
using two CONTROL-M production systems.
Example 1
Some sites are service-bureaus that dedicate a whole mainframe to one customer.
If each mainframe in a Shared-Spool environment is dedicated to a different customer and
each customer requires the services of CONTROL-M, then it is desirable to distribute the
scheduling of production work and operate a separate CONTROL-M system for each
customer.
Example 2
A bank operates two CPUs in a Shared-Spool environment. Each CPU is used for a
different task one handles activities related to the stock market; the other for handles all
other activities of the bank. To maximize reliability and availability the bank operates two
separate CONTROL-M production systems. When one CPU goes down (for any reason), the
other continues performing its tasks.
These two CONTROL-M systems communicate with each other by scheduling special jobs.
For instance, CONTROL-M system A can schedule a special job which invokes the utility
IOACND to add a prerequisite condition in the IOA Conditions/Resource file of
CONTROL-M system B. This prerequisite condition can in turn trigger the submission of
jobs by CONTROL-M system B.
CMEM Operation
If each CPU is fully controlled by its CONTROL-M system, only one CMEM subsystem is
required on each CPU The CMEM which is part of CONTROL-M system A will run on CPU
A. The CMEM which is part of CONTROL-M system B will run on CPU B.
However, if each CONTROL-M system must acknowledge events which may occur under
both CPUs, then each CPU must operate two CMEM subsystems (one for CONTROL-M
system A and the other for CONTROL-M system B).
Multi-CPU Configuration With Shared-DASD Only
Multi-CPU Configuration with Shared DASD Only
This configuration consists of two mainframes which only employ shared DASD (i.e., there
is no shared Spool). Each CPU runs its own CONTROL-M system.
DISK 1 may or may not be connected to CPU B. DlSK 2 may or may not be connected to
CPU A The IOA/CONTROL-M Core and Repository do not need to reside on a shared disk.
However, a shared IOA Condition/Resources file is necessary to support this environment.
It enables communication between two CONTROL-M systems which run in different CPUs
and are not connected via a shared Spool.
Communication is established by sharing prerequisite conditions. These shared
prerequisite conditions enable the two CONTROL-M systems to know the status of
production work in both CPUs.
The two CPUs must employ a global ENQ-handling product (such as GRS, MIM, etc.). See
parameter SHRQNAM in Section 2 of the IOA Installation Guide.
CMEM Operation
If each CPU is fully controlled by its CONTROL-M system, only one CMEM subsystem is
required on each CPU. The CMEM which is part of CONTROL-M system A will run on
CPU A. The CMEM which is part of CONTROL-M system B will run on CPU B.
However, if, each CONTROL-M system must acknowledge events which may occur under
both CPUs, then each CPU must operate two CMEM subsystems (one for CONTROL-M
system A and the other for CONTROL-M system B.
NJE Network of MVS Nodes
NJE Network of MVS Nodes
MVS-to-MVS NJE Connection
This diagram shows a network consisting of two nodes. For this discussion, the node which
operates the CONTROL-M system is called the Home node. All other node are called
Remote nodes.
Many CONTROL-M sites employ a network consisting of two MVS computer systems
(nodes) connected via an NJE (Network Job Entry) link.
This type of network is usually used to connect two MVS machines that are distant from
each other. However, some sites use this type of network between two CPUs in the same
room for security reasons or during a transitional phase.
To make use of and control such a network, CONTROL-M might run on one CPU (called
the Home node) and submit selected jobs to another CPU (the Remote node). The jobs will
run at the Remote node and the sysout (or the SYSDATA) will be returned to the Home
node for analysis by CONTROL-M.
For a more detailed discussion on this subject, see member DOCMNJE in the IOA
SECUDATA library.
Note The Remote node can operate a separate CONTROL-M system. In this case, production
work in the Remote node should be controlled by its own CONTROL-M system.
However, the Home node can still send selected jobs to the Remote node as described
above.
Each CONTROL-M system can communicate with the other by submitting special jobs to
the other CPU. For instance, a special job might invoke utility IOACND to add, delete or
check for the existence of a prerequisite condition.
The following CONTROL-M options which provide special support for the NJE
environment are described in Shared-Spool Configuration above:
Issuing a SHOUT (notification) message to users in a Remote node
Scheduling a started task (STC) in a Remote node
Issuing operator commands in/to a Remote node.
Maintaining job statistics by CONTROL-M
Handling jobs originating in the Remote node operating CMEM in the Home node.
If an enterprise network consists of three MVS nodes (named Node A, Node B and Node C),
the number and location of CONTROL-M systems that should be employed depends on the
structure and goals of the enterprise.
A single CONTROL-M system is sufficient to submit production work to the whole
network. However, specific organizational structures or goals may make it desirable to
operate more than one CONTROL-M system. If the enterprise operates in a centralized
manner, a single CONTROL-M system may be sufficient. If not, multiple CONTROL-M
systems might be more desirable.
Availability considerations
CONTROL-M may be affected by events occurring on the node where CONTROL-M runs.
e.g., system down (regular maintenance or system crash), disk crash, line-down problems.
If CONTROL-M is employed on a single node, such events will affect the whole network.
However, if, each node employs its own CONTROL-M system, only one part of the network
will be affected.
Performance considerations
If many jobs are to be transferred through the communication lines, then multiple
CONTROL-M systems should he considered (in order to cut down the communications
overhead).
Note The overhead for sending jobs is usually insignificant. It is usually jobs reports which
utilize the communication lines the most when they are sent back. CONTROL-M only
requires the SYSDATA to be sent back, which is also insignificant in regard to the
communications overhead).
Disaster and backup planning
Overall disaster and backup planning requires that important production work be switched
within a short time from one node to another. If each node already employs its own
CONTROL-M system, then the transfer can be performed quickly and easily.
Special Considerations
Mainframe with PR/SM (or MDF or MLPF)
The PR/SM (Processor Resource/Systems Manager) feature in an IBM mainframe allows a
site to divide its mainframe into partitions and run multiple operating systems in
parallel.
Mainframe With PR/SM
For our purposes, we can treat each partition as a standalone mainframe computer and we
can treat the processor complex as a type of multi-CPU configuration.
To determine how CONTROL-M controls the production work in two logical partitions, we
need to determine what connection (if any) exists between the two partitions. Relevant
connections are: shared SPOOL, shared-DASD only, and NJE.
If an MVS system runs in both partitions and the only connection between them is shared-
DASD, then the description of Multi-CPU Configuration With Shared-DASD Only also
applies to this configuration.
The same considerations apply to MDF (Multi-Domain Facility) from AMDAHL and MLPF
(Multiple Logical Processor Facility) from HDS (Hitachi Data Systems).
In addition, these considerations apply to other supported CPUs with hardware
partitioning capabilities, which can be operated in either single image mode or partition
mode.
Operating MVS System(s) Under VM
For information about this topic, see CONTROL-M VM Support later in this section.
Support of Other Platforms (VM, DOS/VSE, AS/400, DEC, HP, etc.)
Note This discussion does not deal with non-MVS CONTROL-M products. For information
about these products, see the appropriate non-MVS CONTROL-M publications.
This diagram deals with a multi-CPU environment which includes one or more non-MVS
machines. The most common non-MVS platforms are: VM, DOS/VSE, AS/400, DECs
VAX/VMS, and HP.
Support of Other Platforms
The following discussion shows how an MVS-based CONTROL-M system can contribute to
this environment.
The MVS-based CONTROL-M can:
Schedule work in the non-MVS system.
Control production work which is scheduled by a non-MVS system to run on the MVS
system.
Trigger events on the non MVS system.
Interact with any hardware which supports an appropriate connection to the MVS
machine. Some of these appropriate connections are listed below.
RJE/RJP
Many systems use hardware and software to emulate an RJE station connection to an MVS
System. For example, the following systems can emulate an RJE station: VM/RSCS,
VSE/POWER Version 1, DECNET/SNA RJE, AS/400 RJE, and HP SNA/NRJE.
CONTROL-M has several options which support RJE, such as:
CONTROL-M Event Manager (CMEM) can be used to acknowledge and handle jobs
submitted from RJE. CMEM can be used to acknowledge the creation/deletion of
datasets by jobs which originated from RJE.
CONTROL-M SYSOUT options can support the routing of sysouts to RJE. RJE jobs can
use utility IOACND or other IOA/CONTROL-M utilities to communicate with
CONTROL-M.
NJE (SNA)
MVS/JES can set up an NJE connection with non-MVS systems which employ compatible
networking facilities. For example, MVS/JES NJE connections can be set up with IBM
VM/RSCS, IBM VSE/POWER Version 2, IBM AS/400 using VM/MVS Bridge, and DEC
VAX/VMS systems (through 1nterlink or Jnet).
An NJE connection provides the ability to transmit and receive jobs, in-stream datasets,
sysout datasets, commands, and messages from one computer system (node) to another.
Note The ability to send in-stream datasets via jobs is limited by data structure, recovery
capabilities, reliability, etc. Therefore, most sites which require data transfer use an
appropriate file transfer program instead.
CONTROL-M can be used to send jobs and files to the NJE node. The best way to do this is
for CONTROL-M to submit an MVS job which produces a sysout file with the appropriate
non-MVS destination.
The same methods of operation which support RJE (for example, usage of CMEM) can be
used to transfer jobs/data from the NJE node to the MVS system.
SNA Connections for Terminal Access
If basic SNA connections can be established between the two systems and if the non-MVS
platform employs appropriate terminals, a terminal user connected to the non-MVS
platform can log on to a VTAM application running on the MVS platform.
This capability enables a terminal user to invoke the IOA/CONTROL-M Online facility by
logging on to VTAM applications (such as TSO, CICS, IMS/DC, the IOA VTAM monitor, or
any other VTAM application which supports the IOA/CONTROL-M Online facility). This
method makes all of CONTROL-Ms tracking and control options available to the user.
For example, users of the following terminals can access VTAM applications running under
MVS: DECnet, HP, AS/400, VM (through VM/VTAM), and VSE (through VSE/VTAM).
Support of Network Software
The following diagram deals with a multi-CPU environment which consists of an MVS
platform running CONTROL-M and another platform which can be an MVS or a VM, VSF,
AS/400, VAX/VMS, TANDEM/GUARDIAN 90, or PC platform.
Both platforms operate a Network Management product and/or a File Transfer product.
Support of Network Software
In this environment, the CONTROL-M system can:
Transfer data to the other system
Transfer alerts to the other system
Trigger events in the other system
Schedule work in the other system
CONTROL-M can interact with various Network Management and File Transfer products
which use existing connections between the MVS platform and the other platform.
Network Management Products
Systems which are connected by Network Management products can use this connection to
transfer triggers (events) from the CONTROL-M system to another SNA system.
CONTROL-M can schedule a dummy job which sends a SHOUT message to the system
console. The message can be captured by NETVlEW, which triggers a command that is
transmitted by NETVIEW to a remote VSE system console, or through a TAF terminal to a
remote application such as IMS/DC or CICS.
File Transfer Products
Various File Transfer products can be used under MVS to transfer data from MVS to other
systems, and vice versa.
These File Transfer programs include FTP and BDT from IBM, XCOM 6.2 from
SPECTRUM CONCEPTS, and CONNECT DIRECT (formerly NDM). In addition, the
TSO/E TRANSMIT and RECEIVE commands can be used to send and receive files.
Each product has its own transfer method and may or may not have easy-to-use interfaces
and exits. We provide some general tips on how CONTROL-M can interface with these
products. We recommend that you check with the appropriate software representative to
determine whether or not these tips are suitable for your environment.
Tips for Interfacing with File Transfer Products
CONTROL-M can periodically trigger a file transfer from the MVS system to the other
system. This technique can be used to pass data to the other system. In some cases, the
transferred data can trigger a process in the target system.
All File Transfer products can be interfaced via batch and/or TSO. CONTROL-M can
submit a job which interfaces with the File Transfer product by invoking the
appropriate program under batch or by operating TSO Batch and invoking the File
Transfer products TSO interface.
The CMEM facility can be used to acknowledge the receipt of a file from another system
and, for instance, to order a job to handle that file (or add a prerequisite condition
indicating that the file arrived). CMEM can acknowledge the receipt of files only under
the following conditions:
The file is received by a started task (STC) or job. Most File Transfer products use
an STC for this functions. However, TSO RECEIVE and TRANSMIT operate under
TSO.
The File Transfer product uses regular MVS ALLOCATION/DEALLOCATlON
facilities (i.e., SVC 99) to create the new file.
Note CMEM can acknowledge the receipt of files. However, it cannot determine whether the
file transfer process was successful or not.
If the File Transfer product provides appropriate exits, these exits can be used to inform
CONTROL-M of events occurring within the File Transfer product.
For example, if the other system has a File Receipt exit, utility IOACND can be called by
this exit to add a prerequisite condition which informs CONTROL-M that a file has been
received.
Some products provide the option to submit a job after the file transfer process has
finished. Such a job can invoke utility lOACND to add a prerequisite condition to the IOA
For information about the built-in CONTROL-M interface to CONNECT DIRECT, see
CONNECT DIRECT Support in Section 6 of the CONTROL-M User Manual.
CONTROL-M

VM Support
Introduction
Most medium to large computer centers maintain a complex production environment based
on multiple operating systems and platforms. A typical, large computer center may employ
MVS/ESA, VM, VAX/VMS, AS/400, UNIX machines, PCs, etc.
One of the most popular combinations at these computer centers is the coupling of MVS and
VM. These computer centers require integrated production control capabilities for both
operating systems. One aspect of integrated production control is the capability to
automate processes in the VM environment. For example, VM commands or EXECs must
automatically be executed under VM at certain times, or according to events which occur in
either MVS or VM. Usually, these VM commands or EXECs must be executed in certain
sequences, and the results must be checked to ensure that the commands/sequences have
completed successfully. Another aspect of integrated production control is the
synchronization of processes in and between MVS and VM. For example, an MVS-based
application may require an input file to be received from VM before the application can
proceed.
This section details how CONTROL-M and IOA can easily be implemented in order to
automate control of VM operations through standard MVS and VM operating system
functions and specific CONTROL-M features.
There is no single answer or solution to every problem. Much depends on the hardware and
software configurations implemented at your site. Some of the solutions described here
may not be appropriate for your site. Therefore, for some problems, more than one solution
or approach has been presented. Each site can determine which solution is most suitable
for its environment.
VM Configurations
To automate processes in the VM environment and synchronize MVS and VM processes, the
VM configuration must facilitate appropriate communication with MVS. Three popular
configurations exist for running MVS and VM operating systems at the data center:
MVS running under VM
MVS and VM running on separate computers
MVS and VM running under PR/SM (or MDF or MLPF)
The configuration implemented at your site will determine which of the techniques
described below are applicable.
MVS Running Under VM
The VM system runs the Control Program (CP) together with a number of Conversational
Monitor System (CMS) virtual machines. In addition, an MVS virtual machine is activated
which operates CONTROL-M.
When MVS is running under VM, the following options are available for transferring data
between the MVS and VM operating systems:
A VM CP command can be issued in the MVS machine, using the DIAGNOSE machine
command. This allows the MVS machine to issue commands to be processed by VM.
If an RSCS machine is operated under VM, then RJE or NJE connections can be
established between VM and MVS. This allows jobs and sysouts to be transferred
between MVS and VM.
If a VM/VTAM machine is operated under VM, SNA connections can be established
between MVS and VM. This allows a VM terminal user to invoke the IOA Online
interface.
If a disk or minidisk is shared between MVS and VM, a PS or PO file created under MVS
can be read from VM CMS.
If a card reader/punch is defined in MVS, files can be passed between MVS and VM.
MVS and VM Running on Separate Computers
The above VM and MVS systems run on separate computers. However, on some levels,
communication exists between the two computers.
The options available for transferring data between the MVS and VM operating systems
running on separate computers include the following:
If an RSCS machine is operated under VM, then RJE or NJE connections can be
established between VM and MVS. This allows jobs and sysouts to be transferred
between MVS and VM.
If a VM/VTAM machine is operated under VM, SNA connections can be established
between MVS and VM. This allows a VM terminal user to invoke the IOA Online
interface.
If a disk is shared between MVS and VM, a PS or PO file created under MVS can be read
under VM.
MVS and VM Running Under PR/SM, MDF or MLPF
The PR/SM (Processor Resource/Systems Manager) feature in an IBM mainframe allows the
installation to (optionally) divide the mainframe into partitions and run multiple operating
systems in parallel.
For our purposes, each partition can be regarded as a standalone mainframe computer.
Therefore, when partitioning is used, we can regard the processor complex as a type of
multi-CPU configuration.
If, as in the diagram above, one partition runs MVS and the other partition runs VM, the
previous discussion of VM and MVS running on separate machines is also applicable.
The above discussion of the PR/SM feature also applies to users of MDF (Multi-Domain
Facility) from AMDAHL, MLPF (Multiple Logical Processor Facility) from HDS (Hitachi
Data Systems), and any other supported CPU with hardware partitioning capabilities.
Invoking the IOA Online Facility From a VM Terminal
If appropriate interactive communication connections are set up between the VM and MVS
operating systems, a VM terminal user can log onto an MVS VTAM application which
supports the IOA Online facility (e.g., TSO, CICS, IMS/DC, IOA VTAM Monitor, IDMS/DC,
ROSCOE and COM-PLETE).
All examples in this document assume the use of an IOA VTAM monitor. However, each site
should determine which of the above-mentioned MVS VTAM applications is most suitable.
Once the VM user has entered the IOA Online facility, all tracking and control options of
CONTROL-M and IOA are available to the user. For example, the user can add or delete
prerequisite conditions, define a new job schedule, order a job, view job run results, hold a
job, etc.
Several methods exist for setting up interactive communication connections, depending on
the software and hardware configurations used at each site:
Dialing into the MVS machine (MVS under VM only)
Using VM/VTAM
Using IOAs Logical Terminal Emulator
Using a session handling product
Dialing Into the MVS Machine (MVS Under VM Only)
A VM terminal user can dial directly into the MVS machine (at a predefined address),
receive the MVS VTAM logon screen, and then log onto the IOA VTAM monitor running
under MVS.
Using VM/VTAM
If VM/VTAM is employed under VM, a VM terminal user can dial into the VM/VTAM
machine, and then establish (from the VM/VTAM screen) a cross-domain session with the
IOA VTAM monitor running under MVS.
Using IOAs Logical Terminal Emulator
The IOA Logical Terminal Emulator can be employed in conjunction with VM/VTAM. This
facility allows the user to establish a VTAM session without leaving CMS. A session can be
established in this way with the IOA VTAM monitor running under MVS. At the end of the
session, the user remains at the VM/CMS machine.
In addition, the users sign-on procedure can be taught this option and, on future
invocations, can automatically repeat the option. See Section 2 of the IOA Installation
Guide for additional information on this subject.
Using a Session Handling Product
There are several session handling products available for the VM environment, such as
VM/Pass-through (PVM), Tubes and Vterm.
If such a product is employed under VM, a VM terminal user can use that product to log on
the MVS system, and then log on to the IOA VTAM monitor running under MVS.
File Transfer From MVS to VM
General
This section demonstrates several techniques for sending a sysout or file to VM. Some of
these techniques utilize CONTROL-M functions. Others utilize standard functions of
MVS/JES, VM, and/or other products.
All of the following JCL examples assume that:
An NJE connection exists between the MVS and VM machines.
The VM node ID is VMPROD.
The sysout/report is to be routed to a VM machine (user) named USER1.
The sysout class is A.
Sysouts or files which are sent to the VM user via NJE/RSCS are placed in the VM users
Reader queue. The VM user periodically checks his/her Reader queue via the RL (RDRLIST)
command. If a file from MVS is found, the user can, for example, browse the file (via the
PEEK command) or move it to the A minidisk (via the RECEIVE command).
Routing the Production Jobs Report to VM via JCL
A specific report created by a CONTROL-M production job can be routed via NJE services to
a VM machine (user), simply by defining the destination of the report in the jobs JCL. The
following examples demonstrate how to implement this via standard MVS and JES
statements.
Route the report to a certain VM user via parameter DEST=(node,user) in the
appropriate DD statement:
//REPORT DD SYSOUT=A,DEST=(VMPROD,USER1)
Route the report to a specified VM user via an MVS OUTPUT statement and the reports
DD statement referencing that MVS OUTPUT statement
//JOB1 JOB ...
//OUTREP OUTPUT DEST=VMPROD.USER1
//STEP1 EXEC PGM=...
//REPORT DD SYSOUT=A,OUTPUT=*.OUTREP
Route printed sysout files of the job to a specified VM user via a JES2 /*ROUTE PRINT
statement:
Note Punched sysout files of the job can be sent to VM via the JES2 /*ROUTE PUNCH
statement. A punched SYSOUT file consists of 80-character records. Most sites define
JES output CLASS B as a punch class.
//JOB1 JOB ...
/*ROUTE PRINT VMPROD.USER1
//STEP1 EXEC PGM=...
//REPORT DD SYSOUT=A
Routing Production Job Sysout to VM via JCL
When a CONTROL-M production job has finished executing, the CONTROL-M monitor
requires that the jobs first three sysout files (SYSDATA) reside in the MVS spool in held
mode, in order to analyze how the job has completed. Once the SYSDATA has been
analyzed, it can be purged, released for printing, etc.
Sometimes, the SYSDATA of a CONTROL-M production job may need to be routed to a VM
user. This can be accomplished by specifying two MVS output statements in the jobs JCL.
These two output statements, shown below, cause the creation of two copies of the
SYSDATA. One copy is assigned standard attributes and can be analyzed by CONTROL-M.
The other copy is directed to the VM machine named USER1.
//jobname JOB ...
//COPY1 OUTPUT JESDS=ALL,CLASS=*
//COPY2 OUTPUT JESDS=ALL,CLASS=A,DEST=VMPROD.USER1
.....
Routing Production Job Sysout to VM via CONTROL-M Sysout Functions
CONTROL-M sysout functions can route the production jobs sysout (or parts of it) to a VM
node. Only the VM node name can be specified (i.e., no user ID can be assigned within the
destination name).
However, if the site uses MVS/ESA JES2 Release 4.1 and above with APAR OY64290 applied,
a JES2 destination ID (defined in JES2 as nodeid.userid) can be specified. As a result, the
output is routed to a specific VM user operating in the VM node.
CONTROL-M can then be used to route selected outputs of a production job (e.g., the whole
sysout, one or more reports, messages, files, etc.) to a specific VM machine (user).
Sending a File to VM in the Form of a Sysout
CONTROL-M can be used to trigger file transfer to a VM machine. Perhaps the easiest way
to perform the file transfer is for CONTROL-M to schedule a job to run under MVS and
produce a sysout file with the appropriate destination.
Note In the example below, the data to be sent are 80-byte records. In order to print larger
data records, use DD statement SYSUT1 to reference a sequential input file which
contains these larger data records.
Example
//jobname JOB ...
//PRINT EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT2 DD SYSOUT=A,DEST=(VMPROD,USER1)
//SYSUT1 DD *
data to be sent
data to be sent
data to be sent
/*
//
File Transfer Products
See File Transfer Products under CONTROL-M Multi-CPU Support earlier in this
section for information about this topic.
Utilize a Shared Disk Between MVS and VM
If a disk or minidisk is shared between MVS and VM, a PS or PO file created under MVS can
be read from VM CMS.
Sometimes there is no need to transfer the PO/PS file to VM. Perhaps just a notification is
needed to inform the user that the file created under MVS is now available. Various user
notification options are described under IOA An Integrated Solution below.
For additional information, refer to the appropriate IBM manual for a description of the
various VM CMS commands that process and query MVS datasets (MOVEFILE, STATE, etc.).
Note MVS catalog services cannot be accessed in a standard way from VM. Therefore, to read
the file, the VM CMS user must know on which disk the file resides.
Triggering an Event in CONTROL-M by a VM User
Two techniques for triggering an event in CONTROL-M are described below. Triggered
events can cause CONTROL-M to run jobs in the MVS environment, stop jobs from being
submitted, order VM-generated jobs into CONTROL-M, etc.
Submitting a Job to MVS to Execute a CONTROL-M Utility
A VM user can communicate with CONTROL-M by submitting a job which invokes an
appropriate utility. For example, a VM user can submit a job to MVS which invokes utility
IOACND or another IOA/CONTROL-M utility.
For example, the job may activate utility IOACND in one of its job steps in order to add or
delete a certain prerequisite condition. Prerequisite conditions can trigger various events
in CONTROL-M and IOA (e.g., cause jobs to be submitted; stop jobs from being submitted).
As another example, a job can invoke a KSL utility. KSL utilities can perform any function
which is available under the IOA Online facility.
Prerequisite condition can also be added and deleted by CMEM (see below).
Caution As a default, all VM-generated jobs receive the same security attributes in MVS,
regardless of who generated them. Consult your security administrator about how this
problem is handled at your site.
Submitting a Job to MVS to be Monitored by CMEM
The CONTROL-M Event Manager Facility (CMEM), operating under MVS, can acknowledge
a job originating from VM (by its job name) and perform various actions upon
arrival/completion of the job or upon specific job execution events.
Sample Functions Available via CMEM
Give CONTROL-M full control over job processing.
When a job is submitted by a VM user to MVS, CMEM places a job order for that job in
the CONTROL-M Active Jobs File. CONTROL-M treats the job as a regular job.
Note If the job is submitted with parameter TYPRUN=HOLD in the JOB statement,
CONTROL-M releases the job for execution when all scheduling requirements are
fulfilled.
When the job finishes execution, execution analysis is performed as usual. If the job
order contains post-processing instructions, they will be carried out in the same
manner as for a regular job.
Add or delete a prerequisite condition in case of job arrival/completion.
CMEM can be ordered to add/delete a prerequisite condition when the VM-generated job
appears on the MVS internal reader, or when the VM-generated job finishes execution
in the MVS environment.
For example, CMEM can be ordered to add prerequisite condition SEND-NOW-FILE1
when a job named VMJOB1 appears in the MVS system. The SEND-NOW-FILE1
prerequisite condition can cause CONTROL-M to submit a job which causes an MVS file
named FILE1 to be sent to VM. (Various techniques are described in Sending Sysouts and
Other Files From MVS to VM above.)
The addition/deletion of prerequisite conditions in this manner does not interfere in any
way with the execution of the VM-generated job, nor does CONTROL-M analyze
execution results for the job.
Monitor dataset usage of the job.
CMEM can be ordered to monitor the execution of a VM-generated job with regard to
dataset creation/deletion/access.
For example, CMEM can be ordered to add prerequisite condition FILE1-CREATED when
a VM-generated job creates a file named FILE1 in the MVS system. Prerequisite
condition FILE1-CREATED may trigger a job which sends a user notification back to VM.
(Various techniques are described below.)
For additional information about CMEM, see File Transfer Products above and see
Section 4 of the CONTROL-M User Manual.
CONTROL-M Triggering of Events in VM
This topic demonstrates how to trigger an event in the VM environment. For example,
events can be triggered which cause user notification, attach/detach devices, operate a
virtual machine in disconnected mode, initiate a backup process, etc.
Depending on the software and hardware configuration used at your site, there are at least
two methods of triggering an event:
Issuing a VM CP Command via IOAOPR (MVS Under VM only)
Executing VM Commands via the IOAVAUTO machine
Issuing a VM CP Command via IOAOPR (MVS Under VM only)
If the MVS system is running under VM, you can use utility IOAOPR to issue a VM CP
command to VM. Any command which begins with the letters CP followed by a blank is
considered by IOAOPR to be a VM CP command.
Note The MVS machine must be defined with appropriate security privileges and
authorizations to enable IOAOPR to issue the commands.
Utility IOAOPR returns a completion code to indicate whether or not the VM CP command
has succeeded. CONTROL-M can check the completion code and act accordingly. (For
example, CONTROL-M can add or delete a prerequisite condition, reschedule the IOAOPR
job after several minutes, etc.)
Note If utility IOAOPR is operated under an MVS which is not running under VM, IOAOPR
issues an error message if ordered to process a VM CP command.
For additional information about utility IOAOPR, see Section 9 of this guide.
In the following examples, utility IOAOPR is run as a job, and the VM command to be
executed is defined in the PARM field.
Example 1
//jobname JOB ...
//COMMAND EXEC IOAOPR,PARM='CP MSG USER1 JOBA ENDED OK
This job notifies the VM user, USER1, that JOBA has ended OK.
Example 2
//jobname JOB ...
//COMMAND EXEC IOAOPR,PARM='CP AUTOLOG BATCH01'
This job operates a VM machine named BATCH01 in disconnected mode.
Note VM/ESA sites can use the XAUTOLOG command instead of the AUTOLOG command.
Executing VM Commands via the IOAVAUTO Machine
A special VM AUTOLOG machine (called IOAVAUTO below) can be set up to execute
commands under VM, and (optionally) inform CONTROL-M as to whether or not the
commands have been performed successfully.
Note The IOAVAUTO machine must be defined with appropriate security privileges and
authorizations to enable IOAVAUTO to execute the VM commands.
One way in which CONTROL-M can send a command file to IOAVAUTO is by submitting a
job which produces a sysout file to be passed to the VM IOAVAUTO machine. The sysout file
can contain one or more REXX commands. The sysout file will be passed by JES to VM
(RSCS) and will be placed on IOAVAUTOs reader.
The IOAVAUTO machine (driven by EXEC IOAVEXEC) awaits the arrival of command files
sent to the machines reader. When a reader file arrives, it is received and processed. In
addition, the commands processed are logged on minidisk A in file IOA LOG.
Optionally, an indication can be sent to CONTROL-M as to whether or not the commands
have succeeded, enabling CONTROL-M to take appropriate action. (For example,
CONTROL-M can trigger another job, reschedule the same commands to IOAVAUTO after
several minutes, etc.).
EXEC IOAVCND is supplied to inform CONTROL-M as to whether or not the request has
been performed successfully. IOAVCND generates a job and submits it to MVS. The job
operates utility IOACND to add/delete a prerequisite condition in CONTROL-M. The
example below illustrates how to call utility IOAVCND.
Example
An important message has to be delivered to VM user USER1.
JOB1 is defined in CONTROL-M as a cyclic job, with an interval of 20 minutes. JOB1 is
triggered by prerequisite condition SHOUT-REQUIRED. The JCL for JOB1 is shown below:
//JOB1 JOB ....
//REQUEST EXEC PGM=IEBGENER
//SYSIN DD DUMMY
//SYSUT2 DD SYSOUT=A,DEST=(VMPROD,IOAVAUTO)
//SYSUT1 DD DATA,DLM=@@
/* REXX EXEC */
MSG USER1 Production Job PRDUPDT has abended!
IF RC = 0 THEN EXEC IOAVCND DELETE SHOUT-REQUIRED 0101
EXIT(0)
@@
//
JOB1 is submitted by CONTROL-M upon the creation of prerequisite condition SHOUT-
REQUIRED (by another job or process). JOB1 runs under MVS and produces a sysout file
containing four REXX statements to be passed to the VM IOAVAUTO machine.
The IOAVAUTO machine reads the file from its reader and processes the command file.
If the MSG command is performed successfully by the IOAVAUTO machine, a job is sent to
MVS which deletes prerequisite condition SHOUT-REQUIRED.
If the MSG command is unsuccessful, no feedback is sent back to MVS. As a result, JOB1
is run again by CONTROL-M (about 20 minutes after its previous run), and another
attempt is made to deliver SHOUT message to the VM user.
Issuing a SHOUT Message to a VM User
General
SHOUT is the IOA notification facility by which operations personnel and departmental
users are notified of significant events in the production environment. The SHOUT
mechanism enables CONTROL-M to send notifications to VM users instead of, or in addition
to, other MVS destinations.
Note The VM operating system does not employ a function equivalent to the MVS
BROADCAST function, which maintains user notification messages. If a SHOUT is
issued to a VM user who is not logged on at that time or to a VM user who has
suppressed the receipt of messages, the SHOUT will not be effective.
The following is a brief list of IOA techniques can be used to send notification messages to a
VM user. All of these techniques allow you to verify that the notification message has
reached its destination.
Using utility IOAOPR
Using the VM IOAVAUTO machine
Other IOA options
Using Utility IOAOPR
If MVS is running under VM, CONTROL-M can schedule an IOAOPR job or started task to
issue a SHOUT message to a VM user.
Additional information about utility IOAOPR and a detailed example of how to issue the
notification can be found under the topic Issuing a VM CP Command via IOAOPR above.
Using the VM IOAVAUTO Machine
CONTROL-M can schedule a request to the VM IOAVAUTO machine to issue a SHOUT
message to a VM user, and (optionally) inform CONTROL-M whether or not the SHOUT has
been performed successfully.
Additional information about the VM IOAVAUTO machine and a detailed example of how to
set up the notification request can be found under the topic Executing VM Commands via
the IOAVAUTO Machine above.
Other IOA Options
Additional options exist if CONTROL-O or CONTROL-O/PC are operated at the site. See the
topics CONTROL-O and CONTROL-O/PC below.
IOA An Integrated Solution
General
Some unique facilities in various IOA products which may be of interest to the VM
operations staff are described below.
CONTROL-O
CONTROL-O is the IOA Console Automation Product. The main CONTROL-O functions
relevant to VM are:
Issuing a VM CP command
If MVS is running under VM, CONTROL-O can issue VM CP commands via parameter DO
COMMAND.
Accessing VM machines via KOA
The KeyStroke OpenAccess Facility (KOA) permits two-way communication between
CONTROL-O and any VTAM application. If VM/VTAM is operated under VM, CONTROL-O
can log onto a VM machine.
For additional information, refer to the documentation of VM SolveWare in the
CONTROL/SolveWare Solutions Guide.
CONTROL-O/PC
CONTROL-O/PC is the IOA Outboard Automation Product, designed to manage multiple
heterogeneous systems. The main CONTROL-O/PC functions relevant to VM are:
VM system and hardware console support
CONTROL-O/PC can initiate and perform the IML/IPL process on local or remote VM
systems, issue operator commands and automatic responses, etc.
Logon to VM applications
CONTROL-O/PCs 3270 emulation session support enables it to log on to one or more
virtual machines running applications.
Enterprise-wide automation
CONTROL-O/PC can fully control the MVS and VM systems from a single, centralized
point.
Among other things, CONTROL-O/PC can be used to:
Consolidate console messages from both MVS and VM consoles in one window.
Coordinate actions across MVS and VM platforms. For example, when a certain message
appears on the MVS console, CONTROL-O/PC can notify a VM user.
CONTROL-D
CONTROL-D is the IOA output management/distribution product, providing scheduling and
control for every aspect of report processing and distribution.
Report destinations of up to 16 characters can be assigned in all relevant CONTROL-D print
options. Therefore, CONTROL-D can route selected outputs (bundles) to specific VM
machines (users).
Disaster Recovery Planning
Overview
This topic describes disaster recovery tasks that should be performed in advance. If
necessary, one can plan to activate the CONTROL-M monitor on a different computer
system in the same data center (i.e., multi-CPU sites) or at a backup site.
Prepare the disaster recovery plan (i.e., a set of documented steps and procedures to
implement in a specific order when the need arises) in advance. The documentation and
software which form the disaster recovery plan must always be available so that the plan
can be implemented quickly and easily. All of the topics discussed below should be
considered.
Recovery Tools
The following tools, if properly implemented in advance, can be used for disaster recovery.
Dual Checkpoint Mode
The CONTROL-M monitor can work in dual checkpoint mode. Under this mode, the
CONTROL-M monitor maintains duplicate copies (mirror files) of the CONTROL-M Active
Jobs file (CKP) and the IOA Conditions/Resources file (RES/SNC). If a disk crash which
makes the primary files inaccessible, they can be restored from the mirror files.
Note For reasons of physical safety, the mirror Active Jobs file (CKP) and IOA
Conditions/Resources file (RES/SNC) must be placed on a different disk than the
other CONTROL-M files.
The installation procedure for dual checkpoint mode is described in Steps 4.2 and 7 of
Section 2 and in Steps 2 and 3.1 of Section 3 of the IOA Installation Guide.
When working in dual checkpointing mode, the CONTROL-M monitor keeps the Active
Jobs mirror file synchronized with the primary Active Jobs file. The mirror file should be
protected from any update by another source. If either the primary or mirror file becomes
damaged, the CONTROL-M monitor will shut down with an appropriate message.
To resume CONTROL-M monitor operation, the damaged file must be restored.
To restoring the Active Jobs file, perform the following steps:
1. Allocate and format a new Active Jobs file using utility CTMFRCKP.
2. Run utility CTMCAJF. Use the undamaged Active Jobs file as input and the newly
created Active Jobs file as output.
3. Rename the damaged file. Then rename the newly created Active Jobs file with the
original name of the damaged primary or mirror file.
4. Restart the CONTROL-M monitor.
To restore the IOA Conditions/Resources file, perform the following steps:
1. Allocate and format a new IOA Conditions/Resources file using utility IOAFRRES. See
Appendix D of the IOA Installation Guide for information about the structure and
space requirements of the IOA Conditions/Resources file.
2. Run utility IOACOPRS. Use the undamaged IOA Conditions/Resources file as input
and the newly created IOA Conditions/Resources file as output.
3. Rename the damaged file. Then rename the newly created IOA Conditions/Resources
file (RES and SNC) with the original name of the damaged primary or mirror file.
4. Restart the CONTROL-M monitor.
Journaling
Journaling is an optional feature that can be implemented by the IOA administrator. If
CONTROL-M installation parameter JRNL is set to Y (Yes), changes made to the Active
Jobs file and prerequisite condition added or deleted in the IOA Conditions/Resources file
are recorded in the Journal file. If the Active Jobs file and/or IOA Conditions/Resources file
must be restored, the Journal file can be used to implement the restoration.
Note Changes to control resources and quantitative resources are not recorded in the
Journal file and therefore cannot be restored via he Journal file.
Journal File Initialization
Journal file initialization is performed by the CONTROL-M monitor as part of New Day
processing after procedure CONTDAY has completed successfully. Initialization consists of
the following steps:
Journal file initialization All previous data in the Journal file is deleted. The file is
initialized with date information that establishes synchronization with the Active Jobs
file.
Active Jobs file snapshot A snapshot of the Active Jobs file is taken. If the Active Jobs
file must be restored, this snapshot file serves as the base file upon which restoration is
performed.
IOA Conditions/Resources file snapshot A snapshot of the prerequisite conditions in
the IOA Conditions/Resources file is taken. If the IOA Conditions/Resources file must
be restored, this snapshot file serves as the base file upon which restoration is
performed.
Journal File Commands
Journal file activity is controlled by issuing modify commands to the CONTROL-M
monitor. The following modify commands are available:
F CONTROLM,JOURNAL=ENABLE
This command initializes journaling. The steps described above under Journal File
Initialization are performed. Thereafter, changes made to the Active Jobs file and changes
made to prerequisite conditions in the IOA Conditions/Resources file are recorded in the
Journal file.
F CONTROLM,JOURNAL=DISABLE
This command stops journaling. The CONTROL-M monitor continues normal processing
without recording any changes in the Journal file.
Restoration
Utility CTMRSTR is used to restore the Active Jobs file and, optionally, prerequisite
conditions in the IOA Conditions/Resources file. This utility is documented in Section 9 of
this guide. When running this utility, the following items should be considered:
The CONTROL-M monitor and ECSGATE must be shut down when running utility
CTMRSTR. If parameter CONDITIONS NO is specified in the utility job stream,
CONTROL-D and CONTROL-O will not be affected. If parameter CONDITIONS YES is
specified, the operation of CONTROL-D and CONTROL-O could be affected by changes
to prerequisite conditions in the IOA Conditions/Resources file.
CONTROL-M and ECSGATE must be activated after restoration. Other IOA products
need not be recycled.
The ALTRES and ALTCKP files are fully updated when the CONTROL-M monitor is
initialized. Therefore, no special handling is needed for the restored Active Jobs file
and the restored IOA Conditions/Resources file.
If parameter ENDTIME specifies a date/time which is earlier than the timestamp on
the last entry of the Journal file, not all entries in the Journal file will be restored.
When the monitor is activated with the restored Active Jobs file, the following message
will be issued with a reply request:
CTML14E JOURNAL FILE IS NOT SYNCHRONIZED WITH NEWDAY PROCESSING
The following replies are possible:
C Continue without journaling. The CONTROL-M monitor continues normal
execution without updating the Journal file. This option can be used to ensure
that CONTROL-M is running properly after restoration. If necessary,
CONTROL-M can be shut down to perform restoration again. If no problems are
encountered after restoration, the command JOURNAL=ENABLE can be used to
reactivate journaling.
I Initialize the Journal file. Journaling is activated immediately after initialization
and synchronization with the Active Jobs file. All data used to restore the Active
Jobs file is deleted.
E Shut down the CONTROL-M monitor. The Journal file is not initialized.
Planning and Creating a Disaster Recovery Plan
MVS, JES, Exits and Other Definitions
Any defined links (e.g., exits) between MVS, JES (or any other software product or
application) and CONTROL-M should be documented, backed up and defined in the
disaster recovery plan.
Example
Adding the CONTROL-M LOAD library to the LLA facility.
Authorizing the LOAD library.
Changes to MVS exits.
Changes to JES parameters and exits.
TSO Logon procedures and authorizations.
Security Considerations
All security parameters should be backed up in such a way that they can be installed in the
backup computer as a whole, not as a patch ad hoc installation.
Special care should be taken with respect to the following:
The correct implementation of the security authorizations needed by the CONTROL-M
monitor (i.e., defining the CONTROL-M monitor and its special authorization to the
security package used in the backup computer).
All security parameters and definitions should be backed up and copied to the backup
computer.
Third-party vendor exits relating to CONTROL-M (e.g., RACF exit for R1.7 and R1.8
see the RACF Security Guide) should be copied, installed and checked in the backup
computer, thus enabling a quick and correct implementation if the need arises.
CONTROL-M security exits, if used, should be checked and passed as a part of the
disaster recovery plan.
Scheduling Libraries and Other Production Libraries
The datasets listed below should be backed up at regular intervals, so that they will be
available if needed:
CONTROL-M scheduling libraries.
Production JCL libraries.
Production parameters libraries.
Production symbols libraries.
These libraries, which are used by CONTROL-M, should be backed up together. The
recommended time to perform this backup is just after the New Day procedure has ended OK.
This backup is important because it reflects a picture of the production environment just
before production begins. If a production application must be run again (e.g., because a
programming error entered corrupt data in the database) the backup can be used to
reconstruct the environment.
If CONTROL-R is installed, an alternative solution is to utilize the History Jobs file.
During New Day processing, jobs which ended OK or expired (according to job scheduling
definition parameters) are deleted from the Active Jobs file. If these jobs are placed in the
History Jobs file during New Day processing, they can be easily restored (by request) to the
Active Jobs file for subsequent restart. See Section 6 of the CONTROL-M User Manual for
additional information.
Backup Procedures
CONTROL-M files and appropriate production libraries should be backed up periodically.
It is recommended that this backup be made just before batch processing begins. The
backup frequency depends on your sites requirements.
The New Day procedure creates a backup of the Active Jobs file before it begins deleting
yesterdays jobs. The backup (DSN suffix BKP) should reside on a different disk than
the Active Jobs file. This standard backup enables the internal recovery of the New Day
procedure in case of cancellation, abends, system crash, etc.
The Active Jobs file should be backed up by utility CTMCAJF. The IOA
Conditions/Resources file (RES,SNC) should be backed up by utility CTMCOPRS. These
backups can be copied later from disk to tape or cartridge using any standard copy
procedure. These utilities can be executed any time without integrity problems because
they are synchronized with the CONTROL-M monitor.
The CONTROL-M Log should also be placed on a different disk than the other
CONTROL-M files.
CONTROL-M Parameter Definitions
The CONTROL-M installation procedure, parameters and exits should be tailored to the
backup computer. The CONTROL-M production control system must be installed and
checked.
Examples
CONTROL-M installation parameters (e.g., HLDCLAS, INTERVL, QNAME,
SHRQNAM, ARCUNIT) may change depending on the backup computer. (See Steps 2
and 3 in Section 3 of the IOA Installation Guide.)
The mode of operation may differ, i.e., Dual Checkpoint mode or not. (See Step 4.2 in
Section 2 of the IOA Installation Guide.)
Installation parameter CPUS must be adjusted to the backup computer. (See Step 4.3
in Section 2 and Step 3.5 in Section 3 of the IOA Installation Guide.)
Take a close look at the installation procedure. Appropriate adjustments should be
documented in the disaster recovery plan.
Catalog Considerations
Use a shared catalog when working in a multi-CPU environment. In case of a computer
crash, all the relevant files will remain cataloged in the backup computer. If any files are not
cataloged in the shared catalog, they should be cataloged in advance in the backup computer.
Defining an Authorized TSO User
Define a special TSO user as part of the disaster recovery plan. Give this user the same
security authorizations as the CONTROL-M monitor.
Examples
Ability to access all production JCLs, parameters and AutoEdit Facility symbol
libraries (in read mode).
Ability to issue the TSO submit command from this special TSO user.
Authorization to submit jobs on behalf of other users. This authorization should enable
this special TSO user to submit jobs as if they were submitted by CONTROL-M.
Problem Resolution
General
Various types of problems can occur in the CONTROL-M environment. Examples include:
System crash (software and hardware).
CONTROL-M abends.
Disaster recovery relocation.
System maintenance (e.g., a new MVS release is installed).
Recommended solutions are presented for each of these problems.
CONTROL-M Structural Recoverability
The CONTROL-M production control system should never be down. The CONTROL-M
monitor, Online facility, ISPF utilities, Key-Stroke Language (KSL) and batch utilities are
separate components. Most of them will continue working even if other components are
inoperable.
System Crash Auto Recovery Options
The CONTROL-M LOAD library, Core and Repository (i.e., Active Jobs file (CKP), IOA
Conditions/Resources file (RES,SNC), History Jobs file, and IOA Log file) should be restored
in order to activate the CONTROL-M monitor in the backup site or the original site.
Once the monitor is active, it will check the JES queues and the Active Jobs file. The
status of active jobs that are not on the JES queues will change to JOB DISAPPEARED.
Other jobs will be tracked, scanned or submitted when they are eligible.
Automatic handling of a system crash is illustrated in Example 3 below.
System Crash
The CONTROL-M monitor is usually started automatically as part of the IPL procedure. If
any CONTROL-M files are inaccessible, the monitor will shut down with an appropriate
message.
Because the CONTROL-M monitor is usually already active, it will resume production
processing automatically.
CONTROL-M File(s) are Inaccessible
Disaster recovery from file inaccessibility (e.g., file deleted by mistake, disk crash, etc.) is
generally an easy task. Dual file management, as well as appropriate backup and placing
procedures, provide a good solution to this recovery problem.
Active Jobs file or IOA Conditions/Resources file is inaccessible Dual mode
A dual IOA Conditions/Resources file (RES,SNC) and a dual Active Jobs file (CKP) can be
defined.
If the above files are inaccessible, the CONTROL-M monitor will shut down with an
appropriate message. To resume production operations, the damaged files can be restored
from the mirror files.
Restoring the Active Jobs file and the IOA Conditions/Resources file is described under
Dual Checkpoint Mode earlier in this section.
IOA Log file is inaccessible
Define a new IOA Log file using utility CTMFRLOG. Then activate the CONTROL-M
monitor.
Active Jobs file or IOA Conditions/Resources file is inaccessible Non-dual mode
The status of the production environment can be determined according to the IOA Log file
or the Active Jobs file (depending on which file is inaccessible). The recovery process will
be done manually, using reports extracted by specially designed programs and KSL.
In either case, whether running in dual mode or not, it is advisable to use the Journaling
and Restoration facility.
The Journal file is used to collect data relating to changes occurring in the CONTROL-M
Active Jobs file and the IOA Conditions/Resources file during the CONTROL-M working
day.
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
activities that impact the Active Jobs file and all prerequisite condition changes.
If the Active Jobs file and (optionally) the IOA Conditions/Resources file need to be
restored, run utility CTMRSTR to restore the files to the status they had as of any specific
time after the last run of the New Day procedure.
AutoEdit Simulation Facility
Production processing generally should not be stopped even if the CONTROL-M monitor
cannot be activated (e.g., the CONTROL-M Active Jobs file was deleted or a programming
error occurred in one of the CONTROL-M exits).
The SUBMIT option of the AutoEdit Simulation facility can be used to enable submission
of production jobs via the authorized TSO user. (See Defining an Authorized TSO User
above.)
What should be executed or submitted and in what order can be determined using specially
designed programs and KSLs. (See Manual Recovery Procedures below for more
information on this topic.)
The AutoEdit Simulation facility simulates a CONTROL-M monitor submission (i.e., it
activates the CONTROL-M submission exit (exit 2) and the AutoEdit facility). As a result
no modifications to the JCL libraries are needed when submission is done through this
facility.
Notes The submission exit (exit 2) can be used to check security authorizations. If security
considerations for the recovery process are different, use an alternate submission exit.
JCL members which have AutoEdit facility statements before the JOB statement may
cause the submission of a dummy job.
CONTROL-M Monitor Abends
If the CONTROL-M monitor abends, it may be possible to determine that a specific job or
started task caused the abend.
Examine error messages that may appear on the MVS SYSLOG.
Scan the bottom of the CONTROL-M log for the last jobs handled by CONTROL-M. The
last job(s) handled probably caused the abend.
If this is the case, change the status of the specific job or started task to HELD using the
CONTROL-M Status screen. When the monitor is reactivated, it will process the held
request first and thus be able to continue production work. (CONTROL-M bypasses all jobs
in HELD status.)
If the CONTROL-M monitor cannot be reactivated, continue to work manually. (See
AutoEdit Simulation Facility above.)
See Manual Recovery Procedures below for more information about implementing the
submission workplan.
Disaster Relocation
Shared DASD (Multi-CPU Environment)
Starting a CONTROL-M monitor in the second CPU should not be a problem because all
the production files (i.e., the CONTROL-M LOAD library, the Repository, the production
JCL parameters, and the symbols libraries) are cataloged and residing on shared DASD.
(See CONTROL-M Parameter Definitions above.)
Backup Site
Use the disaster recovery plan. Transfer CONTROL-M and the production files from the
most recent backups. Install and activate CONTROL-M. Resume production work using
manual recovery procedures and these backups. See Manual Recovery Procedures below
for more information.
System Maintenance
System maintenance usually does not affect CONTROL-M. After system maintenance ends,
activate the CONTROL-M monitor and resume production. However, when making a major
change or upgrade to MVS or JES, it is recommended that you test the production
environment before performing the upgrade.
If the MVS SPOOL is to be changed or reformatted during system maintenance, perform
the following steps:
Shut down the CONTROL-M monitor.
Unload the content of the SPOOL to tape or disk
Before production resumes:
Reload the SPOOL.
Reactivate the CONTROL-M monitor.
If the SMF-ID or the JES-ID are to be changed, perform the following steps before
production resumes:
Make the required change(s) to installation parameter CPUS.
Compile member CTMPARM. (See Step 4.3 in Section 2 and Step 3.5 in Section 3 of the
IOA Installation Guide.)
Reactivate the CONTROL-M monitor.
Manual Recovery Procedures
Manual recovery can be performed by using the IOA Log file or the CONTROL-M Active
Jobs file (depending on the file which is accessible).
The relevant KSL scripts the CONTROL-M SAMPLE library can be tailored as necessary.
CTMRAFL and CTMRNSC Reports
If the CONTROL-M monitor cannot be activated or the Active Jobs file is inaccessible, use
the CTMRAFL and CTMRNSC reports to determine which jobs should be submitted and in
what order.
Job flow report CTMRAFL provides information about jobs in the Active Jobs file sorted by
groups. For each group, the jobs are presented in order of expected execution. This report
should be executed daily before starting the batch production cycle. It can be used if the
Active Jobs file is lost during the batch production cycle.
The night schedule report (CTMRNSC) provides a summary of all jobs which executed
during a specified time range. The start-time, end-time, elapsed time, and other data are
reported for each job. Sort the report by group, end-time and start-time (parameter
GROUP ENDTIME).
By combining these two reports (manually or by a user-written program), the exact status
of the production environment can be established. The reports should be sorted by groups
(which usually represent application systems), making it easy for production personnel to
continue the work manually (i.e., by groups, using the AutoEdit Simulation facility
SUBMIT option).
KSL Log Reports
REP5ALL activates KSL program REPLOGAL. This program prints all the log messages
for a specified date. The reports output indicates which jobs did not yet execute. Example
1
//STEP1 EXEC CTMRKSL
TRACE OFF
MAXCOMMAND 999999
CALLMEM REPLGMSG FROMDATE TODATE JOB511I NULL NULL NULL
END
//STEP2 EXEC CTMRKSL
TRACE OFF
MAXCOMMAND 999999
CALLMEM REPLGMSG FROMDATE TODATE CTM659I FRM467I SEL208I NULL
END
REP5MSGD activates KSL program REPLGMSG. This program prints only relevant log
messages for a specific time span. A maximum of four messages can be specified as input
parameters. This report should be run in two steps.
In the STEP1 and STEP2 set:
FROMDATE Date from which data will be extracted, in format (ddmmyy or mmddyy)
used at your site.
TODATE Date to which data is still relevant, in format (ddmmyy or mmddyy) used at
your site.
The most practical value for parameter FROM DATE depends on the value of parameter
MAXWAIT (e.g., if most production jobs do not have a MAXWAIT parameter of more than
seven days, parameter FROMDATE should not exceed seven days),
STEP1 prints a list of all the jobs placed on the Active Jobs file (message: JOB511).
STEP2 prints a list of all the jobs which ended OK, were discarded (MAXWAIT exceeded),
were held, or were deleted by online users.
By manually combining these two reports, an accurate list of all jobs which should be
scheduled and executed can be compiled. This method is complex, error prone, and does not
determine the exact order of scheduling. This method should be used only if there is no
alternative (i.e., no other way to restore the Active Jobs file).
REP5EXP activates KSL program REPLOGEX. This program can help trace problematic
jobs (e.g., jobs ending in abends, etc.). Priorities can then be better defined and reasonable
throughput maintained.
Using the Active Jobs File
REP3ALLJ activates KSL program REPJOBST. This program prints a list of the Active
Jobs file. It can be used as a general guideline to the planned recovery procedure.
REP3LEFT activates KSL program REPJOBMO. This program prints a list of all jobs in
active and problematic status (shown below):
Example 2: Active and Problematic Statuses
1. WAIT SCHEDULE 7. RECOVERY NEEDED
2. WAIT SUBMISSION 8. DISAPPEARED
3. SUBMITTED 9. ABENDED
4. WAIT EXECUTION 10. UNEXPECTED CC
5. EXECUTING 11. JCL ERROR
6. ENDED NOT OK
Using this report in combination with the state of the jobs in the JES queues (i.e., statuses
2-5), a manual submission work plan can be devised. This work plan can be executed using
the AutoEdit Simulation facility SUBMIT command.
Automatic Recovery after a System Crash
Example 3 (below) illustrates an automatic recovery process defined to a job to be used
after a system crash. This example uses value *UKNW in the CODES parameter.
This example assumes that there was a computer crash during the execution of this job.
When the CONTROL-M monitor is activated, the recovery program will be submitted and a
message will be sent to the appropriate user.
Example 3: Usage of *UKNW Codes Parameter
ON PGMSTEP ANYSTEP PROCSTEP CODES *UKNW
DO COND RESTART-AP-STC ODAT +
DO SHOUT TO TSO-AP1 URGENCY U
MSG SYSTEM CRASH AUTO TO FILE RECOVERY IS ACTIVE
This page is intentionally left blank
General ...........................................................................................................................................4-1
Activating the CONTROL-D Monitor .......................................................................................4-1
Activating Generic Processing ...................................................................................................4-1
Activating the Compressed Dataset Access Method.................................................................4-2
Activating the IOA Archive Server (CONTROL-V)..................................................................4-2
Modifying the CONTROL-D Sleeping Interval ........................................................................4-2
Loading the Recipient Tree........................................................................................................4-3
Loading the Recipient Tree into the CONTROL-D Monitor...............................................4-3
Loading the Recipient Tree into the IOA Online Monitor ..................................................4-3
Loading the Recipient Tree into CONTROL-D Application Server ...................................4-4
Loading the Recipient Tree into File Transfer Monitor ......................................................4-4
Reloading the Manual Conditions File......................................................................................4-4
Deactivating the CONTROL-D Monitor ...................................................................................4-4
Deactivating Generic Processing ...............................................................................................4-5
Automatic Warning ...............................................................................................................4-5
Deactivating the Compressed Dataset Access Method.............................................................4-5
Deactivating the IOA Archive Server (CONTROL-V)..............................................................4-6
CONTROL-D/Decollation Server Integration...........................................................................4-6
New Day Processing....................................................................................................................4-6
Overview .....................................................................................................................................4-6
Starting the New Day Procedure...............................................................................................4-7
New Day Procedure Workflow...................................................................................................4-7
User Daily Job ............................................................................................................................4-8
Use of the Date Control Record by the User Daily Job .......................................................4-9
Use of the Date Control Record by the New Day Procedure.............................................4-10
Programs Called During New Day Processing .......................................................................4-10
Parameters of the New Day Procedure ...................................................................................4-12
Mission Scheduling................................................................................................................... 4-13
Overview ...................................................................................................................................4-13
Scheduling Methods .................................................................................................................4-13
Scheduling Missions Via the New Day Procedure (CTDNDAY) ................................................4-14
Supplied Mission List Members .........................................................................................4-15
Scheduling Missions Via a User Daily Procedure ..................................................................4-16
Scheduling a Mission Manually...............................................................................................4-16
Scheduling Workflow................................................................................................................4-17
Decollation Mission Management ......................................................................................... 4-19
Overview................................................................................................................................... 4-19
Generic Decollating Missions.................................................................................................. 4-19
Generic Decollating Mission Workflow ............................................................................. 4-19
Additional Considerations.................................................................................................. 4-20
Scheduling Generic Decollating Missions Via the New Day Procedure.......................... 4-21
Controlling the Generic Process......................................................................................... 4-21
Defining a Generic User Name List .................................................................................. 4-22
Interfaces to Production Control Systems.............................................................................. 4-22
Overview of CONTROL-M Scheduling With CONTROL-D............................................. 4-23
Job-Report Dependency...................................................................................................... 4-25
Scheduling via the CONTROL-M Production Control System........................................ 4-25
Scheduling via a Non-CONTROL-M Production Control System................................... 4-27
Considerations for When CONTROL-M and CONTROL-D Are Installed...................... 4-29
Printing Mission Management............................................................................................... 4-30
Printing Mission Workflow ..................................................................................................... 4-31
Printing Mission Definition................................................................................................ 4-31
Preparing the Skeleton....................................................................................................... 4-33
Advanced Scheduling Issues ................................................................................................... 4-34
Distribution According to Scheduling Dates..................................................................... 4-34
Report Decollating and Printing Mission Dependency .................................................... 4-35
Printer Control......................................................................................................................... 4-35
One-Chunk Method ............................................................................................................ 4-35
Multi-Chunk Method.......................................................................................................... 4-36
One-Outgroup Method (JES2 Only) .................................................................................. 4-37
Opening/Closing Printers................................................................................................... 4-37
Printing Process.................................................................................................................. 4-38
Identifying CONTROL-D Chunks on Spool (JES2 Only)...................................................... 4-39
CONTROL-D/Writer Facility.................................................................................................. 4-40
Activating the CONTROL-D/Writer Facility .................................................................... 4-40
Printing on AFP (APA) Printers ............................................................................................. 4-42
Using CDAM PAGEDEF/FORMDEF Parameters ........................................................... 4-43
Using a Specified OUTPUT Statement ............................................................................. 4-43
AFP Page Mode Output...................................................................................................... 4-44
Page Markers Under AFP.................................................................................................. 4-44
In-Stream AFP Control Statements .................................................................................. 4-44
Printing Using XEROX LCDS (DJDE) Parameters...............................................................4-46
Using OUTPARMS for Global Control of Printing Characteristics.................................................4-48
Printing to a File.......................................................................................................................4-49
Tailoring Exit CTDX005 .....................................................................................................4-50
Advanced ACIF Interface Facility ........................................................................................ 4-52
ACIF Utility Benefits ...............................................................................................................4-52
Making ACIF Accessible to CONTROL-D...............................................................................4-53
Activating the Advanced ACIF Interface................................................................................4-53
ACIF Execution Parameters...............................................................................................4-53
ACIFPARM Library ............................................................................................................4-54
WYSIWYG Viewing of XEROX Reports ................................................................................ 4-56
Overview ...................................................................................................................................4-56
Initial Preparations ..................................................................................................................4-56
Processing XEROX Reports .....................................................................................................4-56
Parameters for the DVS Printer Emulator .............................................................................4-57
Activating the DVS Printer Emulator................................................................................4-57
CCIFPARM Library .................................................................................................................4-57
Page On Demand....................................................................................................................... 4-59
Introduction ..............................................................................................................................4-59
Page On Demand Components ................................................................................................4-59
Viewing AFP/CCIF Reports Under Page On Demand ...........................................................4-61
Preparation for AFP Reports ..............................................................................................4-61
Preparation for CCIF Reports ............................................................................................4-61
Parameter STORE of Printing Mission Definition............................................................4-62
Starting Page On Demand on the Mainframe........................................................................4-63
Displaying a List of All Active Users .................................................................................4-63
Displaying Active Application Server Address Spaces .....................................................4-63
Reloading the Recipient Tree..............................................................................................4-64
Problem Determination............................................................................................................4-64
Mainframe PC File Transfer................................................................................................ 4-65
File Transfer Monitor ...............................................................................................................4-65
File Transfer Protocols .............................................................................................................4-65
File Transfer Process................................................................................................................4-65
Activating and Stopping the File Transfer Monitor..........................................................4-66
Reawakening the File Transfer Monitor............................................................................4-66
Reloading the Recipient Tree..............................................................................................4-66
File Transfer Monitor Parameters .....................................................................................4-66
CONTROL-D/Image................................................................................................................... 4-67
Sample Files............................................................................................................................. 4-67
Implementing CONTROL-D/Image........................................................................................ 4-68
Packing and Transferring CONTROL-D/Image Files ........................................................... 4-68
Decollating and Indexing CONTROL-D/Image Files ............................................................ 4-68
Viewing CONTROL-D/Image Files......................................................................................... 4-70
Backup Mission Management................................................................................................. 4-71
Overview................................................................................................................................... 4-71
Backup According to Scheduling Dates............................................................................. 4-71
Report Decollating and Backup Mission Dependency...................................................... 4-72
Backup Mission Workflow....................................................................................................... 4-73
Exception Handling............................................................................................................ 4-75
Changing the Backup Mission Retention Period................................................................... 4-75
Backup Mission Considerations.............................................................................................. 4-76
Restore Mission Management ................................................................................................ 4-77
Overview................................................................................................................................... 4-77
Restoring According to Scheduling Dates ......................................................................... 4-77
Restore Mission Workflow....................................................................................................... 4-78
Exception Handling............................................................................................................ 4-81
Restoring With the Original Backup Utility..................................................................... 4-81
Migration Mission Management (CONTROL-V Only) ...................................................... 4-82
Overview................................................................................................................................... 4-82
Migrating Reports.................................................................................................................... 4-82
Multi-stage Migration.............................................................................................................. 4-83
Migration Mission Report Correspondence......................................................................... 4-83
MIG and MSM Migration Types............................................................................................. 4-83
Scheduling Criteria.................................................................................................................. 4-84
Primary and Secondary Migration ......................................................................................... 4-84
Migration Mission Skeleton Jobs............................................................................................ 4-85
Sample Skeleton Job........................................................................................................... 4-86
Target Media Types ................................................................................................................. 4-88
Migration to Cartridge (CART).......................................................................................... 4-88
Migration to ROSs/OSS...................................................................................................... 4-88
Emulation Mode) ................................................................................................................ 4-89
Migration to FileTek Storage Machine.............................................................................. 4-89
Migration to OAM............................................................................................................... 4-90
Naming Conventions................................................................................................................4-91
CDAM Datasets...................................................................................................................4-91
Indexes .................................................................................................................................4-92
Migration Mission Workflow....................................................................................................4-93
Example: Multi-stage Migration Mission Workflow .........................................................4-95
Exception Handling..................................................................................................................4-97
Job Archiving............................................................................................................................. 4-98
IOA Archive Server................................................................................................................. 4-100
General ....................................................................................................................................4-100
Device Definition and Usage..................................................................................................4-100
Cartridge (CART) Media...................................................................................................4-100
DataWare/ROSs/OSS Usage.............................................................................................4-101
Updating the OSS Database.............................................................................................4-101
FileTek Storage Machine Media Definition.....................................................................4-102
Object Access Method (OAM) Usage ................................................................................4-103
Media and Resource Control ..................................................................................................4-103
Media Control ....................................................................................................................4-103
Resource Control................................................................................................................4-103
ROSs/OSS Media DataWare/ROSs/OSS Storage Subsystem .....................................4-104
CART Media 3480/3490/3490E/3590 Tape Cartridge Subsystem...............................4-104
FTK FileTek Storage Machine (SM) or OAM Object Access Method Media............4-105
Logical Device Status ........................................................................................................4-105
Reducing/Increasing the Number of Usable Devices ......................................................4-106
Starting/Stopping a Specific Logfcal Device ....................................................................4-106
Displaying Media Information...............................................................................................4-107
Problem Determination..........................................................................................................4-108
User Report List File Management..................................................................................... 4-109
Overview .................................................................................................................................4-109
Permanent User Report List File ..........................................................................................4-110
Active User Report List File ..................................................................................................4-112
Migrated User Report List File..............................................................................................4-113
History User Report List File ................................................................................................4-113
User Report List File Maintenance .......................................................................................4-115
Repository Maintenance ....................................................................................................... 4-116
General ....................................................................................................................................4-116
Expanding the Active Missions File......................................................................................4-116
Expanding the Active Transfer File ......................................................................................4-117
User Report List File Housekeeping .....................................................................................4-117
Reorganizing the Files ......................................................................................................4-118
Dynamic Sorting of the Active User Report List File..................................................... 4-118
Rebuilding the Index Component .................................................................................... 4-119
Recovering a Damaged File.............................................................................................. 4-119
SMF Accounting....................................................................................................................... 4-120
General
This section describes the initialization, customization and administration features that
are available for CONTROL-D and CONTROL-V.
CONTROL-D and CONTROL-V share the same customization features, except the IOA
Archive Server and the migration mission (which are CONTROL-V features). Whenever
the text refers to CONTROL-D, the same customization methods apply to CONTROL-V.
Activating the CONTROL-D Monitor
CONTROL-D and CONTROL-V share the same monitor when both products are installed.
The CONTROL-D monitor usually operates 24 hours a day as a started task (STC) in one
and only one computer at an installation. Generally, the monitor is automatically activated
as part of the IPL process. To activate the monitor manually, issue operator command:
S CONTROLD
If the monitor is successfully activated, the following message appears on the operator
console:
CTD100I CONTROL-D MONITOR STARTED
If you try to activate more than one CONTROL-D monitor with the same database in the
same computer environment, the second monitor immediately shuts down and an
appropriate message is issued.
Note See Activating More Than One Monitor under Installation Considerations in
The Printers Control monitor also operates 24 hours a day, but is activated and controlled
by the main CONTROL-D monitor. When the Printers Control monitor is successfully
activated, the following message appears on the operator console:
CTD775I monitor-name CONTROL-D PRINTERS CONTROL MONITOR STARTED
Activating Generic Processing
When the CONTROL-D monitor is brought up, Generic Classes processing is automatically
activated. You may need to activate Generic Classes processing manually after
CONTROL-D is brought up. Caution should be used if you manually activate the Generic
option when it has not been activated automatically.
To manually automate Generic Classes processing, issue operator command:
F CONTROLD,STARTGEN
The following message appears on the operator console from which the modify command
was issued:
CTD139I GENERIC JOB DECOLLATION IS ACTIVE ON CLASSES (class-list)
Activating the Compressed Dataset Access Method
The Compressed Dataset Access Method (CDAM) should operate 24 hours a day because
CDAM is used both by the CONTROL-D monitor and by jobs within the system to read,
write and view compressed reports. For information about how a job can invoke the
Compressed Dataset Access Method, refer to Section 5 in the CONTROL-D User Manual.
Usually, CDAM is automatically initialized as part of the IPL process. To activate the
Compressed Dataset Access Method manually, issue operator command:
S IOASINIT,OPTIONS=D
If CDAM is successfully initialized, operator message appears on the operator console:
CTM227I IOA SUBSYSTEM subsystem-name INITIALIZATION OF CONTROL-D FUNCTIONS COMPLETED
Activating the IOA Archive Server (CONTROL-V)
To activate the IOA Archive Server, issue the following command:
S IOASMON
Notes The IOA Archive Server uses cross-memory services to communicate with other address
space requesting services. Like other address spaces using cross-memory services,
whenever the IOA Archive Server is shut down, the address space entry in the MVS
Address Space Vector Table (ASVT) remains non-reusable until the next IPL, and the
message IEF352I is issued (in some MVS releases). If the IOA Archive Server is
brought up and down many times, the ASVT may become full. New address spaces will
not start, and an immediate IPL may be required.
To prevent this problem, specify a large enough value in MVS initialization parameters
MAXUSER, RSVSTRT and RSVNONR in member IEASYSXX in the SYS1.PARMLIB
library. Information about these parameters can be found in the MVS Initialization
and Tuning Reference manual.
Modifying the CONTROL-D Sleeping Interval
CONTROL-D wakes up every few seconds and checks what it has to do. This interval is
set via a CONTROL-D installation parameter and can be changed by the system
administrator. In addition, the interval can be altered by operator command:
F CONTROLD,INTERVAL=nn
It is recommended that the interval be modified by automatic commands invoked by the
CONTROL-O or CONTROL-M monitor (if present) according to set conditions and time
ranges, and not manually by the operator. For sites which do not use the CONTROL-M
Production Control System, the commands can be issued via the JES Automatic Commands
facility.
At most sites, the interval should be longer during the day (when fewer batch production
jobs are executing) and shorter during the night.
on the processing power of the machine indicated, the sleeping interval should usually not
be less than the number of seconds indicated:
There is no practical benefit in setting the interval to less than these minimums. Doing so
could slow down CONTROL-D operation.
When the modification is received by CONTROL-D, the following message is displayed on
the operator console from which the modify command was issued:
CTD123I CONTROL-D INTERVAL IS SET TO nn SECONDS
Loading the Recipient Tree
The Recipient Tree resides in a partitioned dataset. It is loaded by CONTROL-Ds various
monitors during their start-up. In order to replace the current copy of the Recipient Tree,
use the operator commands described below.
Loading the Recipient Tree into the CONTROL-D Monitor
To load a new (modified) Recipient Tree under the CONTROL-D monitor, enter operator
command:
F CONTROLD,LOADTREE
Examine the messages which are sent to the operator console. The following message
indicates that the tree was loaded successfully:
CTD160I CONTROL-D RECIPIENT TREE LOADED- nnnnnn RECIPIENTS
where nnnnnn is the number of recipients successfully loaded.
Loading the Recipient Tree into the IOA Online Monitor
The recipient tree is also loaded into the IOA Online monitor. To load a new (modified) Recipient
Tree under the IOA Online monitor, issue operator command:
F IOAOMONx,LOADTREE
where x is the unique monitor ID.
If the tree is loaded successfully, the following message is displayed on the operator console
from which the modify command was issued:
CTM786I monitor-name NEW TREE LOADED. NEW USERS WILL BE SIGNED ON TO THE NEW
TREE
When a new Recipient Tree is loaded, every user who enters the CONTROL-D Online
facility will start working with the new tree. However, users who were using the Online
facility when the new tree was loaded will continue to use the old tree. The old tree is
deleted from memory after all users who were accessing it have exited the Online facility.
Loading the Recipient Tree into CONTROL-D Application Server
To load a new (modified) Recipient Tree under the CONTROL-D Application Server, issue
operator command:
F IOAGATE,MODASID[=nn] LOADTREE
Where nn is the decimal sequential ASID number of the CONTROL-D Application Server
address space to which the MODIFY command will be submitted. The MODIFY command
will be broadcast to all active Application Server address spaces if the ASID number =nn
is omitted.
Loading the Recipient Tree into File Transfer Monitor
To load a new (modified) Recipient Tree under the File Transfer monitor, issue operator
command:
F CTDFTM,LOADTREE
If no address space is specified, the modify command will be broadcast to all the active
serve address spaces related to that specific monitor.
Reloading the Manual Conditions File
The Manual Conditions file (screen 7) is created by utility IOALDNRS. This utility scans
the Active Missions file and builds a list of prerequisite conditions that should be set
manually. See Section 9 in this guide for a description of this utility and its parameters.
The Manual Conditions file is refreshed (i.e., recreated) by each run of utility IOALDNRS.
Normally, the utility is activated as the second step of the CTDNDAY procedure. However,
the utility can be run more than once a day.
Deactivating the CONTROL-D Monitor
To shut down the CONTROL-D monitor, issue operator command:
P CONTROLD
After a few seconds (a maximum of a minute), the monitor shuts down and the following
messages appear on the operator console:
CTD107I SHUT DOWN UPON REQUEST FROM OPERATOR
CTD136I STOPPING THE PRINTERS CONTROL MONITOR monitor-name
CTD779I monitor-name CONTROL-D PRINTERS CONTROL MONITOR ENDED
CTD120I CONTROL-D MONITOR SHUTTING DOWN
Message CTD779I is highlighted. Message CTD120I is highlighted and unrollable.
In case of emergency, you can cancel the CONTROL-D monitor. However, this is not
recommended. If the monitor is cancelled, you should also cancel the Printers Control
monitor(s) and secondary monitors.
When you shut down the CONTROL-D monitor, all other CONTROL-D facilities (the
Compressed Dataset Access Method, IOA Online monitors, IOA Archive Server) and Online
facility sessions can remain active.
Deactivating Generic Processing
It is sometimes desirable to stop CONTROL-D from processing the outputs in the generic
classes (usually to replace the current report decollating mission definitions).
Issue operator command:
F CONTROLD,STOPGEN
The following message is displayed on the operator console from which the modify
command was issued:
CTD140I GENERIC JOB DECOLLATION IS BEING DEACTIVATED
New decollation of generic class output does not start. Currently executing (decollating)
missions finish processing those jobs whose output processing already started.
Automatic Warning
When generic decollation is not active, the CONTROL-D monitor issues the following
warning on the operator console:
CTD271I GENERIC JOB DECOLLATION IS INACTIVE CHECK WHY
This highlighted message, reappears every ten minutes if there is a job waiting to be
decollated in one of the generic classes.
Generic mission deactivation can occur in one of the following ways:
If started task CTDNDAY fails during the ordering of a generic decollating mission,
deactivation is automatic. Check if all the generic decollating missions are in the Active
Missions file before reactivating generic processing.
The operator issues the STOPGEN command (discussed above). Check why generic
decollating was deactivated and whether it should remain deactivated.
The Active User Report List file becomes full. Run utility CTDDELRP to delete
unnecessary entries from this file.
The spool can become full if there are many generic jobs waiting to be decollated.
Deactivating the Compressed Dataset Access Method
There is rarely any reason to deactivate the Compressed Dataset Access Method. It should
be done only in conjunction with problem-solving efforts as directed by your IOA
representative. In this case, shut down the CONTROL-D monitor and issue operator
command:
S IOASTERM,OPTIONS=D
The following message is displayed on the operator console:
CTM231I IOA SUBSYSTEM subsystem-name DEACTIVATION OF CONTROL-D FUNCTIONS
COMPLETED
If the same subsystem supports other IOA products, their functions remain active.
Deactivating the IOA Archive Server (CONTROL-V)
To deactivate the IOA Archive Server, issue one of the following operator commands:
P IOASMON
-or-
F IOASMON,STOP
When either of these commands is issued, the IOA Archive Server terminates and an
appropriate message is displayed on the operator console.
IOA107I IOASMON SHUT DOWN UPON REQUEST FROM OPERATOR
IOA10BI IOASMON IOA ARCHIVE SERVER SHUTTING DOWN
CONTROL-D/Decollation Server Integration
CONTROL-D/Decollation Server is a separately licensed product for report distribution to
a UNIX or Windows/NT environment. If CONTROL-D/Decollation Server is installed at
your site, you can distribute mainframe reports via Email or deliver them to NT/UNIX
printers or file systems.
To activate this feature, perform the ICE installation steps described in Step 15,
Connection with Decollation Server, in Section 5 of the IOA Installation Guide. Then set
Decollation Server for running utility 'repmgr' from the Automation Process as described in
Using the Distribution Repository Manager Command Line Utility to Distribute
CONTROL-D Reports in Chapter 8 of the CONTROL-D/Decollation Server Version 2.2.0A
User Guide.
In order to send immediate or deferred print reports through the Decollation Server,
external destinations should be specified in CONTROL-D. For information about specifying
external destinations, see Section 2 of the CONTROL-D User Manual.
External destination specification is controlled by CONTROL-D user exit CTDX026 and
security module CTDSE26. See member DOCDX026 in the IOA SECUDATA library for
more information.
New Day Processing
Overview
The CONTROL-D monitor is usually activated as a started task and remains active 24
hours a day. New Day processing consists of automatic cleanup from the previous days
mission ordering and automatic ordering of missions for the current day.
The main components related to New Day processing are:
New Day procedure
User Daily job
Date Control records
Active Missions file
Starting the New Day Procedure
Once a day, at a predefined time determined by the IOA system administrator, the
CONTROL-D or CONTROL-V monitor and the Printers Control monitor are shut down and
New Day procedure CTDNDAY (this name is defined in installation parameters and may
be different at your site) is activated. The following highlighted, unrollable messages are
sent to the operators console:
CTD779I monitor-name CONTROL-D PRINTERS CONTROL MONITOR ENDED
CTD113W CONTROL-D MONITOR SHUTTING DOWN FOR A NEW DAY
The CONTROL-D monitor signals the Printers Control monitor to shut down and waits
until it does so. Then the CONTROL-D monitor shuts itself down. When the Printers
Control monitor shuts down, it suspends all active printing missions. Printing resumes
after the Printers Control monitor is restarted.
Before CONTROL-D shuts down, started task CTDNDAY is activated. This started task
may ask the operator several questions. After a few minutes CTDNDAY finishes executing
and automatically reactivates CONTROL-D using the following command:
S CONTROLD
If procedure CTDNDAY abends or fails for any reason, a highlighted, unrollable message is
issued to the operator console and the monitor is not reactivated automatically.
Procedure CTDNDAY compares the date and time of the computer with the CONTROL-D
control files. If they do not match, the following questions are displayed on the operator console:
CTD426W CONTROL-D (CTDNDAY) DID NOT RUN FOR nnnnnn DAYS
CTD427W IS THIS TRUE? (ANSWER YES OR NO)
CTD428W YOUR ANSWER IS:
If this situation occurs after the computer has not been working for a few days (e.g., a
hardware failure or a holiday) your response should be YES. If this is not the case, the
computer was probably IPLed with the wrong date. Your response should be NO, the
system date should be checked and corrected. Then restart CTDNDAY. If the system date
was correct, the IOA administrator should check the cause of the problem.
New Day Procedure Workflow
The New Day procedure performs the following daily maintenance actions and then
reactivates the CONTROL-D monitor:
1. Cleans unnecessary missions from the Active Missions file. This includes missions that
ended OK, missions in wait schedule state whose MAXWAIT parameter has been
exceeded, emergency missions which are no longer needed, etc.
Note Missions that ended OK can optionally be kept in the Active Missions file until the
MAXWAIT period for these missions is exceeded.
2. Schedules regular and generic decollating missions, printing missions, backup
missions, restore missions, and CONTROL-V migration missions. See Mission
Scheduling later in this section for more information.
3. Reactivates the CONTROL-D monitor by issuing operator command S CONTROLD.
4. Updates the IOA Manual Conditions file. See the description of utility IOALDNRS in
Section 9 of this guide.
User Daily Job
The User Daily job is used to place new missions in the Active Missions file. Each User Daily
job usually runs once a day on one or more missions definition members. The missions are
selected according to the working date specified to the User Daily job. Therefore, the User Daily
job is date-dependent and certain special situations must be dealt with, such as:
The computer has not been working for a few days (e.g., due to holidays, or a
hardware/software failure).
The user wants to run a job or a group of jobs and to process their reports prior to or
later than the current working date.
Date Control Record
Each User Daily job uses a special Date Control record to store the last running date for
the User Daily job. A Date Control record is a member in the CONTROL-D PARM library
in which relevant date information is placed during New Day processing.
The Date Control record is analyzed by the User Daily job to determine the current
running date, the last running date, and possible error situations. This date information is
used to manage the ordering of missions during New Day processing.
When a User Daily job is run, the current working date is placed in the Date Control record,
and the Basic Scheduling parameters of each mission in the mission lists being ordered are
compared to this date to determine if the mission should be placed in the Active Missions file.
The length of a Date Control record is 80 characters. The following chart shows the format
of the Date Control Record and describes each date in the record.
Columns Value Added Description
1-6 date-1 Current (or last) original scheduling date.
8-13 date-2 Current (or last) original scheduling date of non-generic
report decollating missions.
15-20 date-3 Current (or last) original scheduling date of non-generic
report decollating missions finish indicator.
22-27 date-4 Current (or last) original scheduling date of printing missions.
29-34 date-5 Current (or last) original scheduling date of printing
missions finish indicator.
36-41 date-6 Current (or last) original scheduling date of backup
missions/migration missions.
42-47 date-7 Current (or last) original scheduling date of backup
missions/migration missions finish indicator.
48-53 date-8 Current (or last) original scheduling date of restore missions.
54-59 date-9 Current (or last) original scheduling date of restore missions
finish indicator.
67-72 date-10 Finish indicator date of the User Daily job.
Date format is mmddyy, ddmmyy or yymmdd, depending on the site standard.
Use of the Date Control Record by the User Daily Job
In some cases, the Date Control record of a User Daily job can be updated via a regular editor. The
Date Control record is referenced by DD statement DACHK (in the Daily procedure or CLIST).
The workflow of the User Daily job is dependent on the Date Control record. The main
steps of the User Daily job are:
Checking the last running date of the User Daily job (the internal program CTDCHK).
If they match, the User Daily job has already run today. A message is issued and the
condition code is set to 0004.
a User Daily job run has been attempted before its time. The User Daily job stops
executing and notifies the user accordingly.
updated to the current working date. This date is then used as the current
scheduling date.
If the User Daily job did not run for more than one day, a warning message is issued
and the User Daily job tries to schedule the missions for all of the days which have
passed since the last scheduling date (according to the production parameters).
Placing missions in the Active Missions file according to the current scheduling date and the
last running date (via internal programs CTDRRQ, CTDPRQ, CTDBRQ, and CTDSRQ). See
the table in Programs Called During New Day Processing for more information.
Program CTDxRQ works on mission definitions referenced by DD statement DAxxxLST.
For each category in the mission, the program checks whether the category should be
scheduled on one or all the days that have passed since the last original scheduling date
(date-2, date-4, date-6 or date-8) until the working date in the record (date-1). If the mission
should be scheduled, the mission is placed in the Active Missions file.
For example, if a computer did not operate from the 20th to the 23rd, a mission originally
scheduled to execute on the 20th was not executed. Program CTDxRQ decides whether or
not the mission should be retroactively scheduled to run on the logical date of the 20th. (See
parameter RETRO in Sections 3 and 4 of the CONTROL-D User Manual.)
Note Basic Scheduling parameters are considered only if the FORCE option is not specified.
When the program finishes processing the mission definitions, the finish indicator
dates (date-3, date-5, date-7 and date-9) are updated to the working date (date-1)
calculated by program CTDCHK .
Before program CTDxRQ starts operating, it compares date-2 with date-3 (date-4 with
date-5, etc.). If do not match, a previous run of program CTDxRQ of the same User Daily job
has probably abended. The user is notified and the program terminates. To correct the
error, adjust the date values in the user Date Control record (using a standard editor).
Note When manually modifying the Date Control record, make sure that the same
missions are not scheduled to run twice on the same day.
Indicating that the User Daily job has ended (via program CTDPDA).
Program CTDPDA updates the finish indicator date (date-10) by setting it to the
running date (date-1). This indicates that the User Daily job finished successfully.
Use of the Date Control Record by the New Day Procedure
Separate Date Control records are used for the New Day procedure and the User Daily job. The
Date Control record for the New Day procedure has two additional dates: date-11 and date-12.
Columns Value Added Description
60-65 date-11 The last formatting date of the Active Missions file (used by
the program CTDFRM) is required to prevent formatting
from being performed twice on the same day. When this date
is in the record, program CTDCHK recognizes that this is a
General Date Control record. If there are problems
concerning the date, the program prompts the operator with
a series of questions.
74-79 date-12 The current original scheduling date of Generic decollating
missions.
When working under the New Day procedure (CTDNDAY), the program asks the operator
a question regarding the computers current date. This is to ensure that an incorrect date
was not inadvertently entered during the IPL process.
Programs Called During New Day Processing
Two important programs in New Day Processing are CTDILY and CTDILU.
The New Day procedure executes program CTDILY.
Each User Daily job executes program CTDILU.
Programs CTDILY and CTDILU both execute other programs which implement New Day
processing. However, program CTDILU (used by User Daily jobs) has less authorization
(i.e., is not APF-authorized) and calls fewer programs than program CTDILY.
Both CTDILY and CTDILU read the member referenced by DD statement DAPROG and
activate the programs listed in the member.
The format for each record in the program list is:
Columns
01-08 Program name.
10-11 Maximum return code allowable in the preceding program. If a higher return code
is encountered in the preceding program, the current program is not executed.
The programs called by the program CTDILY (the New Day procedure) and by program
CTDILU (User Daily jobs) are shown in the following chart:
Called By
Program CTDILY CTDILU Purpose
CTDCHK Checks the current date and its relation to the
General Date Control record. The program may
communicate with the computer operator to verify
that CONTROL-D is activated on the correct date.
CTDFRM Program reformats the Active Missions file. Missions
that have already executed and ended OK, missions
whose MAXWAIT parameter has been exceeded, and
emergency missions which are not needed are erased
from the file and the file is compressed. If this
program abends, it recovers automatically after
startup, using an automatically-generated backup
copy. See also Parameters of the New Day
Procedure below.
CTDCATF Reformats the Active Transfer file. Packets that were
transferred successfully, packets whose MAXWAIT
parameter has been exceeded, and the corresponding
files for these packets are erased from the Active
Transfer file. The file is then compressed. If this
program abends, it recovers automatically after
startup, using an automatically-generated backup
copy.
CTDPRQ Places printing missions in the Active Missions file
according to the date in the General Date Control
record and the scheduling criteria in the printing
mission definitions. The program receives
parameters via DD statement DAPRTLST.
CTDBRQ Places backup and migration missions in the Active
Missions file according to the date in the General
Date Control record and the scheduling criteria in
the backup and migration mission definitions. The
program receives parameters via DD statement
DABKPLST.
CTDSRQ Places restore missions in the Active Missions file
according to the date in the General Date Control
record and the scheduling criteria in the restore
mission definitions. The program receives
parameters via DD statement DARSTLST.
Called By
Program CTDILY CTDILU Purpose
CTDGRQ Places generic decollating missions in the Active
the generic decollating mission definitions. The
DAGENLST.
CTDRRQ Places non-generic decollating missions in the Active
the report decollating mission definitions. The
DAREPLST.
CTD34F Executes operator commands (system, JES, VTAM,
etc.) from a list (ddname DA34F). The default
command is S CONTROLD which starts the
CONTROL-D monitor.
CTDPDA Records the end of the Daily run.
Parameters of the New Day Procedure
Program CTDFRM, activated as part of the New Day procedure, is responsible (among
other duties) for erasing all CONTROL-D related conditions from the IOA
Conditions/Resources file for the current day. Prerequisite conditions are always assigned
a date reference (day and month). They can be kept in the IOA Conditions/Resources file
for a entire year. Therefore, it is necessary to erase them at the beginning of each working
day. Otherwise, missions may be triggered because of conditions remaining from the
previous year.
It is common to use prerequisite conditions which are not date-dependent (e.g., IMS-IS-UP,
or AR-FILE-OK). It is important that these conditions not be erased. You can supply a list
of conditions which are not to be erased via DD statement DAFRMIN. The format is:
IGNORE COND prefix
where:
prefix Name (or mask) of conditions not to be erased. If an asterisk (*) is specified,
no conditions are erased. Multiple IGNORE statements can be specified.
Note When the CONTROL-M Production Control System is installed at your site, the IOA
Conditions/Resources file is updated by CONTROL-M.
Mission Scheduling
Overview
CONTROL-D and CONTROL-V manage report distribution at your site via missions defined by
the user. Several different types of missions are available, each for a different type of task.
Decollation missions.
Printing missions.
Restore missions.
Backup missions.
Migration missions (CONTROL-V only).
The topics listed below are discussed on the following pages:
Scheduling Methods.
Scheduling Missions Via the New Day Procedure (CTDNDAY).
Scheduling Missions Via a User Daily Procedure.
Scheduling a Mission Manually.
Scheduling Workflow.
Scheduling Methods
Missions can be scheduled via the following methods:
Automatically by the CONTROL-D New Day procedure (CTDNDAY). This is the usual
method. (See Scheduling Missions Via the New Day Procedure CTDNDAY.)
Using a batch job (e.g., procedure CTDRPDAY for decollating missions). The job can be
submitted manually or automatically by a scheduler. (See Scheduling Missions Via a
User Daily Procedure.)
Manually from the Mission Definition screen, using the O (Order) and F (Force)
options.
Manually under ISPF using the Online Utilities panel. The panel can be invoked
directly using a CLIST (e.g., CTDMISRQ MIS(REP) for a decollating mission).
Manually under ROSCOE (e.g., using RPF CTDRQPRT for a printing mission).
Using a KeyStroke Language utility from the SAMPLE library (e.g., BKPORDER for
backup missions).
Scheduling Missions Via the New Day Procedure (CTDNDAY)
The recommended method for scheduling missions uses the New Day procedure because
the New Day procedure is activated automatically once a day. A member in the
CONTROL-D PARM library is referenced by a DD statement in the New Day procedure.
This member contains a list of missions that should be scheduled. The Basic Scheduling
parameters of these missions are analyzed against the requested scheduling date. If the
mission should be scheduled for that day, it is placed on the Active Missions file. The table
contains the names of the mission list members and the DD statements used to reference
each mission type in the New Day procedure.
Mission Type Member DD Statement
Regular Decollating REPLIST DAREPLST
Generic Decollating GENLIST DAGENLST
Printing PRTLIST DAPRTLST
Restore RSTLIST DARSTLST
Backup BKPLIST DABKPLST
Migration BKPLIST DABKPLST
The records in each member listed above should not contain line numbers. Each of these
records has the following format:
date libname [missionname catname] [FORCE]
date ODATE (original scheduling date) of the mission. Format:
mmddyy, ddmmyy or yymmdd (depending on the site standard).
The Basic Scheduling parameters of the mission are compared with
this date. The Date Control record is not updated.
Specifying an * (asterisk) indicates that date management is handled
automatically by CONTROL-D using the Date Control record.
Parameter RETRO affects the result obtained when the missions basic
scheduling criteria are compared with the last scheduling date of the
mission.
libname Name of the library in which the mission parameters are found. Valid
values:
Specific library name. In this case, the library is dynamically
allocated.
A DD name preceded by an asterisk. The library must be a
partitioned dataset with a record length of 80.
missionname Name of the mission (a member in the library). Optional.
Specifying an * (asterisk) indicates that all the missions (members) in
the specified library are analyzed. Using an asterisk eliminates the
need to update mission lists to include new missions.
catname The specific category of the mission is analyzed. Specifying an asterisk
indicates that all categories of the mission are analyzed.
FORCE Optional. When FORCE is not specified, Basic Scheduling parameters
of the category of the missions are analyzed against the specified
original scheduling date. If the mission should be scheduled on that
date, it is placed on the Active Missions file.
When FORCE is specified, mission categories are placed on the Active
Missions file with the specified original scheduling date (which must
be an actual date, not an asterisk) regardless of basic scheduling
criteria.
The following is an example of the JCL (relevant DD statements of procedure CTDNDAY
only):
//CTDNDAY EXEC PGM=CTDILY
//DACHK DD DISP=SHR,DSN=ctd_parm_library(DDATEREC)
//DAREPLST DD DISP=SHR,DSN=ctd_parm_library(REPLIST)
The Date Control record used in this case is the General CONTROL-D Date Control record.
Supplied Mission List Members
The following are the default mission list members supplied with CONTROL-D:
PRTLIST Schedules one printing mission (for form STD).
BKPLIST Schedules the following backup missions:
BKP0007D Back up for 7 days.
RSTLIST Schedules the following restore missions:
RST0060M Restore reports every 60 minutes.
RSTADHOC Restore reports immediately (for authorized users only).
Note Generic Decollating Missions
It is recommended that you schedule Generic Decollating missions by the New Day
procedure. See Decollating Mission Management later in this section.
Scheduling Missions Via a User Daily Procedure
The following JCL should be used:
// EXEC procedure-name
//DACHK DD DISP=SHR,DSN=ctd_parm_library(daterec)
//DAxxxLST DD DISP=SHR,DSN=ctd_parm_library(mlistmem)
where:
procedure-name Specify CTDRPDAY for decollating missions, CTDPRDAY for printing
missions, CTDRSDAY for restore missions, and CTDBKDAY for
backup and migration missions.
DAxxxLST Reference to the member containing the mission list. Same as specified
above for the New Day procedure.
daterec Name of the Date Control record for the procedure.
Each procedure must use its own Date Control record. A Date Control
record cannot be shared by two procedures. The Date Control record is
referenced by DD statement DACHK and is used to determine the
correct scheduling date for selecting missions according to their
scheduling criteria. See the description of the Date Control record
earlier in this section for more information.
mlistmem Name of the member containing the mission list. Same as specified
above for the New Day procedure.
Scheduling a Mission Manually
Missions are normally scheduled automatically via New Day processing. However, it is sometimes
necessary to schedule a mission manually (for testing, ad hoc missions, etc.). In addition, it may be
necessary to schedule a mission for different scheduling dates (e.g., scheduling a mission which
was to run on the 1st of next month on the 30th of this month, or rescheduling a mission which
ran on the 4th because the entire run has to be performed again on the 5th).
To manually reschedule a mission, we recommend using the O (Order) or F (Force) options
of the Mission List screen or using an ISPF online utility. However, to schedule a mission
without entering the IOA Online facility, you can use one of the following CLISTs, KSL
utilities, or RPFs (for ROSCOE):
Mission Type CLIST RPF KSL Utility
Decollating (Regular and Generic) CTDMISRQ MIS (REP) CTDRQREP REPORDER
Printing CTDMISRQ MIS (PRT) CTDRQPRT PRTORDER
Restore CTDMISRQ MIS (RST) CTDRQRST RSTORDER
Backup CTDMISRQ MIS (BKP) CTDRQBKP BKPORDER
Migration CTDMISRQ MIS (MIG) CTVRQMIG MIGORDER
See Section 2 of the CONTROL-D or CONTROL-V User Manual for more information about ISPF
Online utilities.
Scheduling Workflow
A mission is defined using the Online facility: option R for decollating missions, option M
for other missions. Each mission contains parameters describing actions to be performed
and when and under what conditions they are to be performed. Mission definitions are
stored in libraries (partitioned datasets).
Mission definitions in the library are not active instructions to the CONTROL-D monitor.
To make a mission active, it must be placed on the Active Missions file. The process of
selecting a mission from the definition library and placing it on the Active Missions file is
performed by the CONTROL-D New Day procedure during New Day processing.
The New Day procedure analyzes mission definitions in a library. According to the basic
scheduling criteria specified, appropriate missions are selected, placed in the Active
Missions file, and automatically assigned an original scheduling date (ODATE).
When a decision is made to schedule a mission, its parameters are passed to CONTROL-D user
exit CTDX001. This exit can modify the contents of the parameters or cancel the mission. If the
mission is not cancelled by the exit, the mission is placed in the CONTROL-D Active Missions file.
The Active Missions file can contain more than one mission with the same name.
Examples
Several categories exist for the same printing mission. Consider the organization of
bundling by a delivery network. A few categories are used, each category describing a
bundle with different report recipients. The categories COURIER-NORTH,
COURIER-SOUTH, COURIER-AIRPORT are used for the same printing mission. A
different list of recipients are bundled under each category. Using this method, a
separate bundle is prepared for each category.
A printing mission is late by more than one day (e.g., prerequisite reports have not yet
finished). In this case, the Active Missions file contains two printing missions with the
same name, but each with a different original scheduling date.
When a daily job is late by more than one day (e.g., input tape has not arrived yet). In
this case, the Active Missions file contains two report decollating missions for the same
job, each with a different original scheduling date.
When the same job is being run several times a day.
Notes Scheduling of decollating missions can depend on the operation mode of the production
control system at your site. It is possible to use all the different modes of operation at
the same site. This is usually done to solve special scheduling problems.
The different modes of operation generally vary according to the type of production
control system in use. The following situations are possible:
The production control system is CONTROL-M.
The production control system is not CONTROL-M.
There is no production control system.
See Interfaces to Production Control Systems later in this section for a description of
how CONTROL-D interacts with production control systems.
Decollation Mission Management
Overview
Regular report decollating missions can handle output from the spool or from CDAM
datasets. They are executed once to handle the output produced by a specific job name
(unless defined as cyclic report decollating missions, with a task type of CRP).
Generic Decollating Missions
CONTROL-D provides the option of decollating output from dedicated output classes. Whenever
a non-held output appears on the spool in one of the classes defined for generic processing, the
CONTROL-D monitor looks for a generic decollating mission which matches the job name,
CLASS, DEST, FORM, and EXTWTR of the selected SYSOUT. The search is performed on all
generic missions currently in the Active Missions file (which are not held).
Generic decollation is intended for processing ad hoc sysouts (e.g., MSGCLASS), or reports
generated dynamically from a CICS (or similar) environment. A generic decollating
mission can process sysouts from a job which is still running (e.g., SYSLOG files) at time of
decollation.
Generic Decollating Mission Workflow
A generic decollating mission can be defined for a specific job name but is usually used in
conjunction with a generic job name. A generic job name is specified using mask
characters. Execution of the generic decollating mission is triggered by the appearance of a
job (whose name matches the job name mask) in a specific output class (in non-held
status). These output classes are defined in the CONTROL-D installation parameters. The
appearance of a matching job name in other output classes (or in held status in the generic
classes) does not trigger the execution of a generic decollating mission.
A generic decollating mission can decollate only from the generic classes defined in the
CONTROL-D installation parameters. Any output which is decollated by a generic
decollating mission is purged from spool. After decollation, the missions post-processing
parameters (OUT, SHOUT) are executed, but the mission does not stay in ENDED status.
It is recycled for re-execution (i.e., it is in WAIT SCHEDULE status).
All runtime scheduling criteria (IN, TIME, PRIORITY) are applicable to generic
decollating missions. Usually the recycled generic mission is immediately eligible for
execution and is assigned the WAITING FOR JOB status.
Sysouts of jobs that appear on a generic class but do not have a matching generic
decollating mission name in the Active Missions file are removed from the generic class in
one of the following ways, depending on the value specified in CONTROL-D installation
parameter GENOTFND:
Values which are valid under JES2:
PRIORITY The outputs spool priority is set to one. This allows other output with
higher priority to be processed. Default.
DELETE The output is deleted from the spool.
HOLD The outputs spool status is altered to hold, preventing it from being
processed again by CONTROL-D generic decollation class monitoring.
CLASS=x The outputs class is altered to the specified class. This class should not
be one of the classes specified in parameter GENCLAS.
Values which are valid under JES3:
DELETE The output for which there is no associated scheduled generic decollation
mission is deleted from the spool.
CLASS=x The outputs class is altered to the specified class. This class should be
defined as HOLD=EXTWTR. This class should not be one of the classes
specified in parameter GENCLAS.
Additional Considerations
It is possible that more than one generic decollating mission matches the same job. In this
case, the missions are processed according to their priority levels. If their priorities are
equal, they are processed in the order in which they appear in the Active Missions file (i.e.,
in the order in which they were ordered/scheduled).
When GENERIC=Y and MONITOR is blank, the mission is ordered separately for each
monitor and each copy of the mission is assigned a different monitor number (ID). This
enables concurrent decollating of generic jobs under more than one monitor.
It is also possible that a match could occur between a generic definition and a regular report
decollating mission. This duplication should not create problems because it is impossible to
specify a generic class in an ON CLASS statement of a regular report decollating mission.
However, if a regular (ON DSN) report decollating mission is specified with parameter
WHEN IN QUEUE=Y, it might never execute because its jobs output is deleted by a generic
decollating mission. If WHEN IN QUEUE=Y is specified for a regular report decollating
mission, make sure that the jobs output will not be deleted by a generic mission.
In an environment using a production control system there is a significant advantage in
decollating job reports using regular report decollating missions. The decollating of the
reports can be made dependent on a prerequisite condition which is added by the
production control system after checking that the job has finished executing OK. Using
this method, erroneous reports are not decollated. On the other hand, MSGCLASS output
of the job (on another class) is best handled by a generic decollating mission.
Examples
Generic decollating missions can be used to:
Handle all MSGCLASS outputs of jobs in the same way (e.g., move them from spool to
compressed datasets, allow Online Viewing of output, and retain backups for two
weeks).
Handle ad hoc jobs (e.g., decollate output to users based on job prefix).
Note CONTROL-D first handles regular report decollating missions according to their
priority and then scans the generic output classes for outputs. However, this does not
guarantee that the regular mission of the same job is executed before a generic one.
Scheduling Generic Decollating Missions Via the New Day Procedure
Special scheduling of generic decollating missions ensures that all generic missions are
scheduled successfully before the CONTROL-D monitor starts generic mission processing. If
procedure CTDNDAY fails (e.g., system crash or invalid parameters in generic decollating
mission definitions) while processing a report decollating mission from member GENLIST,
when the CONTROL-D monitor is started, it will not process generic decollating missions
without a manual operator command. If all generic missions are scheduled successfully,
decollating of generic missions resumes when the CONTROL-D monitor is brought up.
If generic mission decollating is not active when the CONTROL-D monitor shuts down for
a new day (e.g., because the operator deactivated it manually), it remains inactive when
the CONTROL-D monitor is brought up again.
Generic decollating missions can also be scheduled manually, or by any of the other
scheduling methods. However, it is highly recommended not to schedule the missions via
the REPLIST member of the New Day procedure with non-generic decollating missions.
Controlling the Generic Process
You can control generic processing by turning it off and on. This process is performed via
operator commands. By default, generic processing is started when CONTROL-D is started
(unless it was previously deactivated by an operator command).
One reason that generic processing may be deactivated is if the CONTROL-D New Day
procedure (CTDNDAY) fails to schedule the generic missions to the Active Missions file.
When generic processing is deactivated, the generic missions do not select output from the
defined generic classes.
Generic processing may also be deactivated if an error occurs while updating the Active User
file during decollation. In this case generic processing is deactivated to prevent the deletion
of sysouts from the spool without the creation of relevant reports in the Active User file.
To stop generic processing, issue the following operator command:
F CONTROLD,STOPGEN
To start generic processing, issue the following operator command:
F CONTROLD,STARTGEN
Defining a Generic User Name List
CONTROL-D provides an option to specify a generic user name in the report decollation
definition. (See parameter DO USER in Section 3 of the CONTROL-D/V User Manual for a
detailed description.) This option defines a generic name that describes a group of users
(e.g., all the branches of the bank, senior management, or financial controllers).
A generic user name list resides in a PDS member. The name of the member is referenced
in the DO USER statement, preceded by an asterisk (e.g., *BRANCHES). The member
must be in a library which should be referenced by DD statement DAGENUSR of the User
Daily job (or CTDNDAY). Although, it is possible to use a few generic user name libraries
in a distributed environment, it is generally recommended that you use only one to
simplify the administration.
Each member in the library represents a generic user name. The contents of the member
are lines in the following format:
Column Data
01 05 TUSER (i.e., constant value TUSER).
06 09 Blank.
10 11 Level code of the user (e.g., recipient) as defined in the Recipient Tree.
12 31 User name.
One line is required for each user. Additional lines in the member are not permitted. Do
not use columns 73-80. Each line must describe a valid user name in the Recipient Tree.
Use the main user name, not a synonym.
Example of the member BRANCHES:
TUSER 30BR101
TUSER 30BR103
TUSER 30BR106
TUSER 30BR112
TUSER 30BR114
TUSER 30BR123
TUSER 30BR127
TUSER 30BR128
TUSER 30BR130
Interfaces to Production Control Systems
Various aspects of CONTROL-D/Production Control System interfaces are explained under
the following topics:
Overview of CONTROL-M Scheduling With CONTROL-D
Scheduling via the CONTROL-M Production Control System
Scheduling via a Non-CONTROL-M Production Control System
Overview of CONTROL-M Scheduling With CONTROL-D
CONTROL-M jobs are scheduled and placed in the Active Jobs file during CONTROL-M
New Day Processing. (The job order is submitted when the runtime requirements are
satisfied.) The main function of CONTROL-M New Day Processing is to determine whether
or not the job should be executed on a specific day. Once that decision is made, the job
order is placed in the CONTROL-M Active Jobs file.
The CONTROL-D category field in the CONTROL-M job order is checked. If the category
field is not blank, the library referenced by DD statement DAREPMIS is searched for the
appropriate report decollating mission. The library is searched for a member with the same
name as the CONTROL-M MEMNAME parameter (the CONTROL-D job name), and for
the same category as specified in the CONTROL-M category field. If category * was used,
the library is searched for all categories of the specified job name.
In this case, the scheduling criteria of the CONTROL-D report decollating missions (if any)
are ignored (unless optional wish WM0983 is applied). Report decollating mission
parameters are passed to CONTROL-D user exit CTDX001. This exit may alter the
contents of the parameters or cancel the decollating mission. If the report decollating
mission is not cancelled by the exit, the report decollating mission is placed in the
CONTROL-D Active Missions file. The original scheduling date assigned to the report
decollating mission is the same as that of the CONTROL-M job order.
Usage Instructions
The library containing report decollating mission definitions is referenced by DD statement
DAREPMIS. This DD statement is normally included in the CONTROL-M User Daily job.
However, if jobs ordered via the New Day procedure have decollating missions, DD
statement DAREPMIS must also be included in the CONTROL-M New Day procedure. Add
DD statement DAREPMIS to procedures CONTDAY and/or CTMDAILY, the CLIST
CTMCJOBS, the Online monitor, etc.
More than one partitioned dataset can be referenced by each DD statement DAREPMIS (in
a job or CLIST). If a library is not referenced, an error message is produced and the
CONTROL-M New Day procedure or the User Daily job skips to the next job.
If you wish to use more than one library to store definitions of report decollating missions,
more than one CONTROL-M Daily can be used. This usually corresponds with using more
than one CONTROL-M scheduling library (for security reasons).
Example (Relevant DD Statements Only)
CONTROL-M User Daily Job 1
//USER01 EXEC CTMDAILY
//DACHK DD DISP=SHR,DSN=parm-library-1(date-CONTROL-record-1)
//DAJOB DD DISP=SHR,DSN=scheduling-library-1(table-1)
// DD DISP=SHR,DSN=scheduling-library-1(table-2)
//DAREPMIS DD DISP=SHR,DSN=report-definitions-library-1
//DAAMF DD DISP=SHR,DSN=the-CONTROL-D-active-missions-file
CONTROL-M User Daily Job 2
//USER02 EXEC CTMDAILY
//DACHK DD DISP=SHR,DSN=parm-library-2(date-CONTROL-record-2)
//DAJOB DD DISP=SHR,DSN=scheduling-library-2(table-1)
//DAREPMIS DD DISP=SHR,DSN=report-definitions-library-2
//DAAMF DD DISP=SHR,DSN=the-CONTROL-D-active-missions-file
For a full description of CONTROL-M New Day processing, see Section 3 in this guide.
Job-Report Dependency
It is recommended that you establish dependency between the successful execution of the
job under CONTROL-M and the processing of the jobs reports by the CONTROL-D report
decollating mission. The dependency can be established using a prerequisite condition.
Parameter OUT of the job order under CONTROL-M should specify a prerequisite
condition to be referenced by parameter IN of the CONTROL-D report decollating mission.
Using CONTROL-M Scheduling Data Summary
The advantage of invoking the CONTROL-D report decollating missions via CONTROL-M
scheduling criteria is that the scheduling criteria only have to be defined once (under
CONTROL-M). It is then unnecessary to update the scheduling criteria of CONTROL-D
each time the criteria are updated in CONTROL-M. In addition, ad hoc job orders under
CONTROL-M automatically place report decollating missions in the CONTROL-D Active
Missions file.
The job scheduling information is managed by one source of data and control.
Scheduling via the CONTROL-M Production Control System
When the CONTROL-M production control system is in use, the integrated environment of
CONTROL-D and CONTROL-M can produce optimum results.
In such an environment, the recommended method of scheduling a non-generic report
decollating mission is via CONTROL-M scheduling criteria.
The CONTROL-M Job Scheduling Definition screen contains a field (D-CAT) to indicate
that a CONTROL-D report decollating mission should be scheduled whenever the job is
scheduled to run under CONTROL-M.
In this field, the user specifies the CONTROL-D category of the report decollating mission
that should be selected from the CONTROL-D report decollating mission library. To select
all categories of the job, specify an asterisk (*) in the D-CAT field. (If the D-CAT field is
empty, a report decollating mission is not scheduled for the job.)
Each report decollating mission can be composed of a few categories. The category is
usually used as a mechanism to specify different report decollating (processing)
parameters for different execution days (e.g., a regular work day, end of the month).
Based on different scheduling criteria under the CONTROL-M monitor, the same
CONTROL-M job order can be used to select different report decollating missions of
different categories.
When CONTROL-M and CONTROL-D operate together in the same environment, the
following situations may arise:
A job to be run by CONTROL-M does not generate any reports. Therefore, there is no
need to process the job by CONTROL-D. In this case, the category field in the
CONTROL-M Job Scheduling Definition screen should remain blank.
A job to be run by CONTROL-M generates a report but does not (yet) have a report
decollating mission defined for the job. (CONTROL-D can be implemented in phases.)
In this case, the category field in the CONTROL-M Job Scheduling Definition screen
should remain blank.
A job generates a report which should be decollated by a CONTROL-D report
decollating mission. In this case, the name of the CONTROL-D category of the report
decollating mission should be defined in the D-CAT field in the CONTROL-M job
scheduling definition. An asterisk (*) can be used to select all categories of the job.
Scheduling via a Non-CONTROL-M Production Control System
The primary advantage of invoking CONTROL-D report decollating missions from the user
exit of a production control system is that scheduling criteria only have to be defined once
(under the production control system). The user does not have to update scheduling criteria
of report decollating missions each time they are updated in the production control system.
The following methods can be used to implement CONTROL-D in data centers which use a
production control system other than CONTROL-M:
CONTROL-D scheduling is managed independently of the production control system.
This method is the same as managing the scheduling without any production control
system.
The scheduling of report decollating missions under CONTROL-D is controlled by the
production control system (described in the following paragraphs).
Most production control systems include some means of passing control to a user exit
before a job is submitted. Some products have user exits in earlier stages (when the
decision to schedule a job for a specific day is made). The basic idea is to invoke the
CONTROL-D report decollating mission from the user exit of the production control
system.
When a production control system and CONTROL-D operate together in the same
environment, the following situations may arise:
A job which is to be run by the production control system does not have any reports. It
does not need to be processed by CONTROL-D.
A job which is to be run by the production control system does not yet have a report
decollating mission defined for the job.
A job is to be run by the production control system and decollated by CONTROL-D.
To handle the situations mentioned above, the user should use some method of specifying
to the production control system user exit whether or not a report decollating mission
should be issued for the job. The decision of how to mark a job is local for each installation
and can be performed using one of the following methods:
Specify a flag in a job scheduling parameter of the production control system that is
otherwise unused, or is used for another purpose (e.g., the job description).
Use a list accessed by or internal to the user exit. The list must be modified whenever a
new report decollating mission is defined.
When the production control system user exit receives control and a decision is made to
invoke a report decollating mission, the user exit should activate program CTDRRQ. This
program performs a search for the report decollating mission. For more information about
program CTDRRQ and its parameters, see Programs Called During New Day Processing
earlier in this section.
The search is made for a member name with the same name as the job name and for the
specified category. The scheduling criteria of the CONTROL-D report decollating mission
(if any) are ignored. The report decollating mission parameters are passed to CONTROL-D
user exit CTDX001. This exit can alter the contents of the decollating parameters or cancel
the decollating mission. If the report decollating mission is not cancelled by the exit, it is
placed in the CONTROL-D Active Missions file.
Usage Notes
When a report decollating mission is scheduled by invoking program CTDRRQ from a
production control system user exit, the following DD statements must be used:
STEPLIB IOA LOAD library (if not included in the MVS Linklist).
DAAMF CONTROL-D Active Missions file.
DAOUT Output print file.
DALOG IOA Log file.
DAGENUSR Generic user names library (if this option is used by your site).
If the production control system does not have an appropriate exit or you do not want to
use this method to schedule report decollating missions, there is an alternative. Most
production control systems can produce a night plan report a list of jobs to be executed
during the night. This list can be used as input to a program that will schedule report
decollating missions by invoking program CTDRRQ.
The IOA SAMPLE library contains examples of production control system interfaces.
Member $$INTER in the IOA SAMPLE library contains an index to these interfaces. A
user-written interface to CA-7 (UCC7) is not officially supported but is available. For more
information about the CA-7 (UCC7) interface and interfaces to other production control
systems contact your IOA representative.
JobReport Dependency
It is recommended that you establish dependency between the successful execution of the
job under the production control system and the processing of the jobs reports by the
CONTROL-D report decollating mission. This dependency can be established using the
prerequisite condition concept.
A prerequisite condition (e.g., REP-M01AUPD-READY) should be specified in the IN
parameter of the CONTROL-D report decollating mission. This condition is added to the
IOA Conditions/Resources file by the production control system after the job finishes
executing successfully.
Use utility IOACND to add a prerequisite condition. Utility IOACND can be activated from
a production control system user exit, from a specially defined successor task of the job
under the production control system, or from a job step.
It is not mandatory to establish via dependency prerequisite conditions between the
production control system and CONTROL-D. If dependency is not established,
CONTROL-D will process the reports when the job appears on the output queue. It is also
possible to use manual prerequisite conditions for report processing when required.
Considerations for When CONTROL-M and CONTROL-D Are Installed
The following issues should be considered if both CONTROL-M and CONTROL-D are being
installed:
Prior to release 5.0.0 of CONTROL-M and CONTROL-D, it was necessary to modify
some CONTROL-D daily JCL procedures and CLISTs. In the current release, no
modifications are required. The appropriate CONTROL-M/CONTROL-D files are
dynamically allocated. DD statement DAALOCIN points to a member in a partitioned
dataset which contains a list of files that are dynamically allocated.
When both CONTROL-M and CONTROL-D are installed, IOA installation parameter
CTM must be set to Y. When CTM=Y, maintenance of conditions in the
Conditions/Resources file is handled by the CONTROL-M New Day procedure and not
by CONTROL-D. Therefore, it is recommended that the CONTROL-M New Day
procedure always run before the CONTROL-D New Day procedure. The CONTROL-M
New Day procedure CONTDAY should delete all conditions from the previous year. The
CONTROL-M New Day procedure can receive parameters which control the delete
operation via DD statement DAFRMIN.
It is recommended that you clean the IOA Conditions/Resources file periodically using
utility IOACLRES. Use only utility IOACLRES to clean the IOA Conditions/Resources
file because this file is used for both CONTROL-M and CONTROL-D. Use DD
statement DACRSIN to assign the parameter control member.
Utility IOALDNRS builds the Manual Conditions file from information in the
CONTROL-M Active Jobs file, the CONTROL-D Active Missions file, and the IOA
Conditions/Resources file. However, utilities CTMLDNRS and CTDLDNRS, which
perform the same function, are supplied for compatibility with previous releases of
CONTROL-M and CONTROL-D.
We strongly recommend that only utility IOALDNRS be used to build the Manual
Conditions file because the same file is used for both CONTROL-M and CONTROL-D.
Use DD statement DALNRIN to assign the parameter control member.
Printing Mission Management
The topics listed below are explained on the following pages:
Printing Mission Workflow
Printing Mission Definition
Preparing the Skeleton
Advanced Scheduling Issues
Distribution According to Scheduling Dates
Report Decollating and Printing Mission Dependency
Printer Control
One-Chunk Method
Multi-Chunk Method
One-Outgroup Method (JES2 Only)
Opening/Closing Printers
Printing Process
Identifying CONTROL-D Chunks on Spool (JES2 Only)
CONTROL-D/Writer Facility
Activating the CONTROL-D/Writer Facility
Printing on AFP (APA) Printers
Printing Using XEROX LCD5 (DJDE) Parameters
Using OUTPARMS for Global Control of Printing Characteristics
Printing to a File
Tailoring Exit CTDX005
Advanced ACIF Interface Facility
AFPDS and ACIF
ACIF Utility Benefits
Making ACIF Accessible to CONTROL-D
Activating the Advanced ACIF Interface
WYSIWYG Viewing of XEROX Reports
Overview
Installation
Processing XEROX Reports
Parameters for the DVS Printer Emulator
CCIFPARM Library
Printing Mission Workflow
The following parameters (specified in the Online facility) affect printing mission
workflow.
BATCH Specifies whether a printing mission is submitted as a batch job or as
a subtask of a Printers Control monitor. Optional.
Y (Yes) Submit the current printing mission as a batch job instead
of executing it as a subtask of the Printers Control
monitor.
N (No) Execute the printing mission as a subtask of the Printers
Control monitor. Default.
SKELETON Name of an existing member in the CONTROL-D SKL library. This
member contains the job skeleton or started task skeleton for the
batch job. Mandatory if BATCH is set to Y.
FREE Sysout allocation mode. Determines whether or not chunking is
implemented and when sysout files will be freed. Optional. Valid
values are:
CLOSE Regular chunking mechanism is used. Sysout files are
freed as soon as they are printed. Default.
END Sysout files are allocated as usual but are not freed until
the end of the batch job. This value is available only if
BATCH=Y is specified.
TIMEOUT mm Number of minutes within which the printing mission
should start. If the mission does not start during the
specified time interval, it terminates NOTOK. Default: 5
minutes.
See Section 4 of the CONTROL-D User Manual for more information about these
parameters
The defined printing missions are stored in the Print Mission library.
The diagram below illustrates the steps of Printing Mission workflow from initial
scheduling of the printing mission through the printing of reports.
A printing mission is executed as follows:
The CONTROL-D monitor makes a fast scan of the Active User file to locate all reports
which require printing by the specified printing mission. The result of this process is a
Print Plan file with an entry for each report to be printed.
In addition, the CONTROL-D monitor selects an available logical printer for this printing mission.
When the printer is selected, control is passed to the Printers Control monitor (CTDPRINT) if
parameter BATCH was set to N, or to a batch job if parameter BATCH was set to Y.
Chunks are sent to the spool according to the value specified for parameters CHUNKSIZE
and OVERRIDE. See Printer Control later in this section for further details.
After printing is completed, the status of each report entry from the Print Plan file is
updated in the Active User Report List file according to the printing completion status
(e.g., Printed/Not printed).
Processing a Batch Printing Mission
When the report is printed by a batch job, the CONTROL-D monitor reads the member
whose name is specified in the printing mission (e.g., PRTSKL) from the library referenced
by DD statement DADSKL of the CONTROL-D monitor. This member contains a job
skeleton or started task skeleton for the batch job.
Note Because the same library is used for printing, migration, backup and restore mission
skeletons, the names of all missions must be unique.
Preparing the Skeleton
To use a printing mission in batch mode, a skeleton member must be prepared in the
CONTROL-D SKL library. The skeleton member can be either a job skeleton or a started
task skeleton. See sample member PRTSKL in the CONTROL-D SKL library.
The skeleton member can contain parameters which are interpreted by the
CONTROL-D monitor. These parameters are:
%COM#% Number of the COM file record assigned to this mission.
%MISSION% Mission name.
%CATEGORY% Mission category.
%GROUP% Mission group.
%OWNER% Mission owner ID.
%PRTY% Mission priority.
%DEST% Mission destination.
When CONTROL-D finishes preparing the member for submission, control is passed to
user exit CTDX009. This exit can modify the contents of the submitted job (by adding,
deleting or modifying the JCL). The exit can return the following return codes:
0 Submit the job.
4 Do not submit the job. User exit CTDX009 can request CONTROL-M to submit the
job. Job submission can be done via CTMAJO routines to ensure correct handling of
the print job under CONTROL-M.
8 Do not submit the job. Terminate the mission with NOTOK status.
Synchronization between the printing mission and the CONTROL-D monitor is achieved by
creating a special control subtask for each printing mission in the CONTROL-D address
space. (The same method is used to synchronize the CONTROL-D and Printers Control
monitors.) This control subtask is synchronized with the corresponding print task via the
ENQ mechanism. The QNAME for this ENQ is taken from CONTROL-D installation
parameter PRTSTC in member CTDPARM in the IOA INSTCTD library.
To run a batch printing mission on a CPU other than the CPU in which the CONTROL-D
monitor runs, this QNAME should be shared through GRS, MIM, or other enqueue
manager products.
If parameter PRTMON# is set to 0 in member CTDPARM, no Printers Control monitors are
started. In this case, parameter BATCH in the printing mission must be set to Y.
See One-Outgroup Method (JES2 only) under Printer Control later in this section for
additional considerations on running printing missions in batch mode.
Note Printing mission abend or timeout does not cause termination of CONTROL-D
monitors. In such cases, the printing mission terminates with a status of NOTOK.
Distribution According to Scheduling Dates
It is possible to organize printing missions so that each days printing management (i.e.,
the printing workflow) is the same. The simplest method is to specify DAYS=ALL in the
Basic Scheduling parameters of all printing missions. Once a day, when the New Day
procedure calls program CTDPRQ, all printing missions scheduled for the next 24 hours
are placed in the Active Missions file.
This printing organization does not maximize the capabilities of CONTROL-D. You can
organize the printing order in different ways for different types of days (e.g., weekdays,
weekends, end of the month, holidays).
Using CONTROL-D, it is possible to define several copies of the same printing mission.
Each copy is an independent definition of the printing mission and can have different
scheduling criteria, different runtime criteria, different bundling instructions, different
printing configurations, etc. For example, the (form) STD printing mission will start not
later than 05:00 on every workday, will start not later than 04:00 at the end of the month,
and will not be scheduled for holidays.
Since there is no limit to the number of printing missions which can be defined, the user
can organize the printing process to optimally suit every production day of the year.
Report Decollating and Printing Mission Dependency
We recommend that the printing of bundles by CONTROL-D printing missions depend
upon the successful decollation of reports. Dependency can be established using the
prerequisite condition concept. Parameter OUT of the report decollating mission should
specify a prerequisite condition that is referenced by parameter IN of the printing mission.
Using this method, bundles start printing only when all the reports which must be
included in them have been decollated.
It is possible to define different report-printing dependencies for different scheduling dates
(e.g., regular dates vs. end of the month). This can be done, as described above, by using
multiple copies of the same printing mission, each one distinguished by different basic
scheduling criteria and different runtime scheduling criteria (prerequisite conditions, time,
priority, etc.).
Printer Control
CONTROL-D provides the following methods for printing bundles:
One-Chunk Method Send entire bundle to the spool for printing.
Multi-Chunk Method Send a specified number of lines at a time to the spool for printing.
One-Outgroup Method Send one outgroup (containing all output files produced by a
printing mission) at the end of that printing mission.
These methods are described below.
One-Chunk Method
Using this method, the entire bundle is sent to the spool for printing at one time. This
method is activated by specifying CHUNKSIZE=0 in the printing mission definition. If not
specified in the printing mission definition, CHUNKSIZE defaults to the value defined in
installation parameter PRINTER. Specifying CHUNKSIZE=0 suppresses installation
parameter OUTGRP.
This method can be used for printing reports that contain identical printing
characteristics. If reports which contain different printing characteristics are processed in
this manner, the characteristics of the first report are used for all the reports in the
bundle.
Note If the bundle contains reports for different printing destinations, a separate chunk is
created for each destination but CONTROL-D does not monitor the printing of the
chunk. CONTROL-D continues to send additional chunks of the bundle to the spool.
Multi-Chunk Method
CONTROL-D creates a new chunk each time the number of lines specified in parameter
CHUNKSIZE is exceeded, or when printing characteristics of the reports change,
whichever comes first (unless CHUNKSIZE is specified as 0 as described in the
One-Chunk method above). CHUNKSIZE can be specified in the printing mission
definition. If it is not specified in the printing mission definition, CHUNKSIZE defaults to
the value defined during the installation process. For the Multi-Chunk method, the value
for parameter CHUNKSIZE must be greater than 1. The recommended value is 10000.
Multi-Chunk processing provides the following major advantages:
The ability to print reports with different printing characteristics in the same bundle.
The ability to control the size of the chunk so the spool does not become overloaded.
Under the Multi-Chunk method, the printer must be assigned to CONTROL-D using the
following JES commands.
Under JES2
A printer is normally defined as DEST=LOCAL with one or more printing classes. To
assign the printer to CONTROL-D, use a JES operator command to initialize the printer
with the following parameters:
S=N No separator (because CONTROL-D creates its own banner pages).
R=destination This value is set during CONTROL-D installation for each printer.
SEPDS=N No dataset separator.
WS=-Q Select from all output classes on which CONTROL-D can print.
Sample JES2 operator command:
$TPRT1,S=N,R=U1001,SEPDS=N,WS=(-W,-Q,-PRM,-LIM/R,-F,-UCS,-FCB)
Verify that the printer has been modified successfully with all the above attributes.
Under JES3
Change the printer options using an operator command. Initialize the printer with the
following parameters:
B=N No burst separator because CONTROL-D creates its own banner
pages.
WC=class The class defined in CONTROL-D installation parameter PRINTCL.
Sample JES3 operator commands: (PRINTCL=Z)
*CALL WTR,OUT=04E,H=N,B=N,WC=Z,WS=CL
*S 04E
where * is the JES3 command prefix.
Verify that the printer has been modified successfully with all the above attributes.
One-Outgroup Method (JES2 Only)
It is possible to combine all the output files produced by a printing mission in one output
group. Such a method is useful to ensure that all files will be printed together even if the
JES printer is not dedicated to CONTROL-D and is used for other jobs as well as for
CONTROL-D reports. This method is also useful for output files that are sent through NJE
to a remote computer.
To combine the output files, perform the following steps:
1. Run the printing mission as a batch job. (Set parameter BATCH to Y in the Printing
Mission Definition screen.)
2. Free all sysout files at the end of the job. (Set parameter FREE to END in the Printing
Mission Definition screen.)
3. Note the following:
Parameters CLASS, DEST, WTRNAME, PRMODE and OUTGROUP should be the
same for all reports included in the printing mission.
Parameter OVERRIDE in the Printing Mission Definition screen can be used to
assign uniform values to parameters CLASS, DEST and WTRNAME.
Parameters PRMODE=PAGE and GROUPID=CONTROLD should be defined in all
OUTPUT statements in the Printers Control monitor JCL procedure (CTDPRINT).
4. Set parameter USERSET to YES in the OUTDEF statement in member JES2PARM in
the SYS1.PARMLIB library.
5. Verify that the output class is a non-held class.
Opening/Closing Printers
During installation, a value of OPEN or CLOSE is assigned to parameter PRINTER for
each printer. If installation parameter PRINTER is set to OPEN for a printer, it is not
necessary to open that printer unless it has been closed by an operator command.
To display the entire list of open printers, issue operator command:
F CONTROLD,STARTPRT
If a required printer was defined as CLOSE, issue the following operator command to
open it:
F CONTROLD,STARTPRT,printername
where printername is the name assigned to the printer during CONTROL-D installation.
The following message is issued to the operator console from which the operator command
was issued:
CTD130I COMMAND STARTPRT ACCEPTED FOR PRINTER printername
To close a CONTROL-D printer, issue operator command:
F CONTROLD,STOPPRT,printername
When there are no CONTROL-D bundles to print, you can reset the printers original
parameters with a JES command.
Note It is not necessary to close CONTROL-D printers. A printer remains open but
nothing is printed if the JES2-DEST or JES3-CLASS setting of the printer is not
assigned to CONTROL-D.
Printing Process
When a printing mission is activated manually or automatically, the printing mission
creates an index of all reports which are ready to print and which were specified to be
printed by this particular printing mission. This index can be viewed and controlled online
using the Print Control option (P) in the Active Missions screen. The bundle is then
prepared for printing.
CONTROL-D searches for an available printer that was defined in parameter PRINTER of
the printing mission definition. If parameter PRINTER has not been specified,
CONTROL-D searches for any available printer that was defined in installation parameter
PRINTER.
If a printer was defined as CLOSE, an operator command is required to OPEN the printer
(as described above). If a printer was defined as OPEN or if an operator command was
issued to open it, CONTROL-D sends the bundle to the spool for printing.
When using the One-Chunk method, the full bundle is created on the spool and waits in
queue to print (along with any other output that may be on the spool i.e.,
non-CONTROL-D output).
When using the Multi-Chunk method, it is recommended that you send only CONTROL-D
bundles to the printer at a specified time. If the printer is not assigned exclusively to
CONTROL-D when using the Multi-Chunk method, non-CONTROL-D output may be
printed in a CONTROL-D bundle. After the bundles finish printing, the printer can be
assigned to print non-CONTROL-D output.
Bundle printing can be interrupted using the Print Control option in the Active Missions
Status screen. This may be required to immediately print an important non-CONTROL-D
output, to change priority of a report printed by CONTROL-D, or to perform any other
desired action during the printing process. Refer to Section 2 of the CONTROL-D User
Manual for a description of this option.
Identifying CONTROL-D Chunks on Spool (JES2 Only)
CONTROL-D provides the ability to uniquely identify each chunk that is sent to the JES
output queue. This is done by appropriately setting the OUTGROUP field (GROUPID in
JCL, O-GRP-N in SDSF) for the chunks that CONTROL-D sends to the spool.
CONTROL-D can place the following types of identifiers in the OUTGROUP field:
1. Original job name of the report.
2. User name of the user (e.g., recipient) who is to receive the report.
3. Printing mission name.
4. Unique time stamp.
5. Specific string specified in the printing mission.
To activate this feature, do the following:
1. Add a special OUTPUT statement to the CONTROL-D Printers Control monitor
procedure (CTDPRINT). It must be coded as follows:
//OUTGROUP OUTPUT GROUPID=CONTROLD
If the site runs more than one Printers Control monitor (CTDPRIN2, etc.), add this DD
statement to all the Printers Control monitor procedures.
2. Add operand GROUPID=CONTROLD to all OUTPUT statements in the Printers
Control monitor procedure(s). This operand must be coded in the first operand in the
OUTPUT statements.
3. Set the OUTGRP CONTROL-D installation parameter in member CTDPARM in the
IOA INSTCTD library as detailed in the IOA Installation Guide.
We recommend specifying OUTGRP=Y, and using the GROUP parameter in the printing
mission definition to define OUTGROUP processing. Refer to Section 4 of the CONTROL-D
User Manual for information about using the GROUP parameter.
CONTROL-D/Writer Facility
The CONTROL-D/Writer facility enables CONTROL-D to directly control AFP printers
using standard CONTROL-D screens. Using this feature, CONTROL-D can print directly
to a printer through the Print Services Facility (PSF) without writing the output to SPOOL
through JES. The operator can exercise a level of control over output printed via the
Writer facility that cannot be exercised over output printed via JES.
Communication between CONTROL-D/Writer and the PSF is realized via the Functional
Subsystem Interface (FSI). The FSI allows communication with a Functional Subsystem
(FSS) and a Functional Subsystem Application (FSA). The FSS/FSA can be a program that
allows a site to support sophisticated printer devices.
The PSF is an example of an FSS. The PSF can support printers such as the IBM 3820 and
IBM 3800-3. Communication between JES and the PSF is accomplished using the FSI. To
communicate with the PSF, CONTROL-D/Writer uses the same FSI functions that are
used by JES.
The CONTROL-D/Writer facility is applicable to each printer identified as a CONTROL-D
printer by CONTROL-D installation parameter DEFPRTS. See Printers Definitions in
A CONTROL-D printing mission that prints on a CONTROL-D printer has special controls
and options in the Print Plan screen that allows the user to change the flow of printing.
CONTROL-D processes these printing missions the same way it processes regular printing
missions (i.e., Print Plan creation, deletion, printer allocation, and balancing).
Actual printing to a CONTROL-D printer is processed by the CONTROL-D FSS monitor.
This monitor allocates a printer from the PSF (the printer is drained by JES) and prints
directly to that printer.
The Print Plan screen enables the user to change the flow of printing by performing the
following CONTROL-D/Writer actions:
Halt the printing mission
Resume printing
Skip to a specific point in the Print Plan
Perform a test print of a report
Immediately Print a report
Perform various other options
See CONTROL-D/Writer Facility in Section 2 of the CONTROL-D or CONTROL-V User
Manual for a description of these actions.
Activating the CONTROL-D/Writer Facility
The activation procedure for the CONTROL-D/Writer feature consists of a number of steps.
These steps are listed below. A detailed description of the steps follows.
1. Turn ON Optional Wish WD3013.
2. Tailor the CONTROL-D FSS Monitor Procedure.
3. Define the CONTROL-D Printer(s) in Member CTDPARM.
4. Initialize the CONTROL-D/Writer Subsystem.
Step 1 Turn ON Optional Wish WD3013
Update member IOADFLTC in the IOA MAC library and specify APPLY=YES for WD3013
to activate the CONTROL-D/Writer feature. In parameter DATAC=, specify three
characters that will be used by CONTROL-D as an identifier string to indicate that a
printer is a CONTROL-D printer. The default specification is DATAC=FSS.
Step 2 Tailor the CONTROL-D FSS Monitor Procedure
Create a new CONTROL-D FSS procedure from your current FSS procedure.
Notes It is possible to have more than one CONTROL-D FSS monitor. Each monitor can
control one or more FSS printers.
The name of the CONTROL-D FSS procedure must contain the 3-character identifier
specified in parameter DATAC= in optional wish WD3013 in member IOADFLTC.
It is recommended that the first three characters of the procedure be the same as the value
of installation parameter %PROCPREFD%.
For example, if you use the name CTDFSS1, add the following DD statements from
procedure CTDPRINT to procedure CTDFSS1:
Add the following parameters from statement //CTDPRINT PROC to statement
//CTDFSS1 PROC:
// STEPLIB=IOAP.V514.LOAD,
// DBPREFD=CTDP.V514,
// DBPREFA=IOAP.V514,
// ILPREFD=CTDP.V514,
// OLPREFD=CTDP.V514,
// OLPREFA=IOAP.V514,
// ILPREFA=IOAP.V514,
// LANG=,
// TREE=CTDTREE,
// OUT=*,
// OUTDUMP=Z DUMP SYSOUT CLASS
Actual values for all parameters shown above should be taken from the parameters of
the CTDPRINT monitor procedure.
Add the following DD statement after the EXEC statement of procedure CTDFSS1:
//STEPLIB DD DISP=SHR,DSN=&STEPLIB&LANG
Before the printers section in procedure CTDFSS1, add all the DD statements from
procedure CTDPRINT except DD statement STEPLIB.
Step 3 Define the CONTROL-D Printer (s) in Member CTDPARM
Each FSS printer defined in procedure CTDFSS1 must be defined in the printer list of member
CTDPARM. The printer name is the same as the name specified in procedure CTDFSS1 and
the destination is the name of the corresponding FSS procedure (e.g., CTDFSS1).
For example:
DEFPRTS PRINTER=(PRTM,CTDFSS1,1000,CLOSE,10000,APA)
Note The string specified in parameter DATAC= of optional wish WD3013 must appear in
the destination field of a CONTROL-D printer but cannot appear in any CONTROL-D
logical printer destination.
For more information about defining printers, see Printers Definitions in Section 5 of the
IOA Installation Guide.
All other parameters are the same as for any other printer. See Specify CONTROL-D
Parameters in Section 5 of the IOA Installation Guide.
Step 4 Initialize CONTROL-D/Writer Subsystem
Issue the following command after installation and after every IPL, or add the command to
member COMMNDxx in the SYS1.PARMLIB library:
S IOASINIT,OPTIONS=W
Note There is no need to start the CTDFSS1 procedure. It is started automatically when the
printer is activated by CONTROL-D. If the printer is defined with printer status
CLOSE, command STARTPRT must be issued.
Printing on AFP (APA) Printers
AFP (Advanced Function Printing presentation) is the standard IBM laser printing technology
which supports printers such as the 39xx and 38xx family of printers, and uses APA (All Points
Addressable) technology. Throughout this guide and in the CONTROL-D User Manual, these
printers are referred to as AFP printers. The way in which CONTROL-D supports AFP printers
is described. (Additional information, including instructions for customization, can be found in
the IOA Installation Guide in the step that implements AFP Support and in the publication
Implementing AFP in the CONTROL-D Environment.)
When a sysout is printed on AFP printers, two additional printing control parameters are added:
FORMDEF and PAGEDEF. These parameters specify the member name of a form definition and
page definition in the FORMDEF and PAGEDEF libraries, respectively. These parameters cannot
be defined in a standard DD statement. Instead, they are specified in an OUTPUT statement
which is referenced by a DD statement.
Support for PAGEDEF and FORMDEF in CONTROL-D is implemented by either of two methods:
The first method uses a specified OUTPUT statement and is parallel to the JCL approach.
The second method uses CDAM PAGEDEF/FORMDEF parameters, is more flexible,
and is easier to use.
Using CDAM PAGEDEF/FORMDEF Parameters
Under CONTROL-D you can specify parameters FORMDEF and PAGEDEF without
actually using an OUTPUT statement. When writing directly to a CDAM file, use the
CDAM parameters PAGEDEF and FORMDEF. When you decollate a report from spool, you
must specify the requested PAGEDEF/FORMDEF in the decollation mission definition
PRINT/CDAM PARMS field.
Note This option is not supported when using the One-Chunk method. See Printer Control
When using this option, CONTROL-D looks for an OUTPUT statement named CONTROLD
or CONTROLF during the printing process and automatically inserts inline FORMDEF
and PAGEDEF. This option utilizes the AFP Inline Resource Option.
This method requires that a CONTROLD and CONTROLF OUTPUT statement exist under
all printing environments (the Printers Control monitor, the IOA Online monitor, the TSO
user, etc.). See AFP Support in the IOA Installation Guide for site adaptations required for
AFP support.
Using a Specified OUTPUT Statement
The name of an OUTPUT statement containing the FORMDEF/PAGEDEF combination can
be specified.
When writing directly to a CDAM file, use CDAM parameter OUTPUT.
When decollating a report from spool, specify the requested OUTPUT statement in the
decollating mission definition PRINT/CDAM PARMS field.
Any OUTPUT specified in the PRINT/CDAM PARMS field overrides any such parameter
specified in the DD statement during CDAM file creation.
Note The name of the OUTPUT statement used is the name under the Printers Control
monitor and not the name of the OUTPUT statement in the job that created the sysout.
When using this method, CONTROL-D searches for the specified OUTPUT statement and
uses it to print the report. An OUTPUT statement must exist under all printing
environments (Printers Control monitor, IOA Online monitor, TSO user, etc.) for every
combination of FORMDEF/PAGEDEF which is in use. See AFP Support in the IOA
Installation Guide for site adaptations required for AFP support.
AFP Page Mode Output
Any AFP report (including Page Mode reports) can be decollated by CONTROL-D.
Decollating includes identifying each page of a report with identifying strings and
assigning the pages to recipients accordingly. CONTROL-D recognizes page breaks in AFP
Page Mode output (CATEGORY 5).
Searching for a string in Page Mode output can be performed on the entire line of data, as
supported by AFP (from column 1 to column 32767).
Page Mode output is usually produced by DCF (IBMs mainframe word processor) when
making Composed AFP documents, by GDDM and other software tools (such as SLR) that
use GDDM for producing graphic reports and PostScript output (translated to AFP
Structured Fields), and by application programs.
Page Markers Under AFP
Page Markers for differentiating between user bundles (via print perforation markers) can be
initiated using standard methods with most printers. (See the publication Implementing AFP
in a CONTROL-D Environment for details.) The exception is the 3800-3 printer. For special
3800-3 printer Page Markers, refer to member DOCDPAGM in the IOA SECUDATA library.
In-Stream AFP Control Statements
A major feature of CONTROL-D is the automatic insertion of AFP control parameters
in-stream in reports. This feature is especially useful for the following situations:
When implementing advanced AFP options:
AFP control parameters (structured fields) can be inserted in reports without modifying
application programs.
When AFP control parameters are contained at the beginning of the sysout, and the
sysout is decollated into different users bundles:
AFP control parameters would normally be missing from all but the first user bundle. This
feature can verify that AFP control parameters are automatically inserted in each users bundle.
This feature operates as follows:
A special library is used to define the AFP control parameters of each report. This library
is referenced by DD statement DAAPA of the Printers Control monitor. The original name
supplied is OLPREFD.APAPARM.
The library can be defined as RECFM=V or RECFM=F. By default, it is defined as
RECFM=V. RECFM=V is highly recommended because if you use an APAPARM library
with RECFM=F, you must add four bytes (RDW) before every AFP control parameter and
before command IMM/IDM.
The APAPARM library contains one member for each job which produces output to be
printed on AFP printers. The member name must be identical to the job name. Each
member contains AFP control parameters for all reports produced by the job.
Note If you use the APAPARM option for Online printing, be sure your online environment
(e.g., IOA Online monitor, TSO Logon procedure) is referenced by DD statement DAAPA.
In each member, there must be one line in the following format for each AFP report
produced by this job:
+++repname (+++ starts in column 1)
where:
+++ Identifies the line as a report name line.
repname Name (or mask) of the report (maximum length: 20 characters). repname
must be the same as the name of the report specified in Report
Decollating parameter DO NAME.
Note Any number of +++repname lines can be present in one member (i.e.,
several reports can be produced by the same job).
Following the +++repname line, one or more AFP control parameters records may
follow.
Any AFP command can be specified in its original AFP hexadecimal format. The
following special commands can also appear as AFP control parameter records:
IMM=copy-group-name (maximum length: 8 characters)
IDM=page-format-name (maximum length: 8 characters)
These commands are translated to the appropriate hexadecimal AFP structured fields
IMM and IDM.
Note If you are using APAPARM libraries with RECFM=F, add four bytes (RDW) before
every AFP control parameter and before command IMM/IDM.
Example
Consider the following report decollating mission parameters:
JOBNAME=ARINS1
DO NAME=AR-REPORT-1
DO NAME=AR-REPORT-2
Member ARINS1 in the CONTROL-D APARARM library can contain the following:
+++AR-REPORT-1
IMM=GROUP1
IDM=PAGFM1
+++AR-REPORT-2
IMM=GROUP2
When CONTROL-D prints the report named ar-report-1, the two lines following the +++
line are written at the beginning of the report.
When CONTROL-D prints the report named ar-report-2, the last line in the member is
written to the report.
Sample member APARARMS is located in the CONTROL-D APARARM library.
Not every job has special AFP control parameters. The library should only contain
members for jobs with in-stream AFP control parameters and not for other jobs.
When the Printers Control monitor or a batch printing mission is about to print a report
for a user on an AFP printer, it searches for a member name with the same name as the job
which produced the report. It looks for the report name in the member, translates any
IMM/IDM commands to hexadecimal, and writes all the reports AFP control parameters to
the printer (via the spool). AFP printers must be defined as APA in member CTDPARM.
(See Printers Definition under Specify CONTROL-D Parameter in Section 5 of the IOA
Installation Guide for more information.)
Printing Using XEROX LCDS (DJDE) Parameters
For many XEROX printer models (9700, 8700, etc.), it may be necessary to specify different
printing options using special control records which are inserted in the sysout directed to
the printer. These parameters are usually referred to as DJDE parameters. The way in
which CONTROL-D supports DJDE parameters is described below. Additional information
including instructions for local adaptations can be found in the IOA Installation Guide.
A special library is used to define the DJDE parameters of each report. This library is
referenced by DD statement DADJDE of the Printers Control monitor. The original name
supplied is OLPREFD.DJDEPARM.
The CONTROL-D DJDEPARM library contains one member for each job which produces
output to be printed on XEROX printers. The member name must be identical to the job
name. Each member contains DJDE parameters for all reports produced by the job.
Note If you use option DJDEPARM for online printing, be sure your online environment
(e.g., IOA Online monitor, TSO Logon procedure) is referenced by DD statement
DADJDE.
In each member, there must be one line in the following format for each report produced by
this job:
+++repname (+++ starts in column 1)
+++ Identifies the line as a report name line.
repname Name or mask of the report (maximum length: 20 characters).
repname must be the same as the name of the report specified in
report decollating parameter DO NAME.
One or more DJDE control parameters records may follow the +++repname line.
Note Any number of +++repname lines can be present in one member (i.e., several reports
can be produced by the same job).
Example
Consider the following report decollating mission parameters:
JOBNAME=ARINS1
DO NAME=AR-REPORT-1
DO NAME=AR-REPORT-2
Member ARINS1 in the CONTROL-D DJDEPARM library can contain the following:
+++AR-REPORT-1
DJDE C MULTI RECORD DJDE EXAMPLE
DJDE FORMS=(XEROX1,1,3),FORMAT=XPDE12,FONTINDEX=1,NUMBER=(3,15,55),;
DJDE COLLATE=YES,ASSIGN=(1,5),ASSIGN=(5,32),;
DJDE FONTS=((P0612A),(P0812A)),;
DJDE ASSIGN=(12,63),TOF=5,BOF=66,END;
+++AR-REPORT-2
DJDE JDE=JDEAR3,JDL=JDLAR3,END;
When CONTROL-D prints the report named ar-report-1 (produced by the job ARINS1), the
multi-record DJDE example lines are written to the report.
When CONTROL-D prints the report named ar-report-2, the DJDE line (JDE=JDEAR3) is
written to the report.
Sample member JDEPARMS is in the CONTROL-D DJDEPARM library.
Note Not every job has special DJDE parameters. Many jobs are printed using default
DJDE parameters. The library should only contain members for jobs with special
DJDE parameters (and not for other jobs).
When the Printers Control monitor is about to print a report for a user on a XEROX
printer, it searches for a member name with the same name as the job which produced the
report. It looks for the report name in the member and writes all the reports DJDE
parameters to the printer (via the spool). The DJDE prefix and offset should be specified in
macro CTDUDJP. The printer must be defined as XER in member CTDPARM. (See
Printers Definitions under Specify CONTROL-D Parameters in Section 5 of the IOA
Installation Guide for more information.)
Using OUTPARMS for Global Control of Printing Characteristics
The CONTROL-D Global Control of the Printing Characteristics option provides the ability to
override the default printing characteristics (specified at decollation time) for all (or some) of
the reports and banners to be printed by CONTROL-D. This option is for deferred printing as
well as for immediate printing. The following printing characteristics can be controlled:
BURST CHAR4 FCB FORMS PAGEDEF
CHAR1 CHARS FLASH MODIFY/MODIF TRC
CHAR2 CLASS FLASC OPTCD UCS
CHAR3 DEST FORMDEF OUTPUT UCSOP
CHAR1, CHAR2, CHAR3, and CHAR4 define specific character sets. CHARS defines the
character set referenced by CHAR1 and nullifies CHAR2, CHAR3, and CHAR4.
The value assigned to DEST is specified in the following format: node.rmtid
Setting parameter TRC (Table Reference Character) to YES produces the same result as
including parameter OPTCD=J in the JCL.
The CONTROL-D OUTPARMS library is used to implement global control of printing
characteristics. Each member in the OUTPARMS library refers to a job name (e.g., the
member name is the job name), or each member refers to a user ID. All member names must
either refer to job names or to user IDs; the two cannot be mixed. The members contain the
printing characteristics that will be used for the reports. In addition, a special member
named $$BANCHR is used for printing characteristics of banners (see steps 1 and 2 below).
The report name or mask (20 character maximum) to which the printing characteristics apply
is identified by a +++ prefix. See ACIFPARM Library below for a detailed explanation.
Different printing characteristics can be applied to a specific copy of a report by specifying the
copy number (format: COPY=nn from column 24) on the same line as the +++reportname.
Refer to the sample members in the OUTPARMS library for details on how to specify the
printing characteristics of the reports and banners produced by CONTROL-D.
Note Reports which are not specified in library OUTPARMS are printed using default
characteristics which are specified in the decollating mission or are taken from the
Permanent User file.
As an example of how this option can be used, the user can send all the reports that belong
to the accounting department to the local printer at the accounting department.
To control the printing characteristics of reports, add parameters OUTPARM and BANNER to
the banner exits (CTDX003 and CTDX014) in the IOA SECUDATA library. (See OUTPARM
Options in Section 10 of this guide for more information about these parameters.)
To control the printing characteristics of banners, follow these steps:
1. Sample member SAMPBANN in the OUTPARMS library describes how to specify the printing
characteristics that will be used for banners. All printing characteristics listed above in Using
OUTPARMS for Global Control of Printing Characteristics can be used.
Create member $$BANCHR in the OUTPARMS library. This member is used to specify
the printing characteristics that will be used for banners. The following is an example
of the contents of this member:
+++STD*
OUTPUT=BANNER1
In this example, all printing missions whose names start with STD will use OUTPUT
statement BANNER1 to determine the printing characteristics of the banners. If an
asterisk is specified instead of STD*, all printing missions will use OUTPUT statement
BANNER1 to determine the printing characteristics of banners.
2. Add OUTPUT DD statement(s) to the CONTROL-D Printers Control monitor procedure
(CTDPRINT). For each OUTPUT statement, add the appropriate printing parameters
(PAGEDEF, FORMDEF, etc.). For example, assume that member $$BANCHR contains
the following lines:
+++STD*
OUTPUT=BANNER1
+++STD?G
OUTPUT=BANNER2
OUTPUT statements BANNER1 and BANNER2 must be added to the CTDPRINT procedure.
3. If the site runs more than one Printers Control monitor (CTDPRIN2, etc.), these
OUTPUT statement(s) must be added each Printers Control monitor procedure.
Printing to a File
It is sometimes advantageous to direct output (a bundle) to a sequential file instead of to
the printer. This function is supported under CONTROL-D using a supplied user exit
(CTDX005) which is described in the following pages.
Activating the Facility
There are two recommended methods to route output to a sequential file. The first allocates
a new file using a dynamic filename; the second writes the output to an existing file.
1. Allocating a New File
Type SEQL-FILE in the CATEGORY field of the Printing Mission Definition screen. A
new dataset is created with the following dataset name format:
prefix.mission-name.Dddmmyy.Thhmmss
where prefix is the value assigned to CONTROL-D user exit CTDX005 parameter
PREFIX. (See Tailoring CTDX005 below.) If no value is assigned to this parameter,
the prefix defaults to CTDPRT.
Note If a dataset name is designated in the DSN parameter of exit CTDX005, this
dataset name overrides the default name. However, specifying a fixed name in the
exit is not recommended because the file will have to be deleted so it can be
reallocated when it is used again.
2. Using an Existing File
Type SEQL=filename in the CATEGORY field of the Printing Mission Definition screen.
filename is the name (maximum length: 15 characters) of an existing cataloged dataset.
The exit will append the output at the end of the existing file (DISP=MOD). This
method ignores the default parameters of exit CTDX005 and utilizes the characteristics
of the existing file, affording the user flexibility in specifying file characteristics. If the
file does not exist, a new file is created (DISP=NEW) utilizing the macro default
parameters (as in method above).
If parameter DEST is set to CTDPC or CTDPCPRT, the report is prepared for transfer to
the PC even if SEQL=filename is specified in the mission definition.
Tailoring Exit CTDX005
Edit member CTDX005 in the IOA SECUDATA library. The parameters listed and
described below relate to printing a file. Tailor them to site requirements.
CTDUX005 UNIT=SYSDA,
DSN=,
PREFIX=,
PRIVATE=NO,
VOLCNT=,
VOL1=XXXXXX,
VOL2=,
LABEL=,
SPACETY=,
PRIMARY=20,
SECOND=,
RLSE=,
DEFER=,
DEN=,
LRECL=133,
BLKSIZE=1330,
RECFM=FBA,
RULER=NO,
DUMMY=NO,
FOB=NO,
EXPDT=,
TRTCH=
Exit CTDX005 Parameters
UNIT Unit type e.g., TAPE, 3380 (default is SYSDA).
DSN Dataset name for the sequential file (used when the CATEGORY field of
the printing mission definition does not specify a dataset name in a
SEQL= string). See the note in method 1 (Allocating a New File) above.
PREFIX The default prefix of the sequential file name (the first qualifier in the
dataset name). Length: 1-7 characters.
PRIVATE Indicates whether the output will be written to a specified volume or a
scratch volume.
Y (Yes) The file will be written to a specified volume. Default.
N (No) The file will be written to a scratch volume.
VOLCNT Maximum number of tape volumes required for the output dataset
(used in conjunction with parameter PRIVATE=YES).
VOL1 First volume serial number.
VOL2 Second volume serial number. Optional.
LABEL Tape label type (SL, NL, NSL, AL, AUL, SUL, or BLP). Default: SL.
SPACETY Allocation type CYL or TRK. Default: TRK.
PRIMARY Primary space allocation. Default: 20.
SECOND Secondary space allocation. Default: 0.
RLSE Unused space release specification.
DEFER Deferred mounting specification.
DEN Tape density 1600/6250. Default: 6250.
LRECL Maximum logical record length. Default: 203.
BLKSIZE Maximum block size. Default: 4060.
RECFM Record format (the default is FB).
DUMMY Indicates whether the exit does or does not create a sequential file.
Y (Yes) The exit will not create a sequential file. It can be used for
other special processing.
N (No) The exit will be used to create a sequential file. Default.
FOB Indicates whether or not FOB printers are supported.
Y (Yes) FOB printers are supported.
N (No) (See Siemens Printer Support in the IOA Installation
guide.) FOB printers are not supported.
RULER Indicates whether or not to include a ruler.
Y (Yes) Write the report to a sequential file with the ruler.
N (No) Write the report to a sequential file without the ruler.
EXPDT=yyddd File expiration date.
TRTCH Indicates whether or not to compress the output.
COMP Use compression mode when writing to cartridges.
NOCOMP Write without compression.
Advanced ACIF Interface Facility
The CONTROL-D Advanced ACIF Interface facility automatically converts selected reports
to AFP Category 5 data stream (AFPDS) format, making them available for display with
the CONTROL-D/PC for Windows AFP Viewing component.
The converted reports can have a CONTROL-D/PC destination (i.e., CTDPC) or can be
stored on the mainframe and be accessed through Page On Demand.
AFPDS and ACIF
AFPDS (Advanced Function Presentation Data Stream) is an AFP Category 5 data stream
format which facilitates graphical WYSIWYG (What You See Is What You Get) viewing
and enables reports to be printed on AFP supported devices and platforms. AFPDS can
contain graphics, text, images and bar code objects. AFPDS also supports print resources
such as fonts, overlays, page segments, form definitions, and page definitions.
ACIF (AFP Conversion and Indexing Facility) is a utility that is supplied as a standard
component of PSF/MVS (Print Services Facility) version 2.1.1 and above.
ACIF Utility Benefits
The major benefits of the ACIF utility are:
Converting Line Mode Output to Page Mode Output
ACIF can convert line mode output to full AFP Category 5 data stream (AFPDS) page
mode output. AFPDS output can be displayed under CONTROL-D/PC for Windows with
the AFP Viewing component (technology from the IBM Printing Systems Company).
Indexing Reports
ACIF can optionally index reports according to character strings at specified locations
in a report. For example, ACIF can produce an index according to account number and
client name data contained in a customer statement. The index enables direct access to
specific report pages when displayed with CONTROL-D/PC for Windows.
Saving/Archiving External Resources
ACIF can create encapsulated AFPDS files that contain all the resources required for
AFP printing and presentation. These resources include FORMDEFs, electronic
overlays, page segments and fonts. The resources can be combined with the report and
index data and saved as a new report file (CDAM file). This file can be printed or
viewed at a later date in its original format, without regard to resource availability or
subsequent changes to the resource definitions. The file can also be transferred to other
sites or platforms for viewing and printing. If transferred to the PC environment or by
using Page On Demand, the output can be viewed online using CONTROL-D/PC for
Windows.
For more detailed information on ACIF, refer to the ACIF Application Programming
Guide (IBM publication number G544-3824) or subsequent documentation.
Making ACIF Accessible to CONTROL-D
It is recommended that ACIF program module APKACIF be located in the LPA (LINK
PACK AREA) or in an MVS LINKLIST library. Otherwise, all CONTROL-D Printers
Control monitor JCL procedures must be manually edited to concatenate the ACIF
distribution LOAD library to the STEPLIB DD statement. The default name of the ACIF
distribution LOAD library (as documented in the IBM installation instructions for PSF) is
PSF.ACIF.AAPKMOD1. See the CONTROL-D installation procedure for MVS and PSF
release prerequisites.
Activating the Advanced ACIF Interface
By specifying CDAM parameter ACIF=YES in a reports decollating mission definition,
CONTROL-D automatically calls ACIF during printing mission processing. ACIF converts
the report to AFPDS format. The report can then be transferred to CONTROL-D/PC for
Windows for display.
If parameter STORE of the printing mission definition is set to Y(Yes), the reports can be
accessed via Page On Demand. See Viewing AFP/CCIF Reports Under Page On Demand
later in this section. Otherwise, the reports are designated for PC file transfer.
ACIF Execution Parameters
ACIF requires parameters at execution time to control the processing of resources and
conversion of report data to AFPDS format. Many parameters specified to ACIF are the
same as printing parameters specified in JCL statements when printing a job. Some ACIF
parameters define the report index that ACIF can optionally compile. Other ACIF
parameters are used to specify the names of datasets which contain resource definition
members.
ACIF parameter RESTYPE can have the values FDEF, PSEG, OVLY, FONT, ALL, NONE,
or any combination of these which does not include NONE or ALL. We recommend
specifying RESTYPE=FDEF,PSEG,OVLY. This instructs ACIF to include all the resources
except fonts and improves the response time when viewing documents.
These parameters must be read by ACIF from a sequential file or a library member. While
some reports can share common parameter settings, most reports require settings that are
in some way different from those specified for other reports. Without the CONTROL-D
ACIF Interface facility, tracking hundreds or thousands of ACIF parameter files or
members becomes an impossible task.
ACIFPARM Library
For the CONTROL-D ACIF Interface facility, ACIF execution parameters are placed in the
CONTROL-D ACIFPARM library.
Unlike standard executions of ACIF, the CONTROL-D ACIF Interface facility allows the
specification of different parameters for different reports associated with the same job
name, the same printing mission name, and/or the same recipient (user ID) name, to be
kept in a single member of the CONTROL-D ACIFPARM library.
By default, ACIFPARM member names must be identical to a reports original job name.
However, as an optional enhancement, the ACIF Interface facility can be modified to
associate member names with a reports printing mission name or recipient name.
In each member, one or more sets of ACIF execution parameters can exist for different
reports. Each set of parameters must be preceded by a report name (repname) control
statement in the following format:
1 2 3 4 5 6 7
1234567890123456789012345678901234567890123456789012345678901234567890
+++repname unitname pind sind pres sres prep srep c
+++ Indication that this is a report name (repname) statement.
repname Name of the report (maximum length: 20 characters). The name must be
the same as the name of the report specified in parameter DO NAME of
the decollation mission that created the report.
The report name can be specified explicitly, or may contain the
following mask characters:
*
Any character, group of characters, or no character.
? Any single character.
Examples
ABC
*
The report name must begin with ABC (i.e., prefix).
*
D The report name must end with D (i.e., suffix).
ABC*D The report name must begin with the prefix ABC and end
with the suffix D. Any or no character(s) may be present
between the prefix and the suffix.
* All report names are selected.
A?B1 The report name must begin with a prefix of A and end
with a suffix of B1. One character of any value must be
present between the prefix and the suffix.
unitname Work unit name to be used by the CONTROL-D ACIF Interface facility
to allocate temporary ACIF index, resource and report data files.
pind Primary space allocation, in tracks, for the temporary ACIF index file.
sind Secondary space allocation, in tracks, for the temporary ACIF index file.
pres Primary space allocation, in tracks, for the temporary ACIF resource file.
sres Secondary space allocation, in tracks, for the temporary ACIF resource file.
prep Primary space allocation, in tracks, for the temporary ACIF report data file.
srep Secondary space allocation, in tracks, for the temporary ACIF report data file.
c JES output class to which ACIF prints its informational or error
message report. If left blank or specified as an asterisk (*), the default
MSGCLASS of the Printers Control monitor is assigned.
ACIF execution parameters must immediately follow the repname statement.
For detailed information on available ACIF execution parameters, refer to the ACIF
Application Programming Guide (IBM publication number G544-3824) or subsequent
documentation.
An ACIPARM library member can contain any number of repname and ACIF execution
parameter groups.
Example
Consider the following decollation mission parameters for two reports:
JOBNAME=jobname-memb
PRINT/CDAM PARMS=ACIF=YES
DO NAME=REPORT-NAME1
DO NAME=REPORT-NAME2
Member jobname-memb in the ACIFPARM library can contain the following:
+++REPORT-NAME1 ................
ACIF EXECUTION PARAMETER STATEMENTS
.
+++REPORT-NAME2 ................
ACIF EXECUTION PARAMETER STATEMENTS
Default member $$$$DFLT in the CONTROL-D ACIFPARM library contains default ACIF
execution parameters. These parameters control how reports with no specifically associated
member in the ACIFPARM library are processed by the ACIF Interface facility.
WYSIWYG Viewing of XEROX Reports
CONTROL-D/PC for Windows enables you to view/print XEROX reports in WYSIWYG
(What You See Is What You Get) format. Technology from Document Sciences Corporation
(CompuView Navigator) is used to enable the preparation and viewing/printing of the
XEROX reports. Currently supported XEROX formats include LCDS (i.e., DJDE) and
Metacode documents.
Overview
XEROX reports produced on the mainframe are processed (decollated) by CONTROL-D.
XEROX reports intended for WYSIWYG viewing/printing under CONTROL-D/PC for
Windows can either be transferred from the mainframe to the PC, or remain on the
mainframe and be accessed via Page On Demand. The value of CDAM parameter CCIF in
the decollation mission definition indicates that these reports require special processing
during printing mission processing.
A special file needs to be created that identifies all external XEROX printer resources.
Optionally, indexing criteria can also be included. This file must be created in advance on a
PC using DSC utility CCIF Manager and uploaded to the mainframe.
The DVS Printer Emulator is invoked during the printing mission to process XEROX
reports. The DVS Printer Emulator prepares a fully-contained CCIF file after retrieving
the relevant parameters from the CONTROL-D CCIFPARM and DJDEPARM libraries.
The fully contained CCIF files can remain on the mainframe to be accessed by
CONTROL-D/PC via Page On Demand, or can be downloaded to the PC. CONTROL-D/PC
identifies these reports as XEROX reports. When these reports are selected, they are
displayed/printed in WYSIWYG format by the DSC viewing technology.
Initial Preparations
Perform the following steps:
1. Obtain the password for using DVS and install it with job PASDVS from IOA PARM
library.
2. Review optional wishes WD2375, WD2376, WD2377, WD2378 and WD2383 in member
CTDDFLTS in the IOA SECUDATA library. Change the values, if required, by
referring to member UMIDFLTU in the IOA SECUDATA library.
Processing XEROX Reports
To process XEROX LCDS (i.e., DJDE) or Metacode reports by the DVS Printer Emulator, a
special file specifying all required resources and definitions needs to be prepared. This file
should be prepared on a PC using the DVS utility CCIF Manager. Once the file is
prepared, it needs to be transferred to the mainframe. Optionally, index definitions can be
prepared and included in this file. Some of the resources are extracted from the XEROX
printer, while others are prepared manually. The DVS Users Guide describes how to
prepare this file.
Parameters for the DVS Printer Emulator
The DVS Printer Emulator requires a number of parameters. Some of these parameters are
prepared by the CONTROL-D interface routine and some are prepared by the user.
User-defined parameters reside in CONTROL-D library CCIFPARM where they are coded
in a PARAMETER=VALUE form (one parameter per line). Member $$CCDFLT contains a
default set of parameters. Members with a corresponding print mission, user, or job name
(determined by optional wish WD2376) contain parameters specific for each report which
are used in addition to the parameters in member $$CCDFLT.
Activating the DVS Printer Emulator
If CDAM parameter CCIF= is specified in the PRINT/CDAM PARM of the report
decollating mission, CONTROL-D automatically invokes the Printer Emulator during the
printing mission. In addition, printing mission parameter STORE should be set to Y (Yes)
to access the reports via Page On Demand, or the reports should have a CONTROL-D/PC
destination (i.e., CTDPC). For more information, see Viewing AFP/CCIF Reports Under
Page On Demand later in this section.
Valid values for parameter CCIF:
YES The report file has already been processed by the DVS Printer Emulator
prior to decollation by CONTROL-D. Reports with CCIF=YES should have
the following DCB parameters: BLKSIZE=8192,RECFM=F or FB.
META The report file is in Metacode format and will be processed by the DVS
Printer Emulator during the print mission process.
LCDS The report file is in LCDS (i.e., DJDE) format and will be processed by the
DVS Printer Emulator during the print mission process.
CCIFPARM Library
The DVS parameters listed below are described in Chapter 8 of the DVS Users Guide.
These DVS Print Emulator parameters are mandatory and must be provided in each
member of CONTROL-D library CCIFPARM. They are not supplied in the default member.
RESFILE=
STARTJDL=
STARTJDE=
The following DVS Print Emulator parameters are generated automatically by
CONTROL-D:
CCIF1
CCIF2
CCIF3
LOGFILE
The following DVS Print Emulator parameters are in member $$CCDFLT and must not be changed:
RDBCCIF=1
DOCCCIF=2
RESCCIF=2
IDXCCIF=2
TMPCCIF=3
SYSCCIF=4
CCIF4=SYSCCIF
MAKEDOC=YES
CONTROL-D/V uses certain parameters without passing them to the Printer Emulator.
These parameters are:
RESFILE= name of resource file
WORK_SPACE= number of tracks for work files
WORK_UNIT= unit name for work files
LOG_CLASS= sysout class for Printer Emulator log file
CTVINDEXnn= name of a CCIF main index to be automatically converted to a level nn
CONTROL-V index during a STORE=Y printing mission. The usage of
parameter CTVINDEXnn is described below. See Section 4 of the
CONTROL-V User Manual for information about parameter STORE.
Parameter CTVINDEXnn
Each CTVINDEXnn parameter defines a CONTROL-V hierarchical index which
incorporates the values of a CCIF main index. The two digit number at the end of this
parameter indicates the CONTROL-V level of the target index. See Section 2 of the
CONTROL-V User Manual for more information about hierarchical index levels.
For example, six CCIF index names can be converted to CONTROL-V indexes based on the
following specifications:
CTVINDEX01=index-name1
These specifications will cause the CONTROL-V printing mission to build the two
hierarchical index structures illustrated below:
index-name1 index-name4
| | |
index-name2 index-name5 index-name6
|
index-name3
Every CCIF main index that is not specified in a CTVINDEXnn parameter is converted to
a CONTROL-V level 01 main index.
Page On Demand
Introduction
Page On Demand is a separately licensed add-on feature for CONTROL-D, CONTROL-V
and CONTROL-D/PC.
The Page On Demand client/server feature enables CONTROL-D/PC users to view reports
that reside on mainframe storage in real-time. Page On Demand is provided by
CONTROL-D, CONTROL-V, and CONTROL-D/PC in addition to the batch download
method.
Page On Demand eliminates the need to distribute large production reports over the
network to all potential online viewing users. The reports remain centrally stored and
users retrieve only the pages they require. Reports can be retrieved from the CONTROL-D
Active User file, the CONTROL-V Migrated User file, or both. Indexed reports can be
retrieved by index name and value. AFPDS/CCIF reports can be retrieved and displayed
using CONTROL-D/PC with the AFP viewer or the CompuView navigator.
Page On Demand Components
CONTROL-D/PC acts as a client component which communicates with the CONTROL-D
Application Server. The CONTROL-D/PC client and the CONTROL-D Application Server
communicate over SNA and TCP/IP networks.
The diagram below illustrates how Page On Demand is processed using the CONTROL-D
Application Server on the mainframe and CONTROL-D/PC as the client or a workstation.
MVS Mainframe
LU6.2
TCP/IP
IOA
Gateway
CONTROL-D/CONTROL-V
Application Server
CONTROL-D/PC
POD
POD
Communication
Support
CONTROL-D/PC Client
The workflow under CONTROL-D/PC Page On Demand is as follows:
A user who needs to view centrally archived reports logs in to CONTROL-D/PC.
The user is presented a list of reports that were downloaded in batch format according
to predefined criteria.
The user requests report retrieval from the central repository (i.e., in the mainframe
under CONTROL-D or CONTROL-V).
A communication process is established (via SNA using APPC or via TCP/IP protocol)
in the background between the PC and the MVS mainframe.
Logon to the mainframe is enabled using the Mainframe Logon User ID and MF
password fields in the Communication Setup dialog box in CONTROL-D/PC.
User exit IOAX016 and security module IOASE16 are provided to control access to the
mainframe through the IOA Gateway. See Section 10 of this guide and the IOA
Security Guide for more information.
Once logon to the mainframe is established, the CONTROL-D Application Server
processes all the requests of the CONTROL-D/PC client.
The user specifies selection criteria for the mainframe reports. Reports can be retrieved
from the CONTROL-D Active User file, the CONTROL-V Migrated User file, or both.
Indexed reports can be retrieved by index name and value.
An additional communication process is initialized between the PC and the mainframe.
User exit CTDX024 and security module CTDSE24 are provided to control access to
CONTROL-D/V mainframe reports. See Section 10 of this guide and see the IOA
Security Guide for more information.
In CONTROL-D/PC, the list of reports based on the selection criteria are listed in the
Report list. These criteria can be modified as required using the standard
CONTROL-D/PC filter.
The user then selects the required reports for viewing.
The retrieval request is transferred from CONTROL-D/PC to the CONTROL-D
Application Server on the mainframe. The CONTROL-D Application Server retrieves
the report pages and transfers them to CONTROL-D/PC for further processing.
CONTROL-D/PC Page On Demand uses a caching mechanism whereby pages that have
already been retrieved do not need to be retrieved again from the mainframe.
The Notification facility enables the user to create and update notes and annotations to
CONTROL-D/V reports. These notes are kept on the mainframe and are accessible via
the CONTROL-D/V Online Interface and via CONTROL-D/PC using Page On Demand.
AFPDS/CCIF reports can be retrieved and displayed using CONTROLD/PC with the
AFP viewer or the CompuView navigator.
For details about using this feature, refer to the documentation for CONTROL-D/PC for
Windows version 3.20 or above.
Viewing AFP/CCIF Reports Under Page On Demand
Desired portions of reports in AFPDS/CCIF format can be viewed and printed via Page On
Demand using CONTROL-D/PC (Version 3.21 and above) with the AFP Viewer or
CompuView Navigator. Such reports should be stored under CONTROL-D/V with their
original Print Resources. By using CONTROL-V indexes for AFP/CCIF reports, selected
pages can be downloaded to the PC. The preparations needed for viewing AFP/CCIF
reports under Page On Demand are described below.
Preparation for AFP Reports
For an AFP report to be viewed via Page On Demand, its report decollating mission
definition must include one of the following PRINT/CDAM PARM values:
Parameter=Value Explanation
APA=YES Specify this parameter if the original report is already converted to
AFPDS format. If the report does not contain ACIF index information,
it is recommended that CONTROL-V indexes be specified in the
decollation mission based on the report data.
Optional wish WD2949 should have APPLY=NO (default).
ACIF=YES Specify this parameter if the ACIF utility is called to convert
original reports to AFPDS format. It is recommended that
CONTROL-V indexes be specified in the decollation mission according
to the report data or that ACIF indexes be specified in the
CONTROL-D ACIFPARM library. This enables direct access to specific
report pages.
Preparation for CCIF Reports
For a CCIF report to be viewed via Page On Demand, its Report Decollating Mission
Definition must include the following PRINT/CDAM PARM values:
Parameter=Value Explanation
CCIF=YES Specify this parameter if the original report is already in CCIF format.
It is recommended that CCIF indexes be specified when the file is
created to enable direct access to specific report pages.
CCIF=LCDS Specify this parameter if the DVS Printer Emulator is called to
convert original reports from LCDS (i.e., DJDE) format to CCIF
format. It is recommended that CONTROL-V indexes be specified in
the decollation mission according to the report data or that CCIF
indexes be specified in the CONTROL-D CCIFPARM library. This
enables direct access to specific report pages.
Optional Wish WD1685
If CONTROL-V indexes are defined and the reports have embedded
DJDE lines, set APPLY=YES in optional wish WD1685.
Parameter DATAC defines the string that identifies the DJDE
statements. Parameter DATA defines the offset in the line of the
identifying string.
CCIF=META Specify this parameter if the DVS Printer Emulator is called to
convert a report from Metacode format to CCIF format. It is
recommended that CCIF indexes be specified in the CONTROL-D
CCIFPARM library to enable direct access to specific report pages.
Update EBCDIC ASCII Translation Tables
If CCIF reports have indexes, corresponding CONTROL-V indexes are created during
printing mission processing. CCIF indexes in ASCII format are automatically translated to
EBCDIC format for CONTROL-V.
Members TRNA2E and TRNE2A in the IOA PARM library are translation tables which can
be used to translate between ASCII and EBCDIC. If your site uses a non-standard
EBCDIC and/or ASCII character set, update these tables accordingly.
Parameter STORE of Printing Mission Definition
Parameter STORE in the printing Mission definition should be set to Y (Yes) to store the
AFPDS/CCIF report on the mainframe. In this case, a new report is created and its print
image is stored in a new CDAM file. New SYSDATA and User entry records are created in
the Active User file pointing to this new CDAM file. The new CDAM file is allocated
according to PC installation parameters PCBLKSZ, PCPREF, PCUNIT and PCVOLS. For
more information about parameter STORE, see Section 4 of the CONTROL-D User
Manual. If ACIF or CCIF indexes were specified for these reports and CONTROL-V is
installed, then corresponding CONTROL-V indexes will be created during printing mission
processing.
Starting Page On Demand on the Mainframe
Verify that the IOA Gateway has been successfully installed before trying to start Page On
Demand. (See Section 2 of the IOA Installation Guide for information about installing the
IOA Gateway.)
To start Page On Demand processing, first initialize the mainframe components.
CONTROL-D/PC users can then proceed to use Page On Demand.
Activate the IOA Gateway using following operator command:
S IOAGATE
It is possible to override ECAPARM communication parameters (COMM, APPLIDS, PORT)
with parameters specified in the EXEC PARM of IOAGATE. See the IOA Installation
Guide for information about ECAPARM parameters.
For example:
S IOAGATE,PRM=COMM=TCP,PORT=2525
The CONTROL-D Application Server (called CTDAS) is automatically activated by the IOA
Gateway.
To deactivate the IOA Gateway, specify operator command:
P IOAGATE
This deactivates the CONTROL-D Application Server (CTDAS) as well.
To activate CONTROL-D/PC, refer to the CONTROL-D/PC User Guide.
To display the list of all active users in the Application Server, specify operator command:
F IOAGATE,MODASID[=nn] [DISPLAY]
where nn is the specific address space ID of the server to which the modify command will
be submitted.
If no address space is specified, the modify command will be submitted to all the active
server address spaces.
When D[ISPLAY] is specified, a list of all active sessions will be displayed.
Displaying Active Application Server Address Spaces
Operator command F IOAGATE,STATUS can be issued in the IOAGATE address space at
any time to display all the active CONTROL-D Application Server address spaces and their
ASID numbers:
ECAG34I TYPE TID.ASID STATUS
ECAG35I CM 0001.01 READY
ECAG35I CD 0002.01 READY
ECAG35I CS 0003.01 READY
For information about activating the IOA Gateway, see Starting Page On Demand on the
Mainframe later in this section.
Reloading the Recipient Tree
See Loading the Recipient Tree earlier in this section for information on this topic.
To enable or disable debug messages, specify command:
F CTDAS,DEBUG=(nn[,-nn]...)
where nn enables and -nn disables debug message nn in the following table:
nn Debug Action
10 Write input/output request buffers to DD statement DADUMP.
11 Write mailbox messages to DD statement PRTDBG.
12 Write application program calls to DD statement PRTDBG.
17,18,19 Write online viewing messages to DD statement PRTDBG.
20,21,22 Write CDAM interface messages to DD statement PRTDBG.
23 Write Report list messages to DD statement PRTDBG.
32 Write mailbox internal trace to DD statement PRTDBG.
Mainframe PC File Transfer
When CONTROL-D/PC is installed, files can be transferred from the mainframe to the PC.
These transfers can be initiated from the mainframe (Push mode) and from the PC (Pull mode).
File transfers in Push mode can be implemented via KeyStroke Language KSL scripts or
by the File Transfer Monitor (see below). See the CONTROL-D/PC Administrator Guide for
information about performing file transfers with scripts.
File transfers in Pull mode can be implemented manually by the user via CONTROL-D/PC
commands and automatically by the CONTROL-D/PC server on the LAN. See the
CONTROL-D/PC User Guide for information about these methods.
At most sites, file transfers are made in Push mode. At some sites, Pull mode may be more
appropriate, especially if the LAN is not active 24 hours a day or PC users are often not
connected to the LAN.
File Transfer Monitor
The File Transfer monitor transfers CONTROL-D/PC packet files from the Mainframe to
the PC. It activates the file transfer in PUSH mode. The File Transfer monitor is a started
task activated by procedure CTDFTM which operates 24 hours a day.
File Transfer Protocols
The File Transfer monitor currently supports TCP/IP and XCOM 6.2 protocols. The default
protocol is TCP/IP. User exit CTDX023 can be used to designate the desired file transfer
protocol. Sample exit CTDX023C provides XCOM 6.2 support.
File Transfer Process
The File Transfer monitor examines the Active Transfer file and selects all entries with
status WAIT TRANSMISSION and TRANSMITTING. From these entries, it selects entries
whose IP address is defined in the CONTROL-D Recipient Tree.
The IP host name can be defined in the Recipient Tree as follows:
RECIPIENT USERNAM RECIPIENT LEVEL 55 PARENT MGT PARENT LEVEL
DESC DEVELOPMENT DEPARTMENT
DESC IP=host-name
where host-name is the logical name of the computer where the TCP/IP server is running.
The IP address can be defined in the Recipient Tree as follows:
RECIPIENT USERNAM RECIPIENT LEVEL 55 PARENT MGT PARENT LEVEL
DESC DEVELOPMENT DEPARTMENT
DESC IP=128.131.100.90:1948
where 128.131.100.90 is the physical IP address and 1948 is the port number.
Note For protocol XCOM6.2, the IP address is the LU name.
The process transfers the PIX and CDAM files for each entry.
The status of each entry in the Active Transfer file is changed to TRANSMITTED OK if the
corresponding files were transmitted successfully, or to WAIT TRANSMISSION if the files
were not transmitted successfully for some reason.
On the CONTROL-D/PC side, the TCP/IP server must be running and CONTROL-D/PC Import
must be running in Reports From Disk mode. We recommend using Reports From Disk in Global
Polling mode to import reports automatically. For each local area network, we recommend using
one CONTROL-D/PC TCP/IP Server and running CONTROL-D/PC Import at only one station.
Refer to the CONTROL-D/PC Administrator Guide for more information on this topic.
After the File Transfer monitor processes all entries in the Active Transfer file, it waits a
predefined period of time. The monitor then repeats the scanning process to find files
associated with new entries in the Active Transfer file and files which need to be
retransmitted for some reason.
Activating and Stopping the File Transfer Monitor
To activate the File Transfer monitor, issue operator command:
S CTDFTM
To stop the File Transfer monitor, issue operator command:
P CTDFTM
Reawakening the File Transfer Monitor
To reawaken the File Transfer monitor, issue operator command:
F CTDFTM,TRANSFER
This command causes the File Transfer monitor to immediately scan the Active Transfer
file even if the specified time interval has not elapsed.
Reloading the Recipient Tree
To reload the Recipient Tree, issue operator command:
F CTDFTM,LOADTREE
This command can be used to reload the Recipient Tree without stopping the File Transfer
monitor. See Loading the Recipient Tree earlier in this section for more information.
File Transfer Monitor Parameters
The following parameters affect the activity of the File Transfer monitor:
TASKS Maximum number of parallel transfer processes that can exist
concurrently. Default: 30. The actual number of concurrent transfer
processes will not exceed the number of unique IP addresses.
INTERVAL Time interval after which the Active Transfer file is searched for files
waiting to be transferred. The value is specified in minutes. Default: 10.
Example
S CTDFTM,TASKS=20,INTERVAL=15
This command limits the File Transfer monitor to a maximum of 20 concurrent transfer
processes and causes the monitor to be activated every 15 minutes.
CONTROL-D/Image
CONTROL-D/Image facilitates the viewing of scanned images of documents such as bank
checks, trade invoices, monthly bills, and applications for insurance.
If the appropriate password has been obtained and entered in member PASDIMG in the
IOA PARM library, CONTROL-D and CONTROL-V will support the decollation, indexing
and archiving of PC-originated image files and binary large object (BLOB) files. Archived
files can be retrieved via indexes for viewing using Page On Demand and CONTROL-D/PC
associated file support.
The PC files are packed by a PC utility (CTVPACK) into a flat control file whose first line
contains file identification and indexing information. The packed files are uploaded to the
mainframe and converted into CDAM files which can be migrated and retrieved by
CONTROL-V.
Sample Files
The following files are supplied with CONTROL-D/Image:
CDAMCRE.JOB Mainframe job which creates a CDAM file from the packed file that is
transferred in binary mode from the PC.
CTVPACK.BAT Batch file to be used for packing images before archiving on mainframe.
Each line of this file contains parameters which specify the type of files to
be packed, format of the file identification data, name of the control file,
and name of the output file to be created.
CTVPACK.EXE Packing program.
DECMIS.BIN Sample decollation mission. This mission can be transferred to the
mainframe in binary mode and used as a sample.
DECMIS.TXT Sample decollation mission (identical to DECMIS.BIN, but viewable).
LIST.TXT Sample control file that points to two GIF files (LOAN01 and LOAN02)
with extracted data.
LOAN01.GIF Sample GIF file #1 (scanned from a loan form).
LOAN02.GIF Sample GIF file #2 (scanned from a loan form).
PACKED.GIF File created by the packing program using the two sample GIF files and
the sample control file. This file will be transferred to the mainframe in
binary mode.
Implementing CONTROL-D/Image
Program CTVPACK.EXE must be installed on, or be accessible to, each PC which has
entities to be uploaded to the mainframe. Batch file CTVPACK.BAT contains a description
of the parameters used when invoking the packing program, CTVPACK.EXE.
The packing program can handle the following objects:
Images which can be scanned by almost any scanning system to produce uploadable PC
objects. The output of the scanning system must be a flat control file with one control
record for each object.
Word documents, Excel spreadsheets, etc. For these files, control records may need to
be produced manually
Each record in the control file (e.g., the sample LIST.TXT file) contains the name of the PC
object and indexing data extracted from the object. All the objects must be accessible to the
packing program.
Packing and Transferring CONTROL-D/Image Files
The packing program creates the control file with all the objects and their indexing data
packed together. The current version supports the packing of multiple objects if all the
objects are of the same type.
Manually transfer the packed file (created by the packing program) to the mainframe in
binary mode into a file with RECFM=FBA,LRECL=80.
Use a utility such as IEBGENER with the following JCL to convert the transferred file into
a CDAM file with BLOB=typ in the CDAM parameters:
//SYSUT2 DD SUBSYS=(R504,PREFIX=N50.NDS,BLOB=GIF),
// DCB=(BLKSIZE=8000,LRECL=80,RECFM=FBA)
Decollating and Indexing CONTROL-D/Image Files
Decollate the CDAM file. Use DO INDEX to index the report and use the control line
created by the packing program for index value extraction. Use DO MIGRATE to control
migration of the CDAM file. The sample report decollation mission (in file DECMIS.TXT) is
illustrated below.
When planning the decollation mission definition, the locations of values to be extracted
(name, index values, etc.) are based on the BLOB description line that is added by the
CTVPACK program. In the current version of the packing program, the actual key
specified in the control file begins in column 33.
In the sample report decollating mission below, character string KEY is used as a mask in
columns 29-31 to ensure that valid index values are extracted by the DO INDEX
statement.
CATEGORY DEMOLOAN JOBNAME N50LOAN GENERIC MONITOR
===========================================================================
DEF COPIES LVL USER DEST MAX COPIES
===========================================================================
ON DSN = PREFIX=N50.GIF
PRT COPIES LVL USER DEST MAX COPIES
PRINT/CDAM PARMS =
WHEN LINE - COL - PRINT REF NEXT PAGE CONTID AND/OR
STRING =
DO USER = DEMO LVL LINE COL - S A T
SYNONYM = CONCAT =
DO INDEX = ACCOUNT LINE 001 COL 043 - 048 R
MASK = KEY LINE 001 - 001 COL 029 - 031 REC N
SUBINDEX = LVL LINE COL -
MASK = LINE - COL - REC
===========================================================================
INDEX LEVEL DISPLAY
ACCOUNT
===========================================================================
DO INDEX = AMOUNT LINE 001 COL 050 - 054 R
02 SUBINDEX = ACCOUNT LVL 02 LINE 001 COL 043 - 048
===========================================================================
INDEX LEVEL DISPLAY
AMOUNT / ACCOUNT
===========================================================================
DO INDEX = PERIOD LINE 001 COL 056 - 057 R
===========================================================================
INDEX LEVEL DISPLAY
PERIOD / ACCOUNT
===========================================================================
DO INDEX = EFFECTIVE_DATE LINE 001 COL 059 - 066 R
===========================================================================
INDEX LEVEL DISPLAY
EFFECTIVE_DATE / ACCOUNT
===========================================================================
DO NAME = LOAN-ARCHIVE-DEMO LINE COL -
DO
STRING =
Viewing CONTROL-D/Image Files
Objects can be viewed in the following ways:
Using CONTROL-D/PC Page On Demand (Release 3.26 and above).
In the Index/Value Selection panel, specify or select the index name and value(s)
combination required to retrieve the desired image or image list. Select the View option
for the desired image(s) to view the image(s). Index navigation and image viewing
follows the same conventions that are used for viewing standard reports and
documents.
Using CONTROL-D/Web Access.
CONTROL-D/Web Access facilitates navigation and viewing of both images
and standard reports and documents in the CONTROL-D/V Repository from
a users standard web browser via Internet, Intranet or Extranet
connections. (Extranets connect external, authorized users to resources on a protected
network.)
Using a POD-API application written in C, C++ or Visual Basic.
POD-API facilitates access to both CONTROL-D/Image objects and standard reports
and documents in the CONTROL-D/V Repository by in-house developed and 3rd party
applications.
Backup Mission Management
Overview
The topics listed below are explained on the following pages:
Backup According to Scheduling Dates
Report Decollating and Backup Mission Dependency
Backup Mission Workflow
Exception Handling
Changing the Backup Mission Retention Period
Backup According to Scheduling Dates
It is possible to organize backup missions so that each days backup management (i.e., the
backup workflow) is the same. The simplest method is to specify DAYS=ALL in the Basic
Scheduling parameters of all backup missions. Once a day, when the New Day procedure is
invoked, all backup missions scheduled for the next 24 hours are placed in the Active
Missions file.
This backup organization does not maximize the capabilities of CONTROL-D. You can
organize the backup order in different ways for different days (e.g., weekdays, weekends, end
of the month, holidays).
Using CONTROL-D, it is possible to define several copies of the same backup mission. Each
copy is an independent definition of the backup mission and can have different scheduling
criteria, different runtime criteria, etc.
Example
Backup mission BKP0031D will start not later than 06:00 on every workday, will start not
later than 05:00 at the end of the month, and will not be scheduled for holidays. Since
there is no limit to the number of backup missions which can be defined, the user can
organize the backup process to optimally suit every production day of the year.
Report Decollating and Backup Mission Dependency
We recommend that the backup process (by CONTROL-D backup missions) depend upon
the successful decollation of reports. The dependency can be established using a
prerequisite condition. Parameter OUT of the report decollating mission should specify a
prerequisite condition that will be referenced by parameter IN of the backup mission.
Using this method, backup occurs only when all the reports which should be backed up
together have been decollated.
It is possible to define different report-backup dependencies for different scheduling dates
(e.g., regular dates vs. end of the month). This can be done, as described above, by using
multiple copies of the same backup mission, each one distinguished by different basic
scheduling criteria and different runtime scheduling criteria (prerequisite conditions, time,
priority, etc.).
Backup Mission Workflow
The backup mission workflow of CONTROL-D is shown below. It illustrates the stages involved
from initially scheduling the backup mission through backing up the CDAM datasets.
The workflow of a backup mission is:
The Active User Report List file is scanned by the CONTROL-D monitor for all reports
requiring backup by the specified backup mission name. (This is a fast scan, not a scan
of the entire file.) Reports which have been previously backed up, or have been restored
from a backup, are not backed up a second time. The result of this process is a list of
dataset names to be backed up.
The CONTROL-D monitor reads a skeleton job from the library referenced by DD
statement DADSKL of the CONTROL-D monitor. The member name must be the same
as the backup mission name (e.g., BKP0031D).
Note Since the same library is used for printing, backup, restore and migration mission
skeletons, the name of each mission must be unique.
When you define a new backup mission, you must create a new skeleton job with the same
name.
The member must contain the following parameters which are interpreted by the
CONTROL-D monitor:
%DSNS% Resolves into a list of all the dataset names that have to be backed
up. This list is in DF/DSS, DF/HSM, FDR, DMS/OS, ASM2 or ARCS
format depending on installation parameters. Mandatory.
%TIMESTMP% Resolves into a timestamp, which is later used by CONTROL-D for
internal purposes. Mandatory.
%MISSNAME% Resolves into the backup mission name. Mandatory.
%COND% condnm When the preparation of the backup job is completed, the specified
condition name is added to the IOA Conditions/Resources file. The
ODAT of the condition is the original scheduling date of the backup
mission. This can be used for triggering the backup job under
CONTROL-M. Optional.
When CONTROL-D finishes preparing the member for submission, control passes to
exit CTDX010. This exit can modify the contents of the submitted job by adding,
deleting or modifying the JCL. For example, the dataset names list can have a format
different from the DF/DSS, DF/HSM, FDR, DMS/OS, ASM2 or ARCS format. The exit
can return the following return codes:
0 Submit the job.
4 Do not submit the job (normally used when the submission is to be executed by a
production control system).
The member is written to the library referenced by DD statement DADJOB of the
CONTROL-D monitor with a name identical to the name of the backup mission.
Therefore, this library must be different from the library referenced by DD statement
DADSKL. The return code from the user exit determines if the job is or is not
submitted. If CONTROL-M is installed, submission of the job can be triggered by the
%COND% statement. (The advantage of this method is that overall production tape
workload and tape usage priority are taken into consideration when submitting the
backup job.)
The original member supplied contains two steps:
The DF/DSS, DF/HSM, FDR, DMS/OS, ASM2 or ARCS backup utility.
A program which analyzes the output of the backup process and updates
CONTROL-D files with the results (e.g., the tape numbers used).
When the job finishes executing, the CONTROL-D monitor is notified (by the second step)
and the backup missions post-processing parameters (OUT and SHOUT) are processed.
Exception Handling
If the backup job abends in the first step (BACKUP), the status of the backup mission is
changed to ENDED-NOTOK. When this happens, check why the abend occurred and
correct the problem. After the problem has been corrected, rerun the backup mission from
the Active Missions file.
If the backup job abends during the second step (ANALYZE), the status of the backup
mission remains BACKUP IN PROCESS. When this happens, reset the backup mission
status to ENDED via job BKPRESET in the CONTROL-D JCL library.
If the backup mission ended NOTOK because one or more CDAM files were not backed up
successfully, reorder the mission to back up only the CDAM files which were not backed up
successfully during the previous run. Rerunning the same mission (without reordering it)
reprocesses all CDAM files of the previous run including files which were successfully
backed up.
Changing the Backup Mission Retention Period
Backup missions use the following parameters to specify the retention period of a backed
up CDAM file:
# OF DAYS TO KEEP Specifies how many days should elapse from the backup
date to the expiration date.
# OF GENERATIONS TO KEEP Specifies how many subsequent generations (executions) of
the backup mission should be produced until the
generation expires.
You can specify either one (but not both) of these parameters in the backup mission
definition screen. If you need to change from the # OF GENERATIONS TO KEEP method
to the # OF DAYS TO KEEP method, use a new backup mission (i.e., statement DO
BACKUP in the decollation mission definition should refer to a new backup mission name).
If the same backup mission is used, an error message will appear and the backup mission
will end NOTOK.
Backup Mission Considerations
The organization of backup missions is performed according to the backup cycles used at
the site. A backup mission should be defined for each backup cycle.
Example
BCK0007D Backup for one week
BCK0014D Backup for two weeks
BCK0031D Backup for one month
BCK0091D Backup for three months
BCK0365D Backup for one year
Each backup mission archives on the same tape or cartridge all the reports assigned to it.
The backup mission for archiving a report is selected in the job decollating parameters.
Example
WHEN LINE 001 - 001 COL 020 - 080
STRING ACCOUNTS RECEIVABLE - DAILY
DO ..
DO BACKUP = BCK0031D
WHEN LINE 001 - 001 COL 020 - 080
STRING ACCOUNTS RECEIVABLE - BILLS
DO ..
DO BACKUP = BCK0007D
Different reports within the same job can be backed up for different retention periods.
The name of the backup mission is descriptive. The actual retention period is determined
by parameter # OF DAYS/GENERATIONS TO KEEP in the backup mission. For example,
backup mission BCK0031D can actually keep the reports on the tape(s) for 35 days.
Backup missions can be triggered based on:
Time (example: 0400 a.m.)
Automatic dependencies when one or more specified jobs have been decollated.
Manual dependencies the operator can decide when to start the backup process.
A combination of the above.
Restore Mission Management
Overview
Restoring According to Scheduling Dates
Restore Mission Workflow
Exception Handling
Restoring with the Original Backup Utility
Restoring According to Scheduling Dates
It is possible to organize restore missions so that each days restore management (i.e., the
restore workflow) is the same. The simplest method is to specify DAYS=ALL in the Basic
Scheduling parameters of all restore missions. Once a day, when the New Day procedure is
invoked, all restore missions scheduled for the next 24 hours are placed on the Active
Missions file.
This restore organization does not maximize the capabilities of CONTROL-D. You can
organize the restore order in different ways for different days (e.g., weekdays, weekends, end
of the month, holidays).
Using CONTROL-D, it is possible to define several copies of the same restore mission. Each
copy is an independent definition of the restore mission and can have different scheduling
criteria, different runtime criteria, etc.
For example, the RSTNOON restore mission will start not later than 12:00 on every
workday, will start not later than 11:00 at the end of the week, and will not be scheduled
for holidays.
Since there is no limit to the number of restore missions which can be defined, the user can
organize the restore process to optimally suit every production day of the year.
Restore Mission Workflow
The restore mission workflow of CONTROL-D is shown below. It shows the stages involved
from initially scheduling the restore mission through restoring the CDAM datasets.
The workflow of a restore mission is:
Restore is requested by online users via option R of the History Report List screen. The
History User Report List file is scanned by the CONTROL-D monitor for all reports
which need to be restored by the specified restore mission name. (This is a fast scan,
not a scan of the entire file.) The result of this process is a list of dataset names to be
restored.
The CONTROL-D monitor reads a skeleton job from the library referenced by DD
statement DADSKL of the CONTROL-D monitor. The member name must be the same
as the restore mission name (e.g., RST0060M).
Note Since the same library is used for printing, migration, backup and restore mission
skeletons, the names of the missions must be unique.
When you define a new restore mission, you must create a new skeleton job with the
same name.
The member must contain certain parameters which are interpreted by the
CONTROL-D monitor. The parameters are:
%REPEAT% %ENDREPEAT%
Beginning/end of a repeating step. Mandatory. Since outputs
can be backed up on many volumes, it is sometimes necessary
(with certain archiving products) to perform the restore by more
than one step. The definition of this repeating step is found
between the %REPEAT% and %ENDREPEAT% statements (not
applicable to DF/HSM, DMS/OS, ASM2 or ARCS formats).
%DSNS% Resolves into a list of all the dataset names that have to be
restored. This list is in DF/DSS, DF/HSM, FDR, DMS/OS, ASM2,
or ARCS format, depending on installation parameters. Mandatory.
%VOLUMES% Resolves into the volume serial numbers of the tapes taking part in
the restore. Mandatory. (Applies to DF/DSS or FDR formats.)
%TIMESTMP% Resolves into a timestamp which is later used by CONTROL-D
for internal purposes. Mandatory.
%MISSNAME% Resolves into the restore mission name. Mandatory.
%COND% cond-name When the preparation of the restore job has been completed, the
specified condition name is added to the IOA
Conditions/Resources file. The ODAT of the condition is identical
to the original scheduling date of the restore mission. This can be
used for triggering the restore job under CONTROL-M. Optional.
%BKPUTIL% Resolves into the backup utility name. Optional.
The value of this parameter is determined in the following manner:
The skeleton member is searched for the BKPUTIL
assignment (e.g., BKPUTIL=HSM). The value assigned for
this parameter is referred to as the backup utility name.
If BKPUTIL is not set in the skeleton member, the value is
taken from installation parameter BKPUTIL in member
CTDPARM in the IOA INSTCTD library.
Note In all the sample skeleton members provided in the
CONTROL-D SKL library, the appropriate backup utility
name is already assigned to parameter BKPUTIL.
See Restoring with the Original Backup Utility below for
details about how to use this parameter.
When CONTROL-D finishes preparing the member for submission, control is passed to
user exit CTDX011. This exit can modify the contents of the submitted job by adding,
deleting or modifying the JCL. For example, the dataset names list can have a format
different from the DF/DSS, DF/HSM, FDR, DMS/OS, ASM2 or ARCS format. The exit
can return the following return codes:
0 Submit the job.
4 Do not submit the job (normally used when the submission is to be executed by a
production control system).
The member is written to the library referenced by DD statement DADJOB of the
CONTROL-D monitor, with a name identical to the name of the restore mission.
Therefore, this library must be different from the library referenced by DD statement
DADSKL. Depending on the return codes from the user exit, the job is, or is not,
submitted. If CONTROL-M is installed, submission of the job can be triggered by the
%COND% statement. (The advantage is that overall production tape workload and tape
usage priority are taken into consideration when submitting the restore job.)
The original member supplied is divided into:
The DF/DSS, DF/HSM, FDR, DMS/OS, ASM2 or ARCS restore utility. A step is created for
each group of tapes (VOLSERs) containing reports to be restored (not with all products).
A program which analyzes the output of the restore process and updates
CONTROL-D with the results. This step copies the restored user/report entries from
the History User Report List file to the Active User Report List file and indicates
that a restore has been performed.
If a CDAM file to be restored already exists on disk, that file is not restored to disk. If
all the files to be restored already exist on disk, the restore mission creates a restore job
which performs only the ANALYZE step. This step will copy user and sysdata records
from the History User Report List file to the Active User file and will end OK.
When the job finishes executing, the CONTROL-D monitor is notified (by the second step)
and the restore missions post-processing parameters (OUT and SHOUT) are processed.
Exception Handling
If the restore job abends in one of the first steps (such as the RESTORE step), rerun the
job (enter the CONTROL-D JCL library and submit it or, if scheduled under CONTROL-M,
use the CONTROL-M rerun option without restart).
If the restore job abends in the last step (ANALYZE), rerun the job from the last step (i.e.,
submit it again without restart).
If the last step abends, the status of the restore mission remains RESTORE IN PROCESS.
To reset the restore mission status to ENDED, run job RSTRESET (which resets the
restore mission) from the CONTROL-D JOB library. In addition, perform all the restore
requests again (using option R in the History User Report List of screen U). The restore
mission finishes with ENDED NOTOK status.
Restoring With the Original Backup Utility
Sites which are moving from one backup utility to another (e.g., from FDR to DF/HSM)
might end up having CDAM files which are backed up by different backup utilities. Each of
the backed up CDAM files should be restored using the original backup utility.
To restore the CDAM file with the appropriate backup utility, the restore mission name
should point to a skeleton member of the original backup utility. Parameter BKPUTIL in
the skeleton member should be set to the original backup utility name.
Example
//* BKPUTIL=FDRCAT
This statement should appear in the skeleton member to use the FDR backup utility
regardless of the value specified for BKPUTIL in member CTDPARM in the IOA INSTCTD
library.
Note The BKPUTIL value in the backup skeleton overrides the value of installation
parameter BKPUTIL in member CTDPARM in the IOA INSTCTD library.
Migration Mission Management (CONTROL-V Only)
Overview
Migrating Reports
Multi-stage Migration
Migration Mission Report Correspondence
MIG and MSM Migration Types
Scheduling Criteria
Primary and Secondary Migration
Migration Mission Skeleton Jobs
Target Media Types
Migration to Cartridge (CART)
Migration to ROSs/OSS
Emulation Mode)
Migration to FileTek Storage Machine
Migration to OAM
Naming Conventions
CDAM Datasets
Indexes
Migration Mission Workflow
Example: multi-stage Migration Mission Workflow
Exception Handling
Migrating Reports
Migration missions control the migration of Compressed Dataset Access Method (CDAM)
reports and their indexes from one media (optical disk, cartridge, DASD, etc.) to another.
They enable you to move data between fast-access higher-cost media and slower-access
lower-cost media according to need. All user-defined parameters are specified in the
Migration Mission Definition screen.
Information about defining indexes and migration missions is contained in Section 3 of the
CONTROL-V User Manual. Information about CDAM files and migrated CDAM datasets is
contained in Section 5 of the CONTROL-V User Manual.
Multi-stage Migration
A maximum of 10 migration stages can be defined as a migration path in each migration
mission. Single-stage migration can be defined for reports whose re-migration is not
required.
Each migration stage specifies the target media, the age of the report in days when
migration should occur, the cyclic time interval in days between refresh operations (when
the report migrates to a new physical media of the same type), the prefix value (for
migration to DASD and ROSs/OSS), and the FSET and VSET values (for migration to
FileTek).
Migration Mission Report Correspondence
The migration mission name is specified in the DO MIGRATE statement of a reports
decollation mission. A report retains its original migration mission name for its entire
lifetime. Each migration mission defines all stages in the migration path for all reports
whose decollation mission contains a DO MIGRATE statement specifying that migration
missions name.
The user can modify the migration path and other parameters in a migration mission at any
time. When a migration mission is modified, the migration of all reports whose decollation
mission specifies that migration missions name will be affected by the modification.
The retention period of each report is stored with the report. If the retention period of all
reports previously migrated by a migration mission must be changed uniformly, modify
parameter RETENTION DAYS in that migration mission and set parameter FORCE to Y
(Yes). This causes $SYSDATA records created by previous runs of this migration mission to
be updated with the new retention period during the next run of the modified migration
mission. If parameter FORCE is not set to Y, only subsequently migrated reports will
receive the new retention period.
If the retention period of the previously migrated reports must be selectively changed, use
utility CTDUPBKP.
Only one migration mission name should be specified for each report. If more than one
migration mission is specified in the decollation mission definition, a reports files are
migrated by that migration mission whose name is first encountered in the decollation
process. Warning messages are generated if all CDAM files associated with a report do not
have the same migration mission name.
If the decollation process detects more than one migration mission name, a warning is
issued to the IOA Log file and the decollation process terminates with a status of ENDED
OK WITH WARNINGS. If $SYSDATA records created by different decollation missions
for the same report contain more than one migration mission name, a warning is issued by
utility CTDDELRP.
MIG and MSM Migration Types
Initial migration from DASD by the first stage (stage 01) in a migration path is called
MIG migration. All subsequent migrations in the migration path are called MSM
(multi-stage) migration. The migration type (MIG or MSM) is displayed in the TYP field of
the Active Missions screen.
Scheduling Criteria
Separate scheduling criteria are specified for the two migration types:
MIG scheduling criteria are specified under STAGE 01 SCHEDULING PARAMETERS
in the Migration Mission Definition screen. At most sites, stage 01 migration is
scheduled frequently, perhaps daily, to remove reports from scarce DASD resources as
soon as possible.
MSM scheduling criteria are specified under MIGRATION PATH SCHEDULING
PARAMETERS in the Migration Mission Definition screen. At most sites, subsequent
stages in the migration path are scheduled less frequently, perhaps every weekend, to
minimize the extent to which running migration jobs impacts production jobs.
Stage 01 (MIG type) migrations should be scheduled more frequently to minimize DASD
utilization. Other (MSM type) migrations should be scheduled less frequently to minimize
the usage of computer resources when such resources are required for other jobs.
Primary and Secondary Migration
Each migration stage can contain a primary migration specification and, optionally, a
secondary migration specification. Secondary migration produces a copy of primary
migration reports (usually on less expensive media) that can be accessed if primary
migration reports become damaged.
If SECONDARY MEDIA is specified in a migration mission, the migration mission submits
two migration jobs:
The primary migration job uses the migration skeleton (see Migration Mission
Skeleton Jobs below) whose name is identical to the migration mission name.
The secondary migration job uses the migration skeleton whose name is specified in
parameter SECONDARY SKELETON. This parameter defaults to the name of the
primary migration mission, modified by changing the 3rd character to C (or to D if it
had been C).
Only files designated as primary migration files can be accessed for viewing. If primary
migration files are not usable for any reason, utility CTDUPBKP can be run to switch the
primary and secondary migration designations. After running this utility, the secondary
migration files are accessed for viewing. This utility can be run again to switch back to
viewing primary migration files. The next Multi-Stage Migration mission will
automatically recreate the primary migration files on the (originally) defined media.
Information about retention and about the current primary migration media can be
displayed in $SYSDATA long format by using option A (Additional Info) in the Migrated
Report list. Information about secondary migration media can be retrieved by running
utility CTDUPBKP with parameter SIMULATE set to YES. See Section 9 of this guide for
utility CTDUPBKP documentation.
Secondary migration files are deleted when the next secondary migration is completed and
at the end of the retention period. Refresh operations are performed independently for
primary and secondary media.
Migration Mission Skeleton Jobs
Every primary and secondary migration mission must have its own skeleton job in a
separate member of the CONTROL-D SKL library. The name of the member containing the
skeleton job for a primary migration mission must be identical to the name of the
migration mission. The name of the member containing the skeleton job for the secondary
migration mission can be specified in parameter SECONDARY SKELETON in the
migration mission.
In the CONTROL-D SKL library, member MIGLIM contains a skeleton job for a primary
migration mission. Member MICLIM contains an almost identical skeleton job for a
secondary migration mission. These skeleton jobs can be used as is (for migration
missions MIGLIM and MICLIM) and can be duplicated (and modified) as required for other
migration missions. It is recommended that you use the same JOBNAME in both skeletons
of the same migration mission to ensure that the primary and secondary migration
missions do not run concurrently.
Note Because the same library is used for printing, backup, restore and migration mission
skeletons, the names of all missions must be unique.
When defining a new migration mission, create a skeleton job member with the same
name. To implement secondary migration, create a skeleton job member with the name in
parameter SECONDARY SKELETON. The skeleton job format is identical for migration to
all media types.
Skeleton jobs contain the parameters listed below. These parameters are interpreted
(resolved) by the CONTROL-D/V monitor. All parameters (except %COND%) are
mandatory and must remain exactly as written in the MIGLIM and MICLIM skeleton jobs.
%KODAK% / %ENDKODAK%
Labels which enclose a part of the skeleton job that is placed in the
migration job only when the target media is ROSs/OSS.
%REPEAT% / %ENDREPEAT%
Labels which enclose a part of the skeleton job that is repeated for
every target media by CONTROL-D/V.
%TARMEDIA% Name of the target media to which files are migrated. The value is
specified in the migration mission definition.
%MIGPREF% Prefix of the volume or platter to which files are migrated. If a value is
not specified in the migration mission definition, NOCHECK appears
in the job and the prefix is not checked. Optional.
%LEVEL% For a migration mission with both primary and secondary migration,
resolves to PRIMARY and SECONDARY in the appropriate jobs. For
only primary migration, resolves to PRIMARY in step MIG and
PRIMONLY in step ANALYZE. For only secondary migration, resolves
to SECONDARY in step MIG and SECREFRESH in step ANALYZE.
%MISSNAME% Migration mission name.
%TIMESTMP% Timestamp which is later used by CONTROL-V for internal purposes.
%VSET% / %FSET%
VSET (volume set) and FSET (file set) parameters specified in the
migration mission definition. These parameters are used only for
migration to FileTek. For other target media, these parameters and
DD statement FTKIN are not included in the migration job.
%DSNS% List of datasets to be migrated by this mission. The CONTROL-D/V
monitor obtains these values by scanning $SYSDATA records.
%COND% condition Prerequisite condition to be added to the IOA Conditions/Resources
file when preparation of the migration job is completed. The condition
is specified in parameter OUT of the migration mission. The ODAT of
the condition is identical to the original scheduling date of the
migration mission. This mechanism can be used for triggering the
migration job under CONTROL-M. Optional.
Sample Skeleton Job
Skeleton job MIGLIM for primary migration is listed below. Skeleton job MICLIM for secondary
migration is identical except the DSN suffix in DD statement SYSPRINT is S instead of P.
The labels %KODAK% and %ENDKODAK% enclose a part of the skeleton job that is
placed in the migration job only when the target media is ROSs/OSS. (When the target
media is not ROSs/OSS, nothing is inserted between these labels.)
//I514INMG JOB ,IOA514,MSGCLASS=X,CLASS=A,
// PERFORM=1
//*
%KODAK%
%ENDKODAK%
%REPEAT%
//MIGRAT EXEC PGM=CTVMIG,PARM=%TARMEDIA%,%MIGPREF%,%LEVEL%
//STEPLIB DD DISP=SHR,DSN=IOAP.V514.LOAD
//PRTDBG DD DUMMY
//ERRLOG DD SYSOUT=*,HOLD=YES
//DALOG DD DISP=SHR,DSN=IOAP.V514.LOG
//DAMIG DD DISP=SHR,
// DSN=CTDP.V514.MIG.E000
//DAMIGI DD DISP=SHR,
// DSN=CTDP.V514.MIGI.E000
//SYSPRINT DD DSN=CTVP.V514.%MISSNAME%.MIGLIST.P,
// DISP=(MOD,PASS,CATLG),SPACE=(CYL,(1,1)),UNIT=SYSALLDA
//SORTOUT DD SYSOUT=*,HOLD=YES
//SORTWK01 DD UNIT=SYSALLDA,SPACE=(CYL,(20,40))
//SYSOUT DD SYSOUT=*,HOLD=YES
//FTKIN DD *
VSET=%VSET%
FSET=%FSET%
//SYSIN DD *
%DSNS%
/*
%ENDREPEAT%
//*******************************************************************
//* CONTROL-D ANALYZE STEP *
//* ---------------------- *
//*******************************************************************
//ANALYZE EXEC PGM=CTDBKC,COND=EVEN,REGION=4096K,
// PARM=%TIMESTMP%,%MISSNAME%
//STEPLIB DD DSN=IOAP.V514.TLOAD,DISP=SHR
// DD DSN=IOAP.V514.LOAD,DISP=SHR
//TAPE DD DUMMY
//SYSIN DD DSN=CTVP.V514.%MISSNAME%.MIGLIST.P,
// DISP=(OLD,DELETE,CATLG)
//DAAMF DD DISP=SHR,
// DSN=CTDP.V514.AMF
//DAAMF1 DD DISP=SHR,
// DSN=CTDP.V514.AMF
//DALOG DD DISP=SHR,
// DSN=IOAP.V514.LOG
//DAACT DD DISP=SHR,
// DSN=CTDP.V514.ACT.E000
//DAACTI DD DISP=SHR,
// DSN=CTDP.V514.ACTI.E000
//DAMIG DD DISP=SHR,
// DSN=CTDP.V514.MIG.E000
//DAMIGI DD DISP=SHR,
// DSN=CTDP.V514.MIGI.E000
//SYSPRINT DD SYSOUT=*,HOLD=YES
//SYSABEND DD SYSOUT=*,HOLD=YES
//PRTDBG DD SYSOUT=*,HOLD=YES
//
Target Media Types
The following migration target media types are supported:
CART 3480/3490/3490E/3590 Tape Cartridge
DASD Disks (3380, 3390, Fat-DASD 3390-9, IBM 3995 Optical Library Dataserver
in 3390 emulation mode, etc.)
OSS DataWare/ROSs/OSS or compatible
FTK FileTek Storage Machine (SM)
OAM IBMs Object Access Method
Each site can utilize any or all of the supported types of migration target media.
Media-specific parameters (NAME, TYPE, DSNPREF, UNITNAME, DEVADDR, etc.) must
be defined in member IOASPARM in library IOA INSTCTV for each target media type
(including DASD) that is used. See Installing CONTROL-V in the IOA Installation Guide
for details about these parameters.
Note ROSs/OSS media, which includes DataWare ROSs and KODAK OSS, was called
KODAK OPTISTAR prior to IOA release 5.1.4.
See Device Definition and Usage later in this section for more information about the
supported media types.
Migration to Cartridge (CART)
When migrating to media type CART, the migration mission places as many files as
possible on the same volume. Any space remaining will be used by a subsequent run of the
same migration mission. When insufficient space remains, a scratch volume is used.
Before writing each file, the migration process determines if the file will fit on the volume
(based on the CART media capacity parameter CARTLEN specified in member
IOASPARM). If the file will not fit, a new scratch volume is used. If the file is larger than
the specified volume capacity, the migration process uses a new volume for that file and
then uses as many volumes (not exceeding five) as needed.
Miscalculating the remaining space (because the specific volume was smaller or the
compression factor was lower than expected) may cause the file to span more than one
volume. This can result in slower retrieval response time.
Migration to ROSs/OSS
The EXEC statement in the OSS migration skeletons SRVD step contains PARM='OSS'.
Change OSS to the logical name of the target media specified in member IOASPARM in
library IOA INSTCTV.
Specifying a set of platters to which reports (and indexes) should migrate is recommended.
Use meaningful prefixes to create sets of platters containing reports with similar
characteristics (e.g., viewed together, viewed with similar frequencies, viewed by the same
group of users). If a prefix is not specified in the migration mission, the report migrates to
the first available platter.
The user defines ROSs/OSS platters and the VOLSERs on each platter. The platter prefix
in a migration mission resolves to the value specified in parameter PREFIX of the
Migration Mission Definition screen. This platter prefix enables the migration process to
select the desired platter.
After selecting a platter, the migration process scans the VOLSER list and selects the first
completely empty VOLSER in the list. CDAM files migrate sequentially until this VOLSER
is filled (to a maximum of 32K blocks on any volume). Virtual VOLSERs that are not
filled in one migration mission are left partially empty, but no physical platter space is
wasted.
When a file is written on a VOLSER on the ROSs/OSS, it is cataloged on that VOLSER
with the specific label number. The VOLSER of each migrated report is stored both on the
catalog and in the CONTROL-V Migrated User Report file. When the report is viewed, this
catalog entry enables the ROSs/OSS to access the needed platter and read the required
VOLSER. When all VOLSERs on a specific platter are no longer needed, the user can
destroy the platter.
Migration to Disk, Fat-DASD, and IBM 3995 Optical Library
Dataserver (in 3390 Emulation Mode)
It is recommended that you specify the prefix of a set of VOLSERs to which the reports
should migrate. Meaningful prefixes should be used to create sets of volumes containing
reports with similar characteristics (e.g., viewed together, viewed with similar frequencies,
viewed by the same group of users). If a prefix is not specified in the migration mission, the
report migrates to the first available VOLSER that belongs to the MVS UNIT specified in
the media definition.
Migration to FileTek Storage Machine
The following parameters must be specified when the target media is a FileTek Storage
Machine:
VSET Volume set of the storage machine to be used for the migration mission.
FSET File set of the storage machine to be used for the migration mission.
If these parameters are not specified, the default VSET and FSET for the FileTek user ID
specified in member IOASPARM in library IOA INSTCTV will be used.
Refer to the FileTek Storage Machine documentation for information about how to
determine the Volume set and File set.
If separate VSET and FSET values need to be specified for different groups of users, define
a separate migration mission for each group.
Migration to OAM
During the migration process, the CONTROL-V migration program interfaces with IBMs
OAM through application interface OSREQ to store the report as OBJECTs in a
COLLECTION. The size of the OBJECTs are determined by media specific parameters
defined in member IOASPARM.
The SMS management system, guided by the users definition in an ACS routine, directs
the data server to transport the collection of OAM objects to a 3995 device. The user cannot
specify parameters to SMS through CONTROL-V. Therefore, all parameters for SMS must
be specified externally.
Naming Conventions
CDAM Datasets
A primary migrated CDAM dataset conforms to the following naming convention:
dsnpref.prefix.jobname.jobid.datetime.fileid
where:
dsnpref Value specified in installation parameter DSNPREF in member
IOASPARM. All primary CDAM files migrated to the same media have
the same DSNPREF value.
A secondary migrated CDAM dataset conforms to the following naming convention:
secpref.prefix.jobname.jobid.datetime.fileid
where:
secpref Value specified in installation parameter SECPREF in member
IOASPARM. All secondary CDAM files migrated to the same media
have the same SECPREF value.
The other qualifiers are copied from the original CDAM dataset name. See CDAM Dataset
Naming Conventions in Section 5 of the CONTROL-D User Manual. For both primary and
secondary migration, the DATETIME field has the following format:
datetime This field is a CONTROL-V generated timestamp. When a CDAM
dataset migrates from disk to the level 01 target media, this field
remains prefixed by the letter D. This letter is replaced by the next
letter in alphabetical sequence if, as a result of a subsequent
migration or refresh, the DSNPREF of the target media is identical to
the DSNPREF of the source media.
Indexes
An index file conforms to the following naming convention:
ixhpref.ixpref.jobname.date.time.fileid
where:
ixhpref Three-letter first level prefix specified in parameter IXHPREF in
member CTVPARM of the INSTCTV library. All indexes have the
same IXHPREF value.
ixpref Second level prefix specified in parameter IXPREF in member CTVPARM
of the INSTCTV library. All indexes have the same IXPREF value.
date Six-character date in the standard date format at your site.
time Letter T followed by 6 digits indicating the time in hhmmss format.
fileid File ID beginning with the letter M, followed by one digit (from 1 to 9)
which indicates the number of the monitor which created the index,
followed by the 3-digit sequential number of the index produced in the
decollation mission.
A primary migrated index conforms to the following naming convention:
dsnpref.ixpref.jobname.date.time.fileid
where:
dsnpref Value specified in installation parameter DSNPREF in member
IOASPARM. All primary CDAM files migrated to the same media have
the same DSNPREF value.
A secondary migrated index conforms to the following naming convention:
secpref.ixpref.jobname.date.time.fileid
where:
secpref Value specified in installation parameter SECPREF in member
IOASPARM. All secondary CDAM files migrated to the same media
have the same SECPREF value.
For both primary and secondary migration, the DATE field has the following format:
date When an index migrates from disk to the level 01 target media, this
field remains prefixed by the letter C. This letter is replaced by the
next letter in alphabetical sequence if, as a result of a subsequent
migration or refresh, the DSNPREF of the target media is identical to
the DSNPREF of the source media.
The other qualifiers are copied from the original index name.
Migration Mission Workflow
A migration mission consists of the following steps:
Ordering one migration mission adds a MIG mission to the Active Missions file (if its
scheduling criteria are satisfied) and adds a MSM mission to the Active Missions file (if
its scheduling criteria are satisfied). The MIG mission migrates reports from DASD to
the stage 01 target media. The MSM mission migrates reports from the media on which
they currently reside (stage n-1) to the target media of stage n.
If MIG and MSM missions with the same name exist concurrently, the status of both
missions is IN PROCESS but the CONTROL-D/V monitor ensures that job MSM is
not created and submitted before job MIG ends.
The MIG mission scans $SYSDATA records in the Active User file and the MSM
mission scans $SYSDATA records in the Migrated User file to find records for all
reports that need to be migrated by the migration mission. This process produces a list
of datasets to migrate.
The CONTROL-D/V monitor looks for the primary migration skeleton job in the library
referenced by DD statement DADSKL of the CONTROL-D/V monitor. The member
name must be the same as the primary migration mission name (e.g., MIG0007Y).
If secondary media values are specified in a migration mission stage, the
CONTROL-D/V monitor looks for the secondary migration skeleton job in the library
referenced by DD statement DADSKL of the CONTROL-D/V monitor. The member
name must be the same as the secondary migration mission name specified in
parameter SECONDARY NAME in the Migration Mission Definition screen.
Primary and secondary migration skeletons are tailored to produce jobs that perform the
appropriate migrations and analyze the results. For MSM, the MIGRAT step is
automatically duplicated for each migration stage that should be included in the
migration job.
The age of each report is calculated by subtracting the ODATE of its decollation
mission from the ODATE of the migration mission which controls its migration. This
calculation method permits testing whether or not a report will migrate on a future
date by specifying that date in the migration missions ODATE parameter. (An
installation parameter enables calculating the age of each report by subtracting the
ODATE of its decollation mission from the current installation date. This calculation
method does not permit such testing.)
If a report does not currently reside on the media specified for its age (as calculated in
the previous step), it will be migrated to the specified media by the migration mission.
If a report migrated by a migration stage has resided on a media for the number of days
specified in parameter REFRESH EVERY for that stage, the media will be refreshed by
the migration mission.
When the migration job is ready for submission, control is passed to user exit
CTDX010. This exit can add, delete or modify JCL statements in the job. Exit CTDX010
returns one of the following return codes:
0 Submit the job.
4 Do not submit the job. This return code is normally used when the job should be
submitted by CONTROL-M or another production control system.
The migration job JCL is written to the library referenced by DD statement DADJOB of the
CONTROL-D/V monitor with a name identical to the name of the migration mission.
Therefore, this library must not be the skeleton library referenced by DD statement DADSKL.
If %COND% is specified in the migration skeleton, the resolved condition is added to
the IOA Conditions/Resources file. Depending on the return code from user exit
CTDX010, the job is or is not submitted. If CONTROL-M is installed, submission of the
job can be triggered by the condition added by a %COND% statement.
If the migration target media is OSS (DataWare/ROSs/OSS or compatible), the
migration job begins with step SRVD (which releases an OSS device) and step
OSSDBEXT (which creates the OSS Extract Dataset using information from the OSS
Database).
The migration process creates/updates $SYSDATA records in the Migrated User file
with target media, target prefix, timestamp, and other migration parameters for both
primary and secondary migration. All $SYSDATA records pointing to a migrated report
are updated with the new migration information.
For migration stages whose target media is CART, CONTROL-V records the VOLSER
of the last used tape. This enables the next invocation of that migration mission to use
the same tape.
The original copy of each report that expires or moves to another physical media is
marked for deletion. Actual deletion is performed during the next run of utility
CTVCLMIG. This utility should be run periodically.
When the job finishes executing, the CONTROL-D/V monitor is notified by the
ANALYZE step and the migration missions post-processing parameters (OUT and
SHOUT) are processed.
Example: Multi-stage Migration Mission Workflow
The cumulative retention period for reports in this example is 8 years.
Decollating Mission
Report Processing Every workday, CDAM reports and indexes are stored on
DASD for 1 month.
Primary Migration Secondary Migration
Stage 01 Migration Every weekend, 5 reports
and indexes migrate from
DASD to Optical for 11
months.
Optical media is refreshed
every 6 months.
Every weekend, 5 reports
and indexes migrate from
DASD to CART for 7 years
and 11 months.
CART media is refreshed
every 4 years.
Stage 02 Migration Every month, reports and
indexes which have attained
age 12 months migrate from
Optical to CART for 7 years.
CART media is refreshed
every 4 years.
In the illustration above, the Optical media is refreshed after six months and the CART
media is refreshed after 4 years.
The multi-stage migration mission illustrated on the previous page is specified in this
migration mission definition:
---- CONTROL-V CATEGORY MIGOS1C7 MIG MISSION MIGOS1C7 --------(M.S)
COMMAND ===> SCROLL===> CRSR
+------------------------------------------+
======= >>>>>>>>>>>>>>>>>>> TOP OF CATEGORY PARAMETERS <<<<<<<<<<<<<<<<<< =====
CATEGORY MIGOS1C7 MISSION MIGOS1C7
OWNER M15 TASKTYPE MSM GROUP
DESC
===========================================================================
STAGE 01 SCHEDULING PARAMETERS
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
MINIMUM PDS
===========================================================================
IN MIG-DASD-TO-OSS-11M ODAT
TIME FROM TO NOT LATER THAN PRIORITY
===========================================================================
OUT
SHOUT WHEN NOTOK TO OPER URGN R
MSG MIGOS1C7 STAGE 01 ENDED NOT OK
SHOUT WHEN TO URGN
MSG
===========================================================================
RETENTION DAYS 2922 FORCE SECONDARY SKELETON MICOS1C7
===========================================================================
STAGE 01 PRIMARY MEDIA NAME OSS AGE 0030 REFRESH EVERY 0183
PREFIX
SECONDARY MEDIA NAME CART REFRESH EVERY 1460
===========================================================================
MIGRATION PATH SCHEDULING PARAMETERS
DAYS DCAL
AND/OR
WDAYS 0,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 N MAXWAIT 00
MINIMUM PDS
===========================================================================
IN MIG-OSS-TO-CART-7Y ODAT
TIME FROM TO NOT LATER THAN PRIORITY
===========================================================================
OUT
SHOUT WHEN NOTOK TO OPER URGN R
MSG MIGOS1C7 STAGE 02 ENDED NOT OK
===========================================================================
STAGE 02 PRIMARY MEDIA NAME CART AGE 0365 REFRESH EVERY 1460
SECONDARY MEDIA NAME REFRESH EVERY
STAGE 03 PRIMARY MEDIA NAME AGE REFRESH EVERY
SECONDARY MEDIA NAME REFRESH EVERY
===========================================================================
======= >>>>>>> END OF MIGRATE MISSION PARAMETERS OF THIS CATEGORY <<<<<< =====
PLEASE FILL IN MISSION PARAMETERS. USE "SHPF" TO SEE PFK DEFINITION 11.04.10
Exception Handling
If the migration job abends in the MIGRAT step, rerun the job. (Either enter the JOB
library and submit it, or if scheduled under CONTROL-M, use the CONTROL-M rerun
option without restart.)
If the migration job abends in the ANALYZE step, rerun the job from the first step
(i.e., submit it again without restart).
If the ANALYZE step abends, the status of the migration mission remains MIGRATE IN
PROCESS. To reset the migration mission status to ENDED, run the migration job from
the ANALYZE step but change DD statement SYSIN to DUMMY. Sample job MIGRESET
(which resets the migration mission) is in the JCL library.
If a migration mission ends NOTOK because one or more CDAM files did not migrate
successfully, the same mission can be rerun (by specifying option R in the Active Missions
Environment screen) or can be reordered. In either case, only CDAM files which did not
migrate successfully during the previous run are migrated.
Submitting a partially run migration job does not create duplicate copies of files on the
target media. The migration job verifies that each file is cataloged (with the appropriate
migration prefix).
Job Archiving
Organizations which run a large number of production jobs daily need to archive job sysout
while maintaining the ability to access specific jobs, specific job steps, or jobs with certain
attributes.
This can be accomplished using the Job Archiving facility, as described below:
1. Run the production jobs with a dedicated MSGCLASS. Order a generic decollation
mission for that output class. The generic decollation will create a cumulative CDAM
file containing the output of all the jobs which satisfy the decollation missions criteria.
Each job will have a single report entry for same-day viewing and tracking.
In the generic mission, specify a unique prefix for the CDAM file that is accumulated
during the decollation and specify ALLOCOPT=JOBSDSN1.
Specify DO NAME=%%JOBNAME(1,8) to use the job name of the job currently being
decollated as the report name.
Specify DO INDEX=JOBNAME_DDNAMES to create a main index with the name
JOBNAME with a subindex of the DDNAMES. The main index has a single value
comprised of the fixed-length fields listed below separated by a blank. (The same
format is also used by utility CTVJAR. See utility CTVJAR in Section 9 of this guide.)
JOBNAME Name of the job
JOBID ID of the job
SMFID SMF ID of the system in which the job ran
COMP-CODE Completion code of the job
DATE Date of the job
START-TIME Start time of the job
END-TIME End time of the job
This index structure ensures unified access to the reports (before and after
consolidation).
Specify DO MIGRATE=JOBARC in the decollation mission definition to ensure that the
reports will be consolidated before deletion. JOBARC is the name of a fictitious
migration mission that is deleted after the report is consolidated.
Specify DO REMARK=*+CC to capture both the highest condition code of the job and
the SMF ID of the system in which it ran (to be used for index value creation).
Parameters LINE and COL of the DO REMARK statement must be tailored to capture
the SMF ID from the JES message log of the job. (In the example below, the values
specified for LINE and COL should capture the SMF ID in JES2 message $HASP373
under MVS ESA 4.2.)
The specifications described above are illustrated in the sample report decollation
mission below. This sample mission is also contained in member JOBARC of the
CONTROL-D REPORTS library.
Example
CATEGORY GENCAT JOBNAME * GENERIC Y MONITOR
===========================================================================
DEF COPIES LVL USER DEST MAX COPIES
===========================================================================
ON CLASS = R EXTWTR DEST FORM
PRT COPIES LVL USER DEST MAX COPIES
PRINT/CDAM PARMS = ALLOCOPT=JOBSDSN1
PRINT/CDAM PARMS =
STRING =
DO NAME = %%JOBNAME(1,8) LINE COL -
DO USER = MKT LVL LINE COL - S A T
SYNONYM = CONCAT =
DO INDEX = JOBNAME_DDNAMES R
DO REMARK = *+CC LINE 004 COL 073 - 077
DO MIGRATE = JOBARC
DO
2. Once a day, run utility CTVJAR to consolidate all report entries created by the generic
decollation into one report entry, with an index that has an entry for each job. Utility
CTVJAR will process all accumulated CDAM files that have a specific prefix (the
unique prefix specified in the generic decollation mission) and that were created until
the end of the previous day. Utility CTVJAR creates a single report entry with the
specified attributes (e.g., printing/backup/migration mission) and a single main index.
Subindex DDNAMES that was created during decollation is copied and converted to a
subindex of the newly created index.
3. Delete the job-specific report entries with utility CTDDELRP. In the CTDDELRP
control statements, set the number of days that each report entry (described in item 2
above) will be kept. Report entries can either be kept for one day (until the
consolidation routine is run) or can be kept for several days to expedite retrieval.
4. Display type J is available in the User Reports entry panel for accessing jobs archived
by the Job Archiving facility both before and after consolidation. This display type can
be selected by issuing a DI J command in the entry panels command line. Display type
J can be used to initiate a hit-list search for a specific job having specific attributes (job
name, job number, run date, run time, run system, and the jobs highest return code).
The search criteria entered by the user is used by CONTROL-V to dynamically compose
the appropriate index value and display the job the user is looking for. See section 2 in
the User Manual for details of the User Reports entry panel.
IOA Archive Server
General
The IOA Archive server enables online viewing and immediate printing of reports and
indexes which have migrated to non-disk storage media. The server provides access to the
following media types:
CART 3480/3490/3490E/3590 Tape Cartridge.
DASD Disks (e.g., 3380, 3390, fat-DASD 3390-9 or IBM 3995 Optical Library
Dataserver in 3390 emulation mode).
OSS DataWare/ROSs/OSS or compatible.
FTK FileTek Storage Machine (SM).
OAM IBMs Object Access Method (OAM).
Note OSS media, which includes DataWare ROSs and KODAK OSS, was called KODAK
OPTISTAR prior to IOA release 5.1.4.
There is no connection or dependency between the CONTROL-D/V monitor and the IOA
Archive server. Each can be brought up and down independently.
Device Definition and Usage
Cartridge (CART) Media
The cartridge devices defined in member IOASPARM in the INSTCTV library for media
type CART can be used in the following two modes:
Dedicated
Dynamic
Dedicated Device Mode
Dedicated devices are allocated to the server during the entire time the device is connected
to the server. Devices can be defined explicitly by parameter DEVADDR, or implicitly by
parameter DEVQTY. Devices can be connected (STARTed) or disconnected (STOPped) at
any time using operator commands.
When using this mode, the number of devices available for the server is known. The
response time for user requests can be predicted based on the servers workload.
Dynamic Device Mode
Dynamic devices are allocated to the server when needed, and freed when no requests are
pending. Dynamic devices are defined implicitly by parameter DEVQTY. This parameter
defines the maximum number of devices that are allocated when the server is started. The
allocation is done upon request. No device is allocated until the first access is issued by an
online viewing user. Parameter DYNDEVRLSE defines when the device will be freed after
requests have been processed:
DYNDEVRLSE=(method,idletime)
where:
method Indicates the allocation method to use when processing a request for a
volume. Valid values:
SWITCH Free the device when a request for another volume is to
be processed. The device can be released and allocated
to another job even if there are still requests pending.
Dynamic allocation is performed in a standard manner
using the MVS catalog. This is the recommended
method at sites with multiple Robotic Tape Libraries
and at sites where IOASMON non-switched allocation
impacts the Tape Management Systems functionality.
NOSWITCH Process requests for all volumes before releasing the
device.
idletime Number of minutes to hold the device after the last request is processed.
This parameter ensures that if a request is issued within the specified
time interval, the device will still be available to the server. This
parameter applies to both SWITCH and NOSWITCH methods.
DataWare/ROSs/OSS Usage
Note ROSs/OSS media, which includes DataWare ROSs and KODAK OSS, was called
Updating the OSS Database
Before updating the OSS database by adding/deleting virtual tapes or importing/exporting
platters, stop the IOA Archive server or the appropriate media in the IOA Archive server.
When the update is complete, run job LODOSSDB from the IOA INSTCTV library to create
the OSS Extract Dataset file. After this job completes, reactivate the IOA Archive server
or, if only the media was stopped, restart the media.
FileTek Storage Machine Media Definition
CONTROL-V communicates with the FileTek Storage machine via an application interface.
The Resources (devices) defined in IOASPARM for media type FTK are logical devices. A
logical device task is activated whenever a request is made to access a dataset that is not
already being handled by another logical device. Each device task handles only one dataset
at a time.
FTK Media Definition
The following parameters are used to define FTK media during CONTROL-V installation:
MAXCONN Maximum number of logical devices that can be active at any one time
for the media. Each logical device opens a session with the Storage
Machine (SM). See the documentation supplied with the FileTek
Storage machine to determine an appropriate value for this
parameter.
Note If more than one media has been defined for the same SM, you
must verify that the sum of the values specified for parameter
MAXCONN in all media definitions for the SM does not exceed
the maximum number of sessions that the SM can support.
SMNAME Name of the FileTek Media being defined.
SUBSYS Name of the FileTek Host Storage Machine subsystem.
ACCOUNT Storage Machine Account ID. CONTROL-V uses this value to open a
session with the FileTek SM.
PASSWORD Password for the specified ACCOUNT.
GROUP An Access Group name for files migrated to this media.
GROUPPWD Used to specify passwords for access to files in the specified GROUP.
Separate passwords can be specified for READ, WRITE, and DELETE
access of the files in the GROUP.
Using the above parameters you can create several different definitions for FTK media.
Some possible reasons for creating more than one definition for FTK media include:
You have more than one FileTek Storage Machine at your site.
You want to maintain several different groups of datasets on the same SM (e.g., with
different passwords). To accomplish this, define the different FTK media with the same
subsystem (SUBSYS) and storage-machine (SMNAME) name, but with different group
names (GROUP) and group passwords (GROUPPWD).
The parameters used for FTK media definition are described in detail in the CONTROL-V
section of the IOA Installation Guide.
Object Access Method (OAM) Usage
CONTROL-Vs IOASMON Archive server retrieves reports from the OAM via the OSREQ
application interface.
The resources (devices) defined in IOASPARM for media type OAM are logical devices. A
logical device task is activated whenever a request is made to access a dataset that is not
already being handled by another logical device. Each logical device handles only one
dataset at a time.
Up to 100 logical devices can be activated at a time depending either on the value specified
for CONTROL-V installation parameter MAXCONN or, optionally, the maximum number
set via a START or STOP operator command. If all (i.e., the maximum number of) logical
devices are active concurrently and additional requests are made, those requests wait in a
queue for an available logical device.
Media and Resource Control
The use of each media and resource defined to the IOA Archive server can be controlled
using operator commands:
Each media with all its resources can be stopped and restarted.
Resources (devices, sessions, etc.) can be connected to or disconnected from the IOA
Archive server.
Operator commands for media and resource control are described below:
Media Control
Each media defined to the IOA Archive server can be stopped and restarted separately.
To stop a media with all its resources, issue operator command:
F IOASMON,STOP MEDIA=media-name
When the media is stopped, an appropriate message is displayed on the operator console.
To start a media, issue operator command:
F IOASMON,START MEDIA=media-name
When the media is ready to receive requests, an appropriate message is displayed on the
operator console.
Resource Control
Resources and their usage differ by media type.
ROSs/OSS Media DataWare/ROSs/OSS Storage Subsystem
The ROSs/OSS works in 3480 emulation. Its resources are treated like 3480 devices. The
devices are referred to by device number. Each device defined to the IOA Archive Server
can be stopped and restarted separately.
To stop an OSS device, issue operator command:
F IOASMON,STOP MEDIA=media-name,DEVICE=device-number
When a device stops, an appropriate message is displayed on the operator console.
To start an OSS device, issue operator command:
F IOASMON,START MEDIA=media-name,DEVICE=device-number
When a device is ready to process requests, an appropriate message will be displayed on
the operator console.
Notes Before starting an OSS device, make sure that the device is online and ready in
the system.
ROSs/OSS media, which includes DataWare ROSs and KODAK OSS, was called
CART Media 3480/3490/3490E/3590 Tape Cartridge Subsystem
The resources are actual tape/cartridge devices. Devices are referred to by device number,
or by specifying the quantity of devices and letting the IOA Archive server decide which to
use or free. Each device defined to the IOA Archive server can be stopped and restarted
separately.
To stop a specific device, issue operator command:
When the device stops, an appropriate message is displayed on the operator console.
To start a specific device, issue operator command:
Note Before starting a CART device, make sure that the device is online and ready in the
system.
This command can be issued only when the devices are dedicated to the IOA Archive
Server. If the devices are used dynamically, start a device by specifying device quantity.
When the device is ready to process requests, an appropriate message is displayed on the
operator console. To stop one/some/all devices of a specific media, issue operator command:
F IOASMON,STOP MEDIA=media-name,DEVQTY=number|ALL
where number can be any integer from 1 through 99, or the value ALL can be specified
instead.
As each device is stopped, an appropriate message is displayed on the operator console.
To start one/some/all devices of a specific media, issue operator command:
F IOASMON,START MEDIA=media-name,DEVQTY=number|ALL
where number can be any integer from 1 through 99, or the value ALL can be specified
instead.
As each device becomes ready to process requests, an appropriate message is displayed on
the operator console.
Note Before starting the devices, make sure enough devices are online and ready in
the system.
FTK FileTek Storage Machine (SM) or OAM Object Access Method
Media
The resources (devices) defined in IOASPARM for media type FTK and OAM are logical
devices. A logical device task is activated whenever a request is made to access a dataset
that is not already being handled by another logical device. Each logical device handles
only one dataset at a time.
Up to 100 logical devices can be activated at one time depending on the value specified for
CONTROL-V installation parameter MAXCONN, and optionally, the maximum set via a
START or STOP operator command. If more than MAXCONN requests were made
concurrently, they will wait in a queue for an available logical device.
Logical Device Status
Logical devices are each assigned one of the following statuses:
ACTIVE/BUSY The device is processing a request for file access.
IDLE The device processed a request recently and is waiting for another
request.
INACTIVE The device is not processing any requests.
When a logical device finishes processing a request, it checks the DSN queue for the next
request. If no request is found, the logical device enters the IDLE status. If no request is
detected within a limited time period, the device is assigned a status of INACTIVE.
Note If no requests are being processed and the number of usable devices is one or more,
device number one retains a status of IDLE (i.e., its status is not set to
INACTIVE).
Reducing/Increasing the Number of Usable Devices
As mentioned above, the maximum number of devices is defined via installation parameter
MAXCONN. You can, however, limit the number of devices to be used (usable devices) via
operator commands.
To reduce the number of usable devices, issue operator command:
F IOASMON,STOP MEDIA=media-name,DEVQTY=num|ALL
where num is the number of logical devices to be brought down. num can be any integer
from 1 through 99, or the value ALL can be specified instead.
The STOP command determines which devices should be stopped, according to device
status.
The specified number of INACTIVE devices are stopped.
If the number of devices to be stopped is greater than the number of devices that are
presently INACTIVE, IDLE devices are stopped as well.
If the number of devices to be stopped is greater than the number of devices that are
either INACTIVE or IDLE, BUSY/ACTIVE devices are stopped as well.
Each BUSY device to be stopped completes the request it is processing before being
assigned a status of INACTIVE.
To increase the maximum number of devices, use operator command:
F IOASMON,START MEDIA=media-name,DEVQTY=num|ALL
where num is the number of logical devices to be brought up. num can be any integer from
1 through 100, or the value ALL can be specified instead.
Note The maximum set by the START command cannot be greater than the number
specified for CONTROL-V installation parameter MAXCONN.
Starting/Stopping a Specific Logical Device
To stop a specific ACTIVE (or IDLE) device, issue operator command:
When the device is stopped, the maximum number of usable devices is reduced by 1 and an
appropriate message is displayed on the operator console.
To start a specific INACTIVE device, issue operator command:
When the device is started, the maximum number of usable devices is increased by 1 and
an appropriate message is displayed on the operator console.
Note The maximum set by the START command cannot be greater than the number
specified for CONTROL-V installation parameter MAXCONN.
Since the devices defined for the FTK type media are logical devices (i.e., not physical
devices), starting or stopping any specific device has the same effect as using the DEVQTY
parameter to increase/decrease the maximum number of usable devices by one.
Displaying Media Information
Information about a media can be displayed by issuing operator command:
F IOASMON,DISPLAY MEDIA=media-name
The information displayed as a result of this command includes media and resource
information. The media information includes details such as:
Media type
System unit name/type to be used for this media
Number of pending requests
Type and number of resources
Resource information varies by media type but includes details such as:
Device number
Device use type (DEDICATED/DYNAMIC)
Device status (ACTIVE/BUSY/INACTIVE/IDLE)
Details about the current process, if there is one (e.g., user ID, volser, or dsn)
High or low water mark, number of gets and puts, time of last get and put
Data integrity status flag
FTK FileTek Storage Machine (SM) or OAM Object Access Method
Media
Resource information for FTK or OAM media includes:
Maximum number of usable devices
Number of devices that are active (with a status of BUSY, ACTIVE, or IDLE)
Status (displayed for each logical device)
User-ID and the name of the dataset being processed (displayed for each logical device)
Devices that are no longer usable, or are currently INACTIVE, are displayed on the console
with a status of INACTIVE.
The IOA Archive Server is supplied with internal debugging facilities. Under normal
circumstances, these facilities are dormant. However, if required (e.g., your IOA
representative requests debugging information), it is possible to activate the debugging
facility as follows:
1. The debugging level can be set when starting the IOA Archive server or during normal
operation. To start the debugging facility while starting the IOA Archive server, issue
operator command:
S IOASMON,DEBUG=level
To start the debugging facility during operation, issue operator command:
F IOASMON,SET DEBUG=level
The debugging level can be any value from 0 (no debugging) to 255. The required
debugging level, and instructions to set it with a START or MODIFY command, will be
supplied by your IOA representative.
When the IOA Archive server debugging facility is successfully activated, the following
message is displayed on the operator console:
IOA128I IOASMON DEBUG LEVEL IS SET TO level
Note It is strongly recommended that you do not activate the IOA Archive server with
parameter DEBUG on a regular basis for the following reasons:
Spool utilization is greatly increased if a large amount of debugging information
is generated.
In case of a JES problem, the IOA Archive server may become suspended while
waiting for JES.
2. Debugging information is printed to DD statements PRTDBG and DADUMP of the IOA
Archive server procedure.
3. When problem determination procedures are completed, turn off the debugging facility
by issuing operator command:
F IOASMON,SET DEBUG=0
When the IOA Archive Server debugging facility is successfully deactivated, the
following message is displayed on the operator console:
IOA128I IOASOM DEBUG LEVEL IS SET TO 0
User Report List File Management
Overview
The following User Report List files are contained in the CONTROL-D repository:
Active User Report List file
History User Report List file
Migrated User Report List file (CONTROL-V only)
Permanent User Report List file
These files are managed by the IOA Access Method. Each file consists of two separate
sequential datasets:
A Data component, where the actual record information resides.
An Index component, which provides keyed access to records in the Data component.
Both Data and Index components can extend beyond one physical dataset (depending on
whether or not automatic extension was specified for the file during allocation). Initially, a
component is allocated as a single physical dataset called the primary extent.
See IOA Access Method in Section 2 of this guide for more information.
The file naming convention is:
prefix.dbname.Ennn
where:
prefix Set to CONTROL-D installation parameter DBPREFD.
dbname Set to file identifier name, as follows:
HST CONTROL-D History User Report list Data component.
ACT CONTROL-D Active User Report list Data component.
ACTI CONTROL-D Active User Report list Index component.
HSTI CONTROL-D History User Report list Index component.
PRM CONTROL-D Permanent User Report list Data
component.
MIG CONTROL-V Migrated User Report list Data component.
MIGI CONTROL-V Migrated User Report list Index component.
PRMI CONTROL-D Permanent User Report list Index
component.
Ennn Extent sequence number suffix. The suffix consists of the letter E
followed by nnn, a number from 000 to 255, indicating the extent
sequence number.
Example
If CONTROL-D installation parameter DBPREFD contains the value CTD, the following
file names are assigned for the Active User Report List file:
CTD.ACT.E000 For the Data component.
CTD.ACTI.E000 For the Index component.
Each component uses its own file definition member which resides in the IOA INSTCTD
library. The member includes the files physical and logical attributes. The member name
is DEFxxx for a Data component, or DEFxxxI for an Index component, where xxx is the
dbname as described previously. The member is used by utility IOADBF. Additional
utilities are provided to maintain these IOA Access Method files. See Section 9 of this
guide for more information about these utilities.
The files can be activated with dual (mirror image) file support. The dual file name is
similar to the main file name, except for the suffix (Dnnn instead of Ennn). Dual file
support can be defined for both the Data component and Index component. It is
recommended that this feature be activated only for the Data component to reduce
overhead, since the Index component can be built from the Data component.
See Repository Maintenance later in this section for details about maintaining these files.
Permanent User Report List File
The Permanent User Report List file can be referred to as a report catalog. It contains, for
each user, the list of reports the user (recipient) can receive at any time, their copy count
(for the user), the print destination (if it is not one of the main computer printers such as
LOCAL), and other information.
The Permanent User Report list file is used by end users (recipients) to permanently define
the number of (printed) copies they want to receive from each report (in a given category),
to request that the report be printed on a local printer, to assign a copy of the report to
another user, and to permanently define other report list defaults.
Once a day, the report list in the Permanent User Report List file can be copied to the
Active User Report List file. The user, for example, can change the copy count of his/her
reports on the Active User Report List file, but that change remains in effect only for that
day. On the next day, the reports of each user are copied again from the Permanent User
Report List file to the Active User Report List file with the original (permanent) copy
count. Using this simple method, the user can either set the copy count of a report
permanently by modifying it in the Permanent User Report List file (using the Online
Permanent User Report list screen), or temporarily modify it for a specific day in the
Active User Report List file (using the Online Active User Report List screen). All other
updatable fields (parameters) work the same way.
There are two ways to access the data stored in this file:
Using utility CTDCP2A
Using the decollation mission definition SEARCH parameter
Utility CTDCP2A
This utility is used to copy the list of reports from the Permanent User Report List file to
the Active User Report List file. Newly-made changes to the Permanent User Report List
file are then reflected in the Active User Report list file. Each report copied to the Active
User Report List file has an original scheduling date associated with it. The original
scheduling date is passed as a parameter to the utility. If the parameter is omitted, the
system date is used. (For more details, refer to utility CTDCP2A in Section 9 of this guide.)
Running this utility more than once a day (e.g., after a computer crash) does not create
duplicate entries. You can run this utility before or after the New Day procedure.
SEARCH Parameter
This is the recommended method for accessing the Permanent User Report List file. By
setting parameter S(earch) in the report decollation mission definition, the relevant
Permanent User Report List file entries are accessed during the decollation process to
retrieve the values of the report parameters. See Section 3 of the CONTROL-D User
Manual for a description of parameter S(earch) in the DO USER statement.
Utility CTDCA2P
Utility CTDCA2P copies newly generated report/user entries from the Active User Report
List file to the Permanent User Report List file (which maintains the list of all reports that
can be created at any specific time).
New report/user entries are created on the Active User Report List file when a new
recipient is detected in a certain report (e.g., when a new bank branch is opened). This
entry has the default copy count of the report as defined in the report decollating mission.
The utility copies the entries to the Permanent User Report List file, thereby automatically
updating the User Report list on the Permanent User Report List file. It does not update
User/Report entries that already exist in the Permanent User Report List file.
Utility CTDCA2P can be run more than once a day (e.g., after a computer crash). Duplicate
entries are not created.
It is recommended that the utility be run once a day, preferably before the New Day
procedure is invoked.
Active User Report List File
The Active User Report List file contains entries with the following report status:
Reports due to be decollated (in WAIT DECOLLATION status). These entries are
created by utility CTDCP2A.
The user can change the copy count and print destination.
The user can add additional report recipients.
Reports which are decollated but are waiting to be bundle printed (in WAIT PRINT
status):
The user can view the reports.
The user can change the copy count, print destination and any other report
characteristics.
Reports which are decollated but will not be bundle printed (in DECOLLATED status):
The user can issue an immediate print request.
Reports which have been printed (in PRINTED or PRINTED-WAIT BKP status):
CONTROL-V reports which are decollated but have not yet migrated from DASD
storage, or reports that have been migrated after the last run of utility CTDDELRP
(i.e., reports in WAIT MIGRATE status):
The Active User Report list files may contain reports from more than one day. Therefore,
these files can contain more than one entry for each report/recipient/category. Each entry
is distinguished by its original scheduling date and its decollation date.
Migrated User Report List File
The CONTROL-V Migrated User Report List file contains a list of all migrated reports that
have been deleted from DASD. These reports are in MIGRATED status. The user can:
View the reports.
Issue an immediate print request.
The user can request that the Active User Report List screen display reports from the
Active User file only, from the Migrated User file only, or from both User Report List files.
The Migrated User Report List files can contain reports from more than one day.
Therefore, these files can contain more than one entry for each report/recipient/category.
Each entry is distinguished by its original scheduling date and its decollation date.
Utility CTVCLMIG
This CONTROL-V utility erases from the Migrated User Report List file all report entries
for which the retention period has expired (i.e., the number of days that the reports should
be retained has passed). For relevant migrated media, the utility produces a list of tapes
which can be freed for general use (i.e., returned to the free tape pool).
Each report copied to the Migrated User Report List file has an original scheduling date
associated with it.
This utility can be run before or after the New Day procedure and it can be run more than
once a day (e.g., after a computer crash).
This utility should be run at least once a week. For more information, refer to the
description of this utility in Section 9 of this guide.
History User Report List File
The History User Report List file contains a list of all backed up reports that have been
deleted from the disk. The site can control the time that the report will be retained in the
History User Report List file. The file also contains details about the storage media of the
report data (compressed dataset name on disk, or volsers of tape or cartridge).
To view a report, the user should issue a report restore request from the History User
Report List file. When the report restore request is performed, the user report entry is
copied from the History User Report List file to the Active User Report List file by the
restore mission as soon as the report is restored from tape to disk.
Utility CTDDELRP
CONTROL-D utility CTDDELRP scans the Active User Report List file for reports whose
Active User Entry has expired. For reports meeting the specified selection criteria, utility
CTDDELRP does the following:
Reports for which a backup or migration has been requested but not performed are
flagged as WAITING FOR BACKUP (or WAITING FOR MIGRATION).
The entry of each report for which both backup and migration have been performed is
moved from the Active User Report List file to both the History and Migrated User
Report list files.
The entry of each report for which only migration has been performed is moved from
the Active User Report List file to the Migrated User Report List file.
The entry of each report for which only backup has been performed is moved from the
Active to the History User Report List file.
A report entry that is not requested to be backed up or migrated is erased from the
Active User Report List file.
When the Active User Report List file has no entries for a report, the compressed
dataset containing that report is erased from DASD storage (if it does not contain data
of other reports not yet erased).
Run this utility at least once a day, preferably after all backups have finished executing.
See Section 9 of this guide for more information about utility CTDDELRP.
There is no harm in running utility CTDDELRP more than once a day (e.g., after a
computer crash). You can run this utility before or after the New Day procedure.
Utility CTDCLHIS
This utility erases from the History User Report List file all entries belonging to reports for
which the backup period has expired (i.e., the number of days that the reports should be
retained has passed). The utility produces a list of tapes which can be freed for general use
(i.e., returned to the free tape pool).
This utility can be run before or after the New Day procedure and it can be run more than
once a day (e.g., after a computer crash). This utility should be run at least once a week.
For more details, refer to Section 9 of this guide.
User Report List File Maintenance
The following steps should be applied when maintaining various User Report List files,
usually on a daily basis:
Copy report definitions from the Permanent User Report List file to the Active User
Report List file (utility CTDCP2A).
Copy the new user/report entries from the Active User Report List file to the
Permanent User Report List file (utility CTDCA2P).
Erase old user/report entries from the Active User Report List file and erase their
compressed datasets. Move/copy report entries from the Active User Report List file to
the History User Report List file and/or the Migrated User Report List file (utility
CTDDELRP).
Erase report information from the History User Report List file (utility CTDCLHIS).
Erase report information from the Migrated User Report List file (CONTROL-V utility
CTVCLMIG).
Repository Maintenance
General
The CONTROL-D Repository consists of the following files:
Active Missions file (AMF).
Active Transfer file (ATF).
User Report List files:
Active User Report List file.
Permanent User Report List file.
History User Report List file.
Migrated User Report List file for CONTROL-V.
All the files are self-maintained by the New Day procedure or by utilities described earlier
(e.g., CTDDELRP, CTDCLHIS). Self maintenance is usually performed on a daily basis.
Additional utilities are used for expanding file sizes, physical reorganization, etc. An
explanation of how to use these utilities follows.
Expanding the Active Missions File
1. Change CONTROL-D installation parameter AMFSIZE in member CTDPARM to the
required new Active Missions file size. Assemble the CONTROL-D installation
parameters. Alternatively, perform these steps using the CUSTOMIZE activity in ICE.
2. Change parameter AMFSIZE in job FORMAMF in the IOA INSTCTD library to the
new size of the Active Missions file.
3. Run member FORMAMF of the IOA INSTCTD library. Change the dataset names so
you do not override the existing Active Missions file and its backup file (e.g., parameter
TYPE should be changed to NEWAMF).
4. Stop CONTROL-D activities which use the Active Missions File (e.g., CONTROL-D
monitor, online activities).
5. Run utility CTDCAMF with the following parameters:
//EXEC CTDCAMF,
// OLDAMF=CTD.PROD.AMF, old Active Missions file
// NEWAMF=CTD.PROD.NEWAMF new Active Mission file
COPY
//
Utility CTDCAMF copies the current Active Missions file to the new Active Missions
file. The utility should end with a condition code of 0. See sample job CTDCAMF in the
CONTROL-D JCL library for more details.
6. Rename the old Active Missions file (and its backup file using suffix AMB).
7. Rename the new Active Missions file (and its backup file using suffix AMB) to the
former names of the old file.
8. Start the CONTROL-D monitor and resume operation.
Expanding the Active Transfer File
1. Change CONTROL-D installation parameter ATFBLK in member CTDPARM to the
required new Active Transfer file size. Assemble the CONTROL-D installation
parameters. Alternatively, perform these steps using the CUSTOMIZE activity in ICE.
2. Stop all CONTROL-D related activities (e.g., CONTROL-D monitor, online activities).
3. Rename the old Active Transfer file (and its backup file using suffix ATB).
4. Change parameter ATFSIZE in job FORMATF in the IOA INSTCTD library to the new
size of the Active Transfer file.
5. Run member FORMATF of the IOA INSTCTD library.
6. Run utility CTDCATF with the following parameters:
//EXEC CTDCATF,P=COPY,
// INATF=CTD.PROD.OLDATF, old Active Transfer file
// OUTATF=CTD.PROD.ATF new Active Transfer file
//
Utility CTDCATF copies the current Active Transfer file to the new Active Transfer
file. The utility should end with a return code of 0.
7. Start CONTROL-D monitor and resume operation.
User Report List File Housekeeping
Perform the following User Report List file housekeeping activities as required:
Reorganize the Files
Dynamically Sort the Active User Report List File
Rebuild the Index Component
Recover a Damaged File
Reorganizing the Files
The Data and Index components of an IOA Access Method file may extend beyond one
physical dataset. When an IOA Access Method file extends to many physical datasets,
processing may degrade due to fragmentation overhead. In this case, it is recommended
that you reorganize the IOA Access Method file so that the primary and secondary extent
datasets are larger. Perform the following steps:
1. Stop all CONTROL-D related activities (CONTROL-D monitor, online activities, batch utilities).
2. Run utility IOADUL to unload the contents of the Data component to a sequential file. See
member CTDUFDUL in the CONTROL-D JCL library for an example.
3. Increase the value specified for parameter SPACE in the relevant DEFxxx and DEFxxxI
definition members to specify larger primary and secondary extents. This parameter should
be changed in the definition members of both the Index and Data components.
4. Delete all dataset extents of the Index and Data components. This step should be performed
with caution. See member CTDUFDEL in the CONTROL-D JCL library for an example.
5. Run the IOADBF utility with parameter FUNC=INIT to allocate and format the new files
components using the new parameters. The utility should be activated twice, once for the
Data component and a second time for the Index component. See member CTDUFDBF in
the CONTROL-D JCL library for an example.
6. Run utility IOADLD to reload contents of the Data component from the sequential dataset
previously produced by utility IOADUL. Run utility CTDDIB to rebuild the Index
component. See member CTDUFRST in the CONTROL-D JCL library for an example.
7. Restart CONTROL-D and all other related activities.
Dynamic Sorting of the Active User Report List File
The Active User Report List file can be dynamically sorted by utility IOADBSR.
The Index component of the IOA Access Method file functions as a balanced tree index. The
CONTROL-D monitor can optionally sort the Data component of the Active User Report
List file so that the physical order of the records is the same as the logical order of the
Index component. This automatically provides increased I/O performance benefits for users
of the CONTROL-D Online Viewing facility and utilities such as CTDDELRP.
Dynamic sorting of the Active User Report list file does not inhibit the simultaneous
execution of other CONTROL-D activities, such as decollation, printing, backup and
restore mission processing, or access to online user facilities.
Although dynamic sorting allows other processes to be performed concurrently on the same
file components, IOA supplies a set of Sort Control parameters that can be specified to
execute dynamic sorting at a time of day and at intervals when access to CONTROL-D file
components is at a minimum. Sort Control parameters are described in the documentation
of utility IOADBSR in Section 9 of this guide. Dynamic sorting is disabled by default (see
parameter ENABLE in the description of the Sort Control parameters).
Dynamic sorting of the Active User Report list file is enabled and controlled by the
parameters specified in member DBSRTPRM in the CONTROL-D PARM library (allocated
to DD statement DASORTPR in the CONTROL-D monitors procedure JCL).
IOA Access Method files can also be sorted by executing utility IOADBSR as a batch job.
Utility IOADBSR is described in Section 9 of this guide.
Rebuilding the Index Component
To rebuild the Index component, perform the following steps:
1. Stop all CONTROL-D related activities (CONTROL-D monitor, online activities, batch
utilities).
2. Run utility CTDDIB to rebuild the Index component from the Data component. See
member CTDUFDIB in the CONTROL-D JCL library for an example.
3. Restart CONTROL-D and all other related activities.
Recovering a Damaged File
If dual mirror image file processing is used, it is possible to immediately recover a
damaged file. The dual file is an exact copy of the main file. The recovery procedure uses
utility IOADCPY to copy the entire dual file to the main file or vice versa. Before starting
the recovery procedure, make a backup copy of the main file and the Dual file.
If the Main file is damaged, perform the following recovery steps:
utilities).
2. Delete all extents of the Data component of the main copy only. For example, to delete
all the extents of the Active User Report List file, list all the files with prefix
CTD.ACT.E* and delete them.
3. Run the IOADCPY utility with parameter SUFFIX set to the Dual file (D000). See
sample member CTDUFCPY in the CONTROL-D JCL library for an example.
4. Rebuild the Index component as described above.
5. Restart all CONTROL-D activities.
If the Dual file is damaged, perform the following recovery steps:
utilities).
2. Delete all extents of the Data component of the Dual copy only. For example, to delete
all the extents of the CONTROL-D Active User Report List file, list all the files with
prefix CTD.ACT.D* and delete them.
3. Run the IOADCPY utility with parameter SUFFIX set to the Main file (E000). See
sample member CTDUFCPY in the CONTROL-D JCL library for an example.
4. Rebuild the Index component as described above.
5. Restart all CONTROL-D activities.
See Section 9 of this guide for more information about IOA Access Method utilities for User
Report List files.
SMF Accounting
CONTROL-D produces several types of SMF records which provide comprehensive
accounting and chargeback information.
1. An SMF record for each printed report is produced during deferred printing. The record
number is specified in parameter SMF=nnn in member CTDPARM in the INSTCTD
library. The record can be disabled by setting SMF to NO in member CTDPARM. The
structure of the record is described in macro CTDSMF in the IOA MAC library.
CONTROL-D exit CTDX006 receives each record before it is written to SMF files. The
exit can change or add fields to the record.
2. An SMF record can be produced for each printed report during immediate printing.
This is triggered by optional wish number WD0892 in member IOADFLTC in the IOA
SECUDATA library. The record number and structure are identical to those provided
for deferred printing.
3. An SMF record describing activity of an online user is written during logoff operation
performed under the IOA online monitor. The record contains CPU/EXCP consumed by
the current user and also the number of operations performed by it (e.g., print, restore,
delete requests). The record is produced by IOA exit IOAX006S. The desired record
number should be set in the exit. The exit must be recompiled. The structure of the
record is described by macro CTDSF1 in the IOA MAC library.
4. An SMF record created during a decollation process contains the number of pages/lines
processed by a decollation mission, the CPU utilized by it, the number of report entries
built, etc. The record is built by of CONTROL-D exit CTDX022D. Desired record
numbers should be set in the exit. The exit must be recompiled. The structure of the
record is described in macro CTDSF2 in the IOA MAC library.
5. An SMF record is produced when each request from the IOASMON CDAM Archive
Server completes execution. The SMF record number is specified in parameter
SMF=nnn in member IOASPARM in the INSTCTV library. Generation of this SMF
record can be disabled by setting SMF=NO in member IOASPARM. The structure of
this SMF record is described in macro CTVSMF in the IOA MAC library. CONTROL-V
exit CTVX002 receives each record before it is written to the SMF file. The exit can add
or change fields in the record and can prevent the record from being written.
Deleting IOA Access Method Files
When deleting IOA Access Method files (e.g., for reorganization or reallocation with new
SPACE parameters), delete all existing extents, not just the first (*.E000) extent. Use job
CTDUFDEL for this purpose.
General ...........................................................................................................................................5-1
Starting CONTROL-O................................................................................................................5-1
Shutting Down CONTROL-O....................................................................................................5-2
Replacing an Active CONTROL-O Monitor ..............................................................................5-2
Replacing the Active CONTROL-O Executor Module (CTOWTO).....................................5-2
Replacing the Active CMEM Executor Module (CTOAIDT)...............................................5-2
Rule Types...................................................................................................................................5-3
Automatic Loading of Rules.......................................................................................................5-4
Manual Loading of Rules ...........................................................................................................5-5
Manual Loading of CMEM Rules ..............................................................................................5-6
Deleting (Deactivating) an Active Rule Table ..........................................................................5-7
Rule Loading Errors Related to Type of Table..........................................................................5-7
Virtual Storage Requirements of the CONTROL-O Monitor.............................................5-9
Calculating Region Size .............................................................................................................5-9
Troubleshooting ........................................................................................................................5-10
Storage Allocation.....................................................................................................................5-10
Structure of the IOA Conditions/Resources File.....................................................................5-10
CONTROL-O Usage of the Common Storage Area (E/CSA)............................................. 5-11
Extended CSA Usage (Above the 16M Line)...........................................................................5-11
CSA Usage (Below the 16M Line)............................................................................................5-11
Recommended Organization Method................................................................................... 5-12
Replacing the IPL CONTROL-O .............................................................................................5-14
Rule Scheduling........................................................................................................................5-15
Displaying Active Rules ......................................................................................................5-15
Management of CONTROL-O Facilities............................................................................... 5-16
Controlling the Message Statistics Facility ............................................................................5-16
Preventing Unnecessary Enlargement of Statistics Files.................................................5-17
Handling Near-Full and Full Conditions for the Statistics File.......................................5-17
Controlling the Automation Log Facility ................................................................................5-18
Determining the Size of the Log.........................................................................................5-18
Preventing Logging of Unnecessary Messages..................................................................5-19
Management of the CONTROL-O Status Monitoring System (COSMOS)...........................5-19
Controlling Rule Operation Mode............................................................................................5-20
Controlling OpenEdition (UNIX for MVS) Support ...............................................................5-21
Global AutoEdit Variables ...................................................................................................... 5-23
Defining a New Global Member or Variable Database .................................................... 5-25
Automatic Compression of the Global AutoEdit Library ................................................. 5-27
Modifying the CONTROL-O Sleeping Interval...................................................................... 5-28
Refreshing the CONTROL-O Security Cache ........................................................................ 5-29
Customization of Automation Options................................................................................. 5-34
AOP Overview.......................................................................................................................... 5-34
Menus ....................................................................................................................................... 5-35
Menu Member Syntax ........................................................................................................ 5-35
Parameters.......................................................................................................................... 5-35
Format Members...................................................................................................................... 5-39
Client Programs....................................................................................................................... 5-39
Program Input.......................................................................................................................... 5-40
Execution Process .................................................................................................................... 5-40
Client Program Linkage Conventions .................................................................................... 5-40
Considerations for When CONTROL-M and CONTROL-O Are Installed..................... 5-41
CONTROL-O/CICS Interface .................................................................................................. 5-42
CONTROL-O Interface for the CICS Environment............................................................... 5-42
CONTROL-O/IMS Interface..................................................................................................... 5-43
Operating the CONTROL-O/IMS Interface ........................................................................... 5-43
CONTROL-O/IMS Commands................................................................................................ 5-43
Starting CONTROL-O Communication Support (CTOGATE)............................................... 5-44
Displaying a List of All Active Users...................................................................................... 5-44
General
Starting CONTROL-O
CONTROL-O is usually started at an early stage of the IPL process. Once initialized,
CONTROL-O can automate certain parts of the IPL process. To use CONTROL-O for automating
parts of the IPL process, member COMMNDnn (where nn is either the number specified in
member IEASYS in SYS1.PARMLIB, or 00) in the SYS1.PARMLIB library should contain
command:
S CONTROLO,SUB=MSTR,OUTLIST=DUMMY[,ORDER=IPLRULES][,TYPE=IPL]
Parameters SUB=MSTR and OUTLIST=DUMMY are necessary to start CONTROL-O
before JES has been brought up. Parameters ORDER and TYPE are optional. For more
information about these parameters and how/when CONTROL-O should be started, see
Recommended Organization Method later in this section.
If you do not plan to use CONTROL-O to automate the IPL process, CONTROL-O can still
be started during IPL, after JES has been brought up, by adding the following command to
member COMMNDnn in the SYS1.PARMLIB library:
S CONTROLO
It is also possible to manually issue the above mentioned operator commands.
Notes CMEM users:
If CONTROL-M is installed, CONTROL-O assumes responsibility for the functions of
the CMEM facility. Therefore, it is important to verify that the CMEM monitor
(CTMCMEM) is down before the CONTROL-O procedure is started.
For sites with CMEM rules that are to be implemented (triggered) in the early stages of
the IPL process, command member COMMNDnn in SYS1.PARMLIB should contain
command:
S CONTROLO,SUB=MSTR,OUTLIST=DUMMY[,ORDER=IPLRULES][,CMORDER=IOAIPLCM][,TYPE=IPL]
For more information about the parameters in the above statement and how/when
CONTROL-O should be started, see Recommended Organization Method later in this
section.
Shutting Down CONTROL-O
It is usually not necessary to shut down CONTROL-O. However, if shutting down
CONTROL-O becomes necessary, it is recommended that the active CONTROL-O monitor be
replaced by starting a new CONTROL-O monitor. See Replacing an Active CONTROL-O
Monitor below.
It is possible to shut down CONTROL-O with operator command F CONTROLO,STOP or
P CONTROLO, but this is not recommended. Use an operator command to shut down
CONTROL-O only if a problem cannot be resolved by the replacement method. If operator
command F CONTROLO,STOP or P CONTROLO is used, CONTROL-O shuts down after a
few seconds.
Note CMEM users:
When CONTROL-O is shut down, the CMEM facility is also shut down. To restart
CONTROL-O CMEM support after CONTROL-O has been completely shut down, issue
operator command: S CONTROLO,TYPE=CTOCMEM
Replacing an Active CONTROL-O Monitor
When a CONTROL-O monitor is started via operator command S CONTROLO and a
CONTROL-O monitor is already active in the computer, the current CONTROL-O monitor
passes control to the new CONTROL-O monitor and then shuts down. It is not necessary to
reload the rule tables; they are passed from the current monitor to the new one. To clean
(erase) all CONTROL-O tables from memory, shut down the CONTROL-O monitor. This is
not usually done, except in an emergency.
Replacing the Active CONTROL-O Executor Module (CTOWTO)
When the active CONTROL-O monitor is replaced, most CONTROL-O modules are
automatically reloaded. If maintenance is supplied for the CONTROL-O executor module
(CTOWTO), this module must be reloaded as well.
To reload module CTOWTO, use operator command:
F CONTROLO,RELOAD=CTOWTO
Replacing the Active CMEM Executor Module (CTOAIDT)
When the active CONTROL-O monitor is replaced, most CONTROL-O modules are
automatically reloaded. If maintenance is supplied for the CMEM executor module
(CTOAIDT), this module must be reloaded as well.
To reload module CTOAIDT, use operator command:
F CONTROLO,RELOAD=CTOAIDT
Note All of the CONTROL-O modify commands and their parameters are listed in Appendix H.
Rule Types
In CONTROL-O there are two types of rules:
CONTROL-O rules that are created using the CONTROL-O Rule Definition screen
(option OR in the IOA Primary Option menu).
CMEM rules which were created from ONSPTAB by utility CTM2RULE or via the
CMEM Rule Definition screen (option C in the IOA Primary Option menu).
CMEM rules can contain only the following types of statements: ON JOBARRIV, ON
JOBEND, ON DSNEVENT, ON STEP, DO FORCEJOB, DO COND, DO RESOURCE, and
DO STOPJOB. CMEM rules can also contain DO SHOUT and DO RULE statements if
CONTROL-O is installed.
CMEM tables cannot contain CONTROL-O rules (i.e., rules which contain statements
other than the types listed above).
The type of table (CONTROL-O vs. CMEM) is determined by the way in which the table is
loaded:
CMEM rules are:
Loaded from DACTMLST
Ordered/Forced from the CMEM Rule Definition screen (screen C)
Loaded via modify command F CONTROLO,C=LIB(table)
CONTROL-O rules are:
Loaded from DARULLST
Ordered/Forced from the CONTROL-O Rule Definition screen (screen OR)
Loaded via modify command F CONTROLO,O|F=LIB(table)
If a rule is rejected because it is not compatible with the method used to load it, the
following message is issued to the SYSPRINT SYSOUT of the CONTROL-O monitor:
LDT54DE RULE TYPE IS INCORRECT. TABLE table LIBRARY library
When CONTROL-O loads a table, it only replaces tables of the same type. To change the
type of a table, the table must be deleted and loaded again.
Example
If table A is loaded as a CMEM table, it cannot be reloaded as a CONTROL-O table. To
load table A as a CONTROL-O table, first delete table A by issuing operator command
F CONTROLO,D=LIB(A)
For more information, see Rule Loading Errors Related to Type of Table later in this
section.
Automatic Loading of Rules
When CONTROL-O is started, and it is not replacing an active CONTROL-O monitor, it
attempts to read a list of rule tables from the member referenced by DD statement
DARULLST. These are the rule tables to be automatically loaded by CONTROL-O. The
name of the member can be passed in the CONTROL-O procedure parameter ORDER. The
supplied default member RULELIST is in the CONTROL-O PARM library. Each line in the
list has the following format:
date library table {FORCE|NOFORCE|ORDER}
where:
date Date of the rule. If a specific date is designated, it is used to analyze
the Basic Scheduling parameters (see below). The date format is
mmddyy, ddmmyy, or yymmdd (depending on the site standard).
An asterisk (*) can be specified to indicate the current CONTROL-O
working date.
For every line in the list, CONTROL-O loads the specified rule table from the specified library.
If either NOFORCE or ORDER is specified, each rules Basic Scheduling parameters are
compared to the specified date, or the current CONTROL-O working date if * has been
specified. If the rule should be scheduled on that date, the rule is loaded by CONTROL-O
and activated.
If FORCE or no option is specified, each rule is loaded by CONTROL-O and activated. Use
this option when you do not wish to use CONTROL-O scheduling options.
Notes CMEM users:
When CONTROL-O is started (and it is not replacing an active CONTROL-O monitor),
it attempts to read the member referenced by DD statement DACTMLST. This member
lists the CMEM rule tables to be automatically loaded by CONTROL-O.
The name of the member containing the list of CMEM rule tables can be passed in
parameter CMORDER of the CONTROL-O procedure. The default member for the
CMEM list is member IOACMEML in the IOA PARM library.
Manual Loading of Rules
Member RULELIST contains a list of basic rule tables to be activated by CONTROL-O as it
is started. To load additional tables, or to replace a currently active table with a new
(updated) copy of the rules in the table, use one of the following options:
Option 1
Enter the CONTROL-O Online facility and use the ORDER/FORCE option in the Table
List screen (screen OR).
Option 2
F CONTROLO,{O|F}=library(table)[,D=date]
where:
O Order. Each rules Basic Scheduling parameters are compared to the
specified date. If the rule should be scheduled on that date, the rule is
loaded by CONTROL-O and activated.
F Force. Each rule is loaded by CONTROL-O and activated, regardless
of Basic Scheduling parameters. Use this option when you do not want
to use CONTROL-O scheduling options.
date Scheduling date (optional). If no date is specified, the CONTROL-O
working date is used. Date format is mmddyy, ddmmyy, or yymmdd
(depending on the site standard).
Examples
F CONTROLO,F=CTO.PROD.RULES(CICSPROD)
Loads table CICSPROD from CTO.PROD.RULES.
F CONTROLO,F=CTO.PROD.RULES(*)
Loads all tables from CTO.PROD.RULES.
F CONTROLO,F=CTO.PROD.RULES(PROD*)
Loads tables whose names start with PROD from CTO.PROD.RULES.
F CONTROLO,F=CTO.PROD.RULES(?CICS*)
Loads tables whose names start with any character followed by the string CICS from
CTO.PROD.RULES.
If the table has already been loaded by CONTROL-O, the new copy of the table replaces all
the rules of the table active under the CONTROL-O monitor.
If you wish to replace all the tables under CONTROL-O with the list of tables specified in
DD statement DARULLST, use operator command:
F CONTROLO, O|F=ALL [,REBUILD]
Notes When ALL is specified, each table is ordered or forced according to its
FORCE/NOFORCE specification in the rule list as defined in DD statement
DARULLST.
When the REBUILD option is specified, all previously loaded rules are deleted. This
option should be specified when using calendar-dependent rules.
If the REBUILD option is not specified, previously loaded rules are either replaced by
new copies of the rules or left unchanged.
The CMEM table is reloaded automatically when ALL is specified.
Manual Loading of CMEM Rules
The member referenced by DD statement DACTMLST during startup contains a list of
CMEM rule tables to be automatically ordered by CONTROL-O when it is started.
To load additional tables, or to replace a currently active table with a new (updated) copy,
use one of the following options:
Option 1
Enter the CMEM Online facility (=C), and use the FORCE option in the Table List screen.
Option 2
F CONTROLO,C=library(table)
where:
C Indication that CMEM rules are to be loaded. Each CMEM rule in the
specified table(s) is ordered by CONTROL-O and activated.
Examples
F CONTROLO,C=CTM.CMEM.RULES(DATASET)
Loads table DATASET from CTM.CMEM.RULES.
F CONTROLO,C=CTM.CMEM.RULES(*)
Loads all tables from CTM.CMEM.RULES.
F CONTROLO,C=CTM.CMEM.RULES(BKP*)
Loads tables whose names start with BKP from CTM.CMEM.RULES.
F CONTROLO,C=CTM.CMEM.RULES(?CICS*)
Loads tables whose names start with any character followed by the string CICS from
CTM.CMEM.RULES.
If a specified CMEM table has already been loaded by CONTROL-O, the new copy of the
CMEM table replaces all the rules of the table active under the CONTROL-O monitor.
The following operator command affects CMEM rules as well as CONTROL-O rules:
F CONTROLO,O|F=ALL[,REBUILD]
This command affects CMEM rules in the following way:
When ALL is specified, all CMEM rule tables defined in the CMEM list member
referenced by DD DACTMLST are reloaded.
When REBUILD is specified, all previously loaded CMEM rules are deleted as well as
the CONTROL-O rules.
If REBUILD is not specified, previously loaded CMEM rule tables are either replaced
by new copies or left unchanged.
Deleting (Deactivating) an Active Rule Table
To deactivate an active rule table, use an operator command. For example:
F CONTROLO,D=CTO.PROD.RULES(CICSPROD)
A single rule can also be deleted/held using appropriate line commands in the Rule Status
screen.
Rule Loading Errors Related to Type of Table
When loading CMEM or CONTROL-O rule tables, error message LDT54DE will be issued
when:
loading a CMEM table that contains one or more CONTROL-O rules.
loading a CMEM table as a CONTROL-O rule table.
loading a CONTROL-O rule table as a CMEM table.
These errors and the corrective action that should be taken are described in more detail
below. If one of these errors occurs, the specified table will be rejected and the following
error message will be issued to the SYSPRINT SYSOUT of the CONTROL-O monitor:
LDT54DE RULE TYPE IS INCORRECT. TABLE tablname LIBRARY libname.
where:
tablname Name of the rule table.
libname Name of the library where the table resides.
Rule Loading Errors
Loading a CMEM table that contains one or more CONTROL-O rules
CMEM tables can only have rules which contain the following types of statements: ON
JOBARRIV, ON JOBEND, ON DSNEVENT, ON STEP, DO FORCEJOB, DO COND,
DO RESOURCE, and DO STOPJOB. If CONTROL-O is installed, CMEM tables can
also have rules which contain DO SHOUT and DO RULE statements.
If a user loads a CMEM table that has a rule which contains an invalid statement type,
an error will occur. To resolve the error, the user must either:
remove the invalid rule from the CMEM table and reload the CMEM table.
-or-
delete the table from CONTROL-O, then reload the table as a CONTROL-O rule
table via the CONTROL-O Rule Definition screen (option OR on the IOA Primary
Options menu), or via modify command F CONTROLO,O|F=LIB(table)
Loading a CMEM table as a CONTROL-O rule table
CMEM tables are created via the CMEM Rule Definition screen (option C in the IOA Primary
Options menu). When they are loaded into CONTROL-O, they are identified as CMEM tables.
To load the rules in a CMEM table as a CONTROL-O rule table, delete the CMEM table
from CONTROL-O and reload the table as a CONTROL-O rule table.
Note Although CMEM rules can be executed from CONTROL-O rule tables, these rules must
be reloaded as CONTROL-O rule tables.
Loading a CONTROL-O rule table as a CMEM table
CONTROL-O rule tables are created via the CONTROL-O Rule Definition screen
(option OR in the IOA Primary Options menu). When they are loaded into
CONTROL-O, they are identified as CONTROL-O rule tables.
If a CONTROL-O rule table contains only statements which are valid as CMEM rules
(see above), that table can be loaded as a CMEM table by deleting the CONTROL-O
rule table from CONTROL-O and reloading the table as a CMEM table.
Reloading Rule Tables
Reloading a CMEM table as a CONTROL-O rule table:
Delete the CMEM table from CONTROL-O.
Reload the rule table from the library via the CONTROL-O Rule Definition screen
(option OR in the IOA Primary Options menu) or via modify command
F CONTROLO,O|F=LIB(table)
Reloading a CONTROL-O rule table as a CMEM table:
Delete the table from CONTROL-O.
Reload the rule table from the library via the CMEM Rule Definition screen (option C
in the IOA Primary Options menu) or via modify command F CONTROLO,C=LIB(table)
Virtual Storage Requirements of the CONTROL-O
Monitor
CONTROL-O monitor procedure CONTROLO is supplied with a default region size of
5 MB. The region size can optionally be increased to a maximum of 2 GB.
Calculating Region Size
The items described below should be included in your calculation of the amount of virtual
storage needed by the CONTROL-O monitor:
Block size of the IOA Conditions/Resources file, specified in parameter RESLREC in
member IOAPARM. See Appendix D: Structure of the IOA Conditions/Resources File
in the IOA Installation Guide for information about how to calculate this block size.
Number of records in the Message Statistics file, specified in parameter STREC# in
member CTOPARM.
The monitor loads the used records of the Message Statistics file into virtual storage.
Each entry of the Message Statistics file requires 100 bytes. For example, if there are
5000 entries in the Message Statistics file, the CONTROL-O monitor needs a maximum
of 500 K of virtual storage to load the necessary records.
CONTROL-O monitor working buffers require approximately 750 K of virtual storage.
CONTROL-O monitor software requires approximately 500 K of virtual storage,
depending on the environment and the functions used.
Site-defined work areas and programs (e.g., user exits). These items usually require a
small amount of virtual storage. Therefore, it is usually not necessary to calculate the
requirements of site-defined components precisely. However, it is important that you
allow some storage space for these components.
Note It is recommended that you specify a larger than necessary region size to ensure
sufficient storage space for CONTROL-O and related MVS activities.
Example
At a site with:
A block size (RESLREC) of 32760 for the IOA Conditions/Resources file.
One slot per block (RESREC#).
5000 records in the Message Statistics file.
Site defined components requiring approximately 0.20 MB of virtual storage.
Calculate virtual storage for the CONTROL-O monitor as follows:
IOA Conditions/Resources file 1.10 MB (32,760 * 32 * 1) + 64 K
CONTROL-O software 0.50 MB
Message Statistics file 0.50 MB
CONTROL-O working buffers 0.75 MB
Site Defined components 0.20 MB
Extra space for MVS activities 0.20 MB
________
Total 3.25 MB
Troubleshooting
MVS allocates the region size specified for the CONTROL-O monitor unless a local exit
(e.g., IEALIMIT, IEFUSI, or another MVS or JES exit) is used to limit the region size of
jobs and/or started tasks at the site.
Message IEF374I in the third SYSOUT of the CONTROL-O monitor indicates the amount
of virtual storage used by the CONTROL-O monitor. Compare the information in this
message with the existing region size definition.
If sufficient virtual storage is not available for the CONTROL-O monitor, use on-site
performance tools to determine if the specified region size was rejected by MVS (e.g., via a
local exit).
If MVS accepted the specified region, recalculate the CONTROL-O monitors virtual
storage requirements, as shown above, and modify the region size in the EXEC
statement of the CONTROL-O monitor procedure accordingly.
If an MVS procedure rejected the specified region size, consult your system
administrator.
Storage Allocation
At start-up time, the CONTROL-O monitor allocates working storage. CONTROL-O can
allocate virtual storage above the 16 MB line. The decision as to whether to allocate above
or below the 16MB line is made by MVS (which considers the specified job, the amount of
requested storage, MVS exits, etc.).
Structure of the IOA Conditions/Resources File
See Appendix D of the IOA Installation Guide for information about the structure and
space requirements of the IOA Conditions/Resources file.
CONTROL-O Usage of the Common Storage Area
(E/CSA)
CONTROL-O receives control of a message/command under the user TCB (i.e.,
CONTROL-O acts as part of the job that issued the message/command). Therefore,
CONTROL-O allocates storage from the Extended Common Storage Area (ECSA).
Due to MVS Services requirements, only a small part of the Common System Area (CSA) is
used by CONTROL-O.
Use the information below to calculate CONTROL-O ECSA and CSA storage requirements.
Extended CSA Usage (Above the 16M Line)
The following CONTROL-O components use Extended CSA:
Subsystem
executor
160 K
Wait
elements
160 K Each element requires 8 K. The number of elements is specified via
parameter WAITPR# in member CTOPARM. For example, 20
elements would require 160 K.
Work
Buffers
105 K If the system on which CONTROL-O is working has only one or two
CPUs, a minimum of 105 K is required. If the system has three or
more CPUs, each CPU requires 30 K.
Rules 50 K This amount assumes 500 rules and an average of 100 bytes per
rule.
______
Total 475 K
Note Converting the CMEM ONSPOOL table to a CMEM rule table can create thousands of
rules in the new table. (Each entry of CTMEVENT becomes a CMEM rule.) If old
CMEM definitions were converted at your site, modify the above calculation to include
a suitably larger amount of storage for CONTROL-O rules.
CSA Usage (Below the 16M Line)
SWT and other system control blocks 1.5 K
Dataset triggering executor 30.0 K
OpenEdition Interface 7.0 K
Total 38.5 K
Recommended Organization Method
CONTROL-Os primary function is to automate console operation. An especially important
use of CONTROL-O is the automation of system startup (IPL). The recommended
CONTROL-O organization method for automating the IPL process is described below. If
you do not automate the IPL process, CONTROL-O organization is simplified because
certain MVS-related restrictions need not be addressed. In this case, skip directly to Rule
Scheduling later in this section.
System Definitions
The IOA subsystem name, as defined in IOA Installation parameter SUBSYS, should
appear as the first subsystem name after the primary subsystem in the subsystem list
(member IEFSSNnn in SYS1.PARMLIB). This enables CONTROL-O to control
commands directed to other MVS subsystems before they are executed by these
subsystems. However, to control JES commands before they are executed by JES,
CONTROL-O uses JES exits or an additional subsystem name, defined optionally in the
CONTROL-O installation parameters. See parameter JCMDSSN under Specify
CONTROL-O Parameters in Section 7 of the IOA Installation Guide for more
information.
Notes MVS 5.2 users:
The subsystem name can be defined by using positional parameter IEFSSNnn (described
above) or by using the keyword parameter form of the IEFSSNnn PARMLIB member.
When using the keyword parameter form, add a record to member IEFSSNnn in the
format:
SUBSYS SUBNAME(xxxx)
where xxxx is the name of the subsystem specified in IOA installation parameter SSNAME.
See the MVpS/ESA SP 5.2 Initialization and Tuning Reference Manual for more
information.
The CONTROL-O procedure must reside in the SYS1.PROCLIB library.
The CONTROL-O monitor should be started at an early stage of IPL. To do this,
member COMMNDnn in the SYS1.PARMLIB library (where nn is either the number
specified in member IEASYS in the same library, or 00) should contain the following
command as one of the first commands in the member:
COM=S CONTROLO,SUB=MSTR,OUTLIST=DUMMY
Note CMEM users:
Member COMMNDnn in SYS1.PARMLIB should contain the following command:
COM=S CONTROLO,SUB=MSTR,OUTLIST=DUMMY[,ORDER=IPLRULES]
[,CMORDER=IOAIPLCM][,TYPE=IPL]
The following CONTROL-O and IOA files are allocated to the CONTROL-O monitor:
IOA LOAD library
IOA Conditions/Resources file and its Synchronization file
Calendar library
PARM library
Message Statistics file (dynamically allocated)
Rules library (dynamically allocated)
Automation Log file (dynamically allocated)
Global Variables library (dynamically allocated)
Because CONTROL-O is started as part of IPL, you should either catalog all these files
in the MVS Master Catalog, or specify the VOLSER and UNIT parameters for each of
the files. The dynamically allocated files (e.g., the Message Statistics file) must be in
the Master catalog.
If you specified parameters VOLSER and UNIT for these files and you move the files to
another disk, you must modify the CONTROL-O procedure as well.
It is recommended that CONTROL-O start and control the initialization of other
system components (JES, VTAM, TSO, etc.).
The on-site enqueue manager must be up before any attempt is made by CONTROL-O
to update an IOA file. See the description of parameter QNAME in Section 2 and the
description of parameter CTOQNAM in Section 7 of the IOA Installation Guide for
more information.
Use of Two Rule List Members
Parameter ORDER of the CONTROL-O monitor specifies the name of a member containing
the list of rules to be loaded by CONTROL-O upon startup. The easiest organization
method is using one list member containing all CONTROL-O tables (e.g., the supplied
member RULELIST). This is the preferred method when CONTROL-O will not control IPL.
However, if CONTROL-O will control IPL, it should be organized somewhat differently.
As your sites use of CONTROL-O expands, it is possible that hundreds of operations rules
will be defined. Loading all of these operation rules may take time. CONTROL-O does not
start to analyze messages until it has finished loading all rules in the initialization rule
list. Consequently, if the list is quite large, CONTROL-O may not detect some of the
messages and commands issued during the beginning of the IPL process.
To ensure analysis of all messages, it is recommended to place all rules which control the
IPL process in a separate list. This list is loaded when CONTROL-O is started by
overriding the default list member name using parameter ORDER to designate member
IPLRULES. Member IPLRULES should contain only the rule tables to be used during IPL.
One of the rules in this member should load the remaining CONTROL-O rule tables.
Multiple Rule Table Lists for CMEM Rules
Parameter CMORDER specifies the name of the member which contains the CMEM list,
i.e., the list of CMEM rule tables to be loaded by CONTROL-O upon startup. It is usually
recommended that you list all CMEM rule tables in one list. The default name for the
member containing this list is IOACMEML. However, as described below, it is sometimes
recommended that you list certain rule tables separately.
CONTROL-O does not start to analyze CMEM events until it has finished loading all rule
tables in the CMEM list specified via parameter CMORDER. If a large number of rules
have been defined at your site, CONTROL-O may not detect some CMEM events during
the beginning of the IPL process.
To ensure detection of all CMEM events, it is recommended that you place CMEM rules to
be triggered during the IPL process in a separate list in member IOAIPLCM, and that you
specify this list via parameter CMORDER. Rule tables specified in this way are loaded and
activated during the startup process.
Replacing the IPL CONTROL-O
Operation of CONTROL-O involves processing phases which are implemented by starting
separate CONTROL-O monitors, each one replacing the previous one.
Phase 1: When CONTROL-O is activated with SUB=MSTR during IPL, certain
functions, particularly the debugging facilities, are inactive. This is
because JES is not yet initialized and it is impossible to allocate a
sysout file. For this reason, CONTROL-O is started with parameter
OUTLIST=DUMMY.
Phase 2: A simple CONTROL-O rule can detect the JES initialization message
and then restart CONTROL-O without parameters. Table STARTSYS
contains a sample rule that does this. The new CONTROL-O
automatically takes control from the previous CONTROL-O used
during IPL. It is not necessary to reload the rules.
Phase 3: If CONTROL-O controls the termination of JES, a third CONTROL-O
monitor, which does not allocate sysout files, is required during
shutdown of the system. This third CONTROL-O monitor should be
started by a rule containing parameters SUB=MSTR and
OUTLIST=DUMMY.
Parameter TYPE of operator command START CONTROLO enables you to specify the
CONTROL-O processing phase for a specific monitor. Valid values for this parameter are:
IPL The CONTROL-O monitor controls the IPL process.
REGULAR The CONTROL-O monitor is a regular CONTROL-O monitor.
SHUTDOWN The CONTROL-O monitor controls the shutdown of the system.
The CONTROL-O TYPE appears in the following initialization message:
CTO147I CONTROL-O INITIALIZATION COMPLETE,TYPE=type,SUB=job-entry-subsystem
This message can be used by CONTROL-O rules whenever phase-dependent processes are
handled.
Notes When CONTROL-O is brought up to replace an existing CONTROL-O monitor, it does
not load rules from DD statement DARULLST. Instead, it takes control of the rules
which were active under the previous CONTROL-O monitor. Only a new operator
command F CONTROLO,O=ALL loads the rules from DARULLST.
CMEM Users:
This note also applies to CMEM rules loaded from DD statement DACTMLST.
Rule Scheduling
CONTROL-O is usually started at an early stage of IPL and remains active until
shutdown. Most rules behave the same on any date. However, it is sometimes necessary to
schedule different rules for different dates. For example, you may want to trigger one
response to a certain message on a regular working date and a different response to the
same message on the first day of a month.
Under CONTROL-O, you can define scheduling parameters for rules. For example, a rule
can be scheduled for a specific date only. The scheduling criteria of rules are checked when
a rule is ordered (either automatically or manually).
If a rule is subject to scheduling criteria, these criteria should be checked on a daily basis
and the rule loaded and activated only if it should be scheduled according to its scheduling
criteria. It is recommended that rules be reloaded on a daily basis using a time-initiated
command (rule) which issues the following order command for all CONTROL-O tables at a
specified time of day:
F CONTROLO,O=ALL,REBUILD
Displaying Active Rules
The Rule Status screen displays a list of all rules which have been ordered and their
statuses. The displayed rules can be held/deleted/freed. Alternatively, enter operator
command
F CONTROLO,DISPLAY
The list is sent to the console.
Management of CONTROL-O Facilities
The following pages contain descriptions of commands and considerations for managing
various CONTROL-O facilities and components. The following topics are included:
Message Statistics Facility
Automation Log Facility
CONTROL-O Status Monitoring System (COSMOS)
Rule Operation Mode
Global AutoEdit Variables
CONTROL-O Sleeping Interval
CONTROL-O Security Cache
Controlling the Message Statistics Facility
The Message Statistics facility allows accumulation and display of statistics for the
messages/commands issued by the system on which CONTROL-O is active.
The Message Statistics facility counts messages and commands by message/command ID.
Each time a message or command appears, the counter for the corresponding entry in the
Statistics file is incremented. When a new message ID or %%$STATID value is detected, a
new entry is opened in the Statistics file.
Statistics accumulation is normally started automatically when CONTROL-O is brought
up. However, when necessary, accumulation of statistics can be controlled by the following
operator commands:
1. Stop statistics accumulation:
F CONTROLO,STOPSTAT
This command can be used if statistical accumulation is no longer required or if it
becomes necessary to reformat the Statistics file without bringing down CONTROL-O.
2. Start statistics accumulation:
F CONTROLO,STARTSTAT
3. Reset statistics for all messages and commands:
F CONTROLO,RESETSTAT
Preventing Unnecessary Enlargement of Statistics Files
The Message Statistics facility counts messages and commands by message/command ID.
The first word of the message/command is the message/command ID.
To prevent the Statistics files from becoming too large and to eliminate duplicate
information, it might be desirable to group messages or commands according to other
criteria. It would be useful, for example, to group messages/commands under one
message/command ID when:
Messages start with free text. Accumulating each of these messages under a different
message ID, enlarges the size of the Statistics file and may prevent the accumulation of
meaningful statistics for the message.
Concatenation of JES2 commands with different operands results in separate statistics
accumulation for each operand. For example, statistics for $PJ05555 and $PJ01234 are
normally accumulated under different IDs even though both IDs refer to the same
command.
Separate statistics are accumulated for messages which are not of interest to the user.
AutoEdit reserved variable %%$STATID can be used to specify the ID under which the
messages/commands are accumulated. For example:
ON COMMAND $P*
DO SET %%$STATID=$P
Rule table STATS from the RULES library has been provided to perform the necessary
grouping by %%$STATID. This table can be adapted/used according to site requirements.
Handling Near-Full and Full Conditions for the Statistics File
When the Statistics file becomes more than 90% full, CONTROL-O issues unrollable
message CTO240W as a warning.
When CONTROL-O detects that the Statistics file is full, it issues unrollable message
CTO241E. CONTROL-O then stops tracking statistics for new messages but continues to
update the counters of messages already in the Statistics file.
If message CTO240W or CTO241E is issued, it is recommended that the operator enlarge
the Statistics file via utility CTOCSF and check if messages can be grouped by
%%$STATID (as described above).
Controlling the Automation Log Facility
The Automation Log facility allows accumulation and display of automation information
from all inputs available to CONTROL-O.
The Automation Log facility is started automatically when parameter AUTOMLOG in member
CTOPARM is set to V or D. (Refer to the CONTROL-O section in the IOA Installation Guide.)
While CONTROL-O is active, the Automation Log facility is controlled by the following
operator commands:
1. Stop Automation Log accumulation:
F CONTROLO,AUTOLOG=NO
This command can be used when the Automation Log is no longer required or when it
becomes necessary to reformat or rebuild the Automation Log file without bringing
down CONTROL-O. Message CTO297I indicates that Automation Log accumulation
has stopped.
The Automation Log can be viewed via screen OL, even when CONTROL-O is inactive
or Automation Log accumulation has been stopped.
2. Start Automation Log accumulation:
F CONTROLO,AUTOLOG=YES
Message CTO297I indicates that Automation Log accumulation has started.
Note When the Automation Log is not active, CONTROL-O trace messages are written to
the SYSOUT specified by DD statement DAACTLOG of the CONTROL-O monitor.
Determining the Size of the Log
The Automation Log is a wrap-around dataset, which means that the number of records in
the file is constant and, when the file is full, a new record overwrites the oldest record.
Automation Log entries can be archived/backed up for subsequent retrieval using utility
CTOALOCP (described in Section 9 of this guide).
If backup is performed on a regular basis, the Automation Log should be large enough to
prevent overwriting record that have not been backed up. The size of the Automation Log
is specified in installation parameter ALREC#. The backup frequency depends on site
requirements.
Preventing Logging of Unnecessary Messages
Some messages may be of little interest. The amount of unnecessary information on the
Automation Log can be minimized by not writing these messages to the Automation Log.
System AutoEdit variable %%$AUTOLOG can be used to control which messages are
entered into the Automation Log. Valid values:
Y (Yes) Record the message in the Automation Log.
N (No) Do not record the message in the Automation Log.
Example
Prevent messages whose ID starts with TST from being written to the Automation Log.
ON MESSAGE TST*
DO SET %%$AUTOLOG=N
Management of the CONTROL-O Status Monitoring System
(COSMOS)
The CONTROL-O Status Monitoring System (COSMOS) is used to monitor the status of
objects in the computing environment. When activated, COSMOS ensures that specified
objects are maintained in their specified desired status.
COSMOS should normally be activated as part of the CONTROL-O startup process.
While CONTROL-O is active, the following commands can be used to control COSMOS
operations:
COSINI Starts up the COSMOS facility.
COSTERM Shuts down the COSMOS facility.
COSBOUNZ Recycles the COSMOS facility by bringing it down and then restarting
it. This command also reloads all COSMOS databases, thus refreshing
variables used during COSMOS operations.
COSUP Assigns all COSMOS-controlled objects a desired status of UP.
COSDOWN Assigns all COSMOS-controlled objects a desired status of DOWN.
For more information about these and other COSMOS commands, see Section 2 of the
CONTROL-O/COSMOS User Manual.
Controlling Rule Operation Mode
The mode of operation (i.e., the trace mode) for a rule is determined by parameter MODE
in its rule definition. Sometimes it is useful to override the operation mode of all active
rules and verify that events and actions are recorded in a particular way. For example:
Ensure a full trace of all rules (i.e., all events and actions are recorded) to facilitate
analysis of the interaction between rules.
Record (trace) only the triggering of every rule.
Global trace operations are requested via the following operator commands:
1. Activate a full trace:
F CONTROLO,LOG=ALL
All rules are fully traced as if they were defined with mode LOG. This operator
command should only be used temporarily for specific tests because extended use of full
trace mode can adversely affect CONTROL-O performance.
2. Trace rule triggering only:
F CONTROLO,LOG=TRIGGER
Only rule triggering is traced for all rules. However, rules defined with mode LOG are
fully recorded.
3. Restore the default operation mode (as defined in the rule definition) for each rule:
F CONTROLO,LOG=DEFAULT
Controlling OpenEdition (UNIX for MVS) Support
Starting with OS/390 version 2.4, IBM introduced major changes and enhancements to the
OpenEdition (UNIX for MVS) environment. As a result, some applications, such as FTP,
stopped issuing allocation and de-allocation messages to the JESYSMSG spool dataset.
CONTROL-O provides a special interface to support dataset-triggering events originating
from OpenEdition with OS/390 version 2.4 and above. CONTROL-O automatically
determines if the OpenEdition interface should be installed and no user action is required.
The OpenEdition interface is shared by all CONTROL-O installations at the site and is
version independent. The first CONTROL-O subsystem to initialize loads the OpenEdition
interface module to common storage. This interface is later used by all other CONTROL-O
subsystems. Upon startup, every CONTROL-O subsystem registers itself with the
OpenEdition interface. This registration mechanism enables the OpenEdition interface to
recognize all the available CONTROL-O subsystems and to call them if an OpenEdition
dataset-triggering event occurs.
When a CONTROL-O subsystem shuts down, it unregisters itself from the OpenEdition
interface. The last CONTROL-O subsystem to shut down removes the OpenEdition
interface from common storage.
The following sequences of messages indicate that the OpenEdition interface was
successfully installed:
For the first CONTROL-O subsystem to initialize:
CTO780I INITIALIZATION OF OPENEDITION ENVIRONMENT STARTED
CTO781I OPENEDITION INTERFACE MODULE SUCCESSFULLY LOADED
CTO782I SUBSYSTEM REGISTERED WITH OPENEDITION INTERFACE
CTO783I INITIALIZATION OF OPENEDITION ENVIRONMENT ENDED SUCCESSFULLY
For any subsequent CONTROL-O subsystem:
CTO780I INITIALIZATION OF OPENEDITION ENVIRONMENT STARTED
CTO782I SUBSYSTEM REGISTERED WITH OPENEDITION INTERFACE
CTO783I INITIALIZATION OF OPENEDITION ENVIRONMENT ENDED SUCCESSFULLY
The following sequences of messages indicate that the OpenEdition interface was
successfully deactivated:
For any CONTROL-O subsystem except from the last subsystem to shut down:
CTO790I DEACTIVATION OF OPENEDITION ENVIRONMENT STARTED
CTO791I SUBSYSTEM UNREGISTERED FROM OPENEDITION INTERFACE
CTO793I DEACTIVATION OF OPENEDITION ENVIRONMENT ENDED SUCCESSFULLY
For the last CONTROL-O subsystem to shut down:
CTO790I DEACTIVATION OF OPENEDITION ENVIRONMENT STARTED
CTO791I SUBSYSTEM UNREGISTERED FROM OPENEDITION INTERFACE
CTO792I OPENEDITION INTERFACE MODULE REMOVED
CTO793I DEACTIVATION OF OPENEDITION ENVIRONMENT ENDED SUCCESSFULLY
CONTROL-O enables the operator to start and stop the OpenEdition interface using the
Modify operator command. Usually, there is no need to intervene with the default
processing performed by CONTROL-O. The following operator commands are available:
F CONTROLO,STARTOE
F,CONTROLO,STOPOE[,FORCE]
The STARTOE command instructs a CONTROL-O subsystem to restart the OpenEdition
interface. This includes initializing the interface (if no other subsystem has initialized it)
and/or registering the current subsystem with the OpenEdition interface. If the STARTOE
command is issued for a subsystem that is already registered with the OpenEdition
interface, the following message is generated:
CTO788I SUBSYSTEM ALREADY REGISTERED WITH OPENEDITION INTERFACE
The STOPOE command instructs a CONTROL-O subsystem to deactivate the OpenEdition
interface. This includes unregistering the current subsystem from the OpenEdition
interface and removing the OpenEdition interface from common storage if no other
subsystem is using it. If the STOPOE command is issued for a subsystem which is not
registered with the OpenEdition interface, the following message is generated:
MTO796W SUBSYSTEM NOT UNREGISTERED FROM OPENEDITION INTERFACE: SUBSYSTEM NOT
FOUND
If the STOPOE command is issued when the OpenEdition interface is not installed, the
following message is issued:
MTO795W OPENEDITION INTERFACE MODULE NOT INSTALLED
The STOPOE,FORCE command instructs CONTROL-O to remove the OpenEdition
interface from common storage even if one or more CONTROL-O subsystems are still
registered with it.
CONTROL-O also provides Started Procedure CTOOEDSC. This procedure can be started
from the console using the START command. Procedure CTOOEDSC acts like a
STOPOE,FORCE command and removes the OpenEdition interface regardless of any
registered subsystems. The STOPOE,FORCE command and procedure CTOOEDSC should
be used only in case of emergency.
Global AutoEdit Variables
Global AutoEdit variables can be supplied to CONTROL-O in Global members and in
AutoEdit variable databases.
When CONTROL-O is started, it reads the Global AutoEdit members and databases and
loads Global variables defined in those members and databases into memory. The list of
members and databases to be loaded is specified in DD statement DAGLBLST of the
CONTROL-O monitor procedure.
Global members and variable databases are managed in different ways. File configuration
for Global members and variable databases is described below.
Global Members
A different Global library (in which the Global members reside) is used for each computer
(SMF ID) on which CONTROL-O operates. The Global library name is composed of:
the prefix defined in CONTROL-O installation parameter GLBPREF
the Global identifier: .GLB.
the string CPU followed by the SMF ID of the specified computer.
Example: CTO.Vxxx.GLB.CPUSYSA.
Member $GLOBAL is usually the default Global member. This member contains
CONTROL-O Global AutoEdit variables that are not assigned to specific Global members.
The member format is identical to the format of a CONTROL-M AutoEdit variables
member. Therefore, CONTROL-O Global members can be referenced by CONTROL-M jobs
via MEMSYM and LIBSYM parameters.
Updates or additions to Global variables (by rules or KOA scripts) are kept in memory by
CONTROL-O and are available to all other rules. While CONTROL-O is active, Global
variables can be reloaded from, or written back to, the PDS (partitioned dataset) Global
library, in total or by member name, using operator commands LOADGLOBAL and
WRITEGLOBAL. When CONTROL-O is stopped, the Global variables are written back to
their respective PDS members.
Variable Databases
All variable databases are stored in a set of three IOA Access Method files allocated during
CONTROL-O installation:
Variable Database Definition file
Variable Database Columns file
Variable Database Variables file
For more information about the IOA Access Method, see Section 2 of this guide.
The variable database files are used to copy information into memory on each computer on
which CONTROL-O is working.
Updates and additions to variables in variable databases (by rules or KOA scripts) are kept
in memory by CONTROL-O and are available to all other rules. While CONTROL-O is
active, a specific variable database or all variable databases can be reloaded from or
written to the variable database files via operator commands LOADGLOBAL and
WRITEGLOBAL. When CONTROL-O is stopped, command WRITEGLOBAL is performed
to update all variable database files with the latest information.
Note AutoEdit Variable databases are not stored in partitioned datasets (PDS members)
and therefore cannot be accessed by CONTROL-M (i.e., via %%LIBSYM and
%%MEMSYM control statements).
Loading Global Variables
Use the following operator command to load Global variables from a Global member or
variable database into CONTROL-O memory:
F CONTROLO,LOADGLOBAL[=memname]
where memname indicates the Global members or variable databases to be loaded. Valid
values:
name Name of a specific Global member or variable database to be loaded.
ALL Load all Global members and variable databases listed in member
DAGLBLST.
If no memname value is specified with a LOADGLOBAL command, only member
$GLOBAL (i.e., the default Global member) is loaded.
Updating Global Variables
Use the following operator command to update Global members or variable database files
with the current status of the Global variables in memory:
F CONTROLO,WRITEGLOBAL[=memname]
where memname indicates the Global members or variable databases to be updated. Valid
values:
name Name of a specific Global member or variable database to be updated.
ALL Update all Global members and variable databases listed in member
DAGLBLST.
If no memname value is specified with a WRITEGLOBAL command, only member
$GLOBAL (i.e., the default Global member) is updated.
Note If command WRITEGLOBAL is used to update a variable database, only variables
that have been modified are written to the variable database files, enabling more
efficient use of computer resources.
Defining a New Global Member or Variable Database
Rules related to a specific application can use their own Global member or variable
database to isolate their variables from the rules of other applications, to enable the use of
checkpoints or to perform initializations on an application basis.
To define a new Global member, create a member in the GLB library and add its name
to the Global Member list (DAGLBLST).
To define a new variable database, use the Online Variable Database Definition facility
(described in Section 2 of the CONTROL-O User Manual) and add the name of the new
variable database to the Global member list (DAGLBLST).
The Global member list (DAGLBLST) is referenced by DD statement DAGLBLST of the
CONTROL-O monitor procedure and usually resides in member DAGLBLST of the
CONTROL-O PARM library.
Each line of the Global member list describes a Global member or variable database.
Format:
member attribute
where:
member Name of the Global member or variable database.
attribute Type of Global member or variable database.
The following attributes can be specified for a Global member:
INOUT The member is loaded and updated using commands
LOADGLOBAL and WRITEGLOBAL as described
above.
INPUT The member can be loaded but cannot written back.
This option can be used for storing Global AutoEdit
variables whose initial values are specified in the
member and do not require checkpointing. The value of
each Global AutoEdit variable can be changed and new
Global AutoEdit variables can be added to the member
during the CONTROL-O session, but these new values
and new variables are not saved when CONTROL-O is
stopped.
PROT The member cannot be updated during the
CONTROL-O session and no new Global AutoEdit
variables can be assigned to the member. This option
can be used for a member containing Global AutoEdit
variables that are constants (e.g., the messages of an
application).
TEMP The member does not reside on the disk and therefore
cannot be loaded or written back. This attribute is
useful for a member containing Global AutoEdit
variables that do not need to be saved after
CONTROL-O is stopped.
The following attributes can be specified for a variable database:
DBINOUT The variable database is loaded and updated using
commands LOADGLOBAL and WRITEGLOBAL as
described above.
DBINPUT The variable database can be loaded but cannot be
written back. This option can be used for storing Global
AutoEdit variables whose initial values are specified in
the database and do not require checkpointing. The
value of each Global AutoEdit variable can be changed
and new Global AutoEdit variables can be added to the
database during the CONTROL-O session, but these
new values and new variables are not saved when
DBPROT The variable database operates in protected mode. The
database cannot be updated during the CONTROL-O
session and no new Global AutoEdit variables can be
assigned to the database. This option can be used for a
database containing Global AutoEdit variables that are
constants (e.g., the messages of an application).
DBTEMP The variable database does not reside on disk and
therefore cannot be loaded or written back. This
attribute is useful for a database containing Global
AutoEdit variables that do not need to be saved after
The following screen segment contains sample content for member DAGLBLST of the
CONTROL-O PARM library:
$$COMPST PROT NEVER DELETE NOR CHANGE THIS LINE $$COMPST
$GLOBAL INOUT NEVER DELETE NOR CHANGE THIS LINE $GLOBAL
READONLY INPUT A READ-ONLY MEMBER
POOLTEMP TEMP TEMPORARY VARIABLES (NO MEMBER - ONLY IN MEMORY)
* ********************************************************************
* * COSMOS RELATED POOLS *
* ********************************************************************
*
* DEMO DATABASES
*
COSWORKV TEMP COSMOS - WORKING VARIABLES
COSALLPR DBINPUT COSMOS - DEMO PREREQUISITES DATABASE
COSALLMT DBINPUT COSMOS - DEMO METHODS DATABASE
COSSTCOB DBTEMP COSMOS - DEMO STC WORKING DATABASE
COSVTMOB DBTEMP COSMOS - DEMO VTAM WORKING DATABASE
COSIMGOB DBTEMP COSMOS - DEMO SYSIMAGE WORKING DATABASE
COSSTCSD DBINPUT COSMOS - DEMO STC SOURCE DATABASE
COSVTMSD DBINPUT COSMOS - DEMO VTAM SOURCE DATABASE
COSIMGSD DBINPUT COSMOS - DEMO SYSIMAGE SOURCE DATABASE
*
Once the new Global member or variable database has been defined and listed as described
above, it is necessary to activate it with operator command:
F CONTROLO, LOADGLOBAL=member
where:
member Name of Global member or variable database.
Automatic Compression of the Global AutoEdit Library
Because of its PDS (partitioned dataset) organization, the Global AutoEdit library is prone
to D37 ABENDs (insufficient space to write to disk). If, at your site, there is no product to
keep the library compressed, CONTROL-O enables you to automatically compress the
Global AutoEdit variables library whenever it becomes full, as explained below.
Note AutoEdit variable databases are stored in a set of IOA Access method files and are
therefore not handled by the Automatic Compression facility. For more information
about the IOA Access method, see Section 2 of this guide.
The Automatic Compression facility is normally activated when the Global AutoEdit
library is full (i.e., when a D37 abend is encountered during a WRITEGLOBAL operation).
Before attempting to compress the Global AutoEdit library, CONTROL-O backs up the
library to a sequential file via utility IEBCOPY. The name of the backup sequential file is
the name of the specified Global Library with the suffix .COPY. For example, when
Global library CTO.Vxxx.GLB.CPUSYSA is backed up, the resulting sequential file name
is: CTO.Vxxx.GLB.CPUSYSA.COPY
The Automatic Compression facility uses member $$COMPST of the Global AutoEdit
library to track the progress of the compression operation. $$COMPST is a single record
member that is created automatically when the Global library is defined.
For each step in the backup/compression process, variable %%STATUS in member
$$COMPST is updated to reflect the status of the compression process. Possible values for
this variable are:
%%STATUS=S1 Backup of the Global AutoEdit library has been started but not
completed.
%%STATUS=S2 Backup of the library was successful. Compression has been started
but not completed (i.e., is either still in process or has failed).
%%STATUS=OK Compression has been successfully completed.
Whenever the Global AutoEdit library is accessed (via a LOADGLOBAL or
WRITEGLOBAL operation), the value of %%STATUS is checked to ensure that the library
was not corrupted during the last automatic compress operation.
If the value of %%STATUS is OK, the requested LOADGLOBAL or WRITEGLOBAL
operation is performed.
If the value of %%STATUS is S2, the Automatic Compression facility automatically
restores the Global AutoEdit library from the backup file and compresses it before
execution of the LOADGLOBAL or WRITEGLOBAL operation.
If the value of %%STATUS is S1, the Global AutoEdit library and backup may be
corrupt and the operation cannot be performed. An error message is issued.
Enabling Automatic Compression
If automatic compression of the AutoEdit variables library was not enabled at time of
installation, it can be enabled by performing the following steps:
1. Bring down CONTROL-O.
2. Specify Y for parameter GLBCOMP in member CTOPARM of the IOA INSTCTO
library. Submit job CTOPARMJ.
3. Submit job NEWGLOB in the IOA INSTCTO library. This job:
Renames the old Global AutoEdit library.
Defines a new Global AutoEdit library (using the old library name) and a sequential
backup file (used by the Automatic Compression facility).
Copies the contents of the renamed Global AutoEdit library to the new Global
AutoEdit library.
4. Restart CONTROL-O.
Modifying the CONTROL-O Sleeping Interval
CONTROL-O wakes up every few seconds and checks on time-related events. This time
interval is defined in CONTROL-O installation parameters and can be changed by the
system administrator. In addition, the interval can be modified by operator command:
F CONTROLO,INTERVAL=nn
If CONTROL-M is active at your site, it is recommended that you specify an interval
shorter than the CONTROL-M sleeping interval.
It is recommended that the interval be modified by automatic commands which are
invoked by the CONTROL-O monitor itself, according to set conditions and time ranges,
and not manually by the operator.
on the processing power of the machine indicated below, the sleeping interval should
usually not be less than the number of seconds indicated:
There is no practical benefit in setting the interval to less than the above minimum. Doing
so could actually slow down CONTROL-O s operation.
When the modification is accepted by CONTROL-O, the following message appears on the
operator console:
CTO123I CONTROL-O INTERVAL IS SET TO nn SECONDS
Refreshing the CONTROL-O Security Cache
CONTROL-O security modules use a security block to identify each user for which an
authority check is performed. The first time a users security authorization is checked,
CONTROL-O creates a security block for that user. The security block can then optionally
be saved for the next time the users security authorization is checked.
Security blocks saved for subsequent checks are kept in the CONTROL-O Security Cache.
The size of the security cache is defined in parameter RUNTCACH in member CTOPARM.
If 0 is specified for parameter RUNTCACH, no security blocks are saved. (See parameter
RUNTCACH under CONTROL-O Operational Parameters in Section 7 of the IOA
Installation Guide for information about this parameter.)
The CONTROL-O Security Cache holds security blocks for only the last n users to have
their security authorization checked, where n is the value specified for parameter
RUNTCACH. For example, if parameter RUNTCACH contains a value of 10, the security
cache holds a security block for each of the last ten users that were checked.
Changes made to a users security authorization since the last time that users security
block was created are not automatically included in the information in the users security
block in the CONTROL-O Security Cache. However if a users security authorization has
been changed, and there is no security block in the CONTROL-O Security Cache for that
user, changes made to the users security authorization are put into effect the next time
that users security authorization is checked.
To immediately include new user authorization information in the CONTROL-O security
cache, refresh the security cache via operator command:
F CONTROLO,NEWSECDEF
This command refreshes all user authorization information in the CONTROL-O security cache.
When the modification is accepted, the following message appears on the operator console:
CTO251I RUNTIME SECURITY REFRESH ENDED OK
CONTROL-O is supplied with internal debugging facilities which provide the ability to
print an internal debugging trace and to print the contents of CONTROL-O internal data
areas. Under normal circumstances, the debugging facilities are dormant. However, if
required (i.e., if Technical Support has requested debugging information), it is possible to
activate the debugging facilities as follows:
Activate the CONTROL-O internal trace:
1. Perform either step A or B.
A. Start a new CONTROL-O monitor with the following operator command:
S CONTROLO,DEBUG=level
The CONTROL-O monitor passes control to the new CONTROL-O monitor and
shuts down.
-or-
B. Issue the following operator command:
F CONTROLO,DEBUG=level
The required debugging level will be supplied by your IOA representative. It can be any
value from 000 to 255 (000 specifies no debugging).
Note It is highly recommended that you not activate CONTROL-O with the DEBUG
parameter on a regular basis because a JES problem may cause CONTROL-O to
become suspended while waiting for JES.
2. Debugging information is printed to files referenced by DD statements PRTDBG and
DADUMP of the CONTROL-O procedure.
3. When you finish your problem determination procedures, start a new CONTROL-O
using operator command:
S CONTROLO
or specify operator command:
F CONTROLO,DEBUG=000
Print CONTROL-O Internal Data Areas
To print a snapshot of CONTROL-O internal data areas, issue operator command:
F CONTROLO,SNAP[=name1,name2 .....,namen]
where:
name1, name2,.... namen are the names of the CONTROL-O internal data areas.
When no name is specified, all data areas are printed. Your IOA representative will
provide you with the list of data area names and will specify which areas should be printed
depending on the problem encountered.
Valid values:
ALL DLY MTOLNK MTOWSC RQCALO RQCSTO STO
ALO EXO MTOMIX MVS RQCDLY RQH SWT
CAS LINK MTOMPT OMT RQCEXO RULES UCM
CDT MAIN MTOPLB OPR RQCFREE SEC VARS
CONLIST MCT MTOPND PARM RQCMTO SLO WISHES
CONS MTO MTOPNX PND RQCRFR SRV WSC
CONSOLE MTOCOS MTOSRV RFR RQCSLO SSCT
COS MTOINX MTOSRVA RQC RQCSRV SSVT
When the snap is completed, the following message appears on the console:
CTO150I SNAP COMMAND WAS PERFORMED SNAPID=xxxx
where:
SNAPID is the snap identifying number which appears on the lower right of the screen
after the snap is completed.
Displaying Internal Resource Utilization
To obtain information on internal resource utilization, issue operator command:
F CONTROLO,WATERMARKS
The response to this command is displayed as message CTO15DI. See the IOA Messages
and Codes manual for an explanation of this message.
Displaying a CONTROL-O Storage Table
To obtain information about CONTROL-O usage of internal storage areas, issue operator
command:
F CONTROLO,STORAGETABLE
Note This command should only be issued if requested by your local IOA representative or
Technical Support.
Information message CTO356I is issued in response to this command. An example of this
message is shown below:
CTO356I STORAGETABLE
NAME ADDRESS LEN(HEX) LEN(DEC)
DEST 00D495C8 00000108 00000264
FMIX 00000000 00000000 00000000
INX 0370A390 000000E8 00000232
MIX 036C0D28 00000504 00001284
MSGB 00045190 00018E70 00102000
PND 0358BAC8 00021534 00136500
SRVR 03673EB8 00001144 00004420
WSC 03614000 0001E000 00122880
NETMAP 00C014A0 00003B60 00015200
CTOWTO 831B3600 0002AA10 00174608 12/17/98 16.56 BO0709
CTOAIDT 00BA6D58 000082B8 00033464 12/02/98 12.18 WO0818
CTOALT 80B8FEC0 00003140 00012608 11/12/98 12.37
CTOMTO 00006FB0 0003E050 00254032 01/06/99 13.15
Displaying Major CONTROL-O Blocks
To display information about major blocks used by CONTROL-O, issue operator command:
F CONTROLO,SHOWPARM
Note This command should only be issued if requested by your local IOA representative or
Technical Support.
Information messages similar to those shown below are issued in response to this
command:
CTO000I CTOPARM :CTOPARM - 11/23/98 18.32 - CONTROL-O, REL 5.1.4
CTO000I IOAPARM :IOAP 11/24/98 17.03 5.1.4
CTO000I CTMPARM :CTMP 11/24/98 17.03 5.1.4
CTO000I CTOPARM AT 000414F8
CTO000I ****....... CTOPARM - 11/23/98 18.32 - CONTROL-O, REL 5.1.4
CTO000I FLAGS...... CTM CTOQNAME... O51TROLO INTERVAL... 0000040
CTO000I DAYTIME.... +1200 STSFL...... 0
The first messages issued indicate the compilation date and level of existing CTOPARM,
IOAPARM and CTMPARM blocks.
Additional information (e.g., the address of blocks in ECSA storage) is supplied in
subsequent messages.
Changing CONTROL-Os Operating Mode
A special CONTROL-O operator command can be used to modify the operating mode of
CONTROL-O. Under normal circumstances, CONTROL-O operating mode should not be
modified. However, if severe CONTROL-O problems are detected and your IOA representative
has requested debugging information, these commands can help isolate and solve the problem.
Use the following operator command to modify the CONTROL-O operating mode:
F CONTROLO,MODE[=modename]
where modename is the mode in which CONTROL-O should be run. The following modes
can be specified:
blank Displays the current operating mode of CONTROL-O. Under normal
circumstances, the following message is issued in response to this command:
CTO138I CONTROL-O OPERATING MODE IS NORMAL
FREEZE Freezes all CONTROL-O automatic processes. No rules are activated
and rules which are currently running (e.g., they are paused due to a
DO WAIT statement) are frozen. In FREEZE mode, messages and
commands are not analyzed by CONTROL-O and the Automation Log
(screen OL) does not display any new messages or commands.
LOGONLY Stops all CONTROL-O automatic processes. No rules are activated
DO WAIT statement) are frozen. In LOGONLY mode, no messages or
commands are analyzed by CONTROL-O. However, the Automation
log (screen OL) displays all new messages and commands.
TRIGGERONLY Stops all CONTROL-O automatic processes. No rules are activated
DO WAIT statement) are frozen. However, rules are examined by
CONTROL-O to determine if they should be activated.
In TRIGGERONLY mode, the Automation log (screen OL) displays all
new messages and commands and indicates what actions (i.e., rules)
would have been performed if CONTROL-O were operating in NORMAL
mode.
RESUME,option Returns CONTROL-O to NORMAL mode. All automatic processes are
resumed. The option appended to this command determines whether
or not rules that were running when the automatic processes were
interrupted should be continued. Valid options:
CONTINUE Continue running interrupted rules.
CANCEL Abort interrupted rules.
Note The longer CONTROL-O automatic processes are halted (due to a MODE command),
the more likely CONTROL-Os examination of messages and commands will result in
unexpected actions. Therefore, it is recommended that you stop CONTROL-O (via
command P CONTROLO) and start CONTROL-O (via command S CONTROLO) as
soon as a debugging session is complete.
Customization of Automation Options
Automation Options (AOP) screens can be modified and new screens defined to meet site
requirements. (Refer to sections 1 and 2 in the CONTROL-O User Manual for a description
of the Automation Options facility.)
AOP Overview
The Automation Options facility is comprised of the following components:
1. Menu Definition Members
Each menu definition is written in a member containing parameters (keywords and
values) that describe the options in the menu. The following are defined for each option:
Name of the option.
Parameters that define the format of the display line.
Name of the program to be executed or, for a submenu, name of the member
containing the submenu definition.
Each Automation Option should have a menu definition member in the IOA MSG
library. The name of this member should be the name of the menu, prefixed by ##. For
example, the definition for menu OPER should reside in member ##OPER.
The main Automation Options menu is defined in member ##AOP.
To update or add an Automation Option, it is necessary to access the appropriate menu
definition member and modify it as described later in this section.
2. Format Members
Formats describe how lines provided by a client program are to be displayed on the
screen. The format of the primary Automation Options screen provided by CONTROL-O
is specified in member $$AOP in the IOA MSG library. The user can write new formats
and save them as members in the IOA MSG library.
Note To avoid problems in the execution of the Automated Options facility, do not modify
member $$AOP.
3. Client programs
Client programs can be any independent load module, TSO CLIST, or REXX EXEC,
which the Automation Options facility invokes either to perform functions or to provide
lines to be displayed.
Menus
Update the appropriate member in the IOA MSG library with the parameters of the new
options. Each parameter described below defines a line in the specification of the new
Automation Option.
Menu Member Syntax
The following syntax rules should be considered when defining menus of new options.
A menu statement consists of one or more lines, each with of a maximum of 72 columns.
Each menu statement is comprised of a parameter (keyword and its value), separated
by one or several blank spaces. Parameters can be specified in uppercase or lowercase.
Data can be specified anywhere between columns 1 and 71.
A non-blank character in column 72 indicates that the statement is continued on the
next line.
Data on continuation lines must start at column 16.
An asterisk (*) in column 1 specifies that the line is a comment.
Parameters
OPTION Name of the option (1-8 characters) as it appears in the menu screen.
OPTION must be unique within the menu member. Mandatory.
Parameter OPTION heads a group of statements. The group ends
when a new OPTION parameter or the end of file is encountered.
Example: OPTION USERINFO
DESC Description of the option as it appears in the menu screen. DESC is a
string of 1-70 characters, enclosed in single quotes. Mandatory.
Example: DESC Query USER database
LINECMD Line command character. This character defines the line command
used to select the option to be executed from the Automation Options
entry panel.
The line command character can be any character (with the exception
of ?) which does not invoke the client program. When selected, ?
displays the prompt window.
LINECMD heads a subgroup of statements that define actions to be
performed when the specified line command is entered. The subgroup
ends when a new LINECMD, new OPTION, or end of file is
encountered.
At least one LINECMD must be specified within an OPTION group of
statements. The following parameters help define the LINECMD
subgroup: PROGRAM, PROMPT, PARM, RETURNS, FORMAT,
OPTLIST. They are described below.
PROGRAM Program name (1 to 8 characters). Mandatory within a subgroup of
statements headed by a LINECMD statement. PROGRAM names a
client program which is invoked when the preceding line command
LINECMD is entered. The program can be any regular load module, a
TSO CLIST, or a REXX EXEC. The PROGRAM statement can include
subparameters to define special program attributes. When no
subparameters are specified, the client program performs according to
Automation Options standard linkage conventions (described in
member DOCOAOCP in the IOA SECUDATA library) and is called an
AOP program.
Optional subparameters are:
IMMEDIATE Prompt window is not displayed. If parameters are
specified, they are passed directly to the program.
NOSCREEN Display lines are not returned. (The client program
may perform its own terminal I/O without using the
Automation Options facility.) Programs specifying
NOSCREEN can be invoked only under TSO.
ISPFENV Valid ISPF environment is required. Programs
specifying ISPFENV can be invoked only under
ISPF.
TSOCP Client program is invoked as a TSO command
processor.
EXECPGM Parameters are passed to the program in the format
of the PARM= statement of a JCL EXEC program.
REFRKEY Definition of function key(s) for REFRESH action.
Valid values: ENTER and PF4. Default: PF4.
Examples
PROGRAM AOPGUINF
Client program retrieves user information which is displayed later on
the screen.
PROGRAM SDSF IMMEDIATE NOSCREEN TSOCP
TSO command processor does not receive any prompts and performs
its own terminal I/O.
PROGRAM CLIST1 IMMEDIATE NOSCREEN TSOCP
TSO CLIST does not receive any prompts and performs its own
terminal I/O.
PROGRAM CTOTAMN
OPTLIST ##SAMPLE
Invoke supplied program CTOTAMN to display the submenu defined
in member ##SAMPLE.
PROMPT Request for data to be passed to the client program. Optional. A
maximum of 14 PROMPT statements can be specified. When the
LINECMD character is specified and at least one PROMPT parameter
has been specified, a prompt window is opened with as many prompt
lines as PROMPT parameters in the menu. The user fills in the
required input, then presses <ENTER>, thus calling the client
program. The answers to the prompts are passed to the client program
as an array unless parameter PARM (described below) is specified.
Format:
PROMPT data1,length,data2
where:
data1 String of 1-20 characters between quotes. It is
considered a comment and should be used to describe
the required input. Mandatory.
length Number (0-44) specifying the length of the prompt
input field. Mandatory.
data2 String in quotes specifying the prompts initial
value. Optional. If data2 is specified, its length must
be less than or equal to length. Default value is
blanks.
Examples
PROMPT User name ====>>,8
The user is prompted to enter an 8-byte input field. The field is
initialized to blanks.
PROMPT Department ====>>,20,TECH-SUPPORT
The user is prompted to enter a 20-byte input field. The field is
initialized to the value of TECH-SUPPORT padded to the right with
blanks.
PARM String delimited by two identical characters (e.g., both PARM /xxx/
and PARM xxx are valid; PARM /xxx is invalid since the delimiters
of the string are not identical).
The string contains input parameters that are required by the client
program. Data between the delimiters can consist of any characters,
except the character chosen as delimiter, The string can include
special AutoEdit variables %%Pn and %%., where:
%%Pn is the value assigned to PROMPT number n.
%%. is a special variable used to concatenate two AutoEdit
variables.
Functions such as %%$SUBSTR can also be specified.
After AutoEdit symbols have been resolved, the strings length cannot
exceed 255 characters.
Example 1
PARM #00 77#
Passes to the client program the value: 00 77
Example 2
PROMPT User name ====>>, 8
PROMPT Department ====>>,20,TECH-SUPPORT
PARM /QUERY,USERID=%%P1,DEPARTMENT=%%P2/
The first parameter is blank and the second parameter is TECH-
SUPPORT.
If the user enters UserA on the first PROMPT line, leaves the second
PROMPT line unchanged, and presses <ENTER>, the following string
is passed to the program:
QUERY,USERID=UserA,DEPARTMENT=TECH-SUPPORT
Note When both PROMPT and PARM statements are specified, the order
of their appearance within the menu is not important; however, the
data is passed to the program as specified in the PARM statement.
RETURNS String, delimited by quotes (maximum 200 characters), which defines
the layout of a line of display. Optional. Default is: 1 LINE +77. If
display type A exists in the format member of the option, it must
contain the name of all the variables defined here.
The string is a simple CONTROL-O template which names the format
variables and their positions in the displayed line. Variable names
must not exceed eight characters and their positions must be specified
numerically only. (Refer to the description of the %%$PARSE function
in Section 4 of the CONTROL-O User Manual for detailed information
on templates.)
For each variable on the template, the following fields should be specified:
starting position Starting position of the variable on the template
string (character).
variable name Name of the variable (in uppercase).
length Length of the variable (in characters).
Example
Divide the returned lines into the following displayable variables:
FIRSTNME Begins in column 1 and its length is 8 characters.
LASTNME Begins in column 20 and its length is 12 characters.
ADDRESS Begins in column 60 and its length is 35 characters.
RETURNS 1 FIRSTNME +8 20 LASTNME +12 60 ADDRESS +35
These variables must be defined in the corresponding format member.
Note RETURNS cannot be specified for programs specifying
NOSCREEN.
FORMAT Name of the format member (1-8 characters) used for displaying the
lines returned from the client program. Format member name must
begin with $$, in accordance with Automation Options conventions.
Optional. FORMAT is ignored if specified in a menu together with
subparameters NOSCREEN, TSOCP, or EXECPGM.
Example
FORMAT $$UINFO
$$UINFO is the format member for use in displaying the return lines.
OPTLIST Name of a lower level menu member (1-8 characters). Optional. To
process a lower level menu, invoke the supplied program CTOTAMN
and specify the $$AOP format member (or a similar format member) to
display your customized Automation Options screen. OPTLIST must
begin with ##, in accordance with Automation Options conventions.
Example of Menu
OPTION USERINFO
DESC Query USER database
LINECMD S
PROGRAM CTOTAMN
OPTLIST ##UINFO FORMAT $$AOP
RETURNS 1 OPTION +8 9 DESC +60
When option USERINFO is selected by specifying S in the select option field of the
Automation Options screen, the user-defined Automation Options specified in the
##UINFO menu member are displayed in a new screen.
Format Members
Format members are used to format the lines displayed on the screen. Refer to
Customizing IOA Display Format Members in Section 2 of this guide for details on how
to define and customize format members.
Note The first @FIELD in each @LINE must be SAOPLCMD. The other @FIELDs in each
@LINE must contain variables that match those in the RETURNS statement of the menu.
Client Programs
A client program is a load module, TSO CLIST, or REXX EXEC that is invoked by the
Automation Options facility when selected by a line command character (other than ?).
Client programs can be called, with or without parameters, to perform a function and then
return without displaying lines.
Sophisticated AOP programs receive parameters via PROMPTs or PARM statements and
return lines for display. Before a program is called, the Automation Options facility
reviews program attributes in the menu and takes special actions if necessary.
Examples
If ISPFENV is specified, the Automation Options facility ensures that a valid ISPF
environment exists before invoking the client program.
If IMMEDIATE is specified, the Automation Options facility checks the PROMPTs and the
PARM specification in the menu, if any, and passes the data to the client program without
displaying it on the screen.
General registers 1 15 contain the following information at time of entry to the client program:
R15 Entry point of the called program
R14 Return address
R13 Address of save area
R1 Address of input data
R0 N/A
R2-R12 N/A
Program Input
The program input varies according to the type of client program: EXECPGM, TSOCP, or
AOP (as described above). A full description of the input data is included in member
DOCOAOCP in the SECUDATA library.
Execution Process
Client programs of the TSOCP or EXECPGM type must follow the rules specified below:
The program is to be considered an extension of IOA. Since it runs under IOA, an
abend of the client program triggers an abend of the IOA session. Storage overlays
within the program may produce unpredictable results.
Registers must be saved and restored according to standard IBM conventions.
Areas acquired by the program during execution must be released before returning to
the Automation Options facility. Failure to follow this rule may result in storage
buildup and cause abends.
CLISTs and REXX EXECs can be used under MVS/XA or higher level operating systems.
Client programs that are not of type TSOCP or EXECPGM are called AOP programs. A full
description of the execution process of an AOP program is included in member DOCOAOCP
in the SECUDATA library.
Client Program Linkage Conventions
Client programs which do not specify attributes NOSCREEN, TSOCP, or EXECPGM,
return a set of lines to the Automation Options facility. These lines are displayed according
to the parameters specified in the format member referenced by the FORMAT statement in
the menu definition member.
A full description of the Client Program Linkage Conventions for an AOP program is
included in member DOCOAOCP in the IOA SECUDATA library.
Considerations for When CONTROL-M and
CONTROL-O Are Installed
When CONTROL-O and CONTROL-M are installed, the CONTROL-O monitor assumes
the responsibilities of both the CMEM facility and CONTROL-O. The way in which the
CONTROL-O monitor functions depends on how organizational requirements, scheduling,
and automation have been addressed at your site.
The following DD statements in the CONTROL-O startup procedure are relevant to this
issue:
DARULLST References a member containing the list of CONTROL-O rule tables to
be loaded by the CONTROL-O monitor. The default name for this
member is RULELIST.
DACTMLST References a member containing the list of CMEM rule tables to be
loaded by the CONTROL-O monitor. The default name for this
member is IOACMEML.
Below is a description of the different ways in which the CONTROL-O monitor can operate:
If all automation was implemented only via the Online CONTROL-O Rule Definition
facility (and the CMEM facility was not used):
Start CONTROL-O via operator command:
S CONTROLO
CONTROL-O loads the rule tables listed in the member referenced by DD statement
DARULLST. The member referenced by DD statement DACTMLST must be empty.
If automation was implemented via both the CONTROL-O Rule Definition facility and
the CMEM facility:
Start CONTROL-O via operator command:
S CONTROLO
CONTROL-O first loads the CMEM rule tables listed in the member referenced by DD
statement DACTMLST. CONTROL-O then loads the CONTROL-O rule tables listed in
the member referenced by DD statement DARULLST.
If automation was implemented via both the CONTROL-O Rule Definition facility and
the CMEM facility but, temporarily, only CMEM functionality is desired (e.g., for a
trial period):
Start CONTROL-O via the following operator command:
S CONTROLO,TYPE=CTOCMEM
This command causes the CONTROL-O monitor to load only CMEM rule tables.
CONTROL-O loads the CMEM rule tables listed in the member referenced by DD
statement DACTMLST. Loading of CONTROL-O tables is skipped. This mode of
operation should not be used on a long-term basis.
More information on the management of the CMEM facility by the CONTROL-O monitor is
provided at the beginning of this section.
CONTROL-O/CICS Interface
Although regular CONTROL-O processing can handle CICS messages which are sent to
the MVS console, most CICS messages are not sent to the MVS console. CICS sends
messages to an internal component called the Transient Data Queue and sometimes to the
user console as well.
The CONTROL-O/CICS interface enables you to retrieve these messages.
Note CICS commands are executed in a CICS transaction. There is no CICS exit which
handles CICS system commands. Therefore, the CONTROL-O CICS interface cannot
handle CICS system commands.
CONTROL-O Interface for the CICS Environment
The CONTROL-O/CICS interface uses the CICS XTDOUT exit to intercept CICS messages
which are to be sent to the Transient Data Queue. This exit receives control before each
message is written to the Transient Data Queue and passes it to the CONTROL-O/CICS
interface module CTOCTDX. Module CTOCTDX passes the message to the CONTROL-O
WTO executor module (CTOWTO) as a WTO message. Module CTOWTO determines if the
message should be untouched, changed, or suppressed (i.e., not written to the Transient
Data Queue).
Starting the Interface
The CONTROL-O/CICS interface can be started in either of the following ways:
Manual start Issue the following CICS transaction:
IOAC INIT
Automatic start Define program CTOCTDT in the CICS DFHPLTPI table. This
ensures that the CONTROL-O/CICS interface is started when CICS is
brought up.
IOAC Transaction Options
The following options can be specified for a CICS IOAC transaction:
INIT Start the CONTROL-O/CICS interface.
SHUT Stop the CONTROL-O/CICS interface.
DEBUG=ON Issue debug messages describing the operation of the
CONTROL-O/CICS interface. Resulting messages appear in the CICS
job log and on the console.
DEBUG=OFF Stop issuing debug messages describing the CONTROL-O/CICS
interface.
CONTROL-O/IMS Interface
Although regular CONTROL-O processing can handle IMS messages which are sent to the
MVS console, most IMS messages are not sent to the MVS console. IMS messages that are
not sent to the MVS console are sent to an internal component called the Automated
Operations Interface (AOI). The CONTROL-O/IMS interface enables you to retrieve and
respond to these messages.
Depending on the IMS release in use at your site, one of the following IMS AOI programs
is used to handle messages:
DFSAOEU0 Called by IMS versions prior to version 5. This exit does not handle
messages and commands in IMS DBCTL (the IMS address space in the
CICS environment).
DFSAOE00 Called by IMS version 5 or later. This exit does handle messages and
commands in IMS DBCTL.
These programs are supplied with CONTROL-O and are implemented during CONTROL-O
installation. These programs intercept IMS messages sent to the IMS Automation Interface
and pass them to CONTROL-O WTO executor module CTOWTO. Module CTOWTO
determines if the message should be untouched, changed or suppressed.
Operating the CONTROL-O/IMS Interface
The CONTROL-O/IMS interface is implemented via the Automated Operations Interface
(AOI). AOI starts when the IMS environment is initiated, if either module DFSAOUE0 is
link-edited into the IMS nucleus or module DFSAOE00 is found in the IMS RESLIB
library.
Prior to IMS version 5, the AOI can be stopped only by stopping the IMS environment and
removing module DFSAOUE0 from the IMS nucleus.
In IMS version 5 or later, the AOI can be stopped in either of the following ways:
Stop the IMS environment and delete module DFSAOE00 from the IMS RESLIB
library.
Stop the CONTROL-O/IMS interface via a CONTROL-O/IMS command (described
below).
CONTROL-O/IMS Commands
The CONTROL-O/IMS interface is activated when IMS is brought up. The following
commands can be used with CONTROL-O/IMS interface module DFSAOE00:
/CTO STOP Stop the CONTROL-O/IMS interface module DFSAOE00.
/CTO START Reactivate interface module DFSAOE00.
/CTO CANCEL Terminate interface module DFSAOE00. If the interface module is
terminated via this command, it cannot be reactivated until IMS is
brought down and restarted.
Note CONTROL-O/IMS commands are relevant only for IMS version 5 and above.
Starting CONTROL-O Communication Support (CTOGATE)
Verify that the IOA Gateway has been successfully installed before trying to start
CTOGATE. (See Section 2 of the IOA Installation Guide for information about installing
the IOA Gateway.)
To start CTOGATE processing, first initialize the mainframe components. CONTROL-O
users can then proceed to use the communication channel.
Activate the IOA Gateway using operator command:
S IOAGATE
ECAPARM communication parameters (COMM, APPLIDS, PORT) can be overridden by
parameters specified in the EXEC PARM of IOAGATE. See Section 2 of the IOA
Installation Guide for information about ECAPARM parameters.
For example:
S IOAGATE,PRM=COM=SNA,APPLID=CTOLUA1
The CONTROL-O Application Server (called CTOAS) is automatically activated by the IOA
Gateway.
To deactivate the IOA Gateway, use operator command:
P IOAGATE
This deactivates the CONTROL-O Application Server (CTOAS) as well.
To display the list of all active users in the Application Server, use operator command:
F IOAGATE,MODASID[=nn],D[ISPLAY]
where nn is the specific address space ID of the server to which the modify command will
be submitted. If no address space is specified, the modify command will be submitted to all
active server address spaces.
When D[ISPLAY] is specified, a list of all active sessions will be displayed.
To enable or disable debug messages, specify operator command:
F CTOAS,DEBUG=(nn[,-nn]...)
where nn enables and nn disables debug action nn in the following table:
nn Debug Action
10 Write Sender module messages to DD statement PRTDBG.
11 Write Receiver module messages to DD statement PRTDBG.
General ...........................................................................................................................................6-1
CONTROL-B New Day Procedure............................................................................................6-1
Reformatting the Active Balancing File Utility CTBFRM....................................................6-2
Scheduling Balancing Missions .................................................................................................6-2
Format of the Date Control Record ...........................................................................................6-3
Use of the Date Control Record by the New Day Procedure....................................................6-3
Invoking CONTROL-B (Runtime Environment) ..................................................................6-5
Passing Arguments While Invoking CONTROL-B ..................................................................6-5
Invoking CONTROL-B Via a Direct Call ..................................................................................6-7
Invoking CONTROL-B From a Job Step or Application Program ..........................................6-8
Invoking CONTROL-B by CONTROL-M..................................................................................6-9
Invoking CONTROL-B by CONTROL-D..................................................................................6-9
Invoking CONTROL-B With Balancing Missions ..................................................................6-10
General
This section describes the initialization and customization features that are available for
CONTROL-B.
CONTROL-B New Day Procedure
The CONTROL-B New Day procedure (CTBNDAY
1
) performs certain automatic functions
which start a new day under CONTROL-B. It performs daily clean-up operations on the
CONTROL-B Active Balancing file and, optionally, other files. It also orders (activates)
CONTROL-B missions.
The New Day procedure can be activated automatically by a scheduler (e.g., CONTROL-M)
at a predefined time each day. It can also be activated manually by submitting a job or
starting a started task (STC).
The supplied New Day procedure activates program CTMILY. Program CTMILY reads the
sequential dataset (or member) referenced by DD statement DAPROG. This dataset
contains a list of programs to be activated.
The normal sequence of programs and utilities activated by the New Day procedure is:
Program Purpose
CTBCHK Checks the current date and its relation to the General Date Control
record (see below). The program may communicate with the computer
operator to verify that CONTROL-B is activated on the correct date.
CTBFRM Reformats the Active Balancing file. Unnecessary missions are erased and
the file is compressed.
CTBBAO Places balancing missions in the Active Balancing file according to the
date in the Date Control record and scheduling criteria.
CTBPDA Records the end of the daily run.
The CONTROL-B New Day procedure usually runs once a day on one or more balancing
mission definitions. The New Day procedure places mission entries in the Active Balancing
file. Missions are selected according to the working date specified to the New Day procedure.
1
This name is defined during the installation process and may be different at your site.
Reformatting the Active Balancing File Utility CTBFRM
The New Day procedure activates utility CTBFRM to clean up and reformat the Active
Balancing file. Missions and rules that have already executed and ended OK, and missions
whose MAXWAIT parameter has been exceeded, are erased from the file. Unscheduled
rules are automatically assigned a MAXWAIT value of 0. After these mission entries are
erased, the Active Balancing file is compressed.
Note If utility CTBFRM abends, information is recovered automatically after startup
using an automatically-generated backup copy of the Active Balancing file named
ABFBKP. For more information, see utility CTBFRM in Section 9 of this guide.
Scheduling Balancing Missions
The second function performed by the New Day procedure is the determination of which
missions can potentially be activated on a specific date (i.e., which missions will be placed
in the Active Balancing file).
Which missions will be scheduled depends on the working date. See Date Control Record
below for additional information.
Date Control Record
The New Day procedure is date-dependent. The last running date of the New Day
procedure is stored in a special Date Control record. The Date Control record is referenced
by DD statement DACHK in procedure CTBNDAY.
The New Day procedure calls program CTBCHK to check the Date Control record. The
Date Control record is analyzed by the New Day procedure to determine the current
running date, the last running date, and possible error situations. Special situations, such
as downtime due to hardware failure, must be handled. If necessary, the Date Control
record can be manually updated via a regular editor, e.g. the ISPF editor.
Format of the Date Control Record
Each Date Control record has 80 characters and contains the following fields:
Columns Field Purpose
01-06 date-1 Current (or last) original scheduling date.
18-23 date-2 Current (or last) original scheduling date of balancing missions using
parameters DATES, DAYS, DCAL and/or WCAL.
25-30 date-3 Finish indicator for missions of type date-2.
43-48 date-4 Current (or last) original scheduling date of balancing
missions using parameter WDAYS.
50-55 date-5 Finish indicator for missions of type date-4.
60-65 date-6 Last date the Active Balancing file was formatted by program
CTBFRM. This field prevents formatting the file twice on the
same day. If there are any problems concerning the date, the
program presents the operator with a series of questions.
67-72 date-7 Finish indicator date of the CONTROL-B New Day
procedure.
The format of the dates is determined by the date standard used at your site.
Use of the Date Control Record by the New Day Procedure
The Date Control record controls New Day procedure work flow. The New Day procedure,
in turn, updates the Date Control record during various stages of New Day processing.
The main steps of the New Day procedure are:
Checking the last running date of the New Day procedure (via internal program CTBCHK).
If the current working date is the same as the first date in the Date Control record,
a message indicates that the New Day procedure has already run today and the
condition code is set to 0004.
the New Day procedure stops executing and notifies the user that an attempt was
made to run a New Day procedure before its time.
updated to the current working date which is then used by all components of the
New Day procedure as the current scheduling date.
If the New Day procedure did not run for more than one day, a warning message is issued
and the New Day procedure attempts to schedule balancing missions for all of the days
which have passed since the last scheduling date (according to production parameters).
The program asks the operator a series of questions regarding the computers current
date. This ensures that an incorrect date was not inadvertently entered during IPL.
Placing balancing missions in the Active Balancing file according to the current
scheduling date and the last running date (via internal program CTBBAO).
Program CTBBAO acts on a user-defined balancing mission table referenced by DD
statement DABAL. The program checks whether each mission in the table should be
scheduled on one or all the days that have passed since the last original scheduling
date (date-3 or date-5) until the current working date (date-1). If a mission should be
scheduled, it is placed in the Active Balancing file.
For example, if a computer did not operate from the 20th to the 23rd, a mission
originally scheduled to run on the 20th did not run. Program CTBBAO decides whether
or not the mission should be retroactively scheduled to run on the logical date of the
20th. See parameter RETRO in Section 6 of the CONTROL-B User Manual.
When the program finishes processing the mission definitions, the finish indicator
dates (date-3 and date-5) are updated to the working date calculated by program
CTBCHK (date-1).
Before program CTBBAO starts operating, it compares date-2 with date-3 and date-4
with date-5. If they are not equal it probably means that a previous run of program
CTBBAO has abended. The user is notified and the program terminates. To correct the
error, you must edit the Date Control record to the correct date values.
Note When manually modifying the Date Control record, verify that the same missions
are not scheduled to run twice on the same day.
Recording the end of the Daily run (via program CTBPDA).
Program CTBPDA updates the finish indicator date (date-7) by setting it to the value
of the current working date (date-1). This is used to indicate that the New Day
procedure finished successfully.
It is highly recommended that utility CTBJAFDL be run as the last step of the New
Day procedure. See Section 9 in this guide for more information about this utility.
Invoking CONTROL-B (Runtime Environment)
CONTROL-B rules are invoked by the CONTROL-B Runtime environment. Therefore, the
Runtime environment must be invoked in order to invoke a CONTROL-B rule.
The CONTROL-B Runtime environment can be invoked by:
Direct call
When the CONTROL-B Runtime environment is invoked by a direct call, the name of the
rule to be invoked by the Runtime environment is one of the parameters passed in the
call. The direct call to the Runtime environment can come from an application program, a
job step, or another IOA product. A search for the specified rule name is performed in the
libraries referenced by DD statement DABRULE. No scheduling criteria are specified.
The same rule is always activated.
Balancing mission
A search is performed for the specified balancing mission name in the Active Balancing
file. After locating the appropriate mission, the rule specified by the mission is
activated. When CONTROL-B is invoked using this method, scheduling criteria can be
specified for date-dependent balancing activities. For example, the same mission can
activate different rules according to the day of the week using different categories of
the mission.
These methods of rule activation are discussed on the following pages.
Passing Arguments While Invoking CONTROL-B
Arguments can be passed when directly invoking CONTROL-B via procedure CONTROLB.
The arguments are specified in the EXEC statement of the job step:
// EXEC CONTROLB,RULE=rule,GROUP=group,MISSION=mission,ARG=arglist
where:
rule Name of the rule to be invoked.
group Group name of the rule to be invoked.
mission Mission name of the rule to be invoked.
arglist Arguments, separated by commas, to be passed to the rule.
A maximum of 50 arguments can be parsed in the ARG specification.
The arguments specified in arglist are accessed via System variable RARGnn, where nn is a
one- or two-digit number which represents the position of the argument in arglist. To
access the value of the first argument in the list, specify RARG01 within a rule.
See Invoking CONTROL-B via a Direct Call and Invoking CONTROL-B with Balancing
Missions later in this section.
Example
The following sample JCL and rule definition demonstrate how an argument can be passed
when invoking CONTROL-B. In this case, the value PROD1.COPY.FILE1 is passed to
CONTROL-B as an argument. In CONTROL-B, this value is checked to indicate whether
or not the dataset exists. The JCL continues to run according to the result of the
CONTROL-B activation.
//CHKTAPE JOB 0,ACCT,CLASS=A,MSGCLASS=X,COND=(0,NE)
//CTB EXEC CONTROLB,RULE=RULDSN,ARG=PROD1.COPY.FILE1
//COPYTAPE EXEC PGM=IEBCOPY
//IN DD DSN=PROD.COPY.FILE1,DISP=SHR
//OUT DD DISP=(NEW,PASS),DSN=COPY.FILE1,
// VOL=SER=TAPE18,UNIT=TAPE,
// LABEL=(1,SL)
//SYSIN DD *
C O=OUT,I=IN
//
LIBRARY : CTB.PROD.RULES RULE : RULDSN
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
OWNER M42A GROUP PROD1
UPDATED 08/08/98 - 12:19:37 BY M42A
DESC
OPTIONS
===========================================================================
EXECUTE BLOCK1 UPON C
ON DATA
IF ISDSN(%%RARG01) C
DO TERMINAT = OK COD 0000
ELSE
DO PRINT = FILE %%RARG01 DOES NOT EXIST F C
DO TERMINAT = NOTOK COD 0008
===========================================================================
EXECUTE UPON C
ON
======= >>>>>>>>>>>>>>> END OF RULE DEFINITION PARAMETERS <<<<<<<<<<<<<<< =====
Invoking CONTROL-B Via a Direct Call
The CONTROL-B Runtime environment can be invoked by a direct call from any of the following:
Application program The name of the rule to be invoked is specified by the application
programs call to CONTROL-B. See Appendix C of the CONTROL-B
User Manual for additional information.
Format
CALL CONTROLB(<rule name>)
Job step The rule to be invoked is specified by the JCL statement of the job
step (in the balancing job). This is the most frequently used method.
Format
// EXEC CONTROLB,RULE=rulename,GROUP=group,ARG=(arg1,...argn)
Note The GROUP argument is mandatory only if the rule definition
does not contain a value for parameter GROUP. If parameter
GROUP is specified in the rule definition, the GROUP
argument is optional.
The ARG specification allows up to 50 arguments. See Passing
Arguments while invoking CONTROL-B below.
Another IOA product The rule to be invoked is specified by parameter DO CTBRULE in a
CONTROL-M job scheduling definition or a CONTROL-D decollating
mission definition.
When CONTROL-B starts processing, it searches for the specified rule in the libraries
referenced by DD statement DABRULE.
If the rule is found, it is invoked. If the rule is not found, a runtime error occurs.
This flexibility enables the CONTROL-B user to select one or more appropriate points in
the life cycle of a particular data source during which balancing activities should be
performed. For example:
1. CONTROL-B can be invoked before the creation of a report to check the validity of the
report job input.
2. CONTROL-B can be invoked before updating a database (e.g., a DB2 table) or an
important file in the system. CONTROL-B checks the validity of the input used for the
update.
3. After a report is created, it can be checked during the current job before executing
other steps in the job and before the report is distributed.
4. CONTROL-D can invoke a CONTROL-B rule to validate a decollation process.
5. CONTROL-M can invoke CONTROL-B to perform balancing actions which verify the
input and/or output of a job run. Job flow can be controlled by CONTROL-M based on
the results of these balancing actions.
Invoking CONTROL-B From a Job Step or Application
Program
The following parameters can be used to invoke CONTROL-B from a job step or from an
application program:
RULE
MISSION
GROUP
ARG
Parameters RULE and MISSION cannot be specified together to invoke balancing
operations (i.e., the user must decide whether CONTROL-B should be invoked directly or
indirectly). Either the mission name or rule name should be specified but not both.
The group name is determined as follows:
1. If GROUP is specified in the invocation, that group name overrides any other group
specification.
2. If GROUP is not specified in the invocation and balancing operations are invoked by a
mission, the group name of the mission is used.
3. Otherwise, the group name specified in the rule definition is used as the current group.
Note The specified group must already be defined in the CONTROL-B repository.
Parameters can be passed to a CONTROL-B rule and accessed by the rule via system
variable RARGnn, where nn is a one- or two-digit number which represents the position of
the argument in the argument list. To access the value of the first argument in the list,
specify RARG01 within a rule.
Examples of Job Step Invocation
Direct invocation of a CONTROL-B rule:
// EXEC CONTROLB,RULE=ACCTCHK,GROUP=ACCT,ARG=12/06/98
CONTROL-B invocation via a mission:
// EXEC CONTROLB,MISSION=ACTMISS
Application program invocation:
CALL CONTROLB,(rulename,mission,groupname,result,argument-count,argument-list)
See the beginning of this section for more information about CONTROL-B invocation.
Invoking CONTROL-B by CONTROL-M
When CONTROL-B is invoked by CONTROL-M, it is not necessary to specify scheduling
criteria for the rule (i.e., there is no need to define a balancing mission). The CONTROL-B
rule is scheduled in accordance with the scheduling criteria specified in the CONTROL-M
job scheduling definition.
However, when invoked by CONTROL-M, CONTROL-B must execute each rule for a
specific group. The name of the group can be specified by any of the following methods
(which are listed in order of decreasing priority). The group name can be specified in:
Parameter GROUP in the CONTROL-B rule.
The GROUP=group-name argument in the procedure which invokes CONTROL-B.
Parameter GROUP in the CONTROL-M job scheduling mission.
If a group name is specified by more than one of these methods, the rule is implemented
with the group name specified by the method with the highest priority.
Invoking CONTROL-B by CONTROL-D
When CONTROL-B is invoked by CONTROL-D, it is not necessary to specify scheduling
criteria for the rule (i.e., there is no need to define a balancing mission). The CONTROL-B
rule is scheduled in accordance with the scheduling criteria specified in the CONTROL-D
decollating mission definition.
It is highly recommended that a group be specified in the CONTROL-B rule or in the
CONTROL-D decollating mission. When CONTROL-B is invoked, the name of the group is
obtained from one of the following sources (which are listed in order of decreasing priority).
The group name can be specified in parameter GROUP of the:
CONTROL-B rule.
CONTROL-D decollating mission.
If a group name is specified in both of these parameters, the rule is implemented with the
group name specified in the CONTROL-B rule.
Invoking CONTROL-B With Balancing Missions
Balancing missions can be used to invoke CONTROL-B from one of the following:
Application program Name of the mission to invoke is specified by a program call to
CONTROL-B in the application program. See Appendix C in the
CONTROL-B User Manual for additional information.
Example
CALL CONTROLB(<mission>, ...);
Job step Name of the mission to be invoked is specified in the JCL
statements of the job step which invokes the CONTROL-B Runtime
environment.
Example
// EXEC CONTROLB,
// MISSION=DAILYBAL,GROUP=group,ARG=(arg1,...,argn)
Note The GROUP argument is mandatory only if the rule definition
does not contain a value for parameter GROUP. If parameter
GROUP is specified in the rule definition, the GROUP
argument is optional.
The ARG specification allows up to 50 arguments. See Passing Arguments While Invoking
CONTROL-B above.
When the call/step which invokes CONTROL-B is invoked, CONTROL-B first checks each
entry in the Active Balancing file to locate the appropriate balancing mission. The Active
Balancing file search method consists of the following phases:
Phase 1 All mission entries with corresponding mission names are checked
to see if their runtime scheduling criteria are met. Missions whose
runtime scheduling criteria are met advance to the second phase
for further checking.
Phase 2 Missions which have passed the first phase are checked to see if the
values specified by parameters JOB and STEP match the job name
and (optional) step name of the current call/step.
Note The * mask character can be specified at the end of JOB and
STEP names.
Parameter SCOPE of each eligible mission entry in the Active Balancing file is checked to
determine a JOB/STEP match. Parameter SCOPE specifies one of the following options:
SINGLE If JOB and STEP values match, the mission entry is eligible for
further checking only if it has not been invoked before. Option
SINGLE guarantees that this mission entry is only invoked once
by a single CONTROL-B invocation.
STEP If JOB and STEP values match, the mission entry is eligible for
further checking if it has not been invoked before or if it was
previously invoked by the current STEP in the current JOB. Option
STEP enables the mission entry to be invoked repeatedly, provided
that the mission entry is invoked from the same job step each time
(e.g., from an application program that invokes CONTROL-B from
within a loop).
JOB If the JOB value matches, the mission entry is eligible for further
checking if it has not been invoked before or if it was previously
invoked by the current JOB. Option JOB enables the mission entry
to be invoked by several CONTROL-B invocations, provided that
the invocations all originated from the same job.
ALL The mission entry is always eligible for further checking. Option
ALL enables the mission entry to be invoked regardless of the JOB
and STEP that previously invoked the mission entry.
The first mission that matches the above criteria is selected for execution. If no matching
mission is found, a runtime error occurs.
General ...........................................................................................................................................7-1
CONTROL-T Real-Time Environment ....................................................................................7-2
Initialization ...............................................................................................................................7-2
Procedure CTTINIT....................................................................................................................7-3
Loading of Rules .........................................................................................................................7-6
Termination ................................................................................................................................7-6
New Day Procedure.....................................................................................................................7-7
New Day Functions ....................................................................................................................7-7
New Day Processing..............................................................................................................7-7
Repository Structure...................................................................................................................7-9
Media Database Structure .........................................................................................................7-9
Data File Contents ..............................................................................................................7-10
Fields in the Data File.........................................................................................................7-11
Index File Contents .............................................................................................................7-12
Structure of the Trace File.......................................................................................................7-17
Structure of the Stacking Database ........................................................................................7-18
Repository Maintenance ......................................................................................................... 7-19
Verifying Data Integrity of Media Databases.........................................................................7-19
Manual Update of the Media Database...................................................................................7-21
Enlarging the Media Database................................................................................................7-21
Enlarging the Trace File ..........................................................................................................7-22
Enlarging the Stacking Database............................................................................................7-24
Repository Backup and Recovery......................................................................................... 7-25
General ......................................................................................................................................7-25
Media Database Backup...........................................................................................................7-25
Media Database Recovery ........................................................................................................7-25
Disaster Recovery .....................................................................................................................7-26
Selective Recovery ....................................................................................................................7-27
Cartridge Message Display Customization......................................................................... 7-27
CONTROL-R Support for CONTROL-T................................................................................ 7-29
CONTROL-R Driver Exit CTRX001G.....................................................................................7-29
Installing the CONTROL-R Interface.....................................................................................7-29
CONTROL-T Application Programming Interface ........................................................... 7-30
Background Information......................................................................................................... 7-31
CONTROL-T Control Table (TCT).......................................................................................... 7-31
Creating a Local TCT .............................................................................................................. 7-32
Obtaining the Address of the Real-Time TCT........................................................................ 7-33
Media Database Structure ...................................................................................................... 7-34
Base Level vs. High Level API ................................................................................................ 7-34
Base Level API ........................................................................................................................... 7-35
Record Access by the Base Level API ..................................................................................... 7-35
Macro CTTIOS......................................................................................................................... 7-36
Base Level API Access of the Media Database....................................................................... 7-40
Examples for Base Level API.................................................................................................. 7-42
Macro CTTACCDB .................................................................................................................. 7-54
Macro CTTCHKDB.................................................................................................................. 7-55
Media Database Error Handling Routine .............................................................................. 7-56
Example for High Level API ................................................................................................... 7-57
Input ......................................................................................................................................... 7-61
Output ...................................................................................................................................... 7-61
Invoking the Rule Search API................................................................................................. 7-63
Sample Call to the Rule Search API.................................................................................. 7-64
Return Codes....................................................................................................................... 7-64
Sample For Using the Rule Search API ................................................................................. 7-65
General
This section describes how the different components and files of CONTROL-T are
activated, controlled, and maintained on a regular daily basis. The following topics are
discussed in this section:
CONTROL-T Real-Time Environment
New Day Procedure
Repository Structure
Repository Backup and Recovery
Cartridge Message Display Customization
CONTROL-T Application Programming Interface
Some administrative tasks are performed via CONTROL-T utilities. The available utilities
are described in detail in Section 9 of this guide.
Additional customization and security measures can be implemented via CONTROL-T
exits. The available CONTROL-T exits are described in Section 10 of this guide.
Note As of CONTROL-T Release 5.1.4, certain topics have been moved to the CONTROL-T
Implementation Guide. These include: Interfaces for robots, DFSMS, and EDMs, as
well as detailed information about dataset stacking implementation.
CONTROL-T Real-Time Environment
The Real-Time environment of CONTROL-T is established during the Initialization process.
Once the Real-Time environment is established, CONTROL-T takes control of tape volumes
processed in the system. This is accomplished by the MVS interfaces of CONTROL-T.
CONTROL-T performs extensive validity checks to ensure the data integrity of the media
library at the site. In addition, stacking can be performed for non-specific mount requests.
As a dataset moves through the system, CONTROL-T gathers relevant information,
searches rules to determine the required actions (such as retention and vaulting
information), and updates the Media Database.
These topics are described on the following pages.
Initialization
The first step in using CONTROL-T is to initialize CONTROL-T in each CPU. This is done
by procedure CTTINIT. CONTROL-T is usually initialized as part of the IPL process.
Procedure CTTINIT performs the following steps to establish the CONTROL-T Real-Time
environment:
Creates the main CONTROL-T Control Table.
Loads rule tables, pool definitions, and vault definitions into common storage.
Opens the files necessary for the Real-Time environment: Media Database, Trace file,
and Stacking Database.
If requested by the user, loads and defines the CONTROL-T SVC. (The SVC number is
specified as an installation parameter.)
If requested by the user, establishes interfaces between CONTROL-T and MVS by
setting intervention points in MVS where CONTROL-T obtains control. These
interfaces remain until a termination process is run.
Establishes the WTO (Write to Operator) Intercept so that mount messages can be
modified.
Initializes the subsystem for handling stacking and other functions.
Note DD statement STEPLIB must not be removed from procedure CTTINIT. The CTTINIT
procedure will not function properly if this DD statement is removed.
The CONTROL-T Control Table (TCT) is a block of information in common storage
containing key control data and pointers. Its common storage address is used by all
real-time components (e.g., the CONTROL-T SVC and the subsystem) and certain other
components (e.g., EDM expiration exits). All activity starts from the TCT, which contains
pointers to all CONTROL-T tables and modules in storage. The TCT, along with its related
routines, remains in common storage until CONTROL-T is shut down.
Upon completion of the initialization process, CONTROL-Ts Real-Time environment is
established and CONTROL-T takes control of removable media processing.
After initialization, no address space is needed for the CONTROL-T environment.
Procedure CTTINIT
Procedure CTTINIT controls the initialization, termination, and operation of CONTROL-T.
This procedure is invoked by operator command:
S CTTINIT,PARM=MODE=xxxxx[,DBGLEVEL=nnn,DBGJOB=xxxxxxxx]
The PARM field can contain one of the MODE= values described below:
Note The MODE keyword can be omitted. For example, PARM=MODE=INIT and
PARM=INIT are equivalent.
Parameters Relating to Initialization/Termination/Refreshing
MODE=INIT Initializes CONTROL-T. For details on how CONTROL-T is
initialized, refer to Initialization in Section 4 of the CONTROL-T
User Manual. This command must be issued on each MVS system in
which CONTROL-T is to be activated.
MODE=TERM Terminates CONTROL-T. This command must be issued on each MVS
system in which CONTROL-T was activated.
MODE=RELOAD,EXIT=exit
Loads a new copy of a CONTROL-T exit without the need to restart
CONTROL-T. Specify the full name of the exit module, e.g., CTTX004.
Note Reloadable exits are: CTTX002, CTTX003, CTTSE03, CTTX004,
CTTSE04, CTTX005, CTTX006, CTTSE06, CTTX009,
CTTSE09, CTTX010 and IOAX035.
MODE=RELOAD,TBLT=RULE
When CONTROL-T is initialized, it reads a list of rule tables from the
member referenced by DD statement DARULLST in procedure
CTTINIT. The supplied default member RULLIST is in the
CONTROL-T PARM library. For every line in the list, CONTROL-T
loads the specified rule table from the specified library.
To replace all currently active rules with a new (updated) copy of the
rules, issue operator command:
S CTTINIT,PARM=MODE=RELOAD,TBLT=RULE
MODE=RELOAD,TBLT=POOL
When CONTROL-T is initialized, it reads pool definitions from the
member referenced by DD statement DAPOOLS in procedure
CTTINIT. These pools are defined via the CONTROL-T Pool Definition
screen.
If you modified or added pools and you want to replace the currently
active pools with a new (updated) copy of the pools, issue operator
command:
S CTTINIT,PARM=MODE=RELOAD,TBLT=POOL
MODE=RELOAD,TBLT=VAULT
When CONTROL-T is initialized, it reads vault definitions from the
member referenced by DD statement DAVLTS in procedure CTTINIT.
These vaults are defined via the CONTROL-T Vault Definition screen.
If you modified or added vaults and you want to replace the currently
active vaults with a new (updated) copy of the vaults, issue operator
command:
S CTTINIT,PARM=MODE=RELOAD,TBLT=VAULT
MODE=RELOAD,TBLT=PARM
The following CTTPARM options can be modified while CONTROL-T
is active. There is no need to shut down CONTROL-T.
ABENDACT BLPDEF CNGMSGID
DAYTIME DEFABEND DEFEXPDT
DSNMCHK DYNDS DYNVOL
EXPDTDDN EXPDTYPE EXTRNVOL
LBLROUTC MODE MSGFMT
NLASKOP OVERJCL PARALLEL
RBTTYPE RECREATE, RTNUPD
SCRPROT SMSINTR STKDEFFT
STKMODE STKSRCHL STKTEST
VLTBYDS1 X98ASKOP
To modify these options, run job CTTPARMJ to create a new
CTTPARM module. Then issue operator command:
S CTTINIT,PARM=RELOAD,TBLT=PARM
Parameters Relating to MVS Interfaces
MODE=VERIFY Verifies that CONTROL-T MVS interfaces can be applied and the SVC
can be installed.
This mode can be used during CONTROL-T installation, or when
bringing up a new MVS version, to determine if CONTROL-T can be
initialized.
MODE=CHECK Checks if CONTROL-T MVS interfaces are already applied and the
SVC already installed.
Because CONTROL-T has no active address space (job or started task)
in the system, this mode is used to determine if CONTROL-T is up.
VERIFY can be executed only if the CONTROL-T Real-Time environment is not active.
CHECK can be executed whether or not CONTROL-T is active.
Parameters Relating to Operating Status
MODE=DORM Makes CONTROL-T temporarily dormant. After this command is
issued, CONTROL-T does not intervene in any job, does not check
expiration dates, etc.
The CONTROL-T environment (CONTROL-T tables, rules, I/O control
blocks, etc.) is saved.
MODE=SUSPEND Temporarily suspends removable media activity. After this command
is issued, all jobs which access removable media wait for an operator
reply specifying how to proceed. The operator can specify that
processing should continue without CONTROL-T, should wait for a
RESUME command, or should abend.
The CONTROL-T environment (CONTROL-T tables, rules, I/O control
blocks, etc.) is saved.
MODE=RESUME Causes normal CONTROL-T operations to resume after
MODE=DORM or MODE=SUSPEND commands were issued.
MODE=STOPSTK Stops the Dynamic Stacking facility.
MODE=STARTSTK Starts/restarts the Dynamic Stacking facility.
Problem Resolution Parameters
Note The following parameters should only be used if requested by your IOA representative
or Technical Support.
DBGLEVEL or DL Debug level. A numeric value from 0 to 255 can be specified.
0 No debug messages are printed.
1-255 Debug messages are printed.
DBGJOB or DJ Name of the job for which debugging should be enabled. If DBGJOB is not
specified, or DBGJOB=ALL is specified, debugging is enabled for all jobs.
Sample JCL for procedure CTTINIT can be found in the CONTROL-T Procedure library.
The following DD statements are important for managing and maintaining CONTROL-T:
DARULLST References a member which contains a list of the rules that should be
loaded upon initialization/reload.
Example
* CTT.V514.RULES BKPRULE ORDER
* CTT.V514.RULES SAVRULE ORDER
For additional information see Loading of Rules below.
DAPOOLS References a member that contains pool definitions. By default, this
member is $$POOL in the PARM Library. Several pool definition
members can be concatenated and specified with this DD statement.
DAVLTS References a member that contains vault definitions. By default, this
member is $$VAULT in the PARM Library. Several vault definition
members can be concatenated and specified with this DD statement.
Loading of Rules
When CONTROL-T is started (or rules need to be re-loaded), CONTROL-T attempts to read a
list of rule tables from the member referenced by DD statement DARULLST. These rule
tables are automatically loaded by CONTROL-T. The supplied default member RULLIST is
in the CONTROL-T PARM library. Each line in the list has the following format:
date library table operation
where:
date The date of the rule table. If a specific date is designated, it is used to
analyze the Basic Scheduling parameters (see below). The date format
is mmddyy, ddmmyy, or yymmdd (depending on the site standard).
Specifying an asterisk (*) indicates the current CONTROL-T Working
Date.
library Name of the library in which the rule table is located.
table Name of the rule table.
operation Operation to be performed on the rules in the specified table. Valid
values:
ORDER Each rules Basic Scheduling parameters are compared to
the specified date (or the current CONTROL-T Working
Date when * is specified). If the rule should be scheduled
on that date, the rule is loaded by CONTROL-T and
activated. Default.
FORCE Each rule is loaded by CONTROL-T and activated. Use the
FORCE option when you do not want to use CONTROL-T
scheduling options.
For every line in the list, CONTROL-T loads the specified rule table from the specified
library.
Termination
CONTROL-T should be in operation from computer startup to shutdown (i.e., all the time)
so that it can intercept all removable media management activities. Information about jobs
which access removable media, is not recorded.
When CONTROL-T is terminated, a check is triggered for active jobs which access
removable media in the system. If such jobs exist, the operator is prompted to cancel the
termination, retry the termination, or continue (force) the termination.
When CONTROL-T is terminated, all traces of the CONTROL-T Real-Time environment
are removed from the system, including the following:
Interfaces established between CONTROL-T and MVS (i.e., intervention points in
MVS).
The CONTROL-T SVC.
The WTO Intercept is disabled and mount messages are no longer modified.
New Day Procedure
The New Day procedure is the primary mechanism used to perform daily maintenance on
the CONTROL-T Media Database and related files.
The New Day procedure, called CTTDAY, can be activated automatically by a scheduler
(e.g., CONTROL-M) at a predefined time each day. The New Day procedure can also be
activated manually by submitting a job.
New Day Functions
The maintenance operations illustrated and described below are performed by the New
Day procedure:
New Day Processing
1
1
The order of processing may be changed in certain situations.
Check CONTROL-T Operation Mode
Procedure CTTINIT (with MODE=CHECK specified) checks
whether or not CONTROL-T is active, and whether or not
Dynamic Dataset Stacking is operational. This step also checks
the expiration date of the CONTROL-T password.
Rule Refresh Procedure CTTINIT can be invoked with parameter
MODE=RELOAD to refresh CONTROL-Ts active rules. The
user should consider whether or not this step should be
included in the New Day procedure. The following are some
considerations that should be taken into account:
1. Rules are automatically refreshed when CONTROL-T is
initialized (usually when an IPL is performed). If a rule
definition is changed (in the Definition Library), the
modified definition takes effect only when the next IPL is
performed (monthly, weekly, etc.).
2. The retention management and vault management utilities
optionally load rules from the library as their first step. In
this case, all subsequent retention and vault decisions are
based on refreshed rules.
While these utilities may operate with new, refreshed rules,
the CONTROL-T Real-Time environment continues to use
the older, original rules in memory.
To avoid confusion over which rule definitions are being
accessed, the user can implement the Rule Refresh option at
any time. Because of this situation, a rule refresh step is
usually performed as the first step of the New Day
Procedure.
3. CONTROL-Ts Rule Scheduling facility (enabled by
specifying Scheduling parameters while defining rules)
allows you to define when rules should be activated based on
calendars and scheduling criteria. For example, this allows
you to specify a different retention period for the same
dataset when that dataset is created on weekdays and
weekends.
Retention Management Utility CTTRTM scans the Media Database and determines
which volumes/datasets have expired. These volumes are
marked as scratch volumes in the CONTROL-T Media Database.
This utility can also produce various reports concerning the
current status of scratch volumes in the Media Database.
Vault Management Utility CTTVTM determines which volumes should be moved
and the locations to which they should be moved. This utility can
also produce a distribution report.
Stacking Database Utility CTTSTK updates the Stacking file with new statistics
collected on each dataset. This utility uses data from the Trace file.
Media Database Backup This backup consists of the following steps:
1. Writing a Started Media Database Backup record to the
Trace file.
2. Backing up the Media Database data file and the Trace file
using any standard backup utility. In the supplied job,
utility IEBGENER is used for the backup.
3. Writing an Ended Media Database Backup record to the
Trace file.
This backup can be used if a Media Database restore is
required. See Repository Backup And Recovery later in this
section.
Check Media Database Integrity
Utility CTTIDB is run to check the Media Database for integrity
errors. See utility CTTIDB in Section 9 for more information.
Repository Structure
The CONTROL-T Repository is composed of the following files:
Media Database
Trace file
Stacking Database (called the Stacking Statistics file prior to Release 5.1.4)
Note CONTROL-T databases and the Trace file should be placed on disks that will not get
defragmented while CONTROL-T is running. If your site uses a disk defragmentor,
place the CONTROL-T TRC, MDBD, MDBI, STKD and STKI datasets in an "exclude
list" to prevent the defragmentor from processing them.
Media Database Structure
The CONTROL-T Media Database is composed of the following primary physical files:
Data file Contains all required data about volumes and datasets in the Media
Database.
Index file Provides keyed access to data in the Data file.
Note Another file, the Trace file, is used to track updates and facilitate recovery of the Media
Database. (See Structure of the Trace File later in this section for more information.)
The Data and Index files are allocated via the following DD statements:
Data file DD statement DAMDB
Index file DD statement DAMDI
Note Although these files are sequential and may be read using standard MVS QSAM
services, the structure or format of these files may change in future releases. Therefore,
it is highly recommended that the Media Database be accessed only via the standard
macros described in CONTROL-T Application Programming Interface later in this
section.
Data File Contents
The Data file contains all the data about any volume or dataset. In CONTROL-T, unlike
other tape management systems, volume information and dataset information are stored in
the same file, but with different record types and formats.
The two most common record types in the CONTROL-T Data file are:
Volume record Contains information regarding a volume.
Dataset record Contains information regarding a dataset.
Note Additional record types and formats in the database are not described because they are
not relevant for most users.
Volume and dataset records are mapped via Assembler macros CTTDVL and CTTDDS,
respectively. All record types in the Data file have a common header at the beginning of
the record. This header contains the following information about the record:
RBA Internal record location identifier (explained later in this section).
Each record in the Data file is assigned an RBA that indicates the
location of the record in the Data file. The format of the CONTROL-T
RBA is bbr. The first two bytes identify the block number in the Data
file and the last byte identifies the record number in that block.
Access to a specific Data file record can be performed via its RBA if
known (or via the index, as explained later in this section). Access of a
data record via its RBA is known as non-keyed access.
Record Status Indicator
Indicates whether the record is active or free.
Record Type Indicates whether the record is a volume or dataset record.
Note The term RBA as used in this section should not be confused with the term Relative
Byte Address used in IBM literature.
Fields in the Data File
Some of the more important fields in the volume and dataset records in the Data file are
listed in the table below. Each field is assigned an internal name (a symbol in a DSECT
which describes the record) and an external name (a logical name used by the user in
INCLUDE/EXCLUDE statements). A comprehensive list of these fields can be found in
Logical Field Names for the CONTROL-T Repository in Appendix D of this guide and in
the IOA MAC library.
Commonly Referenced Volume Record Fields
Internal
Name
External
Name Description
DVLRBA DVLRBA RBA of the record.
DVLRID DVLRID Record status (A-Active, F-Free).
DVLRTYPE DVLRTYPE Record type (V-Volume record).
DVLSTAT
DVLSTA2
VOLSTAT
VOLIND
Various status and flag bytes.
DVLFLG1 VOLFLAGS Various status and flag bytes.
DVLVOLSR VOLSER Volume serial number.
DVLLTYPE LBLTYP Label type of the volume.
DVLACTD# ACTIVEDS Number of active (non-expired) datasets on the
volume.
DVLLBLNM LBLNUM Label number of the last active dataset on the volume.
DVLVSEQ VOLSEQ Volume sequence number for a volume that is part of
a multi-volume chain.
DVLNEXT NEXTVOL Next volume (of the multi-volume chain).
DVLPREV PREVVOL Previous volume (of the multi-volume chain).
DVLFIRST FIRSTVOL First volume (of the multi-volume chain).
Commonly Referenced Dataset Record Fields
Internal
Name
External
Name Description
DDSRBA DDSRBA RBA of the record.
DDSRID DDSRID Record status (A-Active, F-Free).
DDSRTYPE DDSRTYPE Record type (D-Dataset record).
DDSSTAT DSSTAT Various status bytes
DDSFLG1 DSFLAGS Various flag bytes.
DDSDSN DSNAME Dataset name.
DDSLBLNM DSLABEL Label number (dataset sequence number on the tape).
DDSVOLSR DSVOLSER Volser of the dataset (or the first volser of a
multi-volume dataset).
DDSVOLS# VOLSNUM Number of volumes in the dataset (if the file spans
multiple volumes).
Index File Contents
The Index file makes keyed access of records in the Data file possible. The Index file
contains records which, in turn, contain index elements. Each index element contains the
following information:
Key Type D, V, or L (see Key Types below).
Key Information which used to identify a record in the data file. Each
index element contains one key only.
RBA Internal record location identifier of the relevant record in the Data
file.
Additional info Bytes used by repository handling mechanisms.
Key Types
Each index element contains a particular type of key which is used for accessing records in
the data file.
Full and partial keys of each type, are described below:
V Used to index volume records in the Data file. One index element
containing one V-type key is created for each volume record in the
Data file. The full V-type key for each volume record is the full volume
serial number. This is a unique key.
D Index to dataset records in the Data file. One index element
containing one D-type key is created for each dataset record in the
Data file. The full D-type key for each dataset record is the full
dataset name. Because duplicate dataset names may exist in the
media library, this is a non-unique key (i.e., more than one index
element may exist with the same D-type key).
L Index to dataset records in the Data file. An element with an L-type
key is created for each volume on which a specific dataset resides. For
example, if a dataset record indicates that the dataset spans three
volumes, three L-type keys (one for each volume) are created to
reference that dataset record. The full L-type key is comprised of the
full volume serial number and the full file sequence number (label) of
the dataset on the volume. This is a unique key.
Depending on the function being performed when accessing the Index file (described later
in this section), a full key or a partial key may be specified.
A partial key is shorter than the full length of the key in the index file. The most common
usage of a partial key is the specification of a prefix (e.g., dataset name prefix instead of a
full dataset name). Partial keys can also be used when all necessary information is not
available.
All index elements have the same fixed length, which is determined by the index elements
with D-type keys because the D-type key is the longest full key (i.e., the dataset name).
Index element length exceeds the length of the longest key because index elements contain
additional bytes which are used by the CONTROL-T Repository handling mechanisms.
Index elements with V-type keys are mapped via assembler macro CTTDVX. Index
elements with D-type keys are mapped via assembler macro CTTDDX. Index elements with
L-type keys are mapped via assembler macro CTTDLX.
Volume/Dataset Relations
The Media Database Data file contains a record for each volume and a record for each
dataset. Fields in these records, and indexes of various types, are used to describe the
relationships between a volume and its respective datasets. These fields and indexes also
describe the relationship between volumes in a multi-volume chain.
The examples below show the relationship between the relevant fields in the volume
records, dataset records, and the index elements that reference these records.
Example 1
This example shows the record and index configuration for a single volume (VVV)
containing only one dataset (called A.B).
Example 2
This example shows the record and index configuration for a single dataset (A.B) that
spans two volumes (VVV and XXX).
Example 3
This example shows the record and index configuration for a group of datasets (A.B, A.C,
and A.D) contained in a multi-volume chain (volumes VVV and XXX). Dataset A.B resides
on volume VVV. Dataset A.C starts on volume VVV and continues on volume XXX. Dataset
A.D resides on volume XXX.
Structure of the Trace File
The Trace file is used for the following primary purposes:
To track updates of the Media Database. This information is used to facilitate recovery
of the Media Database when necessary.
To serve as a queue for requests to be performed by the IOA Functional monitor.
The Trace file is automatically maintained by CONTROL-T mechanisms that handle the
Media Database and the requests to the IOA Functional monitor.
The length of logical records in the Trace file can vary, depending on the type of
information in the record.
Logical records in the Trace file are composed of a header (mapped by macro CTTARC)
followed by the record data (mapped by the macro relevant for the type of traced action).
The Trace file is processed as a cyclic file. When the file is full new records overwrite the
oldest logical records. When the physical end-of-file is reached, the next record is written
on the first physical record.
Fields in the Trace File
Some of the more important fields in the Trace file are listed below. A comprehensive list of
these fields can be found in Logical Field Names for the CONTROL-T Repository in
Appendix D of this guide, and in the IOA MAC Library.
ARCLL Record Length.
ARCTYPE Record type.
ARCIDENT Name of the component that generated this record.
ARCSTAMP Record time stamp (i.e., when the record was created).
ARCDATA Actual information that is recorded.
Note The Trace file can be copied to a sequential variable-blocked file,
enabling the output to be formatted in a number of different
ways. (See the description of utility CTTACP in Section 9 of this
manual for more information.)
Structure of the Stacking Database
The Stacking Database (called the Stacking Statistics file prior to Release 5.1.4) contains
statistical information about datasets processed by CONTROL-T. This information is
gathered from various locations (e.g., the Media Database, or the Trace file) by utility
CTTSTK. The information in this file is used by the Dynamic Dataset Stacking facility in
the real-time environment.
The Stacking Database is composed of the following physical files:
Data file Contains statistical information about datasets processed by CONTROL-T.
Index file Provides keyed access to data in the Data file.
Records in the Data and Index files are mapped by Assembler macros CTTSTK and
CTTSTX, respectively.
Data File Contents
The Data file contains statistical information about datasets that have been processed by
CONTROL-T. A dataset is identified by its name and the name of the job which created the dataset.
All record types in the Data file have a common header at the beginning of the record. This
header contains the following information about the record:
RBA Internal record location identifier. The format of the CONTROL-T RBA is
bbr. The first two bytes identify the block number in the Data file and the
last byte identifies the record number in that block.
Record Status Indicator
Indicates whether the record is active or free.
Record Type Indicates whether the record is a volume or dataset record.
Each record in the Data file is assigned an RBA that indicates the location of the record in
the Data file.
Access to a specific data file record can be performed via its RBA if known, or via the index.
Access of a data record via its RBA is known as non-keyed access.
Note The term RBA as used in this section should not be confused with the term Relative
Byte Address used in IBM literature.
Fields in the Data File
A comprehensive list of these fields can be found in the IOA MAC Library and in
Appendix D: Logical Field Names for the CONTROL-T Repository in this guide .
Index File Contents
The Index file contains index records. These index records enable keyed access to records
in the Data file.
Verifying Data Integrity of Media Databases
In the CONTROL-T Media Database, data of different types are stored in separate records
that are linked via the following mechanisms:
Data fields in data records, which reference other data records (e.g., field DDSVOLSR in
a dataset record indicates the record of the volume containing the beginning of the
dataset).
Index records which link data records (e.g., the L-index record).
Counters within data records (e.g., field DVLACTD# in a volume record indicates the
number of datasets in the volume).
Media Database integrity is the degree to which the links between data/index records are
free of errors. A high level of integrity is necessary to ensure smooth processing by
CONTROL-T. Use utility CTTIDB to check Media Database integrity on a daily basis (e.g.,
as a part of the CONTROL-T New Day Procedure).
Causes of Media Database Integrity Errors
As a rule, normal tape processing by CONTROL-T should not cause integrity errors.
However, such errors can be caused by external events that interrupt CONTROL-Ts
processing, resulting, for example, in partially updated records. Some common causes of
integrity errors are:
System-crash.
Cancellation of a job that accesses tapes in the middle of its processing.
Interruption of a CONTROL-T utility that updates records in the Media Database.
Processing CONTROL-T databases or the Trace file by a defragmentation program
while CONTROL-T is running.
Examples of Errors Due to Interruption of CONTROL-T Processing
A volume record points to the next record in a multi-volume chain (via the NEXTVOL
field), but that volume does not point back (field PREVVOL).
A dataset does not span the number of volumes indicated in the record for that dataset.
An L-index points to a scratch volume.
Integrity errors should not occur often. If utility CTTIDB detects an unusually large
number of integrity errors, it is recommended that you immediately investigate the cause
of these errors and fix the problem.
Recovery From Integrity Errors
Some integrity errors are automatically resolved by CONTROL-T:
L-indexes that point to a scratch volume are removed as soon as the scratch volume is
mounted in response to a scratch tape request.
Some utilities (i.e., CTTRTM and CTTVTM) have restart capabilities which allow them
to continue from the point at which the utility was interrupted.
Integrity errors that are not automatically fixed by CONTROL-T should be handled by first
studying the nature of the error, and then determining what Media Database updates
should be performed to correct the error.
Analyzing an Integrity Error
Check the output of utility CTTIDB every day. If an integrity error is detected, you should
be able to determine the type of error, and which data/index records are involved, from the
output of the utility. Below is a list of the most common integrity errors detected via utility
CTTIDB:
Information in a data record and corresponding information in an index record do not
match.
A counter field in a data record has an incorrect value.
A group of volumes is chained incorrectly or some volumes in the chain have conflicting
attributes (e.g., vaulting criteria).
Data fields linking data records point incorrectly.
A scratch volume points to, or is pointed to, by an active volume record.
Chose the method used to correct the error based on information in the output of utility
CTTIDB and, optionally, in record data viewed via the Inquire/Update Media Database
Screen (screen TI).
Correcting Integrity Errors
Integrity errors are corrected by updating the data records and/or index records in error.
Errors involving data records should be corrected, one at a time, via utility CTTMUP. After
fixing each error, it is recommended that you rerun utility CTTIDB, because fixing one
error often eliminates other errors. This can be done automatically by specifying
CHECK=YES in the TYPERUN statement of utility CTTMUP. The output of utility
CTTIDB after it is rerun will indicate the integrity errors that remain.
Utility CTTMUP can also be used to fix most index related problems by rebuilding the
indexes for a volume, a dataset, or a group of volumes and datasets.
If a large number of index errors are found in the Media Database, consider fixing these
errors by rebuilding the index component via utility CTTBIX.
Notes If you choose to rebuild the index of the Media Database, it is necessary to first halt all
tape processing.
For a detailed description of utilities CTTIDB, CTTMUP and CTTBIX see Section 9 of
this guide.
Manual Update of the Media Database
Manual update of the Media Database is accomplished via utility CTTMUP. This utility
can be used to add new volume/dataset records to the Media Database, or to fix integrity
errors detected via utility CTTIDB.
Before using utility CTTMUP, it is important to understand the structure of the Media
Database (described earlier in this section). Attempting to fix integrity errors without
properly understanding the Media Database structure can lead to even more integrity
errors.
When updating a volume record, utility CTTMUP does not always automatically update
the corresponding dataset records, and vice versa. When updating data fields that are used
to link records, be sure to update all relevant records so that no new integrity errors are
created. For example, when you add a dataset to a volume, verify that the new number of
datasets is recorded in the volume record.
When updating groups of volumes (multi-volume chains), use the group statements (prefixed
GRP) to implement the desired change in the records of all the volumes in the group.
After performing the necessary updates, it is highly recommended that you run utility
CTTIDB to verify the results. This can be accomplished by running the utility manually, or
by including CHECK=YES in the TYPERUN statement of utility CTTMUP. See the
description of utility CTTMUP in Section 9 of this guide for more information about
manual update of the Media Database.
Enlarging the Media Database
At times, it may become necessary to increase the size of the Media Database (MDB). This
situation arises if one of the Media Database components (index or data) is almost at
maximum capacity, or if extensive additions to the Media Database need to be made in the
near future.
To enlarge the Media Database:
1. Calculate the space needed for your Media Database.
To calculate the amount of space needed, see Media Database Calculations in Section
9 of the IOA Installation Guide. The Media Database can be enlarged by increasing the
number of blocks, by enlarging the block size, or via a combination of the two methods.
(By following the instructions listed here, any of these extension methods are possible.)
2. Shut down CONTROL-T via operator command:
S CTTINIT,PARM=MODE=TERM
3. Back up the active Media Database by running CONTROL-T utility CTTDBDUL, IBMs
utility IEBGENER, or any similar tool.
4. Create and format new Media Database data components by running the same job
which is run at installation time to allocate Media Database components (see step
CONTROL-T Media Database in the CONTROL-T Installation Procedure in the IOA
Installation Guide), but with a larger allocation size.
Notes Before running this job, verify that at least one of the procedure parameters
(DBPREFT and DBFILET) which compose the Media Database component names
is modified. By doing so, the active Media Database will not be affected.
The Media Database should be placed on disks that will not get defragmented
while CONTROL-T is running. If your site uses a disk defragmentor, place the
MDBD and MDBI datasets in an "exclude list" to prevent the defragmentor from
processing them.
5. Unload the Media Database data component via CONTROL-T utility CTTDBDUL.
6. Rename the production Media Database data component and index component.
7. Rename the newly-created Media Database data component to the name of the
production data component. Rename the newly-created Media Database index
component to the name of the production index component.
8. Reload the Media Database data component into the new (and larger) data component
via CONTROL-T utility CTTDBDLD.
9. Run utility CTTBIX.
10. Restart CONTROL-T via operator command:
S CTTINIT,PARM=MODE=INIT
Enlarging the Trace File
At times, it may be necessary to increase the size of the CONTROL-T Trace file. This
situation arises if the Trace file often reaches maximum capacity, or if an increase in tape
activity at your site is imminent.
To enlarge the Trace file:
1. Calculate the space needed for the Trace file.
To calculate the space needed, see the topic Trace File under Planning and Space
Calculation and the topic Trace File Calculations in Section 9 of the IOA Installation
Guide. At this stage, you should also determine the correct value of installation
parameter TRCSIZE in member CTTPARM in the IOA INSTCTT library. The Trace file
can be enlarged either by increasing the number of blocks, by enlarging the block size,
or by a combination of these methods. By following the instructions listed here, any of
these extension methods are possible. (For more information about parameter
TRCSIZE, see Section 9 of the IOA Installation Guide.)
3. Back up the active Trace file via CONTROL-T utility CTTACP, IBM utility
IEBGENER, or any other similar tool.
4. Update installation parameter TRCSIZE in member CTTPARM of the IOA INSTCTT
library according to the size of the new Trace file.
5. Run job CTTPARMJ (located in the INSTCTT library). Running this job makes the new
value of TRCSIZE available.
6. Create and format a new Trace file by running the same job used at time of installation
to allocate the Trace file, but with a larger allocation size.
Note Before running this job, verify that at least one of the procedure parameters
(DBPREFT and DBFILET) which compose the Trace file name is modified. By
doing so, the active Trace file is not affected.
The CONTROL-T Trace file should be placed on disks that will not get defragmented
while CONTROL-T is running. If your site uses a disk defragmentor, place the TRC
dataset in an "exclude list" to prevent the defragmentor from processing it.
7. Rename the production Trace file.
8. Rename the newly-created Trace file to the former name of the production Trace file.
9. Copy the old Trace file to the new (and larger) Trace file via CONTROL-T utility
CTTACP. An example of CTTACP activation is provided below:
//name JOB ,IOA,CLASS=A,MSGCLASS=X
//*
//* COPY ONE CONTROL-T TRC DATASET TO ANOTHER TRC
//*
//TT2ACP EXEC CTTACP,
// TRCIN=CTT.V514.TRC.OLD,
// TRCOUT=CTT.V514.TRC
//SYSIN DD *
COPY FROM=TRACE,TO=TRACE
//
Enlarging the Stacking Database
At times, it may become necessary to increase the size of the Stacking Database. This
situation arises if one of the Stacking Database components (index or data) is almost at
maximum capacity, or if extensive additions to the Stacking Database need to be made in
the near future.
To enlarge the Stacking Database:
1. Calculate the space needed for your Stacking Database.
To calculate the amount of space needed, see Stacking Database Calculations in
Section 9 of the IOA Installation Guide. The Stacking Database can be enlarged by
increasing the number of blocks, by enlarging the block size, or via a combination of the
two methods. (By following the instructions listed here, any of these extension methods
are possible.)
3. Back up the active Stacking Database by running CONTROL-T utility CTTDBDUL,
IBMs utility IEBGENER, or any similar tool.
4. Create and format new Stacking Database components by running the same job which
is run at installation time to allocate Stacking Statistic file components (see Minor step
Stacking Database in Section 9 of the IOA Installation Guide), but with a larger
allocation size.
Notes Before running this job, verify that at least one of the procedure parameters (DBPREFT
and DBFILET) which compose the Stacking Database component names is modified.
By doing so, the active Stacking Database will not be affected.
The Stacking Database should be placed on disks that will not get defragmented while
CONTROL-T is running. If your site uses a disk defragmentor, place the STKD and
STKI datasets in an "exclude list" to prevent the defragmentor from processing them.
5. Unload the Stacking Database data component via CONTROL-T utility CTTDBDUL.
6. Rename the production Stacking Database data component and index component.
7. Rename the newly-created Stacking Database data component to the name of the
production data component. Rename the newly-created Stacking Database index
component to the name of the production index component.
8. Reload the Stacking Database data component into the new (and larger) data
component via CONTROL-T utility CTTDBDLD.
9. Run utility CTTDBIB.
Repository Backup and Recovery
General
CONTROL-T has a comprehensive set of utilities which ensure data integrity and provide
full recovery in situations caused by system/disk crashes or user error. Two types of
recovery are possible: logical and physical. Each type is appropriate in specific situations.
Refer to the following chart to determine when to use each recovery method.
Comparison of Physical vs. Logical Recovery Methods
Physical Recovery Logical Recovery
When to use: After a physical disaster After user errors
What will be recovered: Entire Media Database Selected portions of the Media
Database
How the data is
recovered:
Via restore and
roll-forward
Via roll-back
The following pages briefly discuss backup procedures, followed by a description of the
procedures that the IOA administrator should perform in various situations. See Section 9
in this guide for a detailed description of the utilities mentioned below.
Media Database Backup
CONTROL-T provides several utilities to facilitate the backup and recovery process.
Backups can be performed at any time using batch utilities. At most sites, backups are
initiated by the New Day procedure.
Normally, the Media Database is backed up first. It updates the Trace file with the date and time
that backup started and completed. The Trace file is backed up as soon as the Media Database
backup completes successfully, Therefore, each Media Database backup has a corresponding Trace
file backup. All removable media processing can continue during this process.
Media Database Recovery
If the Media Database or some portion of it must be recovered:
Restore the latest Media Database backup using the standard site backup utility. Run
utility CTTRCV to apply all updates since that backup from the active Trace file (a
Roll-Forward process).
Based on the current Media Database, utility CTTRCV can withdraw all updates until
a certain point (a Roll-Back process).
Utility CTTRCV can also remove all updates in a specified time range or generated by a
specific job.
Once the restore is complete, all indexes are rebuilt by utility CTTBIX and the free
space chain is rebuilt by utility CTTDBID.
Disaster Recovery
CONTROL-T recovery is performed using the Trace file from the last Media Database
backup via several steps. First, a backup/restore utility (e.g., IEBGENER) is run to restore
the Media Database. Then, utility CTTRCV is run to roll forward all Trace file Updates
since the last backup. Utilities CTTBIX/CTTDBID are then run to rebuild the file structure
and indexes.
Note Run the index format utility (CTTDBF)Before rebuilding the index file.
Selective Recovery
This method recovers only a selection of changes which satisfy specified selection criteria.
For example, to undo the effects of a bad maintenance job (e.g., a retention management
job which ran with incorrect parameters) all decisions/actions made by this job should be
reversed. Only selected portions of the Media Database are recovered. This is a logical,
backward recovery in two steps via utilities CTTRCV and CTTBIX/CTTDBID.
Note After completing the rollback updates, run utility CTTDBF to format the index and
then run utility CTTBIX to rebuild the index file.
Cartridge Message Display Customization
The CONTROL-T interface for displaying messages on cartridge magnetic tape subsystems
allows you to:
Display the first seven characters of a pool name on the cartridge drive LCD display
when a scratch tape is requested from a specific scratch pool.
Stop automatic cartridge load when two consecutive tape mounts result in the rejection
of the mounted tapes. To enable this feature, the Cartridge Stack Loader (CSL) must be
set to SYSTEM mode.
Message display installation exit IGXMSGEX enables you to customize messages to be
displayed on an IBM 3480 tape drive. This exit is optional and is invoked only if it is link-
edited with the message display execution module (IGX00030).
Installing the Message Display Interface
Installation of the message display interface is performed via the application of an SMP/E
USERMOD to your MVS SMP/E environment. This USERMOD introduces two
CONTROL-T CSECTs (IGXMSGEX and CTTMSGD) which are linked to module IGX00030
in the LPA library.
Note If another Message Display interface installed, is already remove it before installing
the CONTROL-T interface.
The steps described below are applied to your MVS SYS1.LPALIB library. You can apply
these changes to your MLPA library instead by overriding the LPALIB DD statement
(either through DDDEF or through your MVS SMP/E JCL procedure).
To install the CONTROL-T interface to the Message Display, perform the following steps:
1. Edit member IGXMSGEX in the IOA SAMPLE library. Member IGXMSGEX contains a
sample message display installation exit which allows control to be passed to several
modules for customization of MVS messages before they are displayed on an IBM 3480
tape drive. All modules to which control is to be passed are listed under label MODLIST
in this sample member. By default, this list contains one module CTTMSGD, the
CONTROL-T message customization module.
You can let other modules process tape drive messages in parallel with the
CONTROL-T interface (e.g., for parallel processing by CA-1) by adding an entry for
each of these modules under label MODLIST in sample member IGXMSGEX. (See
comments in this sample member for the format of module specifications.)
It is recommended that you save a backup copy of sample member IGXMSGEX before
modifying it. All changes to this sample member must be saved before proceeding step 2.
2. Use SMP/E online panels to find the Owning FMID of MOD IGX00030 and write it
down for later reference (Step 4a below).
3. Save a backup copy of module IGX00030 before continuing with the next step. This
module is located in your LPA library.
4. Edit member INSTMSGD in the IOA INSTCTT library. This member contains a job that
uses SMP/E to compile member IGXMSGEX and link-edit it with module IGX00030.
Tailor the job as follows:
A. Replace the FMID with the FMID obtained in Step 2.
B. Replace the SMP JCL procedure name with your sites MVS SMP/E JCL procedure.
C. Update the target zone name to reflect your MVS target environment name.
D. Add the IOA SMPPTS and IOA MAC libraries to your procedures SYSLIB specification.
Submit the job. The job should complete with a return code of 0.
To activate the CONTROL-T message display interface, either IPL your system or use a
system tool (e.g., RESOLVE) to dynamically add the new IGX00030 module to your
MLPA.
Note If you have already implemented the CONTROL-T Message Display Interface
(described above) and you wish to update member IGXMSGEX, repeat only step 4
(above) using job REDOMSGD instead of job INSTMSGD.
CONTROL-R Support for CONTROL-T
CTRX001 (CONTROL-R exit 1) must be defined as an interface between CONTROL-R and
CONTROL-T. This exit must be defined in addition to (not as a replacement for) any
previously defined CONTROL-R exit 1 (e.g., an interface between CONTROL-R and
another product such as HSM or CA-1).
The CONTROL-R Driver exit (described below) is used to invoke the CONTROL-T interface
exit 1 and any previously defined exit 1(s).
When CONTROL-R exit 1 is used for the CONTROL-T interface, it receives dataset
DELETE requests and changes the CONTROL-T controlled dataset status to Scratch. This
enables expiration of the specified dataset by the next run of Retention Management utility
CTTRTM. Via customization of this exit, you can cause CONTROL-T controlled datasets to
be scratched immediately (i.e., without running utility CTTRTM).
CONTROL-R Driver Exit CTRX001G
The CONTROL-R Driver exit optionally invokes multiple user exits which provide
programming interfaces to various dataset management software packages (e.g., HSM or
CONTROL-T). The CONTROL-R Driver exit sequentially invokes all user exits listed in its
source text (see step 4 below). Any number of single purpose CONTROL-R user exits can be
listed. See CONTROL-R Exits in Section 10 of this guide for more information.
Installing the CONTROL-R Interface
Perform the following steps to install the CONTROL-R to CONTROL-T interface.
1. Verify that YES is specified for CONTROL-R installation parameter TAPEMS in
member CTRPARM.
2. Compile and link the existing CONTROL-R exit 1 via member UMRXROOF in the IOA
SECUDATA library.
3. Use member UMRXROOF to compile and link the sample exit used to implement the
CONTROL-T to CONTROL-R interface. Member UMRXROOF is located in the IOA
SECUDATA library.
4. Compile and link Driver exit CTRX001G via member UMRX001 in the IOA SECUDATA library.
See member DOCRX001 in the IOA SECUDATA library for more information about the
logic implemented by this exit.
CONTROL-T Application Programming Interface
The CONTROL-T Application Programming Interface provides an interface between
CONTROL-T and user application programs. CONTROL-T API requests are performed
using Assembler macros. All macros mentioned in this section, including mapping macros,
are located in the IOA MAC library.
Calling programs can interface with CONTROL-T via either a base level or a high level
API. The differences between these types of API are discussed later in this section.
Note Examples of macro code usage and JCL are provided later in this section.
This section contains the following information:
Background Information
CONTROL-T Control Table (TCT)
Media Database structure
Base level vs. high level API
Base Level API
Record access by the base level API
Macro CTTIOS
Base level API access of the Media Database
Examples of macro access and base level API functions
High level API
Macro CTTACCDB
Macro CTTCHKDB
Media Database Error Handling Routine
Example of macro usage and JCL for high level API
Rule Search API
Input
Output
Invoking the Rule Search API
Sample Rule Search API
Background Information
Users should become familiar with the following background information before using the
CONTROL-T Application Programming Interface.
CONTROL-T Control Table (TCT)
CONTROL-T stores certain basic information (e.g., the values specified for CONTROL-T
installation parameters) in a control block called the CONTROL-T Control Table (TCT).
User-written APIs require access to the TCT in order to determine certain aspects of the
CONTROL-T environment.
The TCT is mapped by macro CTTTCT.
Note The TCT, and all other major CONTROL-T control blocks, are allocated above the
16MB line. Therefore, all programs using the CONTROL-T API must run in extended
addressing mode (AMODE 31).
Two types of TCTs are used by CONTROL-T APIs:
Local TCT A control block containing the values specified for CONTROL-T
installation parameters. A local TCT is used by base level APIs.
Programs which use the Base level API call a CONTROL-T routine
which creates a local TCT for use by that API. A local TCT can be
created regardless of whether or not CONTROL-T is active.
For more information about how to create a local TCT, see Creating a
Local TCT later in this section.
Real-Time TCT A control block containing information about the CONTROL-T
real-time environment. The Real-Time TCT contains all information
which appears in a local TCT and, in addition, it contains information
generated during CONTROL-T initialization (e.g., rule tables
addresses and for user exits).
The Real-Time TCT is used by the high level API and the Rule Search
API. The high level API uses its own internal method to access the
TCT. The Rule Search API requires the address of the Real-Time TCT.
This address is obtained via the CTTGTCT macro described below.
The Real-Time TCT is available only when CONTROL-T is active. It is
built by CONTROL-T during initialization and is kept in E/CSA
storage.
Creating a Local TCT
A local TCT must be created for each program which uses the Base-Level API. This task is
performed via routine CTTTLD which is called from a user-written program.
Use the following call to invoke routine CTTTLD:
CALL CTTTLD,(func-addr, tct-addr, 0, 0)
where:
func-addr Address of an eight-character field which describes the function to be
performed by routine CTTTLD. Valid values:
LOAD Create a local TCT.
DELETE Release the storage area used by the LOAD function call.
Routine CTTTLD should be called with this function after the
user-written program has finished using the base level API.
tct-addr Address of a full-word field in which the routine will insert the
address of the newly created local TCT.
Note The job step used to run the CTTTLD routine must include a DD statement which
references the IOA LOAD library which contains member CTTPARM.
Return Codes
Routine CTTTLD returns one of the following return codes in general register 15:
0 Local TCT created successfully
4 Invalid function
8 TCT could not be created
12 GETMAIN failed
Sample TCT Load Request
The following sample demonstrates a call to routine CTTTLD which creates a copy of the
local TCT.
CALL CTTTLD,(LOAD,TCTADDR,0,0) Load the TCT
LTR R15,R15 Successful ?
BNZ TCTFAIL No - Terminate
L R12,TCTADDR
USING TCT,R12
.
.
TCTFAIL WTO TCT LOAD FAILED, PROGRAM TERMINATED
.
.
LOAD DC CL8LOAD Constant for CTTTLD
TCTADDR DS A Address of TCT
.
TCT DSECT
COPY CTTTCT TCT mapping
Obtaining the Address of the Real-Time TCT
Each invocation of a Rule Search API must include the address of the Real-Time TCT. The address
of the Real-Time TCT is obtained via macro CTTGTCT.
Use the following call statement to invoke macro CTTGTCT:
CTTGTCT TCTADDR=tct-addr,TEST=ACT
where:
tct-addr Address of a full-word field to contain the address of the Real-Time
TCT which is returned by macro CTTGTCT. Optional. If no value is
specified for this parameter, the address of the Real-Time TCT is
returned in general register 1.
TEST An explicit request to check if CONTROL-T is active. A value of ACT
must be specified for this parameter.
Macro CTTGTCT alters the values in general registers 0, 1, and 15. If programs at your site
depend on the integrity of values in these registers, it is recommended that you save their values
before running macro CTTGTCT and restore them after the macro is completed.
Return Codes
Macro CTTGTCT returns one of the following return codes in general register 15:
0 Real-Time TCT address successfully obtained.
4 CONTROL-T is not active.
other TCT address could not be determined.
Sample TCT Address Request
The following sample demonstrates how macro CTTGTCT is called to obtain the address of
the Real-Time TCT:
CTTGTCT TCTADDR=ACTVTCT,TEST=ACT
LTR R15,R15 Active TCT obtained ?
BNZ TCTFAIL No - Terminate
L R12,ACTVTCT
USING TCT,R12
.
.
TCTFAIL WTO TCT NOT FOUND OR NOT ACTIVE, PROGRAM TERMINATED
.
.
COPY CTTSSVT | For use by
CVT CVT DSECT=YES,PREFIX=YES | Macro
IEFJSCVT | CTTGTCT
IEFJESCT |
ACTVTCT DS A Address of TCT
.
TCT DSECT
COPY CTTTCT TCT mapping
Media Database Structure
The API consists of Assembler macros that facilitate interaction with the CONTROL-T
Media Database. Therefore, familiarity with the Media Database format is a prerequisite
for using the API. For a detailed description of the Media Database see Media Database
Structure earlier in this section.
Base Level vs. High Level API
A calling program can interface with CONTROL-T via either the base level or high level
API (Application Programming Interface). The base level API offers versatility with few
fixed requirements. The high level API provides more automation but requires an active
CONTROL-T Real-Time environment and APF authorization. Below is a table which
details the differences between these two types of API access methods.
Note The term Real-Time environment as used in this section refers to the CONTROL-T
environment initialized by operator command: S CTTINIT,PARM=MODE=INIT
Function Base Level API High Level API
Available Functions Reads any Media
Database record.
Performs Read, Update, Add, or
Delete functions on volume
records only.
Sequential Read Supported by the
READNEXT function.
Not supported.
Authorization Required
from the Calling
Program
None. APF authorization.
Keyed / Non-keyed
Access
Both keyed and non-keyed
(RBA based) access are
supported.
Only keyed access supported.
Media Database
Allocation
The calling program must
allocate DAMDB, DAMDI
and DATRC files.
The calling program does not need
to allocate Database components.
The Real-Time environment Data
file, Index file, and Trace file are
allocated automatically for the
calling program.
Load of CONTROL-T
Control Table (TCT)
The calling program must
load a CONTROL-T
Control Table (TCT).
The calling program need not
load a CONTROL-T Control
Table (TCT). The Real-Time
environment TCT is accessed for
the calling program.
CONTROL-T Real-Time
environment
Base level API can be
used whether or not the
CONTROL-T Real-Time
environment is active.
High level API can be used only
if the CONTROL-T Real- Time
Environment is active.
Base Level API
When accessing the Media Database, the base level API can perform the following
functions:
OPEN Access of the Media Database must begin with a request to open the
database.
READ This request reads a record. This function is generally used for
reading specific records.
READNEXT Reads the record(s) following the specified record, i.e., the next
record(s). This function is generally used for reading a series of
records.
CLOSE Access of the Media Database must end with a request to close the
database.
Record Access by the Base Level API
Records in the database can be accessed by non-keyed or keyed methods:
To perform non-keyed access of database records, the full RBA must be specified.
To perform keyed access of database records, the value specified depends on the
function performed:
To perform a READNEXT operation, the entire index record must be specified.
To perform a READ operation, it is sufficient to use a partial key. Of course, the full
key or even the full index record can be used.
Both READ and READNEXT requests return the full index record to the area pointed to by
parameter KEY=.
A READ request is usually used for accessing a specific record. Since a READ request can
use a partial key as input, it is also useful when you have only partial data available (e.g.,
a volser without a label number when using the L-type index).
A READNEXT request is usually used for accessing a series of records. Since, however, a
READNEXT request requires specification of a full index value (whereas a READ request
can use a partial key as an input value), a sequence of READNEXT requests must be
preceded by a READ request.
Macro CTTIOS
CONTROL-T APIs use macro CTTIOS to access the Media Database. However, before the
base level API can use macro CTTIOS, the CONTROL-T Control Table (TCT) must be
loaded.
Instructions for loading the TCT are included in the examples for base level API later in
this section.
Format
Instructions for macro CTTIOS are formatted as follows:
Label CTTIOS request-type,
function-code,
RC=reason-code-field,
[ENV=envir-id,]
[TCT=tst-address,]
[DBGLVL=debug-level,]
[REC=buffer-address,]
[RBA=field,]
[DATA=Y/N,]
[KEY=key-field,]
[KEYTYPE=key-type,]
[KEYLEN=key-length,]
[MF={L,(E,list-address)}]
Note Macro CTTIOS may contain other parameters and fields, but only the parameters
described in this section should be used. Specification of other parameters can lead to
unpredictable results, and these additional parameters may not be supported in future
releases of CONTROL-T.
Parameters
request-type Type of request from macro CTTIOS. Mandatory. This parameter must
always be the first parameter in the macro instructions. Valid values:
VOL Volume data requests.
DS Dataset data requests.
ANY Both volume and dataset data requests.
function-code Function requested from macro CTTIOS. Mandatory. This parameter
must always be the second parameter in the macro instructions. Valid
values:
OPEN Open the Media Database (to establish access to the
Media Database).
CLOSE Close the Media Database (to terminate access to the
Media Database).
READ Read data from the Media Database.
READNEXT Read the next data item from the Media Database.
These functions are described in more detail in Base Level API Access
of the Media Database later in this section.
RC Points to a four-byte area into which macro CTTIOS places the reason
code. Mandatory for all request types and function codes.
Note The reason code should not be confused with the return code
located in register 15 (described later).
Reason codes are extremely useful when analyzing the reasons a
request failed, and should be kept for debugging and error handling
purposes. Reason code explanations can be found in the description of
message CTT200S in the IOA Messages and Codes Manual.
ENV Points to a four-byte field which identifies the environment under
which the Media Database is opened. Mandatory for Media Database
OPEN requests.
The value specified in the ENV= parameter is passed to user exits and
is recorded in the Trace file when Media Database updates are
performed.
TCT Address of the TCT returned by macro CTTTLD. Mandatory for Media
Database OPEN requests.
DBGLVL One-byte field specifying the tracing level to be used for further
executions of macro CTTIOS. Mandatory for Media Database OPEN
requests. It should contain value X'00'.
REC The buffer into which macro CTTIOS puts data retrieved from the Media
Database. Mandatory for READ requests. REC should point to an area
large enough to hold the data record retrieved from the database.
RBA Record location identifier used to determine which record should be
retrieved from the Data file.
For READ requests, the field should specify the RBA of the record to
be read (or X'000100' for the first record). For READNEXT requests,
the field should specify the RBA of the record preceding the record to
be read (i.e., the RBA returned by the previous READ/READNEXT
request).
DATA Whether or not to read the Data record of the specified
dataset/volume. Valid only when the READ or READNEXT function
code (described above) is specified. Valid values:
Y (Yes) Read the Data record of the specified dataset/volume.
N (No) Do not read the Data record.
KEY Points to a valid index record (mapped by macro CTTDVX, CTTDDX
or CTTDLX, described earlier in this section) that serves as the key (or
partial key) by which macro CTTIOS retrieves the data record from
the Media Database. Valid for READ requests. This parameter is
related to parameters KEYTYPE and KEYLEN.
For READ requests, this field should specify the key (or partial key) of
the record to be read. For READNEXT requests, this field should
specify the key of the record preceding the record to be read (i.e., the
key returned by the previous READ/READNEXT request).
KEYTYPE Type of index being used. Valid when accessing data records that may
be pointed to by more than one index type (i.e., dataset records).
Because volume records are indexed by only one key type (the V-type
index), this parameter should not be specified when performing keyed
access of volume records.
When performing keyed access dataset records, valid values are:
D When using the D-type key (mapped by DSECT CTTDDX).
Default.
L When using the L-type key (mapped by DSECT CTTDLX).
KEYLEN Points to a four-byte field which specifies the length of the key to be
searched. The record length of the Index file is identical for all index
types; therefore, this parameter is useful when using an index value
shorter than the maximum index length of the file, or when using a
partial key.
Parameter KEYLEN should be used with both full keys and partial
keys. Set all necessary fields in the key area (pointed to by parameter
KEY) and specify a KEYLEN parameter that includes only the desired
fields. When the full key is specified, set parameter KEYLEN to the
full length of the key field. This is demonstrated in the examples
provided in this section.
Macro CTTIOS reads the entire index record into the area specified by
parameter KEY. Therefore, when using this parameter, be sure to
allocate sufficient storage for the entire index record, or storage
overlays will occur.
MF Macro invocation form. Valid values:
L List form Generate all required data areas.
E Execute form Perform the request specified by the
macro parameters using the data
areas generated by the List form of
the macro. When the Execute form
of the macro is used, it must be
accompanied by a pointer to the List
form of the macro.
This same list form address must be
used for all subsequent accesses of
the Media Database via macro
CTTIOS until the Media Database
is closed.
All invocations of macro CTTIOS should access the same parameter
area. It is therefore preferable to specify the combined Execute and
List forms of the macro.
Macro CTTIOS must be coded in accordance with all standard macro Assembler coding
restrictions.
The values in general purpose registers 0, 1, 15 are modified by macro CTTIOS.
Macro CTTIOS accesses a set of variables generated by macro CTTDBTP. Therefore, macro
CTTDBTP should be included in the source code of the calling program.
Return Codes
Macro CTTIOS returns a return code in general purpose register 15. This should not be
confused with the reason code returned in parameter RC described above.
0 Successful execution of the request.
4 Requested record not found (READ requests)/End-of-File (READNEXT
requests).
Greater than 4 Unsuccessful execution of the request; the reason code indicates
additional information about why the request failed.
For more information about the return codes and reason codes of macro CTTIOS, see
message CTT200S in the IOA Messages and Codes Manual.
Base Level API Access of the Media Database
Note Sample macro code and examples are provided later in this section.
Opening/Closing Files
Access of the Media Database must begin with an OPEN request. The OPEN request
automatically opens the Data, Index and Trace files. A Media Database OPEN request
should be accompanied by parameters ENV, TCT and DBGLVL (described earlier).
Access of the Media Database must end with a CLOSE request. The CLOSE request
automatically closes all the files and performs all other required activities.
Reading Files
As mentioned earlier, Media Database READ requests can be made using either of the
following function codes: READ and READNEXT.
The differences between these requests should be understood if they are to be used
effectively. These function codes, and the various key and RBA related parameters used
with them are described below.
READ Requests
The READ request is used to read a specific data record from the Media Database. The
READ request locates the requested data record and retrieves it into the area specified by
parameter REC= .
Either a keyed or non-keyed (i.e., RBA) access method can be used to specify the record to be read.
When using keyed access to perform a READ from the Media Database, either a full or
partial key can be specified. The READ request returns the whole index record (of the data
record being read) into the area specified by parameter KEY=. Therefore, even when using
a partial key, parameter KEY= must specify an area large enough to contain the whole
index record (not just the partial key).
If the requested record is not found, either because there is no record at the specified RBA
or because no record exists with the specified full or partial key, macro CTTIOS returns a
return code of 4.
Using the READ request in conjunction with partial keys is useful for reading from the
Media Database when you have partial data only.
For example, assume you know a volser and want to find the name of the first dataset on
the volser, but you do not know the label number for this dataset (e.g., the first label may
belong to a file that is already expired). In this case, you can use partial keys as follows:
Select request type VOL, specify KEYTYPE=L and set the VOLSER field in the L-type
index to the known volser.
Instead of specifying the label number, read using a KEYLEN= parameter equal to the
length of the volser number (without the label number).
Macro CTTIOS then retrieves the first record that matches the volser number, which is the
dataset record of the first label number that exists for this volser. The area specified by the
key field will be updated with the full-key value of the retrieved record.
READNEXT Requests
The READNEXT request is used to read the next data record(s) from the Media Database.
A READNEXT request can be used with either an RBA or a full index record. READNEXT
finds and reads the record (matching the request type specified in macro CTTIOS) that
follows the specified RBA or index (i.e., the next record), and then updates the KEY= field
or RBA= field with the corresponding value of the record being read.
Because READNEXT requests require specification of an RBA value or a full index record,
and because READ requests always store the RBA value or the full index record of the
record read, a READ request should always precede a READNEXT request or set of
READNEXT requests. The READ request can be specified with either the RBA= or KEY=
parameters and partial keys can be used. The READNEXT request should then be specified
without explicitly modifying the value in the KEY or RBA fields, and without specifying
parameter KEYLEN.
Because both READ and READNEXT update the key or RBA value with each invocation, it
is possible to follow the READ request with more than one READNEXT request. Each
READNEXT request will, in its turn, read the next record and update the index record
(pointed to by the KEY parameter) or the RBA (pointed to by the RBA parameter) to the
value corresponding to the record being read.
The READNEXT function is generally used for reading a series of records in the Media
Database, such as all records matching a prefix, or all records until the end-of-file.
For example, to read all records that match a dataset name prefix, first specify a READ
with the partial key (the dataset prefix) followed by one or more READNEXT requests. The
first record matching the dataset prefix will be read (if one exists), and the READNEXT
requests will read all subsequent records (datasets) following the first match. If no
matching record exists, CTTIOS positions the program for subsequent READNEXT
requests according to ordinary key sorting rules.
Note A READNEXT operation does not automatically stop after all records matching the
prefix (or any other partial key) are read. The READNEXT request stops reading, and
returns a return code of 4, only when the end-of-file is reached. Therefore, your
application program must check when the READNEXT request results in a record that
does not match the partial key, and it must then stop issuing READNEXT requests.
Sequential Reading of the Entire Media Database Keyed vs. Non-Keyed Access
The entire Media Database can be read either by using indexes (e.g., reading all volsers by using
the V-type index) or by using RBAs to read through the entire Media Database. Every program
that requires sequential access to the entire Media Database must select the appropriate access
method. When selecting the access method, the following points should be considered:
When reading the Media Database using RBAs, one I/O operation is performed for each
block (one block contains a number of records). Thus, the number of I/O operations
required for reading the entire Media Database is relatively small. When reading the
Media Database sequentially via indexes, each record access results in one access to the
index, and one access to the data. This may result in a high I/O count and
unsatisfactory performance for the program.
When reading the Media Database via indexes, records are read in ascending sort
order. When reading the Media Database using RBAs, records are read in the order
they appear in the data file (not necessarily sorted).
It is much faster to read the Media Database using RBAs instead of indexes. If data items
from the Media Database do not have to be sorted, it is highly recommended to use
RBA-based reading of the Media Database.
Even if the data items retrieved from the Media Database should be sorted, it might be
more efficient (depending on the environment) to read the Media Database using RBAs,
and sort it after you have read it. You can also use sort utilities to merge volume and
dataset records retrieved from the Media Database, instead of performing keyed accesses
for every volume (or for every dataset).
Examples for Base Level API
Below are several examples of how to perform the various functions described in this section.
These examples should not be used without appropriate modification. Most of the examples
provided do not check the return code from macro CTTIOS. Some examples refer to
Assembler symbols that are not included in the example.
Loading the TCT into Storage
The TCT (CONTROL-T Control Table) is not a load module and therefore cannot be loaded
using the LOAD macro. To load the TCT, use macro CTTTLD. Below is a sample program
which uses macro CTTTLD to load the TCT.
Sample TCT Load Request
CALL CTTTLD,(LOAD,TCTADDR,0,0) LOAD THE TCT
LTR R15,R15 SUCCESSFUL?
BNZ TCTFAIL NO - TERMINATE
.
.
TCTFAIL WTO TCT LOAD FAILED, PROGRAM TERMINATED
ABEND 8,DUMP ABEND PROGRAM WITH U0008
.
.
LOAD DC CL8LOAD CONSTANT FOR CTTTLD
TCTADDR DS A ADDRESS OF TCT
Sample Media Database OPEN Request
CALL CTTTLD,(LOAD,TCTADDR,0,0) Load the TCT
.
.
L R12,TCTADDR
OPENMDB CTTIOS ANY,OPEN,ENV=$ENV,DBGLVL=$DBG,TCT=(R12), Open the MDB *
RC=RESCODE,MF=(E,IOSLIST)
.
.
IOSLIST CTTIOS MF=L
$ENV DC CL4USER Environment specification
$DBG DC X00 Debug level
TCTADDR DS A Address of TCT
RESCODE DS F
LOAD DC CL8LOAD Constant for CTTTLD
Note The return code from macro CTTTLD should also be checked.
Sample CLOSE Request
CLOSEMDB CTTIOS ANY,CLOSE,MF=(E,IOSLIST)
.
.
IOSLIST CTTIOS MF=L
Keyed Reading From the Media Database
CONTROL-T base level API provides keyed access to data residing in the Media Database.
Keyed access is achieved using the indexes, as explained above.
Following are samples for keyed access requests from the Media Database:
Sample Read by Volser Request
L R2,=A(VOLKEY) Volume key field
USING DVX,R2
XC VOLKEY,VOLKEY
MVC DVXVOLSR,=C123456 Prepare vol. key
LA R15,=A(LDVXVOLSR) Length of volser
READVOL CTTIOS VOL,READ,KEY=VOLKEY,RC=RESCODE,REC=VOLREC, Read from MDB *
KEYLEN=(R15),MF=(E,IOSLIST)
LTR R15,R15 Was read OK?
BNZ NOTFOUND No - treat accordingly
.
.
VOLKEY DS XL(DVXLEN) Vol. index key
VOLREC DS XL(DVLLEN) Vol. record buffer
RESCODE DS F CTTIOS reason code
IOSLIST CTTIOS MF=L CTTIOS list form
.
.
* CONTROL-T MAPPING MACROS
CTTDVL Vol. data record
CTTDVX Vol. index record
CTTDBTP CTTIOS parameters block
Sample Read by Dataset Name Request
Since D-type indexes are non-unique (i.e., more than one dataset can have the same name),
the sample shown below will read only the record of the first dataset in the Media
Database with the specified name.
LA R2,DSNKEY D.S. key field
USING DDX,R2
XC DSNKEY,DSNKEY
MVC DDXDSN,=CL44CTT.SAMPLE.FILE Prepare D.S. key
LA R15,=A(LDDXDSN)
CTTIOS DS,READ,KEY=DSNKEY,REC=DSNREC, Read from MDB *
KEYLEN=(R15),ENQ=Y,MF=(E,IOSLIST)
.
.
DSNKEY DS XL(DDXLEN) D.S. index key
DSNREC DS XL(DDSLEN) D.S. record buffer
.
.
CTTDDS D.S. data record
CTTDDX D.S. index record
Note In the above example, parameter KEYTYPE is omitted. It defaults to KEYTYPE=D.
Sample Read by Volser and File Sequence Number Request
LA R2,DLSKEY D.S. key field
USING DLX,R2
XC DLSKEY,DLSKEY
MVC DLXVOLSR,=C123456 Copy volser
LA R3,1 First D.S. on volser
STCM R3,B0011,DLXLBLNM Store label number
LA R15,=A(LDLXVOLSR+LDLXLBLNM)
CTTIOS DS,READ,KEY=DLSKEY,KEYLEN=(R15),KEYTYPE=L, Read from MDB *
REC=DSNREC,MF=(E,IOSLIST)
.
.
DLSKEY DS XL(DLXLEN) D.S. L-type key
.
.
CTTDDS D.S.data record
CTTDLX D.S.L-type index
Sample Read All Datasets With Specified Prefix Using READNEXT Request
LA R2,DSNKEY D.S. key field
USING DDX,R2
L R3,=A(DSNREC) Record addressability
USING DDS,R3
XC DSNKEY,DSNKEY Clear index
MVC DDXDSN(LDSPRFX),DSPRFX Datasets prefix
LA R15,=A(LDSPRFX) Length of prefix
CTTIOS DS,READ,KEY=DSNKEY,REC=DSNREC, Read from MDB *
KEYLEN=(R15),MF=(E,IOSLIST)
.
.
READNEXT CTTIOS DS,READNEXT,KEY=DSNKEY, Read next dataset from MDB *
REC=DSNREC,MF=(E,IOSLIST)
LTR R15,R15 Successful ?
BNZ NOMORE No - skip further READNEXTs
CLC DDSDSN(LDSPRFX),DSPRFX Is it still the same prefix
BE READNEXT Yes - loop again
NOMORE EQU *
.
.
DSPRFX DC CL15DATASET.PREFIX. Datasets prefix
DSNKEY DS XL(DDXLEN) D.S. index key
.
.
CTTDDX D.S.index record
Non-Keyed (RBA-Based) Reading of the Media Database
CONTROL-T Base Level API also provides non-keyed access to data residing in the Media
Database. Non-keyed access is achieved by using the RBA as the pointer to the desired
record in the data file, as explained above.
Following are a few sample RBA-based access requests from the Media Database:
Sample Read a Record Request
MVC RECRBA,=X000203 Set the RBA to block 2, record 3
CTTIOS ANY,READ,RC=RESCODE,REC=AREA,RBA=RECRBA, Read from MDB *
MF=(E,IOSLIST)
LTR R15,R15 Does record exists ?
L R3,=A(AREA) R3 points to the record read
USING DVL,R3
CLI DVLRTYPE,DVLRVL Is it a volume record ?
BE TREATVOL Yes - treat accordingly
CLI DVLRTYPE,DDSRDS Is it a dataset record ?
BE TREATDS Yes - treat accordingly
B TREATOTH Treat other record types
.
.
AREA DS CL(DVLLEN) Record buffer (both vol and D.S.)
RECRBA DS XL3 RBA of record
.
.
CTTDVL Vol. data record
In the above example:
You do not have to check whether or not the record being read is free or active, since
macro CTTIOS does that for you. If the record is free (i.e., not active), the macro
returns a return code of 4 (not found).
Since the header of all record types is the same, it is possible to compare the record
type FIELD from the volume DSECT against the record type EQUATE from the dataset
DSECT.
Sample Read Next Record Request
MVC RECRBA,DVLRBA Set RBA of current record
CTTIOS ANY,READNEXT,REC=AREA, Read the next record from MDB *
RBA=RECRBA,RC=RESCODE,MF=(E,IOSLIST)
LTR R15,R15
.
.
In the above example:
The rest of the sample program can be the same as the prior example.
When using the READNEXT function code, macro CTTIOS skips free records and looks
for active records to read. A return code of 4 (not found) signals that the end-of-file was
reached.
Sample Media Database Access Program
This sample access program sequentially reads all the Media Database using RBAs and
produces the following reports:
All volumes with all the datasets for each volume.
All datasets with all the volumes for each dataset.
This program provides a working example for a wide variety of requests available through
macro CTTIOS.
**********************************************************************
* *
* CTTSAM1 *
* *
* *
* FUNCTION: SAMPLE PROGRAM TO DEMONSTRATE ACCESS TO THE CONTROL-T *
* MEDIA DATABASE (MDB) USING THE BASE LEVEL API. *
* THE PROGRAM READS THE MDB AND PRODUCES TWO REPORTS: *
* 1. A VOLUME REPORT CONTAINING ALL VOLUMES IN THE MDB *
* AND ALL DATASETS EXISTING ON EACH VOLUME *
* 2. A DATASET REPORT CONTAINING ALL DATASETS IN THE MDB *
* AND ALL VOLUMES THAT ARE PART OF EACH DATASET *
* *
* RETURN CODES: 00 - OK *
* 04 - MDB EMPTY *
* 08 - ERROR DURING PROCESSING *
* *
* LOGIC: THE PROGRAM READS THE MDB SEQUENTIALLY USING RBAS. VOLUME *
* AND DATASET RECORDS ARE PROCESSED, AND OTHER RECORDS ARE *
* DISREGARDED. *
* FOR VOLUME RECORDS, THE DATASETS OF THE VOLUME ARE READ, *
* USING THE L-TYPE INDEX. A READ REQUEST WITH NO LABEL *
* NUMBER (VOLSER ONLY) IS PERFORMED FIRST. THE READNEXT *
* REQUEST IS THEN USED REPEATEDLY UNTIL ALL DATASETS ON THE *
* VOLUME ARE PROCESSED. *
* FOR DATASET RECORDS, THE VOLUMES OF THE DATASET ARE READ *
* THE FIRST VOLSER IS TAKEN FROM THE DATASET RECORD, AND *
* AFTERWARDS, THE VOLUME RECORDS ARE READ, AND THE *
* NEXT VOLUME RETRIEVED FROM THEM, UNTIL ALL VOLUMES OF THE *
* DATASET HAVE BEEN READ. *
* *
* DD CARDS: DAMDB - MDB DATA FILE *
* DAMDI - MDB INDEX FILE *
* DATRC - TRACE FILE *
* DARPTVOL - VOLUME REPORT FILE *
* DARPTDSN - DATASET NAMES REPORT FILE *
* *
* DISCLAIMER: THIS SAMPLE PROGRAM IS PROVIDED ON AN AS IS BASIS,*
* WITHOUT ANY WARRANTY, EITHER EXPRESS OR IMPLIED *
* *
* REGISTERS: R13 - BASE *
* R2 - MDB RECORD KEY (WHERE APPLICABLE) *
* R3 - MDB RECORD BUFFER *
* *
* ATTRIBUTES: AMODE 31 *
* RMODE 24 *
* *
* TO COMPILE AND LINK THE PROGRAM : *
* *
* //CTTSAM1 JOB ... *
* //ASM EXEC CTTASM *
* //C.SYSIN DD DSN=CTT.V514.SAMPLE(CTTSAM1) *
* //L.SYSLMOD DD DISP=SHR,DSN=YOUR.LOAD.LIBRARY *
* //L.SYSIN DD * *
* INCLUDE SYSLIB(CTTTLD) *
* MODE RMODE(24),AMODE(31) *
* NAME CTTSAM1(R) *
* //* *
* //RUN EXEC PGM=CTTSAM1,COND=(0,NE),REGION=60M *
* //STEPLIB DD DISP=SHR,DSN=YOUR.LOAD.LIBRARY *
* //DAMDB DD DISP=SHR,DSN=CTT.V514.MDBD *
* //DAMDI DD DISP=SHR,DSN=CTT.V514.MDBI *
* //DATRC DD DISP=SHR,DSN=CTT.V514.TRC *
* //DARPTVOL DD SYSOUT=* *
* //DARPTDSN DD SYSOUT=* *
* // *
* *
**********************************************************************
EJECT
CTTDDS D.S. DATA RECORD
CTTDVL VOL. DATA RECORD
CTTDVX VOL. INDEX RECORD
CTTDDX D.S. INDEX RECORD
CTTDLX D.S. L-TYPE INDEX
CTTDBTP CTTIOS PARAMETERS BLOCK
EJECT
MACRO
&NAME MYPUT &DCB,&REC
&NAME LA R15,*+6 ADDRESS FOLLOWING BASSM
BASSM R14,R15 CHANGE AMODE
PUT &DCB,&REC PUT THE DESIRED RECORD
LA R15,*+10 ENDING ADDRESS
O R15,=X80000000
BSM 0,R15
MEND
**********************************************************************
EJECT
CTTSAM1 CSECT
BEGIN *,EQUR=YES
CTTLEVEL
SPACE 3
***
* INITIALIZE PROGRAM - LOAD THE TCT AND OPEN FILES
***
CALL CTTTLD,(LOAD,TCTADDR,0,0) LOAD THE TCT
LTR R15,R15 SUCCESSFUL ?
BNZ LTCTFAIL NO - TERMINATE
SPACE 3
OPEN (RPTVOL,OUTPUT) OPEN VOLUME REPORT OUTPUT FILE
BNZ OUTERROR NO - TERMINATE
OPEN (RPTDSN,OUTPUT) OPEN DATASET REPORT OUTPUT FILE
BNZ OUTERROR NO - TERMINATE
MYPUT RPTVOL,VOLMSG PRINT VOLUME REPORT HEADER
MYPUT RPTDSN,DSNMSG PRINT DATASET REPORT HEADER
SPACE 3
L R12,TCTADDR
MVC MSGOP,=CL8OPEN
CTTIOS ANY,OPEN,ENV=$ENV,DBGLVL=$DBG, OPEN MDB *
TCT=(R12),RC=RESCODE,MF=(E,IOSLIST)
BNZ MDBERROR NO - TERMINATE
SPACE 3
***
* SEQUENTIAL READING OF THE MDB, BY RBA
***
MVC RECRBA,RBA0 START WITH THE FIRST RECORD
MVC MSGOP,=CL8READ
CTTIOS ANY,READ,RC=RESCODE,REC=AREA,RBA=RECRBA, *
MF=(E,IOSLIST) READ THE FIRST RECORD
BZ READOK YES - PROCESS THE NEXT RECORD
CH R15,=H4 WAS IT BECAUSE FIRST RECORD IS FREE?
BH MDBERROR NO - TERMINATE *
OTHERWISE TRY TO READ THE NEXT ONE
MVC MSGOP,=CL8READNEXT
CTTIOS ANY,READNEXT,RC=RESCODE,REC=AREA, READ NEXT RECORD *
RBA=RECRBA,MF=(E,IOSLIST)
LTR R15,R15 WAS READNEXT SUCCESSFUL ?
BZ READOK YES - PROCESS THE RECORD
CH R15,=H4 E.O.F ?
BE MDBEMPTY YES - MDB IS EMPTY
B MDBERROR OTHERWISE - TERMINATE
SPACE 3
***
* LOOP ON ALL RECORDS
***
READOK EQU *
L R3,=A(AREA) ESTABLISH ADDRESSABILITY
USING DVL,R3 TO THE RECORD BUFFER
CLI DVLRTYPE,DVLRVL IS THIS A VOLUME RECORD ?
BE TREATVOL YES - TREAT ACCORDINGLY
CLI DVLRTYPE,DDSRDS IS THIS A DATASET RECORD ?
BE TREATDS YES - TREAT ACCORDINGLY
READNEXT EQU *
CTTIOS ANY,READNEXT,RC=RESCODE,REC=AREA, READ NEXT RECORD *
RBA=RECRBA,MF=(E,IOSLIST)
LTR R15,R15 WAS READ SUCCESSFUL ?
BZ READOK YES - PROCCESS THIS RECORD
CH R15,=H4 E.O.F ?
BE EODAD YES - ISSUE MESSAGE
B MDBERROR OTHERWISE TERMINATE
DROP R3
SPACE 3
***
* TREAT ONE VOLUME RECORD - PRINT ALL ITS DATASETS
***
TREATVOL EQU *
USING DVL,R3 ESTABLISH ADDRESSABILITY
MVC VOLUME,DVLVOLSR MOVE VOLSER TO OUTPUT RECORD
MYPUT RPTVOL,OUTVOL
TM DVLSTAT,DVLSSCR IS IT SCRATCH ?
BNO GETDSNS NO - GET DATASETS ON THE VOLUME
MVC DSNAME,SCRIND ELSE - ISSUE SCRATCH MESSAGE
MYPUT RPTVOL,OUTDSN PRINT THE SCRATCH MESSAGE
B ENDVOL END VOLUME PROCESSING
GETDSNS EQU *
LA R2,DLSKEY ESTABLISH ADDRESSABILITY
USING DLX,R2 TO D.S. L-TYPE INDEX
XC DLSKEY,DLSKEY CLEAR INDEX FIELD
MVC DLXVOLSR,DVLVOLSR MOVE VOLSER TO KEY FIELD
DROP R3 VOLUME RECORD NOT NEEDED ANY MORE
LA R15,=A(LDLXVOLSR)
MVC MSGOP,=CL8READ
CTTIOS DS,READ,KEY=DLSKEY, READ FROM MDB *
RC=RESCODE, *RC *
KEYTYPE=L,KEYLEN=(R15),REC=AREA,MF=(E,IOSLIST)
CH R15,=H4 *NFD
BE ENDVOL *NFD1
BH MDBERROR *NFD
PRINTDSN EQU *
USING DDS,R3 ADDRESSABILITY (R3->>RECORD BUFFER)
MVC DSNAME,DDSDSN MOVE DSNAME TO OUTPUT RECORD
MYPUT RPTVOL,OUTDSN PRINT IT
CTTIOS DS,READNEXT,KEY=DLSKEY, READ NEXT RECORD FROM MDB *
RC=RESCODE, *RC *
KEYTYPE=L,REC=AREA,MF=(E,IOSLIST)
BZ PROCDSN YES - PROCESS DSN
CH R15,=H4 NO - WAS IT BECAUSE THE END OF MDB ?
BH MDBERROR NO - ISSUE AN ERROR MESSAGE
B ENDVOL YES - PROCESS NEXT VOLUME
PROCDSN EQU *
CLC DLXVOLSR,VOLUME ARE WE STILL IN THE SAME VOLUME ?
BE PRINTDSN YES - PRINT IT AND PROCESS NEXT DS
ENDVOL EQU *
B READNEXT GO TO GET NEXT RECORD
SPACE 3
***
* TREAT ONE DATASET RECORD - PRINT ALL ITS VOLUMES
***
TREATDS EQU *
USING DDS,R3 ESTABLISH ADDRESSABILITY
MVC DSNAME,DDSDSN MOVE DSNAME TO OUTPUT RECORD
MYPUT RPTDSN,OUTDSN PRINT IT
MVC VOLUME,DDSVOLSR MOVE FIRST VOLSER TO MESSAGE
MYPUT RPTDSN,OUTVOL PRINT MESSAGE
LH R4,DDSVOLS# NUMBER OF VOLUMES IN DATASET
CH R4,=H1 IS THERE ONLY ONE VOL IN DATASET ?
BNH ENDDSN YES - END PROCESSING OF DATASET
DROP R3 ADDRESSABILITY NOT NEEDED ANY MORE
SPACE 3
***
* FIND ALL VOLUMES OF DATASET
***
LA R2,DVXKEY ESTABLISH ADDRESSABILITY
USING DVX,R2 TO VOLUME INDEX FIELD
USING DVL,R3 AND TO VOLUME RECORD
XC DVXKEY,DVXKEY CLEAR VOLUME KEY FIELD
BCTR R4,0 DECREMENT VOL COUNT (1 PRINTED)
NEXTVOL EQU *
MVC DVXVOLSR,VOLUME
LA R15,=A(LDVXVOLSR)
MVC MSGOP,=CL8READ
CTTIOS VOL,READ,KEY=DVXKEY, READ FROM MDB *
RC=RESCODE, *
REC=AREA,KEYLEN=(R15),MF=(E,IOSLIST)
CH R15,=H4
BE ENDDSN
BH MDBERROR
MVC VOLUME,DVLNEXT NEXT VOLUME (PREV ALREADY PRINTED)
MYPUT RPTDSN,OUTVOL PRINT THE VOLUME SERIAL
BCT R4,NEXTVOL AND GO GET NEXT VOLUME (IF ANY)
ENDDSN EQU * END OF DATASET PROCESSING
B READNEXT GO TO GET NEXT RECORD
DROP R3
SPACE 3
*
MDBERROR EQU *
LR R5,R15
CVD R5,DOUBLE
UNPK MSGRC(2),DOUBLE+6(2)
OI MSGRC+1,XF0
*
L R5,RESCODE
CVD R5,DOUBLE
UNPK MSGRSN(5),DOUBLE+5(3)
OI MSGRSN+4,XF0
*
IOAEDIT CTT200S _ FAILED FOR DAMDB DATASET.,(MSGOP,8), *
INTO=MDBERR1+8,REGSAVE=YES,MF=(E,WORKEDIT)
MDBERR1 WTO CTT200S OPER FAILED FOR DAMDB DATASET.
*
IOAEDIT RC=_, REASON=_,(MSGRC,2,MSGRSN,5), , *
INTO=MDBERR2+8,REGSAVE=YES,MF=(E,WORKEDIT)
MDBERR2 WTO RC=XX, REASON=YYYYY
*
B RET8
OUTERROR WTO UNABLE TO OPEN OUTPUT FILE
B RET8
LTCTFAIL WTO TCT LOAD FAILED
B RET8
MDBEMPTY WTO MDB IS EMPTY
B RET4
EODAD EQU *
MYPUT RPTVOL,EOFMSG
MYPUT RPTDSN,EOFMSG
CLOSE (RPTVOL,,RPTDSN) CLOSE OUTPUT FILES
CTTIOS ANY,CLOSE, *
RC=RESCODE, *
MF=(E,IOSLIST)
CALL CTTTLD,(DELETE,TCTADDR,0,0) FREE TCT AREA
B RET0
RET8 LA R15,8
B ENDPGM
RET4 LA R15,4
B ENDPGM
RET0 SLR R15,R15
B ENDPGM
ENDPGM EQU *
SPACE 3
BRTRN (15)
EJECT
***
* CONSTANTS
***
RBA0 DC XL3000100 RBA OF FIRST RECORD IN DATABASE
$ENV DC CL4SAM1
$DBG DC X00
LOAD DC CL8LOAD
DELETE DC CL8DELETE
PATTERN DC X402120202020
SPACE 3
***
* DATA AREAS
***
AREA DS CL(DVLLEN) RECORD BUFFER (BOTH VOL AND D.S.)
RECRBA DS XL3 RBA OF RECORD
RESCODE DS F REASON CODE OF PROGRAM
DLSKEY DS XL(DLXLEN) D.S. L-TYPE INDEX KEY
DVXKEY DS XL(DVXLEN) VOL. INDEX RECORD
TCTADDR DS A ADDRESS OF THE TCT
DOUBLE DS D
MSGRC DS CL6 RC FROM CTTIOS FOR CTT200S
MSGRSN DS CL6 REASON CODE FOR CTT200S
MSGOP DS CL8 OPERATION FOR CTT200S
DS 0F
WORKEDIT DS CL256 OPERATION FOR CTT200S
SPACE 3
***
* OUTPUT MESSAGES
***
OUTDSN DS CL80 DATASET OUTPUT RECORD
ORG OUTDSN
DC CL6 DSN= RECORD PREFIX
DSNAME DS CL(LDDSDSN) DATASET NAME
DC CL(80+OUTDSN-*) FILLER
ORG
OUTVOL DS CL80 VOLUME OUTPUT RECORD
ORG OUTVOL
DC CL6 VOL= RECORD PREFIX
VOLUME DS CL(LDVLVOLSR) VOLUME SERIAL
DC CL(80+OUTVOL-*) FILLER
ORG
VOLMSG DC CL80 *** VOLUME REPORT ***
DSNMSG DC CL80 *** DATASET REPORT ***
EOFMSG DC CL80 *** END OF MDB WAS REACHED ***
SCRIND DC CL44 *** THIS IS A SCRATCH VOLUME ***
SPACE 3
***
* CTTIOS IN LIST FORM
***
IOSLIST CTTIOS MF=L
SPACE 3
***
* DATA CONTROL BLOCKS
***
RPTVOL DCB DDNAME=DARPTVOL,MACRF=PM,LRECL=81,RECFM=FBA, *
DSORG=PS
RPTDSN DCB DDNAME=DARPTDSN,MACRF=PM,LRECL=81,RECFM=FBA, *
DSORG=PS
END
High Level API
Calling programs that access the CONTROL-T Media Database via basic level API must
load a CONTROL-T Control Table and allocate the Media Database components. High level
API performs these actions automatically.
High level API uses the Real-Time environment TCT and the Real-Time environments Media
Database components.
As a result:
High Level API cannot be used when the CONTROL-T Real-Time environment is not
active.
Calling programs intended for use with high level API have to be APF-authorized.
CONTROL-T high level API is implemented by two Assembler macros:
CTTACCDB Accesses the Media Database.
CTTCHKDB Checks the last access of the Media Database (via macro CTTACCDB).
The following functions can be performed by high level API via macro CTTACCDB:
START Initializes the high level API. Access of the Media Database must
begin with this function.
READVOL Reads a requested volume record from the Media Database.
ADDVOL Adds a volume record to the Media Database.
DELVOL Deletes a volume record from the Media Database.
UPDTVOL Updates a volume record in the Media Database.
END Terminates high level API functions. Access of the Media Database
must end with this function.
After each run of macro CTTACCDB, it is highly recommended that you check the
completion code of the access to the Media Database via macro CTTCHKDB. This macro
tests the return code from the API and transfers control to an error handling routine which
is written by the user as part of the calling program.
Macro CTTACCDB
High level API access to the Media Database is performed via macro CTTACCDB.
Format
Instructions for macro CTTACCDB are formatted as follows:
label CTTACCDB function-code,
R EC=buffer-address,
VOL=volser,
PARMS=parm-work-area
Parameters
function-code Function requested from macro CTTACCDB. Mandatory. This
parameter must always be the first parameter. Valid values:
START Perform initialization functions required to enable
access to the Media Database of CONTROL-T (e.g., gain
access to the Real-Time environment TCT, and open the
Real-Time environment Media Database).
END Perform cleanup functions after using high level API
(e.g., close the Media Database).
READVOL Read a volume record from the Media Database.
A buffer-address, a volser, and a parm-work-area must
be specified with this function code.
ADDVOL Add a volume record to the Media Database.
A buffer-address and a parm-work-area must be
specified with this function code.
DELVOL Delete a volume record from the Media Database.
A volser and a parm-work-area must be specified with
this function code.
UPDTVOL Update a volume record in the Media Database.
A buffer-address and a parm-work-area must be
specified with this function code.
buffer-address Buffer used by macro CTTACCDB for either storing data retrieved from
the Media Database, or storing data to be inserted in the Media
Database. This variable should point to an area defined as follows:
REC DS (DVLLEN)X
This parameter is mandatory when function-code READVOL,
ADDVOL or UPDTVOL is specified.
volser Volume serial number. This variable should point to an area six
characters in length. This variable is mandatory when function-code
READVOL or DELVOL is specified.
parm-work-area Macro invocation work area. Mandatory. This variable should point to
an area defined as follows:
ADBPARMS DS (ADBPLEN)X
All invocations of CTTACCDB must access the same parameter area. Therefore, you must
use the same parm-work-area in all calls to macro CTTACCDB.
Macro CTTACCDB must be coded in accordance with all standard macro Assembler coding
restrictions.
Values in general purpose registers 0, 1, 14, and 15 are modified by macro CTTACCDB.
Macro CTTACCDB accesses a set of variables generated by macro CTTADBP and by macro
CTTDBTP. Therefore, the source of the calling program should include both these macros.
Macro CTTCHKDB
This macro is used to check return codes resulting from access of the Media Database via
macro CTTACCDB.
Format
Instructions for macro CTTCHKDB are formatted as follows:
label CTTCHKDB ERR=error-routine,
PARMS=work-area
where:
error-routine Points to a subroutine in the source code of the calling program that
handles Media Database access errors. For more information, see
Media Database Error Handling Routine below. Mandatory.
work-area Invocation work area of the last CTTACCDB macro. Mandatory.
The value for this field must be the same work area specified in the
parameters for CTTACCDB.
Macro CTTCHKDB must be coded in accordance with all standard macro Assembler coding
restrictions.
Values in general purpose registers 0, 1 and 15 are modified by macro CTTCHKDB.
Media Database Error Handling Routine
The calling program must supply an error handling routine. This error handling routine is
given control whenever macro CTTCHKDB determines that the last access to the Media
Database was unsuccessful (e.g., the requested volume was not found).
High level API invokes macro CTTIOS to access the Media Database. For more
information, see the description of macro CTTIOS earlier in this section.
High level API accesses a set of variables generated by macro CTTADBP. Some of these
variables contain information relevant to the Media Database error handling routine. The
variables are located in the area specified via parameter PARMS to macro CTTACCDB,
and are mapped by macro CTTADBP. Below is a list of these variables:
ADBPRC Return code from the last high level API function. Full word. Possible
values:
0 OK
8 Invalid function requested
12 CONTROL-T TCT not found (i.e., CONTROL-T not
active)
16 A CTTIOS command failed (see parameters ADBPIRC
and ADBPIRSN described below)
20 Internal error (CTTIOS handle not supplied)
24 Media Database record not supplied
28 Calling program is not APF-authorized
32 Key (volser) not supplied
36 Function code not allowed (denied by exit CTTX006)
ADBPFUNC Last CTTACCDB function. The field for this variable is eight
characters long.
ADBPIRC Return code from the last run of macro CTTIOS which was invoked by
the high level API. Full word. (For more details on the return codes of
macro CTTIOS, see message CTT200S in the IOA Messages and Codes
Manual.)
ADBPIRSN Reason code returned from the last run of macro CTTIOS invoked by
the high level API. Full word. (For more information about the reason
codes of macro CTTIOS, see the message CTT200S in the IOA
Messages and Codes Manual.)
ADBPIOPR Last CTTIOS function issued by the high level interface. This variable
is contained in an 8-character field.
Example for High Level API
This sample access program reads the volume record of volume V00001 from the Media
Database using high level API, and issues a message about the status of this volume (i.e.,
SCRATCH, ACTIVE, or NOT FOUND IN MDB). This sample also includes an example for
the Media Database error handling routine.
Note The code shown below is just an example and should not be used without appropriate
modification.
**********************************************************************
* *
* CTTSAM2 *
* *
* *
* FUNCTION: SAMPLE PROGRAM TO DEMONSTRATE ACCESS TO THE CONTROL-T *
* MEDIA DATABASE (MDB) USING THE HIGH LEVEL API. *
* THIS PROGRAM READS THE MDB VOLUME RECORD OF A CERTAIN *
* VOLUME, (IN THIS SAMPLE: V00001) AND ISSUES A MESSAGE *
* ABOUT THE VOLUMES STATUS: ACTIVE OR SCRATCH. *
* IN THIS CODE YOU WILL ALSO FIND AN EXAMPLE FOR AN *
* MDB ERROR HANDLING ROUTINE THAT SHOULD BE CALLED BY *
* ANY PROGRAM THAT USES THE HIGH LEVEL API. *
* *
* DD CARDS: NONE (THE HIGH LEVEL API USES THE CONTROL-T REAL *
* TIME ENVIRONMENT FILES). *
* *
* DISCLAIMER: THIS SAMPLE PROGRAM IS PROVIDED ON AN AS IS BASIS, *
* WITHOUT ANY WARRANTY, EITHER EXPRESS OR IMPLIED *
* *
* REGISTERS: R13 - BASE *
* R4 - MDB VOLUME RECORD (MAPPED BY CTTDVL) *
* R9 - CTTACCDB PARMS (MAPPED BY CTTADBP) *
* *
* RMODE 24 *
* *
* TO COMPILE AND LINK THE PROGRAM : *
* *
* //CTTSAM2 JOB ... *
* //C.SYSIN DD DSN=IOA.V514.SAMPLE(CTTSAM2) *
* //L.SYSLMOD DD DISP=SHR,DSN=YOUR.LOAD.LIBRARY *
* //L.SYSIN DD * *
* MODE RMODE(24),AMODE(31) *
* NAME CTTSAM2(R) *
* //* *
* //RUN EXEC PGM=CTTSAM2,COND=(0,NE),REGION=60M *
* //DAMDB DD DISP=SHR,DSN=CTT.V514.MDBD *
* //DAMDI DD DISP=SHR,DSN=CTT.V514.MDBI *
* //DATRC DD DISP=SHR,DSN=CTT.V514.TRC *
* //DARPTVOL DD SYSOUT=* *
* //DARPTDSN DD SYSOUT=* *
* // *
* *
**********************************************************************
EJECT ,
CTTSAM2 CSECT HIGH LEVEL API SAMPLE
BEGIN *,EQUR=YES
SPACE 1
LA R9,ADBPARMS R9->> CTTADB PARMS
USING ADBP,R9
XC FLAG,FLAG INIT INTERNAL FLAG
SPACE 1
*********************************************************************
* PERFORM INITIALIZATION REQUIRED VIA HIGH LEVEL API: START COMMAND *
*********************************************************************
SPACE 1
CTTACCDB START,PARMS=ADBPARMS INITIALIZATION
CTTCHKDB ERR=ADBERROR,PARMS=ADBPARMS CHECK START OPERATION
SPACE 1
OI FLAG,$OPENED MARK: MDB IS OPENED
SPACE 1
*********************************************************************
* READ MDB VOLUME RECORD OF VOLUME: V00001 VIA READVOL COMMAND *
*********************************************************************
SPACE 1
MVC VOL(6),=CL6V00001 VOLSER TO READ
SPACE 1
CTTACCDB READVOL,REC=VOLREC,VOL=VOL,PARMS=ADBPARMS
CTTCHKDB ERR=RVOLERR,PARMS=ADBPARMS
SPACE 1
NI FLAG,XFF-$OPENED MARK: MDB IS NOT OPENED
SPACE 1
*********************************************************************
* PERFORM CLEANUP REQUIRED VIA HIGH LEVEL API: END COMMAND *
*********************************************************************
SPACE 1
CTTACCDB END,PARMS=ADBPARMS
CTTCHKDB ERR=ADBERROR,PARMS=ADBPARMS
SPACE 1
*********************************************************************
* ISSUE A MESSAGE ACCORDING TO VOLUMES STATUS: ACTIVE OR SCRATCH *
*********************************************************************
SPACE 1
LA R4,VOLREC R4->>MDB VOL RECORD
USING DVL,R4
TM DVLSTAT,DVLSACT AN ACTIVE VOLUME ?
BNO WTOSCR ..N, GO ISSUE: SCRATCH
SPACE 1
WTO VOLUME V00001 IS ACTIVE VOLUME IS ACTIVE
B EXIT
SPACE 1
WTOSCR DS 0H VOLUME IS SCRATCH
WTO VOLUME V00001 IS SCRATCH
SPACE 1
B EXIT
DROP R4 WAS MDB VOL RECORD
SPACE 1
*********************************************************************
* MDB ERROR HANDLING ROUTINE - FOR READVOL FUNCTION *
*********************************************************************
SPACE 1
RVOLERR DS 0H READVOL ERROR
L R15,ADBPRC R15 - CTTADB RC
C R15,=F16 A CTTIOS FAILURE ?
BNE ADBERROR ..N, GO ISSUE ERROR MSG
SPACE 1
L R15,ADBPIRC R15 - RC OF CTTIOS
C R15,=F4 VOLUME NOT FOUND ?
BNE ADBERROR ..N, GO ISSUE ERROR MSG
SPACE 1
WTO VOLUME V00001 NOT FOUND IN MEDIA DATABASE
SPACE 1
NI FLAG,XFF-$OPENED
CTTACCDB END,PARMS=ADBPARMS TRY TO PERFORM CLEANUP
CTTCHKDB ERR=ADBERROR,PARMS=ADBPARMS
SPACE 1
B EXIT NO OTHER UPDATES
SPACE 1
*********************************************************************
* MDB ERROR HANDLING ROUTINE - FOR START/END FUNCTIONS *
*********************************************************************
ADBERROR DS 0H
MVC MSG1FUNC(8),ADBPFUNC CTTACCDB FUNCTION FOR MESSAGE
MVC MSG1VOL(6),=CL6V00001 VOLSER FOR MESSAGE
L R3,ADBPRC CONVERT
CVD R3,DW ..CTTACCDB
UNPK MSG1RC(3),DW+6(2) ..RETURN-CODE
OI MSG1RC+2,XF0 ..FOR MESSAGE
SPACE 1
MVC WTO1+10(MSG1LEN),MSG1 MOVE MESSAGE TO BE WTOED
WTO1 WTO +
,ROUTCDE=11
MVC MSG2FUNC(8),ADBPIOPR LAST CTTIOS FUNCTION FOR MSG
L R3,ADBPIRC CONVERT
CVD R3,DW ..LAST CTTIOS
UNPK MSG2RC(3),DW+6(2) .. RETURN-CODE
OI MSG2RC+2,XF0 .. FOR MESSAGE
SPACE 1
L R3,ADBPIRSN CONVERT
CVD R3,DW ..LAST CTTIOS
UNPK MSG2RSN(5),DW+5(3) .. REASON-CODE
OI MSG2RSN+4,XF0 .. FOR MESSAGE
SPACE 1
MVC WTO2+10(MSG2LEN),MSG2 MOVE MESSAGE TO BE WTOED
WTO2 WTO +
,ROUTCDE=11
SPACE 1
B EXIT
SPACE 1
EXIT DS 0H
TM FLAG,$OPENED IS MDB STILL OPENED ?
BNO SKIPEND ..N, SKIP END
SPACE 1
CTTACCDB END,PARMS=ADBPARMS
SPACE 1
SKIPEND DS 0H
BRTRN 0
SPACE 1
*********************************************************************
* WORK AREAS *
*********************************************************************
DW DS D DOUBLE WORD
*
FLAG DS X INTERNAL FLAG
$OPENED EQU X80 MARK: MDB IS OPENED
*
MSG1 DS 0C 1ST ERROR MESSAGE
DC CCTTACCDB FUNCTION:
MSG1FUNC DS CL8
DC C FOR VOLUME: MSG1VOL DS CL6
DC C FAILED. RC:
MSG1RC DS CL3
MSG1LEN EQU *-MSG1
*
MSG2 DS 0C 2ND ERROR MESSAGE
DC CLAST CTTIOS FUNCTION:
MSG2FUNC DS CL8
DC C RC:
MSG2RC DS CL3
DC C REASON:
MSG2RSN DS CL5
MSG2LEN EQU *-MSG2
*
VOL DS CL6 VOLUME SERIAL NUMEBR TO READ
VOLREC DS (DVLLEN)X MDB RECORD BUFFER
*
ADBPARMS DS (ADBPLEN)X CTTACCDB WORK PARMS
*********************************************************************
* MAPPING DSECTS *
*********************************************************************
CTTDBTP , CTTIOS PARMS
CTTADBP , CTTACCDB PARMS
CTTDVL , MDB VOLUME RECORD MAP
END
Rule Search API
The CONTROL-T Rule Search API is a powerful tool that can be used to determine what
actions (DO statements) will be triggered when a given set of selection criteria (specified
via ON statements) is satisfied.
The following steps describe how to use the CONTROL-T Rule Search API:
1. Obtain the address of the CONTROL-T Control Table (TCT) of the real-time Environment
via macro CTTGTCT. (See Obtaining the Address of the Real-Time TCT earlier in this
section.)
2. Specify desired selection criteria (i.e., ON statements) via the RSO block (described below).
3. Call the Rule Search API with the necessary arguments specified.
4. Analyze the information returned by the Rule Search API in the RLM and RSI control blocks.
Note The CONTROL-T Rule Search API searches only the rules currently in memory. If new
rules have been defined but are not yet loaded, CONTROL-T rules should be refreshed
before the Rule Search API is invoked.
Input
A set of selection criteria are specified for the Rule Search API via an RSO block. This
block is passed to the API and is mapped by dsect CTTRSO. For information about how the
RSO block should be set, see the CTTRSO dsect in the IOA Macro library.
An example of how information can be specified in an RSO block is shown below:
SPACE 1
MVI MYRSO,C Clear RSO block
MVC MYRSO+1(LMYRSO-1),MYRSO
LA R3,MYRSO
USING RSO,R3
MVC RSODSN,MYDSN Specify ON DATASET criteria
MVC RSOVOL,MYVOL Specify ON VOLUME criteria
DROP R3
.
.
MYRSO DS XL(RSOLEN)
MYDSN DC CL44MY.FILE
MYVOL DC CL6VOL001
SPACE 1
The Rule Search API scans CONTROL-T rules currently in memory and determines which
actions (DO statements) would be invoked by the specified selection criteria. The Rule
Search API needs the address of the Real-Time TCT in order to determine the address of
the currently loaded rules in memory. The address of the Real-Time TCT must be included
in the CALL statement used to invoke the Rule Search API.
Use macro CTTGTCT (described earlier in this section) to determine the address of the
Real-Time TCT.
Output
The Rule Search API returns information in the following control blocks:
RLM Information about DO statements which are performed in response to
the specified selection criteria.
RSI Information about DO statements in control block RLM (e.g., the rule
name, table name and library in which each DO statement was found).
The addresses for control blocks RLM and RSI are indicated as parameters in the CALL
statement which is used to invoke the Rule Search API. (See Invoking the Rule Search
API below for more information.)
Control Block RLM
Control block RLM is mapped by the CTTRLM dsect. Whereas an RLM control block is
normally created for each CONTROL-T rule in memory, the RLM control block created by
the rule search API contains information about all DO statements that are triggered by
selection criteria specified in the RSO block (described above).
This control block is composed of the following components:
A rule header. This part of the control block normally contains rule-specific information
(e.g., rule mode).
Information about DO statements which can be assigned only one set of values (e.g.,
DO STACK, DO POOL and DO LABEL).
Information about DO statements which can be assigned multiple sets of values (e.g.,
DO VAULT or DO STKGROUP).
Information about DO statements which perform IOA functions (e.g., DO FORCEJOB,
DO SHOUT or DO CONDITION).
Each DO statement describing an IOA function is preceded by a one-byte number
describing the length of the DO statement. This number can be used while extracting
information from the RLM control block to move from the description of one DO
statement to the description of the next DO statement.
For more information about the fields in the RLM control block, see the CTTRLM dsect in
the CONTROL-T MACRO library.
Control Block RSI
The RSI control block contains information about each of the DO statements described in
the RLM control block (described above).
The following information is provided for each DO statement:
The name of the rule containing the DO statement.
The name of the rule table.
The name of the library from which the rule table was loaded into memory.
The address of the RLM control block that describes the rule from which the
information was extracted. This RLM control block is not the one created by the Rule
Search API. This RLM block was created as part of the CONTROL-T rule load process.
For more information about the fields in the RSI control block, see the CTTRSI dsect in the
IOA MACRO library.
Invoking the Rule Search API
Use the following call statement to invoke the CONTROL-T Rule Search API:
CALL CTTRSR,(func-addr,tct-address,rso-address,expdt,rlm-address,rsi-address)
where:
func-addr The address of a function specification which indicates the action to be
performed by the API. The address specified in this field points to a
one-byte character which indicates the function to be performed by the
API.
The following function types can be specified:
R Return only the DO statements that are triggered in
response to the specified selection criteria. This function
creates only an RLM control block. The RSI address
(described below) need not be specified.
O Return only the information about the rules triggered by
the specified selection criteria. This function creates only
an RSI control block.
I Return the DO statements and rule information. This
function creates both the RLM and RSI control blocks
(described above).
F Free control blocks RLM and RSI (which were created by
previous runs of the Rule Search API). This function
should be specified in the last call to the API.
tct-address The address of the Real-Time TCT.
rso-address Address of the RSO block (described above) within the user program
which is calling the Rule Search API.
expdt JCL EXPDT keyword to be associated with the specified selection
criteria. If no keyword is needed, specify 0 for this argument in the
CALL statement.
rlm-address Address of a full-word in which to return the address of the RLM
control block (described above).
rsi-address Address of a full-word in which to return the address of the RSI
control block (described above).
Sample Call to the Rule Search API
The following lines demonstrate a call to the CONTROL-T Rule Search API:
L R12,TCTADDR
CALL CTTRSR,(RSEARCH,(12),RSOBLK,0,RLMADDR,RSIADDR)
.
.
.
TCTADDR DS A
RSEARCH DC CR
RSOBLK DS XL(RSOLEN)
RLMADDR DS A
RSIADDR DS A
A more detailed example is provided later in this section.
Return Codes
The Rule Search API returns one of the following return codes in general register 15:
0 The Rule Search API was successfully completed.
4 No CONTROL-T rule currently in memory is triggered by the specified
selection criteria.
8 GETMAIN error.
12 Internal error.
16 FREEMAIN error.
20 An invalid argument was specified in the CALL statement which was
used to invoke the Rule Search API.
Sample For Using the Rule Search API
The following sample program demonstrates usage of the Rule Search API. This sample
includes commands which print the information in the RLM and RSI control blocks (i.e.,
the DO statements and relevant descriptions).
This sample is located in member CTTSAM3 in the IOA SAMPLE library.
***********************************************************************
* *
* CTTSAM3 *
* *
* Using Rule Search API - Sample *
* *
* V 5.1.4 *
* ------------------------------------------------------------------- *
* *
* FUNCTION: This sample program demonstrates the Rule Search API. *
* This program obtains a copy of the real-time environment *
* TCT, specifies two ON statements and calls the API. *
* *
* Upon return from the API, the program searches the RLM *
* control block created by the API for DO STACK, DO VAULT *
* and DO CONDITION statements which are triggered by the *
* specified ON criteria. The DO statements that are *
* detected are then printed out. *
* *
* RETURN CODES: *
* 00 OK *
* 04 No matching rules were triggered/found *
* 24 SYSPRINT file could not be opened *
* 28 TCT could not be obtained. CONTROL-T is *
* probably not active *
* Other Internal error in API (see documentation) *
* *
* LOGIC: The following steps are performed by this sample program:*
* *
* 1. Obtain a copy of the real-time environment TCT. *
* *
* 2. Specify ON DATASET and ON VOLUME criteria and call *
* the Rule Search API. *
* *
* 3. Search for DO STACK, DO VAULT and DO CONDITION *
* statements in the RLM control block created by *
* the API, and print information about detected DO *
* statements. *
* *
* 4. If a DO STACK statement was found in the previous *
* step, print the rule name, the table name, and the *
* library name in which the DO STACK statement was *
* found. *
* *
* DD CARDS: SYSPRINT - Output file *
* *
* DISCLAIMER: This sample is provided on an as-is basis, without any *
* warranty, either expressed or implied. *
* *
* REGISTERS: R13 - Base *
* R12 - TCT address *
* R2 - SYSPRINT DCB address *
* R3:R7 - Work registers *
* *
* RMODE 24 *
* *
* TO COMPILE AND LINK THE PROGRAM: *
* *
* //CTTSAMP JOB ... *
* //C.SYSIN DD DISP=SHR,DSN=CTT.V514.SAMPLE(CTTSAM3) *
* //C.AIOALOAD DD DISP=SHR,DSN=IOA.AIOALOAD <<<----- CHANGE *
* //L.SYSLMOD DD DISP=SHR,DSN=YOUR.LOAD.LIBRARY <<<----- CHANGE *
* //L.SYSIN DD * *
* INCLUDE AIOALOAD(CTTRSR) *
* INCLUDE AIOALOAD(IOADBG) *
* INCLUDE AIOALOAD(IOAMVN) *
* MODE AMODE(31),RMODE(24) *
* ENTRY CTTSAM3 *
* NAME CTTSAM3(R) *
* //* *
* //RUN EXEC PGM=CTTSAM3,COND=(0,NE) *
* // DD DISP=SHR,DSN=IOA.V514.LOAD *
* //SYSPRINT DD SYSOUT=* *
* // *
* *
***********************************************************************
CTTSAM3 CSECT
CTTSAM3 AMODE 31
CTTSAM3 RMODE 24
BEGIN EQUR=YES
CTTLEVEL CTTAPI,1.0.0
*
XC RC,RC Clear RC
SPACE 1
***********************************************************************
* GET ADDRESS OF REAL-TIME ENVIRONMENT TCT *
***********************************************************************
SPACE 1
CTTGTCT TCTADDR=ACTVTCT,TEST=ACT
LTR R15,R15 TCT loaded ?
BNZ TCTFAIL N, exit
SPACE 1
***********************************************************************
* BUILD ON COMMANDS BLOCK *
***********************************************************************
SPACE 1
MVI MYRSO,C Clear RSO block
MVC MYRSO+1(LMYRSO-1),MYRSO
LA R3,MYRSO
USING RSO,R3
MVC RSODSN,MYDSN Set ON DATASET command
MVC RSOVOL,MYVOL Set ON VOLUME command
DROP R3
SPACE 1
***********************************************************************
* CALL RULE SEARCH API *
***********************************************************************
SPACE 1
MVI FUNCTYPE,CI Extract DO commands & rule info
L R12,ACTVTCT
CALL CTTRSR,(FUNCTYPE,(R12),MYRSO,EXPDT,DOOPT,RULEINFO),VL
C R15,=F4 Any matching rules found ?
BE NOMATCH No, exit
BH RSRFAIL Rule search API failed ?
SPACE 1
***********************************************************************
* OPEN SYSPRINT FILE *
***********************************************************************
SPACE 1
OPEN (SYSPRINT,OUTPUT)
LA R2,SYSPRINT
USING IHADCB,R2
TM DCBOFLGS,DCBOFOPN Successfully opened ?
DROP R2
BNO OPENFAIL
SPACE 1
***********************************************************************
* PRINT OUT THE TRIGGERED DO Statements *
***********************************************************************
SPACE 1
BAL R14,PRTDO
SPACE 1
***********************************************************************
* PRINT OUT THE INFORMATION ORIGIN *
***********************************************************************
SPACE 1
BAL R14,PRTINFO
SPACE 1
***********************************************************************
* CLOSE SYSPRINT FILE *
***********************************************************************
SPACE 1
CLOSE SYSPRINT
SPACE 1
***********************************************************************
* FREE RULE SEARCH API *
***********************************************************************
SPACE 1
MVI FUNCTYPE,CF Free request
CALL CTTRSR,(FUNCTYPE,(R12),0,0,DOOPT,RULEINFO),VL
LTR R15,R15 RLM/RSI freed ?
BNZ RSRFAIL Rule search API failed ?
B RETURN Return
SPACE 1
***********************************************************************
* CHECK SELECTED DO COMMANDS AND PRINT THEM OUT *
***********************************************************************
SPACE 1
PRTDO EQU *
LR R11,R14 Save return address
***
* Check DO command (in fixed part of RLM)
***
L R3,DOOPT Get address of RLM block
USING RLM,R3
CLI RLMDPSTK,RLMDPSBL DO STACK command is blank ?
BE CHKVLT Yes, go check DO VAULT
MVC STACKVAL(1),RLMDPSTK
PUT SYSPRINT,STACK PRINT DO STACK = X
***
* Check DO command (in dynamic part of RLM)
***
CHKVLT EQU *
ICM R6,15,RLMDV#VL Any DO VAULT commands ?
BZ CHKMORE No, go check other DO commands
L R5,RLMDVADR Yes, get address of vaults block
VLTLOOP MVC VAULTNAM(LRLMDVNAM),0(R5)
PUT SYSPRINT,VAULT Print DO VAULT = <vault-name>
LA R5,RLMDLVLT(R5) Skip to next vaulting pattern
BCT R6,VLTLOOP
CHKMORE EQU *
ICM R5,15,RLMDOADR Address of DO block
BZ NOMORE
USING RLMRCRDS,R5
L R6,RLMD#IOA No. of DO <IOA-cmd> commands
XR R7,R7
MOREDO MVI IOACMDV,C Clear output record
MVC IOACMDV+1(LIOACMDV-1),IOACMDV
CLI RLMDTYPE,RLMDCOND Is it a DO CONDITION command ?
BNE SKIPNXT No, skip to next DO command
MVC IOACMDV(LRLMDCCND),RLMDCCND
PUT SYSPRINT,IOACMD Print the DO command
ICM R7,B0001,RLMLRCRD Length of the DO command
SKIPNXT AR R5,R7 Skip to next command
BCT R6,MOREDO
DROP R5
NOMORE EQU *
BR R11
SPACE 1
***********************************************************************
* PRINT OUT THE INFORMATION ORIGIN *
***********************************************************************
SPACE 1
PRTINFO EQU *
LR R11,R14 Save return address
CLI STACKVAL,C DO STACK command retrieved ?
BE NOSTACK No, dont print its origin
***
* Print information about the origin of the DO STACK command
***
L R3,RULEINFO Get address of RSI block
USING RSI,R3
MVC RULENAME(LRSISRLNM),RSISRLNM
LA R4,RULENAM
PUT SYSPRINT,(R4) Print the rule name
MVC RULETABL(LRSISTBNM),RSISTBNM
LA R4,RULETAB
PUT SYSPRINT,(R4) Print the rule table
MVC RULELIBR(LRSISTBLB),RSISTBLB
LA R4,RULELIB
PUT SYSPRINT,(R4) Print the rule library
NOSTACK EQU *
BR R11
SPACE 1
***********************************************************************
SPACE 1
NOMATCH EQU * No rule was triggered
LA R15,RC4
ST R15,RC
B RETURN
*
OPENFAIL EQU * SYSPRINT Open failed
LA R15,RC24
ST R15,RC
B RETURN
*
TCTFAIL EQU * TCT could not be obtained
LA R15,RC28
ST R15,RC
B RETURN
*
RSRFAIL EQU * Rule search API has failed
ST R15,RC
B RETURN
*
RETURN L R15,RC Return to caller
BRTRN (15)
*--------------------------------------------------------------------*
LTORG
EJECT
*--------------------------------------------------------------------*
* COMMON BLOCK AREA *
*--------------------------------------------------------------------*
COMBLOCK DS 0D
*
* Constants
*
RC4 EQU 4
RC24 EQU 24
RC28 EQU 28
*
RC DS F Routines return code
ACTVTCT DS A TCT address
MYDSN DC CL44N89.CHKIN.TRY
MYVOL DC CL6CHKIN0
DOSTKFND DS C DO STACK command found ? (Y/N)
*---------------------------------------------------------------------*
FUNCTYPE DS C Function type
MYRSO DS XL(RSOLEN) ON statement(s)
DOOPT DC A(0) Address of RLM block
RULEINFO DC A(0) Address of RSI block
EXPDT DC F0 JCL expdt
*---------------------------------------------------------------------*
SYSPRINT DCB DDNAME=SYSPRINT,DSORG=PS,MACRF=PM,RECFM=FB,LRECL=121
*---------------------------------------------------------------------*
IOACMD DC CL14DO CONDITION:
IOACMDV DS CL107
STACK DC CL11DO STACK =
STACKVAL DS CL110
VAULT DC CL11DO VAULT =
VAULTNAM DS CL110
RULENAM DC CL37DO STACK command taken from rule:
RULENAME DS CL84
RULETAB DC CL37 from table:
RULETABL DS CL84
RULELIB DC CL37 from library:
RULELIBR DS CL84
*---------------------------------------------------------------------*
EJECT
IEFJSCVT Macros for CTTGTCT
IEFJESCT
COPY CTTSSVT
CVT CVT DSECT=YES,PREFIX=YES
TCT DSECT
COPY CTTTCT TCT layout
*---------------------------------------------------------------------*
EJECT
RSO DSECT ON statement(s)
COPY CTTRSO
RLM DSECT DO statement(s)
COPY CTTRLM
RSI DSECT Rules information
COPY CTTRSI
RLD DSECT Equates for CTTRLM
COPY CTTRLD
RLX DSECT Equates for CTTRLM
COPY CTTRLX
DCBD DSORG=PS
*---------------------------------------------------------------------*
END
Introduction..................................................................................................................................8-1
IOA Release 5.1.4 Packaging .....................................................................................................8-1
Product Packaging......................................................................................................................8-1
Language Support ......................................................................................................................8-1
Applying Periodic Maintenance...............................................................................................8-4
Preliminary Steps.......................................................................................................................8-4
Step 1 Apply Periodic Maintenance ....................................................................................8-4
Applying Ad Hoc Maintenance .................................................................................................8-5
Introduction ................................................................................................................................8-5
Step 1 Run SMP/E to RECEIVE, APPLY CHECK and APPLY the Fix...........................8-5
Step 2 Customize and Propagate Fix Elements to Working Libraries .............................8-7
Processing Elements with DEFPARMx Members or a SYSLIB Library of GENERAL....8-9
Step 3 Enable Fixes Applied to ICE..................................................................................8-11
Step 4 Copy JCL Procedures and ISPF Elements to System Libraries (Optional) ........8-11
Introduction
For IOA Release 5.0.0 and higher, maintenance is performed via PTFs containing object
replacement elements using SMP/E at level 1.8 or higher with IBM APAR IR26630
installed.
The documentation in this section assumes that the reader has a general knowledge of
SMP/E.
The following paragraphs present a technical overview of the IOA Release 5.1.4
installation in order to facilitate the understanding of the maintenance processes.
IOA Release 5.1.4 Packaging
IOA Release 5.1.4 is packaged as a pre-installed SMP/E environment containing three
SMP/E zones: GLOBAL, Target and Distribution.
IOA Release 5.1.4 supports use of any one of the following installation modes for the
SMP/E CSI:
A new CSI file loaded with the GLOBAL, Target and Distribution zones.
An existing global zone for the IOA GLOBAL zone and two new CSI files, one for the
Target zone and one for the Distribution zone.
An existing CSI file for all three zones. The IOA GLOBAL zone is added to the existing
global zone, while the Target and Distribution zones form separate entities in the file.
Product Packaging
The products in IOA Release 5.1.4 are packaged as different functional components as
listed in the following table. This release is based on previous releases of IOA 5.x.x and
includes the functional components of those releases where applicable. IOA is the base
component for all products.
Table 1: IOA Release 5.1.4 Functional Components
FMID Product
IOA5140, IOA5040, IOA5000 IOA Release 5.1.4 Common Routines, Samples, etc.
IOA514C IOA Release 5.1.4 C Language Modules
CTM5140, CTM5040, CTM5000 CONTROL-M Release 5.1.4 Modules and Samples
CTL5140, CTL1200 CONTROL-M/Workload Release 5.1.4 Modules and
Samples
CTG5140, CTG5000 CONTROL-M NJE GATEWAY Release 5.1.4 Modules
CTD5140, CTD5040, CTD5000 CONTROL-D Release 5.1.4 Modules and Samples
CTD514C, CTD504C, CTD500C CONTROL-D Release 5.1.4 C Language Modules
CTR5140, CTR5040, CTR5000 CONTROL-R Release 5.1.4 Modules and Samples
CTO5140, CTO5000 CONTROL-O Release 5.1.4 Modules and Samples
CTB5140, CTB5040, CTB5000 CONTROL-B Release 5.1.4 Modules and Samples
CTB514C, CTB504C, CTB500C CONTROL-B Release 5.1.4 C Language Modules
CTW5140, CTW5040, CTW5000 MVS Gateway for Enterprise Controlstation Release
5.1.4 Modules and Samples
CTW514C, CTW500C MVS Gateway for Enterprise Controlstation Release
5.1.4 C Language Modules
CTV5140, CTV5040, CTV5000 CONTROL-V Release 5.1.4 Modules and Samples
CTT5140, CTT5000 CONTROL-T Release 5.1.4 Modules and Samples
IOX5140 IOA/Pathfinder Release 5.1.4 Modules and Samples
Language Support
IOA Release 5.1.4 supports various languages. Program elements for each language are
packaged as unique functions in IOA Release 5.1.4 as follows:
Table 2: Language Elements
FMID Elements Contained
IOA514F, IOA504F, IOA500F IOA Release 5.1.4 French Elements
IOA514G, IOA504G, IOA500G IOA Release 5.1.4 German Elements
IOA514J IOA Release 5.1.4 Japanese Elements
A different SMP/E environment exists for each language supported by IOA Release 5.1.4.
Each environment contains the IOA Release 5.1.4 functions listed in Table 1 above, as well
as the appropriate language function (applied and accepted). Each language function
contains a LOAD library in which the load modules which support the language in
question are stored. These load modules, as well as screen and message source members,
are named according to the language they support (e.g., GEMMABC is the name of the
message member for ABC).
This naming convention enables SMP/E to support the libraries of the basic English
installation as well as the libraries of the language support installation. However, it
prevents maintenance from identifying the modules that should be updated. The following
example demonstrates aliases that are utilized to overcome this problem.
The example in the table below compares the linking of comparable English and German
load modules (containing the same functionality). In the example, the English load module
is linked into the IOA LOAD library while the German NLS (National Language Support)
load module is linked into the LOADGER library.
Table 3: Example
English German Comments
ORDER CTMABC ORDER CTMABC Non-NLS MOD
ORDER CTMMABC ORDER GEMMABC Language
sensitive MOD
INCLUDE (CTMABC) INCLUDE (CTMABC)
INCLUDE (CTMMABC) INCLUDE (GEMMABC)
NAME CTMABC(R) ALIAS CTMABC
NAME GEMABC(R)
LOAD LOADGER SYSLMOD name
Applying Periodic Maintenance
Periodic maintenance is applied via the Installation and Customization Engine (ICE).
Perform the following preliminary steps and installation steps to apply periodic
maintenance.
Preliminary Steps
1. Load the maintenance tape files to the BASE.MAINT library.
2. Refer to the IOA Installation Guide for instructions on how to invoke and use ICE.
3. Invoke ICE and verify that IOA is specified in the Product ID field, and that YES
is specified in the Enforce Step Order field.
4. Select option 4 (Maintenance) on the ICE menu. Major steps for installing maintenance
are then displayed.
5. Apply the major steps listed below.
Installation Steps
Step 1 Apply Periodic Maintenance
Select major step 1 Apply Periodic Maintenance. The Minor Steps Selection screen is
displayed.
Step 1.1 Specify Maintenance Level
Select minor step 1 Specify Maintenance Level.
In the Maintenance Level Specification screen, specify the maintenance to be applied in
the format yynn (where yy represents the year and nn represents a sequence number).
Specify YES in the Do you want to reset the steps status? field.
Exit the Maintenance Level Specification screen.
Mark this step as completed.
Step 1.2 View Maintenance Documentation (Optional)
If written documentation is available, read it.
Follow the steps specified in the documentation to apply the maintenance.
Applying Ad Hoc Maintenance
Introduction
Fixes to IOA Release 5.0.0 and above are applied using SMP/E level 1.8 or higher with IBM
APAR IR26630 installed. (The Installation and Customization Engine is not used to apply
ad hoc maintenance.)
Once a fix is applied by SMP/E, the affected elements which reside in base libraries
(e.g., source members, the JCL, samples) often contain unresolved installation variables
and are likely to require further tailoring. These elements must be propagated (i.e., copied
and tailored) to the working libraries. Other elements, such as load modules, are applied
by SMP/E directly to the working libraries and do not require any further processing.
The following steps describe how to install a fix in the active environment.
Installation Steps
Step 1 Run SMP/E to RECEIVE, APPLY CHECK
and APPLY the Fix
LOAD the fixes into your IOA MAINTLIB library. It is recommended that you use the
same name for the member as the fix name.
Example
Fpnnnnn
where:
p Product ID
nnnnn Fix number (e.g., FI12345)
Run an SMP/E job using the supplied IOASMP procedure to:
RECEIVE the fixes into your SMP/E CSI file which contains IOA Release 5.1.4.
APPLY CHECK the fixes for detection of errors (e.g., missing prerequisite fixes).
Note Procedure IOASMP is used in examples throughout this section. However, if
installation parameter PROCPREFA was changed in ICE from its supplied default,
the procedure name should be modified accordingly. This also applies to other JCL
procedures which are executed. Similarly, the target zone that is indicated in the
sample job below is the default zone name IOA5TZN. If installation parameter
IOATZN was modified in ICE, the modified value should be used instead.
The following is a sample JCL for an SMP/E RECEIVE and APPLY CHECK job:
//SMPJOB JOB ,your job-card,.....
//SMPSTEP EXEC IOASMP
//SMPPTFIN DD DISP=SHR,DSN=IOA.V514BASE.MAINTLIB(FI12345)
// DD DISP=SHR,DSN=IOA.V514BASE.MAINTLIB(FMnnnnn)
//SMPCNTL DD *
SET BDY(GLOBAL).
RECEIVE SYSMODS LIST.
SET BDY(IOA5TZN).
APPLY S(FI12345, FMnnnnn,.....) CHECK.
/*
Before applying a fix, verify its SMP/E HOLD status. A fix may be in HOLD status due to
an error or an action that must be performed. The output of the SMP/E RECEIVE
SYSMODS LIST lists any HOLDDATA associated with the fixes that were received.
If the current fix being applied is in HOLD status, the HOLDDATA indicates the reason. If
the reason is ACTION, a comment describes the steps to be taken prior to or following the
APPLY of the fix. Ensure that these instructions are carefully followed.
If the fix is held, the APPLY CHECK fails and displays an informational message. If you
have reviewed the HOLDDATA and know which actions are required, you can add the
keyword BYPASS(HOLDSYS) to the APPLY CHECK statement and rerun it. If, however,
the reason for the hold is ERROR, the fix should not be applied until a corrective fix is
available.
The following is a sample SMP/E APPLY CHECK job with the bypass for the HOLD status:
//SMPJOB JOB ,your job-card,.....
//SMPSTEP EXEC IOASMP
//SMPCNTL DD *
SET BDY(IOA5TZN).
APPLY S(FI12345) BYPASS(HOLDSYS) CHECK.
/*
When the APPLY CHECK completes successfully, the CHECK keyword should be removed
and the APPLY should be run to install the fix in the IOA target environment.
Step 2 Customize and Propagate Fix Elements to
Working Libraries
Perform this step only if a fix that was applied in Step 1 is on HOLD with an ACTION
reason that requires tailoring and propagation.
Applicable fixes are those which modify elements (PDS members) in base libraries which
may require file tailoring and are likely to contain unresolved variables (e.g., parameter
ILPREFA). Two IOA utilities, IOAFTR and IOAINS, are run for these fix elements. Fixes
to load modules are always applied directly to the active environment.
During propagation, all elements applied by a single SMP/E APPLY command should be
propagated at the same time to verify that all prerequisite and corequisite fixes are applied
to the working environments. To determine which elements require propagation, and the
appropriate action, review the Element Summary report in the SMPRPT dataset (produced
by SMP/E APPLY) and follow the rules below:
Elements that meet any of the following criteria do not require propagation:
Elements with an entry in the LMOD SYSLIB column, except user and security exits.
Elements with one of the following listed in the SYSLIB library column: MAC, MSG,
PANEL, ISMSG, CICSSAMP, SAMPREPS, BANNERS, CAL.
Elements that are part of ICE (i.e., elements whose names begin with IOAI and have a
SYSLIB library specification of INSTALL).
Elements with a SYSLIB library specification of GENERAL. For these elements, a
different procedure, described later in this section, is required.
The following sample Element Summary report sample shows two elements that require
propagation: CONTROLM (in the IOA PROCLIB library), and $PROFFLD (in the IOA
PARM library). Elements CTDSEC, CTMCUSI and IOAHLP do not require propagation
because they all have entries listed in the LMOD SYSLIB column. $$FRM does not require
propagation because its SYSLIB library is MSG, and IOAICHLP is part of ICE (i.e., starts
with IOAI and has INSTALL listed in the SYSLIB library column).
ELEMENT SUMMARY REPORT FOR APPLY CHECK PROCESSING
ELEMENT ELEMENT ELEMENT CURRENT CURRENT DISTLIB SYSLIB ASSEM LOAD LMOD SYSMOD SYSMOD
TYPE NAME STATUS FMID RMID LIBRARY LIBRARY NAMES MODULE SYSLIB NAME STATUS
MAC CONTROLM APPLIED IOA5140 FI00075 APROCLIB PROCLIB FI00075 APPLIED
SRC CTDSDEC APPLIED IOA5140 FI00071 AMSG MSG CTDSDEC CTDTAMS LOAD FI00071 APPLIED
MOD CTMCUSI APPLIED IOA5140 FI00072 AIOALOAD CTMCINT LOAD FI00072 APPLIED
CTMCTSO LOAD
MOD IOAHLP APPLIED IOA5140 FI00030 AIOALOAD IOAHLP INSL FI00030 APPLIED
HELPENP $$FRM APPLIED IOA5140 FI00073 AMSG MSG FI00073 APPLIED
PARM $PROFFLD APPLIED IOA5140 FI00083 APARM PARM FI00083 APPLIED
SAMP IOAICHLP APPLIED IOA5140 FI00030 AINSTALL INSTALL FI00030 APPLIED
Change the member name that was changed or replaced and the last qualifier (suffix) of
the library in accordance with the value listed in the SYSLIB library column for that
element. For example, if member CONTROLD was replaced in the PROCLIB library, the
JCL will appear as follows:
//MYJOB JOB my job card,....
//*========================================
//* PERFORM:
//* CHANGE ???????? member-name ALL
//* CHANGE @@@@@@@ library suffix ALL
//*========================================
//PROP1 EXEC IOAPROP,
// BASEPRF=IOA514.BASE, <===== Specify YOUR BASEPRF
// ILPREFA=IOA514.TESTI <===== Specify YOUR ILPREFA
//IOAFTR.SYSIN DD *
COPY INDD=IPROCLIB,OUTDD=OPROCLIB <===== Input cards to IOAFTR
SELECT MEM=CONTROLD,REPLACE=YES <===== Input cards to IOAFTR
/*
//IOAINS.DALIBS DD *
*---+----1----+----2----+----3----+----4----+
CONTROLD IOA514.TESTI.PROCLIB <===== Input cards to IOAINS
/*
If more than one member or more than one library is changed by the fix, you can repeat the
control cards of both utilities as necessary. For example, the following is a sample job that
propagates members CONTROLM and CONTROLD in the PROCLIB library, and member
$PROFFLD in the PARM library:
/MYJOB JOB my job card,....
//*========================================
//* PERFORM:
//* CHANGE ???????? member-name ALL
//* CHANGE @@@@@@@ library suffix ALL
//*========================================
//PROP1 EXEC IOAPROP,
// BASEPRF=IOA514.BASE, <===== Specify YOUR BASEPRF
// ILPREFA=IOA514.TESTI <===== Specify YOUR ILPREFA
//IOAFTR.SYSIN DD *
COPY INDD=IPROCLIB,OUTDD=OPROCLIB <===== Input cards to IOAFTR
SELECT MEM=CONTROLM,REPLACE=YES <===== Input cards to IOAFTR
SELECT MEM=CONTROLD,REPLACE=YES <===== Input cards to IOAFTR
COPY INDD=IPARM,OUTDD=OPARM <===== Input cards to IOAFTR
SELECT MEM=$PROFFLD,REPLACE=YES <===== Input cards to IOAFTR
/*
//IOAINS.DALIBS DD *
*---+----1----+----2----+----3----+----4----+
CONTROLM IOA514.TESTI.PROCLIB <===== Input cards to IOAINS
CONTROLD IOA514.TESTI.PROCLIB <===== Input cards to IOAINS
$PROFFLD IOA514.TESTI.PARM <===== Input cards to IOAINS
/*
After performing the necessary customization, submit the job. All steps must end with a
condition code of 0.
Processing Elements with DEFPARMx Members or a SYSLIB Library
of GENERAL
Elements that have DEFPARMx members or a SYSLIB library of GENERAL should be
processed according to the following rules:
Elements belonging to non-installed products require no further processing.
Elements belonging to installed products must be copied manually to the product
library as directed by the HOLD action of SMP/E. The element may contain unresolved
installation variables. Therefore, utility IOAINS should be run to resolve them. To run
utility IOAINS, modify job IOAINSJ in the IOA INSTALL library (as described below).
The default IOAINSJ member is presented below:
//****************************************************************
//* PLEASE MAKE THE FOLLOWING CHANGES: *
//* CHANGE ???????? MEMBER-NAME ALL *
//* CHANGE @@@@@@@@ FULLY-QUALIFIED-LIBRARY-NAME *
//* CHANGE &&& 3-CHARACTER-PRODUCT-ID ALL (E.G.CTM) *
//* CHANGE # 1-CHARACTER-PRODUCT-ID (E.G. M) *
//****************************************************************
//CTMINST EXEC PGM=IOAINS,PARM=&&&, <=== Check Parm
// REGION=5120K,TIME=30
//STEPLIB DD DISP=SHR,DSN=%BASEPREF%.INSLOAD
//PRTDBG DD DUMMY
//SYSUDUMP DD SYSOUT=*
//DAREP DD DISP=SHR,DSN=&ILPREFA%.INSTALL(DEFPARMA)
// DD DISP=SHR,DSN=&ILPREFA%.INST&&&(DEFPARM#) <=== Check library/member
//DALIBS DD
* IOAINS INPUT STATEMENTS
*---+----1----+----2----+----3----+----4----+
???????? @@@@@@@@ <=== IOAINS CONTROL CARDS
/*
Change the member as follows:
Replace ???????? with the member name from the ELEMENT NAME column.
Replace @@@@@@@@ with the fully-qualified dataset name. The SMP/E HOLD data
will contain the library suffix.
Replace &&& with the three-character product ID from the SMP/E HOLD data to
specify the value in the PARM field and the name of the product installation library.
Replace # with the one-character product ID from the SMP/E HOLD data to resolve the
name of the DEFPARMx member in the product installation library.
If the product is CONTROL-R, repeat the second DAREP line and modify it so that it
points to member DEFPARMM in the IOA INSTCTM library.
If the product is CONTROL-V, repeat the second DAREP line and modify it so that it
points to member DEFPARMD in the IOA INSTCTD library.
IOAINS control cards can be repeated in the same IOAINS step for elements belonging to
the same product.
The following sample shows IOAINSJ tailored to process this member:
//****************************************************************
//* PLEASE MAKE THE FOLLOWING CHANGES: *
//* CHANGE ???????? MEMBER-NAME ALL *
//* CHANGE @@@@@@@@ FULLY-QUALIFIED-LIBRARY-NAME *
//* CHANGE &&& 3-CHARACTER-PRODUCT-ID ALL (E.G.CTM)*
//* CHANGE # 1-CHARACTER-PRODUCT-ID (E.G. M) *
//****************************************************************
//CTMINST EXEC PGM=IOAINS,PARM=CTR, <== Check Parm
// REGION=5120K,TIME=30
//STEPLIB DD DISP=SHR,DSN=your.basepref.INSLOAD
//PRTDBG DD DUMMY
//SYSUDUMP DD SYSOUT=*
//DAREP DD DISP=SHR,DSN=your.ilprefa.INSTALL(DEFPARMA)
// DD DISP=SHR,DSN=your.ilprefa.INSTCTR(DEFPARMR) <== for CONTROL-R
// DD DISP=SHR,DSN=your.ilprefa.INSTCTM(DEFPARMM) <== for CONTROL-M
//DALIBS DD
* IOAINS INPUT STATEMENTS
*---+----1----+----2----+----3----+----4----+
CTRCNPJ your.ilprefr.JCL <== INPUT CARDS TO IOAINS
/*
Submit the job. All steps must end with a condition code of 0.
Step 3 Enable Fixes Applied to ICE
If a fix results in the replacement of ICE tables, the new copy of the table must be merged
with all values previously entered during installation, customization, etc.
Perform this step only if the fix was held in SMP/E with reason ACTION, and the hold
comment refers specifically to enabling ICE fixes.
After applying the fix, enter ICE and choose the Housekeeping activity from the ICE Main
menu. Select Refresh Tables to refresh the ICE elements that were replaced by the fix.
Step 4 Copy JCL Procedures and ISPF Elements
to System Libraries (Optional)
If a fix replaces JCL procedures, CLISTs or ISPF elements which were copied to system
libraries during installation, these elements need to be recopied.
Perform this step only if the fix was held with reason ACTION, and the hold comment
specifically refers to copying JCL procedures and ISPF elements to system libraries.
Skip this step if JCL procedures and ISPF elements are not copied during installation to
your system libraries.
If you chose to copy JCL procedures to your system PROCLIB (i.e., installation parameter
PROCLIB contains a value other than DONTCOPY), any updated procedures should be
recopied. If the value of installation parameter PROCPREFA was modified and does not
use the default value of IOA, the procedures should be copied with a new name that
matches the value specified for PROCPREFA.
If you choose to copy CLISTs or ISPF messages, panels, skeletons or tables to your system
libraries, (i.e., a value other than DONTCOPY was specified for installation parameters
CLIST, ISPFMSG, ISPFPNL, ISPFSKL, or ISPFTBL) updated elements should be
recopied.
General ...........................................................................................................................................9-1
Summary of Utilities ...................................................................................................................9-1
IOA Utilities................................................................................................................................9-1
CONTROL-M Utilities ...............................................................................................................9-2
CONTROL-D/V Utilities ............................................................................................................9-3
CONTROL-O Utilities................................................................................................................9-4
CONTROL-B Utilities ................................................................................................................9-4
CONTROL-T Utilities ................................................................................................................9-5
IOA Utilities...................................................................................................................................9-7
IOABLCAL Build Calendars ..................................................................................................9-7
IOACLRES Clean IOA Conditions/Resources File..............................................................9-13
IOACND Perform IOA Condition/Resource Adjustments...................................................9-16
IOACOPRS Copy/Resize IOA Conditions/Resources File ...................................................9-20
IOACPLOG Copy the IOA Log File......................................................................................9-21
IOADBF Allocate/Format an IOA Access Method File........................................................9-23
IOADBSR Sort Records in an IOA Access Method Data Component ................................9-31
IOADCPY Recover an IOA Access Method File...................................................................9-33
IOADIG Verify Integrity of an IOA Access Method File Data Component........................9-35
IOADII Verify Integrity of an IOA Access Method File Index Component........................9-36
IOADLD Load IOA Access Method File Contents ...............................................................9-37
IOADPT Print IOA Access Method File Content.................................................................9-39
IOADUL Unload IOA Access Method File Contents...........................................................9-40
IOAFRLOG Allocate and Format the IOA Log File ............................................................9-42
IOAFRNRS Allocate and Format the IOA Manual Conditions File...................................9-43
IOAFRRES Allocate and Format the IOA Conditions/Resources File.....................................9-44
IOALDNRS Load IOA Manual Conditions File...................................................................9-46
IOANOTE Write a Message to the IOA Log File.................................................................9-49
IOAOPR - Issue Operator Commands Via a Job or STC .......................................................9-50
IOATEST Simulate Production Environment Events.........................................................9-51
IOAVERFY Verify IOA File Installation and Status ..........................................................9-53
CONTROL-M Utilities .............................................................................................................. 9-59
CTMBGRP Convert Regular Scheduling Tables to Group Scheduling Tables..................9-59
CTMCAJF Maintain the Active Jobs File or History File...................................................9-62
CTMFRCKP Allocate and Format the Active Jobs File......................................................9-68
CTMFRJNL Allocate and Format the Journal File ............................................................9-69
CTMJSA Job Statistics Accumulation .................................................................................9-70
CTMRSTR Restore the CONTROL-M Active Jobs File ......................................................9-73
CONTROL-B Utilities ............................................................................................................... 9-75
CTBABI Initialize Active Balancing File ............................................................................ 9-75
CTBCMP Compile Rule Definitions..................................................................................... 9-76
CTBDBCP Increase Size of a Database File ....................................................................... 9-77
CTBDBIB Rebuild a CONTROL-B Index File.................................................................... 9-79
CTBDBVCG Change Number of Variable Generations ..................................................... 9-81
CTBDBVCP Copy Variables or Groups to Another File..................................................... 9-83
CTBDBVDL Delete Variables/Groups from Variable/Group Files .................................... 9-86
CTBDBVIG Check the Integrity of Variable/Group Files.................................................. 9-88
CTBFRM Compress the Active Balancing File................................................................... 9-89
CTBJAFCP Copies Entries in Rule Activity/Report Files.................................................. 9-90
CTBJAFDL Deletes Entries From Rule Activity/Report Files........................................... 9-92
CTBJAFIG Check the Integrity of Rule Activity/Report Files........................................... 9-94
CONTROL-D/V Utilities ........................................................................................................... 9-95
CTDBLXRP Rebuild Print Control Records in the Active User File ................................. 9-95
CTDCAMF Compress Active Missions File......................................................................... 9-96
CTDCATF Compress Active Transfer File.......................................................................... 9-98
CTDCA2P Copy Active User Report File to Permanent..................................................... 9-99
CTDCCU Delete Unneeded CDAM Files .......................................................................... 9-101
CTDCLHIS Clean History User Report List File ............................................................. 9-103
CTDCP2A Copy Permanent User Report File to Active................................................... 9-104
CTDDELRP Delete Reports Which Are Not Needed........................................................ 9-106
Examples........................................................................................................................... 9-111
CTDDIB Rebuild Index Component of a User Report List File....................................... 9-114
CTDDIG User Report List File Integrity Check............................................................... 9-115
CTDULD User File Report List Load................................................................................ 9-116
CTDUPBKP Update Backup/Migration Details............................................................... 9-117
CTVCLMIG Clean Migrated CDAM Files......................................................................... 9-123
CTVDELI Delete Index Files from DASD......................................................................... 9-125
CTVJAR Job Archiving Utility .......................................................................................... 9-129
CTVUNMIG Unmigrate Utility......................................................................................... 9-132
CONTROL-O Utilities............................................................................................................. 9-133
CTOCSF Copy the Message Statistics File........................................................................9-133
CTOCTA List Programs Running in an Address Space....................................................9-134
CTOCTI Generate Input for the SYSIMAGE Facility ......................................................9-135
CTODBIB Rebuild a CONTROL-O Index File ..................................................................9-138
CTORSTM Statistics Report Utility...................................................................................9-140
CTOTEST Simulate Messages and/or Commands ............................................................9-141
CTOALOCP Backing Up the Automation Log...................................................................9-144
CONTROL-T Utilities ............................................................................................................. 9-146
Control Statement Syntax .....................................................................................................9-146
Record Selection Logic (INCLUDE/EXCLUDE Statements) ...............................................9-146
INCLUDE Statements ......................................................................................................9-147
EXCLUDE Statements .....................................................................................................9-148
INCLUDE/EXCLUDE Examples .....................................................................................9-151
CTTACP Copy Trace File....................................................................................................9-152
CTTAFR Format and Initialize Trace File.........................................................................9-155
CTTBIX Rebuild Media Database Index............................................................................9-156
CTTCRDF Allocate and Format Data/Index Files ............................................................9-158
CTTCTRC Allocate and Format Trace File........................................................................9-160
CTTDBDLD Load Media Database/Stacking Database Data Components.....................9-161
CTTDBDUL Unload Media Database/Stacking Database Data Components.................9-162
CTTDBF Format Existing Data/Index Files......................................................................9-163
CTTDBIB Rebuild Indexes of Stacking Database.............................................................9-164
CTTDBID Check Integrity of Data File .............................................................................9-165
CTTDBII Check Integrity of Index File .............................................................................9-166
CTTDBPRT Print Data Records.........................................................................................9-167
CTTDLD Add/Delete/Convert Volumes..............................................................................9-169
CTTGVL User Interface to Stacking Facility ....................................................................9-173
CTTIDB Check Integrity of the Media Database ..............................................................9-175
CTTMER Merge Records Into the Media Database ..........................................................9-177
CTTMUP Manually Update the CONTROL-T Repository ...............................................9-180
CTTRCV Recover the Media Database Using Trace File..................................................9-191
CTTRPT Database Extraction and Report Utility ............................................................9-195
CTTRSM Recover Tape Activity From SMF Records........................................................9-214
CTTRTM Perform Retention Management........................................................................9-218
CTTSBD Perform Dataset Stacking in Batch Mode..........................................................9-234
CTTSCA Dataset Contention Detection.............................................................................9-264
CTTSPL Copies or Moves Media Database Records......................................................... 9-271
CTTSTK Build and Update Stacking Database ............................................................... 9-276
INCLUDE/EXCLUDE...................................................................................................... 9-277
CTTSTKR Stacking Statistics Report Utility ................................................................... 9-279
CTTSYNC Synchronize Robot Database & Media Database........................................... 9-283
CTTTPI Tape Initialization, Information Mapping, and Tape Erasure.......................... 9-285
CTTTRB Synchronize Trace File and Media Database Backup ...................................... 9-300
CTTVTM Perform Vault Management.............................................................................. 9-301
General
This section describes the administrative utilities available for each IOA product.
A summary of these utilities (by product) is provided below. This section contains a
detailed description of each utility (in alphabetical order by product).
Summary of Utilities
The following list provides a short description of each utility used in the IOA environment.
These utilities are fully described later in this section unless otherwise noted.
Note Some utilities prefixed by IOA replace corresponding utilities prefixed by CTM, CTD
and/or CTB in previous releases. In such cases, the old utilities are supported for your
convenience; however, we recommend using the IOA utilities.
IOA Utilities
IOABLCAL Builds calendars.
IOACLRES Cleans the IOA Conditions/Resources file.
IOACND Performs Condition/Resource Adjustments.
IOACOPRS Copies, or changes the size of, the IOA Conditions/Resources file.
IOACPLOG Copies contents of the IOA Log file to a sequential file or to another
Log file.
IOAFRLOG Allocates and formats an IOA Log file.
IOAFRNRS Allocates and formats an IOA Manual Conditions file.
IOAFRRES Allocates and formats an IOA Conditions/Resources file.
IOALDNRS Creates/loads the IOA Manual Conditions list.
IOANOTE Writes a message to the IOA Log file.
IOAOPR Issues operator commands.
IOATEST Simulates various events in the IOA environment.
IOAVCND For VM/CMS environments. Sets prerequisite conditions in a
CONTROL-M monitor running on an NJE-connected MVS machine.
(See the description of utility IOACND in this section of the manual.)
IOAVERFY Verifies file installation, locates errors, optionally implements
corrections and produces status reports for various IOA files.
CONTROL-M Utilities
Note Some utilities prefixed by IOA replace corresponding utilities prefixed by CTM from
earlier releases of CONTROL-M. In such cases, the CONTROL-M utilities remain
supported for your convenience; however, we recommend using the IOA utilities.
CTMAESIM Tests the syntax of AutoEdit control statements (described in
Section 6 of the CONTROL-M User Manual).
CTMBGRP Converts regular scheduling tables to Group scheduling tables
(described later in this section).
CTMBLDAE Builds an AutoEdit symbols member using an IOA calendar as input
CTMBLT Creates CONTROL-M scheduling tables (described in Section 6 of the
CONTROL-M User Manual).
CTMCAJF Compresses, cleans or changes the size of the CONTROL-M Active
Jobs or History file (described later in this section).
CTMFRCKP Allocates and formats a CONTROL-M Active Jobs file (described later
in this section).
CTMFRJNL Allocates and formats the CONTROL-M Journal file (described later
in this section).
CTMJOB Orders jobs into the Active Jobs file (described in Section 6 of the
CTMJSA Accumulates job statistical data in the CONTROL-M Job Statistics file
CTMRCAL Creates a calendar for each job defined in CONTROL-M showing the
actual execution date(s) of the job (described in Section 6 of the
CTMRELRS Releases Quantitative resources from a job step (described in Section 6
of the CONTROL-M User Manual).
CTMRSTR Restores the Active Jobs File (described later in this section).
CTMSIM Activates the Simulation and Forecasting facility (described in
CTMTAPUL Produces a Tape Pull list (described in Section 7 of the CONTROL-M
User Manual).
CTMTBUPD Updates CONTROL-M group/job scheduling definition parameters in
batch mode (described in Section 6 of the CONTROL-M User Manual).
CTMXRF Produces a variety of cross reference reports (described in Section 6 of
the CONTROL-M User Manual).
CONTROL-D/V Utilities
CTDAMUTI Copies, moves and deletes CDAM files (described in Section 5 of the
CONTROL-D User Manual).
CTDBLXRP Deletes and rebuilds all print control records.
CTDCAMF Compresses or changes the size of the Active Missions file.
CTDCATF Compresses or changes the size of the Active Transfer file.
CTDCA2P Copies new report/user entries from the Active User Report List file to
the Permanent User Report List file.
CTDCCU Identifies CDAM files not referenced by the Active User Report List
file and optionally deletes them.
CTDCLHIS Deletes entries in the History Reports List file and makes a list of
backup tapes which have expired based on parameter # OF
DAYS/GENERATIONS TO KEEP.
CTDCP2A Copies empty report/user entries from the Permanent User Report List
file to the Active User Report List file.
CTDDELRP Moves report entries from the Active to the Migrated and/or History
Report List file and erases their compressed datasets from DASD
storage.
CTDDIB Rebuilds a CONTROL-D User Report List file s index component.
CTDDIG Checks the integrity of Active, Permanent, History and Migration
User Report List files.
CTDFRCOM Allocates and formats a Communication file.
CTDSMFRP Produces a paper usage report (described in Section 6 of the
CTDULD Copies records from a sequential file to the current Active, Permanent,
History or Migrated User Report List file.
CTDUPBKP Updates backup information in User Report List files
(Active/Migrated/History/Permanent).
CTVCLMIG Cleans entries from the Migrated User Report List file and erases or
uncatalogs their CDAM datasets.
CTVDELI Deletes unneeded index files from disk based on user-specified
selection groups.
CTVJAR Consolidates reports that are created by Job Archiving.
CTVUNMIG Reads a migrated CDAM file and recreates the original CDAM file on
DASD.
IOA Access Method Utilities (for User Report List Files)
IOADBF Formats a CONTROL-D User Report List file s index or data
component.
IOADBSR Sorts and reorganizes CONTROL-D User Report List files data component.
IOADCPY Restores a CONTROL-D User Report List file from a dual mirror image copy.
IOADIG Verifies the integrity of a CONTROL-D User Report List file s data
component.
IOADII Verifies the integrity of a CONTROL-D User Report List file s index
component.
IOADLD Loads a CONTROL-D User Report List file s data or index component
from a sequential dataset.
IOADPT Prints a CONTROL-D User Report List file s data and index
component records in SNAP dump format.
IOADUL Unloads a CONTROL-D User Report List file s index or data
component to a sequential dataset.
CONTROL-O Utilities
CTOALOCP Backs up the Automation Log.
CTOCSF Copies the Message Statistics file.
CTOCTA Lists programs running in an address space.
CTOCTI Generates input for the COSMOS SYSIMAGE facility.
CTODBIB Rebuilds a CONTROL-O index file.
CTORSTM Produces reports on message statistics.
CTOTEST Simulates messages/commands to trigger CONTROL-O rules.
CONTROL-B Utilities
CONTROL-B Database, Group and Variable File Handling Utilities
CTBDBCP Copies the contents of a specified source file to a specified target file.
All relevant aspects of the file are copied, including (pointers to)
variable definitions, variable generations, and group information.
CTBDBVCP Copies a specified variable or group of variables to another set of
variable/group files.
CTBDBVDL Deletes a variable or a group of variables from variable/group files.
CTBDBVIG Checks the integrity of variable/group data files.
CTBDBVCG Changes the number of generations of a Database variable.
CONTROL-M Utilities
Note Some utilities prefixed by IOA replace corresponding utilities prefixed by CTM from
earlier releases of CONTROL-M. In such cases, the CONTROL-M utilities remain
supported for your convenience; however, we recommend using the IOA utilities.
CTMAESIM Tests the syntax of AutoEdit control statements (described in
CTMBGRP Converts regular scheduling tables to Group scheduling tables
CTMBLDAE Builds an AutoEdit symbols member using an IOA calendar as input
CTMBLT Creates CONTROL-M scheduling tables (described in Section 6 of the
CTMCAJF Compresses, cleans or changes the size of the CONTROL-M Active
Jobs or History file (described later in this section).
CTMFRCKP Allocates and formats a CONTROL-M Active Jobs file (described later
in this section).
CTMFRJNL Allocates and formats the CONTROL-M Journal file (described later
in this section).
CTMJOB Orders jobs into the Active Jobs file (described in Section 6 of the
CTMJSA Accumulates job statistical data in the CONTROL-M Job Statistics file
CTMRCAL Creates a calendar for each job defined in CONTROL-M showing the
actual execution date(s) of the job (described in Section 6 of the
CTMRELRS Releases Quantitative resources from a job step (described in Section 6
of the CONTROL-M User Manual).
CTMRSTR Restores the Active Jobs File (described later in this section).
CTMSIM Activates the Simulation and Forecasting facility (described in
CTMTAPUL Produces a Tape Pull list (described in Section 7 of the CONTROL-M
User Manual).
CTMTBUPD Updates CONTROL-M group/job scheduling definition parameters in
batch mode (described in Section 6 of the CONTROL-M User Manual).
CTMXRF Produces a variety of cross reference reports (described in Section 6 of
the CONTROL-M User Manual).
CTDAMUTI Copies, moves and deletes CDAM files (described in Section 5 of the
CTDBLXRP Deletes and rebuilds all print control records.
CTDCAMF Compresses or changes the size of the Active Missions file.
CTDCATF Compresses or changes the size of the Active Transfer file.
CTDCA2P Copies new report/user entries from the Active User Report List file to
the Permanent User Report List file.
CTDCCU Identifies CDAM files not referenced by the Active User Report List
file and optionally deletes them.
CTDCLHIS Deletes entries in the History Reports List file and makes a list of
backup tapes which have expired based on parameter # OF
DAYS/GENERATIONS TO KEEP.
CTDCP2A Copies empty report/user entries from the Permanent User Report List
file to the Active User Report List file.
CTDDELRP Moves report entries from the Active to the Migrated and/or History
Report List file and erases their compressed datasets from DASD
storage.
CTDDIB Rebuilds a CONTROL-D User Report List file s index component.
CTDDIG Checks the integrity of Active, Permanent, History and Migration
User Report List files.
CTDFRCOM Allocates and formats a Communication file.
CTDSMFRP Produces a paper usage report (described in Section 6 of the
CTDULD Copies records from a sequential file to the current Active, Permanent,
History or Migrated User Report List file.
CTDUPBKP Updates backup information in User Report List files
(Active/Migrated/History/Permanent).
CTVCLMIG Cleans entries from the Migrated User Report List file and erases or
uncatalogs their CDAM datasets.
CTVDELI Deletes unneeded index files from disk based on user-specified
selection groups.
CTVJAR Consolidates reports that are created by Job Archiving.
CTVUNMIG Reads a migrated CDAM file and recreates the original CDAM file on
DASD.
IOA Access Method Utilities (for User Report List Files)
IOADBF Formats a CONTROL-D User Report List file s index or data
component.
IOADBSR Sorts and reorganizes CONTROL-D User Report List files data component.
IOADCPY Restores a CONTROL-D User Report List file from a dual mirror image copy.
IOADIG Verifies the integrity of a CONTROL-D User Report List file s data
component.
IOADII Verifies the integrity of a CONTROL-D User Report List file s index
component.
IOADLD Loads a CONTROL-D User Report List file s data or index component
from a sequential dataset.
IOADPT Prints a CONTROL-D User Report List file s data and index
component records in SNAP dump format.
IOADUL Unloads a CONTROL-D User Report List file s index or data
component to a sequential dataset.
CONTROL-O Utilities
CTOALOCP Backs up the Automation Log.
CTOCSF Copies the Message Statistics file.
CTOCTA Lists programs running in an address space.
CTOCTI Generates input for the COSMOS SYSIMAGE facility.
CTODBIB Rebuilds a CONTROL-O index file.
CTORSTM Produces reports on message statistics.
CTOTEST Simulates messages/commands to trigger CONTROL-O rules.
CONTROL-B Utilities
CONTROL-B Database, Group and Variable File Handling Utilities
CTBDBCP Copies the contents of a specified source file to a specified target file.
All relevant aspects of the file are copied, including (pointers to)
variable definitions, variable generations, and group information.
CTBDBVCP Copies a specified variable or group of variables to another set of
variable/group files.
CTBDBVDL Deletes a variable or a group of variables from variable/group files.
CTBDBVIG Checks the integrity of variable/group data files.
CTBDBVCG Changes the number of generations of a Database variable.
CONTROL-B Report and Rule Activity File Handling Utilities
CTBJAFCP Copies invocation and report entries to other Rule Activity and Report files.
CTBJAFDL Deletes unnecessary entries from the Rule Activity and Report files.
CTBJAFIG Checks the integrity of Rule Activity and Report data files.
CONTROL-B Active Balancing File Utilities
CTBABI Initializes the Active Balancing file after creation.
CTBFRM Compresses the Active Balancing file (usually on a daily basis as part
of the New Day procedure).
IOA Access Method File Utilities
CTBDBIB Rebuilds the indexes of specified CONTROL-B data files.
CTBDBST Replaced by utility IOADPT (see below).
IOADBF Allocates and formats an IOA Access Method files data or index
component.
IOADIG Verifies the integrity of an IOA Access Method files data component.
IOADII Verifies the integrity of an IOA Access Method files index component.
IOADPT Prints an IOA Access Method files data and index component records
in SNAP dump format.
IOADCPY Restores an IOA Access Method file from a dual mirror image copy.
Miscellaneous Utilities
CTBVXRF Produces a report indicating which variables are used by which rules,
(described in Section 8 of the CONTROL-B User Manual).
CONTROL-T Utilities
Trace Utilities
CTTACP Copies the Trace file.
CTTAFR Formats and initializes the Trace file.
CTTCTRC Allocates and formats the Trace file.
CTTRSM Recovers Tape Activity From SMF records.
CTTTRB Synchronizes the Trace file and the Media Database backup process.
Stacking Utilities
CTTGVL Provides a user interface to the Stacking facility.
CTTSBD Performs dataset stacking in batch mode.
CTTSCA Detects dataset contentions.
CTTSTK Builds and updates the Stacking Database.
CTTSTKR Generates Stacking Statistics reports.
Media Database Utilities
CTTBIX Rebuilds the index of the Media Database.
CTTDLD Adds non-scratch volumes, adds and deletes scratch volumes and
converts from other tape management systems.
CTTIDB Checks the integrity of the Media Database.
CTTMER Merges records from an extract file (created by utility CTTSPL) into
the Media Database.
CTTMUP Performs manual update of the CONTROL-T Repository.
CTTRCV Recovers Media Database contents using the Trace file.
CTTSPL Copies or moves (splits) specified records from the Media Database.
CTTSYNC Synchronizes the Robot Database and the Media Database.
CTTUDB Updates Media Database records from a transaction file created by
utility CTTIDB.
Daily Management Utilities
CTTRTM Performs retention management.
CTTVTM Performs vault management.
Database Handling Utilities (for the Media Database and Stacking
Database)
CTTCRDF Allocates and formats various data and/or index files.
CTTDBDLD Loads Media Database and Stacking Database data components from
a sequential dataset.
CTTDBDUL Unloads Media Database and Stacking Database components to a
sequential dataset.
CTTDBF Formats existing data and/or index files.
CTTDBIB Rebuilds the indexes of the Stacking Database.
CTTDBID Checks the integrity of a data file.
CTTDBII Checks the integrity of an index file.
CTTDBPRT Prints (in dump format) records from a database file to a sysout.
Miscellaneous CONTROL-T Utilities
CTTRPT Generates reports and from extracted Media Database information.
CTTTPI Initializes tapes, erases tapes and produces a detailed report of the
logical and physical contents of a volume.
IOA Utilities
IOABLCAL Build Calendars
The scheduling of jobs, missions and rules in the IOA environment is frequently based on
calendars. A data center may use different calendars for different scheduling
requirements.
Example
WORKDAYS All working days in the year
HOLIDAYS All non-standard holidays
ENDOFMON Business end-of-month scheduling
NOTEOFMN All working days except end-of-month days
In many cases, a calendar is related to, and can be derived from, another calendar or from
a combination of two other calendars. For example, in the calendars listed above, calendar
NOTEOFMN can be derived from a combination of the WORKDAYS and ENDOFMON
calendars.
When calendars are related, a change to one calendar frequently affects other calendars.
This can make manual maintenance of calendars time-consuming and error-prone. Utility
IOABLCAL simplifies and automates calendar maintenance.
Through parameters supplied to the utility, the user specifies two existing calendars and
the operation (or formula) which determines how the calendars are combined to build a
new calendar.
The new calendar created by the utility is a regular calendar. It can be viewed using
Option 8 (Calendars) of the IOA Primary Option menu and it can be used as an input
calendar in subsequent runs of the utility. Thus, using several basic calendars, numerous
other calendars can be created.
It is recommended that all steps which calculate calendars be collected into one job, and
that the job be run once a day. This will refresh the calendars in the event that changes
are made to the basic calendars.
Parameters
Parameters are supplied to the utility either via DD statement DABCLIN (or SYSIN) or
via PARM=. Any number of parameter statements can be specified. Parameter statement
syntax:
calendar1 operator calendar2 = calendar3
where:
calendar1, calendar2 Input calendars.
operator One of the following operators (described below):
+, , *, <W nn, >W nn, <>W, ><W
calendar3 Resulting calendar.
If the operation is +, calendar3 will contain all days scheduled in calendar1 and
additionally all days scheduled in calendar2.
If the operation is , calendar3 will contain all days scheduled in calendar1 excluding those
days scheduled in calendar2.
If the operation is *, calendar3 will contain all days scheduled in calendar1 which are also
scheduled in calendar2. The day has to be marked for execution in both calendars in order
to be marked for execution in calendar3.
If calendar2 is a relative calendar, additional logic is required to handle the * operation
mentioned above. (A relative calendar is a calendar which contains days marked + or - instead
of, or in addition to, days scheduled or not scheduled.) Each day in calendar2 which contains a +
or sign is checked against the same day in calendar1. If the day is marked for execution in
calendar1, it will be marked for execution in calendar3. However, if the day is not marked for
execution in calendar1, the result depends on how the day was marked in calendar2:
If the day was marked + in calendar2, the closest next day marked for execution in
calendar1 will be marked for execution in calendar3.
If the day was marked in calendar2, the closest previous day marked for execution in
calendar1 will be marked for execution in calendar3.
Operations <W nn and >W nn create a new calendar (calendar3) by shifting the days in an
old calendar (calendar1) a specified number of working days according to the specified
workdays calendar (calendar2):
Symbol < indicates that days should be shifted to the left (i.e., to preceding days).
Symbol > indicates that days should be shifted to the right (i.e., to subsequent days).
The number of working days to shift is nn.
The logic for operations <W nn and >W nn is as follows:
Each day marked for execution in calendar1 is checked against calendar2.
If the same day is a working day in calendar2, nn working days in calendar2 are counted in
the direction of the shift and the resulting day is marked as a working day in calendar3.
If the same day is not a working day in calendar2, the closest working day in the
direction of the shift is identified in calendar2. From that working day, nn working
days in calendar2 are counted in the direction of the shift and the resulting day is
marked as a working day in calendar3.
If operation <>W or ><W is specified, then for each working day (i.e., day marked for
execution) in calendar1:
If the same day is a working day in calendar2, it is marked as a working day in
calendar3.
If the same day is not a working day in calendar2, the closest working day (in either
direction) is marked as a working day in calendar3.
If two working days are equally close (i.e., the same number of days before and after),
the day selected depends on the parameter specified:
If <>W was specified, the earlier working day is selected as the working day for
calendar3.
If ><W was specified, the later working day is selected as the working day for
calendar3.
Note If specifying operator <W nn, >W nn, <>W, or ><W, calendars must be defined in year
order and must contain the same years.
Activating the Utility
// EXEC IOABLCAL
calendar1 operator calendar2 = calendar3
where:
operator is +, , *, <W nn, >W nn, <>W or ><W
Return Codes
0 Operation performed successfully
8 and above Operation failed
Example 1
The following parameter is passed to the utility:
calendar1 * calendar2 = calendar3
Assuming the following calendars:
S ----------- S ----------- S -------
1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 calendar1
Y Y Y Y Y Y Y Y Y Y Y Y
S ----------- S ----------- S -------
and
S ----------- S ----------- S -------
1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 calendar2
Y Y + - + + -
S ----------- S ----------- S -------
The resulting new calendar is:
S ----------- S ----------- S -------
1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9 calendar3
Y Y Y Y Y Y Y
S ----------- S ----------- S -------
Note the following points in this example:
Since the operation is *, days 2 and 3, which are marked for execution in both
calendar1 and calendar2, will be marked for execution in calendar3.
Day 4 is marked + in calendar2 and is marked for execution in calendar1. Therefore, it
will be marked for execution in calendar3.
Day 5 is marked in calendar2 and is marked for execution in calendar1. Therefore, it
Day 6 is not marked in calendar2. Therefore, even though it is scheduled in calendar1,
it will not be marked for execution in calendar3. This same reasoning applies to days 8,
9, 10, 11, 12, 13 and 19. However, days 8, 13 and 19 are marked for execution for other
reasons described below.
Day 7 is marked + in calendar2 and is not marked for execution in calendar1. The
closest following day marked for execution in calendar1 is day 8. Therefore, day 8 will
be marked for execution in calendar3.
Day 14 is marked + in calendar2 and is not marked for execution in calendar1. The
closest following day marked for execution in calendar1 is day 19. Therefore, day 19
Day 16 is marked in calendar2 and is not marked for execution in calendar1. The
closest preceding day marked for execution in calendar1 is day 13. Therefore, day 13
Example 2
OLDCAL <W 2 WORKDAYS = NEWCAL
S - - - - - - S - - - - - - S - - - -
1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9
Y Y Y Y Y OLDCAL
S - - - - - - S - - - - - - S - - - -
and
S - - - - - - S - - - - - - S - - - -
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 WORKDAYS
S - - - - - - S - - - - - - S - - - -
S - - - - - - S - - - - - - S - - - -
1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9
Y Y Y Y Y NEWCAL
S - - - - - - S - - - - - - S - - - -
Operation <W 2 specifies that for each working day in OLDCAL, utility IOABLCAL
should find the corresponding working day in WORKDAYS, and then shift two
workdays to the left.
The first workday in OLDCAL is day 5. This is also a workday in WORKDAYS. The 2nd
workday to the left of day 5 in WORKDAYS is day 3, which becomes a workday in
NEWCAL.
The next workday in OLDCAL is day 10. This is also a workday in WORKDAYS. The
2nd workday to the left of day 10 in WORKDAYS is day 6, which becomes a workday in
NEWCAL.
2nd workday to the left of day 11 in WORKDAYS is day 7, which becomes a workday in
NEWCAL.
2nd workday to the left of day 12 in WORKDAYS is day 10, which becomes a workday
in NEWCAL.
The next workday in OLDCAL is day 15. This is not a workday in WORKDAYS. The
closest workday to the left, in WORKDAYS, is day 13. The 2nd workday to the left of
day 13 in WORKDAYS is day 11, which becomes a workday in NEWCAL.
Example 3
OLDCAL ><W WORKDAYS = NEWCAL
S - - - - - - S - - - - - - S - - - -
1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9
Y Y Y Y Y OLDCAL
S - - - - - - S - - - - - - S - - - -
and
S - - - - - - S - - - - - - S - - - -
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 WORKDAYS
S - - - - - - S - - - - - - S - - - -
S - - - - - - S - - - - - - S - - - -
1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9
Y Y Y Y Y NEWCAL
S - - - - - - S - - - - - - S - - - -
Operation ><W specifies that for each working day in OLDCAL, utility IOABLCAL
should find the closest working day in WORKDAYS, and make that day a workday in
NEWCAL.
The first workday in OLDCAL is day 5. This is also a workday in WORKDAYS, so it
becomes a workday in NEWCAL.
The next workday in OLDCAL is day 8. This is not a workday in WORKDAYS. The next
closest workday in WORKDAYS is day 7, so day 7 becomes a workday in NEWCAL.
closest workday in WORKDAYS is day 10, so day 10 becomes a workday in NEWCAL.
The next workday in OLDCAL is day 12. This is also a workday in WORKDAYS, so it
becomes a workday in NEWCAL.
closest workdays in WORKDAYS are days 13 and 17 (which are equally close to day 15).
Since the parameter operation statement ><W began with symbol >, the value to the right
(i.e., the subsequent day) is chosen. Therefore, day 17 becomes a workday in NEWCAL.
IOACLRES Clean IOA Conditions/Resources File
This utility cleans the IOA Conditions/Resources file of conditions which are no longer
required. It is recommended that this utility be activated as part of IOA maintenance.
Note If the IOA Conditions/Resources file is shared across multiple CPUs, use an enqueue
manager (such as MIM or GRS) to prevent simultaneous update of the file. See the
description of parameters QNAME and SHRQNAM in Section 2 of the IOA
Installation Guide for more information.
Parameters
Unless the utility is instructed otherwise via parameters, it will delete all prerequisite
conditions (except those whose date reference is STAT) in the IOA Conditions/Resources
file.
The utility outputs a list of all the deleted prerequisite conditions.
Prerequisite conditions which should not be deleted (e.g., prerequisite conditions needed
throughout the year) are specified by means of control statements, which are specified via
DD statement DACRSIN or SYSIN. The formats of these statements are displayed below,
followed by explanations:
1
1
]
1
'
1
1
]
1
'
'
'
n -
date
TO
n -
date
FROM
*
prefix - cond

CONDIN
COND
IGNORE
{ }
CONTROLM
YES
NO

{ }
CONTROLD
YES
NO

IGNORE statements instruct the utility not to delete the indicated prerequisite
condition(s), as follows:
An IGNORE COND statement instructs the utility not to delete the indicated
prerequisite condition under any circumstances.
An IGNORE CONDIN statement instructs the utility not to delete the indicated
prerequisite conditions if the utility determines that the prerequisite conditions are
referenced conditions. A referenced condition is a prerequisite condition appearing in
the IOA Conditions/Resources file at the same time that it appears as an IN condition
in an active job, mission or rule (e.g., one which is currently present in the Active Jobs
file or Active Missions file).
cond-prefix specifies the prefix of prerequisite conditions which should not be deleted.
An asterisk indicates all prerequisite conditions.
If a FROM/TO combination is supplied, a specified condition will not be deleted if its
date is in the date range. Conditions not in the date range will be deleted, unless they
are referred to by another IGNORE statement.
date can be either a specific date in the site-defined standard (mmddyy, ddmmyy or
yymmdd) or a relative date. A relative date is specified in the format n, where n is the
number of days before the current date (e.g., 5 means five days before the current
date). Relative and specific dates can be mixed (e.g., a specific FROM date and a
relative TO date).
When a FROM and/or TO date is not specified, the current date is the default for the
unspecified date. The TO date (regardless of whether specific, relative or assumed) cannot
precede the FROM date.
Note Prerequisite conditions whose date reference is STAT are ignored by this utility.
CONTROLM and CONTROLD statements indicate whether or not the utility should check
prerequisite conditions in the Active Jobs file and/or the Active Missions file, respectively,
if an IGNORE CONDIN statement is specified. By default, each of these files is checked if
its respective product is installed (according to IOA Installation options). These statements
can be used to override the default. You can specify either, both or neither of these
statements.
These statements can impact the result of an IGNORE CONDIN statement because the
utility cannot determine that a prerequisite condition is referenced unless it can check the
Active Jobs/Missions file for the job/mission containing the IN prerequisite condition.
Valid values for these statements are described below:
CONTROLM Determines whether or not the CONTROL-M Active Jobs file is
checked during the cleanup process of the IOA Conditions/Resources
file. Optional.
YES Check the Active Jobs file. Default (if CONTROL-M is
installed).
NO Do not check the Active Jobs file. Default (if
CONTROL-M is installed).
CONTROLD Determines whether or not the CONTROL-D Active Missions file is
checked during the cleanup process of the IOA Conditions/Resources
file. Optional.
YES Check the Active Missions file.
NO Do not check the Active Missions file.
The utility can be run simultaneously with the CONTROL-M and the CONTROL-D
monitors.
If the job is submitted under CONTROL-M, AutoEdit variables are supported.
// EXEC IOACLRES
Specifying AutoEdit Variables and Functions
AutoEdit variables can be specified for any of the above parameters. These variables are
especially useful for specifying relative date ranges in the FROM and TO parameters.
AutoEdit functions can be used to set variables and these variables can then be used in the
parameters of the utility. The lines in which the variables are set must have an asterisk (*)
in the first column of the line. Such lines are resolved by the AutoEdit facility and are
interpreted as comments by the utility. Regular comments can also be specified in lines
with an asterisk in the first column.
Example
* IGNORE MEMBERS PREFIXED WITH BR14 WHICH WERE ORDERED
* WITHIN THE LAST THREE DAYS.
* %%SET %%F = %%CALCDATE %%DATE -3
IGNORE MEMBER BR14*
FROM %%F
Note The following AutoEdit terms cannot be used in the input for this utility:
%%ODATE, %%OYEAR, %%OMONTH, %%ODAY, %%OWDAY, %%INCLIB and
%%INCMEM.
Return Codes
0 Operation performed successfully.
4 Execution error, operation stopped.
8 and above Critical error, task not performed.
Example 1
It is recommended that you run this job weekly. Since this job contains AutoEdit variables,
it must be submitted directly via the CONTROL-M monitor. (The example assumes date
standard mmddyy. For ddmmyy format, the AutoEdit variable should be
%%ODAY.%%OMONTH.%%OYEAR. For yymmdd format, the AutoEdit variable should be
%%OYEAR.%%OMONTH.%%ODAY.)
// EXEC IOACLRES
IGNORE COND * FROM -10 TO %%OMONTH.%%ODAY.%%OYEAR
IGNORE COND CICS
IGNORE COND DB-
Example 2
Clean the resources file of all prerequisite conditions not referenced by jobs in the Active
Jobs file, except those prerequisite conditions beginning with CICS. (Prerequisite
conditions beginning with CICS are not deleted.) Do not check the Active Missions file to
see if a prerequisite condition is referenced.
// EXEC IOACLRES
IGNORE CONDIN * CONTROLD NO
IGNORE COND CICS
IOACND Perform IOA Condition/Resource Adjustments
This utility adds, verifies the existence of, deletes, or modifies prerequisite conditions and
resources in the IOA Conditions/Resources file. It can be activated by the operator as a
started task (STC), from TSO, or from within a user program.
The addition, deletion, modification or verification is recorded three ways: in the job
sysout, as a message on the operator console and as an event in the IOA Log file.
Parameters can be received by the utility in two ways: via DD statement DACNDIN (or
SYSIN), or via PARM. The parameters required depend on whether prerequisite
conditions, control resources or quantitative resources are being processed. If an input
parameter file is specified, its blocksize should not exceed 8000.
If it is necessary to add, delete, verify or modify prerequisite conditions or resources during a
job step, the utility can be called as a procedure from within the application program using
procedure name CTMCND, as described below in Activating the Utility (and Examples).
Note If the IOA Conditions/Resources file is shared across multiple CPUs, use an enqueue
manager (such as MIM or GRS) to prevent simultaneous update of the file. See the
description of parameters QNAME and SHRQNAM in Section 2 of the IOA
Parameters for Processing Prerequisite Conditions
action COND condition condition-date
where:
action Action to be performed by the utility. Valid values:
ADD Add the specified prerequisite condition.
DELETE Delete the specified prerequisite condition.
CHECK Verify the existence of the specified prerequisite
condition.
condition 1-20 character prerequisite condition.
condition-date Date associated with the prerequisite condition. Valid values:
mmdd, ddmm Any specific date (in format mmdd or ddmm, depending
on the site standard).
DATE Current Gregorian date.
WDATE IOA working date.
STAT Static. Indicates that the condition (e.g., IMS-ACTIVE)
is not date-dependent.
Date character-masking for DELETE and CHECK functions is supported as follows:
* Represents any value in the corresponding position of the
date (format mmdd or ddmm depending on the site standard).
Up to four asterisks can be specified. For example:
**** Any date.
*2*2 Valid combinations of:
Months: February and December
Days: 02, 12 and 22
Parameters for Processing Control Resources
action CONTROL resource control
where:
action Action to be performed by the utility. Valid values:
ADD Add the specified Control resource under the specified
type of control.
DELETE Delete the specified resource which is under the
specified type of control.
resource Resource name.
control Type of control. Valid values:
E Exclusive control.
S Shared control.
Parameters for Processing Quantitative Resources
action RESOURCE resource quantity
where:
action Action to be performed by the utility. Valid actions:
ADD Add the specified Quantitative resource with the
quantity specified. quantity is mandatory.
DELETE Delete the resource (and the entire existing quantity).
quantity must not be specified.
CHANGE Adjust the existing quantity of the Quantitative
resource to or by the value specified in quantity.
quantity is mandatory.
resource Quantitative resource name.
quantity Quantity of the Quantitative resource.
For CHANGE actions, valid values can have the format n, +n, or n
where n is an integer. When n is specified, the quantity of the
Quantitative resource is set to n. When +n or n is specified, the
quantity is increased or decreased by n.
For ADD actions, valid values can only have the format n, where n is the
quantity of the Quantitative resource to be added.
Activating the Utility (and Examples)
As a job step:
//CND1 EXEC IOACND
ADD COND JOB-A-ENDED-OL 0505
DELETE COND JOB-A-DID-NOT-RUN 0505
CHANGE RESOURCE TAPE -1
ADD RESOURCE INIT-CPUA 3
DELETE RESOURCE INIT-CPUB
ADD CONTROL PROD-DATA-BASE E
As a job containing AutoEdit variables, submitted through the CONTROL-M monitor:
//CND1 EXEC IOACND
ADD COND AR-FILE-009-CREATED %%OMONTH.%%ODAY
As an operator command:
S IOACND,PARM=ADD COND END-CICS 0102
As a called procedure in an application program:
CALL CTMCND,(PARMCOND),VL
LTR R15,R15
BNZ ERROR
...
PARMCOND DC AL2(80)
DC CL80ADD COND CICS-FILE-CLOSED 0102
Note Program IOACND works in 24-bit addressing mode and is reusable (but not
re-entrant).
Return Codes
ADD 0 Prerequisite condition or resource added.
8 Prerequisite condition or resource already exists.
12 and above Function failed.
DELETE 0 Prerequisite condition deleted.
8 Prerequisite condition or resource to be deleted does not
exist.
12 and above Function failed
CHECK 0 Prerequisite condition exists
8 Prerequisite condition or resource does not exist
CHANGE 0 Quantity of Quantitative resource adjusted successfully
8 Quantitative resource does not exist
Note If you are working in a VM/CMS environment, utility IOAVCND can be used to set
prerequisite conditions in a CONTROL-M monitor running on an NJE-connected MVS
machine.
The EXEC statement for utility IOAVCND utilizes standard IOACND input and sends
a job to the MVS node to set the conditions.
Example
EXEC IOAVCND ADD COND VM-READY STAT
IOACOPRS Copy/Resize IOA Conditions/Resources File
This utility copies the contents of the IOA Conditions/Resources file to another
Conditions/Resources file which may or may not be the same size or version.
Copying/Resizing the IOA Conditions/Resources File
Note Utility IOACOPRS cannot run simultaneously with the IOA product monitors (e.g.,
CONTROL-M monitor). If the monitors are not shut down, the utility will terminate.
Online users can remain logged on, but should not access the Online facility while the
size of the IOA Conditions/Resources file is being changed.
To change the size of the IOA Conditions/Resources file, perform the following steps:
1. Change IOA installation parameters RESLREC and RESREC# in member IOAPARM to
the required new IOA Conditions/Resources file size.
2. Reassemble member IOAPARM using job IOAPARMJ.
3. After doing this, every access to the IOA Conditions/Resources file (online or batch) will
try to utilize the new size and may abend. Therefore, all access to the IOA
Conditions/Resources file should be stopped until the process is complete.
4. Change parameter LRECL and RECNUM in procedure IOAFFRES to the new size of
the IOA Conditions/Resources file.
5. Run member FORMRES in the IOA INSTALL library after changing the dataset names
(so you will not override the existing IOA Conditions/Resources file and its backup file).
If you are working in dual checkpoint mode, run member FORMDRES.
Note If you are working in dual checkpoint mode, the mirror file must also be allocated
with the new size before starting the IOA product monitors (e.g., the CONTROL-M
monitor). Otherwise, the monitors may abend.
6. Run utility IOACOPRS.
The utility will copy the current IOA Conditions/Resources file to the new IOA
7. Rename the old IOA Conditions/Resources file (and its mirror file suffix ALTRES).
8. Rename the new IOA Conditions/Resources file (and its mirror file suffix ALTRES) to
the former names of the old files.
9. Restart the IOA product monitors and resume operation.
The utility must terminate with a return code of 0.
Parameters
The utility receives parameters via the invocation of the procedure.
OLDRES Name of the old IOA Conditions/Resources file.
OLDSNC Name of the old IOA Conditions/Resources Synchronization file.
NEWRES Name of the new IOA Conditions/Resources file.
NEWSNC Name of the new IOA Conditions/Resources Synchronization file.
Return Codes
8 and above Operation failed
Activating the Utility (and Example)
// EXEC IOACOPRS,
// OLDRES=IOA.old.RES, OLD CONDITIONS/RESOURCES
// OLDSNC=IOA.old.SNC, OLD CONDITIONS/RESOURCES
//* SYNCHRONIZATION FILE
// NEWRES=IOA.new.NEWRES, NEW CONDITIONS/RESOURCES
//* FILE
// NEWSNC=IOA.new.NEWSNC NEW CONDITIONS/RESOURCES
//* SYNCHRONIZATION FILE
IOACPLOG Copy the IOA Log File
Utility IOACPLOG copies the contents of the IOA Log file. The contents can be copied to a
sequential file or to another Log file. Usage of the utility depends on the type of target file.
Copying to a Sequential File
The log is generally copied to a sequential file for archiving. The sequential file can be
restored for access under ISPF (e.g., browsing) and for use by report generators.
A date range for the log records to be copied can be specified. If a date range is not
specified, the entire Log file is copied.
The target sequential file is referenced by in DD statement DALOGSEQ. The existing Log
file is reinforced by DD statement DELOGCUR.
It is recommended that the utility be used on a daily basis to copy the contents of the Log
file to a sequential file. Use of AutoEdit parameters can simplify the process.
Parameters
Parameters are supplied via DD statement DALCPPRM (or SYSIN).
COPYTOSEQ Indicates that the utility is being used to copy records from the IOA
Log file to a sequential file.
FROMDATE yymmdd Date of the earliest Log record to be copied. AutoEdit variable are
supported.
TODATE yymmdd Date of the latest Log record to be copied. AutoEdit variable are
supported.
//* %%SET %%D = %%CALCDATE %%ODATE -1
// EXEC IOACPLOG
//DALOGSEQ DD DSN=prefix.seqfile,DISP=... Target sequential file
//DALCPPRM DD *
COPYTOSEQ
FROMDATE %%D
TODATE %%D
//
Return Codes
Other Operation failed
Copying to a Log File
This function is generally used to copy one Log file to another. The target Log file can be
larger or smaller than the source Log file. If the target Log file is smaller, the oldest
records in the source Log file may be deleted.
The target Log file is referenced by DD statement DALOG.
Parameters
One parameter is supplied via DD statement DALCPPRM (or SYSIN).The existing Log file
is reinforced by DD statement DELOGCUR.
COPYTOLOG Indicates that the utility is being used to copy the IOA Log file to
another Log file.
// EXEC IOACPLOG
//DALOG DD DSN=prefix.logfile,DISP=... Target Log file
//DALCPPRM DD *
COPYTOLOG
//
Return Codes
Other Operation failed
IOADBF Allocate/Format an IOA Access Method File
Utility IOADBF is used to allocate and format an IOA Access Method files data and index
components. IOA Access Method files can be allocated by utility IOADBF according to
parameters specified in the DEFxxx/DEFxxxI members of the IOA library.
Parameters
The following parameters can be specified to the utility in the EXEC statement which
invokes the IOADBF JCL procedure:
FUNC Function to be performed:
INIT Allocates and initializes (formats) a new IOA Access
Method file component.
FORM Reformats an existing IOA Access Method file
component.
EXTEND Allocates and formats a new secondary extent for an
existing IOA Access Method file component.
CHANGE Changes/Updates an IOA Access Method file
components internal attribute settings. This function
should be used when it is necessary to change the
settings of parameters in an IOA Access Method file
definition after the file has been created.
DUALOK Resets the flag that indicated a corrupted Dual Mirror
Image file (DUALBAD). This function should be used
after a corrupted Dual Mirror Image file has been
restored via utility IOADCPY.
D Dataset name suffix of the IOA library containing the IOA Access
Method file Definition Statements member. The member name is
specified via parameter M below.
M Name of the IOA library member which contains the IOA Access
Method file Definition Statements and whose dataset name suffix is
specified via parameter D above.
DD Statement DAFILE
When executing utility IOADBF with parameter FUNC set to EXTEND or CHANGE, a
DAFILE DD statement, specifying the name of the IOA Access Method file components
primary dataset extent, must be included in the JCL step executing the utility.
IOA Access Method File Definition Parameters
The following IOA Access Method file definition parameters can be specified as input to
utility IOADBF in the IOA library and member referred to above by EXEC statement
parameters D and M:
TYPE IOA Access Method file type:
F Data component, fixed record format.
V Data component, variable record format. This value is not
valid for use with CONTROL-B files.
I Index component.
The TYPE parameter is not applicable when executing utility IOADBF
with the FORM or CHANGE function specified.
PRODUCT Product which uses the file to be allocated/formatted. Valid values:
D CONTROL-D or CONTROL-V.
B CONTROL-B.
O CONTROL-O.
DSN IOA Access Method files dataset name, excluding the extent number
suffix (.E000 through .E255) which is appended automatically by the
utility when the IOA Access Method file is allocated.
The DSN parameter is not applicable when executing utility IOADBF
with the INIT, FORM or CHANGE function specified.
UNIT Name of the DASD unit to be used when allocating a new IOA Access
Method file extent (e.g., 3390).
VOL List of one to six DASD volume serial numbers, enclosed in
parenthesis and separated by commas, on which the IOA Access
Method files extents can be allocated.
All volumes must be defined to MVS as being associated with the unit
name specified in parameter UNIT above.
To obtain SMS support for IOA Access Method files, omit parameter
VOL and specify the UNIT parameter for the SMS space area in the
DEFxxx members. SMS will allocate all the IOA Access Method
extents according to SMS rules.
If an out-of-space condition occurs due to lack of space in the specified
volumes, additional volumes can be added. (A maximum of six volumes
is permitted.) Utility IOADBF should be executed with EXEC
parameter FUNC=CHANGE (this stores the new setting internally
within the IOA Access Method file) and then the CONTROL-D or
CONTROL-O monitor should be restarted.
If VOL is not specified, the IOA Access Method file will be allocated
using only parameter UNIT.
UNITD Name of the DASD unit to be used when allocating a new dual mirror
image file extent (e.g., 3390).
VOLD List of one to six DASD volume serial numbers, enclosed in
parenthesis and separated by commas, on which the dual mirror
image files extents can be allocated.
name specified in parameter UNITD above.
To obtain SMS support for IOA Access Method files, omit parameter
VOLD and specify the UNIT parameter for the SMS space area in the
DEFxxx members. SMS will allocate all the IOA Access Method
extents according to SMS rules.
Note Specify different volumes for the primary and dual mirror copy of
each file to ensure greater data integrity. See parameter VOL
above.
SPACE Amount of space, in blocks, to be allocated for the primary and,
optionally, for each secondary IOA Access Method file extent.
Note Secondary extents cannot be specified for CONTROL-B files.
It is recommended that a secondary space amount be specified to avoid
termination of the CONTROL-D or CONTROL-O monitor when the
primary extent becomes full and an out-of-space condition is detected.
If an out-of-space condition occurs, secondary extent allocations can be
set by specifying a secondary amount in parameter SPACE, executing
utility IOADBF with EXEC parameter FUNC=CHANGE (this stores
the new setting internally within the IOA Access Method file) and
restarting the CONTROL-D or CONTROL-O monitor.
For more information about secondary extents, see Multiple Extents
below.
Example 1
SPACE=(1500) A 1500-block IOA Access Method file is allocated.
If the file becomes full, the CONTROL-B rule will
terminate.
Example 2
SPACE=(1500,300) A 1500-block IOA Access Method file is allocated.
If the file becomes full and a secondary extent is
automatically or manually allocated (see IOA
Access Method file Definition parameter
EXTEND), each newly-allocated extent will be
300 blocks in size.
Parameter SPACEs primary space amount is not applicable when
executing utility IOADBF with the FORM or CHANGE function specified.
DUAL Y (Yes) Allocate a dual mirror image copy of the specified
file. The dual mirror image files contents are kept
synchronized with the contents of the primary
file. Use of the dual mirror image file provides
maximum data recovery capabilities when the
primary files disk or contents become damaged or
inaccessible. Specifying DUAL=Y is recommended
for the Data component file.
N (No) Do not allocate a dual mirror image copy of the
specified file.
DUALM Y (Yes) If dual mirror image file processing is used,
execution terminates if a non-recoverable I/O
error occurs while processing the dual mirror
image copy of the file.
N (No) If dual mirror image file processing is used,
execution continues if a non-recoverable I/O error
occurs during processing of the dual mirror image
copy of the file.
DUALST Y (Yes) Timestamp checkpoint processing is performed
internally to ensure that the primary and dual
mirror image copies of the file are fully
synchronized. Enabling this option insures
greater data integrity at the expense of increasing
I/O processing overhead.
N (No) Timestamp checkpoint processing is not
performed.
See Planning and Space Calculation in Section 5 of the IOA
EXTEND Specifies secondary extent to be allocated. This parameter cannot be
used for use with CONTROL-B files.
Specifying A (the default) causes a secondary extent to be
automatically allocated when an out-of-space condition is detected.
Specifying M requires a secondary extent to be manually allocated
after an out-of-space condition is detected by executing the utility with
EXEC parameter FUNC=EXTEND.
Parameter EXTEND is ignored if no secondary space amount is
specified via parameter SPACE.
Parameter EXTEND is not applicable when executing utility IOADBF
BLKSIZE Block size of the IOA Access Method file, in bytes. For all index components
and for data components with variable length records, it is recommended
that the block size be set to the maximum half track capacity of the device
on which the IOA Access Method file is allocated, as follows:
BLKSIZE=19068 For 3350 DASD devices.
For data components with fixed length records, where the block size
must be a multiple of the record length, it is recommended that the
block size be set as close to, without exceeding, the devices half track
capacity.
Parameter BLKSIZE is not applicable when executing utility IOADBF
BUFL Number of I/O buffers for which extended storage will be obtained to
access the IOA Access Method file.
Note This parameter cannot be used with CONTROL-B files.
Buffer length is determined by parameter BLKSIZE, described above.
A larger number improves I/O throughput at the expense of increased
storage requirements. A smaller number reduces storage requirements
at the expense of degrading I/O throughput.
LRECL Logical record length for IOA Access Method file data components
only. This parameter should not be specified for index components.
The setting for parameter LRECL is IOA application dependent and
should not be modified unless instructed otherwise by Technical
Support.
Parameter LRECL is not applicable when executing utility IOADBF
KEYLEN Record key length for IOA Access Method file index components only.
This parameter should not be specified for data components.
Parameter KEYLEN is not applicable when executing utility IOADBF
with the CHANGE function specified.
The setting for KEYLEN is IOA application dependent and should not
be modified unless instructed otherwise by Technical Support.
COMPRS Name of the IOA supplied routine to perform Data component record
compression. This parameter should not be specified for index
components.
The setting for COMPRS is IOA application dependent and should not
COMPTB Name of the IOA supplied compression table to be used by the
compression routine when performing data component record
compression. Do not specify this parameter for index components.
Notes If parameter COMPRS is specified, parameter COMPTB must
also be specified.
Parameters COMPRS and COMPTB are not available when
executing utility IOADBF with the FORM or CHANGE function
specified.
Parameters COMPRS and COMPTB are not available when
executing utility IOADBF on a CONTROL-B or CONTROL-O
file.
The setting for COMPTB is IOA application dependent and should not
Example 1
//INIT EXEC IOADBF,FUNC=INIT,D=INSTCTD,M=DEFACT
Contents of member DEFACT in the IOA INSTCTD library:
TYPE=V
DSN=CTD.V514.ACT
BLKSIZE=27998
LRECL=27974
SPACE=(1000,200)
BUFL=100
UNIT=3390
VOL=(PRD021,PRD022,PRD023,PRD024,PRD025,PRD026)
COMPRS=CTDUFCM
COMPTB=CTDUFCMA
Example 2
//CHANGE EXEC IOADBF,FUNC=CHANGE,D=INSTCTD,M=DEFHSTI
//DAFILE DD DISP=SHR,DSN=CTD.V514.HSTI.E000
Example 3
To change the qname of a file from the current dataset qname to the default qname of the
environment under which the utility is run, append (BYPASS) to the DSN specified in DD
statement DAFILE.
//*** RESET QNAME OF CTB.V504.GRPD.E000 TO DEFAULT ENV. QNAME
//GRP EXEC IOADBF,FUNC=CHANGE,D=INSTCTB,M=DEFGRPD,ILPREFA=IOA.V504
//DAFILE DD DISP=SHR,DSN=CTB.V504.GRPD.E000(BYPASS)
Multiple Extents
CONTROL-Ds IOA Access Method files can contain multiple extents. Each extent is a
separate sequential file which contains a maximum of 65534 blocks and is allocated
without a secondary space allocation.
If a CONTROL-D IOA Access Method file should have more than 65534 blocks, specify a
space parameter, such as SPACE=(65534,30000). In this case, the IOA Access Method will
allocate a first extent of 65,534 blocks and a second extent of 30,000 blocks as separate
MVS sequential files. However, the IOA Access Method will treat the two files as one file
with two extents. The new extent will be allocated when records are written to the file if
the first extent does not have sufficient free space for the new records.
The maximum size for secondary extents is also 65534 blocks. The IOA Access Method
supports a maximum of 256 extents.
Using Utility IOADPT for Space Management
Run utility IOADPT with FUNC=DB0 to display information about the space remaining in
an IOA Access Method file. This information enables you to manage space allocations and
provide extra extents before they are created by CONTROL-D. Utility IOADPT can be
activated as follows:
//AMSPACE EXEC IOADPT,FUNC=DB0,DBFILE=ACT
For details and examples, see the documentation for utility IOADPT later in this section.
CONTROL-D Samples
Refer to sample jobs FORMUF1 and FORMUF2 in the IOA INSTCTD library for examples
of how to allocate and format IOA Access Method files.
CONTROL-B Samples
Utility IOADBF is used by the following jobs in the INSTCTB library. Refer to these jobs
for additional examples.
CREFABF Allocates and formats the Active Balancing file.
CREFBKP Allocates and formats the Active Balancing file backup file.
CREFDBM Allocates and formats the Database Variable Basic file.
CREFDBV Allocates and formats the Database Variable Generation file.
CREFGRP Allocates and formats the Group file.
CREFJAF Allocates and formats the Rule Activity file.
CREFREP Allocates and formats the Report file.
CONVABF Converts the CONTROL-B Active Balancing file from Release 1.2.0 to
the format for Release 5.0.0.
CONVGRP Converts the CONTROL-B Group file from Release 1.2.0 to the format
for Release 5.0.0.
CONVJAF Converts the CONTROL-B Rule Activity file from Release 1.2.0 to the
format for Release 5.0.0.
CONVMOD Converts the CONTROL-B Database Variable Basic file from Release
1.2.0 to the format for Release 5.0.0.
CONVREP Converts the CONTROL-B Report file from Release 1.2.0 to the format
for Release 5.0.0.
CONVVAR Converts the CONTROL-B Database Variable Generation file from
Release 1.2.0 to the format for Release 5.0.0.
The following jobs can be used as samples for formatting existing data and index files:
JOBFABF Active Balancing file.
JOBFGRP Group file.
JOBFMOD IOA Access Method Variable Basic file.
JOBFVAR IOA Access Method Variable Generation file.
JOBFBKP Backup file.
JOBFJAF Rule Activity file.
JOBFREP Report file.
The following jobs can be used as samples for formatting and rebuilding the index file for
an existing data file:
JOBBGRP Group file.
JOBBBDM Access Method Variable Basic file.
JOBBDBV Access Method Variable Generation file.
JOBBJAF Rule Activity file.
JOBBREP Report file.
For example, if the index file of the Rule Activity file was damaged by a disk crash but the
data file was not damaged (i.e., the actual information about invocations, etc., is accurate),
use member JOBBJAF to reformat the index file and rebuild the index entries.
CONTROL-O Samples
Utility IOADBF is used by the following jobs in the CONTROL-O JCL library:
CTODBSBF Allocates and formats the CONTROL-O Variable Database Definition
file.
CTOCOLBF Allocates and formats the CONTROL-O Variable Database Column
file.
CTOVARBF Allocates and formats the CONTROL-O Variable Database Variables
file.
IOADBSR Sort Records in an IOA Access Method Data
Component
Utility IOADBSR sorts the records in an IOA Access Method files data component in the
same logical order as the records in the associated IOA Access Method files index
component.
Sorting an IOA Access Method files data component improves I/O performance.
Note The CONTROL-D Active User Report List files data component can optionally be
sorted automatically by the CONTROL-D monitor. See Dynamic Sorting of the Active
User Report List File in Section 4 of this guide for more information.
Parameters
invokes the IOADBSR JCL procedure:
DBPREFA High level dataset name qualifier (prefix) of the IOA Access Method
file.
DBFILE IOA Access Method files dataset name suffix.
PARMLIB The last qualifier of the IOA product library containing the input Sort
Control statements.
M Member name in the IOA product dataset containing the input Sort
Control statements.
Sort Control Parameters
The following Sort Control parameters can be specified for dynamic sorting. Parameters
that are not applicable to batch sorting with utility IOADBSR are indicated as such.
ENABLE Whether or not dynamic sort processing should be disabled. This
parameter is ignored by utility IOADBSR.
Y (Yes) Enable dynamic sort processing.
N (No) Disable dynamic sort processing.
TIMEFROM Earliest time of day, in hhmm format, at which time dynamic sort
processing can be performed. This parameter is ignored by utility
IOADBSR.
TIMETO Latest time of day, in hhmm format, at which time dynamic sort
processing can be performed. This parameter is ignored by utility
IOADBSR.
RBAOFS Offset location within an index record of a four-byte field containing
the address of the associated data record.
This parameter is for internal use only and should not be modified
unless instructed otherwise by Technical Support.
INTERVAL Interval, in hhmm format, at which dynamic sort processing will
automatically start during the time range specified by parameters
TIMEFROM and TIMETO. This parameter is ignored by utility
IOADBSR.
DELYBLK Amount of time, as a four-digit value in hundredths of seconds, that
dynamic sort processing will wait before processing a new block. For
example, a value of 0001, 0010 or 0100 will set the delay time to one
hundredth, one tenth or one full second, respectively.
START-WHEN-OVER
Limit of different Database file data component blocks referred to by
all index records within any single index component block that will
automatically trigger dynamic sort processing.
This parameter is for internal use only and should not be modified
unless instructed otherwise by Technical Support.
STOP-WHEN-OVER
Maximum number of different data component blocks that can be
referred to by all index records within any single index component
block when dynamically sorting the index component block.
Parameter STOP-WHEN-OVER is for internal use only and should not
Example
// EXEC IOADBSR,DBPREFA=CTD,
// DBFILE=ACT,
// PARMLIB=CTD.PROD.PARM,
// M=DBSRTPRM
Refer to sample job CTDUFSR in the CONTROL-D JCL library for an example of how to
sort the data component of the CONTROL-D History User Report list.
IOADCPY Recover an IOA Access Method File
Utility IOADCPY is used to recover an IOA Access Method file from the dual mirror image
copy and vice versa.
If an IOA Access Method file is used with dual file support and either the working copy or
the dual mirror image copy is corrupted or becomes unavailable, the damaged or missing
file must be recovered. Utility IOADCPY restores the damaged or missing copy of the file
from the copy that is still intact and available (including all file extents). If the dual copy is
corrupted, the utility also resets the parameter in the control block of the IOA Access
Method file that indicated a corrupted dual mirror image file (DUALBAD).
Note Utility IOADCPY is not relevant for CONTROL-O Variable Database files.
//COPY EXEC IOADCPY,DBFILE=ACT,SUFFIX=E000
When executing this utility, DD statement DAIN must be included in the JCL stream and
must specify the full name of the uncorrupted (valid, intact) IOA Access Method file.
Notes When using this utility, the activities of all the relevant applications should be stopped.
See the relevant product section for more information on the recovery process.
Utility IOADCPY cannot be used for CONTROL-O Variable Database files.
Examples
If the dual mirror image copy of the CONTROL-D Active User Report List is corrupted, the
DAIN DD statement should specify the name of the main copy:
//DAIN DD DISP=SHR,DSN=CTD.PROD.ACT.E000
If the main copy of the CONTROL-D Active User Report List is corrupted, the DAIN DD
statement should specify the name of the dual mirror image copy:
//DAIN DD DISP=SHR,DSN=CTD.PROD.ACT.D000
Parameters
invokes the IOADCPY JCL procedure:
SUFFIX Suffix of the dataset name of the uncorrupted file.
E000 If the dual mirror image copy is corrupted, specify the
suffix of the main copy of the IOA Access Method file.
D000 If the main copy is corrupted, specify the suffix of the
dual mirror image copy of the IOA Access Method file.
UNIT Name of the DASD unit to be used when allocating new extents for the
damaged or missing file.
VOL List of one to six DASD volume serial numbers, enclosed in
parenthesis and separated by commas, on which the new extents of
the damaged or missing file can be allocated.
name specified in parameter UNIT above.
If VOL is not specified, the extents will be allocated using only
parameter UNIT.
The above parameters are optional and should only be used when it is necessary to
override the UNIT and VOL (or UNITD and VOLD) parameters specified in the IOA Access
Method file definition member when the IOA Access Method file was first created (member
DEFxxx in the IOA INSTCTx library). After running the utility with these parameters,
run utility IOADBF with FUNC=CHANGE specified to update the new values for these
parameters in the IOA Access Method file control block.
Return Codes
4 Missing DD statement or open error occurred for SYSPRINT file.
8 Missing DD statement or open error occurred for input IOA Access
Method file.
12 Error in input parameters.
16 Error in IOA Access Method file name.
20 Error occurred in dynamic allocation.
24 Internal error occurred.
28 Insufficient storage.
32 Missing DD statement or open error occurred for output IOA Access
Method file.
36 Error in input parameters volume serial number was not supplied.
See sample member CTDUFCPY in the CONTROL-D JCL library for more information
about how to use this utility.
IOADIG Verify Integrity of an IOA Access Method File
Data Component
Utility IOADIG is used to verify the integrity of an IOA Access Method files data
component structure. Optionally, utility IOADIG will correct the errors that have been
detected.
Notes All file-related activity of the relevant product must be stopped before this utility is run:
If the file being processed is a CONTROL-D file, all CONTROL-D monitors should
be down when running this utility.
If the file being processed is a CONTROL-O file, all CONTROL-O monitors should
If the file being processed is a CONTROL-B file, all CONTROL-B activities should
be held, e.g., no CONTROL-B rules should be invoked while this utility is running.
//CHECK EXEC IOADIG,DBFILE=filename,FUNC=R|W
Parameters
invokes the IOADIG JCL procedure.
DBFILE IOA Access Method files identifier name (DBNAME) suffix.
FUNC Function to be performed on the file.
R Report errors detected.
W Report and correct errors detected. As a precaution, it is
recommended that a backup copy be made of the IOA
Access Method file data component prior to executing
utility IOADIG with parameter FUNC set to W.
Example
//CHECK EXEC IOADIG,DBFILE=HST,FUNC=R,
Refer to sample job CTDUFCHK in the CONTROL-D JCL library for an example of how to
check the structural integrity of an IOA Access Method file data component.
CONTROL-O Samples
Utility IOADIG is used by the following jobs in the CONTROL-O JCL library:
CTODBSIG Verifies the integrity of the CONTROL-O Variable Database
Definition file.
CTOCOLIG Verifies the integrity of the CONTROL-O Variable Database Column file.
CTOVARIG Verifies the integrity of the CONTROL-O Variable Database Variables file.
IOADII Verify Integrity of an IOA Access Method File
Index Component
Utility IOADII is used to verify the integrity of an IOA Access Method files index
component structure. If errors are detected, the index component should be rebuilt using
the appropriate index rebuilding utility (e.g., CTDDIB for CONTROL-D files or CTBDBIB
for CONTROL-B files).
Note Utility IOADII is not relevant for CONTROL-O Variable Database files.
//CHECK EXEC IOADII,DBFILE=filename
Parameters
invokes the IOADII JCL procedure.
DBFILE IOA Access Method files dataset name suffix.
The utility also indicates the number of records in the file.
Example
//CHECK EXEC IOADII,DBFILE=GRP
Refer to sample job CTDUFCHK in the CONTROL-D JCL library for an example of how to
check the structural integrity of an IOA Access Method file index component.
IOADLD Load IOA Access Method File Contents
Utility IOADLD is used to load an IOA Access Method files contents from a sequential file
previously created by utility IOADUL.
Notes All file-related activity of the relevant product must be stopped before this utility is run:
If the file being loaded is a CONTROL-D file, all CONTROL-D monitors should
If the file being loaded is a CONTROL-O file, all CONTROL-O monitors should
Utility IOADLD cannot be run on CONTROL-B files.
This utility is typically used to migrate an IOA Access Method file to another DASD
volume. In this case, perform the following steps:
1. Run utility IOADUL to unload the IOA Access Method file data components records to
2. Allocate a new IOA Access Method file on a new DASD volume.
3. Format the new IOA Access Method file using utility IOADBF.
4. Run utility IOADLD is executed to reload the IOA Access Method file data component
records from the sequential dataset previously produced by utility IOADUL.
5. The appropriate index rebuilding utility (e.g., CTDDIB for CONTROL-D utility, or
CTODBIB for CONTROL-O) to rebuild the IOA Access Method file index component
based on the contents of the data component.
//LOAD EXEC IOADLD
Parameters
invokes the IOADLD JCL procedure:
SQFILE Input sequential files dataset name suffix.
DBFILE Output IOA Access Method files dataset name suffix.
DISPI MVS dataset disposition of the input file (i.e., KEEP or DELETE).
RENUM Renumber the rows in the Variable Database file. Optional. Valid
value:
R,offset,size
where:
R Indicates that the rows in the Variable Database file
should be renumbered.
offset Number of the column in which the row number begins.
size The number of characters allowed in the row number
field (maximum: 8).
It is recommended that you not alter the offset and size specified in
sample job CTOVARLD (described below).
Note Parameter RENUM is relevant only when reloading the
CONTROL-O Variable Database Variables file.
A maximum of 999 rows can be inserted between two existing
rows in a CONTROL-O Variable Database. Reloading the
Variable Database Variables file with the RENUM parameter
specified refreshes row numbers in the Variable Databases,
thereby allowing insertion of additional rows.
Example
//LOAD EXEC IOADLD,SQFILE=ACTSEQ,DBFILE=ACT
Refer to sample job CTDUFRST in the CONTROL-D JCL library for an example of how to
load an IOA Access Method files data component records from a sequential dataset and
then rebuild the IOA Access Method files index component.
CONTROL-O Samples
Utility IOADLD is used by the following jobs in the CONTROL-O JCL library:
CTODBSLD Loads the CONTROL-O Variable Database Definition file.
CTOCOLLD Loads the CONTROL-O Variable Database Column file.
CTOVARLD Loads the CONTROL-O Variable Database Variables file.
IOADPT Print IOA Access Method File Content
Utility IOADPT prints IOA Access Method file data and index records in SNAP dump
format.
//PRINT EXEC IOADPT
Parameters
invokes the IOADPT JCL procedure.
FUNC Print function to be performed. Valid values:
0 Print IOA Access Method file index and data components.
1 Print IOA Access Method file index component only.
DB0 Print IOA Access Method file index and data component
control records.
DBFILE IOA Access Method files identifier name (DBNAME) suffix.
KEYFROM Value of the record key from which to print. Optional.
KEYTO Value of the record key until which to print. Optional.
RBAOFF RBA offset in the index record key pointing to the data component
record. The default setting for this parameter is 0.
This utility processes both the data and index components of a IOA Access Method file.
If KEYFROM and KEYTO parameters are not specified or are specified as blank, all
records are printed.
Example
//PRINT EXEC IOADPT,FUNC=0,DBFILE=ACT
Refer to sample job CTDUFDPT in the CONTROL-D JCL library for an example of how to
print IOA Access Method file record contents.
CONTROL-O Samples
Utility IOADPT is used by the following jobs in the CONTROL-O JCL library:
CTODBSPT Prints the CONTROL-O Variable Database Definition file.
CTOCOLPT Prints the CONTROL-O Variable Database Column file.
CTOVARPT Prints the CONTROL-O Variable Database Variables file.
IOADUL Unload IOA Access Method File Contents
Utility IOADUL is used to unload an IOA Access Method file data components record
contents to a sequential file.
Notes This utility can run in parallel with IOA monitors. It is not necessary to shut down
monitors for any IOA product when running this utility.
Utility IOADUL cannot be run on CONTROL-B files.
This utility is typically run to migrate an IOA Access Method file to another DASD volume.
In this case, perform the following steps:
1. Run utility IOADUL to unload the IOA Access Method file data components records to
2. Allocate a new IOA Access Method file on a DASD volume.
3. Format the new IOA Access Method file using utility IOADBF.
4. Run utility IOADLD to reload the IOA Access Method file data component records from
the sequential dataset previously produced by utility IOADUL.
5. Utility the appropriate index rebuilding utility (e.g., CTDDIB for CONTROL-D files) to
rebuild the IOA Access Method file index component based on the contents of the data
component.
//UNLOAD EXEC IOADUL,DBFILE=filename,SQFILE=seqfilename,RBAOFF=offset
[,FROMKEY=fkey][,TOKEY=tkey]
Parameters
invokes the IOADUL JCL procedure.
DBFILE Input IOA Access Method files dataset name suffix.
SQFILE Output sequential files dataset name suffix.
RBAOFF RBA offset in the index record key pointing to the data component
record. The default setting for this parameter is 0.
FROMKEY Value of the record key from which to copy. Optional.
TOKEY Value of the record key until which to copy. Optional.
If FROMKEY and TOKEY parameters are not specified or are specified as blank, all
records are copied.
Example
//UNLOAD EXEC IOADUL,DBFILE=PRM,SQFILE=PRMSEQ
Refer to sample job CTDUFDUL in the CONTROL-D JCL library for an example of how to
unload a IOA Access Method file data component to a sequential dataset.
Note For a full list of the files this utility supports, see IOA Access Method in Section 2 of
this guide.
CONTROL-O Samples
Utility IOADUL is used by the following jobs in the CONTROL-O JCL library:
CTODBSUL Unloads the CONTROL-O Variable Database Definition file.
CTOCOLUL Unloads the CONTROL-O Variable Database Column file.
CTOVARUL Unloads the CONTROL-O Variable Database Variables file.
IOAFRLOG Allocate and Format the IOA Log File
Utility IOAFRLOG allocates and formats the IOA Log file. If your site uses dual (mirror)
image files, the primary and dual files should be placed on different disks.
This utility can also be used to delete all records in an existing IOA Log file. To enlarge an
existing IOA Log file, use utility IOACPLOG (described earlier in this section).
Parameters
During the installation process, parameters for this utility are inserted into job FORMLOG
in the IOA INSTALL library. To change these parameters, use Major step Customize IOA
Dataset Parameters via the CUSTOMIZE activity in the IOA Installation Main Menu of
ICE. See Section 14 of the IOA Installation Guide for more information.
invokes the IOAFRLOG procedure:
STEPLIB Name of the IOA LOAD library.
DBPREFA High order dataset name qualifiers of the IOA Core.
ILBLKNO Number of blocks. Automatically calculated by the IOA Installation
procedure under ICE. If specified manually, the value must be:
(LOGSIZE / 31) + 2
The value of LOGSIZE is specified in member IOAPARM.
UNIT Type of unit on which the IOA Log file should reside.
VOL Volume serial number on which the IOA Log file should reside.
DISP1 Status of the IOA Log file. Set DISP=OLD if the IOA Log file exists.
DISP2 Normal termination disposition for the IOA Log file.
DISP3 Abnormal termination disposition for the IOA Log file.
REG Region required to execute the utility. Recommended value: 0M
OUTDUMP Sysout class to which a dump is written if the utility abends.
// EXEC IOAFRLOG
Sample JCL for running this utility is in member FORMLOG of the INSTALL library.
Return Codes
Other One of the errors listed below occurred. A message is printed to the
SYSPRINT dataset.
LOAD FAILED FOR CTMPARM
OPEN FAILED FOR THE DCBOUT (MESSAGES) FILE OR THE LOG
FILE
LOG FILE MUST CONTAIN MORE THAN 100 RECORDS
LOG FILE COULD NOT BE FORMATTED
IOAFRNRS Allocate and Format the IOA Manual
Conditions File
Utility IOAFRNRS allocates and formats the IOA Manual Conditions (NRS) file and the
IOA Manual Conditions Synchronization (NSN) file. This utility can also be used to delete
all records from an existing IOA Manual Conditions file.
Parameters
During the installation process, parameters for this utility are inserted into job FORMNRS
invokes the IOAFRNRS procedure:
UNITNRS Type of unit on which the NRS file should reside.
UNITNSN Type of unit on which the NSN file should reside
LRECL Length of the NRS file record.
RECNUM Number of records in the NRS file. Automatically calculated by the
IOA Installation procedure under ICE. If specified manually, the
value must be:
(NRSREC# * 32) + 2
The value of NRSREC# is specified in member IOAPARM.
DISP1 Status of the NRS file. Set DISP=OLD if the IOA Manual Conditions
file exists.
DISP2 Normal termination disposition for the NRS file.
DISP3 Abnormal termination disposition for the NRS file.
// EXEC IOAFRNRS
Sample JCL for running this utility is in member FORMNRS of the INSTALL library.
Return Codes
Other One of the following errors occurred:
OPEN FAILED
FILES COULD NOT BE FORMATTED
IOAFRRES Allocate and Format the IOA Conditions/Resources
File
Utility IOAFRLOG allocates and formats the IOA Conditions/Resources (RES) file and the
IOA Conditions/Resources Synchronization (SNC) file. This utility can also be used to
delete all records in an existing IOA Conditions/Resources file.
Parameters
During the installation process, parameters for this utility are inserted into job FORMRES
invokes the IOAFRLOG procedure:
UNITRES Type of unit on which the RES file should reside.
UNITSNC Type of unit on which the SNC file should reside.
VOLRES Volume serial number on which the RES file should reside.
VOLSNC Volume serial number on which the SNC file should reside.
TYPERES Low level qualifier for the RES file. Recommended value: RES
TYPESNC Low level qualifier for the SNC file. Recommended value: SNC
LRECL Length of the RES file record. Recommended value: 32760
RECNUM Number of records in the RES file. Automatically calculated by the
IOA Installation procedure under ICE. If specified manually, the
value must be:
(RESREC# * 32) + 2
The value of RESREC# is specified in member IOAPARM.
DISP1 Status of the RES file. Set DISP1=OLD if the RES file already exists.
DISP2 Normal termination disposition for the RES file.
DISP3 Abnormal termination disposition for the RES file.
// EXEC IOAFRRES
Sample JCL for running this utility is in member FORMLOG of the INSTALL library.
Return Codes
Other One of the errors listed below occurred. A message is printed to the
SYSPRINT dataset.
OPEN FAILED
FILES COULD NOT BE FORMATTED
IOALDNRS Load IOA Manual Conditions File
This utility creates and loads the IOA Manual Conditions file which can be viewed via the
IOA Manual Conditions screen described in Section 2 of the IOA product-specific user
manuals. The utility is usually run every day after the New Day procedure finishes
executing.
To identify conditions which should be placed in the IOA Manual Conditions file, the
utility first performs a search for all prerequisite IN conditions required for the submission
of jobs/missions/reports on the particular day. The search for prerequisite IN conditions is
performed by checking the job scheduling definitions of all jobs in the Active Jobs file and
by checking the mission definitions of missions in the Active Missions file.
Once the prerequisite IN conditions have been identified, the utility eliminates
non-manual conditions from the list to arrive at the list of manual conditions which need
loading. A prerequisite IN condition is not included in the IOA Manual Conditions file if it
satisfies either of the following criteria:
The prerequisite condition is added to the IOA Conditions/Resources file by an OUT or
DO COND statement in a job/mission/report which is active that day.
The prerequisite condition already exists in the IOA Conditions/Resources file.
All prerequisite IN conditions which do not meet the above criteria are assumed to be
manual conditions and are placed in the IOA Manual Conditions list.
Through parameters passed to the utility, it is possible to exclude the Active Jobs file
and/or the Active Missions file from the search for manual conditions. Of course, if both
files are excluded, no manual conditions will be found, even if they exist.
Every time the utility is activated, the IOA Manual Conditions file is re-created and all
previous conditions are automatically deleted from the file. It is possible to override this
default by using parameter ADDMODE.
This utility can be used in conjunction with KeyStroke Language utility ADDMNCND.
(Refer to Maybe Jobs in Section 6 of the CONTROL-M User Manual for details.)
The conditions to be included in the file can be limited by control statements supplied via
DD statement DALNRIN (or SYSIN).
Parameters
IGNORE Indicates conditions to be ignored during the building of the IOA
Manual Conditions file. Valid values:
IN prefix All conditions beginning with the specified prefix are
ignored when the file is created.
OUT prefix Conditions defined in an IGNORE statement in
production parameter OUT which begin with the
specified prefix are ignored by the algorithm used to
build the IOA Manual Conditions file. An asterisk (*)
signifies that all OUT parameters are ignored.
CODES prefix Conditions defined in an IGNORE statement in
production parameter DO COND which begin with
the specified prefix are ignored by the algorithm
used to build the IOA Manual Conditions file. An
asterisk (*) signifies that all DO COND parameters
are ignored.
WHEN prefix Conditions defined in an IGNORE statement in
production parameter WHEN DO COND which begin
with the specified prefix are ignored by the
algorithm used to build the IOA Manual Conditions
file. An asterisk (*) signifies that all WHEN DO
COND parameters are ignored.
CTM STATUS ENDED
Manual conditions for jobs in the Active Jobs file
which have finished executing (ended OK or
NOTOK) are ignored by the algorithm used to build
the IOA Manual Conditions file. If this parameter is
used, parameter CONTROLM must be set to YES.
CTD STATUS ENDED
Manual conditions for missions in the Active
Missions file which have finished executing (ended
OK or NOTOK) are ignored by the algorithm used to
build the IOA Manual Conditions file. If this
parameter is used, parameter CONTROLD must be
set to YES.
CONTROLM Determines whether or not information in the CONTROL-M Active
Jobs file should be used in the calculation which builds the IOA
Manual Conditions list. Optional. Default taken from installation
parameters.
Y (Yes) Include CONTROL-M information in the calculation
which builds the IOA Manual Conditions file.
N (No) Build the IOA Manual Condition file based on
CONTROL-D/V information only.
CONTROLD Determines whether or not information in the CONTROL-M Active
Missions file should be used in the calculation which builds the IOA
Manual Conditions file. Optional. Default taken from installation
parameters.
YES Include CONTROL-D information in the calculation
which builds the IOA Manual Conditions file.
NO Build the IOA Manual Conditions file based on
CONTROL-M information only.
ADDMODE If this parameter is specified, when the existing Manual Conditions
file is deleted, only manual conditions from that file which were added
(via the ADD command) to the IOA Conditions/Resources file are
retained and appear in the new Manual Conditions file.
Note When CONTROL-M and CONTROL-D/V are both active, it is recommended that a
shared control parameters member be used.
// EXEC IOALDNRS
//DALNRIN DD *
IGNORE IN CICS
IGNORE IN IMS
IGNORE OUT DB-FILE
IGNORE CODES DB-FILE
CONTROLM YES
Return Codes
4 File is full; no more space to add conditions
8 Critical error, list not created
IOANOTE Write a Message to the IOA Log File
This utility writes a message to the IOA Log file. It can be invoked as a started task (STC)
or as a job step.
On terminals supporting color, messages written by IOANOTE appear on the Log screen in
a different color than other messages, making them more readily identifiable.
The message to be written to the Log file is specified via parameter PARM.
Parameters
PARM Text of the message to be written.
As a job step:
// EXEC IOANOTE,PARM=text
As a started task:
S IOANOTE,PARM=text
Return Codes
4 No parameters passed to utility program
8 Operation failed
Example
// EXEC IOANOTE,PARM=PAYROLL APPLICATION MESSAGES BEGIN HERE
IOAOPR - Issue Operator Commands Via a Job or STC
Utility IOAOPR can be used to issue operator commands (MVS, JES2, JES3, VTAM, etc.).
It can be activated as a job step or as a started task, and allows full control over when a
command should be issued and what to do afterwards. It is also possible to send the
command to any computer (because CONTROL-M can schedule a started task in any
computer).
Each command issued by the utility is recorded in the IOA Log file.
The utility can execute commands from a list supplied in DD statement DA34F. To activate
the utility (e.g., as a job step):
// EXEC IOAOPR,CMDMEM=memname
where:
memname Name of a member containing a list of operator commands to be executed.
To activate the utility for one command, use the PARM parameter, as follows:
// EXEC IOAOPR,PARM=command
It is also possible to activate the utility using CONTROL-M facilities. The following is an
example of a schedule definition for a single command in a specified computer:
MEMNAME IOAOPR MEMLIB M3,PARM=$PIA
TASKTYPE STC
Notes Use of this utility/program should be limited to authorized personnel. Most popular
security products support control of the use of programs by program name.
The utility can also issue JES3 commands (under a JES3 environment). A JES3
command will be identified as such only if it begins with the IOA JESCHAR. Under
JES3 it is possible to specify commands starting with more than one type of character.
A command which starts with a valid JES3 command prefix and not with the IOA
JESCHAR will be sent for execution but may not be executed by JES (without any
indication from utility IOAOPR).
IOATEST Simulate Production Environment Events
This utility simulates various events in the production environment. For example, it can
simulate step termination codes or cause a step to wait a specified interval.
Parameters
CMD Issue an operator command. The command can be either an MVS/JES
command or, when MVS is running under VM, a CP command. (CP
commands must start with characters CP.) Maximum text length = 76
characters.
WTO Write message to operator console. Maximum text length = 76
characters.
WTOR Write message to operator console with reply. Maximum text length =
75 characters.
WTOM Issue multi-line message. major is the primary message line.
Subsequent minor lines are secondary message lines, delimited by a
+++ line. A maximum of ten message lines are permitted.
Example
WTOM= major
Minor 1
Minor 2
minor n
+++
ROUT Valid route code from 0 to 16 (0 = no route code). Default: all route
codes.
DESC Valid descriptor code from 0 to 16. Default: 0 (none).
CONID Console ID to which the message is issued. Valid range: 0-999. Default: 0.
CONNAME Name of the console to which the message is sent, or on which the
command is issued.
SYSTEM Name of the system (i.e., the MVSIMAGE) to which the message is
sent, or on which the command is issued.
JOBNAME Name of the job that issued the message.
JOBID The JES2 or JES3 job ID of the job that issued the message.
Note Parameters SYSTEM, JOBNAME and/or JOBID can be used to simulate
messages coming from another member of a SYSPLEX environment or JES3
complex.
DEFDELAY where n = number of 1/100 seconds. The program waits for a given
time both before a WTO/WTOR/WTOM message or command is
executed and before the program ends. 1-4 digits. Default: 100 (one
second).
WAIT Cause the step to wait n seconds. Valid range: 0-999.
TERM=Cnnn Condition code to be simulated. Valid range: 0-4095.
TERM=Unnnn User abend code to be simulated. Valid range: 0-4095.
TERM=Snnn System abend code to be simulated. Valid hexadecimal range:
000-FFF.
WTO, ROUT, DESC, CONID, CMD, WAIT and TERM can also be specified in the PARM
keyword of the EXEC job step. If this method is used, only the PARM parameters are
executed in the following order: WTO, WAIT, TERM. When using PARM, DEFDELAY is
always 0.
Examples
//EXEC IOATEST,
// PARM=WTO=PROGRAM ERROR,WAIT=10,TERM=U0008
Issues WTO message with the text PROGRAM ERROR, waits 10 seconds and terminates
the step with user abend U0008.
// EXEC IOATEST
//SYSIN DD *
CMD=D T
TERM=C0004
//
Issues the operator command D T and then terminates with condition code C0004.
IOAVERFY Verify IOA File Installation and Status
Utility IOAVERFY can be used to perform the following tasks:
Verify IOA product installation.
Produce reports on the utilization of various IOA files.
Produce a report describing invalid records in the IOA Conditions/Resources file, the
CONTROL-M Active Jobs file, or the CONTROL-M History Jobs file. (Invalid records
can be automatically corrected during the same run.)
Verify and replace specified data in records of the CONTROL-M Active Jobs file.
Parameters
DISPLAY Controls the scope of display. Optional. Multiple DISPLAY statements
can be specified. A DISPLAY statement is in effect until the next
display statement. Valid parameters for this statement:
ALL Both information and error messages are displayed. Default.
ERROR Only error and warning messages are displayed.
VERIFY Displays and verifies information about the requested item(s).
Optional, but at least one VERIFY, LIST, DIAGNOSE or VER/REP
statement must be specified or there will be no utility output. Multiple
VERIFY statements can be specified. A VERIFY statement remains in
effect until the next VERIFY statement is specified.
VERIFY statement formats:
VERIFY SYSTEM GENERAL
Displays general information about the system environment.
VERIFY PASSWORD Displays CPU identification information required before requesting a
new password.
VERIFY FILE filetype
where:
filetype Indicates files to be displayed and verified in this run of
utility IOAVERFY. Valid values:
ALL Includes all files listed below.
CKP/AJF CONTROL-M Active Jobs file.
HST CONTROL-M History Jobs file.
AMF CONTROL-D Active Missions file.
RES IOA Conditions/Resources file.
NRS IOA Manual Conditions file.
LOG IOA Log file.
Notes CKP and AJF are two names for the same CONTROL-M file. Both
names are supported.
If VERIFY FILE ALL is specified, the program determines which
products are installed and displays information on all relevant filetypes.
LIST Displays subsystem control blocks and IOA parameter tables. This
statement helps IOA support personnel during problem determination.
Optional, but at least one VERIFY, LIST, DIAGNOSE or VER/REP
statement must be specified or there will be no utility output. Multiple
LIST statements can be specified. A LIST statement remains in effect
until the next LIST statement is specified.
LIST statement formats:
LIST PARM parmname
-or-
LIST SUBSYS subsys-name
where:
parmname Names of parameter tables to be displayed:
ALL Snapshot dumps of parameter tables for all
IOA products installed
CTBPARM Snapshot dump of module CTBPARM
CTDPARM Snapshot dump of module CTDPARM
CTMPARM Snapshot dump of module CTMPARM
CTOPARM Snapshot dump of module CTOPARM
CTTPARM Snapshot dump of module CTTPARM
CTVPARM Snapshot dump of module CTVPARM
CTRPARM Snapshot dump of module CTRPARM
ECSPARM Snapshot dump of module ECSPARM
IOAPARM Snapshot dump of module IOAPARM
IOAXPARM Snapshot dump of module IOAXPARM
subsys-name Name of subsystem whose control blocks are to be
displayed. Optional. If omitted, the subsystem name
specified in member IOAPARM is used. A snapshot dump
is taken of all the data areas relating to the subsystem.
DIAGNOSE Checks the integrity of file(s) processed by the utility. Produces a report
describing all records containing errors. Optional, but at least one VERIFY,
LIST, DIAGNOSE or VER/REP statement must be specified or there will be
no utility output. Multiple DIAGNOSE statements can be specified.
If optional keyword CORRECT (described below) is specified, records
containing errors are automatically corrected.
Notes Utility IOAVERFY cannot be run with the CORRECT function
while the CONTROL-M monitor is active. However, online users can
remain logged on.
It is strongly recommended that you not run the CORRECT function
while the CONTROL-D monitor, the CONTROL-O monitor, or the
IOA Functional monitor is active.
If the Active Jobs file is corrected by utility IOAVERFY, it is highly
recommended that you compress it. For information about how to
compress the Active Jobs file, see utility CTMCAJF later in this section.
Valid formats for a DIAGNOSE statement:
DIAGNOSE filetype
-or-
DIAGNOSE filetype CORRECT
where:
filetype Indicates file(s) to be processed by the DIAGNOSE statement.
Valid values:
ALL Includes all files listed below.
AJF CONTROL-M Active Jobs file.
HST CONTROL-M History Jobs file.
RES IOA Conditions/Resources file.
CORRECT Optional keyword. Records will be automatically corrected
only if this keyword is specified.
VER Indicates information that should be replaced with information in the
REP statement which immediately follows. Optional, but at least one
VERIFY, LIST, DIAGNOSE or VER/REP statement must be specified or
there will be no utility output. Each VER statement must be followed by
one REP statement.
Notes VER statements and REP statements can be specified only for
records in the CONTROL-M Active Jobs file.
The VER statement is rejected if the data at the specified offset does
not match the data specified in the VER statement. If a VER
statement is rejected, the REP statement which follows it is ignored.
An appropriate error message is produced for each record that is
rejected because of a VER/REP failure.
VER operands must appear between columns 1 and 80. VER statement
format:
VER rba type offset verformat verdata
where:
rba RBA of the record to be verified. The RBA must be specified
as a hexadecimal value of two, four, or six digits.
type Type of offset:
X Hexadecimal value.
D Decimal value.
offset Location of the data to be replaced with the data in the REP
statement. The first byte of the record always has an offset of 0.
If type X is specified, the offset must be a hexadecimal
value with two or four digits. The maximum value cannot
exceed 03FF.
If type D is specified, the offset must be a decimal value of
one to four digits and cannot exceed 1023.
verformat Format of the data to be verified:
X verdata contains hexadecimal digits.
C verdata contains alphanumeric characters.
verdata Value to be replaced by the data specified in the REP
statement which follows. The specified value must be
enclosed in either single or double quotes.
If verformat is X, verdata must be specified as pairs of
hexadecimal digits. A maximum of 48 hex digits (i.e., 24
pairs) can be specified.
If verformat is C, verdata must be a string of
alphanumeric characters. Maximum length: 48
characters.
REP Indicates data that should replace the information in the immediately
preceding VER statement. Optional, but each REP statement must be
preceded by one VER statement.
Note VER statements and REP statements can be specified only for
records in the CONTROL-M Active Jobs file.
REP operands must appear between columns 1 and 80. REP statement
format:
REP rba type offset repformat repdata
where:
rba, type and offset must be identical to the rba, type and offset specified
in the preceding VER statement.
repformat The format of the specified repdata
X repdata contains hexadecimal digits.
C repdata contains alphanumeric characters.
repdata Data which should replace the data specified in the preceding
REP statement. The specified data must be enclosed in either
single or double quotes.
If repformat is X, repdata must be specified as pairs of
hexadecimal digits. A maximum of 48 hex digits (i.e., 24
pairs) can be specified.
If repformat is C, repdata must be a string of
alphanumeric characters. Maximum length: 48
characters.
The data specified in the VER statement and the data
specified in the REP statement must indicate strings of equal
length. Therefore, if verdata and repdata are specified in
different formats, the data which is specified in hexadecimal
characters must contain twice as many characters as the data
specified in alphanumeric characters. (See Example 2
below.)
Notes Utility IOAVERFY cannot be run with the VER/REP function while
the CONTROL-M monitor is active. However, online users can
remain logged on.
It is strongly recommended that you not use the VER/REP function
while the CONTROL-D monitor, the CONTROL-O monitor, or the
IOA Functional monitor is active.
Samples of VER statements and REP statements:
Example 1
Change the record with RBA 0 at offset x3F from x0003E8 to x00045D.
VER 00 X 3F X 0003E8
REP 00 X 3F X 00045D
Example 2
Change the record with RBA 0 at offset x0103 from x000000 to
character string JB1.
VER 00 X 0103 X 000000
REP 00 X 0103 C JB1
Example 3
Change the record with RBA 1A95 at decimal offset 20 from character
string N28 to character string M04.
VER 1A95 D 20 C N28
REP 1A95 D 20 C M04
END Terminates input to the utility. Optional. Only one END statement
can be specified, at the end of the utility statements.
//VERIFY EXEC IOAVERFY
//DAVRFIN DD *
Return Codes
4 Warning message.
8 and above Severe error found.
Trace Facility
If you encounter errors when running utility IOAVERFY, you may be requested to run the
utility with optional parameter TRACE.
This parameter activates the trace facility of utility IOAVERFY. If TRACE is specified,
information about internal data areas is printed when the utility is run.
Parameter TRACE is specified in the EXEC statement of the utility in the following
format:
//VERIFY EXEC IOAVERFY,PARM=TRACE=level
where level is the trace level to be activated. Valid value: 121.
Note This parameter should be used only if requested by your IOA representative.
CONTROL-M Utilities
CTMBGRP Convert Regular Scheduling Tables to Group
Scheduling Tables
Utility CTMBGRP automatically converts regular scheduling tables into Group scheduling tables.
During conversion from a regular scheduling table to a Group table, the following actions
are automatically performed by the utility:
A Group entity is created for the table.
A Group name is defined and added (in protected mode) to the GROUP field in each job
scheduling definition.
The format of the regular job scheduling definitions is modified to match the format of
job scheduling definitions in Group scheduling tables (i.e., the SCHEDULE TAG field is
added to, and supported in, the job scheduling definitions).
By default, the value of parameter MAXWAIT is obtained from the group definition.
However, if wish WM2890 has been applied, the value of this parameter is obtained
from the job definition.
Note Compress jobs within a table (i.e., job scheduling definitions with the MINIMUM and
PDS fields defined) are converted, but these jobs are not assigned SCHEDULE TAG
fields. Instead, their only scheduling criteria after the conversion are the MINIMUM
and PDS criteria. However, a SCHEDULE TAG field can be manually added
following conversion.
Statements and Parameters
All utility messages are written to the SYSPRINT file.
The START/END conversion messages are also written to the IOA Log file.
Parameters are passed to the utility via DD statement SYSIN.
The required datasets are referenced by the following DD statements:
DALOG References the IOA Log file.
SYSPRINT References the utility message file. This file can be a SYSOUT
file.
SYSIN References the utility input file.
Keywords in the SYSIN statements must be specified beginning in column 1 and in the
exact sequence indicated. Lines with an asterisk (*) in column 1 are treated as comment
lines.
Parameters:
IN-TABLE=old-table Old (regular) scheduling table library and member.
OUT-TABLE=new-table New (Group) scheduling table library and member.
GROUP=group-name Group name (1 20 characters) to be assigned to the jobs in the
scheduling table.
Multiple tables can be converted in a single run of the utility by passing multiple sets of
IN/OUT/GROUP lines. These sets can be separated by one or more comment lines.
Note The value assigned to OUT-TABLE cannot be identical to value of IN-TABLE.
The following sample job to activate the utility can be found in member CTMBGRP in the
CTM.JCL library:
// JOB CARD PARAMETERS
//BUILD1 EXEC PGM=CTMGRB,REGION=0M
//STEPLIB DD DISP=SHR,DSN=IOA.Vnnn.LOAD
//DALOG DD DISP=SHR,DSN=IOA.Vnnn.LOG
//SYSIN DD *
*----------------------------------------*
* FIRST TABLE. *
*----------------------------------------*
IN-TABLE=OLD.DSN(OLDTABLE)
OUT-TABLE=NEW.DSN(NEWTABLE)
GROUP=NEW-GROUP-NAME
*----------------------------------------*
* SECOND TABLE. *
*----------------------------------------*
IN-TABLE=OLD.DSN2(OLDTAB2)
OUT-TABLE=NEW.DSN2(NEWTAB2)
GROUP=NEW-GROUP-NAME-2
*----------------------------------------*
* THIRD TABLE, ETC. *
*----------------------------------------*
Return Codes
0 All scheduling tables were successfully converted.
4 All scheduling tables were successfully converted, but at least one of the
tables contained at least one compress job. Compress jobs were not
assigned SCHEDULE TAG fields during conversion.
8 At least one table was not converted due to error. An error message
identifying the unconverted table, and the error, was issued for each
unconverted table.
16 Initialization failed. No tables were converted. A message indicating the
error was issued.
20 Insufficient memory. No tables were converted.
CTMCAJF Maintain the Active Jobs File or History File
Utility CTMCAJF performs special maintenance functions on the Active Jobs file or
History file. The operator is warned in advance when the file is nearly full. The operator
can use utility CTMCAJF to perform any of the following actions:
Compress the file.
Delete entries from the Status screen.
Change the size of the file by copying the file to a different size file.
TYPE Argument
An optional TYPE= argument can be specified for the COMPRESS and COPY functions to
specify whether the Active Jobs file or the History file is to be compressed/copied. If this
argument is not specified, the Active Jobs file is compressed or copied.
TYPE Indicates the file to be compressed or copied. Optional. Valid
values:
AJF Copy or compress the Active Jobs file. Default.
HST Copy or compress the History file.
Statements and Parameters
The utility receives parameters, which designate the required function, via DD statement
DACOPPRM (or SYSIN). Any of the following functions can be requested:
COMPRESS Make room in the Active Jobs file or History file by physically
deleting all jobs marked DELETED or ENDED OK.
CLEANUP Logically delete all jobs marked DELETED or ENDED OK in the
Active Jobs file. These jobs remain in the Active Jobs file until the
New Day procedure is run. The space these jobs occupy in the file
cannot be reused.
Logically deleted jobs can be restored via the U (Undelete) option in
the CONTROL-M Active Environment screen (screen 3).
COPY Copy the Active Jobs file or History file to a different size file,
generally a larger file.
Notes The COMPRESS and COPY functions cannot run in parallel
with the CONTROL-M monitor. If the monitor is not shut
down, the utility will terminate. Online users can remain
logged on.
The CLEANUP function must run simultaneously with the
CONTROL-M monitor. Do not shut down the monitor when
running the utility with this function.
SELECT/IGNORE Statements
SELECT/IGNORE statements are optional and can only be specified for COMPRESS and
CLEANUP functions. They identify jobs which should be deleted or not deleted, as follows:
IGNORE statements Identify jobs which should not be deleted.
SELECT statements Identify jobs which should be deleted.
Note If a CLEANUP is being performed, SELECT/IGNORE statements are applied in
addition to (not instead of) the default SELECT/IGNORE statements specified in the
New Day procedure. New Day procedure default SELECT/IGNORE statements are
applied by this utility.
Up to 500 SELECT/IGNORE statements can be specified. Jobs are handled according to
the first statement for which the criteria are met.
One or more of the following parameters can be specified in any SELECT/IGNORE
statement (in any order):
GROUP groupname Name of the group appearing in the job scheduling definition.
JOBNAME jname/MEMBER memname
jname Name of the job appearing in both the JOB
statement and the JOBNAME field of the Status
screen.
memname Name of the JCL member (specified in the
MEMNAME field in the job scheduling
definition).
jname or memname (but not both) can be specified in one
statement.
STATUS status Valid values:
ACTIVE
Note ACTIVE status includes all statuses except WAITSCHED,
ENDOK and ENDNOTOK. This status enables the user to
select or ignore jobs which are in ACTIVE status.
ENDOK
ENDNOTOK
HELD
WAITSCHED
FROM date Starting ODATE in yymmdd format
TO date Ending ODATE in yymmdd format
Note A prefix can be specified instead of a full group name, job
name or member name by placing an asterisk (*) at the end
of the string (e.g., PROD*).
Specifying AutoEdit Variables and Functions
AutoEdit variables can be specified for any of the above parameters. These variables are
especially useful for specifying relative date ranges in the FROM and TO parameters.
AutoEdit functions can be used to set variables and these variables can then be used in the
parameters of the utility. The lines in which the variables are set must have an asterisk (*)
in the first column of the line. Such lines are resolved by the AutoEdit facility and are
interpreted as comments by the utility. Regular comments can also be specified in lines
with an asterisk in the first column.
Example
* IGNORE MEMBERS PREFIXED WITH BR14 WHICH WERE ORDERED
* WITHIN THE LAST THREE DAYS.
* %%SET %%F = %%CALCDATE %%DATE -3
IGNORE MEMBER BR14*
FROM %%F
Note The following AutoEdit terms cannot be used in the input for this utility:
%%ODATE, %%OYEAR, %%OMONTH, %%ODAY, %%OWDAY, %%INCLIB and
%%INCMEM.
File Statements
File statements are mandatory for COPY functions. They cannot be specified for
COMPRESS or CLEANUP functions. Either OLDAJF and NEWAJF statements or
OLDHST and NEWHST statements must be specified for COPY functions:
OLDAJF Name of the old Active Jobs file.
NEWAJF Name of the new Active Jobs file.
OLDHST Name of the old History file.
NEWHST Name of the new History file.
Compressing the Active Jobs File
The Active Jobs file often contains entries for jobs which are no longer needed (jobs with a
status of DELETED or ENDED OK). Compression makes room in the Active Jobs file by
physically removing these unneeded entries from the file. Removed entries no longer
appear on the Status screen.
Cleaning the Active Jobs File
Normally, the Active Jobs file is cleaned (i.e., unneeded job entries are deleted) once a day
by the New Day procedure. By default, all jobs with status ENDOK which are not being
held are deleted during this cleanup. The defaults can be overridden by using SELECT and
IGNORE statements (which select or ignore jobs for deletion).
Utility CTMCAJF can be run as often as necessary to clean the Active Jobs file.
Unlike the cleanup performed by the New Day procedure, utility CTMCAJF does not
actually delete the unneeded jobs. Instead, it marks the job entries as deleted so that they are
ignored by CONTROL-M and so that, by default, the job entries do not appear in the Status
screen. (To display these logically deleted jobs in the Active Environment (Status screen, specify
Y in the DELETED field in the Show Screen Filter window (3.SHOW) of the Status screen.)
Logically, deleted jobs are physically deleted the next time the New Day procedure is run.
When utility CTMCAJF is run to clean up the Active Jobs file, it applies the cleanup criteria of
the New Day procedure in addition to the cleanup criteria specified with the utility. If the
cleanup criteria of the New Day procedure are not desired when running utility CTMCAJF,
they should be overridden by SELECT/IGNORE statements specified in the utility.
Changing the Size of the Active Jobs File
Note Online users should not access the CONTROL-M Online facility while the size of the
Active Jobs file is being changed.
To change the size of the CONTROL-M Active Jobs file, perform the following steps:
1. Change CONTROL-M installation parameter CKPSIZE in member CTMPARM to the
required new Active Jobs file size.
Note After step 2 , every access to the Active Jobs file (Online, batch, or monitor) will try to
utilize the new size and may abend. Therefore, all access to the Active Jobs file
should be stopped and the monitor should be shut down until the process is complete.
2. Reassemble member CTMPARM using job CTMPARMJ. Refresh the LLA, if necessary.
3. Change parameter CKPSIZE in procedure CTMFRCKP to the new size of the Active Jobs file.
4. Run member FORMCKP in the IOA INSTCTM library after changing the dataset
names (to avoid overwriting the existing Active Jobs file and its backup file).
5. If you have a backup file, allocate a new backup file and run member FORMCKP against
the new backup file. If you are working in dual checkpoint mode, run member FORMDCKP.
Note If you are working in dual checkpoint mode, the Mirror file must also be allocated
with the new size before starting the CONTROL-M monitor. Otherwise, an abend
of the CONTROL-M monitor may occur.
6. Run utility CTMCAJF. The utility copies the current Active Jobs file to new Active Jobs file.
7. Rename the old Active Jobs file (and its backup file suffix BKP).
8. Rename the new Active Jobs file (and its backup file suffix BKP) to the former names
of the old files.
9. Restart the CONTROL-M monitor and resume operation. The utility must terminate
with a return code of 0.
Note The CONTROL-M BKP file is normally updated only during New Day processing
(when the CKP file is copied to the BKP file).
Activating the COMPRESS Function (Active Jobs File or History File)
//COMP EXEC CTMCAJF{,TYPE=AJF|HST}
COMPRESS
//
Activating the CLEANUP Function(Active Jobs File Only)
//CLEANUP EXEC CTMCAJF
CLEANUP
//
Activating the COPY Function (Active Jobs File)
//COPY EXEC CTMCAJF,{TYPE=AJF,}
// OLDAJF=CTM.PROD.CKP, OLD ACTIVE JOBS FILE
// NEWAJF=CTM.PROD.NEWCKP NEW ACTIVE JOBS FILE
COPY
//
Activating the COPY Function (History File)
//COPY EXEC CTMCAJF,TYPE=HST,
// OLDHST=CTM.PROD.HST, OLD HISTORY FILE
// NEWHST=CTM.PROD.NEWHST NEW HISTORY FILE
COPY
//
Return Codes
other Operation failed
Example 1
Delete all jobs of the night batch from the Active Jobs file, except those with a WAIT
SCHEDULE status. In addition, delete jobs which ended OK and jobs whose MAXWAIT
interval has been exceeded if such jobs do not have WAITSCHED status.
//COMP EXEC CTMCAJF,TYPE=AJF
COMPRESS
IGNORE STATUS WAITSCHED
SELECT GROUP NIGHT-BATCH
Example 2
Delete only jobs in group G1, G2 and G3.
//COMP EXEC CTMCAJF
COMPRESS
SELECT GROUP G1
SELECT GROUP G2
SELECT GROUP G3
IGNORE GROUP *
Example 3
Delete all jobs except job A622451C.
//COMP EXEC CTMCAJF
COMPRESS
IGNORE MEMBER A622451C
SELECT GROUP *
CTMFRCKP Allocate and Format the Active Jobs File
Utility CTMFRCKP allocates and formats the Active Jobs file (AJF, formerly called file
CKP), its associated backup file (file BKP), and the dual (mirror) AJF if dual mirror
imaging is implemented for the AJF at your site. (For more information about dual
imaging, see parameter DUALDB in Section 3 of the IOA Installation Guide.)
File BKP can be used as a recovery file to recover from procedure CONTDAY failures and
as a base file when utilizing the Journal file to implement forward restoration.
The dual file can be used as a recovery file if the AJF file fails (e.g., because of a disk
crash). For performance and data safety reasons, the AJF and its dual file should not be on
the same physical disk.
// EXEC CTMFRCKP
Parameters
The following parameters can be specified in the EXEC statement which invokes the
CTMFRCKP procedure:
STEPLIB IOA Load library.
DBPREFA High order dataset name qualifiers of the IOA Log file.
DBPREFM High order dataset name qualifiers of the AJF and BKP files.
UNIT Type of unit on which AJF and BKP files should reside.
VOL Volume on which the AJF and BKP files should reside.
DISP1, DISP2, DISP3
Status, normal termination and abnormal termination disposition of the
AJF and BKP files.
REG Region required to execute the job (recommended: 0M).
OUT Sysout class to which program messages are to be written.
Return Codes
8 One of the following errors occurred:
OPEN FAILED FOR DCBOUT (MESSAGES) FILE OR THE CKP/BKP FILE
CKP/BKP FILE COULD NOT BE FORMATTED
OPEN/LOAD OF LOG FAILED
CTMFRJNL Allocate and Format the Journal File
Utility CTMFRJNL allocates and formats the CONTROL-M Journal file.
The Journal file can be used to implement forward restoration in the event of an Active
Jobs file failure. For performance and data safety reasons, the Active Jobs file and the
Journal file should not be on the same physical disk.
// EXEC CTMFRJNL
Parameters
CTMFRJNL procedure:
STEPLIB IOA Load library.
DBPREFA High order dataset name qualifiers of the IOA Log file.
DBPREFM High order dataset name qualifier of the Journal file.
UNIT Type of unit on which the Journal file should reside.
VOL Volume on which the Journal file should reside.
DISP1, DISP2, DISP3
Status, normal termination and abnormal termination disposition of the
Journal file.
REG Region required to execute the job (recommended: 0M).
OUT Sysout class to which program messages are to be written.
Return Codes
16 An error occurred
CTMJSA Job Statistics Accumulation
General
Utility CTMJSA is used to keep the Statistics file up to date. The utility scans the IOA Log
file for message SPY281I. If the Automatic Tape Drive Quantity Adjustment feature
(optional wish WM2744) is enabled, the utility also scans the IOA Log file for message
SPY28GI. Messages SPY281I and SPY28GI contain information that is used to update the
statistics file. The utility updates the Statistics file for every job that ended OK within a
specified date range. Statistical records can optionally be deleted from the Statistics file.
A number of features that significantly improve production handling and flow rely on the
data in the Statistics file. Therefore, it is important to keep this data as up to date as
possible. It is recommended that utility CTMJSA be run once a day during New Day
processing before production jobs are ordered.
CONTROL-M accumulates data for up to 20 successful runs of each job. If a job finished
executing NOTOK, or has been queued for re-execution by command $EJ, its statistical
data is not accumulated.
Note Statistics are accumulated only if parameter STAT in member CTMPARM is set to Y.
When the accumulation of statistical information has been properly automated, the
information can be effectively used for the following facilities and reports:
Simulation and Forecasting
Dataset Job Cross-Reference
Automatic Tape Drive Resource Adjustment
Deadline Scheduling
Enterprise Controlstation Live Simulation
Parameters
The following parameters can be specified for utility CTMJSA:
FROMDATE Date from which to accumulate statistical data from the IOA Log file.
Mandatory.
The date can be a specific date (in mmddyy, ddmmyy or yymmdd
format, depending on the site standard), or a relative negative number
(including 0) of days from the date specified in parameter ODATE.
TODATE Date until which to accumulate statistical data from the IOA Log file.
Mandatory.
The date can be a specific date (in mmddyy, ddmmyy or yymmdd
format, depending on the site standard), or a relative negative number
(including 0) of days from the date specified in parameter ODATE.
ODATE Date reference for use by parameters FROMDATE and/or TODATE.
Mandatory if a relative date is specified for either of these parameters;
otherwise, optional.
The date specified for this parameter can be a specific date (in
mmddyy, ddmmyy, or yymmdd format, depending on the site
standard) or an AutoEdit variable which resolves to a specific date.
CLEANUP Date from which to keep records. Records which have not been
updated since the specified date will be deleted from the Statistics file.
Optional.
The date specified for this parameter can be a specific date (in
mmddyy, ddmmyy, or yymmdd format, depending on the site
standard) or an AutoEdit variable which resolves to a specific date.
It is highly recommended that the utility be activated daily. The following example
illustrates the accumulation of statistics for a single day:
//D4JSA JOB...
// EXEC CTMJSA
ODATE %%OMONTH.%%ODAY.%%OYEAR
FROMDATE -3
TODATE -1
//
The statistical accumulation for the above example will always work on jobs which have
executed from three days ago until the day before today. The same jobs data will not be
accumulated twice.
Note The above sample job contains AutoEdit variables and must therefore be submitted
directly by CONTROL-M.
At most sites, parameter CLEANUP is specified only occasionally to delete inactive records
from the Statistics file. However, parameters FROMDATE and TODATE must always be
specified. The following sysout illustrates a run of utility CTMJSA during which entries
were removed from the Statistics file because a date was specified for parameter
CLEANUP.
09.43.56 JSA921I ACCUMULATION OF JOB EXECUTION STATISTICS STARTED
CLEANUP 010698
ODATE 010698
FROMDATE -2
TODATE -1
09.43.57 JSA909I JOB @BR14 GROUP DATE 220598 WAS REMOVED
09.43.57 JSA909I JOB CTMJSA GROUP DATE 140598 WAS REMOVED
09.43.57 JSA909I JOB IEBGEN GROUP DATE 100598 WAS REMOVED
09.43.57 JSA909I JOB IEFBR14 GROUP DATE 090598 WAS REMOVED
09.43.57 JSA909I JOB ISRA2MEM GROUP DATE 090598 WAS REMOVED
09.43.57 JSA909I JOB JOBA GROUP DATE 090598 WAS REMOVED
09.43.57 JSA909I JOB JSA514 GROUP DATE 220598 WAS REMOVED
09.43.57 JSA909I JOB NJER GROUP DATE 110598 WAS REMOVED
09.43.57 JSA909I JOB QM12A GROUP DATE 090598 WAS REMOVED
09.43.57 JSA909I JOB QM17D GROUP THEQMGRP DATE 010598 WAS REMOVED
09.43.57 JSA909I JOB RUNCTMJS GROUP DATE 090598 WAS REMOVED
09.43.57 JSA909I JOB TAPE22 GROUP DATE 220598 WAS REMOVED
09.43.57 JSA922I ACCUMULATION OF JOB EXECUTION STATISTICS ENDED WELL
CTMRSTR Restore the CONTROL-M Active Jobs File
When restoration of the CONTROL-M Active Jobs file is necessary, utility CTMRSTR can
be run to perform this task. Optionally, prerequisite conditions in the IOA
Conditions/Resources file can also be restored.
The utility uses the CONTROL-M journal file in conjunction with the CKPJNL and
RESJNL files to perform a forward restoration of the Active Jobs file from the last time
New Day processing was performed.
Notes In certain situations (e.g., when multiple IOA products have been updating the IOA
Conditions/Resources file), restoration of the IOA Conditions/Resources file may not
be desirable and should not be performed.
ECSGATE should be down when running utility CTMRSTR. If CONDITIONS NO is
specified, CONTROL-D and CONTROL-O will not be affected by running this utility.
CONTROL-M and ECSGATE must be activated after running utility CTMRSTR.
Other IOA products need not be recycled.
Parameters
The parameters are passed to the utility via the DD SYSIN file. The parameters:
ENDTIME yyyymmddhhmmssth
*Time until which the CONTROL-M Active Jobs file is to be restored.
The Active Jobs file image (after the New Day procedure) is updated to
reflect the image of the file at the specified time. The time parameter
consists of the following subparameters:
yyyy 4-character year.
mm Month (1 12).
dd Day (1 31).
hh Hour (00 24).
mm Minute (00 59).
ss Second (00 59).
th Hundredths of a second (00 99).
CONDITIONS Indicates whether or not to restore the IOA Conditions/Resources file:
Y (Yes) Restore the IOA Conditions/Resources file to its image at
the time specified.
N (No) Do not restore the IOA Conditions/Resources file. Default.
Example
Restore the contents of the CONTROL-M Active Jobs file to the image it contained at 12
noon on July 1, 1998. In addition, restore the prerequisite conditions in the IOA
Conditions/Resources file to the same point in time.
//RESTORE EXEC CTMRSTR
//SYSIN DD *
ENDTIME 199807011200000000
CONDITIONS YES
//
Return Codes
4 Warning message issued
8 Verification check failed prior to initialization of restoration
AJF verification
CTMPARM verification
Endtime specification mismatch
Unexpected program error
12 Addition or deletion of a condition in the IOA Conditions/Resources file
failed
16 Unable to open file or obtain storage for processing
CONTROL-B Utilities
CTBABI Initialize Active Balancing File
Utility CTBABI initializes both the Active Balancing file and its backup file, ABFBKP.
Utility CTBABI should be activated whenever these files are reformatted by utility
IOADBF.
Parameters
The following parameter must be specified in the EXEC statement which invokes the
CTBABI JCL procedure.
DBFILEB Name of the file to initialize:
ABF Active Balancing file.
ABFBKP Backup file ABFBKP of the Active Balancing file.
// EXEC CTBABI, DBFILEB=[ABF|ABFBKP]
Return Codes
0 Operation successful
Example
// EXEC CTBABI,DBFILEB=ABF
This utility is used by jobs CREFABF and CREFBKP (in the INST CTB library) when the
Active Balancing File and its backup file are created. See these jobs for additional
examples.
CTBCMP Compile Rule Definitions
Utility CTBCMP checks the syntax of rule definitions. It is especially useful for checking
rule definitions created via a standard editor.
Parameters
Parm=-irulename
Name of the rule definition which must be checked for syntax errors. The rule name is
preceded by the prefix i (which can be uppercase or lowercase). The rule name and the i
prefix must be specified between quotes.
// EXEC CTBCMP,PARM=-IRULENAME
Return Codes
0 No syntax errors were found
other Syntax errors were found
Example
// EXEC CTBCMP,PARM=-ICOMPTOTS
//DABRUL DD DISP=SHR,DSN=CTB.PROD.RULES
CTBDBCP Increase Size of a Database File
This utility copies the contents of a specified source file to a specified target file. All
relevant aspects of the file are copied, including (pointers to) variable definitions, variable
generations, and group information.
The sizes of the source and target files can differ. Therefore, utility CTBDBCP is useful for
increasing the size of a file. Usually, this utility copies data from a source file to a larger target file.
Copying a file is composed of the following stages:
Create and format a new file (target file).
Copy the data from the source file to the newly-created target file.
Delete the source file.
Utility CTBDBVCP can modify all CONTROL-B database files simultaneously. However,
utility CTBDBCP is more efficient than utility CTBDBVCP when modifying a single file.
Parameters
The following parameters must be specified in the EXEC statement which invokes the
CTBDBCP JCL procedure.
DBFILE Name of the file to be enlarged. (Add the suffix .OLD to the name of
the input file before the JCL procedure is executed.) The specified
name becomes the name of the enlarged output file. Mandatory.
Valid names must contain one of the following suffixes:
File Type Suffix
Group GRP
Database Variable MOD
Variable Generation VAR
Report REP
Rule Activity JAF
OLDQNAME QNAME of the input file (for validity checking only). Mandatory.
KEY Type of index file to be generated. Mandatory. Valid values:
File Type Value
Group KEYGRP
Database Variable KEYDBM
Variable Generation KEYDBV
Report KEYREP
Rule Activity KEYJAFJ
Note The KEY value should match an existing descriptor member
supplied in the CONTROL-B PARM library.
DUAL Indicates whether or not a mirror image file is maintained.
Mandatory. Valid values:
TRUE Use this value if DUAL=Y in the respective DEF* member
in the INSTCTB library.
FALSE Use this value if DUAL=N (the default value) in the
respective DEF* member in the INSTCTB library.
Note If you are using CONTROL-B Release 5.0.x, ensure that wishes WB0502 and WB0506
are applied at your site.
// EXEC IOADBF,FUNC=INIT,D=INSTCTB,M=DEFxxxD allocate new file
// EXEC CTBDBCP,DBFILE=xxx,OLDQNAME=qname,KEY=KEYyyy copy old contents
Valid values for xxx and yyy are:
File Type xxx yyy
Group GRP GRP
Database Variable MOD DBM
Variable Generation VAR DBV
Report REP REP
Rule Activity JAF JAFJ
Return Codes
0 Copy operation performed successfully
other Descriptive execution error, copy operation failed
Procedure CTBDBCP
Member CTBDBCP of the IOA PROCLIB library contains a procedure which calls a series
of programs to automatically enlarge a database file. This explanation assumes that the
name of the file which needs to be enlarged is ...GRPD. Before using this procedure,
perform the following steps:
1. Rename the source input file from ...GRPD... to ...GRPD...OLD. For example, rename
file CTBT.V514.GRPD.E000 to CTBT.V514.GRPD.E000.OLD
2. If DUAL=Y in member DEFGRPD in the INSTCTB library, ensure that fix BB0731 is
applied at your site and rename file CTB.V514.GRPD.D000 to CTB.V514.GRPD.D000.OLD.
3. Modify member DEFGRPD in the INSTCTB library by increasing the space allocated for the file.
4. Run the job in member CREFGRP of the INSTCTB library.
When the procedure described above is called, the following actions are performed:
1. Program IOADBF formats a new preallocated IOA Access Method output file.
2. Program CTBDBCP copies data from the input file to the output file.
3. Program IOADIG verifies the integrity of the output file data component.
4. Program IOADBF reformats the existing index component for the file.
5. Program IOADIB rebuilds the index component.
6. Program IOADPT prints index and data component control records to the output file.
Refer to sample member JDBCP in the JCL library for additional information.
CTBDBIB Rebuild a CONTROL-B Index File
Utility CTBDBIB rebuilds index files for various CONTROL-B data files. The new index
files correspond to information contained in the data files.
This utility rebuilds the indexes of a specific data file. Previous contents of the index file
are erased.
Note The index file that is to be rebuilt must be allocated and formatted prior to activating
the utility.
This utility should be used:
When the space remaining for the existing index file is insufficient. In this case:
Delete the index file.
Redefine the index file with the required amount of space.
Format the index file with utility IOADBF.
Rebuild the index file with utility CTBDBIB.
In case of index file integrity problems: Index file integrity problems can be detected
using utility IOADII, described later in this section.
In case of data file integrity problems: Correct the data file and re-index it with utility
CTBDBIB to reproduce the corresponding index file.
Parameter
The following parameter can be specified in the EXEC statement which invokes the
CTBDBIB JCL procedure.
DBFILE Name of data file to be processed.
Note SYSIN parameters are provided in the KEYyyy members in the CONTROL-B PARM
library for your convenience. File name specifications are hard-coded (predefined) in
these members.
// EXEC CTBDBIB,DBFILE=xxxD
//SYSIN DD DSN=CTB.PROD.PARM(KEYyyy),DISP=SHR
//DAxxx DD DSN=CTB.PROD.xxxI,DISP=SHR
Valid values for xxx and yyy:
File Type xxx yyy
Group GRP GRP
Database Variable MOD DBM
Variable Generation VAR DBV
Report REP REP
Rule Activity JAF JAFJ
Return Codes
Example
// EXEC CTBDBIB,DBFILE=GRPD
//SYSIN DD DSN=CTB.PROD.PARM(KEYGRP),DISP=SHR
//DAGRP DD DSN=CTB.PROD.GRPI,DISP=SHR
Utility CTBDBIB is used by the following jobs in the JCL library. Refer to these jobs for
additional examples:
JOBBDBM Rebuilds the index of the Database Variable Basic file.
JOBBDBV Rebuilds the index of the Generation file.
JOBBGRP Rebuilds the index of the Group file.
JOBBJAF Rebuilds the index of the Rule Activity file.
JOBBREP Rebuilds the index of the Report file.
CTBDBVCG Change Number of Variable Generations
This utility changes the maximum number of generations specified for one or more
Database Variables. It is useful whenever the number of generations must be changed but
is most often used when changing the status (mode) of variables from test to production.
The utility can be invoked in batch mode as described in Activating the Utility.
The number of generations to be retained in the database can be increased or decreased.
The content of existing variable generations can be retained or deleted. All other relevant
aspects of the variable(s) are retained, including definitions and group information.
It is possible to change the number of generations of all variables, groups of variables (with
a common group name prefix), or one or more variables of the same group (with a common
variable name prefix) in one activation of utility CTBDBVCG.
Parameters
CTBDBVCG JCL procedure. These parameters dynamically specify source (input) file
names and indicate whether the current content of existing generations should be retained
or deleted.
DIMOD Prefix of the third qualifier of the name of the source (input) Database
Variable Basic Data file.
DIVAR Prefix of the third qualifier of the name of the source (input) Database
Variable Generation Data file.
DIGRP Prefix of the third qualifier of the name of the source (input) Group
file.
COPY Y (Yes) Retain current contents of existing generations.
Default.
N (No) Delete current contents, if any, of existing
generations.
Parameters can also be supplied via DD statement SYSIN. The following parameters are
mandatory:
GROUP Group name (or prefix) of variables to be affected. A group name prefix
can be specified only if parameter VARIABLE contains an asterisk (*).
Example
GROUP=INV Variables of group INV are changed.
GROUP=INV* Variables of all groups that begin with INV (e.g.,
INV, INVENTORY, INVESTMENTS) are
changed.
To change the number of variables for all groups, the SYSIN input file
should be empty (and no GROUP or VARIABLE names should be specified).
Note Parameter GROUP can be specified only if an asterisk (*) is
specified in parameter VARIABLE.
VARIABLE Variable name (or prefix) of variable(s) whose number of generations
should be changed.
Examples
GROUP=INV
VARIABLE=TOT
Variable TOT of group INV is changed.
GROUP=INV TOT
VARIABLE=TOT*
Variables of group INV that begin with TOT (e.g., TOT, TOTAL,
TOT01, TOT02) are changed.
NUMGEN New number of generations to be specified for the variable. If not
specified, NUMGEN is set to the default number of generations in
System Variable SYSDBVARGENS.
// EXEC CTBDBVCG,DIMOD=mod,DIVAR=var,DIGRP=grp,COPY=YES|NO
//SYSIN DD *
GROUP=group
VARIABLE=variable
NUMGEN=new-maximum-#-of-generations
//
Return Codes
other Execution error, operation failed
Example
// EXEC CTBDBVCG,DIMOD=MGMT,DIVAR=ACTG,DIGRP=TAX,COPY=YES
//SYSIN DD *
GROUP=BONDS
VARIABLE=COST*
NUMGEN=24
//
CTBDBVCP Copy Variables or Groups to Another File
This utility copies the contents of specified group/variable files (i.e., data from source files)
to another set of group/variable files (i.e., target files). All relevant aspects of the variables
are copied, including definitions, generations and group information.
The sizes of the source and target files may differ. Therefore, utility CTBDBVCP is useful
for increasing the size of variable files. Usually, this utility copies variables from source
files to larger target files.
Copying variables is composed of the following stages:
Create and format a new set of group/variable files (target files).
Copy the data from the source files to the newly-created target group/variable files.
Delete the source files.
It is possible to copy all variables, groups of variables (with a common group name prefix),
or one or more variables of the same group (with a common variable name prefix) in one
activation of utility CTBDBVCP.
Parameters
CTBDBVCP JCL procedure. These parameters dynamically specify the prefix of the third
qualifier for the source and destination files listed below:
DIMOD Source (input) Database Variable Basic Data file.
DIVAR Source (input) Database Variable Generation Data file.
DIGRP Source (input) Group file.
Note At least one of the above parameters must be specified. For each input file specified, the
parameter (below) for the corresponding output file must also be specified.
DOMOD Destination (output) Database Variable Basic file.
DOVAR Destination (output) Database Variable Generation file.
DOGRP Destination (output) Group file.
REPLACE Flag which indicates whether or not the source variable should
overwrite an existing variable of the same name in the target.
Optional.
YES Target variable should be overwritten. Default.
NO Target variable should not be overwritten.
COPY Flag which indicates whether entire records or only variables should
be copied. Optional.
YES Copy entire records from the Group file.
NO Copy only variables. Default.
Parameters can also be supplied via DD statement SYSIN. Only one parameter can be
specified on each line.
GROUP Group name (or prefix) of variables to be copied. Mandatory. A group
name prefix can be specified only if parameter VARIABLE contains an
*.
Examples
GROUP=INV Variables of group INV are copied. Mandatory.
INV, INVENTORY, INVESTMENTS) are copied.
Note Parameter GROUP can be specified only if * is specified in
parameter VARIABLE.
VARIABLE Variable name (or prefix) to be copied.
Examples
GROUP=INV VARIABLE=TOT
Variable TOT of group INV is copied.
GROUP=INV VARIABLE=TOT*
Variables of group INV that begin with TOT (e.g.,
TOT, TOTAL, TOT01, TOT02) are copied.
NUMGEN Number of generations to be created for the variable during the copy.
If not specified, the number matches the source variables number of
generations. Do not specify more than the number of existing
generations.
FROMGEN Most recent generation to copy from the source to the target. If
FROMGEN is not specified, CONTROL-B begins copying with the
current (most recent) source generation.
TOGEN Oldest generation to copy from the source to the target. If TOGEN is
not specified, CONTROL-B. Copies successfully older generations until
the number of generations copied equals the existing value of TOGEN
FROMGEN + 1.
Example
GROUP=INV
VARIABLE=TOT
NUMGEN=20
FROMGEN=5
TOGEN=10
Assume the source variable has at least 10 generations.
The target variable can have a maximum of 20 generations. The first
six generations of the target variable will contain the values of the 5th
through 10th generations of the source variable.
// EXEC CTBDBVCP [DIMOD, DIVAR, DIGRP, DOMOD, DOVAR, DOTRP, REPLACE=YES|NO,
COPY=YES|NO]
Return Codes
0 Copy operation performed successfully
other Descriptive execution error, copy operation failed
Example
// EXEC CTBDBVCP,DIMOD=MOD,DIVAR=VAR,DIGRP=GRP,
// DOMOD=TARGMOD,DOVAR=TARGVAR,DOGRP=TARGGRP
//SYSIN DD *
GROUP=CURRENCY
VARIABLE=TOT*
//
Refer to sample member JOBDBVCP in the JCL library for additional information.
CTBDBVDL Delete Variables/Groups from Variable/Group
Files
Utility CTBDVBDL deletes specified records from CONTROL-B Database Variable files.
Mandatory.
Parameters
CTBDBVDL JCL procedure. These parameters provide dynamic specification of source and
destination file names:
DMOD Prefix of the third qualifier of the name of the Database Variable Basic file.
DVAR Prefix of the third qualifier of the name of the Database Variable
Generation file. Mandatory.
DGRP Prefix of the third qualifier of the name of the Group file. Mandatory.
DELGR Flag which indicates whether or not the entire group should be
deleted.
Y (Yes) Delete the entire group if no variables exist for this
group.
N (No) Do not delete the entire group. Default.
Parameters can also be supplied via DD statement SYSIN. Only one parameter can be
specified on each line.
GROUP Group name (or prefix) of variables to be deleted. A group name prefix
can be specified only if parameter VARIABLE contains an *.
Example
GROUP=INV Variables of group INV are deleted.
INV, INVENTORY, INVESTMENTS) are deleted.
Note GROUP=* cannot be specified.
VARIABLE Variable name (or prefix) to be deleted.
Note Parameter VARIABLE can be specified only if *' is not specified
for parameter GROUP.
Example
GROUP=INV VARIABLE=TOT
Variable TOT of group INV is deleted.
GROUP=INV VARIABLE=TOT*
Variables of group INV that begin with TOT (e.g., TOT,
TOTAL, TOT01, TOT02) are deleted.
// EXEC CTBDBVDL
Return Codes
Example
// EXEC CTBDBVDL,DMOD=MOD,DVAR=VAR,DGRP=GRP,DELGR=YES
//SYSIN DD *
GROUP=CURRENCY
VARIABLE=TOT*
//
Refer to sample member JOBDBVDL in the JCL library for additional information.
CTBDBVIG Check the Integrity of Variable/Group Files
Utility CTBDBVIG checks the integrity of the Database Variable Basic and Generation
files. The utility reports errors which are detected in the logical organization of these files.
Optionally, CTBDBVIG corrects errors that are detected. File integrity errors are listed in
the sysout of the job.
Parameter
CTBDBVIG JCL procedure:
ACT Flag which indicates whether or not integrity errors should be
corrected.
R Report errors, but do not correct them. Default.
W Report errors and correct them.
Notes Index file integrity is not checked. Therefore, after running utility CTBDBVIG, run jobs
JOBBDBM and JOBBDBV to rebuild the index files according to the corrected state of
the data file.
It is recommended that utility CTBDBVIG first be run without requesting corrections
(ACT=R) and that a backup copy of Database variable files be made before running
utility CTBDBFIG with ACT=W.
// EXEC CTBDBVIG DMOD=dmod,DVAR=dvar,DGRP=dgrp[,DELGR=YES|NO]
Return Codes
Example
// EXEC CTBDBVIG,ACT=R
CTBFRM Compress the Active Balancing File
Utility CTBFRM compresses the Active Balancing file. The utility usually runs as part of
the New Day procedure before potential missions are placed as entries in the Active
Balancing file. The utility can also be run as a stand-alone job using parameter FORCE=y.
The utility deletes entries from the Active Balancing file which will no longer be processed
by CONTROL-B. The Active Balancing file is then compressed.
A backup of the Active Balancing file is created automatically by this utility. The default
backup file name is ABFBKP.
Parameters
The following parameters are specified in the EXEC statement which invokes the CTBFRM
JCL procedure.
DBABFB=ABF Third qualifier of the Active Balancing file name. Mandatory.
DBBKPB=ABFBKP Third qualifier of Backup file name. Mandatory.
FORCE Indicates whether the utility is being run in stand-alone mode (forced)
or being invoked by the New Day procedure. Optional.
Y (Yes) The utility is being run in stand-alone mode without
checking dates in member CTBDATE in the CONTROL-B
PARM library.
N (No) The utility is being invoked by the CONTROL-B New Day
procedure. Default.
// EXEC CTBFRM,DATABFB=balfile,DTBBKPB=backup file,FORCE={Y|N}
Return Codes
Example
// EXEC CTBFRM,FORCE=N,DBABFB=ABF,DBBKPB=ABFBKP
Refer to sample member JOBFRM in the JCL library for additional information.
CTBJAFCP Copies Entries in Rule Activity/Report Files
Utility CTBJAFCP copies invocation and report entries to other Rule Activity and/or
Report files.
Parameters
FILE File to be copied. Mandatory.
JAF Only the Rule Activity file is copied.
REP Only the Report file is copied.
ALL Both the Rule Activity file and corresponding reports from
the Report file are copied.
CTBJAFCP JCL procedure:
DBJAFI Prefix of the third qualifier of the source (input) Rule Activity
file name.
DBREPI Prefix of the third qualifier of the source (input) Report file
name.
DBJAFO Prefix of the third qualifier of the destination (output) Rule
Activity file name.
DBREPO Prefix of the third qualifier of the destination (output) Report
file name.
INCLUDE/EXCLUDE Statements
INCLUDE/EXCLUDE statements are supplied via DD statement SYSIN. The suffix * is
permitted at the end of any of these parameters. * represents any number of characters
(including no characters).
The scope of the copy can be limited by one or more INCLUDE or EXCLUDE statements.
Each INCLUDE/EXCLUDE statement contains job name prefixes which limit the entries
which are copied. If one or more INCLUDE statements are specified, only entries specified
in the INCLUDE statements are copied. If one or more EXCLUDE statements are
specified, the entries specified in the EXCLUDE statements are not copied. There is an OR
relationship between multiple INCLUDE statements and between multiple EXCLUDE
statements.
Each INCLUDE/EXCLUDE statement must be listed on a separate line.
Parameter JOBNAME can be specified in INCLUDE/EXCLUDE statements. This
parameter represents the job name.
Note If the SYSIN file contains no INCLUDE/EXCLUDE statements, all records from the
source file are copied.
// EXEC CTBJAFCP FILE={JAF|REP|ALL}
//SYSIN DD *
//
Return Codes
8 Syntax error in the input parameters stream (SYSIN cards).
12 Insufficient memory to run the utility.
16 Unable to open a CONTROL-B Database file.
100+ Internal error.
108 ENQ of the Rule Activity and Report files failed. Run the utility again later.
Example
// EXEC CTBJAFCP,FILE=ALL,DBJAFI=JAF,DBREPI=REP,DBJAFO
=JAFNEW,DBREPO=REPNEW
//SYSIN DD *
INCLUDE JOB2*
EXCLUDE JOB22
EXCLUDE JOB23*
//
To copy the files, perform the following steps:
1. Allocate a new set of Rule Activity and Report files via utility CTBCRDF.
2. Copy the existing files, or a portion of these files (e.g., only relatively new invocations),
into the new files via utility CTBJAFCP.
3. Delete the old files.
4. Rename the new files to the names of the original files.
Refer to sample member JOBJAFCP in the JCL library for additional information.
CTBJAFDL Deletes Entries From Rule Activity/Report
Files
Utility CTBJAFDL cleans unnecessary entries from the Rule Activity file and/or the Report
file.
Parameters
CTBJAFDL JCL procedure:
DBJAFB Prefix of the third qualifier of the Rule Activity file name.
DBREPB Prefix of the third qualifier of the Report file name.
PRINT Flag which indicates whether or not deleted entries are printed.
PRINT Information about deleted entries is printed.
NOPRINT Information about deleted entries is not printed.
The following parameters are supplied via DD statement SYSIN. The suffix * is permitted
at the end of any of these parameters. * represents any number of characters (including no
characters).
DAYS n Number of days to retain entries in the Rule Activity file/Report file.
n cannot be a negative number. To delete all entries, specify DAYS=0.
Mandatory.
INCLUDE/EXCLUDE
The scope of the deletion can be limited by one or more INCLUDE or
EXCLUDE statements. Each INCLUDE/EXCLUDE statement
contains job name prefixes which limit the entries which are deleted.
If one or more INCLUDE statements are specified, only entries
specified in the INCLUDE statements are deleted. If one or more
EXCLUDE statements are specified, the entries specified in the
EXCLUDE statements are not deleted. There is an OR relationship
between multiple INCLUDE statements and between multiple
EXCLUDE statements.
Parameter JOBNAME can be specified in INCLUDE/EXCLUDE statements. This
parameter represents the job name.
Each INCLUDE/EXCLUDE statement must be listed on a separate line.
// EXEC CTBJAFDL
//SYSIN DD *
DAYS n
[INCLUDE {PARAMETERS}]
[EXCLUDE {PARAMETERS}]
//
Return Codes
104 ENQ of the Rule Activity and Report files failed. Run the utility again
later.
other Operation failed.
Example
// EXEC CTBJAFDL,DBJAFB=JAF,DBREPB=REP,PRINT=PRINT
//SYSIN DD *
DAYS 4
INCLUDE JOB2*
EXCLUDE JOB22
EXCLUDE JOB23*
//
CTBJAFIG Check the Integrity of Rule Activity/Report
Files
Utility CTBJAFIG checks the integrity of Rule Activity and Report files. The utility reports
errors detected in the logical organization of these files. If requested, utility CTBJAFIG
corrects the errors that are detected. File integrity errors are listed in the sysout of the job.
Parameters
CTBJAFIG JCL procedure:
FILE File to be checked/corrected. Mandatory.
JAF Rule Activity file. Default.
REP Report file.
BTH Both of the files (without logical links).
ALL Both the Job Activity and Report files (and their logical
links).
C Flag to indicate whether or not integrity errors should be corrected.
Optional.
Y (Yes) Correction is requested.
N (No) Correction is not requested. Default.
Notes Index file integrity is not checked. Therefore, after running utility
CTBJAFIG with option C=Y, run jobs JOBBJAF and JOBBREP to
rebuild the index files based on the corrected data file.
It is recommended that utility CTBJAFIG first be run without
requesting correction (C=N) and that a backup copy of the file(s) be
made before running utility CTBJAFIG with C=Y.
// EXEC CTBJAFIG FILE={JAF|REP|BTH|ALL}[C={Y|N}]
Return Codes
Example
// EXEC CTBJAFIG,FILE=ALL,C=N
Refer to sample member JOBJAFIG in the JCL library for additional information.
CTDBLXRP Rebuild Print Control Records in the Active
User File
Print control records are used by printing missions during the process of producing print
plans.
Utility CTDBLXRP deletes all existing print control records in the Active User Reports File
and rebuilds them. These records are rebuilt by scanning the Active User Reports file,
creating new print control records and inserting pointers to reports in WAIT PRINT status.
If reports which have WAIT PRINT status are not selected for printing.
If many CTD908S error messages with RC=16 are issued when a printing mission is
building a print plan.
This utility can be run in parallel with other CONTROL-D activities (decollation, printing,
online viewing, etc.).
Parameters
This utility has no parameters.
Utility CTDBLXRP is activated by the following EXEC statement:
// EXEC CTDBLXRP
Return Codes
8 Execution error
CTDCAMF Compress Active Missions File
This utility can compress the Active Missions file or change its size.
Message CTDF63W is issued if the Active Missions file is about to become full. Message
CTD533S is issued if the Active Missions file does become full. There are two solutions:
increase the size of the file or compress the file.
Utility CTDCAMF receives control parameters via DD statement DACOPPRM (or SYSIN).
The parameters designate the required function (compress or copy).
Note This utility cannot run simultaneously with the CONTROL-D monitor. Results will be
unpredictable if the monitor is not shut down. Online users can remain logged on.
Compressing the Active Missions File
The Active Missions file contains entries for jobs which are no longer required
(e.g., missions whose status is DELETED or ENDED OK). By removing the unneeded
entries from the file, utility CTDCAMF provides space for new entries.
//COMP EXEC CTDCAMF
COMPRESS
//
Refer to sample job CTDCAMF in the CONTROL-D JCL library for an example of how to
implement this utility.
Changing the Size of the Active Missions File
Note Online users should not access the Online facility while the size of the Active Missions
file is being changed.
Perform the following steps to change the size of the Active Missions file:
1. Change CONTROL-D installation parameter AMFSIZE in member CTDPARM to the
required new Active Missions file size. Assemble the CONTROL-D installation
parameters. From this point on, every access to the Active Missions file (online or
batch) will use the new size and may abend. Therefore, it is recommended to stop all
access to the Active Missions file until the process is complete.
2. Change parameter AMFSIZE in procedure CTDFRAMF to the new size of the Active
Missions file.
3. Run member FORMAMF in the IOA INSTCTD library. Change the dataset names so
you do not overwrite the existing Active Missions file and its backup file (e.g.,
parameter TYPE should be changed to NEWNAME).
4. Run utility CTDCAMF with the following parameters:
//EXEC CTDCAMF,
// OLDAMF=CTD.PROD.AMF, OLD ACTIVE MISSIONS FILE
// NEWAMF=CTD.PROD.NEWAMF NEW ACTIVE MISSIONS FILE
COPY
//
Utility CTDCAMF copies the current Active Missions file to the new Active Missions
file. The utility must terminate with a return code of 0.
5. Rename the old Active Missions file (and its backup file suffix AMB).
6. Rename the new Active Missions file (and its backup file suffix AMB) to the former
names of the old files.
7. Restart the CONTROL-D monitor and resume operation.
CTDCATF Compress Active Transfer File
This utility can compress the Active Transfer file or change its size.
If the Active Transfer file becomes full, there are two solutions: increase the size of the file
or compress the file.
Utility CTDCATF receives control parameters via the EXEC statement. The parameters
designate the required function (compress or copy).
Note This utility cannot run simultaneously with the CONTROL-D monitor. Results will be
unpredictable if the monitor is not shut down. Online users can remain logged on.
Compressing the Active Transfer File
The Active Transfer file often contains entries for packets which are no longer required
(e.g., packets whose status is DELETED or TRANSFERRED OK). By removing the
unneeded entries from the file, utility CTDCATF provides space for new entries.
Example
//COMP EXEC CTDCATF
//
Changing the Size of the Active Transfer File
Note It is highly recommended that online users do not access the Online facility while the
size of the Active Transfer file is being changed.
Perform the following steps to change the size of the Active Transfer file:
1. Change CONTROL-D installation parameter ATFBLK in member CTDPARM to the
required new Active Transfer file size. Assemble the CONTROL-D installation
parameters. After you do this, every access to the Active Transfer file (online or batch)
will use the new size and may abend. Therefore, it is recommended to stop all access to
the Active Transfer file until the process is complete.
2. Change parameter ATFSIZE in procedure CTDFRATF to the new size of the Active
Transfer file.
3. Run member FORMATF in the IOA INSTCTD library. Change the dataset names so
you will not overwrite the existing Active Transfer file and its backup file.
4. Run utility CTDCATF with the following parameters:
// EXEC CTDCATF,P=COPY,
// INATF=CTD.PROD.ATF, OLD ACTIVE TRANSFER FILE
// OUTATF=CTD.PROD.NEWATF NEW ACTIVE TRANSFER FILE
//
Utility CTDCATF copies the current Active Transfer file to the new Active Transfer
file. The utility must terminate with a return code of 0.
5. Rename the old Active Transfer file (and its backup file suffix ATB).
6. Rename the new Active Transfer file (and its backup file suffix ATB) to the former
names of the old files.
7. Restart the CONTROL-D monitor and resume operation.
CTDCA2P Copy Active User Report File to Permanent
This utility copies new user/report/job/category entries from the Active User Report List
file to the Permanent User Report List file. The Permanent User Report List file contains,
for each user, a list of all the reports which he/she can receive at any point in time. When a
new report is defined, or when a user becomes a report recipient (e.g., because of new data
from the application), this information is placed in the Active User Report List file after
decollation.
This utility copies new entries from the Active User Report List file to the Permanent User
Report List file. In this way, the list of reports which the user can get is maintained
automatically.
It is recommended that utility CTDCA2P be run on a daily basis. See Permanent User
Report List File in Section 4 of this guide.
Each INCLUDE/EXCLUDE statement contains parameters which limit the user/report list
entries which will be copied. See Record Selection Logic (INCLUDE/EXCLUDE
Statements) under CONTROL-T Utilities in this section for information about prefixing,
masking and the INCLUDE and EXCLUDE logic used to determine record selection.
Parameters in INCLUDE/EXCLUDE Statements
The parameters which can be specified in INCLUDE/EXCLUDE statements:
JOBNAME Job name
USER User name
REPNAME Report name
CATEGORY Category name
// EXEC CTDCA2P
[INCLUDE {parameters}]
[EXCLUDE {parameters}]
The new report entries are assigned the current CONTROL-D working date (not the
computer system date).
This utility can be run simultaneously with the CONTROL-D monitor.
Return Codes
8 I/O error, execution stopped
Example 1
// EXEC CTDCA2P
INCLUDE REPNAME=PROD-JCL
The following is the status of the files before the utility is run:
Active User Report List File
--USER-- -------REPORT------- ---JOB-- ----CATEGORY----
ACCTSRCV ACCOUNTS-RECEIV-REPT D4ACCRCV QUARTERLY
ACCTSRCV ACCOUNTS-RECEIV-REPT D4ACCRCV WEEKLY
BRANCH01 DAILY-BALANCE-REPORT D4DAILYB DAILY
BRANCH02 DAILY-BALANCE-REPORT D4DAILYB MONTHLY
Permanent User Report List File
The following is the status of the Permanent User Report List file after the utility is run:
--USER-- -------REPORT------- --JOB-- ----CATEGORY----
ACCTSRCV ACCOUNTS-RECEIV-REPT D4ACCRCV QUARTERLY
1
ACCTSRCV ACCOUNTS-RECEIV-REPT D4ACCRCV WEEKLY
1
2
BRANCH02 DAILY-BALANCE-REPORT D4DAILYB MONTHLY2
2
3
1
These entries were copied from the Active User Report List file since they did not exist on the Permanent
User Report List file.
2
These entries were not copied from the Active User Report List file since they already existed in the
Permanent User Report List file.
3
This entry was not modified.
CTDCCU Delete Unneeded CDAM Files
This utility identifies CDAM files not referenced by the Active User Report List file (by the
SYSDATA entries) and optionally deletes them.
CDAM files created using JCL parameter SUBSYS are not always decollated. In these
cases, CTDDELRP does not delete these CDAM files since they are not referenced by the
Active User Report List file (ACTUSR). This utility identifies/deletes these CDAM files.
Parameters
DATE Date range for selecting CDAM files. Format: fromdate todate.
fromdate is mandatory; todate is optional.
Date is in format mmddyy, ddmmyy or yymmdd, depending on the
site standard. todate must not exceed the run date minus one. If
todate is not specified, it defaults to the specified fromdate.
PREFIX CDAM prefix. At least one PREFIX command is required. Multiple
PREFIX commands are supported. Maximum length: 17 characters.
SIMULATION Whether or not CDAM files should be deleted during the run of the
utility.
YES Report on CDAM files to be deleted. Do not perform the
deletion. Default.
NO Report on CDAM files to be deleted. Perform the
deletion.
Note It is recommended that utility CTDCCU be run first in
simulation mode to verify that only the correct files are to be
deleted.
VERIFY-IN-HISTORY Whether or not the History User Report file should be searched for
references to CDAM files not in the Active User Report List file.
YES Search the History User Report List file for references
to CDAM files not in the Active User file. Issue a
message that indicates whether or not such references
were found. This parameter does not influence the
identification of the CDAM files to be deleted.NO
Do not search the History User Report List file.
Default.
// EXEC CTDCCU
DATE=fromdate [- todate]
PREFIX=prefix
[SIMULATION={YES|NO}]
[VERIFY-IN-HISTORY={YES|NO}]
Example 1
// EXEC CTDCCU
DATE=082198-083098
PREFIX=CTDRSV
In this example, CDAM files satisfying all of the following criteria are listed in the report
but not deleted:
Prefixed CTDRSV.
Created August 21 30, 1998 (mmddyy format).
Not referenced by the Active User Report List file.
Still on disk.
Example 2
// EXEC CTDCCU
DATE=210898-300898
PREFIX=CTDRSV
PREFIX=CTDALL
SIMULATION=NO
VERIFY-IN-HISTORY=YES
In this example, CDAM files satisfying all of the following criteria are deleted:
Prefixed by CTDRSV or CTDALL.
Created 21 30 August 1998 (ddmmyy format).
Not referenced by the Active User Report List file.
Still on disk.
Deleted CDAM files are checked against the History User Report List file. The report
indicates whether or not the deleted CDAM files are referenced in the History User Report
List file.
CTDCLHIS Clean History User Report List File
This utility cleans entries from the History User Report List file. The History User Report List file
contains entries describing backed up user reports. Each report has a retention period. The utility
scans the History User Report List file for all the reports whose retention period has passed (i.e.,
the backup is no longer needed) and deletes them.
This utility produces a list of all tapes which are no longer needed and can therefore be
returned to the global tape pool.
MODE Parameter
This optional parameter in the EXEC Statement determines whether utility CTDCLHIS is
run in Production mode or Simulation (Test) mode. If the parameter is not specified, the
default is Production mode. It is recommended that this utility be run in Simulation mode
prior to being run in Production mode.
PROD The utility runs in Production mode, deleting report entries which
satisfy the requirements specified by other parameters. Default.
TEST The utility runs in Simulation mode, performing analysis and
reporting but not changing or deleting any files.
NOSYS Parameter
This optional parameter in the EXEC statement determines whether utility CTDCLHIS
checks for orphan User records; i.e., User records which do not have corresponding
SYSDATA records.
When parameter NOSYS is not specified or set to Y (Yes), utility CTDCLHIS checks for
orphan entries and issues a message for each one found. Default.
When parameter NOSYS is set to N (No), the utility does not check for orphan entries.
However, the performance of the utility is substantially improved.
// EXEC CTDCLHIS [MODE=TEST|PROD,NOSYS=Y|N]
Return Codes
4 Operation performed successfully (for HSM backup utility)
8 Execution error
11 Operation performed successfully (in TEST mode)
12 Invalid input parameters
CTDCP2A Copy Permanent User Report File to Active
This utility copies job/user/report/category entries from the Permanent User Report List
file to the Active User Report List file. This process is performed once a day to create new
empty entries (in WAIT DECOLLATION status) for each job/user/report/category/odate
(original scheduling date).
Any job/user/report/category/odate entries which are already present on the Active User
Report List file are not copied (i.e., are not duplicated).
Each INCLUDE/EXCLUDE statement contains parameters which limit the user/report list
entries which will be copied. See Record Selection Logic (INCLUDE/EXCLUDE
Statements) under CONTROL-T Utilities in this section for information about prefixing,
masking and the INCLUDE and EXCLUDE logic used to determine record selection.
JOBNAME Job name
USER User name
REPNAME Report name
CATEGORY Category name
// EXEC CTDCP2A
[INCLUDE {PARAMETERS}]
[EXCLUDE {PARAMETERS}]
The new report entries are assigned the current CONTROL-D working date (not the
computer system date). It is possible to specify a specific date via parameter PARM=date
(format mmddyy, ddmmyy or yymmdd, depending on the site standard).
The utility can be run simultaneously with the CONTROL-D monitor.
Return Codes
8 I/O error, execution stopped
Example
// EXEC CTDCP2A,PARM=date
The following is the status of the files before the utility is run:
Permanent User Report List file
Active User Report List file
--USER-- -------REPORT------- ---JOB-- ----CATEGORY---- -ODATE-
ACCTSRCV ACCOUNTS-RECEIV-REPT D4ACCRCV QUARTERLY 070798
ACCTSRCV ACCOUNTS-RECEIV-REPT D4ACCRCV WEEKLY 070798
BRANCH01 DAILY-BALANCE-REPORT D4DAILYB DAILY 070798
BRANCH02 DAILY-BALANCE-REPORT D4DAILYB MONTHLY 070798
The following is the status of the Active User Report List file after the utility is run on the
7
th
of July:
--USER-- -------REPORT------- ---JOB-- ----CATEGORY---- -ODATE-
ACCTSRCV ACCOUNTS-RECEIV-REPT D4ACCRCV QUARTERLY 070798
ACCTSRCV ACCOUNTS-RECEIV-REPT D4ACCRCV WEEKLY 070798
CTDDELRP Delete Reports Which Are Not Needed
This utility cleans unneeded user/report/job entries from the Active User Report List file
and erases from the disk compressed (CDAM) datasets which have no entries in the Active
User Report List file.
This utility also moves a report entry from the Active to the History User Report List file
or the Migrated User Report List file when the DASD retention period for that report has
expired and the report has been backed up or migrated successfully.
The utility determines which reports are no longer needed (i.e., for backup, migration,
Online viewing, or printing) by means of user-specified selection groups. A selection group
consists of a DAYS statement and any number of optional INCLUDE and/or EXCLUDE
statements. The DAYS statement must contain a retention period which specifies the
number of days the reports should remain online, after which they should be deleted by the
utility. The optional INCLUDE/EXCLUDE statements further qualify which reports belong
to the selection group.
By specifying multiple selection groups, each with its own retention period (and
INCLUDE/EXCLUDE statements), groups of entries with differing retention periods can
be deleted by a single execution of CTDDELRP. See Record Selection Logic
(INCLUDE/EXCLUDE Statements) under CONTROL-T Utilities in this section for
information about prefixing, masking and the INCLUDE and EXCLUDE logic used to
determine record selection.
Selection groups are scanned sequentially. The processing of a report is determined by the
first selection group whose INCLUDE or EXCLUDE criteria match the report.
INCLUDE/EXCLUDE criteria in other selection groups are ignored for that report.
Utility CTDDELRP performs the following steps:
1. Records to be deleted from the Active User Report List file are selected (according to
the parameters specified for the utility) and written to a temporary file.
Records for reports which have been backed up are written to the History User Report
List file.
CDAM files to be deleted are written to an intermediate file.
2. The temporary file is read and the records it contains are deleted from the Active User
Report List file.
3. CDAM files stored in the intermediate file (in Step 1) are deleted.
Parameters
MODE This optional parameter in the EXEC statement determines whether
utility CTDDELRP is run in Production mode or Simulation mode. If
the parameter is not specified, the default is Production mode. It is
recommended that this utility be run in Simulation mode prior to
being run in Production mode.
PROD The utility runs in Production mode, changing and
deleting report entries and CDAM files which satisfy
the requirements specified by other parameters.
Default.
TEST The utility runs in Simulation mode, performing
analysis and reporting but not changing or deleting any
files.
DAYS Statement
The DAYS statement can contain the following parameters:
n Retention period (in days), after which the report expires and is
selected for deletion from the Active User Report List file by the
selection group. This parameter must be the first parameter in the
statement. Mandatory
By default, the report expires n days from the original scheduling date
(ODATE) of the report decollating mission. The IOA administrator can
change the default so that n is calculated from the decollation date.
Refer to optional wish WD1377 in member IOADFLTC of the MAC
library.
n can be a negative number (to delete reports created on future
ODATEs) and cannot exceed 9999.
FORCE When not specified, reports with WAIT BACKUP status are not
deleted. Optionally, reports waiting backup are also deleted.
WAITPRINT Optionally, reports with WAIT PRINT status are not deleted. If not
specified, reports waiting to be printed are also deleted.
WAITDEC/NOTWD
WAITDEC deletes only reports having Wait Decollation status.
NOTWD excludes from the selection group reports having Wait
Decollation status. If neither parameter is specified, Wait Decollation
status does not affect report deletion. Both parameters cannot be
specified in the same selection group.
RESTORED/NOTRST
RESTORED deletes only reports having Restored status. NOTRST
excludes from the selection group reports having Restored status. If
neither parameter is specified, Restored status does not affect report
deletion. Both parameters cannot be specified in the same selection
group.
Note Parameters FORCE, WAITPRINT, WAITDEC, NOTWD, RESTORED and NOTRST
apply only to the specific selection group in which they appear. They can be specified
for as many selection groups as necessary.
NOREPORT Deletes any SYSDATA entries and their CDAM datasets (original reports
data) if the SYSDATA is not pointed to by any user entries (e.g., the user
entries have been manually deleted), regardless of the retention value
specified in the DAYS parameter and all other selection group parameters.
KEEPDSN Deletes reports from the Active User Report List file but does not
delete CDAM datasets. The CDAM datasets can then be re-decollated.
NOINDEX Prevents migrated indexes from being deleted from DASD by utility
CTDDELRP (when a report is deleted and its control records are
moved to the Migrated User file), even if the indexes are defined as
non-resident. This parameter is valid only for CONTROL-V.
This parameter is designed to retain nonresident indexes on DASD for
an indefinite period of time after the report has migrated. These
indexes can be deleted by utility CTVDELI at any time.
Note Parameters NOREPORT, KEEPDSN and NOINDEX apply to all selection groups
regardless of the criteria specified for them.
STORED/ NOTSTOR
STORED deletes only those reports created by a printing mission with
a value of Y in field STORE. NOTSTOR excludes from the selection
group reports created by a printing mission with a value of Y in field
STORE. If neither parameter is specified, reports created by a
printing mission with a value of Y in field STORE do not affect report
deletion. Both parameters cannot be specified in the same selection
group.
Each INCLUDE/EXCLUDE statement must be specified on a separate line.
Multiple INCLUDE/EXCLUDE statements can be specified. Each statement can contain
any or all of the parameters listed below separated by a space. However, each parameter
can appear no more than once in each statement.
See Record Selection Logic (INCLUDE/EXCLUDE Statements) in CONTROL-T Utilities
in this section for more information about INCLUDE and EXCLUDE statements.
General Parameters in INCLUDE/EXCLUDE Statements
Each INCLUDE/EXCLUDE statement must contain at least one of the following parameters:
JOBNAME Job name (or prefix).
JOBID Job ID (format Jnnnnn).
USER User name (or prefix).
CLASS Class.
REPNAME Report name (or prefix). If the report name contains embedded spaces,
replace each embedded space with the @ character.
CATEGORY Category of report decollation mission.
By default, the values specified for JOBNAME, USER and REPNAME are treated as
prefixes. To prevent a value from being considered a prefix, place the special character <
after the value.
CDAM Dataset Parameters in INCLUDE/EXCLUDE Statements
The following additional parameters can be specified for CDAM datasets created directly
via job JCL SUBSYS parameters:
PGMSTEP Program step name (which created the report).
PROCSTEP Procedure step name (which created the report).
DDNAME DD name (which created the report).
Notes PGMSTEP refers to the step name specified in a //STEP01
EXEC PGM=pgmname statement.
PROCSTEP refers to the step name specified in a //UPB01
EXEC procname statement which invokes a procedure.
CTDDELRP Deletion Rules
CONTROL-D/V reports are identified by user entries, SYSDATA entries and CDAM
compressed datasets. Each user entry can point to one or more SYSDATA entries. Each
SYSDATA entry points to one CDAM dataset and is pointed to by one or more user entries.
Each CDAM dataset is pointed to by one or more SYSDATA entries.
When deleting reports, CTDDELRP maintains the integrity of this data structure
according to the following rules:
A CDAM compressed dataset is deleted when all SYSDATA entries pointing to it are deleted.
A SYSDATA entry is deleted when all user entries pointing to it are selected for deletion.
A user entry is deleted when all SYSDATA entries it points to are selected for deletion.
A user entry is also deleted when all SYSDATA entries to which it points do not exist
(i.e., the SYSDATA entries were deleted via the CONTROL-D/V Online facility).
CTDDELRP issues a message if it finds a SYSDATA entry which is not pointed to by any
user entry (i.e., the user entries were deleted via the CONTROL-D/V Online facility). If
parameter NOREPORT was specified, this SYSDATA entry is automatically deleted.
// EXEC CTDDELRP[,MODE=TEST|PROD]
//SYSIN DD *
DAYS n [FORCE] [WAITPRINT] [WAITDE|NOTWD] [RESTORED|NOTRST][NOREPORT]
[KEEPDSN]
[INCLUDE [JOBNAME=Job name] [JOBID=jobid] [USER=user] [CLASS=class]
[REPNAME=repname] [PGMSTEP=pgmstep] [PROCSTEP=procstep]
[DDNAME=ddname]
.
.
.
[EXCLUDE [JOBNAME=Job name] [JOBID=jobid] [USER=user] [CLASS=class]
[REPNAME=repname] [PGMSTEP=pgmstep] [PROCSTEP=procstep]
[DDNAME=ddname]
.
.
.
[
DAYS statement
[INCLUDE statement]
.
.
.
[EXCLUDE statement]
.
.
]
Examples
Example 1
//S1 EXEC CTDDELRP
DAYS 3
The utility deletes reports which are older than three days if they have been backed up and
have either WAIT PRINT or PRINTED status.
Example 2
//S1 EXEC CTDDELRP
DAYS 0 WAITPRINT
A disk space saver. All reports that were backed up and printed are deleted. Reports
waiting for migration, print and/or backup are not deleted.
Example 3
//S1 EXEC CTDDELRP
DAYS 5
All reports with name prefix PROD-JCL which are more than five days old are deleted
unless they have not yet been backed up.
Example 4
//S1 EXEC CTDDELRP
DAYS 0 FORCE
INCLUDE JOBNAME=Y99BUP01 JOBID=J01923
All reports of the specified job name and job ID are deleted, regardless of WAIT
BACKUP/WAIT PRINT status.
Example 5
Assume the following report names exist: ACCT, ACCT-REC, ACCT-PAY.
//S1 EXEC CTDDELRP
DAYS 0
INCLUDE REPNAME=ACCT*
All of the above reports are deleted.
//S1 EXEC CTDDELRP
DAYS 0
INCLUDE REPNAME=ACCT<
Only report ACCT is deleted.
Example 6
//S1 EXEC CTDDELRP
DAYS 0 WAITPRINT
EXCLUDE REPNAME=PROD-JCL
EXCLUDE CLASS=X
EXCLUDE JOBNAME=P00*
All reports which have already been migrated, printed and backed up (if backup was
requested) are deleted from DASD, except:
Production JCL reports.
Reports produced on output Class X.
Reports produced by jobs with names beginning P00.
Example 7
//S1 EXEC CTDDELRP
DAYS 7 WAITPRINT
INCLUDE JOBNAME=PROD*
DAYS 3 FORCE
INCLUDE JOBNAME=TEST*
Reports older than seven days and created by jobs with names beginning PROD are deleted
except reports waiting for print. Reports older than three days and created by jobs with
names beginning TEST are deleted, regardless of WAIT BACKUP/WAIT PRINT status.
Example 8
//S1 EXEC CTDDELRP
DAYS 3 WAITPRINT RESTORED
DAYS 1 WAITDEC
DAYS 10 WAITPRINT NOT RST NOT WD
DAYS 0
INCLUDE USER=SCRAP
Reports that were restored at least three days ago are deleted except reports still waiting
for print.
Report entries with a status of WAIT DECOLLATION (created via utility CTDCP2A) that
are older than one day are deleted.
Reports older than ten days with neither RESTORE nor WAIT DECOLLATION status and
which already printed are deleted.
Report entries belonging to user name SCRAP are deleted.
Example 9
//S1 EXEC CTDDELRP
DAYS 4 NOREPORT
Reports which are older than four days will be deleted.
Reports which have only a SYSDATA record (no user record points to them) will be deleted,
even if the SYSDATA record is one day old.
Example 10
//S1 EXEC CTDDELRP
DAYS 30
INCLUDE JOBNAME=PROD*
INCLUDE JOBNAME=FIRST*
DAYS 15 WAITPRINT
INCLUDE JOBNAME=TEST*
DAYS 5 FORCE
EXCLUDE JOBNAME=PROD*
EXCLUDE JOBNAME=FIRST*
EXCLUDE JOBNAME=TEST*
Reports older than 30 days and created by jobs with names beginning PROD or FIRST are
deleted unless they have not been backed up yet. Reports which have been printed, backed
up and migrated, older than 15 days and created by jobs with names beginning TEST are
deleted. All other reports older than 5 days are deleted.
Note This utility is fully recoverable. If an abend occurs at any step of the utility, fix the
problem and rerun the utility from the first step.
CTDDIB Rebuild Index Component of a User Report List
File
Utility CTDDIB is used to rebuild a CONTROL-D User Report List files index component.
The new index component corresponds to information currently contained in the IOA
Access Method files data component. Previous contents of the index component are erased.
Note The index component that is to be rebuilt must be allocated and formatted prior to
activating the utility.
This utility should be used when an integrity problem is detected in an IOA Access Method
files index component. In this case:
Delete and reallocate the index component.
Format the index component with utility IOADBF.
Rebuild the index component with utility CTDDIB.
//BUILD EXEC CTDDIB, DBFILE={ACT|PRM|HST|MIG}
Parameters
The following parameter can be specified to the utility in the EXEC statement which
invokes the CTDDIB JCL procedure.
DBFILE CONTROL-D IOA Access Method files dataset name suffix.
ACT Active User Report List file.
PRM Permanent User Report List file.
HST History User Report List file.
MIG Migrated User Report List file (CONTROL-V only).
Example
//BUILD EXEC CTDDIB,DBFILE=HST
Refer to sample job CTDUFDIB in the CONTROL-D JCL library for an example of how to
rebuild a IOA Access Method file index component.
CTDDIG User Report List File Integrity Check
Utility CTDDIG checks the integrity of the User Report List Files (i.e., Active, Permanent,
History and Migration Report List files) by comparing the data and index components of
these files. Optionally, detected errors can be corrected. This utility can detect and correct
the following types of errors:
More than one data record exists with the same key.
A data record exists without a corresponding index record.
An index record exists without a corresponding data record.
A data record and its corresponding index record do not have the same update
timestamp.
Utility CTDDIG is executed in two sequential stages:
Stage 1 Information is read from the specified User Report List file.
Stage 2 Integrity is checked and (optionally) corrupted records are repaired.
This utility can be run while CONTROL-D and the Online monitor(s) are active. However,
it locks the specified User Report List file so that other applications cannot modify it.
If MODE=TEST, the specified file is locked during only Stage 1.
If MODE=CHANGE, the specified file is locked during both Stage 1 and Stage 2.
It is recommended to run this utility in TEST mode before running it in CHANGE mode.
Parameters
CTDDIG JCL procedure:
DBFILE File to be checked. Mandatory. Valid values:
PRM Permanent User Report List file.
MIG Migration User Report List file.
MODE Mode in which the utility is run. Optional. Valid values:
TEST Messages are issued about detected problems but errors
are not fixed. Default.
CHANGE Messages are issued and errors are fixed.
// EXEC CTDDIG,DBFILE={ACT|PRM|HST|MIG}[,MODE=TEST|CHANGE]
JCL for executing this utility is in member CTDUFDIG in the CONTROL-D JCL library.
CTDULD User File Report List Load
Utility CTDULD copies records from a sequential file to the current User Report List File
(i.e., an Active, Permanent, History or Migrated User Report List file). This utility can be
run simultaneously with other applications (e.g., the CONTROL-D or CONTROL-V Online
facility) which use the specified file. It is not necessary to close the CONTROL-D or Online
monitor(s) when this utility is run.
Utilities IOADLD (Load IOA Access Method File Contents) and CTDDIB (Rebuild Index
Component of a User Report List File) can be used for the same purpose but cannot be run
simultaneously with other applications which use the specified file.
Parameters
The following parameters are specified in the EXEC statement which invokes the CTDULD
JCL procedure:
DBFILE File to be updated. Mandatory. Valid values:
ACT Active User Report file.
PRM Permanent User Report file.
HST History User Report file.
MIG Migration file.
SEQ Name of the sequential input file. Mandatory.
REPLACE Indicates whether or not existing records with the same key should be
replaced. Optional. Valid values:
Y (Yes) Replace existing records that have the same key.
N (No) Do not replace existing records. Input records with the
same key are rejected. Default.
// EXEC CTDULD,DBFILE=ACT|PRM|HST|MIG,SEQ=input-file[,REPLACE=Y|N]
Member CTDUFLD of the CONTROL-D JCL library contains a sample job for using this
utility.
CTDUPBKP Update Backup/Migration Details
This utility is primarily used to update retention period and backup volume serial numbers
in History/Migration/Active User Report List files.
This utility can also be used to switch PRIMARY and SECONDARY information in the
Migrated User Report List file.
The utility receives the following groups of parameters:
Selection parameters
CHANGETO parameters
Report parameters
The utility scans the file(s) that are specified via the Selection parameters and modifies the
specified records in those files according to the CHANGETO parameters. Report
parameters specify characteristics of the report to be produced.
//UPDATE EXEC CTDUPBKP
//DAUIN DD *
SELECT
[FILE=ACT]
[FILE=HST]
[FILE=MIG]
[JOBNAME=jobname]
[JOBID=jobid]
[DECFROM=ddmmyy,hhmmss]
[DECTO=ddmmyy,hhmmss]
[BKPFROM=ddmmyy,hhmmss]
[BKPTO=ddmmyy,hhmmss]
[BKPMIS=backup migration mission name]
[PLATTER=platter name]
[VOLSER=old volser]
[SIMULATE=YES/NO]
CHANGE TO
[GENER=number of generation|NONE]
[RETPD=retention period]
[VOLSER=new volser]
[SECONDARY|PRIMARY]
NEWBKP=new=backup-mission
NEWMIG=new=migrat-mission
/*
//DAULST DD *
[PRINTSYS]
[DETAIL]
[UNMATCH=ALL|VOLSER]
/*
//
Selection Parameters
The following parameters can be specified in the SELECT statement:
FILE Type of file to be acted upon. Specify at least one of the following three files:
MIG Migration User Report List file.
Mandatory.
JOBNAME Name of the job which produced the reports. Optional.
JOBID Job ID (maximum: 5 digits) of the job which produced the report.
Optional.
DECFROM Earliest decollation date and time of reports to be selected for update.
Format: date, time. Both parameters are optional, but time cannot be
specified without specifying date.
Date format is mmddyy, ddmmyy or yymmdd (depending on the site
standard defined in installation member IOAPARM).
Time format is hhmmss.
DECTO Latest decollation date and time of reports to be selected for update.
BKPFROM Earliest backup date and time of reports to be selected for update.
Time format is hhmmss.{ XE BKPFROM Parameter:Utility
CTDUPBKP }
BKPTO Latest backup date and time of reports to be selected for update.
BKPMIS Backup/migration mission name. Validity checks are identical to those
of DO BACKUP or DO MIGRATE in the decollation mission definition.
Optional.
VOLSER Volume serial number (maximum 6 characters) to be updated. A
maximum of 10 volume serial numbers can be specified. Optional.
Example: 444444, 555555, 666666.
PLATTER Platter name.(maximum: 9 characters.) This parameter is used as a
selection parameter for migration files and can be specified for Kodak
OptiStar Storage System (OSS) only.
SIMULATE Y (Yes) Files are not updated. Only a report of all records to be
updated is produced. Default.
N (No) Files are actually updated.
CHANGETO Parameters
The following parameters can be specified in the CHANGETO area:
GENER Number of generations. Valid values:
nnnn Valid numeric value greater than zero.
Only parameters FILE=HST and BKPMIS=bkpname can
be defined in the SELECT area.
Parameter RETPD must not be defined in the CHANGETO
area. Reports belonging to the Backup mission are
switched from DAYS TO KEEP method to the
GENERATIONS TO KEEP method. The value of DAYS
TO KEEP is automatically set to 0000. If there is no
corresponding Backup control record in the History file,
this utility creates it.
NONE Parameter RETPD must be defined in the CHANGETO
area.
Reports belonging to the Backup mission are switched
from GENERATIONS TO KEEP method to the DAYS
TO KEEP method.
RETPD Four-digit value identical to the # DAYS TO KEEP value in the
Backup mission.
If this parameter is specified without specifying parameter GENER, #
definition GENERATIONS TO KEEP must be 0 in the corresponding
Backup control record in the History Report List file. Otherwise,
utility CTDUPBKP produces an error message.
VOLSER A new volume serial number (maximum 6 characters) for the volume
be updated. A maximum of 10 volsers can be specified (e.g., 111111,
222222, 333333). The number of volsers specified must be identical to
the number of volsers specified in the SELECT area (described above).
PRIMARY If utility CTDUPBKP was previously run with parameter
SECONDARY specified, running this utility again with parameter
PRIMARY causes the primary migrated copy of CDAM and index files
to be used when accessing the migrated report. FILE=MIG must be
specified in the SELECT area.
SECONDARY If utility CTDUPBKP is run with parameter SECONDARY specified,
the secondary migrated copy of CDAM and index files will be used
when accessing the migrated report. FILE=MIG must be specified in
the SELECT area. If there is no secondary migration information, in
SYSDATA or the index record, this parameter is ignored.
Note Parameters PRIMARY and SECONDARY are relevant if a value
was specified for parameter SECONDARY was specified in the
Migration Mission Definition screen.
Report Parameters
By default the utility produces a report for all the SYSDATA records which were selected
according to the SELECTion parameters. The report contains the most up-to-date backup
information in these SYSDATA records. Additional reports are available by specifying the
following parameters in DD statement DAULST:
UNMATCH Produce a report listing all volsers in the file(s) that did not match any
of the old volsers defined in the input file referenced by DD statement
DAUIN.
ALL Produces this report in any case.
VOLSER Produces a report only if volser update was requested.
PRINTSYS Produce a report detailing all SYSDATA records.
If parameter VOLSER is specified in the CHANGETO area, a report can be produced
containing a list of old and new VOLSERs. This report is produced if parameter DETAIL is
specified in the Report parameters.
DETAIL Print a detailed report for all volsers found in the file(s), including the
backup job name, date and time. This report is available only when a
new volser is requested. This report replaces the default report.
Note If parameter DETAIL is specified without specifying parameter VOLSER in the
CHANGETO area, then the default report will also not be produced.
Example 1
//DAUIN DD *
SELECT
FILE=HST
DECFROM=250698,1000
DECTO=270698,1500
BKPFROM=260698,1000
BKPTO=280698,1500
BKPMIS=BKP001
SIMULATE=YES
CHANGETO
/*
//DAULST DD *
//
The utility creates a report for the History file. Every SYSDATA which was created from
25/06/98 at 10 a.m. until 27/06/98 at 3 p.m. and was backed up from 26/06/98 at 10 a.m.
until 28/06/98 at 3 p.m. by backup mission BKP001 is printed in this report.
Example 2
//UDPATE EXEC CTDUPBKP
//DAUIN DD *
SELECT
FILE=ACT
FILE=HST
BKPFROM=260698,1000
BKPTO=280698,1500
BKPMIS=BKP001
VOLSER=VOL001
SIMULATE=NO
CHANGETO
RETPD=0100
VOLSER=VOL002
//DAULST DD *
PRINTSYS
DETAIL
If a CDAM was backed up to volser VOL001 from 26/06/98 at 10 a. m. unti l 28/06/98 at
3 p. m. by backup mission BKP001, the corresponding SYSDATA from the Active User
Report List file and History User Report List file will be changed. The new value of RETPD
is 100 and the new value of VOLSER is VOL002. A report about every SYDATA from the
Active User Report List file and the History User Report List file and a detailed report
about every changed SYSDATA is produced.
Example 3
//DAUIN DD *
SELECT
FILE=MIG
BKPMIS=MIG001
PLATTER=PLATTER01
SIMULATE=YES
CHANGETO
SECONDARY
//DAULST DD *
In this example, a simulation is performed for switching SYSDATA and INDEX records of
the Migrated User Report List file to use the secondary migrated CDAM files. Only the
SYSDATA and INDEX records for CDAM files which migrated to platter PLATTER01 by
migration mission MIG001 are selected. The result of this simulation is a report of the
selected SYSDATA records. No change is made to the records themselves.
Example 4
//DAUIN DD *
SELECT
FILE=HST
BKPMIS=BKP001
SIMULATE=NO
CHANGETO
GENER=0005
//DAULST DD *
SYSDATA records referring to backup mission BKP001 are set to use the # of
GENERATIONS TO KEEP method. (In this example, 5 generations are used.) A report for
the modified SYSDATA records is produced.
See sample job CTDUBKPJ in the CONTROL-D JCL library for an example of how to
update backup information in CONTROL-D User Report List files.
CTVCLMIG Clean Migrated CDAM Files
This CONTROL-V utility cleans entries from the Migrated User Report List file and erases
and/or uncatalogs the CDAM datasets and index files that belong to these entries.
The Migrated User Report List file contains entries describing migrated user reports and
indexes. Each report has a retention period. The utility scans the Migrated User Report
List file for all the reports whose retention period has passed or for which a new stage has
been successfully created and deletes them from the Migrated User Report List file.
For non-DASD reports, the utility produces a list of cartridges which can be returned to
the global tape pool. However, a list of expired cartridges is not produced when using
continuous migration to cartridge because each cartridge contains files with different
expiration dates.
For FileTek migrated reports, a temporary file with report names and their MEDIA type is
created. This file is processed by the next step which deletes them from the FileTek SM.
Parameters
invokes the CTVCLMIG JCL procedure:
MODE Determines whether utility CTVCLMIG is run in Production mode or
Simulation (Test) mode. Optional. Default: Production mode. It is
bring run in Production mode.
PROD The utility runs in Production mode, changing and
deleting report entries and CDAM files which satisfy the
requirements specified by other parameters. Default.
TEST The utility runs in Simulation mode, performing analysis
and reporting but not changing or deleting any files.
NOSYS Determines whether or not utility CTVCLMIG checks for orphan User
records; i.e., User records which do not have corresponding SYSDATA
records. Optional. When parameter NOSYS is set to Y (Yes) or is not
specified, utility CTVCLMIG checks for orphan entries and issues a
message for each one found. Default.
When parameter NOSYS is set to N (No), the utility does not check for
orphan entries. However, the performance of the utility is
substantially improved.
NOLOCATE This optional parameter bypasses the LOCATE action for all migrated
files. This parameter can only be specified if the LIST OF TAPES TO
DELETE is not produced by CTVCLMIG (when wish WV0241 is
applied).
Utility CTVCLMIG normally performs a LOCATE action for each
migrated CDAM file. This LOCATE action can be bypassed by
specifying parameter NOLOCATE. Skipping the LOCATE action can
save a significant amount of time, but the utility may not detect files
that were accidentally erased.
// EXEC CTVCLMIG[,MODE=TEST|PROD,NOSYS=Y|N,NOLOCATE]
Return Codes
4 Operation performed successfully (for HSM backup utility)
8 Execution error
11 Operation performed successfully (in TEST mode)
12 Invalid input parameters
CTVDELI Delete Index Files from DASD
This CONTROL-V utility scans the Migrated User Report List file and erases from the disk
index files which are no longer needed on DASD. The utility determines which indexes to
delete based on user-specified selection groups.
Note Indexes that have been deleted from DASD by utility CTVDELI will be retrieved from
the migrated media when required.
A selection group consists of a DAYS statement and any number of optional INCLUDE
and/or EXCLUDE statements. The DAYS statement must contain a retention period which
specifies the number of days the indexes should remain on DASD, after which they are
deleted by the utility. The optional INCLUDE/EXCLUDE statements further qualify which
indexes belong to the selection group.
By specifying multiple selection groups, each with its own retention period (and
INCLUDE/EXCLUDE statements), groups of entries with differing retention periods can
be deleted by a single execution of utility CTVDELI. See Record Selection Logic
(INCLUDE/EXCLUDE Statements) in CONTROL-T Utilities in this section for
information about prefixing, masking and the INCLUDE and EXCLUDE logic used to
determine record selection.
Selection groups are scanned sequentially. The processing of a report is determined by the
first selection group whose INCLUDE or EXCLUDE criteria match the index.
INCLUDE/EXCLUDE criteria in other selection groups are ignored for that index.
$INDEX records are not deleted from the Migrated User Report List file because they are
needed for accessing the migrated index file.
After an index file is deleted, a flag indicating INDEX DELETED FROM DASD is placed in
the corresponding $INDEX record.
EXEC Statement
The EXEC statement can contain the following parameter:
MODE Determines whether utility CTVDELI is run in Production mode or
Simulation mode. Optional. Default: Production mode. It is
being run in Production mode.
PROD The utility runs in Production mode, deleting index files
which satisfy the requirements specified by other
parameters. Default.
TEST The utility runs in Simulation mode, performing analysis
and reporting but not deleting any indexes.
DAYS Statement
Parameters in the DAYS Statement
The DAYS statement can contain the following parameters:
n Retention period (in days) after which the index expires and is
selected for deletion from the Active User Report List file by the
selection group. Mandatory. This parameter must be the first
parameter in the statement.
By default, the index expires n days from the Original Scheduling
Date (ODATE) of the Report decollating mission. The IOA
administrator can change the default so that n is calculated from the
decollation date.
n can be a negative number (to delete reports created on future
ODATEs) and cannot exceed 9999.
RESIDENT If RESIDENT is specified, resident indexes are deleted. Otherwise,
resident indexes are not deleted.
Parameter RESIDENT only applies to the specific selection group in
which it appears. It can be specified for as many selection groups as
necessary.
If multiple INCLUDE/EXCLUDE statements are specified, each statement can contain any
or all of the parameters listed below separated by a space. However, each parameter can
appear no more than once in each statement.
See Record Selection Logic (INCLUDE/EXCLUDE Statements) in CONTROL-T Utilities
in this section for more information about INCLUDE and EXCLUDE statements.
Each INCLUDE/EXCLUDE statement must contain at least one of the following
parameters:
JOBNAME Job name or prefix.
JOBID Job ID (format Jnnnnn).
REPNAME Report name or prefix.
If the report name contains embedded spaces, replace each embedded
space with the @ character.
IXNAME Index name or prefix.
By default, the values specified for JOBNAME, REPNAME and IXNAME are treated as
prefixes. To prevent a value from being considered a prefix, place the special character <
after the value.
// EXEC CTVDELI[,MODE=TEST|PROD]
DAYS n [RESIDENT]
[INCLUDE [JOB NAME=Jobname] [JOBID=jobid] [IXNAME=indexname]
[REPNAME=repname]
[EXCLUDE [JOB NAME=Jobname] [JOBID=jobid] [IXNAME=indexname]
[REPNAME=repname]
DAYS statement
[INCLUDE statement]
.
.
[EXCLUDE statement]
.
.
.
Example 1
//S1 EXEC CTVDELI
DAYS 3
All non-resident indexes which are older than three days are deleted.
Example 2
//S1 EXEC CTVDELI
DAYS 0
A disk space saver. All non-resident indexes are deleted.
Example 3
//S1 EXEC CTVDELI
DAYS 5
All indexes of reports with name prefix PROD-JCL which are more than five days old are
deleted.
Example 4
//S1 EXEC CTVDELI
DAYS 0 RESIDENT
INCLUDE JOBNAME=Y99BUP01 JOBID=01923
All indexes (including resident indexes) with the specified job name and job ID are deleted.
Example 5
Assume the following index names exist: ACCT, ACCT-REC, ACCT-PAY.
//S1 EXEC CTVDELI
DAYS 0
INCLUDE IXNAME=ACCT
All of the above indexes are deleted.
//S1 EXEC CTVDELI
DAYS 0
INCLUDE IXNAME=ACCT<
Only index ACCT is deleted.
Example 6
//S1 EXEC CTVDELI
DAYS 0
EXCLUDE IXNAME=PROD-NDX JOBNAME=P01
All non-resident indexes are deleted from DASD except:
Indexes whose name begins with PROD-NDX.
Indexes for reports produced by jobs whose name begins with P01.
CTVJAR Job Archiving Utility
General
Utility JOBSDSN1 consolidates reports that are contained in the same CDAM file and
creates a new report, JOBNAME, whose index points to each jobs data. This utility
economizes by reducing the number of user $SYSDATA and $INDEX records in the
database. This is especially important for migrated reports, since they are usually kept for
a long period of time.
Index Format
JOBNAME Name of the job.
JOBID ID of the job.
SMFID SMF ID of the system in which the job ran.
COMP-CODE Completion code of the job.
DATE Date of the job.
START-TIME Start time of the job.
END-TIME End time of the job.
When the option to define a DDNAMES index for the reports in the initial decollation is
selected, utility CTVJAR will create that index as a subindex in the new report. (See Job
Archiving in Section 4 of this guide.)
The utility determines which reports to consolidate based on input parameters specified in
DD statement SYSIN. The utility also verifies that it is a JOBSDSN1 decollation.
Note If reports from the current date are consolidated, the utility synchronizes its activity
with the decollation process (see utility CTDDELRP). This avoids a situation in which
utility CTVJAR attempts to collect reports that are still being created by the decollation
process.
//JCLARC EXEC PGM=CTVJAR[,MODE=PROD, TEST]
//SYSIN DD *
EXEC Statement
The EXEC statement can contain the following parameters:
MODE Determines whether utility CTVJAR is run in Production or
Simulation mode. Optional. It is recommended that this utility be run
in Simulation mode prior to being run in Production mode.
PROD The utility runs in Production mode, consolidating reports
and creating the JOBNAME report. Default.
TEST The utility runs in Simulation mode, producing a sysout
which indicates the operations that would have been
performed in Production mode.
The following parameters are passed to the utility via DD statement SYSIN:
PREFIX Prefix of the CDAMs that are to be consolidated.
FODATE From ODATE of the consolidated reports in DD/MM/YY format.
TODATE To ODATE of the consolidated reports in DD/MM/YY format.
Note If both FODATE and TODATE are not specified or specified as
blank, all reports in the Active User Report List file that were
created until yesterday are consolidated. If only one of these
parameters is specified, reports with this ODATE are
consolidated. If both FODATE and TODATE are specified,
reports whose ODATE is within the specified range are
consolidated.
REPNAME Name of the newly created report. If blanks or apostrophes are
included in the report name, they must be specified between
apostrophes and the apostrophes of the report name must be doubled.
USER Name of the user for whom the new report will be created.
MIGMIS Migration mission name for the new report.
BKPMIS Backup mission names for the new report. Up to 6 names can be
specified within brackets separated by a comma.
PRTMIS Print mission names for the new report. Up to 5 names can be
specified within brackets separated by a comma.
SYNC Indicates whether or not to synchronize with decollation. Optional.
Y (Yes) Synchronize with decollation. Accumulation of jobs into a
currently open CDAM will be stopped and a new CDAM
will be opened.
N (No) Do not synchronize with decollation. Jobs of currently
opened CDAM files will not be consolidated. Default.
Example
//CTVJAR EXEC PGM=CTVJAR,PARM=PROD
//STEPLIB DD DSN=IOAP.V514.LOAD,DISP=SHR
//ERRLOG DD SYSOUT=*,HOLD=YES
//DATREE DD DISP=SHR,DSN=CTDP.V514.PARM(CTDTREE)
//SORTIN DD UNIT=SYSALLDA,SPACE=(CYL,(20,40))
//SORTOUT DD UNIT=SYSALLDA,SPACE=(CYL,(20,40))
//SORTWK01 DD UNIT=SYSALLDA,SPACE=(CYL,(20,40))
//SYSOUT DD SYSOUT=*,HOLD=YES
//DAACT DD DISP=SHR,DSN=CTDP.V514.ACT.E000
//DAACTI DD DISP=SHR,DSN=CTDP.V514.ACTI.E000
//SYSIN DD *
REPNAME=MANAGEMENT REPORTS USER=MGT
PREFIX=CTDP.E3 BKPMIS=(BKP1,BKP2,BKP3) MIGMIS=MIGDASD
PRTMIS=(PRT1,PRT22,PRT56)
//SYSUDUMP DD SYSOUT=*,HOLD=YES
//
CTVUNMIG Unmigrate Utility
General
This utility reads a migrated CDAM file and recreates the original CDAM file on DASD.
The utility can work in standalone mode. Stand-alone mode is applicable for disaster
recovery (when the IOA 514 environment, log messages and IOASPRM table content are
not available). In standalone mode, all IOA related files can be omitted from the job if they
are not available when the job is submitted. The utility issues error messages for
unavailable load-modules, assumes that the migrated CDAM is a standard sequential file
(migrated to either DISK or CART) and tries to re-create the original report file.
Sample JCL for invoking utility CTVUNMIG is contained in member CTVUNMIG of the
CONTROL-D JCL library. CDAM file names are passed to utility CTVUNMIG via DD
statement SYSIN. This sample JCL is reproduced here:
//%JOBNAME%UM JOB %JOBCARD%
%JCL1%
%JCL2%
//*******************************************************************
//* UNMIGRATE UTILITY JOB *
//* ---------------------- *
//* THIS MEMBER CONTAINS SAMPLE JCL FOR THE UNMIGRATE UTILITY *
//* *
//* IN PARM FIELD SPECIFY THE MEDIA NAME AS IT IS WRITTEN *
//* IN IOASPARM, AND UNIT NAME FOR CDAM FILE ALLOCATION *
//* IN SYSIN DD SPECIFY THE MIGRATED FILE(S) NAME(S). *
//*******************************************************************
//UNMIGR EXEC PGM=CTVUMG,COND=EVEN,REGION=3000K,
// PARM=CART
//STEPLIB DD DSN=IOAP.V514.LOAD,DISP=SHR
//SYSABEND DD SYSOUT=*,HOLD=YES
//SYSIN DD *
OPV.CTDP.E2.N50TRPTI.J15637.D2460924.N000500
OPV.CTDP.E2.N50TRPTI.J15637.D2451624.N000500
//
Parameters
The following parameter must be specified in the job which invokes utility CTVUNMIG.
PARM Media name as specified in member IOASPARM.
Return Codes
0 All original CDAMs were recreated successfully
8 Error encountered during the process (see specific error messages on each
input file for details)
16 Error opening file (input or output)
CONTROL-O Utilities
CTOCSF Copy the Message Statistics File
Utility CTOCSF copies the Message Statistics file. The utility is generally used to create a
new Message Statistics file whose size will be better adapted to the sites needs.
Before copying the file, the following steps must be followed:
1. If the CONTROL-O monitor is active, stop the CONTROL-O statistics collection task
using the command:
F CONTROLO,STOPSTATS
Message CTO189I indicates that statistics accumulation has stopped.
2. Verify that no users have allocated the Message Statistics file using CONTROL-O screen OM.
3. Rename the current Message Statistics file (input file for the copy operation), for
example, via ISPF 3.2/3.4.
4. Perform the following steps in ICE:
Specify CTO as the Product ID.
Select the CUSTOMIZE activity from the menu.
Select Major step CTOPARM Post-Installation.
Select Minor step Update CTOPARM Variables.
Change parameter STREC# from (for example) 10000 records to 20000 records to
change the size of the new Message Statistics file.
Select Minor step Save Parameters Into Product Libraries.
Select Minor step Compile and Link CTOPARM.
5. Allocate and format the new Message Statistics file (output file for the copy operation)
using member DEFSTAT in the IOA INSTCTO library.
6. Edit member CTOCSFJ in the CONTROL-O JCL library. Change DD statement
DASTF DSN to match the name specified in Step 3.
Example
//COPYST JOB
//COPYFILE EXEC CTOCSF
//DASTF DD DISP=SHR,DSN=old-dsname
//
where:
old-dsname is the name specified in Step 3 above.
After the Message Statistics file has been copied, the statistics collection task can be
restarted using operator command:
F CONTROLO,STARTSTATS
Message CTO184I indicates that statistics accumulation has started.
CTOCTA List Programs Running in an Address Space
Utility CTOCTA enables you to determine which programs are running in a specific
address space. This utility is used primarily for gathering information to be included in the
input file of utility CTOCTI below.
Note The address space being analyzed must be running when this utility is run.
//DISPGMNM EXEC PGM=CTOCTA,PARM=asname
//STEPLIB DD DSN=prefix.cto.load,DISP=SHR
Parameter
CTOCTA JCL procedure.
PARM Name of the address space to check. The utility analyzes this address space
and displays the names of the programs it is running.
Return Codes
Example
If the utility is run to check address space M70TEST, the following output messages may
be generated:
CTO660I ADDRESS SPACE M70TEST WILL BE PROCESSED NOW
CTO666I PROGRAM IEAVAR00 FOUND IN THE RB CHAIN
CTO666I PROGRAM IEESB605 FOUND IN THE RB CHAIN
CTO666I PROGRAM IEFSD060 FOUND IN THE RB CHAIN
CTO666I PROGRAM IEFIIC FOUND IN THE RB CHAIN
CTO666I PROGRAM TESTPGM FOUND IN THE RB CHAIN
CTO666I PROGRAM IEAVTSDT FOUND IN THE RB CHAIN
CTO664I ADDRESS SPACE M70TEST ACTIVE
When determining which program name should be specified in the input file for utility
CTOCTI, ignore programs IEAVAR00, IEESB605, IEFSD060, IEFIIC and IEAVTSDT.
These are system programs used by all started tasks and batch programs. In the above
example, TESTPGM is the program name that should be specified in the input file for
utility CTOCTI.
CTOCTI Generate Input for the SYSIMAGE Facility
SYSIMAGE is a facility used by the CONTROL-O Status Monitoring System (COSMOS) to
automatically generate an Object database which reflects your current environment.
Utility CTOCTI is called by the SYSIMAGE facility to accumulate the information
necessary for creation of the Object database.
A sample input file (CTOOBJFL) is supplied with information about the objects in a typical
environment. This file should be edited to reflect your environment and the objects you
want COSMOS to manage. The input file is described in detail below.
See Section 8 of the CONTROL-O User Manual for more information about COSMOS.
Use the following JCL to activate the utility:
//BLDCOSDB EXEC PGM=CTOCTI
//STEPLIB DD DSN=loadlib,DISP=SHR
//OBJFILE DD DSN=parmlib(CTOOBJFL),DISP=SHR
where:
loadlib Dataset name of the CONTROL-O LOAD library.
parmlib Dataset name of the CONTROL-O PARM library.
Input File
Object names and program names used as input for the utility are specified in sample
input file CTOOBJFL located in the CONTROL-O PARM library.
Sample segment of the input file
*OBJECT_DETAIL__OBJECT CLASS____AS_NAME_PGMNAME_X
ELD ETILOADR
PDS MANAGER PDSMOPR
TEST PDS MANAGER PDSMANT PDSMOPR X
BB CSA MONITOR PMGCSWRN
RESOLVE ASTXA1MN
ENDEAVOR LDMMAIN
CONTROL-D CTDMON
TSO IKTCAS00
PCAUTH PCAUTH IEAVXMASX
RASP RASP IARDINITX
TRACE TRACE IEAVETAIX
XCFAS XCFAS IXCINJSTX
GRS GRS ISGNASIMX
Format of the Input File
columns 01 16 Object description. The SYSIMAGE facility copies the description in
these columns to the DETAIL column in the Object database
generated from the input file. Mandatory.
columns 17 32 Object class name. You can use this field to create logical groups of
objects. For more information, see the description of the CLASS
column of the Object database in Section 8 of the CONTROL-O User
Manual. Optional.
columns 33 40 Address space name. Optionally, utility CTOCTI searches for the
specified program name (described below) running in this address
space. If no address space name is specified, CTOCTI will match the
entry with the active objects program name (see below). Optional.
columns 41 48 Program name. This is the primary field used by CTOCTI for
identifying the system object. Mandatory.
column 49 Exclude field. Used to indicate that the object in this row should not
be managed by COSMOS. Valid values:
X The program and/or address space in this row is ignored
by the utility.
blank The object is processed by this utility and is included in
the input for the SYSIMAGE facility.
Modifying the Input File
Before running utility CTOCTI, it is recommended that you modify the input file in the
following ways:
Exclude system resources from the utility output by placing an X in column 49 of the
rows describing the resource objects.
Add rows for objects (e.g., started tasks) not listed in the input file. At least an object
name and program name must be specified for each new row.
Modify object and/or class names to conform to your site standards.
If a started task that is running in the system is not listed in the input file, it is listed in
the output of the utility. Instead of a specific object name and description,
**UNDEF_OBJECT** is returned.
The program name associated with a specific address space can be determined via utility
CTOCTA (described above).
Return Codes
0 The utility completed successfully
8 The utility ended with errors (see messages issued by the utility for details)
Utility Output
The output of utility CTOCTI is a series of messages describing objects (resources) at your
site. These messages are used as input for the SYSIMAGE facility which generates an
Object database to be used by COSMOS.
The following is a sample output for this utility:
CTO657I OBJECT__ OBJECT DETAIL___ OBJECT_CLASS____ STATUS__ J
CTO658I -------- ---------------- ---------------- -------- -
CTO659I ELD ELD N/A ACTIVE
CTO659I PDSMAN PDS MANAGER N/A ACTIVE
CTO659I PDSMANT TEST PDS MANAGER N/A INACTIVE
CTO659I RESOLVE RESOLVE N/A ACTIVE
CTO659I D54TROLD CONTROL-D N/A ACTIVE
CTO659I TSO TSO N/A ACTIVE
CTO659I RMF **UNDEF_OBJECT** *UNDEFINEDCLASS* ACTIVE
CTO659I SMLSMS **UNDEF_OBJECT** *UNDEFINEDCLASS* ACTIVE
CTO659I RASP RASP N/A EXCLUDED
CTO659I TRACE TRACE N/A EXCLUDED
Certain messages return an object name of **UNDEF_OBJECT**. These messages
describe started tasks which were active in the environment, but were not listed in the
input file for the utility. The SYSIMAGE facility creates objects for undefined address
spaces. However, such objects are not assigned values in the DETAIL and CLASS columns
of the Object database.
To ensure that no started tasks are omitted from the Object database created from the
utility output:
1. Run utility CTOCTI (not via the SYSIMAGE facility).
2. Check the messages generated by the utility for undefined objects.
3. Edit the input file for utility CTOCTI in the following way:
Add rows for the missing started tasks.
Specify an appropriate object name for each started task.
Determine the program name for each started task (via utility CTOCTA) and
specify it in the input file.
4. When all started tasks have been defined in the input file for utility CTOCTI, rerun
this utility via the SYSIMAGE facility.
The SYSIMAGE facility uses the utility output to create an Object database which includes
all started tasks not excluded via the input file to the utility.
CTODBIB Rebuild a CONTROL-O Index File
Utility CTODBIB rebuilds index files for various CONTROL-O Variable Database data
files. The new index files correspond to information contained in the data files.
This utility rebuilds the indexes of a specific data file. Previous contents of the index file
are erased.
Note The index file that is to be rebuilt must be allocated and formatted prior to activating
the utility.
When the space remaining for the existing index file is insufficient, or the relevant data
file was reloaded. In this case:
Format the index file with utility IOADBF.
Rebuild the index file with utility CTODBIB.
In case of index file integrity problems which can be detected using utility IOADII,
(described earlier in this section).
In case of data file integrity problems. In this case, correct the data file and re-index it
with utility CTODBIB to reproduce the corresponding index file.
Parameter
CTODBIB JCL procedure.
DBFILE Name of the data file to be processed.
Note SYSIN parameters are provided in the keyxxx members in the PARM library for your
convenience. File name specifications are hard-coded (predefined) in these members.
// EXEC CTODBIB
Return Codes
Example
// EXEC CTODBIB,DBFILE=GRPD
//SYSIN DD DSN=CTO.PROD.PARM(KEYGRP),DISP=SHR
//DAGRP DD DSN=CTO.PROD.COLI,DISP=SHR
Utility CTODBIB is used by the following jobs in the CONTROL-O JCL library. Refer to
these jobs for additional examples:
CTODBSBI Rebuilds the index of the Variable Database Definition file.
CTOCOLBI Rebuilds the index of the Variable Database Column file.
CTOVARBI Rebuilds the index of the Variable Database Variable file.
CTORSTM Statistics Report Utility
Utility CTORSTM generates statistical reports based on information provided by the
Message Statistics facility. CTORSTM output can be used to analyze site automation
requirements and the progress of the automation process. CTORSTM output can also be
used as input for report generator utilities (e.g., SAS, SP/SS, or EASYTRIEVE).
A sample JCL which invokes procedure CTORSTM can be found in member CTORSTMJ in
the CONTROL-O JCL library. The output report is written to SYSPRINT.
Report parameters are passed to utility CTORSTM via DD statement DAREPIN.
SORT Parameter
The following parameter can be specified to sort the report data.
SORTBY
MSGID
COUNT
1
]
1
Indicates whether the report should be sorted by message ID
(MSGID) or by message count (COUNT) with the most frequent
messages appearing first. Default: SORTBY COUNT.
Each INCLUDE/EXCLUDE statement contains parameters which limit the messages for
which statistics are collected. See Record Selection Logic (INCLUDE/EXCLUDE
Statements) in CONTROL-T Utilities earlier in this section for information about
prefixing, masking and the INCLUDE and EXCLUDE logic used to determine record
selection.
msg Message ID (e.g., DFH1799) or mask (e.g., DFH*). Defaults:
INCLUDE * Include all messages.
EXCLUDE blank Do not exclude any messages.
Example
//REPORT EXEC CTORSTM
//DAREPIN DD *
INCLUDE DFH*
INCLUDE $HASP*
EXCLUDE $HASP100
SORTBY MSGID
/*
CTOTEST Simulate Messages and/or Commands
Utility CTOTEST simulates messages and commands used to trigger CONTROL-O rules.
The messages/commands are specified in a dataset used as input for the utility. When the
utility is run, CONTROL-O responds to the specified messages as if they had been issued
in the usual manner.
This utility can be used to:
Check the performance of a rule or group of rules.
Check if an existing rule handles a specific message or command.
Check CONTROL-O response to a series of commands and/or messages.
Utility CTOTEST is run on each record in the input file. A pair of messages is generated
for each run of the utility. The first message describes the record being processed. The
second message describes the CONTROL-O response to the input record. A return code
(described below) is supplied as part of the second message.
//SIMULATE EXEC PGM=CTOTEST,PARM=ssname
//CMDMSGFL DD DSN=dsname,DISP=SHR
Parameters
CTOTEST procedure.
PARM CONTROL-O subsystem name specified in parameter SSNAME in
member IOAPARM.
The following paramater must be specified in DD statement CMDMSGFL:
DSN Name of the dataset containing the messages and/or commands to be
processed by the simulated CONTROL-O environment. The format of
the input dataset is described below.
Format of the Input File
The input file for utility CTOTEST has the following characteristics:
Physical sequential
Record length: 127
Record format: Fixed or Fixed block
Records in the input file have the following format:
nyyyyyyyyyyyy
where:
n Single digit indicating the type of message/command to be simulated.
Valid values:
1 MVS operator command
2 MVS or JES2 message
3 JES3 command
4 JES3 message
5 JES2 command
yyyyyyyyyyyy Text of the message or command to be simulated. Maximum length:
126 characters. Comment lines (indicated by an asterisk in column
one) can also be included in the input dataset.
Return Codes
The following return codes may be returned by each run of utility CTOTEST. If an internal
error is detected while processing an input record, that record is ignored and processing
continues with the next record of the input dataset.
0 Input record was processed successfully or no CONTROL-O rule has been
defined for the specified message or command.
4 Message was suppressed.
8 Message was changed, or a JES2 command or message rule was
processed.
12 Specified CONTROL-O subsystem is inactive.
Other Internal error.
Example
Below is a sample JCL and input for utility CTOTEST followed by the messages returned
as output.
JCL
//CTOSIM EXEC PGM=CTOTEST,PARM=N500
//STEPLIB DD DISP=SHR,DSN=CTO.LOAD.LIB
//CMDMSGFL DD *
Input File
5$D MODULE(HASPCOMM)
1IEC301A S JOB T56E DSNAME
1IEF403I M70TT123 STARTED
Output Messages
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
CTO500I INPUT LEN=019 REC=$D MODULE(HASPCOMM)
CTO503I RC000 LEN=000 REC=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
CTO500I INPUT LEN=025 REC=IEC301A S JOB T56E DSNAME
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
CTO500I INPUT LEN=024 REC=IEF403I M70TT123 STARTED
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
CTOALOCP Backing Up the Automation Log
Utility CTOALOCP copies the contents of one Automation Log file to another Automation
Log file or to a sequential dataset. The utility can be used to perform any of the following
functions, depending on the parameters specified.
Backing up the Automation Log to another Automation Log. Automation Log backup
files can be displayed, just like the current Automation Log file, via the Automation
Log screen (option OL).
Increasing the size of the current Automation Log file.
Copying the Automation Log to a sequential file. The sequential file can be processed by
a report generator utility or restored and displayed later as an Automation Log file.
Restoring a sequential backup file to the format of an Automation Log file.
Changing the dataset organization of an Automation Log.
Parameters are passed to utility CTOALOCP via DD statement DAALPPRM.
The following parameters can be specified:
STARTDATE Earliest date of the log records to be copied. Format: yymmdd. Default:
Date of the earliest record in the log.
STARTTIME Earliest time of the log records to be copied. Format: hhmmss. Default: 000000.
ENDDATE Latest date of the log records to be copied. Format: yymmdd. Default:
Date of the latest record in the log.
ENDTIME Latest time of the log records to be copied. Format: hhmmss. Default: 240000.
FROMDSN Name of the input dataset for the copy operation. Default: Name of the
operational Automation Log file.
FROMTYPE Organization of the input dataset. Valid values: S and blank. Type S
must be specified if the input dataset is a sequential file. For all other
input dataset types, the field must be blank.
TODSN Name of the output dataset for the copy operation.
TOTYPE Organization of the output dataset.Optional. Valid values:
V DIV (VSAM Linear) dataset.
D Direct Access (BDAM) dataset.
S Sequential file.
The default is the type of the operational Automation Log (i.e., the value
of parameter AUTOMLOG in member CTOPARM). See CONNTROL-O
Operational Parameters in Section 7 of the IOA Installation Guide for
more information about parameter AUTOMLOG.
TOVOLUME Name (volser) of the volume on which the dataset named in parameter
TODSN will reside. This parameter is mandatory for an output
dataset of type V (whether specified explicitly with parameter
TOTYPE or by default).
TOUNIT Name of the unit to which the output dataset will be allocated.
Default: SYSALLDA.
TORECNUM Number of records allocated to the output file. (This value is used to
determine the size of the output dataset.) Default: number of records
in the input file.
Valid values:
nnnnnnnn Specified number of records.
MINIMAL The number of records copied from the input dataset,
based on date and time specified limits.
Automation Log Backup Utility Examples
1. Copy the entire operational Automation Log to another file of the same size:
TODSN SYS3.MYLOG
TOVOLUME WORK02
TOUNI DISK
2. Copy the entire operational Automation Log to a larger file:
TODSN SYS3.MYLOG
TOVOLUME WORK02
TOUNIT DISK
TORECNUM 100000
3. Restore a sequential file to the format of a direct access (BDAM) Automation Log file:
FROMTYPE S
TODSN SYS3.MYLOG.DTYPE
TOTYPE D
TOVOLUME WORK02
TOUNIT DISK
4. Back up part of the operational Automation Log to a file on the basis of date/time
limits. (The output file will contain only the records selected.) With CONTROL-M, the
date/time can be set using the CONTROL-M AutoEdit facility.
STARTDATE 981027
STARTTIME 150000
ENDDATE 981027
ENDTIME 200000
TODSN SYS3.MYLOG.D2710.F15T20
TOVOLUME WORK02
TOUNIT DISK
TORECNUM MINIMAL
5. Copy part of the operational Automation Log file to a sequential file:
STARTDATE 981020
ENDDATE 981021
TODSN SYS6.MYLOG.F20T21
TOTYPE S
TOVOLUME WORK02
TOUNIT DISK
TORECNUM MINIMAL
CONTROL-T Utilities
Control Statement Syntax
The following rules apply to the syntax for control statements specified for CONTROL-T
utilities:
Multiple INCLUDE and EXCLUDE statements can be specified for each run of a
utility.
Each control statement (i.e., an INCLUDE/EXCLUDE statement or a CONTROL-T
TYPERUN statement) can span multiple lines.
Specification for each parameter in a control statement must be contained in a single
line.
To specify a value which includes blank spaces, the value must be enclosed in single
quotes (e.g., This is a value with spaces).
All control statements must be specified in columns 1 through 71. (Comments can be
specified in any column.)
If not all parameters of a statement fit on a line, place a comma immediately after the
last parameter that fits on the line and continue specifying subsequent parameters on
the next line.
To add a comment to a line, separate it from the code on the line by one or more blank
spaces. For example:
INCLUDE DSNAME=DB2* Select all DB2 datasets for processing
Record Selection Logic (INCLUDE/EXCLUDE Statements)
General
Certain utilities accept selection criteria that determine which records should be processed
when the utility runs. These selection criteria are specified as expressions in INCLUDE
and EXCLUDE statements which are supplied as parameters to the utility.
INCLUDE and EXCLUDE statements are grouped into blocks. An INCLUDE/EXCLUDE
block consists of INCLUDE statements followed by corresponding EXCLUDE statements.
INCLUDE and EXCLUDE expressions, statements and blocks are described on the
following pages.
Expressions
Expressions are used to specify selection criteria. The format of an expression:
key operator value
where:
key A parameter (field) in the record. Each key listed in each
INCLUDE/EXCLUDE statement must be unique.
operator Relational symbols used to compare the key to the value. Supported
symbols include:
= equal
or ! not equal
< less than
> greater than
value Number or character string (which may include mask characters)
against which to compare the key.
Note See Appendix D: Logical Field Names for the CONTROL-T
Repository in guide for valid values that can be specified in
INCLUDE/EXCLUDE statements in CONTROL-T.
Only the =, and ! operators can be specified when the key and value are of type character
(i.e., non-numeric).
Mask characters can be specified:
For expressions whose operator is either =, or !
-and-
As part of a character string.
For additional information about masking, see Character Masking in Section 2 of the
appropriate user manual.
INCLUDE Statements
INCLUDE statements determine which records should be processed by the utility
according to selection criteria.
INCLUDE statements are composed of expressions (at least one) separated by commas.
The format of an INCLUDE statement:
INCLUDE Expression1, Expression2, ... , ExpressionN
All the expressions in an INCLUDE statement must be true for the statement to be true
(i.e., the relationship between the expressions within one INCLUDE statement is AND).
EXCLUDE Statements
EXCLUDE statements determine which records should not be processed by the utility
according to selection criteria.
EXCLUDE statements are composed of expressions (at least one) separated by commas.
The format of an EXCLUDE statement:
EXCLUDE Expression1, Expression2, ... , ExpressionN
All the expressions in an EXCLUDE statement must be true for the EXCLUDE statement
to be true (i.e., the relationship between the expressions within one EXCLUDE statement
is AND).
INCLUDE/EXCLUDE Block
An INCLUDE/EXCLUDE block is composed of any number of INCLUDE statements
followed by any number of its corresponding EXCLUDE statements.
The format of an INCLUDE/EXCLUDE block:
Include Statement
Exclude Statement
Exclude Statement
Exclude Statement
AND
OR
OR
.
.
.
OR
The relationship between multiple INCLUDE statements in a block is OR.
The relationship between multiple EXCLUDE statements in a block is OR.
The relationship between an INCLUDE statement(s) and the following EXCLUDE
statement(s) in a block is AND.
Single INCLUDE/EXCLUDE Block Processing
If even one EXCLUDE statement of a block is true (i.e., a record satisfies the EXCLUDE
statement), the record is not selected and the next record is examined.
If all EXCLUDE statements in the block are false, the INCLUDE statement is evaluated
against the record. For a record:
If the INCLUDE statement is true, the record is selected.
If the INCLUDE statement is false, the record is not selected and the next record is
examined.
Multiple INCLUDE/EXCLUDE Blocks
Multiple INCLUDE/EXCLUDE blocks can be specified.
If multiple INCLUDE/EXCLUDE blocks are specified, the relationship between the
INCLUDE/EXCLUDE blocks is OR and the blocks are checked sequentially.
If a record is not selected after being checked against an INCLUDE/EXCLUDE block, it
is checked against the next INCLUDE/EXCLUDE block. Once a record is selected based
on an INCLUDE/EXCLUDE block, the record is included and not checked against other
blocks.
If only EXCLUDE statements are specified in the first block (i.e., no INCLUDE
statements are specified), only records not excluded by the first block are considered for
selection by subsequent INCLUDE/EXCLUDE blocks.
INCLUDE/EXCLUDE Examples
The following examples illustrate include/exclude logic. For all but the last example,
assume the following expressions, all of which evaluate to True.
Expression 1: Key1=Value1 True
Example 1
Select all records which match these expressions:
INCLUDE Key1=Value1,Key2=Value2,Key3=Value3
Example 2
Select all records which match these expressions, using another method:
INCLUDE Key1=Value1
EXCLUDE Key2Value2
EXCLUDE Key3Value3
Example 3
Select all records which match the first expression and either the second or third
expressions:
INCLUDE Key1=Value1
EXCLUDE Key2Value2,Key3Value3
Example 4
Select all records which do not match these expressions:
INCLUDE Key1Value1
INCLUDE Key2Value2
INCLUDE Key3Value3
Example 5
Select all records which match either the second or third expression, but do not match the
first expression:
INCLUDE Key2=Value2
EXCLUDE Key1=Value1
INCLUDE Key3=Value3
EXCLUDE Key1=Value1
Example 6
The following example utilizes actual values (instead of the terms KeyN and ValueN).
Select the records of all volumes starting with FD whose dataset name starts with BACKUP,
except for those volumes starting with FD but ending with 102. Furthermore, independent of the
preceding selection criteria, select records created by jobs whose job names start with CTT.
INCLUDE VOLSER=FD*,DSNAME=BACKUP*
EXCLUDE VOLSER=FD?102
INCLUDE CREJBN=CTT*
CTTACP Copy Trace File
This utility can be used to:
Copy a Trace file to another preformatted Trace file.
Copy a Trace file to a sequential variable-blocked file, enabling the output to be
formatted to a Hexadecimal or Dump display format.
Note If the Trace file is 100% full, no tape activity can be recorded in it. In this case, use
JCL parameter EXPDT=98000 when the Trace file is copied to tape
Copy a sequential, variable-blocked file containing Trace data back to a formatted
Trace dataset. If this Trace dataset contains data, the sequential files contents will be
appended to it.
Note The Trace file that is to be created must be formatted prior to activating the utility.
// EXEC CTTACP
//SYSIN DD *
COPY FROM=TRACE|SEQ,TO=TRACE|SEQ
<INCLUDE/EXCLUDE STATEMENTS>
OUTPUT TYPE=T|C|X|D|F,LINESIZE=size
//
Parameters
invokes the CTTACP JCL procedure:
TRCIN Name of source file.
TRCOUT Name of target file.
Parameters can also be supplied via DD statement SYSIN:
COPY Copy statement type. Mandatory.
FROM Source dataset type:
TRACE
SEQ
Source is a CONTROL-T Trace file.
Source is a sequential, variable-blocked file.
TO Target dataset type:
TRACE
SEQ
Target is a CONTROL-T Trace file.
Target is a sequential, variable-blocked file.
INCLUDE/
EXCLUDE
The records written to the output dataset can be filtered by one or more
INCLUDE/EXCLUDE statements. INCLUDE/EXCLUDE statements for
this utility can filter records according to any of the fields listed in
Table 4 of Appendix D in this guide. For more information see Record
Selection Logic (INCLUDE/EXCLUDE statement) earlier in this section
and see Appendix D.
OUTPUT Output formatting.
TYPE Output format type:
T Trace file records are unchanged. Default.
C Output contains only printable characters.
X Output is written in Hexadecimal format.
D Output is written in dump format (a
combination of C and X types).
F Output is formatted. A comprehensive list of
Logical Field Names and relevant values is
written for each volume/dataset record.
LINESIZE Output record size. Valid values: 70 to 132 characters;
Default: 80.
Note The LINESIZE parameter and C, X, D and E
values for the TYPE parameter are only valid
when the output is a sequential dataset.
Return Codes
0 Operation ended successfully
8 Missing DD statement(s) or open failed
12 Control card error
16 Load of CONTROL-T routines failed
20 I/O error on input/output files
Example 1
Copy a Trace file to a second preformatted Trace file:
// EXEC CTTACP,TRCOUT=CTT.BACKUP.TRC
//SYSIN DD *
COPY FROM=TRACE,TO=TRACE
//
Example 2
Copy the Trace file to a sequential variable-blocked file. Only records from job TAPEJOB
are included. The output should be in dump format. The line size is 132 bytes.
// EXEC CTTACP,TRCOUT=CTT.JOB.ACTIVITY
//SYSIN DD *
COPY FROM=TRACE,TO=SEQ
INCLUDE JOBNAME=TAPEJOB
OUTPUT TYPE=D,LINESIZE=132
//
CTTAFR Format and Initialize Trace File
Utility CTTAFR formats and initializes the Trace file.
The required number of trace records is specified in parameter TRCSIZE in member
CTTPARM. The maximum length of a trace record is 600 bytes. Assuming the dataset
blocksize is 3600 (the supplied installation default), one 3380 cylinder contains about 1000
trace records.
// EXEC CTTAFR
//
Parameters
No parameters are specified for this utility.
Return Codes
8 DCB open error or TCT load failure occurred
Example
Format the Trace file.
// EXEC CTTAFR
//
CTTBIX Rebuild Media Database Index
This utility rebuilds the index file for the Media Database. The new index file corresponds
to information currently contained in the Media Database data file.
Notes The index file to be rebuilt must be allocated and formatted prior to activating the
utility.
CTTBIX will usually run only if CONTROL-T is down or suspended. See parameter
TYPERUN below for further information.
When the amount of space remaining for the existing index file is insufficient. In this
case:
Format the index file.
Rebuild the index file.
For performance improvement.
After recovery.
After converting volumes from other tape management systems (e.g., CA-1, CA-TLMS)
to CONTROL-T.
// EXEC CTTBIX,TYPERUN=B|C|F|N
//
Parameters
Parameter TYPERUN is contained in t he EXEC statement.
TYPERUN Run type.
B Utility is run in BUILD mode; the index file is rebuilt. If
CONTROL-T is active, utility CTTBIX will not run.
C Utility is run in CONVERT mode. This mode is specified when
converting the database from another tape management system
to CONTROL-T. If CONTROL-T is active, utility CTTBIX will
not run.
F
N
Utility is run in FORCED BUILD mode; the index file is
rebuilt. No checking is performed for CONTROL-T status. This
mode forces building of the index file.
This value is useful to initiate a rebuild in a test environment
on a test Media Database while the production environment is
still active.
Utility is run in FORCED CONVERT mode. No checking is
performed for CONTROL-T status. This mode forces the
building of the Index file.
This mode is specified when converting the database from
another tape management system to CONTROL-T. This index
file can be built and checked in a test environment while the
production environment is still active.
Note Do not use type TYPERUN=F if utility CTTBIX is running
on the production Media Database (i.e., CONTROL-T is
active). Running this utility on the production Media
Database can cause unpredictable results.
Return Codes
8 Inconsistency error detected Execution continues Index file built
successfully (logical errors in the data should be manually corrected).
12 Error in parameters Execution terminates.
16 Error opening DCB Execution terminates.
24 Unsuccessful sort.
28 Media Database access error.
32 Load of CONTROL-T TCT failed.
40 Index not empty
44 CONTROL-T is active Utility CTTBIX cannot run in the specified mode
while CONTROL-T is active
Example
// EXEC CTTBIX,TYPERUN=B
//
CTTCRDF Allocate and Format Data/Index Files
CTTCRDF creates and formats various CONTROL-T files. It can also increase or decrease
the size of an index file to provide more space for the file or reduce the space used by the file.
// EXEC CTTCRDF
Other utilities are provided for copying entries from the original data file to the
newly-formatted data file. These other utilities are described later in this section.
This utility is used during CONTROL-T installation by jobs that create CONTROL-T files.
Each file creation job builds a newly-formatted data file and a corresponding index file.
Note This utility is activated during CONTROL-T installation.
Parameters
There are two categories of CTTCRDF parameters: Data file parameters and Index file
parameters. Parameters of both categories specify precisely the type of file to be created.
Parameters are supplied to the utility via a JCL procedure. Each file creation job creates
and formats a data/index file by receiving one or more of the following parameters:
Parameters for Data File Creation
DBPREFT High-level dataset name qualifier of the dataset.
DBFILET Third qualifier of the name of the data file to be created. Valid values:
MDBD Media Database file
STKD Stacking Database
DBUNITT Type of unit on which the data file should reside (3380, 3390).
DBVOLT Volume on which the data file should reside.
NRECS Number of records that the data file should contain. (To calculate the
required number of records, refer to Media Database Calculations
and Stacking Database Calculations Section 9 of the IOA
NBLKS Number of blocks that the data file should contain. (To calculate the
KEYLEN For data files, KEYLEN is always zero.
BLK Block size. This value should not be changed.
LREC Record length. This value should not be changed.
Parameters for Index File Creation
DBPREFT Highest dataset name qualifier of the dataset.
DBFILET Third qualifier of the name of the index file to be created. Valid values:
MDBI Media Database file.
STKI Stacking Database.
DBUNITT Type of unit on which the index file should reside (3380, 3390).
DBVOLT Volume on which the index file should reside.
NRECS Number of records that the data file should contain. (To calculate the
required number of records, refer to Media Database Calculations and
Stacking Database Calculations Section 9 of the IOA Installation Guide.)
KEYLEN Index files preset key length. This value should not be changed.
BLK Block size. This value should not be changed.
LREC Same as block size length. This value should not be changed.
NBLKS Number of blocks that the data file should contain. (To calculate the
Parameters DBPREFT and DBFILET specify the name of the file to be created (e.g., if DBPREFT
is CTT and DBFILET is MDBI, the name of the newly-created file is CTT.V514.MDBI).
Return Codes
8 Invalid parameters
12 LRECL not equal to BLKSIZE (Index file)
16 Open of output file failed
20 SYSPRINT open failed
24 Insufficient storage (REGION)
28 Maximum block count was exceeded
32 Invalid key length
Example
// EXEC CTTCRDF,DBPREFT=CTT.V514,DBFILET=MDBI,
DBUNITT=3390,KEYLEN=30
Utility CTTCRDF is used by the following jobs in the IOA INSTCTT library. Refer to these
jobs for additional examples.
CTTCMDB Allocates and formats the Media Database file (described in detail in
Section 9 of the IOA Installation Guide).
CTTCSTK Allocates and formats the Stacking Database (described in detail
Section 9 of the IOA Installation Guide).
CTTCTRC Allocate and Format Trace File
CTTCTRC creates and formats CONTROL-T Trace files.
// EXEC CTTCTRC
This utility is used during CONTROL-T installation by the job that creates the
CONTROL-T Trace file.
Parameters
Parameters are supplied to the utility via the invocation of a JCL procedure.
Parameters for Data File Creation
DBPREFT Highest dataset name qualifier of the dataset.
DBUNITT Type of unit on which the file should reside (3350, 3380, 3390).
TRCVOL Volume on which the file should reside.
TRCBLKS Number of blocks that the data file should contain. (To calculate the
Parameters DBPREFT and DBVERT specify the name of the file to be created (e.g., if
DBPREFT is CTT and DBVERT is V514, the name of the
newly-created file is CTT.V514.TRC).
Return Codes
8 DCB open error or CONTROL-T Control table load failure
Example
// EXEC CTTCTRC,DBPREFT=CTT.V514,DBUNITT=3390,
TRCBLKS=1700
CTTDBDLD Load Media Database/Stacking Database Data
Components
Utility CTTDBDLD loads Media Database (MDB) or Stacking Database data components
from a sequential file (which was previously created by utility CTTDBDUL). The data file
must be formatted via utility CTTDBF before running this utility.
Note The Media Database index component can be rebuilt from the database data
component using utility CTTBIX. The Stacking Database index component can be
rebuilt from the data database component using utility CTTDBIB.
// EXEC CTTDBDLD
Parameters
invokes the CTTDBDLD JCL procedure:
DBFILEI Sequential input file name suffix.
DBFILEO Output file name suffix. Valid values:
Return Codes
8 Sequential file operation error
20 IOAPARM load failed
100-199 Index component errors
200-299 Data component errors
Example
// EXEC CTTDBDLD,DBFILEI=SEQ,DBFILEO=MDBD
CTTDBDUL Unload Media Database/Stacking Database
Data Components
Utility CTTDBDUL unloads Media Database (MDB) or Stacking Database data
components to a sequential file. The sequential file must be previously allocated as fixed
block, with a record length equal to the record length of the database file being unloaded.
// EXEC CTTDBDUL
Parameters
invokes the CTTDBDUL JCL procedure:
DBFILEI Third qualifier of the input dataset. Valid values:
DBFILEO Sequential output file name suffix.
Return Codes
8 File operation error
16 IOAPARM load failed
Example
// EXEC CTTDBDUL,DBFILEI=MDBD,DBFILEO=SEQ
CTTDBF Format Existing Data/Index Files
This utility formats an existing CONTROL-T data or index file.
Note Utility CTTDBF is similar to utility CTTCRDF (described in this section). However,
utility CTTDBF does not actually create data/index files. The files must exist on the
disk before the utility is run.
// EXEC CTTDBF
Parameters
invokes the CTTDBF JCL procedure:
DBFILET File name suffix. Valid values:
MDBD Media Database Data file
MDBI Media Database Index file
STKD Stacking Database Data file
STKI Stacking Database Index file
NRECS Number of records. This number should be the same number that utility
CTTCRDF received via parameter NRECS when the file was created.
KEYLEN Record key length. This number should be the same number that utility
CTTCRDF received via parameter KEYLEN when the file was created.
For data files, KEYLEN is always zero.
Return Codes
12 LRECL not equal to BLKSIZE (Index file)
16 Open of output file failed
20 SYSPRINT open failed
28 Maximum block count was exceeded
32 Invalid key length
Example
// EXEC CTTDBF,DBFILET=STKD,NRECS=1000,KEYLEN=0
See the following jobs in the JCL library for additional examples.
CTTFMDB Formats Media Database data and index files.
CTTFSTK Formats Stacking Database data and index files.
CTTDBIB Rebuild Indexes of Stacking Database
Utility CTTDBIB rebuilds an index file from the CONTROL-T Stacking Database Data file.
The new index file corresponds to information currently contained in the Stacking
Database Data file.
Previous contents of the index file are erased.
Note The index file to be rebuilt must be allocated and formatted prior to activating the utility.
When the amount of space remaining in the existing index file is insufficient. In this
case:
Format the index file with utility CTTDBF.
Rebuild the index file with utility CTTDBIB.
Performance improvement.
// EXEC CTTDBIB
Parameters
invokes the CTTDBIB JCL procedure:
DBFILET Data file name to be processed. Valid values:
STKD Stacking Database Data file.
Note SYSIN parameters are provided in the KEYxxx members in the PARM library for your
convenience. Relevant file name specifications are hard-coded (predefined) in these
members.
Return Codes
Example
// EXEC CTTDBIB,DBFILET=STKD
//SYSIN DD DSN=CTT.PROD.PARM(KEYSTK),DISP=SHR
//DAIDXSTK DD DSN=CTT.PROD.STKI,DISP=SHR
CTTDBID Check Integrity of Data File
Utility CTTDBID checks data file integrity.
Utility CTTDBID checks the physical organization of a data file and reports errors which
are detected in the data file structure. Optionally, the utility corrects errors that are
detected.
// EXEC CTTDBID, DBFILET=MDBD|STKD,ACT=R|W
Data file integrity errors are listed in the sysout of the job.
Parameters
invokes the CTTDBID JCL procedure.
DBFILET Third qualifier of the name of the data file to be processed. Valid
values:
MDBD Media Database file.
STKD Stacking Database.
ACT Action to be performed on the file.
R Report detected errors. Default.
W Report and correct detected errors.
Note It is recommended that utility CTTDBID be run first with
ACT=R (i.e., without requesting corrections. Corrections are
necessary, rerun the utility with ACT=W (i.e., requesting
corrections).
Return Codes
0 Operation performed successfully. No errors found.
4 Operation performed successfully. Errors were detected and fixed (applicable only
when ACT=W).
other Errors were detected. Refer to the utility messages for more information.
Example
// EXEC CTTDBID,DBFILET=MDBD,ACT=R
CTTDBII Check Integrity of Index File
Utility CTTDBII checks index file integrity.
Utility CTTDBII checks the physical organization of an index file and reports errors that
are detected in the index file structure.
If errors are detected, the corresponding index file should be rebuilt using utility CTTDBIB
(or utility CTTBIX if the file is the Media Database file).
// EXEC CTTDBII,DBFILET=MBDI|STKI
Index file integrity errors are listed in the sysout of the job.
Parameters
invokes the CTTDBII JCL procedure:
DBFILET Third qualifier of the name of the index file to be processed. Valid
values:
MDBI Media Database file.
STKI Stacking Database.
Return Codes
Example
// EXEC CTTDBII,DBFILET=STKI,DBFILET=NDB|STK[FROM={D|V|K}from-key,TOS{D|V|K}to-key
CTTDBPRT Print Data Records
This utility prints any CONTROL-T data file and its corresponding index file in SNAP
format.
// EXEC CTTDBPRT
Parameters
invokes the CTTDBPRT JCL procedure:
DBFILET Third qualifier of the name of the data file. Valid values:
MDB Media Database file.
STK Stacking Database.
FROM Value of key from which to print.
TO Value of key until which to print.
Notes This utility works with both data and index files.
Parameters FROM and TO are keys that should be found in the
index and according to which data are printed.
The actual key is prefixed with one byte which identifies the
record type:
D Dataset
V Volume
K Stacking
Either FROM and TO, or neither FROM nor TO, can be
specified. If FROM and TO parameters are not specified or are
specified as blank, all records are printed.
Example 1
Print the entire Media Database file.
// EXEC CTTDBPRT,DBFILET=MDB
Example 2
Print Media Database volume records for volumes 100000 through 999999.
// EXEC CTTDBPRT,DBFILET=MDB,FROM=V100000,TO=V999999
Example 3
Print Media Database dataset records for datasets BACKUP.G0012V00 through
BACKUP9.
// EXEC CTTDBPRT,DBFILET=MDB,FROM=DBACKUP.G0012V00,TO=DBACKUP9
Example 4
Print Stacking Database records created by job M77BKUP.
// EXEC CTTDBPRT,DBFILET=STK,FROM=KM77BKUP,TO=KM77BKUP
CTTDLD Add/Delete/Convert Volumes
This utility adds volumes to, and deletes volumes from, the Media Database. It can also
convert volumes from other tape management systems (e.g., CA-1, CA-TLMS).
To add a range of scratch/non-scratch volumes to the Active library (MAINLIB).
Records for these volumes are added to the Media Database. This is called ADD mode.
To delete a range of scratch volumes from the Active Library (MAINLIB). Records for
these volumes are deleted from the Media Database. This is called DELETE mode.
To build data from an external source of information and add it to the data component of the
Media Database. This is called CONVERT mode. Usually CONVERT mode is used to convert
another tape management systems database (e.g., CA-1, CA-TLMS) to CONTROL-T.
ADD mode:
// EXEC CTTDLD
//SYSIN DD *
TYPERUN MODE=ADD
RANGE FIRST=firstvol,LAST=lastvol,MEDIA=type,
SCRATCH=Y|N,VENDOR=vendor,RENAME=prefix
//
DELETE mode:
// EXEC CTTDLD
//SYSIN DD *
TYPERUN MODE=DELETE
RANGE FIRST=firstvol,LAST=lastvol
//
CONVERT mode:
// EXEC CTTDLD,INP=source-dataset
//SYSIN DD *
TYPERUN MODE=CONVERT
RANGE FIRST=firstvol,LAST=lastvol,MEDIA=type,
VENDOR=vendor,RENAME=prefix
//
Note Parameter INP in procedure CTTDLD is mandatory and valid only in CONVERT mode.
Utility CTTDLD is used by the following jobs in the INSTCTT library. Refer to these jobs
for additional examples.
CONVTMDB Converts CA-TLMS tape management system reports to the
CONTROL-T Media Database.
CONVC4MD/CONVC5MD
Converts from CA-1 (version 4 or 5) to the CONTROL-T Media
Database.
CONVLCTL Converts from MVS Catalog to the CONTROL-T Media Database.
CONVRMDB Converts from RMM to the CONTROL-T Media Database.
Parameters
The following parameter is specified in the EXEC statement:
INP Name of the input file containing the data (VWR records) to be
converted. Mandatory and valid only in CONVERT mode.
The following parameters are supplied via DD statement SYSIN:
TYPERUN Run type.
MODE Operation mode. Valid values:
ADD
DELETE
CONVERT
Add volume entries to the Media Database.
Delete scratch volume entries from the Media
Database.
Convert volume entries from another tape
management products database to
CONTROL-T Media Database format.
RANGE Volume range and attributes. Valid values:
FIRST First volume serial number in the range. Mandatory.
LAST Last volume serial number in the range. Mandatory.
MEDIA One of the media types defined in member CTTPARM.
Mandatory and valid only in ADD and CONVERT modes.
SCRATCH Indication of whether or not the volume should be
added as scratch. Mandatory and valid in ADD mode
only.
Y (Yes) Volume should be added as scratch.
N (No) Volume should not be added as scratch.
VENDOR Vendor of the media. Optional. Valid only in ADD and
CONVERT modes.
RENAME String to replace the prefix of the volume serial number
(volser). The SL-name of the volume remains
unchanged. Optional. RENAME=prefix is valid only in
ADD and CONVERT modes. The length of this string
must not exceed the length of the prefix in parameters
FIRST and LAST (above).
Return Codes
4 Minor errors occurred Operation continues
12 Error in parameters Execution terminates
16 Error opening DCB Execution terminates
Greater than 16 Other error the error is accompanied by an appropriate message
indicating the problem Execution terminates
Example 1
Add 3400 type media non-scratch volumes numbered K00100-K00500, made by vendor IBM.
// EXEC CTTDLD
//SYSIN DD *
TYPERUN MODE=ADD
RANGE FIRST=K00100,LAST=K00500,MEDIA=3400,
SCRATCH=N,VENDOR=IBM
//
Example 2
Delete volumes numbered K00100-K00500.
// EXEC CTTDLD
//SYSIN DD *
TYPERUN MODE=DELETE
RANGE FIRST=K00100,LAST=K00500
//
Example 3
Convert 3480 type volumes numbered K00100-K00500 to CONTROL-T.
// EXEC CTTDLD,INP=tape.convert
//SYSIN DD *
RANGE FIRST=K00100,LAST=K00500,MEDIA=3480
//
Example 4
If you are consolidating two tape libraries and both libraries contain tapes with the same
volsers, you can rename the volsers for one set of tapes so that no conflict will appear in
the Media Database.
In this example, active 3480 type volumes made by vendor IBM with volsers FX0001-
FX0100 are converted to CONTROL-T, renamed and added to the Media Database.
Volsers FX0001-FX0100 are renamed MA0001-MA0100. The SL-names (the internal labels
of the volumes) remain FX0001-FX0100.
// EXEC CTTDLD,INP=TAPE.CONVERT
//SYSIN DD *
RANGE FIRST=FX0001,LAST=FX0100,MEDIA=3480,
VENDOR=IBM,RENAME=MA
//
CTTGVL User Interface to Stacking Facility
Utility CTTGVL assigns a volume to a given dataset before the dataset is allocated. The
utility returns a volume serial number (according to user specifications) for the file that
the user wishes to create.
When utility CTTGVL returns a volume serial number, the volume is assigned a status of
In-Use. This status prevents selection of the volume by other users. When a dataset is
written to the selected volume, the In-Use status is removed from the volume.
If, for some reason, (e.g., because no dataset was written to the volume) a volume selected
by utility CTTGVL remains with a status of In-Use for three days, the status is removed by
retention management utility CTTRTM (which is normally run as part of the CONTROL-T
New Day procedure).
To select the appropriate volume, utility CTTGVL scans the CONTROL-T rules (according
to supplied parameters) so that the volume which is returned is allocated from the
appropriate pool.
The utility can optionally activate the CONTROL-T Stacking facility, which searches the
Media Database to locate a volume which has enough free space to hold the new file. Upon
user request, or if such a volume cannot be located, a scratch volume can be returned
instead.
Utility CTTGVL uses the active CONTROL-T environment (in ECSA). Therefore, the
utility can be called only on a CPU on which the CONTROL-T environment is initialized.
If utility CTTGVL is run simultaneously on more than one CPU, an enqueue manager (e.g.,
GRS) must be used to ensure that no volume is selected more than once by the utility.
The utility requires APF authorization. Therefore, it must reside in an authorized library
and the load module that contains it (if linked to the user program) must also be
authorized (AC=1).
This utility is not a standalone utility. It must be called by an application using one of the
following methods. See sample CTTGVLD in the IOA SAMPLE library.
Using a Call Command
CALL CTTGVL,(dataset,jobname,stackid,volser,label),VL
Using a Link command
LINK EP=CTTGVL,PARAM=(dataset,jobname,stackid,volser,label),VL
Parameters
Utility CTTGVL receives parameters in the standard method (Register 1 points to a list of
addresses). The following parameters should be passed to the utility:
Input Parameters
DATASET Name of the dataset. Maximum length: 44 characters can be specified.
Mandatory.
JOBNAME Name of the job. Maximum length: eight characters can be specified.
Optional.
STACKID Indicator (one character in length) specifying whether stacking is
enabled/disabled:
Y (Yes) Stacking is enabled.
N (No) Stacking is disabled.
Output Parameters
VOLSER Volume serial number. Six characters must be specified.
LABEL Hexadecimal representation (two bytes in length) of the label number.
Return Codes
0 Function completed successfully
4 No matching volume found
8 Invalid stacking indicator
12 CONTROL-T is not active
16 Database access failed a detailed message can be found in the Job log or
System log
Example
This utility must be called from an application program using one of the following
methods:
Using a Call command:
CALL CTTGVL,(DSN,JOBNAME,STACKID,VOLSER,LABEL),VL
Using a Link command:
LINK EP=CTTGVL,PARAM=(DSN,JOBNAME,STACKID,VOLSER,LABEL),VL
Assume the following definitions for either of the above methods:
DSN DC CL44MY.DSN Dataset name
JOBNAME DC CL8MYJOB jobname
STACKID DC CY Stacking indicator
VOLSER DS CL6123456 Volume serial number
LABEL DS H01 Label
CTTIDB Check Integrity of the Media Database
Utility CTTIDB checks the integrity of the Media Database (MDB) and provides statistical
information. Warning messages are provided if database inconsistencies are detected.
These inconsistencies may occur during conversion from another database, or as a result of
system crashes, utility abends, etc., during processing.
Examples of inconsistencies:
Errors in the chain links which connect volumes in a multi-volume chain.
Existence of active volumes which do not contain datasets.
Existence of scratch volumes which do contain datasets.
Discrepancies between various Media Database records.
Upon completion, utility CTTIDB provides statistics about the Media Database. The utility
can be run for statistical purposes. The statistics provided include:
Number of used data records.
Number of used index records.
Number of free data records.
Number of free index records.
Totals by type of record (volume, dataset, scratch).
It is recommended that this utility be run immediately after conversion from another
database, after a system crash, or after a CONTROL-T utility abends during processing.
This utility can be run whenever Media Database statistics are desired.
Note Utility CTTIDB requires exclusive access to the Media Database. Other utilities which
access the Media Database (e.g., CTTRTM or CTTVTM) cannot run concurrently with
this utility.
Note The SYSIN statement and the TYPERUN parameter are optional.
// EXEC CTTIDB
//SYSIN DD *
TYPERUN MODE=CHECK[,USEDAYS=n]
Parameters
TYPERUN Run type.
MODE Operation mode. Mandatory. Valid values:
CHECK Only messages about inconsistencies are provided. Default.
USEDAYS Threshold number of days since the volume was last
accessed. Messages are only generated for volumes that
are in use for more than the specified number of days.
Default: 7 (days).
Return Codes
8 Problem detected in the Media Database Execution continues.
12 Invalid control parameter given Execution terminates.
16 Error opening DCB Execution terminates.
Greater than 16 Severe error the error is accompanied by an appropriate message
indicating the problem Execution terminates.
Example
In the following example, utility CTTIDB produces a transaction file of problems and
issues appropriate messages.
// EXEC CTTIDB
//SYSIN DD *
TYPERUNMODE=CHECK,USEDAYS=6
CTTMER Merge Records Into the Media Database
Utility CTTMER is used to merge Media Database records into a target Media Database
via an extract file created by utility CTTSPL.
Notes There is no need to shut down CONTROL-T while running this utility.
Utility CTTMER is used together with utility CTTSPL in the split and merge process.
See Split and Merge Processing in the description of utility CTTSPL in this section
before using utility CTTMER.
After running of utility CTTMER it is highly recommended that you run utility
CTTVTM in SLOTBLD mode to rebuild the slot definitions. After completion of utility
CTTVTM, use utility CTTIDB to check the integrity of the target Media Database.
Utility CTTMER automatically updates the Media Database index component. There is
no need to run utility CTTBIX after the run of this utility.
// EXEC CTTMER,MRGIN=repdata-file
//DAIN DD *
TYPERUN MODE=NORMAL|SIMULATE|RSIMULAT[,DBGLEVEL=nnn]
/*
Parameters
repdata-file Extract file created by utility CTTSPL. The name of this file is
supplied via parameter MRGIN. Mandatory.
The extract file is a predefined sequential file
(olpreft.olvert.REPDATA) allocated as one of the CONTROL-T
operations libraries at time of CONTROL-T installation (at the site
containing the source Media Database).
TYPERUN The TYPERUN statement is specified via DD statement DAIN. The
format for this statement:
TYPERUN MODE=NORMAL|SIMULATE|RSIMULAT[,DBGLEVEL=nnn]
where:
MODE Operation mode. Mandatory.
NORMAL Normal operation mode. Records in the
extract file are merged into the Media
Database. Default.
SIMULATE Simulation mode. No changes are made to
the Media Database. Messages describing
simulated operations are sent to the Utility
log.
RSIMULAT Restart simulation. If a first run of utility
CTTMER abended, the utility can be rerun
in this mode prior to rerunning it in
NORMAL mode and thus causing an
automatic restart. Only the deletion of
records already merged into the Media
Database is simulated.
Note Only the deletion of data records, V-keys, D-keys
and T-keys is simulated. Deletion of L-keys is not
simulated.
DBGLEVEL Debug level. A numeric value from 1 to 255 can be
specified. Optional.
Note This parameter should only be used if requested
by your IOA representative.
Example
In this example utility CTTMER merges all records in the extract file
(CTT.V514.REPDATA) into the Media Database.
// EXEC CTTMER,MRGIN=CTT.V514.REPDATA
//DAIN DD *
TYPERUN MODE=NORMAL
/*
Return Codes
8 Initialization problem.
12 Merge failed some of the records to be merged already exist in the
target Media Database.
16 Unable to access the restart information from the Trace file.
20 Simulation mode is not allowed while restart is required.
24 Another utility is currently executing the Media Database is locked.
28 Restart processing failed.
Greater than 28 Severe error the error is accompanied by a message describing the
problem.
CTTMUP Manually Update the CONTROL-T Repository
Utility CTTMUP can be used to update information in the Media Database and/or the
Stacking Database. This utility is especially useful for modification of information for a
small number of datasets or volumes (e.g., to correct file integrity errors which resulted
from a system crash or a utility abend).
Notes Utility CTTMUP is an extremely powerful utility which modifies your tape
management information. Great care should be taken that it is being used correctly.
Before using utility CTTMUP, it is important to familiarize yourself with the structure
of the file you are planning to update (described in Section 7 of this guide). Attempting
to update tape management information proper understanding structure of the
relevant file can lead to integrity errors.
Updating the Media Database
Utility CTTMUP can update fields of a volume or dataset record in the Media Database
(MDB). Update is performed independently for volume and/or dataset records. When
updating a volume record, CTTMUP does not automatically update the corresponding
dataset records and vice versa. (For example, the dataset count in a volume record is not
updated when CTTMUP adds a dataset.) Therefore, when using this utility, be sure to
update all connected records. For more information, see Special Notes Regarding Media
Database Control Statements following the parameter descriptions of this utility (below).
When a dataset is added, utility CTTMUP can optionally search the rules (as if the dataset
is being created on removable media) to determine retention and vaulting criteria to be
assigned to the dataset and the volume containing the dataset.
Refer to Manual Update of the Media Database in Section 7 of this guide for a general
description of how this utility can be used to update the Media Database.
Updating the Stacking Database
Utility CTTMUP can be used to update fields in the Stacking Database (e.g., to modify the
expected length of a dataset, or to indicate whether or not a dataset should be considered
stackable).
Before updating the Stacking Database via utility CTTMUP, it is recommended that you
use utility CTTSTKR to generate a report from information currently in the Stacking
Database. This report will help you determine what (if any) changes need to be made to the
Stacking Database.
// EXEC CTTMUP
//SYSIN DD *
TYPERUN MODE=NORMAL|SIMULATION[,RULEINFO=YES|NO][,CHECK=YES|NO]
[,APPLY=GROUP][,DBGLEVEL=nnn]
<CONTROL STATEMENTS>
Parameters
The following parameters can be specified for utility CTTMUP.
Note Only parameter MODE is relevant for updates to the Stacking Database. If other
parameters are specified, they are ignored while the utility is updating stacking
statistics records.
TYPERUN Run type.
NORMAL Normal operation is performed.
SIMULATION Simulation mode is performed.
RULEINFO Whether or not to apply rule information (e.g., Retention
criteria) when adding a dataset to the Media Database.
Y (Yes) Apply rule information to the Media
Database record. Default.
N (No) Do not apply rule information to the
Media Database record.
CHECK Whether or not to check Media Database integrity after
performing the requested changes.
Y (Yes) Check the integrity of the Media
Database. Default.
N (No) Do not check the integrity of the Media
Database.
APPLY Determines which volumes will be affected by the
VOLUPD control statement. Optional. Valid value:
GROUP The VOLUPD statement is applied to all
volumes in the multi-volume chain
containing the volume specified in the
VOLSER field of the VOLUPD
statement.
Note If parameter APPLY is not specified, the VOLUPD
statement is applied only to the volume specified in
the VOLSER field of the VOLUPD statement.
Control Statements
Control Statements specify the update function to be performed, the fields to be updated
and the update values.
Valid Control Statement functions for Media Database update and Stacking Database
update are listed below, followed by information on specifying fields and values.
Media Database Update Control Statements
Some of the functions are valid for volume type records only and some functions are valid
for dataset records only. Media Database fields which can be updated by this utility are
listed in Table 1 and Table 2 in Logical Field Names for the CONTROL-T Repository in
Appendix D. (They are the same fields that can be specified in INCLUDE/EXCLUDE
statements of other utilities.)
VOLADD Add volume. One field is mandatory for this function:
VOLSER Volume serial number.
VOLUPD Update volume. The VOLSER field is mandatory for this function:
VOLDEL Delete volume. The volume to be deleted must be identified by one of
two fields (either field is mandatory):
-either-
-or-
DVLRBA Internal CONTROL-T record identifier.
If DVLRBA is used to identify the volume, VOLSER can be used for
verification.
VOLSCR Expire all the datasets in the volume and change the status of the
volume to scratch. One field is mandatory for this function:
VOLBIX Rebuild the indexes of a volume and of all its datasets. The volume
must be identified by one of two fields (either field is mandatory):
-either-
-or-
DVLRBA Internal CONTROL-T record identifier.
verification.
GRPSCR Expire all datasets of all the volumes in the group and change the
status of those volumes to scratch. One field is mandatory for this
function:
VOLSER Volume serial number of one of the volumes in the
group.
GRPBIX Rebuild the indexes of all the volumes and of all the datasets in the
group. One of the volumes in the group must be identified by one of
two fields (either field is mandatory):
-either-
VOLSER Volume serial number of a volume in the group.
-or-
DVLRBA Internal CONTROL-T record identifier of a volume in
the group.
verification.
DSNUPD Update dataset record. The record to be updated must be identified in
one of two ways (either set of fields is mandatory):
-either-
DSVOLSER Datasets volume serial number.
DSLABEL Datasets label number (file sequence).
-or-
DDSRBA Internal CONTROL-T record identifier.
If DSNAME is specified, it is used for verification only. The dataset
name cannot be modified.
DSNUPDN Update dataset name (the DSNAME field in the dataset record). Only
the parameters shown below are valid for this control statement.
NEWNAME New dataset name. Mandatory.
DSNAME The current dataset name (before update). This
parameter is used for verification only. The dataset
cannot be modified.
The record to be updated must be identified in one of two ways (either
set of fields is mandatory):
-either-
DSLABEL Datasets label number (file sequence).
-or-
DSNADD Add dataset record. Three fields are mandatory for this function:
DSLABEL Datasets label number.
DSNAME Dataset name.
DSNDEL Delete dataset record. The record to be deleted must be identified in
one of two ways (either set of fields is mandatory):
-either-
DSVOLSER Datasets first volume.
-or-
If DDSRBA is used to identify the record, DSVOLSER and DSLABEL
can be used for verification.
If DSNAME is specified, it is used for verification only.
DSDELL Delete L-type key for a volume. Two fields are mandatory for this
function:
RECDEL Delete Media Database record (any type). One field is mandatory for
this function:
RBA Internal CONTROL-T record identifier.
RECUPD Modify records of any type in the Media Database (e.g., Restart
Control records, Slot Definition records).
This function includes the following control statements:
RECUPD RBA=rba
VER offset data
REP offset data
ENDUPD
Statement RECUPD selects a records from the Media Database for
update. It must be the first statement specified. This statement
includes the following parameters:
RBA Internal CONTROL-T record identifier of the record to
be updated.
VER Identifies existing data to be verified before updating
the record.
REP Identifies the new data that should replace existing
data.
ENDUPD Identifies the end of the RECUPD function. It must be
the last statement in this function.
An unlimited number of paired VER and REP statements can follow
the RECUPD statement. These statements are formatted like the VER
and REP statements of MVS utility AMASPZAP:
Data is provided in both the VER and REP statements, as follows:
offset Offset of the data from the beginning of the record (four
digits in hexadecimal format, from 0000 to 01CC).
data Record data for verification or replacement (in
hexadecimal ZAP format).
Example
This example updates the volume record with RBA=000104. Two
status bytes are verified on offset 0005 and status IN-USE then set.
RECUPD RBA=000104
VER 0005 8000
REP 0005 8002
ENDUPD
UPDQNM Change the QNAME in the Media Database (i.e., in the following files:
MDBD, MDBI, TRC, STKD, STKI). One field is mandatory for this
function:
QNAME New QNAME.
VOLSCRF Scratch a volume in the Media Database regardless of integrity errors.
One field is mandatory for this function:
Stacking Database Update Control Statements
Stacking Database fields which can be updated by this utility are listed in Table 7 in
Appendix D: Logical Field Names for the CONTROL-T Repository.
STKADD Add a record to the Stacking Database. The following fields are
mandatory for this function:
JOBNAME Name of the job that created the first generation of the
dataset.
STKUPD Update a record in the Stacking Database. The following fields are
mandatory for this function:
dataset.
STKDEL Delete a record from the Stacking Database (STK). The following
fields are mandatory for this function:
dataset.
Special Notes Regarding Media Database Control Statements
Function VOLBIX
This function is intended for use only when utility CTTIDB detected errors with V-indexes
(volume indexes). This function should not be used for L-index problems.
Function GRPBIX
Be sure that you have corrected all V-indexes before using this function.
This function corrects problems of L-indexes and D-indexes. It can be applied for a single
volume as well as for a multi-volume group.
Function VOLUPD
When this function is used to update fields MEDIA, LOCATION or SLOTNUM of the
volume, the slot in which a vaulted volume resided remains in status IN USE.
In this case, to synchronize the Slot Definition Records in the Media Database, run
utility CTTVTM with the following control statement:
TYPEVLT MODE=SLOTBLD
A single status bit can be set in a specific status byte of a volume/dataset record.
For example to turn on status PVLT (Potential Vault) on a volume record, include the
following statement:
VOLUPD.....,VOLIND=+PVLT
To turn off the above status bit include the following:
VOLUPD.....,VOLIND=-PVLT
Function VOLSCRF
This function is intended for use only after integrity errors occurred while trying to scratch
records via function VOLSCR or GRPSCR.
This function affects single volumes only. To scratch a multi-volume group, specify this
function for each volume separately.
Specifying Fields and Values
The following points should be considered when specifying fields and values for this utility:
Date Fields Format is yymmdd or yyyymmdd.
Time Fields Format is hhmmss.
Numeric Fields Leading zeroes are not required.
Embedded Blanks Should only be used if the value is enclosed in either single or double
quotes.
Quotation Marks ( or )
If the value begins and ends with either single or double quotes, the
quotation marks are interpreted as markers of the beginning and end
of the value. To include a quote mark in a string (value), use the other
type of quote mark to mark the beginning and end of the string. For
example, a single quote (apostrophe) can only be included in the value
if the value is enclosed in double quotes ().
Null Values Specify a null value for a field by specifying the field without a value
(e.g., VOLSER,).
Retention Criteria Fields
Specification of retention criteria requires two fields/values:
Retention type.
Retention data.
If retention data is specified without specifying the retention type, the
retention type defaults to DATE.
Fields with Predefined Valid Values
Certain fields have a predefined set of valid values (e.g., valid values
for field VOLSTAT are ACTIVE, VAULTED).
Valid values for these fields are listed in Table 1 and Table 2 in
Appendix D: Logical Field Names for the CONTROL-T Repository.
Values can also be specified in hexadecimal format (e.g.,
VOLSTAT=X88, which means Active and Vaulted).
Status Bits A single status bit can be set in a specific status byte of a
volume/dataset record.
For example, to turn on status PVLT (Potential Vault) on a volume
record, include the following statement:
VOLUPD.... ,VOLIND=+PVLT
To turn off the above status bit, include the following:
VOLUPD.... ,VOLIND=-PVLT
Specific Field Recommendations
LBLNUM Last label number on the volume. This value cannot be less than the
value of ACTIVEDS (number of active datasets on the volume). If not
specified, LBLNUM defaults to the value of ACTIVEDS.
Return Codes
4 Minor errors occurred. Operation continues
12 Load of other CONTROL-T programs failed
16 I/O error
20 Input Control Statement error
24 Authorization failure (by security exit)
28 Invalid return code from routine CTTEXP
Example 1
Convert scratch volume DDD020 to active status and add dataset FILE7 to the volume.
// EXEC CTTMUP
//SYSIN DD *
TYPERUN MODE=NORMAL
VOLUPD VOLSER=DDD020,ACTIVEDS=1,VOLSTAT=ACTIVE
DSNADD DSVOLSER=DDD020,DSLABEL=1,DSNAME=FILE7,
CREDT=950622,CRETM=142500,CREJBN=JOB1
Example 2
Rebuild a chain of two volumes. The first volume, PRD001, has two datasets on it. The
second dataset reached the end of the first volume and continued on the second volume,
PRD002.
//JOB NAME JOB ....
//CTTMUP EXEC CTTMUP
//SYSIN DD *
TYPERUN MODE=NORMAL,RULEINFO=YES,CHECK=NO
VOLUPD VOLSER=PRD001,VOLSTAT=ACTIVE,VOLSEQ=1,ACTIVEDS=2,LBLNUM=2,
MEDIA=3480,LOCATION=MAINLIB,FIRSTVOL=PRD001,
NEXTVOL=PRD002,PREVVOL=
VOLUPD VOLSER=PRD002,VOLSTAT=ACTIVE,VOLSEQ=2,ACTIVEDS=1,LBLNUM=2,
MEDIA=3480,LOCATION=MAINLIB,FIRSTVOL=PRD001,
NEXTVOL=,PREVVOL=PRD001
DSNADD DSVOLSER=PRD001,DSLABEL=1,DSNAME=PROD.BACKUP.G0001V00,
VOLSNUM=1
DSNADD DSVOLSER=PRD001,DSLABEL=2,DSNAME=PROD.BACKUP.G0002V00,
VOLSNUM=2
//
Considerations
This example assumes that PRD001 and PRD002 are defined in the Media Database
and are in SCRATCH status. If these volumes are not defined in the Media Database,
you must change the first two control cards from VOLUPD to VOLADD.
Parameter ACTIVEDS is set to 2 for PRD001 because PRD002 contains the two
datasets. PRD002 contains only the second dataset, so ACTIVEDS is set to 1 for
PRD002.
LBLNUM is set to 2 for both volumes because the highest label number on both of
volumes is label 2.
The second dataset, PROD.BACKUP.G0002V00 has VOLSNUM=2 because it spans the
two volumes.
RULEINFO=YES indicates that retention and vaulting attributes are automatically
taken from the rules. It is therefore unnecessary to specify retention and vaulting
information.
Example 3
Update a record in the Stacking Database to indicate that dataset ACCT.JAN1 is stackable
and update a different record in this file to indicate new maximum and minimum lengths
for dataset ACCT.FEB2.
//CTTMUP EXEC CTTMUP
//SYSIN DD *
TYPERUN MODE=NORMAL,CHECK=NO
STKUPD DSNAME=ACCT.JAN1,JOBNAME=JOB1,STATUS=STK,
STKUPD DSNAME=ACCT.FEB2,JOBNAME=JOB2,MAXSIZE=20480,MINSIZE=1024
//
CTTRCV Recover the Media Database Using Trace File
Utility CTTRCV recovers damaged Media Database (MDB) contents according to trace data
recorded during Media Database update operations. The utility can perform either a
physical or a logical recovery.
Physical Recovery (Roll Forward)
Physical recovery assumes that the last available backed-up Media Database was
restored to disk (see utility CTTTRB in this section). From this point forward, the
recovery is performed according to trace data.
Trace records are read starting with the first record after the Media Database backup
record. The recovery continues until the last trace record is reached. When the process
is finished, the Media Database will have been brought back to the condition it was in
before it was damaged.
In situations where no Media Database backup has been performed, the recovery can be
started from the first trace record.
While the physical recovery process is running, the CONTROL-T environment should
be inactive (or unpredictable results may occur).
Logical Recovery (Roll Back)
Logical recovery rolls back selected changes from the current Media Database. This
type of recovery can be performed when a user modifies the status of one or more Media
Database records and subsequently discovers that these modifications should be
reversed. A good example of this scenario is the run of a job which scratches a series of
active volumes or moves a series of volumes to a vault incorrectly.
When this type of recovery is used, the trace records are read backward (starting from
the last record towards the first record). The improper modifications are reversed in a
way that restores the Media Database to the condition it was in prior to the improper
modifications.
To maintain the logical consistency of the Media Database, the utility must verify that
the current contents of the Media Database match the information in the Trace file.
Therefore, before a Media Database operation is reversed, the utility checks that the
current Media Database reflects that operation. For example, if the status of a volume
was changed from Active to Scratch by TSO user ABC and a logical recovery is
performed on all operations performed by user ABC, the utility verifies that the current
volume status in the Media Database is Scratch before the recovery reverses the
operation. The check can be bypassed (by specifying FORCE=YES) but this may lead to
unpredictable results.
// EXEC CTTRCV
//SYSIN DD *
RECOVER TYPE=PHYSICAL|LOGICAL [MODE=SIMULATION|NORMAL]
[,FROMREC=LASTBKP|FIRSTREC][,CHECKACT=YES|NO][,RECAT=YES|NO]
[,FORCE=YES|NO]
//
Parameters
Utility parameters are supplied via DD statement SYSIN:
RECOVER Determines the type of recovery that should be performed.
TYPE Type of the recovery. Mandatory.
PHYSICAL A physical (roll forward) recovery is to
be performed.
LOGICAL A logical (roll back) recovery is to be
performed.
MODE Mode of recovery. Optional.
SIMULATION Simulation mode. Trace records (and
Media Database records when needed)
are read. The Media Database is not
updated and datasets are not
recataloged.
NORMAL Normal mode. Default. Trace records
(and Media Database records when
needed) are read. Updates are actually
performed on the Media Database (i.e.,
the Media Database is updated).
FROMREC Starting point of the recovery. Can only (and must) be specified when
TYPE=PHYSICAL.
LASTBKP The recovery starts from the point where the Media
Database was last backed up.
FIRSTREC The recovery starts from the first Trace
record. This option is useful for new
sites which have not yet performed any
Media Database backups.
CHECKACT Check whether or not CONTROL-T is active before
starting the recovery. When recovery is performed, the
CONTROL-T Real-time environment should not be active
(i.e., it should be down or suspended). In Simulation
mode, this parameter has no effect.
Y (Yes) If, before starting the recovery, CONTROL-T
is active, recovery will not be started.
N (No) Recovery will be started whether or not
CONTROL-T is active.
Note Specifying NO can cause
unpredictable results and the
loss of Media Database integrity,
if CONTROL-T is active.
This value is useful to initiate a recovery in a test
environment on a test Media Database while the
production environment is still active.
RECAT In logical (roll back) recovery, indicates whether datasets that
were uncataloged by utility CTTRTM should be recataloged.
Y (Yes) Recatalog all datasets that were
uncataloged.
Note The same catalog environment
that existed for CTTRTM is
required by CTTRCV.
N (No) Do not recatalog datasets.
FORCE In logical (roll back) recovery, indicates whether a check will be
performed to verify that the current contents of the Media
Database match the operation that should be reversed.
Y (Yes) Perform the reversal operation without
performing the check.
Note Specifying YES can cause
unpredictable results and the
loss of Media Database integrity.
N (No) Perform the reversal operation only if all
checks were performed successfully.
INCLUDE/ EXCLUDE
The scope of the utility can be limited by one or more INCLUDE or
EXCLUDE statements. INCLUDE/EXCLUDE statements are optional
and are valid only when a logical (roll back) recovery is performed
(i.e., TYPE=LOGICAL).
For more information about INCLUDE/EXCLUDE statements for this
utility, refer to Logical Field Names for the CONTROL-T Repository
in Appendix D.
For additional information on INCLUDE/EXCLUDE statements, see
Record Selection Logic (INCLUDE/EXCLUDE Statements) earlier in
this section.
Return Codes
0 Recovery operation performed successfully.
4 Input statement(s) missing.
8 DCB open error occurred.
12 Input statement parsing error or validation error occurred.
16 CONTROL-T Control Table (TCT) load failed.
24 Media Database/Trace file I/O error occurred.
28 Logical error in Media Database (for TYPE=LOGICAL).
32 CONTROL-T Real-time environment is active.
Example 1
Recover a damaged Media Database. The last available Media Database backup has been
restored to disk.
//EXEC CTTRCV
//SYSIN DD *
RECOVERTYPE=PHYSICAL,FROMREC=LASTBKP
Example 2
Reverse all changes performed by user M27A from July 19th, 13.40.00, to July 22nd,
12.24.45:
// EXEC CTTRCV
//SYSIN DD *
RECOVER TYPE=LOGICAL,RECAT=YES
INCLUDE JOBNAME=M27A,DATE=970719,TIME>134000
INCLUDE JOBNAME=M27A,DATE>970719
EXCLUDE DATE>950721
INCLUDE JOBNAME=M27A,DATE=970722,TIME<122445
Rel. 5.1.4 Administrator Guide 9 195
CTTRPT Database Extraction and Report Utility
Utility CTTRPT extracts data from the Media Database (MDB) via Extract parameters and
generates reports from the extracted data via Report Formatting parameters.
Data extraction and report generation are performed in a single utility run. Both
Extraction parameters and Report Formatting parameters are specified in the utility run.
Instead of extracting entire records, the utility only extracts information required for the
report from the Media Database (or from the extracted dataset described above) and
produces the report. There is no need to create a dataset for saving the extracted
information, although this can be done if desired.
This method of report generation is the most efficient when a single report is required.
It is also most efficient when alDts of subsequent reports can be satisfied from the
extracted data (i.e., when no additional data is required by subsequent reports). In this
case, the extracted data should be saved in a dataset for subsequent runs of the utility.
At least one group of parameters (i.e., Extract parameters or Report Formatting
parameters) must be specified.
The dataset for holding extracted information is specified in DD statement REPDATA.
Primary Key, Primary Fields and Primary Lines in Report Generation
The user can define up to two lines which comprise the report output (i.e., the user
determines which fields are included in the report lines).
Many fields in a report maintain the same value for many records (e.g., vault name for a
multi-volume group). These fields are called primary fields and one of them is the primary
key. (The field which is the primary key and the fields which are the primary fields are
determined by the type of report being created.)
Via parameter ID=P|S, the user can designate a report line as a primary line. Primary
lines are only printed when the primary key changes value.
The primary key and the primary fields are determined as follows:
In the GENERAL report, the primary key is determined by the PATH parameter
specified in the EXTRACT statement.
If PATH=VOLUME/ALLDATASETS or PATH=VOLUME/FIRSTDATASET is specified,
the primary key is the volser and the primary fields are the fields extracted from
volume record.
If PATH=DATASET/ALLVOLUMES or PATH=DATASET/FIRSTVOLUME is specified,
the primary key is the datasets volser and datasets sequence number; and the primary
fields are the fields extracted from the dataset record.
In the DISTRIB report, the primary key is the volumes volser (or the first volumes
volser in a multi-volume chain) and the primary fields are the fields which have the
same value for all volumes in the chain (e.g., From Location and To Location) and the
fields extracted from the dataset record which determined the vaulting pattern.
In the SCRATCH report, the primary key is the volumes volser (or the first volumes
volser in a multi-volume chain) and the primary fields are the fields extracted from the
expiration dataset record.
9 196 Rel. 5.1.4 Administrator Guide
// EXEC CTTRPT
//REPDATA DD DSN=extract-dataset
//SYSIN DD *
[
<EXTRACT parameters>
<REPORT parameters>
]
Parameters
Extract Parameters
EXTRACT PATH=VOLUME|
VOLUME/FIRSTDATASET|
VOLUME/ALLDATASETS|
DATASET|
DATASET/FIRSTVOLUME|
DATASET/ALLVOLUMES
<INCLUDE/EXCLUDE statements>
EXTRACT PATH=rectype Specifies the type of records to be extracted. Valid values:
VOLUME Volume records are extracted.
VOLUME/
FIRSTDATASET
Volume records with only their first dataset
records are extracted. Abbreviation:
VOLUME/FIRSTDS.
VOLUME/
ALLDATASETS
Volume records with all their dataset records are
extracted. Abbreviation: VOLUME/ALLDS
DATASET Dataset records are extracted.
DATASET/
FIRSTVOLUME
Dataset records with only their first volume
records are extracted. Abbreviation:
DATASET/FIRSTVOL
DATASET/
ALLVOLUMES
Dataset records with all their volume records are
extracted. Abbreviation: DATASET/ALLVOLS
Multiple EXTRACT statements can be specified in DD statement SYSIN, but each
additional EXTRACT statement must follow the INCLUDE/EXCLUDE statements (if any)
and the Report Parameter statements of the preceding EXTRACT statement. When saving
extracted data in a dataset, if several EXTRACT statements are specified, only the data
extracted by the last EXTRACT statement is stored.
The scope of extraction can be limited by one or more INCLUDE or EXCLUDE statements.
INCLUDE/EXCLUDE statements can be specified only immediately after the EXTRACT
statement.
Subparameters specified in INCLUDE/EXCLUDE statements must not contradict the
PATH parameter of the EXTRACT statement. For example, if PATH=DATASET is
specified, subparameters specified in the INCLUDE/EXCLUDE statements must not
include fields from volume records.
The subparameters which can be specified in INCLUDE/EXCLUDE statements are listed
in Tables 1 and 2 in Appendix D of this manual. Refer to this appendix for more
information. For additional information about INCLUDE/EXCLUDE statements, see
Record Selection Logic (INCLUDE/EXCLUDE Statements) earlier in this section.
Report Formatting Parameters
REPORT NAME=GENERAL,TITLE=text,FOLD=YES|NO,
PAGESIZE=p,LINESIZE=s,MARGINS=m-n,SUMMARY=YES|NO,OUTDD=ddname
FIELDS field 1/options-1,field 2/options-2,...,field n/options-n,ID=P|S
SORTBY field 1/options-1,field 2/options-2,...,field n/options-n
ATTR FIELD=name,LENGTH=t,TITLE=text,EDIT=mask
BREAK FIELD=name,COLUMN=c,SUMTITLE=text,EDIT=numeric mask
REPORT Activates report formatting. The following subparameters can be
specified:
NAME Report name. Mandatory. Valid value:
GENERAL General report of information
extracted from the Media Database.
TITLE Report title. Optional. The maximum length: 64
characters. Default: General Report.
FOLD Indicates whether or not all report data should be
printed in upper case. Valid values:
Y (Yes) Print all report data in upper case.
N (No) Print report data in upper and lower
case. Default.
PAGESIZE Maximum lines in a page, where p is a numeric
value greater than 20. Optional. Default: 63.
LINESIZE Maximum characters in a line, where s is a numeric
value not greater than 255. Optional. Default: 127.
MARGINS=m-n Lowest (m) and highest (n) columns in a line, where m
is a numeric value greater than 0 and n is a numeric
value greater than m but not greater than s (the value
of LINESIZE). Optional. Defaults: m=1 and n=s.
SUMMARY=
YES|NO
Indicates whether or not to show a summary line for
each field break. Optional. Default: NO.
A field break occurs when there is a change in value
for a field which is specified in a SORTBY statement
with option /BRK, (or /B).
OUTDD JCL DD name of the output. Default: REPOUT.
FIELDS Output fields (i.e., fields required in the report) and the options that
can be applied to each field. Mandatory.
The GENERAL report can contain volume and dataset fields which
can be specified as INCLUDE/EXCLUDE subparameters and special
fields which cannot be specified as INCLUDE/EXCLUDE
subparameters (described with their attributes later in this utility).
Options Options can be added as a suffix to any output field
in the list (optional for each field). The slash (/)
preceding the option is required to distinguish the
option from the field. Any number of options can be
added to an output field. Available options:
/Ln Length of the output field. n must be a
numeric value which does not exceed
the length defined in the list of
available fields. This option should be
used for Alphanumeric and
Hexadecimal fields only. Optional.
This value, if specified, overrides a
LENGTH value specified in the ATTR
statement (see below).
/Cn Column in which the field should
begin in the printed output. If
specified for a field, it must be
specified for all preceding fields. n
must be a numeric value greater than
the last column of the preceding field
(determined by the preceding fields
beginning column and field length).
ID=P|S Output line indicator. This parameter designates an
output line as a Primary Line (P) or Secondary Line (S).
These values determine whether or not duplicate lines
are printed from Volume and Dataset data. Optional.
P Primary line indicator. The line is
only printed when a primary key
changes value.
S Secondary line indicator. A line is
printed for each record. Default.
SORTBY Sort order of the output fields (see FIELDS above). Optional.
Options Options can be added as a suffix to any output field
in the list (optional for each field). The slash (/)
preceding the option is required to distinguish the
option from the field. Any number of options can be
added to an output field. Available options:
/BRK or /B Insert a page break in the report
when the field changes its value. If
specified for a field, it must be
specified for all preceding fields.
/ASC Sort the field in ascending order.
Default.
/DSC Sort the field in descending order.
/RSR Reset the row number whenever the
value of the field changes. This option
is effective only when field ROWID is
specified in the FIELDS statement.
/RSP Reset the row number whenever the
value of the field changes. This option
automatically activates option /RSR.
Note Primary fields in a SORTBY statement should be specified before
non-primary fields.
Examples of SORTBY usage are provided below.
Example 1 SORTBY LOCATION /BRK (or /B)
POOL/BRK/DSC,MEDIA/ASC
Output is sorted by vault (LOCATION) in ascending
order (the default) by pool (POOL) within a vault in
descending order and by media (MEDIA) within a
pool in ascending order. A page break is inserted
each time the vault or pool changes.
Example 2 SORTBY LOCATION /BRK/RSP,
MEDIA/BRK/RSR,EXPDT/DSC
Output is sorted by vault (LOCATION) in ascending
order (the default) by media (MEDIA) within a vault
in ascending order (by default) and by expiration
date (EXPDT) within a media in descending order. A
page break is inserted for every change in vault and
media and the page number (and, by default, the row
number) is also reset each time the vault changes.
The row number is reset each time the media
changes.
ATTR Overrides default attributes defined for a field. Optional.
At least one optional parameter must be specified for statement ATTR.
An ATTR statement can be specified for any field, even a field not
included in a FIELD statement. The report, however, is not effected by
an ATTR for a field until the field is included in a FIELD statement.
(This means that an ATTR statement can be defined in advance for
each field, for use when the field appears in a FIELD statement.)
Member ATTRGEN in the CONTROL-T PARM library contain sample
ATTR statements for the GENERAL report.
The following parameters apply to the field whose attributes should be
changed:
FIELD=name Name of the field. Mandatory.
LENGTH=t Length of the output field. t must be a numeric value
which must not exceed the field length specified in
the list of available fields. Optional. An /Ln value, if
specified for the same field in the FIELDS
statement, overrides this value.
TITLE=text Field header. text is any character string (enclosed
in apostrophes). To split the header between lines,
insert a slash (/) before each line break. The number
of header lines in the report is determined by the
field whose TITLE parameter text has the highest
number of lines. Optional.
For example, if the following is specified:
ATTR FIELD=VOLSER
TITLE=Volume/Serial/Number
The header for field VOLSER will span three output
lines as follows:
Volume
Serial
Number
EDIT=mask Field format, as specified through a mask. The mask
must be enclosed in apostrophes. Parameter EDIT
cannot be specified for character and hexadecimal
fields. Valid mask formats:
Numeric Format
For numeric fields only. The mask can consist of Zs
and 9s and commas, where 9 represents any digit, Z
represents a digit which is suppressed if its value is a
leading zero and comma is a separator between digits.
When specifying a numeric format, the following
rules apply:
A 9 cannot precede a Z in the mask.
A comma cannot be the first or last character of the
mask.
Example
Assume number 1234 is being edited (and b indicates
blank)
Mask Specified Result
ZZ,ZZ9 b1,234
Z,999 1,234
999999 001234
ZZZ,ZZZ bb1,234
Date Format
For Date fields. Valid mask combinations can have
no more than one day symbol, one month symbol and
one year symbol.
Valid symbols:
DD Day (i.e., values 1 31).
MM Month (i.e., values 1 12).
MMM Month (i.e., values Jan Dec).
YY Year (last two digits, i.e., 00 99).
YYYY 4-digit year (e.g., 1998).
Symbols can be optionally separated by one or more
separation characters: /, ., -, blank, etc.
Example
Assume the date being formatted is August 23, 1998.
Mask Specified Result
DD/MM/YY 23/08/98
YYYY.MM.DD 1998.08.23
MM-DD-YYYY 08-23-1998
DD MMM YYYY 23 Aug 1998
MMM DD YYYY Aug 23 1998
YY/MM 98/08
Boolean Format
For Boolean fields (i.e., fields that contain a
True/False or Yes/No condition). The specified
FIELD is checked for a true/false condition in the
record.
The mask can contain either one value or two values
separated by a slash (/). A null value can be specified
on either side of the slash.
When one mask value is specified, the value is
printed in the report only if the FIELD checks true
in the record. (If the FIELD checks false, the mask
value is not printed; blanks are printed instead.)
When two values are specified, the first value is
printed in the report if the FIELD checks true in
the record. The second value is printed if the field
checks false.
Examples
(1) ATTR FIELD=SCRATCH,
TITLE=Scratch,EDIT=Yes/No
(2) ATTR FIELD=ACTIVE,
TITLE=Type,EDIT=Active/Scratch (3)ATTR
FIELD=VAULTED, TITLE=V,EDIT=v
(4) ATTR FIELD=EDM, TITLE=Edm,EDIT=/No
The following table shows the results of Boolean
editing for these examples.
Example
Field
Tested
Field
Title
Printed
Result if
TRUE
Printed
Result if
FALSE
(1) SCRATCH Scratch Yes No
(2) ACTIVE Type Active Scratch
(3) VAULTED V v (blank)
(4) EDM Edm (blank) No
BREAK Attributes of the summary line printed at the bottom of the page when
a field break occurs. Optional.
For each field break, the user can specify a header and variables
which indicate the number of primary and secondary lines printed and
the value of the field before the break occurred.
At least one optional parameter of the BREAK statement must be
specified.
A BREAK statement can be specified for any field, even a field that is
not included in a SORTBY statement. The report, however, is not
effected by a BREAK for a field until the field is included in a
SORTBY statement with option /BRK and SUMMARY=YES has been
specified in the REPORT statement.
(This means that a BREAK statement can be defined in advance for
each field when the field appears in a SORTBY statement and report
summaries are included.)
FIELD=name Name of the field. Mandatory.
COLUMN=c Column of the output line in which the summary
title will begin printing. c must be numeric.
Optional. The default is the report start margin
specified in parameter MARGINS of the REPORT
statement.
SUMTITLE=text
Summary text to be printed when the value of a field
changes. text can be any string of characters. It must
be enclosed in apostrophes and can contain one or
more of the following variables:
%FIELD Value of the field before the break
occurred.
%COUNTP Number of primary lines printed
before the break occurred.
%COUNT Number of secondary lines printed
before the break occurred.
The default value of SUMTITLE text is:
TOTAL IN %FIELD IS %COUNT
Note If parameter ID is not specified in the FIELDS statement or there
is only one FIELDS statement, the value of %COUNT is equal to
the value of %COUNTP.
EDIT=numeric mask
Numeric format of %COUNT and %COUNTP
variables. Optional. The default is ZZ,ZZ9. (See the
Numeric format example for parameter EDIT in the
ATTR statement above.)
Example
REPORT NAME=DISTRIB,SUMMARY=YES
FIELDS ...
SORTBY TOLOC/BRK/RSR/RSP,
FROMLOC/BRK (or /B)
TOSLOT,FROMSLOT,
VOLSER
BREAK FIELD=TOLOC,
SUMTITLE=Total Volumes
Moved To %FIELD is
%COUNT, EDIT=Z,ZZ9
BREAK FIELD=FROMLOC,
SUMTITLE=Total Volumes
Moved From %FIELD is
%COUNT, EDIT=Z,ZZ9
ATTR ...
Special Fields
The following table contains a list of derived fields that can be included in the GENERAL
report. These fields do not exist in the Media Database records, but their values are
derived from either volume or dataset records, as indicated, where:
V Indicates the source is a volume record.
D Indicates the source is a dataset record.
ROWID is a calculated field and therefore no source is indicated.
These fields cannot be subparameters of INCLUDE/EXCLUDE statements.
Field
Name Source Type
Default Size
in Bytes Description
ROWID Numeric 5 Row (line) number. Can be
specified for either Primary or
Secondary lines but not for both.
VOLSTAT V Character 12 Volume statuses as shown below
the header STATUS in Screen
TI. See the description of Screen
TI in Section 2 of the
Field
Name Source Type
Default Size
in Bytes Description
CONTROL-T User Manual.
DSSTAT D Character 12 Dataset statuses as shown below
the header STATUS in Screen
TI. See the description of Screen
TI in Section 2 of the
VSTATX V Hexadecimal 8 Volume statuses in Hexadecimal
representation.
DSTATX D Hexadecimal 4 Dataset statuses in Hexadecimal
representation.
POOL V Character 15 Pool name derived from the
volser of the volume record.
DSPOOL D Character 15 Pool name derived from the
volser of the dataset record.
Return Codes
8 Missing DD statement(s) or open error occurred.
12 Control card error.
16 Operation code not found.
20 Invalid operation code.
24 Syntax error in FIELDS or SORTBY statement.
28 Field name specified in FIELDS or SORTBY list is undefined.
32 Same parameter specified more than once.
36 Field name exceeds maximum length.
40 Invalid relation specified (must always be equal sign).
44 Report NAME is undefined.
48 /BRK not specified for the preceding field in SORTBY list.
52 FIELDS statement not specified.
56 Total of all field lengths requested in FIELDS statement exceeds the line size.
60 Continuation card expected but not received.
64 Invalid numeric value.
68 Option in FIELDS or SORTBY statement already specified.
72 ROWID specified in BREAK or SORTBY statement.
76 EDIT parameter in ATTR statement is invalid for specified FIELDS.
80 EDIT mask is not valid.
84 Specified number not in permitted range.
For example, end column of a MARGIN statement exceeds the LINESIZE
or a column in a FIELDS statement is outside the reports margins.
88 Column option (/C) not specified in the preceding field.
92 Specified column in a FIELDS statement is less than the sum of the
previous fields column and length.
96 Second EXTRACT statement did not come after report statements.
100 Load of CONTROL-T programs failed..
104 Load of POOL table failed.
108 Insufficient memory.
200 Fields in FIELDS or SORTBY statements do not fit the PATH parameter
of the EXTRACT statement.
Sample Reports
The reports listed below can be created via utility CTTRPT. These reports are located in
the IOA SAMPLE library.
Some of these sample reports contain question marks (??) where customization is
necessary. Replace the question marks with the desired values and use the appropriate job
to produce the report.
Reports
CTTRFSCR Full-scratch report. Lists all volumes with SCRATCH status in the Media
Database.
CTTRINV Vault inventory report. Lists all vaulted volumes and datasets in a
specified location.
CTTRINVT Comprehensive inventory report. Lists all volumes and datasets in the
Media Database.
CTTRSCRD Lists all volumes scratched on a specified date and the datasets residing
on these volumes.
CTTRDELV Lists all volumes with DELETED status.
CTTRCLN Clean report. Lists volumes that need to be cleaned (i.e., each volume
that has more than a specified threshold number of permanent I/O
errors).
CTTRRTNP Lists all datasets (and their volumes) according to expiration date type
(e.g., CYCLE or CATALOG).
CTTRLACV Lists all volumes accessed today.
CTTRDCRE Lists all datasets created yesterday.
CTTRMOVW Lists all volumes moved within the last seven days.
CTTRCHKI Lists all external volumes checked-in during the last 30 days).
CTTRUTIL Lists volumes that are under-utilized (less than less than 10 megabytes).
CTTRLAVJ Lists all volumes that were last accessed by a certain job since a specified
date.
CTTRWDCP Lists all datasets that were written in a certain system (CPU) since a
specified date.
CTTROUTL Lists all volumes in an out-location (borrower volumes).
CTTRLRTV Lists all volumes with high retention dates (e.g., after year 2001).
CTTRM10V Lists all multi-volume datasets which span more than ten volumes.
CTTRMACV Lists the most active volumes (accessed more than ten times since they
became active).
CTTREDM Lists all EDM volumes.
CTTRRCLV Lists all RECALLed volumes.
CTTRVUPD Lists all volumes that were manually updated by a specified user.
CTTRDUPD Lists all datasets that were manually updated by a specified user.
CTTRM25D Lists all volumes containing more than 25 active datasets.
CTTRVBOX Lists the volumes stored in a specified box.
CTTRBXLC Lists all volumes which are stored in boxes, according to location and
BOXID.
CTTRNRTR Lists all borrowed volumes which have not yet been returned.
Jobs for Report Production
The above reports are produced via the following jobs (which are located in the JCL
library):
REPFSCR Produces report CTTRFSCR (full-scratch report).
REPINV Produces report CTTRINV (comprehensive inventory report).
REPSJOB Produces all other reports. This job requires customizations to indicate
the desired report.
Example 1
Extract all datasets from location VAULT1 and generate a report showing all VAULT1
datasets and their volumes sorted by their pool name (DSPOOL) which is derived from
dataset volser.
//EXTRACT EXEC CTTRPT
//SYSIN DD *
EXTRACT PATH=DATASET/ALLVOLS
INCLUDE LOCATION=VAULT1
REPORT NAME=GENERAL,SUMMARY=YES,MARGINS=1-080,LINESIZE=080,
TITLE=Datasets in Vault VAULT1
FIELDS ROWID,FIRSTVOL,
DSNAME,DSLABEL,CREJBN,CREDT,LRECL,RECFM,
ID=P
FIELDS VOLSER/C13,MOVEDATE,VOLSEQ,SLOTNUM,
ID=S
SORTBY DSPOOL/BRK/RSP,FIRSTVOL,DSLABEL,VOLSEQ,SLOTNUM
BREAK FIELD=DSPOOL,COLUMN=10,EDIT=Z,ZZ9,
SUMTITLE=%FIELD Datasets in VAULT1: %COUNTP
ATTR FIELD=ROWID,TITLE=Row/Id,EDIT=ZZ,ZZ9
ATTR FIELD=FIRSTVOL,TITLE=First/Volume
ATTR FIELD=DSNAME,TITLE=/Dataset Name,LENGTH=24
ATTR FIELD=DSLABEL,TITLE=Ds/Seq.,EDIT=ZZ9
ATTR FIELD=CREJBN,TITLE=Create/Job
ATTR FIELD=CREDT,TITLE=Create/Date,EDIT=DD MMM YY
ATTR FIELD=LRECL,TITLE=Record/Length,EDIT=ZZ,ZZ9
ATTR FIELD=RECFM,TITLE=Record/Format
ATTR FIELD=DSPOOL,TITLE=Pool/Name
ATTR FIELD=VOLSER,TITLE=/Volser
ATTR FIELD=MOVEDATE,TITLE=Move/Date,EDIT=DD MMM YYYY
ATTR FIELD=VOLSEQ,TITLE=Vol/Seq.,EDIT=Z9
ATTR FIELD=SLOTNUM,TITLE=Slot/No.,EDIT=Z,ZZ9
A sample of the output report from the above example is illustrated below:
NEW DIMENSION SOFTWARE, LTD. CONTROL-T REPORT (REL 5.1.4)
Datasets in Vault VAULT1
-------------------------
Pool Name: POOL-NUMBER-1
Row First Ds Create Create Record Record
Id Volume Dataset Name Seq. Job Date Length Format
Move Vol Slot
Volser Date Seq. No.
------ ------------------------------------- ------------------ ------ ------
58 016475 FDRABR.VTSO006.C1004900 27 ZCOBKUPD 16 Jun 98 0 U
012517 23 Jun 1998 55 74
015692 23 Jun 1998 56 163
015646 23 Jun 1998 57 162
016024 23 Jun 1998 58 177
59 016475 FDRABR.VESAD1A.C1002800 28 ZCOBKUPD 16 Jun 98 0 U
016024 23 Jun 1998 58 177
015722 23 Jun 1998 59 167
016048 23 Jun 1998 60 178
012771 23 Jun 1998 61 90
60 016475 FDRABR.VVSAM00.C1001300 29 ZCOBKUPD 16 Jun 98 0 U
012771 23 Jun 1998 61 90
010096 23 Jun 1998 62 16
018862 23 Jun 1998 63 223
018839 23 Jun 1998 64 222
012914 23 Jun 1998 65 96
016314 23 Jun 1998 66 190
016296 23 Jun 1998 67 187
016211 23 Jun 1998 68 184
61 016475 FDRABR.VSCLM02.C1003500 30 ZCOBKUPD 16 Jun 98 0 U
016211 23 Jun 1998 68 184
016201 23 Jun 1998 69 183
016127 23 Jun 1998 70 181
016337 23 Jun 1998 71 193
016322 23 Jun 1998 72 192
015072 23 Jun 1998 73 148
62 016475 FDRABR.VVSAM12.C1006800 31 ZCOBKUPD 16 Jun 98 0 U
015072 23 Jun 1998 73 148
015062 23 Jun 1998 74 147
011488 23 Jun 1998 75 44
011035 23 Jun 1998 76 31
010970 23 Jun 1998 77 29
010967 23 Jun 1998 78 28
63 017244 CA.BKUPMSTR.G0502V00 1 CALDPBK 14 Jun 98 8,287 VB
017244 23 Jun 1998 1 113
013076 23 Jun 1998 2 110
018149 23 Jun 1998 3 114
015278 23 Jun 1998 4 112
019308 23 Jun 1998 5 115
013099 23 Jun 1998 6 111
64 018042 TS63.CATALOG.VWGL507.BAC 1 ZTSVSMB4 16 Jun 98 32,756 VBS
018042 23 Jun 1998 1 9
018137 23 Jun 1998 2 10
013684 23 Jun 1998 3 7
011951 23 Jun 1998 4 5
011932 23 Jun 1998 5 61
Datasets in Vault VAULT1
-------------------------
Pool Name: POOL-NUMBER-1
Row First Ds Create Create Record Record
Id Volume Dataset Name Seq. Job Date Length Format
Move Vol Slot
Volser Date Seq. No.
------ ------------------------------------- ------------------ ------ ------
011257 23 Jun 1998 6 40
010885 23 Jun 1998 7 25
010870 23 Jun 1998 8 24
017991 23 Jun 1998 9 209
017509 23 Jun 1998 10 203
014339 23 Jun 1998 11 136
015050 23 Jun 1998 12 145
015097 23 Jun 1998 13 149
65 018228 TS63.CATALOG.VMVSCAT.BAC 1 ZTSVSMB1 16 Jun 98 32,756 VBS
018228 23 Jun 1998 1 11
66 018288 TS63.CATALOG.VWGL83A.BAC 1 ZTSVSMBA 16 Jun 98 32,756 VBS
018288 23 Jun 1998 1 13
018280 23 Jun 1998 2 12
018358 23 Jun 1998 1 14
POOL-NUMBER-1 Datasets in VAULT1: 67
Example 2
Extract all volumes located in VAULT1 which were created by job ZCOIBKUP during June
1998.
//EXTRACT EXEC CTTRPT
//SYSIN DD *
EXTRACT PATH=VOLUME/ALLDS
INCLUDE LOCATION=VAULT1,CREJBN=ZCOIBKUP
EXCLUDE CREDT<19980601
EXCLUDE CREDT>19980630
REPORT NAME=GENERAL,SUMMARY=YES,MARGINS=1-80,LINESIZE=80,
TITLE=Inventory Report
FIELDS ROWID,VOLSER,VOLSTAT,MOVEDATE,VOLSEQ,SLOTNUM,VOLEXPDT,
ID=P
FIELDS DSNAME/C13,DSLABEL,CREJBN,CREDT,BLOCKCT,DSEXPDT,
ID=S
SORTBY ACTIVE/BRK/RSP,POOL/BRK/RSP,
LOCATION/BRK/RSR,VOLSER,DSLABEL
BREAK FIELD=LOCATION,EDIT=ZZ9,
SUMTITLE=Total number of volumes in %FIELD: %COUNTP
BREAK FIELD=ACTIVE,EDIT=ZZ,ZZ9,
SUMTITLE=Number of %FIELD Volumes: %COUNTP
BREAK FIELD=POOL,EDIT=ZZ9,
SUMTITLE=Total number of volumes in %FIELD: %COUNTP(%COUNT)
ATTR FIELD=ROWID,TITLE=Row/Id,EDIT=ZZ,ZZ9
ATTR FIELD=VOLSER,TITLE=/Volser
ATTR FIELD=VOLSTAT,TITLE=Volume/Status
ATTR FIELD=MOVEDATE,TITLE=Move/Date,EDIT=DD MMM YYYY
ATTR FIELD=VOLSEQ,TITLE=Vol/Seq.,EDIT=Z9
ATTR FIELD=SLOTNUM,TITLE=Slot/No.,EDIT=Z,ZZ9
ATTR FIELD=VOLEXPDT,TITLE=Volume/Expiration,EDIT=DD MMM YYYY
ATTR FIELD=DSNAME,TITLE=/Dataset Name,LENGTH=24
ATTR FIELD=DSLABEL,TITLE=Ds/Seq.,EDIT=ZZ9
ATTR FIELD=CREJBN,TITLE=Create/Job
ATTR FIELD=CREDT,TITLE=Create/Date,EDIT=DD MMM YY
ATTR FIELD=BLOCKCT,TITLE=Block/Count,EDIT=ZZ,ZZ9
ATTR FIELD=DSEXPDT,TITLE=Dataset/Expiration,EDIT=YYYY-MMM-DD
ATTR FIELD=ACTIVE,TITLE=Type,EDIT=ACTIVE/SCRATCH
ATTR FIELD=LOCATION,TITLE=Location
ATTR FIELD=POOL,TITLE=Pool/Name
/*
The following is a sample output produced by the above example. Note the following about
the output:
1. The page number, date and time are not printed unless the LINESIZE specified in the
REPORT statement is at least 127.
2. During printing, if there is insufficient room on the current page for secondary lines,
the primary line is reprinted as part of the page header on the next page.
3. A field specified with option /BRK in a SORTBY statement is shown in the page header
following the report title and any slashes (/) specified in the TITLE definition are
suppressed to blanks.
Inventory Report
----------------
Type: ACTIVE Pool Name: POOL-NUMBER-1 Location: VAULT1
Row Volume Move Vol Slot Volume
Id Volser Status Date Seq. No. Expiration
Ds Create Create Block Dataset
Dataset Name Seq. Job Date Count Expiration
---------------------------- -----------------------------------------------
1 010222 Vaulted Jun 20-1998 2 427 21 Jun 1998
FDRABR.VPROD02.C1005204 6 ZCOIBKUP 14 Jun 98 0 1998-Jun-21
FDRABR.VSAS001.C1006504 4 ZCOIBKUP 14 Jun 98 0 1998-Jun-21
FDRABR.VTSO006.C1004804 3 ZCOIBKUP 14 Jun 98 0 1998-Jun-21
2 010372 Vaulted Jun 20-1998 1 433 21 Jun 1998
3 011938 Vaulted Jun 20-1998 14 487 21 Jun 1998
FDRABR.VWGLE00.C1035504 17 ZCOIBKUP 14 Jun 98 0 1998-Jun-21
FDRABR.VWGLE1C.C1027404 16 ZCOIBKUP 14 Jun 98 0 1998-Jun-21
FDRABR.VMVS89C.C1005304 15 ZCOIBKUP 14 Jun 98 0 1998-Jun-21
FDRABR.VMVS89D.C1005304 14 ZCOIBKUP 14 Jun 98 0 1998-Jun-21
FDRABR.VMVSR1A.C1028204 13 ZCOIBKUP 14 Jun 98 0 1998-Jun-21
FDRABR.VWGL800.C1006704 12 ZCOIBKUP 14 Jun 98 0 1998-Jun-21
4 011954 Vaulted Jun 20-1998 15 492 21 Jun 1998
FDRABR.VMVSRES.C1018704 18 ZCOIBKUP 14 Jun 98 0 1998-Jun-21
5 012016 Vaulted Jun 20-1998 13 506 21 Jun 1998
FDRABR.VSCLM03.C1001304 11 ZCOIBKUP 14 Jun 98 0 1998-Jun-21
6 012191 Vaulted Jun 20-1998 3 529 21 Jun 1998
7 012271 Vaulted Jun 20-1998 9 539 21 Jun 1998
8 012313 Vaulted Jun 20-1998 12 544 21 Jun 1998
9 013315 Vaulted Jun 20-1998 4 551 21 Jun 1998
10 014347 Vaulted Jun 20-1998 11 568 21 Jun 1998
11 014743 Vaulted Jun 20-1998 10 572 21 Jun 1998
12 016465 Vaulted Jun 20-1998 5 583 21 Jun 1998
Inventory Report
----------------
Type: ACTIVE Pool Name: POOL-NUMBER-1 Location: VAULT1
Row Volume Move Vol Slot Volume
Id Volser Status Date Seq. No. Expiration
Ds Create Create Block Dataset
DataSet Name Seq. Job Date Count Expiration
---------------------------- -----------------------------------------------
12 016465 Vaulted Jun 20-1998 5 583 21 Jun 1998
13 017248 Vaulted Jun 20-1998 6 587 21 Jun 1998
14 018377 Vaulted Jun 20-1998 8 596 21 Jun 1998
15 018393 Vaulted Jun 20-1998 7 596 21 Jun 1998
Total number of volumes in VAULT1 : 15
POOL-NUMBER-1 Volumes: 73 , POOL-NUMBER-1 Datasets: 581
Number of ACTIVE Volumes: 221
CTTRSM Recover Tape Activity From SMF Records
Utility CTTRSM recovers tape activity not recorded in the Media Database from data in
SMF records. This utility can be used to extract information about tape activity performed
when CONTROL-T was not active.
Before running utility CTTRSM, SMF records must be accumulated and loaded into one or
more sequential files via appropriate MVS utilities (e.g., IFASMFDP). The sequential files
containing the SMF records should then be specified in DD statement DASMFIN of utility
CTTRSM. The SMF records in the sequential file should be only type 14 and type 15
SMF records.
// EXEC CTTRSM
//DASMFIN DD DISP=SHR,DSN=SMF-file-#1
// DD DISP=SHR,DSN=SMF-file-#2
...
//SYSIN DD *
TYPERUN MODE=NORMAL|SIMULATION
[,DYNVOL=Y|N]
[,DYNDS=Y|N]
[,ACCTYPE=CREATE|UPDATE|ALL]
[,SYNCHLVL=MATCH|FORCE]
[,X98000=SKIP|UPDATE]
REPORT NAME=SMFRCV
FIELDS ...
[SORTBY ...]
[ATTR ...]
[BREAK ...]
//
Parameters
TYPERUN Operation type and mode of execution. Mandatory.
MODE Mode in which the utility will run. Mandatory. Valid
values:
NORMAL SMF records are read and the Media
Database is updated according to the
tape activity recorded in the SMF
records. Default.
The utility produces a report which lists
the tape activity extracted from SMF
records.
SIMULATION SMF records are read but the Media
Database is not updated. The utility
produces a report of tape activity from
SMF records without updating the Media
Database.
DYNVOL Instructions for handling volumes that were accessed but
do not exist in the Media Database. Optional.
Y (Yes) Create a volume record for each of these
volumes automatically. This value is not
valid if DYNDS=N (described below).
Default.
E (External) Create a volume record which describes
the volume as an external tape. This
value is not valid if DYNDS=N
(described below) is specified.
N (No) Do not create a volume record for the
volume. Information about datasets on
the volume and the volume chain it
belongs to will not be recorded in the
CONTROL-T Media Database.
DYNDS Instructions for handling datasets that were accessed for
Read/Update but are not defined in the Media Database.
This parameter is ignored if CREATE is specified for
parameter ACCTYPE (described below). Optional.
Y (Yes) Create a Dataset record for each of these
datasets and insert the appropriate
information. Default.
N (No) Do not create Dataset records for these
datasets (i.e., do not record tape activity
for these datasets).
ACCTYPE Type(s) of tape activity to be processed during this run of
the utility. Optional.
CREATE Process only SMF records that describe
creation of new datasets.
UPDATE Process only SMF records that describe
an update of a tape dataset (including
creation of new datasets).
ALL Process all SMF records of tape activity
which were stored in the sequential files
specified as input to the utility. Default.
SYNCHLVL
Instructions for handling conflicts (e.g., when an SMF
record indicates creation of a dataset that overwrites an
existing dataset) between the Media Database and the
SMF records. Optional.
MATCH If a conflict occurs, the conflict is
described in the utility report. The Media
Database is not updated with the
conflicting information. Default.
FORCE If a conflict occurs, the Media Database
is modified to reflect the changes
described in the SMF record.
X98000 Instructions for handling datasets for which
LABEL=EXPDT=98000 was specified. Optional.
SKIP Do not process datasets specified with
LABEL=EXPDT=98000. Default.
UPDATE Process all datasets regardless of their
EXPDT specification.
INCLUDE/EXCLUDE
Utility CTTRSM uses, as input, SMF records which describe tape
access. The SMF records to be processed by the utility are included in
sequential files specified via DD statement DASMFIN. These records
can be filtered by one or more INCLUDE/EXCLUDE statements. Valid
values that can be used to filter the SMF records are listed in Tables 1
and 2 in Appendix D of this guide.
For more information about INCLUDE/EXCLUDE statements, see
Record Selection Logic earlier in this section. Optional.
REPORT Indicates the report to be created by the utility. Mandatory.
The following parameter must be specified:
NAME = SMFRCV
An SMF recovery report is produced by the utility, listing all datasets
whose access (or creation) is described in the SMF records processed
by the utility. The fields in this report are determined by the FIELDS
statement (described below).
FIELDS Indicates which fields to include in the report produced by the utility.
Valid field names are all dataset record and volume record fields
(described in Tables 1 and 2 of Appendix D in this guide). The
following special field can also be specified:
STATUS Indicates the action performed on the dataset record by
utility CTTRSM. This field is empty if the dataset was
processed successfully. Otherwise, this field contains a
rejection reason which explains why the dataset was not
processed.
SORTBY Order in which the report is sorted. Optional, Valid sort fields are all
dataset record and volume record fields (described in Tables 1 and 2 of
Appendix D in this guide).
ATTR Override of default attributes defined for a field in the report.
Optional.
BREAK Attributes of the summary header line(s) printed when a field break
occurs. Optional.
Note See the FIELDS, SORTBY, ATTR and BREAK statements in utility CTTRPT (earlier
in this section) for a description of the parameters for these statements.
Example
The following example recovers all tape datasets accessed by jobs with names prefixed by
ABC. Volumes and datasets that are not defined in the Media Database are automatically
defined. Conflicts with the Media Database are reported as errors.
// EXEC CTTRSM
//DASMFIN DD DISP=SHR,DSN=N00.ACCUM.SMFRECS
//SYSIN DD *
TYPERUN MODE=SIMULATION,DYNDS=Y,DYNVOL=Y
INCLUDE CREJBN=ABC*
REPORT NAME=SMFRCV
FIELDS DSNAME,DSVOLSER,DSLABEL,STATUS
CTTRTM Perform Retention Management
This utility performs batch retention management functions. Batch retention management
is performed daily to check expiration criteria and determine which datasets should be
marked scratch. When all the datasets on a volume have expired, the volume becomes a
scratch volume. The utility should be run as part of the CONTROL-T New Day procedure
(CTTDAY).
Utility CTTRTM supports a number of different types of retention. See Retention
Management in Section 4 of the CONTROL-T User Manual for a list of the supported
retention types.
Utility CTTRTM does not perform retention management for the following volumes:
Vaulted volumes.
Volumes not in the currently active library (i.e., volumes with a status of Act-Out).
Volumes with a status of Pend-Vault.
Volumes which have been recalled from a vault.
Volumes with a status of Act-Use.
Deleted volumes.
EDM controlled volumes.
Notes Retention information for these volumes is updated by utility CTTRTM if either
CONVERT or RECALC is specified for parameter TYPERET (described later).
However, these volumes (and the datasets they contain) are not expired by the utility
(i.e., they are not marked as scratched).
Utility CTTRTM requires exclusive access to the Media Database. Jobs can access
tapes during the run of this utility. However, other utilities which access the Media
Database (e.g., CTTIDB or CTTVTM) are not allowed to run concurrently with this
utility.
Scratch Report
Utility CTTRTM can produce a Scratch report at the end of processing. The Scratch report
contains a list of all volumes which have expired (i.e., become scratch) as a result of this
utility run.
Note Full Scratch report FULLSCR is no longer generated by utility CTTRTM. Instead, this
report can be generated as part of the GENERAL report by utility CTTRPT. For more
information see utility CTTRPT earlier in this section.
Utility CTTRTM adds the following special pool names in the POOLNAME field of certain
volume records in the Scratch report:
EXTERNAL External volumes not deleted from the Media Database.
EXT-DEL External volumes deleted from the Media Database..
EXT-DUP External volumes which are not deleted from the Media Database but
whose SL-NAME and VOLSER are different.
DUPLICATE VOL Internal volumes whose SL-NAME and VOLSER are different.
The special pool name is written over the previous name in field POOLNAME (if one
existed).
Scratched volumes with different SL-NAMEs and VOLSERs (listed in the EXT-DUP and
DUPLICATE VOL pools) should each be re-initialized (via utility CTTTPI) to set the
SL-NAME to the value of the VOLSER.
Parameters MAXDSNO and MAXVOLNO of utility CTTRTM can be used to indicate a
maximum number of datasets and/or volumes that can be scratched during a run of the
utility. Before scratch is performed, the utility checks if the maximum specified (via one of
these parameters) will be exceeded.
If a specified maximum will be exceeded, no changes are made to any datasets or volumes,
an error message is issued and a Scratch report is produced describing all scratches that
would have been performed (if the maximum had not been specified).
RECALC Report
If utility CTTRTM is used to recalculate retention periods (i.e., MODE=RECALC is
specified in the TYPERET statement) a RECALC report can optionally be generated.
The RECALC report contains information about datasets whose expiration dates were
changed as a result of the run of the utility.
The information provided about each dataset depends on the field names specified in the
FIELDS control statement for the RECALC report. Special field names can be used to
indicate the various retention types that were specified for a dataset and the AND/OR
relationship between them. For more information, see Fields of the RECALC Report
under the description of the REPORT statement (below).
Recovery From Abends
Since utility CTTRTM updates the Media Database in several stages, a CANCEL
operation, job abend or system crash can lead to logical inconsistencies in the database.
CONTROL-T can recover from abends occurring during the run of utility CTTRTM. The
type of recovery depends on the stage of the utility in which the abend occurred. Utility
CTTRTM performs retention management in the following stages:
1. A physical file is produced which contains the information necessary for updating the
relevant records in the Media Database.
2. The Media Database records are updated.
3. A Scratch report is produced.
If an abend occurred during Step 1, no updates were performed on the Media Database and
the utility can be rerun normally.
If an abend occurred while the Media Database was being updated (Step 2) the next time
utility CTTRTM is run it will automatically enter RESTART mode and continue updating
the Media Database from where the previous run terminated. (The utility uses the physical
file created in Step 1 and a timestamp which indicates where the previous run of utility
CTTRTM was interrupted.)
If an abend occurred after all updates of the Media Database were performed but the
Scratch report was not produced, this report can be generated by rerunning the utility with
the following parameters:
TYPERUN MODE=NORMAL
REPORT NAME=SCRATCH
FIELDS fields
SORTBY fields
where:
fields Same fields that were specified in the FIELDS and SORTBY
statements in the original run of utility CTTRTM.
Note No value should be specified for parameter TYPERET in this run of utility CTTRTM.
Exits Used by Utility CTTRTM
The following exits can be used to influence a run of utility CTTRTM:
CTTX006 Receives control immediately before updates are made to
dataset/volume records in the Media Database. This exit can be used
to accept or reject expiration of a dataset record and/or to update a
dataset/volume record before it is marked as scratched. Valid values:
CTTX008 Receives control when the Scratch report is used to update the
information in the robotic tape library (if one exists at your site). This
exit can be used to scan the scratch report and to determine which
volume records are updated in the robot s database.
Relevant Installation Parameters
Installation parameters (specified in member CTTPARM) determine how utility CTTRTM
operates. These parameters are described below.
RTNTYPE Specifies when the datasets on the volume will be scratched.
VOL Each dataset on the volume will be marked scratch only
if all datasets on the volume have expired. This option
is recommended for compatibility with CA-1 and
CA-TLMS.
DSN Each dataset records expiration criteria in the Media
Database is independent of other datasets on the
volume.
Note A multi-volume chain functions independently of
parameter RTNTYPE. Only if all datasets on
each volume have expired will all the datasets of
the chain be marked scratch and all volumes of
the chain become scratch.
CYCLECNT Defines how to calculate cyclic datasets. Valid values:
DS1 Handles datasets with the same dataset name and
creation date as a single cycle. Default.
DS Handles datasets with the same dataset name as
separate cycles. The creation date is ignored.
DSJ Handles datasets with the same dataset name and job
name as a single cycle. The creation date is ignored.
DSJ1 Handles datasets with the same dataset name, creation
date and job name as a single cycle.
EXPDTYPE Determines expiration logic depending on the type of retention criteria
and value specified:
When DATE or DAYS retention criteria are assigned to a dataset:
CA1 CA-1 expiration logic applies. DATE or DAYS specifies
the day on which the dataset is expired. Default.
TLMS CA-TLMS expiration logic applies. DATE or DAYS
specifies the last day of retention. The dataset is
expired the following day.
NONE Expiration date in standard MVS format.
When cyclic retention criteria are specified:
CA1 CA-1 expiration logic applies. Only primary datasets
(datasets with LABEL=1) are considered in the
expiration calculation. Default.
Other All cyclic datasets are considered regardless of label number.
CTLGWAIT Defines the number of wait days before utility CTTRTM checks a
catalog-controlled dataset (i.e., one for which DO RETENTION=
MVS CATALOG is specified). In some cases, a dataset is created
during a job step and cataloged at the end of a later job step. If utility
CTTRTM is executed after the dataset is created but before it is
cataloged, the utility expires the dataset. Parameter CTLGWAIT
causes utility CTTRTM to wait a specified number of days before
checking if the dataset is cataloged.
MODE Determines whether or not to uncatalog expired datasets in the MVS
Catalog.
TEST Datasets are not uncataloged.
PROD or
PHASE
Datasets are uncataloged if no Test rules match the
expired datasets (see parameter TESTRUL below).
SMSINTR Determines whether or not the CONTROL-T to DF/SMS interface is
active. If this interface is active and expiration dates are defined by
SMS-managed classes, retention is dependent on expiration dates
specified in SMS Management Classes.
Y (Yes) The CONTROL-T to DF/SMS interface is active.
Note If CDAM files will be allocated on SMS volumes, these volumes
must be defined with PARTIAL RELEASE=NO.
N (No) The CONTROL-T to DF/SMS interface is not active.
TESTRUL Determines whether or not Test rules are used in the production
environment (global MODE=PROD or PHASED). If an expired dataset
matches a Test rule, the dataset should not be uncataloged.
Y (Yes) Test rules are used. The utility loads and scans the
CONTROL-T rules.
N (No) Test rules are not used. The utility does not load and
scan the CONTROL-T rules. Default.
For additional information refer to Specify Retention and Vault Parameters in Section 9
of the IOA Installation Guide.
// EXEC CTTRTM
//SYSIN DD *
TYPERUN MODE=NORMAL|SIMULATION|[,DATE=date][,TRACE=YES|NO]
[,DBGLEVEL=level][,RESTART=YES|NO][,LIST=YES|NO|FULL]
[,MAXDSNO=nnn][,MAXVOLNO=nnn]
TYPERET MODE=REGULAR|RECALC|CA1CONV|CONVERT[,UNCTLG=YES|NO]
[,UPDVOL=YES|NO]
REPORT NAME={SCRATCH|RECALC}
FIELDS ...
SORTBY ...
ATTR ...
BREAK ...
//
Parameters
Note Although both the TYPERET and the REPORT parameters are optional, at least one of
them must be specified.
TYPERUN Operation type. Mandatory.
NORMAL Normal operation is performed. The
Media Database is updated as
required by utility CTTRTM.
SIMULATION Simulation is performed. No changes are
made to the Media Database. In this
mode, CONTROL-T keeps in memory a
list of Media Database records that would
have been updated if the utility ran in
NORMAL mode.
Notes Running utility CTTRTM in SIMULATION
mode requires a much larger region than running
the utility in NORMAL mode. The required region
size depends on the number of updated Media
Database records which this utility stores in
memory.
Utility CTTRTM can be run in SIMULATION
mode while utility CTTRTM is run in NORMAL
mode. However, more than one run of utility
CTTRTM in NORMAL mode is not permitted.
DATE Operation date in 6- or 8-character format according to
site standard. (For example, in USA standard the date
can be specified mm/dd/yy or mm/dd/yyyy.) Optional.
TRACE Specifies whether or not the Trace file is used during
CTTRTM run. Optional.
YES The Trace file is used. Default.
NO The Trace file is not be used.
specified.
RESTART Specifies whether or not to enable Automatic Restart
mode when the utility is run after an abend or
cancellation of the previous run of the utility. Valid
values:
Y (Yes) Enable Automatic Restart mode.
Default.
N (No) Disable Automatic Restart mode.
LIST Specifies whether or not diagnostic messages CTT301I,
CTT302I, CTT493I and CTT494I will be produced. The
messages are sent to SYSPRINT. Valid values:
N (No) None of these messages are produced.
Y (Yes) Messages CTT301I, CTT302I and
CTT493I are produced. Default.
FULL All of these diagnostic messages are
produced.
MAXDSNO Maximum number of datasets that can be scratched by
this run of the utility. Optional. A value from 1 to
999999 can be specified.
If this limit is exceeded, the utility stops, a message is
issued, no changes are made to the Media Database and
the Scratch report (if requested) is produced describing
all dataset and/or volume scratches that would have
been performed (if the maximum had not been
exceeded).
Default: Any number of datasets can be scratched by
the utility (i.e., no limit is assumed).
MAXVOLNO Maximum number of volumes that can be scratched by
this run of the utility. Optional. A value from 1 to 999999 can
be specified.
If this limit is exceeded, the utility stops, a message is
issued, no changes are made to the Media Database and
the Scratch report (if requested) is produced describing
all dataset and/or volume scratches that would have
been performed (if the maximum had not been
exceeded).
Default: Any number of volumes can be scratched by
the utility (i.e., no limit is assumed).
Note A Scratch report is only produced by utility CTTRTM if a
REPORT control statement describing the report was specified.
TYPERET Retention management type. Optional if parameter REPORT is
specified. If TYPERET is not specified, retention processing is not
performed, but the report produced by the last run of utility CTTRTM
is regenerated.
MODE Retention management mode. Valid values:
REGULAR Retention management is performed
according to the retention criteria
currently specified in dataset records
in the Media Database.
CONVERT This parameter is used after
conversion from a different tape
management system (e.g., CA-TLMS).
Expiration date information is
extracted from one of the following
locations (depending CONTROL-T
installation parameters):
CONTROL-T rules
JCL EXPDT parameters
SMS Management Classes
Default values defined in member
CTTPARM
The extracted retention information is
used to update dataset records in the
Media Database. However, no actual
expiration is performed. This enables
the user to check that the conversion
works as planned, before retention
management is implemented.
Note TYPERET=CONVERT should only be specified
in the following cases:
This is the first run of utility CTTRTM since
conversion from the previous tape
management system and retention
information does not exist in the dataset
records created as a result of this conversion
(e.g., CA-TLMS).
Rules have been defined with new retention
information that must be incorporated into the
dataset records in the Media Database.
RECALC Retention information in dataset
records in the Media Database is
updated and expiration is performed.
Running utility CTTRTM with
TYPERET=RECALC specified has the
same effect as running this utility
twice: once with TYPERET=CONVERT
specified and a second time with
TYPERET=REGULAR specified.
If MODE=RECALC is specified, a
special RECALC report can be
generated. For more information, see
control statement REPORT below.
CA1CONV This parameter is used only after
CA-1 conversion. In this mode, no
retention actions are taken. This mode
is used to fill in the dataset names
prefix length (as defined in
CONTROL-T rules) in the Media
Database dataset records. This
information is later used for retention
management of cyclic datasets.
Notes If utility CTTRTM has already been run with
TYPERET=CONVERT specified, it is not
necessary to run it again with
TYPERET=CA1CONV specified.
Basic Scheduling parameters are checked when
rules are loaded and not when datasets are
created or retention information is updated or
extracted. Therefore, when running utility
CTTRTM in RECALC, CONVERT or CA1CONV
mode, the rules applied may differ from the rules
normally applied at dataset creation. For more
information, see Basic Scheduling Parameters
in Section 2 of the CONTROL-T User Manual.
UNCTLG Specifies whether or not to uncatalog datasets after
scratching the dataset records from the Media
Database. Optional.
YES Uncatalog the datasets. Default.
NO Do not uncatalog the datasets.
UPDVOL Specifies whether or not to copy the retention
information from the dataset records to the volume
where the datasets reside. (The highest retention period
is stored in the volume record.) Applies only if the
MODE specified in the TYPERET statement is
RECALC or CONVERT. Valid values:
YES Copy the retention information to the
volume record.
NO Do not copy the retention information
to the volume record. Default.
Specifying NO can significantly
improve performance time when
running the utility in CONVERT or
RECALC mode. However, accurate
retention information will only be
available via inquiry of dataset
records in the Media Database (i.e., an
inquiry of the volume records may not
yield accurate retention information).
INCLUDE/EXCLUDE
EXCLUDE statements. INCLUDE/EXCLUDE statements are specified
immediately after the TYPERET parameter and are applied to
retention processing.
For additional information on INCLUDE and EXCLUDE statements,
see Record Selection Logic (INCLUDE/EXCLUDE Statements)
See also Appendix D: Logical Field Names for the CONTROL-T
Repository in this guide.
Note As of CONTROL-T Release 2.1.0, INCLUDE/EXCLUDE
statements cannot be specified after SORTBY parameters.
With few exceptions, the parameters and options of the REPORT, FIELDS, SORTBY,
ATTR and BREAK statements are identical to those found in utility CTTRPT. For a
complete description of these parameters and options, refer to utility CTTRPT earlier in
this section. Differences between the parameters and options of utility CTTRTM and utility
CTTRPT are described below.
REPORT Produces one of the following reports. Optional if a TYPERET
parameter is specified.
NAME Report name. Mandatory. Valid values:
SCRATCH Report listing volumes which expired
based on the execution results of
utility CTTRTM.
Note Full scratch report FULLSCR
is no longer generated by
utility CTTRTM. Instead, this
report can be generated as part
of the GENERAL report by
utility CTTRPT. A sample Full
Scratch report can be found in
member REPFSCR in the
CONTROL-T JCL library.
RECALC Report listing datasets whose
expiration date changed during this
run of the utility.
This report can only be generated if
MODE=RECALC is specified when
the utility is run.
Note Either or both of these reports can be generated
during a single run of utility CTTRTM.
FIELDS Fields to print in the report. The fields are printed in the order they
are specified. The fields that can be specified for each report type are
described below:
Fields of the SCRATCH Report
MEDIA Media type.
POOL Pool name.
SL-NAME Standard label name of the volume.
UNAME Unit name.
FIRSTVOL First volser in a multi-volume chain.
DSNAME Name of the first dataset in the volume.
CREDS Creation date of the first dataset in the volume.
EXPDS Expiration date of the first dataset in the volume.
EXPDT Expiration date of the volume.
LACCDT Last access date of the volume.
LOCATION Location.
CHKINDT Check-in date.
IOERR Number of input/output errors.
LCLNDT Last clean date.
VOLSTAT Status(es) of the volume.
Fields of the RECALC Report
Each of the following fields can be specified for each dataset in a
RECALC report:
LABEL Dataset label number.
VOLSNUM Number of volumes on which the dataset resides.
CREDT Creation date.
CRETM Creation time.
READDT Date the dataset was last opened for READ access.
READTM Time the dataset was last opened for READ access.
WRITEDT Date the dataset was last opened for WRITE access.
WRITETM Time the dataset was last opened for WRITE access.
DSSTAT Dataset status.
LASTACC Type of last access (i.e., CREATE, READ or WRITE).
SMSCL SMS management class.
CREUSER User ID which created the dataset.
CREJOBID Creating Job ID.
JCLEXPDT Dataset expiration date as specified in the JCL.
Retention Type Fields for Report RECALC
The following fields describe the retention types specified for each
dataset and the and/or relationships between them. Fields prefixed by
OLD indicate retention types before the utility was run. Fields
prefixed by NEW indicate retention types after the utility was run.
OLDEXDT1 First expiration criterion before recalculation.
OLDXDTR1 Relation between the first and second old expiration
dates.
OLDEXDT2 Second expiration criterion before recalculation.
OLDXDTR2 Relation between second and third old expiration dates.
OLDEXDT3 Third expiration criterion before recalculation.
NEWEXDT1 First expiration criterion after recalculation.
NEWXDTR1 Relation between first and second new expiration dates.
NEWEXDT2 Second expiration criterion after recalculation.
NEWXDTR2 Relation between second and third new expiration
dates.
NEWEXDT3 Third expiration date after recalculation.
SORTBY Order in which the report is sorted. (Available fields are listed above
under parameter FIELDS.) The /B (or /BRK) option (or /BRK) can be
added as a suffix to any field to indicate that a page break should be
inserted in the report when the field changes its value.
ATTR Override of default attributes defined for a field (see FIELDS above).
Optional.
occurs. Optional.
in this section) for a description of the options of these statements.
Return Codes
16 Load of CONTROL-T routines failed.
20 Sort error occurred.
24 Media Database input/output error occurred.
32 Error in report printing utility occurred.
36 Load of rule, pool or vault table failed.
40 Authorization error (by security exit).
44 Media Database file in use.
52 Logical error in Media Database.
56 Number of datasets/volumes to be scratched exceeded the limit.
Examples
In the following example, retention management is performed according to the current
retention specifications in the Media Database. Report SCRATCH is printed, listing volser
and media type and is sorted according to pool name. The list for each media type starts on
a new page.
// EXEC CTTRTM
//SYSIN DD *
TYPERUN MODE=NORMAL
TYPERET MODE=REGULAR
REPORT NAME=SCRATCH
FIELDS POOL,VOLSER,MEDIA
SORTBY POOL,MEDIA/B,VOLSER
//
In the following example, retention information is updated for all datasets whose name
begins with prefix BKP.
// EXEC CTTRTM
//SYSIN DD *
TYPERUN MODE=NORMAL
TYPERET MODE=CONVERT
INCLUDE DSNAME=BKP*
REPORT NAME=SCRATCH
FIELDS EXPDT,MEDIA,VOLSER,POOL
SORTBY EXPDT
//
In the following example, the utility is used to produce the scratch report from the last
finished run of utility CTTRTM.
// EXEC CTTRTM
//SYSIN DD *
TYPERUN MODE=NORMAL
REPORT NAME=SCRATCH
FIELDS fields
SORTBY fields
//
In the following example, retention information is recalculated for all datasets in the
Media Database. A RECALC report is produced listing the datasets whose retention
information changed and the old and new expiration information for these datasets.
TYPERUN MODE=NORMAL
TYPERET MODE=RECALC
REPORT NAME=RECALC
FIELDS VOLSER/C4/L6,LABEL/C12/L3,DSNAME/C17/L44,
OLDEXDT1/C63/L10,OLDXDTR1/C75/L1,OLDEXDT2/C78/L11,
OLDXDTR2/C91/L1,OLDEXDT3/C94/L10,ID=P
FIELDS NEWEXDT1/C63/L10,NEWXDTR1/C75/L1,NEWEXDT2/C78/L11,
NEWXDTR2/C91/L1,NEWEXDT3/C94/L10,ID=S
ATTR FIELD=OLDXDTR1,TITLE= ,LENGTH=1
ATTR FIELD=OLDXDTR2,TITLE= ,LENGTH=1
ATTR FIELD=NEWXDTR1,TITLE= ,LENGTH=1
ATTR FIELD=NEWXDTR2,TITLE= ,LENGTH=1
ATTR FIELD=OLDEXDT1,TITLE=OLD-
ATTR FIELD=NEWEXDT1,TITLE=NEW-
ATTR FIELD=OLDEXDT2,TITLE=EXPIRATION-
ATTR FIELD=NEWEXDT2,TITLE=EXPIRATION-
ATTR FIELD=OLDEXDT3,TITLE=DATA
ATTR FIELD=NEWEXDT3,TITLE=DATA
ATTR FIELD=LABEL,TITLE=LBL,EDIT=999
The following report is generated by this example:
1NEW DIMENSION SOFTWARE, LTD. CONTROL-T REPORT (REL 5.1.4) DATE 26/11/1997 TIME 15.10 PAGE 1
List of Datasets With Recalculated Expiration
---------------------------------------------
First LBL DATASET OLD- EXPIRATION- DATA
Volume NAME
NEW- EXPIRATION- DATA
------ --- -------------------------------------------- ---------- - ----------- - ----------
B21002 001 M27.BACKUP.BD1.D971111 Catalog O 01/04/1999
Cycl+0003 A Catalog O 25/05/1999
B21002 002 M27.BACKUP.BD2.D971111 01/04/1999
B21003 001 M27.BACKUP.NBD3.D971112 Catalog
B21003 002 M27.BACKUP.NBD4.D971112 Cycl+0005 A Catalog
CHKINE 001 N89.CHKIN.SET 01/01/1999 O Cycl+0005
23/09/1997
CHKINF 001 N89.CHKIN.SET 01/01/1999
23/09/1997
CHKING 001 N89.CHKIN.SET 01/01/1999
23/09/1997
CHKINH 001 N89.CHKIN.SET 01/01/1999
24/09/1997
CTTSBD Perform Dataset Stacking in Batch Mode
Utility CTTSBD copies datasets residing on removable media. It supplements
CONTROL-Ts Dynamic Dataset Stacking facility, which controls the placement of
datasets at time of creation.
Utility CTTSBD enables you to copy existing datasets (input datasets) from one location to
another. Output datasets (the new copies) can be new datasets with their own names and
retention or they can replace input datasets by taking over relevant catalog entries and
assuming certain attributes of the input datasets.
Note If you are working in an SMS-managed environment, it is important to ensure that no
DATACLASS ACS routines modify/set attributes of datasets created by utility
CTTSBD (e.g., via keywords RECFM, LRECL or BLKSIZE).
Utility CTTSBD enables you to:
Copy multiple input datasets to a single output volume or a multi-volume chain
(stacking).
Copy each dataset from an input volume or volume chain to a separate output volume
(unstacking).
Select input datasets and volumes according to various criteria.
Control grouping of output datasets in a volume (or volume chain).
Copy the attributes of input datasets to the output datasets. Attributes describing
dataset name, catalog reference, retention information, creating job, etc. can be copied.
Analyze free (available) space in the tape library and associated costs.
Running utility CTTSBD to stack multiple datasets is called Batch stacking. Batch
stacking helps you:
Increase the number of available (scratch) tapes in a tape library.
Free scratch volumes to satisfy immediate production needs.
Simplify stacking implementation at your site.
Control the growth of your cartridge inventory.
Refresh old media.
Migrate datasets from one media type to another.
Implement new or modified site standards regarding which datasets (e.g., datasets
created by different applications) should or should not reside on the same volumes.
Create additional copies of existing datasets for backup, shipping off-site or usage by
other applications.
Reclaim space occupied by expired datasets on multi-file volumes.
Utility Logic
Utility CTTSBD searches the Media Database for datasets and volumes which satisfy
selection criteria specified in INCLUDE/EXCLUDE statements.
Selected volumes are sorted according to the volser of the first volume in each input
volume chain. Each dataset on each selected volume chain is then copied to a new volume
or volume chain. Various parameters are used to control the actions taken by utility
CTTSBD. For example:
Whether or not to copy expired datasets.
Which datasets can reside together on the same output volume chain.
How many datasets/volumes can be in a volume chain.
When a dataset is successfully copied, CTTSBD updates the relevant Media Database
records and catalog information according to user specifications. Via the parameters of
utility CTTSBD, the user can indicate:
Cataloging of the output dataset (parameter OUTCAT).
Retention of output and/or input datasets (parameters OUTRET and INRET).
Copying of certain historical information about the input dataset to the output dataset
record (parameter COPYATTR).
Utility CTTSBD terminates when one of the following occurs:
All selected volumes have been processed.
An operator command is issued (see Modify Command).
A specified number of input volumes have been processed (parameter NUMVOL).
A specified maximum amount of time has passed (parameter TIMELIM).
Processing of a specified maximum allowed number of input volume chains is stopped
due to runtime errors (parameter MAXERR).
Execution Considerations
Run utility CTTRTM after running utility CTTSBD to scratch newly freed volumes. Utility
CTTVTM can also be run after running utility CTTSBD to update vault information
effected by the CTTSBD run. See Batch Stacking and Vault Management below for more
information.
Notes Utility CTTSBD is not designed to handle vaulted volumes. For more information on
this issue, see Batch Stacking and Vault Management below.
Utility CTTSBD does not handle external or EDM-managed volumes.
Resource Requirements
Resource requirements can help you decide when is the best time to run utility CTTSBD.
The duration of resource consumption depends primarily on the number of volumes
selected for processing by utility CTTSBD. Below is a description of the various resources
used by this utility.
Disk processing CTTSBD disk processing includes sequential processing of the Media
Database and multiple sort phases.
In NORMAL mode, disk processing is performed during the
selection phase only. After the first volume is mounted for copying,
disk processing becomes minimal.
In SIMULATION mode, volume selection is the primary action
performed by the utility. In this mode, the utility runs faster even
though disk processing continues during most of the run.
Tape processing CTTSBD tape resource consumption is similar to that of any other
tape-to-tape copy or backup program which uses two tape drives.
Memory Requirements
CTTSBD uses memory resident information about volumes and
datasets. Storage is allocated as new volume chains are created.
Virtual storage requirements for this utility depend on:
The number of output volume chains created by the utility.
The maximum number of datasets allowed in each output volume chain.
Exit CTTX011
CONTROL-T exit CTTX011 enhances the functionality of utility CTTSBD by allowing
placement of output files to be dependent on stacking criteria which cannot be specified via
utility parameters (e.g., security constants).
Information passed to this exit describes:
The input dataset name.
The candidate output volume.
The datasets already residing on the output volume chain being considered as a
location for the output dataset.
This exit examines the information provided and does one of the following:
Allows placement of the output dataset on the candidate output volume.
Rejects placement of the output dataset on the candidate output volume.
Forces placement of the output dataset on a scratch volume.
Grants the candidate output volume preferred status.
Passes (i.e., the exit does not influence CTTSBD processing).
See member DOCTX011 in the IOA SECUDATA library for more information about this exit.
Retention
When an output dataset is written by utility CTTSBD, it is subjected to CONTROL-T rules
for retention and vaulting. When the dataset is successfully copied, retention of the output
dataset can be modified according to the setting for utility parameters OUTRET and
OUTCAT.
It is recommended that you run utility CTTRTM after running utility CTTSBD to scratch
newly freed volumes. It is not necessary to specify mode RECALC for this run of CTTRTM.
Notes If datasets with CYCLE type retention are to be handled by utility CTTSBD, a specific
number must be specified for utility parameter INRET and/or OUTRET.
If a dataset with CYCLE type retention is detected and no specific value was specified
for at least one of these parameters, the dataset is ignored (i.e., skipped) and the utility
continues to process the next dataset in the current input volume chain.
Batch Stacking and Vault Management
Utility CTTSBD copies datasets on volumes which reside in the main library and are not
scheduled for storage in an off-site vault. By default, volumes which are in a vault or are
scheduled to be transferred to a vault, are not selected by CTTSBD, even if specified
INCLUDE/EXCLUDE statements explicitly state otherwise.
Some sites use vault management for administrative purposes other than off-site storage.
At such a site, parameter VAULTED can be used to indicate that vaulted (and
to-be-vaulted) volumes should be processed by utility CTTSBD.
Note If VAULTED=YES is specified for utility CTTSBD, vaulted/to-be-vaulted volumes can
be stacked together (i.e., in the same volume chain) with volumes which have no
specified vaulting pattern.
Vault patterns of output volumes are determined by CONTROL-T rules which are active at
time of output dataset creation. These vault patterns can also be influenced by various
attributes copied from the input datasets (e.g., creation date). The resulting vault pattern
may very likely be inappropriate and should therefore be reset via user-defined vaulting
rules. For information on vaulting rules, see Online Vault Definition in Section 2 of the
Run utility CTTVTM to refresh vaulting information for newly created datasets. Mode
RECALC can be specified but will not necessarily correct all inconsistencies. It is highly
recommended to use INCLUDE statements to limit operation of the utility to necessary
tapes only.
Volume and Dataset Information
When an output dataset is created by utility CTTSBD, the Media Database initially
describes the dataset as a new file. There is no indication that this file is a copy of another
dataset.
After the output dataset is successfully written, various attributes can be set by utility
CTTSBD in the relevant Media Database records. See parameter COPYATTR in General
Utility Parameters below for more information.
Dataset Record
When a dataset is copied, CONTROL-T assigns various attributes to it. For example:
Creation date (the date utility CTTSBD was run).
Retention information (subject to active CONTROL-T rules).
Utility CTTSBD can optionally be instructed to copy certain attributes of the input dataset
to the dataset record of the output dataset and to override the above settings. (See
parameters OUTRET and COPYATTR below for more information.)
Note Certain physical attributes of the output dataset are not modified by utility CTTSBD. These
physical attributes include volume serial number(s) label number, blocking and size.
Volume Record
No volume information from the input volume records is copied to the output volume
records. Output volume records are not modified by utility CTTSBD and contain
information relevant to only the output volumes.
Stacking Logic
Utility CTTSBD augments the CONTROL-T Dynamic Dataset Stacking facility by allowing
multiple pre-existing datasets to be copied and stacked according to specified criteria.
Datasets are placed on output volumes according to stacking parameters and runtime
parameters specified by the user.
Output dataset size is calculated according to the known size of input datasets and
runtime information about output volumes. The output dataset size is used to determine
whether or not there is sufficient space in a given volume chain to stack the dataset.
Output datasets are stacked only on volumes which became active during the current run
of utility CTTSBD. If no appropriate volume is found, the dataset is written on a scratch
volume.
Batch Stacking and Dynamic Dataset Stacking
Datasets written by utility CTTSBD are not stacked by CONTROL-Ts Dynamic Dataset
Stacking facility. DO STACK, DO STKRULE and DO STKGROUP statements in relevant
CONTROL-T rules are ignored by utility CTTSBD.
Utility CTTSBD can be used to implement dataset grouping similar to the grouping
produced by DO STKGROUP statements. This utility can also be used to force the stacking
of datasets which would not normally be stacked by the Dynamic Dataset Stacking facility.
Batch stacking can be used to complement the Dynamic Dataset Stacking facility in the
following way:
Datasets are normally stacked via the CONTROL-T Dynamic Dataset Stacking facility
at time of creation.
Utility CTTSBD can be run periodically to consolidate under-utilized volumes and to
alter dataset placement according to site needs.
Dataset Groups
A dataset group is a collection of datasets for which stacking statements can be specified.
A group name is assigned to each dataset.
Each group name is associated with a set of stacking statements which determine
where (and with which datasets) members of the dataset group can be stacked.
To apply a stacking statement to a dataset, the dataset must first be associated with a
dataset group.
Group names are re-assigned each time utility CTTSBD is run.
All statements specified for dataset groups are applied using input dataset names. Prefixes
and/or suffixes (parameters OUTPREF and OUTSUFF) added to dataset names do not
effect application of dataset group stacking statements during the current run of the
utility. However, these prefixes may effect future runs of the utility.
Example
Assume the following:
Input datasets ACCT.JAN98 and ACCT.FEB98 are assigned to group ACCT.
A prefix of NEW is added to output dataset names for group ACCT.
Input datasets NEW.ACCT.NOV97 and NEW.ACCT.DEC97 are assigned to group
NEW. (These datasets may have been created by a previous run of utility CTTSBD.)
No prefix is added to output dataset names for group NEW.
Utility CTTSBD selects all datasets from group ACCT and group NEW.
The following output datasets are created by this run of utility CTTSBD:
Input Dataset Name
Input
Dataset
Group Output Dataset Name
Output
Dataset
Group
ACCT.JAN98 ACCT NEW.ACCT.JAN98 ACCT
ACCT.FEB98 ACCT NEW.ACCT.FEB98 ACCT
NEW.ACCT.NOV97 NEW NEW.ACCT.NOV97 NEW
NEW.ACCT.DEC97 NEW NEW.ACCT.DEC97 NEW
Note that the group name assigned to each input dataset is automatically assigned to the
corresponding output dataset (regardless of the output dataset name).
Determination of Output Dataset Location
Utility CTTSBD determines placement for output datasets in the following way:
Utility CTTSBD first attempts to place the current dataset on the current output volume
chain (i.e., the chain on which the previous dataset was stacked).
If the dataset cannot be placed on the current volume chain, utility CTTSBD attempts
to place the dataset on the first volume chain created during this run of the utility.
If the first volume chain is not suitable, the second one is considered, etc. Utility
CTTSBD considers each chain created during this run (in the order in which they were
created) as a possible location for the current dataset until either a suitable volume
chain is found or all chains have been considered.
If no suitable volume chain is found, the dataset is placed on a scratch volume.
Datasets can be stacked on volumes (or multi-volume chains) created during a run of
utility CTTSBD even after the volumes have been dismounted.
Each volume chain considered as a possible location for the current dataset is processed in
the following way:
1. The dataset group definition associated with the current dataset is compared with the
dataset group definition of each dataset on the candidate volume chain.
If a statement specified in any dataset group definition does not allow the datasets to
coexist in the same volume chain (due to group name, job name or dataset name) utility
CTTSBD rejects the volume chain and attempts to place the dataset on the next volume
chain. (Dataset group stacking parameters are described in detail later is this section.)
2. Utility CTTSBD searches the dataset group definitions for a WITHGRP statement
which indicates that the current dataset should be stacked together with the datasets
on the candidate volume chain. An appropriate WITHGRP statement may exist in the
dataset group definition of the current dataset and/or a dataset on the candidate
volume chain. (WITHGRP statements are described in detail later in this section.)
If a matching WITHGRP statement is found, utility CTTSBD copies the dataset to
the volume chain (as long as limits specified to the utility have not been exceeded).
Notes You can maximize media utilization by instructing utility CTTSBD to create output
volume chains containing a large number of volumes (via parameter OUTMVLIM).
You can also control the number of datasets in an output volume chain via parameter
MAXLABEL.
If the specified maximum number of volumes in a chain is exceeded during the writing
of a multi-volume dataset (e.g., due to an inaccurate prediction concerning dataset
length) utility CTTSBD continues writing the dataset on as many volumes as required.
If no matching WITHGRP statement is found, utility CTTSBD rejects the volume
chain and attempts to place the dataset on the next volume chain.
Note Exit CTTX011 (if implemented) is invoked at various stages in the above process to
modify/force a stacking decision. See Exit CTTX011 above and member DOCTX011
in the IOA SECUDATA library for more information.
Masking
Mask characters are supported for many of the parameters of utility CTTSBD. The ability
to use mask characters is indicated in the description of the relevant parameters.
The following mask characters can be used:
? Represents any one character.
* Represents any number of characters (or no characters). This mask character is
only supported when at the end of a mask.
Examples
JBN? Matches JBN1, JBN2, etc.
J?N? Matches JBN1, JAN1, JUN2, etc.
JBN* Matches JBN1, JBN2, JBN123, JBN, JBN1234, etc.
*BN Invalid mask.
Stopping Utility CTTSBD
Utility CTTSBD may run for a long time. If you need to free up resources (e.g., tape drives)
for other processing, you can stop utility CTTSBD via the following operator command:
F jobname,STOP
where jobname is the name of the job or started task which is executing utility CTTSBD.
When the above STOP command is issued, utility CTTSBD acknowledges this fact (via an
operator message) and continues processing the remaining datasets in the current input volume
chain. When the current chain has been completely processed, utility CTTSBD stops.
If utility CTTSBD is restarted, you may need to modify the INCLUDE/EXCLUDE
statements so that previously processed volume chains are not processed again.
Reports
Utility CTTSBD produces a variety of reports detailing information relevant to the run of
the utility.
Media Utilization Report.
Lists the number of volumes and the amount of available space in each of several media
categories (scratch tapes, non-scratch tapes, etc.).
Input Volume Inventory.
Lists all input volumes selected for the run of utility CTTSBD and the datasets residing
on those volumes.
Output Volume Inventory.
Lists all output volumes created during the run of utility CTTSBD and the datasets
residing on those volumes.
Note The output volume inventory identifies output datasets whose names are identical
to the corresponding input dataset names and neither the input nor the output
dataset is cataloged. Via this report, such datasets can be tracked, making it easier
for you to take action (if necessary).
Detailed Input/Output Report.
For each input volume, the utility lists the input datasets and the corresponding output
datasets, output volumes, label numbers and retention information.
Note Expiration dates listed in this report for input datasets are the expiration dates
after the datasets have been processed by utility CTTSBD. The original expiration
date for these datasets is listed in the Input Volume Inventory (described above).
Output Volume Access Report.
Lists output datasets (in the order in which they were created) and the output volume on
which each output dataset was written. This report serves as a log for output volume mounts.
You can generate additional reports from the Media Database via utility CTTRPT.
See Utility CTTRPT earlier in this section for more information.
Simulation Reports
Utility CTTSBD can be run in simulation mode. This mode can be used to experiment with
various stacking configurations (i.e., dataset group definitions) without effecting dataset
location in the tape library.
In simulation mode, utility CTTSBD calculates output volume capacity according to the
value specified for parameter OUTVOLMB. A very large value can be specified for
parameter OUTVOLMB to indicate virtually unlimited capacity for output volumes. This is
useful for determining how many logical sets of output files will be produced by a run of
utility CTTSBD.
Multiple runs of utility CTTSBD in simulation mode can be used to compare the results of
batch stacking with various combinations of input volumes. The reports produced are
described above.
Note The reports generated by a run of utility CTTSBD in simulation mode assume that
arbitrary scratch volumes will be mounted, numbered with fictitious volume serial
numbers (volsers) 000001, 000002, 000003, etc. Simulated mounts are listed according
to the volsers of the fictitious scratch volumes.
Unstacking
Utility CTTSBD can unstack volume chains containing multiple datasets. Unstacking is
the process of copying each dataset to a different scratch tape, without stacking additional
datasets on the output volumes.
Input datasets are unstacked by specifying stacking statements (in dataset group
definitions) which prohibit each dataset in a specified group from coexisting on a volume
with any other dataset or by limiting the number of datasets which can be stacked on a
single volume.
See the examples provided later in this section for more information.
Recovery From Abends
Utility CTTSBD can perform recovery operations in the following situations:
Upon encountering a recoverable error during a run of the utility.
Upon initialization of the utility following a run of the utility which was terminated
due to a nonrecoverable error or a system crash.
Recovery is performed in the following way:
If an input dataset was uncataloged and failure occurred before the corresponding
output dataset was cataloged, utility CTTSBD attempts to recatalog the input dataset
during the recovery process.
Note Utility CTTSBD will attempt to recatalog a dataset only once. If the recatalog
attempts fails, the dataset will have to be recataloged manually.
In all other cases, input and output datasets remain in the state they were in at time of
failure (i.e., the abend or system crash).
This recovery logic ensures that at least one copy of each dataset is always retained and, if
necessary, cataloged. It may be necessary to scratch a single unneeded output dataset
created by an incomplete run of utility CTTSBD.
During recovery, CTTSBD will have to process no more than one dataset (i.e., the dataset
which was being processed at time of abend). Datasets processed prior to the abend require
no further processing.
Note If utility CTTSBD abended due to a physical or logical error in the Media Database,
use standard CONTROL-T methods to perform recovery. (See Repository Backup and
Recovery in Section 7 of the this guide for more information.)
Relevant Installation Parameters
Certain CONTROL-T installation parameters (specified in member CTTPARM) may be
relevant to utility CTTSBD operations. These parameters are described below.
DYNSTK Determines whether or not the CONTROL-T Dynamic Dataset
Stacking facility is activated. Utility CTTSBD performs Batch
stacking even if DYNSTK=N is specified.
MODE Determines CONTROL-T operation mode. Utility CTTSBD is fully
functional only when MODE=PROD is specified. However, CTTSBD can
be run in simulation mode while CONTROL-T is operating in any mode
(TEST, PHASED or PROD) or even when CONTROL-T is not active.
RTNTYPE Determines whether retention is performed on a dataset level or on a
volume level.
Input datasets are considered expired by utility CTTSBD only if they have
already been marked as expired by CONTROL-T (e.g., via utility CTTRTM).
If RTNTYPE=DSN is specified in member CTTPARM, datasets
whose expiration conditions are met are expired by CONTROL-T. If
COPYEXPF=NO is specified in utility CTTSBD, these datasets are
not copied during batch stacking.
If RTNTYPE=VOL is specified in member CTTPARM, datasets
whose expiration criteria are met are not expired by CONTROL-T
until all datasets on the volume can be expired. These datasets will
be copied during batch stacking regardless of the value specified for
CTTSBD parameter COPYEXPF.
STKMODE Determines the search algorithm to be used by the CONTROL-T
Dynamic Dataset Stacking facility. Utility CTTSBD ignores the
setting for this parameter. Parameter CHAINRET (described later)
provides similar controls for utility CTTSBD.
CTTMEDDF Specifies a CONTROL-T logical media definition.
Utility CTTSBD uses media definitions specified during CONTROL-T
installation (and other information) during calculation of output
volume capacity.
If volume capacity information produced during a run of CTTSBD
appears to be inaccurate, it may be necessary to modify the media
definition for the relevant volumes.
For more information on the above installation parameters, see Specify Stacking
Parameters in Section 9 of the IOA Installation Guide.
Preparation Steps
The following steps must be performed before the first run of utility CTTSBD at your site:
1. Allocate and format utility CTTSBDs Checkpoint-Restart dataset via batch job
CTTSBF in the CONTROL-T JCL library.
2. Implement security considerations.
CONTROL-T utility CTTSBD reads and writes datasets in your sites library. Relevant
Media Database records are subsequently updated. Therefore, the user ID associated
with the job or started task which executes the utility must be authorized to:
Read selected input datasets.
Create and write the output datasets (whose names may or may not be the same as
the names of the input datasets).
Read and update Media Database records.
Consult your security administrator to ensure that the required authorization is
defined for the user that will run utility CTTSBD.
// EXEC CTTSBD
//SYSIN DD *
TYPERUN MODE=NORMAL|SIMULATION[,NUMVOL=n][,TIMELIM=n]
,INUNIT=xxxx,OUTUNIT=xxxx,OUTRET=RULE|SAME|nnnn,
COPYATTR=YES|NO[,CHAINRET=ONE|ANY]
[,OUTPREF=xxx|NONE][,OUTSUFF=xxx|NONE]
OUTCAT=YES|NO|RECAT[,COPYEXPF=YES|NO]
[,OUTMVLIM=n][,MAXLABEL=n]
[,VAULTED=YES|NO|ONLY],INRET=nnnn|SAME,
[,OUTVOLMB=nnnnnn][,MAXERR=n][,CARTCOST=n]
[,PROCESS=CHAIN|DATASET][,DBGLEVEL=n]
[INCLUDE/EXCLUDE statements]
//CTTSBGRP DD *
GROUP NAME=groupname[,OUTMVLIM=n][,MAXLABEL=nnnn]
[,OUTPREF=xxx|NONE][,OUTSUFF=xxx|NONE]
[,INUNIT=xxxx][,OUTUNIT=xxxx]
DATASET [DSNAME=dsname-mask][,CREJBN=jobname-mask]
DATASET ...
[WITHGRP NAME=SAME|mask]
...
[NOTWGRP NAME=SAME|mask|OTHER]
...
[NOTWJOB NAME=SAME|mask]
...
[NOTWDSN NAME=SAME|mask]
...
GROUP ...
...
Parameters
Parameters specified for utility CTTSBD are arranged in the following way:
General utility parameters are specified via the SYSIN DD statement. These
parameters are arranged in one mandatory TYPERUN statement followed by one or
more INCLUDE/EXCLUDE statements. The parameters that can be included in these
statements are described below.
Dataset group parameters are specified via DD statement CTTSBGRP. Each group is
defined by a single GROUP statement followed by any number of DATASET,
WITHGRP, NOTWGRP, NOTWDSN and NOTWJOB statements in any order. Valid
statements and parameters for dataset group stacking are described later in this
section (following the general utility parameters).
General Utility Parameters
TYPERUN Operation type. Mandatory.
NORMAL Utility CTTSBD copies specified
datasets and updates the MVS
Catalog and the CONTROL-T Media
Database as specified by utility
parameters.
The utility also produces various
reports which describe the operations
it performed.
SIMULATION Utility CTTSBD selects input volumes
according to specified INCLUDE/
EXCLUDE statements and produces a
report indicating how input datasets
would be distributed in output volume
chains if utility CTTSBD were run in
NORMAL mode. No input or output
volumes are accessed.
NUMVOL Specifies a maximum number of input volumes to be
processed. Optional. A value from 0 to 9999 can be
specified.
When the specified number of input volumes is
reached, utility CTTSBD finishes processing the
datasets in the current input volume chain before
stopping.
If no value is specified for this parameter, all
selected volumes and datasets are processed.
TIMELIM Elapsed time (in minutes) beyond which the utility
should be stopped. A value from 0 to 9999 can be
specified. Default: No time limit.
If the specified time limit is reached, utility CTTSBD
finishes processing the datasets in the current input
volume chain before stopping.
INUNIT Unit name or unit address to be used by utility
CTTSBD for allocation of each input dataset. A name
of up to eight characters can be specified.
Mandatory.
This parameter can be overridden for specific
datasets via parameter INUNIT in a dataset group
definition.
OUTUNIT Unit name or unit address to be used by utility
CTTSBD for allocation of each output dataset.
A name of up to eight characters can be specified.
Mandatory.
datasets via parameter OUTUNIT in a dataset group
definition.
OUTRET Indicates retention information to be used for the
output dataset. Mandatory. Valid values:
nnn Specific number of days to retain output datasets.
A number from 1 to 9999 can be specified.
SAME Copy retention information
(e.g., retention type and expiration
date) from input dataset. Fields
RTNFROM, JCLEXPDT, DSEXPTYP
and DSEXPDT are copied from the
input dataset record.
If the expiration date of the input file
is known to CONTROL-T when the
dataset is copied, the output dataset is
set to expire on that same date.
Retention of an input dataset with
retention type DAYS is calculated
according to creation date. The output
dataset is created on a later date.
However, the output dataset is set to
expire on the date on which the input
dataset would have expired had
utility CTTSBD not been run.
RULE Apply CONTROL-T rules to determine
retention of the newly created output
dataset.
Note A prefix and/or suffix can be added via
parameters OUTPREF and OUTSUFF
described below.
COPYATTR Indicates whether or not certain attributes of an
input dataset should be copied to the corresponding
output dataset. Mandatory.
Y (Yes) Copy dataset attributes (e.g., creation
date, creating job and creating
program) from the input dataset to
the output dataset. This information
replaces the attributes assigned by
CONTROL-T to the newly created
dataset.
The following fields are copied from
the input dataset record:
ACCOUNT DSUSECT READUAD
CREDT DSEXCP READCC
CREUSER DUSRDATA WRITEDT
CREJOBID LASTACCS WRITETM
CRETM READDT WRITEJBN
CREJBN READTM WRITESTP
CRESTEP READJBN WRITEDDN
CREDDN READSTEP WRITEPGM
CRECPU READDDN WRITECPU
CRECC READPGM WRITEUAD
CREUAD READCPU WRITECC
See Appendix D in this guide for more
information on the content of these
fields.
N (No) Do not copy attributes from the input
dataset to the output dataset.
CHAINRET Determines whether or not utility CTTSBD should
force a uniform retention type on output volume
chains. Valid values:
ONE All datasets placed on a given output
chain must have the same retention
type (e.g., specific date or CATALOG).
An output dataset is added to an
existing chain only if its retention
type is identical to that of datasets
already in the chain.
ANY Datasets with different retention
types can reside on the same output
volume chain. Default.
OUTPREF Prefix to be added to the names of output datasets.
A period is inserted between the new prefix and the
original dataset name. Valid values:
xxx Prefix to be added (1 to 20 characters).
A period can be specified as part of
the OUTPREF value.
NONE Add no prefix to the dataset name.
Default.
This parameter can be overridden for
specific datasets via parameter
OUTPREF in a dataset group
definition.
Note If a new dataset name exceeds 44 characters,
utility CTTSBD stops processing the current
input volume chain.
OUTSUFF Suffix to be added to output dataset names. A period
is inserted between the original dataset name and
the new suffix. Valid values:
xxx Suffix to be added (1 to 20 characters).
the OUTSUFF value.
NONE Add no suffix to the dataset name.
Default.
datasets via parameter OUTSUFF in a dataset group
definition.
Note If a new dataset name exceeds 44 characters,
utility CTTSBD stops processing the current
input volume chain.
OUTCAT Indicates whether or not the output dataset should
be cataloged. Mandatory. Valid values:
Y (Yes) The action taken depends on whether
or not the input and output datasets
have the same name.
If the input dataset and the output
dataset have the same name (i.e.,
no prefix or suffix was added)
catalog the output dataset. If the
input dataset was cataloged,
uncatalog it.
If the input and the output
datasets do not have the same
name, catalog the output dataset.
If the input dataset was cataloged,
it remains cataloged. If the output
dataset name was already
cataloged, the utility stops
processing the current input
volume chain.
N (No) Do not catalog the output dataset.
RECAT Catalog the output dataset only if the
input dataset was cataloged.
Uncatalog the input dataset.
COPYEXPF Specifies whether or not input datasets previously
marked as expired by CONTROL-T should be copied
during this run of utility CTTSBD. Optional.
Y (Yes) Copy all datasets to output volumes.
N (No) Do not copy datasets marked as
expired. Default.
Note If an expired dataset is copied by utility
CTTSBD, its status is changed to ACTIVE (i.e.,
it is unscratched).
OUTMVLIM Specifies a maximum number of volumes for multi-
volume chains created by utility CTTSBD. Optional.
A value from 1 to 20 can be specified. Default: 1.
Parameter OUTMVLIM in a dataset group definition
can override this parameter for specific datasets.
Note Datasets can be stacked on volumes (or multi-
volume chains) created in a given run of utility
CTTSBD even after they have been dismounted.
If the specified limit is exceeded during the
writing of a multi-volume dataset (e.g., due to
inaccurate information about dataset length)
utility CTTSBD continues writing the dataset
on as many volumes as required.
MAXLABEL Specifies a maximum number of datasets to be stored
in an output volume chain created by utility
CTTSBD. A value from 1 to 9999 can be specified.
Default: 100.
datasets via parameter MAXLABEL in a dataset
group definition.
Note Datasets can be stacked on volumes (or multi-
volume chains) created in a given run of utility
CTTSBD even after they have been dismounted.
VAULTED Specifies if selected input volumes which are in a
vault or are scheduled to be vaulted, should be
processed by utility CTTSBD.
YES Process vaulted (and to-be-vaulted)
volumes.
NO Do not process vaulted (or to-be-
vaulted) volumes. Default.
ONLY Process only vaulted (and to-be-
vaulted) volumes.
INRET Indicates retention for input datasets. This
parameter is used to specify how long input datasets
should be retained after they are copied. Mandatory.
Valid values:
nnnn Retain input datasets nnnn days
before scratching them. A number
from 0 to 9999 can be specified.
SAME Do not modify type or duration of
retention for input datasets.
Note If either YES or RECAT is specified for
parameter OUTCAT and the retention type of
the input dataset is CATALOG, the input
dataset is expired when it is uncataloged by
utility CTTSBD.
To retain these input datasets for a longer
period, you must indicate a specific retention
period via parameter INRET.
OUTVOLMB Indicates the capacity (in megabytes) of an output
volume. This parameter is most useful for prediction
of utility results when running in simulation mode.
A value from 1 to 1000000 can be specified. Default:
200.
A very large value can be used during simulation to
determine how many logical sets of output datasets
will be created by a run of utility CTTSBD. (See
Simulation Reports above for more information.)
MAXERR Maximum number of allowable severe runtime
errors. Normally when the program encounters a
severe error, utility CTTSBD abandons the current
input volume chain and skips to the next input
volume chain. This parameter can be used to specify
a maximum number of abends that can be
encountered during the run of utility CTTSBD. If the
specified number of abends is exceeded, the utility
shuts down. A value from 0 to 100 can be specified.
Default: 1.
If MAXERR=0 is specified, utility CTTSBD will shut
down when the first severe error is encountered.
CARTCOST Cost of a single volume (cartridge) in the tape
library. This value should include media, slot space,
robot and management costs. A value from 1 to
1000000 can be specified. Default 20.
This parameter can be used to estimate savings
resulting from a run of utility CTTSBD at your site.
PROCESS Instructions for handling datasets which exist on the
same input volume chain as a dataset which matches
an INCLUDE/EXCLUDE statement.
CHAIN The INCLUDE/EXCLUDE statement
applies to all datasets in the same
input volume chain (i.e., either all or
none of the datasets are processed).
Default.
If one or more datasets in an input
volume chain match an INCLUDE
statement, all datasets on the
chain are selected.
If one or more datasets in an input
volume chain were rejected by the
INCLUDE/EXCLUDE statements,
no datasets on the chain are
processed.
DATASET Only datasets that match the
specified INCLUDE selection criteria
and are not rejected by subsequent
EXCLUDE statements are processed.
The following examples describes how parameter PROCESS can
influence the processing of an input volume chain.
All examples below apply to an input volume chain containing the
following datasets:
SYS1 Begins on volume VOL001 and ends on VOL002.
SYS2 Begins on volume VOL002 and ends on VOL003.
SYS3 Resides on VOL003.
Example 1
The following INCLUDE/EXCLUDE statements are specified:
INCLUDE VOLSER=*
EXCLUDE DSNAME=SYS1
The results are as follows:
If PROCESS=CHAIN is specified, none of the datasets are
processed by the utility.
If PROCESS=DATASET is specified, only SYS2 and SYS3 datasets
are processed by the utility.
Example 2
INCLUDE VOLSER=*
INCLUDE DSNAME=SYS3
EXCLUDE DSNAME=SYS1
If PROCESS=CHAIN is specified, none of the datasets are
processed by the utility.
If PROCESS=DATASET is specified, only datasets SYS2 and SYS3
Example 3
INCLUDE VOLSER=VOL003
If PROCESS=CHAIN is specified, all datasets (SYS1, SYS2 and
SYS3) are processed by the utility.
If PROCESS=DATASET is specified, only SYS2 and SYS3 datasets
DBGLEVEL Debug level. A numeric value from 1 to 255 can be specified.
This parameter should only be used if requested by your IOA
representative.
INCLUDE/EXCLUDE
Statement(s) specifying the volumes and datasets to be used as input
for utility CTTSBD. These statements are specified immediately after
the TYPERUN statement. At least one INCLUDE/EXCLUDE
statement must be specified.
Note If no include statement is specified (i.e., only EXCLUDE
statements are specified) an implicit INCLUDE statement, which
selects all volumes and datasets, is assumed.
Each INCLUDE/EXCLUDE statement specifies conditions for the
selection of a volume record and/or a dataset record from the Media
Database. If volume and dataset information are specified in an
INCLUDE/EXCLUDE statement, utility CTTSBD checks each dataset
record together with the record of the each volume in the chain on
which the dataset resides.
If a dataset on a volume chain matches an EXCLUDE statement, the
other datasets that exist together with it on the same volume chain
may or may not be processed depending on the value specified for
parameter PROCESS (described earlier).
The following fields can be specified in INCLUDE/EXCLUDE
statements for utility CTTSBD:
Dataset Record Fields Volume Record Fields
ACCOUNT DSEXPTYP ACTIVEDS VOLEXPDT
BLKSIZE DSCSIZE LACCDT VOLEXPTY
BLOCKCT DSLABEL LBLNUM VUSEDKB
CRECPU DSNAME LOCATION VOLODESC
CREDT DSVOLSER MEDIA VOLOWNER
CREJBN DUSRDATA VFREEKB VOLSEQ
CREPGM SMSMC USERDATA VOLSER
DCHANGED VOLSNUM VAULT
DSEXPDT
These fields enable you to select datasets and volumes according to
application, age, usage, size, free space, etc.
For more information on these fields and INCLUDE/EXCLUDE
statement format, see Record Selection Logic earlier in this section
and Appendix D: Logical Field Names of the CONTROL-T Repository
in this guide.
The following additional fields are created from information calculated
by utility CTTSBD and can also be specified in INCLUDE/EXCLUDE
statements as selection criteria for input datasets and input volumes:
VOLGROUP Dataset group name.
VOLPCT Percent of occupied space on a single volume or the
last volume of an input volume chain.
Volumes in a volume chain that are not the last
volume of the chain are always considered 100
percent full.
VOLSBAGE For volume chains created by a previous run of
utility CTTSBD, the number of days that have
passed since the volume chain was created.
Example
INCLUDE VOLPCT<5,DSNAME=ACCT.*
Selects all datasets on volume chains in which the last (or only)
volume is less than 5 percent full and contains a dataset with a prefix
of ACCT.
Dataset Group Stacking Parameters
Dataset groups are groups of datasets for which special stacking information is specified.
A group name is assigned to each dataset in a sequential matching process. Each dataset is
assigned the group name of the first group whose description matches the attributes of the
dataset. The group name assigned to each dataset remains assigned to the dataset for the
duration of the current run of utility CTTSBD.
Dataset groups and relevant information are defined in the file referenced by DD
statement CTTSBGRP.
Each dataset group is defined by a GROUP statement followed by one or more DATASET
statements. Any number of additional statements can be added in any order to determine
how datasets in the group should be stacked.
Valid dataset group statements and parameters:
GROUP Statement used to specify characteristics of a dataset group. This
statement is followed by various other statements which indicate
stacking rules for the dataset group. All statements listed between
this GROUP statement and the next GROUP statement determine
stacking rules for this dataset group. Valid parameters:
NAME Name of the dataset group. Datasets which satisfy at
least one of the DATASET statements below are
assigned this group name. A name from 1 to 20
characters in length can be specified.
OUTMVLIM Maximum number of volumes in a chain. Specifies a
number from 1 to 20. Datasets in this group will not
be added to multi-volume chains with more than the
specified number of volumes.
Datasets in this group are also not added to a multi-
volume chain with the specified number of volumes
if anticipated dataset size is larger than the
remaining space on the volume.
If no value is specified for this parameter, the value
specified in parameter OUTMVLIM in the
TYPERUN statement of utility CTTSBD is used.
MAXLABEL Maximum number of datasets in an output volume
(or multi-volume chain). A number from 1 to 999 can
be specified. Datasets in this group are not added to
a volume (or chain) which already contains the
specified number of datasets or more.
If no value is specified for this parameter, the value
specified in parameter MAXLABEL in the
TYPERUN statement of utility CTTSBD is used.
OUTPREF Prefix to be added to the names of output datasets in
this group. A period is inserted between the new
prefix and the original dataset name. Valid values:
xxx Prefix to be added (1 to 20 characters).
the OUTPREF value.
NONE Add no prefix to the dataset name.
If a value is specified for OUTPREF in the group
definition, that value overrides the OUTPREF value
specified in the TYPERUN statement of utility
CTTSBD.
OUTSUFF Suffix to be added at the end of output dataset
names in this group. A period is inserted between
the original dataset name and the new suffix.
xxx Suffix to be added (1 to 20 characters).
the OUTSUFF value.
NONE Add no suffix to the dataset name.
If a value is specified for OUTSUFF in the group
definition, that value overrides the OUTSUFF value
CTTSBD.
INUNIT Unit name to be used by utility CTTSBD for
allocation of each input dataset in this group.
If a value is specified for INUNIT in the group
definition, that value overrides the INUNIT name
CTTSBD.
OUTUNIT Unit name to be used by utility CTTSBD for
allocation of each output dataset in this group.
If a value is specified for OUTUNIT in the group
definition, that value overrides the OUTUNIT name
CTTSBD.
DATASET Statement used to determine which datasets belong to the group.
All datasets which match the specified mask(s) are associated with the
last specified group name. Multiple values specified in a single
DATASET statement have an AND relationship. Multiple DATASET
statements have an OR relationship.
The following fields can be specified:
DSNAME Dataset name or mask.
CREJBN Creating job name or mask.
Notes You can set a default group name by specifying DATASET
DSNAME=* in the last GROUP definition.
For Generation Data Groups (GDG datasets) the last qualifier
(GnnnnVnn) is excluded from the comparison of dataset names.
WITHGRP NAME Specifies a dataset group (or groups) with which datasets in this group
should be stacked.
grpname Group name or mask with which datasets in the
current group should be stacked. A name from 1 to
20 characters in length can be specified.
SAME Stack the datasets in the current group with
datasets from the same group.
If more than one WITHGRP statement is included in a group
definition, an OR relationship is assumed (i.e., the output dataset can
be stacked with any of the specified groups).
If no appropriate output volume (or volume chain) is located, the
dataset is written to a scratch volume.
NOTWGRP NAME Specifies a dataset group name or mask with which the datasets in the
current group should not be stacked. If more than one NOTWGRP
statement is specified, the output dataset is not stacked with datasets
from any of the specified groups.
grpname Group name or mask with which datasets in the
current group should not be stacked. A name from 1
to 20 characters in length can be specified.
SAME Do not stack datasets in the current group with
other datasets from the same group.
OTHER Do not stack datasets in the current group on
volumes with datasets from any other group (i.e.,
allow stacking only with datasets from the group
specified in the WITHGRP statement).
NOTWJOB NAME Specifies a job (or jobs) which create datasets that should not be
stacked with the datasets in the current dataset group.
jname Job name or mask. Datasets in the current group
should not be stacked with datasets created by the
specified job(s). A jobname or mask from 1 to 8
characters in length can be specified.
SAME Do not stack a dataset in the current group with
other datasets that have the same creating job name.
NOTWDSN NAME Specifies a dataset name or mask with which datasets in the current
dataset group should not be stacked.
dsname Dataset name or mask. Do not allow datasets from
the current group to be stacked on volumes with
datasets whose original names match the specified
name or mask.
Prefixes and/or suffixes added to output dataset
names are ignored by this parameter. Utility
CTTSBD compares the specified dataset name (or
mask) with the input dataset names that correspond
to the output datasets on the candidate volumes.
SAME Do not allow datasets in the current group to be
stacked on volumes containing datasets with the
same original input dataset name.
Note For Generation Data Groups (GDG datasets) the last qualifier
(GnnnnVnn) is excluded from the comparison of dataset names.
Return Codes
0 Utility CTTSBD completed successfully without errors.
4 Utility CTTSBD completed successfully, but at least one recoverable
error was encountered.
8 Missing DD statement(s) or an error occurred while opening a file.
12 Control statement error.
16 Load of CONTROL-T routines failed.
40 Authorization error (by security exit).
52 Logical error in Media Database.
56 Failure while allocating, opening or processing a dataset.
Example 1
This example copies all datasets residing on chains whose last volume is less than 5%
utilized. The datasets are divided into three dataset groups which are stacked separately:
System files (SYS*)
Accounting files (ACCT*)
All other files
SYSIN DD Statement
TYPERUN MODE=NORMAL,INRET=2,
OUTRET=SAME,OUTPREF=NONE,
OUTSUFF=NONE,COPYEXPF=NO,
OUTMVLIM=3,MAXLABEL=100,
VAULTED=NO,CARTCOST=10,
INUNIT=460,OUTUNIT=461,
MAXERR=30,OUTCAT=RECAT,
COPYATTR=YES,CHAINRET=ANY,
OUTVOLMB=200
INCLUDE DSNAME=*,VOLPCT<5
CTTSBGRP DD Statement (Dataset Group Definitions)
GROUP NAME=SYS
DATASET DSNAME=SYS*
WITHGRP NAME=SAME
GROUP NAME=ACCT
DATASET DSNAME=ACCT*
WITHGRP NAME=SAME
GROUP NAME=ALL
DATASET DSNAME=*
WITHGRP NAME=SAME
Example 2
This example unstacks all multi-volume chains which contain at least one dataset
beginning with a prefix of ACCT and whose last volumes are less than 10% utilized.
SYSIN DD Statement
OUTVOLMB=200
INCLUDE DSNAME=ACCT*,VOLSEQ>1,VOLPCT<10
The sites standard group definitions can be included in this file. Unstacking is indicated
by MAXLABEL=1 (specified in the TYPERUN Statement) and there is therefore no need
for additional group definitions.
GROUP NAME=ANY
DATASET DSNAME=*
Example 3
This example stacks all datasets with the prefix ACCT and makes sure that no two
datasets with the same name are written to the same output volume chain.
SYSIN DD Statement
OUTVOLMB=200
INCLUDE DSNAME=ACCT*
GROUP NAME=ACCT
DATASET DSNAME=ACCT*
NOTWDSN NAME=SAME
Example 4
This example performs a run of utility CTTSBD in simulation mode. In this run, copying of
all the sites datasets from 3480 cartridges to 3590 cartridges is simulated. New names are
assigned to the output datasets.
Dataset groups are determined according to first letter of each input dataset name.
SYSIN DD Statement
TYPERUN MODE=SIMULATION,INRET=SAME,
OUTRET=7,OUTPREF=TST3590,
OUTSUFF=TST,COPYEXPF=YES,
MAXERR=30,OUTCAT=YES,
OUTVOLMB=30000
INCLUDE DSNAME=*
CTTSBGRP DD Statement(Dataset Group Definitions)
Although the NOTWGRP statements in these dataset group definitions may appear
redundant, they are included to protect each group definition from new or modified group
definitions (specifying current group names in WITHGRP statements) which may be added
to the file.
GROUP NAME=GROUP-A
DATASET DSNAME=A*
WITHGRP NAME=SAME
NOTWGRP NAME=OTHER
GROUP NAME=GROUP-B
DATASET DSNAME=B*
WITHGRP NAME=SAME
NOTWGRP NAME=OTHER
GROUP NAME=GROUP-C
DATASET DSNAME=C*
WITHGRP NAME=SAME
NOTWGRP NAME=OTHER
.
GROUP NAME=GROUP-Z
DATASET DSNAME=Z*
WITHGRP NAME=SAME
NOTWGRP NAME=OTHER
CTTSCA Dataset Contention Detection
Utility CTTSCA analyzes SMF records to detect potential dataset contentions,
i.e., a situation in which two datasets on the same volume need to be accessed at the same
time.
The SMF records processed by utility CTTSCA are read from a sequential file which is
referenced by DD statement DASMFIN. The sequential file should contain relevant
accumulated type 14 and type 15 SMF records.
Utility CTTSCA performs one or both of the following tasks for each detected pair of
datasets:
Creates CONTROL-T rules which disallow stacking the datasets together on the same
volume.
Adds the dataset pair to a report produced by the utility.
This utility should be run before implementing the Dynamic Dataset Stacking facility.
Rules created by the utility should be reviewed and, if appropriate, added to a rule table
which is listed in CONTROL-T Rule Table member RULLIST in the CONTROL-T PARM
library.
After implementing the Dynamic Dataset Stacking facility, run utility CTTSCA
periodically (e.g., once a month) to check for new dataset contentions. The frequency with
which this utility should be run depends on the number of tape mounts performed daily at
your site.
// EXEC CTTSCA,RULELIB=rule-library,RULEMEM=rule-table-name
//DASMFIN DD DISP=SHR,DSN=smf=flat-file
//SYSIN DD *
TYPERUN LEVEL=ALL|JOB, [JOBPREF=prefix,]
CRERULE=YES|NO, [RULEPREF=prefix,][CONTSEAR=Y|N,]
[MODE=PROD|TEST,][PRIORITY=nn,]
[DURATION=nn]
INCLUDE/EXCLUDE STATEMENTS
REPORT NAME=CONFLICT
FIELDS ...
[SORTBY ...]
[ATTR ...]
[BREAK ...]
//
Parameters
The following control statements and parameters are supplied via DD statement SYSIN:
RULELIB Library to contain CONTROL-T rules which are created by the utility.
RULEMEM Name of the member to contain the CONTROL-T rules which are
created by the utility.
TYPERUN Used to specify parameters which affect the general functioning of the
utility. Mandatory. Only one TYPERUN statement can be specified for
each run of utility CTTSCA.
The following parameters can be included in the TYPERUN
statement:
LEVEL Level of contention to be detected. Mandatory. Valid
values:
JOB Search only for pairs of datasets which are
accessed simultaneously by the same job.
ALL Search for all pairs of datasets opened
simultaneously regardless of whether or not
they are accessed by the same job. This is
the recommended value.
JOBPREF Prefix for jobs whose SMF records should be checked for
contention problems. A prefix of one to eight characters
can be specified. Optional.
If LEVEL=JOB is specified, the utility searches for
pairs of datasets which are accessed simultaneously
by the same job (for jobs with the specified prefix).
If LEVEL=ALL is specified, the utility searches for
all datasets which are accessed by jobs with the
specified prefix at the same time as other datasets
accessed by jobs with the specified prefix. Default.
DURATION Tolerated contention duration in minutes. Optional.
Default: 5 minutes.
Contention duration is the amount time during which a
pair of datasets were simultaneously accessed. For
example, if dataset DSA was accessed from 10:00 until
10:10 and dataset DSB was accessed from 10:05 until
10:30, the duration of contention between these two
datasets is five minutes.
If the detected dataset contention lasts for less than the
specified duration, the contention is tolerated (i.e., no
rule is created to prevent stacking these two datasets
together).
RULEINFO Used to specify rule information parameters which affect the general
functioning of the utility. Mandatory. Only one RULEINFO statement
can be specified for each run of utility CTTSCA.
The following parameters can be included in the RULEINFO
statement.
CRERULE Indicates whether or not CONTROL-T rules should be
created by the utility. Mandatory.
Y (Yes) Create two rules for each pair of datasets
detected by the utility.
For example, if datasets DSA and DSB are
accessed at the same time, one rule is
created to prevent DSA from being stacked
with DSB. Another rule is created to
prevent DSB from being stacked with DSA.
N (No) Do not create rules during this run of utility
CTTSCA.
RULEPREF Prefix for rules created by the utility. The value of this
parameter must be alphanumeric. Maximum length: 4
characters. Mandatory if CRERULE=YES is specified.
CONTSEAR Value to be inserted in the CONTINUE SEARCH field
of CONTROL-T rules created in this run of the utility.
Optional.
Y (Yes) Set the CONTINUE SEARCH field to Y.
Default.
N (No) Set the CONTINUE SEARCH field to N.
MODE Value to be inserted in the MODE field of CONTROL-T
rules created in this run of the utility. Optional.
PROD Set the MODE field to PROD. Default.
TEST Set the MODE field to TEST.
PRIORITY Value to be inserted in the SEQUENCE PRIORITY
field in CONTROL-T rules created in this run of the
utility. Optional.
The value specified must be two alphanumeric
characters. See SEQUENCE PRIORITY in Section 3
of the CONTROL-T User Manual for more information
about valid values for this parameter.
If no value is specified, the SEQUENCE PRIORITY
field is blank in rules created by the utility.
INCLUDE/EXCLUDE
SMF records which describe tape access are used as input for utility
CTTSCA. The SMF records to be processed by the utility can be
filtered by one or more INCLUDE/EXCLUDE statements. For more
information about INCLUDE/EXCLUDE statements, see Record
Selection Logic earlier in this section. Optional.
Values that can be specified in INCLUDE/EXCLUDE statements of
utility CTTSCA are listed in Table 6 of Appendix D in this guide.
If no INCLUDE/EXCLUDE statement is specified for utility CTTSCA,
all SMF records describing actions on tape datasets are processed by
the utility.
REPORT Report to be generated by the utility. Mandatory.
The following parameter must be specified:
NAME = CONFLICT
A contention detection report, produced by the utility, lists all detected
pairs of datasets. The fields in this report are determined by the
FIELDS statement (described below).
FIELDS Fields which should be printed in the report produced by the utility.
Mandatory.
Fields are included in the report produced by the utility in the order in
which they are specified in the FIELDS control statement. Valid field
names:
CPUID1 CPU ID of the first dataset.
CPUID2 CPU ID of the second dataset.
DSNAME1 First dataset name.
DSNAME2 Second dataset name.
DURATION The duration of the detected contention.
JOBNAME1 Jobname of the first dataset.
JOBNAME2 Jobname of the second dataset.
VOLUME1 First volume of the first dataset.
VOLUME2 First volume of the second dataset.
DATE1 Date the first dataset was opened.
DATE2 Date the second dataset was opened.
TIME1 Time of day first dataset was opened.
TIME2 Time of day second dataset was opened.
CRERULE1 Indication whether a rule was generated to prevent the
first dataset from being stacked with the second dataset.
CRERULE2 Indication whether a rule was generated to prevent the
second dataset from being stacked with the first dataset.
REASON1 Reason for not creating a rule to prevent the first
dataset from being stacked with the second dataset.
Possible reasons:
USER REQ The user specified CRERULE=NO
TOLERATED The time during which the two
datasets were both accessed was
shorter than the time specified for
parameter DURATION (described
above).
REASON2 Reason for not creating a rule to prevent the second
dataset from being stacked with the first dataset.
Possible reasons are the same as described above for
field REASON1.
RULENAM1 Name of the rule created to prevent the first dataset
from being stacked with the second dataset.
RULENAM2 Name of the rule created to prevent the second dataset
from being stacked with the first dataset.
SORTBY Order in which the report is sorted. Optional. (Available fields are
listed above under parameter FIELDS.) The /B (or /BRK) option can be
added as a suffix to any field to indicate that a page break should be
inserted in the report when the field changes its value.
Optional.
occurs. Optional.
Return Codes
4 Report statement not provided. Report not created.
12 An error was detected in a control statement specified to the utility.
16 Sort error occurred. See the SYSOUT file for more information about the error.
Example
The following example requests detection of all possible contentions, creation of preventive
rules and a contention report.
Example for SYSIN statements:
//SYSIN DD *
TYPERUN LEVEL=ALL
RULEINFO CRERULE=YES,RULEPREF=NEWR,CONTSEAR=Y
REPORT NAME=CONFLICT
FIELDS CPUID1/C3,JOBNAME1/C12,DSNAME1/C23,
DATE1/C69,TIME1/C78,DURATION/C87,
CRERULE1/C98,REASON1/C107,RULENAM1/C119,ID=P
FIELDS CPUID2/C4,JOBNAME2/C13,DSNAME2/C24,
DATE2/C69,TIME2/C78,
CRERULE2/C98,REASON2/C107,RULENAM2/C119,ID=S
/*
Below is a sample portion of a report produced by utility CTTSCA. Each line in the report describes a pair of datasets that can be in
possible contention. Rules created by the utility (to prevent Dataset 1 from being stacked together with Dataset 2 and vice versa)
are also listed in this report.
Contention Detection Report
---------------------------
CpuId 1 Jobname 1 Dataset 1 Open Open Possible Rule 1 Reason 1 Rule
Date 1 Time 1 Contention Created? Name 1
CpuId 2 Jobname 2 Dataset 2 Open Open Duration Rule 2 Reason 2 Rule
Date 2 Time 2 Created? Name 2
-------- ---------- --------------------------------------------- -------- -------- ---------- -------- ---------- --------
MVSP DFHSM DFHSM.HMIGTAPE.DATASET (GDG) 12/10/98 08:12:36 00:03:34 NO TOLERATED
MVSP UH56VPM0 HZ.PROD.RDADLSQC.SEQ 12/10/98 08:10:10 YES NEWR0001
MVSP DFHSM DFHSM.HMIGTAPE.DATASET (GDG) 12/10/98 09:47:19 00:00:44 NO TOLERATED
MVSP DFHSM DFHSM.BACKTAPE.DATASET (GDG) 12/10/98 09:45:58 YES NEWR0002
MVSP UC95VPM0 HZ.PROD.RDADLSQC.SEQET 12/10/98 09:47:40 00:01:09 NO TOLERATED
MVSP DFHSM DFHSM.HMIGTAPE.DATASET (GDG) 12/10/98 09:47:19 YES NEWR0003
MVSP UC95VPM0 HZ.PROD.RDADLSQC.SEQET 12/10/98 09:47:40 00:00:23 NO TOLERATED
MVSP DFHSM DFHSM.BACKTAPE.DATASET (GDG) 12/10/98 09:45:58 YES NEWR0004
MVSP PMS6105M MS.PROD.MGSRT.SEQSEQET 12/10/98 09:48:36 00:05:30 YES NEWR0005
MVSP UC95VPM0 HZ.PROD.RDADLSQC.SEQET 12/10/98 09:47:40 YES NEWR0006
MVSP PMS6105M MS.PROD.MGSRT.SEQSEQET 12/10/98 09:48:36 00:00:13 NO TOLERATED
MVSP DFHSM DFHSM.HMIGTAPE.DATASET (GDG) 12/10/98 09:47:19 YES NEWR0007
MVSP PMS6105M MS.PROD.MDSRT.SEQSEQET 12/10/98 09:50:07 00:03:59 NO TOLERATED
MVSP UC95VPM0 HZ.PROD.RDADLSQC.SEQET 12/10/98 09:47:40 YES NEWR0008
CTTSPL Copies or Moves Media Database Records
Utility CTTSPL extracts (i.e., moves or copies) Media Database records for transfer to a
different Media Database. Before using this utility, it is important to review the
information in Split and Merge Processing below.
Notes There is no need to shut down CONTROL-T while running this utility.
Utility CTTMER (used to merge information extracted via utility CTTSPL)
automatically updates the Media Database index component. There is no need to run
utility CTTBIX after running this utility.
Split and Merge Processing
The split and merge process is the method by which information is extracted (split) from
one Media Database and inserted (merged) into another Media Database (usually at a
different site). This process is especially useful when a decision is made to join two Media
Databases or to split a large Media Database in two or more smaller Media Databases.
The split and merge process is performed via utilities CTTSPL and CTTMER.
Utility CTTSPL extracts records from the source Media Database according to specified
selection criteria. This utility can be used with either of two functions.
MOVE Moves selected records to the extract file and deletes them from the source
Media Database.
COPY Copies selected records from the source Media Database to the extract file.
The source Media Database is not altered when this function is specified.
The output of utility CTTSPL (the extract file) is a predefined sequential file
(olpreft.olvert.REPDATA) allocated as one of the CONTROL-T operations libraries at
time of CONTROL-T installation.
Utility CTTMER merges the extracted Media Database records into the Media
Database in the target system. Utility CTTMER uses the extract file created by
CTTSPL as input.
If utility CTTSPL is being used to move (not copy) Media Database records, the selected
records are deleted from the source Media Database.
If the target Media Database is in a different site, the extract file (REPDATA) produced by
utility CTTSPL must be transferred to the target site.
Data Integrity
Utilities CTTSPL and CTTMER do not check Media Database integrity.
It is highly recommended that utility CTTIDB be used to check the integrity of the source
Media Database before execution of utility CTTSPL. To avoid transfer of data errors to the
target Media Database, integrity errors detected by utility CTTIDB should be fixed in the
source Media Database before execution of utility CTTSPL.
It is also recommended that utility CTTIDB be used after the split and merge process to
check the integrity of the:
Source Media Database after running utility CTTSPL (if the MOVE function was
specified).
Target Media Database after execution of utility CTTMER.
Simulation Mode
Utilities CTTSPL and CTTMER can be executed in simulation mode. In this mode, no
Media Database updates are performed. In simulation mode, messages are sent to the
utility log to record the updates that would have been performed on the Media Database if
the utility were running in normal mode.
If the last run of the utility abended, simulation mode is not allowed. If an attempt is made
to run the utility in simulation mode, the utility is terminated and an appropriate message
is displayed.
A special restart simulation mode is available for utility CTTMER. (See the description of
parameter MODE in utility CTTMER for more information.)
Note Since the Media Database is not updated in simulation mode, it is possible that a run
of one of these utilities in simulation mode will end successfully, while the
corresponding run in normal mode could abend (e.g., due to a lack of free space in the
Media Database).
Volume Status
Utilities CTTSPL and CTTMER do not check volume status. Volume records are split and
merged regardless of volume status. For some volumes (e.g., those with a status of
VAULTED or PENDING-VAULT) this can result in inaccurate slot definitions.
To correct this problem, it is necessary to run utility CTTVTM in SLOTBLD mode to rebuild the
Slot Definition Records. Utility CTTVTM should be run against both the source Media
Database and the target Media Database after completion of the split and merge process.
Recovery from Abends
CONTROL-T can recover from abends occurring during the run of utilities CTTSPL and
CTTMER. If the utility has abended during update of the Media Database (deletion of
records in utility CTTSPL or addition of records in utility CTTMER) when the utility is run
again it will automatically enter RESTART mode and recover from the abend.
The extract file (REPDATA) must not be altered (or deleted) prior to restart execution of
utility CTTSPL or CTTMER. It is highly recommended that this file be backed up after
each run of utility CTTSPL to facilitate recovery.
Undoing Splits and Merges
You can choose to undo the actions of the Split/Merge utilities as follows:
Splits If utility CTTSPL was run with the MOVE function, use utility
CTTMER to merge the extracted records from the extract (REPDATA)
file back into the source Media Database. (Specify the source Media
Database as the target Media Database).
Note If the extract file no longer exists but the extracted records have
been merged into the target Media Database, they can be extracted
(copied or moved) from the target Media Database into another
extract file and then merged back into the source Media Database.
If utility CTTSPL was run with the COPY function, the source Media
Database is unchanged and there is no need to undo anything.
Merges To remove records that have been merged into the target Media
Database, use utility CTTSPL with the MOVE function to extract the
necessary Media Database records from the target Media Database.
The selection statements passed to the utility must include only the
volumes added previously by utility CTTMER.
Activating Utility CTTSPL
// EXEC CTTSPL
//SYSIN DD *
EXTRACT PATH=ALL
/*
//DAIN DD *
TYPERUN FUNCTION=COPY|MOVE[,MODE=NORMAL|SIMULATE][,DBGLEVEL=XXX]
/*
Parameters
EXTRACT PATH=ALL
EXTRACT statement specified via DD statement SYSIN. This is the
only EXTRACT statement allowed with utility CTTSPL. Mandatory.
INCLUDE/EXCLUDE
The scope of the utility can be limited by one or more INCLUDE
and/or EXCLUDE statements.
INCLUDE/EXCLUDE statements are specified immediately after the
EXTRACT statement in the SYSIN DD statement. For more
information see Record Selection Logic earlier in this section.
TYPERUN The TYPERUN statement is specified via DD statement DAIN. The
format for this statement is:
TYPERUN FUNCTION=COPY|MOVE[,MODE=NORMAL|SIMULATE][,DBGLEVEL=XXX]
where:
FUNCTION The function to be performed. Mandatory. Valid values:
COPY Records are copied from the source
Media Database to the extract file
(REPDATA). Copied records are not
deleted from the source Media
Database.
MOVE Records are moved from the source
Media Database to the extract file.
Moved records are deleted from the
source Media Database.
MODE Operation mode. Optional. Valid Values:
NORMAL Normal operation mode. Default.
SIMULATE Simulation mode. No changes are
made to the Media Database.
Messages are sent to the utility log to
show which changes would have been
made to the Media Database if the
run were in NORMAL mode.
Note The result of running utility CTTSPL in
simulation mode is identical to running it with
FUNCTION=COPY specified. The resulting extract
file (REPDATA) can be used as input for a regular
(or simulation mode) run of utility CTTMER.
Note This parameter should be used only if requested
Example 1
In this example, utility CTTSPL extracts the records for all volumes beginning with VOL.
The records for the volumes and their associated datasets are removed (deleted) from the
source Media Database and placed in the extract file (REPDATA) to be used later as input
for utility CTTMER.
// EXEC CTTSPL
//SYSIN DD *
EXTRACT PATH=ALL
INCLUDE VOLSER=VOL*
/*
//DAIN DD *
TYPERUN FUNCTION=MOVE
Example 2
In this example, utility CTTSPL extracts the records of all datasets beginning with
MY.FILE. The records for these datasets and the associated volumes are copied (not
deleted) from the source Media Database and placed in the extract file (REPDATA) to be
used later as input for utility CTTMER.
// EXEC CTTSPL
//SYSIN DD *
EXTRACT PATH=ALL
INCLUDE DSNAME=MY.FILE*
/*
//DAIN DD *
TYPERUN FUNCTION=COPY
/*
Return Codes
8 Initialization problem.
12 Extract failed.
16 Split failed.
20 Simulation mode is not allowed while restart is required.
Greater than 20 Severe error the error is accompanied by a message describing the
problem.
CTTSTK Build and Update Stacking Database
This utility builds and updates the Stacking Database. The utility should be run on a
regular basis via job CTTDAY.
The utility accepts input from one of the following three types of datasets:
System Management Facilities (SMF) accumulated type 15 records (not the actual SMF
files)
Media Database records.
Trace file records.
The purposes, advantages, and disadvantages of using Media Database and Trace file
input are described in the table below. SMF type 15 records can be used to supplement
Trace file input, if necessary, to decrease the time required to accumulate comprehensive
statistics in the Statistics Database.
Media Database Trace File (and SMF type 15 Records)
Purpose To load the Stacking
Database when
installing the Dynamic
Dataset Stacking
facility.
To update the Stacking Database with the
latest statistics on a daily basis.
Advantages The Stacking Database
will have statistics for
most datasets.
All statistics transferred to the Stacking
Database will be accurate and up-to-date.
Disadvantages Some data transferred
to the Stacking
Database will come
from scratched dataset
records. This data may
be inaccurate and out-
of-date.
When the Trace file is full, its oldest
records are overwritten. Consequently, only
statistics for recently used datasets will be
transferred to the Stacking Database. It
may require several updates for the
Stacking Database to accumulate
comprehensive statistics.
Input records can be selected according to INCLUDE/EXCLUDE statements (see below)
supplied to the utility. Record timestamps are inserted in the dataset. Records from
different utility runs with earlier timestamps are considered duplicate records and are
dropped. Therefore, records with overlapping timestamps from different source computers
should not be supplied to the utility in the same run.
// EXEC CTTSTK
//SYSIN DD *
TYPERUN MODE=SMF|TRC|MDB
//
Parameters
TYPERUN Statement type. Mandatory.
MODE Source of input records. Mandatory.
SMF Input records come from accumulated SMF
type 15 records.
In this mode, parameter SMFIN (supplied
to procedure CTTSTK) specifies the name of
a file containing accumulated SMF records.
TRC Input records come from the Trace file. This
mode should be used for regular updates of
the Stacking Database (e.g., as part of the
CONTROL-T New Day procedure).
MDB Input records come from the Media
Database. This mode should be used only
for the first run of utility CTTSTK (i.e.,
when the Stacking Database is empty).
INCLUDE/EXCLUDE
The scope of the utility can be limited by one or more INCLUDE or EXCLUDE statements.
The subparameters which can be specified in INCLUDE/EXCLUDE statements are listed
in Table 3 in Appendix D: Logical Field Names for the CONTROL-T Repository this
guide.
For additional information on INCLUDE and EXCLUDE Statements, see Record Selection
Logic (INCLUDE/EXCLUDE Statements) earlier in this section.
Gathering Statistics for Datasets with Non-specific Retention
Utility CTTSTK gathers additional statistical information for datasets with non-specific
retention (i.e., retention types CYCLES, CATALOG and LAST ACCESS). The average life
span of a scratched dataset with non-specific retention is calculated by the utility and
saved in the STK file. This information is calculated only for datasets that were scratched
during execution of utility CTTRTM. The average life span is not calculated for datasets
that are manually scratched (i.e., scratched by using option E in the TI screen).
For information about how a datasets average life span is used by the Dynamic Stacking
facility, see Stacking Datasets With Non-Specific Retention in Section 4 of the
CONTROL-T User Guide.
Return Codes
4 Input statement(s) missing.
8 DCB open error occurred.
12 Input statement parsing error occurred.
16 CONTROL-T Control Table (TCT) load failed.
24 Media Database/ Stacking Database /Trace file I/O error occurred.
CTTSTKR Stacking Statistics Report Utility
Utility CTTSTKR extracts data from the Stacking Database and generates reports from
the extracted data. Various parameters can be used to format and to filter the report
produced by this utility (e.g., to describe only statistics for specified datasets).
// EXEC CTTSTKR
//SYSIN DD *
REPORT NAME=STACKING
FIELDS ...
[SORTBY ...]
[ATTR ...]
[BREAK ...]
//
Parameters
INCLUDE/EXCLUDE
The information to be processed can be filtered by one or more
INCLUDE/EXCLUDE statements. Valid values that can be specified
in these INCLUDE/EXCLUDE statements are listed in Table 7 in
Appendix D of this guide.
If no INCLUDE/EXCLUDE statement is specified, a report is created
for all records in the Stacking Database.
REPORT The report to be produced by the utility. Mandatory.
NAME Report name. Mandatory. Valid value is:
STACKING Stacking Statistics Report listing all
requested statistics for the CONTROL-T
controlled datasets.
FIELDS Fields to print in the report. The fields are printed in the order in
which they are specified. Available fields:
JOBNAME Name of the job that created the dataset.
DSNAME Name of the dataset.
STATUS Whether or not the dataset is stackable.
UNIT Unit name on which the dataset was created.
DENSITY Density with which the dataset was recorded.
OBSERVE Number of observations of the dataset which were used
to determine statistics for the dataset.
MAXSIZE Maximum dataset size in Kilobytes (KB).
MINSIZE Minimum dataset size in Kilobytes (KB).
TOTSIZQ Sum of the square of dataset size for all previous
observations in Kilobytes (KB).
STDDEV Standard deviation (in Kilobytes) of dataset size for all
observations.
AVGSIZE
1
Average dataset size in Kilobytes (KB).
PREDICTD Predicted dataset size in Kilobytes (KB).
AVGSIZEU Average uncompressed dataset size in Kilobytes.
PREDICTU Average predicted uncompressed dataset size in
Kilobytes.
LIFEOBS Total number of observations of the dataset (including
observations which were not used to calculate dataset
statistics). This field is relevant only for datasets with
non-specific retention (e.g., CATALOG or LAST
ACCESS).
LIFESPAN Average life span of the dataset in days. This field is
relevant only for datasets with non-specific retention
(e.g., CATALOG or LAST ACCESS).
1
Prior to CONTROL-T Release 5.1.4 this field was called FOOTAGE.
SORTBY Order in which the report is sorted. Optional. (Available fields are
listed above, under parameter FIELDS.) The /B (or /BRK) option can
be added as a suffix to any field to indicate that a page break should
be inserted in the report when the field changes its value.
Optional.
occurs. Optional.
Return Codes
Example
The following example extracts stacking statistics information and produces reports for
datasets which:
Have a maximum size of less than 70 Kilobytes.
Were created and monitored under the control of CONTROL-T less than 15 times
(generations).
// EXEC CTTSTKR
//SYSIN DD *
INCLUDE OBSERVE<15,MAXSIZE<70
REPORT NAME=STACKING
FIELDS JOBNAME,DSNAME,STATUS,DENSITY,MAXSIZE,MINSIZE,TOTSIZQ,
OBSERVE,AVGSIZE
/*
Stacking Statistics Report
--------------------------
Jobname Dataset name Stackable? Density Maximum Minimum Total Observ- Average
Size(KB) Size(KB) Square ations Size
Size (KB)
-------- -------------------------------------------- ---------- -------- ------- ------- ------ ------- -------
M27EXIT M27.NEW.DIMENS YES BPI38KE 2 2 4 1 1
M27S M27.TRY1 YES BPI38KE 2 2 4 1 1
M27STK M27.TRY1 YES BPI38KE 2 2 4 1 1
M27SVC M27.SVC YES BPI38K 2 2 4 1 1
N22SB05 N22.SB.F001 YES BPI38KE 28 28 784 1 3
N22T01 N22.SB.F001 YES BPI38K 28 28 784 1 3
N22T01 N22.SB.F002 YES BPI38K 67 67 4489 1 6
N22T01 N22.SB.F003 YES BPI38K 28 28 784 1 3
N22T01 N22.SB.F004 YES BPI38K 67 67 4489 1 6
N65CHAIN N65.TRY.DS YES BPI38KE 2 2 4 1 1
N65DFDSS N65.TRY.DFDSS YES BPI38KE 5 5 25 1 1
N70STACK N70.STACK.DSN1 YES BPI38KE 2 2 8 2 1
N89GENER N89.EXPDT.Y2000.FILE1 YES BPI38K 7 7 49 1 1
N89GENER N89.NON.SPECIFIC YES BPI38K 7 7 49 1 1
N89GENER N89.PERM.FILE1 YES BPI38K 7 7 49 1 1
N89GENE1 N89.ACCT.CAT3 YES BPI38K 7 7 49 1 1
CTTSYNC Synchronize Robot Database & Media Database
Utility CTTSYNC synchronizes information in the CONTROL-T Media Database and the
database of the robot in use at your site. The utility can be used to:
Check and update the status (i.e., SCRATCH or ACTIVE) of volumes in the robot
database according to their statuses as indicated in the Media Database.
Check the robot database to determine if volumes in the Media Database are or are not in
the robot and update the volumes status and location in the Media Database accordingly.
Perform both of the functions.
The actual operations performed by utility CTTSYNC depend on the value specified for
parameter UPDATE (described below).
When the utility finishes processing, messages describing the results are issued.
Note Depending on the robot(s) in use at your site, this utility usually updates information
about the internal location of each selected volume in the robotic tape library.
// EXEC CTTSYNC
//SYSIN DD *
TYPERUN UPDATE=MDB|RDB|BOTH,MODE=NORMAL|SIMULATION
//
Parameters
TYPERUN General statement containing parameters for the utility. Only one
TYPERUN statement can be specified for each run of utility CTTSYNC.
The following parameters can be included in the TYPERUN
statement:
UPDATE The type of data to be synchronized. Mandatory. Valid
values:
MDB Check if volumes that are listed in the
Media Database are in the robot. If
necessary, update the volumes status
and location in the Media Database.
RDB Check the status (i.e., ACTIVE or
SCRATCH) of each volume in the Media
Database. Update the robot database so
that it indicates the same status.
BOTH Perform both of the above described
operations.
MODE Mode in which the utility will run. Optional. Valid values:
NORMAL Checks are performed, appropriate
messages are issued and the Media
Database or robot database is updated
accordingly. Default.
SIMULATION Checks are performed and messages are
issued, but the Media Database and
robot database are not updated. This
mode can be used to determine the extent
to which the robot database and Media
Database are out-of-sync without
modifying either database.
INCLUDE/EXCLUDE
The volumes to be processed can be filtered by one or more
INCLUDE/EXCLUDE statements. Valid values that can be specified
in these INCLUDE/EXCLUDE statements are listed in Table 2 in
Appendix D of this guide.
If no INCLUDE/EXCLUDE statements are specified for utility
CTTSYNC, all volumes in the Media Database are processed.
Return codes
8 Missing DD name(s) or file open error.
12 Error in control statement specified to the utility.
16 Internal error.
20 Read/update of the Media Database failed.
24 Robot interface service has failed.
Example
The following example searches for volumes in the Media Database with a volser prefixed
by V001 and then checks the robot database to determine if these volumes are in the robot.
If an in-robot indication in the Media Database is incorrect, it is updated accordingly.
// EXEC CTTSYNC
//SYSIN DD *
TYPERUN UPDATE=RDB
INCLUDE VOLSER=V001*
//
CTTTPI Tape Initialization, Information Mapping, and
Tape Erasure
The utility provides the following major functions:
Safe Tape Initialization (INITT) Initializes tapes and cartridges. Checks that a
volume is not active before initializing it,
thereby ensuring that active volumes are not
accidentally initialized.
Media Information Mapping (TAPEMAP) Produces a detailed report about the logical
and physical content of a volume including
logical files, labels, tape marks and unreadable
areas (I/O errors).
Safe Tape Erasure (TAPERAS) Physically erases the contents of a volume.
Checks that a volume is not active before
erasing it, thereby ensuring that active
volumes are not accidentally erased.
These functions are described in detail below.
Multiple jobs or started tasks can run utility CTTTPI in parallel on separate tape drives
for distinct ranges of volume serial numbers.
Safe Tape Initialization Function INITT
Utility CTTTPI protects active volumes from initialization by checking the specified
volume serial number and the mounted volume before creating tape labels. Volumes are
protected regardless of whether or not they appear in the Media Database (MDB).
Utility CTTTPI initializes magnetic media (tape-reels and cartridges) with standard labels
(SL) or with ANSI standard labels (AL).
The initialization function is generally invoked as a started task via command:
S CTTTPI,V=volser,[U=unitname|devnum,]F=INIT
This command invokes the utility with the single control statement:
INITT SER=volser,NUMBTAPE=999
When invoked in this manner, the utility first checks that the specified target volume
serial number is either not in the Media Database or is in the Media Database with scratch
status.
If the target volume serial number passes the first check, the utility requests that the
operator mount the physical volume. Once the volume is mounted, the utility reads it to
verify that it is not an active volume in the Media Database.
If both the specified target volume and the physical mounted volume pass the checks, the
desired label is written on the mounted volume.
If the specified volser is numeric, the utility requests successive volumes in ascending
order until stopped or canceled by the operator.
The utility issues messages (e.g., CTT289A) and sometimes prompts the operator for a
reply or decision.
If CONTROL-O or CONTROL-O/PC is installed at your site, responses to the messages can
usually be automated.
Depending on specified parameters, the Media Database can be updated by the utility.
Media Information Mapping Function TAPEMAP
Utility CTTTPI can produce a detailed report about the logical and physical content of a
volume including logical files, labels, tape marks and unreadable areas (I/O errors).
This function is especially useful when recovering files and/or data which have been
partially-overwritten on magnetic media (e.g., a longer file partially overwritten by a
shorter file or multi-file volumes in which the first few files have been overwritten).
The tape mapping function is generally invoked as a started task via command:
S CTTTPI,[V=volser,][U=unitname|devnum,]F=MAP
This command invokes utility CTTTPI with the single control statement:
TAPEMAP SER=volser
The TAPEMAP function produces a report which contains a single line for each of the
following elements:
Element Description
VOL1 Volume label.
HDR1 First part (and sometimes the only part) of a header label which
describes a standard label dataset.
HDR2 Second part of a dataset label.
DATA BLOCKS Actual data portion of a file on the media.
EOF1 First part of a dataset trailer label.
EOF2 Second part of a dataset trailer label.
EOV1 First part of an End-Of-Volume tape label. This element appears when
the preceding standard label dataset continues on another volume.
EOV2 Second part of an End-Of-Volume tape label.
Tape Mark Physical indication on the media which separates one physical file
from another and separates standard labels from data. Two
consecutive tape marks commonly determine the logical end of the
recorded area on the media.
I/O Error Area which could not be read by CTTTPI.
The TAPEMAP function reports information extracted from the above elements such as the
dataset name (i.e., the full dataset name if it does not exceed 17 characters, or the last 17
characters of a longer dataset name) creation date, creating job name, block size, physical
and logical file sequence numbers.
Physical file sequence numbers are counted by tape marks. Each tape mark on the tape
indicates an end-of-file. Logical file sequence numbers are extracted from HDR1. If there is
no HDR1 on the tape (e.g., an NL tape) the logical file sequence number is blank.
If a map of the complete media is requested (parameter STOP=N, described later) datasets
written beyond the present logical end of the recorded area can be examined.
Safe Tape Erasure Function TAPERAS
Utility CTTTPI protects active volumes from being erased by comparing the specified
volume serial number and the volser of the mounted volume, before erasing the data on the
tape. Volumes are protected regardless of whether or not they appear in the Media
Database.
Utility CTTTPI uses an MVS function (Data Security Erase EXCP) to erase tapes. This
function writes a random pattern of data on the specified tape.
The erase function is generally invoked as a started task via the following command:
S CTTTPI,V=volser,[U=unitname|devnum],F=ERAS
where:
volser Volume serial number of the tape to be erased.
unitname Type of the unit in which the specified tape is loaded.
devnum Number of the device in which the specified tape is loaded.
This command invokes the utility with the following single control statement:
TAPERAS SER=volser,NUMBTAPE=999
When invoked in this manner, the utility first checks that the specified target volume
serial number is either not in the Media Database or is in the Media Database with scratch
status.
If the target volume serial number passes the first check, the utility requests that the
operator mount the physical volume. Once the volume is mounted, the utility reads it to
verify that it is not an active volume in the Media Database.
The mounted volume is erased only if the volser of the mounted volume matches the volser
specified in the JCL for the utility.
If the specified volser is numeric, the utility requests successive volumes in ascending
order until stopped or canceled by the operator.
The utility issues messages (e.g., CTT289A) and sometimes prompts the operator for a
reply or decision. If CONTROL-O or CONTROL-O/PC is installed at your site, responses to
these messages can usually be automated.
Depending on specified parameters, the Media Database can be updated by the utility.
CTTTPI and I/O Error Recovery
Because utility CTTTPI thoroughly examines magnetic tapes in unknown condition, it may
encounter more I/O errors than ordinary programs. In particular, CTTTPI encounters I/O
errors when reading a new tape to which data has never been written. While CTTTPI
handles most of these errors successfully, the user may observe pertinent error messages
originated by MVS. Normally these messages can be ignored. If automation procedures are
driven by these messages, you may want to make adjustments to exclude tape initialization
and media swapping jobs.
To minimize the overhead of I/O error recovery, CTTTPI turns off DDR/SWAP capability in
the allocated device for a short duration while it reads the label of a mounted tape to be
initialized. If CTTTPI is canceled during that short period, the device may be left in a state
where it is not a candidate for DDR/SWAP.
The operator can increase control over DDR/SWAP via MVS commands G OFF and G ON.
Note In some cases the I/O error encountered by CTTTPI is due to incompatible recording
formats of different device types. To avoid the destruction of media originally created
by another device, care should be exercised in handling the mounted volume, in
examining the I/O error messages on the console and in specifying the CTTTPI
protection parameters.
In particular, utility CTTTPI recognizes volumes which have never been accessed by the
occurrence of an I/O error when it reads the label. If a 3480 device attempts to read a
cartridge written by a 3490 device, an I/O error message is issued by MVS indicating
format incompatibility and the cartridge is treated by CTTTPI as a media to which data
has never been written. In some cases the cartridges can be overwritten by a 3480 device.
If your site has both media types and you want enhanced protection against the accidental
mounting of cartridges created by a 3490 device and their reinitialization by a 3480 device,
specify PROTECT=PROMPT.
The utility can be activated as a job, started task (STC) or program called from within
another program.
Parameters can be passed to the utility in either of the following ways:
Via the EXEC statement.
Via the SYSIN DD statement.
However, do not use both methods at the same time.
Passing Parameters via the EXEC Statement
When passing parameters via the EXEC statement, the statement format is:
// EXEC CTTTPI,V=volser,[U=unitname|devnum,]F=INIT|MAP|ERAS
where:
V Six-character volume serial number. Valid for INIT, MAP or ERAS functions. Optional.
F Function to be performed using default control statements. Valid functions:
INIT Initialize the tape (reel or cartridge). Create a volume label.
MAP Map the tape: Provide information about the contents of a reel or cartridge.
ERAS Erase the data on the tape. Write a random pattern from the beginning
until the physical end-of-tape.
U Tape drive to be allocated for use by the utility. Valid values are a generic or esoteric
unit name or a specific device number.
Passing Parameters via DD Statement SYSIN
When passing parameters via DD statement SYSIN, the syntax is:
// EXEC CTTTPI
//SYSIN DD *
TYPERUN [MODE=NORMAL|SIMULATION]
[,PROTECT=ALL|MDB|PROMPT|NOREAD]
[,MDBUPDAT=Y|N]
[,ADD=N|Y|E|P]
INITT SER=volser
[,DDNAME=ddname]
[,OWNER=owner]
[,NUMBTAPE=number]
[,LABTYPE=AL]
[,ACCESS=char]
[,ERASE=Y|N]
[,MEDIA=media-type]
[,VENDOR=vendor-name]
TAPEMAP SER=volser
[,DDNAME=ddname]
[,NUMERR=number]
[,STOP=Y|N]
[,MODE=S|E]
TAPERAS SER=volser,
[DDNAME=ddname]
[,NUMBTAPE=number]
[,ERASELBL=Y|N]
Input Parameters SYSIN DD File
Note Throughout the documentation, the term specified volser refers to the volume serial
number specified in parameter SER=volser. The term mounted volume refers to the
physical volume (and its label, if one exists) which was mounted with the intent of
writing a new volume label on it.
TYPERUN Provides general information effecting the remainder of the run.
Optional. Valid only for function INITT.
Only one TYPERUN statement can be specified in each run of
CTTTPI. When specified, it must be the first statement.
MODE Controls the operation of function INITT. Optional.
Valid values:
NORMAL The utility creates labels on the media
and performs other requested
functions. Default.
SIMULATION The utility only verifies that the
specified target volume either does not
appear in the Media Database or it
appears in the Media Database in
scratch status. The physical mounted
volume, however, is not read and not
initialized.
When this mode is used, mounting the
target volume is not required.
PROTECT Controls the protection of the physical mounted volume.
Optional. Valid only for function INITT. Valid values:
ALL Default. Protects all mounted
volumes, as follows:
Mounted volumes which are active
in the Media Database are rejected
without a prompt to the operator.
Mounted volumes which have
never been written to are accepted
without a prompt to the operator.
Note Media created on a 3490 may
be treated as empty by
CTTTPI. See CTTTPI and
I/O Error Recovery above for
more information.
Mounted SL volumes which are not
in the Media Database result in a
prompt to the operator.
NL volumes which contain data
result in a prompt to the operator.
A mounted SL scratch volume
whose volume serial number is the
same as the specified target volser
is accepted without a prompt to the
operator (reinitializing the existing
volume).
A mounted SL volume whose
volume serial number exists in the
Media Database in scratch status
but whose volume serial number is
not the same as the specified target
volser results in a prompt to the
operator.
MDB Protects mounted volumes only if they
are in the Media Database. The
mounted volume is protected in the
same manner as in PROTECT=ALL,
except that SL volumes which are not
in the Media Database are accepted
without a prompt.
NOREAD Mounted volumes are not read or
otherwise protected before writing a
new label on them.
Note Verification of the specified
target volume serial number is
still performed subject to other
parameters.
PROMPT Mounted volumes are read and the
operator is requested to approve the
initialization of the mounted volume.
MDBUPDAT Controls updates to the Media Database record of the
specified target volume. Optional. Valid for function
INITT only. Cannot be used in SIMULATION mode.
Valid values:
Y (Yes) Default. If the volume is already in
the Media Database, the information
in its record is reset, including volume
statistics and information regarding
scratch datasets which have resided
on the volume.
The value of the last job to access
the volume is changed to
*CTTTPI*.
If the volume is not in the Media
Database and ADD=Y is specified,
the volume record is added to the
Media Database.
N (No) No changes are made to the Media
Database as a result of the
initialization process.
If MDBUPDAT=N is specified,
parameter ADD is ignored.
ADD Controls the handling of specified volume serial
numbers which are not in the Media Database.
Optional. Valid for function INITT only. Cannot be used
in SIMULATION mode. Valid values:
N (No) A volume record is not added to the
Media Database. Default.
Y (Yes) A volume record is added to the Media
Database.
E (External) A volume record is added to the Media
Database and marked External.
P (Prompt) The operator is prompted to decide
whether or not to add a record to the
Media Database.
INITT Initialization function. Controls initialization (or initialization
simulation) of magnetic media volumes. Optional. If this control
statement is used, at least one optional subparameter must be
specified:
SER Volume serial number to be initialized (up to 6
alphanumeric characters). Mandatory.
This parameter is identical to parameter SER= in IBM
utility IEHINITT.
Note A volume serial number specified in // EXEC
CTTTPI,V=volser or passed to the program as
PARM=CTTTPIV=volser overrides this value.
NUMBTAPE Maximum number of tapes to be initialized. Optional.
After the first specified volume is processed, the
numeric suffix of the volume serial number (if one
exists) is repeatedly incremented by one to generate
additional serial numbers, until the number of tapes
initialized equals the value of NUMBTAPE or until a
volume is initialized with a volser whose suffix is all
9s. NUMBTAPE must be an integer between 1 and
9999. The default is 1.
OWNER Owner identification to be recorded on the volume label.
Maximum: 10 alphanumeric characters. (This
parameter is identical to parameter OWNER= in IBM
utility IEHINITT.) Optional.
LABTYPE Type of label to create. Optional. (This parameter is
identical to parameter LABTYPE= in IBM utility
IEHINITT.) If this parameter is omitted, an IBM
standard label is created. Otherwise, the following
value is valid:
AL Create an ANSI standard label.
ACCESS Protection character for ANSI standard label. (This
parameter is identical to parameter ACCESS= in IBM
utility IEHINITT.) Optional.
DDNAME DD name for the tape drive to be used by CTTTPI. The
ddname must start with the characters CTTTPI. The
default value is CTTTPITP. Optional.
MEDIA Volume media name to be recorded in the Media
Database for volumes being added to the Media
Database as part of the initialization process. The
media must be defined in member CTTPARM. If no
value is specified, the media name is derived from the
device type of the assigned tape drive (e.g.,
MEDIA=3480). Optional.
VENDOR Media vendor name to be recorded in the Media
Database for volumes being added to the Media
Database as part of the initialization process. Optional.
ERASE Indicates whether or not to erase all data on the tape
from after the label until the physical end-of-tape.
Y (Yes) Erase the data on the tape.
N (No) Do not erase the data on the tape.
Note Since the ERAS function physically writes a random
pattern of data until the physical end of the tape, a
run of utility CTTTPI in which ERASE=Y is
specified can be a time-consuming process.
TAPERAS Erase function. Controls erase (or erase simulation) of magnetic media
volumes. Optional. These subparameters are available for this function:
SER Volume serial number to be erased (up to 6
alphanumeric characters). Mandatory.
Note A volume serial number can also be specified:
// EXEC CTTTPI,V=volser
or it can be passed to the program as follows:
PARM=CTTTPIV=volser
which overrides the volser in the EXEC statement.
Both these statements override the value specified
via parameter SER.
NUMBTAPE Maximum number of tapes to be erased. Optional.
After the first specified volume is processed, the
numeric suffix of the volume serial number (if one
exists) is repeatedly incremented by one to generate
additional serial numbers, until the number of tapes
erased equals the value of NUMBTAPE or until a
volume is erased with a volser whose suffix is all 9s.
NUMBTAPE must be an integer between 1 and 9999.
The default is 1.
DDNAME DD name for the tape drive to be used by utility
CTTTPI. The ddname must start with the characters
CTTTPI. The default value is CTTTPITP. Optional.
ERASELBL Indicates whether or not to erase the label of the
volume. Optional.
Y (Yes) ERASE the label.
N (No) Keep the label. Default.
TAPEMAP Tape mapping function. Optional. If this parameter is used, at least
one optional subparameter must be specified:
SER Volume serial number to appear in the mount message.
This volume serial number does not have to match the
volume serial number recorded on the media. Optional.
DDNAME Name of the DD statement identifying the tape drive to
be used by CTTTPI. The ddname must start with
CTTTPI. The default value is CTTTPITP. Optional.
NUMERR Number of I/O errors (between 1 and 999) which will
cause utility CTTTPI to terminate. Default is 1.
Optional.
STOP Controls termination of the TAPEMAP function.
Optional.
Y (Yes) Default. The TAPEMAP function ends
when one of the following is
encountered:
Logical End-of-Volume as indicated
by:
Two consecutive tape marks, or
End-of-Volume label followed by
a tape mark.
The maximum number of I/O errors
permitted (specified in parameter
NUMERR=) has occurred.
N (No) Function TAPEMAP ends only when
canceled by the operator or when it
encounters an error it cannot ignore.
Note Processing a volume with STOP=N
may cause unexpected operational
problems, such as a tape running off
a reel or unusual I/O errors.
It is recommended that STOP=N be used only in a test
environment where unexpected problems will not
disrupt production.
MODE Controls both the extent of the report produced by the
TAPEMAP function and the way in which this function
reads the tape.
E (Extended) Produces a report on all datasets that
exist on the volume including datasets
that exist after the logical end of data
(see value N for subparameter STOP
above). When operating in this mode,
utility CTTTPI physically reads every
byte on the volume. This mode is
therefore time-consuming. Default.
S (Standard) Produces a report on all datasets that
exist on the volume up to the logical
end of data. The utility scans the
datasets on the volume, it does not
physically read the data. This mode is
therefore quicker than Extended
mode.
When MODE=S is specified, subparameter STOP is
ignored and field LARGEST BLOCK produced by utility
CTTTPI is set to zero.
Invoking CTTTPI From Another Program
When calling CTTTPI as a program from within another program:
Input parameters for CTTTPI should be passed only via DD statement SYSIN. Do not
specify input parameters in the JCL EXEC statement.
Linkage and parameter-passing conventions for utility CTTTPI are the same as for
IBM utilities (see the IBM Utilities Manual).
Utility CTTTPI supports substitution of DD names for its SYSIN and SYSPRINT
statements via the same parameters used by IBM utilities (see the IBM Utilities
Manual).
When constructing jobs which invoke CTTTPI, copy the DD statements from the CTTTPI
JCL procedure as follows:
SYSIN Input Stream.
SYSPRINT Output stream for CTTTPI. This DD statement must point to a
SYSOUT file or the results can be unpredictable.
DAMDB Media Database Data component.
DAMDI Media Database Index component.
DALOG IOA Log file.
DATRC CONTROL-T Trace file.
CTTTPITP Tape drive for tape initialization.
Activating Utility CTTTPI From the Software Component of a
StorageTek Robot
The initialization program of the StorageTek Host Software Component invokes a
site-specific media initialization program. To indicate that you wish to use utility CTTTPI
for volume initialization, follow the instructions above and the instructions for the
cartridge initialization utility in StorageTeks reference manual with the following
modifications.
1. Specify PROG(ctttpiname) to StorageTek utility SLUADMIN.
where:
ctttpiname is either CTTTPI or (if you renamed utility CTTTPI as described in the final
adjustments to CONTROL-T installation) IEHINITT.
2. Pass the CTTTPI input control statements to StorageTeks Host Software Component
via DD statement SLSINIT.
3. Specify ****** (six asterisks) for CTTTPI parameter SER.
See Example 2 (below) for a sample JCL which activates utility CTTTPI from StorageTeks
HSC Software component.
For more information about the CONTROL-T interface to StorageTek robots, see Section 8
of the CONTROL-T Implementation Guide.
Return Codes
Upon completion, CTTTPI returns one of the following return codes (in register 15):
0 Successful completion.
4 Operator requested termination by typing CANCEL in response to a
program prompt.
8 The specified target volume is a non-scratch volume in the Media
Database.
12 The Media Database could not be updated.
MDBUPDAT=Y was specified, but the specified target volume is not in
the Media Database and the volume could not be added (i.e., either
ADD=N was specified or the operator responded negatively to the ADD
prompt).
16 Syntax error in control statements or parameters.
20 IEHINITT (or the specified substitute) failed or was stopped by the
operator.
24 Error while opening the IOA Log file.
28 Error while loading IOA modules or tables.
32 Unable to open DD file CTTTPIxx for accessing a tape drive.
36 Unable to open DD file SYSPRINT or its replacement.
40 Unable to open DD file SYSIN or its replacement.
44 Error while accessing the Media Database.
48 Erase of INITT failed.
52 TAPERASE command failed.
56 TAPEMAP EXCP command failed.
60 INITT command failed.
64 CTTRBD robot interface load failed.
68 Unable to change a volume status to active in a 3495 silo.
72 Unable to scratch a volume in a 3495 silo.
Example 1
Below is a sample of TAPEMAP output with STOP=N.
15.33.04 CTT704I CONTROL-T UTILITY CTTTPI STARTED
15.33.04 CTT700I TAPEMAP SER=CTTMAP,STOP=N
VOL1 V=V00001
HDR1 DSN=...NOPOOL.F.G0028V00 FIRST=V00100 VOLSEQ=0002
FILESEQ=0002 CREDT=94346
HDR2 CREAT-JOB=N77MUL01 BLKSZ=00080 LRECL=00080
RECFM=F
TAPE-MARK ---------
DATA BLOCKS: COUNT=00000005 LARGEST-BLKSZ=00080 LOGICAL-FILE
-SEQ=0002 PHYSICAL-FILE-SEQ=00002
TAPE-MARK ---------
EOF1 DSN=...NOPOOL.F.G0028V00
EOF2
TAPE-MARK ---------
TAPE-MARK --------- **** LOGICAL END OF RECORDED AREA ****
IO-ERROR *********
DATA BLOCKS: COUNT=00000051 LARGEST-BLKSZ=03120 LOGICAL-FILE
-SEQ=PHYSICAL-FILE-SEQ=00005
TAPE-MARK ---------
EOF1 DSN=NNN.TSC1
EOF2
TAPE-MARK ---------
TAPE-MARK ---------
. . .
Example 2
The following sample JCL demonstrates how to use utility CTTTPI to initialize tapes in a
StorageTek robot silo, from another program:
//INITAPE JOB ,USER,MSGCLASS=X,CLASS=A
//INITT EXEC PGM=SLUADMIN,PARM=MIXED
//STEPLIB DD DISP=SHR,DSN=SYS3.HSC HCS LOADLIB
// DD DISP=SHR,DSN=SYS2.IOA.LOAD CTT LOADLIB
//SLSTAPE DD DISP=NEW,UNIT=(3480,,DEFER) <=== UPDATE UNIT
//SLSIN DD *
INITIALIZE CAP(000:00) PROG(CTTTPI) OPT(SCR) CNTLDD(SYSIN)
//SLSINIT DD *
INITT OWNER=ABCD,SER=******
//*
//SLSPRINT DD SYSOUT=* SLUADMIN MSGS
//SYSPRINT DD SYSOUT=* CTTPI MSGS
//SYSIN DD UNIT=DISK,SPACE=(TRK,1) CTTTPI SYSIN
//CTTTPITP DD UNIT=AFF=SLSTAPE,DISP=NEW UNIT=AFF=SLSTAPE
//DAMDB DD DISP=SHR,DSN=SYS2.CTT.MDBD <=== UPDATE CTT MDBD
//DAMDI DD DISP=SHR,DSN=SYS2.CTT.MDBI <=== UPDATE CTT MDBI
//DATRC DD DISP=SHR,DSN=SYS2.CTT.TRC <=== UPDATE CTT TRC
//DALOG DD DISP=SHR,DSN=SYS2.CTT.LOG <=== UPDATE CTT LOG
CTTTRB Synchronize Trace File and Media Database
Backup
This utility marks records in the Trace file that are no longer needed, so that they can be
overwritten. This utility should be run immediately before and after each backup of the
Media Database and the Trace file.
The Trace file is used primarily to trace actions performed on the Media Database. When
the Trace file becomes full, all CONTROL-T functioning is halted and an appropriate
message is issued. This situation can be avoided by running utility CTTTRB on a regular
basis. This utility is called by the CONTROL-T New Day procedure before and after the
daily backup of the Media Database and the Trace file.
// EXEC CTTTRB,PARM=BKP=START|END
Parameters
Utility parameters are supplied via JCL PARM:
BKP Indicates if the Backup procedure is beginning or ending.
START Backup procedure of Media Database has started.
END Backup procedure of Media Database has ended.
The steps for implementing utility CTTTRB are as follows:
1. Run the utility before backup of the Media Database and the Trace file. In this run
BKP=START must be specified. This run of the utility marks the most recently filled
record in the Trace file.
2. Perform the necessary backups. Any local site backup procedures can be used to
perform this task.
3. After the backup has been successfully completed, run utility CTTTRB with BKP=END
specified. This run marks all Trace file records before the record marked in the
previous run of the utility (Step 1 above).
Return Codes
8 DCB open error occurred, TCT load failed or PARM error.
12 I/O error on Trace file occurred.
Example
// EXEC CTTTRB,PARM=BKP=START
// EXEC PGM=IEBGENER
...
// EXEC CTTTRB,PARM=BKP=END
CTTVTM Perform Vault Management
This utility performs vault management functions. This utility should be run on a regular
basis via job CTTDAY.
The utility checks each volume records vault specifications in the Media Database and
determines which volumes should be moved to a new location according to their vault
patterns. The current volume location in the volume record is updated.
This utility can produce a distribution report at the end of processing, which lists all
volumes which should be moved to a new location or assigned a new slot number.
Notes Inventory report INVENT is no longer produced by utility CTTVTM. Instead, this
report can be produced as part of the GENERAL report by utility CTTRPT. For more
information see the description of utility CTTRPT earlier in this section.
Utility CTTVTM requires exclusive access to the Media Database. Real-time jobs which
access tapes can be run at the same time as utility CTTVTM, However, other utilities
which access the Media Database (e.g., CTTRTM or CTTIDB) will not be allowed to
run concurrently with this utility.
Since the utility handles a large number of Media Database records, a CANCEL operation,
job abend or system crash can lead to logical inconsistencies in the database. After any of
these situations, the next execution of the utility will automatically operate in Restart
mode. In Restart mode, the utility will complete execution of the failed process, thereby
eliminating the logical errors from the Media Database. The utility does not move any
additional volumes during Restart execution.
Certain installation parameters (specified in member CTTPARM) determine how utility
CTTVTM operates. These parameters are described below.
VLTBYDS1 Specifies which dataset can determine how the vaulting pattern of a
volume is chosen. Valid values:
Y (Yes) Only the first dataset of the volume determines the
vaulting pattern for the volume. This improves
performance of CTTVTM (and is compatible with other
tape management systems vaulting methods). Default.
N (No) Any dataset can determine the vaulting pattern for the
volume.
CYCLECNT Defines how to handle cyclic datasets.
For additional information refer to Retention and Vault Parameters in the IOA
Installation Guide.
// EXEC CTTVTM
//SYSIN DD *
TYPERUN MODE=NORMAL|SIMULATION[,DATE=date][,TRACE=YES|NO][BOXLIM=num]
TYPEVLT MODE=REGULAR|RECALC|CONVERT|SLOTBLD|BOXBLD[,RESLOT=YES|NO]
REPORT NAME=DISTRIB,...
FIELDS...
SORTBY...
ATTR ...
BREAK ...
//
Parameters
TYPERUN Operation type.
NORMAL Normal operation is performed.
SIMULATION Simulation is performed. No actual
changes are made to the Media
Database.
DATE Operation date in 6- or 8-character format according to
site standard with separating slashes. (For example,
the date in MDY format can be specified mm/dd/yy or
mm/dd/yyyy.) Optional.
The utility assumes that the specified date is the
current date and performs vaulting accordingly. This
parameter can be used together with
MODE=SIMULATE (described above) to simulate
vaulting to be done on a specific date in the future.
TRACE Specifies whether or not the Trace file is used during
the CTTVTM run. Optional.
YES The Trace file is used. Default.
NO The Trace file is not used. If NO is
specified, recovery of the lost updates
to the Media Database will be
impossible. TRACE=NO is specified
for the run of this utility during
conversion from another product, but
is not otherwise recommended.
RESTART Specifies whether or not to enable Automatic Restart mode
when the utility is run after an abend or cancellation of
the previous run of the utility. Valid values:
YES Enable Automatic Restart mode.
Default.
NO Disable Automatic Restart mode. It is
highly recommended not to specify
RESTART=NO, as this can result in
integrity errors in the Media Database
and loss of important information.
BOXLIM Minimum number of volumes a box can contain. If the
number of volumes is below the minimum, the volumes
are placed in a slot instead of a box. Default is 1.
TYPEVLT Vault management type. Optional if parameter REPORT is specified.
If TYPEVLT is not specified, vault processing is not performed but
reports are produced.
MODE Vault management mode.
REGULAR Vault management is performed
according to the vault patterns
currently specified for the volumes (in
Media Database volume records).
RECALC Rule definitions are reloaded and the
vault pattern of each volume is
recalculated.
CONVERT This parameter is used following
conversion from another tape
management system. Rule definitions
are reloaded, the vault pattern for
each volume is calculated and the
current location of each volume is
reserved within the vault pattern.
SLOTBLD The slot map is built in the Media
Database. This mode cannot be
specified if RESLOT=YES.
BOXBLD Box records are built in the Media
Database from the vault definition
and volume records. This mode cannot
be specified if RESLOT=YES.
Note Basic Scheduling parameters are checked when
rules are loaded and not when datasets are
created or retention information is updated or
extracted. Therefore, when running utility
CTTVTM in RECALC or CONVERT mode, the
rules applied may differ from the rules normally
applied at dataset creation. For more
information, see Basic Scheduling Parameters
in Section 2 of the CONTROL-T User Manual.
RESLOT Specifies whether or not to reassign slot numbers to
vaulted volumes. Optional.
Y (Yes) New slot numbers will be assigned.
N (No) Existing slot numbers will be
preserved. Default.
INCLUDE/EXCLUDE
EXCLUDE statements. INCLUDE/EXCLUDE statements are specified
immediately after the TYPEVLT parameter and are applied to vault
processing. The subparameters which can be specified in
INCLUDE/EXCLUDE statements are listed in Tables 1 and 2 in
Logical Field Names for the CONTROL-T Repository in Appendix D.
Note As of CONTROL-T Release 2.1.0, INCLUDE/ EXCLUDE
statements cannot be specified after SORTBY parameters.
For additional information on INCLUDE and EXCLUDE statements,
see Record Selection Logic (INCLUDE/EXCLUDE Statements)
Note With few exceptions, the parameters and options of the REPORT,
FIELDS, SORTBY, ATTR and BREAK statements are identical
to those found in utility CTTRPT. For a complete description of
these parameters and options, see utility CTTRPT earlier in this
section. Differences between utility CTTVTM and utility
CTTRPT, in those parameters and options, are described below.
REPORT Activates report utility. Optional if parameter TYPEVLT is specified.
NAME Report name. Mandatory. Valid value is:
DISTRIB Distribution Report listing volumes which need to
change location as a result of this utility run.
Notes Inventory report INVENT is no longer produced
by utility CTTVTM. Instead, this report can be
produced as part of the GENERAL report by
utility CTTRPT. A sample Inventory report can be
found in member REPINV in the CONTROL-T
JCL library.
See the REPORT statement in utility CTTRPT
(earlier in this section) for a description of the other
parameters and options of the REPORT statement.
FIELDS Fields to print in the report. The fields are printed in the order they
are specified.
The following fields can be printed on the Distribution report:
MEDIA Media type.
POOL Pool name.
VOLSTAT Status(es) of the volume.
SL-NAME Standard label name of the volume.
VOLCNT Number of volumes in a multi-volume chain.
FIRSTVOL First volser in a multi-volume chain.
FROMLOC From vault location of the volume.
TOLOC To vault location of the volume.
FROMSLOT From slot number in the vault.
TOSLOT To slot number in the vault.
NEXTLOC Next location in the vault pattern.
NEXTLCDT Date the volume should be moved to the next location in
the vault pattern.
BOXID Name of the box in which the volume resides.
EXPDT Expiration date.
LBLTYP Label type.
VOLSEQ Volume sequence number.
LOCSEQ Sequence number of the location in the vault pattern.
CREJBN Creating jobs name.
CREDT Creation date.
CRETM Creation time.
Note See the FIELDS statement in utility CTTRPT (earlier in this
section) for a description of the options of the FIELDS statement.
SORTBY Sort order of the output fields (see FIELDS above) with the options
that can be applied to each field. Optional.
Note See the SORTBY statement in utility CTTRPT (earlier in this
section) for a description of the parameters and options of the
SORTBY statement.
Optional.
Note See the ATTR statement in utility CTTRPT (earlier in this
section) for a description of the parameters of the ATTR
statement.
occurs. Optional.
Note See the BREAK statement in utility CTTRPT (earlier in this
section) for a description of the parameters of the BREAK
statement.
Return Codes
4 Minor errors detected. See accompanying messages for more information.
8 Major errors detected. See accompanying messages for more information.
16 Load of CONTROL-T programs failed.
36 Rule/vault/pool load failed.
44 Authorization failed.
48 Media Database in use by another utility.
52 Missing DD statement or Open failed.
56 Missing box definition record.
Example 1
Vault management is performed according to the current vault pattern specifications in
the Media Database. Report DISTRIB is printed, listing the MEDIA, VOLSER, VOLSEQ,
FROMLOC and TOLOC fields.
// EXEC CTTVTM
//SYSIN DD *
TYPERUN MODE=NORMAL
TYPEVLT MODE=REGULAR
REPORT NAME=DISTRIB
FIELDS MEDIA,VOLSER,VOLSEQ,FROMLOC,TOLOC
SORTBY FROMLOC/B,TOLOC,VOLSER
//
The report is sorted according to the location from which each volume is being moved
(FROMLOC). The report is then sorted according to the destination (TOLOC) and the
volser name (VOLSER). A page break is inserted after each FROMLOC location listed in
the report (i.e., each group of volumes from a specific location will start on a new page).
Example 2
The location of all volumes whose volume serial numbers start with DIV1 is modified. The
volumes are assigned new slot numbers. Rule definitions are reloaded to recalculate the
vaulting patterns.
// EXEC CTTVTM
//SYSIN DD*
TYPERUN MODE=NORMAL
TYPEVLT MODE=RECALC,RESLOT=YES
INCLUDE VOLSER=DIV1*
REPORT NAME=DISTRIB
FIELDS MEDIA,VOLSER,POOL,FROMLOC,TOLOC
SORTBY FROMLOC/B,VOLSER,POOL
//
Section 10: Exits
General ........................................................................................................................................ 10-1
USERMODs ..............................................................................................................................10-1
USERMOD Installation Jobs..............................................................................................10-1
Definitions............................................................................................................................10-2
ID Check ..............................................................................................................................10-3
Element Status NOT SEL During APPLY ........................................................................10-3
Link-edit Updates................................................................................................................10-3
Including Local CSECTs in IOA Exits...............................................................................10-4
Summary USERMOD Jobs..............................................................................................10-4
IOA Exits ..................................................................................................................................... 10-5
CONTROL-M Exits.................................................................................................................... 10-9
CMEM Exits ......................................................................................................................10-11
CONTROL-R Exits................................................................................................................... 10-12
CONTROL-D/V Exits............................................................................................................... 10-14
Replacing CONTROL-D User Exits ......................................................................................10-20
Tailoring CONTROL-D Banner Exit.....................................................................................10-21
General...............................................................................................................................10-21
Banner Pages..........................................................................................................................10-21
Format of Banner Pages ...................................................................................................10-22
Printing User Address in Bundle Banner........................................................................10-24
Eliminate Banners ............................................................................................................10-25
INDEX Printing Control ...................................................................................................10-25
Banner Printing Options...................................................................................................10-26
OUTPARM Options...........................................................................................................10-27
AFP (APA) Support ...........................................................................................................10-27
XEROX (DJDE) Support...................................................................................................10-27
Summary............................................................................................................................10-27
CONTROL-B Exits................................................................................................................... 10-28
CONTROL-T Exits................................................................................................................... 10-29
CONTROL-O Exits................................................................................................................... 10-31
Section 10: Exits
General
Various user exits are provided to enable you to modify the operation of IOA products to
suit your sites needs. These exits are contained in members of the IOA SECUDATA
library. These members have names in the format IOAXnnn or CTxXnnn, where x
indicates the IOA product and nnn is the exit number.
Note Some special exits are also provided. Special exits are identified by an additional
character at the end of the member name (e.g., IOAX006D).
A full explanation of how to use exit is contained in members which have names in the
format DOCIXnnn. For example, the explanation for exit IOAX006 is contained in member
DOCIX006 in the IOA SECUDATA library.
The documentation in this section assumes that the reader has a general knowledge of
SMP/E.
USERMODs
These exits are installed using SMP/E USERMODs. USERMODs for the standard exits
and for the special exits are also contained in members of the IOA SECUDATA library.
These members have names in the format UMxXnnn[a], where x indicates the IOA
product, nnn is the exit number, and a is an [optional] additional character. For example,
the USERMOD for exit CTDX015V is in member UMDX015V.
The USERMODs in the SECUDATA library should be modified and tailored for local needs
according to the recommendations below and the explanations contained in each
USERMOD.
Before you modify a USERMOD, backup that USERMOD. Then edit that USERMOD to fit
your requirements.
Note New Dimension Software does not undertake to provide USERMODs for all special or
customized exits.
USERMOD Installation Jobs
USERMOD installation jobs often need to be submitted more than once. Therefore, each
job contains an SMP/E reject command to delete the previous copy of the USERMOD from
the SMPPTS dataset and the SMP/E global zone.
Note The first time each USERMOD job is submitted, it will terminate with a return code of
12. This return code is expected because there is nothing to reject.
In order to avoid interrupting of the SMP/E command stream after receiving a return code
of 12, the installation job contains an SMP/E RESETRC command after the reject.
Note Never ACCEPT a USERMOD.
Section 10: Exits
Definitions
The following terms are used in describing these topics:
FMID Function Modification ID. This is the ID of the base function that owns a
particular element (usually source elements of type ++SRC).
RMID Replacement Modification ID. This is the ID of the last SYSMOD (function,
PTF, USERMOD, etc.) that replaced this element.
1. Check the FMID and RMID of the source in SMP online (option 3.2, element type is
SRC, element name is the name of the source being replaced).
Note If the element name specified in the ++SRC statement is not known to SMP/E,
check the FMID of a sample (element type: SAMP) with the same name and use its
FMID and RMID values as the values for FMID and RMID for ++SRC in the
following steps.
The next two steps apply only to the main USERMOD in the USERMOD member.
Language USERMODs should normally not be changed. The line to be changed has the
format:
++VER(I500) FMID(FMID-VALUE) /* PRE(RMID-VALUE) */
2. Set the FMID in the USERMOD that is to be applied to the same value as the FMID
currently owning the source element (i.e., the value obtained in step 1 above).
3. If the RMID is not the same as the FMID or the same as the USERMOD-ID, then
uncomment the PRE(RMID-VALUE), if applicable, in the ++VER line and set the
RMID to the RMID-VALUE obtained in step 1 above.
Example
If running job UMDX006 to apply USERMOD CTDX006 to install source CTDX006 (see
member UMDX006), then:
1. Check the FMID and RMID for element type SRC, element name CTDX006. (In this
example, assume the values found for this element are FMID=IOA5140,
RMID=FI09876.)
2. If necessary, change the value of the FMID operand in the ++VER statement so that it
is the same as that of the SRC CTDX006 determined in step 1.
3. If the RMID of CTDX006 is not the same as the FMID (true in this case), add
PRE(FI09876) to the ++VER statement as follows:
++VER(I500) FMID(IOA5140) PRE(FI09876)
If the APPLY has already been run, it can be run again after modifying the ++VER
statement.
If the above steps are not performed correctly, the problems described below may occur.
Section 10: Exits
ID Check
If the RMID of the element to be installed is not the same as its FMID value, then a
PRE(RMID-value) must be added to the ++VER statement in the USERMOD (as
described above), otherwise the APPLY will fail due to an ID-check.
Element Status NOT SEL During APPLY
The USERMOD has an FMID (in the ++VER statement). The element being installed via
this USERMOD is also associated with an FMID. These FMID values must be identical. If
they are not identical, the following will occur:
The fix will be reported as APPLYed successfully,
The job will complete with a return code of 04, but the element will not be installed.
This situation is unacceptable and the user must be aware of it. In order to determine if
this situation occurred, review the SMPRPT file of the sysout of the APPLY (CHECK) job.
This file contains a report titled Element Summary Report for APPLY Processing. In this
report, check the status of the element installed. If the status is APPLIED then it is OK.
However, if the status is NOT SEL, then the problem described above was encountered
and the steps listed above must be taken. It is recommended that these steps be performed
before submitting an APPLY (CHECK) job, and the checks described above be performed to
make sure the job ran OK.
Link-edit Updates
Link-editing is performed by SMP/E. Therefore, to change the link-edit statements in a
load-module, SMP/E must be informed via JCLIN. JCLIN is also applied via an SMP/E
USERMOD.
If JCLIN is installed without any element (SRC source or MOD module), SMP/E is
updated with link-edit statement changes, but no link-edit is performed. The new link-edit
statements are used only when SMP/E is requested to change the load-module because an
element is being updated or replaced. To ensure that the new link-edit statements are
used, an element is provided with the USERMOD containing JCLIN.
Section 10: Exits
Including Local CSECTs in IOA Exits
If a local CSECT is included in an IOA exit, the following steps must be followed:
1. Add INCLUDE AIOALOAD(LOCAL-CSECT-NAME) after the last include statement.
2. Add ++SRC(CSECT-NAME) or ++MOD(CSECT-NAME) after the DD statement of the
last source (++SRC) or last module (++MOD) in the USERMOD updated, as follows:
++SRC(EXITXXX) SYSLIB(SECUDATA) DISTLIB(ASECUDAT) ORIGINAL-LINE
DISTMOD(AIOALOAD). ORIGINAL-LINE
/* ORIGINAL-LINE
// DD DISP=SHR, ORIGINAL-LINE
// DSN=%ILPREFA%.SECUDATA(EXITXXX) ORIGINAL-LINE
// DD * ADDED-LINE
++SRC(LOCAL-CSECT) SYSLIB(SECUDATA) DISTLIB(ASECUDAT) ADDED-LINE
DISTMOD(AIOALOAD). ADDED-LINE
/* ADDED-LINE
// DD DISP=SHR, ADDED-LINE
// DSN=LIBRARY-CONTAINING-THE-ELEMENT(LOCAL-CSECT) ADDED-LINE
Summary USERMOD Jobs
Before submitting the USERMOD jobs, follow these steps:
1. Verify that a backup of the LOAD library exists.
2. Make all necessary updates to the USERMOD:
Update the PRE operand of the +++VER MCS of the USERMOD to include the exit
SRC entry RMID and UMIDs as described above. If the exit has no UMIDs and the
RMID is equal to the FMID, the PRE operand should be omitted.
Update the JCLIN (link-edit input statements) if required.
Update the source exit name in the SMP/E ++SRC statement, if necessary.
Update the library and member names of the source exit in the IOA SECUDATA
library on the unnamed DD statement following the ++SRC statement.
3. Submit the job. It will perform SMP/E RECEIVE and APPLY commands, selecting the
SMP/E USERMOD just created. Do not run ACCEPT on this USERMOD.
Section 10: Exits
IOA Exits
The following IOA exits are available:
IOAX006 This exit controls the use of the IOA Online facility.
IOAX006 and IOAX009 are twin exits. IOAX006 is invoked by the
Online facility before the entry panel is displayed. When signing on to
the Online facility through the online monitor, exit IOAX009 is
invoked first, followed by exit IOAX006). When the Online facility is
used without the online monitor, only exit IOAX006 is invoked). These
exits can be used to display a sign-on window for users to enter their
user ID and password.
These sign-on modules determine and build the users identity for all
subsequent actions. They both have similar structure, parameters,
return codes and functionality. However, they work in different
address spaces. The home address space is the primary address space
requesting and receiving services from the online monitor address
space using the cross-memory facilities. Exit IOAX006 is invoked in
the online monitor address space (when signing on through the online
monitor). Exit IOAX009 is invoked in the home address space for the
VTAM monitor, CICS, IMS, CA-ROSCOE, etc. The control block that
represents the users identity accompanies the user during the entire
session with the IOA Online services facility.
In the online monitor environment, the ACEE control block is stored
in the users TCB (Task Control Block) and the OCT (Online Control
Table). MVS recognizes the ACEE as a standard control block to be
used for authorization checks, so that task level security feature is
achieved. If the ACEE is not stored in the TCB, either because module
IOASE06 is not implemented or because the security package does not
build an ACEE (e.g., ACF2 in native mode), then all authorization
checks for file access are performed using the identity of the online
monitor address space. All authorization checks are performed using
the correct users ACEE. If the ACEE is not built, it is quite likely that
the security interface will not perform the authorization checks
correctly.
MVS checks authorization for actions such as opening files by first
checking if there is an ACEE in the current TCB. If it is found,
authorization checks are performed using the TCBs ACEE. If it is not
found, MVS continues to search for the appropriate TCB until the
ACEE associated with the address space is found.
In an environment where security is not implemented, exits IOAX006
and IOAX009 can set the OCTUSER parameter, which is the reference
parameter for all programs used as the identity of the current working
user ID.
Section 10: Exits
When using the Online facility under CA-ROSCOE, the IOA security
interface receives the CA-ROSCOE started task procedure and not the
users own user ID. Therefore the user must sign on both under
ROSCOE and under IOA. To avoid forcing the user to sign on twice,
special routine IOARROT is provided in the IOA SECUDATA library.
This routine retrieves the user ID from the corresponding
CA-ROSCOE control block and places it in IOA so that it can be used
for additional security authorizations. Routine IOARROT should be
called from within the IOA Online environment, before calling the
standard IOA security modules. This call should be placed in an IOA
user module that is invoked before module IOASE06 and IOASE09 are
called. The user modules that support CA-ROSCOE for IOA Online
facility communication are IOAX006T and IOAX009. These modules
reside in the IOA SECUDATA library.
User exit IOAX006T should be called when all IOA functions are
performed under native CA-ROSCOE address space.
See members DOCIX006 and DOCIX009 in the IOA SECUDATA
library for more information about these exits.
Note When two environments run simultaneously, both user modules are placed in the
IOA LOAD library. User exit IOAX006T is invoked in the online monitor address
space as well, but cannot locate the required control blocks because there are no
CA-ROSCOE control blocks in the online monitor address space. The started session
abends. It is recommended that these two modules be placed in the special IOA
LOAD library which is concatenated to the STEPLIB in the CA-ROSCOE started
task procedure before the IOA LOAD library.
IOAX007 This exit can be used to control update of the IOA
Conditions/Resources file. For further details, refer to the IOA
Security Guide.
See member DOCIX007 in the IOA SECUDATA library for more
information about this exit.
IOAX009 This exit controls entry to the IOA Online facility when working with
the Online monitor (under CICS, VTAM, IMS/DC, TSO/ROSCOE cross
memory options, COM-PLETE and IDMS/DC).
User exit IOAX009T should be called when CA-ROSCOE
communicates with IOA through cross-memory services. All IOA
functions are performed in the separate address space, which is the
IOA Online monitor address space (OMON1).
In an environment where security is not implemented, exits IOAX006
and IOAX009 can set a value for parameter OCTUSER, which is used
by all programs as the identity of the current user ID.
See member DOCIX009 in the IOA SECUDATA library and the
description of exit IOAX006 above.
Section 10: Exits
IOAX012 This exit can be used to control or modify operator commands issued
by utilities CTMOPR, CTDOPR and IOAOPR, by CONTROL-O and by
the CONTROL-M and CONTROL-D/V New Day procedures.
IOAX016 Mainframe application server exit. This exit is called when a logon
request is made by CONTROL-D Page On Demand. The mainframe
logon user ID and password from the CONTROL-D/PC
Communication Setup menu are passed to the exit. This exit is
provided as a dummy load module. For more information, see member
DOCIX016 in the IOA SECUDATA library. The associated security
module is IOASE016.
IOAX028 IOA definition screen exit. This exit is invoked each time the user
presses the <ENTER> or PF3 key to exit an IOA definition screen.
This exit is relevant for all IOA definition screens (screens 2, 8, R, M,
TR, TV, TP, BM, BR OR and C).
IOAX029 IOA Online Sysout/Report Viewing exit. This exit is activated as part
of the Online viewing facility invoked for each sysout/report line which
is to be displayed on the user terminal. For example, this exit allows
translation of unprintable characters. This exit also provides
additional features (e.g., making special data invisible on the report).
IOAX031 IOA Log exit. This exit is invoked before a message is written to the
IOA Log file. The exit can be used to write the message on other files
(SMF, etc.) or to accumulate message statistics.
IOAX032 This exit is invoked in all IOA panels each time an IOA user attempts
to perform an operation on a PDS library or member in a PDS library.
This exit can deny operations such as accessing a library, listing its
directory and browsing, editing or saving a member. The exit is
invoked when a user requests to edit JCL members or documentation
data through Enterprise Controlstation. The exit checks authorization
and either grants or denies the Edit (or Save) request prior to the
performance of these operations by the MVS Gateway for Enterprise
Controlstation (ECSGATE).
IOAX034 Receives control for every message issued by the IOA Shout facility.
This exit can modify the message text, change its destination, or
suppress it. This exit can be activated by either the CONTROL-O
monitor or an IOA Functional monitor (used with CONTROL-T).
Section 10: Exits
IOAX035 IOA Account Information Extraction exit. This exit is invoked by an
IOA product whenever account field information is required. Exit
IOAX035 can extract the requested information from different parts of
the account field depending on site customization. The exit can be
invoked by CDAM when writing directly to a CDAM file, by
CONTROL-D when decollating from a spooler by CONTROL-T when a
jobs account field is copied to the Media Database, etc.
IOAX036 IOA Access Method (IOAAM) exit. This exit is invoked whenever
program IOADBF is executed, both as an independent utility program
and when called internally by IOA Access Method I/O routines. This
exit can check for which function it is being called and either grant or
deny the request.
IOAX037 IOA translation exit. This exit contains four 256-byte translation
tables for the IOA online routines. This exit can be used to translate
IOA screens to any language supported at the site. In addition, it can
implement upper casing, special characters sets and other capabilities.
IOAX038 IOA Functional monitor exit. This exit is invoked before writing a
request to the Functional monitor queue. The return code of the exit
determines whether the request will or will not be written. For
performance reasons, exit IOAX038 in the IOA LOAD library is a
dummy exit.
IOAX039 IOA Page Separating Exit. This exit is invoked during the creation of
a CDAM file by a CONTROL-D decollating mission or during direct
writing to a CDAM file by a job. The exit can control page separation
in a CDAM file being created.
Section 10: Exits
CONTROL-M Exits
The following CONTROL-M exits are available:
CTMX001 This exit is invoked for every job order which should be placed in the
Active Jobs file. The exit is usually used to modify job production
parameters. This exit has an associated security module CTMSE01.
For further details, refer to the IOA Security Guide.
See member DOCMX001 in the IOA SECUDATA library for more
information about this exit
CTMX002 CONTROL-M submission exit. Every line of the job stream submitted
by CONTROL-M can be modified/deleted/replaced, etc. For example,
this exit can be used for adding /*PRIORITY 15 for every production
job. This exit has an associated security module CTMSE02. For
further details, refer to the IOA Security Guide.
CTMX003 CONTROL-M sysout scan exit. After the job finishes executing, every
line of the jobs SYSDATA
1
is passed to the exit. The main use of this
exit is to detect user generated constants in the sysout (such as
program DISPLAY messages)and to affect the execution results of the
current job accordingly.
CTMX004 This exit allows the user to change the defaults of the CONTROL-M
scheduling algorithm by assigning weights to quantitative resources.
In this way, CONTROL-M can be fine-tuned to achieve maximum
throughput.
CTMX005 Exit CTMX005 is an integral part of the statistical data accumulation
process. It is invoked by utility CTMJSA. which accumulates job
statistical data from the IOA Log file. The exit can be used for the
following purposes:
By default the machine ID (one-character) is automatically derived
from the SYSID (four-character) and from information contained in
CTMPARM, before exit CTMX005 is invoked. Exit CTMX005 can
override the machine ID.
Exit CTMX005 enables the user to incorporate additional statistical
data from sources other than the IOA Log (e.g., performance
monitors) into the job execution statistics.
1
SYSDATA is an IOA term used to designate the data in the following three job SYSOUT datasets:
job log (console messages), expanded JCLand system output messages.
Section 10: Exits
CTMX008 This exit is used to control access to the Active Jobs file. This exit has
an associated security module CTMSE08. For further details, refer to
the IOA Security Guide.
Exit CTMX008 and security module CTMSE08 are also invoked by the
MVS Gateway for Enterprise Controlstation.
CTMX010 This exit is used to control job submission via the Quick Submit
facility. For example, it can force the use of CONTROL-M for
production job submissions under TSO.
CTMX011 This exit is invoked for every message issued by the CONTROL-M
Shout facility. It can modify the message text, change its destination
or suppress it. It can also be used for special purposes, such as an
interface to InfoMan or to Electronic Mail Systems.
CTMX013 This exit is invoked each time a line is displayed by the CONTROL-M
Online facility in the Job Statistics screen (3.S). The exit can modify
the line to be displayed.
CTMX014 This exit is invoked when a request is made to ISPF-edit a JCL
member under screen 2 and screen 3 of the Online facility.
CTMX015 This exit is invoked when a job has finished executing and has been
assigned a CONTROL-M termination status.
CTMX016 This exit is invoked when a job has been submitted and needs to be
tracked. When multiple monitors are used, the exit can be direct job
tracking to a specific monitor.
CTMX017 The exit receives control each time the Tape Pull list utility
(CTMTAPUL) attempts to resolve volumes for each DD statement of
the job.
Section 10: Exits
CTMX018 This exit receives control during the process of determining the
anticipated elapse time of a job.
CTMX019 This exit receives control during the CONTROL-M external writer
initialization phase.
CMEM Exits
The CONTROL-M Event Manager (CMEM) can also use the following CONTROL-O exits:
CTOX001 Receives control under the Online interface whenever a rule
ORDER/FORCE is performed.
See member DOCOX001 in the IOA SECUDATA library for more
CTOX002 Receives control for every rule before it is loaded to the active
environment. This exit can be used to modify rule parameters prior to
rule loading.
Section 10: Exits
CONTROL-R Exits
The following CONTROL-R exits are available:
CTRX001 This exit can be activated by CONTROL-R. It allows better control of
CONTROL-R execution and can be used to interface with other
products (e.g., for checking non-standard datasets).
Sample exit CTRX001T can be used as an interface to a tape
management system in order to extend CONTROL-Rs processing.
When used as an interface with CONTROL-T, this exit receives
dataset DELETE requests and changes the CONTROL-T controlled
dataset status to Immediate-Scratch (the default) or Deferred-Scratch
(if specified). Datasets with a status of Deferred-Scratch will be
expired by the next run of CONTROL-T Retention Management utility
CTTRTM. By default, this exit causes CONTROL-T controlled datasets
to be scratched immediately (i.e., without running utility CTTRTM).
For more information see CONTROL-R Interface to CONTROL-T in
Section 3 of this guide and CONTROL-R and Tape Management
Systems in the CONTROL-R User Manual.
See member DOCRX001 in the IOA SECUDATA library for more
CTRX001G This exit is called a roof exit or driver exit because it can be used to
activate as many as nine other CONTROL-R sample exits. Each
sample exit activates a different function. The driver exit calls each
sample exit in turn.
For example, exit CTRX001G can be used to activate two tape
management products: CA-1 and CONTROL-T. The instructions below
can be expanded to create a driver exit for more than two functions.
Example: How to Design a Driver Exit
1. Check the CTRX001x sample exits in the SECUDATA library for
those which activate CONTROL-T and CA-1. Note the last
character of each samples name. If, for example, CONTROL-T is
activated by sample exit CTRX001T and CA-1 is activated by
sample exit CTRX001Z, perform the following steps:
2. Copy job UMRXROOF into a new member called UMRX001T.
3. Change all the question marks (?) in job UMRX001T to t and
submit the job. This job creates a module called CTRX001T with an
entry point CTRX001T.
4. Copy job UMRXROOF into a new member called UMRX001Z.
5. Change all the question marks (?) in job UMRX001Z to z and
submit the job. This job creates a module called CTRX001Z with an
entry point CTRX001Z.
Section 10: Exits
Note This process (of copying job UMRXROOF to a new member
and changing the question mark to a character) can be
duplicated for a maximum of 9 functions.
6. Assign exit names to macro variables &MODULE1 and
&MODULE2 in the CTRX001G source member as follows:
&MODULE1 SETC CTRX001T
&MODULE2 SETC CTRX001Z
7. Change all the question marks (?) in job UMRX001 to g and
submit the job. This job will create the driver exit CTRX001 with
an entry point CTRX001.
As a result of the above steps, CONTROL-R will call driver exit
CTRX001 (built from the CTRX001G source by job UMRX001), which
will then call exit CTRX001T and exit CTRX001Z (built by steps 2-5
above) one after the other.
Note The highest return code from all exits is returned to CONTROL-R.
CTRX014 This exit is invoked by CONTROL-R via the IOA online Status screen
3.V before a sysout is viewed.
The exit can be used for the following purposes:
To verify or change parameters and control blocks.
For CDAM manipulation.
See member DOCRX014 in the IOA SECUDATA library for more
Section 10: Exits
CONTROL-D/V Exits
The following CONTROL-D/V exits are available:
CTDX001 Receives control for every mission which should be placed on the
Active Missions file. This exit is usually used to modify mission
production parameters.
See member DOCDX001 in the IOA SECUDATA library and review
the IOA Security Guide for further details.
CTDX002 Printer command exit. This exit receives control at the end of any
chunk of lines which is sent by CONTROL-D to the spool. This exit
can issue operator commands to set the printer for the coming chunk.
(Consult your IOA representative before using this exit.)
See member DOCDX002 in the IOA SECUDATA library for more
CTDX003 CONTROL-D banner exit. This exit receives control at the beginning
and end of every print mission or the beginning of a user in the bundle
or for every report in the bundle or for every chunk in the bundle.
This exit produces banner pages at any level and in any desired
format. It can also, optionally, produce an index of the reports in a
bundle. A detailed explanation of how to tailor and use the banner exit
appears later in this section.
CTDX004 This exit controls access to User Reports List files. When an online
user specifies report selection criteria, a list of reports which the user
is allowed to see is displayed. The user can view and perform other
operations only for reports authorized by this exit. The user will see
only the decollated portion of a report which he/she is allowed to see.
When CONTROL-D is installed, a default dummy exit is active. To
facilitate installation and product testing, this exit does not enforce
any security standards. When security standards are not enforced, all
of the users can see all reports via option U. When CONTROL-D
becomes operational and access to its Online facility is given to many
users, it is highly recommended to use either security module
CTDSE04 or sample user exit CTDX004A.
Sample exit CTDX004A retrieves security definitions from the
Recipient Tree. The administrator can identify one or more recipients
in the Recipient Tree with a TSO logon (or logon, CICS, VTAM, etc.)
user ID. These authorizations enable users to see reports under
Option U. The user IDs to be authorized should be specified in the
AUTHORIZE field in the definition of each recipient which is
authorized to view that IDs reports. For more information, refer to the
Recipient Definition screen in Section 2 of the CONTROL-D User
Manual. When a user is authorized in the Recipient Tree, it means
that the TSO (or CICS, IMS, DC, etc.) user can view all the reports of
that recipient and the reports of his descendants in the Recipient Tree.
Section 10: Exits
The same TSO user ID (or other environments sign-on ID) can be
defined for more than one recipient in the Recipient Tree.
Note Decollated report pages can be sent to recipients that are not
listed in the Recipient Tree. See Decollating Without the
Recipient Tree in Section 7 of the CONTROL-D or CONTROL-V
User Manual for information about how to do this.
User ID identification in the AUTHORIZE field is performed according
to the following rules:
The specified user ID is treated as a prefix of the user ID (if
optional wish WD2564 is set to YES in member IOADFLTC in the
IOA SECUDATA library).
The specified user ID can contain a number of ? characters. This
wildcard character indicates any single character.
Example
AUTHORIZE A??X will match AIOX01, but will not match A1X01.
Consider the following tree:
Programmers with TSO user IDs beginning with T10 are responsible
for reports assigned to the AP department. JOHN is the only
programmer who writes programs also for the DOD contracts section
which is classified. JOHN and every programmer whose user ID starts
with T10 can view reports of all the members in the programming
departments and all reports of the AP department. There is one
exception: except for JOHN (T1002), no one can look at the DOD
contracts section and at JOHNs reports. His boss (TSO user T1001)
can look at JOHNs test reports. But not at the DOD production
reports. Every user in the AP department can look at his/her own
reports only.
Section 10: Exits
The Active User Reports List file also contains entries which describe
the entire original report. The entries are referenced by a specially
reserved user name $SYSDATA. Authorized users can perform
Online viewing of the original report (which is now compressed). The
authorization for accessing $SYSDATA entries is also controlled by
this exit. A user who is authorized in the Recipient Definition screen
can also be allowed to view $SYSDATA entries if the SYSDATA field
contains the value Y (Yes). For more information, refer to Recipient
Definition screen in Section 2 of the CONTROL-D User Manual.
It is strongly recommended that a restricted number of operations
personnel, be authorize the use the SYSDATA option because this
option allows viewing of original reports.
This exit also receives control for every function performed on an entry
in the User Report List file (e.g., update, print, restore, view, index
functions). It is possible to control who is allowed to request a restore,
to determine the maximum number of pages to be printed to a remote
printer, etc. The functionality described above can also be performed
by the security interface module (CTDSE04). If CTDSE04 is installed,
the use of sample exit CTDX004A is not necessary.
Default Global Ruler
Each report can have a default ruler whose name is DEFAULT. User
exit CTDX004 can change the ruler that is used as this default to a
global ruler whose name begins with $. Before CONTROL-D looks for
the reports default ruler, it calls exit CTDX004 and CTDSE04 with
function DEFGRUL. The user exit can return the global ruler name
that should be used as the default ruler and the security exit can
check if the user is allowed to change the default global ruler name.
details about the exit.
CTDX005 This exit receives every line to be printed by the CONTROL-D
Printers Control monitor before actual printing takes place. The exit
can prevent the line from being printed, change its contents or add
more lines to the printed output. Examples of its use:
Print page sequence numbers from the beginning of the printing
mission (these numbers can be printed in the bundle index as well).
The actual printing is suppressed and the bundle is saved to a
sequential file (for file transfer to RJE stations, etc.). See Printing
to a File in Section 4 of this guide.
Section 10: Exits
CTDX006 SMF exit. This exit receives control before each CONTROL-D SMF
record is written to the SMF datasets. It can suppress the record or
change it. The SMF record written by CONTROL-D is created for each
combination of User/Report/Job name. Therefore, it allows accounting
on each level including accounting by report recipient. The number
of pages is accurate (unlike SMF type 6 records which use
approximate numbers).
Note SMF type 6 records are created by JES for the CONTROL-D
Printers Control monitor when it prints bundles. Therefore, it is
necessary not to count the same page twice. This is the reason
why the CONTROL-D SMF record is not of type 6. The SMF
record number is determined by installation parameter SMF.
For more information about the format of the record, see the
sample exit in the IOA SECUDATA library.
CTDX007 This exit handles the problem of decollating reports which cannot be
shown on the screen. Many sites use special character sets in reports
which cannot be displayed on a screen but can be printed. It is
possible under CONTROL-D to decollate such reports by specifying the
name of a translation table before the string in the WHEN statement.
Under this method, the user types what he/she can see and decollation
takes place using the actual non-standard spool representation. See
member DOCDX007 in the IOA SECUDATA library for more details.
CTDX008 This exit is used to control the update of the Active Missions file. See
member DOCDX008 in the IOA SECUDATA library and review the
IOA Security Guide for more information about this exit.
CTDX009 Print job tailoring exit. This exit can modify the contents of the print
job prepared by the CONTROL-D print mission. See Section 4 of this
guide for a description of printing mission work flow.
CTDX010 Backup job tailoring exit. This exit can modify the contents of the
backup job prepared by the CONTROL-D backup mission. See
Section 4 in this guide for a description of backup mission work flow.
CTDX011 Restore job tailoring exit. This exit can modify the contents of the
restore job prepared by the CONTROL-D restore mission. See
Section 4 in this guide for a description of restore mission work flow.
Section 10: Exits
CTDX012 Activated by utility CTDCA2P. This exit allows the user to change the
contents of the records which are copied from the Active User Report
List file to the Permanent User Report List file. The exit can also
suppress the copying of any record.
CTDX013 Activated by utility CTDCP2A. This exit allows the user to change the
contents of the records which are copied from the Permanent User
Report List file to the Active User Report List file. The exit can also
suppress the copying of any record.
CTDX014 Immediate print request banner exit. Used to print banners on
immediate print requests from the Online viewing facility. The exit is
similar in function to exit CTDX003 and is described in more detail in
Tailoring CONTROL-D Banner Exit below.
CTDX015 This exit receives every line to be printed by an immediate print
request under the Online viewing facility. The exit can suppress the
line, change its contents, etc. It is similar in function to exit CTDX005.
CTDX016 This exit receives control during report decollation when a search is
made in the Recipient Tree for a synonym which is identical to the
recipient name found in the report (i.e., when trying to identify the
recipient of the page). The exit can determine whether they are equal
or not. It is mainly used to define synonym ranges. For example: User
BR129 should receive all postal codes from 10200 to 10399. See
Section 7 of the CONTROL-D User Manual for an example of the use
of this exit.
CTDX017 This exit receives control for every message issued by the
CONTROL-D Shout facility. It can modify the message text, change its
destination or suppress it. It can also be used for special purposes such
as interfacing Electronic Mail systems or InfoMan.
Section 10: Exits
CTDX018 This exit is activated when CDAM parameter EXIT=YES is specified.
The exit receives control for every line written to the CDAM file. See
Section 5 of the CONTROL-D User Manual for a description of the
exit.
CTDX019 This exit is used to control the update of the CONTROL-D/PC Active
Transfer file.
See member DOCDX019 in the IOA SECUDATA library and see the
IOA Security Guide for more information about this exit.
CTDX020 This exit is invoked when the Print Plan file is built. It can modify the
contents of print plan records before they are written to the print plan
file.
CTDX021 This exit is activated before the Recipient Tree is displayed (Screen T).
Based on the library name and Recipient Tree member name, the exit
determines if the Recipient Tree is to be edited or browsed.
CTDX022 This exit is invoked during decollation. It can be used to access default
records in the Active or Permanent User files, to create user and
SYSDATA records in the Active User file, to access each page of a
report that is being decollated, or to access index values before they
are added to the index file. When this exit is called, function
INXMASK can be used to modify a mask value and function INXVAL
can be used to unify index values by (for example) changing index
values from mixed case to uppercase.
CTDX023 User exit CTDX023 is invoked by the file transfer monitor during each
step which prepares and sends files. This exit can be used to designate
the desired file transfer protocol. The default file transfer protocol is
TCP/IP. Other supported protocols include XCOM 6.2. See sample
member CTDX023C in the IOA SECUDATA library which provides
support for XCOM 6.2.
Section 10: Exits
CTDX024 This exit is invoked by the Application server when a Page On
Demand (POD) request is processed. It can be called to control access
to the CONTROL-D Active User file and the CONTROL-V Migrated
User file from CONTROL-D/PC Page On Demand. The mainframe
logon user ID specified in the CONTROL-D/PC Communication Setup
menu is passed to this exit.
Security module CTDSE24 retrieves security definitions from the
Recipient Tree. The administrator can authorize CONTROL-D/PC
Page On Demand users to view mainframe reports by adding the
appropriate mainframe logon ID to the AUTHORIZE field in the
recipient definition(s) in the Recipient Tree. See the documentation for
security module CTDSE24 for more information about this topic.
CTDX026 This exit is invoked by the CONTROL-D/Decollation Server Online
environment under the T, M, A.Z and U.P screens.
CTVX001 This exit is invoked during online processing of index files. It enables
the user to retrieve index values from non-CONTROL-V index files.
See member DOCVX001 in the IOA SECUDATA library for more
CTVX002 This exit is invoked by the IOASMON Archive Server before writing
an SMF record.
See member DOCVX002 in the IOA SECUDATA library for more
Replacing CONTROL-D User Exits
The CONTROL-D monitor supports several user exits: CTDX007, CTDX010, CTDX011 and
CTDX022.
To load a new copy of an exit without shutting down the CONTROL-D monitor, simply
enter the exit name using a modify command. For example:
F CONTROLD,CTDX007
After a few seconds, the following message is displayed on the operator console from which
the modify command was issued.
CTD126I NEW EXIT CTDX007 LOADED
In case of an error while loading the new copy of an exit, an appropriate message appears
on the operator console and the original copy of the exit remains active.
Section 10: Exits
Tailoring CONTROL-D Banner Exit
General
There are two Banner exits under CONTROL-D:
CTDX003 The deferred print (printing mission) Banner exit.
CTDX014 Immediate Print request Banner exit. Used for printing banners on
direct print requests of Online viewing users.
The CONTROL-D Banner exits (CTDX003 and CTDX014) can be tailored for most sites
without coding Assembler instructions (described later in this section).
The following items are discussed below:
Banner Pages
Format of Banner Pages
Printing User Address in Bundle Banner
Index Printing Control
AFP (APA) Support
XEROX (DJDE) Support
Initiating Page Marks
Global Control of Printing Characteristics
Banner Pages
The CONTROL-D supplied Banner exit prints different types of banner pages. Banners are
defined in the library allocated to DD statement DABANNER of the CONTROL-D Printers
Control monitor, the Online monitor and of each Online user. A sample CONTROL-D
BANNERS library is supplied as part of the IOA installation. The following banners can be
found in the library:
xxBNDLST Bundle Open banner
xxBNDLEN Bundle Close banner
xxUSERST Beginning of a User (Recipient) Reports banner
xxUSEREN End of a User (Recipient) Reports banner
xxREPSTA Start of Report banner
xxREPEND End of Report banner
xxUINDXH Header of Reports index
xxUINDXV Format of each index line
$$ONLSTA Start Banner of immediate print requests
$$ONLEND End banner of immediate print requests
Section 10: Exits
The prefix of the banner members beginning with xx is determined by the type of printer
used to print the report (Xerox, APA, Siemens, etc.), as follows:
Type Banner Prefix
REG $$
LAS $$
APA $1
XER $2
FOB $3
If a banner member for a specific printer type is not found, the default banner member is
used (e.g., if $1BNDLST is not found, default member $$BNDLST is used).
The type of the printer specified in the CONTROLD installation parameters (member
CTDPARM in the IOA INSTCTD library).
Format of Banner Pages
The contents of each banner page is determined by the text which is found in the banner
member. The following rules apply to printing banner pages:
The first character of each line can be:
Any valid ASA code (1, +, -, etc.).
X5A for AFP (Advanced Function Printing).
A line descriptor:
Blank Regular size letters.
B Big (large) size letters.
M Medium size letters.
S Small size letters.
E End of banner page.
C Comment line.
Section 10: Exits
It is possible to use special variables within the banner page definition. These variables
will automatically be replaced for each banner printed. The variables are:
%MISSION%
2
Printing mission name.
%USER% User (recipient) name.
%FATHER% Father of the recipient in the tree.
%REPORT% Report name.
%CATEGORY% Printing Mission category.
%JOBNAME% Name of the job which produced the report.
%JOBID% Job ID (in JES) which created the report.
%DATE% Current date (at printing time).
%TIME% Current time.
%ODATE% Original scheduling date of the report.
%PAGES% Number of pages (for each type of banner and for the index).
%LINES% Number of lines (for each type of banner and for the index).
%DEST% Printing (JES) destination.
%LASTUSER% Last user (used in END banners).
%COPIES% Number of copies to be printed (for report banner and for the index).
%CURRCOP% Current printing copy (of the copies) (for report banner only).
%FROMPAGE% From page printed.
%TOPAGE% Until page printed.
%OUSER%
3
Name of the user who requested the print.
%REMARK% Decollation remark (in Active User List file).
%RULER% Name of the ruler being used to print the report. (If no ruler is being
used, no RULER is printed.)
%GROUP% Printing GROUP (from the printing mission definition).
2
For a Deferred Print Banner only.
3
For an immediate Print banner only.
Section 10: Exits
%GLOBALn% The nth line of member $$GLOBAL (where n is an integer from 1 to
10).
The CONTROL-D BANNERS library contains member $$GLOBAL.
This member can contain 1-10 lines of data. When parameter
%GLOBALn% is specified in the report, the nth line from this member
is placed in the banner page.
This parameter can be used to distribute NEWS to all report
recipients.
%DATAn% The nth line of a member whose name is identical to the user name
(not to the synonym) in the Recipient Tree. Valid values for n: 1 to 10.
The CONTROL-D Banners library can contain a member for each
report recipient. This member can contain 1-10 lines of data. When the
parameter %DATAn% is specified in the report, the nth line from the
member of the current user is placed in the banner page. CONTROL-D
does not expect to find such a member for each user.
This parameter can be used for special distribution instructions for a
user. See sample members BMIAMI and UNIDENT in the BANNER
library.
%ADDRn% The nth address line of the current user (recipient) in the tree. Valid
values for n: 1 to 10.
The CONTROL-D Recipient Tree can contain address lines which can
be inserted in the banner page of this user. Any text can be entered in
these address lines. A maximum of ten address lines can be specified
per user. CONTROL-D does not expect to find such lines for each user.
A common use of this parameter is for the user address (to which the
bundle should be delivered).
Note For performance reasons, it is recommended to use variable
%ADDRn% instead of variable %DATAn% whenever possible
because %ADDRn% data is located in memory and %DATA is in
a library, member.
%LASTADDRn% Used in the End user banner to print the address of the last user
(which has already printed). This variable is identical to %ADDRn%
and is supported for backward compatibility.
Printing User Address in Bundle Banner
CONTROL-D can group the reports of several recipients into one bundle. In such cases, it
can be desirable to have a specific address assigned to the entire bundle and to print this
address on the bundle banner. CONTROL-D does this in the following way:
The contents of the GROUP field of the printing mission is compared with the Recipient
Tree. If the GROUP field contains a user name from the tree (not a synonym), using the
variable %ADDRn% in the bundle banner produces the address of this user.
Section 10: Exits
Eliminate Banners
If you want to suppress the printing of a certain banner type, simply rename the banner
member in the BANNERS library. You can suppress the printing of User and/or Report
Banners for all reports of a particular recipient using the Recipient Tree definition. See
Section 2 of the CONTROL-D User Manual for more details.
To suppress the printing of all Banners by a particular printing mission, specify in the
printing mission CATEGORY field the special name NOBANNER. See Section 4 of the
CONTROL-D User Manual for more details.
See also parameter BANSEQ described in Banner Printing Option later in this section.
INDEX Printing Control
The title of the index is retrieved from member $$UINDXH in the BANNERS library. The
format of each line of index is retrieved from member $$UINDXV in the BANNERS
library.
If variable %COPIES% is used in the index, the printed value is the value before the actual
print. If the copies count is changed during printing (e.g., it was suppressed by a user exit),
the correction will not be shown on the index.
The following parameters can be specified in the banner exits (CTDX003 and CTDX014) to
control the printing of indexes:
GINDEX Whether or not an index bundle contents (global index) should be
printed at the beginning of a printing mission (after the bundle
banner page). Valid values:
ON The global index is printed.
OFF The global index is not printed.
INDEX Optionally, it is possible to create a separate index for each user in the
bundle. A bundle can contain reports for more than one user. Valid
values:
ON Each user will receive an index at the beginning of each
user bundle. However, if parameter INDEX in the
Recipient Tree is equal to N, an index will not be
printed for this user.
OFF An index will not be produced for each user. However, if
parameter INDEX in the Recipient Tree is equal to Y,
an index will be printed for this user.
LINECT Specifies the maximum number of index records to be printed on a
page. If LINECT=0 is specified there is no limit (i.e., any number of
records can be printed on a page).
Section 10: Exits
EINDEX Whether or not an End User Index should be printed. An End User
Index is an index printed at the end of a specific users report bundle
that indicates which reports were actually printed (i.e., it does not
include reports that were not printed) for that user. Valid values:
Y (Yes) End User Indexes are printed. However, if parameter
INDEX in the Recipient Tree is equal to N (or blank),
an index will not be printed for this user.
NO/blank End User Indexes are not printed.
GEINDEX Whether or not a Global End Index should be printed. The Global End
Index contains an index of all reports that were actually printed in a
report bundle. Valid values:
Y (Yes) Print a Global End Index.
NO/blank Do not print a Global End Index.
Banner Printing Options
The following parameters in the banner exits (CTDX003 and CTDX014) are used to
determine where, when and how bundle banners are printed:
BUNSEP Where bundle banners should be printed. Valid values:
Y (Yes) The bundle start banner, bundle index and bundle end
banner are printed to the destination specified in the
print mission. See parameter DEST in Section 2 of the
CONTROL-D User Manual,.
All other banners, indexes and reports are printed to
the destination specified in the User Reports screen.
See parameter DEST in Section 2 of the CONTROL-D
User Manual,.
N (No) All banners, indexes and reports are printed to the
destination specified in the User Reports screen. See
parameter DEST in Section 2 of the CONTROL-D User
Manual.
BANSEQ Indicates whether or not CONTROL-D should print banners when
printing to a sequential file instead of the JES SPOOL. Valid values:
Y (Yes) Print banners when printing to a sequential file.
N (No) Do not print banners when printing to a sequential file.
BANAFP Indicates whether or not to implement PAGEDEF, FORMDEF and
OUTPUT statements when printing banners for the report. These
statements can be included either with the PRINT/CDAM parameters
for this report or in the OUTPARMS library. The OUTPARMS library
is described in Section 4 of this guide.
Y (Yes) Implement these statements when printing banners for
the relevant report.
NO/blank Do not implement these statements when printing
banners for the relevant report. Default.
Section 10: Exits
OUTPARM Options
The OUTPARM options provide the ability to override the default printing characteristics
(specified at decollation time) for all (or some) of the reports and banners to be printed by
CONTROL-D. To activate this feature add the following parameters to the banner exits
(CTDX003 and CTDX014):
OUTPARM Whether all the members in the CONTROL-D OUTPARMS library
refer to job names or to user IDs. Valid values:
JOB The members in the OUTPARMS library refer to job
names.
USER The members in the OUTPARMS library refer to user
names.
BANNER Whether or not banners should be printed with the characteristics
specified for reports in the OUTPARMS library. Valid values:
Y (Yes) Banners will be printed with these characteristics.
N (No) Banners will not be printed with these characteristics.
For more information, see Using OUTPARMS for Global Control of Printing
Characteristics in Section 4 of this guide.
AFP (APA) Support
Section 3 of the CONTROL-D User Manual and Section 4 in this guide explain how
CONTROL-D supports AFP (APA) printers. When you are using AFP (APA) printers, the
banner exit invokes a special routine called CTDAPA.
XEROX (DJDE) Support
See Section 4 in this guide for information about how CONTROL-D supports XEROX
(DJDE) printers. When you are using XEROX printers, the banner exit invokes a special
routine called CTDDJDE. The source of this routine is in the IOA SECUDATA library.
Summary
By using various line types and special variables, it is possible to tailor the format of
banner pages for most sites without modifying the banner exit itself. However, it is also
possible to tailor the banner exit. If the supplied banner exit does not fit your
requirements, you can modify the exit and adapt it for your special requirements. If you do
so, let us know what changes you made and why. Your modifications can be implemented
as a standard in a future release.
Section 10: Exits
CONTROL-B Exits
The following CONTROL-B exits are available:
CTBX001 Receives control for every mission order which should be placed in the
Active Balancing file. For further details, see the IOA Security Guide.
See member DOCBX001 in the IOA SECUDATA library for more
CTBX003 CONTROL-B database exit. Controls all access (for read/write or
update) to CONTROL-B database files (group file, basic variable
definitions files and variable generation files).
CTBX004 CONTROL-B Rule Activity file selection exit. This exit controls which
users can see CONTROL-B invocations on the Rule Activity screen.
CTBX008 This exit is used to control access to the Active Balancing file. For
example, the exit checks if a user is authorized to delete a mission
using the Active Balancing Environment screen. For further details,
see the IOA Security Guide.
CTBX009 This exit receives control for every message issued by the
CONTROL-B Shout facility. It can modify the message text, change its
destination or suppress it. It can also be used for special purposes,
such as an interface to InfoMan or to Electronic Mail Systems.
CTBX010 This exit is used to process extracted information according to user-
defined specifications during processing of a DO EXTRACT statement.
For more information on extract processing, see the description of
statement DO EXTRACT in Section 5 of the CONTROL-B user
manual. and member CTBX010 in the IOA SECUDATA library.
Section 10: Exits
CONTROL-T Exits
The following CONTROL-T exits are available:
CTTX001 Receives control for every CONTROL-T rule which is loaded during
initialization. This exit can be used to modify rule parameters.
Security module CTTSE01 is associated with this exit. See the IOA
Security Guide for more information on this security module.
See member DOCTX001 in the IOA SECUDATA library for more
CTTX002 Dynamic stacking exit. Receives control when utility CTTSTK is
executed, when dynamic stacking for a dataset should be performed
and when a new dataset is added to the Media Database.
CTTX003 SVC operation decision. Receives control at dataset open and can
determine the process of this open request. The exit has an associated
security module CTTSE03.
CTTX004 Dynamic definition exit. Receives control when a dataset or volume is
to be dynamically defined to the Media Database. The exit has an
associated security module CTTSE04.
CTTX005 Abend exit. When CONTROL-T is about to abend a job, this exit
receives control and determines whether to allow the job to abend or to
bypass CONTROL-T.
If you decide to implement this exit, do so with extreme caution. If you
bypass CONTROL-T, tape protection is disabled for this job.
CTTX006 Media Database update validation. Receives control when a request to
update the Media Database is received from the SVC, Online
environment, or utilities CTTRTM, CTTVTM and CTTEXP. Security
module CTTSE06 is associated with this exit.
CTTX007 Cycle processing exit. Receives control whenever utility CTTRTM or
CTTVTM processes a cyclic dataset. The exit can determine the
processing parameters.
Section 10: Exits
CTTX008 Robotic Tape library interface confirmation exit. Receives control
before a request is made to the Robotic Library routine and before a
retry is initiated for a request after a failure. The exit can allow or
reject the request and can modify the maximum number of retries
allowed for a request.
CTTX009 External label printing. Receives control either from CONTROL-Ts
SVC (via statement DO LABEL) during dataset creation or from the
Online environment (screen TI or TC) by specific request. It can be
used to format label structure and contents and/or specify whether or
not to print labels. Security module CTTSE09 is associated with this
exit.
CTTX010 Receives control when the Dynamic Dataset Stacking facility scans the
Media Database for a stackable volume. This exit can be used to
change search decisions (i.e., to Reject or Accept a volume)or to supply
a new volume to be used for stacking.
IOAX038 Determination of execution environment for IOA functions. This exit
can be used to specify which Functional monitor is to be used to
perform which IOA functions.
Section 10: Exits
CONTROL-O Exits
The following CONTROL-O exits are available:
CTOX001 Receives control under the Online interface whenever a rule
ORDER/FORCE is performed.
CTOX002 Receives control for every rule before it is loaded to the active
environment. This exit can be used to modify rule parameters prior to
rule loading.
CTOX003 Receives control before execution of each DO KSL/TSO statement.
This exit can be used to modify specific requests.
CTOX004 Receives control each time a user enters an Automation Options
screen or attempts to perform an action in an Automation Options
screen.
CTOX008 Receives control each time a user enters the Rule Status screen or
attempts to perform operations in the Rule Status screen.
Section 10: Exits
Activating the CONTROL-M/WorkLoad Monitor .............................................................. 11-1
Shutting Down the CONTROL-M/WorkLoad Monitor...................................................... 11-1
Command Scope ........................................................................................................................ 11-2
Monitor Control Commands................................................................................................... 11-3
Modifying the CONTROL-M/WorkLoad Operation Mode......................................................11-3
Modifying the CONTROL-M/WorkLoad Sleeping Interval....................................................11-4
Reloading the Installation Parameters ...................................................................................11-4
Reloading CONTROL-M/WorkLoad Programs.......................................................................11-5
Rule Management ..................................................................................................................... 11-6
Manual Loading of Rules to the Active Environment ............................................................11-6
Deleting a Rule Table From the Active Environment ............................................................11-7
Holding/Releasing a Loaded Rule............................................................................................11-8
Displaying Rules.....................................................................................................................11-10
Pipe Control Commands........................................................................................................ 11-10
Displaying the Pipe Information Summary..........................................................................11-10
Displaying Pipe Information..................................................................................................11-11
Forcing End-Of-File Indication on a Pipe .............................................................................11-12
Canceling an Active Pipe .......................................................................................................11-12
Unlocking a Pipe.....................................................................................................................11-13
Participant Control Commands .......................................................................................... 11-13
Displaying Participant Information......................................................................................11-13
Job Control Commands ......................................................................................................... 11-14
Displaying the Parallel Job Information Summary .............................................................11-14
Displaying Parallel Job Information.....................................................................................11-14
Cancel Active Job/Step...........................................................................................................11-15
Unlocking a JOB.....................................................................................................................11-15
Problem Determination Commands................................................................................... 11-16
Internal Trace Management ..................................................................................................11-16
Activating the Internal Trace ...........................................................................................11-16
Stopping the Internal Trace..............................................................................................11-18
Displaying the Internal Trace Setting .............................................................................11-18
Displaying Pipe and Participant Information ......................................................................11-18
Displaying Data Space Information......................................................................................11-19
Printing Internal Data ...........................................................................................................11-19
Printing Pipe-Related Tables............................................................................................11-19
Printing Participant (ASID) Related Tables....................................................................11-20
Table of Contents
Printing Data Space (CLPOOL) Contents ...................................................................... 11-20
Printing General Data Areas ........................................................................................... 11-20
Display Command Output Formats .................................................................................... 11-21
Display Rules ......................................................................................................................... 11-21
Display All Pipes.................................................................................................................... 11-22
Display Specific Pipe Information ........................................................................................ 11-23
General Pipe Information................................................................................................. 11-24
Pipe I/O Information......................................................................................................... 11-26
General Participant Information..................................................................................... 11-26
Participant I/O Information............................................................................................. 11-28
Display Participant Information........................................................................................... 11-29
Address Space Information.............................................................................................. 11-29
Pipe Information............................................................................................................... 11-29
Display Parallel Job Information Summary ........................................................................ 11-31
Display Parallel Job Information.......................................................................................... 11-32
Job Information................................................................................................................. 11-32
Step Information............................................................................................................... 11-33
Activating the CONTROL-M/WorkLoad Monitor
CONTROL-M/WorkLoad services are provided by the CONTROL-M/WorkLoad monitor. A
separate monitor runs in each system in which CONTROL-M/WorkLoad services are
required. The monitor must constantly be active, and therefore it is usually activated as
part of the IPL process. To activate the monitor manually, use the operator command:
S CTLMON
After the monitor is successfully activated, the following message appears on the operator
console:
CTL106I CONTROL-M/WORKLOAD MONITOR IS ACTIVE. NAME=ctlmon ID jobid
Once the monitor is active, if you try to activate an additional monitor with the same
subsystem name on the same system, the new (i.e., additional) monitor immediately shuts
down and an appropriate message is issued.
Shutting Down the CONTROL-M/WorkLoad Monitor
If, for some reason, it is necessary to shut down the monitor, use operator command:
F CTLMON,SHUT TYPE=NORMAL|FORCE[,SCOPE=LOCAL|GLOBAL]
where:
TYPE=NORMAL Requests that the monitor perform Normal termination. During
Normal termination, the monitor first switches to Draining Mode.
Under that operation mode, all active jobs/applications using the
monitors services are allowed to terminate their processes, but no new
jobs/applications are accepted and no new pipes are defined. When
there are no more active jobs/applications, the monitor terminates.
While operating in this mode, the operator can perform other
commands (e.g., Display), request forced termination, or cancel the
shutdown request and resume standard operation (see Modifying the
CONTROL-M/WorkLoad Operation Mode below).
TYPE=FORCE Forces the monitor to terminate immediately, causing abends to all
the participants which are currently using its services.
SCOPE Relevant only when CONTROL-M/WorkLoad operates in a Sysplex
environment in Global mode. Valid values:
LOCAL Shut down only the specific monitor in the system where
the command was issued. Default.
GLOBAL Shut down all monitors operating in Global mode in all
systems of the Sysplex.
After a few seconds, the monitor starts its termination process and the following message
appears on the operator console:
CTL113I SHUT DOWN UPON REQUEST FROM OPERATOR
When the termination is concluded, the following message appears on the operator console:
CTL103I CONTROL-M/WORKLOAD MONITOR SHUTTING DOWN
Note Operator command P CTLMON should not be used. If used, it will cause normal
termination of the specific monitor, but will not allow any further operator commands
(not even displays).
In case of emergency, the monitor can be canceled. However, this is not recommended
because it will cause active jobs using CONTROL-M/WorkLoad services to abend.
Command Scope
When CONTROL-M/WorkLoad operates in Local mode, each system is handled
independently. An operator command issued for a CONTROL-M/WorkLoad monitor in
Local mode affects only the monitor in the system where the command was issued.
When CONTROL-M/WorkLoad operates in Global mode in a Sysplex environment, Monitor
Control commands, Rule Management commands (excluding Display commands), and
Internal Trace Management commands can be distributed to all the monitors in all the
Sysplex systems. This is accomplished by adding parameter SCOPE to these commands.
SCOPE=GLOBAL Distribute operator commands to all the monitors in all the systems.
Default.
SCOPE=LOCAL Perform the operator command only in the specific monitor in the
system where the command was issued.
Note When parameter SCOPE is omitted, operator commands are distributed to all the
monitors in all the systems of a Sysplex.
When SCOPE=GLOBAL is used (either explicitly or as a default), each monitor in the
Sysplex environment receives the command, performs it, and issues the appropriate
response messages.
Parameter SCOPE is ignored for Pipe Control commands, Participant Control commands,
and Problem Determination commands (except Internal Trace Management). These
commands are processed as Local commands.
For Pipe Control commands there is no need to distribute the command because the Pipe
list which is holding the pipe information is shared between all systems in the Sysplex.
Therefore, Pipe Control commands can be performed in any system, regardless of the Pipe
Home System.
Participant Control commands and Problem Determination commands (except Internal
Trace Management) are always handled only in the specific monitor in the system where
the command was issued.
Monitor Control Commands
Modifying the CONTROL-M/WorkLoad Operation Mode
The CONTROL-M/WorkLoad monitor provides services to jobs which are already connected
to it, and receives new jobs requiring its services.
It may occasionally become necessary or desirable to temporarily prevent new jobs from
requesting services from the monitor, and then afterwards resume normal processing. This
can be done using the operator command:
F CTLMON,SET MODE=DRAIN|RESUME[,SCOPE=LOCAL|GLOBAL]
where:
MODE Changes the operation mode of the monitor. Valid values:
DRAIN The monitor switches to Draining mode. The monitor does not
accept new jobs/applications, but existing applications can
continue processing until normal termination.
RESUME The monitor resumes normal operation (Active) mode.
SCOPE See Commands Scope earlier in this guide.
After the command is executed, the following message appears on the operator console:
CTL101I CONTROL-M/WORKLOAD OPERATES IN "mode" MODE
where the indicated mode value is DRAINING or ACTIVE, depending on the command issued.
Example
F CTLMON,SET MODE=DRAIN,SCOPE=GLOBAL
Changes the operation mode of all monitors in the Sysplex to Draining.
Modifying the CONTROL-M/WorkLoad Sleeping Interval
The monitor wakes periodically at a predefined interval, checks for time-out events and
performs housekeeping tasks when required. This time interval is defined in the
CONTROL-M/WorkLoad installation parameters which can be changed by the system
administrator and reloaded (see Reloading the Installation Parameters below). In
addition, during execution, the operator can modify the interval via the command:
F CTLMON,SET INTERVAL=nn[,SCOPE=LOCAL|GLOBAL]
where:
INTERVAL New interval, in seconds. Minimum value is 5.
When the modification is accepted by the monitor, the following message appears on the
operator console:
CTL144I MONITOR INTERVAL IS SET TO ### SECONDS
The optimal sleeping interval depends on the processing power of the machine. The
sleeping interval should usually not be less than the number of seconds indicated:
For machines with 2050 MIPS 20 seconds
Example
F CTLMON,SET INTERVAL=20,SCOPE=LOCAL
Sets the sleeping interval of CTLMON to 20 seconds.
Reloading the Installation Parameters
The CONTROL-M/WorkLoad installation parameters (defined in member CTLPARM of the
INSTCTL library) can be reloaded while the monitor is active. There is no need to shut down
the monitor for that purpose.
To reload the installation parameters, issue the operator command:
F CTLMON,RELOAD PARM=INSTPARM[,SCOPE=LOCAL|GLOBAL]
After the reload was performed by the monitor, the following message appears on the
operator console:
CTL108I MONITOR RELOAD INSTPARM ENDED. RC=rc
Changes to the following parameters take effect immediately following command execution:
DATACLAS INTERVAL MGMTCLAS
MODE SMF STORCLAS
STPASNM TMPFLPRF UNITNAME
Changes to other parameters do not affect the current execution of the
CONTROL-M/WorkLoad monitor.
Reloading CONTROL-M/WorkLoad Programs
After applying maintenance to CONTROL-M/WorkLoad programs or applying user
modifications to CONTROL-M/WorkLoad user exits, a new copy of the program/exit can be
reloaded for monitor use without having to shut down the monitor for that purpose.
To reload a program or exit issue the operator command:
F CTLMON,RELOAD PGM=CTLxxxx[,SCOPE=LOCAL|GLOBAL]
where:
PGM Program/exit name which appears in the list below.
After the reload is performed by the monitor, the following message appears on the
operator console:
CTL108I MONITOR RELOAD CTLxxxx ENDED. RC=rc
The following user exits can be reloaded:
CTLX003
CTLSE03
CTLX004
CTLX005
The following programs can be reloaded:
CTLABMP CTLADSM CTLAERH CTLAIO
CTLAJLM CTLAJLS CTLAJMP
CTLAMPS
CTLAPBM CTLAPLM CTLAPLS CTLAPST
CTLAREQ
CTLASCLN CTLASCR CTLASIOR
CTLASMF CTLASTE CTLCOND CTLDEXT
CTLDISP CTLDSEN CTLDYNA
CTLGASM
CTLHASH
CTLJEND CTLJPLN CTLMLST
CTLPJLM CTLPLST CTLPPLM
CTLRMGR
CTLRSRH
CTLRSRJ CTLSEJS CTLSESH
CTLSMGT
CTLSMOD
Example
F CTLMON,RELOAD PGM=CTLSE03,SCOPE=GLOBAL
Reloads user security exit CTLSE03 to all monitors in the Sysplex.
Rule Management
Manual Loading of Rules to the Active Environment
The Rule Load list member (default member: CTLRLLST) contains a list of basic rule tables
to be loaded by CONTROL-M/WorkLoad as it is started. To load additional tables, or to
replace a currently active table with a new (updated) copy of the rules in the table, use
either of the following methods:
Enter the CONTROL-M/WorkLoad Online facility and use the ORDER/FORCE option in
the Table List screen (screen LR). See Section 2 of the CONTROL-M/WorkLoad User
Manual for details.
Issue the operator command:
F CTLMON,LOAD TABLE=table-name|ALL[,LIB=library-name][,SCOPE=LOCAL|GLOBAL]
where:
TABLE Rule table name, or ALL.
Use a Rule table name to load a new table of rules or replace an
existing table in memory. If the table has already been loaded by
CONTROL-M/WorkLoad, the new copy of the table replaces all the
rules of the table active under the CONTROL-M/WorkLoad monitor.
Use TABLE=ALL to replace all the tables under
CONTROL-M/WorkLoad with the tables specified in the Rule Load list
referenced by DD statement DARULLST.
LIB Rule library name, required only when loading a specific table.
When ALL is specified, all previously loaded rules are deleted. Each table from the
Rule Load list referenced by DD statement DARULLST is ordered or forced according
to its ORDER/FORCE/NOFORCE specification in list.
When a table name is specified, or when TABLE=ALL is used and ORDER/NOFORCE
is specified for a table in the Rule Load list, the rules from the table are ordered. This
means that each rules Basic Scheduling parameters are compared to the current date.
If the rule should be scheduled on that date, the rule is loaded by
CONTROL-M/WorkLoad (similar to the ORDER command under the Online facility).
Note Unless defined otherwise, all Rule commands refer to both pipe rules and job rules.
After the load request is received by the monitor, the following message appears on the
operator console:
CTL263I RULE LOAD STARTED. TABLE=table|ALL
After the load is performed by the monitor, the following message appears on the operator console:
CTL264I RULE LOAD ENDED. RC=rc
Examples
F CTLMON,LOAD TABLE=ACTGPROD,LIB=ACTG.PROD.RULES,SCOPE=LOCAL
Loads table ACTGPROD from ACTG.PROD.RULES to the CTLMON active environment.
F CTLMON,LOAD TABLE=ALL,SCOPE=GLOBAL
Replaces all the loaded tables in all monitors in the Sysplex with the tables specified in the
Rule Load list referenced by DD statement DARULLST in each monitor.
Deleting a Rule Table From the Active Environment
During monitor execution, all rules of a given table can be removed from the active environment.
To delete a loaded table, issue the operator command:
F CTLMON,DELETE TABLE=table-name,LIB=library-name[,SCOPE=LOCAL|GLOBAL]
where:
TABLE Rule table name.
LIB Rule library name, from which the table was loaded.
After the delete request was received by the monitor, the following message appears on the
operator console:
CTL263I RULE DELETE STARTED. TABLE=table
After the delete was performed by the monitor, the following message appears on the
operator console:
CTL264I RULE DELETE ENDED. RC=0000
Example
F CTLMON,DELETE TABLE=ACTGPROD,LIB=ACTG.PROD.RULES,SCOPE=GLOBAL
Deletes all rules of table ACTGPROD loaded from library ACTG.PROD.RULES.
Holding/Releasing a Loaded Rule
During monitor execution, rules can be temporarily excluded from the rule search process.
This is done by using the HOLD command. Held rules remain loaded, but are ignored by
the rule search process.
A rule remains held until it is released (via the RELEASE command) or until the table
containing the rule is refreshed (via the LOAD command).
Holding a rule is useful when a specific run of the job (e.g., restart after abend) is
performed without using CONTROL-M/WorkLoad services. After the job finishes
execution, the rule can be released for subsequent runs of the job.
Holding/releasing rules can be performed using either of the following methods:
Use the Hold/Free option in the Rule Status screen (screen LS) of the
CONTROL-M/WorkLoad Online facility. See Section 2 of the CONTROL-M/WorkLoad
User Manual for details.
Issue an operator command, as described below.
Holding/releasing rules can be performed using the rule name, pipe name or job name. To
hold a specific rule by rule name, issue the operator command:
F CTLMON,HOLD RULE=rule-name,TABLE=table-name,LIB=library-name [,SCOPE=LOCAL|GLOBAL]
To release a specific rule by rule name, issue the operator command:
F CTLMON,RELEASE RULE=rule-name,TABLE=table-name,LIB=library-name [,SCOPE=LOCAL|GLOBAL]
where:
RULE Rule name.
TABLE Rule table name.
LIB Rule library name.
Note A rule name (within a rule table) does not have to be unique. The Hold and Release
commands will locate the first rule (with the required name in the required table)
according to the search order. Subsequent commands will locate the next rule which
match the criteria, etc.
To hold pipe rules by pipe name, issue the operator command:
F CTLMON,HOLD RULE=*,PIPE=pipe-name[,SCOPE=LOCAL|GLOBAL]
To release rules by pipe name, issue the operator command:
F CTLMON,RELEASE RULE=*,PIPE=pipe-name[,SCOPE=LOCAL|GLOBAL]
where:
RULE Always has the value *
PIPE Pipe name.
Note When using the pipe name, all pipe rules matching the pipe name will be held/released.
To hold job rules by job name, issue the operator command:
F CTLMON,HOLD RULE=*,JOB=job-name[,SCOPE=LOCAL|GLOBAL]
To release rules by job name, issue the operator command:
F CTLMON,RELEASE RULE=*,JOB=job-name[,SCOPE=LOCAL|GLOBAL]
where:
RULE Always has the value *
JOB Job name.
Note When using the job name, all job rules matching the job name will be held/released.
After the hold/release request was received by the monitor, the following message appears
on the operator console:
For holding/releasing a rule using a rule name:
CTL263I RULE operation STARTED. RULE=rule-name
For holding/releasing a rule using a pipe name:
CTL263I RULE operation STARTED. PIPE=pipe-name
where:
operation = HOLD or RELEASE.
After the hold/release is performed by the monitor, the following message appears on the
operator console:
CTL264I RULE operation ENDED. RC=rc
where:
operation = HOLD or RELEASE.
Examples
F CTLMON,HOLD RULE=ACT001,TABLE=ACTGPROD,LIB=ACTG.PROD.RULES,SCOPE=GLOBAL
Holds rule ACT001 of table ACTGPROD loaded from library ACTG.PROD.RULES.
F CTLMON,HOLD RULE=*,PIPE=PROD.TRAN.FILE,SCOPE=GLOBAL
Holds the rule(s) defining a pipe named PROD.TRAN.FILE.
Displaying Rules
All the rules currently loaded in a specific monitor can be displayed according to their
search order.
To display loaded rules, use either of the following methods:
Use the CONTROL-M/WorkLoad Online facility Rule Status screen (screen LS). See
Section 2 of the CONTROL-M/WorkLoad User Manual for details.
Issue the operator command:
F CTLMON,DISPLAY RULE=ALL
An example and explanation of the display output can be found under the topic Display
Rules under Display Command Output Formats later in this guide.
Pipe Control Commands
Displaying the Pipe Information Summary
The pipe information summary contains brief information about each active pipe and its
participants.
Displaying Pipe information can be performed using either of the following methods:
Use the CONTROL-M/WorkLoad Online facility Active Environment screen (screen
LA). See section 2 of the CONTROL-M/WorkLoad User Manual for details.
To display the pipe information summary, issue the operator command:
F CTLMON,DISPLAY PIPE=ALL[,SYSTEM=sys-name]
where:
SYSTEM Optional. System name (1-8 characters). Default: All systems.
This parameter can be used when working in Global mode in a Sysplex
environment to limit the scope of the display to pipes managed by the
specified system (i.e., the Pipe Home System).
Example
F CTLMON,DISPLAY PIPE=ALL
Display information regarding all the pipes and participants in all systems.
An example and explanation of the display output can be found under the topic Display All
Pipes under Display Command Output Formats later in this guide.
Displaying Pipe Information
Information about a specific pipe and its participants can be displayed. The information
can be requested in either of two formats, Long or Short. The Short format provides basic
information about the pipe and its participants. The Long format provides detailed
information used for problem determination purposes.
General pipe and participant information is available until all the pipe participants
disconnect from the pipe. Information related to I/O (such as the number of blocks read or
written) is available only while the pipe is open (i.e., data is being transferred).
When working in Global mode in a Sysplex environment, I/O information is available only
at the Pipe Home System. If the display command is issued in another system, pipe
information is displayed without I/O information.
Displaying Pipe information can be performed using either of the following methods:
LA). See section 2 of the CONTROL-M/WorkLoad User Manual for details.
To display specific pipe information, issue the operator command:
F CTLMON,DISPLAY PIPE=pipe-name[,FORMAT=SHORT|LONG]
where:
PIPE Pipe full name, 1 44 characters.
FORMAT Optional. Determines the amount of information that is displayed:
SHORT Basic information is displayed. Default.
LONG Detailed information is displayed.
Example
F CTLMON,DISPLAY PIPE=PROD.TRANS.FILE
Display information regarding pipe PROD.TRANS.FILE.
Specific Pipe Information later in this guide.
Forcing End-Of-File Indication on a Pipe
If a pipe remains active after the writers have disconnected and the last writer did not
write an EOF, you can terminate that pipe in an orderly fashion by forcing an external
EOF indication. This allows the readers to read the data from the pipe but prevents new
writers from joining the pipe. When the readers finish reading and disconnect, the pipe is
deleted.
To force an external EOF indication for a pipe, issue the operator command:
F CTLMON,FEOF PIPE=pipe-name
where:
After a pipe is marked EOF, no data can be written to the pipe. However, data already
written to the pipe can be read.
After FORCE EOF is performed by the monitor, the following message appears on the
operator console:
CTL146I PIPE FORCED EOF BY OPERATOR. PIPE=pipe-name ID pipe-id
Example
Force an EOF indication to pipe PROD.TRANS.FILE.
F CTLMON,FEOF PIPE=PROD.TRANS.FILE
Canceling an Active Pipe
An active pipe can be canceled by the operator. When this is done, the pipe is immediately
deleted and all its participants abend. Canceling a pipe may be required when:
A pipe remained defined with no participants, but new participants cannot join it.
Canceling this pipe allows a new pipe to be defined.
The monitor is draining (after a SHUT command with TYPE=NORMAL), but active
pipes are holding up the shutdown. These pipes can be forced to close before their
participants terminate normally by canceling these pipes. (Another method is to force
termination of all pipes by issuing the SHUT command with TYPE=FORCE.)
To cancel a pipe, issue the operator command:
F CTLMON,CANCEL PIPE=pipe-name
where:
After the cancel has been performed by the monitor, the following message appears on the
operator console:
CTL146I PIPE CANCELLED BY OPERATOR. PIPE=pipe-name ID pipe-id
Example
F CTLMON,CANCEL PIPE=PROD.TRANS.FILE
Cancels pipe PROD.TRANS.FILE.
Unlocking a Pipe
In rare situations (e.g., internal program failure, abend), a pipe block might remain locked by
a participant or the monitor, preventing any access to the pipe. In this case, the pipe lock
may be removed using an operator command. Removal of the pipes lock should be performed
with the utmost care since it might expose the pipe participants to unexpected situations.
To unlock a locked pipe, issue the following operator command:
F CTLMON,UNLOCK PIPE=pipe-name
where:
After the unlock has been performed by the monitor, the following message appears on the
operator console:
CTL146I PIPE UNLOCKED BY OPERATOR. PIPE=pipe-name ID pipe-id
Participant Control Commands
Displaying Participant Information
Information regarding a participant (in one or more pipes) can be displayed using its
Address Space ID. The information can be requested in two formats, Long or Short. The
Short format provides basic information about the participant. The Long format provides
detailed information used for problem determination purposes.
To display pipe participant information, issue the operator command:
F CTLMON,DISPLAY ASID=nnn[,FORMAT=SHORT|LONG]
where:
ASID Address space number, in decimal form, in which the participant (job) is
running.
FORMAT Optional. Amount of information that is displayed:
Example
F CTLMON,DISPLAY ASID=85
Displays information about the participant (job) which runs in address space number 85.
Participant Information later in this guide.
Job Control Commands
Note The term job in this topic refers only to a job which runs Parallel Steps (i.e., a Parallel
Job). Jobs which are connected to cross-job pipes are defined as Pipe Participants.
To display job information, use either of the following methods:
LA). See Section 2 of the CONTROL-M/WorkLoad User Manual for details.
Displaying the Parallel Job Information Summary
The job information summary contains brief information about active/terminated parallel
jobs. Information about a terminated job is kept until the same job-name is run again, or
until a specified period of time has elapsed since the job terminated.
To display the job information summary, issue operator command:
F CTLMON,DISPLAY JOB=ALL[,SYSTEM=sys-name]
where:
SYSTEM Optional. System name (18 characters). Default: All systems.
This parameter can be used when working in Global mode in a Sysplex
environment to limit the scope of the display to jobs running in the
specified system.
Example
Display information about all the parallel jobs in all systems.
F CTLMON,DISPLAY JOB=ALL
For an example and explanation of the display output, see Display Parallel Job
Information Summary later in this guide.
Displaying Parallel Job Information
Information about a specific job and its steps can be displayed. The information can be
requested in either of two formats, Long or Short. The Short format provides basic
information about the jobs and its steps. The Long format provides detailed information
used for problem determination purposes.
To display specific job information, issue operator command:
F CTLMON,DISPLAY JOB=job-name[,FORMAT=SHORT|LONG]
where:
JOB Job full name, 18 characters.
FORMAT Optional. Determines the amount of information that is displayed:
Example
Display information regarding job PRODRPT.
F CTLMON,DISPLAY JOB=PRODRPT
For an example and explanation of the display output, see Display Parallel Job Information
later in this guide.
Cancel Active Job/Step
An active job or a specific parallel step can be cancelled during execution.
To cancel a job/step, issue operator command:
F CTLMON,CANCEL JOB=job-name,STEP=ALL|nnn[,FORCE=YES|NO]
Where:
JOB Job full name, 18 charactars.
STEP Step number (1255), which causes a parallel step to terminate; or ALL,
which cancels the entire job.
FORCE Causes immediate termination of the step (used only for cancelling a
step).
After the monitor performs the cancel, one of the the following messages is displayed on
the operator console:
CTL171I JOB CANCELLED BY OPERATOR. JOB NAME=job-name ID=job-id
CTL179I STEP CANCELLED BY OPERATOR. JOB NAME=job-name ID=job-id
STEP=step-number step-name
Example
Cancel step 3 of job PRODRPT.
F CTLMON,CANCEL JOB=PRODRPT,STEP=3
Unlocking a JOB
In rare situations (e.g., internal program failure, abend), a job block might remain locked by
a component such as the job-manager or monitor, preventing access to the job or its steps. In
this case, the job lock can be removed using an operator command. Removal of the job lock
should be performed with the utmost care since it might expose the job and its steps to
unexpected situations.
To unlock a locked job, issue operator command:
F CTLMON,UNLOCK JOB=job-name
where:
JOB Full name of the job. Length: 18 characters.
After the job is unlocked, the following message is displayed on the operator console:
CTL171I JOB UNLOCKED BY OPERATOR. JOB NAME=job-name ID=job-id
Problem Determination Commands
CONTROL-M/WorkLoad is supplied with internal tracing and problem determination
facilities which provide the ability to:
Produce an internal trace.
Display pipe and/or participant information.
Display statistics about the data space usage.
Print the contents of the CONTROL-M/WorkLoad internal data areas.
Note These facilities should be used only when requested by the IOA representative.
Internal Trace Management
Under normal circumstances, the tracing facilities are dormant.
Internal tracing can be activated when the monitor is started or during monitor execution,
and it can be modified or stopped during monitor execution. The internal trace setting can
be displayed.
When activated, the trace information is either printed to DD statements PRTDBG and
DADUMP of the CONTROL-M/WorkLoad procedure, or issued to the console (depending on
the process which produces the trace information).
Tracing can be requested for specific components and/or for a specific job or pipe. Each
component has its own identifying numbers for purposes of producing the trace. These
numbers are called the trace level. One or more trace levels can be activated at the same
time. Trace levels can be modified during execution.
Your IOA representative will provide you with the list of the trace levels which should be
used, depending on the problem encountered.
Activating the Internal Trace
The Internal trace can be activated during one of the following situations:
When the monitor is already active.
During monitor initialization.
Activating the Internal Trace When the Monitor Is Active
To activate the internal trace while the monitor is active, issue the following operator command:
F CTLMON,SET DEBUG=level[,DBGJOB=jobname][,DBGPIPE=pipe-name][,SCOPE=LOCAL|GLOBAL]
where:
DEBUG=level Numbers used to activate/deactivate the trace in specific
components. Positive numbers activate the trace; negative numbers
deactivate the trace. Valid level values are:
Any number between 1 and 1024, or a range of numbers (e.g.,
10:15) to activate the trace. The level is added to the levels
already set.
Any number between -1 and -1024 or a range of numbers
(e.g., -20:-25) to deactivate the trace. The level is removed from
the active levels.
DBGJOB=jobname Job(s) to be traced. Optional. Valid values:
jobname Internal tracing (according to the active trace levels) is
to be performed only for the specified job.
ALL Internal tracing (according to the active trace levels) is
to be performed for all jobs. Default.
DBGPIPE=pipename Pipe(s) to be traced. Optional. Valid values:
pipename Internal tracing (according to the active trace levels) is
to be performed only for the specified pipe.
ALL Internal tracing (according to the active trace levels) is
to be performed for all pipes. Default.
When the trace level set is completed, all or part of the following messages appear on the
console, depending on the parameters specified.
IOAD01I DEBUG LEVELS SET AS FOLLOWS:
IOAD02I 00nn:00mm TURNED on/off
CTL122I DEBUG job/pipe IS SET TO jobname/pipename
Examples
F CTLMON,SET DEBUG=20:29,SCOPE=GLOBAL
Ask for internal trace levels 20 to 29 for all the jobs, all the pipes, and all the monitors in
the Sysplex.
F CTLMON,SET DEBUG=-25,SCOPE=LOCAL
Remove internal trace level 25 (and keep all the others) from this specific monitor.
F CTLMON,SET DEBUG=30,DBGPIPE=PROD.TRANS.FILE,SCOPE=GLOBAL
Ask for internal trace level 30 for pipe PROD.TRANS.FILE only in all the monitors in the Sysplex.
Activating the Internal Trace During Monitor Initialization
If you require tracing during monitor initialization, ensure that the monitor is not active,
and then start a new monitor with the following operator command:
S CTLMON,PARM=SET DEBUG=level
where:
DEBUG=level Numbers used to activate the trace in specific components. Valid level values
are any number between 1 and 1024, or a range of numbers (e.g., 10:15).
Stopping the Internal Trace
When you have finished the with problem determination procedures, internal tracing
should be stopped.
Use the following operator command to stop internal tracing:
F CTLMON,SET DEBUG=OFF[,SCOPE=LOCAL|GLOBAL]
When tracing is stopped, the following messages appear on the console:
IOAD01I DEBUG LEVELS SET AS FOLLOWS:
IOAD02I 0001:1024 TURNED OFF
CTL122I DEBUG JOB IS SET TO ALL
CTL122I DEBUG PIPE IS SET TO ALL
Displaying the Internal Trace Setting
The internal trace setting (level, DBGJOB value, and DBGPIPE value) can be displayed for
a specific monitor.
Use the following operator command to display the internal trace setting:
F CTLMON,SET DEBUG=SHOW
The following messages are produced as the result of the Show command. The format
depends on the setting of the trace levels and job/pipe names:
IOAD03I PRESENT DEBUG LEVELS ARE AS FOLLOWS:
IOAD04I level:level on/off
IOAD04I level:level on/off
CTL122I DEBUG JOB IS SET TO name/ALL
CTL122I DEBUG PIPE IS SET TO name/ALL
Displaying Pipe and Participant Information
Detailed pipe and participant information may be required for problem determination purposes.
To display (detailed) pipe information, see Displaying Pipe Information earlier in this
section.
To display participant information, see Displaying Participant Information earlier in
this section.
Displaying Data Space Information
Data space storage is logically divided into blocks called cell pools. Each cell pool is assigned
a name and contains a number of cells. CONTROL-M/WorkLoad uses different cell pools for
different types of information, such as pipe buffers or messages. Some statistic information
regarding cell pools utilization and data space utilization can be displayed.
To display data space information, issue the operator command:
F CTLMON,DISPLAY CLPOOL=pool-name|ALL
where:
CLPOOL Specific cell pool name, or ALL.
Valid cell pool names are: BP_1K, BP_4K, BP_8K, BP_16K, BP_24K,
BP_28K, BP_32K, CP_PIPB, CP_MSGB, CP_IOB.
If ALL is specified, all of the above cell pools are displayed.
Example
F CTLMON,DISPLAY CLPOOL=BP_24K
Displays information regarding the cell pool which contains pipe buffers for pipes with
block size between 16K and 24K.
Printing Internal Data
The contents of several CONTROL-M/WorkLoad internal data areas and the contents of
the data space can be printed, in dump format, to DD statement DADUMP (defined in the
CONTROL-M/WorkLoad monitor procedure).
Your IOA representative will provide you with the type of data (described below) and, if necessary,
the list of the data area names, to be printed, depending on the problem encountered.
When the print is completed, the following message appears on the console:
CTL021I SNAP ID=snapid PRODUCED ON DADUMP DD
where:
snapid Snap identifying number which appears within the printed data and
identifies the print that was just completed.
Printing Pipe-Related Tables
To print pipe-related tables, issue the following operator command:
F CTLMON,SNAP PIPE=pipe-name
where:
Example
F CTLMON,SNAP PIPE=PROD.TRANS.FILE
Prints the tables related to pipe PROD.TRANS.FILE and its participants.
Printing Participant (ASID) Related Tables
Participant-related tables can be printed using the address space number (ASID).
To print the tables, issue operator command:
F CTLMON,SNAP ASID=number
where:
ASID Address space number (in decimal) in which the participant (job) is
running.
Example
F CTLMON,SNAP ASID=85
Prints the tables related to the job which runs in address space number 85.
Printing Data Space (CLPOOL) Contents
The contents of all or part (specific cell pools) of the data space can be printed.
To print this information, use operator command:
F CTLMON,SNAP CLPOOL=pool-name|ALL
where:
CLPOOL Specific pool name or ALL. Valid cell pool names: BP_1K, BP_4K, BP_8K,
BP_16K, BP_24K, BP_28K, BP_32K, CP_PIPB, CP_MSGB, CP_IOB
If ALL is specified, the contents of all the above cell pools are printed.
Examples
F CTLMON,SNAP CLPOOL=BP_24K
Prints the contents of the cell pool containing pipe buffers for pipes with block size between
16K and 24K.
F CTLMON,SNAP CLPOOL=ALL
Prints the contents of the entire data space.
Printing General Data Areas
To print the contents of the CONTROL-M/WorkLoad internal data areas, issue operator
command:
F CTLMON,SNAP TABLE=table-name
where:
TABLE Specific table name or ALL.
Valid table names: QJT, MMT, MTL, RQT, MNH.
If ALL is specified, all the above tables are printed.
Example
F CTLMON,SNAP TABLE=QJT
Prints the contents of the QJT table.
Display Command Output Formats
This topic contains examples of Display command outputs and their explanations.
For commands having Short and Long display formats, only the Short format is explained.
(Long display formats are not explained because they are usually used for problem
determination, and most of the information in Long display formats is for internal use by
the IOA technical support staff.)
Note When a block of information is displayed, (e.g., via DISPLAY PIPE or DISPLAY
ASID), field order is always maintained. However, formatting and line breaks can
change according to the data displayed.
Display Rules
The following command displays the list of pipe rules:
F CTLMON,DISPLAY RULE=ALL
The following messages are displayed when the above command is specified:
CTL268I RULE/DSN PRIORITY MODE STATUS TABLE LIBRARY
CTL269I IVP P A CTLIVPRL CTLP.V514.RULES
CTL270I TEST.WORKLOAD
CTL269I TRANS P A PROD CTLP.V514.RULES
CTL270I PROD.TRANS.FILE
CTL269I CTLDEFRL P A CTLDEFRL CTLP.V514.RULES
CTL270I *
The display output contains a title line (CTL268I), followed by two lines for each rule
displayed: CTL269I for rule information, and CTL270I for the dataset name:
RULE/DSN Rule name in CTL269I. Dataset (pipe) name in CTL270I.
PRIORITY Sequence priority specified in the rule.
MODE Rule operation mode:
P PROD
T TEST
STATUS Rule status:
A ACTIVE
H HELD
TABLE Name of the table containing the rule.
LIB Name of the library containing the rule table.
Display All Pipes
The following command displays the list of pipes and participants:
F CTLMON,DISPLAY PIPE=ALL
CTL148I PIPE|JOB NAME JOBID DDNAME TYPE SYSTEM STATUS
CTL149I PROD.TRANS.FILE ESA1
CTL150I PRCRTRNS JOB14788 TRANS WRITER ESA1 ACTIVE
CTL149I ACCT.NOTES.FILE ESA1
CTL150I ACTPRTNT JOB14796 SYSUT1 READER ESA1 ACTIVE
CTL150I ACTCRENT JOB14795 SYSUT2 WRITER ESA1 ACTIVE
CTL151I NUMBER OF PIPES=0002, NUMBER OF PARTICIPANTS=0003
The display output contains:
A title line (CTL148I).
For each pipe displayed, one line for pipe information (CTL149I), followed by one line
for each participant connected to the pipe (CTL150I).
A summary line (CTL151I) containing the total number of pipes and participants.
The following information is displayed:
PIPE|JOB NAME Pipe name in CTL149I. Job name in CTL150I.
JOBID Participant job ID.
DDNAME Name of the DD statement used to allocate the pipe.
TYPE Participant type: READER, WRITER
SYSTEM For the pipe, the Pipe Home System (PHS). For the participant, the
system in which the participant is executing.
STATUS Participant status:
ACTIVE Participant is connected to the pipe.
TERM Participant has already disconnected from the pipe.
Display Specific Pipe Information
The following command displays specific pipe information:
F CTLMON,DISPLAY PIPE=PROD.TRANS.FILE
CTL136I PIPE: PROD.TRANS.FILE ID: 19385831
CTL136I ================================================================
CTL136I PHASE...... ACTIVE STAT1...... STAT2...... 00
CTL136I CURR-WTR... 1 CURR-RDR... 1 TOT-WTR.... 1
CTL136I TOT-RDR.... 1 LAST-ACT... 19:38:58
CTL136I FLAG1...... DAT-PIPE FLAG2...... 00
CTL136I TIMESTMP... 1938583148280000
CTL136I HOME-SYS... ESA1 SYNC-TYP... OPEN,CLOSE
CTL136I RD-EROPT... DELAY WT-EROPT... IGNORE
CTL136I I/O INFORMATION:
CTL136I ----------------
CTL136I BLKS-WT.... 455 BLKS-RD.... 447
CTL136I LAST-ACT... 19:39:02 BUFF#...... 10
CTL136I DSCLPOOL... BP_1K MULTI-RD... 1
CTL136I PARTICIPANT PRCRTRNS
CTL136I =====================
CTL136I TYPE....... WRITER JOBNAME.... E01ACDW1
CTL136I PHASE...... IO#1DONE WAIT-TYP... NONE ERR-FLAG...
CTL136I STAT1...... STAT2...... 00 FLAGS......
CTL136I RDR/WTR.... EOF-CLOS JOBID...... JOB00332 ASID....... 15
CTL136I STEP-NUM... 01 PROCSTEP...
CTL136I PGMSTEP.... GO3 DDNAME..... TRANS
CTL136I SYSTEM..... OS32
CTL136I I/O INFORMATION:
CTL136I ----------------
CTL136I BLK-CNT.... 455 WAIT-CNT... 47 WAITP...... IO-WAIT
CTL136I LAST-ACT... 19:39:02
The participant group of messages is repeated for each participant connected to the pipe.
The displayed information is divided into several logical groups:
Pipe information.
General pipe information.
Pipe I/O information, available only when the pipe is Active.
Participant information for each participant connected to the pipe.
General participant information.
Participant I/O information, available only when the pipe is Active.
This information is described below.
General Pipe Information
PIPE Pipe (dataset) name.
ID Unique pipe identifier (the first 8 characters of the pipe time-stamp (see below).
PHASE Current phase in the pipe life cycle:
ALOCSYNC Pipe is not fully defined yet. Synchronization type
ALLOC was defined in the rule; not all the required
participants performed allocation.
OPENSYNC Pipe is not fully initialized yet. Synchronization type
OPEN was defined in the rule; not all the required
participants opened the pipe.
WAITFWTR Readers which already opened the pipe are waiting for
the first writer to open the pipe and perform pipe
initialization (synchronization at open was not
requested).
INIT Pipe initialization is in process.
ACTIVE Pipe is active. Data can be transferred into/from
the pipe.
AFTEOF Pipe is empty and is marked with End-Of-File
indication. (No more data can be read or written.)
CLOSSYNC Some of the participants closed the pipe and are waiting
for all the participants to close (synchronization at
CLOSE was requested).
AFTCLOSE All the participants already closed the pipe.
DALCSYNC Some of the participants deallocated the pipe and are
waiting for all the participants to deallocate
(synchronization at DEALLOC was requested).
STAT1 First status field. One or more of the following can be indicated:
ERROR Pipe in error. Active participants can continue process
according to the Error Option defined in the rule.
ABEND Pipe in error. All active participants should
immediately abend (the pipe can no longer be accessed).
EOF-RCVD End-Of-File indication was received from the last active
writer. No more data can be written into the pipe.
ADD-RDR The pipe will accept additional readers.
ADD-WTR The pipe will accept additional writers.
STAT2 Second status field. The following can be indicated:
IO-ERROR I/O Error occurred during pipe process.
CURR-WTR Number of writers that are currently connected to the pipe (in any phase).
CURR-RDR Number of readers that are currently connected to the pipe (in any phase).
TOT-WTR Total number of writers that are and were connected to the pipe
(including writers who terminated for any reason).
TOT-RDR Total number of readers that are and were connected to the pipe
(including readers who terminated for any reason).
LAST-ACT Time of last action which was performed by any participant, and which
caused a Phase or Status change (not including I/O operations).
FLAG1 First indicator field. One or more of the following can be indicated:
DAT-PIPE Pipe is used to transfer data. Default.
READ-ALL All readers receive all the data passing through
the pipe.
WTR2FILE Writer will write all the pipe data into a physical file.
OPEN-P Open pipe. The pipe accepts an unlimited number of
participants.
FLAG2 Second indicator field. For future use.
TIMESTMP Unique identifier (time stamp) for a pipe. The time stamp value is
determined when the first participant allocates the pipe.
HOME-SYS Name of the Pipe Home System (PHS). This is the system where the pipe
is managed and where the pipe buffers are allocated.
SYNC-TYP Synchronization points defined for the pipe. Valid values: NONE (no
synchronization) or any combination of: ALLOC, OPEN, CLOSE
and DEALLOC.
RD-EROPT Action to be taken by a reader when an error is distributed to it from
another participant:
IMMED Abend immediately.
DELAY Continue reading until there is nothing more to read
from the pipe, and then abend.
IGNORE Continue reading until there is nothing more to read from
the pipe, and then terminate normally.
WT-EROPT Action to be taken by a writer when an error is distributed to it from
another participant:
IMMED Abend immediately.
IGNORE Continue writing to the file and, if possible, to the pipe.
At the end of the process, terminate normally.
Pipe I/O Information
The following data is available only during I/O process.
BLKS-WT Total number of blocks written by all the writers.
BLKS-RD Total number of blocks read by all the readers.
LAST-ACT Time of last I/O operation.
BUFF# Number of buffers allocated for this pipe.
DSCLPOOL Name of the data space cell pool used to hold the pipe buffers.
MULTI-RD Number of times each block must be read before it can be freed. This
number is 1, unless there are several readers, and each reader gets all
the data. In this case, it is equal to the number of readers.
General Participant Information
The following blocks (General Participant Information and Participant I/O Information)
are repeated for each participant.
TYPE Participant type: READER or WRITER.
JOBNAME Job name.
PHASE Current phase of a pipe participant:
WAITALOC Waiting during allocation until all required
participants allocated the pipe (synchronization type
ALLOC was requested).
ALOCDONE After allocation.
DEFROPEN Open is requested and is deferred until the participant
performs its first I/O (because no writer has opened the
pipe yet).
WAITOPEN Waiting during open until all required participants
opened the pipe (synchronization type OPEN was
requested), or waiting for pipe initialization process to
complete.
OPENDONE After open.
IO#1DONE During I/O, after the first I/O operation.
DEFRCLOS Close was requested and is deferred until deallocation.
Reopen is allowed because an End-Of-File indication
was not already sent.
EOF-CLOS Writer has already sent EOF indication as part of its
close process.
WAITCLOS Waiting during close until all the required participants
closed the pipe (synchronization type CLOSE
was requested).
CLOSDONE After close.
EOF-DLOC Writer has already sent EOF indication as part of its
deallocation process.
WAITDALC Waiting during deallocation until all the required
participants deallocated the pipe (synchronization type
DEALLOC was requested).
DALCDONE After deallocation.
WAIT-TYP If the participant is waiting for any event, this field contains the wait
type (i.e., reason for waiting).
NONE Participant is not waiting.
ALOCSYNC Participant is waiting for Allocation synchronization.
OPENSYNC Participant is waiting for Open synchronization.
PIPEINIT Participant is waiting for pipe initialization.
SPECINIT Participant is waiting for connection initialization (it
joined the pipe when the pipe was already active).
IO-WAIT Participant is waiting for I/O (for a reader, the reader
tries to read a block but the pipe is empty; for a writer,
the writer tries to write a block but the pipe is full).
CLOSSYNC Participant is waiting for Close synchronization.
DALCSYNC Participant is waiting for Deallocation synchronization.
ERR-FLAG Participant error flags:
REJECTED Participant was unable to join the pipe for various reasons.
ERROR Participant encountered an error.
DIST-ERR An error was distributed from another participant.
IO-ERROR Participant encountered an I/O error.
STAT1 First status field.
TERM Participant terminated; participant will no longer
access the pipe.
AFT-EOF End-Of-File was already sent or received.
DEFROPEN Deferred open situation. Open process to be completed
before the first I/O.
RMT-PRT A remote participant. A participant which runs in a
different system than the Pipe Home System.
STAT2 Second status field. For future use.
FLAGS Indicator field. Possible values:
REOPEN Participant reopened the pipe.
RDR/WTR Information according to the participant type (reader or writer):
For Writer:
EOF-CLOS Participant should send EOF indication as part of close
process.
EOF-DALC Participant should send EOF indication as part of
deallocation process.
For Reader:
EOF-REQ Participant must wait for EOF before closing the pipe.
JOBID Participant job-ID (job number).
ASID Address space number (in decimal) in which the participant is running.
STEP-NUM Step number, within the job, that invokes the current program (i.e., application).
PROCSTEP Name of step that invokes the current JCL procedure.
PGMSTEP Name of step that invokes the current program (i.e., application).
DDNAME Name of DD statement used to allocate the pipe.
SYSTEM System name where the participant is running.
Participant I/O Information
The following data is available only during the I/O process.
BLK-CNT Total number of blocks written to, or read by, the participant.
WAIT-CNT Number of times the participant waited for I/O.
WAITP Type of wait when waiting. Possible values:
IO-WAIT Waiting for I/O.
LAST-ACT Time of last I/O operation.
Display Participant Information
The following command displays participant information:
F CTLMON,DISPLAY ASID=15
CTL136I ASID 00015
CTL136I ==========
CTL136I JOBNAME.... PRCRTRNS JOBID......JOB02946 STEP-NUM... 01
CTL136I PIPE: PROD.TRANS.FILE ID: 19293949
CTL136I ---------------------------------------------------------------
CTL136I TYPE....... WRITER LAST-ACT... 19:29:39 STAT.......RMT-PRT
CTL136I PHASE...... WAITOPEN PRT-FLG.... PIPE-FLG...
CTL136I STEP-NUM... 01 DDNAME..... TRAMS
CTL136I HOME-SYS... OS32 TIMESTMP... 1929394911930000
CTL136I IO-FLAG.... RQS-SENT
The displayed information is divided into two logical groups:
Information regarding the job running in this address space.
Specific information regarding each pipe which is currently accessed by this address
space.
Address Space Information
ASID Address space number (in decimal) in which the job is currently
executing.
JOBNAME Job name.
JOBID Job-ID (job number).
STEP-NUM Current step number within the job (if this step accesses the pipe), or the
number of the last step that accessed the pipe (if the current step does
not access the pipe).
Pipe Information
PIPE Pipe (dataset) name.
ID Unique pipe identifier. First 8 characters of the pipe time stamp (see
below).
TYPE Participant type: READER or WRITER.
LAST-ACT Time of last operation.
STAT Various indications. Valid values:
AFT-EOF End-Of-File was sent/received by this participant.
UNC-CLOS Close was performed following a previous error
(unconditional close).
DEFRCLOS Deferred close was performed.
UNC-DALC Deallocation was performed following a previous error
(unconditional deallocation).
RMT-PRT A remote participant. This participant runs in a
different system than the Pipe Home System.
OFI/DLY For a writer: the writer writes only to the physical file.
For a reader: the reader continues its process regardless
of an error in the pipe, but abends at the end of the
process.
IGN-ERR An error in the pipe was ignored by this participant.
PHASE Current phase of the pipe participant.
PRT-FLG Participant-related error indications, set by the Pipe Handler. One or
more of the following values can be indicated:
REJECT Participant was unable to join the pipe for various
reasons.
USRERROR Participant encountered an error.
INTABDON Pipe Handler abended this participant.
DISTABND Participant distributed its error to all other
participants. When they receive the error, they should
abend.
TIMEOUT Timeout expired, and the participant accepted that
indication.
PIPEIOE Pipe I/O Error status encountered.
PIPE-FLG Pipe-related error indications, set by the Pipe Handler. One or more of
the following values can be indicated:
PIPERROR Pipe is in error.
ABENDIMM Pipe is in error. All participants should immediately
abend.
ERRDIST Error was distributed from another participant.
TIMEOUT Timeout expired, and the participant should abend.
PIPEIOE Pipe I/O error occurred.
STEP-NUM Step number, within the job, in which the application is running.
DDNAME Name of DD statement that allocates the pipe.
HOME-SYS Pipe Home System (PHS) name.
TIMESTMP Unique identifier of a pipe. Its value is determined when the first
participant allocates the pipe.
IO-FLAG Relevant to remote participants only. Specifies the various stages of
processing an I/O operation using a Global pipe. Possible values:
RQS-SENT A request for I/O was sent to the PHS monitor.
RESP-RCV A response was received from the PHS monitor.
WAIT-LST Waiting for Sysplex List services to complete.
LST-COMP Sysplex List services completed.
RIO-DONE Remote I/O operation was performed.
RIO-ERR Remote I/O error was identified.
Display Parallel Job Information Summary
Sample Output
CTL173I JOB NAME JOB ID SYSTEM STATUS
CTL174I PRODTRN JOB13361 ESA1 ACTIVE
CTL174I PRODRPT JOB13348 OSR3 TERM
CTL175I NUMBER OF JOBS=0002
The display output contains:
A title line (CTL173I).
One line of general information (CTL174) for each job displayed.
A summary line (CTL175I) containing the total number of parallel jobs.
The following information is displayed:
JOB NAME Job name.
JOB ID Job ID (number).
SYSTEM System in which the job is/was executing.
STATUS Job status:
ACTIVE Job is currently running.
TERM Job has already finished running.
Display Parallel Job Information
Sample Output
CTL136I JOB: PRODRPT ID: JOB13891 SYSTEM: ESA1
CTL136I ================================================================
CTL136I STAT1...... EXECUTE JOBNAME.... PRODRPT
CTL136I JOBID...... JOB13891 ASID....... 49
CTL136I SYSTEM..... ESA1 LAST-STP... 07
CTL136I STEP NUMBER 001
CTL136I ===============
CTL136I STEP-NUM... 01 PGMSTEP.... DELFILE CMP-TYPE... CC
CTL136I CMP-CODE... 8 PHASE...... STEP-END
CTL136I STAT1...... AFT-RMGR PROGRAM.... IDCAMS
CTL136I PROCSTEP... SYSTEM..... ESA1
CTL136I ===============
CTL136I STEP-NUM... 02 PGMSTEP.... GORPTA CMP-TYPE... CC
CTL136I CMP-CODE... 0 PHASE...... AS-TERM
CTL136I STAT1...... TERM,PRL-STEP
CTL136I PROGRAM.... DOREPA PROCSTEP...
CTL136I SYSTEM..... ESA1
CTL136I ===============
CTL136I STEP-NUM... 03 PGMSTEP.... GORPTB
CTL136I CMP-TYPE... EXECUTE CMP-CODE... 0
CTL136I PHASE...... EXECUTE STAT1...... PRL-STEP
CTL136I PROGRAM.... DOREPB PROCSTEP...
CTL136I SYSTEM..... OSR3
The displayed information is divided into two logical groups:
Job information.
Step information for each job step.
Job Information
JOB Job Name.
ID Job ID number.
SYSTEM Name of MVS System where the job is/was running.
STAT1 Job Status:
EXECUTE Job is executing
ENDED Job Ended
ERROR Internal error situation
ABEND Severe internal error
ASID Address space number (in decimal) in which the job was running.
LAST-STP Number of last step of the job (i.e., number of steps in the job).
Step Information
STEP-NUM Step number.
PGMSTEP Name of step that invokes the current program.
CMP-TYPE Completion type for terminated steps, or step status for other steps.
PRE-EXEC Step not yet processed by CONTROL-M/WorkLoad.
EXECUTE Step is currently executing.
CC Step ended with a condition code (see CMP-CODE
below).
USR-ABND Step abended with the specified User Abend code (see
CMP-CODE below).
SYS-ABND Step abended with the specified System Abend code (see
CMP-CODE below).
JCL-ERR Step ended with a JCL error.
NOT-RUN Step was not run because of condition codes.
UNKNOWN Step ended with an unknown status.
NOT-STRT Parallel step did not start in its address space.
CMP-CODE Step completion code.
PHASE Current phase of step:
PRE-EXEC Step not yet processed CONTROL-M/WorkLoad.
EXECUTE Step is currently executing.
STEP-END Step ended.
AS-TERM Address space running a parallel step has terminated.
STP-ORG Step Organizer of the parallel step finished its process.
STAT1 Step Status:
PRL-STEP Step is a parallel step
RMT-STP Step will execute on a remote system.
TERM Step terminated.
AFT-RMGR Step processing was completed.
PROGRAM Name of program that is activated by the step
PROCSTEP Name of a step that invokes the current JCL procedure.
SYSTEM System name where the step is running.
Section 12: ECSGATE
CONTROL-M-to-ECSGATE Communications Dataset ..................................................... 12-1
Defining Applications .............................................................................................................. 12-1
Section 12: ECSGATE
IOA Rel. 5.1.4 Administrator Guide 121
CONTROL-M-to-ECSGATE Communications Dataset
To change the size of the CONTROL-M-to-ECSGATE Communication dataset, perform the
following steps:
1. Stop CONTROL-M and ECSGATE.
2. Change the communication dataset size definition (parameter M2GSIZE) in member
ECSPARM in the INSTECS library. Submit job ECSPARMJ using the ICE
CUSTOMIZE option.
3. Delete the old M2G dataset.
4. Edit member FORMM2G. Change parameter RECNUM in the JCL.
5. Submit the job as described in step 9.1, Format CONTROL-M to ECSGATE Com.
Dataset in Section 12 of the IOA Installation Guide.
6. Restart CONTROL-M and ECSGATE.
Defining Applications
Defining applications organizes data in the Active Jobs file so that the data can be more
easily comprehended and manipulated using the ENTERPRISE/CS GUI. This GUI enables
you to define applications for each job separately.
Application definition is optional. If you do not define applications, all groups are assigned
by default to application NO_APPL.
You can define or redefine applications during the installation procedure or at any time
after installation is complete. See step 6.4, Define Applications, in Section 12 of the IOA
Section 12: ECSGATE
Appendixes
Appendix A: IOA Application Program Names
Appendix B: Dataset Formatting Utilities for IOA Products
Appendix C: Modifying IOA Online Facility Commands
Appendix D: Logical Field Names for the CONTROL-T Repository
Appendix E: IOA Online Options Cross-Reference
Appendix F: IOAMEM Module
Appendix G: Customizing the CONTROL-M Status Screen
Appendix H: CONTROL-O Modify Commands
Index
IOA Rel. 5.1.4 Administrator Guide A 1
The following application program names are contained in IOA product tapes:
CTBIUTI CONTROL-B Utilities screen
CTBTABS CONTROL-B Active Balancing Environment screen
CTBTBAL CONTROL-B Balancing Mission Definition screen
CTBTDAT CONTROL-B Database Variables Definition screen
CTBTJBL CONTROL-B Rule Activity screen
CTBTRLB CONTROL-B Rule Definition screen
CTDIUTI CONTROL-D Utilities screen
CTDTAMS CONTROL-D Active Missions screen
CTDTATF CONTROL-D/PC File Transfer Status screen
CTDTDPC CONTROL-D File Transfer screen
CTDTMIS CONTROL-D/V Migration/Printing/Backup/Restore Mission
Definition screen
CTDTREP CONTROL-D Report Decollating/Indexing Definition screen
CTDTUSR CONTROL-D User Reports screen (Online Report Viewing)
CTDTUTR CONTROL-D Recipient Tree screen
CTMTDTM IOA Calendar screen
CTMTNRS IOA Manual Conditions screen
CTMTRES IOA Conditions/Resources screen
CTMTSCH CONTROL-M Online Scheduling
CTMTRCM CMEM Definition facility
CTMTSTA CONTROL-M Status screen
CTMTTSO IOA TSO Command Processor screen
CTOTARF CONTROL-O Rule Status screen
CTOTMSC CONTROL-O Message Statistics screen
CTOTOMP CONTROL-O Rule Definition screen
A 2 IOA Rel. 5.1.4 Administrator Guide
CTOTALO CONTROL-O Automation Log
CTOTAOP CONTROL-O Automation Options
CTTTRLD CONTROL-T Rule Definition screen
CTTTPLD CONTROL-T Pool Definition screen
CTTTVLD CONTROL-T Vault Definition screen
CTTTINQ CONTROL-T Inquire/Update screen
CTTTKIN CONTROL-T External Volume Check-In screen
IOATLOG IOA Log screen
IOATMNU IOA Primary Option menu
IOA Rel. 5.1.4 Administrator Guide B 1
Appendix B: Dataset Formatting Utilities for IOA
Products
The following JCL members can be used to create and format IOA product datasets:
1. IOA (in IOA INSTALL Library)
FORMDRES IOA Mirror (Dual) Conditions/Resources file.
FORMIOA Formats all IOA files.
FORMLOG IOA Log file.
FORMNRS IOA Manual Conditions file.
FORMRES IOA Conditions/Resources file.
2. CONTROL-M (in IOA INSTCTM Library)
FORMCKP CONTROL-M Active Jobs file and its backup file.
FORMCTM Formats all CONTROL-M files.
FORMDCKP CONTROL-M Mirror (Dual) Active Jobs file.
FORMG2M CONTROL-M Gateway Communications file.
FORMGRF CONTROL-M Dependencies file.
FORMSUB1 CONTROL-M CMEM file.
FORMSUB2 CONTROL-M CMEM file.
FORMSTT CONTROL-M Job Execution Statistics file.
3. CONTROL-D (in IOA INSTCTD Library)
FORMAMF CONTROL-D Active Missions file and its backup file.
FORMAS4 CONTROL-D MF/AS400 Transfer file.
FORMATF CONTROL-D Active Transfer file for CONTROL-D/PC.
FORMBTR CONTROL-D Bundle Tracking file.
FORMCAT Creates the IOA user catalog for CDAM files.
FORMCOM CONTROL-D Communication file.
FORMCTD Formats all CONTROL-D files.
FORMPGC File that saves the number of pages prepared for all print missions.
FORMUF1 Allocates and formats all CONTROL-D User Report files.
FORMUF2 Reformats all CONTROL-D User Report files without reallocating.
B 2 IOA Rel. 5.1.4 Administrator Guide
4. CONTROL-V (in IOA INSTCTV library)
FORMCTV Allocates and formats CONTROL-V Migration file.
FORMUF3 Allocates and formats CONTROL-V Migrated User Reports file.
FORMUF4 Formats CONTROL-V Migrated User Reports file without
reallocating.
5. CONTROL-O (in the IOA INSTCTO library)
DEFGLOB Allocates and formats Global Variables library and allocates a backup
file.
DEFSTAT Allocates and formats Message Statistics file.
DEFALO Allocates and formats Automation Log file.
6. CONTROL-T (in IOA INSTCTT library)
CTTCMDB Allocates and formats CONTROL-T Media Database (MDB) file.
CTTCSTK Allocates and formats CONTROL-T Stacking Database
CTTCTRC Allocates and formats CONTROL-T Trace file.
7. Enterprise Controlstation (in IOA INSTECS library)
FORMM2G Allocates and formats CONTROL-M/ECSGATE Communications file.
Appendix C: Modifying IOA Online Facility Commands
IOA Rel. 5.1.4 Administrator Guide C 1
Appendix C: Modifying IOA Online Facility
Commands
Every screen of the IOA Online facility supports a set of commands. It is possible to change
the names of these commands or to create synonyms. The commands reside in the IOA
PARM library in members with the following naming conventions:
TxxxCMD1 The active commands member.
TxxxCMDD Debugging aid member contains additional commands for problem
analysis.
xxx is the screen identifier. For a detailed description of how to modify a command
member, refer to the Section 2 of this guide.
A command member is composed of one header line and any number of command lines. The
number at the left of the header line is the total number of command lines in the member.
It must be updated when lines from the command member are added or deleted.
The structure of the command line is as follows:
Column Description
1-8 Command name.
25-28 Reserved hexadecimal (unprintable) value. Do not change it.
29-68 Description of the command.
69-72 Reserved hexadecimal (unprintable) value the internal command
member. Do not change it.
It is possible to change the command name and/or description. To add a synonym,
duplicate the command line, modify the command name on the duplicated line and modify
the command line counter at the left side of the header line.
Every screen of the IOA Online facility has a set of PFKeys with pre-assigned commands.
It is possible to change these PFKey definitions. The PFKey assignments reside in the IOA
PARMCMD library in members with the following naming convention:
TxxxPF1 xxx is the screen identifier.
A PFKey member is composed of one header line and any number of PFKey definition
lines.
The structure of the PKFey definition line is as follows:
Column Description
1-8 The PFKey or <ENTER>.
9-22 Command assigned to the PFKey.
At least one PFKey/Enter key must be defined as the <ENTER> command.
C 2 IOA Rel. 5.1.4 Administrator Guide
IOA Rel. 5.1.4 Administrator Guide D 1
Appendix D: Logical Field Names for the CONTROL-T
Repository
The tables in the following pages list fields that can be:
Specified in utility INCLUDE/EXCLUDE statements to determine which records are
processed when the utility runs. For a complete explanation of INCLUDE/EXCLUDE
statements, see Record Selection Logic (INCLUDE/EXCLUDE Statements) at the
beginning of the CONTROL-T utility descriptions in Section 9 of this guide.
Manually updated in the Media Database via utility CTTMUP.
Included in utility-generated reports.
The following pages contain a series of tables which specify field names according to record
type. Each table contains the following data for each field:
External Name Field name as specified by the user.
Valid Values Either of two types of data:
Keyword
value
Specific valid values. Shown in uppercase (e.g., CYCLE,
DATE, JCL). Non-trivial values are accompanied by a
description in the Description column of the table.
Value type Shown in lowercase (e.g., char, integer, date). These are
described below. If relevant, the maximum length of the
value is displayed in parentheses next to the value type.
Description Brief description of the field. This column also contains a description
of any specific values specified in the Valid Values column.
Internal Name Name used in the macro to reference the field.
Below is a brief description of the value types that can be specified in the Valid Values column:
char Free character format. Maximum length indicated in parentheses. The
specified character string may include masking characters. For more
information about masking characters, see Character Masking in
Section 2 of the CONTROL-T User Manual.
hex Hexadecimal character format (valid characters: 0-9, A-F). Maximum
length indicated in parentheses.
D 2 IOA Rel. 5.1.4 Administrator Guide
date Valid formats are: yymmdd or yyyymmdd. The following keywords are
also valid:
%CDAY Current day (today).
%PDAY Previous day (yesterday).
%NDAY Next day (tomorrow).
%PWEEK Previous week.
%NWEEK Next week.
%PMONTH Previous month (30 days).
%NMONTH Next month (30 days).
time Valid format is hhmmss.
julian date Valid formats are yyddd or yyyyddd. Special values (e.g., 98000,
99000) are also supported.
integer Numeric value.
date/integer Either a date value or an integer value (as described above) can be
specified. Date values should be prefixed by D (e.g., format
Dyyyymmdd). Integer values should be prefixed by I (e.g., I35). By
default (i.e., if no prefix is specified), the value is assumed to be a date.
Table 1: Keywords to Be Used With Dataset Type Records
EXTERNAL
NAME
VALID
VALUES DESCRIPTION
INTERNAL
NAME
ACCOUNT char (50) Jobs accounting information DDSACCT
BLKSIZE
integer
Datasets block size DDSBLK
BLOCKCT integer Block count DDSBLKC
CRECC char (4) Condition code of creating step DDSCCC
CRECPU char (4) CPU in which dataset was created DDSCCPU
CREDDN char (8) Creating DD name DDSCDDN
CREDT date Creation date DDSCDT
CREJBN char (8) Creating job name DDSCJBN
CREJOBID char (8) Creating job ID (format
JOBxxxxx)
DDSCJID
CREPGM char (8) Creating program name DDSCPGM
CRESTEP char (8) Creating step name DDSCSTP
EXTERNAL
NAME
VALID
VALUES DESCRIPTION
INTERNAL
NAME
CRETM time Creation time DDSCTM
CREUAD hex (4) Unit address on which the dataset
was created
DDSCUAD
CREUSER char (8) User ID which created the dataset DDSCUSER
DCHANGED date Last change date DDSMDT
DCHANGET time Last change time DDSMTM
DCHANGEU char (8) Last user ID that changed the
entry
DDSLUSER
DENSITY BPI200 BPI556
BPI800 BPI1600
BPI6250 BPI38000
BPI38KE BPI3590
Density of the data on the volume DDSDEN
DSENDSZE integer Ending size in kilobytes on the
volume
DDSECSZE
DSEXCP integer EXCP count since dataset was
created
DDSEXCP#
DSEXPDT date/integer Datasets expiration date, number
of cycles or number of days
according to DSEXPTYP
DDSEXPD1
DSEXPTYP
CYCLE
DATE
EDM
LACCS
CATALOG
PERM
VLTRET
SMS
Datasets expiration type:
Number of cycles
Actual date
EDM controlled
Number of days since last
accessed
MVS Catalog Control
Permanent dataset
Controlled by vaulting
Controlled by SMS Management
Class
DDSEXPT1
EXTERNAL
NAME
VALID
VALUES DESCRIPTION
INTERNAL
NAME
DSCSIZE integer Compressed size in kilobytes DDSCSIZE
DSFLAGS
1
DISPMOD
DYNDEF
RECREATE
MANUPDAT
JCLRETPD
DELRTM
DSRSTRT
Dataset flag byte:
Dataset opened with DISP=MOD
Dataset dynamically defined
Dataset recreated
Dataset manually updated
(Online/Utility CTTMUP)
RETPD specified in the JCL for the
dataset
Dataset marked to be deleted by
CTTRTM
Dataset processed under MVS
RESTART
DDSFLG1
DSLABEL integer Dataset label number DDSLBLNM
DSNAME char (44) Dataset name DDSDSN
DSPOS hex (4) Block ID of current dataset
Header1 block
DDSPOS
DSSTAT
2
DACTIVE
DINUSE
DPENDSCR
DSCRATCH
DSTACKED
DEDM
DABEND
DNSTK
Dataset status:
Active dataset
In-use dataset
Pending scratch dataset
Scratched dataset
Stacked dataset
EDM controlled dataset
Closed under abend dataset
Unstackable dataset
DDSSTAT
DSTKGRP char(8) Dataset Stacking Group DDSSTKG
DSUSECT integer Dataset usage count DDSUSED#
1
This field can be used normally in INCLUDE/EXCLUDE statements of a report. This field cannot be used in
FIELDS and/or SORTBY statements of a report. Fields DSSTAT and DSTATX can be used instead. See
Special Fields in utility CTTRPT in Section 9 of this guide
2
This field has a special meaning when used in FIELDS and/or SORTBY statements of a report. See Special
Fields in utility CTTRPT in Section 9 of this guide.
EXTERNAL
NAME
VALID
VALUES DESCRIPTION
INTERNAL
NAME
DSVOLSER char (6) Datasets first volume DDSVOLSR
DUSRDATA char (20) User data DDSUSER2
JCLEXPDT Julian date JCL EXPDT value DDSJEXPD
LASTACCS C, R, W Last access type (create, read,
write)
DDSLACS
LRECL integer Dataset logical record length DDSRECL
RBA hex(6) Records RBA DDSRBA
READCPU char (4) CPU in which dataset was last
read
DDSRCPU
READDDN char (8) Last read DD name DDSRDDN
READDT date Last read date DDSRDT
READJBN char (8) Name of the last job which read
the dataset
DDSRJBN
READPGM char (8) Name of last program which read
the dataset
DDSRPGM
READSTEP char (8) Name of the last step which read
the dataset
DDSRSTP
READTM time Last read time DDSRTM
READUAD hex (4) Unit address on which the dataset
was last read
DDSRUAD
RECFM U, F, FB, FBA,
FBM, FBS, V, VB,
VS, VBA, VBM,
VBS, D
Datasets record format DDSRECFM
RTNFROM
DEFAULT
JCL
RULE
SMS
SMSDFLT
SMSLIMIT
SMSJCL
Dataset Retention origin:
From CTTPARM
From JCL
From CONTROL-T rules
From SMS Management Class
From SMS default
From SMS limit
From SMS JCL
DDSRTORG
SMSMC char (8) SMS Management Class DDSSMCL
EXTERNAL
NAME
VALID
VALUES DESCRIPTION
INTERNAL
NAME
TRTCH COMP, NOCOMP Indication of whether or not the
data is compressed (e.g., IDRC)
DDSTRTCH
VOLSNUM integer Number of volumes on which the
dataset resides (multi-volume
dataset)
DDSVOLS#
WRITECCC char (4) Condition code of the last step
which wrote to the dataset
DDSWCC
WRITECPU char (4) CPU in which the dataset was
last written
DDSWCPU
WRITEDDN char (8) Last write DD name DDSWDDN
WRITEDT date Last write date DDSWDT
WRITEJBN char (8) Name of the last job which wrote
to the dataset
DDSWJBN
WRITEPGM char (8) Name of last program which
wrote to the dataset
DDSWPGM
WRITESTP char (8) Name of the last step which wrote
to the dataset
DDSWSTP
WRITETM time Last write time DDSWTM
WRITEUAD hex (4) Unit address on which the dataset
was last written
DDSWUAD
Table 2: Keywords to Be Used With Volume Type Records
EXTERNAL
NAME
VALID
VALUES DESCRIPTION
INTERNAL
NAME
ACTIVEDS integer Number of active datasets DVLACTD#
BOXID char (6) Box ID DVLBOXID
CHKINDT date Check-in date DVLFCDT
CLNCOUNT integer Volumes Clean Count DVLCLN#
EXPDSNUM integer Expiration dataset number DVLEXPDS
EXPRTRN date Expected return date from out
location
DVLRTRN
FIRSTVOL char (6) First volser for multi-volume
chains
DVLFIRST
IOERPRM integer Read permanent errors count DVLRPER
EXTERNAL
NAME
VALID
VALUES DESCRIPTION
INTERNAL
NAME
IOERPRMC integer Read permanent errors count
since last clean
DVLRPERC
IOERTMP integer Read temporary errors count DVLRTER
IOERTMPC integer Read temporary errors count since
last clean
DVLRTERC
IOEWPRM integer Write permanent errors count DVLWPER
IOEWPRMC integer Write permanent errors count
since last clean
DVLWPERC
IOEWTMP integer Write temporary errors count DVLWTER
IOEWTMPC integer Write temporary errors count
since last clean
DVLWTERC
LACCDT date Date of last volume access DVLADT
LACCJBN char (8) Name of last job which accessed
the volume
DVLJBN
LACCTM time Time of last volume access DVLATM
LBLNUM integer Last label number on the volume DVLLBLNM
LBLTYP SL, NL, NSL, SUL,
AL, AUL, BLP
Label type DVLLTYP
LCLNDT date Last clean date DVLCLN
LDSCSIZE integer Compressed size in kilobytes of
the last dataset on the volume
DVLLDCSZ
LDSPOS hex (4) Block ID of the last dataset
starting on this tape
DVLPOSLD
LDSPOSLB integer Label number for LDSPOS
(above)
DVLPOSLB
LOCATION char (8) Current location of the volume DVLCODE
LOCSEQ integer Vault sequence number DVLVTSQ
MEDIA char (8) Volumes media type DVLMEDIA
MOVEDATE date Last move date DVLMVDT
NEXTVOL char (6) Next volser for multi-volume
chains
DVLNEXT
PREVVOL char (6) Previous volser for multi-volume
chains
DVLPREV
RBA hex (6) Records RBA DVLRBA
RECFROM char (8) Vault name from which the
volume recalled
DVLVLTRC
EXTERNAL
NAME
VALID
VALUES DESCRIPTION
INTERNAL
NAME
RECVLNUM integer Vault number (in pattern) from
which the volume recalled
DVLVLTI
VFREEKB integer Available kilobytes on the volume DVLFREE
RETVLTDT date Return to vault date DVLVRTRN
SCRDT date Last volume scratch date DVLSCRDT
SLNAME char (6) Volumes SL-NAME DVLSLNAME
SLOTNUM integer Vault slot number DVLVSLOT
UNITNAME char (8) Volumes unit name DVLUNAM
USERDATA char (20) User data DVLUSER2
VAULT char (8) Vault name in vault info DVLVLTNM
VCHANGED date Last change date DVLMDT
VCHANGET time Last change time DVLMTM
VCHANGEU char (8) Last user ID that changed the
entry
DVLUSER
VDENSITY BPI200
BPI556
BPI800
BPI1600
BPI6250 BPI38000
BPI38KE BPI3590
Density of the data on the volume DVLDEN
VENDOR char (8) Name of vendor who
manufactured the volume
DVLVNDOR
VLTDSNUM integer Vaulting dataset number DVLVLTDS
VLTENTDT date Entry date to the vault DVLVENDT
VLTENTNM integer Number of vault entries for the
volume
DVLVLTT
VLTEXPDT date/integer Vault expiration date, number of
cycles or number of days
DVLVXPD1
EXTERNAL
NAME
VALID
VALUES DESCRIPTION
INTERNAL
NAME
VLTEXTYP
VCYC
VDATE
VLACC
VCAT
VPERM
VEXP
VDAYS
Vault expiration type:
Number of cycles
Actual date (in yyyymmdd format)
Number of days since last access
MVS Catalog Control
Permanent
Until volume expiration
Number of days in vault
DVLVXPT1
VLTPREFL integer Vaulting dataset name prefix
length
DVLPRFLN
VOLEDMID char (4) EDM-ID for EDM controlled
volumes
DVLEDMID
VOLEXCP integer EXCP count since last scratched DVLEXCP#
VOLEXPDT date Expiration date DVLEXPD
VOLEXPTY DATE, PERM,
UNKNOWN
Expiration date type DVLEXPT
VUSEDKB integer Kilobytes used on the volume DVLUSED
EXTERNAL
NAME
VALID
VALUES DESCRIPTION
INTERNAL
NAME
VOLFLAGS
3
RETURNVL
DYNDEF
MANUPDAT
VLRSTRT
EXTDEL
MANVLT
SNGLVOL
INROBOT
Additional volume status flags:
Volume returned from vault
Volume dynamically defined
Volume manually updated
(Online/Utility CTTMUP)
Volume processed under MVS
RESTART
Volume is deleted when expired
Volume manually moved to vault
Single volume (out of multi-vol
group) in VAULT/RECALL
Volume resides in a robot
DVLFLG1
VOLFLAG2
3
VLTBYBOX
Additional status flag:
Volume can be vaulted by boxes
DVLFLG2
VOLIND
3
PVLT
PENDVLT
RECALL
HOLD
NOSTACK
INUSE
Additional volume status
indications:
Potential vault
Pending vault
Recalled back from a vault
Hold before return to vault
Stacked datasets not accepted
Volume is in-use
DVLSTA2
VOLODESC char (20) Volumes description DVLDESC
VOLOWNER char (8) Volumes owner DVLOWNR
VOLSEQ integer Volume sequence number DVLVSEQ
3
These fields can be used normally in INCLUDE/EXCLUDE statements of a report. These fields cannot be
used in FIELDS and/or SORTBY statements of a report. Fields VOLSTAT and VSTATX can be used instead.
See Special Fields in utility CTTRPT in Section 9 of this guide.
EXTERNAL
NAME
VALID
VALUES DESCRIPTION
INTERNAL
NAME
VOLSER char (6) Volume serial number DVLVOLSR
VOLSTAT
4
ACTIVE
SCRATCH
PENDSCR
OUT
VAULTED
EXTERNAL
EDM
DELETED
Status of volume:
Active
Scratch
Pending scratch
Out of library (but not vaulted)
Vaulted
External volume
EDM controlled volume
Deleted volume
DVLSTAT
VOLUSECT integer Volume usage count from last
scratch
DVLUSED#
VSTKGRP char (8) Volume Stacking Group DVLSTKG
VTRTCH COMP
NOCOMP
Indicates whether or not data is
compressed (e.g., IDRC)
DVLTRTCH
4
This field has a special meaning when used in FIELDS and/or SORTBY statements of a report. See Special
Fields in utility CTTRPT in Section 9 of this guide
Table 3: Keywords to Be Used With Stacking Type Records
EXTERNAL
NAME
VALID
VALUES DESCRIPTION
INTERNAL
NAME
SDENSITY BPI200
BPI556
BPI800
BPI1600
BPI6250
BPI38000
BPI38KE
BPI3590
Density of the data on the
volume
STUDDEN
STKBLKCT integer Datasets block count STUDBLC
STKBLKSZ integer Datasets block size STUDBLKS
STKCOMPF integer Stacking compression factor STUDCMPF
STKDATE date Creation date STUDDTE
STKDSN char (44) Dataset name for which
stacking statistics are kept
STUDDSN
STKIND NOSTK Indication whether or not the
dataset can be stacked
STUFLAG1
STKJBN char (8) Job name by which stacking
statistics are kept for the
dataset
STUDJOB
STKPGM char (8) Name of the program which
created the stacked dataset
STUDPGM
STKTIME time Creation time STUDTME
STKUNIT hex (4) Unit name used to create the
dataset
STUDUNIT
STKVOL1 char (6) First volume in the group of
volumes
STUDVOL
STRTCH COMP
NOCOMP
Indicates whether or not data
is compressed (e.g., IDRC)
STUDRTCH
Table 4: Keywords to Be Used With Trace Type Records
EXTERNAL
NAME
VALID
VALUES DESCRIPTION
INTERNAL
NAME
CPUID char (4) CPU-ID ARCCPUID
DATE date Date ARCDATE
ENV DLD5
EDM
MUP
ONL
ONLC
RTM
STK
SVCT
UTL
VTM
$RCV
CTTDLD utility
External Data Manager
Manual update utility
(CTTMUP)
Online facility
External Volume Check-In
(TC Screen)
Retention management
utility (CTTRTM).
Dynamic Stacking Facility
Real-time environment
Volume expiration utility
Vault management utility
(CTTVTM)
Utility CTTRCV Recover
Media Database using Trace
file
ARCIDENT
FUNCTION ADD, DELETE,
CHANGE
Activity type ARCTYPE
JOBID char (8) Job ID (format JOBxxxxx) ARCJOBID
TIME time Time ARCTIME
JOBNAME char (8) User ID/Job name ARCUSRID
Table 5: Keywords to Be Used With Trace Data
EXTERNAL
NAME
VALID
VALUES DESCRIPTION
INTERNAL
NAME
RECTYPE V, D MDB Record Type DVLRTYPE,
DDSRTYPE
VOLSER char (6) Volume serial number DVLVOLSR
DSNAME char (44) Dataset name DDSDSN
RBA hex (6) Records RBA DVLRBA,
DDSRBA
Table 6: Keywords for Selecting SMF Records to be
Processed by Utility CTTSCA
EXTERNAL
NAME
VALID
VALUES DESCRIPTION
INTERNAL
NAME
CPUID char (4) CPU ID SCACPUID
JOBNAME char (8) Job name SCAJBNAM
DSNAME char (44) Dataset name SCADSNAM
DATE date Dataset creation date SCADATE
TIME time Dataset creation time SCATIME
Table 7: Keywords to be used with Stacking Statistics
Records for Utility CTTSTKR or CTTMUP
EXTERNAL
NAME
VALID
VALUES DESCRIPTION
INTERNAL
NAME
AVGSIZE integer Average dataset size in
kilobytes (compressed)
STKAVCSZ
AVGSIZEU integer Average dataset size in
kilobytes (uncompressed)
STKAVUSZ
DENSITY BPI200
BPI556
BPI800
BPI1600
BPI6250
BPI38000
BPI38KE
BPI3590
Dataset density STKDEN
DSNAME char (44) Dataset name STKDSN
JOBNAME char (8) Job name STKJBN
LIFEOBS integer Total number of observations
of the dataset (including
observations not used to
calculate dataset statistics)
This field is relevant only for
datasets with non-specific
retention (e.g., CATALOG or
LAST ACCESS)
STKLSOBS
LIFESPAN integer Average life span of the
dataset in days
This field is relevant only for
datasets with non-specific
retention (e.g., CATALOG or
LAST ACCESS)
STKLSPAN
MAXSIZE integer Maximum dataset size in
STKMAXCS
MINSIZE integer Minimum dataset size in
STKMINCS
EXTERNAL
NAME
VALID
VALUES DESCRIPTION
INTERNAL
NAME
OBSERVE integer Number of observations of
the dataset which were used
to determine dataset
statistics
STKOBS
PREDICTD integer Predicted dataset size in
STKPREDC
PREDICTU integer Predicted dataset size in
kilobytes (uncompressed)
STKPREDU
STATUS STK
NOSTK
Indication whether or not the
dataset can be stacked
STKFLAG1
STDDEV integer Standard deviation (in
kilobytes) of dataset size for
all observations
STKSTDEV
TOTSIZQ integer Square of accumulated length
of all dataset observations in
kilobytes
STKTOTSQ
UNIT char (8) Unit name STKUNAM
IOA Rel. 5.1.4 Administrator Guide E 1
IOA
Option Screen
Title
Module/
CSECT
Screen
Member
Format
Member
PFKey
Member
Command
Member
Help
Member
1 IOA Primary
Option Menu
IOATMNU $$MNU TMNUPF3 TMNUCMD3 CTMHMNU*
4 IOA
Conditions/
Resources
CTMTRES CTMSRES TRESPF1 TMNUCMD3 CTMHMNU*
5 IOA LOG
file
IOATLOG $$LOG TLOGPF1 TLOGCMD1 CTMHLOG
6 TSO TSO
command
CTMTTSO CTMSTSO TTSOPF1 TTSOCMD1 CTMHTSO
6
1
ISPF
Utilities
IOAIUTI
7 IOA Manual
Conditions
CTMTNRS CTMSNRS TNRSPF1 TNRSCMD1 CTMHNRS
8 IOA
Calendar
Facility
(Entry
Panel)
CTMTDTM CTMSDTM TDTMPF1 TDTMCMD1 CTMHDTM
8.D List of
Calendars
CTMTDTM CTMSDTD TDTMPF1 TDTMCMD1 CTMHDT2
8.D List of Years CTMTDTM CTMSDTD TDTMPF3 TDTMCMD1 CTMHDT3
8.Y Calendar
Definition
CTMTYER CTMSYER TDTMPF4 TDTMCMD1 CTMHYER
1
A separate ISPF panel cross-reference appears later in this section.
E 2 IOA Rel. 5.1.4 Administrator Guide
CONTROL-M
Option Screen Title
Module/
CSECT
Screen
Member
Format
Member
PFKey
Member
Command
Member
Help
Member
2 Scheduling
Definition
Entry Panel
CTMTSCH CTMSSCH TSCHPF1 TSCHCMD1 CTMHSCH
2 Table List CTMTSCH CTMSDIR TSCHPF3 TSCHCMD1 CTMHSC2
2 Job List CTMTSCH CTMSDIR TSCHPF3 TSCHCMD1 CTMHSC3
2.0 Job Order
Messages
CTMTJOB CTMSJOB TJOBPF1 TJOBCMD1 CTMHJOB
2.G Graphic Job
Flow
CTMRFLW CTMSFLW TGRFPF1 TGRFCMD1 CTMHGRF
2.P Job
Scheduling
Plan
CTMTRPL $$RPL TRPLPF1 TRPLCMD1 CTMHRPL
2 Job
Definition
Screen
CTMTZUM CTMSZUM TZUMCMD1 TZUMCMD1 CTMHZUM
2 Group
Definition
Screen
CTMTGZM CTMSGZM TGZMPF1 TGZMCMD1 CTMHGZM
3 Active
Environment
CTMTSTA CTMSSTA TSTAPF1 TSTACMD1 CTMHSTA
3.Z Job Zoom
Screen
CTMTSZM CTMSSZM TSZMPF1 TSZMCMD1 CTMHSZM
3.N Jobs NET
Display
CTMTNET $$NET TNETPF1 TNETCMD1 CTMHNET
3.? Jobs WHY
Screen
CTMTNET $$NET TNETPF1 TNETCMD1 CTMHNET
3.S Jobs
Statistics
CTMTVST CTMTVST TVSTPF1 TVSTCMD1 CTMHVST
3.V Jobs View
SYSOUT
CTMTSYV $$AJH
$$AJA
TAJHPF1 TAJHCMD1 CTMHAJH
3.V.S Jobs SYSOUT
Viewing
IOATOLV CTMSSYV TSYVPF1 TSYVCMD1 CTMHSYV
3.VIEW Jobs GROUP
DISPLAY
CTMTVEW CTMSVEW TVEWPF1 TVEWCMD1 CTMHVEW
C CMEM Entry
Panel
CTMTRCM CTMSRCM TRCMPF1 TRCMCMD1 CTMHRCM
C Tables/Rules
of Library
CTMTRCM CTMSRDR TRCMPF3 TRCMCMD1 CTMHCM2
C Rules of
Tables in
Library
CTMTRCM CTMSRDR TRCMPF3 TRCMCMD1 CTMHCM3
C Rule
Definition
Screen
CTOTRUL CTOSRUL TRULPF1 TRULCMD1 CTMHRUL
CONTROL-D
Option Screen Title
Module/
CSECT
Screen
Member
Format
Member
PFKey
Member
Command
Member
Help
Member
A Mission
Status
Screen
CTDTAMS CTDSAMS TAMSPF1 TAMSCMD1 CTDHAMS
A.Z Zoom
Decollating
Mission
Definition
Screen
CTDTDEC CTDSDEC TDECPF1 TDECCMD1 CTDHDEC
A.Z Zoom
Printing
Mission
Definition
Screen
CTDTAPR CTDSAPR TAPRPF1 TAPRCMD1 CTDHAPR
A.Z Zoom Restore
Mission
Definition
Screen
CTDTARS CTDSARS TARSPF1 TARSCMD1 CTDHARS
A.Z Zoom Backup
Mission
Definition
Screen
CTDTABK CTDSABK TABKPF1 TABKCMD1 CTDHABK
A.L LOG messages IOATLOG $$LOG TLOGPF1 TLOGCMD1 CTMHLOG
A.P Print Plan
Screen
CTDTPMM CTDSPMM TPMMPF1 TPMMCMD1 CTDHPMM
A.? WHY Screen CTDTDWY CTDSDWY TDWYPF1 TDWYCMD1 CTDHDWY
R Report
Decollating
Mission
Definition
Entry Panel
CTDTREP CTDSREP TREPPF1 TREPCMD1 CTDHREP
R Job List CTDTREP CTDSDIR TREPPF3 TREPCMD1 CTDHRE2
R Categories of
Library
CTDTREP CTDSDIR TREPPF3 TREPCMD1 CTDHRE3
R Report
Decollation
Mission
Definition
Screen
CTDTCAT CTDSCAT TCATPF1 TCATCMD1 CTDHCAT
R.O Order
Decollation
Mission
Screen
CTMTJOB CTDSCAM TCAMPF1 TCAMCMD1 CTDHCAM
M Mission
Definition
Entry Panel
CTDTMIS CTDSMIS TMISPF1 TMISCMD1 CTDHMIS
M Mission List CTDTMIS CTDSMSD TMISPF3 TMISCMD1 CTDHMI2
Option Screen Title
Module/
CSECT
Screen
Member
Format
Member
PFKey
Member
Command
Member
Help
Member
M Category List CTDTMIS CTDSMSD TMISPF3 TMISCMD1 CTDHMI3
M Print Mission
Definition
Screen
CTDTPRT CTDSPRT TPRTPF1 TPRTCMD1 CTDHPRT
M Backup
Mission
Definition
Screen
CTDTBKP CTDSBKP TBKPPF1 TBKPCMD1 CTDHBKP
M Restore
Mission
Definition
Screen
CTDTRST CTDSRST TRSTPF1 TRSTCMD1 CTDHRST
M.O Mission
Order
CTMTJOB CTDSMIM TMIMPF1 TMIMCMD1 CTDHMIM
F PC Packet
Status
CTDTATF CTDSATF TATFPF1 TATFCMD1 CTDHATF
F.Z Packet Zoom
Screen
CTDTZTF CTDSZTF TDECPF1 TDECCMD1 CTDHZTF
F.I Packet Index
Screen
CTDTITF CTDSITF TITFPF1 TITFCMD1 CTDHITF
U User Reports
Entry Panel
CTDTUSR $$USR TUSRPF1 TUSRCMD1 CTDHUSR
U User Report
Lists
CTDTUSR $$FRM TUSRPF2 TUSRCMD2 CTDHUS2
U.N General
Notepad
Screen
CTDTNTP CTDSNTP
U.P Print Report CTDTUSR $$FRM CTDHUSI
U.V Report
Viewing
IOATOLV CTDSOLV TOLVPF1 TOLVCMD1 CTDHOLV
U.V Tag Notepad
Screen
CTDTNTP CTDSNTP
U.E Report
Editing
Screen
CTDTEXT CTDSEXT TOLVPF2 TOLVCMD1 CTDHEXT
U.E.1 Edit Report
Lines and
Columns
CTDTLNF CTDSLNF TOLVPF3 TOLVCMD1 CTDHLNF
U.E.1.C Edit Report
Columns
CTDTCLF CTDSCLF TOLVPF5 TOLVCMD1 CTDHCLF
U.E.2 Include Lines
Based on
Strings
CTDTINC CTDSINC TOLVPF4 TOLVCMD1 CTDHINC
Option Screen Title
Module/
CSECT
Screen
Member
Format
Member
PFKey
Member
Command
Member
Help
Member
U.E.3 Exclude
Lines Based
on Strings
CTDTEXC CTDSEXC TOLVPF4 TOLVCMD1 CTDHINC
U.E.4 Color Lines
Based on
Strings
CTDTCOL CTDSCLR TOLVPF4 TOLVCMD1 CTDHCLR
T Recipient
Tree Entry
Panel
CTDTUTR CTDSUTR TUTRPF1 TUTRCMD1 CTDHUTR
T CONTROL-D
Recipient
Tree
CTDTUTR CTDSUTR TUTRPF2 TUTRCMD1 CTDHUT2
T CONTROL-D
CHECK TREE
Messages
CTMTJOB CTDSTRM TTRMPF1 TTRMCMD1 CTDHTRM
T.S CONTROL-D
Recipient
Definition
CTDTRCP CTDSRCP TRCPPF1 TRCPCMD1 CTDHRCP
CONTROL-V
Option Screen Title
Module/
CSECT
Screen
Member
Format
Member
PFKey
Member
Command
Member
Help
Member
A Mission
Status
CTDTAMS CTDSAMS TAMSPF1 TAMSCMD1 CTVHAMS
A.Z Zoom
Decollating
Mission
Definition
CTDTDEC CTDSDEC TDECPF1 TDECCMD1 CTVHDEC
A.Z Zoom
Printing
Mission
Definition
CTDTAPR CTDSAPR TAPRPF1 TAPRCMD1 CTVHAPR
A.Z Zoom Restore
Mission
Definition
CTDTARS CTDSARS TARSPF1 TARSCMD1 CTVHARS
A.Z Zoom Backup
Mission
Definition
CTDTABK CTDSABK TABKPF1 TABKCMD1 CTVHABK
A.Z Zoom
Migration
Mission
Definition
CTDTABK CTDSABK TABKPF1 TABKCMD1 CTVHAMG
A.L LOG
Messages
IOATLOG $$LOG TLOGPF1 TLOGCMD1 CTMHLOG
A.P Print Plan
Screen
CTDTPMM CTDSPMM TPMMPF1 TPMMCMD1 CTVHPMM
A.? WHY Screen CTDTDWY CTDSDWY TDWYPF1 TDWYCMD1 CTVHDWY
R Report
Decollating
Mission
Definition
Entry Panel
CTDTREP CTDSREP TREPPF1 TREPCMD1 CTVHREP
R Job List CTDTREP CTDSDIR TREPPF3 TREPCMD1 CTVHRE2
R Categories of
Library
CTDTREP CTDSDIR TREPPF3 TREPCMD1 CTVHRE3
R Report
Decollation
Mission
Definition
Screen
CTDTCAT CTDSCAT TCATPF1 TCATCMD1 CTVHCAT
R.O Order
Decollation
Mission
CTMTJOB CTDSCAM TCAMPF1 TCAMCMD1 CTVHCAM
M Mission
Definition
Entry Panel
CTDTMIS CTDSMIS TMISPF1 TMISCMD1 CTVHMIS
M Mission List CTDTMIS CTDSMSD TMISPF3 TMISCMD1 CTVHMI2
M Category List CTDTMIS CTDSMSD TMISPF3 TMISCMD1 CTVHMI3
M Print Mission
Definition
Screen
CTDTPRT CTDSPRT TPRTPF1 TPRTCMD1 CTVHPRT
Option Screen Title
Module/
CSECT
Screen
Member
Format
Member
PFKey
Member
Command
Member
Help
Member
M Backup
mission
Definition
Screen
CTDTBKP CTDSBKP TBKPPF1 TBKPCMD1 CTVHBKP
M Migration
mission
Definition
Screen
CTDTBKP CTDSBKP TBKPPF1 TBKPCMD1 CTVHMIG
M Restore
Mission
Definition
Screen
CTDTRST CTDSRST TRSTPF1 TRSTCMD1 CTVHRST
M.O Mission
Order
CTMTJOB CTDSMIM TMIMPF1 TMIMCMD1 CTVHMIM
F PC Packet
Status
CTDTATF CTDSATF TATFPF1 TATFCMD1 CTVHATF
F.Z Packet Zoom
Screen
CTDTZTF CTDSZTF TDECPF1 TDECCMD1 CTVHZTF
F.I Packet Index
Screen
CTDTITF CTDSITF TITFPF1 TITFCMD1 CTVHITF
U User Reports
Entry Panel
CTDTUSR $$USR TUSRPF1 TUSRCMD1 CTVHUSR
U User Report
Lists
CTDTUSR $$FRM TUSRPF2 TUSRCMD2 CTVHUS2
U.N General
Notepad
Screen
CTDTNTP CTDSNTP
U.P Print Report CTDTUSR $$FRM CTVHUSI
U.V Report
Viewing
IOATOLV CTDSOLV TOLVPF1 TOLVCMD1 CTVHOLV
U.V Tag Notepad
Screen
CTDTNTP CTDSNTP
U.E Report
Editing
Screen
CTDTEXT CTDSEXT TOLVPF2 TOLVCMD1 CTVHEXT
U.E.1 Edit Report
Lines and
Columns
CTDTLNF CTDSLNF TOLVPF3 TOLVCMD1 CTVHLNF
U.E.1.C Edit Report
Columns
CTDTCLF CTDSCLF TOLVPF5 TOLVCMD1 CTVHCLF
U.E.2 Include Lines
Based on
Strings
CTDTINC CTDSINC TOLVPF4 TOLVCMD1 CTVHINC
U.E.3 Exclude
Lines Based
on Strings
CTDTEXC CTDSEXC TOLVPF4 TOLVCMD1 CTVHINC
U.E.4 Color Lines
Based on
Strings
CTDTCOL CTDSCLR TOLVPF4 TOLVCMD1 CTVHCLR
Option Screen Title
Module/
CSECT
Screen
Member
Format
Member
PFKey
Member
Command
Member
Help
Member
U.Q Quick Access
Panel
CTVTQAC $$QAC TQACPF1 TQACCMD1 CTVHQAC
U.Q.X Values of
Index
CTVTVOI $$VOI TVOIPF1 TVOICMD1 CTVHVOI
U.S.X Values of
Index
CTVTVOI $$VOI TVOIPF1 TVOICMD1 CTVHVOI
T Recipient
Tree Entry
Panel
CTDTUTR CTDSUTR TUTRPF1 TUTRCMD1 CTVHUTR
T CONTROL-D
/V Recipient
Tree
CTDTUTR CTDSUTR TUTRPF2 TUTRCMD1 CTVHUT2
T CONTROL-D
/V CHECK
TREE
Messages
CTMTJOB CTDSTRM TTRMPF1 TTRMCMD1 CTVHTRM
T.S CONTROL-D
/V Recipient
Definition
CTDTRCP CTDSRCP TRCPPF1 TRCPCMD1 CTVHRCP
CONTROL-O
Option Screen Title
Module/
CSECT
Screen
Member
Format
Member
PFKey
Member
Command
Member
Help
Member
OR Rule
Definition
Entry Panel
CTOTOMP CTOSOMP TOMPPF1 TOMPCMD1
CTOHOMP
OR Tables/Rules
of Library
CTOTOMP CTOSDIR TOMPPF1 TOMPCMD1 CTOHOM2
OR Order/Force
Messages
CTOTOMP CTOSOMM TOMPPF1 TOMPCMD1 CTOHOM3
OR Rule
Definition
Screen
CTOTRUL CTOSRUL TRULPF1 TRULCMD1 CTOHRUL
OM MSG
Statistics
CTOTMSC CTOSMSC TMSCPF1 TMSCCMD1 CTOHMSC
OS Rule Status CTOTARF CTOSARF $$ARF TARFPF1 TARFCMD1 CCTOHAR
OS Error
Messages
CTOTARM CTOSARM TARMPF1 TARMCMD1 CTOHARM
OS Why (?) CTOTOWY CTOSOWY TOWYPF1 TOWYCMD1 CTOHOWY
OL Automation
Log
CTOTALO $$ALO TALOPF1 TALOCMD1 IOAHALO
OA Automation
Options
CTOTAOP $$AOP
##AOP
2
TAOPPF1 TAOPCMD1 CTOHAOP
COMMAND CTOTMCS $$AOPCMD TAOPPF1 TAOPCMD1 CTOHAOP
CONSOLE CTOTCNS $$AOPCNS TAOPPF1 TAOPCMD1 CTOHAOP
ENQINFO CTOTGES $$AOPGES TAOPPF1 TAOPCMD1 CTOHAOP
GLOBALS CTOTGLB $$AOPGLB TAOPPF1 TAOPCMD1 CTOHAOP
SUBSYS CTOTSBS $$AOPSBS TAOPPF1 TAOPCMD1 CTOHAOP
SERVERS CTOTSRV $$AOPSRV TAOPPF1 TAOPCMD1 CTOHAOP
OA OPERATOR
Menu
CTOTAMN $$AOPOPR
##OPER
*
OA SAMPLE
Menu
CTOTAMN $$AOP
##SAMPLE
*
OA SLIP Menu CTOTAMN $$AOPSLP
##SLIP
*
OA Operator
Command
CTOTMCS $$AOPCMD TAOPPF1 TAOPCMD1 CTOHAOP
* Data for the Format member.
2
Data for the Format member.
CONTROL-B
Option Screen Title
Module/
CSECT
Screen
Member
Format
Member
PFKey
Member
Command
Member
Help
Member
BB Balancing
Status
CTBTABS CTBSABS $$ABS TABSPF1 TABSCMD1 CTBHABS
BB.L LOG messages IOATLOG $$LOG TLOGPF1 TLOGCMD1 CTMHLOG
BB.? WHY screen
displayed for
a rule
CTBTBWY CTBSBWY TBWYPF1 TBWYCMD1 CTBHBWY
BM Mission
Definition
CTBTBAL CTBSBAM TBALPF1 TBALCMD1 CTBHBAL
BM Mission List CTBTBAL CTBSBAD TBALPF3 TBALCMD1 CTBHBA2
BM Category List CTBTBAL CTBSBAD TBALPF3 TBALCMD3 CTBHBA3
BM.S Balancing
Mission
Definition
Screen
CTBTBMD CTBSBMD TBMDPF1 TBMDCMD1 CTBHBMD
BV Database
Variables
Definition
Facility
CTBTDAT CTBSSCH TDATPF1 TDATCMD1 CTBHDAT
BV Database
Facility
Group List
CTBTDAT CTBSDAR TDATPF3 TDATCMD1 CTBHDA2
BV Database
Facility
Variables List
CTBTDAT CTBSDAR TDATPF3 TDATCMD1 CTBHDA3
BV.G Display
Variable by
Graph
IOATGRU $$BVG TGRPPF1 TGRPCMD1 IOAHGRU
BV.V Display And
Update
Variables In
Active File
CTBTDBV CTBSDBV $$DBV TDBVPF1 TDBVCMD1 CTBHDBV
BV.S CONTROL-B
Variable
Definition
CTBTMOD CTBSMOD TMODPF1 TMODCMD1 CTBHMOD
BR Rule
Definition
Entry Panel
CTBTRLB CTBSRLB TRLBPF1 TRLBCMD1 CTBHRLB
BR Rule List CTBTRLB CTBSDIR TRLBPF3 TRLBCMD1 CTBHRL2
BR.S Rule
Definition
Screen
CTBTRUM CTBSRUM TRUMPF1 TRUMCMD1 CTBHRUM
Option Screen Title
Module/
CSECT
Screen
Member
Format
Member
PFKey
Member
Command
Member
Help
Member
BR.S Rule
Definition
Compiler
Messages
Screen
CTMTJOB CTBSJOB TJOBPF1 TJOBCMD1 CTBHJOB
BA Rule Activity
Entry Panel
CTBTJBL CTBSJBL TJBLPF1 TJBLCMD1 CTBHJBL
BA Rule Activity CTBTJBL CTBSJAC $$JAF TJBLPF2 TJBLCMD1 CTBHJB2
BA CONTROL-B
List-Editing-
Format Error
Messages
CTMTJOB CTBSJER TJERPF1 TJERCMD1 CTBHJER
BA CONTROL-B
Report
Viewing
CTMTJOB CTBSJRP TJRPPF1 TJRPCMD1 CTBHJRP
BA.G Display
Variable by
Graph
IOATGRU $$BJG TGRPPF1 TGRPCMD1 IOAHGRU
CONTROL-T
Option Screen Title
Module/
CSECT
Screen
Member
Format
Member
PFKey
Member
Command
Member
Help
Member
TR Rule
Definition
Entry Panel
CTTTRLD CTTSRLD TRLDPF1 TRLDCMD1 CTTHRLD
TR Rule
Definition
List of Tables
CTTTRLD CTTSDIR TRLDPF3 TRLDCMD1 CTTHRL2
TR Rule
Definition
List of Rules
CTTTRLD CTTSDIR TRLDPF3 TRLDCMD1 CTTHRL3
TR Rule
Definition
Screen
CTTTRLM CTTSRLM TRLMPF1 TRLMCMD1 CTTHRLM
TP Pool
Definition
Entry Panel
CTTTPLD CTTSPLD TPLDPF1 TPLDCMD1 CTTHPLD
TP Pool
Definition
List of Tables
CTTTPLD CTTSPDR TPLDPF3 TPLDCMD1 CTTHPL2
TP Pool
Definition
List of Pools
CTTTPLD CTTSPDR TPLDPF3 TPLDCMD1 CTTHPL3
TP Pool
Definition
Screen
CTTTPLM CTTSPLM TPLMPF1 TPLMCMD1 CTTHPLM
TV Vault
Definition
Entry Panel
CTTTVLD CTTSVLD TVLDPF1 TVLDCMD1 CTTHVLD
TV Vault
Definition
Table List
CTTTVLD CTTSVDR TVLDPF3 TVLDCMD1 CTTHVL2
TV Vault
Definition
Vaults List
CTTTVLD CTTSVDR TVLDPF3 TVLDCMD1 CTTHVL3
TV Vault
Definition
Screen
CTTTVLM CTTSVLM TVLMPF1 TVLMCMD1 CTTHVLM
TI Inquire/
Update MDB
Entry Panel
CTTTINQ $$INQ TINQPF1 TINQCMD1 CTTHINQ
TI Inquire/
Update MDB
Variables
List
CTTTINQ $$INS TINQPF3 TINQCMD1 CTTHINS
Option Screen Title
Module/
CSECT
Screen
Member
Format
Member
PFKey
Member
Command
Member
Help
Member
TI Inquire/
Update MDB
Volume
Update
Screen
CTTTUPR $$UPV TUPRPF1 TUPRCMD1 CTTHUPR
TI Inquire/
Update MDB
Dataset
Update
Screen
CTTTUPR $$UPD TUPRPF1 TUPRCMD1 CTTHUPR
TC Check In
External
Volume
CTTTKIN $$KIN TKINPF1 TKINCMD1 CTTHKIN
ISPF
Option Screen Title
Module/
CSECT
Screen
Member
Panel With Docutext/
Jobscan Member
Help
Member
6 ISPF UTILITIES IOAIUTI
M CTMPUTI CTMPUTIJ
D CTDPUTI
T CTTPUTI CTTPUTH
M+D CTMPUTID CTMPUTIX
D+T CTTPUTID CTTPUTH
M+T CTTPUTIM CTTPUTIN CTTPUTH
M+D+T CTTPUTIS CTTPUTIX CTTPUTH
M+B CTMPUTI CTMPUTIJ
D+B CTDPUTI
B+T CTTPUTI CTTPUTH
M+D+B CTMPUTID CTMPUTIX
D+B+T CTTPUTID CTTPUTH
M+B+T CTTPUTIM CTTPUTIN CTTPUTH
M+D+B+T CTTPUTIS CTTPUTIX CTTPUTH
D1 Decollating CTDMISRQ
D2 Printing CTDMISRQ
D3 Backup/Migration CTDMISRQ
D4 Restore CTDMISRQ
I1 Prerequisite
Conditions
IOACCND
M1 Job Order Issue CTMJOBRQ
M2 AutoEdit
Simulation
CTMCAES CTMPROMP
M3 Simulation/Tape Pull CTMCSIM
M4 Parameter
Prompting
M5 Quick Schedule CTMQUICK
M6 User Interface CTMJBINT
R1 CONTROL-R
Simulation
R2 Dataset Cleanup
R3 Job Dataset List
R4 Standalone
T1 CONTROL-T
Simulation
CTTCRSS
IOA Rel. 5.1.4 Administrator Guide F 1
General Description
IOAMEM module attributes: RENT, AMODE=31 RMODE=24
Upon entry, the value of AMODE is saved. AMODE is set to 31 to handle addresses above
the 16MB line. Upon return, the original value of AMODE is restored.
Storage for the handler is obtained below the 16 MB line and is saved in the handler
address. The caller must not modify the handler address between the first call and the
FINISH request call to module IOAMEM.
The handler address is returned in field IMHNDLR, which is mapped by macro
IOAMMEM.
When invoking macro IOAMEM with parameter HANDLE=addr, the field that contains
the handler address is not modified by macro IOAMEM. If more than one handler is used
in the same program, save the handler address and invoke macro IOAMEM with the
proper handler address in parameter HANDLE=addr.
It is not necessary to provide a buffer address for GETMEM, DIRECTOR and DIRFULL
requests.
If the buffer address is not passed (field value is zero), module IOAMEM obtains storage
above or below the 16MB line. The number of records in the storage buffer is determined as
follows:
If field RECNUM(IMRECNUM) is not zero, the number of records is the value in field
RECNUM(IMRECNUM).
If field RECNUM(IMRECNUM) is zero, the default number of records is 5000.
The actual buffer size is the number of records in the buffer times the LRECL of the input
dataset, plus 16 bytes for the header.
Module IOAMEM does not free any buffer the caller uses. If module IOAMEM obtains a
storage buffer address on behalf of a caller, the caller must free this storage. The caller can
free the buffer by using macro IOAXAGR. Field IMBUFARD points to the real buffer
address + 16 bytes. The length of the buffer is in offset 4 from the beginning of the header.
F 2 IOA Rel. 5.1.4 Administrator Guide
If the buffer address is passed (field value is not zero), module IOAMEM treats field
IMRECNUM as follows:
If the value in field IMRECNUM is less than or equal to the value passed in the buffer
address field, then the value in field IMRECNUM is treated as the number of records.
If the value in field IMRECNUM is greater than the value passed in the buffer address
field, then the value in field IMRECNUM is treated as an end-of-buffer address.
If the buffer address is passed (field value is not zero) and the buffer size is insufficient,
module IOAMEM ends with a return code of 08 and a reason code of 24. The actual number
of records the member contains is returned in field IMRECNUM.
If the buffer address is not passed (field value is zero), module IOAMEM returns with a
buffer that contains the entire member. The number of records in the buffer is returned in
field IMRECNUM.
Macro IOAMEM checks whether or not parameter IOAMEMA has been supplied. If this
parameter has been supplied, macro IOAMEM uses the supplied address. Otherwise,
macro IOAMEM loads the IOAMEM module before invoking it and deletes it upon return.
GETMEM, GETLINE and PUTMEM requests support reading and writing members with
record lengths other than 80 bytes. The GETLINE request can read members with variable
record lengths.
The FINISH request cleans up the environment, closes all opened DCBs, and frees all I/O
buffers and the handler storage.
Note Module IOAMEM must be called with a FINISH request. Otherwise, some DCBs may
remain open and some storage buffers may remain allocated.
The parameter list passed to IOAMEM is mapped by macro IOAMMEM as follows:
Type Field name Input fields Length
In IMREQ Request / Function CL8
In/Out IMHNDLR Handler address AL4
In/Out IMBUFADR Buffer address AL4
In/Out IMRECNUM Buffer size in
records unit
AL4
In IMFRMREC Read from record
number
AL4
In IMMCTADR MCT address AL4
In IMDSNAME Dataset name CL44
In IMMEMBER Member name CL8
In IMDDNAME DD name CL8
In IMUSERID User ID CL8
In IMBUFFMT Buffer format CL1
Vector/Double
pointers
In IMACT Action for
PUTMEM
CL1
Add/Replace
In IMISPFS ISPF statistics CL1
Yes/No/Blank
In IMBFLOC Buffer location CL1
Above/Below
In IMESTAE ESTAE CL1 Yes/No
In IMDUMP DUMP when
ESTAE is yes
CL1 Yes/No
Out IMRC Return code AL2
Out IMRSN Reason code AL2
Out IMLRECL LRECL of dataset AL2
Out IMBLKSIZ Blocksize of dataset AL2
Out IMRECFM RECFM of dataset CL2
Out IMDSORG DSORG of dataset CL2
Out IMABENDC Abend code CL10
Return Codes and Reason Codes
RC RSN DIRFULL DIRECTOR DELMEM MEMSTAT
00 00 OK OK OK OK
04 00
04 Requested
member does
not exist in
dataset
08 00 Member
name has not
been
supplied
Same
04 Dataset is
not PDS or
PDSE
Same Same Same
08 Insufficient
storage
GETMAIN
failed
Same Same Same
12 OPEN for
dataset failed
Same Same Same
16
20 Member does
not exist
24 Buffer is full
Actual
number of
records
returned
Same
28 ENQ failed
12 Reason code
from STOW
STOW for
DELETE
failed
RC RSN GETMEM GETLINE PUTMEM
00 00 OK OK OK
04 00 End of file
reached
04 Replace was
specified for a
non=existing
member,
changed to Add
08 00 Member name
has not been
supplied
Same Same
04 Dataset is not
PDS or PDSE
Same Same
08 Insufficient
storage
GETMAIN
failed
Same Same
12 OPEN for
dataset failed
or
RDJFCB failed
Same Same
16 RECFM is not
F or FB
Same
20 Requested
member does
not exist
Same Add was
specified for an
existing member
24 Buffer is full
Actual number
of records
returned
28 ENQ failed
12 Reason code
from STOW
STOW for
ADD/REPLACE
failed
RC RSN All functions
16 04 Unknown request type
04 Neither dsname nor
ddname have been
supplied
08 Requested dataset is not
cataloged
12 Dynamic allocation failed
for the requested dataset
16 ESTAE caught an ABEND
20 The requested dsname is
not in the concatenation of
the given ddname
24 Requested dataset does
not exist on volume
pointed to by the catalog
Return Codes and Reason Codes From Librarian/Panvalet
RC RSN All functions
20 04 EOD reached
08 Open failed for
Librarian/Panvalet
dataset
12 Member not found
16 Read record error
Function Codes
The following function codes are be supported by module IOAMEM
INIT Set up the handler (optional).
DELMEM Delete an existing member.
DIRECTOR Retrieve the directory entry for a given dataset.
DIRFULL Retrieve the full directory to a buffer.
ENDLIBDE Close the last input member processed.
FINISH Close last member and deallocate the library.
GETLINE Read a member line by line.
GETMEM Get a whole member into a buffer.
INITMEM Prepare a member for GETLINE request.
MEMSTAT Retrieve ISPF statistics for a given member.
PUTMEM Write a whole member to a library.
In order to map the parameter list, use macro IOAMMEM with the following format:
[name] IOAMMEM DSECT=[ NO | YES ]
To invoke module IOAMEM, use the IOAMEM macro with the following parameters:
[name] IOAMEM request, Request type
HANDLE=, Handler address
BUFFADR=, Buffer address
RECNUM=0, Number of records in buffer
FROMREC=0, Read from record number
MCTADDR=0, MCT address
DSNAME=, DSNAME
MEMBER=, Member name
DDNAME=0, DDNAME
USERID==CL8IOAUSER, User ID
BUFFRMT=V, Buffer format
ACTION=A, Action for PUTMEM
ISPFSTAT=Y, ISPF statistics for PUTMEM
BUFFLOC=A, Buffer location
ESTAE=Y, ESTAE request
DUMP=N, DUMP option when ESTAE is yes
IOAMEMA=, Location of IOAMEM address
MF=[ L | E | (E,label) ]
Parameter Explanation
Request see list above
HANDLE=addr Addr or register (2) - (12) used as input and output
BUFFADR=addr Addr or register (2) - (12) used as input and output
RECNUM= Addr or register (2) - (12) or number used as input and output
FROMREC=addr Addr or register (2) - (12)
MCTADDR=addr Addr or register (2) - (12)
DSNAME=addr Addr or register (2) - (12)
MEMBER=addr Addr or register (2) - (12)
DDNAME=addr Addr or register (2) - (12)
USERID=addr Addr or register (2) - (12)
BUFFMT=value V or D or address for GETMEM and PUTMEM only
ACTION=value A or R or address for PUTMEM only
ISPFSTAT=value Y or N or address for PUTMEM only
BUFFLOC=value A or B or address
ESTAE=value Y or N or address
DUMP=value Y or N or address
IOAMEMA=addr Addr or register (2) - (12)
Examples
LOAD EP=IOAMEM
ST R0,MEMADR
IOAMEM GETMEM,
DDNAME=0,
RECNUM=1000,
DSNAME==CL44N22.LIB.CNTL,
MEMBER==CL8TESTX,
ESTAE=Y,
DUMP=N,
IOAMEMA=MEMADR,
MF=E,
MCTADDR=0
MVC HANDLE,IMHNDLR save handler address
IOAMEM GETMEM,
HANDLER=HANDLE,
BUFFADR=0,
RECNUM=RECNUM,
DDNAME=DDNAME,
DSNAME=DSNAME,
MEMBER=MEMBER,
ESTAE=Y,
DUMP=N,
IOAMEMA=MEMADR,
MF=E,
MCTADDR=0
HANDLE DS A
DDNAME DC CL8DD1
DSNAME DC CL44MY.DSNAME
MEMBER DC CL8MEMBER1
RECNUM DC A(10000)
IOA Rel. 5.1.4 Administrator Guide G 1
Appendix G: Customizing the CONTROL-M Status
Screen
This appendix contains information that is useful for customizing the Status screen and
creating/modifying Display Types for screens 3, 3.N, 3.G and the History Environment
screen. For more information about the Display Type facility, see Customizing IOA
Display Format Members in Section 2 of this guide.
This appendix provides information about the following topics:
Screen Fields
Header and Bottom Line Fields
Job Related Fields
Status Area Color
Filter Fields
CLASS of Bottom Lines
Screen Fields
The following tables list the fields that can be displayed in the Active Environment
(Status) screen (Screen 3). Header line and bottom line fields do not vary by display type.
Job related fields do vary by display type.
Header and Bottom Line Fields
Field
Name
Field
Length
Where Used (As
supplied) Details
ACTAFILT 9 Title line Active filter.
ACTTIND 7 Title line Dump ON indication. In regular mode, it
contains only dashes. If the Dump status is
ON, the text DUMP ON is displayed in red.
ACTTDIS 7 Title line Display mode (Active/History/Network/Group)
In History mode, the word History is displayed
in red.
ACTTITL 7 Title line Display details (Environment/memname).
ACTTMST 4 Title line CONTROL-M status (UP/DOWN).
ACTDTYP 3 Title line Current Display Type.
ACTBTIM 8 Bottom line Current time.
ACTTUPD 8 Unused Last time the Refresh NET was handled.
G 2 IOA Rel. 5.1.4 Administrator Guide
Job Related Fields
Field
Name
Field
Length
Where Used (As
supplied)
1
Details
ACTDNAM 8 <A> <D> Job MEMNAME.
ACTDOWN 8 <A> <D> Job Owner.
ACTDODT 6 <A> <D> Job ODATE.
ACTDJNM 14 <A> <D> Jobname/Job ID.
ACTJTYP 3 <A> <D> Task type.
ACTSTAT 306 <A> <D> <N> Jobs status. Multiple line field composed of
9 subfields, each of which is 33 characters
with one blank at the end. Under <N>, only
the first 16 bytes are displayed.
ACTDPRI 2 <A> <N> Job Priority.
ACTDDIN 4 <A> <N> DUE IN.
ACTDDUT 4 <A> <N> DUE OUT.
ACTDLPS 4 <A> <N> Job average elapsed time.
ACTDRUN 5 Unused Run number.
ACTDORD 5 <A> Order-ID. (Also displayed in the STATUS
field if command ORDER was issued.)
ACTDGRP 20 <A> Group. (Also displayed in the STATUS field
if command Group was issued.)
ACTDTMF 4 <A> Time FROM.
ACTDTMU 4 <A> Time UNTIL.
ACTDMCC 24 <A> Max-RC (STEP.PROC).
ACTDNOD 8 Unused NJE Node ID.
ACTDRBA 6 <A> Jobs RBA in the AJF.
ACTDRES 1 <A> <N> Resource use indicator (Y/_). NET display:
Quantitative or Control resource. All other
displays: In Condition, Out Condition,
Quantitative Resource or Control Resource.
ACTDLAT 1 <A> <N> Late indicator (Input/eXecuting/Out).
1
<A>, <D> and <N> represent DI A, DI D and DI N, respectively.
Field
Name
Field
Length
Where Used (As
supplied)
1
Details
ACTDING 1 <A> IN Group indicator (G/_). G indicates a
Group Entity or a job ordered in a Group
table.
ACTDNNA 27 <N> Nesting Level & Name of job. This field is
meaningful only under NET display. The
Root job is displayed in the left-most
position. Successor and predecessor jobs are
aligned to the right according to level. E.g.:
2 Pred2
1 Pred1
=> Root
+1 Succ1
+2 Succ2
ACTDNNM 27 Unused Nesting Level & Name of job. This field is
meaningful only under NET display. The
Root job is centered. Predecessor jobs are
aligned to the left and successor jobs are
aligned to the right according to level. E.g.:
2 Pred2
1 Pred1
=> Root
+1 Succ1
+2 Succ2
Color Fields
The following fields affect the color of the status area (field ACTSTAT). To change a color
for a specific status, the appropriate field in the General Constants part of the $$ACT
member should be changed. Only the following fields impact the color of the status area.
All other fields in the General Constants part do not affect the color of the status area.
Field Name Field Length Current Color Value of the Field
$677 10 GREEN Ended OK
$810 9 GREEN Forced OK
$WRE 12 YELLOW Wait Release
$REL 8 YELLOW Released
$671 15 YELLOW Wait Submission
$672 14 YELLOW Wait Execution
$673 9 YELLOW Executing
$687 9 YELLOW Submitted
$695 14 YELLOW Going to Start
$697 7 YELLOW Started
$807 15 YELLOW In Output Queue
$808 7 YELLOW NJE Job
$809 20 YELLOW NJE Job
(ID changed)
$811 6 YELLOW Active
$801 17 PINK Wait Confirmation
$NF1 13 PINK Not found
$692 15 RED Ended Not OK
$682 23 RED Failed Reason Unk
$674 23 RED Problems Reading Sysout
$679 13 RED Not Submitted
$680 11 RED Disappeared
$LTE 16 RED (Late Executing)
$LAT 6 RED (Late)
$LTS 17 RED (Late Submission)
$696 11 RED Not Started
$804 14 RED Term - Stop job
$812 10 RED In Error
Filter Fields
Predefined and user-defined filters are composed of various fields. The following table lists
all the fields that can be specified as part of such filters:
Field Name Field Length Used For
SACTSM1 8 1st Memname
SACTSM2 8 2nd Memname
SACTSM3 8 3rd Memname
SACTSM4 8 4th Memname
SACTSM5 8 5th Memname
SACTGR1 20 1st Group
SACTGR2 20 2nd Group
SACTGR3 20 3rd Group
SACTGR4 20 4th Group
SACT700 1 In Process Y/N
SACT701 1 Ended Y/N
SACT702 1 State Y/N
SACT703 1 Wait Sched Y/N
SACT704 1 Ended OK Y/N
SACT705 1 Free Y/N
SACT723 1 Wait Confirm Y/N
SACT707 1 Not OK Y/N
SACT708 1 Held Y/N
SACT706 1 Wait SUB Y/N
SACT710 1 Rerun Y/N
SACT711 1 On Request Y/N
SACT709 1 Submitted Y/N
SACT713 1 Disappeared Y/N
SACT714 1 Deleted Y/N
SACT712 1 Wait Exec Y/N
SACT716 1 Abended Y/N
Field Name Field Length Used For
SACT717 1 Late (ONLY) Y/N
SACT715 1 Executing Y/N
SACT719 1 Unexpected CC Y/N
SACT718 1 On Output Queue Y/N
SACT722 1 JCL Error Y/N
SACTTPJ 1 Job Task Type Y/N
SACTTPC 1 Cyc Task Type Y/N
SACTTPE 1 Emr Task Type Y/N
SACTTPS 1 Stc Task Type Y/N
SACTTPD 1 Cst Task Type Y/N
SACTTPY 1 Est Task Type Y/N
SACTTPX 1 Ecj Task Type Y/N
SACTTPZ 1 Ecs Task Type Y/N
SACTTPW 1 Wrn Task Type Y/N
SACTTPG 1 Grp Task Type Y/N
SACTRE1 20 1st Resource
SACTRE2 20 2nd Resource
SACTRIN 1 In Res Type Y/N
SACTROU 1 Out Res Type Y/N
SACTRCO 1 Conds Res Type Y/N
SACTRRS 1 Resource Res Type Y/N
SACTRCN 1 Control Res Type Y/N
SACTUI1 8 1st Owner
SACTUI2 8 2nd Owner
SACTUI3 8 3rd Owner
SACTUI4 8 4th Owner
SACTUI5 8 5th Owner
SACTPRI 2 Priority
Note From and To ODATE values are not part of the filtering mechanism.
CLASS of Bottom Lines
Each display has its own Primary and Alternate bottom lines. The Primary bottom line is
always the first bottom line displayed when entering the screen. Command OPT toggles
between the Primary and the Alternate bottom lines. As supplied, the Primary bottom line
lists the most important options/commands valid under the display. The Alternate bottom
line(s) lists all the valid options/commands under the display.
The CLASS= of the @STYLE section which defines the bottom lines determines the
appropriate Primary and Alternate bottom lines in each display (History, Net, etc.).
The following table lists the CLASS of Primary & Alternate bottom lines for each display,
with and without CONTROL-R installed:
Display
CLASS with
CONTROL-R
Prim. Alt.
CLASS without
CONTROL-R
Prim. Alt.
Active A 1 A 2
Net B 1 B 2
Group B 1 B 2
History A 3 N/A
IOA Rel. 5.1.4 Administrator Guide H 1
Command Description Parameters
ABEND Terminate CONTROL-O with
abend
AUTOLOG= Enable/disable the Automation
log
=Yes/No
C= Order the rules in a CMEM
table
=LIB(table)
COSDB= Set a COSMOS table to a
specific mode of operation
=TABLEID,xxxxxxxx
where xxxxxxxx = FREE
HELD
NOPRE
FORCE_OK
DISPLAY
COSMOSSTART Start COSMOS
COSMOSSTOP Stop COSMOS
D= Delete a rule table =Yes/No
DEBUG= Activate CONTROL-O internal
trace using:
GTF for the subsystem interface
PRTDBG and DADUMP in the
CONTROL-O monitor
=nnn
where nnn is a number (000-255)
supplied by your IOA
representative, Technical Support,
or CONTROL-O development staff
DISABLEALT Stop using alternate subsystem
name
DISPCOMM Display CONTROL-O network
connections
DISPLAY Display 1st 1000 rules
F= Force CONTROL-O table rules =LIB[(mem)],D=date
=ALL[,REBUILD]
INTERVAL= Change the CONTROL-O
sleeping interval
=ss
where ss is the number of seconds
(range: 3 60)
H 2 IOA Rel. 5.1.4 Administrator Guide
LOADGLOBAL Load global variable memname
from the global variable
database or library
=memname
where memname is a specific
Global member or variable
database
LOG= Change the MODE of all the
rules to TRIGGER or LOG, or
reset all rules to their original
mode
=ALL set all rules to MODE LOG
=Trigger set all rules to issue a trace
record when a rule is triggered
=DEFAULT set all rules back to the
original MODE
MODE= CONTROL-O mode of operation without parameters: display
current MODE
=FREEZE stop all CONTROL-O
actions
=LOGONLY stop all
CONTROL-O actions but log all the
rules that should be triggered
=TRIGGERONLY stop only new
rules from being triggered
=RESUME,CANCEL reactivate
CONTROL-O operation but
IGNORE all pending rules
=RESUME,CONTINUE
reactivate CONTROL-O operation
and CONTINUE all pending rules
NEWCONLIST Reload all CMEM tables from
DACTMLST DDNAME
NEWDEST Reload the destination table
NEWSECDEF Reload security definitions
O= Order CONTROL-O table rules =LIB[(mem)],D=date
=ALL[,REBUILD]
RELOAD= Reload the CONTROL-O
executor module in order to
apply maintenance without
stopping CONTROL-O
=xxxxx
where xxxxx is the name of the
CONTROL-O module that should
refreshed: CTOAIDT or CTOWTO
RESETSTAT Reset CONTROL-O message
statistics
IOA Rel. 5.1.4 Administrator Guide H 3
SERVER= Send a command to
CONTROL-O severs
=serverid,STOP stop an active
server
=serverid,START start a failing
server
=serverid,CANCEL cancel active
request
=serverid,FORCE reset and stop
the server
=serverid,TERM terminate the
server
=serverid,DISPLAY display
server status
SHOWPARM Display CONTROL-O major
blocks
SMODE= Modify standalone mode when
CONTROL-M is also active
=F force standalone operation
=N CONTROL-O uses only
CONTROL-M to write to the
IOALOG
=Y CONTROL-O writes to the
IOALOG via CONTROL-M when
CONTROL-M is active; otherwise,
CONTROL-O writes to the
IOALOG directly
SNAP= Take a snapshot dump of
CONTROL-O internal data
areas
=xxxxx
where xxxxx is the list of blocks
that can be snapped
See CONTROL-O problem
determination in this manual
STARTCOMM Start CONTROL-O
communication via IOAGATE
STARTSTAT Start CONTROL-O message
statistics
STOP Stop the CONTROL-O function
and take down the CONTROL-O
monitor
STOPCOMM Stop CONTROL-O
communication via IOAGATE
STOPSTAT Stop CONTROL-O message
statistics
H 4 IOA Rel. 5.1.4 Administrator Guide
STORAGETABLE Display CONTROL-O E/CSA
usage and the major
CONTROL-O module address
SVCDUMP Make a CONTROL-O monitor
SVC dump
WATERMARKS Display watermarks for
CONTROL-O internal elements
and queues
WRITEGLOBAL Save global variable memname
into the global variable database
or library
=memname
where memname is a specific
Global member or variable database
Index
IOA Rel. 5.1.4 Administrator Guide I 1
Index

Operator
IOABLCAL Utility, 9-8
#
# OF DAYS TO KEEP Parameter
Backup Missions, 4-75
# OF GENERATIONS TO KEEP
Parameter
$
$ prefix
AutoEdit Variable Names, 1-14
$$AOP Member
IOA MSG Library, 5-34
$$BANCHR Member
Banner Printing, 4-49
$$CCDFLT
CCIFPARM Library, 4-56
$$COMPST Member
Global Library Compression, 5-27
$$POOL Member
PARM Library (CTT), 7-5
$$VAULT Member
PARM Library (CTT), 7-5
$Djnnn
JES2 Command, 3-49
$GLOBAL
Global Variable Member, 5-23
$HASP Messages
CMEM Tracking, 3-54
$INDEX Records
CTVDELI Utility, 9-125
CTVJAR Utility, 9-129
$LJnnn
JES2 Command, 3-49
$PROFFLD
Default Filters, 2-35
$PROFFLD Member
Global Profile, 2-33
$PROFMOD
Global Profile Member, 2-35
$PROFMOD Member
$PROFVAR Member
$SYSDATA Records
Migration Information, 4-86, 4-93
Migration Mission, 4-83
$TJnnR
JES Command, 3-49
$UINDXH Member
Banner Index, 10-25
$UINDXV Member
Banner Index, 10-25
%
%%$AUTOLOG System Variable, 5-19
%%$STATID Reserved Variable
Message ID (CTO), 5-17
%%MISSION Variable
Banner Page Definition, 10-23
%%STATUS AutoEdit Variable
Automatic Compression, 5-28
%%STATUS Variable
%ADDRn% Variable
%BKPUTIL% Parameter
Restore Skeleton, 4-80
%CATEGORY Parameter
Printing Mission, 4-33
%CATEGORY% Variable
%COM#% Parameter
%COND% Parameter
Migration Skeleton Job, 4-86
%COPIES% Variable
Banner Index, 10-25
Index
I 2 IOA Rel. 5.1.4 Administrator Guide
%COUNTP Parameter
CTTRPT Utility, 9-203
%CURRCOP% Variable
%DATAn% Variable
%DATE% Variable
%DEST% Parameter
%DEST% Variable
%DSNS% Parameter
Backup Mission, 4-74
%ENDKODAK% Parameter
%ENDREPEAT% Parameter
%FATHER% Variable
%FIELD Parameter
%FROMPAGE% Variable
%FSET% Parameter
%GLOBALn% Variable
%GROUP% Parameter
%GROUP% Variable
%JOBID% Variable
%JOBNAME% Variable
%KODAK% Parameter
%LASTADDRn% Variable
%LASTUSER% Variable
%LEVEL% Parameter
Migration Job, 4-84
%LINES% Variable
%MIGPREF% Parameter
%MISSION% Parameter
%MISSNAME% Parameter
%ODATE% Variable
%OUSER% Variable
%OWNER% Parameter
%PAGES% Variable
%PROCPREFD% Installation Parameter
Writer Facility, 4-41
%PRTY% Parameter
%REMARK% Variable
%REPEAT% Parameter
%REPORT% Variable
%RULER% Variable
%TARMEDIA% Parameter
%TIME% Variable
%TIMESTAMP% Parameter
%TIMESTMP% Parameter
%TOPAGE% Variable
Index
%USER% Variable
%VOLUMES% Parameter
%VSET% Parameter
*
* Operator
:
:Exit CTDX005, 10-16
@
@DLM Line Type
Display Format Member, 2-24
@END Line Type
@FIELD Line Type
Color Parameters, 2-25
@HEADER Line Type
@LINE Line Type
@STYLE Line Type
@VAL Line Type
+
+ Operator
++VER Statement
USERMOD, 10-3
<
<>W Operator, 9-8
<W Operator, 9-8
>
> Symbol
TIME UNTIL Field, 3-11
><W Operator, 9-8
>W Operator, 9-8
3
3270 Terminals
Multi-CPU Support, 3-55
3480/90/90E Tape Cartridge
Stopping/Starting a Device, 4-104
3490 Tape Cartridge
Utility CTTTPI, 9-288
A
Abend
Exit CTTX005, 10-29
ABENDACT Parameter
Modification (CTT), 7-4
ABFBKP File
CTBABI Utility, 9-75
CTBFRM, 9-89
ACCESS Parameter
CTTTPI Utility, 9-293
Account Information
Exit IOAX035, 10-8
ACCOUNT Keyword
Dataset Record, D-2
ACCOUNT Parameter
FileTek Media, 4-102
ACEE Control Block
OMON1Environment, 10-5
ACIF Distribution LOAD Library
APKACIF Program Module, 4-53
ACIF Interface
Activating, 4-53
Parameter Member Format, 4-54
ACIF=YES
AFP Reports, 4-61
ACIFPARM Library
ACIF Interface, 4-54
AFPDS Format, 4-61
Index
ACT Parameter
CTTDBID Utility, 9-165
Utility CTBDBVIG, 9-88
Activating
CDAM, 4-2
CMEM Facility, 3-2
CONTROL-D Monitor, 4-1
CTB Missions, 6-5
Generic Processing CTD, 4-1
IOA Online Monitor, 2-4
VTAM Monitor, 2-7
Active Balancing File, 6-5
Access Control, 10-28
Exit CTBX001, 10-28
Formatting, 9-30
Initialization, 9-75
Reformatting, 6-2
Searching, 6-10
Active Environment Screen. See also Status
Screen
Fields, G-1
Active Jobs File
Allocation, 9-68
Changing Size, 9-65
Cleaning, 9-65
Compressing, 9-64
CONTROL-M, 3-11
Disaster Recovery, 3-91
Exit CTMX008, 10-10
Formating, 9-68
Record Zero, 3-53
Restoration, 3-85
Snapshot, 3-86
Tuning, 3-46
Active Library (CTT)
Adding Volumes, 9-169
Active Mission Screen
Profile Variables, 2-37
Active Missions File
Changing Size, 9-97
Cleaning, 4-7
Compressing, 9-96
Exit CTDX001, 10-14
Expanding, 4-116
Active Missions Screen
Migration Type. See
Active Report List
Copy from Permanent, 9-104
Copying, 9-99
CTDDELRP Utility, 4-114
Deleting Reports, 9-106
Description, 4-112
Dynamic Sorting, 4-118
Active Transfer File
Changing Size, 9-98
Compressing, 9-98
Expanding, 4-117
PC File Transfer, 4-65
Active User File
Backup Utility, 9-117
Active User Report List
Copy to Permanent, 4-111
Copy to/from History, 4-113
Permanent User Report List, 4-110
Sorting, 4-118
ACTIVEDS Keyword
Volume Record, D-6
ACTIVEDS Parameter
CTTMUP Utility, 9-188
ACTSTAT Field
Status Screen, G-4
ADBPFUNC Variable
API Error Handling, 7-56
ADBPIOPR Variable
CTTIOS Function, 7-56
ADBPIRC Variable
API Error Handling, 7-56
ADBPIRSN Variable
API Reason Code, 7-56
ADBPRC Variable
API Return Code, 7-56
ADD Parameter
Adding
MDB Volume, 9-182
Volumes to MDB, 9-169
ADDMODE Statement
IOALDNRS Utility, 9-48
Index
Address Space
Application Server, 4-64
Checking, 9-134
Address Space ID
Pipe Participant, 11-13
Address Space Information
Fields, 11-29
Address Space Number
ASID Argument, 11-20
ADDVOL Function
High Level API, 7-53, 7-54
Ad-hoc Maintenance
IOA Products, 8-5
AFP Printers
AFP Printing
Banner Exits, 10-27
Commands, 4-45
Page Markers, 4-44
Page Mode Output, 4-44
Printing Missions, 4-42
AFP Report
Page On Demand, 4-61
AFP viewer
AFPDS
Description, 4-52
AFPDS Format
WD2949 Wish, 4-61
AJF File
CTMFRCKP Utility, 9-68
ALL Option
SCOPE Parameter (CTB), 6-11
Allocating
CTT Files, 9-158
Trace Files (CTT), 9-160
Allocation Members
Customization, 2-10
ALLOCOPT=JOBSDSN1
Generic Decollation, 4-98
ALREC# Parameter
Automation Log Size, 5-18
Alternate Allocation, 2-12
AMDAHL
MDS (Multi-Domain Facility), 3-74
AMFSIZE Parameter
Active Missions File, 4-116, 9-97
AMODE Value
IOAMEM Module, F-1
ANALYZ Step
Abend, 4-97
ANALYZE Step
Restore Missions, 4-81
AOI
CTO/IMS Interface, 5-43
APA Technology
Laser Printing, 4-42
APA=YES
AFP Reports, 4-61
APAPARM Library
AFP Parameters, 4-44
Format, 4-45
Sample Member, 4-45
APAR IR26630
SMP/E level 1.8, 8-1
APAR OY64290
JES2 Destination, 3-77
APF Authorization
CTTGVL Utility, 9-173
High Level API, 7-53
API
Base Level/High Level, 7-34
CONTROL-T Interface, 7-30
API (CTT)
High Level, 7-53
API, Base Level
Local TCT, 7-32
APKACIF Program Module
ACIF Distribution LOAD Library, 4-53
APPC Protocol
Application Program
Invoking CONTROL-B, 6-8
Application Server
Address Spaces, 4-64
CTDX024 Exit, 10-20
Displaying Users, 5-44
Recipient Tree, 4-4
Application Server, CONTROL-D
Index
APPLIDS Parameter
Page On Demand, 4-63, 5-44
APPLTYPE Parameter
IOAONL CLIST, 2-2
ARCCPUID Keyword
Trace Record, D-13
ARCDATE Keyword
Trace Record, D-13
Archive Server, 4-100
CTVX002 Exit, 10-20
DD Statements, 4-108
Deactivating, 4-6
Problem Determination, 4-108
ARCIDENT Keyword
Trace Record, D-13
ARCJOBID Keyword
Trace Record, D-13
ARCS
ARCTIME Keyword
Trace Record, D-13
ARCTYPE Keyword
Trace Record, D-13
ARCUNIT Installation Parameter
ARCUSRID Keyword
Trace Record, D-13
Argument Passing
CONTROL-B, 6-5
ASID Argument
Address Space ID, 11-13
Table Dump, 11-20
ASID Field
Address Space Information, 11-29
Participant Info, 11-26
ASID Number
CONTROL-D Application Server, 4-4
ASID Table
Dump Print, 11-20
ASM2
ASVT
MVS Table, 2-5, 4-2
ATFSIZE Parameter
Active Missions File, 4-117
CTDFRATF Procedure, 9-98
CTDPARM Member, 9-98
ATTR Statement
CTTRSM Utility, 9-217
CTTRTM Utility, 9-230
CTTSCA Utility, 9-268
CTTSTKR Utility, 9-281
CTTVTM Utility, 9-306
Authorization
Online Facility, 10-5
AUTHORIZE Field
User Reports List, 10-15
AutoEdit Facility
Description, 1-13
Global Variables (CTO), 5-23
AutoEdit Simulation
AutoEdit Variables
Global, 5-23
IGNORE/SELECT Statements, 3-19
AUTOLOG Command (CTO), 5-18
Automatic Compression
AutoEdit Library, 5-28
Automatic Recovery
System Crash, 3-95
Automation Log
Changing Size, 9-144
Description, 5-18
Search Limit, 2-42
Size, 5-18
Unecessary Messages, 5-19
Automation Option
Menu Syntax, 5-35
Automation Options
Exit CTOX004, 10-31
Format Members, 5-39
Menus, 5-35
Overview, 5-34
AUTOMLOG Parameter (CTO), 5-18
Auto-Recovery
Index
B
Backup
Automation Log, 5-18, 9-144
MDB and Trace File, 9-300
Retention and Volser (CTD), 9-117
Backup and Recovery
Repository (CTT), 7-25
Backup File (CTB)
Formatting, 9-30
BACKUP IN PROCESS Status
Backup Job Tailoring
Exit CTDX010, 10-17
Backup Mission
Advanced Scheduling, 4-71
CTDBKDAY Procedure, 4-16
Decollation Missions, 4-72
Default Missions, 4-15
Exception Handling, 4-75
Overview, 4-71
Retention Period, 4-75
Scheduling, 4-13
Workflow, 4-73
Backup Procedure
Backup Site
Balance Workload
IOA Online Monitors, 2-4
Balancing Activities
Invoking, 6-7
Balancing Mission (CTB)
Invoking, 6-10
Scheduling, 6-2
BANAFP Printing Option
Banner Exits, 10-26
Banner
Index Printing, 10-25
Printing Characteristics, 4-49
Printing Options, 10-26
Samples, 10-21
Suppression, 10-25
Banner Exits
Tailoring, 10-21
Banner Pages
Exits, 10-21
Format, 10-22
Letter Size, 10-22
Variables, 10-23
BANNER Parameter
Banner Exits, 10-27
Banner Printing
Exit CTDX003, 10-14
BANSEQ Printing Option
Banner Exits, 10-26
Bar-code
AFPDS Printing, 4-52
Base Level API (CTT)
Examples, 7-42
Functions, 7-35
Macro CTTIOS, 7-36
Media Database Access, 7-40
Read Entire MDB, 7-42
Record Access, 7-35
BASE MAINT Library
Maintenance Files, 8-4
BATCH Parameter
Batch Stacking
CTTSBD Utility, 9-237, 9-239
BDT Product
File Transfer Product, 3-70
BKP File
New Day Processing, 9-66
BKP Parameter
CTTTRB Utility, 9-300
BKPLIST Member
Migration Missions, 4-14
Mission List (CTD), 4-15
BKPMIS Parameter
Utility CTDUPBKP, 9-119
BKPORDER KSL Utility
BKPRESET Job
Backup Mission Rerun, 4-75
Index
BKPTO Parameter
BLK Parameter
CTTCRDF Utility, 9-158
BLK-CNT Field
Participant I/O Info, 11-28
BLKSIZE Keyword
Dataset Record, D-2
BLKSIZE Parameter
Exit CTDX005, 4-51
IOADBF Utility, 9-27
BLKS-RD Field
Pipe I/O Info, 11-26
BLKS-WT Field
BLOB Description
CONTROL-D/Image, 4-68
BLOCKCT Keyword
Dataset Record, D-2
Blocksize
Tuning, 3-47
BOXID Keyword
Volume Record, D-6
BOXLIM Parameter
BREAK Parameter
BREAK Statement
Browse Mode
Profile Variable, 2-43
BUFF# Field
Buffer Address
IOAMEM Module, F-1
BUFL Parameter
Building
Manual Conditions File, 9-46
Stacking Statistics File, 9-276
Bundle Printing
Banners, 10-24
Bundle Printing (CTD), 4-35
BUNSEP Printing Option
Banner Exits, 10-26
C
C Parameter
Utility CTBJAFIG, 9-94
CA-1
Compatibility, 9-221
Conversion of Retention Information,
9-226
Conversion Utility, 9-170
CA-7 (UCC7) Interface, 4-28
CA-ACF2
Security Product, 1-14
Calendar Creation
Calendar Facility
Overview, 1-10
Calendar Option
Primary Option Menu, 9-7
CALL Command
CART Media
Media Definition, 4-100
Migration, 4-88
CARTLEN Parameter
IOASPARM Member, 4-88
Cartridge Message Display
Customization, 7-27
Catalog Considerations
CATALOG Retention
CTTSTK Utility, 9-277
Cataloging
Datasets (Utility CTTRCV), 9-193
CATEGORY 5
AFP Printing, 4-44
Category Field
Job Scheduling, 4-26
Index
CA-TLMS
Compatibility, 9-221
Conversion of Retention Information,
9-225
CA-TOP SECRET
CCIF Main Index
CONTROL-V Index, 4-58
CCIF Parameter
DSC Printer Emulator, 4-57
CCIF Report
CCIF=LCDS Parameter
DVS Printer Emulator, 4-61
CCIF=YES Parameter
CCIF Format, 4-61
CCIF1 Parameter
XEROX Reports, 4-57
CCIF2 Parameter
XEROX Reports, 4-57
CCIF3 Parameter
XEROX Reports, 4-57
CCIF4 Parameter
XEROX Reports, 4-58
CDAM
Activating, 4-2
AFP Printing, 4-43
Dataset Names, 4-91
Deactivating, 4-5
Deleting Files, 9-101
Migrating Files, 4-82
Migration Mission Name, 4-83
Parameters, 4-43
CDAM File
Page Separator Exit, 10-8
CDAMCRE.JOB File
Cell Pool
Data Dump, 11-20
Data Space Storage, 11-19
CHANGETO Parameters
CTDUPBKP Utility, 9-119
CHECK Mode
CTTINIT Procedure, 7-4
CHECK Parameter
Checkpointing
CHKINDT Field
SCRATCH Report, 9-229
CHKINDT Keyword
Volume Record, D-6
CHUNKSIZE Parameter
Bundle Printing, 4-36
CICS
CONTROL-O Interface, 5-42
IOA Online Support, 2-1
Memory Requirement, 2-3
CICS Support
CKP File. See also AJF File
CKPSIZE Parameter
Active Jobs File Size, 9-65
CLASS JES Parameter
Multi-Chunk Printing, 4-36
CLASS Parameter
@STYLE Display Format Line, 2-21
CLASSLIKE Parameter
Cleaning
Active Jobs File, 9-65
History User Report List, 9-103
Migrated Report List, 9-123
CLEANUP Function
CTMCAJF Utility, 9-62
CLIST
Entry to Online Facility, 2-2
Mission Scheduling (CTD/V), 4-16
CLNCOUNT Keyword
Volume Record, D-6
CLOSE Function
Base Level API (CTT), 7-35
CLPOOL Argument
Cell Pool Dump, 11-20
Data Space Information, 11-19
Index
CLPOOL Content
Data Dump, 11-20
CMD Parameter
IOATEST Utility, 9-51
CMEM
Exits, 10-11
File Transfer, 3-70
Multi-CPU Support, 3-57, 3-62, 3-63
Storage Requirements, 3-39
Tuning, 3-54
CMEM Executor Module
CTOAIDT, 5-2
CMEM Facility
Activation, 3-2
CONTROL-O Installed, 5-1
CONTROL-O Not Installed, 1-6
CTO Installed, 5-41
Deactivating a Rule Table, 3-37
Debugging, 3-43
Description, 3-35
Display Active Rules, 3-37
Multiple Rule Tables, 5-14
Replacing a Monitor, 3-3
Replacing Rule Tables, 3-36
Resource Utilization, 3-44
Rule Loading, 3-35, 5-4
Rule Operation Mode, 3-38
Security Cache, 3-39
Shutting Down, 3-2
Sleeping Interval, 3-38
CMEM Rules
CTM2RULE Utility, 5-3
Statement Types, 5-3
CMORDER Parameter
CONTROL-O Procedure, 5-4
Rule Lists (CMEM), 5-14
CNGMSGID Parameter
CODE Parameter
CTMMMSG Macro, 2-49
Color Fields
Status Screen, G-4
COLOR Parameter
Color Support
Customization, 2-26
Extended, 2-26
IDMS/DC, 2-26
IMS/DC, 2-26
IRMA, 2-26
ISPF, 2-26
COLORA Parameter
COLUMN Parameter
Combinatorial Logic
COMM Parameter
Command Members
Format, 2-13
Modification, 2-13
Online Facility, E-1
Commands
COSMOS, 5-19
Customization, C-1
JES3, 9-50
Journal File, 3-87
COMMNDnn Member, 5-12
COMMNDxx Parameter
SYS1.PARMLIB Library, 4-42
Communication
Cross-Product, 1-15
Inter-System, 1-15
Multi-system, 1-16
Communication Between Platforms
VM Support, 3-74
Communication Monitors (CTM), 1-19
Communication Setup Dialog Box
CONTROL-D/PC, 4-60
Communications File
Inter-System Communications (CTM),
1-16
COMP-CODE Field
CTVJAR Parameter, 9-129
Index
Compiling
Rule Definitions (CTB), 9-76
COM-PLETE
COM-PLETE Support
COMPRESS Function
CTMCAJF Utility, 9-62
Compressing
Active Transfer File, 9-98
Global AutoEdit Library, 5-27
Compressing Libraries
Job Submission, 3-28
CompuView Navigator
Document Sciences Corporation, 4-56
CONDITIONS Parameter
CTMRSTR Utility, 9-73
Conditions Selection List (CTM), 1-17
Conditions/Resources File
Copying, 9-20
Description, 1-9
Exit IOAX007, 10-6
Expanding, 2-52
IOACND Utility, 9-16
Snapshot, 3-86
Storage Space, 3-40, 5-9
Conditions/Resources Screen
Configuration
CONNECT DIRECT Product
CONNECT DIRECT Support
Dataset Event, 3-30
Constant Blocks
IOA Screen Definition, 2-19
Constants
IOA Screens, 2-17
CONTDAY Procedure
Customization (CTM), 3-18
DAREPMIS DD Statement, 4-24
Exit IOAX012, 10-7
New Day Processing (CTM), 3-13
CONTROL D/PC
AFP Viewing Component, 4-52
Control Resources
Adding/Deleting, 9-16
Description, 1-9
Control Statements
AFP, 4-44
Control Table (CTT)
Loading, 7-36, 7-42
Control Table (TCT)
CONTROL-T Initialization, 7-2
CONTROL-B
Activating Missions, 6-5
Compile Rule Definitions, 9-76
Database Exit, 10-28
Database Integrity, 9-88
Deleting Variables, 9-86
Initialize Active Balancing File, 9-75
Invoking via CONTROL-D, 6-9
Invoking via CONTROL-M, 6-9
IOA Access Method, 2-29
IOA Access Method Files, 2-30
JCL Example, 6-6
Job Step Invocation, 6-8
Online Facility Members, E-10
Rebuild Index, 9-79
Repository, 1-12
Rule Activity File Integrity, 9-94
Runtime Environment, 6-7
Variable Generations, 9-81
CONTROL-B Utilities
Summary, 9-4
CONTROL-D
Chunks on the Spool, 4-39
CONTROL-M, 4-23
CONTROL-M Considerations, 4-29
Daily Maintenance, 4-7
Date Control Record, 4-8
Decollation Server, 4-6
Functional Subsystem Monitor, 4-41
Index
Generic Processing, 4-1
Initialization, 4-1
Internet Access, 4-70
Monitor Activation, 4-1
Monitor Exits, 10-20
Number of Users, 2-4
Online Viewing, 2-4
Printer, 4-40
Product Description, 1-1
Repository, 1-11
SMF Accounting, 4-120
User Daily, 4-8
User Groups, 4-22
Utilities, 9-95
VM Support, 3-84
Web Access, 4-70
CONTROL-D Application Server
Overview, 1-7
CONTROL-D Monitor
Deactivating, 4-4
Mission Processing, 1-7
CONTROLD OUTPUT Statement
AFP Printing, 4-43
CONTROL-D Printer
CTDPARM Member, 4-42
CONTROL-D Repository
Maintenance, 4-116
CONTROLD Statement
IOACLRES Utility, 9-14
CONTROL-D Utilities
Summary, 9-3
CONTROL-D/Decollation Server. See
Decollation Server
CONTROL-D/Image
Decollating, 4-68
Description, 4-67
File Packing, 4-68
File Transfer, 4-68
Implementing, 4-68
Indexing, 4-68
POD-API Application, 4-70
Sample Files, 4-67
Viewing, 4-70
CONTROL-D/PC
File Transfer Monitor, 1-7
CONTROL-D/V Monitor
CONTROL-D/Writer
Installation, 4-40
CONTROLF OUTPUT Statement
AFP Printing (CTD), 4-43
CONTROL-I/2000
CONTROL-M
Active Jobs File, 3-11, 9-62
Administration, 3-1
CONTROL-D, 4-23
CONTROL-D Considerations, 4-29
CONTROL-O, 5-41
CONTROL-V Migration Job, 4-94
File Expansion, 3-7
Initialization, 3-1
Inter System Communications, 1-16
Job Ordering, 3-10
Maintenance Jobs, 3-12
MAS Environment, 3-50
Monitor, 3-1
Monitor Shutdown, 3-1
New Day Processing, 3-10, 3-17
Repository, 1-11
Rerun Backup Mission (CTD), 4-75
Rerun Restore Mission (CTD), 4-81
Scheduling, 4-25
Scheduling Library, 4-24
Index
Trace Facility, 3-9
Tuning Recommendations, 3-45
User Daily Job, 3-10
VM Support, 3-71
CONTROL-M Event
Triggered by VM User, 3-78
CONTROL-M Facility
Security Cache, 3-4
CONTROL-M Monitor
Abend, 3-92
JES2 Activity, 3-50
Non-swappable, 3-51
Priority, 3-51
CONTROLM Statement
CONTROL-M Utilities
Summary, 9-2
CONTROL-M/WorkLoad
Parallel Processing Rules, 1-5
CONTROL-O
Administration, 5-4
Automation Log, 5-18
CICS Interface, 5-42
CMEM, 5-41
CMEM Control, 5-1
CONTROL-M, 5-41
Deactivating a Rule Table, 5-7
Debugging, 5-30
IMS Interface, 5-43
Internal Data Areas, 5-31
IPL Automation, 5-12
IPL Process, 5-14
Message Statistics, 5-16
Multiple Rule Tables, 5-13
Operating Mode, 5-33
Operator Command Exit, 10-7
Rebuild Index, 9-138
Repository, 1-12
Resource Utilization, 5-31
Rule Types, 5-3
Security Cache, 5-29
Simulation Utility, 9-141
Starting, 5-1
Storage Allocation, 5-10
Storage Requirements, 5-9
Troubleshooting, 5-10
Utilities, 9-133
VM Support, 3-84
CONTROL-O Monitor
CMEM Rules, 1-7
Replacing, 5-2
CONTROL-O Rules
CMEM Rule Comparison, 5-3
CONTROL-O Status Monitoring System.
See COSMOS
CONTROL-O Utilities
Summary, 9-4
CONTROL-O/COSMOS
CONTROL-O/IMS Interface
Implementation, 5-43
CONTROL-O/PC
VM Support, 3-84
CONTROL-R
CTT Interface, 7-29
CONTROL-T
API Interface, 7-30
Backup and Recovery, 7-25
Control Table, 7-2
CTR Interface, 7-29
Database Printing, 9-167
Dormant Mode, 7-5
Initialization, 7-2, 7-3
Media Database Integrity, 7-19
MVS Interface Parameters (CTT), 7-4
MVS Interfaces, 7-2
New Day Procedure, 7-7
Normal Mode, 7-5
Index
Operating Status, 7-5
Operation Mode, 7-8
Overview, 7-1
Real-time Environment, 7-2
Repository, 1-12
Repository Field Names, D-1
Suspended Mode, 7-5
SVC Number, 7-2
Termination, 7-3, 7-6
Utilities, 9-146
Utility Statement Syntax, 9-146
CONTROL-T Control Table. See TCT
CONTROL-T Utilities
Summary, 9-5
CONTROL-V
Customization, 4-1
Initialization, 4-1
Reports, 4-112
CONTROL-V Monitor
Indexing, 1-7
CONTROL-V Utilities
Summary, 9-3
CONVABF Job
CONVC4MD Job
CTTDLD Utility, 9-170
CONVC5MD Job
CONVERT Mode
Converting
Volume Records, 9-169
CONVGRP Job
CONVJAF Job
CONVLCTL Job
CONVMOD Job
CONVREP Job
CONVRMDB Job
CONVTMDB Job
Copy Count
Active User Report List, 4-112
Report List Files, 4-110
COPY Parameter
CTBDBVCG Utility, 9-81
CTBDBVCP Utility, 9-83
Copying
Active Report List, 9-99
Conditions/Resources File, 9-20
CTB File, 9-77
Database Records, 9-271
IOA Log File, 9-21
Message Statistics File, 9-133
Permanent User Report List (CTD),
4-111
Rule Activity File, 9-90
Trace File (CTT), 9-152
Variable Files (CTB), 9-83
COPYTOLOG Parameter
Utility IOACPLOG, 9-22
COPYTOSEQ Parameter
COSBOUNZ Command (CTO), 5-19
COSDOWN Command (CTO), 5-19
COSINI Command (CTO), 5-19
COSMOS
Commands (CTO), 5-19
CTOCTI Utility, 9-136
Overview, 1-12
COSTERM Command (CTO), 5-19
COSUP Command (CTO), 5-19
COUNT Parameter
CP Command
MVS Under VM, 3-80
CPU Configuration
Shared DASD, 3-63
CPU Partitioning
Index
CPU Workload Balancing
CPUID Keyword
SMF Record, D-14
Trace Record, D-13
CPUS Installation Parameter
Creating
Trace Files, 9-160
CRECC Keyword
Dataset Record, D-2
CRECPU Keyword
Dataset Record, D-2
CREDDN Keyword
Dataset Record, D-2
CREDS Field
CREDT Keyword
Dataset Record, D-2
CREFABF Job
Utility CTBABI, 9-75
CREFBKP Job
CREFDBM Job
CREFDBV Job
CREFGRP Job
CREFJAF Job
CREFREP Job
CREJBN Keyword
Dataset Record, D-2
CREJOBID Keyword
Dataset Record, D-2
CRESTEP Keyword
Dataset Record, D-2
CRETM Keyword
Dataset Record, D-3
CREUAD Keyword
Dataset Record, D-3
CREUSER Keyword
Dataset Record, D-3
Cross Memory Interfaces
Cross-Memory Services
Cross-Product Interfaces
CTM and CTD, 4-26
CTT and CTR, 7-29
CRPEGM Keyword
Dataset Record, D-2
CSA Usage
Above 16M Line, 5-11
Below 16M Line, 5-11
CSECT
IOA Exits, 10-4
CSECT List
CTBABI Utility
Summary, 9-5
CTBBAO Program
New Day Procedure (CTB), 6-1
CTBCHK Program
CTBCMP Utility
Compile Rules, 9-76
CTBDBCP Utility
Copy CTB File, 9-77
Description, 9-77
Summary, 9-4
CTBDBIB Utility
Rebuild CTB Index, 9-79
Summary, 9-5
CTBDBST Utility
Summary, 9-5
CTBDBVCG Utility
Summary, 9-4
Variable Generations, 9-81
CTBDBVCP Utility
Copy CTB Variables, 9-83
Summary, 9-4
CTBDBVDL Utility
Deleting Variables, 9-86
Sujmmary, 9-4
Index
CTBDBVIG Utility
Summary, 9-4
Variable File Integrity, 9-88
CTBFRM Utility
Description, 9-89
Summary, 9-5
CTBIUTI Program
Utilities Screen (CTB), A-1
Utilities Screen (CTD), A-1
CTBJAFCP Utility
Summary, 9-5
CTBJAFDL Utility
Summary, 9-5
CTBJAFIG Utility
Rule Activity File Integrity, 9-94
Summary, 9-5
CTBNDAY
CTBPDA Program
CTBTABS Program
Active Balancing Environment (CTB),
A-1
CTBTAMS Program
Active Missions Screen (CTD), A-1
CTBTATF Program
File Transfer Status (CTD/PC), A-1
CTBTBAL Program
Balancing Mission Definition (CTB),
A-1
CTBTDAT Program
Database Variables Definition (CTB),
A-1
CTBTJBL Program
Rule Activity Screen (CTB), A-1
CTBTRLB Program
Rule Definition Screen (CTB), A-1
CTBVXRF Utility
Summary, 9-5
CTBX001 Exit
CTBX003 Exit
CONTROL-B Database, 10-28
CTBX004 Exit
CTBX008 Exit
CTBX009 Exit
CTB Shout Facility, 10-28
CTD34F Program
CTD Daily, 4-12
CTDAMUTI Utility, 9-3
CTDAPA Routine
CTDAS
Page On Demand, 1-6
CTDBKDAY Procedure
CTDBLXRP Utility
Description, 9-95
Summary, 9-3
CTDBRQ Program
CTD Daily, 4-11
CTDCA2P Utility
Copy User Report List, 9-99
CTDX012 Exit, 10-18
Description, 4-111
Summary, 9-3
CTDCAMF Utility
Compress Active Missions File, 9-96
Summary, 9-3
CTDCATF Utility
Compress Active Transfer File, 9-98
CTD Daily, 4-11
Summary, 9-3
CTDCCU Utility
Deleting CDAM Files, 9-101
CTDCHK Program, 4-9
CTD Daily, 4-11
CTDCLHIS Utility
Clean History Report List, 9-103
Description, 4-114
Summary, 9-3
Index
CTDCP2A Utility
Copy User Report List, 9-104
CTDX013 Exit, 10-18
Description, 4-111
Summary, 9-3
CTDDELRP Utility
Deleting Reports, 9-106
Job Specific Report Entries, 4-99
Migration Mission Name, 4-83
Summary, 9-3
CTDDFLTS Member
IOA SECUDATA Library, 4-56
CTDDIB Utility
Access Method Index, 9-114
Rebuild Index Component, 4-119
Summary, 9-3
CTDDIG Utility
Description, 9-115
Summary, 9-3
CTDDJDE Routine
CTDFRAMF Procedure
CTDFRATF Procedure
ATFSIZE Parameter, 9-98
CTDFRCOM Utility
Summary, 9-3
CTDFRM Program
CTD Daily, 4-11
CTDGRQ Program
CTD Daily, 4-12
CTDILY Program
DD Statements, 4-15
CTDMISRQ CLIST
Mission Scheduling, 4-16
CTDNDAY Procedure
Exit IOAX012, 10-7
CTDNDAY Started Task
Abend, 4-5
CTDOPR Utility
Exit IOAX012, 10-7
CTDPARM Member
CONTROL-D Printer, 4-42
CTDPDA Program
CTD Daily, 4-12
CTDPRDAY Procdure
Printing XE "CTDBKDAY
Procedure:Backup Missions" XE
"CTDBKDAY Procedure:Migration
Missions" XE "Decollating
Mission:CTDRPDAY Procedure" XE
"Printing Mission:CTDPRDAY
Procedure" XE "Backup
Mission:CTDBKDAY Procedure" XE
"Migration Mission:CTDBKDAY
Procedure" XE "Restore
Mission:CTDRSDAY Procedure"
Missions, 4-16
CTDPRINT Monitor Procedure
CTDPRINT Procedure
Printers Control Monitor, 4-39
CTDPRQ Program
CTD Daily, 4-11
CTDRPDAY Procdure
Decollating Missions, 4-16
CTDRRQ Program
CTD Daily, 4-12
DD Statements, 4-28
Production Control System, 4-27
CTDRSDAY Procdure
CTDSE24 Security Module
Recipient Tree, 10-20
Report Access, 4-60
CTDSE26 Security Module
External Destinations, 4-6
CTDSMFRP Utility
Summary, 9-3
CTDSRQ Program
CTD Daily, 4-11
CTDTDPC Program
File Transfer Screen (CTD), A-1
CTDTDTM Program
IOA Calendar Screen, A-1
CTDTMIS Program
Mission Definition Screen (CTD/V), A-1
Index
CTDTNRS Program
IOA Manual Conditions Screen, A-1
CTDTREP Program
Decollating/Indexing (CTD/V), A-1
CTDTUSR Program
User Reports Screen (CTD), A-1
CTDTUTR Program
Recipient Tree Screen (CTD), A-1
CTDUDJP Macro
DJDE Printing, 4-52
CTDUFDEL Job
Deleting IOA Access Method Files,
4-120
CTDUFDIB Member
JCL Library, 4-119
CTDULD Utility
Description, 9-116
Summary, 9-3
CTDUPBKP Utility
Backup Retention and Volser Info,
9-117
Migrated Files, 4-84
Summary, 9-3
CTDX001 Exit
Production Control Systems, 4-27
Scheduling with CTM, 4-23
CTDX002 Exit
Printer Commands, 10-14
CTDX003 Exit
Banner Exit, 10-14
Banner Tailoring, 10-21
CTDX003 User Exit
Banner Exit, 4-48
CTDX004 Exit
Default Global Ruler, 10-16
User Reports List, 10-14
CTDX005 Exit
Customization, 4-50
Printing to a File, 4-49
CTDX006 Exit
SMF Exit, 10-17
CTDX007 Exit
Reports With Special Characters, 10-17
CTDX008 Exit
Update Active Missions, 10-17
CTDX009 Exit
Print Job Tailoring, 10-17
CTDX010 Exit
Backup Job Tailoring, 10-17
Migration Job, 4-94
CTDX011 Exit
Restore Job Tailoring, 10-17
CTDX012 Exit
CTDCA2P Utility, 10-18
CTDX013 Exit
CTDCP2A Utility, 10-18
CTDX014 Exit
Banner Tailoring, 10-21
Immediate Print Request, 10-18
CTDX014User Exit
Banner Exit, 4-48
CTDX015 Exit
Immediate Print Request, 10-18
CTDX016 Exit
Recipient Synonyms, 10-18
CTDX017 Exit
Shout Facility, 10-18
CTDX018 Exit
EXIT CDAM Parameter, 10-19
CTDX019 Exit
Active Transfer File, 10-19
CTDX020 Exit
Print Plan File, 10-19
CTDX021 Exit
CTDX022 Exit
User File Access, 10-19
CTDX023 Exit
CTDX023C Member
SECUDATA Library, 10-19
CTDX023C User Exit
XCOM 6.2 Support, 4-65
CTDX024 Exit
Index
CTDX024 User Exit
Report Access, 4-60
CTDX026 Exit
CTDX026 User Exit
External Destinations, 4-6
CTL103I Message
WorkLoad Monitor, 11-2
CTL106I Message
CTL108I Message
Reload INSTPARM, 11-4
Reloading Programs, 11-5
CTL113I Message
CTL122I Message
Trace Facility, 11-17, 11-18
CTL136I Message
Participant Information, 11-29
Pipe Information, 11-23
CTL144I Message
CTL148I Message
Pipe Display, 11-22
CTL149I Message
Pipe Display, 11-22
CTL150I Message
Pipe Display, 11-22
CTL151I Message
Pipe Display, 11-22
CTL263I Message
Rule Deleting, 11-7
Rule Loading, 11-6
CTL264I Message
Rule Loading, 11-6
CTL268I Message
Display Command, 11-21
CTL269I Message
CTL270I Message
CTLABMP Program
Reloading, 11-5
CTLADSM Program
Reloading, 11-5
CTLAIO Program
Reloading, 11-5
CTLAMPS Program
Reloading, 11-5
CTLAPBM Program
Reloading, 11-5
CTLAPLM Program
Reloading, 11-5
CTLAPLS Program
Reloading, 11-5
CTLAPST Program
Reloading, 11-5
CTLAREQ Program
Reloading, 11-5
CTLASMF Program
Reloading, 11-5
CTLGASM Program
Reloading, 11-5
CTLHASH Program
Reloading, 11-5
CTLMLSS Program
Reloading, 11-5
CTLPARM Member
INSTCTL Library, 11-4
CTLPLSS Program
Reloading, 11-5
CTLPPLM Program
Reloading, 11-5
CTLRLLST Member
Rule Load List, 11-6
CTLRMGR Program
Reloading, 11-5
CTLRSRH Program
Reloading, 11-5
CTLSE03 User Exit
Reloading, 11-5
CTLSMGT Program
Reloading, 11-5
CTLX003 User Exit
Reloading, 11-5
CTLX004 User Exit
Reloading, 11-5
CTM262S Message
Index
CTM262W Message
Sysout Problems, 3-49
CTM2RULE Utility
CMEM Rules, 5-3
CTMAESIM Utility
Summary, 9-2
CTMAJO Routine
Printing Missions (CTD), 4-34
CTMBGRP Utility
Group Scheduling Tables, 9-59
Summary, 9-2
CTMBLDAE Utility
Summary, 9-2
CTMBLT Utility
Summary, 9-2
CTMCAJF Utility
IGNORE/SELECT Conditions, 3-18
Restoring the Active Jobs File, 3-85
Summary, 9-2
CTMCHK Program, 3-25
CTMCJOBS CLIST, 4-24
CTMCLRES Utility, 3-12, 3-18
CTMCMEM Operator Command, 3-2
CTMDAILY Procedure, 3-23
DAREPMIS DD Statement, 4-24
CTMDAS Program
CTMEDA Program
CTMFRCKP Utility
Description, 9-68
Restoring the Active Jobs File, 3-85
Summary, 9-2
CTMFRJNL Utility
Description, 9-69
Summary, 9-2
CTMFRM Program, 3-18
History Jobs File, 3-25
CTMHELP
Allocation, 2-11
CTMILU Program
CTMILY Program
CTMISCA Member, 1-18
CTMISCB Member, 1-18
CTMISR Routine
1-19
CTMJAIS Message
IOADDC Module, 3-31
CTMJOB Program
CTMJOB Utility
Job Ordering, 3-20
Summary, 9-2
CTMJSA Utility
Description, 9-70
CTMLDNRS Maintenance Job, 3-12
CTMLEVEL Macro, 2-49
CTMMMSG Macro, 2-49
CTMOPR Started Task
JES Priority, 3-51
CTMOPR Utility
Exit IOAX012, 10-7
CTMPDA Program
Daily Processing (CTM), 3-26
CTMRAFL Report
CTMRCAL Utility
Summary, 9-2
CTMRELRS Utility
Summary, 9-2
CTMRNSC Report
CTMRSTR Utility
Description, 9-73
Running Requirements, 3-87
Summary, 9-2
CTMSBLK Macro
Index
CTMSEND Macro
CTMSFLD Macro
Format, 2-18
CTMSIM Utility
Summary, 9-2
CTMSSTA Macro
CTMTAPUL Utility
Exit CTMX017, 10-10
Summary, 9-2
CTMTBUPD Utility
Summary, 9-2
CTMTRCM Program
CMEM Definition, A-1
CTMTRES Program
IOA Conditions/Resources Screen, A-1
CTMTSTA Program
Status Screen (CTM), A-1
CTMTTSO Program
IOA TSO Command Processor, A-1
CTMX001 Exit
Job Ordering, 10-9
CTMX003 Exit
Sysout Scanning, 10-9
CTMX004 Exit
Job Scheduling, 10-9
CTMX005 Exit
Job Statistics, 10-9
CTMX008 Exit
CTMX010 Exit
Quick Submit Facility, 10-10
CTMX011 Exit
CTM Shout Facility, 10-10
CTMX011A User Exit
CTMX013 Exit
Job Statistics Screen, 10-10
CTMX014 Exit
Editing JCL, 10-10
CTMX015 Exit
Job End, 10-10
CTMX016 Exit
Job Tracking, 10-10
CTMX017 Exit
Tape Pull List, 10-10
CTMX018 Exit
Elapsed Time, 10-11
CTMX019 Exit
External Writer Initialization, 10-11
CTMXRF Utility
Summary, 9-2
CTO78xI Message
OpenEdition Initialization, 5-21
CTO79xI Message
OpenEdition Deactivation, 5-21
CTOAIDT Module
CMEM Executor, 5-2
CTOALOCP Utility
Back up Automation Log, 5-18
Back Up Automation Log, 9-144
Summary, 9-4
CTOCOLBF Job
Variable Databae Column File, 9-30
CTOCOLBI Job
CTODBIB Utility, 9-139
CTOCSF Utility
Copy Statistics File, 9-133
Statistics File Size (CTO), 5-17
Summary, 9-4
CTOCSFJ Member
CTOCTA Utility
Check Address Space, 9-134
Summary, 9-4
CTOCTI Utility
Generate SYSIMAGE Input, 9-135
Summary, 9-4
SYSIMAGE Facility, 9-137
CTODBIB Utility
Description, 9-138
Rebuild CTO Index, 9-138
Summary, 9-4
CTODBSBF Job
Variable Database Definition File, 9-30
CTODBSBI Job
CTBDBIB Utility, 9-139
Index
CTOGATE
Communication Gateway, 1-6
CTOOBJFL File
CONTROL-O PARM Library, 9-135
CTOOEDSC Procedure
OpenEdition Shutdown, 5-22
CTORSTM Utility
Message Statistics Report, 9-140
Summary, 9-4
CTOTALO Program
Automation Log (CTO), A-1
CTOTAOP Program
Automation Options (CTO), A-1
CTOTARF Program
Rule Status Screen (CTO), A-1
CTOTEST Utility
Simulate CTO Environment, 9-141
Summary, 9-4
CTOTINQ Program
Inquire/Update Screen (CTT), A-1
CTOTKIN Program
External Volume Check-In (CTT), A-1
CTOTMSC Program
Message Statistics Screen (CTO), A-1
CTOTOMP Program
Rule Definition Screen (CTO), A-1
CTOTPLD Program
Pool Definition Screen (CTT), A-1
CTOTRLD Program
Rule Definition Screen (CTT), A-1
CTOTVLD Program
Vault Definition Screen (CTT), A-1
CTOVARBI Job
CTOWTO Module
Refreshing, 5-2
CTOX001 Exit
Ordering/Forcing a Rule, 10-11, 10-31
CTOX002 Exit
Rule Loading, 10-11, 10-31
CTOX003 Exit
DO KSL/TSO Statements, 10-31
CTOX004 Exit
Automation Options, 10-31
CTRX001 Exit, 10-12
Interface to CTT, 7-29
CTRX001G Driver Exit
CTRX001G Exit
Description, 10-12
Driver Exit, 10-12
Roof Exit, 10-12
CTRX014 Exit
Description, 10-13
CTTACCDB Macro
Return Codes, 7-56
Work Area, 7-54
CTTACP Utility
Copy Trace File, 9-152
Trace File Size, 7-23
CTTADBP Macro
Call From CTTACCDB, 7-55
Variables, 7-56
CTTAFR Utility
Format/Initialize Trace File, 9-155
Summary, 9-5
CTTARC Macro
Trace File Mapping, 7-17
CTTBIX Utility
Media, 7-20
Rebuild Indices (CTT), 7-25
Rebuild MDB Index, 9-156
Rebuild MDB Index File, 7-27
Summary, 9-6
CTTCCU Utility
Summary, 9-3
CTTCHKDB Macro
CTTCMDB Job
Utility CTTCRDF, 9-159
CTTCMDB Utility
MDB Format (CTT), B-2
CTTCRDF Utility
Allocate/Format CTT Files, 9-158
Summary, 9-6
CTTCSTK Job
Utility CTTCRDF, 9-159
Index
CTTCSTK Utility
Stacking Database (CTO), B-2
CTTCTRC Utility
Allocate/Format Trace File, 9-160
Summary, 9-5
Trace File (CTT), B-2
CTTDAY Procedure
New Day Procedure (CTT), 7-7
CTTDBDLD Utility
Load MDB and STK Files, 9-161
Reload Stacking Database, 7-24
Summary, 9-6
CTTDBDUL Utility
Loading Files, 9-161
Summary, 9-6
Unload MDB and STK Files, 9-162
Unload Stacking Database, 7-24
Unloading Files, 9-162
CTTDBF Utility
Format an Existing File, 9-163
Format MDB Index File, 7-27
CTTDBIB Utility
Rebuild Stacking Statistics Index, 9-164
Stacking Database, 7-24
Summary, 9-6
CTTDBID Utility
Check Data File Integrity, 9-165
Rebuild Indices (CTT), 7-25
Summary, 9-6
CTTDBII Utility
Index File Integrity, 9-166
Summary, 9-6
CTTDBPRT Utility
Print Database Records, 9-167
Summary, 9-6
CTTDBTP Macro
Call From CTTACCDB, 7-55
CTTDDX Macro
Index Mapping, 7-13
CTTDLD Utility
Add/Delete/Convert Volumes, 9-169
Summary, 9-6
CTTDLX Macro
Index Mapping, 7-13
CTTDVX Macro
Index Mapping, 7-13
CTTFMDB Job
CTTDBF Utility, 9-163
CTTFSTK Job
CTTGTCT Macro
Real-Time TCT Address, 7-33
Return Codes, 7-33
TCT Address, 7-60
CTTGVL Utility
Description, 9-173
Summary, 9-5
CTTIDB Utility
Common Integrity Errors, 7-20
Description, 9-175
Integrity Errors, 7-19
MDB Integrity, 7-19
Summary, 9-6
CTTINIT Procedure
Description, 7-3
Parameters, 7-3
Starting CONTROL-T, 7-2
CTTIOS Macro
API Access of MDB, 7-36
Format, 7-36
Reason Codes, 7-37, 7-56
Return Codes, 7-39, 7-56
CTTMEDDF Installation Parameter
CTTSBD Utility, 9-245
CTTMER Utility
Merge Records, 9-177
Summary, 9-6
Examples, 9-189
Field Names, D-1
Field/Value Specification, 9-187
Manual Update of the MDB, 7-21
Return Codes, 9-188
Summary, 9-6
CTTRBXLC Report
Index
CTTRCHK1 Report
CTTRCLN Report
CTTRCV Utility
Database Recovery, 7-25
Examples, 9-194
MDB Recovery, 9-191
Return Codes, 9-194
Selective Recovery, 7-27
Summary, 9-6
CTTRDCRE Report
CTTRDELV Report
CTTRDUPD Report
CTTREDM Report
CTTRFSCR Report
CTTRINV Report
CTTRINVT Report
CTTRLACV Report
CTTRLAVJ Report
CTTRLRTV Report
CTTRM10V Report
CTTRM25D Report
CTTRMACV Report
CTTRMOVW Report
CTTRNRTR Report
CTTROUTL Report
CTTRPT Utility
Report Generation, 9-195
Sample Reports, 9-206
Summary, 9-6
CTTRRCLV Report
CTTRRTNP Report
CTTRSCRD Report
CTTRSM Utility
Description, 9-214
Summary, 9-5
CTTRSO dsect
IOA MACRO Library, 7-61
CTTRTM Utility
Condition Codes, 9-231
Cyclic Datasets, 10-29
Examples, 9-231
Exit CTTX007, 10-29
Parameters, 9-223
Retention Management, 9-173, 9-218
Summary, 9-6
CTTRUTIL Report
CTTRVBOX Report
CTTRVUPD Report
CTTRWDCP Report
CTTSAM3 Member
IOA SAMPLE Library, 7-65
CTTSBD Utility
Description, 9-234
Summary, 9-5
CTTSBGRP DD Statement
CTTSCA Utility
Description, 9-264
Summary, 9-5
CTTSPL Utility
CTTMER Utility, 9-177
Extract MDB Info, 9-271
Summary, 9-6
Index
CTTSTK Macro
Statistics Database Data File, 7-18
CTTSTK Utility
Build/Update STK File, 9-276
Summary, 9-5
CTTSTKR Utility
Description, 9-279
Summary, 9-5
CTTSTX Macro
Statistics Database Index File, 7-18
CTTSYNC Utility
Description, 9-283
Summary, 9-6
CTTTCT Macro
CONTROL-T Control Table, 7-31
CTTTLD Routine
Return Codes, 7-32
CTTTPI Utility
Activation, 9-288
Examples, 9-298
Invoking, 9-296
Return Codes, 9-297
StorageTek Robot Support, 9-297
Summary, 9-6
Tape Init/Erase/Mapping, 9-285
CTTTPITP DD Statement
CTTTRB Utility
Backup MDB and Trace File, 9-300
Summary, 9-5
CTTUDB Utility
Summary, 9-6
CTTVTM Utility
Cyclic Datasets, 10-29
Examples, 9-307
Exit CTTX007, 10-29
Summary, 9-6
Vault Management, 9-301
CTTX001 Exit
Rule Loading, 10-29
CTTX002 Exit
Dynamic Stacking, 10-29
CTTX003 Exit
SVC Operations, 10-29
CTTX004 Exit
Dataset/Volume Definition, 10-29
CTTX005 Exit
Abending a Job, 10-29
CTTX006 Exit
MDB Update, 10-29
CTTX006 User Exit
CTTX007 Exit
Cyclic Dataset Processing, 10-29
CTTX008 Exit
Robot Interface, 10-30
CTTX008 User Exit
CTTX010 Exit
Stackable Volume Search, 10-30
CTTX011 User Exit
CTVCLMIG Utility
Clean Migrated Report List, 9-123
Description, 4-113
Summary, 9-3
CTVDELI Utility
Deleting DASD Index Files, 9-125
Summary, 9-3
CTVINDEXnn Parameter
XEROX Reports, 4-58
CTVJAR Utility
Description, 9-129
Main Index Format, 4-98
Summary, 9-3
CTVPACK.BAT File
CTVPACK.EXE File
CTVSMF Macro
SMF Record Format, 4-120
CTVUNMIG Utility
Summary, 9-3
CTVUNMIG Utiltiy
Description, 9-132
CTVX001 Exit
Index File Value Retrieval, 10-20
Index
CTVX002 Exit
IOASMON Archive Server, 10-20
CTVX002 User Exit
SMF Record, 4-120
CURR-RDR Field
Pipe Information, 11-24, 11-32
CURR-WTR Field
Customization
Allocation of Files, 2-10
Color Support, 2-26
Commands, C-1
Exit CTDX005, 4-50
IOA Messages, 2-49
IOA Profiles, 2-33
IOA Screens, 2-17
Limited Access to IOA Products, 2-8
PFKeys, 2-13
Screen Definition, 2-36
CUSTOMIZE Option
IOA Installation Menu, 2-37
Customizing
MAINDAY Table, 3-20
CYCLE Type Retention
CYCLECNT Parameter
CTTPARM, 9-301
CTTPARM Member, 9-221
CYCLES Retention
Cyclic Dataset
Processing Parameters, 10-29
Cyclic Job
D
D Parameter
D37 Abend
Global AutoEdit Library, 5-27
DA34F DD Statement
IOAOPR Utility, 9-50
DAALOCIN DD Statement
Dynamic File Allocation, 4-29
DAALPPRM DD Statement
Utility CTOALOCP, 9-144
DAALTALC DD Statement
Allocation Customization, 2-12
DAAMF DD Statement
CTDRRQ Program, 4-28
DAAPA DD Statement
AFP Control Parameters, 4-44
DABANNER DD Statement
DABCLIN DD Statement
DABKPLST DD Statement
DABRULE DD Statement
CTB Rule Libraries, 6-5
DACHK DD statement, 4-9
DACHK DD Statement
CTBNDAY Procedure, 6-2
CTMDAILY Procedure, 4-24
DACOPPRM DD Statement
CTDCAMF Utility, 9-96
Utility CTMCAJF, 9-62
DACRSIN DD Statement
DACTMLST DD Statement
CMEM Rule List, 5-41
Rule Table List (CMEM), 3-35, 5-4
DADJDE DD Statement
DADJOB DD statement
DADJOB DD Statement
Migration Job JCL, 4-94
Restore Mission, 4-80
DADSKL DD statement
DADSKL DD Statement
Index
DADUMP DD Statement
Archive Server Procedure, 4-108
CMEM Procedure, 3-44
Dump Print, 11-19
DAFILE DD statement
DAFRMIN DD Statement
IGNORE/SELECT Statements, 3-18
New Day Procedure (CTM), 4-29
DAGENLST DD Statement
Generic Decollating, 4-14
DAGENUSR DD Statement
Generic User List, 4-22
DAGLBLST DD Statement
Global Variables, 5-23
DAGLBLST Member
CONTROL-O PARM Library, 5-26
Daily Checkpointing, 3-15
Daily Processing
Description, 1-7
DAILYPRD Job
Sample User Daily, 3-12
DAILYSYS Job
Sample User Daily, 3-12
DAISCNn DD Statement
1-18
DAJOB DD Statement
DALCPPRM DD Statement
DALNRIN DD Statement
New Day Procedure (CTM & CTD)),
4-30
DALOG DD Statement
Utility CTMBGRP, 9-59
DALOGCUR DD Statement
DALOGSEQ DD Statement
Copy IOA Log, 9-21, 9-22
DAMDB DD Statement
Media Database, 7-9
DAMDI DD Statement
Media Database, 7-9
DAOUT DD Statement
DAOVRALC DD Statement
Allocation Customization, 2-11
DAPOOLS DD statement
DAPOOLS DD Statement
DAPROG DD Statement
New Day Processing (CTM), 3-23
DAPRTLST DD Statement
DAREPIN DD Statement
Utility CTORSTM, 9-140
DAREPLST DD Statement
DAREPMIS DD Statement
Decollating Mission Library, 4-24
Decollating Missions Library, 4-23
DARSTLST DD Statement
DARULLST DD statement
DARULLST DD Statement
CTO Rule List, 5-41
Loading CONTROL-O Rules, 5-15
Loading Rules (CTO), 5-4
Rule Load List, 11-6
DASD
Deleting Index Files, 9-125
Migration Media, 4-88
DASD, Shared
DASMFIN DD Statement
Index
DASORTPR DD Statement
Active User Report Sorting, 4-118
Data Area Dump
Printing, 11-19
Data Extraction
Media Database, 9-195
Data File
Fields, 7-18
Printing (CTT), 9-167
Data File Parameters
CTTCTRC Utility, 9-160
DATA Parameter
@FIELD Display Format Line, 2-23
@HEADER Display Format Line, 2-22
@VAL Display Format Line, 2-24
CTTIOS Macro, 7-38
Data Space Information
Displaying, 11-19
Database (CTT)
Printing, 9-167
DATAC= Parameter
Dataset
Multi-Volume, 7-15
Dataset Definition
Exit CTTX004, 10-29
Dataset Event
CONNECT DIRECT Support, 3-30
Dataset Group Stacking
Dataset Groups
DATASET Parameter
Dataset Record
Index File, 7-13
Keywords, D-2
Volume Record, 7-13
DataWare OSS
Date
Printing Mission Scheduling, 4-34
Date Control Record
Checkpointing, 3-15, 3-20
DD Statement DACHK, 3-20
Decollating Scheduling (CTD), 4-14
Format, 3-21, 6-3
Format CTD, 4-8
PARM Library, 3-21
User Daily Job (CTM), 3-10, 3-25
DATE Field
Index File Name, 4-92
Date Format
INCLUDE/EXCLUDE Statements, D-2
DATE Keyword
SMF Record, D-14
Trace Record, D-13
DATE Parameter
CTDCCU Utility, 9-101
Date Range
IOA Log, 9-21
DATEREC
Date Control Record (CTM), 3-13
DATERECU
Date Control Record (CTM), 3-13
DATETIME Field
Migration Timestamp, 4-91
DATRC DD Statement
DAVLTS DD statement
DAVLTS DD Statement
DAxxxLST
Mission List, 4-16
Daylight Savings Time
changing the clock, 3-32
Index
DAYS Parameter
CTBJAFDL Utility, 9-92
DAYS Statement
DAYTIME Parameter
DBABFB Parameter
CTBFRM Utility, 9-89
DBBKPB Parameter
DBCS Terminals
Japanese Kanji Support, 3-55
DBFILE Parameter
CTBDBCP Utility, 9-77
CTDDIG Utility, 9-115
CTDULD Utility, 9-116
IOADBSR Utility, 9-31
IOADIG Utility, 9-35
IOADII Utility, 9-36
IOADPT Utility, 9-39
IOADUL Utility, 9-41
DBFILEB Parameter
DBFILEI Parameter
CTTDBDLD Utility, 9-161, 9-162
CTTDBDUL Utility, 9-162
DBFILEO Parameter
CTTDBDLD Utility, 9-161
DBFILET Parameter
CTTDBIB Utility, 9-164
CTTDBID Utility, 9-165
CTTDBII Utility, 9-166
CTTDBPRT Utility, 9-167
Media Database, 7-21, 7-24
Trace File, 7-23
DBGJOB Argument
Trace Facility, 11-17
DBGLEVEL Parameter
CTTSPL Utility, 9-274
DBGLVL Parameter
CTTIOS Macro, 7-37
DBGPIPE Argument
DBINOUT Attribute
Variable Database, 5-26
DBINPUT Attribute
DBJAFB Parameter
DBJAFI Parameter
CTBJAFCP Utility, 9-90
DBJAFO Parameter
DBPREFA Parameter
IOAFRLOG Utility, 9-42
IOAFRNRS Utility, 9-43
IOAFRRES Utility, 9-44
DBPREFT Parameter
Trace File, 7-23
DBPREFx Parameter
CTMFRJNL Utility, 9-69
DBPROT Attribute
DBREPB Parameter
DBREPI Parameter
DBREPO Parameter
DBSRTPRM DD Statement
Active User Report Sorting, 4-118
DBTEMP Attribute
DBUNITT Parameter
DBVOLT Parameter
Index
DCF
IBM word processor, 4-44
DCHANGED Keyword
Dataset Record, D-3
DCHANGET Keyword
Dataset Record, D-3
DCHANGEU Keyword
Dataset Record, D-3
DD Statement
DA34F, 9-50
DABCLIN, 9-8
DACHK, 3-20
DAJOB, 3-20
DD Statements
DDNAME Field
Pipe Info Display, 11-22
DDNAME Parameter
CTTTPI Utility, 9-293, 9-294, 9-295
DDNAMES Index
DDSACCT Keyword
Dataset Record, D-2
DDSBLK Keyword
Dataset Record, D-2
DDSBLKC Keyword
Dataset Record, D-2
DDSCCC Keyword
Dataset Record, D-2
DDSCCPU Keyword
Dataset Record, D-2
DDSCDDN Keyword
Dataset Record, D-2
DDSCDT Keyword
Dataset Record, D-2
DDSCJBN Keyword
Dataset Record, D-2
DDSCJID Keyword
Dataset Record, D-2
DDSCPGM Keyword
Dataset Record, D-2
DDSCSTP Keyword
Dataset Record, D-2
DDSCTM Keyword
Dataset Record, D-3
DDSCUAD Keyword
Dataset Record, D-3
DDSCUSER Keyword
Dataset Record, D-3
DDSDEN Keyword
Dataset Record, D-3
DDSDSN Keyword
Dataset Record, D-4
Trace Data, D-14
DDSEXCP# Keyword
Dataset Record, D-3
DDSEXPD1 Keyword
Dataset Record, D-3
DDSEXPT1 Keyword
Dataset Record, D-3
DDSFLG1 Keyword
Dataset Record, D-4
DDSJEXPD Keyword
Dataset Record, D-5
DDSLACS Keyword
Dataset Record, D-5
DDSLBLNM Keyword
Dataset Record, D-4
DDSLUSER Keyword
Dataset Record, D-3
DDSMDT Keyword
Dataset Record, D-3
DDSMTM Keyword
Dataset Record, D-3
DDSRBA Keyword
Trace Data, D-14
DDSRCPU Keyword
Dataset Record, D-5
DDSRDDN Keyword
Dataset Record, D-5
DDSRDT Keyword
Dataset Record, D-5
DDSRECFM Keyword
Dataset Record, D-5
DDSRECL Keyword
Dataset Record, D-5
Index
DDSRJBN Keyword
Dataset Record, D-5
DDSRPGM Keyword
Dataset Record, D-5
DDSRSTP Keyword
Dataset Record, D-5
DDSRTM Keyword
Dataset Record, D-5
DDSRTORG Keyword
Dataset Record, D-5
DDSRTYPE Keyword
Trace Data, D-14
DDSRUAD Keyword
Dataset Record, D-5
DDSSMCL Keyword
Dataset Record, D-5
DDSSTAT Keyword
Dataset Record, D-4
DDSTRTCH Keyword
Dataset Record, D-6
DDSUSED Keyword
Dataset Record, D-4
DDSUSER2 Keyword
Dataset Record, D-5
DDSVOLS# Keyword
Dataset Record, D-6
DDSVOLSR Keyword
Dataset Record, D-5
DDSWCC Keyword
Dataset Record, D-6
DDSWCPU Keyword
Dataset Record, D-6
DDSWDDN Keyword
Dataset Record, D-6
DDSWDT Keyword
Dataset Record, D-6
DDSWJBN Keyword
Dataset Record, D-6
DDSWPGM Keyword
Dataset Record, D-6
DDSWSTP Keyword
Dataset Record, D-6
DDSWTM Keyword
Dataset Record, D-6
DDSWUAD Keyword
Dataset Record, D-6
Deactivating
Archive Server (CTV), 4-6
CDAM, 4-5
CMEM Monitor, 3-2
CMEM Rule Table, 3-37
CONTROL-M Monitor, 3-1
Generic Processing (CTD), 4-5
VTAM Monitor, 2-7
DEADLINE Command
CONTROL-M, 3-4
Deadline Scheduling
Refreshing (CTM), 3-4
DEBUG Argument
DEBUG Command
CMEM, 3-43
CONTROL-O, 5-30
Debug Messages
Debugging
CMEM Rules, 3-43
CONTROL-O, 5-30
DECFROM Parameter
DECMIS.BIN File
DECMIS.TXT File
DECOLLATED Status
Decollating
CONTROL-D/Image Files, 4-68
Decollating Mission
CTDRPDAY Procedure, 4-16
Generic, 4-19
Scheduling, 4-13
Decollation Mission
Overview, 4-19
Decollation Server
CTDX026 Exit, 10-20
Description. See Decollation Server
Index
NT Environment, 4-6
UNIX Distribution, 4-6
DECTO Parameter
Dedicated Device Mode
CART Media, 4-100
DEFABEND Parameter
DEFALO Utility
Automation Log (CTO), B-2
DEFAULTEDIT Parameter
DEFER Parameter
Exit CTDX005, 4-51
DEFEXPDT Parameter
DEFGLOB Utility
Global Variables (CTO), B-2
DEFGRP Member, 2-31
DEFGRPI Member, 2-31
DEFHST Member, 2-31
DEFHSTI Member, 2-31
Definition Screens
Exit IOAX028, 10-7
DEFPARMx Member
Processing Rules, 8-9
DEFPRTS Parameter
Defragmentation
CONTROL-T Databases, 7-19
Trace File, 7-23
DEFSTAT Member
DEFSTAT Utility
Message Statistics File (CTO), B-2
Deleting
CDAM Files, 9-101
CTB Variables, 9-86
DASD Index Files, 9-125
MDB Volume, 9-182
Prerequisite Conditions, 9-13
Reports (CTD), 9-106
Rule Table (CTO), 5-7
Unneeded Jobs, 9-65
Volumes from MDB, 9-169
Deletion Rules
Utility CTDDELRP, 9-110
DELGR Parameter
CTBDBVDL Utility, 9-86
DELVOL Function
DELYBLK Parameter
DEN Parameter
Exit CTDX005, 4-51
DENSITY Keyword
Dataset Record, D-3
Dependency
CTM Job and CTD Report, 4-25
DESC Parameter
Automation Option Menu, 5-35
DEST JES2 Parameter
DEST Parameter
DETAIL Parameter
DEVADDR Parameter
CART Media, 4-100
Device Definition
CART Media, 4-100
DEVICE Parameter
MEDIA Operator Command, 4-104
DEVQTY Parameter
CART Media, 4-100
MEDIA Operator Command, 4-105
DF/DSS
DF/HSM
DFLT Parameter
DFSAOE00 Module
IMS RESLIB Library, 5-43
DFSAOEU0 Exit
Index
DFSAOUE0 Module
IMS Interface, 5-43
DGRP Parameter
DIAGNOSE Machine Command
VM Support, 3-72
DIAGNOSE Parameter
IOAVERFY Utiility, 9-55
DIGRP Parameter
DIMOD Parameter
DIRECTOR Request
IOAMEM Module, F-1
DIRFULL Request
IOAMEM Module, F-1
DISAPPEARED Status
Sysout problems, 3-49
Disaster Recovery
Manual Recovery, 3-94
Overview, 3-85
Disaster Relocation
Recovery, 3-93
Disk Access
Fixed Head, 3-46
Tuning, 3-46
Disk Controllers
Tuning, 3-47
Disks
Fixed Head, 3-47
Display
Media/Resource Information, 4-107
Display Command
Format, 11-21
Pipe Rules, 11-21
DISPLAY Command
Active Users, 2-5
CMEM, 3-37
Display Format
Status Screen (CTM), G-1
Display Format Member
Customization, 2-20
Format, 2-20
DISPLAY Parameter
IOAVERFY Utility, 9-53
DISPn Parameter
CTMFRJNL Utilitiy, 9-69
Distribution Report
DIVAR Parameter
DJDE Document
XEROX Format, 4-56
DJDE Lines
WD1685 Wish, 4-62
DJDE Parameters
XEROX Printers, 4-46
DJDEPARM Library
Format, 4-46
XEROX DJDE Parameters, 4-46
DMOD Parameter
DMS/OS Support
DO KSL Statement
Exit CTOX003, 10-31
DO MIGRATE=JOBARC
Fictitious Migration Mission, 4-98
DO TSO Statement
Exit CTOX003, 10-31
DOCCCIF Parameter
XEROX Reports, 4-58
DOCDPAGM Member
AFP Printing, 4-44
DOCDX024 Member
DOCDX026 Member
SECUDATA Library, 4-6, 10-20
DOCMNJE Member
SECUDATA Libarry, 3-64
Index
DOCOAOCP Member
DOCRX001 Member
DOCRX014 Member
Document Viewing Service
Document Sciences Corporation, 4-56
DOCVX001 Member
DOCVX002 Member
DOGRP Parameter
Dollar Sign. See $
DOMOD Parameter
DORM Mode
DORMANCY Parameter
Dormant Mode
CONTROL-T, 7-5
Double Byte Character Set
DOVAR Parameter
Draining Mode
WorkLoad Monitor, 11-1, 11-3
Driver Exit
CONTROL-R, 7-29
CTRX001G, 10-12
Design, 10-12
DSCLPOOL Field
DSDELL Statement
DSENDFET Keyword
Dataset Record, D-3
DSEXCP Keyword
Dataset Record, D-3
DSEXPDT Keyword
Dataset Record, D-3
DSEXTYP Keyword
Dataset Record, D-3
DSFLAGS Keyword
Dataset Record, D-4
DSLABEL Keyword
Dataset Record, D-4
DSN Parameter
CTDX005 User Exit, 4-49
CTOTEST Utility, 9-141
Exit CTDX005, 4-50
DSN=parm_library(member)
DSN=sched_library(table)
DSNADD Statement
DSNAME Field
DSNAME Keyword
Dataset Record, D-4
SMF Record, D-14
Stacking Record, D-15
Trace Data, D-14
DSNDEL Statement
DSNPREF Parameter
Migrated File Name, 4-91
DSNUPD Statement
DSNUPDN Statement
DSSTAT Keyword
Dataset Record, D-4
DSUSECT Keyword
Dataset Record, D-4
DSVOLSER Keyword
Dataset Record, D-5
D-type Index
Dual Checkpoint Mode
Index
Dual Checkpointing Mode
Mirror File, 3-53
Dual Mirror Image File
Recovery, 9-33
Support, 2-32
DUAL Parameter
DUALM Parameter
DUALST Parameter
DUE OUT Time
Shifting, 3-5
DUEIN Field
DUE IN Field, 1-2
DUMMY Parameter
Exit CTDX005, 4-51
DUPLICATE-VOL Pool Name
DUSRDATA Keyword
Dataset Record, D-5
DVAR Parameter
DVLACTD# Keyword
Volume Record, D-6
DVLADT Keyword
Volume Record, D-7
DVLATM Keyword
Volume Record, D-7
DVLBOXID Keyword
Volume Record, D-6
DVLCLN Keyword
Volume Record, D-7
DVLCLN# Keyword
Volume Record, D-6
DVLCODE Keyword
Volume Record, D-7
DVLDEN Keyword
Volume Record, D-8
DVLDESC Keyword
Volume Record, D-10
DVLEDMID Keyword
Volume Record, D-9
DVLEXCP# Keyword
Volume Record, D-9
DVLEXPD Keyword
Volume Record, D-9
DVLEXPDS Keyword
Volume Record, D-6
DVLEXPT Keyword
Volume Record, D-9
DVLFCDT Keyword
Volume Record, D-6
DVLFIRST Keyword
Volume Record, D-6
DVLFLG1 Keyword
Volume Record, D-10
DVLFLG2 Keyword
Volume Record, D-10
DVLJBN Keyword
Volume Record, D-7
DVLLBLNM Keyword
Volume Record, D-7
DVLLTYP Keyword
Volume Record, D-7
DVLMDT Keyword
Volume Record, D-8
DVLMEDIA Keyword
Volume Record, D-7
DVLMTM Keyword
Volume Record, D-8
DVLMVDT Keyword
Volume Record, D-7
DVLNEXT Keyword
Volume Record, D-7
DVLOWNR Keyword
Volume Record, D-10
DVLPREV Keyword
Volume Record, D-7
DVLPRFLN Keyword
Volume Record, D-9
DVLRBA Keyword
Trace Data, D-14
DVLRPER Keyword
Volume Record, D-6
Index
DVLRPERC Keyword
Volume Record, D-7
DVLRTER Keyword
Volume Record, D-7
DVLRTERC Keyword
Volume Record, D-7
DVLRTRN Keyword
Volume Record, D-6
DVLRTYPE Keyword
Trace Data, D-14
DVLSCRDT Keyword
Volume Record, D-8
DVLSLNAME Keyword
Volume Record, D-8
DVLSTA2 Keyword
Volume Record, D-10
DVLSTAT Keyword
Volume Record, D-11
DVLTRTCH Keyword
Volume Record, D-11
DVLUNAM Keyword
Volume Record, D-8
DVLUSED# Keyword
Volume Record, D-11
DVLUSER Keyword
Volume Record, D-8
DVLUSER2 Keyword
Volume Record, D-8
DVLVENDT Keyword
Volume Record, D-8
DVLVLT1 Keyword
Volume Record, D-8
DVLVLTDS Keyword
Volume Record, D-8
DVLVLTNM Keyword
Volume Record, D-8
DVLVLTRC Keyword
Volume Record, D-7
DVLVLTT Keyword
Volume Record, D-8
DVLVNDOR Keyword
Volume Record, D-8
DVLVOLSR Keyword
Trace Data, D-14
Volume Record, D-11
DVLVRTRN Keyword
Volume Record, D-8
DVLVSEQ Keyword
Volume Record, D-10
DVLVSLOT Keyword
Volume Record, D-8
DVLVTSQ Keyword
Volume Record, D-7
DVLVXPD1 Keyword
Volume Record, D-8
DVLVXPT1 Keyword
Volume Record, D-9
DVLWPER Keyword
Volume Record, D-7
DVLWPERC Keyword
Volume Record, D-7
DVLWTER Keyword
Volume Record, D-7
DVLWTERC Keyword
Volume Record, D-7
DVS Print Emulator
Parameters, 4-57
DVS Programmers Guide
XEROX Reports, 4-56
Dynamic Dataset Stacking
Dynamic Destination Table, 2-51
Description, 1-13
Dynamic Device Mode
CART Media, 4-101
Dynamic Sorting
DYNDEVRLSE Parameter
CART Media, 4-101
DYNDS Parameter
DYNSTK Installation Parameter
DYNSTYP Parameter
DYNVOL Parameter
Index
E
E/CSA Storage
Real-Time TCT, 7-31
E/CSA Usage
Common Storage Area, 5-11
EBCDIC to ASCII
Automatic Translation, 4-62
ECAPARM Communication Parameter
ECSA Storage
CMEM, 3-41
CONTROL-O, 5-11
ECSGATE
Exit CTMX008, 10-10
Exit IOAX032, 10-7
EDIMACNM Profile Variable
Editing JCL, 2-47
EDIT Parameter
EINDEX Parameter
Banner Index, 10-26
Element Summary
Sample Report, 8-7
Email
ENABLE Parameter
END Function
END Parameter
End User Job Order Interface, 3-29
ENDDATE Parameter
ENDED Status
End-Of-File
Forcing, 11-12
END-TIME Field
ENDTIME Parameter
ENDUPD Statement
Enhanced Daily Checkpointing
(CTD), 3-15
Enlarging
Trace File, 7-22
ENQ Handling Produdt
ENQ Mechanism, 4-34
Enqueue Manager
CONTROL-O, 5-13
Enterprise Controlstation
Authorization, 10-7
ENV Keyword
Trace Record, D-13
ENV Parameter
CTTIOS Macro, 7-37
Environment
IOA Online, 2-1
Program List Member, 2-9
EOF. See End-Of-File
ERASE Parameter
ERASELBL Parameter
Erasing
Information on a Tape, 9-287
ERR-FLAG Field
Error
Error Handling
High Level API (CTT), 7-56
Event List
IOACDDR REXX Procedure, 3-31
Exception Handling
Index
EXCLUDE Statement
CTTSYNC Utiility, 9-284
Syntax, 9-146
EXCLUDE Statements
Format (CTT), 9-148
Record Selection (CTT), 9-146
EXEC Statement
Execution Parameters
Exit CTTX009
External Lables, 10-30
EXIT Parameter
CDAM, 10-19
Exits
CTBX001, 10-28
CTBX003, 10-28
CTBX004, 10-28
CTBX008, 10-28
CTBX009, 10-28
CTDX001, 4-18, 4-23, 4-27, 10-14
CTDX002, 10-14
CTDX003, 10-14, 10-21
CTDX004, 10-14
CTDX005, 10-16
CTDX006, 10-17
CTDX007, 10-17
CTDX008, 10-17
CTDX009, 4-34, 10-17
CTDX010, 4-74, 10-17
CTDX011, 4-80, 10-17
CTDX012, 10-18
CTDX013, 10-18
CTDX014, 10-18, 10-21
CTDX015, 10-18
CTDX016, 10-18
CTDX017, 10-18
CTDX018, 10-19
CTDX019, 10-19
CTDX020, 10-19
CTDX021, 10-19
CTDX022, 10-19
CTMX001, 10-9
CTMX003, 10-9
CTMX004, 10-9
CTMX005, 10-9
CTMX008, 10-10
CTMX010, 10-10
CTMX011, 10-10
CTMX013, 10-10
CTMX014, 10-10
CTMX015, 10-10
CTMX016, 10-10
CTMX017, 10-10
CTMX018, 10-11
CTMX019, 10-11
CTOX001, 10-11, 10-31
CTOX002, 10-11, 10-31
CTOX003, 10-31
CTOX004, 10-31
CTRX001, 7-29, 10-12
CTTX001, 10-29
CTTX002, 10-29
CTTX003, 10-29
CTTX004, 10-29
CTTX005, 10-29
CTTX006, 10-29
CTTX007, 10-29
CTTX008, 10-30
CTTX009, 10-30
CTTX010, 10-30
IGXMSGEX, 7-27
IOAX006, 10-5
IOAX007, 1-17, 10-6
IOAX009, 10-6
IOAX012, 10-7
IOAX028, 10-7
IOAX029, 10-7
IOAX031, 10-7
IOAX032, 10-7
IOAX034, 10-7
IOAX035, 10-8
IOAX036, 10-8
IOAX037, 10-8
IOAX038, 10-30
IOAX039, 10-8
Replacing (CTD), 10-20
Index
Expanding
IOA LOG File, 2-52
EXPDSNUM Keyword
Volume Record, D-6
EXPDT Field
EXPDT Parameter
Exit CTDX005, 4-51
EXPDTDDN
EXPDTYPE Parameter
EXPRTRN Keyword
Volume Record, D-6
EXT-DEL Pool Name
EXT-DUP Pool Name
EXTEND Parameter
Extended Color Support, 2-26
External Lable
Exit CTTX009, 10-30
EXTERNAL Pool Name
External Writer
Extract File
EXTRACT PATH Statement
EXTRNVOL Parameter
F
F CTLMON
Operator Command, 11-1, 11-3, 11-23,
11-29
FDR
Fetch Optimization
Tuning, 3-45
Fictitious Migration Mission
DO MIGRATE=JOBARC, 4-98
Field Names
CTT Repository, D-1
Dataset Records, D-2
SMF Records, D-14
Stacking Records, D-12, D-15
Trace Data, D-14
Trace Records, D-13
Volume Records, D-6
FIELD Parameter
FIELDS Parameter
FIELDS Statement
File
Allocation (CTT), 9-158
Creation (CTT), 9-158
Expanding (CTM), 3-7
Formatting (CTT), 9-158
File Allocation
Tuning, 3-53
File Definition
IOA Access Method, 2-31, 9-24
File Management
FILE Parameter
Utility CTBJAFIG, 9-94
File Set Parameter
FileTek, 4-86
File Transfer
CMEM, 3-70
Exits, 3-70
Recommendations, 3-70
Shared Disk, 3-78
VM Supoort, 3-75
VM Support, 3-78
Index
File Transfer Monitor
CONTROL-D/PC, 1-7
Operator Commands, 4-66
Overview, 1-7
Parameters, 4-66
Recipient Tree, 4-4
File Transfer Product
FILEID Parameter
Files
Security, 10-5
FileTek Storage Machine
Logical Devices, 4-105
Media Definition, 4-102
Migration Parameters, 4-86
FileTek Storage Machine Machine
Media Information, 4-107
Filter Fields
Status Screen, G-5
Finish Indicator Date (CTD), 4-9
FINISH Request
IOAMEM Module, F-2
FIRST Parameter
FIRSTVOL Field
FIRSTVOL Keyword
Volume Record, D-6
Fix Element
Customization, 8-7
FLAG1 Field
FLAG2 Field
FLAGS Field
FMID
Definition, 10-2
FMID Value
NOT SEL Status, 10-3
FOB Parameter
Exit CTDX005, 4-51
FODATE Parameter
Fonts
FORCE Parameter
Form Definitions
FORMAMF Member, 9-97
FORMAMF Utility
Active Missions File (CTD), B-1
FORMAS4 Utility
AS/400 Transfer File, B-1
FORMAT Argument
Pipe Information Display, 11-11, 11-14
Pipe Participant Information, 11-13
Format Member
Automation Option, 5-34
FORMAT Parameter
FORMATF Member
INSTCTD Library, 9-98
FORMATF Utility
Active Transfer File (CTD/PC), B-1
Formatting
Access Method Variable File (CTB),
9-30
Backup File (CTB), 9-30
CTB Files, 9-30
CTT Files, 9-158, 9-163
Group File (CTB), 9-30
Report File (CTB), 9-30
Rule Activity File (CTB), 9-30
Trace File (CTT), 9-155, 9-160
FORMBTR Utility
Bundle Tracking (CTD), B-1
FORMCAT Utility
CDAM Filer Catalog, B-1
Index
FORMCKP Member
FORMCKP Utility
Active Jobs File (CTM), B-1
FORMCOM Utility
Communication File (CTD), B-1
FORMCTD Utility
File Formats (CTD), B-1
FORMCTM Utility
CONTROL-M File Formats, B-1
FORMCTV Utility
Migration File (CTV), B-2
FORMDCKP Utility
Mirror (Dual) Active Jobs File (CTM),
B-1
FORMDEF Parameter
AFP Printing, 4-42
CDAM, 4-43
FORMDEF Statement
FORMDRES Member
Conditions/Resource File, 2-52
FORMDRES Utility
Mirror (Dual) Conditions/Resources
File, B-1
FORMG2M Utility
Gateway Communications File (CTM),
B-1
FORMGRF Utility
Dependencies File (CTM), B-1
FORMIOA Utility
IOA File Format, B-1
FORMLOG Job
IOA INSTALL Library, 9-42
FORMLOG Member
IOA Log File, 2-52
FORMLOG Utility
IOA Log File, B-1
FORMM2G Utility
ECSGATE Communications File, B-2
FORMNRS Job
FORMNRS Utility
IOA Manual Conditions File, B-1
FORMPGC Utility
Print Mission Pages (CTD), B-1
FORMRES Job
FORMRES Utility
IOA Conditions/Resources File, B-1
FORMSTT Utility
Job Execution Statistics (CTM), B-1
FORMSUB1 Utility
CMEM File, B-1
FORMSUB2 Utility
CMEM File, B-1
FORMUF1 Utility
User Report Files (CTD), B-1
FORMUF2 Utility
User Report File Reformat (CTD), B-1
FORMUF3 Utility
Migrated User Reports File (CTV), B-2
FORMUF4 Utility
Migrated User Reports File (CTV), B-2
FORMUFx Sample Job
FREE Parameter
Free Space Chain
Rebuilding (CTT), 7-25
Free Tape Pool
Utility CTDCLHIS, 4-114
FREEZE Mode
Operating Mode (CTO), 5-33
French
Language Support, 8-3
FROM Parameter
FROM Parameter
FROMDATE Parameter
Utility CTMJSA, 9-70
FROMDSN Parameter
FROMGEN Parameter
FROMKEY Parameter
FROMTYPE Parameter
Index
FTP Product
FUNC Parameter
IOADIG Utility, 9-35
Function Codes
IOAMEM Module, F-7
FUNCTION Keyword
Trace Data, D-13
FUNCTION Parameter
Functional Components
IOA Rel. 5.1.4, 8-2
Functional Monitor
Execution Environment, 10-30
Exit IOAX034, 10-7
Functional Subsystem
Monitor Procedure, 4-40
Funtional Monitor
G
GDDM
AFP Documents, 4-44
GEINDEX Parameter
Banner Index, 10-26
GENCLAS Parameter
GENER Parameter
Generations
CTB Variables, 9-81
Generic Decollating Mission
Overview, 4-19
Scheduling, 4-21
Generic Processing
Activating, 4-1
Deactivating, 4-5
Generic User Name
Definition, 4-22
GENLIST Member
German
GETLINE Request
IOAMEM Module, F-2
GETMEM Request
IOAMEM Module, F-1
GINDEX Parameter
Banner Index, 10-25
GLBCOMP Parameter
GLBPREF Parameter
Global AutoEdit Variable Library
Automatic Compression, 5-27
Global Control
Global Member
Definition (CTO), 5-25
GLOBAL Mode
Command Scope, 11-2
WorkLoad Monitor Command, 11-1
Global Processor
JES3 Environment, 3-49
Global Ruler
Default, 10-16
GLOBAL SMP/E Zone, 8-1
Global Variabales
Loading, 5-24
Global Variables
Description (CTO), 5-23
Updating, 5-24
Graphics
GROUP ENDTIME Parameter
Group Entity
Recovery Procedure, 3-15
GROUP Field
Group File (CTB)
Copying, 9-83
Formatting, 9-30
Rebuilding, 9-30
Index
Group of Users
CONTROL-D, 4-22
GROUP Parameter
IGNORE/SELECT Statements (CTM),
9-63
Printing Mission Definition, 4-39
Group Scheduling Table
GROUPPWD Parameter
GRPBIX Statement
CTTMUP Utility, 9-183, 9-186
GRPSCR Statement
H
Held Output Class (CTM), 3-5
HELD Status
Help Members
Hexadecimal
AFP Parameters, 4-45
Hierarchical Indexing
CONTROL-V, 4-58
High Level API (CTT)
Base Level API, 7-34
Buffer Address, 7-54
Description, 7-53
Error Handling, 7-56
Functions, 7-53
Macro CTTACCDB, 7-54
Macro CTTCHKDB, 7-55
Sample JCL, 7-57
Highlight
Display Format, 2-25
HILITE Parameter
HILITEA Parameter
History Jobs File
CONTROL-R, 3-11
CTMFRM program, 3-25
History Report List
Cleaning, 9-103
CTDDELRP Utility, 4-114, 9-106
Description, 4-113
History User File
History User Report List
Utility CTDCLHIS, 4-114
HLDCLAS Installation Parameter
HLDCLAS Parameter
HOLD Parameter
HOME-SYS Field
Pipe Information, 11-24, 11-29, 11-32
I
IBM
3480 Tape Cartridge Device, 4-104
IBM 3995
Optical Library Dataserver, 4-89
ICE
Description, 1-3
IOA Maintenance, 8-11
Profile Customization, 2-33
ICOLOR
ID Check
USERMOD, 10-3
ID Field
ID Parameter
IDBCS
Index
IDLIKE Parameter
IDM=
AFP Command, 4-45
IDMS
Color Support, 2-47
IDMS Support
IDMS/DC
Color Support, 2-26
IDXCCIF Parameter
XEROX Reports, 4-58
IEASYSXX Member, 2-5, 4-2
IEBGENER Utility
Media Database Backup, 7-9
IEFSSNxx Member
Subsystem List, 5-12
IFASMFDP Utility
IFLTSTA
Profile Variable (CTM), 2-42
IGNORE Statement
CTD Daily Processing, 4-12
Program CTMFRM, 3-18
IGNORE/SELECT Statements
CTM Daily Processing, 3-18
IGXMSGEX Exit
Cartridge Message Display, 7-27
ILBLKNO Parameter
IMBUFARD Field
IOAMEM Module, F-1
IMHNDLR Field
IOAMEM Module, F-1
IMM=
AFP Command, 4-45
Immediate Print Request
Exit CTDX014 and CTDX015, 10-18
Immediate Printing
Implementation
Checkpointing, 3-20
CONNECT DIRECT Support, 3-30
IMRECNUM Field
IOAMEM Module, F-2
IMS
Color Support, 2-47
CONTROL-O Interface, 5-43
IMS Environment
CONTROL-O, 5-43
IMS Support
IMS/DC
Color Support, 2-26
IN Parameter
Inaccessible Files
INCLUDE Statement
CTTSBD Utility, 9-235, 9-255
CTTSYNC Utiility, 9-284
Syntax, 9-146
CTORSTM Utility, 9-140
CTTACP Utility, 9-153
CTTRCV Utility, 9-194
CTTSTK Utility, 9-276, 9-277
CTVDELI Utility, 9-125, 9-126
Examples, 9-151
Field Names, D-1
Format (CTT), 9-147
Record Selection (CTT), 9-146
Record Selection Logic, 9-146
Index
Index
CTD Reports, 4-38
Index Component
Rebuilding, 4-119
Index File
Deleting from DASD, 9-125
Integrity (CTT), 9-166
Naming Convention, 4-92
Parameters (CTT), 9-159
Printing (CTT), 9-167
Rebuild Stacking Index, 9-164
Rebuilding (CTT), 7-25
Index Format
INDEX Parameter
Banner Index, 10-25
Index Record
CTTIOS Macro, 7-38
Types, 7-13
Index, CONTROL-V
CCIF Main Index, 4-58
Index/Value Selection Panel
Indexing
Indexing Reports
INIT Mode
Initialization
CONTROL-D, 4-1
CONTROL-M, 3-1
CONTROL-O, 5-1
CONTROL-T, 7-2
CONTROL-V, 4-1
Tape Initialization, 9-285
Trace File, 9-155
INITT Function
Inline Resource Option
AFP Printing, 4-43
INOUT Attribute
Global Variable Member (CTO), 5-25
INP Parameter
CTTDLD Utility, 9-169, 9-170
INPUT Attribute
Inquire/Update Screen (CTT)
Installation Job
USERMODs, 10-1
Installation Parameter
CONTROL-M, 3-89
Reloading, 11-4
Installation Parameters
Displaying (CTM), 3-8
Installation Working Date, 4-9
INSTCCIF Job
IOA INSTCTD Library, 4-56
INSTCTV Library
Migration Target Media, 4-88
IN-TABLE Parameter
Integrity
Access Method Index, 9-36
Data Files (CTT), 9-165
Index Files (CTT), 9-166
Media Database, 7-9, 7-19, 9-181, 9-272
Variable Files (CTB), 9-88
Integrity Error
Correction, 7-20
Integrity Errors
CTTIDB Utility, 7-19
INTENS Parameter
Inter System Communications (CTM), 1-16
Interface
CONTROL-R, 10-12
CONTROL-T to MVS, 7-2
CTM and CTD, 4-26
CTR to CTT, 7-29
Interfaces
CA-7 (UCC7), 4-28
Index
Internal Data Areas
CONTROL-O, 5-31
INTERVAL Argument
INTERVAL Command
CMEM, 3-38
CONTROL-D Monitor, 4-2
CONTROL-O Monitor, 5-28
INTERVAL Parameter
INTERVL Installation Parameter
Inventory Report
Vault Management, 9-301
IOA
Account Information, 10-8
Ad hoc Maintenance, 8-5
Application Program Names, A-1
Color Support, 2-25, 2-26
Customizing Screens, 2-17
Dataset Formatting Utilities, B-1
Exits, 10-5
Introduction, 1-1
Limited Access, 2-8
Online Monitor, 10-6
Online Monitor Activation, 2-4
Periodic Maintenance, 8-4
Profiles, 2-33
Dual Mirror Image Files, 2-32
Exit IOAX036, 10-8
File Allocation, 2-28
File Definition, 2-31, 9-24
File Deletion, 4-120
File Recovery, 4-119
File Structure, 2-28
Files (CTB), 2-29
Files (CTD), 2-30
Files (CTO), 2-30
Index Integrity, 9-36, 9-114
Index of CTD Files, 9-114
Integrity, 9-35
Loading Files, 9-37
Overview, 1-8, 2-28
Printing Files, 9-39
Recovery, 2-32, 9-33
Sorting Files, 4-118, 9-31
Unloading Files, 9-40
Utilities, 2-31
Variable File (CTB), 9-30
IOA Access Method Utilities
Summary, 9-4
IOA Archive Server
ROSs/OSS Mecia, 4-100
IOA Conditions/Resources. See
Conditions/Resources
IOA Core
Description, 1-8
IOA Gateway
Page On Demand, 4-60, 4-63, 5-44
IOA INSTALL Library
Utilities, B-1
IOA INSTCTD Library
Utilities, B-1
IOA INSTCTM Library
Utilities, B-1
IOA INSTCTO Library
Utilities, B-2
IOA INSTCTT Library
Utilities, B-2
IOA INSTCTV Library
Utilities, B-2
IOA INSTECS Library
Utilities, B-2
IOA LOAD Libraries
Blocksize, 3-47
IOA LOAD Library
Tuning, 3-45
IOA Log
Copying, 9-21
Exit IOAX031, 10-7
IOA Log File
Deleting Records, 9-42
Summary, 1-8
Tuning, 3-47
Index
IOA LOG File
Expanding, 2-52
IOA Manual Conditions. See Manual
Conditions
IOA PARM Library
Online Facility Commands, C-1
IOA Primary Option Menu. See Primary
Option Menu
IOA Screen Definition
Constant Blocks, 2-19
IOA Server
Tuning, 3-53
IOA Translation
Exit IOAX037, 10-8
IOA Utilities
Summary, 9-1
IOA/Pathfinder
Job Description, 1-2
IOA5DZN SMP/E Zone, 8-1
IOABLCAL Utility
Calendar Creation, 9-7
Example, 9-9
Logic, 9-8
Summary, 9-1
IOAC Transaction
CTO/CICS Interface, 5-42
IOACDDR REXX Procedure
Dataset Event Definition, 3-31
CONTROL-M Maintenance, 3-12
Description, 9-13
Summary, 9-1
IOACMEML Member
CMEM Rule List, 5-41
Rule Table List (CMEM), 3-35, 5-4
IOACND Utility
File Transfer, 3-70
Manage Conditions/Resources, 9-16
Summary, 9-1
IOACOPRS Utility
Copy/Resize Cond/Res File, 9-20
Restore Conditions/Resources File, 3-86
Summary, 9-1
IOACPLOG Job
IOA Log File, 2-52
IOACPLOG Utility
Copy Log File, 9-21
Summary, 9-1
IOAD01I Message
IOAD02I Message
IOAD03I Message
IOAD04I Message
Description, 9-23
Summary, 9-4, 9-5
IOADBSR Utility
Sort Access Method Files, 4-118, 9-31
Summary, 9-4
IOADCPY Utility
Access Method File Recovery, 9-33
CONTROL-D File Recovery, 4-119
Summary, 9-4, 9-5
IOADDC Module
IOADDR Module, 3-31
IOADDR Module
Dataset Event, 3-31
IOADDS Started Task
IOADDR Module, 3-31
IOADEST Member
Destination Table, 2-51
IOADESTJ Member, 2-51
IOADFLTC Member
IOA MAC Library, 4-41
Optional Wishes, 3-54
Updating, 2-48
IOADIG Utility
Access Method File Integrity, 9-35
Summary, 9-4, 9-5
IOADII Utility
Access Method Index Integrity, 9-36
Summary, 9-4, 9-5
Index
IOADLD Utility
Load Access Method Files, 9-37
Summary, 9-4
IOADPT Utility
Print Access Method Files, 9-39
Space Management, 9-29
Summary, 9-4, 9-5
IOADUL Utility
Summary, 9-4
Unload Access Method Files, 9-40
IOAFRLOG Utility
Description, 9-42
Summary, 9-1
IOAFRNRS Utility
Description, 9-43
Summary, 9-1
IOAFRRES Utility
Description, 9-44
Restore Conditions/Resources File, 3-86
Summary, 9-1
IOAFTR Utility
Fix Element, 8-7
IOAGATE
Communication Support, 1-6
IOAINS Utility
Fix Element, 8-7
IOAINSJ Member
IOAIPLCM Member
CMEM Rule List, 5-1, 5-14
IOAISPF CLIST
CONTROL-M Maintenance, 3-12
Manual Conditions, 4-4
Summary, 9-1
IOAMEM Module
Attributes, F-1
Function Codes, F-7
Reason Codes, F-6
Return Codes, F-6
IOAMEMA Parameter
IOAMEM Module, F-2
IOAMMEM Macro
IOAMEM Module, F-3
IOANOTE Utility
Sending a Message, 9-49
Summary, 9-1
IOAOMON
IOAONL CLIST
Entry of Online Facility, 2-2
IOAOPR Utility
Description, 9-50
Exit IOAX012, 10-7
SHOUT Message, 3-83
Summary, 9-1
VM CP Command, 3-80
IOARROT Utility
Exit IOAX006T, 10-6
IOASE16 Security Module
IOA Gateway Access, 4-60
IOASMON Archive Server
CTVX002 Exit, 10-20
IOASMP Procedure
PROCPREFA Installation Parameter,
8-5
IOASPARM Member
INSTCTV Library, 4-88
IOASPRM Table
CTVUNMIG Utility, 9-132
IOATEST Utility
Simulation, 9-51
Summary, 9-1
IOATLOG Program
IOA Log Screen, A-1
IOATMNU Program
IOA Primary Option Menu, A-1
IOATSO CLIST
IOAVAUTO Machine
SHOUT Message, 3-83
VM Commands, 3-81
IOAVCND Utility
Summary, 9-1
Index
VM Support, 3-81
IOAVERFY Utility
Description, 9-53
Summary, 9-1
IOAVEXEC Procedure
VM Support, 3-81
IOAVMON
Operator Command, 2-7
VTAM Monitor, 2-7
IOAX006 Exit
Online Facility Exit, 10-5
IOAX007 Exit, 10-6
Customization, 1-19
1-17
IOAX009 Exit, 10-5, 10-6
IOAX012 Exit, 10-7
IOAX016 User Exit
IOA Gateway Access, 4-60
IOAX028 Exit, 10-7
IOAX029 Exit, 10-7
IOAX031 Exit
IOA Log, 10-7
IOAX032 Exit:, 10-7
IOAX035 Exits
Account Information, 10-8
IOAX036 Exit
IOAX037 Exit
IOA Translation, 10-8
IOAX038 Exit
Environment for IOA Functions, 10-30
IOAX039 Exit
Page Separation, 10-8
IOAXAGR Macro
IOAMEM Module, F-1
IOAXTSO CLIST
IOERPRM Keyword
Volume Record, D-6
IOERPRMC Keyword
Volume Record, D-7
IOERR Field
IOERTMP Keyword
Volume Record, D-7
IOERTMPC Keyword
Volume Record, D-7
IOEWPRM Keyword
Volume Record, D-7
IOEWPRMC Keyword
Volume Record, D-7
IOEWTMP Keyword
Volume Record, D-7
IOEWTMPC Keyword
Volume Record, D-7
IO-FLAG Field
IP Address
Recipient Tree, 4-65
IPL
Automation (CTO), 5-12
CONTROL-O IPL Process, 5-14
Starting CONTROL-O, 5-1
IPLRULES Member
CONTROL-O Rule List, 5-13
IRMA
Color Support, 2-26
ISCALLOC Member
Inter-System Communications, 1-17
ISCPARM Member (CTM), 1-17
ISPF
Color Support, 2-26
Editing JCL, 2-47
ISPF Element
Copy to System Library, 8-11
ISPF Support
ISPFBOTL
IXHPREF Parameter
IXNAME Parameter
Index
J
Japanese
JCL
Editing via ISPF, 2-47
JCL Editing
JCL Procedure
Copy to System Library, 8-11
JCL Setup
JCLEXPDT Keyword
Dataset Record, D-5
JDEPARMS Member
Sample DJDE Parameters, 4-47
JES
Communication with Monitor, 3-51
IPL Automation (CTO), 5-12
Priority, 3-51
JES Command
JES2
Shared Spool Complex (MAS), 3-50
Utilization Rates, 3-50
JES262S Message
JES2-DEST Printer Setting, 4-38
JES2PARM
Tuning, 3-50
Tuning Considerations, 3-50
JES3
Command Prefix, 9-50
Global Processor, 3-49
JES3 Command
JES3-CLASS Printer Setting, 4-38
JESCHAR Command Prefix
Job
Dependency on CTD Report, 4-25
Job Archiving
Description, 4-98
Job Dependency (CTM), 3-4
Job End
Job Lists
User Specific, 3-29
JOB NAME Field
JOB Option
Job Ordering
CONTROL-M, 3-10
Exit CTMX001, 10-9
Job Priority
Refreshing, 3-4
Job Rerun
Job Rerun Screen
Profile Variable (CTD), 2-38
Job Scheduling
Category Field, 4-26
Exit CTMX004, 10-9
Job Scheduling Definitions
Overview, 1-5
Job Statistics
CTMJSA Utiility, 9-70
Exit CTMX005, 10-9
Job Statistics Screen
Job Status Screen
Profile Variable (CTM), 2-38, 2-45
Job Step
Job Step Invocation
CONTROL-B, 6-8
Job Submission
CTMAJO routines (CTD), 4-34
Job Tracking
Exit CTMX016, 10-10
JOBARC Member
REPORTS Library, 4-98
JOBBBDM Job
Rebuild Access Method Variable File,
9-30
JOBBDBM Job
Index
JOBBDBV Job
Rebuild Access Method Variable File,
9-30
JOBBGRP Job
Rebuild Group File, 9-30
JOBBJAF Job
Rebuild Rule Activity File, 9-30
JOBBREP Job
Rebuild Report File, 9-30
JOBFABF Job
Format Active Balancing File, 9-30
JOBFBKP Job
Format Backup File, 9-30
JOBFGRP Job
Format Group File, 9-30
JOBFJAF Job
Format Rule Activity File, 9-30
JOBFMOD Job
IOA Access Method Variable File, 9-30
JOBFREP Job
Format Report File, 9-30
JOBFVAR Job
Format IOA Access Method Variable
File, 9-30
JOBID Field
JOBID Keyword
Trace Record, D-13
JOBID Parameter
JOBNAME Field
JOBNAME Keyword
SMF Record, D-14
JOBNAME Parameter
Job-Related Fields
Jobs Dependency Network File
Expanding (CTM), 3-7
Journal File
Commands, 3-87
Journaling
K
KANJI Parameter
KEEPDSN Parameter
KEY Parameter
CTTIOS Macro, 7-38
Keyed Access
API Interface, 7-40
KEYFROM Parameter
KEYLEN Parameter
CTTCRDF Utility, 9-158, 9-163
CTTIOS Macro, 7-38
KEYTO Parameter
Key-Type
Media Database Index, 7-13
KEYTYPE Parameter
CTTIOS Macro, 7-38
Keywords
Dataset Records, D-2
SMF Records, D-14
Stacking Records, D-12, D-15
Trace Data, D-14
Trace Records, D-13
Volume Records, D-6
KEYxxx Members
PARM library, 9-164
Index
KOA
VM Support, 3-84
Kodak OPTISTAR
KODAK OPTISTAR. See ROSs/OSS
KODAK/DataWare OSS
Updating, 4-101
KSL Log Report
REP5ALL Procedure, 3-94
KSL Scripts
SAMPLE Library, 3-94
KSL Utility
Mission Scheduling (CTD), 4-16
L
LABEL Parameter
Exit CTDX005, 4-51
LABTYPE Parameter
LACCDT Field
LACCDT Keyword
Volume Record, D-7
LACCJBN Keyword
Volume Record, D-7
LACCTM Keyword
Volume Record, D-7
Language Elements
IOA Rel. 5.1.4, 8-2
Language Support
IOA Products, 8-2
Laser Printers
AFP Printing, 4-42
LAST ACCESS Retention
LAST Parameter
LASTACCS Keyword
Dataset Record, D-5
LAST-ACT Field
LBLNUM Keyword
Volume Record, D-7
LBLNUM Parameter
LBLROUTC Parameter
LBLTYP Keyword
Volume Record, D-7
LCDS Document
XEROX Format, 4-56
LCDS to CCIF Conversion
CCIFPARM Library, 4-61
LCLNDT Field
LCLNDT Keyword
Volume Record, D-7
LDSPOS Keyword
Block ID of Last Dataset, D-7
LDSPOSLB Keyword
Label Number for LDSPOS, D-7
LDT54DE Message
Rejected CMEM Rule, 5-3
LENGTH Parameter
Letter Size
Banner Pages, 10-22
LIB Argument
Hold Rule, 11-8
Release Rule, 11-8
Rule Deleting, 11-7
Rule Loading, 11-6
LIB Field
Pipe Rule Display, 11-21
LIBRARIAN Product
IOAMEM Module, F-6
Library Compression
Job Submission, 3-28
LIFEOBS Keyword
LIFESPAN Keyword
LINDCT Parameter
Banner Index, 10-25
LINECMD Parameter
Index
LINESIZE Parameter
LINK Command
Linklist Library
Tuning, 3-45
Linklist Lookaside. See LLA
LIST Parameter
LIST.TXT File
LLA Function
Tuning, 3-45
LLA/VLF
Load Module Fetching, 3-45
LOAD Command
Pipe Rule Table, 11-8
LOADGLOBAL Command
Global Variable Members (CTO), 5-27
Loading
CMEM Rules, 3-35
LOADTREE Command
Recipient Tree Loading (CTD), 4-3
LOAN01.GIF File
LOAN02.GIF File
LOCAL Mode
Command Scope, 11-2
LOCATION Field
LOCATION Keyword
Volume Record, D-7
LOCSEQ Keyword
Volume Record, D-7
LODOSSDB Job
OSS Database Update, 4-101
LOG Command
Automation Log (CTO), 5-20
CMEM, 3-38
Log File
Copying the IOA Log, 9-21
LOG_CLASS Parameter
XEROX Reports, 4-58
LOGFILE Parameter
XEROX Reports, 4-57
Logical Field Names
CTT Repository, D-1
Logical Recovery
Description, 7-27
vs. Physical Recovery, 7-25
Logical Terminal Emulator
VM/VTAM, 3-75
LOGONLY Mode
LOGSIZE Parameter
IOA Log File, 2-52
LONG Parameter
@LINE Display Format Line, 2-22
LREC Parameter
LRECL Field
IOAMEM Module, F-1
LRECL Keyword
Dataset Record, D-5
LRECL Parameter
Exit CTDX005, 4-51
LTH Parameter
L-type Index
M
M Parameter
Index
MAINDAY Scheduling Table
CTM, 3-12
MAINDAY Table
Customization, 3-20
Maintenance
Ad-hoc, 8-5
CONTROL-D, 4-7
Module CTOWTO, 5-2
Periodic, 8-4
User Reports List File, 4-117
Maintenance Jobs
CONTROL-M, 3-12
MAKEDOC Parameter
XEROX Reports, 4-58
Manual Conditions
Default Date, 2-42
Reloading (CTD), 4-4
Manual Conditions File
Overview, 1-10
Manual Conditions List
Building, 9-46
Utility IOALDNRS, 4-30
Manual Procedures
Manual Update
Stacking Statistics, 9-180
Mapping
Media Information, 9-286
MARGINS Parameter
MAS Environment
CONTROL-M Performance, 3-50
Mask Characters
INCLUDE/EXCLUDE Statements,
9-147
Masking
TSO User ID, 3-29
MAXCONN Parameter
MAXUSER MVS Parameter, 2-5
MDBUPDAT Parameter
MDF
CPU Partitioning, 3-66
MDF (Multi-Domain Facility)
AMDAHL, 3-74
Media Control
Media Database
Access via Base Level API, 7-40
Adding Volumes, 9-169
API Access, 7-35
Backup and Recovery, 7-25
Checking Integrity (CTT), 7-9
Converting Volumes, 9-169
Creation, 9-158
Deleting Volumes, 9-169
Enlarging, 7-21, 7-24
Formatting, 9-159, 9-163
Index File, 7-12
Index Integrity, 9-166
Integrity, 7-19, 9-165, 9-181
Keyed Access (API), 7-43
Loading, 9-161
Manual Update, 7-21
Merge Utility, 9-177
Non-Keyed Access, 7-45
Printing, 9-167
Record Types, 7-10
Recovery, 7-20, 9-191
Selective Recovery, 7-27
Split/Merge Process, 9-271
Statistics, 9-175
Structure, 7-9
Unloading, 9-162
Update (Exit CTTX006), 10-29
Update Utility, 9-180
Updates, 7-17
Media Definition
CART Media, 4-100
FileTek Storage Machine, 4-102
Index
MEDIA Field
Media Information
Display, 4-107
Tape Mapping, 9-286
MEDIA Keyword
Volume Record, D-7
MEDIA Parameter
MEMNAME Member
CTD Scheduling, 4-23
Memory Requirement
IOA Online, 2-3
Menu Definition
MENU Member, 2-15
Menus
Automation Options (CTO), 5-35
Merging
MDB Records, 9-177
Message
Color of Display, 2-41
Modification, 2-49
Message Display
Cartridge Tape Subsystems, 7-27
MESSAGE Parameter
CTMMMSG Macro, 2-49
Message Statistics Facility (CTO), 5-16
Copy Statistics File, 9-133
Report Utility, 9-140
Message to Log File
IOANOTE Utility, 9-49
Messages
CME123I, 3-38
CME150I, 3-44, 5-31
CME15DI, 3-44
CME251I, 3-39
CTD100I, 4-1
CTD107I, 4-4, 4-6
CTD113W, 4-7
CTD120I, 4-4
CTD123I, 4-3
CTD126I, 10-20
CTD130I, 4-37
CTD136I, 4-4
CTD139I, 4-1
CTD140I, 4-5
CTD160I, 4-3
CTD271I, 4-5
CTD426W, 4-7
CTD427W, 4-7
CTD533S, 9-96
CTD775I, 4-1
CTD779I, 4-4, 4-7
CTDF63W, 9-96
CTM100I, 3-1
CTM107I, 3-1
CTM120I, 3-1
CTM123I, 3-3
CTM227I, 4-2
CTM231I, 4-5
CTM645I, 2-5
CTM646I, 2-5
CTM777I, 2-4
CTM778I, 2-4
CTM786I, 4-3
CTM7A0I, 2-7
CTM7A1I, 2-7
CTM7ACI, 2-7
CTM7B0I, 2-7
CTM7B1I, 2-7
CTO123I, 5-29
CTO147I, 5-15
CTO184I, 9-133
CTO189I, 9-133
CTO240W, 5-17
CTO241E, 5-17
CTO251I, 5-29
CTO297I, 5-18
CTT200S, 7-39, 7-56
IOA10BI, 4-6
IOA128I, 4-108
MIGLIM Member
SKL Library, 4-85
MIGMIS Parameter
MIGORDER KSL Utility
Index
MIGRAT Step
Abend, 4-97
Migrated Report
Migrated User Report List
Cleaning, 9-123
Description, 4-113
Migration
CDAM File Names, 4-91
DATETIME Field, 4-91
Multi-stage, 4-83
Stages. See
Migration Job
CONTROL-M Submission, 4-94
OSSDBEXT Step, 4-94
Migration Mission
Abend, 4-97
CART Target, 4-88
CTDBKDAY Procedure, 4-16
DASD Target, 4-89
Example, 4-95
Fat-DASD Target, 4-89
FileTek Storage Machine, 4-89
Management, 4-82
Multi-Stage, 4-96
OSS Target, 4-88
Overview, 4-82
Primary, 4-84
Report Correspondence, 4-83
Rerun, 4-84
Scheduling, 4-13, 4-84
Secondary, 4-84
SECONDARY NAME Parameter, 4-93
Skeleton Job, 4-85, 4-86
Target Media, 4-88
Triggering, 4-86
Work Flow, 4-93
Mirror File
Dual Checkpointing Mode, 3-53
Mirror Image File
Recovery, 9-33
Support, 2-32
Mission
Scheduling
Workflow, 4-17
Workflow, 4-18
Mission Definitions
Overview, 1-5
Mission List Members (CTD), 4-14
Mission List Screen (CTB)
Mission Name
DO MIGRATE Statement, 4-83
MISSION Parameter
Mission Scheduling
CONTROL-D, 4-13
Manual, 4-16
MLPF
MLPF (Multiple Logical Processor Facility)
Hitachi Data Systems, 3-74
MMT Table
Data Dump, 11-20
MNH Table
Data Dump, 11-20
MODE Argument
MODE Field
MODE Installation Parameter
MODE Keyword
MODE Parameter
CMEM Rule, 3-38
CTDCLHIS Utility, 9-103
CTDDIG Utility, 9-115
Index
CTTVTM Utility, 9-302, 9-303
CTVCLMIG Utility, 9-123
Rule Operation (CTO), 5-20
MODIFY Command
IOADDS Started Task, 3-31
Monitor. See WorkLoad Monitor
CMEM, 3-2, 5-41
CONTROL-D, 4-1, 10-20
CONTROL-M, 3-1
CONTROL-O, 5-41
IOA Online, 1-6, 2-3, 2-4
IOA Products, 1-5
Sleeping Interval (CTD), 4-2
Sleeping Interval (CTM), 3-3
VTAM, 2-7
Monitor Procedure
Functional Subsystem, 4-40
Monitor, Functional Subsystem
Mount Messages
Modification, 7-2
MOVEDATE Keyword
Volume Record, D-7
Moving
Database Records, 9-271
MRGIN Parameter
Utility CTTMER, 9-177
MSGCLASS Parameter
MSGCLASS, Dedicated
Job Archiving, 4-98
MSGFMT Parameter
MSM Migration. See Migration
MTL Table
Data Dump, 11-20
Multi Chunk Method
JES2, 4-36
JES3, 4-36
Multi-Access Spool Environment. See MAS
Environment
Multi-CPU Configuration
Tuning, 3-46
Multi-CPU Environment
Multi-CPU Sites
1-16
Multi-CPU Support
CONTROL-M, 3-54
MULTI-RD Field
Multi-stage Migration. See Migration
Multi-Volume Chain
Manual Update, 7-21
RTNTYPE Parameter, 9-221
Volume/Dataset Records, 7-16
Multi-Volume Dataset, 7-15
MVS
ASVT, 2-5, 4-2
Catalog Conversion, 9-170
Interface (CTT), 7-2, 7-4
IPL Automation (CTO), 5-12
MVS - VM Communication
VM Support, 3-71
MVS and VM
Running on Separate Computers, 3-73
Running Under PR/SM, MDF, MLPF,
3-74
MVS Job
CMEM Monitoring, 3-78
MVS Linklist
Tuning, 3-45
MVS Running Under VM
VM Support, 3-72
MVS SPOOL
MVS SYSLOG Messages
Index
N
NAME Parameter
Naming Convention
Index File, 4-92
Naming Conventions
CDAM Datasets, 4-91
NET Command
CONTROL-M, 3-4
NETVIEW Product
Network Management
Network Software
New Day procedure
Daylight Savings Time, 3-33, 3-34
New Day Procedure
CONTROL-B, 6-1
Maintenance Operations, 7-7
Parameters, 4-12
Scheduling Generic Missions, 4-21
Starting, 4-7
New Day Processing
Checkpointing, 3-20
Conditions/Resources (CTM/D), 4-29
CONTROL-D, 4-7
CONTROL-M, 3-10, 4-23
CONTROL-T, 7-7
CTDCA2P, 4-111
Description, 1-7
Implementation (CTM), 3-16
Overview, 4-6
Program Arguments, 3-23
Programs (CTD), 4-10
Programs (CTM), 3-23
Rule Refresh Option (CTT), 7-8
Sample Components (CTM), 3-12
NEWAJF File Statement
NEWCONLIST Command
CMEM, 3-36
NEWDEST Command
Destination Table, 2-51
NEWEXDTn Field
NEWGLOB Job
NEWNAME Parameter
NEWRES Parameter
IOACOPRS Utility, 9-21
NEWSECDEF Command
CMEM, 3-39
CONTROL-M, 3-4
CONTROL-O Security Cache, 5-29
NEWSNC Parameter
NEWXDTRn Field
NEXTVOL Keyword
Volume Record, D-7
Night Plan Report
Night Schedule Report
NJE Connection
NJE Environment
NLASKOP Parameter
NOFORCE Parameter
Non-Keyed Access
Non-MVS System
NOPRINT Parameter
NOREPORT Parameter
Normal Mode
CONTROL-T, 7-5
NOSEP JES Parameter
Index
NOSYS Parameter
CTVCLMIG Utility, 9-123
NOLOCATE Utility, 9-123
NOT SEL Status
FMID Value, 10-3
NOTRST Parameter
NOTWD Parameter
NOTWDSN NAME Parameter
NOTWGRP NAME Parameter
NOTWJOB NAME Parameter
NRECS Parameter
CTTCRDF Utility, 9-158, 9-159, 9-160,
9-163
NUMBTAPE Parameter
CTTTPI Utility, 9-293, 9-294
NUMERR Parameter
NUMGEN Parameter
O
OBSERVE Keyword
OCTUSER Parameter
Exit IOAX009, 10-6
ODATE
Migrated Report List, 4-112, 4-113
OFFSET Parameter
OLDAJF File Statement
OLDEXDTn Field
OLDQNAME Parameter
OLDRES Parameter
OLDSNC Parameter
OLDXDTRn Field
OMON1 Environment
Exit IOAX006, 10-5
One-Chunk Method
One-Outgroup Method
Online Facility
Command Customization, C-1
Command Modification, 2-13
Cross Memory Interfaces, 2-1
Cross-Reference of Options, E-1
Customization, 2-8
Entry, 2-2
Environments, 2-1
Exit IOAX006, 10-5
PFKey Definition, 2-13
Tuning, 3-53
Online Monitor
Deactivation, 2-6
Online Monitor
Balance Workload, 2-4
Description, 1-6, 2-3
IOA, 2-3, 2-4
Number of Users, 2-4
Online Viewing
ONSPTAB
CMEM Rules, 5-3
OPEN Function
OpenEdition
Deactivation, 5-21
UNIX for MVS, 5-21
Opening Files
Authorization, 10-5
Operating Status
Parameters (CTT), 7-5
Index
Operation Mode
Checking (CTT), 7-8
CMEM, 3-38
CONTROL-O Rules, 5-20
Dormant (CTT), 7-5
Normal (CTT), 7-5
Suspended (CTT), 7-5
Operator Command
Data Space Information, 11-19
Display Pipe Rule, 11-10
F CONTROLM,SAPI=YES|NO, 3-8
Hold Rule, 11-8
OpenEdition Interface, 5-22
Pipe Canceling, 11-12
Pipe Information Summary, 11-10,
11-14
Pipe Unlocking, 11-13, 11-15
Release Rule, 11-8
Reloading Installation Parameters, 11-4
Rule Deleting, 11-7
Rule Loading, 11-6
Scope, 11-2
Trace Facility, 3-9
Trace Facility Activation, 11-17
Trace Facility Setting, 11-18
Operator Commands
Exit IOAX012, 10-7
F CONTROLO, C=library(table), 5-6
F CONTROLO,INTERVAL=, 5-28
F CONTROLO,O/F, 5-5
F CTMCMEM,INTERVAL=, 3-38
F IOASMON,DISPLAY MEDIA=,
4-107
F IOASMON,SET DEBUG=, 4-108
F IOASMON,START MEDIA, 4-103
F IOASMON,STOP MEDIA, 4-103
F CONTROLD,INTERVAL, 4-2
F CONTROLD,LOADTREE, 4-3
F CONTROLD,STARTGEN, 4-1, 4-21
F CONTROLD,STARTPRT, 4-37
F CONTROLD,STOPGEN, 4-5, 4-21
F CONTROLD,STOPPRT, 4-38
F CONTROLM,DEADLINE, 3-4
F CONTROLM,INTERVAL, 3-3
F CONTROLM,NET, 3-4
F CONTROLM,NEWCONLIST, 3-36
F CONTROLM,NEWSECDEF, 3-4
F CONTROLM,PROP, 3-4
F CONTROLM,REFALL, 3-4
F CONTROLM,SDOUT, 3-5
F CONTROLM,SHOWPARM, 3-8
F CONTROLO, LOADGLOBAL, 5-27
F CONTROLO,AUTOLOG, 5-18
F CONTROLO,D=, 5-7
F CONTROLO,DEBUG=, 5-30
F CONTROLO,LOG=, 5-20
F CONTROLO,NEWSECDEF, 5-29
F CONTROLO,O=ALL,REBUILD, 5-15
F CONTROLO,RELOAD, 5-2
F CONTROLO,RESETSTAT, 5-16
F CONTROLO,SNAP, 5-31
F CONTROLO,STARTSTAT, 5-16
F CONTROLO,STARTSTATS, 9-133
F CONTROLO,STOPSTAT, 5-16
F CONTROLO,STOPSTATS, 9-133
F CONTROLO,WATERMARKS, 5-31
F CONTROLx,NEWDEST, 2-51
F CTMCMEM, C=, 3-36
F CTMCMEM,D=, 3-37
F CTMCMEM,DEBUG=, 3-43
F CTMCMEM,DISPLAY, 3-37
F CTMCMEM,LOG=, 3-38
F CTMCMEM,NEWSECDEF, 3-39
F CTMCMEM,SNAP, 3-44
F CTMCMEM,STOP, 3-2
F CTMCMEM,WATERMARKS, 3-44
F IOAOMONx,LOADTREE, 4-3
F IOAVMON,D, 2-7
F monitor_name,DISPLAY, 2-5
P CONTROLM, 3-1
P CTMCMEM, 3-2
P IOAOMONx, 2-7
P monitor_name, 2-6
S IOASMON,DEBUG=, 4-108
S CONTROLM, 3-1
S CONTROLO,DEBUG=, 5-30
S CONTROLO,TYPE=CTOCMEM, 5-41
S CTMCMEM, 3-2, 3-35
S CTMCMEM,DEBUG=, 3-43
Index
S CTTINIT, 7-3
S IOAVMON, 2-7
Optical Library
Optical Library Dataserver
IBM 3995, 4-89
Optical Storage System
ROSs/OSS Media, 4-88
Option 8
Option C
Option Code
Customization, 2-10
Option OR
OPTION Parameter
Optional Wishes
CONTROL-M, 3-54
Options
OPTLIST Parameter
ORDER Parameter
Rule Lists (CTO), 5-13
Rule Table Loading (CTT), 7-6
S CTMCMEM Command, 3-35
ORDER Statement
Method 2 Job Ordering, 3-20
OSS
Migration, 4-88
OSS Database
Updating, 4-101
OSS Target Media
Migration Job, 4-94
OSSDBEXT Step
Migration Job, 4-94
OUT Parameter
Decollation Missions, 4-35, 4-72
Job Dependency, 4-25
OUT180 DD Statement
Tuning, 3-46
OUTDD Parameter
OUTDUMP Parameter
OUTGROUP Parameter
CONTROL-D Chunks, 4-39
OUTGRP Parameter
OUTLIST Parameter
CONTROL-O Initialization, 5-1
OUTPARM Parameter
Banner Exits, 10-27
OUTPARMS
Exit 3 and 14, 10-27
OUTPARMS Library
OUTPUT CDAM Parameter
AFP Printing, 4-43
OUTPUT Statement
AFP Printing, 4-42
Printers Control Monitor (CTD), 4-39
OUT-TABLE Parameter
OVERJCL Parameter
Overlays
Overriding
Allocation Member, 2-11
OWNER Parameter
P
P Option
Active Missions Screen, 4-38
Packaging
IOA, 8-1
Index
PACKED.GIF
Page Break
AFP Printing, 4-44
Page Markers
AFP Printing, 4-44
Page Mode Output
AFP Printing, 4-44
Page On Demand
Components, 4-59
CTDX024 Exit, 10-20
Description, 4-59
Index Value Selection Panel, 4-70
Problem Determination, 4-64, 5-44
Page Segments
Page Separator
Exit IOAX039, 10-8
PAGE/SWAP Dataset
Tuning, 3-46
PAGEDEF Parameter
AFP Printing, 4-42
CDAM, 4-43
PAGEDEF Statement
PAGESIZE Parameter
Paging Rate
Storage Isolation, 3-52
PANVALET Product
IOAMEM Module, F-6
Parallel Sysplex
SCOPE Argument, 11-1
Parameters
ACIF, 4-53
CDAM, 4-43
DJDE (XEROX Printers), 4-46
Restore Skeleton Job, 4-79
PARM Library
PARM Parameter
CTMMMSG Macro, 2-49
CTOCTA Utility, 9-134
CTVUNMIG Utility, 9-132
PARMLIB Parameter
Participant Control
Commands, 11-13
Participant I/O Information
Fields, 11-28
Participant Information
Display, 11-29
Displaying, 11-13
Fields, 11-26
Participant-Related Table
Dump Print, 11-20
PASSWORD Parameter
PC Installation Parmeters
CDAM File Allocation, 4-62
PDATELTH
PDSE-type Library
Date Control Records, 3-17
PDSMAN
Fetch Optimization, 3-45
Performance Considerations
Multiple-CPU Support, 3-65
Periodic Maintenance
ICE, 8-4
IOA Products, 8-4
Permanent Report List
Copy from Active, 9-99
Copy to Active, 9-104
Permanent User Report List
Description, 4-110
PF03 Function Key
PFKey Definition, C-1
Format, 2-13
Modification, 2-13
PFKey Members
Index
PGM Argument
PGM Parameter
Transaction Member, 2-8
PGMCTx Member
Program List Member, 2-10
PGMSTEP Field
PHASE Field
Physical Recovery
vs. Logical Recovery, 7-25
Physical Safety
Recommendations, 3-85
Pipe
Canceling, 11-12
Display, 11-22
End-Of-File, 11-12
Unlocking, 11-13, 11-15
PIPE Argument
End-Of-File Forcing, 11-12
Pipe Canceling, 11-12
Table Dump, 11-19
Unlocking Operator Command, 11-13,
11-15
Pipe Control
Commands, 11-10, 11-14
PIPE Field
Pipe Home System
I/O Information, 11-11, 11-14
Pipe I/O Information
Fields, 11-26
Pipe Information
Display, 11-23
Displaying, 11-11, 11-14
Fields, 11-24, 11-29, 11-32
Summary, 11-10, 11-14
Pipe Lock
Removing, 11-13, 11-15
PIPE NAME Field
Pipe Rule
Displaying, 11-10
Holding, 11-8
Management, 11-6
Manual Loading, 11-6
Releasing, 11-8
Pipe Rule Table
Deleting, 11-7
PIPE-FLG Field
Pipe-Related Table
Dump Print, 11-19
PIX File
PMO
PNRSDTYP
POD-API Application
Report Access, 4-70
Pool Definition
DD Statement (CTT), 7-5
Initializing (CTT), 7-3
POOL Field
PORT Parameter
Post Processing Parameters
Post-Processing Utility
SYSOUT, 3-8
Postscript Output
AFP Printing, 4-44
PR/SM
PREDICTD Keyword
PREF Parameter
PREFIX Parameter
Index
Exit CTDX005, 4-50
Migration Mission Definition, 4-88
Prerequisite Condition
Adding/Deleting/Verifying, 9-16
Backup Mission Dependency, 4-72
Date Related Erasure, 3-18
Deleting, 9-13
Description, 1-9
IGNORE/SELECT (CTM), 3-18
1-16
Job Dependency, 4-28
Manual Conditions, 4-4
Printing Mission Dependency, 4-35
Presentation Mode
PREVVOL Keyword
Volume Record, D-7
Primary Extent Dataset
Primary Key
Primary Migration. See Migration
Primary Option Menu
Customization, 2-15
Description, 1-4
Format, 2-14, 2-16
PRIMARY Parameter
Exit CTDX005, 4-51
Print Destination
Print Job Tailoring
Exit CTDX009, 10-17
PRINT Parameter
Print Services Facility
PRINT/CDAM PARM Values
AFP Reports, 4-61
PRINTED Status
PRINTED-WAIT BKP Status
Printer Command
Exit CTDX002, 10-14
Printer Control
Printer Emulator
XEROX Reports, 4-56
Printer List
PRINTER Parameter
Opening/Closing Printers, 4-37
Printers
AFP Printers, 4-42
Opening/Closing, 4-30, 4-37
XEROX, 4-46
Printers Control Monitor
Activation CTD, 4-1
OUTPUT Statement, 4-39
XEROX Printers, 4-52
Printing
Data File (CTT), 9-167
Database Records (CTT), 9-167
Global Control, 10-27
Index File (CTT), 9-167
Stacking Stacking File, 9-167
Printing Characteristic
OUTPARMS Library, 4-48
Printing Mission
Batch Processing, 4-33
CHUNKSIZE Parameter, 4-36
CTDPRDAY Procedure, 4-16
Decollation Missions, 4-35
Management, 4-30
Scheduling, 4-13
Scheduling Dates, 4-34
Workflow, 4-32, 4-38
Printing Mission
ACIF Parameter Member, 4-54
Index
Parameters, 4-31
Printing to a File
Exit CTDX005, 4-49
PRINTSYS Parameter
PRIORITY Field
Priority Values
Refreshing (CTM), 3-4
PRIVATE Parameter
Exit CTDX005, 4-51
Commands, 11-16
CTOGATE, 5-44
Problem Resolution
Processor Resource/Systems Manager. See
PR/SM
PROCSTEP Field
Production Control System
Production Job Report
VM Support, 3-76
Production Job Sysout
Routing via JCL, 3-76
Routing via Sysout Functions, 3-77
PROF Parameter
Profile Attributes, 2-36
Profile
Description, 2-33
Members, 2-33
Profile Member Format, 2-34
Saving a Profile Member, 2-36
Profile Variables
Color Support, 2-41
Modification, 2-36
Program List Member
Default Members, 2-10
IOA Customization, 2-9
Program Names
IOA Applications, A-1
PROGRAM Parameter
PROMPT Parameter
PROP Command
CONTROL-M, 3-4
PROTECT Parameter
PROTECTED Attribute
PRTDBG DD Statement
Archive Server Procedure, 4-108
CMEM Procedure, 3-44
PRT-FLG Field
PRTLIST Member
Mission List (CTD), 4-15
PRTMIS Parameter
PRTMON# Parameter
PRTORDER KSL Utility
PSCHDTYP
PSO Support
Switch from SAPI Support, 3-8
Pull Mode
Push Mode
PUTMEM Request
IOAMEM Module, F-2
PZUMFAPP
PZUMFGRUP
Q
QJT Table
Data Dump, 11-20
Index
QNAME Installation Parameter
QNAME Parameter
Quantitative Resource
Adding/Deleting/Modifying, 9-16
Description, 1-9
Quick Submit Facility
QUICKFETCH
R
R1.7
RACF Exit, 3-88
R1.8
RACF Exit, 3-88
RACF
RBA
RBA Keyword
Trace Data, D-14
RBA Parameter
CTTIOS Macro, 7-37
RBAOFF Parameter
RBAOFS Parameter
RBTTYPE Parameter
RC Parameter
CTTIOS Macro, 7-37
RDBCCIF Parameter
XEROX Reports, 4-58
RD-EROPT Field
RDR/WTR Field
RDRLIST Command
File Transfer, 3-75
READ Function
Base Level API (CTT), 7-35, 7-40
READCPU Keyword
Dataset Record, D-5
READDDN Keyword
Dataset Record, D-5
READDDT Keyword
Dataset Record, D-5
Reading Files
API Interface (CTT), 7-40
READJBN Keyword
Dataset Record, D-5
READNEXT Function
Base Level API (CTT), 7-35, 7-41
READPGM Keyword
Dataset Record, D-5
READSTEP Keyword
Dataset Record, D-5
READTM Keyword
Dataset Record, D-5
READUAD Keyword
Dataset Record, D-5
READVOL Function
Real-time Environment
CONTROL-T, 7-2
Real-Time Environment
CONTROL-T, 7-4
Termination (CTT), 7-6
Reason Codes
Macro CTTIOS, 7-37
REBUILD Option
CMEM Facility, 3-36
Rule Loading (CTO), 5-6
Rebuilding
Access Method Variable File (CTB),
9-30
CTB Index, 9-79
CTO Index, 9-138
Group File (CTB), 9-30
Report File (CTB), 9-30
REC Parameter
CTTIOS Macro, 7-37
RECALC Report
CTTRTM Utility, 9-219, 9-229
RECAT Parameter
CTTRCV Utility, 9-193
Index
RECDEL Statement
RECEIVE Command
File Transfer, 3-75
RECFM Parameter
APAPARM Library, 4-44
Dataset Record, D-5
Exit CTDX005, 4-51
RECFROM Keyword
Volume Record, D-7
Recipient Tree
CTDSE24 Security Module, 10-20
Exit CTDX004, 10-15
Exit CTDX021, 10-19
FIle Transfer Monitor, 4-4
IP Address, 4-65
Loading via IOA, 4-3
Reloading, 4-66
Reloading (CTD), 4-3
RECNUM Field
IOAMEM Module, F-1
RECNUM Parameter
Record Selection Logic
CTT Utilities, 9-146
Record Zero
Recovery
Access Method Files, 4-119
CONTROL-M, 3-16
CONTROL-T, 7-20
CONTROL-T Repository, 7-25
MDB from Trace File, 9-191
Selective (CTT), 7-27
Split/Merge Process (CTT), 9-273
Recovery Procedure
Group Entity, 3-15
RECREATE Parameter
RECTYPE Keyword
Trace Data, D-14
RECUPD Statement
RECVLNUM Keyword
Volume Record, D-8
REFALL Command
CONTROL-M, 3-4
Reformatting
Refreshing
CMEM Security Cache, 3-39
CONTROL-M Security Cache, 3-4
Rule Definitions (CTT), 7-8
REG Parameter
Region Size
CMEM, 3-39
CONTROL-O, 5-9
RELEASE Command
Pipe Rule, 11-8
RELOAD Command (CTO), 5-2
RELOAD Mode
Reloading
CONTROL-T Rules, 7-8
Exits (CTD), 10-20
Recipient Tree, 4-3
User Exits (CTT), 7-3
RENAME Parameter
REP Parameter
REP5ALL
KSL Log Report, 3-94
Repeating Step
REPFSCR Job
Index
REPLACE Parameter
Replacing
CONTROL-O IPL Monitor, 5-14
Exits (CTD), 10-20
REPLIST Member
REPLOGAL Program
KSL Log Report, 3-94
REPNAME Parameter
REPORDER KSL Utility
Report
Deleting (CTD), 9-106
Dependency on CTM Job, 4-25
Printing to a File, 4-49
Scratch Report (CTT), 9-218
Report Decollating Mission
Example, 4-68
Report File (CTB)
Formatting, 9-30
Rebuilding, 9-30
Report Generation (CTT)
Sample Reports, 9-206
Report List Files
Active, 4-112
History, 4-113
Management (CTD), 4-109
Permanent User Report, 4-110
Summary, 4-115
Workflow (Diagram), 4-115
Report Parameter
REPORT Parameter
REPORT Statement
Report Status
Reports
Repository
Backup and Recovery (CTT), 7-25
IOA Products, 1-10
Overview (CTT), 7-9
Recovery Methods (CTT), 7-25
Selective Recovery (CTT), 7-27
RES File. See Conditions/Resource File
Tuning, 3-47
RESCCIF Parameter
XEROX Reports, 4-58
RESETR C Command
SMP/E, 10-1
RESETSTAT Command
Message Statistics (CTO), 5-16
RESFILE Parameter
XEROX Reports, 4-57, 4-58
RESIDENT Parameter
RESLOT Parameter
Resource Control
Resource Information
Display, 4-107
Resource Utilization
CMEM, 3-44
CONTROL-O, 5-31
RESREC# Parameter
RESTART Parameter
Restoration
Disaster Recovery, 3-86, 3-87
RESTORE IN PROCESS Status
Restore Mission Abend, 4-81
Index
Restore Job Tailoring
Exit CTDX011, 10-17
Restore Mission
CTDRSDAY Procedure, 4-16
Default Missions, 4-15
Exception Handling, 4-81
History User Report List, 4-113
Overview, 4-77
Post Processing Parameters, 4-80
Scheduling, 4-13
Skeleton Job Parameters, 4-79
Workflow, 4-78, 4-79
RESTORED Parameter
Restoring
RESTYPE Parameter
ACIF Reports, 4-53
RESUME Mode
RESWPF3
Retention
RETENTION DAYS Parameter
Retention Management
CTR Interface to CTT, 7-29, 10-12
Retention Period
Backup Mission (CTD), 4-75
Migrated Report List, 9-123
Retention, Non-specific
RETPD Parameter
RETRO Parameter
Decollating Scheduling, 4-14
Return Codes
RETURNS Parameter
RETVLTFT Keyword
Volume Record, D-8
REXX Command
VM Support, 3-81
RJE/RJP Workstation
RLM Control Block
CTTRLM dsect, 7-62
Rule Search API (CTT), 7-61
RLSE Parameter
Exit CTDX005, 4-51
RMID
Definition, 10-2
RMM
Robot Interface
Exit CTTX008, 10-30
Roll Back Recovery
Roll Forward Recovery
Roof Exit
CTRX001G, 10-12
ROSCOE
Color Support, 2-47
Cross-Memory Interface, 2-1
Online Facility Exit, 10-6
ROSCOE Support
ROSs/OSS Media
IOA Archive Server, 4-100
Optical Storage Systems, 4-88
ROUT Parameter
RPF
Mission Scheduling (CTD/V), 4-16
RQT Table
Data Dump, 11-20
RSCS Machine
VM Support, 3-72
RSI Control Block
Rule Search API, 7-62
Index
RSO Block
Example (CTT), 7-61
RSTLIST Member
RSTORDER KSL Utility
RSVNONR MVS Parameter, 2-5
RSVSTRT MVS Parameter, 2-5
RTNFROM Keyword
Dataset Record, D-5
RTNTYPE Installation Parameter
RTNTYPE Parameter
RTNUPD Parameter
Rule
Automatic Loading (CTO), 5-4
CTB Activation, 6-5
Deactivating (CTO), 5-7
Loading (CMEM), 3-35, 5-4
Loading (CTO), 5-5
Loading (CTT), 7-6
Loading Exit (CMEM), 10-11
Loading Exit (CTO), 10-31
Loading Exit (CTT), 10-29
Operation Mode (CMEM), 3-38
Operation Mode (CTO), 5-20
Order/Force Exit (CMEM), 10-11
Order/Force Exit (CTO), 10-31
Scheduling (CTO), 5-15
Rule
Refreshing (CTT), 7-8
Rule Activity File
Exit CTBX004, 10-28
Rule Activity File (CTB)
Formatting, 9-30
Rebuilding, 9-30
RULE Argument
Hold Rule, 11-8
Release Rule, 11-8
Rule Definition (CTB)
Example, 6-6
RULE Field
Rule List
Rule List Member
Multiple Lists (CMEM), 5-14
Multiple Lists (CTO), 5-13
RULE Parameter
Rule Search API
Example, 7-65
Invoking, 7-63
Output (CTT), 7-61
Return Codes, 7-64
Sample Call, 7-64
Usage, 7-60
Rule Status Screen
Displaying Rules (CTO), 5-15
Rule Status Screen (CTO), 5-16
Rule Table
Date, 7-6
Loading (CTT), 7-3, 7-6
Rule Table List
Rule Usage
Overview, 1-5
RULEINFO Parameter
RULELIB Parameter
RULELIST Member
CTO Rule List, 5-41
Format (CTO), 5-4
RULEMEM Parameter
RULER Parameter
Exit CTDX005, 4-51
RULLIST Member
Format (CTT), 7-6
RUNTCACH Parameter
Security Cache (CTO), 5-29
Runtime Environment
CONTROL-B, 6-5
Index
Runtime Environment (CTB)
Invoking, 6-5
S
S CTLMON
Operator Command, 11-1
S IOASINIT,OPTIONS=W Command
Writer Facility Initialization, 4-42
SACTCNF
SACTDEL
SACTFOC
SACTMOD
SACTRER
SAMAWND
SAMDELI
SAMPLE Library
KSL Scripts, 3-94
SAPI Support
Switch to PSO Support, 3-8
SAPRWND
SARSWND
SBALTBO
Profile Variable (CTB), 2-45
SCACPUID Keyword
SMF Record, D-14
SCADATE Keyword
SMF Record, D-14
SCADSNAM Keyword
SMF Record, D-14
SCAJBNAM Keyword
SMF Record, D-14
SCATIME Keyword
SMF Record, D-14
SCHEDULE TAG Field
Scheduling
Balancing Missions, 6-2
CONTROL-M, 4-25
CONTROL-O Rules, 5-15
CTD and CTM Workflow, 4-22
CTD Missions, 4-13
Non-CONTROL-M, 4-27
Scheduling Calendar
Scheduling Date
Scheduling Facility
Calendar-based Rules (CTT), 7-8
Scheduling Parameters
Scheduling Table
Scheduling Tables
Regular to Group Conversion, 9-59
SCOPE Argument
Hold Rule, 11-8
Release Rule, 11-8
Rule Deleting, 11-7
Rule Loading, 11-6
WorkLoad Monitor Command, 11-1,
11-3
SCOPE Parameter
CONTROL-B Missions, 6-11
SCRATCH Parameter
Scratch Report
SCRATCH Report
Fields, 9-228
Scratch Volumes
Daily Report, 7-8
SCRDT Keyword
Volume Record, D-8
Screen Definition
Constant Blocks, 2-19
Macros, 2-17
Profile Attribute, 2-36
Index
Screen Members
Screen Modification
Recommended Stages, 2-19
Screens
Customization, 2-17
Primary Option Menu, 2-14, 2-15
Report Decollating Mission, 4-68, 4-99
Rule Definition (CTB), 6-6
SCRPROT Parameter
SDECWND
SDENSITY Keyword
SDOUT Command
CONTROL-M, 3-5
SDWYCNA
SEARCH Parameter
Secondary Extent Dataset
Secondary Migration. See Migration
SECONDARY NAME Parameter
SECONDARY Parameter
Exit CTDX005, 4-51
SECONDARY SKELETON
Migration Job, 4-84
SECPREF Parameter
Migrated File Name, 4-91
SECUDATA Library
USERMODs, 10-1
Security
CMEM, 3-39
CONTROL-M, 3-4
Description, 1-14
User Reports, 10-14
Security Cache
Refreshing (CTO), 5-29
SELECT Statement
Program CTMFRM, 3-18
Selection Criteria
(CTT), 9-146
Selective Recovery
Semiconductor Devices
Tuning, 3-47
SEPDS JES2 Parameter
SEQ Parameter
SEQL=filename
CATEGORY Field, 4-50
Sequential File
IOA Log, 9-21
Printing to, 4-49
Sequential Read
SER Parameter
CTTTPI Utility, 9-293, 9-294, 9-295
Session Handling Product
VM Support, 3-75
SET ICS Command
Tuning, 3-51
SET IPS Command
Tuning, 3-51
Shared DASD
Shared DASD (CTM), 1-16
Shared Spool (CTM), 1-16
Shout Facility
Exit CTDX017, 10-18
Exit IOAX034, 10-7
SHOUT Facility
VM Support, 3-82
Shout messages
Daylight Savings Time, 3-33, 3-34
Show Screen Filter
SHOW Window Filters
Profile Customization, 2-35
Index
SHOWBLINE Parameter
@LINE Display Format Line, 2-22
SHOWPARM Command
CONTROL-M, 3-8
SHRQNAM Installation Parameter
SHUT Command
Active Pipes, 11-12
SIMULATE Parameter
Simulation
CTO Environment, 9-141
Overview, 1-14
Simulation Facility
SIMULATION Parameter
Simulation Reports
SINGLE Option
SINSLMT
Profile Variable (CTT), 2-43
Size
Active Missions File, 4-116, 9-97
Active Transfer File, 4-117, 9-98
Automation Log, 5-18, 9-144
CONTROL-M Files, 3-7
Skeleton Job
Example, 4-86
SKELETON Parameter
Sleeping Interval
CMEM, 3-38
CONTROL-D, 4-2
CONTROL-M, 3-3
Tuning, 3-47
SL-NAME Field
SLNAME Keyword
Volume Record, D-8
SLNFPAG
Slot Numbers
Vaulted Volumes, 9-304
SLOTNUM Keyword
Volume Record, D-8
SMF
Exit CTDX006, 10-17
Type 15 Records, 9-276
SMF Accounting
CONTROL-D, 4-120
SMF Record
Archive Server Request, 4-120
Keywords, D-14
SMF Records
SMFID Field
SMISTBO
SMNAME Parameter
SMP/E
Link-Edit Updates, 10-3
Product Maintenance, 1-3
SMP/E Modules
IOA Packaging, 8-1
SMSCWND
Profile Variable (CTO), 2-39
SMSGERR
SMSGINF
SMSGSVR
Index
SMSGWRN
SMSINTR Parameter
SMS-Managed Environment
SMSMC Keyword
Dataset Record, D-5
SNA Connection
SNAP Command
CMEM, 3-44
CONTROL-O, 5-31
SNAP ID Field
Data Area Dump, 11-19
Snapshot
CTT Database Files, 9-167
SNC File
Conditions/Resource File, 2-52
Tuning, 3-47
SNRSCNE
Profile Variable (IOA), 2-39
SNRSDRNG
SNTPCBR
SNTPCED
SOLVHFC
SOLVICL
Monochrome Terminals, 2-41
Profile Variable (CTV), 2-41
SOLVLVC
Profile Variable (CTV), 2-41
SOLVOCL
SOLVSCL
SOMPTBO
Profile Variable (CTO), 2-46
SORTBY Parameter
SORTBY Statement
Utility CTORSTM, 9-140
Sorting
Access Method Files, 9-31
Space Calculation
CART Migration, 4-88
SPACE Parameter
SPACETY Parameter
Exit CTDX005, 4-51
Special Character Printing
Exit CTDX007, 10-17
Split/Merge Process
Description (CTT), 9-271
Merge Utility, 9-177
SPOOL Configuration
SPOOL Sharing
SPY281I Message
SPY28GI Message
SQFILE Parameter
IOADLD Utility, 9-37
SRCHLMT
SRCMTBO
SREPTBO
SRESCND
Profile Variable (IOA), 2-39
SRESDRNG
SRLDATO
Profile Variable (CTT), 2-46
Index
SSCHBRO
SSCHTBO
ssname Parameter
SSTACNS. See SACTCNF
SSTALTO
SSTAWND. See SACTRER
SSTDEL1. See SACTDEL
SSYVORD
Profile Variable (CTR), 2-43
SSYVSCL
Profile Variable (CTR), 2-42
SSZMWND
STACKID Parameter
Stacking Database
Daily Update, 7-8
Defragmentation, 7-9
Structure, 7-18
Stacking Facility
Exit CTTX002, 10-29
Exit CTTX010, 10-30
Stacking Facility (CTT)
Starting, 7-5
Stopping, 7-5
Stacking Logic
Stacking Record
Keywords, D-12, D-15
Stacking Statistics File
Build/Update Utility, 9-276
Creation, 9-158
Formatting, 9-159, 9-163
Index Integrity, 9-166
Integrity, 9-165
Loading, 9-161
Printing, 9-167
Unloading, 9-162
Update Utility, 9-180
START Function
STARTDATE Parameter
STARTGEN Command
Generic Processing (CTD), 4-1, 4-21
Starting
Printers, 4-37
STARTJDE Parameter
XEROX Reports, 4-57
STARTJDL Parameter
XEROX Reports, 4-57
STARTOE Command
OpenEdition Restart, 5-22
STARTPRT Command
Starting a Printer, 4-37
STARTSTAT Command
STARTSTATS Command
CTO Message Statistics, 9-133
STARTSTK Mode
START-TIME Field
STARTTIME Parameter
START-WHEN-OVER Parameter
STAT Date Reference
SELECT/IGNORE Statemetns, 3-18
STAT Field
STAT Parameter
CTMPARM Member, 9-70
STAT1 Field
STAT2 Field
Statcking Statistics File. See Stacking
Database
Statistics
Index
Message Statistics File, 9-133
Statistics File
Maintenance, 5-17
Statistics File (CTM)
Expanding, 3-7
Statistics File (CTO), 5-16
Full Conditions, 5-17
STATS Rule Table (CTO), 5-17
STATUS Field
STATUS Parameter
IGNORE/SELECT Statements (CTM),
9-63
Status Screen
Fields, G-1
Status Screen (CTM)
Bottom Line, G-7
CLASS= in @STYLE Section, G-7
Customization, G-1
STEP Option
STEPLIB DD Statement
Tuning, 3-45
STEPLIB Parameter
CTMFRJNL Utility, 9-69
STEP-NUM Field
STKADD Parameter
STKBLKCT Keyword
STKBLKSZ Keyword
STKCOMPF Keyword
STKDATE Keyword
STKDEFFT Parameter
STKDEL Parameter
STKDSN Keyword
Stacking Record, D-12, D-15
STKIND Keyword
STKJBN Keyword
Stacking Record, D-12, D-15
STKLSOBS Keyword
STKLSPAN Keyword
STKMODE Installation Parameter
STKOBS Keyword
STKPGM Keyword
STKPRED Keyword
STKSRCHL Parameter
STKTEST Parameter
STKTIME Keyword
STKUNAM Keyword
STKUNIT Keyword
STKUPD Parameter
STKVOL1 Keyword
STOP Parameter
STOPGEN Command
Decollation Deactivation, 4-5
Generic Processing (CTD), 4-21
STOPOE Command
OpenEdition Deactivation, 5-22
Index
STOPPRT Command
Stopping a Printer, 4-38
STOPSTAT Command
STOPSTATS Command
CTO Message Statistics, 9-133
STOPSTK Mode
Storage Allocation
CONTROL-O, 5-10
Storage Fencing. See Storage Isolation
Storage Isolation
Tuning, 3-52
Storage Requirements
CMEM, 3-39
CONTROL-O, 5-9
STORE Parameter
Printing Mission, 4-53, 4-62
STRTCH Keyword
Structural Recoverability
Structure
Media Database, 7-9
STUDBLC Keyword
STUDBLKS Keyword
STUDCMPF Keyword
STUDDEN Keyword
STUDDSN Keyword
STUDDTE Keyword
STUDJOB Keyword
STUDPGM Keyword
STUDRTCH Keyword
STUDTME Keyword
STUDUNIT Keyword
STUDVOL Keyword
STUFLAG1 Keyword
SUB Parameter
CONTROL-O Initialization, 5-1
SUBMIT Option
AutoEdit Simulation, 3-92, 3-94
SUBSYS JCL Parameter
CDAM Files, 9-101
SUBSYS Parameter
IOA Subsystem, 5-12
Subsystem Chains
SUFFIX Parameter
Utility IOADCPY, 9-33
SUMMARY Parameter
Suppression
SUS2LMT
SUS2SRTI
SUSPEND Mode
Suspended Mode
CONTROL-T, 7-5
SUSRFTR
SUSRHDR
SUSRVEW
SVC
Exit CTTX003, 10-29
Installation (CTT), 7-4
Index
SVC Number, 7-2
SVEWFFI
SWHYCNA
SYNC Parameter
Synchronization
SYNC-TYP Field
Syntax
Rule Definitions (CTB), 9-76
SYSAFF Specification
SYSCCIF Parameter
XEROX Reports, 4-58
SYSDATA
Trace Facility, 3-9
SYSDATA (CTM), 3-5
SYSDATA Entry
SYSDATA Files
VM Support, 3-76
SYSDATA Option
User List Report Exit, 10-16
SYSIMAGE Facility
CTOCTI Utility, 9-136
Input Generation, 9-135
SYSIN DD Statement
Utility CTTTPI, 9-289
SYSLIB Library
Ad-hoc Maintenance, 8-9
SYSOUT
Post-processing Utility, 3-8
SYSOUT File
Punch Class, 3-76
Sysout Scanning
Exit CTMX003, 10-9
Sysout/Report Viewing
Exit IOAX029, 10-7
Sysplex Environment
Command Scope, 11-2
SYSPRINT DD Statement
SYSTEM Argument
System Crash
Automatic Recovery, 3-95
SYSTEM Field
System Maintenance
SYSTEM.CCF File
Password Information, 4-56
T
TABLE Argument
Data Dump, 11-20
Hold Rule, 11-8
Release Rule, 11-8
Rule Deleting, 11-7
Rule Loading, 11-6
TABLE Field
Table List Screen
Tape Cartridge
Tape Erasure, 9-287
Tape Initialization, 9-285
Tape Mapping, 9-286
Tape Pool
Tape Pull List
Exit CTMX017, 10-10
TAPEMAP Function
TAPEMS Parameter (CTR)
Interface to CTT, 7-29
TAPERAS Function
TASKS Parameter
Index
TBLT Parameter
TCOLOR
TCP/IP File Transfer Protocol
CTDX023 Exit, 10-19
TCP/IP Protocol
TCT
Creating a Local TCT, 7-32
CTTTCT Macro, 7-31
Load Request, 7-32
Real-Time, 7-31
TCT Parameter
CTTIOS Macro, 7-37
TCTGTCT Macro
Real-Time TCT Address, 7-31
TDBCS
TEMPORARY Attribute
TERM Mode
TERM Parameter
Terminal Characteristics
Double Byte Character Set, 2-47
Terminal Emulator
VM/VTAM, 3-75
Termination
CONTROL-T, 7-6
TERMTYPE
TESTRUL Parameter
TIME Keyword
SMF Record, D-14
Trace Record, D-13
TIME Parameter
TIME UNTIL Field
> Symbol, 3-11
TIMEFROM Parameter
TIMEOUT Parameter
Timestamp
TIMESTMP Field
TIMETO Parameter
TITLE Parameter
TMPCCIF Parameter
XEROX Reports, 4-58
TO Parameter
TO Parameter
TODATE Parameter
TODSN Parameter
TOKEY Parameter
TOT-RDR Field
TOT-WTR Field
TOTYPE Parameter
TOUNIT Parameter
TOVOLUME Parameter
Trace Data
Keywords, D-14
Trace Facility
Activating, 11-16
CONTROL-M, 3-9
Description, 11-16
Monitor Initialization, 11-18
Setting, 11-18
Stopping, 11-18
TRACE Facility
Trace File
Backup, 7-25
Index
Copying, 9-152
CTTSTK Utilitiy, 9-276
Enlarging, 7-22
Formatting/Creating, 9-160
Formatting/Initializing, 9-155
MDB Recovery, 9-191
Structure (CTT), 7-17
Utilities, 9-5
Trace Modes
Rule Operation (CTO), 5-20
TRACE Parameter
Trace Record
Keywords, D-13
Tracing Facility
TRANID Parameter
IOAONL CLIST, 2-2
Transaction ID
IOA Online, 2-2
Transaction Member
IOA Customization, 2-8
Predefined (Reserved) Members, 2-8
Transient Data Queue
CTO/CICS Interface, 5-42
TRC Parameter
Table Reference Character, 4-48
TRCIN Parameter
TRCOUT Parameter
TRCSIZE Parameter
Trace File Size, 7-22
TRCVOL Parameter
Triggering by VM User
CONTROL-M Event, 3-78
TRIGGERONLY Mode
TRNA2E Member
ASCII to EBCDIC Translation, 4-62
TRNE2A Member
EBCDIC to ASCII Translation, 4-62
TRTCH Keyword
Dataset Record, D-6
TRTCH Parameter
Exit CTDX005, 4-51
TSO
Color Support, 2-47
Cross-Memory Interface, 2-1
STEPLIB Elimination, 3-53
TSO Support
TSO User
Defining, 3-90
TSO User ID
Masking, 3-29
TSO/ISPF Support
TSO/ROSCOE
IOA Server, 3-53
Tuning
CONTROL-M, 3-45
JES2PARM, 3-50
TYPE Argument
TYPE Field
TYPE Parameter
TYPELIKE Parameter
TYPERES Parameter
TYPERET Parameter
TYPERUN Parameter
Index
CTTSYNC Utility, 9-283
TYPERUN Statement
Syntax, 9-146
Utility CTTMUP, 7-21
TYPERUN=HOLD
JOB Statement, 3-79
TYPESNC Parameter
TYPEVLT Statement
U
UMIDFLTU Member
IOA SECUDATA Library, 4-56
UMRXROOF Job
Roof Exits, 10-12
UMRXROOF Member
UNAME Field
UNCTLG Parameter
UNDERSCORE Attribute
UNIT Keyword
UNIT Parameter
Exit CTDX005, 4-50
UNITD Parameter
UNITNAME Parameter
Volume Record, D-8
UNITNRS Parameter
UNITNSN Parameter
UNITRES Parameter
UNITSNC Parameter
UNIX for MVS
OpenEdition Support, 5-21
Unloading
UNMATCH Parameter
Unstacking
CTTSBD Utiility, 9-243
Update Active Missions
CTDX008 Exit, 10-17
Updating
MDB Volume, 9-182
Stacking Statistics, 9-180
UPDQNM Statement
UPDTVOL Function
UPDVOL Parameter
USCORE
USEDAYS Parameter
User Daily
CONTROL-D, 4-8
CONTROL-M, 3-10
Date Control Record (CTD), 4-9
Work Flow (CTM), 3-25
User Daily (CTD), 4-18
User Daily Job
Checkpointing, 3-20
Customization, 3-20
Scheduling Table, 3-18
Index
User Daily Procedure
Mission Scheduling (CTD), 4-16
User Exit
Reloading (CTT), 7-3
User Exits
Customization, 10-1
File Transfer, 3-70
Overview, 1-14
User Groups
CONTROL-D, 4-22
User Name
Report Distribution, 10-24
USER Parameter
User Profile, 2-33
User Report List File Utilities
Summary, 9-4
User Reports List
Exit CTDX004, 10-14
User Reports List File
Maintenance, 4-117
USERDATA Keyword
Volume Record, D-8
USERID Keyword
Trace Record, D-13
USERMOD
++VER Statement, 10-3
Installation Jobs, 10-1
SMP/E, 10-1
USERMOD Jobs
Summary, 10-4
Users
Multiple Users (IOA), 2-4
Utilities
Control Statement Syntax, 9-146
CTBABI, 9-75
CTBCMP, 9-76
CTBDBCP, 9-77
CTBDBIB, 9-79
CTBDBVCG, 9-81
CTBDBVCP, 9-83
CTBDBVDL, 9-86
CTBDBVIG, 9-88
CTBJAFCP, 9-90
CTBJAFDL, 9-92
CTBJAFIG, 9-94
CTDBLXRP, 9-95
CTDCA2P, 4-111, 9-99
CTDCAMF, 9-96
CTDCATF, 9-98
CTDCCU, 9-101
CTDCLHIS, 4-114, 9-103
CTDCP2A, 9-104
CTDDELRP, 9-106
CTDDIB, 9-114
CTDDIG, 9-115
CTDULD, 9-116
CTDUPBKP, 9-117
CTMBGRP, 9-59
CTMCAJF, 9-62
CTMFRCKP, 9-68
CTMFRJNL, 9-69
CTMRSTR, 9-73
CTMSIM, 9-2
CTOALOCP, 5-18, 9-144
CTOCSF, 5-17, 9-133
CTOCTA, 9-134
CTOCTI, 9-135
CTODBIB, 9-138
CTORSTM, 9-140
CTOTEST, 9-141
CTTACP, 7-23, 9-152
CTTAFR, 9-155
CTTBIX, 7-20, 7-25, 9-156
CTTCRDF, 9-158
CTTCTRC, 9-160
CTTDBDLD, 9-161
CTTDBDUL, 9-162
CTTDBF, 9-163
CTTDBIB, 9-164
CTTDBID, 7-25, 9-165
CTTDBII, 9-166
CTTDBPRT, 9-167
CTTDLD, 9-169
CTTGVL, 9-173
CTTIDB, 7-9, 7-20, 9-175
CTTMER, 9-177
CTTMUP, 7-21, 9-180
CTTRCV, 7-25, 9-191
Index
CTTRPT, 9-195
CTTRSM, 9-214
CTTRTM, 7-8, 9-218
CTTSCA, 9-264
CTTSPL, 9-271
CTTSTK, 7-8, 9-276
CTTSTKR, 9-279
CTTSYNC, 9-283
CTTTPI, 9-285
CTTTRB, 9-300
CTTVTM, 7-8, 9-301
CTVCLMIG, 9-123
CTVDELI, 9-125
CTVJAR, 9-129
CTVUNMIG, 9-132
Dataset Formatting, B-1
IEBGENER, 7-9
IOABLCAL, 9-7
IOACLRES, 4-29, 9-13
IOACND, 4-28, 9-16
IOACOPRS, 9-20
IOACPLOG, 9-21
IOADBF, 9-23
IOADBSR, 4-118, 9-31
IOADCPY, 9-33
IOADIG, 9-35
IOADII, 9-36
IOADLD, 9-37
IOADPT, 9-39
IOADUL, 9-40
IOAFRLOG, 9-42
IOAFRNRS, 9-43
IOAFRRES, 9-44
IOALDNRS, 3-20, 4-4, 4-30, 9-46
IOANOTE, 9-49
IOAOPR, 9-50
IOARROT, 10-6
IOATEST, 9-51
IOAVERFY, 9-53
kCTBFRM, 9-89
Overview, 1-14
Summary, 9-1
Utility CTMJSA
Exit CTMX005, 10-9
Utilties
CTMJSA, 9-70
V
Validity
Checking via CONTROL-B, 6-7
Variable Database
Files, 5-23
Variable Generations
Utility CTBDBVCG, 9-81
VARIABLE Parameter
Variables
Banner Pages, 10-23
Vault Definition
Initializing (CTT), 7-4
VAULT Keyword
Volume Record, D-8
Vault Management
VAULTED Parameter
VCHANGED Keyword
Volume Record, D-8
VCHANGET Keyword
Volume Record, D-8
VCHANGEU Keyword
Volume Record, D-8
VDENSITY Keyword
Volume Record, D-8
VENDOR Keyword
Volume Record, D-8
VENDOR Parameter
VER Parameter
Index
VERIFY FILE Parameter
VERIFY Mode
VERIFY Parameter
VERIFY-IN-HISTORY Parameter
Viewing
Virtual Lookaside Facility. See VLF
VLF
Module Fetching, 3-45
VLTBYDS1 Parameter
CTTPARM, 9-301
VLTDSNUM Keyword
Volume Record, D-8
VLTENTDT Keyword
Volume Record, D-8
VLTENTNM Keyword
Volume Record, D-8
VLTEXPDT Keyword
Volume Record, D-8
VLTEXTYP Keyword
Volume Record, D-9
VLTPREFL Keyword
Volume Record, D-9
VM Commands
IOAVAUTO Machine, 3-81
VM CP Command
CONTROL-O, 3-84
MVS Under VM, 3-80
VM Events
Triggered by CONTROL-M, 3-79
VM Machine
Access via KOA, 3-84
VM Support
CONTROL-D, 3-84
CONTROL-O, 3-84
CONTROL-O/PC, 3-84
Description, 3-71
VM/VTAM
MVS Communication, 3-75
VM/VTAM Machine
VM Support, 3-72
VOL Parameter
VOL1 Parameter
Exit CTDX005, 4-51
VOL2 Parameter
Exit CTDX005, 4-51
VOLADD Statement
VOLBIX Statement
VOLCNT Parameter
Exit CTDX005, 4-51
VOLD Parameter
VOLDEL Statement
VOLEDMID Keyword
Volume Record, D-9
VOLEXCP Keyword
Volume Record, D-9
VOLEXPDT Keyword
Volume Record, D-9
VOLEXPTY Keyword
Volume Record, D-9
VOLFLAG2 Keyword
Volume Record, D-10
VOLFLAGS Keyword
Volume Record, D-10
VOLIND Keyword
Volume Record, D-10
VOLODESC Keyword
Volume Record, D-10
VOLOWNER Keyword
Volume Record, D-10
VOLRES Parameter
VOLSCR Statement
Index
VOLSCRF Statement
VOLSEQ Keyword
Volume Record, D-10
VOLSER Field
VOLSER Keyword
Trace Data, D-14
Volume Record, D-11
VOLSER List
OSS Migration, 4-88
VOLSER Parameter
CONTROL-O Files, 5-13
VOLSNC Parameter
VOLSNUM Keyword
Dataset Record, D-6
VOLSTAT Field
VOLSTAT Keyword
Volume Record, D-11
Volume Definition
Exit CTTX004, 10-29
Volume Expiration
Volume Record
Dataset Record, 7-13
Index File, 7-13
Keywords, D-6
Volume Set Parameter
FileTek, 4-86
VOLUPD Statement
VOLUSECT Keyword
Volume Record, D-11
VTAM
Monitor Activation, 2-7
Monitor Deactivation, 2-7
VTAM Logon
VM Support, 3-75
VTAM Support
VTR, 3-75
VTRTCH Keyword
Volume Record, D-11
V-type Index
W
W Operator, 9-8
WAIT DECOLLATION Status
WAIT MIGRATE Status
WAIT PRINT Status
CTDBLXRP Utility, 9-95
WAIT-CNT Field
WAITDEC Parameter
WAITING FOR BACKUP Status
WAITING FOR MIGRATION Status
WAITP Field
WAITPRINT Parameter
WAIT-TYP Field
Warning Message
Decollation Inactive, 4-5
WATERMARKS Command
CMEM, 3-44
Resource Utilization (CTO), 5-31
WD1685 Wish
Embedded DJDE Lines, 4-62
WD2376 Wish
XEROX Reports, 4-56
WD2949 Wish
AFPDS Format, 4-61
Index
WD3013 Wish
WHEN IN QUEUE
Generic Decollation, 4-20
Why Screen
Windows Display
WM2744 Wish
Work Modes
WORK_SPACE Parameter
XEROX Reports, 4-58
WORK_UNIT Parameter
XEROX Reports, 4-58
Workflow
CTD New Day Procedure, 4-7
CTM and CTD, 4-23
Restore Mission (CTD), 4-78
Working Set Size
Storage Isolation, 3-52
WorkLoad Monitor
Activating, 11-1
Draining Mode, 11-3
Operation Mode, 11-3
Shutting Down, 11-1
WorkLoad Program
Reloading, 11-5
WRITECCC Keyword
Dataset Record, D-6
WRITECPU Keyword
Dataset Record, D-6
WRITEDDN Keyword
Dataset Record, D-6
WRITEDT Keyword
Dataset Record, D-6
WRITEGLOBAL Command
$GLOBAL Member, 5-24
WRITEJBN Keyword
Dataset Record, D-6
WRITEPGM Keyword
Dataset Record, D-6
Writer Facility
Installation, 4-40
Overview, 4-40
Wish WD3013, 4-40
WRITESTP Keyword
Dataset Record, D-6
WRITETM Keyword
Dataset Record, D-6
WRITEUAD Keyword
Dataset Record, D-6
WT-EROPT Field
WTO
CONTROL-T Intercept, 7-2
WTO Parameter
WTOM Parameter
WTOR Parameter
WYSIWYG Viewing
XEROX Reports, 4-56
X
X98ASKOP Parameter
XCOM 6.2 File Transfer Protocol
CTDX023 Exit, 10-19
XCOM 6.2 Product
XCOM 6.2 Protocol
XEROX Printers
DJDE Parameters, 4-46
XEROX Report
WYSIWYG Viewing, 4-56
Z
Zoom Screen

AdministrationGuide Ioa514ag

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

AdministrationGuide Ioa514ag

Загружено:

Авторское право:

Доступные форматы

N E W

) have a problem interpreting the 3270 color stream.

Вам также может понравиться