CA Workload Automation CA 7® Edition - 12.0 - ENU - Configuring - 20180208 PDF

CA Workload
Automation CA 7®
Edition - 12.0
Configuring
Date: 08-Feb-2018
CA Workload Automation CA 7® Edition - 12.0
This Documentation, which includes embedded help systems and electronically distributed materials, (hereinafter referred to as
the “Documentation”) is for your informational purposes only and is subject to change or withdrawal by CA at any time. This
Documentation is proprietary information of CA and may not be copied, transferred, reproduced, disclosed, modified or
duplicated, in whole or in part, without the prior written consent of CA.
If you are a licensed user of the software product(s) addressed in the Documentation, you may print or otherwise make
available a reasonable number of copies of the Documentation for internal use by you and your employees in connection with
that software, provided that all CA copyright notices and legends are affixed to each reproduced copy.
The right to print or otherwise make available copies of the Documentation is limited to the period during which the applicable
license for such software remains in full force and effect. Should the license terminate for any reason, it is your responsibility to
certify in writing to CA that all copies and partial copies of the Documentation have been returned to CA or destroyed.
TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION “AS IS” WITHOUT WARRANTY OF ANY
KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE, OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE,
DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION, LOST PROFITS, LOST
INVESTMENT, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED IN ADVANCE OF THE
POSSIBILITY OF SUCH LOSS OR DAMAGE.
The use of any software product referenced in the Documentation is governed by the applicable license agreement and such
license agreement is not modified in any way by the terms of this notice.
The manufacturer of this Documentation is CA.
Provided with “Restricted Rights.” Use, duplication or disclosure by the United States Government is subject to the restrictions
set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) and DFARS Section 252.227-7014(b)(3), as applicable, or
their successors.
Copyright © 2018 CA. All rights reserved. All trademarks, trade names, service marks, and logos referenced herein belong to
their respective companies.
08-Feb-2018 3/722
Table of Contents
Configuration Best Practices ..................................................................... 22

Review the IBM Workload Manager (WLM) Service Class ....................................................................... 22
Update JES MAS Tuning .......................................................................................................................... 22
Use XCF for SMF Record Notification ....................................................................................................... 23
Perform File Maintenance ......................................................................................................................... 23
Reconsider JCL Files ................................................................................................................................ 24
Understand LOAD Processing .................................................................................................................. 24
Evaluate Schedule Scan Options .............................................................................................................. 25
Exclude Some Data Set SMF Feedback ................................................................................................... 25
Parallel Submission Processing ................................................................................................................ 26
Customization Best Practices .................................................................... 27

Add Batch Terminals ................................................................................................................................. 27
Add CAICCI Terminals .............................................................................................................................. 27
Add JCL Libraries ...................................................................................................................................... 28
Add TCP/IP Terminals ............................................................................................................................... 29
Add VTAM Terminals ................................................................................................................................ 29
Implement or Delete Submit Data Sets ..................................................................................................... 30
Implement Workload Balancing (WLB) ..................................................................................................... 30
Maintain the CA7AGNT VSAM File ........................................................................................................... 32
Move or Reallocate Batch Terminal Files .................................................................................................. 32
Move or Reallocate the Checkpoint and Queue Files ............................................................................... 33
Move or Reallocate the Communications Data Set ................................................................................... 33
Move or Reallocate the Database Files .................................................................................................... 33
Move or Reallocate the Log Files .............................................................................................................. 34
Order for Starting Programs ...................................................................................................................... 34
Review the Region Size ............................................................................................................................ 35
Startup Procedures Recommendations .................................................................................................... 35
Update the Initialization File ...................................................................................................................... 36
Interfaces ................................................................................................... 37
Configuring 4
Interfaces and Integration Point Best Practices ........................................................................................ 37
Batch Terminal Interface ..................................................................................................................... 38
CA Driver or Global Variables ............................................................................................................. 39
CAICCI Interface ................................................................................................................................. 39
CA JCLCheck Interface ....................................................................................................................... 40
CA Service Desk Interface .................................................................................................................. 41
CA WA Restart Option (CA 11) ........................................................................................................... 42
Email Feature ...................................................................................................................................... 43
IBM WLM ............................................................................................................................................. 45
JFM Interface ...................................................................................................................................... 46
TCP/IP Terminal Interface ................................................................................................................... 48
Interfaces with Other Products .................................................................................................................. 49
Interface with CA7LOG CAIENF Events ............................................................................................. 49
Interface with CA 1 .............................................................................................................................. 49
TIQ Command ............................................................................................................................ 50
Interface with CA APCDDS ................................................................................................................. 50
Interface with CA APCDOC ................................................................................................................ 51
Compare FSTRUC to a Database Flowchart ............................................................................. 51
Interface with CA Dispatch .................................................................................................................. 52
Forecast Print Volumes .............................................................................................................. 52
Create a Plan Data Set .............................................................................................................. 52
Interface with CA Earl ......................................................................................................................... 53
Interface with CA Easytrieve ............................................................................................................... 53
Interface with CA JCLCheck ............................................................................................................... 54
CA 7 Considerations .................................................................................................................. 54
Interface with CA Librarian .................................................................................................................. 55
Interface with CA OPS/MVS ............................................................................................................... 56
Activate the CA OPS/MVS® Event Management and Automation API ..................................... 57
Example Process SMF0-19 Browse Log Event ......................................................................... 57
Interface with CA Panvalet .................................................................................................................. 59
Interface with CA Service Desk ........................................................................................................... 59
Configure CAISDI/els For CA Workload Automation CA 7 Edition ............................................ 60
Configure CA Service Desk For CA Workload Automation CA 7 Edition ................................... 61
Configure CA Workload Automation CA 7 Edition ..................................................................... 61
CAISDI/els Events Provided By CA Workload Automation CA 7 Edition ................................... 61
SERVDESK Rules ..................................................................................................................... 62
Event Variables .......................................................................................................................... 64
Interface with CA WA Restart Option for z/OS Schedulers ................................................................. 66
ARTS Command Monitor ........................................................................................................... 67
Automatic RMS Step Insertion ................................................................................................... 67
Automatic CMT Updating ........................................................................................................... 68
Condition Code Synchronization ................................................................................................ 69
Configuring 5
Interface with Critical Path Monitoring ................................................................................................. 69
Critical Path Definition ................................................................................................................ 70
CPM Requirements .................................................................................................................... 71
CPM Requirements with JFM .................................................................................................... 72
CPM and CAIENF Maintenance ................................................................................................ 73
Interface with IBM Automated Restart Management .......................................................................... 74
Interface with IBM Health Checker for z/OS ....................................................................................... 75
Interface with IBM Workload Manager (WLM) .................................................................................... 76
Working with ICOM and IBM Workload Manager Resources .................................................... 77
Automatic Scheduling Environment JOB Statement Insertion ................................................... 77
Problem Management Interface .......................................................................................................... 78
CA 7 Statements ........................................................................................................................ 78
Problem Management Interface Tasks ...................................................................................... 79
CA Netman Model Transactions ................................................................................................ 79
CA Netman Model Transactions - Continuation Rules ............................................................... 80
Problem Management Variables ................................................................................................ 80
Interface with TSO/ISPF ..................................................................................................................... 83
VTAM Considerations ................................................................................................................ 84
ISPF Considerations .................................................................................................................. 85
CA 7 Considerations .................................................................................................................. 89
Interface with Unicenter Event Console .............................................................................................. 89
UNIX System Services Interface ......................................................................................................... 90
Invoke the Interface .................................................................................................................... 90
Environment Variables ............................................................................................................... 90
Schedule UNIX System Services Jobs ..................................................................................................... 92
External Communicators ........................................................................................................................... 92
Batch Card Load Program (BCLP) ...................................................................................................... 93
CA 7 Requirements .................................................................................................................... 94
JCL Requirements ..................................................................................................................... 94
Sample BCLP JCL ..................................................................................................................... 96
Control Statements for BCLP ..................................................................................................... 96
Control Statements Examples .................................................................................................. 102
Batch Terminal Interface (BTI) .......................................................................................................... 103
Command Format and Sequence ............................................................................................ 104
DBM List Functions .................................................................................................................. 105
Batch Commands ..................................................................................................................... 105
Use the Batch Terminal Interface ............................................................................................. 106
Interface with CAICCI ........................................................................................................................ 110
CAICCI Usage Notes ............................................................................................................... 111
Execute the CAICCI Batch Interface ........................................................................................ 112
Execute the CAICCI REXX Interface ....................................................................................... 114
Execute the CAICCI Program-to-Program Interface ................................................................ 116
Configuring 6
Interface with TCP/IP ........................................................................................................................ 119
TCIP/IP Usage Notes ............................................................................................................... 120
Execute the TCP/IP Batch Interface ........................................................................................ 121
Execute the REXX Interface .................................................................................................... 125
Execute the TCP/IP Program-to-Program Interface ................................................................. 126
Execute the TCP/IP Java-to-Program Interface ....................................................................... 129
Execute the TCP/IP C-to-Program Interface ............................................................................ 134
Manage the Trailer Step Facility ....................................................................................................... 142
Manage the U7SVC Facility .............................................................................................................. 145
Batch Step Execution ............................................................................................................... 145
Call U7SVC from a User Program ........................................................................................... 147
CA Driver Procedures, Variable Parameters, and Functions .................................................................. 148
CA Driver ........................................................................................................................................... 149
Using CA Driver ....................................................................................................................... 149
Verify JCL ................................................................................................................................. 150
Procedure Library .............................................................................................................................. 150
Create Procedures ................................................................................................................... 151
Call Procedures ........................................................................................................................ 151
Nested Procedures .................................................................................................................. 152
Include Data ............................................................................................................................. 153
Verify Data Inclusion ................................................................................................................ 153
Variable Parameters ......................................................................................................................... 154
Array Elements ......................................................................................................................... 155
Attributes of Variables .............................................................................................................. 156
Null Values ............................................................................................................................... 158
Reserved-Name Variable Parameters ..................................................................................... 158
Substrings ................................................................................................................................ 161
CA Driver and Predefined Functions ................................................................................................. 162
Arithmetic Date Functions ........................................................................................................ 163
Date Conversion Functions ...................................................................................................... 164
Day-Of-Month Functions .......................................................................................................... 166
Conditional Procedure Expansion ..................................................................................................... 167
Abort Expansion (DFLUSH) ..................................................................................................... 167
Abort Expansion of the Current Procedure (DABORT) ............................................................ 168
Branch (DGOTO) ..................................................................................................................... 168
Control Loops (DLCTR) ........................................................................................................... 168
Define Conditions (DIF) ............................................................................................................ 169
Define Step Names (DSTEP) ................................................................................................... 170
Set Variable Parameters (DSET) ............................................................................................. 170
Comments Inside CA Driver Procedures .......................................................................................... 171
Comments for CPU Jobs ......................................................................................................... 171
Comments for XPJOB Jobs ..................................................................................................... 172
Configuring 7
Conditional Execution Based on Schedule ID Example .................................................................... 172
XPJOB Driver Procedures Example ................................................................................................. 172
Manage the Network Communications Facility ....................................................................................... 173
NCF Requirements ............................................................................................................................ 174
NCF Component Data Flow .............................................................................................................. 174
NCF Component Reference ..................................................................................................... 176
NCF Planning and System Requirements ........................................................................................ 180
NCF General Notes .................................................................................................................. 180
NCF Resource Requirements .................................................................................................. 182
NCF Implementation Considerations ................................................................................................ 183
NCF General Usage ................................................................................................................. 184
Data Sets and NCF .................................................................................................................. 185
CA 7 Database and NCF ......................................................................................................... 185
Execution Options for NCF ...................................................................................................... 186
User Execution JCL ................................................................................................................. 187
System Operations and NCF ............................................................................................................ 189
NCF Initialization ...................................................................................................................... 189
Establish Communications ....................................................................................................... 190
Standard Operations ................................................................................................................ 190
NCF Operator Commands ................................................................................................................ 191
Deactivate the Trace Facility .................................................................................................... 192
LOGOFF Command ................................................................................................................. 192
LOGON Command ................................................................................................................... 192
PURGE Command ................................................................................................................... 193
SHUTDOWN Command .......................................................................................................... 193
STARTUP Command ............................................................................................................... 194
STATUS Command ................................................................................................................. 194
STOP Command ...................................................................................................................... 196
TRACE Command ................................................................................................................... 196
Cross-Platform Scheduling ...................................................................................................................... 197
CAICCI Cross-Platform Connections ................................................................................................ 198
MVS CAICCI Connections ....................................................................................................... 198
Non-MVS CAICCI Connections ............................................................................................... 199
The XPS CLIENT .............................................................................................................................. 200
Batch Submit Function ............................................................................................................. 200
Direct Submit Function ............................................................................................................. 200
Cross-Platform Tracking .......................................................................................................... 203
Cross-Platform Tracking Notes and Examples ........................................................................ 212
The XPS SERVER ............................................................................................................................ 214
Submission ............................................................................................................................... 214
Status Update .......................................................................................................................... 215
Cross-Platform Scheduling Router (XPS Router) .................................................................... 216
Configuring 8
Cross-Platform Server Password Requirements ..................................................................... 218
CA 7 XPS Server Implementation Checklist ............................................................................ 222
CA Workload Automation Agents ...................................................................................................... 224
Enable the CA 7 Edition Agent Interface .................................................................................. 225
CA 7 Agent Job Types ............................................................................................................. 227
CA 7 Agent Job PARMLIB Member Creation .......................................................................... 229
Agent and CA IAS Commands ................................................................................................. 229
Manage Email from CA 7 ........................................................................................................................ 230
JES3 Site Email Usage ..................................................................................................................... 231
Email Address Members ................................................................................................................... 231
Email Template Variables ................................................................................................................. 232
Email Templates ...................................................................................................................... 232
Special Characters ................................................................................................................... 235
Email Test Utility ............................................................................................................................... 235
Control Statements .................................................................................................................. 236
Data Set for TCP/IP Data .................................................................................................................. 236
Global Variables ...................................................................................................................................... 237
Substitution Process ......................................................................................................................... 237
Job Statements ........................................................................................................................ 237
CA Driver Procedures .............................................................................................................. 238
Standard Procedures ............................................................................................................... 238
Substitution Rules and Restrictions .................................................................................................. 238
Reserved Variable Names ................................................................................................................ 240
General Reserved Variable Names ......................................................................................... 240
Specific Reserved Names ........................................................................................................ 241
DATE Examples ....................................................................................................................... 242
Code Variable Parameters ....................................................................................................... 242
Jobflow Illustrator .................................................................................................................................... 245
Workflow Building Process ................................................................................................................ 246
Connections ...................................................................................................................................... 246
Building Parameters (PARMDEF DD Statement) ............................................................................. 247
Global Building Parameters ..................................................................................................... 247
Search Building Parameters .................................................................................................... 250
Filter Building Parameters ........................................................................................................ 252
Commands (SYSIN DD Statement) .................................................................................................. 254
Ad Hoc Commands .................................................................................................................. 255
System Command .................................................................................................................... 255
Output Command ..................................................................................................................... 255
Command Coding Rules .......................................................................................................... 255
ADDJOB Command -- Add a Job ............................................................................................ 256
ADDDS Command -- Add a Data Set ...................................................................................... 257
DELJOB Command -- Delete a Job ......................................................................................... 259
Configuring 9
SAVE Command -- Write to the Checkpoint Data Set ............................................................. 261
FLOWCHART Command -- Generate a Jobflow Illustrator Workflow ...................................... 261
CSV Flowchart File Description ........................................................................................................ 269
Fields (Columns) ...................................................................................................................... 269
FLOWCHART TYPE=PRINT Description ......................................................................................... 274
Jobs .......................................................................................................................................... 274
Data Sets ................................................................................................................................. 275
Pointers .................................................................................................................................... 276
Dependencies .......................................................................................................................... 277
Connections ............................................................................................................................. 277
Implement Jobflow Illustrator ............................................................................................................ 278
Communication with CA 7 ........................................................................................................ 278
Sample User JCL ..................................................................................................................... 278
Input DD Statements ................................................................................................................ 279
Output DD Statements ............................................................................................................. 279
Dynamically Allocated DD Statements ..................................................................................... 280
Initialization Parameters (INITDEF DD Statement) ........................................................................... 280
TYPE Parameter ...................................................................................................................... 280
CA7 Parameter ........................................................................................................................ 281
LOGON Parameter .................................................................................................................. 281
CA7PASS Parameter ............................................................................................................... 281
SIZE Parameter ....................................................................................................................... 282
NODE Parameter ..................................................................................................................... 282
RECEIVER Parameter ............................................................................................................. 282
CKPTDDN Parameter .............................................................................................................. 283
Jobflow Illustrator JCL Examples ...................................................................................................... 283
Example 1: Cold Start .............................................................................................................. 283
Example 2: Checkpoint Start and CSV Flowchart .................................................................... 284
Example 3: Null Table Cold Start, Multiple Checkpoints .......................................................... 284
Example 4: Delete Job and Print Flowchart to DASD .............................................................. 285
Sample FLOWCHART TYPE=CSV File (Partial) .............................................................................. 286
Workflow Data Simulation Mode ....................................................................................................... 287
Ad Hoc Adds and Deletes ........................................................................................................ 287
Checkpoint Save and Start ...................................................................................................... 287
Flowchart Output ...................................................................................................................... 287
Jobflow Monitor ....................................................................................................................................... 288
Storage Considerations for Jobflow Monitor ..................................................................................... 288
Security Requirements for Jobflow Monitor ...................................................................................... 289
Configure CA ACF2 and Jobflow Monitor ................................................................................ 290
Configure CA Top Secret and Jobflow Monitor ........................................................................ 291
Configure IBM RACF and Jobflow Monitor .............................................................................. 293
Implement Jobflow Monitor ............................................................................................................... 295
Configuring 10
Minimum z/OS Requirements .................................................................................................. 296
CA7LOG CAIENF Event .......................................................................................................... 296
Sample JFM User JCL ............................................................................................................. 296
Monitoring Considerations ....................................................................................................... 296
Jobflow Monitor DD Statements ............................................................................................... 297
Initialization Parameters for Jobflow Monitor .................................................................................... 298
Address Space Statements ...................................................................................................... 299
MONITOR Statement ............................................................................................................... 302
PORT Statement ...................................................................................................................... 303
Operator Command for Jobflow Monitor ........................................................................................... 304
Start Jobflow Monitor ............................................................................................................... 304
Stop Jobflow Monitor ................................................................................................................ 304
Issue a Command to a Jobflow Monitor Instance .................................................................... 305
Forecasting and Monitoring with Jobflow Monitor ............................................................................. 311
CPM Processing ............................................................................................................................... 312
Encrypted Communications and JFM ............................................................................................... 313
Implement Support for SSL Transmission ............................................................................... 313
Set Up to Use System SSL ...................................................................................................... 318
Implement Support for AT-TLS Transmission .......................................................................... 319
iDash and the CA 7 Server ...................................................................................................................... 319
Monitoring and Streaming ................................................................................................................. 320
Implement CA 7 Server for iDash ..................................................................................................... 321
Minimum z/OS Requirements .................................................................................................. 321
CA7LOG Event ........................................................................................................................ 321
Sample User JCL ..................................................................................................................... 323
Input DD Statements ................................................................................................................ 323
Output DD Statements ............................................................................................................. 323
Optional SYSTCPD DD Statement .......................................................................................... 323
Initialization Parameters (CA 7 Server for iDash) ............................................................................. 324
Address Space Statements (CA 7 Server for iDash) ............................................................... 324
Event Configuration Options (CA 7 Server for iDash) .............................................................. 327
MONITOR Statement (CA 7 Server for iDash) ........................................................................ 329
PORT Statement (CA 7 Server for iDash) ............................................................................... 330
Operator Commands (CA 7 Server for iDash) .................................................................................. 330
Storage Considerations (CA 7 Server for iDash) .............................................................................. 336
Security Requirements (CA 7 Server for iDash) ............................................................................... 337
Configure CA ACF2 Security ................................................................................................... 338
Configure CA Top Secret Security ........................................................................................... 339
Configure IBM RACF Security ................................................................................................. 340
Encrypted Communications .............................................................................................................. 343
Implement Support for SSL Transmission for CA 7 Server for iDash ...................................... 343
Set Up to Use System SSL for CA 7 Server for iDash ............................................................. 348
Configuring 11
Implement Support for AT-TLS Transmission - iDash ............................................................. 348
CA7TOUNI Conversion Utility ................................................................................................................. 349
Execute PHASE I of the Conversion Utility ....................................................................................... 350
Phase I Steps ........................................................................................................................... 350
Examples of SASSX2UN SYSIN Statements .......................................................................... 351
PHASE I Input JCL Statements ............................................................................................... 352
PHASE I Output JCL Statements ............................................................................................. 354
Execute PHASE II of the Conversion Utility ...................................................................................... 357
Execute the CONVERT Command Online ............................................................................... 357
Restore a Converted Member .................................................................................................. 358
Clean-Up after a Conversion ............................................................................................................. 358
CA7TOUNI Error Messages .............................................................................................................. 358
CA7TOUNI Informational Messages ................................................................................................. 363
CA7TOUNI Warning Messages ........................................................................................................ 364
Pre-Conversion Utility ....................................................................................................................... 365
CA7TOUNI Input Parameters .................................................................................................. 366
CA7TOUNI Input JCL Statements ........................................................................................... 366
CA7TOUNI Output JCL Statements ......................................................................................... 366
SASSX2PD Return Codes ....................................................................................................... 368
Pre-Conversion Utility Messages ............................................................................................. 369
CA7TOUNI Batch Program ..................................................................................................................... 375
Submit CA7TOUNI ............................................................................................................................ 376
Manage XTRK as an STC or Job ............................................................................................................ 381
Cross-Platform Tracking JCL ............................................................................................................ 381
XPS Client Implementation Checklist ................................................................................................ 383
Manage XTRK under ICOM .................................................................................................................... 384
Cross-Platform Tracking ICOM PARM Values .................................................................................. 384
Cross-Platform Tracking ICOM DD Statements ................................................................................ 385
Cross-Platform Tracking ICOM WTOR/MODIFY Replies ................................................................. 386
XPJOB Conversion Utility ........................................................................................................................ 387
Run the XPJOB ................................................................................................................................. 387
Back Up and Extract XPJOB List ............................................................................................. 389
Generate XPJOBs to AGJOBs BTI Files ................................................................................. 389
Process the Conversion BTI File .............................................................................................. 395
Generate Agent User-ID/Password Records ........................................................................... 397
Clean Up XPJOB ..................................................................................................................... 399
XPJOB Conversion Messages (AL2AGJC1 Job) .............................................................................. 400
XPJOB Conversion WTO Messages ....................................................................................... 401
XPJOB Conversion Informational Messages ........................................................................... 406
XPJOB Conversion Warning Messages .................................................................................. 407
XPJOB Conversion Error Messages ........................................................................................ 408
Configuring 12
Programming ........................................................................................... 416

System Operations .................................................................................................................................. 416
System Structure ............................................................................................................................... 416
Central Control System ............................................................................................................ 417
ICOM Functions ....................................................................................................................... 419
SVC and SMF Exits ................................................................................................................. 420
Network Communications Facility (NCF) ................................................................................. 420
Internal Cross-Platform Jobs .................................................................................................... 420
Jobflow Monitor (JFM) .............................................................................................................. 421
CA 7 Server for iDash .............................................................................................................. 421
Workload Definitions and Active Workload ....................................................................................... 421
Workload Definitions ................................................................................................................ 421
Active Workload ....................................................................................................................... 422
JCL and Parameter Libraries ............................................................................................................ 423
Database Verification Utility .............................................................................................................. 423
Backup/Reload .................................................................................................................................. 423
Work Queues .................................................................................................................................... 423
Active Workload Flow Phases ........................................................................................................... 424
Other Data Sets ................................................................................................................................ 427
Terminal Communications ................................................................................................................. 427
Batch Access ........................................................................................................................... 427
BSAM Terminal (Browse Data Set) .......................................................................................... 428
CA 7 Web Client User Interface ............................................................................................... 429
Logical Terminals ..................................................................................................................... 429
Online Access .......................................................................................................................... 429
Set up the Execution Environment .......................................................................................................... 430
Initialize CAIRIM ................................................................................................................................ 430
The System Environment ......................................................................................................... 431
Differences Between Instances ................................................................................................ 432
Manage the System Environment with CAIRIM ....................................................................... 433
The System Configuration File ................................................................................................. 433
Examples of Configuring the System Environment .................................................................. 445
CAIENF Events ................................................................................................................................. 451
Browse Messages Using CAIENF ........................................................................................... 451
Job Completions Using CAIENF .............................................................................................. 451
Log Records Using CAIENF .................................................................................................... 452
External Tracking and Filtering ......................................................................................................... 452
Track External Tasks ............................................................................................................... 452
Track External Data Sets ......................................................................................................... 458
Configuring 13
SMF Type 14/15/64 Record Filter - SASSXU83 ...................................................................... 460
Pattern Masking Characters ..................................................................................................... 462
Execute and Initialize ICOM .............................................................................................................. 463
ICOM Usage Considerations ................................................................................................... 463
Initialize ICOM .......................................................................................................................... 464
ICOM Execution PARM Values and DDNames ....................................................................... 464
ICOM WTOR/MODIFY Replies ................................................................................................ 468
Resource Affinity Scheduling with ICOM ................................................................................. 472
CA 7 Startup Procedures .................................................................................................................. 472
Date and Time Validation Option ............................................................................................. 473
Log Usage ................................................................................................................................ 474
Batch Job Compared to Started Task ...................................................................................... 475
Manage CA 7 .................................................................................................................................... 475
PARM Values ........................................................................................................................... 475
Startup Options ........................................................................................................................ 476
DBPARMS Parameter File ....................................................................................................... 480
Online Execution ...................................................................................................................... 481
Batch Execution ....................................................................................................................... 484
Dormant Copy .......................................................................................................................... 485
Shutdown Procedures .............................................................................................................. 487
Manage the Initialization File ................................................................................................................... 487
Initialization File Statements Syntax Rules ....................................................................................... 488
Sample Statement Format ....................................................................................................... 488
Sample Statement Continuation Formats ................................................................................ 488
Initialization Files Statements and Keywords .................................................................................... 489
Verify the Initialization File Offline ..................................................................................................... 493
Batch Edit Execution ................................................................................................................ 493
ALOG1 Statement ............................................................................................................................. 494
ALOG2 Statement ............................................................................................................................. 495
APPLCTN Statement ........................................................................................................................ 495
CALBLK Statement ........................................................................................................................... 496
CALENDAR Statement ..................................................................................................................... 497
CANCEL Statement .......................................................................................................................... 498
CPU Statement ................................................................................................................................. 499
CUST Statement ............................................................................................................................... 500
DAIO Statement ................................................................................................................................ 501
DBASE Statement ............................................................................................................................. 502
DRCLASS Statement ........................................................................................................................ 505
DRMODE Statement ......................................................................................................................... 505
EMAIL Statement .............................................................................................................................. 506
END Statement ................................................................................................................................. 508
FMTBLK Statement ........................................................................................................................... 508
Configuring 14
GROUP Statement ............................................................................................................................ 509
INIT2 Statement ................................................................................................................................ 512
INIT Statement .................................................................................................................................. 512
JCLCHECK Statement ...................................................................................................................... 516
JCL Statement .................................................................................................................................. 517
LINE Statement ................................................................................................................................. 520
NETMAN Statement .......................................................................................................................... 522
NEWS Statement .............................................................................................................................. 522
OPTIONS Statement ......................................................................................................................... 522
PFnn and PAnn Statements .............................................................................................................. 537
PFTERM Statement .......................................................................................................................... 538
RESIDENT Statement ....................................................................................................................... 539
RESTART Statement ........................................................................................................................ 541
SCHEDULE Statement ..................................................................................................................... 544
Schedule Scan Example .......................................................................................................... 547
SECURITY Statement ....................................................................................................................... 548
SERVICEDESK Statement ............................................................................................................... 558
SMF Statement ................................................................................................................................. 558
STATEMGR Statement ..................................................................................................................... 560
STATIONS Statement ....................................................................................................................... 560
STNCAL Statement ........................................................................................................................... 561
SVCNO Statement ............................................................................................................................ 562
TERM Statement ............................................................................................................................... 568
UCC7VTAM Statement ..................................................................................................................... 572
VRMOPTS Statement ....................................................................................................................... 574
XPDEF Statement ............................................................................................................................. 574
Calendars ................................................................................................................................................ 577
Batch-Generated Calendars ............................................................................................................. 578
Sample Base Calendar Assembly Listing ................................................................................ 578
CALENDAR Macro ................................................................................................................... 579
Coding Notes ........................................................................................................................... 581
Perpetual Calendars ......................................................................................................................... 582
Perpetual Calendar Requirements ........................................................................................... 583
Perpetual Calendar Criteria ...................................................................................................... 583
Perpetual Calendar Criteria Member Samples ........................................................................ 588
CA Datacom/AD Database Backup, Recovery, and Tuning ................................................................... 589
Backup Options ................................................................................................................................. 590
Stable Backup .......................................................................................................................... 590
Hot Backup ............................................................................................................................... 590
Reorganize Your Database ............................................................................................................... 591
Tune Your Database ......................................................................................................................... 592
Dynamic Extend ................................................................................................................................ 593
Configuring 15
Index Defragmentation ...................................................................................................................... 593
Logging ............................................................................................................................................. 594
LXX Spilling .............................................................................................................................. 594
LXX Sizing ................................................................................................................................ 595
Database Resizing ................................................................................................................... 595
Recover Unique Row Identifiers ........................................................................................................ 595
Execute a Forward Recovery ............................................................................................................ 596
Shadow MUF Feature ....................................................................................................................... 597
Implement the Shadow MUF .................................................................................................... 597
Shadow MUF and Dormant Copy ............................................................................................ 598
Recover an Unresponsive Terminal ........................................................................................................ 598
Recover VTAM Terminals ................................................................................................................. 598
Recover Batch Terminals .................................................................................................................. 600
Back up and Reload Agent Data ............................................................................................................. 600
Agent Data Backup Procedure - CA7AGBK ..................................................................................... 601
Agent Data Reload Procedure - CA7AGRL ...................................................................................... 601
Agent Data Reload Usage ................................................................................................................ 602
Agent Data Set IDCAMS Define Parameters .................................................................................... 602
Workload Recovery Considerations ........................................................................................................ 602
CA 7 Workload Recovery Considerations ......................................................................................... 603
Other CA Products ............................................................................................................................ 603
Other Vendor Software Products ...................................................................................................... 603
Workload Documentation Considerations ......................................................................................... 603
NCF Usage ....................................................................................................................................... 604
Magnetic Tape Considerations ......................................................................................................... 604
Recovery Aid ........................................................................................................................................... 604
Queue Milestones ............................................................................................................................. 605
Preserve the Log Data ...................................................................................................................... 606
Reports Generated ............................................................................................................................ 606
Request the Reports ......................................................................................................................... 607
Recovery Aid Procedures ................................................................................................................. 607
Disaster Recovery Mode ......................................................................................................................... 609
Disaster Recovery Classes ............................................................................................................... 610
Schedule Scan .................................................................................................................................. 610
Suppress Triggers During Disaster Recovery ................................................................................... 610
Job Requirements ............................................................................................................................. 611
End Disaster Recovery Mode ........................................................................................................... 611
Disaster Recovery Example .................................................................................................................... 612
Log Data Set Management ..................................................................................................................... 613
History Management Program - SASSHIS5 ............................................................................................ 614
SASSHIS5 File Descriptions ............................................................................................................. 617
Configuring 16
Condition Codes ................................................................................................................................ 617
SASSHIS5 Report Descriptions ........................................................................................................ 618
History Purge Program - SASSHIS6 ....................................................................................................... 620
SASSHIS6 File Descriptions ............................................................................................................. 622
Condition Codes ................................................................................................................................ 623
SASSHIS6 Report Descriptions ........................................................................................................ 623
Workload Balancing ................................................................................................................................ 624
Workload Balancing Without Enhanced Submission Selection ........................................................ 624
Workload Balancing With Enhanced Submission Selection ............................................................. 626
Workload Balancing Commands ....................................................................................................... 626
Define the Production Environment .................................................................................................. 627
Tape Drives .............................................................................................................................. 627
CPU Use .................................................................................................................................. 628
Initiators and Job Class Structure ............................................................................................ 629
Job Start Times ........................................................................................................................ 629
Threshold Priorities .................................................................................................................. 629
Implement WLB ................................................................................................................................. 630
Define the Selection Parameters ...................................................................................................... 632
Workload Balancing Questionnaire ................................................................................................... 632
Sample Workload Balancing Objectives Definition .................................................................. 634
Use CLBARR ........................................................................................................................... 635
Use CPU .................................................................................................................................. 636
Use INITR ................................................................................................................................ 636
Use STARTIME ........................................................................................................................ 637
Use TAPE1/TAPE2 .................................................................................................................. 637
Use WLBPDEF ........................................................................................................................ 638
Define Tape Drive Types .................................................................................................................. 639
Code WLB Macros ............................................................................................................................ 641
Coding Rules ............................................................................................................................ 641
CLBARR ................................................................................................................................... 642
CPU .......................................................................................................................................... 642
INITR ........................................................................................................................................ 643
STARTIME ............................................................................................................................... 645
TAPE1 ...................................................................................................................................... 646
TAPE2 ...................................................................................................................................... 647
WLBPDEF ................................................................................................................................ 649
WLBPEND ............................................................................................................................... 649
Generate WLB Definitions and Modules ........................................................................................... 649
Schedule WLB Modules .................................................................................................................... 650
UNIX System Services Interface Communications ................................................................................. 651
File Permissions for UNIX ................................................................................................................. 652
MSMR - Route Master Station (Browse) Messages ................................................................................ 652
Configuring 17
Implement MSMR .............................................................................................................................. 652
MSMR Control File Syntax ................................................................................................................ 653
TO Keyword ............................................................................................................................. 654
TXT Keyword ........................................................................................................................... 654
COLOR Keyword ..................................................................................................................... 655
ATTRIBUTE Keyword .............................................................................................................. 655
SEVERITY Keyword ................................................................................................................ 655
MSMR Control File Statement Examples .......................................................................................... 656
MSMR Messages List ....................................................................................................................... 657
XCF Group and Member Names ............................................................................................................. 659
CA WA CA 7 Edition XCF Names ..................................................................................................... 659
ICOM XCF Names ............................................................................................................................ 659
CAL2DBVR Utility .................................................................................................................................... 660
Database Verification Parameters ..................................................................................................... 661
Interpret DBVR Output ...................................................................................................................... 663
CAL2ENVR Utility .................................................................................................................................... 664
CAL2ENVR Example ........................................................................................................................ 664
CAL2SC80 Utility ..................................................................................................................................... 669
L2JFMIGR Utility ..................................................................................................................................... 669
SASS Utilities .......................................................................................................................................... 670
SASSCDSI Utility .............................................................................................................................. 670
SASSXDSI Utility .............................................................................................................................. 671
SASSXKPI Utility ............................................................................................................................... 672
SASSZXTV Utility .............................................................................................................................. 672
User Exits and Modifications ................................................................................................................... 673
User Modifications Under SMP/E ...................................................................................................... 673
Code User Exits ................................................................................................................................ 673
Rules for Coding Online Exits .................................................................................................. 675
Register Descriptions for Online Exits ...................................................................................... 675
Rules for Coding Standard Exits .............................................................................................. 676
Test User Exits ......................................................................................................................... 676
Online Exit Descriptions .................................................................................................................... 677
Agent Job Submission - SASSXX22 ........................................................................................ 677
Browse Message - SASSXX17 ................................................................................................ 678
Command Exit - SASSXX09 .................................................................................................... 679
Console Terminal Output - SASSXX15 .................................................................................... 680
Database Load Processing - SASSXX12 ................................................................................ 680
ENQ/RESERVE - SASSXX04 .................................................................................................. 681
External DSN Access - SASSXX07 ......................................................................................... 681
Forecast Worksheet - SASSXX08 ........................................................................................... 683
JCL Attach Verification - SASSXX11 ....................................................................................... 684
JCL Submission - SASSXX02 .................................................................................................. 685
Configuring 18
Job Data Verification - SASSXX10 .......................................................................................... 686
Job Name Verification - SASSXX01 ........................................................................................ 688
Logoff Exit - SASSXXFF .......................................................................................................... 689
Logon/Password Verification - SASSXXLX .............................................................................. 690
Personal Scheduling Verification - SASSXX14 ........................................................................ 691
Queue Entry JCL - SASSXX05 ................................................................................................ 693
SMF Feedback - SASSXX13 ................................................................................................... 694
SMF WTO Message (SASSXX16) ........................................................................................... 696
Statement Modification Exit for CPU Job Submission - SASSXX20 ........................................ 697
Utility Function Security Checking - SASSXX03 ...................................................................... 698
XPJOB Submission - SASSXX21 ............................................................................................ 700
Standard Exit Descriptions ................................................................................................................ 702
Database Load Processing (SASSXX12) ................................................................................ 702
Problem Management Interface Exit ........................................................................................ 704
APA Graph Modifications .................................................................................................................. 705
Change Graph Definitions ........................................................................................................ 705
Add Counters for New Graphs ................................................................................................. 708
Other System Modification Techniques ............................................................................................ 709
Batch Interface Message Table - SASSXXBT ......................................................................... 709
Generic Unit Name/Device Type Table - SASSUTBL .............................................................. 711
Suppress Messages - SASSMSGS ......................................................................................... 712
CA Driver Customization - CA7AGENB ................................................................................... 712
Reserved DDname Table - SASSPMDD ................................................................................. 712
EBCDIC/ASCII Translation Tables - CAL2XLAT ..................................................................... 713
Function Aliases for Formatted Panels .................................................................................... 713
Performance and Tuning ......................................................................................................................... 715
Monitor Performance ......................................................................................................................... 715
Automated Performance Analysis (APA) ................................................................................. 715
CA Earl Reports ....................................................................................................................... 716
History Reporting and Performance ......................................................................................... 716
/DISPLAY Command and Performance ................................................................................... 717
Initialization File Considerations ........................................................................................................ 717
Schedule Scan Parameters ..................................................................................................... 717
Queue IOB Count ..................................................................................................................... 717
Application Pool Sizes .............................................................................................................. 718
Terminal Dispatching Priority ................................................................................................... 718
Calendar Schedules .......................................................................................................................... 719
Operating System Considerations .................................................................................................... 719
Nonswappable ......................................................................................................................... 719
Dispatching Priority .................................................................................................................. 719
Database Placement Considerations ................................................................................................ 719
Data Set Placement Recommendations and Restrictions ................................................................. 720
Configuring 19
Communications Data Set ....................................................................................................... 720
Load Library ............................................................................................................................. 721
Placement of Data Sets ........................................................................................................... 721
SMF Processing ................................................................................................................................ 721
Data Set Placement Recommendations ........................................................................................... 722
Configuring 20
Configuring
To see all the articles in this area, log in by clicking Sign In near the upper-right corner and
log in using your CA Support Online credentials.
Documentation in the Interfaces area provides information about the interfaces and options of the
product. The documentation in the Programming area provides information that is aimed at systems
programmers. The articles are related to planning, installing, and maintaining the product.
Use the left navigation pane to view detailed information about configuring and programming.
Configuration Best Practices (see page 22)
Customization Best Practices (see page 27)
Interfaces (see page 37)
Programming (see page 416)
08-Feb-2018 21/722
Configuration Best Practices

CA Workload Automation CA 7® Edition presents significant opportunities for configuration to meet
the needs of your environment and users. To optimize the product usage at your site, use the
following best practices.
Review the IBM Workload Manager (WLM) Service

Class
We strongly suggest that you make the following equal to or no more than one service class below
JES:
CA7ONL
ICOM
CA Datacom/AD Multi-User Facility (MUF) used by CA Workload Automation CA 7® Edition
CA Workload Automation Restart Option for z/OS Schedulers when used
The timely submission of jobs to the internal reader is probably the most important role of CA
Workload Automation CA 7 Edition in your environment. After the implementation of z/OS 1.7, most
internal reader processing is done in the address space allocating the reader. An address space that is
not optimally qualified in the WLM Service Policy does not always get access to the processor for
timely job submission.
Business Value:
This practice ensures better CA7ONL performance and more efficient, quicker job submission.
Update JES MAS Tuning

Consider updating the MASDEF specifications for Hold and Dormancy.
In a JESplex, the JES system running within a sysplex, each LPAR is known as a member. For a JESplex,
the SPOOL and JES Checkpoint data sets are shared among the members, which are known as the
Multi-Access Spool (MAS). Only one member of the MAS can hold the checkpoint at one time.
If a MAS member holds the checkpoint too long, accessing the JES2 checkpoint can cause problems.
This situation sometimes slows the CA Workload Automation CA 7® Edition job submission process.
See the JES2 Availability and Performance Redbook. That guide helps you determine the correct
specifications that are based on the number of members in the MAS and their activity. The member
with the CA7ONL address space (that is, the one submitting the jobs) must have a higher Hold value
than the other members. The systems with less JES2 activity can benefit by adjusting the MINDORM
and MAXDORM values.
08-Feb-2018 22/722
Business Value:
This practice ensures more efficient, quicker job submission.
Use XCF for SMF Record Notification

Change your initialization so that CA7ONL and ICOM join an XCF group.
CA Workload Automation CA 7® Edition tracks the progress of jobs on the operating system using
SMF for z/OS work and pseudo SMF for cross-platform work. Records are generated for the job start,
step end, data set create, and job end. ICOM is the facility that picks up the feedback and
communicates it to CA7ONL. Before r11.3, all ICOMs wrote SMF feedback to the communications
data set.
The SMF initialization file statement has a keyword of SMFXCF= with the default of NO. As a best
practice, specify YES and CA7ONL joins an XCF group. The group name defaults to the instance name
or can be specified on the SMFXCF keyword.
For ICOM, the PARM, XCF, determines whether ICOM uses XCF to notify CA7ONL that the SMF
records are ready to process. The default is XCF=NO. As a best practice, specify NOTIFY to indicate
that ICOM joins an XCF group. To specify a group name other than th e default, add the keyword
XCFGRP=grpname.
If XCF=NOTIFY is used for ICOM, XCF is not used for the SMF feedback process, but XCF notifies CA
Workload Automation CA 7 Edition when SMF data is written to the COMMDS. If the LPAR that runs
this ICOM does not have much activity, this setting can make SMF feedback processing quicker.
You can run ICOMs using this feature simultaneously with other ICOMs are running without this
feature, communicating to the same CA Workload Automation CA 7 Edition.
Business Value:
This practice ensures more efficient tracking of work in CA7ONL.
Perform File Maintenance

Keep the CA Workload Automation CA 7® Edition files reorganized, sized, and placed correctly.
The size and location of CA Workload Automation CA 7 Edition files impact product performance. The
files can benefit from the fiber attachment, DASD Fast Write, and the caching attribute on storage
devices. Do not place CA Workload Automation CA 7 Edition files on the DASD volumes with other
high-activity product files.
The browse data set usually has a ddname in CA7ONL of BROWSE. The browse data set is a
sequential file that contains messages that CA7ONL produces. The messages are buffered according
to the block size before they are written to the file. Use a larger block size to decrease the number of
writes to the file, which can improve the overall performance. If you have periods of inactivity in
CA7ONL, the browse messages are not written in a timely manner because the buffer must fill before
the writing. To force the writing of the block to the browse file, log in to CA7ONL. Issue the /MSG,
08-Feb-2018 23/722
the writing. To force the writing of the block to the browse file, log in to CA7ONL. Issue the /MSG,
LT=MASTER,M=message enough times to fill the buffer. If you had a buffer size of 800, you would
have to issue this 10 times to write the block to the browse file. Because typically CA7ONL is
continuously busy, this activity is not an issue.
The communications data set, which has a ddname of UCC7CMDS, is the focal point of
communication between CA7ONL and ICOM. The tracking information that the system collects is sent
to CA7ONL by ICOM through the communications data set. The XCF option is available to pass SMF
data from system to system instead of writing to the communications data set. This option can
alleviate the major source of contention. Any trailer or U7SVC commands are also fed to CA7ONL
through this file. In multi-CPU environments, it is imperative for performance that this file is on a low-
accessed volume. This file is the only CA Workload Automation CA 7 Edition file that has explicit
reserves that are done on it for synchronization.
Business Value:
The correct placement, use, and definition of files promotes better performance of CA7ONL.
Reconsider JCL Files

Use procedures instead of inline JCL for performance purposes.
CA Workload Automation CA 7® Edition places a copy of execution JCL for job submission in the
trailer queue when a job comes into the request queue for processing. PDS access can be degraded
with large numbers of members within the file for either or both of the following reasons:
If you have some contention for the JCL file
If JCL files need compressing
Using PDSMAN or any other PDS performance product can help by placing the PDS directory in
storage. Also, a large JCL member can take longer to submit.
Business Value:
Your jobs enter the CA7ONL request queue faster.
Understand LOAD Processing

Schedule a batch job to issue top line LOAD commands at nonpeak processing periods and only LOAD
a few jobs at a time.
The first time that CA Workload Automation CA 7® Edition submits a job or if the RELOAD option is Y
on the DB.1 panel, a LOAD step is inserted and executes with the JCL. The LOAD step causes the
defining to the database of the step, DD, and data set information within the JCL of the job. The
execution of many LOAD steps can affect system performance and overall CA7ONL performance.
08-Feb-2018 24/722
If you do not use the data set information from the database, you can turn off the adding of data set
information. Use the LOADDSNS keyword on the DBASE statement in the initialization file. You can
also set a job to never reload by placing an X in the RELOAD field on the DB.1 panel.
Note: XPJOBs and AGJOBs do not use LOAD processing because no data sets are created on
the z/OS system.
Business Value:
This practice produces quicker, more efficient processing of batch work.
Evaluate Schedule Scan Options

Using shorter spans means fewer jobs coming into the queues during a scan, which can improve
performance.
Schedule scan runs on a timer basis, bringing jobs into the queues for a specified time frame. The
SCNINCR and QDWELL values from the SCHEDULE statement in the initialization file are added. They
determine the timespan that is scanned at each wakeup.
Schedule scan also drives prompting. During a prompt cycle, messages are written to the browse data
set regarding late jobs or jobs in restart status. For performance purposes, set the SCHEDULE
statement REPROMPT keyword to one hour, or turn it off with REPROMPT=0.
Jobs go into RETRY status in the request queue because a dynamic allocation error occurs accessing
the file that contains the JCL for the job.
When a nonzero value for the RETRY keyword on the SCHEDULE statement is coded, the product tries
to reattach the JCL from the library.
Use a longer RETRY value for performance purposes.
The XPRETRY keyword lets XPJOBs automatically retry a submission when the node or alternate node
is in an offline, stopped, or failed state.
Business Value:
This practice ensures more efficient job processing in CA7ONL and less work in the queues to
monitor.
Exclude Some Data Set SMF Feedback

You can selectively exclude specific SMF 15 record processing for data sets that CA7ONL or any job
that it submits does not use.
CA Workload Automation CA 7® Edition collects various SMF records. Job initiation and job
08-Feb-2018 25/722
CA Workload Automation CA 7® Edition collects various SMF records. Job initiation and job
completion records are collected to determine when a job starts and ends. Data set creation records
are also collected to satisfy data set requirements and for data set triggers. The collection and
processing of the SMF 15 data set creation/update records is sometimes resource-intensive. Use the
SASSXU83 exit to exclude specific data sets (not pick up or process the SMF 15 data for the specified
data sets). If you do not use data set triggers or data set requirements within CA Workload
Automation CA 7 Edition, you can turn off collection of the SMF type 15 records during the CAIRIM
initialization.
Business Value:
This practice ensures more efficient use of SMF feedback for data sets.
More Information:
For more information, see SMF Type 14/15/64 Record Filter - SASSXU83 (see page 460).
Parallel Submission Processing

Use PSP=YES in the OPTIONS statement of the initialization file.
Parallel Submission Processing (PSP) lets CA Workload Automation CA 7® Edition open more than one
JES Internal Reader simultaneously to submit the work to JES. This processing is activated using the
OPTION,PSP=Y specification. The number of subtasks defaults to 5. The MAXSUBOUT parameter on
the OPTIONS statement can specify from 1 to 15. This setting indicates the number of jobs that CA
Workload Automation CA 7 Edition can submit simultaneously.
Business Value:
Faster job submission to JES improves the job throughput through the CA Workload Automation CA 7
Edition system.
08-Feb-2018 26/722
Customization Best Practices

The installation macros cause various specifications to occur (such as file space and names, JCL library
designations, number of terminals). After the installation, you can change any of the items that the
install macros configure.
Add Batch Terminals

Have at least one set of larger batch data sets to use for commands such as RESOLV or generic
listings. These commands can produce much output.
You can have up to eight batch terminal definitions. If you currently do not have eight defined, you
can add batch terminals. Update the initialization file and the CA7ONL procedure. The Batch Terminal
Interface (BTI) input and output data sets are pointed to in CA7ONL. Each data set has a ddname that
matches the GROUP name in the initialization file. The first seven characters of these ddnames must
match the initialization file GROUP statement NAME parameter. The last (eighth) character is either
an I or O indicating either an input or output data set. In the initialization file, each batch terminal
data set pair is defined as a batch terminal by having its own GROUP, LINE, TERM, and STATIONS
statement. BTI input files are known as BATCHIN and output files as BATCHOUT. The LINE statement
for each batch terminal must have the BUFSIZE keyword match the block size (BLKSIZE) of the
BATCHIN file.
The PARM on the execution of SASSBSTR (program that is executed for BTI) determines the number
of the batch terminal (and corresponding BATCHIN and BATCHOUT data sets) that are used. This
number corresponds to the order of the batch terminal definitions in the initialization file. If 0 is used
in the PARM, you are using dynamic allocation of the BTI terminals and BATCHIN and BATCHOUT.
Changing terminal definitions requires a specified ERST type start of CA7ONL.
Business Value:
This change results in faster processing of batch terminal input commands and fewer BATCH
TERMINAL IN USE messages.
Add CAICCI Terminals

Many different types of access to CA7ONL use CAICCI terminals. Adding CAICCI terminals as this
access grows is sometimes necessary. If you need more CAICCI terminals, update the initialization
file. Add a GROUP, LINE, TERM, and STATIONS statement for each added terminal as follows:
GROUP,NAME=CCIGRP2,DEVICE=CCI,LNAME=CCILN2
LINE,NAME=CCILN2,BUFSIZE=3120,TNAME=CCIT2
TERM,NAME=CCIT2,DEVICE=CCI,NLINE=60,LINLEN=137,CONS=ALTRN
*
GROUP,NAME=CCIGRP3,DEVICE=CCI,LNAME=CCILN3
LINE,NAME=CCILN3,BUFSIZE=3120,TNAME=CCIT3
TERM,NAME=CCIT3,DEVICE=CCI,NLINE=60,LINLEN=137,CONS=ALTRN
.......
STATIONS,TRMID=CCIT2,STANIDS=(CCI2)
08-Feb-2018 27/722
These statements are positional. Add the GROUP, LINE, and TERM statements after the existing ones
for CAICCI terminals. Add the STATIONS statements after the SECURITY statement (grouped with the
other STATIONS statements).
Note: Make the total number of CAICCI terminals defined the number of required CAICCI
terminals plus the number of required TCP/IP terminals. If either is heavily used, define at
least 20 CAICCI terminals.
Business Value:
This best practice results in quicker processing of CAICCI terminal input commands.
Add JCL Libraries

For performance purposes, consider using more JCL libraries with fewer members in each library.
During installation, JCL files are defined to CA7ONL in the initialization file with JCL statements. Add
or remove the JCL statements as needed by making the initialization file changes and shutting down
and restarting CA7ONL.
To add dynamically a JCL library without bouncing CA7ONL, use the following top line command:
/JCL,OPT=ADD,INDEX=indexc,DSN=your.jcl.library
The INDEX keyword defines the symbolic index that is associated with the JCL statement. A symbolic
index is referred to as a JCLLIB on the DB.1 panel. A symbolic index consists of an ampersand (&)
followed by up to 15 alphanumeric characters.
You can also define the JCL library as an alternate library to an existing JCL library. Use the ALT= xxx
keyword. The xxx defines the INDEX value from a previously defined JCL library that is searched
before this library.
/JCL,OPT=ADD,INDEX=indexc,DSN=your.jcl.library,ALT=001
After you define a JCL library dynamically, an index value of 255 is assigned. You can display all the
JCL libraries that are defined to CA7ONL including the dynamically added libraries. Issue the following
top line command:
/DISPLAY,ST=JCLVAR
You also can delete or update the current dynamically allocated library using the /JCL command.
Remember, this library is a dynamically added library. If you restart CA7ONL, the JCL library is only
defined when you specify JCLDEFS=VSAM on the RESIDENT statement.
Business Value:
08-Feb-2018 28/722
This best practice ensures flexibility in JCL library use.
Add TCP/IP Terminals

Many different types of access to CA7ONL use TCP/IP terminals. TCP/IP terminals are defined in the
same way as CAICCI terminals. No distinction exists between the two in the initialization file. Follow
the same directions as for adding CAICCI terminals.
Define the total number of CAICCI terminals that are defined as the number of required CAICCI
terminals plus the number of required TCP/IP terminals. If either is heavily used, define at least 20
CAICCI terminals.
To activate the TCP/IP terminal interface, code the TCPTPORT parameter on the initialization file
UCC7VTAM statement. Set TCPTPORT to define the TCP/IP port on which CA7ONL listens for
messages that are sent to CA Workload Automation CA 7® Edition. The TCPTMOUT parameter
specifies the number of seconds before the TCP/IP terminal session times out. The default is 10
seconds.
Business Value:
This best practice results in quicker processing of TCP/IP terminals.
Add VTAM Terminals

This article explains how to add VTAM terminals.
As you give new users access to CA7ONL, you sometimes must add terminals. If you require more
terminals in CA7ONL, update the initialization file.
If you have used our defaults, change the VTM#nnn on the LINE and TERM statements. The nnn is
the number of terminals available. After this change, perform a specified ERST type start.
If you have not used the defaults for virtual terminal naming, you have a VTNAME= xxx on the
UCC7VTAM statement. Change the LINE and TERM statement with xxx#nnn. Change the nnn to
the number of terminals that are available online.
If you use the ISPF interface and you want more terminals available to it, change the CA7CLIST
SESSAPL keyword. You can use SESSAPL(TSO9999) to enable the use of all available virtual
terminals in the ISPF interface.
Business Value:
More personnel can require more terminal definitions.
08-Feb-2018 29/722
Implement or Delete Submit Data Sets

If you do not have a JES shared spool and you have more than one LPAR where CA7ONL submits jobs,
add submit data sets.
In a JES shared spool environment, CA7ONL submits jobs to the internal reader on the LPAR where it
is running. JES decides where the job executes. We do not recommend that ICOM submit in this
environment for the following reasons:
JES decides the LPAR where the job actually executes.
Performance issues can occur with the overhead of opening and reading files between systems.
To route jobs to specific LPARs in a JES shared spool environment, use the route execute statements
(or /*JOBPARM SYSAFF=).
If you do not have a shared JES environment, you can use ICOM to submit jobs on LPARS other than
the one running CA7ONL. CA Workload Automation CA 7® Edition uses submit data sets to let ICOM
do job submission. A submit data set is a physical sequential file that contains 80-byte records and
resides on DASD that is shared among systems. If you decide to use submit data sets, initialize the
communications data set (ddname UCC7CMDS) with the submit data sets ddnames. The ddname is
required to be UCC7SUBx (the x is a number from 1 to 7). The ddname corresponds to a DD
statement in CA7ONL and ICOM. Setting the DD PARM data for ICOM to the number on its submit
data set DD statement enables ICOM to do job submission. CA7ONL knows which submit data set to
write the JCL of a job to by the designation of MAINID on the DB.1 panel with a SY x value. The SYx is
also defined in the initialization file on a CPU statement. When it is time to submit a job, the JCL is
written to the designated submit data set. ICOM picks up the JCL from the submit data set. ICOM
writes it to the internal reader on the LPAR where it is running. JES takes over from there.
You can remove the submit data sets and have CA7ONL submit the jobs (instead of ICOM). Change
the initialization file, CA7ONL, and ICOM. In the initialization file, remove the CPU statement that has
the DDNAME=xxxxxxxx (where xxxxxxxx is the ddname of the submit data set in CA7ONL). Remove
the DD in CA7ONL and ICOM, and change the ICOM PARM DDNAME= to *NONE*. Shut down or stop
CA7ONL, ICOM, or both, and restart to get the changes into effect. Only stop or start the ICOM task
that referred to the removed submit data set.
Business Value:
You can submit jobs to an LPAR where the CA7ONL is not running (only ICOM) when no JES is shared
between the LPARs.
Implement Workload Balancing (WLB)

Use the Workload Balancing (WLB) feature that is designed to select the best mix of jobs to submit to
the host system to meet defined objectives. WLB has numerous benefits including the class barriers
(CA Workload Automation CA 7® Edition class, not JES), tape drive usage (if a CPU job), and the
prioritized submission of jobs.
08-Feb-2018 30/722
Start by defining what you want Workload Balancing to do. Do you want it to control tape drives? Do
you want it to control the number of jobs that are submitted by class? Do you want it to control the
submission of jobs by a user-defined priority? Workload Balancing (see page 624) contains a table
that discusses the steps for implementing Workload Balancing. Read this entire topic thoroughly to
determine whether Workload Balancing can help you reach your job submission objectives. After you
have set the goals, you are ready to do some preliminary tasks.
Answer the Workload Balancing Questionnaire provided in that topic. The answers to this
questionnaire you establish and define your Workload Balancing goals. If you do not use Workload
Balancing for tape drives or initiators, code the corresponding macros anyway. The TAPE1, TAPE2,
and INITR macros have defaults that can stop the submission of jobs. For example: You want to use
only the class barrier feature of Workload Balancing. Code the TAPE1 macro with the highest
permitted value for 'total available.' If you do not code the TAPE1 macro, the total available tape
drives default to zero. Jobs using a tape device are not submitted.
After you have coded the macros and assembled and link edited the Workload Balancing module, you
have a load module named UCC7Rxxx. The xxx is the MODNAME value from the WLBPDEF macro.
After adding the module as a job on the DB.1 panel (job name UCC7R xxx), you can schedule this job
the same as any job. Consider scheduling different Workload Balancing modules to be in effect at
different times of the day or after certain processes complete. When the job UCC7R xxx goes to the
ready queue, the Workload Balancing module by that name is loaded and the UCC7R xxx job flushes
from the queues (like a nonexecutable job). (Obviously, UCC7R is a special job name prefix that can
only be used for Workload Balancing modules.)
Once a Workload Balancing module is created, the values for that module can be viewed, modified,
or both with online commands. The LWLB command lets you list the values for a specific Workload
Balancing module. The XWLB command lets you modify the values of the current Workload Balancing
module. A /WLB command can be issued using the Batch Terminal Interface, U7SVC, or the trailer
step to modify the current Workload Balancing module from JCL or user-written programs. You can
modify the Workload Balancing associated values of an individual job in the following ways:
Permanently on the DB.1 panel for number of tape drives used and CA Workload Automation CA
7® Edition job class.
The XUPD command for a one-time change after the job is scheduled to run (currently in the
queue).
A #RES statement in the JCL of a job to change the resource values of the job.
Workload Balancing affects jobs waiting submission in the ready queue. Before you implement
Workload Balancing, jobs usually remained in the ready queue only long enough to be submitted and
initiated unless they were held by a virtual resource. After you turn on Workload Balancing, some
jobs can stay in the ready queue longer. To determine the status of a job in the ready queue, look at
the output from an LQ command. For jobs in the ready queue, a date and time in the column with the
SUB/START heading is the time that the job was submitted to JES. If you see *NONE* in this field, the
job is not yet submitted. To view the nonsubmittal reason, issue the following command:
LRDYP,JOB=jobname/job#,LIST=STATUS
08-Feb-2018 31/722
Once the module is loaded and in effect, it is too late to discover that you set some options
incorrectly. You can test your Workload Balancing modules with Workload Planning. Workload
Planning is a modeling process that can test what-if scenarios. You can run Workload Planning with
the default Workload Balancing module. Next, run Workload Planning with the module that you want
to test to see how the new module affects processing.
Business Value:
This best practice ensures more efficient processing of batch work.
Maintain the CA7AGNT VSAM File

Use the provided procedures to back up and restore the agent database file (ddname CA7AGNT).
JCLLIB members CA07N513 and CA07N514 contain samples of the execution of these procedures.
Alternately, use IDCAMS REPRO to move or reallocate this database file.
The CA7AGNT file contains agent job data from executed jobs. Remove these entries using the
/DELAGENT command in CA 7. The removal of old entries prevents the file from expanding too large.
The agent purges the job-related data periodically, so there is no need to keep the data in the
CA7AGNT file.
If you use the agent job interface, you can also back up and can move the CA IAS checkpoint file. Use
the CA IAS CIASJCL members IASCKPBK (backup) and IASCKPRL (reload). These members use the
IDCAMS REPRO utility.
If you must maintain the password, CIASJCL member IASCKPRP uses a utility. The utility extracts any
passwords from the backed-up file. The utility reloads only those entries instead of all agent and
message entries. Use this process when any problems exist on the CA IAS checkpoint file.
Business Value:
This best practice results in less down time when reallocating files.
More information:
For more information, see CA WA CA 7 Edition File (https://docops.ca.com/display/CA712

/CA+WA+CA+7+Edition+File).
Move or Reallocate Batch Terminal Files

To move or reallocate batch terminal input (BATCHI#n) files, output (BATCHO#n) files, or both, shut
down CA7ONL. Perform the move or reallocation. Next, restart CA7ONL with a specified ERST type
start.
Business Value:
08-Feb-2018 32/722
Move or Reallocate the Checkpoint and Queue

Files
Shut down to move or reallocate the checkpoint file or the SCRQ and DQTQ files when those files are
not allocated to a VIO (virtual input/output) device.
The queue files are pointed to in the CA7ONL procedure with the ddnames UCC7SCRQ and
UCC7DQTQ. Using VIO reduces the maintenance needs for these two files.
The checkpoint file is pointed to in the CA7ONL procedure with the ddname UCC7CKPT.
The queue files and the checkpoint file must reside on the same device type when not using VIO for
SCRQ and DQTQ.
Business Value:
Move or Reallocate the Communications Data Set

If you are moving the communications data set to a different device type or enlarging it, reallocate
and reformat. Do not use IEBGENER.
The communications data set is pointed to by the UCC7CMDS DD in CA7ONL and in ICOM. You must
have both down to reallocate or move the file. You can move the communications data set using
utility IEBGENER. As a best practice, if you are moving the communications data set to a different
device type or enlarging it, reallocate and reformat it. Do not copy using IEBGENER.
To reformat the communications data set, see member CA07N700 in JCLLIB.
If you are not copying the existing communications data set, stop job submission and let all active
jobs complete.
Business Value:
Move or Reallocate the Database Files

Back up, move, or reallocate the database files using the DBUTILITY supplied with CA Datacom/AD.
We recommend that you consult with CA Datacom/AD support when you have questions.
Back up the CA Datacom/AD database daily using a hot backup. Perform a full backup on a periodic
basis such as before a planned system outage. The CAL2JCL members AL2DBHOT and AL2DBKUP
provide samples for this backup process.
Moving or expanding the database again uses the DBUTLTY utility with different commands. For the
08-Feb-2018 33/722
Moving or expanding the database again uses the DBUTLTY utility with different commands. For the
best methods to move the database, see the CA Datacom documentation and contact CA Support.
Business Value:
Move or Reallocate the Log Files

This article explains how and why to move or reallocate the log files.
Shut down CA7ONL before running the log dump jobs.
The primary log file is pointed to by the UCC7LOG DD in the CA7ONL procedure and in the
initialization file on the ALOG1 statement. The secondary log file is named on the ALOG2 statement
and can be pointed to by the UCC7LOGS DD statement. These two files must reside on the same
volume. As a best practice, when moving these files, shut down CA7ONL and then run the log dump
jobs. When the log dump jobs are complete, you can then reallocate the log files. Next, perform an
ERST type start of CA7ONL.
Business Value:
Order for Starting Programs

We recommend the following starting order (after CA Common Services CAIRIM or CAS9 has
executed):
CA Datacom/AD MUF region
CA Workload Automation Restart Option for z/OS Schedulers (if using)
ICOM
CA7ONL
CPM
JFM (if using the initialization file option CPM=JFM)
Business Value:
This best practice ensures proper tracking of work and correct processing of batch work for possible
restarts.
08-Feb-2018 34/722
Review the Region Size

Define a region size of at least 50 MB and MEMLIMIT=25G if necessary for 64-bit storage use. A best
practice is leaving REGION=0M and MEMLIMIT=NOLIMIT when possible.
Earlier releases of the CA7ONL procedure contained the value REGION=6144K in the installation
JCLLIB. This region is probably sufficient for testing. We recommend that you use a value of at least
50 MB when running in production. Depending on the options and interfaces that you use, your
installation could require 120 MB or more. The most current CA7ONL procedure contains
REGION=0M.
Some z/OS users have reworked the standard IBM IEALIMIT exit. These users must verify that this exit
has not reduced this large region value for CA7ONL.
With Version 12.0, many areas are now allocated in 64-bit storage. These areas include the active
workload queues and work files that are used in performing forecasts and sorts. Also, if you are using
the agent job interface, CA Integrated Agent Services (CA IAS), 64-bit memory is used. This amount is
coded as MEMLIMIT on the CA7ONL EXEC statement. For CA IAS, a minimum of 10 MB is required.
Depending on the installation requirements at your site, add MEMLIMIT=25G to the EXEC statement.
Business Value:
This best practice results in a better overall performance for CA7ONL.
Startup Procedures Recommendations

When starting CA Workload Automation CA 7® Edition, we recommend an ERST type start (unless
otherwise noted).
The default start is WARM. To change the start type, edit the CA7ONL PROC replacing TYPE=WARM
with TYPE=ERST. Alternately, you can use the TYPE=ERST on the start command (S CA7ONL,
TYPE=ERST).
You can also change the TYPE parameter in the initialization file on the INIT statement. Remember
that the TYPE parameter specified in the procedure or on the start command overrides the TYPE
parameter in the initialization file.
Business Value:
Correct startup of CA7ONL assures seamless scheduling of batch work.
Additional Considerations:
Two cold-type starts, COLD and FORM, are available. Use the cold-type starts rarely, especially with
CA Datacom/AD. The COLD start resets the active workload queues as empty. The FORM start resets
the active workload queues and the data in the Prior Run table as empty.
08-Feb-2018 35/722
When performing a cold-type start of the CA 7 Online system, a WTOR asks for confirmation of the
cold-type start. If you want to perform the cold start, reply OK to the WTOR. If a cold-type start is not
wanted, reply to the WTOR with a warm start option. You can suppress the WTOR in the initialization
file by coding COLDWTOR=NO on the RESIDENT statement.
More Information:
For more information, see Startup Options (https://wiki.ca.com/display/CWAC7E/Execution#Execution-

StartupOptions).
Update the Initialization File

Use the batch edit function to ensure the accuracy of any initialization file changes.
At the installation, the JCLLIB contains a sample initialization file. The UCC7IN DD in the CA7ONL
procedure with member name ONLINE points to this file. When the initialization file is discussed, this
file is the file that is referenced. To initiate this function, execute the program UCC7 with a PARM of
TYPE=EDIT:
//EDIT EXEC PGM=UCC7,PARM='TYPE=EDIT'
This execution verifies the contents of the initialization file without having to start CA7ONL for any
other functions. Run this program any time that you make any initialization file changes. You want to
verify the accuracy of any changes before implementing the changes in a production mode. This
practice is especially helpful when you add or delete terminals in the initialization file. Running this
batch job does not require that CA7ONL is already active.
Business Value:
This best practice results in no downtime due to incorrect changes to the initialization file.
08-Feb-2018 36/722
Interfaces
CA Workload Automation CA 7® Edition interfaces with many other CA Technologies products and
other products. Use the navigation pane to the left to view more detailed information about these
interfaces and options.
Documentation in this area provides the following interface information:
Interfaces and integration points
Interfaces with other products
Schedule UNIX System Services jobs
IBM Workload Management
External communicators
CA Driver
NCF
Cross-Platform scheduling
Email
Global variables
Jobflow Illustrator
Jobflow Monitor
CA 7 Server for iDash
CA7TOUNI conversion utility and batch program
XTRK as an STC or job and under ICOM
XPJOB conversion utility
Use the navigation panel to the left to access these interfaces articles.
Interfaces and Integration Point Best Practices

CA Workload Automation CA 7® Edition presents significant opportunities for meeting the needs of
your environment and users. To optimize the product usage at your site, use the following best
practices.
CA WA CA 7 Edition provides many interfaces such as ISPF, TSO Foreground, and batch processing.
08-Feb-2018 37/722
CA WA CA 7 Edition provides many interfaces such as ISPF, TSO Foreground, and batch processing.
Many options affect your results. Best practices for CA Workload Automation Restart Option for z/OS
Schedulers, CA JCLCheck™, email, and others are included to maximize your use as required.
Batch Terminal Interface

Use the Batch Terminal Interface (BTI) program SASSBSTR to send commands to CA7ONL in batch and
receive the output from the commands in SYSPRINT format.
We highly recommend that you run any long running command (such as RESOLV) or commands that
have many lines of output through BTI. Also, processing database additions or updates in batch let
you retain the commands that are used in case you have to recreate the process.
The following sequence of events occurs when executing SASSBSTR:
If you are using Dynamic BTI Management, the BTI program dynamically allocates the BATCHIN and
BATCHOUT files that are associated with a specific batch terminal. Typically, the BTI program
constructs the data set names for these files. BTI uses the data set name prefix from the
communication data set (UCC7CMDS DD). The suffix BATCHI#n/BATCHO#n is appended to the prefix
to construct the full data set names. The n is the associated batch terminal number.
The constructed BATCHIN and BATCHOUT data set names must match the data set names in the
CA7ONL procedure.
Note: No dynamic allocation occurs when the following items are true:
A specific batch terminal (1-8) is specified on the PARM
The BATCHIN and BATCHOUT DDs are in the BTI JCL
SASSBSTR writes SYSIN to the BATCHIN data set.
SASSBSTR then verifies the status flags in the UCC7CMDS (communications data set). SASSBSTR sees
whether CA7ONL is up and whether the requested batch terminal is available.
If CA7ONL is up and the batch terminal is not in use--SASSBSTR turns on a setting in the UCC7CMDS
file. The setting tells CA7ONL that it has commands to process from this batch terminal.
CA7ONL reads the settings in the UCC7CMDS and processes the commands from the appropriate
BATCHIN data set.
As CA Workload Automation CA 7® Edition processes the commands from BATCHIN, it writes the
output from the commands into the appropriate BATCHOUT data set.
When the commands are completed, CA7ONL turns on a setting in the UCC7CMDS file noting this
completion.
08-Feb-2018 38/722
The SASSBSTR program has been waking every few seconds to test the setting. When it sees that
CA7ONL has completed the processing, it writes BATCHOUT to SYSPRINT and ends.
Never cancel a BTI job that is executing. If the program SASSBSTR is canceled, the batch terminal that
is used is not always accessible again until you shut down and restart CA7ONL.
Business Value:
BTI input can be saved and used to recreate the database updates or changes and commands that
produce much output can be processed.
CA Driver or Global Variables

If you have JCL substitutions that are done consistently for jobs to process correctly, look into using
either CA Driver or global variables (or perhaps both).
CA Driver is provided with CA Workload Automation CA 7® Edition and can be used to perform JCL
substitutions. The global variables feature lets users perform variable substitution without requiring
the use of CA Driver procedures. The feature lets users define global variables and assign values to
those variables. A fixed set of reserved global variables is always available (for example, current date,
job name, and more). You can add user-defined variables as needed.
If your substitution is straightforward enough, we recommend that you use global variables instead
of CA Driver procedures.
If calculations are part of the substitution (such as a date calculation), we recommend CA Driver.
Business Value:
This best practice automates JCL substitutions.
CAICCI Interface
Use the CAICCI interface for short running commands that have minimal output.
The CAICCI interface uses the CA Common Communications Interface (CAICCI) to send batch
commands to, and receive command output from CA7ONL. The interface can be executed from
batch, from a REXX address environment, or in a program-to-program mode. The interface uses
CAICCI. Thus, no requirement exists for shared DASD between the MVS images where CA Workload
Automation CA 7® Edition executes and where the CAICCI interface environment executes.
Using the CAICCI interface heavily sometimes requires that you define up to 20 CAICCI terminals.
CAICCI terminals are defined in the initialization file. When CA7ONL starts, it recognizes the CAICCI
terminal definitions. This recognition causes the CAICCI Terminal interface to initialize. You then see
the following messages in the SYSLOG:
CA-7.XTM0 - SASSXTM0 initialization in progress
CA-7.XTM0 - SASSXTM0 initialization complete
08-Feb-2018 39/722
CA-7.XTM0 - SASSXTM0 initialization complete
CA-7.XTM0 - CCI Interface initialized.
CA-7.XTM0 - CTI Receiver is: #ENFNODE .CA-7 XTM CA71
CAL2C900I CA-7 CCI Initialization Complete
Note: The initialization file OPTIONS statement CTIMSGS=NO can suppress some of these
messages.
Use the following JCL to execute the CAICCI batch interface:

//jobname JOB (user job parms)
//JS1 EXEC PGM=CAL2X2WB,PARM='ENFNODE,CA71'
//STEPLIB DD DISP=SHR,DSN=cai.ca7.cal2load
//SYSPRINT DD SYSOUT=*
//ERRORS DD SYSOUT=*
//SYSIN DD *
.....
(CA 7 commands go here)
.....
//
The command input is in Batch Terminal Interface format. The PARM information that is provided on
the execute statement is positional and optional. The first position is CAICCI NODE, where CA7ONL
runs. The second position is the CA7ONL CAICCI receiver name. Both can be found in the CA7ONL
startup message:
CA-7.XTM0 - CTI Receiver is: #ENFNODE .CA-7 XTM CA71
Note: Most clients run in a multiple LPAR environment, and batch jobs run on different
LPARs. If so, connect each LPAR through CAICCI to the LPAR where the CA7ONL started task
resides. For more information about connecting LPARS, see the CA Common Services
documentation.
REXX and a Program-to-Program call can also use the CAICCI interface.
Business Value:
Using the CAICCI interface lets you process short running commands in batch quickly. You are not
limited to eight simultaneous executions like the batch terminal interface (BTI).
CA JCLCheck Interface
Use the interface with CA JCLCheck™. The interface provides the following support:
Enhanced validation of JCL in the CA7ONL editor and on the LJCK command
08-Feb-2018 40/722
Enhanced validation of JCL in the CA7ONL editor and on the LJCK command
Batch validation of JCL for a stream of forecasted jobs
In the online environment, the interface displays procedure expansions, so that error messages are
reported in a meaningful context. Also, the interface supports checking for the existence of data sets
that can prove useful in testing production job streams.
The interface also includes a batch utility that uses the FJOB command to forecast a series of jobs.
Next, the utility uses the LJCK command to extract JCL for them so that CA JCLCheck can validate the
JCL for the stream as a whole. This utility is requested from an ISPF panel that is provided with CA
JCLCheck.
The CA JCLCheck Common Component is a subset of the CA JCLCheck product. CA JCLCheck Common
Component is shipped free of charge with CA Workload Automation CA 7 Edition to validate JCL
statement syntax and job execution within CA7ONL.
CA JCLCheck Common Component is shipped with other CA products. We recommend that you install
CA JCLCheck Common Component into its own SMP zone. This installation prevents duplicate
installation and duplicate libraries, and eliminates new installation if the primary CA product is
upgraded.
The recommended best practice is placing the CA JCLCheck Common Component load library in the
linklist and above all other CA products. If you cannot use the linklist, the CA7ONL started task must
have a STEPLIB DD pointing to the CA JCLCheck Common Component load library.
If you do not use the AUTOPROC option, add a SYSPROC DD to the CA7ONL started task. This DD
statement points to the procedure libraries that you want CA JCLCheck to search for PROC expansion.
Business Value:
Using CA JCLCheck results in fewer JCL errors.
More Information:
For more information, see the CA JCLCheck documentation.
CA Service Desk Interface

Use the CA Service Desk feature to open problem issues automatically. This feature is primarily
intended to open issues for abnormal job completions or when selected queues reach 80 percent full.
Follow these steps:
1. Install and configure the CA Service Desk using CAISDI/els from CA Common Services. CAICCI
must also be present between the system where CAISDI/els and the CA Workload Automation
CA 7® Edition are installed.
2. Customize the AL2CNTL member found in the CA Workload Automation CA 7 Edition

CAL2EVNT library.
3. Review and if necessary create CAISDI/els events in the CAL2EVNT library.
4. Define the product and event library to CAISDI/els system.
08-Feb-2018 41/722
4. Define the product and event library to CAISDI/els system.
5. Configure the CA Service Desk to recognize the information that is contained in the AL2CNTL
member.
6. Add the SERVICEDESK initialization statement to CA Workload Automation CA 7 Edition.
7. Add SERVDESK and SERVLOG DD statements to the CA7ONL procedure. The SERVDESK
statement contains the rules for the creation and customization of CA Service Desk events.
Business Value:
Using CA Service Desk enables the recording and processing of problem issues.
More Information:
For more information, see Interface with CA Service Desk (see page 59).
CA WA Restart Option (CA 11)

Use the interface with CA Workload Automation Restart Option for z/OS Schedulers (CA 11™). This
interface works in the following ways:
Supporting the ARTS command monitor
Ensuring the automatic RMS step insertion
Providing automatic CMT updating when jobs are restarted, forced to complete, or canceled
With CA Workload Automation Restart Option for z/OS Schedulers installed, CA7ONL establishes the
interfaces as jobs are ready to submit, restart, or cancel (also Force Complete). If CA Workload
Automation Restart Option for z/OS Schedulers becomes inactive, a WTO is produced:
CA-7.730 - CA-11 INACTIVE, DO YOU WANT JOBS SUBMITTED? (YES/NO/NO11)
You have the following options:
Turning off submit until you get CA Workload Automation Restart Option for z/OS Schedulers
activated
Continuing to submit work with the CA Workload Automation Restart Option for z/OS Schedulers
step inserted
Submitting work without the CA Workload Automation Restart Option for z/OS Schedulers step
inserted
Usually, you want to suspend the submission until you can activate CA Workload Automation Restart
Option for z/OS Schedulers.
If CA Workload Automation Restart Option for z/OS Schedulers is activated after CA7ONL, you can
redrive the CA Workload Automation Restart Option for z/OS Schedulers with a CA7ONL command of
SUBMIT. The CA Workload Automation CA 7® Edition top line SUBMIT command with no keywords
causes the interface to CA Workload Automation Restart Option for z/OS Schedulers to be initialized.
08-Feb-2018 42/722
causes the interface to CA Workload Automation Restart Option for z/OS Schedulers to be initialized.
If CA Workload Automation Restart Option for z/OS Schedulers is not active, you receive the CA-7.730
WTOR again. The message requires a reply before processing continues.
With CA Workload Automation Restart Option for z/OS Schedulers and CA Workload Automation CA
7 Edition, a parameter, CONDCHK=YES, on the initialization file RESTART statement, indicates that CA
Workload Automation CA 7® Edition controls the restart step. The relative job step number in which
to restart the job is passed to CA Workload Automation Restart Option for z/OS Schedulers. CA
Workload Automation Restart Option for z/OS Schedulers then evaluates the true restartable step
(based on temporary data sets and other items). Also, CA Workload Automation CA 7 Edition displays
the JES node where the job executed and the CA Workload Automation Restart Option for z/OS
Schedulers subsystem name on the restart panel.
Jobs with remote nodes that use CA Workload Automation Restart Option for z/OS Schedulers r11 or
higher require one of the following items:
The no cost CA GTS product that is configured for CA Workload Automation Restart Option for z
/OS Schedulers.
The CA Workload Automation Restart Option for z/OS Schedulers configuration option
LOCALGTS=NO when all nodes are in the same SYSPLEX.
Business Value:
Using CA Workload Automation Restart Option for z/OS Schedulers ensures that job restarts and
reruns that are correct without any manual intervention.
Email Feature
Use the email feature for an automatic problem notification. The email feature lets you generate and
send emails from the address space using standard SMTP protocol. This feature is primarily intended
for an automatic problem notification, such as job abends. However, the feature can notify end-users
or other staff about any status.
Business Value:
Using email provides quicker notification of job abends and better communication within your
organization.
To implement the email feature:
Add the following DD to your CA7ONL procedure.

//SYSTCPD DD DSN=VTAM.TCPIP.DATA,DISP=SHR
The SYSTCPD DD statement points to the data set containing systemwide TCP/IP definitions. If only
one TCP/IP system is executing in the environment, you can omit this DD statement from the CA7ONL
procedure. If you have multiple TCP/IP environments, code the SYSTCPD DD statement pointing to
the definition library for the TCP/IP.
Note: If TCP/IP is not in the linklist, add the TCP/IP STEPLIB data sets to the CA7ONL STEPLIB
08-Feb-2018 43/722
Note: If TCP/IP is not in the linklist, add the TCP/IP STEPLIB data sets to the CA7ONL STEPLIB
concatenation.
The following references to AL2xxxxx members are for releases starting with r11.3. Release 11.1 uses
member names that start with CAL2xxxx that reside in the CAL2OPTN library.
Next, add the following statements in your initialization file with the appropriate values:
EMAIL,ESERVER=email.com,
EADDRLIB=CA7.AL2EADR,
EMAILLIB=CA7.AL2EMAIL,
EFROM=CA7,
EREPLY=CA7@do.not.reply,
EPORT=25,
ETIMEOUT=10
If you do not already have one, build the data set referenced by EADDRLIB. The data set is a fixed
block, 80-byte PDS. Members of the EADDRLIB PDS are used to build the list of email addresses to
which emails are sent. The TO=xxxxxxxx keyword on the /EMAIL command specifies the member
name. Also, provide a TXT keyword on the /EMAIL command to provide the message text to send. We
provide four sample messages to send for job failures, abends, late jobs, and jobs ending. Member
AL2EMAIL in the CAL2JCL library contains these samples.
A batch utility, AL2EMLT, is available to test the email interface in an isolated environment. The utility
can be used to test different SMTP (email) servers, new templates, new email address members, or
all. AL2EMLT provides information about a "dummy" job so that email templates with variables
referencing job information are shown with realistic data. See the AL2EMAIL member in the
CAL2OPTN library.
Verify that you have an L2SCEMAL resource that is defined to the external security exactly like you
would have for other L2xxxx commands.
To generate an automatic email notification for job failures, you have an ARFSET set up to respond
with a /EMAIL command. A sample ARFSET follows. The ARFSET gets invoked for a job when a return
completion rc = 0004. The ARFSET then issues the /EMAIL command to send an email. The email goes
to the email addresses listed in the member that is named SUPPORT with the message found in the
library AL2EMAIL member @JOBEND.
----------------------- ARF CONDITION EDIT FOR SUPPORT ---------------
FUNCTION: LIST (ADD,DELETE,EXIT,FORMAT,LIST,REPL,SAVE,SR,SS) DEFCT:
TYPE: JC SYS EQ * SID EQ 0 RSTC GE 0 EM EQ * DEFID: 1
FROM: 01011975 0001 TO: 12312074 2359

JC, SC TST: STEP EQ * PROC EQ * PGM EQ *
CC/ABENDS : CC EQ 0004 __ ??? GE 000 __ ??? GE 000 __
??? GE 000 __ ??? GE 000 __ ??? GE 000
EC, EE, IS, LB, LE, LS TST:
RO: DATE: TIME: AO: INT/ADJ:
RESPONSES:
1: AC,M=/EMAIL,TO=SUPPORT,TXT=@JOBEND,JOB=&JOBNAME
2:
3:
FINAL -- DISP : N CA-11?: N BYPGDG: N USAGE: PROCESS: CC:
START : END :
PROGRAM: AR32 MSG-INDX: 00 -- AR.3.1 -- yy.ddd / hh:mm:ss
08-Feb-2018 44/722
IBM WLM
CA7ONL can facilitate the use of WLM for balancing work on the mainframe.
Features that can facilitate the use of IBM WLM (Workload Management System) scheduling
environments to manage your batch workload are provided. A scheduling environment is a list of
WLM resource names and their required states (ON, OFF, or RESET). Through CA Workload
Automation CA 7 Edition Virtual Resource Management (VRM) definitions, you can assign IBM WLM
scheduling environments to individual jobs and have CA7ONL automatically add the appropriate
SCHENV= keyword at job submission time. These VRM definitions use the variable (VAR) resource
type and can be associated based on schedule ID (SCHID). When CA7ONL prepares to submit a job, it
scans VRM variable definitions for the SCHID of the job. If an appropriate VRM variable definition is
found, it is used to set the value of the SCHENV keyword to insert.
Business Value:
This best practice lets you exploit WLM to control batch work.
The definition of VRM variables is supported using the RM panels. The sole purpose of a VRM
variable definition is to control the SCHENV keyword insertion. The SCHENV keyword insertion can be
tailored to a specific run of a job. Define a VRM variable in the resource profile of the job.
A VRM WLM variable is indicated when VAR is specified as the resource type in the definition on the
RM.1 panel. When VAR is specified, the FREE value is not used and is always set to N. The resource
name in the definition must begin with 'SCHENV.'. This prefix signifies that the variable is used for
SCHENV insertion. The second node of the resource name designates the WLM scheduling
environment that must be available for the job to run. This value must conform to IBM naming
conventions for scheduling environments.
The setting of the WLMSE keyword on the OPTIONS statement in the initialization file governs
SCHENV keyword insertion. IF N or NO is coded, CA7ONL does not attempt to insert the SCHENV
keyword. WLMSE=Y or WLMSE=YES indicates that CA7ONL is to insert the SCHENV keyword. If a value
other than Y or YES is coded, CA7ONL assumes that it is a global default. The global default is inserted
when CA7ONL is unable to determine a more specific value for the job.
First, CA7ONL scans for an entry with a SCHID value matching that of the job being submitted. If a
match occurs, the value from the resource name is inserted on the JOB statement. If no match
occurs, a scan is made for an entry with a SCHID value of 0. If found, this value is the SCHENV value
that is used on the JOB statement. If neither is present, CA7ONL attempts to use the global value
defined in the initialization file, if one is available. If no global value has been defined on the WLMSE
keyword of the OPTIONS statement, the job is submitted without any SCHENV keyword insertion.
Note: All scheduling environments must be defined to the IBM WLM.
08-Feb-2018 45/722
If the JCL for a job already has a SCHID keyword on the JOB statement, it is not overridden or
validated. Assume that a job is submitted with a SCHID keyword specifying a scheduling environment
that is not part of the current policy. In this case, the job terminates with a preexecution JCL error.
More Information:
For more information about resource types and examples, see VRM Resource Types (https://docops.ca.
com/display/CA712/VRM+Resource+Types).
JFM Interface
Jobflow Monitor, JFM, monitors the current and near future workload, and provides a small historical
view. You can use JFM for more than one application, like CA Critical Path Monitor (CPM) and CA 7
Web Client. JFM lets these applications make queries while collecting the job status information from
the CA 7 Online system.
We recommend separate JFM tasks for each application, but separate tasks are not required. The
start-up options and parameters are unique by application. Also, with each application having its own
log, JFM records deal only with that application and facilitates problem isolation.
More information:
Jobflow Monitor (see page 288)
To prevent performance and support issues, consider adding the following DD statements to the JFM
JCL:
//CEEOPTS DD DISP=SHR,DSN=cai.CA7.useroptions(JBFLWCEE)
//CEEDUMP DD SYSOUT=*
Where this member contains the following statement:

CEEDUMP(0,SYSOUT=*,FREE=END,SPIN=UNALLOC),
DYNDUMP(yourHLQ.JFM.XLCDUMP,DYNAMIC,TDUMP),
HEAP64(,,FREE,,,FREE,,,FREE),
HEAPCHK(OFF),
IOHEAP64(,,FREE,,,FREE,,,FREE),
LIBHEAP64(,,FREE,,,FREE,,,FREE),
RPTOPTS(OFF),
RPTSTG(OFF),
STORAGE(NONE,NONE,NONE),
TERMTHDACT(UADUMP),
TRACE(OFF),
TRAP(ON,SPIE)
These settings turn off several CPU-intensive debug options. These settings also improve support
dumps for the JFM address space.
CA CPM Application: After starting the CA 7 Online system (CA7ONL), then start CA CPM before JFM.
08-Feb-2018 46/722
CA CPM Application: After starting the CA 7 Online system (CA7ONL), then start CA CPM before JFM.
In the CAL2OPTN member JBFLWMN, the recommended parameter settings for a CA 7 instance
(CA7n) are:
MONITOR(INSTANCE(CA7n) TYPE(WARM) REFRESH(60) SPAN(1) HISTORY(0)
Use a WARM start to allow automatic recovery (CAIENF events) so that CA CPM is synchronized with
JFM. The history value is set to zero, because any data needed is obtained from the recorded CAIENF
events. The REFRESH and SPAN values can be changed based on the needs of an installation. Also
consider whether long running flows span more time and how much processing is being done with
flows.
In the CAL2OPTN member JBFLWIP, set the IP communications for CA CPM as follows:
PORT(NAME(CPMPORT) NUMBER(7173))
Port number 7173 is the default for the CA CPM port for JFM. You can override the default by
specifying a different port number.
The CA7 Web Client Application: After starting the CA 7 Online system (CA7ONL), then start JFM
before starting the CA 7 Web Client. This method lets JFM get ready for query requests from the CA 7
Web Client interface. In the CAL2OPTN member JBFLWMN, we recommend the following parameter
settings for a CA 7 instance (CA7n):
MONITOR(INSTANCE(CA7n) TYPE(COLD) REFRESH(60) SPAN(1) HISTORY(1)
The CA 7 Web Client is interactive with queries for current data. For this reason, perform a cold-type
start because the data is only from this point in time. A history period is given so that the CA 7 Web
Client queries can complete two tasks:
Obtain data from the past number of hours
Forecast (SPAN) for the next number of hours
This period is the moving window to encompass the rolling period of workload.
In the CAL2OPTN member JBFLWIP, set the IP communications for CA 7 Web Client as follows:
PORT(NAME(CPMPORT) NUMBER(NONE))
PORT(NAME(QRYPORT) NUMBER(nnnnn))
This setting disables the CPMPORT communications, as this instance of JFM does not need to
exchange data with CA CPM. The QRYPORT is a valid port number for use by JFM to listen for CA 7
Web Client requests.
Business Value:
JFM is used with CA CPM to monitor critical SLAs, with reporting and updating job status.
For the CA 7 Web Client, JFM provides a graphical interface to determine job flows, triggers, and
requirements.
08-Feb-2018 47/722
TCP/IP Terminal Interface

Use the TCP/IP terminal interface for short running commands that have minimal output.
The TCP/IP terminal interface uses TCP/IP to send batch commands to, and receive command output
from CA7ONL. The interface can be executed from batch, from a REXX address environment, or in a
program-to-program mode. The interface uses TCP/IP. Thus, no requirement exists for shared DASD
between the MVS images where CA Workload Automation CA 7® Edition executes and where the TCP
/IP interface environment executes.
TCP/IP terminals are defined in the initialization file as CAICCI terminals.
Update the initialization file on each instance of CA7ONL that is to use the TCP/IP interface. Add the
following keyword to the UCC7VTAM statement:
TCPTPORT=nnnnn
The nnnnn is a number from 1 to 65535. This number is the TCP/IP port number on which CA7ONL
listens for incoming messages. The port number must be registered in the profile of the running TCP
started task.
Also, on the UCC7VTAM statement is the TCPTMOUT parameter. This parameter specifies the
number of seconds in which to receive responses. The default is 10 seconds.
When CA7ONL starts, it recognizes the TCPTPORT keyword and the CAICCI terminal definitions. This
recognition causes the TCP/IP terminal interface to initialize. You next see messages similar to the
following messages in the SYSLOG:
CAL2T050I TCP/IP host name is USCOMP31
CAL2T051I TCP/IP host addr is 155.222.67.89
CAL2T065I TCP/IP port number is 4071
Use the following JCL to execute the TCP/IP batch interface:

//JS1 EXEC PGM=CAL2X2TB,PARM='USCOMP31.CO.COM,4071,CA71'
//STEPLIB DD DISP=SHR,DSN=cai.ca7.cal2load
//ERRORS DD SYSOUT=*
//SYSIN DD *
.....
.....
//
The command input is in Batch Terminal Interface format.
The PARM information that is provided on the execute statement is positional and is required. The
first position is the TCP/IP address where CA7ONL runs. The second position is the TCP/IP port
number where CA7ONL listens. The third position is the name of the CA7ONL instance.
08-Feb-2018 48/722
Note: Most customers run in a multiple LPAR environment, and batch jobs run on different
LPARs. If so, connect each LPAR using TCP/IP to the LPAR where the CA7ONL started task
resides.
Business Value:
Using the TCP/IP interface lets you process short running commands using TCP/IP quickly.
Interfaces with Other Products

CA Workload Automation CA 7® Edition was developed to interface with CA Technologies and other
software products. Combined with other products, CA Workload Automation CA 7® Edition forms the
base for a highly automated, efficient data center.
Note: For more information about the security product interfaces, see Securing (http://wiki-
dev.ca.com/display/CWAC7E/Securing).
Interface with CA7LOG CAIENF Events

Using CAIENF, CA Workload Automation CA 7® Edition issues CA7LOG events that Jobflow Monitor
uses to monitor and forecast the CA Workload Automation CA 7® Edition workflow.
To activate the generation of the events, specify JFM=YES in the OPTIONS statement of the
initialization file.
Add the CA7LOG event to your CAIENF database. To add this event, see member AL2ENF12 in the CA
Workload Automation CA 7® Edition CAL2OPTN library.
The previous releases of CA Workload Automation CA 7® Edition restricted the critical path definition
and monitoring to trigger-only paths. Jobflow Monitor can provide more robust critical path
definition and monitoring by including nontriggering predecessors into the critical path
determination. To activate this processing, specify CPM=JFMLOAD and JFM=YES in the CA Workload
Automation CA 7® Edition OPTIONS statement.
Interface with CA 1
The CA 1® TIQ interface with online TIQ and TIQU top line commands is supported. TIQ allows access
but no update while TIQU allows access and update to the CA 1 TMC. After a TIQ or TIQU command is
entered, the terminal is placed in TIQ monitor mode. Input is exactly as documented in the CA 1
documentation.
Note: CA Workload Automation CA 7® Edition has no batch interface to the CA 1 TIQ
08-Feb-2018 49/722
Note: CA Workload Automation CA 7® Edition has no batch interface to the CA 1 TIQ

Interface.
The default for DSN verification is YES. Enter TIQU,DSN=NO to change this setting.
To exit from TIQ mode, enter C. You can cause an automatic cancel from TIQ mode after a specified
number of minutes of inactivity. Use the MONLIM value from the TERM statement in the initialization
file.
The CA Workload Automation CA 7® Edition OPID used to log in to CA Workload Automation CA 7®

Edition is sent to CA 1 as the password. If it is not defined to the CA 1 Security module, a message
appears. You must enter a different CA 1 password.
Messages that the CA Workload Automation CA 7® Edition TIQ interface produces are documented in
the Messages and Codes articles. Those messages that CA 1 produces are documented in the CA 1
documentation.
The CA 1 TMS load library must be concatenated to the CA Workload Automation CA 7® Edition
STEPLIB to use this feature.
When the TIQ interface is used, increase the CWORK value for CA Workload Automation CA 7®
Edition by 10 for each concurrent TIQ session through CA Workload Automation CA 7® Edition.
Note: The CA 1 TIQ interface in CA Workload Automation CA 7® Edition dynamically loads

the appropriate TIQ interface module. The selection is based on the current release of CA 1
found on your system during execution. Therefore no special application statements are
required.
TIQ Command
This command has the following format:
{TIQ|TIQU}[,DSN={YES|NO}]
U
Indicates that updating occurs.
DSN
Indicates whether to verify the data set name before CA 1 allows updating of the TMC record. The
default is YES. This parameter is valid only with TIQU.
Interface with CA APCDDS

CA Workload Automation CA 7® Edition can interface with CA APCDDS™, which automates the
manual, often neglected task of data verification. CA APCDDS increases the accuracy and consistency
of your output while reducing reruns and improving auditability.
CA APCDDS is a rule-based menu-driven system. CA APCDDS provides comprehensive data
08-Feb-2018 50/722
CA APCDDS is a rule-based menu-driven system. CA APCDDS provides comprehensive data

verification routines. The routines catch errors in a timely fashion — before mistakes are propagated
throughout the system. CA APCDDS adds to the flexibility of CA Workload Automation CA 7® Edition
by allowing an out-of-balance condition affect the production workflow directly. CA APCDDS can
directly issue a CA Workload Automation CA 7® Edition command in response to an out-of-balance
condition. No longer is it necessary to balance a report manually and then manually to demand jobs
for execution. Implementation of CA APCDDS requires no changes to your existing application
programs.
Interface with CA APCDOC

CA Workload Automation CA 7® Edition can interface with CA APCDOC™, which is a CA production
documentation product. Installed on your system, you can use its flowchart facility to show schedule
and job flowcharts from the database. These flowcharts can be based on the current workload or
forecasted for a future date. CA Workload Automation CA 7® Edition users can use the DOCCHART
component. The component can print flowcharts of jobs showing the job schedules, successor
relationships, and other job-related information.
Note: We recommend the use of the Jobflow Illustrator feature of CA Workload

Automation CA 7® Edition for the production of flowcharts.
Compare FSTRUC to a Database Flowchart

CA Workload Automation CA 7® Edition users have the option of producing a flowchart directly from
the database or by reading an FSTRUC report. If the user chooses the FSTRUC option, the FSTRUC
command is issued first, placing the output into a sequential file. The DOCCHART then reads the file.
The differences between creating a CA Workload Automation CA 7® Edition flowchart from FSTRUC
output and creating one from the database include the following items:
The database flowchart shows job and data set requirements, which FSTRUC does not.
The database flowchart shows a starting point and continues on until it reaches the end, whereas
FSTRUC only shows one job at a time.
The database flowchart is not time sensitive. The flowchart shows the relationship between jobs
regardless of the time it is run. The flowchart gives an undistorted view of triggers and
requirements, and database relationships.
The database flowchart runs independently of CA Workload Automation CA 7® Edition and does
not require CA Workload Automation CA 7® Edition address space or BTI. CA Workload
Automation CA 7® Edition does not have to be active (although it usually is). The forecast
commands such as FSTRUC use many resources that the database flowchart does not.
Because the database flowchart issues its own reads to the database, it can run against any copy
of the database (current, old, or restored). A user can compare the database today to the
database as it was six months ago.
08-Feb-2018 51/722
Interface with CA Dispatch

CA Workload Automation CA 7® Edition can interface with CA Dispatch™.
This interface consists of two parts where data is communicated either from CA Workload
Automation CA 7® Edition to CA Dispatch or from CA Dispatch to CA Workload Automation CA 7®
Edition.
The CA Workload Automation CA 7® Edition to CA Dispatch part of the interface is discussed in

the following topic.
The CA Dispatch to CA Workload Automation CA 7® Edition part of the interface is discussed in

the CA Dispatch documentation.
Forecast Print Volumes

When CA Dispatch is used for managing printed output, the forecasting of print volumes by CA
Dispatch is sometimes desirable for planning activities that are associated with handling the actual
printed output.
An interface to CA Dispatch is provided to support this function.
Note: For more information about the forecast of print activity, see the CA Dispatch
documentation.
Create a Plan Data Set

Follow these steps:
1. Issue a CA Workload Automation CA 7® Edition top line FWLP command, or an equivalent

batch command through a batch terminal interface, to forecast the jobs for which print
volumes are wanted.
This places data in a data set reserved for FWLP purposes. This card-image data identifies the
jobs and when they are scheduled to run.
That data set must have been previously defined in the CA Workload Automation CA 7®
Edition JCL.
2. Run a batch job using module SASSDPCH to reformat the data from Step 1 into plan records in
the format that CA Dispatch requires.
3. Using the output file from SASSDPCH, produce the forecast of print volumes as described in
the CA Dispatch user documentation.
Alternatively, the user can modify or create manually the data set created in Step 1 before Step 2.
The following sample is the JCL necessary to produce a plan file for CA Dispatch.
//jobname JOB user-defined-parameters.........................................
//*
//******************************************************************************
//* *
08-Feb-2018 52/722
//* *
//* CREATE FWLP DATA SET WITH DESIRED FORECAST INFORMATION *
//* *
//******************************************************************************
//*
//STEP1 EXEC PGM=SASSBSTR,REGION=20K,PARM=parm
//STEPLIB DD DISP=SHR,DSN=cai.CAL2LOAD
//UCC7CMDS DD DISP=SHR,DSN=ca7.communications.data.set
//BATCHIN DD DISP=SHR,DSN=batch.input.data.set
//BATCHOUT DD DISP=SHR,DSN=batch.output.data.set
//SYSPRINT DD SYSOUT=A,DCB=BLKSIZE=133
//SYSUDUMP DD SYSOUT=A
//SYSIN DD *
/LOGON operatorid
FWLP,....desired parameters go here.....
/LOGOFF
//*
//*
//******************************************************************************
//* *
//* REFORMAT FWLP DATA INTO CA-DISPATCH 'PLAN' RECORDS *
//* *
//******************************************************************************
//*
//STEP3 EXEC PGM=SASSDPCH
//SYSUDUMP DD SYSOUT=*
//FWLPDATA DD DISP=SHR,DSN=dataset-containing-FWLP-data
//DISPATCH DD DSN=input-plan-data-set-for-DISPATCH,
// DISP=(NEW,CATLG),UNIT=SYSDA,SPACE=(TRK,(n,n)),
// DCB=(RECFM=FB,LRECL=50,BLKSIZE=nnnn)
//
Interface with CA Earl

The interface between CA Earl™ and CA Workload Automation CA 7® Edition requires the CAL2EARL
target library that is generated during installation and a copy of CA Earl. If a full copy of CA Earl is
installed, it can be used. If a full copy of CA Earl is not available, you can install the service from CA
Common Services.
The CAL2EARL EARL report members, prefix CA7ER, contain record and report definitions that are
used for the reports.
More information:
CA Earl and CA Easytrieve Reporting (https://wiki.ca.com/display/CWAC7E

/CA+Earl+and+CA+Easytrieve+Reporting)
Interface with CA Easytrieve

CA Workload Automation CA 7® Edition can interface with CA Easytrieve. CA Workload Automation
CA 7® Edition provides a complete set of report definitions for use with CA Easytrieve. If a full copy of
CA Easytrieve is installed, it can be used. If a full copy of CA Easytrieve is not available, you can install
the service from CA Common Services.
You can produce a standard set of reports using either the CA Workload Automation CA 7® Edition
08-Feb-2018 53/722
You can produce a standard set of reports using either the CA Workload Automation CA 7® Edition
log history file as input to CA Easytrieve.
The CA Easytrieve report definitions, prefix CA7EZ, are saved in the CAL2EZTR data set.
More information:
CA Earl and CA Easytrieve Reporting

(https://wiki.ca.com/display/CWAC7E/CA+Earl+and+CA+Easytrieve+Reporting)
Interface with CA JCLCheck

The interface with CA JCLCheck™ supports enhanced validation of JCL in the CA Workload
Automation CA 7® Edition editor and on the LJCK command. The interface also supports batch
validation of JCL for a stream of forecasted jobs.
If a full copy of CA JCLCheck is installed, it can be used with enhanced features such as procedure
expansions. If a full copy of CA JCLCheck is not available, you can install a common component of CA
JCLCheck.
In the online environment, the interface greatly extends the CA Workload Automation CA 7® Edition
validation facilities. For example, the interface displays procedure expansions, so that error messages
are reported in a meaningful context. Also, the interface supports checking for the existence of data
sets that sometimes proves useful in testing production job streams.
The interface also includes a batch utility that uses the FJOB command to forecast a series of jobs.
Then the LJCK command can extract JCL for them so that CA JCLCheck can validate the JCL for the
stream as a whole. This utility is requested from an ISPF panel that is provided with CA JCLCheck.
Note: For more information, see the CA JCLCheck documentation.
CA 7 Considerations
The interface is requested through the JCLCHECK statement in the CA Workload Automation CA 7®
Edition initialization file. An OS LOAD macro is used during CA Workload Automation CA 7® Edition
initialization to locate the JCLCHECK load module. The address that the LOAD macro returned is used
for all subsequent accesses of CA JCLCheck by CA Workload Automation CA 7® Edition. If the
JCLCHECK module is not resident or in a linklist library, concatenate the library containing the
JCLCHECK load module to the CA Workload Automation CA 7® Edition STEPLIB.
08-Feb-2018 54/722
If you use the interface with CA JCLCheck, the storage requirement for CA Workload Automation CA
7® Edition can increase significantly. A CWORK increase of 250 is proposed as a starting value.
However, consider this value as a tentative recommendation. The storage that is required can vary
according to several factors. Factors can include the number of concurrent interface users and the
number of input statements to parse. For more information about CA JCLCheck storage
requirements, see the CA JCLCheck documentation.
The execution JCL for CA Workload Automation CA 7® Edition must be modified to include a DD
statement that points to the libraries on which cataloged procedures reside. The name of the DD
statement must be SYSPROC. If this DD statement is not found, the CA JCLCheck option AUTOPROC
can be specified. For more information about the AUTOPROC option, see the CA JCLCheck
documentation.
If the JCLCHECK statement in the CA Workload Automation CA 7® Edition initialization file uses the
DDNAME parameter, an additional DD statement is required using the name from the DDNAME
parameter. The DD references a card-image file specifying more options for CA JCLCheck. For a list of
valid options, see the JCLCHECK statement. For more information about these options, see the CA
JCLCheck documentation.
Note: With the internal cross-platform job types, the CA Workload Automation CA 7®
Edition command LJCK works to validate the parameters being sent to the distributed
operating environment. This validation is performed outside of the CA JCLCheck product.
Interface with CA Librarian

CA Workload Automation CA 7® Edition can interface with CA Librarian®.
To configure the interface, add the following DD statement to the CA Workload Automation CA 7®
Edition online JCL for each CA Librarian data set.
//JCLnnn DD DISP=SHR,DSN=name-of-librarian-data-set
Add the following JCL statement to the CA Workload Automation CA 7® Edition initialization file for
each CA Librarian data set.
JCL,DSN=name-of-librarian-data-set,INDEX=nnn,DSORG=LIB [,MCD=xxxx]
The nnn value of the INDEX parameter of the JCL statement must be the same value as nnn on the DD
statement. The DD statement requires leading zeros. Access is read-only using JCL panels, list
commands, or job scheduling functions such as DEMAND and RUN.
Normal access expands "include" references, but a list option is available to suppress expansion when
doing an LLIB command.
Add an APPLCTN statement to the initialization file. The statement has the following format:
APPLCTN,NAME=SASSLIBR,ATTR=PERM
08-Feb-2018 55/722
Interface with CA OPS/MVS

CA OPS/MVS® Event Management provides an interface to CA Workload Automation CA 7® Edition
using the U7SVC facility. This interface allows CA Workload Automation CA 7® Edition commands to
be issued based on events that CA OPS/MVS® Event Management and Automation recognizes. Any
commands that issued using the CA OPS/MVS® Event Management and Automation interface require
operator security that is defined for the trailer terminal. For more information about this interface,
see the CA OPS/MVS® Event Management and Automation documentation.
CA Workload Automation CA 7® Edition commands can also be issued using the CA Workload
Automation CA 7® Edition CAICCI interface. This facility returns the output from the CA Workload
Automation CA 7® Edition commands to the caller for an evaluation. For information about using this
facility in CA OPS/MVS® Event Management and Automation, see the CA-GSS topics.
For CA OPS/MVS® Event Management and Automation to monitor CA Workload Automation CA 7®

Edition browse data set messages, add the CA Workload Automation CA 7® Edition browse event to
your CAIENF database. To add this event, see member AL2ENF12 in the CA Workload Automation CA
7® Edition CAL2OPTN library.
CA Workload Automation CA 7® Edition also provides an interface to CA OPS/MVS® Event

Management and Automation System State Manager (SSM). The CA Workload Automation CA 7®
Edition online task, ICOM, and NCF support the interface. These tasks can provide information
directly to CA OPS/MVS® Event Management and Automation without having to issue messages to
the console. The state of the tasks (UP, DOWN, and so on) is passed to the System State Manager
(SSM) in CA OPS/MVS® Event Management and Automation.
These tasks set their status in SSM automatically when the associated initialization options are set to
enable the CA OPS/MVS® Event Management and Automation interface. This status is set in the CA
Workload Automation CA 7® Edition online task by the 'STATEMGR,OPSSSM=YES' initialization
statement and in ICOM and NCF by EXEC parameter 'OPSSSM=YES'.
The SSM application names are CA7ONL, CA7ICOM, and CA7NCF.
These tasks issue the following states:
STARTING
Issued at the beginning of the task initialization
UP
Issued after the task initialization is complete
STOPPING
Issued when a termination is requested
DOWN
Issued only before the task ends
Assume both the ARM interface and the CA OPS/MVS® Event Management and Automation SSM
interface are enabled for a specific task. In this case, the action that is defined in the CA OPS/MVS®
Event Management and Automation SSM 'Action' table must not include restarting the task. ARM is
already performing the restart.
08-Feb-2018 56/722
More information:
IBM Automated Restart Management (https://wiki.ca.com/display/CWAC7E

/IBM+Automated+Restart+Management)
Critical Path Monitoring (https://wiki.ca.com/display/CWAC7E/Critical+Path+Monitoring)
CA GSS REXX Address Environment Interface Execution (https://wiki.ca.com/pages

/viewpage.action?pageId=134845067)
Activate the CA OPS/MVS® Event Management and Automation API

CA OPS/MVS® Event Management and Automation also provides an application programming
interface (API) to CA Workload Automation CA 7® Edition using the Master Station Message Routing
(MSMR) facility. This API lets CA OPS/MVS® Event Management and Automation monitor CA
Workload Automation CA 7® Edition browse data set messages.
Follow these steps:
1. Add an event that is named CA7MSG where your CA OPS/MVS® Event Management and
Automation events are defined.
2. Set up CA OPS/MVS® Event Management and Automation AOF rules as necessary to process
the event.
3. See the information about using MSMR (https://wiki.ca.com/display/CWAC7E/MSMR+-

+Route+Master+Station+%28Browse%29+Messages).
Each send of a message to CA OPS/MVS® Event Management and Automation triggers API rules in
that product, which responds by either logging the information or acting in response to the
information.
CA Workload Automation CA 7® Edition passes an event named CA7MSG to CA OPS/MVS® Event

Management and Automation.
Sites must specify in CA OPS/MVS® Event Management and Automation what action to take in
response to the events from CA Workload Automation CA 7® Edition by writing API rules that respond
to the events. Rules are written in the OPS/REXX language, which is similar to IBM REXX, but includes
certain enhancements.
Note: For more information about coding and debugging API rules, see the AOF Rules in
the CA OPS/MVS® Event Management and Automation documentation.
Example Process SMF0-19 Browse Log Event

This example processes the SMF0-19 browse log event.
08-Feb-2018 57/722
)API CA7MSG
/*--------------------------------------------------------------------*/
/* The simple logic within this sample API rule will process */
/* the CA 7 Browse Log API events and create a banner alert */
/* MLWTO for the abnormal termination (SMF0-19) event. */
/*--+----1----+----2----+----3----+----4----+----5----+----6----+----7*/
)Proc

/*--------------------------------------------------------------------*/
/* The complete CA 7 Browse Log API event will be contained in the */
/* API.TEXT variable. We'll parse out the message ID so that we can */
/* determine if we have any special processing to perform. */
/*--+----1----+----2----+----3----+----4----+----5----+----6----+----7*/
parse var api.text msg_id msg_text

/*--------------------------------------------------------------------*/
/* Process this particular API event. This sample is only interested */
/* in SMF0-19 events. */
/* SMF0-19 JOB CA74GE01 (0102) ABNORMALLY TERMINATED. */
/* RESTART REQUIRED FAILING CODE = S013.LAST STEP EXECUTED = JS020 */
/*--+----1----+----2----+----3----+----4----+----5----+----6----+----7*/
select
when msg_id = 'SMF0-19' then call abnormal_term
otherwise nop
end
return

/*--------------------------------------------------------------------*/
/* Sub-routine (abnormal_term): */
/* Process API indicating that a CA 7 job abnormally terminated */
/* - Extract jobname, CA 7 jobid and fail code from message */
/* - Call issue_alert routine to issue MLWTO alert banner */
/*--+----1----+----2----+----3----+----4----+----5----+----6----+----7*/
abnormal_term:
parse var msg_text . 'JOB ' jobname jobid . 'CODE = ' fcode '.' .
call issue_alert 'Abnormal term for:'jobname jobid 'FC='fcode
return

/*--------------------------------------------------------------------*/
/* Sub-routine (Issue_Alert): */
/* Issue alert banner message to the local master or via route codes */
/* if a local master does not exist. */
/* The below logic will generate a MLWTO similar to: */
/* */
/* OPSNOTIFY OPS/MVS ALERT MESSAGE: */
/* ************************************************** */
/* * CA74 API alert detected: * */
/* * ABNORMAL TERM FOR:CA74GE01 (0102) FC=S013 * */
/* * Notify primary support contact. * */
/* ************************************************** */
/*--+----1----+----2----+----3----+----4----+----5----+----6----+----7*/
Issue_Alert:
arg alerttxt
msg1 = api.level 'API alert detected:'
msg2 = alerttxt
msg3 = 'Notify primary support contact.'
mlwtxt.1 = 'OPS/MVS ALERT MESSAGE:'
mlwtxt.2 = COPIES('*',50)
mlwtxt.3 = '* '||CENTER(msg1,46)||' *'
mlwtxt.6 = COPIES('*',50)

/*-------------------------------------------------------------------*/
/* Determine the destination attributes for the Address WTO command. */
/* Use the local master console on this system or routes 1,2 if a */
/* console is not defined. */
/*-+----1----+----2----+----3----+----4----+----5----+----6----+----7*/
localmstr = OPSINFO('LOCMSTCONSNM')
destination = 'CNNAME('localmstr')'
if localmstr = '' then destination = 'ROUTE(1,2)'

08-Feb-2018 58/722

/*-------------------------------------------------------------------*/
/* Issue the created MLWTO to the derived destination. */
/*-+----1----+----2----+----3----+----4----+----5----+----6----+----7*/
address WTO
"Msgid(OPSNOTIFY) Textvar(mlwtxt.) Desc(2) "destination
return
Interface with CA Panvalet

CA Workload Automation CA 7® Edition can interface with CA Panvalet®.
The following DD statement must be added to the CA Workload Automation CA 7® Edition online JCL
for each CA Panvalet data set.
//JCLnnn DD DISP=SHR,DSN=name-of-panvalet-data-set
The following JCL statement must also be added to the CA Workload Automation CA 7® Edition
initialization file for each CA Panvalet data set.
JCL,DSN=name-of-panvalet-data-set,INDEX=nnn,DSORG=PAN
The nnn value of the INDEX parameter of the JCL statement must be the same value as nnn on the DD
statement. Leading zeros are required on the DD statement. Access is read-only using JCL panels, list
commands, or job scheduling functions such as DEMAND, RUN, and others.
Normal access expands "include" references, but a list option is available to suppress the expansion
when doing an LLIB command.
If a new version of CA Panvalet is installed, recycle CA Workload Automation CA 7® Edition (a WARM

start is sufficient).
Interface with CA Service Desk

CA Workload Automation CA 7® Edition can open requests (issues) in CA Service Desk when certain
events occur in CA Workload Automation CA 7 Edition. For example, if a payroll job abends, a request
can be automatically opened to track the problem.
The following CA Workload Automation CA 7 Edition events can be used to create a request in CA
Service Desk:
Job Completions
Scratch or DQTABLE reaching 80 percent full
The /SDESK command
CA Workload Automation CA 7 Edition requires CAISDI/els from the CA Common Services tape. CA
Service Desk Release 11 or higher is also required.
If you do not want requests open for all job completions or queue full conditions, you can provide CA
Workload Automation CA 7 Edition with rules about opening requests.
08-Feb-2018 59/722
Note: This interface is not the same as the Problem Management Interface, formerly
known as CA Netman™.
Configure CAISDI/els For CA Workload Automation CA 7 Edition

To learn how to install CAISDI/els from the CA Common Services tape, see the CA Service Desk
Integration documentation.
The CAISDI/soap started task must be running on at least one z/OS image. The image must be
accessible to the image where CA Workload Automation CA 7 Edition is executing using CAICCI. In
other words, there must be a CAICCI connection between the system where CA Workload
Automation CA 7 Edition is executing and the system where CAISDI/soap is executing. If CAISDI/soap
is executing on the same system with CA Workload Automation CA 7 Edition, no CAICCI connection is
necessary.
CA Workload Automation CA 7 Edition provides an event library for CAISDI/els. The default name of
this library is CAI.CAL2EVNT.
Event library member AL2CNTL is named the control member. The control member can require some
customization for some shops, but is probably sufficient for most CA Workload Automation CA 7
Edition sites.
The remaining members in the event library are CAISDI/els events.
We recommend against changing any of the event members that are provided with CA Workload
Automation CA 7 Edition. If your site must tailor an event, copy the event member to another name
and change the copy.
Event member names have the format xxxxxxnn where xxxxxx is the six-character CAISDI/els event
name, and nn is the language. For example, CAISDI/els event ABEND2 for English is named
ABEND2EN.
Each event member is divided into three sections: summary, description, and options. The summary
section contains a one-line problem description. The description section contains a lengthy HTML-
formatted description of the problem. The final section, options, specifies the priority (severity) of
the problem.
The summary and description sections can contain variables that CA Workload Automation CA 7
Edition fills. For example, a job completion event in CA Workload Automation CA 7 Edition provides
variables for the job name, JES number, completion code, and others. For a complete list of the
variables available, see the topic Event Variables.
After each IPL or change to the event library, CAISDI/els must load the event library on the system
where CA Workload Automation CA 7 Edition is executing. The CAISDI/els CASDIELS procedure does
the load. The CASDIELS define statement for CA Workload Automation CA 7 Edition looks like the
following example:
define product=CA-7,eventlib=cai.CAL2EVNT,prodcntl=al2cntl
08-Feb-2018 60/722
Case does not matter on the define statement. Spell "CA-7" and "al2cntl" exactly as shown. Specify
the event library name.
Configure CA Service Desk For CA Workload Automation CA 7 Edition

The control member in the event library (member AL2CNTL) contains contact and asset names.
Define these names to CA Service Desk, or set the appropriate options in CA Service Desk to permit
the dynamic adding of contacts and asset names.
Read the comments in the control member and the CA Service Desk documentation for more
information.
Configure CA Workload Automation CA 7 Edition

The SERVICEDESK initialization file statement activates the CA Service Desk interface. SERVICEDESK
has no keywords.
When CA Workload Automation CA 7 Edition finds the SERVICEDESK initialization file statement, it
reads filtering rules from the SERVDESK DD statement. The filtering rules control when to create a CA
Service Desk request. For example, the rules can indicate to open requests for job names that start
with PAY and that abend.
CA Workload Automation CA 7 Edition writes the CA Service Desk request number that was opened
to the SERVLOG DD statement. Verify that SERVLOG is a SYSOUT file that is allocated to the CA
Workload Automation CA 7 Edition started task.
CAISDI/els Events Provided By CA Workload Automation CA 7 Edition

CA Workload Automation CA 7 Edition uses CAISDI/els events to create requests in CA Service Desk.
In addition to the text (contents) of the request, the events also control the formatting and priority of
the request.
CA Workload Automation CA 7 Edition provides events with and without the HTML formatting for the
description. Using the HTML formatting can require that you change installation options in CA Service
Desk.
Events that start with @ do not use the HTML formatting. Events that do not start with @ do use the
HTML formatting.
CA Workload Automation CA 7 Edition provides the following CAISDI/els events:
Name Name with Intended Use

without HTML
HTML Formatting
Formatting
@ABND1EN ABEND1EN Job completions where the job has abended. Event names ending in 1EN
@ABND2EN ABEND2EN create priority 1 requests, ending in 2EN create priority 2 requests, and
@ABND3EN ABEND3EN so on
08-Feb-2018 61/722
Name Name with Intended Use

without HTML
HTML Formatting
Formatting
@FAIL1EN FAILD1EN Job completions where the job has ended with an unacceptable return
@FAIL2EN FAILD2EN code. Event names ending in 1EN create priority 1 requests, ended in
@FAIL3EN FAILD3EN 2EN create priority 2 requests, and so on
@QFUL1EN QFULL1EN One of the CA Workload Automation CA 7 Edition queues (scratch or
DQTABLE) is at or above 80 percent full. This event creates a priority 1
request.
You can create any number of extra CAISDI/els events at your site by adding extra members to the
event library.
SERVDESK Rules
The SERVDESK DD statement points to an FB 80 data set containing the rules for when CA Workload
Automation CA 7 Edition creates requests in CA Service Desk. The SERVDESK rules are read at CA
Workload Automation CA 7 Edition startup when the SERVICEDESK initialization file statement is
processed. The rules are then stored in memory. The SERVDESK rules can be refreshed without
restarting CA Workload Automation CA 7 Edition by using the /REFRESH,MOD=SERVDESK command.
The /DISPLAY,ST=SDESK command can be used to display the currently active SERVDESK rules.
SERVDESK rules start in column one and have the following general syntax:
type,keyword=value,keyword=value
Rules can continue after any "keyword=value," and can start again in any column.
The following types are valid:
JOBCOMP
Job completion. All CA Workload Automation CA 7 Edition job completions are compared against
JOBCOMP rules to determine whether to open a request. All completions include job abends, job
condition code failures, normal (successful) completions, and "force completes."
Note: Nonexecutable jobs and "force completes" are treated as zero return code
completions (C-C0000). Also, cross-platform jobs (CA7TOUNI) are not evaluated when the
MVS submit execution of the CA7TOUNI step is successful. In that case, the completion
code reflects the return code that the cross-platform target node returned.
QFULL
Queue full. QFULL rules are evaluated when the message CA-7.306 is issued (CA-7.306 - **
WARNING ** 80% xxxxxxx QUEUE UTILIZATION ** WARNING **).
The following keywords can be included on SERVDESK rules (not all keywords are valid for all rule
types):
08-Feb-2018 62/722
ARFOVER=
Specifies whether an ARF job completion definition takes precedence in determining whether to
open a Service Desk incident ticket.
NO
Opens a Service Desk issue assuming that the job completion condition matches the
JOBCOMP COMP= setting. This value is the default when ARFOVER is not supplied.
YES
Does not open a Service Desk issue assuming that the ARFSET JC definition ID matches the
completion code of the job.
ATIME=, BTIME=
Specifies after and before times used for all rule types. If the after time is less than the before
time, then the event (that is, job completion) must occur between the two times. If the after time
is greater than the before time, the event must occur outside of the time range.
ATIME Default: 0000
BTIME Default: 2359.
COMP=
Specifies a required completion code or completion code mask that is used for JOBCOMP rules.
The completion code uses the same format as seen on the LQ command (that is, an S806 abend
would be "A-S806"). COMP= is required on JOBCOMP rules.
A value of FAILED can be used to match any code that is not a successful completion. For
example, COMP=FAILED matches any abend, bad return code, or JCL error.
EVENT=
(Required for all rule types) Specifies the first six characters of the member name of the
CAL2EVNT library that creates the request in CA Service Desk. The CAISDI/els event determines
the priority of the request in CA Service Desk.
JOB=
Specifies a job name or job name mask that is used for JOBCOMP rules for matching job
completion events in CA Workload Automation CA 7 Edition. JOB= defaults to *.
QUEUE=
Specifies a queue name or queue name mask that is used for QFULL rules. See message CA-7.306
for the queue names that can be specified.
SYSTEM=
Specifies a system name or system name mask that is used for JOBCOMP rules. SYSTEM defaults
to *.
A CA Workload Automation CA 7 Edition event must match all of the keywords on a rule before a
request is opened in CA Service Desk. If multiple rules would match an event, then the first rule is
used.
Masking
Any of the maskable fields in the rules (such as JOB, COMP) can use the wildcard characters "*" and
"?". The asterisk "*" can be used to match any number of characters, including zero characters. The
question mark "?" can be used to match any nonblank character.
08-Feb-2018 63/722
Use any number of asterisks and question marks in any combination in any of the SERVDESK fields
that accept masks.
Example SERVDESK Rules
This example creates a priority 1 request if any job that starts with PAY abends:
JOBCOMP,JOB=PAY*,COMP=A*,EVENT=ABEND1
This example creates a priority 2 request for any job in the ACCT system that abends or gets a bad
return code:
JOBCOMP,SYSTEM=ACCT,COMP=A*,EVENT=ABEND2
JOBCOMP,SYSTEM=ACCT,COMP=R*,EVENT=FAILD2
This example creates a request for abending jobs with an X in column 3 and that end in $ and is in the
BILLING system. If the abend occurs during the day, use priority 2, otherwise use priority 1.
JOBCOMP,JOB=??X*$,SYSTEM=BILLING,ATIME=0800,BTIME=1700,
COMP=A*,EVENT=ABEND2
JOBCOMP,JOB=??X*$,SYSTEM=BILLING,COMP=A*,EVENT=ABEND1
Note: The second JOBCOMP rule does not need the ATIME and BTIME fields. The second
rule is only examined when the first rule did not match the job completion.
This example creates a priority 1 request when a job that starts with PAY* abends. Job PAYOK does
not generate a request when the appropriate ARFSET JC definition is linked to the job.
JOBCOMP,JOB=PAYOK,COMP=A*,EVENT=ABEND1,ARFOVER=YES
JOBCOMP,JOB=PAY*,COMP=A*,EVENT=ABEND1
Event Variables
The CAISDI/els events that CA Workload Automation CA 7 Edition uses to create requests in CA
Service Desk can contain variables. Variables start with an ampersand (&) and are in uppercase.
When the values are substituted into the CAISDI/els events, any trailing blanks are dropped.
The following variables are available. Not all variables are available for all CA Workload Automation
CA 7 Edition event types.
Variable CA Workload Automation CA Description

7 Edition Event Types
&CA7N ALL The value of the PRODNAME keyword in the AL2CNTL
AME member of CAL2EVNT
&DLDAT JOBCOMP Deadline date
E
&DLTIM JOBCOMP Deadline time
E
&DODA JOBCOMP Due out date
TE
08-Feb-2018 64/722

&DOTI JOBCOMP Due out time
ME
&EDATE JOBCOMP End date
&ENTRY JOBCOMP Entry mode of the job (demanded, auto, sscan)
MOD
&ETIME JOBCOMP End time
&EVENT ALL Name of CAL2EVNT member
&EXEC JOBCOMP EXEC flag
&EXSYS JOBCOMP Execution system SYSID (is 7UNI for cross-platform jobs,
7XPJ for XPJOB jobs, and AGJ for agent jobs)
&INSTA All CA 7 instance name (that is, CA71)
NCE
&JESNU JOBCOMP JES number (can be *NA* for force complete and cross-
M platform jobs)
&JOB JOBCOMP Name of the job
&JOBL JOBCOMP Long name of the job
&JQUSE JOBCOMP Contents of the JQUSER field
R
&MAIN JOBCOMP MAINT flag
T
&NL All Single Enter key (new line)
&NUM JOBCOMP CA 7 job number
&P All Double Enter key
&QUEU QFULL Name of the queue that is 80 percent full
E
&RESTA JOBCOMP Number of times job has been restarted.
RTS
&SCHDI JOBCOMP Schedule ID
D
&SDATE JOBCOMP Start date
&STAT8 JOBCOMP The 8-byte status of the job, as seen on the LQ command
&STAT8 JOBCOMP A longer, user-friendly, status of the job
0
&STIME JOBCOMP Start time
&SUBD JOBCOMP Submission date
ATE
&SUBTI JOBCOMP Submission time
ME
&SYSDA All Current date in format MM/DD/YYYY
TE
08-Feb-2018 65/722

&SYSED All Current date in format DD/MMM/YYYY
ATE
&SYSID All SMF ID where CA 7 is executing.
&SYSTE JOBCOMP System of the job
M
&SYSTI All Current time
ME
&SYSJO All Name of the CA 7 task
B
Interface with CA WA Restart Option for z/OS Schedulers

The interface with CA Workload Automation Restart Option for z/OS Schedulers works in the
following ways:
ARTS Command Monitor (see page 67)

Automatic RMS Step Insertion (see page 67)
Automatic CMT Updating (see page 68)
Condition Code Synchronization (see page 69)
The CA Workload Automation Restart Option for z/OS Schedulers interface is included automatically
during the installation of the CA Workload Automation CA 7® Edition base product.
Note: A separate FMID is no longer required for the interface. Sites no longer must
assemble the interface at APPLY time.
The CA Workload Automation Restart Option for z/OS Schedulers interface is delivered already
assembled. If a future release of CA Workload Automation Restart Option for z/OS Schedulers
requires a reassembly of the interface, you can use CAL2OPTN member AL2UM43.
Add the following statements to the initialization file before the APPLCTN statement for SASSPROG:
APPLCTN,NAME=SASSRMS1,ATTR=PERM
APPLCTN,NAME=SASSRMS2,ATTR=PERM
The CA Workload Automation Restart Option for z/OS Schedulers load library must be concatenated
to the CA Workload Automation CA 7® Edition STEPLIB or in a linklist because CA Workload
Automation Restart Option for z/OS Schedulers modules perform part of the interface.
The following initialization file statement is required to turn on the CA Workload Automation Restart
Option for z/OS Schedulers interface:
RESTART,RMS=YES
08-Feb-2018 66/722
ARTS Command Monitor

CA Workload Automation CA 7® Edition supports the CA Workload Automation Restart Option for z
/OS Schedulers ARTS interface with the ARTS top line command. This support allows use of online
tracking and maintenance of restart/rerun information as described in CA Workload Automation
Restart Option for z/OS Schedulers documentation. The ARTS interface is similar to the TIQ interface.
The monitor mode is entered, and the MONLIM value from the TERM statement in the initialization
file can limit it.
Note: CA Workload Automation CA 7® Edition has no batch interface to CA Workload

Automation Restart Option for z/OS Schedulers.
The CA Workload Automation CA 7® Edition OPID is passed to CA Workload Automation Restart

Option for z/OS Schedulers as a password. If it is not defined to the CA Workload Automation Restart
Option for z/OS Schedulers Security module, a message appears, and a different CA Workload
Automation Restart Option for z/OS Schedulers password can be entered.
Messages and Codes (https://wiki.ca.com/display/CWAC7E/Messages+and+Codes) contains messages that

the CA Workload Automation CA 7® Edition ARTS interface produces. The CA Workload Automation
Restart Option for z/OS Schedulers documentation contains its messages.
The format of the ARTS command is as follows:

ARTS
No parameters are entered with this command. If you want to use the HELP feature of this command,
include the CA11HELP DD statement in your CA Workload Automation CA 7® Edition startup
procedure. Point it to the CA Workload Automation Restart Option for z/OS Schedulers help data set.
When the ARTS command monitor is used, increase the CWORK execution parameter for CA
Workload Automation CA 7® Edition by a count of 20 for each concurrent ARTS session through CA
Workload Automation CA 7® Edition. If CA Workload Automation CA 7® Edition is being run in a large
enough region, CWORK does not always require adjusting. Typically, five or fewer interfaces are
concurrent even in large terminal networks. However, because CWORK reduces the external storage
available to other CA Workload Automation CA 7® Edition interfaces, it is sometimes better to
increase region size.
When issuing CA Workload Automation Restart Option for z/OS Schedulers commands with multiple
panels of output, it is necessary to retype the first letter of the command (or a blank) before pressing
Enter to view secondary panels.
Automatic RMS Step Insertion

For jobs that CA Workload Automation CA 7® Edition submits, a job-level option can cause the
insertion of a CA Workload Automation Restart Option for z/OS Schedulers RMS procedure in the JCL
of the job. The default procedure name inserted depends on the release level of CA Workload
Automation CA 7® Edition. You can change the procedure name by using the PROCRMS parameter of
the RESTART statement in the initialization file. (You can find a sample RMS PROC in the CA Workload
Automation Restart Option for z/OS Schedulers SAMPJCL data set as member CA11RMS.)
When CA Workload Automation CA 7® Edition inserts the RMS procedure, the parameter that is
08-Feb-2018 67/722
When CA Workload Automation CA 7® Edition inserts the RMS procedure, the parameter that is
passed is determined as follows:
If restart data is present in the JCL as part of the //*UCC7RESTART statement, the restart data is
passed as the parameter.
If you have no restart data for //*UCC7RESTART, the parameter is set to P unless Load processing
is needed.
If you have no restart data and Load processing is needed, the parameter is set to F.
This parameter can be overridden by using the PARMRMS parameter of the RESTART statement in
the initialization file.
To request an automatic RMS step insertion for a job, set the INSERT-RMS field on the DB.1 panel to
Y. If CA Workload Automation Restart Option for z/OS Schedulers is not installed, the insert feature is
not active regardless of the INSERT-RMS field on the DB.1 panel.
Note: If IBM OS Restart (JOB statement RESTART parameter) is used, it is possible that the
RMS step inserted by CA Workload Automation CA 7® Edition is bypassed. This bypass
could result in various problems depending on the steps that are not executed: possible
abends, loss of data, loss of data set postings, and so on.
Automatic CMT Updating

Assume that CA Workload Automation Restart Option for z/OS Schedulers is available and jobs are
restarted, forced completed, or canceled through CA Workload Automation CA 7® Edition. In this
case, the Catalog Management Table (CMT) is updated automatically. If CA Workload Automation CA
7® Edition NCF is installed, then, for jobs that are executed at nonlocal NCF nodes, CMT updating
cannot occur and the //*UCC7RESTART statement passes the restart data.
When a job is resubmitted, force completed, or canceled, the interface attempts to clear the CMT
flags. When a job is restarted, the interface posts the restart data to the CMT then sets the restart
data to P. If the QM.4 panel SET PARM field is used, the CMT is not accessed. The PARM data is
passed using the //*UCC7RESTART statement.
The CA Workload Automation CA 7® Edition commands that cause CMT updating are CANCEL,
RESTART, XQ function C or F, and XRST.
Note: For more information, see the CA Workload Automation Restart Option for z/OS
Schedulers documentation.
08-Feb-2018 68/722
Condition Code Synchronization

The enhanced CA Workload Automation Restart Option for z/OS Schedulers interface synchronizes
job success/failure criteria between the two products. This synchronization lets CA Workload
Automation CA 7® Edition control restart processing for jobs under its control, as opposed to the
operating system and CA Workload Automation Restart Option for z/OS Schedulers database. In
other words, CA Workload Automation CA 7® Edition informs CA Workload Automation Restart
Option for z/OS Schedulers of the restart step (ignoring the CA Workload Automation Restart Option
for z/OS Schedulers HIRTCD), but CA Workload Automation Restart Option for z/OS Schedulers still
determines the appropriate step in which to restart the job.
In addition, this enhancement lets CA Workload Automation CA 7® Edition tell CA Workload

Automation Restart Option for z/OS Schedulers the JESNODE where the job ran and the CA Workload
Automation Restart Option for z/OS Schedulers subsystem that controls the job, leading to greater
accuracy for job restarts.
By default, this feature is not enabled. Sites wanting to take advantage of this feature must set the
RESTART statement (https://wiki.ca.com/display/CWAC7E/RESTART+Statement) keyword CONDCHK to YES
in the initialization file. Sites must also be running CA Workload Automation Restart Option for z/OS
Schedulers r11.0 or newer, as older CA Workload Automation Restart Option for z/OS Schedulers
releases do not support this feature.
This feature is best exploited by using CA Workload Automation CA 7® Edition #SCC statements to
handle condition code checking of a job.
CA Workload Automation CA 7® Edition now captures the JES node where a job executes and the CA
Workload Automation Restart Option for z/OS Schedulers subsystem that tracks the job. This
information is passed back to CA Workload Automation Restart Option for z/OS Schedulers when a
job is restarted, forced complete, or canceled. CA Workload Automation Restart Option for z/OS
Schedulers can use this information to determine what CMT to update and where it is located. If this
type of processing is desired, configure CA Workload Automation Restart Option for z/OS Schedulers
to support NJE requests for job restarts across remote JES nodes. This configuration can require
implementing the CA Generalized Transaction Server (CA GTS).
Note: For more information, see the CA Workload Automation Restart Option for z/OS
Schedulers documentation.
Interface with Critical Path Monitoring

CA Workload Automation CA 7® Edition can interface with Critical Path Monitoring (CPM). Large
production workloads can be difficult to manage without monitoring tools that afford integrated
views of key segments of the workload. CPM provides tools that can be used for this purpose. CA
Workload Automation CA 7® Edition can report on the status of jobs within key workload segments.
This information can be used to track the progress of critical production job streams, "critical paths."
Two tools can be used to track and display CA Workload Automation CA 7 Edition critical path
information:
08-Feb-2018 69/722
CA OPS/MVS® Event Management and Automation® Event Management can work with other CA
solutions to track and graphically display the status of CA Workload Automation CA 7 Edition
critical paths. These solutions are not provided as part of the CA Workload Automation CA 7
Edition installation package. For more information about this option, see the CA OPS/MVS® Event
Management and Automation documentation.
CA CPM is supplied as part of the CA Workload Automation CA 7 Edition installation package. You
can use it to track CA Workload Automation CA 7 Edition critical paths and to display critical path
information in text-based formats on the ISPF panels.
Note: An old release of CA CPM, Version 3, works with current versions. The enhanced
CPM=JFM interface requires versions starting with CA Workload Automation CA 7 Edition
r11.3. We recommend that you upgrade to the current release of CA CPM because the
latest releases of CA CPM and CA Workload Automation CA 7 Edition products are installed
into the same SMP/E CSI.
More information:
Use CA CPM (https://wiki.ca.com/display/CWAC7E/Use+CA+CPM)
Critical Path Definition

The definition of CA Workload Automation CA 7 Edition critical paths and the creation of critical path
events by CA Workload Automation CA 7 Edition are the same regardless of which CPM tracking tool
is used. Unless otherwise noted, the following description of Critical Path Monitoring applies to either
tracking method that is referred to generically as the "CPM Tracker."
Within CA Workload Automation CA 7 Edition, a named segment of a triggered stream of jobs is

known as a FLOW. The following elements are required for FLOW definition:
The name of the FLOW.
The name and schedule ID of the starting job.
The name and schedule ID of the ending job.
The expected completion time of the ending job (Service Level Agreement, or SLA time) or the
expected maximum length of time for the FLOW to complete.
A FLOW initiates when VRM resources are attached to the starting job and terminates when its
ending job completes successfully. CA Workload Automation CA 7 Edition considers an active FLOW
to include the beginning job and all of its job and data set triggered descendants up to and including
the ending job. When CPM=YES is used, the CA Workload Automation CA 7 Edition command FLOWL
can be used to display active FLOWs in CA Workload Automation CA 7 Edition.
08-Feb-2018 70/722
CA Workload Automation CA 7 Edition uses CAIENF to report status information for all FLOW jobs to
the CPM Tracker. When CA Workload Automation CA 7 Edition notifies the CPM Tracker that a FLOW
has begun, the CPM Tracker requests forecast information from CA Workload Automation CA 7
Edition. With this information, CA Workload Automation CA 7 Edition charts the "critical path" that
connects the FLOWs beginning and ending jobs. The CPM Tracker then uses the CA Workload
Automation CA 7 Edition ongoing status information to monitor the progress of the critical path.
FLOW initiation occurs at job submission as part of the VRM resource evaluation process. This
initiation implies a restriction on defining the starting job in a FLOW. A job must be eligible to use
VRM resources to initiate a FLOW. This means that a nonexecutable job cannot start a FLOW.
However, nonexecutable jobs can be included in a FLOW and can be defined as the ending job of a
FLOW.
Note: If flows are not properly defined, active flows can become stranded. For example, if
the specified ending job is no longer in the trigger flow, all related jobs can complete
without finding the end of flow. Also, if a job in the critical trigger path is canceled, the flow
never recognizes the ending job. Current releases of CA Workload Automation CA 7 Edition
automatically delete active flows when there are no longer any jobs connected to it (see
Message CAL2P099W). When using CPM=YES, periodically issue a FLOWL command and
check for active flows that have not completed as expected. Use the FLOWD command to
delete them because active flows take up memory in the CA Workload Automation CA 7
Edition address space. When CPM=JFM, FLOWL and FLOWD are inactive, and flows are only
monitored in CPM. Incompleted flows can be canceled from CPM.
CPM Requirements
You can activate CPM=YES functionality for CA Workload Automation CA 7 Edition.
Enable CPM in the CA Workload Automation CA 7 Edition initialization file options.

The CA Workload Automation CA 7 Edition CPM interface is activated at CA Workload Automation
CA 7 Edition startup when CPM=YES is coded on the OPTIONS statement in the CA Workload
Automation CA 7 Edition initialization file. When active, this interface provides services that can
be used to define those portions of the triggered workload that require special management
attention using CPM. These services can define the limits of a key segment of the triggering
stream. These services can assign a name to the segment for subsequent references in the CPM
environment.
Enable the CA Workload Automation CA 7 Edition CAICCI interface in the CA Workload

Automation CA 7 Edition initialization file options.
The CA Workload Automation CA 7 Edition CAICCI Interface extracts information from CA
Workload Automation CA 7 Edition for the CPM Server to build an image of a critical path. At least
one CA Workload Automation CA 7 Edition CAICCI terminal must be defined in the CA Workload
Automation CA 7 Edition initialization file.
Tailor the CPM Server JCL.

If you are using Critical Path Monitor r11 or Version 3, the CPM Server JCL is the CPMSRVR started
task JCL. The CPM Server must have access to the CA Workload Automation CA 7 Edition load
library. If the library is not in the LNKLST or LPALIB, add them to the OSF server's STEPLIB DD.
Optionally, you may need to add a CA7PARMS DD statement to the CPM Server JCL to set the
parameters that the CA Workload Automation CA 7 Edition CAICCI interface uses to gather
08-Feb-2018 71/722
parameters that the CA Workload Automation CA 7 Edition CAICCI interface uses to gather
information about active flows. If specified, the CA7PARMS DD must point to an 80-byte card-
image data set or PDS member.
More information:
Interface with CAICCI (https://wiki.ca.com/display/CWAC7E/Interface+with+CAICCI)
CPM Requirements with JFM

You can activate CPM=JFMLOAD (Jobflow Monitor) functionality for CA Workload Automation CA 7
Edition.
Enable CPM in the CA Workload Automation CA 7 Edition initialization file options.

When CPM=JFMLOAD is coded on the OPTIONS statement in the initialization file, the same
critical paths can be tracked using CA CPM. The same critical path resource definitions (RM.1) are
used for either CPM=YES or CPM=JFMLOAD.
CPM collects path information from Jobflow Monitor using TCP/IP. JFM creates a name-token pair
to provide the port number for CPM to send a request for each flow.
Tailor the CPM Server JCL.

If you are using Critical Path Monitor r11 or Version 3, the CPM Server JCL is the CPMSRVR started
task JCL. The CPM Server must have access to the CA Workload Automation CA 7 Edition load
library. If the library is not in the LNKLST or LPALIB, add it to the CPMSRVR STEPLIB DD.
The CA7PARMS DD is not required when using CPM=JFMLOAD. Only three of the parameters are
used for CPM=JFMLOAD flows: CA7SNAP, CA7DBUG, and CA7TIME.
CA7PARMS keywords must start in column 1 with no embedded blanks. Lines that begin with a blank
or asterisk are considered comment lines. The following lists keywords and their defaults:
CA7NODE=
Specifies the CAICCI node where CA Workload Automation CA 7 Edition resides. The default is
local node.
CA7SSCT=
Specifies the CA Workload Automation CA 7 Edition instance name (CA71, CA72, and so forth).
The default is CA71.
CA7USER=
Specifies the user ID to log in to CA Workload Automation CA 7 Edition with. The default is CPM
Server user ID.
CA7PSWD=
Specifies the user ID password. No default.
CA7SNAP=
Specifies the ddname for the trace snaps. The default is CA7TRACE.
CA7TIME=
08-Feb-2018 72/722
CA7TIME=
Specifies the timeout in seconds for TCP/IP activity with JFM. The default is 10 seconds.
CA7DBUG=
Specifies the debug/trace options as follows:
0
Suppresses trace.
1
CPMF WTO trace only.
2
CPMF and CAICCI interface WTO trace only.
3
CPMF WTO trace and CPMF snap trace only.
4
CPMF and CAICCI interface WTO and CMPF snap trace (full).
The parameter has no default.

If you want to use one of the snap trace options, add a CA7TRACE SYSOUT DD to the JCL.
If a CA Workload Automation CA 7 Edition user ID is not specified in the CPM Server or in
CA7PARMS, the user ID under which the CPM Server task itself is running is used to log in to CA
Workload Automation CA 7 Edition. Regardless of the source, the CA Workload Automation CA 7
Edition user ID used by the CPM Server requires authority to issue FJOB, FLOWL, FQJOB, FRJOB,
LQ, and LRLOG CA Workload Automation CA 7 Edition commands and having CA Workload
Automation CA 7 Edition UID access to all jobs in the critical path flows.
CPM and CAIENF Maintenance

JFM installation includes new CAIENF event types.
After the CAIENF database maintenance is applied, CPM does not initialize with CAIENF when the
CPM checkpoint database has retained old data.
When this retention occurs, an error message is issued:
CPM1015F Unexpected return code (8) from ENF INIT - terminating
To let CPM initialize with CAIENF, add the following setting to the CPMOPTS member of the OPTLIB
data set:
set Restarttime=0000000000000
This setting can remain in CPMOPTS with no effect on flow monitoring.
08-Feb-2018 73/722
Interface with IBM Automated Restart Management

CA Workload Automation CA 7® Edition can interface with the IBM Automated Restart Management
(ARM) service. ARM can restart failed tasks without operator intervention to provide improved
program availability. The restart can reduce the impact when unexpected errors occur. Now,
interfaces to ARM for the CA 7 online, ICOM, and NCF tasks are provided.
ARM can restart a task after an abend when your site has activated a policy through the SETXCF
START command. This policy can be the IBM default policy or a site-written policy. For more
information about setting up ARM, see MVS Setting Up a Sysplex in the IBM dooumentation.
You can use the following MVS command to display information about tasks that have registered for
services of ARM:
D XCF,ARMSTATUS
The CA 7 online, ICOM, and NCF tasks can register with ARM. They register when their associated
initialization options are set to enable the ARM interface. If the task, and sometimes, the system,
fails, ARM can then restart the task. ARM does not restart a task when it fails as the result of a
CANCEL or FORCE command unless specific options are used on the command to request the restart.
The CA Workload Automation CA 7® Edition ARM element names are CA7yyy_ssssxxxx. The yyy is a
task identifier (ONL/ICM/NCF), ssss is the SMF ID, and xxxx is the CA 7 instance name.
ARM can perform two types of restarts.
A started task or job fails.

ARM restarts the started task or job on the same LPAR.
The LPAR where the started task or job was running fails.
ARM restarts the started task or job on another LPAR in the sysplex.
By default, the CA 7 online task registers for both restart types. ICOM and NCF tasks only registers for
the first type of restart.
The following control the ARM interface:
CA 7 online
Contains the initialization file statement: STATEMGR,ARM=YES|NO
ICOM
Accepts the EXEC PARM: ARM=YES|NO
NCF
Accepts the EXEC PARM: ARM=YES|NO
If the primary CA 7 online task is using ARM for automatic restarts, a secondary, dormant CA 7 copy is
unnecessary. Do not start one. If a CA 7 online task is started with TYPE=DORM with an initialization
file statement STATEMGR,ARM=YES, a user abend occurs. The dormant task fails.
08-Feb-2018 74/722
The following example includes sample CA Workload Automation CA 7® Edition definitions within an
ARM policy:
RESTART_GROUP(CA7)
TARGET_SYSTEM(SYS1,SYS3)
ELEMENT(CA7ONL)
RESTART_ATTEMPTS(3,300)
RESTART_TIMEOUT(300)
READY_TIMEOUT(300)
TERMTYPE(ALLTERM)
ELEMENT(ICOM)
READY_TIMEOUT(300)
TERMTYPE(ELEMTERM)
ELEMENT(NCF)
READY_TIMEOUT(300)
TERMTYPE(ELEMTERM)
Interface with IBM Health Checker for z/OS

CA Workload Automation CA 7® Edition can interface with the IBM Health Checker for z/OS. This
checker provides a central location for IBM and other vendors, such as CA Technologies, to scan the z
/OS system for potential problems. IBM Health Checker reports on its findings and suggests possible
actions to take. IBM Health Checker for z/OS runs in a separate started task, named HZSPROC in the
IBM documentation. This task includes many individual checks. The checks can run either local (in the
IBM Health Checker for z/OS address space) or remote (in the address space of the calling program).
The checks for CA Workload Automation CA 7® Edition are local checks.
The interface to IBM Health Checker for z/OS monitors the availability of the CA 7 online and ICOM
tasks at a user-specified interval. In addition, for the online task, it verifies that activity has taken
place after the previous check iteration.
A new CAIRIM L2OPTS HEALTHCHECK keyword on the GLOBAL INIT/INITC/UPDATE statement

controls this check.
The CA Workload Automation CA 7® Edition check routines execute every nn minutes as defined by
the CAIRIM HEALTHCHECK keyword.
If a value of zero is specified for an interval, the check is defined to IBM Health Checker but not
scheduled (it is made inactive). You can run the check manually whenever you prefer. See the sample
operator commands that follow.
Most messages regarding the state of the check routines or of CA Workload Automation CA 7®
Edition itself are issued from the IBM Health Checker for z/OS started task, not from the CA Workload
Automation CA 7® Edition started task (or tasks).
Each LPAR has only one Health Checker address space. The checks are reporting on all eligible CA 7
online and ICOM tasks on that LPAR. It is looking for an ICOM task for each defined CA Workload
Automation CA 7® Edition tracking instance, regardless of release level. For online tasks, it examines
all defined tracking instances where a CA Workload Automation CA 7® Edition r11.3 or higher task
has been started.
08-Feb-2018 75/722
The CA Workload Automation CA 7® Edition load library must be available to the IBM Health Checker
for z/OS started task either as part of the linklist or as a STEPLIB. If the load library is not part of the
linklist, copy the exit routine, CAL2HCXT, to a linklist library. CAL2JCL member AL2HCKCP can perform
this copy.
If the IBM Health Checker for z/OS address space is cycled while CA Workload Automation CA 7®
Edition is up, perform a CAIRIM GLOBAL UPDATE HEALTHCHECK(nn) or GLOBAL REFRESH to redefine
the checks to IBM Health Checker for z/OS.
Information about IBM Health Checker for z/OS check routines is most easily displayed using SDSF
using the CK command or through the CA SYSVIEW® Performance Management HC command.
Information can also be displayed using operator commands to the IBM Health Checker started task
(usually HZSPROC).
The following command displays all CA Workload Automation CA 7® Edition check routines:
F HZSPROC,DISPLAY,CHECK(CA_7,*),DETAIL
The following command manually executes all CA Workload Automation CA 7® Edition check
routines:
F HZSPROC,RUN,CHECK(CA_7,*)
Note: For more information about more commands, see the IBM Health Checker for z/OS
user documentation.
All IBM Health Checker for z/OS check routines have an owner, a name, and a reason. The owner of
the CA Workload Automation CA 7® Edition check routines is "CA_7." The checks have the following
names and reasons:
CA7_ONLINE_ACTIVE_TASKS
Confirm the availability for CA 7 online tasks.
CA7_ICOM_ACTIVE_TASKS
Confirm the availability for ICOM tasks.
Interface with IBM Workload Manager (WLM)

IBM Workload Management services (WLM) enable installations to manage workload distribution,
transaction balancing, and resource distribution in z/OS environments. WLM allows the specification
of policies to control the distribution of workloads throughout a sysplex. While used primarily to
control and manage online transaction workloads, such as CICS user transactions, WLM also has
features that you can use to help manage batch workloads.
08-Feb-2018 76/722
CA Workload Automation CA 7® Edition provides interfaces that help you to use IBM WLM to treat CA
Workload Automation CA 7 Edition and its Independent Communications Manager (ICOM) as WLM
resources. CA Workload Automation CA 7 Edition also provides features that help you use WLM
scheduling environments to manage your batch workload. Use these interfaces separately or
concurrently based on your processing requirements.
Working with ICOM and IBM Workload Manager Resources

A provided interface helps you use IBM WLM to treat CA Workload Automation CA 7® Edition and its
Independent Communications Manager (ICOM) as WLM resources. You can group WLM resources
into scheduling environments. Scheduling environments let you manage the scheduling of tasks in a
sysplex where different hardware or software applications are available on each system.
The resources that make up scheduling environments are defined to the IBM Workload Manager.
They can represent something physical such as a hardware device. They can represent the presence
of a software application such as DB2. Or, they can represent something intangible, such as a day of
the week. MVS or JES operator commands can set WLM resource states. Interface calls to WLM by
software applications can also set them.
You can assign IBM WLM resource names to the CA 7 online started task and the Independent
Communications Manager (ICOM) started task. When specified CA Workload Automation CA 7
Edition, ICOM, or both call the IBM Workload Manager to set the state of the designated resource to
ON when the started task is initiated. When the started task terminates, a call is made to set the
state of the resource to OFF.
One possible use of these resources is to control which MVS images CA Workload Automation CA 7
Edition Batch Terminal Interface (BTI) jobs are directed to. Because these jobs require the same CA
Workload Automation CA 7 Edition system interfaces as ICOM, you could use an IBM WLM scheduling
environment to verify that these jobs are only directed to images where ICOM is running.
You can assign an IBM WLM resource name to the CA Workload Automation CA 7 Edition started
task. See the documentation for the WLMCA7 keyword on the initialization file OPTIONS statement (
https://wiki.ca.com/display/CWAC7E/OPTIONS+Statement).
You can assign an IBM WLM resource name to the ICOM started task. See the documentation for
ICOM Execution (https://wiki.ca.com/display/CWAC7E/ICOM+Execution).
Automatic Scheduling Environment JOB Statement Insertion

Several features are provided that can facilitate your use of IBM WLM scheduling environments to
manage your batch workload. A scheduling environment is a list of WLM resource names and their
required states (ON, OFF, or RESET). Scheduling environments let you manage the scheduling of tasks
in a sysplex where differences exist in the hardware or software applications available on each
system. If an MVS image matches the scheduling environment requirements, that task can be routed
to that system.
Through CA Workload Automation CA 7 Edition Virtual Resource Management (VRM) definitions, you
can assign IBM WLM scheduling environments to individual jobs and have CA Workload Automation
CA 7 Edition automatically add the appropriate SCHENV keyword at job submission time. These VRM
definitions use the variable (VAR) resource type and can be associated based on CA Workload
Automation CA 7 Edition schedule ID.
Also, CA Workload Automation CA 7 Edition can optionally validate the specified scheduling
08-Feb-2018 77/722
Also, CA Workload Automation CA 7 Edition can optionally validate the specified scheduling
environment with the current IBM WLM policy before job submission. This validation avoids
preexecution JCL errors. JCL errors occur when a SCHENV keyword is specified with a scheduling
environment that is not defined in the current IBM WLM policy.
You can activate the insertion and validation of scheduling environments in CA Workload Automation
CA 7 Edition. For more information, see the WLMSE and WLMSEVAL keywords in the initialization file
OPTIONS statement.
To create Virtual Resource Management (VRM) definitions to associate scheduling environments with
individual jobs, see VRM Variable Definitions.
Problem Management Interface

Transactions for a problem management interface can be issued dynamically in response to CA
Workload Automation CA 7 Edition job completions using the real-time CA 7 Problem Management
Interface. When CA Workload Automation CA 7 Edition detects a job completion, one or more
Problem Management API transactions are issued. The transactions are based on information about
the job from the CA Workload Automation CA 7 Edition status queues.
Note: This interface was formerly known as the CA Netman™ interface. Do not confuse
that interface with the new CA ServiceDesk/els interface (see page 59).
In the standard implementation, use the real-time interface for the following situations:
OPEN or UPDATE the problems in a problem management system for CA Workload Automation
CA 7 Edition jobs that end abnormally.
CLOSE these problems for those restarted CA Workload Automation CA 7 Edition jobs when they
complete typically.
CA 7 Statements (see page 78)

Problem Management Interface Tasks (see page 79)
CA Netman Model Transactions (see page 79)
CA Netman Model Transactions - Continuation Rules (see page 80)
Problem Management Variables (see page 80)
CA 7 Statements
The real-time interface is initialized if the NETMAN statement is present in the CA Workload
Automation CA 7® Edition initialization file. This statement is used to set the problem management
API control values and parameters. They regulate the activity of the CA Workload Automation CA 7®
Edition subtask that invokes the problem management API.
08-Feb-2018 78/722
The interface also requires a NETMAN DD statement in the JCL used to start CA Workload
Automation CA 7® Edition. This statement identifies a file containing the problem management API
transaction schema. The file is used to build the problem management API transactions that are
issued when a CA Workload Automation CA 7® Edition job completes.
CA Workload Automation CA 7® Edition loads the problem management interface module, which is
identified on the NETMAN statement EXIT keyword, at the interface initialization. Verify that the exit
module resides on a library that CA Workload Automation CA 7® Edition can access.
The API transactions are issued under a CA Workload Automation CA 7® Edition subtask, SASSPM00.
When this task is ready to accept CA Workload Automation CA 7® Edition job completions, a message
is issued indicating successful initialization of the interface.
If the problem management interface is used, the storage requirement for CA Workload Automation
CA 7® Edition can increase significantly. We recommend an increase in region size of 1 MB as a
starting value. A larger increase is sometimes required, which depends on the volume of transactions
to issue.
Problem Management Interface Tasks

If the real-time problem management interface is indicated, a task in the CA Workload Automation
CA 7® Edition address space is created to accomplish the following tasks:
Accept CA Workload Automation CA 7® Edition job completion data asynchronously.
Build API transactions based on the schema in the model transaction file.
Issue API requests to send those transactions to the problem management interface.
CA Netman Model Transactions

Model CA Netman transactions are coded in a sequential file identified in the CA Workload
Automation CA 7® Edition execution JCL by a NETMAN DD statement. Each time the CA Netman
interface is invoked, CA Netman commands that are built from the model transactions are issued. For
example, if the following model CA Netman transaction is coded:
MGPT FUN=UPDATE SOURCE=XXX CAT=YYY SD='JOB 1'
Each time the CA Netman interface is invoked, an attempt is made to issue an MGPT transaction
conforming to the preceding format.
The model transaction file must be defined as DSORG=PS, LRECL=80 and RECFM=F or FB.
CA Netman transactions are issued in the order that they appear in the model transaction file for
each invocation of the interface.
The next example illustrates the use of variables in model CA Netman transactions:
SIGNON MJM
MGPT FUN=&&MFUN SOU=CA7 CAT=U +
DESC='&&L2PME_L2JOBN. ENDED WITH &&L2PME_L2CC' +
IDAT=0&&L2DATE ITIM=000&&L2PME_L2JOB# +
OCCRD=&&L2OCDT OCCRT=&L2OCTI
SIGNOFF
Variables can be used in the model transactions to refer to useful data such as job name, JES number,
08-Feb-2018 79/722
Variables can be used in the model transactions to refer to useful data such as job name, JES number,
date, time. With model transactions coded as in the preceding example, the following CA Netman API
transaction could be generated when job ABC123 completes:
SIGNON MJM
MGPT FUN=UPDATE SOU=CA7 CAT=U +
DESC='ABC123 ENDED WITH S-0C4' +
IDAT=008161 ITIM=00002127 +
OCCRD=060908 OCCRT=2230
SIGNOFF
Values for most variables are determined based on CA Workload Automation CA 7® Edition job
completion information. In this example, suppose that job ABC123 abended with an S-0C4 on 08.161
at 10:30 at night. Note the use of the incident time keyword (ITIM). The CA Workload Automation CA
7® Edition job number is inserted instead of a true incident time. In this way, you can reference the
problem by incident date and CA Workload Automation CA 7® Edition job number.
CA Netman Model Transactions - Continuation Rules

Model transactions can be continued. The occurrence of + as the last nonblank character on the line
indicates a continuation. The continuation resumes at column 1 of the next line. The length of a CA
Netman transaction that is built by this interface cannot exceed 1000 bytes. This limit restricts the
number of continuations for CA Netman model transactions.
Problem Management Variables

You can code the following variables in transactions:
Variable Length Value

Name
&&L2NTM_ 16 The value of the DBASENM keyword on the initialization file NETMAN statement
DBASENM
&&L2PME_ 08 Name of the job scheduled by CA Workload Automation CA 7® Edition
L2JOBN
&&L2PME_ 05 JES number of the job scheduled by CA Workload Automation CA 7® Edition
L2JES
&&L2PME_ 04 Execution SMF ID of the job scheduled by CA Workload Automation CA 7®
SYSID Edition
&&L2PME_ 05 CA Workload Automation CA 7® Edition assigned job number
L2JOB
&&L2PME_ 03 CA Workload Automation CA 7® Edition schedule ID associated with the job
L2SID
&&L2PME_ 08 System name from the CA Workload Automation CA 7® Edition job definition
L2SYSN
&&L2PME_ 08 Restart step name
L2RSN
&&L2PME_ 06 Completion code:
L2CC C-nnnn - normal completion
CFnnnn - job forced complete
08-Feb-2018 80/722

Name
JCLERR - JCL error
R-nnnn - condition code test failed
S-nnnn - system abend
U-nnnn - user abend
&&L2PME_ 04 Restart count
L2RC
&&L2PME_ 08 CPU time
L2CPUT
&&L2PME_ 03 CA Workload Automation CA 7® Edition JCL ID for the job
L2JCLI
&&L2PME_ 04 CA Workload Automation CA 7® Edition due-out year
L2DOYR
&&L2PME_ 03 CA Workload Automation CA 7® Edition due-out day
L2DODY
&&L2PME_ 04 CA Workload Automation CA 7® Edition due-out time
L2DOT
&&L2PME_ 04 CA Workload Automation CA 7® Edition deadline year
L2DLYR
&&L2PME_ 03 CA Workload Automation CA 7® Edition deadline day
L2DLDY
&&L2PME_ 04 CA Workload Automation CA 7® Edition deadline time
L2DLT
&&L2PME_ 04 CA Workload Automation CA 7® Edition submit year
L2SMYR
&&L2PME_ 03 CA Workload Automation CA 7® Edition submit day
L2SMDY
&&L2PME_ 04 CA Workload Automation CA 7® Edition submit time
L2SMT
&&L2PME_ 04 CA Workload Automation CA 7® Edition start year
L2STYR
&&L2PME_ 03 CA Workload Automation CA 7® Edition start day
L2STDY
&&L2PME_ 04 CA Workload Automation CA 7® Edition start time
L2STT
&&L2PME_ 04 CA Workload Automation CA 7® Edition end year
L2ETYR
&&L2PME_ 03 CA Workload Automation CA 7® Edition end day
L2ETDY
&&L2PME_ 04 CA Workload Automation CA 7® Edition end time
L2ETT
&&L2PME_ 04 The entry mode of the job. See the list following the table.
L2EM
08-Feb-2018 81/722

Name
&&L2PME_ 01 OVERRIDE=Y or N from CA Workload Automation CA 7® Edition job definition
L2OVR
&&L2PME_ 01 MAINT=Y or N from CA Workload Automation CA 7® Edition job definition
L2MNT
&&L2PME_ 01 EXEC=Y or N from CA Workload Automation CA 7® Edition job definition
L2EX
&&L2DATE 05 CA Workload Automation CA 7® Edition due-out date: format is YYDDD
&&L2OCDT 06 Occurrence date: format is MMYYDD
&&L2OCTI 04 Occurrence time: format is HHMM
&&DATE 06 System date: format is CYYDDD
&&TIME 06 System time: format is HHMMSS
&&MFUN 06 Expected value for FUNCTION keyword. If job ends abnormally,
&&MFUN=UPDATE. If job ends typically but was restarted, &&MFUN=CLOSE.
The following list details the entry modes:
ADEM
Indicates job entered by DEMAND command in ARF recovery.
ADST
Indicates data set triggered in ARF recovery.
AEXT
Indicates externally tracked job in ARF recovery.
AJBT
Indicates job triggered in ARF recovery.
ANWT
Indicates network triggered in ARF recovery.
APS
Indicates job entered by Personal Scheduling in ARF recovery.
ARFJ
Indicates ARF recovery job.
ARUN
Indicates job entered by RUN command in ARF recovery.
ASSC
Indicates job entered by Schedule Scan in ARF recovery.
DEMD
Indicates job entered by DEMAND command.
08-Feb-2018 82/722
DSTR
Indicates data set triggered.
EXTL
Indicates externally tracked job.
JBTR
Indicates job triggered.
NWTR
Indicates network triggered.
PSCH
Indicates job entered by Personal Scheduling.
RPET
Indicates repeat job.
RUN
Indicates job entered by RUN command.
SSCN
Indicates job entered by Schedule Scan.
XDEM
Indicates cross-platform scheduled using XPSSCHD=DEMAND.
XPS
Indicates cross-platform scheduled using XPSSCHD=RUNREF.
XRUN
Indicates cross-platform scheduled using XPSSCHD=RUN.
Interface with TSO/ISPF

CA provides an interface that gives the TSO/ISPF user access to a wide range of CA Workload
Automation CA 7® Edition functions. The interface lets CA Workload Automation CA 7® Edition users
enjoy many of the benefits that derive from TSO/ISPF (such as split-panel capability and ISPF Editor)
while using CA Workload Automation CA 7® Edition. However, the ISPF jump facility is not available
from a CA Workload Automation CA 7® Edition terminal session under ISPF. For example, one cannot
go to the ISPF BROWSE panel by simply entering =1 in a command area and pressing Enter. One must
either split the panel or end the CA Workload Automation CA 7® Edition terminal session.
In the TSO/ISPF environment, the ISPF user requests interface services with a CLIST. Programs that
are executed under the CLIST acquire a CA Workload Automation CA 7® Edition virtual terminal and a
VTAM LU-LU session is set up between ISPF(SLU) and CA Workload Automation CA 7® Edition(PLU).
Except for edit sessions, panel data is presented as it is in any CA Workload Automation CA 7® Edition
08-Feb-2018 83/722
Except for edit sessions, panel data is presented as it is in any CA Workload Automation CA 7® Edition
online terminal session. The interface processes panel input and output for the ISPF session by
invoking the appropriate ISPF Dialog Manager services. Interface modules issue VTAM SEND and
RECEIVE macros to handle the data traffic with CA Workload Automation CA 7® Edition.
Note: Because the interface uses a CA Workload Automation CA 7® Edition VTAM terminal,
all restrictions that apply to VTAM terminals also apply to the ISPF sessions using the
interface. For example, restrictions include the 255 page limit on output.
All CA 7 online terminal functions can be requested using the interface except for /SHUTDOWN
commands.
The native CA Workload Automation CA 7® Edition uses the JCL syntax checking facility. Editor is not
available in the ISPF environment. JCL validation through CA JCLCheck™ can be requested using the !
JCK edit macro. For more information about !JCK, see the CA JCLCheck documentation if you are
using the full CA JCLCheck product.
To use the CA Workload Automation CA 7® Edition TSO/ISPF interface, virtual terminals must be
defined in the CA Workload Automation CA 7® Edition initialization file.
Information about the TSO/ISPF interface installation follows in the next three topics.
VTAM Considerations
The TSO/ISPF interface requires VTAM node definitions to support the LU-LU session between CA
Workload Automation CA 7® Edition and ISPF. The following information discusses the VTAM
application that contains the nodes that are used by the interface.
The CA Workload Automation CA 7® Edition TSO/ISPF interface uses only the node name that is
defined using the ACBNAME keyword on the VTAM APPL statement. The interface imposes strict
conventions that must be observed when coding the value for this keyword. The interface does not
directly reference the application minor node name that the label on the APPL statement creates.
VTAM uses this name, which must be unique within the network.
The ACBNAME values must be exactly 7 bytes long. Users can select the first three characters, subject
to VTAM naming conventions. The last four characters must be numeric and numbered
consecutively. The numbers range from 0001 to nnnn, where nnnn represents the maximum number
of concurrent uses of the interface.
For example, suppose all the node names that ISPF uses during CA Workload Automation CA 7®
Edition sessions begin with the characters CA7. If the maximum number of concurrent interface uses
is four, define four nodes for this purpose. See the following example of a VTAMLST member defining
the nodes for such an installation.
CA7ISPF VBUILD TYPE=APPL
CA710001 APPL ACBNAME=CA70001
08-Feb-2018 84/722
A sample VTAMLST member is included in the CA7ISPF member of CAL2MAC. Edit the member to
reflect the specific needs of your installation. Next, copy the member to the appropriate VTAMLST
library to define correctly the VTAM application.
Each request for a CA 7 terminal session from an ISPF panel requires the use of one of these nodes
that are dedicated for interface use. Thus, in this example, anywhere from one to four ISPF users can
be allowed depending on terminal characteristics. In most instances, an ISPF user requires the use of
only one CA 7 terminal session. However, nothing would prevent one ISPF user from having more
than one CA 7 terminal session going at one time using the ISPF split panel capability. For example,
one user could split the panel into four ISPF panels, and from each screen maintain a CA 7 terminal
session. This split would imply four concurrent uses of the interface or four CA 7 terminal sessions
going on at once. In this example, any attempt to use the interface during this time from another
terminal fails because no nodes would be available for this purpose.
Unlike the node for CA Workload Automation CA 7® Edition that requires that AUTH=ACQ be coded
on the VTAM APPL statement, the ISPF nodes have no such special requirements.
A VTAM application similar to the one previously described must be defined in each VTAM domain
where TSO/ISPF sessions with CA Workload Automation CA 7® Edition are supported. For CLIST
compatibility, the ACBNAME values should be the same across domains, only the node names that
are created by the labels on the VTAM APPL statements need be changed for network uniqueness. In
the following example, the CA7ISPF member could be used as a model for an application definition in
another domain of the network.
CA7ISPF2 VBUILD TYPE=APPL
When the install is complete, activate the applications where the interface nodes are defined. In this
example, issue a VARY command on the MVS console to make the VTAM nodes available for use;
such as:
VARY NET,ID=CA7ISPF,ACT
ISPF Considerations
The TSO/ISPF interface requires several CLISTs, panel definitions, and load modules.
The CLIST used to invoke the interface is provided in the CA7CLIST member of library CAL2CLS0. Edit
this CLIST to reflect changes appropriate for your installation. Next, copy the CLIST to a library that is
part of the SYSPROC concatenation in the TSO LOGON procedure to make it easily accessible.
In the CLIST member, the CA7APL keyword supplies the name of the ACB for CA Workload
Automation CA 7® Edition. Make this value identical with the value coded for the APPL keyword in
the UCC7VTAM statement in the CA Workload Automation CA 7® Edition initialization file. Make the
value on the SESSAPL keyword the ACBNAME with the highest value. In this example, code CA70004
because four nodes were defined for CA Workload Automation CA 7® Edition TSO/ISPF
communication. Also, the LIB keyword should specify the CA Workload Automation CA 7 Edition load
module library CAL2LOAD.
08-Feb-2018 85/722
When installing, you can run SMP/E USERMOD AL2UM11 in the CAL2JCL library. The job replaces the
default TSO/ISPF CLIST with a copy that the CA Workload Automation CA 7® Edition Stage I SYSGEN
customizes.
Also, several CLISTs are used as EDIT macros when the ISPF Editor is called in the CA Workload
Automation CA 7® Edition environment. The edit macros are CA7EXIT, CA7SAVE, CA7SS, and CA7SR.
These names correspond respectively to EXIT, SAVE, SS, and SR in the CA Workload Automation CA 7®
Edition environment. Another edit macro CA7ED0 is supplied and is required for internal use by the
interface. These CLISTs are also supplied in data set CAL2CLS0. These CLISTs must also be copied to a
CLIST library that is included in the SYSPROC concatenation in the TSO LOGON procedure.
The following load modules are required. They are used to handle the VTAM link with CA Workload
Automation CA 7® Edition, invoke the Dialog Manager Services and perform other interface
functions. These modules do not execute in the CA Workload Automation CA 7® Edition address
space but in the address space of the TSO user.
L2ADDON
L2ISPFWA
L2ISPF00
L2ISPF10
L2ISPF20
L2ISPF21
L2ISPF40
L2ISPF42
L2ISPF45
L2ISPF46
L2ISPF90
CA Workload Automation CA 7® Edition does not need access to these modules. Move them from the
CA Workload Automation CA 7® Edition production load library to a smaller load library that TSO
users access. In this way, use of the interface does not entail allocation of the CA Workload
Automation CA 7® Edition load library. The library containing the interface modules is dynamically
allocated using a CALL statement.
Three ISPF panel definitions are supplied in CAL2PNL0 and are required for the interface:
CA7@PRIM
CA7P000
CA700003
The CA7@PRIM panel is the menu panel for CA Workload Automation CA 7® Edition under ISPF.
CA700003 is a documentation panel that is invoked when the ISPF HELP command is issued. CA7P000
is the panel required for processing option 1 from the CA Workload Automation CA 7® Edition menu.
This panel is used for all online terminal panel handling. These panel definitions should be copied to a
library that is part of the ISPPLIB concatenation in the TSO LOGON procedure.
Although you can acquire a CA 7 online terminal session by simply executing CA7PDRVR, modify
ISR@PRIM to issue the CA7PDRVR command with NEWAPPL (CA7). If CA7PDRVR is invoked in this
way, an ISPF application named CA7 is recognized by ISPF. If the interface is invoked in any other way
(for example, by executing CA7PDRVR or CA7CLIST from ISPF option 6) then you have no CA
Workload Automation CA 7® Edition PF key support. See the sample AL2@PRIM provided in the
CAL2OPTN library for an example of an ISPF primary menu where the
CA Workload Automation CA 7® Edition TSO/ISPF interface is an option.
08-Feb-2018 86/722
If the CA7@PRIM panel is defined as a SELECT option with the NEWAPPL(CA7) parameter and if the
CA Workload Automation CA 7® Edition TSO/ISPF interface option is selected from the ISPF primary
menu, then ISPF searches for a user profile named CA7PROF, an edit profile named CA7EDIT, and a
command table named CA7CMDS. The CA7CMDS member in CAL2TBL0 is provided as part of the
installation. CA7PROF and CA7EDIT are built by ISPF dynamically. ISPF retrieves all profile information
from CA7PROF while the CA Workload Automation CA 7® Edition application is in control, thus letting
the user the define ISPF PF key settings that are unique to the CA Workload Automation CA 7®
Edition application.
When the online option (option 1 from the CA Workload Automation CA 7® Edition TSO/ISPF menu) is
invoked for the first time, PF keys are assigned the following default settings:
PF01 - HELP PF13 - HELP
PF02 - SPLIT PF14 - SPLIT
PF03 - END PF15 - END
PF04 - RETURN PF16 - RETURN
PF05 - RFIND PF17 - RFIND
PF06 - RCHANGE PF18 - RCHANGE
PF07 - UP PF19 - UP
PF08 - DOWN PF20 - DOWN
PF09 - SWAP PF21 - SWAP
PF10 - LEFT PF22 - LEFT
PF11 - RIGHT PF23 - RIGHT
PF12 - CURSOR PF24 - CURSOR
In a CA Workload Automation CA 7® Edition terminal session under ISPF there is no ISPF command
input area, unless the ISPF editor is invoked. All input is interpreted as CA Workload Automation CA
7® Edition terminal input and is treated as such. CA Workload Automation CA 7® Edition input can be
entered either from the "top line" or from any area considered appropriate for a CA Workload
Automation CA 7® Edition formatted panel if a formatted panel is displayed.
ISPF commands are usually issued from any area preceded by the character string '====>' or through
the PF key. However from a CA Workload Automation CA 7® Edition session under ISPF, ISPF
commands can be entered only through the PF key, because all panel input is taken to be CA
Workload Automation CA 7® Edition terminal input.
CA Workload Automation CA 7® Edition allows assignment of CA Workload Automation CA 7® Edition

commands to PF keys as does ISPF. In a CA Workload Automation CA 7® Edition terminal session
under ISPF, a PF
CA Workload Automation CA 7® Edition formatted input panels, PF3 is used to return to the menu
from which the current panel could be selected. (PF15 is not accepted as an equivalent function.)
Assigning PF3 to any ISPF command will prevent that key from being used by CA Workload
Automation CA 7® Edition in any way; transfers between panels requires the user to enter the panel
name each time.
When an ISPF command is entered, ISPF searches a table to determine the action that should be
taken when this command is input. Such a table is known as an application commands table and can
be modified using ISPF option 3.9. The table exists as a member of a PDS in the ISPTLIB concatenation
in the TSO LOGON procedure. The name of the member (also the name of the table) is xxxxCMDS,
where xxxx is the name of the ISPF application in control when the command was entered. If an ISPF
command is entered from a CA Workload Automation CA 7® Edition terminal session under ISPF,
then the application in control would be CA7. Thus, the table that ISPF would search is CA7CMDS. If
an entry is found in the table that matches the command entered, then ISPF takes the action
specified on that table entry. Among the actions that can be specified are PASSTHRU, NOP, and
blanks. If the action in a table entry is blank, then ISPF processes the command as if there were no
table entry for it. If NOP is specified, then the command associated with it is deactivated for that
08-Feb-2018 87/722
table entry for it. If NOP is specified, then the command associated with it is deactivated for that
application. If PASSTHRU is specified, then the command with its PF key interrupt is passed to the
application in effect, which in this case is the CA Workload Automation CA 7® Edition TSO/ISPF
interface. An action can also be specified dynamically by using an ISPF variable.
A command table (CA7CMDS) is provided that is intended to be used with the default PF key settings
for the CA7 application previously listed. Use of this table with the default PF key settings allows all
PF keys except PF02, PF03, PF09, PF14, PF15, and PF21 to be given their CA Workload Automation CA
7® Edition interpretation in a CA Workload Automation CA 7® Edition terminal session unless the ISPF
editor is invoked. If the ISPF editor is invoked, then all PF keys are taken as providing ISPF command
input. Such an assignment allows the ISPF commands SPLIT, SWAP, and END to always be input using
PF keys when in the CA7 application. The CA7CMDS member should be copied from CAL2TBL0 to a
PDS that is in the ISPTLIB concatenation in the TSO LOGON procedure.
The following entries are in the CA7CMDS member supplied in CAL2TBL0:
VERB T ACTION
DESCRIPTION
.... SUBMIT 3 NOP
.... HELP 0 &CA7ACT

.... RETURN 0 &CA7ACT

.... RFIND 0 &CA7ACT

.... RCHANGE 0 &CA7ACT

.... UP 0 &CA7ACT

.... DOWN 0 &CA7ACT

.... LEFT 0 &CA7ACT

.... RIGHT 0 &CA7ACT

.... CURSOR 0 &CA7ACT
The ACTION NOP on the entry for SUBMIT causes the ISPF SUBMIT command to be deactivated for
the CA7 application. This behavior prevents users from using the ISPF SUBMIT command to submit
jobs while in the ISPF editor in a CA Workload Automation CA 7® Edition terminal session. We
strongly recommend this because CA Workload Automation CA 7® Edition does not track jobs
submitted through the ISPF SUBMIT command.
Use of the &CA7ACT variable on the other table entries lets the interface programs and CLISTs set the
action dynamically, so that the action can be changed when the need arises. If the ISPF editor is
invoked from a CA Workload Automation CA 7® Edition terminal session, then the value of &CA7ACT
is set to blanks, otherwise the value of the variable is set to PASSTHRU.
To see how this works, suppose that the PF01 key has been pressed in a CA Workload Automation CA
7® Edition terminal session where the ISPF editor is not currently being used. Suppose also, that the
PF01 key is associated with the ISPF HELP command under the CA7 application. ISPF searches the
CA7CMDS table for an entry for the ISPF HELP command. The entry is found and the variable
&CA7ACT has been set by the interface programs to PASSTHRU. The HELP command is not processed
by ISPF but instead is sent to the interface programs that send the PF01 interrupt to CA7. CA7 sees
the interrupt and processes the command (if any) associated with that PF key.
If, however, the ISPF editor has been invoked from a CA Workload Automation CA 7® Edition terminal
08-Feb-2018 88/722
If, however, the ISPF editor has been invoked from a CA Workload Automation CA 7® Edition terminal
session, then the situation is different. Prior to entering the ISPF editor, the interface programs set
the value of &CA7ACT to blanks. Thus, the action associated with the ISPF HELP command in the
CA7CMDS table has been set to blanks. This causes the ISPF HELP command to be processed normally
when PF01 is pressed.
Most of the default PF key settings that are provided for the CA7 application equate with ISPF
commands that have no significance in a CA Workload Automation CA 7® Edition terminal session
unless the ISPF editor is invoked.
Exercise great care when modifying the ISPF PF key settings or the command table for the CA7
application. Only those PF keys that are associated with ISPF commands that appear in the CA7CMDS
table with an action of PASSTHRU or &CA7ACT are honored by CA Workload Automation CA 7®
Edition. The default command table CA7CMDS that is found in CAL2TBL0 does not include entries for
SPLIT, SWAP and END. This causes these ISPF commands to always be honored. We recommend that
PF keys be set up (using option 0 from the CA Workload Automation CA 7® Edition TSO/ISPF menu)
for all essential ISPF or TSO command input that must be entered from the CA Workload Automation
CA 7® Edition terminal session. If such command input is always to be handled by ISPF or TSO, do not
create entries for these commands in CA7CMDS.
Also, if you are calling the CA7CLIST from a REXX program, set the call as shown in the following
sample:
ADDRESS ISPEXEC "SELECT CMD(CA7CLIST) NEWAPPL(CA7"
key interrupt can be used for ISPF command input or CA Workload Automation CA 7® Edition
command input but not both. Since it is desirable to use PF keys for both types of command input,
most users may want to specify that certain PF keys provide ISPF command input, and that other PF
keys are treated like CA Workload Automation CA 7® Edition PF keys. When using
CA 7 Considerations
Virtual terminal definitions are required. Verify that the number of virtual terminals defined is greater
than or equal to the number of nodes defined for CA Workload Automation CA 7 Edition TSO/ISPF
communication.
The ISPF display services that are used by CA Workload Automation CA 7 Edition do not support
scrolling. The display of a CA Workload Automation CA 7 Edition page always starts with the top of
the page. You can use the CA Workload Automation CA 7 Edition /PAGE command to page through
the CA Workload Automation CA 7 Edition pages. This behavior means that a CA Workload
Automation CA 7 Edition panel image that has all 24 lines used does not show some of the bottom
lines, depending on where the split is done (when using a split panel).
Interface with Unicenter Event Console

CA Workload Automation CA 7® Edition sends many important messages to the master station. They
include messages about CA Workload Automation CA 7 Edition job status and CA Workload
Automation CA 7 Edition system activities such as schedule scan and job submission. CA Workload
Automation CA 7 Edition can route master station messages to a designated Unicenter Event
Console.
08-Feb-2018 89/722
More information:
Master Station Routing Messages (MSMR) (https://wiki.ca.com/display/CWAC7E/MSMR+-

+Route+Master+Station+%28Browse%29+Messages)
UNIX System Services Interface

The UNIX System Services interface provides a method of communication for requests to CA
Workload Automation CA 7® Edition from the UNIX System Services environment. The interface can
be called directly from the UNIX shell or from the MVS batch interface Unix Systems Services MVS
BPXBATCH. This group includes user applications, shell scripts, and the command prompt. The
request can be any valid CA Workload Automation CA 7® Edition command that is typically passed to
U7SVC and must be syntactically correct.
For information about the installation and setup of the CA Workload Automation CA 7® Edition USS
Interface modules, see UNIX System Services Interface Communications (https://wiki.ca.com/display
/CWAC7E/UNIX+System+Services+Interface+Communications).
Note: For more information about using the UNIX Services with the shell environment, see
the IBM documentation for the UNIX System Services User' and Command Reference
documentation.
For invoking the CA Workload Automation CA 7® Edition interface, see the following examples.
Invoke the Interface

From the UNIX shell environment command prompt, you can invoke the interface as follows:
ca7oecom demandh,job=payjob1
The preceding example invokes the CA Workload Automation CA 7® Edition UNIX Services interface
executable CA7OECOM and passes the command on to CA Workload Automation CA 7® Edition
through U7SVC. In this case, a DEMANDH command for job PAYJOB1 is requested. A return code is
supplied to indicate the status of the request to U7SVC.
The UNIX shell can be entered by issuing the TSO/E OMVS command from within TSO.
If the command you want to submit to CA Workload Automation CA 7® Edition contains special
characters, blanks, or quotes, embed the entire command in single quotes. The single quotes prevent
the shell from evaluating the special characters as part of the command. For example:
ca7oecom 'addrq,job=payjob1,usr=this is a user requirement'
Environment Variables
08-Feb-2018 90/722
CA7DIR
This environment variable specifies the fully qualified path name for the location of the interface
executable CA7OECOM. This variable is required to be set before execution of the interface.
Example Path
/users/applications/ca7/bin
CA7TRACE
This environment variable is used for diagnostic purposes. When set to "ON", the interface
module CA7OECOM issues diagnostic messages during execution to help with problem
determination.
Set Environment Variables
Environment variables can be set from within the shell by using the UNIX "export" command. If you
use the MVS Batch interface Unix Systems Services MVS BPXBATCH, you can set the environment
variables in a file pointed to by ddname STDENV.
Example: Set CA7DIR variable
This example sets the CA7DIR variable in the UNIX environment from the command prompt. Issue the
following command:
export CA7DIR=/users/applications/ca7/bin
Example: Set environment variables
This example sets the environment variables from within a file or PDS member. Simply set the
variable to the value as follows:
CA7DIR=/users/applications/ca7/bin
Special Information
The UNIX environment is case-sensitive. The CA7DIR environment variable name must be specified in
uppercase. The path name itself can be mixed case.
The maximum length for the value of the path variable is 1024 characters.
//CA7UNIX JOB 'ACCOUNT,INFO','PROGRAMMER',
// CLASS=A,MSGCLASS=X
//**********************************************************
//* S A M P L E
//*
//* A sample batch job which executes BPXBATCH to invoke
//* the IBM UNIX shell and then execute the CA 7
//* interface module CA7OECOM. The files stderr and stdout
//* are allocated on the UNIX file system. The required
//* environment variables are defined in a standard PDS
//* member ENVARS.
//*
//**********************************************************
//*
//JS10 EXEC PGM=BPXBATCH,
// PARM='sh /u/users/bin/ca7oecom demandh,job=payjob1'
//*
//STDOUT DD PATH='/u/users/work/mystd.out',
// PATHOPTS=(OWRONLY,OCREAT,OTRUNC),PATHMODE=SIRWXU
//*
08-Feb-2018 91/722
//*
//STDERR DD PATH='/u/users/work/mystd.err',
//*
//STDENV DD DSN=USER.PDS(ENVARS),DISP=SHR
//*
Schedule UNIX System Services Jobs

This article explains how to schedule UNIX System Services (USS) jobs with CA Workload Automation
CA 7® Edition. The mainframe environment provides a UNIX implementation referred to as USS.
These services let UNIX users operate from within the mainframe environment without having to
learn the MVS system internals. UNIX users use most of the standard UNIX facilities such as shell
commands, shell scripts, and binary executables. This UNIX shell runs as an MVS system task. The
shell can be accessed from any MVS batch job through a program named BPXBATCH.
The BPXBATCH program is invoked from MVS batch and executes shell scripts or executables on the
UNIX file system. Because this JCL is standard MVS batch JCL, CA Workload Automation CA 7® Edition
can schedule these tasks like any other MVS batch job.
Note: For more information about the BPXBATCH utility, see the IBM documentation.
The following example is a sample invocation of BPXBATCH:

//JOBNAME JOB 'ACCOUNT,INFO','PROGRAMMER',CLASS=A,MSGCLASS=X
//*****************************************************************
//* S A M P L E *
//* *
//* Sample batch JCL which executes BPXBATCH to invoke the IBM *
//* UNIX shell and then executes a shell command under *
//* UNIX System Services. *
//* *
//*****************************************************************
//*
//JS10 EXEC PGM=BPXBATCH,PARM='sh /bin/ls'
//*
//STDOUT DD PATH='/u/users/work/mystd.out',
//*
//STDERR DD PATH='/u/users/work/mystd.err',
//*
//STDENV DD DSN=USER.PDS(ENVARS),DISP=SHR
//*
External Communicators
The external communicators enable the processing of work that is under CA Workload Automation
CA 7® Edition control, which is based on events that are not under CA Workload Automation CA 7
Edition control.
One example would be an RJE site transmitting data to a central location for processing. The
08-Feb-2018 92/722
One example would be an RJE site transmitting data to a central location for processing. The
remainder of the processing, to be done under the control of CA Workload Automation CA 7 Edition,
must consider the creation of the data file as a prerequisite task and is triggered when the data file is
received from the RJE site. CA Workload Automation CA 7 Edition facilities such as batch terminal
interface, trailer step, U7SVC, and batch card load program (BCLP) handle such activities.
The batch terminal interface facility (BTI) is used to perform mainly database functions within a batch
job instead of through an online terminal. Many of the same commands that are available online can
be performed through a batch terminal when a CA 7 online terminal is unavailable or impractical.
Trailer steps communicate queue posting commands to CA Workload Automation CA 7 Edition for
some action that has taken place. On receiving this communication, CA Workload Automation CA 7
Edition automatically initiates all tasks that are defined as dependent on that posting action.
The U7SVC program combines the BCLP and trailer step functions. U7SVC can be executed as a step,
in the same manner as a trailer step. Another program can call it to send commands to CA Workload
Automation CA 7 Edition or post a data set creation. Through U7SVC, the user can post to CA
Workload Automation CA 7 Edition the creation of a noncard-image data set or request commands
that the trailer step does not support.
The CA Workload Automation CA 7 Edition CAICCI interface combines aspects of the BTI and U7SVC
facilities. The interface uses the CA Common Communication Interface (CAICCI) to send batch
commands to CA Workload Automation CA 7 Edition on the same or another MVS image. The
interface also receives back the CA Workload Automation CA 7 Edition output from those commands.
The caller can evaluate the success of the command string, extract information from the command
output for future processing, or both. The CA Workload Automation CA 7 Edition CAICCI interface can
be executed in a batch mode, called from a REXX CLIST or environment, or called directly from
another program.
The CA Workload Automation CA 7 Edition TCP/IP interface performs the same functions as the CA
Workload Automation CA 7 Edition CAICCI interface, only it uses TCP/IP as the communication
protocol.
BCLP is used to transfer batches of card-image data to disk or tape. Once the data files are created,
work under CA Workload Automation CA 7 Edition control can use those files. On the creation of the
file, completion information is posted to the CA Workload Automation CA 7 Edition log data set and
all dependent processing tasks are initiated.
These facilities let you have work performed outside of the data center, perhaps at an RJE site. The
production control functions remaining at the central computer location. The inherent advantages of
having full data center security are maintained. Remote personnel are not necessarily involved in
data center operations, JCL, and so forth. Work that begins with any task external to CA Workload
Automation CA 7 Edition can still realize the advantages of automated production control.
Batch Card Load Program (BCLP)

The Batch Card Load Program (BCLP) loads card-image data to sequential data sets required for CA
Workload Automation CA 7® Edition jobs. Through BCLP, you can create, modify, or replace
sequential data sets. When BCLP is executed, ICOM notifies CA Workload Automation CA 7 Edition of
successful data set manipulation through the communications data set. In this way, the database
index entries are updated to reflect a new creation date and time.
When BCLP is used, CA Workload Automation CA 7® Edition is notified of successful data set
08-Feb-2018 93/722
When BCLP is used, CA Workload Automation CA 7® Edition is notified of successful data set
manipulation. CA Workload Automation CA 7 Edition then scans the request queue for jobs that use
this data set as an input requirement. Jobs triggered by the data set are brought into the request
queue.
A single run of BCLP can create, replace, or modify multiple data sets. These data sets cannot be
members of a PDS.
BCLP can also be run as a CA Workload Automation CA 7 Edition job under CA Workload Automation
CA 7 Edition control. However, it must be marked as a maintenance job to prevent the posting of
SMF records. To mark BCLP as a maintenance job, use the DB.1 panel or the #MNT special purpose
override statement.
If the job is not marked as a maintenance job, Message SMF0-17 is issued (unless suppressed with
SASSMSGS) and the type-99 record (DSN creation) is ignored. This situation could cause improper
scheduling if the data set request included the SCHID keyword.
BCLP dynamically allocates space required for each data set. BCLP accomplishes this allocation by
spooling card images to a work data set and calculating the number of disk tracks required to store
the data.
Generation data groups can be handled through BCLP; however, the following differences exist:
Because new generation data set catalog maintenance is done at the time of creation, relative
GDG numbers greater than +1 are not allowed. That is, if the user wishes to create three new
GDG versions in one run, each must be referenced as +1.
A model DSCB is not required.
An attempt to catalog a generation that has already been dropped results in an error.
If BCLP terminates with an error, the completion code is the hexadecimal equivalent of the error
message number. Error messages are listed in Messages and Codes (https://wiki.ca.com/display/CWAC7E
/Messages+and+Codes).
Note: BCLP cannot process data sets on SMS managed volumes.
CA 7 Requirements
All data sets created, replaced, or modified by BCLP must be defined in the CA Workload Automation
CA 7 Edition database unless REQSAT=NO is used.
To post requirements as available, ICOM must be active. If ICOM is not active, requirements are not
posted until ICOM is brought up.
JCL Requirements
PARMs
08-Feb-2018 94/722
PARM information about the BCLP execute statement can consist of one or more of the following
parameters. If more than one is entered, separate them with commas.
CA7=xxxx
Indicates which instance of CA Workload Automation CA 7 Edition BCLP communicates with,
where xxxx is one of the following values:
An instance name from CA71 through CA78
A one- to four-character alias specified during the CA Workload Automation CA 7 Edition

initialization with CAIRIM
PROD, which defaults to CA71
TEST, which defaults to CA72
If CA7 is omitted, the default is CA71.
ERR=ABORT
Indicates that whenever any error is detected, abort the run with a dump. If this option is not
specified, a dump is not produced.
DD Statements
The following DD statements are required:
SYSPRINT
Receives a listing of all statements read and any messages generated.
SYSUDUMP
Used for a dump under certain error conditions.
STEPLIB
Specifies the CA Workload Automation CA 7® Edition and CA Datacom/AD execution libraries. The
libraries that are specified on this STEPLIB must match the libraries that are specified in your CA7
online execution JCL.
DBPARMS
Defines the logical database name. Specify the same data set that is specified on the DBPARMS
DD in your CA7 online JCL here.
UCC7WORK
Allocates a work file that temporarily contains card images for a data set. Allocate enough space
to contain the largest data set to be processed.
U7xxxxxx
One U7 statement must be present for each volume referred to by the VOL keyword, or used as a
result of a catalog search. Have xxxxxx match the VOL=SER of the DD statement. If it does not
match, a warning message is generated. Volumes are located by VOL=SER, not by ddname.
08-Feb-2018 95/722
Note: Only one DD for a nonspecific volume allocation is permitted. The name must be
U7VOLSER. Make it the first U7 statement in the JCL.
SYSIN
Source of input control statements and data.
Sample BCLP JCL

The following is a sample of BCLP JCL:
//ST1 EXEC PGM=SASSBCLP,PARM=('CA7=CA74')
// DD DISP=SHR,DSN=cai.CUSLIB
// DD DISP=SHR,DSN=cai.CAAXLOAD
//SYSPRINT DD SYSOUT=A
//DBPARMS DD DSN=user-defined-location-of-DBPARMS,DISP=SHR
//UCC7WORK DD VOL=SER=111111,UNIT=SYSDA,
// DISP=(NEW,DELETE),SPACE=(TRK,(10,10))
//U7VOLSER DD UNIT=SYSDA,SPACE=(TRK,0)
//U7111111 DD VOL=SER=111111,UNIT=SYSDA,DISP=SHR
//SYSIN DD *
*UCC7 CREATE DSN=A.B.C,VOL=111111
statement1
*UCC7 REPLACE DSN=X.Y.Z,VOL=222222
statement1
statement2
*UCC7 EODS
/*
Control Statements for BCLP

Control statements for the Batch Card Load Program (BCLP) must contain an identifier, an operation,
and optionally one or more keyword operands. Separate the identifier and operation fields with one
or more blanks. Separate the operation field and the first keyword parameter with one or more
blanks. Separate the keyword operands with commas.
BCLP OPTION Statement (see page 97)

Data Set Request Statements CREATE, REPLACE, MODDATA (see page 100)
End-of-Data Set (EODS) Statement (see page 102)
Use the following format for entering control statement data:
Identifier
The identifier is always *UCC7 and must appear in columns 1 through 5 of each control
statement, including continuation statements.
Operation Field
The operation field must be separated from the identifier by one or more blanks. If multiple
statements are used for the same operation, the operation field must appear on the first
statement.
08-Feb-2018 96/722
Keyword Parameters
Separate the operation field and the first keyword parameter by one or more blanks. The
keyword parameters can appear in any order. For a continuation, the last keyword on a
statement to continue must have a comma following it. The next keyword parameter and its
operand (except for JOBS) must appear on the next statement. On continuation statements,
Separate the identifier (*UCC7) and the first keyword parameter with at least one blank.
Comments
Comments can be entered in two ways. A comment can be entered beyond the last keyword of a
statement. A comment must be separated from the keyword and its operand by one or more
blanks. If an entire statement is to contain comments, the first character of the comments must
be an asterisk (*). Even if the entire statement is to contain a comment, the identifier (*UCC7)
must be present.
Examples
*UCC7 operation1 keyword1=x,keyword2=y
*UCC7 operation2
*UCC7 keyword=x, THIS VALUE IS
*UCC7 *REQUIRED ON MONDAYS
*UCC7 keyword=y,keyword=z,
*UCC7 keyword=zz
The possible operation field values are the following items:
OPTION
CREATE
REPLACE
MODDATA
EODS
Examples are provided following the keyword formats and options.
BCLP OPTION Statement

Use the OPTION statement to set up default parameters for the execution of BCLP. If the OPTION
statement is used, it must be first. If standard defaults are sufficient, you can omit this statement.
Options specified in the statement can be overridden at the data set level.
This statement has the following format:

*UCC7 OPTION [,LTERM={MASTER|xxxxxxxx}]
[,DETLIST={YES|NO}]
[,VOLROT={NO|YES}]
[,REQSTAT={YES|NO}]
[,BLKSIZE={3120|nnnnn}]
[,MAXJOBS={10|nnn}]
[,SCHID={1|nnn}]
[,CVOL={SYSRES|xxxxx}]
08-Feb-2018 97/722
LTERM
(Optional) When the product has completed updating the database index entries and input
requirement posting, a data set completion message is generated. The LTERM keyword
designates the logical terminal to receive the data set completion message. This message is
generated when the product has updated its database index entries and appropriate
requirements are posted as satisfied. This action, and the associated message, are not produced
unless REQSAT=YES was specified or taken as a default. Also, the message is not produced for
data sets that are defined as PERM (permanent) in the product. If LTERM is specified, it must
match a logical terminal name (STANIDS) in the initialization file. If this keyword is omitted,
MASTER is assumed.
MASTER
Specifies the master terminal is to receive the data set completion message.
Default: MASTER
xxxxxxxx
Specifies the logical terminal name that receives the completion message.
Limits: 1 to 8 alphanumeric characters
DETLIST
(Optional) Specifies whether to produce a detail list of all statements entered.
YES
Specifies to produce a list of all statements.
Default: YES
NO
Specifies to list only control statements and messages.
VOLROT
(Optional) Indicates whether, on a specific volume request, an insufficient space condition results
in a search of other volumes for the space.
NO
Indicates an insufficient space condition resulting in an error. NO is the default.
YES
Specifies a search of U7xxxxxx volumes, in a DD statement sequence, is made for sufficient
data set space. Rotation begins with the first volume and proceeds as if it were a nonspecific
request.
REQSAT
(Optional) Specifies whether a successful operation on a data set results in a requirement being
satisfied or a job being triggered.
YES
Indicates that CA Workload Automation CA 7 Edition is notified of the successful operation
with a type-99 record that BCLP generates.
Default: YES
08-Feb-2018 98/722
NO
Indicates that the operation is performed, but a type-99 record is not generated and CA
Workload Automation CA 7 Edition is not notified.
BLKSIZE
(Optional) Designates the block size to use when creating data sets.
This keyword can also be used to assign a default block size for all data sets or for a single data
set.
3120
Specifies the block size of 3120.
Default: 3120
nnnnn
Specifies the block size that is divisible by 80. The block size cannot be larger than the track
size of the receiving device or 32720, whichever is smaller.
Limits: 2 to 5 numeric characters from 80 to 32720
MAXJOBS
(Optional) Specifies the maximum number of job names to appear in any JOBS parameter on a
data set request statement. If a data set request is encountered containing more job names than
the maximum, the data set request is bypassed.
10
Specifies ten job names are to appear in the JOBS parameter on a data set request statement.
Default: 10
nnn
Specifies the number of job names that appear in the JOBS parameter on a data set request
statement.
SCHID
(Optional) Specifies which schedule ID created the data set. This method can be done on a data
set basis or for the whole job.
1
Specifies the default schedule ID to associate with each data set.
Default: 1
nnn
Specifies the schedule ID to associate with each data set.
Limits: 1 to 3 numeric characters from 1 through 999
CVOL
(Optional) Specifies the volume containing the system catalog to search, to update, or both. This
keyword is required only when a proper index structure is not established for a data set.
SYSRES
Specifies the system resident device as the volume containing the system catalog.
Default: SYSRES
xxxxxx
08-Feb-2018 99/722
xxxxxx
Specifies the volume containing the system catalog.
Data Set Request Statements CREATE, REPLACE, MODDATA

To define the operation that is performed to a data set, use the data set request statements. A data
set statement always immediately precedes the first data statement for the data set being acted on.
These statements have the following format:

*UCC7 {CREATE|REPLACE|MODDATA},DSN=xx...xx
[,BLKSIZE={3120|nnnnn}]
[,CATALOG={NO|YES}]
[,DETLIST={YES|NO}]
[,JOBS={xxxxxxxx|(xxxxxxxx,...,xxxxxxxx)}]
[,LTERM=xxxxxxxx]
[,REQSTAT={YES|NO}]
[,SCHID={1|nnn}]
[,VOL=xxxxxx]
[,VOLROT={YES|NO}]
[,CVOL=xxxxx]
CREATE
Creates a data set. The data set must not exist on the volume. If the data set is cataloged and the
data set still exists on the volume pointed to by the catalog, specify the VOL keyword. In this case,
CATALOG=YES results in an update of the catalog, but the original data set is not scratched. If
VOLROT=YES is specified and the data set is found during volume rotation, an error occurs and
the data set request is bypassed.
REPLACE
Replaces an existing data set. The data set specified in the DSN keyword must exist on the volume
pointed to by the catalog, or if VOL has been specified, on that volume. If VOLROT=YES was
specified and not enough space is on the volume originally containing the data set, another
volume is assigned and the catalog is updated.
MODDATA
Adds data to an existing data set when it exists. Creates a data set when it does not exist. If the
data set does exist, the keyword VOLROT has no meaning. When creating a data set, the rules
that are described under the CREATE option apply.
DSN
Describes the name of the data set operated on. The name must be a valid OS data set name.
GDG can be described by a relative number (+1) or by an absolute generation number. The data
set name must be defined in the CA Workload Automation CA 7 Edition database.
BLKSIZE
(Optional) Describes the output block size to be used for this data set. The rules for BLKSIZE are
described in the BLKSIZE keyword of the OPTION Statement.
CATALOG
(Optional) Indicates whether to catalog the data set after a successful operation.
NO
Specifies that the system catalog is not modified.
Default: NO
08-Feb-2018 100/722
Default: NO
YES
Specifies to catalog the data set.
Can also be used to catalog a data set being created, replaced, or modified.
DETLIST
(Optional) Specifies whether to produce a detail list of all statements entered.
YES
Produces a detail list of all statements entered.
Default: YES
NO
Lists only control statements and messages.
JOBS
(Optional) Indicates that a data set request is to occur only if the specified job or jobs have run
after the last data set update. A maximum of ten jobs can be entered with this keyword unless
MAXJOBS has been entered on the OPTION statement to increase the maximum number. If more
than one job is entered, the group of job names must be enclosed in parentheses. The JOBS
keyword is the only keyword whose operand can be continued. If continued, place a comma after
the last job name on a statement. The next job name can start anywhere on the next statement.
The right parenthesis must appear immediately after the last job name.
LTERM
(Optional) Overrides the default logical terminal and follows the rules that are described in the
LTERM keyword of the OPTION Statement. If present, this keyword overrides the default only for
this data set.
REQSAT
(Optional) Described in the OPTION Statement. If present, it overrides the default only for this
data set.
SCHID
(Optional) Specifies which schedule ID created the data set. This value overrides the default
schedule ID. SCHID is described in the OPTION Statement.
VOL
(Optional) Indicates the volume to be used for this data set. The keyword overrides the catalog if
the data set is cataloged. If a volume is entered, it must be described with a U7xxxxxx DD
statement. If VOLROT=YES is specified and there is insufficient space on the volume, another
volume is chosen. If VOLROT=NO or is defaulted, an insufficient space condition results in an error.
Specific Requests. If VOL is not specified, the system catalog is searched in an attempt to locate
the data set. If the data set is located in the system catalog and on the volume pointed to by the
system catalog, the data set is replaced or added to on the volume. If a data set is not found for a
REPLACE, an error has occurred. If a data set is found for a CREATE, an error has occurred. If a
data set is found for a MODDATA, data is added to the data set. If the data set is not found for a
MODDATA, the data set is created.
Nonspecific Requests. If a CREATE request is encountered or if a MODDATA data set is not found,
and the VOL parameter is not present, the data set is assigned to the first U7xxxxxx volume. If
08-Feb-2018 101/722
and the VOL parameter is not present, the data set is assigned to the first U7xxxxxx volume. If
there is insufficient space on that volume, an attempt is made to obtain space on subsequent
volumes. Volumes are assigned in the same sequence as their respective DD statements in the job
stream.
Note: For nonspecific requests, the U7xxxxxx JCL statements must specify a volume, or the
first U7xxxxxx must be named U7VOLSER.
VOLROT
data set.
CVOL
data set request.
End-of-Data Set (EODS) Statement

The end of data statement optionally indicates the end-of-statement input for a data set request. If
the EODS statement is omitted, an EODS is generated if another control statement is encountered. If
EODS is entered, another data set request control statement or end-of-file must follow it.

*UCC7 EODS
A null data set is created when no data statements follow the control statement. You can use this
method to indicate no transaction input is available for today's run of a job.
Control Statements Examples

This article includes multiple examples to demonstrate how to use Control Statements.
This example creates data set A on volume 111111. The data set is an input requirement for JOB
Z. The data set is set for cataloging after creation. The BCLP control statements appear as follows.
*UCC7 CREATE DSN=A,VOL=111111,CATALOG=YES
statement1
statement2
*UCC7 EODS
Note: Because the default of REQSAT is YES, the keyword is not required.
All keywords not entered use default values.

The EODS statement is optional.
A U7xxxxxx DD statement must define volume 111111.
This example is the same as Example 1, with the addition that JOB Z must have run after the last
creation.
08-Feb-2018 102/722
*UCC7 CREATE DSN=A,VOL=111111,CATALOG=YES,
*UCC7 JOBS=Z
statement1
statement2
*UCC7 EODS
This example replaces cataloged data set A.

*UCC7 REPLACE DSN=A
statement3
statement4
statement5
Note: Because the data set was cataloged, VOL and CATALOG are not required.
An EODS statement is generated.

A U7xxxxxx DD statement must define the volume on which the data set is cataloged.
This example adds data to the end of a cataloged data set B. JOBS X, Y, and Z must have run after
the last update of data set B.
*UCC7 MODDATA DSN=B,JOBS=(X,Y,Z)
statement M
statement N
.
.
.
.
statement Z
*UCC7 EODS
Note: If data set B does not exist on the volume, the MODDATA is changed to CREATE.
A U7xxxxxx DD statement must define the volume on which the data set does (or is going to) exist
This example replaces data set C. Data set C is not presently cataloged, but is set for cataloging
after this run.
*UCC7 REPLACE DSN=C,VOL=111111,CATALOG=YES
statement A
statement B
statement C
Note: A U7xxxxxx DD statement must define volume 111111.
Batch Terminal Interface (BTI)

The batch terminals let you process commands in batch as if from an online terminal. You can
perform many of the same commands available online in this manner:
When no CA 7 online terminal is available
08-Feb-2018 103/722
When no CA 7 online terminal is available
When you want hardcopy output from the commands performed
When you produce more than 255 pages of output
Each batch terminal is actually a pair of disk data sets, one input, and one output. These data sets
must be defined in the online CA Workload Automation CA 7® Edition JCL.
When using a batch terminal, ICOM does not have to be active on the CPU where SASSBSTR is
running. The batch terminal must have access to the Communications data set. However, when using
the trailer step, U7SVC or BCLP facilities, ICOM must be active on the CPU where it runs.
Commands must follow the same sequence as if using a CA 7 online terminal. Queue maintenance
commands, like XQ or XUPD, are unavailable in batch mode, and the DB.2.7 panel and other menu-
type panels.
Command Format and Sequence

The input to the program (SYSIN) consists of CA Workload Automation CA 7® Edition commands. The
/LOGON and /LOGOFF commands are the required first and last records, respectively, for each batch
terminal interface input data set. They must begin in column 1 of the record.
To log on, the format is:

/LOGON opid [,password]
opid
Specifies the required operator identification.
password
Specifies an optional password (site-specific).
Note: When using an external security interface, the /LOGON statement can be omitted,
and the batch terminal interface program generates one using an extracted security ID for
the user who submitted the BTI job.
The format of the DBM batch commands consists of placing the equivalent panel top line command
by itself in the first statement. In the second and following statements are the function, positional
parameters and optional keywords. Statements begin in column 1. If the statement is to be
continued, it must end with a comma following the last value entered. There must be a nonblank
character in column 72 and the next statement must begin in column 1.
In the following, notice that function is a positional parameter and must appear where it is shown.
command function,positional-parameter,optional-keywords...
The following is an example of the command format:

JOB ADD,jobname,SYSTEM=sys,...,(other optional keywords)
To terminate database maintenance mode, enter DBM starting in column 1. For example:
08-Feb-2018 104/722
To terminate database maintenance mode, enter DBM starting in column 1. For example:
/LOGON JOB ADD,ACCT001,SYSTEM=S1 UPD,ACCTPAY,USERID=003 JOBCONN UPD,JDEP,ACCTPAY,
DEPJOB=ACCT001,OPT=C DBM LJOB,JOB=ACCTPAY,LIST=RQMT /LOGOFF
To log out, the format is:

/LOGOFF
DBM List Functions

The DBM LIST function in batch commands only validates the existence of the target. The function
does not actually provide an image of the equivalent online formatted panel containing field names
and values. For example:
JOB LIST,ACCTPAY
The example does not list the ACCTPAY job. The example does indicate that it either found or did not
find the job.
Batch Commands
This article explains common batch commands.
Non-DBM Batch Commands (see page 105)

Installation Batch Process Commands (see page 106)
DBM List Functions (see page 106)
Non-DBM Batch Commands

Non-DBM batch commands are similar to DBM commands in that they must:
Be card-image statements
Have a preceding /LOGON statement
Have a /LOGOFF statement that follows
Have a comma after the last value on a statement if you want to continue that statement. Do not
go past column 71.
Begin in column 1 regardless of whether it is a new or continued statement
Although the formats for DBM and non-DBM commands have many similarities, they have a
significant difference:
For non-DBM commands, the batch statement format is the same as the online top line format of
the command:
command(,positional parameter) [keyword=parm,...]
For example:
LPROS,JOB=jobname
08-Feb-2018 105/722
Installation Batch Process Commands

The CA Workload Automation CA 7® Edition installation (or SYSGEN) process creates a job, N220,
which includes many commands in BTI format. These commands perform database maintenance
(DBM) functions and some inquiry functions.
These commands provide a good example of how to use the BTI facility effectively. The user can
benefit from reviewing that data and understanding better how this facility can help accomplish
many user needs.
Note: Do not run the N220 job itself while CA Workload Automation CA 7 Edition is active
online. The N220 job is an execution of CA Workload Automation CA 7 Edition in batch
mode. The same commands, however, can be used with the Batch Terminal Interface
program. The batch commands for job N220 reside in member N220DECK in the JCLLIB
from installation. Check with your installation specialist at your installation or systems
programmer who installed CA Workload Automation CA 7 Edition for the data set name.
DBM List Functions

The DBM LIST function in batch commands only validates the existence of the target. The function
does not provide an image of the equivalent online formatted panel containing field names and
values.
For example:
JOB
LIST,ACCTPAY
The example does not list the ACCTPAY job. The example does indicate that it found or did not find
the job.
Use the Batch Terminal Interface

The following topics explain how to use the batch terminal interface:
Processing Flow (see page 106)

CA7BTI JCL Procedure (see page 107)
JCL Parameters (see page 108)
Sample BTI JCL (see page 109)
Processing Flow
The batch terminal interface program (SASSBSTR) controls the BTI processing flow. The program
performs the following functions:
Locates and allocates an available pair of batch terminal data sets.
Copies SYSIN data to the BATCHIN data set.
Requests processing by CA Workload Automation CA 7® Edition of the contents of the BATCHIN
08-Feb-2018 106/722
Requests processing by CA Workload Automation CA 7® Edition of the contents of the BATCHIN

data set.
Waits for CA Workload Automation CA 7 Edition to process the commands in the input data set
and place responses in the output data set.
Copies output (from the processing) from the BATCHOUT data set to the SYSPRINT data set.
If the user-defined batch error message table module SASSXXBT is available, each line of output is
compared against entries in the table. If matched, a message is written to the ERRORS DD (if
available). Also, the matching table entry return code is saved when it is higher than any
previously saved return code.
The following return codes are possible:
0
Indicates that the SASSBSTR program successfully completed its functions without detecting an
error. SASSBSTR does not validate that CA Workload Automation CA 7 Edition successfully
processed the SYSIN commands.
8
Indicates that SASSBSTR detected an error condition that prevented successful completion of its
tasks. Usually, a WTO or message in the SYSPRINT is issued indicating the error condition.
Note: If a /SHUTDOWN, Z3 is done with the batch terminal, it gets a return code of 8.
16
Indicates that a security violation occurred that prevented successful execution of SASSBSTR.
Usage of the SASSXXBT message table can generate more return code values.
Never cancel a BTI job while it is executing. This cancel does not interrupt the execution of the CA
Workload Automation CA 7 Edition commands that the BTI has given to CA Workload Automation CA
7 Edition to process on the specified (or pooled) batch terminal. All these commands have to
complete before CA Workload Automation CA 7 Edition can make the batch terminal available for
another BTI execution.
If you do a cancel, possibly the only way to recover (reuse) that batch terminal is to run another BTI
specifying the appropriate ID number. This run causes CA Workload Automation CA 7 Edition to
produce the CA-7.252 WTOR. A reply of RESET lets the BTI proceed. However, if the previous BTI
commands have not yet completed, the current BTI still fails. No BTI using pooling can use the same
ID again of the canceled one until your recycle of CA Workload Automation CA 7 Edition or the use of
the preceding procedure.
CA7BTI JCL Procedure

The CA Workload Automation CA 7 Edition installation procedures generate a batch terminal
interface JCL procedure to use for BTI jobs. The default name of the procedure is CA7BTI. This
procedure is initially found in the system-generated JCLLIB. You csn copy it to a procedure library if
job N020 is executed.
//CA7BTI PROC ID=0,POOL='1-8',DSNPFX=,OPT=,CA7=CA7n,PG=SASSBSTR
//BTERM EXEC PGM=&PG,
// PARM='&ID,POOL=(&POOL),DSNPFX=&DSNPFX,CA7=&CA7,&OPT'
08-Feb-2018 107/722
// PARM='&ID,POOL=(&POOL),DSNPFX=&DSNPFX,CA7=&CA7,&OPT'
//UCC7CMDS DD DISP=SHR,DSN=cai.ca7.commds
//SYSPRINT DD SYSOUT=*,DCB=BLKSIZE=133
//ERRORS DD SYSOUT=*,DCB=BLKSIZE=133
//SYMDUMP DD DUMMY
JCL Parameters
The PARM values for SASSBSTR are shown in the following format:
PARM=(n,POOL=(x-y,b,c),DSNPFX='batch dsn prefix.',CA7=instance,NOMCHK,NOWAIT)
n
Can be 0 or specific BTI terminal. A value of 0 (zero) indicates using Dynamic BTI Management.
(The program automatically locates and uses an available BTI terminal.) A specific BTI terminal
number (1-8) indicates that the program uses that specific batch terminal. If that terminal is
already in use by another job, the current job checks every 5 seconds. The job checks for a total of
one minute to see if the terminal becomes available. If the terminal is still unavailable, a CA-7.252
WTOR is issued. You can decide whether you want this job to wait for the terminal to become
available or cancel this job. Remember that if a specific BTI terminal number is coded, then the
POOL parameter is ignored.
POOL=(x-y,b,c)
The POOL= keyword can be used with Dynamic BTI Management to specify the pool of batch
terminals to be considered when searching for an available terminal. POOL= can be specified as a
range of terminals x-y, as a list of terminals b,c,..., or both. The default terminal pool is all eight
possible batch terminals.
The POOL= parameter can be used to reserve particular batch terminals for specific jobs. If these
terminal numbers are excluded from the pool, Dynamic BTI Management never allocates them.
Thus, they should always be available for BTI executions that reference them specifically.
If all batch terminals in the pool are busy, the BTI program enters a cycle where it looks for an
available batch terminal every 5 seconds. This cycle continues for 5 minutes. If no batch terminals
have become available during that time, WTOR CA-7.253 is issued. If you have a system problem,
the operator can reply CANCEL to terminate the BTI job with a return code of 8. If a reply of WAIT
is issued, the BTI program continues its wait/check cycle indefinitely. If several BTI jobs are
waiting on any available batch terminal, there is no serialization in the order in which they obtain
a terminal.
DSNPFX='batch.dsn.prefix.'
Specifies the high-level qualifier (hlq) for the BATCHIN and BATCHOUT data sets. This hlq must
match the hlq for the BATCHI#x and BATCHO#x data sets that are defined to the CA 7 started
task. The BTI program dynamically allocates the BATCHIN and BATCHOUT files that are associated
with a specific batch terminal. Normally, the BTI program constructs the data set names for these
files using the data set name prefix from the CA Workload Automation CA 7 Edition
communication data set (UCC7CMDS DD). The suffix BATCHI#n/BATCHO#n is appended to the
prefix to construct the full data set names (where n is the associated batch terminal number). This
parameter is only needed if the hlq of the BATCHI#x and BATCHO#x is not the same as the hlq for
the COMMDS.
Note: If a specific batch terminal (1-8) is specified and the BATCHIN and BATCHOUT DDs in
the BTI JCL are coded, no dynamic allocation occurs.
08-Feb-2018 108/722
CA7
Specifies the instance of CA Workload Automation CA 7 Edition used to determine whether
submit checking is turned on. The instance can be one of the following values. The default is
CA7=CA71.
CA7n
Specifies the true instance name to use where n is a value from 1 through 8.
alias
Defines a one- to four-character alias specified at CA Workload Automation CA 7 Edition
resource initialization.
PROD
Defaults to instance CA71.
UC07
TEST
UCT7
NOMCHK
Suppresses BTI output message checking against the SASSXXBT message table. If this parameter is
not specified and a user-coded SASSXXBT table module is available, the message checking is done.
NOWAIT
If this parameter is specified, BTI terminates with an RC=8 if CA Workload Automation CA 7
Edition is not active when the BTI job starts. If this parameter is not specified and the CA
Workload Automation CA 7 Edition address space is not active when the BTI process starts, it
issues a WTOR (CA-7.255) and it waits for CA Workload Automation CA 7 Edition. When CA
Workload Automation CA 7 Edition becomes active, BTI processing continues without any
intervention.
If no PARM data is supplied to SASSBSTR, an ID of 0 is used.
Sample BTI JCL

This example shows a job using the CA7BTI procedure.
//JS10 EXEC CA7BTI
//SYSIN DD *
.....
.....
.....
.....
/*
//
08-Feb-2018 109/722
Interface with CAICCI

The CA Workload Automation CA 7® Edition CAICCI interface uses the CA Common Communications
Interface (CAICCI) to send batch commands to, and receive command output from the CA Workload
Automation CA 7 Edition address space. The interface can be executed from batch, from a REXX
address environment, or in a program-to-program mode. Because the interface uses CAICCI, no
requirement exists for shared DASD between the MVS images where CA Workload Automation CA 7
Edition executes and where the CA Workload Automation CA 7 Edition CAICCI interface environment
executes.
CAICCI is a CA common component that lets CA applications communicate with each other without
dealing with the specifics of a particular communication protocol. The actual transfer of data can be
in the form of cross-memory, VTAM to VTAM connection, or some form of TCP/IP connection.
However, the application code is not dependent on any particular protocol. CAICCI is a
subcomponent of the CAIENF (Event Notification Facility) common component.
The CA Workload Automation CA 7 Edition CAICCI interface establishes communication with the CA
Workload Automation CA 7 Edition CAICCI receiver in the CA Workload Automation CA 7 Edition
address space. This receiver is created when one or more CA Workload Automation CA 7 Edition
CAICCI terminals (DEVICE=CCI) are defined in the CA Workload Automation CA 7 Edition initialization
file.
The CA Workload Automation CA 7 Edition CAICCI interface uses the CA Workload Automation CA 7
Edition batch format for CA Workload Automation CA 7 Edition commands. The output from these
commands is also returned in the CA Workload Automation CA 7 Edition batch format. For more
information about CA Workload Automation CA 7 Edition batch formats, see the batch information.
When continuing a command input for CAICCI, the following rules apply:
Have a comma and the chosen command separator (the default is a semicolon (;)) after the last
value on a statement when that statement continues. Do not go past column 71.
Begin in column 1 regardless of whether it is a new or continued statement.
In the REXX and program-to-program interfaces, you can code a command as one single string. If
a single command is more than 80 bytes, code a command separator (the default is a semicolon)
after a comma and before displacement 79.
Note: For information about implementing CAICCI, see Administrating at CA Common

Services for z/OS (https://docops.ca.com/docops.ca.com/ccszos).
More information:
Batch Terminal Interface (BTI) (https://wiki.ca.com/pages/viewpage.action?

pageId=134845050)
08-Feb-2018 110/722
CAICCI Usage Notes

In general, use CAICCI terminals for short-running CA Workload Automation CA 7® Edition commands
that do not generate much output.
CAICCI must be active on both the MVS image where the CA Workload Automation CA 7 Edition
address space is executing and where the CA Workload Automation CA 7 Edition CAICCI interface
environment is executing. A CAICCI connection between these systems must exist.
The CA Workload Automation CA 7 Edition address space must be active.
There must be one or more CA Workload Automation CA 7 Edition CAICCI terminals (DEVICE=CCI)
defined and active in the CA Workload Automation CA 7 Edition address space. If you execute long-
running commands, the associated CAICCI terminal is not available for other commands until the first
command is complete. Consider using a batch terminal (BTI) for long-running commands such as
large forecasts or generic RESOLVes.
A valid CA Workload Automation CA 7 Edition operator ID must either be supplied explicitly in a

/LOGON command, or the security owner of the environment where the CA Workload Automation
CA 7 Edition CAICCI interface is executing must be a valid CA Workload Automation CA 7 Edition
operator.
No requirement exists for shared DASD between the MVS image where the CA Workload Automation
CA 7 Edition CAICCI interface executes and the image where CA Workload Automation CA 7 Edition
itself executes.
CA7ICOM is not required to execute on the MVS image where the CA Workload Automation CA 7
Edition CAICCI interface executes.
If no CAICCI terminal is available for two minutes, then the "connection" fails, and an appropriate
message is produced.
The CA Workload Automation CA 7 Edition CAICCI receiver name in the CA Workload Automation CA
7 Edition address space is CA-7. XTM xxxx, where xxxx is the CA 7 instance name, or a value specified
on the XTMNAME= keyword of the SVCNO statement in the initialization file.
Before r11, the default values for CA Workload Automation CA 7 Edition instance names (previously
called SSCT names) were UC07 for the production copy (alias of PROD) and UCT7 for the test copy
(alias of TEST). Starting with r11, the default instance name for PROD is CA71, and the default
instance name for TEST is CA72. To make the transition from previous releases smoother, the
interface can automatically search for alternate instance names if the requested instance is not
found. This substitution is made under the following conditions:
If instance=PROD and CA71 is not found, the search looks for instance UC07 if the local CA
Workload Automation CA 7 Edition system environment is in release compatibility mode.
If instance=TEST and CA72 is not found, the search looks for instance UCT7 if the local CA
Workload Automation CA 7 Edition system environment is in release compatibility mode.
If instance=UC07 and UC07 is not found, the search looks for instance CA71 if the local CA
Workload Automation CA 7 Edition system environment is not in release compatibility mode.
If instance=UCT7 and UCT7 is not found, the search looks for instance CA72 if the local CA
08-Feb-2018 111/722
If instance=UCT7 and UCT7 is not found, the search looks for instance CA72 if the local CA
Workload Automation CA 7 Edition system environment is not in release compatibility mode.
If a different instance is successfully substituted, Message CAL2C405I is issued.
More information:
Command Format and Sequence (https://wiki.ca.com/display/CWAC7E

/Command+Format+and+Sequence)
Execute the CAICCI Batch Interface

The CAICCI Batch Interface program (CAL2X2WB) lets you send commands to CA Workload
Automation CA 7® Edition. You receive the output from those commands as a step in a batch job.
The CAL2X2WB program does the following tasks:
Reads the commands to process from SYSIN and builds a command block.
Calls the CA Workload Automation CA 7 Edition CAICCI interface module CAL2X2W0 passing the
command block.
Receives CA Workload Automation CA 7 Edition command output through CAL2X2W0 and writes
each line to SYSPRINT.
available). Also, the matching table entry return code is saved when it is higher than any
previously saved return code.
CAL2X2WB JCL
Sample JCL to execute the CA Workload Automation CA 7 Edition CAICCI Batch Interface is in JCLLIB
member CA07N550. The prefix can have changed based on the SYSGEN.
You can specify the following optional parameters on the EXEC statement:
PARM='cci node,instance name,options,cmdin ddname,cmdout ddname,errors ddname'
CCI NODE
Specifies the CAICCI node name where the CA Workload Automation CA 7 Edition address space is
executing. The default is to attempt to communicate with a CA Workload Automation CA 7
Edition executing at the same CAICCI node where the batch job is executing (local node).
Note: The reserved value *AUTO* can be used to indicate that the CA Workload
Automation CA 7 Edition CAICCI interface should attempt to locate dynamically the CAICCI
node where a CA Workload Automation CA 7 Edition with a matching instance name
resides.
INSTANCE NAME
08-Feb-2018 112/722
INSTANCE NAME
Specifies the instance name of the CA Workload Automation CA 7 Edition you want to
communicate with. The primary copy of CA Workload Automation CA 7 Edition (named the
production copy in r3.3) has an instance name of CA71. The secondary copy of CA Workload
Automation CA 7 Edition (named the test copy in r3.3) has an instance name of CA72. Other
values include instance names CA73 through CA78 and a 1-4 character alias if one was set at CA
Workload Automation CA 7 Edition resource initialization. The value PROD can be used instead of
CA71 and the value TEST can be used instead of CA72. For more information about instance
names, see Usage Considerations.
OPTIONS
Specifies a one- to four-character option string:
TRACE OPTION
If set to 'Y' it turns on diagnostic WTOs for the CA Workload Automation CA 7 Edition CAICCI
interface process. Any value other than a capital Y results in no trace. The default is no trace.
CMD SEPARATOR
The character that is used to separate commands when they are read from SYSIN and they are
stacked into a command block. The default command separator character is a semicolon (;).
-- unused --
The third and fourth characters of the options are reserved for future use.
CMDIN DDNAME
Specifies the ddname of the source for CA Workload Automation CA 7 Edition commands. The
default is SYSIN.
CMDOUT DDNAME
Specifies the ddname for the CA Workload Automation CA 7 Edition command output. The
default is SYSPRINT.
ERRORS DDNAME
Specifies the ddname for messages. The messages are produced when a CA Workload
Automation CA 7 Edition command output line matches an entry in the batch error message
table, SASSXXBT. The default is ERRORS.
If you do not want error message checking to occur, even when a SASSXXBT table is available,
specify *NOMCHK* as the override ddname in the parameter list.
CAL2X2WB Return Codes

Module CAL2X2WB issues WTO CAL2C509I when processing completes that lists the return code and
condition code for the process. The possible return and condition codes from CAL2X2WB are as
follows:
0
Indicates that the CAL2X2WB program successfully completed its functions without detecting an
error.
8
Indicates a processing error:
08-Feb-2018 113/722
CC=1
No valid CA Workload Automation CA 7 Edition commands were read from SYSIN.
CC=2
No command output responses were received from CA Workload Automation CA 7 Edition.
CC=8
Nonzero return code from the CAICCI interface module (CAL2X2W0). See Message
CAL2C596E.
CC=9
Error attempting to GETMAIN storage. See Message CAL2C594E.
CC=10
Error attempting to LOAD a needed module. See Message CAL2C595E.
16
Indicates a parameter list error:
CC=1
Invalid parameter list. See Message CAL2C590E.
CC=2
Invalid parameter value. See Message CAL2C591E.
CC=3
Required DD statement missing or invalid. See Message CAL2C592E.
CC=4
DCB open error. See Message CAL2C593E.
Note: Usage of the SASSXXBT error message table can generate more return code values.
More information:
Batch Interface Message Table - SASSXXBT (https://wiki.ca.com/display/CWAC7E

/Batch+Interface+Message+Table+-+SASSXXBT)
Execute the CAICCI REXX Interface

The CAICCI REXX interface programs (CAL2X2WA and CAL2X2WR) let you send commands to CA
Workload Automation CA 7® Edition and receive the output from those commands in a REXX
environment. Program CAL2X2WA establishes the REXX CA Workload Automation CA 7 Edition
address environment, and program CAL2X2WR processes the command handling.
A REXX example is provided in the CAL2CLS0 installation library. The sample EXEC is CA7REXX. Copy
08-Feb-2018 114/722
A REXX example is provided in the CAL2CLS0 installation library. The sample EXEC is CA7REXX. Copy
this member to the SYSEXEC or SYSPROC concatenation for the TSO environment. Follow the
instructions included in the member for execution.
Note: The reserved value *AUTO* can be used for the ca7_node variable value. *AUTO*
indicates that the CA Workload Automation CA 7 Edition CAICCI interface attempts
dynamically to locate the CAICCI node. The node is where a CA Workload Automation CA 7
Edition with a matching instance name resides.
You can explicitly set the name that is used to identify the CAICCI receiver for a given copy of CA
Workload Automation CA 7 Edition. Use the XTMNAME or RNAME keywords of the SVCNO statement
in the initialization file. This name lets each copy of CA Workload Automation CA 7 Edition be unique
across a CAICCI network even though more than one can be production or test copies. Assignment of
unique CAICCI receiver names allows the *AUTO* ca7_node variable to be used dynamically to target
a specific copy of CA Workload Automation CA 7 Edition.
CA GSS REXX Address Environment Interface Execution

OPS/REXX is the REXX implementation that CA OPS/MVS® Event Management uses. OPS/REXX uses
CA GSS to execute CA Workload Automation CA 7 Edition commands and return the response lines to
the external data queue (stack) of the OPS/REXX program that issues the ADDRESS CA7 command.
A sample CA7OPSRX OPS/REXX EXEC is in the CAL2CLS0 installation library. Copy this EXEC to a data
set in your SYSEXEC concatenation.
Add the following statement to the CA GSS initialization parameters:

ADDRESS CA7 CAL2X2WR 15 TYPE 0
Also, the following variables can be customized as needed using the following CA GSS initialization
parameters:
GLOBVAL &CA7_NODE /xxxxxxxx/
/* CCI Node where CA 7 resides (default - local node) */
GLOBVAL &CA7_SSCT /xxxx/ /* CA 7 instance name (CA71-CA78) */
GLOBVAL &CA7_DEBUG /xxxx/ /* CA 7 CCI interface options */
Address commands can be established for multiple copies of CA Workload Automation CA 7 Edition
in the same CA GSS environment. For each copy, add an ADDRESS statement with a unique one- to
four-character name and global variables with the name as the prefix. For example, assume that you
want to establish ADDRESS commands for a primary copy of CA Workload Automation CA 7 Edition,
CA7, and a second copy, in this case CA72. Add the following CA GSS initialization parameters:

GLOBVAL &CA7_NODE /xxxxxxxx/ /* Node where primary CA 7 resides */
GLOBVAL &CA7_SSCT /xxxx/ /* Instance name for primary CA 7 */
GLOBVAL &CA7_DEBUG /xxxx/ /* Optional Debug options */

GLOBVAL &CA72_NODE /xxxxxxxx/ /* Node where second CA 7 resides */
GLOBVAL &CA72_SSCT /xxxx/ /* Instance name for second CA 7 */
GLOBVAL &CA72_DEBUG /xxxx/ /* Optional Debug options */
08-Feb-2018 115/722
Note: You can use the reserved value *AUTO*. *AUTO* indicates that the CA Workload
Automation CA 7 Edition CAICCI interface attempts dynamically to locate the CAICCI node
where a CA Workload Automation CA 7 Edition with a matching instance name resides.
Because the character string '/*' indicates the start of a comment, use a delimiter other
than slash if you are going to specify *AUTO*. For example: GLOBVAL &CA7_NODE ?
*AUTO*?
You can explicitly set the name that is used to identify the CAICCI receiver for a given copy of CA
Workload Automation CA 7 Edition. Use the XTMNAME or RNAME keywords of the SVCNO statement
in the initialization file. This setting lets each copy of CA Workload Automation CA 7 Edition be unique
across a CAICCI network even though more than one can be production or test copies. Assignment of
unique CAICCI receiver names allows the *AUTO* &CA7_NODE variable to be used dynamically to
target a specific copy of CA Workload Automation CA 7 Edition.
Execute the CAICCI Program-to-Program Interface

Another program can call the CA Workload Automation CA 7® Edition CAICCI Program-to-Program
Interface (CAL2X2WP) directly. The calling program passes a string of CA Workload Automation CA 7
Edition batch commands. CAL2X2WP interfaces with CA Workload Automation CA 7 Edition and
builds a buffer in storage that contains the command responses from CA Workload Automation CA 7
Edition. The calling program can then parse the responses and take other appropriate actions that
are based on the results.
Call CAL2X2WP
To invoke the CAICCI Program-to-Program Interface, the CA Workload Automation CA 7 Edition load
library must be available to the program being executed. A standard parameter list is passed in
register 1. The format of the parameter list is:
+0
Address of the CA Workload Automation CA 7 Edition batch command string. If you have more
than one command, separate them with a command separator character. The default is
semicolon (;). This parameter is required.
+4
Length of the string of CA Workload Automation CA 7 Edition batch commands, and this
parameter is required.
+8
Address of an 8-byte field where the address and length of the CA Workload Automation CA 7
Edition response buffer is placed. The first 4 bytes contain the address, and the second 4 bytes
contain the length of the buffer. If the caller wants the response buffer to be in storage above the
16-MB line, have the first byte of the 8-byte field contain the value X'80'. Otherwise, the buffer
storage is GETMAINed below the 16-MB line. This parameter is required.
Warning! The caller is responsible to FREEMAIN the response buffer storage.
08-Feb-2018 116/722
+12
Pointer to a 64-byte field that contains the CAICCI node name where the CA Workload
Automation CA 7 Edition address space executes. The default is the local node. This parameter is
optional.
Note: You can use the reserved value *AUTO*. *AUTO* indicates that the CA Workload
Automation CA 7 Edition CAICCI interface attempts dynamically to locate the CAICCI node.
The node is where a CA Workload Automation CA 7 Edition with a matching CA 7 instance
name resides.
+16
Pointer to the instance name of the CA Workload Automation CA 7 Edition to communicate with.
The value CA71 or PROD can be used to indicate the primary instance. The value CA72 or TEST
can be used to indicate the secondary, or "test" instance. Other values include instance names
CA73 through CA78 and a 1-4 character alias if one was set at CA Workload Automation CA 7
Edition resource initialization.
For more information about instance names, see Usage Considerations.
Note: You can explicitly set the name that is used to identify the CAICCI receiver for a
given copy of CA Workload Automation CA 7 Edition. Use the XTMNAME or RNAME
keywords of the SVCNO statement in the initialization file. This setting lets each copy of CA
Workload Automation CA 7 Edition be unique across a CAICCI network even though more
than one can be production or test copies. Assignment of unique CAICCI receiver names
lets the *AUTO* CA-7 CAICCI node parameter be used dynamically to target a specific
copy.
+20
Pointer to a four-character Options field. The first character indicates whether to generate
diagnostic trace messages (value of Y). The default is not to produce trace messages. The second
character can specify the command string separator character. Any nonblank not null character
can be used as a command separator. The default separator is a semicolon (;). The third and
fourth characters are reserved for future use. This parameter is optional.
CAL2X2WP Response Buffer

The response buffer that CAL2X2WP returned contains all the output lines received from CA
Workload Automation CA 7 Edition in response to the command string provided. If CA Workload
Automation CA 7 Edition received no responses because of an error, no response buffer is created.
The address/length field that the caller supplied is null. If an error was encountered after CAL2X2WP
began receiving responses from CA Workload Automation CA 7 Edition, a response buffer is still
created. The address and length are set in the address/length field of the caller.
Warning! You can receive a nonzero return code from CAL2X2WP and still have a response
buffer.
08-Feb-2018 117/722
The CA Workload Automation CA 7 Edition responses in the response buffer are fixed-length records.
Each record is 133 bytes in length. If you want to calculate the number of lines in the buffer, simply
divide the overall length by 133. Each response is blank-padded and begins with a carriage control
character.
The caller is responsible to FREEMAIN the response buffer once it is no longer needed. The buffer is
obtained from subpool 0. Assume that the first byte of the 8-byte address/length field of the caller
contains X'80' on entry to CAL2X2WP. In this case, the response buffer is obtained from storage
above the 16-MB line (LOC=ANY GETMAIN option).
Warning! The caller is responsible for freeing the response buffer storage.
CAL2X2WP Return Codes

On exit from module CAL2X2WP, the return code is in register 15, and the condition code is in
register 0. The following return and condition codes from CAL2X2WP are possible:
0
Indicates that the CAL2X2WP program successfully completed its functions without detecting an
error.
4
Indicates no responses from CA Workload Automation CA 7 Edition received.
8
CC=9
Error attempting to GETMAIN storage
CC=10
Error attempting to LOAD a needed module
12
Indicates error return from CAL2X2W0 (nonabend)
CC=
AL2(CAL2X2W0 rc),AL2(CAL2X2W0 cc)
16
Indicates parameter list error:
CC=1
Invalid parameter list
CC=2
Invalid parameter value
08-Feb-2018 118/722
20
Indicates error return from CAL2X2W0 (abend).
CC=
Sxxx or Uxxxx that is the printable abend code.
Sample Invocation of CAL2X2WP

The following sample is an invocation of CAL2X2WP:
X2WPSAMP START
*--------------------------------------------------------------------*
* SAMPLE PROGRAM TO CALL CA 7 CCI PROGRAM-TO-PROGRAM INTERFACE *
*--------------------------------------------------------------------*
SASSVRSN VRSN=TST,LINK=OS,REGS=R10,EQU=YES
*
LA R1,X2WPPARM * R1 -> PARM LIST
LINK EP=CAL2X2WP * CALL CA 7 CCI PGM-PGM
*
CLC BUFFADR,=A(0) * ANY CA 7 RESPONSES ?
BE #UCC7RET * NO - EXIT WITH RC
L R2,BUFFADR * R2 -> RESPONSES
L R3,BUFFLEN * R3 = BUFFER LENGTH
LA R3,0(R2,R3) * R3 -> END OF RESPONSES
LOOP DS 0H
CLC SPO700,0(R2) * GOOD DEMAND RESPONSE ?
BE GOOD * YES - EXIT LOOP
LA R2,133(,R2) * R2 -> NEXT LINE
CR R2,R3 * REACHED END ?
BL LOOP * NO - CYCLE
WTO 'X2WPSAMP : JOB DEMAND NOT SUCCESSFUL '
B #UCC7RET * BRANCH TO PROGRAM EXIT
*
GOOD DS 0H
WTO 'X2WPSAMP : JOB DEMANDED SUCCESSFULLY '
B #UCC7RET * BRANCH TO PROGRAM EXIT
*
SPO700 DC CL10' SPO7-00 ' * GOOD DEMAND MSG PREFIX
*
X2WPPARM DS 0F * CA 7 CCI IFACE PARM LIST
DC A(CMDLIST) * ADDRESS OF COMMAND STRING
DC A(CMDLISTL) * LENGTH OF COMMAND STRING
DC A(BUFFSET) * BUFFER ADDRESS/LENGTH FIELD
DC X'80',AL3(0) * END OF PARMLIST
*
BUFFSET DS 0D * SPOT FOR BUFFER ADDR/LENGTH
BUFFADR DC A(0) * ADDR OF CA 7 RESPONSE BUFFER
BUFFLEN DC F'0' * LENG OF CA 7 RESPONSE BUFFER
*
CMDLIST DC 0C
* DC C'CA7=CA7n;' (REQUIRED IF INSTANCE NOT CA71)
DC C'/LOGON USERX;DEMAND,JOB=TESTJOB;/LOGOFF'
CMDLISTL EQU (L'CMDLIST)
*
END X2WPSAMP
Interface with TCP/IP

This article explains how CA Workload Automation CA 7® Edition can interface with TCP/IP. The CA
Workload Automation CA 7® Edition TCP/IP interface uses TCP/IP to send batch commands to, and
receive command output from, the CA Workload Automation CA 7 Edition address space. You can
execute the interface from batch, from a REXX address environment, or in a program-to-program
08-Feb-2018 119/722
execute the interface from batch, from a REXX address environment, or in a program-to-program
mode. Because the interface uses TCP/IP, no requirement exists for shared DASD between the MVS
image where CA Workload Automation CA 7 Edition executes and where the CA Workload
Automation CA 7 Edition TCP/IP environment executes.
The interface with TCP/IP establishes communication with the CA Workload Automation CA 7 Edition
TCP/IP server in the CA Workload Automation CA 7 Edition address space. This server is created at CA
Workload Automation CA 7 Edition initialization when the following items are present in the
initialization file:
One or more CAICCI terminals (DEVICE=CCI) are defined in the initialization file.
A TCPTPORT keyword is present on the UCC7VTAM statement in the initialization file.
The TCP/IP interface uses the CA Workload Automation CA 7 Edition batch format for CA Workload
Automation CA 7 Edition commands. The output from these commands is also returned in the batch
format.
When continuing a command input for the TCP/IP interface, the following rules apply:
Have a comma and the chosen command separator (the default is a semicolon (;)) after the last
value on a statement when that statement continues. Do not include any text past column 71.
Start in column 1 regardless of whether the statement is a new or a continued statement.
In the REXX and program-to-program interfaces, you can code a command as one string. If a
single command is more than 80 bytes long, code a command separator (the default is a
semicolon) after a comma and before displacement 79.
More information:
Batch Terminal Interface (BTI) (https://wiki.ca.com/pages/viewpage.action?

pageId=134845050)
TCIP/IP Usage Notes

TCP/IP must be active on both the MVS image where the CA Workload Automation CA 7® Edition
address space is executing and where the CA Workload Automation CA 7 Edition TCP/IP interface
environment is executing. A TCP/IP connection between these systems is necessary.
Depending on your local implementation of TCP/IP, it is sometimes necessary to add a //SYSTCPD DD

statement to your CA 7 online JCL.
The CA Workload Automation CA 7 Edition address space must be active.
The CAICCI terminals that are defined to CA Workload Automation CA 7 Edition are shared between
CAICCI and TCP/IP.
08-Feb-2018 120/722
One or more CA Workload Automation CA 7 Edition CAICCI terminals (DEVICE=CCI) must be defined
and active in the CA Workload Automation CA 7 Edition address space. If you execute long-running
commands, the associated CAICCI terminal is not available for other commands or for use with the
CAICCI interface until the first command is complete.
A valid CA Workload Automation CA 7 Edition operator ID must either be supplied explicitly in a

/LOGON command, or the security owner of the environment where the CA Workload Automation
CA 7 Edition TCP/IP interface is executing must be a valid CA Workload Automation CA 7 Edition
operator.
If the first command supplied is a /LOGON, make the last command supplied a /LOGOFF.
No requirement exists for shared DASD between the MVS image where the CA Workload Automation
CA 7 Edition TCP/IP environment executes and the image where CA Workload Automation CA 7
Edition itself executes.
If no CAICCI terminal is available for two minutes, the connection is refused and an appropriate
message is produced.
In general, use the CAICCI terminals for short-running CA Workload Automation CA 7 Edition
commands that do not generate much output.
To communicate with CA Workload Automation CA 7 Edition, the user must supply the following:
The TCP/IP address of the MVS image on which CA Workload Automation CA 7 Edition is
executing. The address is in one of two formats: presentation format (for example, abc.xyz.com (
http://abc.xyz.com)) or numeric format (nnn.nnn.nnn.nnn).
The port number that is assigned to the CA 7 instance to which commands are sent.
The instance name to which commands are sent if not CA71. CA71 is the default.
More information:
Command Format and Sequence (https://wiki.ca.com/display/CWAC7E

/Command+Format+and+Sequence)
Execute the TCP/IP Batch Interface

The TCP/IP batch interface program (CAL2X2TB) can send commands to CA Workload Automation CA
7® Edition and receive the output from those commands as a step in a batch job.
The CAL2X2TB program does the following:
Reads the commands to process from SYSIN and builds a command block.
Calls the CA Workload Automation CA 7 Edition TCP/IP interface module CAL2X2T0, passing the
command block.
Receives CA Workload Automation CA 7 Edition command output through CAL2X2T0 and writes
08-Feb-2018 121/722
Receives CA Workload Automation CA 7 Edition command output through CAL2X2T0 and writes
each line to SYSPRINT.
available). If the code is higher than any previously saved return code, the matching table entry
return code is saved.
CAL2X2TB JCL
Sample JCL to execute the CA Workload Automation CA 7 Edition TCP/IP Batch Interface is in JCLLIB
member CA07N560 (the prefix can differ based on the SYSGEN).
Note: Depending on your local implementation of TCP/IP, it is sometimes necessary to add

a //SYSTCPD DD statement to your CA Workload Automation CA 7 Edition batch interface
JCL.
You can specify the following parameters on the EXEC statement:

PARM=’tcpip address,tcpip port[,instance name,options,cmdin ddname,cmdout ddname,
errors ddname]’
TCP/IP ADDRESS
Specifies the TCP/IP address where the CA Workload Automation CA 7 Edition address space is
executing. Specify the address in one of two formats: presentation format (for example, abc.xyz.
com) or numeric format (nnn.nnn.nnn.nnn). The parameter has no default.
TCP/IP PORT
Specifies the port number that is assigned to the instance of CA Workload Automation CA 7
Edition with which you want to communicate. The maximum number is 65535. The parameter
has no default.
INSTANCE NAME
Specifies the instance name of the CA Workload Automation CA 7 Edition with which you want to
communicate (CA71-CA78). The default instance name is CA71. Aliases are not permitted.
OPTIONS
Specifies a one- to four-character option string.
TRACE OPTION
If set to Y, the option turns on diagnostic WTOs for the CA Workload Automation CA 7 Edition
TCP/IP interface process. Any value other than a capital Y results in no trace. The default is no
trace.
CMD SEPARATOR
Specifies the character that separates commands when they are read from SYSIN and are
stacked into a command block. The default command separator character is a semicolon (;).
unused
The third and fourth characters of the options are reserved for future use.
08-Feb-2018 122/722
CMDIN DDNAME
Specifies the ddname of the source for CA Workload Automation CA 7 Edition commands. The
default is SYSIN.
CMDOUT DDNAME
Specifies the ddname for the CA Workload Automation CA 7 Edition command output. The
default is SYSPRINT.
ERRORS DDNAME
Specifies the ddname for messages that are produced when a CA Workload Automation CA 7
Edition command output line matches an entry in the batch error message table, SASSXXBT. The
default is ERRORS.
If you do not want error message checking to occur, even when a SASSXXBT table is available,
specify *NOMCHK* as the override ddname in the parameter list.
CAL2X2TB Return Codes

When processing completes, module CAL2X2TB issues WTO CAL2T012I that lists the return code and
condition code for the process. The following return and condition codes are possible from
CAL2X2TB:
RC=0
Indicates that the CAL2X2TB program successfully completed its functions without detecting an
error.
RC=8
CC=6
No valid commands were read from SYSIN.
CC=7
No command output responses were received from CA Workload Automation CA 7 Edition.
CC=9
Nonzero return code from the TCP/IP interface module CAL2X2T0. See Message CAL2T011E.
CC=10
Error attempting to obtain storage. See Message CAL2T009E.
CC=11
Error attempting to LOAD a needed module. See Message CAL2T010E.
RC=16
CC=1
Invalid parameter list. See Message CAL2T004E.
CC=2
Invalid parameter list. See Message CAL2T005E.
CC=3
08-Feb-2018 123/722
CC=3
Required DD statement missing or invalid. See Message CAL2T006E.
CC=5
DCB open error. See Message CAL2T007E.
Note: Use of the SASSXXBT error message table can generate more return code values.
More information:
Batch Interface Message Table - SASSXXBT (https://wiki.ca.com/display/CWAC7E

/Batch+Interface+Message+Table+-+SASSXXBT)
CAL2X2T0 Condition Codes

Module CAL2X2T0 returns a return code and condition code to the calling interface routine. That
interface can report those condition codes. The following conditions codes are possible from
CAL2X2T0:
CC=Sxxx or Uxxxx
Printable abend code
CC=4
CA Workload Automation CA 7 Edition is not available. See Message CAL2T029E or other
message.
CC=8
Error attempting to LOAD a needed module. See Message CAL2T026E.
CC=12
Error attempting to get storage.
CC=16
CA Workload Automation CA 7 Edition could not initialize a session with a terminal. See Message
CAL2T034E.
CC=20
CA Workload Automation CA 7 Edition sent a buffer that had an invalid size. See Message
CAL2T035E.
CC=24
CA Workload Automation CA 7 Edition sent a nonzero return code.
CC=28
CAL2X2T0 received a record that was in the wrong format. See Message CAL2T030E.
CC=32
08-Feb-2018 124/722
CC=32
CAL2X2T0 received a record that was out of sequence. See Message CAL2T033E.
CC=36
A TCP/IP function returned a bad return code. See Message CAL2T025E.
CC=40
An error occurred while processing the command. See Message CAL2T040E.
Execute the REXX Interface

This article explains how you can use CA Workload Automation CA 7® Edition to receive command
output in a REXX environment.
The CA Workload Automation CA 7® Edition TCP/IP REXX interface programs (CAL2X2TA and
CAL2X2TR) can send commands to CA Workload Automation CA 7 Edition. The programs can receive
the output from those commands in a REXX environment. Program CAL2X2TA establishes the REXX
CA Workload Automation CA 7 Edition address environment and program CAL2X2TR processes the
command handling.

statement to your TSO online PROC.
The sample REXX EXEC is AL2REXXT in the CAL2CLS0 installation library. Follow the instruction in this
member as you place it into your TSO SYSEXEC or the SYSPROC concatenation.
CA GSS REXX Address Environment Interface Execution

OPS/REXX is the REXX implementation that CA OPS/MVS® Event Management uses. OPS/REXX uses
CA GSS in the following ways:
To execute CA Workload Automation CA 7 Edition commands.
To return the response lines to the external data queue (stack) of the OPS/REXX program that
issues the ADDRESS CA7T command.

statement to your TSO online PROC.
The sample OPS/REXX EXEC is AL2OPSRT in the CAL2CLS0 installation library. Copy this EXEC to a data
set in your SYSEXEC concatenation.
Add the following statement to the CA-GSS initialization parameters:

ADDRESS CA7T CAL2X2TR 15 TYPE 0
Also, the following variables can be customized as needed using the following CA-GSS initialization
parameters:
GLOBVAL &CA7T_TADDR /abc.xyz.com/ /* TCP/IP addr where CA 7 resides */
GLOBVAL &CA7T_PORT /nnnn/ /* TCP/IP port number of CA 7 instance */
GLOBVAL &CA7T_SSCT /xxxx/ /* CA 7 instance name (CA71-CA78) */
GLOBVAL &CA7T_DEBUG /xxxx/ /* CA 7 TCP/IP interface options */
08-Feb-2018 125/722
Execute the TCP/IP Program-to-Program Interface

Another program can directly call the TCP/IP Program-to-Program Interface. The calling program
passes a string of CA Workload Automation CA 7® Edition batch commands. CAL2X2TP interfaces with
CA Workload Automation CA 7 Edition through program CAL2X2T0 and builds a buffer in storage that
contains the command responses from CA Workload Automation CA 7 Edition. The calling program
can then parse the responses and take other appropriate actions that are based on the results.

statement to your job/STC/logon PROC JCL.
Call CAL2X2TP
To invoke the CA Workload Automation CA 7 Edition TCP/IP Program-to-Program Interface, make the
CA Workload Automation CA 7 Edition load library available to the program that is executed. A
standard parameter list is passed in register 1. The following is the format of the parameter list:
+0
Address of the CA Workload Automation CA 7 Edition batch command string. If the string has
more than one command, separate them with a command separator character. The default is a
semicolon (;). This parameter is required.
+4
Fullword length of the CA Workload Automation CA 7 Edition batch commands. This parameter is
required.
+8
Address of an 8-byte field indicating where the address and length of the CA Workload
Automation CA 7 Edition response buffer are returned. The first 4 bytes contain the address, and
the second 4 bytes contain the length of the buffer. If the caller wants the response buffer to
reside in storage above the 16-MB line, make the first byte of the 8-byte field contain the value X
‘80’. Otherwise, the buffer storage is obtained below the 16-MB line. This parameter is required.
Important! The caller is responsible for FREEMAINing the response buffer storage.
+12
Pointer to a 48-byte field that contains the TCP/IP address where the CA Workload Automation
CA 7 Edition address space executes. The TCP/IP address is in one of two formats: presentation
format (for example, abc.xyz.com) or numeric format (nnn.nnn.nnn.nnn). This parameter is
required.
+16
Pointer to a 5-byte field that contains the port number that is assigned to the CA 7 instance with
which you want to communicate. The port number requires a decimal format and leading zeros.
This parameter is required.
08-Feb-2018 126/722
+20
Pointer to the instance name of the CA Workload Automation CA 7 Edition with which to
communicate (CA71-CA78). Aliases are not permitted. The default instance name is CA71. This
parameter is optional.
+24
Pointer to a four-character Options field. The first character indicates whether to generate
diagnostic trace messages (value of Y). The default is not to produce trace messages. The second
character specifies the command string separator character. Use any nonblank not null character
as a command separator. The default separator is a semicolon (;). The third and fourth characters
are reserved for future use. This parameter is optional.
CAL2X2TP Response Buffer

CAL2X2TP returns the response buffer containing all the output lines received from CA Workload
Automation CA 7 Edition in response to the command string provided. If no responses are received
from CA Workload Automation CA 7 Edition because of an error, no response buffer is created. The
address/length field that the caller supplied is null. If an error is encountered after CAL2X2TP begins
receiving responses from CA Workload Automation CA 7 Edition, a response buffer is still created.
The address and length are set in the address/length field of the caller.
Important! You can receive a nonzero return code from CAL2X2TP and still have a response
buffer.
CA Workload Automation CA 7 Edition responses in the response buffer are fixed-length records.
Each record is 133 bytes in length. If you want to calculate the number of lines in the buffer, simply
divide the overall length by 133. Each response is blank-padded and begins with a carriage control
character.
The caller is responsible for freeing up the response buffer after it is no longer needed. The buffer is
obtained from subpool 0. Assume that the first byte of the 8-byte address/length field of the caller
contains X‘80’ on entry to CAL2X2TP. In this case, the response buffer is obtained from storage above
the 16-MB line.
Important! The caller is responsible for freeing the response buffer storage.
CAL2X2TP Return Codes

On exit from module CAL2X2TP, the return code is in register 15 and the condition code is in register
0. The possible return and condition codes that are generated by CAL2X2TP are listed. For condition
codes not listed here, see CAL2X2T0 Condition Codes.
RC=0
Indicates that the CAL2X2TP program successfully completed its functions without detecting an
error.
08-Feb-2018 127/722
RC=4
Indicates no responses from CA Workload Automation CA 7 Edition received.
RC=8
CC=9
Error attempting to obtain storage.
CC=10
Error attempting to LOAD a needed module.
RC=12
Indicates error return from CAL2X2T0 (nonabend).
CC=
AL2(CAL2X2T0 rc), AL2(CAL2X2T0 cc)
RC=16
CC=1
Invalid parameter list.
CC=2
Invalid parameter value.
RC=20
Indicates error return from CAL2X2T0 (abend).
CC=
Sxxx or Uxxxx that is the printable abend code.
More information:
CAL2X2T0 Return Codes (https://wiki.ca.com/pages/viewpage.action?

pageId=134845066#CAWorkloadAutomationCA7EditionTCP/IPBatchInterfaceExecution-
CAL2X2T0ConditionCodes)
Sample Invocation of CAL2X2TP

The following sample invocation of CAL2X2TP is listed here and in CAL2OPTN member AL2X2TPS.
AL2X2TPS START
*
* Sample program to call CA 7 TCP/IP Pgm-to-Pgm Interface
*
SASSVRSN VRSN=TST,LINK=OS,REGS=R10,EQU=YES, X
AMODE=31,RMODE=ANY
LA R1,X2TPPARM Point to parm list
LINK EP=CAL2X2TP Call CA 7 TCP/IP pgm-to-pgm
*
CLC BUFFADDR,NORESPON Q - Any CA 7 responses?
08-Feb-2018 128/722
CLC BUFFADDR,NORESPON Q - Any CA 7 responses?
BE #UCC7RET N - Exit w/X2TP RC
L R2,BUFFADDR R2 -> Responses
L R3,BUFFLEN R3 = Buffer length
LA R3,0(R2,R3) R3 -> End of responses
LOOP DS 0H
CLC SPO700,0(R2) Q - Good DEMAND response?
BE GOOD Y - Exit loop
LA R2,133(,R2) N - R2 -> Next line
CR R2,R3 Q - Reached end?
BL LOOP N - Cycle
WTO 'AL2X2TPS: Job demand NOT successful'
*
LA R15,8 Set RC=8
B #UCC7RET Go exit
*
GOOD DS 0H
WTO 'AL2X2TPS: Job demanded successfully'
*
LA R15,0 Set RC=0
B #UCC7RET Go exit
*
BUFFSET DS 0D Spot for buffer address/length
BUFFADDR DC X'80000000' >line addr of CA 7 resp buffer
BUFFLEN DC F'0' Leng of CA 7 response buffer
NORESPON DC X'80000000' This value means no responses
X2TPPARM DS 0F CA 7 TCP/IP interface parmlist
DC A(CMDLIST) Address of command string
DC A(CMDLISTL) Length of command string
DC A(BUFFSET) Buffer address/length field
DC A(TCPADDR) TCP/IP addr of CA 7 system
DC A(PORT) Address of port number
DC A(INSTANCE) Instance (req'd if not CA71)
* DC A(OPTS) Options
DC X'80',AL3(0) End of parmlist
TCPADDR DC CL48'ABC.XYZ.COM' TCP/IP addr of CA 7 server
PORT DC CL5'04099' TCP/IP port number
INSTANCE DC CL4'CA74' CA7 instance name if not CA71
OPTS DC CL4'Y; ' Options
SPO700 DC CL9' SPO7-00 ' Good DEMAND message prefix
CMDLIST DC C'/LOGON MASTER;DEMAND,JOB=TESTJOB;/LOGOFF'
CMDLISTL EQU L'CMDLIST
END AL2X2TPS
Execute the TCP/IP Java-to-Program Interface

A user-written application written in Java can directly call the CA Workload Automation CA 7 Edition
TCP/IP Program-to-Program Interface from either a Microsoft Windows operating environment or a
distributed operating environment. The calling program passes a string of CA Workload Automation
CA 7 Edition batch commands using functions supplied by interface module CAL2X2TJ. CAL2X2TJ
interfaces with CA Workload Automation CA 7 Edition through the program CAL2X2T0 and builds a
buffer in storage that contains the command responses from CA Workload Automation CA 7 Edition.
The calling program can then parse the responses and take other appropriate actions based on the
results.
CAL2X2TJ Java Class Module (see page 130)

CAL2Command (see page 130)
CAL2 Command Return Codes (see page 131)
Issue CA7Command (see page 131)
CAL2X2TJ Sample Application Program (see page 131)
Download the CAL2X2TJ Java Sample Project (see page 133)
CAL2X2TJ Java Sample Project Contents (see page 133)
View and Compile the Java Sample Application (see page 134)
08-Feb-2018 129/722
View and Compile the Java Sample Application (see page 134)
The CAL2X2TJ interface includes two utility methods that perform the following tasks:
CAL2Command
Reads input parameters for connecting to the CA Workload Automation CA 7 Edition TCP/IP
server, sending batch commands, and storing the response for the caller.
Connects to the CA Workload Automation CA 7 Edition TCP/IP server to communicate to the
interface module CAL2X2T0.
Sends CA Workload Automation CA 7 Edition batch commands.
Receives CA Workload Automation CA 7 Edition command output response through CAL2X2T0,
writes the command response to a buffer, and returns the response to the caller.
IssueCA7Command
This method is a variation of CAL2Command that uses a different method to pass parameters.
CAL2X2TJ Java Class Module

The CA Workload Automation CA 7 Edition TCP/IP Java class module (CAL2X2TJ) is made up of two
methods that are exposed and that user-written applications can call directly. This module uses
Native TCP/IP Socket support for communications with the CA Workload Automation CA 7 Edition TCP
/IP server component on the z/OS operating environment.
CAL2Command
This method can be called to initiate a command request to the CA Workload Automation CA 7
Edition TCP/IP server and process the results. The following list shows the array elements that must
be supplied when calling this method.
public int CAL2Command(java.lang.Object[] array)
/* array[0] Input CA 7 commands to send */
/* array[1] CA 7 server name or IP address */
/* array[2] CA 7 server port number */
/* array[6] Input debug option */
Parameter detail usage:
The array must contain the following string values:
array[0]
This input string must contain one or more CA Workload Automation CA 7 Edition batch
commands. A semicolon (;) must separate multiple commands. This input string is required.
Range: Cannot exceed 512 bytes.
array[1]
TCP/IP address where the CA Workload Automation CA 7 Edition address space executes. The TCP
/IP address is in one of two formats: presentation format (for example, abc.xyz.com) or numeric
format (nnn.nnn.nnn.nnn). This input string is required.
array[2]
The port number that is assigned to the instance of CA Workload Automation CA 7 Edition with
which you want to communicate. The port number requires a decimal format and leading zeros
are not necessary. This input string is required.
Range: 1 to 65535
08-Feb-2018 130/722
array[6]
This input value turns on diagnostic information for logging. The value 0 indicates that no
diagnostic information is logged, and 1 indicates that diagnostic trace information is logged. The
log file is created in the same folder as the CAL2X2TJ Java class file and is named CAL2X2TJ.log.
This value is required.
CAL2 Command Return Codes

Return codes have been replaced with throw exceptions. For more information, see the log file
CAL2X2TJ.log.
Issue CA7Command
The functionality of this method is similar to CAL2Command except for implementing an ArrayList.
The following list contains the ArrayList elements that must be supplied when calling this method.
public int IssueCA7Command(java.lang.Object[] ArrayList)
/* element 1 – CA 7 server name or IP address */
/* element 2 – CA 7 server port number */
/* element 3 – CA 7 command to send */
The array must contain the following string values:
element 1
TCP/IP address where the CA Workload Automation CA 7 Edition address space executes. The TCP
/IP address is in one of two formats: presentation format (for example, abc.xyz.com (http://abc.xyz.
com)) or numeric format (nnn.nnn.nnn.nnn). This input string is required.
element 2
The port number that is assigned to the CA 7 instance with which you want to communicate. The
port number requires a decimal format and leading zeros are not necessary. This input string is
required.
Range: 1 to 65535
element 3
This input string must contain one CA Workload Automation CA 7 Edition batch command. This
input string is required.
CAL2X2TJ Sample Application Program

The following sample application program is an example of how to implement the CA7TCPIP class file
methods IssueCA7Command and CAL2Command. This program sends batch commands to the TCP/IP
server and returns response data to the Command Prompt window.
CAL2Command
/** Sample java program to call the CAL2X2TJ.CAL2Command() method */import java.util.
ArrayList;
import java.util.List;

public class CA7TCPIP
{
public static void main(String[] argv)
08-Feb-2018 131/722

{
issuecommand();
return;
}

public static void issuecommand()
{
try
{
CAL2X2TJ ca7Communicator = new CAL2X2TJ();
String commandToBeSent = "/LOGON YOUR_LOGON;LQ;/DISPLAY,PERF=ALL;/LOGOFF";
String[] parmlist = new String[7];
parmlist[0] = commandToBeSent;// The list of commands to be sent, separated
by ;
parmlist[1] = "your_ca7_server_ip"; // CA7 TCPIP server address
parmlist[2] = "your_ca7_server_port"; // CA7 TCPIP server port number
parmlist[6] = "1"; // Debug option 1=ON 0=OFF

int returnCode = ca7Communicator.CAL2Command(parmlist);
if (returnCode == 0)
System.out.println(parmlist[4]);// The response comes to the 4 array
element
}
catch (Exception e)
{
e.printStackTrace();
}
}
} /* CA7TCPIP */

IssueCA7Command
/** Sample java program to call the CAL2X2TJ.issueCA7Command() method */import java.
util.ArrayList;
import java.util.List;

public class CA7TCPIP
{
{
// If there are no arguments passed to main , just execute the command below
if((argv == null) || (argv.length == 0))
{
// Issue the /DISPLAY,ST=CA7 command
issuecommand("/DISPLAY,ST=CA7");
issuecommand("/DISPLAY,PERF=ALL");
}
else if (argv.length == 1)
issuecommand((String)argv[0]);
return;
}

public static void issuecommand(String command)
{
try
{
CAL2X2TJ ca7Communicator = new CAL2X2TJ();
ArrayList<String> commands = new ArrayList<String>();
commands.add("/LOGON YOUR_LOGON");
commands.add(command);
commands.add("/LOGOFF");
// Change your_ca7_server_ip to the real CA7 TCP server IP address.
// Change your_ca7_server_port to the real CA7 TCP server port.
List<String> responses = ca7Communicator.issueCa7Command
("your_ca7_server_ip", your_ca7_server_port,
commands.toArray(new String[0]),true);
08-Feb-2018 132/722
commands.toArray(new String[0]),true);
if (responses != null)

{
// Line number
int lineNo = 1;
for (String resp : responses)
{
// Print the line number before each answer
System.out.println("[" + lineNo + "]-" + resp);
lineNo++;
}
}
}
catch (Exception e)
{
e.printStackTrace();
}
}
} /* CA7TCPIP */

Download the CAL2X2TJ Java Sample Project

You can download the CAL2X2TJ Java sample project.
Follow these steps:
1. Create a temporary folder on your workstation hard disk before downloading the sample
project. For example: under the c:\temp or c:\windows\temp folder, create a subfolder
named \cal2x2tj.
2. Log in to CA Support Online (http://support.ca.com).
3. Navigate to the Support By Product Home Page for CA 7 Workload Automation.
4. Under Select a Product page, click CA 7 Workload Automation.
5. From the CA 7 Workload Automation product page, click Product status.
6. Click CA 7 Workload Automation r11.3 TCPIP Server Java Sample Project Download.
7. Click Save and verify that the Save As dialog points to the folder you prepared for download.
CAL2X2TJ Java Sample Project Contents

The CAL2X2TJ Java project requires the Java SE Development Kit (JDK) 1.6.0_13 or above installed.
The Java JAR file CAL2X2TJ.jar, contains the sample program with the supporting class file. The
following list shows the JAR file contents:
Readme.txt
Information about the JAR file contents
CA7TCPIP.java
Sample Java program calling CAL2X2TJ methods
08-Feb-2018 133/722
CA7TCPIP.class
Executable version of CA7TCPIP.java. This value is overlaid when you change CA7TCPIP and
compile it.
CA72X2TJ.class
CA 7 TCPIP Java to Program class
A META-INF directory is also extracted.
View and Compile the Java Sample Application

Extract the Java modules to the C:\CAL2X2TJ directory by issuing the following command:
jar xfvM CAL2X2TJ.jar
You can compile the sample program (CA7TCPIP.java).
Note: In the sample program CA7TCPIP.java, change the parameters for the CA Workload
Automation CA 7 Edition TCPIP server address and port to match the server setup in your
environment.
Compile the sample program by issuing the following commands:

cd c:\CAL2X2TJ
javac CA7TCPIP.java
After the class module is compiled, issue the following command to invoke the module under a Java
Runtime Environment:
java CA7TCPIP
Execute the TCP/IP C-to-Program Interface

A program that is written in C can directly call the CA Workload Automation CA 7® Edition TCP/IP
Program-to-Program Interface from the Windows operating environment. The calling program passes
a string of CA Workload Automation CA 7 Edition batch commands using functions supplied by
Windows DLL CAL2X2TC. CAL2X2TC interfaces with CA Workload Automation CA 7 Edition through
the program CAL2X2T0 and builds a buffer in storage that contains the command responses from CA
Workload Automation CA 7 Edition. The calling program can then parse the responses and take other
appropriate actions based on the results.
The CAL2X2TC DLL interface includes two functions that perform the following actions:
CAL2Command

08-Feb-2018 134/722

writes the command response to a buffer, and returns all (or part) of the response to the caller.
CAL2GetMoreData
Processes an existing response that was generated as a result of calling the CAL2Command
function when the caller response buffer is smaller than the command response received from
the product.
CAL2Command


writes the command response to a buffer, and returns all (or part) of the response to the caller.
CAL2GetMoreData
Processes an existing response that was generated as a result of calling the CAL2Command
function when the caller response buffer is smaller than the command response received from
the product.
CAL2X2TC DLL Interface

The CA Workload Automation CA 7 Edition TCP/IP DLL interface module (CAL2X2TC) is made up of
two functions that are exposed and that user-written applications on Microsoft Windows platforms
can call directly. This module contains the low-level service routines necessary to communicate with
the CA Workload Automation CA 7 Edition TCP/IP server component using TCP/IP and Windows
sockets.
CAL2Command
This function can be called to initiate a command request to the CA Workload Automation CA 7
Edition TCP/IP server and process the results. The following list shows the arguments that must be
supplied when calling this function with their properties. Input strings must be null-terminated. The
caller program initializes the output strings to their desired lengths before usage.
int CAL2Command (char *CommandBuffer, /* Input CA 7 commands to send */
char *ServerAddress, /* CA 7 server name or IP address */
char *ServerPort, /* CA 7 server port number */
char *ResponseBuffer, /* Output response buffer */
int *ResponseLength, /* Input/output length of response buffer */
char *ErrorDescription, /* Output error description */
int DebugOption); /* Input debug option */
08-Feb-2018 135/722
CommandBuffer
This input parameter must contain one or more CA Workload Automation CA 7 Edition batch
commands. A semicolon (;) must separate multiple commands. The maximum size of the value
contained in this parameter cannot exceed 512 bytes. This parameter is required.
ServerAddress
Pointer to a parameter that contains the TCP/IP address where the CA Workload Automation CA
7 Edition address space executes. The TCP/IP address is in one of two formats: presentation
format (for example, abc.xyz.com) or numeric format (nnn.nnn.nnn.nnn). The maximum size of
the value that is contained in this parameter cannot exceed 256 bytes. This parameter is required.
ServerPort
Pointer to a 5-byte parameter that contains the port number that is assigned to the instance of
the product with which you want to communicate. The port number requires a decimal format
and leading zeros. Range is 00001-65535. This parameter is required.
ResponseBuffer
Pointer to the response buffer containing the output lines received from the product in response
to the command string provided. If the response data is less than the length of ResponseBuffer,
ResponseLength is set to the response data length. If the response data is greater than the length
of ResponseBuffer, CAL2Command returns a value of -1. The caller must call the
CAL2GetMoreData function to retrieve the remaining output lines. If no responses are received
from the product because of an error, ResponseBuffer does not always contain output lines.
CA Workload Automation CA 7 Edition responses in the response buffer are fixed-length records.
Each record is 133 bytes in length. To calculate the number of lines in the buffer, simply divide the
overall length by 133. Each response is blank-padded and begins with a carriage control character.
The maximum size of the value that is contained in this parameter cannot exceed 35328 bytes.
ResponseLength
This input integer must contain the size of the output parameter ResponseBuffer and cannot
exceed 35328. Refer to ResponseBuffer for more information.
ErrorDescription
Pointer to a 512-byte parameter that contains the error description associated with an error
return code. This parameter is required.
DebugOption
Turns on diagnostic information that is logged. The value 0 indicates that no diagnostic
information is logged, and 1 indicates that diagnostic trace information is logged. The log file is
created in the same folder as the CAL2X2TC DLL and is named CAL2X2TC.log. This parameter is
required.
CAL2Command Return Codes

The possible return codes from CAL2Command are set to one of the following integer values:
RC=0
Indicates the CAL2Command method has successfully completed without detecting an error.
08-Feb-2018 136/722
RC=-1
Indicates that the CAL2Command method successfully completed its functions without detecting
an error and response data length exceeded the size of the response buffer.
These codes indicate that an error occurred in CAL2Command. The ErrorDescription buffer contains
error message text. The possible error return codes are set to one of the following values:
RC=1
Indicates an invalid parameter list.
RC=2
Indicates an invalid parameter value.
RC=3
Indicates an error encountered creating socket.
RC=4
Indicates an error connecting to server.
RC=5
Indicates an error attempting to malloc storage.
RC=6
Indicates a socket closed.
RC=7
Indicates a server returned a processing error.
RC=8
Indicates a socket receive failed.
RC=9
Indicates a socket send failed.
RC=10
Indicates an invalid or missing request command string.
RC=11
Indicates an invalid eyecatcher in data response from the server.
RC=12
Indicates an invalid transaction function code from the server.
CAL2GetMoreData
This function can be called to process a remaining response data that was generated as a result of
calling the CAL2Command function. The following list details the arguments that must be supplied
when calling this function with their properties. Input strings must be null-terminated. Output strings
are initialized by the caller program to their desired lengths before usage.
int CAL2GetMoreData (char *ResponseBuffer, /* Output response buffer */
int *ResponseLength, /* Input/output length of response buffer */
char *ErrorDescription, /* Output error description */
08-Feb-2018 137/722
ResponseBuffer
Pointer to the response buffer containing the output lines received from the product in response
to the command string provided. If the remaining response data is less than the length of
ResponseBuffer, ResponseLength is set to the response data length. If the response data is
greater than the length of ResponseBuffer, CAL2GetMoreData returns a value of -1. The caller
must call the CAL2GetMoreData function again to retrieve the remaining output lines. If no
responses are received from the product because of an error, ResponseBuffer does not contain
output lines.
The maximum size of the value that is contained in this parameter cannot exceed 35328 bytes.
ResponseLength
This input integer must contain the size of the output parameter ResponseBuffer and cannot
exceed 35328.
ErrorDescription
Pointer to a 512-byte parameter that contains the error description associated with an error
return code. This parameter is required.
DebugOption
Turns on diagnostic information that is logged. The value 0 indicates that no diagnostic
information is logged, and 1 indicates that diagnostic trace information is logged. This parameter
is required.
CAL2GetMoreData Return Codes

The possible return codes from CAL2GetMoreData are set to one of the following values:
RC=0
Indicates the CAL2GetMoreData method successfully completed its functions without detecting
an error.
RC=-1
Indicates that the CAL2GetMoreData method successfully completed without detecting an error
and response data length exceeded the size of the response buffer.
These codes indicate that an error occurred in CAL2GetMoreData. The ErrorDescription buffer
contains error message text. The possible error return codes are set to one of the following values:
RC=1
Indicates an invalid parameter list.
RC=2
Indicates an invalid parameter value.
08-Feb-2018 138/722
CAL2X2TC Sample Application Program

The following sample application program shows how to implement the CAL2X2TC DLL functions
CAL2Command and CAL2GetMoreData. This program sends batch commands to the CA Workload
Automation CA 7 Edition TCP/IP server using the CAL2Command function, processes the return code,
and returns response data to the Command Prompt window. The sample also shows how the
CAL2GetMoreData function is used to handle the retrieve more response data.
/* Sample program to call CA 7 TCP/IP C-to-Pgm Interface
/* ----- Start of CAL2X2TC.h
/*--------------------------------------------------------------------*/
/* */
/* File Name: CAL2X2TC.h */
/* Description: Include used to define exported function(s), */
/* structures and global variables. */
/* */
/**********************************************************************/
// Defines -------------------------------------------------------------
#define DEBUG_ON 1 /* Request number for ignore block*/
#define DEBUG_OFF 0 /* Line number for ignore block */
#define SCREEN_LINE_WIDTH 133 /* Screen output line length */
#define ERROR_MSG_LENGTH 512 /* Return error message length */
#define RC_MORE_DATA -1 /* Return code more data avail */
#define RC_NORMAL 0 /* Return code normal & no more */
/* data available */

// external function found in CAL2X2TC DLL
__declspec(dllimport) int CAL2Command(char *CommandBuffer,
// Pointer to command string buffer

char *ServerAddress,
// Pointer CA 7 server IP address
char *ServerPort,
// Pointer CA 7 server port
char *ResponseBuffer,
// Pointer to the response buffer
int *ResponseLength,
// Pointer to resp buffer length
char *ErrorDescription,
// Pointer error description buffer
int DebugOption);
// Debug option 1=ON 0=OFF

__declspec(dllimport) int CAL2GetMoreData(char *ResponseBuffer,
// Pointer to the response buffer
int *ResponseLength,
// Pointer to resp buffer length
char *ErrorDescription,
// Pointer error description buffer
int DebugOption);
// Debug option 1=ON 0=OFF

/* ----- End of CAL22X2TC.h

/* ----- Start of CA7TCPIP.cpp// CA7TCPIP.
cpp : A console application sample program to call
// the CA 7 TCP/IP C-to-Pgm Interface.
//
#include <iostream>
using namespace std;

#include "CAL2X2TC.h"
// Constants for parameter list dll calls
#define CMDARG "/LOGON MASTER;/DISPLAY,ST=CA7;/LOGOFF\0" // Command string
#define SERVER_ADDRESS "USILCA31.CA.COM\0" // TCP/IP addr of CA 7 system
#define SERVER_PORT "4078\0" // Port number of CA 7 system
#define SUCCESS 0 // Exit code if successful
#define FAILURE 1 // Exit code if not successful

08-Feb-2018 139/722

void displayResults(char*, int);

int main(int argc, char *argv[])
{
// Parameter variables for dll calls
char CommandBuffer[] = CMDARG; // Buffer for the command string
char *ServerAddress = SERVER_ADDRESS; // Pointer CA 7 system TCP/IP addr
char *ServerPort = SERVER_PORT; // Pointer TCP/IP port number
char *ResponseBuffer; // Pointer response buffer
char *ErrorDescription; // Pointer error description
int ResponseLength; // Reponse buffer returned size

// Other variables
char getBuffer[100];
int rc; // Return code for CAL2X2TC calls
int totalLinesRequested = 100; // Maximum screen lines return
rc = RC_NORMAL; // Set return code to success

ResponseLength = // Calc maximum bytes to return
SCREEN_LINE_WIDTH*totalLinesRequested;

// Allocate the response buffer
ResponseBuffer = (char *) malloc(ResponseLength);
if( ResponseBuffer == NULL )
return FAILURE;
// Allocate the error description buffer
ErrorDescription = (char *) malloc(ERROR_MSG_LENGTH);
if( ErrorDescription == NULL )
return FAILURE;

// Call CAL2X2TC function function to send the commands strings to
// the CA 7 TCP/IP server and receive the initial response buffer
// rc returns the following -
// 0 - RC_NORMAL, success & response returned in buffer
// -1 - RC_MORE_DATA,success,response returned & more data available
// >0 - error return code & description returned in pErrorDescription
rc = CAL2Command(CommandBuffer, // Pointer to command string buffer
ServerAddress, // Pointer CA 7 server IP address
ServerPort, // Pointer CA 7 server port
ResponseBuffer, // Pointer to the response buffer
&ResponseLength, // Pointer to response buffer length
ErrorDescription, // Pointer to error description buffer
DEBUG_ON); // DEBUG_ON (1) write messages to file
// Loop to output the response buffer to the screen and call
// CAL2GetMore if more data is available
do {
if (rc > RC_NORMAL) { // Not success - display error description
displayResults(ErrorDescription, ERROR_MSG_LENGTH);
}
else { // Output response buffer
displayResults(ResponseBuffer, ResponseLength);
}

if (rc == RC_MORE_DATA) { // More response data available
rc = CAL2GetMoreData(ResponseBuffer, // Pointer response buffer
&ResponseLength, // Pointer response buffer length
ErrorDescription,// Pointer to error buffer
DEBUG_ON); // DEBUG_ON (1) write messages file
}
} while (rc == RC_MORE_DATA); // Loop while more data available

printf("Press <Enter. to continue>>>");
fgets(getBuffer,100,stdin);
return SUCCESS;
}

void displayResults(char *result, int buffersize)
/* Assumes that there is at least one element */
/* Parse the response buffer into screen lines*/
/* and outputs to the screen */
{
08-Feb-2018 140/722
{
int pos, i, rows;
rows = buffersize/SCREEN_LINE_WIDTH;
pos = 0;
for( i = 0; i < rows; i++) {
if (*(result + pos) == '\0')
return;
printf("%s\n", result + pos);
pos = pos + SCREEN_LINE_WIDTH;
}
return;
}
/* ----- End of CA7TCPIP.cpp

Download the CAL2X2TC C Sample Project

Follow these steps:
1. Create a temporary folder on your workstation hard disk before downloading the sample
project. For example: under the c:\temp or c:\windows\temp folder, create a subfolder that is
named \cal2x2tc.
2. Log in to the CA Support Online website at http://support.ca.com.
3. Navigate to the Support By Product Home Page for CA 7 Workload Automation.
4. Under Select a Product page, click CA 7 Workload Automation.
5. From the CA 7 Workload Automation product page, click Product status.
6. Click CA 7 Workload Automation r11.3 TCPIP Server C Sample Project Download.
7. Click Save and verify that the Save As dialog points to the folder you prepared for download.
View and Compile Code in the C++ Sample Application

The CA7TCPIP project requires Visual Studio .NET 2003 or higher. To run the C++ CA7TCPIP Sample
Application, compile the C++ CA7TCPIP Sample Application solution. You can view all the code for the
C++ CA7TCPIP Sample Application by opening the CA7TCPIP.sln solution file in Visual Studio.
To view the C++ CA7TCPIP Sample Application code in Visual Studio .NET 2003
1. Browse to the following folder:

\CAL2X2TC\CA7TCPIP
2. Double-click CA7TCPIP.sln.
To compile the C++ CA7TCPIP Sample Application code in Visual Studio .NET 2003
1. On the Build menu, click Build Solution.
CA7TCPIP Sample Application Contents

The CA7TCPIP flowchart sample program files are found in the \CAL2X2TC\CA7TCPIP folder.
Also, the CAL2X2TC folder contains three files that are required to develop your own application:
08-Feb-2018 141/722
Also, the CAL2X2TC folder contains three files that are required to develop your own application:
CAL2X2TC.dll
Windows DLL that must reside in the same directory as your application
CAL2X2TC.h
C++ header file includes define and DLL import statements
CAL2X2TC.lib
Library file to link your application
Manage the Trailer Step Facility

CA Workload Automation CA 7® Edition trailer steps are special purpose job steps. The steps can be
added to any job to cause the processing of CA Workload Automation CA 7 Edition commands at
strategic points within the processing. Jobs executing trailer steps are not necessarily defined to CA
Workload Automation CA 7 Edition, but you can when you want to do so.
Use the CA Workload Automation CA 7 Edition trailer step by including an extra step in the job
stream. This step does not affect the operational function of the job but causes activity within CA
Workload Automation CA 7 Edition. A CA Workload Automation CA 7 Edition application is executed
that performs the operation that is requested in trailer step JCL. You can use the trailer step to
perform any of the commands belonging to the queue maintenance application as defined by SPO0
security. The following illustration shows trailer step data flow.
08-Feb-2018 142/722
You can use the trailer step for special situations. One example is an early post of a data set
requirement. Typically, CA Workload Automation CA 7 Edition does not post data set requirements
for jobs in the request queue until normal completion of the job that creates the data sets. This
method of posting is due to the possibility of a restart that would again create the data set. A trailer
step could be inserted after the step that creates the data set (before other steps of the job) to post
requirements for another job in the request queue that is waiting for that data set creation.
Another example is jobs that cannot run until an online system is down. The job dependency could be
established even though the online system is not a CA Workload Automation CA 7 Edition job. The
final step of the online system could post these jobs with a trailer step to satisfy this requirement.
The /MSG command is also allowed in the trailer step. You can send messages to logical terminals by
this process.
The /WTO command is allowed in the trailer step. You can send messages to the console operator on
the system where CA Workload Automation CA 7 Edition is running.
The /WLB command is permitted in the trailer step. You can turn workload balancing ON or OFF and
can adjust certain resources.
Once the trailer terminal is used, it cannot be logged off. A /LOGOFF command is ignored other than
to terminate a block of input data as noted later in these topics.
To use the trailer step facility, define a trailer terminal in the initialization file. Also, verify that ICOM
is active on the CPU where the trailer step is to run. You can define only one trailer terminal. A JCL
procedure, CA7TRLR, is provided during installation. Use the procedure to ease maintenance and
release upgrades. Ask your systems programmer or the CA Workload Automation CA 7 Edition
specialist at your installation for the correct procedure name.
//CA07TRLR EXEC PGM=SASSTRLR,PARM=
//STEPLIB DD DSN=cai.CAL2LOAD,DISP=SHR
//SYSOUT DD SYSOUT=A
//SYSIN DD DATA,DLM=##
/LOGON operator-ID
CA 7 queue posting commands go here
/MSG,LT=station,M=message
##
//*
You can specify an optional PARM value on the EXEC statement.
The PARM values have the following format:

[INACT|ACT] [,CA7={CA71 }] [,NCFNODE=nnnnnnn]
{CA7n }
{alias}
{PROD }
{UC07 }
{TEST }
{UCT7 }
INACT|ACT
ACT indicates that ICOM must be active or the data is not sent. If ACT is specified and ICOM is not
active, the program issues an error message and ends with RC=8. When the parameter value of
INACT is used, the data is held in CSA for processing when ICOM is started. INACT is the default.
08-Feb-2018 143/722
CA7
Specifies the CA 7 instance name. If omitted, the default is CA71. If used, the value must be ',CA7=
xxxx' where xxxx is one of the following values:
CA7n
Where n is a value from 1 through 8. This name is the true instance name to use.
alias
Is a one- to four-character alias specified at CA Workload Automation CA 7 Edition resource
initialization.
PROD
Defaults to instance CA71
UC07
TEST
UCT7
NCFNODE
Indicates the name of an NCF node for routing. If NCFNODE is specified, the CA7= parameter must
be CA71.
The following are possible return codes:
0
Indicates PARM value supplied.
4
Indicates that PARM defaulted to INACT, an invalid command was found in the input, or both. If
an invalid command is found, the following WTO is issued: CA-7.TRLR-10 COMMAND NOT IN
SPO0 APPLICATION.
8
Indicates an invalid PARM, INACT assumed. Various error conditions, denoted with a WTO that
describes the error.
To prevent command interleaving among multiple tasks on the same CPU and tasks among multiple
CPUs, trailer input is blocked with the /LOGON statement. As a result, if many commands are input, it
is sometimes necessary to intersperse /LOGON statements to avoid blocking errors. (A /LOGOFF can
be used to terminate a block.)
In some situations, it is sometimes necessary to add the DCB parameter to the SYSIN DD statement.
The attribute is BLKSIZE=80.
08-Feb-2018 144/722
Manage the U7SVC Facility

This article explains how to manage the U7SVC facility.
The CA Workload Automation CA 7® Edition SVC is used for several different functions. The Batch
Card Load program (SASSBCLP) uses the SVC to post to CA Workload Automation CA 7 Edition the
creation of a data set. The trailer program (SASSTRLR) uses the SVC to issue various posting
commands. A program is provided to allow the user flexibility in the use of the SVC. The name of this
program is U7SVC and it can be executed as a job step in batch or called from a user program.
U7SVC lets the user post to CA Workload Automation CA 7 Edition that a data set has been created. A
previous step of a job that is running external to CA Workload Automation CA 7 Edition sometimes
creates the data set. The created data set is not required to be fixed blocked with a record length of
80, as is the case with BCLP.
The program also allows the user to issue CA Workload Automation CA 7 Edition batch commands. All
commands that are authorized for the trailer terminal can also be issued. Thus, the U7SVC program is
not limited to queue maintenance commands as is the case with SASSTRLR.
Note: If the U7SVC program is used to post a data set creation, the SASSXDSN exit table
should not specify the data set, or possible double postings (and double triggering) can
occur.
Batch Step Execution

The JCL procedure CA7SVC is provided as part of the SYSGEN process. The input to U7SVC consists of
PARM data, DD * data, or both. Both are optional, but at least one is required. The ddname for the
DD * input data is CA7DATA. Each command must be on one line and cannot be continued. Each
entry is a CA Workload Automation CA 7® Edition batch command or a data set creation statement.
(Each entry can begin and end with one or more blanks.)
The format of the PARM consists of an optional instance name and one or more entries that
semicolons separate. Each data record consists of one or more entries that semicolons separate.
Parameter
By default, U7SVC communicates with instance CA71. To communicate with a different instance,
place a 'CA7=xxxx;' at the beginning of the PARM= string. Use the following format:
CA7={CA71}; {alias} {CA7n } {PROD } {TEST }
CA71
Indicates the default, which maps to what was referred to as the "production" copy of CA
Workload Automation CA 7 Edition.
alias
Indicates a one- to four-character alias. This alias must correspond to an alias assigned to a CA 7
instance during the initialization by CAIRIM.
08-Feb-2018 145/722
CA7n
Indicates an instance where n can be an integer from 2 to 8.
PROD
Indicates to map to instance CA71.
TEST
Indicates to map to instance CA72.
Syntax
To indicate that the creation of a data set has completed, a statement in the following format is
required:
D=dsname,[vvvvvv],[xxx][,tttttttt]
dsname
Specifies the data set name.
vvvvvv
(Optional) Indicates a positional parameter specifying the volume serial number where the data
set was created. Not needed if the data set has been cataloged. If not specified, use a comma to
denote its absence.
xxx
(Optional) Indicates a positional parameter specifying the schedule ID to use for the data set
creation. If not specified, use a comma to denote its absence.
Default: 1
tttttttt
(Optional) Indicates a positional parameter specifying the logical terminal or station name to
notify of the data set creation.
Default: MASTER
Note: When external security is present, a resource test is made for all data set creation
requests. Because CA Workload Automation CA 7 Edition treats these requests as if the
data set was created, it can cause posting or triggering to occur. Therefore, a security
resource test is made. The test verifies that the current user is authorized to create the
named data set (even when it does not exist).
U7SVC Examples
The following examples show the use of the U7SVC program. The CA7SVC procedure is written to a
user-specified PROCLIB during the execution of the N020 installation job.
Example 1
08-Feb-2018 146/722
This example indicates that creation has been completed for data set CA7.TEST with a schedule ID of
50.
// EXEC CA7SVC,PARM='D=CA7.TEST,,50'
Example 2
This example is the same as Example 1 except U7SVC communicates with instance CA74.
// EXEC CA7SVC,PARM='CA7=CA74;D=CA7.TEST,,50'
Example 3
This example indicates a logon, demand scheduling of job TEST, posting creation of data set CA7.
TEST2, demand scheduling of jobs TEST2 and TEST3, and a logout. All could have been provided in the
CA7DATA data set when so desired. Each could also be provided as a separate record.
// EXEC CA7SVC,PARM='/LOGON MASTER;DEMAND,JOB=TEST' //CA7DATA DD * D=CA7.
TEST2 ; DEMAND,JOB=TEST2 DEMAND,JOB=TEST3 ; /LOGOFF /*
Note: When using the U7SVC program for posting GDG data set creations, use the relative
GDG number format. The relative GDG number is converted to the corresponding absolute
generation number. For example, if D=A.B(+1) is specified, it is converted to D=A.B.Gnnnn
Vnn. GnnnnVnn is the corresponding absolute generation number. The absolute zero-
generation number can also be specified, for example, D=A.B.G0000V00. This format is not
converted, but it is recognized as a GDG data set.
You can enter queue maintenance commands (other than D commands) through the U7SVC facility.
They must follow the same sequence as if using a CA Workload Automation CA 7 Edition batch
terminal. The command sequence must start with a /LOGON, followed by the desired commands and
end with a /LOGOFF.
Note: When external security is used, a password can be required. For more details on
security interfaces, see Securing (https://wiki.ca.com/display/CWAC7E/Securing).
The U7SVC facility uses the same blocking technique noted for the trailer step facility on the Trailer
Step Facility.
Call U7SVC from a User Program

To call U7SVC from a user program, the CA Workload Automation CA 7® Edition LOADLIB must be
available to the program being executed. A standard parameter list is passed in register 1. One or
more commands can be passed for each call.
08-Feb-2018 147/722
You can invoke U7SVC by using the LINK macro. Register 1 must contain the address of the parameter
list. The parameter list must be on a halfword boundary. The first 2 bytes are the length of the
parameter (commands). These conventions are normal IBM conventions. The format of the
command area is the same as if the EXEC statement had a PARM keyword included with it.
U7SVC can modify the parameter list that is passed to it. If a user program is calling the U7SVC
multiple times during a single execution, have the user program reinitialize the parameter list
between calls.
The sample program calls U7SVC.

ZSVCTEST TITLE '-- SAMPLE PROGRAM TO CALL U7SVC'
ZSVCTEST START
SASSVRSN VRSN=TST, X

REGS=R10, IDENTIFY BASE REGISTER X

LINK=OS, REQUEST OS LINKAGE X

EQU=YES REQUEST REGISTER EQUATES
LA R1,PARMA POINT TO PARAMETER ADDRESS
LINK EP=U7SVC,ERRET=OOPS
B #UCC7RET RETURN TO CALLER
OOPS DS 0H
WTO 'U7SVC NOT LINKED'
LA R15,16 SET ERROR CODE
B #UCC7RET RETURN TO CALLER
PARMA DC A(PARMS)
PARMS DC Y(PARML)
*COMMANDS DC C'CA7=CA7n;' (REQUIRED IF INSTANCE NOT CA71)
* REMOVE "COMMANDS" TAG FROM NEXT LINE IF PREVIOUS LINE IS NOT COMMENTED
COMMANDS DC C'/LOGON;DEMANDH,JOB=CA07TEST;/LOGOFF' PARML
EQU *-COMMANDS
END
CA Driver Procedures, Variable Parameters, and

Functions
These topics describe how to store JCL, variables, and data in the CA Driver procedure library. These
topics also describe how to use CA Driver to accomplish the following actions:
Nest procedures
Insert data at a predetermined point in a procedure
Use variable parameters in procedures and supply values when the procedures are retrieved
Use CA Driver functions
Conditionally expand procedures based on logic or variables in the procedure.
CA Driver is activated when the //CARPROC DD statement is added to the CA Workload Automation
CA 7® Edition execution JCL. CA Workload Automation CA 7 Edition calls CA Driver for each statement
in a job at the job's submission time. For the CPU jobs, CA Driver scans the JCL statements looking for
either of the following control statements embedded in the job stream.
// EXEC procname
08-Feb-2018 148/722
// EXEC procname
or
// EXEC PROC=procname
For the XPJOB jobs, CA Workload Automation CA 7 Edition scans the parameters looking for DPROC=
name and changes this parameter into a statement recognizable by CA Driver.
Note: The agent jobs (AGJOBs) cannot use the CA Driver procedure facility. For variable
substitution, global variables are available. Only CPU jobs and XPJOB jobs can use the CA
Driver procedures.
When one statement is encountered, CA Driver searches all allocated CA Driver procedure libraries
looking for a matching procname (procedure name). If that procedure name is found in a procedure
library, CA Driver expands the procedure. CA Driver passes back a set of expanded statements to the
job stream one statement at a time instead of passing back the // EXEC procname or // EXEC PROC=
procname or DPROC= statement. If the procedure name is not found in a CA Driver procedure library,
the statement is passed back to the job stream unchanged. Thus, you can embed the CA Driver
procedure calls anywhere in the job stream. Assume that the DPROC= statement is returned for an
XPJOB job. This return produces a JCL error status for the job, forcing it back to the request queue.
The CARPROC DD statement typically determines the allocation of CA Driver procedure libraries.
However, this allocation can be altered in any defined CA Workload Automation CA 7 Edition JCL or
PARM library. If the definition of the CA Workload Automation CA 7 Edition JCL or PARM library
includes a reference to a CA Driver procedure library, that procedure library is searched before the
libraries in the CARPROC concatenation when CA Driver is invoked for statements from that library.
For more information about associating a CA Driver procedure library with a CA Workload
Automation CA 7 Edition JCL or PARM library, see the DPROC keyword on the JCL statement of the
initialization file. Alternately, see the DPROC keyword on the /JCL command.
CA Driver
This article explains how to use CA Driver.
Using CA Driver (see page 149)

Verify JCL (see page 150)
Using CA Driver
Because CA Driver modifies the JCL or PARM data at job submission, these changes are not reflected
in the queue JCL of the job.
If the SASSXX02, SASSXX20, or SASSXX21 user exit is used, the exit receives the statements after CA
Driver manipulates them. If the user exit inserts or modifies statements, CA Driver does not inspect
the changed statements.
08-Feb-2018 149/722
If the SASSXX05 user exit is being used, it receives the statements as the job enters the queues
(before submission). Therefore, any statements that are inserted or changed are available to CA
Driver.
All scheduled overrides (such as #JI and #XO) are applied before the CA Driver invocation.
The JOB statement cannot be in a CA Driver PROC.
For XPJOB job types, the CA Driver invocation is started with the DPROC= keyword. The Driver
procedure must use the same first statement (//name DPROC variables), but then include PARMnn
keywords that are inserted in the data that is transmitted to the destination scheduling agent. All
references to CA Driver-specific statements are coded as if they would be used in a CPU job. For
example, the // DNEST procname is used to call another CA Driver procedure.
Although XPJOB job data is case-sensitive, all CA Driver keywords must be specified in uppercase
only.
For XPJOB jobs, using the Global Variable features, which allow variable substitution directly into the
parameter data, is an alternative to CA Driver procedures.
Verify JCL
This topic explains how and when to use the commands to verify that CA Driver is modifying
statements appropriately.
The interface with CA Driver is invoked at job submission time. The interface is also invoked when the
LJCK command is issued, and for CPU jobs, when certain CA Workload Automation CA 7® Edition
editor subcommands are used (any JCLxx command). Default CA Workload Automation CA 7 Edition
variable values vary depending on the command environment. For example, the value of &C_L2JN is
the job name defined in the CA Workload Automation CA 7 Edition database if evaluated in LJCK
processing. If CA Driver is invoked using the JCLL editor subcommand for a CPU job, the value of
&C_L2JN is the character string UNKNOWN. The value is UNKNOWN because the job name is
unavailable when the command is entered. Use these commands to verify that CA Driver is modifying
the statements appropriately.
More information:
Text Editor (https://wiki.ca.com/display/CWAC7E/Text+Editor)
Procedure Library
The CA Driver procedure library is a standard OS partitioned data set. Therefore, you can use ISPF or
any other editor for all library maintenance.
Create Procedures (see page 151)

Call Procedures (see page 151)
Nested Procedures (see page 152)
Include Data (see page 153)
08-Feb-2018 150/722
Include Data (see page 153)

Verify Data Inclusion (see page 153)
Create Procedures
To create a procedure in the CA Driver procedure library, place a DPROC statement as the first
statement in the procedure. The contents of the procedure consist of all the statements following the
DPROC statement. When a procedure is called (retrieved from the library), CA Driver replaces the
calling statement with the contents of the procedure.
Give the name of the procedure immediately following the slashes on the DPROC statement. This
name must be one to eight alphanumeric characters, beginning with an alpha or national character.
//procname DPROC
Use ISPF or any other editor to code procedures.
Call Procedures
For CPU jobs to retrieve a procedure from the CA Driver procedure library, use a standard OS EXEC
statement. Specify the name of the procedure after PROC=.
//stepname EXEC PROC=procname
-- or specify --
//stepname EXEC procname
For XPJOB jobs, to retrieve a procedure, use the keyword DPROC:

DPROC=procname
This sample job stream calls the LVTOC procedure.

//LIST JOB ,JOHN.DOE,CLASS=A
//LIST1 EXEC PGM=IEHLIST
//VOL DD UNIT=SYSDA,VOL=SER=VSIAUX,DISP=SHR
//SYSIN DD *
//CALL EXEC PROC=LVTOC
//
CA Driver replaces the EXEC statement with the contents of the procedure and submits this expanded
job stream to JES for execution.
//SYSIN DD *
LISTVTOC VOL=3390=VSIAUX,FORMAT
//
Note the following items about this expansion process:
Any EXEC statements that are part of the contents of a procedure are included in the expanded
job stream that is submitted to JES.
08-Feb-2018 151/722
For CPU jobs, if no member of the CA Driver procedure library has the name that is specified on
the EXEC statement, the search passes to the OS procedure library. (This result is what would
happen if the EXEC statement misspelled LVTOC as LVTIC.)
If CA Driver detects any error conditions during its expansion, a DERR statement with an
appropriate error message passes to JES. This statement is then flagged as an invalid statement
by JES and displayed on the SYSLOG listing.
For XPJOB jobs, if no member of the CA Driver procedure library has the name that is specified,
the DPROC keyword is returned. The XPJOB fails with a JCL error. Because you cannot correct
errors to the output data stream, use the command LJCK to resolve any errors before allowing the
XPJOB job to execute in a production stream.
Nested Procedures
One procedure can call another procedure, which can, in turn, call other procedures. Each time a
procedure calls another procedure, this call is counted as a nesting level. When the first procedure is
retrieved, any procedures nested in it are also retrieved.
You can use procedure nesting to store commonly used pieces of JCL and data (especially data tables)
as separate procedures. These procedures can then be retrieved, as needed, by nesting them in other
procedures. If one of these separate procedures needs modification, you change only that one
procedure. When another procedure calls the procedure, the updated version is automatically
retrieved; so the expanded job stream reflects all changes.
Use a DNEST statement to introduce each nested procedure.

// DNEST procname
This sample shows both the LVTOC procedure and the LVTOCS procedure that is nested in the LVTOC
procedure.
//LVTOC DPROC
//SYSIN DD *
// DNEST LVTOCS
//LVTOCS DPROC
When the LVTOC procedure is retrieved, it calls the LVTOCS procedure that is nested in it. Therefore,
this sample job stream calls both procedures.
//
The contents of both procedures replace the EXEC statement, and this job stream is submitted to JES
for execution.
//SYSIN DD *
08-Feb-2018 152/722
//
Include Data
You can design a procedure to perform the following:
Stop expansion at predefined points,
Read one or more records from the job stream,
Continue expansion of the procedure from the stopping point.
Procedures are useful for job streams that process data that change each time that the job is run and
for those jobs that read such data as a date card.
To use this facility, insert a DATA statement in the procedure at the point at which you want
expansion to stop.
// DATA
CA Driver replaces the DATA statement with the statements that follow the EXEC statement in the
input job stream. When CA Driver reaches a DEND statement, it returns to the procedure and
continues expansion.
For example, we could have designed procedure LVTOC so that the LISTVTOC statement is submitted
from the job stream rather than from within the procedure itself. Instead of including LISTVTOC in
the procedure, we use the DATA statement at the same point.
//LVTOC DPROC
//SYSPRINT DD SYSOUT=V
//SYSIN DD *
// DATA
Then we include the LISTVTOC statement on the input job stream followed by a DEND statement.
// DEND
//
When the procedure is expanded, the LISTVTOC statement replaces the DATA statement.
You can use any number of DATA statements in a procedure. Each DATA statement directs CA Driver
back to the job stream until a DEND statement is found. Therefore, if a job procedure contains three
DATA statements, the job stream submitted for processing must contain three DEND statements.
Variable parameters must be within the DPROC and cannot be within the statements that the DATA
and DEND include.
Verify Data Inclusion

To verify that the correct data is inserted into the expanded procedure at the appropriate places, you
can use the following:
A verification name on each DATA statement
08-Feb-2018 153/722
The same name on the DEND statement that terminates that data
// DATA LVTOCX
// DEND LVTOCX
Sometimes the name on the DATA statement and the name on the DEND statement are not the
same. CA Driver flags the condition as an error. The verification name must be one- to eight-
alphanumeric characters. The name begins with an alpha character, and does not have to relate to
the name of the procedure.
This example shows the same procedure with a data verification name.
//LVTOC DPROC
//VOL DD UNIT=SYSDA,VOL=SER,VSIAUX,DISP=SHR
//SYSIN DD *
// DATA LVTOCX
The same verification name is coded on the DEND statement that signals the end of the data
inclusion statements.
// DEND LVTOCX
//
Variable Parameters
A procedure in the CA Driver library can contain up to 64 symbolic parameters. A default value can be
defined for each parameter when the procedure is created. When the procedure is expanded, its
default value or a value on the EXEC or DPROC statement that calls the procedure replaces each
parameter. (If no default value is defined, supply a value on the EXEC or DPROC statement or on a
DSET statement.)
To use these symbolic parameters, list them on the //DPROC statement when the procedure is
created, with or without a default value.
//procname DPROC parmname=value,parmname=value,...
Then precede them with an ampersand (&) whenever they are referenced in the body of the
procedure. When the procedure is expanded, CA Driver replaces each occurrence of the parameter
with one of the following:
The value supplied on the EXEC or DPROC statement or on a DSET statement
The default value if no value is supplied on the EXEC or DPROC statement
This example shows the LVTOC procedure with two parameters, each with a default value.
//LVTOC DPROC VOL=3390,ID=VSIAUX
//SYSIN DD DD *
LISTVTOC VOL=&VOL=&ID,FORMAT
08-Feb-2018 154/722
If this procedure is called with no supplied values:

The procedure is expanded with the default values inserted in the body of the procedure in place of
&VOL and &ID.
//SYSIN DD *
//
If this procedure is called with a value for the VOL parameter only:
//CALL EXEC PROC=LVTOC,VOL=3380
The procedure is expanded with this value replacing &VOL and the default value replacing &ID.
//SYSIN DD *
//
Up to 64 variable parameters can be defined for each procedure. Each parameter must be named on
the //DPROC statement when the procedure is defined. The name must be from one to seven
alphanumeric characters (A-Z, 0-9), beginning with an alphabetic character. The underscore character
(_) is also acceptable except in the first character position. However, we recommend that you do not
use the underscore character in a variable name that is defined on the //DPROC statement so that
you avoid conflicts with any reserved-name variable parameters.
Array Elements
A variable parameter can be assigned multiple values or array elements. To indicate that a parameter
has an array of values, give the total number of values in parentheses following the parameter name
on the DPROC statement. For example, VAR(4) indicates that a parameter has four values. When this
procedure is expanded, each of these four values can be individually referenced as:
&VAR(1)
&VAR(2)
&VAR(3)
&VAR(4)
To define default values for any of these elements, specify the values in parentheses separated by
commas in the order of the array elements. To omit a default value, code a comma instead of the
value.
//NAME DPROC X(10),Y(3)=(A,B,C),Z(5)=(,,TESTJOB)
This example defines the following:
08-Feb-2018 155/722
A parameter named X, which consists of ten elements in an array, none of which have default
values.
A parameter named Y, which consists of three elements in an array, each of which has a default
value:
&Y(1) = A
&Y(2) = B
&Y(3) = C
A parameter named Z, which consists of five elements in an array, only the third of which has a
default value (TESTJOB).
To supply array values on the calling EXEC statement, list the values, enclosed in parentheses and
separated with commas. To omit a value, code a comma in place of the value.
//CALL EXEC PROC=LVTOC,VAR=(A,B,,D,,F)
This statement retrieves the LVTOC procedure and supplies override values for the first, second,
fourth, and sixth array elements of the VAR parameter. The third and fifth elements would retain
their default values. (These default values must be defined when the procedure is created.)
Attributes of Variables
Every variable parameter has two attributes: type and length. Variable parameter arrays also have a
third attribute: number.
Type Attribute (see page 156)

Test the Type Attribute (see page 157)
Length Attribute (see page 157)
Test the Length Attribute (see page 157)
Number Attribute (see page 157)
Test the Number Attribute (see page 158)
Each of these attributes can be tested during conditional expansion using the following format:
To test for Specify

Type T'parmname
Length L'parmname
Number N'parmname
Type Attribute
Variable parameters (or parameter array elements) fall into one of four categories. The category
depends on the type of value that replaces them when the procedure is expanded. (The actual
replacement value determines the type, not the defined value or how the value was stated.)
08-Feb-2018 156/722
If the replacement value is The type is

A character format C
A positive integer N
A negative integer M
Omitted (not the same as a null value) O
Test the Type Attribute

To test a variable parameter for type, prefix it with T'.
// DIF T'VAR1 EQ C GOTO CHARVALU
// DIF T'VAR2 EQ N GOTO ISNUMERC
Because variable parameters that are used in array indexing and segment subscripting must be
positive integers (type N), it is a good idea to test the type attribute of a variable parameter before
using it for such a purpose.
Length Attribute
The length attribute of a variable parameter (or an array element) is the number of bytes in the
replacement value.
If the replacement value is The length is

CA Driver 9
X 1
0049 4
(null) 0
27 2
Test the Length Attribute

To test a variable parameter for length, prefix it with L'.
// DIF L'VAR3 EQ 0 GOTO NOVALUE (zero length - null value)
// DIF L'VAR4 GT 4 GOTO TOOLARGE
Number Attribute
The number attribute gives the number of elements in a variable parameter array that have values
assigned to them, regardless of whether the value was assigned by default or on the DPROC
statement. For example, assume the procedure XYZ was created with the following statement:
//XYZ DPROC Q(8)=(A,B,C,,,,H)
If it is retrieved with an EXEC statement containing no override values, the number attribute of the
parameter Q is 4, because four of the eight array elements have default values. If it is retrieved with
an EXEC statement that supplies two additional values for the fourth and fifth elements:
//CALL EXEC PROC=XYZ,Q=(,,,D,E)
08-Feb-2018 157/722
The parameter now has a number attribute of six.
Test the Number Attribute

To test a variable parameter for number, prefix it with N'.
// DIF N'VAR6 LT 1 GOTO NOVALUES
// DIF N'VAR7 EQ 5 GOTO DONEALL
Null Values
This article explains how and when to use a null value.
Unless you supply a value for every variable parameter that is listed on the DPROC statement, the
procedure cannot be expanded. However, this value can be a null value. A null value can work as the
default value when the procedure is created or as the override value when the procedure is called. To
specify a null value on either the DPROC or EXEC statement, code two delimiters with anything in
between.
//CALL EXEC PROC=LVTOC,Y=(1,2,'',4)
This example supplies override values for array elements one through four of the Y parameter. The
value for the third element is a null value. (If the default value are supposed to be two apostrophes,
you could use slashes as the delimiters: /''/). If &Y(3) is referenced in the procedure, it is replaced
with nothing. In other words, the statement is expanded as though the parameter reference were
not there.
The same thing would happen if the default value is a null value and no override is supplied. For
example, assume that the parameter Y was defined with a null default value. No override value is
supplied when the procedure is called. When the procedure is expanded, each occurrence of Y is
replaced with a null character string. Thus, Y is effectively removed from the expanded statement as
these examples show.
This statement in the procedure: will be expanded like this:

//SYSUT1 DD DSN=&Y.FILE.DATA //SYSUT1 DD DSN=FILE.DATA
//SYSUT1 DD DSN=FILE&Y //SYSUT1 DD DSN=FILE
A null value is different from having no value associated with a variable parameter. If a parameter has
no default or override value, an error message is issued indicating that the procedure cannot be
expanded.
Reserved-Name Variable Parameters

CA Driver provides a set of reserved-name variable parameters. You can reference the parameters
anywhere that a variable parameter can be referenced in a CA Driver procedure. CA Driver
automatically assigns values when the reserved-name variable parameter is referenced during
procedure expansion. These reserved-name variable parameters cannot be defined in a DPROC
statement, and assigned values cannot be changed using the DSET statement. All reserved-name
variable parameters begin with &C_ to avoid conflicts with variable names defined on the DPROC
statement.
CA Driver Reserved-Name Variable Parameters

CA Driver offers the following reserved-name variable parameters:
08-Feb-2018 158/722
Note: All references to a scheduled job refer to a CA Workload Automation CA 7® Edition

scheduled job.
&C_DATE
Indicates the current system date in mm/dd/yy format.
&C_DAY
Indicates the current day of the week (MONDAY, TUESDAY, ...).
&C_JDATE
Indicates the current system Julian date in yyddd format.
&C_L2CA7
Indicates the CA Workload Automation CA 7 Edition instance name.
&C_L2SMF
Indicates the SMF ID of the LPAR where CA Workload Automation CA 7 Edition is executing.
&C_L27RL
Indicates the CA Workload Automation CA 7 Edition release.
&C_MONTH
Indicates the current month name (JANUARY, FEBRUARY, ...).
&C_TIME
Indicates the current system time in hhmmss format.
Example: Use CA Driver Reserved-Name Variables
This example procedure uses four of the CA Driver reserved-name variable parameters.
//TIMER DPROC
//* IT IS &C_TIME ON &C_DAY IN &C_MONTH AND THE DATE IS &C_DATE
The procedure is retrieved with the following statement:

//CALL EXEC PROC=TIMER
The procedure is expanded like the following example:

//* IT IS 103545 ON MONDAY IN APRIL AND THE DATE IS 04/05/yy
Information for a specific run of a scheduled job can be referenced by using the following variables:
&C_L2JN
Indicates the name of scheduled job.
&C_L2UID
Indicates the UID of scheduled job.
08-Feb-2018 159/722
&C_L2MID
Indicates the MAINID value for a scheduled job. This variable is not applicable to XPJOB jobs.
&C_L2SN
Indicates the SYSTEM name of scheduled job.
&C_L2QN
Indicates the name of queue where a scheduled job resides.
Value is REQUEST on LJCK displays.
&C_L27#
Indicates the CA Workload Automation CA 7 Edition job number for a scheduled job.
Value is 00001 on LJCK displays.
&C_L2LT
Indicates the LTERM value for a scheduled job. Value is the job name on LJCL displays.
&C_L2RO
Indicates the RO value for a job level COND-CODE test.
&C_L2CC
Indicates the value for a job level COND-CODE test.
&C_L2PRY
Indicates the PRIORITY value for a scheduled job as defined on the job definition panel.
&C_L2CLS
Indicates the CLASS value for a scheduled job as defined on the job definition panel.
&C_L2SID
Indicates the SCHEDULE-ID value for a scheduled job.
The value that is supplied from the SCHID keyword on LJCK displays.
&C_L2#T1
Indicates the number of TAPE1 tape drives for a scheduled job as defined on the job definition
panel. This variable is not applicable to XPJOB jobs.
&C_L2#T2
Indicates the number of TAPE2 tape drives for a scheduled job as defined on the job definition
panel. This variable is not applicable to XPJOB jobs.
&C_L2EM
Indicates the entry mode for a scheduled job, such as DEMAND or RUN. Value is SSCAN on LJCK
displays.
&C_L2DOD
Indicates the due-out date for a scheduled job (YYDDD).
&C_L2DOT
Indicates the due-out time for a scheduled job (HHMM).
08-Feb-2018 160/722
&C_L2DLD
Indicates the deadline date for a scheduled job (YYDDD).
&C_L2DLT
Indicates the deadline time for a scheduled job (HHMM).
Note: All values for the CA Workload Automation CA 7 Edition reserved-name variables are
derived from JQREC for the submitted job, unless CA Driver is invoked from LJCK. In that
case, some values are determined from database information.
Example: Use Reserved-Name Variable Parameters
This example illustrates the use of CA Workload Automation CA 7 Edition reserved-name variable
parameters.
//COMMENTS DPROC
//* &C_L2JN was scheduled via &C_L2EM and was assigned the following
//* CA 7 job number: &C_L27#. Thank you for your support.
The procedure is retrieved using the following statement:

//STEP EXEC PROC=COMMENTS
If job ABC123 was demanded and received a CA Workload Automation CA 7 Edition job number of
02233 and used the JCL mentioned previously, the following expansion would result:
//* ABC123 was scheduled via DEMAND and was assigned the following
//* CA 7 job number: 02233. Thank you for your support.
Substrings
This article explains how and when to use substrings.
You can reference part of the value given to a variable parameter instead of the entire value. To
reference part of the value, specify two numbers in parentheses following the parameter name.
&parmname(n,m)
n
Indicates the location within the value of the start of the substring.
m
Indicates the length of the substring (one or more bytes).
These examples show how the two numbers identify the substring that is being referenced.
Parameter Value Substring Reference Substring Value

&VAR1 HOWDY &VAR1(1,2) HO
&VAR1 89 &VAR1(2,1) 9
Variable parameters that represent numbers can also identify substrings. This representation is
08-Feb-2018 161/722
Variable parameters that represent numbers can also identify substrings. This representation is
illustrated in the following:
Parameter Value Substring Reference Substring Value

&VAR2 4
&VAR3 2
&VAR4 12/31/14 &VAR4(&VAR2,&VAR3) 31
These sample control statements show how to base procedure expansion on the contents of a
substring, rather than on the entire parameter value:
The following control statement references a substring to test only the month portion of the date
value (1st and 2nd positions).
// DIF C_DATE(1,2) NE 01 GOTO MONTHERR
The following control statement references a substring to check for a slash in the date (third
position).
// DIF C_DATE(3,1) NE '/' GOTO ERROR
The following control statement references a substring to set VAR1 equal to year portion of date
value (7th and 8th positions).
// DSET VAR1=&C_DATE(7,2)
The following control statement references a substring to test only part of VAR1 (VAR2 and VAR3
represent numbers).
// DIF VAR1(&VAR2,&VAR3) EQ 9 GOTO OK1
CA Driver and Predefined Functions

CA Driver recognizes a set of predefined functions. A CA Driver function has a reserved name and
accepts one or more parameters. The following sample is the general format of a function:
function(parameter1,parameter2,..)
Function parameters can be absolute constants or can be coded as variable parameters containing
valid values that the function expects. In either case, parameters values must be in valid format and
must follow the order required by the function.
CA Driver functions are recognized on the right side of the DSET statement. To set a variable to the
result of the predefined function, use the following format:
// DSET variable=function(parameter1,parameter2,...)
For example,
// DSET VAR1=DTADD(1,&C_JDATE)
The preceding statement adds one to the current system date and stores the result in variable VAR1.
(The DTADD function automatically handles all month-end and leap-year adjustment.)
The primary value of these functions is that they can be used to automate your JCL setup. By
08-Feb-2018 162/722
The primary value of these functions is that they can be used to automate your JCL setup. By
encoding the functions in your CA Driver procedures, you eliminate the need for JCL staging and
manual manipulation. Because all functions have parameters that accept or default to CA Driver
variable parameters, the power of the functions and the variable parameters can be combined.
The functions perform more than simple arithmetic operations because they count transitions
between months, years, and periods so that they return the expected values.
Arithmetic Date Functions (see page 163)

Date Conversion Functions (see page 164)
Day-Of-Month Functions (see page 166)
Arithmetic Date Functions

CA Driver offers the following arithmetic date functions. CA Driver automatically handles all leap-
year, month-end, and year-end adjustments.
DTADD(n,&var)
Adds "n" to variable "&var." The variable &var must contain a valid Julian date in the yyddd
format. The n represents a number of days to add to &var. The n can be a positive numeric
constant or a variable containing a positive numeric value..
Example: If &C_JDATE=08366,
DTADD(4,&C_JDATE)=09004
DTSUB(n,&var)
Subtracts "n" from variable "&var." The variable &var must contain a valid Julian date in the
yyddd format. The n represents a number of days to subtract from &var. The n can be a positive
numeric constant or a variable containing a positive numeric value.
DTSUB(8,&C_JDATE)=09363
DTDIF(&var1,&var2)
Subtracts variable "&var2" from variable "&var1" The variables &var1. and &var2. must contain
valid Julian dates in the yyddd format.
DTDIF(09045,&C_JDATE)=5.
MNADD(n,&var)
Adds "n" to variable "&var." The variable &var must contain a valid Julian date in the yyddd
format. The n represents a number of months to add to &var. The n can be a positive numeric
constant or a variable containing a positive numeric value.
MNADD(2,&C_JDATE)=09082
MNSUB(n,&var)
Subtracts "n" from variable "&var." The variable &var must contain a valid Julian date in the
yyddd format. The n represents a number of months to subtract from &var. The n can be a
positive numeric constant or a variable containing a positive numeric value.
MNSUB(1,&C_JDATE)=09008
08-Feb-2018 163/722
Date Conversion Functions

CA Driver offers the following date conversion functions. CA Driver automatically handles all leap-
year, month end, and year-end adjustments.
DMY(&var)
Converts variable "&var" into ddmmyy format. The variable &var must contain a valid Julian date
in the yyddd format.
Example: If &C_JDATE=09032, DMY(&C_JDATE)=010209
MDY(&var)
Converts variable "&var" into mmddyy format. The variable &var must contain a valid Julian date
Example: If &C_JDATE=09032, MDY(&C_JDATE)=020109
YMD(&var)
Converts variable "&var" into yymmdd format. The variable &var must contain a valid Julian date
Example: If &C_JDATE=09032, YMD(&C_JDATE)=090201
DMYR(&var)
Converts variable "&var" into ddmmccyy format. The variable &var must contain a valid Julian
date in the yyddd format.
DMYR(&C_JDATE)=01022009
MDYR(&var)
Converts variable "&var" into mmddccyy format. The variable &var must contain a valid Julian
MDYR(&C_JDATE)=02012009
YRMD(&var)
Converts variable "&var" into ccyymmdd format. The variable &var must contain a valid Julian
YRMD(&C_JDATE)=20090201
DM3Y(&var)
Converts variable "&var" into ddmonyy format. The variable &var must contain a valid Julian date
DM3Y(&C_JDATE)=01FEB09
M3DY(&var)
Converts variable "&var" into monddyy format. The variable &var must contain a valid Julian date
M3DY(&C_JDATE)=FEB0109
08-Feb-2018 164/722
YM3D(&var)
Converts variable "&var" into yymondd format. The variable &var must contain a valid Julian date
YM3D(&C_JDATE)=09FEB01
DM3YR(&var)
Converts variable "&var" into ddmonccyy format. The variable &var must contain a valid Julian
DM3YR(&C_JDATE)=01FEB2009
M3DYR(&var)
Converts variable "&var" into monddccyy format. The variable &var must contain a valid Julian
M3DYR(&C_JDATE)=FEB012009
YRM3D(&var)
Converts variable "&var" into ccyymondd format. The variable &var must contain a valid Julian
YRM3D(&C_JDATE)=2009FEB01
DAY(&var)
Converts variable "&var" into the day of the week (MONDAY, TUESDAY, and so on). The variable
&var must contain a valid Julian date in the yyddd format.
DAY(&C_JDATE)=SUNDAY
MONTH(&var)
Converts variable "&var" into the month name (JANUARY, FEBRUARY, and so on). The variable
&var must contain a valid Julian date in the yyddd format.
MONTH(&C_JDATE)=FEBRUARY
MON(&var)
Converts variable "&var" into a three character abbreviation of the month name (JAN, FEB, and so
on). The variable &var must contain a valid Julian date in the yyddd format.
Example: If &C_JDATE=09032, MON(&C_JDATE)=FEB
MON#(&var)
Converts variable "&var" into the month number (01,02,03, and so on). The variable &var must
contain a valid Julian date in the yyddd format.
Example: If &C_JDATE=09032, MON#(&C_JDATE)=02
DOW(&var)
Converts variable "&var" into a three-character abbreviation of the day of the week name (SUN,
MON, and so on). The variable &var must contain a valid Julian date in the yyddd format.
Example: If &C_JDATE=09032, DOW(&C_JDATE)=SUN
08-Feb-2018 165/722
DOW#(&var)
Converts variable "&var" into a two-digit day of the week (01, 02, 03, and so on). The two digit
numbering begins with Sunday (01). The variable &var must contain a valid Julian date in the
yyddd format.
Example: If &C_JDATE=09032, DOW#(&C_JDATE)=01
WOM(&var)
Converts variable "&var" into a two-digit week of the month (01, 02, 03, and so on). The variable
&var must contain a valid Julian date in the yyddd format. This value refers to full weeks (not
partial).
Example: If &C_JDATE=09096, WOM(&C_JDATE)=01
WOY(&var)
Converts variable "&var" into a two-digit week of the year (01, 02, 03, and so on). The variable
&var must contain a valid Julian date in the yyddd format. This value refers to full weeks (not
partial).
Example: If &C_JDATE=09096, WOY(&C_JDATE)=14
WOM#(&var)
Converts variable "&var" into a two-digit week of the month (01, 02, 03, and so on). The variable
&var must contain a valid Julian date in the yyddd format. Because the weeks are defined from
Sunday to Saturday, the first week sometimes only contains a couple of days.
Example: If &C_JDATE=09096, WOM#(&C_JDATE)=02
WOY#(&var)
Converts variable "&var" into a two-digit week of the year (01, 02, 03, and so on). The variable
&var must contain a valid Julian date in the yyddd format. Because the weeks are defined from
Sunday to Saturday, the first week may only contain a couple of days.
Example: If &C_JDATE=09096, WOY#(&C_JDATE)=15
Day-Of-Month Functions
CA Driver offers the following day-of-month functions. These functions return dates or portions of
dates by counting a specified number of days forward from the beginning of months or backwards
from the end of months. CA Driver automatically handles all leap-year, month end, and year-end
adjustments. The functions are useful for coding procedures that require a date that is always some
days from the beginning or end of the month such as a billing date that is constantly on the 10th day
of the month.
LDOM(n,yyddd)
Returns the day-of-month number by counting n days backwards from the end of the month of
the Julian date (yyddd) specified. Counting begins at 1 on the last day of the month. (n=1 returns
the last day of the month.) If yyddd is not specified, the default is the current &C_JDATE value.
The n has a range of 1-31.
Example 1: LDOM(2,09025)=30
Example 2: LDOM(2,09045)=27
JDOM(n,yyddd)
Returns a Julian date by counting n days from the beginning of the month of the Julian date
(yyddd) specified. Counting begins at 1 on the first day of the month. (n=1 returns a Julian date
representing the first day of a month.) If yyddd is not specified, the default is the current
08-Feb-2018 166/722
representing the first day of a month.) If yyddd is not specified, the default is the current
&C_JDATE value. The n has a range of 1-31.
Example 1: JDOM(2,09025)=09002
Example 2: JDOM(2,09045)=09033
LJDOM(n,yyddd)
Returns a Julian date by counting n days backward from the end of the month of the Julian date
(yyddd) specified. Counting begins at 1 on the last day of the month. (n=1 returns a Julian date
representing the last day of a month.) If yyddd is not specified, the default is the current
&C_JDATE value. The n has a range of 1-31.
Example 1: LJDOM(2,09025)=09030
Example 2: LJDOM(2,09045)=09058
Conditional Procedure Expansion

You can use the CA Driver conditional procedure expansion to accomplish the following tasks:
Control which parts of a procedure are expanded, based on logic in the procedure.
Branch forward or backward within a procedure, which is based on the variable parameter values
that are supplied on the EXEC statement.
These commands are available to program conditional procedure.
Code the commands in control statements like the following example:

//name command operands
The name is an optional user-defined value. The value is given to a control statement so that it can be
referenced in DGOTO and DIF statements.
Each of the commands is described on the following articles.
Abort Expansion (DFLUSH) (see page 167)

Abort Expansion of the Current Procedure (DABORT) (see page 168)
Branch (DGOTO) (see page 168)
Control Loops (DLCTR) (see page 168)
Define Conditions (DIF) (see page 169)
Define Step Names (DSTEP) (see page 170)
Set Variable Parameters (DSET) (see page 170)
Abort Expansion (DFLUSH)

Use the DFLUSH command to terminate completely procedure expansion.
//name DFLUSH
The DFLUSH statement flushes not only the remainder of the current procedure, but the remainder
of any calling procedures too.
08-Feb-2018 167/722
Abort Expansion of the Current Procedure (DABORT)

Use the DABORT command to terminate expansion of the current procedure. Calling procedures
continue to expand typically.
//name DABORT
Branch (DGOTO)
Use the DGOTO command to stop procedure expansion, branch forward or backward to another
control statement, and continue expansion at that point.
//name1 DGOTO name2
DGOTO Examples
//name DGOTO ONE
//name DGOTO DAILYRUN
//name DGOTO STEP1
//name DGOTO 1
The following example demonstrates how to use DSTEP and DGOTO statements to restart an
abended job stream at step three instead of step one. To do this restart, the procedure is defined
with a variable parameter named RESTART that has a default value of STEP01.
//PAYROLL DPROC RESTART=STEP01
//* THIS JOB IS BEGINNING AT STEP &RESTART
// DGOTO &RESTART
//STEP01 DSTEP
//* STEP STEP01 ...
//STEP1 EXEC PGM=PAY01
// DD ...
//SYSIN DD *
// DATA
/*
//STEP02 DSTEP
//* STEP STEP02
// DD ...
// DD ...
//STEP03 DSTEP
//* STEP STEP03
// DD ...
If a restart is necessary, an overriding value is supplied for the RESTART parameter specifying the
stepname at which restart is to begin. In this case, this is step three:
//CALL EXEC PROC=PAYROLL,RESTART=STEP03
This procedure could easily be expanded to include logic that would make step selection stop at any
specified stepname and start at any specified stepname.
Control Loops (DLCTR)

As a result of backward step branching during procedure expansion, procedure expansion can enter a
loop. CA Driver automatically terminates procedure expansion when any stepname is referenced
more than 16 times. To override the default value of 16-step references, use the DLCTR command
and specify a number.
//name DLCTR n
08-Feb-2018 168/722
//name DLCTR n
The number that you specify (n) is the maximum number of times any one step can be branched to. If
any step is referenced n+1 times, an error message is produced and procedure expansion is
terminated.
DLCTR Examples
// DLCTR 4
// DLCTR 90
// DLCTR 999
Define Conditions (DIF)

Use the DIF command for conditional forward and backward branching. Code the DIF control
statement in this format, supplying the values shown in following:
//name1 DIF parmname operator value GOTO name2
Note: Do not confuse the DGOTO statement with the GOTO clause of the DIF statement.
name1
Defines an optional name for this control statement that allows it to be referenced in other DIF or
DGOTO statements.
parmname
Specifies a variable parameter that was defined on the DPROC statement when the procedure
was cataloged.
operator
Identifies the relationship between the parameter and the value as one of these operators: LT,
GT, EQ, NE, GE, or LE. The symbols =, <, > can be used instead of EQ, LT, and GT.
value
Defines a character string against which to test the variable parameter. The string can be 1-64
characters in length. Delimit the string with quotes or some other special character when it
contains other than all alphanumeric characters. (If this character string is a different length than
the value of the parameter, the length of the parameter value is used.) This value can also be a
variable.
name2
Specifies the name of another control statement to branch to when these conditions are met.
DIF Examples
// DIF VAR1 EQ YES GOTO STEP1
// DIF VAR2 NE 'DAILY RUN' GOTO MONTHLY
// DIF VAR3 LE 99 GOTO TESTOK
// DIF SIZE GT 120 GOTO TOOLARGE
08-Feb-2018 169/722
The following example demonstrates how conditional procedure expansion selects different job steps
from a large procedure, depending on the day of the week. The reserved variable C_DAY is used to
inform the procedure of the day of the week. The procedure is stored in the CA Driver library as
follows:
//PAYROLL DPROC
//* THIS PAYROLL REPORTING RUN IS FOR &C_DAY
//STEP1 EXEC PGM=PAYRUN
// DD ...
// DD ...
// DIF C_DAY NE FRIDAY GOTO NOTFRI
//* THIS STEP IS PROCESSED ONLY ON FRIDAYS
//STEP2 EXEC PGM=RECAP
// DD ...
// DD ...
//NOTFRI DSTEP
//* END OF PAYROLL
When this procedure is called on Monday, this expanded job stream is submitted.
//* THIS PAYROLL REPORTING RUN IS FOR MONDAY
// DD ...
// DD ...
//* END OF PAYROLL
When this procedure is called on Friday, this expanded job stream is submitted.
//* THIS PAYROLL REPORTING RUN IS FOR FRIDAY
// DD ...
// DD ...
//* THIS STEP IS PROCESSED ONLY ON FRIDAYS
//STEP2 EXEC PGM=RECAP
// DD ...
// DD ...
//* END OF PAYROLL
Define Step Names (DSTEP)

Use the DSTEP command to assign a name to a control statement. Naming a control statement lets
you branch to that statement from a DIF or DGOTO statement.
//name DSTEP
Names can be one to eight alphanumeric characters. A maximum of 256 names can be defined in
each procedure.
DSTEP Examples
//ONE DSTEP
//DAILYRUN DSTEP
//STEP1 DSTEP
//1 DSTEP
Set Variable Parameters (DSET)

Use the SET command to change the value of a variable parameter during conditional expansion.
Code the name of the parameter and the new value in this format with no spaces after the
parameter name.
//name DSET parmname=value
08-Feb-2018 170/722
The value can be one of these values:
An integer, either positive or negative

// DSET VAR1=4 (positive value is assumed)
// DSET VAR=+22 (positive value can be explicit)
// DSET VAR=-3 (negative value must be explicit)
The result of an arithmetic expression using integer values and arithmetic operators (+, -, *, /)
// DSET VAR1=4-2
// DSET VAR1=8+7
// DSET VAR1=4*3
// DSET VAR1=8/4
A character string
// DSET VAR1=NO
// DSET VAR1='A CHARACTER STRING'
The value of another variable parameter

// DSET VAR1=&VAR2
The result of an arithmetic expression using two variable parameters or one variable parameter
and an integer. (Variable parameters that are used in arithmetic expressions must have numeric
values associated with them, rather than character values. The results of all arithmetic operations
are truncated to provide only integer results.)
// DSET VAR1=&VAR1+1
// DSET VAR1=&VAR1+&VAR2
// DSET VAR1=&VAR2-&VAR3
// DSET VAR1=&VAR2*&VAR3
// DSET VAR1=&VAR2/2
Comments Inside CA Driver Procedures

Comments inside the CA Driver procedure vary for CPU jobs and XPJOB jobs. Two topics address
these differences separately. Use the navigation pane to the left for more information about these
differences.
Comments for CPU Jobs

By default, each statement in a CA Driver procedure is considered a part of the procedure and is
subject to modification by CA Driver. Even those statements that begin with '//*' and are considered
comments in JCL are eligible for CA Driver variable substitution.
This substitution can be useful in certain situations, but you sometimes want comments inside CA
Driver procedures that do not appear in expansions.
CA Driver can be instructed to ignore comment statements altogether. In this way, comment
statements can be used for documentation inside the procedure but does not appear in any displays
where the procedure is expanded.
08-Feb-2018 171/722
The DPROCCOM keyword on the OPTIONS statement in the initialization file controls the use of
comments inside CA Driver procedures. The default is DPROCCOM=NO. All CA Driver procedure
statements beginning with '//*' are subject to variable substitution and are included in procedure
expansions.
If DPROCCOM=YES is specified, CA Driver ignores any CA Driver procedure statement beginning with '
//*', and the statement does not appear in procedure expansions.
You can have comment statements inside CA Driver procedures that begin with a character string
other than '//*'. Code that string as a value on the DPROCCOM keyword. The value must not exceed
8 bytes and includes no blanks or commas. The value also cannot be one of the following: Y, YES, N,
or NO.
Comments for XPJOB Jobs

For XPJOB jobs, an asterisk (*) in column one denotes comments, assuming that the previous
statement is not a continued statement. You can embed comments into the CA Driver procedure, but
these comments are not used nor shown in the data sent to the destination agent. If the procedure
uses variables on the line, these variables are not reflected anywhere but in the returned comment
statement, which is not used.
Conditional Execution Based on Schedule ID Example

This article shows an example of conditional execution that is based on a Schedule ID.
You can use the &C_L2SID reserved name variable parameter to modify a parameter for a job. For
example, by convention, schedule ID 001 indicates that the job run with a parameter of MONTHLY.
Schedule ID 002 is associated with a parameter of WEEKLY. Schedule ID 003 is considered a DAILY run
by the job.
You can use CA Driver to generate a parameter to the job based on schedule ID.
//procname DPROC RUNTYPE=,VAR(4)=(MONTHLY,WEEKLY,DAILY,OTHER),HOLDSEL=
// DSET HOLDSEL=&C_L2SID
// DIF HOLDSEL LE 3 GOTO DOIT
// DSET HOLDSEL=4
//DOIT DSTEP
// DSET RUNTYPE=&VAR(&HOLDSEL)
//STEPNAME EXEC PGM=USERPGM,PARM=&RUNTYPE
XPJOB Driver Procedures Example

For an XPJOB, the CA Driver Procedure XPJDPROC is stored in the DPROC library (either CARPROC DD
statement or the DPROC library associated with the JCL or PARM library as defined through
initialization parameters). Notice the format of the first statement, which identifies the procedure
name.
//XPJDPROC DPROC TIME=60
PARM01='T=&TIME'
The XPJOB PARM member that invokes this procedure is coded as follows:
DPROC=XPJDPROC,TIME=30
08-Feb-2018 172/722
DPROC=XPJDPROC,TIME=30
PARM02=F=0012
The parameters sent to the destination platform are as follows (not all data sent to the platform is
represented here):
PARM01 T=30
PARM02 F=0012
Manage the Network Communications Facility

This article explains the Network Communications Facility (NCF) and how to use it. Many sites want
to maximize the use and effectiveness of their computer resources. One method is to route CPU jobs
(and their products) to some other data centers for processing, printing, and so forth. Generally,
these data centers are widely dispersed geographically. They can be located very close to each other,
however. In any case, JES performs the routing of jobs over a communications link between the data
centers. This routing is accomplished with JES control statements included within the JCL for the job.
IBM provides a Network Job Entry (NJE) facility within JES to handle the routing of jobs for processing
at another data center. NJE also routes any print or punch output to whatever location the user
wants to perform that function. Printing and punching of job output are not required at the location
where job execution occurs.
CA Workload Automation CA 7® Edition, in its native form, performs dynamic workload management
functions such as scheduling, prerequisite verification, job submission, and so forth, based on SMF
data. In an NJE environment, as in all environments, SMF data is only produced at the location where
job execution occurs. Installation of CA Workload Automation CA 7 Edition at that location is not
required. SMF data must, however, be returned to the CA Workload Automation CA 7 Edition that
originally submitted the job if CA Workload Automation CA 7 Edition is to be able to track the job.
NCF is an optional component of CA Workload Automation CA 7 Edition. NCF provides necessary

software to let the user fully use all workload management facilities of CA Workload Automation CA 7
Edition, whether some jobs are processed on an NJE basis.
With NCF, jobs submitted by CA Workload Automation CA 7 Edition can execute at any site within a
network of sites as if the site were a local CPU. NCF verifies that the CA Workload Automation CA 7
Edition that submitted a job receives the necessary SMF data for the job regardless of which site
processed the job.
No changes are required to the CA Workload Automation CA 7 Edition database for a job to run on an
NJE basis. The JCL for any such job must, however, contain the JES statements necessary to cause JES
to route the job to the desired location after CA Workload Automation CA 7 Edition has submitted it.
When execution does occur, CA Workload Automation CA 7 Edition performs its functions related to
the job as if the job executed in an initiator on a local CPU. This transparency to both CA Workload
Automation CA 7 Edition and the production user would not be possible without the NCF component.
08-Feb-2018 173/722
NCF Requirements
CA Workload Automation CA 7® Edition must exist at each node from which you want to submit CA
Workload Automation CA 7 Edition controlled jobs. ICOM (the Independent Communications
Manager) must be installed on each CPU where these jobs are to execute. CAIRIM plus the CA
Workload Automation CA 7 Edition SMF interface exits and SVC interface must also be installed on
each CPU.
The following are the minimum requirements for NCF:
Support for CA Workload Automation CA 7 Edition, under z/OS with JES2 or JES3, at a minimum of
one site.
Support for ICOM, under z/OS, at all sites.
Generation of SMF record types 14 (optional), 15, 26 (optional), 30, and 64 (optional) at all sites.
A VTAM environment that supports the Multisystem Networking Facility (MSNF) at all sites.
NJE jobs do not necessarily require special database definitions.
NCF Component Data Flow

The following list details the primary components of a Network Communications Facility (NCF)
system:
CAIRIM
SVC Interface
ICOM
Node Table
Unknown Node Table
NCF Communications Data Set
NCF Undeliverable Queue
NCF VTAM Application Program
NCF Test Data Generator
The following figures illustrate the data flow between these components within a single CPU and a
typical NCF environment. Many other variations are available.
For a detailed explanation of each NCF component in the data flow, see NCF Component Reference
(see page 176).
08-Feb-2018 174/722
The following graphic illustrates data flow within one sysplex:
The following graphic illustrates one typical NCF environment:
08-Feb-2018 175/722
NCF Component Reference

This article explains each NCF component.
CAIRIM (see page 176)

SVC Interface (see page 177)
ICOM and NCF (see page 177)
Node Table (see page 177)
Unknown Node Table (see page 178)
NCF Communications Data Set (see page 178)
NCF Undeliverable Queue (UDQ) (see page 178)
NCF VTAM Application Program (see page 179)
NCF Test Data Generator (see page 179)
CAIRIM
This topic explains the role of CA Resource Initialization Manager (CAIRIM) with NCF. CAIRIM is the
common driver for a collection of dynamic initialization routines. CAIRIM eliminates the need for
preinstalled user SVCs, SMF interface exits, subsystems, and other installation requirements
commonly encountered when installing systems software. These routines are grouped under the
service code S910, which is one of the CA Common Services for z/OS (CCS).
CA Workload Automation CA 7® Edition uses the CAISMFI Dynamic SMF Event Interceptor, which is a
08-Feb-2018 176/722
CA Workload Automation CA 7® Edition uses the CAISMFI Dynamic SMF Event Interceptor, which is a
subcomponent of CAIRIM. SMF recording must be active in the system for any SMF event or data
handling product routines. The CAIRIM SMF Interceptor component does not require any particular
SMF records.
SVC Interface
This article explains how NCF uses the SVC interface.
When each job is submitted to JES by CA Workload Automation CA 7® Edition, the JOB statement is
flagged with the originating node ID. The CA Workload Automation CA 7 Edition UJV SMF interface
exit preserves this ID in either the SMF Reader Time or SMF User ID fields. The location depends on
which location the user designates, in ICMDSECT, for this purpose.
The CA Workload Automation CA 7 Edition SMF interface exits call the CA Workload Automation CA 7
Edition SVC. The SVC uses this node ID to identify the CA Workload Automation CA 7 Edition location
that submitted the job and to which returns all SMF data for the job. The originating CA Workload
Automation CA 7 Edition node ID is used to distinguish between data to retained locally and data to
route back to CA Workload Automation CA 7 Edition at some other node.
The CA Workload Automation CA 7 Edition SVC interface obtains data from the CA Workload
Automation CA 7 Edition SMF interface exits and the CA Workload Automation CA 7 Edition trailer or
U7SVC programs. The SVC interface transfers this data across address spaces for any subsequent
processing by ICOM. The SVC interface and SMF interface exits must be installed at all sites for the
NCF processing to occur.
The execution location must generate the necessary SMF record types to satisfy CA Workload
Automation CA 7 Edition requirements. The data need not be also written to the SMF MANX/Y data
sets unless the user so chooses. This data that occurs at the execution site is available at the
originating CA Workload Automation CA 7 Edition site for logging in to the CA Workload Automation
CA 7 Edition log data set. The data is in standard CA Workload Automation CA 7 Edition log record
format.
ICOM and NCF

All ICOMs that run in an NCF environment must have the NCF modules available (for example,
STEPLIB). All ICOMs also require an extra DD statement pointing to the NCF communications data set.
This is an extension of the standard ICOM program. It must be installed at each node. It processes
data for local and remote records by extracting data from the SVC interface and writing local records
to the communications data set and remote records to the NCF communications data set.
Data received through VTAM at an originating node is routed through the SVC interface and
processed by ICOM as if it were generated locally.
Node Table
The node table defines nodes in the network for the NCF VTAM task. Up to 222 nodes can exist in any
one network. Each NCF node corresponds to a JES NJE node on a one-to-one basis. UCC7NODE is the
required name for the node table. Generation of the node table is accomplished with the UNCNOD
macro.
08-Feb-2018 177/722
Each node in the node table must have both a unique CA Workload Automation CA 7® Edition
identifier and a unique VTAM identifier (ACBNAME) as specified in a VTAM APPL definition. Each site
must have its own table.
To establish a successful communications link between the NCF VTAM tasks at any two nodes in the
network, a validation of the two node tables is automatically performed at "bind" time.
Note: For more information about this validation procedure and the UNCNOD macro, see
VTAM and NCF Node Table Definitions (https://wiki.ca.com/display/CWAC7E
/VTAM+and+NCF+Node+Table+Definitions).
Unknown Node Table

Occasionally, during processing, data is encountered for a node that is not defined in the node table.
Then, an entry is created in the unknown node table dynamically by the NCF VTAM task. Any SMF or
trailer data for such nodes are written to the undeliverable queue in addition to creating an entry to
this table.
Unless the user changes the node table while jobs are executing at a remote node in the network, no
unknown nodes typically occur.
If the unknown node table becomes full, a warning message is issued and any new undeliverable data
is dropped.
Data in the undeliverable queue for an unknown node can be purged with the PURGE command. Any
recurrence of data for this unknown node is also written to the undeliverable queue. The existing
entry in the unknown node table is reused.

The NCF communications data set acts as intermediate storage for remote data collection at each
node in the network. The data set contains SMF and CA Workload Automation CA 7® Edition trailer
data for jobs submitted from a remote node. This file must exist for NCF processing to occur. This
data set has a one-to-one relationship with a JES NJE SPOOL or job queue. In a multiple access spool
(MAS) complex or a single CPU site, only one data set is defined.
NCF Undeliverable Queue (UDQ)

The undeliverable queue, UDQ, contains data for nodes that do not have an active link, or that are
not defined in the node table. Any data that cannot be transmitted due to communication
interruptions are saved in this data set. This file must exist for NCF processing to occur.
If the UDQ becomes full, data that is contained in the file must be purged or transmitted or new data
is lost. A progressive series of warning messages are issued beginning when the file threshold (80
percent) is reached. The messages continue until the percentage used drops below the threshold
value.
08-Feb-2018 178/722
NCF VTAM Application Program

The NCF VTAM application program receives and transmits NCF data between nodes in the network.
This program receives control once VTAM and the NCF VTAM application program are started.
NCF Functions
The NCF VTAM application program performs the following functions:
Loads the node table
Builds the unknown node table
Establishes VTAM sessions with all other nodes
Packages outbound SMF and trailer data and transmits it through VTAM facilities to NCF at
another node for host CA Workload Automation CA 7® Edition processing
Processes NCF operator commands
Writes/reads undeliverable data to/from the UDQ
Receives data from the sending node and passes it to the SVC for processing by ICOM and later by
CA Workload Automation CA 7 Edition
Transmits a positive response to the sending node
NCF Test Data Generator

CA Workload Automation CA 7® Edition supplies a test program that generates sample data for use
by NCF. For testing purposes, change the EXEC statement for the NCF VTAM task to include two more
PARM values. The PARM value TEST indicates that the installation test is being performed. Another
PARM value, TABLE=member, can identify a node table to use for this test. This node table name
does not have to be UCC7NODE, but can be if you want. The coded PARM value for this test would be
similar to the following example:
PARM=('TIME=3000',TEST,'TABLE=UCC7NODB')
Note: The installation test parameters TEST and TABLE are not valid for use in a normal
production environment.
You can test the establishment of a session between two or more NCF nodes. The TEST and TABLE
parameters can execute two or more nodes on a single computer. Code the VTAM APPL definitions
correctly to permit a local-LU to local-LU session.
You can test data transmission between two nodes. Use the supplied data generator program that
you can execute with the following JCL:
// EXEC PGM=SASSNCDG,PARM='TABLE=xxxxxxxx'
//STEPLIB DD DISP=SHR,DSN=user load library
//UCC7NCFD DD DISP=SHR,DSN=user defined NCF communications data set
08-Feb-2018 179/722
//UCC7NCFD DD DISP=SHR,DSN=user defined NCF communications data set
//SYSIN DD DUMMY,BLKSIZE=80
Verify that the TABLE parameter specifies the same table that the NCF VTAM application program
that is to transmit the data uses. Sample data is generated, according to this table, for transmission
to all remote nodes. The SYSIN DD statement is required. Always code it as shown in the preceding
JCL unless otherwise directed by CA Support.
Note: NCF never invokes the CA Workload Automation CA 7® Edition SVC when
PARM=TEST is specified.
When you have completed testing with the NCF Test Data Generator, reinitialize the following items:
The ICOM communications data set (COMMDS)
The NCF communications data set (COMNCF)
The NCF undeliverable queue (UNDQUE)
The reinitialization removes the test data that is placed in these files.
NCF Planning and System Requirements

This article explains NCF planning and system requirements, including installation and resource notes.
At least one site in the network must have CA Workload Automation CA 7® Edition installed. The
installation of NCF is incorporated in Installing and Upgrading (https://wiki.ca.com/display/CWAC7E
/Installing+and+Upgrading). The information in this topic is provided to let you effectively plan the
installation of NCF. Installation requirements for sites that are not running CA Workload Automation
CA 7 Edition are slightly different from the requirements for sites that are running NCF.
NCF General Notes

This article explains terminology and installation.
NCF Terminology
The following terminology is used throughout the documentation and helps distinguish between
environments.
NCF
Network Communication Facility, a component of CA Workload Automation CA 7® Edition. Also
refers to the VTAM application program used to pass certain CA Workload Automation CA 7
Edition data from site to site.
NCF Complex
All sites connected by NCF.
08-Feb-2018 180/722
NCF1
A site that runs CA Workload Automation CA 7 Edition and NCF.
NCF2
A site that runs NCF but not CA Workload Automation CA 7 Edition.
Site
A node in an NJE network. Consists of one or more CPUs running with or without shared spool.
NCF and Installation

The following general items apply to installation:
CA Workload Automation CA 7 Edition must be installed in at least one of the sites in the NCF
complex.
If you plan to install both CA Workload Automation CA 7 Edition and NCF at a site, first install CA
Workload Automation CA 7 Edition and NCF at the NCF1 site. Next, proceed installing NCF at the
NCF2 sites.
Only the CA71 instance can use NCF.
All of the CPUs in the NCF Complex must have the CA Workload Automation CA 7 Edition SVC and
CA Workload Automation CA 7 Edition SMF interface exits installed. ICOM must be run on each
CPU in the complex. However, NCF itself only runs on one CPU per site.
The JOB statements for all jobs submitted by CA Workload Automation CA 7 Edition must have
blanks in columns 69, 70, and 71. (If external security is used with USERID insertion, column 68
must also be blank.)
Sites that run in different time zones can cause apparent date/time problems. Set the time values
in the CA Workload Automation CA 7 Edition database that the user establishes (for example,
DOTM) according to the time zone where the CA Workload Automation CA 7 Edition database is
located and not where the job is to run.
WLB values have less meaning because CA Workload Automation CA 7 Edition groups all the
resources together.
CA Workload Automation Restart Option for z/OS Schedulers controlled jobs require the CA
Workload Automation Restart Option for z/OS Schedulers database and programs be at the site
where the jobs are run. Also, all sites to which CA Workload Automation CA 7 Edition submits CA
Workload Automation Restart Option for z/OS Schedulers controlled jobs must use the same
procedure name for RMS. The RMS procedure name must be in the CA Workload Automation
Restart Option for z/OS Schedulers Option Table or in the CA Workload Automation CA 7 Edition
initialization file (RESTART statement).
The LOAD procedure inserted into jobs submitted by CA Workload Automation CA 7 Edition must
exist at all sites and the procedure name must be the same at all sites.
08-Feb-2018 181/722
A CA Workload Automation CA 7 Edition site that does not use NCF cannot send a CA Workload
Automation CA 7 Edition submitted job to a CA Workload Automation CA 7 Edition site that does
run NCF (NCF1 or NCF2) when a LOAD step is included in the JCL. This results in a U0110 abend in
the LOAD step. If there is no LOAD step, the job runs but does not track.
NCF Resource Requirements

For the NCF system to function, specific requirements must be met for the operating system,
memory size, and NCF data sets.
NCF Operating System Environment

NCF operates under all levels of the z/OS operating system that IBM supports.
Each site does not require the installation of CA Workload Automation CA 7® Edition for NCF to
function. ICOM must exist for each site and in each CPU where CA Workload Automation CA 7 Edition
controlled jobs are to execute. CA Workload Automation CA 7 Edition must exist at each site from
which you submit CA Workload Automation CA 7 Edition controlled jobs.
The CA Workload Automation CA 7 Edition SVC interface and SMF interface exits must be installed at
all sites and on all CPUs that can execute CA Workload Automation CA 7 Edition controlled jobs.
CAIRIM, CA Resource Initialization Manager, must be on each CPU too.
NCF Memory Requirements

The virtual memory requirements of the VTAM task are variable, based on the number of nodes in
the node table. Use the following formula to calculate the virtual region size:
Region size = 180KB + (4KB * (# of nodes))
Memory requirements of ICOM remain about the same, approximately 512 KB.
DASD Devices for NCF

NCF supports the following disk drives:
3375
3380
3390
9345
DASD Requirements for NCF

The permanent files for NCF consist of two data sets used by NCF itself and one data set used by
ICOM. Following is a description of the permanent files.

The NCF communications data set contains CA Workload Automation CA 7 Edition formatted SMF
and trailer data to transmit to remote nodes. In a multi-CPU site, this data set must reside on a
shared DASD device. Each CPU in the complex must execute a copy of ICOM, each of which shares
08-Feb-2018 182/722
shared DASD device. Each CPU in the complex must execute a copy of ICOM, each of which shares
this data set. The NCF communications data set is a formatted physical sequential data set with
the following characteristics:
DCB=(RECFM=F,BLKSIZE=1024,LRECL=1024)
The space required by the NCF communications data set depends on the amount of NCF activity.
We recommend a minimum allocation of 900 blocks. This data set must be formatted using the
SASSNC12 program. See the install job N030 for sample JCL.
Undeliverable Queue (UDQ)

The UDQ contains formatted SMF and trailer data that could not be transmitted because
communication with a node was interrupted or could not be established. The UDQ also contains
data for any nodes encountered during processing that have not been defined in the node table.
Unless the user changes the node table while NJE jobs are in the JES queue, either locally or
remote, no unknown node IDs typically occur. The undeliverable queue is a formatted physical
sequential data set with the following characteristics:
The space required by the UDQ depends on the amount of NCF activity. No less than one cylinder
is recommended. Allocate at least 600 blocks of space for each node to which data can be
transmitted. Experience sometimes shows that a particular site requires more space. Format this
data set using the SASSNC15. See the install job N030 for sample JCL.
ICOM Communications Data Set

The ICOM communications data set contains CA Workload Automation CA 7 Edition formatted
SMF and trailer data for the local CA Workload Automation CA 7 Edition to process. This data set
must reside on a shared DASD device for multi-CPU sites. For NCF1 sites, this data set is allocated
and initialized during CA Workload Automation CA 7 Edition installation. The ICOM
communications data set is a formatted physical sequential data set with the following
characteristics:
Space required for the ICOM communications data set at NCF2 sites is approximately 100-150
blocks (about five tracks on 3390 devices). At NCF1 sites, space is determined during CA Workload
Automation CA 7 Edition installation. For NCF2 sites, the *CPU* statement used to format the file
specifies UCC7NCF2 (not UCC7IRDR or UCC7SUB1). Failure to do this specification could possibly
result in ICOM looping.
CAIRIM System Requirements for NCF

The installation of NCF requires the installation of CAIRIM at each site where NCF executes. This
service is sometimes already installed with another CA product.
NCF Implementation Considerations

This article details key considerations before you implement NCF.
Using JES NJE capabilities to address requirements for production processing in the CA Workload
Automation CA 7® Edition environment requires the installation of the necessary software at the
processing sites. Using JES NJE capabilities also requires some production planning for implementing
jobs under CA Workload Automation CA 7 Edition.
08-Feb-2018 183/722
NCF provides the user with software that lets CA Workload Automation CA 7 Edition submit jobs.
These jobs, through JES NJE routing, execute at a remote site, yet let CA Workload Automation CA 7
Edition control and monitor the jobs as if they were executing locally. Even without the support of
NCF, jobs that are routed to a remote site or node through JES can execute at the desired destination
node. CA Workload Automation CA 7 Edition at the local site or node would, however, be unable to
track the jobs automatically through SMF feedback. All SMF data for the job would occur only at the
remote node at which execution occurred. Using the NCF component software, production
processing can occur at any remote node as if the remote processor and initiator were a local
initiator.
However, implementation planning for the production user is critical to the success of this
processing. Use the navigation pane to the left to find information about these items.
NCF General Usage

Several facilities routinely used at local nodes can also be used at remote NJE nodes as long as the
load modules are installed at the remote site. These facilities include the following:
Trailer step (SASSTRLR)
Batch card load program (SASSBCLP)
U7SVC utility
LOAD process (SASSJJCL)
All features of these facilities function the same for both local and remote nodes. Jobs can be
demanded, requirements can be posted, and so forth, by executing these programs at the execution
node. CA Workload Automation CA 7® Edition makes processing decisions based on the feedback
provided by NCF support. Activities that CA Workload Automation CA 7 Edition is to perform as a
result of the execution of these programs that CA Workload Automation CA 7 Edition controls,
wherever it resides. Jobs demanded or released by these facilities can execute at any node in the
network. The execution is based on the routing that is specified in JES control statements within the
JCL for the jobs.
NCFNODE Parameter
When executing SASSTRLR, the EXEC statement can be coded with a node name in the PARM
parameter. This coding routes the event posting data to CA Workload Automation CA 7 Edition
residing at the node name specified. If this parameter is not coded, the feedback data is sent to the
CA Workload Automation CA 7 Edition location that submitted the job.
If used, the parameter must be first and would be coded in the following format:
PARM='NCFNODE=nodename,...'
nodename identifies which node to send posting data. The node name must exist in the NCF node
table as defined with the NODNAME parameter of the UNCNOD macro.
Note: For more information about node names, see VTAM and NCF Node Table Definitions (
https://wiki.ca.com/display/CWAC7E/VTAM+and+NCF+Node+Table+Definitions).
08-Feb-2018 184/722
LOAD Process and NCF

The LOAD process is performed at the execution site. Data from this process is automatically
returned to the originating CA Workload Automation CA 7 Edition site for updating of the CA
Workload Automation CA 7 Edition database. Job characteristics in the database reflect the resource
and data set information from the execution environment. This information includes the RESOURCE
data on the DB.1 panel, the cross-reference reports, and all other references to data sets and
resources within CA Workload Automation CA 7 Edition.
Data set requirements and triggers are supported no matter where the job executes. The data sets
must physically reside at the execution node for proper execution to occur.
Data Sets and NCF

Users must verify JCL, program, and other module library requirements. In addition, the user must
also verify that production data sets are located at the execution node and, if applicable, are
cataloged correctly. Some production data sets can always be maintained at one site while others are
sometimes required at more than one site. The user must verify that the correct version of each data
set is available at the execution node before job execution.
References to data sets in all DD statements must meet the requirements of the execution node.
CA 7 Database and NCF

NCF supports CA Workload Automation CA 7® Edition jobs that execute at a remote NJE node. Actual
execution can occur at any location within the network of CPUs. The execution location is transparent
to the production control person. However, CA Workload Automation CA 7 Edition database
considerations for scheduling and the DB.1 panel are important for NJE jobs.
Scheduling and NCF

All CA Workload Automation CA 7 Edition scheduling considerations are the same for NJE jobs as for
jobs that execute locally. Triggers, calendar schedules, job dependencies, use of networks, and so
forth, are fully supported for NJE jobs. The only difference is that NJE jobs execute at a remote site.
Users are responsible for verifying that the remote node is prepared to process the job when it
arrives.
Note: The day and time values that are specified in defining the schedules for the jobs are
the values that are used by the CA Workload Automation CA 7 Edition into which they are
defined. For example, consider a situation where site A is in New York and site B is in Los
Angeles. Job X is to run at site A and is due out at 10:00 a.m., New York time. If the job is
defined in the CA Workload Automation CA 7 Edition database at site B, mark the due-out
time for the job as 7:00 a.m.
08-Feb-2018 185/722
DB.1 Panel and NCF

Fields on the DB.1 panel are used for NJE jobs with only a few special items to consider. The
GENERAL, JCL, REQUIREMENTS, and MESSAGES segments of the DB.1 panel are used as they would
be without NCF.
All the fields in the EXECUTION segment have the same meaning except one. The MAINID field for an
NJE job, when used, specifies a CPU from which JES can transmit the job to the proper remote node
(after CA Workload Automation CA 7 Edition submits the job to JES). Users are still responsible for
verifying that the job contains the necessary JCL. The JCL must JES to do the routing once JES receives
an NJE job that CA Workload Automation CA 7 Edition submitted.
If the INSERT-RMS field in the EXECUTION segment has a value of Y, CA Workload Automation CA 7
Edition inserts the step that executes CA Workload Automation Restart Option for z/OS Schedulers.
In these cases, CA Workload Automation Restart Option for z/OS Schedulers must be installed at the
location where the job executes.
Fields in the RESOURCES segment of the DB.1 panel apply to resources that must be available at the
remote node.
Execution Options for NCF

An option can specify the time that is allowed for asynchronous processing with NCF. The option also
enables the interfaces to external system state monitoring systems ARM and CA OPS/MVS® Event
Management SSM.
Sample NCF VTAM PARM (see page 187)

Sample NCF VTAM JCL (see page 187)
These options are specified in the JCL PARM field of the EXEC statement for the NCF VTAM
application program. The option is specified as follows:
PARM='[ARM={NO|YES}]
[,OPSSSM={NO|YES}]
[,TIME={3000|tttttttt}]'
ARM
(Optional) Indicates to register the NCF task with ARM.
NO
Disables the interface. This value is the default.
YES
Enables the ARM interface.
OPSSSM
(Optional) Indicates to report NCF task state changes to CA OPS/MVS SSM.
NO
Disables the interface. This value is the default.
YES
Enables the CA OPS/MVS SSM interface.
08-Feb-2018 186/722
TIME
(Optional) Indicates the duration of the WAIT that the NCF VTAM application program issues
when an attempt to enqueue the NCF communications data set fails. This parameter sometimes
requires adjustment to minimize any data set contention, especially in a MAS environment.
This time limit is also used to synchronize the initial LOGON processing during NCF startup. If all
remote nodes have not attempted to LOGON when the limit is reached, a warning message (CA7.
NC203) is issued. The remaining LOGONs are allowed to complete asynchronously while normal
processing commences.
3000
Specifies the default time limit (30 seconds) in one hundredths of a second.
tttttttt
Specifies a user-specified time limit in one hundredths of a second. Leading zeros can be
omitted.
Sample NCF VTAM PARM

The following coded example shows the PARM for the NCF VTAM application program:
//NCF EXEC PGM=NCF,PARM='ARM=YES,OPSSSM=YES,TIME=00002500'
Sample NCF VTAM JCL

The following JCL is an example of the NCF VTAM task:
//jobname JOB *user job statement specifications*
/*JOBPARM *user specifications*
//*
//NODE1 EXEC PGM=NCF,PARM='TIME=3000'
//UCC7SNAP DD SYSOUT=*
//SYSABEND DD SYSOUT=*
//SYMDUMP DD DUMMY
//UCC7NCFD DD DISP=SHR,DSN=user defined communications data set
//UCC7NCFU DD DISP=OLD,DSN=user defined NCF undeliverable queue
//*
The UCC7SNAP DD statement cannot have FREE=CLOSE specified.
User Execution JCL

User execution JCL for the NJE jobs must be located at the CPU site from which CA Workload
Automation CA 7® Edition initially submits the job to JES. The JCL segment of the DB.1 panel must
define where the JCL can be found.
Take care with any LTERM value specified in the MESSAGES segment of the DB.1 panel or in the JCL
statement in the initialization file. The LTERM values cause messages to go to a terminal where
problems can be properly addressed when they arise.
JOB Statement and NCF

Because the job executes at a remote site with its own version of the operating system, fields in the
JOB statement must meet the requirements of the remote site. The requirements include the
following JOB statement fields:
Job name
08-Feb-2018 187/722
Job name
Accounting data
Job class
To control the job, positions 69 through 71 of the JOB statement are reserved for indicators that CA
Workload Automation CA 7 Edition manages. Position 69 must always contain a blank (to prevent JCL
errors). Positions 70 and 71 contain indicator bytes set by CA Workload Automation CA 7 Edition for
execution control purposes. These reserved positions in the JOB statement must be reserved in all CA
Workload Automation CA 7 Edition controlled jobs whenever NCF support is used for any jobs.
In a CA Workload Automation CA 7 Edition environment without NCF support, only positions 70 and
71 of the JOB statements were reserved. To avoid problems when NCF is installed, the user must
verify that all JOB statements that CA Workload Automation CA 7 Edition handles do not violate this
convention.
Note: Use of external security can require an additional column of the JOB statement..
JES2 Statements and NCF

Jobs can be routed to a remote node for execution, through JES2, through one of the following
control statements:
/*ROUTE
/*XEQ
See the IBM publications for more information these statements. When used, these statements are
located in the local execution JCL library immediately after the JOB statement. Once CA Workload
Automation CA 7 Edition submits the job to JES, these statements direct JES2 to route the job to the
proper NJE node.
JES2/NJE also supports the /*XMIT control statement. This statement is only documented in the JES2
documentation. When used, the name of the job transmitted to the remote node must be the same
as the name of the job that caused the transmission of the job.
Consider the use of the /*ROUTE statement to direct printed or punched output to the proper
location carefully. Its function varies depending on where it is positioned in the JCL relative to the
position of a /*ROUTE XEQ statement.
JES3 Statements and NCF

In a JES3 environment, the following JES3 statements are used to control the routing of jobs and their
output to the proper JES3 locations:
//*MAIN
//*FORMAT
IBM publications contain more information about these statements.
08-Feb-2018 188/722
EXEC Statements and NCF

All programs, including all utility type programs, executed in NJE jobs must exist at the execution
node as opposed to the submission node. Existence of the programs at the execution node is the
responsibility of the user.
Cataloged procedures used in NJE jobs must also be located at the site where conversion and
interpretation of the cataloged procedures occur.
DD Statements and NCF

Data definition (DD) statements, in addition to referencing a data set located at the execution site,
must also meet the requirements of the execution node for the following:
Catalog conventions including data set name index levels
Unit names for devices needed
Model DSCBs
SYSOUT classes
SYSOUT DEST values
MVS subsystem names
System Operations and NCF

This article explains key tasks regarding system operations and NCF. The only recurring initialization
task that is required of the user after the system is installed is to verify that VTAM is active before
starting.
NCF Initialization (see page 189)

Establish Communications (see page 190)
Standard Operations (see page 190)
NCF Initialization
All other initialization is performed automatically to include the following items:
Loading the node table (UCC7NODE)
Creation of control blocks
Scanning files
If you want to scratch and reallocate NCF data sets for any reason, reinitialize them before the
execution of NCF.
08-Feb-2018 189/722
Note: For more information about the programs that are provided to satisfy this
requirement, see VTAM and NCF Node Table Definitions (https://wiki.ca.com/display/CWAC7E
/VTAM+and+NCF+Node+Table+Definitions).
Establish Communications
When the system is started, it automatically establishes communications with VTAM. Next, the
system attempts to log in to all nodes in its table.
If any nodes are not active, they cannot log in. However, when those nodes do become active, they
automatically attempt to log in.
More information:
LOGON Command (https://wiki.ca.com/pages/viewpage.action?pageId=134845021)
Standard Operations
The following topics discuss standard operations.
Status Information
The STATUS command provides information about the nodes in the system, including nodes specified
in the node table and any unknown nodes encountered during processing. The display indicates
whether they are active or inactive and displays activity counts. Status can be displayed for one node
or all of the nodes.
More information:
STATUS Command (https://wiki.ca.com/pages/viewpage.action?pageId=134844988)
Error Recovery
Data for nodes with which NCF cannot communicate, or which are not in the UCC7NODE table, is put
in the undeliverable queue (UDQ). Data for these unknown nodes remains on the UDQ until
communication can be established or until the data is purged using the PURGE command. If
communication is not established with that node soon, consider purging its data to prevent filling up
the UDQ.
More information:
PURGE Command (https://wiki.ca.com/pages/viewpage.action?pageId=134844987)
08-Feb-2018 190/722
PURGE Command (https://wiki.ca.com/pages/viewpage.action?pageId=134844987)
Termination
The normal method of terminating NCF is to issue the SHUTDOWN command followed by the STOP
command. This process lets all pending processes complete and provides an orderly termination.
By using only the STOP command, pending processes are cut off and the job terminates. Data cannot
be lost using this method because the data set pointers are not updated until a positive response has
been received. However, duplicate data can be sent because the data is sometimes successfully
received before the positive response was issued.
More information:
STOP Command (https://wiki.ca.com/pages/viewpage.action?pageId=134845024)
SHUTDOWN Command (https://wiki.ca.com/pages/viewpage.action?pageId=134845023)
NCF Operator Commands

The NCF operator commands let the user:
Initiate and terminate communication with another node
Reestablish communication after a shutdown
Display node status information
Purge data from the undeliverable queue
Terminate the NCF VTAM application
All commands to the NCF application are done using the MVS MODIFY command except for the MVS
STOP command. The other commands that are discussed in this topic require that a MODIFY
taskname precede the command text. See the following format:
MODIFY taskname,command [operand]
The short form of the MODIFY command, F, can be used interchangeably with MODIFY.
The maximum acceptable length for the command [operand] is 36 characters.
Any command that is not syntactically and logically correct is rejected with the message:
CA-7.NC101 UNKNOWN COMMAND IGNORED
Deactivate the Trace Facility (see page 192)

LOGOFF Command (see page 192)
LOGON Command (see page 192)
08-Feb-2018 191/722
LOGON Command (see page 192)

PURGE Command (see page 193)
SHUTDOWN Command (see page 193)
STARTUP Command (see page 194)
STATUS Command (see page 194)
STOP Command (see page 196)
TRACE Command (see page 196)
Deactivate the Trace Facility

To deactivate the previously activated trace facility, the following command is used:
MODIFY jobname,TRACE=OFF
jobname
Specifies the same meaning as in the previous TRACE command entered to activate the tracing
facility.
LOGOFF Command
The LOGOFF command marks the node specified to log off. Once that node has completed any
pending processes, the LOGOFF command is executed, communications are terminated and all future
data goes to the undeliverable queue until the node is again logged on. This command can be issued
at any node.

MODIFY jobname,LOGOFF nodename
jobname
Defines the OS job or task name of the NCF VTAM application.
nodename
Defines the node specified to log off.
LOGOFF Command Response

Upon successful completion of this command, the following message is issued:
CA-7.N303 LOGOFF REQUEST COMPLETE FOR NODE=xxxxxxxx
LOGON Command
The LOGON command attempts to establish communications with the node specified. This attempt is
done after that node has been logged off. Once the link has been established, any undeliverable data
in the UDQ is sent.

MODIFY jobname,LOGON nodename
jobname
08-Feb-2018 192/722
nodename
Defines the node with which communication is being established.
LOGON Command Response

Upon successful completion of this command, the following message is issued:
CA-7.NC302 SESSION ESTABLISHED WITH NODE (xxxxxxxx)
PURGE Command
The PURGE command deletes all the records from the undeliverable queue for the node specified in
the command. The entire undeliverable queue must be read. Processing of the communications data
set is suspended until this task is completed. Multiple nodes can be purged only by entering multiple
commands.

MODIFY jobname,PURGE nodename
jobname
nodename
Defines the node to be purged.
PURGE Command Response

A message is not issued when the purge is complete. To verify that the purge completed, issue a
STATUS command.
Note: Because UDQ processing must be serialized to verify chronological integrity of the
SMF data, a PURGE command can require several minutes to complete depending on the
volume of records.
This command deletes records that CA Workload Automation CA 7® Edition uses for tracking jobs.
This process can result in some jobs staying in the ready or active queues.
SHUTDOWN Command
The SHUTDOWN command posts all node processors to complete their pending processes and logs
off. The command terminates communication with VTAM by closing the ACB and freeing all control
blocks. The only valid commands after a SHUTDOWN are STARTUP or STOP. The SHUTDOWN
command also issues a STATUS command.

MODIFY jobname,SHUTDOWN
jobname
Defines the OS job or task name of the NCF VTAM application to terminate.
08-Feb-2018 193/722
SHUTDOWN Command Response

Upon successful completion of the command, the following message is issued:
CA-7.NC105 SHUTDOWN COMPLETE
A STATUS command, issued by the SHUTDOWN command, displays the status of the nodes.
STARTUP Command
The STARTUP command, after a SHUTDOWN command, reestablishes communications. The
command rebuilds all control blocks, opens the ACB, and logs on all nodes.

MODIFY jobname,STARTUP
jobname
Defines the OS job or task name of the NCF VTAM application to be attached.
STARTUP Command Response

The following message appears for each node (xxxxxxxx) that was logged on successfully:
CA-7.NC302 SESSION ESTABLISHED WITH NODE (xxxxxxxx)
STATUS Command
The STATUS command displays the status of a single node or all nodes. The nodes displayed are those
in the UCC7NODE table plus any unknown nodes that were encountered during processing. The
percentage of blocks that are used in both the NCF communications data set and undeliverable
queue is also displayed. Record counts reflect the volume of data because the last STARTUP.
This command has the following formats:
To display the status of all nodes:

MODIFY jobname,STATUS
jobname
To display the status of a single node:

MODIFY jobname,STATUS nodename
nodename
Defines the single node for which status is to display.
STATUS Command Response

Following is an example of a display for the STATUS command.
--------------------- CA-7/NCF VTAM STATUS ---------------
--NODE-- (ID) -STATUS- -LUTYP- -RECV- -SENT- -UNDL- -PURG-
ADL0101 (02) INACTIVE 000057 000057 000000 000000
ACH0201 (03) ACTIVE PLU 000485 000485 000000 000000
nodename (04) UNKNOWN 000000 000000 000000 000000
08-Feb-2018 194/722
ACH0201 (03) ACTIVE PLU 000485 000485 000000 000000
nodename (04) UNKNOWN 000000 000000 000000 000000
NCF QUEUE 041% USED UND QUEUE 023% USED
This panel contains the following fields:
NODE
Specifies the VTAM APPL ACBNAME of the node whose status information is displayed. Each
unknown node name is printed on a separate line.
ID
Specifies the node ID in hexadecimal.
STATUS
Specifies the status of each node:
ACTIVE
Indicates that communication is established with this node.
INACTIVE
Indicates that communication is not established with this node.
UNKNOWN
Indicates that this node is not in the UCC7NODE table, but data was received and is either
being held on the undeliverable queue or was purged.
LUTYP
Specifies either a primary logical unit (PLU) or secondary logical unit (SLU) when a node is active.
The node that initiated the communications link is the PLU.
RECV
Specifies the number of blocks received from the node specified.
SENT
Specifies the number of blocks sent to the specified node.
UNDL
Specifies the number of blocks on the undeliverable queue (UDQ) that contain data for this node.
The physical blocks on the UDQ can contain data for multiple nodes. Therefore, the total of the
UNDL counts on the STATUS command does not necessarily correlate to the physical blocks used
on the UDQ.
PURG
Specifies the number of blocks on the UDQ that contained data for the node that was purged.
NCF QUEUE
Specifies the percentage of blocks that are used in the NCF communications data set compared to
total blocks available.
UND QUEUE
Specifies the percentage of blocks used in the UDQ compared to total blocks available. When the
UND QUEUE % USED first exceeds 80 percent, 85 percent, and 90 percent, a warning message is
issued. The warning message is issued every time that a block is added while it exceeds 95
percent.
08-Feb-2018 195/722
STOP Command
The STOP command immediately detaches the subtask and terminates the NCF job. Issue a
SHUTDOWN command before a STOP command to complete all pending processes.

STOP jobname
jobname
Defines the OS job or task name of the NCF VTAM application to terminate.
STOP Command Response

Upon successful completion of the command, the following message is issued:
IEF404I jobname - ENDED - TIME = hh.mm (http://hh.mm).ss
TRACE Command
As a debugging aid, the TRACE command is used to activate or deactivate the NCF tracing facility. This
facility can provide SNAP dumps or WTOs to help with isolating problems.
Note: Due to the extreme volumes of WTO and SNAP output produced, use this facility
only when requested by CA Support for problem resolution.

MODIFY jobname,TRACE={SNAP|n|(n,mm,mm,...,mm)}
jobname
Defines the OS job or task name of the VTAM subtask.
TRACE={SNAP|n|(n,mm,mm,...,mm)}
Activates the trace facility.
SNAP
Indicates to take SNAP dumps.
n
Indicates the level number of WTOs desired. When coded by itself, all modules produce
WTOs. Level numbers (n) for WTOs are 1, 4, and 7 and are the only valid values for WTOs.
Level 1 provides the most general WTOs. Levels 4 and 7 provide progressively more detailed
WTOs. Level 7 provides the most detailed WTOs. A special level number of 127 can be used to
request PCB SNAP dumps each time a PCB is dispatched. A PCB (Program Control Block) is an
NCF internal data area used in controlling all processing.
08-Feb-2018 196/722
(n,mm,mm,...,mm)
Indicates that you want only the specified level of WTOs (n) from the modules specified as mm
in the list. The parentheses must be coded as shown. The specification for n is the same as
previously indicated. As an example, (7,01,03,04) indicates that the most detailed WTOs are
desired from modules SASSNC01, SASSNC03, and SASSNC04. Leading zeros are not required.
Cross-Platform Scheduling
A CA scheduling solution can request that work is run on its behalf by another CA scheduling solution
on a different operating environment. For example, CA Workload Automation AE on a UNIX operating
environment can request that CA Workload Automation CA 7® Edition schedule MVS jobs on its
behalf.
The following CA scheduling solutions can participate in cross-platform scheduling:
CA Workload Automation CA 7 Edition
CA Workload Automation AE
CA WA Agents
CA Jobtrac™
CA Scheduler®
CA NSM
CA UJMA
With CA Workload Automation Agents, CA Workload Automation CA 7 Edition communicates across

the platforms using TCP/IP connections. These CA Workload Automation Agents operate on various
platforms and support various application interfaces.
These topics refer to the CA scheduling solution requesting work (such as an MVS job or UNIX script)
as the XPS CLIENT. The XPS SERVER is the CA scheduling solution controlling execution of the work
that the XPS CLIENT requested. In the previous example, CA Workload Automation AE is the XPS
CLIENT and CA Workload Automation CA 7 Edition is the XPS SERVER.
The workload can be thought of as primarily under the control of the XPS CLIENT. The XPS CLIENT
requests work and monitors status for purposes of workload control (evaluating requirements,
triggering other work). The XPS SERVER only acts to initiate work and to communicate status
information about the work to the XPS CLIENT.
CA Workload Automation CA 7 Edition can act as the XPS CLIENT by requesting work on other
platforms. CA Workload Automation CA 7 Edition can also act as the XPS SERVER by submitting and
tracking work in response to requests from XPS CLIENTs.
08-Feb-2018 197/722
These topics discuss the requirements that let CA Workload Automation CA 7 Edition participate in
the cross-platform scheduling environment. All forms of cross-platform scheduling require
communications between systems using CA Common Communication Interface (CAICCI). Other
requirements necessary for CA Workload Automation CA 7 Edition to run as an XPS CLIENT are
distinct from those requirements that CA Workload Automation CA 7 Edition requires to act as an XPS
SERVER. For this reason, the information about CA Workload Automation CA 7 Edition and cross-
platform scheduling follows in two topics: the XPS CLIENT and the XPS SERVER.
CAICCI Cross-Platform Connections

CAICCI (CA Common Communications Interface) must connect the MVS system and the system
running the other scheduler or agent. Specifically, Cross-Platform Scheduling uses the TCP/IP
Gateway protocol of CAICCI. The connection can be defined on the MVS side, the non-MVS side, or
on both.
Ideally, the connection definitions are made on the system with the fewest number of connections,
the system that is recycled most often, or both. A typical site probably has a few MVS systems that
are active most of the time and many non-MVS systems, some of which are shut down frequently. In
this case, it makes sense to make the CAICCI connection definitions on the non-MVS system.
MVS CAICCI Connections (see page 198)

Non-MVS CAICCI Connections (see page 199)
MVS CAICCI Connections

CAICCI protocol and connection definitions on MVS reside in the CAICCI parameters, which are
pointed to by the CAIENF started task.
A TCP/IP Gateway PROTOCOL statement is required for any CAICCI cross-platform scheduling
communication. This statement is necessary even when the individual node connections are defined
on the non-MVS platforms. The types of TCP/IP Gateway protocols are TCPIPGW, TCPIP3GW, and
TCPIPSGW.
Note: For more information about these protocols, see the CAICCI User documentation (
https://docops.ca.com/ca-common-services-for-z-os/14-1/en).
Each remote connection definition requires both a NODE and CONNECT statement.
NODE(TCPIPGW,ip-address:port,retry,cciname)
CONNECT(cciname)
Make TCPIPGW match the type of gateway specified on your PROTOCOL statement (TCPIPGW,
TCPIP3GW, or TCPIPSGW).
ip-address
Either the numerical TCP/IP address of the node or a name that can be resolved into a TCP/IP
address. A TSO PING command on this value should be successful.
port
08-Feb-2018 198/722
port
Specifies the TCP/IP port number in use at the specified node.
retry
Specifies the number of minutes between attempts to establish or reestablish the connection.
cciname
Name that CAICCI uses for this node. This value is not always the same as the IP address. The
name must match the CAICCI name defined at the remote node (or the ALIAS= if specified). On
MVS, the node name is not case-sensitive.
The NODE and CONNECT statements can also be issued from a console by prefixing the command
with "ENF'. For example:
ENF CONNECT(NODEX)
Non-MVS CAICCI Connections

CAICCI connections are defined in the following files, depending on the operating environment:
Operating Product File

environment
UNIX CA NSM or $caiglbl0000/cci/config/<machine-name>/ccirmtd.prf where <machine-
Agent name> is the CAICCI name of the machine.
Windows CA NSM \TNG\CAIUSER\CCIRMTD.RC
Windows Agent \CA\CAIUSER\CCIRMTD.RC
The format of the CCIRMTD file is the same on all non-MVS platforms. The first line must be a LOCAL
statement, and any number of REMOTE statements can follow.
LOCAL = ip-address cciname blocksize [STARTUP] [PORT=nnnn] [ALIAS=xxxxxxxx]
REMOTE = ip-address cciname blocksize [STARTUP] [PORT=nnnn] [RETRY=n]
ip-address
Either the numerical TCP/IP address of the node, or a name that can be resolved into a TCP/IP
address. A TCP/IP PING command on this value should be successful.
cciname
Name that CAICCI uses for this node. This value is not always the same as the IP address. The
name must match the CAICCI name defined at the remote node. For MVS, the SYSID parameter in
the CAICCI parameters defines the CAICCI name.
blocksize
Size of the buffer returned to the client. Make the value 32768.
STARTUP
If STARTUP is specified, the connection is attempted when CAICCI starts. We recommend this
keyword.
08-Feb-2018 199/722
PORT
Specifies the TCP/IP port number to use. The default is 1721, which is the default port for CA NSM
and agent. The default port on MVS is 7000 and can be changed on the PROTOCOL(TCPIPGW....)
statement.
ALIAS
Only valid on the LOCAL statement. If cciname is longer than eight characters, use a one- to eight-
character alias to accommodate CAICCI on MVS systems. Other CAICCI systems see the local
system by this alias name.
RETRY
Only valid on the REMOTE statement. If the connection cannot be made or is broken, CAICCI
retries the connection every n minutes.
CAICCI must be restarted to pick up changes to the CCIRMTD file.
The XPS CLIENT

The XPS CLIENT for CA Workload Automation CA 7® Edition sends scheduling requests to a CA
scheduling solution (XPS SERVER) that can be running on a remote operating environment. The XPS
CLIENT receives status feedback (job initiation and job termination information) from the XPS
SERVER.
The XPS CLIENT for CA Workload Automation CA 7 Edition performs two functions: submission and
tracking. Jobs can be submitted to a remote operating environment directly (XPJOB definitions) or by
using the batch program CA7TOUNI. The CA Workload Automation CA 7 Edition Cross-Platform
Tracking System (XTRK) provides the tracking function.
Batch Submit Function (see page 200)
Direct Submit Function (see page 200)
Cross-Platform Tracking (see page 203)
Cross-Platform Tracking Notes and Examples (see page 212)
Batch Submit Function

The CA7TOUNI Batch Program (https://wiki.ca.com/display/CWAC7E/CA7TOUNI+Batch+Program) can also
send jobs to a remote platform. This process was the initial method CA Workload Automation CA 7®
Edition used to schedule jobs on a remote platform and is still supported. Sites wanting to use
variable substitution for the node name or wanting a protected data set for password information
should continue to use the batch CA7TOUNI program. Sites that do not have a CAICCI connection on
the operating system where CA Workload Automation CA 7 Edition runs should also use CA7TOUNI
because it lets them route the job for execution on an operating system with a CAICCI connection.
Direct Submit Function

This article explains the direct submit function and its parameters.
08-Feb-2018 200/722
When CA Workload Automation CA 7® Edition detects a job to submit for execution, CA Workload
Automation CA 7 Edition reads the database and determines the type of job. If the job is an internal
cross-platform job (XPJOB), CA Workload Automation CA 7 Edition builds a request containing the
information that is required to run the job on the remote platform. The remote platform location, or
node, is extracted from the XPJOB definition. After all requirements are met, CA Workload
Automation CA 7 Edition sends this information to the remote platform using CA Common Services
CAICCI.
No JCL is associated with XPJOB definitions. No separate batch job builds and sends the scheduling
request to the remote platform. The job is validated against rules relevant for XPJOBs as opposed to
regular CPU jobs (for example, a JOB statement is not required). All the CA Workload Automation CA
7 Edition features that are applicable to regular jobs (triggering, scheduling, prose, and so on) are
applicable for XPJOBs. XPJOBs flow through the CA Workload Automation CA 7 Edition queues the
same as regular CPU jobs. A CPU indication of XPJ distinguishes it from a regular CPU job.
XPJOB definitions provide many benefits when compared to using the batch program CA7TOUNI.
The XPJOB function makes it simpler for users not familiar with z/OS JCL to schedule cross-
platform jobs.
XPJOB definitions provide a method to secure sensitive data. Typically, CA7TOUNI parameters are
coded in-stream with the job's JCL, making user IDs, passwords, or both visible in JES displays.
Optionally, this information can be placed in yet another data set that the JCL must reference.
With XPJOB definitions, the sensitive data does not appear in JES displays and can be stored in the
CA Workload Automation CA 7 Edition database, an indirect location, or in the job definition's
parameter library. Access to this data can be protected using the CA Workload Automation CA 7
Edition external security interface.
XPJOB definitions improve system resource use by eliminating the need to run a z/OS job for
every cross-platform job. This efficiency reduces or eliminates the overhead and runtime
problems that users often face when dealing with batch jobs. More batch initiators are not
required. XPJOBs jobs are not subject to JCL errors, extraneous resource conflicts, or processor
delays that are often found with batch jobs.
Because transmission of the XPJOB request is handled entirely within the CA Workload
Automation CA 7 Edition address space, more effective control of the job submission process
occurs at program level. If an alternative remote node is defined for the primary remote platform
node, and the primary remote platform node is not currently active, CA Workload Automation CA
7 Edition can reroute the XPJOB information to the alternate node. Also, with direct connections
to the remote nodes, a user can request a job cancellation, assuming the cross-platform agent
supports such a request.
CA Workload Automation CA 7 Edition relies on SMF data for posting batch job information. Using
an internal interface to communicate to the cross-platform agent eliminates the SMF tracking
overhead, delays, and ambiguities. The cross-platform jobs are submitted for execution through a
separate subtask directly to CA Common Services CAICCI. For this reason, the normal batch job
throughput through a JES internal reader is eliminated.
Sites can convert their CA7TOUNI jobs to XPJOB definitions using the CA7TOUNI Conversion Utility (
https://wiki.ca.com/display/CWAC7E/CA7TOUNI+Conversion+Utility).
08-Feb-2018 201/722
Direct Submit Function Parameters

Parameter data, previously contained in z/OS JCL (when using batch program CA7TOUNI), is now
located in a parameter library. The library is identified in the XPJOB definition. Two of the CA7TOUNI
required parameters, XPNODE and XPEXEC, are now part of the XPJOB definition.
The following describes all the parameters that are valid for XPJOB definitions:
DOMAIN
(Optional) Defines a domain name and can be required for some requests sent to Windows
platforms.
Source: Optional parameter library or associated to a node/owner access definition (for more
information, see XPSWD).
LINELEN
(Optional) Controls the line length of the SYSIN input for the SUBFILE and PARM xx keyword
parameters. Normal XPJOB submission processing automatically determines whether columns 73
through 80 contain line sequence numbers (LINELEN=AUTO). If column 72 contains a blank, null,
or plus sign, and columns 73 through 80 are numeric, columns 73 through 80 are considered to be
line sequence numbers. Line sequence numbers are not considered part of the PARMxx keyword
value.
The LINELEN keyword can override this automatic determination. LINELEN forces XPJOB
submission processing to consider the full 80-byte record as part of the data area (LINELEN=80).
Or it can force XPJOB submission processing to ignore columns 73 through 80 (LINELEN=72)
regardless of the contents of those columns.
Default: LINELEN=AUTO
Limits: AUTO, 72, and 80 are the only allowed values
Source: Optional parameter library
Note: This keyword can be specified multiple times. The last valid LINELEN specification
processed before the current line controls processing for PARMxx keywords.
PARM1 thru PARM64

(Optional) Supply values to use on the target platform. Values can be 1 through 256 characters.
Avoid special characters because they do not always translate correctly on the target platform.
Embedded blanks cause the XPS SERVER on the target platform to enclose the value in double
quotes. Because the parameter library is limited to 80 characters, continuation can be required.
To continue a record, end it with a plus sign (+) and continue in column 1 of the next statement.
The ending plus sign does not appear in the resulting value. Keyword checking is suspended
during a continuation operation.
Source: Optional parameter library. If only one parameter is needed (and it is 128 characters or
less), it can be specified in the XP PARM field on the XPJOB definition.
Note: The contents of columns 73 through 80 can be included or excluded based on the
processing controls currently in effect. Typically, line sequence numbers in columns 73
through 80 are ignored. For more information, see the preceding LINELEN parameter.
08-Feb-2018 202/722
SUBPASS
(Optional) Identifies the password to pass with SUBUSER to the target platform. The password is
sent to the target system in an encrypted format. Some target systems require that a password
accompanies the SUBUSER on cross-platform requests.
Note: XPJOB definitions provide a number of more secure alternatives to using SUBPASS
and SUBUSER. Review the OWNER parameter in the XPJOB definition and the XPSWD
command. The XPDEF statement discusses the hierarchy of cross-platform job submission
user ID and password processing.
SUBUSER
(Optional) Identifies the user ID for security purposes on the target platform.
Note: XPJOB definitions provide a number of more secure alternatives to using SUBPASS
and SUBUSER. Review the OWNER parameter in the XPJOB definition and the XPSWD
command. The XPDEF statement discusses the hierarchy of cross-platform job submission
user ID and password processing.
Additional parameters that are valid for CA7TOUNI jobs are either not applicable for XPJOBs (for
example, JOBNO, JOBSET, SUBCHECK, 7TRACE), or handled differently. MONITOR information is now
extracted from the XMONITOR keyword of the XPDEF file initialization statement. Sites wanting to
use the equivalent of SUBROOT must do the following:
Set the SUBROOT keyword of the XPDEF file initialization statement to Y.
Associate the ROOT user ID to an Owner or Node using the XPSWD command.
Lastly, SUTYPE is now a field in the XPJOB definition.
Cross-Platform Tracking
Cross-platform tracking consists of the XPS SERVER returning feedback records for CA Workload
Automation CA 7® Edition submitted jobs to the system that sent the request. These records are
transmitted using CA Common Services CAICCI and represent job initiation, job termination, and job
failure events.
The CA Workload Automation CA 7 Edition Cross Platform Tracking System (XTRK), running on the
MVS system where the CA Workload Automation CA 7 Edition cross-platform job submission
occurred, receives these events. XTRK converts them to SMF-like feedback recognized by CA
Workload Automation CA 7 Edition. The product then processes this information like any other job to
determine when it becomes active, completes, or fails. Have one copy of XTRK per CA Workload
Automation CA 7 Edition instance executing on each system where CA Workload Automation CA 7
Edition cross-platform jobs can be submitted.
08-Feb-2018 203/722
XTRK can be run in any of the following ways:
Started task/batch job
Subtask under ICOM
Subtask under the product (recommended)
Running XTRK as a subtask under CA Workload Automation CA 7 Edition is the recommended

execution method. This method is required for tracking XPJOB defined jobs submitted directly from
CA Workload Automation CA 7 Edition. XTRK also tracks jobs submitted using CA7TOUNI. Sites not
planning to allow XPJOB definitions can run XTRK as a started task, batch job, or subtask under ICOM.
Sites wanting to take advantage of the XTRK High Availability Option (HAO) must run XTRK as a
subtask under CA Workload Automation CA 7 Edition. HAO allows a backup (or failover) system of CA
Workload Automation CA 7 Edition to continue tracking cross-platform jobs (XPJOB job type)
submitted by the downed CA Workload Automation CA 7 Edition system. CAICCI reroutes the tracking
information to that CA Workload Automation CA 7 Edition system so that XPJOB posting continues to
occur when one of the following is true:
A site has a dormant copy of CA Workload Automation CA 7 Edition.
A site starts CA Workload Automation CA 7 Edition on another system, with the same primary
name as the original CA Workload Automation CA 7 Edition system.
Also, you can track events like job execution and file creation/update that occur on non-MVS
platforms. You can track these events even though CA Workload Automation CA 7 Edition did not
request that work (Cross-Platform External Tracking). A CA scheduler or agent must be executing at
the remote node for this tracking to occur.
More information:
XTRK as an STC or Job (https://wiki.ca.com/display/CWAC7E/XTRK+as+an+STC+or+Job)
XTRK Under ICOM (https://wiki.ca.com/display/CWAC7E/XTRK+Under+ICOM)
Cross-Platform Tracking Under the Started Task

You can execute XTRK as a subtask under CA Workload Automation CA 7 Edition.
Follow these steps:
1. Define CAICCI connections among systems. For more information, see CAICCI Cross-Platform
Connections.
These CAICCI connections are the same regardless of which side is acting as the XPS CLIENT or
XPS SERVER.
Note: This interface requires CA Common Services for z/OS.
08-Feb-2018 204/722
2. Update the CA Workload Automation CA 7 Edition started task JCL to include the following JCL
DD statement:
//XCKPT DD DISP=OLD,DSN=xtrkcheckpoint
The XCKPT DD points to the CA Workload Automation CA 7 Edition Cross-Platform Checkpoint

file. Each XTRK copy must have its own Checkpoint file. The DCB parameters for the
Checkpoint files are:
DSORG=PS,RECFM=FB,LRECL=4096,BLKSIZE=4096
CA Workload Automation CA 7 Edition JCLLIB member CA07N010 (prefix may have changed
based on the SYSGEN) allocates a checkpoint file that can be used for the XCKPT DD
statement. Optionally, sites can use an existing XTRK checkpoint data set that is currently
used in an XTRK started task, batch job, or ICOM JCL stream. This option assumes sites are
converting to run XTRK as a subtask under CA Workload Automation CA 7 Edition.
//XPRINT DD SYSOUT=*
The XPRINT DD specifies the SYSOUT class for XTRK trace messages. The first value of the
XTRKTRC keyword of the XPDEF initialization file statement controls the type and volume of
messages.
//XSNAP DD SYSOUT=*
The XSNAP DD specifies the SYSOUT class for XTRK storage snap output. The second value of
the XTRKTRC keyword of the XPDEF initialization file statement controls the type and volume
of output.
//XEVENTS DD DISP=SHR,DSN=xtrk..xtracking(rules) ***optional***
The XEVENTS DD is optional.
Note: For more information about the XEVENTS DD statement, see CA 7 Cross-
Platform External Tracking (https://wiki.ca.com/display/CWAC7E/Cross-
Platform+Tracking#Cross-PlatformTracking-CA7Cross-PlatformTrackingCommands).
3. Update the CA Workload Automation CA 7 Edition started task initialization file tracking
tracing statement if needed.
XTRKTRC=21
XTRK is automatically enabled when an XCKPT DD statement is found in the CA Workload
Automation CA 7 Edition online started task.
4. Recycle the CA Workload Automation CA 7 Edition started task. Look for the CAL2X101I -
CAL2X103I messages (in the JOBLOG) showing the status of the cross-platform tracking
subtask under CA Workload Automation CA 7 Edition.
5. Define CA Workload Automation CA 7 Edition cross-platform jobs using the XPJOB definition
function.
6. Schedule/Demand the XPJOB definition on CA Workload Automation CA 7 Edition.
08-Feb-2018 205/722
6. Schedule/Demand the XPJOB definition on CA Workload Automation CA 7 Edition.
Configure the High Availability Option (HAO) of XTRK

Sites can use HAO by assigning a value to the XPDEF file initialization statement XPHAO keyword. The
XPHAO value must be unique across the enterprise. If two or more copies of CA Workload
Automation CA 7 Edition have the same XPHAO value, it cannot be determined which copy receives
the cross-platform job feedback.
Cross-platform failover is automatically handled if the primary copy of CA Workload Automation CA 7

Edition fails when the following points are true:
The XPHAO value is set.
A secondary dormant copy of CA Workload Automation CA 7 Edition is active.
Sites can also shut down CA Workload Automation CA 7 Edition and resubmit the same CA Workload
Automation CA 7 Edition started task on a different LPAR. Provided the XPHAO keyword has not
changed, cross-platform tracking information is routed to the new copy of CA Workload Automation
CA 7 Edition when it is active.
Important! If you chose to activate HAO, do so when no XPJOB cross-platform jobs are
active. Failure to do so could result in cross-platform tracking information not being
returned to the originating copy of CA Workload Automation CA 7 Edition.
CA 7 Cross-Platform Tracking Commands

Sites running XTRK as a subtask under CA Workload Automation CA 7 Edition can use the /XTASK
command to display its status or add/update information. XTRK running as a batch job, started task,
or subtask under ICOM accepts MODIFY or STOP operator commands. The following list details the
available parameters:
ADDNODE(nnnnnnn)
Adds a CAICCI node (nnnnnnnn) to the XTRK Node Table. XTRK attempts to establish
communications with that node.
BLDXEVT
Rebuilds the Cross-Platform External Tracking table from the rules defined in the XEVENTS DD. If
the rebuild is successful, XTRK attempts to resynchronize with each remote node to pass the new
set of external tracking rules.
DELNODE(nnnnnnn)
Deletes a CAICCI node (nnnnnnnn) from the XTRK Node Table. XTRK no longer attempts to
communicate with that node.
NODE[(nnnnnnnn),status]
Lists nodes from the XTRK Node Table indicating the status, last activity and checkpoint dates and
times. The default is to list all nodes. A full or partially qualified argument can be specified to limit
the display. For example: NODE(AIX*). See messages CAL2X155I and CAL2X156I. In addition to a
node argument, a status argument can be specified to limit the display to nodes that have a
08-Feb-2018 206/722
node argument, a status argument can be specified to limit the display to nodes that have a
particular connection status. The status keywords match the status displayed in the CAL2X156I
message (ACTIVE, LOSTCONN, SYNCH, NO CONTACT, DELETED), plus a special keyword, INACT.
INACT selects nodes that are not active (for any reason). For example, NODE(AIX*),INACT. Or,
NODE,ACTIVE.
NODEN[(nnnnnnnn),status]
Lists nodes from the XTRK Node Table indicating the CAICCI node name and the remote node
name. This display can be useful if you are using CAICCI Alias names. The default is to list all
nodes. A full or partially qualified argument of the CAICCI node name can be specified to limit the
display. For example: NODEN(AIX*). See message CAL2X154I. In addition to a node argument, a
status argument can be specified to limit the display to nodes that have a particular connection
status. (See the previous NODE command).
NODEX[(nnnnnnnn),status]
Lists nodes from the XTRK Node Table indicating the status, last activity and checkpoint dates and
times, and the internal status flags. The default is to list all nodes. A full or partially qualified
argument can be specified to limit the display. For example: NODEX(AIX*). See messages
CAL2X155I and CAL2X156I. In addition to a node argument, a status argument can be specified to
limit the display to nodes that have a particular connection status. (See the previous NODE
command).
PING
Forces the XTRK Tracking Manager to send a CAICCI record to each node in the XTRK Node Table
to confirm a connection, or attempt to initiate a connection. Typically this process is done on a
timer basis.
SNAP(..option..)
Forces the writing of a storage snap to the XSNAP DD (if available and open).
SVT
XTRK System Vector Table
TAB
XTRK Node Table Blocks
XEVT
XTRK External Event Table entries
ALL
All of the above
STOP
Causes XTRK to perform normal shutdown processing. This function can also be done using the
operator STOP command (P CA7XTRK).
TRC
Without any operands, the keyword causes a display of current XTRK trace settings (see message
CAL2X159I). With operands:
TRC(pc)
Resets the current trace code settings. For example: TRC(21) sets the print trace code to 2 and
the console trace code to 1. Both codes must be specified.
08-Feb-2018 207/722
TRC(OPEN,...)
Causes the opening of the PRINT or SNAP file
TRC(CLOSE,...)
Causes the closing of the PRINT or SNAP file.
TRC(RESET,...)
Causes the closing of the PRINT or SNAP and then opening.
XEVT
Lists rules from the XTRK External Tracking Event table. See messages CAL2X185I and CAL2X186I.
The default is to list all event rules. A full or partially qualified CAICCI node argument can be
specified to limit the display to only those rules that apply to that node argument. For example:
XEVT(AIX*).
The following are some examples that display the command syntax for XTRK running as a subtask
under CA Workload Automation CA 7 Edition, XTRK running as a batch job, and XTRK running under
ICOM. Command output is written to CA Workload Automation CA 7 Edition or to batch job JOBLOG.
This example adds a node.

CA Workload Automation SE Subtask - /XTASK,M=(CMD,TRACKER,ADDNODE(TESTNODE))
Batch Job - F jobname,ADDNODE(TESTNODE)
ICOM - F CA7ICOM,XTRK=ADDNODE(TESTNODE)
This example displays nodes.

CA Workload Automation SE Subtask - /XTASK,M=(CMD,TRACKER,NODE(TEST*),ACTIVE)
Batch Job - F jobname,NODE(TEST*),ACTIVE
ICOM - F CA7ICOM,XTRK=NODE(TEST*),ACTIVE
This example displays nodes.

CA Workload Automation SE Subtask - /XTASK,M=(CMD,TRACKER,NODEX)
Batch Job - F jobname,NODEX
ICOM - F CA7ICOM,XTRK=NODEX
This example pings nodes.

CA Workload Automation SE Subtask - /XTASK,M=(CMD,TRACKER,PING)
Batch Job - F jobname,PING
ICOM - F CA7ICOM,XTRK=PING
This example deletes nodes.

CA Workload Automation SE Subtask - /TASK,M=(CMD,TRACKER,DELNODE(TESTPLN))
Batch Job - F jobname,DELNODE(TESTPLN)
ICOM - F CA7ICOM,XTRK=DELNODE(TESTPLN)
This example changes trace settings.

CA Workload Automation SE Subtask - /TASK,M=(CMD,TRACKER,TRC(22))
Batch Job - F jobname,TRC(22)
ICOM - F CA7ICOM,XTRK=TRC(22)
08-Feb-2018 208/722
CA 7 Cross-Platform External Tracking

The CA Workload Automation CA 7 Edition Cross-Platform Tracker (XTRK) can request notification of
job events and file create/updates from a CA scheduler or agent. For tracking jobs, they must be
under the control of the CA scheduler or agent. However, the CA scheduler or agent can detect the
creation or update of files even if a task outside of their control does it.
When XTRK starts, it looks for an XEVENTS DD statement. If present, it points to an 80-byte
statement-image data set or PDS member that contains the event rules for CA Workload Automation
CA 7 Edition Cross-Platform External Tracking. When XTRK establishes communication with a remote
system, it passes to that system the rules that apply to it. When a matching job initiation,
termination, or file create/close occurs on that system, the feedback record for that event is sent to
XTRK using the same format as normal cross-platform work.
When XTRK receives this external feedback, it generates pseudo-SMF records for CA Workload
Automation CA 7 Edition that match the format of CA Workload Automation CA 7 Edition External
Tracking. The CA Workload Automation CA 7 Edition address space treats these pseudo-SMF records
in the same manner as other external tracking records.
For cross-platform external file creates/updates, SASSXDSN is not required. The following sample
shows the general syntax of an event definition in XEVENTS:
EVENT( -
NODE(cciname) -
TYPE(JOB|DSN|CONNECT) -
NAME(external job name or file name) -
JNO(nnnn) -
JOBSET(external jobset name) -
MVSNAME(mvs job or data set name) -
STAT(N|Y) -
)
The keywords within the EVENT( can be in any order. Not all keywords are meaningful for all types of
events. Unless otherwise specified, case does not matter. All data must be between columns 1 and
72. To continue lines at any point (inside or outside a keyword), end the line with " -" (a blank
followed by a dash). The line is continued with the first nonblank character on the next line. To code
comments, place an asterisk (*) in column 1.
NODE
The CAICCI node name at which the other CA scheduler or agent watches for this event. For TYPE
(CONNECT) it is the node name that XTRK always establishes contact with.
NODE is REQUIRED for all events.
NODE must be fully qualified for TYPE(CONNECT) events.
NODE can be fully qualified, partially qualified or fully generic for TYPE(JOB) or TYPE(DSN) events.
TYPE
Indicates the type of event. Valid values are JOB, DSN, or CONNECT. TYPE is required for all
events.
TYPE(JOB)
Indicates track matching job initiation and termination events.
TYPE(DSN)
Indicates track matching file creation/update events.
TYPE(CONNECT)
08-Feb-2018 209/722
TYPE(CONNECT)
Indicates that XTRK always attempts to establish contact with the CAICCI node specified in the
NODE( parameter.
NAME
For event TYPE(JOB), the name of the job to track as defined to the other CA scheduling system.
For event TYPE(DSN), the fully qualified name of the file to track, or in certain configurations
masking is allowed. The value of NAME is case-sensitive when used for a job name. The value is
sometimes case-sensitive when used as a file name, depending on the target platform.
NAME is REQUIRED for TYPE(JOB) and TYPE(DSN) events.
JNO
For event TYPE(JOB), the four-digit job number of the job to track as defined to CA NSM.
JNO is REQUIRED for TYPE(JOB) events. JNO is ignored for other types.
For CA Workload Automation AE, use a fixed value of 0001.
JOBSET
For event TYPE(JOB), the jobset name of the job to track as defined to CA NSM.
JOBSET is REQUIRED for TYPE(JOB) events. JOBSET is ignored for other types.
For CA Workload Automation AE, use a fixed value of XXXX.
MVSNAME
For event TYPE(JOB), the job name that conforms to MVS standards that CA Workload
Automation CA 7 Edition uses to track this job.
For event TYPE(DSN), the fully qualified data set name that conforms to MVS standards that CA
Workload Automation CA 7 Edition uses to track this file.
MVSNAME is REQUIRED for TYPE(JOB) and TYPE(DSN) events.
STAT
For EVENT(DSN), STAT indicates which method to use on UNIX machines to determine when the
file has been updated. STAT(N), the default, uses hooks in the UNIX kernel and is the fastest and
most reliable method. STAT(Y) uses a UNIX statistics utility to determine when the file has been
updated. For more information about these methods, see the documentation for the other CA
scheduler or agent.
STAT( is optional for EVENT(DSN) events and ignored for all other events.
To display the current external events, use the XTRK command XEVT.
To rebuild the table of external events, use the XTRK command BLDXEVT.
Cross-Platform Examples and Usage Notes
XEVENTS Example 1
When file c:\dir\myfile.txt is created or updated on node NTBOX1, XTRK tracks the creation/update
of data set name NTBOX1.MYFILE.TXT as a CA Workload Automation CA 7 Edition external data set.
EVENT( TYPE(DSN) -
NODE(NTBOX1) -
NAME(c:\dir\myfile.txt) -
MVSNAME(NTBOX1.MYFILE.TXT) )
XEVENTS Example 2
08-Feb-2018 210/722
The other CA scheduler or agent sends XTRK feedback when job 'payjob-on-unix', job number '0001'
in jobset 'payroll-jobset-on-unix' initiates and terminates at node UNIX01. XTRK tracks it as a CA
Workload Automation CA 7 Edition external job with the name UNIXPAY1.
EVENT( TYPE(JOB) -
NODE(UNIX01) -
NAME(payjob-on-unix) -
JNO(0001) -
JOBSET(payroll-jobset-on-unix) -
MVSNAME(UNIXPAY1) )
XEVENTS Example 3
Each CA scheduler or agent that XTRK connects with, whose CAICCI node name begins with the
characters 'AIX', is asked to send XTRK feedback when job 'aix-job1', job number '0001' in jobset 'aix-
jobset' initiates and terminates. XTRK tracks it as a CA Workload Automation CA 7 Edition external job
with the name AIXJOB1. This definition lets you set up one rule that captures tracking for this job
regardless of which AIX computer it runs on.
EVENT( TYPE(JOB) -
NODE(AIX*) -
NAME(aix-job1) -
JNO(0001) -
JOBSET(aix-jobset) -
MVSNAME(AIXJOB1) )
XEVENTS Example 4
These rules ensure that XTRK attempts to communicate with each of these systems (AIX001, AIX002,
AIX003). Typically, XTRK communication only occurs if CA Workload Automation CA 7 Edition submits
a cross-platform job to that remote system. If you simply want to listen for cross-platform external
tracking events at a node, the TYPE(CONNECT) rule esnures that XTRK attempts to establish
communication with that system.
EVENT( TYPE(CONNECT) NODE(AIX001) )
Cross-Platform Usage Notes

Duplicate External Events
If you are running CA Workload Automation CA 7 Edition Cross-Platform Tracking System (XTRK) on
more than one MVS image, do not use the same XEVENTS rules for both copies. If you do, each XTRK
could receive feedback for the same remote job or file event. Depending on the timing of XTRK,
ICOM, and CA Workload Automation CA 7 Edition processing, this situation could result in either of
the following outcomes:
Duplicate triggers (at worst).
Unnecessary overhead in the CA Workload Automation CA 7 Edition address space (at best).
We recommend having one copy of XTRK handle the Cross-Platform External Tracking for CA
Using TYPE(CONNECT) Event Rules
Typically the CA Workload Automation CA 7 Edition Cross-Platform Tracking System (XTRK) only
08-Feb-2018 211/722
communicates with those remote systems where CA Workload Automation CA 7 Edition Cross-
Platform jobs are submitted to. To use XTRK for remote systems that do not receive any CA Workload
Automation CA 7 Edition cross-platform work, define at least one XEVENTS rule that explicitly
references that node. If the only rules that apply to that node have generic NODE( parameters, use a
TYPE(CONNECT) rule to identify explicitly the node to XTRK.
SASSEXTT Model Queue Record Table Module
For CA Workload Automation CA 7 Edition to track external tasks (local or cross-platform), the Model
Queue Record Table module, SASSEXTT, must be available to the CA Workload Automation CA 7
Edition address space. The External Job/STC Filter Table module, SASSEXTL, is not required for cross-
platform external tracking.
Note: For more information about tracking external tasks, see External Tracking and
Filtering (https://wiki.ca.com/display/CWAC7E/External+Tracking+and+Filtering).
Cross-Platform Tracking Notes and Examples

This article details cross-platform tracking usage notes and examples.
XEVENTS Example 1 (see page 212)

Cross-Platform Usage Notes (see page 213)
XEVENTS Example 1
When file c:\dir\myfile.txt is created or updated on node NTBOX1, XTRK tracks the creation/update
of data set name NTBOX1.MYFILE.TXT as a CA Workload Automation CA 7 Edition external data set.
EVENT( TYPE(DSN) -
NODE(NTBOX1) -
NAME(c:\dir\myfile.txt) -
MVSNAME(NTBOX1.MYFILE.TXT) )
XEVENTS Example 2
The other CA scheduler or agent sends XTRK feedback when job 'payjob-on-unix', job number '0001'
in jobset 'payroll-jobset-on-unix' initiates and terminates at node UNIX01. XTRK tracks it as a CA
Workload Automation CA 7 Edition external job with the name UNIXPAY1.
EVENT( TYPE(JOB) -
NODE(UNIX01) -
NAME(payjob-on-unix) -
JNO(0001) -
JOBSET(payroll-jobset-on-unix) -
MVSNAME(UNIXPAY1) )
08-Feb-2018 212/722
XEVENTS Example 3
Each CA scheduler or agent that XTRK connects with, whose CAICCI node name begins with the
characters 'AIX', is asked to send XTRK feedback when job 'aix-job1', job number '0001' in jobset 'aix-
jobset' initiates and terminates. XTRK tracks it as a CA Workload Automation CA 7 Edition external job
with the name AIXJOB1. This definition lets you set up one rule that captures tracking for this job
regardless of which AIX computer it runs on.
EVENT( TYPE(JOB) -
NODE(AIX*) -
NAME(aix-job1) -
JNO(0001) -
JOBSET(aix-jobset) -
MVSNAME(AIXJOB1) )
XEVENTS Example 4
These rules ensure that XTRK attempts to communicate with each of these systems (AIX001, AIX002,
AIX003). Typically, XTRK communication only occurs if CA Workload Automation CA 7 Edition submits
a cross-platform job to that remote system. If you simply want to listen for cross-platform external
tracking events at a node, the TYPE(CONNECT) rule esnures that XTRK attempts to establish
communication with that system.
Cross-Platform Usage Notes

Duplicate External Events
If you are running CA Workload Automation CA 7 Edition Cross-Platform Tracking System (XTRK) on
more than one MVS image, do not use the same XEVENTS rules for both copies. If you do, each XTRK
could receive feedback for the same remote job or file event. Depending on the timing of XTRK,
ICOM, and CA Workload Automation CA 7 Edition processing, this situation could result in either of
the following outcomes:
Duplicate triggers (at worst).
Unnecessary overhead in the CA Workload Automation CA 7 Edition address space (at best).
We recommend having one copy of XTRK handle the Cross-Platform External Tracking for CA
Using TYPE(CONNECT) Event Rules
communicates with those remote systems where CA Workload Automation CA 7 Edition Cross-
Platform jobs are submitted to. To use XTRK for remote systems that do not receive any CA Workload
Automation CA 7 Edition cross-platform work, define at least one XEVENTS rule that explicitly
references that node. If the only rules that apply to that node have generic NODE( parameters, use a
TYPE(CONNECT) rule to identify explicitly the node to XTRK.
SASSEXTT Model Queue Record Table Module
08-Feb-2018 213/722
Queue Record Table module, SASSEXTT, must be available to the CA Workload Automation CA 7
Edition address space. The External Job/STC Filter Table module, SASSEXTL, is not required for cross-
platform external tracking.
Note: For more information about tracking external tasks, see External Tracking and
Filtering (https://wiki.ca.com/display/CWAC7E/External+Tracking+and+Filtering).
The XPS SERVER

The CA Workload Automation CA 7® Edition XPS SERVER receives scheduling requests from a CA
scheduling solution that can be running on a remote operating environment. The XPS SERVER
responds by servicing the requests (job submission), and returning appropriate feedback to the XPS
CLIENT. In this way, the XPS CLIENT is notified of job initiation and termination.
The XPS SERVER comprises two distinct functions: the XPS SUBMIT MONITOR and the XPS Router.
The programs that make up the XPS Router function that is typically run as subtasks in the CA
Workload Automation CA 7 Edition address space. Main task and subtask programs accomplish the
XPS SUBMIT MONITOR function.
The XPS SUBMIT MONITOR is the function that accomplishes the following:
Interprets the scheduling request from the XPS CLIENT.
Schedules the job in CA Workload Automation CA 7® Edition.
Sends status feedback to the XPS CLIENT through the XPS Router.
The XPS SUBMIT MONITOR is responsible for the following two activities:
Submitting of CA Workload Automation CA 7 Edition jobs.
Creating status information for the XPS CLIENT.
Submission
The XPS Router forwards a scheduling request from an XPS CLIENT to the XPS SUBMIT MONITOR
using CAICCI. The SUBMIT MONITOR builds a terminal command based on parameters provided in
the scheduling request or from options coded in the CA Workload Automation CA 7 Edition
initialization file. The SUBMIT MONITOR then uses an internal terminal to issue a command that
causes the job to be scheduled. The definition of an internal terminal is marked by the specification
of DEVICE=TRXDV. If CA Workload Automation CA 7 Edition is to be an XPS SERVER, at least one
internal terminal must be defined.
The value of the XPSSCHD keyword on the SVCNO and XPDEF statements in the CA Workload
Automation CA 7 Edition initialization file determines the scheduling command that is issued when a
cross-platform scheduling request is received.
The XPS SUBMIT MONITOR respects CA Workload Automation CA 7 Edition terminal security. A
08-Feb-2018 214/722
The XPS SUBMIT MONITOR respects CA Workload Automation CA 7 Edition terminal security. A
USERID is required for the logon to the internal terminal used for the scheduling request. This USERID
determines the security in effect for the request. If no USERID is supplied on the scheduling request
from the XPS CLIENT, the value of the XPSSID keyword on the SECURITY statement is used for the
logon to the internal terminal. If no USERID is supplied and if no value is coded for the XPSSID
keyword then the scheduling requests will fail.
If the default value for the XPSSCHD keyword is used, jobs that are requested by an XPS CLIENT
report an entry mode of XPS in the output of queue displays.
Jobs that another CA scheduling system requests must be defined on the CA Workload Automation
CA 7 Edition database before scheduling. If the job is not defined to CA Workload Automation CA 7
Edition, the scheduling request from the XPS CLIENT fails.
The command that the XPS SERVER uses to schedule the job is recorded in the CA Workload
Automation CA 7 Edition Log. If an XPS CLIENT scheduling request fails, the terminal command and
the CA Workload Automation CA 7 Edition error message can prove useful in problem determination.
More information:
Manage the Cross Platform Workload (https://wiki.ca.com/display/CWAC7E/Cross-

Platform+Server+Password+Requirements#Cross-PlatformServerPasswordRequirements-
ManagetheCross-PlatformWorkload)
Status Update
The XPS SUBMIT MONITOR function sends status information to the XPS CLIENT in the form of
CAIENF events. The CAIENF event that is used for this purpose is named 'CAXPSFBK'. CA Workload
Automation CA 7 Edition creates CAXPSFBK records to signal status changes such as job initiation, job
termination, and job failure. The XPS Router captures these CAIENF events and forwards them to the
XPS CLIENT.
Sometimes the command used to schedule the job fails for any reason (for example, /LOGON failure,
job not defined, and so on). In this case, CA Workload Automation CA 7 Edition creates a CAIENF
record reporting the failure to send to the XPS CLIENT.
A CAIENF record reporting job initiation is created when CA Workload Automation CA 7 Edition
receives the job initiation record from SMF.
The value of the XPSSCHD keyword on the SVCNO and XPDEF initialization file statements affect the
way job completion status updates are reported to the XPS CLIENT. If the default of
XPSSCHD=RUNREF is used, a CAIENF record for job completion is created immediately when the job
terminates. If XPSSCHD=DEMAND or XPSSCHD=RUN is coded, the job completion status update is not
reported until the job exits the request queue.
If a job requested by an XPS CLIENT is canceled in CA Workload Automation CA 7 Edition before job
submission, CA Workload Automation CA 7 Edition creates a CAIENF record indicating that the job
failed. If, however, the job has already run at least once, then a CAIENF record indicating job
termination is created.
08-Feb-2018 215/722
Note: Exercise care with jobs using XPSSCHD=RUNREF and CA Workload Automation CA 7
Edition step condition code checking (#SSC statements). If #SSC processing detects an error
situation, then the code returned to the requesting system is the return code detected by
#SSC processing. This code is not always the highest condition code produced by the job.
Cross-Platform Scheduling Router (XPS Router)

The cross-platform scheduling router (XPS Router) is the single point of communication on MVS
systems. To communicate with other CA scheduling solutions, each system must present a single
point of communication. A given MVS system can have more than one CA scheduling solution
executing. For example, there can be multiple instances of CA Workload Automation CA 7® Edition
executing on the same MVS image. The cross-platform scheduling router enables all instances of CA
Workload Automation CA 7 Edition to participate in cross-platform scheduling.
On MVS systems, the cross-platform scheduling router receives all requests for work from other
systems. The router then routes each request to the appropriate CA scheduling solution on that
system. The feedback information (job initiation, termination, failure) generated by the CA scheduling
solution is used to create CAIENF cross-platform feedback events (CAXPSFBK). The cross-platform
scheduling router intercepts these events and sends the feedback to the original requester. Logging
this information in CAIENF also prevents the loss of feedback data when communications problems
interrupt the links among platforms. When the link is reestablished, the cross-platform scheduling
router can retrieve the logged feedback events from CAIENF. The cross-platform scheduling router
sends them to the system that originated the request.
Cross-platform scheduling communication is performed by using the CA Common Communications

Facility (CAICCI). A copy of CAICCI runs on each system where CA solutions require it. The copies of
CAICCI on each system communicate with each other using various protocols based on CAICCI control
parameters. The gateway communication protocol is used for cross-platform scheduling (host-to-host
connection).
Each copy of CAICCI has a unique identifier known as the node name. On each system, CA solutions
register with the local copy of CAICCI as a CAICCI application. The local CAICCI then makes those
applications known to the copies of CAICCI on other systems that it is connected to. Several unique
CAICCI application names are used only for cross-platform scheduling. The combination of the node
name and the unique CAICCI application names let CA scheduling solutions route requests for work
and the feedback from that work.
Besides the unique node and CAICCI application names, each CA scheduling solution that participates
in cross-platform scheduling has a seven-character identifier known as a monitor name. In an MVS
environment, each CA scheduling solution must have a monitor name that is unique in the local MVS
environment. Thus, on a system where there are multiple instances of CA Workload Automation CA 7
Edition at the same node, each instance must have a different monitor name for cross-platform
scheduling to work properly for all defined instances.
The CAICCI application names used by cross-platform scheduling are based on the functions they
perform. The CAICCI application that receives requests for work has a fixed name that is common to
all systems, and there can only be one copy at a CAICCI node. Other CAICCI applications that
participate in cross-platform scheduling have a common format where the monitor name makes
them unique in the local CAICCI environment.
The CAICCI application names used in cross-platform scheduling are the following:
08-Feb-2018 216/722
The CAICCI application names used in cross-platform scheduling are the following:
SUBMITC Server
This CAICCI application name receives requests for work from CA Scheduling solutions on other
systems. The SUBMITC Server routes the request to the appropriate CA scheduling solution at
that node (monitor-name Server).
Only one copy of the SUBMITC Server can be on a given node regardless of how many CA
Scheduling solutions are executing at that node. On MVS, the cross-platform scheduling router
controls this application. On non-MVS platforms, only one CA Scheduling solution can run so that
solution directly controls the SUBMITC Server.
CAU9SET Setup Manager

This CAICCI application name controls the Checkpoint Synchronization process with other
systems. The Setup Manager initiates the Synchronization process. The Setup Manager sends
feedback (job initiation, termination, failure information) that was previously logged but not yet
sent to the other system participating in the synchronization.
Only one copy of the Setup Manager can be on a given node regardless of how many CA
Scheduling solutions are executing at that node. On MVS, the cross-platform scheduling router
controls this application.
CAU9CTK Track Task

This CAICCI application name sends the real-time feedback (job initiation, termination, and failure
information) to the remote system that requested a piece of work.
Only one copy of the Track Task can be on a given node regardless of how many CA Scheduling
solutions are executing at that node. On MVS, the cross-platform scheduling router controls this
application.
monitor-name Job Submit or monitor-name Job Submit2

This CAICCI application sends a request for a job to run on a different system. The request for
work is sent to the SUBMITC Server at the target node where the work is to execute. The CAICCI
application name consists of the seven character monitor name followed by the fixed text 'Job
Submit' or 'Job Submit2'.
There can be as many copies of Job Submit applications on a given node as there are CA
Scheduling solutions executing at that node. On MVS, each CA scheduling solution participating in
cross-platform scheduling controls these applications.
monitor-name Job track

This CAICCI application name receives the cross-platform feedback (job initiation, termination,
and failure information) for jobs it requested to be run on a remote system. Either the Setup
Manager or Track Task at the system where the job was run sends the feedback. The CAICCI
application name consists of the seven-character monitor name followed by the fixed text 'Job
track'.
There can be as many copies of Job track applications on a given node as there are CA Scheduling
solutions executing at that node. On MVS, each CA scheduling solution participating in cross-
platform scheduling controls these applications.
monitor-name Server
There can be multiple CA scheduling solutions on a single MVS image. These CAICCI applications
receive requests for work from the SUBMITC server application running at the local node. The
CAICCI application name consists of the seven-character monitor name followed by the fixed text
'Server'.
08-Feb-2018 217/722
'Server'.
There can be as many copies of Server applications on a given node as there are CA Scheduling
solutions executing at that node. These applications appear only on MVS, and each CA scheduling
solution participating in cross-platform scheduling controls them.
Cross-Platform Server Password Requirements

The password requirement rules for the cross-platform server on MVS define when a password must
accompany an explicit user ID in a cross-platform request. Using these rules you can discriminate
between trusted and nontrusted systems when receiving requests. That is, if you are confident that
requests from a given system have already gone through security checks to verify that the user ID
passed with the request should be honored, you can specify a rule. The rule lets the cross-platform
router accept the user ID without a password. For other systems that are not 'trusted' you can write
rules. The rules state that any request from them that contains a user ID must also carry a password
that the cross-platform server can validate. The XPS Router automatically rejects requests that are
received from these systems that have a user ID but no password.
Syntax Rules (see page 218)

Keywords (see page 219)
Processing (see page 219)
NODE Examples (see page 219)
Manage the Cross-Platform Workload (see page 220)
The Password Requirement process in the XPS Router does not validate the user ID/password
combination itself. The XPS Server scheduling system performs that process based upon its own
security processing (internal or external).
Password Requirement Rules are defined in a data set pointed to by the XPSPSWD DD statement in
the Cross-Platform Scheduling Router (XPS) environment. This data set is a sequential file consisting
of fixed 80-byte records (physical sequential or a member of a PDS). The records can be blocked or
unblocked. If the XPSPSWD DD statement is not present, or contains no valid rules, the default
processing is to accept all requests without checking for the presence of passwords.
When the Cross-Platform Scheduling Router (XPS) goes through initialization processing, it attempts
to locate and parse the Password Requirement Rules. If found, these rules are stored in an in-storage
table that is accessed during normal processing. Changes made to the rules do not take effect until
XPS is reinitialized.
Syntax Rules
Lines beginning with a blank or an asterisk (*) are considered comment lines.
Each individual rule must be contained on a single line between columns 1 through 71.
Continuation lines are not supported.
The rule definition consists of a series of keywords/values beginning in column 1, separated by

commas with no embedded blanks.
08-Feb-2018 218/722
Keywords
NODE=caicci-node-name
Identifies the one- to eight-character CAICCI node name that a Cross-Platform request can be
received from. Specify the value as a specific name or an asterisk (*) that indicates all nodes. If
not specified, the default is NODE=* indicating all nodes.
MONITOR=monitor-name
Identifies the seven-character scheduling system monitor name that a Cross-Platform request can
be received from. Specify the value as a specific name or an asterisk (*) that indicates all monitor
names. In cases where a given node can have multiple scheduling systems (such as multiple CA 7
instances), the NODE and MONITOR combination uniquely identifies a specific scheduling system.
If not specified, the default is MONITOR=* indicating all monitor names.
ID=user-id
Identifies the one- to eight-character user ID that can be passed with a cross-platform request.
Specify the value as a specific name or an asterisk (*) that indicates all user IDs. If not specified,
the default is ID=* indicating all user IDs.
PSWD=YES|NO
Indicates whether a cross-platform request that matches the NODE/MONITOR/ID parameters of
the rule must have a password to accompany the user ID in the request.
YES|Y
Indicates that such requests must have a password. This value is the default.
NO|N
Indicates that passwords are optional for such requests.
Processing
During processing, the XPS Router receives a cross-platform request. A check is made to determine
whether the request contains an explicit user ID.
If the request does not contain a user ID, a password requirement check is not made.
If the request contains both a user ID and a password, a password requirement check is not
made.
If the request contains a user ID but no password, a password requirement check is made.
The XPS Router attempts to find the 'best match' between the current request and the Password
Requirement Rule Table based on the NODE, MONITOR, and user ID. A match with a rule that
specifies a specific NODE, MONITOR, ID, or all, takes precedence over a generic rule. If multiple rules
equally match a request, the rules that require a password take precedence over those rules that do
not. If no match is found in the table, the request can proceed without a password.
NODE Examples
This rule indicates that any request from CAICCI node A04IENF, scheduling system CA7CA71 must
have a password when it contains an explicit user ID.
NODE=A04IENF,MONITOR=CA7CA71,ID=*,PSWD=YES
08-Feb-2018 219/722
This rule indicates that any request that contains a user ID of MASTER must have a password,
regardless of what CAICCI node or scheduling system sent the request. The default for MONITOR= is
'*' when it is not specified.
NODE=*,ID=MASTER,PSWD=YES
This rule indicates that a request from CAICCI node A04IENF with a user ID of TESTUSER is not
required to have an associated password.
NODE=A04IENF,ID=TESTUSER,PSWD=NO
If a request is received from CAICCI node A04IENF with a user ID of TESTUSER, it partially matches on
both of the preceding rules. The second rule takes precedence because a specific ID match takes
precedence over a specific NODE match. A password is not required.
NODE=A04IENF,ID=*,PSWD=YES
NODE=*,ID=TESTUSER,PSWD=NO
If a request is received from CAICCI node A04IENF, scheduling system CA7CA71 with any user ID it
partially matches on both of the preceding rules. In this case, the matches have equal weight (NODE
or MONITOR-specific, ID generic). If a tie, the rule that requires a password takes precedence over
one that does not. A password is required.
NODE=A04IENF,MONITOR=*,ID=*,PSWD=YES
NODE=*,MONITOR=CA7CA71,ID=*,PSWD=NO
Manage the Cross-Platform Workload

The distributed nature of cross-platform scheduling emphasizes the need to consider the question of
managing the cross-platform workload.
The degree of control granted the XPS CLIENT compared to the degree of control granted the XPS
SERVER distinguish two approaches to scheduling.
The manager-agent model can be useful in determining the distinction. The scheduling manager is
the focal point of control for the workload. The scheduling manager requests work and monitors
status for purposes of workload control (evaluating requirements, triggering other work). The
scheduling agent initiates work at the request of the manager and communicates status information
to the manager. Scheduling definitions (triggers, requirements) are primarily the responsibility of the
scheduling manager.
The question then arises: Does the XPS CLIENT or the XPS SERVER handle scheduling manager
functions?
How cross-platform jobs enter CA Workload Automation CA 7® Edition largely determines these
roles. Cross-platform jobs can enter CA Workload Automation CA 7 Edition in one of three ways:
Using a special variant of the RUN command referred to as RUNREF
The DEMAND command
The RUN command
08-Feb-2018 220/722
CA Workload Automation CA 7 Edition determines how the job enters the request queue based on
the value of the XPSSCHD keyword on the XPDEF initialization file statement. Values include RUNREF,
DEMAND, and RUN.
By default, cross-platform jobs enter using the RUNREF option. This assigns the role of scheduling
manager to the XPS CLIENT, the requester of the job on another operating environment (for example,
CA Workload Automation AE). The primary responsibility for workload control belongs to the XPS
CLIENT. Jobs that are scheduled using this option do not honor requirements that are defined in CA
Workload Automation CA 7 Edition. They are not considered requirements for other CA Workload
Automation CA 7 Edition jobs. They do not trigger other CA Workload Automation CA 7 Edition jobs
at completion. This variant of the RUN command differs from the standard RUN command in that it
does not allow a CA Workload Automation CA 7 Edition restart. A job that is scheduled using this
command is considered "complete" at either normal or abnormal termination. An entry for the job
appears in the CA Workload Automation CA 7 Edition RUNLOG. However, no entry is created for the
job in the prior-run queue.
A greater degree of workload control over cross-platform jobs can be assigned to CA Workload
Automation CA 7 Edition using the XPSSCHD=DEMAND or XPSSCHD=RUN options. If either of these
options is used, extra management functions become the responsibility of CA Workload Automation
CA 7 Edition.
XPSSCHD=RUN confers more responsibility on CA Workload Automation CA 7 Edition for monitoring

and control of restart and rerun conditions. However, because the RUN command is used to schedule
the job, CA Workload Automation CA 7 Edition requirement and trigger definitions are ignored.
XPSSCHD=DEMAND confers even more management responsibility on CA Workload Automation CA 7

Edition. Because the DEMAND command is used to schedule the job, CA Workload Automation CA 7
Edition requirement and trigger definitions are honored. CA Workload Automation CA 7 Edition must
be used to monitor restart and rerun conditions.
Note: The XPSSCHD keyword on the XPDEF initialization file statement is used to declare a
global option that applies to all jobs requested from XPS CLIENTs. This parameter can be
overridden for selected job. Code this keyword in the 'Filename' field (Job Detail -
Submission - Filename) in CA NSM. See Step 6 in CA WA CA 7 Edition XPS Server
Implementation Checklist (https://wiki.ca.com/display/CWAC7E
/CA+Workload+Automation+CA+7+Edition+XPS+Server+Implementation+Checklist).
Exercise care with jobs using XPSSCHD=RUNREF and CA Workload Automation CA 7 Edition step
condition code checking (#SSC statements). If #SSC processing detects an error situation, the code
returned to the requesting system is the return code that #SSC processing detects. This code is not
always the highest condition code that the job produces.
The default schedule ID for cross-platform jobs is 1. This value can be overridden for selected jobs.
Code a SCHID keyword in the Filename field (Job Detail - Submission - Filename) in the requesting
system definition. For more information about SCHID, see CA WA CA 7 Edition XPS Server
Implementation Checklist (https://wiki.ca.com/display/CWAC7E
/CA+Workload+Automation+CA+7+Edition+XPS+Server+Implementation+Checklist).
08-Feb-2018 221/722
CA 7 XPS Server Implementation Checklist

This checklist helps you implement the XPS Server.
Connections (see page 198).
XPS SERVER.
This interface requires CA Common Services for z/OS.
2. Define CAIENF Cross-Platform Scheduling Feedback Event (CAXPSFBK).

To define the CAXPSFBK CAIENF event and data elements, see the member JE10DCM. The
member is in the CA Common Services Sample JCL library.
3. Add cross-platform scheduling keywords to the CA Workload Automation CA 7® Edition

Select the appropriate values for cross-platform scheduling on the XPDEF initialization file
statement:
a. Specify XSERVER=YES. This value indicates to activate CA Workload Automation CA 7

Edition XPS SERVER functions.
b. The XPS Router executes on only one copy of CA Workload Automation CA 7 Edition at
any given CAICCI node. The XPS Router starts on the primary copy of CA Workload
Automation CA 7 Edition by default when XSERVER=YES is coded. You can use cross-
platform scheduling only with a nonprimary CA 7 instance. Code XROUTER=YES on the
XPDEF statement for that CA 7 instance to start the XPS Router.
c. Determine the appropriate value for the XPSSCHD parameter (on the XPDEF
statement) based on the needs of your environment. Remember that the default value
gives the greatest degree of workload control to the XPS CLIENT and limited control to
CA Workload Automation CA 7 Edition. To give a greater degree of control over cross-
platform jobs CA Workload Automation CA 7 Edition, consider either DEMAND or RUN
values for XPSSCHD.
d. Assume that you have more than one CA 7 instance on the target MVS system and you
want to route jobs to them all. Determine the appropriate value for the XPDEF file
initialization statement XMONITOR keyword. If this keyword is enabled, the MONITOR
name for a given CA 7 instance is displayed at startup in the following message
'CA-7.ISVC - XPS SERVER INITIALIZED. MONITOR VALUE: xxxxxxx
Refer to Step 6 in this checklist for information about how this value is used.
At least one internal terminal must be defined for use by cross-platform scheduling with
DEVICE=TRXDV.
The initialization file contains information about the initialization options for CA Workload
Automation CA 7 Edition XPS SERVER functions. Shut down and restart CA Workload
Automation CA 7 Edition for these options to take effect.
4.
08-Feb-2018 222/722
4. Define cross-platform scheduling password requirement rules.

To define cross-platform scheduling password requirement rules, create a data set or PDS
member to hold the rules. Add an XPSPSWD DD statement to the CA Workload Automation
CA 7 Edition JCL where the XPS Router executes (see the preceding step 3 b). For information
about coding the password requirement rules, see Cross-Platform Server Password
Requirements (see page 218).
5. In CA NSM, define a Station for the system where CA Workload Automation CA 7 Edition
executes.
See the CA NSM documentation for the specific procedures to define a Station. The Station
represents the MVS system where CA Workload Automation CA 7 Edition executes. The
'Station Type' is CPU, and the 'Node Type' is MVS.
6. Define cross-platform jobsets and jobs on CA NSM Job Management Option.

See the CA NSM Job Management Option documentation for the specific procedures to define
Jobsets and Jobs.
a. Use the 'Station' defined previously in the Job definition (Job Detail - Main Panel).
b. Specify the MVS job name that is defined to CA Workload Automation CA 7 Edition in
the 'Filename' field (Job Detail - Submission - Filename).
c. Assume that you have more than one instance of CA Workload Automation CA 7
Edition at the target MVS system and you want to route this job to a specific instance
of CA Workload Automation CA 7 Edition. Add the keyword ',MONITOR=monitor-name
' after the MVS job name in the 'Filename' field. For example, if you want to execute
job TESTJOB1 on the third CA 7 instance whose monitor name is CA7CA73, specify the
following values in Filename:
TESTJOB1,MONITOR=CA7CA73
The value of the XPSSCHD keyword on the XPDEF initialization file statement specifies
how to schedule a job that an XPS CLIENT requested. This value is a global value and
applies to all jobs requested by XPS CLIENTs. To override this value for a specific job
add the keyword ',XPSSCHD=xpsschd-value' after the MVS job name in the 'Filename'
field. For example, you want to DEMAND the job TESTJOB1 on the third CA 7 instance,
but the XPSSCHD value in CA Workload Automation CA 7 Edition is RUNREF. Specify
the following values in Filename:
TESTJOB1,MONITOR=CA7CA73,XPSSCHD=DEMAND
d. You can have the requested CA Workload Automation CA 7 Edition job to run with a
schedule ID other than 1. Add the keyword ',SCHID=nnn' after the MVS job name in
the 'Filename' field. The value for SCHID must be 1 through 3 digits from 1 through
999. For example, if you want to DEMAND the job TESTJOB1 with schedule ID 19,
specify the following values in Filename:
TESTJOB1,XPSSCHD=DEMAND,SCHID=19
e. You can specify a CA Workload Automation CA 7 Edition user ID that is used to bring
the MVS job into the CA Workload Automation CA 7 Edition system. Specify it in the
'Run as User', 'User' field (Job Detail-Submission-Run as User). Otherwise, the CA
Workload Automation CA 7 Edition user ID defaults according to the XPSSID= option
on the SECURITY statement in the CA Workload Automation CA 7 Edition initialization
file. A password is not always required depending on the MVS Password Requirement
08-Feb-2018 223/722
e.
file. A password is not always required depending on the MVS Password Requirement
Table described in the preceding Step 4. Passwords are only required when you set up
a Password Requirement Table. Otherwise, a password is not required.
7. Define the MVS jobs to CA Workload Automation CA 7 Edition.

Define the jobs in the CA Workload Automation CA 7 Edition database that cross-platform
requests are to initiate. These jobs are the MVS jobs that are identified in the 'Filename' field
of the CA NSM jobs. For information about defining a job in CA Workload Automation CA 7
Edition, see the CA Workload Automation CA 7 Edition documentation.
The Automated Recovery Facility (ARF) cannot be used with cross-platform jobs.
8. Schedule/Demand the CA NSM Jobset.

For more information about procedures to schedule Jobsets/Jobs, see the CA NSM
documentation.
When the cross-platform jobs are submitted, the request is routed to CA Workload
Automation CA 7 Edition on the specified MVS system (XPS SERVER). The CA Workload
Automation CA 7 Edition feedback is returned to the requesting system (XPS CLIENT).
CA Workload Automation Agents

CA Workload Automation agents are programs that reside on distributed servers. CA Workload
Automation agents are add-on components that must be purchased separately. That is, the CA
Workload Automation agents themselves are not distributed with CA Workload Automation CA 7®
Edition.
CA Workload Automation CA 7 Edition agent jobs let you automate and manage workloads running
on operating systems. Operating systems include Windows, Linux, and UNIX and ERPs such as SAP,
PeopleSoft, and the Oracle E-Business Suite. Also, CA Workload Automation agents respond to
messages sent from CA Workload Automation CA 7 Edition. They send messages back to CA
Workload Automation CA 7 Edition through CA Integrated Agent Services (CA IAS).
CA Workload Automation agents fall into four main categories:
Business agents (SAP, PeopleSoft, Oracle)
Application services (Java, WebServices)
Database agents (SQL, Stored Procedures)
System agents (Windows, UNIX)
In fact, CA Workload Automation CA 7 Edition supports a large variety of distinct agent job types.
The CA Workload Automation agent interface can be active or inactive. Sites can enable (activate) the
feature using the AGENTJOB keyword of the XPDEF statement of the initialization file. By default, the
feature is not active, and you cannot define CA Workload Automation CA 7 Edition agent jobs.
Note: Agent jobs use the same CA Workload Automation CA 7 Edition facilities as regular
jobs for:
08-Feb-2018 224/722
Scheduling
Triggering
Defining requirements
Defining resources (VRM)
Automating recovery (ARF)
All agent job feedback times are normalized to the CA Workload Automation CA 7 Edition time zone
as part of the CA IAS interface. Therefore, the Time Zone Offset, TZO, is always zero, matching the CA
Workload Automation CA 7 Edition time zone.
These topics document the following items:
The steps that you must follow to define and run CA Workload Automation CA 7 Edition agent
jobs
Agent job types
Agent commands that can affect job processing at the agent
Enable the CA 7 Edition Agent Interface

This process enables CA Workload Automation CA 7® Edition agent jobs. This process assumes that
the AGENTJOB parameter in the XPDEF Statement (https://wiki.ca.com/display/CWAC7E/XPDEF+Statement
) is set to YES.
Follow these steps:
1. Purchase the CA Workload Automation agents.
2. Install the CA Workload Automation agent software on the intended distributed operating
environment. The CA Workload Automation agent CD includes instructions for installing the
CA Workload Automation agent.
Note: Installing the CA Workload Automation agent is separate from installing CA

3. Create the files that are used as input for the CA Workload Automation agent interface. These
files include an agent definition (or configuration) file, an encryption key file, and a checkpoint
file.
08-Feb-2018 225/722
Note: For more information, see Implement CA IAS. (https://wiki.ca.com/display

/CWAC7E/Implement+CA+IAS)
4. Allocate and "seed" the CA Workload Automation CA 7 Edition agent information file using job
CA07N010, ddname DDAGENT, and SYSIN member AGTALLOC.
5. Modify the CA Workload Automation CA 7 Edition Online JCL to add the following DD
statements:
IASAGENT
Defines CA Workload Automation CA 7 Edition as a "manager" and lists the CA Workload
Automation agents to which this instance of CA Workload Automation CA 7 Edition can
communicate.
IASCRYPT
Defines the encryption keys to use in the AES encryption algorithm when data is sent to or
from a CA Workload Automation agent.
IASCKPT
Defines the checkpoint data set for CA Integrated Agent Services (CA IAS) use.
CA7AGNT
Defines the agent information file to CA Workload Automation CA 7 Edition. This file
contains information that is returned from the CA Workload Automation agents when a
job has been executed.
6. Activate the agent job interface by coding XPDEF AGENTJOB=YES in the CA Workload
Automation CA 7 Edition initialization file.
7. Start CA Workload Automation CA 7 Edition online.
8. Define a CA Workload Automation CA 7 Edition agent job to CA Workload Automation CA 7

Edition.
9. Create the CA Workload Automation CA 7 Edition agent job PARMLIB member.
10. Create the CA Workload Automation CA 7 Edition agent user ID and password. CA Workload
Automation agents, which are installed in Step 2, typically require a user ID and password be
passed with the job the agent is to execute.
11. Execute the LJCK command against the job that is defined to verify that no syntax errors are
encountered.
12. DEMAND the job from CA Workload Automation CA 7 Edition as you would any other job.
This test verifies the connection between CA Workload Automation CA 7 Edition and the CA
Workload Automation agent is made and that the job runs successfully.
13. Schedule or trigger the job to run as required.
08-Feb-2018 226/722
CA 7 Agent Job Types

This article explains how to manage Agent job types.
Manage Agent Job Types (see page 227)

Convert XPJOBs to Agent Job Types (see page 229)
Manage Agent Job Types

You identify the agent job type that you want to define using menus or the AGJOB command. The
menus are useful if you forget the actual job type specification or you want to see the available agent
job types. Before you define an agent job to CA Workload Automation CA 7® Edition, verify that the
agent supporting that job type is installed on the destination platform. Also verify that the agent is
defined to CA Workload Automation CA 7 Edition.
Options on the CA-7 Cross Platform Jobs Menu can direct you to the CA-7 Agent Job Definition panel
or to another menu. For example, if you select option F (SAP), you are directed to a tertiary menu of
SAP options.
Option A - XPJOB is not an Agent Job. This option is the same as the DB.10 panel option or XPJOB
command. The option is listed on this menu because it is used for submitting jobs on an alternate
platform.
The more direct way to access the Agent Job Definition panel is using the AGJOB command. The
following table shows the menu option, the valid Agent Job Type name, and a description of each job
type.
DB Panel Agent Job Type Alias Agent Job Description

DB.A.B UNIX_JOB UNIX Generic UNIX
DB.A.C NT_JOB WIN Microsoft Windows
DB.A.D FILE_TRIGGER FTRG File Trigger
DB.A.E Not applicable FTP Jobs Menu
DB.A.E.A FTP_JOB FTP FTP
DB.A.E.B SCP_JOB SCP Secure Copy
DB.A.E.C SFTP_JOB SFTP Secure File Transfer
DB.A.F Not applicable SAP Jobs Menu
DB.A.F.A BDC_JOB BDC SAP Batch Input Session
DB.A.F.B BWIP_JOB BWIP SAP Business Warehouse InfoPackage
DB.A.F.C BWPC_JOB BWPC SAP Business Warehouse Process Chain
DB.A.F.D SAP_JOB SAP SAP Generic
DB.A.F.E SAPA_JOB SAPA SAP Archive
DB.A.F.F SAPE_JOB SAPE SAP Event Monitor
DB.A.F.G SAPM_JOB SAPM SAP Process Monitor
DB.A.G PS_JOB PS PeopleSoft
08-Feb-2018 227/722

DB.A.H Not applicable Oracle Menu
DB.A.H.A OA_JOB ORAJ Oracle Request
DB.A.H.B OAC_JOB ORAC Oracle Copy
DB.A.I Not applicable Object Monitor Menu
DB.A.I.A CPU_MON OMCP CPU Monitor
DB.A.I.B DISK_MON OMDK Disk Monitor
DB.A.I.C IP_MON OMIP IP Monitor
DB.A.I.D PROCESS_MON OMPM Process Monitor
DB.A.I.E TEXT_MON OMTF Text File Monitor
DB.A.I.F EVENTLOG_MON OMEL Event Log Monitor
DB.A.I.G SERVICE_MON OMSM Service Monitor
DB.A.J Not applicable Database Jobs Menu
DB.A.J.A SQL_JOB SQL Database SQL
DB.A.J.B DBSP_JOB DBSP Database Stored Procedure
DB.A.J.C DB_MON DBMN Database Monitor
DB.A.J.D DB_TRIG DBTR Database Trigger
DB.A.K AS400_JOB OS40 AS400/OS400
DB.A.L Not applicable Java Jobs Menu
DB.A.L.A JMSP_JOB JMSP J2EE JMS Publish
DB.A.L.B JMSS_JOB JMSS J2EE JMS Subscribe
DB.A.L.C EJBE_JOB EJBE J2EE Entity Bean
DB.A.L.D HTTP_JOB HTTP J2EE HTTP/Servlet
DB.A.L.E POJO_JOB POJO J2EE POJO
DB.A.L.F RMI_JOB RMI J2EE RMI
DB.A.L.G EJB_JOB EJBS J2EE Session Bean
DB.A.L.H JMXB_JOB JMXB JMX-Mbean Attribute Get
DB.A.L.I JMXA_JOB JMXA JMX-Mbean Attribute Set
DB.A.L.J JMXO_JOB JMXO JMX-Mbean Operation
DB.A.L.K JMXS_JOB JMSX JMX-Mbean Subscribe
DB.A.L.L JMXN_JOB JMXN JMX-Mbean Create Instance
DB.A.L.M JMXR_JOB JMXR JMX-Mbean Remove Instance
DB.A.M Not applicable SNMP Jobs Menu
DB.A.M.A SNPG_JOB SNPG SNMP Get Attribute
DB.A.M.B SNPS_JOB SNPS SNMP Set Attribute
DB.A.M.C SNPC_JOB SNPC SNMP Subscribe
DB.A.M.D SNPE_JOB SNPE SNMP TrapSend
08-Feb-2018 228/722

DB.A.N WEB_SERV WEBS Web Services
DB.A.O WOL_JOB WOL Wake-On-LAN
DB.A.P PROXY_JOB Remote Execution
DB.A.Q NONSTOP_JOB NSTP HP Integrity NonStop
Convert XPJOBs to Agent Job Types

Sites that have purchased the CA Workload Automation Agent for UNIX, Windows, or both can, if
desired, convert their XPJOBs to UNIX or Windows Agent Jobs using the XPJOB Conversion Utility.
CA 7 Agent Job PARMLIB Member Creation

This article explains CA 7 Agent Job PARMLIB Member Creation. Defining the CA Workload
Automation CA 7® Edition agent job to CA Workload Automation CA 7 Edition is the first of two steps
in the job definition process. Next, set up the proper parameter statements for the agent job you
want to execute. Each job type has a different set of parameters that define what task executes at
the agent. These parameters are stored in the parameter library, which can also serve as a JCL library.
After you define the parameters in the PARMLIB, execute the LJCK command. LJCK performs an initial
validation of the message that is built. The LJCK command builds a simulated message. The message
verifies that the parameters are correctly coded for the agent job type coded.
CA IAS interfaces with CA Workload Automation CA 7 Edition to build information to send to the
agents and handles the communications
Note: For more information about the keywords that can be coded with each job type, see
Use CA IAS (https://docops.ca.com/display/CA712/Use+CA+IAS).
Agent and CA IAS Commands

CA Workload Automation CA 7® Edition supports commands that are directed to CA Workload
Automation agents and to the CA IAS interface. Agent command examples include retrieving spool
data for an executed job, canceling a job that is actively executing, and refreshing security files. CA
IAS command examples include saving the password information that is required for most agent job
types, reconfiguring the agents, and setting logging options.
The AGFILE command provides several options to obtain details about an agent job. AGFILE can
display the stored information from the CA Workload Automation CA 7 Edition agent information file.
Also, AGFILE can retrieve the spool data or log for a job that has executed. From the agent
information file, the AGFILE command can display the job status information, which can change
during the execution of a job. If a job failed at the agent, the status information can also provide
information as to why the job failed.
08-Feb-2018 229/722
For certain job types whereby the job is waiting to be transmitted to the agent, or is active at the
agent, the CANCEL command either removes the job from the CA IAS queues or sends a cancel
command to the agent. For a few job types, a HOLD and RELEASE command sends a command
message to the agent.
The administrative commands /AGENT and /IAS can perform various functions against an agent or to
the CA IAS interface. Restrict these functions, such as clearing log files or setting logging options, to
those users who maintain the CA Workload Automation CA 7 Edition system environment.
Manage Email from CA 7

CA Workload Automation CA 7® Edition can generate and send email messages. The email message
content can be generic or can contain information about a job in the CA Workload Automation CA 7
Edition queues.
The EMAIL initialization file statement must process successfully before the CA Workload Automation
CA 7 Edition email interface is initialized. Sites can use the /DISPLAY,ST=EMAIL command to
determine whether the email interface is initialized.
If a TCP/IP connection was not established at initialization, the /EMAIL or /EADMIN,ENABLE=Y

commands can be issued to reattempt a connection. If the connection attempt failed, the following
symptoms are present:
WTO: “CAL2E002E UNABLE TO RESOLVE ESERVER NAME FUNC=INTIAPI RC=-00000001

REA=00001036”
/DISPLAY,ST=EMAIL shows “ENABLED: NO TCP/IP”
The email interface uses an email template (read from the EMAILLIB PDS) to build the the email body.
The template can have variables (such as &JOBNAME) that the product resolves before sending the
email.
An email is sent to the list of email addresses in an email address member (read from the EADDRLIB
PDS). One email can have 1 through 100 recipients. If more email recipients are needed, the email
must be sent again using a second email address member.
Emails are generated and sent when the /EMAIL command is issued. The /EMAIL command specifies
an email template to use (using the TXT keyword) and an email address member to use (using the TO
keyword). The /EMAIL command can optionally specify a job in the CA Workload Automation CA 7
Edition queues (using the JOB keyword).
The /EMAIL command can be issued anywhere a CA 7 top-line command can be issued, including
from an ARFSET.
Your local implementation of TCP/IP sometimes requires that you add a //SYSTCPD DD statement to
your CA Workload Automation CA 7 Edition online JCL and your email test utility.
08-Feb-2018 230/722
Note: CA Workload Automation CA 7 Edition has no control over the delivery of emails.
Therefore, we recommend that you do not use email as the sole notification of a problem,
such as an abended or failed job.
JES3 Site Email Usage

Whether you run IPv4 or IPv6, include the name of your global is in the HOSTS.LOCAL file for the
system where the product runs.
Email Address Members

EADDRLIB PDS members are used to build the list of email addresses to which an email is sent. The
TO=xxxxxxxx keyword on the /EMAIL command specifies the member name.
Each member can have 1 through 100 email addresses. Each address must start in column one and
can be up 70 characters long. The addresses can contain uppercase and lowercase letters, and any
special characters needed in the email address.
CA Workload Automation CA 7® Edition does not verify the email address in any way. Email addresses
are used as is.
Email addresses can be internal or external to your company. Remember that your SMTP (email)
servers sometimes require some configuring to deliver mail outside of your company.
Comments can be included in the email address member by starting each comment line with an
asterisk in column one.
The EMAIL initialization file statement on the EREPLY keyword specifies the default reply email
address. To override the default, start the first email address with the word "reply:" followed by the
reply address. The new reply address starts immediately after the colon. The word "reply:" can be in
uppercase or lowercase.
Example 1
This example shows that the simplest address member is a single line with an email address.
****** ********************** Top of Data ********************** =COLS> ----+----1----
+----2----+----3----+----4----+----5----+-- 000001 user.one@company.com (mailto:user.
one@company.com) ****** ********************* Bottom of Data ********************
Example 2
This example contains multiple email addresses with comments included.

****** ********************** Top of Data ********************** =COLS> ----+----1----
+----2----+----3----+----4----+----5----+-- 000001 * Payroll application group
000002 user.one@company.com (mailto:user.one@company.com) 000003 another_user@company.com
(mailto:another_user@company.com) 000004 Upper_And_Lower_Case@a_really_long_company_name
.com (mailto:Upper_And_Lower_Case@a_really_long_company_name.com)
****** ********************* Bottom of Data ********************
Example 3
08-Feb-2018 231/722
Example 3
This example overrides the reply address.

****** ********************** Top of Data ********************** =COLS> ----+----1----
+----2----+----3----+----4----+----5----+-- 000001 reply:operations_group@company.com
(http://company.com) 000002 application_programmer@company.com (mailto:
application_programmer@company.com)
****** ********************* Bottom of Data ********************
If the Application Programmer receiving this email replies to it, the reply goes to the operations
group. A site can decide to use this method to let email recipients respond to a problem directly to
the person or group responsible for correcting the problem. For example, the Application
Programmer might instruct the operations group to restart the abended job in a certain step.
Email Template Variables

This article explains email template variables, including special character usage.
Email Templates (see page 232)

Special Characters (see page 235)
Email Templates
The email template controls the subject line and body of the email. Templates are stored in the
EMAILLIB PDS. The email template member name is specified on the TXT=xxxxxxxx keyword on the
/EMAIL command.
The first line of the template can specify the email subject. The line starts with the word "subject:"
starting in column one. The remainder of that line is used as the email subject.
The rest of the email template is used for the body of the email, which can be in any valid email
format, such as simple (ASCII) text or HTML.
Note: Emails are translated from EBCDIC to ASCII using the IBM XLATE service or the CA
Workload Automation CA 7® Edition CAL2XLAT translation module. The XLATE service does
not translate all characters correctly.
Trailing blanks on each line are discarded.
Any line can have one or more variables that the product resolves before sending the email. Variable
names must start with an ampersand (&) and must be in uppercase. Trailing blanks are removed from
the values of all variables. Remember that some variables do not always have a value.
The following variables are available in an email template:
&AMPER
The ampersand (&)
&CA7
08-Feb-2018 232/722
&CA7
The instance name (CA71, CA72, PROD, TEST) of the product that is generating and sending the
email.
&CA7CCI
The 8-byte CAICCI node name of the system on which the product is executing.
&CA7CUST
The 44-character heading value that is specified on the CUST,ID=xxxxx initialization file statement.
&CA7HOST
The SMFID of the system on which the product is executing.
&CA7LVL
Previously the service pack level, and now returns four spaces.
&CA7NAME
The name of the product, "CA 7".
&CA7RLSE
The product release number, such as r11.3
&CRLF
The carriage return/line feed
&EFROM
The value to display in the "from" field of the email. The value is specified on the EMAIL,EFROM=
xxxx initialization file statement. Use the /EADMIN,EFROM=xxxx command to change the value.
Default: CA-7
&EREPLY
The reply email address for this email. The value is specified on the EMAIL,EREPLY= xxxx
initialization file statement. Use the /EADMIN,EREPLY=xxxx command to change the value. The
reply address can also be overridden in the email address member.
Default: CA-7@do.not.reply (mailto:CA-7@do.not.reply)
&VAR1 to &VAR8
Contents of the VAR=(xx,xx,) keyword on the /EMAIL command. If the VAR= keyword is not
specified, these variables are blank.
The following variables are available when the JOB= keyword is specified on the /EMAIL command:
Variable Name Variable Contents Notes

&DEADDATE The deadline date for the job 1
&DEADTIME The deadline time for the job 2
&DUEDATE The due out date for the job 1
&DUETIME The due out time for the job 2
&EDATE The date the job ended 1, 3
&EMODE The entry mode for the job, such as "DEMANDED."
&ETIME The time the job ended 2, 3
08-Feb-2018 233/722
Variable Name Variable Contents Notes

&JES# The JES number for the job 3
&JOB# The CA Workload Automation CA 7 Edition job number
&JOBL The long name of the job
&JOBNAME The name of the job
&JQUSER The 20-byte contents of the JQUSER field 4
&MAINID The MAINID for the job 6
&MCNT The current master requirement count for the job
&QUEUE The current queue- REQ, RDY, or ACT
&RC The return code for the job 3
&SCHDID The schedule ID for the job
&SDATE The date the job started 1, 3
&SMFID The SMFID of the system where the job is executing (or did execute). 3
&STATUS The status for this job 5
&STIME The time the job started 2, 3
&SYSTEM The SYSTEM (from the job definition) for this job
&UID The CA Workload Automation CA 7 Edition UID (userid) value for this job
Notes
1
Dates are formatted as "Tue, 14 Sep 20xx"
2
Times are formatted as "hh:mm:ss". If the specified time does not have seconds, then "00" is
used for the seconds.
3
If the job has not started, the start date and time are "*Unknown". The JES number and SMFID
are blank. If the job has not yet ended, the end date and time are "*Unknown". The return code
(RC) is blank. For cross-platform jobs, the JES number is *NA* while the possible SMFID values are
7XPJ, 7UNI, 7UWT, AGJ, or blank. The value depends on how the job completed (job status) and
the timing of when the email is generated.
4
No conversion is done on the JQUSER contents. If the contents are not EBCDIC characters, the
ASCII translation necessary for sending the email sometimes generates garbage characters.
5
The job status variable contains the same string that would appear in the column of an LQ
command display.
6
For XPJOB jobs, the MAINID is XPJ. For agent jobs, the MAINID value uses the four-character alias
of the Agent Job Type.
The CAI.CAL2EMAL data set provides some sample email templates. Use these templates as-is or can
08-Feb-2018 234/722
The CAI.CAL2EMAL data set provides some sample email templates. Use these templates as-is or can
tailor them to your needs. The samples are formatted for HTML. The following sample templates are
provided:
@JOBABND
Job abends
@JOBEND
Job successful completions
@JOBFAIL
Job failures (bad return codes)
@JOBLATE
Jobs being marked late
Special Characters
Emails must be in ASCII. The product uses the translate table defined by module CAL2XLAT, if
available. You can modify this table to translate certain special characters such as the exclamation
mark, the square brackets, and the vertical bar.
If you use HTML format for your email template, you can use JavaScript codes for these special
characters. The following is a partial table of JavaScript codes that you can use instead of these
special characters:
Character Code
! !
[ [
] ]
| |
Many other JavaScript codes are available.
Each code starts with an ampersand followed by a hash mark and ends with a semicolon.
If your site has implemented the CAL2XLAT module, characters are translated based on the
definitions assigned in the program. If you have not remapped the special characters described
previously, you have the same issues as the XLATE service.
Email Test Utility

A batch utility, CAL2EMLT, tests the email interface in an isolated environment. The utility can test
different SMTP (email) servers, new templates, new email address members, or all.
CAL2EMLT provides information about a "dummy" job so that email templates with variables
referencing job information display with realistic data. CAL2EMLT should complete with RC=0.
However, it generates a variable that simulates that the program abended with code S0C4.
The JCL for CAL2EMLT is in the AL2EMAIL CAL2JCL member.
08-Feb-2018 235/722
Control Statements
The control statements must begin in column one in the SYSIN DD statement. Enter keywords (such
as ESERVER) in uppercase. Some keywords (again, such as ESERVER) accept mixed-case values.
Include your comments by starting the line with an asterisk in column one.
ESERVER=value Identifies the primary SMTP (email) server. If the primary SMTP server is
unavailable or if the ESERVER keyword is not specified, the SMTP server on the z/OS image where
CAL2EMLT executes is used. The ESERVER value can be a one to 70 character name to be resolved
by a Domain Name Server (DNS) or an IP statement in the format n.n.n.n or x:x:x:x:x:x:x:x, where
n is a decimal number from 0 through 255 and x is a hexadecimal number from 0 through FFFF.
You can specify leading zeros for both. The short form of an IPv6 address using a double colon (::)
can be used.
EPORT=value Specifies the TCP/IP port number that is used when communicating with the SMTP
(email) server.
Valid values: 1 through 99999
Default: 25 (well-known port number for SMTP and rarely requires a change)
EFROM=value Specifies the value that appears in the "From" field of the email.
Valid values: 1 through 70 characters
Default: CA-7
EREPLY=value Specifies the email reply address that is used when the recipient replies to the
email.
Valid values: 1 through 70 characters
Default: CA-7@do.not.reply.
ETIMEOUT=value Specifies the maximum number of seconds CAL2EMLT waits for responses from
TCP/IP and the SMTP (email) server.
Valid values: 5 to 20 seconds
Default: 10 seconds
TO=value Identifies the member in the EADDRLIB PDS that is read for the email addresses.
Default: not applicable
TXT=value Identifies the member in the EMAILLIB PDS that is read for the email template.
Default: not applicable
VARn=value The VAR1 to VAR8 keywords let the user specify one to eight character values. The
values are substituted for the &VAR1 to &VAR8 variables in the email template.
Data Set for TCP/IP Data

Email uses TCP/IP as a transport mechanism. Each system must run at least one TCP started task. TCP
/IP configuration data is contained in a data set pointed to by a //SYSTCPD DD statement in the TCP
started task. Depending on your implementation of TCP/IP, that data set can be dynamically
allocated.
08-Feb-2018 236/722
Your site can run more than one TCP started task. If so, CA Workload Automation CA 7® Edition
corresponds to one of these TCP stacks. If the data set is not dynamically allocated, or if your site
runs multiple TCP stacks, it is sometimes necessary to add a //SYSTCPD DD statement to your CA
Workload Automation CA 7 Edition online JCL. Check with your TCP/IP support person to see if this
DD statement is necessary at your site.
If needed, make this DD statement the same as the //SYSTCPD DD statement in the JCL of the TCP
started task that corresponds to CA Workload Automation CA 7 Edition.
//SYSTCPD DD DISP=SHR,DSN=TCPIP.VTAM.DATA
In addition, add an identical //SYSTCPD DD statement to the JCL of the email test utility.
Global Variables
The global variables feature permits users to perform variable substitution without requiring the use
of CA Driver procedures. The global variables also provide functionality for customers who want to
use the feature instead of, or in addition to, CA Driver.
The feature lets users define global variables and assign values to those variables. Also, a fixed set of
reserved global variables is always available (for example, current date, job name, and more). A one-
character prefix (7 is the default) that the site can set identifies the reserved global variables.
Note: To add, update, and delete global variables, use the /GVAR command.
Variable substitution takes place if the GVARSUB=YES option was specified when the CA 7 instance
was started.
A CA Workload Automation CA 7® Edition command can be used to simulate JOB statement

expansion to test substitution without actually submitting the job.
Substitution Process
How global variable substitution behaves depends on where it is encountered. The substitution
process is designed for CA Workload Automation CA 7® Edition JOB statements. Global variable
substitution behaves differently in CA Driver procedures and standard JCL procedures.
Job Statements
As CA Workload Automation CA 7 Edition processes the job, each statement is parsed for variables
based on a character string prefix that the site can specify. The default prefix is an ampersand
followed by a colon (&:). When a valid variable is found, the value for that variable is substituted in
place of the variable. After the entire statement has been parsed, it is submitted.
08-Feb-2018 237/722
CA Driver Procedures
When CA Driver is active, the CA Driver process takes place before global variable substitution. In
effect, two variable substitution processes take place. In a statement of a CA Driver procedure, the
CA Driver variables are first replaced with their values. Next, any global variables are replaced with
their own values before being submitted.
Note: The value of a CA Driver variable can be a global variable, which its own value then
replaces.
Standard Procedures
CA Workload Automation CA 7 Edition does not expand non-Driver JCL procedures. JES performs that
function. Therefore, if a global variable is found in a standard, non-Driver JCL procedure, global
variable substitution does not take place.
Note: If JES encounters an unsubstituted global variable, a JCL error sometimes occurs.
Substitution Rules and Restrictions

The following rules and restrictions apply to global variable substitution:
Global variable substitution applies only to jobs submitted by CA Workload Automation CA 7®

Edition.
For CPU jobs, a JCL error occurs if the replacement data would cause the JCL line to expand:
into column 72 if the line is numbered and column 72 is blank
into column 67 on the JOB statement
into column 80 in all other cases
The error is described in the CA Workload Automation CA 7 Edition browse data set.
If a blank follows the global variable, at least one blank also follows the replacement data.
If a comma follows the global variable, a comma also follows the replacement data.
If a right parenthesis follows the global variable, a right parenthesis also follows the replacement
data.
08-Feb-2018 238/722
If a single period follows the global variable, a period does not follow the replacement data. The
period is omitted, and the replacement data is concatenated with the text immediately following
the variable.
If the replacement character string is shorter than the global variable (including the prefix), the
character string is shifted left the number of bytes the replacement character string is shorter
than the global variable. The shift continues until a space is encountered, at which point the shift
terminates. At that point, the number of spaces is increased by the number of bytes that the
global variable exceeds the replacement character string.
If the replacement character string is longer than the global variable, all following bytes are
shifted right by the number of bytes that the replacement character string is longer than the
global variable. This shift continues until a string of spaces long enough to contain the number of
characters that are shifted, plus one blank is encountered at the end of the statement. If such a
string of spaces is not available, an error message is issued and the process terminates. Two or
more character strings can be shifted right if the number of spaces at the end of the statement is
sufficient to contain the number of characters that are shifted and still leave one space. In the
following examples, global variable &:F has a replacement value of FILEAB and &:DATASET has a
replacement value of DSN:
Original stmt: //&:F DD DSN=PAYROLL.MASTER COMMENT
Expanded stmt: //FILEAB DD DSN=PAYROLL.MASTER COMMENT
Original stmt: //INP DD DSN=&:DATASET..XYZ COMMENT
Expanded stmt: //INP DD DSN=DSN.XYZ COMMENT
Original stmt: //INP DD DSN=MASTER.&:F..INPUT COMMENT
Expanded stmt: //INP DD DSN=MASTER.FILEAB.INPUT COMMENT
The value for a global variable can contain one or more other global variables. For example, the
following value is legal: AB&:CD.EF&:WX.YZ. If the value for global variable &:CD is 7 and the
value for &:WX is 5, the final substituted value is AB7EF5YZ
Recursion is allowed and means that a global variable can return another variable in the first
position. Examples: global variable &:ABC returning the string &:XYZ is recursive. &:ABC returning
XY&:ZW is not recursive because the &: prefix is not in the first position. In the following example,
global variable &:RC1 has a replacement value of &:RC2. (note the period at the end) and &:RC2
has a replacement value of MASTER:
Original stmt: //DD1 DD DSN=PAYROLL.&:RC1 COMMENT
Expanded stmt: //DD1 DD DSN=PAYROLL.MASTER COMMENT
If the number of recursions for a global variable exceeds the limit that is specified by the GVARLVL
parameter on the initialization OPTIONS statement, a JCL error occurs. The error is described in
the CA Workload Automation CA 7 Edition browse data set.
When right-shifting, the number of characters that are moved is the largest number moved
during any of the intermediate or final substitutions. In the following example, the value for the
variable &:MODEL is &:X. and the value for the variable &:X is the reserved variable &:7CA7. The
instance of CA7 is CA74. The numbers 15 and 30 show the positions of columns 15 and 30 during
and after substitution.
Original stmt: //* &:MODEL 15 &:MODEL.XX 30
Intermediate (unseen) stmt: //* &:X. 15 &:X.XX 30
Intermediate (unseen) stmt: //* &:7CA7. 15 &:7CA7.XX 30
Final stmt: //* CA74 15 CA74XX 30
08-Feb-2018 239/722
In a job's JCL, you can code a special JCL comment statement of //*VARSUB=OFF and
//VARSUB=ON. This comment statement turns off and on whether to do global processing for the
job. The special comment statement can be coded multiple times and simply sets a switch that is
checked as the job is processed.
Reserved Variable Names

This article describes reserved variables names and coding variable parameters..
General Reserved Variable Names (see page 240)

Specific Reserved Names (see page 241)
DATE Examples (see page 242)
Code Variable Parameters (see page 242)
General Reserved Variable Names

The following table contains the general reserved variable names.
Variable Variable Contents Variable Notes

Name Length
7CA7 Instance/alias name of CA Workload Automation CA 7® Edition =<4 See
note.
7CA7CCI CAICCI node name of the system on which CA Workload Automation =<8 See
CA 7 Edition is executing note.
7CA7HOST SMFID of the system on which CA Workload Automation CA 7 Edition =<4 See
is executing note.
7CA7LVL Blanks 4
7CA7RLSE Release of CA Workload Automation CA 7 Edition, such as "R11.3" or =<5 See
"R12.0" note.
7CDATE Current system date in Gregorian format (mm/dd/yy) 8
7CDATEJ Current system date in Julian format (yyjjj) 5
7CDAYW Current day of the week (SUNDAY,...) =<9 See
note.
7CMONTH Current month (JANUARY,...) =<9 See
note.
7CTIME Current system time (hh:mm:ss) 8
7DD Current day of the month 2
7HH Current hour 2
7MM Current month 2
7MN Current minute 2
7NULL Null 0
7SS Current second 2
08-Feb-2018 240/722

Name Length
7YY Current year (yy) 2
7YYYY Current year (yyyy) 4
Note: The length of returned text varies. Trailing blanks are omitted to avoid embedded
blanks if there was concatenation.
Specific Reserved Names

The following table lists the job-specific reserved variable names.

Name Length
7CA7JOB# CA Workload Automation CA 7® Edition job number 5 2
7CC Value for the condition code test in job definition 5
7CLASS Job workload balancing (WLB) class value 1
7DLDATE Job deadline date (mm/dd/yy) 8
7DLTIME Job deadline time (hh:mm:ss) 8 3
7DODATE Job due out date 8
7DOTIME Job due out time 8 3
7EMODE Job entry mode =<8 1,4
7JOBL Long job name =<64 1
7JOBNAME Job name =<8 1
7LTERM Job LTERM value =<8 1,5
7MAINID Job MAINID =<4 1
7PRY Job WLB priority value 3
7QUEUE Job current queue =<8 1
7RO Relational operator value for the condition code test in job 2 6
definition
7SCHDID Job schedule ID 3 7
7SYSTEM Job system in job definition =<8 1
7TAPE1 Number of WLB TAPE1 tape drives for job 3
7TAPE2 Number of WLB TAPE2 tape drives for job 3
7UID Job UID 3
Notes:
08-Feb-2018 241/722
1. The length of returned text varies. The trailing blanks are omitted to avoid
embedded blanks in concatenation.
2. The value is 00001 on LJCK displays.
3. The specified time does not have seconds. The time uses 00 value for the seconds.
4. The value is SSCAN on LJCK displays.
5. The value is the job name on LJCK displays.
6. If character is a blank, it is translated to a period to avoid embedded blanks in

concatenation.
7. The value that is supplied from SCHID is used.
DATE Examples
Assume that the current date is November 25, 2014. The reserved global variable &:7CDATE
produces the value 11/25/14.
European Date Format
The following sequence can be used to produce the value 25/11/14:
&:7DD./&:7MM./&:7YY
Alternate Date Format
The following sequence can be used to produce the value 2014.11.25:
&:7YYYY..&:7MM..&:7DD
Code Variable Parameters

Define Default Values
A default value of up to 64 characters can be optionally defined for each parameter:
If the value contains any blanks or special characters, it must be enclosed in quotes or other
special character delimiters like apostrophes or slashes. (The following cannot be delimiters:
spaces, commas, periods, ampersands, plus or minus signs.)
If the value contains only alphanumeric characters, delimiters are optional.
Examples
//LVTOC DPROC VAR1=YES
//LVTOC DRPOC VAR2='A B C'
//LVTOC DPROC VAR3=/JOHN'S/
//LVTOC DPROC VAR4=
In the first example, the default value for VAR1 is YES. Because this name consists only of
08-Feb-2018 242/722
In the first example, the default value for VAR1 is YES. Because this name consists only of
alphanumeric characters, no quotes or other delimiters are required.
In the second example, VAR2 has a default value of A B C. Because this name contains spaces, enclose
it in quotes or other delimiters.
In the third example, the default value for VAR3 is JOHN'S. Because this character string contains a
quote, a special character other than a quote must be used as a delimiter. In this example, a slash (/)
is used.
In the fourth example, no default value is defined.
Supply Values on the EXEC Statement

If no default value is defined on the procedure, a value for the parameter must be given on the
calling EXEC or DPROC statement. (If values are given in both places, the value on the EXEC or DPROC
statement overrides the defined default value.)
Values that are supplied on the calling EXEC or DPROC statement are coded the same way as default
values:
If the value contains other than alphanumeric characters, delimiters are required.
If the value contains only alphanumeric characters, delimiters are optional.
Examples
//CALL EXEC PROC=LVTOC,VAR1=NO
//CALL EXEC PROC=LVTOC,VAR2='D E F'
//CALL EXEC PROC=LVTOC,VAR3=/MARY'S/
//CALL EXEC PROC=LVTOC,VAR4='REPLACEMENT VALUE'
DPROC=LVTOC,VAR5='NEW PARM DATA FOR XPJOB ONLY'
Multiple variable parameters can be listed one after the other, separated by commas.
For CPU jobs to continue an EXEC statement to the next line, end the first line with a completed
parameter, including the separation comma. Code the second line with slashes in columns 1 and 2.
Code the additional parameters beginning in column 16 or before, but not in column 3.
For XPJOB jobs to continue the statement with more variables, end the first line with a completed
parameter, including the separation comma. Code the second line with the variable name starting in
column 1.
Note: The line being continued does not need to have a plus sign (+) at the end. If you want
to put a plus sign, leave at least one space between the command and the plus sign (+).
Examples
//CALL EXEC PROC=LVTOC,VAR1=NO,VAR2='D E F',VAR3=/MARY'S/
//CALL EXEC PROC=LVTOC,VAR1=NO,VAR2='D E F',VAR3=/MARY'S/,
// VAR4='REPLACEMENT VALUE'
DPROC=LVTOC,VAR1=XPJOB,VAR2='has a different syntax',
08-Feb-2018 243/722
DPROC=LVTOC,VAR1=XPJOB,VAR2='has a different syntax',
VAR3='BUT DPROCs will still work'
All variable parameters must be given a value before they are used. If a value is not specified on the
DPROC or EXEC statements, it can be specified on the DSET statement. You can test for an omitted
variable value with the Type test of the DIF statement.
// DIF T'VAR1 NE O GOTO VAR1OK
// DSET VAR1=DEFAULT
//VAR1OK DSTEP
Reference Variable Parameters in the Procedure

An ampersand must precede the variable parameter wherever it is coded in the body of the
procedure. (Never use an ampersand on the DPROC or EXEC statements.) The ampersand signals CA
Driver to replace the variable parameter with a value. For example, assume that the default value
FILE has been defined for the variable parameter VAR1.
This statement in the procedure will be expanded as:

//&VAR1 DD DSN=DATA.SET //FILE DD DSN=DATA.SET
//SYSUT1 DD DSN=DATA.&VAR1 //SYSUT1 DD DSN=DATA.FILE
If an alphanumeric character immediately follows the variable parameter, terminate it with a period
in the procedure. If a period is to follow the variable parameter after replacement, it must appear in
the procedure followed by two periods. For example:
This statement in the procedure will be expanded as:

//SYSUT1 DD DSN=&VAR1.DATA //SYSUT1 DD DSN=FILEDATA
//SYSUT1 DD DSN=&VAR1..DATA //SYSUT1 DD DSN=FILE.DATA
An ampersand does not precede a variable parameter in either of the following situations:
The object of a DSET statement (that is, a value is being assigned to it).
The first object of a DIF statement.

// DSET VAR1=&VAR2 will assign VAR1 the contents of VAR2
// DSET VAR1=VAR2 will assign VAR1 the string 'VAR2'
// DIF VAR1 EQ &VAR2 GOTO STEP will compare the contents of VAR1 and VAR2
// DIF VAR1 EQ VAR2 GOTO STEP will compare the contents of VAR1
with the string 'VAR2'
Use Variable Parameters In Nested Procedures

Variable parameters can be passed from a calling procedure to a nested procedure. To pass variables,
the variable parameter must be defined in each procedure using either the same parameter name or
different parameter names. For example, a nested procedure being passed a parameter from a
calling procedure could be created as:
//LVTOC DPROC VAR1=YES
.
.
.
// DNEST LVTOCS,VAR2=&VAR1
//LVTOCS DPROC VAR2=
The calling procedure defines VAR1, and the nested procedure defines VAR2.
08-Feb-2018 244/722
Shift During Expansion

During variable parameter substitution, the substitution character string can be shorter or longer
than the parameter name. CA Driver shifts the character string during procedure expansion according
to these guidelines:
If the replacement character string is shorter than the variable parameter (including the
ampersand and concatenation character, if present), the character string is shifted left the
number of bytes that the replacement character string is shorter than the variable parameter.
This shift continues until a string of two or more spaces is encountered. At which point, the shift
terminates. As a result, these spaces are increased by the number of bytes that the variable
parameter exceeds the replacement character string.
If the replacement character string is longer than the variable parameter, all following bytes are
shifted right by the number of bytes that the replacement character string is longer than the
variable parameter. This shift continues until a string of spaces long enough to contain the
number of characters that are shifted, plus one blank, is encountered at the end of the
statement. If such a string of spaces is not available, an error message is issued. The procedure
expansion terminates. Two or more character strings can also be shifted right when the number
of spaces between them is sufficient to contain the number of characters that are shifted and still
leave one space.
In these examples, the variable parameter &F has a replacement value of FILE and &DATASET has a
replacement value of DSN.
Original stmt: //&F DD DSN=PAYROLL.MASTER COMMENT
Expanded stmt: //FILE DD DSN=PAYROLL.MASTER COMMENT
Original stmt: //INP DD DSN=&DATASET..XYZ COMMENT
Expanded stmt: //INP DD DSN=DSN.XYZ COMMENT
Original stmt: //INP DD DSN=MASTER.&F..INPUT COMMENT
Expanded stmt: //INP DD DSN=MASTER.FILE.INPUT COMMENT
Note: We do not recommend the use of sequence numbers or extraneous data such as
comments on lines containing variables in CA Driver DPROCs. Shifting during DPROC
expansion can produce undesirable results.
Jobflow Illustrator
The Jobflow Illustrator forecasting facility can execute in a batch mode outside of the online
environment. Jobflow Illustrator provides several features that the online forecasting tool does not
provide:
Reflect job dependencies like other jobs and data sets in the forecasted flow in addition to
triggers.
Obtain visuals through the CA 7® Web Client.
Permit job additions or job deletions to see what effect occurs on the workload.
A workflow is a comprehensive view of the CA Workload Automation CA 7® Edition workload for a
08-Feb-2018 245/722
A workflow is a comprehensive view of the CA Workload Automation CA 7® Edition workload for a

specific period, which is known as the span. The workload comprises objects (jobs and data sets) and
the direct relationships, or connections, between them.
To include an object or connection in a workflow, the object or connection must first be defined in
the CA Workload Automation CA 7 Edition database.
Workflow Building Process

The workflow building process consists of two phases: search and filter. Jobflow Illustrator builds its
tables and uses search parameters to query the CA Workload Automation CA 7® Edition definitions to
see which scheduled jobs meet all the specified criteria. Each matching job becomes head of a
workflow chain.
After the heads of chain are identified, each chain is run to add triggered jobs and data sets and
required (prerequisite) jobs and data sets. The filter parameters specify the criteria for selecting the
nonhead of chain job and data sets.
Once the workflow build completes, commands from the SYSIN file process the selected information.
Connections
Jobflow Illustrator reports the following connections:
COND
Identifies a conditional dependency.
DRJ
Identifies a data set is a requirement (prerequisite) for a job.
DTJ
Identifies a data set triggers job.
INDJRJ
Identifies a job is indirectly a requirement for a job. (See Note)
INDJTJ
Identifies a job indirectly triggers a job. (See Note)
JCD
Identifies a job creates a data set.
JRJ
Identifies a job is a requirement for a job.
JTJ
Identifies a job triggers a job.
NEGDEP
Identifies a negative dependency.
08-Feb-2018 246/722
REPEAT
Identifies a job that repeats.
Note: Indirect relationships are reported when the user selects the option not to display
data sets in the workflow. For example:
JOBA creates DSN1, which triggers JOBB. If data sets are not displayed in the workflow, JOBA shows
as indirectly triggering JOBB.
Building Parameters (PARMDEF DD Statement)

Building parameters tell Jobflow Illustrator how to build the workflow tables. Some parameters
(MAXJOBS, FROM, TO, SPAN, EXTRACT, QTIME) are global and relate to all workflow jobs. Other
parameters (JOB, JOBL, SCHID, SYS) select the head of chain jobs for the workflow. The remaining
parameters (JOBFILTER, JOBFILTRL, SCHFILTER, SYSFILTER) determine the jobs and data sets that are
triggered or requirements (prerequisites).
Global Building Parameters (see page 247)

Search Building Parameters (see page 250)
Filter Building Parameters (see page 252)
You can code parameters in columns 1 through 71. Separate the parameters with spaces or commas.
Use no space between the parameter keyword and value. Values containing spaces or commas must
be contained within parentheses. Typically, JOBL and JOBFILTRL work best with names of 50
characters or less in batch processing.
On a TYPE=CKPT start, the PARMDEF DD is ignored.
Note: All parameters in this topic can be overridden by coding them in the PARM field on
the EXEC statement.
Global Building Parameters

These parameters pertain to all jobs and data sets in the workflow.
MAXJOBS Parameter
This parameter has the following format:
[MAXJOBS={0|number}]
MAXJOBS
(Optional) Limits workflow processing to a maximum number of jobs. This limit helps when the
size of the workflow is unclear, and the user expects a limited number of jobs in the output.
MAXJOBS is useful when testing.
08-Feb-2018 247/722
MAXJOBS is useful when testing.

Default: 0 (no limit on the job number)
Limits: 1 - 9999999 (When Jobflow Illustrator exceeds this number of jobs, it stops processing and
sets return code 8.)
Example: Set MAXJOB Limit to 40 Jobs
Assume that you know that your weekend payroll cycle has only 20 jobs. Specifying the following
MAXJOBS avoids runaway processing when building parameters were coded incorrectly.
MAXJOBS=40
FROM Parameter
[FROM={current date,current time)|(mmyy,hhmm)|hhmm}]
FROM
(Optional) Specifies the beginning date and time of the workflow.
Default: Current date and time
(mmddyy,hhmm)
Defines the date and time.
mmddyy
Defines the calendar date of the beginning date of the workflow.
mm Defines the month. Leading zeros are required.
Limits: 01 - 12
dd Defines the day. A leading zero is required if less than 10.
Limits: 01 - 31
yy Defines the year.
hhmm
Defines the beginning time.
hh Defines the hour.
Limits: 00 - 23
mm Defines the minute.
Limits: 00 - 59
hhmm
Defines the beginning time. With this parameter, the current date is used.
hh
Defines the hour.
Limits: 00 - 23
mm
Defines the minute.
Limits: 00 - 59
TO Parameter
[TO={(mmddyy,hhmm)|hhmm}]
08-Feb-2018 248/722
[TO={(mmddyy,hhmm)|hhmm}]
TO
(Optional) Specifies the ending date and time of the workflow.
Limits: TO is mutually exclusive with SPAN.
(mmddyy,hhmm)
mmddyy
Defines the calendar date of the ending date of the workflow.
Limits: 01 - 12
Limits: 01 - 31
hhmm
Defines the ending time.
Limits: 00 - 23
Limits: 00 - 59
hhmm
Defines the ending time. With this parameter, the current date is used.
hh
Defines the hour.
Limits: 00 - 23
mm
Defines the minute.
Limits: 00 - 59
SPAN Parameter
[SPAN={00800|hhhmm}]
SPAN
(Optional) Specifies the length of the time interval (the duration) of the workflow. This value is
added to the FROM date and time to determine the ending date and time of the workflow.
Default: 00800 (8 hours and no minutes)
Limits: SPAN is mutually exclusive with TO.
hhhmm
Defines a time interval. hhh is a three-digit field, with leading zeros, if necessary. mm must be
two digits. The maximum duration of the span is 16800 (one week).
EXTRACT Parameter
08-Feb-2018 249/722
[EXTRACT={YES|NO}]
EXTRACT
(Optional) Specifies whether Jobflow Illustrator performs an initial extract of data from the
database or it starts with null tables. With null tables, flows are built from ADDJOB and ADDDS
commands.
YES (default)
Builds internal tables by extracting data from the database.
NO
Starts with null tables. JOB building parameters are not permitted with this option.
QTIME Parameter
[QTIME={HONOR|IGNORE}]
QTIME
(Optional) Specifies whether to use elapsed queue time (QTM) in determining the start time of a
triggered job.
HONOR (default)
Delays the start time of a triggered job by the amount of the queue time.
IGNORE
Ignores queue time when calculating start time.
Search Building Parameters

Jobflow Illustrator uses the parameters when searching the product database for scheduled jobs to
become heads of chains in the workflow.
JOB Parameter
[JOB={*|jobname|jobname*|job?ame|jo?name*|(jobname,nnn)}]
JOB
(Optional) Specifies search criteria for the names of scheduled jobs to become heads of chains in
the workflow.
Default: * (All jobs)
Limits: This parameter is not allowed with EXTRACT=NO.
jobname
Specifies a job name.
jobname*
Specifies a generic job name that is terminated with an asterisk.
job?ame
Specifies a generic job name that is masked in a single position.
jo?name*
08-Feb-2018 250/722
jo?name*
Specifies a combination job name that is masked in a single position and terminated with an
asterisk.
(jobname,nnn)
Specifies a job name with a specific one- to three-digit SCHID. If specified, the SCHID overrides
the SCHID parameter for this job.
Note: For inclusion in the output, the JOB or JOBL must match. Both can match, but a
match on both is not required.
JOBL Parameter
[JOBL={*|longjobname|longjobname*|longjob?ame|longjo?name*|(longjobname,nnn)}]
JOBL
(Optional) Specifies search criteria for the long job names of scheduled jobs to become heads of
chains in the workflow.
Default: * (All jobs)
Limits: 1 to 64 characters. This parameter is not allowed with EXTRACT=NO.
longjobname
Specifies a long job name.
longjobname*
Specifies a generic long job name that is terminated with an asterisk.
longjob?ame
Specifies a generic long job name that is masked in a single position.
longjo?name*
Specifies a combination long job name that is masked in a single position and terminated with
an asterisk.
(longjobname,nnn)
Specifies a long job name with a specific one- to three-digit SCHID. If specified, the SCHID
overrides the SCHID parameter for this job.
SCHID Parameter
[SCHID={0|nnn|(nnn,...,nnn)}]
08-Feb-2018 251/722
SCHID
(Optional) Defines the schedule ID value as the selection criteria for the jobs to be heads of chains
in the workflow. This parameter can be overridden by coding the ( jobname,nnn) format of the
JOB parameter.
Default: 0 (all schedule IDs)
nnn
Defines a one- to three-digit number.
Limits: 0 - 999
(nnn list)
Specifies a list of up to ten schedule ID numbers, which are enclosed in parentheses and
separated by commas.
SYS Parameter
[SYS={*|systemid|system*|(systemid,...,systemid)}]
SYS
(Optional) Specifies system name selection criteria for the jobs to be heads of chains in the
workflow.
Default: * (All system names)
systemid
Defines a system name. This value is a one- to eight-character alphanumeric field.
system*
Defines a generic system name that is terminated with an asterisk.
(systemid list)
Defines a list of up to ten system names, which are enclosed in parentheses and separated by
commas.
Filter Building Parameters

Jobflow Illustrator uses the parameters when running trigger and requirement chains. The
parameters determine whether to include jobs and data sets in the workflow.
JOBFILTER Parameter
[JOBFILTER={*|jobname|jobname*|job?ame|jo?name*|(jobname,nnn)}]
JOBFILTER
(Optional) Defines the criteria for selecting the nonhead of chain job names in the workflow.
Default: * (All job names)
jobname
Defines a job name.
jobname*
08-Feb-2018 252/722
jobname*
Defines a generic job name that is terminated with an asterisk.
job?ame
jo?name*
asterisk.
(jobname,nnn)
Defines a job name with a specific one- to three-digit SCHID. If specified, the SCHID overrides
the SCHID parameter for this job.
Note: For inclusion in the output, the JOBFILTER or JOBFILTRL must match. Both can
match, but a match on both is not required.
JOBFILTRL Parameter
[JOBFILTRL={*|longjobname|longjobname*|longjob?ame|longjo?name*|
(longjobname,nnn)}]
JOBFILTRL
(Optional) Defines the criteria for selecting the nonhead of chain long job names in the workflow.
Default: * (All long job names)
longjobname
Defines a long job name.
longjobname*
longjob?ame
longjo?name*
an asterisk.
(longjobname,nnn)
Defines a long job name with a specific one- to three-digit SCHID. If specified, the SCHID
overrides the SCHID parameter for this job.
08-Feb-2018 253/722
SCHFILTER Parameter
[SCHFILTER={0|nnn|(nnn,...nnn)}]
SCHFILTER
(Optional) Defines the criteria for selecting the nonhead of chain schedule ID values in the
workflow.
Default: 0 (All schedule IDs)
nnn
Defines a one- to three-digit number.
Limits: 0 - 999
(nnn list)
Defines a list of up to ten schedule ID numbers, which are enclosed in parentheses and
separated by commas.
SYSFILTER Parameter
[SYSFILTER={*|systemid|system*|(systemid,...,systemid)}]
SYSFILTER
(Optional) Defines the criteria for selecting the nonhead of chain system names in the workflow.
Default: * (All system names)
systemid
Specifies a system name. This value is a one- to eight-character alphanumeric field.
system*
(systemid list)
Defines a list of up to ten system names, which are enclosed in parentheses and separated by
commas.
Commands (SYSIN DD Statement)

After the workflow is built and saved in internal tables, Jobflow Illustrator looks at the SYSIN file for
commands on how to use the workflow.
Ad Hoc Commands (see page 255)

System Command (see page 255)
Output Command (see page 255)
Command Coding Rules (see page 255)
08-Feb-2018 254/722
Ad Hoc Commands
The three ad hoc commands are ADDJOB, ADDDS, and DELJOB. They add a job, add a data set, and
delete a job, respectively, to/from the workflow. When one or more ad hoc commands are
processed, a new workflow is generated before Jobflow Illustrator processes a system or an output
command.
The ad hoc commands, combined with the SAVE system command and TYPE=CKPT start, provide the
simulation, or what-if capability, of simulation mode.
Note: To save processing time, a new workflow is not generated after each ad hoc
command. If multiple ad hoc commands follow each other, they are processed. The jobs,
data sets, or both are added to the workflow as heads of chains. Jobs are delete(default)d
from the flow, one per DELJOB command. Only when a system or output command is
encountered are trigger and requirement chains run to generate a whole new workflow.
System Command
The system command, SAVE, writes workflow data to the checkpoint data set. If it is necessary to do
multiple saves, write each save to a different checkpoint data set.
Output Command
The output command, FLOWCHART, produces workflow output in two different formats.
FLOWCHART TYPE=PRINT produces a traditional flowchart with job and data set names in connected
boxes, suitable for printing. A keyword option can suppress the data set boxes and produces only
boxes with job names.
FLOWCHART TYPE=CSV produces a file of records consisting of comma-separated (CSV) fields. The file
is suitable for importing into a spreadsheet program. The first record is the field names (analogous to
column headings), and subsequent records are the data.
Command Coding Rules

The following rules specify command coding requirements:
Commands can be coded in columns 1-72 and can start in any column.
The command coding rules impose some limitations on the number and length of the long job
names that you can specify on the FLOWCHART command.
Commands can be continued on the following line when a comma follows the last keyword on the
line that is continuing.
No more than one command can be entered on a line.
An asterisk in column 1 signifies a comment.
08-Feb-2018 255/722
ADDJOB Command -- Add a Job

The ADDJOB command adds a job to the workflow as a head of chain.
The workflow that is generated before the next system or output command includes triggered and
requisite jobs and data sets related to this job.

ADDJOB {JOB=jobname|JOBL=longjobname}
[,START={(mmddyy,hhmm)|hhmm}]
[,END={(mmddyy,hhmm)|hhmm}]
[,SCHID={1|nnn}]
JOB
Specifies a job name to add to the workflow. This job becomes a head of chain.
Limits: 1-8 alphanumeric characters. The job name cannot be masked.
JOBL
Specifies a long job name to add to the workflow. This job becomes a head of chain.
Limits: 1-64 alphanumeric characters. The long job name cannot be masked.
START
(Optional) Specifies the date and time that the job begins.
Default: If START and END are omitted, The START value defaults to the date and time of the
build parameters in the PARMDEF file. If START is omitted and END is specified, the START date
and time are calculated from the END date/time.
(mmddyy,hhmm)
mmddyy
Defines the date.
Limits: 01 - 12
Limits: 01 - 31
hhmm
Defines the time.
Limits: 00 - 23
Limits: 00 - 59
hhmm
Defines the time. This parameter uses the current date.
hh
Defines the hour.
Limits: 00 - 23
08-Feb-2018 256/722
mm
Defines the minute.
Limits: 00 - 59
END
(Optional) Specifies the date and time for the job to end.
Default: If END is omitted, the date and time are calculated from the START date and time.
(mmddyy,hhmm)
mmddyy
Defines the date.
Limits: 01 - 12
Limits: 01 - 31
hhmm
Defines the time.
Limits: 00 - 23
Limits: 00 - 59
hhmm
hh
Defines the hour.
Limits: 00 - 23
mm
Defines the minute.
Limits: 00 - 59
SCHID
(Optional) Specifies the one- to three-digit schedule ID of the job being added to the workflow.
Default: 1
Limits: 1 - 999
ADDDS Command -- Add a Data Set

The ADDDS command adds a data set to the workflow. The main purpose of ADDDS is to satisfy
requirements.
ADDDS DSN=datasetname
08-Feb-2018 257/722
ADDDS DSN=datasetname
[,CREDT={(mmddyy,hhmm)|hhmm}]
[,SCHID={1|nnn}]
DSN
Defines a data set name to add to the workflow.
Limits: 1 - 44 characters
CREDT
(Optional) Specifies the date and time the data set was created.
Default: Current date and time
(mmddyy,hhmm)
mmddyy
Defines the date.
Limits: 01 - 12
Limits: 01 - 31
hhmm
Defines the time.
Limits: 00 - 23
Limits: 00 - 59
hhmm
hh
Defines the hour.
Limits: 00 - 23
mm
Defines the minute.
Limits: 00 - 59
SCHID
(Optional) Specifies the one- to three-digit schedule ID of the data set being added to the
workflow.
Note: If you are unsure about the schedule ID of a data set, the general rule is the data set
inherits the schedule ID of the job that creates it.
08-Feb-2018 258/722
Default: 1
Limits: 1 - 999
DELJOB Command -- Delete a Job

The DELJOB command deletes a job from the workflow.
Triggered and requisite jobs and data sets related to this job are deleted from the workflow that is
generated before the next system or output command.
If this job is a requisite for one or more jobs that are not in this job's trigger chain, this job is
converted to a soft object. A soft object is a placeholder with no SCHID.

DELJOB {JOB=jobname|JOBL=longjobname},SCHID={nnn|0}
[,START={(mmddyy,hhmm)|hhmm}]
[,END={(mmddyy,hhmm)|hhmm}]
[,FUZZ=nnn]
JOB
Specifies a job name to delete from the workflow.
Limits: 1-8 alphanumeric characters. The job name cannot be masked.
JOBL
Specifies a long job name to delete from the workflow.
Limits: 1-64 alphanumeric characters. The long job name cannot be masked.
SCHID
Specifies the schedule ID of the job being deleted from the workflow.
nnn
Specifies a one- to three-digit number.
Limits: 1 - 999
0
Specifies that any SCHID matches the criteria.
START
(Optional) Specifies the date and time that the job begins.
Limits: START or END is required, but both cannot be coded.
(mmddyy,hhmm)
mmddyy
Defines the date.
Limits: 01 - 12
Limits: 01 - 31
08-Feb-2018 259/722
hhmm
Defines the time.
Limits: 00 - 23
Limits: 00 - 59
hhmm
hh
Defines the hour.
Limits: 00 - 23
mm
Defines the minute.
Limits: 00 - 59
END
(Optional) Specifies the date and time that the job ends.
Limits: START or END is required, but both cannot be coded.
(mmddyy,hhmm)
mmddyy
Defines the date.
Limits: 01 - 12
Limits: 01 - 31
hhmm
Defines the time.
Limits: 00 - 23
Limits: 00 - 59
hhmm
hh
Defines the hour.
Limits: 00 - 23
08-Feb-2018 260/722
mm
Defines the minute.
Limits: 00 - 59
FUZZ
(Optional) Specifies the amount of time, plus or minus, in minutes, that the specified START/END
time can vary from the job's actual time for Jobflow Illustrator to consider the job to match the
time parameter.
Limits: 1 - 999
Example: Set FUZZ Parameter to 10 Minutes
The following example assumes that the start time of the job is 0853. If the parameters are coded as
follows, the job's start time matches because 0900 is within 10 minutes of 0853. Without the FUZZ
keyword, there would be no match because 0900 does not equal 0853.
START=0900,FUZZ=10
SAVE Command -- Write to the Checkpoint Data Set

The SAVE command writes the workflow to the checkpoint data set. Performing multiple saves to the
same data set overwrites previous data. Only data from the last save survives.
The correct way to do multiple saves is to use the DDNAME option and write each checkpoint to a
different data set.

SAVE [DDNAME={SAVE|ddname}]
DDNAME
(Optional) Defines a one- to eight-character ddname.
Default: SAVE
FLOWCHART Command -- Generate a Jobflow Illustrator Workflow

The FLOWCHART command generates a workflow from data in the internal tables and output in one
of two formats: print or CSV.
Print format is the traditional flowchart where information is presented in boxes with connecting
lines showing relationships. Print format flowcharts are sent to SYSOUT.
CSV format is sent to a data set. Commas separate the fields in each record. The first record in the file
contains the names of the fields. These names can be used as column headings. This data set is
suitable for importing into a program such as Microsoft Excel.

FLOWCHART=[TYPE={PRINT|CSV}]
[,JOB={(*|jobname|jobname*|job?ame|jo?name*)}]
[,JOBL={(*|longjobname|longjobname*|longjob?ame|longjo?name*)}]
[,JOBFILTER={(*|jobname|jobname*|job?ame|jo?name*)}]
[,JOBFILTRL={(*|longjobname|longjobname*|longjob?ame|longjo?name*)}]
[,SCHID={0|nnn|(nnn,...)}]
[,SYS={(*|systemid|system*,...)}]
08-Feb-2018 261/722
[,SYS={(*|systemid|system*,...)}]
[,SYSFILTER={(*|systemid|system*,...)}]
[,SCHFILTER={0|nnn|(nnn,...)}]
[,FROM={(mmddyy,hhmm)|hhmm}]
[,TO={(mmddyy,hhmm)|hhmm}]
[,SPAN=hhhmm]
[,OBJECT={ALL|JOB}]
[,CONTYPE={ALL|TRIG}]
[,LOOP={SHOW|NOSHOW}]
[,DDNAME={FLOWPRT|FLOWCSV|ddname}]
Note: All the preceding keywords (except for TYPE and DDNAME) are designed to limit the
output of the flowchart. The default command produces a flowchart containing all the
objects that were built using the criteria that the building parameters specify. The
preceding keywords can generate a subset of the total flow. If you want a flowchart
containing the total flow, omit them.
The following keywords are available for TYPE=PRINT only.

[,LRECL={133|nnn}]
[,LPPAGE={60|nnn}]
[,HDR={ONLY|ALL}]
[,BLANKP={SHOW|NOSHOW}]
[,TEXT={CA 7 Jobflow Illustrator|heading text}]
[,JOBBOX=(value,...)]
TYPE
(Optional) Describes the output format of the flowchart.
PRINT
Formats the flowchart for print, that is, jobs and data sets are represented in boxes that are
connected by lines depicting relationships. For more information about the printed output,
see FLOWCHART TYPE=PRINT Description (see page 274). This value is the default.
CSV
Formats the flowchart as records with fields separated by commas. For more information
about this format, see CSV Flowchart File Description (see page 269).
JOB
(Optional) Defines the jobs to use as heads of chains in the flowchart. A single entry does not
require parentheses.
Default: * (all job names)
jobname
Specifies a job name.
jobname*
Specifies a generic job name that is terminated with an asterisk.
job?ame
08-Feb-2018 262/722
jo?name*
asterisk.
JOBL
(Optional) Defines the long job names to use as heads of chains in the flowchart. A single entry
does not require parentheses.
Limits: 1 to 64 characters
Default: * (all long job names)
longjobname
Specifies a long job name.
longjobname*
Specifies a generic long job name that is terminated with an asterisk.
longjob?ame
longjo?name*
an asterisk.
JOBFILTER
(Optional) Defines the criteria for selecting the non-head of chain job names in the workflow. A
single entry does not require parentheses.
Default: * (all job names)
jobname
Defines a job name.
jobname*
job?ame
jo?name*
asterisk.
08-Feb-2018 263/722
JOBFILTRL
(Optional) Defines the criteria for selecting the non-head of chain long job names in the workflow.
A single entry does not require parentheses.
Limits: 1 to 64 characters
Default: * (all long job names)
longjobname
Defines a long job name.
longjobname*
Defines a generic long job name that is terminated with an asterisk.
longjob?ame
longjo?name*
an asterisk.
SCHID
(Optional) Defines the one- to three-digit schedule ID value as a selection criterion for the head of
chain jobs in the flowchart. A single entry does not require parentheses.
Limits: 0 - 999
SYS
(Optional) Defines the systems as selection criteria for the head of chain jobs in the flowchart. A
single entry does not require parentheses.
Default: * (all system names)
systemid
Defines a system name. This name is a one- to eight-character alphanumeric field.
system*
SYSFILTER
(Optional) Defines the criteria for selecting the non-head of chain system names in the workflow.
A single entry does not require parentheses.
Default: * (all system names)
systemid
Defines a system name. This name is a one- to eight-character alphanumeric field.
08-Feb-2018 264/722
system*
SCHFILTER
(Optional) Defines the criteria for selecting the non-head of chain schedule IDs in the workflow
(one- to three-digits). A single entry does not require parentheses.
Limits: 0 - 999
FROM
(Optional) Defines the earliest end date and time for jobs that are selected for display in the
flowchart.
Default: FROM time that the PARMDEF build parameter specifies.
(mmddyy,hhmm)
mmddyy
Defines the date.
Limits: 01 - 12
Limits: 01 - 31
hhmm
Defines the time.
Limits: 00 - 23
Limits: 00 - 59
hhmm
hh
Defines the hour.
Limits: 00 - 23
mm
Defines the minute.
Limits: 00 - 59
TO
(Optional) Defines the latest end date and time for jobs that are selected for display in the
flowchart.
Default: TO time specified in the PARMDEF build parameter or calculated using the from time and
span.
Limits: TO is mutually exclusive with SPAN.
(mmddyy,hhmm)
08-Feb-2018 265/722
(mmddyy,hhmm)
mmddyy
Defines the date.
Limits: 01 - 12
Limits: 01 - 31
hhmm
Defines the time.
Limits: 00 - 23
Limits: 00 - 59
hhmm
hh
Defines the hour.
Limits: 00 - 23
mm
Defines the minute.
Limits: 00 - 59
SPAN
(Optional) Defines the length of the time interval (that is, the duration) of the workflow.
Default: None. If omitted, the span is calculated from the from and to times.
Limits: SPAN is mutually exclusive with TO.
hhhmm
1. hhh
Indicates a three-digit field, with leading zeros, if necessary.
mm
Indicates two digits.
The maximum duration of the span is 16800, which is one week.
OBJECT
(Optional) Defines which objects to place in the flowchart boxes: jobs and data sets or jobs only.
ALL
Specifies to display both jobs and data sets in boxes on the flowchart. This value is the default.
JOB
08-Feb-2018 266/722
JOB
Specifies to display only jobs in boxes on the flowchart. An exception is made for data sets
that are heads of a chain, which are displayed. Connections that would involve a data set in an
intermediate relationship are shown as indirect connections.
CONTYPE
(Optional) Defines whether to display requirement connections on the flowchart.
ALL
Displays all connections on the flowchart. This value is the default.
TRIG
Displays only trigger and repeating connections on the flowchart. This display includes job
creates data set connections.
LOOP
(Optional) Sets display options for jobs that are part of a trigger loop.
SHOW
Specifies to show that a job is part of a trigger loop. This value is the default.
NOSHOW
Specifies not to show that a job is part of a trigger loop.
DDNAME
(Optional) Defines the ddname to which the flowchart is written.
FLOWPRT
Specifies the standard ddname for FLOWCHART TYPE=PRINT. The ddname has the attributes
of SYSOUT (RECFM=FBA, LRECL=133). Use of the LRECL parameter can override the LRECL.
This value is the default.
FLOWCSV
Specifies the standard ddname for FLOWCHART TYPE=CSV. The ddname has the following DCB
attributes: RECFM=VB, LRECL=1000.
ddname
Defines a different ddname to use from the two listed previously. The DCB attributes must
match those attributes that are listed for FLOWPRT for TYPE=PRINT or for FLOWCSV for
TYPE=CSV, or a system error sometimes occurs.
LRECL
(Optional) Defines the number of horizontal characters per page of the printed flowchart. This
number includes a printer carriage control character. This number can be used when using a
nonstandard printer font.
Default: 133
Limits: 20 - 999
LPPAGE
(Optional) Describes the number of lines per page on the printed flowchart.
Default: 60
Limits: 10 - 999
HDR
08-Feb-2018 267/722
HDR
(Optional) Describes whether to print the heading text on only the top pages of the flowchart or
on every page of the flowchart.
ONLY
Specifies to print the heading text on only the top pages (PAGE 001. nnn) of the flowchart. This
value is the default.
ALL
Specifies to print the heading text on all pages of the flowchart.
BLANKP
(Optional) Describes whether to print blank pages.
SHOW
Specifies to print blank pages. This value is the default.
NOSHOW
Specifies not to print blank pages.
TEXT
(Optional) Contains the text of the page heading.
Default: (CA 7 Jobflow Illustrator)
Limits: 1 - 68 characters that are enclosed in parentheses
JOBBOX
(Optional) Describes which options to show in the job boxes on the printed flowcharts. If more
than one option is selected, they must be enclosed in parentheses. Up to four of the listed
options can be selected. If more than four are coded, an error message is generated and return
code 8 is set.
BEGIN
Specifies to display the begin date and time.
END
Specifies to display the end date and time.
DRCLASS
Specifies to display the disaster recovery class.
JOBNET
Specifies to display the job network name.
MAINID
Specifies to display the main ID (CPU on which the job can or cannot be scheduled).
SYSTEM
Specifies to display the system name.
WLB
Specifies to display the workload balancing class.
08-Feb-2018 268/722
WLP
Specifies to display the workload balancing priority.
CSV Flowchart File Description

The comma-separated value (CSV) flowchart file consists of records that are composed of fields that
commas separate. The records represent the workflow as it is kept in two internal tables. The five
types of records are as follows:
Header record, whose fields contain the field name. This record is analogous to a spreadsheet
column heading.
JOB record, which describes a job object
DSN record, which describes a data set object
XCN record, which describes a connection between two objects
Commas separate fields in each record. Each field has a value that is enclosed in double quotes or
simply a pair of double quotes. Not all records have the same number of fields. The first record in the
file is the header record, which contains the names of the fields. These names can be used as column
headings.
This data set is suitable for importing into a program like Microsoft Excel.
Fields (Columns)
These descriptions describe the fields of the CSV file. The row type describes which types of records
the field applies to. Length is the length of the field value and does not include the double quotes.
Rel_Number
Indicates the row number of the object in internal output table.
Row type: JOB, DSN, XCN
Length: 8
Row_Type
Indicates one of the following:
JOB if the object being described is a job in the output table.
DSN if the object being described is a data set in the output table
XCN if this item is a connection record.
Row type: JOB, DSN, XCN

Length: 4
08-Feb-2018 269/722
XCN_Conn_Type
Indicates PR if the connection type is a prerequisite, TR for trigger, RP for repeat, and ID for an
indirect connection.
Row type: XCN
Length: 3
XCN_Conn_SubType
Indicates NEG if the connection relationship is a negative dependency. COND if the connection
relationship is a conditional dependency.
Row type: XCN
Length: 4
XCN_Fwd_Rel_Number
Indicates the number of the forward connection output entry (that is, the Rel_Number field of the
connected object).
Row type: XCN
Length: 8
Fwd_Conn_Count
Indicates the number of forward connections for this object.
Row type: JOB, DSN
Length: 5
Job_Name
Indicates the name of the job.
Row type: JOB
Length: 8
Schid
Indicates the CA Workload Automation CA 7® Edition schedule ID.
Row type: JOB, DSN
Length: 5
DS_Name
Indicates the name of the data set.
Row type: DSN
Length: 44
DS_Number
Indicates the schedule data set number.
Row type: DSN
Length: 10
Job_System
Indicates the system name (jobset).
Row type: JOB
Length: 8
Job_Jobnet
Indicates the job network name.
Row type: JOB
Length: 8
08-Feb-2018 270/722
Hidden_Conn
Indicates whether the job/data set has hidden connections (Y or N). The hidden connections are
trigger or dependency connections to objects that are not included in the workflow because of
date and time criteria or selection filters.
Row type: JOB, DSN
Length: 1
Soft_Flag
Indicates whether this job is a soft object (Y or N). A soft object is one that does not have a
starting/creation point in the current workflow. For jobs, these are jobs that are dependency
predecessors to one or more jobs in the workflow, but there is no date and time schedule or
trigger in the workflow to define when the soft job runs. For data sets, these are data sets that
are dependency predecessors to one or more jobs in the workflow, but none of the jobs in the
workflow create that data set, so there is no way to tell when that creation occurs.
Row type: JOB, DSN
Length: 1
Job_Head
Indicates whether this job is the head of a chain (Y or N).
Row type: JOB
Length: 1
Job_Start_Date
Indicates the target begin date in Julian format (yyyyddd).
Row type: JOB
Length: 7
Job_Start_Time
Indicates the target begin time of day in hh:mm:ss format.
Row type: JOB
Length: 8
Job_End_Date
Indicates the target end date in Julian format (yyyyddd).
Row type: JOB
Length: 7
Job_End_Time
Indicates the target end time of day in hh:mm:ss format.
Row type: JOB
Length: 8
Job_Avg_Elapsed
Indicates the job lead time or average run time in hh:mm:ss format.
Row type: JOB
Length: 8
Job_Mainid
Indicates the CPU on which the job can or cannot be scheduled.
Row type: JOB
Length: 8
08-Feb-2018 271/722
Job_DR_Class
Indicates the job disaster recovery class.
Row type: JOB
Length: 8
Job_WLB_Class
Indicates the job workload balancing class.
Row type: JOB
Length: 1
Job_Maint_Flag
Indicates whether the job is a MAINT job (Y or N).
Row type: JOB
Length: 1
Job_Xplat_Target
Reserved for future use.
Row type: JOB
Length: 64
Job_Xplat_Flag
Indicates whether the job is an XPJOB job (Y or N). If the CA 7® Web Client flags the job as a
CA7TOUNI job, this field is also a Y after the next cycle.
Row type: JOB
Length: 1
Job_Nonexec_Flag
Indicates whether the job is marked as EXEC=NO (Y or N).
Row type: JOB
Length: 1
Job_Verify_Flag
Indicates whether the job is marked as VERIFY=YES (Y or N).
Row type: JOB
Length: 1
Job_Locked_Flag
Indicates whether the job is locked (Y or N).
Row type: JOB
Length: 1
Job_Hold_Flag
Indicates whether the job is marked as HOLD=YES (Y or N).
Row type: JOB
Length: 1
Job_JCLOverride_Flag
Indicates whether the job is marked as OVERRIDE=YES (Y or N).
Row type: JOB
Length: 1
08-Feb-2018 272/722
Job_Trig_Job_Flag
Indicates whether the job triggers one or more other jobs (Y or N).
Row type: JOB
Length: 1
Job_Trig_Loop_Flag
Indicates N unless both of the following conditions are met, then Y:
LOOP=NOSHOW is specified.
The job is triggered and is a duplicate (jobname/schid) of another job in the trigger path of a
chain. For example:
JOBA/001 triggers JOBB/001 triggers JOBA/001. The second JOBA is a duplicate.
Row type: JOB

Length: 1
DS_Perm_Flag
Indicates whether the data set is marked permanent (Y or N).
Row type: DSN
Length: 1
DS_Internal_Flag
Indicates whether the data set is marked internal (Y or N).
Row type: DSN
Length: 1
DS_Cpost_Flag
Indicates whether the data set is posted at creation time (Y or N).
Row type: DSN
Length: 1
DS_Auto_Flag
Indicates whether the data set is AUTO type (Y or N).
Row type: DSN
Length: 1
DS_GDG_Flag
Indicates whether the data set is a GDG (Y or N).
Row type: DSN
Length: 1
Manual_Add
Indicates whether this object was manually added to the flow using an ADDJOB or ADDDS
command (Y or N).
Row type: JOB, DSN
Length: 1
Job_WLB_Priority
Indicates the job workload balancing priority.
Row type: JOB
Length: 3
08-Feb-2018 273/722
Job_Type
Indicates the type of job, regular (JOB), cross-platform or CA7TOUNI (XPJ), or Agent (for example,
WIN, FTP, SAP, FTRG).
Row type: JOB
Length: 4
Job_User_Rqmt_Cnt
Indicates the user requirement count.
Row type: JOB
Length: 3
Job_Name_Long
Indicates the long job name associated with the job.
Row type: JOB
Length: 64
More information:
CA 7 Agent Job Types (https://wiki.ca.com/display/CWAC7E/CA+7+Agent+Job+Types)
FLOWCHART TYPE=PRINT Description

A printed flowchart has the following types of objects: jobs, data sets, pointers, dependencies, and
connections. Pages are numbered going across, and then down. Page 001.002 is immediately to the
right of page 001.001. Page 002.001 is immediately under page 001.001.
Jobs (see page 274)

Data Sets (see page 275)
Pointers (see page 276)
Dependencies (see page 277)
Connections (see page 277)
Jobs
A job object can look like the following sample:
J--------------+
| jobname /nnn |
| |
| |
| |
| |
+--------------+
The J in the upper left corner indicates that this box represents a job. The job name and schedule ID
are displayed on the first line in the box.
The box can display certain attributes of the job. The JOBBOX keyword on the FLOWCHART command
controls the attributes to display.
08-Feb-2018 274/722
For example, if JOBBOX=(SYSTEM,BEGIN,END,MAINID) is specified, a job can look like the following
sample:
J--------------+
| PAYME01 /001 |
|SYS=SYSTNAME |
|BEG=09090/0759|
|END=09090/0800|
|MNID=ALL |
+--------------+
Additional job attributes are placed automatically on the top or bottom lines of the box when
appropriate:
If the job is marked as maintenance only, MAINT is placed on the top line on the left.
J-MAINT--------+
If the job is not a MAINT job and has user requirements, USR is placed on the top line on the left.
J-USR----------+
If the job is marked as non-executable, NOEX is placed on the top line on the right.
J---------NOEX-+
If the job is marked as a cross-platform job (XPJOB, CA7TOUNI, or agent job), the 3-4 character
job type is placed on the bottom line on the left. For example, a CA Workload Automation CA 7
Edition FTP agent job shows the following job type:
+FTP-----------+
If the job was manually added to the flow as the result of an ADDJOB command, MA is placed on
the bottom line on the right.
+-------MA-----+
If the job is not scheduled or triggered, but is a requirement of another job that is scheduled or
triggered, the predecessor job is marked with SOFT on the bottom line on the right.
+----------SOFT+
Data Sets
A data set object sometimes looks like the following sample:
D--------------+
|xxxxxxxx.xxxxx|
|xxx.xxxxxxxx.x|
|xxxxxxx.xxxxxx|
|xx |
|N=DSnnnnnnnn |
+--------------+
The D in the upper left corner indicates that this box represents a data set. The data set name and its
data set number are displayed in the box.
Additional data set attributes are added automatically when appropriate:
If the data set is part of a generation data group, GDG is placed on the top line on the right.
D----------GDG-+
08-Feb-2018 275/722
D----------GDG-+
If the data set is marked to be posted at creation, POST is placed on the line above the data set
number, right-justified.
If the data set is marked as external, EXT is placed on the bottom line on the left.
+EXT-----------+
If the data set was manually added to the flow as the result of an ADDDS command, MA is placed
on the bottom line on the right.
+-------MA-----+
If the data set is not created by any scheduled or triggered job, but is a requirement for a job that
is scheduled or triggered, SOFT is placed on the bottom line on the right.
+----------SOFT+
Pointers
A pointer object is shown in a flowchart when a job or data set appears more than once. The first
time a job or data set is shown, it appears as a normal job or data set object, as described previously.
A pointer is shown in all other places where the job or data set is referenced. A pointer for a job looks
like the following example:
J------*-------+
jobname /nnn
tag>>>xxx.yyy
The name of the job and schedule ID are shown. The tag is a unique three-digit number to help you
find the original object. The xxx.yyy is the page number on which you can find the tag number. The
tag number is on the connection immediately above the object. For example, if the pointer shows the
following example:
J------*-------+
PAYME05 /000
002>>>001.001
On page 001.001 is a tag of 002 pointing to job PAYME05, like the following example:
002>>>+
+
J------*-------+
| PAYME05 /000 |
| |
| |
| |
| |
+--------------+
A special type of pointer can be displayed when a never-ending trigger loop is detected. An example
of a trigger loop is JOBA schedule ID 1 triggers JOBB schedule ID 1, which triggers JOBA schedule ID 1
again. Instead of a tag and page number, the word LOOP is displayed.
J------*-------+
| jobname /nnn |
| ********** |
| ** LOOP ** |
| ********** |
| |
+--------------+
08-Feb-2018 276/722
Dependencies
A dependency is shown without any indication of when the job runs. A dependency is exhibited only
to let the viewer know that a dependency exists. Both negative and conditional dependencies are
shown. No additional information about the job is displayed:
J------*-------+
jobname /nnn
The job may not appear elsewhere in the flowchart.
Connections
Connections show the relationships between the objects in the flowchart. The connections always go
down and to the right.
The connection is labeled to show the type of connection. The character that is used to print the
connection can also indicate the type of connection. In general, the vertical bar (|) is used for
triggers, repeats, and data set creation. The plus sign (+) is used for requirements. X is used for
dependencies. If more than one type of connection is being shown, the vertical bar (|) is used.
The following types of connections are shown:
COND
Identifies a conditional dependency.
DRJ
Identifies a data set required by job.
DTJ
Identifies a data set that triggers a job.
INDJRJ
Identifies a job that the job requires indirectly. This connection type is shown only when data sets
are being excluded from the display. If JOBA creates data set X and JOBB requires data set X, the
flowchart shows JOBA as an indirect requirement of JOBB.
INDJTJ
Identifies a job that triggers a job indirectly. This connection type is shown only when data sets
are being excluded from the display. If JOBA creates data set X and data set X triggers JOBB, the
flowchart shows JOBA indirectly triggering JOBB.
JCD
Identifies a job that creates data set.
JRJ
Identifies a job that another job requires.
JTJ
Identifies a job that triggers a job.
NEGDEP
Identifies a negative dependency.
REPEAT
08-Feb-2018 277/722
REPEAT
Identifies a job that repeats itself.
Connections can look like the following example:

D------*-------+
|COMPANY.DAILY.|
|PAYME02 |
| |
| |
|N=DS00000316 |
+------*-------+
|
|
|
|
*-----------------*-----------------*-----------------*
| | + +
|DTJ |DTJ +DRJ +DRJ
001>>>| 002>>>| + +
| | + +
J------*-------+ J------*-------+ J------*-------+ J------*-------+
| PAYME03/002 | | PAYME04/002 | PAYME03/002 PAYME04/002
|BEG=09090/0900| |BEG=09090/0901| 001>>>001.001 002>>>001.001
|END=09090/0901| |END=09090/0902|
| | | |
| | | |
+--------------+ +--------------+
This example shows when data set COMPANY.DAILY.PAYME02 is updated, jobs PAYME03 and
PAYME04 are triggered (DTJ = Data set Triggers Job). These jobs also have a data set dependency of
the data set (DRJ = Data set Required by Job).
Implement Jobflow Illustrator

You can start Jobflow Illustrator as a batch job.
Communication with CA 7 (see page 278)

Sample User JCL (see page 278)
Input DD Statements (see page 279)
Output DD Statements (see page 279)
Dynamically Allocated DD Statements (see page 280)
Communication with CA 7
Jobflow Illustrator uses CAICCI to communicate with CA Workload Automation CA 7® Edition. To work
correctly, the CA 7 instance to which the workflow relates must be up and running.
The Jobflow Illustrator job must run on an LPAR that can communicate with the appropriate CA 7
instance.
Sample User JCL

A sample JCL procedure for executing the Jobflow Illustrator is in the JCLLIB member CA7FSIM. The
prefix sometimes changes based on the SYSGEN process.
The DD statements are described in the next topic.
08-Feb-2018 278/722
Input DD Statements
The following are the Jobflow Illustrator input DD statements:
STEPLIB
Specifies the CA Workload Automation CA 7® Edition and CA Datacom/AD execution libraries. The
libraries that are specified on this STEPLIB must match the libraries that are specified in your CA 7
online execution JCL.
CHKPOINT
Specifies the Jobflow Illustrator checkpoint data set to read. Required only if a TYPE=CKPT start is
being done. If the CKPTDDN initialization parameter is specified, this name can be a different
ddname.
INITDEF
Identifies the source of initialization parameters or identifies the data set containing the
initialization parameters. This statement is required.
PARMDEF
Identifies the source of building parameters or identifies the data set containing the building
parameters. This statement is required for TYPE=COLD start and ignored for TYPE=CKPT start.
SYSIN
Identifies the source of control statements or identifies the data set containing the control
statements. This statement is required.
Output DD Statements
The following items are the Jobflow Illustrator output DD statements:
SAVE
Specifies the data set where a checkpoint file is saved. This statement is required if the SAVE
command statement is specified. The value can be a different ddname if the DDNAME option is
specified on the SAVE command statement.
FLOWCSV
Specifies the data set where a comma-separated value file is written. This statement is required if
the FLOWCHART TYPE=CSV command statement is specified. The value can be a different
ddname if the DDNAME option is specified on the FLOWCHART command statement.
FLOWPRT
Specifies SYSOUT or the file where a flowchart is printed. This statement is required if the
FLOWCHART TYPE=PRINT command statement is specified. The value can be a different ddname
when the DDNAME option is specified on the FLOWCHART command statement.
SYSMSGS
Specifies SYSOUT or the file to which Jobflow Illustrator messages are written. This statement is
required if Jobflow Illustrator is being run as a batch job. Recommended if a calling program is
executing Jobflow Illustrator, but in this case, SYSMSGS can be omitted. If omitted, SYSMSGS is
dynamically allocated, and the default SYSOUT class is used.
08-Feb-2018 279/722
SYSUSNAP
(Optional) Specifies SYSOUT or the file where SNAPs are written when some error conditions
generate return code 8 or higher.
SYSUDUMP
(Optional) Specifies SYSOUT or the file where a dump is written in the case of an abend.
Dynamically Allocated DD Statements

DBPARMS is the Jobflow Illustrator dynamically allocated DD statement:
DBPARMS
Defines the logical database name. Jobflow Illustrator allocates dynamically the same DBPARMS
data set as the associated CA 7 online instance.
To allocate the DBPARMS data set dynamically, it must be a permanent data set, residing on
DASD. DD DUMMY must not be specified in the CA Workload Automation CA 7 Edition JCL.
Initialization Parameters (INITDEF DD Statement)

The initialization parameters used by Jobflow Illustrator have no relationship to those parameters
used by CA Workload Automation CA 7® Edition. Any names or options that match are coincidental
and have no effect on CA Workload Automation CA 7 Edition.
You can code parameters in columns 1 through 71. Separate parameters with spaces or commas. No
space is used between the parameter keyword and value.
Note: All of the parameters in this topic can be overridden by coding them in the PARM
field on the EXEC statement.
TYPE Parameter
The TYPE parameter has the following format:
[TYPE={COLD|CKPT}]
TYPE
(Optional) Specifies the method of starting Jobflow Illustrator.
COLD
Specifies that Jobflow Illustrator uses the building parameters specified in the PARMDEF file
and information from a CA Workload Automation CA 7 Edition database to build a workflow.
CKPT
Specifies that Jobflow Illustrator ignores the PARMDEF file and read the data set pointed to by
the CHKPOINT DD. The checkpoint data is used as input to build a workflow. The database is
not read when building the workflow.
08-Feb-2018 280/722
CA7 Parameter
The CA7 parameter has the following format:
[CA7={CA71|CA7n|alias}]
CA7
(Optional) Specifies the CA 7instance that the workflow models.
CA71
Maps to what used to be known as the production copy of CA Workload Automation CA 7
Edition. This value is the default.
CA7n
CA7n specifies the CA 7 instance with which to connect. n can be an integer from 1 through 8.
alias
Defines a one- to four-character alias. This alias must correspond to an alias assigned to a CA 7
instance during CA Workload Automation CA 7 Edition initialization by CAIRIM.
LOGON Parameter
The LOGON parameter has the following format:
[LOGON={submitter ID|operatorid}]
LOGON
(Optional) Specifies the operator identification required to log on to the CA 7 instance that the
workflow models. This parameter is typically coded for a TYPE=COLD start.
Note: This information is not saved to the checkpoint data set during a SAVE operation.
During a TYPE=CKPT start, it is not necessary to code a LOGON parameter unless accessing
the CA Workload Automation CA 7 Edition database with an ad hoc (ADDJOB, ADDDS, or
DELJOB) command.
Default: The submitter ID of the person who is running Jobflow Illustrator. If a batch job was run,
this ID is typically the TSO ID of the submitter. If a program called Jobflow Illustrator, the ACEE of
the address space returned by SAF determines this field.
operatorid
Defines a one- to eight-character field.
CA7PASS Parameter
The CA7PASS parameter has the following format:
[CA7PASS=password]
CA7PASS
(Optional) Specifies the one- to eight-character password required to log on to the CA 7 instance
that the workflow models. This field is not always necessary depending on your site
requirements. The keyword has no default. The password is encrypted internally.
The following is applicable only if your site requires a password to log on to CA Workload
08-Feb-2018 281/722
The following is applicable only if your site requires a password to log on to CA Workload
Automation CA 7 Edition: This information is not saved to the checkpoint data set during a SAVE
operation. During a TYPE=CKPT start, it is not necessary to code a CA7PASS parameter unless
accessing the CA Workload Automation CA 7 Edition database with an on demand (ADDJOB,
ADDDS, or DELJOB) command.
SIZE Parameter
The SIZE parameter has the following format:
[SIZE={SMALL|MEDIUM|LARGE}]
SIZE
(Optional) Provides Jobflow Illustrator an estimate of the size of the flow. With this estimate, the
internal tables are built with an appropriate size to facilitate processing.
SMALL
Estimates that the flow contains less than 10,000 jobs. If the flow size is unknown, use this
default size. This value is the default.
MEDIUM
Estimates that the flow contains from 10,000 to 100,000 jobs.
LARGE
Estimates that the flow contains over 100,000 jobs.
NODE Parameter
The NODE parameter has the following format:
[NODE={localnode|crossnode|*AUTO*}]
NODE
(Optional) Specifies the CAICCI node where the copy of CA Workload Automation CA 7 Edition
that is being modeled is executing. If that copy executes on the local node, the parameter is not
needed.
Default: The local CAICCI node.
crossnode
Defines a one-to eight-character field.
*AUTO*
Specifies that the CAICCI interface tries dynamically to locate the CAICCI node where a CA
Workload Automation CA 7 Edition with a matching instance name resides.
Note: For more information, see RECEIVER Parameter.
RECEIVER Parameter
The RECEIVER parameter has the following format:
[RECEIVER={instance|suffix}]
08-Feb-2018 282/722
RECEIVER
(Optional) Specifies the one- to four-character CAICCI suffix when it is not the same as on the
local node.
Default: The name of the CA 7 instance that is being modeled.
Note: You can set the name used to identify the CAICCI receiver for a given copy of CA
Workload Automation CA 7 Edition as follows:
This setting lets each copy of CA Workload Automation CA 7 Edition be unique across a
CAICCI network even though more than one copy can have the same instance name.
Assignment of unique CAICCI receiver names lets you use the NODE=*AUTO* parameter
to target dynamically a specific copy of CA Workload Automation CA 7 Edition.
CKPTDDN Parameter
The CKPTDDN parameter has the following format:
[CKPTDDN={CHKPOINT|ddname}]
CKPTDDN
(Optional) Specifies the one- to eight-character ddname of the checkpoint data set to read during
a TYPE=CKPT start.
Default: CHKPOINT
Jobflow Illustrator JCL Examples

The following JCL examples can help you understand the Jobflow Illustrator process.
Example 1: Cold Start (see page 283)

Example 2: Checkpoint Start and CSV Flowchart (see page 284)
Example 3: Null Table Cold Start, Multiple Checkpoints (see page 284)
Example 4: Delete Job and Print Flowchart to DASD (see page 285)
Example 1: Cold Start

In this example, Jobflow Illustrator starts typically with a COLD start. The default PARM of
MAXJOBS=0 is overridden with an EXEC PARM of MAXJOBS=100. The internal tables are built with CA
Workload Automation CA 7® Edition database data specified using the building parameters in the
PARMDEF DD statement. The table data is then saved to the data set described by the SAVE DD
statement (SAVE command). Next, the workflow is printed in flowchart format to SYSOUT, as
specified by the FLOWPRT DD statement (FLOWCHART TYPE=PRINT command).
//jobname JOB (accounting)
//JS010 EXEC PGM=CAL2FSIM,PARM='MAXJOBS=100'
//SAVE DD DSN=ckpt.data.set.name,
// DISP=(NEW,CATLG,DELETE),
// SPACE=(CYL,(1,1)),UNIT=SYSALLDA,
// DCB=(RECFM=VB,LRECL=724,BLKSIZE=0)
//FLOWPRT DD SYSOUT=*
//SYSMSGS DD SYSOUT=*
//SYSUSNAP DD SYSOUT=*
//INITDEF DD *
08-Feb-2018 283/722
//INITDEF DD *
TYPE=COLD
CA7=CA74
LOGON=USER
CA7PASS=USERPASS
/*
//PARMDEF DD *
FROM=(033109,0001)
TO=(033109,1800)
SYS=*
SCHID=(1,2,4)
JOB=PAY*
JOBFILTER=PAYME*
JOBFILTER=(PAYYOU*,2)
JOBFILTER=(PAYUS*,1)
JOBFILTER=(PAYUS*,2)
/*
//SYSIN DD *
SAVE
FLOWCHART TYPE=PRINT
//
Example 2: Checkpoint Start and CSV Flowchart

In this example, Jobflow Illustrator starts with a CKPT start, reading data from the checkpoint data set
created in Example 1 and described by the CHKPOINT DD statement. Because no ad hoc commands
are being performed, the LOGON parameter in the INITDEF file is not required.
Next, a workflow in comma-separated value format is written to the data set defined by DD
statement FLOWCSV (command FLOWCHART TYPE=CSV).
//JS010 EXEC PGM=CAL2FSIM
//CHKPOINT DD DSN=ckpt.data.set.name,DISP=SHR
//FLOWCSV DD DSN=csv.data.set.name,
// SPACE=(TRK,(1,1)),UNIT=SYSALLDA,
//INITDEF DD *
TYPE=CKPT
/*
//SYSIN DD *
FLOWCHART TYPE=CSV
//
Example 3: Null Table Cold Start, Multiple Checkpoints

In this example, Jobflow Illustrator initializes its tables using data from the PARMDEF file. Jobflow
Illustrator does not read any information from the CA Workload Automation CA 7 Edition instance
CA74 database (because of parameter EXTRACT=NO).
After table initialization is accomplished, workflow data is saved to the checkpoint data set defined
by DD CHKPOIN1. Then, using only the internal tables, job PAYME01 is added as a head of chain
(command ADDJOB). Data set company.DAILY.PAYME01, which is a requisite of PAYME01, is added to
the tables (command ADDDS). Because the subsequent command, SAVE, is a system command, a
workflow is generated. Jobs and data sets in the database that are triggered and are requisites that
meet the start/end/SCHID criteria are included.
08-Feb-2018 284/722
Next, the modified workflow is saved to the checkpoint data set defined by DD CHKPOIN2. Next, the
workflow is printed to SYSOUT as specified by DD MYPRINT (command FLOWCHART TYPE=PRINT).
//CHKPOIN1 DD DSN=ckpt1.data.set.name,
//CHKPOIN2 DD DSN=ckpt2.data.set.name,
//MYPRINT DD SYSOUT=*
//INITDEF DD *
CA7=CA74,LOGON=USER,CA7PASS=USERPASS
/*
//PARMDEF DD *
FROM=(033109,1700)
TO=(033109,1900)
SCHID=2
EXTRACT=NO
/*
//SYSIN DD *
SAVE DDNAME=CHKPOIN1
ADDJOB JOB=PAYME01,START=(033109,1730),
END=(033109,1800),SCHID=2
ADDDS DSN=company.DAILY.PAYME01,
CREDT=(033109,1700),SCHID=2
SAVE DDNAME=CHKPOIN2
FLOWCHART TYPE=PRINT,DDNAME=MYPRINT
//
Example 4: Delete Job and Print Flowchart to DASD

In this example, Jobflow Illustrator builds a workflow with a span of 24 hours. The flow is expected to
contain approximately 22,000 jobs. After table initialization is accomplished, job PAYME05 with
SCHID=2 is deleted from the flow if it starts from 1235 through 1255. So are all jobs that it triggers
and all related requirements (command DELJOB).
Next, Jobflow Illustrator writes a print flowchart to a DASD data set. The flowchart has more than the
usual number of rows and columns per page (command FLOWCHART).
//FLOWPRT DD DSN=print.data.set.name,
// SPACE=(TRK,(2,1)),UNIT=SYSALLDA,
// DCB=(RECFM=FBM,LRECL=200,BLKSIZE=0)
//INITDEF DD *
CA7=CA74
LOGON=USER
CA7PASS=USERPASS
SIZE=MEDIUM
/*
//PARMDEF DD *
FROM=(033109,0001)
JOB=PAY*
/*
08-Feb-2018 285/722
/*
//SYSIN DD *
DELJOB JOB=PAYME05,START=(033109,1245),
SCHID=2,FUZZ=10
FLOWCHART LRECL=200,LPPAGE=100
//
Sample FLOWCHART TYPE=CSV File (Partial)

The following is a sample of comma-separated values for the FLOWCHART TYPE=CSV File:
"Rel_Number","Row_Type","XCN_Conn_Type","XCN_Conn_SubType","XCN_Fwd_Rel_Number","
Fwd_Conn_Count","Job_Name","Schid","DS_
Name","DS_Number","Job_System","Job_Jobnet","Hidden_Conn","Soft_Flag","Job_Head","
Job_Start_Date","Job_Start_Time","Job_
End_Date","Job_End_Time","Job_Avg_Elapsed","Job_Mainid","Job_DR_Class","
Job_WLB_Class","Job_Maint_Flag","Job_Xplat_Targe
t","Job_Xplat_Flag","Job_Nonexec_Flag","Job_Verify_Flag","Job_Locked_Flag","
Job_Hold_Flag","Job_JCLOverride_Flag","Job_T
rig_Job_Flag","Job_Trig_Loop_Flag","DS_Perm_Flag","DS_Internal_Flag","DS_Cpost_Flag","
DS_Auto_Flag","DS_GDG_Flag","Manua
l_Add","Job_WLB_Priority","Job_Type","Job_User_Rqmt_Cnt"
"1","JOB",,,,"2","PAYME01","001",,,"SYSTNAME",,"N","N","Y","2009090","07:59:00","
2009090","08:00:00","00:01:00","ALL",,"
A","N",,"N","N","N","N","N","N","N","N",,,,,,"N","100","JOB","2"
"1","XCN","TR",,"2"
"1","XCN","TR",,"3"
"2","DSN",,,,"1",,"001","COMPANY.DAILY.PAYME01","8",,,"N","N",,,,,,,,,,,,,,,,,,,,"N","
Y","N","N","N","N""2","XCN","PR",,
"13"
Y","N","Y","N","N"
"3","XCN","TR",,"14"
"3","XCN","TR",,"15"
"3","XCN","PR",,"14"
"3","XCN","PR",,"15"
2009090","08:00:00","00:01:00","ALL",,"
8","N",,"N","N","N","N","N","N","N","N",,,,,,"N","100","JOB","2"
"4","XCN","TR",,"5"
"4","XCN","TR",,"6"
"4","XCN","PR",,"7"
Y","N","N","N","N"
"5","XCN","PR",,"16"
Y","N","Y","N","N"
"6","XCN","TR",,"7"
"6","XCN","PR",,"7"
"7","JOB",,,,"4","PAYME10","001",,,"TEST10",,"N","N","N","2009090","08:15:00","
08-Feb-2018 286/722
"7","JOB",,,,"4","PAYME10","001",,,"TEST10",,"N","N","N","2009090","08:15:00","
2009090","08:16:00","00:01:00","ALL",,"A"
,"N",,"N","N","N","N","N","N","Y","N",,,,,,"N","100","JOB","0"
"7","XCN","TR",,"17"
"7","XCN","TR",,"18"
"7","XCN","PR","NEG","15"
"7","XCN","PR",,"18"
2009090","08:00:00","00:01:00","ALL",,"
B","N" ,,"N","N","N","N","N","N","Y","N",,,,,,"N","100","JOB","0"
"8","XCN","RP",,"9"
"8","XCN","TR",,"10"
Workflow Data Simulation Mode

Simulation Mode is a manner of operation in which all workflow data comes from the CA Workload
Automation CA 7® Edition database definitions. No information comes from the queues or active
workload.
The workflow is built in internal tables depending on the building parameters that are supplied at
startup. Because no data comes from the queues, the workflow is static. The jobs running in the
system have no effect on the workflow. However, modifying the definitions while Jobflow Illustrator
is starting can affect the tables.
Ad Hoc Adds and Deletes

After the original workflow is built, you can simulate what-if situations by adding jobs, data sets, or
both. Also, you can try deleting jobs from the workflow to see how the outcome would change.
Checkpoint Save and Start

You can create a baseline workflow by saving the workflow to a data set. This data set can be used as
input on a TYPE=CKPT start to create a workflow. You can use that workflow as the baseline starting
point for a new simulation.
Flowchart Output
Jobflow Illustrator produces two kinds of flowchart output: print and comma-separated value (CSV).
In print output, boxes contain data about job and data set objects. An option lets users omit the data
set boxes and print only job boxes. The boxes are connected and information about the types of
connections is displayed. The maximum size print flowchart is 999 pages horizontally by 999 pages
vertically. A sample print flowchart can be found in the FLOWCHART TYPE=PRINT Description.
In CSV output, data is sent to a file. Commas separate fields in each record. The first record in the file
contains the names of the fields, similar to column headings. This data set is suitable for importing
into a program such as Microsoft Excel. An extract of a CSV file is shown in the Sample FLOWCHART
TYPE=CSV File (Partial) (see page 286).
08-Feb-2018 287/722
Jobflow Monitor
Jobflow Monitor (JFM) provides an ongoing current and forecasted view of the CA Workload
Automation CA 7® Edition workload. Jobflow Monitor uses CA7LOG events that CA Workload
Automation CA 7® Edition generates to track the flow and status of the workload. This information is
provided to consumers such as CA Critical Path Monitor (CA CPM) and the CA 7® Web Client.
Jobflow Monitor addresses the need for the CA Workload Automation CA 7® Edition critical path
monitoring to incorporate job and data set dependencies into the calculation of possible paths. When
a CA Workload Automation CA 7® Edition FLOW is initiated, CPM can optionally interface with
Jobflow Monitor to get the list of jobs, both triggers and dependencies, which determine the critical
path. Jobflow Monitor issues the CAIENF events to CPM as these jobs start and stop execution.
To reduce overhead in the CA Workload Automation CA 7® Edition address space, Jobflow Monitor
executes in its own address space. Jobflow Monitor can monitor multiple CA 7 instances in the same
JFM address space. Jobflow Monitor must execute on the same z/OS image as the CA 7 instances it is
monitoring.
Jobflow Monitor supports only CA 7 instances starting with Version 12.0. Jobflow Monitor does not
support instances from previous releases. You cannot intermix CA 7 instances in Jobflow Monitor
from any releases before Version 12.0. If you do, an error for that instance occurs. To monitor
multiple CA 7 instances in a single Jobflow Monitor address space, all the CA 7 instances must run in
the same CA Datacom/AD MUF.
Requests for Jobflow Monitor data are through XML documents and TCP/IP. CPM uses this interface
to communicate with Jobflow Monitor.
Storage Considerations for Jobflow Monitor

Some sites must adjust the storage requirements for the Jobflow Monitor startup JCL. The JCL is listed
in the Sample User JCL member AL2JFM. Whether you adjust the storage requirements depends on
several factors, including the following items:
The number of CA 7 instances you want to monitor.
The number of jobs in each CA 7 instance entering the queues for that instance.
The number of requirements, predecessors, and successors for each job.
The MEMLIMIT parameter in the startup JCL determines the amount of 64-bit memory that Jobflow
Monitor can use.
A MEMLIMIT=NOLIMIT parameter in the startup JCL is the amount of 64-bit memory that is set up as
a default. You can change the MEMLIMIT limit by overriding the parameter in the execution JCL or
changing the in-stream PROC.
Also, the REGION parameter in the startup JCL determines the amount of 31-bit memory that Jobflow
Monitor can use.
08-Feb-2018 288/722
A REGION=0M is the maximum amount of 31-bit memory that is set up as a default. You can change
the REGION limit by overriding the parameter in the execution JCL or changing the in-stream PROC.
Security Requirements for Jobflow Monitor

Jobflow Monitor executes as a started task as distributed (it can also execute as a batch job if
necessary). As a started task, a started task user ID must be defined to the installation security
system.
If the FACILITY option is used to activate security in Jobflow Monitor on the XML query calls, the
following access is necessary:
The ID that is used to start Jobflow Monitor requires READ access to BPX.SERVER.
The ID used on the XML request requires a valid z/OS UserID and Password.
The ID used on the XML request requires access to Jobflow Monitor.
The ID used on the XML request requires access to the resource class defined on the FACILITY
keyword.
The ID used on the XML request requires access to one or more XML query resources.
Jobflow Monitor validates users from external sources using the XML services through standard SAF
RACROUTE calls. Thus, users using the XML services must have a valid z/OS user ID defined on the z
/OS security system. This user ID is sent to Jobflow Monitor when XML services are requested and are
used for authentication.
The SAF resource class that the Jobflow Monitor address space uses is defined in the FACILITY
address space options. Thus, each Jobflow Monitor can have different rules that are set up based on
the resource class name.
Note: You can use FACILITY(NONE) to bypass all resource authorization checks that Jobflow
Monitor makes. This bypass includes checks for access to Jobflow Monitor and access to
one or more XML queries being sent to Jobflow Monitor through web services.
The default FACILITY value is NONE, which indicates that security is not invoked. Refer to the FACILITY
address space option for more information.
Access to Jobflow Monitor is controlled using the resource key CA7JFM.ACCESS with READ access. A
resource call is made to the resource class with key CA7JFM.ACCESS. Users without READ access to
CA7JFM.ACCESS cannot use the Jobflow Monitor web services to invoke the XML query that was
requested.
All XML query resource names are prefixed with the following name: CA7JFM.XML. queryname, where
queryname contains the specific resource name that is associated with the XML query being
performed.
08-Feb-2018 289/722
Security verifies that the user associated with the specific XML query has READ level access.
More information:
XML Query Resource Names (https://wiki.ca.com/display/CWAC7E

/XML+Query+Resource+Names)
Configure CA ACF2 and Jobflow Monitor

Configuring CA7JFM in a CA ACF2™ system includes the following steps:
Define Jobflow Monitor To CA ACF2 (see page 290)

Define the CA7JFM Resource Class (see page 290)
Define CA7JFM Resource Rules (see page 291)
Define Jobflow Monitor To CA ACF2

Jobflow Monitor generally executes as a started task in the z/OS system and thus requires that you
assign an STC user ID. Also, because multiple users are signing on to each, Jobflow Monitor address
space acts as a multiple-user, single address space system, or MUSASS. The MUSASS attribute is
assigned. Also, to permit the taking of complete dumps when the Jobflow Monitor address space
abends, the DUMPAUTH attribute is requested.
INSERT CA7JFM NAME(CA7 JFM SERVER) STC MUSASS DUMPAUTH
Note: Because CA7JFM uses TCP/IP for its communications in its web services, the user ID
associated with Jobflow Monitor requires OMVS access to the following areas:
FACILITY BPX.SERVER ACCESS(READ)
DATASET TCPIP.ACCESS(READ)
Define the CA7JFM Resource Class

With CA ACF2, users must define what resource class is mapped to CA ACF2.
This definition is accomplished using the Class Map facility by defining the resource class and then
defining a three-character type to which this resource class is known in CA ACF2. Using the example
CA7JFMD, coded on the Jobflow Monitor Address Space options FACILITY statement, a class map
definition can look like the following example:
CLASMAP.CA7JFM RESOURCE(CA7JFMD) TYPE(SRV)
Now, when Jobflow Monitor issues the SAF call, CA ACF2 knows to protect the resource class.
After this class map is defined, define resource rules to map who has access to Jobflow Monitor itself
and each XML query.
08-Feb-2018 290/722
Define CA7JFM Resource Rules

Using our previous CA7JFMD resource class example, we must define the following rules:
Any user that is permitted to use Jobflow Monitor for XML Web Services requires READ access to the
CA7JFM.ACCESS resource:
$KEY(CA7JFM.ACCESS) TYPE(SRV)
UID(ui-users) SERVICE(READ) ALLOW
Also, any user that is permitted to use Jobflow Monitor for XML Web Services requires that you
establish one or more resources to indicate the generic (or specific) rule for the XML resource
required.
The following example is for a generic XML request:

$KEY(CA7JFM.XML.*) TYPE(SRV)
UID(admin-users) SERVICE(READ) ALLOW
The following example is for a “QueryWorkflow” XML request:

$KEY(CA7JFM.XML.QUERYWORKFLOW) TYPE(SRV)
More information:

Configure CA Top Secret and Jobflow Monitor

Configuring CA7JFM in a CA Top Secret® system includes the following steps:
Define Jobflow Monitor to CA Top Secret (see page 291)

Define the CA7JFM Resource Rules (see page 292)
Define Jobflow Monitor to CA Top Secret

Jobflow Monitor generally executes as a started task in the z/OS system and thus requires the
definition of an STC ACID. This definition identifies the started task name, the procedure from which
the started task executes, and associates a facility with the started task ACID. You can use security
definitions already in place to set up the started tasks or use the following samples to create new
security definitions.

TSS MODIFY(FAC(USERxx=NAME=CA7JFM)
TSS MODIFY(FAC(CA7JFM=ASUBM,LOG(ALL),MULTIUSER,NOABEND,PGM=CAL2J))
TSS CREATE(CA7JFM) NAME('CA 7 JFM SERVER ACID') FAC(STC,BATCH) +
TYPE(USER) PASS(NOPW) DEPT(CA7OPS) MASTFAC(CA7JFM)
TSS ADDTO(STC) PROCNAME(CA7JFM) ACID(CA7JFM)
TSS CREATE(CA7GROUP) TYPE(GROUP) NAME(‘CA 7 JFM SERVER GROUP’) DEPT(xxxx)
TSS ADD(CA7GROUP) GID(?) RANGE(xxxxx,yyyyy)
TSS ADD(CA7JFM) UID(?) GROUP(CA7GROUP) DFLTGRP(CA7GROUP)
08-Feb-2018 291/722
HOME(/u/users/cai/)
The UID selected must have access to TCP/IP services.
Each CA 7® Web Client user requires access to the CA7JFM facility directly or through a profile:
TSS ADD(xxxxxxx) FAC(CA7JFM)
Note: Because CA7JFM uses TCP/IP for its communications in its web services, the user ID

With CA Top Secret, users must define the SAF resource class to CA Top Secret.
This definition is accomplished using the following commands. In this example, the Jobflow Monitor
Address Space options have FACILITY(CA7JFMD).
TSS ADDTO(RDT) RESCLASS(CA7JFMD) ACLST(READ) MAXLEN(40)
TSS ADDTO(dept) CA7JFMD(CA7JFM)
Define the CA7JFM Resource Rules

CA7JFM.ACCESS resource:
TSS PER(ui-userid) CA7JFMD(CA7JFM.ACCESS) ACCESS(READ)
Additionally, any user that is permitted to use Jobflow Monitor for XML Web Services requires that
you establish one or more resources to indicate the generic (or specific) rule for the XML resource
required.


TSS PER(admin-userid) CA7JFMD(CA7JFM.XML.QUERYWORKFLOW) ACCESS(READ)
More information:

08-Feb-2018 292/722
Configure IBM RACF and Jobflow Monitor

Configuring Jobflow Monitor in an IBM RACF system includes the following steps:
Define the Resource Class to the Resource Descriptor Table (see page 293)
Define the Resource Class to the Router Table (see page 293)
Activate the New Resource Class (see page 294)
Define the Jobflow Monitor Started Task to the Started Procedures Table (see page 294)
Define the Jobflow Monitor Started Task User ID (see page 294)
Define the Resource Class and Permit Access (see page 295)
Define the Resource Class to the Resource Descriptor Table

Defining the resource class to the resource descriptor table informs RACF that it is to protect the
resource class. Specify the same resource class that you specified in the Jobflow Monitor Address
Space input FACILITY option statement. You can decide to have multiple Jobflow Monitors use the
same resource class and thus the same rules, or you can decide to assign a different resource class
per Jobflow Monitor. The latter permits different accesses in different Jobflow Monitor address
spaces.
IBM recommends the dynamic Class Descriptor Table (CDT). To define the resource class to this table,
use the RDEFINE command. The following statement shows an example of adding resource CA7JFMD
to the dynamic CDT:
RDEFINE CDT CA7JFMD CDTINFO(MAXLENGTH(40) FIRST(ALPHA NUMERIC) MAXLENX(40) GENLIST
(ALLOWED) RACLIST(ALLOWED) OPERATIONS(NO) POSIT(nnn) OTHER
(ALPHA NATIONAL NUMERIC SPECIAL))
Change the nnn in POSIT to the desired three-digit number.
Note: For more information about the RDEFINE command and its parameters, see the IBM
Security Server RACF Command Language Reference documentation.
Define the Resource Class to the Router Table

The RACF Router Table lets you associate installation resource class authorization calls with RACF
functions. You must also add the resource classes added to the Class Descriptor Table to the RACF
Router Table to specify security processing requirements for the resource classes.
The following example statement adds CA7JFMD to the Router Table:

CA7JFMD ICHRFRTB CLASS=CA7JFMD,ACTION=RACF
Note: For more information about the RACF Router Table, see the IBM Security Server
RACF System Programmer's documentation.
08-Feb-2018 293/722
Activate the New Resource Class

To activate the resource class under RACF, issue the following command:
SETROPTS CLASSACT(CA7JFMD)
Define the Jobflow Monitor Started Task to the Started Procedures Table
RACF must know the started task for Jobflow Monitor and have a user ID associated with it. This
relationship is accomplished through the started procedures table (ICHRIN03) or through the
STARTED class. Do not make the started task user ID privileged or trusted. To use the started
procedures table, use the ICHRIN03 macro to add an entry, such as the following items for CA7JFMD:
ICHRIN03 CSECT
TITLE 'ICHRIN03 - STARTED PROCEDURES TABLE'
DC XL2'8001' NEW FORMAT - 03 ENTRIES
*
DC CL8'CA7JFMD' PROCNAME - CA 7 JFM Server
DC CL8'CA7JFMD ' USERID
DC CL8' ' GROUP- NULL
DC XL1'00' NOT PRIVILEGED OR TRUSTED
DC XL7'00' RESERVED
END
If preferred and your site is set up to use the STARTED resource class, use the RDEFINE command to
define the Jobflow Monitor started task. An example to define CA7JFMD follows:
RDEFINE STARTED CA7JFMD.* UACC(NONE)
STDATA(USER(CA7JFMD) GROUP(CA7GROUP))
Note: The STARTED resource class overrides the started procedures table (ICHRIN03). For
more information, see the IBM Security Server RACF Security Administrator documentation
.
Define the Jobflow Monitor Started Task User ID

An ADDUSER RACF command adds a user ID to the RACF database. The ADDUSER command
associates that user with an existing group, by which the CA7SRVR user ID can be added. The data set
resources that it needs access to are the SYSIN input options and the profile (CA7PROF DD).
If you do not already have a CA7GROUP, issue the following command:

ADDGROUP CA7GROUP SUPGROUP(xxxx) OMVS(GID(?)) OWNER(xxxxx)
To add the user ID CA7SRVR, issue the following command. Some sites require passwords for started
task user IDs.
ADDUSER CA7SRVRD NAME('CA 7 UI Server') OWNER(CA7GROUP) NOPASSWORD
Add the OMVS segment to the user ID according to the standards at your site, for example:
ALTUSER CA7SRVRD OMVS(UID(?) HOME(‘/u/users/cai/’) + PROGRAM(‘/BIN/SH’))
08-Feb-2018 294/722
Note: Because CA7JFM uses TCP/IP for its communications in its web services, the UserID
Define the Resource Class and Permit Access

The specific resources that Jobflow Monitor uses are listed in this topic. In this example CA7JFMD, we
set up the basic permissions to grant to resources within this class.
First, define the class with universal access defaulting to NONE (only users granted access have
access):
RDEFINE CA7JFMD (CA7JFM.ACCESS) DATA('CA 7 JFM Access') OWNER(CA7GROUP) UACC(NONE)
Next, permit specific groups, IDs, or both access to the Jobflow Monitor resource.
CA7JFM.ACCESS resource. The specifics about the resource access are provided in the following
example:
PERMIT CA7JFM.ACCESS CLASS(CA7JFMD) ID(ui-users) ACCESS(READ)
Additionally, permitting that user requires that you establish one or more resources to indicate the
generic (or specific) rule for the XML resource required.


PERMIT CA7JFM.XML.QUERYWORKFLOW CLASS(CA7JFMD) ID(CA7Admin) ACCESS(READ)
More information:

Implement Jobflow Monitor

Review these topics before you start Jobflow Monitor.
Minimum z/OS Requirements (see page 296)

CA7LOG CAIENF Event (see page 296)
Sample JFM User JCL (see page 296)
Monitoring Considerations (see page 296)
08-Feb-2018 295/722
Minimum z/OS Requirements

The following minimum z/OS requirements are for using Jobflow Monitor:
z/OS 1.7
APF authorized
IBM Language Environment
64-bit storage exploited/required
CA7LOG CAIENF Event

Using CAIENF, CA Workload Automation CA 7® Edition issues CA7LOG events that Jobflow Monitor
uses to monitor and forecast the CA Workload Automation CA 7® Edition workflow.
To activate the generation of the events, specify JFM=YES in the CA Workload Automation CA 7®
Edition OPTIONS statement.
The previous releases of CA Workload Automation CA 7® Edition restricted the critical path definition
and monitoring to trigger-only paths. Jobflow Monitor can provide more robust critical path
definition and monitoring by including nontriggering predecessors into the critical path
determination. To activate this processing, specify CPM=JFMLOAD and JFM=YES in the OPTIONS
statement in the initialization file.
Sample JFM User JCL

The sample JCL for using Jobflow Monitor is in the CA Workload Automation CA 7® Edition sample JCL
library CAL2JCL as member AL2JFM.
Monitoring Considerations
Start CA Workload Automation CA 7® Edition before starting Jobflow Monitor. When Jobflow Monitor
starts, each MONITOR statement is processed and attempts a connection with the CA 7 instance.
Jobflow Monitor supports only CA 7 instances starting with Version 12.0. Jobflow Monitor does not
support instances from previous releases. You cannot intermix CA 7 instances in Jobflow Monitor
from any releases before Version 12.0. If you do, an error for that instance occurs. If you want to
monitor multiple CA 7 instances in a single Jobflow Monitor address space, all the CA 7 instances
must run in the same CA Datacom/AD MUF.
If Jobflow Monitor is started before CA Workload Automation CA 7® Edition, Jobflow Monitor does
not connect with CA Workload Automation CA 7® Edition, even when CA Workload Automation CA 7®
Edition is started.
For example, Jobflow Monitor is running and the CA 7 instance comes down. Jobflow Monitor
automatically attempts to reconnect with the CA 7 instance once it comes back up.
Also, assume that a Jobflow Monitor connection to a CA 7 instance is manually stopped (for example,
08-Feb-2018 296/722
Also, assume that a Jobflow Monitor connection to a CA 7 instance is manually stopped (for example,
STOP I(CA7x)). Jobflow Monitor does not attempt to start it up later unless a start command is issued
(for example, START I(CA7x)).
Jobflow Monitor DD Statements

Jobflow Monitor uses the following DD statements.
Input DD Statements (see page 297)

Output DD Statements (see page 297)
Optional SYSTCPD DD Statement (see page 298)
Input DD Statements
Jobflow Monitor has the following input DD statements:
STEPLIB
Specifies the Jobflow Monitor load library, the CA Workload Automation CA 7® Edition load
library, the CA Datacom®/AD execution libraries, and the IBM Language Environment load
libraries.
CAJFPARM
Specifies the data set containing the Jobflow Monitor startup parameters.
CEEOPTS
Specifies the member containing IBM Language Environment (LE) run-time options. Jobflow
Monitor uses the options to control certain behaviors and to provide an overall performance
improvement.
Note: For more information about language environment run-time options, see the z/OS
IBM Language Environment Programming Reference.
Jobflow Monitor has the following output DD statements:
CAJFLOG
Specifies the data set definition for the Jobflow Monitor log. Jobflow Monitor uses this DD
statement for diagnostic logging.
This DD statement is optional. If this DD statement is not allocated during Jobflow Monitor
startup, diagnostic logging does not occur.
The LOGLEVEL setting, an address space parameter, establishes the level of diagnostic logging
that is used during the Jobflow Monitor session. Also, the LOGLEVEL command lets you change
this setting after Jobflow Monitor is started.
Use the LOGLEVEL setting and command only at the direction of CA Support.
CAJFnnnn
If the PRINTLOG command is issued, Jobflow Monitor dynamically allocates the next available CAJF
nnnn DD and uses it to print the internal Jobflow Monitor log.
Use the PRINTLOG command only at the direction of CA Support.
08-Feb-2018 297/722
More information:
Operator Commands (https://wiki.ca.com/display/CWAC7E/Operator+Commands)
Address Space Statements (https://wiki.ca.com/display/CWAC7E/Address+Space+Statements)
Optional SYSTCPD DD Statement

Depending on your local implementation of TCP/IP, it might be necessary to add a //SYSTCPD DD
statement to your Jobflow Monitor JCL.
Initialization Parameters for Jobflow Monitor

Jobflow Monitor product initialization parameters are specified in the PDS that the CAJFPARM
ddname points to.
A JCL EXEC PARM operand in the JFM startup JCL lets you specify a “parameter member prefix”. This
prefix lets you have multiple sets of parameter files in the same CAJFPARM data set. This prefix
removes the requirement that you have a separate CAJFPARM data set for each JFM region. Using
the prefix lets you have a single CAJFPARM data set with multiple sets of JFM parameter members.
The EXEC PARM operand is PMEMPFX(value) where value is a 1 through 6 character parameter
member prefix. If the PMEMPFX operand is not specified, a default prefix of JBFLW is used. JFM
processes parameters from parameter members JBFLWAS, JBFLWMN, JBFLWIP, and JBFLWEV. If you
specify an EXEC PARM operand of PMEMPFX(value), the specified prefix is used instead of the
default. For example, if you specified PMEMPFX(PRD1J2), JFM processes parameters from parameter
members PRD1J2AS, PRD1J2MN, PRD1J2IP, and PRD1J2EV.
The documentation uses the default JBFLWxxx names.
The Jobflow Monitor address space parameters are defined in the JBFLWAS member. Refer to
member AL2JFMAS in the CA Workload Automation CA 7® Edition CAL2OPTN data set for an
example.
The Language Environment options that Jobflow Monitor uses are specified in the JBFLWLE member.
These settings are recommended only in the Jobflow Monitor address space and are used only while
Jobflow Monitor is running. Refer to member AL2JFMLE in the CA Workload Automation CA 7®
Edition CAL2OPTN data set for an example.
The Jobflow Monitor instances are defined in the JBFLWMN member using the MONITOR()
statement. All instances that are defined in JBFLWMN are automatically started when the Jobflow
Monitor address space is started. Refer to member AL2JBFLW in the CA Workload Automation CA 7®
Edition CAL2OPTN data set for an example.
The TCP/IP configuration data is defined in the JBFLWIP member using the PORT() statement. Refer
to member AL2JFMIP in the CA Workload Automation CA 7® Edition CAL2OPTN data set for an
example.
The Jobflow Monitor Event Subscription parameters are defined in the JBFLWEV member. Refer to
08-Feb-2018 298/722
The Jobflow Monitor Event Subscription parameters are defined in the JBFLWEV member. Refer to
member AL2JFMEV in the CA Workload Automation CA 7 Edition CAL2OPTN data set for an example.
Initialization file statements must be in columns 1-72. Any data past column 72 is ignored. Lines that
begin with either an asterisk (*) or a forward slash (/) are considered comment lines. Enter all
keywords and values in uppercase, unless otherwise noted. The initialization statement parameters
are enclosed in parentheses and each parameter value is enclosed in parentheses. The blank spaces
on any line and blank lines are ignored. If an initialization statement must continue on the next line,
no special continuation character is needed.
Address Space Statements

This topic describes statements available for the Jobflow Monitor address space.
EVENTS
(Optional) Specifies whether Jobflow Monitor supports CA 7 Event Subscription.
Default: NONE
NONE
Jobflow Monitor does not publish CA 7 events to subscribers. This value is the default.
YES
Jobflow Monitor publishes CA 7 events to subscribers.
EXTRACTPATH
(Optional) Specifies the absolute USS PATH name where CA 7 data extract files are placed.
Specify a USS pathname from 1 to 60 characters.
Default: No default.
Example: EXTRACTPATH statement

EXTRACTPATH(/u/users/myjfm/extractpath
DELTAINT
(Optional) Specifies the minimum number of seconds between DELTA XML requests for a specific
job stream. The value must be numeric and within a range of 0 to 86400 inclusive. If not specified,
DELTAINT(30) is the default. A setting of zero indicates that there is no minimum limitation.
This parameter controls how often a job stream refresh call is honored. A setting of 30 seconds
indicates that JFM only generates and returns delta information for a given job stream once every
30 seconds, even if a request is made every 5 seconds.
Default: DELTAINT(30)
Example: DELTAINT statement

DELTAINT(30)
FACILITY
(Optional) Specifies the resource class to use on security calls in Jobflow Monitor for all JFM XML
queries. The value can range from 1 to 8 characters.
Note: Any value that is set takes effect on the next authorization call made.
Default: NONE
08-Feb-2018 299/722
NONE
Bypasses all resource authorization checks in Jobflow Monitor, including checks for access to
Jobflow Monitor. This value is the default.
YES
Uses CA7JFM as the resource class on the security call.
Example: FACILITY statement

FACILITY(NONE)
JFMNAME
(Optional) Specifies a name to associate with the Jobflow Monitor job or started task that is
running.
The value can range from 1 to 32 characters in length.
The value can contain one or more of the following valid characters: period (.), dash (-),
underscore (_), 0-9, a-z, and A-Z.
Default: If not provided, a default in the following format is generated:
JFM.jobname
jobname
Identifies the JOBNAME (or STC name) of the Jobflow Monitor that is running.
Example: JFMNAME statement

JFMNAME(JFM.AL2JFM)
LOGLEVEL
(Optional) Specifies whether to activate diagnostic logging and at what level.
Use the LOGLEVEL setting and command only the direction of CA Support.
Default: 0
0
Performs no diagnostic logging. This value is the default.
1
Performs the least amount of diagnostic logging.
2
Performs more diagnostic logging.
3
Performs the most amount of diagnostic logging.
Note: If LOGLEVEL contains a value greater than zero, allocate the CAJFLOG DD in the
Jobflow Monitor startup JCL, or no diagnostic logging occurs.
Example: LOGLEVEL statement

LOGLEVEL(0)
SAFRING
08-Feb-2018 300/722
SAFRING
(Required if SSLRINGTYPE(SAF) is specified; otherwise, optional) Specifies the name of the SAF
keyring.
The name is specified in the following format:
userid/keyring
userid
Indicates a 1 through 8 character user ID.
keyring
Indicates a 1 through 8 character key ring name.
The current userid that is associated with the Jobflow Monitor job or started task is used when
the userid is omitted. The user must have READ access to the IRR.DIGTCERT.LISTRING resource in
the FACILITY class when using a SAF key ring that the user owns. The user must have UPDATE
access to the IRR.DIGTCERT.LISTRING resource in the FACILITY class when using a SAF key ring
that another user owns.
Note: Certificate private keys are not available when using a SAF key ring that another user owns.
If this parameter is specified, the SSLRINGTYPE(SAF) parameter must also be specified.
Examples: SAFRING statement

SAFRING(KEYRING1)
SAFRING(MYUSERID/KEYRING2)
SSLCERTLABEL
(Optional) Specifies the label of the certificate in the key ring that is used to authenticate the
application.
Specify a string from 1 to 58 characters.
If this parameter is specified, the SSLRINGTYPE parameter must also be specified.
Default: If not specified, the default certificate from the key ring is used.
Example: SSLCERTLABEL statement

SSLCERTLABEL(My certificate label)
SSLRINGTYPE
(Optional) Indicates that System SSL is supported in the Jobflow Monitor job or started task and
specifies the type of key database to use.
Default: No default. If SSLRINGTYPE is not specified, SSL is not supported in the Jobflow Monitor.
KDB
Indicates the use of an HFS key database and the password stash file. The KEYDB and STASH
DD statements in the Jobflow Monitor startup JCL specify the path to the USS files where the
key database and the password stash file reside.
SAF
Indicates the use of a SAF key ring. The SAFRING parameter is required.
Examples: SSLRINGTYPE statement

SSLRINGTYPE(KDB)
08-Feb-2018 301/722
MONITOR Statement
The MONITOR statement provides various information about Jobflow Monitor instances. For
example, the statement defines the instance to monitor and the number of hours to monitor.
If an error occurs while processing the MONITOR statements, no more statements are processed.
Any MONITOR statements read before an error occurs are processed.
INSTANCE
Specifies which instance of CA Workload Automation CA 7® Edition to monitor. The instance must
be CA71 through CA78 inclusive. No aliases are permitted.
Limits: CA71 - CA78
TYPE
(Optional) Specifies the type of recovery.
COLD
Does not attempt to recover any critical path data. Any critical paths that are active do not get
any updates (start and stop events) from Jobflow Monitor. Consider removing them from
CPM manually. COLD is the default.
WARM
Attempts to recover any critical path data. If WARM is specified and critical paths are active,
Jobflow Monitor reads the CAIENF records trying to recover all possible information about the
critical path. Two items determine whether Jobflow Monitor can recover all the required data
to rebuild the critical paths:
The retention period of the CAIENF records.
The age of the critical paths.
SPAN
(Optional) Specifies the number of hours to monitor. The SPAN value includes the active workload
and forecasted data.
Limits: 1-72 hours
Default: 12 hours
REFRESH
(Optional) Specifies the number of minutes between refreshes of the forecasted data. When the
refresh interval ends, new forecasted data is brought in to fill in the span.
Limits: 1-60 minutes
Default: 15 minutes
HISTORY
(Optional) Specifies the number of hours to keep information about jobs that have already run.
When Jobflow Monitor initially starts up, no history data is available. The history data
accumulates over time.
Limits: 1-12 hours
Default: 3 hours
08-Feb-2018 302/722
CPMCCI
(Optional) Specifies the CAICCI server name that CPM uses on the system where Jobflow Monitor
runs. If your CPM CCIApplname is set to something other than CpmServer, specify that value here.
Default: CpmServer
JFMCCI
(Optional) Specifies the CAICCI server name that the Jobflow Monitor instance uses when
communicating with CPM.
Default: JobflowMgrCA7n where CA7n is the same value as the INSTANCE parameter
Note: JFM reads flow definitions from a cache that is refreshed once each minute. These
definitions are attached when the starting job enters the JFM workload. They remain
associated with that job for the life of the monitor.
You can change a flow definition for a job that has not yet entered the Jobflow Monitor workload.
Ensure that your changes are made at least a minute before the job enters the workload.
If the job has already entered the Jobflow Monitor workload, recycle the monitor after changing the
flow definition for the changes to take effect. Recycle before the job actually enters the request
queue because the flow is activated then.
Do not change a flow definition while the flow is active in CPM.
Example: MONITOR Statement

MONITOR(INSTANCE(CA72) SPAN(18) REFRESH(45))
PORT Statement
Jobflow Monitor uses TCP/IP to communicate with other programs. The PORT statement tells the
Jobflow Monitor address space which ports to use for communication and whether the traffic is
encrypted. Multiple PORT statements with varying port numbers and encryption modes can be
specified.
CPM uses the port named CPMPORT. If you do not specify a PORT statement with NAME(CPMPORT),
a CPMPORT with a port number of 7173 is automatically defined. If you do not want the Jobflow
Monitor address space to interact with CPM, specify the following PORT statement:
This statement has the following parameters:
NAME
Provides an alias name for the port containing up to 256 characters
NUMBER
Specifies the port number.
08-Feb-2018 303/722
ENCR
Specifies whether to support encryption on the port.
Default: NONE
The following values are valid:
NONE
Uses no encryption on the port. All data is transmitted in clear text.
SSL
Uses IBM System SSL to encrypt the data that is transmitted on the port. You cannot specify
SSL for CPMPORTs.
ATTLS
Indicates that AT-TLS is used to encrypt data that is transmitted on the port. Jobflow Monitor
is AT-TLS aware and ensures that connections established to ports defined with ENCR(ATTLS)
are actually under control of AT-TLS. If not, the connection is closed.
Example: PORT statement

PORT(NAME(CPMPORT) NUMBER(7173))
PORT(NAME(QRYCLEAR) NUMBER(12001) ENCR(NONE)
PORT(NAME(QRYSECURE1) NUMBER(12002) ENCR(SSL)
PORT(NAME(QRYSECURE2) NUMBER(12003) ENCR(ATTLS)
Operator Command for Jobflow Monitor

This article explains operator commands for Jobflow Monitor.
Start Jobflow Monitor (see page 304)

Stop Jobflow Monitor (see page 304)
Issue a Command to a Jobflow Monitor Instance (see page 305)
Start Jobflow Monitor

To start a Jobflow Monitor address space, submit a batch job or issue the following command. In the
command, jobflow is the name of the started task JCL member.
S jobflow
Stop Jobflow Monitor

To stop a Jobflow Monitor address space, issue the following command where jobflow is the started
task or job name:
P jobflow
08-Feb-2018 304/722
Issue a Command to a Jobflow Monitor Instance

To issue a command to a running Jobflow Monitor instance, the command must be directed to the
address space and toward a specific monitor instance. To do this, Jobflow Monitor commands are
prefixed with the following:
F jobflow,INSTANCE(CA 7 instance list)
INSTANCE(CA 7 instance list) identifies which Jobflow Monitor instances execute the command. The
CA Workload Automation CA 7® Edition identifier is the same one specified in the INSTANCE
parameter of the MONITOR() statement. The list can contain a single CA Workload Automation CA 7®
Edition identifier or a comma-delimited list. No aliases are permitted.
INSTANCE(*) or INSTANCE(ALL) directs the command to all monitor instances in the address space.
If the INSTANCE keyword is omitted and only one monitor instance is active in the address space, the
command is directed toward that monitor.
If the INSTANCE keyword is omitted and more than one monitor instance is active in the address
space, the command is rejected.
The INSTANCE keyword can be shortened to I.
The following modify commands are available:
ALTER(HISTORY(nn))
Dynamically changes the number of hours of history to maintain.
Valid values can range from 1 to 12 hours.
The new history value takes effect after the current refresh interval expires.
If more than one Jobflow Monitor instance is active, include the INSTANCE keyword on the
command; otherwise, the INSTANCE keyword is not required.
Example: ALTER HISTORY Command

F jobflow,ALTER(HISTORY(12))
CAL2M211I Command: ALTER(HISTORY(12)) received
CAL2M212I Command will be performed for Monitors: CA77
CAL2M242I History interval will be set to 12 hours
ALTER(REFRESH(nn))
Dynamically changes how often to update the forecasted data.
Valid values can range from 1 minute to 60 minutes.
The new refresh value takes effect after the current refresh interval expires.
Example: ALTER REFRESH Command

F jobflow,ALTER(REFRESH(15))
CAL2M211I Command: ALTER(REFRESH(15)) received
CAL2M243I Refresh interval will be set to 15 minutes
08-Feb-2018 305/722
ALTER(SPAN(nn))
Dynamically changes the number of hours to monitor.
Valid values are 1 hour to 72 hours.
If the SPAN value is less than the current definition, the number of hours that are monitored
dynamically adjusts over time to the specified value.
If the new SPAN value is greater than the current definition, the new value takes effect at the
next REFRESH interval.
Example: ALTER SPAN Command

F jobflow,ALTER(SPAN(16))
CAL2M211I Command: ALTER(SPAN(16)) received
CAL2M244I Span will be set to 16 hours
CLEARLOG
Requests that Jobflow Monitor clears the current log file that is maintained in memory.
Example: CLEARLOG Command

F jobflow,CLEARLOG
CAL2M211I Command: CLEARLOG received
CAL2M261I CLEARLOG request was processed
FACILITY(value)
Dynamically changes the resource class to use on security calls in Jobflow Monitor for all Web
Service XML queries.
The valid values can range from 1 to 8 characters.
If FACILITY(NONE) is specified, all resource authorization checks in Jobflow Monitor are bypassed,
including checks for access to Jobflow Monitor.
If FACILITY(YES) is specified, CA7JFM is used as the resource class on the security call.
Example: FACILITY Command

F jobflow,FACILITY(NONE)
CAL2M211I Command: FACILITY(NONE) received
CAL2M250I FACILITY will be set to NONE
HELP(cmd)
Gives detailed syntax help for the specified Jobflow Monitor command.
If cmd is omitted, provides help on all Jobflow Monitor commands.
Example: HELP Command

F jobflow,HELP

CAL2M211I Command: HELP received
CAL2M270I Available keywords for Jobflow Monitor modify command:
CAL2M270I + Instance(*|All|CA7n,...) - Direct to monitor instance
CAL2M270I + Alter(Span(nn)|(Refresh(nn)|History(nn)) - Change settings
CAL2M270I + Clearlog - Clear the current log file
CAL2M270I + Facility(xxxx) - Change security facility setting
CAL2M270I + Help(command|Help) - Command help information
CAL2M270I + Loglevel(0|1|2|3) - Diagnostic logging options
CAL2M270I + Printlog - Print the current log file
CAL2M270I + Resolve - Force dependency resolution
CAL2M270I + STARt - Start monitor instances
CAL2M270I + STATus(SHort|Verbose|STorage) - Display monitor status
08-Feb-2018 306/722
CAL2M270I + STOp - Stop monitor instances
Example: HELP ALTER Command

F jobflow,HELP(ALTER)
CAL2M211I Command: HELP(ALTER) received
CAL2M272I Alter(Span(nn)|(Refresh(nn)|History(nn)) - Change settings
CAL2M272I + Alter(Span(nn))
CAL2M272I Change the number of hours(1-72) to monitor
CAL2M272I + Alter(Refresh(nn))
CAL2M272I Change refresh rate (1-60 minutes) of forecasted workload
CAL2M272I + Alter(History(nn))
CAL2M272I Change the number of hours(0-12) of history to maintain
CAL2M272I The new values will take effect at the next refresh interval
Example: HELP FACILITY Command

F jobflow,HELP(FACILITY)
CAL2M211I Command: HELP(FACILITY) received
CAL2M279I Facility(xxxx) - Change security facility setting
CAL2M279I The FACILITY command specifies the resource class to use
CAL2M279I on security calls in Jobflow Monitor for all Web Service
CAL2M279I XML queries. The value can range from 1 to 8 characters.
CAL2M279I If this keyword is not provided, the default is NONE.
CAL2M279I If FACILITY(YES) is specified, CA7JFM will be used as the
CAL2M279I class. Any other valid value will be used. Any value set
CAL2M279I will take effect on the next authorization call made.
Example: HELP STATUS Command

F jobflow,HELP STATUS
CAL2M211I Command: HELP STATUS received
CAL2M275I STATus(SHort|Verbose|STorage) - Display monitor status
CAL2M275I + SHort - provides an overview about active monitors
CAL2M275I + Verbose - shows detailed information about active monitors
CAL2M275I + STorage - provides detailed storage information about
CAL2M275I + active monitors
LOGLEVEL(n)
Specifies whether to activate diagnostic logging and at what level.
0
Performs no diagnostic logging.
1
2
3
Note: If LOGLEVEL contains a value greater than zero, allocate the CAJFLOG DD in the
Jobflow Monitor startup JCL, or no diagnostic logging occurs.
Example: LOGLEVEL Command
08-Feb-2018 307/722

F jobflow,LOGLEVEL(0)
CAL2M211I Command: LOGLEVEL(0) received
CAL2M249I LOGLEVEL will be set to 0
PRINTLOG
Prints the current Jobflow Monitor log file. This command dynamically allocates the next available
CAJFnnnn DDNAME to use, opens the file, writes the current log file, closes the file, and frees the
file.
This command lets operations obtain output that is generated to the CAJF nnnn DD without
having to bring down or recycle the Jobflow Monitor task.
Note: Use the PRINTLOG command only at the direction of CA Support.
Example: PRINTLOG Command

F jobflow,PRINTLOG
CAL2M211I Command: PRINTLOG received
CAL2M257I PRINTLOG request was processed to DDNAME: CAJF0001
RESOLVE
Resolves any outstanding dependencies and database updates in the current forecasted
workload. For the forecasted workload, this processing usually occurs at the refresh interval. To
cause this processing to occur now, use this command.
command. For one instance, INSTANCE keyword is not required.
Example: RESOLVE Command

F jobflow,RESOLVE(INSTANCE(CA77))
CAL2M211I Command: RESOLVE(INSTANCE(CA77)) received
START
Starts the monitor instance. This keyword requires the INSTANCE keyword.
The JBFLWMN member for the requested instance must contain a MONITOR statement.
Example: START Command

F jobflow,START(INSTANCE(CA77))
CAL2M211I Command: START(INSTANCE(CA77)) received
CAL2M241I The requested INSTANCE(S) will be started: CA77
STATUS
Returns the monitor status. The INSTANCE keyword is not used with any STATUS command. The
default value for the STATUS command is STATUS(VERBOSE).
VERBOSE
Provides detailed information about the Jobflow Monitor instances running in the address
space. This command displays the following information:
A list of the Jobflow Monitor instances to include in the output.
Jobflow Monitor assembly information.
08-Feb-2018 308/722
A list of the current Jobflow Monitor options in effect.
A list of the active Jobflow Monitor instances.
Detailed Jobflow Monitor processing data information.
Jobflow Monitor Heap storage availability and usage.
The following information is listed for each active Jobflow Monitor instance:
Current options in effect.
Event information and counts.
Current and total object counts by object type.
Current and total cell pool counts by size of the cell pool.
SHORT
Provides some overview information about the Jobflow Monitor instances running in the
address space. This command displays the following information:
A list of the Jobflow Monitor instances that are included in the output.
Jobflow Monitor assembly information.
A list of the current Jobflow Monitor options in effect.
A list of the active Jobflow Monitor instances.
Detailed Jobflow Monitor processing data information.
STORAGE
Provides detailed storage usage about the Jobflow Monitor instances running in the address
space. This command displays the following information:
A list of the Jobflow Monitor instances that are included in the output.
Jobflow Monitor Heap storage availability and usage.
The following information is listed for each active Jobflow Monitor instance:
Current and total cell pool counts by thread and size of the cell pool.
Example: STATUS Command

F jobflow,STATUS
CAL2M211I Command: STATUS received
CAL2M284I JOBFLOW MONITOR STATUS - VERBOSE REPORT
CAL2M285I Assembly Information: r12.0
CAL2M292I Address Space Options in effect:
CAL2M292I DELTAINT(59), FACILITY(NONE), LOGLEVEL(0)
CAL2M292I JFMNAME(Jobflow Monitor production)
CAL2M286I Active Instances: CA77
CAL2M287I Process Data:
CAL2M287I PID 000003D4, Size 13705216, MVS User TESTUSER
08-Feb-2018 309/722
CAL2M287I System Time 0.1700, User Time 0.5300, Total Time 0.7000
CAL2M287I Started Tue Aug 13 10:34:14 2013
CAL2M281I Heap Storage Data:
CAL2M281I Total 24117248
CAL2M281I In use 21580192
CAL2M281I Available 2537056
CAL2M297I Thread Counts:
CAL2M297I Active Inactive
CAL2M297I JFM Worker 1 16
CAL2M283I CA77 INSTANCE INFORMATION
CAL2M288I TYPE(COLD), HISTORY(1) hours, SPAN(1) hours, REFRESH(60) min
CAL2M288I CPMCCI(CpmServer), JFMCCI(JobFlowMgrCA77)
CAL2M288I CPMSRVR(N)
CAL2M288I Started 2013-08-13T10:36:25.472538-04:00
CAL2M298I The CA 7 TCP/IP Interface is active
CAL2M298I TCP/IP Terminal Host Name(USILCA11)
CAL2M298I TCP/IP Terminal Host Addr(141.202.65.11), PORT(65000)
CAL2M297I Query Worker 0 6
CAL2M289I Event Information:
CAL2M289I Count 0
CAL2M289I Time Received
CAL2M289I Time Created
CAL2M289I Last Request
CAL2M290I Object Counts:
CAL2M290I Current HWM
CAL2M290I Job 16 16
CAL2M290I Dataset 11 11
CAL2M290I JobStream 0 0
CAL2M290I Requirement 32 32
CAL2M290I RequiredBy 26 26
CAL2M290I XML 0 0
CAL2M290I System 26 26
CAL2M291I Total Cell Pool Counts:
CAL2M291I 64Byte 169 176
CAL2M291I 128Byte 12 12
CAL2M291I 256Byte 0 0
F jobflow,STATUS(SHORT)
CAL2M211I Command: STATUS(SHORT) received
CAL2M284I JOBFLOW MONITOR STATUS - SHORT REPORT
CAL2M292I DELTAINT(30), FACILITY(NONE), LOGLEVEL(0)
CAL2M292I JFMNAME(Jobflow Monitor production)
CAL2M287I PID 00000056, Size 11227136, MVS User TESTUSER
CAL2M287I Started Fri Jun 18 07:45:03 2010
F jobflow,STATUS(STORAGE)
CAL2M211I Command: STATUS(STORAGE) received
CAL2M280I JOBFLOW MONITOR STORAGE REPORT
CAL2M282I MainThread Cell Pool Counts:
CAL2M282I 128Byte 10 10
08-Feb-2018 310/722
CAL2M282I StatusUpdateThread Cell Pool Counts:
CAL2M282I StructureUpdateThread Cell Pool Counts:
CAL2M282I 64Byte 245 245
CAL2M282I 128Byte 256 256
CAL2M282I 256Byte 289 289
CAL2M282I 512Byte 103 103
CAL2M282I 2048Byte 101 101
CAL2M282I QueryRequestThread Cell Pool Counts:
STOP
Stops the specified monitor instance.
Example: STOP Command

F jobflow,STOP(INSTANCE(CA77))
CAL2M211I Command: STOP(INSTANCE(CA77)) received
CAL2M254I STOP monitor instance requested for: CA77
CAL2M171I Monitor (CA77) is stopping
CAL2M173I Monitor(CA77) has ended
Forecasting and Monitoring with Jobflow Monitor

During initialization, Jobflow Monitor (JFM) uses the CA Workload Automation CA 7® Edition queues
and databases to create a view, or window, of the CA Workload Automation CA 7® Edition workload.
The Jobflow Monitor window includes active work and forecasted work. The SPAN parameter of the
MONITOR initialization statement determines the size of the window.
The model of the CA Workload Automation CA 7® Edition workload is kept in memory, exploiting 64-
bit storage.
Forecasted work is built out using trigger and dependency definitions of the jobs in the active queues
and jobs that are schedule scanned in.
CA Workload Automation CA 7® Edition issues CAIENF CA7LOG events for which Jobflow Monitor
listens. These events tell JFM when jobs start, stop, and enter the CA Workload Automation CA 7®
Edition queues. These events also tell JFM what database changes have been made and what
operator commands have been issued that affect the status of a job. Jobflow Monitor uses this data
to keep its view of the CA Workload Automation CA 7® Edition workload up to date.
08-Feb-2018 311/722
CA7LOG events that affect jobs in the active workload are processed immediately. CA7LOG events
that affect jobs that are in the forecasted workload are not processed until the job enters the active
workload or the window refresh interval has expired.
The window refresh interval is the REFRESH parameter on the MONITOR initialization statement.
REFRESH defines how often to process the deferred CA7LOG events and to build out the Jobflow
Monitor window.
During a window refresh, JFM goes to the CA Workload Automation CA 7® Edition databases and
brings in triggers, dependencies, and schedule scanned jobs to build out the window to the SPAN
size. Deferred CA7LOG events are processed and dependencies are resolved.
For example, assume SPAN=12 hours and REFRESH=30 minutes. If Jobflow Monitor started at 8:00 a.
m., it built a forecasted window that started at 8:00 a.m. and ended at 8:00 p.m. During the next 30
minutes, CA Workload Automation CA 7® Edition issued CA7LOG events. JFM applied those events to
the active workload. At 8:30 a.m., the window refresh interval expires. Now, the JFM window
contains forecasted jobs from 8:30 a.m. to 8:00 p.m. Window refresh process gets data from the CA
Workload Automation CA 7® Edition databases to build out the JFM window so that it now contains
forecasted jobs from 8:30 a.m. to 8:30 p.m., or 12 hours, matching the requested window SPAN
value.
The RESOLVE operator command causes the processing of the deferred CA7LOG events and the
resolution of dependencies but does not build out the JFM window. Use the RESOLVE command if
you change the CA Workload Automation CA 7® Edition databases and you want JFM to process
those changes before the next window refresh interval.
Jobflow Monitor can also keep, in memory, history of job executions. The HISTORY parameter on the
MONITOR initialization statement controls the amount of history kept. When Jobflow Monitor first
starts, no history of job executions exists. History is built up over time until the HISTORY value is
reached. Now, the oldest jobs are deleted. HISTORY value is not included in the window SPAN size.
CPM Processing
Jobflow Monitor can provide Critical Path Monitor (CPM) tracking data. If you use Jobflow Monitor
(JFM) for CPM data, your critical path FLOWs include both trigger and dependency predecessors.
When a CA Workload Automation CA 7® Edition FLOW is initiated, CPM interfaces with JFM to get the
list of jobs, both trigger and dependencies, that determine the critical path. Jobflow Monitor issues
the CAIENF CPM status events as those jobs start and stop execution.
When CPM sends the request to JFM for the list of jobs, JFM validates both the starting job and the
ending job of the FLOW. IF JFM has no record of the starting job in the active workload or in history,
JFM cannot process the request, and CPM cannot track the critical path.
If JFM knows about the starting job, JFM validates that the ending job is a valid CA Workload
Automation CA 7® Edition job that is defined in the CA Workload Automation CA 7® Edition database.
If the ending job cannot be validated, JFM tells CPM that JFM cannot process the request, and CPM
cannot track the critical path.
Once the starting and ending jobs are validated, JFM can provide the list of jobs to CPM. If the ending
job of the FLOW is not currently in the JFM window, JFM returns a partial list of jobs to CPM. JFM
issues the start and stop CPM events for those jobs.
08-Feb-2018 312/722
If the ending job is not in the JFM window, JFM watches for the ending job during window refresh
processing. If the ending job comes into the forecast, JFM reinitiates CPM processing so that CPM can
obtain the complete list of jobs.
Jobflow Monitor watches for the ending job of a FLOW for a limited time. The time is calculated as
SLA of the FLOW plus the current SPAN value. For example, if the SLA of a FLOW is 1:30 p.m. and
SPAN is 8 hours, JFM watches for the ending job until 9:30 p.m. If the ending job does not enter the
forecast by the stop time, the CPM flow is incomplete.
If Jobflow Monitor stops during a critical path flow or is not available when a critical path flow starts,
recovery of these flows can occur the next time JFM starts. The TYPE parameter on the MONITOR
initialization statement controls this recovery processing.
If TYPE=WARM is specified, JFM uses CAICCI to find out from CPM if any CA Workload Automation CA
7® Edition FLOWs are active or incomplete. If FLOWs are active or incomplete, JFM reads the CA7LOG
events from the CAIENF database to attempt to recreate what the CA Workload Automation CA 7®
Edition workload looked like in the past. Jobflow Monitor then tries to recreate the CPM job list for
each active or incomplete FLOW. If successful, JFM can provide CPM with current data and begin
issuing start and stop events for the jobs defined to the FLOWs.
If TYPE=COLD is specified, JFM does not attempt the recovery process described previously.
If you want JFM to provide CPM tracking data, specify JFM=YES and CPM=JFM on the CA Workload
Automation CA 7® Edition OPTIONS initialization statement. If you activate JFM to provide the CPM
tracking data, CA Workload Automation CA 7® Edition does not issue the start/stop CPM events.
Encrypted Communications and JFM

To enable encrypted communications with the JFM address space requires configuring one of the
following encryption methods:
IBM System Secure Socket Layer (SSL)
IBM Application Transparent Transport Layer Security (AT-TLS)
Implement Support for SSL Transmission (see page 313)

Set Up to Use System SSL (see page 318)
Implement Support for AT-TLS Transmission (see page 319)
Implement Support for SSL Transmission

Set up the JFM address space to use one of the following methods:
IBM System Secure Socket Layer (SSL) toolkit using a key store file that is on a Hierarchical File
System (HFS).
Note: Execute the program gskkyman under OMVS at a shell prompt. Executing this
program creates a key store file on the HFS, generates a self-signed certificate authority
certificate, and generates a server certificate.
08-Feb-2018 313/722
External Security Manager (ESM)
Note: Execute the commands of your ESM to generate a server certificate.
Create a Key Store File

You can create a key store file on zFS or HFS when setting up the JFM address space to use SSL.
Follow these steps:
1. From a mainframe console, execute gskkyman.
2. Select Create new database and enter the path and file name to the new key store file or
database.
Note: The path and file names must be writable path or file names.
3. Enter a database password and enter the password expiration in days.
Note: Press ENTER if the password never expires.
4. Enter 5000 for the database record length and enter 0 for the database mode.
5. Wait for acknowledgment that the key database is created.
6. Select Exit program.

The key store file is created.
Create a Self-Signed Certificate Authority Certificate

You can create a self-signed certificate authority certificate when setting up the JFM address space to
use SSL.
Follow these steps:
2. Select Open database, enter the path to the database that you created, and enter the
database password.
The Key Management menu appears.
3. Select Create a self-signed certificate.
4. Select certificate authority certificate with 1024-bit RSA key and select SHA-512.
08-Feb-2018 314/722
Note: Selecting certificate authority certificate with 1024-bit RSA key creates the
certificate authority.
5. Enter a label for the self-signed certificate authority certificate and enter a common name.
Note: The common name can be the same as the label.
6. Provide data for the prompts regarding ownership of the certificate. Ownership includes the
following items:
Organizational unit
Organization
Organization city, state and country
7. Enter the number of days the certificate is valid and enter 0 to continue.
8. Wait until the certificate is created.

The self-signed certificate authority certificate is created.
Create a Server Certificate

You can create a server certificate when setting up the JFM address space to use SSL.
Follow these steps:
database password.
3. Select Manage keys and certificates and enter the number of the certificate authority
certificate to use.
Note: You can use the number that you previously created.
4.
08-Feb-2018 315/722
4. Select Create a Signed Certificate and Key, and select User or server certificate with 1024-bit
RSA key.
5. Enter a label for the server certificate and enter a common name.
following items:
Organizational unit
Organization
Organization city, state, and country
7. Enter the number of days the certificate is valid, and enter 0 to continue.

The server certificate is created.
Set the Server Certificate as the Default Certificate

You can set the server certificate as the default certificate when setting up the JFM address space to
use SSL.
Follow these steps:
2. Select Open database and enter the path to the database you created.
3. Enter the database password.

4. Select Manage keys and certificates and enter the number of the label for the server
certificate.
5. Select the option to set the key as the default.

The server certificate is set as the default certificate.
Export the Certificate Authority Certificate

You can export the certificate authority certificate when setting up the JFM address space to use SSL.
Follow these steps:
08-Feb-2018 316/722
Follow these steps:
2. Select Open database and enter the path to the database that you created.

4. Select Manage keys and certificates and enter the number of the label for the certificate
authority certificate to export.
5. Select Export certificate to a file and select Binary ASN.1 DER.
6. Enter the path name and file to export the certificate to and press Enter.

The certificate authority certificate is exported.
Store the Database or Key Store Password into a Stash File

You can store the database or key store password into a stash file when setting up the JFM address
space to use SSL.
Follow these steps:
2. Select Open Database and enter the path to the database that you created.
3. Enter the database password and select Store Database Password.

The file, database_name.sth, is stored where the database file is stored.

The database or key store password is stored into a stash file.
Import the Certificate Authority Certificate into a Java Key Database

You can import the certificate authority certificate into a Java key database when setting up the JFM
address space to use SSL.
Follow these steps:
1. Execute the keytool program that came with your Java SDK installation in superuser mode.
2. Enter the keystore password.

Default: changeit
3. Enter yes to trust the certificate.
Note: If the certificate is added successfully, the configuration is complete.
08-Feb-2018 317/722
3.
The certificate authority certificate is imported into a Java key database.
Example: Execute the keytool program
The following example illustrates how to execute the keytool program:

keytool - import - trustcacerts
- file /path/to/exported/ca/certificate
- keystore $JAVA_HOME/lib/security/cacerts
Set Up to Use System SSL

For the JFM address space to use System SSL, the PDSE member GSKSSL must be accessible to the
program by one of two methods:
Adding the PDSE named pdsename.SIEALNKE to the dynamic LPA (PROGxx member).
Note: For more information about setting up System SSL, see the IBM documentation z/OS
Cryptographic Service System Secure Sockets Layer Programming.
Modifying the JCL used to start the JFM address space. Add a DD statement for STEPLIB to include
a reference to pdsename.SIEALNKE.
If you are planning to use an HFS key database file, modify the JCL that is used to start the JFM
address space to:
Include a DD statement for KEYDB that specifies the USS path to the key database created in
Create a Key Store File.
Include a DD statement for STASH that specifies the USS path to the password stash file created in
Store the Database or Key Store Password Into a Stash File.
Change the CAJFPARM(JBFLWAS) configuration parameter member to specify the following

statement:
SSLRINGTYPE(KDB)
If you are planning to use an External Security Manager to manage your key database and
certificates, change the CAJFPARM(JBFLWAS) configuration parameter member to specify the
following statement:
SAFRING(userid/keyring)
If the server certificate you are using is not the default certificate in the key store, specify the label of
your server certificate in the CAJFPARM(JBFLWAS) configuration parameter member as follows:
SSLCERTLABEL(Your Server Certificate Label Here)
Change the CAJFPARM(JBFLWIP) configuration parameter member to specify ENCR(SSL) on the PORT()
statements that you are configuring to use SSL. For example:
PORT(NAME(QRYPORT1) NUMBER(12001) ENCR(SSL))
08-Feb-2018 318/722
Implement Support for AT-TLS Transmission

Application Transparent Transport Layer Security (AT-TLS) is a component of z/OS. AT-TLS provides
encryption services for applications that exchange sensitive data but have not been implemented to
include encryption. This service lets you encrypt data being sent to the application without adding
the extra API calls to do encryption.
To use AT-TLS with the JFM address space, you must have completed the following items:
Configuration of the Communications Policy Agent
Configuration of AT-TLS policies
Installation of Server Certificate and Certificate Authority Certificate
Note: For more information about IBM Policy Agent, see the IBM z/OS V1R11
Communications Server TCP/IP Implementation Volume 4: Security and Policy-Based
Networking.
JFM is “AT-TLS aware” and can be configured to confirm that AT-TLS has secured incoming
connection requests. To enable this support, change the CAJFPARM(JBFLWIP) configuration
parameter member to specify ENCR(ATTLS) on the PORT() statements that you configure to require
AT-TLS. For example:
PORT(NAME(QRYPORT2) NUMBER(12002) ENCR(ATTLS))
iDash and the CA 7 Server

CA 7 Server for iDash provides information about CA Workload Automation CA 7® Edition managed
objects to CA Workload Automation iDash. This information includes object definitions (seed data)
and notifications as objects change state (CA7LOG events).
Such workload information is typically obtained through terminal commands such as LJOB, LQ, or
08-Feb-2018 319/722
Such workload information is typically obtained through terminal commands such as LJOB, LQ, or
LRLOG. However, terminal commands must compete with other important functions that the
CA7ONL address space main task provides (like job submission and job completion).
For this reason, CA 7 Server for iDash extracts workload information without using services of the
CA7ONL address space main task. When workload definitions are needed (“seed” data), the server
connects directly to the CA Workload Automation CA 7 Edition database without using CA7ONL
terminal services. Object state changes are delivered to CA 7 Server for iDash without more CA7ONL
main task activity. This method frees CA7ONL to focus on the core work of scheduling.
The CA 7 Server for iDash runs in a separate address space on the CA7ONL host and uses TCP/IP and
XML services to communicate with iDash.
CA 7 Server for iDash addresses the need for iDash to have a mainframe-resident component with
access to mainframe workload events and CA Workload Automation CA 7 Edition database
definitions. When changes occur within definitions for portions of the workload that is defined within
CA Workload Automation CA 7 Edition, CA 7 Server for iDash serves an event notifying any subscribed
CA Workload Automation iDash servers of the change. These CA Workload Automation iDash servers
then request an extract of the specific database item as required, which is packaged and transmitted
by CA 7 Server for iDash. The first time that CA Workload Automation iDash connects with CA 7
Server for iDash for a particular CA 7 instance, CA 7 Server for iDash instead serves an extract, or seed
data file, of the entire CA Workload Automation CA 7 Edition database.
CA 7 Server for iDash supports only CA 7 instances starting with Version 12.0 RO89740 and RO89961
. CA 7 Server for iDash does not support previous releases or maintenance levels for Version 12.0.
You cannot intermix CA 7 instances that are monitored in CA 7 Server for iDash from any releases
before Version 12.0. If you do, an error for that particular instance occurs.
Important! For optimal performance, we recommend that you apply Common Services
CAIENF Release 14.1 PTF RO92964 .
CA 7 Server for iDash broadcasts event data to all subscribers and can recover event records in case
communication is interrupted.
Monitoring and Streaming

During initialization, CA 7 Server for iDash restores any durable subscriptions that are found in its
OMVS directory that is specified for this use (see the next topic Implement CA 7 Server for iDash). CA
7 Server for iDash examines their last known event to ensure that no events were missed while CA 7
Server for iDash was offline. If necessary, CA 7 Server for iDash initiates a recovery attempt for any
subscription that is behind the current events that are seen in the monitored instance for that
subscription.
08-Feb-2018 320/722
CA Workload Automation CA 7® Edition issues CA7LOG events for which CA 7 Server for iDash listens.
These events tell CA 7 Server for iDash when jobs start, stop, and move through the CA Workload
Automation CA 7 Edition queues. These events also tell CA 7 Server for iDash what database changes
have been made, and what operator commands have been issued that affect the status of a job. CA 7
Server for iDash communicates all this data to any CA Workload Automation iDash subscriber to
facilitate tracking of SLAs or workload prediction.
If any subscriber is unreachable or fails to respond to an event notification, CA 7 Server for iDash flags
that subscription for recovery and begins spooling event data from the monitored instance of CA
Workload Automation CA 7 Edition. This spooled event data is kept in memory, exploiting 64-bit
storage within the CA 7 Server for iDash address space, until CA 7 Server for iDash reestablishes
communication with the subscriber and successfully transmits the data. If a specific subscription
remains out of contact with CA 7 Server for iDash for long enough, CA 7 Server for iDash cancels the
subscription to free up that storage. The number of retry attempts before this cancellation occurs,
with other subscription controls, is configurable through CA Workload Automation iDash.
Implement CA 7 Server for iDash

Review the following topics before you start CA 7 Server for iDash.
Minimum z/OS Requirements

The following items are the minimum z/OS requirements for using CA 7 Server for iDash:
z/OS 1.7
APF authorized
IBM Language Environment
64-bit storage
CA7LOG Event
The CA7ONL address space optionally generates records of state changes to workload objects. These
records are known as CA7LOG events. CA 7 Server for iDash collects these event records and
forwards them to CA Workload Automation iDash as required.
To activate generation of the events, specify JFM=YES in the OPTIONS statement in the initialization
file.
Several sizing and customization concerns are particular to this use of CAIENF and the recording of
the CA7LOG event. While the following items are recommended as a minimum, it would be highly
beneficial to contact CA Datacom®/AD Support to tailor the MUF fully to your environment.
08-Feb-2018 321/722
Database Sizing
The data sets backing the ENF700 area within CA Datacom®/AD must be able to grow to keep pace
with your production workload. Using production workload amounts seen across several customer
sites, we recommend that you define the ENF700 area with the following attributes:
DSNTYPE=LARGE
Remove the track limit on extents within a single volume.
SMS-managed DATACLAS, STORCLAS, and/or MGMTCLAS

Remove the 16 extent limit and allow growth across multiple volumes
This method lets CA Datacom®/AD grow the ENF700 database dynamically as needed, without
outages or intervention. In addition, CA Datacom®/AD compression can be enabled to provide
growth with minimal DASD consumption.
Each site requires a different initial database size, which is based on various complex factors. Thus it
is difficult to provide a single sizing algorithm that is both sufficient and accurate at all sites. However,
as a guideline, here are some relative initial sizes that are based on workload monitored:
Workload Volume ENF700 Dataset Size (Primary,Secondary)

Small ( < 100k jobs per day) CYLS,(1000,100)
Medium ( > 100k jobs per day) CYLS,(2500,250)
Large ( > 200k jobs per day CYLS,(4500,500)
We recommend that you monitor the CAIENF task (or the external MUF, when configured as such)
closely for the first few weeks until the database has grown enough to accommodate the largest day
in your normal workload. At that point, you can reallocate the database using what the allocation
grew to as the primary, with a secondary of approximately 10 percent of the primary.
MUF Configuration
Within your CA Common Services for z/OS CUSMAC library (or the appropriate CA Datacom®/AD
library for External MUFs), you find the AXDATIN1 member that contains some of the MUF startup
parameters. Edit or add the following items to improve the efficiency of database operations per
MIPS:
COVERED IXX700,9G
Moves CAIENF database index into 64-bit storage for speed
DATAPOOL 8K,10000,16K,2
Increases the number of buffers for record work data retrieval within the CA Datacom®/AD MUF
FLEXPOOL 1,1,1
Allows dynamic alteration of a flexible buffer pool counts while MUF is up
SYSPOOL 10,2000,8000,4096,64
Increases the number of buffers for the MUF internal work index processing within the MUF
08-Feb-2018 322/722
VIRTUAL TTM017,9G
Increases the size of the SQL ‘scratch’ area (in 64-bit memory) to accommodate volume of
CA7LOG events
Sample User JCL

The sample JCL for using CA 7 Server for iDash is in the sample JCL library, CAL2JCL, as the member
AL2IDASH.
Input DD Statements
The following items are the CA 7 Server for iDash input DD statements:
STEPLIB
Specifies the CA 7 Server for iDash load library, the CA Workload Automation CA 7 Edition load
library, and the IBM Language Environment load libraries.
CAJFPARM
Specifies the data set containing the CA 7 Server for iDash startup parameters.
CEEOPTS
Specifies the Language Environment options that CA 7 Server for iDash requires.
The following output DD statements are used in CA 7 Server for iDash:
CEEDUMP
Specifies the IBM Language Environment CEE3DMP Report output area. This value is typically sent
to SYSOUT to include it with the basic CA 7 Server for iDash task output if an abend occurs.
CAJFLOG
Specifies the data set definition for the CA 7 Server for iDash log. CA 7 Server for iDash uses this
DD statement for diagnostic logging. This DD statement is optional. If this DD statement is not
allocated during CA 7 Server for iDash startup, diagnostic logging does not occur. The LOGLEVEL
setting, an address space parameter, establishes the level of diagnostic logging that is used during
the CA 7 Server for iDash session. Also, the LOGLEVEL command lets you change this setting after
CA 7 Server for iDash is started. Use the LOGLEVEL setting and command only at the direction of
CA Support.
CAJFnnnn
If the PRINTLOG command is issued, CA 7 Server for iDash dynamically allocates the next available
CAJFnnnn DD and uses it to print the internal CA 7 Server for iDash log. Use the PRINTLOG
command only at the direction of CA Support.
Optional SYSTCPD DD Statement

Depending on your local implementation of TCP/IP, it is sometimes necessary to add a SYSTCPD DD
statement to your CA 7 Server for iDash JCL.
08-Feb-2018 323/722
Initialization Parameters (CA 7 Server for iDash)

CA 7 Server for iDash product initialization parameters are specified in the PDS where the CAJFPARM
ddname points.
The CA 7 Server for iDash address space parameters are defined in the IDASHAS member. Refer to
member AL2IDSAS in the CA Workload Automation CA 7® Edition CAL2OPTN data set for an example.
The CA 7 Server for iDash subscription parameters are defined in the IDASHEV member. All
subscriptions that are begun with this CA 7 Server for iDash are saved to the OMVS directory
specified by the PATHNAME keyword. These subscriptions are then automatically loaded when the
CA 7 Server for iDash address space is started. Refer to member AL2IDSEV in the CA Workload
Automation CA 7 Edition CAL2OPTN data set for an example.
The TCP/IP configuration data is defined in the IDASHIP member using the PORT keyword. Refer to
member AL2IDSIP in the CA Workload Automation CA 7 Edition CAL2OPTN data set for an example.
The CA 7 Server for iDash Monitor instances are defined in the IDASHMN member using the
MONITOR keyword. All instances that are defined in IDASHMN are automatically started when the CA
7 Server for iDash address space is started. Refer to member AL2IDSMN in the CA Workload
Automation CA 7 Edition CAL2OPTN data set for an example.
The Language Environment options that CA 7 Server for iDash requires are specified in the JCL
member. These settings are tuned for CA 7 Server for iDash, and are only in effect while CA 7 Server
for iDash is running. Refer to member AL2IDASH in the CA Workload Automation CA 7 Edition
CAL2JCL data set for an example.
Initialization file statements must be in columns 1-72. Any data past column 72 is ignored. Lines that
begin with either an asterisk (*) or a forward slash (/) are considered comment lines. Enter all
keywords and values in uppercase, unless otherwise noted. The initialization statement parameters
are enclosed in parentheses and each parameter value is enclosed in parentheses. The blank spaces
on any line and blank lines are ignored. If an initialization statement must continue on the next line,
no special continuation character is needed.
Address Space Statements (CA 7 Server for iDash)

This topic describes statements available for the CA 7 Server for iDash address space.
EVENTS
(Required) Specifies whether CA 7 Server for iDash supports CA 7 Event Subscription. This setting
should not be changed from the ONLY value. If it is, CA 7 Server for iDash emits an error and fails
to initialize.
Default: No default
ONLY
CA 7 Server for iDash publishes CA 7 events to subscribers. This value is the only valid choice.
EXTRACTPATH
(Required) Specifies the absolute USS path name where CA Workload Automation CA 7 Edition
data extract files are placed.
Specify a USS pathname from 1 to 60 characters.
Default: No default
Example: EXTRACTPATH statement
08-Feb-2018 324/722
EXTRACTPATH(/u/users/myjfm/extractpath)
FACILITY
(Optional) Specifies the resource class to use on security calls in CA 7 Server for iDash for all XML
queries. The value can range from 1 to 8 characters.
Note: Any value that is set takes effect on the next authorization call made.
Default: NONE
NONE
Bypasses all resource authorization checks in CA 7 Server for iDash, including checks for access
to CA 7 Server for iDash. This value is the default.
YES
Uses CA7JFM as the resource class on the security call.
Example: FACILITY statement
FACILITY(NONE)
JFMNAME
(Optional) Specifies a name to associate with the CA 7 Server for iDash job or started task that is
running.
The value can range from 1 to 32 characters in length.
The value can contain one or more of the following valid characters: period (.), dash (-),
underscore (_), 0-9, a-z, and A-Z.
Default: If not provided, a default in the following format is generated:
JFM.jobname
jobname
Identifies the JOBNAME (or STC name) of the CA 7 Server for iDash that is running.
Example: JFMNAME statement
JFMNAME(JFM.CAIJFM1)
LOGLEVEL
(Optional) Specifies whether to activate diagnostic logging and at what level.
Use the LOGLEVEL setting and command only the direction of CA Support.
Default: 0
0
Performs no diagnostic logging. This value is the default.
1
2
3
Performs all logging except memory and data structure management.
08-Feb-2018 325/722
7
Performs all logging except memory management.
8
Note: If LOGLEVEL contains a value greater than zero, allocate the CAJFLOG DD in the CA 7
Server for iDash startup JCL, or no diagnostic logging occurs.
Example: LOGLEVEL statement

LOGLEVEL(0)
SAFRING
(Required if SSLRINGTYPE(SAF) is specified; otherwise, optional) Specifies the name of the SAF
keyring.
The name is specified in the following format:
userid/keyring
userid
Indicates a 1 through 8 character user ID.
keyring
Indicates a 1 through 8 character key ring name.
The current userid that is associated with the CA 7 Server for iDash job or started task is used
when the userid is omitted. The user must have READ access to the IRR.DIGTCERT.LISTRING
resource in the FACILITY class when using a SAF key ring that the user owns. The user must have
UPDATE access to the IRR.DIGTCERT.LISTRING resource in the FACILITY class when using a SAF key
ring that another user owns.
Note: Certificate private keys are not available when using a SAF key ring that another
user owns.
If this parameter is specified, the SSLRINGTYPE(SAF) parameter must also be specified.

Examples: SAFRING statement
SAFRING(KEYRING1)
SAFRING(MYUSERID/KEYRING2)
SSLCERTLABEL
(Optional) Specifies the label of the certificate in the key ring that is used to authenticate the
application.
Specify a string from 1 to 58 characters.
If this parameter is specified, the SSLRINGTYPE parameter must also be specified.
Default: If not specified, the default certificate from the key ring is used.
Example: SSLCERTLABEL statement

SSLCERTLABEL(My certificate label)
08-Feb-2018 326/722
SSLRINGTYPE
(Optional) Indicates that System SSL is supported in the CA 7 Server for iDash job or started task
and specifies the type of key database to use.
Default: No default. If SSLRINGTYPE is not specified, SSL is not supported in the CA 7 Server for
iDash.
KDB
Indicates the use of an HFS key database and the password stash file. The KEYDB and STASH
DD statements in the CA 7 Server for iDash startup JCL specify the path to the USS files where
the key database and the password stash file reside.
SAF
Indicates the use of a SAF key ring. The SAFRING parameter is required.
Example: SSLRINGTYPE statement

SSLRINGTYPE(KDB)
STATICNODE
(Optional) Defines a replacement value for the z/OS System Name (SMF ID), which is typically
acquired programmatically. This value is used when the host LPAR for CA 7 and CA 7 Server for
iDash can change, but you want CA Workload Automation iDash to treat the events as though
they were coming from the same CA 7. This setting is rarely needed. The value can be any
combination of 4 characters, including alphabetic, numeric, and special characters.
The identifier can range from 1 to 4 characters in length.
The value can contain any valid EBCDIC or National character permitted by IBM as part of a
System Name.
Default: If not provided, the IBM System Name is used.
Example: STATICNODE Statement
STATICNODE PRD1
Event Configuration Options (CA 7 Server for iDash)

These statements are available for Event Configuration options in the CA 7 Server for iDash address
space.
The IDASHEV member defines CA 7 Server for iDash event configuration options that are used in the
CA 7 Server for iDash address space for the CA 7 Web Services when processing events.
All these options are applicable to all CA 7 instances being monitored and are defined in the
CAJFPARM(IDASHMN) member.
CAPTURE
(Optional) Indicates whether a capture table is used for CA 7 Web Services events. All CA 7
instances that are selected for processing process all events that are captured. For more
information, see the MONITOR Statement.
The keyword value must contain the number of entries to hold in the capture table. The value
must be numeric and between a value of 100 and 10000.
A value of zero indicates that an events capture table is not used.
Default: 1000
Example: CAPTURE statement
CAPTURE(1000)
DURABLE
08-Feb-2018 327/722
DURABLE
(Required) Determines whether to allow durable subscriptions. Durable subscriptions are
subscriptions that are saved on a disk in a USS file directory. CA 7 Server for iDash loads them into
memory each time it is started. This setting should not be changed from the YES value. If it is
changed, CA 7 Server for iDash does not accept subscriptions from CA Workload Automation
iDash.
YES
Indicates that durable subscriptions are allowed. This keyword also requires that options
PATHNAME and SUBSCRIBE(YES) are set. Refer to these keywords for more information.
Example: DURABLE statement
DURABLE(YES)
GUARANTEED
(Required) Indicates whether CA 7 Server for iDash attempts to ensure the delivery of events to a
client that is subscribed to a durable subscription. This setting should not be changed from the
YES value. If it is, CA 7 Server for iDash does not accept subscriptions from CA Workload
Automation iDash.
This guarantee means that:
The package of captured events is successfully sent to the client using TCP/IP.
A zero return code from the function was received.
An HTTP response of 200 was received from the send operation.
YES
Indicates that CA 7 Server for iDash attempts to ensure the delivery of events to a client that
is subscribed to a durable subscription. This keyword requires that the DURABLE(YES)
keyword option is also selected. For more information, see the DURABLE and SUBSCRIBE
keyword descriptions.
Example: GUARANTEED statement

GUARANTEED(YES)
MAXEVENTS
(Optional) Indicates the amount of memory that each subscription uses. This value is the
maximum number of events that any one subscription can monitor.
The MAXEVENTS value must be numeric and between a value of 100 and 1000000.
Default: 1000
Example: MAXEVENTS statement
MAXEVENTS(1000)
MAXSUBS
(Optional) Indicates the number of subscriptions allowed.
The MAXSUBS value must be numeric and between a value of 0 and 1000. If SUBSCRIBE(YES) was
specified, the value of MAXSUBS must be greater than zero.
Default: 100
Example: MAXSUBS statement
MAXSUBS(100)
08-Feb-2018 328/722
PATHNAME
(Required) Specifies the absolute USS path name where durable subscriptions are stored. This
keyword is required when DURABLE(YES) is specified.
The USS path name must be predefined. If this option is used, the path name that is specified
must contain 1-63 characters in length and can be specified in mixed-case.
CA 7 Server for iDash saves each durable subscription in this directory when requested by a web
service client when a durable subscription is processed. Each durable subscription is saved in this
directory and is suffixed with “.xml”.
When CA 7 Server for iDash is started, all durable subscriptions are read from this directory and
are stored in memory.
Note: This directory is for the exclusive use of CA 7 Server for iDash for the sole purpose of
storing and retrieving durable subscriptions. Do not store other files in this directory.
Example: PATHNAME statement

PATHNAME(/u/users/JobflowMonitorDurableSubscriptions/)
SUBSCRIBE
(Required) Indicates whether to allow subscriptions. Do not change this setting from the ‘YES’
value. If it is changed, CA 7 Server for iDash cannot accept subscriptions.
YES
Indicates that subscriptions are allowed. This option enables the use of options MAXEVENTS,
MAXSUBS, and DURABLE. For more information, see these keyword descriptions.
Example: SUBSCRIBE statement

SUBSCRIBE(YES)
MONITOR Statement (CA 7 Server for iDash)

The MONITOR statement provides information about the CA 7 instances to monitor.
If an error occurs while processing the MONITOR statements, no more statements are processed.
Any MONITOR statements read before an error occurs are processed.
INSTANCE
Specifies which CA 7 instance to monitor. The instance must be CA71 through CA78 inclusive. No
aliases are permitted.
Limits: CA71 - CA78
Example: MONITOR Statement

MONITOR(INSTANCE(CA72))
08-Feb-2018 329/722
PORT Statement (CA 7 Server for iDash)

This article details the PORT statement. CA 7 Server for iDash uses TCP/IP to communicate with other
programs. The PORT statement tells the CA 7 Server for iDash address space which ports to use for
communication and whether the traffic is encrypted. Multiple PORT statements with varying port
numbers and encryption modes can be specified.
This statement has the following parameters:
NAME
Provides an alias name for the port containing up to 256 characters.
NUMBER
Specifies the port number.
ENCR
Specifies whether to support encryption on the port.
Default: NONE
The following values are valid:
NONE
Uses no encryption on the port. All data is transmitted in clear text.
SSL
Uses IBM System SSL to encrypt the data that is transmitted on the port.
ATTLS
Indicates that AT-TLS is used to encrypt data that is transmitted on the port. CA 7 Server for
iDash is AT-TLS aware and ensures that connections established to ports defined with ENCR
(ATTLS) are actually under control of AT-TLS. If not, the connection is closed.
Example: PORT statement

PORT(NAME(IDSCLEAR) NUMBER(12001) ENCR(NONE))
PORT(NAME(IDSSECURE1) NUMBER(12002) ENCR(SSL))
PORT(NAME(IDSSECURE2) NUMBER(12003) ENCR(ATTLS))
Operator Commands (CA 7 Server for iDash)

To start a CA 7 Server for iDash address space, submit a batch job or issue the following command. In
the command, idssrvr is the name of the started task JCL member.
S idssrvr
To stop a CA 7 Server for iDash address space, issue the following command where idssrvr is the
started task or job name:
P idssrvr
To issue a command to a running CA 7 Server for iDash instance, the command must be directed to
the address space and toward a specific monitor instance. To direct the command, CA 7 Server for
iDash commands are prefixed with the following:
F idssrvr,INSTANCE(CA 7 instance list)
08-Feb-2018 330/722
F idssrvr,INSTANCE(CA 7 instance list)
INSTANCE(CA 7 instance list) identifies which CA 7 Server for iDash instances execute the command.
The CA Workload Automation CA 7 Edition identifier is the same one specified in the INSTANCE
parameter of the MONITOR() statement. The list can contain a single CA Workload Automation CA 7
Edition identifier or a comma-delimited list. No aliases are permitted.
INSTANCE(*) or INSTANCE(ALL) directs the command to all monitor instances in the address space.
If the INSTANCE keyword is omitted and only one monitor instance is active in the address space, the
command is directed toward that monitor.
If the INSTANCE keyword is omitted and more than one monitor instance is active in the address
space, the command is rejected.
The INSTANCE keyword can be shortened to ‘I’.
The following modify commands are available:
CLEARLOG
Requests that CA 7 Server for iDash clears the current log file that is maintained in memory.
Example: CLEARLOG Command
F idssrvr,CLEARLOG
CAL2M211I Command: CLEARLOG received
CAL2M261I CLEARLOG request was processed
FACILITY(value)
Dynamically changes the resource class to use on security calls in CA 7 Server for iDash for all
Web Service XML queries.
The valid values can range from 1 to 8 characters.
If FACILITY(NONE) is specified, all resource authorization checks in CA 7 Server for iDash are
bypassed, including checks for access to CA 7 Server for iDash.
If FACILITY(YES) is specified, CA7JFM is used as the resource class on the security call.
Example: FACILITY Command
F idssrvr,FACILITY(NONE)
CAL2M211I Command: FACILITY(NONE) received
CAL2M250I FACILITY will be set to NONE
HELP(cmd)
Gives detailed syntax help for the specified CA 7 Server for iDash command.
If cmd is omitted, provides help on all CA 7 Server for iDash commands.
Example: HELP Command
F idssrvr,HELP
CAL2M211I Command: HELP received
CAL2M270I Available keywords for CA 7 Server for iDash modify command:
CAL2M270I + Instance(*|All|CA7n,...) - Direct to monitor instance
CAL2M270I + Alter(Span(nn)|(Refresh(nn)|History(nn)) - Change settings
CAL2M270I + Clearlog - Clear the current log file
CAL2M270I + Facility(xxxx) - Change security facility setting
CAL2M270I + Help(command|Help) - Command help information
CAL2M270I + Loglevel(0|1|2|3) - Diagnostic logging options
CAL2M270I + Printlog - Print the current log file
CAL2M270I + Resolve - Force dependency resolution
CAL2M270I + STARt - Start monitor instances
CAL2M270I + STOp - Stop monitor instances
08-Feb-2018 331/722

F idssrvr,HELP(FACILITY)
CAL2M279I on security calls in CA 7 Server for iDash for all Web Service

F idssrvr,HELP(FACILITY)
CAL2M279I on security calls in CA 7 Server for iDash for all Web Service

F idssrvr,HELP STATUS
CAL2M211I Command: HELP STATUS received
CAL2M275I STATus(SHort|Verbose|STorage) - Display monitor status
CAL2M275I + SHort - provides an overview about active monitors
CAL2M275I + Verbose - shows detailed information about active monitors
CAL2M275I + STorage - provides detailed storage information about
CAL2M275I + active monitors
LOGLEVEL(n)
Specifies whether to activate diagnostic logging and at what level.
0
Performs no diagnostic logging.
1
2
3
Performs all logging, except memory and data structure management.
7
Performs all logging except memory management.
8
08-Feb-2018 332/722
Note: If LOGLEVEL contains a value greater than zero, allocate the CAJFLOG DD in the CA 7
Server for iDash startup JCL, or no diagnostic logging occurs.

F idssrvr,LOGLEVEL(0)
CAL2M211I Command: LOGLEVEL(0) received
CAL2M249I LOGLEVEL will be set to 0
PRINTLOG
Prints the current CA 7 Server for iDash log file. This command dynamically allocates the next
available CAJFnnnn ddname to use, opens the file, writes the current log file, closes the file, and
frees the file.
This command lets operations obtain output that is generated to the CAJF nnnn DD without
having to bring down or recycle the CA 7 Server for iDash task.
Note: Use the PRINTLOG command only at the direction of CA Support.
Example: PRINTLOG Command

F idssrvr,PRINTLOG
CAL2M211I Command: PRINTLOG received
CAL2M257I PRINTLOG request was processed to DDNAME: CAJF0001
START
Starts the monitor instance. This keyword requires the INSTANCE keyword.
The JBFLWMN member for the requested instance must contain a MONITOR statement.
Example: START Command
F idssrvr,START(INSTANCE(CA77))
CAL2M211I Command: START(INSTANCE(CA77)) received
CAL2M241I The requested INSTANCE(S) will be started: CA77
STATUS
Returns the monitor status. The INSTANCE keyword is not used with any STATUS command. The
default value for the STATUS command is STATUS(VERBOSE).
VERBOSE
Provides detailed information about the CA 7 Server for iDash instances running in the
A list of the CA 7 Server for iDash instances to include in the output
CA 7 Server for iDash assembly information
A list of the current CA 7 Server for iDash options in effect
A list of the active CA 7 Server for iDash instances
Detailed CA 7 Server for iDash processing data information
CA 7 Server for iDash Heap storage availability and usage
08-Feb-2018 333/722
The following information is listed for each active CA 7 Server for iDash monitor instance:
Current options in effect.
A list of the current CA Workload Automation iDash subscriptions registered
Event information and counts
Current and total object counts by object type
Current and total cell pool counts by size of the cell pool
SHORT
Provides some overview information about the CA 7 Server for iDash instances running in the
A list of the CA 7 Server for iDash instances that are included in the output
CA 7 Server for iDash assembly information
A list of the current CA 7 Server for iDash options in effect
A list of the active CA 7 Server for iDash instances
Detailed CA 7 Server for iDash processing data information
STORAGE
Provides detailed storage usage about the CA 7 Server for iDash instances running in the
A list of the CA 7 Server for iDash instances that are included in the output
CA 7 Server for iDash Heap storage availability and usage
The following information is listed for each active CA 7 Server for iDash instance:
Current and total cell pool counts by thread and size of the cell pool.
Example: STATUS Command

F idssrvr,STATUS
CAL2M211I Command: STATUS received
CAL2M284I CA 7 SERVER FOR IDASH STATUS - VERBOSE REPORT
CAL2M299I Parameter Member Prefix: IDASH
CAL2M292I DELTAINT(59), FACILITY(NONE), LOGLEVEL(0), EVENTS
(ONLY)
CAL2M292I EXTRACTPATH(/u/users/myjfm/extractpath)
CAL2M293I Event Configuration Options in effect:
CAL2M293I CAPTURE(1000), MAXSUBS(100), MAXEVENTS(1000)
CAL2M293I SUBSCRIBE(YES), DURABLE(YES), GUARANTEED(YES)
CAL2M293I PATHNAME(/u/users/JobflowMonitorDurableSubscriptions
/)
08-Feb-2018 334/722
CAL2M287I Started Tue Aug 13 10:34:14 2013
CAL2M297I JFM Worker 1 16
CAL2M288I Started 2013-08-13T10:36:25.472538-04:00
CAL2M297I Query Worker 0 1
CAL2M269I Subscription Information:
CAL2M269I NAME(iDash idash3.mybiz.
com CA77)
CAL2M269I TARGET ADDR:PORT(123.45.678.901:8080)
CAL2M269I INTERVALS: PUSH(60) DELAY(10) RETRY(300)
CAL2M269I RETRY COUNT(750) RETRIES LEFT(750)
CAL2M269I MINIMUM EVENTS(10) MAXIMUM RECORDS(500)
CAL2M269I DURABLE(Y) GUARANTEED(Y) HEARTBEAT(Y)
CAL2M269I LAST EVENT: TIME(2013-08-13T17:36:41.070000-05:00) SEQ(631903)
CAL2M269I NOTIFY FLAGS(PUSH)
CAL2M269I NOTIFY MODE(LIVE)
CAL2M289I Event Information:
CAL2M289I Count 355
CAL2M289I Time Received 2013-08-13T17:36:42.862156-05:00
CAL2M289I Time Created 2013-08-13T17:36:41.070000-05:00
CAL2M289I Last Request JFJBMISS
CAL2M290I Object Counts:
CAL2M290I Job 0 0
CAL2M290I Dataset 0 0
CAL2M290I JobStream 0 0
CAL2M290I Requirement 0 0
CAL2M290I RequiredBy 0 0
CAL2M290I XML 0 1
CAL2M290I System 0 0
CAL2M291I Total Cell Pool Counts:
CAL2M291I 64Byte 169 176
CAL2M291I 128Byte 12 12
F idssrvr,STATUS(SHORT)
CAL2M211I Command: STATUS(SHORT) received
CAL2M284I CA 7 SERVER FOR IDASH STATUS - SHORT REPORT
CAL2M299I Parameter Member Prefix: IDASH
CAL2M292I DELTAINT(59), FACILITY(NONE), LOGLEVEL(0), EVENTS
(ONLY)
CAL2M292I EXTRACTPATH(/u/users/myjfm/extractpath)
CAL2M293I Event Configuration Options in effect:
CAL2M293I CAPTURE(1000), MAXSUBS(100), MAXEVENTS(1000)
CAL2M293I SUBSCRIBE(YES), DURABLE(YES), GUARANTEED(YES)
CAL2M293I PATHNAME(/u/users/JobflowMonitorDurableSubscriptions
/)
CAL2M287I PID 00000056, Size 11227136, MVS User TESTUSER
CAL2M287I Started Fri Jun 18 07:45:03 2010
F idssrvr,STATUS(STORAGE)
CAL2M211I Command: STATUS(STORAGE) received
CAL2M280I CA 7 SERVER FOR IDASH STORAGE REPORT
08-Feb-2018 335/722
CAL2M282I MainThread Cell Pool Counts:
CAL2M282I 128Byte 10 10
CAL2M282I QueryRequestThread Cell Pool Counts:
STOP
Stops the specified monitor instance.
Example: STOP Command
F idssrvr,STOP(INSTANCE(CA77))
CAL2M211I Command: STOP(INSTANCE(CA77)) received
CAL2M254I STOP monitor instance requested for: CA77
CAL2M171I Monitor (CA77) is stopping
CAL2M173I Monitor(CA77) has ended
Storage Considerations (CA 7 Server for iDash)

This article explains storage considerations for CA 7 Server for iDash. Some sites might want to adjust
the storage requirements for the CA 7 Server for iDash startup JCL. The JCL is listed in the Sample
User JCL member AL2IDASH. Whether you adjust the storage requirements depends on several
factors, including the following items:
The number of iDash subscriptions that you plan to register
The number of CA 7 instances you want to monitor
The number of jobs in each CA 7 instance entering the queues for that instance
Before you change the storage parameters, remember that limiting these values can severely impact
the performance of CA 7 Server for iDash. Up to, and including, memory-related abends.
The MEMLIMIT parameter in the startup JCL determines the amount of 64-bit memory that CA 7
Server for iDash can use.
A MEMLIMIT=NOLIMIT parameter in the startup JCL is the amount of 64-bit memory that is set up as
a default. You can change the MEMLIMIT limit by overriding the parameter in the execution JCL or
changing the in-stream PROC.
Also, the REGION parameter in the startup JCL determines the amount of 31-bit memory that CA 7
Server for iDash can use.
08-Feb-2018 336/722
A REGION=0M is the maximum amount of 31-bit memory that is set up as a default. You can change
the REGION limit by overriding the parameter in the execution JCL or changing the in-stream PROC.
Security Requirements (CA 7 Server for iDash)

CA 7 Server for iDash executes as a started task as distributed (it can also execute as a batch job if
necessary). As a started task, a started task user ID must be defined to the installation security
system.
If the FACILITY option is used to activate security in CA 7 Server for iDash on the XML query calls, the
following access is necessary:
The ID that is used to start CA 7 Server for iDash requires READ access to BPX.SERVER.
The ID that is used on the XML request requires a valid z/OS userId and password.
The ID that is used on the XML request requires access to CA 7 Server for iDash.
The ID that is used on the XML request requires access to the resource class defined on the
FACILITY keyword.
The ID that is used on the XML request requires access to one or more XML query resources.
CA 7 Server for iDash validates users from external sources using the XML services through standard
SAF RACROUTE calls. Thus, users using the XML services must have a valid z/OS user ID defined on
the z/OS security system. This user ID is sent to CA 7 Server for iDash when XML services are
requested and are used for authentication.
The SAF resource class that the CA 7 Server for iDash address space uses is defined in the FACILITY
address space options. Thus, each CA 7 Server for iDash can have different rules that are set up based
on the resource class name.
You can use FACILITY(NONE) to bypass all resource authorization checks that CA 7 Server for iDash
makes. This bypass includes checks for access to CA 7 Server for iDash and access to one or more XML
queries being sent to CA 7 Server for iDash through web services.
The default FACILITY value is NONE, which indicates that security is not invoked. See the FACILITY
address space option for more information.
Access to CA 7 Server for iDash is controlled using the resource key CA7JFM.ACCESS with READ
access. A resource call is made to the resource class with key CA7JFM.ACCESS. Users without READ
access to CA7JFM.ACCESS cannot use the CA 7 Server for iDash web services to invoke the XML query
that was requested.
All XML query resource names are prefixed with the following name: CA7JFM.XML. queryname, where
queryname contains the specific resource name that is associated with the XML query being
performed.
Security verifies that the user associated with the specific XML query has READ level access.
08-Feb-2018 337/722
Configure CA ACF2 Security

Configuring CA7JFM in a CA ACF2™ system includes the following steps:
Define CA7JFM to CA ACF2 (see page 338)

Define CA7JFM Resource Rules (see page 338)
Define CA7JFM to CA ACF2

CA 7 Server for iDash generally executes as a started task in the z/OS system and thus requires that
you assign an STC user ID. Also, because multiple users are signing on to each, CA 7 Server for iDash
address space acts as a multiple-user, single address space system, or MUSASS. The MUSASS
attribute is assigned. Also, to permit the taking of complete dumps when the CA 7 Server for iDash
address space abends, the DUMPAUTH attribute is requested.
INSERT CA7JFM NAME(CA 7 Server for iDash) STC MUSASS DUMPAUTH
Note: Because CA7JFM uses TCP/IP for its communications in its web services, the user ID associated
with CA 7 Server for iDash requires OMVS access to the following areas:

With CA ACF2, users must define what resource class is mapped to CA ACF2.
This definition is accomplished using the Class Map facility by defining the resource class and then
defining a three-character type to which this resource class is known in CA ACF2. Using the example
CA7IDSD, coded on the CA 7 Server for iDash Address Space options FACILITY statement, a class map
definition can look like the following example:
CLASMAP.CA7JFM RESOURCE(CA7IDSD) TYPE(SRV)
Now, when CA 7 Server for iDash issues the SAF call, CA ACF2 knows to protect the resource class.
After this class map is defined, define resource rules to map who has access to CA 7 Server for iDash
itself and each XML query.
Define CA7JFM Resource Rules

Using our previous CA7IDSD resource class example, we must define the following rules:
Any user who is permitted to use CA 7 Server for iDash for XML Web Services requires READ access to
the CA7JFM.ACCESS resource:
$KEY(CA7JFM.ACCESS) TYPE(SRV)
UID(ui-users) SERVICE(READ) ALLOW
Also, any user who is permitted to use CA 7 Server for iDash for XML Web Services requires that you
required.
08-Feb-2018 338/722

$KEY(CA7JFM.XML.QUERYWORKFLOW) TYPE(SRV)
Note: For more information, see XML query resource names (https://docops.ca.com/display/CA712
/XML+Query+Resource+Names).
Configure CA Top Secret Security

Configuring CA7JFM in a CA Top Secret® system includes the following steps:
Define CA7JFM to CA Top Secret (see page 339)

Define the CA7JFM Resource Rules (see page 340)
Define CA7JFM to CA Top Secret

CA 7 Server for iDash generally executes as a started task in the z/OS system and thus requires the
definition of an STC ACID. This definition identifies the started task name, the procedure from which
the started task executes, and associates a facility with the started task ACID. You can use security
definitions already in place to set up the started tasks or use the following samples to create new
security definitions.

TSS MODIFY(FAC(USERxx=NAME=CA7JFM)
TSS MODIFY(FAC(CA7JFM=ASUBM,LOG(ALL),MULTIUSER,NOABEND,PGM=CAL2J))
TSS CREATE(CA7JFM) NAME('CA 7 Server for iDash ACID') FAC(STC,BATCH) +
TYPE(USER) PASS(NOPW) DEPT(CA7OPS) MASTFAC(CA7JFM)
TSS ADDTO(STC) PROCNAME(CA7JFM) ACID(CA7JFM)
TSS CREATE(CA7GROUP) TYPE(GROUP) NAME(‘CA 7 Server for iDash GROUP’) DEPT(xxxx)
TSS ADD(CA7GROUP) GID(?) RANGE(xxxxx,yyyyy)
HOME(/u/users/cai/)
Each CA 7 Web Client user requires access to the CA7JFM facility directly or through a profile:
TSS ADD(xxxxxxx) FAC(CA7JFM)
Because CA7JFM uses TCP/IP for its communications in its web services, the user ID associated with
CA 7 Server for iDash requires OMVS access to the following areas:

With CA Top Secret®, users must define the SAF resource class to CA Top Secret.
This definition is accomplished using the following commands. In this example, the CA 7 Server for
iDash Address Space options have FACILITY(CA7JFMD).
08-Feb-2018 339/722
TSS ADDTO(RDT) RESCLASS(CA7JFMD) ACLST(READ) MAXLEN(40)
TSS ADDTO(dept) CA7JFMD(CA7JFM)
Define the CA7JFM Resource Rules

the CA7JFM.ACCESS resource:
TSS PER(ui-userid) CA7JFMD(CA7JFM.ACCESS) ACCESS(READ)
Also, any user who is permitted to use CA 7 Server for iDash for XML Web Services requires that you
required.


TSS PER(admin-userid) CA7JFMD(CA7JFM.XML.QUERYWORKFLOW) ACCESS(READ)
Note: For more information, see XML query resource names (https://docops.ca.com/display
/CA712/XML+Query+Resource+Names).
Configure IBM RACF Security

Configuring CA 7 Server for iDash in an IBM RACF system includes the following steps:
Define the Resource Class to the Resource Descriptor Table (see page 340)
Define the Resource Class to the Router Table (see page 341)
Activate the New Resource Class (see page 341)
Define the CA 7 Server for iDash Started Task to the Started Procedures Table (see page 341)
Define the CA 7 Server for iDash Started Task User ID (see page 342)
Define the Resource Class and Permit Access (see page 342)
Define the Resource Class to the Resource Descriptor Table

Defining the resource class to the resource descriptor table informs RACF that it is to protect the
resource class. Specify the same resource class that you specified in the CA 7 Server for iDash Address
Space input FACILITY option statement. You can decide to have multiple CA 7 Server for iDash tasks
use the same resource class and thus the same rules, or you can decide to assign a different resource
class per CA 7 Server for iDash. The latter permits different accesses in different CA 7 Server for iDash
address spaces.
08-Feb-2018 340/722
IBM recommends the dynamic Class Descriptor Table (CDT). To define the resource class to this table,
use the RDEFINE command. The following statement shows an example of adding resource CA7JFMD
to the dynamic CDT:
RDEFINE CDT CA7JFMD CDTINFO(MAXLENGTH(40) FIRST(ALPHA NUMERIC) MAXLENX(40) GENLIST
(ALLOWED) RACLIST(ALLOWED) OPERATIONS(NO) POSIT(nnn) OTHER
(ALPHA NATIONAL NUMERIC SPECIAL))
Change the nnn in POSIT to the desired three-digit number.
Note: For more information about the RDEFINE command and its parameters, see the IBM
documentation Security Server RACF Command Language Reference.
Define the Resource Class to the Router Table

The RACF Router Table lets you associate installation resource class authorization calls with RACF
functions. You must also add the resource classes added to the Class Descriptor Table to the RACF
Router Table to specify security processing requirements for the resource classes.
The following example statement adds CA7JFMD to the Router Table:

CA7JFMD ICHRFRTB CLASS=CA7JFMD,ACTION=RACF
Note: For more information about the RACF Router Table, see the IBM documentation
Security Server RACF System Programmer.
Activate the New Resource Class

To activate the resource class under RACF, issue the following command:
SETROPTS CLASSACT(CA7JFMD)
Define the CA 7 Server for iDash Started Task to the Started Procedures Table
RACF must know the started task for CA 7 Server for iDash and have a user ID associated with it. This
relationship is accomplished through the started procedures table (ICHRIN03) or through the
STARTED class. Do not make the started task user ID privileged or trusted. To use the started
procedures table, use the ICHRIN03 macro to add an entry, such as the following items for CA7JFMD:
ICHRIN03 CSECT
TITLE 'ICHRIN03 - STARTED PROCEDURES TABLE'
DC XL2'8001' NEW FORMAT - 03 ENTRIES
*
DC CL8'CA7JFMD' PROCNAME - CA 7 JFM Server
DC CL8'CA7JFMD ' USERID
DC CL8' ' GROUP- NULL
DC XL1'00' NOT PRIVILEGED OR TRUSTED
DC XL7'00' RESERVED
END
08-Feb-2018 341/722
If preferred and your site is set up to use the STARTED resource class, use the RDEFINE command to
define the CA 7 Server for iDash started task. An example to define CA7JFMD follows:
RDEFINE STARTED CA7JFMD.* UACC(NONE)
STDATA(USER(CA7JFMD) GROUP(CA7GROUP))
Note: The STARTED resource class overrides the started procedures table (ICHRIN03). For
more information, see the IBM Security Server RACF Security Administrators
documentation.
Define the CA 7 Server for iDash Started Task User ID

An ADDUSER RACF command adds a user ID to the RACF database. The ADDUSER command
associates that user with an existing group, by which the CA7SRVR user ID can be added. The data set
resources that it needs access to are the SYSIN input options and the profile (CA7PROF DD).
If you do not already have a CA7GROUP, issue the following command:

ADDGROUP CA7GROUP SUPGROUP(xxxx) OMVS(GID(?)) OWNER(xxxxx)
To add the user ID CA7SRVR, issue the following command. Some sites require passwords for started
task user IDs.
ADDUSER CA7SRVRD NAME('CA 7 UI Server') OWNER(CA7GROUP) NOPASSWORD
Add the OMVS segment to the user ID according to the standards at your site, for example:
ALTUSER CA7SRVRD OMVS(UID(?) HOME(‘/u/users/cai/’) + PROGRAM(‘/BIN/SH’))
Note: Because CA7JFM uses TCP/IP for its communications in its web services, the UserID
associated with CA 7 Server for iDash requires OMVS access to the following areas:
Define the Resource Class and Permit Access

The specific resources that CA 7 Server for iDash uses are listed in this topic. In this example
CA7JFMD, we set up the basic permissions to grant to resources within this class.
First, define the class with universal access defaulting to NONE (only users granted access have
access):
RDEFINE CA7JFMD (CA7JFM.ACCESS) DATA('CA 7 JFM Access') OWNER(CA7GROUP) UACC(NONE)
Next, permit specific groups, IDs, or both access to the CA 7 Server for iDash resource.
08-Feb-2018 342/722
the CA7JFM.ACCESS resource. The specifics about the resource access are provided in the following
example:
PERMIT CA7JFM.ACCESS CLASS(CA7JFMD) ID(ui-users) ACCESS(READ)
Also, permitting that user requires that you establish one or more resources to indicate the generic
(or specific) rule for the XML resource required.


PERMIT CA7JFM.XML.QUERYWORKFLOW CLASS(CA7JFMD) ID(CA7Admin) ACCESS(READ)
Note: For more information, see XML query resource names (https://docops.ca.com/display
/CA712/XML+Query+Resource+Names).
Encrypted Communications
Enabling encrypted communications with the CA 7 Server for iDash address space requires
configuring one of the following encryption methods:
IBM System Secure Socket Layer (SSL)
IBM Application Transparent Transport Layer Security (AT-TLS)
Implement Support for SSL Transmission for CA 7 Server for iDash (see page 343)
Set Up to Use System SSL for CA 7 Server for iDash (see page 348)
Implement Support for AT-TLS Transmission - iDash (see page 348)
Implement Support for SSL Transmission for CA 7 Server for iDash

Set up the CA 7 Server for iDash address space to use one of the following methods:
IBM System Secure Socket Layer (SSL) toolkit using a key store file that is on a Hierarchical File
System (HFS).
Note: Execute the program gskkyman under OMVS at a shell prompt. Executing this program
creates a key store file on the HFS, generates a self-signed certificate authority certificate, and
generates a server certificate.
External Security Manager (ESM)

Note: Execute the commands of your ESM to generate a server certificate.
08-Feb-2018 343/722
Create a Key Store File

You can create a key store file on zFS or HFS when setting up the CA 7 Server for iDash address space
to use SSL.
Follow these steps:
2. Select Create new database and enter the path and file name to the new key store file or
database.
Note: The path and file names must be writable path or file names.
3. Enter a database password and enter the password expiration in days.
Note: Press ENTER if the password never expires.
4. Enter 5000 for the database record length and enter 0 for the database mode.
5. Wait for acknowledgment that the key database is created.

The key store file is created.
Create a Self-Signed Certificate Authority Certificate

You can create a self-signed certificate authority certificate when setting up the CA 7 Server for iDash
Follow these steps:
database password.
3. Select Create a self-signed certificate.
08-Feb-2018 344/722
4.
Note: Selecting certificate authority certificate with 1024-bit RSA key creates the
certificate authority.
5. Enter a label for the self-signed certificate authority certificate and enter a common name.
following items:
Organizational unit
Organization
Organization city, state and country
7. Enter the number of days the certificate is valid and enter 0 to continue.

The self-signed certificate authority certificate is created.
Create a Server Certificate

You can create a server certificate when setting up the CA 7 Server for iDash address space to use
SSL.
Follow these steps:
database password.
3. Select Manage keys and certificates and enter the number of the certificate authority
certificate to use.
Note: You can use the number that you previously created.
4. Select Create a Signed Certificate and Key, and select User or server certificate with 1024-bit
RSA key.
08-Feb-2018 345/722
following items:
Organizational unit
Organization
Organization city, state, and country
7. Enter the number of days the certificate is valid, and enter 0 to continue.

The server certificate is created.
Set the Server Certificate as the Default Certificate

You can set the server certificate as the default certificate when setting up the CA 7 Server for iDash
Follow these steps:
2. Select Open database and enter the path to the database you created.

4. Select Manage keys and certificates and enter the number of the label for the server
certificate.
5. Select the option to set the key as the default.

The server certificate is set as the default certificate.
Export the Certificate Authority Certificate

You can export the certificate authority certificate when setting up the CA 7 Server for iDash address
space to use SSL.
Follow these steps:
08-Feb-2018 346/722
2. Select Open database and enter the path to the database that you created.

4. Select Manage keys and certificates and enter the number of the label for the certificate
authority certificate to export.
5. Select Export certificate to a file and select Binary ASN.1 DER.
6. Enter the path name and file to export the certificate to and press Enter.

The certificate authority certificate is exported.
Store the Database or Key Store Password into a Stash File

You can store the database or key store password into a stash file when setting up the CA 7 Server for
iDash address space to use SSL.
Follow these steps:
2. Select Open Database and enter the path to the database that you created.
3. Enter the database password and select Store Database Password.

The file, database_name.sth, is stored where the database file is stored.

The database or key store password is stored into a stash file.
Import the Certificate Authority Certificate into a Java Key Database

You can import the certificate authority certificate into a Java key database when setting up the CA 7
Server for iDash address space to use SSL.
Follow these steps:
1. Execute the keytool program that came with your Java SDK installation in superuser mode.
2. Enter the keystore password.

Default: changeit
3. Enter yes to trust the certificate.
Note: If the certificate is added successfully, the configuration is complete.
The certificate authority certificate is imported into a Java key database.
08-Feb-2018 347/722
Example: Execute the keytool program
The following example illustrates how to execute the keytool program:

keytool - import - trustcacerts
- file /path/to/exported/ca/certificate
- keystore $JAVA_HOME/lib/security/cacerts
Set Up to Use System SSL for CA 7 Server for iDash

For the CA 7 Server for iDash address space to use System SSL, the PDSE member GSKSSL must be
accessible to the program by one of two methods:
Adding the PDSE named pdsename.SIEALNKE to the dynamic LPA (PROGxx member).
Note: For more information about setting up System SSL, see the IBM documentation z/OS
Cryptographic Service System Secure Sockets Layer Programming.
Modifying the JCL used to start the CA 7 Server for iDash address space. Add a DD statement for
STEPLIB to include a reference to pdsename.SIEALNKE.
If you are planning to use an HFS key database file, modify the JCL that is used to start the CA 7
Server for iDash address space to:
Include a DD statement for KEYDB that specifies the USS path to the key database created in
Create a Key Store File.
Include a DD statement for STASH that specifies the USS path to the password stash file created in
Store the Database or Key Store Password Into a Stash File.
Change the CAJFPARM(IDASHAS) configuration parameter member to specify the following

statement:
SSLRINGTYPE(KDB)
If you are planning to use an External Security Manager to manage your key database and
certificates, change the CAJFPARM(IDASHAS) configuration parameter member to specify the
following statement:
SAFRING(userid/keyring)
If the server certificate you are using is not the default certificate in the key store, specify the label of
your server certificate in the CAJFPARM(IDASHAS) configuration parameter member as follows:
SSLCERTLABEL(Your Server Certificate Label Here)
Change the CAJFPARM(IDASHIP) configuration parameter member to specify ENCR(SSL) on the PORT()
statements that you are configuring to use SSL. For example:
PORT(NAME(QRYPORT1) NUMBER(12001) ENCR(SSL))
Implement Support for AT-TLS Transmission - iDash

Application Transparent Transport Layer Security (AT-TLS) is a component of z/OS. AT-TLS provides
encryption services for applications that exchange sensitive data but have not been implemented to
include encryption. This service lets you encrypt data being sent to the application without adding
the extra API calls to do encryption.
08-Feb-2018 348/722
To use AT-TLS with the CA 7 Server for iDash address space, you must have completed the following
items:
Configuration of the Communications Policy Agent
Configuration of AT-TLS policies
Installation of Server Certificate and Certificate Authority Certificate
Note: For more information about IBM Policy Agent, see the IBM z/OS V1R11 Communications Server
TCP/IP Implementation Volume 4: Security and Policy-Based Networking.
CA 7 Server for iDash is “AT-TLS aware” and can be configured to confirm that AT-TLS has secured
incoming connection requests. To enable this support, change the CAJFPARM(IDASHIP) configuration
parameter member to specify ENCR(ATTLS) on the PORT() statements that you configure to require
AT-TLS. For example:
PORT(NAME(IDASHPORT2) NUMBER(12002) ENCR(ATTLS))
CA7TOUNI Conversion Utility

The CA7TOUNI to XPJOB conversion utility lets users convert existing CA7TOUNI cross-platform jobs
to XPJOB type job definitions. The conversion process consists of two phases. The first phase reads
existing CA7TOUNI JCL members, extracting the information necessary to build the new XPJOB
definition. The second phase takes that output as BTI input and defines the XPJOB in the CA
Workload Automation CA 7® Edition database.
The conversion utility has two benefits. First, it provides a semi-automated mechanism for changing
your CA7TOUNI jobs to XPJOB definitions. Second, it maintains any requirements, triggers, and
schedules associated with the original CA7TOUNI job.
Due to the complexity of the conversion process, the following conditions must be true for the
conversion to succeed:
The job must have successfully executed in a CA Workload Automation CA 7® Edition

environment without QJCL updates. CA7TOUNI jobs that have run successfully usually convert,
assuming the remaining conditions are met. Jobs that have not run successfully most likely have
errors that would preclude their successful conversion.
All CA7TOUNI jobs to convert must reside in a PDS in uncompressed format. Move the JCL that
resides in a source control product (for example, CA Endevor® and CA LIbrarian® to a PDS. Only
one PDS can be processed at a time. The PDS must be cataloged and defined to CA Workload
Automation CA 7® Edition.
A one-to-one match of the CA7TOUNI JCL member name and the CA Workload Automation CA 7®
Edition CA7TOUNI job definition must exist. If the same member does not exist in CA Workload
Automation CA 7® Edition, the conversion fails or worse, wipes out a CA Workload Automation CA
7® Edition job definition having the same name.
The CA7TOUNI job cannot have a SYSIN DD data set, only in-stream data. We assume if the
parameters are in a data set, the SUBPASS parameter is specified, which sites do not want
displayed.
If your site has SYSIN DD data sets in their CA7TOUNI JCL, run the preconversion utility to convert
08-Feb-2018 349/722
If your site has SYSIN DD data sets in their CA7TOUNI JCL, run the preconversion utility to convert
these data sets to in-stream data. Use the output data set from the preconversion utility as input
to the conversion utility.
A NODE parameter must exist in the CA7TOUNI job definition, either in the //PROFILE data set or
in the SYSIN data. Multiple NODE parameters in either location prevent the member from being
converted.
A SUBFILE parameter must exist in the CA7TOUNI job definition SYSIN data. Multiple SUBFILE
parameters prevent the member from being converted.
Any # cards in the CA7TOUNI JCL stream prevent the member from being converted. The # cards
are allowed in the CA7TOUNI SYSIN data as long as they follow the NODE and SUBFILE
parameters.
The conversion utility generates a report that shows the processing for each member. Numerous
error messages can be generated that indicate conversion was not possible. However, if the
conditions listed previously are met, the conversion is expected to be successful.
The CA7TOUNI member job is expected but not required to consist of a single step. An input
parameter is supplied that lets you specify whether the first step invokes a CA Workload Automation
Restart Option for z/OS Schedulers RMS procedure. In this situation, the first step is ignored. Any
steps after the CA7TOUNI step are also ignored, and a warning message is generated to that effect.
Execute PHASE I of the Conversion Utility

In Phase I, the conversion utility program, SASSX2UN, is executed in a batch job. The batch job
consists of two steps.
Phase I Steps (see page 350)

Examples of SASSX2UN SYSIN Statements (see page 351)
Phase I Steps
The first step executes IEBCOPY, which creates a backup copy of the PDS against which the
conversion is performed. The PDS can contain CA7TOUNI JCL, conventional CA Workload Automation
CA 7® Edition job JCL or both. You do not need to separate out CA7TOUNI JCL.
The second step executes program SASSX2UN. Only PDS members whose first statement begins with
#7UNI are eligible for selection. All other members are bypassed. The JCL is shown in the following
(see member AL2XPJC in CAL2JCL).
//jobname JOB ......,REGION=4096K
//JS010 EXEC PGM=IEBCOPY
//SYSUT1 DD DSN=highlvl.input.dsn,DISP=SHR
//SYSUT2 DD DSN=highlvl.input.dsn.backup,
// UNIT=SYSALLDA,
// SPACE=(CYL,(05,02,20),RLSE),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)
//SYSIN DD *
COPY INDD=((SYSUT1,R)),OUTDD=SYSUT2
//*
//JS20 EXEC PGM=SASSX2UN
//PDSDD DD DSN=highlvl.input.dsn,DISP=SHR
08-Feb-2018 350/722
//PDSDD DD DSN=highlvl.input.dsn,DISP=SHR
//CONVCMDS DD DSN=highlvl.xpjconv.convcmds,
// UNIT=SYSALLDA,
// SPACE=(CYL,(10,5),RLSE),
//RESTCMDS DD DSN=highlvl.xpjconv.restcmds,
// UNIT=SYSALLDA,
//CARPROC DD DSN=cai.ca7.dprocs,DISP=SHR
//REPORT DD SYSOUT=*
//SYSIN DD *
RESTMASK=$2
RMSEXEC=RMSPROC
MEMBER=AAAA
MEMBER=B?CA*
MEMBER=DDDD*
//
The JCL that executes the SASSX2UN program consists of three input and three output data sets.
Examples of SASSX2UN SYSIN Statements

The following examples are SASSX2UN SYSIN statements.
Example 1 SASSX2UN SYSIN Statements

This example generates no Restore command because no RESTMASK keyword is found. The first step
in the CA7TOUNI job is examined for a JCL procedure named RMSPROC. If found, the JCL procedure is
bypassed, and the next step is considered the CA7TOUNI step. If the first step in the job does not
execute a JCL procedure that is named RMSPROC, it is considered the CA7TOUNI step. Members
matching the mask or member name that is provided are eligible for selection. The data set name
that is referenced in the PDSDDDSN keyword is reflected in the DELETE and SAVE BTI commands. This
name must reference a valid CA Workload Automation CA 7® Edition JCLLIB.
RMSEXEC=RMSPROC
MEMBER=C?ABC
MEMBER=ABC
MEMBER=TOUNIJOB
PDSDDDSN=ABC.CA7.JOBLIB

The following example generates a Restore command for each member that is selected for
processing. The Restore member name has a $ in the fourth position. Because no RMSEXEC keyword
is provided, the first step of the job is considered the CA7TOUNI step. All members are eligible for
selection because no MEMBER keywords are provided.
RESTMASK=$4

This example generates no Restore command because the RESTMASK keyword was not provided. The
first step of the job is considered the CA7TOUNI step because no RMSEXEC keyword was provided. All
members are eligible for conversion. For this situation, it is more efficient to omit the MEMBER=*
entry. Each member must be compared to the mask to determine whether it is eligible for selection.
If this card is omitted, no mask comparison is performed (like Example 2), members are automatically
eligible for selection.
MEMBER=*
08-Feb-2018 351/722
MEMBER=*
PHASE I Input JCL Statements

The following are the input data sets:
SASSX2UN PDSDD Statement

(Required) The PDSDD data set contains the CA7TOUNI JCL and can also contain JCL for
conventional CA Workload Automation CA 7® Edition jobs. Only JCL whose first card starts with
#7UNI is selected for conversion. This data set must be defined to CA Workload Automation CA
7® Edition as a CA Workload Automation CA 7® Edition JCL library. #7UNI jobs can execute the
CA7TOUNI program directly or from a JCL procedure (as shown in the following):
#7UNI
//jobcard
//SUBMIT EXEC PGM=CA7TOUNI,PARM='&C_L27#,&C_L2SN'
//STEPLIB DD DISP=SHR,DSN=ca7.loadlib
//PROFILE DD DISP=SHR,DSN=highlvl.ca7.profile
//SNAP DD SYSOUT=*
//SYSIN DD *
7TRACE=YES
NODE=TESTPLN
SUBFILE=CAU9TEST
#7UNI
//jobcard
//SUBMIT EXEC CA7TPROC,PARM='&C_L27#,&C_L2SN'
//SYSIN DD *
7TRACE=YES
NODE=TESTPLN
SUBFILE=CAU9TEST
When executed as a JCL procedure, the procedure name (for example, CA7TPROC) must exist as a
member in the data set pointed to by the CARPROC DD statement.
If a site ran the preconversion utility, use the final output from that job here in place of the
original CA Workload Automation CA 7® Edition JCL library.
SASSX2UN CARPROC Statement

(Required) The CARPROC data set identifies the data set containing any defined CA7TOUNI JCL
procedures and is required, even if no JCL procedures are used to execute the CA7TOUNI
program. In this situation, supply an existing procedure library such as SYS2.PROCLIB or USER.
PROCLIB. It is only used if a JCL procedure is found in the #7UNI member being processed.
SASSX2UN SYSIN Statement

(Optional) The SYSIN data set contains processing keywords used by SASSX2UN. If this statement
is not supplied, the following processing occurs:
All CA7TOUNI members in the PDSDD data set are eligible for selection.
No restore commands for backout are generated. Thus, you cannot restore your original
CA7TOUNI CA Workload Automation CA 7® Edition job definition.
CA Workload Automation Restart Option for z/OS Schedulers RMS steps are not permitted.
The first step in the CA7TOUNI JCL is assumed to invoke the CA7TOUNI program.
If the SYSIN DD statement is supplied, the keyword/value pair entered influences processing. The
four valid keywords are PDSDDDSN, RESTMASK, RMSEXEC, and MEMBER.
08-Feb-2018 352/722
Important! If a site has to run the preconversion utility, the SYSIN DD statement must be
supplied and have PDSDDDSN keyword specified.
RESTMASK
Defines a two-character value that creates the restore name of the CA7TOUNI job definition. If a
RESTMASK is not provided, a backup of the CA7TOUNI job definition is not created . The member
being converted has a character in its name replaced by the mask. The first character is the
replacement character, and the second character indicates the offset of the replacement
character in the member name. For example:
RESTMASK=$2
The restore name for member CA7XJOB is C$7XJOB.
RESTMASK=#3
The restore name for member CA7XJOB is CA#XJOB.
If the member name is not as long as the offset position, the mask character is placed in the first
blank position of the member name. For example:
RESTMASK=$4
The restore name for member CA7X is CA7$.
The restore name for member CA7Y is also CA7$.
Important! If the mask character becomes the last character of the member name, you
could end up with duplicate member names and get undesirable results during conversion.
In the preceding situation, CA7Y would not convert during Phase II. However, its JCL would
be deleted. This situation is discussed in greater detail under SASSX2UN CONVCMDS DD.
The last RESTMASK value specified in the SYSIN DD statement is the value used when creating the
restore name.
Before conversion, verify that your CA Workload Automation CA 7® Edition database has enough
space to hold backup copies of the CA7TOUNI jobs being converted.
RMSEXEC
Identifies the CA Workload Automation Restart Option for z/OS Schedulers RMS procedure used
at your site. The value follows standard JCL procedure naming conventions. If specified, and the
first step in the CA7TOUNI JCL contains a PROC that matches the value of this keyword, that JCL is
bypassed, and the next step is assumed to contain the CA7TOUNI program or procedure.
The last RMSEXEC value specified in the SYSIN DD statement is the value used to identify the CA
Workload Automation Restart Option for z/OS Schedulers RMS procedure used at your site.
MEMBER
Identifies the members you want to convert. The value can be 1 through 8 characters. You can
enter up to 512 MEMBER cards. Full masking is supported. The following are some sample values:
MEMBER=CA7XJOB
The member name must match this name exactly.
MEMBER=CA7X*
All members matching the first four letters are eligible for selection.
MEMBER= C?7?J*
All members having a C in the first position, a 7 in the third position, and a J in the fifth position
08-Feb-2018 353/722
All members having a C in the first position, a 7 in the third position, and a J in the fifth position
are selected for processing.
The CA7XJOB is not selected three times for processing, regardless of the order of these three
member statements. The first match found results in the member being processed for conversion.
If no MEMBER= keywords are found, all members in the input PDS are eligible for selection.
PDSDDDSN
Identifies the original PDSDD data set name used as input to the preconversion utility and is only
needed if the site has to run the preconversion utility.
If the PDSDDDSN keyword was not supplied, and a site ran the preconversion utility, the output
BTI files produced by the conversion utility reference the output data set generated by pre-
conversion process, not the real CA Workload Automation CA 7® Edition JCL library containing the
jobs to convert.
PHASE I Output JCL Statements

This article provides the Phase I output JCL statements, the SASSX2UN return codes, and the
CA7TOUNI keyword processing during Phase I of conversion.
SASSX2UN Return Codes (see page 356)

CA7TOUNI Keyword Processing During Phase I of Conversion (see page 357)
The following are the output JCL statements:
SASSX2UN CONVCMDS Statement

(Required) The CONVCMDS data set is a physical sequential output data set. The CA Workload
Automation CA 7® Edition commands that convert the CA7TOUNI job to the XPJOB are written to
this data set. Though you can edit the CONVCMDS data set before running it through the Batch
Terminal Interface (Phase II), it is not recommended. Examples of the output are shown in the
following:
/LOGON TRENT05
DBM
CONVERT,CASE0401,BACKUP=C$SE0401
XPJOB
UPD,CASE0401,
NODE=CA7NODE,
EX1=(C:\PROGRA~1\WINDOW~3\MPLAYER2.EXE),
MEMBER=CASE0401,
SUTYPE=Y
JCL
DELETE,CASE0401,DSN=APCDAL.DEVCA7.CA31CA76.JOBLIB
JCL,CASE0401
EDIT
MIXED
XSEQ
I ,
PARM1=C:\MUSIC.MP3
SUBUSER=CA7USER
$IEND
SAVE
SAVE,CASE0401,DSN=APCDAL.DEVCA7.CA31CA76.JOBLIB
CLEAR
DBM
XNODE
ADD,CA7NODE
/LOGOFF
As the examples show, you always have the following commands:
CONVERT statement
08-Feb-2018 354/722
CONVERT statement
XPJOB statement
JCL DELETE statement
Depending on your parameters, the JCL/EDIT/MIXED/XSEQ/I and $IEND/SAVE/CLEAR commands

are not always available. XNODE ADD commands are present for each unique node.
Important! Conditions that can cause the conversion to fail are as follows:
Conversion is a destructive process. You can enter each of the commands noted previously by
itself and succeed or fail. For example, the CONVERT and XPJOB commands could fail, but the JCL
DELETE command could succeed. Thus, you are left with a CA7TOUNI job definition and no
CA7TOUNI JCL (remember that you do have a backup from the IEBCOPY step).
Two conditions can cause the conversion to fail.
The JCL member name contains the #7UNI statement and appropriate CA7TOUNI parameters
but the definition in CA Workload Automation CA 7® Edition does not indicate a CA7TOUNI
job. If the assumptions identified at the beginning of this topic are true, this situation is
unlikely.
The Restore name that is provided exists.
Regarding the second bulleted item, consider this example where the RESTMASK was set to 8$
(so the last character of the member name is changed to the mask character).
CONVERT,ABCDE1,BACKUP=ABCDE$
CONVERT,ABCDE2,BACKUP=ABCDE$
Job ABCDE1 completes successfully. Job ABCDE2 fails because the backup name exists. The JCL
stream for job ABCDE2 is deleted. A backup of the ABCDE2 CA7TOUNI JCL exists in the copy of the
PDSDD PDS created in the first job step.
Important! Verify that duplicate backup members do not exist, or will not exist, when the
CONVERT command is executed.
SASSX2UN RESTCMDS Statement

(Required) The RESTCMDS data set is a physical sequential output data set. The CA Workload
Automation CA 7® Edition commands that restore the XPJOB back to the CA7TOUNI job are
written to this data set. The Restore command is a single-line command.
RESTORE,CA7XJOB,BACKUP=CA7$JOB
The Restore command is a destructive command. The command wipes out an XPJOB definition
created by the Convert command. If the Restore command is executed, also copy the original
CA7TOUNI JCL from the backup data set (created during the conversion process) to the
appropriate CA Workload Automation CA 7® Edition JCL library.
Remember, if a RESTMASK is not provided, no back-up of the CA Workload Automation CA 7®
08-Feb-2018 355/722
Remember, if a RESTMASK is not provided, no back-up of the CA Workload Automation CA 7®

Edition job definition is created because no RESTORE command is generated. To restore, delete
the CA7 XPJOB definition, create a "new" job definition, and copy the original JCL back from the
data set created in the IEBCOPY step.
SASSX2UN REPORT Statement

(Required) The REPORT data set is a SYSOUT data set. All informational, warning, and error
messages generated during the first phase of the conversion process are written to this data set.
Inspect this report thoroughly before proceeding to Phase II.
If your site's CA7TOUNI job definitions meet the assumptions defined in the first part of this
section, you should only see informational and, possibly, warning messages. A sample of the
report follows. All possible messages are shown in Conversion Utility Messages.
SASSX2UN-01 CA-7 CA7TOUNI Conversion Utility
DATE: 10/25/yy
MEMBER CASE0101 SELECTED FOR PROCESSING
MEMBER CASE0101 PROFILE DSN IS CA7.SASSX2UN.PROFILE.CASE01
*** ERROR *** - MEMBER CASE0101 NO NODE KEYWORD FOUND. CANNOT CONVERT THIS M
*** ERROR *** - MEMBER CASE0106 - PARM2 HAS NO DATA
*** ERROR *** - MEMBER CASE0106 PROCESSING FAILED - SEE PREVIOUS MESSAGES
*** ERROR *** - MEMBER CASE0107 - SUTYPE HAS BAD PARAMETER VALUE
*** ERROR *** - MEMBER CASE0108 - CONTINUTATION FAILED
*** ERROR *** - MEMBER CASE0109 - WRONG OR UNKNOWN KEYWORD
MEMBER CASE0110 CONVERT COMMANDS SUCCESSFULLY CREATED
MEMBER CASE0110 RESTORE COMMANDS SUCCESSFULLY CREATED
MEMBER CASE0111 CONVERT COMMANDS SUCCESSFULLY CREATED
MEMBER CASE0111 RESTORE COMMANDS SUCCESSFULLY CREATED
Total Members................................ 7
Members Selected for Conversion.............. 7
Members Successfully Converted............... 2
Members Not Converted........................ 5
SASSX2UN Return Codes

The conversion utility program (SASSX2UN) returns one of the following four return codes:
RC=0
Indicates that the job ran successfully. Only informational messages are written to the REPORT
DD statement.
RC=4
Indicates that the job ran successfully but one or more members had warning messages issued.
Examine the warning messages in the REPORT DD statement and determine whether any action is
necessary.
08-Feb-2018 356/722
RC=8
Indicates that the job ran successfully but one or more members had errors that prevented
conversion statements from being created. Examine the error messages in the REPORT DD
statement and determine whether any action is necessary.
RC=12
Indicates that the job failed. No CONVERT commands were generated. Examine the WTO in the
JES JOBLOG of the job for the cause of the failure.
CA7TOUNI Keyword Processing During Phase I of Conversion

SASSX2UN processes CA7TOUNI keywords in the sequence in which they were entered. User ID and
password information that is extracted from the JOB statement, //*LOGONID card, //*JOBFROM
statement, or //*PASSWORD card is written out first. The keyword information that is extracted from
the PROFILE data set follows, and then the SYSIN data stream.
The JOBNO, JOBSET, MONITOR, SUBCHECK, and 7TRACE CA7TOUNI keywords are not valid for XPJOB
definitions and ignored.
Execute PHASE II of the Conversion Utility

In Phase II of the Conversion Utility, the Batch Terminal Interface (BTI) procedure is executed.
This job uses the Phase I output file CONVCMDS as input. JCL to execute this procedure is shown in
the following example:
//JS010 EXEC CA7BTI
//SYSIN DD DSN=highlvl.batch.convcmds,DISP=SHR
//
If the member name specified on the CONVERT command does not exist, or is not a CA7TOUNI job
definition, the command fails. If the BACKUP= parameter is specified on the CONVERT command, and
the backup member exists, the command fails. Standard error processing is followed for all other
commands (such as XPJOB, JCL, SAVE, CLEAR) that can be found in the deck.
When the BTI job completes, thoroughly inspect the output report and resolve any errors that were
reported.
Be sure to use the BTI (CA7BTI) procedure during the conversion process. CA7BTI can handle PARM xx
keyword/value pairs up to 80 characters in length. The CAICCI batch interface truncates PARM xx
keyword/value pairs greater than 71 characters and causes your conversion to fail.
Execute the CONVERT Command Online

You can enter the CONVERT command within CA Workload Automation CA 7® Edition from any
panel. The command creates an XPJOB shell definition that cannot be executed. Update this
definition, providing the XPJOB information described in DB.10 XPJOB Definition Panel (https://wiki.ca.
com/display/CWAC7E/DB.10+-+XP+Job+Definition+Panel), and modify the "JCL" as necessary with the
CA7TOUNI parameter statements. We do not recommend using the CONVERT command in the CA
Workload Automation CA 7® Edition online environment.
The following is an example of executing the CONVERT command from an online CA Workload
08-Feb-2018 357/722
The following is an example of executing the CONVERT command from an online CA Workload
Automation CA 7® Edition panel and the output that command would produce.
Command: CONVERT,XPJOB01,BACKUP=XPJOB01$
Output:
--- FUNCTION: CONVERT
--- JOBNAME : XPJOB01
--- BACKUP : XPJOB01$
SM27-01 L JOB=XPJOB01 CONVERT SUCCESSFULLY COMPLETED
Restore a Converted Member

You can restore a converted member or members using the commands found in the RESTCMDS DD
data set and the BTI JCL stream. See the following example:
//JS010 EXEC CA7BTI
//SYSIN DD DSN=highlvl.batch.restcmds,DISP=SHR
//
Because RESTORE is a single-line command, you can easily cut and paste only those members you
want to restore to another data set. Use that as your BTI input. Alternately, log on to your CA
Workload Automation CA 7® Edition environment and execute it as an online command. A sample is
shown in the following:
Command: RESTORE,XPJOB01,BACKUP=XPJOB01$
Output:
--- FUNCTION: RESTORE
SM27-01 L JOB=XPJOB01 RESTORE SUCCESSFULLY COMPLETED
Remember, this command simply restores the CA7TOUNI definition. You must still copy the
CA7TOUNI JCL from the Phase I IEBCOPY back-up to the appropriate CA Workload Automation CA 7®
Edition JCL library.
Clean-Up after a Conversion

This article explains how to clean up your environment after you complete a conversion. As stated in
the beginning of these topics, this process maintains any requirements, triggers, and schedules
associated with the original CA7TOUNI job. The process also maintains PROFILE and STEPLIB data set
definitions resulting from the original CA7TOUNI LOAD, or done using the DB.6 panel. These
definitions are not required for the XPJOB type jobs and can be deleted using the DB.6 panel. Review
your original JCL or CA7TOUNI procedure to determine the PROFILE and STEPLIB data sets.
CA7TOUNI Error Messages

This article details CA7TOUNI error messages.
08-Feb-2018 358/722
*** ERROR *** - MEMBER xxxxxxxx CARDS FOUND BEFORE SYSIN DD CARD. CANNOT CONVERT
THIS MEMBER
Reason:
The listed member has # statements before the SYSIN data. # statements are typically used for
substitution and are resolved at job submission. The utility cannot determine how to process JCL
when # statements are present.
*** ERROR *** - MEMBER xxxxxxxx CARDS FOUND BEFORE THE NODE. CANNOT CONVERT THIS
MEMBER
Reason:
The listed member has # statements before the NODE parameter in the SYSIN data. # statements are
typically used for substitution and are resolved at job submission. The utility cannot determine how
to process a NODE parameter that follows a # statement.
*** ERROR *** - MEMBER xxxxxxxx CARDS FOUND BEFORE THE SUBFILE. CANNOT CONVERT THIS
MEMBER
Reason:
The listed member has # statements before the SUBFILE parameter in the SYSIN data. # statements
are typically used for substitution and are resolved at job submission. The utility cannot determine
how to process a SUBFILE parameter that follows a # statement.
*** ERROR *** - MEMBER xxxxxxxx CANNOT BUILD JFCB FOR CARPROC DD. CANNOT CONVERT
THIS MEMBER
Reason:
This member referenced a JCL procedure for CA7TOUNI. The data set referenced in the CARPROC DD
statement typically contains this member. An error occurred trying to access this data set.
*** ERROR *** - MEMBER xxxxxxxx CONTINUATION FAILED
Reason:
This member had a continuation error in a PARMxx or SUBFILE. A previous line that ends in a + sign
has no continuation on the next line. The member is not converted.
*** ERROR *** - MEMBER xxxxxxxx COULD NOT ALLOCATE PROFILE DSN. CANNOT CONVERT THIS
MEMBER
Reason:
The listed member has a JCL error. The PROFILE DSN could not be allocated. One of the initial
conditions is that the job has run successfully as a CA7TOUNI job. This condition is not true when this
error is displayed.
*** ERROR *** - MEMBER xxxxxxxx FOUND PGM= STATEMENT AND PGM NOT CA7TOUNI.
CANNOT CONVERT MEMBER
08-Feb-2018 359/722
Reason:
The first step that is found, which is assumed to be the CA7TOUNI step, does not execute the
CA7TOUNI program.
*** ERROR *** - MEMBER xxxxxxxx MULTIPLE NODES FOUND IN PROFILE DSN. CANNOT CONVERT
THIS MEMBER
Reason:
The listed member has multiple NODE parameter entries in the PROFILE data set. The conversion
utility permits for a maximum of one entry in the PROFILE data set.
*** ERROR *** - MEMBER xxxxxxxx MULTIPLE NODES FOUND IN SYSIN DATA. CANNOT CONVERT
THIS MEMBER
Reason:
The listed member has multiple NODE parameter entries in the SYSIN data. The conversion utility
permits for a maximum of one entry in the SYSIN data.
*** ERROR *** - MEMBER xxxxxxxx MULTIPLE SUBFILES FOUND IN SYSIN DATA. CANNOT CONVERT
MEMBER
Reason:
The listed member has multiple SUBFILE parameter entries in the SYSIN data. The conversion utility
permits for a maximum of one entry.
*** ERROR *** - MEMBER xxxxxxxx NO NODE KEYWORD FOUND. CANNOT CONVERT THIS MEMBER
Reason:
The listed member has no NODE parameter. XPJOB definitions require a NODE. If one is not found,
the job cannot be converted.
*** ERROR *** - MEMBER xxxxxxxx NO SUBFILE KEYWORD FOUND. CANNOT CONVERT THIS
MEMBER
Reason:
The listed member has no SUBFILE parameter in the SYSIN DD data. XPJOB definitions require a
SUBFILE. If one is not found, the job cannot be converted. This message also displays when the first
step found in the member is not the CA7TOUNI step and it does not match the RMSEXEC parameter
value.
*** ERROR *** - MEMBER xxxxxxxx NO VALUE PROVIDED FOR PGM= OR PROC NAME. CANNOT
CONVERT MEMBER
Reason:
The listed member has a JCL error. One of the initial conditions is that the job has run successfully as
a CA7TOUNI job. This condition is not true when this error is displayed.
08-Feb-2018 360/722
*** ERROR *** - MEMBER xxxxxxxx NO VALUE PROVIDED FOR PROFILE DSN. CANNOT CONVERT
THIS MEMBER
Reason:
The listed member has a JCL error. No value was provided for the PROFILE data set. One of the initial
error is displayed.
*** ERROR *** - MEMBER xxxxxxxx PROCESSING FAILED - SEE PREVIOUS MESSAGES
Reason:
The listed member has serious errors that prevented conversion. Previous error messages in the
REPORT DD output (for the member) explain the exact cause of the problem.
*** ERROR *** - MEMBER xxxxxxxx PROC/PGM=VALUE EXCEEDS 8 CHARACTERS. CANNOT

CONVERT THIS MEMBER
Reason:
The listed member has a JCL error. The JCL procedure or the program name exceeded eight
characters. One of the initial conditions is that the job has run successfully as a CA7TOUNI job. This
condition is not true when this error is displayed.
*** ERROR *** - MEMBER xxxxxxxx PROFILE DSN EXCEEDS 44 CHARACTERS. CANNOT CONVERT
THIS MEMBER
Reason:
The listed member has a JCL error. Data set names cannot exceed 44 characters. One of the initial
error is displayed.
*** ERROR *** - MEMBER xxxxxxxx PROFILE DSN NOT FOUND. CANNOT CONVERT THIS MEMBER
Reason:
The listed member has a JCL error. The PROFILE DSN could not be found. One of the initial conditions
is that the job has run successfully as a CA7TOUNI job. This condition is not true when this error is
displayed.
*** ERROR *** - MEMBER xxxxxxxx READ PAST EOL SEARCHING //PROFILE DSN. CANNOT
CONVERT MEMBER
Reason:
*** ERROR *** - MEMBER xxxxxxxx READ PAST EOL SEARCHING PROC/PGM LINE. CANNOT
CONVERT THIS MEMBER
Reason:
08-Feb-2018 361/722
Reason:
*** ERROR *** - MEMBER xxxxxxxx RESTORE NAME FOUND IN PDSDD FILE. CANNOT CONVERT
MEMBER
Reason:
The RESTMASK keyword was supplied to the Conversion Utility. A test sees whether the member
name generated for the back-up (using the RESTMASK value) exists in the PDSDD file. If this member
exists, the member is not converted.
*** ERROR *** - MEMBER xxxxxxxx SYSIN DSN OR PROC FOUND IN SYSIN. CANNOT CONVERT THIS
MEMBER
Reason:
The listed member has a SYSIN data set or PROC concatenated to the SYSIN DD statement. A SYSIN
data set is assumed to contain a SUBPASS parameter the site does not want displayed. The member
is not processed. Anything concatenated to the SYSIN DD * statement causes an error.
*** ERROR *** - MEMBER xxxxxxxx SYSIN KEYWORD CARDS EXCEEDED MAXIMUM. CANNOT
CONVERT THIS MEMBER
Reason:
The listed member has over 400 lines of SYSIN data. The member has exceeded the maximum that is
permitted.
*** ERROR *** - MEMBER xxxxxxxx TOO MANY KEYWORD LINES IN PROFILE DSN. CANNOT
CONVERT THIS MEMBER
Reason:
The listed member has over 25 lines of keywords, which are used by CA7TOUNI, in the PROFILE DD
data set. The member has exceeded the maximum that is permitted.
*** ERROR *** - MEMBER xxxxxxxx UNABLE TO OPEN THE CARPROC DD. CANNOT CONVERT THIS
MEMBER
Reason:
This member referenced a JCL procedure for CA7TOUNI. The data set referenced in the CARPROC DD
statement typically contains this member. An error occurred trying to access this data set.
*** ERROR *** - MEMBER xxxxxxxx WRONG OR UNKNOWN KEYWORD
Reason:
This member had an invalid keyword parameter. The member is not converted.
*** ERROR *** - MEMBER xxxxxxxx yyyyyyyy HAS BAD PARAMETER VALUE
08-Feb-2018 362/722
*** ERROR *** - MEMBER xxxxxxxx yyyyyyyy HAS BAD PARAMETER VALUE
Reason:
This member had a keyword (yyyyyyyy) whose value was incorrect for the keyword. The member is
not converted.
*** ERROR *** - MEMBER xxxxxxxx yyyyyyyy HAS NO DATA
Reason:
This member had a keyword (yyyyyyyy) for which no data was supplied. The member is not
converted.
*** ERROR *** - MEMBER xxxxxxxx yyyyyyyy EXCEEDS zzz CHARACTERS
Reason:
This member had a keyword (yyyyyyyy) whose value exceeded the maximum size (zzz) allowed. The
member is not converted.
Note: If you receive this message for the SUBFILE keyword, continue to run the job as a
CA7TOUNI job. SUBFILE can support lengths up to 256 bytes. The field that it is converted
to can only support 244 characters.
CA7TOUNI Informational Messages

This article details CA7TOUNI informational messages.
MEMBER xxxxxxxx CA7TOUNI PROC =
Reason:
This message shows the CA7TOUNI JCL procedure the member invokes. If the member executes
PGM=CA7TOUNI, this message is not displayed.
MEMBER xxxxxxxx CONVERT COMMANDS SUCCESSFULLY CREATED
Reason:
This message indicates that the member was successfully processed. The CONVERT BTI commands
for this member have been placed in the CONVCMDS DD data set.
MEMBER xxxxxxxx PROFILE DSN IS
Reason:
08-Feb-2018 363/722
This message shows the PROFILE data set the member uses. The CACCENV member is this data set is
examined for CA7TOUNI parameters and values.
MEMBER xxxxxxxx RESTORE COMMANDS SUCCESSFULLY CREATED
Reason:
This message indicates that the member was successfully processed. The RESTORE BTI commands for
this member have been placed in the RESTCMDS DD data set. This message is only generated when
the RESTMASK parameter was specified.
MEMBER xxxxxxxx SELECTED FOR PROCESSING
Reason:
This message indicates the member contained the #7UNI statement and was selected for conversion
processing.
CA7TOUNI Warning Messages

This article details CA7TOUNI warning messages.
*** WARNING *** - MEMBER xxxxxxxx COULD NOT BE OPENED AND WAS BYPASSED
Reason:
A member in the PDSDD statement data set could not be processed.
*** WARNING *** - MEMBER xxxxxxxx JOB STEPS FOUND AFTER CA7TOUNI ARE IGNORED. REVIEW
THEIR PURPOSE
Reason:
A CA7TOUNI job had job steps after the CA7TOUNI step. Review these steps and determine what
action to take when the job is converted to an XPJOB because these steps are no longer executed.
*** WARNING *** - MEMBER xxxxxxxx SUBROOT PARM FOUND. SEE XPDEF INIT DECK PARM FOR
SUBROOT DETAILS
Reason:
A CA7TOUNI job had SUBROOT parameter. This parameter is processed differently in XPJOB
definitions.
Note: For more information about this processing, see the XPDEF statemen (see page 574)t
in the initialization file.
*** WARNING *** - MEMBER xxxxxxxx VALUE FOR PASSWORD EXCEEDS 14 CHARACTER MAXIMUM
08-Feb-2018 364/722
*** WARNING *** - MEMBER xxxxxxxx VALUE FOR PASSWORD EXCEEDS 14 CHARACTER MAXIMUM
Reason:
A CA7TOUNI job had a PASSWORD= parameter on the JOB statement or a //*PASSWORD statement.
The conversion utility creates a SUBPASS parameter statement from either of these cards when the
value is 14 characters or less.
*** WARNING *** - MEMBER xxxxxxxx VALUE FOR USER=/LOGONID/JOBFROM BYPASSED,

EXCEEDS 8 CHARACTER MAX
Reason:
A CA7TOUNI job had a USER= parameter on the JOB statement, or a //*LOGONID statement, or a
//*JOBFROM statement. If the value is eight characters or less, the conversion utility creates a
SUBUSER parameter statement from any of these statements.
*** WARNING *** - MEMBER xxxxxxxx VALUE FOR USER=/LOGONID/JOBFROM OR PASSWORD

NOT VALID
Reason:
A CA7TOUNI job had one of the following:
USER= parameter on the JOB statement
PASSWORD= parameter on the JOB statement
A //*LOGONID statement
//*JOBFROM statement
//*PASSWORD statement
No value was specified for the parameter. The Conversion Utility creates either SUBUSER or SUBPASS
parameter statements from these statements their value is valid.
Pre-Conversion Utility
The CA7TOUNI conversion utility assumes that all CA7TOUNI SYSIN DD data is in-stream. Any
CA7TOUNI jobs containing one or more permanent data sets in the SYSIN DD statement are not
converted. The Pre-Conversion Utility can be used to alleviate this situation.
The Pre-Conversion Utility reads the same PDS, containing CA7TOUNI jobs, that the conversion utility
reads. The utility reads and writes each record of any job starting with #7UNI (all other jobs are
bypassed) to a new sequential file. The utility dynamically allocates any permanent SYSIN DD data
sets associated with the CA7TOUNI job. The utility adds each record to the new sequential file as part
of a SYSIN DD * statement. The sequential file is actually an IEBUPDTE job that contains control cards
to add each CA7TOUNI job to a new PDS. After the IEBUPDTE has been run, the new PDS that can be
used as input to the conversion utility.
The Pre-Conversion Utility consists of three steps:
08-Feb-2018 365/722
Step 1 reads the PDS containing CA7TOUNI jobs and creates an IEBUPDTE job file and two other
files. The report file contains information about each member that was processed. Errors that
occurred processing the member can be found in this file. The output data file contains
information that is used in Steps 2 and 3.
Step 2 sorts the file.
Step 3 generates the Node/JobName report. Because the output data file is a CSV file, it can be
downloaded to an Excel spreadsheet or MS-Access database and further manipulated if desired.
For a JCL sample, see the AL2XPJPC member in CAL2JCL.
The Pre-Conversion Utility contains limited support for JCL SET and INCLUDE statements. Nested
INCLUDE statements are not processed. For example, if the INCLUDE MEMBER(A) has a JCL statement
for the INCLUDE MEMBER(B), the job fails pre-conversion processing. Also, the INCLUDE member
must reside in a library that is contained in a JCLLIB statement that is part of the CA7TOUNI JCL. The
utility does not search JES2 PROCLIBs or JOBPARM PROCLIB= keyword value.
CA7TOUNI Input Parameters

By default, no input parameters are required. When SASSX2PD is executed with no input parameters,
SUBUSER and SUBPASS information is EXCLUDED from the IEBUPDTE job (OUNIJCL).
EXEC PGM=SASSX2PD,PARM='SUBUSER'
Executing SASSX2PD with this parameter setting includes SUBUSER information in the OUNIJCL
file.
EXEC PGM=SASSX2PD,PARM='SUBUSER,SUBPASS'
Executing SASSX2PD with this parameter setting includes SUBUSER and SUBPASS information in
the OUNIJCL file.
Note: SUBPASS information is never written to the OREPDATA DD statement.
Be aware, the passwords can be compromised depending on who can run this job.
CA7TOUNI Input JCL Statements

The utility has one input data set:
SASSX2PD PDSDD Statement

(Required) The PDSDD data set contains the CA7TOUNI JCL and can also contain JCL for
conventional jobs. Only JCL whose first card starts with #7UNI are selected for preconversion. The
input file that is specified on this PDSDD statement must be supplied as the PDSDDDSN keyword
value in the conversion utility when it is run.
CA7TOUNI Output JCL Statements

The following items are the output JCL statements:
08-Feb-2018 366/722
SASSX2PD OUNIJCL Statement

This DD statement contains an IEBUPDTE job with all the CA7TOUNI jobs that were processed
(with all SYSIN DD data now in-stream). This job is submitted to create the PDS to use as input to
the conversion utility.
A sample of this file follows:
//PRECONV JOB (ACCTINFO),PGMR,CLASS=A,MSGCLASS=A
//GENBLD EXEC PGM=IEBUPDTE,PARM=NEW
//SYSUT2 DD DISP=(NEW,CATLG,DELETE),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=0),
// SPACE=(3120,(130,13,15)),
// DSN=, <=== FILL WITH DSN
// UNIT=, <=== FILL WITH UNIT
// VOL=SER= <=== FILL WITH VOLUME
//SYSIN DD DATA,DLM=$$
./ ADD NAME=PRECNV01
#7UNI
//PRECNV01 JOB (40100000,IGN),'CA-7.TOUNI',
// CLASS=K,MSGCLASS=P,NOTIFY=&SYSUID
/*JOBPARM S=*
// JCLLIB ORDER=(PROCLIB.DSN)
//SUBMIT EXEC CA7TOUNI
//PROFILE DD DSN=PROFILE.DATA,DISP=SHR
//SYSIN DD *
NODE=TRENT05
SUBFILE=C:\WINDOWS\+
NOTEPAD.EXE
/*
//
./ ADD NAME=PRECNV02
#7UNI
//PRECNV02 JOB (40100000,IGN),'CA-7.TOUNI',
// CLASS=K,MSGCLASS=P,NOTIFY=&SYSUID
/*JOBPARM S=*
// JCLLIB ORDER=(PROCLIB.DSN)
//SUBMIT EXEC CA7TOUNI
//PROFILE DD DSN=PROFILE2.DATA,DISP=SHR
//SYSIN DD *
node=JAMES02
SubFile=C:\WINDOWS\+
NOTEPAD.EXE
/*
//
$$
//
SASSX2PD OREPDATA Statement

This DD statement contains a list of jobs that were processed. Specific information is the following
items:
NODE (eight characters max)
JOB (eight characters max)
SUBUSER (32 characters max)
SUBPASS Indicator (YES or NO)
08-Feb-2018 367/722
The SUBPASS Indicator indicates whether password information exists for the job. This data set is
sorted in Step 2 and used to generate the CA Workload Automation CA 7® Edition Pre-Conversion
Utility Report by Node/JobName. Optionally, you can download this file to a MS-Access database
or Excel spreadsheet and process as desired.
A sample of the output file follows:
TRENT05 ,PRECNV01,USER5678901234567890123456789012,YES
JAMES02 ,PRECNV02,user ,YES
,PRECNV03,user ,NO
TRENT05 ,PRECNV04, ,NO
TRENT05 ,PRECNV05,myUserNameLongest890123456789012,YES
SASSX2PD REPORT Statement

This DD statement is a SYSOUT data set. All informational, warning, and error messages that are
generated during the pre-conversion process are written to this data set. Inspect this report
thoroughly before proceeding. If the CA7TOUNI job definitions at your site meet the assumptions
that are defined in the conversion utility topic, you only see informational, and possibly, warning
messages. A sample of the report is shown in the following example. The possible messages are
shown in Pre-Conversion Utility Messages.
MEMBER PRECNV13 SELECTED FOR PROCESSING
MEMBER PRECNV13 SYSIN DSN IS APCDAL.DEVCA7.CL2111.TESTDATA.B1JF.PDS(T)
MEMBER PRECNV13 SYSIN DSN IS APCDAL.DEVCA7.CL2111.TESTDATA.B1JF.SEQDS01
MEMBER PRECNV13 PROCESSED SUCCESSFULLY
MEMBER PRECNV14 SELECTED FOR PROCESSING
*** ERROR *** MEMBER PRECNV14 SYSIN DSN IS INVALID. CANNOT PROCESS THIS MEMBER
SASSX2PR X2PROUTP Statement

This DD statement is a SYSOUT data set. The data set contains the CA 7 Pre-Conversion Utility
Report by Node/JobName. A sample of the report follows:
-------------------------------------------------------------------------------
SASSX2PR CA 7 Pre-Conversion Utility Report by Node/JobName
NODE JOBNAME SUBUSER SUBPASS
-------------------------------------------------------------------------------
PRECNV03 user NO
** Total Jobs Going to Node is 00001
MARJA24 PRECNV08 myuser4 YES
MARJA24 PRECNV09 myuser5 YES
MARJA24 PRECNV10 user123 YES
MARJA24 PRECNV17 USERNAME4 YES
** Total Jobs Going to Node MARJA24 is 00004
USERX06 PRECNV19 NO
** Total Jobs Going to Node USERX06 is 00001
JAMES02 PRECNV02 user YES
JAMES02 PRECNV07 myuser3 YES
JAMES02 PRECNV11 user654 NO
JAMES02 PRECNV13 user654 NO
** Total Jobs Going to Node JAMES02 is 00004
TRENT05 PRECNV01 USER5678901234567890123456789012 YES
TRENT05 PRECNV04 NO
TRENT05 PRECNV05 myUserNameLongest890123456789012 YES
TRENT05 PRECNV09 Marja24User YES
TRENT05 PRECNV13 myuser YES
** Total Jobs Going to Node TRENT05 is 00005
** TOTAL JOBS = 00015
SASSX2PD Return Codes

The Pre-Conversion Utility program (SASSX2PD) returns one of the following return codes:
RC=0
08-Feb-2018 368/722
RC=0
Indicates that the job ran successfully. Only informational messages are written to the REPORT
DD statement.
RC=4
Indicates that the job ran successfully, but one or more of the PDSDD members could not be
opened. Examine the warning messages in the REPORT DD statement and determine whether any
action is necessary.
RC=8
Indicates that the job ran successfully, but one or more members had errors that prevented them
from being processed. Examine the error messages in the REPORT DD statement and determine
whether any action is necessary.
RC=12
Indicates that the job failed. No IEBUPDTE job was generated. Examine the WTO in the JES
JOBLOG of the job for the cause of the failure.
Pre-Conversion Utility Messages

The following messages can appear in the Pre-Conversion Utility REPORT DD statement.
CA7TOUNI Informational Messages (see page 369)

CA7TOUNI Warning Messages (see page 370)
CA7TOUNI Error Messages (see page 371)
CA7TOUNI Informational Messages

The pre-conversion utility issues the following informational messages.
MEMBER xxxxxxxx PROCESSED SUCCESSFULLY
Reason:
This message indicates the member contained the #7UNI statement and was successfully processed.
Action:
None.
MEMBER xxxxxxxx SELECTED FOR PROCESSING
Reason:
This message indicates the member contained the #7UNI statement and was selected for pre-
conversion processing.
Action:
None.
MEMBER xxxxxxxx SYSIN DSN IS yyyyyyyy
Reason:
08-Feb-2018 369/722
Reason:
This message indicates the member contained a permanent SYSIN data set that is being processed.
Action:
None.
CA7TOUNI Warning Messages

The pre-conversion utility issues the following warning message.
CA7--*** WARNING *** MEMBER xxxxxxxx CONTAINS TOO MANY JCLLIB ENTRIES TO BE FULLY
PARSED
Reason:
This message indicates input PDSDD member xxxxxxxx contained more than 16 JCLLIB entries.
Generally this situation is not a problem as long as any INCLUDE statements can be resolved.
Action:
Check the job output in the OUNIJCL DD statement and ensure all the necessary CA7TOUNI
statements are present.
CA7--*** WARNING *** MEMBER xxxxxxxx CONTAINS TOO MANY SET STATEMENTS TO BE FULLY
PARSED
Reason:
This message indicates input PDSDD member xxxxxxxx contained more JCL SET statements that the
pre-conversion utility could process. Generally this situation is not a problem because other more
severe problems occur when a SET statement required to resolve a symbolic variable cannot be
found.
Action:
Check the job output in the OUNIJCL DD statement and ensure all the necessary CA7TOUNI
statements are present.
*** WARNING *** MEMBER xxxxxxxx COULD NOT BE OPENED AND WAS BYPASSED
Reason:
This message indicates input PDSDD member xxxxxxxx could not be opened.
Action:
Determine whether you want to process the member. If it is not a CA7TOUNI job, ignore the
message. If it is a CA7TOUNI job, fix the problem and rerun the Pre-Conversion Utility after deleting
any data sets created during the prior job run.
08-Feb-2018 370/722
CA7TOUNI Error Messages

The pre-conversion utility issues the following error messages.
*** ERROR *** INCLUDE MEMBER xxxxxxxx NOT FOUND IN JCLLIB
Reason:
This message indicates input PDSDD member xxxxxxxx contained an INCLUDE member that could not
be found in the JCLLIB concatenation.
Action:
Perform one of the following actions:
Determine whether you want to process the member. If you do not need to convert the job,
ignore the message and continue.
Add the INCLUDE member to a data set in the JCLLIB concatenation.
*** ERROR *** MEMBER xxxxxxxx HAS INCLUDE MEMBER BUT NO JCLLIB
Reason:
This message indicates input PDSDD member xxxxxxxx contained a JCL INCLUDE statement but no
JCLLIB statement.
Action:
Add a JCLLIB statement for the data set containing the INCLUDE member. The pre-conversion
utility searches only the JCLLIB concatenation for INCLUDE members.
*** ERROR *** MEMBER xxxxxxxx HAS NESTED INCLUDE STATEMENTS
Reason:
This message indicates input PDSDD member xxxxxxxx contained nested INCLUDE statements.
Action:
08-Feb-2018 371/722
Otherwise, copy the data contained in the nested INCLUDE member to an existing data set. The
pre-conversion utility only processes single level INCLUDE members. INCLUDE members that
contain additional JCL INCLUDE statements fail processing.
*** ERROR *** MEMBER xxxxxxxx HAS NESTED SYSIN DD DATA SETS
Reason:
This message indicates input PDSDD member xxxxxxxx contained a SYSIN DD data set containing a
line of data pointing to another data set.
Action:
Copy the data in the nested data set into the data set that was pointing to it.
*** ERROR *** MEMBER xxxxxxxx HAS SYSIN DD SET STATEMENTS
Reason:
This message indicates input PDSDD member xxxxxxxx contained SET statements in the SYSIN DD
concatenation.
Action:
Move the SET statements before the SYSIN DD statement. SET statements are not valid in a SYSIN
concatenation.
*** ERROR *** MEMBER xxxxxxxx INCLUDE JCLLIB ALLOC. FAILED FOR yyyyyyyyy
Reason:
This message indicates input PDSDD member xxxxxxxx contained a JCLLIB statement with a data set (
yyyyyyyyyy) that could not be allocated.
Action:
Correct the data set entry in the JCLLIB concatenation.
08-Feb-2018 372/722
*** ERROR *** MEMBER xxxxxxxx INCLUDE JCLLIB OPEN FAILED FOR yyyyyyyyy
Reason:
This message indicates input PDSDD member xxxxxxxx contained a JCLLIB statement with a data set (
yyyyyyyyyy) that could not be opened.
Action:
Determine why the data set could not be opened and correct the problem.
*** ERROR *** MEMBER xxxxxxxx JCLLIB ERROR. CANNOT PROCESS THIS MEMBER
Reason:
This message indicates input PDSDD member xxxxxxxx contained a JCLLIB statement that could not
be resolved.
Action:
Fix the JCLLIB statement.
CA7--*** ERROR *** MEMBER xxxxxxxx SUBSTITUTION ERROR. CANNOT PROCESS THIS MEMBER.
Reason:
This message indicates input PDSDD member xxxxxxxx contained a symbolic that could not be
resolved.
Action:
Determine whether the symbolic is incorrect or a SET statement for the symbolic is missing or
invalid.
*** ERROR *** MEMBER xxxxxxxx SYMBOLIC ERROR. CANNOT PROCESS THIS MEMBER
Reason:
This message indicates input PDSDD member xxxxxxxx contained a JCL SET statement that could not
08-Feb-2018 373/722
This message indicates input PDSDD member xxxxxxxx contained a JCL SET statement that could not
be resolved.
Action:
Fix the JCL SET statement.
*** ERROR *** MEMBER xxxxxxxx SYSIN DD ALLOCATION FAILED FOR yyyyyyyy
Reason:
This message indicates the dynamic allocation for SYSIN data set (yyyyyyyy) failed.
Action:
Determine whether the data set exists and whether to process it. If the member is bad, delete the
member from the new PDS after the IEBUPDTE job has completed.
*** ERROR *** MEMBER xxxxxxxx SYSIN DD FIND ERROR FOR yyyyyyyyyy.
Reason:
This message indicates input PDSDD member xxxxxxxx contained a PDS data set name and member (
yyyyyyyyyy) in the SYSIN DD concatenation that could not be found.
Action:
Determine whether the member exists and is in the correct library.
*** ERROR *** MEMBER xxxxxxxx SYSIN DD OPEN FAILED FOR yyyyyyyy
Reason:
This message indicates that the attempts to open SYSIN data set (yyyyyyyy) failed.
Action:
*** ERROR *** MEMBER xxxxxxxx SYSIN DSN IS INVALID. CANNOT PROCESS THIS MEMBER
Reason:
08-Feb-2018 374/722
This message indicates the SYSIN DD data set name was not valid.
Action:
CA7TOUNI Batch Program

This article explains CA7TOUNI Batch Program usage considerations.
Similar to the Submit Function, any job whose JCL starts with #7UNI is treated as a cross-platform job.
When such a job completes on MVS, it is requeued to the ready queue with a CPU indication of
7UWT. The job stays in the ready queue until another job initiation record is received. When
initiation is received, the CPU indication is changed to 7UNI and normal job flow continues.
In the area of reporting, realize there are two sets of log records for each 7UNI job submitted. The
first set represents the MVS job that submitted data to the XPS SERVER. The second set represents
the job execution on the XPS SERVER operating environment. This second set consists of job
initiation, step termination, and job termination records only. No data set records exist, and not all
fields are filled in for the other records.
Concerning restart, we recommend that 7UNI jobs not include a CA Workload Automation Restart
Option for z/OS Schedulers restart step or have CA Workload Automation CA 7® Edition insert such a
step. Including CA Workload Automation Restart Option for z/OS Schedulers is unnecessary because
these jobs consist of a single step, produce no data sets, and must be totally rerun if restarted.
Because commands and parameters can be included in the JCL as SYSIN data, certain special
situations are applied to jobs flagged for submittal to another system. Many platforms are case-
sensitive to their input. However, unless CA Workload Automation CA 7® Edition Mixed Case Editing
is enabled, the CA Workload Automation CA 7® Edition editor forces all data to uppercase. Therefore,
edit functions of CA Workload Automation CA 7® Edition can only be used against JCL for cross-
platform jobs if INITCASE=Y is specified in the CA Workload Automation CA 7® Edition initialization
file.
Note: If CA Workload Automation CA 7® Edition Mixed Case Editing is not enabled, the
following JCL edit related features are not available for cross-platform (7UNI) jobs.
The following applies to these panels and functions:
DB.7 (JCL panel) FE function
QM.5 (QJCL panel) FE and FETCH functions
QM.1-X (XQ panel) E function
08-Feb-2018 375/722
If you must change the JCL for a 7UNI job, use an editor outside of CA Workload Automation CA 7®
Edition, such as TSO/ISPF or CA Roscoe®. If the JCL must be changed after the job enters the queues,
change the JCL outside of CA Workload Automation CA 7® Edition. Next, cancel and demand a new
version of the job. If the job was scheduled or triggered and cannot be canceled and demanded,
change the JCL outside CA Workload Automation CA 7® Edition. Use the JCL panel to FETCH it (do not
use FE or EDIT). Next use the QJCL panel to REPL the request queue job's JCL thus bypassing the CA
Workload Automation CA 7® Edition editor.
Submit CA7TOUNI
Submission consists of CA Workload Automation CA 7® Edition submitting a batch job that executes
program CA7TOUNI to send execution data through CAICCI to the XPS SERVER on the target
operating environment. The XPS SERVER on that operating environment submits the job and returns
CAIENF tracking data as it executes. Output from the job is directed to the XPS SERVER console on
that operating environment.
To use this interface, the MVS job must use JCL as described in the following paragraphs. The JCL
must begin with a #7UNI statement, and it must execute CA7TOUNI. All normal scheduling features
are available for the job. It can have schedules, predecessors, triggers, and resources.
When the job is submitted to MVS, it executes and completes. The job is returned to the ready queue
with a CPU indication of 7UWT to denote it is waiting on XPS SERVER submission. If an error occurs,
the job abends and is subject to restart considerations. When execution begins on the target
operating environment, the XPS SERVER returns tracking data and normal job flow resumes. The CPU
indication changes to 7UNI.
CA7TOUNI has one required and one optional parameter on the EXEC statement. The required
parameter is a unique number for tracking. The optional parameter is a jobset name. To facilitate
supplying these parameters, use a CA Driver procedure. This example shows JCL of such a procedure:
//CA7TOUNI DPROC
//STEP1 EXEC PGM=CA7TOUNI,
// PARM='&C_L27#,&C_L2SN'
//PROFILE DD DISP=SHR,DSN=cai.ca7.xps.profile
The CA 7 job number and system name respectively replace the CA Driver variables &C_L27# and
&C_L2SN when the product submits the job.
The PROFILE DD statement must reference a card image PDS that contains a member that is named
CACCENV. CACCENV contains keyword entries specifying environment parameters for the Submit
Function.
Note: The security ID under which the Submit job executes must have READ access to the
CA Workload Automation CA 7® Edition XPS Profile.
This example shows JCL that uses the CA Driver procedure:
08-Feb-2018 376/722
#7UNI
//CA7TOUNI JOB ...jobcard...values...
//STEP1 EXEC CA7TOUNI (execute CA-Driver proc)
//SYSIN DD *
...platform... (this could be in a data set)
...specific... (instead of using DD * )
...data...
/*
More parameters are required to specify what to execute and where to send the data. If the same
parameter is encountered in multiple sources, they are processed as follows:
EXEC PARM values override SYSIN and PROFILE values
SYSIN values override PROFILE values
The following items describe all parameters for CA7TOUNI:
DOMAIN
(Optional) Identifies a parameter that some requests sent to Windows platforms require.
Source: SYSIN or PROFILE
Note: The DOMAIN variable is only accepted from the same source as the NODE variable.
They both have to come from the PROFILE data or both from the SYSIN data. If the
DOMAIN variable is supplied from a source other than NODE, it is ignored. The request is
sent without a DOMAIN parameter.
JOBNO
Must match the CA 7 assigned job number to provide its uniqueness. The name must be supplied
as the first positional value of PARM input on the EXEC statement. Use a CA Driver procedure to
insert automatically the CA Workload Automation CA 7® Edition job number in the JCL for this
parameter.
Limits: 1 to 5 numeric characters
Source: EXEC PARM
Note: Even though JOBNO can be up to five digits, the product only supports four-digit job
numbers. Only the last four digits are sent with the cross-platform request. If the specified
job number is fewer than four digits, it is right-justified and zero-filled.
JOBSET
(Optional) When combined with the JOBNO and batch job name, this variable provides a unique
identifier for the cross-platform request. Avoid special characters. They do not always translate
correctly on the target operating environment. If omitted, the MONITOR value is used as JOBSET.
Use a CA Driver procedure to insert the CA Workload Automation CA 7® Edition system name in
the JCL for this parameter.
Default: MONITOR name
Source: EXEC PARM, SYSIN, or PROFILE
LINELEN
08-Feb-2018 377/722
LINELEN
(Optional) Controls the line length of the SYSIN input for the SUBFILE and PARM xx keyword
parameters. Typically CA7TOUNI automatically determines if columns 73 through 80 contain line
sequence numbers (LINELEN=AUTO). If column 72 contains a blank, null, or plus sign, and
columns 73 through 80 are numeric. Columns 73 through 80 are considered to be line sequence
numbers. Line sequence numbers are not considered part of the SUBFILE or PARM xx keyword
value.
The LINELEN keyword can override this automatic determination and can force CA7TOUNI to
consider the full 80-byte record as part of the data area (LINELEN=80). Or it can force CA7TOUNI
to ignore columns 73 through 80 (LINELEN=72) regardless of the contents of those columns.
Default: LINELEN=AUTO
Limits: AUTO, 72, and 80 are the only permitted values
Note: This keyword can be specified multiple times. The last valid LINELEN specification
that is processed before the current line controls processing for SUBFILE and PARM xx
keywords.
MONITOR
When combined with the local CAICCI node, this parameter uniquely identifies the copy of the
product submitting this cross-platform request. The value must be exactly seven characters.
Avoid CA7PROD as the product commonly uses this name. If only one copy of CA Workload
Automation CA 7® Edition is executing, use CA7 followed by the SMF-ID of the originating system.
If you are executing multiple CA Workload Automation CA 7® Edition instances, use CA7 followed
by the instance name, such as CA7CA73. This value must match the one used by the CA Workload
Automation CA 7® Edition Cross-Platform Tracking System (XTRK).
Limits: 7 alphanumeric characters
Source: PROFILE
NODE
Identifies the CAICCI node of the target system for this request. The name must match what is
defined in CAICCI on that system.
PARM1 thru PARM64

(Optional) Supplies values to use on the target operating environment. Values can be 1 through
256 characters. Avoid special characters. They do not always translate correctly on the target
operating environment. Embedded blanks result in the XPS SERVER on the target operating
environment enclosing the value in double quotes. Because JCL is limited to 80 characters per
record, continuation can be required. To continue a record, end it with a plus sign (+) and
continue in column 1 of the next statement. The ending plus sign does not appear in the resulting
value. Keyword checking is suspended during a continuation operation.
Source: SYSIN
08-Feb-2018 378/722
SUBCHECK
(Optional) Forces a security test for authorization of the currently running user to submit jobs for
the ID supplied in SUBUSER. This value can override the instance default that CAIRIM sets. If the
value of BSUBCHK is N, the security test is not done unless SUBCHECK overrides it. For more
information about BSUBCHK, see Security Considerations for Cross-Platform Scheduling (
https://wiki.ca.com/display/CWAC7E/Security+Considerations+for+Cross-Platform+Scheduling).
Limits: YES or Y
Source: PROFILE
Note: This parameter cannot be used to turn off submit checking. A setting of NO causes a
warning message, and the parameter is ignored.
SUBFILE
Identifies the script or command that the XPS SERVER executes. The name has the same size,
content, and continuation characteristics as the previous PARMx values. The script that is named
must reside in a special directory that is identified to the product or must indicate a fully qualified
path name. For more information about client/server processing and the CAISCHD0004 variable,
see the CA NSM documentation.
Source: SYSIN
SUBPASS
(Optional) Identifies the password to pass with SUBUSER to the target operating environment.
The password is sent to the target system in an encrypted format. Some target systems require
that a password accompany the SUBUSER on cross-platform requests.
Note: The SUBPASS variable is only accepted from the same source as the SUBUSER
variable. That is, they both have to come from the PROFILE data or both from the SYSIN
data. Sometimes, the SUBPASS variable is supplied from a source other than the SUBUSER.
In this case, SUBPASS is ignored. The request is sent without a password.
SUBROOT
(Optional) Determines whether the special user ID of ROOT can be used for job submission. The
user ID of ROOT has special meaning and capabilities on many non-MVS platforms. We
recommend that you not use it when submitting work from MVS. By default, this interface does
not permit ROOT. To submit work using ROOT as the user ID, this parameter must be set to YES or
Y.
08-Feb-2018 379/722
Y.
Default: NO
Limits: YES, NO, Y, N
Source: PROFILE
SUBUSER
(Optional) Identifies the user ID for security purposes on the target operating environment. If
omitted, the user ID of the executing MVS job is extracted and used. A test is performed to see
whether the user ID ROOT is in use. In that case, the setting for parameter SUBROOT controls
submission. Regardless of the setting for SUBROOT, the use of ROOT as the user ID causes the
issuing of a WARNING message. Because the user ID ROOT has special meaning on UNIX
platforms, we recommend that you not specify ROOT.
Default: Batch job user ID
SUTYPE
(Optional) Determines the type of "switch user" command to execute when the target node is
UNIX.
YES
Executes an SU- command causing the environment setup to include execution of the '.
PROFILE' for the target user.
NO
Executes an SU command without the profile option.
Default: YES
XPHAO
(Optional) Enables the High Availability Option (HAO) for tracking CA7TOUNI jobs. The value must
match the value set in the XPDEF file initialization statement XPHAO keyword of the copy of CA
Workload Automation CA 7® Edition that the CA7TOUNI batch job submits.
Default: None
Limits: Must match XPDEF XPHAO keyword value
7TRACE
(Optional) Turns on the trace facility to assist in tracking down problems. If the parameter is set to
YES, more messages are written to the SYSPRINT DD. The messages can be helpful in pinpointing
when an error is encountered.
Default: NO
Examples
This example has a job that lists the product status on the target operating environment.
#7UNI
//TESTJOB1 JOB ...jobcard...values...
//STEP1 EXEC CA7TOUNI (CA-Driver proc)
//SYSIN DD *
node=newyork
08-Feb-2018 380/722
node=newyork
subuser=ca7user
subfile=unifstat
/*
This example shows a CACCENV member.

monitor=ca7mvsa
jobset=fromca7
Note: If the submit function encounters an error that prevents the request from being sent
to the target system, the submit step abends with a User 4000 code (U4000). To determine
the exact nature of the problem, see the messages in the submit job output.
Manage XTRK as an STC or Job

The Cross-Platform Tracking System (XTRK) can work as an STC or job.
Cross-Platform Tracking JCL (see page 381)

XPS Client Implementation Checklist (see page 383)
Cross-Platform Tracking JCL

This example shows JCL for the CA Workload Automation CA 7® Edition XTRK:
//CA7XTRK EXEC PGM=CAL2XTRK,PARM='...parm...values...'
//STEPLIB DD DISP=SHR,DSN=...ca7..caiload...
//XCKPT DD DISP=OLD,DSN=...xtrk..checkpoint...
//XEVENTS DD DISP=SHR,DSN=...xtrk..xtracking(rules)... **optional**
//XPRINT DD SYSOUT=*
//XSNAP DD SYSOUT=*
The XCKPT DD must point to a CA Workload Automation CA 7® Edition Cross-Platform Checkpoint file.
Each copy of XTRK must have its own Checkpoint file. The DCB parameters for Checkpoint files are:
DSORG=PS,RECFM=FB,LRECL=4096,BLKSIZE=4096
One track is sufficient for most sites. The Checkpoint file does not require preformatting.
The XEVENTS DD is optional. If specified, it should point to an 80 byte statement-image sequential

data set, or PDS member, which contains CA Workload Automation CA 7® Edition cross-platform
external tracking rules. These rules define what events that occur on other systems CA Workload
Automation CA 7® Edition tracks even though CA Workload Automation CA 7® Edition did not submit
the work that caused these events to take place. For more information about the format of these
rules, see Cross-Platform External Tracking.
The following code shows the EXEC PARM values for XTRK:
PARM='monitor[,ca 7 instance name][,trace-codes]'
08-Feb-2018 381/722
monitor
Identifies the seven character monitor name that uniquely identifies the copy of CA Workload
Automation CA 7® Edition whose cross-platform jobs are tracked. The name must match the
MONITOR value used by the CA Workload Automation CA 7® Edition Cross-Platform Submit jobs
to track (CA7TOUNI).
ca 7 instance name
(Optional) Specifies the instance name of the CA Workload Automation CA 7® Edition for which
this copy of XTRK is collecting. This parameter controls which copy of CA Workload Automation
CA 7® Edition receives the pseudo-SMF feedback generated by this copy of XTRK. The primary
copy of CA Workload Automation CA 7® Edition (referred to as the production copy in r3.3) has an
instance name of CA71. The secondary copy of CA Workload Automation CA 7® Edition has an
instance name of CA72. Other available instances are named CA73 through CA78. The values
PROD or UC07 can be used instead of CA71, and the values TEST or UCT7 can be used instead of
CA72.
Note: The RNAME value does not affect this setting.
trace-codes
(Optional) Specifies the level of diagnostic messages and snaps that XTRK generates. You can
specify two codes: print/snap trace code and console message trace code. The first value controls
what messages are written to the XPRINT DD, and what records and control blocks are written to
the XSNAP DD. The second value controls what WTOs are issued to the system console. The
default trace codes are '21'. The following list shows the possible trace codes:
0
QUIET MODE - Only severe error WTOs. This value is only honored for the console trace code.
If entered for the print trace code it is interpreted the same as a code of 1.
1
NORMAL MESSAGES/WTOS. These messages indicate XTRK system startup and shutdown.
They also indicate when communication with remote systems is first established, if such
communication is lost, and if it is reestablished.
2
FEEDBACK MESSAGES/WTOS. In addition to the messages issued for trace code 1, messages
relating to cross-platform feedback events are issued.
3
COMMUNICATION MESSAGES/WTOS. In addition to the messages issued for trace code 2,
messages relating to CAICCI communications with other systems are issued. Also, messages
are issued for pseudo-SMF records generated and sent to CA Workload Automation CA 7®
Edition. Also, if the XSNAP DD is available, snap dumps are taken of the storage areas related
to CAICCI control blocks and records, and pseudo-SMF records.
4
PROGRAM PATH MESSAGES/WTOS. In addition to the messages issued for trace code 3,
messages relating to internal XTRK processing are issued. Also, if the XSNAP DD is available,
snap dumps are taken of the storage areas related to XTRK control blocks, in addition to the
communication and feedback-related snaps.
08-Feb-2018 382/722
Note: Use trace code 4 only at the direction of CA Support because it produces a
significant number of messages.
5-9
Trace codes 5 through 9 do not have specific definitions. If entered, they are interpreted the
same as trace code 4.
Note: Messages that indicate critical errors are always issued as WTOs regardless of the
trace code settings. Also, all error and warning messages (message-IDs ending with E or
W) are always written to the trace print (if available) regardless of the current trace code
settings.
PARM Example
This example starts XTRK for a production CA Workload Automation CA 7® Edition system whose
monitor name is 'CA7IPO1', a print trace code of '3' and a console trace code of '1'.
PARM='CA7IPO1,CA71,31'
XPS Client Implementation Checklist

Connections.
XPS SERVER.
Note: This interface requires CA Common Services for z/OS.
2. Allocate and initialize the CA Workload Automation CA 7® Edition XPS Profile PDS. See CA
Workload Automation CA 7® Edition CAL2JCL member AL2XPROF and Batch Program
CA7TOUNI.
3. Allocate CA Workload Automation CA 7® Edition XTRK Checkpoint files.

See CA Workload Automation CA 7® Edition CAL2JCL member AL2XPSCK and the Cross-
Platform Tracking JCL information preceding this checklist.
Note: This allocation is sometimes completed when installing or upgrading CA

Workload Automation CA 7® Edition and is not always necessary.
4.
08-Feb-2018 383/722
4. Define and start CA Workload Automation CA 7® Edition Cross-Platform Tracking Tasks (XTRK).
See CA Workload Automation CA 7® Edition JCLLIB member CA7XTRK (prefix can change
based on SYSGEN) and the previous topic in this article. This procedure can appear in the
PROCLIB if the CA07N020 installation job was executed.
5. Define the CA-Driver Procedure for the CA Workload Automation CA 7® Edition XPS Submit
Function.
See CA Workload Automation CA 7® Edition CAL2OPTN member AL2P2UNI and Batch Program
CA7TOUNI. If you are not familiar with CA-Driver, see CA Driver Procedures, Variable
Parameters, and Functions.
6. Define the CA Workload Automation CA 7® Edition cross-platform jobs and JCL for the Submit
Function.
See CA Workload Automation CA 7® Edition CAL2JCL member AL2TOUNI and to Batch
Program CA7TOUNI. Define and schedule the jobs like any other CA Workload Automation CA
7® Edition job; only the JCL is different.
7. Schedule/Demand the Cross-Platform Job on CA Workload Automation CA 7® Edition.

See the CA Workload Automation CA 7® Edition documentation on scheduling and demanding
CA Workload Automation CA 7® Edition jobs.
When the cross-platform jobs are submitted, the request is routed to the specified operating
environment (XPS Server). The feedback is returned to CA Workload Automation CA 7®
Edition (XPS Client).
Manage XTRK under ICOM

This article explains how to manage cross-platform tracking (XTRK) and ICOM.
Cross-Platform Tracking ICOM PARM Values (see page 384)

Cross-Platform Tracking ICOM DD Statements (see page 385)
Cross-Platform Tracking ICOM WTOR/MODIFY Replies (see page 386)
Cross-Platform Tracking ICOM PARM Values

You can execute the CA Workload Automation CA 7® Edition XTRK as a subtask in the ICOM address
space. Add the following parameters to the SASSICOM EXEC statement.
XMONITOR=monitor-name
This required parameter is the seven-character monitor name that uniquely identifies each copy of
CA Workload Automation CA 7® Edition whose cross-platform jobs are tracked. The name must
match the MONITOR= value that is used by the CA Workload Automation CA 7® Edition Cross-
Platform Submit jobs to track (CA7TOUNI).
08-Feb-2018 384/722
Note: This parameter is required if you want to execute the CA Workload Automation CA
7® Edition XTRK system in the ICOM address space. If this parameter is specified, the XCKPT
DD statement for the CA Workload Automation CA 7® Edition Cross-Platform Tracking
Checkpoint file must be present in the ICOM JCL.
XTRC=trace-codes
These optional codes specify the level of diagnostic messages and snaps that XTRK generates. Two
codes can be specified: print/snap trace code and console message trace code. The first value
controls what messages are written to the XPRINT DD, and what records and control blocks are
written to the XSNAP DD. The second value controls what WTOs are issued to the system console.
The default trace code is 'XTRC=21'.
Note: If used, add the XMONITOR and XTRC keywords to the end of the SASSICOM
parameter list. Also precede them with commas to separate them from other PARM
values.
More information:
Cross-Platform Tracking ICOM DD Statements

You can execute the CA Workload Automation CA 7® Edition Cross-Platform Tracking System (XTRK)
as a subtask in the ICOM address space. Add the following DD statements to the SASSICOM JCL.
XCKPT
Required if the XMONITOR keyword is specified in the SASSICOM EXEC parameters) Points to a
Cross-Platform checkpoint file. Each copy of XTRK must have its own checkpoint file. That is,
assume that you are running ICOM on two separate mainframe images and you want to run XTRK.
In this case, each copy requires a separate checkpoint file.
XEVENTS
(Optional) Points to an 80 byte card-image sequential data set, or PDS member, which contains
cross-platform external tracking rules. These rules define what events that occur on other
systems CA Workload Automation CA 7® Edition tracks even though it did not submit the work
that caused these events to take place.
08-Feb-2018 385/722
Note: If you are running XTRK on multiple mainframe images, do not specify the same
external tracking rules for more than one copy of XTRK. This situation could cause the
product to receive multiple copies of the same tracking information from different copies
of XTRK.
XPRINT
(Optional) Specifies a SYSOUT class for Cross-Platform Tracker (XTRK) trace messages. The first
value of the XTRC keyword in the SASSICOM EXEC parameters controls the type and volume of
messages produced.
XSNAP
(Optional) Specifies a SYSOUT class for Cross-Platform Tracker (XTRK) storage snap output. The
first value of the XTRC keyword in the SASSICOM EXEC parameters controls the type and volume
of output produced.
More information:
Cross-Platform Tracking ICOM WTOR/MODIFY Replies

If you execute the Cross-Platform Tracking System (XTRK) as a subtask of ICOM, you can pass
commands to the XTRK task using the CA-7.575 WTOR or a MODIFY command. Responses to these
commands are issued as WTOs and are explained in Messages and Codes (https://wiki.ca.com/display
/CWAC7E/Messages+and+Codes).
This example shows the ICOM reply/command for XTRK:

XTRK=...native XTRK command...
For example, to issue a MODIFY command to display all nodes connected to XTRK issue:
F CA7ICOM,XTRK=NODE
More information:
08-Feb-2018 386/722
XPJOB Conversion Utility

The XPJOB Conversion Utility lets users convert existing XPJOBs that run on UNIX or Windows
platforms to Agent (AGJOB) jobs. Before the conversion, verify that you have purchased the
appropriate CA Workload Automation Agent for UNIX or Windows. Also verify that you have installed
CA Integrated Agent Services (CA IAS) as described in Implement CA IAS (https://wiki.ca.com/display
/CWAC7E/Implement+CA+IAS).
The XPJOB Conversion utility has two benefits. First, the utility provides a semi-automated
mechanism for changing your XPJOBs to UNIX (UNIX_JOB) or Windows (NT_JOB) definitions. Second,
the utility maintains any requirements, triggers, and schedules that are associated with the original
XPJOB definition.
One of the most significant differences you see when the conversion completes is the lack of XPJOB
PARMnn statements (assuming that they were present in the original XPJOB definition). The XPJOB
PARMnn statements are converted to a single agent ARGS statement. Each PARM nn statement value
is wrapped in double quotes inside the ARGS statement. A single space between each entry
delineates multiple arguments (PARMnn statements).
During the conversion:
The backup copies of existing XPJOB Optional PARMLIB members are created. You are responsible
for verifying that any data set containing Optional PARMLIB information is included in the JCL
creating the backup. The next step generates a series of explicit LJOB and LJCL statements for
each XPJOB meeting the LJOB selection criteria that you provided.
The conversion file, XNODE and XPSWD cleanup files, and agent user ID/password file are
generated using the output from bullet item 1 as input. When this job completes, you have the
Batch Terminal Interface (BTI) files necessary to convert your XPJOBs to agent jobs and clean up
related XNODE and XPSWD entries.
When the bullet item 2 is complete, the Batch Terminal Interface program reads the conversion
file that was created to perform the actual conversion. For most cases, except where stated, use
the Batch Terminal Interface program for reasons later discussed.
The Agent Security file, also created as part of bullet item 2, is processed. When complete, the
user IDs and passwords that are required to run the jobs at the Agents are defined.
After you are sure the converted AGJOBs run successfully, you can clean up old XNODE and
XPSWD entries that the original XPJOBs used. Again, the BTI procedure is executed, but in this
case, twice. The first BTI execution processes the BTI file that is created in bullet item 2 to delete
XPSWD records. The second BTI execution processes the BTI file to delete XNODE records.
Run the XPJOB

This article explains the conditions required to run the XPJOB.
08-Feb-2018 387/722
Tip: After meeting these conditions, complete the procedures in this section in sequential
order.
The following conditions and rules must be true for the conversion to complete successfully:
The XPJOB must have successfully executed in the CA Workload Automation CA 7® Edition
environment without QJCL updates. Jobs that have not run successfully most likely have errors
that would preclude their successful conversion.
Do not attempt to convert jobs that go to another CA Workload Automation Mainframe

Scheduling product. Only jobs that are destined for a UNIX or Windows environment can be
converted.
A one-to-one match of the XPJOB job name definition and the Optional PARMLIB member name
(when specified) must exist. If they do not match, the job is not converted. If the XPJOB does not
have an Optional PARMLIB member, one is created during the conversion using the XPJOB job
name. This member becomes part of the agent job definition.
XPJOB extraction is based on the LJOB commands you enter for Step I processing. If you enter
multiple LJOB commands (which is allowed), you could select the same job more than once for
conversion. In these situations, the first instance of the job converts successfully while the
remaining jobs do not convert. We strongly recommend that your LJOB input is explicit enough to
prevent this problem.
Program paths are important. If the agent program path does not match the XPJOB program path,
an XPJOB that executes cannot execute as an Agent job.
AGJOB syntax rules can prevent a job from being converted. In these situations, convert the job
manually. For example:
XPJOBs containing #JI/#JO or #XI/#XO cards are not converted.
XPJOBs containing DPROC= cards are not converted.
XPJOBs whose total length for all PARMnn values exceeds 4078 bytes are not converted. PARMnn
cards are converted to an ARGS statement for UNIX and Windows Agent jobs. The maximum
length of an ARGS statement is 4078 bytes.
XPJOBs do not require a user ID or password for execution whereas AGJOBs do. If the XPJOB does
not have an associated user ID and password, it is not converted.
XPJOB XP EXEC statements can be 244 characters in length. The equivalent AGJOB CMDNAME
cannot exceed 100 bytes. Because we must wrap the CMDNAME in open and closing double
quotes, XP EXEC statements that exceed 98 bytes are not converted.
If present, the CA Workload Automation CA 7® Edition Cond-Code/RO logic is converted to an

AGJOB EXITCODE parameter. The Cond-Code value for a GT and LT specification can prevent a job
from converting.
Plan to execute this conversion process during periods of low CA Workload Automation CA 7®
Edition activity, because jobs are changing and also because the CA Workload Automation CA 7®
Edition VRM file is read.
08-Feb-2018 388/722
Comments in the XPJOB Optional PARMLIB member are not carried forward because their logical
placement in the new agent member cannot be guaranteed.
The XPJOB Conversion Utility generates a report that shows the processing for each request. Any job
with an ** ERROR ** message is not converted. Jobs with ** WARNING ** messages are converted.
This typically occurs because certain XPJOB fields (SUTYPE, Trace, and Retain) have no equivalent
AGJOB field so they are “dropped” during conversion. This can also occur if the XPJOB definition has
#SCC Condition Code/Relational Operator logic as #SCC cards are dropped during conversion.
Back Up and Extract XPJOB List

This article explains how to run the Backup and Extract XPJOB job The number of steps in the Backup
and Extract XPJOB job depends on the number of optional PARMLIB data sets requiring backup.
During conversion, the original XPJOB Optional PARMLIB members are deleted. The sample JCL
provides two input and output data sets. You can add or delete data sets depending on your needs.
Do not forget to update the COPY INDD statements to match your input and output data sets.
After the IEBCOPY step, the CA Workload Automation CA 7® Edition Batch Terminal Interface Utility
(BTI) is executed. The BTI utility uses LJOB commands as its input. You can enter any number of LJOB
commands to identify the XPJOBs that are selected for conversion. Be careful entering multiple
generic LJOB commands because these commands can select the same job for conversion multiple
times. To convert only jobs that run at specific nodes, use the LJOB,NODE= syntax. To convert all
XPJOBs, use the LJOB,MAINID=XPJ syntax.
The final step of this job runs a sanity check on the LJOB output. In effect, any job that is not an
XPJOB is eliminated from the output. When this step has completed, you have a BTI file consisting of
paired LJOB/LJCL statements for each XPJOB that selected for conversion. Step II uses this BTI file as
input.
The X2U1REPT DD statement contains a report listing each job selected for conversion. The last line
of the report shows the total number of jobs selected. If you have no jobs in the list and no total
number count, no XPJOBs met the specified LJOB selection criteria.
You can modify the JCL in member AL2AGJC1 in CAL2JCL to back up your libraries and to create your
XPJOB conversion list.
Generate XPJOBs to AGJOBs BTI Files

This procedure consists of a two-step job. The first step executes the BTI utility, using as input the
X2U1BTIO DD output created in AL2AGJC1. The step generates an output file containing the detailed
information that is required for use by the program (SASSX2U2) invoked in JS020.
The sample JCL is in member AL2AGJC2 in CAL2JCL. The following topics describe the JS020 input and
output DDs.
Input JCL Statements (see page 389)
Output JCL Statements (see page 392)
Input JCL Statements

08-Feb-2018 389/722
SASSX2U2 DBPARM DD Statement

Specifies the CA 7 database from which to extract data.
SASSX2U2 X2U2NODE Statement

This file contains Node-Agent relationship information. Every XPJOB that currently runs at NODE x
will run at AGENTy after the conversion is complete. You should already have defined agents as
part of the CA Integrated Agent Services (CA IAS) installation. Your job is to identify the Node-
Agent associations and place them in this file. Code as many as you need. This file is a comma-
delimited file containing the following fields:
NODE (1-8 characters - required)
AGENT (1-16 characters - required)
JOBTYPE (6-8 character, constants below - required)
NT_JOB for Windows
UNIX_JOB for UNIX
JCLLIB (JCL Library that appears in the /DISPLAY,ST=JCLVAR output - optional)
During XPJOB definition (DB.10 screen), the node where the job would run was entered in the XP
Node field. So, every XPJOB has an associated Node which can be up to eight characters in length.
This information is what is placed in the NODE position.
Assume that all XPJOBs running at NODEx run at AGENTy when conversion is completed. Thus, AGENT
y is what is placed in the AGENT position.
As stated earlier, XPJOBs can be converted to NT_JOBs or UNIX_JOBs. If the NODE where the XPJOB
runs is a Windows operating environment, use NT_JOB for the JOBTYPE. If the NODE where the
XPJOB runs is a UNIX operating environment, specify UNIX_JOB for the JOBTYPE.
Not all XPJOBs have an Optional PARMLIB. Agent jobs require a PARMLIB. You can specify a JCL library
where information required by the agent job is stored. This library is only used in the following cases:
The XPJOB XP Node information matches a NODE in this table.
The XPJOB does not already contain an Optional PARMLIB.
The JCL library specified must match a library in the /DISPLAY,ST=JCLVAR output. If you do not specify
this field and the XPJOB does not contain an Optional PARMLIB, specify a default PARMLIB in the
SYSIN DD (discussed later in this topic); otherwise, the job is not converted.
Examples
NYNODE1,NYAGENT005,UNIX_JOB,highlvl.cai.JCLLIB1
MYWIND,MYAGENT,NT_JOB
YOURWIND,YOURAGENT,NT_JOB,highlvl.cai.JCLLIB2
Remember, every unique XP Node (associated to the XPJOB being converted) must have an entry in
this file.
SASSX2U2 X2UTBTII Statement

This file contains all the LJOB and LJCL output for the XPJOBs requested for conversion. The file is
created in the first job step as a temporary file.
SASSX2U2 SYSIN Statement

(Optional) The SYSIN data set contains processing keywords used by SASSX2U2. If this statement
is not supplied, the following occurs:
08-Feb-2018 390/722
No back out job is created. If you have a problem with the converted job, you cannot restore
it back to its XPJOB state.
No default PARMLIB is supplied. If the XPJOB being converted does not have an Optional
PARMLIB, and one was not specified on the appropriate NODE line in the X2U2NODE file, the
XPJOB is not converted.
The three valid keywords are RESTMASK, DEFPRLIB, and INTERACT.
RESTMASK
Defines a two-character value that creates the restore name of the XPJOB definition. If a
RESTMASK is not provided, a backup of the XPJOB definition is not created. The member being
converted has a character in its name replaced by the mask. The first character is the
replacement character, and the second character indicates the offset of the replacement
character in the member name. For example:
RESTMASK=$2
The restore name for member CA7XJOB is C$7XJOB.
RESTMASK=#3
The restore name for member CA7XJOB is CA#XJOB.
If the member name is not as long as the offset position, the mask character is placed in the first
blank position of the member name. For example:
RESTMASK=$4
The restore name for member CA7X is CA7$.
The restore name for member CA7Y is also CA7$.
Important! If the mask character becomes the last character of the member name, you
could end up with duplicate member names and could get unwanted results during
conversion. In the preceding situation, CA7Y would not convert. However, its JCL would be
deleted. This situation is discussed in greater detail under SASSX2U2 X2U2CONV DD.
The last RESTMASK value specified in the SYSIN DD statement is the value used when creating the
restore name.
Before conversion, verify that your CA Workload Automation CA 7® Edition database has enough
space to hold backup copies of the XPJOBs being converted.
DEFPRLIB
Identifies the default PARMLIB data set used to hold required AGJOB information. Remember,
XPJOBs may or may not have an Optional PARMLIB specified whereas AGJOBs require a PARMLIB.
The hierarchy of placement is as follows:
1. If the XPJOB definition has an Optional PARMLIB/MEMBER specified, the AGJOB information
replaces the XPJOB information in this library.
2. If the XPJOB definition has no Optional PARMLIB/MEMBER, AGJOB information is placed in

the JCLLIB specified in the X2U2NODE DD statement for the NODE where the XPJOB
executes.
3. If no JCLLIB is specified in the X2U2NODE DD statement for the NODE where the XPJOB
executes, AGJOB information is placed in the DEFPRLIB library.
4. If a DEFPRLIB is not specified, the job is not converted (assuming the conditions described in
08-Feb-2018 391/722
4. If a DEFPRLIB is not specified, the job is not converted (assuming the conditions described in
Items 1 and 2 are not met).
This parameter has the following syntax:
DEFPRLIB=highlvl.CAI.JCLLIB
This library must be found in the /DISPLAY,ST=JCLVAR output. If not, a WTO is issued, and
the job terminates.
INTERACT=NO|YES
Identifies whether the AGJOB runs in foreground or background on the Windows operating
environment (not valid with UNIX_JOBs). Valid values are YES and NO. NO is the default. If
something other than YES or NO is specified, NO is used. As a simple example, consider an AGJOB
that invokes the Windows Calculator. If you execute C:\WINDOWS\SYSTEM32\CALC.EXE without
the INTERACT parameter, you do not see the calculator on your monitor. If you execute with the
INTERACT parameter set to YES, you see the calculator on your monitor.
Output JCL Statements

The following are the output data sets:
SASSX2U2 X2U2CONV Statement

The X2U2CONV data set is a physical sequential output data set. The CA Workload Automation CA
7® Edition commands that convert the XPJOB to the AGJOB are written to this data set. Although
you can edit the X2U2CONV data set before running it through the Batch Terminal Interface (next
Step), we discourage it.
The following is an example of the output:

/LOGON MASTER
DBM
CONVERT,XPAG0006,BACKUP=X$AG0006,JOBTYPE=NT_JOB
AGJOB
UPD,XPAG0006,
AGJOBTYP=NT_JOB,
AGENT=MACAGENT,
AG1=tant\userid
JCL,
DELETE,XPAG006,DSN=highlvl.cai.JCLLIB
JCL,XPAG0006
EDIT
MIXED
XSEQ
I ,
CMDNAME "c:\nsm\bin\cau9test.exe"
ARGS "f=0008"
Exitcode 0-7 Success
Exitcode 0008-9999 Failure
$IEND
SAVE
SAVE,XPAG0006,DSN= highlvl.cai.JCLLIB
CLEAR
DBM
As the example shows, you always have the following commands:
DBM statement
CONVERT statement
AGJOB statement
08-Feb-2018 392/722
AGJOB statement
JCL Statement
If your XPJOB did not have an Optional PARMLIB, you do not have a JCL statement followed by a
DELETE. In these situations, you see PRMLIB and MEMBER keyword/value pairs that are used during
agent job definition.
Important! Conversion is a destructive process. You can enter each of the commands
noted previously by itself and succeed or fail. For example, the CONVERT and AGJOB
commands could fail, but the JCL DELETE could succeed. Thus, you are left with an XPJOB
definition and no Optional PARMLIB member.
Two conditions can cause the conversion to fail.
You are trying to CONVERT the same job twice. The first conversion is successful, the second fails.
This failure is not, however, catastrophic! The subsequent AGJOB statement makes the same
updates the initial AGJOB statement made during conversion. Subsequent JCL statements also
execute as they did during the initial conversion.
The RESTORE name already exists. If the RESTORE name exists as a result of converting the same
job twice, you have the same situation as the first bullet item (for example, nothing catastrophic).
If, however, this conversion attempt is your first and a RESTORE name is already in the database,
you can be left with an XPJOB definition and no Optional PARMLIB member.
Regarding the second bulleted item, consider this example where the RESTMASK was set to 8$ (so
the last character of the member name is changed to the mask character).
CONVERT,ABCDE1,BACKUP=ABCDE$,JOBTYPE=NT_JOB
CONVERT,ABCDE2,BACKUP=ABCDE$,JOBTYPE=UNIX_JOB
Job ABCDE1 completes successfully. Job ABCDE2 fails because the backup name already exists. Job
ABCDE2's Optional PARMLIB (if present) is deleted. A backup of the ABCDE2 Optional PARMLIB exists
in the backup copies created in job AL2AGJC1.
Important! Verify that duplicate backup members do not exist, or will not exist, when the
CONVERT command is executed. Also, remember the same process was used during the
CA7TOUNI to XPJOB conversion. Verify that the RESTMASK used for converting XPJOBs to
agent jobs is not the same one that you used for the CA7TOUNI to XPJOB conversion.
SASSX2U2 X2U2ASEC Statement

(Required) The X2U2ASEC data set is a physical sequential output data set. This data set contains
the information necessary to build the agent user ID/password records required to run the
converted job at the agent. This data set is used as input to job AL2AGJC3, described later in these
topics. Do not worry about duplicate entries in this data set. They are resolved when job
AL2AGJC3 is executed.
XPJOBs that contain SUBUSER/SUBPASS information in the Optional PARMLIB member have that
information transferred to the X2U2ASEC data set. Thus, consider restricting who can access this
08-Feb-2018 393/722
information transferred to the X2U2ASEC data set. Thus, consider restricting who can access this
data set. No other password information is maintained in this data set. This information is
described in more detail in Step IV - Generating Agent User-ID/Password Records.
SASSX2U2 X2U2REST Statement

(Required) The X2U2REST data set is a physical sequential output data set. The CA Workload
Automation CA 7® Edition commands that restore the AGJOB back to an XPJOB are written to this
data set. The Restore command is a single-line command.
RESTORE,CA7XJOB,BACKUP=CA7$JOB
The Restore command is a destructive command. The command wipes out an AGJOB definition
created by the Convert command. If the Restore command is executed, you also must copy the
original Optional PARMLIB member (if present) from the backup data set (created by AL2XPJC1)
to the appropriate CA Workload Automation CA 7® Edition JCL library.
Remember, if a RESTMASK is not provided, no backup of the CA Workload Automation CA 7®
Edition XPJOB definition is created. To restore, delete the AGJOB definition, create a "new" XPJOB
definition, and copy the original Optional PARMLIB member back from the data set created in the
AL2AGJC1 job.
SASSX2U2 X2U2XNOD Statement

(Required) The X2U2XNOD data set is a physical sequential output data set. The CA Workload
Automation CA 7® Edition commands that delete Node records from the database are written to
this data set. This data set is input to JCL procedure CA7BTI and is discussed in more detail in Step
V - XPJOB Clean Up.
SASSX2U2 X2U2XPSW Statement

(Required) The X2U2XPSW data set is a physical sequential output data set. The CA Workload
Automation CA 7® Edition commands that delete Owner and Node Access records from the
database are written to this data set. This data set is input to JCL procedure CA7BTI and is
discussed in more detail in Step V - XPJOB Clean Up.
SASSX2U2 X2U2REPT Statement

(Required) The X2U2REPT statement is a SYSOUT data set. All informational, warning, and error
messages generated during the AL2XPJC2 job are written to this data set. Inspect this report
thoroughly before proceeding to Step III - Processing the Conversion BTI File.
Your XPJOB definitions dictate the messages you see. Ideally you only see informational or warning
messages. However, because of some situations where we cannot convert, error messages
sometimes occur. A truncated sample of the report follows.
SASSX2U2-01 CA Workload Automation XPJOB-
AGJOB Conversion Report PAGE 1
DATE: 06/30/yy
JOBNAME C4MSG01SELECTED FOR PROCESSING
*** WARNING *** -
JOBNAME C4MSG01WILL NOT RETAIN PARMLIB INFO IN PRIOR RUN QUEUE WHEN CONVERTED
*** WARNING *** - JOBNAME C4MSG01 WILL NOT RETAIN PARMLIB INFO IN PRIOR RUN QUEUE WH
EN CONVERTED
JOBNAME C4MSG01 CONVERT COMMANDS SUCCESSFULLY CREATED

JOBNAME C4MSG02 SELECTED FOR PROCESSING

*** WARNING *** - JOBNAME C4MSG02 WILL NOT RETAIN PARMLIB INFO IN PRIOR RUN QUEUE WH
EN CONVERTED
JOBNAME C4MSG02 CONVERT COMMANDS SUCCESSFULLY CREATED

JOBNAME C4MSG02A SELECTED FOR PROCESSING

*** WARNING *** - JOBNAME C4MSG02A WILL NOT RETAIN PARMLIB INFO IN PRIOR RUN QUEUE WH
08-Feb-2018 394/722
*** WARNING *** - JOBNAME C4MSG02A WILL NOT RETAIN PARMLIB INFO IN PRIOR RUN QUEUE WH
EN CONVERTED
*** ERROR *** - JOBNAME C4MSG02A EXEC EXCEEDS 100 CHARACTERS, JOB NOT CONVERTED

JOBNAME C4MSG02B SELECTED FOR PROCESSING

*** WARNING *** - JOBNAME C4MSG02B WILL NOT RETAIN PARMLIB INFO IN PRIOR RUN QUEUE WH
EN CONVERTED
JOBNAME C4MSG02B CONVERT COMMANDS SUCCESSFULLY CREATED
…..
…..
…..
Members Selected for Conversion............. 15
Members Successfully Converted............... 6
Members Not Converted........................ 9
SASSX2U2 Return Codes

The conversion utility program (SASSX2U2) returns one of the following four return codes:
RC=0
Indicates that the job ran successfully. Only informational messages are written to the X2U2REPT
DD statement.
RC=4
Indicates that the job ran successfully, but one or more members had warning messages issued.
Review the warning messages in the X2U2REPT DD statement to see what is not in the converted
job.
RC=8
Indicates that the job ran successfully, but one or more members had errors that prevented the
creation of conversion statements. Review the error messages in the X2U2REPT DD statement,
and determine the necessary action.
RC=12
Indicates that the job failed. No CONVERT commands were generated. Review the WTO in the
job's JES JOBLOG for the cause of the failure.
SASSX2U2 Optional PARMLIB Processing

SASSX2U2 processes the Optional PARMLIB statements in the sequence in which they were entered.
So, for duplicate entries, the last one is what is used for conversion. Consider the following Optional
PARMLIB example.
SUBUSER=User1
SUBPASS=Pass1
PARM2=F=2048
SUBUSER=User2
SUBPASS=Pass2
PARM2=T=10
In this situation, the new AGJOB definition would use User2/Pass2 as the agent user ID/password.
The ARGS statement would have T=10.
Process the Conversion BTI File

In this procedure, the Batch Terminal Interface (BTI) procedure is executed.
Execute the CONVERT Command Online (see page 396)

Restore a Converted Member (see page 396)
08-Feb-2018 395/722
Restore a Converted Member (see page 396)
This job uses the X2U2CONV file (created earlier) as input. JCL to execute this procedure is shown in
the following:
//JS010 EXEC CA7BTI
//SYSIN DD DSN=highlvl.cai.X2U2CONV,DISP=SHR
//
If the member name specified on the CONVERT command does not exist or is not an XPJOB
definition, the command fails. If the BACKUP= parameter is specified on the CONVERT command, and
the backup member exists, the command fails. Standard error processing is followed for all other
commands (such as AGJOB, JCL, SAVE, CLEAR) that can be found in the file.
When the BTI job completes, thoroughly inspect the output report, and resolve any errors that were
reported.
Be sure to use the BTI (CA7BTI) procedure during the conversion process. CA7BTI can handle PARM xx
keyword/value pairs up to 80 characters in length. The CAICCI batch interface truncates PARM xx
keyword/value pairs greater than 71 characters and causes your conversion to fail.
Execute the CONVERT Command Online

Although you can enter the CONVERT command within CA Workload Automation CA 7® Edition from
any panel, we do not recommend it. The command creates an AGJOB shell definition that cannot be
executed. If you execute the CONVERT command online, update the job definition, providing the
AGJOB information described in DB.11 Agent Job Definition Panel (https://wiki.ca.com/display/CWAC7E
/DB.11+-+Agent+Job+Definition+Panel).
Restore a Converted Member

You can restore a converted member or members using the commands found in the X2U2REST DD
data set and the BTI JCL stream, as shown in the following:
//JS010 EXEC CA7BTI
//SYSIN DD DSN=highlvl.batch.restcmds,DISP=SHR
//
Because RESTORE is a single-line command, you can easily cut and paste only those members you
want to restore to another data set. You can use that as your BTI input. Or, you can log on to your CA
Workload Automation CA 7® Edition environment and execute it as an online command. The
following is a sample:
Command: RESTORE,XPJOB01,BACKUP=XPJOB01$
Output:
--- FUNCTION: RESTORE

SM27-01 L JOB=XPJOB01 RESTORE SUCCESSFULLY COMPLETED
Remember, this process simply restores the XPJOB definition. Copy the Optional PARMLIB (if present)
from the AL2AGJC1 IEBCOPY backup to the appropriate CA Workload Automation CA 7® Edition JCL
library.
08-Feb-2018 396/722
Generate Agent User-ID/Password Records

As stated previously, any XPJOB for conversion requires an associated user ID and Password. These
IDs and passwords can be related using a Node or Owner Access record created using the XPSWD
command or by having the SUBUSER/SUBPASS keyword value pairs specified in the Optional
PARMLIB. Without this relationship, commands to convert the job are not created.
Step IV Input DD Statements (see page 397)

Step IV Output DD Statements (see page 398)
SASSX2U9 Return Codes (see page 398)
Assume that the Agent that is replacing the Node requires the same User-ID/Password combination
to run the job. The output file X2U2ASEC, created during the SASSX2U2 program execution, carries
those relationships forward. This process uses a program-to-program CAICCI Terminal Interface as
opposed to a Batch Terminal Interface.
The X2U2ASEC file is input to job AL2AGJC3. The sample JCL is member AL2AGJC3 in CAL2JCL.
If you have restricted access to the X2U2ASEC data set, do the same for the SORTOUT/X2U9ASEC
data set.
This job does the following:
Sorts the input file.
Eliminates duplicate records from processing.
Generates AGPSWD records based on SUBUSER/SUBPASS information.
Generates AGPSWD records based on information extracted from the database for Owner Access
or Node Access records (records created using the XPSWD command).
Step IV Input DD Statements

SASSX2U9 DBPARM DD Statement

SASSX2U9 SORTIN Statement

(Required) The SORTIN DD statement points to the X2U2ASEC file created by job AL2AGJC2. This
data set contains the information necessary to build the Agent User-ID/Password records
required to run the converted job at the Agent.
SASSX2U9 SYSIN Statement

(Optional) The SYSIN data set contains processing keywords that SASSX2U9 can use. Statements
must begin in column 1.
LOGON
Identifies the User-ID to use when logging on to the system. You can also include a password.
LOGON=MASTER
LOGON=BWY2Z7,upswd
08-Feb-2018 397/722
NODE
Specifies the CAICCI node name where the CA Workload Automation CA 7® Edition address space
is executing. The default is to attempt to communicate with a CA Workload Automation executing
at the same CAICCI node where the batch job is executing (local node).
Note: You can use the reserved value *AUTO* to indicate that the CA Workload
Automation CA 7® Edition CAICCI interface can attempt to locate dynamically the CAICCI
node where a CA Workload Automation CA 7® Edition with a matching instance name
resides.
CA7
Specifies the instance name of the CA Workload Automation CA 7® Edition with which you want
to communicate. This name must match what is specified for either CA7 or RNAME in the
instance’s initialization file (see the SVCNO Statement in the initialization file).
Step IV Output DD Statements

The following are the output data sets:
SASSX2U9 CA7PRINT Statement

(Required) This file contains output returned by CAICCI for CA Workload Automation CA 7®
Edition commands. Passwords are masked out. The results of a /DISPLAY,ST=CA7 are also
captured so the CA Workload Automation CA 7® Edition instance that was updated is
documented.
SASSX2U9 X2U9REPT Statement

(Required) This file contains the Security Updates Status Report (see the following sample)
showing the records that were added and any errors that occurred.
SASSX2U9-01 CA WORKLOAD AUTOMATION XPJOB-
AGJOB CONVERSION REPORT
DATE: 07/05
/yy Security Update Requests
USERID AGENT NAME UPDATE STATUS

cmsg02 MACAGENT Password already exist
s
cmsg20 MACAGENT Password already exist
s
fulllengthdoman\oco0002 EROCTESTAGNODE Password added succe
ssfully
TANT\USER001 USERO01ESP Password already exi
sts
Total number of successful updates: 1

Total number of failed updates: 3
SASSX2U9 Return Codes

The conversion utility program (SASSX2U9) returns one of the following four return codes:
RC=0
Indicates that the job ran successfully, all updates were successful.
08-Feb-2018 398/722
RC=4
Indicates the input file SORTIN, which was built from the X2U2ASEC file generated by the
AL2AGJC2 job, is empty.
RC=8
Indicates at least one security update request failed. Review the X2U9REPT file for details.
RC=12
Indicates that the job failed, and the program is terminating early. Review the JES2 Job Log for a
WTO indicating the cause of the problem.
Clean Up XPJOB
Job AL2AGJC2 processing created two clean-up files, X2U2XPSW and X2U2XNOD. These files can
serve as input to the BTI procedure to clean up XPSWD and XNODE entries that are no longer needed.
Do not process either of these files until you are certain of the following:
All converted jobs run successfully.
Any other jobs that were not part of the conversion or did not convert successfully do not need
the XPSWD records.
Any other jobs that were not part of the conversion or did not convert successfully do not need
the XNODE records.
Important! If you did not specify a NODE= on your LJOB command in the first job
(AL2AGJC1) of the conversion process, be cautious about executing the clean-up step.
If you do execute the clean-up process, run the X2U2XPSW file through the BTI procedure first. This
method is suggested because when you delete Node records, any associated Node Access records are
automatically deleted. So, if you run using X2U2XNOD file first, and then run using X2U2XPSW file,
you probably have errors in the BTI job processing the X2U2XPSW file.
JCL to execute the BTI procedure is similar to what you have already seen and is shown in the
following:
To delete XPSWD Records

//JS010 EXEC CA7BTI
//SYSIN DD DSN=highlvl.cai.X2U2XPSW,DISP=SHR
//
To delete XNODE Records

//JS010 EXEC CA7BTI
//SYSIN DD DSN=highlvl.cai.X2U2XNODE,DISP=SHR
//
08-Feb-2018 399/722
XPJOB Conversion Messages (AL2AGJC1 Job)

All messages from AL2AGJC1 are write-to-operator (WTO) messages that appear in the AL2AGJC1 JES
Job Log. If you receive any of the following messages, fix the problem, and rerun the job before
continuing to the AL2AGJC2 job. A user abend of the same reason code value accompanies these
WTOs.
X2U1-12 CANNOT OPEN DDN=X2U1IN
Reason:
An error occurred trying to open the X2U1IN data set.
Action:
Examine the DD statement for correct values including the spelling of ddname X2U1IN.
X2U1-16 CANNOT OPEN DDN=X2U1OUT
Reason:
An error occurred trying to open the X2U1OUT data set.
Action:
Examine the DD statement for correct values including the spelling of ddname X2U1OUT.
X2U1-24 BAD LJOB GROUP END, NOT SLIA-00
Reason:
The SLIA-nn message terminating the output produced for an LJOB command indicates that an error
occurred. That is, the nn value is not zero.
Action:
Correct the cause of the nonzero completion message in the BTI step and rerun.
X2U1-32 END OF FILE REACHED BUT /LOGON EXPECTED
Reason:
No /LOGON command could be found in the input data set. Either the previous BTI set completed
abnormally or the wrong data set was used as input to SASSX2U1.
Action:
Correct the input and resubmit.
X2U1-40 END OF FILE REACHED BUT SLIA-00 EXPECTED FOR LJOB GROUP
Reason:
The program reached end-of-file during processing of LJOB command output without finding the SLIA-
08-Feb-2018 400/722
The program reached end-of-file during processing of LJOB command output without finding the SLIA-
nn message indicating routine completion of the command. The output data set being produced is
incomplete. Probably caused by exceeding the capacity of the Batchout data set during the previous
BTI step.
Action:
Increase the allocation for the Batchout data set and rerun the job.
X2U1-44 NUMBER OF JOBS HAS EXCEEDED TABLE CAPACITY
Reason:
The number of unique job names requested exceeds the capacity of the internal job name table.
Action:
Divide the LJOB commands into multiple job runs.

Messages from the AL2AGJC2 job can be write-to-operator (WTO), informational, warning, or error
messages.
WTO messages are written to the AL2AGJC2 JES Job Log and cause the job to terminate. Resolve the
cause of the WTO message and rerun the job after deleting any output data sets created during the
job run.
The informational, warning, and error messages are applicable to a single XPJOB and do not
terminate the AL2AGJC2 job. Error messages prevent that job from converting.
XPJOB Conversion WTO Messages (see page 401)

XPJOB Conversion Informational Messages (see page 406)
XPJOB Conversion Warning Messages (see page 407)
XPJOB Conversion Error Messages (see page 408)
XPJOB Conversion WTO Messages

The XPJOB conversion process can generate the following WTOs.
X2U2-01 xxxxxxxx MODULE NOT FOUND
Reason:
A module (xxxxxxxx) needed by the XPJOB Conversion Utility could not be found.
Action:
Contact your site's system programmer to determine why the module is missing.
X2U2-02 UNABLE TO OPEN xxxxxxxx DD FILE
08-Feb-2018 401/722
Reason:
An error occurred attempting to open the DD file (xxxxxxxx).
Action:
Verify the spelling of the ddnames in the AL2AGJC2 JCL and correct any misspelled or missing DDs.
X2U2-03 UNKNOWN KEYWORD IN SASSX2U2 SYSIN FILE
Reason:
The SYSIN file used by SASSX2U2 can have three keywords, RESTMASK, INTERACT, and DEFPRLIB. All
keywords must begin in column 1.
Action:
Verify the spelling of each keyword.
X2U2-04 INVALID OFFSET POSITION IN RESTORE MASK, MUST BE 1-8
Reason:
The RESTMASK offset position must be a number from 1 to 8.
Action:
Correct the input and resubmit the request.
X2U2-05 INVALID SUBSTITUTION CHARACTER IN RESTORE MASK, ALPHANUMERIC OR NATIONAL

REQUIRED
Reason:
The substitution character specified in the RESTMASK was not valid. The character must be a letter,
number, or national character.
Action:
X2U2-06 IF OFFSET POSITION = 1, RESTORE MASK MUST BE AN ALPHA OR NATIONAL CHARACTER
Reason:
The substitution character is being used as the first character of the job name. As such, it must be a
letter or national character (it cannot be numeric).
Action:
X2U2-07 INVALID DATA SET NAME ON SYSIN DD DEFPRLIB STATEMENT
08-Feb-2018 402/722
Reason:
The data set name specified on the DEFPRLIB statement exceeded 44 characters.
Action:
X2U2-08 /DISPLAY,ST=XPS OUTPUT PROBLEM, CHECK PSWDLOC IN THIS OUTPUT FOR VALIDITY
Reason:
The PSWDLOC hierarchy values are DATABASE, OWNER, NODE, and USER in any order. In addition,
not all are required. An invalid value is in the hierarchy.
Action:
Have your installation specialist correct this problem.
X2U2-09 SASSTMNT ERROR ALLOCATING STORAGE FOR /DISPLAY,ST=JCLVAR OUTPUT
Reason:
The number of data sets in the /DISPLAY,ST=JCLVAR output exceeds what the SASSTMNT program
has allocated.
Action:
Contact CA Support at http://ca.com/support for assistance.
X2U2-10 LJOB JOBNAMES NOT MATCHED, DATA APPEARS TO BE CORRUPTED. RE-CHECK ALL DATA.
Reason:
The data set specified in the X2U2BTII DD statement has been edited incorrectly. The statement in
error follows the WTO.
Action:
Recreate the data set, and process without editing.
X2U2-11 LJOB MAINID COLUMN VALUE NOT XPJ, ONLY XPJOB DATA SHOULD BE EXTRACTED
Reason:
Action:
Recreate the data set and process without editing.
08-Feb-2018 403/722
X2U2-12 LJOB PRMLIB= OUTPUT NOT FOUND, DATA APPEARS TO BE CORRUPTED. RE-CHECK ALL
DATA.
Reason:
Action:
Recreate the data set and process without editing.
X2U2-13 INVALID PARM DATA STARTING
Reason:
A parameter error occurred. The parameter field is displayed following the WTO.
Action:
Correct the error and resubmit the job.
X2U3-02 UNABLE TO OPEN X2U2NODE DD FILE
Reason:
An error occurred trying to open the X2U2NODE data set.
Action:
Examine the DD statement for correct values including the spelling of ddname X2U2NODE.
X2U3-03 STORAGE OBTAIN FOR NODE-AGENT TABLE FAILED
Reason:
An error occurred while attempting to get storage for the Node-Agent table.
Action:
Increase the region size allocated in the job and try again. If the problem persists, contact CA Support
at http://ca.com/support for assistance.
X2U3-04 SYNTAX ERROR IN DATA FOR DD X2U2NODE
Reason:
The X2U2NODE file had a syntax error. The card-in-error follows the WTO.
Action:
Correct the error and resubmit the job after deleting any allocated output data sets.
08-Feb-2018 404/722
X2U3-05 INVALID JOB TYPE IN DATA FOR DD X2U2NODE
Reason:
The X2U2NODE file job type was not NT_JOB or UNIX_JOB. The card-in-error follows the WTO.
Action:
Perform the following actions:
Delete any allocated output data sets.
Correct the error and resubmit the job.
X2U3-07 DSN NOT DEFINED TO CA WORKLOAD AUTOMATION: xxxxx…xxxx
Reason:
The data set specified (xxxxx…xxxx) is not in the /DISPLAY,ST=JCLVAR output. Only data sets defined
to CA Workload Automation CA 7® Edition are permitted in the X2U2NODE file or as the value in the
DEFPRLIB statement.
Action:
X2U3-08 CA7RSRC VSAM qqqq ERROR RC=rr FDBK=cccc
Reason:
A VSAM request, either OPEN or GET (qqqq), has failed on CA7RSRC. The return code was rr, and the
feedback code was cccc.
Note: For more information about the return and feedback codes, see the IBM VSAM
Programmers documentation.
Action:
X2U4-01 STORAGE OBTAIN FOR CLEANUP TABLE FAILED
Reason:
An attempt to obtain storage for an internal table created during SASSX2U2 execution failed.
Action:
Delete the output data sets created during this job run.
08-Feb-2018 405/722
Increase your REGION size.
Rerun the job.
If the problem persists, contact CA Support at ca.com/support for assistance.
**WARNING** RESTMASK NOT PROVIDED. NO RESTORE/BACKOUT CAPABILITY REQUESTED
Reason:
This is the only WTO that does not terminate processing. This WTO is a reminder that you have
chosen not to maintain a backout copy of your XPJOB.
Action:
If you want to maintain a backout copy of your original XPJOB do the following:
Delete the output data sets allocated by AL2AGJC2.
Add a RESTMASK= statement to the SYSIN DD statement used by program SASSX2U2 (the second
step in AL2AGJC2).
Rerun AL2AGJC2.
Note: Until you use the X2U2CONV file created in AL2AGJC2 as input a job running the
Batch Terminal Interface procedure, you have not converted any jobs. Until that time, you
can run AL2AJC2 for a given LJOB selection set as many times as necessary.
XPJOB Conversion Informational Messages

The conversion process generates the following informational messages.
JOBNAME xxxxxxxx CONVERT COMMANDS SUCCESSFULLY CREATED
Reason:
This message indicates job xxxxxxxx was successfully processed and that the CONVERT BTI commands
for this job have been placed in the X2U2CONV DD data set.
Action:
None.
JOBNAME xxxxxxxx RESTORE COMMANDS SUCCESSFULLY CREATED
Reason:
08-Feb-2018 406/722
This message indicates job xxxxxxxx was successfully processed and that the RESTORE BTI commands
for this job have been placed in the X2U2REST DD data set. You only see this message if you have
specified a RESTMASK parameter.
Action:
None.
JOBNAME xxxxxxxx SELECTED FOR PROCESSING
Reason:
This message indicates job xxxxxxxx was selected for conversion processing.
Action:
None.
XPJOB Conversion Warning Messages

The XPJOB conversion process can issue the following warning messages.
*** WARNING *** - JOBNAME xxxxxxxx USES SCC CARDS, THESE WILL NOT BE RESOLVED WHEN
CONVERTED.
Reason:
With XPJOBs, you can code #SCC cards to handle condition code logic. Because AGJOBs do not have
this feature, it is dropped during conversion.
Note: Once conversion is complete, edit the AGJOB PARMLIB member and add EXITCODE
logic. The EXITCODE parameter is described in EXITCODE Statement (https://wiki.ca.com
/display/CWAC7E/EXITCODE+Statement+--+Identify+Success+or+Failure+by+Exit+Code).
Action:
None.
*** WARNING *** - JOBNAME xxxxxxxx WILL NOT RETAIN PARMLIB INFO IN PRIOR RUN QUEUE
WHEN CONVERTED
Reason:
With XPJOBs, you can retain Optional PARMLIB information in the prior run queue by setting RETAIN
to Y on the DB.10 screen. Because AGJOBs do not have this feature, it is dropped during conversion.
Action:
None.
08-Feb-2018 407/722
*** WARNING *** - JOBNAME xxxxxxxx WILL NOT RETAIN SUTYPE VALUE OF N WHEN CONVERTED
Reason:
XPJOBs have an SUTYPE field on the DB.10 screen. When set to N you bypass execution of the ".
PROFILE" for the target user. Because AGJOBs do not have this feature, it is dropped during
conversion.
Action:
None.
*** WARNING *** - JOBNAME xxxxxxxx WILL NOT RETAIN TRACE VALUE WHEN CONVERTED,
INVALID FOR AGJOBS
Reason:
With XPJOBs, you can issue WTOs to trace a job as it goes through the submission process by setting
the Trace parameter on the DB.10 screen to Y. This option is not available with AGJOBs.
Action:
None.
XPJOB Conversion Error Messages

The XPJOB conversion process can generate the following error messages.
*** ERROR *** - JOBNAME xxxxxxxx CC/RO VALUES CANNOT BE CONVERTED TO EXITCODE. JOB
NOT CONVERTED.
Reason:
For LT/GT relational operators, we must add or subtract 1 from the condition code value to generate
the correct EXITCODE statement. If the condition code is 9999 for the LT condition or 0 for the GT
condition, we do not generate an EXITCODE statement. The statement would exceed the bounds
used by the XPJOB.
Action:
Convert this job manually.
*** ERROR *** - JOBNAME xxxxxxxx CONDITION CODE NOT NUMERIC. JOB NOT CONVERTED.
Reason:
The XPJOB has a condition code that is not numeric.
Action:
Fix the error.
08-Feb-2018 408/722
Fix the error.
*** ERROR *** - JOBNAME xxxxxxxx DID NOT MATCH MEMBER NAME AND WAS BYPASSED
Reason:
Conversion requires a one-to-one match between the job name and the Optional PARMLIB member
name (if specified). If the names do not match, the member is not converted.
Action:
*** ERROR *** - JOBNAME xxxxxxxx EXEC EXCEEDS 98 CHARACTERS. JOB NOT CONVERTED.
Reason:
XPJOB XP EXEC statements can be up to 244 characters. The equivalent Agent CMDNAME can only be
100 characters. Because we must wrap double quotes around it, we can only convert XP EXEC
statements that are 98 characters or less.
Action:
*** ERROR *** - JOBNAME xxxxxxxx EXEC HAS SLASH (/). NOT VALID WITH NT_JOB. JOB NOT
CONVERTED.
Reason:
The job to be converted supposedly ran in a Windows operating environment. However, slashes in
the XP EXEC statement indicate that it is a UNIX job.
Action:
*** ERROR *** - JOBNAME xxxxxxxx EXEC HAS SLASH ( ). NOT VALID WITH UNIX_JOB. JOB NOT
CONVERTED.
Reason:
The job to be converted supposedly ran in a UNIX operating environment. However, slashes in the XP
EXEC statement indicate it is a Windows job.
Action:
*** ERROR *** - JOBNAME xxxxxxxx HAS INVALID PARMnn CARD. JOB NOT CONVERTED.
Reason:
08-Feb-2018 409/722
Reason:
The PARMnn statements have an error.
Action:
Fix the error.
*** ERROR *** - JOBNAME xxxxxxxx HAS NO CORRESPONDING PARMLIB. JOB NOT CONVERTED.
Reason:
The job being converted did not have an Optional PARMLIB, nor was one supplied in the X2U2NODE
file NODE-AGENT association for this job or in the DEFPRLIB parameter.
Action:
Make the appropriate updates to the X2U2NODE file or DEFPRLIB.
If you select the latter, rerun AL2AGJC1 after updating the LJOB selection criteria to eliminate jobs
you have already converted.
*** ERROR *** - JOBNAME xxxxxxxx HAS UNKNOWN LINELEN VALUE. JOB NOT CONVERTED.
Reason:
Valid XPJOB LINELEN values are AUTO, 80, and 72. This job cannot run as an XPJOB either.
Action:
Correct the error.
*** ERROR *** - JOBNAME xxxxxxxx JCL LIBRARY INDEX NOT FOUND. JOB NOT CONVERTED.
Reason:
This job specified a JCL Library index that did not match the indexes in the /DISPLAY,ST=JCLVAR
output.
Action:
08-Feb-2018 410/722
*** ERROR *** - JOBNAME xxxxxxxx LJCL HAS DPROC= CARD. JOB NOT CONVERTED.
Reason:
This job has a DPROC card that must be interpreted during job submission. The XPJOB Conversion
Utility cannot decipher this card. Agent jobs cannot use CA Driver procedures.
Action:
*** ERROR *** - JOBNAME xxxxxxxx LJCL HAS TOO MANY PARMLIB CARDS, JOB NOT CONVERTED.
Reason:
Agent UNIX and Windows jobs cannot have as much input data as XPJOBs. This error occurs if you
have more than 150 statements in your Optional PARMLIB member.
Action:
*** ERROR *** - JOBNAME xxxxxxxx LJCL DSN= VALUE LONGER THAN 44 CHARACTERS. JOB NOT
CONVERTED.
Reason:
The X2U2BTII file entry for this job is corrupted.
Action:
*** ERROR *** - JOBNAME xxxxxxxx LJCL HAS JI OR XI CARDS. JOB NOT CONVERTED.
Reason:
This job has #JI or #XI statements that must be interpreted during job submission. The XPJOB
Conversion Utility cannot decipher these statements.
Action:
*** ERROR *** - JOBNAME xxxxxxxx LJCL JOB= VALUE DOES NOT MATCH LJOB JOBNAME. JOB NOT
CONVERTED.
Reason:
The X2U2BTII file entry for this job is corrupted.
Action:
08-Feb-2018 411/722
Action:
*** ERROR *** - JOBNAME xxxxxxxx NO USER-ID AND/OR PASSWORD FOR JOB. JOB NOT
CONVERTED.
Reason:
XPJOBs do not require a user ID or Password to execute, and AGJOBs do. This job did not have an
associated user ID and/or password either using the Owner field, Node field, or SUBUSER/SUBPASS
parameters.
Action:
*** ERROR *** - JOBNAME xxxxxxxx NODE NOT IN NODE-AGENT TABLE. JOB NOT CONVERTED.
Reason:
All XPJOBs have an XP NODE entry (defined on the DB.10 screen). For each job/node being converted,
there must be a NODE-AGENT entry in the X2U2NODE file. Without this entry, the program does not
know where to send the AGJOB when requested for submission.
Action:
Rerun AL2AGJC1 after updating the LJOB selection criteria to eliminate jobs you have already
converted.
Add the NODE-AGENT association to the X2U2NODE file.
Rerun the AL2AGJC2 job.
*** ERROR *** - JOBNAME xxxxxxxx PARMnn LENGTH EXCEEDS 4078. JOB NOT CONVERTED.
Reason:
XPJOBs can have 64 PARMnn cards of 256 bytes each, for a total of 16,384 bytes. PARM nn cards are
converted to an ARGS statement which cannot exceed 4078 bytes.
Action:
Determine how to break down the PARMnn statements.
*** ERROR *** - JOBNAME xxxxxxxx RELATIONAL OPERATOR INVALID. JOB NOT CONVERTED.
Reason:
08-Feb-2018 412/722
Reason:
This job has an RO (see DB.10 screen) value that is invalid.
Action:
Fix the error.
*** ERROR *** - JOBNAME xxxxxxxx XP PARM VALUE NOT VALID. JOB NOT CONVERTED.
Reason:
The XPPARM field for this job is corrupted.
Action:
Convert the job manually.

All messages from AL2AGJC3 are write-to-operator (WTO) messages that appear in the AL2AGJC3 JES
Job Log. If you receive any of the following messages (except for the X2U9-08 WTO), fix the problem
and rerun the job.
X2U9-01 UNABLE TO OPEN xxxxxxxx DD FILE
Reason:
An error occurred trying to open the data set (xxxxxxxx).
Action:
Examine the DD statement for correct values including the spelling of the ddname.
Fix the problem.
Rerun the job.
X2U9-02 INVALID SYSIN CARD FOLLOWS
Reason:
Valid SYSIN cards for AL2AGJC3 are LOGON, NODE, and CA7. The invalid card follows this WTO.
Action:
08-Feb-2018 413/722
Resolve the error.
Resubmit the job.
X2U9-03 STORAGE OBTAIN FOR COMMAND TABLE FAILED
Reason:
An attempt to obtain storage for an internal table that is created during SASSX2U9 execution failed.
Action:
Rerun the job after increasing your REGION size.
If the problem persists, contact CA Support at ca.com/support for assistance.
X2U9-04 CA7RSRC VSAM qqqq ERROR RC=rr FDBK=cccc
Reason:
A VSAM request, either OPEN or GET (qqqq), has failed on CA7RSRC. The return code was rr, and the
feedback code was cccc.
Note: For more information about the return and feedback codes, see the IBM VSAM
Programmers documentation.
Action:
Resolve the problem.
Rerun the job.
X2U9-05 CCI RETURNED ERROR R15=rr R0=cccc
Reason:
The CA Workload Automation CA 7® Edition CAICCI interface module (CAL2X2W0) returned an error
code. The return code was rr, and the reason code was cccc.
Action:
See any messages in the JES log indicating the nature of the error encountered.
08-Feb-2018 414/722
Contact CA Support at ca.com/support for assistance.
X2U9-06 EMPTY X2U9ASEC INPUT FILE
Reason:
No input data was found in X2U9ASEC. The most likely scenario is that there were no jobs to convert.
As a result, because the X2U2ASEC file is empty, the X2U9ASEC file is also empty.
Action:
Examine the AL2AGJC2 job output to determine whether the X2U2ASEC file is also empty.
X2U9-07 AT LEAST ONE SECURITY UPDATE FAILED, CHECK REPORT
Reason:
An attempt to add one or more user ID/Password records through the AGPSWD command was
unsuccessful.
Action:
See the X2U9REPT file for more information.
X2U9-99 TERMINATING BECAUSE OF PRIOR ERROR
Reason:
Job AL2AGJC3 terminates due to a previous error.
Action:
Review the JES2 job log for more WTOs describing the cause of the failure.
Resolve the problem.
Resubmit the job.
08-Feb-2018 415/722
Programming
Documentation in this area provides systems programming information, including system operations,
setting up the system environment, the initialization file, calendars, backup and recovery, and
disaster recovery mode. This area also describes log and history data set management, workload
balancing, UNIX, MSMR, and XCF, utilities, user exits and modifications, and performance and tuning.
This information was previously included as the Systems Programming Guide (or SPG).
Use the navigation panel to the left to access these programming articles.
System Operations
The system operations articles discuss various topics including system structure, database contents,
JCL and parameter libraries, work queues, and more. Use the left navigation pane to view these
articles.
System Structure
A good understanding of the overall system structure of CA Workload Automation CA 7® Edition is a
prerequisite for data center personnel. CA Workload Automation CA 7® Edition includes the following
items:
CA7ONL (Central Control System)
ICOM (Independent Communications Manager)
SVC and SMF exits
NCF (Network Communications Facility)
CA Workload Automation CA 7® Edition database
Terminal communications
CA 7 Web Client (user interface)
CA 7 JFM (Job Flow Monitor)
The following figure illustrates the CA Workload Automation CA 7® Edition environment.
08-Feb-2018 416/722
Note: The submit data sets shown in the figure are optional. They are primarily used in a
JES nonshared spool environment.
Central Control System

The Central Control System (Module UCC7) is the supervisor of the entire CA Workload Automation
CA 7® Edition system. All CA Workload Automation CA 7® Edition facilities accessible to the user are
under the control of the Central Control System. The Central Control System also controls execution
of time-driven functions, event-driven functions, or both. The Central Control System controls all
communications to and from terminals and between other CA Workload Automation CA 7® Edition
components.
The Central Control System can be executed as a started task or a batch job. When executed as a
batch job, the Central Control System requires an initiator. The amount of virtual storage must be
increased as the system grows. In multiple computer configurations, the Central Control System
executes on only one computer. An ICOM is on each computer to which the Central Control System is
submitting jobs.
Contents
08-Feb-2018 417/722
The Central Control System functions are as follows:
Terminal network control handles the interface with VTAM to communicate with operators. This
communication lets the various applications to operate independent of the type of teleprocessing
network in use.
The log management function controls writing of log records. Also, it monitors the usage of the
log files. When a log file is full, log management swaps the files and schedules a job to dump the
full data set. These log dump jobs are monitored to verify that success before the next swap
occurs.
Database access is handled so that applications can provide the services that are requested.
Subtask control provides an interface with the operating system for certain types of service. This
approach lets the Central Control System operate with a minimal system overhead while
supporting application requirements.
SMF feedback is processed for work that the Central Control System tracks. This data causes
updating of status information in the queues and the database. By keeping status information
current, the Central Control System can dynamically monitor the workload and react to changing
requirements and conditions.
The schedule scan is responsible for scheduling and controlling all CA Workload Automation CA
7® Edition jobs and networks. The schedule scan is activated automatically on a user-defined time
interval or dynamically by internal events. Schedule scan functions include the following items:
Selecting work to process.
Placing it in the queues.
Performing an initial scan of requirements for newly scheduled work.
Prompting and reprompting for work that is late.
Submit provides the job submission interface between the ready queue and the host job entry
subsystem, submit data set, or cross-platform communication. Submission is automatically
activated when all requirements are satisfied for a job in the request queue.
External Terminal Manager (XTM) handles access control for the CAICCI and TCP/IP batch
interfaces. XTM permits communications to and from CA Workload Automation CA 7® Edition to
other interfaces through those network protocols.
Communication with CA Integrated Agent Services (CA IAS) is managed when the agent jobs
feature is active. When the jobs destined to CA Workload Automation Agents are submitted, the
message traffic generally passes through this interface.
Application Programs
CA Workload Automation CA 7® Edition application programs provide the functions and activities
required for effective use of automated production control. Prompting, schedule resolution,
forecasting, and so forth, are provided. Each application provides multilevel capabilities for the
activity it supports. The database maintenance application is an example. Database management lets
you update elements within a database entry, delete the entire entry, or add a new entry.
08-Feb-2018 418/722
Application modules are stored on the CA Workload Automation CA 7® Edition load library. Some CA
Workload Automation CA 7® Edition applications provide user exits. User exits let you tailor CA
Workload Automation CA 7® Edition to meet the requirements of your installation.
Base Calendars
The base calendars built by an installation define the structure and processing year. These base
calendars determine when the scheduled processing can occur. The calendar criteria include:
Processing days available for the scheduling of work
Holidays
Beginning and ending days of each month (if not standard Gregorian)
The CALENDAR macro generates base calendars in batch mode. The user supplies macro parameters
to define each calendar. A standard assemble and link-edit procedure is then used to build the
calendar and store it in a library. Many different base calendars can be defined.
The CALMOD function (DB.2.8) can define, modify, and delete base calendars in an online mode.
The perpetual calendars let you specify criteria to use to automate the creation of a base calendar.
When the criteria are specified, the associated calendar is automatically generated the first time that
a non-existing calendar is referenced.
More information:
Calendars (https://wiki.ca.com/display/CWAC7E/Calendars)
ICOM Functions
The Independent Communications Manager (ICOM) has direct contact with activity in the host
system. ICOM monitors the processing of computer job activity through data that the System
Management Facility (SMF) produced. ICOM monitors the SMF record types-15, and -30 (and
optionally -14 and -64) created for jobs defined to, and submitted by, CA Workload Automation CA 7®
Edition. ICOM also monitors type-26 records that are created for all jobs.
ICOM has the following principal functions:
Communicate SMF and trailer information to CA Workload Automation CA 7® Edition.
Submit jobs to the host system internal reader (optional).
ICOM is executed as either a started task or batch job. ICOM must be active whenever CA Workload
Automation CA 7® Edition is executed in production mode to perform automatic job submission,
monitoring, and control.
In multiple computer configurations, ICOM must be active on each computer executing jobs that CA
Workload Automation CA 7® Edition is to control. Also, in multiple computer configurations, the CA
Workload Automation CA 7® Edition communications data set must be accessible to each computer
on which ICOM executes. The communications data set is a transfer point between CA Workload
08-Feb-2018 419/722
on which ICOM executes. The communications data set is a transfer point between CA Workload
Automation CA 7® Edition and ICOM for SMF data, trailer data, and control information. When the
cross-system coupling facility (XCF) is used to communicate between ICOM and CA Workload
Automation CA 7® Edition, SMF data is sent through that link. SMF data is not sent through the
COMMDS.
ICOM continues to record activity that is associated with the CA Workload Automation CA 7® Edition
controlled work even if CA Workload Automation CA 7® Edition is not active. This recording lets CA
Workload Automation CA 7® Edition resume processing of data to when it is reactivated.
SVC and SMF Exits

The CA Workload Automation CA 7® Edition SVC passes SMF information to ICOM collected by the CA
Workload Automation CA 7® Edition SMF interface processors, providing job and data set monitoring.
ICOM and each of the SMF interface processors can issue the SVC.
The CA Workload Automation CA 7® Edition SMF exits monitor SMF record types-15, -26, and -30
(and optionally -14 and -64). These records must be generated to track properly the status of jobs
and data set usage. Because the CA Workload Automation CA 7® Edition exits extract only the data
that CA Workload Automation CA 7® Edition requires, writing these records to the SMF data sets is
not necessary.
Network Communications Facility (NCF)

The Network Communications Facility (NCF) lets users process NJE work and have the work appear to
CA Workload Automation CA 7® Edition as if it were done locally. All the functions that CA Workload
Automation CA 7® Edition performs for jobs that are executed at remote nodes are the same
functions that CA Workload Automation CA 7® Edition performs for jobs that are executed locally.
NJE can route jobs that CA Workload Automation CA 7® Edition schedules to a remote node, and CA
Workload Automation CA 7® Edition using NCF can still track the jobs. The SMF feedback for the jobs
that are executed at a remote node returns to the originating node through the NCF/VTAM link. The
feedback includes the usual event postings, dependencies, log records, and so forth, associated with
a locally run job. Inside CA Workload Automation CA 7® Edition, various reports and panels show
when and which jobs ran remotely.
You can use the DB.7 panel to make the JCL changes required to cause a remote job to run correctly
in the NCF environment.
More information:
NCF (see page 173)
Internal Cross-Platform Jobs

CA Workload Automation CA 7® Edition lets you define and submit jobs that are destined for
execution on another operating environment. The two types of internal cross-platform jobs are:
08-Feb-2018 420/722
The first type, XPJOBs, is defined in the CA Workload Automation CA 7® Edition database using
the XPJOB command when the XSUBMIT keyword of the XPDEF statement in the initialization file
permits.
These types of jobs are routed to a Unicenter agent, such as CA Universal Job Management Agent
(UJMA).
The second type, agent jobs (AGJOB), supports many platforms and applications (for example,
LINUX, i5/OS, SAP, and Oracle).
These types of jobs are routed to the CA Workload Automation Agent and its associated plug-ins
when the AGENTJOB keyword of the XPDEF statement in the initialization file permits.
Jobflow Monitor (JFM)

Jobflow Monitor (see page 288) (JFM) is an optional CA Workload Automation CA 7® Edition
component that provides workload information that is required by CA workload monitoring solutions
such as:
CA Critical Path Monitor (CPM)
CA 7® Web Client (if using Monitor Perspective flow views)
CA 7 Server for iDash

CA 7 Server for iDash (see page 319) is an optional CA Workload Automation CA 7® Edition
component providing workload information that CA Workload Automation iDash requires.
Workload Definitions and Active Workload

The CA Workload Automation CA 7® Edition database maintains two types of information:
Workload definitions for scheduling and controlling work
Active workload for tracking the execution of this work
The database is structured using the CA Datacom/AD database.
Workload Definitions
The following list describes the workload definitions:
Job definitions
Includes job structure, activity relationships, execution characteristics, and data set relationships.
Jobs are defined and maintained to the database through the database maintenance application.
This information includes scheduling criteria for jobs.
Data set definitions

Includes data set definitions, their attributes and using-jobs known to CA Workload Automation
CA 7® Edition.
08-Feb-2018 421/722
Network members
Defines workstation groupings for related activities, and the scheduling criteria for input/output
workstations.
User documentation (prose)

Indicates the free-form documentation that is associated with the defined elements.
Virtual Resource Management (VRM)

Defines information about jobs and the associated resource connections. These virtual resources
include exclusive, shared, address space, corequisite, and resource count resources.
Automation Recovery Facility (ARF)

Provides information for the evaluation of an exception condition and the responses that execute
when the exception is detected. An ARFSET is a named collection of ARF definitions.
Prior Run (Queue)

Defines when the job last executed successfully. This information is used to fulfill requirements
for jobs being submitted currently or in the future.
Note: Although previously defined as a unique CA Workload Automation CA 7® Edition

queue data set, the Prior Run data has been rolled into the database as a definition entry.
The definition side of the database also contains miscellaneous information that CA Workload
Automation CA 7® Edition uses. This information includes the global variables, profile records, and
records for cross-platform support (node records, owner/node access records).
Active Workload
The active workload, also known as the queues, provides the status of the CA Workload Automation
CA 7® Edition submitted jobs and resources actively in use. The status queues are separated by
function, although in the database there is no physical distinction. The status queues include the
following queues:
Preprocess queue Tracks input activities for workstations.
Request queue Contains records of all jobs that CA Workload Automation CA 7® Edition
scheduled. Jobs can enter the request queue because of automatic scheduling by CA Workload
Automation CA 7® Edition or because of demand scheduling to satisfy a user request.
Ready queue Contains records of jobs with all requirements satisfied that are waiting to be
submitted, or have been submitted, to the operating system for execution.
Active queue Contains records of jobs that have become active on a computer.
Postprocess queue Performs a function similar to the preprocess queue for tracking output data
handling.
Active VRM holds the resource information for resources that currently CA Workload Automation CA
7® Edition submitted jobs are using or for resources that are active in the system.
Active ARF Records (AARs) are created any time that a job referring to the ARFSET enters the request
08-Feb-2018 422/722
Active ARF Records (AARs) are created any time that a job referring to the ARFSET enters the request
queue. The AARs are used to monitor one or more production jobs in the system. ARF dynamically
deletes a record when no more jobs are on the system to monitor using that ARFSET. When
exception conditions are detected, an ARFQ record is created to schedule the responses that are
associated with the exception conditions. ARFQ records are dynamically deleted when all responses
have been scheduled.
JCL and Parameter Libraries

These data sets typically exist before the installation of CA Workload Automation CA 7® Edition. They
are simply defined to CA Workload Automation CA 7® Edition. They contain execution JCL (JOB
statement, and so forth), parameter data, or both to submit to the operating system. PDS, CA
Panvalet®, and CA Librarian® organizations are supported. Cataloged procedure libraries (PROCLIBs)
are not defined to CA Workload Automation CA 7® Edition directly but continue to serve the same
function as always.
Database Verification Utility

The CAL2DBVR database verification utility examines relationships between tables in the database for
inconsistencies.
More information:
CAL2DBVR Utility (https://wiki.ca.com/display/CWAC7E/CAL2DBVR+Utility)
Backup/Reload
In all production environments, backup and reloading of databases is an important consideration.
Schedule backups on a regular basis.
More information:
Backup (https://wiki.ca.com/display/CWAC7E/Backup)
Work Queues
The product uses following work queues:
08-Feb-2018 423/722
Disk queue table (DQT)

Contains control information for all online terminal messages.
Scratch queue
Contains the response messages for terminals and provides space for application work areas.
Active Workload Flow Phases

During processing, work (defined to CA Workload Automation CA 7® Edition) is moved from one CA
Workload Automation CA 7® Edition phase or queue to the next. Appearance of work in a given
queue depends on the status of that work at a particular time.
Following is a narrative of the work flow within the CA Workload Automation CA 7® Edition structure.
Numbers within parentheses in the narrative refer to circled numbers in the following figure.
(1)
The preprocess queue is used by CA Workload Automation CA 7® Edition to track input
workstation activity. Work enters the preprocess queue as a result of the following:
Schedule scan placing work in the queue because of calendar schedules.
Demanding of an input network by the user with the DMDNW command.

Within CA Workload Automation CA 7® Edition, a network (input and/or output) is a structure
of user-defined workstations (data entry, production control, distribution) where activities
related to work processing are performed. A network may or may not be related to a job. For
example, a network can be defined, scheduled and invoked to track work flow or control
nonproduction or non-CPU data processing activities. When input networks are used with
jobs, these networks define activities to be completed before the associated job executes.
Networks are scheduled and controlled somewhat like jobs and are referenced by CA
Workload Automation CA 7® Edition in controlling job execution. Prompts are issued to
workstations whenever work is late or when defined deadline time (must start times) indicate
that work may become late.
(2)
Work (jobs) enters the request queue as a result of the following:
Schedule scan placing work in the queue because of calendar schedules.
A DEMAND command to demand processing of a particular job.
A LOAD command to cause loading of a CPU job to the CA Workload Automation CA 7®

Edition database.
A RUN command to run a job independent of predecessor job or data set requirements.
A job completion, input workstation network completion or data set creation triggering a
subsequent job.
08-Feb-2018 424/722
(3) and (4)

At the time a job is placed in the request queue, JCL or PARMs for the job is added to the trailer
queue from the JCL or PARM data set. Output networks associated with the job are placed in the
postprocess queue. As a job is processed through CA Workload Automation CA 7® Edition,
pointers are maintained that point to the data in the trailer queue.
The request queue contains requests by CA Workload Automation CA 7® Edition (or the user) to
run jobs. Each job in the request queue has a master requirements count. This is a count of
activities (requirements for the job) that must be completed before the associated job can be
sent to an operating system for execution.
These activities can include both internal and external events. Internal events might include
creation of an input data set by another job, successful completion of another job, and so on.
Internal events are monitored and event completion is posted automatically by CA Workload
Automation CA 7® Edition. External events might include JCL overrides, creation of a data set by a
job unknown to CA Workload Automation CA 7® Edition, or any other type of manual activity.
Completion of external activities is posted manually through a CA Workload Automation CA 7®
Edition command or automatically by batch external programs (U7SVC, BCLP, trailer step). (An
external event can be posted by a job submitted by CA Workload Automation CA 7® Edition that
updates the data set, even though the data set is marked external.)
As events are completed and posted, the master requirements count for a job is decremented.
When the count goes to zero (when all requirements are satisfied), the job is ready for processing.
Jobs placed in the request queue by a LOAD or RUN command do not have data set or
predecessor requirements but can enter the request queue with a HOLD requirement. This
requirement is imposed through use of the LOADH (LOAD/HOLD) command or the RUNH (RUN
/HOLD) command. Jobs entering the request queue with a HOLD requirement must be manually
released from the queue by posting the requirement.
(5)
When all requirements for a job are satisfied, the job is moved to the ready queue.
a.
If the workload balancing feature is not turned on, the JCL necessary to execute the job is
written to the internal reader or submit data set (for the CPU on which the job is to execute)
or sent to the destination agent (cross-platform jobs).
08-Feb-2018 425/722
b.
If the workload balancing feature is active, the JCL is not written to the internal reader or data
set until the job satisfies the job mix optimization criteria specified by the user. For cross-
platform jobs, the data is not sent to the agent until the job satisfies the job initialization
optimization.
c.
If the job has any resource connections (through Virtual Resource Management), a check is
made to determine whether the resources are available and meet the execution requirements
for the job. If the resource requirements are satisfied, the JCL is written to the internal reader
or submit data set. If resources are unavailable to the job, the job stays in the ready queue
with a status of W-RSRC - waiting on resources. Similarly, for cross-platform jobs, the data is
sent to the destination agent when the resource requirements are met.
(6) and (7)

When a job becomes active on an operating system, CA Workload Automation CA 7® Edition
receives the job initialization record for the job and moves the job to the active queue. The job
remains in the active queue until CA Workload Automation CA 7® Edition receives a job
completion record. On receipt of the job completion record, the job is moved back to the request
queue for job completion processing.
If CA Workload Automation CA 7® Edition determines, through condition or abend codes, that a
job did not successfully complete, the job is moved from the active queue to the request queue
where it remains until it is restarted or canceled. At this time, a restart prompt is issued for the
job. A list of all jobs requiring restart is available through the LIST command.
With agent jobs (AGJOBs), the CA Workload Automation Agent determines the success or failure
of the job. CA Workload Automation CA 7® Edition has no control in interpreting the condition
codes. If the agent detects that the job should fail, it sends to CA Workload Automation CA 7®
Edition an unsuccessful message. The job is placed in the request queue pending a restart or
cancel command.
During job completion processing, the following will happen:
Data sets created by a successfully completed job are updated in the database and used to
post requirements for those data sets used by other jobs in the request queue.
During completion processing, job triggers and data set triggers are examined to determine
whether to bring more jobs into the request queue.
Requirement records in the database for NEXT-RUN=ONLY are discarded.
Requirement records in the database for NEXT-RUN=SKIP are reset to YES.
(8) and (9)

Once completion processing is finished, the status queue record is placed in the prior-run queue.
This serves as a last runtime record for the job. Optionally, JCL or PARM data used to execute the
job can be retained in the trailer queue. Retaining this data in the trailer queue has the advantage
of having it available for review and reuse should the need arise. However, the practice of
retaining a large volume of data impacts the size requirements of the trailer queue.
The status record for an agent job is retained in the prior run queue, but the PARMs used to
submit the job are not retained. With agent jobs, there is the potential for a large amount of data
to be sent with the job request. To see the data that was used for a job, see SASSHIS8 History
Reporting (https://wiki.ca.com/display/CWAC7E/SASSHIS8+History+Reporting).
(10)
08-Feb-2018 426/722
(10)
For every job completion, job cancellation, job restart, completion of a preprocess or postprocess
network, or cancellation of a preprocess or postprocess network, an entry is written to the run
log. This log is accumulated continuously with a user-specified number of days being retained (the
default is five days).
Other Data Sets

The DD Statements (see page 475) article provides more information about the other data sets and
their requirements.
Terminal Communications
A terminal network provides terminal communications with CA Workload Automation CA 7® Edition.
The network provides online and batch access to CA Workload Automation CA 7® Edition facilities.
Batch Access
Several programs provide batch access to CA Workload Automation CA 7® Edition:
Batch Card Load Program (BCLP)

Loads card-image data to required data sets for CA Workload Automation CA 7® Edition jobs.
Through BCLP, you can create, replace, or modify single or multiple data sets. When BCLP
executes, CA Workload Automation CA 7® Edition is notified of successful data set manipulation
through the communications data set. In this way, the database can be updated to reflect the
creation date and time. Also, the request queue is scanned for jobs that have that particular data
set as an input requirement. BCLP can execute on any computer where ICOM is active.
Batch Terminal Interface

Let you process commands in batch mode as if from a real terminal. Up to eight batch terminals
can be assigned to CA Workload Automation CA 7® Edition. Each batch terminal consists of a pair
of disk data sets: one input and one output. These data sets are defined to CA Workload
Automation CA 7® Edition so that they appear to be a real terminal. Use of a batch terminal is
accomplished by using the CA Workload Automation CA 7® Edition batch terminal interface
program.
CAICCI Terminals
CAICCI terminals can schedule work in CA Workload Automation CA 7® Edition from an external
task like a batch job or a REXX EXEC running in a TSO session. The format of CAICCI terminal input
and output is the same as the format the Batch Terminal Interface uses.
Internal Terminals
System functions like as Cross-Platform Scheduling and the Automated Recovery Facility (ARF) use
internal terminals. These terminals let you schedule work for the following items:
Threads that are not directly associated with online terminal users
Tasks using the external communicators like trailer step

For example, ARF uses an internal terminal to issue CA Workload Automation CA 7® Edition
commands in response to exceptions detected.
08-Feb-2018 427/722
TCP/IP Terminals
TCP/IP terminals can also schedule work in CA Workload Automation CA 7® Edition from an
external task like a batch job or a REXX EXEC running in a TSO session. Provided programs can
execute on distributed platforms to request work from CA Workload Automation CA 7® Edition.
These terminals communicate through the TCP/IP network. The format of TCP/IP terminal input
and output is the same as the format that the Batch Terminal Interface uses.
Trailer Step
Trailer steps are special job steps that execute a utility type program. You can add them to any
job (including jobs that are not defined to CA Workload Automation CA 7® Edition) to cause the
processing of CA Workload Automation CA 7® Edition queue maintenance posting commands. A
trailer step can execute on any computer where ICOM is active. Although it causes activity within
CA Workload Automation CA 7® Edition, it does not affect the operational function of the job that
contains the trailer step. The trailer step can perform any of the queue maintenance posting
functions as defined in QM Command (https://wiki.ca.com/display/CWAC7E/QM+Command) and some
other CA Workload Automation CA 7® Edition functions.
U7SVC Facility
U7SVC is a program that combines certain functions of both the trailer step and the Batch Card
Load program. U7SVC can execute as a job step in batch or can receive a call from a user
program. You can execute U7SVC on any computer where ICOM is active. The user can use U7SVC
to post to CA Workload Automation CA 7® Edition the creation of a data set or to issue CA
Workload Automation CA 7® Edition batch commands.
More information:
External Communicators (https://wiki.ca.com/display/CWAC7E/External+Communicators)
BSAM Terminal (Browse Data Set)

A BSAM terminal is a sequential DASD file that can be used as an alternative to a terminal printer.
This file is treated as a wraparound, 80-character print image data set. The primary use of a BSAM
terminal is for master station messages.
All master station messages are written to the log data set whether a browse data set is in use. If a
browse data set is defined with the appropriate GROUP, LINE, and TERM statements in the
initialization file, messages are also written to this data set. The data set is sequential, wraparound,
80-character, and print line image. The user allocates the data set to contain as much message
volume as wanted for online browsing. Once the allocated area is filled with messages, writing of
messages to the data set begins again at the front of the allocated area.
At startup time, the browse data set is opened as a sequential output data set. No checkpointing is
done for the data set. Therefore, message traffic is written beginning at the front of the area
allocated. Assume that a restart of CA Workload Automation CA 7® Edition is occurring, and the user
wants to avoid overlaying previous messages. In this case, the user must preserve the data, before
restarting CA Workload Automation CA 7® Edition, using whatever technique satisfies their particular
requirements. A simple copy of the data set to another DASD area, or to a magnetic tape, could
quickly save the data.
To do browsing through TSO, CA Roscoe®, or any facility other than CA Workload Automation CA 7®
08-Feb-2018 428/722
To do browsing through TSO, CA Roscoe®, or any facility other than CA Workload Automation CA 7®
Edition, code the DISP parameter in the DD statement as SHR for shared access.
A special one-time consideration exists whenever the browse data set is being used for the first time.
Because the data set is used in a wraparound manner, formatting occurs automatically while
messages are being written during execution of CA Workload Automation CA 7® Edition. However,
until the area is used the first time, reading beyond end of file would occur during any attempt to
browse the data set unless the user had preformatted the area.
CA 7 Web Client User Interface

The CA 7® Web Client user interface lets you enter CA 7 requests. The user interface consists of a
Web Client Server, the CA 7 Server, and the browser window of the user, with the CA Common
Services Viewpoint Interface. The Web Client has user-friendly panels in which to enter information.
When the user enters the data in the browser, the request is sent to the Web Client Server. The Web
Client Server then connects to the CA 7 Server. The CA 7 Server passes the request and receives the
response from CA 7 through the Viewpoint Interface. The CA 7 Server next returns the data to the
user through the CA 7 Web Client.
Logical Terminals
A logical terminal is a symbolic name, known as station name, assigned to a real (physical) terminal
that is defined to the CA Workload Automation CA 7® Edition system. A single device can represent
multiple logical terminals to the CA Workload Automation CA 7® Edition system. For example, one
physical terminal can service several functions. Each functional use could be assigned its own logical
name.
Online Access
3270-type terminals (and optionally associated printers) provide online access (compared to batch
access). These terminals are used for input of CA Workload Automation CA 7® Edition commands,
and for output of CA Workload Automation CA 7® Edition messages and prompts. OS consoles are
also considered to be online terminals.
The CA Workload Automation CA 7® Edition master terminal (CONS=MASTR in the initialization file)
must be an input and output device and can be the OS console or any online terminal. In addition to
serving as the master console, the terminal can be used to input commands and data like any other
terminal in the network. Typically, the master console receives few CA Workload Automation CA 7®
Edition messages during operation.
The master station can be a browse data set, or a 3270-compatible terminal or printer. You can
define the master station as the same physical device as the master console, although this method is
not recommended. Unlike the master console, the master station receives most messages issued by
CA Workload Automation CA 7® Edition during job processing. If you define the master console and
the master station as the same physical device, an OS console cannot be used.
Note: Do not confuse the master terminal (CONS=MASTR in the initialization file) with the
master station (STANIDS=MASTER).
08-Feb-2018 429/722
Set up the Execution Environment

The execution environment consists of multiple elements. These pages address planning and
preparing these elements for a full CA Workload Automation CA 7® Edition execution. Correctly
setting up the execution environment ensures that you have the best environment for CA 7.
The execution environment elements that are discussed in these articles include:
CAIRIM is used to establish and maintain the CA WA CA 7 Edition system environment on each
LPAR.
CAIENF can generate notifications for the following events:
Browse messages
Job completions
Log records
External Tracking and Filtering discusses tracking external z/OS tasks, tracking external data sets,
and filtering the data set records that CA WA CA 7 Edition processes.
The principal functions of ICOM are:
Communicate SMF and trailer information to CA WA CA 7 Edition.
Submit jobs to the host system internal reader (optional).
CA7ONL (CA 7 Central Control System)
Startup Procedures help you with the initialization process that starts the functions that
schedule and control the production environment.
For execution, Module UCC7 is the central control entity of CA WA CA 7 Edition. UCC7 must be
active when you want to perform CA WA CA 7 Edition functions. When you want CA WA CA 7
Edition to provide automatic scheduling, monitoring, and control of work, the Independent
Communications Manager (ICOM) must also be active.
Initialize CAIRIM
This article explains how to initialize the Resource Initialization Manager (CAIRIM). The CA Workload
Automation CA 7® Edition system environment is the set of control structures that are necessary to
support the CA Workload Automation CA 7® Edition SVC and SMF interfaces. These structures include
the SVC and SMF interface modules and options that control job tracking and trailer data processing.
These articles describe the system environment and the facilities that are used to maintain it.
08-Feb-2018 430/722
The System Environment

A job is "CA Workload Automation CA 7® Edition tracked" when its progress can be monitored using
CA Workload Automation CA 7® Edition facilities such as LQ or XQ. A "CA Workload Automation CA 7®
Edition system environment" must be configured on every LPAR where CA Workload Automation CA
7® Edition tracked jobs execute.
CAIRIM is used to establish and maintain the CA Workload Automation CA 7® Edition system
environment on each LPAR. The IVT (Instance Vector Table) is the principal control block in the CA
Workload Automation CA 7® Edition system environment. Installation options and addresses of
important routines such as the CA Workload Automation CA 7® Edition SVC and SMF exits are
maintained in the IVT. The CAIRIM product initialization routine establishes and maintains the IVT.
Once the IVT is created, its address is located using a subsystem control block that is built for CA
Workload Automation CA 7® Edition.
The CA Workload Automation CA 7® Edition system environment on an LPAR can host up to eight
active "tracking instances" of CA Workload Automation CA 7® Edition. A tracking instance is a control
structure that is used to identify SMF and Trailer data in CSA. Programs such as SASSICOM, U7SVC
and UCC7 access this data by locating the appropriate tracking instance. Each such control structure
includes pointers to the SMF and Trailer data and options that control the behavior of the SVC and
SMF exits for the instance.
Running multiple CA 7 instances can be helpful in the following ways:
Running multiple customers.
Upgrading to a new version (see the following caution).
Applying maintenance.
Testing user exits.
A tracking instance can be active or inactive. By default, all tracking instances are inactive when the
system environment is initialized. To be used, they must be made active. CAIRIM is used to activate
or inactivate CA Workload Automation CA 7® Edition tracking instances.
Important! You have only one copy of the SMF interface exits and the SVC modules.
Therefore, these modules cannot be tested using this method. This means that these
modules must be installed for the primary ("production") level of CA Workload Automation
CA 7 Edition. Other instances can be a different release level, but the system interface
modules are at the production level.
There are typically three ways of referring to a tracking instance: the 4-byte tracking instance name,
the SMF indicator byte, and the JOB statement indicator byte.
08-Feb-2018 431/722
Programs like UCC7, SASSICOM, and U7SVC use the tracking instance name. The JOB statement
indicator is inserted into the JOB statement when CA Workload Automation CA 7® Edition submits a
job. When CA Workload Automation CA 7® Edition submits a job, it finds the value of the JOB
statement indicator that is associated with the tracking instance name supplied at CA Workload
Automation CA 7® Edition startup. This value is then inserted into the JOB statement.
The JOB statement indicator identifies the tracking instance associated with the submitter to the
SASSUJV module (the CA Workload Automation CA 7® Edition SMF exit). SASSUJV uses the JOB
statement indicator to determine the value of the SMF indicator that is propagated to SMF records
for the job.
The SMF indicator identifies the tracking instance with which the SMF data is to associate.
Tracking Instance Identifiers
The following table describes the ways that tracking instances can be identified in the CA Workload
Automation CA 7® Edition system environment.
Tracking Instance Name SMF Identifier JOB Statement Identifier

CA71 x'EE' x'31'
CA72 x'ED' x'30'
CA73 x'EC' x'2F'
CA74 x'EB' x'2E'
CA75 x'EA' x'2D'
CA76 x'E9' x'2C'
CA77 x'E8' x'2B'
CA78 x'E7' x'2A'
Differences Between Instances

Participation in NCF is limited to the primary tracking instance (CA71).
Each instance can be configured to track external data sets and tasks. However, using external data
set tracking, task tracking or both, implies more resource use, that is, CPU and storage. For this
reason, we recommend that you limit such tracking to as few instances as possible.
As a best practice, each instance has its own data sets, JCLLIB, and procedures that refer specifically
to it. This group includes batch jobs, procedures, and network connections. Each instance must have
its own logical database name (DBPARMS), but multiple instances can share a CA Datacom/AD Multi-
User Facility (MUF).
The initialization file identifies the instance that this CA 7 central control system (CA7ONL) controls. In
this way, batch jobs and other processes know which instance to use. The execution parameters
generally indicate a keyword parameter CA7=CA7n, where n is the instance number.
More information:
08-Feb-2018 432/722
Install Multiple Instances (see page 430)
Manage the System Environment with CAIRIM

The CA Workload Automation CA 7® Edition system environment is configured and maintained using
the CA Resource Initialization Manager, CAIRIM. CAIRIM is a collection of services that facilitates the
installation of systems software. Products such as CA Workload Automation CA 7® Edition can
dynamically install and manage SVC routines, SMF exits, and subsystems using services that CAIRIM
provides. For more information about CAIRIM, see the CA Common Services documentation.
CAIRIM must be run during or after an IPL to establish the system environment on each LPAR where
CA Workload Automation CA 7® Edition tracked jobs are to execute. If a valid system environment is
not present, CA Workload Automation CA 7® Edition cannot track jobs. SASSICOM does not execute
properly. The external communicators like SASSTRLR and U7SVC do not function.
To see details about the system environment, execute the CAL2ENVR utility, the environment report.
This report shows information about the IVTs, the SVC, and SMF exits, and other information.
More information:
CAL2ENVR Utility (https://wiki.ca.com/display/CWAC7E/CAL2ENVR+Utility)
The System Configuration File

The system environment management requests are coded in the CA Workload Automation CA 7®
Edition System Configuration File. Add a DD statement named L2OPTS to the CAIRIM procedure to
identify this sequential file (DCB=LRECL=80) to the CA Workload Automation CA 7® Edition product
initialization routine.
The product initialization routine executes in two phases. In the first phase, no changes are made to
the system environment. The routine first determines the state of the system environment. This state
becomes the initial value of the "working" system state. When a statement is read from the System
Configuration File, it is validated for syntax. If the statement is syntactically valid, it is examined for
consistency with the working system state. If the request is consistent with the working system state,
then it is staged for execution. The working system state is updated as if the request had been
processed, and the product initialization routine continues to the next statement. If an error is
encountered during the staging process, the product initialization routine terminates with an error.
No updates are made to the system environment.
When all requests have been staged without error, the second phase of processing begins. In that
phase, the product initialization routine reads the staged requests and updates the system
environment on the LPAR.
To see an interpretation of the System Configuration file from an actively running system, use the
CAL2SC80 utility to create an L2OPTS file.
08-Feb-2018 433/722
Syntax
A statement that has an asterisk in column 1 is treated as a comment. If a statement does not have
an asterisk in column 1, it must conform to the following scheme:
OBJECT-NAME VERB KEYWORD1 KEYWORD2 KEYWORD3
Blanks delimit the statement elements.
The first System Configuration File statement element is the object name. A valid statement that is
not a comment must begin with an object name. If the object name is 'GLOBAL', then the intended
object of the operation is the entire system environment. If the intended object is a specific tracking
instance, then the object name must be a valid CA 7 instance name: CA71, CA72, CA73, CA74, CA75,
CA76, CA77, or CA78. No other object names are valid. Although a tracking instance can be assigned
an alias, the alias name cannot be used in this position.
The second System Configuration File statement element is the verb.
After the object name and the verb, additional keywords can be coded if default options must be
overridden.
Configuration File Elements
The following table lists valid object names, the verbs that are allowed with them, and the keywords
that are supported for them.
Object Verb Parameters

Name
GLOBAL INIT BSUBCHK EXTTRK7 FORCESSCT FORCESVC HEALTHCHECK SMFO SVC
SVDSNCHK TRLBLK
INITC BSUBCHK EXTTRK7 FORCESSCT FORCESVC HEALTHCHECK SMFO SVC
SVDSNCHK TRLBLK TSVC
REFRESH NOSVC
UPDATE BSUBCHK EXTTRK7 HEALTHCHECK SVDSNCHK TRLBLK
(UPD)
DELETE ALL
(DEL)
CA71 ADD ALIAS BSUBCHK NCF SMF SVDSNCHK TRLBLK XDSN XJOB XU83
UPDATE ALIAS BSUBCHK NCF SMF SVDSNCHK TRLBLK XDSN XJOB XU83
(UPD)
DELETE
(DEL)
CA72- ADD ALIAS BSUBCHK SMF SVDSNCHK TRLBLK XDSN XJOB XU83
CA78
UPDATE ALIAS BSUBCHK SMF SVDSNCHK TRLBLK XDSN XJOB XU83
(UPD)
DELETE
(DEL)
No other parameters are permitted on a System Configuration File statement. If columns 73-80 are
08-Feb-2018 434/722
No other parameters are permitted on a System Configuration File statement. If columns 73-80 are
numeric, they are assumed to be sequence numbers and are ignored.
The last non-blank character as a '+' indicates a statement continuation. Precede the continuation
indicator with at least one blank. At least one blank must also follow the continuation character. A
keyword and its associated parameters cannot be continued across statements.
Statement Actions
These topics describe the actions that are taken in response to System Configuration File statements.
GLOBAL INIT
GLOBAL INIT processing locates the CA Workload Automation CA 7® Edition IVT (Instance Vector
Table). If the IVT is not present, the IVT is built with initial values. The 'CA-7' subsystem is defined
when it is not already present. The address of the IVT is stored in a control block that is associated
with that subsystem. GLOBAL INIT processing locates the CA Workload Automation CA 7® Edition SVC
routines and associates them with the SVC number that CA Workload Automation CA 7® Edition
programs use. The SMF routines that CA Workload Automation CA 7® Edition uses (SASSUJV,
SASSU83, and SASSU84) are located and identified to the CA common SMF interface.
This statement is the first statement that CAIRIM must process after an IPL to create a CA Workload
Automation CA 7® Edition system environment on this LPAR.
The SVC, SMFO, and HEALTHCHECK keywords can be used to override system defaults. Other
keyword parameters can override system defaults for all instances on the LPAR.
GLOBAL INITC
Before r11, you could define up to two tracking copies of CA Workload Automation CA 7® Edition to
run on an LPAR: a production copy and an optional test copy. These copies were known as UC07 and
UCT7.
Today, you can define up to eight fully functional tracking instances of CA Workload Automation CA
7® Edition. The system environment that is required to support these instances is created when you
use GLOBAL INIT.
The system environment is also created when you use GLOBAL INITC. However, GLOBAL INITC also
creates system structures that are needed for UC07 and UCT7, known as compatibility mode. In the
compatibility mode, the system environment can associate old explicit and implicit references to
production and test tracking instances.
Then, the system environment recognizes the production copy of CA Workload Automation CA 7®
Edition as the CA71 tracking instance. The test copy of CA Workload Automation CA 7® Edition is seen
as the CA72 tracking instance. A typical configuration exploiting compatibility mode includes the
following items:
A UC07 copy on the CA71 instance.
A UCT7 copy on the CA72 instance.
Up to six current release copies on instances CA73-CA78.
If you intend to run a test copy of CA Workload Automation CA 7® Edition in the compatibility mode
08-Feb-2018 435/722
If you intend to run a test copy of CA Workload Automation CA 7® Edition in the compatibility mode
system environment, add the TSVC keyword to the GLOBAL INITC statement. This keyword identifies
the SVC that the CA72 test instance uses. For more information, see the TSVC description in this
topic.
GLOBAL INITC ensures the compatibility mode, but you are not required to exploit it. So, for example,
if your system environment is in compatibility mode and you have defined the CA71 instance, you can
run another CA 7 instance.
Note: Either GLOBAL INIT or GLOBAL INITC must be the first statement that is processed
after an IPL to create the system environment on the LPAR.
A GLOBAL INIT or GLOBAL INITC builds the CA Workload Automation CA 7® Edition system
environment (SVC and SMF interfaces) on an LPAR. However an instance must then be added for
each copy of CA Workload Automation CA 7® Edition that is submitting jobs. This addition can be
accomplished in one execution of CAIRIM. Simply include the ADD statements for the instances to
add after the GLOBAL INIT or GLOBAL INITC statement in the System Configuration File. For example,
if three copies of CA Workload Automation CA 7® Edition are submitting jobs, the System
Configuration File would look something like the following example:
GLOBAL INIT
CA71 ADD
CA72 ADD
CA73 ADD
GLOBAL REFRESH
GLOBAL REFRESH processing reloads interface routines that a previous GLOBAL INIT or GLOBAL INITC
loaded. To refresh the CA Workload Automation CA 7® Edition SVC routines and SMF exits, use this
option. If the IBM Health Checker interface is active, the exit and check routines are also reloaded.
This statement is not accepted unless a valid CA Workload Automation CA 7® Edition system
environment is present on the LPAR.
Note: By default, GLOBAL REFRESH reinitializes the CA Workload Automation CA 7® Edition

SVC. ICOMs that are active on the LPAR when the SVC is initialized can abend. To avoid this
situation, terminate all ICOMs before executing the GLOBAL REFRESH. When the CAIRIM
processing is complete, you can restart these tasks.
If you must reload the SMF exits, but you do not need to refresh the SVC, use GLOBAL REFRESH
NOSVC. This method does not require the recycling of ICOMs.
GLOBAL UPDATE
GLOBAL UPDATE processing alters values in the IVT that are used for instance defaults, the IBM
Health Checker interface, or both.
08-Feb-2018 436/722
environment is present on this LPAR.
GLOBAL DELETE
GLOBAL DELETE processing removes the association between the CA Workload Automation CA 7®
Edition SVC routines and the SVC number that was identified as the CA Workload Automation CA 7®
Edition SVC number on a previous GLOBAL INIT/INITC. It also deactivates the CA Workload
Automation CA 7® Edition SMF routines, deactivates the IBM Health Checker interface, and marks the
IVT inactive. Only one parameter is permitted on this statement: ALL.
If GLOBAL DELETE ALL is coded, all active instances are deleted before removing the SVC and SMF
exits. If ALL is not coded, all instances must have been deleted before issuing the GLOBAL DELETE.
environment is present on this LPAR.
CA7n ADD
CA7n ADD processing creates an active CA Workload Automation CA 7® Edition tracking instance. An
instance must be added before it is available for use by CA Workload Automation CA 7® Edition
programs. ADD processing includes the construction of an instance control block (ICMDSECT). The
storage that the SVC requires for the instance operation is acquired and initialized.
Note: Use of NCF is limited to the CA71 instance. NCF support is indicated if a valid
UCC7NODE table is present when CAIRIM adds the CA71 instance. If a valid table is present,
the NCF keyword can be used on the CA71 ADD statement to indicate the host node
number.
An error message is issued if you try to add an instance that is already present.
CA7n UPDATE
CA7n UPDATE processing alters values in the instance control block (ICMDSECT).
This statement is not accepted unless the instance is active on this LPAR.
CA7n DELETE
CA7n DELETE processing removes this instance from the CA Workload Automation CA 7® Edition
system environment on this LPAR. The instance is no longer available for use by CA Workload
Automation CA 7® Edition programs on this LPAR.
No keywords are permitted on the CA7n DELETE statement.
This statement is not accepted unless the instance is active on this LPAR.
08-Feb-2018 437/722
Statement Keywords
These topics describe the keywords that can be used on the System Configuration File statement.
ALIAS
Length: 1 - 4 characters.
Allowable values: A-Z, 0-9, #, @, $, _, -. No embedded or trailing blanks. Alias must be unique in this
CA Workload Automation CA 7® Edition system environment. The following values are reserved:
PROD, TEST, CA71, CA72, CA73, CA74, CA75, CA76, CA77, CA78, UC07, and UCT7. ALIAS(*) can be
used to remove a previously assigned alias from an instance.
Default: None.
Applicable statements: CA7n ADD, CA7n UPDATE
If an alias is assigned to a CA Workload Automation CA 7® Edition tracking instance, use that value
instead of the instance name in CA Workload Automation CA 7® Edition programs. You cannot assign
more than one alias to an instance. In addition to any alias that you can assign, PROD and UC07 can
always be used to refer to CA71. TEST and UCT7 can always be used to refer to CA72.
BSUBCHK
Allowable values: BSUBCHK(Y) and BSUBCHK(N)
Default: BSUBCHK(N)
Applicable statements: GLOBAL INIT, GLOBAL INITC, GLOBAL UPDATE, CA7n ADD, CA7n UPDATE
When coded on the GLOBAL statements, the BSUBCHK keyword sets the default value of BSUBCHK
for all tracking instances on the LPAR.
If the BSUBCHK value for a given instance is Y, CA Workload Automation CA 7® Edition programs that
run outside the CA Workload Automation CA 7® Edition address space issue a submit check when
necessary.
For CAICCI or TCP connections, the BSUBCHK setting on the target CA Workload Automation CA 7®
Edition instance can optionally be used in place of the local terminal setting. If this setting is used, the
instance setting overrides the setting on the local terminal. If the target instance uses a submit
security class value other than the default, this class value can optionally be used for the security
check.
EXTTRK7
Allowable values: EXTTRK7(Y) and EXTTRK7(N)
Default: EXTTRK7(N)
Applicable statements: GLOBAL INIT, GLOBAL INITC, GLOBAL UPDATE
08-Feb-2018 438/722
Use this keyword when a CA 7 instance must externally track a job or data set that another CA 7
instance is internally tracking. Effective use of this feature requires at least one instance that supports
external tracking of jobs or data sets. The XJOB or XDSN keyword occurs in the instance definition.
When using the default, EXTTRK7(N), SMF information for a CA Workload Automation CA 7® Edition
job (and any data set associated with it) is routed to a single destination: The CA 7 instance that
submitted it. Other CA 7 instances do not see this information. Thus another CA 7 instance is not
tracking a job or data set.
However if EXTTRK7(Y), SMF information about jobs and data sets is available to all other defined CA
7 tracking instances. Thus, any interested CA 7 instance can externally track an object, even if another
CA 7 instance is already tracking it internally.
Use of EXTTRK7(Y) requires additional system resources. When SMF data for a CA Workload
Automation CA 7® Edition job or data set is processed, the SMF exits must search the external
tracking tables for the other instances. The impact of these additional searches varies depending on
the following:
The number of job and data set events to process.
The number of instances that use external tracking.
The size and complexity of the external tracking tables involved.
Additional CSA is used when CA Workload Automation CA 7® Edition jobs and data sets are also
externally tracked.
Note: For more information about external tracking, see the XJOB and XDSN keywords
later in this topic.
FORCESSCT
Applicable statements: GLOBAL INIT, GLOBAL INITC
GLOBAL INIT/INITC processing requires an SSCT for 'CA-7'. If this SSCT does not exist, the CA
Workload Automation CA 7® Edition product initialization builds it for use by CA Workload
Automation CA 7® Edition. But if an SSCT by this name exists on the LPAR, GLOBAL INIT/INITC
processing tries to help ensure that CA Workload Automation CA 7® Edition uses it. If it does not
appear that CA Workload Automation CA 7® Edition uses the SSCT, the GLOBAL INIT/INITC fails.
If you want to override this checking and let CA Workload Automation CA 7® Edition use the existing
SSCT, code the FORCESSCT parameter.
This parameter can cause the application that created the SSCT to fail.
Example:
In this example, the CA Workload Automation CA 7® Edition system environment initializes without
verifying ownership of the SSCT named 'CA-7'.
08-Feb-2018 439/722
GLOBAL INIT FORCESSCT
FORCESVC
The CA Workload Automation CA 7® Edition CAIRIM routine attempts to verify that there is no
conflict over the use of the indicated SVC number. When a conflict occurs, the GLOBAL INIT/INITC
operation fails. If you want to override this checking and force the definition of the CA Workload
Automation CA 7® Edition SVC using this number, you can code FORCESVC.
Example:
In this example, because the SVC keyword is not coded, the CA Workload Automation CA 7® Edition
CAIRIM routine attempts to define SVC 167. Because FORCESVC is coded, the CA Workload
Automation CA 7® Edition CAIRIM routine appropriates SVC 167 for use by CA Workload Automation
CA 7® Edition even if it is in use by another application.
GLOBAL INIT FORCESVC
HEALTHCHECK
Allowable values: N or 0-99
Default if not coded: HEALTHCHECK(N)
Default if coded: HEALTHCHECK(15)
Applicable statements: GLOBAL INIT, GLOBAL INITC, GLOBAL REFRESH, GLOBAL UPDATE
Use a value of N to deactivate the IBM Health Checker interface. Use a value of 0-99 to activate the
IBM Health Checker interface and define the number of minutes between IBM Health Checker
checks. A value of 0 defines the IBM Health Checker checks but marks them inactive.
Note: If the CA Workload Automation CA 7® Edition load library is not part of the linklist,
copy the exit routine, CAL2HCXT, to a linklist library. CAL2JCL member AL2HCKCP can
perform this copy.
Example:
This example initializes the CA Workload Automation CA 7® Edition system environment with 30
minutes between IBM Health Checker checks.
GLOBAL INIT HEALTHCHECK(30)
NCF
Length/format: 1 - 2 characters.
Allowable values: Y, N, or the UCC7ID= value on the NCF node table entry for the host system
08-Feb-2018 440/722
Allowable values: Y, N, or the UCC7ID= value on the NCF node table entry for the host system
Default: NCF(N)
Applicable statements: CA71 ADD, CA71 UPDATE
Installing NCF requires performing a CA71 ADD with NCF(Y) or NCF( nn). A CA71 UPDATE cannot install
NCF. You can change NCF (for example, to change the UCC7NODE table) with the CA71 UPDATE
action.
Use this keyword to activate, deactivate, or modify NCF tracking parameters.
Specify NCF(Y) if you intend to use the Network Communications Facility (NCF). In that case, CAIRIM
loads the NCF node table. CAIRIM attempts to find an entry in the table that matches the SMF ID of
the CAIRIM host. If it is found, it is made the first entry in the table. If it is not found, the table is not
modified.
If you specify NCF(nn), CAIRIM attempts to locate an entry in the node table with UCC7ID= nn. If such
an entry is found, it is made the first in the table.
If you want to deactivate NCF tracking support, use NCF(N).
More information:
NCF (https://wiki.ca.com/display/CWAC7E/NCF)
Example:
In this example, the CA71 instance is defined with NCF support. The entry in the NCF table that has
UCC7ID=78, is first in the table.
CA71 ADD NCF(78)
NOSVC
Applicable Statement: GLOBAL REFRESH
GLOBAL REFRESH processing reloads routines loaded by a previous GLOBAL INIT or GLOBAL INITC.
These routines include the SMF exits and the SVC modules. If you want to reload system routines
without reinitializing the CA Workload Automation CA 7® Edition SVC, use the NOSVC parameter.
Example:
In this example, CAIRIM reloads the CA Workload Automation CA 7® Edition SMF exits, U7SVC,
SASSSVCA, SASSXSEC, and other CA Workload Automation CA 7® Edition interface routines. The CA
Workload Automation CA 7® Edition SVC is not reinitialized and ICOM does not require recycling.
GLOBAL REFRESH NOSVC
08-Feb-2018 441/722
In this example, CAIRIM reloads the interface routines listed in the previous example and also
reinitializes the CA Workload Automation CA 7® Edition SVC. To avoid abends, terminate all ICOMs on
the LPAR before executing the GLOBAL REFRESH. Restart all ICOMs once CAIRIM processing is
complete.
GLOBAL REFRESH
SMF
Length: 2 - 11 characters
Allowable values: Value must be a list of the following values: 14, 15, 26, and 64. The list must be
blank delimited.
Default: If the instance is CA71, the default is SMF(15 26). The default for all other instances is SMF
(15).
Use this parameter to declare the types of SMF records to collect for this instance. If you want to
collect none of these SMF record types, specify SMF(NONE).
Example:
In this example, the CA73 instance is updated to collect SMF type 15, 26, and 64 records.
CA73 UPD SMF(15 26 64)
SMFO
Length/format: 1 character.
Allowable values: Value must be one of the following: 0-7, T.
Default: SMFO(7)
SASSUJV stores a 1-byte tracking instance identifier in the SMF common area if a CA Workload
Automation CA 7® Edition JOB statement indicator is detected on the JOB statement. SMF propagates
this identifier to other SMF records that CA Workload Automation CA 7® Edition monitors during job
tracking.
This keyword is used to declare the location in the SMF common area where the CA Workload
Automation CA 7® Edition SMF indicator is stored. If the userid field of the SMF common area is to be
used, specify the offset in that area (0-7) where the indicator can be stored. If the reader time field is
to be used, specify SMFO(T).
If the reader time field is to be used, you must also declare any SMF records not generated by IBM
that use the SMF standard header. This lets CA Workload Automation CA 7® Edition remove the CA
Workload Automation CA 7® Edition SMF indicator from these records. The restored records are
listed using the RCA parameter on the GLOBAL INIT statement. In the following example, record types
188 and 190 are identified to CA Workload Automation CA 7® Edition:
GLOBAL INIT SMFO(T) RCA(188 190)
08-Feb-2018 442/722
GLOBAL INIT SMFO(T) RCA(188 190)
The INIT RCA keyword accepts only four values. However, RCA keyword is supported on the GLOBAL
UPDATE statement where additional records can be declared. This is illustrated in the following
example:
GLOBAL INIT SMFO(T) RCA(188 190 191 192)
GLOBAL UPDATE RCA(193 194 195 196)
GLOBAL UPDATE RCA(197)
Use this keyword if the default SMF indicator location SMFO(7) is not suitable for your installation.
Example:
In this example, the CA Workload Automation CA 7® Edition system environment is initialized so that
the SMF indicator is stored in the first byte of the userid field in the SMF common area.
GLOBAL INIT SVC(168) SMFO(0)
SVC
Length/format: 3 decimal characters.
Allowable values: The value specifies the number of the SVC CA Workload Automation CA 7® Edition
uses. The name must conform to rules for type 3/4 SVCs.
Default: SVC(167)
Use this keyword if the default SVC number (167) is not suitable for your installation.
Example:
In this example, the CA Workload Automation CA 7® Edition system environment associates the CA
Workload Automation CA 7® Edition SVC routine with SVC number 168.
GLOBAL INIT SVC(168)
SVDSNCHK
Allowable values: SVDSNCHK(Y) and SVDSNCHK(N)
Default: SVDSNCHK(N)
When coded on the GLOBAL INIT statement, the SVDSNCHK keyword sets the default value of
SVDSNCHK for all tracking instances on the LPAR.
This option is examined when U7SVC is used with the D= parameter.
If the value of SVDSNCHK for a given instance is Y, U7SVC attempts to determine if the extracted ID
has CREATE authorization for the data set specified on the D=. If the extracted ID does have
authorization, the D= command is passed to CA Workload Automation CA 7® Edition for processing.
08-Feb-2018 443/722
Note: For more information about SVDSNCHK, see the Securing topics.
TRLBLK
Allowable values: TRLBK(Y) and TRLBLK(N)
Default: TRLBLK(Y)
Do not code TRLBLK(N) unless instructed to do so by CA Support.
When coded on the GLOBAL INIT statement, the TRLBLK keyword sets the default value of TRLBLK for
all tracking instances on the LPAR.
If the value of TRLBLK for a given instance is N, trailer blocking is not used.
TSVC
Length/format: 3 decimal characters.
Allowable values: The value specifies the number of the SVC that CA Workload Automation CA 7®
Edition uses. The name must conform to rules for type 3/4 SVCs.
Default: None
Applicable statements: GLOBAL INITC
Use this keyword if you intend to run a pre-r11 "test" copy of CA Workload Automation CA 7® Edition
when the current system environment is in compatibility mode.
Example:
In this example, the CA Workload Automation CA 7® Edition system environment is initialized in

compatibility mode. The SVC that is for the "test" copy of CA Workload Automation CA 7® Edition is
222.
GLOBAL INITC TSVC(222)
XDSN
Allowable values: Value must conform to rules governing load module names. If an External Data Set
Tracking Criteria Table was previously assigned to this instance, XDSN(*) indicates that the instance
no longer supports external data set tracking.
Default: None.
Use this parameter to assign an External Data Set Tracking Criteria Table (see page 452) to the
08-Feb-2018 444/722
Use this parameter to assign an External Data Set Tracking Criteria Table (see page 452) to the
instance.
XJOB
Allowable values: Value must conform to rules governing load module names. If an External Task
Filter Table was previously assigned to this instance, XJOB(*) indicates that the instance no longer
supports external job tracking.
Default: None.
Use this parameter to assign an External Task Filter Table (see page 452) to the instance.
XU83
Allowable values: Value must conform to rules governing load module names. If an SMF Type 14/15
Record Exclusion/Inclusion Table (https://wiki.ca.com/pages/viewpage.action?pageId=134844883) was
previously assigned to this instance, XU83(*) indicates that the instance no longer supports
customized SMF type 14/15 record selection.
Default: None.
Use this parameter to assign an SMF Type 14/15 Record Exclusion/Inclusion Table to the instance.
Examples of Configuring the System Environment

These examples illustrate the use of CAIRIM in typical system configuration tasks.
Initialize the System Environment After an IPL (see page 446)

Add a Tracking Instance (see page 446)
Update a Tracking Instance (see page 446)
Update the System Environment Defaults for Tracking Instances (see page 446)
Update the System Environment IBM Health Checker Interface (see page 446)
Add the Second Tracking Instance (see page 447)
Remove a Tracking Instance (see page 447)
Remove the System Environment (see page 447)
Refresh System Environment Modules (see page 447)
Refresh NCF Node Table (see page 448)
Update a User Table for a Tracking Instance (see page 448)
Reinitialize a Tracking Instance (see page 449)
Add an Alias for a Tracking Instance (see page 449)
Remove an Alias for a Tracking Instance (see page 449)
Enable SMF Type 14 Records for a Tracking Instance (see page 449)
08-Feb-2018 445/722
Disable SMF Type 15 Records for a Tracking Instance (see page 450)
Initialize the System Environment After an IPL

Use this System Configuration File statement to initialize the CA Workload Automation CA 7® Edition
system environment after an IPL:
GLOBAL INIT
Processing for this statement creates the CA-7 subsystem and the IVT. The statement also defines the
SVC and activates the SMF exits. This example contains no keywords to override default values.
CA Workload Automation CA 7® Edition programs that require SVC functions do not execute properly
until you add instances.
Add a Tracking Instance

Use this System Configuration File statement to add a tracking instance for CA71 to the CA Workload
Automation CA 7® Edition system environment:
CA71 ADD
Processing for this statement ensures that the instance is not already active. If the instance is not
active, the instance control block (ICMDSECT) is created using defaults set on the GLOBAL INIT. In the
previous example, the default value for BSUBCHK is N. The value of BSUBCHK for CA71 is N.
Update a Tracking Instance

Use this System Configuration File statement to update tracking instance CA71:
CA71 UPD BSUBCHK(Y)
Processing for this statement verifies that the instance is active. If the instance is active, the instance
control block (ICMDSECT) is updated to use BSUBCHK(Y).
Update the System Environment Defaults for Tracking Instances

Use this System Configuration File statement to update an existing CA Workload Automation CA 7®
Edition system environment:
GLOBAL UPD BSUBCHK(Y)
Processing for this example statement updates the default value for BSUBCHK. This value is the new
default for any instance that is added later. The value of BSUBCHK for CA71 remains unchanged
because it was added before this update.
Update the System Environment IBM Health Checker Interface

Processing for the following statement results in the IBM Health Checker interface being deleted and
added again with a 20-minute interval between checks. If the IBM Health Checker interface was not
active, it is activated. The interval between checks is set to 20 minutes.
GLOBAL UPDATE HEALTHCHECK(20)
08-Feb-2018 446/722
Add the Second Tracking Instance

Use the following System Configuration File statement to add a tracking instance, CA72, to the CA
Workload Automation CA 7® Edition system environment:
CA72 ADD
Processing for this statement verifies that the instance is not already active. If the instance is not
already active, the instance control block (ICMDSECT) is created using defaults set on the GLOBAL
INIT. In the example provided for initializing the system environment after an IPL, the default value
for BSUBCHK is N. But this value was changed in updating the system environment defaults for
tracking instances. Thus, the value of BSUBCHK for CA72 is Y.
Remove a Tracking Instance

Use this System Configuration File statement to remove a tracking instance, CA72, from the system
environment:
CA72 DEL
Processing for this statement verifies that the instance is active. If the instance is not active, an error
message is issued. Processing terminates. If the instance can be deleted, the instance control block
(ICMDSECT) is marked inactive. This instance is unavailable for use by CA Workload Automation CA 7®
Edition programs.
Remove the System Environment

Use this System Configuration File statement to remove the current system environment:
GLOBAL DELETE ALL
Processing for this statement deletes all currently active instances. When all instances are deleted,
the association between the CA Workload Automation CA 7® Edition SVC routines and the SVC
number reserved for use by CA Workload Automation CA 7® Edition is removed. The CA Workload
Automation CA 7® Edition SMF exits are deactivated, and the IVT is marked inactive. No tracking
instances are available for use by CA Workload Automation CA 7® Edition programs after the GLOBAL
DELETE ALL.
Note: This process causes a CAIRIM message of CAS9140E indicating a return code of 4.
Refresh System Environment Modules

Use this System Configuration File statement to refresh copies of system environment modules:
GLOBAL REFRESH
Processing for this statement fetches new copies of system modules including the SVC and SMF exits.
New copies of other commonly used modules such as the U7SVC are loaded into LPA.
REFRESH only loads new copies of system modules. Options currently set for an instance (from the
CA7n statements) are not modified.
08-Feb-2018 447/722
Note: GLOBAL REFRESH does not load a new copy of the UCC7NODE module. To refresh
the UCC7NODE module, update the CA71 instance with the appropriate NCF keyword
value.
Refresh NCF Node Table

Use this System Configuration File statement to refresh your NCF node table:
CA71 UPD NCF(Y)
When this statement is processed, the entry for the local node is made the first entry in the table.
A node other than the local node can appear as the first entry in the table. Specify the ID of that node
in the NCF keyword as the following example illustrates:
CA71 UPD NCF(03)
For more information, see the NCF keyword.
Update a User Table for a Tracking Instance

In this example, assume that CAIRIM has run successfully with the following statements:
GLOBAL INIT SMFO(T) SVC(222)
CA71 ADD BSUBCHK(Y) ALIAS(SYS1)
CA72 ADD ALIAS(SYST)
In this example, the CA Workload Automation CA 7® Edition system environment has been initialized
to use SVC 222. The location of the CA Workload Automation CA 7® Edition SMF indicator is the
reader time field. The default value for BSUBCHK is implied: BSUBCHK(N).
Two instances were added. CA71 was added with an alias of SYS1 and overrode environment default
for BSUBCHK by setting BSUBCHK(Y). The CA72 instance was added with an alias of SYST and the
environment default of BSUBCHK(N).
Assume that CAIRIM runs again with the following System Configuration File statement as the only
input:
CA72 UPDATE XJOB(MYXJOB)
This input verifies that the MYJOB module is suitable for use as an External Task Filter Table and
makes it available for use by SASSU84.
If you use a different module, for example, YOURJOB, resubmit CAIRIM with the following input:
CA72 UPDATE XJOB(YOURJOB)
This input verifies that YOURJOB is suitable for use as an External Task Filter Table and makes it
available for use by SASSU84.
If the external task tracking is no longer needed, run CAIRIM with the following input:
CA72 UPDATE XJOB(*)
This input signals that external task tracking is no longer in effect for this instance.
08-Feb-2018 448/722
Reinitialize a Tracking Instance

GLOBAL INIT
CA71 ADD
In this example, the system environment is initialized. One instance is available: CA71. Now, CAIRIM is
executed with the following System Configuration File statements:
CA71 DEL
CA71 ADD
This input results in the creation of a new instance control block (ICMDSECT), thus reinitializing the
instance.
Tracking data for this instance that was not processed before the DELETE can be lost.
Add an Alias for a Tracking Instance

GLOBAL INIT
CA71 ADD
In this example, the system environment is initialized. One instance is available: CA71.
CAIRIM is executed with the following System Configuration File statement:

CA71 UPDATE ALIAS(SYSX)
The CA71 instance is now accessible from CA Workload Automation CA 7® Edition programs using the
name SYSX.
Remove an Alias for a Tracking Instance

GLOBAL INIT
CA71 ADD ALIAS(SYST)
In this example, the system environment is initialized. One instance is available: CA71. The CA71
instance has an alias of SYST.
CAIRIM is executed with the following System Configuration File statement:

CA71 UPDATE ALIAS(*)
The CA71 instance is no longer accessible from CA Workload Automation CA 7® Edition programs
using the name SYST.
Enable SMF Type 14 Records for a Tracking Instance

GLOBAL INIT
CA71 ADD
In this example, the CA Workload Automation CA 7® Edition system environment is initialized. One
08-Feb-2018 449/722
In this example, the CA Workload Automation CA 7® Edition system environment is initialized. One
instance is available: CA71. The installation defaults in effect for the CA71 ADD are SMF(15 26).
To enable collection of SMF type 14 records in addition to types 15 and 26, each record type must
appear in the list as in the following System Configuration File statements:
CA71 UPDATE SMF(14 15 26)
After CAIRIM successfully processes this statement, the CA71 instance now extracts data from SMF
type 14 records.
Note: Because collection of SMF type 14 records can greatly increase overhead, we do not
recommend enabling SMF type 14 records.
Enable SMF Type 26 Records for a Tracking Instance

GLOBAL INIT
CA71 ADD SMF(15)
CA72 ADD SMF(15)
CA73 ADD SMF(15)
In this example, the system environment is initialized. The following instances are available: CA71,
CA72, and CA73. Each instance extracts information from type 15 SMF records.
The following System Configuration File statement executes CAIRIM:

CA72 UPDATE SMF(15 26)
After CAIRIM successfully processes this statement, SMF 15 and 26 records are processed for the
CA72 instance. Options for the other instances are unchanged.
Note: Because CA Workload Automation CA 7® Edition relies on data from SMF type 15
records for requirement monitoring, we do not recommend disabling SMF type 15 records.
Disable SMF Type 15 Records for a Tracking Instance

In this example, assume that CAIRIM has already run successfully with the following statements:
GLOBAL INIT
CA71 ADD SMF(15 26)
CA72 ADD SMF(15 26)
CA73 ADD SMF(15 26)
In this example, the system environment is initialized. The following instances are available: CA71,
CA72, and CA73. Each instance extracts information from type 15 and 26 SMF records.
The following System Configuration File statement executes CAIRIM:

CA72 UPDATE SMF(26)
08-Feb-2018 450/722
After CAIRIM successfully processes this statement, only SMF 26 records are processed for the CA72
instance. Options for the other instances are unchanged.
CAIENF Events
CAIENF can generate notifications for the following events:
Browse Messages Using CAIENF (see page 451)

Job Completions Using CAIENF (see page 451)
Log Records Using CAIENF (see page 452)
Browse Messages Using CAIENF

The CAIENF events can be generated for messages that are sent to the CA Workload Automation CA
7® Edition browse data set. Applications running outside the CA Workload Automation CA 7® Edition
address space can be notified of these messages through CAIENF. CAIENF only generates these
events when you add the CAL2DCM1 module to the CAIENF database.
The CAL2DCM1 module describes the CA Workload Automation CA 7® Edition browse message event
(CA7BRWSE) and the message text data element (CA7TEXT) to CAIENF. To add this module to the
CAIENF database, see member AL2ENF12 in the sample options library (CAL2OPTN).
Some other CA Technologies products like CA Opera™ and CA 7 Workload Automation Smart Console
Option use the CA Workload Automation CA 7® Edition browse event. Your CAIENF database
sometimes already contains the member.
Note: For more information about displaying the contents of CAIENF event records, see
Administrating at CA Common Services (https://docops.ca.com/ccszos).
Job Completions Using CAIENF

CAIENF events are created for CA Workload Automation CA 7® Edition job completions. Applications
running outside the CA Workload Automation CA 7® Edition address space can be notified through
CAIENF of the completion of CA Workload Automation CA 7® Edition submitted jobs.
CAIENF does not recognize these events unless you add the CAL2DCM0 module to the CAIENF
database. The CAL2DCM0 module describes the CA Workload Automation CA 7® Edition job
completion event for CAIENF. To add this module to the CAIENF database, see member AL2ENF12 in
the sample options library (CAL2OPTN).
When this process is complete, the CA Workload Automation CA 7® Edition job completion event is
identified to CAIENF as the L2JOBCMP event.
Note: For more information about displaying the contents of CAIENF event records such as
L2JOBCMP, see Administrating at CA Common Services (https://docops.ca.com/ccszos).
08-Feb-2018 451/722
Log Records Using CAIENF

CAIENF events can be generated for a subset of CA Workload Automation CA 7® Edition log
messages. These events are known as CA7LOG events. The interested applications can listen for
CA7LOG events using CAIENF. One such application is Jobflow Monitor, which uses CA7LOG events to
track workload activity in CA Workload Automation CA 7 Edition.
To generate these events, do each of the following actions:
Specify JFM=Y on the OPTIONS statement in the initialization file.
Add the CAL2DCM3 module to the CAIENF database.
See member AL2ENF12 in the sample options library (CAL2OPTN) for information about adding this
module to the CAIENF database.
Note: For more information about CAIENF, see the CA Common Services for z/OS
documentation.
External Tracking and Filtering

These articles explain tracking external z/OS tasks, tracking external data sets, and filtering the data
set records that CA Workload Automation CA 7 Edition processes. Use the left navigation pane to
view these articles.
Track External Tasks

CA Workload Automation CA 7® Edition can track z/OS batch jobs and started tasks that are
submitted outside of the product. The term task refers to a batch job or started task. This definition
does not include TSO users. The tracking is selective based on entries in two tables that are coded to
specify the task names to track. This tracking is only available for CPUs that share the
communications data set. In an NCF environment, the external tracking is only available for NCF1
sites. An NCF1 site can track only external jobs that execute at its own site, not at another NCF1 site.
To track external tasks, code two tables.
The first table is the External Task Filter Table, which contains criteria that identify the tasks to
track. The client determines the module name, which is declared using the XJOB keyword in the
System Configuration File. Supply an XJOB parameter naming an External Task Filter Table for
each tracking instance that requires external task tracking. This table is loaded into CSA when
CAIRIM executes the product initialization routine.
08-Feb-2018 452/722
The second table resides in the private area of the CA Workload Automation CA 7® Edition
address space. When an SMF job initiation record is received for an external task, this table
creates the queue record representing the external task. Name this table SASSEXTT.
When an external task is tracked, the product is monitoring task start, step terminations, and task
termination. The data set information is not collected. A record in the CA Workload Automation CA
7® Edition queues, dynamically added when the product gets the task start SMF record, represents
an external task. When the task terminates, it is posted to the product run log and, optionally, in the
database.
External tasks are not necessarily defined to the product database. However, if these tasks are
defined to the product, they can be used for triggering and predecessor relationships, except for
negative dependencies that cannot be used.
Usage Notes
Tracking external tasks can impact product performance due to the additional SMF records that are
processed.
The active workload (queues) size can require a larger allocation to accommodate the external work
that is represented.
If an external task terminates unsuccessfully, it remains in the CA Workload Automation CA 7®

Edition request queue with a restart status. Restart the task outside of the product. Cancel the CA
Workload Automation CA 7® Edition queue record. If you want the task to be viewed as successfully
completed, use the top-line RESTART command to force complete the job.
The external tasks are not included in workload balancing, even though they are in the active queue.
The external tasks cannot be used for negative dependencies.
This facility cannot track cross-platform jobs (XPJOB and AGJOB) because their execution occurs on a
different platform.
Define External Tasks to Track

The active workload for a CA Workload Automation CA 7® Edition tracking instance includes only
those tasks that the instance submits. A task that the instance is not submitting is considered external
to that instance. However, external tasks can be included in the active workload when an External
Task Filter Table has been activated for that instance. SASSU84 uses this table when it is determined
that a tracking instance is not submitting the task. If the table indicates to select the task, SASSU84
collects SMF task initiation, step termination, and task termination data for the task. SASSU84
forwards it to the product to include in the active workload.
This table is activated for an instance using the XJOB parameter in the System Configuration File.
Note: NCF2 sites cannot track external work. Do not activate an External Task Filter Table
for an NCF2 site. An NCF1 site can track only those external tasks that execute on that site.
After you code the module, assemble and link-edit it. The module must reside on a library that is
08-Feb-2018 453/722
After you code the module, assemble and link-edit it. The module must reside on a library that is
accessible to the CAS9 procedure (CAIRIM). Identify the table name using the XJOB keyword in the
System Configuration File. CAIRIM uses the file to initialize or update the product configuration. Code
entries in this table using the following format:
column
10 16
| |
DC CL8'xxxxxxxx'
CL8'xxxxxxxx'
Indicates a required task name that can be from one- to eight-alphanumeric characters. This
name can also include masking characters such as a question mark to mask a single character or
an asterisk to terminate a generic specification.
For a sample External Task Filter Table module, see AL2UM34(M) in the Options library (CAL2OPTN).
External Task Filter Table Example

column
10 16
| |
TITLE 'CA WORKLOAD AUTOMATION SE EXTERNAL TASK FILTER TABLE'
SPACE 1
SASSEXTL START
DC CL8'TESTJOB*'
DC CL8'TEST???X'
DC CL8'TESTSTC '
TABEND DC 4X'FF' END OF TABLE INDICATOR (REQUIRED)
END
Note: Define each entry in the table as CL8 (padded with blanks if necessary). Place an x'FF'
terminator as the last entry.
If the table is coded as in the preceding example and named on the XJOB keyword of the System
Configuration File, SASSU84 collects SMF data for tasks with the criteria:
First seven characters of name are equal to TESTJOB

OR
First four characters of name are equal to TEST and eighth character equal to X
OR
Task name equal to TESTSTC
Define the Model Queue Records

The module SASSEXTT defines a table of model queue records that are used for external tasks. If this
load module does not exist, the product does not post the CA Workload Automation CA 7® Edition
queues for external jobs, even if the SMF data is being collected.
08-Feb-2018 454/722
When the task start SMF record is received, the product recognizes an externally submitted task and
adds a record to the active queue for the task. If a record exists in the active or ready queue for this
task, an error message is issued to the master station and also as a WTO. The new queue record is
not added.
When the product adds a record to the active queue for an external task, it searches the SASSEXTT
module for a model that specifies the information that is used for that task. The product uses the
FIRST entry in SASSEXTT that matches the task name (not necessarily the best match or most
specific). If the SASSEXTT module does not contain a match, the product builds the queue record
using all default values.
$L2EXTT Macro
This macro is used in the SASSEXTT module to define the model queue records used when tracking
external tasks.
This macro has the following format:

$L2EXTT JOB=taskname [,CC={0|condcode}]
[,LTERM={MASTER|lterm}]
[,MAINID={ALL|mainid}]
[,PROMPT={Y|N}]
[,RO=ro]
[,RQMT={N|Y}]
[,SECID=userid]
[,SCHID={0|schid}]
[,SYS=systemname]
[,TRIG={N|Y}]
[,UID={0|uid}]
JOB
Indicates a required task name specification. This name is used to match a model queue record
with an external task name. The name can be specific, generic, or masked using a question mark.
If you are using masking or generics, code the $L2EXTT calls in the order of most specific to least
specific. The product uses the first entry in the table that matches an external task name as the
model queue record.
Limits: 1 to 8 alphanumeric characters (can end with an asterisk or can use a question mark to
mask a character).
Examples:
$L2EXTT JOB=ABC*
All tasks whose first three characters are ABC.
$L2EXTT JOB=*
All tasks (coded last in the table if used).
$L2EXTT JOB=A?C
Tasks whose first letter is A, third letter is C and have any valid character for the second letter
(only includes three-character task names).
$L2EXTT JOB=A?C*
Same as previous entry but also includes tasks with more than three-character names.
08-Feb-2018 455/722
CC
(Optional) Used with RO to define the job-level condition code that is used to determine whether
a task executes successfully.
Default: 0
LTERM
(Optional) Routes messages about this job to this logical terminal name.
Default: MASTER
MAINID
(Optional) This parameter does not control where the task is executing. However it can be
propagated to any triggered jobs when TRIG=Y is coded. Specify SY n or /SYn where n is the
system number and / indicates not this system.
Default: ALL
PROMPT
(Optional) Specifies whether to issue prompt messages when this task is late.
Default: Y
Limits: N or Y
RO
(Optional) Indicates the relational operator of the condition code. This pair of parameters (CC and
RO) tests the highest condition code that a task generates. This test is for internal use by CA
Workload Automation CA 7® Edition only. The value simply tells the product what action to take
after the task completes.
Limits: two alpha characters: EQ, LT, GT, GE, LE, NE, or IG
RQMT
(Optional) Specifies whether this task can satisfy requirements for a job on the product. If Y is
specified, the successful completion of this task posts jobs currently in the product request queue
waiting for the task. Also, if the task is defined to the product database, the successful completion
updates the database information for the task.
Default: N
Limits: N or Y
SECID
(Optional) Indicates the security user ID associated with the task. This ID is available to be
propagated to triggered jobs. This keyword has no effect unless external security is used with
SUBUID.
Default: Blanks
SCHID
(Optional) Indicates the schedule ID value for the queue record.
Default: 0
08-Feb-2018 456/722
Note: If this value is set to zero, the schedule ID of the active queue records is set
according to the global external job schedule ID parameter. The EXTSCHID keyword on the
OPTIONS statement in the initialization file sets this global parameter.
SYS
(Optional) Indicates the system name for the queue record.
Default: Blanks
TRIG
(Optional) Specifies whether this task can trigger work on the product. If Y is specified, also
specify RQMT=Y.
Default: N
Limits: N or Y
UID
(Optional) Specifies the product security identification.
Default: 0 (No UID security protection)
Define the SASSEXTT Module

This module comprises one or more $L2EXTT macro calls. After the module is coded, assemble and
link it. Place this module in the STEPLIB of the CA 7 Central Control System (CA7ONL) or in the linklist.
If the size of the module exceeds 32 KB, include an APPLCTN statement in the initialization file. The
format is as follows:
APPLCTN,NAME=SASSEXTT,ATTR=PERM
Place this statement before the APPLCTN statement for SASSPROG.
For a sample SASSEXTT module in SMP/E format, see AL2UM35 (M) in the Options library
(CAL2OPTN).
Warning! With Version 12.0, this module must be reassembled or relinked using the
current macros library. If the module is not using the current macros, an error message is
issued during CA 7 initialization.
SASSEXTT Example
column
10 16 72
| | |

TITLE 'EXTERNAL JOBS MODEL QUEUE HEADER RECORDS'
SASSEXTT START
PRINT ON
$L2EXTT JOB=TESTEXT1,SYS=TEST,SCHID=3,RQMT=Y,TRIG=Y, X
CC=0,RO=LT
$L2EXTT JOB=TEST???1,SYS=TEST,SCHID=20,MAINID=SY1,RQMT=Y, X
CC=0,RO=LT
$L2EXTT JOB=TEST*,SCHID=5,CC=0,RO=LT
08-Feb-2018 457/722
$L2EXTT JOB=TEST*,SCHID=5,CC=0,RO=LT
$L2EXTT JOB=*,SYS=TEST
TABEND DC 2X'FF' END-OF-TABLE MARKER **REQUIRED**
END
Note: An x'FF' terminator must be the last entry.
Track External Data Sets

CA Workload Automation CA 7® Edition can track SMF data for data sets that tasks not submitted by
CA Workload Automation CA 7® Edition access. The tracking process examines SMF type-15 and -64
records. The SMF record types used to track external data sets are specified during the CAIRIM
initialization. The tracking process compares the job name and data set name information with the
External Data Set Tracking Criteria Table. The table is created at each site.
The CA Workload Automation CA 7® Edition SMF collection process uses the External Data Set
Tracking Criteria Table to determine which external tasks are tracked. The tracking is done by
capturing the SMF type-15 (x'0F') record that is generated when a data set is closed after being
opened for output. For VSAM data sets, an SMF type-64 (x'40') record is generated when a data set is
closed after being opened for output. Data set records can be captured for batch jobs and started
tasks and TSO users. When a record is captured, the product attempts to associate it with a job in the
active queue. If the job that created the SMF record does not exist, the product processes the data
set as a POST AT CREATE TIME data set and updates the database with the date and time. If the
creating job is in the active queue, the data set is stored with that job. The database is updated when
the job completes.
External data sets must be defined to the database for use as requirements for jobs or for data set
triggers.
The name of the External Data Set Tracking Criteria Table is declared using the XDSN keyword in the
System Configuration File. Supply an XDSN parameter naming an External Data Set Tracking Criteria
Table for each tracking instance that requires external data set tracking. The module must reside on a
library that is accessible to the CAS9 procedure (CAIRIM). This table is loaded into CSA when CAIRIM
executes the product initialization routine.
Usage Notes
Tracking external data sets can impact product performance due to the additional SMF records that
are processed.
If the external data set is associated with an external task that is in the active queue, the model
queue record for the job must have RQMT=Y specified in the SASSEXTT module. If this parameter is
not specified, the data set information is not posted to the database.
External data set tracking is available only for LPARs that share the communications data set. In an
NCF environment, this tracking is available only for the local NCF1 site.
External data sets must be physical sequential, permanent files (not temporary).
08-Feb-2018 458/722
For a system (LPAR) that has a time where the SMF activity that is related to CA Workload
Automation CA 7® Edition submitted jobs is low, the external data set postings to the product can be
delayed. The length of the delay depends upon the product SMF activity through ICOM. This delay
includes (but is not limited to) when a CA Workload Automation CA 7® Edition submitted job starts
(or ends or has a step term) or any job that goes through a JES purge on the system where the data
set was created.
A data set cannot be externally tracked when a job that any CA Workload Automation CA 7® Edition
submits creates the data set, unless the CAIRIM process uses EXTTRK7( y).
External data set tracking does not apply to cross-platform jobs (XPJOB and AGJOB).
Define External Data Sets to Track

This table defines the criteria that SASSU83 uses to determine which external data sets are tracked.
The CAIRIM initialization for CA Workload Automation CA 7® Edition (procedure CAS9) loads the
table. Assume that SASSU83 finds a match in the External Data Set Tracking Criteria Table. The SMF
type-15 record, type-64 record, or both, are collected for the data set, if that type was specified
during the CAIRIM process.
Note: External data sets cannot be tracked at NCF2 sites. Therefore, activate no External
Data Set Tracking Criteria Table at those sites. Also, an NCF1 site can track only external
data sets that are created at that site.
$L2XDSN Macro
This macro is used in the External Data Set Tracking Criteria Table to define the filtering criteria for
external data sets.

$L2XDSN [JOB={*|taskname}][,DSN={*|dsname}]
JOB
(Optional) Indicates a task name specification. This name is used to match the task name in the
SMF record. The name can be specific, generic, or masked using a question mark.
Default: *
Limits: 1 to 8 alphanumeric characters (can be terminated with an asterisk or specify a question
mark to mask a character)
DSN
(Optional) Defines the data set name. This name is used to match the data set name in the SMF
record. The name can be specific, generic, or masked using a question mark.
Default: *
Limits: 1 to 44 alphanumeric characters with a question mark used to mask a character, or use
multiple question marks to mask multiple characters. You can use an asterisk to terminate the
matching. Thus, only one asterisk is allowed. It must be last if used.For GDG data sets, use a
generic specification so that any new creation can be matched.
08-Feb-2018 459/722
Define the External Data Set Tracking Criteria Table

This table comprises one or more $L2XDSN macro calls. After the module is coded, it must be
assembled and linked. The module must be accessible to the CAIRIM procedure and identified using
the XDSN parameter in the System Configuration File.
For a sample SMP/E USERMOD to create the table, see AL2UM37 in the Options library (CAL2OPTN).
External Data Set Tracking Example

column
10 16
| |

TITLE 'EXTERNAL DATA SET TRACKING CRITERIA'
SASSXDSN START
PRINT ON
$L2XDSN JOB=ABCDE
$L2XDSN DSN=A.B.C
$L2XDSN JOB=STC1,DSN=TRANSMIT
$L2XDSN DSN=PROD.D???.DATA
END
Note: If you are tracking external jobs/tasks and also tracking data sets in those jobs/tasks,
specify RQMT=Y and TRIG=Y in the SASSEXTT definitions for those jobs/tasks.
$L2XDSN JOB=ABCDE
All data set SMF 15/64 records for job ABCDE.

$L2XDSN DSN=A.B.C
All data set SMF 15/64 records for A.B.C, regardless of the task that generates the records.
$L2XDSN JOB=STC1,DSN=TRANSMIT.*
Data set SMF 15/64 records for data sets that have a high-level node of TRANSMIT and are generated
by task STC1.
$L2XDSN DSN=PROD.D???.DATA
Data set SMF 15/64 records for data sets that match this name, with any character in the positions of
the question marks, regardless of the task that generates the records.
SMF Type 14/15/64 Record Filter - SASSXU83

The SMF Type 14/15/64 Record Filter is a table. The U83 SMF interface can use the table to
determine which type-14, type-15, and type-64 records to pass to the address space through the
communications data set. The table can contain specific or generic entries for job names, ddnames,
data set names, or all. The default usage of the table is to identify those 14/15/64 records to exclude
from processing. However, you can override this exclusion to indicate that the table is inclusive.
Inclusive here means to process only those 14/15/64 records that match an entry in the table. The
entries in the filter table are created using the $L2XU83 macro.
Usage Notes (see page 461)
08-Feb-2018 460/722
Usage Notes (see page 461)

$L2XU83 Macro (see page 461)
Define the SMF Type 14/15/64 Record Filter (see page 462)
SMF Type 14/15/64 Record Filter Example (see page 462)
Usage Notes
If the SMF type-15 record is not passed to CA Workload Automation CA 7® Edition, data set triggering
cannot occur for the data set.
If the SMF-type 64 record is not passed to CA Workload Automation CA 7® Edition, data set triggering
cannot occur for the VSAM data set.
Reducing the volume of SMF data passed to CA Workload Automation CA 7® Edition can significantly
improve overall performance.
If you want to suppress all type-14, type-15, and/or -64 records, you can do so by modifying the
instance control block (ICMDSECT) with CAIRIM. By default, the CA Workload Automation CA 7®
Edition SMF exits collect SMF type-15 records but do not collect SMF type-14 and type-64 records.
More information:
Disable SMF Type 15 Records for a Tracking Instance (https://wiki.ca.com/display/CWAC7E

/Examples+of+Configuring+the+System+Environment#ExamplesofConfiguringtheSystemEnvironment-
DisableSMFType15RecordsforaTrackingInstance)
SMF Processing (https://wiki.ca.com/display/CWAC7E/SMF+Processing)
$L2XU83 Macro
The $L2XU83 macro creates the entries in the SMF Type 14/15/64 filter table.
$L2XU83 [,OPT={EXCLUDE|INCLUDE}]
[,JOB={jobname|jobname*}]
[,DD={ddname|ddname*}]
[,DSN={dsname|dsname*}]
OPT
Indicates whether to process the SMF Type 14/15/64 Record Filter as an inclusion or exclusion
table. If OPT is coded, it must be the first occurrence of $L2XU83 in the module. If INCLUDE is
specified, only the SMF type-14/15/64 records that match criteria in the table are collected and
passed to CA Workload Automation CA 7® Edition.
Default: EXCLUDE
Limits: EXCLUDE or INCLUDE
Required: No (mutually exclusive with other parameters)
JOB
Specifies a job name pattern to match with SMF type-14/15/64 records.
Limits: 1 to 8 alphanumeric characters (can include ?, *, or both mask characters)
08-Feb-2018 461/722
DD
Specifies a ddname pattern to match with SMF type-14/15/64 records.
DSN
Specifies a data set name pattern to match with SMF type-14/15/64 records.
Define the SMF Type 14/15/64 Record Filter

The filter module comprises one or more $L2XU83 macro calls. After the module is coded, it must be
assembled and linked. See the CA Workload Automation CA 7® Edition JCL library (CAL2JCL) for
sample JCL to receive and apply SASSXU83 to CA Workload Automation CA 7® Edition as a USERMOD.
See member AL2$$IDX that contains an index of the members in both CAL2JCL and CAL2OPTN.
The SMF Type 14/15/64 Record Filter module must be accessible to CAIRIM when CA Workload
Automation CA 7® Edition is initialized by the CAS9 procedure. For example, it can be placed in the
same library containing the SASSU83 module that CAIRIM uses.
If you want a CA Workload Automation CA 7® Edition instance to filter SMF type 14/15/64 records,
identify the filter module when CAIRIM is used to add the instance. You can also refresh the filter
module by identifying the module when the instance is updated. To identify the module, supply the
name of the module using the XU83 keyword as in the following example:
CA71 UPD XU83(SASSXU83)
CA76 ADD XU83(SYS2FLTR)
See member AL2UM33(M) in the Sample Options library (CAL2OPTN) to generate an SMF 14/15/64
filter table.
SMF Type 14/15/64 Record Filter Example

This example illustrates the use of the XU83 keyword to refresh the filter module on an already
existing instance (in this example CA71). The example also illustrates the use of the keyword to
identify the filter module when adding an instance (CA76 in this example).
In the following example, the name of the filter is SASSXU83.

column
10 16 72
| | |

TITLE 'CA WORKLOAD AUTOMATION SE SMF 14/15/64 FILTER TABLE'
SASSXU83 START
PRINT ON
$L2XU83 OPT=EXCLUDE
$L2XU83 JOB=ABC
$L2XU83 JOB=ABCDE*
$L2XU83 DSN=MY.COMMON.PARMLIB
$L2XU83 DSN=*.???QUE.PROD
END
Pattern Masking Characters

This article explains pattern masking characters and the process to use them.
The JOB=, DD=, and DSN= keywords support mask patterns with wildcard mask characters (?) and
08-Feb-2018 462/722
The JOB=, DD=, and DSN= keywords support mask patterns with wildcard mask characters (?) and
generic mask characters (*). These characters can be used anywhere in the pattern mask. If the
pattern that you specify does not contain any question mark or asterisk mask characters, the target
string has to match the pattern exactly to satisfy the comparison.
The wildcard masks (?) match any single character in the target string. For example, a mask of 'A?C'
matches on 'ABC', 'AXC', 'A7C', but it does not match on 'ACX' or 'AC'. If you want to find any four-
character string that begins with the letter A and ends with the letter C, specify the pattern 'A??C'.
The generic masks (*) match a string of characters of any length (including zero). For example, a mask
of '*ABC' matches on any string that ends with the characters ABC (including 'ABC' with no prefix).
When used with the DSN= keyword, an embedded generic mask only has a scope of the current data
set node. For a data set name that has exactly three nodes where the first is the characters 'ABC' and
the third is the letters 'XYZ'. The generic masks at the end of the pattern have an unlimited scope that
begins with the characters 'ABC.' regardless of the number of nodes. Data sets 'ABC.Z' and 'ABC.W1.
X2.Y3.Z4' would both match the mask.
Note: Use caution when using wildcards and embedded generics in your patterns. Before
you use them, carefully determine what it is you are trying to match. Make the pattern as
simple as possible. If you do not keep this simplicity in mind, you can exclude or include
elements that you did not intend to match on.
Execute and Initialize ICOM

This article explains how to manage the Independent Communications Manager (ICOM). ICOM
performs the functions that are described in System Operations (https://wiki.ca.com/display/CWAC7E
/System+Operations). The main purposes of ICOM include the following items:
Move SVC-captured SMF and trailer data to the communications data set for processing by CA
Workload Automation CA 7® Edition or through XCF for processing by CA Workload Automation
CA 7 Edition.
Optionally, to submit jobs to the host.
ICOM, like CA Workload Automation CA 7 Edition, is activated through JCL. ICOM must be given a
high priority. In a multiple CPU environment, one host CPU has both CA Workload Automation CA
7 Edition and ICOM active. All other CPUs to which CA Workload Automation CA 7 Edition submits
jobs only have ICOM active.
The ICOM task can also optionally track Cross-Platform jobs and events. This tracking is done by
running the Cross-Platform Tracking System (XTRK) as a subtask in the ICOM address space. XTRK can
also execute as a subtask under CA Workload Automation CA 7 Edition, a separate job, or started
task.
ICOM Usage Considerations

The following items are some notes for using ICOM JCL, initialization, and execution of ICOM:
The ddnames in ICOM JCL are fixed except for the variable portion that is indicated in the ddname
08-Feb-2018 463/722
The ddnames in ICOM JCL are fixed except for the variable portion that is indicated in the ddname
of the statement defining the submit data set.
If submit data sets are used, the data set name (in the DD statement that the DD parameter
specifies) must be the same data set name as the name that is coded in the CA Workload
Automation CA 7® Edition execution JCL (pointed to by the DDNAME keyword in the CPU
initialization file statement). Each ICOM has its own submit data set. The JCL must have a
corresponding submit data set, pointed to by a CPU initialization file statement. That is, you have
a CPU statement for each ICOM. Again, this rule is only true when submit data sets are used
instead of the internal reader option. That option is discussed in the following topics.
In a shared spool environment, you can omit the submit data set. In this case, the DD parameter
for ICOM specifies **NONE**.
Initialize ICOM
ICOM must be activated on each CPU to perform automatic monitoring of the CPU jobs and,
optionally, job submission. ICOM, like CA Workload Automation CA 7® Edition, can be run as a batch
job or a started task.
The JCL is generated as part of the SYSGEN process. Refer to member CA07N500 (job) and CA7ICOM
(procedure). The prefix CA07 is sometimes changed based on SYSGEN options. Refer to this member
as you learn about the parameters that require coding.
For nonshared spool environments, establish separate ICOM JCL members for each CPU. Store these
members in libraries accessible to the CPU on which each is to run.
The PARM values on the EXEC statement determine the way ICOM is initialized. The following topics
have descriptions of the PARMs. Then some general notes about ICOM usage follow.
After the initialization, you can change certain parameters and values that are passed to ICOM for the
initialization. Reply to the outstanding WTOR of ICOM, or issue a MODIFY command. The acceptable
replies to the WTOR or MODIFY and their meanings are discussed later in these topics.
We recommend that you read this topic before initializing ICOM. This circumstance is especially true
of the user who has the choice of job submission by ICOM or CA Workload Automation CA 7® Edition.
More Information:
Cross-Platform Tracking (https://wiki.ca.com/display/CWAC7E/Cross-Platform+Tracking)
XTRK Under ICOM (https://wiki.ca.com/display/CWAC7E/XTRK+Under+ICOM)
ICOM Execution PARM Values and DDNames

This article details the following ICOM execution values:
PARM Values (see page 465)

ICOM Execution DDNames (see page 467)
08-Feb-2018 464/722
PARM Values
The PARM data that is specified in the CA7ICOM EXEC statement identifies the host system, the
submit data set for that ICOM, and the type of record collection to perform.
The CA7ICOM JCL procedure has the following symbolic parameters that create the executable
parameter pass to the program:
//CA7ICOM PROC SMFTRL=B,HOST=2,DD='**NONE**',R=512K,
// CA7=',CA7=CA71',X=,
// ARM=',ARM=NO',SSM=',OPSSSM=NO'
The following describes the usage of symbolic parameters from the ICOM execution JCL.
HOST
Identifies the host system and must be one of the following values: 2 for JES2 and 3 for JES 3.
DD
Identifies the submit data set for this ICOM. Value must be one of the following values:
UCC7SUBn
Identifies the name of the DD statement defining the submit data set.
**NONE**
Indicates no submit data set is defined. ICOM does not do the job submission. CA Workload
Automation CA 7® Edition submits the jobs directly to an internal reader.
SMFTRL
Specifies the type of data to collect. The value must be one of the following values:
B
Specifies both SMF and trailer step data is collected. Value is B for a normal execution of
ICOM.
N
Specifies no SMF or trailer step data is collected.
S
Specifies only SMF data is collected.
T
Specifies only trailer step data is collected.
CA7
Specifies the CA Workload Automation CA 7® Edition instance name. The value of CA7= must be ",
CA7=nnnn". Note the preceding comma. Embedded or trailing blanks are not permitted in an alias
name. If omitted, the default is CA71.
If used, the value must be CA7=',CA7=xxxx' where xxxx is one of the following values:
CA7x
Where x is a value from 1 through 8. This name is the true instance name to use.
PROD
08-Feb-2018 465/722
UC07
TEST
Note: The parameter ",TEST=YES" (note comma) is still currently supported.
UCT7
alias
Defines a one- to four-character alias specified at CA Workload Automation CA 7® Edition
resource initialization.
X
Indicates whether to use the Cross-system Coupling Facility (XCF) to send SMF data to CA
Workload Automation CA 7® Edition. If omitted, SMF data is sent through the communications
data set (COMMDS). If used, the value must be in the form X=',XCF= xxxxxx[,XCFGRP=yyyyyyyy]'
where xxxxxx is one of the following values:
NO
Does not use XCF. Uses the COMMDS to send SMF data to CA Workload Automation CA 7®
Edition. NO is the default.
SMF
Uses XCF to send SMF data to CA Workload Automation CA 7® Edition.
NOTIFY
Uses the COMMDS to send SMF data to CA Workload Automation CA 7® Edition, but uses XCF
to notify CA Workload Automation CA 7® Edition that SMF data is waiting in the COMMDS.
This "wakes up" CA Workload Automation CA 7® Edition more frequently to read waiting data.
XCFGRP
Specifies the XCF group name to use for ICOM. If this keyword is omitted, a default XCF group
name is assigned to ICOM. A maximum of eight characters is permitted.
yyyyyyyy
Assigns yyyyyyyy as the XCF group name for ICOM.
Note: All ICOMs (that use XCF) that communicate with an instance of CA Workload
Automation CA 7® Edition must share the same XCF group name.
ARM
Indicates to register the ICOM task with ARM. If used, the value must be ARM=',ARM=YES' to
enable the ARM interface or ARM=',ARM=NO' to disable. If omitted, the default is NO.
08-Feb-2018 466/722
SSM
Indicates the ICOM task to report state changes to CA OPS/MVS® Event Management and
Automation SSM. If used, the value must be SSM=',OPSSSM=YES' to enable the CA OPS/MVS®
Event Management and Automation® SSM interface or SSM=',OPSSSM=NO' to disable. If omitted,
the default is NO.
WLM
Indicates an IBM WLM resource name to associate with ICOM so that requirements can be
defined for jobs or tasks that depend on an active ICOM. If specified, the resource state is set to
ON during ICOM initialization and is set to OFF during ICOM termination.
Add the keyword to the end of the PARM= string and separate it from the preceding parameter
by a comma. The resource name is the 1-character to 16-character name that has been defined in
your IBM WLM policy definitions.
XMONITOR
Specifies the XTRK monitor name. When running XTRK as a subtask under ICOM, this required
parameter is the seven-character monitor name that uniquely identifies each copy of CA
Workload Automation CA 7® Edition whose cross-platform jobs are tracked. The name must
match the MONITOR= value that is used by the CA Workload Automation CA 7® Edition Cross-
Platform Submit jobs to track (CA7TOUNI).
If this parameter is specified, the XCKPT DD statement for the CA Workload Automation CA 7®
Edition Cross-Platform Tracking checkpoint file must be present in the ICOM JCL.
Add the keyword to the end of the PARM= string, and separate it from the preceding parameter
with a comma.
XTRC
Specifies the XTRK trace codes. When running XTRK as a subtask under ICOM, these optional
codes specify the level of diagnostic messages and snaps that XTRK generates. The default is
XTRC=21.
Add the keyword to the end of the PARM= string, and separate it from the preceding parameter
with a comma.
More information:
XCF Group and Member Names (https://wiki.ca.com/display/CWAC7E

/XCF+Group+and+Member+Names)
ICOM Execution DDNames

The following ddnames are associated with ICOM execution:
STEPLIB
Defines the CA Workload Automation CA 7® Edition load module library.
SYSUDUMP
Defines a standard SYSUDUMP output data set.
08-Feb-2018 467/722
UCC7CMDS
Defines the communications data set. The data set is always required. The data set name must be
the same data set name as in the CA Workload Automation CA 7® Edition execution JCL.
UCC7WTR
Defines the internal reader to which JCL submitted by ICOM is written. The SYSOUT=INTRDR entry
provides a symbolic reference to an internal reader in both JES2 and JES3 environments. The
UCC7WTR DD is required whenever ICOM is to perform job submission. If ICOM does not perform
job submission (DD PARM of **NONE**), omit it.
UCC7SUBn
Defines the submit data set that ICOM references. The UCC7SUBn name must match the
corresponding ddname in the initialization file (CPU statement DDNAME). The UCC7SUBn name
must also match the corresponding ddname in the DD parameter of the SASSICOM PARM value.
The UCC7SUBn DD is required whenever ICOM is to perform job submission. If this ICOM does not
perform job submission (the PARM data DD parameter specifies **NONE**), omit it.
XCKPT
Defines the Cross-Platform checkpoint file. This item is required if Cross-Platform Tracking System
(XTRK) is running. Each copy of XTRK must have its own checkpoint file.
XEVENTS
(Optional) Defines the data set containing XTRK rules.
XPRINT
(Optional) Defines the SYSOUT class for XTRK trace messages.
XSNAP
(Optional) Defines the SYSOUT class for XTRK storage snap output.
XCFDS
Defines the XCF data set. This item is required when XCF is used. Each ICOM must have its own
XCFDS.
ICOM WTOR/MODIFY Replies

This article explains Independent Communications Manager (ICOM) WTOR/MODIFY replies. ICOM
must be initialized and active for CA Workload Automation CA 7® Edition to perform automatic job
submission and monitoring of job activity through SMF.
When the ICOM initialization is successfully completed, a WTOR is issued to the operating system
master console. The WTOR can be suppressed by using a DD statement in the ICOM JCL that has a
ddname of NOWTOR (//NOWTOR DD DUMMY). This only does a WTO and not a WTOR and requires
the MODIFY command to communicate with ICOM. The format of this WTOR/WTO is:
CA-7.574 (CA7ICOM) ENTER REQUEST FOR ICOM (CA7x)
This message remains as an outstanding WTOR as long as ICOM is active. It can be used to alter or
terminate an ICOM operation or to inquire into its current state of activity. However, no reply is
required for ICOM to function as specified by its initialization JCL parameters. Alternatively, if ICOM is
a started task, a MODIFY command can be used instead of the WTOR reply.
Replies to ICOMs WTOR (CA-7.574) or MODIFY input can be used to perform the following functions:
08-Feb-2018 468/722
Display ICOM control blocks
Dynamically alter ICOM processing options
Shut down ICOM
WTO messages are issued to the (OS) master console indicating the results of a particular reply to
ICOM's WTOR.
The possible replies to the ICOM WTOR and the MODIFY command are discussed in the remainder of
this topic. WTOs that result from one of these replies are also explained. WTOs that are not a direct
result of a reply to the ICOM WTOR or MODIFY are explained in the messages and codes.
The replies include the following:
STOP
Terminates the ICOM processing. WTOs are issued confirming the tasks were stopped. No new
outstanding CA-7.574 WTOR is issued. (In general, do not issue an OS CANCEL for ICOM.)
D=xxx...x
Displays memory at the location indicated by xxx...x, where xxx...x can be one of the following:
DSECT
Dumps the first X'50' bytes of ICMDSECT (which is memory-resident). A CA-7.576 WTO is
issued to display this information. A new CA-7.574 WTOR is issued following the response.
ICOM
Dumps the first X'40' bytes of SASSICOM. A CA-7.576 WTO is issued to display this
information. A new CA-7.574 WTOR is issued following the response.
STAT
Displays statistics for SMF and trailer and the ddname of the submit data set. A CA-7.575 WTO
is issued to display the information. A new outstanding CA-7.574 is issued following the
response.
The WTO responses to D=STAT are in the following format:
CA-7.575 SMF - aaa(bbb) cccccccc(dddddddd) xxxCA-7.575 TRL - aaa(bbb) cccccccc
(dddddddd) xxxCA-7.575 DDNAME=xxx...x
SVC
Dumps the first X'50' bytes of the first load of the CA Workload Automation CA 7® Edition
SVC. A CA-7.576 WTO is issued. A new CA-7.574 WTOR is issued following the response.
EXTJOB
Displays the entries in the SASSEXTL table that are currently in use. A new outstanding CA-
7.574 is issued following the response.
EXTDSN
Displays the entries in the SASSXDSN table that are currently in use. Message CA-7.585 is
issued for each entry in the table. A new outstanding CA-7.574 is issued following the
response.
08-Feb-2018 469/722
XU83
Displays the entries in the SASSXU83 (INCLUDE/EXCLUDE) table that are currently in use.
Message CA-7.586 is issued for each entry in the table. A new outstanding CA-7.574 is issued
following the response.
In the responses, ttttttt displays as INCLUDE or EXCLUDE.
The WTO responses to D=XU83 are in the following format:
CA-7.586 XU83 ttttttt JOB=jobnameCA-7.586 XU83 ttttttt DD=ddnameCA-7.586 XU83
ttttttt DSN=your.data.set
Note: The following message indicates that the entry in the XU83 table is invalid.
CA-7.586 XU83 TABLE ENTRY INVALID.
DD=ddname
Indicates the ddname of a submit data set to be used for job submission. The ddname must be
defined in JCL of the ICOM. This reply can be required when multiple submit data sets are defined
in the ICOM JCL and it becomes necessary to switch from one to another. If the ddname is being
changed from **none**, the S=SUB command can be used to start job submission.
No WTO response is issued. A new outstanding CA-7.574 WTOR is issued.
DEL=xxxxx
Specifies a problem debugging aid and is only used with the guidance of a CA Workload
Automation CA 7® Edition specialist. Used to delete chains of SMF or trailer records from the CSA
/ECSA area.
P=xxx...x
Stops an ICOM function that is currently active when the reply is entered. The function, which is
designated by xxx...x, can be any of the values allowable for S=xxx...x (following), which is the
reply used to start inactive functions of ICOM.
S=xxx...x
Starts an ICOM function not currently active when the reply is entered. The function, which is
designated by xxx...x, can be any one of the following:
CALL
Starts collecting both SMF and trailer records.
CSMF
Starts collecting only SMF records.
CTRL
Starts collecting only trailer records.
FILBUF
Requires that buffers are filled before the buffers are written to the communications data set.
(If this value is not specified, buffers are output to the communications data set by the
occurrence of a job initiation, step termination, job termination, or JCL error.)
IOALL
08-Feb-2018 470/722
IOALL
Starts writing both SMF and trailer records to the communications data set.
IOSMF
Starts writing only SMF records to the communications data set.
IOTRL
Starts writing only trailer records to the communications data set.
SUB
Starts the submit function.
SUB=x
Specifies a problem debugging aid that is only used with the guidance of a CA Workload
Automation CA 7® Edition specialist. Modifies the submission process for problem debugging. The
value specified for x is one of the following:
F
Forces submission of jobs in the submit data set even when CA Workload Automation CA 7®
Edition is inactive.
R
Causes the resetting of control bits in the communications data set.
No WTO response is issued. A new outstanding CA-7.574 WTOR is issued. (Not valid unless submit
data sets are used.)
XCF=STAT
Displays the status of the Cross-system Coupling Facility (XCF) interface and names of the XCF
group and members. A new CA-7.574 WTOR is issued following the responses.
CAL2XC37I ICOM IS [NOT] USING XCF

Specifies whether ICOM is using XCF.
If ICOM is using XCF, one or more of the following messages are displayed.
CAL2XC38I XCF GROUP NAME: gggggggg

Identifies the XCF group name, gggggggg.
CAL2XC39I ACTIVE MEMBER NAME: mmmmmmmmmmmm

Identifies the name of an active group member, mmmmmmmmmmmm.
CAL2XC40I CA 7 IS NOT A MEMBER OF THE XCF GROUP

Is displayed if CA Workload Automation CA 7® Edition is not a member of the XCF group.
XTRK=
Modifies or stops CA7XTRK running under ICOM. A new CA-7.574 WTOR is issued following the
response.
More information:
08-Feb-2018 471/722
CA 7 Cross-Platform Tracking Commands (https://wiki.ca.com/display/CWAC7E/Cross-

Platform+Tracking#Cross-PlatformTracking-CA7Cross-PlatformTrackingCommands)
Resource Affinity Scheduling with ICOM

One of the features of IBM Workload Management (WLM) lets you define real or intangible
resources. Next, you can group them together into scheduling environments. This feature lets you
establish a set of conditions that are required before a piece of work executes. This process is
referred to as resource affinity scheduling.
An IBM WLM resource name can be associated with a CA Workload Automation CA 7® Edition ICOM
task so that requirements can be defined for jobs or tasks that depend on ICOM being active. If
specified, the resource state is set to ON during ICOM initialization and the state is set to OFF during
ICOM termination.
If you want to associate an IBM WLM resource name with an ICOM address space, add the following
parameter to the SASSICOM EXEC statement.
,WLM=...resource-name...
Add the keyword to the end of the PARM= string. Separate it from the preceding parameter with a
comma. Resource-name is the 1-character to 16-character name that has been defined in your IBM
WLM policy definitions.
CA 7 Startup Procedures
This article explains CA 7 startup procedures. Performing an initialization process starts the functions
that schedule and control the production environment. The initialization file controls the
environment. Statements within the file define the following items:
Environment in which the Central Control System resides
Processing options to exercise
Terminal and security definitions to use
Type of initialization to perform
Scheduling calendar definitions
An initialization process is necessary regardless of whether you use CA Workload Automation CA 7®

Edition in batch-only mode for maintenance type functions or in online mode for automatic
scheduling and production control. Batch and online activities use the same programs. The user
options in the initialization file define the operating environment and the functions over which it is to
have control. The file is processed when CA Workload Automation CA 7® Edition begins execution.
Also, activate ICOM, the Independent Communications Manager. ICOM, like CA Workload
Automation CA 7® Edition, is activated through JCL. ICOM must be given a high priority. In a multiple
CPU environment, one host CPU has both CA Workload Automation CA 7® Edition and ICOM active.
All other CPUs to which CA Workload Automation CA 7® Edition submits jobs only have ICOM active.
08-Feb-2018 472/722
Make certain data sets associated with the CA Workload Automation CA 7® Edition system available
in addition to activating CA Workload Automation CA 7® Edition and ICOM.
The following help to simplify the initialization process:
Establish separate JCL members for batch and online JCL.
Set up separate initialization files for batch-only and online execution.
If the CA Workload Automation CA 7® Edition JCL is stored in a location other than PROCLIB, the
initialization file to use can be in-stream with the JCL.
For nonshared spool environments, establish separate ICOM JCL members for each CPU. Store
these members in libraries accessible to the CPU on which each is to run.
The PARM values on the EXEC statement of CA Workload Automation CA 7® Edition and the values
that are coded in the initialization file determine the initialization options. CA Workload Automation
CA 7® Edition accesses the initialization file (INIT file) through the UCC7IN DD statement in the JCL.
Before these values are coded, give some thought and analysis to the following items:
Terminals for CA Workload Automation CA 7® Edition to use
System startup options wanted
JCL data sets available to CA Workload Automation CA 7® Edition
CA Workload Automation CA 7® Edition is typically initialized in batch mode only one time, during the
initial installation. After the installation, the online version is used.
Other initialization areas to consider include the following topics.
Date and Time Validation Option

The date and time validation feature provides the opportunity to verify and manually correct system
clocks on all CPUs whenever CA Workload Automation CA 7® Edition is initialized. This feature can
ensure that the date and time are correct within the system. Schedule scan produces improper
results when those values are incorrect.
An initialization file parameter keyword, VALIDATE, can have two values:
Specify no validation.
Designate a tolerance value for disabling the validation process.
The time tolerance is based on the difference (in hours) between the current system date/time
values and the most recent CA Workload Automation CA 7® Edition checkpoint date/time values (if
available).
The system initiates the verification process by displaying the current date and time values followed
by a WTOR requesting action. A response to the WTOR indicates the desired action of CA Workload
Automation CA 7® Edition. When the WTOR is issued, the following options are available:
08-Feb-2018 473/722
Manually correct the system clocks before proceeding. However, if the system clocks are
acceptable, clock adjustment is not necessary.
Proceed with schedule scan deactivated.
Whenever the desired option has been entered, the current date and time are displayed again, after
the operator response, before proceeding. Any manual adjustments to the date or time while the
WTOR was outstanding are obvious from the before and after displays.
Log Usage
The following items are automatically logged:
Transactions from terminals
Internal events
Queue processing
SMF feedback
Messages for the master station
Log data sets can be allocated on DASD or tape. If tape is selected, only one log data set is required,
and a tape drive must be dedicated to CA Workload Automation CA 7® Edition.
The recommended configuration for the log file is to designate two disk data sets. This way, when
one file is full, a switch is made to begin recording in the other log file. With CA Workload Automation
CA 7® Edition, the job to dump the data is also automatically submitted whenever the switch occurs.
Only the UCC7LOG DD statement, pointing to the primary log file, is needed. The secondary log file
must reside on the same pack as the primary file, with a different data set name. The secondary log
file does not require a DD statement although one can be coded to keep the data set from any
migration utility (recommended UCC7LOGS ddname). The secondary log file data set name is used
with the ddname UCC7LOG to access the data set.
The initialization file must specify both of the following items:
The primary and secondary log data set names (ALOG1 and ALOG2 statements).
The name of the job that dumps the primary log file (DBASE statement JOB parameter).
Define that job name in the database, and the JCL for the job must reside in a JCL data set accessible
to CA Workload Automation CA 7® Edition.
More information:
Log Data Set Management (see page 613)
08-Feb-2018 474/722
Batch Job Compared to Started Task

CA Workload Automation CA 7® Edition can run as a started task or a batch job. ICOM can also be a
started task. Regardless of whether CA Workload Automation CA 7® Edition is a batch job or a started
task, it processes the same way.
Manage CA 7
This article explains how to manage CA 7, including startup and shutdown.
Module UCC7 is the central control entity of CA Workload Automation CA 7® Edition. UCC7 must be
active when you want to perform CA Workload Automation CA 7® Edition functions. When you want
CA Workload Automation CA 7® Edition to provide automatic scheduling, monitoring, and control of
work, the Independent Communications Manager (ICOM) must also be active.
More information:
ICOM Execution (see page 463)
PARM Values
The PARM data on the EXEC statement defines the amount of memory, from the CA Workload
Automation CA 7® Edition region, to reserve for interface work areas within CA Workload Automation
CA 7® Edition. Optionally, the user can also specify the startup type, with the TYPE keyword, as a
PARM value.
The CA7ONL PARM field has the following format:

PARM='CABND=&CABND,CWORK=&CWORK,TYPE=&TYPE,DRMODE=&DRMODE'
The ampersand (&) values are defined on the CA7ONL or CA7BAT PROC statement.
The following PARM keyword parameters are available:
TYPE=type
Specifies the type of startup option: COLD, WARM, EDIT, ERST, FORM, CKPT, or DORM. The TYPE
value that is specified here overrides the value that the initialization file INIT statement specifies.
However, the initialization file must always have a valid TYPE value coded.
CABND=nnn
Specifies the number of 2-KB memory blocks that are reserved for abend processing during the
initialization.
Default: 2 (4 KB of memory).
08-Feb-2018 475/722
CWORK=nnn
Specifies the number of 2-KB memory blocks that are reserved for initialization and interface
work areas.
Default:110
If you use a REGION=6M (or larger) for CA Workload Automation CA 7® Edition, the CWORK value
is not required.
DRMODE={NO|YES}
Determines whether CA Workload Automation CA 7® Edition starts in disaster recovery mode.
The default, DRMODE=NO, starts CA Workload Automation CA 7® Edition in normal mode.
Specifying DRMODE=YES starts CA Workload Automation CA 7® Edition in disaster recovery
mode.
More information:
Disaster Recovery Classes (see page 609)
Verify the Initialization File Offline (see page 493)
Startup Options
Seven types of initialization or startup options are available. These options include the following
types:
WARM start
ERST start
COLD start
FORM start
CKPT start
DORM start
EDIT start
MOVQ is obsolete starting with [set release level for product]. If specified, the startup option defaults
to ERST.
The startup option is specified in one of the following methods:
In the INIT statement of the initialization file
As a PARM in the EXEC statement
08-Feb-2018 476/722
However, if specified as a PARM in the EXEC statement, it overrides whatever is specified in the INIT
statement. In any case, specify a TYPE parameter in the INIT statement even when a TYPE is included
in the PARM data.
The option has no default value. Code the option in the following format:
TYPE=type
The following topics discuss the acceptable values and their meanings in detail.
The normal restart procedure is a WARM start. If CA Workload Automation CA 7® Edition does not
activate, try a specified ERST (emergency restart) start. If CA Workload Automation CA 7® Edition still
does not activate, contact your CA Workload Automation CA 7® Edition coordinator. Sometimes a
COLD start is necessary.
WARM Start (Normal Restart)

The WARM start option initializes CA Workload Automation CA 7® Edition with information in the
queues remaining intact from the last time it was active. A WARM start can reactivate CA Workload
Automation CA 7® Edition after a normal shutdown. The internal control blocks are reinitialized from
information. The information resides in the checkpoint data set, communications data set, log data
sets, and the queues.
Except for the SCRQ and DQTQ, all queues remain intact. The secondary messages queued for
terminals are retained. The queues and database are updated with any information stored in the
communications data set while CA Workload Automation CA 7® Edition was inactive.
The WARM start initialization process performs several checks of internal system status to verify that
a WARM start is possible. If CA Workload Automation CA 7® Edition detects that previously it did not
shut down cleanly, it automatically performs an ERST start. This ERST start is not the same as a
specified ERST type of startup. If TYPE=ERST is coded, queued messages are purged from the CA
Workload Automation CA 7® Edition queues. Also, if the number of terminals that are defined in the
initialization file is greater than 254, a TYPE=ERST is assumed. This assumption is because CA
Workload Automation CA 7® Edition cannot checkpoint the terminal data in this case.
The following items are considered errors during a WARM start:
Any changes to the initialization file other than those changes permitted. The allowed changes
follow this list.
Any discrepancy in the date, time, and CA Workload Automation CA 7® Edition version number
information that is stored in the shutdown record in the checkpoint and log data sets.
No shutdown record is found in the log data set.
Changes to the initialization file are permitted as part of a WARM start. The allowable changes
include the following items:
RESIDENT
Only the APGPL and G64PL parameters can be changed.
INIT
All parameters can be changed.
08-Feb-2018 477/722
SVCNO
The SASSVC parameter can be changed.
APPLCTN
Statements can be added or removed as necessary. All parameters can also be changed.
FMTBLK
Statements can be added or removed as necessary. All parameters can also be changed.
GROUP
Only the OPEN parameter can be changed.
LINE
Only the BUFSIZE and OPEN parameters can be changed.
TERM
Only the RELADR, TIMLIM, MONLIM, LOGMODE, LCLSNA, ADRCHR, and CONS parameters can be
changed.
ERST Start (Emergency Restart)

The ERST start (emergency restart) option can recover from most CA Workload Automation CA 7®
Edition system failures. Certain initialization file changes require this type of start. The object of
emergency restart is twofold:
Reconstruct the system as it existed before the system failure.
Bring all status up to the current time.
During the ERST procedure you can add, delete or change terminals. Also, you can change the
security.
The data that is stored in the communications data set (while CA Workload Automation CA 7® Edition
was down) is used to update the status. After a successful emergency restart occurs, the status of
jobs under CA Workload Automation CA 7® Edition is current as reflected in the queues. However,
any messages queued to terminals are lost. All other information in the queues remains intact.
COLD Start (Clear Workload Restart)

Use the COLD start option when you do not want to retain CA Workload Automation CA 7® Edition
queue information.
Use a COLD start when a nonrecoverable failure occurred or to purge all information in the queues
remaining from the last time CA Workload Automation CA 7® Edition was active. Certain initialization
file changes require a COLD start. Every COLD start reestablishes the environment definition. The CA
Workload Automation CA 7® Edition active workload queues are cleared except for the prior-run
queue. All internal control blocks, the log data sets, and the checkpoint data set are reinitialized. The
workload balancing definition is reset to the default module UCC7RDFL, unless the DFLTWLB
parameter of the OPTIONS statement in the initialization file is used. The schedule scan processing
options are also reestablished. Scanning can be initiated at the option of the user.
08-Feb-2018 478/722
When a COLD start is done, CA Workload Automation CA 7® Edition starts logging to the primary log.
Any data that was in the primary or secondary log file is overwritten without being written to the
history file. If you want to save the log data, execute the log dump jobs before doing the COLD start.
Note: When a COLD start is referred to in other CA Workload Automation CA 7® Edition

documentation, FORM can also be used. (FORM is considered a COLD type of startup.)
During a COLD or FORM start, the Virtual Resource Management facility (VRM) deletes all active and
nonfreed corequisite and manual resource records. The resource count records (RCT) remain, but the
in-use count is cleared.
Keep in mind the following general principles:
A COLD start is necessary when recovery from an ERST error is not possible.
Internal CA Workload Automation CA 7® Edition status, queue status, and terminal status are
initialized from scratch, regardless of the activity occurring when the previous online execution of
CA Workload Automation CA 7® Edition terminated.
The default workload balancing module is always used for the initial values for WLB purposes.
The primary log data set is always used for any recording activity.
FORM Start (Format Queues Restart)

A FORM start performs the same functions as COLD start except that the prior run queue is also
cleared. See COLD start for information about functions that are performed during a COLD start.
CKPT Start (Reinitialize the Checkpoint Data Set)

A CKPT start performs the same functions as an ERST start except that the checkpoint file is
reinitialized. See the ERST start for more information about functions that are performed during an
ERST start.
The checkpoint file reinitialization causes the following actions:
The CA7 job number starts over at the lowest available number.
The schedule scan processing options are reestablished. Scanning can be initiated at the option of
the user.
The product starts logging to the primary log. Any data previously in the primary or secondary log
file is overwritten without being written to the history file. If you want to save the log data,
execute the log dump jobs before doing the CKPT start.
This type of start is required when using a new checkpoint file like executing under a new release for
the first time.
08-Feb-2018 479/722
DORM Start (Dormant Copy)

DORM start let you start a dormant (backup) copy of CA Workload Automation CA 7® Edition. If the
main CA Workload Automation CA 7® Edition is active, this copy does not fully initialize. However, it
monitors the status of the main CA Workload Automation CA 7® Edition. If the main terminates, the
dormant copy completes initialization and it takes over for the main. TYPE=DORM is only valid on the
PARM to CA Workload Automation CA 7® Edition (that is, it is not a valid type in the initialization file).
More information:
Dormant Copy (see page )

(https://wiki.ca.com/display/CWAC7E/Offline+Verification+of+Initialization+File)
EDIT Start (Offline Verification of Initialization File)

The EDIT start can test values in the initialization file. TYPE=EDIT can be specified but does not cause
CA Workload Automation CA 7® Edition to be initialized. TYPE=EDIT is only valid on the PARM to CA
Workload Automation CA 7® Edition (that is, it is not a valid type in the initialization file). The EDIT
start is used only for initialization file editing.
More information:
Verify the Initialization File Offline (see page 493)
DBPARMS Parameter File

The DBPARMS parameter file is a card-image file. The file defines the logical database name for this
CA 7 instance. This file must be provided through the ddname of DBPARMS.
Once the database is loaded, code the same DBPARMS file in the following places:
The CA 7 Central Control System (CA7ONL) execution
The JCL for CA Workload Automation CA 7® Edition with any execution of the Batch Card Load
program (SASSBCLP)
All uses of the Database Verification program (CAL2DBVR)
The various steps of Database Transportability
WLP and other small utilities that need access to the logical database name for the CA 7 instance
The SYSGEN process creates a sample DBPARMS file. You can change the sample if necessary. This file
resides in the DBPARMS member in the JCLLIB created during the SYSGEN process.
08-Feb-2018 480/722
The specific syntax for the DBPARMS file is:

DATACOM (NAME(logicalname))
Where the logicalname is the name of the logical database for this CA 7 instance.
The following rules apply to the DBPARMS file:
An asterisk in column 1 is a comment statement.
Only columns 1 through 72 are examined. Columns 73 through 80 are ignored.
DATACOM can start in column 1 or after, but the whole string must occur on the same statement.
A logical name is 1 through 16 characters (alphanumeric, dash, underscore, and period). All other
characters cause an error.
No continuations of statements are permitted.
The two closing parentheses after the logicalname must occur together with no space in between
the closing parentheses.
The logical database names must be unique within a sysplex, even if using different physical CA
Datacom/AD MUFs. Consider the following scenario
MUF_A on LPAR A contains logical database name INITIAL_TESTING
MUF_B on LPAR B contains logical database name INITIAL_TESTING
LPAR A and LPAR B are in the same sysplex
Only one CA7ONL can be active using the logical database name of INITIAL_TESTING. If a
CA7ONL is active and using the INITIAL_TESTING logical database on MUF_A, and you attempt
to bring up a second CA7ONL that attempts to use INITIAL_TESTING on MUF_B on LPAR B,
message CAL2I030E is returned indicating the ENQ on the logical database name could not be
obtained. The second CA7ONL task comes down with a U0955 abend.
Online Execution
To perform automatic scheduling and job submission functions, initialize CA Workload Automation
CA 7® Edition for online operation.
The SYSGEN macros generate JCL necessary for executing CA Workload Automation CA 7® Edition
online. The JCLLIB member CA07N240 represents the batch job, which invokes the JCL procedure
CA7ONL. The descriptions of the DD statements follow. The SYSGEN macros also generate a sample
initialization file for executing CA 7 online. You can modify this file to reflect your own environment.
A sample online initialization file is in the member ONLINE in the JCLLIB produced by the SYSGEN
process.
Do the first online execution of CA Workload Automation CA 7® Edition with a TYPE=FORM start. You
can specify this type of start with the PARM information of the EXEC statement. After the first
execution, perform a TYPE=WARM or TYPE=ERST start.
08-Feb-2018 481/722
DD Statements
DDNAME Explanation Status
STEPLIB CA Workload Automation CA 7® Edition load library. Other Required unless linklisted.
libraries can be concatenated in the STEPLIB for:
CA Datacom/AD MUF and programs that describe the CA 7
database
Base calendars (if another library)
CA 1® LOADLIB if using TIQ
CA IAS LOADLIB if using CA WA Agents
CA Workload Automation Restart Option for z/OS Schedulers
LOADLIB if using ARTS.
SYSMDU GDG data set with DISP=(NEW,DELETE,CATLG) Required for debugging
MP purposes.
UCC7DU CA Workload Automation CA 7® Edition snap dumps. Optional.
MP
UCC7OU Output data set for listing the CA Workload Automation CA 7® Required.
T Edition initialization file.
UCC7IN Input data set for the initialization file. Required.
DBPARM A member stating the logical database name for the CA 7 Required.
S database.
UCC7LO Required CA Workload Automation CA 7® Edition log data set. Required.
G Specify primary log data set name.
UCC7LO CA Workload Automation CA 7® Edition secondary log data set. Optional. If used, use only
GS Specify secondary log data set name. in online to protect the
secondary log data set.
UCC7CM Communications data set. In multi-CPU environments, must Required for online.
DS reside on a shared DASD device available to all CPUs that Optional for batch.
process CA Workload Automation CA 7® Edition controlled jobs.
UCC7SUB Submit data set used for submitting JCL to the host system. In a Optional unless you coded
n multi-CPU environment, each host system requires its own CPU statements in the CA
or submit data set. Shared spooled systems require only the Workload Automation CA
UCC7IRD UCC7IRDn DD. The n is used to provide some ddname 7® Edition initialization
n uniqueness. file.
UCC7CKP Checkpoint data set. Required.
T
UCC7DQ Disk queue table queue. Required.
TQ
UCC7SCR Scratch queue. Required.
Q
XCKPT Internal cross-platform checkpoint file (XTRK). Optional. Required for
XPJOB submission.
XEVENTS XTRK event rules. Optional.
XPSPSW Cross-platform scheduling password requirement rules. Optional.
D
XPRINT XTRK trace messages. Optional.
08-Feb-2018 482/722

XSNAP XTRK trace snaps. Optional.
JCLnnn CA Librarian® or CA Panvalet® for z/OS JCL data set. Optional.
BTERMn Input data set for the batch terminal nn. Optional for online.
nI Required for batch.
See Note 1.
BTERMn Output data set for the batch terminal nn. Optional for online.
nO Required for batch.
See Note 1.
UCC7STA Statistics data set. Required.
T
BROWSE A sequential DASD browse data set that contains records of Optional. The ddname
print image messages that are produced for station name must match GROUP
MASTER. statement NAME
parameter in the
XCFCKPT XCF checkpoint data set. Required for XCF.
UCC7WL Workload planning data set. Required for FWLP.
P
CARPRO CA Driver procedure library. Optional for online only.
C Used by the CA Driver
component.
MSGRCN A sequential file that is used to provide control information for Optional, required when
TL Master Station Message Routing (MSMR). using MSMR.
EADDRLI Partitioned data set containing one or more email addresses to See Note 2.
B which an email can be sent.
EMAILLIB Partitioned data set containing the contents (template) of one See Note 2.
or more emails that can be sent.
SERVDES A sequential input file containing the filtering rules for the Optional, required if
K CAISDI/els interface. SERVICEDESK is specified
SERVLOG A sequential output file containing request numbers for the Optional, required if
CAISDI/els interface. SERVICEDESK is specified
SYSPROC The proclib to search when AUTOPROC is not used for CA Optional, depends on
JCLCheck. whether the interface is
used.
CA7AGN A VSAM file containing information that is returned with an Optional, required only if
T agent job feedback. the agent jobs interface is
active.
IASAGEN A sequential file defining the CA WA Agents with which CA Optional, required only if
T Workload Automation CA 7® Edition® communicates. the agent jobs interface is
active.
IASCRYPT A sequential file defining the encryption keys for CA WA Agent
communication.
08-Feb-2018 483/722

Optional, required only if
the agent jobs interface is
active.
IASCKPT A Data-in-Virtual (DIV) Linear VSAM file to contain checkpoint Optional, required only if
information for the IAS interface. the agent jobs interface is
active.
Note 1:
The first seven characters of these ddnames must match the initialization file GROUP statement
NAME parameter. The first seven characters do not have to be BTERMnn. However, the last
(eighth) character must be an I or O (alpha) to indicate an input or output data set.
Note 2:
The data set is dynamically allocated at CA Workload Automation CA 7® Edition startup when the
initialization file contains the EMAIL statement. Optionally, the data set can be allocated in the CA
Workload Automation CA 7® Edition JCL with the ddname listed.
Batch Execution
CA Workload Automation CA 7® Edition can execute in batch-only mode for maintenance or
reporting activities that do not require automatic scheduling and job submission facilities or online
terminals. Run this type of execution only when CA Workload Automation CA 7® Edition is first
installed using the installation job N220.
Note: CA Workload Automation CA 7® Edition cannot execute in batch and online mode
simultaneously. The batch terminal interface facility can be used for batch maintenance
and reporting while CA Workload Automation CA 7® Edition is executing online.
The CA Workload Automation CA 7® Edition SYSGEN macros generate the JCL necessary for executing
CA Workload Automation CA 7® Edition in batch-only mode. The job is CA07N220 and the procedure
is CA7BAT. Refer to the JCLLIB member BATCH for a sample initialization file for batch-only mode.
For a batch-only execution of CA Workload Automation CA 7® Edition, ICOM is not required. Also,
never attempt a batch-only execution while CA Workload Automation CA 7® Edition is active online.
The following guidelines are for the initialization file changes for batch-only. The sample batch
initialization file that is produced during SYSGEN, BATCH, typically only requires changes when the
batch terminal ddname has changed.
RESIDENT statement
Specify NETWORK=BAT
INIT statement
RUNOPT=SCAN is not permitted.
Specify RUNOPT=REPT to perform database maintenance and reporting. For this operation, the
queues can be allocated to temporary data sets. As a result, TYPE=COLD can be coded. The
communications data set is not required.
08-Feb-2018 484/722
GROUP statement
Remove all GROUP statements that do not specify DEVICE=BATCH. Only one is needed.
LINE/TERM statements
Remove all LINE and TERM statements belonging to GROUP statements that have been removed.
Only one LINE or TERM statement is needed.
Note: You must have GROUP/LINE/TERM statement sequences for the batch terminal.
SECURITY statement
Verify that the Security module includes SECURITY macro definitions for the specified batch
terminal.
STATIONS statement
Remove STATIONS statements for terminals no longer defined due to removal of GROUP/LINE
/TERM statements. Have the batch terminal specify STANIDS=MASTER.
ALOG1/ALOG2 statements
DSN= can be indicated as temporary (for example, &&LOGP).
If the log data set is assigned to a tape for batch runs, remove the ALOG2 statement. The ALOG2
statement is never required.
SCHEDULE statement
Not used
CPU statement
Not used
SMF statement
SMFXCF=YES is not permitted. The Cross-system Coupling Facility (XCF) cannot be used when CA
Workload Automation CA 7 Edition runs in batch mode.
Dormant Copy
A secondary, dormant copy of CA Workload Automation CA 7® Edition can run. The copy can take
over for a primary CA Workload Automation CA 7® Edition that has terminated. This method lets you
have an automatic recovery procedure for the CA Workload Automation CA 7® Edition task in case of
the following situations:
The abnormal termination of the primary task
The loss of the CPU where the primary was executing
The dormant copy is started while the primary is active and monitors the status of the primary. If
the dormant copy determines that the primary has terminated, the dormant copy completes
initialization and it assumes the functions of the primary.
The dormant copy can execute on the same CPU as the primary or on another CPU. The other CPU
must have access to the DASD where the CA Workload Automation CA 7® Edition data sets reside.
08-Feb-2018 485/722
Note: If the primary CA 7 online task is using ARM for automatic restarts, a secondary,
dormant copy is not necessary and should not be started. If a CA 7 online task is started
with TYPE=DORM and it contains the initialization file statement STATEMGR,ARM=YES, a
user abend occurs. The dormant task fails.
Procedure
The dormant copy of CA Workload Automation CA 7® Edition must have access to all the data sets
that the primary CA Workload Automation CA 7® Edition is using. To set up the JCL, you can copy the
procedure for the primary CA Workload Automation CA 7® Edition and simply change the TYPE=
PARM. If any of the DD statements have DISP=OLD, change them to DISP=SHR to avoid an ENQ
conflict. If the dormant copy executes under a different task/job name, duplicate the security
definitions in place for the primary CA Workload Automation CA 7® Edition for the dormant copy.
Specifying TYPE=DORM as the PARM in the JCL designates a CA Workload Automation CA 7® Edition
as dormant. When this PARM is used, the CA Workload Automation CA 7® Edition task starts and
does some of the initialization process. The task then issues the following WTOR:
CA-7.740 - CA-7 DORMANT START. REPLY "YES" TO TAKE OVER OR "STOP" TO END
This WTOR lets you stop the dormant copy or manually request it to take over for the primary CA
Workload Automation CA 7® Edition. Now, the dormant CA Workload Automation CA 7® Edition
monitors the status of the primary CA Workload Automation CA 7® Edition by validating the
availability of the ENQ that CA Workload Automation CA 7® Edition issues at startup. As long as the
ENQ cannot be obtained, the dormant copy remains in this state. When the ENQ can be obtained, the
dormant copy issues the following WTOR:
CA-7.743 - MAIN CA-7 INACTIVE - DORM WILL TAKE OVER UNLESS "STOP" REPLY
If a STOP response is not received within 60 seconds (default), the dormant copy completes
initialization as an ERST startup. Next, the dormant copy takes over the functions from the primary
CA Workload Automation CA 7® Edition. You can set the time interval using the DORMVER keyword
of the SVCNO statement in the initialization file.
ENQ Monitoring
The monitoring of the primary CA Workload Automation CA 7® Edition is accomplished by checking
the availability of the ENQ issued by the primary. The qname for the ENQ is UCC7SVT. The default
name is the CA 7 instance name (CA7n).
Note: The RNAME keyword on the SVCNO statement of the initialization file can override
the RNAME. The RNAME for the primary and dormant copies must match. If they do not
match, they can damage the database and queue files, requiring possible database reload
of CA Workload Automation CA 7® Edition.
If the dormant copy executes on a CPU different from the primary copy, verify that an ENQ package is
being used to enforce a single usage of the previous ENQ by any task on the CPUs.
08-Feb-2018 486/722
Shutdown Procedures
The /SHUTDOWN command causes a normal termination of CA Workload Automation CA 7® Edition
execution. The command is only authorized from the CA Workload Automation CA 7® Edition master
or alternate terminal because of the impact of shutting down the CA Workload Automation CA 7®
Edition system.
OS CANCEL Command
While not recommended, you can use the OS CANCEL command from the system master console to
terminate the CA Workload Automation CA 7® Edition execution. Use an OS CANCEL only when the
/SHUTDOWN is unable to terminate CA Workload Automation CA 7® Edition. This command results in
an abnormal termination, and the system issues an abend message. If the OS CANCEL is needed,
specify the option to produce a dump to aid in problem analysis.
Terminals are not notified that the system is being deactivated. Some data can be lost.
After an OS CANCEL of CA Workload Automation CA 7® Edition, the ERST start option is the
recommended method of reactivating CA Workload Automation CA 7® Edition.
Manage the Initialization File

The initialization file is input during activation of CA Workload Automation CA 7® Edition. The
initialization file is contained in the data set that the UCC7IN DD statement in the CA Workload
Automation CA 7® Edition execution JCL defines. The file can be kept in a sequential data set or as a
member of a partitioned data set. Some users find it convenient to maintain different copies of the
initialization file depending on requirements to alter the CA Workload Automation CA 7® Edition
processing configuration.
The installation process generates sample execution JCL and sample initialization files for the batch
and online initialization. The process then places them in the CA Workload Automation CA 7® Edition
JCLLIB data set created during CA Workload Automation CA 7® Edition SYSGEN. Generated Stage II
JCL and initialization files require modification to suit installation requirements.
Depending on installation requirements and on configuration requirements during a given CA

Workload Automation CA 7® Edition execution, you can omit some initialization statements. Other
statements must always be included, and some statements are specified multiple times.
The statements in the initialization file define the following items:
Host operating system and job entry subsystem
Number of CPUs in the CA Workload Automation CA 7® Edition configuration
Type of initialization to perform
CA Workload Automation CA 7® Edition terminal network
Workstations and the physical terminal each is assigned
User JCL data sets
08-Feb-2018 487/722
CA Workload Automation CA 7® Edition modules to be available
Samples of online and batch mode initialization files are provided. Those examples are helpful, as a
reference, when reviewing these topics.
Initialization File Statements Syntax Rules

Initialization file statements include a statement name followed by keywords and keyword values.
Begin statement names (RESIDENT, INIT, SVCNO, and so forth) in column 1. An asterisk in column 1
indicates a comment statement. Include comment statements in the initialization files to document
the usage of each file or portion of a file.
Separate the first statement keyword from the statement name by a single comma. No blanks are
permitted. The statement keywords are nonpositional unless otherwise noted. Separate keyword
values from subsequent statement keywords with a single comma. No blanks are permitted.
More information:
Syntax Diagrams (https://wiki.ca.com/display/CWAC7E/Syntax+Diagrams)
Sample Statement Format

COL 1
|name,keyword1=value,keyword2=value
Do not code statements beyond column 71. Blank statements are not permitted.
Either of the following actions accomplishes statement continuation:
Coding values through column 71 and a nonblank character in column 72, or
Leaving at least one blank after any comma.
Continuation then resumes with the first nonblank character in the next record that is not a comment
statement. Continuation can begin anywhere before column 72.
Column 72 is reserved to contain an optional, nonblank character to indicate that a statement is

being continued. A nonblank character in column 72 is required only when a value continues on the
next record after breaking after column 71.
You can code comments in individual statements following at least one blank but must not extend
beyond column 71.
Sample Statement Continuation Formats

COL 1 COL 72
| |name,keyword1=value,keyword2=valu
e,keyword3=value, *

keyword4=value
name,keyword1=value,keyword2=value,keyword3=value,ke*
08-Feb-2018 488/722
name,keyword1=value,keyword2=value,keyword3=value,ke*
yword4=value
name,keyword1=value,keyword2=value,keyword3=value, keyword4
=value
Note: Continuation requires that at least one keyword is coded on the first line of the
statement. Statements cannot be continued without at least one keyword on the first line
of the statement.
Initialization Files Statements and Keywords

This table is a matrix of the initialization statements and keywords. When used, statements must
appear in the file in the sequence shown in the table. The letter R identifies required statements. The
letter M identifies those statements that can appear multiple times within the file. The letter C
identifies statements that you can continue from one statement or line to the next.
Statement Required Can code multiple times Possible continuation necessary Notes
RESIDENT R C
CUST R
NEWS M
INIT R C
SVCNO R C
APPLCTN R M Note 4
FMTBLK R M Note 4
CALBLK R M Note 4
UCC7VTAM C
GROUP R M C
LINE R M C
TERM R M C
INIT2
SECURITY R
STATIONS R M C
STNCAL M C
DBASE R C
ALOG1 R
ALOG2 Note 1
RESTART C Note 2
SCHEDULE R C
CPU M C Note 6
08-Feb-2018 489/722
Statement Required Can code multiple times Possible continuation necessary Notes
CALENDAR
JCL R M C
JCLCHECK Note 3
DAIO R
NETMAN Note 5
OPTIONS M
VRMOPTS M
PFTERM M
PAnn M
PFnn M
CANCEL
DRMODE C
DRCLASS M
EMAIL C
SERVICEDESK
XPDEF C
STATEMGR C
SMF M
END
Note 1:
If used, ALOG1 must also be present.
Note 2:
Required only if you want to require restart reasons of the operator or you want the CA Workload
Automation Restart Option for z/OS Schedulers interface.
Note 3:
Required only if you want the interface with CA JCLCheck™.
Note 4:
Associated load module required.
Note 5:
Required with a real-time problem management interface.
Note 6:
Required if using submit data sets.
The statements that are presented in the following table are the only allowable statements in the
initialization file. This topic gives a detailed explanation of each statement and its associated
keywords. All statements must begin in column 1.
08-Feb-2018 490/722
The following statement descriptions appear in the order in which they appear in the initialization
file.
Statement Keywords Required Optional

RESIDENT APGPL, NETWORK X
COLDWTOR, G64PL, JCLDEFS X
CUST ID X
NEWS M X
INIT CONFIG, TYPE X
METRICS, PERFORM, RUNOP, TIMLIM, VALIDATE X
SVCNO SASSVC X
CA7, DORMENQ, DORMVER, MONITOR, RNAME, ROUTER, TEST, X
XPSSCHD, XTMNAME
APPLCTN NAME X
ATTR X
FMTBLK NAME X
ATTR X
CALBLK NAME X
ATTR X
UCC7VTA APPL X
M
NUMRECV, OPEN, TCPTOUT, TCPTPORT, VTNAME X
GROUP DEVICE, LNAME, NAME X
OPEN, VLOGOFF X
LINE BUFSIZE, NAME, TNAME X
OPEN X
TERM DEVICE, LINLEN, NAME, NLINE X
CONS, LCLSNA, LOGMODE, MONLIM, PRINTER, RELEASE, SIMLOG, X
TIMLIM, VLOGOFF, VTAMID
INIT2 X
SECURITY NAME X
ACF2CARD, AGCLASS, AGUSER, APPL,BYPSEC, CCLASS, DFLTUSER, X
DISPLAY, EXTERNAL, HIDEGRP, HIDEPW, HIDEUPD, HIDEUSER, JCLUID,
LOADSUBC, LOGOPID, MIXPW, MULTIJOB, PCLASS, PROPAGATE,
PSOWNER, RCLASS, RESLOGON, RLOGUID, SCLASS, STATSID, SUBNOID,
SUBUID, UID, USER, XBSCLASS, XBSUBCHK, XPSSID
STATIONS TRMID, STANIDS X
STNCAL STN X
CAL, FROM, TO X
DBASE X
08-Feb-2018 491/722

DEFAULTAG, DEFAULTJOB, DEFAULTPS, DEFAULTXPJ, JOB, LDJOBNM,
LOADDSNS, PROCLOAD, RLOGDAYS, RSRC
ALOG1 DSN X
ALOG2 DSN X
RESTART ARF, CONDCHK, LRTCDREQ, PARMRMS, PROCRMS, REASON, RMS, X
ROUTCDE, STEPRMS, WTO, WTOSTEP
SCHEDULE HIJBNUM, QDWELL, REPROMPT, SCNINCR, SCNSPAN, XPRETRY X
ABR, ENDDAY, PSFORCE, QPRG, REQUE, RETRY, SCHID, STOPQ X
CPU BARRIER, DDNAME, HOST, MAINIDS X
CALENDA DSN, PCALDSN X
R
JCL DSN, INDEX X
ALT, DPROC, DSORG, DYN, LTERM, MCD X
JCLCHECK DDNAME, JSC, MAXUSERS, TCBSEC X
DAIO DASD X
BUFSIZE, IOBS, RECORDS X
NETMAN DBASENM X
EXIT, GOODCOMP X
OPTIONS ATTACH, AUTOREQ, CAL2C900, CMGRDELAY, CPM, CTIMSG, DFLTWLB, X
DPROCCOM, EXPDTCHK, EXTSCHID, FCMAXLEV, GVARLVL, GVARRPFX,
GVARSUB, INITCASE, JCLDSST, JCLJOBCK, JCLTAG, JFM, JOBDEL, JSOP,
LATEPROMPT, LOADCLASS, LOGSUBJCL, MAXRINGSZ, MAXSUBOUT,
OVJCL, PERMDSN, PROPDSNU, PROPMAIN, PSP, RLOGBDEF, RLOGCAN,
RQMT255, RUNCLASS, SHRCRQ, SHRCRQPFX, SHUTDOWN,
SUBMSGLVL, SUBSEL, VRMDD, WLBOPT, WLMCA7, WLMSE,
WLMSEVAL, XQOFF
VRMOPTS RPLCNT X
PFTERM TERM/T X
PAnn X
PAnn(nn=01-03) X
PFnn X
PFnn(nn=01-24) X
CANCEL REASON X
DRMODE DEFCLASS, RQMTS, TRIGGERS, VERIFY X
DRCLASS CLASS X
EMAIL ESERVER X
EADDRLIB, EFROM, EMAILLIB, EPORT, EREPLY, ETIMEOUT X
SERVICED X
ESK
XPDEF X
08-Feb-2018 492/722

AGENTDAY, AGENTJOB, PSWDLOC, SUBROOT, XMONITOR, XPHAO,
XPKILL, XPSSCHD, XPSTRC, XROUTER, XSERVER, XSERVERTRC, XSUBMIT,
XTRKTRC
STATEMG ARM, OPSSSM X
R
SMF SMFXCF, TZDISPLAY, TZPREDS X
END X
Verify the Initialization File Offline

The initialization file can require many statements depending on the user site and how the site uses
CA Workload Automation CA 7® Edition. The opportunity for an error to occur somewhere in a
complete file increases with the number of statements.
Accuracy of the initialization file is not only a concern when building the file for the first time.
Accuracy is also a concern in an ongoing maintenance mode whenever changes become necessary.
To assist the user in verifying the accuracy of the initialization file, a batch edit function is provided.
This job lets the user verify the contents of the file without having to start up CA Workload
Automation CA 7® Edition for any other functions. Run the job at any time when initialization file
changes are made to verify its accuracy before implementing the changes in a production mode. The
job is especially helpful when terminals are added or terminals are deleted in the initialization file.
This batch job can be run whether CA Workload Automation CA 7® Edition is already active.
Batch Edit Execution

No changes are required within the initialization file to indicate that this job is an initialization file
edit. Once a successful edit has been done, the file can then be used "as is" to start up CA Workload
Automation CA 7® Edition as intended. The following JCL is a sample initialization file edit JCL:
//CA7EDIT JOB............,REGION=3072K
//************************************************************
//* EXECUTION OF CA-7 INITIALIZATION FILE EDIT *
//************************************************************
//EDIT EXEC PGM=UCC7,PARM='TYPE=EDIT'
//STEPLIB DD DISP=SHR,DSN=ca7.loadlib
//UCC7OUT DD SYSOUT=*
//UCC7IN DD *
*** CA-7 Initialization File goes here ***
/*
This JCL executes PGM=UCC7, not a cataloged procedure, with a TYPE value of EDIT through the
PARM value on the EXEC statement. This value causes CA Workload Automation CA 7® Edition to
terminate after editing the initialization file, without attempting any of its other functions, regardless
of any values are coded within the file itself. The TYPE value in the INIT statement in the file has
whatever value is needed whenever the file is used in production. EDIT is not valid in the INIT
statement. EDIT is only valid as a PARM value.
08-Feb-2018 493/722
Any errors that are encountered within the file are handled as they are any other time that CA
Workload Automation CA 7® Edition is executed. That is, the messages and abend codes are the same
here for any errors that are encountered.
The following message indicates successful completion of the edit:
CA-7.998 - INITIALIZATION DECK EDIT COMPLETE
Because CA Workload Automation CA 7® Edition itself performs this edit, make the REGION size large
enough to handle the environment that the initialization file defines. The REGION size that is needed
for a production run of CA Workload Automation CA 7® Edition is much larger than the size needed
for this run. This process only requires DD statements for the file input data set UCC7IN and the print
data set UCC7OUT. Omit other DDs from the JCL to avoid allocation conflicts with any production
copy of CA Workload Automation CA 7® Edition. The regular execution JCL for CA Workload
Automation CA 7® Edition can be used only when CA Workload Automation CA 7® Edition is not
currently executing.
The TYPE=EDIT checking does not detect all initialization file problems. For example, correspondences
between TERM statements and STATIONS statements cannot be tested. Even so, TYPE=EDIT is
effective for other types of conditions. We recommend its use when initialization file changes are
made.
Note: Some selected options of CA JCLCheck™ sometimes require the SYSPROC DD

statement.
ALOG1 Statement
The ALOG1 statement specifies the name of the primary log data set. The statement is supplied with
the skeleton initialization file but sometimes requires changes by the user.
The ALOG1 statement is always required unless the initialization is for a maintenance or batch only
run. In that case, MAIN or REPT was specified for RUNOPT on the INIT statement. Generally, the
continuation of the ALOG1 statement is never necessary.

ALOG1,DSN=x...x
DSN
Specifies the fully qualified data set name of the primary log data set. The value, up to 44
characters, must correspond to the DSN given in the UCC7LOG DD statement in the CA Workload
Automation CA 7® Edition JCL. DSN is required and has no default.
08-Feb-2018 494/722
ALOG2 Statement
The ALOG2 statement identifies the alternate (secondary) log data set. ALOG2 has the same format
as the ALOG1 statement. The difference is the statement keyword identifier, which is ALOG2 for this
statement. The statement is supplied with the skeleton initialization file but sometimes requires that
the user change or remove it.
If a secondary log data set is defined, both primary and secondary logs must be disk data sets.
They must reside on the same volume with unique data set names.
Note: An extra DD is not required in the CA Workload Automation CA 7® Edition JCL for
this secondary log data set, but can be coded so that Space Management systems (like
DFHSM) do not archive the data set. The specified DSN value is used, with the ddname
UCC7LOG, to access the data set. That ddname is used to define the primary log data set
(ALOG1) in the CA Workload Automation CA 7® Edition execution JCL.If a DD statement is
coded, it can be any name. We recommend that the ddname is UCC7LOGS.
If the primary log data set is a tape data set, no secondary log is necessary. You must omit the
ALOG2 statement. We do not recommend that the primary log is on tape.
APPLCTN Statement
APPLCTN statements define all CA Workload Automation CA 7® Edition application modules that are
available for use after initialization is complete. The statements also indicate modules that must be
CA Workload Automation CA 7® Edition resident and modules that require resources for input/output
activity.
All the supplied CA Workload Automation CA 7® Edition application program modules are defined in
the SASSPROG module. The APPLCTN statement included in the skeleton initialization file refers to
this load module and has the following format:
APPLCTN,NAME=SASSPROG,ATTR=LOAD
Additions to the initialization file are made by inserting more APPLCTN statements before SASSPROG
in the initialization file. Additions are only needed for interface modules or to mark modules as PERM
or RESD, if necessary.

APPLCTN,NAME=SASSxxxx[,ATTR={RESD|PERM|LOAD}]
NAME
Specifies the name of a CA Workload Automation CA 7® Edition program module. Value must be
the eight-character program name. The first four characters must be SASS. The last four identify
the CA Workload Automation CA 7® Edition application and the specific module within that
application. NAME is required and has no default. NAME must be specified before the other
keywords.
If ATTR=LOAD, NAME=SASSxxxx is the name of a module that is created from APPLCTN macros
08-Feb-2018 495/722
If ATTR=LOAD, NAME=SASSxxxx is the name of a module that is created from APPLCTN macros
(other modules to be loaded). We recommend that only SASSPROG be used with the ATTR=LOAD
keyword.
ATTR
(Optional) Specifies where to load a module. If ATTR is not coded, the specified module is loaded
in the application pool (APGPL) by CA Workload Automation CA 7® Edition when it is required. If
ATTR=RESD or PERM is entered, the module is loaded during initialization of CA Workload
Automation CA 7® Edition. If used, the value must be one of the following choices:
RESD
The module is made permanently resident within the memory that is allocated to the CA
Workload Automation CA 7® Edition resident pool.
PERM
The module is loaded in the CA Workload Automation CA 7® Edition job pack area by an OS
LOAD macro. Memory for these modules should be in the CA Workload Automation CA 7®
Edition region.
LOAD
Indicates that NAME is a load module that is created from APPLCTN macros. If ATTR=(LOAD,
PERM) is used, each module specified by NAME is marked PERM.
CALBLK Statement
The CALBLK statement identifies the base calendars defined by the user with the CALENDAR macro.
At least one base calendar must be defined before job and/or network schedules can be resolved.
The CA Workload Automation CA 7® Edition SYSGEN generates JCL to create sample base calendars
that are referenced in the skeleton initialization file by CALBLK statements.
Additions to the initialization file are made by inserting additional CALBLK statements or replacing the
sample CALBLK statements in the skeleton initialization file.
A CALBLK statement must be specified for each active base calendar if no CALENDAR statement is
coded. Continuation of a CALBLK statement should never be necessary.
Note: Online Calendars are available through specification of the CALENDAR (see page 497)
initialization file statement. Also available are Perpetual calendars through the same
statement.

CALBLK,NAME=ssssxxyy[,ATTR=LOAD]
08-Feb-2018 496/722
NAME
Specifies the name of a base calendar or a module containing base calendar definitions. NAME is
required and has no default. If NAME specifies an individual calendar, the ssss must be SCAL. If it
specifies a module defining base calendars, use SASS as the first four characters followed by any
other four characters. If it is an individual calendar (SCAL) the xxyy values are:
xx
Identifies the year being defined by the calendar (09, 10, and so forth). The xx value must
correspond to the value specified for YEAR on the CALENDAR macro statement.
yy
Identifies the unique name assigned by the user at the time the base calendar was generated.
The yy value must correspond to the value specified for SCAL on the CALENDAR macro
statement.
ATTR
(Optional) Indicates NAME is a load module that defines base calendars using the CALBLK macros.
If used, value must be LOAD. If omitted, the CALBLK statement specifies the name of an individual
calendar.
CALENDAR Statement
The CALENDAR statement identifies the optional CA Workload Automation CA 7® Edition calendar
PDS where copies of base calendars are stored. This data set is required only if you want to have
online access to base calendars using the DB.2.8 Calendar Maintenance panel, or through the
Calendar facilities available in CA 7® Web Client.
The CALENDAR statement also identifies the optional CA Workload Automation CA 7® Edition
perpetual calendar PDS where members containing criteria for automatically building base calendars
reside. The PCALDSN data set is required only if you want to use the perpetual calendar feature.
See member AL2ALCAL in the CA Workload Automation CA 7® Edition JCL Library CAL2JCL library for
model JCL to allocate either a base calendar PDS or a perpetual calendar PDS. Use the name of the
allocated libraries in the CALENDAR initialization file statement. When you start CA Workload
Automation CA 7® Edition with the modified initialization file, all CA Workload Automation CA 7®
Edition base calendars defined with CALBLK statements are copied to the calendar PDS in a new
format. These existing calendar load modules will not be altered or deleted. New base calendars
created through online facilities do not require CALBLK statements.
All keywords are nonpositional and can appear in any order following CALENDAR.

CALENDAR[,DSN=x...x][,PCALDSN=x...x]
DSN
(Optional) Specifies the fully qualified name of the Calendar PDS (partitioned data set).
PCALDSN
(Optional) Specifies the fully qualified name of the perpetual calendar PDS (partitioned data set).
08-Feb-2018 497/722
More information:
Calendars (https://wiki.ca.com/display/CWAC7E/Calendars)
CANCEL Statement
This statement indicates whether some type of explanation is permitted or required when a CPU job
is manually canceled. The statement is optional. However, if CANCEL is used, the REASON keyword is
required.

CANCEL,REASON={NO|OPTIONAL|REQUIRED}
REASON
Indicates whether a reason is required when manually canceling a job.
NO
Indicates that providing a reason is not required. This value is the default. With this option,
you have no opportunity to change your mind after requesting a C function on the QM.1
panel.
OPTIONAL
Indicates that a reason can be provided but is not required. When specified:
For each C function on a QM.1 panel, transfer is made to the REASON FOR CANCEL panel.
That panel lets the user provide a brief explanation of why the job is canceled. For more
information, see the QM.1 panel. Simply displaying the REASON FOR CANCEL panel also
provides an opportunity for the user to reconsider whether to cancel the job before doing
so.
For each top line CANCEL command, the REASON keyword can be used to provide a brief
explanation of why the job is canceled. For more information about that keyword and its
use, see that command.
REQUIRED
Indicates that a reason must be provided before the cancellation can occur. When specified:
For each C function on a QM.1 panel, transfer is made to the REASON FOR CANCEL panel.
That panel requires the user to provide a brief explanation of why the job is canceled. For
more information, see the QM.1 panel. Simply displaying the REASON FOR CANCEL panel
also provides an opportunity for the user to reconsider whether to cancel the job before
doing so.
For each top line CANCEL command, the REASON keyword must be used to provide a brief
explanation of why the job is canceled. For more information about that keyword and its
use, see that command.
08-Feb-2018 498/722
CPU Statement
In most cases, the CPU statement is not needed. By default, JCL for CPU jobs is written directly to an
internal reader on the CA Workload Automation CA 7® Edition host. This method is known as direct
submission of CPU jobs. Direct submission is the most efficient mode of CPU job submission. We
recommend this option when CA Workload Automation CA 7® Edition is running in a shared spool or
single CPU environment.
If jobs must be submitted to a system that does not share spool with the CA Workload Automation
CA 7® Edition host, then CA Workload Automation CA 7® Edition can be configured for indirect
submission of CPU jobs. In this mode, CA Workload Automation CA 7® Edition writes JCL to a transfer
file known as a submit data set. This file resides on a device that is shared between CA Workload
Automation CA 7® Edition and an ICOM running on the system where the job is to be submitted.
When a job is to be submitted, CA Workload Automation CA 7® Edition writes the JCL to the submit
data set and then signals ICOM to read the JCL and write it to an internal reader on the ICOM host.
This method is a less efficient and more costly method of submitting CPU jobs and is not
recommended for optimal performance.
If you do not intend to use a submit data set, the CPU statement is unnecessary.
If you intend to use a submit data set, use CPU statements to identify all the destinations (internal
reader and submit data sets) where CA Workload Automation CA 7® Edition writes JCL for CPU jobs.
In the following items, two example configurations are considered.
CA Workload Automation CA 7® Edition resides on SYSA. SYSA shares spool with SYSB and SYSC.
CA Workload Automation CA 7® Edition submits jobs to these three systems. CA Workload
Automation CA 7® Edition writes all JCL to internal readers on SYSA.
No CPU statement is needed.
CA Workload Automation CA 7® Edition resides on SYSA. SYSA shares spool with SYSB and SYSC.
SYSD does not share spool with these systems. CA Workload Automation CA 7® Edition must
submit jobs to all these systems. CA Workload Automation CA 7® Edition submits jobs to SYSA,
SYSB, and SYSC by writing JCL to internal readers on SYSA. JCL for jobs that are destined for SYSD
is written to a submit data set.
Two CPU statements are required. One CPU statement identifies the internal reader for jobs that
can be submitted from SYSA. Another CPU statement identifies the submit data set used to
submit jobs to SYSD.
A CPU statement is supplied with the skeleton initialization file. Modify this statement as necessary to
fit your environment.
The CPU statement can be continued. All keywords are nonpositional and can appear in any order
following the CPU keyword.

CPU,BARRIER=nnnn,DDNAME=xxxxxxxx,HOST=host,MAINIDS={SYn|(SYn,...)}
BARRIER
Specifies the maximum number of CA Workload Automation CA 7® Edition submitted jobs to be
allowed in the host system job queue at any one time. Value must be a decimal number, up to
four digits. BARRIER is required and has no default.
08-Feb-2018 499/722
DDNAME
Specifies the name of the DD statement in the CA Workload Automation CA 7® Edition JCL that
defines this submit data set or internal reader. Value must be the eight-character ddname to
which job submission for this CPU is done. DDNAME is required and has no default.
Note: A DDNAME=UCC7IRDx denotes an internal reader for the host job entry subsystem,
where x can be any valid character. A corresponding JCL statement must be added to the
CA Workload Automation CA 7® Edition JCL with the DDNAME pointing to an internal
reader.
HOST
Specifies the job entry subsystem to which JCL is submitted. Value must be JES2 or JES3. HOST is
required and has no default.
MAINIDS
Specifies the CA Workload Automation CA 7® Edition main ID that is assigned to the submit data
set or internal reader. Multiple main IDs can be specified as a sublist, which is enclosed in
parentheses and separated by commas. MAINIDS is required and has no default. Value must be in
the format SYn where n can be:
0
Indicates where the JCL for jobs without a specific MAINID (1 through 7) or with MAINID=ALL
on the DB.1 panel is written.
1-7
Indicates a main ID number that is used on the DB.1 panel for each job to indicate the CPUs
on which a job can or cannot execute. Specific main IDs, SY1 through SY7, can appear in
multiple CPU statements. This causes the JCL for a job with a matching ID to be written to the
submit data set or internal reader that the DDNAME keyword specifies.
*
Indicates a default. Those jobs with main IDs defined on the DB.1 panel that do not match any
other CPU statement MAINID are written to this default submit data set or internal reader. If
multiple CPU statements are used, specify SY* only on one of them.
CUST Statement
The CUST statement specifies a heading that is shown on logo panels and APA graph displays. This
name typically contains the company name that the user supplies. This statement must immediately
follow the RESIDENT statement and cannot be omitted. Continuation is never needed. Comments are
not permitted at the end of this statement. All text that is entered is considered as part of the ID.

CUST,ID=xx...x
08-Feb-2018 500/722
ID
Specifies the heading value that appears on CA Workload Automation CA 7® Edition logo panels
and APA graphs. The value can be any string of characters, up to 44, that the user wants. At least
one nonblank is required.
DAIO Statement
The DAIO statement defines the device type for the checkpoint data set.
The DAIO statement is supplied with the skeleton initialization file. Change the device type if
necessary.
The DAIO statement is required for every initialization of CA Workload Automation CA 7® Edition. The
statement must not appear more than once in the initialization file. No continuation is necessary.

DAIO,DASD=xxxx[,BUFSIZE=1024][,IOBS={3|n}][,RECORDS=nn]
DASD
Specifies the type of direct-access device on which the queue data sets reside. DASD is required
and has no default. Value must be one of the following choices:
3375
Indicates a 3375 DASD device.
3380
3390
9345
BUFSIZE
(Optional) Specifies the physical block size for the queue data sets. Value must be 1024 bytes
(BUFSIZE=1024). If omitted, the BUFSIZE value defaults to 1024.
IOBS
(Optional) Specifies the number of input/output blocks to be created at initialization time for
concurrent queue access. Value can be changed, but we recommend that the value supplied with
the distributed version of the product (IOBS=10) is retained initially. If using Parallel Submission
Process (OPTIONS PSP=Y), set the IOBS value as 5 plus number that is specified in the OPTIONS
MAXSUBOUT parameter. As the number of active terminals increases, it is sometimes necessary
to increase the number of input/output blocks. The default is 3.
RECORDS
(Optional) Specifies the number of records per track for the queue data sets. If omitted, RECORDS
is automatically determined from the DASD device type. If coded, must be one of the following
values:
08-Feb-2018 501/722
25
Indicates 3375-type devices.
31
33
28
DBASE Statement
The DBASE statement is required and provides information about database processing options. At
least one keyword must be specified on the DBASE statement; it can be any keyword. A DBASE
statement is supplied with the skeleton initialization file. The statement can be modified, if
necessary.
Only one DBASE statement can be specified. All keywords are nonpositional and can appear in any
order following DBASE.

DBASE[,DEFAULTAG={DEFAULTA|jobname}]
[,DEFAULTJOB={DEFAULTS|jobname}]
[,DEFAULTPS=jobname]
[,DEFAULTXPJ={DEFAULTX|jobname}]
[,JOB=xxxxxxxP]
[,LDJOBNM=xxxx]
[,LOADDSNS={YES|NO}]
[,PROCLOAD={CA7LOAD|procname}]
[,RLOGDAYS={5|nnn}]
[,RSRC={Y|YES|M|MAINT}]
DEFAULTAG
Specifies the default job name for all AGJOB jobs added later. If a job is defined to the database
with this name, the values for fields of this job, except JOBL, MEMBER, and UID fields, are the
default values for the new job. The default job name is DEFAULTA.
DEFAULTJOB
Specifies a job on the database to use for default values for all job adds. If a job is defined on the
database with this name, the values for fields of this job are used as default values for the new
job, except for the JOBL, MEMBER, and UID fields. The default job name is DEFAULTS. For the
Personal Scheduling exceptions, see the DEFAULTPS keyword.
DEFAULTPS
Specifies a job on the database to use for default values for jobs added through the CA 7 Personal
Scheduling facility. If not specified, the Personal Scheduling jobs obtain defaults from the regular
default job. See the preceding DEFAULTJOB keyword.
08-Feb-2018 502/722
DEFAULTXPJ
Specifies the default job name for all XPJOB jobs added later. If a job is defined to the database
with this name, the values for fields of this job, except for the JOBL, MEMBER, and UID fields, are
the default values for the new job. The default job name is DEFAULTX.
JOB
Specifies the name of a CA Workload Automation CA 7® Edition defined job to submit
automatically for dumping the primary log data set from a disk to tape. Value must be the eight-
character job name of the log data set dump job ending with a P. Another job name with the
same first seven characters plus a suffix of S is used for dumping the secondary log data set. Both
jobs must be defined in the CA Workload Automation CA 7® Edition database and the JCL must
reside in one of the JCL data sets defined to CA Workload Automation CA 7® Edition in an
initialization file JCL statement. JOB is optional. If omitted, automatic submission of jobs for
execution is suspended when the log data set becomes full and CA Workload Automation CA 7®
Edition stops.
LDJOBNM
Specifies the first four characters to use for the load-only job names that are generated for top
line LOAD commands. Four characters must be specified. If used, the load-only job name
becomes xxxxnnnn, where xxxx is the LDJOBNM value and nnnn is the CA Workload Automation
CA 7® Edition assigned job number. All load-only jobs then execute with this name. LDJOBNM is
optional. If omitted, the normal job name is used.
Note: When this keyword is used, the existing JOB statements for jobs being loaded must
allow eight positions for the job name; otherwise JCL syntax errors result.
LOADDSNS
Specifies whether the CA Workload Automation CA 7® Edition LOAD process build data set
information and requirement entries for jobs. This setting only applies to jobs that are marked as
MAINT=Y on the DB.1 panel.
YES
Indicates that the LOAD process adds DD information to the CA Workload Automation CA 7®
Edition database for the MAINT=Y jobs. YES is the default.
NO
Indicates that the LOAD process ignores any DD information for MAINT=Y jobs; bypassing
adding the information to the CA Workload Automation CA 7® Edition database.
If this option is specified as NO, consider the following items:

Benefits:
Smaller CA Workload Automation CA 7® Edition database files
Faster LOAD processing
No need to mark data sets PERM, because MAINT=Y is used
Reduced maintenance of the database files
Data set triggers can be used when the data sets are added to the database manually or the
08-Feb-2018 503/722
Data set triggers can be used when the data sets are added to the database manually or the
job is MAINT=N
Functions not available for MAINT=Y jobs when LOADDSNS=NO is used:
Automatic building of data set requirements during the CA Workload Automation CA 7®

Edition LOAD process. LJOB,JOB=xxx,LIST=RQMT show no data set requirements unless they
are added manually.
Data set information added to the database files. The LDSN does not reflect any data sets that
the jobs are using.
Job data set DD/dsn information. LJOB,JOB=xxx,LIST=STEPDD show only the steps for the job,
not data set information.
SQL reports for data set/job.
Forecast commands for resources do not reflect any information that is based on data sets
(tape pull lists, and so on). FTAPE (and FQTAPE) are no longer useful.
Workload balancing and workload planning no longer have tape information to work with (the
TAPE1 and TAPE2 values on the DB.1 (JOB) panel always show 0). You are unable to use WLB
to balance these jobs that are based on tape drive usage (unless the tape values are filled in
manually).
PROCLOAD
Specifies the one- to eight-character procedure name to insert to cause CA Workload Automation
CA 7® Edition Load processing. The Load processing builds job profiles from submitted JCL. The
default is CA7LOAD, which is generated as part of the CA Workload Automation CA 7® Edition
installation.
RLOGDAYS
This parameter specifies the number of days of CA Workload Automation CA 7® Edition run log
data that are kept for access online. This statement is optional and has a default of 5. The
maximum value is 365. Consider the following items when increasing this value:
Important! The size of the run log is one or more entries per job per day. Each day can
take up a considerable number of rows in the database table.
The LRLOG command can take longer as the number of days is increased (because more data is
processed).
RSRC
Specifies the type of Virtual Resource Management (VRM) support that is activated during the
product initialization.
YES
Specifies full VRM support. YES is the default setting when a DBASE statement is provided.
08-Feb-2018 504/722
MAINT
Permits the maintenance of the database without the resource management during the job
submission process.
DRCLASS Statement
The DRCLASS statement provides one or more disaster recovery classes to make active when CA
Workload Automation CA 7® Edition starts. The DRCLASS statement cannot be continued. You can
repeat it as many times as necessary to specify all the disaster recovery classes.
The DRCLASS statement does not put CA Workload Automation CA 7® Edition in disaster recovery
mode.
The DRCLASS statement is optional. However, if DRCLASS is used it must be after the INIT2
statement. The CLASS keyword is required.

DRCLASS,CLASS=(class,...)
CLASS
Specifies one or more disaster recovery classes that should be active when CA Workload
Automation CA 7® Edition starts. Each disaster recovery class can be one through eight characters
long.
DRMODE Statement
The DRMODE statement specifies global options to use when you place CA Workload Automation CA
7® Edition in disaster recovery mode.
The DRMODE statement does not put CA Workload Automation CA 7® Edition in disaster recovery
mode.
Place the DRMODE statement after the INIT2 statement.

DRMODE[,DEFCLASS={**NONE**|value|@SYSTEM}]
[,RQMTS={DR|ALL}]
[,TRIGGERS={DR|ALL|NONEXEC}]
[,VERIFY={NO|YES}]
DEFCLASS
Provides a default disaster recovery class for jobs without a disaster recovery class. The class is
defined on the job definition panel. DEFCLASS can provide a specific value or can have the
reserved word of @SYSTEM. DEFCLASS=@SYSTEM causes CA Workload Automation CA 7® Edition
to use a job's SYSTEM field as the disaster recovery class for that job. DEFCLASS has a default of
**NONE**, which is never an active disaster recovery class. DEFCLASS can be one to eight
characters.
08-Feb-2018 505/722
RQMTS
Determines whether CA Workload Automation CA 7® Edition honors all job requirements or only
those requirements with an active disaster recovery class. RQMTS=DR, the default, indicates that
CA Workload Automation CA 7® Edition, when running in disaster recovery mode, automatically
satisfies job requirements when the disaster recovery class of the predecessor job is not active.
RQMTS=ALL indicates normal job requirement processing occurs.
TRIGGERS
Determines what jobs and how CA Workload Automation CA 7® Edition triggers when running in
disaster recovery mode. TRIGGERS=DR, the default, indicates that only jobs with an active
disaster recovery class are triggered. TRIGGERS=ALL indicates normal job triggering occurs.
TRIGGERS=NONEXEC indicates that all jobs are triggered, but jobs with an inactive disaster
recovery class are marked as nonexecutable.
Note: For more information about nonexecutable jobs, see the EXEC field description on
the job definition panel.
VERIFY
Lets the operator confirm a start of CA Workload Automation CA 7® Edition in disaster recovery
mode. If you start CA Workload Automation CA 7® Edition with the parameter DRMODE=YES and
the DRMODE initialization file statement has VERIFY=YES, a WTOR is issued. The operator can
confirm the start of CA Workload Automation CA 7® Edition in disaster recovery mode, let CA
Workload Automation CA 7® Edition start in normal mode, or shut CA Workload Automation CA
7® Edition back down. The default is VERIFY=NO.
EMAIL Statement
The EMAIL statement is required when you want to use the CA Workload Automation CA 7® Edition
email interface. The EMAIL statement identifies the location of the SMTP (email) server. The EMAIL
statement also identifies the names of the data sets that contain the email addresses and templates.

EMAIL,ESERVER=xxx[,EADDRLIB=dsname]
[,EFROM={CA-7|name}]
[,EMAILLIB=dsname]
[,EPORT={25|nnnnn}]
[,EREPLY={CA-7@do.not.reply|email-address}]
[,ETIMEOUT={10|nn}]
ESERVER
The ESERVER keyword is required on the EMAIL statement.
Defines the name or IP address of the primary email server that CA Workload Automation CA 7®
Edition uses when sending emails. If a name is specified, it must be known to a domain name
server (DNS) so that CA Workload Automation CA 7® Edition can resolve it to an IP address. IP
addresses can be in either IPv4 format n.n.n.n or IPv6 format x:x:x:x:x:x:x:x. The n is a decimal
number from 0 through 255 and x is a hexadecimal number from 0 through FFFF. Leading zeros
can be specified for both. The short form of an IPv6 address using a double colon (::) can be used.
The maximum length for a name is 70 characters. The name can contain uppercase, lowercase,
and special characters (such as periods). Sites sometimes must specify the name as a fully
qualified DSN name, such as "SERVERNAME.COMPANY.COM".
08-Feb-2018 506/722
qualified DSN name, such as "SERVERNAME.COMPANY.COM".

The SMTP (email) server can be on the same z/OS image with CA Workload Automation CA 7®
Edition, another z/OS image, or a distributed system. The only requirement is that a TCP/IP
connection is available between the z/OS image where CA Workload Automation CA 7® Edition is
running and the system where the SMTP server is located.
Sometimes CA Workload Automation CA 7® Edition cannot establish a connection with the SMTP
(email) server that is specified on the ESERVER keyword. In this case, CA Workload Automation CA
7® Edition attempts to use the SMTP server on the z/OS system where CA Workload Automation
CA 7® Edition is running. If a connection cannot be established to the SMTP server on the local
system, the email is not sent.
If used, configure the SMTP server on the local z/OS system to forward emails to the normal
SMTP server of the site.
EADDRLIB
Specifies the data set name of a RECFM=FB, LRECL=80 PDS. Each member in the PDS contains one
or more email addresses to which an email can be sent. For information about the format of the
members, see Email Address Members (https://wiki.ca.com/display/CWAC7E/Email+Address+Members).
The PDS is dynamically allocated at CA Workload Automation CA 7® Edition startup. Optionally,
the PDS can be allocated in the CA Workload Automation CA 7® Edition JCL with the DDNAME of
EADDRLIB.
If the EADDRLIB PDS is not allocated, the CA Workload Automation CA 7® Edition email interface
is disabled.
EFROM
Specifies the "from" name that is displayed on the email when it is received. The default value is
"CA-7". Any mixed case value can be specified, up to 70 characters. The value cannot contain
blanks or commas. Underscores can be used instead of blanks.
The EFROM value can be changed without restarting CA Workload Automation CA 7® Edition by
using the following command:
/EADMIN,EFROM=xxxx
The /EADMIN command, however, converts all lowercase letters to uppercase.
EMAILLIB
Specifies the data set name of a RECFM=FB, LRECL=80 PDS. Each member in the PDS contains the
contents (template) of an email that can be sent. For information about the format of the
members, see Email Address Members (https://wiki.ca.com/display/CWAC7E/Email+Address+Members).
The PDS is dynamically allocated at CA Workload Automation CA 7® Edition startup. Optionally,
the PDS can be allocated in the CA Workload Automation CA 7® Edition JCL with the DDNAME of
EMAILLIB.
If the EMAILLIB PDS is not allocated, the CA Workload Automation CA 7® Edition email interface is
disabled.
EPORT
Specifies the port number to use when communicating with the SMTP (email) server. The default
is 25, which is the well-known port number for SMTP and is rarely, if ever, changed. Valid values
are 1 through 65535.
EREPLY
Specifies the default return email address to use when email recipients reply to email sent from
CA Workload Automation CA 7® Edition. The default value is "CA-7@do.not.reply" that prevents
any email replies from ever being delivered.
Do not enclose the value in quotes.
Sites who want email replies to be delivered can provide a valid email address on the EREPLY
08-Feb-2018 507/722
Sites who want email replies to be delivered can provide a valid email address on the EREPLY
keyword. Any mixed case value can be specified, up to 70 characters. Remember that the value
cannot contain commas.
The EREPLY value can be changed without restarting CA Workload Automation CA 7® Edition by
using the following command:
/EADMIN,EREPLY=xxxx
The /EADMIN command, however, converts all lowercase letters to uppercase.

Address members (in the EADDRLIB PDS) can also override the EREPLY value for a specific email.
For information about the format of the members, see Email Address Members (https://wiki.ca.com
/display/CWAC7E/Email+Address+Members).
ETIMEOUT
Specifies how many seconds CA Workload Automation CA 7® Edition waits for responses from the
SMTP (email) server. The default is 10 seconds. The valid values are 5 through 20 seconds.
Because emails are sent from a separate subtask in CA Workload Automation CA 7® Edition, the
communication with the SMTP server does not affect normal CA Workload Automation CA 7®
Edition tasks.
CA Workload Automation CA 7® Edition can recover from some timeout situations when
communicating with the SMTP server and can still send the email successfully. Increase
ETIMEOUT only when many timeout messages are issued (CAL2E010W messages).
END Statement
The END statement terminates the initialization file. The statement is optional but when used must
be the last statement.

END
END has no keywords. END must begin in column 1.
FMTBLK Statement
The FMTBLK statement identifies all format block modules that are used for message input and
output by the CA Workload Automation CA 7® Edition applications.
As with APPLCTN statements, the FMTBLK statements for all supplied CA Workload Automation CA 7®
Edition format blocks are defined in two load modules. These modules are SASSFMTA, the load
module containing all batch FMTBLK statements, and SASSFMTH, the load module containing all
online FMTBLK statements. Two FMTBLK statements are included in the skeleton initialization file
referring to these load modules. They have the following format:
FMTBLK,NAME=SASSFMTH,ATTR=LOAD
FMTBLK,NAME=SASSFMTA,ATTR=LOAD
Additions to the initialization file are made by inserting extra FMTBLK statements before the ones
included in the skeleton initialization file. A continuation is almost never necessary. Do not specify
the optional keyword (ATTR) before FMTBLK or NAME.
08-Feb-2018 508/722

FMTBLK,NAME=SFMxyyyy[,ATTR={RESD|PERM|LOAD}]
NAME
Specifies the name of a format block module. NAME is required and has no default. Value must
be in the form SFMxyyyy, as follows:
x
Indicates the device class for which the module is used. Online devices require an H. Batch
type devices require an A.
yyyy
Indicates the CA Workload Automation CA 7® Edition application programs to which the
format block belongs.
ATTR
(Optional) Specifies how to load the format block. If not specified, CA Workload Automation CA
7® Edition loads the format block as needed for terminal input and output. If ATTR=RESD or
PERM, the format block is loaded during CA Workload Automation CA 7® Edition initialization. If
used, the value must be one of the following choices:
RESD
The format block is made permanently resident within the memory that is allocated to the CA
Workload Automation CA 7® Edition resident pool.
PERM
The format block is loaded in the CA Workload Automation CA 7® Edition job pack area by an
OS LOAD macro.
LOAD
If ATTR=LOAD is used, the NAME is the name of a load module that is created from FMTBLK
macros. In this case, the NAME must be of the form SASS xxxx.
We recommend that ATTR=LOAD is only used with the supplied initialization file statements
that specify SASSFMTH and SASSFMTA. Adding FMTBLK statements is mostly unnecessary.
The supplied two are usually sufficient.
GROUP Statement
The GROUP statement defines the name and characteristics of a logical line group. With this group,
you can associate one or more physical lines with terminals. Multiple line groups (and GROUP
statements) are required when terminals with varying device classes are defined. GROUP statements
are supplied with the skeleton initialization file to define several types of terminal groups. They can
require modification to fit the user environment.
The line group is the top level of a hierarchical structure that includes groups, lines, and terminals.
The LINE, and TERM statements must follow the GROUP statement. They identify the elements of
that group. You can define multiple line groups. Specify all the associated lines and terminals before
the next GROUP statement defining a new line group is introduced. The following example shows the
sequence of the GROUP, LINE, and TERM statements:
GROUP,...
LINE,...
TERM,...
08-Feb-2018 509/722
TERM,...
TERM,...
GROUP,...
LINE,...
TERM,...
and so forth.
At least one GROUP statement is required to allow for definition of the CA Workload Automation CA
7® Edition master terminal (for online initialization), or a batch terminal to be used for input and
output (for batch or maintenance initialization). The GROUP statement can be continued.

GROUP,DEVICE=device,LNAME={xxxxxxx|(xxxxxxx,...)},NAME=xxxxxxx [,OPEN={NO|YES}]
[,VLOGOFF={PFnn|PAnn}]
DEVICE
Specifies the symbolic device class of the terminal belonging to the line group. DEVICE is required
and has no default. Use one of the following values:
3270V
Indicates that the line group contains 3270-type VTAM terminals and optionally, the
associated printer. These terminals can be local or remote.
BATCH
Indicates that the line group consists of a single batch terminal. No more than eight batch
terminal groups (with DEVICE=BATCH) can be defined for each CA Workload Automation CA
7® Edition initialization.
CCI
Indicates that the line group consists of a single CAICCI terminal to use with either the CA
Workload Automation CA 7® Edition CAICCI terminal or with a CA Workload Automation CA
7® Edition TCP/IP terminal.
CONSL
Indicates that the line group consists of the OS system console. Only one GROUP with
DEVICE=CONSL can be specified per CA Workload Automation CA 7® Edition initialization.
When this is opened, communication is performed using the MODIFY command.
TRLDV
Indicates that the line group consists of the logical terminal to use for trailer step transactions.
Only one GROUP with DEVICE=TRLDV can be specified per CA Workload Automation CA 7®
Edition initialization.
TRXDV
Indicates that the line group consists of logical terminals that are dedicated to transactions
scheduled internally by CA Workload Automation CA 7® Edition functions. At least one such
terminal must be defined if either of the following CA Workload Automation CA 7® Edition
functions are used:
ARF (RESTART,ARF=YES is specified)
CA Workload Automation CA 7® Edition XPS SERVER support
08-Feb-2018 510/722
BSAM
Indicates that the line group consists of a single, print-image browse data set to receive most
of the CA Workload Automation CA 7® Edition messages. Only one group with DEVICE=BSAM
can be specified.
LNAME
Specifies the name, up to seven characters, of the line that is assigned to this line group. Value
must be the line names that the NAME parameter on the associated LINE statements defined. If
multiple line statements are input after the GROUP statement, specify multiple line names here
as a sublist separated by commas and enclosed in parentheses. LNAME is required and has no
default.
NAME
Specifies the name, up to seven characters, which are associated with the line group.
For the browse data set, the name must be BROWSE, which is the ddname that is used to
define the data set in the CA Workload Automation CA 7® Edition execution JCL.
For batch terminals (DEVICE=BATCH), the NAME must correspond to the first seven characters
of the ddname in the JCL that defines the input and output data set pair. A separate GROUP,
LINE, and TERM statement is required for each batch terminal. This requirement implies a
separate pair of input and output DD statements for each batch terminal that is defined in the
CA Workload Automation CA 7® Edition JCL. The last character of the ddname in the JCL is
either an I for input data set or O for output data set.
For VTAM terminals (DEVICE=3270V), only one GROUP and LINE statement is necessary to
define all VTAM terminals, because only one ACB is opened.
OPEN
Specifies whether the terminals belonging to this group are available for processing transactions
(when the initialization is complete) without manual intervention by the MTO. OPEN is optional. If
used, use one of the following values:
NO
None of the terminals in the line group is immediately available on completion of
initialization. NO is the required value when DEVICE is specified as BATCH or BSAM. For other
DEVICE values, the MTO has to manually activate the lines in the group to make the terminals
available. NO is the default.
YES
All terminals in the line group are immediately available on completion of initialization. YES
must be used if either DEVICE=TRLDV or TRXDV is specified.
VLOGOFF
Specifies the program function (PF) or program access (PA) key that is used to log out from CA
Workload Automation CA 7® Edition and return to VTAM. The format for program function keys is
PFnn where nn is a number from 01 to 24. The format for program access keys is PA nn where nn
is a number from 01 to 03. A two-digit number is required such as PA01; PA1 is invalid. VLOGOFF
is optional and is used with DEVICE=3270V only. When omitted, a program function key or
program access key is not used to return to VTAM unless VLOGOFF is specified with the TERM
statement. When specified on the GROUP statement, the specified key becomes the default for
08-Feb-2018 511/722
statement. When specified on the GROUP statement, the specified key becomes the default for
all 3270V terminals whose TERM statement does not specify a VLOGOFF parameter. If not
specified in either statement, the terminal operator must issue a /CLOSE command, with no
parameters, to return to VTAM.
INIT2 Statement
The INIT2 statement is optional. When used, it indicates the beginning of the second phase of the
initialization process. It is supplied with the skeleton initialization file and requires no changes.

INIT2
INIT2 has no keywords. INIT2 must begin in column 1.
INIT Statement
The INIT statement specifies the initialization options to use when activating CA Workload
Automation CA 7® Edition and the hardware/software configuration of the host environment on
which CA Workload Automation CA 7® Edition is active. This list shows the options:
The type of initialization processing to perform.
Run options to be in effect for CA Workload Automation CA 7® Edition.
The operating system, job entry subsystem, and CPU configuration.
Whether the operator is to validate the system date and time of day at startup time.
Whether to collect and log performance data for Metrics reporting.
The INIT statement must always be present. You can specify it only once, and you can continue it. All
keywords are nonpositional and can appear in any order following INIT.

INIT,CONFIG=(xxx,yyyy),TYPE=type [,METRICS={YES|NO}]
[,PERFORM=(n,...)]
[,{RUNOP|RUNOPT}=runopt]
[,TIMLIM=mmm]
[,VALIDATE={NO|nn}]
CONFIG
Specifies the operating system, job entry subsystem, and CPU configuration of the host
environment on which CA Workload Automation CA 7® Edition is active. Multiple options can be
specified as a sublist, which is enclosed with parentheses and separated by commas. CONFIG is
required and has no defaults. Value is given as a subparameter list. Values must be as follows:
xxx
Identifies the operating system.
Value: MVS
08-Feb-2018 512/722
yyyy
Identifies the job entry subsystem.
Value: JES2 or JES3
TYPE
Specifies the type of initialization process to perform. TYPE is required and has no default. Any
TYPE specification parameter on the EXEC statement in the CA Workload Automation CA 7®
Edition JCL overrides this TYPE parameter. However, include one here. The startup parameters
contain more information about this parameter. Briefly, the value must be one of the following
types:
CKPT
Performs the same functions as an ERST start except that the checkpoint file is reinitialized.
Use TYPE=CKPT the first time that an instance is started with a new release of CA 7.
WARM
Reactivates CA Workload Automation CA 7® Edition after a normal shutdown and if no
environmental changes are made.
ERST
This value is used to restart CA Workload Automation CA 7® Edition after certain system
failures or after certain initialization file changes.
COLD
Reactivates CA Workload Automation CA 7 Edition after certain system failures that are not
recoverable with ERST or activates CA Workload Automation CA 7 Edition after the first
installation. This value can also be used simply to purge the queues, except for the prior run
queue.
FORM
Performs the same functions as a COLD start except that the prior run queue is also purged.
Note: The TYPE= in the PARM in the CA Workload Automation CA 7® Edition PROC
overrides whatever is on the INIT statement TYPE= keyword.
The TYPE= coded on the CA Workload Automation CA 7® Edition PROC parameter can specify one
of the following options, which are not valid on the initialization file INIT statement.
DORM
This value is used to start a dormant copy.
EDIT
Used to verify the initialization file. Offline verification is available.
METRICS
Specifies whether to collect and log performance-related data that can be used in CA Workload
Automation CA 7 Edition history reporting to view and compare performance data.
YES (default)
Indicates that performance-related data is collected and logged.
NO
08-Feb-2018 513/722
NO
Indicates that performance-related data is not collected nor logged.
Note: For information about Metrics, see the /DISPLAY,PERF= command and the Metrics
Report SASSHR25.
PERFORM
Indicates the performance options that are required for this execution of CA Workload
Automation CA 7® Edition. PERFORM is optional. Value can be one or more single character
numbers, which are enclosed in parentheses and separated by commas, as follows:
1
Skips SMF type-14 records. This value reduces database access during the SMF feedback
process, and suppresses messages about input data sets not used.
2
Not used
3
Not used
4
Not used
5
Skips duplicate checking for queue adds. This option reduces EXCPs on the queue data sets.
Using a PERFORM option of 5, duplicate checking can still be done in cases where a CA
Workload Automation CA 7® Edition outage occurs during a schedule scan.
6
Skips DSORG=PO data set feedback. This setting reduces SMF task usage.
7
Causes CA Workload Automation CA 7® Edition to use dynamic allocation instead of OPEN
TYPE=J. This option does not require the use of U7volser DD statements. If no U7volser DD
statements are in the CA Workload Automation CA 7® Edition JCL, option 7 is assumed. If at
least one U7volser DD statement is in the CA Workload Automation CA 7® Edition JCL, 7, 8, or
both must be specified to cause CA Workload Automation CA 7® Edition to use dynamic
allocation.
8
Causes CA Workload Automation CA 7® Edition to use dynamic allocation instead of OPEN
TYPE=J. The use of 8 without specifying 7 indicates that the U7volser DD statements in the CA
Workload Automation CA 7® Edition JCL are required although dynamic allocation is used for
the data sets. If at least one U7volser DD statement is in the CA Workload Automation CA 7®
Edition JCL, 7, 8, or both must be specified to cause CA Workload Automation CA 7® Edition to
use dynamic allocation.
RUNOP|RUNOPT
Indicates the specific run options active when an initialization is complete. Multiple options can
be specified as a sublist, which is enclosed within parentheses and separated by commas. RUNOP
(T) is optional. If REPT and MAIN are omitted, an online run is assumed. Do not use MAIN and
08-Feb-2018 514/722
(T) is optional. If REPT and MAIN are omitted, an online run is assumed. Do not use MAIN and
REPT for the online execution. The default is NSTA, but the value can be one or more of the
following options:
SCAN
Indicates that schedule scan is to begin when the initialization is complete. SCAN cannot be
specified with REPT or MAIN. Should be specified to engage automatic scheduling functions.
NSTA (default)
NSTA is a dummy entry, meaning that schedule scan is not active when CA Workload
Automation CA 7® Edition initializes.
MAIN
Indicates a maintenance-only run. Information from the communications data set is used to
update the database and queues. No scheduling, job submission, or SMF monitoring is done.
If MAIN is specified, omit REPT and SCAN.
NCWT
Indicates that no wait is allowed when a GETMAIN for more storage fails. CA Workload
Automation CA 7® Edition abends. Do not specify NCWT for online runs.
REPT
New JCL can be added, database maintenance can be performed, and reports can be run. No
scheduling, job submission, SMF monitoring, or SMF updating is done. If REPT is specified,
omit MAIN and SCAN.
TIMLIM
Defines an elapsed time limit for CA Workload Automation CA 7® Edition execution. When the
limit is reached, CA Workload Automation CA 7® Edition automatically shuts down. Value must be
given in minutes. TIMLIM is optional for batch only type runs and should not be specified for
online processing. If omitted, no time limit is imposed for online runs, but 60 minutes is used for
batch-only type runs.
VALIDATE
Specifies whether the operator validates the system date and time at CA Workload Automation
CA 7® Edition startup. The value lets the user specify that operator validation is not performed; or
to define a time tolerance for disabling the operator validation process. The date/time tolerance
defines the allowable difference between the current system date/time values and the latest CA
Workload Automation CA 7® Edition checkpoint date/time values. If the date/time values are
within the time tolerance, operator validation is not performed. VALIDATE is an optional
parameter. If used, the values must be one of the following options:
NO
Indicates that the operator does not perform date/time validation. This value is the default.
nn
Defines a numeric value from 1 to 99 indicating the allowable time tolerance in hours. A value
of 0 (zero) indicates that the operator must always perform a date/time validation regardless
of the date and time values in the system clock or the checkpoint record.
For WARM or ERST starts with VALIDATE=0 or date and time values outside the tolerance, the last
checkpoint and last schedule scan date/time values are displayed through a WTO.
Also, if verification is to be performed, the current system clock date and time values are then
displayed followed by a WTOR requesting operator action. If necessary, the system date and time
08-Feb-2018 515/722
displayed followed by a WTOR requesting operator action. If necessary, the system date and time
should be corrected on all CPUs before responding to the WTOR. Response to the WTOR should
be one of the following options:
U
Indicates that initialization can proceed typically.
NOSCAN
Indicates that initialization can proceed, but schedule scan is disabled.
Following a response of U or NOSCAN, the current system clock date and time values are
displayed again before continuing. This lets the user verify any adjustments made while the
WTOR was outstanding. The results of any adjustment should be verifiable from the before and
after displays.
Whenever nonzero time tolerance values are used, the date and time are validated for only the
CPU on which CA Workload Automation CA 7® Edition is running. The operator should validate
the system clock date and time values on all CPUs before responding to the WTOR.
JCLCHECK Statement
The JCLCHECK statement is required to use the CA JCLCheck™ Workload Automation interface and to
specify options for the CA JCLCheck product. For the Common Component, it is not required unless
you want to override an option that is valid with Common Component.

JCLCHECK[,DDNAME=xxxxxxxx]
[,JSC={N|Y}]
[,MAXUSERS=xxx]
[,TCBSEC={NO|YES}]
DDNAME
Specifies the DDNAME for a DD statement in the execution JCL for CA Workload Automation CA
7® Edition. This statement should point to a sequential data set where installation-specific
runtime options for CA JCLCheck reside. Define the data set as follows:
DCB=(LRECL=80,RECFM=FB,BLKSIZE=80 * nnnn)
Only the following user-specified options are permitted:

EASYRDR, EASYPROC, FEATURE, INPUT, OPTIONS, PASSWORD, PREFIX, PROC, OPROC, PULL,
TERM, VSAM, JCLLIB, LOCATE, NOSP, NOCT and for debugging and security NOSEC, NOACF2,
NOSPIE, DEBUG, DEQUE
Also, the AUTOPROC option is allowed if the following conditions are true:
A SYSPROC DD statement is not coded in the CA Workload Automation CA 7® Edition startup

procedure.
CA Workload Automation CA 7® Edition is operating in a JES2 environment.
08-Feb-2018 516/722
Note: If no SYSPROC DD statement points to procedure libraries and the AUTOPROC

option is not used, an error message is produced and the interface is disabled. For more
information about these CA JCLCheck options and the full CA JCLCheck product options,
see the CA JCLCheck documentation.
JSC
Forces the use of the JCLCheck Common Component even if full CA JCLCheck product is available
(JSC=Y). The default is JSC=N.
If the JSC keyword is not specified, CA Workload Automation CA 7® Edition tries to use the full CA
JCLCheck. If full product is not available, CA Workload Automation CA 7® Edition tries to use the
JCLCheck Common Component. If that is not available, an error occurs.
MAXUSERS
Specifies a maximum limit on the number of concurrent users of the interface. If this value is not
coded, you have no limit on the number of concurrent interface users other than whatever
practical limits may obtain due to resource constraints. If MAXUSERS=0 is specified, the JCLCheck
interface is not used, and no JCL syntax checking can be done with CA Workload Automation CA
7® Edition.
TCBSEC
Enables the TCB security option. The default is NO. CA Workload Automation CA 7® Edition must
have at least EXTERNAL=LOGON coded in the SECURITY statement for this to work. With this
option enabled, TCBSEC=YES, any invocation of the CA JCLCheck interface puts the security token
of the user who issued the command in the TCBSENV field for the current TCB. This allows the
external security package access to the security token for validation during CA JCLCheck
processing. Check the documentation for your external security package for information about
how to enable checking from the TCBSENV field.
JCL Statement
The JCL statement provides information about data sets containing the execution JCL for CPU jobs
and parameter data for XPJOBs to be submitted by CA Workload Automation CA 7® Edition. JCL
statements are supplied with the skeleton initialization file. These statements can be modified as
needed to fit the user's environment.
JCL statements can be specified for every initialization of CA Workload Automation CA 7® Edition.
Multiple JCL statements can be specified if execution JCL resides in more than one data set.
JCL statements are stored in the CA Workload Automation CA 7® Edition database. If

JCLDEFS=INITFILE was specified on the RESIDENT statement, JCL statements specified in the
initialization file are used. If JCLDEFS=DATABASE or VSAM was specified on the RESIDENT statement,
JCL statements stored in the CA Workload Automation CA 7® Edition database are used and JCL
statements specified in the initialization file are ignored.
The JCL statement can be continued.
All keywords are nonpositional and can appear in any order following JCL.
JCL,DSN=x...x,INDEX={nnn|&x...x}
08-Feb-2018 517/722
JCL,DSN=x...x,INDEX={nnn|&x...x}
[,ALT={nnn|&x...x}]
[,DPROC={x...x|*NONE*}]
[,DSORG={PDS|LIB|PAN}]
[,DYN={0|2}]
[,LTERM={MASTER|xxxxxxxx}]
[,MCD=nnnn]
DSN
Specifies the fully qualified name of a data set containing execution JCL that CA Workload
Automation CA 7® Edition is to submit. DSN is required and has no default.
INDEX
Specifies the unique identifier assigned to the JCL data set. INDEX is used to equate a number or a
symbolic value with a data set containing execution JCL. INDEX is required.
nnn
Defines an index number referred to as JCLID or PARMLIB on the job definition panels and in
certain commands. This number can range from 0 through 999. Leading zeros are required
only for CA Librarian® data sets. INDEX number 254 is reserved for the override library, and
255 is reserved for the HELP data set. The default JCLID on the DB.1 panel is zero. We
recommend that you give one JCL data set an INDEX value of zero so that the DB.1 panel JCLID
field is not required for jobs with JCL residing in that data set. This is also applicable to the
Parmlib field on the DB.11 panel. The PARMLIB in the DB.10 panel has no default value
because it is optional.
&x...x
Defines a symbolic index referred to as JCLLIB or PARMLIB on the job definition panels and in
certain commands. A symbolic index consists of an ampersand (&) followed by up to 15
alphanumeric characters. If symbolic indexes are used, JCL libraries must be dynamically
allocated and DYN=2 must be specified. Symbolic indexes can only be used with PDS data sets.
Symbolic value &HELP is reserved for the HELP data set and can be specified instead of index
number 255. All symbolic indexes are assigned an index number of 255. Attributes of a JCL
data set referenced by a symbolic index can be changed with the /JCL command.
ALT
(Optional) Specifies the INDEX value from a previously defined JCL library that will be searched
prior to this one. This works exactly like DD statement concatenation where the ALT is first in the
sequence, but is supported for only one level. Since validation of this parameter is done while the
internal table of JCL libraries is being built, the alternate library must be defined in the
initialization file prior to the statement that references it as an alternate. ALT and INDEX values
cannot be equal in any one JCL statement.
Note: For more information about using this option, see Alternate JCL Libraries.
DPROC
Specifies the data set name of a CA Driver procedure library to be concatenated above the
libraries allocated with the CARPROC DD statement whenever CA Driver is invoked for JCL in the
library defined.
DPROC=*NONE* indicates that CA Driver is not to be invoked for JCL in the library defined.
08-Feb-2018 518/722
DSORG
Specifies the organization of the JCL data set being defined. DSORG is optional. If omitted, the
default is DSORG=PDS. Value, if used, must be one of the following:
PDS
Indicates the data set is an OS partitioned data set. TSO packed data is not supported.
LIB
Indicates the data set is a CA Librarian library. A special DD statement is required for such
libraries using the name JCLnnn, where nnn is three digits (leading zeros required) matching
the value for INDEX.
PAN
Indicates the data set is a CA Panvalet® for z/OS library. A special DD statement is required for
such libraries using the name JCLnnn, where nnn is three digits (leading zeros required)
matching the value for INDEX.
DYN
If dynamic allocation of JCL data sets is used (see the PERFORM keyword of the INIT statement),
this parameter can be used to specify how the JCL data set defined in this statement is allocated.
This option is only valid for PDS JCL data sets (not valid for CA Panvalet for z/OS or CA Librarian
files). Value, if used, must be one of the following:
0
This is the default and indicates the JCL data set is allocated as DISP=SHR for read-only access
and as DISP=OLD for update access.
2
This indicates that the JCL data set is allocated as DISP=SHR for update and for read access.
However, for update, ENQs are issued in an attempt to serialize updates with TSO. This allows
the data set to be browsed with TSO while CA Workload Automation CA 7® Edition updates it,
and allows TSO updates on one member and CA Workload Automation CA 7® Edition updates
on another. If a program other than TSO updates a data set while CA Workload Automation
CA 7® Edition is allocating it with DISP=SHR, simultaneous updates are possible if the other
program does not respect the ENQ conventions used by CA Workload Automation CA 7®
Edition. The ENQs use SYSDSN and SPFEDIT as major names.
DYN=2 can only be used if the dynamic allocation option is used. This option must be used for
libraries defined with symbolic indexes.
Note: CA Panvalet for z/OS and CA Librarian files are read-only files through CA Workload
Automation CA 7® Edition. PDS files can be read and updated by CA Workload Automation
CA 7® Edition. For CA Panvalet for z/OS and CA Librarian data sets the interface must be
installed for CA Workload Automation CA 7® Edition to access the JCL. The DASD on which
PDS files reside must be made accessible to CA Workload Automation CA 7® Edition by
including a U7volser DD statement in the CA Workload Automation CA 7® Edition JCL,
unless the dynamic allocation feature is used. See the PERFORM keyword of the INIT
statement. CA Panvalet for z/OS and CA Librarian data sets require DD statements in the
CA Workload Automation CA 7® Edition execution JCL that include the appropriate DSN
value.
LTERM
08-Feb-2018 519/722
LTERM
Specifies the logical terminal to which prompt messages should be routed for jobs that are
submitted using JCL from this JCL data set.
The job definition panel LTERM field can be used to define a logical terminal for a specific job.
LTERM is optional. If omitted and not defined on the job definition panel, the default is
LTERM=MASTER, the logical terminal that receives the majority of CA Workload Automation
CA 7® Edition messages.
If a logical terminal other than MASTER is specified, it must match a STANIDS value on one of
the STATIONS statements.
Note: If the logical terminal name is defined as a virtual terminal, a CAICCI terminal, or
CONSOLE, the messages are dynamically rerouted to the MASTER terminal. Messages that
are routed to the MASTER terminal are written to the BROWSE DD file.
MCD
Specifies the management code used to access PROD2 members of CA Librarian master files.
Valid only if DSORG=LIB and cannot be used if the library is defined using a symbolic index. If
specified, the value must be four characters in length (leading zeros required) and cannot exceed
8768. For more information, see the CA Librarian documentation.
LINE Statement
The LINE statement corresponds to an I/O (buffer) area built by CA Workload Automation CA 7®
Edition during initialization.
At least one LINE statement is always required to allow for definition of the CA Workload Automation
CA 7® Edition master terminal (for online initialization), or the batch terminal used for input and
output (for batch or maintenance initialization). In the case of virtual terminals, if you have multiple
LINE statements, only one of them can use the virtual terminal special name defined with the TNAME
parameter. The LINE statement can be continued.
All keywords are nonpositional and can appear in any order following LINE.

LINE,NAME=xxxxxxx,TNAME={xxxxxxx|(xxxxxxxx,...)},BUFSIZE=nnnn[,OPEN={NO|YES}]
NAME
Specifies the name, up to seven characters, assigned to the line. Each LINE must have a unique
name. Value must match an LNAME value (on the associated GROUP statement) that identifies
this line. NAME is required and has no default.
TNAME
Specifies the name of the terminals. Value must be the names, up to seven characters, designated
by the NAME parameter on the TERM statements. For VTAM terminals, multiple terminal names
can be specified as a sublist, enclosed in parentheses and separated by commas. For all other
terminal types, you may have only one terminal per line.
To use the virtual terminal feature for VTAM terminals, TNAME must begin with the three
08-Feb-2018 520/722
To use the virtual terminal feature for VTAM terminals, TNAME must begin with the three
characters specified by VTNAME followed by a #, followed by a three-digit number. Leading zeros
are required. If VTNAME= is not coded on the UCC7VTAM statement, the first three characters
must be VTM. This definition represents the maximum number of virtual terminals that can be
used at the same time, with 255 being the maximum number. TNAME is required and has no
default.
Note: You must define virtual terminals to use the CA Workload Automation CA 7® Edition
TSO/ISPF and CA 7® Web Client interfaces.
You need to consider the size of the DQTQ data set when defining virtual terminals.
BUFSIZE
Specifies the line buffer size in bytes. Value depends on the symbolic device type designated by
DEVICE on the associated GROUP statement.
If DEVICE=BSAM, the BUFSIZE value must be the block size of the browse data set.
If DEVICE=BATCH, the BUFSIZE must be the block size of the batch input data set.
If DEVICE=3270x, BUFSIZE must be at least 3120.
If DEVICE=TRLDV, BUFSIZE must be 1024.
If DEVICE=CONSL, BUFSIZE must be 150.
If DEVICE=TRXDV, BUFSIZE must be 1024.
If DEVICE=CCI, BUFSIZE must be at least 3120.
BUFSIZE is required for all DEVICE types except 3270V.
OPEN
Specifies whether the terminals on this line are available for processing transactions (as soon as
initialization is complete) without manual intervention by the MTO. OPEN is optional. If used,
value must be one of the following:
NO
None of the terminals on this line is immediately available. This is the required value when
DEVICE is specified as BATCH or BSAM. For online (3270x) device types, the MTO has to
manually activate the line to make the terminals available. This is the default.
Note: If OPEN=YES is not specified for DEVICE=CONSL, you will get the message IEE324I
MODIFY REJECTED - TASK BUSY when trying to issue a modify command.
YES
All terminals on this line are immediately available on completion of initialization. YES must be
used when DEVICE=TRLDV or TRXDV is specified.
08-Feb-2018 521/722
NETMAN Statement
The NETMAN statement is required to use a real-time problem management interface.

NETMAN,DBASENM=xxxxxxxxxxxxxxxx [,EXIT=xxxxxxxx]
[,GOODCOMP={N|Y}]
DBASENM
Specifies the 16-character name of the database associated with the problem management
system. This database receives the API transactions generated by CA Workload Automation CA 7®
Edition job completions. Embedded blanks are not permitted.
EXIT
Identifies a client-supplied interface module that the CA Workload Automation CA 7® Edition
problem management subtask calls to inspect job completion data.
GOODCOMP
The value of this keyword is used to filter job completion data that is fed as input to the problem
management interface.
N
Completion data is passed to the interface for those jobs that abnormally terminate and for
normally terminated jobs that have been restarted. This value is the default.
Y
All data on all job completions (including jobs that complete typically) are passed to the
interface.
NEWS Statement
The NEWS statement specifies message text that can broadcast a free-form message to users who log
in to CA Workload Automation CA 7® Edition. You can have two NEWS statements in the initialization
file to allow for two lines of message data to appear on the Logon panel. The messages only appear
on the Logon panel. Place this statement in the initialization file after the CUST statement.

NEWS,M=xx...x
M
Specifies the text of the message data to appear on the Logon panel. Value can be any string of
characters, up to 64 characters in length.
OPTIONS Statement
The OPTIONS statement can define various processing options for the system. The statement is
optional. However, if the OPTIONS statement is coded, at least one keyword is required.
08-Feb-2018 522/722

OPTIONS[,ATTACH={ALL|EXEC}]
[,AUTOREQ={NO|YES}]
[,CAL2C900={CURRENT|ORIGINAL}]
[,CMGRDELAY={NO|YES}]
[,CPM={NO|YES|JFMLOAD}]
[,CTIMSG={YES|NO}]
[,DFLTWLB={UCC7RDFL|UCC7Rxxx}]
[,DPROCCOM={NO|YES|xxxxxxxx}]
[,EXPDTCHK={YES|NO}]
[,EXTSCHID={1|nnn}]
[,FCMAXLEV={99|nnn}]
[,GVARLVL={4|n}]
[,GVARRPFX={7|x}]
[,GVARSUB={NO|YES|xxxx}]
[,INITCASE={NO|YES}]
[,JCLDSST={NO|YES}]
[,JCLJOBCK={NO|YES}]
[,JCLTAG={CA-7|INSTANCE}]
[,JFM={NO|YES}]
[,JOBDEL={DELETE|DD|PURGE}]
[,JSOP=(n,...)
[,LATEPROMPT={PROMPT|LATE}]
[,LOADCLASS={8|x}]
[,LOGSUBJCL={NO|YES}]
[,MAXRINGSZ={5|n}]
[,MAXSUBOUT={5|nn}]
[,OVJCL={SCRATCH|NOSCRATCH}]
[,PERMDSN={NO|YES}]
[,PROPDSNU={NO|YES}]
[,PROPMAIN={YES|NO}]
[,PSP={YES|NO}]
[,RLOGCAN={STATUS|CANCL}]
[,RQMT255={NO|YES}]
[,RUNCLASS={9|x}]
[,SHRCRQ={NO|YES|(CA7n,CA7n,...)}]
[,SHRCRQPFX={GLOBAL@|*ALL*|xxxxxxxx}]
[,SHUTDOWN=Zn]
[,SUBMSGLVL=1,2,3,...]
[,SUBSEL={NORM|ENH}]
[,VRMDD={NO|DEF|SUB|YES}]
[,WLBOPT=1]
[,WLMCA7=xxx,...xxx]
[,WLMSE={NO|YES|global-default}]
[,WLMSEVAL={NO|YES}]
[,XQOFF=(a,b,c,...]
ATTACH
Specifies whether JCL attach processing is attempted for nonexecutable jobs.
ALL
Indicates that all jobs, including nonexecutable jobs, have JCL attach processing performed.
EXEC
Indicates that only executable jobs have JCL attach processing performed.
AUTOREQ
Specifies whether CA Workload Automation CA 7® Edition automatically requeues jobs found to
be active on a specific CPU when an IPL of that CPU occurs.
NO
Does not automatically requeue jobs. This value is the default.
YES
08-Feb-2018 523/722
YES
Automatically requeues jobs in the active queue and are running on the CPU that has been
IPLed.
CAL2C900
Specifies the format for message CAL2C900I. The following values are possible for this keyword:
CURRENT
Use the following message format:
CAL2C900I CA-7 CCI Initialization Complete
ORIGINAL
Use the following message format:
CAL2C900I Unicenter CA-7 CCI Initialization Complete
CMGRDELAY
Prompts to permit a modification of the interval between CA Workload Automation CA 7® Edition
reads of the communications data set. If this keyword is not specified, the interval is 10 seconds.
Important! Use this keyword only in consultation with CA Support. Inappropriate use of
this option could have an adverse impact on CA Workload Automation CA 7® Edition
performance.
NO
CA Workload Automation CA 7® Edition wakes up every 10 seconds to read the
communications data set. This value is the default.
YES
CA Workload Automation CA 7® Edition issues a message requesting confirmation of the
interval between reads of the communications data set:
CA-7.IOPT - SHOULD CA-7 READ COMMDS EVERY FIVE SECONDS? REPLY TO CONFIRM (YES
/NO)
Reply YES to confirm the interval. A reply of NO indicates that the duration of the interval
defaults to 10 seconds.
CPM
Used to activate the Critical Path Monitor interface.
NO
Does not activate the CPM Interface. This value is the default.
YES
Activates the CPM interface. Selecting this option has CA Workload Automation CA 7® Edition
generate CPM tracking data for every job that is part of a flow.
When CPM=YES is specified, CA Workload Automation CA 7® Edition verifies that RSRC=YES is
coded on the DBASE statement. Also, CA Workload Automation CA 7® Edition checks for the
existence of a terminal that is defined as DEVICE=CCI. Both conditions must be satisfied to use
CPM.
08-Feb-2018 524/722
JFMLOAD
Does not restrict CPM, which can identify paths in addition to the trigger path. When the
beginning job of a flow is submitted, Jobflow Monitor looks ahead to find the ending job in
the workload. JFM then tries to find all of the paths that link the ending job to the starting job.
When JFM is used, CPM considers job and data set requirements and triggers.
Commands FLOWL and FLOWD cannot be used to monitor and manage flows when
CPM=JFMLOAD is specified.
Note: For more information about this feature, see Use CA CPM (https://wiki.ca.com/display
/CWAC7E/Use+CA+CPM).
CTIMSG
Determines whether to write multiple messages to the CA Workload Automation CA 7® Edition
JES log for each CAICCI terminal session. The messages include the following:
CA-7.XTM0 Session started ...
CA-7.XTM0 Session ended ...
CA-7.SCMK /CLOSE SUCCESSFUL for [group]
CA-7.822 - (line) CLOSED
YES
Continues to write all messages. This value is the default.
NO
Writes only one log message for each CAICCI Terminal session:
CA-7.XTM0 Session ended ...
The other messages are not written.
DFLTWLB
Specifies to load a default workload balancing module during CA Workload Automation CA 7®
Edition initialization. The WLB module must be located in a load library accessible to CA Workload
Automation CA 7® Edition during startup. The module name must meet the workload balancing
module naming requirements of "UCC7Rxxx" where xxx is any valid user-specified characters. If
the DFLTWLB keyword is not specified, the default WLB module UCC7RDFL is used. This keyword
is ignored for WARM and ERST starts of CA Workload Automation CA 7® Edition.
DPROCCOM
Indicates whether to ignore comments inside the CA Driver procedures.
NO
CA Driver performs a variable substitution on procedure statements that begin with '//*'.
Such statements are included in CA Driver expansions. This value is the default.
08-Feb-2018 525/722
YES
CA Driver does not perform a variable substitution on procedure statements that begin with '
//*'. CA Driver ignores these statements, and they are not included in any CA Driver
expansions.
xxxxxxxx
CA Driver does not perform a variable substitution on procedure statements that begin with
the specified character string. CA Driver ignores these statements, and they are not included
in any CA Driver expansions. The length of the character string must not exceed 8 bytes and
must not include blanks or commas. The value also cannot be one of the following values: Y,
YES, N, or NO.
EXPDTCHK
Specifies whether CA Workload Automation CA 7® Edition checks for an expiration date before
updating a data set.
YES
Does not attempt to update the data set when the expiration date has not yet been reached.
The default is YES.
NO
Does not check the expiration date before attempting the update.
Note: Consult with your systems programmer before overriding the default for this option.
If you specify EXPDTCHK=NO, an operator request (WTOR) may be issued asking if CA
Workload Automation CA 7® Edition should be allowed to update the data set when a save
or replace is performed on it (see IBM message IEC507D). The entire CA Workload
Automation CA 7® Edition address space may stop, waiting for the operator to answer the
query.
EXTSCHID
Specifies a global default schedule ID for externally tracked tasks. If an externally tracked task is
not explicitly assigned a nonzero schedule ID, it is assigned this value.
The specified value can range from 1 to 999. The default value is 1.
FCMAXLEV
Permits the specification of the maximum number of levels that a forecast command (including
FSTRUC) goes through before issuing an error message and terminating the forecast. This can
help prevent loops in triggering structures.
The specified value can range from 1 to 999.
If FCMAXLEV is not specified, the default maximum level is 99. The maximum level on individual
commands can be overridden by using the LVL= keyword on the command itself.
GVARLVL
CA Workload Automation CA 7® Edition allows multiple levels of substitution (nesting) in global
variables. That is, a variable can return, as its value, another variable. GVARLVL specifies the
number of levels of substitution allowed. GVARLVL=1 allows one level, which implies no nesting
of variables. The default is GVARLVL=4. If the specified limit is exceeded within a job, a JCL error
occurs.
Nesting occurs only if the name (prefix) of the new variable is returned in the first position of the
contents of the old variable.
08-Feb-2018 526/722
contents of the old variable.

Examples:
Global variable &:ABC returning the string &:XYZ is recursive.
Global variable &:ABC returning XY&:ZW is not recursive because the &: prefix is not in the first
position.
4
Identifies the default levels of substitution.
n
Defines a number 1-255.
GVARRPFX
Specifies the starting character for global reserved variable names. This character is installation-
modifiable. For example, the global reserved variable name (without the prefix specified by
GVARSUB) that returns the four-digit current year is 7YYYY. The 7 is the reserved starting
character referred to by GVARRPFX.
7
This value is the default reserved starting character.
x
Defines any single alphanumeric character.
GVARSUB
Specifies whether any variable substitution takes place outside of CA Driver and, if so, what the
variable prefix should be if the default global variable prefix is not to be used.
NO
Specifies CA Workload Automation CA 7® Edition does not perform variable substitution
outside of CA Driver. This value is the default.
YES
Specifies CA Workload Automation CA 7® Edition does perform variable substitution outside
of CA Driver. This can be done instead of using CA Driver or with CA Driver. The default
variable prefix of "&:" (without the quotes) is to be used for variables to be substituted
through this process.
xxxx
Specifies CA Workload Automation CA 7® Edition does perform variable substitution outside
CA Driver. This can be done instead of using CA Driver or with CA Driver. A one- to four-
character prefix of xxxx is to be used for variables to be substituted through this process.
INITCASE
Determines character translation mode in the CA Workload Automation CA 7® Edition Editor. If
Full Edit Mode is used, then:
NO
Forces the translation of all data to uppercase. This value is the default.
YES
Translation is controlled by case setting commands in the Editor.
08-Feb-2018 527/722
Note: FEM subcommands include MIXED and UPPER. For more information, see Character
Translation (https://wiki.ca.com/display/CWAC7E
/CA+7+Text+Editor+Environment#CA7TextEditorEnvironment-CharacterTranslation).
JCLDSST
Used to let CA Workload Automation CA 7® Edition produce a new log record that contains timing
data for JCL data set accesses. CA Earl™ and CA Easytrieve® report 038 can be used to report on
this. Using JCLDSST=YES can create many extra log records and can affect the overall
performance. Thus, use this option with caution.
NO
Does not write extra records to the log. This value is the default.
YES
Writes the extra records to the log.
JCLJOBCK
Used to cause a check of the job name to be done when a job is submitted. If used, a job is
requeued with a JCLERR status if the job name in the JOB statement does not match the job name
in the queue.
NO
No check is made. This value is the default.
YES
Forces the check to be made.
JCLTAG
Specifies which identifier to insert into the JCL comment statement when the job is submitted to
the internal reader. Coding INSTANCE facilitates the identification of which CA Workload
Automation CA 7® Edition submitted the job when multiple copies of CA Workload Automation
CA 7® Edition are executing.
CA-7
Indicates to insert CA-7 into the JCL comment statement. This value is the default.
INSTANCE
Indicates to insert the CA 7 instance name, as coded on the SVCNO,CA7= parameter, into the
JCL comment statement as opposed to CA-7.
JFM
Controls the generation of monitoring data for Jobflow Monitor.
NO
Does not generate monitoring data for this CA 7 instance. Jobflow Monitor does not track the
workload activity for this instance. This value is the default.
YES
Generates monitoring data for this CA 7 instance. Jobflow Monitor tracks the workload
activity for this instance.
08-Feb-2018 528/722
JOBDEL
Allows the specification of how to interpret the DELETE function on the job definition panel. The
default is DELETE, which means it is interpreted as a normal delete. If this option is set to DD or
PURGE, when a user enters DELETE as a function on the job definition panel it is interpreted as if a
DD or PURGE had been entered.
JSOP
Specifies job submission options. Use a comma-delimited sublist when you must specify more
than one option. JSOP has no defaults.
1
This option ensures that a job is complete before another instance of the job can be moved to
the ready queue. If specified, CA Workload Automation CA 7® Edition does not move a job
from the request queue to the ready queue if another job with the same name is in the
request queue in restart status.
This value can be used to reduce unnecessary VRM resource conflicts.
For example, suppose JOBA is defined to use resource RSC1. Also assume that the RM.1
definition specifies TYPE=EXC and FREE=Y. If JOBA (job number x) abnormally terminates and
is waiting for restart in the request queue, another instance of JOBA (job number y) can be
moved to the ready queue once all its requirements have been satisfied. However, because
the first instance of JOBA (job number x) never relinquished exclusive control of the RSC1
resource, the second instance of JOBA (job number y) waits on the RSC1 resource in the ready
queue. In such a case, manual action (such as canceling or force completing JOBA job number
x) is required for JOBA (job number y) to run.
This situation can be avoided using JSOP=1. If JSOP=1 had been used in the previous example,
JOBA (job number y) would not move to the ready queue while JOBA (job number x) waited in
the request queue to be restarted.
2
The job submission process comprises two functions: 1) the "request queue scan" moves jobs
that are ready to submit from the request queue to the ready queue and 2) the "ready queue
scan" submits eligible jobs in the ready queue. If JSOP=2 is not specified, these functions
execute serially within a "submit cycle." The request queue scan runs first. When it is
complete, the ready queue scan runs. No jobs can move from the request queue to the ready
queue during a ready queue scan. No jobs can be submitted during a request queue scan.
If JSOP=2 is specified, these two functions execute concurrently. Jobs can move from the
request queue to the ready queue while jobs in the ready queue are submitted.
A SASSHR21 report does not show jobs that ran when JSOP=2 is in effect.
3
The date and time are recorded when a job is moved from the request queue to the ready
queue. This date and time are the ready queue entry date/time. If JSOP=3 is specified, this
date/time is included in the criteria used to select jobs for submission during a ready queue
scan (the "ready queue scan" is described in the preceding JSOP=2 description).
At the beginning of a ready queue scan, the ready queue contains all jobs that are considered
"ready" to submit. A ready queue scan selects jobs for submission either in priority order or in
physical order.
If the scan selects jobs in physical order, the ready queue is read sequentially. Each job is
submitted once it is fetched, provided there are no exceptions (such as VRM, ARF, or mutually
exclusive conditions). After the job is submitted, the ready queue scan selects the next job in
the ready queue. This process continues until the ready queue scan reaches the end of the
queue. In this mode, the ready queue is read in its entirety only once during a ready queue
scan.
08-Feb-2018 529/722
scan.
To select jobs in priority order, the ready queue must be read in its entirety to determine the
job with the "best" priority. In this mode, a ready queue scan consists of several "evaluation
cycles" where the ready queue is read from beginning to end. At the end of a ready queue
pass, a job can be selected and submitted, provided there are no exceptions (such as VRM,
ARF, or mutually exclusive conditions). After the job is submitted, the ready queue scan
continues by completing another ready queue pass, selecting the job with the "best" priority.
This process continues until the ready queue scan finds no more jobs to submit. In this mode,
the ready queue can be read in its entirety many times within a single ready queue scan.
By default, the ready queue scan selects jobs in physical order. However, if Workload
Balancing is used or if JSOP=3 is coded, the ready queue scan selects jobs in priority order.
When Workload Balancing is used without JSOP=3, the ready queue scan selects jobs for
submission in order by the priority that Workload Balancing assigns. When JSOP=3 is coded
without Workload Balancing, the submission priority is determined by the date/time the job
entered the ready queue. If both are used, jobs are submitted in the Workload Balancing
priority order. However, when Workload Balancing assigns the highest priority to multiple
jobs, JSOP=3 is used to "break the tie." The job that has the lowest ready queue entry date
/time is selected for submission out of the several jobs that have the highest Workload
Balancing priority.
JSOP=3 is implied when the enhanced submission selection (SUBSEL=ENH) is used.
LATEPROMPT
Specifies how to interpret the PROMPTS field on the job definition panel.
PROMPT
Indicates the traditional meaning for the field. PROMPT is the default.
LATE
Indicates that jobs that are defined with PROMPT=NO are never marked as LATE on an LQ or
LRLOG display regardless of how long they stay in the queues.
Jobs that are defined with PROMPT=YES are processed the same regardless of the setting for
LATEPROMPT.
LOADCLASS
Specifies the default Workload Balancing (WLB) class for jobs that are brought into the system by
the LOAD/H command. The value must be a single alphanumeric character. The default is 8.
LOGSUBJCL
Specifies whether to create type x'68'/subtype 4 records to the CA Workload Automation CA 7®
Edition log (refer to SASS7LOG on the CA Workload Automation CA 7® Edition MACLIB for a
record description). The valid values for this keyword are: YES, Y, NO or N. The default is
LOGSUBJCL=NO. If LOGSUBJCL=YES, CA Workload Automation CA 7® Edition creates one of these
type x'68'/subtype 4 log records for each:
Output JCL statement in the case of a CPU job.
Output XPJOB parameter statement that was retrieved from parmlib in the case of an XPJOB.
Output agent CLANG statement that was retrieved from the parmlib in the case of an agent
job.
08-Feb-2018 530/722
The output statement is logged after it has been modified for submission (using CA Driver or
Global Variables, user exits, and so on).
Note: This keyword is only applicable when the parallel submission processing is in effect
(the default). If PSP=NO, the value of LOGSUBJCL is ignored.
By default, the job submission process does not write output statements to the CA Workload
Automation CA 7® Edition log. Since such logging implies more overhead, it could possibly
degrade CA Workload Automation CA 7® Edition system performance. For that reason, we
recommend that you code LOGSUBJCL only when CA Support advises you to do so.
MAXRINGSZ
Specifies the number of top line commands to be saved in the command ring buffer for possible
retrieval by the /FETCH command. The value for MAXRINGSZ must be a numeric value from 1
through 10. The default is 5.
MAXSUBOUT
Specifies the number of output threads to dedicate to job submission. The default value is 5. If
you decide to code the keyword and override the default, you can specify as few as 1 and as
many as 15 output threads that job submission uses to process output.
This keyword is only applicable when the parallel submission processing is in effect (the default).
If PSP=NO, the value of MAXSUBOUT is ignored.
Each output thread requires a dedicated internal reader. CA Workload Automation CA 7® Edition
reduces the number of threads when enough internal readers cannot be allocated.
OVJCL
Specifies whether to delete the JCL members for jobs that are taken from the JCL override library
at the successful job completion. If used, the value must be one of the following choices:
SCRATCH
Indicates deleting the override JCL members on the successful job completion. SCRATCH is the
default.
NOSCRATCH
Indicates not deleting the override JCL members on the successful job completion.
PERMDSN
Specifies whether all data sets added to the CA Workload Automation CA 7® Edition database
default to permanent. The default is NO. If you specify PERMDSN=YES, all data sets added
through the LOAD processing and through the DB.6 panel default to PERM. The DB.3.1 panel
shows a PERM value of N. However, the job does not consider the data set as a requirement
because the DB.6 panel shows the PERM status.
PROPDSNU
Specifies whether to propagate the user field of JQREC (JQUSER) across data set triggers; that is,
to copy the JQUSER field of the job creating/updating a data set to jobs that are triggered by that
data set. The default is NO.
08-Feb-2018 531/722
PROPMAIN
Specifies whether a job mainid propagation occurs for triggered jobs. If you do not want the
mainid of a job propagated to any later triggered jobs specify NO. The default is YES.
PSP
Specifies whether Parallel Submission Processing (PSP) is active. If YES (the default), the number
of subtasks that are specified in MAXSUBOUT is attached to submit jobs for processing.
Note: If the user exit SASSXX02 is found and no SASSXX20 is found, no parallel submission
processing is permitted, and PSP=NO is set internally.
YES
Specifies parallel submission processing is active. YES is the default.
NO
Specifies parallel submission processing is not used. Jobs are submitted singularly for
processing.
RLOGCAN
Specifies the format of the LRLOG status field for the job cancel events.
STATUS
Displays the status of the job at the time the cancel occurred (JCLER, S806, and so on).
CANCL
Displays the literal 'CANCL' in the status field for the job cancel events
Any value other than STATUS or CANCL is ignored.
RQMT255
Specifies whether to look for jobs coming into the REQQ that have more than 255 requirements.
NO
Indicates that no checking is done. NO is the default.
YES
Checks for the jobs, issues a WTO, CA-7.SFER-08, and builds a special user requirement that
has to be manually posted.
RUNCLASS
Specifies the default Workload Balancing (WLB) class for jobs that the RUN/H command brought
into the system. The value must be a single alphanumeric character. The default is 9.
SHRCRQ
Indicates whether to propagate the VRM Corequisite commands PRSQA and PRSQD to other CA 7
instances.
08-Feb-2018 532/722
Note: The commands are propagated using the same user ID that issued them. Ensure
that the destination instances have that user ID defined.
NO
Propagates no commands. NO is the default.
YES
.Propagates the commands to a single instance. The name of the instance must be CA7 n
where n is a number from 1 through 8
(CAn,CA7n,...)
Propagates the commands to multiple instances. The names of the instances must be CA7 n
where n is the number from 1 through 8. You can specify up to seven instances.
SHRCRQPFX
If the VRM Corequisite propagation is in effect, this parameter controls the resource names to
propagate.
GLOBAL@
Propagates the commands when the resource has a GLOBAL@ prefix. GLOBAL@ is the
default.
*ALL*
Propagates all PRSQA and PRSQD commands
xxxxxxxx
Propagates the commands when the resource has this prefix. The length of the character
string must not exceed 8 bytes and must not include blanks, equal signs, or commas.
SHUTDOWN
Indicates the default CA Workload Automation CA 7® Edition shutdown type that is performed
when the /SHUTDOWN command is issued. The default shutdown type is only activated if the
/SHUTDOWN command is issued without parameters.
Zn
Specifies the method of shutdown as follows:
Z1
Specifies a "fast" shutdown of CA Workload Automation CA 7® Edition. Messages are not sent
to the individual terminals and CA Workload Automation CA 7® Edition does not wait for them
to log out, but waits for batch terminals to complete.
Z2
Specifies that shutdown is to occur even if batch terminals are active but the shutdown waits
for online terminals to log out.
Z3
08-Feb-2018 533/722
Specifies that shutdown occurs even if online terminals, batch terminals, or both are active.
SUBMSGLVL
Specifies the level of trace messages to issue during job submission output processing. The
keyword accepts a comma delimited sublist of numeric values. The keyword has no default.
The sublist can contain any or all of the following values: 1, 2 and 3.
Note: This keyword is only applicable when the parallel submission processing is in effect
(the default). If PSP=NO, then the value of SUBMSGLVL is ignored.
By default, the job submission process does not issue trace messages. Activating these trace
messages can result in a high volume of console output. For that reason, we recommend that you
code SUBMSGLVL only when CA Support advises you to do so.
SUBSEL
Specifies whether to use the enhanced submission selection. The enhanced submission selection
streamlines the process of determining which job in the ready queue to submit next. Using the
enhanced submission selection can improve the overall performance.
Important! The enhanced submission selection requires PSP=YES and VRMDD=NO or DEF.
If either option is set to another value, enhanced submission selection is turned off.
The enhanced submission selection acts as if JSOP=3 has been specified.

A job submission cycle consists of multiple phases (see also JSOP=2). The enhanced submission
selection is invoked during the “ready queue scan,” which determines the next job in the ready
queue to submit.
When workload balancing is not in use, jobs are considered in the order they arrived in the ready
queue.
When workload balancing is in use, jobs are considered by descending job priority, as defined on
the job definition (DB.1, DB.10, or DB.11) panels. The jobs are considered by ready queue entry
time within the job priority.
Note: Workload balancing does not change the job priority when using enhanced
submission selection.
Using the enhanced submission selection turns off other portions of workload balancing too. Only
class barriers, total initiator counts, and TAPE1/2 numbers are honored.
The order that jobs are considered is not necessarily the order that jobs are submitted. Consider
the case where jobs X and Y are in the ready queue waiting for a virtual resource. Job X arrived in
the ready queue before Y. A ready queue scan begins and job X is considered. Job X cannot be
submitted because the virtual resource is not available. After X has been considered but before Y
is considered, the job that owns the virtual resource completes successfully. When the ready
queue scan continues and considers job Y, it discovers that Y can be submitted, resulting in Y
running before X even though X arrived in the ready queue first.
When multiple jobs are eligible for submission simultaneously, they can be selected in different
orders by SUBSEL=NORM and SUBSEL=ENH. Both sequences are “correct” in that the jobs being
selected are eligible for submission.
08-Feb-2018 534/722
selected are eligible for submission.

When an ASX (address space) virtual resources is not available, the enhanced submission
selection rechecks for availability at most once a minute.
NORM
Specifies that the enhanced submission selection is not used. NORM is the default.
ENH
Specifies that enhanced submission selection is used.
VRMDD
Specifies whether to activate the VRM device definition.
Note: For more information about the VRM device facility, see VRM Device Control.
NO
Indicates that the VRM device definition is not activated. No VRM device definitions are built.
Any definitions that are detected on the database are ignored when jobs are submitted. This
DEF
Indicates that VRM device definitions are built when jobs are loaded. However, any definitions
are ignored at submission time. This option can prove useful while testing so that device
definitions can be examined before being used in a production environment.
This option also requires that a SASSDTAB table is in a load library that CA Workload
Automation CA 7® Edition can access.
SUB
Indicates to use VRM Device Definitions at the job submission, however no definitions are
dynamically built when jobs are loaded.
This option requires that RSRC=YES is coded on the DBASE statement. This option also
requires that a SASSDTAB table is in a load library CA Workload Automation CA 7® Edition can
access.
YES
Combines the DEF and SUB options. If VRMDD=YES is coded, VRM Device Definitions are built
dynamically when a job is loaded, and those definitions are honored when jobs are submitted.
This option requires that you code RSRC=YES on the DBASE statement. This option also
requires that you have a SASSDTAB table in a load library that CA Workload Automation CA 7®
Edition can access.
WLBOPT
Lets you specify various WLB options.
1
Do not use WLB to calculate a priority. Use the priority that is defined on the DB.1 (JOB)
screen. This option can lower the actual CPU usage by CA Workload Automation CA 7® Edition
during times when several hundred jobs are in the ready queue.
08-Feb-2018 535/722
WLMCA7
Can specify a predefined IBM WLM resource name to be associated with this copy of CA
Workload Automation CA 7® Edition. During startup, CA Workload Automation CA 7® Edition
attempts to set the state for this resource to ON. During the shutdown, CA Workload Automation
CA 7® Edition attempts to set the state for this resource to OFF.
IBM WLM resource names are 1 through 16 characters. The resource must be defined in the
current IBM WLM policy for CA Workload Automation CA 7® Edition to manipulate its state.
Note: If you specify a resource name for CA Workload Automation CA 7® Edition, specify
the same resource name on the WLMCA7= keyword of the execution parameter, PARM=,
on the SASSICLR cleanup step in the CA Workload Automation CA 7® Edition Online JCL
Procedure. The default procedure name is CA7ONL. The default step name is FREE. This
specification ensures that the resource state is set to OFF when CA Workload Automation
CA 7® Edition is inactive even when CA Workload Automation CA 7® Edition terminated
abnormally. For example:
//FREE EXEC PGM=SASSICLR,PARM='WLMCA7=...resource-name...'
WLMSE
Specifies whether CA Workload Automation CA 7® Edition supports the insertion of IBM WLM
scheduling environment keywords on JOB statements for jobs that CA Workload Automation CA
7® Edition submits (SCHENV= keyword). IBM WLM scheduling environments can be associated
with CA Workload Automation CA 7® Edition jobs by special VRM resource connections. Possible
values for this keyword are:
NO
Do not insert SCHENV= keywords on the JOB statements even when scheduling environment
VRM resource connections are defined. This value is the default.
YES
Insert SCHENV= keywords on the JOB statements when matching scheduling environment
VRM resource connections are defined and attached to a job.
global-default
Same as YES, except that it specifies a 1- to 16-character, IBM WLM scheduling environment
name to use as a default for jobs that do not have a matching scheduling environment VRM
resource connection attached.
Note: All scheduling environments must be defined to the IBM Workload Management
system (WLM).
If the JCL for a job already has a SCHENV= keyword on the JOB statement, CA Workload
Automation CA 7® Edition does not override it.
WLMSEVAL
Specifies whether CA Workload Automation CA 7® Edition validates that a scheduling
environment is defined in the current IBM WLM policy before inserting the SCHENV= keyword on
the JOB statement before submission.
08-Feb-2018 536/722
NO
Indicates that CA Workload Automation CA 7® Edition does not validate before inserting a
SCHENV= keyword. This value is the default.
YES
Indicates that CA Workload Automation CA 7® Edition verifies that the scheduling
environment is defined in the current IBM WLM policy before submitting a job with a
SCHENV= keyword that CA Workload Automation CA 7® Edition inserts. If the scheduling
environment is not defined in the current policy, the job is requeued to the request queue.
(This check is only performed on the system where CA Workload Automation CA 7® Edition is
running, which could be different from where the job is running.)
Note: If a job is submitted with a SCHENV= keyword that specifies a scheduling

environment that is not part of the current policy, the job terminates with a pre-execution
JCL error.
If the JCL for a job already has a SCHENV= keyword on the JOB statement, CA Workload
Automation CA 7® Edition does not attempt to validate it before submission.
Validation confirms the definition of a scheduling environment in the current IBM WLM policy. It
does not check the availability of the scheduling environment in the SYSPLEX.
XQOFF
Specifies line function characters to disable on the QM.1-X and QM.1-M panels (XQ and XQM).
The characters that can be specified in the XQOFF list must correspond to valid XQ line functions.
Valid line functions are: C, F, H, J, P, Q, R, S, U, V, X, and E.
If more than one function character is specified, the list must be enclosed in parentheses with
each character separated by commas. For example:
XQOFF=C Disables the Cancel command on the XQ and XQM panels
XQOFF=(C,H) Disables the Cancel and Hold commands on XQ and XQM
Note: The line functions that the XQOFF parameter disables are not available to any CA
Workload Automation CA 7® Edition user regardless of security definitions. If the users
attempt to use one of these commands, they receive a message indicating that a site
option disabled the command. The XQOFF option does not affect any equivalent top line
commands.
PFnn and PAnn Statements

The PFnn statements define the program function (PF) key assignments for the terminals. The PA nn
statements define the program access (PA) key assignments. One statement is required for each key
that you assign. These statements must immediately follow the PFTERM statement that defines the
terminals to which these assignments apply.

PFnn,x...xPAnn,x...x
08-Feb-2018 537/722
nn
Specifies the key number in two digits 01 through 24 for PFnn; 01 through 03 for PAnn.
x...x
Represents a character string that is assigned to the key. This character string can be any
commonly used top line command including the /ECHO command.
Examples
PF07,LQ
PF08,LPRE
PF09,/ECHO,M=(LQ,JOB=#)
.
.
.
PA01,GRAPHJ,ID=0370
.
.
.
If a key is defined with the /ECHO command, the command is displayed back to the terminal and the
cursor is positioned at the # when the key is pressed.
Note: The # must be the last character of the command for the cursor to position itself
there.
The /PA and /PF commands can be entered at a terminal to override any values assigned here. Online
menus and their related formatted and display panels temporarily use PF3, PF7, and PF8 for specific
purposes no matter what values are assigned here. Enter a /DISPLAY,ST=KEY command to view
assigned values.
PFTERM Statement
The PFTERM statements identify terminals for assigning PF/PA key assignments with PF nn and PAnn
statements. These statements allow assignment by individual terminals at initialization. A PFTERM
statement for a specific terminal must immediately precede the PF/PA statements for that terminal

PFTERM[,{T|TERM}={ALL|xxxxxxx}]
TERM|T
(Optional) Specifies the name of a terminal for which PF/PA key assignments are to apply. Value
must be a one- to seven-character terminal name as defined by NAME on the TERM statement. T
can be used instead of TERM. The ALL option causes the PF/PA assignments that follow this
statement to apply to all terminals not otherwise defined by a PFTERM statement.
Default: ALL
Individual terminal assignments using the combination of PFTERM, PFnn, and PAnn statements must
precede the PFTERM for T=ALL.
08-Feb-2018 538/722
Examples
PFTERM,T=term1
PFnn statements for terminal 1
PAnn statements for terminal 1
PFTERM,T=term2
PFnn statements for terminal 2
PAnn statements for terminal 2
.
.
.
PFTERM,T=ALL
PFnn statements for all other terminals
PAnn statements for all other terminals
Note: For more information about saving PA/PF key definitions for individual user IDs, see
the /PROF command.
RESIDENT Statement
The RESIDENT statement defines the type and quantity of certain resources used while CA Workload
Automation CA 7® Edition is active as follows:
The types of terminals.
The size of the CA Workload Automation CA 7® Edition application pool and buffer pools.
The source of the CA Workload Automation CA 7® Edition JCL statements.
The RESIDENT statement also provides an option to override the COLD-type start WTOR warning so
that the WTOR is not issued.
The RESIDENT statement is required. You can specify it only once, but you can continue it. All
keywords are nonpositional and can appear in any order.

RESIDENT,APGPL=nnnnnn,NETWORK={REAL|BAT|ALL}
[,COLDWTOR={YES|NO}]
[,G64PL={15360|nnnnnn}]
[,JCLDEFS={INITFILE|DATABASE|VSAM}]
APGPL
Specifies the memory size of the CA Workload Automation CA 7® Edition application pool that is
used for application programs that are not designated as resident. Value must be given as a
number of bytes (left-justified). APGPL is required and has no default. The size of the application
buffer pool can affect CA Workload Automation CA 7® Edition system performance. The minimum
value is at least 120000. Any amount over 240000 is probably wasted space.
Note: For more information about monitoring pool sizes through the /DISPLAY,POOLS=ALL
command, see the /DISPLAY command.
08-Feb-2018 539/722
NETWORK
Defines the type of terminals that are included in the CA Workload Automation CA 7® Edition
terminal network. NETWORK is required and has no defaults. For CA 7 Online execution, specify
NETWORK=ALL. Value must be one of the following:
REAL
Only real terminals (3270s and associated printers) and the OS system console (optional) are
defined. The batch terminal interface facility cannot be used.
BAT
Only batch terminals are defined.
ALL
Real terminals, batch terminals, and the OS system console (optional) are all defined.
COLDWTOR
Specifies whether to issue a WTOR when a cold type of CA Workload Automation CA 7® Edition
start is attempted.
YES
Performs a WTOR verification of a cold type of start. This type includes COLD, FORM, and
CKPT.
A reply of OK indicates to continue with the cold type of start.
A reply of WARM or ERST causes CA Workload Automation CA 7 Edition to initialize with that
type of start.
YES is the default.
NO
Performs no WTOR verification when a cold type of start is attempted..
G64PL
Specifies the memory size of the CA Workload Automation CA 7 Edition 64 bit above-the-bar
general pool that is used for scratch work files. Supply the value as the number of 1-MB
segments. If the keyword is not specified, the default is 15360. The default equates to 15GBs of
storage. This default storage value is enough to support 200+ users using 8 scratch work files
each. To obtain a good starting value, multiply your average number of users times 72. For
example, 100 users, code G64PL=7200. This pool expands when needed. To display the pool
allocation and usage data, use the /DISPLAY,PL=ALL command. If G64PL=0 is specified, it is
automatically updated to be the default value instead.
JCLDEFS
Specifies the source of the CA Workload Automation CA 7® Edition JCL library definitions that use
symbolic indexes. Any changes to JCL library definitions made with the /JCL command are stored
on the CA Workload Automation CA 7® Edition database. The JCLDEFS option determines how
these stored definitions are used when CA Workload Automation CA 7® Edition is initialized.
INITFILE
Erases any JCL library definitions that are found on the database. Next, reads the JCL library
definitions in the CA Workload Automation CA 7® Edition initialization file. Stores all the
definitions using symbolic indexes in the database. INITFILE is the default.
08-Feb-2018 540/722
DATABASE or VSAM
When CA Workload Automation CA 7® Edition is initialized, all JCL library definitions that use
symbolic indexes are read from the database. Any definitions using symbolic indexes that are
found in the initialization file are ignored.
Note: This option does not affect JCL library definitions that use a numeric index (such
as INDEX=10). To recognize these definitions, they must reside in the initialization file.
RESTART Statement
The optional RESTART statement identifies the available option for job restart processing.
If you want the CA Workload Automation Restart Option for z/OS Schedulers interface, include the
RESTART statement in the initialization file.

RESTART[,ARF={NO|YES|MAINT}]
[,CONDCHK={NO|YES}]
[,LRTCDREQ={NO|YES}]
[,PARMRMS={F|PSEUDO}]
[,PROCRMS=procname]
[,REASON={NO|YES}]
[,RMS={YES|NO}]
[,ROUTCDE={1|nn}]
[,STEPRMS={CA07RMS|stepname}]
[,WTO={NO|YES|HI}]
[,WTOSTEP={NO|YES|HI|ALL|ALLHI}]
ARF
Specifies whether the Automated Recovery Facility is available.
NO
Indicates that ARF is not available. NO is the default.
YES
Indicates that ARF is available. If this value is specified, ARF monitors and responds to job
events.
MAINT
Indicates that ARF is available for database maintenance only. If this option is specified, you
can access ARF database definitions. ARF does not monitor or respond to job events.
CONDCHK
Specifies whether to synchronize CA Workload Automation CA 7® Edition and CA Workload
Automation Restart Option for z/OS Schedulers condition code checking.
Note: For more information about this feature, see the CA Workload Automation Restart
Option for z/OS Schedulers installation documentation.
08-Feb-2018 541/722
NO
Indicates not to synchronize CA Workload Automation CA 7® Edition and CA Workload
Automation Restart Option for z/OS Schedulers condition code checking. NO means that CA
Workload Automation CA 7® Edition and CA Workload Automation Restart Option for z/OS
Schedulers do not determine job failures using the same criteria. CA Workload Automation CA
7® Edition uses the setting in the job definition panel for COND-CODE and RO (or #SCC
statements). CA Workload Automation Restart Option for z/OS Schedulers uses the
information that the operating system provides and the information that is defined in its own
database. NO is the default.
YES
Indicates that CA Workload Automation CA 7® Edition and CA Workload Automation Restart
Option for z/OS Schedulers condition code checking is synchronized. CA Workload
Automation Restart Option for z/OS Schedulers uses information CA Workload Automation CA
7® Edition provides to determine job failures. To use this feature fully, have the CA
Generalized Transaction Server (CA GTS) feature installed and active on each image running
CA Workload Automation Restart Option for z/OS Schedulers.
Note: CA Workload Automation CA 7® Edition now captures the JES node where a job
executes and the CA Workload Automation Restart Option for z/OS Schedulers subsystem
that tracks the job. This information is passed back to CA Workload Automation Restart
Option for z/OS Schedulers when a job is restarted, force completed, or canceled. The
information is also passed when CONDCHK is set to YES. CA Workload Automation Restart
Option for z/OS Schedulers can use this information to determine what CMT to update
and where it is located. If this type of processing is desired, configure CA Workload
Automation Restart Option for z/OS Schedulers to support NJE requests for job restarts
across remote JES nodes. This configuration can require implementing CA GTS and
including the GTS load library in the CA 7 STEPLIB concatenation.
LRTCDREQ
Specifies whether the LRTCD field on the XRST panel is required.
NO
Specifies the LRTCD field is not required. NO is the default.
YES
Specifies the LRTCD field is required. You can specify a value of one for the step name, and
this value causes the LRTCD field to be ignored. This would be necessary if restarting in the
first step of the job.
PARMRMS
Specifies the PARM information to pass to the RMS step at job submission. Using 'F' passes a
PARM='F' to the RMS step.
Using 'PSEUDO' passes a PARM='P,PSEUDO=YES' to the RMS step, unless restart (for example,
XRST) overrides this by specifying an F in the SET PARM field.
PARMRMS has no default. If it is not specified, the PARM is set to a 'P' for initial runs. For restarts,
the PARM is set according to the XRST and CA Workload Automation Restart Option for z/OS
Schedulers options.
08-Feb-2018 542/722
PROCRMS
Specifies the one- to eight-character procedure name to insert for jobs that are flagged for
INSERT-RMS on the DB.1 panel. If CA Workload Automation Restart Option for z/OS Schedulers is
not installed, insertion of the RMS step does not occur even though the DB.1 panel field requests
it. The default procedure name is taken from the CA Workload Automation Restart Option for z
/OS Schedulers Options Table, which is typically created during CA Workload Automation Restart
Option for z/OS Schedulers installation. Regardless of the name that is used, the symbolic
parameter &TYPRUN must exist in the procedure that PROCRMS references.
REASON
Specifies whether a reason code must be input when doing a job restart. The reason code that is
entered, up to 40 characters, is written to the CA Workload Automation CA 7® Edition run log. If
CA Workload Automation Restart Option for z/OS Schedulers is available, the code is passed on to
the CMT. The value must be YES or NO. The default is NO.
RMS
Specifies whether to use CA Workload Automation Restart Option for z/OS Schedulers for restarts
when CA Workload Automation Restart Option for z/OS Schedulers is available. If RMS=NO is
specified, the RMS step is not inserted and restart commands/panel do not display or post CA
Workload Automation Restart Option for z/OS Schedulers data. However, the ARTS command can
be used. Value must be YES or NO. The default is YES, which causes the use of CA Workload
Automation Restart Option for z/OS Schedulers when it is present.
ROUTCDE
Specifies route code for the job and step termination WTOs when the WTO=, WTOSTEP=, or both,
keywords are specified (WTOs CA-7.SMF3 and CA-7.SMF4). The value must be a number from 1 to
16. The default is ROUTCDE=1 that sends the WTOs to the master console.
STEPRMS
Specifies a one-to eight-character step name for the CA Workload Automation Restart Option for z
/OS Schedulers RMS step. If a step name is not specified, the default step name is CA07RMS.
WTO
Specifies whether to issue a WTO when a CA Workload Automation CA 7® Edition submitted job
terminates unsuccessfully. See the CA-7.SMF3 message.
NO
Indicates that CA Workload Automation CA 7® Edition does not issue a WTO at unsuccessful
job completions. This value is the default.
YES
Indicates that CA Workload Automation CA 7® Edition issues a WTO.
HI
Indicates that CA Workload Automation CA 7® Edition issues a highlighted and nonscrollable
WTO.
WTOSTEP
Specifies whether to issue a WTO for job steps that CA Workload Automation CA 7® Edition tracks
(see the CA-7.SMF4 message). The unsuccessful steps are those steps that terminate with an
abend, JCL error, or condition code that fails the job=level code from the job definition panel.
08-Feb-2018 543/722
abend, JCL error, or condition code that fails the job=level code from the job definition panel.
Steps that fail the #SCC tests are not marked as unsuccessful (though they cause the issuing of a
job WTO when that option is specified). LOAD only jobs produce a WTO only if the LOAD step fails
with something other than its usual JCLERR.
NO
Indicates that a step fail WTO is not issued. This value is the default.
YES
Indicates issue a WTO for bad step terminations.
HI
Indicates issue a highlighted and nonscrollable WTO for bad step terminations.
ALL
Indicates issue a WTO for every step completion for every CA Workload Automation CA 7®
Edition tracked job regardless of the termination condition except for LOAD only jobs.
ALLHI
Indicates issue a WTO for every step completion for every CA Workload Automation CA 7®
Edition tracked job regardless of the termination condition except for LOAD only jobs. Also,
WTOs are highlighted and nonscrollable.
Note: If ALL or ALLHI is used, many WTOs are issued depending on the number of jobs
that CA Workload Automation CA 7® Edition tracks and the number of steps in each
job.
SCHEDULE Statement
The SCHEDULE statement establishes values for the parameters that govern the automatic scheduling
and submission control functions of CA Workload Automation CA 7® Edition. This feature is known as
schedule scan. The initial values define:
The maximum job number to be assigned to a CA Workload Automation CA 7® Edition submitted

job.
The schedule scan wake-up interval and time span to be searched for work to schedule.
The time interval to elapse between reprompts.
The SCHEDULE statement is supplied with the skeleton initialization file. Users can change the
specified values at their discretion. The SCHEDULE statement is required. The SCHEDULE statement
can be continued.
All keywords are nonpositional and can appear in any order following SCHEDULE. This statement has
the following format:
SCHEDULE,HIJBNUM=nnnn,QDWELL=mm,REPROMPT=mm,SCNINCR=hh,SCNSPAN=hh [,ABR={NO|YE
S}]
[,ENDDAY={2400|hhmm}]
[,PSFORCE={NO|YES}]
[,QPRG={YES|NO}]
08-Feb-2018 544/722
[,QPRG={YES|NO}]
[,REQUE={NO|YES}]
[,RETRY={0|mm}]
[,SCHID={NO|YES}]
[,STOPQ={NO|YES}]
[,XPRETRY={0|mm}]
HIJBNUM
CA Workload Automation CA 7® Edition assigns its own job numbers to jobs in a manner similar to
the way JES assigns job numbers. This parameter specifies the highest allowable CA Workload
Automation CA 7® Edition assigned job number. HIJBNUM is required and has no default. The
maximum value is 9999. You can change this value on any valid start type (WARM, ERST, COLD, or
FORM).
Note: Before you decrease the HIJBNUM value on a WARM or ERST type start, consider
the following items:
Some jobs in the status queues can already have job numbers greater than the new HIJBNUM
value.
The size of some in-memory queue tables is typically based on the HIJBNUM value. For this
execution of CA WA CA 7 Edition, the size is based on the greater of HIJBNUM and the highest
job number present in the queues at startup time.
These jobs process normally through the queues, but no jobs entering the queues after
startup are assigned job numbers greater than HIJBNUM.
At startup, if the next job number to assign is greater than HIJBNUM, it is reset to the lowest
available job number
QDWELL
Specifies a safety factor for job scheduling that ensures that a job is not in a late status when it
initially enters the queue. Value must be given in minutes (0 through 60). The recommended
value is 30 minutes. QDWELL is required and has no default.
QDWELL becomes important when SCNSPAN and SCNINCR specify the same interval. For
example, if both were specified as two hours but QDWELL was not specified and CA Workload
Automation CA 7® Edition was initialized at 0800, schedule scan would wake up at 08:00, 10:00,
12:00 and so forth. Work scheduled for processing within the next two hours would be loaded
into the queues each time. Work scheduled to start at 10:01, 12:01, or 14:01 would not be loaded
until 10:00, 12:00 and 14:00 respectively. This could cause work to be flagged as late because of
the small amount of time between arrival in the queue and when the work is scheduled to start
(only one minute in the preceding example).
REPROMPT
Specifies the time interval between wake-ups for reprompting for late work. Value must be given
in minutes (0 through 60). The recommended value is between 15 to 30 minutes, depending on
the installation's needs. A value of 0 turns off reprompting. REPROMPT is required and has no
default.
SCNINCR
Specifies the time interval for the schedule scan wake-up. Value must be given in hours (1
through 24), and must be less than or equal to the SCNSPAN value. SCNINCR is required and has
no default.
08-Feb-2018 545/722
no default.
Note: See the note under SCNSPAN that follows.
SCNSPAN
Specifies the span of time beyond the time-of-day of each schedule scan wake-up to search for
jobs to schedule. Any job with a deadline start time that occurs within that span is scheduled into
the queues. Value must be given in hours (1 through 24), and must be equal to or greater than
the SCNINCR value. SCNSPAN is required and has no default.
Note: The schedule scan example in the following topic shows schedule scan becoming
active every two hours. When the schedule scan becomes active, all work scheduled to
start within the next four and one-half hours (SCNSPAN plus QDWELL) is loaded into the
queues. The extra half-hour scheduling is caused by the QDWELL keyword specifying an
overlap of 30 minutes.
ABR
If YES is coded, the format of initial requirements scan output and prompt messages is
abbreviated. The default is NO.
ENDDAY
Specifies the end of a processing day (for use in automated performance analysis statistical
reporting). Value must be given as hours and minutes (hhmm) with 2400 as maximum. ENDDAY is
optional and defaults to 2400.
PSFORCE
Indicates CA Workload Automation CA 7® Edition/Personal Scheduling job completion status.
NO
Indicates that CA Workload Automation CA 7® Edition/Personal Scheduling submitted jobs are
not forced complete automatically. This value is the default.
YES
Indicates any jobs submitted using the CA Workload Automation CA 7® Edition/Personal
Scheduling SUBMIT function are always considered successfully completed, regardless of
actual completion of the job on the CPU.
QPRG
Specifies whether a job in the ready queue is automatically requeued to the request queue if an
SMF type-26 (Job Purge) record is received for that job. When YES is specified or defaulted, the
job is requeued and shows a status of R-JCLERR.
Note: While most JCLERR conditions can be automatically requeued by using QPRG=YES,
some cannot be requeued and require a manual requeue. This is because of the lack of
information in the IBM SMF purge record. For example, DSIP=SHR can be caught, but
DISP=SRH cannot. Another situation that can leave a job in the ready queue with an R-
JCLERR status is the use of the $RXEQ JES command.
08-Feb-2018 546/722
A reload of the JES spool can cause a purge record to be produced for the jobs reloaded and for
jobs in the CA Workload Automation CA 7® Edition ready queue. A JCLERR indication will be
noticed, and if using QPRG=YES, the job will be requeued back to the request queue with JCLERR
status.
REQUE
Specifies whether a job that is abended with a S222 and has a zero CPU time is left in the ready
queue. If a requeuing package performs an operator requeue in JES, specifying YES causes CA
Workload Automation CA 7® Edition to leave the job in the ready queue awaiting the job start
record. The default is NO.
RETRY
Specifies the time interval between wake-ups for reattempting to attach JCL and requirements for
jobs in RETRY status. Jobs can be left in RETRY status if a dynamic allocation (SVC 99) failure
occurred trying to access the JCL library when attempting to attach the JCL for the job. A value of
zero turns off the RETRY cycle. The RETRY parameter is optional and defaults to zero. Value must
be given in minutes (0 through 60).
SCHID
Specifies whether an SCHID= parameter is required for DEMAND(H), RUN(H), and LOAD(H)
commands. The default is NO.
STOPQ
If YES is coded, normal job movement in the request and ready queues is suspended. This entry
has the same effect as the top line command STOP,Q=ALL. To resume normal job flow, use the
START,Q=ALL command.
XPRETRY
Specifies a number of minutes between attempts to send data to the targeted node or its
alternates for XPJOBs waiting in the request queue in some type of node status. The default, 0,
means that no retry is attempted. Even if a non-zero XPRETRY value is coded, attempts to resend
data are determined on a job-by-job basis based on node states. An attempt to resend data is not
made when there is no chance for success. An attempt to resend data is made for the following
node state values:
The primary node is in state ONLINE or FAIL.
The primary node is in state OFFLINE. Alternate node1 is defined and in state ONLINE or FAIL.
The primary node is in state OFFLINE. Alternate node 1 is defined and in state OFFLINE.
Alternate node 2 is defined and in state ONLINE or FAIL.
Schedule Scan Example

SCHEDULE Statement
Keywords:
SCNINCR=2 (scan increment)
SCNSPAN=4 (scan span)
QDWELL=30 (queue dwell)

SCNSPAN QDWELL QDWELL
______________________|__________________________|____ ___|___
| | | | |
| | | | |
0800 1000 1200 1230 1400 1430
|_____________________|______________________|_______|__________|______|
| | | | | |
|_____________________|
08-Feb-2018 547/722
|_____________________|
|
SCNINCR

CURRENT SCHEDULE NEXT SCHEDULE
SCAN WAKE UP SCAN WAKE UP
|____________________________________________________|_________________|
| |
WORK ADDED TO WORK ADDED TO
QUEUES AT 0800 QUEUES AT 1000
SECURITY Statement
The SECURITY control statement determines the security environment for CA Workload Automation
CA 7 Edition based on user-selected keywords. The initialization file contains control statements that
define the processing configuration of CA Workload Automation CA 7® Edition during startup.

SECURITY,NAME={SASSSECI|xxxxxxxx}
[,ACF2CARD={JOBFROM|LOGONID}]
[,AGCLASS={FACILITY|xxxxxxxx}]
[,AGUSER=(OWNER,REQ,QJCL,CA7)]
[,APPL=CA7]
[,BYPSEC=(1,2,3)]
[,CCLASS={CALENDAR1|xxxxxxxx}]
[,DFLTUSER=xxxxxxxx]
[,DISPLAY={YES|NO}]
[,EXTERNAL=(AGENT,CALENDAR,COMMAND,DATASET,LOGON,LONGPASS,SUBCHECK,SUBOWNER,
XSUBCHECK)]
[,HIDEGRP={NO|YES}]
[,HIDEPW={NO|YES}]
[,HIDEUPD={NO|YES}]
[,HIDEUSER={NO|YES}]
[,JCLUID={YES|NO}]
[,LOADSUBC={YES|NO}]
[,LOGOPID={YES|NO|ALL}]
[,MIXPW={NO|YES}]
[,MULTIJOB={IGNORE|FLUSH|REQUEUE}]
[,PCLASS=xxxxxxxx]
[,PROPAGATE={NO|YES}]
[,PSOWNER={YES|NO}]
[,RCLASS=xxxxxxxx]
[,RESLOGON={YES|NO}]
[,RLOGUID={YES|NO}]
[,SCLASS={SUBMIT|xxxxxxxx}]
[,STATSID={YES|NO}]
[,SUBNOID={NO|YES}]
[,SUBUID=(OWNER,REQ,QJCL,DEFAULT,CA7)]
[,UID=xxxxxxxx]
[,USER=xxxxxxxx]
[,XBSCLASS={YES|NO}]
[,XBSUBCHK={YES|NO}]
[,XPSSID={**NONE**|xxxxxxxx}]
1 For CA Top Secret®, the CCLASS default is $CALNDR because CALENDAR is a reserved word in CA
Top Secret.
SECURITY
Identifies the SECURITY statement that describes the CA Workload Automation CA 7 Edition
security environment.
08-Feb-2018 548/722
NAME
Identifies the load module that contains the security definitions built using the SECURITY macro.
This parameter is required for both internal and external security. If you are implementing full
external security control for CA Workload Automation CA 7 Edition, the default security module
SASSSECI can be used. This module is supplied in the CA Workload Automation CA 7 Edition load
library. If you are using CA Workload Automation CA 7 Edition internal security, see Internal
Security (https://docops.ca.com/display/CA712/Internal+Security) for more information about building
and modifying the CA Workload Automation CA 7 Edition security module to meet your
installation's security requirements.
ACF2CARD
(Optional) For USERID insertion at CA ACF2™ sites, CA Workload Automation CA 7 Edition adds a
control statement to the JCL immediately following the JOB statement. This option controls what
type of CA ACF2 control statement is used. JOBFROM is the default. The only other valid value is
LOGONID. For more information, see the JCL USERID Format topic.
AGCLASS
(Optional) Specifies the resource class used for security calls that are made from CA Workload
Automation CA 7 Edition to validate a user's authority to submit agent jobs or execute agent
commands. The default resource class is FACILITY. This field can be up to eight characters.
AGUSER
(Optional) Specifies a hierarchy of candidate user ID sources to determine the mainframe user
(MFUser) to use for authorizing job submission for agent jobs. This list prioritizes the potential
sources for user IDs. The order of specification in the list determines the priority of the user ID to
select. If you are validating agent job submissions, authorizations are performed to verify that
MFUser is authorized to submit agent jobs to the specific agent name using the agent user ID. The
AGCLASS keyword determines the resource class used for the authorization.
If more than one of these subparameters is used, enclose in parentheses and separate them with
commas.
OWNER
Indicates to select the job OWNER ID as the MFUser field.
REQ
Indicates the requester ID is a candidate for the MFUser field. The requester ID can be the
user ID of a user issuing a DEMAND command to request a job. The requester ID can also be
the user ID selected for a job (requester) that then triggers additional jobs. The triggered jobs
inherit the user ID. For data set triggers, jobs that create or "post" a data set to CA Workload
Automation CA 7 Edition have their associated user ID propagated to any later triggered jobs.
For the U7SVC and CA Workload Automation CA 7 Edition SASSBCLP facilities, the user ID is
extracted from the current environment from which the user issues the data set creation or
post request.
QJCL
Indicates that the user ID of any user editing queue PARMLIB data for a job is a candidate for
the MFUser field. This value would be the user ID of the last person to edit queue PARMLIB
data for a job.
CA7
Indicates to select the user ID assigned to CA Workload Automation CA 7 Edition for the
MFUser field.
08-Feb-2018 549/722
APPL
(Optional) Identifies the CA Workload Automation CA 7 Edition Security Application ID. The
application ID, if specified, is used as an additional check during logons. A resource check is
performed, using the Security Application ID as the resource name, to validate the authority of
the user to access CA Workload Automation CA 7 Edition.
BYPSEC
(Optional) Specifies functions for which to bypass UID security when accessing jobs in the
database or queues.
Important! We do not recommend the use of these options. If selected, serious security
exposures sometimes result. Decide to use these options only after careful consideration
of the possible consequences of bypassing the CA Workload Automation CA 7 Edition
security interface.
If using more than one of these subparameters, enclose in parentheses and separate them with
commas.
1
Indicates that security access to predecessor jobs is not validated during job predecessor
definition (DB.3.2). Access to the job for which predecessors are defined is still validated.
2
Indicates that security access to jobs is not validated during forecast processing.
3
Indicates that security access to requirement successor jobs is not validated during job 'purge'
delete processing (job definition panel). That is, assume that a user is deleting job A with the
PURGE function and job B has job A listed as a predecessor. Job B is updated to remove the
predecessor entry for job A without a security check to determine whether the current user
has update access to job B.
CCLASS
(Optional) Specifies the resource class being used for security calls that are made from CA
Workload Automation CA 7 Edition to validate a user's authority to access its calendars. The
default resource class is CALENDAR for CA ACF2 and RACF users and $CALNDR for CA Top Secret
users. This field can be up to eight characters.
DFLTUSER
(Optional) Specifies the default USERID. This USERID is used when it is requested in the SUBUID
hierarchy. This field can be up to eight characters.
DISPLAY
(Optional) Determines whether the USERID is displayed when it is entered on the Logon panel.
YES
Indicates that the USERID is displayed. This value is the default.
NO
Indicates that the USERID is not displayed.
EXTERNAL
08-Feb-2018 550/722
EXTERNAL
(Optional) Identifies the security functions (calls) that external security is to control. Required for
external security. CA Workload Automation CA 7 Edition internal security controls any security
functions that are not specified on the external keyword. This control requires the presence of a
CA Workload Automation CA 7 Edition security module built using the CA Workload Automation
CA 7 Edition SECURITY macro. For more information, see the SECURITY macro.
commas.
AGENT
Indicates that any attempt to submit an agent job or execute an agent command is validated
through external security.
CALENDAR
Indicates that any attempt to access a CA Workload Automation CA 7 Edition base calendar is
validated through external security. The security resource class that is used for such validation
is CALENDAR.
COMMAND
Indicates that all command functions are validated through external security. This value
includes panel access throughout CA Workload Automation CA 7 Edition.
DATASET
Indicates that any attempt to access a data set while signed on to CA Workload Automation
CA 7 Edition is validated through external security.
LOGON
Indicates that logons to CA Workload Automation CA 7 Edition are validated through external
security. This parameter is the minimum requirement for the EXTERNAL keyword when
implementing external security. The security calls to external security during CA Workload
Automation CA 7 Edition LOGONs establishes the security environment for each CA Workload
Automation CA 7 Edition user.
LONGPASS
Enables the 3270 login screen to accept passwords longer than eight characters. A password
greater than eight characters is commonly known as a passphrase.
Limits: When specifying a NEW PASSWORD, the NEW PASSWORD must be entered into the
CONFIRM NEW PASSWORD field. The type of the NEW PASSWORD must conform to the type
of the original password.
If you want to change the type of your password, see the security administrator at your site.
CA 7 does not determine your password protocols. That is, you cannot change a password to a
passphrase or a passphrase to a password.
Leading blanks are not supported, and trailing blanks are removed.
SUBCHECK
Validates the usage of USERIDs under CA Workload Automation CA 7 Edition. SUBCHECK
requires that you code SUBUID.
When a user requests a job through a DEMAND, LOAD, or RUN, CA Workload Automation CA
7 Edition attempts to determine the USERID with which the job runs. External security is used
to validate the authority of the requester to submit for that USERID. Submit checking is also
performed during both JCL and QJCL edits. If a user attempts to add a USERID to the JCL, the
user's authority to submit for that ID is examined. This verification prevents unauthorized
08-Feb-2018 551/722
user's authority to submit for that ID is examined. This verification prevents unauthorized
usage of USERIDs.
If this option is used, CA Workload Automation CA 7 Edition also validates attempts to add,
change, or update the RESPONSE ID associated with an ARFSET.
SUBOWNER
Performs the same function as Submit checking except that it relates only to the OWNER ID
associated with a job. If a job has an OWNER ID defined, validation is performed for attempts
to add, change, or delete the OWNER ID.
XSUBCHECK
Validates the usage of USERIDs for XP jobs under CA Workload Automation CA 7 Edition. Using
XSUBCHECK requires that PSWDLOC is coded on the XPDEF statement. When a user requests
a cross platform job through a DEMAND, LOAD, or RUN, CA Workload Automation CA 7
Edition validates the requestor's authority to use the USERID that is transmitted to the remote
platform.
HIDEGRP
(Optional) Overlays user security group values coded in JCL with @ characters whenever JCL is
listed with one of the inquiry commands.
NO
Displays the values. This value is the default.
YES
Hides the following in inquiry output:
GROUP keyword value in JOB statements
For a list of the affected inquiry commands, see keyword HIDEUSER.
HIDEPW
(Optional) Overlays user security password values coded in JCL with @ characters whenever JCL is
listed with one of the inquiry commands.
NO
YES
PASSWORD keyword value in JOB statements
//*PASSWORD statement values
For a list of the affected inquiry commands, see keyword HIDEUSER.
HIDEUPD
(Optional) Suppresses the last updater on several of the listing commands.
Note: After you enable this keyword, perform an update on the element. When this
element is updated, *SECURE* is placed in the updater field.
08-Feb-2018 552/722
HIDEUSER
(Optional) Overlays user security ID values coded in JCL statements with @ characters whenever
JCL is listed with one of the inquiry commands.
NO
YES
USER keyword value in JOB statements
//*LOGONID statement values
//*JOBFROM statement values
These values are hidden when the following inquiries are used:
LACT,LIST=JCL LPRRN,LIST=JCL
LGVAR LQ,LIST=JCL
LJCK LQUE,LIST=JCL
LJCL LRDY,LIST=JCL
LLIB LREQ,LIST=JCL
LPDS
JCLUID
(Optional) Prevents submission of jobs whose JCL contains a USERID. This parameter is only
applicable if a SUBUID hierarchy is also specified.
YES
Indicates that CA Workload Automation CA 7 Edition submits the job after validating that CA
Workload Automation CA 7 Edition has authority to submit for the USERID in the JCL. This
NO
Indicates that CA Workload Automation CA 7 Edition does not submit a job that has a USERID
in the JCL. Instead, the job is requeued to the request queue with the status of R-NOUID at
submission time.
LOADSUBC
(Optional) Suppresses the submit check on the LOAD(H) command. This option only has meaning
if the EXTERNAL options include SUBCHECK.
YES
Validates the LOAD(H) commands with SUBCHECK. This value is the default.
NO
Exempts the LOAD(H) commands from the SUBCHECK validation.
LOGOPID
(Optional) Specifies whether the transaction log records for /LOGON commands include operator
ID. In all cases, password values are not logged.
YES
Indicates that transaction log records for /LOGON commands include operator ID. YES does
not write the operator ID to type x‘72’ log records. This value is the default.
NO
08-Feb-2018 553/722
NO
Indicates that transaction log records for /LOGON commands do not include operator ID.
ALL
Indicates that transaction log records for all commands include operator ID. ALL includes type
x‘72’ log records.
MIXPW
(Optional) Specifies whether the logon password can validly contain lowercase characters.
NO
Translates passwords to uppercase. This value is the default.
YES
Does not translate passwords to uppercase, allowing the password to contain lowercase
characters. Verify that your security interface (CA ACF2, CA Top Secret, or RACF) supports
lowercase passwords.
MULTIJOB
(Optional) Indicates whether CA Workload Automation CA 7 Edition controls the presence of
several JOB statements within a JCL member. One exception is the following: JOB statements
found within in-stream DD DATA are not controlled and are submitted as is.
IGNORE
Indicates that CA Workload Automation CA 7 Edition does not test for the presence of
multiple JOB statements within a job member when submitting the cards to the internal
reader. This value is the default.
FLUSH
Indicates that CA Workload Automation CA 7 Edition submits only the first job within a JCL
member and flush the rest of JCL. No special sign of JCL truncation is generated.
REQUEUE
Indicates that CA Workload Automation CA 7 Edition does not submit but requeues the job
that has several JOB statements within a JCL member. The requeued job has R-MJOB status.
Note: The MULTIJOB=IGNORE option is sometimes desirable for sites that transmit jobs
between MVS nodes.
PCLASS
(Optional) Specifies the resource class being used for security calls. The calls are made from CA
Workload Automation CA 7 Edition to validate the authority of the user to access CA Workload
Automation CA 7 Edition commands and panels. The default resource class is PANEL. This field
can be up to eight characters.
Note: If you change this value, examine the RCLASS keyword. The default for the RCLASS
keyword is PANEL.
08-Feb-2018 554/722
PROPAGATE
(Optional) Pertains only to RACF (and other SAF environments). This value determines the
method that CA Workload Automation CA 7 Edition uses to associate a USERID with a job when it
is submitted. This parameter is only applicable if a SUBUID hierarchy is also specified.
NO
Indicates that CA Workload Automation CA 7 Edition inserts a USER= parameter in the JOB
statement when a job is submitted. This value is the default.
YES
Indicates that CA Workload Automation CA 7 Edition does not modify the JCL being
submitted. Instead, the USERID is propagated to the submitted job because the USERID of the
job is used when the internal reader is opened to write the JCL. This process is similar to a job
submitted through TSO inheriting the USERID of the person who submitted it.
PSOWNER
(Optional) Determines whether a USERID is required to be the same as the OWNER to access a
job on the CA Workload Automation CA 7 Edition/Personal Scheduling panel.
YES
Indicates that the validation is done. The check requires that the USERID match the OWNER to
allow access to the job. This value is the default.
NO
Indicates no validation.
RCLASS
Workload Automation CA 7 Edition to validate a user's authority to access a UID Resource during
CA Workload Automation CA 7 Edition logon and when issuing the /UID,R= command. The default
resource class is PANEL. (The access level is READ.)
RESLOGON
(Optional) After an online terminal is logged on, subsequent LOGONs from the command line are
not permitted unless RESLOGON=NO.
YES
Any /LOGON command from the top line is treated as an error requiring a logon from the
formatted logon panel. This value is the default.
NO
/LOGON command is permitted.
RLOGUID
(Optional) Determines whether the LRLOG command (List Run Log) subjects job-related events to
CA Workload Automation CA 7 Edition UID internal security checks.
YES
Performs UID checking for LRLOG. This value causes LRLOG to display only jobs that the LRLOG
requestor has access to. This value is the default.
08-Feb-2018 555/722
NO
Performs no UID checking for LRLOG.
SCLASS
Workload Automation CA 7 Edition to validate a user's authority to submit CA Workload
Automation CA 7 Edition jobs under other user IDs. The default resource class is SUBMIT. This
field can be up to eight characters.
STATSID
(Optional) Controls disposition of USERID in PDS directory data when using the CA Workload
Automation CA 7 Edition editor. Members that are built with CA Endevor® in a CA Endevor library
do not have the USERID placed in the STATS.
YES
Writes the USERID to the PDS directory. This value is the default.
NO
Does not write the USERID to the PDS directory but writes it out as all @s.
SUBNOID
(Optional) Specifies the disposition of jobs that do not have a valid USERID available at job
submission time.
NO
Indicates that jobs without a USERID cannot be submitted. Jobs without a valid USERID are
moved back to the request queue and are marked with a requirement status of R-NOUID (No
USERID). A requirement of R-NOUID can be satisfied in two ways. If the QJCL subparameter
was selected on the SUBUID parameter, edit and replace the Queue JCL to set the USERID of
the Queue JCL editor. The second method is to insert a USERID manually into the JCL from the
Queue JCL Edit panel. CA Workload Automation CA 7 Edition identifies the USERID and
satisfies the R-NOUID requirement. This value is the default.
Note: For nonexecutable jobs with R-NOUID, a top line QJCL and a REPLACE function
can be done. If QJCL is in the hierarchy, the R-NOUID is satisfied. Code SUBUID when
SUBNOID=NO is coded.
YES
Indicates that jobs can be submitted without a USERID.
SUBUID
(Optional) Specifies a hierarchy of candidate USERID sources for USERID insertion during job
submission. If CA Workload Automation CA 7 Edition is inserting USERIDs into JCL during
submission, this list prioritizes the potential sources for USERIDs. The order of specification in the
list determines the priority of the USERIDs to select.
If the SUBUID keyword is added to the SECURITY statement and CA Workload Automation CA 7
Edition is recycled, any jobs already in the request queue are not affected. Cancel them and
demand them back in to use the new security data.
commas.
08-Feb-2018 556/722
OWNER
Indicates to select the job OWNER ID for insertion into the JCL for a Job during submission.
REQ
Indicates the requester's ID is a candidate for USERID insertion. The Requester ID can be the
ID of a user issuing a DEMAND, LOAD, or RUN command to request a job. The Requester ID
can also be the USERID selected for a job (requester) that then triggers additional jobs. The
triggered jobs inherit the USERID. For data set triggers, jobs that create or "post" a data set to
CA Workload Automation CA 7 Edition have their associated USERID propagated to any later
triggered jobs. For the U7SVC and SASSBCLP facilities, the USERID is extracted from the
current environment from which the user issues the data set creation or post request.
QJCL
Indicates that the USERID of any user editing Queue JCL for a job is a candidate for USERID
insertion. This value would be the USERID of the last person to edit Queue JCL for a job.
DEFAULT
Indicates that the default USERID specified with the DFLTUSER keyword is to be selected for
insertion.
CA7
Indicates that the USERID assigned to CA Workload Automation CA 7 Edition can be selected
for USERID insertion. If selected, the CA Workload Automation CA 7 Edition USERID is inserted
into the job's JCL during job submission. For CA ACF2, if started task checking is activated, this
option cannot be used.
UID
(Optional) Specifies a UID Resource Table that was built using the CA7RTBL macro. If this
parameter is specified, the UID Resource Table is loaded during CA Workload Automation CA 7
Edition initialization.
The CAL2OPTN member AL2UM09 can be used to build a table. A sample table (SASSRTBL) is also
supplied in the CAL2LOAD library.
USER
(Optional) Specifies the name of the load module link edited from the USERID macro assembly.
XBSCLASS
(Optional) Controls whether all CAICCI and TCP/IP terminal sessions use the external security class
used for Submit checking by CA Workload Automation CA 7 Edition. The SCLASS keyword on the
SECURITY statement sometimes overrides this class.
YES
Communicates the CA Workload Automation CA 7 Edition Submit security class to the CAICCI
and TCP/IP terminal sessions. This value is the default.
NO
Prevents the communication of the Submit security class setting from CA Workload
Automation CA 7 Edition to the CAICCI and TCP/IP terminal sessions. This value means that
the sessions use the default class ‘SUBMIT’. (This method is the way processing occurred
before Version 12.0.)
08-Feb-2018 557/722
XBSUBCHK
(Optional) Controls whether the Batch Submit Checking option (BSUBCHK) on the LPAR where CA
Workload Automation CA 7 Edition executes controls the submit checking on all CAICCI and TCP
/IP terminal sessions regardless of the LPAR on which they execute.
YES
Communicates the BSUBCHK setting from the LPAR where CA Workload Automation CA 7
Edition executes to the CAICCI and TCP terminal sessions. This value is the default.
NO
Prevents the communication of the BSUBCHK setting from CA 7 to the CAICCI and TCP/IP
terminal sessions. This value means the BSUBCHK setting on the LPAR where the CAICCI or TCP
/IP interface executes is used. (This method is the way processing occurred before Version
12.0.)
XPSSID
(Optional) Defines the one- to eight-character USERID to use in the terminal logon for XPS job
submission when no USERID is supplied on the submission request from the XPS CLIENT (typically
CA NSM or CA Workload Automation AE). This value is regarded as the requester ID for purposes
of USERID insertion and propagation. The default value is **NONE**, which means there is no
default USERID. Any XPS submission requests without an explicit USERID are rejected.
SERVICEDESK Statement
The SERVICEDESK statement initializes the CA Service Desk interface.

SERVICEDESK
The SERVICEDESK statement has no keywords.
SMF Statement
The SMF statement establishes the parameters for how CA Workload Automation CA 7® Edition is to
process SMF extract records. The statement is optional; however, if the SMF statement is coded, at
least one keyword is required. The SMF statement includes the following features:
Cross-system Coupling Facility (XCF)
Time Zone Normalization

SMF[,SMFXCF={NO|YES|xxxxxxxx}]
[,TZDISPLAY={EXEC|CA7}]
[,TZPREDS={EXEC|CA7}]
08-Feb-2018 558/722
SMFXCF
Defines whether to use the cross-system Coupling Facility (XCF) for ICOM to send SMF
information to CA Workload Automation CA 7® Edition. Can specify the XCF group name for CA
NO
Specifies to use the communications data set (COMMDS) for ICOM to communicate all SMF
information to CA Workload Automation CA 7® Edition. XCF is not used. This value is the
default.
YES
Specifies that ICOM uses XCF to send SMF information to CA Workload Automation CA 7®
Edition. A default XCF group name of CA7#CA7n (n is the instance number) is assigned for CA
Workload Automation CA 7® Edition. Use this parameter (or SMFXCF=xxxxxxxx) when
specifying XCF=NOTIFY on ICOM startup.
xxxxxxxx
Specifies that ICOM uses XCF to send SMF information to CA Workload Automation CA 7®
Edition. Specifies the value to use for the CA Workload Automation CA 7® Edition XCF group
name.
Note: All ICOMs that communicate with an instance of CA Workload Automation CA 7®

Edition (that use XCF) must share the same XCF group name.
TZDISPLAY
Defines the default option for those commands that allow a TZ keyword.
EXEC
Specifies that job start time and job end time are in the time zone where the job executed.
This value is the mode used before r11.3. EXEC time can be the same time zone as CA7 time.
CA7
Specifies that, where possible, job start time and job end time are normalized to the time
zone of the running CA Workload Automation CA 7® Edition.
TZPREDS
Specifies the time zone used to satisfy the lead (look back) time that can be used to satisfy initial
requirements when a job enters the request queue.
EXEC
Uses the time zone where the job executed, when the information is available. This value is
the default.
CA7
Uses the time zone of the running CA Workload Automation CA 7® Edition.
More information:
08-Feb-2018 559/722
XCF Group and Member Names (https://wiki.ca.com/display/CWAC7E

/XCF+Group+and+Member+Names)
STATEMGR Statement
The STATEMGR statement controls the interface between CA Workload Automation CA 7® Edition
and external products that monitor the state and availability of CA Workload Automation CA 7®
Edition tasks and functions. The statement is optional. However, if the STATEMGR statement is
coded, at least one keyword is required. This statement controls the following external interfaces:
ARM (IBM's Automatic Restart Management)
CA OPS/MVS® Event Management and Automation® SSM (CA OPS/MVS® Event Management and
Automation, System State Monitor)

STATEMGR[,ARM={NO|YES}]
[,OPSSSM={NO|YES}]
ARM
Specifies whether this CA Workload Automation CA 7® Edition registers with IBM's Automatic
Restart Management (ARM) for automatic restart services. The default is NO.
Note: If the primary CA Workload Automation CA 7® Edition online task is using ARM for
automatic restarts, a secondary, dormant copy of CA Workload Automation CA 7® Edition
is not necessary and should not be started. If a CA Workload Automation CA 7® Edition
online task is started with TYPE=DORM and contains initialization file statement
STATEMGR,ARM=YES, a user abend occurs, and the dormant task fails.
OPSSSM
Specifies whether this CA Workload Automation CA 7® Edition interfaces with the CA OPS/MVS®
Event Management and Automation System State Manager (SSM) by sending current state
information. The default is NO.
If you are running CA Workload Automation CA 7® Edition in batch mode (INIT,RUNOPT=MAIN/REPT

and RESIDENT,NETWORK=BAT), either ARM=YES, OPSSSM=YES, or both are ignored, and no
interfaces are activated.
STATIONS Statement
The STATIONS statement defines an installation's workstations or logical terminals, and assigns each
to a physical terminal that is already defined by a TERM statement. The STATIONS statement must
not be specified for virtual terminals.
08-Feb-2018 560/722
Several STATIONS statements are supplied with the skeleton initialization file. Changes may be
required to fit the user's terminal network and workstation naming conventions.
A STATIONS statement is always required for each TERM statement (except for virtual terminals),
even though the terminal is not used as a workstation. The STATIONS statement can be continued.
Keywords are positional and must appear in the order shown.

STATIONS,TRMID=xxxxxxx{STANIDS|LTERM}={xxxxxxxx|(xxxxxxxx,...)}
TRMID
Specifies the name of a terminal to which this STATIONS statement is associated. Value must be
the terminal name, up to seven characters, defined by NAME on the TERM statement. TRMID is
required and has no default. All TRMIDs must be unique.
STANIDS | LTERM
Specifies the workstation name, or logical terminal name. Value must be a name, up to eight
characters. Multiple workstation or logical terminal names can be defined as a sublist, that is
enclosed in parentheses and separated by commas. STANIDS is required and has no default. The
value that is given for STANIDS must not be the same as any TRMID value and all STANIDS values
must be unique.
STANIDS=MASTER defines the CA Workload Automation CA 7® Edition master station that is to
receive most CA Workload Automation CA 7® Edition messages. You must have one, and only
one, STATIONS statement that specifies STANIDS=MASTER.
For an online run of CA 7 (RESIDENT statement does not have NETWORK=BAT), the master station
must refer to the browse data set (TERM DEVICE=BSAM).
For a batch run of CA 7 (RESIDENT statement has NETWORK=BAT), the master station must refer
to the batch terminal (TERM DEVICE=BATCH).
LTERM can be used interchangeably with STANIDS.
STNCAL Statement
The STNCAL statement defines working hours in a day and working days in a year for the installation's
workstations. A separate STNCAL statement can be supplied for each workstation. Alternately, a
number of workstations can be combined in one STNCAL statement. An STNCAL statement is
optional. If provided, it must immediately follow the last STATIONS statement. If omitted, it is
assumed that all workstations are available 24 hours a day for all days in a year and messages to
these terminals are queued. When the terminals are not available (that is, not within working days
and hours specified), messages for these terminals go to STANIDS=MASTER.

STNCAL[,CAL=SCALyynn]
[,FROM={0000|hhmm}]
[,TO=2400|hhmm]
,STN={xxxxxxxx|(xxxxxxxx,...)}
CAL
(Optional) Specifies the name of a base calendar used for determining working days for the
workstation defined by the keyword STN. CAL is optional. If provided, a CALBLK statement must
define the corresponding calendar name. If omitted, it is assumed all days are working days for
the workstation defined by the keyword STN. Value must be in the format SCALyynn
08-Feb-2018 561/722
yy
Identifies the year defined for the calendar (15, 16, and so forth). The value must correspond
to the value specified for YEAR on the CALENDAR macro statement.
nn
Identifies the unique name assigned by the user at the time the base calendar was generated
(that is, the value specified for SCAL on the CALENDAR macro statement).
FROM
(Optional) Specifies the starting time of a working day. Value must be in the format hhmm where
hh are hours of a day (00 through 23) and mm are minutes of an hour (00 through 59). If
provided, it must be less than the value specified for TO. If omitted, the default is FROM=0000.
TO
(Optional) Specifies the ending time of a working day. Value must be in the format hhmm where
hh are hours of a day (00 through 24) and mm are minutes of an hour (00 through 59). If
provided, it must be greater than the value specified for FROM. If omitted, the default is
TO=2400.
STN
Specifies the workstation names (logical terminals) for which working hours and days are defined.
Value must be a name, up to eight characters. Multiple workstation names can be defined as a
sublist, enclosed in parentheses and separated by commas. STN is required and has no default.
You must have a corresponding STANIDS value on a STATIONS statement for each of the
workstations defined. STN must be the last keyword defined in the STNCAL statement.
SVCNO Statement
The SVCNO statement indicates the availability of the type 3/4 SVC assigned to CA Workload
Automation CA 7® Edition. This statement must always be present and can only be specified once.
Note: The XPDEF statement can override all cross-platform keywords. The keywords
MONITOR, ROUTER, and XPSSCHD should be converted to the keywords XMONITOR,
XSERVER, and XPSSCHD.

SVCNO[,SASSVC={YES|NO}]
[,CA7={CA71|alias|CA7n|PROD|TEST}]
[,DORMENQ={10|nnn}]
[,DORMVER={60|nnn}]
[,MONITOR={NO|YES|xxxxxxx}]
[,RNAME=xxxx]
[,ROUTER={NO|YES}]
[,TEST={NO|YES}]
[,XPSSCHD={DEMAND|RUN|RUNREF}]
[,XTMNAME=xxxx]
Note: See the MONITOR, ROUTER, and XPSSCHD keyword descriptions for default values.
08-Feb-2018 562/722
Note: See the MONITOR, ROUTER, and XPSSCHD keyword descriptions for default values.
SASSVC
Specifies whether the SVC is available. SASSVC is required. Value can be YES or NO.
YES
CA Workload Automation CA 7® Edition obtains the SVC number from the instance control
block (ICMDSECT) addressed by the IVT (Instance Vector Table). This is the default.
NO
CA Workload Automation CA 7® Edition executes without the SVC number. This should only
be used for testing purposes when job tracking is not wanted.
SASSVC=NO can be used for installation testing of CA Workload Automation CA 7® Edition. No

jobs can be tracked, but the various formatted panels can be displayed and functions performed,
such as adding jobs, schedules, user documentation, and so forth. The editor can also be used.
When testing in this manner, RUNOPT=REPT should be specified in the INIT statement.
CA7
Indicates which instance of CA Workload Automation CA 7® Edition to start. Keywords CA7 and
TEST are mutually exclusive.
CA71
Maps to what used to be known as the "production" copy of CA Workload Automation CA 7®
Edition. This is the default.
CA7n
Maps to instance CA7n where n is an integer from 2 to 8.
alias
Specifies a one- to four-character alias. This alias must correspond to an alias assigned to a CA
Workload Automation CA 7® Edition instance during initialization by CAIRIM.
PROD
Maps to instance CA71.
TEST
Maps to instance CA72.
DORMENQ
Specifies the number of seconds that a dormant copy of CA Workload Automation CA 7® Edition
waits between checks for an inactive production copy.
nnn
Defines the number of seconds between checks. The default is 10.
DORMVER
Specifies the number of seconds that a dormant copy waits, after it determines that the
production is inactive, before completing initialization and becoming the production copy.
nnn
Defines the number of seconds to wait. The default is 60.
08-Feb-2018 563/722
MONITOR
Identifies this copy of CA Workload Automation CA 7® Edition as an XPS SUBMIT MONITOR that
can receive cross-platform scheduling requests.
Note: If an XPDEF statement is coded, the value coded or derived from the XPDEF
statement overrides this setting.
Allowable values are YES, NO, or a seven-byte monitor name that will be used. The default value
is NO. If the value of MONITOR is YES, a monitor name is generated. If SASSVC=NO, the MONITOR
keyword is ignored.
NO
CA Workload Automation CA 7® Edition does not receive cross-platform scheduling requests.
This is the default.
YES
Generates a monitor name consisting of a string of seven non-blank or null characters.
If CA7=CA7n, where n is 1 through 8, or if PROD, TEST, or an alias is used, the monitor name
generated will be the four characters following CA7= right padded to a length of 7 with Xs.
The following rules are in effect to maintain compatibility with pre-release 11 startup files:
If CA7= is omitted and TEST=YES is not specified, the string begins with CA7.
If CA7= is omitted and TEST=YES is specified, the string begins with TS7.
The remaining four positions of the string are filled with the SMF ID where CA Workload
Automation CA 7® Edition executes.
Any blank positions at the end of the string will be filled with an EBCDIC 'X'.
Examples for an SMF ID of MVS1:
If CA7 and TEST=YES are omitted, the generated monitor name is CA7MVS1.
If TEST=YES is specified, the generated monitor name is TS7MVS1.
Examples for an SMF ID of MVS:
If CA7 and TEST=YES are omitted, the generated monitor name is CA7MVSX.
If TEST=YES is specified, the generated monitor name is TS7MVSX.
Examples where the SMF ID is not used:
If CA7=CA72, the generated monitor name is CA72XXX.
If CA7=PROD, the generated monitor name is PRODXXX.
If an alias of SYS4 is coded in CA7=SYS4, the generated monitor name is SYS4XXX.
08-Feb-2018 564/722
xxxxxxx
The monitor name to be used can be declared as a value of the keyword. It must consist of
seven non-blank or null EBCDIC characters.
Example: MONITOR=XXX is not a valid specification because it is not long enough.
MONITOR=CA7 1 is not valid because a blank is embedded in the keyword value and because
it is not long enough.
Note: You must ensure that the monitor name generated or specified is unique within
the domain of the XPS ROUTER. If it is not unique, the XPS SUBMIT MONITOR function
terminates with an error.
A console message during CA Workload Automation CA 7® Edition initialization announces the

value for MONITOR that is generated or specified.
RNAME
Use this parameter if you want to override the default RNAME used to ENQ the instance control
block (ICMDSECT) at startup. The default is the instance name (declared or implied by the value of
the CA7 keyword). For example, CA71 is the default RNAME for the first tracking instance of CA
Workload Automation CA 7® Edition. CA72 is the default RNAME for the second tracking instance.
In compatibility mode, the defaults are UC07 and UCT7. The value of the keyword can be one to
four alphanumeric characters.
ROUTER
Indicates whether the XPS SUBMIT ROUTER will run in this CA Workload Automation CA 7®
Edition address space. Only one CA Workload Automation CA 7® Edition address space can
function as the XPS Router.
If applicable, this XPS Router routes the work to other CA scheduling solutions.
YES
Indicates that the XPS ROUTER will run in this address space.
NO
Indicates that the XPS ROUTER will not run in this address space.
If ROUTER=YES is specified, MONITOR=YES must also be specified.

If MONITOR=NO is specified, the default value for ROUTER is also NO.
If using the pre-r11 TEST= keyword, the default value for this keyword depends on the values of
TEST and MONITOR.
If TEST=YES is specified, the default value of ROUTER is NO. It is assumed that the XPS ROUTER
will run in the address space associated with the production copy of CA Workload Automation CA
7® Edition.
If MONITOR=NO is specified, the default value for ROUTER is also NO.
If neither of the above conditions is true, the default value for ROUTER is YES.
TEST
08-Feb-2018 565/722
TEST
This keyword is kept for compatibility with pre-r11 releases. Its meaning has changed slightly.
Keywords TEST and CA7 are mutually exclusive.
NO
Uses instance CA71.
YES
Uses instance CA72.
XPSSCHD
Identifies the CA Workload Automation CA 7® Edition command to be used for cross-platform
scheduling requests. When CA Workload Automation CA 7® Edition receives such a request, a CA
Workload Automation CA 7® Edition command to schedule the job is built using parameters
supplied by the requester. The allowable values are RUNREF, DEMAND, and RUN.
XPSSCHD=RUNREF is the default.
RUNREF
Specifies that the job requested does not trigger other jobs, it does not wait for satisfaction of
requirements, nor does it satisfy requirements for other jobs. Such a job cannot be restarted
in CA Workload Automation CA 7® Edition, but is considered complete when CA Workload
Automation CA 7® Edition is notified of its completion on the mainframe. A job that is
requested by an XPS CLIENT when this option is in effect reports an entry mode of 'XPS' in the
output of queue display commands such as LQ.
Because of the restrictions on requirements and restart, jobs requested using this option
encounter fewer conditions preventing immediate submission and cause notification of
completion to be sent to the requester in a timely manner.
Use of this option minimizes processing delays due to conditions that might otherwise require
manual intervention.
If this option is used, triggers, requirements, and job rerun conditions should be defined and
documented in the XPS CLIENT. This ensures that the primary responsibility for workload
control is assigned to the XPS CLIENT (typically CA NSM or CA Workload Automation AE).
However, if it is important that CA Workload Automation CA 7® Edition retain restart control
or if it is important that CA Workload Automation CA 7® Edition requirement and trigger
definitions be honored, you should consider the other XPSSCHD options.
DEMAND
Indicates that the job named on the cross-platform scheduling request is scheduled using the
DEMAND command. CA Workload Automation CA 7® Edition verifies the availability of input
requirements for the job prior to submission and updates the database on successful
completion of the job. Triggers defined for the job are honored when the job successfully
completes. A job scheduled with this option exits the request queue only when the job
completes normally. Otherwise, it remains in the request queue to be restarted. The entry
mode for a job requested by an XPS CLIENT when this option is used is XDEM in the output of
queue display commands such as LQ.
08-Feb-2018 566/722
RUN
Indicates that the job named on the cross-platform scheduling request is scheduled using the
RUN command. CA Workload Automation CA 7® Edition does not verify requirement
availability for the job. This instance of the job does not satisfy any requirement other jobs
can have for this one. Triggers defined for this job are not honored for this instance of the job.
However, like the job scheduled with DEMAND, a job scheduled using RUN exits the request
queue only on normal job completion. Thus, the job can be restarted in CA Workload
Automation CA 7® Edition. The entry mode for a job requested by an XPS CLIENT when this
option is used is reported as XRUN in the output of display commands such as LQ.
Note: It is important to remember the XPS CLIENT is notified of job completion only when
the job requested exits the request queue. If XPSSCHD=RUNREF, this occurs when CA
Workload Automation CA 7® Edition is notified of job completion (whether normal or
abnormal). If XPSSCHD=DEMAND or XPSSCHD=RUN, this occurs when the job completes
normally in CA Workload Automation CA 7® Edition, or when the job is forced completed,
or if the job is canceled in CA Workload Automation CA 7® Edition prior to submission.
If cross-platform scheduling is used, give careful consideration to the assignment of

responsibilities for monitoring and controlling the workload. The value on the XPSSCHD
parameter is important because it affects distribution of those responsibilities. To determine the
appropriate value for this parameter, you must decide if the greatest degree of control should be
given to the XPS CLIENT (typically CA NSM or CA Workload Automation AE) or if the XPS SERVER
(in this case CA Workload Automation CA 7® Edition) should share responsibility for such control.
We recommend XPSSCHD=RUNREF if the primary point of workload control is to be the XPS
CLIENT. In this case triggers and requirements should be defined in the XPS CLIENT. Jobs cannot
be restarted, but can be rerun from the XPS CLIENT.
If a greater degree of control for the XPS SERVER is wanted, XPSSCHD=DEMAND or XPSSCHD=RUN
can be used. If you use one of these options, you can use the CA Workload Automation CA 7®
Edition restart facilities for the job. If you use XPSSCHD=DEMAND, CA Workload Automation CA
7® Edition trigger and requirement definitions are honored. Although these options allow use of
CA Workload Automation CA 7® Edition controls over the workload on the XPS SERVER, a greater
likelihood for processing delays exists due to requirement posting or restarts that cannot be
directly controlled from the XPS CLIENT.
Note: You can override this value for selected jobs by adding the XPSSCHD keyword after
the job name in the 'filename' field (Job detail - submission - filename). For more
information, see the XPS SERVER Implementation Checklist (https://wiki.ca.com/display
/CWAC7E/CA+Workload+Automation+CA+7+Edition+XPS+Server+Implementation+Checklist).
XTMNAME
Indicates to change the suffix used for the CA Workload Automation CA 7® Edition CAICCI receiver
application name (CA-7 XTM xxxx). The XTMNAME can be set to make the CA Workload
Automation CA 7® Edition CAICCI receiver name for each copy of CA Workload Automation CA 7®
Edition unique across the CAICCI network. The default is the RNAME= value (usually the instance
name). The xxxx value can be one to four alphanumeric characters.
Note: The values PROD and TEST should not be used since the CA Workload Automation
08-Feb-2018 567/722
Note: The values PROD and TEST should not be used since the CA Workload Automation
CA 7® Edition CAICCI distributed code converts these values to UC07 and UCT7,
respectively.
TERM Statement
The TERM statement defines the terminals to be active after initialization. The type of terminal, its
page structure and addresses are supplied by this statement. With the exception of virtual terminals,
each terminal that is to have access to CA Workload Automation CA 7® Edition must have a TERM
statement. For DEVICE=3270V terminals, multiple TERM statements can be associated with a single
LINE statement.
At least one TERM statement is always required to define either the CA Workload Automation CA 7®
Edition master terminal (for online initialization), or a batch terminal to be used for input and output
(for batch or maintenance initialization). The TERM statement can be continued.
The theoretical maximum number of TERM statements, and therefore the maximum number of
terminals, is 16,000. However, a more practical limit in the range of 100 to 200 terminals should be
observed if possible. When the terminal network exceeds that size, memory requirements can
become significant. Performance levels may prove to be less satisfactory due to competition between
terminals for resources. To avoid potential performance problems, review the initialization file
considerations.
For the virtual terminal definition, a TERM statement is optional. If a TERM statement is not coded,
CA Workload Automation CA 7® Edition generates one TERM statement with a + in column 1 to
indicate that terminal control blocks were built. Printers cannot be used as virtual terminals.
All keywords are nonpositional and can appear in any order following TERM.

TERM,DEVICE=xxxxx,NAME=xxxxxxx [,CONS={MASTR|ALTRN}]
[,LCLSNA={N0|YES}]
[,LINELEN={nnn}]
[,LOGMODE={ZEROS|xxxxxxxx|BLANKS}]
[,MONLIM={2|n}]
[,NLINE=nnnnn}]
[,PRINTER=YES]
[,RELEASE={YES|NO}]
[,SIMLOG={YES|NO}]
[,TIMLIM={30|nn}]
[,VLOGOFF={PFnn|PAnn}]
[,VTAMID=xxxxxxxx]
DEVICE
Specifies the symbolic device type of the terminal. DEVICE is required and has no default. Value
must be one of the following and must match the DEVICE value given on the associated GROUP
statement:
3270V
Indicates the terminal is a 3270-type device or associated printer, either local or remote, that
is defined to VTAM.
08-Feb-2018 568/722
BATCH
Indicates a batch terminal. Eight terminals with DEVICE=BATCH can be defined for each
initialization of CA Workload Automation CA 7® Edition.
CCI
Indicates the terminal is used with either the CA Workload Automation CA 7® Edition CAICCI
terminal interface or the CA Workload Automation CA 7® Edition TCP/IP terminal interface.
CONSL
Indicates the terminal is the device designated as an OS system console. Only one terminal
with DEVICE=CONSL can be defined for each initialization of CA Workload Automation CA 7®
Edition.
TRLDV
Indicates the terminal to be used for input of trailer step commands. Only one terminal with
DEVICE=TRLDV can be defined for each initialization of CA Workload Automation CA 7®
Edition.
TRXDV
TRXDV indicates the terminal will be dedicated to transactions scheduled internally by CA
Workload Automation CA 7® Edition functions. At least one such terminal must be defined if
either of the following CA Workload Automation CA 7® Edition functions are used:
ARF (RESTART,ARF=YES is specified)
CA Workload Automation CA 7® Edition XPS SERVER support
BSAM
Indicates that this terminal represents a sequential, print-image browse data set where the
master station messages are received. Only one terminal with DEVICE=BSAM can be defined
for each initialization of CA Workload Automation CA 7® Edition. This "terminal" must
correspond to STANIDS=MASTER on the STATIONS statement. The terminal with
DEVICE=BSAM must be in the group named BROWSE.
NAME
Specifies the name that identifies the terminal. The value, up to seven characters, must match the
TNAME value (on the associated LINE statement) that refers to this terminal. NAME is required
and has no default. NAME=MASTER should never be specified since this would prevent
identification of a master terminal through the STANIDS parameter on the STATIONS statement.
See the VTAMID parameter for eight-character VTAM terminal names.
CONS
Designates a terminal from which the /SHUTDOWN command can be entered. CONS is optional
and should only be specified for the terminals to be designated as master and alternate master.
The device type for master and alternate does not have to be a console. Any 3270x terminal
suffices. When omitted, the terminal is assumed not to be a CA Workload Automation CA 7®
Edition alternate master terminal. Value must be one of these:
08-Feb-2018 569/722
MASTR
Identifies the CA Workload Automation CA 7® Edition master terminal. You can have only one
master terminal defined for each initialization of CA Workload Automation CA 7® Edition. This
should not be confused with STANIDS=MASTER. CONS=MASTR and STANIDS=MASTER rarely
refer to the same terminal.
ALTRN
Identifies an alternate CA Workload Automation CA 7® Edition master terminal. You can have
multiples of these as needed.
Note: This option must be specified on DEVICE=BATCH if you want to honor

SHUTDOWN commands from Batch Terminals (BTI).
LCLSNA
This keyword must be specified as YES when using local SNA terminals under VTAM with any type
of 3274-1A controller (for example, 3274-21A and 3274-41A). For all other arrangements, this
keyword must be omitted. For virtual terminals, this parameter should not be coded. CA
Workload Automation CA 7® Edition sets the appropriate indicator at connection time. NO is the
default. This applies to all SNA terminals, including MASTER.
LINLEN
Specifies the length of output lines for the terminal device. LINLEN is required for non-3270x
devices. For 3270x devices, the default value is 80. Value depends on the symbolic device type
(designated by DEVICE) and must be one of the following:
If DEVICE=BATCH, LINLEN must be line length + 5 (line characters plus ASA control character
and record descriptor word).
If DEVICE=BSAM or DEVICE=3270x, LINLEN must be 80.
If DEVICE=CONSL, LINLEN must be 110.
If DEVICE=TRLDV, LINLEN depends on the device type of the CA Workload Automation CA 7®

Edition master station (designated by STANIDS=MASTER on the STATIONS statement).
If DEVICE=TRLDV or TRXDV, LINLEN depends on the device type of the CA Workload

Automation CA 7® Edition master station (designated by STANIDS=MASTER on the STATIONS
statement).
If DEVICE=CCI, LINLEN must be 137.
LOGMODE
Specifies the VTAM log mode name used to identify the kind of information necessary to connect
with the terminal. LOGMODE is optional. If omitted, the default is LOGMODE=ZEROS that causes a
LOGMODE name of binary zeros to be used. BLANKS cause a name of character blanks to be used.
If virtual terminals have been specified and the TERM statement is not coded, LOGMODE defaults
to ZEROS.
Note: LOGMODE=ZEROS is required for cross-domain communications in multi-CPU
08-Feb-2018 570/722
Note: LOGMODE=ZEROS is required for cross-domain communications in multi-CPU

complexes.
MONLIM
Specifies the number of minutes of inactivity allowed to elapse before the terminal is taken out of
monitor mode. Monitor mode is used for TIQ and ARTS online functions. This parameter is
optional and default is for two minutes. Specify zero (0) minutes to disable this feature.
NLINE
Specifies the number of lines per page for the designated device type. NLINE is required for non-
3270x devices. For 3270 devices, the default value is 24. Value depends on the device type
indicated by DEVICE and must be one of the following:
If DEVICE=BSAM OR DEVICE=BATCH, NLINE=60 can be used. This value is variable and can be
set at the user's discretion. It should never be less than 10. Leading zeros are not required.
The maximum value is 32767.
If DEVICE=3270x, NLINE=24 must be used.
If DEVICE=CONSL, NLINE=10 can be used. This value is variable and can be set at the user's
discretion.
If DEVICE=TRLDV or TRXDV, NLINE depends on the device type of the CA Workload

Automation CA 7® Edition master station (designated by STANIDS=MASTER on the STATIONS
statement).
PRINTER
Specifies that the device for the terminal being defined is a 3270 associated printer. Value must
be PRINTER=YES. PRINTER is optional. If omitted, it is assumed the device is not a printer. If used,
DEVICE=3270x must also be specified. For virtual terminals, PRINTER=YES cannot be specified.
RELEASE
Specifies if CA Workload Automation CA 7® Edition is to release control of the terminal (3270V) to
another application under VTAM requesting the terminal. RELEASE is optional and applies to
DEVICE=3270V terminals only. Value must be one of the following:
YES
Release the terminal if requested by another application. This is the default.
NO
Do not release the terminal. It is advisable to use RELEASE=NO for VTAM printer devices.
SIMLOG
Specifies if CA Workload Automation CA 7® Edition is to acquire (issue a SIMLOGON) the terminal
under VTAM. SIMLOG is optional and applies to DEVICE=3270V (VTAM) terminals only. Value
must be one of the following:
YES
CA Workload Automation CA 7® Edition is to acquire the terminal through a simulated logon
(SIMLOGON) if OPEN=YES was specified on the UCC7VTAM statement. This is the default.
08-Feb-2018 571/722
NO
CA Workload Automation CA 7® Edition does not attempt to acquire the terminal. With this
option the terminal operator must initiate the logon.
TIMLIM
Specifies the number of minutes of inactivity allowed to elapse before the terminal is
automatically logged off CA Workload Automation CA 7® Edition. In the case of a virtual terminal,
the terminal is also returned to VTAM. This parameter is optional and the default is 30 minutes.
To disable the logoff feature, specify zero (0) minutes.
Note: When using the ISPF interface, the effective TIMLIM for the session will be the
greater of 30 minutes or the specified TIMLIM (if a nonzero TIMLIM is coded). Also, no
indication of a CA Workload Automation CA 7® Edition time out from an ISPF editor
session occurs until the editor session is terminated. This means that a SAVE should be
done before the TIMLIM is exceeded or all the edits will be lost.
VLOGOFF
Specifies the program function (PF) or program access (PA) key used to log off CA Workload
Automation CA 7® Edition and return to VTAM. The format for program function keys is PF nn
where nn is a number from 01 to 24. The format for program access keys is PA nn where nn is a
number from 01 to 03. A two-digit number is required such as PA01; PA1 is invalid. VLOGOFF is
optional and is used with DEVICE=3270V only.
VLOGOFF on the GROUP statement can be used to establish a default logoff PF or PA key for all
VTAM terminals associated with the group. VLOGOFF on the TERM statement overrides the
GROUP definition for that terminal. If not specified in either statement, the terminal operator
must issue a /CLOSE command, with no parameters, to return to VTAM.
VTAMID
Specifies the VTAM terminal identification name, up to eight characters. If omitted, VTAMID is
assumed to be the NAME value. NAME has a maximum of seven characters.
More information:
Terminal Dispatching Priority (https://wiki.ca.com/display/CWAC7E

/Terminal+Dispatching+Priority)
UCC7VTAM Statement
The UCC7VTAM statement is required if you plan either of the following options:
Connecting VTAM terminals to CA Workload Automation CA 7® Edition
Using the CA Workload Automation CA 7® Edition TCP/IP terminal interface
This statement defines the following types of information to CA Workload Automation CA 7® Edition:
08-Feb-2018 572/722
Information to access the 3270-type terminals defined later in the initialization file with GROUP,
LINE, and TERM statements (DEVICE=3270V).
VTAM options used by CA Workload Automation CA 7® Edition.
TCP/IP port number and timeout time used by the CA Workload Automation CA 7® Edition TCP/IP
terminal interface server

UCC7VTAM,APPL=xxxxxxx [,NUMRECV={3|n}]
[,OPEN={YES|NO}]
[,TCPTMOUT={10|nnn}]
[,TCPTPORT={nnnnn}]
[,VTNAME={VTM|xxx}]
APPL
Specifies the name of the VTAM ACB that defines CA Workload Automation CA 7® Edition to
VTAM. Specify APPL in up to seven characters. APPL has no default.
NUMRECV
(Optional) Specifies the number of VTAM RECEIVE macros to be outstanding concurrently in CA
Workload Automation CA 7® Edition. This value is the number of inputs from VTAM terminals that
can be processed simultaneously. The default is NUMRECV=3.
OPEN
(Optional) Specifies if the CA Workload Automation CA 7® Edition VTAM ACB is to be opened
during initialization. If used, value must be one of the following options:
YES
Opens the VTAM ACB during CA Workload Automation CA 7® Edition initialization. CA
Workload Automation CA 7® Edition attempts to acquire those terminals that have
SIMLOG=YES specified on their TERM statements. This value is the default.
NO
Does not open the VTAM ACB during CA Workload Automation CA 7® Edition initialization. A
/OPEN,GROUP=(the first VTAM group in the initialization file) must be entered through a non-
VTAM CA Workload Automation CA 7® Edition terminal to enable VTAM terminals to access
CA Workload Automation CA 7® Edition.
TCPTMOUT
(Optional) Specifies the TCP/IP timeout time in seconds from 1 to 120. The default is 10 seconds.
TCPTPORT
(Optional) Specifies the TCP/IP port number assigned to CA Workload Automation CA 7® Edition.
This keyword is required if the CA Workload Automation CA 7® Edition TCP/IP terminal interface
is used. The port number must be unique from other instances of CA Workload Automation CA 7®
Edition running on the same machine (that have the same TCP/IP address). No default exists. The
maximum number is 65535.
VTNAME
(Optional) Specifies the first three characters of the CA Workload Automation CA 7® Edition
virtual terminal names. If VTNAME is specified, it must be three characters. If VTNAME is omitted,
the default is VTM.
08-Feb-2018 573/722
VRMOPTS Statement
The VRMOPTS statement can define processing options for the CA Workload Automation CA 7®
Edition Virtual Resource Management facility (VRM). The VRMOPTS statement is optional. However,
if VRMOPTS is used, the RPLCNT keyword is required.

VRMOPTS,RPLCNT={5|nn}
RPLCNT
Specifies the number of RPLs to allocate for access to the VRM data. This value establishes the
number of threads that can access the data concurrently. The specified value can range from 1
through 64, however, we recommend that you specify at least 3. The default is 5.
XPDEF Statement
The XPDEF statement establishes the parameters for cross-platform communications and the actions
to perform for jobs sent or received by the CA Workload Automation CA 7® Edition online system. To
establish appropriate options, code this statement.
Note: When XPDEF is specified, CA Workload Automation CA 7 Edition verifies that

RSRC=YES is coded on the DBASE statement. Also, CA Workload Automation CA 7 Edition
checks for the existence of a terminal that is defined as DEVICE=TRXDV. The TRXDV type is
necessary when XSERVER=YES.

XPDEF[,AGENTDAY={15|nn}]
[,AGENTJOB={NO|YES}]
[,AGENTWTO={NO|YES}]
[,PSWDLOC=({DATABASE,OWNER,NODE,USER,...}}
[,SUBROOT={NO|YES}]
[,XMONITOR=monitor]
[,XPHAO=primaryname]
[,XPKILL={YES|NO}]
[,XPSSCHD={RUNREF|RUN|DEMAND}]
[,XPSTRC={11|nn}]
[,XROUTER={NO|YES}]
[,XSERVER={NO|YES}]
[,XSERVERTRC={NO|YES}]
[,XSUBMIT={YES|NO}]
[,XTRKTRC={11|nn}]
AGENTDAY
(Optional) Specifies the number of days to retain information in the CA7AGNT file before that
information is eligible for deletion. Specify a number from 1 to 35. The default is 15.
The /DELAGNT command deletes the information from the CA7AGNT file, and if not specified
there, uses the value stated here to determine what information to delete.
08-Feb-2018 574/722
Important! Schedule a batch job to issue the /DELAGNT command on a periodic basis to
keep the CA7AGNT file clean of old entries.
Note: For more information about the CA7AGNT file, see DDNAME=CA7AGNT (https://wiki.
ca.com/display/CWAC7E/CA+WA+CA+7+Edition+File).
AGENTJOB
(Optional) Specifies whether this CA Workload Automation CA 7® Edition can send jobs to
another platform through agent job facilities.
NO
Returns error messages after any attempts to enter agent job-related data (commands to
refresh the agent table, define agent jobs, and other agent functions). A bit in the UCC7SVT
reflects this state. This value is the default.
YES
Sets up the agent job environment.
AGENTWTO
(Optional) Specifies whether to issue WTOs when agents are not receiving messages or jobs are
waiting on agent activation (for example, LQ Job Status shows W-AGENT).
NO
WTO messages are not generated for either situation. This is the default.
YES
WTO messages CAL2I743W and CAL2I744W are generated in the situations previously
described.
Note: The XPDEF AGENTJOB keyword must be YES for agent WTOs to be generated during
CA Workload Automation CA 7 Edition startup. It can be turned ON (YES) or OFF (NO) after
startup using the /CHGOPT command.
PSWDLOC
(Optional) Specifies the permissible locations for the storing of the user ID/password data for
XPJOB jobs. This keyword lets a site determine the security protection for the sensitive data. If a
password is specified, the user ID and password must come from the same source. The order of
the subparameters coded determines the hierarchy.
Default: DATABASE, OWNER, NODE, USER
DATABASE
Indicates the user ID and password were entered using the XPSWD command and stored in
the CA Workload Automation CA 7® Edition database. This value is the preferred location.
OWNER
Indicates the user ID specified in the OWNER field on the DB.10 panel is used, and no
associated password is permitted.
NODE
08-Feb-2018 575/722
NODE
Indicates the user ID and optional password that is associated with this node is used in the
AJB sent to the targeted node.
USER
Indicates the user ID and password are stored with the PARM1 through PARM64 data in the
parameter library (the JCL library where XPJOB parameters are stored).
The AJB does not require a USER field to be passed to the node, and thus if no user ID is found
from any of the preceding sources, then no user ID is placed in the AJB for the job. The targeted
node may fail the execution, and CA Workload Automation CA 7® Edition may receive the
notification of this failure. The user may then place user information in the queue parameter
data.
SUBROOT
(Optional) Indicates whether an XPJOB job can use the user ID ROOT, which has extra meaning for
"super" authority in a UNIX environment. The default is NO.
XMONITOR
(Optional) Defines the monitor name to use for both internal XPJOB submissions and for the XPS
SUBMIT MONITOR to receive cross-platform scheduling requests. The name must consist of 7 non-
blank or NULL EBCDIC characters and must be unique within the domain of the XPS ROUTER. The
default is 'CA7' followed by the instance name or alias, if present. If an alias is used and is less
than 4 positions the trailing positions of the monitor name are filled with the letter X. (For
example, CA71XXX)
XPHAO
(Optional) Defines the 1-16 character primary name to use with the high availability option. When
coded, it enables the high availability option for XPJOB submissions by adding the PRIMARY
keyword to the AJB and allowing its use in the internal TRACKER task. The keyword has no
default.
XPKILL
(Optional) Indicates whether a cancel request is sent to the target platform when a CANCEL
command is entered. The default is YES. When set to NO, the cancel request is not sent to the
target platform. The request requires a manual cancellation.
XPSSCHD
(Optional) Identifies the CA Workload Automation CA 7® Edition command to use for cross-
platform scheduling requests. When CA Workload Automation CA 7® Edition receives such a
request, a CA Workload Automation CA 7® Edition command to schedule the job is built using
parameters supplied by the requester. The allowable values are RUNREF, DEMAND, and RUN. The
default is XPSSCHD=RUNREF.
XPSTRC
(Optional) Specifies the trace codes to control the level of diagnostic messages and snaps that
should be generated by the XPS ROUTER. There are two codes that can be specified: print/snap
trace code and console message trace code. The first value controls what messages will be
written to the XPSPRINT DD, and what records and control blocks will be written to the XPSSNAP
DD. The second value controls what WTOs are issued to the system console. The default is 11.
08-Feb-2018 576/722
XROUTER
(Optional) Indicates whether the XPS SUBMIT ROUTER runs in this CA Workload Automation CA
7® Edition address space. Only one CA Workload Automation CA 7® Edition address space can
function as the XPS Router. If applicable, this XPS Router routes the work to other CA scheduling
solutions. If XROUTER=YES is specified, XSERVER=YES must also be specified to run the XPS Router
in this CA Workload Automation CA 7® Edition address space. NO is the default.
XSERVER
(Optional) Indicates whether this copy of CA Workload Automation CA 7® Edition can act as an
XPS SUBMIT MONITOR and receive cross-platform scheduling requests. NO is the default.
XSERVERTRC
(Optional) Specifies whether to turn on trace for the XPS SUBMIT MONITOR during an
initialization. The default is NO.
XSUBMIT
(Optional) Specifies whether this CA Workload Automation CA 7® Edition can send jobs to
another platform through the XPJOB facilities. The default is YES. If a site codes XSUBMIT=NO,
then any attempts to define CAICCI nodes, XPJOB jobs and other XPJOB-environmental data
return error messages. A bit in the UCC7SVT reflects this state. If XSUBMIT defaults or is coded as
YES, the XPJOB environment is set up as coded with the other variables on the XPDEF statement.
This value is modifiable through the /CHGOPT command as long as this CA Workload Automation
CA 7 Edition is initialized with XSUBMIT=YES. Otherwise, you must stop and restart the CA
Workload Automation CA 7® Edition address space to change from one XPJOB state to the other
(allowing XPJOB job submission).
XTRKTRC
(Optional) Specifies the trace codes to control the level of diagnostic messages and snaps that the
internal TRACKER should generate. You can specify two codes: a print/snap trace code and a
console message trace code. The first value controls what messages are written to the XPRINT DD
and what records and control blocks are written to the XSNAP DD. The second value controls
what WTOs are issued to the system console. The default is 11. These values are the same as used
for the external TRACKER.
Calendars
CA Workload Automation CA 7® Edition uses base calendars to determine available dates for job and
input network scheduling for schedules that are defined on a date/time basis.
The base calendar definitions within CA Workload Automation CA 7® Edition allow for processing
schedule variations. Different types of calendars can be required depending on the type of processing
being done. A small sample of the types of calendars that a user requires when scheduling the
production workload can include the following types:
Fiscal year calendars
Billing calendars
Workday calendars
Payroll calendars
08-Feb-2018 577/722
Payroll calendars
Users can define as many different calendars as necessary, up to a maximum of 1500.
You can generate the calendars using batch or online facilities or automatically with the perpetual
calendars feature.
Online calendar maintenance requires the allocation and identification of a CA Workload Automation
CA 7® Edition calendar PDS.
Note: For more information about maintaining calendars through online facilities, see the
Online Calendar Maintenance panel (DB.2.8).
With perpetual calendars, the online calendar facility is used with a perpetual calendar PDS
(PCALDSN). The perpetual calendar stores the automatically generated calendar into the PDS named
in the CALENDAR,DSN= data set.
Batch-Generated Calendars
The batch generation of base calendars can be accomplished with the CALENDAR macro. The user
must identify all calendars that are required for scheduling the existing environment. The CALENDAR
macro parameter values must then define these calendars. Base calendars are then generated by
assembling and linking the calendar definitions to reflect the format that these parameters specify.
These generated calendars are stored in the CA Workload Automation CA 7® Edition load library or a
user-specified calendar load library that is concatenated to the STEPLIB.
If a CALENDAR statement is not included in the initialization file, a CALBLK statement must be
present. The NAME value on the CALENDAR statement must be the name of the load module that is
linked into the load or Calendar library for this calendar to be available for job scheduling.
The flexibility of the combined calendar/schedule concept allows the user to define calendars,
change calendars, or both well before their actual use. For example, all calendars for use in the
following year can be generated and stored in the load library at any time and then referenced when
required.
CA Workload Automation CA 7® Edition also includes facilities for listing (or displaying) calendars for
review or reference purposes. An actual calendar format is printed reflecting the beginning and
ending points of each month and all scheduled workdays (nonworkdays are removed). Following
each calendar, specified holidays are listed for reference. The following sample is a partial base
calendar assembly listing.
Sample Base Calendar Assembly Listing

****************************************************
** **
** CA-7 BASE CALENDAR SCAL14WD **
** FOR YEAR 2014 **
** DATE 13244 **
** **
****************************************************
08-Feb-2018 578/722

****************************************************
** **
** MONTH 1 JAN **
** **
** SUN MON TUE WED THU FRI SAT **
** **
** (B1) 2 3 4 **
** 7 8 9 10 11 **
** 14 15 16 17 18 **
** 21 22 23 24 25 **
** 28 29 30 (E1) **
** **
****************************************************
****************************************************
** **
** MONTH 2 FEB **
** **
** **
** (B2) **
** 3 4 5 6 7 **
** 10 11 12 13 14 **
** 17 18 19 20 21 **
** 24 25 26 27 (E2) **
** **
****************************************************
****************************************************
** **
** MONTH 3 MAR **
** **
** **
** (B2) **
** 3 4 5 6 7 **
** 10 11 12 13 14 **
** 17 18 19 20 21 **
** 24 25 26 27 28 **
** (E3) **
** **
****************************************************
CALENDAR Macro
Assembling and link editing CALENDAR macros with the user-supplied values generates the base
calendars of a data center. One CALENDAR macro is used to create each module that defines each
base calendar. Calendars are used by the schedule resolution application.
A standard naming convention has been established for referencing base calendars. Adhering to this
format ensures that all calendar names are referenced correctly.
This macro has the following required naming format:

SCALyyxx
SCAL
Is constant.
yy
Must be the year the base calendar is defining.
xx
Specifies two nonblank characters that the user supplies to ensure calendar uniqueness.
For example, SCAL15WD is the name of a base calendar for the year 2015 with the unique characters
08-Feb-2018 579/722
For example, SCAL15WD is the name of a base calendar for the year 2015 with the unique characters
WD (that can identify a weekday calendar).
Before you start the calendar generation process, establish your standards and procedures to control
the assignment of the last two unique characters. This practice ensures consistency and ensures that
duplicate names are not chosen.
Base calendars must be link edited using this standard naming convention (SCAL yyxx).
The CA Workload Automation CA 7® Edition SYSGEN generates some sample calendars.

CALENDAR YEAR=nnnn,SCAL=xx[,CURDATE=yyddd]
[,HOLIDAY={(mmdd-mmdd,...)}]
{(mmdd,mmdd,...)}
{(mmddnnn,mmddnnn,...)}
{(days of week)}
[,MONTHS=(mmdd-mmdd,...,mmdd-mmdd)]
[,NOSCHDY={WEEKDAYS}]
{WEEKENDS}
{(mmdd-mmdd,...)}]
{(mmdd,mmdd,...)}
{(days of week)}
[,OPTIONS=SCHDYONLY]
[,SCHDAYS={ALL}]
{WEEKDAYS}
{WEEKENDS}
{(mmdd-mmdd,...)}]
{(mmdd,mmdd,...)}
{(days of week)}
YEAR
Specifies the year that this base calendar defines. The year supplies the yy segment of the
calendar name. The value is specified as the four numeric characters defining the year (for
example, 2015).
SCAL
Specifies the unique characters that form the xx segments of the calendar name. The value must
be two nonblank characters, either alpha, numeric or both.
CURDATE
(Optional) Specifies the date when this base calendar was assembled. This information is stored in
the calendar record for documentation purposes. The value must be in Julian date form.
HOLIDAY
(Optional) Specifies which days in this calendar are holidays. Designation of holidays by the
HOLIDAY parameter is purely documentary because holidays do not halt production. If a holiday is
not an available processing day, specify the holiday as NOSCHDY. For parameter definitions, see
SCHDAYS.
MONTHS
(Optional) Specifies the beginning and ending days for each of the 12 months (January through
December). The parameter must be used if the calendar being defined has nonstandard months;
for example, a fiscal or accounting calendar. The value must specify the wanted beginning and
ending days of each month as follows.
mm
08-Feb-2018 580/722
mm
Identifies the month number.
dd
Identifies the day of the month.
NOSCHDY
(Optional) Specifies which days of the year not to designate as the available processing days. For
parameter definitions, see SCHDAYS.
OPTIONS
(Optional) Defines calendars being referenced by schedules using relative number of processing
days from the beginning or end of the month to determine processing cycle. The value must be
specified as SCHDYONLY if used. This value causes CA Workload Automation CA 7® Edition to
count only available processing days when resolving a schedule with number of days relative to
the beginning or end of the month. (See the RDAY field on the DB.2.1 panel.) The result of not
specifying OPTIONS=SCHDYONLY is that all days are counted when resolving number of days
relative to the beginning or end of the month.
SCHDAYS
(Optional) Specifies which days of the year to designate as the available processing days.
ALL
Indicates to consider every day as an available processing day. This value is the default.
WEEKDAYS
Indicates only Monday through Friday in each week are available processing days.
WEEKENDS
Indicates that only Saturday and Sunday are available processing days.
mmdd-mmdd,...
Specifies a range of days by month and day.
mmdd,mmdd,...
Specifies individual days by month and day.
mmddnnn,mmddnnn,...
Specifies a start day, by month and day, and several days (nnn) beginning with that day to
consider.
days of week
Specifies one or more of SUN, MON, TUE, WED, THU, FRI, or SAT.
Coding Notes
Consider the following items when you code your calendars:
Start the macro name CALENDAR in column 10. You must have at least one blank between the
macro name and the first parameter.
08-Feb-2018 581/722
A nonblank character in column 72 indicates continuation of the CALENDAR macro statement.

Macro parameters and values can be coded through column 71 with no blanks. All continuation
statements must begin in column 16. Keyword values can be broken for continuation at a comma.
This method is a standard assembler continuation.
The CALENDAR macro parameters are keyword type and nonpositional. They can be specified in
any order.
If coding nonstandard months (fiscal year), a year-end boundary can only be crossed in the first or
twelfth month. That is, the first month can begin in December, January, or February. The last
month can end in November, December, or January, but it must not start in January. Also, 12
months must be specified.
If the beginning day for a month is more than one month greater than the beginning day coded
for the previous month, the assembly of the calendar does not show the ending day for the
previous month.
For example, if MONTHS=(0101-0301,0302-0401,...) the assembly shows a (B1) for January 1, a
(B2) for March 2, but the (E1) for March 1 does not appear on the calendar from the assembly.
Perpetual Calendars
The perpetual calendars are designed for use as calendars where the scheduling days are consistent
from year to year. For example, a consistent schedule has weekdays always as schedule days and
weekends as nonprocessing days. In this case, you set up perpetual calendar criteria stating that
weekends are nonscheduled. If all federal holidays are nonprocessing days in several of your base
calendars, you would include a reference to a member. The member defines federal holidays as
nonschedule days in each of those calendar criteria members.
The perpetual calendars have no commands specifically for them. However, when a CA Workload
Automation CA 7® Edition command is issued that references a nonexistent base calendar, the
existence of a perpetual calendar causes the building of that base calendar. The building requires
criteria for that calendar has been properly specified.
Note: Online access to base calendars is a prerequisite for using perpetual calendars.
Online access is defined with the DSN parameter on the CALENDAR initialization file
statement.
If a base calendar is not in the CALENDAR DSN, an attempt is made to load the calendar from a load
module created from assembling and link editing the CALENDAR macros. If no load module is
present, the PCALDSN is examined to see whether a perpetual calendar criteria member exists for
that base calendar suffix. If PCALDSN has no corresponding member, any CA Workload Automation
CA 7® Edition command issues the same error message as in past releases. If a PCALDSN member
exists for that base calendar, that base calendar is generated using the criteria in the PCALDSN
member and saved in the CALENDAR DSN. After the base calendar is generated, it is available to any
other process in CA Workload Automation CA 7® Edition. The calendar is not generated again unless
specific action is taken.
When building criteria for the first time, we recommend using the PRINT command to verify that the
08-Feb-2018 582/722
When building criteria for the first time, we recommend using the PRINT command to verify that the
calendar is being built to your specifications. If any modifications to the criteria are necessary, you
have two choices:
Rebuild the calendar from the REFRESH function of the CALMOD command.
Delete the existing calendar from the CALENDAR DSN with the DELETE function of the CALMOD
command.
Note: If an assembled and link-edited calendar is found, it is always used instead of the
calendar found in the CALENDAR DSN. The perpetual calendars do not override batch-
generated calendars.
After the perpetual calendar criteria is built and verified, base calendars for that suffix are
automatically generated, every following year, the first time that calendar is referenced for that year.
Note: For more information about calendars and scheduling, see Database Maintenance (
https://wiki.ca.com/display/CWAC7E/Database+Maintenance).
Perpetual Calendar Requirements

To use perpetual calendars, define and list a partitioned data set (PDS) on the PCALDSN parameter of
the CALENDAR statement in the initialization file. This data set contains members named PCALYY xx,
where xx creates the SCALyyxx members in the CALENDAR DSN. The yy portion of the SCALyyxx is the
year for which this calendar was generated.
Members in the PCALDSN not conforming to the PCALYYxx standard can contain calendar criteria.
The PCALYYxx members using the INCLUDE verb can reference criteria in these members.
Perpetual Calendar Criteria

Base calendars are automatically built from perpetual calendar criteria and stored in the CALENDAR
DSN. The criteria are a series of statements in PDS members. The perpetual calendar PDS has a
record length of 80. Columns 1 through 71 are used to define the criteria statements. Columns 72
through 80 are ignored and can be used for sequence numbers if desired. The criteria statements are
coded one statement per line, and there is no continuation. Criteria are not case-sensitive. The
statements are processed sequentially, so if you encounter conflicting instructions, the last statement
is honored. For example, if a criteria statement was:
Set Jan 17 unschedule
And a later statement was:

set third Monday in January schedule
In 2015, the third Monday in January was the 19th. Therefore, in that year, January 19 is a schedule
day.
08-Feb-2018 583/722
By default, all perpetual calendars start with every day of the year that is defined as a schedule day.
Thereafter, you can write criteria to list nonscheduled days. If it is easier to list the days to schedule,
use the following criteria statement:
set all days nonscheduled
By default, the beginning of each month is the first, and the end of the month is the last day of the
month. The CHANGE verb can modify these values. By default, SCHONLY is set to 'N' (off). The
CHANGE verb can also change this setting.
Any statement with a # or * in column 1 is considered a comment. Other than comments, criteria
statements are not required to begin in column 1. Most keywords, such as month names, days of the
week, and verbs can be abbreviated to three characters. An exception to this abbreviation is the
keywords following the CHANGE command. They can be abbreviated to a minimum of six characters.
Generally, extra spaces are ignored. The exception to the extra space exemption is in DEFINE terms.
To match, use a term exactly as it was defined.
Verbs
The first word in a criteria statement must be a verb. The four criteria verbs are: SET, INCLUDE,
DEFINE, CHANGE. These verbs are not case-sensitive.
SET
SET specifies whether a date, date range, date sequence, or set of dates is scheduled, nonscheduled,
or a holiday.
The SET verb has the following format:

SET date-phrase action
date-phrase
Specifies one of the following date-phrases:
ALL
Perform the action on all days of the year.
Valid actions: SCHEDULE and NONSCHEDULE/UNSCHEDULE.
WEEKENDS
Perform the action on all weekends (Saturdays, Sundays) of the year. Perform the opposite
action on all weekdays (Monday through Friday) of the year. For example, if the action is
schedule, schedule all weekends and unschedule all weekdays.
WEEKDAYS
Perform the action on all weekdays (Monday through Friday) of the year. Perform the
opposite action on all weekends (Saturdays and Sundays) of the year. For example, if the
action is schedule, schedule all weekdays and unschedule all weekends.
HOLIDAYS
Perform the action on all holidays that have been previously defined using a SET HOLIDAY
command. Holidays that are defined after this command are not affected.
08-Feb-2018 584/722
date-expression
Specifies a single date in one of the following formats.
Valid actions: SCHEDULE, NONSCHEDULE/UNSCHEDULE, HOLIDAY.
mm/dd
month-name dd or dd month-name (for example, march 10 or 10 march)

Month names can be fully spelled out or abbreviated to a minimum of three letters, for
example, APR or AUG.
ordinal-number day-of-week (IN/OF) month-name (for example, second tuesday of march)

Ordinal number can be FIRST, SECOND, THIRD, FOURTH, FIFTH, LAST, 1st, 2nd, 3rd, 4th, 5th
Day-of-week (described later.)
Month name is as described in a previous bullet.
EASTER
date-expression-1 TO date-expression-2
Perform the action on the range of dates, beginning with date-expression-1 and ending with
date-expression-2. Date-expression-1 and date-expression-2 must specify a single date as
described previously under date-expression. Date-expression-2 must be greater than date-
expression-1.
date-expression FOR nnn

Perform the action on the date sequence beginning with date-expression and continuing in a
calendar date sequence until a total of nnn days are processed. Date-expression must specify
a single date as described previously under date-expression. The date sequence cannot go
past 12/31.
day-of-week (day-of-week...)
Perform the action on the specified days of the week for every week of the year. You can
specify one or more of SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY,
SATURDAY. You can use the plural forms, such as MONDAYS. You can also abbreviate the
names to a minimum of three letters such as: SUN THU FRI.
action
Specifies one of the following actions:
SCHEDULE
Mark the days as available for processing.
NONSCHEDULE/UNSCHEDULE
Mark the days as unavailable for processing.
HOLIDAY
Mark the days as holidays. This action is purely documentary. If you want to mark holidays
available or unavailable as processing days, see the HOLIDAYS date phrase.
Notes for SET
By default, all calendars days are marked as available for processing.
08-Feb-2018 585/722
By default, all calendars days are marked as available for processing.
The criteria members are not case-sensitive. You can use lowercase or uppercase or a mixture.
The SET statements are processed in the order that they appear in the criteria member. If a date
phrase references dates that are marked as available or unavailable by a previous SET statement, the
new action overrides the previous settings. For this reason, place date phrases that process all dates
(that is, ALL, WEEKENDS, WEEKDAYS), if coded, first in your criteria member.
A SET HOLIDAYS SCHEDULE|NONSCHEDULE|UNSCHEDULE statement marks all previously defined

holidays as available or unavailable for processing. The holidays that are defined after this statement
is processed are not marked available or unavailable and are purely documentary.
INCLUDE
INCLUDE transfers processing of a criteria member to another member in the PCALDSN. All criteria in
the included member is processed. Processing continues with the next statement following the
INCLUDE statement. The included members can also contain INCLUDE statements. However, no
INCLUDE statement can reference a member that is in process, or an error is returned, and calendar
generation is aborted.
The INCLUDE verb has the following format:

INCLUDE member
member
Name of a member in the DSN specified for PCALDSN on the CALENDAR statement. member does
not have to conform to the PCALYYxx format for use on an INCLUDE.
DEFINE
DEFINE substitutes one phrase for another. SPECIFY is a synonym for DEFINE.
The DEFINE verb has the following format:

DEFINE phrase AS substitution
phrase
All characters from the first nonblank character after the DEFINE to the last nonblank character
before the AS. The phrase cannot contain any of the following reserved words or abbreviations of
these reserved words. Abbreviations have a minimum of three characters, except for the CHANGE
verb keywords which have a minimum of six characters.
Day of week (Sundays through Saturdays)
Month name (January through December)
Ordinals (FIRST through FIFTH, LAST, 1ST through 5th)
Verbs or their synonyms (CHANGE, DEFINE, INCLUDE, MODIFY, SET, SPECIFY)
CHANGE verb keywords (MONTHBEGIN, MONTHEND, SCHONLY, SCHDYONLY)
08-Feb-2018 586/722
Other (ALL, EASTER, FOR, HOLIDAYS, IN, N, NO, OF, OFF, ON, TO, WEEKDAYS, WEEKENDS, Y,
YES)
substitution
First nonblank character after the AS to the last nonblank character of the criteria statement. The
substitution must be one of the following values:
date expression
date expression TO date-expression
date expression FOR nnn
day-of-week (day-of-week…)
Before each criteria statement is interpreted, it is scanned for defined phrases. When one is
encountered, the phrase is replaced with the substitution.
This substitution is useful in designating certain days or periods. For example:

DEFINE Thanksgiving AS 4th Thursday in November
or:
DEFINE company downtime AS third Mon in June TO last Fri in June
These statements could be placed in a member in the PCALDSN, and included in other PCALYY xx
members. After these statements are processed, the following statements are valid:
SET Thanksgiving Holiday
SET company downtime unscheduled
CHANGE
CHANGE modifies attributes of the base calendar or modifies the options that control calendar
generation. MODIFY is a synonym for CHANGE.
The CHANGE verb has the following format:

CHANGE changekeyword keywordoption
The following changekeyword and the associated keywordoption are valid:
MONTHBEGIN
Sets the month begin date.
month-name MM/DD
Sets a month begin date for month month-name to date MM/DD.
MM MM/DD
Sets a month begin date for month MM to date MM/DD.
MONTHEND
Sets the month end date.
month-name MM/DD
08-Feb-2018 587/722
month-name MM/DD
Sets a month end date for month month-name to date MM/DD.
MM MM/DD
Sets a month end date for month MM to date MM/DD.
SCHONLY|SCHDYONLY
Sets the number of days to count.
N|OFF
Counts all days when calculating days relative to the beginning or end of the month.
Y|ON
Counts only available processing days when calculating days relative to the beginning or end
of the month.
Example:
CHANGE MONTHBEGIN FEB 02/03
CHANGE MONTHEND 09 09/29
CHANGE SCHONLY N
MODIFY SCHDYONLY ON
Perpetual Calendar Criteria Member Samples

Example: Mark weekdays as available, weekends unavailable
Perpetual Calendar for weekdays only

set weekdays schedule
Example: Mark Mondays, Wednesdays, and Fridays as available, all others unavailable
Perpetual Calendar for Mondays, Wednesdays, and Fridays

set all nonschedule
set mon wed fri schedule
Example: Mark weekends and second Monday of each month as unavailable, all other available
Perpetual Calendar for weekends and second Monday of each month as unavailable.
set weekends nonschedule
set second Monday of January nonschedule
set second Monday of February nonschedule
set second Monday of March nonschedule
set second Monday of April nonschedule
set second Monday of May nonschedule
set second Monday of June nonschedule
set second Monday of July nonschedule
set second Monday of August nonschedule
set second Monday of September nonschedule
set second Monday of October nonschedule
set second Monday of November nonschedule
set second Monday of December nonschedule
Example: Mark various date ranges and date sequences as available, all others unavailable
Perpetual Calendar for various date ranges and sequences
08-Feb-2018 588/722
set all nonschedule
set 03/12 to 03/20 schedule
set third friday in july for 10 schedule
set 08/19 to first monday in september schedule
set 12/01 for 24 days schedule
Example: Include member for US National holidays, member name=USFEDHOL
Perpetual Calendar for U.S. Federal holidays

DEFINE New Year's Day AS Jan 1
set New Year's Day holiday
DEFINE Martin Luther King's birthday AS third Monday in January
set Martin Luther King's birthday holiday
DEFINE Washington's birthday AS 3rd Mon in Feb
set Washington's birthday holiday
DEFINE Memorial day AS last Monday in May
set Memorial day holiday
DEFINE Independence Day AS July 4
set Independence Day holiday
DEFINE Labor day AS first Monday in Sept
set Labor day holiday
DEFINE Columbus Day AS 2nd Mon in October
set Columbus Day holiday
DEFINE Veteran's Day AS 11/11
set Veteran's Day holiday
DEFINE Thanksgiving Day AS 4th Thurs in November
set Thanksgiving Day holiday
DEFINE Christmas AS 25 December
set Christmas holiday
Example: Mark weekends and US National holidays as unavailable, all others available
Perpetual Calendar for weekdays minus holidays

set weekends nonschedule
include usfedhol
set holidays nonschedule
CA Datacom/AD Database Backup, Recovery, and

Tuning
Design backup and recovery procedures as you implement the CA Workload Automation CA 7®
Edition database. Remember that when multiple logical databases are contained in one CA Datacom
/AD MUF, backup, recovery, and tuning are performed for all logical databases simultaneously.
Consider this important fact when designing backup and recovery procedures.
With the CA Datacom/AD database, the backup includes both the definitions and active workload on
one backup file. Recovery depends on the type of backup that was taken.
All database functions are done with the database utility DBUTLTY. DBUTLTY is documented in the CA
Datacom/DB Database for z/OS DBUTLTY documentation.
08-Feb-2018 589/722
Backup Options
With the CA Datacom/AD database, the backup includes the definitions and active workload on one
backup file. In addition, when multiple CA Workload Automation CA 7® Edition logical databases are
contained in one CA Datacom/AD MUF, a backup backs up all the logical databases simultaneously on
one backup file.
Back up the data in the database periodically. Each installation determines what periodically means,
based on the number of changes to the scheduling database and disaster recovery plans.
For example, some installations make few changes to the scheduling definitions. These installations
always plan to start with an empty active workload during disaster recovery. Other installations make
many daily changes to the scheduling definitions. They plan on disaster recovery continuing from the
point of failure. The type of backup that is needed differs based on why it is being taken.
Stable Backup
Use the CA Datacom/AD utility DBUTLTY for backing up the database. This utility is fast and backs up
all the data in the physical database, regardless of how many logical databases (CA 7 instances) are
present. This backup requires that you shut down all the connected CA 7 online instances. This stable
backup contains both the definition and the active workload data for all CA 7 instances that are
contained within the MUF.
The simplest type of database backup is provided in CAL2JCL member AL2DBKUP. This job backs up
all the records in the database in key (native) sequence. You can restore the resulting backup to the
same physical database. Alternately, you can recreate the database as larger (or smaller) or on a
different device.
Because this stable backup requires exclusive access to the data, shut down all CA 7 instances. This
shutdown ensures the integrity of the data. Once the backup has completed, you can restart all the
CA 7 instances. Consider timing this stable backup at an orderly shutdown or startup of the operating
system like immediately before or after a planned IPL.
The stable backups are good for sites who make few updates to the database, or who are not
concerned with recovering data to the point of failure. For example, some sites, as part of their
disaster recovery plans, take weekly stable backups of the data. At the disaster recovery site, the data
is restored using the database DBUTLTY LOAD function (See CAL2JCL member AL2DLOAD).
Hot Backup
Note: Only use hot backup if the CA Datacom/AD option LOGRCV is set to NO as indicated
in the Installation topics and recovery files are being generated as discussed in LXX Spilling.
Recovery files are required to restore a database from a hot backup.
08-Feb-2018 590/722
Many sites either do not want to stop production for a backup or want a more up to the minute
recovery. These sites can use the database backup-while-open, or hot backup, capability to obtain
valid backups of the CA Workload Automation CA 7 Edition data. This backup can occur while CA
Workload Automation CA 7 Edition is up and users are changing the database.
The example for this type of database backup is provided in CAL2JCL member AL2DBHOT. We
recommend that sites implementing the Hot Backup schedule AL2DBHOT to run nightly, preferably
during a period of low CA Workload Automation CA 7 Edition activity.
Note: The LOCK and UNLOCK commands in the AL2DBHOT are required because the
database compression is in use.
Restore the hot backup data using the DBUTLTY LOAD function like the stable backup. To return to
the point of failure, perform the CA Datacom/AD forward recovery process before starting CA
Warning! The backup of the database by a hot backup does not represent a stable system
state. Restore the database from the backup and perform forward recovery before using it.
See the next article.
Many installations discover that they need both of these backups:
An occasional stable backup for disaster recovery.
A daily hot backup with forward recovery to protect against any DASD problems.
Reorganize Your Database

Database reorganization serves two purposes:
Improve performance
Recover URIs (unique row identifiers)
Reorganizations in the database are helpful when the application performs certain types of
sequential processing, which CA 7 does. However, the CA 7 installation instructions recommend
covering the database, which significantly reduces the impact of reorganizing the database. If our
recommendations are followed, reorganizing the database has little effect on performance. However,
we do provide a sample CAL2JCL member, AL2DBORG, to perform reorganizations when one
becomes necessary. AL2DBORG can run while CA 7 instances remain active, but during periods of a
low production workload.
08-Feb-2018 591/722
Creating a stable backup (SEQ=NATIVE) and then immediately reloading from that file is an
alternative method of reorganization. This method requires that all CA 7 instances using the MUF are
inactive. This method recovers URIs (unique row identifiers) for reuse.
Tune Your Database

To keep performance at an optimum level, it is important to tune the database to provide its best
performance. To achieve the best possible results, we recommend that you modify some of the CA
Datacom/AD install default settings.
The CA Datacom/DB Memory Resident Data Facility (MRDF) lets you specify data areas and index
areas to be stored in storage. We recommend that you take advantage of this feature. MRDF
COVERED and VIRTUAL allocations are from 64-bit memory. Every allocation is rounded up to the
next multiple of a megabyte.
Two SQL queries are provided in the CAL2JCL library. AL2DBTN1 and AL2DBTN2 read the Dynamic
System Tables to assist you allocating the MRDF assigned storage between the areas that give the
most impact. Also, see the MRDF Summary Information in the MUF shutdown report for statistics on
the MRDF usage.
Note: For more information about the MUF EOJ report, see the System Tables Reference (
https://docops.ca.com/display/DATACOM150/System+Tables+Reference) topics in the CA
Datacom®/DB documentation..
For example, consider making the following assignments as a first estimate.

VIRTUAL IXX006,10M
VIRTUAL IXX017,2M
VIRTUAL TTM017,50M
*
COVERED 0015
*
COVERED IXX0770,115%
COVERED MIN0770,100%
COVERED DFS0770,115%
COVERED JOB0770,115%
COVERED AWS0770,115%
COVERED AWL0770,115%
COVERED AWH0770,115%
COVERED HIS0770,115%
COVERED HIL0770,115%
Let the system execute long enough to capture data representative of your processing load. You can
execute the queries in AL2DBTN1 and AL2DBTN2 to report the MRDF efficiency. Adjust the MRDF
allocations to provide the most impact for the resource levels you decide.
Note: If you need assistance setting database values, contact CA Datacom/AD Technical
Support (and not CA 7).
08-Feb-2018 592/722
The CA Datacom/AD installation sets the SMPTASK value to run in SRB mode. We recommend that
this setting is kept. SRB mode lets the database exploit zIIP processors when available.
Note: For more information about the SMPTASK parameter and zIIP processors, see the CA
Datacom/DB Database and Systems Administration (https://docops.ca.com/pages/viewpage.
action?pageId=301818674) articles.
Dynamic Extend
The database is defined using the Dynamic Extend feature. This feature causes the index and data
areas to extend up to 15 times per volume automatically when filled. If the data sets are defined into
a DFSMS storage group, the extents can be to any volume in that group.
The DYNAMIC_EXTEND console command can override the defined dynamic extend size and trigger
an immediate extension.
Note: For more information about extending data areas, see the CA Datacom/DB Database
and System documentation.
CAL2JCL sample JCL member AL2DXTND is an example of using DBUTLTY to add more volumes to a
single area.
Although single extents for the areas are more efficient, the dynamic extend feature permits
temporarily extending the allocation until a maintenance window can be performed. At a convenient
window, reset the areas to be a single extent using CAL2JCL member AL2DCC40.
CA 7 generates CAL2SM00I WTO messages at startup and each day at midnight. The messages show
the percentage that is used of the current allocation for each data area. You can also issue the
/DISPLAY,PERF=DATACOM CA 7 command to see the current allocation usage. The reported
percentage is from the current allocation only. If CA Datacom/AD can obtain another extent, the full
percentage can later decrease. You can use this information with monitoring the number of extents
that are allocated to the data set of a data area. The information can help determine whether you
want to schedule a maintenance window to change allocation of a data area using CAL2JCL member
AL2DCC40.
Index Defragmentation
A defragmentation makes the CA Datacom/AD index function more efficiently and reclaims space in
the index. The sample CAL2JCL member AL2DBFRG can be used to perform online defragmentations
while the CA 7 instances remain active. We recommend that you do not run defrag during high
processing periods of the production workload.
Include defragmentation in your database maintenance procedures. We recommend that you start
08-Feb-2018 593/722
Include defragmentation in your database maintenance procedures. We recommend that you start
by running defrag daily. Next, adjust how often you schedule defragmentation based on the
percentage recovered. Use the following guidelines to adjust the defrag frequency:
< 10 percent recovery, schedule AL2DBFRG less frequently
10-25 percent recovery, leave AL2DBFRG schedule as is
> 25 percent recovery, schedule AL2DBFRG more frequently
Logging
To support transaction back out and database recovery, CA Datacom®/AD records information about
table updates in its Log Area (LXX). The LXX is a fixed-sized file that is written to in a wraparound
fashion.
When all the table updates in an LXX block have been committed, the block becomes spillable.
Spillable means that the block is no longer needed for a transaction back out. The block can be
written to the recovery file (RXX). After an LXX block has been spilled, it can be overwritten with new
log data.
During the CA 7 installation, the LOGRCV setting was set to LOGRCV NO. This setting means that no
dedicated tape drive is reserved for CA Datacom/AD to use for automatically spilling blocks from the
Log Area (LXX) to the recovery file (RXX). Instead, run a SPILL job periodically to write spillable LXX
blocks to the recovery file. After the LXX blocks are written to the recovery file, they are available for
reuse. This process is referred to as inactive recovery.
You must spill the LXX often enough to ensure that space is always available to record new update
information. If the LXX becomes full, all CA 7 activity stops until a SPILL job is run to free up blocks for
reuse.
LXX Spilling (see page 594)

LXX Sizing (see page 595)
Database Resizing (see page 595)
LXX Spilling
How often you must run the SPILL job to ensure that the LXX never fills up depends on:
The size of the LXX file
The number of updates that are performed against the CA Datacom/AD database
CA Datacom/AD generates a notification message when the Log Area reaches a specified percentage
full. Establish automation procedures to submit a SPILL job when the Datacom notification message is
detected. See the CA Datacom/DB Database and System Administrator documentation: Operating
with Logging Active, Processing With an Inactive Recovery File, Approaching a Log Full Condition for
information about specifying the percentage full threshold and the notification message that CA
Datacom/AD issues.
08-Feb-2018 594/722
Warning! If the LXX becomes full, all CA 7 activity stops until you run a SPILL job to free up
blocks for reuse. CA 7 cannot always submit a SPILL job when the LXX file is full. Have the
automation procedure use a different submission method for the SPILL job.
See the following CAL2JCL members for assistance in setting up the definitions and running the SPILL:
AL2DCA80 defines the generation data groups for the backup and spill files
AL2DBSPL contains the JCL for a SPILL job
LXX Sizing
The size of the LXX size affects how often recovery files are created and the probability that “forced
checkpoints” occur.
If the LXX is too small, the file can become full with no blocks eligible for spilling. In this case, CA
Datacom/AD forces a transaction checkpoint to make blocks in the LXX spillable. Forced checkpoints
are not desirable because they can adversely affect a transaction back out.
We recommend that you start with a large LXX allocation. After you have completed the conversion
and begun normal processing, balance the LXX size and SPILL frequency. Find a balance where you
are creating RXX files at the frequency you want and are not seeing forced checkpoints. We suggest
creating no more than 4-6 RXX files per day.
See the CA Datacom/DB Database and System documentation: Operating with Logging Active,
Processing With an Inactive Recovery File, Log Area Full for information about determining whether
forced checkpoints are occurring in your MUF.
CAL2JCL sample member AL2DBLXX can be used initialize a new LXX file. When resizing the LXX, stop
all tasks accessing the MUF. Run a log SPILL job. Next, perform a normal EOJ of the MUF. The MUF
must be down when submitting the AL2DBLXX job.
Database Resizing
Sample JCL in CAL2JCL member AL2DCC40 helps you resize any of the database data areas that
require a larger allocation. All CA Workload Automation CA 7® Edition systems using the same MUF
must be down for a successful resize operation. CAL2JCL member AL2DBSPC is an example that runs a
DBUTLTY report of space usage.
Recover Unique Row Identifiers

CA Datacom®/AD assigns each row in a CA 7 data area a unique row identifier (URI). The URI makes
the data independent of its physical location. When a row is deleted from an area, the URI number
does not become available for reuse until a backup and reload reorganize the area. Online
reorganization does not recover URIs for reuse.
Sample CAL2JCL members AL2DBKUP and AL2DLOAD can be used to backup and reload the database.
08-Feb-2018 595/722
The maximum URI number is 4 billion (4G). When this limit is reached, CA 7 cannot add new rows to
the area until it is reorganized. CA Datacom®/AD issues message DB2801W when the maximum URI
number in an area reaches 3G. Set up automation to monitor for this message so that you can
schedule a reorg at a convenient time before the URI reaches the 4G maximum.
Note: CA Datacom®/AD Release 15.0 includes a URI reuse option. CA 7 data areas are not
currently defined with this attribute. URIs are not reused in CA 7 data areas even when
using CA Datacom release 15.0.
Execute a Forward Recovery
Warning! If you are performing a recovery action on the CA Datacom/AD database, open a
severity 1 issue with the CA Datacom/AD support team so that they can help with the
recovery operations.
Forward recovery uses recovery files, which are sequential files (usually a GDG on either tape or disk)
containing log records. The recovery files are also referred to as RXX files. Each log file record is a
specific change that was made to a database record. Log file records are created for every database
add, update, and delete and are written to the log (LXX) file.
If a forward recovery is necessary, follow these steps:
1. Open a Severity 1 Issue with the CA Datacom/AD support team so that they can assist with
Steps 2 through 4.
2. Start your CA Datacom/AD MUF. Run your site’s SPILL job (AL2DBSPL) to create your most
recent RXX GDG.
3. Restore the database from the most recent backup using the CAL2JCL member AL2DLOAD.
This job executes the DBUTLTY LOAD function. The output from this job tells you when the
backup you loaded was taken.
4. Use CAL2JCL member AL2DBREC as a sample job to process the recovery files. Remember that
you must process all the recovery files that are created after the physical backup in the order
in which they were created (time sequence) as shown in the example. The most recent
recovery file (-0) has been created in the preceding Step 2.
Note: Do not use the GDG family name in the recovery JCL. Code the individual DD
statements starting with the oldest generation as the first DD processed. For example:
08-Feb-2018 596/722
//RXX DD DISP=SHR,
// DSN=your.datacom.hlq.RXX(-2) **** OLDEST GDG coded 1st
// DD DISP=SHR,
// DSN=your.datacom.hlq.RXX(-1) **** Then next oldest GDG
// DD DISP=SHR,
// DSN=your.datacom.hlq.RXX(-0) **** and keep coding until current
Note: For more information about the batch DBUTLTY functions, such as BACKUP, LOAD,
and LOCK/UNLOCK, see the CA Datacom/DB Database for z/OS DBUTLTY Reference (
https://docops.ca.com/display/CDATVSE120/Reference) articles.
Shadow MUF Feature

Implement the Shadow MUF feature of the database to facilitate a failover.
Sometimes, a failure of the full CA Datacom MUF or some other unplanned outage occurs. One of the
best ways to minimize any loss of data access is to implement the Shadow MUF feature. Use of a
Shadow MUF environment also prevents loss of access to data during planned or unplanned outages.
You can only have one Shadow MUF per primary MUF within the sysplex. A Shadow MUF is a nearly
identical MUF job or started task that is running on usually a different LPAR within the z/OS sysplex.
Its sole purpose is to extend the ability for the MUF to be available 24 hours a day, 7 days a week.
Functionally, the Shadow MUF is waiting in stand-by mode (in the shadows). The Shadow MUF is
ready to take over the CA Datacom/AD processing in the following circumstances:
The Primary MUF is shut down.
The Primary MUF goes down due to any unforeseen or unrecoverable error.
For example, assume the following situation:
MUFA is running on LPAR A.
The shadow MUF (MUFB) is running on LPAR B.
You can issue a MIGRATE_TO_SHADOW console command. This command issues an EOJ to the
primary MUF (MUFA) preventing new connections. The Shadow MUF (MUFB) is then activated for
new connections. Each of the CA Workload Automation CA 7® Edition regions detects the change and
reconnects to the now active shadow. This process can give you a smooth transition to MUFB thus
preparing you to IPL LPAR A.
Implement the Shadow MUF

The primary MUF and the Shadow MUF must have different MUF names. An * specified as the MUF
name is required when running in a Shadow MUF environment:
MUF *,99,NO
Both the primary MUF and the Shadow MUF must belong to the same MUFPLEX. To accomplish this
combination, specify the MUFPLEX startup parameter. For example:
08-Feb-2018 597/722
MUFPLEX name,*,,nnnn,S
name
Indicates the name of the MUFPLEX.
*
Indicates the number of the MUF. (The * is required for a Shadow MUF environment).
,,
Indicates that the locks value is omitted.
nnnn
Indicates the maximum tasks value. The value is the most each Multi-User Facility within an
enabled MUFPLEX is permitted.
S
Indicates the mode of operation. S is required for a Shadow MUF environment.
The JCL for executing the MUF must not have any DD statements with DISP=OLD. The first MUF that
is started is the Primary MUF. The second MUF that is started is the Shadow MUF.
Note: For more information about the Shadow MUF environment, see the CA Datacom®
/DB Database and Systems Administration documentation and product information
bulletins RI06032 and RI40632.
Shadow MUF and Dormant Copy

Run the Shadow MUF on the same system where a dormant copy of CA Workload Automation CA 7®
Edition executes, although you can have it on any system within the MUFPLEX or sysplex. This
method retrieves the data using cross-memory services instead of cross-system services.
Recover an Unresponsive Terminal

This article contains suggestions for recovering from unresponsive or "hung" terminals connected to
CA Workload Automation CA 7® Edition.
The following steps and their associated commands are only for terminals that have encountered an
error and are later "hung." A terminal with a CA Workload Automation CA 7® Edition command in
process cannot be interrupted. Interruptions can result in CA Workload Automation CA 7® Edition
abending.
Recover VTAM Terminals

Follow these steps:
1. Find another terminal that is defined to CA Workload Automation CA 7® Edition and log in.
08-Feb-2018 598/722
2. Enter /STOP,T=termname
termname
Name of the hung terminal as it is defined in the initialization file, the TERM statement,
NAME parameter.
3. Enter /START,T=termname
termname
Same terminal name that is used in Step 2.
If the terminal remains hung, try the following actions:
1. Enter /STOP,T=termname
termname
Name of the hung terminal as it appears in the initialization file, the TERM statement,
NAME parameter.
2. Enter /CLOSE,T=termname
/CLOSE disconnects the terminal from CA Workload Automation CA 7® Edition. If the terminal
name is not specified, the terminal issuing the command is disconnected from CA Workload
Automation CA 7® Edition. The operator has to reconnect and log in again.
termname
Same terminal name that is used in Step 1.
3. Enter /PURGPG,LT=termname
termname Same terminal name that is used in Step 1.
4. Enter /OPEN,T=termname
5. Enter /START,T=termname
Note: The commands listed in the steps can be issued through a batch terminal.
After Step 3 (/PURGPG), the terminal sometimes requires that you issue a vary active through
VTAM.
If the suggested steps have been tried and the terminal is still hung, then shut down and
reinitialize CA Workload Automation CA 7® Edition.
08-Feb-2018 599/722
If VTAM is down and CA Workload Automation CA 7® Edition is up, the product can be shut down and
restarted after VTAM has been restored. Or after VTAM has been reinstated, the following suggested
steps can be used. The commands in these steps can be issued from a batch terminal or from the
system console when the console is defined and opened to CA Workload Automation CA 7® Edition.
That is, CA Workload Automation CA 7® Edition has an outstanding WTOR.
1. Enter /CLOSE,GROUP=groupname
groupname
Name of the first group of VTAM terminals defined to CA Workload Automation CA 7®
Edition in the initialization file. This command disconnects all VTAM terminals from CA
2. Enter /OPEN,GROUP=groupname
groupname
Same name specified in Step 1. This command reconnects CA Workload Automation CA 7®
Edition to VTAM.
Recover Batch Terminals

The only way to recover a batch terminal is to shut down CA Workload Automation CA 7® Edition,
cancel any batch terminal interface programs, and restart CA Workload Automation CA 7® Edition.
Any attempt to recover a batch terminal currently in use can result in an abend of CA Workload
Automation CA 7® Edition.
Never cancel batch terminal interface jobs when CA Workload Automation CA 7® Edition is active.
Canceling a BTI job does not prevent CA Workload Automation CA 7® Edition from processing the
commands.
Back up and Reload Agent Data

Because the agent data (information) file, allocated using the CA7AGNT DD statement in CA7ONL, is a
VSAM KSDS, you can use several utilities for backup and reload. Two procedures using IDCAMS are
provided as part of the installation process and reside on the CA Workload Automation CA 7® Edition
JCL library. However, use of these procedures is not required. If you prefer, you can use alternatives
to IDCAMS like CA ASM2® and DFDSS.
Note: This file is periodically cleaned by using the /DELAGNT command. This command
removes old job entries. Execute the command periodically. As a result, schedule a
reorganization (backup and reload) function when the CA 7 Online system is brought down
for maintenance.
08-Feb-2018 600/722
Agent Data Backup Procedure - CA7AGBK

The agent data backup procedure, CA7AGBK, is an execution of IDCAMS. CA7AGBK backs up the
contents of the agent data file to tape. This member is found in the CA 7 JCLLIB library. The JCL to
execute this job, also in the JCLLIB library, is CA07N513. The prefix CA07 is sometimes changed.
The DD statement descriptions are as follows:
INPUT
Specifies the CA Workload Automation CA 7® Edition Agent File component.
OUTPUT
Identifies the sequential backup file.
SYSPRINT
Used for message output.
SYSIN
Refers to member REPRO in the JCLLIB library containing IDCAMS control statements.
Agent Data Reload Procedure - CA7AGRL

The agent data reload procedure CA7AGRL is an execution of IDCAMS to reload. CA7AGRL causes the
agent data file to be deleted, redefined, and loaded from a tape created by the backup procedure.
This procedure is found in the CA 7 JCLLIB library. Also in the same library is member CA07N514,
which executes the procedure CA7AGRL. The prefix CA07 is sometimes changed.
The DD statement descriptions are as follows:
INPUT
Specifies the sequential file that the backup job created.
OUTPUT
Specifies the CA Workload Automation CA 7® Edition agent data file.
SYSPRINT
Used for message output.
SYSIN
Points to the following members in the JCLLIB library:
AGTDEL
Contains IDCAMS control statements to delete the agent data file.
AGTALLOC
Contains IDCAMS control statements to allocate the agent data file.
REPRO
Contains IDCAMS control statements to reload the agent data file with data from the backup
file.
08-Feb-2018 601/722
Agent Data Reload Usage

Each agent job (AGJOB) that executes has feedback information that the CA Workload Automation
Agent returned. The minimal amount of data that is written to this file is the following items:
The last status that is recorded for the job
A record containing the job number that the agent assigned
The destination information (host and agent)
More data can be associated with the agent job feedback data, such as intervention messages,
variable, and external data. If the agent data backup occurred and then other agent jobs were
executed before the reload executes, the agent job data is not always present in the file. This
situation is a problem only when some intervention is required for a message outstanding or the data
is needed for future reference.
Agent Data Set IDCAMS Define Parameters

The IDCAMS parameters that define the agent data file are described here for the agent data set
component:
RECORDSIZE(400 32700)
This parameter determines the record length in the data set. Do not change these values.
SHR(2 3)
Share options specify concurrent read access of the data set is permitted. Recommended.
FREESPACE(30 30)
Specifies the amount of space to remain free when the cluster is loaded (by percentages).
Recommended.
UNIQUE
Specifies unique space for the data and index portions of the data set. Recommended.
KEYS(60, 0)
Required values are 60, 0.
Workload Recovery Considerations

The following articles are some general notes to ensure that the production workload suffers only
minimal disruptions for most disaster situations.
To preserve the integrity and effectiveness of CA Workload Automation CA 7® Edition in the most
severe disaster recovery situations, good practices regarding backup of the system are imperative.
08-Feb-2018 602/722
Not only CA Workload Automation CA 7® Edition backup and recovery procedures are at question.
Also all the application systems that CA Workload Automation CA 7® Edition controls and all the
systems that are required to maintain an orderly workflow require examination.
CA 7 Workload Recovery Considerations

Recovery procedures must include jobs to back up and reload the systems that are under control of
CA Workload Automation CA 7® Edition. Under control of CA Workload Automation CA 7® Edition,
these jobs are backed up with CA Workload Automation CA 7® Edition. The user can develop a series
of jobs so that one initial backup/reload job can be demanded at the appropriate time. That one job
triggers the other backup/reload jobs in a logical sequence.
The safest procedure to adopt is frequent backups of most CA Workload Automation CA 7® Edition
data sets and all systems under the control of CA Workload Automation CA 7® Edition. This data
includes all JCL, load module and control statement data sets, and so forth. Back up all on the same
time period. During the backup of the CA Workload Automation CA 7® Edition database, shut down
CA Workload Automation CA 7® Edition for predictable results.
If frequent backups of CA Workload Automation CA 7® Edition data sets are not feasible, consider
relating backup frequency to update frequency. For example, a database usually has the highest
frequency of update. The database would have the highest frequency of backup. Some data sets have
a low frequency of update in some data centers.
Other CA Products
User backup procedures for CA Workload Automation CA 7® Edition also relate to disaster recovery.
If you also have CA Workload Automation Restart Option for z/OS Schedulers or CA 1®, CA Workload
Automation CA 7® Edition either interfaces with them or controls them. Therefore, make their
backups timely and synchronized with CA Workload Automation CA 7® Edition backup.
Other Vendor Software Products

Place backups for any other product or software package that are necessary for an orderly
progression of work under the control of CA Workload Automation CA 7® Edition. In this way,
backups, restores, and recovery activities are facilitated. Follow vendor recommendations for
backups of these data sets.
Workload Documentation Considerations

One of the important features that users sometimes overlook is the workload documentation
function. When you use the workload documentation effectively, the documentation for all relevant
systems and recovery requirements for any production consideration is kept online. If a disaster
situation arises, the information can aid in accomplishing a recovery. Because the information resides
in the database, any backup of the database also preserves this data.
08-Feb-2018 603/722
NCF Usage
Assume that a user has NCF installed and a disaster situation occurred. The user can go to a new site
with less computing capacity than the destroyed site. The reason is that NCF can offload, to yet
another site, the work that the temporary data center cannot handle. Some JCL changes are involved
to handle the routing to the other data centers.
Magnetic Tape Considerations

Recovery procedures must also consider the FTAPE command. FTAPE can help identify the necessary
tapes to reestablish orderly workflow. Database cross-reference reports are also helpful. The reports
itemize the data set names needed for the jobs.
Recovery Aid
Recovery from system failures is typically a fairly easy process with the CA Workload Automation CA
7® Edition system. Perform a warm start or emergency restart. Do an LQ display to determine the
status of jobs that were active in the system at the time of failure. Then maintenance and restarts are
performed where necessary.
However, if the failure causes the destruction of the CA Workload Automation CA 7® Edition queue
(active workload or database), a warm start or emergency restart of CA Workload Automation CA 7®
Edition is impossible. Because all queue data is lost with a cold start, it becomes difficult to determine
the status of jobs that were active when the system failed, or even to determine which jobs were
active when the failure occurred.
The recovery aid facility provides formatted information from log data reflecting major milestones in
the life of each job. This information can be helpful in recovering from a CA Workload Automation CA
7® Edition failure in which one or more of the CA Workload Automation CA 7® Edition queues are
destroyed. Although this feature does not provide automatic queue recovery, it does provide
information about all jobs active in CA Workload Automation CA 7® Edition at the time of failure.
No information is given concerning the state of the progress of a workstation network in the
preprocessing or postprocessing queue. However, for jobs in the request, ready, active, and prior-run
queues, network requirements are noted on a yes or no basis.
The recovery aid reports are available, through the history reporting facility, in the event one or more
queues are destroyed. The remainder of the system must be intact. This facility can determine the
status of the workload that was in the system at the time of failure. The facility then assists in
recovering from such a failure.
Note: If the CA Datacom/AD database is lost, perform a forward recovery action. Next,
start with a WARM or an ERST start.
08-Feb-2018 604/722
Queue Milestones
The recovery aid facility uses the batch history reporting facility to produce the recovery aid reports
from the following records in the log data set:
Type X'64' - CA Workload Automation CA 7® Edition Startup
Type X'75' - Queue Posting
Type X'69' - CA Workload Automation CA 7® Edition Queue Movement
The Type X'69' log record is generated for queue milestones for CPU jobs but not for workstation
networks. However, information provided in the log records indicates when any networks are
associated with the job. The reports include this indication to alert the user to restore those networks
manually to their appropriate status in the queues.
The log records contain an image of the CA Workload Automation CA 7® Edition internal queue
records as of the time the log record was written. Type X'69' records are written to the log data set
for each of the following milestones:
When a job initially enters the request queue as a result of an automated or manual scheduling
event. The initial entry is only a skeleton record at this time.
When skeleton records are filled in with data from the database. This data includes all
preexecution requirements (for example, overrides, user verification, holds, submit times, and so
forth).
When all requirements for a job are satisfied, and the job moves from the request queue to the
ready queue.
When JCL in the ready queue is submitted for execution.
When JES first initiates a job, and the job moves from the ready queue to the active queue.
When job execution ends, either typically or abnormally, and is moved back to the request queue
from the active queue.
When a job has successfully completed and is moved from the request queue to the prior-run
queue. If not successfully completed, a job remains in the request queue until a restart is
manually performed. Once the restart requirement is satisfied, logging of milestones resumes as
for a normal job life.
When a job is moved back to the request queue as a result of one of the following:
A manually entered REQUEUE top line command.
The Q function from a QM.1 panel.
Requeue a job from either the ready or active queues.
08-Feb-2018 605/722
Preserve the Log Data

If the user wants to generate the recovery aid reports after CA Workload Automation CA 7® Edition is
restarted, unload the log data before the restart. Use SASSHIS5, the normal backup program
provided, for this purpose. Use that data as input to the history reporting facility either before or
after CA Workload Automation CA 7® Edition is restarted.
Reports Generated
You can use CA Workload Automation CA 7® Edition log data, requested by a control statement, to
report the status of CA Workload Automation CA 7® Edition jobs at the time of failure. With the log
data, the recovery aid program can produce the following reports through the history reporting
facility:
SASSRA01 - Last Logged Status of Jobs report
SASSRA02 - Generated Batch Terminal Interface Commands report
SASSRA03 - Simulated LQ Display of Jobs report
An optional data set can also be generated. This data set contains the commands necessary to get
the jobs back into the request queue. This data set is in standard CA Workload Automation CA 7®
Edition batch terminal interface format.
These reports let the user quickly:
Determine the status of all jobs at the time of failure.
Restart the necessary jobs after a COLD or FORM start of CA Workload Automation CA 7® Edition.
Use the command data set so that those jobs that were active at the time of failure can be
reentered into the request queue.
The recovery aid reports help in recovery as follows:
Provide an audit trail of queue contents and generated commands.
Aid in determining whether to modify generated commands before resubmitting them to CA

Assist in determining the manual recovery required for workstation network usage for CPU jobs.
08-Feb-2018 606/722
Request the Reports

A report type-50 control record is input to the history reporting facility, SASSHIS8, to generate the
recovery aid reports. The control record can be input alone or with other history report requests.
Optionally, through the control record, the user can request the creation of a data set that can be
input to the batch terminal interface.
Enter a start time (and optionally an end time) into the control record to govern the information to
extract. The start time must specify a point far enough back in time to ensure that at least one
milestone (log record) is included for each job. Otherwise, the job does not appear either in the
reports or the generated batch commands. Because a COLD or FORM start clears all of the queues
without producing log records, the start time should not be before the most recent COLD or FORM
start. In the absence of an end time in the control record, log records are extracted until the end of
file is reached (presumably the point of failure).
Program SASSHR50 prints the recovery aid reports. The program selects only the last type X'69' or
X'75' record per job written to the log before the system failure. This program formats and prints
reports SASSRA01 and SASSRA03. If you requested commands in the control record, report SASSRA02
and a file of commands are also produced.
Users of the CA Workload Automation CA 7® Edition NCF facility must make their NCF node table
available to provide node names on the reports. You can make this table available through the
ddname STEPLIB. You can also define the table in the linklist.
Recovery Aid Procedures

Documenting all possible situations that can occur requiring the use of the recovery aid output is an
impossible task. The following items are intended only as a general guideline.
1. Establish procedures for management of CA Workload Automation CA 7® Edition log data so

that if a system or CA Workload Automation CA 7® Edition failure occurs, all log data is saved.
These procedures must include saving log files before a cold type (COLD, FORM) start is
attempted. Use the SASSHIS5 program/job to save the data and accumulate it into the log
history file.
2. Implement procedures for also saving master station output. This output can be gathered by
running the Master Station Activity Report SASSHR08 (https://wiki.ca.com/display/CWAC7E
/Master+Station+Activity+Report+SASSHR08). The recovery aid output is probably more useful
than the master station output. However, any jobs that had workstation networks in-process
at the time of the failure sometimes require master station output to determine their status.
3. After verifying that log and master station output are saved, try to restart CA Workload
Automation CA 7® Edition with either WARM or ERST (emergency restart).
4. If CA Workload Automation CA 7® Edition comes up successfully, it is unnecessary to continue

this procedure.
5.
08-Feb-2018 607/722
5. Otherwise, produce the recovery aid output, using the history reporting job and the log data
that you saved and accumulated in Step 1.
Specify a start date/time that is at least before the last schedule scan that scheduled jobs that
were still in the queues. Do not specify a start date/time that is earlier than the last COLD or
FORM start of CA Workload Automation CA 7® Edition. A date/time value earlier than one of
those types of CA Workload Automation CA 7® Edition restarts causes the selection of
unnecessary records. The recovery aid report generation to take longer than it would
otherwise.
Specify an ending date/time that is later than the system failure. Any value later than the last
log record on the log history file works. This value causes all records up to the end of the file,
the last log record that was written before the failure, to be considered.
If you want the batch terminal interface command data set commands, also specify either
DEMAND or DEMANDH in the report type-50 control record. DEMANDH is the recommended
value.
6. COLD start CA Workload Automation CA 7® Edition. Step 6 can be done before, after, or
concurrently with Step 5. Consider specifying RUNOPT=NSTA instead of SCAN to deactivate
the schedule scan for the time being. If one of the queues has been destroyed, a FORM start is
sometimes necessary.
7. Using the recovery aid reports, research the status of all CPU jobs that were in the request,
ready, or active queues. Once Step 6 has been completed, all CA Workload Automation CA 7®
Edition inquiries, forecasts, and so forth, are also available for further assistance in this
process.
8. Perform any necessary file maintenance, JCL overrides, and so forth. If CA Workload
Automation Restart Option for z/OS Schedulers was being used in all of the jobs, file
maintenance is probably unnecessary.
9. If generated in Step 5, edit the commands data set as necessary to accomplish whatever
action was determined in Step 7 as correct for each job.
Be sure to provide the proper operator ID in the /LOGON command.
10. Once the commands data set is in order, run a batch terminal interface job using the
commands data set as the input data.
If the queues contained only a few jobs at the time of the failure, issuing online commands is
sometimes easier to return the jobs to the queues. The user must decide which technique is
most appropriate for the number of jobs involved.
If CA Workload Automation CA 7® Edition was activated without a schedule scan, use the
SSCAN command and an appropriate PERSTART time to reactivate a schedule scan.
If USERID security was in use, some of the demanded jobs are not always scheduled correctly
depending on the operator ID that the batch terminal interface run used.
11. The following items can assist you in determining which workstation networks, if any, were in
process and their status at the time of the failure.
The NETWORKS field on the SASSRA01-01 Last Logged Status of Jobs report from Step 5.
The master station output from Step 2.
08-Feb-2018 608/722
Input networks have to be manually rescheduled and reinstated to the appropriate status.
Output networks are automatically scheduled back into the queues by the generated
commands for the associated CPU jobs. However, reinstate their status manually when the
network had progressed anywhere beyond the LOGIN of the first workstation.
Do not overlook any jobs that made it to the prior-run queue before the failure but still had
output networks in-process. No commands are generated for jobs that made it to the prior-
run queue. Manually reschedule and reinstate any such networks the way that input networks
are.
The following JCL is a Recovery Aid JCL sample:
//jobname JOB ............
//stepname EXEC CA7LOG,PG=SASSHIS8
//COMMANDS DD DSN=user.ca7.recovery.commands,
// DISP=(,CATLG,DELETE),UNIT=SYSDA,
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=nnnnn)
//UCC7ARCH DD DUMMY
//UCC7HIST DD DSN=user.ca7.loghist(0),DISP=OLD
//SASSRA01 DD SYSOUT=A
//SYSIN DD *
50RECOVERYyydddhhmmyydddhhmmDEMANDH
/*
The installation process generates the CA7LOG procedure, which can have a different name at
your site.
Disaster Recovery Mode

These articles discuss the CA Workload Automation CA 7® Edition disaster recovery mode and how it
can be used in a disaster recovery situation.
A typical CA 7 instance has many thousands of jobs that are defined in various job streams. Not all of
these jobs have the same level of importance, especially in a disaster recovery situation.
In a disaster recovery environment, you can decide to have CA Workload Automation CA 7® Edition
schedule and submit some jobs but not others. The disaster recovery mode is a tool that can be used
to identify the jobs that CA Workload Automation CA 7® Edition submits.
Initialization file statement DRMODE sets the initial disaster recovery mode options for TRIGGERS,
RQMTS, and DEFCLASS. These options can be changed using the /DRMODE command.
Initialization file statement DRCLASS creates the initial set of active disaster recovery classes. Disaster
recovery classes can be added to the active class or removed from the active list using the /DRCLASS
command.
Note: CA Workload Automation CA 7® Edition does not start in disaster recovery mode
when either the DRMODE or DRCLASS initialization file statements are present in the
CA Workload Automation CA 7® Edition starts in disaster recovery mode when it is started with the
08-Feb-2018 609/722
CA Workload Automation CA 7® Edition starts in disaster recovery mode when it is started with the
parameter DRMODE=YES.
Disaster Recovery Classes

The CA Workload Automation CA 7® Edition disaster recovery mode centers on disaster recovery
classes. A disaster recovery class is a one-to eight-character alphanumeric label that you define.
Disaster recovery classes are either active or inactive. A disaster recovery class is active if it is in the
list of active disaster recovery classes. To see a list, enter the following command:
/DISPLAY,ST=DR
If a disaster recovery class is not in the active list, it is inactive.
The DRCLASS field on the job definition panel can assign a disaster recovery class to every job.
If a job does not have a disaster recovery class, one is assigned to it based on the DEFCLASS (default
class) setting. DEFCLASS is set on the DRMODE initialization file statement or on the /DRMODE
command. DEFCLASS can cause CA Workload Automation CA 7® Edition to use the SYSTEM value of
the job, or it can provide a default disaster recovery class for all jobs to use.
If, after using DEFCLASS, the disaster recovery class for a job resolves to blanks, a disaster recovery
class of **NONE** is assigned. This class is never active.
Schedule Scan
When schedule scan runs in disaster recovery mode, it lists to the browse log all of the disaster
recovery classes that are currently active.
When a job is found that is typically added to the request queue, schedule scan determines whether
the disaster recovery class of the job is active. If the disaster recovery class of the job is not active,
the job is not added to the request queue. A message is written to the browse log listing the job
name and its disaster recovery class.
Workload balancing jobs (job names starting with UCC7R) are always added to the request queue,
regardless of their disaster recovery classes.
Jobs manually added to the workload, such as through the DEMAND command, are always added,
regardless of the disaster recovery class of the job. Job requirements and triggers are still subject to
disaster recovery mode.
Suppress Triggers During Disaster Recovery

You can suppress triggered jobs when CA Workload Automation CA 7® Edition is running in disaster
recovery mode.
If the DRMODE option TRIGGERS=ALL is set, all triggers typically occur.
If TRIGGERS=DR is set, jobs are only triggered when they have an active disaster recovery class. A
08-Feb-2018 610/722
If TRIGGERS=DR is set, jobs are only triggered when they have an active disaster recovery class. A
message is written to the browse log for jobs that are not triggered.
If TRIGGERS=NONEXEC is set, all triggers occur, but jobs with an inactive disaster recovery class are
marked as nonexecutable.
Note: For more information about nonexecutable jobs, see the EXEC field description on
the job definition panel.
Workload balancing jobs (job names starting UCC7R) are always triggered, regardless of their disaster
recovery classes.
Job Requirements
Job predecessors that are not satisfied when a job enters the request queue are sometimes ignored
when CA Workload Automation CA 7® Edition is running in disaster recovery mode.
If the DRMODE option RQMTS=ALL is set, all job requirements are honored.
If RQMTS=DR is set, a job requirement is satisfied if the predecessor job's disaster recovery class is
not active. In other words, if a job requirement has an inactive disaster recovery class, the job
requirement is ignored. A message is written to the browse log for job requirements that are
satisfied.
Requirements are only satisfied when a job enters the request queue. Jobs already in the request
queue when CA Workload Automation CA 7® Edition starts disaster recovery mode continues to wait
on their predecessors.
Disaster recovery mode does not affect negative requirements (mutually exclusive jobs).
End Disaster Recovery Mode

In the event of a real disaster at your data center, the time eventually comes when the disaster is
over and you want to return to business as usual.
Some jobs enter the request queue with unsatisfied job requirements once disaster recovery mode is
turned off.
For example, consider job SMF01 in the previous topic. The job has been running during the disaster,
but its predecessor job, RPT01, has not. The CA Workload Automation CA 7® Edition disaster recovery
mode has automatically satisfied the job requirement.
Once disaster recovery mode is turned off, however, job SMF01 can enter the request queue long
before the next scheduled run of RPT01. SMF01 waits for the next execution of RPT01.
Careful planning must be done when deciding when to turn off disaster recovery mode. In addition,
expect manual intervention to satisfy job requirements that have not executed during the disaster.
08-Feb-2018 611/722
Disaster Recovery Example

For this disaster recovery example, assume the following initialization file options:
DRMODE,TRIGGERS=DR,RQMTS=DR,DEFCLASS=@SYSTEM
DRCLASS,CLASS=(TIER1,PAYROLL)
The following jobs are included in the example:
Job Name DRCLASS SYSTEM Comments

PAY01 blank PAYROLL Scheduled. Triggers PAY02 and RPT02
PAY02 blank PAYROLL Triggered by PAY01
RPT01 blank REPORT Scheduled.
RPT02 ACCT REPORT Triggered by PAY01
SMF01 TIER1 SMF Scheduled. Waits for RPT01 to complete (job requirement)
CA Workload Automation CA 7® Edition is started with the parameter DRMODE=YES. During startup,
the following highlighted message is issued to the console:
CAL2D001I CA-7 IS STARTING IN DISASTER RECOVERY MODE
Disaster recovery classes TIER1 and PAYROLL are added to the active disaster recovery class list when
the DRCLASS initialization file statement is processed.
The /DISPLAY,ST=DR command would display the following information:

/DISPLAY,ST=DR
DISASTER RECOVERY MODE IS ACTIVE PAGE 0001
TRIGGERS: DR RQMTS: DR DEFAULT CLASS: @SYSTEM
ACTIVE DISASTER RECOVERY CLASSES:
TIER1
PAYROLL
Schedule scan runs. At the beginning of schedule scan, the following messages are written to the
browse log:
SCNJ-43 CA-7 IS RUNNING IN DISASTER RECOVERY MODE
SCNJ-44 DISASTER RECOVERY CLASS TIER1 IS ACTIVE
SCNJ-44 DISASTER RECOVERY CLASS PAYROLL IS ACTIVE
SCNJ-45 END OF ACTIVE DISASTER RECOVERY CLASS LIST
Job PAY01 should be added to the request queue. Because PAY01 does not have a disaster recovery
08-Feb-2018 612/722
Job PAY01 should be added to the request queue. Because PAY01 does not have a disaster recovery
class, the DEFCLASS rule of @SYSTEM is used. The job's SYSTEM value of PAYROLL is used as the job's
disaster recovery class. Because PAYROLL is an active disaster recovery class, job PAY01 is added to
the request queue.
Job RPT01 should also be added to the request queue. Because RPT01 does not have a disaster
recovery class, the DEFCLASS rule of @SYSTEM is used. The job's SYSTEM value of REPORT is used as
the job's disaster recovery class. Because REPORT is not an active disaster recovery class, job RPT01 is
not added to the request queue. The following message is written to the browse log:
SCNJ-42 JOB RPT01 SKIPPED BY SSCAN--DRCLASS REPORT NOT ACTIVE
Job SMF01 should be added to the request queue. Because SMF01 has a disaster recovery class of
TIER1, which is active, SMF01 is added to the request queue.
Job SMF01 has a job requirement of RPT01. Assume that the requirement any of the CA Workload
Automation CA 7® Edition normal procedures do not satisfy the job. Because job RPT01 does not
have a disaster recovery class, the DEFCLASS rule of @SYSTEM is used. EPORT is used for the disaster
recovery class. REPORT is not an active disaster recovery class, so the job requirement on SMF01 is
posted as complete. The following message is written to the browse log:
SIRA-16 JOB RQMT RPT01 SATISFIED--DRCLASS REPORT INACTIVE
Job PAY01 is submitted and completes successfully. Jobs PAY02 and RPT02 should be triggered.
Because job PAY02 does not have a disaster recovery class, the DEFCLASS rule of @SYSTEM is used
and PAYROLL is used for the disaster recovery class. Because PAYROLL is an active disaster recovery
class, job PAY02 is added to the request queue.
Job RPT02 has a disaster recovery class of ACCT. Because ACCT is not an active disaster recovery
class, job RPT02 is not triggered. The following message is written to the browse log:
SATO-69 JOB RPT02 NOT TRIGGERED--DRCLASS ACCT NOT ACTIVE
Log Data Set Management

For processing the CA Workload Automation CA 7® Edition log data sets, define separate jobs in the
database for dumping each data set. When one log becomes full, recording activity automatically
switches to the alternate log. In addition to switching from one log to the other, CA Workload
Automation CA 7® Edition automatically schedules the appropriate job for dumping the full log.
Define the jobs to use for dumping the log in the CA Workload Automation CA 7® Edition database.
The job name of the job to dump the primary log must have an eighth character of P, for primary. The
job name for the secondary log dump job must have the same first seven characters as the primary
log dump job. An eighth character of S, for secondary, is required.
The log dump job must be identified in the CA Workload Automation CA 7® Edition initialization file.
Specify the job name of the log dump job on the DBASE statement. If two logs are defined, the job
name of the primary log dump job must be specified.
08-Feb-2018 613/722
The JCL for the log dump jobs (and the appropriate initialization file statements) is generated during
the SYSGEN of CA Workload Automation CA 7® Edition. During the batch execution of CA Workload
Automation CA 7® Edition at installation time, log dump jobs were added to the database as job
CA07LOGP and CA07LOGS. The prefix CA07 is sometimes changed. The JCL is located in the CA 7
JCLLIB. The procedure, CA7LOG, was added to a PROCLIB in the N020 installation job.
These jobs can also unload log data, following a system failure and before restarting CA Workload
Automation CA 7® Edition, for input to the recovery aid procedure.
The secondary log dump job is a duplicate of the primary log dump job with the following two
exceptions:
The job name must end with an S (S for secondary).
The DD statement for LOGIN references the secondary data set.
The LOGIN data set name in each job must refer to the appropriate log data set as it is cataloged on
the OS catalog.
You can change the LOGIN, HISTIN, and HISTOUT data set names and the job names to meet
installation standards.
We recommend that the data set to which the log is dumped is a GDG with at least three entries. The
CA 7 JCLLIB member GDGDECK defines the GDG family. GDGDEL deletes the family. Executing
CA07N010 invokes the GDGDECK member.
History Management Program - SASSHIS5

The History Management Program, SASSHIS5, extracts and manages the log records produced by the
CA Workload Automation CA 7® Edition system. SASSHIS5 collects log records from the primary or
secondary log files. SASSHIS5 stores them in a control sequence on the log history file. The resulting
report reflects the current contents of the log history file as record counts within the date and time-
of-day ranges in which the records were generated.
At the user's option, SASSHIS5 can also remove log records from the log history file and place them
on the log archives file. This transfer can occur either while the log records are being extracted from
the log files or as a separate operation by making the DD for the log files a DD DUMMY.
Input
Log data file

Log history file
Output
Log archives file (optional)

Log history file
History Management report
PARM operand
08-Feb-2018 614/722
The optional PARM operand of the EXEC statement allows two fixed-length positional keywords:
Date for last records to move
Sort Size
The date format is either a Julian date (yyddd) or a literal value. The literal values indicate a range of
dates. The ending date that is implied by the literal value or the Julian date indicates the end of the
period to place on the log archive files. All records up to and including this date are placed on the
archive file.
Note: The beginning date of the literal value range allows for notification when records
outside of the date range are moved into archives. If the log history file contains records
that are dated before the range beginning date, a message is appended to the report
produced. The program ends with return code 4 at the completion of the move to archives.
This operand has the following format:

PARM='{yyddd},nnnnnn'
{TODAY}
{TWEEK}
{TMNTH}
{TQRTR}
{nnDAY}
{-nDAY}
{LWEEK}
{LMNTH}
{LQRTR}
Where:
yyddd
Defines a Julian date specifying the ending date of the period to place on the log archives file. Five
blanks cause no record archiving. This parameter has no default.
Literals for to-date record archival control and their meanings are as follows:
TODAY
Indicates to use the current date as the ending date of the period to place onto the log archives
file. This value is a special case and does not indicate a beginning date.
TWEEK
file. Also indicates the date of last Sunday as the beginning of the period.
TMNTH
file. Also indicates the first day of the current month as the beginning of the period.
08-Feb-2018 615/722
TQRTR
file. Also indicates the first day month two months ago as the beginning of the period. (Not
calendar quarter.)
nnDAY
Indicates the previous nn days through the current date.
Literals for the prior period (whose end time has already passed) record archival control and their
meanings are as follows:
-nDAY
Indicates the previous n 24-hour periods, encompassing the number of days that n specifies,
ending yesterday.
LWEEK
Indicates the period beginning the previous Sunday through Saturday.
LMNTH
Indicates the period encompassing the previous calendar month.
LQRTR
Indicates the period encompassing the previous three consecutive calendar months.
nnnnnn
Defines a six-digit number, with leading zeros, representing the amount of memory available to
the internal sort. The value must be six blanks when not used. The maximum available memory is
the default.
Flowchart
The following example illustrates the flow of the SASSHIS5 program.
08-Feb-2018 616/722
SASSHIS5 File Descriptions

An example of the log archive JCL is found in the CA 7 JCLLIB member CA07N535. The prefix CA07 is
sometimes changed.
The following table contains file descriptions for SASSHIS5.
File DDNAME Description

Name
Log LOGIN The log file produced by CA Workload Automation CA 7® Edition. This file is the
File primary source of information for SASSHIS5.
Log HISTIN The generation data set containing the accumulated history available for analysis.
History
Log ARCHOU The generation data set containing the accumulated history purged from the log
Archive T history and saved for analysis. This file can be a MOD file.
s
Log HISTOUT The generation data set containing accumulated history available for analysis.
History
Condition Codes
SASSHIS5 can issue the following condition codes:
08-Feb-2018 617/722
4
Indicates that records exist in the history file that are outside of the literal date range that the
PARMs supply. All records before the ending date that is implied by the literal value are moved to
the archive file.
8
Indicates an error with SORT.
12
Indicates a PARM error. The PARM errors cause the creation of an empty history and archive file
generation. To maintain the data integrity, delete these files.
SASSHIS5 Report Descriptions

SASSHIS5 produces the History Management report. The report reflects current activity in SASSHIS5
and the contents of log history and log archives. The ddname is CNTLREPT.
The following sample is a History Management report.
HIS5-01 PARM=yy215,200000
SASSHIS5 C A - 7 - HISTORY MANAGEMENT 08/02/yy 11:03 PAGE 002
---------------------------------------------------------------------------------------------------------------------------------
LOG DATA EXTRACTED P/ STARTING ENDING RECORD D S ARCHIVES EXTRACTED DUPLICATE
CATEGORY DATE TIME S DATE TIME DATE TIME COUNT DATE TIME COUNT
---------------------------------------------------------------------------------------------------------------------------------
HISTORY EXTRACT 02/12/yy 10:31 S 02/12/yy 10:28 02/12/yy 10:28 00000001 05/17/yy 16:15
02/19/yy 09:15 S 02/18/yy 10:42 02/18/yy 10:42 00000001 05/17/yy 16:15
02/19/yy 16:04 S 02/19/yy 14:22 02/19/yy 14:22 00000001 05/17/yy 16:15
03/01/yy 10:12 S 02/29/yy 14:23 02/29/yy 14:23 00000001 05/17/yy 16:15
05/14/yy 08:54 S 05/13/yy 15:12 05/13/yy 15:12 00000001 05/17/yy 16:15
05/14/yy 08:54 S 05/17/yy 14:03 05/17/yy 16:48 00002456 05/18/yy 09:11
05/18/yy 09:03 P 05/17/yy 16:48 05/17/yy 19:44 00000390 05/18/yy 09:11
HISTORY EXTRACT 05/18/yy 09:03 P 05/18/yy 09:03 05/18/yy 09:03 00000001 05/18/yy 15:49
05/18/yy 15:09 S 05/18/yy 09:04 05/18/yy 15:08 00005036 05/18/yy 15:49
05/18/yy 15:09 P 05/18/yy 15:08 05/18/yy 20:47 00001166 05/25/yy 10:50
05/19/yy 08:58 P 05/18/yy 20:48 05/18/yy 20:48 00000001 05/25/yy 10:50
05/19/yy 08:58 S 05/18/yy 20:49 05/19/yy 01:36 00001162 05/25/yy 10:50
05/19/yy 12:10 P 05/19/yy 08:58 05/19/yy 12:08 00002054 05/25/yy 10:50
05/19/yy 16:29 P 05/19/yy 12:09 05/19/yy 12:09 00000001 05/25/yy 10:50
05/19/yy 16:29 S 05/19/yy 12:10 05/19/yy 14:33 00000517 05/25/yy 10:50
05/19/yy 21:06 P 05/19/yy 16:28 05/19/yy 21:05 00001623 05/25/yy 10:50
05/20/yy 12:39 S 05/19/yy 21:05 05/20/yy 12:36 00002991 05/25/yy 10:50
05/20/yy 16:22 P 05/20/yy 12:38 05/20/yy 16:20 00002118 05/25/yy 10:50
05/23/yy 09:02 P 05/20/yy 16:21 05/20/yy 16:21 00000001 05/25/yy 10:50
05/23/yy 09:02 S 05/20/yy 16:22 05/20/yy 20:51 00000380 05/25/yy 10:50
05/23/yy 11:39 P 05/23/yy 09:01 05/23/yy 11:38 00002511 05/25/yy 10:50
05/23/yy 15:14 S 05/23/yy 11:38 05/23/yy 15:11 00010197 05/25/yy 10:50
05/23/yy 15:38 P 05/23/yy 15:34 05/23/yy 15:35 00000129 05/25/yy 10:50
05/23/yy 15:50 S 05/23/yy 15:46 05/23/yy 15:47 00000199 05/25/yy 10:50
05/24/yy 09:05 S 05/23/yy 17:32 05/24/yy 01:28 00002043 05/25/yy 10:50
05/24/yy 10:22 P 05/24/yy 09:04 05/24/yy 10:21 00002873 05/25/yy 10:50
05/24/yy 15:45 S 05/24/yy 10:21 05/24/yy 15:44 00012954 05/25/yy 10:50
05/24/yy 18:17 S 05/24/yy 15:44 05/24/yy 15:44 00000001 05/25/yy 10:50
05/24/yy 18:17 P 05/24/yy 15:44 05/24/yy 18:15 00002890 05/25/yy 10:50
05/25/yy 10:22 P 05/24/yy 18:16 05/24/yy 18:16 00000001 05/25/yy 10:50
08-Feb-2018 618/722
05/25/yy 10:22 S 05/24/yy 18:17 05/25/yy 00:13 00000468 05/25/yy 10:50
05/25/yy 10:20 P 05/25/yy 10:20 05/25/yy 11:34 00002996 05/27/yy 08:04
05/25/yy 15:58 S 05/25/yy 11:34 05/25/yy 15:55 00013603 05/27/yy 08:04
05/25/yy 19:34 P 05/25/yy 15:55 05/25/yy 19:32 00002381 05/27/yy 08:04
05/26/yy 12:06 P 05/25/yy 19:33 05/25/yy 19:33 00000001 05/27/yy 08:04
05/26/yy 12:06 S 05/25/yy 19:34 05/26/yy 12:03 00007848 05/27/yy 08:04
05/26/yy 16:37 P 05/26/yy 12:03 05/26/yy 14:14 00003101 05/27/yy 08:04
05/27/yy 05:24 P 05/26/yy 14:14 05/26/yy 14:14 00000018 05/27/yy 08:04
05/27/yy 05:24 S 05/26/yy 14:14 05/27/yy 05:22 00008226 05/27/yy 08:04
05/27/yy 05:24 S 05/27/yy 05:23 05/27/yy 05:23 00000001 06/01/yy 10:11
05/27/yy 09:39 P 05/27/yy 05:24 05/27/yy 09:38 00001704 06/01/yy 10:11
This report contains the following fields:
LOG DATA CATEGORY

Specifies the disposition of the CA Workload Automation CA 7® Edition log records is represented
as follows:
HISTORY EXTRACT
Data was removed from the log history file and placed on the log archives file.
LOG EXTRACT
Data was extracted from the log history files and placed on the log history file.
Spaces
Data is a continuation of the previous nonblank category. Results when a swap occurs
between the primary and secondary log files due to an overflow.
EXTRACTED DATE TIME

Specifies the date and time log records were extracted and placed on the log history file.
P/S
Specifies whether log file data was extracted from primary or secondary.
STARTING DATE TIME

Specifies the date and time the first record of this batch was written to the log file.
ENDING DATE TIME

Specifies the date and time the last record of this batch was written to the log file.
RECORD COUNT
Specifies the number of log records extracted for the represented CA Workload Automation CA
7® Edition session.
ARCHIVES EXTRACTED DATE TIME

Specifies the date and time the log records represented were removed from log history and
placed on log archives. Blank for LOG DATA CATEGORY value of LOG EXTRACT.
DUPLICATE COUNT
Specifies the number of duplicated records that were bypassed.
The History Management report also displays the options used in the PARM and any associated error
messages.
08-Feb-2018 619/722
History Purge Program - SASSHIS6

The History Purge program, SASSHIS6, deletes unwanted log records from the log history and log
archives files while keeping the internal control data between the files synchronized. Run SASSHIS6
whenever the older log records are no longer needed for analysis. These records are permanently
deleted from the system and thus prevent the log files from becoming too large. The log files that are
created from SASSHIS6 are the new files that are used in subsequent history reporting activities.
Input
Log history file

Log archives file
Output
Log history file

Log archives file
Archives Purge report
Required parameter
PARM='parameter'
PARM operand
The required PARM operand of the EXEC statement must contain one of the following purge
parameters.
PARM='{PURGE=xxddd,yyddd}'
{TODAY}
{TWEEK}
{TMNTH}
{TQRTR}
{nnDAY}
{-nDAY}
{LWEEK}
{LMONTH}
{LQRTR}
PURGE
Identifies the from dates and through dates defining the period (or range) to purge.
xxddd
Defines a Julian date specifying the start of the period to be deleted from the files (from date).
This value has no default.
yyddd
Defines a Julian date specifying the end of the period to be deleted from the files (through
date). This value has no default.
Literals for to-date purge control and their meanings are as follows:
TODAY
Deletes all data with the current date.
TWEEK
08-Feb-2018 620/722
TWEEK
Deletes all data produced this calendar week, date of last Sunday through today.
TMNTH
Deletes all data produced this calendar month. The delete begins with the date of the first day of
the current month through today.
TQRTR
Deletes all data produced this quarter. The delete begins with the date of the first day of the
month two months ago, plus the current month through today. (Not calendar quarter.)
Literals for prior periods (whose end times have already passed) and their meanings are as follows:
nnDAY
Deletes the previous nn days through current date/time.
-nDAY
Deletes data from the previous n 24-hour periods. This value generates a control statement with
a beginning time of 0000 and an ending time of 2400, encompassing the number of days that n
specifies. The ending date/time is yesterday at midnight.
LWEEK
Deletes data from the previous Sunday through Saturday.
LMNTH
Deletes the data of the previous calendar month.
LQRTR
Deletes the data of the previous three consecutive months.
Flowchart
The following example illustrates the flow of the SASSHIS6 program.
08-Feb-2018 621/722
SASSHIS6 File Descriptions

An example of the log purge JCL is found in the CA 7 JCLLIB member CA07N540. The prefix CA07 is
sometimes changed.
The following table contains file descriptions for SASSHIS6.
File DDNAME Description

Name
Log HISTIN The generation data set containing the accumulated history available for analysis
Histor and deletion.
y
Log ARCHIN The generation data set containing the accumulated history previously transferred
Archiv from the log history file and available for deletion.
es
Log HISTOUT The generation data set containing accumulated history available for analysis after
Histor the specified history data has been deleted.
y
Log ARCHOU The generation data set containing the accumulated history (transferred originally
Archiv T from the log history file) after the specified history data has been deleted.
es
08-Feb-2018 622/722
Condition Codes
SASSHIS6 can issue the following condition codes:
4
Indicates that a new archive file was not created because no data was being purged from the
ARCHIN data set.
8
Indicates that a PARM error was detected.
SASSHIS6 Report Descriptions

SASSHIS6 produces the Archives Purge report. The report reflects current activity in SASSHIS6 and the
new contents of log history and log archives. The ddname is SYSLIST.
The following is a sample of the Archives Purge Report.
SASSHIS6 C A - 7 - ARCHIVES PURGE 07/25/yy 10:39 PAGE 001
---------------------------------------------------------------------------------------------------------------------------------
LOG DATA EXTRACTED STARTING ENDING RECORD ARCHIVE EXTRACT PURGED
CATEGORY DATE TIME DATE TIME DATE TIME COUNT DATE TIME DATE TIME
---------------------------------------------------------------------------------------------------------------------------------
02/19/yy 09:15 02/18/yy 10:42 02/18/yy 10:42 00000001 05/17/yy 16:15
02/19/yy 16:04 02/19/yy 14:22 02/19/yy 14:22 00000001 05/17/yy 16:15
03/01/yy 10:12 02/29/yy 14:23 02/29/yy 14:23 00000001 05/17/yy 16:15
05/14/yy 08:54 05/13/yy 15:12 05/13/yy 15:12 00000001 05/17/yy 16:15
05/14/yy 08:54 05/17/yy 14:03 05/17/yy 16:48 00002456 05/18/yy 09:11
05/18/yy 09:03 05/17/yy 16:48 05/17/yy 19:44 00000390 05/18/yy 09:11
CURRENT ARCHIVES 05/18/yy 09:03 05/18/yy 09:03 05/18/yy 09:03 00000001 05/18/yy 15:49
05/18/yy 15:09 05/18/yy 09:04 05/18/yy 15:08 00005036 05/18/yy 15:49
05/18/yy 15:09 05/18/yy 15:08 05/18/yy 20:47 00001166 05/25/yy 10:50
05/19/yy 08:58 05/18/yy 20:48 05/18/yy 20:48 00000001 05/25/yy 10:50
05/19/yy 08:58 05/18/yy 20:49 05/19/yy 01:36 00001162 05/25/yy 10:50
05/19/yy 12:10 05/19/yy 08:58 05/19/yy 12:08 00002054 05/25/yy 10:50
05/19/yy 16:29 05/19/yy 12:09 05/19/yy 12:09 00000001 05/25/yy 10:50
05/19/yy 16:29 05/19/yy 12:10 05/19/yy 14:33 00000517 05/25/yy 10:50
05/19/yy 21:06 05/19/yy 16:28 05/19/yy 21:05 00001623 05/25/yy 10:50
05/20/yy 12:39 05/19/yy 21:05 05/20/yy 12:36 00002991 05/25/yy 10:50
05/20/yy 16:22 05/20/yy 12:38 05/20/yy 16:20 00002118 05/25/yy 10:50
05/23/yy 09:02 05/20/yy 16:21 05/20/yy 16:21 00000001 05/25/yy 10:50
05/23/yy 09:02 05/20/yy 16:22 05/20/yy 20:51 00000380 05/25/yy 10:50
This report contains the following fields:
LOG DATA CATEGORY

Specifies the disposition of the CA Workload Automation CA 7® Edition log records are
represented as follows:
ARCHIVES PURGE
Data deleted from the log archives file.
CURRENT ARCHIVES
Data currently on the log archives file.
08-Feb-2018 623/722
CURRENT HISTORY
Data currently on the log history file.
HISTORY PURGE
Data deleted from the log history file.
EXTRACTED DATE TIME

Specifies the date and time log records were extracted.
STARTING DATE TIME

Specifies the date and time the first record of this batch was written to the log file.
ENDING DATE TIME

Specifies the date and time the last record of this batch was written to the log file.
RECORD COUNT
Specifies the number of log records extracted for the represented CA Workload Automation CA
7® Edition session.
ARCHIVE EXTRACT DATE TIME

Specifies the date and time the log records represented were extracted from either log history or
log archives.
PURGED DATE TIME

Specifies the date and time log records represented were purged from either log history or log
archives.
The Archives Purge Report also displays the options used in the PARM parameter and any associated
error messages.
Workload Balancing
The workload balancing facility can limit or prioritize the jobs that are submitted for execution.
Workload balancing behavior depends on the enhanced submission selection (SUBSEL=ENH) option.
Workload Balancing Without Enhanced Submission Selection (see page 624)

Workload Balancing With Enhanced Submission Selection (see page 626)
Workload Balancing Commands (see page 626)
Workload Balancing Without Enhanced Submission

Selection
The workload balancing facility analyzes jobs waiting for execution and sets priorities for submittal by
preset criteria. The preset criteria include the following items:
CPU usage
External events
08-Feb-2018 624/722
External events
Start times
Tape drive usage (not applicable to cross-platform jobs)
User-assigned priorities
Assume that the facility is active and objective criteria are defined. CA Workload Automation CA 7®
Edition analyzes every job waiting for execution whenever it is ready for processing or completes
processing. As resources are made available or released back to the operating system, the defined
pools are adjusted automatically to reflect current availability.
Each job waiting for processing is analyzed. Its priority is rewarded or penalized based on every
defined value. The job is then automatically submitted whenever the priority reaches the defined
threshold value or becomes the highest of all jobs waiting for submittal. The job with the highest
priority that can run within the available resources is always the next one submitted. If priorities are
equal, the number of available initiators sometimes causes the submission of multiple smaller jobs
rather than one large job. In this way, you attain maximum use of initiators.
The base priority for a job can be entered on the job definition panel when the job is initially defined
to CA Workload Automation CA 7® Edition. The priority can be any value from 1 to 255. Priority 255 is
reserved to force a job to be processed when all prerequisites have been satisfied. Priority 255 is
named the express priority. CA Workload Automation CA 7® Edition provides a default priority value
of 100. Whenever a job exceeds the maximum allowable quantity of resources, the maximum penalty
that is defined is assessed by subtracting that value from the priority. If a job requires the minimum
for any processing objective, the maximum reward is added to the job priority. For requirements
between the minimum and the maximum, CA Workload Automation CA 7® Edition adjusts priority by
a percentage of the reward. The relationship of the requirement to the difference between the
minimum and maximum determines the percentage. For example, if the range is 5 units and the
requirement is 3, 60 percent of the reward is given.
All of these decisions are made continuously based on the review of current conditions. Priority
values can increase or decrease whenever another event causes processing requirements or
availability to change. Relationships to events or time of day can cause priorities to change.
Note: VRM Device Control provides an alternative to the Workload Balancing control of job
submission that is based on tape drive availability. When this VRM option is activated, VRM
resources representing tape, disk, or both, storage devices are dynamically defined as part
of the database load process.
If the limit on the number of Workload Balancing tape drive types is too restrictive, consider this
option. Where Workload Balancing permits only two tape drive types, the user determines the
number of device groupings with VRM Device Definition.
Also, VRM Device Control operates independently of Workload Balancing and does not affect WLB
priority calculations.
08-Feb-2018 625/722
Workload Balancing With Enhanced Submission Selection

When the enhanced submission selection (SUBSEL=ENH) is active, the workload balancing feature can
limit job submission based on:
Total number of jobs that are permitted at one time
Number of each type (class) of jobs that are allowed at one time
Number of tape drives that the jobs use compared to the number of tape drives that are currently
available
Workload balancing also orders jobs that are based on the priority that is specified on the job
definition (DB.1, DB.10 or XPJOB, and DB.11 or AGJOB panels). A job with a higher priority is
considered for submission (and therefore receives a preference) over a job with a lower priority.
The job priority is not adjusted. None of the awards and penalties to the job priority for tape drive
use, CPU use, or any other factor are made. The value that is specified on the job definition is used as
is.
When the enhanced submission selection is active, workload balancing only uses the following values
from the workload balancing definition (the UCC7Rxxx module):
The number of tape drives
The class barrier
The total number of initiators
Workload Balancing Commands

The following table summarizes the workload balancing commands:
/WLB Command
Use the /WLB command to activate, deactivate, or modify the workload balancing function.
LWLB Command
Use the LWLB command to list currently active workload balancing and performance
management processing objective information.
RESCHNG Command
Use the RESCHNG command in a CA 7 trailer step to free tape drives that are no longer needed.
XWLB Command
Use the XWLB command, included in the workload balancing facility, for making temporary
changes in selection parameters.
08-Feb-2018 626/722
Define the Production Environment

Processing objectives involve far more than making a simple choice. A combination of different
factors is necessary. To start with, the following elements are described:
Tape drives
CPU use (This element is not used when the enhanced submission selection is active)
Initiators or job class structure
Job start times (This element is not used when the enhanced submission selection is active)
Threshold priorities (This element is not used when the enhanced submission selection is active)
A workload balancing questionnaire (see page 632) and its directions are provided. This questionnaire
can help you establish a startup objectives definition. By answering the questions as they apply to
your data center operation and following the questionnaire directions, a sample source module can
be generated. The sample source module can then be assembled, link edited, and DEMANDed
through CA Workload Automation CA 7® Edition to begin using workload balancing for real-time
selection of jobs for submission. The workload planning facility can also be helpful in fine-tuning the
objectives definition.
Tape Drives
Tape drives play an important role in determining the completion time of a CPU job. Cross-platform
jobs always have zero tape drive usage. With workload balancing in effect, CA Workload Automation
CA 7® Edition submits a job only when enough tape drives are available and only submits as many
jobs as the available tape drives allow. The tape drives can be of various types: 6250 BPI, 1600 BPI,
800 BPI, 7-track, 9-track, and so forth. CA Workload Automation CA 7® Edition currently controls only
two types at any one time. The user defines what these two types are with the TAPE1 and TAPE2
workload balancing macros and the SASSUTBL module. One particular group of tape drives, based on
the IBM device codes, is considered TYPE1 and the other as TYPE2. Because the default is TYPE1, if
the device code is not defined under either type, it is considered TYPE1.
The following are the objectives in controlling tape drives when the enhanced submission selection is
not active:
To use as many tape drives and initiators as possible simultaneously without going over the
maximum allowable number of either. For example, if two initiators and three tape drives are
available, the objective is to submit two jobs. One job uses one tape drive. The other uses two
tape drives (assuming such jobs are available for submission), rather than one job alone using
three tape drives.
To limit the number of jobs that are submitted so that the total number of tape drives that are
needed does not exceed the maximum number that is allowed to be scheduled, regardless of the
resultant priority. For example, assume the number of tape drives CA Workload Automation CA
7® Edition is allowed to schedule is ten. The number of tape drives currently in use is eight. In this
case, CA Workload Automation CA 7® Edition does not submit any jobs using more than two tape
drives, even when the jobs have high priority.
To limit the jobs using tape drives outside the allowable limits; that is, less than the minimum and
08-Feb-2018 627/722
To limit the jobs using tape drives outside the allowable limits; that is, less than the minimum and
more than the maximum allowable. For example, during a time when you want to discourage
tape drive usage, set the maximum tape drives allowed per job to zero. No jobs needing tape
drives are scheduled. When you want to encourage jobs having heavy tape drive usage
requirements, set a minimum allowable number to a relatively high value. In this way, a job using
fewer tape drives than the minimum value is delayed from submission.
To give a boost to a job that needs many tape drives and is defined as difficult to schedule. For
example, two initiators and seven tape drives are available, and a choice is required among three
jobs. Job A requires three tape drives. Job B requires four. Job C requires seven. Typically, Job A
and Job B are given higher rewards because all tape drives and initiators are used, when both jobs
are submitted. Job C is held back even though enough tape drives and initiators are available. If
having seven tape drives is considered difficult, difficult to schedule (DTS) can be defined as
seven. Job C gets an extra boost, whereas, Job A and Job B get no boost.
When the enhanced submission selection is active, workload balancing selects jobs if the required
numbers of tape drives are available. No attempt is made to maximize the number of jobs submitted.
Jobs are considered in descending job priority order. If a given job needs x tape drives, and at least x
tape drives of the correct type are available, the job is eligible for submission.
More information:
Define the Types of Tape Drives (https://wiki.ca.com/display/CWAC7E

/Define+the+Types+of+Tape+Drives)
CPU Use
Another objective of workload balancing is to balance the CPU cycle use. If the jobs present in the
CPU are process bound jobs, CA Workload Automation CA 7® Edition tries to submit I/O bound jobs
(and conversely) to ensure a balanced mix of jobs. CPU use is not applicable to cross-platform job
types.
The main objective for balancing CPU use is to achieve an ideal CPU use per job.
CPU use is considered the ratio of CPU time to the elapsed time for a job that is expressed as a
percentage. For example, a job needs 6 seconds of actual CPU time in 1 minute of elapsed time. The
job is said to have a CPU use of 10 percent. A simple average of CPU use figures for all jobs active on
the CPU, or actual CPU use per job, is taken. If actual CPU use per job is less than the ideal use per
job, jobs with CPU use higher than actual use get rewards. For example, assume that ideal use per job
is set at 10 percent, and actual is 8 percent. In this case, all jobs with CPU use higher than 8 percent
get rewards. Jobs with less than 8 percent get penalties. Jobs that bring actual use closer to the ideal
use receive higher rewards than others.
Note: Workload balancing does not consider CPU use when the enhanced submission
selection is active.
08-Feb-2018 628/722
Initiators and Job Class Structure

The third objective of CA Workload Automation CA 7® Edition is to consider the number of initiators
available and the job class structure. CA Workload Automation CA 7® Edition fills as many initiators as
possible without going over the allowable number. In doing so, CA Workload Automation CA 7®
Edition again ensures that it does not exceed the maximum number of allowable jobs in each
category or class of jobs. The class code is identical in appearance to OS job classes. The class code is
only used internally within CA Workload Automation CA 7® Edition and does not have to match the
initiator structure or JOB statement class specification. For example, assume that a total of ten
initiators are allocated to jobs running under CA Workload Automation CA 7® Edition, and eight jobs
are already running. In this case, CA Workload Automation CA 7® Edition submits only two more jobs
to the CPU. Again, CA Workload Automation CA 7® Edition selects these two jobs from the classes
whose maximum number running under them has not been reached. It is then possible to control the
total number of jobs running under CA Workload Automation CA 7® Edition and the number of jobs
from each class.
Job Start Times

The next objective of CA Workload Automation CA 7® Edition is to consider how late or early the job
is according to a due-out time and the time available to correct the situation. For example, if two
jobs, Job A and Job B, are both five minutes late, and Job A runs for ten hours while Job B runs for 10
minutes, then CA Workload Automation CA 7® Edition tries to submit Job B ahead of Job A. If both
are five minutes early, CA Workload Automation CA 7® Edition tries to submit Job A ahead of Job B.
If a job is late, it is rewarded. If it is early, it is penalized. A job is not considered late (or early) until it
is late (or early) by a user-defined factor (RUNTF) of its elapsed time. For example, if RUNTF is defined
as 10, then a job that runs for an hour is not rewarded until it is late by 6 minutes or more (60
minutes multiplied by 0.10) or a job that runs for 10 minutes is not rewarded until it is late by one
minute or more (10 minutes multiplied by 0.10). Among the jobs that are late by an equal amount of
time, shorter running jobs are given more reward than longer running jobs. Among the jobs that are
early by an equal amount of time, longer running jobs are given less penalty than shorter running
jobs.
Note: Workload balancing does not consider job start times when the enhanced
submission selection is active.
Threshold Priorities
By using the previous features, either adding rewards or subtracting penalties changes the original
job priority. The resultant priority is compared to the threshold priority. Unless the number of jobs
running on a CPU is less than the specified minimum jobs that must run, the resultant job priority
must be higher than the threshold priority. You must not have any resource constraints for CA
Workload Automation CA 7® Edition to submit that job to a CPU. The objective is clearly the best mix
of jobs that can be submitted. A job can get the highest reward in one category, such as tape drives,
but more penalties in others. The resultant priority is not high enough for the job submission to the
CPU. That job is held back, and others with higher priorities are submitted. This selection of jobs is
clearly beneficial in a situation where work is backlogged due to downtime.
08-Feb-2018 629/722
In order not to hinder the submission of jobs that are of special interest, a special job priority and
special classes for jobs have been provided.
A priority of 255 has been reserved as a special job priority. If a job is given an original priority of 255,
it indicates that the job is important. The relative importance of this job compared others is not
verified. If no resource constraints exist (for example, no tape drives available or no initiators
available), submit the job.
Also, you can define up to three different special job classes with their own threshold priorities.
Change the class of the job that you want to submit ahead of others to one of these special CA
Workload Automation CA 7® Edition classes. For example, the threshold priority is set to 200, and
class B has been defined as a special class with a threshold priority of 50. If two jobs exist, JOBX is in
class C with a resultant priority of 150. JOBY is in class B with a resultant priority of 60. JOBY is
submitted ahead of JOBX, because JOBY belongs to a special class and has a priority higher than its
threshold value.
Note: Workload balancing does not consider threshold priorities when the enhanced
submission selection is active.
Implement WLB
Implementing the workload balancing facility (WLB) is a matter of getting a processing objective in
the form of a load module into the CA Workload Automation CA 7® Edition system. Then, CA
Workload Automation CA 7® Edition can balance the workload to meet the processing objectives of
the data center.
In reality, most installations need more than one processing objective to balance the workload
properly. For example, during business hours, one or more online systems are typically in use. After
business hours, online systems are not needed and so are shut down. This shutdown frees up system
resources to use for additional batch processing. In this case, at least two resource pictures are
needed for WLB to work effectively.
For a sample SMP/E USERMOD to create the module, see member AL2RXXX in the CA Workload
Automation CA 7® Edition Option library (CAL2OPTN).
Follow these steps:
Note: The following are general steps for implementing WLB for each different processing
objective:
1. Analyze the needs and requirements of the environment. A WLB questionnaire is provided to
assist the user in analysis of the environment, determining the needs, and coding the macros.
2. Define the types of tape drives. The system permits two logical classes of tape drives.
08-Feb-2018 630/722
3. Code the WLB macros. Six macros cover the basic resources of the environment, and two
format macros:
WLBPDEF
Identifies the module name, required for format.
TAPE1
Identifies the class of tape drives.
TAPE2
Identifies the class of tape drives.
CPU
Identifies the CPU use.
INITR
Identifies the initiator characteristics.
CLBARR
Identifies the job class barriers.
STARTIME
Identifies the scheduled start time for jobs.
WLBPEND
Required for format.
4. Assemble and link edit the macros creating the module containing the processing objective in
the LOADLIB. The name for this module must begin with the characters UCC7R.
5. Add a job to the database that has a job name that matches the module name created in Step
4. To add a job, proceed as follows:
a. Bring up the DB.1 panel.
b. Enter ADD to select the ADD function.
c. Enter the module name used in WLBPDEF in the JOBNAME field.
No other fields are necessary for the definition. Any job whose name begins with UCC7R is
automatically treated as a nonexecutable job by the system. Whenever the job enters the
queues, only the processing objective criteria is changed.
6. Define a schedule or a trigger for the job added to the database in Step 5. The job scheduling
for a WLB module/job is the same as for any other job. This method avoids having to manually
DEMAND schedule the processing objective when it is needed.
08-Feb-2018 631/722
Define the Selection Parameters

To use the workload balancing facility, the user must supply the processing objectives criteria by
selecting various parameters to CA Workload Automation CA 7® Edition. The criteria defines a virtual
configuration for CA Workload Automation CA 7® Edition to manage. This virtual configuration does
not have to match the actual environment. Consider omitting some resources that are not used for
CA Workload Automation CA 7® Edition jobs. The objectives criteria also let CA Workload Automation
CA 7® Edition know how much reward or penalty to assign to a job under consideration and under
what conditions.
Many different configurations and processing objectives exist. Definitions for different shifts,
weekdays, and weekends are merely a small sample of the types of parameter definitions. CA
Workload Automation CA 7® Edition lets the user define as many different definitions as necessary.
However, only one definition is used at any given time.
CA Workload Automation CA 7® Edition generates these definitions that are based on the parameters
that are defined to the macros provided for this purpose. These generated definitions become
nonexecutable load modules and jobs that are stored in the CA Workload Automation CA 7® Edition
load library and database. The names of these load modules must be names of the format UCC7R xxx
where xxx can be any alphanumeric characters. UCC7RDFL is a reserved name; a default definition
under that name is included on the release tape.
The scheduling feature of CA Workload Automation CA 7® Edition can be used to make different
definitions effective only at specific times. With every workload balancing parameter definition, a
nonexecutable job with the same name as the load module must be added to the database. This
generic job group with names like UCC7Rxxx can have prose, schedules, and triggers, exactly like jobs
in the database. These jobs can be demanded at any time. However, they are never submitted to the
CPU or executed in the initiators. When in the request queue, CA Workload Automation CA 7® Edition
intercepts them. A definition (load module) with the same name is loaded. For example, if job
UCC7R010 is demanded, a UCC7R010 definition is loaded. Whenever CA Workload Automation CA 7®
Edition is active, some definition must be present. In the absence of another definition, the default
definition, UCC7RDFL, provided during the installation, is used.
Note: If the default definition is used, workload balancing is deactivated.
Workload Balancing Questionnaire

This workload balancing questionnaire can help you create a starter objectives definition. By
answering the questions as they apply to your installation and following the workload balancing
questionnaire directions that follow, a sample source module can be generated. That module can
then be assembled, link edited, and DEMANDed through CA Workload Automation CA 7® Edition to
begin using workload balancing for the online selection of jobs for submission. Users find the
workload planning facility helpful in fine-tuning their objectives definition.
Note the following guidance:
Answers to the following questions should relate to one particular time period (shift) that has
08-Feb-2018 632/722
Answers to the following questions should relate to one particular time period (shift) that has
fairly consistent processing characteristics.
The term #nn in the following instructions for creating a workload balancing (WLB) definition
module refers to the question numbers on the preceding questionnaire. Enter the calculated
values in the blanks with corresponding labels on the sample workload balancing objectives
definition.
The following questions relate to tape drive use. If your installation uses two different types of tape
drives (for example, reels and cartridges), answer each question twice, once for each type of tape
drive.
Tape Drive Usage
TYPE 1 TYPE 2

1. How many physical tape drives are available
for CA Workload Automation CA 7® Edition jobs during
this time period? ______ ______

If the answer to #1 is 0, skip to Initiators.

2. What is the average number of drives required per
job (average of "high-water mark" for each job)?
Take into consideration the number of jobs that
do not require tape drives. May be a fractional
value. ______ ______

3. What is the maximum number of tapes that you
would expect any single job to use? ______ ______
Initiators
4. How many initiators are available for job submission
from CA Workload Automation CA 7® Edition during this time frame?

5. Of those initiators available, how many would you
expect to be occupied by CA Workload Automation CA 7® Edition jobs
at any particular time?

6. What is the total maximum percent of CPU use that
CA Workload Automation CA 7® Edition submitted jobs
should occupy? (Consider leaving machine time
available for other online systems, test jobs, and
system overhead.)

7. Are jobs to run during this time frame that have
significantly higher priority than the average job?

8. Do you have jobs that can be run at this time, but that
have such a low priority that you would like to see them
run only if little else is in the system?
Class Barriers
9. Do you have a set of jobs that should not run concurrently
because of file requirements, resource conflicts, or any other
special needs?

10. Are any jobs to be run at this time that are backup to an
online database and that should not be run concurrently with
the online system?

11. Do you have multiple users who share your system and for whom you
want to provide varying levels of service?

12. Will you be using the LOAD command to build database profiles?
If yes, Class 8 must have nonzero count.

13. Will the RUN command be used to schedule certain request type
jobs? If yes, Class 9 must have nonzero count.
Timely Job Completion
14. At a certain point a job is very late and if it is a few more
hours late, it is not more delinquent.
08-Feb-2018 633/722
hours late, it is not more delinquent.

Example: Job A is late by 12 hours. If it does not run for
three more hours, it would still be considered a half
day late. At what point in your shop would you quit
counting how many hours late a job is and just consider
it very late? Maximum of 12 hours.

15. At what point would you stop counting how many hours early a job
is and just consider it very early? Maximum of 12 hours.
Resource Priority
Rate the following statements according to relevance to your shop.
Enter a rating from 0 to 10, 0 being not a concern at all, 10 being
extremely important in your environment.

16. It is important to your shop to balance the initiators with a
good mix of CPU bound and I/O bound jobs.

17. If a job is early, it should not be run until closer to its start
time since it may use resources required by a subsequent job
that is on time.

18. If a job is late it should run as soon as possible, even at the
possible expense of some wasted resources.

TYPE 1 TYPE 2
19. It is important not to overschedule tape drives,
possibly causing a job to wait in an initiator
(or JES3 queue) until tape units can be
allocated. ______ ______

20. It is important to maximize use of available
tape drives. ______ ______
Sample Workload Balancing Objectives Definition

The following is a sample workload balancing objectives definition.
PRINT NOGEN
WLBPDEF MODNAME=_________, 3 characters, no default X
VRSN=_________ 3 digits, informational
*
TAPE1 NAME=__________, 8 characters, informational X
TOTAV=__________, 0-255, default=0 X
MXREW=__________, 0-255, default=20 X
MXPEN=__________, 0-255, default=20 X
MNDTS=__________, 0-255, < MXDTS, default=0 X
MXDTS=__________, 0-255, > MNDTS, default=0 X
MXBST=__________, 0-255, default=0 X
MNJAL=__________, 0-255, < MXJAL, default=0 X
MXJAL=__________, 0-255, > MNJAL, default=0 X
MXTAL=__________ 0-255, not < TOTAV, default=12
*
TAPE2 NAME=__________, 8 characters, informational only X
TOTAV=__________, 0-255, default=0 X
MXREW=__________, 0-255, default=20 X
MXPEN=__________, 0-255, default=20 X
08-Feb-2018 634/722
MXPEN=__________, 0-255, default=20 X
MNDTS=__________, 0-255, < MXDTS, default=0 X
MXDTS=__________, 0-255, > MNDTS, default=0 X
MXBST=__________, 0-255, default=0 X
MNJAL=__________, 0-255, < MXJAL, default=0 X
MXJAL=__________, 0-255, > MNJAL, default=255 X
MXTAL=__________ 0-255, not < TOTAV, default=12
*
CPU IDLUT=__________, 0-100, default=8 X
MXREW=__________, 0-255, default=20 X
MXPEN=__________ 0-255, default=20
*
INITR TOTAV=_________, 0-255, default=10 X
MNJOB=__________, 0-255, default=255 X
JPTHR=__________, 0-255, default=100 X
SPCLS1=_________, (x,yyy), default (yyy) = 100 X
SPCLS2=_________, same as SPCLS1 X
SPCLS3=_________ same as SPCLS1 X
*
CLBARR BARA=________, 0-255, default=255 X
BARB=___________, same default=255 X
BARC=___________, same default=255 X
etc...
BAR9=___________ same default=255
*
STARTIME MXLAT=_________, 0-255, default=12 X
MXERL=__________, 0-255, default=12 X
MXREW=__________, 0-255, default=20 X
MXPEN=__________, 0-255, default=20 X
RUNTF=__________ 0-100, default=10
*
WLBPEND
END
Use CLBARR
The CLBARR macro defines class barriers for CA Workload Automation CA 7® Edition job classes.
BARx
If the answer to #9 is yes, you can put those jobs into the same class on the job definition panel
and can set a class barrier of one to single-thread those jobs through the system. For example, if
several jobs that affect a particular disk pack heavily are given a class C on their job definition
panels by specifying BARC=1 to WLB, only one of those jobs runs at a time.
If the answer to #10 is yes, you can overcome a scheduling problem using class barriers in
combination with scheduling of different WLB definitions. Assume that your online system (that
might or might not be under CA Workload Automation CA 7® Edition control) has a scheduled
downtime from 1:00 a.m. to 5:00 a.m. daily for backup purposes. You have a backup program
08-Feb-2018 635/722
downtime from 1:00 a.m. to 5:00 a.m. daily for backup purposes. You have a backup program
that runs under CA Workload Automation CA 7® Edition with a class D on the job definition panel
and has an elapsed time of three hours. If the backup does not enter the system by 2:00 a.m., it
cannot be run until tomorrow's downtime. A WLB definition module specifying BARD=1 can be
scheduled for 1:00 a.m. and a separate WLB definition module specifying BARD=0 can be
scheduled for 2:00 a.m. daily. This allows the backup program to enter the system only between 1:
00 and 2:00 a.m.
If the answer to #11 is yes, you might classify each user by class on the job definition panel and
control the amount of access each class receives. For example, user 1 represents a large portion
of your site's revenue, so you set user 1's class barrier higher than that of user 2, who accounts
for a small percentage of your business, but whose jobs might come in sporadically.
Use CPU
CPU is not used when the enhanced submission selection is active.
IDLUT
Divide the answer to #6 by #4 to give ideal CPU use per CA Workload Automation CA 7® Edition
job. If the value of #4 is much larger than #5, use the value of #5 instead of #4 (IDLUT = #6 / #4).
MXREW
Multiply #16 by 3 for maximum reward for ideal CPU use (MXREW = #16 X 3).
MXPEN
Use the same value as MXREW (MXPEN = MXREW).
Use INITR
Only the TOTAV value is used when the enhanced submission selection is active.
TOTAV
Enter the answer to #4.
MNJOB
The purpose of MNJOB is to discourage idle hardware and CA Workload Automation CA 7®
Edition withholding jobs from submission because they do not meet the JPTHR value specified.
When the number of CA Workload Automation CA 7® Edition jobs on the system falls below this
value, the relative priority of jobs ready to submit is ignored. They are submitted on a first come
first serve basis (within physical restraints such as tape drive availability) until the number of jobs
on the system exceeds MNJOB. To start, use (MNJOB = #4 / 2).
This value is obtained by observing machine idleness compared to CA Workload Automation CA
7® Edition ready queue backlog in your production environment. Begin with the value calculated
above and adjust it according to your installation's performance.
JPTHR
The priority that is derived by WLB reward/penalty calculations should reflect that job's impact on
the mix of jobs currently running on the CPU. A job's final priority is the sum of the WLB rewards
and penalties and the job's original priority, assigned on the job definition panel. JPTHR is the
threshold of priority below which an average job is considered "too bad" for the current job mix
to submit unless MNJOB is not exceeded. A value of 75 is recommended for an initial value
because the average job enters the queues with the default priority of 100. It must incur a net
penalty from WLB of 25 or more to fall below this value (JPTHR=75).
SPCLS1/SPCLS2/SPCLS3
08-Feb-2018 636/722
SPCLS1/SPCLS2/SPCLS3
If the answer to #7 is yes, you might want to categorize jobs of higher priority into a class (not
necessarily related to job class) designated by A through Z, 0 through 9 on the job definition
panel. You should also give the job a higher job priority on the job definition panel. The average
job receives a default priority of 100. The default or user-specified job priority is added as a WLB
reward as the jobs enter the queues. JPTHR is set at 25 percent below the original priority of the
average job. For SPCLSx jobs of higher priority, you may want an even lower threshold that is
specified as SPCLSx=(Y,0) where x is 1, 2 or 3, Y is the class assigned for that particular group of
jobs and 0 is that class's threshold priority. Keep in mind that the default class for those jobs
considered average is A.
If the answer to #8 is yes, you can enter a lower than average job priority on the job definition
panel and can specify SPCLSx=(Y,150). This is to ensure, for example, that the job is submitted
only if it has received enough rewards from WLB for CPU and tape use so that it is considered
good for the current job mix on the system. Or to ensure that if it became so late, the reward
would push it over its threshold.
Use STARTIME
The STARTIME values are not used when the enhanced submission selection is active.
MXLAT
Enter the value that is assigned to #12 for the point past that a job receives no more than the
maximum reward for being late.
MXERL
Enter the value that is assigned to #13 for the point before which a job receives no more than the
maximum penalty for being early.
MXREW
Enter the value in #18 multiplied by 3 for the maximum reward a job receives for being late
(MXREW = #18 X 3).
MXPEN
Enter the value in #17 multiplied by 3 for the maximum penalty to assign to a job for being early
(MXPEN = #17 X 3).
RUNTF
Runtime factor is the percentage of job elapsed time that is used as leeway in calculating whether
a job is late. This leeway allows a job that runs for 10 minutes, and that is 10 minutes late, to run
ahead of a job that runs two hours and that is also 10 minutes late. The first job receives a reward
for lateness, while the second job does not. RUNTF=10 is recommended and is the default. If
varying this value seems to help overall job timeliness in your installation, it can be manipulated.
Use TAPE1/TAPE2
Only the NAME and TOTAV values are used when the enhanced submission selection is active.
NAME
This entry can be up to eight characters in length and is informational only.
TOTAV
Enter the value given in question #1.
MXREW
08-Feb-2018 637/722
MXREW
Enter the answer to question #18 multiplied by 3 (MXREW = #18 X 3).
MXPEN
Enter the answer to question #17 multiplied by 3 (MXPEN = #17 X 3).
MNDTS
Enter a value over halfway between #2 (average drives/job) and #3 (maximum number of drives
required/job).
(MNDTS = ((#3 - #2)/2) + #2)
MXDTS
Enter the value given for #3 (maximum drives/job).
MXBST
Tape rewards tend to be higher for jobs requiring smaller numbers of drives to use both tapes
and initiators. If many drives are available, you may want to boost a job requiring many drives.
Ideally, the larger #3 (maximum drives/job) is, the larger MXBST should be. It should also be
related to MXREW because that value reflects the relative importance of tape scheduling in your
installation. Also, the more overscheduled your tapes drives tend to be ((#5 X #2) as compared to
#1), the higher you would want to boost. The following calculation takes these factors into
account in figuring an MXBST value. Start with this value. If it is not enough to get a large tape job
scheduled when the right number of drives is available, you may want to increase it.
(MXBST = (MXDTS + ((#5 - 1) X #2)) X MXREW / #1)
MNJAL
MNJAL and MXJAL are most useful as real-time adjustments to the WLB definition. MNJAL can be
raised temporarily, using the XWLB panel, in a situation where none of the large tape jobs can
break into the system because small tape jobs are taking up the slack. Begin your definition with
MNJAL=0.
MXJAL
Enter the answer to #3. If large tape jobs are dominating all drives and jobs requiring few drives
are not moving through the system at a high enough rate, lower MXJAL temporarily using the
XWLB panel.
Note: Jobs with tape requirements falling below MNJAL or above MXJAL are not scheduled
at all. The system disregards rewards and penalties related to lateness, CPU use or difficult-
to-schedule tape requirements for such jobs.
MXTAL
This value allows for overscheduling of physical tape drives to take up the slack on the system
created by variances between job step requirements for tape drives. Begin with the values
suggested below. If tape jobs are consistently waiting in the system initiators for tape drive
allocation, lower MXTAL (MXTAL = (1.25 X #1) or (#4 X #2), whichever is smaller).
Use WLBPDEF
The WLBPDEF macro provides a name and version number to a definition. The WLBPDEF macro is
required and must be coded first; however, only code one macro per module.
08-Feb-2018 638/722

WLBPDEF MODNAME=xxx[,VRSN={000|nnn}]
MODNAME
Specifies the last three characters of the name of a definition. The value must be alphanumeric.
The name of the definition, then, becomes UCC7Rxxx. Do not use MODNAME=DFL for a user-
defined objectives definition because this value indicates the default, and the objectives are
ignored when selecting a job for submission.
VRSN
Specifies the optional version number, if any. The value must be numeric from 000 to 999. The
default is 000. This field is for information only.
Example: Supply a name and version number
This example provides UCC7RSAT as the name of the generated definition and 001 as the version
number.
WLBPDEF MODNAME=SAT,VRSN=001
Define Tape Drive Types

The module SASSUTBL defines a table of units and device codes. Make extra entries for device codes
that are treated as TAPE1 or TAPE2. The following format is for the statement that adds entries to
SASSUTBL:
column
10 16
| |

DC CL8'xxxxxxxx',XL4'yyyyyyyy'
CL8'xxxxxxxx'
Indicates a required generic unit name that can be up to eight characters. If CL4'DASD' is used
instead of XL4'yyyyyyyy', this value is a volume serial number for data sets that are classified as
DASD.
XL4'yyyyyyyy'
Indicates an eight-character, hexadecimal device code, as defined in the operating system device
name table.
You can specify a reserved value of CL4'DASD' in place of the XL4' yyyyyyyy'. CL4'DASD' indicates
that this entry refers to a volume serial number or unit name that is classified as DASD instead of
tape.
Note: CA Workload Automation CA 7® Edition always treats the ddnames of JOBLIB,

STEPLIB, JOBCAT, and STEPCAT as DASD.
Examples
This example assumes four 2400s and four 3400s are to be TAPE1 and one 3420 is to be TAPE2. The
entries can appear as follows, depending on the SYSGENed device codes:
08-Feb-2018 639/722
column
10 16
| |

DC CL8'TAPE1',X'30808001' 2400
DC CL8'TAPE1',X'30C08001' 2400
DC CL8'TAPE1',X'34008001' 2400
DC CL8'TAPE1',X'34208001' 2400
DC CL8'TAPE1',X'30808003' 3400
DC CL8'TAPE1',X'30C08003' 3400
DC CL8'TAPE1',X'34008003' 3400
DC CL8'TAPE1',X'34208003' 3400
DC CL8'TAPE2',X'32108003' 3420
DC X'FFFF'
Note: You must have an x'FFFF' terminator as the last entry.
When the hex device code or the IBM SYSGENed esoteric value is not known, a user-defined value
can be specified as the hex device code for that unit. Make the third byte of the value a hex 80 to
indicate a tape device. The CA Workload Automation CA 7® Edition LOC command can be used to
display the device codes for any currently cataloged data sets.
This same user-defined hex entry must then be placed in SASSUTBL with a unit name of TAPE1 or
TAPE2. For example:
UNIT=CART is coded in the JCL, rather than UNIT=3480
The esoteric SYSGENed value for CART is not known
Treat CART as a TAPE2 device. Then,

DC CL8'CART',X'77778077'
DC CL8'TAPE2',X'77778077'
In this example, any generic unit in SASSUTBL coded with a device code of X'77778077' is considered
a TAPE2 device by CA Workload Automation CA 7® Edition during the load process. The entry for
TAPE2 cannot precede the generic unit (CART in this example).
In place of using TAPE1 or TAPE2, the value TAPE99 can be specified to cause CA Workload
Automation CA 7® Edition to treat a tape data set as being DASD and not count it as either TAPE1 or
TAPE2. The following cause data sets using UNIT=CART to be treated as DASD files instead of
counting as a tape file:
DC CL8'CART',X'77778077'
DC CL8'TAPE99',X'77778077'
At some sites, disk data sets can be archived to tape. The data sets should be classified as DASD, but
the hex device code indicates TAPE. An entry can be specified in SASSUTBL to cause any data sets
using a specified volume serial number to be classified as DASD instead of TAPE. Also, you can code
entries to cause specific esoteric unit names to be classified as DASD. Code the SASSUTBL entries
using the DASD designation before any other entries.
DC CL8'ARCHIV ',CL4'DASD' IF VOLSER=ARCHIV, ASSUME DASD
DC CL8'MIGRAT ',CL4'DASD' IF VOLSER=MIGRAT, ASSUME DASD
DC CL8'SYS348XR',CL4'DASD' IF UNIT IS SYS348XR, ASSUME DASD
08-Feb-2018 640/722
Code WLB Macros

The generation of workload balancing parameter definitions is accomplished through the assembly of
the following special macros:
WLBPDEF
Module name, which is required for format
TAPE1
Class of tape drives
TAPE2
Class of tape drives
CPU
CPU use
INITR
Initiator characteristics
CLBARR
Job class barriers
STARTIME
Scheduled start time for jobs
WLBPEND
Required for format
The user must identify the different virtual configurations and processing objectives that are required
in terms of macro parameter values. An assembly and link edit generate a definition and stores it as a
nonexecutable load member in the CA Workload Automation CA 7® Edition load module library. (Do
not use a PARM of RENT or REUS with the link edit.) A permanent change requires the coding and
assembling of macros before an online session of CA Workload Automation CA 7® Edition is started.
Once the online session is started, temporary changes can be made with the XWLB and /WLB
commands. These changes, however, are only temporary and do not affect the definition in the load
library. The next UCC7Rxxx definition that is loaded erases them.
Coding Rules
The WLBPDEF macro is required and must be coded first. The WLBPEND macro is also required and
must be coded last. The other macros are optional and can be coded in any order. Coding rules for
macros are as follows:
The macro name must begin between columns 2 and 16.
At least one blank must exist between the macro name and the first parameter, if coded.
A nonblank character in column 72 indicates continuation of any macro statement. Macro

parameters and values can appear through column 71 with no blanks. All continuation
statements must begin in column 16. Keyword values can be broken for continuation at a comma.
(This method is a standard assembler continuation.)
08-Feb-2018 641/722
The detailed descriptions of these macros follow.
For assistance in creating the WLB macros, see the workload balancing objectives definition. The
definition is created when the workload balancing questionnaire is completed.
CLBARR
The CLBARR macro defines class barriers for CA Workload Automation CA 7® Edition job classes. Each
class barrier establishes the maximum number of jobs that can be submitted concurrently in the
associated job class. The CLBARR macro is optional and can be coded anywhere between the
WLBPDEF and WLBPEND macros; however, only code one macro per module.

CLBARR [BARx={255|nnn},...]
BARx
Indicates a barrier value for class x (defined by the SPCLS1 keyword for INITR) can have a value of
A through Z or 0 through 9. The parameter value must be numeric and from 0 through 255. A
value of 255 indicates no limit. Multiple barrier values can be specified. The default is 255 for
each.
Example
This example limits CA Workload Automation CA 7® Edition to only five jobs running under class A
and only one job running under class 2. No job under class Z is ever submitted. In other classes, CA
Workload Automation CA 7® Edition can have up to 255 jobs running.
CLBARR BARA=5,BAR2=1,BARZ=0
Note: Jobs entering the request queue through a RUN command are assigned job class 9.
LOAD jobs are assigned job class 8.
CPU
The CPU macro provides information about CPU use. CPU is optional and can be coded anywhere
between the WLBPDEF and WLBPEND macros; however, only code one macro per module.
The CPU macro is not used when the enhanced submission selection is active.

CPU [IDUT={8|nnn}]
[,MAXREW={20|nnn}]
[,MXPEN{20|nnn}]
IDLUT
Indicates the value of an ideal CPU use per job that is expressed as a percentage. The value must
be numeric and from 0 through 100. The product of the values that are specified by this keyword
and by TOTAV in the INITR macro (following) must not be greater than 100. The default is 8.
MXREW
08-Feb-2018 642/722
MXREW
Indicates the maximum reward to give to a job. The value must be numeric and from 0 to 255.
The default is 20.
MXPEN
Indicates the maximum penalty to give to a job. The value must be numeric and from 0 to 255.
The default is 20.
Example: Set ideal CPU use, maximum penalty, and maximum reward
This example indicates that CA Workload Automation CA 7® Edition is to submit jobs so that the
percent CPU use per job is as close to 10 percent as possible. The job that would bring the CPU use
per job closest to 10 percent gets the highest reward of 15 points. The job that would take the CPU
use per job farthest from 10 percent (on either side) is penalized a maximum of ten points.
CPU MXREW=15,MXPEN=10,IDLUT=10
INITR
The INITR macro provides information about initiators. The INITR macro is optional. You can code the
macro anywhere between the WLBPDEF and WLBPEND macros; however, only code one macro per
module.

INITR [TOTAV={10|nnn}]
[,MNJOB={255|nnn}]
[,JPTHR={100|nnn}]
[,SPCLS1={100|(x,yyy)}]
[,SPCLS2={100|(x,yyy)}]
[,SPCLS3={100|(x,yyy)}]
Only the TOTAV value is used when the enhanced submission selection is active.
TOTAV
Indicates the total initiators available for CA Workload Automation CA 7® Edition. The value must
be numeric and from 0 through 255. A value of 255 indicates no limit. The product of the values
that are specified by this keyword and by IDLUT in the CPU macro must not be greater than 100.
The default is 10.
MNJOB
Indicates the minimum number of jobs that are submitted concurrently by CA Workload
Automation CA 7® Edition. If the current number of jobs that are submitted to the CPU falls below
this value, jobs are submitted from the ready queue on a first in, first out basis within resource
limits but regardless of priority calculations, until the total number of submitted jobs equals the
MNJOB=value. The value must be numeric and from 0 through 255. The default is 255.
JPTHR
Indicates the default threshold priority. This value applies to all classes of jobs except any class
specified in SPCLS1, SPCLS2, or SPCLS3. The threshold priority is the minimum calculated priority
that any job must have for submission. Even if a job has the highest priority of those jobs ready
for submission, if it is below the threshold for its class, it is not selected as the best job to run
then. Therefore, another class of jobs with a lower priority threshold is given preference for
submission. The value must be numeric and from 0 through 255. The default is 100.
08-Feb-2018 643/722
SPCLS1
Indicates the first special class and threshold priority.
x
Indicates the job class. The value must be a single alphanumeric character (A through Z or 0
through 9). No default.
yyy
Indicates the threshold priority that is associated with that class. The value must be numeric
and from 0 through 255. The default is 100.
The LOAD jobs are assigned job class 8.
SPCLS2
Indicates the second special class and threshold priority.
x
yyy
SPCLS3
Indicates the third special class and threshold priority.
x
yyy
Example: Set INITR values
08-Feb-2018 644/722
This example indicates that CA Workload Automation CA 7® Edition can have up to 10 jobs running at
a time. If the number of jobs running on a CPU under CA Workload Automation CA 7® Edition control
is less than two, CA Workload Automation CA 7® Edition does not examine the threshold priority until
two jobs are running on the CPU. CA Workload Automation CA 7® Edition checks for any resource
constraints (no initiators available, no tape drives available, and so forth). When at least two jobs are
running, CA Workload Automation CA 7® Edition does not submit any job from classes other than B
and zero, unless the job priority (after all rewards and penalties are calculated) is 200 or more, and
no resource constraints exist. If the job is from class B, the job priority must be 50 or above; if from
class zero, 100 or above.
INITR TOTAV=10,MNJOB=2,JPTHR=200,SPCLS1=(B,50), X
SPCLS2=(0,100)
STARTIME
The STARTIME macro provides information about the relative importance of the scheduled start time
for a job. This macro is optional and can be coded anywhere between the WLBPDEF and WLBPEND
macros; however, only code one macro per module.
The STARTIME macro is not used when the enhanced submission selection is active.

STARTIME [MXLAT={12|nnn}]
[,MXERL={12|nnn}]
[,MXREW={20|nnn}]
[,MXPEN={20|nnn}]
[,RUNTF={10|nnn}]
MXLAT
Indicates maximum hours a job is considered late for the reward calculation. If a job is late by
more hours than this value, it has the same effect as if it is late by maximum hours. That is, it
receives the maximum reward (MXREW) for being late. Must be numeric and from 0 through 255.
The default is 12 hours.
MXERL
Indicates maximum hours a job is considered early for the penalty calculation. If a job is early by
more hours than this value, it has the same effect as if it is early by maximum hours. That is, it
receives the maximum penalty (MXPEN) for being early. Must be numeric and from 0 through
255. The default is 12 hours.
MXREW
Indicates the maximum reward to give a job that is late, based on the maximum number of hours.
Must be numeric and from 0 through 255. The default is 20.
MXPEN
Indicates the maximum penalty to give a job that is early by the maximum number of hours. Must
be numeric and from 0 through 255. The default is 20.
RUNTF
The run-time factor defines a tolerance to allow in determining whether a job is late or early. The
factor is expressed as a percentage of the estimated job elapsed time. The factor must be
numeric and range from 0 to 100. The default value is 10 (for 10 percent). A value of 0 indicates
allow no tolerance.
Examples
08-Feb-2018 645/722
Examples
This example indicates that if a job is late by six or more hours, the reward is 30 points. For a job that
is late between 0 and 6 hours, the reward is proportionate based on the run-time factor (RUNTF). For
example, if late by three hours, the reward is 15. If late by one hour, reward is five. If a job is early by
10 or more hours the penalty is 10 points. If a job is five hours early the penalty is five points. If early
by 15 hours the penalty is 10 points. By default, the run-time factor is ten. This means that a ten-hour
running job is not considered late (and hence rewarded) unless it is late by one or more hours. A five-
hour running job is not considered early (and hence penalized) unless it is early by 30 minutes or
more.
STARTIME MXREW=30,MXPEN=10,MXLAT=6,MXERL=10
TAPE1
The TAPE1 macro provides information about tape drives of TYPE1. The TAPE1 macro is optional and
can be coded anywhere between the WLBPDEF and WLBPEND macros. Only code one macro per
module.

TAPE1 [NAME={TAPEDR1|xxxxxxxx}]
[,TOTAV={10|nnn}]
[,MAXREW={20|nnn}]
[,MXPEN={20|nnn}]
[,MNDTS={0|nnn}]
[,MXDTS={0|nnn}]
[,MXBST={0|nnn}]
[,MNJAL={0|nnn}]
[,MXJAL={255|nnn}]
[,MXTAL={12|nnn}]

NAME
Provides a name for TYPE1 that can be up to eight characters in length. For information only. The
default is TAPEDR1.
TOTAV
Indicates the total number of TYPE1 tape drives available for scheduling. The value must be
numeric, from 0 to 255, and not higher than the value specified by MXTAL. The default is 10.
MXREW
Indicates the maximum reward to give to a job using TYPE1 tape drives. The value must be
numeric and from 0 to 255. The default is 20.
MXPEN
Indicates the maximum penalty to give to a job using TYPE1 tape drives. The value must be
MNDTS
Indicates the minimum number of tape drives considered difficult to schedule. The value must be
numeric and from 0 to 255, and must not be higher than the value specified by MXDTS. The
default is 0.
08-Feb-2018 646/722
MXDTS
Indicates the maximum number of tape drives that are considered difficult to schedule. The value
must be numeric, from 0 to 255, and not less than the value specified by MNDTS. The default is 0.
MXBST
Indicates the maximum boost to add to the reward given to a job for difficult to schedule
numbers for TYPE1 tape drives. The value must be numeric and from 0 to 255. The default is 0.
MNJAL
Indicates the minimum number of TYPE1 tape drives allowed to be scheduled per job. The value
must be numeric, from 0 to 255, and not higher than the value specified by MXJAL. The default is
0.
MXJAL
Indicates the maximum number of TYPE1 tape drives allowed to be scheduled per job. The value
must be numeric, from 0 to 255, and not less than the value specified by MNJAL. The default is
255.
MXTAL
Indicates the total number of TYPE1 drives that can be scheduled. The value must be numeric,
from 0 to 255, and not less than the value specified by TOTAV. The default is 12.
Example
This example indicates that 20 TYPE1 tape drives under the name TAPEDR1 are available for
scheduling, although CA Workload Automation CA 7® Edition can schedule up to 25 tape drives at any
one time. If a job uses more than ten tape drives, do not schedule that job even if the priority is
highest. Under the most favorable conditions, give a maximum reward of 20 points to a job. Under
the most unfavorable conditions, subtract 15 points from the priority of a job.
TAPE1 TOTAV=20,MXTAL=25,MXREW=20,MXPEN=15, X
MXJAL=10,MNJAL=0
TAPE2
The TAPE2 macro provides information about TYPE2 tape drives. The TAPE2 macro is optional. You
can code the macro anywhere between the WLBPDEF and WLBPEND macros; however, only code
one macro per module.

TAPE2 [NAME={TAPEDR2|xxxxxxxx}]
[,TOTAV={10|nnn}]
[,MAXREW={20|nnn}]
[,MXPEN={20|nnn}]
[,MNDTS={0|nnn}]
[,MXDTS={0|nnn}]
[,MXBST={0|nnn}]
[,MNJAL={0|nnn}]
[,MXJAL={255|nnn}]
[,MXTAL={12|nnn}]

08-Feb-2018 647/722
NAME
Provides a name for TYPE2 tape drives that can be up to eight characters in length. The name is
for information only. The default is TAPEDR2.
TOTAV
Indicates the total number of TYPE2 tape drives available for scheduling. The value must be
numeric, from 0 to 255, and not higher than the value specified by MXTAL. The default is 10.
MXREW
Indicates the maximum reward to give to a job using TYPE2 tape drives. The value must be
MXPEN
Indicates the maximum penalty to give to a job using TYPE2 tape drives. The value must be
MNDTS
Indicates the minimum number of tape drives considered difficult to schedule. The value must be
numeric, from 0 to 255, and not higher than the value specified by MXDTS. The default is 0.
MXDTS
Indicates the maximum number of tape drives considered difficult to schedule. The value must be
numeric, from 0 to 255, and not less than the value specified by MNDTS. The default is 0.
MXBST
Indicates the maximum boost to add to the reward given to a job using difficult to schedule
numbers for TYPE2 tape drives. The value must be numeric and from 0 to 255. The default is 0.
MNJAL
Indicates the minimum number of TYPE2 tape drives allowed to be scheduled per job. The value
must be numeric, from 0 to 255, and not higher than the value specified by MXJAL. The default is
0.
MXJAL
Indicates the maximum number of TYPE2 tape drives allowed to be scheduled per job. The value
must be numeric, from 0 to 255, and not less than the value specified by MNJAL. The default is
255.
MXTAL
Indicates the total number of TYPE2 drives that can be scheduled. The value must be numeric,
from 0 to 255, and not less than the value specified by TOTAV. The default is 12.
Example
This example indicates that the name of the group of tape drives is 1600 BPI for information and
report headings only. Only three tape drives are available for scheduling. CA Workload Automation
CA 7® Edition cannot schedule more than three tape drives at any time. No job is to be held back
because of minimum/maximum tape drives. Maximum reward and penalty are both 20 (default
value).
TAPE2 NAME=1600BPI,TOTAV=3,MXTAL=3,MNJAL=0
08-Feb-2018 648/722
WLBPDEF
The WLBPDEF macro provides a name and version number to a definition. The WLBPDEF macro is
required and must be coded first; however, only code one macro per module.

WLBPDEF MODNAME=xxx[,VRSN={000|nnn}]
MODNAME
Specifies the last three characters of the name of a definition. The value must be alphanumeric.
The name of the definition, then, becomes UCC7Rxxx. Do not use MODNAME=DFL for a user-
defined objectives definition because this value indicates the default, and the objectives are
ignored when selecting a job for submission.
VRSN
Specifies the optional version number, if any. The value must be numeric from 000 to 999. The
default is 000. This field is for information only.
Example: Supply a name and version number
This example provides UCC7RSAT as the name of the generated definition and 001 as the version
number.
WLBPDEF MODNAME=SAT,VRSN=001
WLBPEND
The WLBPEND macro indicates the end of a workload balancing parameter definition. The WLBPEND
macro is required and must be coded last; however, only code one macro per module.

WLBPEND
WLBPEND has no other keywords.
Generate WLB Definitions and Modules

CA Workload Automation CA 7® Edition generates definitions that are based on the parameters that
are defined to the WLB macros provided for this purpose. These generated definitions become
nonexecutable load modules and are stored in the CA Workload Automation CA 7® Edition load
module library. The names of these load modules must be names in the format UCC7R xxx where xxx
can be any alphanumeric characters. Begin no other jobs with these same five characters. UCC7RDFL
is a reserved name for the default definition module that is included on the CA Workload Automation
CA 7® Edition installation media.
The following example displays an entire workload balancing parameter definition for the sample
module UCC7R010. (A PRINT NOGEN is suggested because the macro expansions can be lengthy.)
column
10 16 72
| | |
PRINT NOGEN
08-Feb-2018 649/722
PRINT NOGEN
WLBPDEF MODNAME=010
TAPE1 NAME=TYPE1, X
TOTAV=25,MAXTAL=30, X
MXREW=20,MXPEN=20, X
MNJAL=0,MXJAL=6, X
MNDTS=4,MXDTS=6,MXBST=10
CPU MXREW=20,MXPEN=20,IDLUT=5
INITR TOTAV=12,MNJOB=3,JPTHR=100
CLBARR BARA=10,BARB=2
STARTIME MXLAT=6,MXERL=6,RUNTF=10, X
MXREW=20,MXPEN=20
WLBPEND
END
For a sample SMP/E USERMOD to create the module, see member AL2RXXX in the CA Workload
Automation CA 7® Edition Options library (CAL2OPTN).
Schedule WLB Modules

WLB modules can be scheduled like any other job in CA Workload Automation CA 7® Edition. With
every workload balancing parameter definition, a job with the same name as the load module must
be added to the database. These job names must begin with UCC7R followed by three unique
characters. When a certain WLB definition is to be in effect, the job can be demanded in.
WLB modules can have a calendar-based schedule. WLB modules can be triggered (by either job
completion, network completion or data set creation). WLB modules can be demanded. When all
requirements are satisfied, the WLB definition with the same name as the job name is loaded. The
criteria defined in that load module is in effect. The UCC7R job immediately goes through normal job
completion and is never submitted to JES.
At all times that CA Workload Automation CA 7® Edition is active, some definition must be present. In
the absence of another definition, the default definition, UCC7RDFL, provided with the release tape,
is used.
Note: If you are using the default definition, UCC7RDFL, none of the workload balancing
procedures is in effect.
Job names beginning with UCC7R are reserved for workload balancing. If a job beginning with UCC7R
enters the request queue, CA Workload Automation CA 7® Edition attempts to find a load module
with that name to use as the new workload balancing module. If unable to find it, message SCRJ-60 is
issued to the master station. The job remains in the request queue with a master count of one and a
condition code of zero.
A SUBMIT time requirement can be established for the WLB module, and then the module is not in
effect until that SUBMIT time is satisfied.
08-Feb-2018 650/722
UNIX System Services Interface Communications

The UNIX System Services Interface provides a means to communicate with CA Workload Automation
CA 7® Edition from the UNIX environment on z/OS. Two CA Workload Automation CA 7® Edition
modules must reside on the UNIX file system to help ensure proper execution of the interface. The
modules are CA7OECOM and CA7OESTB. This topic outlines the steps necessary to install the
interface.
Copy the CA7OECOM module to the UNIX file system (HFS). The module resides in the CA Workload
Automation CA 7® Edition installation CAL2OPTN in object format. Copy the module to the UNIX file
system (HFS) using the IBM TSO/E OPUT command. See the following example:
OPUT 'CA7.INSTALL.CAL2OPTN)(CA7OECOM)' '/users/bin/ca7oecom.o' BINARY
OPUT
The command that is used to copy objects to the UNIX file system.
'CA7.INSTALL.CAL2OPTN)(CA7OECOM)'
This name is the data set where the CA7OECOM member resides.
'/users/bin/ca7oecom.o'
This name is the path where the object module is copied. The ca7oecom.o specification, in
lowercase, identifies the module name when it is copied to the UNIX file system. The ".o"
extension on the file name is required.
BINARY
This option indicates that the object contains binary data and to copy it as such. This option is
required.
Once the CA7OECOM object is copied to the UNIX file system, it must be link edited into executable
format. The CA Workload Automation CA 7® Edition installation JCL file (CAL2JCL) contains a member
AL2USSLK that can be used to perform the link edit. Modify the AL2USSLK JCL to your installation
standards before execution. The JCL executes the IBM BPXBATCH program, which is the batch
interface to UNIX System Services. The PARM passed to the program contains a link-edit command.
Modify the command to include the path (location) of the ca7oecom.o object you copied in the
previous step.
PARM='sh c89 -v -o /xxxxxx/xxxx/ca7oecom /xxxxxx/xxxx/ca7oecom.o'
The /xxxxxx/xxxx/ca7oecom indicates the path where the executable ca7oecom resides after the link
edit and what the executable name is (ca7oecom). The /xxxxxx/xxxx/ca7oecom.o indicates the path
or location to the ca7oecom.o object that is copied to the UNIX file system in the previous step.
The next step is to copy module CA7OESTB to a PDS/E library and then copy it from the PDS/E to the
UNIX file system. This procedure creates an object of the executable and prepares it for execution on
the UNIX file system. The JCL library (CAL2JCL) member AL2USSCP contains JCL that can be used to
allocate a PDS/E. Then copy the module CA7OESTB from CAL2LOAD to the PDS/E. Once the module
resides in a PDS/E, you can copy the module to the UNIX file system. Use the TSO/E OPUT command.
See the following example:
OPUT 'CAI.PDSE.LOAD(CA7OESTB)' '/users/bin/ca7oestb' BINARY
08-Feb-2018 651/722
File Permissions for UNIX

In a UNIX environment, a set of permissions that are associated with a file determine file security.
Mark the CA Workload Automation CA 7® Edition Interface modules as "executable" to let users
invoke the interface. The following example output is from a "ls -l" command (List). The example
shows the file permissions that are associated with the two interface modules. You can use the UNIX
"chmod" command to change file permissions.
-rwx--x--x 1 U01USER AWORKSG 65600 Jul 6 20yy ca7oecom
-rwx--x--x 1 U01USER AWORKSG 4096 Feb 3 16:16 ca7oestb
MSMR - Route Master Station (Browse) Messages

CA Workload Automation CA 7® Edition sends many important messages to the master station. They
include messages about CA Workload Automation CA 7® Edition job status and CA Workload
Automation CA 7® Edition system activities such as schedule scan and job submission. In the typical
configuration, the master station is associated with a sequential file known as the browse data set.
Once these messages are written to the browse data set, they can be routed to Unicenter Event
Consoles or to CA OPS/MVS® Event Management and Automation. The feature is known as Master
Station Message Routing (MSMR).
Implement MSMR
To activate MSMR, create an MSMR Control File. This sequential file (it can be a PDS member) must
be defined LRECL=80. Add a DD statement that is named MSGRCNTL that identifies the file to the CA
Workload Automation CA 7® Edition JCL. Do not use inline streams (such as DD * or DD DATA). Do not
specify FREE=CLOSE. This file must remain allocated during the CA Workload Automation CA 7®
Edition started task.
The first statement in this file that is not a comment identifies the Unicenter Event Consoles or CA
OPS/MVS® Event Management and Automation to receive CA Workload Automation CA 7® Edition
messages.
All subsequent statements in the MSMR Control File are used as criteria to select and customize
messages for routing.
MSGRCNTL in CAL2OPTN includes a sample MSMR Control File. We recommend using this sample file
for the initial implementation of Master Station Message Routing. The control statements in the
sample file select the most commonly needed messages for routing.
Modify the TO keyword in the sample. Replace the XXXXXXXX with the CAICCI SYSID of the computer
hosting the Unicenter Event Console that receives CA Workload Automation CA 7® Edition messages.
To define more consoles, add nodes to the TO keyword. Blank delimit the nodes, as in this example:
TO(NODE1 NODE2 NODE3)
08-Feb-2018 652/722
To send the browse messages to CA OPS/MVS® Event Management and Automation, set a node
name to *OPSAPI*. Use this node name in place of, or in addition to, a Unicenter Event Console node
name.
All subsequent statements control message selection and customization. The statements in the
sample select the messages that are needed for production control purposes. Alter these parameters
to suit your installation needs.
Modifications must conform to the rules discussed in the following topic.
MSMR Control File Syntax

A statement that begins with an asterisk in column 1 is treated as a comment. If a statement does not
have an asterisk in column 1, it must conform to the following rules:
The first statement identifies Unicenter Event Consoles or CA OPS/MVS® Event Management and
Automation® to receive CA Workload Automation CA 7® Edition messages. This statement
requires the following keyword parameter:
TO
This keyword is the only valid keyword for this statement.
The following keyword parameters are valid on all statements except the first:
TXT
COLOR
ATTRIBUTE
SEVERITY
The TXT keyword is required on all control statements except the first.
Enclose the value of a keyword in parentheses. The parentheses must immediately follow the
keyword. Thus, the following example conforms to this rule:
TXT(SCM0)
But the following example does not, because a blank is between TXT and (SCM0):
TXT (SCM0)
Code each keyword only once.
Nested parentheses are not permitted.
A line that terminates with '+' is considered a continuation. At least one blank must precede the
'+'. And at least one blank must follow the '+'. This requirement implies that the '+' cannot be the
last character on the statement.
The statement resumes on the next valid (not a comment) statement.
Keywords cannot be continued, but their values can. Thus, the following example illustrates a
valid continuation:
TXT(SCM0 +
-19) COLOR(RED)
However, the following example is not valid:
08-Feb-2018 653/722
However, the following example is not valid:

TX +
T(SCM0-19) COLOR(RED)
If a syntax error is detected, no messages are selected for routing.
Characters on a control statement that are not part of a valid keyword string are treated as
comments.
TO Keyword
The TO keyword identifies destinations for Master Station Message Routing. All selected messages
are routed to each of the destinations that are coded on the TO keyword.
The 1 through 8 character CAICCI SYSID of the computer where the console resides identifies each
Unicenter Event Console. Values of this keyword are blank delimited.
The designator for CA OPS/MVS® Event Management and Automation is *OPSAPI*. Specify this
destination only once.
At least one value must be specified to activate Master Station Message Routing. We recommend
coding no more than four values on the TO keyword to avoid excessive storage use.
Begin the TO keyword in column 1 of the control statement.
This keyword is the only valid keyword on the first statement that is not a comment. TO is ignored on
all subsequent statements.
TXT Keyword
The value of the TXT keyword is used as a criterion for message selection. When a master station
message is issued, CA Workload Automation CA 7® Edition compares the TXT value on each control
file statement with the text of the master station message to determine whether to route the
message.
When a master station message is issued, CA Workload Automation CA 7® Edition fetches the first
statement in the MSMR Control File and compares the TXT value with the text of the message.
Comparison proceeds from left to right starting with position 1 of the message for the length of the
TXT keyword value. If all characters in the TXT value match corresponding positions in the message,
the message is selected for routing. No further comparisons are executed for the message. If the TXT
value does not match the corresponding positions of the message, the next control statement is
fetched. The message text is compared with that TXT value.
This process continues until a message is selected or all TXT values have been compared. If all control
statements are fetched and no TXT values match the message, the message is not routed.
When a message is selected for routing, more parameters (if any) from the control statement that
has the matching TXT value (such as COLOR and ATTRIBUTE) are used to alter the display of the
message.
TXT Keyword Coding Rules

Begin the TXT keyword begin in column 1 of the control statement.
08-Feb-2018 654/722
The length of the keyword value must not exceed 80 bytes.
Use of single character wildcards is permitted. A wildcard is designated using a question mark (?).
When a question mark is encountered in the TXT value, the corresponding position in the message
text is ignored during message selection.
To select all messages, code TXT(*).
COLOR Keyword
The COLOR keyword specifies the color that is used to display the message when selected. The
following values are valid for the COLOR keyword:
BLUE
GREEN
ORANGE (invalid for CA OPS/MVS® Event Management and Automation)
PINK
PURPLE (invalid for CA OPS/MVS® Event Management and Automation)
RED
YELLOW
ATTRIBUTE Keyword
The ATTRIBUTE keyword specifies special display attributes for the message. The following values are
valid for the ATTRIBUTE keyword:
BLINK
REVERSE
If ATTRIBUTE(BLINK) is coded, the message blinks when displayed at a Unicenter Event Console. The
blink rate is configurable in the Event Console. If ATTRIBUTE(REVERSE) is coded, the color setting is
used for the background instead of the text. The text is displayed in white.
The CA OPS/MVS® Event Management and Automation API ignores the ATTRIBUTE keyword.
SEVERITY Keyword
The SEVERITY keyword specifies the severity code that is associated with the message. The following
values are valid for the SEVERITY keyword:
W
Warning
I
Informational
E
Error
The Unicenter Event Console displays special icons when one of the previous values is coded. If no
SEVERITY value is coded, the displayed message contains no icon.
08-Feb-2018 655/722
MSMR Control File Statement Examples

In this topic, assume that the CA Workload Automation CA 7® Edition MSMR control file (MSGRCNTL
DD in the CA Workload Automation CA 7® Edition JCL) contains only these statements:
TO(FREDSPC)
TXT(SMF0-19) +
SEVERITY(E) +
COLOR(RED)
TXT(SPO7-10 JOB PAYROLL2) COLOR(BLUE)
TXT(SPO7-10)
Example 1
If the text of the master station message begins with 'SCNJ', the message is not selected for routing
to the console on FREDSPC.
Example 2
If the text of the master station message begins with 'SPO7-10 JOB PAYROLL1', the message is
selected for routing with no special characteristics.
Example 3
If the text of the master station message begins with 'SPO7-10 JOB PAYROLL2', the message is
selected for routing and displays in blue.
Example 4
If the text of the master station message begins with 'SMF0-19', the message is selected for routing
and is displayed in red with a severity code of 'E'.
Note on Interleaved Messages
When you are viewing messages in the browse data set, you sometimes notice that master station
messages are occasionally interleaved. This interleaving is due to the fact that these messages are
written in 80-byte segments. Some messages consist of multiple segments. When a CA Workload
Automation CA 7® Edition terminal writes a message segment, a CA Workload Automation CA 7®
Edition terminal with higher priority can begin writing a segment for a different message. Hence
messages occasionally appear as interrupted by other messages.
This situation occurs when viewing master station messages at a Unicenter Event Console. However,
for many multisegment messages, CA Workload Automation CA 7® Edition MSMR combines
segments into a single segment when selected for routing. This combination reduces but does not
completely eliminate the likelihood of interleaving CA Workload Automation CA 7® Edition master
station messages at a Unicenter Event Console. For a list of multisegment messages that MSMR joins,
see the MSMR Messages List.
The CA OPS/MVS® Event Management and Automation API ignores the SEVERITY keyword.
08-Feb-2018 656/722
MSMR Messages List

This list shows messages that can appear as single segments if selected by Master Station Message
Routing (MSMR).
CA-7.023
SATO-15
SATO-20
SATO-35
SATO-36
SATO-37
SATO-38
SATO-39
SCM0-00
SCNJ-14
SCNJ-15
SCNJ-16
SCNJ-17
SCNJ-18
SCNJ-19
SCNP-11
SCRJ-12
SCRJ-14
SCRJ-48
SCRJ-60
SJL0-00
SJL0-01
SJL0-03
SJL0-11
08-Feb-2018 657/722
SJL0-11
SJL0-12
SJL0-13
SJL1-01
SMF0-13
SMF0-15
SMF0-17
SMF0-19
SMF0-20
SMF0-21
SPO7-00
SSM0-C0
SSM0-C1
SSM0-00
SSM0-1C
SSM0-28
SSM0-33
SSM0-34
SSM0-35
SSM0-36
SSM0-37
SSM0-39
SSM0-40
SSM0-41
SSM0-42
SVPR-50
SVPR-51
08-Feb-2018 658/722
SVPR-65
SVPR-66
SVPR-67
XCF Group and Member Names

Each entity that interacts with the IBM Cross-System Coupling Facility (XCF) has both an 8-character
XCF group name and a 16-character member name. Default CA Workload Automation CA 7® Edition
and ICOM group and member names are assigned as described in the following topics.
CA WA CA 7 Edition XCF Names

If the SMF initialization parameter SMFXCF=Y|YES is coded, the group name is system-assigned. The
default CA Workload Automation CA 7® Edition group name is as follows:
CA7#nnnn
nnnn
Indicates the CA 7 instance name.
If the value of SMFXCF is anything else other than NO or N, the group name is given the value that is
specified for SMFXCF. The group name for CA Workload Automation CA 7® Edition and all ICOMs that
communicate with it must match. For example,
SMFXCF=MYGROUP
The XCF member name for CA 7 is system-assigned as follows:

CA7#nnnnssssbbbb
nnnn
Indicates the CA 7 instance name.
ssss
Indicates the SMF ID of the system on which CA Workload Automation CA 7® Edition is running.
bbbb
Indicates four blanks.
The following example member name includes four blanks:

CA7#CA74SA31
ICOM XCF Names

If the ICOM initialization parameter XCFGRP is not coded, the group name is system-assigned. The
default ICOM group name is as follows:
CA7#nnnn
08-Feb-2018 659/722
nnnn
Indicates the CA 7 instance name that is specified in the ICOM initialization parameter CA7.
If the value of XCFGRP is coded, the group name is given the value that is specified for XCFGRP. The
group name for ICOM must match the group name for the CA Workload Automation CA 7® Edition
with which it communicates. For example,
XCFGRP=CA7#CA74
XCFGRP=MYGROUP
The XCF member name for ICOM is system-assigned as follows:

ICOMnnnnssssbbbb
nnnn
Indicates the CA 7 instance name that is specified in the ICOM initialization parameter CA7.
ssss
Indicates the SMF ID of the system on which ICOM is running.
bbbb
Indicates four blanks.
The following example member name includes four blanks:

ICOMCA74SA31
CAL2DBVR Utility
The CAL2DBVR (database verification) utility examines relationships between tables in the database
for inconsistencies and executes in batch mode outside of CA Workload Automation CA 7 Edition.
Usually, the expectation is that few inconsistencies are found.
The CAL2DBVR module examines the database and optionally applies updates for inconsistent
conditions. The input parameters determine which conditions are evaluated and whether
inconsistencies are corrected or only reported.
Inconsistencies are reported using three-digit message numbers that are written to the DBVOUT DD
statement. The DBVR messages have explanations of the messages.
If DBVR detects inconsistent conditions, the DBVR program completes with a completion code of 4.
If an error occurs processing the database or input parameters, the DBVR program completes with a
condition code of 8.
DBVR cannot execute while a CAL2DBEI EXPORT with TRUSTED=Y is active. DBVR cannot apply
updates while a CAL2DBEI IMPORT or the CA7 online system is active. If any of these conditions exist,
message CAL2D135E is issued and DBVR terminates with a condition code 8.
Database Verification Parameters (see page 661)

Interpret DBVR Output (see page 663)
08-Feb-2018 660/722
Database Verification Parameters

During the installation process, SYSGEN created the CA07N610 job that you can use to execute
CAL2DBVR.
You can specify the Input parameters on the EXEC statement of the DBVR JCL or using DD DBVPARM.
Separate the parameters with commas. When using DBVPARM, the parameters must begin in column
1. If more than one statement is specified in DBVPARM, the parameters are merged. If the
parameters are specified in both DBVPARM and on the EXEC statement, the parameters are merged.
The parameters must appear in the execution JCL in one of the following formats:
PARM='[TRIG][,SCHD][,RQMT][,XREF][,UPDT][,DELR][,DELT][,KEYS][,TABS]'
-or-
//DBVPARM DD *
[TRIG][,SCHD][,RQMT][,XREF][,UPDT][,DELR][,DELT][,KEYS][,TABS]
Specify the parameters in any order. Specify only the parameters for the verification that you want. If
a particular type of verification parameter is omitted, that type of verification is not performed.
Specify at least one of TRIG, SCHD, RQMT, XREF, KEYS, or TABS, or no verification is performed.
The following parameters are valid:
TRIG
Requests a verification that is related to triggering.
SCHD
Requests a verification that is related to schedules.
RQMT
Requests a verification that is related to requirements and the DD entries.
XREF
Requests a verification of various counts that are stored in the database including the number of:
Jobs using each network
Jobs creating each data set
Jobs using each data set
Jobs with manually added requirements for each data set
Steps in each job
DDs in each job
Schedule IDs in each schedule (for both jobs and networks)
08-Feb-2018 661/722
UPDT
Requests that the corrections of errors found. If not specified, verification issues are reported
only. No corrections are applied to the database. We recommend that you run DBVR without
UPDT to report only errors before running with UPDT. See Interpret DBVR Output that follows.
KEYS
Requests a verification of foreign key relationships that CA Datacom®/AD maintains.
TABS
Requests a verification of foreign key relationships in CA Workload Automation CA 7 Edition
internal tables.
The next two parameters apply only if UPDT is specified. They determine whether DBVR cleans up the
definitions that are sometimes left behind after a job was deleted without the PURGE option.
Without a PURGE at job deletion, definitions that include the deleted job as a requirement or as a
triggered job are not also deleted. If DELR, DELT, or both are not specified, DBVR reports these
conditions using message numbers 102 and 301 but does not apply corrections. Specify DELR, DELT,
or both to apply corrections for the conditions that the message numbers 102 and 301 indicate.
DELT
Some inconsistent trigger definitions are only deleted when DELT is specified. See the following
table for more information. Only valid when UPDT also specified. The default is no DELT.
DELR
Some inconsistent requirement definitions are only deleted when DELR is specified. See the
following table for more information. Only valid if UPDT specified. Default is no DELR.
The following table provides detailed descriptions of the conditions that a parameter evaluates and
the corrections applied.
Input Error Criteria Error Correction (applied only when

Parm UPDT is specified)
TRIG Triggering job, data set, or network not defined Delete trigger definition
Triggered job not defined Delete trigger definition (only when
DELT input parameter is also
specified)
Job, data set, or network indicates that it triggers jobs, Turn triggers-jobs indicator off
but no triggered jobs are defined
Job, data set, or network does not indicate that it Turn triggers-jobs indicator on
triggers jobs, but triggered jobs are defined
SCHD A defined schedule does not have a matching job or Delete schedule definitions
network defined
Job or network has the schedule indicator on, but no Turn schedule indicator off
schedule is defined
Job or network does not have the schedule indicator Turn schedule indicator on
on, but a schedule is defined
RQM Required data set or network not defined Delete requirement definition
T
08-Feb-2018 662/722
Input Error Criteria Error Correction (applied only when

Parm UPDT is specified)
Required job is not defined Delete requirement definition (only
when DELR input parameter is also
specified)
Requiring job is not defined Delete requirement
DD data set not defined Delete DD entry
XREF # using jobs are not equal to # jobs requiring network Update # using jobs
# creating jobs that are stored in data set record is not Update # creating jobs
equal to # jobs that create the data set
# using jobs that are stored in data set record is not Update # using jobs
equal to # jobs that use the data set
# jobs with manually added requirement for the data Update # manual data set
set is not equal to number of manual data set requirements
requirements
# steps in the job are not equal to # of steps found in Update # of steps
most recent LOAD of the job
# DDs in the job are not equal to # of DDs found in Update # of DDs
most recent LOAD of the job
# schedule IDs in a job are not equal to # of schedule Update # of schedule IDs
IDs defined for the job
# schedule IDs in a network are not equal to # of Update # of schedule IDs
schedule IDs defined for the network
KEYS Foreign key relationships No corrections are applied. Contact
CA Support for correction assistance.
TABS Foreign key relationships for mini-tables No corrections are applied. Contact
CA Support for correction assistance.
Interpret DBVR Output

DBVR reports inconsistencies and other information about whether to apply corrections by using
numbered messages. The messages are written to the DBVOUT DD statement.
If DBVR is executed in scan mode (without specifying UPDT) before executing in update mode, the
inconsistencies reported in both executions are typically identical. However, differences can be seen
between scan mode and update mode when a job is defined to trigger only one job and the triggered
job is undefined.
When DBVR executes in update mode with both UPDT and DELT, the trigger definition for the
undefined job is deleted. Because of this deletion, the triggering job indicator must be turned off in
the job that supposedly triggered the undefined job. This situation was not reported in the scan.
Because the trigger definition is now removed to the undefined job, the job must be updated to show
that it does not trigger any jobs (because it only triggered that one job). For example, JOBB is
undefined in the database. JOBA indicates that it triggers only one job: JOBB. When the trigger
relationship from JOBA to JOBB is deleted, then JOBA must be updated to show that it does not
trigger any jobs.
08-Feb-2018 663/722
CAL2ENVR Utility
The CAL2ENVR utility reports on the status of the CA Workload Automation CA 7® Edition system
environment. The CAL2ENVR report includes information about options currently in effect for each
tracking instance that is active on the LPAR. Output from this program also includes the storage
locations of important system modules such as the CA Workload Automation CA 7® Edition SVC and
SMF exits.
The JCL (CAL2JCL) member AL2ENVR has model JCL that can be used to execute CAL2ENVR.
CAL2ENVR Example
This topic shows an example of the CAL2ENVR report created on an LPAR where the CA Workload
Automation CA 7® Edition system was initialized in compatibility mode. Systems running in
compatibility mode have more information shown on the CAL2ENVR report than systems running in
native mode.
In this example, the following System Configuration File statements were supplied for the execution
of CAIRIM:
GLOBAL INITC TSVC(222)
CA71 ADD
CA72 ADD
CA74 ADD ALIAS(SYS4)
After CAIRIM completed, r3.3 PROD and TEST instances of CA Workload Automation CA 7 Edition
were started. ICOMs were started for CA71 and CA72. The CAL2ENVR report that follows describes
the state of the CA Workload Automation CA 7 Edition system environment after all the previous
events occurred.
CA Workload Automation SE System Configuration Report for SMFID(CA31) created on 20yy.154 at 14:32:43.34569 PAGE 1
SSCT for CA-7 located at: 00C8A610
SSCT for UC07 located at: 00D2CF8C (00C8A940)
SSCT for UCT7 located at: 00D35FB0 (00C70600)
IVT located at: 00C8A638
System in compatibility mode
IVT last updated on yyyy.ddd at 11:54:44.25572
IVTLVL is r12.0 ; IVT created by CAS9
ICMDSECT Summary
CA71 last updated on yyyy.ddd at 11:54:44.25572
CA71 CA72 (CA73) CA74 (CA75) (CA76) (CA77) (CA78)
Instance alias is SYS4
ICMDSECT located at 00C8A940 00C70600 00B89078
SMF buffer located at 00C8A210 00C70800 00B4F488
TRL buffer located at 00C70C00 00B710F8 00B4F088
STAT area located at 00D0D718 00D0D6D8 00D0D658
NCF outbound buffer at N/A N/A N/A
NCF node table located at N/A N/A N/A
Old NCF node table located at N/A N/A N/A
08-Feb-2018 664/722
SMF Collection Active ? Y Y Y
TRL Collection Active ? Y Y Y
Collect SMF 14 recs ? N N N
Collect SMF 15 recs ? Y Y Y
Collect SMF 64 recs ? N N N
SMF Type 30 support ? Y Y Y
NCF indicated ? N N N
Security for U7SVC D= ? N N N
BSUBCHK ? N N N
Trailer blocking used ? Y Y Y
Track SMF 26 ? Y N N
Test copy linked to this instance ? Y N N
CA-7 SVC number 167 222 167
SMF indicator location 7 7 7
SMF indicator is EE ED EB
Job card indicator is 31 30 2E
CA-7 Release B3 B3 B3
ICOM active on this CPU ? Y Y N
The report heading identifies where (SMFID and LPAR) and when the report was created.
The name and address of the SSCTs used by CA Workload Automation CA 7 Edition are reported. The
SSCT is named 'CA-7'. In compatibility mode, two additional SSCTs are reported. The UC07 SSCT maps
to instance CA71 and the UCT7 SSCT maps to instance CA72.
The address and status of the Instance Vector Table (IVT) is reported. The IVT is the primary structure
in the CA Workload Automation CA 7 Edition system environment. It contains important processing
options and addresses of CA Workload Automation CA 7 Edition system routines.
CAL2ENVR reports that the system is in compatibility mode. This means that the current system
environment supports pre-r11 versions of CA Workload Automation CA 7 Edition programs. If
EXTTRK7(Y) is coded in the system configuration file, you see "CA-7 jobs/data sets subject to external
tracking".
The date and time the IVT was last updated (created) appears in the report.
The IVTLVL reports the current level of CA Workload Automation CA 7 Edition maintenance known on
this LPAR. The information in the product initialization routine and information in the UCC7SVT
module that was accessible to the product initialization routine when CAIRIM last ran determine this
level.
The ICMDSECT Summary reports on options in effect for each CA Workload Automation CA 7 Edition
instance defined on the LPAR. Each reported option is described on the left side of the page. When
CAIRIM is executed to add a tracking instance, an ICMDSECT (instance control block) is allocated. The
ICMDSECT contains all the options specified for the instance in the system configuration file, plus the
defaults for the options not specified. Because a CA Workload Automation CA 7 Edition system
environment can support up to eight tracking instances on an LPAR, there are eight columns of
ICMDSECT information. The name of the instance (CA71, CA72, and so on) heads each column. If the
instance is not currently active, the name of the instance is enclosed in parentheses.
Statements in the CAIRIM System Configuration File statements solely determine whether an
instance is active. The instance must be active before a job or started task can be run that initializes
that instance of CA Workload Automation CA 7 Edition.
In this report, three instances were added, so there are three instances active and five instances
inactive. If an instance is added and deleted, the ICMDSECT does not go away. The name is still
displayed on the report. Parentheses, however, surround the instance name.
08-Feb-2018 665/722
ICMDSECT Extension Summary
CA71 CA72 CA73 CA74 CA75 CA76 CA77 CA78
ICMDSECT extension located at 00C8AAC0 00C70780 00B891F8
XU83 table named N/A N/A N/A
XU83 table located at N/A N/A N/A
XU83 table length is N/A N/A N/A
Old XU83 table located at N/A N/A N/A
Old XU83 table length is N/A N/A N/A
XJOB table named N/A N/A N/A
XJOB table located at N/A N/A N/A
XJOB table length is N/A N/A N/A
Old XJOB table located at N/A N/A N/A
Old XJOB table length is N/A N/A N/A
XDSN table named N/A N/A N/A
XDSN table located at N/A N/A N/A
XDSN table length is N/A N/A N/A
Old XDSN table located at N/A N/A N/A
Old XDSN table length is N/A N/A N/A
The ICMDSECT extension summary in 2 of the CAL2ENVR report also shows information about each
instance. Here you see information about user options such as external task tracking, external data
set tracking, and selective tracking of SMF records.
Page 3 lists the NCF Node Table information that is in use.
CDE Report for selected modules
CAIXAL2@ (00B35210/00000C50) #MODID: CAIXl2XI CAL2C00 ~RMID(RESERVE) ~ 20yy0923 16:28

ICMDSECT (00D0D010/00000180) #MODID: ICMDSECT CAL2C00 ~RMID(RESERVE) ~ 20yy0923 16:28
IGCSEXXX (00D03268/00000238) #MODID: IGCSEXXX CAL2C00 ~RMID(RESERVE) ~ 20yy0923 16:28
IGCSJXXX (00CFC080/00000420) #MODID: IGCSJXXX CAL2C00 ~RMID(RESERVE) ~ 20yy0923 16:28
IGCS1XXX (00D030E8/00000180) #MODID: IGCS1XXX CAL2C00 ~RMID(RESERVE) ~ 20yy0923 16:28
IGCS2XXX (00D16000/00000108) #MODID: IGCS2XXX CAL2C00 ~RMID(RESERVE) ~ 20yy0923 16:28
IGCS3XXX (16526F48/000010B8) #MODID: IGCS3XXX CAL2C00 ~RMID(RESERVE) ~ 20yy0923 16:28
IGCS4XXX (1DEC5018/00000478) #MODID: IGCS4XXX CAL2C00 ~RMID(RESERVE) ~ 20yy0923 16:28
IGCS5XXX (00D0B920/000000E0) #MODID: IGCS5XXX CAL2C00 ~RMID(RESERVE) ~ 20yy0923 16:28
IGCS9XXX (1D91F820/00000708) #MODID: IGCS9XXX CAL2C00 ~RMID(RESERVE) ~ 20yy0923 16:28
SASSSVCA (00C811E0/00000B58) #MODID: SASSSVCA CAL2C00 ~RMID(RESERVE) ~ 20yy0923 16:28
SASSXSEC (00C88130/000009D0) #MODID: SASSXSEC CAL2C00 ~RMID(RESERVE) ~ 20yy0923 16:28
SASSUJV (1A65B3B0/00000700) #MODID: SASSUJV CAL2C00 ~RMID(RESERVE) ~ 20yy0923 16:28
SASSU83 (1A5561E0/00000C68) #MODID: SASSU83 CAL2C00 ~RMID(RESERVE) ~ 20yy0923 16:28
SASSU84 (1A42D2A8/00000950) #MODID: SASSU84 CAL2C00 ~RMID(RESERVE) ~ 20yy0923 16:28
U7SVC (00ADB490/00001B70) #MODID: U7SVC CAL2C00 ~RMID(RESERVE) ~ 20yy0923 16:28
IGC0016G (1A78D068/00000EF0) #MODID: IGC0016G CAL2C00 ~RMID(RESERVE) ~ 20yy0923 16:28
IGC0022B (1EBE5B10/00000250) #MODID: IGC0022B CAL2C00 ~RMID(RESERVE) ~ 20yy0923 16:28
The CDE Report in Page 4 lists, for selected modules, the location in storage and the size of the
module. Systems running native instead of compatibility mode can see fewer modules than shown in
the example. The following load modules would not exist on a native system: ICMDSECT, IGCSEXXX,
IGCSJXXX, IGCS1XXX, IGCS2XXX, IGCS4XXX, IGCS5XXX, IGCS9XXX, and IGC0022B. MODID information
provides release and date information.
The report can display more than one version for a module. If a module is reloaded, CAL2ENVR
reports the current location/size and the previous location/size. Only the immediately previous
version of the module is displayed. If a module is loaded multiple times, earlier versions are not
reported.
The CDE report also shows the amount of static CSA and ECSA used by CA Workload Automation CA 7
Edition.
08-Feb-2018 666/722
CA-7 Address Space Summary
QNAME RNAME JOB NAME SYS NAME ASID
UCC7SVT U731 CA7ONL22 SA31 00163
UCC7SVT UT44 CA7TST44 SA31 00724
ICOM Address Space Summary for UC07
UC07 ICOM CA7ICM22 SA31 00337
ICOM Address Space Summary for UCT7
UCT7 ICOM CA7ICMT4 SA31 00161
UCC7CMDS ENQ/RESERVE Summary
N/A N/A N/A N/A N/A
Logical DB Name ENQ Summary for DBOWN
QNAME RNAME JOB NAME SYS NAME ASID SCOPE
CA7 DBOWNSA31PROD CA7ONL22 SA31 00163 SYSTEM
Logical DB Name ENQ Summary for DBUSE
QNAME RNAME JOB NAME SYS NAME ASID SCOPE
CA7 DBUSESA31PROD CA7ONL22 SA31 00163 SYSTEM
Page 5 of the CAL2ENVR report is generated from enqueues and reserves in the system. The CA-7
Address Space Summary shows the CA Workload Automation CA 7 Edition jobs running at the time
the CAL2ENVR job ran. The ICOM Address Space Summaries show any ICOM jobs running and which
CA7 instances they communicate with.
The UCC7CMDS ENQ/RESERVE Summary shows any CA Workload Automation CA 7 Edition and ICOM
jobs that had an update enqueue or reserve on the communication data set at the time the
CAL2ENVR job ran. This section is typically all "N/A"s.
The Logical DB Name ENQ Summary sections show what CA Datacom/AD logical DB names are in use
and the type of control. The entries in the DBOWN section are under exclusive control, and the
entries in the DBUSE section are under shared control.
CA 7 Health Checker Interface Summary
Interface is Enabled, interval is 15 minutes
Name/Token Pair Summary
NAME TOKEN
SA31CA71 00000E84 00000C06 000076C8 00000000
SA31CA74 00000DC4 00000062 000070C8 00000000
Cross-system Coupling Facility (XCF) Summary
XCF Group Name XCF Member Name
CA7#CA74
ICOMCA74SA31
CA7#CA74SA31
--------
08-Feb-2018 667/722
Page 6 of the CAL2ENVR report shows interfaces with the IBM Health Checker and Cross-system
Coupling Facility (XCF).
The CA 7 Health Checker Interface Summary shows the status of the interface and interval in minutes
between CA Workload Automation CA 7 Edition availability checks in IBM Health Checker. The Name
/Token Pair Summary shows the contents of Name-Token pairs created during the CA Workload
Automation CA 7 Edition initialization for tracking copies of CA Workload Automation CA 7 Edition. If
no pairs are found, the section contains all "N/A"s.
The Cross-system Coupling Facility (XCF) Summary shows the group names for all active CA Workload
Automation CA 7 Edition XCF groups. For each listed group, the active XCF member names are listed.
A row of dashes terminates the group names.
On the following pages 7-9, you see an Address Space Summary, which provides STC names including
instance information, ENF Status, and a Datacom Summary, which includes individual MUF names for
each instance.
CA Workload Automation SE System Configuration Report for SMFID(XE82) created on 20yy.009 at 12:37:13.92002 PAGE 7
Address Space Summary
CA71 CA72 CA73 (CA74) (CA7
Job Name CA71ONL . CA73ONL . .

Job ID STC00056 . STC00124 . .
Start Time 11:36:19 . 12:36:36 . .
Start Date (ccyy.ddd) 20yy.009 . 20yy.009 . .
Start Date (dd/mm/yy) 01/09/15 . 01/09/15 . .
ASCB 00FA7580 . 00FA1D00 . .
ASID (Hex) 0055 . 0064 . .
ASID (Decimal) 00085 . 00100 . .
UCC7SVT 000072A8 . 000072A8 . .
CA 7 Release 12.0 . 12.0 . .
CA 11 Status . . Active . .
CA 11 SSN . . CAL7 . .
CA 11 Release . . 11.0 . .
ICOM ENQ:
o Job Name CA71ICOM . . . .
o ASID (Hex) 0054 . . . .
o ASID (Decimal) 00084 . . . .
Datacom:
o Connection Type L . L . .
o MUF System Name XE82 . XE82 . .
o MUF Job name MUF1482 . MUF1482 . .
o Interface Release 14.0 . 14.0 . .
o MUF Release 14.0 . 14.0 . .
CA ENF Status
Status Active
Level VR14
ASCB 00FA7B80
ASID (Hex) 0051
ASID (Decimal) 0081
Job Name ENFXMUF
Job ID STC00051
Start Time 11:34:29
Start Date (ccyy.ddd) 20yy.009
Start Date (ccyy-mm-dd) 20yy-01-09
CA 7 Datacom Summary
Name Muf DB Name Datacom Load Libraries

---- -------- ---------------- --------------------------------------------
CA71 MUF1482 XE82CA71 APCQADAL.AX14GA.HLQ.XE82.CUSLIB
14.0 APCQADAL.AX14GA.CAAXLOAD
CA73 MUF1482 XE82CA73 APCQADAL.AX14GA.HLQ.XE82.CUSLIB

14.0 APCQADAL.AX14GA.CAAXLOAD
08-Feb-2018 668/722
CAL2SC80 Utility
The CAL2SC80 utility can build the System Configuration File statements that reflect the current state
of the CA Workload Automation CA 7® Edition system environment. This utility can prove useful with
the CAL2ENVR report. You can run CAL2SC80 to take a "snapshot" of the current environment in case
you must restore it later. The utility could also prove useful when upgrading to a new release of the
product.
The JCL (CAL2JCL) member, AL2SC801, contains the model JCL that you can use to run CAL2SC80.
L2JFMIGR Utility
The Last Run Date Extract utility, L2JFMIGR, reads the specified CA 7 database. The utility selects jobs
by using a benchmark DATE and TIME with optional JOB, SYS, and NET mask qualifiers. For each job
with a last run date and time that meets or exceeds the benchmark date and time and matches any
specified qualifier masks, a CA 7 batch NXTCYC command is generated. The commands are written to
a sequential output file with the job and last run date and time data. Once these commands are
executed on the target CA 7, future workload requirements for these jobs are satisfied without any
manual intervention.
Sample JCL for the Last Run Date Extract Utility is located in the CA 7 CAL2JCL library, member
AL2LRUN.
Input:
DBPARMS DD
SYSIN DD
Specifies the criteria on which to extract the data. An asterisk in column one denotes a comment.
Code only one DATE, TIME, JOB, SYS, and NET statement (not multiple statements).
DATE=yyddd
Indicates a benchmark date. Only those jobs with a last run date equal to or more current
than this benchmark date are selected.
TIME=hhmm
(Optional) Indicates a time of day with the date. The default is midnight (0000).
JOB=
(Optional) Indicates a job name mask. The default is all job names.
SYS=
(Optional) Indicates a system name mask. The default is all system names.
NET=
(Optional) Indicates a job network name mask. The default is all job networks.
Output:
08-Feb-2018 669/722
Output:
SYSOUT DD
Specifies where to write the processing messages and report, which is typically routed to SYSOUT.
COMMANDS DD
Specifies the location for the NXTCYC commands of selected jobs (FB/80).
The output commands have the following format:

NXTCYC,SET=RUN,JOB=name,LRDATE=yyddd,LRTIME=hhmmssth
SASS Utilities
Four utilities use the SASS prefix, SASSCDSI, SASSXDSI, SASSXKPI, and SASSZXTV.
SASSCDSI Utility (see page 670)

SASSXDSI Utility (see page 671)
SASSXKPI Utility (see page 672)
SASSZXTV Utility (see page 672)
SASSCDSI Utility
The SASSCDSI utility formats the communications data set.
Before ICOM can use the communications data set, the SASSCDSI program must format the data set.
This formatting process is required for the following:
Changing the size or structure of the communications data set.
Defining a new submit data set to extend CA Workload Automation CA 7® Edition control over
another CPU.
If the formatting of the communications data set is not complete before the execution of ICOM,
execute the CA 7 JCLLIB CA07N700 member to accomplish the required formatting.
Note: During the initial CA 7 installation, the JCLLIB CA07N030 executes this job to initialize
the COMMDS and other data sets used in CA 7 execution.
Note: For NCF concerns, see DASD Requirements for NCF (https://wiki.ca.com/display/CWAC7E
/NCF+Resource+Requirements#NCFResourceRequirements-DASDRequirementsforNCF).
SASSCDSI SYSIN Data Set
08-Feb-2018 670/722
Initialization of the communications data set requires three types of SYSIN control statements. These
statements are as follows:
*CDSINIT*
This statement must be the first statement in the input stream and must begin in column 1.
1 11
| |
*ICOMCPU* xxxxyyyyzzzzaaaa
This statement must be the second statement in the input stream and must begin in column 1.
xxxx, yyyy, zzzz, and aaaa are the system IDs defined to SMF through the appropriate SYS1.PARMLIB
member. Up to four CPUs can be specified. They must begin in column 11. Each system ID must be
four characters long. Multiple IDs can be specified in any sequence. Systems IDs are used for
documentation purposes only. If ICOM is active on more than four systems, only four can be
specified. This does not affect the processing of ICOM or of CA Workload Automation CA 7® Edition.
1 11
| |
*CPU* xxxxxxxx
Defines the submit data set for each ICOM (or CPU). One *CPU* statement is required for each CPU
that CA Workload Automation CA 7® Edition controls. The *CPU* entry must begin in column 1. The
xxxxxxxx value must begin in column 11. The xxxxxxxx value specifies the ddname of a submit data
set as defined in the CA Workload Automation CA 7® Edition JCL and the ICOM JCL. If the internal
reader option is taken (see the following), at least one *CPU* statement is still required.
SASSXDSI Utility
The SASSXDSI utility must format the XCF data set before CA Workload Automation CA 7® Edition can
use it. This formatting process is required when changing the size of the XCFDS or defining a new data
set.
Note: This data set is only used when CA7ONL and ICOM are using XCF as a
communications method between systems.
If the formatting of the XCF data set is not complete before the execution of ICOM, use CA 7 JCLLIB
member CA07N705 to accomplish the required formatting. The prefix CA07 is sometimes changed.
08-Feb-2018 671/722
SASSXKPI Utility
The SASSXKPI utility must format the XCF checkpoint data set before CA Workload Automation CA 7®
Edition can use it. This formatting process is required if a new data set is being defined.
Note: This data set is only used when CA7ONL and ICOM are using XCF as a
communications method between systems.
If the formatting of the XCF checkpoint data set is not complete before CA Workload Automation CA
7® Edition execution, use the CA 7 JCLLIB member CA07N707 to accomplish the required formatting.
The prefix CA07 is sometimes changed.
SASSZXTV Utility
The SASSZXTV utility checks that the user exit programs are assembled using the current level of
SASSVRSN macro and show the current release level as matching the level in this utility. This program
runs as a stand-alone utility and provides a means to examine the user exit programs for a release
level before starting the CA 7 online region.
The SASSZXTV utility reads control statements from SYSIN and produces a report in SYSPRINT.
An example of the JCL to execute SASSZXTV is found in the CAL2JCL library as member AL2ZXTV.
Input:
A list of your user exit programs to be scanned in the SYSIN DD. Lines with * in the first column
are considered comments. Start all parameters in the first column. Have one parameter per
control statement. Statements can be in any order. No SYSIN parameters results in a return code
8.
Output:
A report showing the results of the scan to perform in the online region.
Return Codes:
SASSZXTVI returns the following return codes:
0
Indicates normal completion.
08-Feb-2018 672/722
8
Indicates one of the following conditions:
Error opening SYSIN
Program is not user exit SASSXXxx
Program release level not matching
Program core mark not found
Program load has failed
SYSPRINT file fails to open or is dummy.
User Exits and Modifications

The user exits let you tailor CA Workload Automation CA 7® Edition to meet the special needs of an
installation. See the AL2$$IDX member in the Options file (CAL2OPTN) (members with an AL2UM
prefix) for the appropriate user exits.
User Modifications Under SMP/E

The AL2$$IDX member of the Options file (CAL2OPTN) provides a list of all CA Workload Automation
CA 7® Edition user modifications available under SMP/E. USERMOD member names are prefixed with
AL2UM. The sample source entry itself can be found as member names ALUM nnM, which would be
used in a basic assembly and link JCL (AL2UMASM in CAL2JCL).
Code User Exits

Following the conventions regarding the use and coding of user exits that are outlined here is
important. Failure to do so could result in a serious degradation of CA Workload Automation CA 7®
Edition performance and functionality.
The two types of user exits are online and standard. In the online exit environment, CA Workload
Automation CA 7® Edition main task services are used for linkage. Other services are available as
described. Because online exits require main task services for linkage, they cannot be tested outside
the CA Workload Automation CA 7® Edition environment. In the standard exit environment, CA
Workload Automation CA 7® Edition main task services are not available.
See the AL2$$IDX member in the Options file (CAL2OPTN) (members with an AL2UM prefix) for the
appropriate user exits.
08-Feb-2018 673/722
A version check of the online exits (SASSXXaa) occurs when they are loaded. The version check
ensures that the exit is assembled using the CAL2MAC macro library of the current release. If the exit
is not assembled using the current release macros, the check fails and online does not call the exit for
execution. The exit name (SASSXXaa) and the current release (vv.r) are searched in the first 256 bytes
of the loaded module. If these constants are not found, the exit is disabled. As a result, automation of
the following two messages can be useful to alert someone that exit points are not called:
CAL2D132W Cannot find valid version identification in user exit xxxxxxxx
CAL2D133W Incorrect version identification found in user exit xxxxxxxx
The following table classifies the user exits as either online or standard.
Exit Name Exit Type

Exit that SASSPM00 invokes Standard
(Problem Management Interface exit)
SASSXXBT Standard
SASSXXFF Online
SASSXXLX Online
SASSXX01 Online
SASSXX02 Online
SASSXX03 Online
SASSXX04 Online
SASSXX05 Online
SASSXX07 Online
SASSXX08 Online
SASSXX09 Online
SASSXX10 Online
SASSXX11 Online
SASSXX12 Standard
SASSXX13 Online
SASSXX14 Online
SASSXX15 Online
SASSXX16 Online
SASSXX17 Online
SASSXX20 Online
SASSXX21 Online
SASSXX22 Online
08-Feb-2018 674/722
Rules for Coding Online Exits

The following rules apply to coding online user exits. In certain cases, more restrictions can apply; see
the description of the exit you want to code for further information.
Must be written in assembler language.
Must be reassembled each release using the CAL2MAC macro library of the new release.
Must include the following macros:
EXITPARM (to map exit parameters)
SASSEQU (declares the equates required by CA Workload Automation CA 7® Edition macros,

also provides register equates)
UCC7SVT (required by many CA Workload Automation CA 7® Edition services)
SASSVRSN can be used for entry
In general, must use SEXIT to return
Should be coded reentrant and serially reusable unless otherwise noted.
Avoid any activity that has the potential to degrade CA Workload Automation CA 7® Edition
system functioning. MVS services that must not be requested include but are not limited to:
WAIT, STIMER, and SVC 99. Services that could cause a wait condition or issuing of an STIMER
could adversely affect system performance and must not be used. Because many online exits are
invoked directly from critical CA Workload Automation CA 7® Edition functions, it is important
that exit routines be of short duration.
An APPLCTN statement identifying the exit must be included in the initialization file. If the size of
the exit module exceeds 32 KB, then ATTR=PERM must be specified on the APPLCTN statement.
The use of the BAKR instruction can cause unpredictable results and should be avoided.
The entry point must be the beginning of the load module.
The exits use RMODE=24 and AMODE=24 unless otherwise noted.
Register Descriptions for Online Exits

The following table summarizes the register conventions for the online user exits. See individual exits
for specific register contents.
Register Convention
0 Destroyed
1 Destroyed
2 Saved across CA Workload Automation CA 7® Edition system requests
08-Feb-2018 675/722
Register Convention
9 Saved across CA Workload Automation CA 7® Edition system requests (secondary base
register)
10 Saved across CA Workload Automation CA 7® Edition system requests (primary base
register)
11 Points to the SCT - must not be modified - mapped by macro SCTENTRY
12 Points to the SVT - must not be modified - mapped by macro UCC7SVT
13 Destroyed - does not point to a save area unless otherwise noted
15 Destroyed - but upon entry contains the entry address
Rules for Coding Standard Exits

The following rules apply to coding the STANDARD user exits. In certain cases, more restrictions can
apply. For more information, see the description of the exit that you want to code.
Must be written in assembler language.
Should include the EXITPARM macro to map exit parameters.
Should be coded reentrant and serially reusable unless otherwise noted.
Must not use SEXIT to return.
Use standard IBM register 13 processing for entry and exit.
SASSVRSN can be used at entry for identification (not register saving).
The exits use RMODE=24 and AMODE=24 unless otherwise noted.
Test User Exits

During testing, it is sometimes necessary to refresh exit modules. In certain cases, the /RELINK
command can accomplish the refresh.
If the description of the exit indicates that you can use /RELINK, /RELINK can refresh the module if it
is not marked PERM or RESD. If the module is marked PERM or RESD, recycle the CA Workload
Automation CA 7® Edition address space to refresh the module.
08-Feb-2018 676/722
Online Exit Descriptions

The following topics describe the online exits. The character M sometimes follows the member
names to indicate a source-only (not a USERMOD) when you want a non-SMP/E member.
Agent Job Submission - SASSXX22

The Agent Job Submission exit examines and modifies data immediately before it is sent to a cross-
system CA system agent. This exit is invoked as the control blocks to send to the IAS AFM Builder are
being built. The exit is invoked once for the agent name, once for the user ID, and once for each
complete CLANG statement in the associated PARMLIB member (with line continuations already
resolved). The exit is invoked one final time for a cleanup call, in which the exit can only free its
storage and return to CA Workload Automation CA 7® Edition.
Note: This exit applies only to agent jobs, not to CA7TOUNI or XPJOB jobs.
Application Name: SASSXX22 CAL2OPTN: AL2UM48
Caller: The SASSXX22 exit is called by SASSAFM1, which executes in a subtask in the CA Workload
Automation CA 7® Edition environment (not on the main task). As such, this exit cannot request any
services of the CA Workload Automation CA 7® Edition main task, such as queue or database access.
Note: This exit is only called for agent jobs. SASSXX20 is called for CPU jobs, and SASSXX21
is called for XPJOB jobs.
Module Attributes: This module must have the following attributes:
RENT, REUS
AMODE(24)
RMODE(24)
SASSXX22 can use the SASSVRSN macro for entry/exit logic as demonstrated in the sample program
stub included in the related USERMOD in CA Workload Automation CA 7® Edition Options library
(CAL2OPTN) member AL2UM48 but cannot use any other CA Workload Automation CA 7® Edition
main task service.
Input:
On entry to the exit, the parameter list can contain the following parameters:
R1 =
Address of parameter list
+ 0 = A(72-byte save area for use by exit)
+ 4 = Length of the data field (max = 4096)
08-Feb-2018 677/722
+ 4 = Length of the data field (max = 4096)

+ 8 = A(Data field)
+12 = Function code:
0 - Not end of data call
1 - End of data; termination call
+16 = A(Copy of JQREC); See Note 1
+20 = A(0) that the exit can modify during the processing of a single job. The value is not saved
across different jobs. CA Workload Automation CA 7® Edition does not examine or use this
field.
R12 =
Address of CA Workload Automation CA 7® Edition System Vector Table (UCC7SVT macro)
R13 =
Address of 72-byte save area
R14 =
Return address to which control is returned
R15 =
Entry point of this exit
Output:
On return from the exit, the parameter list can contain the following parameters:
R15 =
Return code
00 = Use data. Exit can change the data and data length in the areas supplied.
01 = Delete this data from the data sent.
02 = Write the data and return before passing any more data (used to add data).
Note 1
A copy of the JQREC is provided to this exit for examination. The same copy is used on each call for
the job being processed. Only after the end of data/termination call is the JQUSER field of the JQREC
updated in the CA Workload Automation CA 7® Edition copy of the JQREC. No other information is
saved.
Do not modify this copy of the JQREC except for the JQUSER data field. This copy is used in submitting
the data to the cross-platform destination. Any inadvertent updates to the copy of the JQREC can
lead to errors in processing the job.
Browse Message - SASSXX17

The Browse Message exit monitors messages that are written to the CA Workload Automation CA 7®
Edition Browse data set. The exit cannot change or suppress Browse messages; however, it can issue
its own WTOs.
Caller: SASSDLOG using SLINK calls this exit. The exit must return control through SEXIT.
08-Feb-2018 678/722
Module Attributes: This exit must be coded reusable, but not necessarily reentrant. However, any
waits issued, explicit, or implicit, can have an impact on the performance of the CA Workload
Automation CA 7® Edition system.
We recommend that the APPLCTN statement for SASSXX17 uses ATTR=PERM or ATTR=RESD, but this
use is not required.
Input:
R2 = Address of a parameter list
+0 =
Address of 80-byte Browse message
+4=
Reserved for customer use
+8=
Reserved for future use
Output:
None
Note: Use EXITPARM EXIT=SASSXX17 to map the input parameters.
Command Exit - SASSXX09

The Command exit permits the user modification of CA Workload Automation CA 7® Edition
command input. The exit can support the use of command aliases.
Caller: SASSSSEC calls SASSXX09. This exit can be /RELINKed.
Module Attributes: Use reentrant coding for the exit.
Input:
R2 = Address of the parameter list
+0 = Value from SASSXXLX or zeros
+4 = Halfword containing length of input
+6 = 200-byte area containing input
+206 = 80-byte area for message
+286 = Halfword containing length of command output
+288 = 200-byte area containing command output
08-Feb-2018 679/722
Output:
R15 = Return code
0 = Accept command (use input as received)
4 = Change command (use output area and length)
R15 not 0 or 4 = Reject command and issue message
Note: Use EXITPARM EXIT=SASSXX09 to map exit parameters.
Console Terminal Output - SASSXX15

The Console Terminal Output exit monitors the output to the CA Workload Automation CA 7® Edition
console terminal. The exit can let the original WTO be issued or suppressed.
Caller: SASSWCSL calls this exit using BALR R14,R15 (NOT SLINK). This exit cannot be /RELINKed.
Module Attributes: Code this exit as reusable but not necessarily reentrant. However, any waits
issued, explicit, or implicit, cause the entire CA Workload Automation CA 7® Edition system to wait.
Input:
+0 =
Address of WTO list in the form MF=(E,(1))
Output:
R15 = Return code
0=
Do the original WTO
Not 0 =
Suppress the WTO
The APPLCTN statement for SASSXX15 must use ATTR=PERM or ATTR=RESD.
Database Load Processing - SASSXX12

The Database Load Processing exit is documented in the Online Exit Descriptions (see page 677).
More information:
08-Feb-2018 680/722
Database Load Processing (SASSXX12) (see page 677)
ENQ/RESERVE - SASSXX04
The ENQ/RESERVE exit can bypass ENQs or RESERVEs. When a SAVE, REPL, RENAME, or DELETE is
done from the DB.7 panel, CA Workload Automation CA 7® Edition issues either an ENQ or a RESERVE
to maintain integrity of the data set. With online systems, consider changing the QNAME or
completely bypassing the ENQ/RESERVE with this exit.
Note: This exit does not get control when the dynamic allocation feature is used. (See the
PERFORM keyword on INIT statement in the initialization file.)
Caller: This exit receives control through an SLINK from module SASSSM5C. This exit can be
/RELINKed.
Module Attributes: This exit must use reentrant coding.
Input:
+0 = Address of the QNAME (SYSDSN)
+4 = Address of the data set name
+8 = Address of the volume serial number
Note: If this exit is invoked from a system task, no saved value from SASSXXLX is present.
The value of the word at +12 is zero. Use EXITPARM EXIT=SASSXX04 to map exit
parameters.
Output:
R15 = 0 Issue the ENQ/RESERVE (QNAME can be changed)
R15 Not equal to 0, do not issue the ENQ/RESERVE
CA Workload Automation CA 7® Edition uses a QNAME of SYSDSN.
External DSN Access - SASSXX07

The External DSN Access exit permits user examination and possible checking of external data set
security. The exit is invoked when accessing a data set through CA Workload Automation CA 7®
Edition commands (for example, utilities, DB.7 panel).
08-Feb-2018 681/722
Caller: SASSSSEC calls this exit. This exit can be /RELINKed.
Input:
R2 = Address of the parameter list with the following values:
+0 =
2-byte hexadecimal UID of the terminal user
+2 =
Access code:
A = create (add/allocate)
R = read
S = scratch (delete)
W = write
+3 through +5 are reserved for future use
+6 =
Return code from the CA Workload Automation CA 7® Edition security checking, halfword of 0
if CA Workload Automation CA 7® Edition allows access or halfword of 4 if CA Workload
Automation CA 7® Edition restricts access.
Note: If a USERID module is not being used, a return code of 0 (zero) is passed.
+8 =
Address of 44-byte dsname
+12 =
Address of 8-byte member name or zero
+16 =
Address of 6-byte volume serial
+20 =
Value from SASSXXLX or zeros
+24 =
80-byte message area if RC not equal to 0
08-Feb-2018 682/722
parameters.
Output:
R15 = 0 if access is allowed, or 4 if access is restricted. Also place this return code in the
parameter list at offset+6 (see Input).
Note: This exit is not invoked in the following cases:
When writing to an FWLP data set as a result of the FWLP command
When logging to the browse data set
When data set name commands like LPDS or JCL(FETCH) access these data sets, they pass through
this exit. Also, run this exit only under user or terminal SCTs.
This exit is invoked for the following items:
Commands:
DEMAND(H)
RUN(H)
LOAD(H)
LJCK
LJCL
LLIB
LPDS
Any function of the DB.7 panel except CLEAR, DBM, EDIT
Utility commands that reference data set names:

AL/ALC
CAT
DMPCAT
DMPDSCB
DMPDSN
FIND
LISTDIR
LOC
MAP
RENAME
SCRATCH(P)
UNC
Forecast Worksheet - SASSXX08

The Forecast Worksheet exit can add text lines to Forecast Worksheets in the Report Summary
portion.
Caller: SASSXX08 receives control from module SASSSFCW. This exit can be /RELINKed.
08-Feb-2018 683/722
Input:
+0 = Address of the job name
+4 = Address of 74-byte output area
+8 = JQREC base address if job in queue (queue record for job)
+12 = SASJE base address (job data set member record)
+16 = SASSJOBR base address (job data set directory record)
Note: Use EXITPARM EXIT=SASSXX08 to map exit parameters.
Output:
R15 = Return code
0 = Do not write output area but continue processing
1 = Write output area and continue processing
2 = Write output area and return to exit (used to add lines)
JCL Attach Verification - SASSXX11

The JCL Attach Verification exit verifies that JCL is being attached from the correct library. The job can
be set to be left in SKELETON status or RETRY status in the request queue, or standard JCL attach
continues.
Caller: This exit is SLINKed (invoked) from SASSSCSR. This exit can be /RELINKed.
Module Attributes: This module must use reentrant coding.
Input:
+0 =
Address of the job queue record (mapped by macro JQREC)
+4 =
Address of the JCL table entry (mapped by macro JCLDSENT)
08-Feb-2018 684/722
+8 =
Address of the job directory (mapped by macro SASSJOBR) or zeros
+12 =
Address of the job member (mapped by macro SASJE) or zeros
Note: If a job is entering the request queue, but is not defined to the database, the
addresses for the job directory and job member are zeros.
Output:
R15 = 0 Continue with JCL attach
R15 = 4
Do not attach JCL, but set the job to RETRY status (if RETRY is not on, the status shows as
SKELETON).
R15 =
Any other value prevents the JCL attach (the job displays SKELETON status in the request
queue).
JCL Submission - SASSXX02

The JCL Submission exit adds, deletes, or changes JCL statements or control statements immediately
preceding job submission. Changes that are made to JCL by this exit are not reflected in the queue
JCL.
Caller: Control is passed to the exit from SASSSSM0. This exit can be /RELINKed.
Module Attributes: The exit must be coded as reusable, but not necessarily reentrant.
Input:
R2 = Address of parameter list
+00 =
Address of 80-byte area containing the JCL statement
+04 =
Address of job's queue record (mapped by the CA Workload Automation CA 7® Edition macro
- JQREC)
08-Feb-2018 685/722
+08 =
Fullword containing an entry code
1 - End of data call. SASSXX02 is not called at end of data for job unless CA Workload
Automation CA 7® Edition has been instructed to do so by flagging the communication area.
On the end of data call, the address at +00 points to a comment statement.
+12
Four-byte communication area used by exit to set calling options.
X'80' Instructs CA Workload Automation CA 7® Edition to call SASSXX02 at end of data. This
flag must be set for each job that is to receive an end of data call.
+16
Fullword reserved for use by exit. CA Workload Automation CA 7® Edition does not modify the
value in this area. The value is initialized to zeros for each job processed.
Output:
R15 = Return code
00 =
Write the statement and continue processing (the JCL statement is sometimes modified).
01 =
Delete this statement from the JCL.
02 =
Write the statement and return to the exit before fetching more JCL (used to add statements).
The job name and columns 67 through 71 in the JOB statement must not be changed. The only areas
in the parameter list that the exit can change are the communication area and the fullword reserved
for customer use. The exit must not modify any other areas in the parameter list.
Note: Use EXITPARM EXIT=SASSXX02 to map input parameters.
Users can modify a 20-byte user field in the JQREC DSECT. If modified, exercise care to use only the
specified 20 bytes. The JQUSER field is copied to the JQUSER field of any triggered job. The JQUSER
field is initialized (hex zeros) only when the job is initially placed into the REQQ by schedule scan and
DEMAND. This field is propagated for triggered jobs. This field is not initialized for restarted jobs.
Job Data Verification - SASSXX10

The Job Data Verification exit validates, modifies, or both the job data that is entered on the job
definition panel (DB.1, DB.10, or DB.11) for ADD, UPDATE, and DELETE functions for jobs being added
or replaced on the CA Workload Automation CA 7® Edition database. Also for CPU jobs (defined using
DB.1) loaded to the database through the load process, this exit is called.
Caller: This exit is SLINKed (invoked) from modules SASSSM28 and SASSSJL1. This exit can be
08-Feb-2018 686/722
Caller: This exit is SLINKed (invoked) from modules SASSSM28 and SASSSJL1. This exit can be
/RELINKed.
Module Attributes: The exit must use reentrant coding.
Input:
+0 =
Address of job directory record image (mapped by SASSJOBR)
+4 =
Address of job member record image (mapped by SASJE)
+8 =
Address of 8-byte message area.
On entry to exit this field contains one of the following strings to indicate the function and
caller:
CL8'JOBSADD' Add function on the DB.1 panel
CL8'JOBSREPL' Update function on the DB.1 panel
CL8'JOBSDEL' Delete or DD function on the DB.1 panel
CL8'LOADADD' Add processing from job load
CL8'LOADREPL' Update processing from job load
+12 =
Value from SASSXXLX or zero.
Output:
R15 = return code
0=
Continues with the requested function without changes.
4=
When received from the job definition panel, the ADD/UPDATE/DELETE fails with a SM20-05
or SM22-05 message, and the 8-byte message field is displayed with a notice that the user exit
caused the failure. This return code is ignored when the XX10 exit is entered during the job
load process.
8=
The user exit has modified data in the job directory and or the job member. The changes to
the records are applied to the CA Workload Automation CA 7® Edition database for the job
entry. The user exit is responsible for verifying that the modified data is in the correct format
to prevent corrupted job records on the CA Workload Automation CA 7® Edition database .
When the user exit returns a return code of 4 from the job definition panel, the user receives one of
the following messages:
SM20-05 INVALID OR OMITTED xxxxxxxx DATA, REJECTED BY USER EXIT
SM22-05 INVALID OR OMITTED xxxxxxxx DATA, REJECTED BY USER EXIT
The xxxxxxxx would be the 8-byte information supplied by the user exit.
08-Feb-2018 687/722
This exit is invoked after CA Workload Automation CA 7® Edition validates the UID access for the job.
This exit is invoked by and for the following:
The job definition panel ADD, UPDATE, DELETE, or DD function
Job adds during the CA Workload Automation CA 7® Edition job load process
Job updates during the CA Workload Automation CA 7® Edition job load process
Note: Use EXITPARM EXIT=SASSXX10 to map the input parameter list.
Job Name Verification - SASSXX01

The Job Name Verification exit validates a job name. The Job Name Verification exit must be
reentrant.
Caller: Control is passed to the exit from SASSSM2A. This exit can be /RELINKed.
Input:
+0 = Address of 8-byte area containing job name
Output:
R15 = 0 Job name is valid
R15 Not equal to 0 Invalid job name
Note: Code EXITPARM EXIT=SASSXX01 to map input.
CA Workload Automation CA 7® Edition validates that the job name is valid for OS before the exit
receives control.
If a nonzero return code is passed back in R15, the user receives a message as indicated in the
following:
This exit is invoked by and for the following:
The DB.1 panel ADD function. If error returned, message is the following:
SM20-05 INVALID OR OMITTED JOB DATA
The RUN(H) function on the DB.7 panel. If error returned, message is the following:
SM50-05 INVALID OR OMITTED JOBCARD DATA
08-Feb-2018 688/722
SM50-05 INVALID OR OMITTED JOBCARD DATA
Commands DEMAND(H), RUN(H), and LOAD(H) for a job not in the database. If error returned,
message is the following:
SPO7-01 JOBNAME - INVALID
Command ADDRQ to validate the DEPJOB value. If error returned, message is the following:
SPO4-02 ADDRQ UNSUCCESSFUL DEPJOB -- INVALID
Logoff Exit - SASSXXFF

The Logoff exit processes /LOGOFF commands from CA Workload Automation CA 7® Edition
terminals. The exit receives control when a /LOGOFF command is entered. SASSXXFF does not receive
control when the VLOGOFF PF key is pressed.
Application Name: SASSXXFF CAL2OPTN: AL2UM14
Caller: This exit receives control from SASSSSEC. This exit can be /RELINKed.
Input:
+0 =
Value from SASSXXLX or zeros
+4 =
8-byte USERID
+12 =
8-byte CA Workload Automation CA 7® Edition terminal name
+20 =
8-byte LU name (VTAMID)
Output:
R15 is ignored
Note: Use EXITPARM EXIT=SASSXXFF to map exit parameters.
Because SASSXXFF might not be called for every condition that can cause a terminal to be logged off
(or disconnected), it is called at logon time before the SASSXXLX exit is called. Thiscall is to allow for
any possible cleanup that is required. This means that this exit is called twice for each logged on
session: once when a normal logoff occurs and again when the next session is about to occur.
08-Feb-2018 689/722
Logon/Password Verification - SASSXXLX

The Logon/Password Verification exit monitors logons at CA Workload Automation CA 7® Edition
terminals. This exit is invoked before CA Workload Automation CA 7® Edition or external security
checking. If the exit accepts the logon, CA Workload Automation CA 7® Edition or external security
can still reject the logon. If the exit rejects the logon, more security validation is not performed.
Application Name: SASSXXLX CAL2OPTN: AL2UM13
Caller: SASSSSEC calls SASSXXLX. This exit can be /RELINKed.
Module Attributes: The exit must be coded reentrant. However, any waits issued, explicit, or implicit,
cause the entire CA Workload Automation CA 7® Edition system to wait.
Input:
+0 = Value that can pass to other exits
+4 = 8-byte USERID
+12 = 8-byte password
+20 = 8-byte new password
+28 = 8-byte CA Workload Automation CA 7® Edition terminal name
+36 = 8-byte LU name (VTAMID)
+44 = 8-byte APPL value from SECURITY statement
+52 = 40-byte PARMS from LOGON panel or command
+92 = 80-byte message area for logon errors
+172 = 8-byte UID resource name
+180 = 1-byte length of a long (>8) password
+181 = 100-byte field that contains the long password
+281 = 1-byte length of a new long (>8) password
+282 = 100-byte field that contains the new long password
Note: Use EXITPARM EXIT=SASSXXLX to map exit parameters.
Output:
R15 = Return code
0 = Accept the logon
08-Feb-2018 690/722
0 = Accept the logon
2 = Accept the logon and allow the user ID, password, and new password fields to change
6 = Accept the logon and skip the CA Workload Automation CA 7® Edition external security
check
To use this return code, omit the EXTERNAL keyword or only specify LOGON
Not 0 or 2 or 6 = Reject the logon and display message
If the exit rejects the logon, an 80-byte message appears. The text of this message is provided by the
exit by modifying an area at R2 +92.
Even if the SASSXXLX exit is used to modify the user ID of the person logging on to CA Workload
Automation CA 7® Edition, the original user ID is still used in the history reports produced by program
SASSHIS8.
Usage Notes
If a long (>8) password is being passed, the length fields contain the length of the data and the short
password/new password fields are blank. If these length fields are zero, the short password/new
password fields are populated.
Personal Scheduling Verification - SASSXX14

The Personal Scheduling Verification exit examines, and accepts or rejects function requests that are
entered on the CA Workload Automation CA 7® Edition Personal Scheduling panel. If rejected, the
exit can pass a 60-byte message to display on the user panel. This exit lets you enforce local
standards in the Personal Scheduling facility. For example, you want all Personal Scheduling jobs to
have a T in the fourth position of the job name. Or, you want to restrict that JCL-IDs can be accessed
from Personal Scheduling.
Caller: SASSPS00 calls this exit. This exit can be /RELINKed.
Module Attributes: This exit must be coded reentrant.
Input:
+00 =
Value from the SASSXXLX logon exit or zero.
+04 =
Address of an 8-byte field containing panel function (ADD, DELETE, LIST, STATUS, SUBMIT, or
UPDATE)
+08 =
Zero or address of an 8-byte field containing job name
08-Feb-2018 691/722
+12 =
Zero or address of a 2-byte field containing JCL-ID (in hex)
+16 =
Zero or address of an 8-byte field containing pattern job name
+20 =
Zero or address of a 2-byte field containing time (in hex, hhmm)
+24 =
Zero or address of an 8-byte field containing predecessor
+28 =
Address of 60-byte field for an error message if the exit rejects the request
+32 =
Zero or address of a 16-byte field containing JCLLIB
Output:
R15 = Return code
0=
Let the processing for the request continue.
Not 0 =
Reject the request. The user receives the following messages:
PS00-16 REQUEST REJECTED BY SASSXX14 USER EXIT
... xx14 error message (if set by exit).......
Note: This exit can only accept or reject personal scheduling requests. The exit cannot
change the request itself.
The exit is invoked after the FUNCTION has been validated. A security check is made to verify that the
current user has authority to issue that function on the Personal Scheduling panel. Validation of any
other fields will be performed only after the call to SASSXX14 has been made. The request can
eventually be rejected even though the user exit has accepted it.
08-Feb-2018 692/722
Queue Entry JCL - SASSXX05

The Queue Entry JCL exit lets you add, delete, or change JCL statements or control statements at the
time execution JCL is attached to a job in the request queue. Also, you can modify the JQUSER field in
the JQREC header (a 20-byte user-defined field) if wanted. Any changes that are made to the JCL in
this exit are reflected in the trailer queue JCL.
Caller: This exit is SLINKed from SASSSCJL and SASSSM50. This exit can be /RELINKed.
Input:
+0 = XL1 function code
X'00' - JCL record is being passed
X'04' - Return from add
X'08' - End of data
X'0C' - Wrap-up call
+1 = AL3 address of 80-byte statement
+4 = AL4 address of JQREC header
+8 = AL4 4-byte exit work area (zero upon initial call for each job)
parameters.
Output:
R15 =Return code
0=
Write this statement and keep processing (this statement might have been modified). If the
end of data is reached, then a 0 return tells CA Workload Automation CA 7® Edition to close
the JCL stream and not to add to it.
1=
Delete this statement from the JCL.
08-Feb-2018 693/722
2=
Write the statement and return to the exit (used to add statements).
16 =
Cancel the job.
32 =
Process new #SCC card for the job and return to the exit.
Do not change the job name. Do not change the addresses in the parameter list.
Note: If hex data is put in the JCL, it probably causes problems when displaying from the
queues (for example, QJCL and LQ,LIST=JCL).
A job cannot be canceled in the wrap-up call. That is, a return code of 16 is not honored when the
entry function code is X'0C'.
If a statement is bypassed due to #JI or #JO scheduled override parameters, the statement is not
passed to this exit.
Step Condition Code (#SCC) cards can be added with a special return code decimal 32. #SCC cards
that are present in the original JCL are processed before the SASSXX05 exit is engaged. They are not
presented to the SASSXX05 exit. The only way to introduce new #SCC cards from the exit is with this
special return code. The inserted #SCC card is processed as if it were in the original JCL, and control is
returned to the exit. Processed #SCC cards do not appear in the resulting queue JCL.
SMF Feedback - SASSXX13

The SMF Feedback exit examines, modifies, or deletes SMF extracts retrieved from the CA Workload
Automation CA 7® Edition communications data set using the SASSXX13 exit.
Caller: SASSXX13 is entered through SLINK from SASSSMF0. SASSXX13 must return control to CA
Workload Automation CA 7® Edition through SEXIT. This exit can be /RELINKed.
Module Attributes: Calls to the exit are single threaded and occur under the control of the SASSSMF0
SCT. Make the exit reusable.
Note: Because SMF feedback processing is a function critical to the proper execution of CA
Workload Automation CA 7® Edition, we strongly recommend that you limit processing in
SASSXX13 to routines of short duration. Any activity that results in a suspension or even
slight degradation of the SMF feedback processing likely affects CA Workload Automation
CA 7® Edition performance adversely.
Input:
08-Feb-2018 694/722
Input:
R2 = Address of the parameter list (mapped by EXITPARM)
+0 =
Return code value set by SASSXX13
0 - continue processing with this SMF extract
4 - allow this SMF extract to be modified
8 - do not continue processing with this SMF extract
+4 =
Address of the SMF extract (see the following note)
+8 =
+12 =
Reserved
R10 =
Address of SASSXX13 entry point. (Set by SLINK macro processing)
R11 =
Address of the SASSSMF0 SCT
R12 =
Address of the UCC7SVT
Note: The SASSXX13 exit must not modify R11 and R12 .
R15 =
Address of SASSXX13 entry point
Output:
The return code in the parameter list pointed to at entry is used to determine the action to be
taken on the SMF extract. The value set in R15 by SASSXX13 is ignored.
Related Messages:
If the SASSXX13 is used, the following WTO can be issued:
CA-7.SMF0 - BAD LRECL FROM SASSXX13, EXIT DISABLED
This indicates that the LRECL of a record modified by SASSXX13 was less than 8 or greater than
1024. If this condition occurs, no further calls are made to the SASSXX13 exit.
Additional Notes:
For information about the format of the SMF extracts, see the SASS7LOG macro, record types 04,
05, 0E, 0F, 14, 76, and 90-9F.
08-Feb-2018 695/722
SMF WTO Message (SASSXX16)

The SMF WTO Message exit monitors CA-7.SMF3, CA-7.SMF4, or both WTOs that are generated.
These optional WTOs are generated to indicate unsuccessful job/step terminations. The exit can
allow the original WTO to be issued or suppress it.
Caller: Called by SASSSMF3 and SASSSMF4 using BALR R14,R15 (NOT SLINK). Registers 0 - 14 are
saved prior to calling the exit and restored on return. This exit cannot be /RELINKed. The exit is called
by SASSSMF3 for WTO CA-7.SMF3 if the WTO= option is set on the CA Workload Automation CA 7®
Edition RESTART initialization statement. The exit is called by SASSSMF4 for WTO CA-7.SMF4 if the
WTOSTEP= option is set on the CA Workload Automation CA 7® Edition RESTART initialization
statement.
Module Attributes: This exit must be coded reusable, but not necessarily reentrant. However, any
waits issued, explicit or implicit, cause the entire CA Workload Automation CA 7® Edition address
space to wait.
The APPLCTN statement for SASSXX16 must use ATTR=PERM or ATTR=RESD. Keep code in this user
exit to a minimum to ensure that the timing of the SMF feedback process in CA Workload Automation
CA 7® Edition is not degraded.
Input:
+0 =
Address of a copy of the SMF extract (mapped by macro SCOMREC)
+4=
Address of a copy of the job queue record (mapped by macro JQREC)
+8=
Address of a copy of the WTO in MF=(E,(1)) format
+12 =
+16 =
Reserved for future use
Output:
R15 = Return code
0=
Issue the WTO
Not 0 =
Suppress the WTO
08-Feb-2018 696/722
Statement Modification Exit for CPU Job Submission - SASSXX20

The Statement Modification Exit for CPU Job Submission adds, deletes, or changes JCL statements or
control statements immediately preceding CPU job submission. The queue JCL does not reflect
changes that are made to JCL by this exit. This exit is not invoked if PSP=NO is in effect. PSP=NO is in
effect either explicitly coded on the OPTIONS statement in the CA Workload Automation CA 7®
Edition initialization file or forced due to environmental restrictions).
The exit is similar in purpose and behavior to the SASSXX02 exit. But the execution environment is
different. Because SASSXX02 is intended for use when CPU jobs are submitted serially, it does not
require reentrant coding. However, SASSXX20 can execute in several tasks concurrently. For that
reason, SASSXX20 requires reentrant coding.
Also, importantly, notice that the CA Workload Automation CA 7® Edition main task services are
available to SASSXX02. This is not the case with SASSXX20. SASSXX20 can use the SASSVRSN macro for
entry/exit logic as demonstrated in the sample program stub included in the related USERMOD in CA
Workload Automation CA 7® Edition Options library (CAL2OPTN) member AL2UM46 but cannot use
any other CA Workload Automation CA 7® Edition main task service.
Caller: Control is passed to the exit from SASSSO30. This exit cannot be refreshed using /RELINK.
Note: This exit is called only for CPU jobs. SASSXX21 is called for XPJOB jobs and SASSXX22
is called for agent jobs.
Module Attributes:The exit must be coded as reusable and reentrant.
Input:
R1 = Address of a work area mapped by XX20DSCT (generated by EXITPARM macro)
+0 =
Address of 18 word save area for use by exit.
+4 =
Address of 80-byte JCL statement
+8 =
Address of read-only copy of JQREC (the JQREC macro can map this area).
+12 =
Fullword entry code that can be used to control exit behavior.
0 - not end of data call
1 - end of data call. SASSXX20 is not called at end of data unless the exit communications
area has been flagged to do so.
08-Feb-2018 697/722
+16 =
Four-byte communication area used by exit to set calling options.
X'80' Instructs CA Workload Automation CA 7® Edition to call SASSXX02 at end of data. This
flag must be set for each job that is to receive an end of data call.
+20 =
Fullword reserved for use by exit. CA Workload Automation CA 7® Edition does not modify the
value in this area. The value is initialized to zeros for each job processed.
+24 =
Fullword value
0 = Write the statement and continue processing

(the JCL statement is sometimes modified).
1 = Delete this statement from the JCL.
2 =Write this statement and return to the exit before fetching

additional JCL (used to add statements).
R13 = Address of standard 18 word save area (A save area for use by the exit is provided in the
XX20DSCT work area).
R14 = Return address
R15 = Address of SASSXX20 entry point
Output:
R15 = Return code. Recognized values follow (they are also documented in the XX20DSCT
generated by the EXITPARM macro).
0 = Write this statement and continue processing
1 = Delete this statement
2 = Write this statement and return to exit before fetching another statement (used to add
statements).
Utility Function Security Checking - SASSXX03

The Utility Function Security Checking exit rejects utility requests. The exit must be reentrant. The
utility commands specified in the following call this exit.
Caller: This exit receives control through an SLINK from one of the following modules:
SASSUTL3
SASSUTL4
SASSUTL5
SASSUTL6
08-Feb-2018 698/722
This exit can be /RELINKed.
Module Attributes: This module must use reentrant coding.
Input: R2 =
Address of the parameter list. This list varies with the function. The first word in the parameter
list points to an 8-byte area containing the function to perform. (The command that was entered.)
The following table explains other offsets in the parameter list:
AL or ALC (Allocate or allocate and catalog)

+4 = Address of 44-byte DSN
+8 = Address of 6-byte volume serial number
BLDG (Build GDG index)
+4 = Address of the 44-byte index name
CAT (Catalog)
+8 = Address of 30-byte area containing one to five volume serial numbers
+12 = Address of 6-byte volume serial number if CVOL specified, zero if CVOL was not specified.
CONN (Connect index)
+4 = Address o the 8-byte index name
DCONN (Disconnect index)
DLTX (Delete index)
+8 = Not used
+12 = Address of 6-byte volume serial number if CVOL specified, zero if CVOL was not specified.
RENAME (Rename data set)
+12 = Address of last 96 bytes of format 1 DSCB
+16 = Address of 44-byte new name
SCRATCH (Scratch a data set or scratch a protected data set)
SCRATCH
P
+12 = Address of last 96 bytes of format 1 DSCB
UNC (Uncatalog a data set)
08-Feb-2018 699/722
Note: In all cases, at +24 in the parameter list is a word that contains a value set on the
SASSXXLX exit or zeros. Use EXITPARM EXIT=SASSXX03 to map these parameters.
Output:
R15 = 0 Process the request
R15 Not equal to 0 Reject the request
XPJOB Submission - SASSXX21

The XPJOB Submission exit examines and modifies fields immediately before data is sent to a cross-
system Workload Automation Scheduling Agent. This exit is invoked as the control block to send to
the destination agent is being built. The exit is invoked once for logon information (user ID, password,
and Domain name). The password is never passed to the exit, but the exit can return a password,
which is then encrypted and used in the data sent. The exit is then invoked with each parameter
specified by the parameter data (PARM01 - PARM64). If no parameters are being passed, none of
these calls are made. Next, the exit is invoked for a cleanup call, in which the exit can only free its
storage and return to CA Workload Automation CA 7® Edition.
Note: This does not apply to CA7TOUNI jobs.
Caller: The SASSXX21 exit is called by SASSSO60, which executes as a subtask in the CA Workload
Automation CA 7® Edition environment (not on the main task). As such, this exit cannot request any
services of the CA Workload Automation CA 7® Edition main task, such as queue or database access.
Note: This exit is called only for XPJOB jobs. SASSXX20 is called for CPU jobs, and SASSXX22
is called for agent jobs.
Module Attributes: This module must have the following attributes:
RENT, REUS
AMODE(24)
RMODE(24)
08-Feb-2018 700/722
SASSXX21 can use the SASSVRSN macro for entry/exit logic as demonstrated in the sample program
stub included in the related USERMOD in CA Workload Automation CA 7® Edition Options library
(CAL2OPTN) member AL2UM47. SASSXX21 cannot use any other CA Workload Automation CA 7®
Edition main task service.
Input:
On entry to the exit, the parameter list can contain the following parameters:
R1 =
Address of parameter list
+ 0 = A(72-byte save area for use by exit)
+ 4 = A(Keyword for the data passed); See the following note
+ 8 = MAX Length for the data associated with keyword
+12 = A(Data for the keyword)
+16 = Function code:
1 - End of data; termination call
+20 = A(Copy of JQREC); See Note 2
+24 = A(0) that the exit can modify during the processing of a single job. The value is not saved
across different jobs. CA Workload Automation CA 7® Edition does not examine or use this
field.
R12 =
Address of CA Workload Automation CA 7® Edition System Vector Table (UCC7SVT macro)
R13 =
Address of 72-byte save area
R14 =
Return address to which control is returned
R15 =
Entry point of this exit
Output:
On return from the exit, the parameter list can contain the following parameters:
R15 =
Return code
00 = Use data for this keyword (exit can change data in the area supplied).
01 = Delete this keyword from the data sent.
02 = Write the data for this keyword and return before passing any more data (used to add
data).
Note 1
The keywords that are passed to this exit are the following, with the data length permitted.
Keyword Length Description

LOGON 61 Security Information
This information is the combination of the following:
User ID=32 Bytes
08-Feb-2018 701/722
Keyword Length Description

User ID for XPJOB.
PASSWORD=14 Bytes
Always blanks when calling the exit because passwords are sensitive data. If the field
is left blank, no changes are done. If the data on return is not blanks, that data is
used as the password for the user ID.
DOMAIN =15 Bytes
WINDOWS NT Domain name.
FILE 256 Execution specification (File or Script).
PARMN 256 Parameter data, where NN is from 01 to 64.
N
Note 2
A copy of the JQREC is provided to this exit for examination. The same copy is used on each call for
the job being processed. Only after the end of data/termination call is the JQUSER field of the JQREC
updated in the CA Workload Automation CA 7® Edition copy of the JQREC. No other information is
saved.
Do not modify this copy of the JQREC except for the JQUSER data field. This copy is used in submitting
the data to the cross-platform destination. Any inadvertent updates to the copy of the JQREC can
lead to errors in processing the job.
Standard Exit Descriptions

The standard exits are the.Database Load Processing - SASSXX12 and the Problem Management
Interface exit.
Database Load Processing (SASSXX12) (see page 702)

Problem Management Interface Exit (see page 704)
Database Load Processing (SASSXX12)

The Database Load Processing exit examines, modifies, or deletes records used to update the CA
Workload Automation CA 7® Edition database that the SASSJJCL program created. One possible use
of the exit is examining a DSN that is ready to load into the CA Workload Automation CA 7® Edition
database. If the DSN for loading matched a DSN in a site defined table, the exit could force the
identification of the data set as PERM in CA Workload Automation CA 7® Edition.
Caller: SASSJJCL calls this exit. This exit cannot be /RELINKed.
Module Attributes: This module is not required as reentrant. This module is LOADed once per
execution of SASSJJCL. This exit observes standard MVS linkage conventions.
Input:
R1 = Address of parameter list (mapped by EXITPARM)
+0 =
08-Feb-2018 702/722
+0 =
Return code value set by SASSXX12
0 - write the load record
4 - do not write the load record
+4 =
Value of R1 at entry to SASSJJCL
+8 =
Address of the ICMDSECT used by SASSJJCL
+12 =
Code indicating the type of IBM record currently examined by SASSJJCL:
1 - JCT
2 - SCT
3 - SIOT/JFCB
4 - SSWA
+16 =
Address of the IBM record currently examined by SASSJJCL
+20 =
Type of CA Workload Automation CA 7® Edition database load record
+24 =
Address of CA Workload Automation CA 7® Edition database load record
If this value is zero, SASSXX12 is called to allow examination of the IBM records used by
SASSJJCL. The return code set by SASSXX12 for these calls is ignored.
If this value is not zero, this word points to the database load record that can be modified.
The SASS7LOG macro can map database load records.
Note: Do not modify the length of the record.
+28 =
One word reserved for customer use
R13 = Address of standard 18 fullword save area
R14 = Return address
R15 = Address of SASSXX12 entry point
Output:
The return code in the parameter list pointed to at entry determines whether the CA Workload
Automation CA 7® Edition database record is written. The value set in R15 by SASSXX12 is
ignored.
08-Feb-2018 703/722
Related Messages:
If SASSXX12 is used, SASSJJCL termination produces the following summary messages:
CA-7.112 xxxxxxxx LOAD RECORDS CHANGED BY SASSXX12
CA-7.113 yyyyyyyy LOAD RECORDS DELETED BY SASSXX12
xxxxxxxx
Identifies the total number of database load records modified.
yyyyyyyy
Identifies the total number of database load records deleted by the SASSXX12 exit.
Additional Notes:
For information about the format of the records created by the SASSJJCL program, see the
SASS7LOG macro. Look at record types 90, 91, 92, 93, 94, and 95.
Problem Management Interface Exit

The Problem Management Interface Exit is declared as the EXIT keyword value on the NETMAN
statement in the CA Workload Automation CA 7® Edition initialization file. The purpose of the exit is
to permit the inspection of CA Workload Automation CA 7® Edition job completion data for problem
tracking.
Application Name: Customer specified.
Important! Starting with CA Netman r4.9, this exit is not needed. Do not specify this exit
because an internal exit is used. Specifying it here disables the automatic existing exit.
The NETMAN statement in the initialization file is still needed when you want the interface, but do
not specify the exit. If you use a version before r4.9 of CA Netman or some other problem
management interface, use this exit to get control and inspect CA Workload Automation CA 7®
Edition job completion data.
Caller: SASSPM00 calls this exit. This exit cannot be /RELINKed. The module is LOADed at CA
Workload Automation CA 7® Edition initialization and control is passed using BASR R14,R15. Because
the module is called from the CA Workload Automation CA 7® Edition Problem Management Subtask,
CA Workload Automation CA 7® Edition Main Task services such as SGETM and SWAIT are not
available. Use MVS services instead.
Module Attributes: The module is not required to use reentrant coding. Link the exit AMODE 31,
RMODE ANY.
Input:
R1 = Address of area mapped by the DSECT L2PM. The L2PMA macro generates this DSECT. The
area contains information about the completion of a CA Workload Automation CA 7® Edition
submitted job.
R12 =
Address of UCC7SVT
R13 =
08-Feb-2018 704/722
R13 =
Address of 18 word save area
R14 =
Return address
R15 =
Module entry point address
Output:
No significant output occurs. The return code in R15 is ignored.
Note: Job completion information is passed to the exit in the order that jobs complete.
If GOODCOMP=N is coded on the NETMAN statement in the CA Workload Automation CA 7® Edition

initialization file, only information about abnormal job completions and their typically complete
restarts is passed to the exit. This value is the default. If GOODCOMP=Y is coded, information about
all CA Workload Automation CA 7® Edition job completions is passed to the exit.
APA Graph Modifications

These topics discuss the changes that you can make to the Automated Performance Analysis (APA)
graph facility.
Change Graph Definitions (see page 705)

Add Counters for New Graphs (see page 708)
Change Graph Definitions

The APA facility provides numerous graphs on CA Workload Automation CA 7® Edition performance
and activities. Users can also define their own graphs, modify graph titles, and so forth, that are
provided with the system. All definitions/redefinitions must be made in the APA graph tables.
Graph Table Definition

Graphs to reference through APA are predefined and link edited to the load library. The object
module from this assembly has been link edited with the following standard name (one for each of
the categories of graphs):
SASSGPHx
x
Represents one of the following values:
D
Specifies database graphs table.
08-Feb-2018 705/722
J
Specifies job graphs table.
N
Specifies network graphs table.
S
Specifies system graphs table.
DEFGRPH Macro
Use the DEFGRPH macro in the SASSGPHx modules to define graph tables that are used in the
automated performance analysis (APA) application.
Use the following format to generate each graph definition:

DEFGRPH ID=nnnn,HDR1='header1',CTR1=(xxxxxxxx,nnnnn)
[,HDR2='header2']
[,SEP={NO|YES}]
[,CTR2=(xxxxxxxx,nnnnn)]
[,GLINE={PRIM|SCND|CALC}]
[,SCALE={2|nnnnn}]
[,TYPE=({COMP|SINGLE},{TOTAL|NOTOTAL},{NONE|x})]
ID
Indicates a required identification number, up to four digits, which are assigned to each graph.
The number must be unique only within each graph definition table. When coding multiple graph
definitions, this identification number must be in ascending numerical sequence in regard to
other DEFGRPH macros.
HDR1
Indicates a required heading, up to 35 characters, to appear as the title line of the graph. Enclose
the value in single quotes.
HDR2
Indicates an optional heading, up to 35 characters, to append to the value defined for HDR1 to
make a title longer than 35 characters. Enclose the value in single quotes.
SEP
Indicates an optional specification to request the four characters ' VS ' (VS preceded and followed
by a blank where VS means versus) as a separator between the character values of HDR1 and
HDR2. If NO separator is requested, the two heading values are concatenated, therefore
permitting up to 70 positions of heading data. The default is NO.
CTR1
Indicates a required parameter describing the primary counter that is used in the graph. The
parameter consists of two subparameters that are enclosed in parentheses.
xxxxxxxx
Indicates a required assembler label, up to eight characters, describing a field name that is
found in the STATAREA macro DSECT. The length attribute of the field name is calculated by
the assembler and must be 4 bytes, 2 bytes, or 1 byte in length. Any other specification causes
unpredictable results.
nnnnn
08-Feb-2018 706/722
nnnnn
Indicates an optional numeric value in the range from 1 to 99999 describing the division factor
for the graph. This value can be used to convert seconds to minutes, minutes to hours, and so
on, if the value accumulated in the counter is not what is wanted for the graph. The default is
1.
CTR2
Indicates required only if TYPE=COMP. The value describes a secondary counter that is used in
comparison graph. CTR2 is coded in same format as CTR1.
GLINE
Indicates an optional parameter describing the value to represent on the output graph line. The
value must be one of the following choices:
PRIM
Use primary counter for graph line. PRIM is the default.
SCND
Use secondary counter for graph line.
CALC
Use calculated value for graph line.
SCALE
(Optional) Supplies the default increment value in calculating the length of the graph scale. The
value must be a numeric value in the range from 1 to 99999. The default is 2.
TYPE
(Optional) Defines how to report the statistics. TYPE consists of three subparameters that are
enclosed in parentheses.
Indicates type of graph as follows:
COMP
Comparison graph (two counters required). COMP is the default.
SINGLE
Single counter graph.
Indicates whether a total line should appear as follows:
TOTAL
Formatted total line. TOTAL is the default.
NOTOTAL
No formatted total line
Indicates type of calculation as follows:
NONE
No calculation. NONE is the default.
x
The following values are possible:
08-Feb-2018 707/722
A
Addition (CTR1+CTR2)
D
Division (CTR1/CTR2)
R
Running Total (for SINGLE graphs only)
P
Percentage (CTR2/CTR1)
S
Subtraction (CTR1-CTR2)
N
Negative replacement (CTR2=CTR1-CTR2, percentage calculation assumed)
Add Counters for New Graphs

Provided counters let you accumulate up to ten items of information in addition to those items that
CA Workload Automation CA 7® Edition already accumulates. Reserved are ten halfword user
counters (STUSER1 through STUSER10) that are available to the user for creating reports. You can add
more graphs for these counters. Supply the required information in the appropriate graph table
module.
Queue Entry JCL Exit Example

The following example shows the Queue Entry JCL user exit (SASSXX05). The example uses the
BMPSTAT macro to increase a counter (STUSER1) in the STATAREA.
Suppose that you want a graph displaying the number of jobs that are scheduled from Department
XX. Assume that you can determine the originating department by examining positions 3 and 4 of the
job name. The following program could be used for the SASSXX05 JCL attach exit:
SASSXX05 START
PRINT NOGEN
UCC7SVT
SASSEQU
STATAREA
JQREC
SASSXX05 CSECT
SASSVRSN REGS=R10 SET BASE ADDRESSABILITY
L R3,4(R2) JQREC HDR
USING JQREC,R3
CLI 8(R2),0 INITIAL CALL
BNE ENDXX05 B IF NOT
MVI 8(R2),255 SET INDICATOR
CLC JQJNAME+2(2),=C'XX' DEPARTMENT XX
BNE ENDXX05 B IF NOT
BMPSTAT F=STUSER1,T=H,NOSTAT=ENDXX05 ADD 1 TO HALFWORD
* COUNTER 'STUSER1'
ENDXX05 SR R15,R15 SET RETURN CODE
SEXIT
END
08-Feb-2018 708/722
Define Single Graphs

After you assemble and link edit the exit, modify, assemble, and link-edit SASSGPHJ after inserting a
DEFGRPH macro to define the wanted graph similar to the following example:
10 16 72
| | |

DEFGRPH ID=8743, X
TYPE=(SINGLE,NOTOTAL,R), X
SCALE=5, X
CTR1=(STUSER1,1), X
HDR1='JOBS SCHEDULED BY DEPT XYZ'
Define Comparison Graphs

Instead of only reporting the number of jobs from Department XX, suppose that you wanted to find
out the percentage of total jobs scheduled compared to those jobs scheduled by Department XX
only. This information involves a comparison graph. The procedures are the same as those
procedures given for a single counter graph except the DEFGRPH macro is similar to the following
example:
10 16 72
| | |

DEFGRPH ID=7510, X
TYPE=(COMP,TOTAL,P), X
SCALE=2, X
CTR1=(STSCHDS,1), X
CTR2=(STUSER1,1), X
GLINE=CALC, X
HDR1='TOTAL JOBS SCHEDULED', X
HDR2='JOBS SCHEDULED BY DEPT XYZ' X
SEP=YES
Other System Modification Techniques

In addition to user exits and security, users can make a wide variety of alterations that these topics
explain.
Batch Interface Message Table - SASSXXBT (see page 709)

Generic Unit Name/Device Type Table - SASSUTBL (see page 711)
Suppress Messages - SASSMSGS (see page 712)
CA Driver Customization - CA7AGENB (see page 712)
Reserved DDname Table - SASSPMDD (see page 712)
EBCDIC/ASCII Translation Tables - CAL2XLAT (see page 713)
Function Aliases for Formatted Panels (see page 713)
Batch Interface Message Table - SASSXXBT

Application Name: SASSXXBT CAL2OPTN: AL2UM12
08-Feb-2018 709/722
The Batch Terminal Interface (BTI) facility and the CA Workload Automation CA 7® Edition CAICCI and
TCP/IP Batch Interfaces let you issue CA Workload Automation CA 7® Edition commands from a batch
job rather than an online terminal.
Exit Purpose: The CA Workload Automation CA 7® Edition Batch Terminal Interface process (BTI) and
the CA Workload Automation CA 7® Edition CAICCI and TCP/IP Batch Interfaces use the SASSXXBT
Message Table as follows:
Detect error and warning messages in batch output.
Set a nonzero return code for the batch job step.
The SASSXXBT module is not executable. The module is a table of messages (or message prefixes) and
condition codes to be associated with those messages. When the batch terminal interface (BTI)
program or the CA Workload Automation CA 7® Edition CAICCI or TCP/IP Batch Interface transfers the
CA Workload Automation CA 7® Edition command output from the output data set to SYSPRINT, each
line is checked against the SASSXXBT table for matches. If an output line is matched with the table,
CA Workload Automation CA 7® Edition writes an information message to the ERRORS DD noting the
text of the line that was matched and the associated condition code from the table.
At the end of BTI or CA Workload Automation CA 7® Edition CAICCI or TCP/IP Batch Interface
processing, if any output lines were matched against the table a WTO is issued indicating the number
of messages matched and the highest condition code. The return code for the batch step is then set
to the highest condition code matched.
Coding:
The SASSXXBT table module is coded using the $L2BTI macro that is in the CA Workload Automation
CA 7® Edition Macro library (CAL2MAC). The assembled module must be in a load library accessible to
the following:
The BTI program SASSBSTR.
The CA Workload Automation CA 7® Edition CAICCI Batch Interface program CAL2X2WB.
The CA Workload Automation CA 7® Edition TCP/IP Batch Interface program CAL2X2TB (that is, in
the STEPLIB concatenation for the BTI, CAICCI, and TCP/IP batch steps).
Each use of the macro defines a separate message in the table. An online example of the source for a
SASSXXBT table is in the AL2UM12 member of the CA Workload Automation CA 7® Edition Options
library (CAL2OPTN).
The following is a coding sample:

SASSXXBT START
*--------------------------------------------------------------------*
* SAMPLE SASSXXBT ERROR MESSAGE TABLE *
* *
* INDIVIDUAL MESSAGES ARE DEFINED USING THE $L2BTI MACRO. EACH *
* ENTRY HAS THE MESSAGE TEXT (MSG=), AND THE CONDITION CODE TO BE *
* ASSOCIATED WITH THAT MESSAGE (CC=). *
* *
* THE MESSAGE TEXT (MSG=) IS REQUIRED. THIS TEXT WILL BE COMPARED *
* WITH EACH LINE OF BATCH OUTPUT STARTING IN COL 1 FOR THE LENGTH *
* OF THE MSG= TEXT. THE LENGTH OF THE MSG= TEXT CAN BE AS LONG OR *
* AS SHORT AS YOU WANT, BUT IT MUST EXACTLY MATCH THE BATCH OUTPUT *
* LINE IN ORDER TO BE CONSIDERED A HIT. IF THE TEXT CONTAINS *
08-Feb-2018 710/722
* LINE IN ORDER TO BE CONSIDERED A HIT. IF THE TEXT CONTAINS *
* EMBEDDED BLANKS OR COMMAS IT MUST BE ENCLOSED IN QUOTES (THE *
* QUOTES WILL NOT BE USED IN THE COMPARES). *
* *
* THE CONDITION CODE (CC=) IS NOT REQUIRED. IF OMITTED IT WILL *
* DEFAULT TO 4. YOU CAN USE ANY NUMBER FROM 1 TO 255, EXCEPT 8, *
* 16, AND 24 WHICH ARE RESERVED. *
* *
*--------------------------------------------------------------------*
*
*- THIS ENTRY IS FOR THE JOB NOT FOUND MESSAGE FROM AN LJOB COMMAND
*- (NOTE: SINCE THERE IS NO CC= THE CONDITION CODE DEFAULTS TO 4)
*
$L2BTI MSG=SLIA-02
*
*- THIS ENTRY IS FOR THE DSN NOT FOUND MESSAGE FROM AN LDSN COMMAND
*- (NOTE: THE CONDITION CODE IS EXPLICITLY SET TO 5.)
*
$L2BTI CC=5,MSG=SLIB-02
*
*- THIS ENTRY IS FOR THE MESSAGE YOU GET WHEN TRYING TO ADD A JOB
*- THAT ALREADY EXISTS. (NOTE: SINCE THE TEXT HAS EMBEDDED BLANKS
*- IT HAS TO BE ENCLOSED IN QUOTE MARKS.)
*
$L2BTI CC=7,MSG='SM20-07 JOB ALREADY EXISTS'
*
*- THIS ENTRY IS FOR THE MESSAGE YOU GET WHEN TRYING TO DEMAND A
*- JOB THAT IS NOT DEFINED. (NOTE: THERE ARE TWO
*- BLANKS BETWEEN THE MESSAGE ID AND THE MESSAGE TEXT. IT HAS TO
*- BE DEFINED THIS WAY TO EXACTLY MATCH THE TEXT IN THE OUTPUT.)
*
$L2BTI CC=7,MSG='SPO7-21 JOB NOT DEFINED AND JCLID'
*
END
Generic Unit Name/Device Type Table - SASSUTBL

SASSUTBL provides a relationship between a generic unit name and an actual device type. A sample
SASSUTBL is distributed with the system. List and modify the sample as necessary to meet installation
requirements for generic unit names. Each entry in the unit/device code table consists of a generic
unit name in up to eight characters followed by a 4-byte hexadecimal device code. For example:
DC CL8'3330',X'30502009'
The device code (X'30502009' in the example) must match a device code in the IBM device name
table.
SASSUTBL is used for the LOAD process, for analyze commands, and for utility commands such as
CAT. Therefore, information about data sets in the database is taken from this table. The information
is displayed for forecast and general inquiry commands and is used by workload balancing.
See AL2UM03 in the CA Workload Automation CA 7® Edition Options library (CAL2OPTN) for a sample
SMP/E USERMOD.
More information:
Define the Types of Tape Drives (https://wiki.ca.com/display/CWAC7E

/Define+the+Types+of+Tape+Drives)
08-Feb-2018 711/722
Suppress Messages - SASSMSGS

Due to the large number of messages generated by CA Workload Automation CA 7® Edition, a
provided message matrix is permits suppression of certain messages. SASSMSGS defines this matrix.
You can change the matrix to fit installation needs. However, you can change only those messages
defined in the distributed version of this module. You cannot add any new messages to the module.
Also, messages are not routed based on these entries. Only suppression occurs.
Follow these steps:
1. Obtain a listing of source member SASSMSGS.
2. Change the SEND macros as wanted.
3. Assemble and link edit SASSMSGS.
4. Shut CA Workload Automation CA 7® Edition down and WARM start.
Examples
This example completely suppresses SP06-10 (station cancel message).

SEND M=SP0610B,LT=*NONE*
This example only sends the station prompt messages to stations KEYPNCH and VERIFY.
SEND M=SCNP11B,LT=KEYPNCH
SEND M=SCNP11B,LT=VERIFY
This example sends cross-station notification only for stations that are printers.
SEND M=SPOC30,LT=*PRNTR*
This example sends station notification of job completion to station OUTPUT that is not a printer.
Suppress this message for all other stations unless they are a printer. In this case, specify the SEND
macros in the following order:
SEND M=SPRG30,LT=OUTPUT
SEND M=SPRG30,LT=*PRNTR*
CA Driver Customization - CA7AGENB

Options set in the load module CA7AGENB determine date formatting in CA Driver. The default
option is to use American style date formats (such as MM/DD/YY). If CA Driver is to use European
style date formats, apply USERMOD AL2UM36. This USERMOD is supplied in the CA Workload
Automation CA 7® Edition Options library (CAL2OPTN). To change the date option, change the DATE=
keyword value on the CAI7GENB macro from MMDD to DDMM. Then follow the instructions to
reassemble and link edit this module.
Reserved DDname Table - SASSPMDD

SASSPMDD is a table of reserved ddnames. The table is examined during the database LOAD process.
The table determines whether to flag a data set as permanent (PERM) when the data set is added to
the database.
08-Feb-2018 712/722
Note: For more information about permanent data sets, see the DB.6 panel.
Data sets whose ddnames exactly match entries in SASSPMDD are flagged as permanent (PERM)
when added to the CA Workload Automation CA 7® Edition database. Generics are not supported.
The table SASSPMDD is distributed in source and load module format. As it is distributed, the table
contains entries for such ddnames as STEPLIB, JOBLIB, STEPCAT, and JOBCAT. You can add more
entries to the table to suit specific installation needs. To modify the table, change the source for
SASSPMDD. Ensure that any updates conform to the existing table format as described in the module.
After you make appropriate source module changes, reassemble and link edit SASSPMDD. Because
module SASSJJCL uses SASSPMDD during the LOAD process, verify that it resides on every library
where SASSJJCL is found. See USERMOD AL2UM06 for a sample of an SMP/E update to the supplied
SASSPMDD module.
EBCDIC/ASCII Translation Tables - CAL2XLAT

By default, CA Workload Automation CA 7® Edition uses the translation tables that are shipped in
module CAL2XLAT. The tables convert between EBCDIC and ASCII when sending and receiving data
using the CAICCI or TCP/IP interface to or from another CA Technologies solution on a different
operating environment. This translation applies to both batch and online programs that use the
interface. If for any reason this module fails to load, then CA Workload Automation CA 7® Edition
uses the standard IBM XLATE macro.
If the default translation tables in CAL2XLAT do not satisfy your local character set requirements,
member AL2UM45 in the Sample JCL library contains a USERMOD. The USERMOD provides
customizable EBCDIC/ASCII translation tables. The source for the customizable tables is in member
CAL2XLAT in the CA Workload Automation CA 7® Edition source library. Copy the CAL2XLAT source
member into USERMOD AL2UM45 at the appropriate place and make the necessary changes to
reflect your local requirements.
This USERMOD performs an SMP/E RECEIVE and APPLY to replace load module CAL2XLAT. After
AL2UM45 is applied, the new tables in the CAL2XLAT load module are used for EBCDIC/ASCII
translations instead of the default tables shipped with CAL2XLAT.
Function Aliases for Formatted Panels

All function values for formatted panels can have assigned alternate names, aliases. These aliases
allow for abbreviation (for example, L for LIST). Aliases also permit alternate values like CHANGE for
UPD. The only restrictions are that the alias names must be eight characters or less, and must not
conflict with a function or other alternate name.
USERMOD AL2UM04 can be used to install an SMP/E version of the panel access table.
The following alias names are distributed with the system:
Functions Service Level Alias

ADD ADD A,ADDT,AELETE,AIST,APD
APPEND READ AP,APP
APPENDP READ N/A
08-Feb-2018 713/722

CLEAR N/A CL,CLR
DD DELETE N/A
DELETE DELETE D,DEL,DELT
DELPRRN UPDATE N/A
EDIT N/A E,EDITH
EXIT N/A N/A
FE READ FEIT,FEPL,FEVE
FETCH READ F
FETCHP READ FP
FORMAT N/A FMT,FOR,FORM
FPE READ N/A
FREE DELETE N/A
LIST READ L,LDD,LDIT,LISTA,LISTP,LISTR,LPD
PURGE DELETE N/A
QUIT N/A Q
REFRESH UPDATE REF
RENAME UPDATE REN
REPL UPDATE R,REP
REQ UPDATE N/A
RESOLV SUBMIT RES
RET SUBMIT N/A
RUN SUBMIT N/A
RUNH SUBMIT N/A
SAVE ADD S
SR UPDATE N/A
SS ADD N/A
STATUS READ ST
SUBMIT SUBMIT SUB
UPD UPDATE U,UDD,UIST,UPDATE,UPDT
XPOST UPDATE N/A
XPRE UPDATE N/A
XQ UPDATE N/A
XQJ UPDATE N/A
XQM UPDATE N/A
XQN UPDATE N/A
XRQ UPDATE N/A
08-Feb-2018 714/722

XRST UPDATE N/A
XSPOST UPDATE N/A
XSPRE UPDATE N/A
XUPD UPDATE N/A
XWLP UPDATE N/A
Performance and Tuning

Use these topics to improve CA Workload Automation CA 7® Edition performance. Use the left
navigation pane to view these articles.
Monitor Performance
Various methods are available for monitoring the performance of CA Workload Automation CA 7®
Edition and monitoring the processing of those jobs that it submits. These methods are described in
the following articles.
Automated Performance Analysis (APA)

The APA system provides a facility for viewing up-to-the-minute information about many aspects of
CA Workload Automation CA 7® Edition processing. The data is displayed using GRAPHx commands
that indicate the type of information to show. Some of the common graphs for analyzing
performance include:
GRAPHS,ID=190 - Percentage of Transactions with Response Time Less than 10 Seconds
GRAPHS,ID=750 - Communication Dataset Reads Vs. Busy Conditions
GRAPHS,ID=580 - CA-7 UP Time Vs. SMF Task Time
GRAPHS,ID=530 - CA-7 Up Time Vs. Job LOAD Time
GRAPHJ,ID=1190 - Percentage of Jobs Scheduled Via Schedule Scan
More information:
Automated Performance Analysis (https://wiki.ca.com/display/CWAC7E

/Automated+Performance+Analysis)
08-Feb-2018 715/722
CA Earl Reports
CA Earl™ is an easy-to-use report writer that can produce reports from CA Workload Automation CA
7® Edition log data or database backup data. Several reports are supplied. Use these reports as
supplied, or modify them to meet the needs of your installation. The following reports are useful
when analyzing performance:
CA7ER028 - Job Termination Posting Dwell Time
CA7ER029 - Job Completion Dwell Time
CA7ER031 - Transaction Response Time Profile
CA7ER035 - Performance Statistics Information Job Report
CA7ER036 - Performance Statistics Information System Report
More information:
CA Earl and CA Easytrieve Reporting (https://wiki.ca.com/display/CWAC7E

/CA+Earl+and+CA+Easytrieve+Reporting)
History Reporting and Performance

The history reporting facility uses log records from the log history and log archive files to produce
historical reports. The following reports are useful when analyzing performance:
06 Job Processing Activity Report
20 Submit Cycle Summary
21 Submission Job Detail
23 Job Submission Activity
24 Job Submission Output Activity
25 Metrics Report
70 Internal Activity Trace Report
More information:
History Reports (https://wiki.ca.com/display/CWAC7E/SASSHIS8+History+Reports)
08-Feb-2018 716/722
/DISPLAY Command and Performance

The /DISPLAY command is also useful in gathering information about CA Workload Automation CA 7®
Edition performance and environment. The following commands are useful:
This example lists information about the current (snapshot) environment for the CA7ONL
environment:
/DISPLAY,PERF=ALL
This example lists information about the database files.

/DISPLAY,DB=ALL
This example lists information about internal main memory storage pools.
/DISPLAY,PL=ALL
This example lists allocation information about queue files.

/DISPLAY,Q=ALL
This example lists information about the usage of application programs.

/DISPLAY,A=ALL
Initialization File Considerations

Adjusting some initialization file statements and keywords can help optimize the performance of CA
Schedule Scan Parameters

When specifying timespan and increments for schedule scan wake-up and queue loading, shorter
time spans and more frequent increments place less load on the system each time that a wake-up
occurs. Because fewer jobs are placed in the request queue, job completion processing is also
improved. See the initialization file SCHEDULE statement parameters SCNINCR and SCNSPAN. An
increase of two and a span of four are good default values.
Queue IOB Count

We recommend that you specify at least 10 as the count for the initialization file DAIO statement IOB
parameter. This number is the value used in the Stage II JCL generated at SYSGEN time. The IOB
parameter determines the number of input/output blocks to create at initialization time for
concurrent queue access used by terminals and Parallel Submission Processing (PSP=Y). Make this
number at least 5 plus the number of PSP subtasks (OPTIONS statement MAXSUBOUT). Also, as the
number of terminals accessing the queues increases, increase this value by 1 (or more) for every ten
terminals.
08-Feb-2018 717/722
Application Pool Sizes

The size of the application pool requires at least 120 KB. Increase the size when many different
functions of CA Workload Automation CA 7® Edition are in use concurrently. A value of 200 KB
(204800) is generally a good value to use. See the initialization file RESIDENT statement APGPL
parameter. Use the following commands to monitor pool size:
/DISPLAY,POOLS=ALL
/DISPLAY,A=ALL
Consider adding APPLCTN statements to the initialization for highly used CA Workload Automation
CA 7® Edition programs. Use the /DISPLAY,A=ALL command to monitor program loads and to
determine whether to mark some programs ATTR=PERM. Programs marked ATTR=PERM are only
loaded once during CA Workload Automation CA 7® Edition initialization.
Terminal Dispatching Priority

CA Workload Automation CA 7® Edition dispatches terminals for service based on how the coding of
the GROUP, LINE, and TERM statements in the initialization file. Using care in the statements can
favorably affect terminal performance.
GROUP, LINE, and TERM statements have certain restrictions on how they are grouped. However,
within those restrictions, the earlier that a LINE statement appears within the initialization file, the
higher the priority that is given to the terminals on that LINE.
The order in which terminal names appear within the TNAME value on each LINE statement further
determines the relative priority of each terminal within that LINE group. Priority decreases in a left-to-
right manner based on the sequence of the terminal names in the TNAME list.
If specified, enter the console terminal (DEVICE=CONSL) first. Follow the console terminal with all the
3270V terminals (VTAM). After the preceding two types, we recommend the following order for best
performance:
CAICCI and TCP/IP Terminals (DEVICE=CCI)
TRX Terminals (DEVICE=TRXDV)
Trailer Terminals (DEVICE=TRLDV)
Batch Terminals (DEVICE=BATCH)
Browse Terminal (DEVICE=BSAM)
Printer terminals, if applicable
If your site executes many batch terminals, perform an evaluation of the order for trailer and batch
terminals. You can place the batch terminals ahead of the trailer terminal.
The total number of terminals that are defined also affects performance. For this reason, use care in
determining the number of terminals coded in the initialization file.
08-Feb-2018 718/722
Calendar Schedules
Use trigger scheduling instead of calendar-oriented schedules whenever possible. You can
significantly reduce schedule scan processing overhead. Using the trigger scheduling causes jobs to
enter the request queue in a more timely fashion. Trigger scheduling decreases the number of jobs in
the queue at one time. Because of fewer jobs, job completion performance improves. Also, fewer
calendar schedules let schedule scan read fewer entries from the database to process the defined
workload.
Operating System Considerations

Consider these articles that are related to operating system performance.
Nonswappable
CA Workload Automation CA 7® Edition and all ICOMs are nonswappable when they initialize.
Dispatching Priority
In systems running large online applications (TSO, CICS, IMS, and so forth), dispatching priority can
significantly influence terminal response. If relatively few terminals are used for CA Workload
Automation CA 7® Edition, allowing it to dispatch above the other online systems typically yields
better response. This priority is unlikely to affect the other online systems adversely.
Note: The dispatching priority for ICOM affects the processing performance of SMF
feedback to CA Workload Automation CA 7® Edition.
Database Placement Considerations

When possible, have the CA 7 Online system (CA7ONL) executing on the same LPAR or system as the
CA Datacom/AD database. This placement improves the retrieval and storing of the data on the
database by using Cross-Memory Services (XMS) of the system. If the database resides on another
LPAR in the sysplex, then Cross-System Coupling Facility (XCF) is used to send and receive data
between the CA7ONL system and the database (MUF) system. If XCF is used, ensure that you provide
a sufficient band width for the XCF channels.
Another consideration is what other systems are combined to share the database MUF environment.
Do not run CA7ONL with systems that have unlike database characteristics like CA CSM and CAIENF.
CA 7 interfaces with CA 11 and shares database backup and recovery requirements. For this reason,
they can share one database MUF environment.
08-Feb-2018 719/722
Data Set Placement Recommendations and Restrictions

Consider the following conditions when you decide where to place data sets. Base the decisions on
your operating environment.
In all cases, it helps to have data sets on packs with low-access activity by other systems or products.
As with any online application, the placement of the data sets that are used can dramatically affect
performance. Proper selection of type of storage and physical location can assure optimum
performance. Conversely, poor selection can result in unsatisfactory performance.
Generally, it helps to have the data sets on packs with otherwise low-access activity from other
systems.
In many installations, products that dump entire packs are used to back up data sets. These products
are highly efficient for this purpose; however, they sometimes monopolize channel activity during
this process. To avoid performance lags in CA Workload Automation CA 7® Edition, its data sets
should not reside on drives or channels those products can dominate at a time when CA Workload
Automation CA 7® Edition performance is important. Any use of such products for backing up other
data sets not related to CA Workload Automation CA 7® Edition could also degrade the CA Workload
Automation CA 7® Edition performance when they are accessed through the same channels that CA
Workload Automation CA 7 Edition uses. If such backups can be scheduled to occur during off-hours
for CA Workload Automation CA 7® Edition, perhaps at the same time that the CA Workload
Automation CA 7® Edition backups are done, no problems should arise.
The following topics address particular concerns for specific data sets or groups of data sets.
Communications Data Set

In a multi-CPU environment, place this data set on a shared volume that is accessible to each CPU
where CA Workload Automation CA 7® Edition or ICOM executes. Other systems must access this
volume infrequently. The volume must not contain CA Workload Automation CA 7® Edition databases
or logs if at all possible. In a multi-CPU environment, a reserve is issued against this data set. Consider
this reserve when deciding where to locate the data set to minimize potential performance problems
which could result.
CA Workload Automation CA 7® Edition and any ICOMs that are executing access the
communications data set. Exclude the reserve that is done from the control of any software package
that converts reserves to global ENQs (for example, GRS or MIM). The QNAME is UCC7CMDS and the
RNAME is CMDS.
Among data sets that should not reside on the same pack are the following items:
TMC for CA 1®
Database for CA Workload Automation Restart Option for z/OS Schedulers
SPOOL pack, page pack
Any high-access data sets for another online system (TSO, CA Roscoe®, CICS, and so forth).
08-Feb-2018 720/722
Load Library
Locate this load module library on a low-access drive whenever possible.
Placement of Data Sets

Some general performance considerations apply to data sets as they would for any data set which is
critical to an online system. For example:
Using drives with little or no contention from other systems.
Avoiding domination of devices, channels, or both by products which dump entire packs.
The following table relates to a multiple CPU environment:
Available packs
1 2 3 4
Using 2 drives Communications data set All others
Using 3 drives Communications data set Database (MUF) All others
Using 4 drives Communications data set Database (MUF) SCRQ All others
DQTQ
The following table relates to a single CPU environment:
Available packs
1 2 3
Using 2 drives Database (MUF) All others
Using 3 drives Database (MUF) DQTQ All others
SCRQ
SMF Processing
The overhead associated with SMF data collection can be considerable depending on the volume of
workload activity. This overhead can be minimized if care is to collect only the data that is truly
needed.
The CA Workload Automation CA 7® Edition SMF module can extract information about data sets that
are opened for input (SMF type 14 records). However, this information is not extracted when
installation defaults are used, because the information is not needed for requirement monitoring by
CA Workload Automation CA 7® Edition. Although we do not recommend collecting input data set
information, you can change the installation defaults to do so with CAIRIM.
08-Feb-2018 721/722
CA Workload Automation CA 7® Edition relies on information about non-VSAM data sets that are
opened for output or update (SMF type 15 records). Default installation options enable collection of
this information. If you disable collection of SMF type 15 records, CA Workload Automation CA 7®
Edition cannot monitor requirement activity for jobs. For that reason, we do not recommend that you
disable collection of SMF type 15 records. However, if you are required to do so, you can change the
installation defaults with CAIRIM.
CA Workload Automation CA 7® Edition can extract information about VSAM cluster data sets opened
for output or update. This information is not extracted by default. If a VSAM cluster activity must
satisfy requirements or trigger jobs, you can change the installation defaults to track VSAM data sets
with CAIRIM.
You can define criteria that limit SMF type 14, 15, and 64 collections to only those data sets that CA
Workload Automation CA 7® Edition must monitor.
SMF type 26 records are created when output for a job is purged in JES. Although the record can be
useful in highlighting possible JCL errors, processing the record does involve extra overhead. Default
installation options enable processing of this record on the CA71 instance only.
More information:
SMF Type 14/15/64 Record Filter - SASSXU83 (https://wiki.ca.com/pages/viewpage.action?

pageId=134844883)
Enable SMF Type 14 Records for a Tracking Instance (https://wiki.ca.com/display/CWAC7E

EnableSMFType14RecordsforaTrackingInstance)
Enable SMF Type 26 Records for a Tracking Instance (https://wiki.ca.com/display/CWAC7E

EnableSMFType26RecordsforaTrackingInstance)
Disable SMF Type 15 Records for a Tracking Instance (https://wiki.ca.com/display/CWAC7E

DisableSMFType15RecordsforaTrackingInstance)
Data Set Placement Recommendations

Consider the following conditions when you decide where to place data sets. Base the decisions on
your operating environment.
In all cases, it helps to have data sets on packs with low-access activity by other systems or products.
08-Feb-2018 722/722

CA Workload Automation CA 7® Edition - 12.0 - ENU - Configuring - 20180208 PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CA Workload Automation CA 7® Edition - 12.0 - ENU - Configuring - 20180208 PDF

Hochgeladen von

Copyright:

Verfügbare Formate

CA Workload

The manufacturer of this Documentation is CA.

Configuration Best Practices ..................................................................... 22

Customization Best Practices .................................................................... 27

Programming ........................................................................................... 416

Configuration Best Practices

Review the IBM Workload Manager (WLM) Service

CA Datacom/AD Multi-User Facility (MUF) used by CA Workload Automation CA 7® Edition

CA Workload Automation Restart Option for z/OS Schedulers when used

Update JES MAS Tuning

This practice ensures more efficient, quicker job submission.

Use XCF for SMF Record Notification

This practice ensures more efficient tracking of work in CA7ONL.

Perform File Maintenance

Reconsider JCL Files

If you have some contention for the JCL file

If JCL files need compressing

Your jobs enter the CA7ONL request queue faster.

Understand LOAD Processing

This practice produces quicker, more efficient processing of batch work.

Evaluate Schedule Scan Options

Use a longer RETRY value for performance purposes.

Exclude Some Data Set SMF Feedback

Parallel Submission Processing

Customization Best Practices

Add Batch Terminals

Changing terminal definitions requires a specified ERST type start of CA7ONL.

Add CAICCI Terminals

Changing terminal definitions requires a specified ERST type start of CA7ONL.

Add JCL Libraries

This best practice ensures flexibility in JCL library use.

Add TCP/IP Terminals

This best practice results in quicker processing of TCP/IP terminals.

Add VTAM Terminals

Changing terminal definitions requires a specified ERST type start of CA7ONL.

More personnel can require more terminal definitions.

Implement or Delete Submit Data Sets

JES decides the LPAR where the job actually executes.

Implement Workload Balancing (WLB)

This best practice ensures more efficient processing of batch work.

Maintain the CA7AGNT VSAM File

For more information, see CA WA CA 7 Edition File (https://docops.ca.com/display/CA712

Move or Reallocate Batch Terminal Files

Move or Reallocate the Checkpoint and Queue

Move or Reallocate the Communications Data Set

To reformat the communications data set, see member CA07N700 in JCLLIB.

Move or Reallocate the Database Files

Move or Reallocate the Log Files

Shut down CA7ONL before running the log dump jobs.

Order for Starting Programs

CA Datacom/AD MUF region

CA Workload Automation Restart Option for z/OS Schedulers (if using)

JFM (if using the initialization file option CPM=JFM)

Review the Region Size

This best practice results in a better overall performance for CA7ONL.

Startup Procedures Recommendations

Correct startup of CA7ONL assures seamless scheduling of batch work.

For more information, see Startup Options (https://wiki.ca.com/display/CWAC7E/Execution#Execution-

Update the Initialization File

Documentation in this area provides the following interface information:

Interfaces and integration points

Interfaces with other products

Schedule UNIX System Services jobs