CA Workload Automation

CA 7® Edition

Database Maintenance Guide

Version 12.0.00

Second Edition
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 © 2015 CA. All rights reserved. All trademarks, trade names, service marks, and logos referenced herein belong to
their respective companies.
CA Technologies Product References
This document references the following CA Technologies products:
■ CA Workload Automation CA 7® Edition, (CA WA CA 7 Edition), formerly CA
Workload Automation SE and CA 7® Workload Automation
■ CA ACF2™
■ CA 7® Web Client
■ CA Datacom A/D
■ CA Dispatch™
■ CA Easytrieve®
■ CA JCLCheck™ Workload Automation (CA JCLCheck)
■ CA Librarian® for z/OS
■ CA Panvalet®
■ CA Roscoe®
■ CA Top Secret®
■ CA Workload Automation AE
■ CA Workload Automation Restart Option for z/OS Schedulers (CA WA Restart
Option), formerly CA 11™ Workload Automation Restart and Tracking
Contact CA Technologies
Contact CA Support

For your convenience, CA Technologies provides one site where you can access the
information that you need for your Home Office, Small Business, and Enterprise CA
Technologies products. At http://ca.com/support, you can access the following
resources:
■ Online and telephone contact information for technical assistance and customer
services
■ Information about user communities and forums
■ Product and documentation downloads
■ CA Support policies and guidelines
■ Other helpful resources appropriate for your product

Providing Feedback About Product Documentation

If you have comments or questions about CA Technologies product documentation, you

can send a message to [email protected].

To provide feedback about CA Technologies product documentation, complete our

short customer survey which is available on the CA Support website at
http://ca.com/docs.
Documentation Changes
The following documentation updates have been made since the last release of this
documentation:
■ DB.10 - XPJOB Job Definition Panel (see page 50)—Changes to the WLBCLASS
keyword.
■ DB.11 - Agent Job Definition Panel (see page 64)—Changes to the WLBCLASS
keyword.
Contents
Chapter 1: Introduction 17
Overview .................................................................................................................................................................... 17
Functional Overview .................................................................................................................................................. 17
Online Input ............................................................................................................................................................... 17
PF Keys ................................................................................................................................................................ 18
Formatted Panel Messages ................................................................................................................................. 19
CA-7 Function Menu ........................................................................................................................................... 20
DB Menu Panel.................................................................................................................................................... 20
Bypassing the Menu ............................................................................................................................................ 21
Function Shortcuts .............................................................................................................................................. 22
Function Transfer ................................................................................................................................................ 23
Aliases for Formatted Panel Functions ............................................................................................................... 24
Batch Input ................................................................................................................................................................. 25
Online Format ..................................................................................................................................................... 26
Batch Format ....................................................................................................................................................... 26
Remove Field Contents Using Batch Input .......................................................................................................... 26
Function Shortcuts and Bypassing the Menu ...................................................................................................... 27
Function Transfer ................................................................................................................................................ 27
Aliases for Formatted Panel Functions ............................................................................................................... 27
Long Job Names ......................................................................................................................................................... 27
Triggers................................................................................................................................................................ 28
Job Predecessors ................................................................................................................................................. 28
Network Tasks ..................................................................................................................................................... 29
User Memo-Form Predecessors.......................................................................................................................... 29
Long Job Name Rules .......................................................................................................................................... 29

Chapter 2: Setting Up and Maintaining Jobs 31

Types of Jobs .............................................................................................................................................................. 31
How You Add a Job ..................................................................................................................................................... 32
Usage Notes for DB.1, DB.10, and DB.11 ................................................................................................................... 33
DB.1 - CPU Job Definition Panel ................................................................................................................................. 34
Example: Batch Input .......................................................................................................................................... 49
How You Change a CPU Job ....................................................................................................................................... 50
DB.10 - XP Job Definition Panel .................................................................................................................................. 50
Example: Batch Input .......................................................................................................................................... 64
DB.11 - Agent Job Definition Panel ............................................................................................................................ 64

Contents 7
 Example: Batch Input .......................................................................................................................................... 75

Chapter 3: Scheduling Work 77

Work Scheduling ........................................................................................................................................................ 77
Date and Time Scheduling................................................................................................................................... 78
Schedule Modifications ....................................................................................................................................... 81
Event Scheduling with Triggers ........................................................................................................................... 82
On-Request Scheduling ....................................................................................................................................... 83
Schedule Definition .................................................................................................................................................... 85
DB.2 - Scheduling Menu Panel ............................................................................................................................ 85
DB.2.1 - Job Scheduling Panel ............................................................................................................................. 87
Job Scheduling Parameter Edit Panel .................................................................................................................. 90
DB.2.2 - Input Network Scheduling Panel ......................................................................................................... 103
Input Network Scheduling Parameter Edit Panel .............................................................................................. 106
DB.2.3 - Output Network Scheduling Panel ...................................................................................................... 115
Output Network Scheduling Parameter Edit Panel ........................................................................................... 118
Trigger Scheduling Panels ................................................................................................................................. 123
DB.2.4 - Job Triggering Panel ............................................................................................................................ 123
DB.2.4L - Job Triggering Panel (Long Job Name) ............................................................................................... 124
DB.2.5 - Input Network Triggering Panel .......................................................................................................... 126
DB.2.5L- Input Network Triggering Panel (Long Job Names) ............................................................................ 127
DB.2.6 - Data Set Triggering Panel .................................................................................................................... 128
DB.2.6L - Data Set Triggering Panel (Long Job Names) ..................................................................................... 134
DB.2.7 - Modification to Resolved Schedule Dates Panel ................................................................................. 139
DB.2.8 - Base Calendar Maintenance Panel ...................................................................................................... 142

Chapter 4: Defining Requirements 147

Execution Requirements and the LOAD Process ...................................................................................................... 147
Dependence Definition ..................................................................................................................................... 147
Database Definitions ......................................................................................................................................... 148
Data Set Dependencies ..................................................................................................................................... 148
Other Dependencies ......................................................................................................................................... 149
Temporary Predecessors ................................................................................................................................... 149
Satisfy Requirements ............................................................................................................................................... 150
Effect of Time Zone Normalization ................................................................................................................... 151
Predecessor and Successor Definition ..................................................................................................................... 151
DB.3 - Job Predecessor/Successor Menu Panel ................................................................................................ 152
DB.3.1 - Data Set Predecessors Panel ............................................................................................................... 153
DB.3.2 - Job Predecessors Panel ....................................................................................................................... 157
DB.3.2L - Job Predecessors Panel (Long Job Name) .......................................................................................... 162

8 Database Maintenance Guide

 DB.3.4 - Input/Output Network Tasks Panel ..................................................................................................... 167
DB.3.4L - Input/Output Network Tasks Panel (Long Job Names) ...................................................................... 172
DB.3.6 - User Memo-Form Predecessors Panel ................................................................................................ 174
DB.3.6L - User Memo-Form Predecessors Panel (Long Job Names) ................................................................. 178

Chapter 5: Virtual Resource Management 181

Resource Types ........................................................................................................................................................ 181
Shared Resources .............................................................................................................................................. 182
Exclusive Resource ............................................................................................................................................ 182
Corequisite Resources ....................................................................................................................................... 182
Address Space Resources .................................................................................................................................. 183
Resource Count Resources ................................................................................................................................ 183
VRM Variable Definitions .................................................................................................................................. 184
Resource Conflicts Resolution .................................................................................................................................. 187
RM - Virtual Resource Management Menu Panel .................................................................................................... 187
RM.1 - Job Resource Management Panel ................................................................................................................ 188
Example: Batch Input ........................................................................................................................................ 194
Critical Path Monitoring Corequisite Resources ............................................................................................... 194
RM.2 - Job/Resource Cross-Reference List Panel ..................................................................................................... 195
Example: Batch Input ........................................................................................................................................ 198
RM.3 - Active Job Resources Display Panel .............................................................................................................. 198
Example: Batch Input ........................................................................................................................................ 200
RM.4 - Pending Resources Job Display Panel ........................................................................................................... 201
Example: Batch Input ........................................................................................................................................ 203
RM.5 - Jobs Waiting on Resources Panel ................................................................................................................. 203
Example: Batch Input ........................................................................................................................................ 205
RM.6 - Corequisite Resources List Panel .................................................................................................................. 205
Example: Batch Input ........................................................................................................................................ 207
RM.7 - Resource Count Resource Management Panel ............................................................................................ 207
Example: Batch Input ........................................................................................................................................ 210
VRM Device Control ................................................................................................................................................. 210
VRM Device Control Functions - Definition Structure....................................................................................... 211
VRM Device Control Functions - Definition Control .......................................................................................... 212
VRM Device Control Functions - Submission Control ....................................................................................... 214
VRM Device Control - Activation ....................................................................................................................... 214

Chapter 6: Automated Recovery Facility 215

Overview .................................................................................................................................................................. 215
Monitor Exception Conditions ................................................................................................................................. 216
Respond to Exception Conditions ............................................................................................................................ 217

Contents 9
Types of Exceptions Recognized by ARF................................................................................................................... 217
ARFSET Structure ...................................................................................................................................................... 220
ARF Definition Structure ................................................................................................................................... 221
Filter Criteria ..................................................................................................................................................... 221
Type Specific Tests ............................................................................................................................................ 221
Responses ......................................................................................................................................................... 222
Final Disposition ................................................................................................................................................ 223
Implementation Considerations ............................................................................................................................... 223
AR.3 - ARF Condition Definition Maintenance Panel ............................................................................................... 223
ARF Condition Definition Edit Panel ......................................................................................................................... 226
Field Descriptions .............................................................................................................................................. 227
Field Descriptions - Filter Criteria ...................................................................................................................... 229
Field Descriptions - Type Specific Tests for JC and SC Conditions ..................................................................... 234
Field Descriptions - Type Specific Tests for EC, EE, IS, LB, LE and LS Conditions ............................................... 239
Field Descriptions - Responses .......................................................................................................................... 243
Field Descriptions - Final Disposition ................................................................................................................ 244
Rules for Coding ARF Action Statements ................................................................................................................. 247
AC - Issue a Command....................................................................................................................................... 247
AM - Issue a Message ........................................................................................................................................ 248
AW - Wait .......................................................................................................................................................... 249
AJ - Schedule a Recovery Job ............................................................................................................................ 250
Use Reserved Words in Type Specific Tests ............................................................................................................. 251
Use Variables in ARF Action Statements .................................................................................................................. 253
Examples of ARF Condition Definition...................................................................................................................... 254
Defining a Job Completion Condition (JC) ......................................................................................................... 254
Defining a Late at Job End Notification (LE) ...................................................................................................... 256

Chapter 7: Workload Documentation 259

Overview .................................................................................................................................................................. 259
Workload Documentation Panels ............................................................................................................................ 260
DB.4 - Workload Documentation Menu Panel .................................................................................................. 260
DB.4.1 - CPU Job Documentation Panel ............................................................................................................ 261
DB.4.2 - Input/Output Network Documentation Panel .................................................................................... 264
DB.4.3 - User-Defined Item Documentation Panel ........................................................................................... 268
DB.4.4 - Data Set Documentation Panel ........................................................................................................... 272
DB.4.5 - DD Statement Documentation Panel .................................................................................................. 276
DB.4.6 - Application System Documentation Panel .......................................................................................... 280
Special Documentation Features ............................................................................................................................. 283
User-Defined Documentation Segments .......................................................................................................... 284
Special Purpose Documentation ....................................................................................................................... 291
#QDESC Segment Usage .................................................................................................................................... 292

10 Database Maintenance Guide

 #station-name Segment Usage ......................................................................................................................... 293
#RESTART Segment Usage ................................................................................................................................ 294
#END Statement ................................................................................................................................................ 294

Chapter 8: Workstation Networks 297

Network Adds ........................................................................................................................................................... 297
DB.5 - Input/Output Network Definition Panel ........................................................................................................ 298
Example: Batch Input ........................................................................................................................................ 301
Network Changes ..................................................................................................................................................... 301

Chapter 9: Data Sets 303

Data Set Adds ........................................................................................................................................................... 303
Permanent Data Sets ........................................................................................................................................ 304
Dynamically Allocated Data Sets ....................................................................................................................... 304
External Data Sets ............................................................................................................................................. 305
DB.6 - Data Set Definition Panel ............................................................................................................................... 305
Usage Notes ...................................................................................................................................................... 310
Example: Batch Input ........................................................................................................................................ 310
Data Set Changes ..................................................................................................................................................... 310

Chapter 10: JCL and PARM Data Maintenance 311

Parameter Data Maintenance for Internal Cross-Platform Job Types ..................................................................... 311
DB.7 - JCL Library Maintenance Panel ...................................................................................................................... 312
Usage Notes ...................................................................................................................................................... 317
Scheduled Overrides ................................................................................................................................................ 317
#JI and #JO Statements ..................................................................................................................................... 318
#JEND Statement .............................................................................................................................................. 321
#XI, #XO, and #XEND Statements ...................................................................................................................... 322
Scheduled Override Examples........................................................................................................................... 322
Additional Override Statements............................................................................................................................... 324
#ARF Statement ................................................................................................................................................ 325
#MSG Statement ............................................................................................................................................... 326
#RES Statement ................................................................................................................................................. 327
#SCC Statement ................................................................................................................................................. 328
Additional Override Examples ........................................................................................................................... 331
SASSJCLU - JCL Utility................................................................................................................................................ 334
Usage Notes ...................................................................................................................................................... 335
Control Statement ............................................................................................................................................. 335
JCL ..................................................................................................................................................................... 336
JCL Validation ........................................................................................................................................................... 336

Contents 11
LOAD Command Processing ..................................................................................................................................... 337
Special Override Library ........................................................................................................................................... 337
Special Override Library Definition ................................................................................................................... 337
Temporary JCL Creation .................................................................................................................................... 338
Temporary JCL Usage ........................................................................................................................................ 338
Other Considerations ........................................................................................................................................ 338
Alternate JCL Libraries .............................................................................................................................................. 339
Alternate Library Definition .............................................................................................................................. 339
Temporary JCL Creation .................................................................................................................................... 339
Temporary JCL Usage ........................................................................................................................................ 339
Other Considerations ........................................................................................................................................ 340

Chapter 11: Using the Edit Facility 341

Overview .................................................................................................................................................................. 341
Active Area ............................................................................................................................................................... 342
Edit Work File ........................................................................................................................................................... 343
Environments ........................................................................................................................................................... 343
Editor Usage ............................................................................................................................................................. 343
Invoking the Editor ............................................................................................................................................ 343
Editing Text Data ............................................................................................................................................... 344
Leaving the Editor ............................................................................................................................................. 344
CA 7 Text Editor Environment .................................................................................................................................. 344
Edit Modes ........................................................................................................................................................ 345
Updating Text .................................................................................................................................................... 365
Creating Text ..................................................................................................................................................... 365
Special Considerations ...................................................................................................................................... 366
TSO/ISPF Editor Environment ................................................................................................................................... 367
Requesting Edit Functions from the ISPF Editor ............................................................................................... 368
Default Requests for CA WA CA 7 Edition Edit Functions ................................................................................. 369
Special Considerations ...................................................................................................................................... 370

Chapter 12: Internal Cross-Platform 373

XN.1 - XNODE Command .......................................................................................................................................... 373
XN.2 - XPSWD Command.......................................................................................................................................... 376
(Password Present)/(Password Not Present) Message ..................................................................................... 380
XN.3 - AGPSWD Command ....................................................................................................................................... 381

Chapter 13: Database Transportability 385

Overview .................................................................................................................................................................. 385
Assumptions ............................................................................................................................................................. 387

12 Database Maintenance Guide

 LOAD/RELOAD Status ........................................................................................................................................ 387
CA WA Restart Option Step Insertion ............................................................................................................... 388
Base Calendars .................................................................................................................................................. 388
Calendar Schedules ........................................................................................................................................... 388
DB.2.7 Schedule Modifications ......................................................................................................................... 388
NXTCYC Settings ................................................................................................................................................ 389
Execution JCL Libraries ...................................................................................................................................... 389
Cataloged Procedures ....................................................................................................................................... 390
In-stream JCL Procedures .................................................................................................................................. 390
Workstation Networks ...................................................................................................................................... 390
User Level Documentation ................................................................................................................................ 390
CPU Job Considerations .................................................................................................................................... 390
XPJOB/AGJOB Considerations ........................................................................................................................... 391
Commas in the Data .......................................................................................................................................... 391
Sequence Numbers ........................................................................................................................................... 391
User ID Security ................................................................................................................................................. 391
LINKed Documentation ..................................................................................................................................... 392
Database Extraction ................................................................................................................................................. 392
Moving Jobs.............................................................................................................................................................. 397
Add at New Site ................................................................................................................................................. 398
Requirements and Network Connections ......................................................................................................... 400
Delete at Original Site ....................................................................................................................................... 402
Disable at Original Site ...................................................................................................................................... 403
Workstation Networks ............................................................................................................................................. 404
Add at New Site ................................................................................................................................................. 405
Delete at Original Site ....................................................................................................................................... 405
Disable at Original Site ...................................................................................................................................... 405
Unconnected Workstation Networks ............................................................................................................... 406
Application Data Sets ............................................................................................................................................... 406
Add at New Site ................................................................................................................................................. 407
Delete at Original Site ....................................................................................................................................... 408
PDS JCL Members ..................................................................................................................................................... 408
Add at New Site ................................................................................................................................................. 409
Delete at Original Site ....................................................................................................................................... 410
CA Librarian JCL ........................................................................................................................................................ 410
Add at New Site ................................................................................................................................................. 411
Delete at Original Site ....................................................................................................................................... 412
CA Panvalet JCL ........................................................................................................................................................ 413
Add at New Site ................................................................................................................................................. 414
Disable at Original Site ...................................................................................................................................... 415
Cataloged Procedures .............................................................................................................................................. 416
Add at New Site ................................................................................................................................................. 417

Contents 13
 Delete at Original Site ....................................................................................................................................... 417
Documentation ........................................................................................................................................................ 418
Add at New Site ................................................................................................................................................. 419
Delete at Original Site ....................................................................................................................................... 420
Schedules ................................................................................................................................................................. 420
Add at New Site ................................................................................................................................................. 420
Delete at Original Site ....................................................................................................................................... 424
Node and Access File ................................................................................................................................................ 425
Agent DIV File ........................................................................................................................................................... 426
Create Command Files ............................................................................................................................................. 427
Job 1 .................................................................................................................................................................. 427
Job 2 .................................................................................................................................................................. 429
Job 3 .................................................................................................................................................................. 431
Special Considerations ............................................................................................................................................. 434
Design Limitations ............................................................................................................................................. 434
Add to the New Database ................................................................................................................................. 435
Run at New Site ................................................................................................................................................. 436
Mass Changes at Existing Site ........................................................................................................................... 436
Virtual Resource Management Database Extracts ................................................................................................... 436
VRM DBT Program ............................................................................................................................................ 437
VRM DBT Job Extract JCL ................................................................................................................................... 437
VRM Node and Access Transport Program .............................................................................................................. 440
VRM Node and Access Extract JCL .................................................................................................................... 440
PARM Keywords ................................................................................................................................................ 441
Data Sets Used/Created .................................................................................................................................... 441
Output Reports ................................................................................................................................................. 442
Automated Recovery Facility Database Extracts ...................................................................................................... 443
ARF DBT Extract JCL ........................................................................................................................................... 444
Data Sets Used/Created .................................................................................................................................... 446

Chapter 14: Job Name Rename Function 447

Online Job Rename .................................................................................................................................................. 447
Batch Job Rename .................................................................................................................................................... 449

Appendix A: Using CA 7/PERSONAL SCHEDULING 451

Overview .................................................................................................................................................................. 451
Panel Descriptions .................................................................................................................................................... 452
Access CA 7/PERSONAL SCHEDULING ...................................................................................................................... 455
Add a Job .................................................................................................................................................................. 457
Submit a Job ............................................................................................................................................................. 458

14 Database Maintenance Guide

Display a Job's Status ............................................................................................................................................... 459
Implement CA 7/PS .................................................................................................................................................. 460
Defining Additional PATTERN Jobs .................................................................................................................... 462
CA 7/PS Messages .................................................................................................................................................... 462

Contents 15
Chapter 1: Introduction
The Database Maintenance Guide is intended for database administrators, change
control personnel, or both using CA Workload Automation CA 7® Edition (CA WA CA 7
Edition).

This section contains the following topics:

Overview (see page 17)
Functional Overview (see page 17)
Online Input (see page 17)
Batch Input (see page 25)
Long Job Names (see page 27)

Overview
CA WA CA 7 Edition is a comprehensive Automated Production Control system. It has
the capability to address the broad range of activities traditionally considered the
responsibility of computer operation's production control. CA WA CA 7 Edition is an
online, realtime, interactive system that automatically controls, schedules, and initiates
work according to time-driven and/or event-driven activities.

Functional Overview
The Systems Programming Guide contains the functional overview of specific features
and abilities of CA WA CA 7 Edition.

Online Input
Before a user performs database maintenance, the user must successfully log in to a CA
WA CA 7 Edition terminal.

A series of formatted panels enable online input to the CA WA CA 7 Edition database.

Each major Database Maintenance (DB) command has an associated input panel. Any of
the following items can display input panels:
■ Selecting from functions that are listed on the DB Menu panels
■ Entering the panel name as a top line command
■ Entering the panel name in the FUNCTION field on any other menu or formatted
input panel

Chapter 1: Introduction 17
Online Input

When the wanted command or menu panel option is entered, a data input panel or
secondary menu is then displayed. For example, if function 4 is selected on the DB
Menu, the DB.4 Workload Documentation Menu is then displayed.

The user can enter any CA WA CA 7 Edition command on the top line of the current
panel.

After a DB function is processed from the formatted panel, the same panel is returned.
This panel includes the function that you originally entered. If the user wants to repeat
the same function, at least one character of that function must be reentered. This
requirement helps avoid inadvertent updates.

When updating text fields through formatted panels in online mode, enter a space as
the first character and erase to end-of-field. When the update occurs, the field in the
database is removed. When using topline commands, omitting the keyword lets you
take the default for that command.

More information:

DB Menu Panel (see page 20)

PF Keys
After a function is selected on the menu and the function panel is displayed, program
function key 3, PF3 is temporarily set to return to the DB MENU panel. In native CA WA
CA 7 Edition VTAM mode, any value that was previously assigned to PF3, by either the
user or CA WA CA 7 Edition, is temporarily ignored as long as the function panel is being
used and reverts to the original value after it is used once or after a top line command is
entered.

With the TSO/ISPF interface, PF3 does not function in this way if any other value is
assigned to PF3 when the user begins the session. The return-to-menu only works in the
TSO/ISPF mode if PF3 remains unassigned in TSO/ISPF mode and is thus allowed to be
returned back to CA WA CA 7 Edition as a PF3.

PF7 and PF8 are similarly temporarily overridden to /PAGE-1 and /PAGE+1 respectively
until PF3 is pressed or a top line command is issued.

18 Database Maintenance Guide

 Online Input

Formatted Panel Messages

The following fields are common to all formatted input panels and appear at the bottom
of each.
PROGRAM:
Identifies the last four characters of the module name that processed the data of
this panel.
MSG-INDX:
Identifies the return message identifier.
panel id
Identifies the panel ID of this panel.
yy.ddd/hh:mm:ss
Identifies the date and time of this returned message.
MSGS:
Identifies the number of secondary output messages queued for this user's
terminal. If no messages are queued, MSGS does not appear. This field also
appears, immediately below the page number, on general inquiry displays
whenever at least one message is awaiting display and the inquiry is made online.
The field does not appear on general inquiry output in batch mode.
MESSAGE:
Identifies up to two lines of message text. Messages are listed in the Message
Reference Guide as a combination of the PROGRAM and MSG-INDX values. For
example, SM11-00.

Chapter 1: Introduction 19
Online Input

CA-7 Function Menu

To access the database maintenance functions, enter DB as the function on the CA-7
Function Menu and press Enter.

---------------------------- CA-7 FUNCTION MENU ------------------------------

FUNCTION ===>

APA - AUTOMATED PERFORMANCE ANALYSIS

AR - AUTOMATED RECOVERY FACILITY
DB - DATABASE MAINTENANCE
QM - QUEUE MAINTENANCE
RM - VIRTUAL RESOURCE MANAGEMENT
UT - UTILITIES
PS - PERSONAL SCHEDULING

HELP - TUTORIAL

PROGRAM: MNU0 MSG-INDX: 00 -- MENU -- yy.ddd / hh:mm:ss

MESSAGE: SPECIFY DESIRED FUNCTION OR ENTER A COMMAND ON THE TOP LINE

DB Menu Panel
Use the DB Menu panel to select various database maintenance functions.

--------------------- CA-7 DATA BASE MAINTENANCE MENU ----------------------

FUNCTION ===>

DATA BASE DEFINITION FOR:

1 - CPU JOB
A - CROSS PLATFORM (XPS) JOB DEFINITION
2 - SCHEDULING
3 - JOB PREDECESSOR/SUCCESSOR
4 - WORKLOAD DOCUMENTATION
5 - INPUT/OUTPUT NETWORK
6 - DATA SET

OTHER FUNCTIONS AVAILABLE:

7 - JCL LIBRARY MAINTENANCE
8 - TEXT EDITOR
9 - CLEAR THE TEXT EDITOR ACTIVE AREA
ACTIVE AREA NOW CONTAINS 0000 LINES OF TEXT

PROGRAM: SDM0 MSG-INDX: nn -- DB -- yy.ddd / hh:mm:ss

MESSAGE:

20 Database Maintenance Guide

 Online Input

To display, enter:
■ DBM (or DB) as a top line command.
■ DBM (or DB) as the FUNCTION value on any other menu or formatted input panel.

To exit, enter the name of an online panel as the FUNCTION value or move the cursor to
the top line and enter a top line command if some other function is wanted.

Usage Notes

Select a function by entering its value as the FUNCTION and pressing Enter.

Bypassing the Menu

CA WA CA 7 Edition provides an extensive menu service for Database Maintenance. The
menus are structured to help a novice user step through various panels. However, as
proficiency increases, it can be desirable to bypass primary menus and proceed directly
to the wanted panel.

The primary DB panel can be bypassed by entering a command panel name on the top
line of the current panel or as the FUNCTION value on any other menu or formatted
panel. For example, DB.1 or DB.4.

Bypassing Secondary Menus

Functions 2, 3, and 4 have secondary menu panels. To go directly from the DB Menu
panel to a function that appears on one of the secondary menus, enter FUNCTION in n.n
format. See the following example:

---------------------
FUNCTION ===> 2.3

Entering 2.3 on the DB Menu panel indicates that you want function 2 (SCHEDULING)
and that Scheduling Menu function 3 (OUTPUT NETWORK) is the function that you want
to perform.

CA WA CA 7 Edition displays the DB.2.3 panel directly and bypasses the Scheduling
Menu (DB.2).

Chapter 1: Introduction 21
Online Input

You can also bypass these secondary menu panels. Enter the equivalent top line
command, placing a comma after the command and selecting a category, as follows:
■ SCHD followed by JOB, INWK, ONWK, JTRG, DTRG, or NTRG.
■ JOBCONN followed by DSN, JOB, NWK, RPT, or USER.
■ PROSE followed by JOB, DSN, SYS, USER, NWK, or DD.

For example, the top line command JOBCONN,JOB would display the DB.3.2 panel for
defining, listing, or updating job predecessor without going through the DB or Job
Predecessor/Successor Menu panels.

Bypassing Tertiary Menus

If your site has enabled CA WA CA 7 Edition agents, Function A has tertiary menus. To go
directly from the DB Menu panel to a function that appears on one of the tertiary
menus, enter FUNCTION in the n.n.n format. See the following example:

---------------------
FUNCTION ===> A.F.D

Entering A.F.D on the DB Menu panel indicates that you want function A (CROSS
PLATFORM (XPS) JOB DEFINITION), then CA-7 Cross Platform Jobs Menu function F
(SAP), and that CA-7 SAP Jobs Menu D (SAP Job) is the function to perform.

CA WA CA 7 Edition displays the Agent Job Definition panel directly, bypassing the CA-7
Cross Platform Jobs Menu and CA-7 SAP Jobs Menu.

The menus provide a view of the various agent job types that are available for
scheduling under CA WA CA 7 Edition. Using the menus also pre-fills the Agent Job Type
field on the CA-7 Agent Job Definition panel (DB.11).

Function Shortcuts
An online shortcut for requesting LIST functions of job predecessor/successors and
schedule triggers is also available. In this case, keyword values identifying the element
data wanted are included in the top line command following the category, as follows:
■ JOBCONN,DSN can be followed by JOB=jobname and SCHID=nnn.
This example lists all DSN connections to job BACKUP for schedule ID 2 with no
further input needed.
JOBCONN,DSN,JOB=BACKUP,SCHID=2

22 Database Maintenance Guide

 Online Input

■ The SCHD trigger function can be followed by JOB=jobname,

DSN=dataset-name/DSNBR=dataset-number or NWK=network-name/DSNBR=
network-number (depending on the trigger function).
This example lists all jobs and schedules that are triggered by the completion of
input network PAYPUNCH.
SCHD,NTRG,NWK=PAYPUNCH

Shortcut Examples

The following are more shortcut examples:

JCL,member,JCLID=nnn

Entering this command on the top line (where JCLID defaults to zero) has the same
result as the following three steps:
1. DB.7 top line command
2. FETCH function with member and JCLID of nnn
3. EDIT function

JOB,jobname

Entering this command on the top line has the same result as the following two steps:
1. DB.1 top line command
2. LIST function with a job name

Function Transfer
To transfer from one menu or formatted panel to another, enter the panel name in the
FUNCTION field of the current panel. For example, you can transfer to Queue
Maintenance by entering QM in the FUNCTION field of the panel.

Chapter 1: Introduction 23
Online Input

Aliases for Formatted Panel Functions

All function values for formatted panels can be assigned alternate (alias) names. Aliases
allow for user-designated abbreviations (for example, L for LIST). Aliases also permit
alternate values such as 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 alias
names.

The following table is a list of formatted panel function values and some alias names
that are distributed with the product:

Functions Service Level Alias

ADD ADD A,ADDT,AELETE,AIST,APD
APPEND READ AP,APP
APPENDP READ N/A
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,REPLH
REQ UPDATE N/A

24 Database Maintenance Guide

 Batch Input

Functions Service Level Alias

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
XRST UPDATE N/A
XSPOST UPDATE N/A
XSPRE UPDATE N/A
XUPD UPDATE N/A
XWLP UPDATE N/A

Note: For more information about modifying the alias values, see the Systems
Programming Guide.

Batch Input
Two different formats for transaction input and output are supported.

Chapter 1: Introduction 25
Batch Input

Online Format
The Online format is used in CA WA CA 7 Edition online terminal sessions. Online
terminal sessions support the command-line input and output and data transfer using
formatted panels.

Unless the online terminal session is in text editor mode, all input beginning in the
upper left corner of the panel is interpreted as command-line input. Transactions that
are entered in this area are referred to here as command transactions.

A command transaction begins with the command name and parameters can follow.
These transactions are documented in the Command Reference Guide.

Formatted panel transactions differ from the command transactions. Input for
formatted panel functions is not solicited at the command line. The formatted panels
structure input and output in an online terminal session using delimited and tagged
panel fields. Some functions require formatted panel transactions. Most database
maintenance functions require transactions in this mode.

Batch Format
The external communicators like the Batch Terminal Interface (BTI) and the CAICCI
Terminal Interface use the batch format.

Command transactions are entered in batch format in the same way that they would be
in an online terminal session. However, functions that use formatted panels in the
online environment have special syntax requirements in batch, because formatted
panels cannot be displayed in batch.

In some cases, batch and online transaction formats differ. For those cases, the
documentation of each online function includes the description of the corresponding
batch transaction format.

Note: For more information about external communicators, see the Interface Reference
Guide.

Remove Field Contents Using Batch Input

When you update text fields in batch mode, code the appropriate keyword with a blank
after the equal sign.

Example: Reset the SYSTEM keyword

UPD,CA07XX01,SYSTEM= ,REGION=50

Another value to update must follow the keyword even when it remains the same.

26 Database Maintenance Guide

 Long Job Names

Function Shortcuts and Bypassing the Menu

The shortcuts available online to bypass certain panels are of limited value in batch.
Batch transactions must single step from function to function much as a new user steps
through a sequence of equivalent panels (for example, DBM, SCHD, JOB, and others).
Some commands that provide secondary menu panels online, such as DB.2, DB.3, and
DB.4, use positional keywords to identify the specific function rather than requiring
another command to be entered separately.

Function Transfer
To transfer to another DB function, input a record with the corresponding batch panel
name starting in the first column. For an example of function transfer between DB mode
and top line command mode, see the N220 installation job. To exit from Database
Maintenance using batch input, the user must input a record with DBM starting in the
first column.

Aliases for Formatted Panel Functions

Batch commands can use any of the alias names that were assigned just as they are
used online.

Note: For the procedures for assigning alias names, see the "User Exits and
Modifications" chapter of the Systems Programming Guide.

Long Job Names

You can assign a long job name to a CA WA CA 7 Edition job. This long job name is an
alias of the short job name and cannot exist on its own. If no short name is entered on a
job definition screen, a short name is generated.

Chapter 1: Introduction 27
Long Job Names

Triggers
Several alternate panels are available for job, input network, and data set triggering
based on long job names. While similar to the regular panels, these new panels have a
different field layout to provide space for the full long job name length. The panel
commands and short names:
■ DB.2.4L (see page 124), SCHD,JTRGL, for the job triggers.
■ DB.2.5L (see page 127), SCHD,NTRGL, for the input network triggers.
■ DB.2.6L (see page 134), SCHD,DTRGL, for the data set triggers.

These panels follow the same security rules as their regular counterparts (DB.2.4,
DB.2.5, DB.2.6).

JOB/L indicates that you can enter a long or short job name. You can also enter the long
or short name in the TRGD-JOBL field. The slash before TRGID indicates that it is the
start of the second line of input. The TRGID, DOTM, QTM, LDTM, SBTM, and exceptions
fields are on the second line of each entry.

Listing triggers displays the long job name, when possible, no matter which name was
used to define the trigger.

Job Predecessors
The alternate panel, DB.3.2L (see page 162), is available for job predecessors that are
based on long job names. While similar to the DB.3.2 panel, this new panel has a
different field layout to provide space for the full long job name length. The new panel
has a short name of JOBCONN,JOBL. The security rules for this panel match the rules for
DB.3.2.

JOB/L indicates that you can enter a long or short job name. You can also enter the long
or short name in the PRED-JOBL field. The S field is the new LIST-SCHID field. The slash
before LEADTM indicates that it is the start of the second line of input. The LEADTM and
NEXT-RUN fields are on the second line of each entry.

Listing predecessors displays the long job name, when possible, no matter which name
was used to define the requirement.

Note: You cannot define generic dependencies like LongJob* using this panel. Define all
generic dependencies using the DB.3.2 screen.

28 Database Maintenance Guide

 Long Job Names

Network Tasks
The alternate panel, DB.3.4L (see page 172), is available for network tasks that are
based on long job names. While similar to the DB.3.4 panel, this new panel has a
different header layout to provide space for the full long job name length. The new
panel has a short name of JOBCONN,NWKL. The security rules for this panel match the
rules for DB.3.4.

JOB/L indicates that you can enter a long or short job name. The S field is the new
LIST-SCHID field.

User Memo-Form Predecessors

The alternate panel, DB.3.6L (see page 178), is available for user predecessors that are
based on long job names. While similar to the DB.3.6 panel, this new panel has a
different header layout to provide space for the full long job name length. The new
panel has a short name of JOBCONN,USRL. The security rules for this panel match the
rules for DB.3.6.

JOB/L indicates that you can enter a long or short job name. The S field is the new
LIST-SCHID field.

For both the original and new user predecessor screens, the predecessor text can now
be mixed case. Previously the text was forced to uppercase.

Long Job Name Rules

The following rules apply to the long job names:
■ Any long job name that is eight or fewer characters in length must match its short
name, ignoring case.
■ The existing jobs do not require a long job name.
■ Long job names that come through the distributed job conversion process must
only contain alphanumerics, underscores, periods, and national characters (@, #, $).
An error is issued when a name does not follow this rule.
■ If you assign a job name, the first character must be an alphabetic or a national
character. The second character must not be a period or an underscore.
■ Jobs that are created in CA WA CA 7 Edition only have a long job name when a user
specifically assigns one.
■ In top line commands, the JOB and JOBL keywords are mutually exclusive.
■ In alternate screens, specify the regular or long job name in the job name fields. CA
WA CA 7 Edition displays the long job names when available using fetched
information (like a LIST function).

Chapter 1: Introduction 29
Long Job Names

More information:

DB.1 - CPU Job Definition Panel (see page 34)

DB.10 - XP Job Definition Panel (see page 50)
DB.11 - Agent Job Definition Panel (see page 64)
DB.2.4L - Job Triggering Panel (Long Job Name) (see page 124)
DB.2.5L- Input Network Triggering Panel (Long Job Names) (see page 127)
DB.2.6L - Data Set Triggering Panel (Long Job Names) (see page 134)
DB.3.2L - Job Predecessors Panel (Long Job Name) (see page 162)
DB.3.4L - Input/Output Network Tasks Panel (Long Job Names) (see page 172)
DB.3.6L - User Memo-Form Predecessors Panel (Long Job Names) (see page 178)

30 Database Maintenance Guide

Chapter 2: Setting Up and Maintaining
Jobs
This section describes setting up and maintaining a job in the CA WA CA 7 Edition
database.

This section contains the following topics:

Types of Jobs (see page 31)
How You Add a Job (see page 32)
Usage Notes for DB.1, DB.10, and DB.11 (see page 33)
DB.1 - CPU Job Definition Panel (see page 34)
How You Change a CPU Job (see page 50)
DB.10 - XP Job Definition Panel (see page 50)
DB.11 - Agent Job Definition Panel (see page 64)

Types of Jobs
You can define and schedule up to three types of jobs through CA WA CA 7 Edition.
■ The first job type is the CPU job. This type of job is submitted to the Job Entry
System (JES) of a z/OS operating system.
■ The second job type is the XPJOB. This type of job executes on another platform
that is executing another CA scheduling system or a CA job management agent,
such as CA UJMA.
■ The third job type is actually a job category, CA WA CA 7 Edition agent jobs. These
jobs can be FTP jobs, SAP jobs, database jobs, and more. CA WA CA 7 Edition
submits these jobs to execute on a platform running the CA system agent and
associated plug-in.

Unless stated, "job" applies to all job types. If the word job has an adjective of CPU,
XPJOB, or agent, the sentence or section applies to the specific job type mentioned. If
something applies only to XPJOB or an agent job, the words "internal cross-platform
job" are used (this designation does not include CPU jobs).

When requesting information about a job, you can enter the request from the JOB
(CPU), XPJOB, or Agent Job Definition panels. CA WA CA 7 Edition tests the type of job
being requested and redirects processing to the appropriate job definition panel if
necessary.

Chapter 2: Setting Up and Maintaining Jobs 31

How You Add a Job

For example, if you request information about a CPU job from the XP Job Definition
panel, you are redirected to the JOB Definition panel. Likewise, if you request
information about an agent FTP job from the JOB Definition panel, you are redirected to
the Agent Job Definition panel. This redirection applies to the LIST and any DELETE
functions. If the function is UPDATE, you must be on the panel representing the job
type. If an UPDATE function is attempted from the incorrect panel, an error message is
issued.

How You Add a Job

You can add jobs in several ways. The primary method is entering data on the DB.1
panel. However, other methods are available.
■ If the job information already exists in machine-readable form, you can write a
program to perform the DB.1 panel functions using batch commands with a Batch
Terminal Interface (BTI) job.
Note: For more information about BTI, see the Interface Reference Guide.
■ If the JCL library is defined to CA WA CA 7 Edition but the jobs are not added to the
database, you can use the DEMAND command to add the job to the database. This
command causes the job to execute. The execution includes a LOAD step because
the job is not defined in the database. You can also use the LOAD command to
submit the jobs, but they do not execute. When scheduled using the LOAD
command, the LOAD step executes but the rest of the job's JCL is flushed.

To use the DEMAND or LOAD commands to add the job, certain conditions must be met.
■ The job name of the job to be added must be the same as the JCL member name in
the JCL library.
■ The default values defined for the DB.1 panel must satisfy the job characteristics.
The default values for the DB.1 panel can be overridden by defining a job that is
named DEFAULTS with the values wanted. Also, if CLASS, JCLID, or JCLLIB is specified
on the command, these values can override the DEFAULTS job values. System
defaults cannot be overridden with the DEMAND and LOAD commands. Job
characteristics, not covered by the defaults, must be manually checked.
■ The JCL library ID number or symbolic JCL library name must be specified on the
command. One JCL library should have an index value of 0 (zero). With the zero
value, you do not have to enter the DB.1 panel JCLID field for jobs with JCL residing
in that library when issuing the top line JCL command.

32 Database Maintenance Guide

 Usage Notes for DB.1, DB.10, and DB.11

The DEMAND command represents on-request scheduling that is useful on a first-time

basis. As an ongoing practice, we do not recommend this method except for jobs that
must always be handled as on-request work.

You can add internal cross-platform jobs through the DB.10 panel and DB.A.x panels or
through an external terminal interface such as Batch Terminal Interface (BTI) or CAICCI
Terminal Interface (CTI) batch job. You can demand an internal cross-platform job to
cause its execution, but the DEMAND command always searches the database for
definition. The DEMAND command does not add any cross-platform jobs to the CA WA
CA 7 Edition database.

More information:

Batch Input (see page 25)

Usage Notes for DB.1, DB.10, and DB.11

Many of the fields have predefined default values that are assigned when no value is
entered. Once a job has been added, the LIST function returns this panel with all fields
containing either the specified data or the defaults taken.

If you want different default values for a job, add a job with the wanted default values
give it the name mentioned with the keywords that follow. All future adds, either online
or batch, then use that job for default values. If you want some other job name for the
defaults pattern job, set the initialization file DBASE statement with the parameter to
the correct job name.
■ DEFAULTJOB for CPU jobs (default is DEFAULTS)
■ DEFAULTXPJ for cross-platform jobs (default is DEFAULTX)
■ DEFAULTAG for agent jobs (default is DEFAULTA)

For all job types, you cannot set the UID value with a default job.

To control which jobs are eligible to be marked as LATE, use the LATEPROMPT keyword
on the OPTIONS statement in the initialization file. If you specify LATEPROMPT=LATE,
jobs that are defined with PROMPT: N never show a status of LATE on the LQ displays
(including LREQ, LRDY, LACT, and so on). This setting lets your operations staff
concentrate on important jobs when they show up as LATE.

Chapter 2: Setting Up and Maintaining Jobs 33

DB.1 - CPU Job Definition Panel

The JOB and JOBL fields have different properties depending on which function has
been specified:
■ If you add a job definition, you can use both the JOB and JOBL fields simultaneously.
The job name and long job name must both be unique. Additionally, if the length of
the long job name is fewer than nine characters, it must match the regular job
name, ignoring case.
■ If you delete a job definition, you can use both the JOB and JOBL fields
simultaneously. They must refer to the same job. A discrepancy causes an error
message.
■ If you update a job definition with both the JOB and JOBL fields in use, the following
action occurs. When the JOBL field does not refer to the same job as the JOB field,
the long job name for the job in the database is updated to match the field input.
The same rules apply as for creating a job with a long job name.
■ If a job definition does not have a long job name, you can assign one by completing
the JOBL field and using the update function.

DB.1 - CPU Job Definition Panel

The DB.1 - CPU Job Definition panel lets you enter or review data that is related to CPU
jobs.

To display the panel, enter:

■ 1 as the FUNCTION on the Database Maintenance (DBM) Menu panel.
■ DB.1 as the FUNCTION value on any other menu or formatted input panel.
■ DB.1 or JOB as a top line command.

To exit the panel:

■ Press PF3 to return to the DBM Menu panel except with the TSO-ISPF interface
when the PF3 key is assigned to another function.
■ Move the cursor to the top line of the panel and enter a top line command for
another function.

34 Database Maintenance Guide

 DB.1 - CPU Job Definition Panel

------------------------- CA-7 CPU JOB DEFINITION --------------------------

FUNCTION: xxxxxxxx (ADD,DELETE,DD,PURGE,DELPRRN,FORMAT,LIST,UPD)
JOB: xxxxxxxx
GENERAL: SYSTEM: xxxxxxxx JOBNET: xxxxxxxx OWNER: xxxxxxxx UID: nnn
JOBL: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
JCL: ID: nnn MEMBER: xxxxxxxx RELOAD: x EXEC: x RETAIN-JCL: x
LIB: xxxxxxxxxxxxxxxx

REQUIREMENTS: HOLD: x JCL-OVRD: x USE-OVRD-LIB: x VERIFY: x MAINT: x

SATISFACTION LEAD-TIME: JOB: nn DSN: nn ARFSET: xxxxxxxx

EXECUTION: MAINID: xxxx INSERT-RMS: x COND-CODE: nnnn RO: xx

DONT SCHEDULE -- BEFORE: yyddd hhmm AFTER: yyddd hhmm

MESSAGES: LTERM: xxxxxxxx REQUIREMENT-LIST: x PROMPTS: x

ERROR MSGS -- RQMTS NOT USED: x DSN NOT FOUND: x

RESOURCES: REGION: nnnn CLOCK-TIME: hhmm CPU-TIME: mmmss

CLASS: x PRTY: nnn MSGCLASS: x DRCLASS: xxxxxxxx
TAPE DRIVES...TYPE1: nnn M nnn C TYPE2: nnn M nnn C

PROGRAM: SM20 MSG-INDX: nn -- DB.1 -- yy.ddd / hh:mm:ss

MESSAGE: ENTER FUNCTION, TRANSFER OR ENTER A COMMAND ON THE TOP LINE

This panel contains the following fields:

FUNCTION
Specifies the function to be performed. Value must be the name of some other
panel or one of the following:
ADD
Adds a job to the database.
DELETE
Deletes a job and its associated data from the database (documentation,
schedules, and so forth).
DD
Same as DELETE, but deletes any data sets that this job references if the data
sets have no users and no documentation, and do not cause job triggering. This
includes all virtual resources connected to the job.
PURGE
Same as DD, but also deletes job trigger definitions that trigger the job being
deleted, job requirement definitions that require the job being deleted; and, if
the CA WA Restart Option interface is active, deletes the CA WA Restart Option
CMT member for the job being deleted.
DELPRRN
Deletes the JCL saved in the trailer queue from the job's prior run.
FORMAT
Clears the panel of all input data.

Chapter 2: Setting Up and Maintaining Jobs 35

DB.1 - CPU Job Definition Panel

LIST
Lists a job and job-related information. In batch, a formatted panel is not listed.
Only a found or not found message is returned.
UPD
Updates database information about a job.
Batch keyword: Positional parameter
Note: A default interpretation can be set for the DELETE function in the CA WA CA 7
Edition initialization file. For more information, see the OPTIONS statement in the
chapter "Initialization FIle" of the Systems Programming Guide.
Also, when using the PURGE function, some residual elements may not be deleted if
the user issuing the PURGE does not have update access to the other jobs affected.
For information about bypassing these security checks, see the BYPSEC keyword in
the chapter "Security Initialization Options" of the Security Reference Guide.
JOB
Defines the job name on which to perform the indicated function.
Limits: 1 to 8 alphanumeric characters
Batch keyword: Positional parameter
Note: Job name format of UCC7Rxxx (where xxx is any three characters) is reserved
for use with Workload Balancing. This imposes a restriction that no other
user-defined job can begin with UCC7R as the first five characters.
This job name always overlays the job name on the JOB statement in the execution
JCL.
GENERAL
Indicates that this section of the panel contains general information about the job.
No input is permitted for this field.
SYSTEM
(Optional) Specifies the user-defined application system name of which this job is a
part.
Limits: 1 to 8 alphanumeric characters. This field cannot contain a comma.
Batch keyword: SYSTEM
JOBNET
(Optional) Specifies the name of a CPU job network of which this job is a part.
Limits: 1 to 8 alphanumeric characters. This field cannot contain a comma.
Batch keyword: JOBNET

36 Database Maintenance Guide

 DB.1 - CPU Job Definition Panel

OWNER
(Optional) Specifies the ID identifying ownership of this job. Depending on the CA
WA CA 7 Edition startup options taken, the external security product being used
and contents of the JCL, this value can be offered to the external security package
by CA WA CA 7 Edition at job submission time as the authority for this job to be
executed.
Limits: 1 to 8 alphanumeric characters. Although this field supports up to 8
characters, some external security packages only accept up to 7 characters. This
field must not exceed any such limit that exists.
Batch keyword: OWNER
UID
(Optional) Specifies the CA WA CA 7 Edition user security identification.
Default: 0 (no internal security protection)
Limits: 1 to 3 numeric characters from 0 through 999
Batch keyword: USERID
JOBL
(Optional) Defines the long job name on which to perform the indicated function.
Note: For more information, see Long Job Name Rules (see page 29).
Limits: 1 to 64 alphanumeric characters, case sensitive.
Batch keyword: JOBL
JCL
Indicates that this line of the panel contains JCL information about the job. No input
is permitted for this field.
ID
(Optional) Specifies a numeric index value that is associated with a JCL library. Two
values have special significance: 254 is reserved to indicate the override library (see
the USE-OVRD-LIB field for more information) and 255 is reserved for use with the
HELP library. 255 is also assigned to libraries that are referenced using a symbolic
index (see the LIB field for more information). LIB and ID are mutually exclusive.
Default: 0
Limits: 1 to 3 numeric characters 0-253 and 256-999
Batch keyword: JCLID

Chapter 2: Setting Up and Maintaining Jobs 37

DB.1 - CPU Job Definition Panel

MEMBER
(Optional) Specifies the JCL library member name and required when the member
name and job name are different.
Default: Job name
Limits: 1 to 8 alphanumeric characters
Batch keyword: JCLMBR
RELOAD
(Optional) Specifies whether to reload this job's JCL (Y, N, or X). When a job comes
into the request queue, it is either flagged for load processing or it is not flagged. If
RELOAD=X, the job is not flagged for load processing unless the LOAD command is
used. If RELOAD=Y, the job is flagged for load processing. If RELOAD=N, the job is
not flagged for load processing unless it is the first time it has run in CA WA CA 7
Edition. A RELOAD=Y is automatically reset to N once the load completes
successfully. A RELOAD=X is never automatically changed even if the LOAD
command is used.
Default: N
Batch keyword: RELOAD
EXEC
(Optional) Indicates whether to execute this job.
Y
Specifies to execute the job. Y is the default.
N
Specifies that the job does not run but shows a normal completion as if it did
run. JCL is not required for nonexecutable jobs.
Note: Consider the following items:
■ Since nonexecutable jobs do not get executed, no data sets are created. This
means that any jobs waiting for data set requirement that may have been
created for the job execution are not created and thus jobs may wait on these
data set requirements.
■ VRM definitions are ignored for the nonexecutable jobs.
■ Critical Path Management flows cannot be started with nonexecutable job, and
thus the critical path may not be monitored.
■ ARF recovery is not invoked for nonexecutable jobs.
Default: Y
Batch keyword: EXEC

38 Database Maintenance Guide

 DB.1 - CPU Job Definition Panel

RETAIN-JCL
(Optional) Specifies whether to retain the execution JCL in the trailer queue after a
successful run (Y or N).
Default: N
Batch keyword: RETJCL
LIB
(Optional) Specifies a JCL library identification. Must be a symbolic INDEX assigned
to a JCL statement. Symbolic value &HELP is reserved for the HELP library. LIB and
ID are mutually exclusive.
Limits: 2 to 16 alphanumeric characters beginning with ampersand (&)
Batch keyword: JCLLIB
Note: The schedule scan uses the current specification for LIB when attempting to
attach the JCL for a job in the request queue with RETRY status.
REQUIREMENTS
Specifies that this section of the panel contains requirements information about the
job. No input is permitted for this field.
HOLD
(Optional) Specifies whether to place this job in a hold status when it enters the
request queue (Y or N).
Default: N
Batch keyword: HOLD
JCL-OVRD
(Optional) Specifies whether this job needs manual JCL overrides before it can be
submitted (Y or N). Similar to the JCLOVRD command.
Default: N
Batch keyword: JCLOVR

Chapter 2: Setting Up and Maintaining Jobs 39

DB.1 - CPU Job Definition Panel

USE-OVRD-LIB
(Optional) Specifies whether to retrieve the JCL from the JCL Override library
(JCLID=254) for the next run only (Y or N). This field is automatically set back to N
the next time the job comes into the request queue.
Default: N
Batch keyword: JOVRDLIB
VERIFY
(Optional) Specifies whether this job requires any presubmission manual
verification (Y or N). Similar to VERIFY command.
Default: N
Batch keyword: VERIFY
MAINT
(Optional) Specifies whether this job is a maintenance job (for example, a system
utility) with no production data set requirements (Y or N). If MAINT=Y, all input data
set requirements are ignored. None of the output data sets created by this job is
posted back to CA WA CA 7 Edition.
Marking a job as MAINT enables job triggering but not data set triggering.
Also, if the LOADDSNS keyword is used on the DBASE statement in the initialization
file, the LOAD process does not build any DD or data set information for jobs that
are marked MAINT=Y on the DB.1 (JOB) panel. This means that there are not any
data set connections for these jobs unless added manually.
Default: N
Batch keyword: MAINT
SATISFACTION LEAD-TIME
Indicates that this area of the panel contains lead time information about the job
requirements. No input is permitted for this field.
JOB
(Optional) Specifies the number of hours to be considered when satisfying
job-dependent requirements.
The following values are possible:
0
Specifies no lead time is considered when satisfying this job's requirements.
99
Specifies the requirement is never considered as already satisfied when the job
enters the queues. Each predecessor job must complete typically while this job
is in the request queue.

40 Database Maintenance Guide

 DB.1 - CPU Job Definition Panel

nn
Since the last run of this job, specifies that each predecessor job must have run
within the last nn hours. Values for nn can be from 1 to 98.
Default: 0
Batch keyword: JOBLDTM
Note: JOB and DSN are on a global level for all job and data set requirements that
have a LEADTM value of 0000 on the DB.3 panels. This applies to all SCHIDs that the
job runs under.
DSN
(Optional) Specifies the number of hours to be considered when satisfying data set
requirements. For a description of values, see preceding field name (JOB).
Default: 0 (specifies to ignore this field)
Limits: 1 to 2 numeric characters from 0 to 99
Batch keyword: DSNLDTM
ARFSET
(Optional) Names the collection of ARF definitions that apply to this job. Remember
that ARF recovery is not invoked for nonexecutable jobs.
Limits: 1 to 8 alphanumeric characters
Batch keyword: ARFSET
Note: The specified ARFSET must be defined in the ARF database.
EXECUTION
Indicates that this panel section contains execution information about the job. No
input is permitted for this field.
MAINID
(Optional) Specifies on which CPU the job can or cannot be scheduled. If the job
requirements impose CPU restrictions, specify SYn or /SYn where n is the system
number and / indicates not this system. System numbers must be consistent with
the initialization file CPU statement MAINIDS parameters.
Default: ALL (lets the job run on any CPU)
Limits: 1 to 4 alphanumeric characters
Batch keyword: MAINID
Note: If a triggered job does not specify a MAINID, the job runs with the MAINID
specified by the triggering job.

Chapter 2: Setting Up and Maintaining Jobs 41

DB.1 - CPU Job Definition Panel

INSERT-RMS
(Optional) Specifies whether to insert the CA WA Restart Option RMS step
automatically at execution time by CA WA CA 7 Edition. Y inserts the step with the
CA WA Restart Option processing code of P. N does not insert the RMS step. Unless
a different name is specified with the PROCRMS parameter on the RESTART
statement of the initialization file, the default procedure name defined in the CA
WA Restart Option Option Table is inserted.
Note: For more information, see the Interface Reference Guide.
Default: N
Batch keyword: INSRTRMS or RESTART
COND-CODE
(Optional) Used with RO (relational operator) to define the job-level condition
codes used to determine whether a job executes successfully.
Default: 0
Limits: 1 to 4 numeric characters from 0 to 4095
Batch keyword: CONDCODE
RO
(Optional) Specifies the relational operator of the condition code (COND-CODE) or if
the step level #SCC statements are being used in the job's JCL.
The following are the possible values:
EQ
Specifies equal to.
LT
Specifies less than.
GT
Specifies greater than.
GE
Specifies greater than or equal to.
LE
Specifies less than or equal to.
NE
Specifies not equal to.

42 Database Maintenance Guide

 DB.1 - CPU Job Definition Panel

#S
Specifies to make step condition code tests based on #SCC statements in the
JCL.
IG
Specifies to do no evaluation of the job. CA WA CA 7 Edition always assumes
the job completes successfully, regardless of condition codes, abend codes, or
runtime JCL errors. When this is used, the INSERT-RMS fields should be N.
0
Specifies to make no condition test.
Default: 0
Batch keyword: RELOPR
If 0 is used, no test is made on the job's condition code.
The highest condition code that this job generates is tested by this pair of
parameters. For example, if COND-CODE is set at 8 and RO is set at LT, the job is
marked as completing abnormally if 8 is less than the job's highest condition code.
Note: This test is for internal use by CA WA CA 7 Edition only. It simply tells CA WA
CA 7 Edition what action to take after the job completes. CA WA CA 7 Edition does
not determine or control which steps are to be executed.
DONT SCHEDULE -- BEFORE
(Optional) Specifies not to schedule this job before this date and time. This field is
especially helpful for timing the start of new jobs.
The following is a sample of panel input:
BEFORE: yyddd hhmm
yyddd
Defines the Julian date.
hhmm
Defines the time of day.
The following is a sample of batch input:
BDATE=yyddd,BTIME=hhmm
Default: All zeros
Limits: Julian date specified as yyddd and time specified as hhmm
Batch keyword: BDATE and BTIME

Chapter 2: Setting Up and Maintaining Jobs 43

DB.1 - CPU Job Definition Panel

AFTER
(Optional) Specifies not to schedule this job after this date and time. This field is
especially helpful for timing the permanent discontinuation of a job.
The following is a sample of panel input:
AFTER: yyddd hhmm
yyddd
Defines the Julian date.
hhmm
Defines the time of day.
The following is a sample of batch input:
ADATE=yyddd,ATIME=hhmm
Default: 99999 0000
Limits: Julian date specified as yyddd and time specified as hhmm
Batch keyword: ADATE and ATIME
Note: If BDATE and BTIME values are equal to ADATE and ATIME, the job is not
scheduled and does not appear on forecasts. If BDATE and BTIME values are greater
than ADATE and ATIME, the job is not available for scheduling during the inclusive
times only. Thus, if BDATE=09031 and BTIME=2359 and ADATE=09001 and
ATIME=0000, the job does not schedule during the time from Jan. 1, 2009 through
Jan. 31, 2009, but does schedule at all other times.
CA WA CA 7 Edition uses current date and time for comparisons.
MESSAGES
Indicates that these lines of the panel contain information about messages that
may occur for the job. No input is permitted for this field.
LTERM
(Optional) Routes the messages about this job to this logical terminal name.
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.
Default: If not entered, the LTERM associated with the JCL library in the
initialization file JCL statement is used. If LTERM is not specified on the JCL
statement, the default is MASTER.
Limits: 1 to 8 alphanumeric characters
Batch keyword: LTERM

44 Database Maintenance Guide

 DB.1 - CPU Job Definition Panel

REQUIREMENT - LIST
(Optional) Specifies whether to list preexecution requirements for this job when it
enters the request queue (Y or N).
Default: Y
Batch keyword: RQLST
PROMPTS
(Optional) Specifies whether to issue prompt messages when this job is late (Y or
N).
Default: Y
Batch keyword: PROMPT
Note: If LATEPROMPT=LATE is specified on the OPTIONS statement of the CA WA
CA 7 Edition initialization file, setting this value to no (N) prevents the job from ever
having a status of LATE on an LQ or LRLOG display. The jobs defined with a value of
yes (Y) are processed the same regardless of the LATEPROMPT setting.
ERROR MSGS -- RQMTS NOT USED
(Optional) Specifies whether to issue error messages for job requirements not used
(Y or N).
Default: Y
Batch keyword: RQMSG
DSN NOT FOUND
(Optional) Specifies whether to list error messages for data sets used at execution
time but not found in the CA WA CA 7 Edition database (Y or N).
Default: Y (The messages are not issued if PERFORM=1 is specified on the INIT
statement in the initialization file.)
Batch keyword: DSNMSG
RESOURCES
Indicates the resource information about the job. No input is permitted in this field.

Chapter 2: Setting Up and Maintaining Jobs 45

DB.1 - CPU Job Definition Panel

REGION
(Optional) Specifies the region size that is required by this job (information only).
Default: 0
Limits: 1 to 4 numeric characters
Batch keyword: REGION
CLOCK-TIME
(Optional) CA WA CA 7 Edition maintains certain SMF feedback data in its database,
including a weighted average elapsed runtime. If the database is updated with a
time of 0000, the counters for number of runs, number of times late, and number
of restarts are also reset to 0000. One use of this value is deadline prompting. If
2359 is specified, deadline prompt time is not adjusted. It remains due-out time
minus lead time.
Note: Clock time and CPU time averages are not updated if the job either fails
(abend, JCL error, and so on) or is restarted. The weighted average is the value in
the database times 5, plus the value from the current run, divided by 6. This tends
to keep the current run from possibly skewing the value.
Default:
0000
Limits: 4 numeric characters specified as hhmm, where hh can be 00 through 23
and mm can be from 00 to 59
Batch keyword: ELAPTM

46 Database Maintenance Guide

 DB.1 - CPU Job Definition Panel

CPU-TIME
(Optional) CA WA CA 7 Edition maintains weighted average CPU time usage values
for each job in its database. (See the preceding note under CLOCK-TIME.)
Limits: 5 numeric characters specified as mmmss, where mmm is minutes and ss is
seconds
Batch keyword: CPUTM
CLASS
(Optional) Specifies the CA WA CA 7 Edition WLB job class. If CLASS is not specified,
a WLB class of A is automatically assigned. This value does not have to match the
JOB statement CLASS value.
The CLASS specified here does not apply when the job enters the queue as a result
of a RUN(H) command. Class 9 is assigned by default. To override class 9, use the
RUNCLASS keyword on the OPTIONS statement in the initialization file.
The CLASS specified here does not apply when the job enters the queue as a result
of a LOAD(H) command. Class 8 is assigned by default. To override class 8, use the
LOADCLASS keyword on the OPTIONS statement in the initialization file.
Default: A space
Limits: 1 alphanumeric character
Batch keyword: CLASS
PRTY
(Optional) Specifies the CA WA CA 7 Edition WLB job priority. A value of 255
indicates an express priority used to bypass WLB priority scheduling criteria. If using
WLB, any job without a specified priority is automatically assigned a priority of 100
unless the default is changed.
Default: 0
Limits: 1 to 3 numeric characters from 0 to 255
Batch keyword: PRTY
MSGCLASS
(Optional) Specifies the job's message class. This field is informational only. Even
though this field can be changed, it does not cause the JCL to be changed. Also, no
validity checking is done on this field.
Default: A space
Limits: 1 alphanumeric character
Batch keyword: MSGCLASS

Chapter 2: Setting Up and Maintaining Jobs 47

DB.1 - CPU Job Definition Panel

DRCLASS
(Optional) Specifies the job's disaster recovery class. This field has no impact on
processing during normal execution. When running in disaster recovery mode, the
disaster recovery class is used to determine whether the job should execute.
Note: For more information, see disaster recovery mode in the Systems
Programming Guide.
Limits: 1 to 8 alphanumeric characters. Disaster recovery class values must start
with a letter, #, or $ (not @) and can include letters, #, $, @, and numbers. Disaster
recovery classes cannot contain embedded blanks.
Batch Keyword: DRCLASS
TAPE DRIVES
Indicates that this line of the panel contains information about tape drives needed
for the job. (If not using Workload Balancing, these fields are informational only.)
No input is permitted for this field.
TYPE1
Indicates that the two following fields (M and C) contain information about TYPE1
tape drives need for the job. No input is allowed for this field.
M
(Optional) Specifies a manual override value for the number of TYPE1 tape drives
needed for the job. Normally this field is only used to update a job where tape drive
requirements have been changed, higher or lower, and the job has not been
reloaded after the change. A value of 255 can be used to specify that the job uses 0
TYPE1 tape drives.
Default: 0
Limits: 1 to 3 numeric characters from 0 to 255
Batch keyword: TP1M
C
Indicates the calculated value for the number of TYPE1 tape drives needed for the
job. Value is automatically calculated when the job is loaded (or reloaded) or the
RESANL command is performed on the job. Calculation is based on DD references
whose unit values are defined as TYPE1 tape drives in the SASSUTBL module. This
field is display only, and no input is permitted.
TYPE2
Indicates that the following two fields (M and C) contain information about TYPE2
tape drives need for the job. No input is allowed for this field.

48 Database Maintenance Guide

 DB.1 - CPU Job Definition Panel

M
(Optional) Specifies a manual override value for the number of TYPE2 tape drives
needed for the job. Normally this field is only used to update a job where tape drive
requirements have been changed, higher or lower, and the job has not been
reloaded after the change. A value of 255 can be used to specify that the job uses 0
TYPE2 tape drives.
Default: 0
Limits: 1 to 3 numeric characters from 0 to 255
Batch keyword: TP2M
C
Indicates the calculated value for the number of TYPE2 tape drives needed for the
job. The value is automatically calculated when the job is loaded (or reloaded) or
the RESANL command is performed on the job. Calculation is done as described in
TYPE1. This field is display only, and no input is permitted.

More information:

#SCC Statement (see page 328)

DB.3 - Job Predecessor/Successor Menu Panel (see page 152)
Usage Notes for DB.1, DB.10, and DB.11 (see page 33)

Example: Batch Input

This batch input example adds job CA07XX01 specifying a system, a JCLID, and a class:

JOB
ADD,CA07XX01,SYSTEM=TESTNTWK,JCLID=3,CLASS=A
DBM

For more information about the batch keywords, see the previous definitions of these
panel fields.

Chapter 2: Setting Up and Maintaining Jobs 49

How You Change a CPU Job

How You Change a CPU Job

The basic way to change the characteristics of a job, which appear on the DB.1 panel, is
to use the UPD function. However, you can make wholesale changes to many jobs using
the Batch Terminal Interface (BTI) facility.

Note: For more information about BTI, see the Interface Reference Guide.

The database information must always agree with the JCL for the job. Therefore,
whenever permanent changes are made to the JCL, resynchronize the database with
new JCL. The CA WA CA 7 Edition LOAD process accomplishes this process, and you can
handle it in one of several ways.
■ Manually issue a LOAD command after the JCL has been changed.
■ Set the RELOAD value on the DB.1 panel to Y if the change is made outside of CA
WA CA 7 Edition (for example, through TSO).
■ Make any permanent changes to the JCL through the DB.7 panel. This method
causes the RELOAD field on the DB.1 panel to be set to Y automatically.

Note: The DB.3 panels establish dependency relationships for CPU jobs, workstation
networks, and so forth, thereby defining prerequisites. Whenever the JCL changes for
any job, consider whether those changes affect the dependency relationships for the
job.

More information:

Batch Input (see page 25)

Mass Changes at Existing Site (see page 436)

DB.10 - XP Job Definition Panel

The DB.10 - XP Job Definition panel lets you enter or review data that is related to
XPJOB jobs.

To display the panel, enter:

■ A.A as the FUNCTION on the DB Menu panel.
■ DB.10 as the FUNCTION on any other menu or formatted input panel.
■ DB.10, XPJOB, or DB.A.A as a top line command.

50 Database Maintenance Guide

 DB.10 - XP Job Definition Panel

To exit the panel:

■ Press PF3 to return to the DB Menu panel except with the TSO/ISPF interface when
PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter a top line command if you
want another function.

------------------------- CA-7 XP Job Definition --------------------------

Function: xxxxxxxx (Add, DD, Delete, DELPRRN, Format, List, Purge, Update)
Job: xxxxxxxx
JobL: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
System: xxxxxxxx JOBNET: xxxxxxxx Owner: xxxxxxxx UID: nnn
XP Node: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
XP EXEC: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
XP PARM: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Optional PARMLIB: xxxxxxxxxxxxxxxx Member: xxxxxxxx Use-Ovrd-Lib:

EXEC: x SUTYPE: x Cond-Code: xxxx RO: xx DRClass: xxxxxxxx

Hold: x Verify: x Satisfaction Lead Time: nn ARFSET: xxxxxxxx
Clock Time: nnnn WLBClass: x WLBPRTY: nnn Trace: x
Don't Schedule Before: yyddd hhmm After: yyddd hhmm Retain: x
LTERM: xxxxxxxx Prompt: x Rqmt List: x Rqmts Not Used: x

PROGRAM: SM22 MSG-INDX: nn -- DB.10 -- yy.ddd / hh:mm:ss

MESSAGE: ENTER FUNCTION, TRANSFER OR ENTER A COMMAND ON THE TOP LINE

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following:
Add
Adds a job to the database when the same-named job does not currently exist.
DD
Deletes a job and its associated data from the database (documentation,
schedules, and so forth).
Delete
Deletes a job and its associated data from the database (documentation,
schedules, and so forth).

Chapter 2: Setting Up and Maintaining Jobs 51

DB.10 - XP Job Definition Panel

DELPRRN
Deletes the parameter and associated data from the prior run queue for this
job.
Format
Clears the panel of all input data.
List
Lists a job and job-related information. In batch, a formatted panel is not listed;
only a found or not found message is returned.
Purge
Same as delete, but also deletes job trigger definitions that trigger the job
being deleted and job requirement definitions that require the job being
deleted. This group includes all virtual resources that are connected to the job.
Update
Updates database information about a job.
Batch keyword: Positional parameter
Note: A default interpretation can be set for the DELETE function in the CA WA CA 7
Edition initialization file. For more information, see the OPTIONS statement in the
chapter "Initialization File" of the Systems Programming Guide.
Job
Defines the job name on which to perform the indicated function.
Limits: 1 to 8 alphanumeric characters. The job name format of UCC7Rxxx (where
xxx is any three characters) is reserved for use with Workload Balancing. This
imposes a restriction that no other user-defined job can begin with UCC7R as the
first five characters.
Batch keyword: Positional parameter
JobL
(Optional) Defines the long job name on which to perform the indicated function.
Note: For more information, see Long Job Name Rules (see page 29).
Limits: 1 to 64 alphanumeric characters, case sensitive
Batch keyword: JOBL

52 Database Maintenance Guide

 DB.10 - XP Job Definition Panel

System
(Optional) Defines the user-defined application system name of which this job is a
part. This field is transmitted to the cross-system platform as the JOBSET name. If
this field is not completed, the JOBSET field is the value of the CA WA CA 7 Edition
XPS monitor name.
Limits: 1 to 8 alphanumeric characters. This field cannot contain a comma.
Batch keyword: SYSTEM
JOBNET
(Optional) Defines the name of a job network of which this job is a part.
Note: This field is not transmitted to the cross-system platform but can be used
within CA WA CA 7 Edition internally.
Limits: 1 to 8 alphanumeric characters. This field cannot contain a comma.
Batch keyword: JOBNET
Owner
(Optional) Defines the ID identifying ownership of this job. This field can have
multiple meanings, depending on the CA WA CA 7 Edition startup options specified
on the XPDEF statement. This field can be used to identify the "User ID" resource
record (entered through the XPSWD,OWNER= command) in which to find the user
ID and password for the job being executed on the alternate platform. If the XPDEF
definition permits this field to code the user ID, the user ID under which the job
executes is obtained from here, and a password is not associated with the job on
the alternate platform. If this field is left blank and the XPDEF definition allows
USER, the security information must be specified in the parameter library. If
PSWDLOC specifies NODE, the user ID and password are obtained from the Node
Table information. If no user ID is found for the AJB, the job is submitted to the
platform without any user information (the platform may reject the job execution if
security is set that way).
Limits: 1 to 8 alphanumeric characters. Although this field supports up to 8
characters, some external security packages only accept up to 7 characters. This
field must not exceed any such limit that exists.
Batch keyword: OWNER

Chapter 2: Setting Up and Maintaining Jobs 53

DB.10 - XP Job Definition Panel

UID
(Optional) Defines the CA WA CA 7 Edition user security identification.
Default: 0 (No internal security identification)
Limits: 1 to 3 numeric characters from 0 through 999
Batch keyword: USERID
XP Node
Defines the CAICCI node to which the execution of this job is targeted. This field
should state the primary node. If this node is unavailable and the node definition
has alternate nodes defined, the execution of this job can be directed to an
alternate node.
Limits: 1 to 44 alphanumeric characters, although current z/OS CAICCI restricts this
name to eight characters.
Batch keyword: NODE
XP EXEC
Defines the executable (file, command) to execute at the targeted cross-platform
node. If the targeted platform is a mainframe scheduling system such as CA WA CA
7 Edition, this value indicates the job name to execute on that platform. If the
targeted platform is CA Workload Automation AE system, this value indicates a job
that is defined in the CA Workload Automation AE system. If this field begins and
ends in single quote (') marks, these marks are removed before being passed in the
transmission data. Otherwise, the field is passed to the target system as-is and in its
entirety. This value includes any embedded blanks and quotation marks.
Limits: Three 64-byte lines and one 52-byte line, comprising 244 alphanumeric
characters, and file delimiters of forward slash (/) and backward slash (\) signs.
Batch keyword: EX1, EX2, EX3, EX4
Note: Some EBCDIC characters do not translate to ASCII. Thus, define the file name
carefully so that translation can occur correctly between EBCDIC and ASCII.
Enclose the value of the batch parameter in parentheses if this field contains
commas or trailing spaces and you are using the batch method to add or update the
XP EXEC or XP PARM fields.

54 Database Maintenance Guide

 DB.10 - XP Job Definition Panel

XP PARM
(Optional) Defines up to 128 bytes of parameter data to pass to the file or
command being executed on the alternate platform. This data is supplied as PARM1
to the data being transmitted to the alternate platform. If this field begins and ends
in single quote (') marks, these marks are removed before being passed in the
transmission data. This value may be overridden if the PARMLIB/MEMBER field
PARM1 is coded.
Limits: Two 64-byte lines, comprising up to 128 EBCDIC characters.
Batch keyword: XP1 and XP2
Note: Some EBCDIC characters do not translate to ASCII, and thus the file name
must be carefully defined so that translation can occur correctly between EBCDIC
and ASCII.
Optional PARMLIB
(Optional) Defines extra, optional indexed, or symbolic (PDS) library from where
execution data to be associated with this job may be found. This information is
typically PARM1 through PARM64 keywords but can vary based on CA WA CA 7
Edition system configuration options. If the PARM1 field is found within this file, it
overrides the data specified in the XP PARM field listed on the panel.
Limits: 1 to 16 alphanumeric characters. If this field starts with a numeric value, the
value is treated as a JCL Index value (0 - 253 or 256 - 999), and the associated
numbered JCL library, as defined in the initialization file JCL statement, is used. If
the first character is not numeric, the field must start with an ampersand (&) and
must denote the library variable as defined using a /JCL command.
Batch keyword: PRMLIB
Note: Specifying data in the PARMLIB/MEMBER fields is in addition to anything
specified in the XPPARM field. If XPPARM is coded, and if the PARMLIB/Member
contains a PARM1 statement, the PARMLIB specification overrides the XP PARM
field. Thus, if both XPPARM and PARMLIB PARM1 fields contain data, the data
obtained from the PARMLIB/MEMBER is used in the data transmitted to the target
node.

Chapter 2: Setting Up and Maintaining Jobs 55

DB.10 - XP Job Definition Panel

Member
(Optional) Indicates the PDS member name of the preceding library where the
parameters for this job reside.
Default: Same as the Job field
Limits: 1 to 8 alphanumeric characters, beginning with an alphabetic character
Batch keyword: MEMBER
Use-Ovrd-Lib
(Optional) Specifies whether to retrieve the JCL from the JCL Override library
(JCLID=254) for the next run only (Y or N). This field is automatically set back to N
the next time the job comes into the request queue.
Default: N
Batch keyword: JOVRDLIB
EXEC
(Optional) Indicates whether to execute this job.
Y
Specifies to execute the job. This is the default.
N
Specifies that the job does not run but shows a normal completion as if it did
run.
Note: Consider the following items:
■ Since nonexecutable jobs do not get executed, no data sets are created. This
means that any jobs waiting for data set requirement that may have been
created for the job execution are not created and thus jobs may wait on these
data set requirements.
■ VRM definitions are ignored for the nonexecutable jobs.
■ Critical Path Management flows cannot be started with nonexecutable jobs and
thus the critical path may not be monitored.
■ ARF recovery is not invoked for nonexecutable jobs.
Batch keyword: EXEC

56 Database Maintenance Guide

 DB.10 - XP Job Definition Panel

SUTYPE
(Optional) Specifies the type of "switch user" command to execute at the UNIX
target node.
Y
Executes an "SU -" causing the environment set up to include execution of the
".PROFILE" for the target user. This is the default.
N
Executes an "SU" command without the profile option.
Batch keyword: SUTYPE
Cond-Code
(Optional) Used with RO (relational operator), defines the job-level condition codes
used to determine whether a job executes successfully. All condition codes
returned from an XPJOB job are treated as positive values. Any negative value
returned is converted to an absolute (positive) value.
Default: 0
Limits: 1 to 4 numeric characters from 0 to 9999
Batch keyword: CONDCODE
RO
(Optional) Specifies the relational operator of the condition code (COND-CODE).
The following are the possible values:
0
Performs no condition test. This value is the default.
EQ
Specifies equal to.
LT
Specifies less than.
GT
Specifies greater than.
GE
Specifies greater than or equal to.
LE
Specifies less than or equal to.

Chapter 2: Setting Up and Maintaining Jobs 57

DB.10 - XP Job Definition Panel

NE
Specifies not equal to.
IG
Performs no evaluation of the job. CA WA CA 7 Edition always assumes that the
job completes successfully, regardless of condition codes, abend codes, or
runtime JCL errors.
Batch keyword: RELOPR
The highest condition code that this job generates is tested by this pair of
parameters. For example, if COND-CODE is set at 8 and RO is set at LT, the job is
marked as completing abnormally if 8 is less than the job's condition code.
Note: This test is for internal use by CA WA CA 7 Edition only. It simply tells CA WA
CA 7 Edition what action to take after the job completes.
DRClass
(Optional) Defines the job's disaster recovery class. This field has no impact on
processing during normal execution. When running in disaster recovery mode, the
disaster recovery class is used to determine whether the job should execute.
Note: For more information about disaster recovery mode, see the Systems
Programming Guide.
Limits: 1 to 8 alphanumeric characters. Values must start with a letter, #, or $ (not
@) and can include letters, #, $, @, and numbers. Disaster recovery classes cannot
contain embedded blanks.
Batch keyword: DRCLASS
Hold
(Optional) Specifies whether to put this job in a hold status when it enters the
request queue.
N
Does not put this job in a hold status. This is the default.
Y
Puts this job in a hold status.
Batch keyword: HOLD

58 Database Maintenance Guide

 DB.10 - XP Job Definition Panel

Verify
(Optional) Specifies whether this job requires any presubmission manual
verification.
Note: This function is similar to VERIFY command.
N
Specifies that this job does not require presubmission manual verification. N is
the default.
Y
Specifies that this job requires presubmission manual verification.
Batch keyword: VERIFY
Satisfaction Lead Time
(Optional) Defines the number of hours to consider when satisfying job-dependent
requirements.
The following values are possible:
0
Indicates no lead time is considered when satisfying this job's requirements.
This value is the default.
99
Indicates that the requirement is never considered as already satisfied when
the job enters the queues. Each predecessor job must complete typically while
this job is in the request queue.
nn
Indicates that each predecessor job must have run within the last nn hours
after the last run of this job.
Limits: 1 - 98
Batch keyword: JOBLDTM
Note: For XPJOB jobs, JOB and DSN Satisfaction Lead Time are treated as one.

Chapter 2: Setting Up and Maintaining Jobs 59

DB.10 - XP Job Definition Panel

ARFSET
(Optional) Defines the collection of ARF definitions that apply to this job.
Remember that ARF recovery is not invoked for nonexecutable jobs.
Limits: 1 to 8 alphanumeric characters. The specified ARFSET must be defined in the
ARF database.
Batch keyword: ARFSET
Clock Time
(Optional) CA WA CA 7 Edition maintains certain feedback data in its database,
including a weighted average elapsed execution time. If the database is updated
with a clock time of 0000, then in addition to this clock time field the counters for
the number of runs, number of times late, and number of restarts is also set to
0000. One use of this value is deadline prompting. If 2359 is specified, deadline
prompt time is not adjusted. The deadline time remains due-out time minus lead
time.
Note: The clock time average is not updated if the job is not successful in its
execution. The weighted average is the value in the database times five, plus the
value from the current execution, divided by six. This tends to keep the current run
from possibly skewing the value.
Default: 0000
Limits: 4 numeric characters specified as hhmm, where hh can be 00 through 23,
and mm can be 00 through 59
Batch keyword: ELAPTM

60 Database Maintenance Guide

 DB.10 - XP Job Definition Panel

WLBClass
(Optional) Specifies the CA WA CA 7 Edition WLB job class. If CLASS is not specified,
a WLB class of A is automatically assigned. This value does not have to match the
JOB statement CLASS value.
The CLASS specified here does not apply when the job enters the queue as a result
of a RUN(H) command. Class 9 is assigned by default. To override class 9, use the
RUNCLASS keyword on the OPTIONS statement in the initialization file.
The CLASS specified here does not apply when the job enters the queue as a result
of a LOAD(H) command. Class 8 is assigned by default. To override class 8, use the
LOADCLASS keyword on the OPTIONS statement in the initialization file.
Default: A
Limits: 1 alphanumeric character
Batch keyword: CLASS
WLBPRTY
(Optional) Defines the CA WA CA 7 Edition WLB job priority. A value of 255 indicates
an express priority used to bypass WLB priority scheduling criteria. If using WLB, any
job without a specified priority is automatically assigned a priority of 100 unless the
default is changed.
Default: 100 if WLB is used or 0 if WLB is not used
Limits: 1 to 3 numeric characters from 0 to 255
Batch keyword: PRTY
Trace
(Optional) Indicates whether to trace the activity associated with this job as it
moves through the CA WA CA 7 Edition queues. The possible values include:
N
Do not activate tracing for this job. N is the default.
Y
Issue WTOs as the job enters into the submission process and retain up to 256
characters of the data sent for inclusion in a log record.
Batch keyword: XPTRACE

Chapter 2: Setting Up and Maintaining Jobs 61

DB.10 - XP Job Definition Panel

Don't Schedule Before

(Optional) Specifies that this job is not to be scheduled before this date and time.
This keyword is especially helpful for timing the start of new jobs.
Panel input is:
BEFORE: yyddd hhmm
Batch input is:
BDATE=yyddd,BTIME=hhmm
Default: All zeros
Limits: Julian date specified as yyddd and time specified as hhmm
Batch keyword: BDATE and BTIME
After
(Optional) Specifies that this job is not to be scheduled after this date and time. This
keyword is especially helpful for timing the permanent discontinuation of a job.
Panel input is:
AFTER: yyddd hhmm
Batch input is:
ADATE=yyddd,ATIME=hhmm
Default: 99999 0000
Limits: Julian date specified as yyddd and time specified as hhmm
Batch keyword: ADATE and ATIME
Note: If BDATE and BTIME values are equal to ADATE and ATIME, the job is not
scheduled and does not appear on forecasts. If BDATE and BTIME values are greater
than ADATE and ATIME, the job is not available for scheduling during the inclusive
times only. Thus, if BDATE=09031 and BTIME=2359 and ADATE=09001 and
ATIME=0000, the job does not schedule during the time from Jan. 1, 2009 through
Jan. 31, 2009, but does schedule at all other times. CA WA CA 7 Edition uses current
date and time for comparisons.
Retain
(Optional) Specifies whether to retain the job data sent to the target node in the
trailer queue after a successful execution.
N
Do not send the job data. N is the default.
Y
Send the job data.
Default: N
Batch keyword: RETJCL

62 Database Maintenance Guide

 DB.10 - XP Job Definition Panel

LTERM
(Optional) Defines a logical terminal name to receive messages about this job.
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.
Default: MASTER
Limits: 1 to 8 alphanumeric characters
Batch keyword: LTERM
Note: For a CPU job, you can specify LTERM on the JOB (DB.1) Definition panel or in
the initialization file JCL statement from which the JCL is pulled. For XPJOBs, the
only place to define the terminal where messages are sent is on the XPJOB (DB.10)
panel.
Prompt
(Optional) Specifies whether to issue prompt messages when this job is late.
Y
Issue the prompt messages. Y is the default.
N
Do not issue the prompt messages.
Batch keyword: PROMPT
Note: If LATEPROMPT=LATE is specified on the OPTIONS statement of the
initialization file, setting this value to no (N) prevents the job from ever having a
status of LATE on an LQ or LRLOG display. Jobs that are defined with a value of yes
(Y) are processed the same regardless of the LATEPROMPT setting.
Rqmt list
(Optional) Specifies whether to list the preexecution requirements for this job when
it enters the request queue.
Y
List the requirements. Y is the default.
N
Do not list the requirements.
Batch keyword: RQLST

Chapter 2: Setting Up and Maintaining Jobs 63

DB.11 - Agent Job Definition Panel

Rqmts Not Used

(Optional) Specifies whether to issue error messages for job requirements not used.
Y
Issue error messages. Y is the default.
N
Do not issue error messages.
Batch keyword: RQMSG

More information:

Usage Notes for DB.1, DB.10, and DB.11 (see page 33)

Example: Batch Input

This batch input example adds XPJOB job CA07XP01, specifying the system name, node,
executable (EX1) and PARM01 (XP1):

XPJOB
ADD,CA07XP01,SYSTEM=TESTXPJB,
NODE=TESTPLN,
EX1=(C:\NSM\BIN\CAU9TEST),
XP1=(T=60,F=12)

DB.11 - Agent Job Definition Panel

The DB.11 - Agent Job Definition panel lets you enter or review data that is related to
agent jobs.

To display the panel, enter:

■ XPSMENU as a top line command or A as the FUNCTION on the DB Menu panel. This
method leads to another menu for job type selection.
■ DB.11 or AGJOB as the FUNCTION on any other menu or formatted input panel.
■ DB.11 or AGJOB as a top line command.

64 Database Maintenance Guide

 DB.11 - Agent Job Definition Panel

To exit the panel:

■ Press PF3. If you entered the agent job command (excluding menu commands), you
are returned to the DBM Menu panel except with the TSO-ISPF interface when the
PF3 key is assigned to another function. If you entered the DB panel, you are
returned to the menu from which you can directly invoke the agent.
■ Move the cursor to the top line of the panel and enter a top line command for
another function.

When you enter a DB panel identifier for a valid agent job type or you traverse through
the menus, the CA-7 Agent Job Definition panel is displayed with the Agent Job Type
field pre-filled. If you enter DB.11 or AGJOB, the Agent Job Type field is not pre-filled.

If you use the Format command to clear the screen and want to add a new agent job
definition, you must supply the Agent Job Type.

Note: You can change the agent job type. Be careful that you do not change it to a value
that is invalid for the type of job you want to execute.

------------------------- CA-7 Agent Job Definition ------------------------

Function: xxxxxxxx (Add, DD, Delete, Format, List, Purge, Update)
Job: xxxxxxxx
JobL: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
System: xxxxxxxx JOBNET: xxxxxxxx Owner: xxxxxxxx UID: xxx

Agent Job Type: xxxxxxxxxxxxxxxx

Agent: xxxxxxxxxxxxxxxx
User: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Parmlib: xxxxxxxxxxxxxxxx Member: xxxxxxxx Use-Ovrd-Lib: x

EXEC: x Hold: x Verify: x

DRClass: xxxxxxxx ARFSET: xxxxxxxx Satisfaction Lead Time: xx
WLBClass: x WLBPRTY: xxx Clock Time: xxxx
Don't Schedule Before: xxxxx xxxx After: xxxxx xxxx
LTERM: xxxxxxxx Prompt: x Rqmt List: x Rqmts Not Used: x

PROGRAM: SM23 MSG-INDX: 00 -- DB.11 -- yy.ddd / hh:mm:ss

MESSAGE: ENTER FUNCTION, TRANSFER OR ENTER A COMMAND ON THE TOP LINE

Chapter 2: Setting Up and Maintaining Jobs 65

DB.11 - Agent Job Definition Panel

This panel contains the following fields:

Function
Specifies the function to perform. Value must be the name of some other panel or
one of the following values:
Add
Adds a job to the database wheh the same-named job does not currently exist.
DD
Deletes a job and its associated data from the database (documentation,
schedules, and so forth).
Delete
Deletes a job and its associated data from the database (documentation,
schedules, and so forth).
DELPRRN
Deletes the parameter and associated data from the prior run queue for this
job.
Format
Clears the panel of all input data.
List
Lists a job and job-related information. In batch, a formatted panel is not listed;
only a found or not found message is returned.
Purge
Same as delete, but also deletes job trigger definitions that trigger the job
being deleted and job requirement definitions that require the job being
deleted. This function includes all virtual resources that are connected to the
job.
Update
Updates database information about a job.
Batch keyword: Positional parameter
Note: A default interpretation can be set for the DELETE function in the CA WA CA 7
Edition initialization file. For more information, see the OPTIONS statement in the
chapter "Initialization File" of the Systems Programming Guide.

66 Database Maintenance Guide

 DB.11 - Agent Job Definition Panel

Job
Defines the job name on which to perform the indicated function.
Limits: 1 to 8 alphanumeric characters. The job name format of UCC7Rxxx (where
xxx is any three characters) is reserved for use with Workload Balancing. This value
imposes a restriction that no other user-defined job can begin with UCC7R as the
first five characters.
Batch keyword: Positional parameter
JobL
(Optional) Defines the long job name on which to perform the indicated function.
Note: For more information, see Long Job Name Rules (see page 29).
Limits: 1 to 64 alphanumeric characters, case sensitive
Batch keyword: JOBL
System
(Optional) Defines the user-defined application system name of which this job is a
part. The internal agent job ID uses this field. If the System Name is blank, the word
"SYSTEM" is used as part of the internal agent job ID.
Limits: 1 to 8 alphanumeric characters. This field cannot contain a comma.
Batch keyword: SYSTEM
JOBNET
(Optional) Defines the name of a job network of which this job is a part.
Note: This field is not transmitted to the cross-system platform but can be used
within CA WA CA 7 Edition internally.
Limits: 1 to 8 alphanumeric characters. This field cannot contain a comma.
Batch keyword: JOBNET
Owner
(Optional) Defines the ID identifying ownership of this job. Depending on the CA
WA CA 7 Edition startup options taken and the external security product being
used, CA WA CA 7 Edition can offer this value to the external security package at job
submission time as the authority for this job to execute.
Limits: 1 to 8 alphanumeric characters. Although this field supports up to 8
characters, some external security packages only accept up to 7 characters. This
field must not exceed any such limit that exists.
Batch keyword: OWNER

Chapter 2: Setting Up and Maintaining Jobs 67

DB.11 - Agent Job Definition Panel

UID
(Optional) Defines the CA WA CA 7 Edition user security identification.
Default: 0 (No internal security identification)
Limits: 1 to 3 numeric characters from 0 through 999
Batch keyword: USERID
Agent Job Type
Defines the type of agent job. The valid values are listed in the Agent Command/Job
Type table that is found in the Interface Reference Guide.
The field has no default. If you use the menus (starting with DB.A or XPSMENU), the
Agent Job Type is pre-filled based on your menu selection.
Batch keyword: AGJOBTYP
Agent
Identifies the explicit distributed platform where the job is to run.
Limits: 1 to 16 alphanumeric characters. The value must be defined to CA WA CA 7
Edition using the IASAGENT DD statement.
Batch keyword: AGENT
User
(Optional) Defines the user ID that is passed to the distributed platform where the
job is to run.
Limits: Two 64-byte lines comprising 128 alphanumeric characters.
Batch keyword: AG1, AG2

68 Database Maintenance Guide

 DB.11 - Agent Job Definition Panel

Parmlib
Defines an indexed or symbolic (PDS) library from where execution data that is
associated with this job can be found. This information is typically keyword
parameters and values that are required by the particular agent job type.
Limits: 1 to 16 alphanumeric characters. If this field starts with a numeric value, the
value is treated as a JCL Index value (0 - 253 or 256 - 999), and the associated
numbered JCL library, as defined in the initialization file JCL statement, is used. If
the first character is not numeric, the field must start with an ampersand (&) and
must denote the library variable as defined using a /JCL command.
Batch keyword: PRMLIB
Member
(Optional) Indicates the PDS member name of the preceding library where the
parameters for this job reside.
Default: Same as the Job field
Limits: 1 to 8 alphanumeric characters, beginning with an alphabetic character
Batch keyword: MEMBER
Use-Ovrd-Lib
(Optional) Specifies whether to retrieve the JCL from the JCL Override library
(JCLID=254) for the next run only (Y or N). This field is automatically set back to N
the next time the job comes into the request queue.
Default: N
Batch keyword: JOVRDLIB
EXEC
(Optional) Indicates whether to execute this job.
Y
Specifies to execute the job. This is the default.
N
Specifies that the job does not run but shows a normal completion as if it did
run.

Chapter 2: Setting Up and Maintaining Jobs 69

DB.11 - Agent Job Definition Panel

Note: Consider the following items:

■ Since nonexecutable jobs do not get executed, no data sets are created. This
means that any jobs waiting for data set requirement that may have been
created for the job execution are not created and thus jobs may wait on these
data set requirements.
■ The VRM definitions are ignored for the nonexecutable jobs.
■ The Critical Path Management flows cannot be started with nonexecutable jobs
and thus the critical path cannot be monitored.
■ The ARF recovery is not invoked for nonexecutable jobs.
Batch keyword: EXEC
Hold
(Optional) Specifies whether to put this job in a hold status when it enters the
request queue.
N
Does not put this job in a hold status. N is the default.
Y
Puts this job in a hold status.
Batch keyword: HOLD
Verify
(Optional) Specifies whether this job requires any presubmission manual
verification.
Note: This function is similar to VERIFY command.
N
Specifies that this job does not require presubmission manual verification. N is
the default.
Y
Specifies that this job requires presubmission manual verification.
Batch keyword: VERIFY

70 Database Maintenance Guide

 DB.11 - Agent Job Definition Panel

DRClass
(Optional) Defines the job's disaster recovery class. This field has no impact on
processing during normal execution. When running in disaster recovery mode, the
disaster recovery class is used to determine whether the job should execute.
Note: For more information about disaster recovery mode, see the Systems
Programming Guide.
Limits: 1 to 8 alphanumeric characters. Values must start with a letter, #, or $ (not
@) and can include letters, #, $, @, and numbers. Disaster recovery classes cannot
contain embedded blanks.
Batch keyword: DRCLASS
ARFSET
(Optional) Defines the collection of ARF definitions that apply to this job.
Remember that ARF recovery is not invoked for nonexecutable jobs.
Limits: 1 to 8 alphanumeric characters. The specified ARFSET must be defined in the
ARF database.
Batch keyword: ARFSET
Satisfaction Lead Time
(Optional) Defines the number of hours to consider when satisfying job-dependent
requirements.
The following values are the possible values:
0
Indicates that no lead time is considered when satisfying this job's
requirements. This value is the default.
99
Indicates that the requirement is never considered as already satisfied when
the job enters the queues. Each predecessor job must complete typically while
this job is in the request queue.
nn
Indicates that each predecessor job must have run within the last nn hours
after the last run of this job.
Limits: 1 to 98
Batch keyword: JOBLDTM
Note: For agent jobs, JOB and DSN Satisfaction Lead Time are treated as one.

Chapter 2: Setting Up and Maintaining Jobs 71

DB.11 - Agent Job Definition Panel

WLBClass
(Optional) Specifies the CA WA CA 7 Edition WLB job class. If CLASS is not specified,
a WLB class of A is automatically assigned. This value does not have to match the
JOB statement CLASS value.
The CLASS specified here does not apply when the job enters the queue as a result
of a RUN(H) command. Class 9 is assigned by default. To override class 9, use the
RUNCLASS keyword on the OPTIONS statement in the initialization file.
The CLASS specified here does not apply when the job enters the queue as a result
of a LOAD(H) command. Class 8 is assigned by default. To override class 8, use the
LOADCLASS keyword on the OPTIONS statement in the initialization file.
Default: A
Limits: 1 alphanumeric character
Batch keyword: CLASS
WLBPRTY
(Optional) Defines the CA WA CA 7 Edition WLB job priority. A value of 255 indicates
an express priority that is used to bypass WLB priority scheduling criteria. If using
WLB, any job without a specified priority is automatically assigned a priority of 100
unless the default is changed.
Default: 100 if WLB is used or 0 if WLB is not used.
Limits: 1 to 3 numeric characters from 0 to 255
Batch keyword: PRTY
Clock Time
(Optional) CA WA CA 7 Edition maintains certain feedback data in its database,
including a weighted average elapsed execution time. If the database is updated
with a clock time of 0000, then in addition to this clock time field the counters for
the number of runs, number of times late, and number of restarts is also set to
0000. One use of this value is deadline prompting. If 2359 is specified, deadline
prompt time is not adjusted. The deadline time remains due-out time minus lead
time.
Note: The clock time average is not updated when the job is unsuccessful in its
execution. The weighted average is the value in the database times five, plus the
value from the current execution, divided by six. This method tends to keep the
current run from possibly skewing the value.
Default: 0000
Limits: 4 numeric characters specified as hhmm, where hh can be 00 through 23,
and mm can be 00 through 59
Batch keyword: ELAPTM

72 Database Maintenance Guide

 DB.11 - Agent Job Definition Panel

Don't Schedule Before

(Optional) Specifies not to schedule this job before this date and time. This keyword
is especially helpful for timing the start of new jobs.
Panel input is:
BEFORE: yyddd hhmm
Batch input is:
BDATE=yyddd,BTIME=hhmm
Default: All zeros
Limits: Julian date specified as yyddd and time specified as hhmm
Batch keyword: BDATE and BTIME
After
(Optional) Specifies not to schedule this job after this date and time. This keyword is
especially helpful for timing the permanent discontinuation of a job.
Panel input is:
AFTER: yyddd hhmm
Batch input is:
ADATE=yyddd,ATIME=hhmm
Default: 99999 0000
Limits: Julian date specified as yyddd and time specified as hhmm
Batch keyword: ADATE and ATIME
Note: If the BDATE and BTIME values are equal to ADATE and ATIME, the job is not
scheduled and does not appear on forecasts. If the BDATE and BTIME values are
greater than ADATE and ATIME, the job is not available for scheduling during the
inclusive times only. Thus, if BDATE=13031 and BTIME=2359 and ADATE=13001 and
ATIME=0000, the job does not schedule during the time from Jan. 1, 2013 through
Jan. 31, 2013, but the job does schedule at all other times. CA WA CA 7 Edition uses
current date and time for comparisons.

Chapter 2: Setting Up and Maintaining Jobs 73

DB.11 - Agent Job Definition Panel

LTERM
(Optional) Defines a logical terminal name to receive messages about this job.
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.
Default: MASTER
Limits: 1 to 8 alphanumeric characters
Batch keyword: LTERM
Note: Although a CPU job can specify LTERM either on the JOB Definition (DB.1)
panel or in the initialization file JCL statement from which the JCL is pulled, for
agent jobs, the only place to define the terminal to which messages are sent is on
the AGJOB (DB.11) panel.
Prompt
(Optional) Specifies whether to issue prompt messages if this job is late.
Y
Issues the prompt messages. Y is the default.
N
Does not issue the prompt messages.
Batch keyword: PROMPT
Note: If LATEPROMPT=LATE is specified on the OPTIONS statement of the CA WA
CA 7 Edition initialization file, setting this value to no (N) prevents the job from ever
having a status of LATE on an LQ or LRLOG display. Jobs that are defined with a
value of yes (Y) are processed the same regardless of the LATEPROMPT setting.
Rqmt List
(Optional) Specifies whether to list the pre-execution requirements for this job
when it enters the request queue.
Y
Lists the requirements. Y is the default.
N
Does not list the requirements.
Batch keyword: RQLST

74 Database Maintenance Guide

 DB.11 - Agent Job Definition Panel

Rqmts Not Used

(Optional) Specifies whether to issue error messages for job requirements not used.
Y
Issues error messages. Y is the default.
N
Does not issue error messages.
Batch keyword: RQMSG

More information:

Usage Notes for DB.1, DB.10, and DB.11 (see page 33)

Example: Batch Input

This batch input example adds UNIX_JOB CA07UNX1 specifying the system name, agent
job type, agent name, user ID, and PARMLIB.

AGJOB
ADD,CA07UNX1,SYSTEM=TESTAGJB,
AGJOBTYP=UNIX_JOB,
AGENT=UNIX_NY,
AG1=userid1,
PRMLIB=200

Chapter 2: Setting Up and Maintaining Jobs 75

Chapter 3: Scheduling Work
This section identifies the panels and commands used to schedule work in CA WA CA 7
Edition.

This section contains the following topics:

Work Scheduling (see page 77)
Schedule Definition (see page 85)

Work Scheduling
CA WA CA 7 Edition uses both date/time-driven and event-driven facilities to cause work
to be scheduled and initiated. To CA WA CA 7 Edition, work is defined as jobs,
preprocessing and postprocessing workstation networks, or both. Event-driven
scheduling, known as trigger scheduling, is a far more efficient technique than
date/time oriented schedules.

For jobs and preprocessing networks, date/time-driven schedules are generated

through definition of base calendars and definition of schedules relative to base
calendars. Once defined, work is automatically scheduled based on defined schedules
and current date and time values within the CA WA CA 7 Edition system. For
postprocessing networks, output workstations are scheduled based on the scheduling of
the job to which the networks are connected.

Event-driven scheduling causes jobs to be scheduled or initiated based on completion of

a previous activity or event. Event mechanisms are the creation of required data sets,
completion of predecessor jobs, or completion of a preprocessing network.

Time-driven and event-driven facilities can be used in combination when scheduling and
initiating work. For example, a job can have a timed schedule for processing but can also
have dependencies on data sets created by another job. When combined, time and
event requirements must be satisfied before work is initiated.

The user should be aware that the schedule ID offers a powerful scheduling tool.
Requirements, networks, JCL overrides, job triggers, and so on, can all be varied through
the use of different schedule IDs. For example, if a given job is to run on Monday
through Friday but the requirements vary on Fridays, this same job could have a
different schedule ID defined for its Friday run.

Multiple schedule options can be chosen for a single schedule ID (for example, daily and
monthly). However, a job that is scheduled automatically on a defined date/time basis is
not scheduled more than once per day for a given schedule ID.

Chapter 3: Scheduling Work 77

Work Scheduling

More information:

Event Scheduling with Triggers (see page 82)

Date and Time Scheduling

The schedule scan function performs date/time-driven scheduling based on initialization
file parameters and database definitions. By combining base calendar and schedule
definitions through a resolution process, CA WA CA 7 Edition stores information about
date/time related work in its database.

Base Calendars

Base calendars define available processing days for the installation. Any number of base
calendars can be defined. However, it may be possible to satisfy installation
requirements with only one or two calendars.

Each calendar defines a single year with a starting and year-ending boundary that can be
crossed only in the first or twelfth month. A given calendar can represent schedule
months in either standard or user-defined format (for example, accounting, fiscal, and
so on).

Either batch or online facilities can generate base calendars. To use the online facility
(DB.2.8), a CA WA CA 7 Edition calendar PDS must be allocated and identified to CA WA
CA 7 Edition. Processing of base calendars for resolution of schedules is the same
regardless of whether they were generated using the batch or online facilities.

Note: For information about enabling online calendar maintenance, see the Systems
Programming Guide.

The CA WA CA 7 Edition CALENDAR macro can generate calendars. Macro keywords are
used for calendar definition, and the macro is assembled and link edited using standard
procedures. Base calendars are link edited to the CA WA CA 7 Edition CAL2LOAD or a
specified calendar library, and are stored in the form of bit masks that represent
available and unavailable processing days for the year.

Timing for generation of base calendars is flexible. The only requirement is that a
particular calendar exist before resolution of work schedules related to the calendar is
attempted. Base calendars must be regenerated whenever available processing days
change and before the beginning of each year. Generally, next year's base calendars
should be generated by July 1 of the current year. New base calendars can be generated
at any time without impacting current processing schedules. Schedule resolution,
described later, is used to change the processing schedules, for jobs or networks, with a
new year or changed base calendars.

78 Database Maintenance Guide

 Work Scheduling

PRINT Command

Use the PRINT command to produce a month-by-month listing of indicated base

calendars. PRINT produces output that reflects the beginning and ending days of each
month, holidays, or any other nonprocessing days that were defined when the calendar
was produced.

Note: For more information about the PRINT command, see the Command Reference
Guide.

Perpetual Calendars

Using perpetual calendars can automate the generation of base calendars. When the
criteria for building a calendar are defined in the Perpetual Calendar DSN (PCALDSN),
the corresponding base calendar (SCALyyxx) is generated and used on the first reference
of the calendar if the calendar does not exist. The reference to the calendar could be a
PRINT, RESOLV, CALMOD, or any other command or process that needs a calendar.

Perpetual calendars, defined with the member name PCALYYxx, describe scheduling and
nonscheduling days in English-like terms. These members can be used each year,
because the command that references a calendar builds the SCALyyxx member if it does
not already exist. This permits the same set of criteria to be used each time. As a result,
perpetual calendars are a tool for jobs that use the same "relative" processing days year
after year. For example, a job that executes every Monday, Wednesday, and Friday can
reference a perpetual calendar PCALYY3W that has the following statements:

Set all days nonscheduled

Set Mondays Wednesdays Fridays schedule

When a command such as PRINT is used, CA WA CA 7 Edition generates the base

calendar SCALyy3W (as an example) that sets the processing days for each Monday,
Wednesday, and Friday of each week. This eliminates the need to set up each year the
corresponding SCALyy3W.

Note: For more information about perpetual calendars see the Systems Programming
Guide.

Chapter 3: Scheduling Work 79

Work Scheduling

Schedule Resolution

Once calendars and schedules are defined, schedules are resolved against calendars to
ensure compatibility and create the processing schedule. This is accomplished through
the RESOLV facility, which is available as both a top line command and a function on the
DB.2 panels. The result of this resolution is the schedule used by CA WA CA 7 Edition to
schedule preprocessing work and jobs. The following figure illustrates this function. The
figure demonstrates the path for a base calendar generated through the batch facility.
Calendars generated through the online base calendar maintenance facility (DB.2.8)
take a different path leading up to the resolution phase but are treated the same as
batch calendars in the actual resolution of schedules.

RESOLV Command

Use the top line RESOLV command to create or modify processing schedules for jobs or
workstation networks that are to be scheduled on a date/time basis. Work that is
scheduled by a trigger or on-request work that is demanded or run has no direct
relationship to a base calendar and therefore does not require the use of this function.

Whenever a calendar-oriented processing schedule expires (at the end of June or the
end of the year) or the scheduling frequency is redefined for any other reason, it again
becomes necessary to resolve the schedule. The RESOLV command provides options for
resolving all or any subset of those tasks scheduled with a single command.

Note: For more information about the RESOLV command, see the Command Reference
Guide.

80 Database Maintenance Guide

 Work Scheduling

The following figure illustrates calendar and schedule creation and resolution.

Schedule Modifications
Schedule Modifications apply to both jobs and input networks and can only be made to
an already defined and resolved schedule. Such modifications are handy when a request
is made to run a scheduled job or input network on a date, time, or both that deviates
from the existing schedule.

One way to make such changes to an existing schedule is to use the Schedule
Modification DB.2.7 panel. This panel displays a SCHID in calendar format showing when
the job or network does or does not run. The schedule can be temporarily modified until
the next DB.2.7 panel or RESOLV command is used against it.

Another way to permanently alter a schedule is by using the DB.2 panel to change it and
then issuing a RESOLV command.

Chapter 3: Scheduling Work 81

Work Scheduling

Schedule Scan

Schedule scan causes scheduled work to be automatically brought into the system.
Based on time intervals specified in the SCHEDULE statement in the initialization file,
schedule scan is activated and loads work into the system that is to start within the
specified interval. After a system down condition, schedule scan normally continues
where it left off; however, under unusual conditions it may be set back to a specific time
to allow for easier recovery.

Event Scheduling with Triggers

Schedule triggers can be used as a more efficient alternative to date/time schedules.
Triggers cause jobs to be dynamically scheduled based solely on completion of an event.
The triggering event can be date/time scheduled, or it too can be automatically
triggered by even another event. Schedule triggers have no association with a calendar.
Therefore, no calendar related maintenance is ever required. Once defined, triggers are
perpetual, remaining in effect until they are either deleted or modified by the user. In
addition to relieving the user of annual calendar schedule maintenance, triggers are a
far more efficient scheduling mechanism in terms of system overhead. Three types of
triggers are available in CA WA CA 7 Edition:
■ Job
■ Network
■ Data Set

With each trigger, you can trigger multiple jobs if you want.

Job Triggers

When a predecessor job completes successfully, a trigger initiates scheduling of the

successor or dependent jobs that will be brought into the request queue. This newly
triggered job can also have a trigger definition that, upon successful completion, causes
another job to start. For ease of definition and understanding, the
predecessor/successor relationship is commonly used to control sequencing of jobs in
the production environment. Job triggers are defined with the DB.2.4 function.

Network Triggers

Input (or preprocessing) workstation networks can be used to trigger jobs that are
dependent on the completion of that network. These triggers take effect whenever the
last workstation in the network is posted as being complete. The jobs to be triggered are
defined through the DB.2.5 function.

Multiple jobs can be triggered by the completion of a single network. Output (or
postprocessing) networks cannot be used to trigger jobs.

82 Database Maintenance Guide

 Work Scheduling

Data Set Triggers

Data set output activity can also be used as a trigger. Whenever a sequential data set is
created or updated, jobs can be triggered by the completion of that activity. Scheduling
of jobs in this manner is accomplished through the DB.2.6 and DB.6 panels.

A data set cannot be used as a trigger if it is defined as PERM=YES on the DB.6 panel or
if it is output by a job that is defined as MAINT=YES.

Data set triggers are very useful if you have a job that needs to run only if a specific data
set has been created.

If the data set used as a trigger specifies YES for the DB.6 panel parameter POST AT
CLOSE TIME, the data set trigger takes effect when the data set is successfully closed
after being opened for output or update. If POST AT CLOSE TIME is NO, the trigger takes
effect on successful completion of the job in which the data set was created or updated.

The advantage of posting at close time is that successful completion of an entire job is
not necessary for data set triggering or requirement posting to take place.

Note: If you trigger a job at data set close, the trigger occurs then, even if the job that
created the data set later abends. If the abended job is then restarted and the data set
is recreated, the trigger occurs again.

On-Request Scheduling
Provisions are included in CA WA CA 7 Edition to permit on-request scheduling of work.
This is the method of scheduling jobs that do not have predefined processing cycles (or
jobs that must be forced into early execution). However, on-request scheduling, using
the RUN command, may optionally cause some of the normal scheduling activities to be
bypassed. This includes verification of requirement availability, construction of
postprocessing workstation networks, data set creation updates to the database and
triggering of other data sets or jobs.

To accomplish on-request scheduling, use the DEMAND and RUN commands for jobs or
the DMDNW and RUNNW commands for networks.

Chapter 3: Scheduling Work 83

Work Scheduling

DEMAND Command

The DEMAND command can be used in either batch or online mode. Any job can be
requested (brought into the CA WA CA 7 Edition request queue) when the following is
provided:
■ A DEMAND (or DEMANDH) command
■ Job name
■ JCL library ID (only needed if the CPU job is not already defined in the database; not
valid with cross-platform jobs)

The job is immediately brought into the CA WA CA 7 Edition request queue. If the CPU
job has never been submitted by CA WA CA 7 Edition, a LOAD step is automatically
inserted to build a database profile unless a SET=NDB parameter is used. The CPU job
then executes as it otherwise would without the LOAD step. This command is generally
used to run a job on a one-time basis.

DMDNW Command

The DMDNW command can be used in either batch or online mode. Any workstation
network in the database can be requested when the following is provided:
■ A DMDNW command
■ Network name

The network is immediately placed in a queue. If the network is defined for input, it is
placed in the preprocessing queue. If the network is defined for output, it is placed in
the postprocessing queue. When input networks are completed, job triggering and
requirement posting occur.

RUN Command

The RUN command is used to request a job without verifying the availability of input
requirements or performing the updates that normally follow successful job completion.

Use of the RUN or RUNH command causes a job to be brought into the request queue
for scheduling. If workload balancing is being used, the job runs in CA WA CA 7 Edition
class 9.

The following normal scheduling activities of CA WA CA 7 Edition are bypassed:

■ Verification of input requirement availability.
■ Construction of postprocessing workstation networks.
■ Database index entry updates for newly created output data sets.

84 Database Maintenance Guide

 Schedule Definition

■ Prior-run queue updates.

■ Scheduling of job or data set triggered jobs.
■ Requirements are not satisfied for normally scheduled jobs.
■ Updating of database "last run" value.

The following normal scheduling activities occur:

■ The appropriate LTERM is prompted if the job becomes late.
■ The appropriate LTERM is notified when the job completes.
■ The RUNLOG is updated.

RUNNW Command

The RUNNW command is used to request a workstation network similar to the DMDNW
command. However, input networks requested with the RUNNW command do not post
job requirements or schedule job triggers.

Use of the RUNNW command causes a network to be placed in a queue immediately. If

the network is defined for input, it is placed in the preprocessing queue. If the network
is defined for output, it is placed in the postprocessing queue.

Schedule Definition
Definition of work schedules is accomplished through DB.2 panels. This process involves
identifying when work is to be processed in relation to given calendars. When a
schedule is initially defined (or changed), schedule resolution with the base calendars is
used to complete the definition of the processing schedule.

DB.2 - Scheduling Menu Panel

The DB.2 - Scheduling Menu panel lets you access the scheduling definition formatted
panels.

To display the panel, enter:

■ 2 as the FUNCTION on the DB Menu panel.
■ DB.2 as the FUNCTION value on any other menu or formatted input panel.
■ DB.2 or SCHD as a top line command.

Chapter 3: Scheduling Work 85

Schedule Definition

To exit the panel:

■ Press PF3 to return to the DB Menu panel except with the TSO/ISPF interface when
PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

Select the wanted function by entering the appropriate FUNCTION value and pressing
Enter.

--------------------------- CA-7 SCHEDULING MENU ---------------------------

FUNCTION ===> xxxxxxxx

DATE/TIME SCHEDULING FOR:

1 - CPU JOB
2 - INPUT NETWORK
3 - OUTPUT NETWORK

TRIGGER SCHEDULING FOR:

4 - JOB TRIGGERING OTHER CPU JOB(S)
5 - INPUT NETWORK TRIGGERING CPU JOB(S)
6 - DATA SET TRIGGERING CPU JOB(S)

OTHER FUNCTIONS AVAILABLE:

7 - MODIFICATION TO RESOLVED SCHEDULE DATES
8 - BASE CALENDAR MAINTENANCE

PROGRAM: SM70 MSG-INDX: nn -- DB.2 -- yy.ddd / hh:mm:ss

MESSAGE:

Note: The PAGE field in the following panels marks the page number of the data output.
New input from the user causes the resetting of this number.

86 Database Maintenance Guide

 Schedule Definition

DB.2.1 - Job Scheduling Panel

Note: Although this panel and command specifically mention the CPU jobs, these
functions are also available with all cross-platform jobs (for example, XPJOBs or agent
jobs).

The DB.2.1 - Job Scheduling panel lets you define or review options that are taken for
CPU jobs with date/time schedules.

To display the panel, enter:

■ 1 as the FUNCTION on the DB.2 Menu panel.
■ 2.1 as the FUNCTION on the DB Menu panel.
■ DB.2.1 as the FUNCTION value on any other menu or formatted input panel.
■ DB.2.1 or SCHD,JOB as a top line command.

To exit the panel:

■ Press PF3 to return to the DB.2 Menu panel except with the TSO/ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

------------------------- CA-7 CPU JOB SCHEDULING --------------------------

FUNCTION: xxxxxxxx (CLEAR,DELETE,EDIT,FE,FETCH,REPL,RESOLV,SAVE)

JOB: xxxxxxxx
JOBL: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

SCAL: xx (DEFAULT SCAL ID FOR ADDS)

SCHID-COUNT: nnn

PROGRAM: SM71 MSG-INDX: nn -- DB.2.1 -- yy.ddd / hh:mm:ss

MESSAGE:

Chapter 3: Scheduling Work 87

Schedule Definition

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following:
CLEAR
Clears the panel input data fields and resets the SCHID-COUNT to 0.
DELETE
Deletes a job schedule member from the database.
EDIT
Transfers the user to the EDIT facility as shown on the Job Scheduling
Parameter Edit panel, which enables the addition or modification of job
schedules in a work area.
FE
A combination of the FETCH and EDIT commands. Retrieves all schedule data
currently defined for the job and transfers you to the secondary scheduling
panel. The scheduling information for the first schedule ID defined for the job is
displayed.
FETCH
Retrieves job schedule data from the database and makes all schedule
information for this job available to the user through the EDIT function of this
panel.
REPL
Replaces existing schedule member in the database. Any SCHMODs that have
been done to the schedule are cleared. This is not the same as overlaid, which
can only occur when a RESOLV is done.
RESOLV
Generates a RESOLV command for the job indicated using the calendar
specified. Any new or modified calendar based schedule must be resolved
before it takes effect.
SAVE
Adds a new job schedule member to the database for this job.
Note: The FETCH function can reference one job name while the SAVE or REPL
function specifies a different job name. This lets the user make some changes
to the schedule of an existing job and save those changes as the schedule for a
new job.
Batch keyword: Positional parameter

88 Database Maintenance Guide

 Schedule Definition

n/a
Contains a constant value of JOB for jobs.
Limits: Required for batch only.
Batch keyword: Positional parameter
JOB
Specifies the required job name for which schedule information is being defined.
Limits: 1 to 8 alphanumeric characters
Batch keyword: JOB
JOBL
Specifies the long job name for which schedule information is being defined.
Limits: 1 to 64 alphanumeric characters, case sensitive
Batch keyword: JOBL
SCAL
Specifies the last two characters of the default base calendar ID to use for schedule
resolution. The complete calendar ID used is in the format SCALnnxx where nn is
the current year and xx is the value entered. This value is used for all SCHIDs that do
not have a specific value coded on the DB.2.1-E panel.
Limits: 2 alphanumeric characters
Required for the SAVE, REPL, and RESOLV functions.
Optional for CLEAR, DELETE, and EDIT functions.
Automatically supplied for FETCH or FE functions.
Batch keyword: SCAL
SCHID-COUNT
Identifies a system-generated field that shows how many schedule IDs currently
exist in the Edit Work File.

Usage Notes

You must resolve schedules defined on this panel against the specified base calendar
with the RESOLV function or top line command before CA WA CA 7 Edition automatic
scheduling can commence.

Chapter 3: Scheduling Work 89

Schedule Definition

Job Scheduling Parameter Edit Panel

Note: Although this panel and command specifically mentions CPU jobs, these functions
are also available with all cross-platform jobs (for example, XPJOBs or agent jobs).

The Job Scheduling Parameter Edit panel lets you define or review schedules for jobs
that are run on a date and time basis.

To display the panel, enter EDIT as the function on the DB.2.1 panel.

To exit the panel:

■ Press PF3 to return to the DB.2 Menu panel except with the TSO/ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

------------------ CA-7 CPU JOB SCHEDULING PARAMETER EDIT ------------------

FUNCTION: xxxxxxxx (ADD,DELETE,EXIT,FORMAT,LIST,REPL,SAVE,SR,SS)
JOB: xxxxxxxx SCHID: nnn SCAL: xx ROLL: x INDEX: nnnn
DOTM LDTM SBTM ---------------------REPEAT----------------------
hhmm hhmm hhmm INTERVAL: hhmm TYPE: xxxxx COUNT: nnnn STOP: hhmm

-- _ -- DAILY
-- _ -- WEEKLY SUN: _ MON: _ TUE: _ WED: _ THU: _ FRI: _ SAT: _

-- _ -- MONTHLY JAN: _ FEB: _ MAR: _ APR: _ MAY: _ JUN: _

JUL: _ AUG: _ SEP: _ OCT: _ NOV: _ DEC: _
WEEK: ______________ DAY-OF-WEEK: ___________________________
RDAY: ____________________________________________________________

-- _ -- ANNUAL DAY: _______________________________________________________

DEFAULT SCAL: xx
-- _ -- SYMETRIC START: ___ SPAN: ___ SCHID-COUNT: nnn

PROGRAM: SM72 MSG-INDX: nn -- DB.2.1-E -- yy.ddd / hh:mm:ss

MESSAGE:

90 Database Maintenance Guide

 Schedule Definition

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following:
ADD
Adds a new SCHID to the work area.
DELETE
Deletes a SCHID from the work area.
EXIT
Returns the user to the DB.2.1 panel restoring the SCHID-COUNT and schedule
data to that which existed when EDIT was initially entered and clears the work
area. Any changes made are ignored.
FORMAT
Clears the panel of user input data.
LIST
Lists all existing SCHIDs, one per panel.
REPL
Replaces an existing SCHID in work area. (Before replacing, you must use the
LIST command to display the existing record.)
SAVE
Updates SCHID-COUNT and SCHID information, and returns the user to the
DB.2.1 panel. Work area data (changes) are retained but the database is not
updated.
SR
Combination function that results in a SAVE, a return to the DB.2.1 panel, and a
subsequent REPL to replace an existing schedule in the database. Saves all
schedule IDs into the Active Area and replaces them in the CA WA CA 7 Edition
database. If not specified, the scheduling changes are lost once leaving this
panel. Entering the SR function automatically returns you to the prior
scheduling panel.
SS
Combination function that results in a SAVE, a return to the DB.2.1 panel, and a
subsequent SAVE to add a newly defined schedule in the database.
Batch keyword: Positional parameter

Chapter 3: Scheduling Work 91

Schedule Definition

JOB
Reflects the job name from the previous panel. This is informational only.
SCHID
Specifies the numeric schedule ID on which the user wants to perform the specified
action.
Limits: 1 to 3 numeric characters from 1 through 999
Batch keyword: SCHID
SCAL
(Optional) Specifies the override of the default SCAL for this SCHID. If this SCHID is
using the default, this field is blank.
Limits: 2 alphanumeric characters
Batch keyword: SCAL
ROLL
(Optional) Specifies the action to take when a schedule day falls on a base calendar
nonavailable processing day. This is not used if the DAILY option is used. If used, the
value must be one of the following:
B
Roll the schedule back to the previous available processing day in the Base
Calendar.
F
Roll the schedule forward to the next available processing day.
N
Do not roll. Schedule day must stand.
D
Do not roll and do not schedule.
Default: D
Batch keyword: ROLL

92 Database Maintenance Guide

 Schedule Definition

INDEX
(Optional) Specifies an adjustment to schedule days. After exercising the ROLL
option, the schedule is adjusted, forward for plus or backward for minus, by the
number of working days entered.
Limits: 4 numeric characters specified as Innn where I can be plus (unsigned) or
minus (-) and nnn can be 0 to 365 days
Batch keyword: INDEX
You can use this field together with the RDAY field to schedule a job to run 3 work
days before the 15th of the month: specify -3 in the INDEX field, X in the MONTHLY
field, and 15 in the RDAY field.
DOTM
Specifies the due-out time of day for this schedule ID.
Limits: 4 numeric characters specified as hhmm where hh can be 00 through 24 and
mm can be 00 through 59. Must be greater than 0000.
Required for ADD and REPL functions.
Optional for DELETE, EXIT, FORMAT, LIST, SAVE, SR, and SS functions.
Batch keyword: TIME
In batch format, this field and the next two fields must be provided as a list of
hhmm values as follows:
TIME=(dueout,lead,submit)
LDTM
Specifies the lead time (elapsed or clock time) for this schedule ID. Lead time
specifies the amount of time necessary to ensure that the job completes before its
due-out time plus any additional time required to perform setup functions. This
value is used for deadline prompting and forecasting only if elapsed (clock) time on
the DB.1 panel is set to 2359.
Limits: 4 numeric characters specified as hhmm where hh can be 00 through 24 and
mm can be 00 through 59. Must be greater than 0000.
Required for ADD and REPL functions.
Optional for DELETE, EXIT, FORMAT, LIST, SAVE, SR, and SS functions.
Batch keyword: TIME

Chapter 3: Scheduling Work 93

Schedule Definition

SBTM
(Optional) Specifies the submit time of day for this schedule ID. If specified, the job
is not submitted before this time. If the submit time is before deadline start time,
the submit time requirement is automatically satisfied when the job enters the
queue. A submit time of zeros is the same as not specifying it, and no submit time is
set up.
Note: If the submit time is after the due-out time, the submit day value is set to the
previous day.
Limits: 4 numeric characters specified as hhmm where hh can be 00 through 24 and
mm can be 00 through 59
Batch keyword: TIME
INTERVAL
(Optional) Specifies that the job should be repeated (executed more than once) and
specifies the amount of time between each iteration.
If INTERVAL is specified, the SBTM (submit time requirement) and TYPE fields are
required.
If both INTERVAL and COUNT are specified, the INTERVAL value times the COUNT
value must total less than 24 hours.
If INTERVAL is not specified, the job is not repeated.
Note: For more information about how deadline, due-out, and submit time
requirements are calculated for repeating jobs, see the Usage Notes.
Limits: 4 numeric characters in hhmm format where hh can be from 0 to 23 and mm
can be from 00 to 59
Batch keyword: INTERVAL
TYPE
(Optional) Determines how the submit time requirement is calculated for repeating
jobs. A TYPE of CLOCK indicates that the INTERVAL is added to the previous
iteration's submit time requirement to determine the new submit time
requirement. A TYPE of START and END indicates that the INTERVAL is added to the
previous iteration's last (most recent) start and end times, respectively, to
determine the new submit time requirement. TYPE is required if INTERVAL is
specified. TYPE is discarded if INTERVAL is not specified.
Limits: CLOCK, START, or END
Batch keyword: TYPE

94 Database Maintenance Guide

 Schedule Definition

COUNT
(Optional) Specifies the maximum number of times to repeat the job. COUNT is
discarded if INTERVAL is not specified. If both COUNT and STOP are specified, the
job stops repeating when either the COUNT reaches zero or the STOP time is
reached, whichever comes first. If COUNT is not specified, the job repeats until the
STOP time is reached.
Limits: 1 to 4 numeric characters from 0 to 1439. Leading zeros can be discarded.
Batch keyword: COUNT
STOP
(Optional) Specifies the clock time on or after which the job should not be repeated.
STOP is discarded if INTERVAL is not specified. If both COUNT and STOP are
specified, the job stops repeating when either the COUNT reaches zero or the STOP
time is reached, whichever comes first.
If the STOP time is less than the submit time requirement, the stop date is assumed
to be the following day.
A stop time of zeros is the same as not specifying a value.
Default: 1439 minutes (24 hours minus 1 minute) after the submit time
Limits: 4 numeric characters specified as hhmm
where hh can be from 0 to 23 and mm can be from 00 to 59
Batch keyword: STOP
DAILY
(Optional) Specifies that the user wants to define a daily schedule. Daily means
every available processing day as defined by the Base Calendar. Enter an X or Y to
select this. If DAILY is used, the ROLL function has no effect.
Batch keyword: DAILY
WEEKLY
(Optional) Specifies that the user wants to define a weekly schedule. Enter an X or Y
to select this. If WEEKLY is used, the run days of the week must be selected using
the SUN through SAT fields.
Batch keyword: WEEKLY

Chapter 3: Scheduling Work 95

Schedule Definition

SUN thru SAT

Defines specific days of the week on which to run the job.
Online:
Place an X in panel field names SUN through SAT as necessary to indicate the
weekly run days.
Limits: Required if WEEKLY is used.
Batch keyword: DAYS
Batch:
Place an X in any of the seven positions following the batch keyword DAYS to
indicate weekly run days. A day is skipped by omitting an X for that day. For
example, if a job is to run weekly on Sunday, Wednesday and Saturday, the user
would specify:
DAYS=(X,,,X,,,X)
MONTHLY
(Optional) Specifies that the user wants to define a monthly schedule. If this field is
used, the user can optionally specify on which particular months the job is to run. If
specific months are not specified in the JAN through DEC fields, all months are
assumed. Enter an X or Y to select this.
Limits: At least WEEK(S) and DAY-OF-WEEK (DOW) or RDAY(S) must also be
specified if MONTHLY is used.
Batch keyword: MONTHLY
JAN thru DEC
(Optional) Online:
Place an X in panel field names JAN through DEC to indicate the run months during
the year. Used with MONTHLY.
Default: Every month if MONTHLY is used and no months are chosen
Batch keyword: MONTHS
Batch:
Place an X in any of the 12 positions following the batch keyword MONTHS to
indicate run months. A month is skipped by omitting an X for that month. For
example, if a job is to run in January, June, July, and November, the user would
specify:
MONTHS=(X,,,,,X,X,,,,X,)

96 Database Maintenance Guide

 Schedule Definition

WEEK
Specifies which weeks of the month to run the job. The values specified can be
positive (unsigned), negative (-) or slash (/).
Positive values 1, 2, 3, 4, or 5 are used to indicate days of week relative to the
beginning of the month. Negative values -0, -1, and -2 are used to indicate
occurrence of day of week relative to the end of the month. Slashes indicate not the
following value. For example, a job that is to run on the first occurrence of day of
week of every month and is also to run on the last occurrence of day of week of the
month would be entered as:
Online:
WEEK:1,-0 (separated by blanks or commas)
Limits: 1 to 14 numeric characters and required if MONTHLY and DAY-OF-WEEK are
used.
Batch keyword: WEEKS
Batch:
WEEKS=1 -0 (separated by blanks)
DAY-OF-WEEK
Specifies which days of the week to run the job. If used, each day must be the first
three letters of the wanted run days just as it appears on the panel following the
weekly field (for example, SUN, MON, and so on).
Online:
DAY-OF-WEEK:TUE,THU
(separated by blanks or commas)
Limits: 3 to 27 alphanumeric characters and required only if WEEK is used with
MONTHLY.
Batch keyword: DOW
Batch:
DOW=TUE THU (separated by blanks)

Chapter 3: Scheduling Work 97

Schedule Definition

RDAY
(Optional) Specifies relative days of the month on which the job is to run. Used with
MONTHLY. A day relative to the beginning or end of the month is specified. If a
positive (unsigned) value is used, the job runs that day relative to the first of the
month. Negative (-) values are used to indicate run days relative to the end of the
month.
Additionally, if you have days of the month when this job is not to run, a slash (/)
can be used with the unsigned or negative values. Valid positive values range from
1 to 31. Valid negative values range from -0 to -30.
Limits: 1 to 60 numeric characters
Batch keyword: RDAYS
To understand the meaning and use of RDAY, assume a job is to run daily, but not
on the first and last day of each month. The user could select DAILY, MONTHLY and
specify:
Online:
RDAY:/1,/-0 (separated by a blank or comma)
Batch:
RDAYS=/1 /-0 (separated by a blank)
Note: RDAY(S) represents calendar days, unless the base calendar was generated
with OPTIONS=SCHDYONLY, in which case RDAY(S) represents processing days.
ANNUAL
(Optional) Defines an annual schedule. To select this type of schedule, enter an X or
Y in this optional field.
Limits: If ANNUAL is used, DAY is required.
Batch keyword: ANNUAL
DAY
(Optional) Specifies on which days of the annual schedule the user wants to run the
job. Days are entered as 1 through 366 and are prefixed by positive (unsigned) or
slash (/) values. Slash indicates not this day.
Limits: 1 to 55 numeric characters and required if ANNUAL is used.
Batch keyword: ANNDAYS
For example, if a job is to run on days 121, 132, 240, and 241, but is not to run on
days 122, 242, and 1, the user would specify:
Online:
DAY:/1,121,/122,132,240,241,/242
(separated by blanks or commas)

98 Database Maintenance Guide

 Schedule Definition

Batch:
ANNDAYS=/1 121 /122 132 240 241 /242
(separated by blanks)
By default, days not specifically defined as processing days (with a number) are
considered as unscheduled days unless another field, such as WEEKLY or MONTHLY
schedules those days. The use of the slash (/) examples given above is only provided
here to illustrate the format of the date specification.
The following illustrates a more practical example of using "not days" (/). Assume a
job's schedule has been defined as every Friday by selecting WEEKLY and FRI.
During the week containing Julian day 177 (a Friday), the job is to run on Thursday
(176) instead of Friday. The user would select WEEKLY, FRI, ANNUAL, and specify:
Online:
DAY:/177,176
Batch:
ANNDAYS=/177 176
When specifying annual days in a schedule definition, keep in mind whether this
schedule is to be resolved for a January through December schedule or a July
through June schedule. For January through December resolutions, the Julian dates
specified are simply for the year resolved.
For July through June resolutions, July through December dates are for the current
year. January through June dates are for the next year.
DEFAULT SCAL
Reflects the default SCAL value from the previous panel. This value applies to all
SCHIDs unless the SCAL field is supplied on the current panel.
SYMETRIC
(Optional) Used with the START and SPAN fields, defines a symmetric schedule.
With this option, schedules are defined as beginning on the date specified with the
START field and recurring every nnn days as specified with the SPAN field. (This field
is misspelled intentionally to provide compatibility with the batch keyword that
cannot exceed eight characters.) The selection of this type of schedule is made by
entering an X or Y.
Batch keyword: SYMETRIC

Chapter 3: Scheduling Work 99

Schedule Definition

START
(Optional) Used with SPAN and SYMETRIC fields, defines a symmetric schedule. This
field is required when the SYMETRIC option is taken. Value must be specified as the
Julian day of the year on which the symmetric schedule is to begin. This value
should be evaluated yearly before schedule resolution and may need to be changed
each year.
If the schedule will be resolved on a July-June basis, the start date must be within
the first of the two years in which the schedule overlaps. For January-December
schedules, it is simply relative to January 1 of the year specified on a RESOLV
command.
If the calendar against which this SCHID will be resolved does not have the
OPTIONS=SCHDYONLY, the START day is adjusted each year to maintain the job's
symmetric schedule from the job's original specified START day.
If the calendar against which the SCHID will be resolved was generated with overall
available processing days only (OPTIONS=SCHDYONLY), the start date must specify
the first day on which the job would actually run. This requires manually setting
(verifying) the START value each year before the RESOLV.
If a nonprocessing day is specified, the start day is the next processing day found in
the calendar. For example, if January 1 is a nonprocessing day and the calendar was
generated with OPTIONS=SCHDYONLY, and 1 is specified as the START day, January
2 is the actual START day (provided it is an available processing day). SPAN is based
from January 2 in this example rather than January 1.
For other types of calendars, the start date is determined at RESOLV time based on
the ROLL and INDEX options taken.
Limits: 3 numeric characters specified as Julian day of the year from 1 to 365
Batch keyword: START

100 Database Maintenance Guide

 Schedule Definition

SPAN
(Optional) Used with SYMETRIC and START, defines symmetric schedules. This field
is required if the SYMETRIC option is taken. When used, specifies the number of
days between scheduled processing cycles.
If the calendar against which the SCHID will be resolved was generated with
processing days only (OPTIONS=SCHDYONLY), the SPAN value is specified as the
number of available processing days between and including the next processing
date as opposed to the actual number of days. With this type of calendar, the ROLL
and INDEX options serve no practical purpose. For other calendar types, the SPAN
value is specified as the number of calendar days between processing cycles and
the ROLL and INDEX options can be used as necessary.
Limits: 1 to 3 numeric characters from 1 to 255
Batch keyword: SPAN
SCHID-COUNT
Identifies a system-generated field containing the current schedule ID count for this
job.

Batch Input Example

This batch input example adds schedule ID 1 for job CA07XX01 for a daily schedule,
using calendar 03, with a due-out time of 0800, and a lead time of one hour.

SCHD
JOB
EDIT
ADD,SCHID=1,DAILY=Y,TIME=(0800,0100)
SAVE
SAVE,JOB=CA07XX01,SCAL=03
DBM

Chapter 3: Scheduling Work 101

Schedule Definition

Usage Notes for Repeating Jobs

A job can be brought into the request queue once through schedule scan and executed
more than once. Each iteration must successfully complete (or be forced complete)
before the next iteration is added to the request queue. The following fields are used
with repeating jobs:
INTERVAL
Required. Specifies the amount of time between each iteration of the job.
TYPE
Required. Specifies how the submit time requirement of each iteration is
calculated-by adding the INTERVAL to the previous iteration's submit time
requirement (CLOCK), START, or END time.
COUNT
Optional. Specifies the maximum number of times the job will be repeated.
STOP
Optional. Specifies the clock time after which the job is not to be repeated. If not
specified then the stop time will be 1439 minutes (24 hours minus one minute)
after the submit time requirement of the first iteration.
DOTM
Required. Specifies the due-out time (expected completion time) of the first
iteration.
LDTM
Required. Specifies the amount of time required to process the job.
SBTM
Required. Specifies the submit time requirement of the first iteration.

As each iteration successfully completes (or is forced complete), CA WA CA 7 Edition

adds the INTERVAL to the submit time requirement, start time, or end time based on
the TYPE setting. This value becomes the next iteration's submit time requirement.

The new submit time requirement is then compared to the STOP time. If either the new
submit time requirement or the current time are greater than the STOP time then the
job is not repeated.

The new job's due-out time is calculated as the new submit time requirement plus the
difference between the original due-out time and the original submit time requirement.

102 Database Maintenance Guide

 Schedule Definition

The new job's deadline time is calculated as the new due-out time minus the original
lead time (LEADTM).

The start and end times of the job are local to the system where the job executed, not
local to the system where CA WA CA 7 Edition is executing. TYPE=START and END should
be used with care for NJE and cross-platform jobs.

Once a repeating job is in the request queue, you can skip iterations by adjusting the
job's submit time using the QM.3 (XUPD) command. For example, suppose a job is set to
repeat every hour on the hour, but today only you want to skip the 11 a.m. and 12 noon
iterations. After the 10 a.m. iteration completes, you can use QM.3 command to edit
the job's early start time to 1300 (1 p.m.). The job then waits until 1 p.m. before
continuing to repeat.

DB.2.2 - Input Network Scheduling Panel

The DB.2.2 - Input Network Scheduling panel lets you define or review scheduling
options for input networks.

To display the panel, enter:

■ 2 as the FUNCTION on the DB.2 Menu panel.
■ 2.2 as the FUNCTION on the DB Menu panel.
■ DB.2.2 as the FUNCTION on any other menu or formatted input panel.
■ DB.2.2 or SCHD,INWK as a top line command.

To exit the panel:

■ Press PF3 to return to the DB.2 Menu panel except with the TSO/ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

Chapter 3: Scheduling Work 103

Schedule Definition

---------------------- CA-7 INPUT NETWORK SCHEDULING -----------------------

FUNCTION: xxxxxxxx (CLEAR,DELETE,EDIT,FE,FETCH,REPL,RESOLV,SAVE)

NETWORK: xxxxxxxx

SCAL: xx (DEFAULT SCAL ID FOR ADDS)

SCHID-COUNT: nnn

PROGRAM: SM71 MSG-INDX: nn -- DB.2.2 -- yy.ddd / hh:mm:ss

MESSAGE:

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following:
CLEAR
Clears the panel input data fields and resets the SCHID-COUNT to 0.
DELETE
Deletes an input network schedule member from the database.
EDIT
Transfers the user to the EDIT facility as shown on the Input Network
Scheduling Parameter Edit panel. This permits the addition or modification of
input network schedules in a work area.
FE
Combines FETCH and EDIT.
FETCH
Retrieves input network schedule data from the database and makes all of the
schedule information for this input network available to the user through the
EDIT function of this panel.
REPL
Replaces an existing schedule in the database.

104 Database Maintenance Guide

 Schedule Definition

RESOLV
Generates a RESOLV command for the network indicated using the calendar
specified. Any new or modified calendar based schedule must be resolved
before it takes effect.
SAVE
Adds a new schedule to the database for this input network. The user can SAVE
to any input network name but the number of stations specified on the EDIT
panel for the network must equal the number defined for the network.
Batch keyword: Positional parameter
n/a
Contains a constant value of INWK for input networks.
Limits: Required for batch only.
Batch keyword: Positional parameter
NETWORK
Specifies the input network name for which schedule information is being defined.
Limits: 1 to 8 alphanumeric characters
Batch keyword: NETWORK
SCAL
Specifies the last two characters of the default base calendar ID to use for schedule
resolution. The complete calendar ID used is in the format SCALnnxx where nn is
the current year and xx is the value entered. This value is used for all SCHIDs that do
not have a value coded on the DB.2.2-E panel.
Limits: 2 alphanumeric characters
Required for SAVE, REPL, and RESOLV functions.
Optional for CLEAR, DELETE, EDIT, FE, and FETCH functions.
Batch keyword: SCAL
SCHID-COUNT
Identifies a system-generated field that shows how many schedule IDs currently
exist for this network.

Chapter 3: Scheduling Work 105

Schedule Definition

Input Network Scheduling Parameter Edit Panel

The Input Network Scheduling Parameter Edit panel lets you define or review scheduling
parameters for input networks that are to be scheduled on a date and time basis.

To display the panel, enter EDIT as the function on the DB.2.2 panel.

To exit the panel:

■ Press PF3 to return to the DB.2 Menu panel except with the TSO/ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

--------------- CA-7 INPUT NETWORK SCHEDULING PARAMETER EDIT ---------------

FUNCTION: xxxxxxxx (ADD,DELETE,EXIT,FORMAT,LIST,REPL,SAVE,SR,SS)
NWK: xxxxxxxx SCHID: nnn SCAL: xx ROLL: x INDEX: nnnn
STATION DOTM LDTM DODY STATION DOTM LDTM DODY STATION DOTM LDTM DODY
1 xxxxxxxx hhmm hhmm nnnn 2 xxxxxxxx hhmm hhmm nnnn 3 xxxxxxxx hhmm hhmm nnnn
4 xxxxxxxx hhmm hhmm nnnn 5 xxxxxxxx hhmm hhmm nnnn 6 xxxxxxxx hhmm hhmm nnnn
7 xxxxxxxx hhmm hhmm nnnn 8 xxxxxxxx hhmm hhmm nnnn 9 xxxxxxxx hhmm hhmm nnnn

-- _ -- DAILY
-- _ -- WEEKLY SUN: _ MON: _ TUE: _ WED: _ THU: _ FRI: _ SAT: _

-- _ -- MONTHLY JAN: _ FEB: _ MAR: _ APR: _ MAY: _ JUN: _

JUL: _ AUG: _ SEP: _ OCT: _ NOV: _ DEC: _
WEEK: ______________ DAY-OF-WEEK: __________________________
RDAY: ____________________________________________________________

-- _ -- ANNUAL DAY: _______________________________________________________

DEFAULT SCAL: xx
-- _ -- SYMETRIC START: ___ SPAN: ___ SCHID-COUNT: nnn

PROGRAM: SM72 MSG-INDX: nn -- DB.2.2-E -- yy.ddd / hh:mm:ss

MESSAGE:

106 Database Maintenance Guide

 Schedule Definition

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of following:
ADD
Adds a new SCHID to the work area.
DELETE
Deletes a SCHID from the work area.
EXIT
Returns the user to the DB.2.2 panel and restores the SCHID-COUNT and
schedule data to that which existed when EDIT was initially entered and clears
the work area.
FORMAT
Clears the panel of user input data.
LIST
Lists all SCHIDs, one per panel.
REPL
Replaces an existing SCHID in the work area.
SAVE
Updates SCHID-COUNT and SCHID information and returns the user to the
DB.2.2 panel. Work area data (changes) are retained but the database is not
updated.
SR
Combination function that results in a SAVE, a return to the DB.2.2 panel, and a
subsequent REPL to replace an existing schedule in the database. Saves all
schedule IDs into the Active Area and replaces them in the CA WA CA 7 Edition
database. If not specified, the scheduling changes are lost once leaving this
panel. Entering the SR function automatically returns you to the prior
scheduling panel.
SS
Combination function that results in a SAVE, a return to the DB.2.2 panel, and a
subsequent SAVE to add a newly defined schedule in the database.
Batch keyword: Positional parameter

Chapter 3: Scheduling Work 107

Schedule Definition

NWK
Reflects the network name from the previous panel. This is informational only.
SCHID
(Optional) Specifies the numeric schedule ID on which to perform the specified
action.
Limits: 1 to 3 numeric characters from 1 through 999
Batch keyword: SCHID
SCAL
(Optional) Overrides the default SCAL for this SCHID. If this SCHID is using the
default, this field is blank.
Limits: 2 alphanumeric characters
Batch keyword: SCAL
ROLL
(Optional) Specifies the action to take when a schedule day falls on a base calendar
nonavailable processing day. If used, the value must be one of the following:
B
Roll the schedule back to the previous available processing day in the Base
Calendar.
F
Roll the schedule forward to the next available processing day.
N
Do not roll. Schedule day must stand.
D
Do not roll and do not schedule.
Default: D
Batch keyword: ROLL

108 Database Maintenance Guide

 Schedule Definition

INDEX
(Optional) Specifies an adjustment to schedule days. After exercising the ROLL
option, the schedule is adjusted, forward or backward, by the number of working
days entered.
Limits: 1 to 4 numeric characters specified as Innn where I can be plus (unsigned) or
minus (-) and nnn can be 0 to 365 days
Batch keyword: INDEX
STATION
(Optional) Specifies network workstation names. Up to nine workstations are listed.
Station names are listed in the sequence in which their tasks are to be performed
(that is, as defined for the network). The same station name can appear multiple
times in the list. This field is for station identification purposes only. For batch, see
the note under the TIME batch keyword.
Limits: 1 to 8 alphanumeric characters
Batch keyword: Not applicable (see TIME)
DOTM
Specifies the due-out time of day for the network workstation using this schedule
ID.
Limits: 1 to 4 numeric characters specified as hhmm, where hh can be 00 through
24 and mm can be 00 through 59
Required for ADD or REPL functions.
Optional for DELETE, EXIT, FORMAT, LIST, SAVE, SR, or SS functions.
Batch keyword: TIME
Note for batch input: The following format must be used, where the numeric value
(or n) corresponds to the relative number of the station.
TIME=(dotm1,ldtm1,dody1,dotm2,ldtm2,dody2,...,dotmn,ldtmn,dodyn)

LDTM
Specifies the lead time for the workstation for this schedule ID. This is the amount
of elapsed time necessary to ensure that the station completes its task by the
scheduled due-out time.
Limits: 1 to 4 numeric characters specified as hhmm, where hh can be 00 through
24 and mm can be 00 through 59
Required for ADD or REPL functions.
Optional for DELETE, EXIT, FORMAT, LIST, SAVE, SR, or SS functions.
Batch keyword: TIME

Chapter 3: Scheduling Work 109

Schedule Definition

DODY
Specifies the due-out day for the workstation in the network for this schedule ID. It
is always relative to the first workstation in the network. It indicates the number of
days elapsed from the first workstation.
Default: 0
Limits: 1 to 4 numeric characters from 0 through 255
Required if the lead time (elapsed time) between workstations in a network causes
the schedule to cross any midnight boundary.
Batch keyword: TIME
DAILY
(Optional) Specifies to define a daily schedule. Daily means every available
processing day as defined by the Base Calendar. Enter an X or Y to select this.
Batch keyword: DAILY
WEEKLY
(Optional) Specifies that the user wants to define a weekly schedule. Enter an X or Y
to select this. If WEEKLY is used, the run days of the week must be selected using
the SUN through SAT fields.
Batch keyword: WEEKLY
SUN thru SAT
These fields are used to define specific days of the week on which the network is to
be run.
Online:
Place an X in panel field names SUN through SAT to indicate the weekly run days.
Limits: Required if WEEKLY is used.
Batch keyword: DAYS
Batch:
Place an X in any of the seven positions following the batch keyword DAYS to
indicate weekly run days. A day is skipped by omitting an X for that day. For
example, if a network is to run weekly on Sunday, Wednesday and Saturday, the
user would specify:
DAYS=(X,,,X,,,X)

110 Database Maintenance Guide

 Schedule Definition

MONTHLY
(Optional) Specifies that the user wants to define a monthly schedule. If this field is
used, the user can specify on which particular months the network is to run. If
specific months are not specified in the JAN thru DEC fields, all months are
assumed. Enter an X or Y to select this.
Batch keyword: MONTHLY
At least WEEK(S) and DAY-OF-WEEK (DOW) or RDAY(S) must be specified if
MONTHLY is used.
JAN thru DEC
(Optional) Online:
Place an X in panel field names JAN through DEC to indicate the run months during
the year. Used with MONTHLY.
Default: Every month if MONTHLY is used and no months are chosen
Batch keyword: MONTHS
Batch:
Place an X in any of the 12 positions following the batch keyword MONTHS to
indicate run months. A month is skipped by omitting an X for that month. For
example, if a network is to run in January, June, July and November, the user would
specify:
MONTHS=(X,,,,,X,X,,,,X,)
WEEK
(Optional) Specifies which weeks of the month the network is to run. Used with
MONTHLY and DAY-OF-WEEK. The values specified can be positive (unsigned),
negative (-) or slash (/).
Positive values 1, 2, 3, 4, or 5 are used to indicate which occurrence of day of week
relative to the beginning of the month. Negative values -0, -1, -2, -3, or -4 are used
to indicate which occurrence of day of week relative to the end of the month.
Slashes indicate it is not the following value.
Limits: 1 to 14 numeric characters
Batch keyword: WEEKS
For example, a network that is to run on the first week of every month and is also to
run on the last week of the month, would be entered as:
Online:
WEEK:1,-0 (separated by blanks or commas)
Batch:
WEEKS=1 -0 (separated by blanks)

Chapter 3: Scheduling Work 111

Schedule Definition

DAY-OF-WEEK
Specifies which day of the week the network is to be run. Used with WEEK and
MONTHLY. If used, must be the first three letters of the wanted run day just as it
appears on the panel following the weekly field (for example, SUN, MON, and so
on).
Online:
DAY-OF-WEEK:TUE,THU
(separated by blanks or commas)
Limits: 3 to 27 alphanumeric characters
Required if WEEK is used.
Batch keyword: DOW
Batch:
DOW=TUE THU (separated by blanks)
RDAY
(Optional) Specifies relative days of the month on which the network is to run. Used
with MONTHLY. A day relative to the beginning or end of the month is specified. If a
positive (unsigned) value is used, the network runs that day relative to the first of
the month. Negative (-) values are used to indicate run days relative to the end of
the month.
Additionally, if you have days of the month when this network is not to run, a slash
(/) can be used with the unsigned or negative values. Valid positive values range
from 1 to 31. Valid negative values range from -0 to -30.
Limits: 1 to 60 numeric characters
Batch keyword: RDAYS
To understand the meaning and use of RDAY, assume a network is to run daily, but
not on the first or last day of each month. The user could select DAILY, MONTHLY
and specify:
Online:
RDAY:/1,/-0 (separated by a blank or comma)
Batch:
RDAYS=/1 /-0 (separated by a blank)
Note: RDAY(S) represents calendar days, unless the base calendar was generated
with OPTIONS=SCHDYONLY, in which case RDAY(S) represents processing days.

112 Database Maintenance Guide

 Schedule Definition

ANNUAL
(Optional) Specifies an annual schedule. To select this type of schedule, enter an X
or Y in this field. If ANNUAL is used, DAY must also be specified.
Batch keyword: ANNUAL
DAY
Specifies on which days of the annual schedule the user wants to run the network.
Days are entered as 1 through 366 and are prefixed by positive (unsigned) or slash
(/) values. Slash indicates not this day.
Limits: 1 to 55 numeric characters
Required if the ANNUAL option above is chosen.
Batch keyword: ANNDAYS
For example, if a network is to run on days 121, 132, 240, and 241, but is not on
days 122, 242, and 1, you would specify:
Online:
DAY:/1,121,/122,132,240,241,/242
(separated by blanks or commas)
Batch:
ANNDAYS=/1 121 /122 132 240 241 /242
(separated by blanks)
By default, days not specifically defined as processing days (with a number) are
considered as unscheduled days unless another field such as WEEKLY or MONTHLY
schedules those days. The use of the slash (/) examples given previously is only
provided here to illustrate the format of the date specification.
The following illustrates a more practical example of using "not days" (/). Assume a
network schedule has been defined as every Friday by selecting WEEKLY and FRI.
During the week containing Julian day 177 (Friday), the network is to run on
Thursday (day 176) instead of Friday. The user would select WEEKLY, FRI, ANNUAL
and:
Online:
DAY:/177,176
Batch:
ANNDAYS=/177 176
When specifying annual days in a schedule definition, keep in mind whether this
schedule will be resolved for a January through December schedule or a July
through June schedule. For January through December resolutions, the Julian dates
specified are simply for the year resolved.
For July through June resolutions, July through December dates are for the current
year. January through June dates are for the next year.

Chapter 3: Scheduling Work 113

Schedule Definition

DEFAULT SCAL
Reflects the default SCAL value from the previous panel. This value applies to all
SCHIDs unless the SCAL field is supplied on the current panel.
SYMETRIC
(Optional) Used with the START and SPAN fields, defines a symmetric schedule.
(This field is misspelled intentionally on the panel to provide compatibility with the
batch keyword that cannot exceed eight characters in length.) The selection is made
by entering an X or Y. With this option, schedules are defined as beginning on the
date specified with the START field and recurring every nnn days as specified in the
SPAN field.
Batch keyword: SYMETRIC
START
Used with the SYMETRIC field, sets a starting day.
Limits: 1 to 3 numeric characters specified as Julian day from 1 to 365
Required if SYMETRIC option is chosen.
Batch keyword: START
If the schedule will be resolved on a July-June basis, the start date must be within
the first of the two years in which the schedule overlaps. For January-December
schedules, it is simply relative to January 1 of the year specified on a RESOLV
command.
If the calendar against which this SCHID will be resolved does not have the
OPTIONS=SCHDYONLY, the START day will be adjusted each year to maintain the
job's symmetric schedule from the job's original specified START day.
If the calendar against which the SCHID will be resolved was generated with overall
available processing days only (OPTIONS=SCHDYONLY), the start date must specify
the first day on which the network would actually run. This requires manually
setting (verifying) the START value each year before the RESOLV.
If a nonprocessing day is specified, the start day is the next processing day found in
the calendar. For example, if January 1 is a nonprocessing day and the calendar was
generated with OPTIONS=SCHDYONLY, and 1 is specified as the START day, January
2 is the actual START day (provided it is an available processing day). SPAN is based
from January 2 in this example rather than January 1.
For other types of calendars, the start date is determined at RESOLV time based on
the ROLL and INDEX options taken.

114 Database Maintenance Guide

 Schedule Definition

SPAN
Used with SYMETRIC and START, defines symmetric schedules. When used, specifies
the number of days between scheduled processing cycles.
If the calendar against which the SCHID will be resolved was generated with
processing days only (OPTIONS=SCHDYONLY), the SPAN value is specified as the
number of available processing days between and including the next processing
date as opposed to the actual number of days. With this type of calendar, the ROLL
and INDEX options serve no practical purpose. For other calendar types, the SPAN
value is specified as the number of calendar days between processing cycles and
the ROLL and INDEX options can be used as necessary.
Limits: 1 to 3 numeric characters no greater than 255
Required if the SYMETRIC option is chosen.
Batch keyword: SPAN
SCHID-COUNT
Identifies a system-generated field containing the current schedule ID count for this
network.

Example: Batch Input

This batch input example adds schedule ID 1 for input network TESTINNW as a DAILY
schedule using calendar PE. This network has two stations. The first station has a
due-out time of 0800 with a lead time of one hour. The second station has a due-out
time of 0900 with a lead time of 30 minutes.

DBM
SCHD
INWK
EDIT,NETWORK=TSTINWK2,SCAL=PE
ADD,SCHID=1,DAILY=Y,TIME=(0800,0100,,0900,0030)
SAVE
SAVE,NETWORK=TSTINWK2,SCAL=PE

DB.2.3 - Output Network Scheduling Panel

The DB.2.3 - Output Network Scheduling panel lets you define or review options taken
for output network schedules.

To display the panel, enter:

■ 3 as the FUNCTION on the DB.2 Menu panel.
■ 2.3 as the FUNCTION on the DB Menu panel.
■ DB.2.3 as the FUNCTION on any other menu or formatted input panel.
■ DB.2.3 or SCHD,ONWK as a top line command.

Chapter 3: Scheduling Work 115

Schedule Definition

To exit the panel:

■ Press PF3 to return to the DB.2 Menu panel except with the TSO/ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

---------------------- CA-7 OUTPUT NETWORK SCHEDULING ----------------------

FUNCTION: xxxxxxxx (CLEAR,DELETE,EDIT,FE,FETCH,REPL,RESOLV,SAVE)

NETWORK: xxxxxxxx

SCHID-COUNT: nnn

PROGRAM: SM71 MSG-INDX: nn -- DB.2.3 -- yy.ddd / hh:mm:ss

MESSAGE:

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of following:
CLEAR
Clears the panel input data fields and resets the SCHID-COUNT to 0.
DELETE
Deletes a network schedule member from the database.
EDIT
Transfers the user to the EDIT facility, as shown on the Output Network
Scheduling Parameter Edit panel. This enables the addition or modification of
network schedules in a work area.

116 Database Maintenance Guide

 Schedule Definition

FE
Combines FETCH and EDIT.
FETCH
Retrieves output network data from the database and makes all of the
schedule ID information for this output network available to the user through
the EDIT function of this panel.
REPL
Replaces existing schedule member in the database.
RESOLV
Not applicable.
SAVE
Adds a new schedule to the database for this output network. The user can
SAVE to any output network name but the number of stations in the EDIT panel
for the network must equal the number defined for the network.
Batch keyword: Positional parameter
n/a
Contains a constant value of ONWK for output networks.
Limits: Required for batch only.
Batch keyword: Positional parameter
NETWORK
Specifies the output network name for which schedule information is being defined.
Limits: 1 to 8 alphanumeric characters
Batch keyword: NETWORK
SCHID-COUNT
Identifies a system-generated field containing the user the current schedule ID
count for this network.
Note: Output networks have no SCAL field because their schedule is actually based
on the schedule of a connected job. Also, the RESOLV function has no effect on
output network schedules.

Chapter 3: Scheduling Work 117

Schedule Definition

Usage Notes

If the network is connected to the job with a DB.3.4 function, the network is scheduled
automatically whenever the connected job is scheduled. However, the network must be
scheduled with DB.2.3 so that time values can be given.

Optionally, for networks that direct the manual handling of SYSOUT type data, users of
CA Dispatch can have that product automatically issue a DMDNW command for the
network. In this case, the network must not be connected to a job with the DB.3.4
panel.

Output Network Scheduling Parameter Edit Panel

The Output Network Scheduling Parameter Edit panel lets you define or review
individual workstation schedules in an output network. The output network's schedule
cycles are based on the schedules of the jobs to which it is connected.

To display the panel, enter EDIT as the function on the DB.2.3 panel.

To exit the panel:

■ Press PF3 to return to the DB.2 Menu panel except with the TSO/ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

118 Database Maintenance Guide

 Schedule Definition

-------------- CA-7 OUTPUT NETWORK SCHEDULING PARAMETER EDIT ---------------

FUNCTION: xxxxxxxx (ADD,DELETE,EDIT,FORMAT,LIST,REPL,SAVE,SR,SS)
NWK: xxxxxxxx SCHID: nnn
STATION DOTM LDTM DODY STATION DOTM LDTM DODY STATION DOTM LDTM DODY
1 xxxxxxxx hhmm hhmm nnnn 2 xxxxxxxx hhmm hhmm nnnn 3 xxxxxxxx hhmm hhmm nnnn
4 xxxxxxxx hhmm hhmm nnnn 5 xxxxxxxx hhmm hhmm nnnn 6 xxxxxxxx hhmm hhmm nnnn
7 xxxxxxxx hhmm hhmm nnnn 8 xxxxxxxx hhmm hhmm nnnn 9 xxxxxxxx hhmm hhmm nnnn

SCHID-COUNT: nnn

PROGRAM: SM72 MSG-INDX: nn -- DB.2.3-E -- yy.ddd / hh:mm:ss

MESSAGE:

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following:
ADD
Adds a new SCHID to the work area.
DELETE
Deletes a SCHID from the work area.
EXIT
Returns the user to the DB.2.3 panel, restores the SCHID-COUNT and schedule
data to that which existed when EDIT was initially entered and clears the work
area.
FORMAT
Clears the panel of user input data.
LIST
Lists all existing SCHIDs, one per panel.

Chapter 3: Scheduling Work 119

Schedule Definition

REPL
Replaces an existing SCHID in the work area.
SAVE
Updates SCHID-COUNT and SCHID information and returns the user to the
DB.2.3 panel. Work area data (changes) are retained but the database is not
updated.
SR
Combination function that results in a SAVE, a return to the DB.2.3 panel, and a
subsequent REPL to replace an existing schedule in the database. Saves all
schedule IDs into the Active Area and replaces them in the CA WA CA 7 Edition
database. If not specified, the scheduling changes are lost once leaving this
panel. Entering the SR function automatically returns you to the prior
scheduling panel.
SS
Combination function that results in a SAVE, a return to the DB.2.3 panel, and a
subsequent SAVE to add a newly defined schedule in the database.
Batch keyword: Positional parameter
NWK
Reflects the network name from the previous panel. This is informational only.
SCHID
Specifies the numeric schedule ID on which the user wants to perform the specified
action.
Limits: 1 to 3 numeric characters from 1 through 999
Batch keyword: SCHID
STATION 1 thru 9
(Optional) Specifies network workstation names. Up to nine workstations are listed.
Station names are listed in the sequence in which their tasks are to be performed.
The same station name can appear multiple times in the list. This field is for station
identification purposes only.
Limits: 1 to 8 alphanumeric characters
Batch keyword: Not applicable (see TIME)

120 Database Maintenance Guide

 Schedule Definition

DOTM
Specifies the due-out time of day for the network workstations on this schedule ID.
Limits: 4 numeric characters specified as hhmm, where hh can be 00 through 24
and mm can be 00 through 59
Required for ADD or REPL functions.
Optional for DELETE, EXIT, FORMAT, LIST, SAVE, SR, and SS functions.
Batch keyword: TIME
Note for batch input: The following format must be used, where the numeric value
(or n) corresponds to the number of the station.
TIME=(dotm1,ldtm1,dody1,dotm2,ldtm2,dody2,...,dotmn,ldtmn,dodyn)

DOTM is used to dynamically calculate the actual due-out time for the network
when it is brought into the queue. If the JOB field of the DB.5 panel definition
matches the job name to which the network is connected, these values are used as
the actual due-out times and no adjustments are made. If the job's DOTM is greater
than the network's DOTM, the network DOTM is incremented by 24 hours (that is,
the next day).
If the job name field of the network definition does not match the job name to
which the network is connected, the actual due-out time for the stations in the
network is calculated as follows:
Station# 1
x+y(1)
Station# 2
x+y(2)+DOTM(2)-DOTM(1)
Station# 3
x+y(3)+DOTM(3)-DOTM(1)
--- ---
x=Job's DOTM+network connection LDTM+LDTM(1)
y=DODY*2400 to calculate the day displacement.

Chapter 3: Scheduling Work 121

Schedule Definition

LDTM
Specifies the lead time for this schedule ID. This is the amount of elapsed time
necessary to ensure that the network completes its task before its scheduled
due-out time.
Limits: 4 numeric characters specified as hhmm, where hh can be 00 through 24
and mm can be 00 through 59
Required: Yes - for ADD or REPL functions
No - for DELETE, EXIT, FORMAT, LIST, SAVE, SR, and SS functions
Batch keyword: TIME
DODY
Specifies the due-out day for this workstation in the network, relative to the
due-out time for the job to which the network is connected.
Default: 0
Limits: 1 to 4 numeric characters from 0 through 255
Required: Yes (if the elapsed time between workstations in a network causes the
schedule to roll over any midnight boundary)
Batch keyword: TIME
SCHID-COUNT
Identifies a system-generated field containing the current schedule ID count for this
network.

Example: Batch Input

This batch input example adds schedule ID 1 for output network TESTOTNW. Because
this network is an output network, no calendar or frequency data are permitted. This
network has two stations where the first station has a due-out time of 0800 with a lead
time of one hour. The second station has a due-out time of 0900 with a lead time of 30
minutes.

DBM
SCHD
ONWK
EDIT,NETWORK=TSTONWK2
ADD,SCHID=1,TIME=(0800,0100,,0900,0030)
SAVE
SAVE,NETWORK=TSTONWK2

122 Database Maintenance Guide

 Schedule Definition

Trigger Scheduling Panels

The database elements that can trigger the scheduling of a job are jobs, data sets, and
input networks. The topics that follow identify the different types corresponding to
these elements, their keywords, and how they cause triggering.

Note: All trigger commands share common field requirements.

Uniqueness of the trigger relationship is determined by the triggering element,

triggered job name, and schedule ID. When a triggering element is successfully
completed/created, the triggered job (TRGD-JOB) enters the request queue. The
TRGD-JOB assumes the schedule ID of the triggering element unless TRGID is specified,
in which case the schedule ID is replaced by TRGID.

Up to 255 job name/schedule ID combinations can be triggered per triggering element,

or one job can be triggered by up to 255 elements.

DB.2.4 - Job Triggering Panel

The DB.2.4 - Job Triggering panel lets you review or define jobs that trigger scheduling of
other jobs when they successfully complete.

To display the panel, enter:

■ 4 as the FUNCTION on the DB.2 Menu panel.
■ 2.4 as the FUNCTION on the DB Menu panel.
■ DB.2.4 as the FUNCTION on any other menu or formatted input panel.
■ DB.2.4 or SCHD,JTRG as a top line command.

To exit the panel:

■ Press PF3 to return to the DB.2 Menu panel except with the TSO/ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

Use the JOB field to define the triggering job.

Other keyword descriptions are the same as the DB.2.6 – Data Set Triggering panel.

Chapter 3: Scheduling Work 123

Schedule Definition

--------------------------- CA-7 JOB TRIGGERING ----------------------------

FUNCTION: xxxxxxxx (FORMAT,LIST,UPD) PAGE nnnn
JOB: xxxxxxxx
OPT SCHID TRGD-JOB TRGID DOTM QTM LDTM SBTM *---- EXCEPTIONS ----*
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
OPTIONS: A=ADD,D=DELETE,U=UPDATE,*=PROCESSED,?=ERROR
PROGRAM: SM75 MSG-INDX: nn -- DB.2.4 -- yy.ddd / hh:mm:ss
MESSAGE:

More information:

DB.2.6 - Data Set Triggering Panel (see page 128)

DB.2.4L - Job Triggering Panel (Long Job Name)

The DB.2.4L - Job Triggering panel lets you review or define jobs that trigger scheduling
of other jobs when they successfully complete using the long job name.

To display the panel, enter:

■ 4L as the FUNCTION on the DB.2 Menu panel.
■ 2.4L as the FUNCTION on the DB Menu panel.
■ DB.2.4L as the FUNCTION on any other menu or formatted input panel.
■ DB.2.4L or SCHD,JTRGL as a top line command.

124 Database Maintenance Guide

 Schedule Definition

To exit the panel:

■ Press PF3 to return to the DB.2 Menu panel except with the TSO/ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

Use the JOB/L field to define the triggering job.

Other keyword descriptions are the same as the DB.2.6L – Data Set Triggering (Long Job
Names) panel.

--------------------------- CA-7 JOB TRIGGERING ----------------------------

FUNCTION: xxxxxxxx (FORMAT,LIST,UPD) PAGE 0001
JOB/L: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
OPT SCHID --TRGD-JOBL-- /TRGID DOTM QTM LDTM SBTM *---- EXCEPTIONS ----*
x xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxx xxxx xxxx xxxx xxxx
x xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxx xxxx xxxx xxxx xxxx
x xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxx xxxx xxxx xxxx xxxx
x xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxx xxxx xxxx xxxx xxxx
x xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxx xxxx xxxx xxxx xxxx
x xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxx xxxx xxxx xxxx xxxx
x xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxx xxxx xxxx xxxx xxxx

OPTIONS: A=ADD,D=DELETE,U=UPDATE,*=PROCESSED,?=ERROR
PROGRAM: SM75 MSG-INDX: 00 -- DB.2.4L -- yy.ddd / hh:mm:ss
MESSAGE: ENTER FUNCTION, TRANSFER OR ENTER A COMMAND ON THE TOP LINE

More information:

DB.2.6L - Data Set Triggering Panel (Long Job Names) (see page 134)

Chapter 3: Scheduling Work 125

Schedule Definition

DB.2.5 - Input Network Triggering Panel

The DB.2.5 - Input Network Triggering panel lets you define or review input networks
that trigger job scheduling when their last workstation is logged out.

To display the panel, enter:

■ 5 as the FUNCTION on the DB.2 Menu panel.
■ 2.5 as the FUNCTION on the DB Menu panel.
■ DB.2.5 as the FUNCTION on any other menu or formatted input panel.
■ DB.2.5 or SCHD,NTRG as a top line command.

To exit the panel:

■ Press PF3 to return to the DB.2 Menu panel except with the TSO/ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

Use the NWK keyword field to define the triggering input network.

Other keyword descriptions are the same as DB.2.6 – Data Set Triggering Panel.

---------------------- CA-7 INPUT NETWORK TRIGGERING -----------------------

FUNCTION: xxxxxxxx (FORMAT,LIST,UPD) PAGE nnnn
NWK: xxxxxxxx
OPT SCHID TRGD-JOB TRGID DOTM QTM LDTM SBTM *---- EXCEPTIONS ----*
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
OPTIONS: A=ADD,D=DELETE,U=UPDATE,*=PROCESSED,?=ERROR
PROGRAM: SM75 MSG-INDX: nn -- DB.2.5 -- yy.ddd / hh:mm:ss
MESSAGE:

More information:

DB.2.6 - Data Set Triggering Panel (see page 128)

126 Database Maintenance Guide

 Schedule Definition

DB.2.5L- Input Network Triggering Panel (Long Job Names)

The DB.2.5L - Input Network Triggering panel lets you define or review input networks
that trigger job scheduling when their last workstation is logged out based on long job
names.

To display the panel, enter:

■ 5L as the FUNCTION on the DB.2 Menu panel.
■ 2.5L as the FUNCTION on the DB Menu panel.
■ DB.2.5L as the FUNCTION on any other menu or formatted input panel.
■ DB.2.5L or SCHD,NTRGL as a top line command.

To exit the panel:

■ Press PF3 to return to the DB.2 Menu panel except with the TSO/ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

Use the NWK field to define the triggering input network.

The other keyword descriptions are the same as DB.2.6L – Data Set Triggering Panel.

---------------------- CA-7 INPUT NETWORK TRIGGERING -----------------------

FUNCTION: xxxxxxxx (FORMAT,LIST,UPD) PAGE 0001
NWK: xxxxxxxx
OPT SCHID --TRGD-JOBL-- /TRGID DOTM QTM LDTM SBTM *---- EXCEPTIONS ----*
x xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxx xxxx xxxx xxxx xxxx
x xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxx xxxx xxxx xxxx xxxx
x xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxx xxxx xxxx xxxx xxxx
x xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxx xxxx xxxx xxxx xxxx
x xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxx xxxx xxxx xxxx xxxx
x xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxx xxxx xxxx xxxx xxxx
x xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxx xxxx xxxx xxxx xxxx

OPTIONS: A=ADD,D=DELETE,U=UPDATE,*=PROCESSED,?=ERROR
PROGRAM: SM75 MSG-INDX: 00 -- DB.2.5L -- yy.ddd / hh:mm:ss
MESSAGE: ENTER FUNCTION, TRANSFER OR ENTER A COMMAND ON THE TOP LINE

More information:

DB.2.6L - Data Set Triggering Panel (Long Job Names) (see page 134)

Chapter 3: Scheduling Work 127

Schedule Definition

DB.2.6 - Data Set Triggering Panel

The DB.2.6 - Data Set Triggering panel lets you define or review data sets that trigger job
scheduling when either their creating jobs complete successfully or when the
created/updated data set is closed. This function is related to the POST AT CLOSE TIME
field on the DB.6 – Data Set Definition Panel.

To display the panel, enter:

■ 6 as the FUNCTION on the DB.2 Menu panel.
■ 2.6 as the FUNCTION on the DB Menu panel.
■ DB.2.6 as the FUNCTION on any other menu or formatted input panel.
■ DB.2.6 or SCHD,DTRG as a top line command.

To exit the panel:

■ Press PF3 to return to the DB.2 Menu panel except with the TSO/ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

Use the DSN, the DSNBR, or both keywords to define the triggering data set.

Partitioned data sets (PDS) cannot be used as data set triggers.

------------------------- CA-7 DATA SET TRIGGERING -------------------------

FUNCTION: xxxxxxxx (FORMAT,LIST,UPD) PAGE nnnn
DSN: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DSNBR: nnnnnnnn
OPT SCHID TRGD-JOB TRGID DOTM QTM LDTM SBTM *---- EXCEPTIONS ----*
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
x nnn xxxxxxxx nnn hhmm hhmm hhmm hhmm xxxxxxxxxxxxxxxxxxxxxx
OPTIONS: A=ADD,D=DELETE,U=UPDATE,*=PROCESSED,?=ERROR
PROGRAM: SM75 MSG-INDX: nn -- DB.2.6 -- yy.ddd / hh:mm:ss
MESSAGE:

128 Database Maintenance Guide

 Schedule Definition

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following:
FORMAT
Clears the panel of user input data.
LIST
Lists the job names and schedule IDs for the triggering element. In batch, a
formatted panel is not listed; only a found or not found message is returned. In
batch, you must explicitly specify a SCHID and TJOB in the input command.
UPD
Performs updating option indicated by OPT parameter below. Do a LIST
function before an online UPD.
Batch keyword: Positional parameter
n/a
Contains a constant value depending on the triggering element, either JTRG, DTRG,
or NTRG for job, data set, or network respectively.
Limits: Required for batch only.
Batch keyword: Positional parameter
JOB
Specifies the job name whose successful completion causes triggering.
Limits: 1 to 8 alphanumeric characters and required for job triggers.
Batch keyword: JOB
DSN
Specifies the data set name whose creation/update causes triggering of a job.
Note: For VSAM files, the cluster name should be specified.
Limits: 1 to 44 alphanumeric characters and required for data set triggers unless
DSNBR is entered.
Batch keyword: DSN
NWK
Specifies the input network name whose completion causes triggering.
Limits: 1 to 8 alphanumeric characters and required for network triggers.
Batch keyword: NWK

Chapter 3: Scheduling Work 129

Schedule Definition

DSNBR
Specifies the existing data set number whose creation causes triggering. It is the
value assigned to the data set by CA WA CA 7 Edition.
Limits:1 to 8 numeric characters for data set triggers
Required for data set triggers unless DSN is entered.
Batch keyword: DSNBR
OPT
(Optional) Used with the UPD function, denotes the operation to perform. Valid
codes are A (add), D (delete), and U (update).
Batch keyword: OPT
SCHID
(Optional) Specifies for which schedule ID of the triggering element the TRGD-JOB is
to be scheduled.
Default: 0 (all schedule IDs)
Limits: 1 to 3 numeric characters from 0 through 999. This field is not valid with
OPT=U.
Batch keyword: SCHID
Note: For the data set trigger panel where the data set is one that is tracked with
use of SASSXDSN (externally tracked data sets), the SCHID field must be 000 for the
trigger to work.
TRGD-JOB
Specifies the job name that is to be triggered by the completion/creation of the
triggering element.
Limits: 1 to 8 alphanumeric characters. This field is not valid with OPT=U.
Batch keyword: TJOB

130 Database Maintenance Guide

 Schedule Definition

TRGID
(Optional) Denotes a replacement schedule ID to use when the TRGD-JOB is placed
into the request queue.
Default: 0 (no replacement)
Limits: 1 to 3 numeric characters from 0 through 999
Batch keyword: TRGID
Note: If TRGID is used, it replaces the SCHID value of the triggered element. Any
jobs triggered (by TRGD-JOB or data sets it creates) use this TRGID for their
schedule ID unless they also have a TRGID value.
Example:
This field is useful to avoid a loop in a situation where a job is both triggered by and
triggers the same job. For example, assume that JOBX is a backup job that needs to
be run after the online system comes down. It triggers JOBY, an update job that
further updates the database. JOBY then triggers JOBX again to get another backup.
When you define the second occurrence of JOBX as being triggered by JOBY, use
TRGID 2 so that this occurrence of JOBX will not trigger JOBY again.
DOTM
Specifies the due-out time of day of TRGD-JOB rounded down to ten minute
increments. If this field is used, QTM must be omitted.
Note: If used and the triggering job's DOTM is after the triggered job's DOTM, CA
WA CA 7 Edition assumes the following calendar day.
Limits: 4 numeric characters specified as hhmm, where hh can be 00 through 24
and mm can be 00 through 59, the highest value being 2400. If specified, the lowest
value is 10.
Required only if QTM omitted.
Batch keyword: DOTM
QTM
Specifies the elapsed queue time of TRGD-JOB rounded down to ten minute
increments. If this field is used, DOTM must be omitted because due-out time is
then calculated as deadline time plus runtime, where deadline time is calculated as
current date/time plus queue time.
Note: Either DOTM or QTM must be used.
Limits: 4 numeric characters specified as hhmm, where hh can be 00 through 24
and mm can be 00 through 59, the highest value being 2400
Required only if DOTM omitted
Batch keyword: QTM

Chapter 3: Scheduling Work 131

Schedule Definition

LDTM
(Optional) Specifies the elapsed lead time for TRGD-JOB rounded to ten minute
increments. This field specifies the lead or processing time necessary to ensure that
TRGD-JOB meets its due-out time.
Default: 0000
Limits: 4 numeric characters specified as hhmm, where hh can be 00 through 24
and mm can be 00 through 59, the highest value being 2400.
Batch keyword: LEADTM
SBTM
(Optional) Imposes a submit time of day requirement on TRGD-JOB. When used, the
job is not submitted before this time. SBTM is always rounded down to 15 minute
increments.
Note: If QTM is used, the date for the submit time requirement will be the same as
the deadline start date. If DOTM is used and the SBTM is less than the DOTM, the
date for the SBTM is the same as the deadline start date. Otherwise, the SBTM date
is the previous day.
Default: 0 (no specific submit time requirement)
Limits: 4 numeric characters specified as hhmm, where hh can be 00 through 24
and mm can be 00 through 59, the highest value being 2400.
Batch keyword: SBTM
EXCEPTIONS
Indicates an informational only field. Brief messages (see page 132) appear here
when an exception occurs trying to process the entry on this line.
Batch keyword: Not applicable

Exceptions Messages

The exception messages that can appear and their meanings are as follows:
DOTM/QTM CONFLICT
Only one of these fields can be specified.
ERROR FROM modulename
Internal logic error. Contact your installation specialist for assistance.
INVALID VALUE fieldname
The value for the indicated field is not valid.

132 Database Maintenance Guide

 Schedule Definition

MORE THAN 255 TRIGGERS

Each object (job, data set, network) can have up to 255 trigger definitions.
NO ROOM IN DATABASE
The database is full. Contact your installation specialist for assistance.
NON-ZERO SCHID EXISTS
The trigger is already defined for a non-zero schedule ID. Adding a trigger with
a schedule ID of zero (all schedule IDs) is not permitted.
SCHID 0 ALREADY EXISTS
Trigger is already defined for schedule ID zero that applies to all schedule IDs.
SECURITY EXCEPTION
You are not authorized to access that job.
TOO HIGH FOR fieldname
The numeric value for the indicated field exceeds the maximum limit.
TOO LOW FOR fieldname
The numeric value does not meet a valid range.
TRGD-JOB ACCESS ERROR
An I/O error occurred while reading the triggered job from the database.
TRGD-JOB NOT FOUND
The triggered job is not defined in the database.
TRIGGER ALREADY EXISTS
Trigger is already defined for this schedule ID.
WARNING TRIGGER LOOP
Job is triggering itself. This message is only a warning, and the database is
updated.

Example: Batch Input

This batch input example defines a trigger schedule from job CA07XX03 to job
CA07XX05 with a queue time of one hour and a lead time of 30 minutes.

SCHD
TRGR
UPD,JTRG,OPT=A,JOB=CA07XX03,TJOB=CA07XX05,
LEADTM=0030,QTM=0100
DBM

Chapter 3: Scheduling Work 133

Schedule Definition

DB.2.6L - Data Set Triggering Panel (Long Job Names)

The DB.2.6 - Data Set Triggering panel lets you define or review data sets that trigger job
scheduling when either their creating jobs complete successfully or when the
created/updated data set is closed using long job names. This function is related to the
POST AT CLOSE TIME field on the DB.6 – Data Set Definition Panel.

To display the panel, enter:

■ 6L as the FUNCTION on the DB.2 Menu panel.
■ 2.6L as the FUNCTION on the DB Menu panel.
■ DB.2.6L as the FUNCTION on any other menu or formatted input panel.
■ DB.2.6L or SCHD,DTRGL as a top line command.

To exit the panel:

■ Press PF3 to return to the DB.2 Menu panel except with the TSO/ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

Use the DSN, the DSNBR, or both keywords to define the triggering data set.

Partitioned data sets (PDS) cannot be used as data set triggers.

------------------------- CA-7 DATA SET TRIGGERING -------------------------

FUNCTION: xxxxxxxx (FORMAT,LIST,UPD) PAGE 0001
DSN: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DSNBR: xxxxxxxxx
OPT SCHID --TRGD-JOBL-- /TRGID DOTM QTM LDTM SBTM *---- EXCEPTIONS ----*
x xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxx xxxx xxxx xxxx xxxx
x xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxx xxxx xxxx xxxx xxxx
x xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxx xxxx xxxx xxxx xxxx
x xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxx xxxx xxxx xxxx xxxx
x xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxx xxxx xxxx xxxx xxxx
x xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxx xxxx xxxx xxxx xxxx
x xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxx xxxx xxxx xxxx xxxx

OPTIONS: A=ADD,D=DELETE,U=UPDATE,*=PROCESSED,?=ERROR
PROGRAM: SM75 MSG-INDX: 00 -- DB.2.6L -- yy.ddd / hh:mm:ss
MESSAGE: ENTER FUNCTION, TRANSFER OR ENTER A COMMAND ON THE TOP LINE

134 Database Maintenance Guide

 Schedule Definition

This panel contains the following fields:

FUNCTION
Specifies the function to perform. The value must be the name of some other panel
or one of the following values:
FORMAT
Clears the panel of user input data.
LIST
Lists the job names and schedule IDs for the triggering element. In batch, a
formatted panel is not listed; only a found or not found message is returned. In
batch, you must explicitly specify a SCHID and TJOB in the input command.
UPD
Performs updating the option that the following OPT parameter indicates. Do a
LIST function before an online UPD.
Batch keyword: Positional parameter
n/a
Contains a constant value depending on the triggering element, either JTRGL,
DTRGL, or NTRGL for job, data set, or network respectively.
Limits: Required for batch only.
Batch keyword: Positional parameter
JOB/L
Specifies the job name or long job name whose successful completion causes
triggering.
Limits: 1 to 64 alphanumeric characters and required for job triggers.
Batch keyword: JOBL
DSN
Specifies the data set name whose creation or update causes triggering of a job.
Note: For VSAM files, specify the cluster name.
Limits: 1 to 44 alphanumeric characters and required for data set triggers unless
DSNBR is entered.
Batch keyword: DSN
NWK
Specifies the input network name whose completion causes triggering.
Limits: 1 to 8 alphanumeric characters and required for network triggers.
Batch keyword: NWK

Chapter 3: Scheduling Work 135

Schedule Definition

DSNBR
Specifies the existing data set number whose creation causes triggering. It is the
value assigned to the data set by CA WA CA 7 Edition.
Limits: 1 to 8 numeric characters and required for data set triggers unless DSN is
entered.
Batch keyword: DSNBR
OPT
(Optional) Used with the UPD function, denotes the operation to perform. The valid
codes are A (add), D (delete), and U (update).
Batch keyword: OPTL
SCHID
(Optional) Specifies for which schedule ID of the triggering element the TRGD-JOB is
to be scheduled.
Default: 0 (all schedule IDs)
Limits: 1 to 3 numeric characters from 0 through 999. This field is not valid with
OPT=U.
Batch keyword: SCHIDL
Note: For the data set trigger panel where the data set is one that is tracked with
use of SASSXDSN (externally tracked data sets), the SCHID field must be 000 for the
trigger to work.
TRGD-JOBL
Specifies the job name or long job name that is to be triggered by the
completion/creation of the triggering element. If a short job name is used, it is
replaced with the long job name at the completion of the function.
Limits: 1 to 64 alphanumeric characters. This field is not valid with OPT=U.
Batch keyword: TJOBL

136 Database Maintenance Guide

 Schedule Definition

TRGID
(Optional) Denotes a replacement schedule ID to use when the TRGD-JOBL is placed
into the request queue.
Default: 0 (no replacement)
Limits: 1 to 3 numeric characters from 0 through 999
Batch keyword: TRGIDL
Note: If TRGID is used, it replaces the SCHID value of the triggered element. Any
jobs triggered (by TRGD-JOB or data sets it creates) use this TRGID for their
schedule ID unless they also have a TRGID value.
Example:
This field is useful to avoid a loop in a situation where a job is both triggered by and
triggers the same job. For example, assume that JOBX is a backup job that needs to
be run after the online system comes down. It triggers JOBY, an update job that
further updates the database. JOBY then triggers JOBX again to get another backup.
When you define the second occurrence of JOBX as being triggered by JOBY, use
TRGID 2 so that this occurrence of JOBX will not trigger JOBY again.
DOTM
Specifies the due-out time of day of TRGD-JOBL rounded down to ten-minute
increments. If this field is used, QTM must be omitted.
Note: If used and the triggering job's DOTM is after the triggered job's DOTM, CA
WA CA 7 Edition assumes the following calendar day.
Limits: 4 numeric characters specified as hhmm, where hh can be 00 through 24
and mm can be 00 through 59, the highest value being 2400. If specified, the lowest
value is 10.
Required only if QTM omitted.
Batch keyword: DOTML
QTM
Specifies the elapsed queue time of TRGD-JOBL rounded down to ten minute
increments. If this field is used, DOTM must be omitted because due-out time is
then calculated as deadline time plus runtime, where deadline time is calculated as
current date/time plus queue time.
Note: Either DOTM or QTM must be used.
Limits: 4 numeric characters specified as hhmm, where hh can be 00 through 24
and mm can be 00 through 59, the highest value being 2400
Required only if DOTM omitted
Batch keyword: QTML

Chapter 3: Scheduling Work 137

Schedule Definition

LDTM
(Optional) Specifies the elapsed lead time for TRGD-JOBL rounded to ten minute
increments. This field specifies the lead or processing time necessary to ensure that
TRGD-JOB meets its due-out time.
Default: 0000
Limits: 4 numeric characters specified as hhmm, where hh can be 00 through 24
and mm can be 00 through 59, the highest value being 2400.
Batch keyword: LEADTML
SBTM
(Optional) Imposes a submit time of day requirement on TRGD-JOBL. When used,
the job is not submitted before this time. SBTM is always rounded down to 15
minute increments.
Note: If QTM is used, the date for the submit time requirement is the same as the
deadline start date. If DOTM is used and the SBTM is less than the DOTM, the date
for the SBTM is the same as the deadline start date. Otherwise, the SBTM date is
the previous day.
Default: 0 (no specific submit time requirement)
Limits: 4 numeric characters specified as hhmm, where hh can be 00 through 24
and mm can be 00 through 59, the highest value being 2400.
Batch keyword: SBTML
EXCEPTIONS
Indicates an informational only field. Brief messages (see page 132) appear here
when an exception occurs trying to process the entry on this line.
Batch keyword: Not applicable

Example: Batch Input

This batch input example defines a trigger schedule from job LongJobNameA to job
LongJobNameB with a queue time of one hour and a lead time of 30 minutes.

SCHD
TRGR
UPD,JTRGL,OPTL=A,JOBL=LongJobNameA,TJOBL=LongJobNameB,
LEADTML=0030,QTML=0100
DBM

138 Database Maintenance Guide

 Schedule Definition

DB.2.7 - Modification to Resolved Schedule Dates Panel

The DB.2.7 - Modification to Resolved Schedule Dates panel lets you, with its rapid and
direct method, permanently alter the resolved schedule information for either a job or
input network without having to totally redefine the schedule. Such schedule
modifications can be made any time after the schedule has been resolved and are
effective immediately.

To display the panel, enter:

■ 7 as the FUNCTION on the DB.2 Menu panel.
■ 2.7 as the FUNCTION on the DB Menu panel.
■ DB.2.7 as the FUNCTION on any other menu or formatted input panel.
■ DB.2.7 or SCHDMOD as a top line command.

To exit the panel:

■ Press PF3 to return to the DB.2 Menu panel except with the TSO/ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

--------------- CA-7 MODIFICATION TO RESOLVED SCHEDULE DATES ---------------

FUNCTION: xxxxxxxx (FORMAT,LIST,UPD)
JOBL: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
JOB: xxxxxxxx NETWORK: xxxxxxxx MODSTAT: xxxxxxxx
SCHID: nnn YEAR: yyyy
1 1 2 2 3 3 LAST RESOLV: yy.ddd / hh:mm
....5....0 ....5....0 ....5....0 1
JAN nnnnnnnnnn nnnnnnnnnn nnnnnnnnnn n
FEB nnnnnnnnnn nnnnnnnnnn nnnnnnnnn
MAR nnnnnnnnnn nnnnnnnnnn nnnnnnnnnn n
APR nnnnnnnnnn nnnnnnnnnn nnnnnnnnnn
MAY nnnnnnnnnn nnnnnnnnnn nnnnnnnnnn n
JUN nnnnnnnnnn nnnnnnnnnn nnnnnnnnnn
JUL nnnnnnnnnn nnnnnnnnnn nnnnnnnnnn n
AUG nnnnnnnnnn nnnnnnnnnn nnnnnnnnnn n
SEP nnnnnnnnnn nnnnnnnnnn nnnnnnnnnn
OCT nnnnnnnnnn nnnnnnnnnn nnnnnnnnnn n
NOV nnnnnnnnnn nnnnnnnnnn nnnnnnnnnn
DEC nnnnnnnnnn nnnnnnnnnn nnnnnnnnnn n

PROGRAM: SM80 MSG-INDX: nn -- DB.2.7 -- yy.ddd / hh:mm:ss

MESSAGE:

Chapter 3: Scheduling Work 139

Schedule Definition

This panel contains the following fields:

Note: DB.2.7 has no batch keywords because this is an online only function.
FUNCTION
The function to perform. Value must be the name of some other panel or one of the
following:
FORMAT
Clears the panel of user input data.
LIST
Lists schedule information from the database.
UPD
Updates existing schedule information in the database using the panel values
for processing days.
JOBL
(Optional) Defines the long job name on which to perform the indicated function.
Limits: 1 to 64 alphanumeric characters, case sensitive. If this field is used, omit
NETWORK.
JOB
(Optional) Defines the job name for which you want to list or alter schedule
information.
Limits: 1 to 8 alphanumeric characters. If this field is used, omit NETWORK.
NETWORK
(Optional) Defines the name of an input network for which you want to list or alter
schedule information.
Limits: 1 to 8 alphanumeric characters. If this field is used, omit JOB and JOBL.
MODSTAT
(Optional) Specifies the status of modifications that are made to the schedule. The
following values are valid:
Blanks
Specifies that no changes have been made to this schedule because the last
RESOLV was done.

140 Database Maintenance Guide

 Schedule Definition

CURRENT
Specifies at least one modification to the schedule ID shown had been made
previously with this panel and is still in effect.
OVERLAID
Specifies at least one modification had been made previously with this panel,
but a subsequent RESOLV for the schedule overlaid the modification that had
been made without changing the schedule.
Default: Blanks
SCHID
Specifies which schedule ID of the job or network to list or update.
Limits: 1 to 3 numeric characters
YEAR
Specifies the calendar year for the first month of the schedule displayed.
LAST RESOLV
Specifies the date and time of the last RESOLV of the schedule displayed.
JAN thru DEC
(Optional) Specifies the run and nonrun Julian days of the job or network for the
month indicated. Any scheduled day (1) can be changed to a nonscheduled day (0),
or vice versa, with the UPD function. This can be easily accomplished with a LIST
followed by a UPD. Schedule Resolution negates these changes.
1
Specifies the days on which work is done, a scheduled day.
0
Specifies the days on which work is not done, a nonscheduled day.
Note: If the schedule ID being reviewed was resolved on a July through June basis
instead of a January through December basis, the month titles show JUL through
DEC followed by JAN through JUN.

Chapter 3: Scheduling Work 141

Schedule Definition

Usage Notes

Unlike other DB functions, DB.2.7 is only available as an online function.

Once displayed, you can change the values as necessary to accomplish the wanted
changes.

If you update a job schedule, you can use both the JOB and JOBL fields simultaneously.
They must refer to the same job. A discrepancy causes an error message.

Note: If schedule scan has already brought the job into the queue and the schedule has
been adjusted for the day, the DB.2.7 changes do not take effect for that day.

DB.2.8 - Base Calendar Maintenance Panel

The DB.2.8 - Base Calendar Maintenance panel lets you list, add, update, and delete the
base calendars. New and updated calendars are immediately available to other
functions, such as Resolve, without the need for a SCAL statement in the initialization
file.

To use the online base calendar maintenance, define the calendar PDS to CA WA CA 7
Edition through the CALENDAR statement in the initialization file.

Note: For more information about the CALENDAR statement, see the Systems
Programming Guide.

To display the panel, enter:

■ 8 as the FUNCTION on the DB.2 Menu panel.
■ 2.8 as the FUNCTION on the DB Menu panel.
■ DB.2.8 as the FUNCTION on any other menu or formatted input panel.
■ DB.2.8 or CALMOD as a top line command.

To exit the panel:

■ Press PF3 to return to the DB.2 Menu panel except with the TSO/ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

142 Database Maintenance Guide

 Schedule Definition

---------------------- CA-7 BASE CALENDAR MAINTENANCE ----------------------

FUNCTION: xxxxxxxx (FORMAT,LIST,ADD,UPD,DELETE,REFRESH)
CALENDAR: xxxxxxxx SCHONLY: x YEAR: nn

1 1 2 2 3
....5....0....5....0....5....01 BEGIN END
JAN nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 01 / 01 01 / 31
FEB nnnnnnnnnnnnnnnnnnnnnnnnnnnnn 02 / 01 02 / 28
MAR nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 03 / 01 03 / 31
APR nnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 04 / 01 04 / 30
MAY nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 05 / 01 05 / 31
JUN nnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 06 / 01 06 / 30
JUL nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 07 / 01 07 / 31
AUG nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 08 / 01 08 / 31
SEP nnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 09 / 01 09 / 30
OCT nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 10 / 01 10 / 31
NOV nnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 11 / 01 11 / 30
DEC nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 12 / 01 12 / 31

PROGRAM: SM85 MSG-INDX: nn -- DB.2.8 -- yy.ddd / hh:mm:ss

MESSAGE:

This panel contains the following fields:

Note: DB.2.8 has no batch keywords because this function is an online only function.
FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following:
FORMAT
Clears the panel of user input data.
LIST
Lists data for the calendar that is specified in the CALENDAR field.
ADD
Adds the calendar that is displayed. The YEAR field is required if the calendar
name is not in standard SCALyyxx format.

Chapter 3: Scheduling Work 143

Schedule Definition

UPD
Updates the calendar displayed. Any changes made to the calendar take effect
immediately. That is, if you update a calendar and then do a RESOLVe against a
job using that calendar, the updated version of the calendar is used. The YEAR
field is required if the calendar name is not in standard SCALyyxx format.
DELETE
Deletes the calendar that is specified in the CALENDAR field. The copy of the
calendar that is saved in the calendar PDS is deleted. The delete function has
no effect on calendars that reside in load libraries.
REFRESH
Fetches the load module copy of the calendar that is specified in the CALENDAR
field and uses it to replace the copy in the CA WA CA 7 Edition calendar PDS.
CALENDAR
Specifies the name of the CA WA CA 7 Edition calendar you want to act on. For CA
WA CA 7 Edition to use a calendar for resolving job/network schedules, the name
must be in the format SCALyyxx. The yy is the last two digits of the year it
represents, and xx is a two-position suffix to identify the calendar uniquely. You can
create and save calendars under other names to use as models or templates for the
creation of other calendars, but CA WA CA 7 Edition processes only names in the
SCALyyxx format.
Limits: 1 to 8 alphanumeric characters
SCHONLY
(Optional) If Y (YES) is specified, CA WA CA 7 Edition counts only available
processing days when resolving a schedule with a number of days relative to the
beginning or end of the month (RDAY). The RDAY is set on the DB.2.1 panel.
If SCHONLY is set to N (NO), CA WA CA 7 Edition counts all days when calculating
days relative to the beginning or end of the month.
Default: N (NO)
YEAR
Specifies the year that the calendar represents. When using the standard CA WA CA
7 Edition calendar naming convention (SCALyyxx), the YEAR should match positions
5 and 6 of the calendar name.
Limits: 2 numeric characters
Required: Yes - for ADD or UPD functions if the calendar name is not in standard
SCALyyxx format

144 Database Maintenance Guide

 Schedule Definition

DAYS OF THE MONTH

Represents each month by a string of zeros and ones. Each digit represents a
particular day of that month. If the digit for a day is 1 (one), it indicates that it is a
processing day. If the digit is 0 (zero), it indicates that it is not a processing day. The
number of digits in an individual string should represent the number of days in that
calendar month.
Required: Yes - for ADD or UPD functions
BEGIN and END
Specifies the beginning and ending days of that month for each month. Use this
field when the calendar being defined has nonstandard months. For example, a
fiscal or accounting calendar. A year-end boundary can only be crossed in the first
or twelfth month.
Required: Yes - for ADD or UPD functions

More information:

DB.2.1 - Job Scheduling Panel (see page 87)

Usage Notes
■ DB.2.8 is only available as an online function.
■ To use online base calendar maintenance, the CA WA CA 7 Edition calendar PDS
must be defined to CA WA CA 7 Edition through the CALENDAR statement in the CA
WA CA 7 Edition initialization file (see the Systems Programming Guide).
■ Base calendars are automatically added to the CA WA CA 7 Edition calendar PDS
when:
– A CALBLK statement is included in the CA WA CA 7 Edition initialization file and
the load module copy exists but the PDS has no copy.
– A reference is made to a base calendar and the PDS has no copy, the load
module does not exist, but the corresponding PCALYYxx member does exist in
the PCDSN.
– An ADD function is performed from the online base calendar maintenance
facility.

Chapter 3: Scheduling Work 145

Schedule Definition

■ If you have assembled and link edited a new copy of a calendar and want to
propagate it to the CA WA CA 7 Edition calendar PDS, use the REFRESH function.
This replaces the existing copy in the CA WA CA 7 Edition calendar PDS with a new
converted copy of the load library version.
■ If you have modified the perpetual calendar criteria of an existing calendar, and
want to regenerate the calendar with the new criteria, use the REFRESH function.
This function replaces the current calendar with a calendar generated from the
updated criteria. Be aware that if an assembled and link edited version of this
calendar exists in the load library, the assembled and link edited version is used.
■ Base calendars that reside in the CA WA CA 7 Edition calendar PDS do not require a
CALBLK statement in the CA WA CA 7 Edition initialization file.
■ Calendars with nonstandard names can be created using the online base calendar
maintenance facility and used as patterns or models to create standard base
calendars. All calendars stored in the CA WA CA 7 Edition calendar PDS must have
valid PDS member names (one to eight characters starting with an alpha or national
character).
■ The DELETE function removes the specified calendar from the CA WA CA 7 Edition
calendar PDS ONLY. It has no effect on a load module copy of the same calendar.
■ To list all calendar names in the CA WA CA 7 Edition calendar PDS, issue the
following topline command:
LISTDIR,DSN=*SCAL*

146 Database Maintenance Guide

Chapter 4: Defining Requirements
This section describes how CA WA CA 7 Edition determines requirements from JCL, how
to define and maintain job requirements, and how requirements are satisfied.

This section contains the following topics:

Execution Requirements and the LOAD Process (see page 147)
Satisfy Requirements (see page 150)
Predecessor and Successor Definition (see page 151)

Execution Requirements and the LOAD Process

This topic discusses dependence definition, database definitions, data set dependencies,
other dependencies, and temporary predecessors.

Dependence Definition
As work is defined in the CA WA CA 7 Edition database, dependencies (preexecution or
predecessor requirements) can be established so that work is not initiated until these
dependencies are satisfied.

Any job under the control of CA WA CA 7 Edition can have predecessor requirements.
CA WA CA 7 Edition does not submit the job until all requirements are satisfied even
though time scheduling criteria has been met.

The main categories of predecessor requirements are as follows:

■ Successful completion of predecessor jobs
■ Availability of data sets
■ Date/time window
■ Completion of an input network
■ Mutual exclusivity with other jobs
■ Specified manual activities such as JCL overrides and manual verifications
■ Presence of other jobs in the CA WA CA 7 Edition queues

Note: Jobs should not have more than 255 requirements.

Chapter 4: Defining Requirements 147

Execution Requirements and the LOAD Process

Database Definitions
This section discusses predecessor requirement database definitions for job, input
network, user requirement, and data set predecessors.

Also discussed are defining those output networks that must be invoked upon normal
completion of a job and defining report IDs that a job can produce.

Data Set Dependencies

Note: The LOAD process is not used with cross-platform jobs, because that job type
does not reference any data sets and has no steps. Thus, there should be no data set
dependencies for cross-platform jobs. Data set requirements can be used when a
cross-platform job must wait for a data set before being submitted for execution.

The LOAD process addresses the requirements that are associated with data set
availability. Based on JCL, the LOAD process determines if the job being LOADed uses or
creates a particular data set and updates the database accordingly. Data set
dependencies are established for the job for each data set that is input to the job.
Unless the dependent job is marked as a MAINT job on the DB.1 panel, it does not run
before any required data set is created.

Whenever a permanent change is made to the JCL, the job must go back through the
LOAD process that redefines the data set requirements for the job. LOAD is automatic if
the JCL is changed through the DB.7 panel.

The LOAD process neither determines nor changes requirements except those
associated with data set availability. If the job has requirements other than those
associated with data set availability that change, they must be specified through the
various DB.3 panel functions. The LOAD process does not delete any requirements that
were manually updated or added through a DB.3 panel. This means that data set name
changes require DB.3 updates to delete outdated references unless RENAME was used
on the DB.6 panel before LOAD occurred.

148 Database Maintenance Guide

 Execution Requirements and the LOAD Process

Other Dependencies
For a CPU job, the DB.1 panel contains fields such as HOLD, VERIFY, and JCL-OVRD. With
these fields, some predecessor requirements can be permanently defined for a job. Top
line commands HOLD, VERIFY, JCLOVRD, and ADDRQ are available for dynamically
defining predecessor requirements on a temporary basis. The QM.1 panel lets you
dynamically add some of these same predecessor requirements to jobs on a temporary
basis.

For internal cross-platform jobs, the DB.10 and DB.A.x panels contain the fields HOLD
and VERIFY. These fields permit the dynamic definition of predecessor requirements
once the job is in the request queue.

A job's JCL or PARM data can also include, on a scheduled basis if wanted, commands to
cause some of the same predecessor requirements to be applied to the job when the
job is scheduled into the queues. This is accomplished with a special set of commands
that are known as scheduled overrides. Based on how these overrides are scheduled,
they can be permanent or temporary without having been defined to the database.

More information:

Scheduled Overrides (see page 317)

Temporary Predecessors
The predecessor requirements are typically defined on a permanent basis. However,
occasionally it is necessary on a one-time basis to add new ones or skip existing ones
temporarily.

The DB.3 panels enable the temporary requirements with the NEXT-RUN facility. Any
such one-time definitions are automatically deleted from the database after a single
execution of the dependent job.

A job executing with any such temporary predecessors, either added or skipped, is
identified on LQ job inquiry output as executing with temporary requirements.
LJOB,LIST=RQMT, and so forth, also flag individual predecessors as SKIP or ONLY to
indicate when these settings exist. QM.2 update panels reflect the letter O to identify a
NEXT-RUN=ONLY predecessor. The letter A identifies one added through the ADDRQ top
line command. NEXT-RUN=SKIP predecessors do not appear on the QM.2 update panels
as they are skipped when the job enters the queue.

Chapter 4: Defining Requirements 149

Satisfy Requirements

Satisfy Requirements
The system examines all of a job's defined predecessor requirements each time the job
is scheduled. The system itemizes these requirements and establishes a total count of
the unsatisfied requirements for the job when it enters the request queue. As each
unsatisfied requirement is fulfilled, the count of the unsatisfied requirements is
decremented. This count is known as the master count and appears on many panels as
MCNT. When the count reaches zero, the job moves to the ready queue and then is
available for execution.

The outstanding requirements can be satisfied either manually or automatically. The

requirements that are automatically tracked and satisfied by the system are as follows:
■ Successful job completion of a predecessor job under the control of CA WA CA 7
Edition
■ Input network completion of a network connection
When the last workstation in an input network is logged complete by the
workstation operator, CA WA CA 7 Edition posts this network requirement as
complete for any dependent jobs.
■ Data set availability posting by the following items:
– SMF feedback
– Batch card load program (BLCP)
– Trailer step
– U7SVC
■ System date/time specifications

Most outstanding requirements needing manual intervention are related to the

following items:
■ User requirements
■ Manually prepared overrides
■ Manual verifications
■ Restart requirements
■ Hold requirements

These requirements must be posted by the POST command, QM.1 type panels, or other
top line commands such as the following:
■ SUBTM
■ VERIFY

150 Database Maintenance Guide

 Predecessor and Successor Definition

The QM.2 panel can be used to view the requirements of a job in the request queue.
The user can see both the outstanding and satisfied requirements for a job. The user can
also post and unpost requirements for a job by using this panel.

If the requirements for a job are predictable, they can lend themselves to use of special
trailer step job steps.

Note: For more information about external communicators, see the Interface Reference
Guide.

Effect of Time Zone Normalization

As stated in the previous topic, the successful job completion of a predecessor job under
the control of CA WA CA 7 Edition is one of the requirements that the system
automatically tracks and satisfies.

Without time zone normalization, or if you specify TZPREDS=EXEC on the SMF

initialization statement, the start and end times used to calculate this initial
requirement are the time zone where the job executed and the time zone where CA WA
CA 7 Edition is running.

With time zone normalization, if you specify TZPREDS=CA7 on the SMF initialization
statement, the job’s start and end times are normalized to the time zone where CA WA
CA 7 Edition is running.

For example, you have job JOBAAA, and you are specifying predecessor job JOBPPP.
When you specify job JOBPPP using panel DB.3.2, you can also enter lead time for that
job. This lead time (also known as look back time) specifies that since the last run of job
JOBAAA, JOBPPP has started and completed successfully within the last nn hours. Values
for nn range from 1 to 98.

For this example, the current time in New York is 1730 and in California it is 1430.
JOBAAA last ran in New York at 1615. The LEADTM specified for JOBPPP is 2. The
previous run of JOBPPP ran in California and ended at 1215.

Without time zone normalization, the difference between 1615 and 1215 is four hours
and the initial requirement is not satisfied. With time zone normalization, the
normalized end time for JOBPPP is now 1515 (New York time), and the difference is only
one hour. The initial requirement is satisfied.

Predecessor and Successor Definition

Use the DB.3n panels in the following topics to define predecessors and successors.

Chapter 4: Defining Requirements 151

Predecessor and Successor Definition

DB.3 - Job Predecessor/Successor Menu Panel

The DB.3 - Job Predecessor/Successor Menu panel lets you select various panels for
defining connections (predecessor requirements) to jobs.

To display the panel, enter:

■ 3 as the FUNCTION on the DB Menu panel.
■ DB.3 as the FUNCTION value on any other menu or formatted input panel.
■ DB.3 or JOBCONN as a top line command.

To exit the panel:

■ Press PF3 to return to the DB Menu panel except with the TSO-ISPF interface when
PF3 has been assigned to another function.
■ If some other function is wanted, enter the name of an online panel as the
FUNCTION value or move the cursor to the top line and enter a top line command.

Select the wanted function by entering the appropriate FUNCTION value and pressing
the Enter key.

------------------- CA-7 JOB PREDECESSOR/SUCCESSOR MENU -------------------

FUNCTION ===>

EXECUTION REQUIREMENTS DEFINED BY:

1 - DATA SET PREDECESSORS
2 - CPU JOB PREDECESSORS OR
MUTUALLY EXCLUSIVE JOBS (CAN NOT RUN AT SAME TIME)
4 - INPUT NETWORK PREDECESSORS OR
OUTPUT NETWORK SUCCESSORS
6 - USER MEMO-FORM PREDECESSORS

PROGRAM: SM60 MSG-INDX: 00 -- DB.3 -- yy.ddd / hh:mm:ss

MESSAGE: SPECIFY OPTION, TRANSFER OR ENTER A COMMAND ON THE TOP LINE

Note: The PAGE field in the following panels marks the page number of the data output.
New input from the user causes the resetting of this number.

152 Database Maintenance Guide

 Predecessor and Successor Definition

DB.3.1 - Data Set Predecessors Panel

For CPU jobs, data set requirements are initially set by CA WA CA 7 Edition at initial job
LOAD time. In other words, when a job runs for the first time, CA WA CA 7 Edition
automatically connects the job's input data sets as requirements when the job
completes. The top line LOAD command can also be issued to accomplish this.

The DB.3.1 - Data Set Predecessors panel lets you modify such requirements or to add
data set requirements for data sets that are not used as input for the job.

To display the panel, enter:

■ 1 as the FUNCTION on the DB.3 Menu panel.
■ 3.1 as the FUNCTION on the DB Menu panel.
■ DB.3.1 as the FUNCTION value on any other menu or formatted input panel.
■ DB.3.1 or JOBCONN,DSN as a top line command.

To exit the panel:

■ Press PF3 to return to the DB.3 Menu panel except with the TSO-ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

------------------------ CA-7 DATA SET PREDECESSORS ------------------------

FUNCTION: xxxxxxxx (FORMAT,LIST,UPD) PAGE nnnn
PRED FOR JOB: xxxxxxxx LIST-SCHID: nnn NEXT
OPT SCHID LEADTM *-------------- DATASET NAME --------------* DSNBR PERM -RUN
x nnn hhhh xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx nnnnnnn x xxxx
x nnn hhhh xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx nnnnnnn x xxxx
x nnn hhhh xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx nnnnnnn x xxxx
x nnn hhhh xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx nnnnnnn x xxxx
x nnn hhhh xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx nnnnnnn x xxxx
x nnn hhhh xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx nnnnnnn x xxxx
x nnn hhhh xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx nnnnnnn x xxxx
x nnn hhhh xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx nnnnnnn x xxxx
x nnn hhhh xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx nnnnnnn x xxxx
x nnn hhhh xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx nnnnnnn x xxxx
x nnn hhhh xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx nnnnnnn x xxxx
x nnn hhhh xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx nnnnnnn x xxxx
x nnn hhhh xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx nnnnnnn x xxxx
x nnn hhhh xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx nnnnnnn x xxxx
x nnn hhhh xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx nnnnnnn x xxxx
OPTIONS: A=ADD,D=DELETE,U=UPDATE,*=PROCESSED,?=ERROR
PROGRAM: SM61 MSG-INDX: nn -- DB.3.1 -- yy.ddd / hh:mm:ss
MESSAGE:

Chapter 4: Defining Requirements 153

Predecessor and Successor Definition

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following:
FORMAT
Clears the panel of user input data.
LIST
Lists data from the database. In batch, a formatted panel is not listed; only a
found or not found message is returned.
UPD
Updates a data set requirement according to OPT field values.
Batch keyword: Positional parameter
n/a
Predecessor type. Contains a constant value of DSN for data sets.
Limits: Required for batch only.
Batch keyword: Positional parameter
PRED FOR JOB
Specifies the required job name for which data set predecessors are being defined.
Limits: 1 to 8 alphanumeric characters
Batch keyword: Positional parameter
LIST-SCHID
(Optional) Applies only to the LIST function. When used, all connections for the
SCHID entered and all connections for schedule ID of 0 are listed. Schedule IDs on
each detail line apply to that line only.
Default: Null (Causes connections for all schedule IDs to be listed).
Limits: 1 to 3 numeric characters
Batch keyword: Not applicable
OPT
(Optional) Used with the UPD function, denotes the type of connection operation.
The operation codes are A (add), D (delete), and U (update).
Note: The U option applies only to LEADTM, PERM, and NEXT-RUN fields.
Batch keyword: OPT

154 Database Maintenance Guide

 Predecessor and Successor Definition

SCHID
(Optional) Specifies for which schedule ID of this job the data set requirement is
applied. The user cannot specify the zero default for one connection and use a
nonzero schedule ID for another connection to the same job and data set. An
attempt to make such a connection results in a CA WA CA 7 Edition error message.
(For an online LIST function, the SCHID field on the same line as JOB field defaults to
null, causing all schedule IDs to be listed.) This field cannot be changed with OPT=U.
Default: 0 (requirement holds for all schedule IDs)
Limits: 1 to 3 numeric characters from 0 through 999
Batch keyword: SCHID
LEADTM
(Optional) Represents satisfaction lead time in hours. If the value is nonzero, this
value overrides any satisfaction lead time on the DB.1 panel for data sets. The
following values are valid:
0
Specifies that the data set must have been created or updated after the start
time of the last run of the job. The amount of time that has elapsed has no
special consideration.
99
Specifies that the requirement is never considered initially satisfied when the
job enters the request queue. The data set must be created or updated while
this job is in the request queue.
nn
Specifies that the data set must have been created or updated within the last
nn hours. Values for nn can be 1 through 98.
Default: 0
Batch keyword: LEADTM
DATASET NAME
Defines the fully qualified data set name that is defined as a data set requirement
for the job in the JOB field.
Limits: 1 to 44 alphanumeric characters and required unless DSNBR is used.
Batch keyword: DSN
DSNBR
Specifies the data set number (as previously assigned by CA WA CA 7 Edition) that is
defined as a data set requirement for the job in the JOB field.
Limits: 1 to 8 numeric characters and required unless DSNAME is used.
Batch keyword: DSNBR

Chapter 4: Defining Requirements 155

Predecessor and Successor Definition

PERM
(Optional) Specifies whether to consider this data set permanent by CA WA CA 7
Edition for the requirements of this job (Y or N). The DB.6 panel can be used to
mark a data set as permanent for all jobs. This field defines the data set as
permanent only for this job.
Default: N
Batch keyword: PERM
NEXT-RUN
(Optional) Specifies status of this predecessor for the next run of this job. The next
time that the job is scheduled into the queues, this value determines the
predecessors for that execution.
YES
Specifies normal, recurring predecessor.
ONLY
Specifies one-time predecessor for only the next run of this job. Automatically
discarded by CA WA CA 7 Edition when next successful job completion is done.
(See note.) Only valid when OPT=A. Noted on QM.2 display as O and on other
general inquiry displays as ONLY.
SKIP
Specifies normal, recurring predecessor that is skipped (ignored) when the next
run is scheduled into the queues. Only valid when OPT=U and previous value
was YES. Automatically reinstated to YES when next successful job completion
is done. (See note.) Noted on certain displays as SKIP but does not appear on
QM.2 displays because it is skipped when the job enters the queues.
Default: Yes (for OPT value of A)
Batch keyword: NEXTRUN
Note: The next successful job completion only applies to jobs that are not already in
the queue when the NEXT-RUN is set. However, if the job is already in the queue
and entered the queue when the NEXT-RUN was SKIP or ONLY, then it is reset as
indicated.

156 Database Maintenance Guide

 Predecessor and Successor Definition

Usage Notes

You can add more requirements on a one-time basis. You can skip existing requirements
on a one-time basis.

A data set connection is not considered a true predecessor requirement when any one
of the following conditions are true:
■ The data set is TYPE=PERM on DB.6 panel.
■ The requirement is marked PERM for this job on the DB.3.1 panel.
■ The job is marked MAINT=Y on the DB.1 panel.
■ The requirement does not apply to this run (schedule ID dependency).
■ The requirement was defined as NEXT-RUN=SKIP.
■ A RUN or LOAD command scheduled the job.
■ The job was DEMANDed using TYPE=RES.

The combination of job name, job schedule ID, and data set name handles any unique
variations of the data set connection.

If the LOADDSNS keyword is used on the DBASE statement in the initialization file, then
the LOAD process does not build any DD or data set information for jobs that are
marked MAINT=Y on the DB.1 (JOB) panel. The result is that there are no data set
connections for these jobs unless added they are added manually.

Example: Batch Input

This batch input example adds the data set USER.XX00.WEEKLY as a predecessor
requirement to job CA07XX01. This requirement applies to the next run scheduled and
then is removed.

JOBCONN
UPD,DSN,CA07XX01,OPT=A,DSN=USER.XX00.WEEKLY,NEXTRUN=ONLY
DBM

DB.3.2 - Job Predecessors Panel

The DB.3.2 - Job Predecessors panel lets you establish predecessor job requirements.

To display the panel, enter:

■ 2 as the FUNCTION on the DB.3 Menu panel.
■ 3.2 as the FUNCTION on the DB Menu panel.
■ DB.3.2 as the FUNCTION value on any other menu or formatted input panel.
■ DB.3.2 or JOBCONN,JOB as a top line command.

Chapter 4: Defining Requirements 157

Predecessor and Successor Definition

To exit the panel:

■ Press PF3 to return to the DB.3 Menu panel except with the TSO-ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

------------------------ CA-7 CPU JOB PREDECESSORS -------------------------

FUNCTION: xxxxxxxx (FORMAT,LIST,UPD) PAGE nnnn
PRED FOR JOB: xxxxxxxx LIST-SCHID: nnn
OPT SCHID LEADTM PRED-JOB NEXT-RUN
x nnn hhhh xxxxxxxx xxxx
x nnn hhhh xxxxxxxx xxxx
x nnn hhhh xxxxxxxx xxxx
x nnn hhhh xxxxxxxx xxxx
x nnn hhhh xxxxxxxx xxxx
x nnn hhhh xxxxxxxx xxxx
x nnn hhhh xxxxxxxx xxxx
x nnn hhhh xxxxxxxx xxxx
x nnn hhhh xxxxxxxx xxxx
x nnn hhhh xxxxxxxx xxxx
x nnn hhhh xxxxxxxx xxxx
x nnn hhhh xxxxxxxx xxxx
x nnn hhhh xxxxxxxx xxxx
x nnn hhhh xxxxxxxx xxxx
x nnn hhhh xxxxxxxx xxxx
OPTIONS: A=ADD,D=DELETE,U=UPDATE,*=PROCESSED,?=ERROR
PROGRAM: SM61 MSG-INDX: nn -- DB.3.2 -- yy.ddd / hh:mm:ss
MESSAGE:

This panel contains the following fields:

FUNCTION
Specifies the function to perform. The value must be the name of some other panel
or one of the following:
FORMAT
Clears the panel of user input data.
LIST
Lists data from the database. In batch, a formatted panel is not listed; only a
found or not found message is returned.
UPD
Updates predecessor job requirements in the database according to OPT field
values.
Batch keyword: Positional parameter

158 Database Maintenance Guide

 Predecessor and Successor Definition

n/a
Predecessor type. Contains a constant value of JOB for jobs.
Limits: Required for batch only.
Batch keyword: Positional parameter
PRED FOR JOB
Specifies the job name for which job requirements are being defined or listed.
Limits: 1 to 8 alphanumeric characters
Batch keyword: Positional parameter
LIST-SCHID
(Optional) Applies only to the LIST function. A SCHID of 0 applies to connections for
all schedules and therefore is listed with connections for any schedule ID requested.
Schedule IDs on each detail line apply to that line only.
Default: Null (all connections for all schedule IDs appear)
Limits: 1 to 3 numeric characters from 0 through 999
Batch keyword: Not applicable
OPT
(Optional) Used with the UPD function, denotes the type of connection operation.
The operation codes are A (add), D (delete), and U (update).
Note: The U option applies only to the LEADTM and NEXT-RUN fields.
Batch keyword: OPT
SCHID
(Optional) Specifies for which schedule ID (of this job, not the PRED-JOB) the
requirement is applied. If omitted when the connection is made, default is 0. A zero
default cannot be specified for one connection and a nonzero schedule ID used for
another connection to the same job with the same predecessor job. An attempt to
make such a connection results in an error message issued by CA WA CA 7 Edition.
(For the online LIST function, the field on the same line as JOB field defaults to null
causing all schedule IDs to be listed.)
Default: 0 (specifies the requirement holds for all schedule IDs)
Limits: 1 to 3 numeric characters from 0 through 999
Batch keyword: SCHID

Chapter 4: Defining Requirements 159

Predecessor and Successor Definition

LEADTM
(Optional) Specifies satisfaction lead time in hours. If nonzero, this value overrides
any satisfaction lead time indicated on the DB.1 panel for this job connection.
Values are the following:
0
Specifies that the predecessor job must have started and completed
successfully since the last run of the dependent job. The amount of time that
may have elapsed has no special consideration.
99
Specifies that the requirement is never considered initially satisfied when this
job enters the request queue. The dependent job must complete typically while
this job is in the request queue.
nn
Specifies that since the last run of this job, the predecessor job has started and
completed successfully within the last nn hours. Values for nn can be 1 to 98.
Default: 0
Batch keyword: LEADTM
PRED-JOB
Names the job on which the job specified in the JOB field is dependent. This
predecessor job name can be preceded by a slash (/) to indicate a negative job
dependency. A conditional job dependency is indicated by prefixing the
predecessor job name with a question mark (?). If job A is conditionally dependent
on job B, then job A will depend on job B only if job B is in the request, ready, or
active queues when job A enters the request queue.
If a generic negative dependency is specified, the successor job will only be
submitted when there are not any jobs are submitted that meet the generic
PRED-JOB criteria. If a generic dependency is defined without the slash, the
successor job will enter the request queue with the generic requirement. The first
job that completes and meets the generic PRED-JOB will satisfy that requirement.
(CA WA CA 7 Edition produces a warning message indicating that PRED-JOB is not
found.) Conditional dependencies cannot be specified as generic.
Limits: 1 to 9 alphanumeric characters
(or 1 to 8 alphanumeric characters terminated with an asterisk to indicate a generic
name)
Batch keyword: PRED

160 Database Maintenance Guide

 Predecessor and Successor Definition

Note: A job predecessor requirement defined as conditional (?) is considered

satisfied if it is NOT in the request, ready, or active queue when the requiring job
enters the request queue. Otherwise, the predecessor job is considered an
unsatisfied requirement. Also, a conditional requirement can establish only one
requirement per job even if multiple occurrences are in the queues for the other
job.
A negative job dependency reflects mutual exclusion of jobs and prevents them
from executing simultaneously. To ensure exclusion, a similar connection must also
be made to define this job as mutually exclusive for the predecessor job. Lead time
is not valid with negative job dependencies.
Negative job dependencies are checked when a job is in the ready queue preparing
for submission (all other job requirements have been satisfied). If one of the job's
mutually exclusive jobs has been submitted (ready queue or active queue), then a
positive job dependency is assigned to the job and it is moved back to the request
queue. The job will then wait for the successful completion of the mutually
exclusive job before it will be ready for submission. A job requirement is assigned
even if the active job was requested with a RUN function or command. The
completion of the active job from RUN does not POST the requirement; the
requirement must be posted manually.
NEXT-RUN
(Optional) Specifies status of this predecessor for the next run of this job. The next
time that the job is scheduled into the queues, the following values determine the
predecessors for that execution:
YES
Specifies normal, recurring predecessor.
ONLY
Specifies one-time predecessor for only the next run of this job. Automatically
discarded by CA WA CA 7 Edition when next successful job completion is done.
(See note.) Noted on QM.2 display as O and on several general inquiry displays
as ONLY.
SKIP
Specifies normal, recurring predecessor that is to be skipped (ignored) when
the next run is scheduled into the queues. Only valid when OPT=U and previous
value was YES. Automatically reinstated to YES when next successful job
completion is done. (See note.) Noted on certain displays as SKIP but does not
appear on QM.2 displays since it is skipped when the job enters the queues.
Default: Yes (for OPT value of A)
Batch keyword: NEXTRUN
Note: The next successful job completion only applies to jobs that are not already in
the queue when the NEXT-RUN is set. However, if the job is already in the queue
and entered the queue when the NEXT-RUN was SKIP or ONLY, then it is reset as
indicated.

Chapter 4: Defining Requirements 161

Predecessor and Successor Definition

Usage Notes

You can add more requirements on a one-time basis. You can skip existing requirements
on a one-time basis.

A job connection is not considered a true requirement for the following conditions:
■ A RUN or LOAD command scheduled the job.
■ The requirement does not apply to this run (schedule ID dependency).
■ The requirement was defined as NEXT-RUN=SKIP.
■ The job was DEMANDed using TYPE=RES.

The combination of the job name, job schedule ID, and predecessor job name handles
the unique variations of the job connection.

Example: Batch Input

This batch input example adds job CA07XX03 as a predecessor requirement for job
CA07XX05.

JOBCONN
UPD,JOB,CA07XX05,OPT=A,PRED=CA07XX03
DBM

DB.3.2L - Job Predecessors Panel (Long Job Name)

The DB.3.2L - Job Predecessors panel lets you establish predecessor job requirements
using long job names.

To display the panel, enter:

■ 2L as the FUNCTION on the DB.3 Menu panel.
■ 3.2L as the FUNCTION on the DB Menu panel.
■ DB.3.2L as the FUNCTION value on any other menu or formatted input panel.
■ DB.3.2L or JOBCONN,JOBL as a top line command.

To exit the panel:

■ Press PF3 to return to the DB.3 Menu panel except with the TSO-ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

162 Database Maintenance Guide

 Predecessor and Successor Definition

------------------------ CA-7 CPU JOB PREDECESSORS -------------------------

FUNCTION: xxxxxxxx (FORMAT,LIST,UPD) PAGE nnnn
JOB/L: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx S: nnn
OPT SCHID PRED-JOBL /LEADTM NEXT-RUN
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
hhhh xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
hhhh xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
hhhh xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
hhhh xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
hhhh xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
hhhh xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
hhhh xxxx

OPTIONS: A=ADD,D=DELETE,U=UPDATE,*=PROCESSED,?=ERROR
PROGRAM: SM62 MSG-INDX: 00 -- DB.3.2L -- yy.ddd / hh:mm:ss
MESSAGE: ENTER FUNCTION, TRANSFER OR ENTER A COMMAND ON THE TOP LINE

This panel contains the following fields:

FUNCTION
Specifies the function to perform. The value must be the name of some other panel
or one of the following values:
FORMAT
Clears the panel of user input data.
LIST
Lists data from the database. In batch, a formatted panel is not listed; only a
found or not found message is returned.
UPD
Updates predecessor job requirements in the database according to OPT field
values.
Batch keyword: Positional parameter
n/a
Predecessor type. Contains a constant value of JOBL for jobs.
Limits: Required for batch only.
Batch keyword: Positional parameter
n/a
Job name.
Limits: Required for batch only. Can leave blank.
Batch keyword: Positional parameter

Chapter 4: Defining Requirements 163

Predecessor and Successor Definition

JOB/L
Specifies the job name or long job name for which job requirements are being
defined or listed.
Limits: 1 to 64 alphanumeric characters, case sensitive
Batch keyword: JOBL
S
(Optional) The LIST-SCHID field for this panel. Applies only to the LIST function. A
SCHID of 0 applies to connections for all schedules and therefore is listed with
connections for any schedule ID requested. Schedule IDs on each detail line apply to
that line only.
Default: Null (all connections for all schedule IDs appear).
Limits: 1 to 3 numeric characters
Batch keyword: Not applicable
OPT
(Optional) Used with the UPD function, denotes the type of connection operation.
The operation codes are A (add), D (delete), and U (update).
Note: The U option applies only to the LEADTM and NEXT-RUN fields.
Batch keyword: OPT
SCHID
(Optional) Specifies for which schedule ID (of this job, not the PRED-JOBL) the
requirement is applied. If omitted when the connection is made, default is 0. A zero
default cannot be specified for one connection and a nonzero schedule ID used for
another connection to the same job with the same predecessor job. An attempt to
make such a connection results in an error message. (For the online LIST function,
the field on the same line as JOB/L field defaults to null causing all schedule IDs to
be listed.)
Default: 0 (specifies the requirement holds for all schedule IDs)
Limits: 1 to 3 numeric characters from 0 through 999
Batch keyword: SCHID

164 Database Maintenance Guide

 Predecessor and Successor Definition

LEADTM
(Optional) Specifies the satisfaction lead time in hours. If a nonzero, this value
overrides any satisfaction lead time that is indicated on the DB.1 panel for this job
connection. The following values are valid:
0
Specifies that the predecessor job must have started and completed
successfully after the last run of the dependent job. The amount of time that
has elapsed has no special consideration.
99
Specifies that the requirement is never considered initially satisfied when this
job enters the request queue. The dependent job must complete typically while
this job is in the request queue.
nn
Specifies after the last run of this job, the predecessor job has started and
completed successfully within the last nn hours. Values for nn can be 1 through
98.
Default: 0
Batch keyword: LEADTM
PRED-JOBL
Names the job on which the job specified in the JOB field is dependent. A slash (/)
can precede this predecessor job name to indicate a negative job dependency. A
conditional job dependency is indicated by prefixing the predecessor job name with
a question mark (?). If job A is conditionally dependent on job B, then job A depends
on job B only if job B is in the request, ready, or active queues when job A enters
the request queue.
Note: The generic dependencies are not permitted for the DB.3.2L screen. If you
require generic dependencies, use the DB.3.2 screen to create the definition.
Limits: 1 through 65 alphanumeric characters
Batch keyword: DEPJOBL

Chapter 4: Defining Requirements 165

Predecessor and Successor Definition

Note: A job predecessor requirement defined as conditional (?) is considered

satisfied if it is not in the request, ready, or active queue when the requiring job
enters the request queue. Otherwise, the predecessor job is considered an
unsatisfied requirement. Also, a conditional requirement can establish only one
requirement per job even if multiple occurrences are in the queues for the other
job.
A negative job dependency reflects mutual exclusion of jobs and prevents them
from executing simultaneously. To ensure the exclusion, make a similar connection
also to define this job as mutually exclusive for the predecessor job. Lead time is
not valid with negative job dependencies.
Negative job dependencies are checked when a job is in the ready queue preparing
for submission (all other job requirements have been satisfied). If one of the job's
mutually exclusive jobs has been submitted (ready queue or active queue), then a
positive job dependency is assigned to the job and it is moved back to the request
queue. The job will then wait for the successful completion of the mutually
exclusive job before it is ready for submission. A job requirement is assigned even if
the active job was requested with a RUN function or command. The completion of
the active job from RUN does not POST the requirement; the requirement must be
posted manually.
NEXT-RUN
(Optional) Specifies status of this predecessor for the next run of this job. The next
time that the job is scheduled into the queues, the following values determine the
predecessors for that execution:
YES
Specifies normal, recurring predecessor.
ONLY
Specifies one-time predecessor for only the next run of this job. Automatically
discarded by CA WA CA 7 Edition when next successful job completion is done.
(See the note.) Noted on QM.2 display as O and on the various general inquiry
displays as ONLY.
SKIP
Specifies normal, recurring predecessor that is skipped (ignored) when the next
run is scheduled into the queues. Only valid when OPT=U and previous value
was YES. Automatically reinstated to YES when next successful job completion
is done. (See the note.) Noted on certain displays as SKIP but does not appear
on QM.2 displays because it is skipped when the job enters the queues.
Default: Yes (for OPT value of A)
Batch keyword: NEXTRUN
Note: The next successful job completion only applies to jobs that are not already in
the queue when the NEXT-RUN is set. However, if the job is already in the queue
and entered the queue when the NEXT-RUN was SKIP or ONLY, it is reset as
indicated.

166 Database Maintenance Guide

 Predecessor and Successor Definition

Usage Notes

You can add more requirements on a one-time basis. You can skip existing requirements
on a one-time basis.

A job connection is not considered a true requirement for the following conditions:
■ A RUN or LOAD command scheduled the job.
■ The requirement does not apply to this run (schedule ID dependency).
■ The requirement was defined as NEXT-RUN=SKIP.
■ The job was demanded using TYPE=RES.

The combination of the job name, job schedule ID, and predecessor job name handles
the unique variations of the job connection.

Example: Batch Input

This batch input example adds the job LongJobNameA as a predecessor requirement for
the job LongJobNameB.

JOBCONN
UPD,JOBL,,JOBL=LongJobNameB,OPT=A,DEPJOBL=LongJobNameA
DBM

DB.3.4 - Input/Output Network Tasks Panel

The DB.3.4 - Input/Output Network Tasks panel lets you define a job's requirements (or
connections) for workstation networks. One network can be connected to multiple jobs.

To display the panel, enter:

■ 4 as the FUNCTION on the DB.3 Menu panel.
■ 3.4 as the FUNCTION on the DB Menu panel.
■ DB.3.4 as the FUNCTION on any other menu or formatted input panel.
■ DB.3.4 or JOBCONN,NWK as a top line command.

To exit the panel:

■ Press PF3 to return to the DB.3 Menu panel except with the TSO-ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

Chapter 4: Defining Requirements 167

Predecessor and Successor Definition

--------------------- CA-7 INPUT/OUTPUT NETWORK TASKS ----------------------

FUNCTION: xxxxxxxx (FORMAT,LIST,UPD) PAGE nnnn
TASK FOR JOB: xxxxxxxx LIST-SCHID: nnn
OPT SCHID LEADTM NETWORK SUB-ID NWK-SCHID DESCRIPTION NEXT-RUN
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
OPTIONS: A=ADD,D=DELETE,U=UPDATE,*=PROCESSED,?=ERROR
PROGRAM: SM61 MSG-INDX: nn -- DB.3.4 -- yy.ddd / hh:mm:ss
MESSAGE:

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of following:
FORMAT
Clears the panel of user input data.
LIST
Lists data from the database. In batch, a formatted panel is not listed; only a
found or not found message is returned.
UPD
Updates a network requirement according to OPT field values.
Batch keyword: Positional parameter
n/a
Predecessor type. Contains a constant value of NWK for networks.
Limits: Required for batch only.
Batch keyword: Positional parameter
TASK FOR JOB
Specifies the job name for which a network connection is to be established.
Limits: 1 to 8 alphanumeric characters
Batch keyword: Positional parameter

168 Database Maintenance Guide

 Predecessor and Successor Definition

LIST-SCHID
(Optional) Applies only to the LIST function. A SCHID of 0 applies to connections for
all schedules and therefore is listed with connections for any schedule ID requested.
Schedule IDs on each detail line apply to that line only.
Default: Null (causes connections for all schedule IDs to appear)
Limits: 1 to 3 numeric characters from 0 through 999
Batch keyword: Not applicable
OPT
(Optional) Used with the UPD function operation, denotes the operation codes: A
(add), D (delete), and U (update).
Note: The U option applies only to the LEADTM, NWK-SCHID, DESCRIPTION, and
NEXT-RUN fields.
Batch keyword: OPT
SCHID
(Optional) Specifies the schedule ID (of this job) for which a network requirement is
applied. If omitted when the connection is made, the default is 0. A zero default
cannot be specified for one connection and a nonzero schedule ID for another
connection to the same job with the same network and sub-ID. An attempt to make
such a connection results in an error message issued by CA WA CA 7 Edition.
Default: 0 (specifies that the requirement holds for all schedule IDs)
Limits: 1 to 3 numeric characters from 0 through 999
Batch keyword: SCHID
LEADTM
(Optional) For an input network, specifies satisfaction lead time in hours. Values are
the following:
0
Specifies that the requirement is satisfied if the input network has been
processed since the last run of the job.
9999
Specifies that the requirement is never considered initially satisfied when the
job enters the request queue. The preprocess network must complete while
this job is in the request queue.
nnnn
Specifies that the requirement is only considered satisfied if the network has
been completed within the last nnnn hours (0 through 9998).

Chapter 4: Defining Requirements 169

Predecessor and Successor Definition

Default: 0
Batch keyword: LEADTM
For an output network, specifies all postprocess network due-out times are
adjusted (lead time is added) by this value.
Default: 0
Limits: 1 to 4 numeric characters specified as hhmm where hours are 00 through 24
and minutes are 00 through 59, the highest value being 2400.
Batch keyword: LEADTM
NETWORK
Specifies the network name.
Limits: 1 to 8 alphanumeric characters
Batch keyword: NETWORK
SUB-ID
(Optional) Specifies a name that further qualifies the network. For example, if a
network is connected to a job multiple times with the same SCHID, the user must
further qualify the network name, by specifying a SUB-ID, to distinguish between
the various purposes each network connection fulfills. For output networks only.
Limits: 1 to 8 alphanumeric characters
Batch keyword: SUBID
NWK-SCHID
(Optional) Specifies a network schedule identification. This field specifies which
output network schedule ID is used when the job is scheduled. This field has no
effect for input networks. If this field does not match the SCHID field on the DB.2.3
panel, the output network is not scheduled.
Default: 0 (the job's schedule ID is used)
Limits: 1 to 3 numeric characters from 0 through 999
Batch keyword: NWKSCHID
DESCRIPTION
(Optional) Provides further identification of the connected network.
Limits: 1 to 8 alphanumeric characters
For output networks, this field shows when listing the network.
For input networks, this field is only documentation.
Batch keyword: DESC

170 Database Maintenance Guide

 Predecessor and Successor Definition

NEXT-RUN
(Optional) Specifies status of this predecessor for the next run of this job. The next
time that the job is scheduled into the queues, the following values determine the
predecessors for that execution:
YES
Specifies normal, recurring predecessor.
ONLY
Specifies one-time predecessor for only the next run of this job. Automatically
discarded by CA WA CA 7 Edition when next successful job completion is done.
(See note.) Only valid when OPT=A. Noted on QM.2 display as O and on various
general inquiry displays as ONLY.
SKIP
Specifies normal, recurring predecessor that is skipped (ignored) when the next
run is scheduled into the queues. Only valid when OPT=U and previous value
was YES. Automatically reinstated to YES when next successful job completion
is done. (See note.) Noted on certain displays as SKIP but does not appear on
QM.2 displays since it is skipped when the job enters the queues.
Default: Yes (for OPT value of A)
Batch keyword: NEXTRUN
Note: The next successful job completion only applies to jobs that are not already in
the queue when the NEXT-RUN is set. However, if the job is already in the queue
and entered the queue when the NEXT-RUN was SKIP or ONLY, then it is reset as
indicated.

Chapter 4: Defining Requirements 171

Predecessor and Successor Definition

Usage Notes

You can add more requirements on a one-time basis. You can skip existing requirements
on a one-time basis.

The combination of job name, job schedule ID, network name, and network sub-ID
handles any unique variations of a network connection.

A connected input network becomes a requirement for the job. An input network
connection is not considered a true requirement for the following conditions:
■ A RUN or LOAD command scheduled the job.
■ The requirement does not apply to this run (schedule ID dependency).
■ The requirement was defined as NEXT-RUN=SKIP.
■ The job was DEMANDed using TYPE=RES.

A connected output network is scheduled into the postprocess queue when the job
enters the request queue. After the network is defined with the DB.5 panel, the network
is logically connected to one or more jobs with the DB.3.4 panel. (Required scheduling
parameters must also be entered with the DB.2.3 panel. The schedule, however, is not
RESOLVed.)

Example: Batch Input

This batch input example adds output network TESTOTNW as a successor to job
CA07XX01. Schedule ID 1 for TESTOTNW is used with station due-out times that are
adjusted by one hour. A name of RPT1205 further identifies this network from any other
that could be associated with the job.

JOBCONN
UPD,NWK,CA07XX01,OPT=A,NETWORK=TESTOTNW,NWKSCHID=1,LEADTM=100,SUBID=RPT1205
DBM

DB.3.4L - Input/Output Network Tasks Panel (Long Job Names)

The DB.3.4 - Input/Output Network Tasks panel lets you define a job's requirements (or
connections) for workstation networks based on the long job name of the job. One
network can be connected to multiple jobs.

To display the panel, enter:

■ 4L as the FUNCTION on the DB.3 Menu panel.
■ 3.4L as the FUNCTION on the DB Menu panel.
■ DB.3.4L as the FUNCTION on any other menu or formatted input panel.
■ DB.3.4L or JOBCONN,NWKL as a top line command.

172 Database Maintenance Guide

 Predecessor and Successor Definition

To exit the panel:

■ Press PF3 to return to the DB.3 Menu panel except with the TSO-ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

Use the JOB/L field to define the triggering job.

The batch positional parameter indicating the predecessor type should have a value of
NWKL.

Other keyword descriptions are the same as the DB.2.6L – Data Set Triggering (Long Job
Name) panel.

--------------------- CA-7 INPUT/OUTPUT NETWORK TASKS ----------------------

FUNCTION: xxxxxxxx (FORMAT,LIST,UPD) PAGE nnnn
JOB/L: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx S: nnn
OPT SCHID LEADTM NETWORK SUB-ID NWK-SCHID DESCRIPTION NEXT-RUN
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
x nnn nnnn xxxxxxxx xxxxxxxx nnn xxxxxxxx xxxx
OPTIONS: A=ADD,D=DELETE,U=UPDATE,*=PROCESSED,?=ERROR
PROGRAM: SM61 MSG-INDX: 00 -- DB.3.4L -- yy.ddd / hh:mm:ss
MESSAGE: ENTER FUNCTION, TRANSFER OR ENTER A COMMAND ON THE TOP LINE

More information:

DB.3.4 - Input/Output Network Tasks Panel (see page 167)

Chapter 4: Defining Requirements 173

Predecessor and Successor Definition

DB.3.6 - User Memo-Form Predecessors Panel

The DB.3.6 - User Memo-Form Predecessors panel lets you enter a user requirement,
free-form text. The text can be displayed on a CA WA CA 7 Edition terminal and that
requires an operator response before the connected job can execute. The text usually
directs someone to perform some manual task. Multiple lines are sometimes required
to describe completely the necessary actions. The POST command, QM.2, or QM.1
panels can be used to indicate that the task has been completed (the requirement has
been satisfied).

To display the panel, enter:

■ 6 as the FUNCTION on the DB.3 Menu panel.
■ 3.6 as the FUNCTION on the DB Menu panel.
■ DB.3.6 as the FUNCTION on any other menu or formatted input panel.
■ DB.3.6 or JOBCONN,USR as a top line command.

To exit the panel:

■ Press PF3 to return to the DB.3 Menu panel except with the TSO-ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

--------------------- CA-7 USER MEMO-FORM PREDECESSORS ---------------------

FUNCTION: xxxxxxxx (FORMAT,LIST,UPD) PAGE nnnn
PRED FOR JOB: xxxxxxxx LIST-SCHID: nnn
OPT SCHID *--- MEMO-FORM USER PREDECESSOR ---* NEXT-RUN
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
OPTIONS: A=ADD,D=DELETE,U=UPDATE,*=PROCESSED,?=ERROR
PROGRAM: SM61 MSG-INDX: nn -- DB.3.6 -- yy.ddd / hh:mm:ss
MESSAGE:

174 Database Maintenance Guide

 Predecessor and Successor Definition

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following:
FORMAT
Clears the panel of user input data.
LIST
Lists data from the database. In batch, a formatted panel is not listed; only a
found or not found message is returned.
UPD
Updates a user requirement according to OPT field values.
Batch keyword: Positional parameter
n/a
Predecessor type. Contains a constant value of USR for user text.
Limits: Required for batch only.
Batch keyword: Positional parameter
PRED FOR JOB
Specifies the job name for which user requirements are being defined.
Limits: 1 to 8 alphanumeric characters
Batch keyword: Positional parameter
LIST-SCHID
(Optional) Applies only to the LIST function. A SCHID value of 0 applies to
connections for all schedules and therefore is listed with connections for any
schedule ID requested. Schedule IDs on each detail line apply to that line only.
Default: Null (causes connections for all schedule IDs to appear)
Limits: 1 to 3 numeric characters from 0 through 999
Batch keyword: Not applicable
OPT
(Optional) Used with the UPD function, denotes the type of connection operation.
The operation codes are A (add), D (delete), and U (update).
Note: The U option applies only to the NEXT-RUN field. To change the memo text, a
delete (D) must be performed followed by an add (A).
Batch keyword: OPT

Chapter 4: Defining Requirements 175

Predecessor and Successor Definition

SCHID
(Optional) Specifies the schedule ID (of this job) for which a user requirement is
applied. A zero default cannot be specified for one connection and a nonzero
schedule ID used for a subsequent connection to the same job with the same user
requirement description. An attempt to make such a connection results in a CA WA
CA 7 Edition error message.
Default: 0 (specifies that the requirement holds for all schedule IDs)
Limits: 1 to 3 numeric characters from 0 through 999
Batch keyword: SCHID
MEMO-FORM USER PREDECESSOR
Specifies a free-form description of the user requirement. Not valid with OPT=U.
Any text can be entered here that communicates the appropriate requirement. This
field can define requirements that cannot be controlled automatically. Ensuring
that the transmission line is up or calling the payroll department to verify that the
edit is OK are examples. You can express the requirements as a simple phrase, a
sentence, or a paragraph. We recommend that you use as many words as necessary
to clarify exactly what to do. For example, "Make sure the online system is down" is
not as clear as "Make sure the online system is down for the day" because online
systems can come up and down during the day. If the instructions do not fit in the
36 spaces on one line, you can use as many lines as necessary to explain them
completely. Each line then becomes a separate requirement that must be satisfied
before the job can run.
We also recommend that you use this type of requirement only when necessary
because a manual intervention is required to satisfy it.
Note: If the text contains an apostrophe, parenthesis, or comma, the requirement
cannot be added through BTI nor can it be posted through an external
communicator.
Limits: 1 to 36 alphanumeric characters, case sensitive
Batch keyword: USR

176 Database Maintenance Guide

 Predecessor and Successor Definition

NEXT-RUN
(Optional) Specifies status of this predecessor for the next run of this job. The next
time that the job is scheduled into the queues, the following values determine the
predecessors for that execution:
YES
Specifies normal, recurring predecessor.
ONLY
Specifies one-time predecessor for only the next run of this job. Automatically
discarded by CA WA CA 7 Edition when next successful job completion is done.
(See note.) Only valid when OPT=A. Noted on QM.2 display as O and on various
general inquiry displays as ONLY.
SKIP
Specifies normal, recurring predecessor that is skipped (ignored) when the next
run is scheduled into the queues. Only valid when OPT=U and previous value
was YES. Automatically reinstated to YES when next successful job completion
is done. (See note.) Noted on certain displays as SKIP but does not appear on
QM.2 displays because it is skipped when the job enters the queues.
Default: Yes (for OPT value of A)
Batch keyword: NEXTRUN
Note: The next successful job completion only applies to jobs that are not already in
the queue when the NEXT-RUN is set. However, if the job is already in the queue
and entered the queue when the NEXT-RUN was SKIP or ONLY, then it is reset as
indicated.

Usage Notes

You can add more requirements on a one-time basis. You can skip existing requirements
on a one-time basis.

The combination of job name, job schedule ID, and user requirement descriptions
handles any unique variations of the user connection.

Example: Batch Input

This batch input example adds a memo type predecessor requirement for job
CA07XX01.

JOBCONN
UPD,USR,CA07XX01,OPT=A,USR=CALL FRED BEFORE RELEASING
DBM

Chapter 4: Defining Requirements 177

Predecessor and Successor Definition

DB.3.6L - User Memo-Form Predecessors Panel (Long Job Names)

The DB.3.6L - User Memo-Form Predecessors panel lets you enter a user requirement,
free-form text, that can be displayed on a CA WA CA 7 Edition terminal and that requires
an operator response before the connected job can execute. This panel accommodates
long job names. The text should direct someone to perform some manual task. Multiple
lines may be required to completely describe the action needed. The POST command,
QM.2, or QM.1 panels can be used to indicate that the task has been completed (the
requirement has been satisfied).

To display the panel, enter:

■ 6L as the FUNCTION on the DB.3 Menu panel.
■ 3.6L as the FUNCTION on the DB Menu panel.
■ DB.3.6L as the FUNCTION on any other menu or formatted input panel.
■ DB.3.6L or JOBCONN,USRL as a top line command.

To exit the panel:

■ Press PF3 to return to the DB.3 Menu panel except with the TSO-ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

Use the JOB/L field to define the triggering job. Use the S field to define the SCHID to list
by.

The batch positional parameter indicating the predecessor type should have a value of
USRL.

Other keyword descriptions are the same as the DB.3.6 - User Memo-Form Predecessors
panel.

178 Database Maintenance Guide

 Predecessor and Successor Definition

--------------------- CA-7 USER MEMO-FORM PREDECESSORS ---------------------

FUNCTION: xxxxxxxx (FORMAT,LIST,UPD) PAGE nnnn
JOB/L: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx S: nnn
OPT SCHID *--- MEMO-FORM USER PREDECESSOR ---* NEXT-RUN
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
x nnn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxx
OPTIONS: A=ADD,D=DELETE,U=UPDATE,*=PROCESSED,?=ERROR
PROGRAM: SM61 MSG-INDX: 00 -- DB.3.6L -- yy.ddd / hh:mm:ss
MESSAGE: ENTER FUNCTION, TRANSFER OR ENTER A COMMAND ON THE TOP LINE

More information:

DB.3.6 - User Memo-Form Predecessors Panel (see page 174)

Chapter 4: Defining Requirements 179

Chapter 5: Virtual Resource
Management
Use the Virtual Resource Management (VRM) facility to define controls on job
submission based on resource availability. The resource connected to a job can
represent a real resource such as a data set or a started task.

This facility provides the following features:

■ Resource control at the job, system, or step level.
■ Job submission control for jobs that use shared or exclusive resources.
■ Job corequisite requirements.

Note: The Virtual Resource Management (VRM) facility manages the resource usage by
using tables internal to CA WA CA 7 Edition.

The resource dependencies are determined during the job submission process. Jobs
waiting for resources wait in the ready queue with a status of W-RSRC.

The VRM resources are ignored for nonexecutable jobs.

This section contains the following topics:

Resource Types (see page 181)
Resource Conflicts Resolution (see page 187)
RM - Virtual Resource Management Menu Panel (see page 187)
RM.1 - Job Resource Management Panel (see page 188)
RM.2 - Job/Resource Cross-Reference List Panel (see page 195)
RM.3 - Active Job Resources Display Panel (see page 198)
RM.4 - Pending Resources Job Display Panel (see page 201)
RM.5 - Jobs Waiting on Resources Panel (see page 203)
RM.6 - Corequisite Resources List Panel (see page 205)
RM.7 - Resource Count Resource Management Panel (see page 207)
VRM Device Control (see page 210)

Resource Types
The following topics discuss the various resource types available and the VRM variable
definitions.

Chapter 5: Virtual Resource Management 181

Resource Types

Shared Resources
At times, multiple jobs can run using the same resource. You can define this situation as
a Shared resource requirement under the Virtual Resource Management facility. A
Shared resource connection indicates that multiple jobs can execute simultaneously
while using this resource.

Exclusive Resource
You can define the exclusive use of a resource under CA WA CA 7 Edition VRM. This
definition indicates that the job requires exclusive use of the resource and that no other
jobs connected to the resource can execute. If the resource is unavailable exclusively at
job submission time, the job waits in the ready queue for the resource with a status of
W-RSRC.

Corequisite Resources
A corequisite resource relationship indicates that a job executes based on the active or
inactive status of the resource. Assume that a job to resource connection is set up to
require that a specific corequisite resource is active before execution. In this case, CA
WA CA 7 Edition checks whether the corequisite resource is active before submitting the
job. The same is true for an inactive corequisite resource. The indicated corequisite
resource must be inactive before the job is submitted for execution. To activate or
deactivate a corequisite resource, issue the PRSQA and PRSQD commands respectively.
You can issue the commands in an online or batch environment.

Note: The following corequisite resource name prefixes are reserved:

■ FLOW@
■ CPM@
■ GLOBAL@ or other prefix on the OPTIONS, SHRCRQPFX keyword

182 Database Maintenance Guide

 Resource Types

Address Space Resources

The Virtual Resource Management facility lets you control the execution of a job based
on the active or inactive status of an address space. For example, assume that JOBA
requires that a CICS region is active for the job to be submitted. During the job
submission cycle, CA WA CA 7 Edition checks to see if the CICS region is active before
submitting the job. If the region is not active, the job waits in the ready queue with a
status of W-RSRC. The job waits until the address space becomes active. This check
occurs during every CA WA CA 7 Edition submission cycle unless the enhanced
submission selection feature (SUBSEL=ENH) is active, in which case the check occurs at
most once per minute. The same process occurs for a job connected to an address space
resource that requires that the address space is inactive. The address space resource
requirement is only valid on the host CPU where CA WA CA 7 Edition is executing.

Resource Count Resources

A resource count resource is a resource that is available for use based on a specific
count or number for this resource. The count value indicates the maximum occurrences
for this resource count resource. When a job to resource connection is made to a
resource count resource, a value is specified. The value identifies the total number of
occurrences for this resource that the job uses. When the job is submitted, this value is
subtracted from the maximum amount available for the resource count resource.

For example, suppose that you have 20 tapes drives available at your site. Next, suppose
that you want to manage the usage of the tape drives by connecting jobs to a resource
count resource. The resource count resource can indirectly represent the tape drives by
establishing a maximum total count available for the resource count resource and then
connecting jobs to the resource and specifying the number of occurrences that each job
uses.

Note: The following resource count resource name prefix is reserved:

■ VRMDD.

Chapter 5: Virtual Resource Management 183

Resource Types

VRM Variable Definitions

Note: VRM Variable Definitions are specific to the CPU jobs because these jobs are
submitted to the z/OS operating system where the IBM feature WorkLoad Management
(WLM) is active. Internal cross-platform jobs do not use VRM Variable Definitions.

CA WA CA 7 Edition supports the definition of variables using the RM panels. These

variables are known as VRM variables because the definitions are stored in the
database.

Currently, the sole purpose of a VRM variable definition is to control the insertion of the
SCHENV keyword. This function is part of the CA WA CA 7 Edition interface with the IBM
Workload Manager.

Note: For more information about this interface, see the Interface Reference Guide.

The SCHENV keyword on the JOB statement names the WLM scheduling environment
that must be available for the job to run. CA WA CA 7 Edition supports dynamic insertion
of the SCHENV keyword on the JOB statement when the job is submitted so that manual
JCL changes are not required.

The value of SCHENV to be inserted can be defined for a specific SCHID of the job using a
VRM variable definition. When CA WA CA 7 Edition prepares to submit the 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 be inserted.

The Structure of VRM Variable Definitions

You can tailor the SCHENV keyword insertion for a specific run of a job by defining a
VRM variable in the resource profile of the job. A VRM 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
the 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.

184 Database Maintenance Guide

 Resource Types

How VRM Variable Definitions Are Used

The CA WA CA 7 Edition IBM WLM Interface uses VRM variable definitions to control the
SCHENV keyword insertion.

The setting of the WLMSE keyword on the OPTIONS statement in the CA WA CA 7

Edition initialization file governs SCHENV keyword insertion. If N or NO is coded, CA WA
CA 7 Edition does not attempt the SCHENV keyword insertion. WLMSE=Y or WLMSE=YES
indicates that CA WA CA 7 Edition is to insert the SCHENV keyword. If a value other than
these values is coded, CA WA CA 7 Edition assumes that it is a global default. The global
default is inserted when CA WA CA 7 Edition is unable to determine a more specific
value for the job.

CA WA CA 7 Edition scans first for an entry with a SCHID value matching the value 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, CA WA CA 7 Edition scans for an entry with a
SCHID value of 0. If found, CA WA CA 7 Edition uses it as the SCHENV value on the JOB
statement. If no variable definition with a SCHID matching the SCHID of the job being
submitted is present and if no definition with a SCHID value of 0 is present, CA WA CA 7
Edition attempts to use the global value that is 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.

Examples

In Examples 1 through 3, consider the following variables that are defined for job A:

OPT SCHID RESOURCE NAME STEPNAME TYPE FREE

0 SCHENV.SHIFT1 VAR N
2 SCHENV.SHIFT2 VAR N
15 SCHENV.SPECIAL VAR N
20 SCHENV.NONE VAR N

Example 1

WLMSE=YES is coded on the OPTIONS statement in the initialization file. If job A is

demanded with SCHID=2, CA WA CA 7 Edition inserts SCHENV='SHIFT2' on the JOB
statement for A.

Example 2

WLMSE=YES is coded on the OPTIONS statement in the initialization file. Suppose that
job A is demanded with SCHID=3. Because you have no specific definition for SCHID=3,
the value from the definition for SCHID=0 is used (SCHENV.SHIFT1).

Chapter 5: Virtual Resource Management 185

Resource Types

Example 3

WLMSE=YES is coded on the OPTIONS statement in the initialization file. Schedule scan
brings in job A with SCHID=20. 'SCHENV.NONE' is a reserved resource name in a VRM
variable definition. The name indicates that the job is submitted without inserting the
SCHENV keyword.

In Examples 4 and 5, consider the following variables that are defined for job B. No
variable has been defined for SCHID 0.

OPT SCHID RESOURCE NAME STEPNAME TYPE FREE

5 SCHENV.FIVE VAR N
55 SCHENV.FIFTY_FIVE VAR N
100 SCHENV.NONE VAR N

Example 4

WLMSE=VANILLA is coded on the OPTIONS statement in the initialization file. Job B is

demanded with SCHID=30. SCHID 30 has no specific definition. Since SCHID 0 has no
definition, CA WA CA 7 Edition uses the global value and inserts SCHENV='VANILLA' on
the JOB statement for B.

Example 5

WLMSE=YES is coded on the OPTIONS statement in the initialization file. Job B is

demanded with SCHID=20. Because SCHID 20 has no specific definition, no generic
definition for SCHID 0 and no global default that is specified for WLMSE, the job is
submitted without any SCHENV keyword.

How VRM Variable Definitions Differ from Other VRM Definitions

A VRM resource definition usually implies a condition that must be satisfied before the
job can be submitted. For example, a definition using the resource type CRQ means that
the corequisite resource must be in the state indicated by the FREE value in the
definition or CA WA CA 7 Edition does not submit the job.

But a VRM variable definition does not imply such a condition. Before submitting a job,
CA WA CA 7 Edition tests each of the resource conditions that are specified in the VRM
profile of the job. When all these conditions are satisfied, the job is eligible for
submission. VRM variable definitions are ignored in this process.

186 Database Maintenance Guide

 Resource Conflicts Resolution

Resource Conflicts Resolution

VRM dynamically manages resource conflicts that are based on definitions and CA WA
CA 7 Edition job queue activity. This process usually requires little or no manual
intervention. CA WA CA 7 Edition detects when a job is no longer using a resource. CA
WA CA 7 Edition frees it for use by other jobs according to the instructions in the jobs
resource profile (the FREE value on the RM.1 panel). However, anomalies can occur if
you have multiple instances of a job with the same name.

For example, suppose that JOBA is defined to use resource RSC1. Further assume that
the RM.1 definition specifies TYPE=EXC and FREE=Y. If JOBA (say, job number 1) abends
and is waiting in the request queue for a restart, another instance of JOBA (job number
2) can move to the ready queue for submission. However, JOBA (1) still has exclusive
control of the RSC1 resource that was acquired when it was initially submitted. Hence,
JOBA (2) does not submit. Instead it waits in the ready queue for the RSC1 resource to
become available. An LQ display shows that the status of JOBA (2) is W-RSRC.

To let JOBA (2) run, one must take a manual corrective action such as canceling or
forcing completion of JOBA (1). JOBA (1) cannot be submitted while JOBA (2) is in the
ready queue.

An initialization file option is provided to streamline the handling of such conflicts.

Note: For information about handling these anomalies, see the OPTIONS statement
keyword JSOP in the Systems Programming Guide.

RM - Virtual Resource Management Menu Panel

The Virtual Resource Management Menu panel lets you select the Virtual Resource
Management functions.

To display the panel, enter:

■ RM as a top line command.
■ RM as the FUNCTION value on any other menu or formatted input panel.

To exit the panel, enter the name of an online panel as the FUNCTION value or move the
cursor to the top line and enter a top line command if some other function is wanted.

Chapter 5: Virtual Resource Management 187

RM.1 - Job Resource Management Panel

Select the wanted function by entering its value as the FUNCTION and pressing the
Enter key.

-------------------- CA-7 VIRTUAL RESOURCE MANAGEMENT MENU -------------------

FUNCTION ==>

RESOURCE MANAGEMENT OPTIONS:

1 - JOB RESOURCE MANAGEMENT

2 - JOB RESOURCE CROSS REFERENCE LIST
3 - ACTIVE JOB RESOURCES DISPLAY
4 - PENDING RESOURCES JOB DISPLAY
5 - JOBS WAITING ON RESOURCES DISPLAY
6 - COREQUISITE RESOURCES LIST
7 - RESOURCE COUNT RESOURCE MANAGEMENT

PROGRAM: RSC0 MSG-INDX: 00 -- RM -- yy.266 / 13:21:42

MESSAGE: SPECIFY DESIRED OPTION OR ENTER A COMMAND ON THE TOP LINE

RM.1 - Job Resource Management Panel

The RM.1 Job Resource Management panel lets you list, add, update, or delete resource
connections by job. The panel generates the VRM static type J and R records that are
maintained on the database.

To display the panel, enter:

■ 1 as the FUNCTION on the RM Menu panel.
■ RM.1 as the FUNCTION value on any other menu or formatted input panel.
■ RM.1 as a top line command.

188 Database Maintenance Guide

 RM.1 - Job Resource Management Panel

To exit the panel:

■ Press PF3 to return to the RM Menu panel except with the TSO/ISPF interface when
PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

-------------------------- CA-7 JOB RESOURCE MANAGEMENT -----------------------

FUNCTION ====> (FORMAT,LIST,UPD)
JOB: LIST-SCHID: PAGE 0001
OPT SCHID RESOURCE NAME STEPNAME TYPE FREE

OPTIONS: A=ADD D=DELETE U=UPDATE *=PROCESSED ?=ERROR

PROGRAM: RSC1 MSG-INDX: 00 -- RM.1 -- yy.ddd / hh:mm:ss
MESSAGE: ENTER FUNCTION, TRANSFER OR ENTER A COMMAND ON THE TOP LINE

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following values:
FORMAT
Clears the panel of user input data.
LIST
Lists the resources that are connected to the specified job and schedule ID.
UPD
Performs the updating option that is indicated by the OPT parameter that
follows.
Batch keyword: Positional parameter

Chapter 5: Virtual Resource Management 189

RM.1 - Job Resource Management Panel

JOB
Specifies the job name on which the indicated function is performed.
Limits: 1 to 8 alphanumeric characters
Batch keyword: JOB
LIST-SCHID
(Optional) Applies only to the LIST function. A SCHID value of 0 applies to
connections for all schedules and therefore is listed with connections for any
schedule ID requested. Schedule IDs on each detail line apply to that line only.
Default: Null (causes connections for all schedule IDs to appear).
Limits: 1 to 3 numeric characters from 0 through 999
Batch keyword: Not applicable
OPT
Used with the UPD function, denotes the type of connection operation. The
operation codes are A (add), U (update), and D (delete).
Batch keyword: OPT
SCHID
(Optional) Specifies the schedule ID (of this job) for which a user requirement is
applied. A zero default cannot be specified for one connection and a nonzero
schedule ID used for a subsequent connection to the same job with the same user
requirement description. An attempt to make such a connection results in an error
message issued by CA WA CA 7 Edition.
Default: 0 (indicates that the requirement holds for all schedule IDs)
Limits: 1 to 3 numeric characters from 0 through 999
Batch keyword: SCHID

190 Database Maintenance Guide

 RM.1 - Job Resource Management Panel

RESOURCE NAME
Specifies the resource name being connected to the job.
Limits: 1 to 44 characters. The first character must be nonblank and no embedded
blanks.
Exception: If the resource connection is made to a resource count resource, the
resource name can be from 1 to 39 characters followed by a / (slash) and a 1 to 4
numeric value indicating the number of occurrences for the resource that the job
will use.
Batch keyword: RSRC
STEPNAME
(Optional) Specifies the resource is freed at the conclusion of the named job step.
Not valid for types ASX and CRQ.
Limits: 1 to 8 alphanumeric characters
Batch keyword: STEP
Note: The stepname field applies to the first occurrence of the stepname
encountered in the job stream. This includes any reference to the stepname
embedded in a PROC.
If a job is restarted in a step after this STEPNAME, the resource does not go through
free processing until the job completes.
A step flush condition does not post the STEPNAME process.
TYPE
Determines the usage of the resource by the job. The valid resource usage types
are:
ASX
Specifies an address space resource. This controls the submission of the job
based on the status of an address space.
Note: The address space resource requirement is only valid on the host CPU
where CA WA CA 7 Edition is executing.
CRQ
Specifies a corequisite resource. The job cannot be submitted if the resource is
active or inactive (see the FREE option). The corequisite resource must be
activated or deactivated using the PRSQA or PRSQD command. This can be
performed in an online or batch environment.
EXC
Specifies an exclusive resource. Only one job can be active with this resource.

Chapter 5: Virtual Resource Management 191

RM.1 - Job Resource Management Panel

RCT
Specifies a resource count resource. This controls the submission of the job
based on the number of available occurrences within a resource count type
resource when adding a resource count resource connection. The resource
name can be from 1 to 39 characters followed by a / (slash) and a 4-character
numeric value indicating the number of resource occurrences this job will use.
SHR
Specifies a shared resource. Multiple jobs can be active with the same
resource.
VAR
Specifies a variable definition. It does not define a necessary resource condition
for the job. The FREE value will be forced to N. The resource name for such a
resource must conform to the following format:
SCHENV.x
x Defines the name of an IBM WLM scheduling environment (1 to 16
characters). This value should follow IBM conventions governing names of
scheduling environments.
Batch keyword: TYPE
FREE
Determines how VRM manages resource availability at job submission and job/step
completion. Different values are supported depending upon the type of resource
defined.
For shared and exclusive resources the following FREE options are supported. There
is no default.
A
Specifies the resource is only freed if any step in the job abends (abend or
condition code checking).
F
Specifies the resource is freed when job ends, either successfully or
unsuccessfully. If the STEPNAME parameter is specified, free the resource
when the specified step completes, either successfully or unsuccessfully.
N
Specifies do not free the resource at successful job completion. The resource
can be freed with the PRSCF command. A cancel of the job also frees the
resource.
Y
Specifies to free the resource at successful job completion. If the STEPNAME
parameter is specified, free the resource when the specified step completes
successfully (does not abend).

192 Database Maintenance Guide

 RM.1 - Job Resource Management Panel

For corequisite resources, the following FREE options are supported:

A
Specifies the job is submitted only if the resource is active (as established by
the PRSQA command). This is the default.
I
Specifies the job is submitted only if the resource is not active.
For address space resources, the following FREE options are supported:
A
Specifies the job is submitted only if the resource is active on the same system
as CA WA CA 7 Edition. The resource name is assumed to be a jobname or
started task name running on the system. This is the default.
I
Specifies the job is submitted only if the resource is not active on the same
system as CA WA CA 7 Edition. The resource name is assumed to be a jobname
or started task name running on the system.
For variable resources, the FREE option is not used and is always set to N regardless
of any value specified.
For resource count resources, the following FREE options are supported. There is no
default.
A
Specifies the resource count is only decremented when the job abends.
F
Specifies the resource count is decremented when the job completes, either
successfully or unsuccessfully. If the STEPNAME parameter is specified, the
resource count is decremented when the specified step completes, either
successfully or unsuccessfully.
N
Specifies the resource count is not decremented when the job completes. The
PRSCF command can be used to decrement the resource count. A cancel of the
job also decrements the resource count.
Y
Specifies the resource count is decremented when the job or step ends
successfully. If the STEPNAME parameter is specified, the resource count is
decremented when the specified step completes successfully (does not abend).
Batch keyword: FREE

Chapter 5: Virtual Resource Management 193

RM.1 - Job Resource Management Panel

Example: Batch Input

This batch input example lists the resources connected to job TESTJOB.

RM.1
LIST,RM.1,JOB=TESTJOB

This batch input example adds a resource connection to job TESTJOB.

RM.1
UPD,RM.1,JOB=TESTJOB,OPT=A,RSRC=SAMPLE.RESOURCE,SCHID=0,TYPE=SHR,FREE=F

Critical Path Monitoring Corequisite Resources

You can use Critical Path Monitoring with CA WA CA 7 Edition to monitor the progress
and status of critical paths in your workload.

To define a critical path flow, you need to connect a unique type of VRM corequisite
resource to the first job in the flow. This resource defines the name, end point, and
target time for the flow. When the job is run, an active flow element is created when
VRM resources are attached in the ready queue.

The resource name has the following format:

[email protected]

flowname
Defines the 1 to 8 character unique name to assign to this flow.
endjob
Defines the job name of the last job in this flow.
endschid
Defines the schedule ID of the last job in this flow. Use a specific number from 1 to
999 or set to a value of 0 (zero) to indicate the ending job has the same schedule ID
as the starting job of the FLOW.
endtarget
Defines the target latest time the ending job should complete (hhmm). Alternately,
a time interval can be set from the starting time of the FLOW (+hhmm).
endday
Defines an optional parameter to add days to the target time (.n). You can specify a
maximum of 9 days when an ending time (hhmm) is used for the endtarget. If an
interval (+hhmm) is used, the maximum endday is 8.

194 Database Maintenance Guide

 RM.2 - Job/Resource Cross-Reference List Panel

Example
[email protected]

Usage Notes

The resource type must be corequisite (CRQ).

The resource name must begin with FLOW@.

The flowname, end job name, end schedule ID, and end target are required parameters
and must be separated by periods.

The end day parameter is optional. If specified, it must be 1 digit (0-9) separated from
the end target by a period. A value of 1 causes 24 hours to be added to the target time.
A value of 2 causes 48 hours to be added, and so forth.

The FREE type must be specified on the definition (A or I), however, it is ignored if the
CPM facility is active. Since these resources are treated as normal corequisites if the
CPM facility is not active, you may want to specify I (inactive) for the FREE type.

Important! VRM resources are never attached to nonexecutable jobs. Thus, the starting
job of any flow must be executable.

Note: For more information about the Critical Path Monitoring facility, see the Interface
Reference Guide

RM.2 - Job/Resource Cross-Reference List Panel

The RM.2 Job/Resource Cross-Reference List panel lets you list jobs using resources. You
can list the jobs by a fully qualified resource name or by a generic key.

To display the panel, enter:

■ 2 as the FUNCTION on the RM Menu panel.
■ RM.2 as the FUNCTION value on any other menu or formatted input panel.
■ RM.2 as a top line command.

To exit the panel:

■ Press PF3 to return to the RM Menu panel except with the TSO/ISPF interface when
PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

Chapter 5: Virtual Resource Management 195

RM.2 - Job/Resource Cross-Reference List Panel

------------------- CA-7 JOB / RESOURCE CROSS REFERENCE LIST ------------------

FUNCTION ====> (FORMAT,LIST)
RSRC: LIST-SCHID: PAGE 0001
RESOURCE NAME SCHID JOBNAME STEPNAME TYPE FREE

PROGRAM: RSC2 MSG-INDX: 00 -- RM.2 -- yy.ddd / hh:mm:ss

MESSAGE: ENTER FUNCTION, TRANSFER OR ENTER A COMMAND ON THE TOP LINE

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following:
FORMAT
Clears the panel of user input data.
LIST
Lists the resources and the associated jobs that are based on user specified
resource criteria.
Batch keyword: Positional parameter

196 Database Maintenance Guide

 RM.2 - Job/Resource Cross-Reference List Panel

RSRC
Specifies the resources for which information is listed.
*
Specifies all resources.
resource
Specifies a fully qualified resource name.
Limits: 1 to 44 alphanumeric characters
resource*
Specifies multiple resources specified by a generic resource name.
Limits: 1 to 43 alphanumeric characters terminated with an asterisk
Batch keyword: RSRC
LIST-SCHID
(Optional) Applies only to the LIST function. A SCHID value of 0 applies to
connections for all schedules and therefore is listed with connections for any
schedule ID requested. Schedule IDs on each detail line apply to that line only.
Default: Null (causes connections for all schedule IDs to appear)
Limits: 1 to 3 numeric characters from 0 through 999
Batch keyword: SCHID
RESOURCE NAME
Identifies the requested resources.
SCHID
Identifies the schedule ID of the job using this resource.
JOBNAME
Identifies the name of the job using this resource.
STEPNAME
Identifies the name of the step that frees this resource.
TYPE
Identifies the usage mode of the resource (for example, SHR, EXC).
FREE
Identifies the disposition of this resource at step, abnormal, or successful
completion time.
Note: For more information about the FREE keyword, see the RM.1 panel
descriptions.

Chapter 5: Virtual Resource Management 197

RM.3 - Active Job Resources Display Panel

Example: Batch Input

This batch input example lists all the cross-reference entries for resources that begin
with PROD.

RM.2
LIST,RM.2,RSRC=PROD*

RM.3 - Active Job Resources Display Panel

The RM.3 Active Job Resources Display panel lets you display active resources by job.
The jobs can be listed generically or with fully qualified job names.

To display the panel, enter:

■ 3 as the FUNCTION on the RM Menu panel.
■ RM.3 as the FUNCTION value on any other menu or formatted input panel.
■ RM.3 as a top line command.

To exit the panel:

■ Press PF3 to return to the RM Menu panel except with the TSO/ISPF interface when
PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

--------------------- CA-7 ACTIVE JOB RESOURCES DISPLAY ----------------------

FUNCTION ====> (FORMAT,LIST)
JOB: RSRC: PAGE 0001
JOBNAME RESOURCE NAME CA7 # STEPNAME TYPE FREE

PROGRAM: RSC3 MSG-INDX: 00 -- RM.3 -- yy.ddd / hh:mm:ss

MESSAGE: ENTER FUNCTION, TRANSFER OR ENTER A COMMAND ON THE TOP LINE

198 Database Maintenance Guide

 RM.3 - Active Job Resources Display Panel

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following:
FORMAT
Clears the panel of user input data.
LIST
Lists active resources associated with user specified jobs.
Batch keyword: Positional parameter
JOB
(Optional) Specifies a fully qualified or generic job name.
*
Specifies all jobs.
job
Specifies a fully qualified job name.
Limits: 1 to 8 alphanumeric characters
job*
Specifies multiple jobs specified by a generic job name.
Limits: 1 to 7 alphanumeric characters terminated with an asterisk
Default: All jobs
Batch keyword: JOB

Chapter 5: Virtual Resource Management 199

RM.3 - Active Job Resources Display Panel

RSRC
(Optional) Specifies a fully qualified or generic resource name. An asterisk indicates
a generic request.
*
Specifies all resources.
resource
Specifies a fully qualified resource name.
Limits: 1 to 44 alphanumeric characters
resource*
Specifies multiple resources specified by a generic resource name.
Limits: 1 to 43 alphanumeric characters terminated with an asterisk
Default: All resources
Batch keyword: RSRC
JOBNAME
Identifies the job name.
RESOURCE NAME
Identifies the names of the active resources.
CA7 #
Identifies the CA WA CA 7 Edition job number.
STEPNAME
Identifies the name of the job step that freed the resource.
TYPE
Identifies the usage mode of the resource for the job.
FREE
Identifies the disposition of the resource at job completion time or the status of a
corequisite resource type.

Example: Batch Input

This batch input example lists all active resources for jobs that begin with PAY.

RM.3
LIST,RM.3,JOB=PAY*,RSRC=*

200 Database Maintenance Guide

 RM.4 - Pending Resources Job Display Panel

RM.4 - Pending Resources Job Display Panel

The RM.4 Pending Resources Job Display panel lets you display all pending resources
with an associated job name. A pending resource is a nonfreed resource connected to a
job that has already executed and has been purged from the request queue. This
resource can only be freed by using the PRSCF command. The pending resources can be
listed using a generic or fully qualified resource name.

To display the panel, enter:

■ 4 as the FUNCTION on the RM Menu panel.
■ RM.4 as the FUNCTION value on any other menu or formatted input panel.
■ RM.4 as a top line command.

To exit the panel:

■ Press PF3 to return to the RM Menu panel except with the TSO/ISPF interface when
PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

--------------------- CA-7 PENDING RESOURCES JOB DISPLAY --------------------

FUNCTION ====> (FORMAT,LIST)
RSRC: PAGE 0001
RESOURCE NAME JOBNAME CA7 JOB# TYPE

PROGRAM: RSC4 MSG-INDX: 00 -- RM.4 -- yy.ddd / hh:mm:ss

MESSAGE: ENTER FUNCTION, TRANSFER OR ENTER A COMMAND ON THE TOP LINE

Chapter 5: Virtual Resource Management 201

RM.4 - Pending Resources Job Display Panel

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following:
FORMAT
Clears the panel of user input data.
LIST
Lists all pending resources (nonfreed) and the associated job name. A pending
resource can be freed using the PRSCF command.
Batch keyword: Positional parameter
RSRC
(Optional) Specifies a fully qualified or generic resource name. An asterisk indicates
a generic request.
*
Specifies all resources.
resource
Specifies a fully qualified resource name.
Limits: 1 to 44 alphanumeric characters
resource*
Specifies multiple resources specified by a generic resource name.
Limits: 1 to 43 alphanumeric characters terminated with an asterisk
Default: All resources
Batch keyword: RSRC
RESOURCE NAME
Identifies the pending resource names.
JOBNAME
Identifies the job name.
CA7 JOB#
Identifies the CA WA CA 7 Edition job number.
TYPE
Identifies the usage mode of the resource by this job.

202 Database Maintenance Guide

 RM.5 - Jobs Waiting on Resources Panel

Example: Batch Input

This batch input example lists all pending VRM resources.

RM.4
LIST,RM.4,RSRC=*

RM.5 - Jobs Waiting on Resources Panel

The RM.5 Jobs Waiting on Resources panel lets you display jobs waiting for resources. It
can be used to show the resources that a job is waiting for when the job shows a status
of W-RSRC on the List Queue (LQ) display. However, ASX resources may not always
show on the RM.5 panel. This can occur because ASX resources are only checked
periodically (approximately two minute intervals) after the initial test for a job.

To display the panel, enter:

■ 5 as the FUNCTION on the RM Menu panel.
■ RM.5 as the FUNCTION value on any other menu or formatted input panel.
■ RM.5 as a top line command.

To exit the panel:

■ Press PF3 to return to the RM Menu panel except with the TSO/ISPF interface when
PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

------------------------ CA-7 JOBS WAITING ON RESOURCES ----------------------

FUNCTION ====> (FORMAT,LIST)
JOB: LIST-SCHID: PAGE 0001
JOB NAME RESOURCE NAME SCHID STEPNAME TYPE FREE

PROGRAM: RSC5 MSG-INDX: 00 -- RM.5 -- yy.ddd / hh:mm:ss

MESSAGE: ENTER FUNCTION, TRANSFER OR ENTER A COMMAND ON THE TOP LINE

Chapter 5: Virtual Resource Management 203

RM.5 - Jobs Waiting on Resources Panel

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following:
FORMAT
Clears the panel of user input data.
LIST
Lists jobs waiting for resources based on user specified job name and schedule
ID criteria.
Batch keyword: Positional parameter
JOB
(Optional) Specifies a fully qualified or generic job name.
*
Specifies all jobs.
job
Specifies a fully qualified job name.
Limits: 1 to 8 alphanumeric characters
job*
Specifies multiple jobs specified by a generic job name.
Limits: 1 to 7 alphanumeric characters terminated with an asterisk
Default: All jobs
Batch keyword: JOB
LIST-SCHID
(Optional) Applies only to the LIST function. A SCHID value of 0 applies to
connections for all schedules and therefore is listed with connections for any
schedule ID requested. Schedule IDs on each detail line apply to that line only.
Default: Null (causes connections for all schedule IDs to appear)
Limits: 1 to 3 numeric characters from 0 through 999
Batch keyword: SCHID

204 Database Maintenance Guide

 RM.6 - Corequisite Resources List Panel

JOB NAME
Identifies the job name of the job awaiting the resource.
RESOURCE NAME
Identifies the name of the nonavailable resource.
SCHID
Identifies the schedule ID of the job awaiting the resource.
STEPNAME
Identifies the jobstep in which the resource is to be freed.
TYPE
Identifies the usage mode of the resource by the job.
Note: On this panel, a TYPE of FRE may show. This would indicate that a PRSCF
command with FORCE=YES has been used for this resource.
FREE
Identifies the disposition of the resource at job completion time.

Example: Batch Input

This batch input example lists jobs waiting on VRM resources.

RM.5
LIST,RM.5,JOB=*

RM.6 - Corequisite Resources List Panel

The RM.6 Corequisite Resources List panel lets you list active corequisite resources.

To display the panel, enter:

■ 6 as the FUNCTION on the RM Menu panel.
■ RM.6 as the FUNCTION value on any other menu or formatted input panel.
■ RM.6 as a top line command.

Chapter 5: Virtual Resource Management 205

RM.6 - Corequisite Resources List Panel

To exit the panel:

■ Press PF3 to return to the RM Menu panel except with the TSO/ISPF interface when
PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

------------------------ CA-7 COREQUISITE RESOURCES LIST ----------------------

FUNCTION ====> (FORMAT,LIST)
RSRC: PAGE 0001
CO-REQ RESOURCE NAME

PROGRAM: RSC6 MSG-INDX: 00 -- RM.6 -- yy.ddd / hh:mm:ss

MESSAGE: ENTER FUNCTION, TRANSFER OR ENTER A COMMAND ON THE TOP LINE

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following:
FORMAT
Clears the panel of user input data.
LIST
Lists active corequisite sources.
Batch keyword: Positional parameter

206 Database Maintenance Guide

 RM.7 - Resource Count Resource Management Panel

RSRC
Specifies a fully qualified or generic resource name. An asterisk indicates a generic
request.
*
Specifies all resources.
resource
Specifies a fully qualified resource name.
Limits: 1 to 44 alphanumeric characters
resource*
Specifies multiple resources specified by a generic resource name.
Limits: 1 to 43 alphanumeric characters terminated with an asterisk
Batch keyword: RSRC
CO-REQ RESOURCE NAME
Identifies the fully qualified corequisite resource name.

Example: Batch Input

This batch input example lists all active corequisite resources.

RM.6
LIST,RM.6,RSRC=*

RM.7 - Resource Count Resource Management Panel

The RM.7 Resource Count Resource Management panel lets you list, add, update, or
delete a resource count type resource.

To display the panel, enter:

■ 7 as the FUNCTION on the RM Menu panel.
■ RM.7 as the FUNCTION value on any other menu or formatted input panel.
■ RM.7 as a top line command.

Chapter 5: Virtual Resource Management 207

RM.7 - Resource Count Resource Management Panel

To exit the panel:

■ Press PF3 to return to the RM Menu panel except with the TSO/ISPF interface when
PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

------------------ CA-7 RESOURCE COUNT RESOURCE MANAGEMENT -------------------

FUNCTION ====> (FORMAT,LIST,UPD)
RSRC: PAGE NO. 0001
OPT RESOURCE NAME TOTAL COUNT CURR IN USE

OPTIONS: U=UPDATE A=ADD D=DELETE *=PROCESSED ?=ERROR

PROGRAM: RSC7 MSG-INDX: 00 -- RM.7 -- yy.115 / 08:16:29
MESSAGE: ENTER FUNCTION, TRANSFER OR ENTER A COMMAND ON THE TOP LINE

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following:
FORMAT
Clears the panel of all input data.
LIST
Lists the Resource Count Resources and related resource information.
UPD
Used to update information about the Resource Count Resource.
Batch keyword: Positional parameter

208 Database Maintenance Guide

 RM.7 - Resource Count Resource Management Panel

RSRC
Specifies a fully qualified or generic Resource Count Resource name. This field is
only valid with LIST function.
*
Specifies all resources.
resource
Specifies a fully qualified resource name.
Limits: 1 to 39 alphanumeric characters
resource*
Specifies multiple resources specified by a generic resource name.
Limits: 1 to 38 alphanumeric characters terminated with an asterisk
Batch keyword: RSRC
OPT
Used with the Update and Add functions, denotes the operation to perform. Valid
codes are U (update), A (add), and D (delete).
Batch keyword: OPT
RESOURCE NAME
Identifies the Resource Count Resource for which the option is to be performed.
Batch keyword: DSN
TOTAL COUNT
Identifies the total number of available occurrences for this Resource Count
Resource.
Batch keyword: TOTAL
CURR IN USE
Identifies the number of occurrences of this Resource Count Resource currently in
use.

Chapter 5: Virtual Resource Management 209

VRM Device Control

Example: Batch Input

This batch input example adds a resource name of PAYROLL.RCT with a total of 100.

RM.7
UPD,RM.7,OPT=A,RSRC=PAYROLL.RCT,TOTAL=100

This batch input example lists all resource count resources that are currently defined.

RM.7
LIST,RM.7,RSRC=*

VRM Device Control

Note: VRM Device control applies only to CPU jobs, because it reads data obtained
from the LOAD process. If you need to control the number of jobs sent from this CA WA
CA 7 Edition Online system to a particular node, you can use the VRM Resource Count
function, but you must implement the function manually.

VRM Device Control provides a way to control job submission based on the availability
of devices that are detected during the CA WA CA 7 Edition Database Load process.
With this option, CA WA CA 7 Edition defines VRM Resource Count Resources that
correspond to real devices used by the job. RM.7 can then be used to set the quantities
of available units.

A VRM device is defined using a device code and unit name combination. The Database
Load process extracts the device code and/or unit name from each DD statement in the
job. Entries in the SASSDTAB table are used to determine which device code/unit name
combinations are eligible to be treated as VRM devices. The load process then defines a
VRM resource count resource for each unique device code/unit name combination that
is allowed by SASSDTAB.

Each entry in SASSDTAB contains information about a device code/unit name

combination and the name of a group to which the device belongs. This name is chosen
at the discretion of the client and allows definition of resource pools. When the job is
submitted, the name of each VRM device is changed to reflect the resource groupings
defined in SASSDTAB. Thus, although VRM devices are defined at the device level, they
are monitored and controlled at the group level based upon the definitions in
SASSDTAB.

210 Database Maintenance Guide

 VRM Device Control

VRM Device Control Functions - Definition Structure

CA WA CA 7 Edition treats a resource count resource definition as a VRM device
definition based upon the structure of the name. The name of a resource count
resource that is used as a VRM device definition conforms to the following format:

VRMDD.Dxxxxxxxx.Uyyyyyyyy/nnnn

xxxxxxxx
Specifies the device code in character hex. If the device code is not available, a
value of 00000000 is used.
yyyyyyyy
Specifies the UNIT name. If the unit name is not available, no value is used.
nnnn
Specifies the number of references to this device code and UNIT combination
calculated during the CA WA CA 7 Edition Database LOAD process.

Each of the following is a valid VRM device definition:

VRMDD.D12345678.UROUND/0030
VRMDD.D00000000.UCART/0010
VRMDD.D00000000.U/0050

VRM device definitions can be listed on the job's RM.1 panel. The term 'VRMDD.' begins
each definition. Because VRM resource names may have already been defined that
begin with 'VRMDD.' we recommend using RM.2 to list all VRM resources that conflict
before implementation of the feature.

Chapter 5: Virtual Resource Management 211

VRM Device Control

VRM Device Control Functions - Definition Control

Definitions for VRM Devices can be entered manually using the RM.1 panel. However,
we recommend that VRM devices be defined dynamically. Dynamic definition is
indicated by VRMDD=D or VRMDD=Y on the OPTIONS statement in the initialization file.
With dynamic VRM device definition, CA WA CA 7 Edition adds or deletes the resource
count resource definitions that correspond to devices detected by SASSJJCL during the
LOAD completion process.

The Database Load program (SASSJJCL) scans each DD statement in the job and extracts
the device code and unit name information. The SASSDTAB table is used to determine
which device code/unit name combinations are eligible to be considered VRM Devices.
If no entry is found in SASSDTAB for the device code/unit name, no resource count
resource is created for the device.

Entries in the SASSDTAB table are created using the L2VDD macro. Each entry declares a
device code and unit name combination that is to be tracked using VRM device
definitions.

SASSJJCL selects devices for dynamic definition based upon a scan of the SASSDTAB
table from top to bottom. Thus, selection depends on the order of L2VDD macro
statements. L2VDD requires a group name. The DEVICE and UNIT parameters are
optional. The value of the DEVICE and UNIT parameters is considered fully qualified
unless an asterisk (*) is coded. If the asterisk is coded, any value is considered eligible
for dynamic definition.

212 Database Maintenance Guide

 VRM Device Control

The following example illustrates significant features of the SASSDTAB module:

column
10 16 72
| | |
SASSDTAB CSECT
SASSVRSN VRSN=DOC
ENTRY1 L2VDD GROUP=SYSDISK, +
DEVICE=3033000E, +
UNIT=SYSDA
*
ENTRY2 L2VDD GROUP=ANYDISK, +
DEVICE=3033000F, +
UNIT=*
*
ENTRY3 L2VDD GROUP=SOME3380, +
DEVICE=*, +
UNIT=3380
*
ENTRY4 L2VDD GROUP=ANYUNIT, +
DEVICE=*, +
UNIT=*
*
ENTRY5 L2VDD GROUP=LAST
END

CAL2OPTN includes a SASSDTAB sample in member AL2UM44.

L2VDD macro statements that include an asterisk are placed lower in the module. In this
example, all devices detected with a device code of 3033000E and a UNIT name of
SYSDA are selected for definition and associated with the group SYSDISK. ENTRY2
ensures that devices with a device code 3033000F are selected for definition regardless
of UNIT name value. Such devices are placed in the ANYDISK group. A device that is not
considered eligible according to the aforementioned criteria will be selected for
definition if the UNIT name of 3380 is detected for it by SASSJJCL. It will be placed in the
SOME3380 group. ENTRY4 in the table ensures that any device not already covered by a
L2VDD entry will be selected for definition and placed in the ANYUNIT group.

L2VDD GROUP=LAST terminates the table and is required. LAST is a reserved group
name.

Chapter 5: Virtual Resource Management 213

VRM Device Control

VRM Device Control Functions - Submission Control

If VRMDD=Y or VRMDD=S is coded on the OPTIONS statement in the CA WA CA 7 Edition
initialization file, jobs are not submitted unless all required VRM devices are available.
Each VRM device definition is modified based on the GROUP name that is associated
with the device in SASSDTAB. For example, after a job is loaded, its RM.1 panel displays
the following entries:

VRMDD.D3390000F.UDISK/0001
VRMDD.D3338000E.USYSDA/0001

When VRM attempts to submit the job, it associates all of the resources according to
the groups defined in SASSDTAB. Thus these entries are reduced to one:

VRMDD.ANYUNIT/0002

This is the resource name that is displayed on RM.3 and RM.5. RM.7 must be updated
with sufficient quantities of the VRMDD.ANYUNIT resource for the job to be submitted.

VRM Device Control - Activation

VRM device control comprises two functions: definition and submission control. Either
or both of these functions can be activated depending on installation needs. Activation
of these functions is indicated by keyword values on the OPTIONS statement in the CA
WA CA 7 Edition initialization file.

If VRMDD=D is specified, VRM devices are dynamically defined during LOAD completion,
however they are ignored during job submission. If VRMDD=S is specified, no VRM
devices are dynamically defined, however any existing VRM device definitions are
respected during job submission. VRMDD=Y indicates that both functions are in effect.

By default, VRM devices are not dynamically defined nor are they modified during
submission. Unless VRM device control is indicated by VRMDD=Y or S, any RCT resource
name beginning with 'VRMDD.' is ignored during submission.

214 Database Maintenance Guide

Chapter 6: Automated Recovery
Facility
This section contains the following topics:
Overview (see page 215)
Monitor Exception Conditions (see page 216)
Respond to Exception Conditions (see page 217)
Types of Exceptions Recognized by ARF (see page 217)
ARFSET Structure (see page 220)
Implementation Considerations (see page 223)
AR.3 - ARF Condition Definition Maintenance Panel (see page 223)
ARF Condition Definition Edit Panel (see page 226)
Rules for Coding ARF Action Statements (see page 247)
Use Reserved Words in Type Specific Tests (see page 251)
Use Variables in ARF Action Statements (see page 253)
Examples of ARF Condition Definition (see page 254)

Overview
Use the Automated Recovery Facility (ARF) for CA WA CA 7 Edition to monitor exception
conditions for production jobs and to schedule recovery actions to execute at or near
the point of failure.

Kinds of exception conditions monitored by ARF include, but are not limited to the
following:
■ Abend exceptions tested at the job or step level.
■ Condition code exceptions tested at the job or step level.
■ Jobs whose elapsed execution time falls outside a range specified by the user.
■ Jobs considered late according to CA WA CA 7 Edition.
■ Jobs considered late according to user specified criteria tested when the job begins
or completes.

Chapter 6: Automated Recovery Facility 215

Monitor Exception Conditions

The kinds of recovery actions that can be executed in response to the exception
conditions detected by ARF include:
■ Scheduling and tracking special recovery jobs.
■ Issuing special messages to a specified TSO user or to the MVS console.
■ Issuing CA WA CA 7 Edition or MVS commands.
■ Restarting, canceling, or forcing the completion of jobs as the final step in the
recovery for job completion exceptions.

Monitor Exception Conditions

Because recovery monitoring can be resource intensive, ARF was designed so that the
recovery needs of a production job are tested at a limited number of points during CA
WA CA 7 Edition processing. These tests are executed only if they are specifically
indicated in the definitions of ARF conditions that are associated with the job when it
enters the request queue. These points include: job submission, SMF feedback, late
prompting, and job completion.

The definitions that provide the criteria for ARF tests are bundled into groups known as
ARFSETs. All of the tests that ARF will use to monitor the status of a job are determined
by the ARFSET that is associated with the job when the job enters the request queue.

An ARFSET can be associated with a job in several ways. An ARFSET can be named on
the job definition panel. This can be overridden using the #ARFSET statement in the JCL
or PARM data. Both of these designations can be overridden using the ARFSET keyword
on the DEMAND command.

For internal cross-platform jobs, each job has only one step. With this step data, the
completion information contains only the node name where the job executed, instead
of the program name, proc name, or step name. Because jobs can be routed to an
alternate node, if defined, these fields may not be reliable in any ARF conditional
testing. Consider this impact if defining ARFSETs for internal cross-platform job types.

216 Database Maintenance Guide

 Respond to Exception Conditions

Respond to Exception Conditions

Recovery actions are scheduled when the exception is detected so that the action can
be performed at or near the point of failure. Each occurrence of an exception condition
can have up to seven distinct actions associated with it in the definition of the condition.
The order in which the actions occur in the definition of the condition determines the
order in which actions are executed.

Each exception is handled in the order that it is detected. Because recovery actions are
executed serially for a given job, all of the actions for an exception occurrence must be
completed before the actions of a later exception occurrence can be executed. Suppose,
for example, that one step completion condition is detected and has two CA WA CA 7
Edition commands associated with it. ARF will begin processing the commands as soon
as the exception is recognized. Also suppose that another step completion exception is
detected for the same job while ARF is issuing commands for the first exception. In this
case, responses associated with the second exception will not be executed until those
associated with the first exception have been handled.

Responses for an ARF exception are executed on an internal terminal dedicated for use
by ARF. Each response is translated into a CA WA CA 7 Edition terminal command or set
of such commands. Since all CA WA CA 7 Edition terminal command input is logged to
the CA WA CA 7 Edition Browse Data Set, all ARF recovery activity is thereby recorded.

Types of Exceptions Recognized by ARF

All ARF monitoring is organized by exception type. Each ARF definition in an ARFSET
must specify the type of exception that is to be monitored. A list of the types of
exceptions recognized by ARF follows.

EC - Elapsed Time Check at Completion

A check of the elapsed time for the job is made when CA WA CA 7 Edition is notified of
normal job completion. The ARF definition specifies an elapsed time value (in minutes)
and a relational operator. If the elapsed time of the completed job stands in the relation
indicated by the relational operator to the elapsed time value in the ARF definition, then
an ARF exception is recognized for the job. Thus, for example, if the ARF definition
associated with a job specifies a relational operator of 'GE' and an elapsed time value of
'0002', then an ARF exception will be recognized if the elapsed time at completion of the
job is greater than or equal to 2 minutes.

Chapter 6: Automated Recovery Facility 217

Types of Exceptions Recognized by ARF

EE - Elapsed Time Check During Execution

The elapsed time of the job is monitored during execution. The ARF definition specifies
an elapsed time value. ARF will begin monitoring the elapsed time of the job when CA
WA CA 7 Edition is notified of job initiation. If the elapsed time interval specified in the
ARF definition expires prior to notification in CA WA CA 7 Edition of job completion then
an ARF exception is recognized. Such monitoring will allow CA WA CA 7 Edition to warn
of a possible problem if a job runs much longer than expected.

IS - Interrupt Submission

A test is made just prior to job submission similar to the test that is made for the LS
condition. The ARF definition specifies a date, time and relational operator. If the date
and time at job submission stands in the indicated relation to the date and time in the
ARF definition, an ARF condition is recognized. ARF will then automatically requeue the
job to the REQUEST queue prior to executing the responses.

JC - Job Completion Check

The execution status of a job is checked at job completion. Up to six completion code
tests joined by Boolean operators can be specified in the ARF definition. Each test allows
specification of the type of code to be tested:
■ SYS for system abends
■ USR for user abends
■ CC for condition codes
■ JCL for JCL error conditions
■ FL for flush conditions
■ HRC for high step condition code or job level cond-code (see the DB.1 - CPU Job
Definition panel)

The test also allows a relational operator to be specified along with the value of the
code. Thus, for example a test can specify 'CC GE 0024'. Only if the condition code of the
job is greater than or equal to 24 is an ARF condition recognized. Masking for wildcards
and generics is allowed. The following test can be specified as part of an ARF JC
definition: SYS EQ +37. This indicates that any system abend ending in 37 such as S-D37
or S-E37 will be recognized as an ARF exception.

218 Database Maintenance Guide

 Types of Exceptions Recognized by ARF

The HRC test is only valid for a JC (Job Completion) exception definition. The highest
condition code from any step in the job is used for the HRC test after the job has
completed. The HRC test cannot be combined with the other test formats. The STEP,
PROC, and PGM applicability tests for a JC definition using HRC must all be EQ *.

Note: We do not recommend a JC (Job Completion) check for a good EOJ condition. A
relational operator (RO) of IG on the Job Definition (DB.1) panel assumes the job
completes successfully. Any responses specified by a JC ARFSET looking for a good EOJ
may not occur.

LA - Late Notification at CA WA CA 7 Edition Prompting

An ARF exception is recognized when CA WA CA 7 Edition begins late prompting for the
job. The exception occurs only once for the job when it is initially considered late by CA
WA CA 7 Edition. Also, the exception is only taken if the job becomes late while in the
request queue, not when it enters the request queue as late. The prompt must actually
be done. For example, if the JOB panel uses PROMPTS of N, the exception does not
occur even though the job may show with a late status.

LB - Late Notification When Job Begins

A test is made when CA WA CA 7 Edition is notified of job initiation. The ARF definition
specifies a date, time and relational operator. If the date and time at job initiation
stands in the relation specified to the date and time in the ARF definition, then an ARF
exception is recognized.

LE - Late Notification When Job Ends

A test is made when CA WA CA 7 Edition is notified of job completion. The ARF

definition specifies a date, time and relational operator. If the date and time at job
completion stands in the relation specified to the date and time in the ARF definition,
then an ARF exception is recognized.

LS - Late Notification at Job Submission

A test is made just before CA WA CA 7 Edition submits the job. The ARF definition
specifies a date, time and relational operator. If the date and time at job submission
stands in the relation specified to the date and time in the ARF definition, then an ARF
exception is recognized.

Chapter 6: Automated Recovery Facility 219

ARFSET Structure

SC - Step Completion Check

The execution status of a job is checked at step completion. Up to six completion code
tests joined by Boolean operators may be specified in the ARF definition. Each test
allows specification of the type of code to be tested: SYS for system abends, USR for
user abends, CC for condition codes and FL for flush conditions. The test also allows a
relational operator to be specified along with the value of the code. Thus, for example a
test can specify 'CC GE 0024'. Only if the condition code of the job is greater than or
equal to 24 is an ARF condition recognized. Masking for wildcards and generics is
allowed. The following test can be specified as part of an ARF JC definition: SYS EQ +37.
This indicates that any system abend ending in 37 such as S-D37 or S-E37 will be
recognized as an ARF exception.

ARFSET Structure
Each production job that is to be monitored by ARF must specify the name of the set of
ARF definitions that will supply the criteria that ARF uses to recognize and respond to
exception conditions.

An ARFSET is a named collection of ARF definitions that can be referred to on the job
definition panel, on a scheduled override statement in production JCL, or on a DEMAND
command. If no ARFSET reference is provided when a job enters the request queue, the
job has no ARF monitoring. The ARFSET specification on the job definition panel supplies
the ARFSET reference unless it is overridden with the #ARF scheduled override
statement in the JCL. Both of these indications can be overridden on the DEMAND
command by specifying the ARFSET keyword.

ARFSETs are created and maintained using the AR.3 panel. An ARFSET contains from 1 to
20 distinct definitions. When an ARFSET is created the client must supply a UID (like the
UID specified on the job definition panel) along with a RESPONSE ID. The RESPONSE ID
will be used to logon to an internal terminal where the responses will be executed when
the exception is detected.

The naming conventions that are in effect for CA WA CA 7 Edition job definition also
apply to ARFSETs.

220 Database Maintenance Guide

 ARFSET Structure

ARF Definition Structure

Each ARFSET contains from 1 to 20 definitions. Each definition in the set must be given a
definition index that is unique within the ARFSET. The value of the definition index (or
DEFID) can range from 1 to 255.

Each definition must also specify the type of exception condition that is being defined.

In addition to the definition index and type, the definition can be considered to have
four parts:
■ The filter criteria
■ The type-specific tests
■ The responses
■ The final disposition

Filter Criteria
The filter criteria determine whether the tests for a particular type of exception are
applicable for this run of the job. If a job enters the request queue with an ARFSET
reference, then the job is considered a candidate for ARF monitoring. The filter criteria
are then used to determine whether the job is to be monitored by ARF.

The ARF definition contains criteria for tests of the system name, SCHID, restart count,
entry mode, and queue entry date and time. The job entering the request queue must
pass ALL of the tests implied by the filter criteria to be monitored by ARF.

Type Specific Tests

If a job passes all of the tests implied by the filter criteria and is monitored by ARF, the
type specific tests in the ARF definition are applied at the point in processing implied by
the exception type.

The type specific tests differ according to the type of exception condition that is to be
defined. For example, the type specific tests for an SC (step completion check) include
tests of the completion codes for the step. However, a different set of type specific tests
must be applied to evaluate an LS (late notification at job submission) condition.

Chapter 6: Automated Recovery Facility 221

ARFSET Structure

Responses
The definition of an ARF condition includes a set of actions that are to be executed in
response to the exception. The responses are numbered in the ARF definition from 1 to
7. When an ARF exception is detected, the responses associated with the exception are
queued for execution. If no other responses are executing for that job, the ARF
dispatcher will begin executing the responses for the exception in the order that they
appear in the ARF definition.

Types of Responses

Responses are defined using action statements. The format of an action statement is
much like that of a CA WA CA 7 Edition top line command. Each action statement begins
with a two-character code that declares the kind of action to be executed. Additional
parameters are supplied with keywords and are delimited by commas.

A description of the four types of action statement follows.

AC - Issue a Command

The AC action statement is used to issue a CA WA CA 7 Edition command. The only

parameter on the AC statement is the text of the command to be issued.

AW - Wait

Execution of the AW action statement causes the sequence of recovery actions to pause
for a specified number of minutes.

AM - Issue a Message

The AM action statement can be used to issue messages to the MVS console or to a
specified TSO user.

AJ - Schedule a Recovery Job

The AJ action statement is used to schedule a job defined in the CA WA CA 7 Edition

database to run on behalf of the job that is in recovery. The AJ action statement is used
to name the recovery job and to specify the number of times that the job is to be retried
in the event that it does not complete successfully. A time interval to wait between such
retries can also be coded on this statement.

Note: The AW and AJ action statements are only valid for use with the IS and JC
exception conditions. Thus, for exception types EC, EE, LA, LB, LE, LS and SC only, the AC
and AM action statements are allowed. All action statement types are valid for use with
IS and JC exceptions.

222 Database Maintenance Guide

 Implementation Considerations

Final Disposition
The final disposition indicates what action to take when all responses are complete for a
job completion exception. If an IS or JC condition is to be defined, a final disposition
must be specified. The final disposition is not valid for any other exception type.

Several options are available. The job can be restarted, it can be canceled, a normal
completion can be forced or if no ARF action is wanted, the job can be left for manual
exception handling.

Implementation Considerations
Although every attempt has been made to ensure that resources are efficiently used by
ARF, additional resources must be expended to monitor ARF exceptions. The impact of
ARF on overall CA WA CA 7 Edition throughput (if any) will vary depending on the extent
of its implementation. We therefore recommend that use of ARF be restricted to
automating recovery for jobs with recurrent and predictable problems or for those jobs
that are on a critical path.

AR.3 - ARF Condition Definition Maintenance Panel

The AR.3 ARF Condition Definition Maintenance panel lets you create, update, delete, or
review ARFSETs.

---------------- CA-7 ARF CONDITION DEFINITION MAINTENANCE ------------------

FUNCTION: (CLEAR,DELETE,EDIT,FE,FETCH,REPL,SAVE)

SET NAME:

UID :

RESPONSE ID:

DEF-COUNT: 000

PROGRAM: AR31 MSG-INDX: 00 -- AR.3 -- yy.ddd / hh:mm:ss

MESSAGE: ENTER FUNCTION, TRANSFER OR ENTER A COMMAND ON THE TOP LINE

Chapter 6: Automated Recovery Facility 223

AR.3 - ARF Condition Definition Maintenance Panel

To display the panel, enter:

■ AR.3 as the function value on any menu or formatted input panel.
■ AR.3 as a top line command.

To exit the panel:

■ Move the cursor to the top line of the panel and enter the wanted top line
command.

This panel contains the following fields:

FUNCTION
Specifies the function to be performed. Value must be the name of another panel
or one of the following:
CLEAR
Clears the panel input data fields and resets the DEF-COUNT to 0.
DELETE
Deletes an ARFSET from the database.
EDIT
Transfers the user to the ARF definition editor where individual definitions
within the ARFSET can be accessed.
FE
Combines the FETCH and EDIT commands. Retrieves all definitions in the
ARFSET and transfers to the ARF definition editor.
FETCH
Retrieves definitions for an ARFSET and puts them in the edit work area for
subsequent access through the ARF definition editor.
REPL
Replaces the existing ARFSET on the database.
SAVE
Adds a new ARFSET to the database.
Batch keyword: Positional parameter

224 Database Maintenance Guide

 AR.3 - ARF Condition Definition Maintenance Panel

SET NAME
Specifies the required name of the ARFSET that is being defined.
Limits: 1 to 8 alphanumeric characters
Batch keyword: SET
UID
Specifies the required CA WA CA 7 Edition user security identification.
Limits: 1 to 3 numeric characters from 0 through 999
Batch keyword: UID
RESPONSE ID
Specifies the ID that will be used during ARF recovery. ARF uses an internal CA WA
CA 7 Edition terminal to process any commands that are needed for ARF recovery.
This ID must have the authority to issue any commands that the ARF recovery
sequence implies. For example, if the ARFSET contains a JC definition that has a final
disposition of RESTART, then the RESPONSE ID will be used to issue a RESTART
command for the job.
If CA WA CA 7 Edition external security SUBCHECK is used, this field is validated to
make sure that the user ID updating this AR.3 panel has submit authority for the
RESPONSE ID value.
Limits: 1 to 8 alphanumeric characters. The maximum length allowable may vary
depending on the external security package used, if any.
Batch keyword: RESPONDR
DEF-COUNT
Specifies a display of the number of definitions that are in the ARF edit work file.

Chapter 6: Automated Recovery Facility 225

ARF Condition Definition Edit Panel

ARF Condition Definition Edit Panel

The ARF Condition Definition Edit panel lets you create, update, delete, or review
individual definitions in an ARFSET.

---------------------------- ARF CONDITION EDIT ----------------------------

FUNCTION: (ADD,DELETE,EXIT,FORMAT,LIST,REPL,SAVE,SR,SS) DEFCT: 00
TYPE: SYS EQ * SID EQ 0 RSTC GE 0 EM EQ * DEFID:
FROM: 01011975 0001 TO: 12312074 2359

JC, SC TST: STEP EQ * PROC EQ * PGM EQ *

CC/ABENDS : ??? GE 0000 __ ??? GE 0000 __ ??? GE 0000 __
??? GE 0000 __ ??? GE 0000 __ ??? GE 0000
EC, EE, IS, LB, LE, LS TST:
RO: GE DATE: TIME: AO: ? INT/ADJ:
RESPONSES:
1:
2:
3:
4:
5:
6:
7:
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
MESSAGE: ENTER FUNCTION, TRANSFER OR ENTER A COMMAND ON THE TOP LINE

To display the panel, enter EDIT as the function on the AR.3 panel.

To exit the panel:

■ Enter EXIT in the function field.
■ Move the cursor to the top line of the panel and enter the wanted top line
command.

Note: Test format HRC requires STEP, PROC, and PGM set to EQ *.

226 Database Maintenance Guide

 ARF Condition Definition Edit Panel

Field Descriptions

---------------------------- ARF CONDITION EDIT ----------------------------

FUNCTION: (ADD,DELETE,EXIT,FORMAT,LIST,REPL,SAVE,SR,SS) DEFCT: 00
TYPE: SYS EQ * SID EQ 0 RSTC GE 0 EM EQ * DEFID:
FROM: 01011975 0001 TO: 12312074 2359

FUNCTION
Specifies the function to be performed. Value must be the name of another panel
or one of the following:
ADD
Adds a new definition to the work area.
DELETE
Deletes a definition from the work area.
EXIT
Returns the user to the AR.3 panel and clears the edit work area. Any changes
are ignored. The DEF-COUNT has the value that it had before EDIT was entered.
FORMAT
Clears any panel input entered by user.
LIST
Lists the definition associated with the current definition index. This function
can be used to browse definitions in the ARFSET.
REPL
Replaces the current definition for this definition index in the work area. The
definition must be listed before it can be replaced.
SAVE
Updates the DEF-COUNT and returns to AR.3 panel. The ARF edit work area
changes are retained but the ARFSET is not yet updated on the database.
SR
Combination function that results in a SAVE, a return to the AR.3 panel, and a
REPL from the AR.3 panel to replace an existing ARFSET on the database.
SS
Combination function that results in a SAVE, a return to the AR.3 panel, and a
SAVE from the AR.3 panel to add a new ARFSET to the database.
Batch keyword: Positional parameter

Chapter 6: Automated Recovery Facility 227

ARF Condition Definition Edit Panel

DEFCT
Online display of the total number of ARF definitions in the ARF edit work area.
TYPE
Specifies the type of ARF exception condition to be defined. This parameter is
required and the value must be one of the following:
EC
Specifies an elapsed time check at normal job completion.
EE
Specifies an elapsed time check during job execution.
IS
Specifies a test of the date and time just prior to job submission. If an exception
is detected, the job is requeued prior to executing ARF responses.
JC
Specifies a test for an exception condition based on completion codes to be
executed when the job completes.
Note: Tests for job completion are made at each step completion. However,
ARF does not respond to a job completion until the job ends. In the event that
several job completion criteria are met, the responses associated with the
lowest definition index are executed. Only one job completion condition occurs
for a given job.
LA
Specifies an exception condition results when CA WA CA 7 Edition initially
prompts for a late condition. No type specific tests are defined for the LA
exception.
LB
Specifies a test to determine whether the job is to be regarded late when the
job begins.
LE
Specifies a test to determine whether the job is to be regarded late when the
job ends.
LS
Specifies a test to determine whether the job is to be regarded late when the
job is submitted.
SC
Specifies a test for an exception condition based on completion codes to be
executed when the specified step completes.
Batch keyword: TYPE

228 Database Maintenance Guide

 ARF Condition Definition Edit Panel

DEFID
Identifies an index that uniquely specifies this definition within the ARFSET.
Limits: 1 to 3 decimal characters
Valid values 1-255
Batch keyword: DEFID

Field Descriptions - Filter Criteria

---------------------------- ARF CONDITION EDIT ----------------------------

FUNCTION: (ADD,DELETE,EXIT,FORMAT,LIST,REPL,SAVE,SR,SS) DEFCT: 00
TYPE: SYS EQ * SID EQ 0 RSTC GE 0 EM EQ * DEFID:
FROM: 01011975 0001 TO: 12312074 2359

SYS
The following two input fields specify a test to be made on the system name
associated with the job when the job enters the request queue to determine
whether the job is to be monitored by ARF. Following the literal 'SYS' is a relational
operator input field that is set by default to 'EQ' indicating that the system name of
the job must be equal to the value in the following input field. This can be
overtyped with an 'NE' to indicate that the system name must not be equal to the
value in the following input field.
Default: EQ
Batch keyword: SYSRO
The input field immediately following the relational operator is set by default to '*'.
The default values for SYS, 'EQ *' indicate that all system names are valid. The '*'
can be changed to provide a fully or partially qualified system name to be compared
against the system name of the job entering the request queue. The value can
incorporate '+' to indicate a wildcard. An '*' terminating the string indicates a
generic. Thus for example, if the values for SYS are 'EQ PAY+23*', then any system
name beginning with 'PAY' and having '23' in the fifth and sixth positions will pass
this test.
Default: *
Limits: 1 to 8 alphanumeric characters
+ indicates a wildcard
* indicates a generic
Batch keyword: SYS

Chapter 6: Automated Recovery Facility 229

ARF Condition Definition Edit Panel

SID
The following two input fields specify a test to be made on the SCHID associated
with the job when the job enters the request queue to determine whether the job
is to be monitored by ARF. Following the literal 'SID' is a relational operator input
field that is set by default to 'EQ' indicating that the SCHID of the job must be equal
to the value in the following input field. This can be overtyped with one of the
following values:
EQ
Equal
NE
Not equal
GE
Greater than or equal to
GT
Greater than
LE
Less than or equal to
LT
Less than
The SCHID of the job entering the request queue will be compared to the value in
the input field following the relational operator. If the resulting statement is true
then the test is passed.
Default: EQ
Batch keyword: SIDRO
The input field immediately following the relational operator is set by default to '0'.
The default values for SID, 'EQ 0' indicate that all SCHIDs are valid. The '0' can be
changed to provide a fully qualified SCHID value from 001-999 to be compared
against the SCHID of the job entering the request queue.
Default: 0 (a value of 0 refers to ALL SCHIDs)
Limits: 1 to 3 numeric characters from 0 through 999
Batch keyword: SID

230 Database Maintenance Guide

 ARF Condition Definition Edit Panel

RSTC
The following two input fields specify a test to be made on the restart count of the
job to determine whether the job is to be monitored by ARF. Following the literal
'RSTC' is a relational operator input field that is set by default to 'GE' indicating that
the restart count of the job must be greater than or equal to the value in the
following input field. This can be overtyped with one of the following values:
NE
Not equal
GE
Greater than or equal to
EQ
Equal
GT
Greater than
LE
Less than or equal to
LT
Less than
The restart count of the job is compared to the value in the input field following the
relational operator. If the resulting statement is true then the test is passed.
Default: GE
Batch keyword: RSTRO
The input field immediately following the relational operator is set by default to '0'.
The default values for RSTC, 'GE 0' indicate that any restart count is valid. The '0'
can be changed to provide a fully qualified decimal value from 0 through 999 to be
compared against the restart count of the job to be considered for ARF monitoring.
Default: 0
Limits: 1 to 3 numeric characters from 0 through 999
Batch keyword: RST

Chapter 6: Automated Recovery Facility 231

ARF Condition Definition Edit Panel

EM
The following two input fields specify a test to be made on the entry mode of the
job when the job enters the request queue to determine whether the job is to be
monitored by ARF. Following the literal 'EM' is a relational operator input field that
is set by default to 'EQ' indicating that the entry mode of the job must be equal to
the value in the following input field. This can be overtyped with an 'NE' to indicate
that the entry mode must not be equal to the value in the following input field.
Default: EQ
Batch keyword: EMRO
The input field immediately following the relational operator is set by default to '*'.
The default values for EM, 'EQ *' indicate that all entry modes are valid. The '*' can
be changed to provide a fully qualified entry mode designation to be compared
against the entry mode of the job entering the request queue. Entry mode
designations valid in this field are the following:
DEMD
Job entered through a DEMAND command
DTRG
Job entered through a DSN trigger
JTRG
Job entered through a job trigger
NTRG
Job entered through a network trigger
PSCH
Job entered through personal scheduling
RPET
Job entered because it was repeated
RUN
Job entered through a RUN command
SSCN
Job entered through a schedule scan
Default: * (all entry modes)
Batch keyword: EM

232 Database Maintenance Guide

 ARF Condition Definition Edit Panel

FROM
Two input fields used to specify a date and time that is compared against the date
and time when the job enters the request queue. To pass the test, the queue entry
date and time must be greater than the date and time specified here.
FROM Date
Default: 01011975
Limits: 8 numeric character positions in MMDDYYYY format. Valid range from
01011975 to 12312074. You can also use one of the reserved words.
Batch keyword: FROMD
FROM Time
Default: 0001 (1 minute past midnight)
Limits: 4 character positions in hhmm format. Valid range from 0000 to 2359.
Batch keyword: FROMT
TO
Two input fields used to specify a date and time that is compared against the date
and time when the job enters the request queue. To pass the test, the queue entry
date and time must be less than the date and time specified here.
TO Date
Default: 12312074
Limits: 8 character positions in MMDDYYYY format. Valid range from 01011975 to
12312074. You can also use one of the reserved words.
Batch keyword: TOD
TO Time
Default: 2359 (11:59 PM)
Limits: 4 character positions in hhmm format. Valid range from 0000 to 2359.
Batch keyword: TOT

More information:

Use Reserved Words in Type Specific Tests (see page 251)

Chapter 6: Automated Recovery Facility 233

ARF Condition Definition Edit Panel

Field Descriptions - Type Specific Tests for JC and SC Conditions

JC, SC TST

JC, SC TST: STEP EQ * PROC EQ * PGM EQ *

CC/ABENDS : ??? GE 0000 __ ??? GE 0000 __ ??? GE 0000 __
??? GE 0000 __ ??? GE 0000 __ ??? GE 0000
EC, EE, LB, LE, LS TST:
RO: GE DATE: TIME: AO: ? INT/ADJ:

HRC test format requires STEP, PROC, and PGM set to EQ *.

Note: We do not recommend a JC (Job Completion) check for a good EOJ condition. A
relational operator (RO) of IG on the Job Definition (DB.1) panel assumes the job
completes successfully. Any responses specified by a JC ARFSET looking for a good EOJ
may not occur.
STEP
The following two input fields specify a test to be made on the step name (or
stepname within proc) at step or job completion for an ARF monitored job.
Following the literal 'STEP' is a relational operator input field that is set by default to
'EQ' indicating that the step name of the job must be equal to the value in the
following input field. This can be overtyped with an 'NE' to indicate that the step
name must not be equal to the value in the following input field.
Default: EQ
Batch keyword: STEPRO
The input field immediately following the relational operator is set by default to '*'.
The default values for STEP, 'EQ *' indicate that all step names are valid. The '*' can
be changed to provide a fully or partially qualified step name to be compared
against the step name of the job being monitored by ARF. The value can
incorporate '+' to indicate a wildcard. An '*' terminating the string indicates a
generic. Thus for example, if the values for STEP are 'EQ STEP++1*', then any step
name beginning with 'STEP' and having '1' in the seventh position will be considered
a candidate for an ARF exception.
Default: *
Limits: 1 to 8 characters, blanks and commas are not allowed
+ indicates a wildcard
* indicates a generic
Batch keyword: STEP

234 Database Maintenance Guide

 ARF Condition Definition Edit Panel

PROC
The following two input fields specify a test to be made on the name of the step
executing the proc at step or job completion for an ARF monitored job. Following
the literal 'PROC' is a relational operator input field that is set by default to 'EQ'
indicating that the proc name of the job must be equal to the value in the following
input field. This can be overtyped with an 'NE' to indicate that the proc name must
not be equal to the value in the following input field.
Default: EQ
Batch keyword: PROCRO
The input field immediately following the relational operator is set by default to '*'.
The default values for PROC, 'EQ *' indicate that all proc names are valid. The '*' can
be changed to provide a fully or partially qualified proc name to be compared
against the proc name of the job being monitored by ARF. The value can
incorporate '+' to indicate a wildcard. An '*' terminating the string indicates a
generic. Thus for example, if the values for PROC are 'EQ PROC++1*', then any proc
name beginning with 'PROC' and having '1' in the seventh position will be
considered a candidate for an ARF exception.
Default: *
Limits: 1 to 8 characters, commas and blanks are not allowed
+ indicates a wildcard
* indicates a generic
Batch keyword: PROC

Chapter 6: Automated Recovery Facility 235

ARF Condition Definition Edit Panel

PGM
The following two input fields specify a test to be made on the program name at
step or job completion for an ARF monitored job. Following the literal 'PGM' is a
relational operator input field that is set by default to 'EQ' indicating that the
program name of the job must be equal to the value in the following input field.
This can be overtyped with an 'NE' to indicate that the program name must not be
equal to the value in the following input field.
Default: EQ
Batch keyword: PGMRO
The input field immediately following the relational operator is set by default to '*'.
The default values for PGM, 'EQ *' indicate that all program names are valid. The '*'
can be changed to provide a fully or partially qualified program name to be
compared against the program name of the job being monitored by ARF. The value
can incorporate '+' to indicate a wildcard. An '*' terminating the string indicates a
generic. Thus for example, if the values for PGM are 'EQ PROG++1*', then any
program name beginning with 'PROG' and having '1' in the seventh position will be
considered a candidate for an ARF exception.
Default: *
Limits: 1 to 8 characters, commas and blanks are not allowed
+ indicates a wildcard
* indicates a generic
Batch keyword: PGM
CC/ABENDS
(Optional) Up to six tests of completion codes can be coded here and joined by
Boolean operators to create complex completion code tests.
The first input field in a completion code test allows specification of the format of
the completion code test. Overtype this field with one of the following values to
define a completion code test:
???
Indicates no completion code test.
SYS
Indicates the completion code to be tested is a system abend code.
USR
Indicates the completion code to be tested is a user abend code.

236 Database Maintenance Guide

 ARF Condition Definition Edit Panel

CC
Indicates the completion code to be tested is a condition code.
FL
Indicates to perform a test for a flush condition. If this value is used, the
corresponding completion code field is ignored, and the only relational
operator arguments permitted are EQ and NE.
JCL
Indicates to perform a test for a JCL error. If this value is used, the
corresponding completion code is ignored, and the only relational operator
arguments permitted are EQ and NE.
HRC
Indicates to test the highest condition code from any step at the end of the job.
An HRC test can only be used in an ARF JC Exception definition. It can only be
combined with other HRC tests.
Default: ??? (indicates no test)
Batch keyword: FMT1, FMT2, FMT3, FMT4, FMT5, FMT6
Note: CC tests (in either SC or JC definitions) are performed for each step of a job
and may result in multiple ARF responses for the same job. HRC tests are only
performed after the last executed step of a job using the highest condition code
from any of the executed steps. A positive HRC test results in only one set of
responses even if multiple steps meet the test.
The second input field in a completion code test allows specification of the
relational operator to be used in the completion code test. The default is 'GE'.
This can be overtyped with one of the following values:
NE
Not equal
GE
Greater than or equal to
EQ
Equal

Chapter 6: Automated Recovery Facility 237

ARF Condition Definition Edit Panel

GT
Greater than
LE
Less than or equal to
LT
Less than
Default: GE
Limits: Optional unless the first input has a value other than ???
Batch keyword: RO1, RO2, RO3, RO4, RO5, RO6
The third input field in a completion code test allows specification of the
completion code value to be used in a completion code test. The default is '000'.
This value can be overtyped with a character value appropriate for the format of
the completion code test. For example, if the first input field in the test contains
'SYS' indicating a system abend, then a valid completion code value might be 'E37'.
The completion code value can contain '+' to indicate a wildcard and '*' for
generics. For example, the following completion code test would cause an ARF
exception to be recognized for any system abend ending in '37': 'SYS EQ +37'.
Note: S822 abends cannot be "caught" because the IBM SMF step term record
does not contain the needed information.
Default: 000
Limits: For SYS, 3 valid hexadecimal characters
For USR and CC, 1 to 4 decimal characters
Limits: Optional unless the first input has a value other than ???
Batch keyword: VAL1, VAL2, VAL3, VAL4, VAL5, VAL6
Completion code tests can be joined using the following logical connectives:
&
Indicates the tests are to be 'and'ed
/
Indicates the tests are to be 'or'ed
Default: __ indicating no connective
Limits: Optional unless tests are to be joined.
Batch keyword: LO1, LO2, LO3, LO4, LO5

238 Database Maintenance Guide

 ARF Condition Definition Edit Panel

Field Descriptions - Type Specific Tests for EC, EE, IS, LB, LE and LS
Conditions

JC, SC TST: STEP EQ * PROC EQ * PGM EQ *

CC/ABENDS : ??? GE 0000 __ ??? GE 0000 __ ??? GE 0000 __
??? GE 0000 __ ??? GE 0000 __ ??? GE 0000
EC, EE, IS, LB, LE, LS TST:
RO: GE DATE: TIME: AO: ? INT/ADJ:

The following fields are used to define condition tests for EC, EE, IS, LB, LE and LS
condition types. The fields required vary according to the condition type to be defined.
RO
This input field can be used with the following condition types: EC, IS, LB, LE and LS.
Data from this field as well as the TIME, AO and INT/ADJ fields is used to construct a
date and time test to determine if an ARF condition exists. The relational operator
for the test is provided in this field.
If the condition type is IS, the date/time when CA WA CA 7 Edition attempts to
submit the job is compared with the date/time expression built from the input
fields following this relational operator. An ARF condition occurs if the indicated
relation obtains.
If the condition type is LB, the date/time when the job begins is compared with the
date/time expression that is built from data provided in the input fields following
this relational operator. An ARF condition occurs if the indicated relation obtains.
If the condition type is LE, the date/time when the job ends is compared with the
date/time expression that is built from data provided in the input fields following
this relational operator. An ARF condition occurs if the indicated relation obtains.
If the condition type is LS, the date/time when the job submits is compared with the
date/time expression that is built from data provided in the input fields following
this relational operator. An ARF condition occurs if the indicated relation obtains.
If the condition type is EC, the elapsed time when the job completes is compared
with the value in the input field tagged INT/ADJ. An ARF condition occurs if the
indicated relation obtains.

Chapter 6: Automated Recovery Facility 239

ARF Condition Definition Edit Panel

The relational operator is ignored for the EE test. The only valid input field is
INT/ADJ.
The default is 'GE'.
This can be overtyped with one of the following values:
NE
Not equal
GE
Greater than or equal to
GT
Greater than
EQ
Equal
LE
Less than or equal to
LT
Less than
Default: GE
Limits: Required for EC, IS, LB, LE and LS condition types. It should not be specified
for any other condition type.
Batch keyword: TRO

240 Database Maintenance Guide

 ARF Condition Definition Edit Panel

DATE
This input field can be used with the following condition types: IS, LB, LE and LS.
Data from this field as well as the TIME, AO, and INT/ADJ fields is used to construct
a date and time that is used in a comparison to determine if an ARF condition exists.
An ARF condition occurs if the relation indicated by the RO value obtains.
If the condition type is IS, the date/time when CA WA CA 7 Edition attempts to
submit the job is compared with the date/time expression specified here.
If the condition type is LB, the date/time when the job begins is compared with the
date/time expression specified here.
If the condition type is LE, the date/time when the job ends is compared with the
date/time expression specified here.
If the condition type is LS, the date/time when the job submits is compared with the
date/time expression specified here.
Limits: 8 character positions in MMDDYYYY format. Valid range from 01011975 to
12312074. Or you can use one of the reserved words.
Required for IS, LB, LE and LS condition types. It should not be specified for any
other condition types.
Batch keyword: TDAT
TIME
This input field can be used with the following condition types: IS, LB, LE and LS.
Data from this field as well as the DATE, AO and INT/ADJ fields is used to construct a
date and time that is used in a comparison to determine if an ARF condition exists.
If the condition type is IS, the date/time when CA WA CA 7 Edition attempts to
submit the job is compared with the date/time expression specified here.
If the condition type is LB, the date/time when the job begins is compared with the
date/time expression specified here.
If the condition type is LE, the date/time when the job ends is compared with the
date/time expression that is specified here.
If the condition type is LS, the date/time when the job submits is compared with the
date/time expression that is specified here.
Limits: 4 character positions in hhmm format. Valid range from 0000 to 2359. You
can also use one of the reserved words.
Required for IS, LB, LE and LS condition types. It should not be specified for any
other condition types.
Batch keyword: TTIM

Chapter 6: Automated Recovery Facility 241

ARF Condition Definition Edit Panel

AO
This input field can be used with the following condition types: IS, LB, LE and LS.
Data from this field as well as the DATE, TIME and INT/ADJ fields is used to
construct a date and time that is used in a comparison to determine if an ARF
condition exists.
Data from this field along with data in the INT/ADJ field is used to adjust the
date/time value provided in the DATE and TIME fields. If the increment used as an
adjustment is to be added, use '+', if it is to be subtracted, use '-'.
If the condition type is IS, the date/time when CA WA CA 7 Edition attempts to
submit the job is compared with the date/time expression specified here.
If the condition type is LB, the date/time when the job begins is compared with the
date/time expression specified here.
If the condition type is LE, the date/time when the job ends is compared with the
date/time expression that is specified here.
If the condition type is LS, the date/time when the job submits is compared with the
date/time expression that is specified here.
Limits: 1 position. Allowable values are '+' or '-'.
Only allowable on IS, LB, LE and LS condition types. It should not be specified for
any other condition types. It should only be used if an adjustment value is provided
in the INT/ADJ field.
Batch keyword: TAO
INT/ADJ
This input field can be used with the following condition types: EC, EE, IS, LB, LE and
LS. Data from this field can be interpreted as an adjustment to a date and time
already specified; this is its meaning if the condition type is IS, LB, LE or LS. If the
condition type is EC or EE, then the value in this field is interpreted as an elapsed
time interval.
The value of this field should be specified in hhmm format, and is valid within +/- 1
minute.
Limits: 4 character positions in hhmm format. Valid range from 0000 to 2359. You
can also use one of the reserved words in the table in the Reserved Words in Type
Specific Tests.
Required for EE and EC
Allowed for IS, LB, LE, and LS.
It should not be specified for any other condition types.
Batch keyword: INT

More information:

Use Reserved Words in Type Specific Tests (see page 251)

242 Database Maintenance Guide

 ARF Condition Definition Edit Panel

Field Descriptions - Responses

RESPONSES:

1:
2:
3:
4:
5:
6:
7:
FINAL -- DISP : N CA-11?: N BYPGDG: N USAGE: PROCESS: CC:

(Optional) In this section of the AR.3 panel are seven lines where you can specify ARF
responses. Responses cannot be continued across lines. Each line of input is taken to be
a separate response that will be executed when this ARF condition is detected.

A valid ARF action statement must be coded on each non-blank response line.

Limits: 74 character positions for input. Format must conform to rules for coding ARF
statements.

Batch keyword: RSP1, RSP2, RSP3, RSP4, RSP5, RSP6, RSP7

Note: Batch syntax requires that action statements be enclosed in parentheses.

Additional parentheses can be needed depending on action statement keywords and
parameters.

More information:

Rules for Coding ARF Action Statements (see page 247)

Chapter 6: Automated Recovery Facility 243

ARF Condition Definition Edit Panel

Field Descriptions - Final Disposition

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
MESSAGE: ENTER FUNCTION, TRANSFER OR ENTER A COMMAND ON THE TOP LINE

This section of the AR.3 panel describes the action that is to be taken after all ARF
responses have been issued.

Note: This section is ignored unless the condition type is IS or JC.

FINAL -- DISP
This input field indicates the action to be taken when all ARF responses have been
issued. The valid values are the following:
N
Take no action, the job is left for manual recovery. Subsequent restarts will
continue to be monitored by ARF. N is the default.
R
Restart the job using the CA WA CA 7 Edition top-line RESTART command.
Additional parms for the command can be supplied using other input fields in
the final disposition section. The JCL override requirement will always be
posted if this option is used. This is not valid for an IS condition.
C
Cancel the job using the CA WA CA 7 Edition top-line CANCEL command.
F
Force completion of this job using the RESTART command with the
FORCECOMP option.
P
Issue an ARFP command to purge ARF records for this job. Subsequent restarts
will not be monitored by ARF.
Default: N (no action)
Limits: Required if condition type is IS or JC. Ignored for all other condition types.
Batch keyword: DSP

244 Database Maintenance Guide

 ARF Condition Definition Edit Panel

CA-11?
(Optional) This input field indicates whether CA WA Restart Option is to be used for
restart. The valid values are the following:
N
No, CA WA Restart Option is not to be used for restart. This is the default.
Y
Yes, CA WA Restart Option is to be used for restart. Other input values in the
final disposition section may be relevant.
Default: N (CA WA Restart Option not used)
Limits: Required only if CA WA Restart Option is to be used for restart.
Batch keyword: CA11
BYPGDG
(Optional) This input field indicates the value on the RESTART command. For more
information, see the documentation on the RESTART command.
Valid values are the following:
C
CA WA Restart Option to accept GDG bias resolution according to the MVS
catalog (CAT option of CA WA Restart Option).
N
This is the default. CA WA Restart Option should NOT bypass GDG logic on
restart.
V
CA WA Restart Option to verify that the GDG bias resolution recorded in the
CMT agrees with the MVS catalog (VER option of CA WA Restart Option).
Y
Yes, CA WA Restart Option should bypass GDG logic on restart.
Default: N (CA WA Restart Option will not bypass GDG logic)
Batch keyword: BYPGDG
USAGE
(Optional) Supplies the value of the USAGE parameter to be used on the RESTART
command. For values, see the CA WA Restart Option documentation. This option
honored only if CA WA Restart Option used and CA WA CA 7 Edition is inserting the
RMS step. For more information, see the documentation on the INSERT-RMS field
of the DB.1 panel and on the RESTART command.
Limits: 1 alphanumeric character
Batch keyword: USAGE

Chapter 6: Automated Recovery Facility 245

ARF Condition Definition Edit Panel

PROCESS
(Optional) Supplies the value of the PROCESS parameter to be used on the RESTART
command. This option honored only if CA WA Restart Option used and CA WA CA 7
Edition is inserting the RMS step. Valid values are F, P, S, N, O or R. For more
information, see the documentation on the INSERT-RMS field of the DB.1 panel and
on the RESTART command.
Limits: 1 alphanumeric character
Batch keyword: PROCESS
CC
(Optional) Supplies the value of the CONDCD parameter to be used on the RESTART
command. This option honored only if CA WA Restart Option used and CA WA CA 7
Edition is inserting the RMS step. For more information, see the documentation on
the INSERT-RMS field of the DB.1 panel and on the RESTART command.
Limits: 1 to 4 alphanumeric characters from 0-4095
Batch keyword: CC
START
(Optional) Supplies values of the PROCSTRT and STPSTRT parameters on the
RESTART command. This option honored only if CA WA Restart Option used.
The format of the START value is 'procstep.step' where 'procstep' is the value of the
PROCSTRT keyword and 'step' is the value of the STPSTRT keyword. If the value of
this field does not contain a '.' then it is assumed that the input applies only to the
STPSTRT keyword. If the step number is used, then PROCSTRT cannot be used.
For more information, see the documentation on the RESTART command.
Limits: 1 to 17 alphanumeric characters. If procstep reference is provided, a '.' must
separate procstep name and step name. You should validate this value prior to use
to ensure that the steps named here are used by the job that uses this ARFSET.
Batch keyword: START
END
(Optional) Supplies values of the PROCEND and STPEND parameters on the
RESTART command. This option honored only if CA WA Restart Option used.
The format of the END value is 'procstep.step' where 'procstep' is the value of the
PROCEND keyword and 'step' is the value of the STPEND keyword. If the value of
this field does not contain a '.' then it is assumed that the input applies only to the
STPEND keyword. If the step number is used, then PROCEND cannot be used.
For more information, see the documentation on the RESTART command.
Limits: 1 to 17 alphanumeric characters. If procstep reference is provided, a '.' must
separate procstep name and step name. You should validate this value prior to use
to ensure that the steps named here are used by the job that uses this ARFSET.
Batch keyword: END

246 Database Maintenance Guide

 Rules for Coding ARF Action Statements

Rules for Coding ARF Action Statements

An ARF action statement is coded in the RESPONSE section of an ARF condition
definition and describes an action or set of actions that will be taken in response to the
occurrence of an ARF condition.

Each ARF statement begins with an identifier that indicates the type of action statement
that is being coded. Parameters on an ARF action statement are provided in keyword
format and are separated by commas.

ARF has four action statement types. A description of each statement type and its
associated parameters follows.

Note: The AW and AJ action statements are only valid for use with the IS or JC
exception conditions. Thus, for exception types EC, EE, LA, LB, LE, LS and SC, only the AC
and AM action statements are allowed. All action statement types are valid for use with
IS and JC exceptions.

AC - Issue a Command
Statement Identifier

AC

Purpose

The AC action statement is used to issue a CA WA CA 7 Edition command.

Format

The allowable keyword is:

M=
The data following the M= keyword is assumed to be valid CA WA CA 7 Edition
terminal input. The format of the command must adhere to the conventions used
for the TRAILER terminal. The maximum length is 69.

Example

The example illustrates the use of the AC action statement to issue a DEMAND
command to request the PAYROLL job.

AC,M=DEMAND,JOB=PAYROLL

Chapter 6: Automated Recovery Facility 247

Rules for Coding ARF Action Statements

AM - Issue a Message
Statement Identifier

AM

Purpose

Execution of the AM action statement causes a message to be issued to the MVS

console or to a specified TSO user.

Format

The following are the allowable keywords:

CM=
The data following the CM= specifies the communications mode for the message.
The following are the acceptable values of CM=:
T
Send the message to the user whose TSO ID is specified using the U= keyword.
The message is not retained if the specified TSO user is not logged on.
L
Send the message to the user whose TSO ID is specified using the U= keyword.
If the specified TSO user is not logged on, the message will be retained and can
be displayed in the next TSO session.
C
Send the message to the MVS console.
H
Send the message to the MVS console and highlight them.
U=
The data following the U= names the TSO user that is to receive the message. This
value is required if CM=T or CM=L. It is invalid for any other value of CM. This
keyword can also be coded as USER=.
M=
The data following the M= specifies the text of a message that is to be issued. If the
text contains commas or keywords (x=y), enclose the entire text string in
parentheses. The maximum length is 60 characters.

248 Database Maintenance Guide

 Rules for Coding ARF Action Statements

Examples

The example illustrates the use of the AM action statement to send the message "HELLO
THERE!" to a TSO user.

AM,CM=T,U=TSOUSER1,M=HELLO THERE!

The example illustrates the use of the AM action statement to send the message "HELLO
CONSOLE!" to the MVS console.

AM,CM=C,M=HELLO CONSOLE!

AW - Wait
Statement Identifier

AW

Purpose

Execution of the AW action statement causes the sequence of recovery actions to pause
for a specified number of minutes.

Format

The allowable keyword is:

TIME=
The data following the TIME= keyword specifies the number of minutes that ARF
should wait before proceeding to execute the next recovery action. This is a decimal
number of minutes from 0001 to 9999. This keyword can also be coded as T=.

Example

AW,TIME=0002

The example above illustrates the use of the AW action statement to cause a 2 minute
pause in ARF recovery for a given job.

Chapter 6: Automated Recovery Facility 249

Rules for Coding ARF Action Statements

AJ - Schedule a Recovery Job

Statement Identifier

AJ

Purpose

The AJ action statement is used to schedule a job (known as an 'ARFJ' job) to run on
behalf of the job that is in recovery. ARF will not proceed to the next ARF action
statement until this action statement is considered complete. An AJ action statement is
complete when the ARFJ job completes successfully or when the specified number of
retries is exhausted.

Note: The completion of an ARFJ job does not satisfy requirements, nor does it cause
triggering of other jobs. However, CA WA CA 7 Edition tracks the progress of the ARFJ
job and records its completion status in the run log and in messages to the master
station.

Also, ARFSET designations (such as those on the job definition panel or on #ARF
statements in the JCL) are ignored for ARFJ jobs. Thus, ARFJ jobs are not monitored for
ARF recovery.

Format

The allowable keywords are the following:

JOB=
The value of this keyword names the job that is to run on behalf of the job that is in
recovery. This keyword is required and has no default.
RETRY=
If the ARFJ job does not complete successfully, ARF can request the job again. The
value of the RETRY parameter is the maximum number of times the job can be
retried. The acceptable values are 0-9. The default value is RETRY=0.

250 Database Maintenance Guide

 Use Reserved Words in Type Specific Tests

DELAY=
If the ARFJ job does not complete successfully, ARF can request the job again. The
value on the DELAY keyword specifies the number of minutes before retrying. This
value must be specified as a decimal number of minutes from 0 to 9999. The
default value is DELAY=0000.
ACTION=
If the ARFJ job does not complete successfully and if all retries are exhausted, then
the ACTION keyword value determines the disposition of the ARFJ job. This keyword
is required and has no default. Acceptable values are the following:
E
Suspend ARF recovery for this job. The LARFQ display indicates that the job is in
error status.
N
Take no action. Continue with next ARF action statement in sequence.
1-7
Jump to the ARF recovery action indicated.

Example

The example illustrates the use of the AJ action statement to request an ARFJ job named
X. If the job does not complete successfully, retry after waiting 1 minute. If the job still
does not complete successfully jump to the 4th action statement in the definition.

AJ,JOB=X,RETRY=1,DELAY=1,ACTION=4

Use Reserved Words in Type Specific Tests

Certain values are not capable of being exactly defined at the time an ARF condition is
defined. For example, the due-out time cannot be known until the job enters the
request queue. For such values, ARF provides a limited number of reserved words that
can be used in certain fields on the AR.3.1 panel. The value of an ARF reserved word is
resolved at the time the value is needed for ARF condition evaluation.

The following table describes each of these reserved words:

Name Description Relevant AR.3 Panel Fields

DOD The due-out date of the job. FROM: (first input field)
TO: (first input field)
DATE:

Chapter 6: Automated Recovery Facility 251

Use Reserved Words in Type Specific Tests

Name Description Relevant AR.3 Panel Fields

DOT The due-out time of the job. FROM: (second input field)
TO: (second input field)
TIME:
DLD The deadline date of the job. FROM: (first input field)
TO: (first input field)
DATE:
DLT The deadline time of the job. FROM: (second input field)
TO: (second input field)
TIME:
EL The current value from INT/ADJ:
JQJELTME for this job; the
elapsed time used by the job.

These reserved words can be used to build arithmetic expressions as in the following
example:

DLD+12

This expression is taken to indicate the deadline date plus 12 days.

Syntax

If used in an arithmetic expression, the reserved word must be followed immediately

(no spaces) by an arithmetic operator (either + or -). If an arithmetic operator is present,
it must be followed immediately (no spaces) by a decimal numeric value (up to four
digits). The value of the reserved word will be incremented or decremented by the
amount specified. The unit of the increment/decrement depends on the reserved word.
For example, if the expression is DOT+0020, this is interpreted as the due-out time plus
20 minutes.

252 Database Maintenance Guide

 Use Variables in ARF Action Statements

Use Variables in ARF Action Statements

You can reference some values in ARF action statements using variables. These variables
can be used in AM and AC action statements. The following list describes each of these
variables:
&ARFSET
Specifies the name of the ARFSET referenced by this run of the job.
&AARDATE
Specifies the date the ARFSET referenced by this job was first used for the ARF
monitoring.
&AARTIME
Specifies the time the ARFSET referenced by this job was first used for the ARF
monitoring.
&ARFRESP#
Specifies the number of the response being processed.
&ARFSETIX
Specifies the index of the definition being processed.
&INTDATE
Specifies the date this ARF condition was detected.
&INTTIME
Specifies the time this ARF condition was detected.
&JES#
Specifies the JES number of the job in ARF recovery. &JES# is not applicable to
cross-platform job types and is not always available for some exception conditions
(for example, IS, LS, and LA).
&JOB#
Specifies the CA WA CA 7 Edition job number of the job in ARF recovery.
&JOBL
Specifies the long job name of the job in ARF recovery.
&JOBNAME
Specifies the name of the job in ARF recovery.
&SCHDID
Specifies the schedule ID of the job in ARF recovery.
&SYSTEM
Specifies the system name of the job in ARF recovery.

Chapter 6: Automated Recovery Facility 253

Examples of ARF Condition Definition

Examples of ARF Condition Definition

The following pages contain detailed examples of using the AR.3 panels to define ARF
conditions and responses. Additional examples are available through the online HELP
facility. An index of ARF help topics can be found in the AR00 help member.

Defining a Job Completion Condition (JC)

Suppose that the PAYROLL job is known to suffer repeated x37 system abends. The
response to an x37 abend for the PAYROLL job is to notify the operator that the REORG
job is to be run. When the REORG job completes, the PAYROLL job should be restarted.
The job can be restarted exactly one time.

This example illustrates how CA WA CA 7 Edition ARF can be used to automate this
recovery procedure. The definition is coded as in the following figure:

---------------------------- ARF CONDITION EDIT ----------------------------

FUNCTION: ADD (ADD,DELETE,EXIT,FORMAT,LIST,REPL,SAVE,SR,SS) DEFCT: 00
TYPE: JC SYS EQ * SID EQ 0 RSTC EQ 0 EM EQ * DEFID: 1
FROM: 01011975 0001 TO: 12312074 2359

JC, SC TST: STEP EQ * PROC EQ * PGM EQ *

CC/ABENDS : SYS EQ +37 __ ??? GE 0000 __ ??? GE 0000 __
??? GE 0000 __ ??? GE 0000 __ ??? GE 0000
EC, EE, IS, LB, LE, LS TST:
RO: GE DATE: TIME: AO: ? INT/ADJ:
RESPONSES:
1: AM,CM=H,M=ATTENTION! &JOBNAME(&JOB#) HAS ABENDED!
2: AJ,JOB=REORG,DELAY=0000,RETRY=0000,ACTION=N
3: AM,CM=H,M=ATTENTION! &ARFSET ACTIONS COMPLETE FOR &JOBNAME(&JOB#)
4:
5:
6:
7:
FINAL -- DISP : R CA-11?: N BYPGDG: N USAGE: PROCESS: CC:
START : END :
PROGRAM: AR32 MSG-INDX: 00 -- AR.3.1 -- yy.ddd / hh:mm:ss
MESSAGE: ENTER FUNCTION, TRANSFER OR ENTER A COMMAND ON THE TOP LINE

254 Database Maintenance Guide

 Examples of ARF Condition Definition

In this example note that the definition is new and is being added. Thus, the value in the
FUNCTION field is 'ADD'. TYPE is required. The value here is 'JC' to indicate that a job
completion condition is being defined. The definition requires an index, the value here is
'1'.

Most of the defaults for the filter criteria are acceptable. However, this definition will
only apply to the first run of the job. If it is restarted, this definition will not be
applicable because the RSTC test specifies 'EQ 0'.

The type specific test indicates that it is to apply to any step, proc, and program in the
job. A system abend code test is indicated so that any 'x37' system abend is to be
recognized as an ARF exception. ARF allows a wildcard specification as in '+37' to
indicate that this definition is for any 'x37' abend.

Assume that a run of PAYROLL (CA WA CA 7 Edition job number: 0211) has abended
with a S-D37 abend. Assume too, that the definition in this example is used for ARF
monitoring and is contained in ARFSET: PAYMON. When the condition is detected, ARF
will send the following highlighted message to the MVS console:

ATTENTION! PAYROLL(211) HAS ABENDED!

Note the use of ARF variables to refer to the job name and CA WA CA 7 Edition job
number. After issuing this message, ARF will submit a job named REORG to run on
behalf of PAYROLL. When the job completes, the following highlighted message will be
sent to the MVS console:

ATTENTION! PAYMON ACTIONS COMPLETE FOR PAYROLL(211)

Because the condition defined is for job completion, the final disposition is processed
when all other action statements for the definition have been handled. In this case, the
job is to be restarted without CA-11.

Chapter 6: Automated Recovery Facility 255

Examples of ARF Condition Definition

Defining a Late at Job End Notification (LE)

The PAYROLL job has problems with x37 system abends, but it also has a tendency to
run rather late on occasion. So ARF will be used to set up a notification based upon a
test of an exact date and time. This test will be executed when the job completes. The
notification should occur when the job completes if it is 30 minutes or more past the
due-out date and time.

This example illustrates how CA WA CA 7 Edition ARF can be used to automate this
recovery procedure. The definition is coded as in the following figure:

---------------------------- ARF CONDITION EDIT ----------------------------

FUNCTION: ADD (ADD,DELETE,EXIT,FORMAT,LIST,REPL,SAVE,SR,SS) DEFCT: 01
TYPE: LE SYS EQ * SID EQ 0 RSTC EQ 0 EM EQ * DEFID: 2
FROM: 01011975 0001 TO: 12312074 2359

JC, SC TST: STEP EQ * PROC EQ * PGM EQ *

CC/ABENDS : ??? GE 0000 __ ??? GE 0000 __ ??? GE 0000 __
??? GE 0000 __ ??? GE 0000 __ ??? GE 0000
EC, EE, IS, LB, LE, LS TST:
RO: GE DATE: DOD TIME: DOT AO: + INT/ADJ: 0030
RESPONSES:
1: AM,CM=T,U=FRED,M=HEY FRED! YOUR PAYCHECK COULD BE DELAYED!!
2:
3:
4:
5:
6:
7:
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
MESSAGE: ENTER FUNCTION, TRANSFER OR ENTER A COMMAND ON THE TOP LINE

In this example note that the definition is new and is being added. Thus, the value in the
FUNCTION field is 'ADD'. The value of DEFCT is 1 that reflects the fact that a definition
has already been added for the job completion condition in the example above. The
TYPE value is required, the value here is 'LE' indicating a "late at job end" notification is
to be defined. The definition also requires an index, the value here is '2'.

The defaults for the filter criteria are acceptable.

256 Database Maintenance Guide

 Examples of ARF Condition Definition

In the relevant type specific test section, the RO value is 'GE', the DATE is 'DOD', the
TIME is 'DOT', the arithmetic operator is '+' and the INT/ADJ value is '0030'. When the
job completes, ARF will test the date and time at job completion to determine if it is
greater than or equal to the due-out date and time plus 30 minutes.

When the ARF condition is detected, the following message will be sent to the TSO user
whose ID is 'FRED':

HEY FRED! YOUR PAYCHECK COULD BE DELAYED!!!

No other actions follow this one. Since this is not a job completion event, no final
disposition processing occurs. ARF recovery is complete for this exception.

Chapter 6: Automated Recovery Facility 257

Chapter 7: Workload Documentation
This section contains the following topics:
Overview (see page 259)
Workload Documentation Panels (see page 260)
Special Documentation Features (see page 283)

Overview
CA WA CA 7 Edition permits the entry of free-form user documentation (prose) of the
workload at virtually any level. Prose can range from a general description to specific
instructions on how a particular function at a specified workstation is performed. The
following items are some of the documentation features:
■ Ready access to documentation through CA WA CA 7 Edition terminals.
■ Real-time, online updating from a change control or production control area.
■ Segmenting documentation into user-defined categories (that is, restart
information, user abends, control statement layouts, balancing instructions, setup
requirements, and so forth).
■ Adding documentation (prose) through any authorized CA WA CA 7 Edition terminal
using the DB.4 panels and edit facility of database maintenance.

Once defined, you can define documentation:

■ With the LPROS command.
■ With the DB.4 panels (on which the documentation is also defined and maintained).
■ As a list option in several other inquiry commands such as LQ, LPRE, LJOB.
■ Automatically in some cases.

More information:

Special Documentation Features (see page 283)

Chapter 7: Workload Documentation 259

Workload Documentation Panels

Workload Documentation Panels

CA WA CA 7 Edition has six predefined major categories of documentation, each with its
own unique definition panel. Within the documentation that is defined through these
panels, the user can embed special user-defined segments.

You can select the appropriate panel from the DB.4 Menu display. Some separate panels
are provided for the following types:
■ Job documentation
■ System documentation
■ Network documentation
■ User-designated documentation
■ Data set documentation
■ DD documentation

If user documentation already exists, a user program could be coded to produce Batch
Terminal Interface PROSE commands. These commands with the documentation could
be the input to the Batch Terminal Interface program, and the documentation could be
added to the CA WA CA 7 Edition database.

Also, assume that the documentation exists as members of a PDS that is available to CA
WA CA 7 Edition. In this case, the documentation could be fetched and edited using the
DB.7 panel and saved in the Active Area. The user could then enter the top line DB.4
command and select the appropriate category. Next, the user can perform the EDIT
function, and then SAVE the documentation to the database. Both of these methods
could save the user from having to retype a long documentation description.

More information:

Special Documentation Features (see page 283)

DB.4 - Workload Documentation Menu Panel

The DB.4 - Workload Documentation Menu panel lets you select various documentation
functions.

To display the panel, enter:

■ 4 as the FUNCTION on the DB Menu panel.
■ DB.4 as the FUNCTION on any other menu or formatted input panel.
■ DB.4 or PROSE as a top line command.

260 Database Maintenance Guide

 Workload Documentation Panels

To exit the panel:

■ Press PF3 to return to the DB Menu panel except with the TSO/ISPF interface when
PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

Select the wanted documentation type by entering the appropriate FUNCTION value
and pressing the Enter key.

--------------------- CA-7 WORKLOAD DOCUMENTATION MENU ---------------------

FUNCTION ===> xxxxxxxx

DOCUMENTATION FOR:
1 - CPU JOB
2 - INPUT/OUTPUT NETWORK
3 - USER-DEFINED ITEM
4 - DATA SET
5 - DD STATEMENT
6 - APPLICATION SYSTEM

PROGRAM: SM10 MSG-INDX: nn -- DB.4 -- yy.ddd / hh:mm:ss

MESSAGE:

DB.4.1 - CPU Job Documentation Panel

The DB.4.1 - CPU Job Documentation panel lets you define free-form job level
documentation. You can define documentation in one continuous stream for the
specified job.

Also, you can subdivide the documentation into segments and subsegments.

To display the panel, enter:

■ 1 as the FUNCTION on the DB.4 Menu panel.
■ 4.1 as the FUNCTION on the DB Menu panel.
■ DB.4.1 as the FUNCTION on any other menu or formatted input panel.
■ DB.4.1 or PROSE,JOB as a top line command.

Chapter 7: Workload Documentation 261

Workload Documentation Panels

To exit the panel:

■ Press PF3 to return to the DB.4 Menu panel except with the TSO/ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

------------------------ CA-7 CPU JOB DOCUMENTATION ------------------------

FUNCTION: xxxxxxxx (APPEND,CLEAR,DELETE,EDIT,FE,FETCH,LIST,REPL,SAVE,UPD)

JOB: xxxxxxxx
SYSTEM: xxxxxxxx

DESC: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx LINK: nnnnnn

ACTIVE SIZE: nnnn

PROGRAM: SM11 MSG-INDX: nn -- DB.4.1 -- yy.ddd / hh:mm:ss

MESSAGE:

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following values:
APPEND
Retrieves documentation data from the database and attaches documentation
text to the end of any existing lines in the Active Area (text work area).
CLEAR
Clears panel input data fields and clears the Active Area of the user.
DELETE
Deletes a documentation member from the database.
EDIT
Transfers the user to the edit facility and permits text processing.
FE
Combines FETCH and EDIT.

262 Database Maintenance Guide

 Workload Documentation Panels

FETCH
Retrieves documentation data from the database and replaces the Active Area
of the user with documentation text.
LIST
Lists documentation data only. In batch, a formatted panel is not listed; only a
found or not found message is returned.
REPL
Replaces a documentation member in the database.
SAVE
Adds a documentation member to the database.
UPD
Updates the DESC and the LINK fields only. UPD does not affect the
documentation text.
Batch keyword: Positional parameter
n/a
Contains a constant value of JOB for job documentation.
Limits: Required for batch only.
Batch keyword: Positional parameter
JOB
Specifies the job name for which the indicated function is performed.
Limits: 1 to 8 alphanumeric characters
Batch keyword: JOB
SYSTEM
(Optional) Specifies the system name or system ID related to the job for the
documentation being defined.
Limits: 1 to 8 alphanumeric characters
Batch keyword: SYSTEM
DESC
(Optional) Specifies an optional description of the job.
Limits: 1 to 45 alphanumeric characters
Batch keyword: DESC

Chapter 7: Workload Documentation 263

Workload Documentation Panels

LINK
(Optional) Specifies the number of another documentation member to link to the
documentation member listed. Linking documentation members together causes
them to be listed together as if they were a single member. The LINK member is
listed after the requested member when using the LPROS command only.
Limits: 1 to 6 numeric characters
Batch keyword: LINK
Note: You can create an LPROS loop. Do not link linked documentation to itself. The
following example shows a loop:
A linked to B
B linked to C
C linked to A

ACTIVE SIZE
Identifies a system-generated field that shows the number of lines of text existing in
the Active Area for the current terminal session.

More information:

Special Documentation Features (see page 283)

Using the Edit Facility (see page 341)

DB.4.2 - Input/Output Network Documentation Panel

The DB.4.2 - Input/Output Network Documentation panel lets you define network level
documentation. Do not use this panel when the SCHD-PROSE field on the DB.5 panel
was used for the network. You can define documentation in one continuous stream for
the specified network.

Also, you can subdivided documentation into segments and subsegments.

To display the panel, enter:

■ 2 as the FUNCTION on the DB.4 Menu panel.
■ 4.2 as the FUNCTION on the DB Menu panel.
■ DB.4.2 as the FUNCTION on any other menu or formatted input panel.
■ DB.4.2 or PROSE,NWK as a top line command.

264 Database Maintenance Guide

 Workload Documentation Panels

To exit the panel:

■ Press PF3 to return to the DB.4 Menu panel except with the TSO/ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

----------------- CA-7 INPUT/OUTPUT NETWORK DOCUMENTATION ------------------

FUNCTION: xxxxxxxx (APPEND,CLEAR,DELETE,EDIT,FE,FETCH,LIST,REPL,SAVE,UPD)

JOB: xxxxxxxx
SYSTEM: xxxxxxxx

NETWORK: xxxxxxxx

DESC: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx LINK: nnnnnn

STEP: xxxxxxxx DDNAME: xxxxxxxx

REPORT-ID: xxxxxxxxxxxxxxxxxxxx
FORM: xxxxxxxx TRAIN: xx CARRIAGE: xxxx COPIES: nnn

ACTIVE SIZE: nnnn

PROGRAM: SM11 MSG-INDX: nn -- DB.4.2 -- yy.ddd / hh:mm:ss

MESSAGE:

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of following values:
APPEND
Retrieves documentation data from the database and attaches documentation
text to the end of any existing lines in the Active Area (text work area).
CLEAR
Clears panel input data fields and clears the Active Area of the user.
DELETE
Deletes a documentation member from the database.
EDIT
Transfers the user to the edit facility and allows text processing.
FE
Combines FETCH and EDIT.

Chapter 7: Workload Documentation 265

Workload Documentation Panels

FETCH
Retrieves documentation data from the database and replaces the Active Area
of the user with documentation text.
LIST
Lists documentation data only. In batch, a formatted panel is not listed; only a
found or not found message is returned.
REPL
Replaces a documentation member in the database.
SAVE
Adds a documentation member to the database.
UPD
Updates formatted panel fields only. UPD does not affect the documentation
text.
Batch keyword: Positional parameter
n/a
Contains a constant value of NWK for network documentation.
Limits: Required for batch only.
Batch keyword: Positional parameter
JOB
(Optional) Specifies the job that is related to the network for the documentation
being defined.
Limits: 1 to 8 alphanumeric characters
Batch keyword: JOB
SYSTEM
(Optional) Specifies the system name or system ID related to the network for the
documentation being defined.
Limits: 1 to 8 alphanumeric characters
Batch keyword: SYSTEM
NETWORK
Specifies the network for which the documentation is being defined.
Limits: 1 to 8 alphanumeric characters
Batch keyword: NETWORK

266 Database Maintenance Guide

 Workload Documentation Panels

DESC
(Optional) Specifies a description of the network.
Limits: 1 to 45 alphanumeric characters
Batch keyword: DESC
LINK
(Optional) Specifies the number of another documentation member to link to the
documentation member listed. Linking documentation members together causes
them to be listed together as if they were a single member. The LINK member is
listed after the requested member when using the LPROS command only.
Limits: 1 to 6 numeric characters
Batch keyword: LINK
Note: You can create an LPROS loop. Do not link linked documentation itself. The
following example shows a loop:
A linked to B
B linked to C
C linked to A

The following fields are informational only:

STEP
(Optional) Specifies the name of a job step in a particular job for which the network
documentation is being defined.
Limits: 1 to 8 alphanumeric characters
Batch keyword: STEP
DDNAME
(Optional) Specifies a ddname for which the documentation is being defined.
Limits: 1 to 8 alphanumeric characters
Batch keyword: DD
REPORT-ID
(Optional) Provides identification of a printed report.
Limits: 1 to 20 alphanumeric characters
Batch keyword: REPORT
FORM
(Optional) Specifies the output form number.
Limits: 1 to 8 alphanumeric characters
Batch keyword: FORM

Chapter 7: Workload Documentation 267

Workload Documentation Panels

TRAIN
(Optional) Specifies the type of printer train required.
Limits: 1 to 2 alphanumeric characters
Batch keyword: TRAIN
CARRIAGE
(Optional) Specifies the type of carriage control required.
Limits: 1 to 4 alphanumeric characters
Batch keyword: CARR
COPIES
(Optional) Specifies the number of original copies required.
Limits: 1 to 3 numeric characters from 0 to 255
Batch keyword: COPIES
ACTIVE SIZE
Identifies a system-generated field that shows the number of lines of text existing in
the Active Area for the current terminal session.

More information:

Special Documentation Features (see page 283)

Using the Edit Facility (see page 341)

DB.4.3 - User-Defined Item Documentation Panel

The DB.4.3 - User-Defined Item Documentation panel lets you define user level
documentation.

To display the panel, enter:

■ 3 as the FUNCTION on the DB.4 Menu panel.
■ 4.3 as the FUNCTION on the DB Menu panel.
■ DB.4.3 as the FUNCTION on any other menu or formatted input panel.
■ DB.4.3 or PROSE,USER as a top line command.

268 Database Maintenance Guide

 Workload Documentation Panels

To exit the panel:

■ Press PF3 to return to the DB.4 Menu panel except with the TSO/ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

------------------- CA-7 USER-DEFINED ITEM DOCUMENTATION -------------------

FUNCTION: xxxxxxxx (APPEND,CLEAR,DELETE,EDIT,FE,FETCH,LIST,REPL,SAVE,UPD)

USER: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

DESC: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx LINK: nnnnnn

REPORT-ID: xxxxxxxxxxxxxxxxxxxx
FORM: xxxxxxxx TRAIN: xx CARRIAGE: xxxx COPIES: nnn

ACTIVE SIZE: nnnn

PROGRAM: SM11 MSG-INDX: nn -- DB.4.3 -- yy.ddd / hh:mm:ss

MESSAGE:

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following values:
APPEND
Retrieves documentation data from the database and attaches documentation
text to the end of any existing lines in the Active Area (text work area).
CLEAR
Clears panel input data fields and clears the Active Area of the user.
DELETE
Deletes a documentation member from the database.

Chapter 7: Workload Documentation 269

Workload Documentation Panels

EDIT
Transfers the user to the EDIT facility and allows text processing.
FE
Combines FETCH and EDIT.
FETCH
Retrieves documentation data from the database and replaces the Active Area
of the user with documentation text.
LIST
Lists documentation data only. In batch, a formatted panel is not listed; only a
found or not found message is returned.
REPL
Replaces a documentation member in the database.
SAVE
Adds a documentation member to the database.
UPD
Updates formatted panel fields only. It does not affect the documentation text.
Batch keyword: Positional parameter
n/a
Contains a constant value of USER for user documentation.
Limits: Required for batch only.
Batch keyword: Positional parameter
USER
Specifies a required name that is used to supply a unique identifier for the
information that the user documentation entry defines. This field must follow z/OS
data set naming conventions. The field must not correspond to any system name,
job name, data set name, job-step-ddname combination, or workstation name that
exists (or will exist) in the CA WA CA 7 Edition system.
Limits: 1 to 32 alphanumeric characters
Batch keyword: USER
DESC
(Optional) Specifies an optional description of the user entry.
Limits: 1 to 45 alphanumeric characters
Batch keyword: DESC

270 Database Maintenance Guide

 Workload Documentation Panels

LINK
(Optional) Specifies the number of another documentation member to link to the
documentation member listed. Linking documentation members together causes
them to be listed together as if they were a single member. The LINK member is
listed after the requested member when using the LPROS command only.
Limits: 1 to 6 numeric characters
Batch keyword: LINK
Note: You can create an LPROS loop. Do not lnk linked documentation to itself. The
following example shows a loop:
A linked to B
B linked to C
C linked to A

The following fields are informational only:

REPORT-ID
(Optional) Provides identification of a printed report.
Limits: 1 to 20 alphanumeric characters
Batch keyword: REPORT
FORM
(Optional) Specifies the output form number.
Limits: 1 to 8 alphanumeric characters
Batch keyword: FORM
TRAIN
(Optional) Specifies the type of printer train required.
Limits: 1 to 2 alphanumeric characters
Batch keyword: TRAIN
CARRIAGE
(Optional) Specifies the type of carriage control required.
Limits: 1 to 4 alphanumeric characters
Batch keyword: CARR

Chapter 7: Workload Documentation 271

Workload Documentation Panels

COPIES
(Optional) Specifies the number of original copies required.
Limits: 1 to 3 numeric characters from 0 to 255
Batch keyword: COPIES
ACTIVE SIZE
Identifies a system-generated field that shows the number of lines of text existing in
the Active Area for the current terminal session.

More information:

Using the Edit Facility (see page 341)

DB.4.4 - Data Set Documentation Panel

The DB.4.4 - Data Set Documentation panel lets you define data set level
documentation. Data sets whose name is longer than 41 characters cannot use this
panel.

To display the panel, enter:

■ 4 as the FUNCTION on the DB.4 Menu panel.
■ 4.4 as the FUNCTION on the DB Menu panel.
■ DB.4.4 as the FUNCTION on any other menu or formatted input panel.
■ DB.4.4 or PROSE,DSN as a top line command.

To exit the panel:

■ Press PF3 to return to the DB.4 Menu panel except with the TSO/ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

272 Database Maintenance Guide

 Workload Documentation Panels

----------------------- CA-7 DATA SET DOCUMENTATION ------------------------

FUNCTION: xxxxxxxx (APPEND,CLEAR,DELETE,EDIT,FE,FETCH,LIST,REPL,SAVE,UPD)

DSN: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DSNBR: nnnnnnnn

DESC: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx LINK: nnnnnn

STEP: xxxxxxxx DDNAME: xxxxxxxx

REPORT-ID: xxxxxxxxxxxxxxxxxxxx
FORM: xxxxxxxx TRAIN: xx CARRIAGE: xxxx COPIES: nnn

ACTIVE SIZE: nnnn

PROGRAM: SM11 MSG-INDX: nn -- DB.4.4 -- yy.ddd / hh:mm:ss

MESSAGE:

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following values:
APPEND
Retrieves documentation data from the database and attaches documentation
text to the end of any existing lines in the Active Area (text work area).
CLEAR
Clears panel input data fields and clears the Active Area of the user.
DELETE
Deletes a documentation member from the database.
EDIT
Transfers the user to the EDIT facility and allows text processing.
FE
Combines FETCH and EDIT.
FETCH
Retrieves documentation data from the database and replaces the Active Area
of the user with documentation text.

Chapter 7: Workload Documentation 273

Workload Documentation Panels

LIST
Lists documentation data only. In batch, a formatted panel is not listed; only a
found or not found message is returned.
REPL
Replaces a documentation member in the database.
SAVE
Adds a documentation member to the database.
UPD
Updates formatted panel fields only. UPD does not affect the documentation
text.
Batch keyword: Positional parameter
n/a
Contains a constant value of DSN for data set documentation.
Limits: Required for batch only.
Batch keyword: Positional parameter
DSN
Specifies the data set name for which the documentation is being defined.
Limits: 1 to 41 alphanumeric characters and required unless DSNBR is used.
Batch keyword: DSN
Note: The data set name must not exceed 41 characters to permit PP. to be added
as part of the data set name in the IDs.
DSNBR
Specifies the data set for which the documentation is being supplied. Must be the
data set number that CA WA CA 7 Edition assigned when the data set was first
defined.
Limits: 1 to 8 numeric characters and required unless DSN is used.
Batch keyword: DSNBR

274 Database Maintenance Guide

 Workload Documentation Panels

DESC
(Optional) Specifies an optional description of the data set.
Limits: 1 to 45 alphanumeric characters
Batch keyword: DESC
LINK
(Optional) Specifies the number of another documentation member to link to the
documentation member listed. Linking documentation members together causes
them to be listed together as if they were a single member. The LINK member is
listed after the requested member when using the LPROS command only.
Limits: 1 to 6 numeric characters
Batch keyword: LINK
Note: You can create an LPROS loop. Do not link linked documentation to itself. The
following example shows a loop:
A linked to B
B linked to C
C linked to A

The following fields are informational only:

STEP
(Optional) Specifies the name of a job step in a particular job for which the
documentation is being defined.
Limits: 1 to 8 alphanumeric characters
Batch keyword: STEP
DDNAME
(Optional) Specifies a ddname for which the documentation is being defined.
Limits: 1 to 8 alphanumeric characters
Batch keyword: DD
REPORT-ID
(Optional) Provides identification of a printed report.
Limits: 1 to 20 alphanumeric characters
Batch keyword: REPORT
FORM
(Optional) Specifies the output form number.
Limits: 1 to 8 alphanumeric characters
Batch keyword: FORM

Chapter 7: Workload Documentation 275

Workload Documentation Panels

TRAIN
(Optional) Specifies the type of printer train required.
Limits: 1 to 2 alphanumeric characters
Batch keyword: TRAIN
CARRIAGE
(Optional) Specifies the type of carriage control required.
Limits: 1 to 4 alphanumeric characters
Batch keyword: CARR
COPIES
(Optional) Specifies the number of original copies required.
Limits: 1 to 3 numeric characters from 0 to 255
Batch keyword: COPIES
ACTIVE SIZE
Identifies a system-generated field that shows the number of lines of text existing in
the Active Area for the current terminal session.

More information:

Using the Edit Facility (see page 341)

DB.4.5 - DD Statement Documentation Panel

The DB.4.5 - DD Statement Documentation panel lets you define DD level
documentation.

To display the panel, enter:

■ 5 as the FUNCTION on the DB.4 Menu panel.
■ 4.5 as the FUNCTION on the DB Menu panel.
■ DB.4.5 as the FUNCTION on any other menu or formatted input panel.
■ DB.4.5 or PROSE,DD as a top line command.

To exit the panel:

■ Press PF3 to return to the DB.4 Menu panel except with the TSO/ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

276 Database Maintenance Guide

 Workload Documentation Panels

--------------------- CA-7 DD STATEMENT DOCUMENTATION ----------------------

FUNCTION: xxxxxxxx (APPEND,CLEAR,DELETE,EDIT,FE,FETCH,LIST,REPL,SAVE,UPD)

JOB: xxxxxxxx
SYSTEM: xxxxxxxx

DESC: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx LINK: nnnnnn

STEP: xxxxxxxx DDNAME: xxxxxxxx

REPORT-ID: xxxxxxxxxxxxxxxxxxxx
FORM: xxxxxxxx TRAIN: xx CARRIAGE: xxxx COPIES: nnn

ACTIVE SIZE: nnnn

PROGRAM: SM11 MSG-INDX: nn -- DB.4.5 -- yy.ddd / hh:mm:ss

MESSAGE:

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following values:
APPEND
Retrieves documentation data from the database and attaches documentation
text to the end of any existing lines in the Active Area (text work area).
CLEAR
Clears panel input data fields and clears the Active Area of the user.
DELETE
Deletes a documentation member from the database.
EDIT
Transfers the user to the EDIT facility and allows text processing.
FE
Combines FETCH and EDIT.

Chapter 7: Workload Documentation 277

Workload Documentation Panels

FETCH
Retrieves documentation data from the database and replaces the Active Area
of the user with documentation text.
LIST
Lists documentation data only. In batch, a formatted panel is not listed; only a
found or not found message is returned.
REPL
Replaces a documentation member in the database.
SAVE
Adds a documentation member to the database.
UPD
Updates formatted panel fields only. UPD does not affect the documentation
text.
Batch keyword: Positional parameter
n/a
Contains a constant value of DD for the DD documentation.
Limits: Required for batch only.
Batch keyword: Positional parameter
JOB
Specifies the job containing the ddname for the documentation being defined.
Limits: 1 to 8 alphanumeric characters
Batch keyword: JOB
SYSTEM
(Optional) Specifies the system name or system ID for which the documentation is
being defined.
Limits: 1 to 8 alphanumeric characters
Batch keyword: SYSTEM

278 Database Maintenance Guide

 Workload Documentation Panels

DESC
(Optional) Specifies a description of the data set.
Limits: 1 to 45 alphanumeric characters
Batch keyword: DESC
LINK
(Optional) Specifies the number of another documentation member to link to the
documentation member listed. Linking documentation members together causes
them to be listed together as if they were a single member. The LINK member is
listed after the requested member when using the LPROS command only.
Limits: 1 to 6 numeric characters
Batch keyword: LINK
Note: You can create an LPROS loop. Do not link linked documentation to itself. The
following example shows a loop:
A linked to B
B linked to C
C linked to A

STEP
Specifies the step of the JOB for the DD documentation being defined.
Limits: 1 to 8 alphanumeric characters
Batch keyword: STEP
DDNAME
Specifies the ddname for which the documentation is being defined.
Limits: 1 to 8 alphanumeric characters
Batch keyword: DD

The following fields are informational only:

REPORT-ID
(Optional) Provides identification of a printed report.
Limits: 1 to 20 alphanumeric characters
Batch keyword: REPORT
FORM
(Optional) Specifies the output form number.
Limits: 1 to 8 alphanumeric characters
Batch keyword: FORM

Chapter 7: Workload Documentation 279

Workload Documentation Panels

TRAIN
(Optional) Specifies the type of printer train required.
Limits: 1 to 2 alphanumeric characters
Batch keyword: TRAIN
CARRIAGE
(Optional) Specifies the type of carriage control required.
Limits: 1 to 4 alphanumeric characters
Batch keyword: CARR
COPIES
(Optional) Specifies the number of original copies required.
Limits: 1 to 3 numeric characters from 0 to 255
Batch keyword: COPIES
ACTIVE SIZE
Identifies a system-generated field that shows the number of lines of text existing in
the Active Area for the current terminal session.

More information:

Using the Edit Facility (see page 341)

DB.4.6 - Application System Documentation Panel

The DB.4.6 - Application System Documentation panel lets you define system level
documentation.

To display the panel, enter:

■ 6 as the FUNCTION on the DB.4 Menu panel.
■ 4.6 as the FUNCTION on the DB Menu panel.
■ DB.4.6 as the FUNCTION on any other menu or formatted input panel.
■ DB.4.6 or PROSE,SYS as a top line command.

To exit the panel:

■ Press PF3 to return to the DB.4 Menu panel except with the TSO/ISPF interface
when PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

280 Database Maintenance Guide

 Workload Documentation Panels

------------------ CA-7 APPLICATION SYSTEM DOCUMENTATION -------------------

FUNCTION: xxxxxxxx (APPEND,CLEAR,DELETE,EDIT,FE,FETCH,LIST,REPL,SAVE,UPD)

SYSTEM: xxxxxxxx

DESC: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx LINK: nnnnnn

ACTIVE SIZE: nnnn

PROGRAM: SM11 MSG-INDX: nn -- DB.4.6 -- yy.ddd / hh:mm:ss

MESSAGE:

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following values:
APPEND
Retrieves documentation data from the database and attaches documentation
text to the end of any existing lines in the Active Area (text work area).
CLEAR
Clears panel input data fields and clears the Active Area of the user.
DELETE
Deletes a documentation member from the database.
EDIT
Transfers the user to the EDIT facility and allows text processing.
FE
Combines FETCH and EDIT.
FETCH
Retrieves documentation data from the database and replaces the Active Area
of the user with documentation text.

Chapter 7: Workload Documentation 281

Workload Documentation Panels

LIST
Lists documentation data only. In batch, a formatted panel is not listed; only a
found or not found message is returned.
REPL
Replaces a documentation member in the database.
SAVE
Adds a documentation member to the database.
UPD
Updates the DESC and the LINK fields only. UPD does not affect the
documentation text.
Batch keyword: Positional parameter
n/a
Contains a constant value of SYS for system documentation.
Limits: Required for batch only.
Batch keyword: Positional parameter
SYSTEM
Specifies the system name or system ID for which the documentation entry is being
defined.
Limits: 1 to 8 alphanumeric characters
Batch keyword: SYSTEM
DESC
(Optional) Specifies an optional description of the system.
Limits: 1 to 45 alphanumeric characters
Batch keyword: DESC

282 Database Maintenance Guide

 Special Documentation Features

LINK
(Optional) Specifies the number of another documentation member to link to the
documentation member listed. Linking documentation members together causes
them to be listed together as if they were a single member. The LINK member is
listed after the requested member when using the LPROS command only.
Limits: 1 to 6 numeric characters
Batch keyword: LINK
Note: You can create an LPROS loop. Do not link linked documentation to itself. The
following example shows a loop:
A linked to B
B linked to C
C linked to A

ACTIVE SIZE
Identifies a system-generated field that shows the number of lines of text existing in
the Active Area for the current terminal session.

More information:

Using the Edit Facility (see page 341)

Special Documentation Features

CA WA CA 7 Edition has six major categories of user-defined documentation. Each
category has its own DB.4 panel with which the documentation can be entered and
maintained in the database. All categories are optional and are provided for user
convenience. Each documentation member falls within one of six categories:
■ Job name
■ System name
■ Network name
■ User level
■ Data set name
■ DD statement

Chapter 7: Workload Documentation 283

Special Documentation Features

User-Defined Documentation Segments

Within each of the major documentation member types, the user can subdivide
documentation text into segments. Segments are convenient because you can access
them individually by name, presenting documentation only on a specific item or set of
items.

The user names and defines segments by the use of special pound sign (#) control
statements. The # control statements begin and end each segment, forming a bookend
notation.

Reserved Segment Names

The system reserves some names for special use. Do not use segment names that would
conflict with the following segment names:

#END

#QDESC

#RESTART

#station-name

Discussions of these special purpose names follow later.

Rules and Guidelines for Documentation Segmentation

The following rules and guidelines help you make more efficient use of the
segmentation tool:
■ Adopt a naming convention for segments. This method adds ease of retrieval.
■ A documentation member can contain one or more segments.
■ Each segment must have a name. Segment names must conform to the following
rules:
– The name is a maximum of eight characters.
– Commas, as part of the name, are not allowed.
– Alphabetic, numeric, and special characters are permitted.
■ A segment name must be unique within the documentation member. Make the
segment name different from the documentation member name of which the
segment is a part.

284 Database Maintenance Guide

 Special Documentation Features

More information:

Naming Conventions Documentation (see page 290)

Segment Names Definition

The user-defined segments can be an orderly method of documentation. By establishing

standards that are related to segment names, a powerful tool results. To define a
segment name, select an eight-character name meaningful to your environment;
precede the name with a # sign. Enter the definition starting in column 1. For example:

#segment-name

The following list contains potential segment names that could fit into the naming
conventions for segments:
#DATECARD
Defines the format of the date cards that are used in this job.
#progname
Provides a description of programs that are used in the job.
#stepname
Provides a description of job steps in the job.
#DISASTER
Defines the instructions for disaster recovery procedures.
#RECOVERY
Defines the recovery specifications for I/O errors, abends, and so forth.
#FILING
Provides the instructions for filing input or output.
#SETUP
Defines I/O media requirements of the job.
#CONTACTS
Defines names and numbers of personnel who support the job.
#DEVICES
Defines I/O device requirements of the job.

Chapter 7: Workload Documentation 285

Special Documentation Features

#CONFLICT
Defines possible processing conflicts with other jobs.
#VALIDATE
Defines special manual verification requirements of the job.
#AFTERHRS
Defines special procedures occurring after the close of the business day.

Other segment names can be helpful or more meaningful and easy to use in any
particular data center. Within the constraints of the few reserved segment names, users
have total flexibility in naming documentation segments.

Format of Documentation Segments

The format of documentation segments is simple. The first statement must be a

#segment-name statement. The #segment-name begins in column 1. Immediately
following the #segment-name statement is the documentation that is associated with
the name. The documentation is in free-form and control characters are not needed.
However, avoid beginning a documentation line with a #, which the system interprets as
a segmentation control character. The system tries to treat it as a start or an end of a
segment or subsegment.

To terminate the documentation for this segment, a #END statement is required. The
#END statement begins in column 1 and the format of this statement is as follows:
#END[,segment-name]

For every segment name defined, you must have a #END control statement. The #END
statement must occur before a new segment name can be defined. That is, the #END
statement must precede the next occurrence of a #segment-name statement.

286 Database Maintenance Guide

 Special Documentation Features

The following shows an example of documentation segments. In this case, the user is
documenting jobs, and thus, is entering job-level documentation.

job documentation
.
. usual job documentation goes here
.
#DATECARD
.
. date control statement information goes here
.
#END,DATECARD
#RECOVERY
.
. production recovery documentation goes here
.
#END,RECOVERY
#CONTACTS
.
. names, telephone numbers of responsible personnel go here
.
#END,CONTACTS

Documentation Segments Display

If your installation has adopted standard naming conventions, displaying the

documentation that is contained in the segments is easy.

For example, all date card instructions for all jobs could be entered in the database,
within each job's JOB documentation, with a standard segment name of DATECARD.
Whenever any question arises regarding the date card for a particular job, the user can
display the documentation with the LPROS command, giving only the name of that job
and the segment name DATECARD as follows:

LPROS,JOB=jobname,SEG=DATECARD

If more documentation on this job is available, it is not displayed. Only the requested
segment is displayed. To obtain all documentation on this job, omit the SEG parameter.

By segmenting documentation, the user can view selected parts of the documentation
and not have to view all the documentation at one time.

Subsegments

Each segment can contain subsegments. The rules and guidelines that apply to
subsegments are similar to the ones for segments.

Chapter 7: Workload Documentation 287

Special Documentation Features

Rules and Guidelines for Subsegments

Adopt a naming convention for subsegments. Just as naming conventions aid the user in
retrieval of segments, the same holds true with subsegments.

Each subsegment must have a name. Subsegment names must follow the same rules as
segment names.

A segment can have one or more subsegments.

A subsegment name must be different from the segment name of which the
subsegment is a part.

A subsegment must end before the end of the segment of which it is a part.

A subsegment name must not have the same name as a reserved segment name.

A subsegment must be embedded between a #subsegment-name statement and a

#END,subsegment-name statement.

More information:

Reserved Segment Names (see page 284)

Rules and Guidelines for Documentation Segmentation (see page 284)
Naming Conventions Documentation (see page 290)

Subsegment Names Definition

To define a subsegment name, select an eight-character name meaningful in your

environment; precede the name with a # sign. Enter the definition starting in column 1.
This method is the same way segment names are defined:

#subsegment-name

For example, your installation can have two procedures for recovery: one for business
hours and one for nonbusiness hours. To define these two names, you can create two
subsegments within the segment that is named RECOVERY using the following
subsegment names:

#DAYTIME
#AFTERHRS

288 Database Maintenance Guide

 Special Documentation Features

Format of Documentation Subsegments

The format of documentation subsegments is exactly like the format of segments. Make
the first statement of the subsegment #subsegment-name, and begin in column 1.
Immediately following this statement is the subsegment documentation that is
free-form. Control characters are not needed. Avoid beginning a documentation line
with a # sign, which the system interprets as a segmentation control character. The
system then tries to treat it as a start or an end of a subsegment or segment.

To terminate the documentation for this subsegment, a #END statement is required.

The #END statement begins in column 1 and the format of this statement is as follows:

#END,subsegment-name

For every subsegment name defined, you must have a #END,subsegment-name control
statement. Nesting of subsegments within other subsegments is not permitted. The
#END,subsegment-name statement must occur before the next occurrence of a
#subsegment-name or #segment-name statement.

The following shows an example of coding DAYTIME and AFTERHRS subsegments within
the RECOVERY segment:

#RECOVERY
#DAYTIME
.
. Daytime procedures go here
.
#END,DAYTIME
#AFTERHRS
.
. After hours procedures go here
.
#END,AFTERHRS
#END,RECOVERY

Chapter 7: Workload Documentation 289

Special Documentation Features

Documentation Subsegments Display

If standard naming conventions for subsegments have been adopted by the installation,
displaying the documentation contained in the subsegments is easy. The user must
know which names are segment names and which names are subsegment names. This is
where standard naming conventions for both is important.

In the previous example, in the segment named RECOVERY are two subsegments; one is
named DAYTIME and the other AFTERHRS. To display the subsegments, use the LPROS
command. For example:

LPROS,JOB=jobname,SEG=(RECOVERY,AFTERHRS)

This would display only the AFTERHRS subsegment. The SEG parameter requires that the
segment name appear first, followed by the subsegment name.

To display the other subsegment of the RECOVERY segment, the entry would be as
follows:

LPROS,JOB=jobname,SEG=(RECOVERY,DAYTIME)

The DAYTIME subsegment would display.

To display all subsegments of a segment, only the segment form of LPROS is used. For
example:

LPROS,JOB=jobname,SEG=RECOVERY

Naming Conventions Documentation

As a further aid in handling documentation, we recommend that not only should you
adopt a naming convention for segments and subsegments but also that you document
the naming convention. We suggest that you use at least one documentation member
(not a segment) of the user-designated level for this purpose. The following are
suggestions for naming a user documentation member:

STANDARD.NAMING.SEGMENTS
STANDARD.NAMES.FOR.SEGMENTS

The DB.4.3 panel contains more information about the USER field.

290 Database Maintenance Guide

 Special Documentation Features

If your installation is using subsegments and segments, two documentation members,

one for segments and one for subsegments, might be advisable. Following are
suggestions for the documentation member name containing documentation on
subsegment naming conventions:

STANDARD.NAMING.SUB.SEGMENTS
STANDARD.NAMES.FOR.SUB.SEGMENTS

As with any documentation, the contents of documentation members can be

maintained easily through the appropriate DB.4 panels.

More information:

DB.4.3 - User-Defined Item Documentation Panel (see page 268)

Special Purpose Documentation

The Special Purpose Documentation (#) feature allows the user to define
documentation information to be used for special situations. The user must use the
reserved names provided for these Special Purpose Documentation items. Once the
information has been entered, it is available through the LPROS command. Optionally, it
can also be displayed by automatically routing the information to a specific workstation
or terminal.

Special Documentation is entered as a segment within a stream of regular

documentation lines using the appropriate DB.4 panel (and the EDIT facility).

General Format

The general format of the Special Purpose Documentation entry (or # entry) is as follows
with the # sign always in position 1 of the segment delimiter statements.

#reserved special purpose name

.
. special documentation lines
.
#END,reserved special purpose name

Chapter 7: Workload Documentation 291

Special Documentation Features

#QDESC Segment Usage

One feature of the Special Purpose Documentation facility applies to job and network
documentation. The following paragraphs provide explanations and examples of these
Special Documentation capabilities.

If the user wants special job or network documentation to be automatically routed to a

predetermined terminal when the task enters the queue, the reserved documentation
segment name #QDESC should be used, within the job or network documentation. An
example follows with the # sign always in position 1 of the segment delimiter
statements.

#QDESC
.
. special documentation for the job or network
.
#END,QDESC

When the job enters the queue, any QDESC documentation for the task is automatically
routed to the terminal defined on the DB.1 panel (LTERM value), or the initialization file
JCL statement, LTERM value, or if neither of these is specified, to the MASTER station.
When a network enters the preprocessing or postprocessing queue, any QDESC
documentation is automatically routed to the MASTER station. Optionally, #QDESC lines
can be listed by the LPROS transaction with job name or network specified.

Note: Module SASSMSGS can cause suppression of the #QDESC. Check messages
SFEP-11 and SIRD-11 in the SASSMSGS module.

292 Database Maintenance Guide

 Special Documentation Features

#station-name Segment Usage

The user may want special network documentation to be automatically routed to
predetermined workstations when the network enters the queue. The wanted station
names are defined as part of the documentation with a #station-name statement. The
station name that is to receive the documentation would be placed in the
#station-name statement immediately following the #. In this case, a #station-name
record, indicating the name of the station, should be entered immediately ahead of the
#QDESC record, as follows:

(A) #station-name1

(B) #QDESC
.
special network documentation for station-name1
.
#END,station-name1
.
(A) #station-name2

(B) #QDESC
.
special network documentation for station-name2
.
#END,station-name2
.
(A) #station-namen

(B) #QDESC
.
special network documentation for station-namen
.
#END,station-namen

Documentation lines can be entered between points (A) and (B), but these lines would
only be displayed through the LPROS command or DB.4 panels. The lines between
#QDESC and #END, however, are automatically sent to the indicated workstations when
the network enters the queue.

Note: If #QDESC documentation is to be displayed at a station that is not a printer,

module SASSMSGS must be changed for message SFEP-11. LT=*PRNTR* must be
changed to either LT=*ALL* or LT=station-name. Also notice that station names should
match station names defined in the STANIDS keyword of the STATIONS statement in the
initialization file.

Chapter 7: Workload Documentation 293

Special Documentation Features

#RESTART Segment Usage

If the user wants to document recovery or restart instructions for a job, the reserved
segment name #RESTART should be used. The restart documentation should be
included in the DB.4.1 documentation as follows:

.
job level documentation
.
.
#RESTART
.
.
special restart/recovery documentation
.
.
#END,RESTART
.
.
job level documentation
.
.
.

As with all special documentation, the # sign must be in position 1 of the record as
shown.

The system recognizes #RESTART as a system-defined segment name having a special

use with the LIST command. It can also be used with the LPROS command, but
#RESTART is treated as any other segment name.

When using the LIST command, if PROSE=YES is specified, the #RESTART documentation
segment of the job documentation is displayed. PROSE=NO is the default.

With the LPROS command, RESTART has to be specifically requested. For example:

LPROS,JOB=jobname,SEG=RESTART

#END Statement
This statement is used to signal the end of a documentation unit.

This statement has the following format:

#END [,segment-name]

[,subsegment-name]

[,station-name]

294 Database Maintenance Guide

 Special Documentation Features

#END
Defines the required statement name. The name must begin in position 1 of the
record. If used without any other parameter, it marks the end of the documentation
unit (that is, current segment and subsegment).
segment-name | subsegment-name | station-name
Defines a user-defined segment, subsegment, or station name. The name must
match the name used in the # record at the beginning of the unit.

Depending on how the user structured the documentation, multiple #END statements
can be nested within one segment of documentation.

More information:

User-Defined Documentation Segments (see page 284)

Chapter 7: Workload Documentation 295

Chapter 8: Workstation Networks
This section describes setting up and maintaining a workstation network within CA WA
CA 7 Edition.

This section contains the following topics:

Network Adds (see page 297)
DB.5 - Input/Output Network Definition Panel (see page 298)
Network Changes (see page 301)

Network Adds
Adding a network is similar to adding a job. The primary method is to use the ADD
function on the DB.5 panel. For new users or users making multiple changes to their
networks, other methods can be used.

If the network information already exists in machine-readable form, writing a program

to produce batch terminal network commands can be an advantage. The database can
then be updated using the Batch Terminal Interface (BTI) facility.

Note: For more information about BTI, the Interface Reference Guide.

The following items are something to remember when adding a network:

■ On the DB.5 panel, stations must be defined in the chronological order in which
they are used.
■ The DMDNW and RUNNW commands do not add a network to the database. These
commands require that the network is defined in the database with some type of
schedule before the commands can act on the network.
■ Input networks can be connected to one or more CPU jobs, in which case, they have
a predecessor/dependency relationship with those jobs. These connections are
defined using the DB.3.4 panel functions.
■ Input networks that are not handled on an on-request basis must have a
calendar-based schedule defined. This definition is done with the DB.2.2 panel.
■ Output networks are scheduled to be run because of their connection to a job.
When the connected CPU job is scheduled into the queue, the output network is
brought into the postprocess queue.
■ Output networks must be logically connected with the DB.3.4 panel. Scheduling
parameters must be entered through the DB.2.3 panel, but the schedule is not
resolved against a calendar.

Chapter 8: Workstation Networks 297

DB.5 - Input/Output Network Definition Panel

(More information:

Batch Input (see page 25)

DB.5 - Input/Output Network Definition Panel

The Input/Output Network Definition panel lets you define networks of workstations at
which manual tasks are performed.

To display the panel, enter:

■ 5 as the FUNCTION on the DB Menu panel.
■ DB.5 as the FUNCTION value on any other menu or formatted input panel.
■ DB.5 or NETWORK as a top line command.

To exit the panel:

■ Press PF3 to return to the DB Menu panel except with the TSO-ISPF interface when
PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

------------------- CA-7 INPUT/OUTPUT NETWORK DEFINITION -------------------

FUNCTION: xxxxxxxx (ADD,DELETE,FORMAT,LIST,UPD)

NETWORK: xxxxxxxx TYPE: xxxxxx

SUB-ID: xxxxxxxx JOB: xxxxxxxx SCHD PROSE: xxxxxxxx

STATION 1: xxxxxxxx
STATION 2: xxxxxxxx
STATION 3: xxxxxxxx
STATION 4: xxxxxxxx
STATION 5: xxxxxxxx
STATION 6: xxxxxxxx
STATION 7: xxxxxxxx
STATION 8: xxxxxxxx
STATION 9: xxxxxxxx

PROGRAM: SM40 MSG-INDX: nn -- DB.5 -- yy.ddd / hh:mm:ss

MESSAGE:

298 Database Maintenance Guide

 DB.5 - Input/Output Network Definition Panel

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following:
ADD
Adds a network to the database.
DELETE
Deletes a network, and its associated documentation and schedules, from the
database.
Note: A network cannot be deleted when it is connected to a job.
FORMAT
Clears the panel of all user input data.
LIST
Lists the database information. In batch, a formatted panel is not listed; only a
found or not found message is returned.
UPD
Updates network information in the database.
Batch keyword: Positional parameter
NETWORK
Specifies the network on which to perform the indicated function. Must be a
network name.
Limits: 1 to 8 alphanumeric characters
Batch keyword: Positional parameter
TYPE
Specifies the value must be INPUT or OUTPUT to indicate the type of network.
Limits: Required for ADD and UPD functions. Optional for DELETE, FORMAT, and
LIST functions.
Batch keyword: Positional parameter

Chapter 8: Workstation Networks 299

DB.5 - Input/Output Network Definition Panel

SUB-ID
(Optional) Specifies further description of the network's duties.
Limits: 1 to 8 alphanumeric characters
Batch keyword: SUBID
Output Networks: Specify the SUBID on the DB.3.4 connection. Then, this sub-ID is
shown on subsequent inquiries.
Input Networks: The SUBID specified here shows on various inquiries. For example,
if handling of input data is required for the network, the task number of the user,
job number, or control number for the data can be defined as the sub-ID.
JOB
(Optional) Specifies a job name. For this job, the schedule associated with the
output network is assumed to be accurate and is not adjusted based on job due-out
time. For all other connected jobs, the network's scheduling parameters for
time-of-day are adjusted as if the network entered the postprocessing queue at the
job's due-out time.
Limits: 1 to 8 alphanumeric characters
Batch keyword: JOB
SCHD PROSE
(Optional) Designates the name of some other network whose DB.4.2 member,
#QDESC segment, is used for special documentation messages. Schedule Scan prints
the messages when this network enters the queue. Cannot be used if this network
has a DB.4.2 member that is defined for it.
Limits: 1 to 8 alphanumeric characters
Batch keyword: SCHPROSE
STATION
Enables entry of up to nine workstations into this network. Enter the station names
in the sequence in which the corresponding workstation tasks are performed. The
same station name can be used more than once, but the names must have a
correlation to the STANIDS or LTERM names as defined in the initialization file.
These station names must not conflict with any existing network names. For BTI
input, make the station names a sublist. For example:
STAT=(st1,st2,st3)
Limits: 1 to 8 alphanumeric characters, and at least one entry is required.
Batch keyword: STAT
Note: To remove a station, place an asterisk (*) in that STATION field and use the
UPD function. However, if the network has a schedule, an update cannot change
the number of stations in a network.

300 Database Maintenance Guide

 Network Changes

Example: Batch Input

This batch input example adds input network PAYPUNCH to the CA WA CA 7 Edition
database. The network consists of three stations: LOG, KEY, and VERIFY.

NETWORK
ADD,PAYPUNCH,INPUT,STAT=(LOG,KEY,VERIFY)
DBM

Network Changes
If the characteristics of the network are changing from those shown on the DB.5 panel,
use the UPD function on the DB.5 panel. If you have many changes, use the Batch
Terminal Interface (BTI) facility to make these changes.

Note: For more information about BTI, see the Interface Reference Guide.

In most cases, reconnecting the network may not be necessary, but the schedule may
be different. Be sure to consider the schedule function for this particular network. You
can use the DB.2 scheduling panels for this purpose.

If the function of the network changes, the job connections for that network may also
change. In this case, you can use the DB.3.4 panel to redefine the job connections.

Keep in mind that one network can be connected to more than one CPU job and
schedule changes may be associated with the change of network function. Use the
LNTWK,NW=networkname,LIST=USERS command to determine which jobs are
connected to the network.

If the number of stations in a network changes, the stations cannot be added or deleted
if the network has a schedule. The schedule must first be deleted.

More information:

Batch Input (see page 25)

Chapter 8: Workstation Networks 301

Chapter 9: Data Sets
This section contains instructions for adding and maintaining data set information in CA
WA CA 7 Edition.

This section contains the following topics:

Data Set Adds (see page 303)
DB.6 - Data Set Definition Panel (see page 305)
Data Set Changes (see page 310)

Data Set Adds

Several methods of adding data sets to the database are available. The primary method
is accomplished through the LOAD process. When a job is loaded, all data set names
referenced in the JCL are added to the database if those names are not already in the
database. If the LOADDSNS keyword is used on the DBASE statement in the initialization
file, the LOAD process does not build any DD or data set information for jobs that are
marked MAINT=Y on the DB.1 (JOB) panel.

Data sets can also be added to the database by using the DB.6 panel ADD function.

If data set information exists in machine-readable form, a program can be written to

perform the DB.6 panel functions with batch commands and the Batch Terminal
Interface (BTI) facility. For further details on BTI, see the Interface Reference Guide.

Once a data set is added to the database, CA WA CA 7 Edition assigns a unique

eight-digit number to the data set, referred to as a DSNBR. You can then reference the
data set by that number. This method eliminates the need to enter a long data set name
each time that CA WA CA 7 Edition commands and panels reference a data set.

More information:

Batch Input (see page 25)

Chapter 9: Data Sets 303

Data Set Adds

Permanent Data Sets

During the LOAD process, any data set that is used as input to the job is considered a
requirement for that job. This means that a new version of the data set must be created
before that CA WA CA 7 Edition can submit the job. Some data sets, however, are not
created by a CA WA CA 7 Edition submitted job. The user may want these data sets to
be considered as permanent to CA WA CA 7 Edition.

The LOAD process automatically adds data sets to the database and marks them
permanent when all of the following conditions are true:
■ Data set name does not already exist in the database.
■ Data set is normal data set (that is, not temporary, SYSIN, or SYSOUT).
■ Data set is accessed using a reserved ddname:
– STEPLIB
– SORTLIB
– JOBLIB
– STEPCAT
– JOBCAT
– SYSUDUMP
– SYSABEND
– SYSMDUMP
– SYSCHK
– SYSCKEOV
The reserved ddnames reside in the SASSPMDD table. Names can be added or
deleted as necessary to satisfy the needs of the user. For more information about
modifying this table, see the topic Reserved DDNAME Table in the chapter "User
Exits and Modifications" of the Systems Programming Guide.

The TYPE field on the DB.6 panel must be set to PERM for permanent data sets to CA
WA CA 7 Edition. This action must be done manually in those cases where the LOAD
process could not determine that the data set was permanent. When the data set is
defined as permanent, it is not considered to be a requirement for any job that uses it
as input.

Dynamically Allocated Data Sets

Data sets that are dynamically allocated by the programs and do not have a DD
statement in the JCL must be defined with the DB.6 panel. The LOAD process cannot
perform this function since a DD statement was not used.

304 Database Maintenance Guide

 DB.6 - Data Set Definition Panel

External Data Sets

Data sets can be defined as preexecution requirements for jobs even though the data
set is never created or referenced by any job running under the control of CA WA CA 7
Edition. Such data sets are referred to as external data sets and must be defined using
the DB.6 panel. Data sets that are used by jobs under the control of CA WA CA 7 Edition
but are never created with a DISP=NEW are also referred to as external data sets. These
data sets can be defined as job requirements using the DB.3.1 panel, but the
requirements must be satisfied by the user before the dependent job can execute.
Requirement posting can be performed using online panels, batch terminal interface
commands, Trailer Step commands, or U7SVC input.

DB.6 - Data Set Definition Panel

The DB.6 - Data Set Definition panel lets you define a user data set to CA WA CA 7
Edition.

Normally, you use this panel to define data sets with a TYPE value of PERM or for
updates. If this panel is not used to define a data set, the initial LOAD of the job adds the
data set to the database automatically. You can also perform any manual maintenance
that is required on this information with this panel.

To display the panel, enter:

■ 6 as the FUNCTION on the DB Menu panel.
■ DB.6 as the FUNCTION value on any other menu or formatted input panel.
■ DB.6 or DSN as a top line command.

Chapter 9: Data Sets 305

DB.6 - Data Set Definition Panel

To exit the panel:

■ Press PF3 to return to the DB Menu panel except with the TSO-ISPF interface when
PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

------------------------- CA-7 DATA SET DEFINITION -------------------------

FUNCTION: xxxxxxxx (ADD,DELETE,FORMAT,LIST,RENAME,UPD)

DSN: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DSNBR: nnnnnnnn

NEWNAME: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

TYPE: xxxx GDG: x

SMF FEEDBACK REQUIRED: x POST AT CLOSE TIME: x

DEVICE: xxxx
DSORG: xxx
RECFM: xxxxx
LRECL: nnnnn
BLKSIZE: nnnnn

PROGRAM: SM30 MSG-INDX: nn -- DB.6 -- yy.ddd / hh:mm:ss

MESSAGE:

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following:
ADD
Adds a data set to the database.
DELETE
Deletes a data set and its associated elements (data set triggers, user
documentation, and so forth).
Note: If any job uses this data set, it cannot be deleted until the jobs or their
DSN predecessor requirements are deleted.
FORMAT
Clears the panel of all user input data.

306 Database Maintenance Guide

 DB.6 - Data Set Definition Panel

LIST
Lists the formatted data of the panel. In batch, a formatted panel is not listed;
only a found or not found message is returned.
RENAME
When the user has changed a data set's name, RENAME with the NEWNAME
field can be used to change the CA WA CA 7 Edition data set name. The
RENAME top line utility command changes the data set name in z/OS; whereas,
the RENAME function on this panel changes the data set name in the CA WA CA
7 Edition database, but not in z/OS.
UPD
Updates data set information in the database.
Batch keyword: Positional parameter
DSN
(Optional) Specifies the data set and must be the fully qualified data set name.
Limits: 1 to 44 alphanumeric characters and required for ADD (and UPD unless
DSNBR is used).
Note: DSN is not required to conform to MVS data set name standards. Embedded
blanks and special characters such as slashes, dashes, and underscores are
permitted. All alphabetic characters are uppercased.
Batch keyword: DSN
DSNBR
(Optional) Specifies the data set to use. The value must be the numeric value that
CA WA CA 7 Edition already assigned.
Limits: 1 to 8 numeric characters (leading zeros are not required) and required
unless DSN is used (ignored for ADD)
Batch keyword: DSNBR
NEWNAME
(Optional) Used with the RENAME function and DSN field to change a data set name
in the CA WA CA 7 Edition database. The RENAME top line utility command changes
the data set name in z/OS; whereas, the RENAME function on this panel changes
the data set name in the CA WA CA 7 Edition database, but not in z/OS.
Limits: 1 to 44 alphanumeric characters
Note: NEWNAME is not required to conform to MVS data set name standards.
Embedded blanks and special characters such as slashes, dashes, and underscores
are permitted. All alphabetic characters are uppercased.
Batch keyword: NEWNAME

Chapter 9: Data Sets 307

DB.6 - Data Set Definition Panel

TYPE
(Optional) Specifies the data set type. Value can be one of the following times:
NORM
Internal: Specifies both the creating-job and using-jobs for this data set are
known to CA WA CA 7 Edition.
External: Specifies the creating-job, using-jobs, or both for this data set are not
known to CA WA CA 7 Edition.
PERM
Specifies this data set is always available for input.
Important! When a data set is marked PERM, no SMF records are captured.
PERM means no data set triggering can occur with this type data set.
Default: NORM when doing ADD
Batch keyword: TYPE
GDG
(Optional) Specifies whether this data set is a generation data group (Y or N).
Default: N
Batch keyword: GDG
Note: The specific GDG creations cannot be used for posting requirements or for
triggering jobs. Posting and triggering are done based on the creation/updating
(SMF 15 record) of any generation of the GDG.
SMF FEEDBACK REQUIRED
(Optional) Specifies whether the interface to System Management Facility (SMF)
inserts the values for DSORG, RECFM, LRECL, and BLKSIZE when this data set is next
used (Y or N). Unless the value is reset, this insertion is only done once.
Default: Y
Batch keyword: SMF
Note: After the first time the job that creates this data set runs under CA WA CA 7
Edition, this field is reset to N. If the data set attributes change, this field must be
reset to Y and the attribute field that changed (that is, DSORG, RECFM) must be
zeroed (if numeric) or blanked out. This process causes CA WA CA 7 Edition to
record the new values when the job is run again.

308 Database Maintenance Guide

 DB.6 - Data Set Definition Panel

POST AT CLOSE TIME

(Optional) Specifies when to post the creation or update of a data set to the
database and queues (Y or N). If Y is specified, action takes place as soon as the SMF
data set creation record is received (when the data set is closed). This process does
not ensure successful step or job termination.
Limits: Y or N
Default: N (causes triggering or posting action to take place at the job termination).
Batch keyword: POST
DEVICE
(Optional) Specifies a device type. If specified, TAPE or DASD are the only
acceptable values.
Batch keyword: DEVICE
DSORG
(Optional) Specifies the data set organization. Same as the DSORG specified in the
DCB subparameter in the JCL.
Limits: 1 to 3 alphanumeric characters
Batch keyword: DSORG
RECFM
(Optional) Specifies the record format of the data set. Same as the RECFM specified
in the DCB subparameter in the JCL.
Limits: 1 to 5 alphanumeric characters
Batch keyword: RECFM
LRECL
(Optional) Specifies the logical record length of the data set. Same as the LRECL
specified in the DCB subparameter in the JCL.
Limits: 1 to 5 numeric characters
Batch keyword: LRECL
BLKSIZE
(Optional) Specifies the block size of the data set. Same as the BLKSIZE specified in
the DCB subparameter in the JCL.
Limits: 1 to 5 numeric characters
Batch keyword: BLKSIZE

More information:

Permanent Data Sets (see page 304)

Chapter 9: Data Sets 309

Data Set Changes

Usage Notes
You can maintain connections to jobs that require this data set using the DB.3.1 panel.

Example: Batch Input

This batch input example adds data set SYS2.PROCLIB to the CA WA CA 7 Edition
database as a permanent type.

DBM
DSN
ADD,DSN=SYS2.PROCLIB,TYPE=PERM
DBM

Data Set Changes

Use the DB.6 panel to change the characteristics of a data set by entering the UPD
function and the changed field values.

One of the more common uses of this panel is that of renaming data sets. If the DCB for
this data set is not changing, all that you must enter is the RENAME function and the
NEWNAME for the data set. This panel changes the data set name in the CA WA CA 7
Edition database. To change the data set name in z/OS, use the RENAME top line utility
command.

If the DCB attributes change, be sure that the SMF indicator has the proper value for the
situation. If the system is to pick up automatically the DCB characteristics, set the SMF
indicator to Y. The appropriate DCB field cleared to blanks or zeros.

Note: Ensure that the RENAME occurs before changing JCL and loading of jobs. If not,
the DB.3.1 updates sometimes need to be manually performed to disconnect the old
data set name.

310 Database Maintenance Guide

Chapter 10: JCL and PARM Data
Maintenance
This section identifies the panels and commands used to manage JCL and PARM data
within CA WA CA 7 Edition.

This section contains the following topics:

Parameter Data Maintenance for Internal Cross-Platform Job Types (see page 311)
DB.7 - JCL Library Maintenance Panel (see page 312)
Scheduled Overrides (see page 317)
Additional Override Statements (see page 324)
SASSJCLU - JCL Utility (see page 334)
JCL Validation (see page 336)
LOAD Command Processing (see page 337)
Special Override Library (see page 337)
Alternate JCL Libraries (see page 339)

Parameter Data Maintenance for Internal

Cross-Platform Job Types
Although these topics consistently refer to JCL (for CPU job types), the topics also apply
to parameter data (PARM data) for XPJOB and agent job types. XPJOB and agent jobs
are referred to as internal cross-platform jobs. Unless a specific note for XPJOBs or
agent jobs is present, you can apply all JCL concepts that are discussed here to internal
cross-platform jobs. You should also be aware of several other items.

When using the JCL or QJCL commands or panels to edit CA7TOUNI or internal
cross-platform PARM data, the FETCH AND EDIT (FE) function is best used to maintain
and allow case-sensitive editing on the parameter data. With the FE function, CA WA CA
7 Edition accesses the database or queue record that denotes whether the job is a
CA7TOUNI or internal cross-platform job type. This function enforces the mixed-case
editing of the data. If the data is fetched using the FETCH function and then edited using
the EDIT function, the information about the job type is lost. The editor defaults to the
OPTIONS,INITCASE specification in the ONLINE initialization file.

Chapter 10: JCL and PARM Data Maintenance 311

DB.7 - JCL Library Maintenance Panel

Unless an internal cross-platform job has been previously defined in the CA WA CA 7

Edition database, the initialization file OPTIONS statement, INITCASE keyword,
determines the case-sensitivity for the edit session. If the internal cross-platform job has
been previously defined, the mixed case attribute (which allows both uppercase and
lowercase letters) is automatically assigned. If INITCASE=N is coded, all data is forced to
uppercase. If INITCASE=Y is coded, you can set the case by entering MIXED or UPPER in
the command area of the edit session.

If a PARM data member is added through this maintenance facility, this information is
not added to the internal cross-platform job definition. If you want to use the new
member during the submission process, you must update the internal cross-platform
job definition through the appropriate formatted screen using a top line command
(XPJOB or AGJOB).

Any references to the LOAD process do not apply to internal cross-platform job types.
Because these jobs only have one step and do not reference any z/OS data sets, the
LOAD process is not executed for internal cross-platform jobs.

The RUN and RUNH functions do not work for internal cross-platform job types from the
JCL Maintenance panels because required information (such as Node, Agent Job Type,
Agent Name, and Executable (file or script)) is not contained within the PARM data.
Because these functions can be used for JCL of the CPU jobs that are not defined in the
CA WA CA 7 Edition database, the functions can be attempted, and JCL errors result for
internal cross-platform jobs.

Regular jobs can have either a JCL-ID or a JCLLIB coded. JCL-ID is numeric, and JCLLIB is
symbolic. The JCL Maintenance panel contains both of these fields. Internal
cross-platform jobs use one field for both numeric and symbolic values. This field is
named PARMLIB (XPJOBs include the word "Optional"). Its batch keyword equivalent is
PRMLIB. If the internal cross-platform job uses a numeric value for PRMLIB, put that
value in the JCL Maintenance panel JCL-ID field. If the PRMLIB value uses a symbolic
name (starting with &), use that symbolic name in the JCL Maintenance panel JCLLIB
field.

DB.7 - JCL Library Maintenance Panel

The DB.7 - Library Maintenance panel lets you enter or review statements in PDS or
sequential libraries. Also, you can use the panel to review CA Librarian or CA Panvalet
JCL.

To display the panel, enter:

■ 7 as the FUNCTION on the DB Menu panel.
■ DB.7 as the FUNCTION on any other menu or formatted input panel.
■ DB.7 or JCL as a top line command.

312 Database Maintenance Guide

 DB.7 - JCL Library Maintenance Panel

To exit the panel:

■ Press PF3 to return to the DB Menu panel except with the TSO/ISPF interface when
PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter the wanted top line
command if yet another function is wanted.

----------------------- CA-7 JCL LIBRARY MAINTENANCE -----------------------

FUNCTION: xxxxxxxx (APPEND,CLEAR,DELETE,EDIT,FE,FETCH,
RENAME,REPL,RUN,RUNH,SAVE)

MEMBER: xxxxxxxx NEWNAME/OPTION: xxxxxxxx

DSN: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx JCL-ID: nnn

VOLSER: xxxxxx JCLLIB: &xxxxxxxxxxxxxxx

ACTIVE SIZE: nnnn

PROGRAM: SM50 MSG-INDX: nn -- DB.7 -- yy.ddd / hh:mm:ss

MESSAGE:

This panel contains the following fields:

FUNCTION
Specifies the function to perform. Value must be the name of some other panel or
one of the following values:
APPEND
Attaches card-image data to the end of any existing lines in the terminal's
Active Area.
CLEAR
Clears panel input data fields and clears the user's Active Area.
DELETE
Deletes a member from a PDS.

Chapter 10: JCL and PARM Data Maintenance 313

DB.7 - JCL Library Maintenance Panel

EDIT
Transfers the user to the edit facility and allows text processing. If editing a
CA7TOUNI or internal cross-platform job, we recommend the FE function to
ensure a mixed-case editing environment.
FE
Combines FETCH and EDIT commands.
FETCH
Retrieves data and replaces the user's Active Area with this text. If editing a
CA7TOUNI or internal cross-platform job, we recommend the FE function to
ensure a mixed-case editing environment.
RENAME
Used with the NEWNAME field, renames a PDS member.
REPL
Replaces a PDS member or sequential data set with the contents of the Active
Area.
RUN
Submits the text editor Active Area to the default MAINID without verifying the
input requirements or performing the updates that typically follow a successful
job completion. Job start and job end messages are sent to the MASTER
terminal (typically the BROWSE data set). The jobs that are scheduled with this
function always show a due-out date and time of 69001/0000. If a /*PRIORITY
statement is found as the first statement being submitted by this function, the
statement is ignored and not submitted.
Limits: RUN(H) function is not valid with internal cross-platform job types.
Note: The SASSXX05 exit is invoked for each JCL statement. Also, if a job is in
the CA WA CA 7 Edition database with this member name and it is set to insert
the CA WA Restart Option RMS step and the CA WA Restart Option interface is
installed, the RMS step is inserted. However, no other job definition (DB.1)
values are used for the current submission.
RUNH
Performs the same action as RUN function except this job is placed in CA WA
CA 7 Edition hold status.
SAVE
Adds a PDS member or replaces a sequential data set with the contents of the
Active Area.
Note: The SAVE or REPL function cannot be performed on CA Librarian or CA
Panvalet files.
Batch keyword: Positional parameter

314 Database Maintenance Guide

 DB.7 - JCL Library Maintenance Panel

MEMBER
Specifies the required member name for PDS, CA Panvalet, or CA Librarian access.
This field must be omitted for sequential files.
Limits: 1 to 8 alphanumeric characters
Batch keyword: Positional parameter
NEWNAME/OPTION
(Optional) Specifies a multiple purpose field. This field is required with the RENAME
function to define the new name that is to replace the old name.
Default: Blank
Limits: 1 to 8 alphanumeric characters and required for RENAME function only.
Batch keyword: NEWNAME
Note: For CA Librarian or CA Panvalet data set functions, a value of N indicates that
include statements are not expanded. Default causes those statements to be
expanded.
DSN
(Optional) Specifies the optional data set name. When reviewing a member of a
PDS, CA Panvalet, or CA Librarian file, DSN is not needed when JCLID is specified. If
the data set is cataloged, DSN is sufficient. If the data set is not cataloged, DSN must
be specified with the VOLSER field that follows.
Limits: 1 to 44 alphanumeric characters
Batch keyword: DSN
JCL-ID
(Optional) Specifies the JCL library identification. Can be used instead of DSN and
VOLSER fields to refer to a JCL statement. Must be a numeric INDEX assigned to a
JCL statement. JCL-ID and JCLLIB are mutually exclusive.
Default: Value is obtained from the corresponding job entry in the database if it
exists. Otherwise, the default is 0 (if DSN and VOLSER are omitted).
Limits: 1 to 3 numeric characters from 0 through 999. A value of 255 is reserved for
symbolic indexes. See JCLLIB.
Batch keyword: JCLID

Chapter 10: JCL and PARM Data Maintenance 315

DB.7 - JCL Library Maintenance Panel

VOLSER
(Optional) Specifies the volume serial number on which the data set resides. Only
used with DSN (that precedes). The volume must be available to CA WA CA 7
Edition.
Limits: 1 to 6 alphanumeric characters
Batch keyword: VOL
JCLLIB
(Optional) Specifies the JCL library identification. Can be used instead of DSN and
VOLSER fields to refer to a JCL statement. Must be a symbolic INDEX assigned to a
JCL statement. JCLLIB and JCL-ID are mutually exclusive.
Default: Blank
Limits: 2 to 16 alphanumeric characters beginning with an ampersand (&). The
value &HELP is reserved.
Batch keyword: JCLLIB
ACTIVE SIZE
Indicates a system-generated field that tells the user how many lines exist in the
Active Area for the current terminal session.
Note: CA Panvalet, CA Librarian, and PDS data sets require a JCL definition in the
initialization file and in the execution JCL for CA WA CA 7 Edition.
When EDIT or FE is entered, the user is transferred to the edit facility.

More information:

CA 7 Text Editor Environment (see page 344)

316 Database Maintenance Guide

 Scheduled Overrides

Usage Notes
A shortcut method of displaying a specific job is to enter the following as a top line
command:

JCL,jobname

You can use this panel to access any card-image PDS, CA Librarian, CA Panvalet, or
sequential file that is on a DASD volume available to CA WA CA 7 Edition.

If a SAVE/REPL is done for a member name that matches a job name in the CA WA CA 7
Edition database, and the specified DSN library is a CA WA CA 7 Edition JCL data set, the
job is flagged for reload on the next run. However, if RELOAD of N is used on the DB.1
(JOB) panel, the RELOAD on the next run is ignored.

When editing CA7TOUNI or internal cross-platform jobs, we recommend the FE (fetch

and edit) function to preserve the mixed case editing environment.

If the DB.7 panel is used to store the JCL in the special override library and the member
name is the same as the job name, the USE-OVRD-LIB field is automatically set to Y.

Note for the RUN Function: If external security is being used with SUBUID, a job that is
not defined to CA WA CA 7 Edition (not in the CA WA CA 7 Edition database) has the
owner user ID to be considered the same as the requestor user ID.

Scheduled Overrides
CA WA CA 7 Edition lets you schedule JCL overrides. The scheduled overrides can consist
of any statement that can be included with the JCL for a job, not only JCL statements.
Some special purpose statements, described later in this section, and any JCL or
embedded data records can be scheduled. This method enables users to have the run
stream contents dynamically constructed to fit the needs of any particular run.

You can schedule overrides for use:

■ On specific dates
■ After specific dates
■ Before specific dates
■ Between specific dates
■ Only after a certain time-of-day
■ Only before a certain time-of-day

Chapter 10: JCL and PARM Data Maintenance 317

Scheduled Overrides

■ With specific schedule IDs

■ Within a range of schedule IDs

This method lets users prepare the proper statements anytime in advance of their needs
without having to remember them on the days they are needed. This method also
enables users to ensure that they are used only on the appropriate days.

The scheduled overrides are placed in the execution JCL members. They cannot be used
in the PROCLIB members because CA WA CA 7 Edition does not access those members
directly. The statements to be scheduled are placed in the JCL wherever they belong and
are bookended with special reserved CA WA CA 7 Edition control statements. One
special statement is placed immediately ahead of the statements to define the
scheduling criteria. Another special statement is placed at the end of the set to mark the
end of the statements being scheduled. Multiple sets can be included within a single
job. All sets must be located after the JOB statement.

The first special statement of each set indicates the scheduling criteria and whether to
include or exclude the other statements in the set based on those criteria. The
characters #JI, #JO, #XI, or #XO in positions 1-3 of the statement identify these special
statements. Also, these statements cannot be continued.

#JI and #JO Statements

These statements have the following format:

{#JI|#JO} [,ID={0|nnn|nnn-nnn|(nnn,...nnn)}]
[,BD={00000|yyddd}]
[,BT={0000|hhmm}]
[,ED={99999|yyddd}]
[,ET={2400|hhmm}]
[,JOB=jobname]
[,OA={0000|hhmm}]
[,OB={2400|hhmm}]
[,CV=DO|DL|CU]

318 Database Maintenance Guide

 Scheduled Overrides

#JI
Indicates to Include the statements that are based on the specified scheduling
criteria.
#JO
Indicates to Omit the statements that are based on the specified scheduling criteria.
ID
(Optional) Specifies a schedule ID number. If this ID schedules the job, this test for
statement inclusion or exclusion is considered true.
Default: 0
Limits: 1 to 3 decimal characters from 0 through 999
0
All schedule IDs.
nnn
Defines a specific schedule ID.
nnn-nnn
Defines a range of schedule IDs. If either of the two IDs specified or any ID
between those two IDs schedules the job, this test is considered true.
(nnn,...,nnn)
Defines a list of IDs, either specific or ranges, which are separated by commas
and enclosed within parentheses. If any test in the list is true, statements are
included or excluded based on the type of statement used.
BD
(Optional) Specifies a beginning date after which the overrides are in effect.
Default: 00000
Limits: 5 numeric characters Julian date that is specified as yyddd
BT
(Optional) Specifies a beginning time-of-day for the BD date.
Default: 0000
Limits: 4 numeric characters that are specified as hhmm

Chapter 10: JCL and PARM Data Maintenance 319

Scheduled Overrides

ED
(Optional) Specifies an ending date after which the overrides are no longer in effect.
Default: 99999
Limits: 5 numeric characters Julian date specified as yyddd
ET
(Optional) Specifies an ending time-of-day for the ED date.
Default: 2400
Limits: 4 numeric characters specified as hhmm
JOB
(Optional) Specifies that inclusion/exclusion is based on a matching fully qualified
job name.
Limits: 1 to 8 alphanumeric characters
OA
(Optional) Specifies a time-of-day only at which and after which the overrides are
considered for inclusion or exclusion. The OA time should be lower than the OB
time specified.
Default: 0000
Limits: 4 numeric characters specified as hhmm
OB
(Optional) Specifies a time-of-day only at which and before which the overrides are
considered for inclusion or exclusion.
Default: 2400
Limits: 4 numeric characters specified as hhmm
CV
(Optional) Specifies the comparison values against which BD, BT, ED, ET, OA, and OB
parameters are compared.
Default: DO
DO
Specifies to compare values against the due out date and the time-of-day
values.

320 Database Maintenance Guide

 Scheduled Overrides

DL
Specifies to compare values against the deadline date and the time-of-day
values.
CU
Specifies to compare values against the current date and the time-of-day
values.
The ID, BD, BT, ED, ET, OA, OB, and CV parameters can be used in combination to
accomplish the wanted result. At least one of the parameters must be used.

Note: The default date and time used for the test for exclusion or inclusion is the job's
due out time unless otherwise specified on the CV parameter. That is, if the due out
time for the job falls within the beginning and ending date and time, the statements are
excluded or included. The due out time for a demanded job is the current time plus one
hour unless otherwise specified on the CV parameter or specified differently with the
DOTM, LEADTM, or both on the DEMAND command. When using JCL validation to test
these statements, the time that is used is always the current time because due-out and
deadline times are not applicable.

If any errors are encountered in the #JI or #JO override statements (that is, invalid data
for ID, BD, BT, ED, ET, OA, OB, or CV fields), a message is sent notifying the MASTER
station that the JCL could not be attached, and the job remains in the request queue in
SKELETON status.

The first statement in any JCL member must be a JOB statement and cannot be
overridden. The exception is a /*PRIORITY statement that can precede the JOB
statement. However, #JI and #JO statements must come after the JOB statement.

#JEND Statement
Another #JO or #JI statement, an end-of-file, or a #JEND statement can terminate the
conditional statements. The #JEND statement indicates the end of a set of Scheduled
Override control statements.

This statement has the following format:

#JEND

#JEND has no other keywords, and it must begin in position 1 of the statement.

Note: #JI, #JO, and #JEND statements are stripped out of the JCL, and overrides applied,
as the JCL for the job is brought into the queue. These statements cannot be seen in the
JCL for the job in the queue, nor can they be added to the queue JCL.

Chapter 10: JCL and PARM Data Maintenance 321

Scheduled Overrides

#XI, #XO, and #XEND Statements

If the user prefers # statements to remain until submission time, the characters #XI,
#XO, and #XEND must be substituted for #JI, #JO, and #JEND respectively. The format
and field descriptions of the #XI, #XO, and #XEND statements are the same as the #JI,
#JO, and #JEND statements. All scheduling parameters have the same meaning when
either the #X or #J statements are used. The only difference between #X and #J is that
the overrides are applied at submission time for the #X statements. If any errors are
encountered in the #XI or #XO override statements at submission time, the job is
flushed with an error message.

Any time after the job enters the queues and before JCL submission, #X statements can
be reviewed, changed, or both with the QM.5 panel.

Scheduled Override Examples

Example: Omit statements with specific schedule ID

This example omits statements whenever a job is scheduled by Schedule ID 6.

#JO,ID=6
.
. (JCL statements to be omitted)
.
#JEND

Example: Include statements with date and time

This example includes statements until date 13265 at 8.00 a.m.

#JI,ED=13265,ET=0800
.
. (JCL statements to be included)
.
#JEND

Example: Omit statements with dates

This example omits statements from 13200 through 13206.

#JO,BD=13200,ED=13206
.
. (JCL statements to be omitted)
.
#JEND

322 Database Maintenance Guide

 Scheduled Overrides

Example: Include statements with dates

This example includes statements from 13200 through 13206.

#JI,BD=13200,ED=13206
.
. (JCL statements to be included)
.
#JEND

Example: Include statements with several schedule IDs

This example includes statements whenever a job is scheduled by schedule IDs 1, 4, 5, 6,

and 9.

#JI,ID=(1,4-6,9)
.
. (JCL statements to be included)
.
#JEND

Example: Include statements between two times

This example includes statements only between 10:00 a.m. and 4:00 p.m.

#JI,OA=1000,OB=1600
.
. (JCL statements to be included)
.
#JEND

Example: Omit statements between two times for specific schedule IDs

This example omits statements only between 4:00 p.m. and 10:00 p.m. for schedule IDs
9, 10, and 11.

#JO,ID=9-11,OA=1600,OB=2200
.
. (JCL statements to be omitted)
.
#JEND

Note: The JCLxx text editor command or the LJCK command can simulate the JCL
inclusions or omissions. This simulation can help test the conditional JCL statements for
proper generation. SASSJCLU can remove expired override statements from PDS
libraries.

Chapter 10: JCL and PARM Data Maintenance 323

Additional Override Statements

More information:

SASSJCLU - JCL Utility (see page 334)

Additional Override Statements

CA WA CA 7 Edition also provides a number of other functions that can be accomplished
with statements that also begin with a # in position 1. These statements can be located
anywhere within the execution JCL after the JOB statement. (PROCLIB members
containing these statements are not seen by CA WA CA 7 Edition and including them
there would thus serve no purpose.) They can be scheduled with #Jx statements if
wanted; however, they can be included by themselves if conditional inclusion is not
necessary. Only the #MSG statement can be scheduled with the #Xx statement.

These statements are valid only when a job using them is brought into the request
queue and not at submit time. Thus, the #X statements cannot be used to schedule
them (other than the #MSG statement).

Note: Do not use the following override statements with internal cross-platform job
types: #MNT (Maintenance run) and #7UNI (batch cross-platform submission).

The following statements can be placed in the execution JCL:

#ARF
Overrides the ARFSET designation on the job definition panel when the JCL is
attached for the job.
#HLD
Places the job in HOLD. Similar to the HOLD command and the job definition panel
HOLD option.
#JCL
Sets a JCL override requirement.
#MNT
Considers this run a maintenance type run. Similar to the DB.1 panel MAINT option.
#MSG
Sends the messages to the master station at job submission time.
#NOX
Makes this run nonexecutable. Similar to the job definition panel EXEC option.

324 Database Maintenance Guide

 Additional Override Statements

#NTR
Turns off triggering by successful job completion for this run. Similar to the
DEMAND command with SET=NTR option.
#RES
Changes any Workload Balancing resource requirement for this run. Similar to the
RESCHNG command.
#SCC
Defines step-level condition code checking criteria.
#VER
Sets manual verification requirement. Similar to the VERIFY command and the job
definition panel VERIFY option.
#7UNI
Flags JCL as a cross-platform submission job. The statement must be the first
statement in the member.

#ARF Statement
The #ARF statement lets you override the ARFSET designation on the job definition
panel when the JCL is attached for the job.

This statement has the following format:

#ARF,SET=nnnnnnnn

#ARF
Identifies the statement as an ARFSET override. #ARF must begin in position 1 of
the record.
SET
Identifies the name of the ARFSET to use for this run of the job.

Example

Suppose that the job definition panel for job A designates an ARFSET named ARECOVR
to be used for ARF recovery.

The following example illustrates the use of the #ARF statement to override the ARFSET
designation:

#ARF,SET=ABC

In this example, ARFSET ABC is used to determine ARF recovery for this job instead of
ARECOVR.

Chapter 10: JCL and PARM Data Maintenance 325

Additional Override Statements

Usage Notes

When a job initially enters the request queue, CA WA CA 7 Edition determines whether
ARF is to monitor the job. CA WA CA 7 Edition selects an ARFSET to be used for
monitoring and recovery that is based on the following hierarchy:
1. If an ARFSET is supplied on the DEMAND or RUN command, it is used.
2. If no ARFSET is supplied on a DEMAND or RUN command for the job, the ARFSET
named on the appropriate #ARF statement in the JCL is used.
3. If no ARFSET is supplied on a DEMAND or RUN command for the job, and if no
ARFSET is named on a #ARF statement in the JCL, the ARFSET named on the job
definition panel is used.
4. If none of the preceding sources supplies an ARFSET reference, ARF does not
monitor the job.

#MSG Statement
The #MSG statements let you send messages to the CA WA CA 7 Edition Master Station
at job submission time. These statements must begin in column 1 and are placed in
execution JCL members on the JCL libraries. The edit facility, with the JCL command of
database maintenance, can be used to add these statements. The statements can
appear within scheduled overrides, in which case sending the messages is conditional.

This statement has the following format:

#MSG,message-text

The message-text in columns 6 through 72 is sent immediately preceding the submit

message. The actual #MSG statements are never included in the submitted JCL.

Note: The same rules for other # statements also apply to the #MSG statement.

326 Database Maintenance Guide

 Additional Override Statements

#RES Statement
The #RES statement in the execution JCL lets you make temporary changes to the
high-water workload balancing resource requirements of the job.

This statement has the following format:

#RES[,TP1=nnn]
[,TP2=nnn]
[,CPUTM=mmmss]
[,ELAPTM=hhmm]
[,PRT=nnn]
[,CLASS=x]

TP1
(Optional) Specifies the number of tape drives of TYPE1 that are required of the job.
Not valid for internal cross-platform job types.
Limits: 1 to 3 numeric characters from 0 to 255
TP2
(Optional) Specifies the number of tape drives of TYPE2 that are required of the job.
Not valid for internal cross-platform job types.
Limits: 1 to 3 numeric characters from 0 to 255
CPUTM
(Optional) Specifies the amount of CPU time the job consumes in minutes and
seconds. Not valid for internal cross-platform job types.
Limits: 2 to 5 numeric characters specified as mmmss where mmm can be from null
to 999; seconds from 00 to 59
ELAPTM
(Optional) Specifies the elapsed time required for the job.
Limits: 2 to 5 numeric characters specified as hhmm where hh can be from 0 to 24;
mm from 00 to 59, the highest value being 2400.
PRT
(Optional) Specifies the initial priority value for the job.
Limits: 1 to 3 numeric characters from 0 to 255
CLASS
(Optional) Specifies the WLB job class of the job.
Limits: 1 alphanumeric character

Chapter 10: JCL and PARM Data Maintenance 327

Additional Override Statements

#SCC Statement
The #SCC statements in the execution JCL let you define step level condition code tests
used to determine whether the job completed successfully.

This statement has the following format:

#SCC,COND=(xxxx[-yyyy],ro,{*|nnnnnnnn|jjjjjjjj.nnnnnnnn|*-nnnnnnnn|*-jjjjjjjj.nnn
nnnnn})

#SCC
Identifies the statement as a step level condition code test. #SCC must begin in
position 1 of the record.
COND
Identifies the following information as condition code test values.
xxxx
Specifies the condition code value to test against the actual value returned at
execution time. The entry must be numeric and fall within the range of 0 to
9999.
A range of condition codes can be specified as xxxx-yyyy (or yyyy-xxxx) where
xxxx is the minimum in the range of condition code values to be tested and
yyyy is the maximum in the range of condition codes to be tested. Each entry
must be numeric and fall within the range of 0 to 9999.
ro
Identifies the relational operator specifying the comparison to be made. If the
condition code value returned has the relationship defined by the ro entry, the
step value is unacceptable and the job is considered abnormally completed. For
example, if ro is set to LT and xxxx is set to 8, the job is marked as completing
abnormally if 8 is less than the return code from the step whose name matches
the name in the nnnnnnnn parameter. The value must be one of the following:
GT
Specifies greater than.
GE
Specifies greater than or equal to.
EQ
Specifies equal to.

328 Database Maintenance Guide

 Additional Override Statements

LT
Specifies less than.
LE
Specifies less than or equal to.
NE
Specifies not equal to.
FL
Specifies to mark the job abnormally terminated if the named step was
flushed.
Note: Condition code values coded on the #SCC statement are ignored if an ro
of FL is specified.
nnnnnnnn jjjjjjjj.nnnnnnnn
(For CPU Jobs) Specifies the step name (and optional procstepname) of the
steps to test. An * (asterisk) entry indicates that the test applies to all job steps.
A test that is to be applied to all job steps is a global #SCC test. To exclude a
step from a global test, code the statement using the following format:
#SCC,COND=(xxxx,ro,*-nnnnnnnn)

A #SCC statement coded in this fashion indicates that the test is to apply to all
job steps except the one named by nnnnnnnn.
If specifying a test that applies to a step in a cataloged or in-stream procedure,
the jjjjjjjj identifies the EXEC statement of the calling job step; nnnnnnnn
identifies the EXEC statement of the procedure step that issues the return code
to be used in the test. If only nnnnnnnn is specified, the test is applied to all
occurrences of that job step name or procedure step name.
(For XPJOB Jobs) Only nnnnnnnn should be specified, and it should be set to the
CCI node name (or alias if present) where the job will execute (that is, the
remote node). An * (asterisk) entry indicates that the test applies to all CCI
node names. A test that is to be applied to all CCI node names is a global #SCC
test. To exclude a CCI name from a global test, code the statement using the
following format:
#SCC,COND=(xxxx,ro,*-nnnnnnnn)

A #SCC statement coded in this fashion indicates that the test is to apply to all
job steps except the one named by nnnnnnnn.
Agent jobs cannot use #SCC statements because the agent determines success
or failure of a job execution.

Chapter 10: JCL and PARM Data Maintenance 329

Additional Override Statements

Example

The following statements are examples of the #SCC statement:

#SCC,COND=(16,LT,STEP0030)

In the preceding example, if 16 is less than the condition code value returned from
STEP0030, the job is considered as having terminated abnormally.

Note: A condition code test defined on a #SCC statement is applied to ALL steps whose
name matches nnnnnnnn until all such steps have been tested or until conditions
defined by a #SCC test have been met. Steps are tested in order of execution.

It is possible to exclude only a couple of steps from a global #SCC test by coding multiple
#SCC statements with the same RO and condition code:

#SCC,COND=(0,LT,*-STEP5)
#SCC,COND=(0,LT,*-STEP10)

The preceding example would cause all steps of the job except STEP5 and STEP10 to be
tested. If the RO or condition code specified are different, each statement would be
evaluated separately.

Usage Notes
■ #SCC statements can optionally be scheduled using the #JI or #JO techniques. If the
#JI or #JO are used, different #SCC statements can be used per SCHID.
■ #SCC statements cannot be scheduled using #XI or #XO and cannot be added to JCL
in the queue.
■ Multiple #SCC statements are allowed for each job step name.
■ A #SCC test for a step name of * (asterisk) can be used by itself to apply to each
step in the job. If used in combination with a #SCC for a specific job step, the
condition code returned by that step is validated against both #SCC condition code
tests.
■ The RO value on the job definition panel must be set to #S or all #SCC statements
are ignored. If job-level condition code testing is wanted, the job definition panel
must be used and the RO value is any other valid value (other than #S). In this way
#SCC statements can still be in the JCL for future use, but are ignored.
■ Since CA WA CA 7 Edition only regains control of a job at job completion time, #SCC
tests cannot be used to bypass execution of job steps.
■ Failure of any condition code test, either at step level or job level, causes the job to
be returned to the request queue and flagged with a restart requirement.

330 Database Maintenance Guide

 Additional Override Statements

■ #SCC statements can be located anywhere in the JCL following the JOB statement,
but should be positioned in step execution sequence for user readability.
■ Overhead for a job-level condition code test as defined on the job definition panel is
less than using the #SCC statements and should be considered before implementing
#SCC tests. For most jobs, the job definition panel option probably can be used.
■ SMF step termination records cause a job step to be tested against all #SCC tests
defined for that step. No tests are made to ensure that a step exists with the name
defined in #SCC statements.

Additional Override Examples

The following statements are more override examples.

Example 1

This example assumes that job DUSAZZ01 runs Monday through Friday. Monday
through Thursday has been defined as SCHID=1 and Friday as SCHID=2. Manual
verification is only required on the Friday run.

//DUSAZZ01 JOB ...

#JI,ID=2
#VER
#JEND
.
.
.

Chapter 10: JCL and PARM Data Maintenance 331

Additional Override Statements

Example 2

This example assumes that job DUSAZZ01 runs Monday through Friday. Monday
through Thursday has been set up as SCHID=1 and Friday as SCHID=2. Job resources
have been set up as follows:

Tape drives of TYPE1 = 0

Tape drives of TYPE2 = 0
CPU time (mmmss) = 00130
Elapsed time (hhmm) = 0012
Class = A

The preceding resources are needed only from Monday through Thursday. On Friday,
the job uses two TYPE1 tape drives and requires 2 minutes and 40 seconds of CPU time
and 20 minutes of elapsed time. To change the resource requirements only for the
Friday run, enter:

//DUSAZZ01 JOB ...

#JI,ID=2
#RES,TP1=2,CPUTM=00240,ELAPTM=0020
#JEND
.
.
.

Example 3

This example assumes that job XYZ runs daily, Monday through Friday. But on Friday, a
control statement must be included to indicate a week-ending run and extra file is to be
output. Monday through Thursday is defined as SCHID=1 and Friday is defined as
SCHID=2. The following sample JCL is for job XYZ:

//XYZ JOB ...

//JOBLIB DD DSN=MY.LOADLIB,DISP=SHR
//STEP1 EXEC PGM=MYPGM
//INPUT DD DSN=INPUT.TRANS,DISP=SHR
//RPTDAILY DD SYSOUT=A
#JI,ID=2
//WKLYOUT DD DSN=WEEK.ENDING.FILE,DISP=(NEW,CATLG)...
#JEND
//SYSIN DD *
#JI,ID=1
DAILY
#JI,ID=2
FRIDAY
#JEND
/*

332 Database Maintenance Guide

 Additional Override Statements

Example 4

This example assumes that a job has 10 steps. On STEP01, consider any condition code
other than 5 as invalid. If the condition code returned from any step other than STEP01
is not equal to 0, move the job back to the request queue and flag it for restart.

#SCC,COND=(5,NE,STEP01)
#SCC,COND=(0,NE,*-STEP01)

Example 5

This example assumes that a job has 5 steps. On STEP01 any condition codes other than
0, 8, 16, and 32 should be considered invalid. STEP02-STEP04 has no condition code
checking. STEP05 should be considered invalid if the condition code is not 0 or 54.

Note: The range specified in the first test is 7-1, this is considered equivalent to 1-7.

#SCC,COND=(7-1,EQ,STEP01)
#SCC,COND=(9-15,EQ,STEP01)
#SCC,COND=(17-31,EQ,STEP01)
#SCC,COND=(32,LT,STEP01)
#SCC,COND=(1-53,EQ,STEP05)
#SCC,COND=(54,LT,STEP05)

Example 6

This example assumes that a job has 10 steps. On STEP03, consider any condition code
other than 100 as invalid. Only two condition codes are valid for STEP07: 0 and 100.
Consider any condition other than 0 as invalid on all remaining job steps. Code the
following #SCC statements to effect the correct tests:

#SCC,COND=(100,NE,STEP03)
#SCC,COND=(1-99,EQ,STEP07)
#SCC,COND=(100,LT,STEP07)
#SCC,COND=(0,NE,*-STEP03)
#SCC,COND=(0,NE,*-STEP07)

Example 7

This example assumes that the JOBCHECK step must complete with a condition code of
zero for the job to complete typically. Code the following #SCC statements:

#SCC,COND=(0,NE,JOBCHECK)
#SCC,COND=(,FL,JOBCHECK)

More information:

JCL Validation (see page 336)

Chapter 10: JCL and PARM Data Maintenance 333

SASSJCLU - JCL Utility

SASSJCLU - JCL Utility

SASSJCLU is a batch utility program that provides capabilities to perform the following
actions:
■ Remove expired JCL Scheduled Override control statements (#J and #X statements)
and the scheduled JCL from a JCL library member of a PDS.
■ Print the contents of all or selected JCL members in a JCL PDS data set.

Note: This utility can only be applied against a PDS JCL library. Members that are
updated show CA7JCLU as the ID from the last update and ISPF statistics are updated or
created.

The wanted functions to be performed are indicated through the PARM values to the
program. A SYSIN data set can be used to identify particular members to list, update, or
both.

The utility requires the following execution JCL:

//STEPX EXEC PGM=SASSJCLU,PARM='xxxxxxxx.....x'

//STEPLIB DD DSN=user-defined-CA-7-loadlib,DISP=SHR
//SYSPRINT DD SYSOUT=A
//SYSUT1 DD DSN=JCL-jcl.dataset.name,DISP=OLD
//SYSIN DD * (optional)
control card (optional)
/*

PARM='xxxxxxxx....x'
The acceptable values for PARM='xxxxxxxx....x' can be any of the following:
PRINT
Print the JCL members that are selected by control statements in the SYSIN
data set.
CLEAN=nn
Remove all scheduled JCL overrides from JCL members that are selected for
which the ending date (ED) is more than nn days before today's date.
PANIC
Remove all scheduled JCL overrides from JCL members selected.

334 Database Maintenance Guide

 SASSJCLU - JCL Utility

Usage Notes
Usage considerations for PARM options are:
■ If PARM is omitted, PRINT is the default.
■ CLEAN=nn causes CA WA CA 7 Edition JCL Scheduled Overrides to be removed from
the JCL library if their ending date (ED) was more than nn days before today's date.
If CLEAN is specified, the two-digit nn number must be present.
■ If CLEAN and PRINT are both specified, expired Scheduled Overrides are removed
and the contents of the selected members are listed. If a control statement is
present in the SYSIN data set, only selected members are subject to the CLEAN and
PRINT options in the SYSIN data set.
■ If CLEAN is specified and PRINT is not, any JCL member with expired Scheduled
Overrides removed is listed anyway.
■ PANIC causes all Scheduled Overrides to be removed, expired or not. If a SYSIN
control statement is specified, only JCL members selected have all Scheduled
Overrides removed.

Control Statement
The SYSIN DD statement is required only if a control statement is to be supplied. If the
SYSIN statement is not used, all members are selected. The control statement format,
starting in position 1 is:

1
NAMEKEY=xxxxxxxx

where:
xxxxxxxx
Is a JCL member name, up to eight characters, or the first part of a JCL member
name (generic selection). Generic selection here does not use an asterisk to indicate
the end of the common characters. All JCL members whose first characters match
the characters specified are subject to the operations specified by the PARM
selection.
Note: Care must be taken if member names with fewer than eight characters are
used. For example, if a member name is four characters, and they are the same as
the first four characters of an eight-character member name, both are considered.

Only one control statement is allowed per each execution of SASSJCLU.

Chapter 10: JCL and PARM Data Maintenance 335

JCL Validation

JCL
This illustrates sample JCL for the SASSJCLU utility:

//STEPX EXEC PGM=SASSJCLU,PARM='PRINT,CLEAN=14'

//STEPLIB DD DSN=cai.CAL2LOAD,DISP=SHR
//SYSPRINT DD SYSOUT=A
//SYSUT1 DD DSN=CA7.JCLLIB,DISP=OLD
//SYSIN DD *
NAMEKEY=DUSA
/*

This sample JCL is used to scan the JCL library for members with names beginning with
DUSA and:
■ Print those members starting with DUSA.
■ Remove all Scheduled Overrides that expired two or more weeks ago from the
DUSA members selected.

JCL Validation
The JCL Validation facilities can be invoked from the editor to check for various syntax
errors. This validation is available only when the native editor is used in Full Edit Mode
(FEM). Thus, if you are using the interface with TSO/ISPF, these subcommands are not
honored in the ISPF editor.

CA JCLCheck handles the JCL validation. A limited set of CA JCLCheck functions is

provided as part of the CA WA CA 7 Edition base product at no extra cost. However, a
more extensive report of errors is available when using the interface with the complete
CA JCLCheck.

336 Database Maintenance Guide

 LOAD Command Processing

LOAD Command Processing

Use the LOAD/LOADH command to create or recreate job profile data in the database.
Job profiles should agree with the current JCL. Therefore, any changes to the JCL must
be resynchronized with the database by loading the job.

The RELOAD field of the DB.1 panel serves as an alternative to this command.

Use the LOADH command to indicate that the job is to be entered into the queue in CA
WA CA 7 Edition hold status to allow for manual release at a future time.

Note: LOAD processing is not valid with internal cross-platform job types.

Use of this command causes the rest of the job's JCL to be flushed. The job returns to
the request queue with a JCL error.

Note: For more information about the LOAD/LOADH command, see the Command
Reference Guide.

Special Override Library

A supported JCL override library is intended to handle any one-time JCL needs that arise.

The combination of the special override library and the various special override
statements let you handle virtually every special need that can arise. See that discussion
for more details on the various special functions that are available.

More information:

Scheduled Overrides (see page 317)

Special Override Library Definition

Although PDS, CA Panvalet, and CA Librarian libraries are supported for execution JCL
for production jobs, this special override library is global for all jobs under the control of
CA WA CA 7 Edition and must be a PDS. Only one special override library can be defined
to CA WA CA 7 Edition.

This special override library must be allocated by the user and made available to CA WA
CA 7 Edition through an appropriate DD statement and an initialization file JCL
statement that specifies INDEX=254. This library is then available to the user on the
various panels and commands as JCL ID of 254.

Chapter 10: JCL and PARM Data Maintenance 337

Special Override Library

Temporary JCL Creation

Execution JCL can be placed here, through the DB.7 panel, any time prior to the
scheduling into the queues of the job that uses that JCL. The DB.1 panel field
USE-OVRD-LIB must also be set to Y for the special override library JCL to be used. If the
DB.7 panel is used to store the JCL in the special override library and the member name
is the same as the job name, the USE-OVRD-LIB field is automatically set to Y.

The next time the job is scheduled into the queues, CA WA CA 7 Edition uses the special
override library JCL instead of retrieving the JCL from the primary library specified with
the ID field in the JCL section of the job definition panel.

Temporary JCL Usage

When the job is initially brought into the queues and the USE-OVRD-LIB value is Y, the
JCL is copied in from the special override library instead of the normal production library
specified with the ID field on the DB.1 panel. The USE-OVRD-LIB value is then
automatically reset to a value of N, to prevent that JCL from being used again.

The JCL that was copied in from the special override library is used until a successful
completion of this run is accomplished. It can be altered using the QM.5 panel if
necessary. When the job completes successfully, the JCL is then deleted from the special
override library if the member name in the DB.1 panel field is the same as the job name.

Note: Your installation may choose to prevent the automatic deletion of JCL from the
special override library. The OVJCL keyword in the OPTIONS statement in the CA WA CA
7 Edition initialization file can be used to prevent this automatic deletion. If this option
is set, it applies to all CA WA CA 7 Edition jobs. For more information, see the OPTIONS
statement in the Systems Programming Guide. Before using this option, you should read
about alternate JCL libraries to see whether they are appropriate for your situation.

More information:

Alternate JCL Libraries (see page 339)

Other Considerations
A LOAD step automatically sets the USE-OVRD-LIB value to N whenever it is executed. If
a job has JCL in the special override library waiting for the job to be scheduled and a
permanent change is made to the master JCL in the normal production library, any load
of the JCL causes the USE-OVRD-LIB flag to be reset to N. Therefore, such changes must
be avoided, or at least not reloaded with a LOAD top line command, until after the job
has been scheduled into the queues with the set of JCL from the special override library.

338 Database Maintenance Guide

 Alternate JCL Libraries

Alternate JCL Libraries

CA WA CA 7 Edition supports a primary/alternate approach to JCL libraries. This enables
the user to place temporary JCL in a staging-type of library to be used for more than just
a single execution of a job. The special override library, discussed earlier in this section,
accommodates one-time overrides only and the temporary member is deleted after just
one execution of the job. CA WA CA 7 Edition LOAD processing does not use the
alternate JCL library (when using the LOAD command).

Alternate Library Definition

In the initialization file, JCL libraries are defined with a JCL statement. In each of these
statements, the ALT parameter is used to define which of the defined libraries is to be
the alternate library. Only one alternate can be defined for each library.

Libraries can be any of the supported organizations and do not have to be PDS like the
global special override library.

Temporary JCL Creation

Temporary JCL can be stored in an alternate library from either CA WA CA 7 Edition or
from outside of CA WA CA 7 Edition (for example, TSO, CA Roscoe, and so forth). The JCL
ID field on the job definition panel still indicates that the JCL resides in the primary
library.

Temporary JCL Usage

When CA WA CA 7 Edition schedules a job that uses a JCL library having an alternate
library defined, CA WA CA 7 Edition searches the alternate library first. If the JCL
member is found in the alternate library, CA WA CA 7 Edition uses the alternate JCL and
flags the job queue entry. If the JCL member is not found in the alternate library, CA WA
CA 7 Edition searches the primary library.

Unlike the special override library previously discussed, no action is taken by CA WA CA

7 Edition at job completion to delete JCL used from an alternate library. As long as a JCL
member exists in an alternate library, it is used for job scheduling.

The JCL ID specified on the DB.7 panel must specifically request an alternate library
since the job definition panel does not indicate alternate usage. Likewise, the LJCL
command shows JCL only from the primary library.

Runtime messages to the Master Station and the CA WA CA 7 Edition comment

statement included with the JCL for the job reflect the JCL ID number for the library
from which the JCL was taken for execution.

Chapter 10: JCL and PARM Data Maintenance 339

Alternate JCL Libraries

Other Considerations
Unlike the one-time Override library (INDEX=254), which is automatically reset by CA
WA CA 7 Edition, the user is responsible for ensuring deletion of temporary JCL from the
alternate library once it is no longer needed.

One library can be defined as the alternate for more than one primary library.

An alternate library can have its own alternate. However, searching is only done for the
primary library requested and its single alternate.

340 Database Maintenance Guide

Chapter 11: Using the Edit Facility
This section contains the following topics:
Overview (see page 341)
Active Area (see page 342)
Edit Work File (see page 343)
Environments (see page 343)
Editor Usage (see page 343)
CA 7 Text Editor Environment (see page 344)
TSO/ISPF Editor Environment (see page 367)

Overview
The CA 7 edit facility is an interactive component that can create, modify, and manage
80-character card-image data. With this facility, job streams (JCL and PARM data) can be
created or changed before submittal and documentation (prose) can be maintained in
the database.

This facility consists of files, panels, programs, and a command. The command is EDIT
that can be issued as a top line command or as a panel function. The files are referred to
as active area and the edit work file (EWF). The panels and programs vary based on the
environment from which EDIT is issued.

When this facility is invoked, the active area can be cleared or loaded with source data,
when requested. The active area is copied to the EWF and an editor program is
executed to make the wanted changes. When editing is complete, any saved data is
copied back to the active area. From the active area, it can be copied to the source file
or some other target file.

Chapter 11: Using the Edit Facility 341

Active Area

Note: For CA7TOUNI jobs and for any internal cross-platform jobs, the editing session
always appears in mixed case mode, allowing both uppercase and lowercase letters.

The following figure shows the edit facility data flow.

Active Area
The active area is a dynamic file that is suballocated from the scratch queue for each
terminal user. Allocation is performed one track at a time, as needed, to minimize disk
space usage.

This file is initialized by the CLEAR and FETCH functions. The CLEAR function removes all
data from the file and unallocates its disk space. The FETCH function allocates disk space
and copies data into the file. Several of the DB panels show a field that is named ACTIVE
SIZE. The field tells the terminal user how many lines of text are in this active area. A
CLEAR function is performed at every logon and logoff.

342 Database Maintenance Guide

 Edit Work File

Edit Work File

The edit work file (EWF) is a dynamic file that is created for each terminal user when
EDIT is invoked. For the CA WA CA 7 Edition environment, the file is suballocated from
the scratch queue as previously described for the active area. For other environments, it
is allocated according to the rules and conventions of the environment where
requested. The EWF space is released when leaving the editor.

The EWF is initialized by copying the contents of the active area. An editor program is
invoked in the environment of the terminal user to change the EWF data. When editing
is complete, any saved updates are copied back to the active area and the EWF is freed.

Environments
Currently, the edit facility supports the CA WA CA 7 Edition and TSO/ISPF environments.
Although the editing process is similar, the editor programs that are used in each
environment are different. Also, areas unique to each environment are in this section.

Editor Usage
Using the editor involves the following three general activities:
■ Invoking the editor
■ Editing text data
■ Leaving the editor

When using CA WA CA 7 Edition, the editor is invoked from another command or panel,
such as DB.7 or DB.4, although it can be requested with the EDIT top line command.
While under the control of the editor, several subcommands are available for editing
the text data. After making any wanted changes, it is necessary to leave or exit from the
editor to retain or use the updated text.

Invoking the Editor

Any of the following methods can invoke the editor:
■ Using the top line EDIT command.
■ Using the EDIT or FE (Fetch and Edit) functions from database maintenance or
queue maintenance panels or commands.

These functions cause the transfer of data from the active area to an edit work file, as
described previously. Next, they engage the editor programs for the appropriate
environment.

Chapter 11: Using the Edit Facility 343

CA 7 Text Editor Environment

Editing Text Data

Once in the editor, text can be created or changed using the subcommands appropriate
to the environment where editing occurs.

More information:

CA 7 Text Editor Environment (see page 344)

TSO/ISPF Editor Environment (see page 367)

Leaving the Editor

After completing the editing tasks wanted, the editor must be exited and changes saved,
if wanted. To save changes, the editor must be told to retain the updates, and the
updated EWF data must be transferred back to the active area. To cancel the changes,
the editor must be told to release the EWF and not transfer data back to the active area.

For the CA WA CA 7 Edition environment, the subcommands to leave the editor and
save the changes are SAVE, SS (SAVE-SAVE), and SR (SAVE-REPLACE). The subcommand
to leave the editor without retaining EWF changes is EXIT.

For the TSO/ISPF environment, ISPF edit macros are provided. They correspond to
required CA 7 editor subcommands. Also, when the editor is invoked, a default
subcommand is set. If cancel the changes, request the CA7EXIT subcommand.

More information:

CA 7 Text Editor Environment (see page 344)

CA 7 Text Editor Environment

The CA 7 text editor routines provide the capability to create or change text information
in the database, queues, and JCL data sets. These routines operate in the CA WA CA 7
Edition environment servicing multiple terminal users from a single address space and
using a single set of support files (queues). The editor can be invoked using interactive
online panels or batch card-image input.

344 Database Maintenance Guide

 CA 7 Text Editor Environment

Edit Modes
Earlier versions of CA WA CA 7 Edition contained a basic text editor. This editor is still
available, but is generally used by the batch terminal interface. For online editing, a
more flexible editor was developed that has a more flexible set of routines. Therefore,
two versions or modes of the text editor are available. These modes are referred to as
Full Edit Mode (FEM) and Alternate Edit Mode (EDIT or AEM). The Full Edit Mode offers
more features than the Alternate Edit Mode.

When EDIT is entered either as a top line command, from the DB Menu Panel or from
any formatted panel (other than a DB.2.n panel), FEM is automatically invoked (except
from batch). Once in FEM, the RETURN subcommand activates Alternate Edit Mode. To
return to Full Edit Mode from Alternate Edit Mode, enter the FEM subcommand.

Usage Considerations
■ To terminate the text editor modes without retaining changes, enter the EXIT
subcommand.
■ FEM is not a top line command. It is only used in the text editor facility.
■ If the text editor was entered from a top line EDIT command or from a formatted
panel where EDIT is not a listed function (for example, DB.1, DB.6), return is to the
DB Menu panel.
■ If the text editor was entered from a formatted panel (other than DB.2.n) where
EDIT is a valid function (for example, DB.7, DB.4), the return is to the originating
panel.
■ Unprintable (or hex) data can cause a 3270 screen error and terminate the user
session.
■ If you do not have a data set assigned to JCL-ID zero, some of the FEM
subcommands do not yield the intended results. For example, in this situation, the
SS subcommand does not save your changes into the intended library, only in the
edit work area. You must then enter the JCL command to invoke the CA-7 JCL
Library Maintenance panel and then enter SAVE as a function while supplying the
member name and a valid JCL-ID.

Chapter 11: Using the Edit Facility 345

CA 7 Text Editor Environment

Full Edit Mode (FEM)

Full Edit Mode is entered through the EDIT command, by the FE (Fetch Edit) function, or
through the FEM command if already in the Alternate Edit Mode. The FEM command
can only be entered as a command from the Alternate Edit Mode. FEM reduces the
number of operations in editing data. It also allows greater text change flexibility.

Normally, when FEM is entered, the edit work file (EWF) is positioned at the top. It is
possible, however, when entering FEM from the Alternate Edit Mode, to specify a
starting sequence number. For example, FEM 5725 would place the user in Full Edit
Mode beginning at the line (or next highest) whose sequence number is 5725.

A Full Edit Mode (FEM) panel consists of six areas of information:

1. Scale Line
2. Status Information
3. Data Area
4. Command Area
5. Message Line
6. Sequence Numbers/Subcommands

The first area, containing the scale line, appears at the top and bottom of the display.
This allows for column-oriented changes in the data area. (An asterisk denotes the last
effective column.)

The second area contains status information. It appears on the right half of line two.
Items of information found here are FILL/NOFILL, MIXED/UPPER case setting, insert
increment I (010) and NUM/NONUM.

The third area is the active area. It contains information residing in the edit work file
(EWF).

The fourth area on the FEM panel, the command line, appears on the left half of line
two. It is from this line that the commands are input. When the text editor is first
entered and the EWF is empty, lines must be inserted with an INSERTnnn command to
enable input to the EWF.

The fifth area is the message line on the last panel display line. When an error occurs or
specific status is required, this line is used. Under normal processing, this line remains
blank.

The sixth area on the FEM panel contains the sequence numbers of the data lines being
displayed. This area is used as a subcommand area to delete lines, insert blank lines and
position the display. More than one subcommand can appear in a single sequence
number.

346 Database Maintenance Guide

 CA 7 Text Editor Environment

The following rules apply when the data area, subcommand (sequence number field)
and command lines are used and the Enter key is pressed:
■ When the data area has no changes, and no subcommand or command is entered,
the display is paged forward (PF) or backward (PB) depending upon the default
page command showing in the command line.
■ When the data area has changes, and no subcommand or command is entered, the
data changes are applied and the display is positioned according to the default page
command (PF or PB).
■ When subcommands are entered and no command is entered, data area changes
are made, subcommands are processed and the display is positioned at the last P
(Position to this line) subcommand on the panel, or the first line of the current
display if no P subcommand was specified.
■ When a command is entered, all subcommands and data area changes are
processed. If the command is a display positioning command (TOP, BOTTOM, MD,
PF, PB, HF, HB, and so forth), positioning with the subcommand P is ignored. If the
command is not a display positioning command, the last P subcommand is honored,
or the first line of the current display designates the position if no P subcommand is
specified.

FEM Subcommands

The following subcommands can be placed in the sequence number area:

P
Positions the display to this line. The last P found on the page is honored.
D
Deletes the line at this sequence number from the EWF (edit work file).
DD
Deletes this line and all subsequent lines to the next DD or end of page.
Note: A DD in the first sequence field of the page when no other DDs are coded
deletes all lines on the current page from the EWF once Enter is pressed.

Chapter 11: Using the Edit Facility 347

CA 7 Text Editor Environment

Innn
Inserts nnn blank lines after the line where the I appears. nnn must be from 1 to
255. Leading zeros are not required. The number of blank lines (nnn) to be inserted
must be truncated by a blank, another subcommand (I, P, D, DD, or R), the EOF key
(erase to End of Field) or the end of the sequence field. These blank lines physically
exist in the EWF and can be altered by making changes in the data area of
subsequent displays. If not truncated, the sequence numbers remaining are
considered part of the lines to be inserted.
Rnnn
Repeats nnn lines after the line where the R appears. The line where the R appears
is repeated. nnn must be from 1 to 255 and must be truncated as in Innn.
Note: Errors in subcommands cause the subcommand to be ignored with no error
notification.

Editor Command Descriptions

The following details the commands available under the CA 7 text editor. (The short
form of the command is underlined.)
BOTTOM
Positions the FEM display to the bottom of the EWF. Available in FEM only.
BREAK [nn]
Changes the maximum number of lines to be displayed when the EWF is listed.
Value of nn can be from 00 to 99. The default is 99 lines. BREAK with no parameter
establishes the default. Available in FEM and AEM.
CLEAR
Deletes all lines in the edit work file (EWF). Lines of information added by the EDIT
commands, or those already present in the Active Area when the text editor was
entered, are deleted. Available in FEM and AEM.

348 Database Maintenance Guide

 CA 7 Text Editor Environment

COL [n,m]
Displays only columns n through m for data area changes. The column where the
asterisk appears on the scale line is the last affected column. The maximum number
of columns displayed is 72. COL specified with no parameters sets the default
columns of 1 through 72. Available in FEM only.
COPY i[,m,n,t]
Duplicates lines m through n and places them after line i, t number of times. When
n is omitted, line m through the last line are copied t number of times. Two commas
must separate the m and t values when n is omitted. When both m and n are
omitted, the last line of the edit work file (EWF) is copied t number of times and
three commas must precede the t. When t is omitted, a default of 1 is assumed.
Sequence numbers are assigned to the inserted lines using the current system
increment value (see INSERT). The first line copied or moved after the insert line (i)
is assigned a sequence number of i plus the current system increment value. All
subsequent inserted lines are renumbered using the system increment value. When
many new lines are inserted, existing lines following the insert point can be
renumbered (using the current system increment) to ensure that the EWF remains
in sequence. Available in FEM and AEM.
DELETE m[,n]
Removes lines from the EWF. When n is omitted, only line m is deleted. When both
m and n are specified, lines m through n are deleted. Available in AEM.
EDIT
Manipulates specified character strings of data, lines of data, or columns for reentry
into the EWF. The following EDIT commands are discussed separately. These are
only available in AEM.
EDIT LIST [m,n]
Enters Edit List mode. Lines displayed can be changed by keying the changes into
the EWF and pressing Enter. A line displayed on the panel can be deleted by keying
$EDEL in the first five characters, or by positioning the cursor at the first character
of the line and pressing the EOF key (erase to End-of-Field). Panels are returned
until either the end of the EWF is reached, line n is displayed, or $EEND is keyed on
the last line. ($EEND can be keyed on any line to exit Edit List mode. Any lines
displayed from the $EEND to the end of the current Edit List output page, however,
are deleted from the EWF.)

Chapter 11: Using the Edit Facility 349

CA 7 Text Editor Environment

EDIT /string/[m,n]
Searches the EWF for the string specified. Slash (/) can be any special character and
is used as the string delimiter. All lines found from m through n with the specified
string of characters are displayed at the terminal. When n is omitted, only line m is
scanned. When both m and n are omitted, the entire EWF is scanned. The
maximum number of characters for the string is 54.
EDIT /string1/string2/[m,n]
Replaces character string1 with character string2. All occurrences of string1 from
line m through n are replaced by string2. When n is omitted, only line m is scanned
for string1. When both m and n are omitted, the entire EWF is scanned. The
maximum number of characters for string1 and string2 is 54.
EDIT /string//[m,n]
Deletes a string of characters. All occurrences of the string from line m through n
are deleted. When n is omitted, only line m is scanned for the string. When both m
and n are omitted, the entire EWF is scanned. The maximum number of characters
for the string is 54.
EDIT //string//[m,n]
Replaces the contents of the edit columns with the string, regardless of the current
character content. For all lines m through n, the current edit columns are spaced
out and the string is left-justified into this area. When n is omitted, only line m is
changed. When both m and n are omitted, the entire EWF is changed. The
maximum number of characters for the string is 54.
EDIT x[,y]
Changes the start and end columns to be scanned by the other EDIT commands.
When y is omitted, x is the new end column. When x and y are both specified, x is
the new beginning column and y is the new end column. When y is specified, x must
always be less than or equal to y. The values of x and y must be from 1 to 80.
The following are examples of this command:
This example changes scan columns to be columns 73 through 80.
EDIT 73,80

This example fills columns 73 through 80 with SASSEDIT.

'E //SASSEDIT/'

This example resets scan columns.

E 1,72

350 Database Maintenance Guide

 CA 7 Text Editor Environment

EXIT
Returns to the original function that invoked the text editor. The contents of the
active area are not replaced by the edited EWF. This command is used to exit the
text editor without changing the contents of the active area. See SAVE for changing
the active area contents. Available in FEM and AEM.
FEM [n]
Used to enter Full Edit Mode (FEM). n is the sequence of the first line of information
to be positioned in the display. If n is omitted, the top of the EWF is assumed.
FILL
Indicates trailing spaces in the data area of the display are to be preserved. Data
area changes made by positioning to the end of displayed lines are not left-justified
to the first nonblank character on the line. Available in FEM only.
FIND /xxx...x/[n,m]
Searches for a given string of characters (xxx...x) and positions the display at the
next line containing those characters. The slash (/) characters are the string
delimiters and can be any special characters. Searching is always forward from the
current line. To initiate the search from the beginning of the display, first enter the
TOP command and then the FIND command. FIND always initiates the search for
the next occurrence of the character string. The n and m limits the search to
between lines n through m of the current command. If m is omitted, only line n is
searched if it follows the top line of the display. If n and m are omitted, the EWF is
searched forward from the current position. The string xxx...x is retained.
Subsequent FIND commands with no operands search forward for the last string of
characters specified by FIND. Available in FEM only. The following is an example of
this command.
The following example searches forward after the first line displayed for the next
line containing ABC. A subsequent FIND positions the display to the next line
containing ABC. If ABC is not found after searching forward, the display is
positioned at the top. A subsequent FIND then searches for ABC in any following
line. Available in FEM only.
FIND /ABC/0,99999

Chapter 11: Using the Edit Facility 351

CA 7 Text Editor Environment

HB [n]
Positions the display n half-pages backward. If omitted, n is assumed to be 1.
Available in FEM only.
HF [n]
Positions the display n half-pages forward. If omitted, n is assumed to be 1.
Available in FEM only.
INSERT [m,i]
Used to request Data Insert processing. The operator fills a page with input lines
and presses Enter. The lines are then added to the EWF and a new blank panel with
continued sequence numbers is presented for more input. To terminate Data Insert
processing, either key in $IEND after the last line to be inserted, or enter a null line
after the last line to be inserted.
When both m and i are specified, Data Insert mode processing adds lines beginning
with line m, incremented by i. When i is omitted, m changes the system increment
value for the INSERT, MOVE and COPY commands. The default of i is 10. If line m
exists in the EWF, Insert mode is established at line m + i (lines are inserted after
line m). Line m is not altered. If both m and i are omitted, Insert mode is established
at the end of the EWF. (In this case, a comma must be used to indicate the absence
of m and i, if sequence numbers are in 73-80.) The first inserted line has a sequence
number consisting of the last sequence number in the file plus the current edit
increment. The increment value specified here is reflected in the status
information. The INSERT command can be requested in either AEM or FEM. If
entered in FEM, control is passed to the editor in AEM for the duration of Data
Insert processing, and is returned to the editor in FEM when processing is complete.
Note: Mixed case support is available only in FEM. Hence, all data added during
Data Insert processing will be translated to uppercase.
JCL nnn[,yyddd,hhmm]
CA-Driver procedures are expanded, if used. Then CA WA CA 7 Edition scans the
EWF and reports syntax errors. The format of the report depends on whether the
default or the complete version of CA JCLCheck is used. After the report is
displayed, control is returned to the editor environment where the JCL
subcommand was invoked. Default values for schedule ID, date and time are used
in CA-Driver procedures and in #JI/#JO statements unless those values are
overridden. Use nnn to override the default SCHID (1). The default date (current
date) can be overridden using yyddd. Use hhmm to override the default time
(current time).

352 Database Maintenance Guide

 CA 7 Text Editor Environment

JCLL nnn[,yyddd,hhmm]
CA-Driver procedures are expanded, if used. Then CA WA CA 7 Edition scans the
EWF and lists the JCL statements along with any syntax errors detected. The format
of the report depends on whether the default or the complete version of CA
JCLCheck is used. After the report is displayed, control is returned to the editor
environment where the JCLL subcommand was invoked. Default values for schedule
ID, date and time are used in CA-Driver procedures and in #JI/#JO statements unless
those values are overridden. Use nnn to override the default SCHID (1). The default
date (current date) can be overridden using yyddd. Use hhmm to override the
default time (current time).
JCLS nnn[,yyddd,hhmm]
CA-Driver procedures are expanded, if used. Then CA WA CA 7 Edition scans the
EWF and reports syntax errors. The format of the report depends on whether the
default or the complete version of CA JCLCheck is used. A SAVE subcommand is
processed if no errors are detected and control is returned to the point where the
editor was invoked. If errors are detected then after the report is displayed, control
will return to the editor environment where the JCLS subcommand was issued.
Default values for schedule ID, date and time are used in CA-Driver procedures and
in #JI/#JO statements unless those values are overridden. Use nnn to override the
default SCHID (1). The default date (current date) can be overridden using yyddd.
Use hhmm to override the default time (current time).
JCLSR nnn[,yyddd,hhmm]
CA-Driver procedures are expanded, if used. Then CA WA CA 7 Edition scans the
EWF and reports syntax errors. The format of the report depends on whether the
default or the complete version of CA JCLCheck is used. An SR subcommand is
processed if no errors are detected and control is returned to the point where the
editor was invoked. If errors are detected then after the report is displayed, control
will return to the editor environment where the JCLSR subcommand was issued.
Default values for schedule ID, date and time are used in CA-Driver procedures and
in #JI/#JO statements unless those values are overridden. Use nnn to override the
default SCHID (1). The default date (current date) can be overridden using yyddd.
Use hhmm to override the default time (current time).
JCLSS nnn[,yyddd,hhmm]
CA-Driver procedures are expanded, if used. Then CA WA CA 7 Edition scans the
EWF and reports syntax errors. The format of the report depends on whether the
default or the complete version of CA JCLCheck is used. An SS subcommand is
processed if no errors are detected and control is returned to the point where the
editor was invoked. If errors are detected then after the report is displayed, control
will return to the editor environment where the JCLSS subcommand was issued.
Default values for schedule ID, date and time are used in CA-Driver procedures and
in #JI/#JO statements unless those values are overridden. Use nnn to override the
default SCHID (1). The default date (current date) can be overridden using yyddd.
Use hhmm to override the default time (current time).

Chapter 11: Using the Edit Facility 353

CA 7 Text Editor Environment

LIST [m,n]
Displays the contents of the EWF. When n is omitted, only line m is displayed. When
both m and n are specified, all lines from m through n are displayed within the
limits of the current BREAK value. When m and n are both omitted, the entire EWF
is listed within the limits of the current BREAK value. Available in AEM only.
MD [n]
Moves the display to the sequence number specified by n. If n is 0 or omitted, MD is
equivalent to the TOP command. If n is 99999, MD is equivalent to the BOTTOM
command. Available in FEM only.
MIXED
Changes the current case setting to mixed case. If the current case setting is
'MIXED' then characters will not be translated, thus allowing both uppercase and
lowercase characters to be entered. For more information about changing the case
setting, see the discussion of the UPPER command in this section.
MIXED is always the default setting for CA7TOUNI jobs and for all internal
cross-platform jobs, regardless of any options set and data contained in the file.
With CPU jobs, other than CA7TOUNI jobs, the following applies:
The initial case setting is 'UPPER' unless lowercase characters are detected. If
lowercase characters are detected and INITCASE=Y is specified on the OPTIONS
statement in the CA WA CA 7 Edition initialization file, the initial case setting is
'MIXED'.
This subcommand is not valid unless INITCASE=Y is specified on the OPTIONS
statement in the CA WA CA 7 Edition initialization file.
MOVE i[,m,n,t]
Places lines m through n after line i, t number of times. When n is omitted, m is the
only line moved. When both m and n are omitted, the last line of the EWF is moved.
When t is omitted, a default of 1 is assumed. Sequence numbers are assigned to the
inserted lines using the current system increment value (see INSERT). The first line
copied or moved after the insert line i is assigned a sequence number of i plus the
current system increment value. All subsequent inserted lines are renumbered
using the system increment value. When many new lines are inserted, existing lines
following the insert point can be renumbered (using the current system increment)
to ensure that the EWF remains in sequence. Available in AEM and FEM.
Note: When m or n are omitted, commas must be specified to denote the omission
of these positional parameters.
NOFILL
Indicates that trailing spaces in the data area of the display are not preserved. Data
area changes made by positioning to the end of displayed lines are left-justified to
the first nonblank character of the line. Spaces must be inserted to hold position.
Available in FEM only.

354 Database Maintenance Guide

 CA 7 Text Editor Environment

NONUM
Indicates that sequence numbers are external to the data. (Same as the XSEQ.)
Available in FEM only.
NUM
Indicates that sequence numbers are to be found in lines 76 through 80 of the data.
(Same as XSEQ OFF.) Available in FEM only.
PB [n]
Positions the display n pages backward. If omitted, n is assumed to be 1. Available
in FEM only.
PF [n]
Positions the display n pages forward. If omitted, n is assumed to be 1. Available in
FEM only.
RENUM m,i
Renumbers the entire EWF. Both m and i are required. m is the number to be
assigned to the first line of the EWF. i is the increment for each succeeding line
number. Available in FEM and AEM.
RETURN
Used to enter the Alternate Edit Mode from FEM.
SAVE
Used to return to the original function that invoked the text editor. The contents of
the active area are replaced by the current EWF. This command is used to exit the
text editor with the edited EWF replacing the active area. Available in FEM and
AEM.
SCALE [OFF]
Indicates whether a column indicator heading is to be displayed on each output
page. SCALE OFF turns off Scale mode. SCALE with no operand displays the column
scale. Available in AEM only.
SR
Performs two functions, SAVE and REPL. The current EWF replaces the active area,
control returns to the panel that was used to enter the text editor, and a REPL
function is performed. Available in FEM and AEM.
Note: If JCL or PARM data is being replaced in the request queue, the SR command
also sets an outstanding JCL or PARM data override requirement off.
SS
Performs two functions, SAVE and SAVE. The current EWF replaces the active area,
control returns to the panel used to enter the text editor, and a SAVE function is
performed. Available in FEM and AEM.

Chapter 11: Using the Edit Facility 355

CA 7 Text Editor Environment

STATUS
Displays current information about the EWF. This information consists of the
number of lines in the EWF, last line number, edit scan columns, and so on. Press
Enter to redisplay the EDIT panel after a STATUS command. Available in FEM and
AEM.
TOP
Positions the display to the top of the EWF. Available in FEM only.
TRACE [EDIT] | [OFF]
Sets on (TRACE EDIT) or sets off (TRACE OFF) the tracing of lines altered by the
editor commands. With TRACE on, each line changed by the EDIT command is
displayed. (BREAK does not apply.) Available in FEM and AEM.
UPPER
Changes the current case setting to uppercase. If the current case setting is 'UPPER'
then all characters will be translated to uppercase.
The initial case setting is 'UPPER' unless lowercase characters are detected. If
lowercase characters are detected and INITCASE=Y is specified on the OPTIONS
statement in the CA WA CA 7 Edition initialization file then the initial case setting is
'MIXED'.
Note: For CA7TOUNI CPU jobs and for all internal cross-platform jobs, the initial
setting is always MIXED. You can specify UPPER if you want to have all data
translated to uppercase characters.
XSEQ [OFF]
Establishes External Sequence mode. XSEQ alone indicates that the sequence
numbers are to be external to the 1- to 80-character line image. XSEQ OFF indicates
that columns 76 through 80 of the line image are to be the sequence number field.
When an active area is saved and XSEQ is in effect, the contents of columns 76
through 80 are the same values present when the text editor was entered. When
XSEQ OFF is in effect and an active area is saved, the current line number for each
line replaces columns 76 through 80 of the line. Available in FEM and AEM.

356 Database Maintenance Guide

 CA 7 Text Editor Environment

FEM Sample Panels

The following are FEM sample panels. Each panel displays the use of subcommands in
the sequence field areas or changes made to the data area.

The following panel shows five of the six areas discussed previously. The last area of the
panel, the message line, is blank.

FEM Sample Panel 1

----+----10---+----20---+----30---+----40---+----50---+----60---+----70*
PF NOFILL I(010)
00010 //DUSAXX01 JOB HE67YFSH,ACPAY,REGION=40K,TIME=0003,CLASS=A
00020 /*ROUTE PRINT RMT1
00030 //STEP1 EXEC PGM=IEBGENER
00040 #JI,ID=1
00050 #MSG,*******************************************************************
00060 #MSG,* NETWORK RUN AS SCHID OF 1 *
00070 #MSG,*******************************************************************
00080 #JI,ID=2
00090 #MSG,*******************************************************************
00100 #MSG,* NETWORK RUN AS SCHID OF 2 *
00110 #MSG,*******************************************************************
00120 #JI,ID=3
00130 #MSG,*******************************************************************
00140 #MSG,* NETWORK RUN AS SCHID OF 3 *
00150 #MSG,*******************************************************************
00160 #JI,ID=4
00170 #MSG,*******************************************************************
00180 #MSG,* NETWORK RUN AS SCHID OF 4 *
00190 #MSG,*******************************************************************
00200 #JEND
----+----10---+----20---+----30---+----40---+----50---+----60---+----70*

Chapter 11: Using the Edit Facility 357

CA 7 Text Editor Environment

The following panel reflects a data area change on line 60 of FEM Sample Panel 1. Make
changes by keying over existing line data and then pressing Enter.

FEM Sample Panel 2

----+----10---+----20---+----30---+----40---+----50---+----60---+----70*
PF NOFILL I(010)
00010 //DUSAXX01 JOB HE67YFSH,ACPAY,REGION=40K,TIME=0003,CLASS=A
00020 /*ROUTE PRINT RMT1
00030 //STEP1 EXEC PGM=IEBGENER
00040 #JI,ID=1
00050 #MSG,*******************************************************************
00060 #MSG,* THIS IS A CHANGE EXAMPLE *
00070 #MSG,*******************************************************************
00080 #JI,ID=2
00090 #MSG,*******************************************************************
00100 #MSG,* NETWORK RUN AS SCHID OF 2 *
00110 #MSG,*******************************************************************
00120 #JI,ID=3
00130 #MSG,*******************************************************************
00140 #MSG,* NETWORK RUN AS SCHID OF 3 *
00150 #MSG,*******************************************************************
00160 #JI,ID=4
00170 #MSG,*******************************************************************
00180 #MSG,* NETWORK RUN AS SCHID OF 4 *
00190 #MSG,*******************************************************************
00200 #JEND
----+----10---+----20---+----30---+----40---+----50---+----60---+----70*

358 Database Maintenance Guide

 CA 7 Text Editor Environment

The following panel reflects the request for deletion of three lines from the EWF. You
can place a D in any position of the sequence field to delete the line.

Note: For the results of this edit, see FEM Sample Panel 4.

FEM Sample Panel 3

----+----10---+----20---+----30---+----40---+----50---+----60---+----70*
PF NOFILL I(010)
00010 //DUSAXX01 JOB HE67YFSH,ACPAY,REGION=40K,TIME=0003,CLASS=A
00020 /*ROUTE PRINT RMT1
00030 //STEP1 EXEC PGM=IEBGENER
00040 #JI,ID=1
00050 #MSG,*******************************************************************
00060 #MSG,* THIS IS A CHANGE EXAMPLE *
00070 #MSG,*******************************************************************
D0080 #JI,ID=2
00090 #MSG,*******************************************************************
00100 #MSG,* NETWORK RUN AS SCHID OF 2 *
00110 #MSG,*******************************************************************
0012D #JI,ID=3
00130 #MSG,*******************************************************************
00140 #MSG,* NETWORK RUN AS SCHID OF 3 *
00150 #MSG,*******************************************************************
00D60 #JI,ID=4
00170 #MSG,*******************************************************************
00180 #MSG,* NETWORK RUN AS SCHID OF 4 *
00190 #MSG,*******************************************************************
00200 #JEND
----+----10---+----20---+----30---+----40---+----50---+----60---+----70*

Chapter 11: Using the Edit Facility 359

CA 7 Text Editor Environment

The following panel reflects the results of the edit performed in FEM Sample Panel 3
deleting three lines: 00080, 00120, and 00160.

Now a P is placed in the sequence field on line 100.

Note: For the results, see FEM Sample Panel 5.

FEM Sample Panel 4

----+----10---+----20---+----30---+----40---+----50---+----60---+----70*
PF NOFILL I(010)
00010 //DUSAXX01 JOB HE67YFSH,ACPAY,REGION=40K,TIME=0003,CLASS=A
00020 /*ROUTE PRINT RMT1
00030 //STEP1 EXEC PGM=IEBGENER
00040 #JI,ID=1
00050 #MSG,*******************************************************************
00060 #MSG,* THIS IS A CHANGE EXAMPLE *
00070 #MSG,*******************************************************************
00090 #MSG,*******************************************************************
P0100 #MSG,* NETWORK RUN AS SCHID OF 2
00110 #MSG,*******************************************************************
00130 #MSG,*******************************************************************
00140 #MSG,* NETWORK RUN AS SCHID OF 3 *
00150 #MSG,*******************************************************************
00170 #MSG,*******************************************************************
00180 #MSG,* NETWORK RUN AS SCHID OF 4 *
00190 #MSG,*******************************************************************
00200 #JEND
----+----10---+----20---+----30---+----40---+----50---+----60---+----70*

360 Database Maintenance Guide

 CA 7 Text Editor Environment

The following panel reflects the result of the P subcommand to position the display from
FEM Sample Panel 4 to line 100.

Now an I3 is placed in sequence line 200.

Note: For the results, see FEM Sample Panel 6.

FEM Sample Panel 5

----+----10---+----20---+----30---+----40---+----50---+----60---+----70*
PF NOFILL I(010)
00100 #MSG,* NETWORK RUN AS SCHID OF 2 *
00110 #MSG,*******************************************************************
00130 #MSG,*******************************************************************
00140 #MSG,* NETWORK RUN AS SCHID OF 3 *
00150 #MSG,*******************************************************************
00170 #MSG,*******************************************************************
00180 #MSG,* NETWORK RUN AS SCHID OF 4 *
00190 #MSG,*******************************************************************
I3 00 #JEND
00210 //SYSIN DD DUMMY
00220 //SYSPRINT DD SYSOUT=A
00230 //SYSUT2 DD DSN=CA7.TEST1,
00240 // DISP=(NEW,CATLG,DELETE),UNIT=DISKA,VOL=SER=LIB112,SPACE=(TRK,1),
00250 // DCB=(RECFM=F,LRECL=80,BLKSIZE=80)
00260 //SYSUT1 DD *,DCB=BLKSIZE=80
00270 /*
00280 //STEP2 EXEC PGM=SASSTRLR,PARM=ACT
00290 //STEPLIB DD DSN=user-defined-CA-7-loadlib,DISP=SHR
00300 //SYSPRINT DD SYSOUT=A
00310 //SYSOUT DD SYSOUT=A,DCB=BLKSIZE=133
----+----10---+----20---+----30---+----40---+----50---+----60---+----70*

Chapter 11: Using the Edit Facility 361

CA 7 Text Editor Environment

The following panel reflects the result of the I subcommand to insert three blank lines
after line 200. An I3 (I3space) was entered in the sequence field of line 200. The inserted
lines were incremented by 10, the line increment value on the status line. The previous
line 210 has been renumbered to 240. All subsequent lines are renumbered as
necessary to retain ascending sequence numbers in the EWF.

Now a DD is placed in sequence lines 150 and 200. For the results, see FEM Sample
Panel 7.

FEM Sample Panel 6

----+----10---+----20---+----30---+----40---+----50---+----60---+----70*
PF NOFILL I(010)
00100 #MSG,* NETWORK RUN AS SCHID OF 2 *
00110 #MSG,*******************************************************************
00130 #MSG,*******************************************************************
00140 #MSG,* NETWORK RUN AS SCHID OF 3 *
DD150 #MSG,***********************************************************
00170 #MSG,*******************************************************************
00180 #MSG,* NETWORK RUN AS SCHID OF 4 *
00190 #MSG,*******************************************************************
DD200 #JEND
00210
00220
00230
00240 //SYSIN DD DUMMY
00250 //SYSPRINT DD SYSOUT=A
00260 //SYSUT2 DD DSN=CA7.TEST1,
00270 // DISP=(NEW,CATLG,DELETE),UNIT=DISKA,VOL=SER=LIB112,SPACE=(TRK,1),
00280 // DCB=(RECFM=F,LRECL=80,BLKSIZE=80)
00290 //SYSUT1 DD *,DCB=BLKSIZE=80
00300 /*
00310 //STEP2 EXEC PGM=SASSTRLR,PARM=ACT
----+----10---+----20---+----30---+----40---+----50---+----60---+----70*

362 Database Maintenance Guide

 CA 7 Text Editor Environment

The following panel reflects the result of the DD subcommand to delete multiple lines
from the EWF. A DD was placed in the sequence field of lines 150 and 200 of FEM
Sample Panel 6. Lines 150 through 200 are deleted from the EWF.

FEM Sample Panel 7

----+----10---+----20---+----30---+----40---+----50---+----60---+----70*
PF NOFILL I(010)
00100 #MSG,* NETWORK RUN AS SCHID OF 2 *
00110 #MSG,*******************************************************************
00130 #MSG,*******************************************************************
00140 #MSG,* NETWORK RUN AS SCHID OF 3 *
00210
00220
00230
00240 //SYSIN DD DUMMY
00250 //SYSPRINT DD SYSOUT=A
00260 //SYSUT2 DD DSN=CA7.TEST1,
00270 // DISP=(NEW,CATLG,DELETE),UNIT=DISKA,VOL=SER=LIB112,SPACE=(TRK,1),
00280 // DCB=(RECFM=F,LRECL=80,BLKSIZE=80)
00290 //SYSUT1 DD *,DCB=BLKSIZE=80
00300 /*
00310 //STEP2 EXEC PGM=SASSTRLR,PARM=ACT
00320 //STEPLIB DD DSN=user-defined-CA-7-loadlib,DISP=SHR
00330 //SYSPRINT DD SYSOUT=A
00340 //SYSOUT DD SYSOUT=A,DCB=BLKSIZE=133
00350 //SYSIN DD *,DCB=BLKSIZE=80
00360 /LOGON MASTER
----+----10---+----20---+----30---+----40---+----50---+----60---+----70*

The following panel reflects multiple subcommands entered on the panel.

FEM Sample Panel 8

----+----10---+----20---+----30---+----40---+----50---+----60---+----70*
PF NOFILL I(010)
00100 #MSG,* NETWORK RUN AS SCHID OF 2 *
00110 #MSG,*******************************************************************
00130 #MSG,*******************************************************************
00140 #MSG,* NETWORK RUN AS SCHID OF 3 *
00210
00220
00230
00240 //SYSIN DD DUMMY
00250 //SYSPRINT DD SYSOUT=A
P0260 //SYSUT2 DD DSN=CA7.TEST1,
00270 // DISP=(NEW,CATLG,DELETE),UNIT=DISKA,VOL=SER=LIB112,SPACE=(TRK,1),
00280 // DCB=(RECFM=F,LRECL=80,BLKSIZE=80)
D0290 //SYSUT1 DD *,DCB=BLKSIZE=80
00300 /*
DD310 //STEP2 EXEC PGM=SASSTRLR,PARM=ACT
00320 //STEPLIB DD DSN=user-defined-CA-7-loadlib,DISP=SHR
DD330 //SYSPRINT DD SYSOUT=A
00340 //SYSOUT DD SYSOUT=A,DCB=BLKSIZE=133
I2 50 //SYSIN DD *,DCB=BLKSIZE=80
00360 /LOGON MASTER
----+----10---+----20---+----30---+----40---+----50---+----60---+----70*

Chapter 11: Using the Edit Facility 363

CA 7 Text Editor Environment

The following panel reflects the results of multiple subcommands entered on the panel
displayed in FEM Sample Panel 8. A P was placed in sequence number 260. A D was
placed in sequence 290. A DD was entered in sequence numbers 310 and 330. An I2 and
one blank were placed in sequence 350.

FEM Sample Panel 9

----+----10---+----20---+----30---+----40---+----50---+----60---+----70*
PF NOFILL I(010)
00260 //SYSUT2 DD DSN=CA7.TEST1,
00270 // DISP=(NEW,CATLG,DELETE),UNIT=DISKA,VOL=SER=LIB112,SPACE=(TRK,1),
00280 // DCB=(RECFM=F,LRECL=80,BLKSIZE=80)
00300 /*
00340 //SYSOUT DD SYSOUT=A,DCB=BLKSIZE=133
00350 //SYSIN DD *,DCB=BLKSIZE=80
00360
00370
00380 /LOGON MASTER
00390 DEMAND,JOB=DUSAXX02,LEADTM=100
00400 //STEP3 EXEC PGM=IEBGENER
00410 //SYSPRINT DD SYSOUT=A
00420 //SYSIN DD DUMMY
00430 //SYSUT2 DD DSN=CA7.TEST2,
00440 // DISP=(NEW,CATLG,DELETE),UNIT=DISKA,VOL=SER=LIB112,SPACE=(TRK,1),
00450 // DCB=(RECFM=F,LRECL=80,BLKSIZE=80)
00460 //SYSUT1 DD *,DCB=BLKSIZE=80
00470 CONTROL CARD
00480 /*

----+----10---+----20---+----30---+----40---+----50---+----60---+----70*

364 Database Maintenance Guide

 CA 7 Text Editor Environment

Updating Text
The most common editing activity is to make changes to existing text. The following is a
step-by-step example for this activity using the CA 7 text editor. In the example, the
primary panel is the DB.7 panel, but the same steps apply to other panels, such as DB.4
and QM.5.

See the figure at the beginning of this section.

To update text, proceed as follows:

1. Display the primary panel, in this case, DB.7.
2. Type FE in the function field, and then enter the required fields to identify the
source of the text to be edited, such as MEMBER and DSN or JCL-ID, and press
Enter.
3. Use the editor subcommands to make wanted changes to the text.
4. Enter the SAVE or SR subcommand to retain the changes and return to the DB.7
panel. If SAVE is used to leave the editor, another function is required on the DB.7
panel to move the updated text to a permanent file. IF SR is used to leave the
editor, the source file identified in Step 2 is updated. If the text updates are not to
be saved, leave the editor using the EXIT subcommand.

Creating Text
Another common editing activity is to create text from scratch. The following example is
a step-by-step example for this activity using the CA 7 text editor. In the example, the
primary panel is the DB.4 panel, but the same steps apply to other panels, such as DB.7
and QM.5.

See the figure at the beginning of this section.

To create text, proceed as follows:

1. Display the primary panel, in this case, DB.4.
2. Since this panel is a menu panel, a secondary entry is required, such as 1 for job
level documentation.
3. Once on the DB.4.1 panel, enter CLEAR in the function field to initialize the active
area. (If the active size is 0, this step can be bypassed.)

Chapter 11: Using the Edit Facility 365

CA 7 Text Editor Environment

4. Next enter EDIT in the function field to transfer to the editor. The edit panel that is
returned indicates EWF EMPTY.
5. Enter I or INSERT that invokes Data Insert processing.
6. Enter text as wanted. Lines are double spaced with sequence numbers protected. If
text is entered on all displayed numbered lines, another panel of blank lines is
presented for continued entry. After all input is complete, leave at least one blank
line on the panel and press Enter to return to FEM.
7. If any changes are needed to the newly created text, use the editor subcommands
to manipulate the data.
8. Enter the SAVE subcommand to retain the text and return to the DB.4.1 panel.
9. Type SAVE in the function field and the job name in the JOB field. Data can be
entered in the other fields too. Press Enter to add the text to the database.
Note: If you are entering no data in the other fields, use SS in Step 8. SS performs
steps 8 and 9 with one command.

Special Considerations
This topic explains special considerations for using PF/PA keys, character translation,
and nondisplayable data (hex).

PF/PA Key Usage

While in the CA 7 text editor, PF and PA keys should not be used. These keys can be
equated to top line commands not valid in the editor, and their use can cause
unpredictable results. Even if the equated command works, all edit data is lost because
the EWF is not saved to the Active Area.

Character Translation

CA WA CA 7 Edition translates all online character data to uppercase unless the text
editor is used in Full Edit Mode. If you use FEM, character data is translated or not
depending on the case setting. If the case setting is UPPER, all character data are
translated to uppercase. If the case setting is MIXED, characters on data lines are left
untranslated. The FEM subcommands MIXED and UPPER can be used to change the case
setting. The status line reports the current case setting.

On entry to the CA 7 editor in Full Edit Mode (FEM) for CA7TOUNI CPU jobs and for all
internal cross-platform jobs, the default case setting is always MIXED, regardless of the
options set or the data contained in the text being edited. You can change this setting to
'UPPER' if you want only uppercase data.

On entry to the CA 7 editor in Full Edit Mode, the case setting is UPPER unless lowercase
characters are detected. In that event, the initial case setting is MIXED.

366 Database Maintenance Guide

 TSO/ISPF Editor Environment

If the case setting is changed to UPPER,all character data in the editor is translated to
uppercase when it is saved to the active area. If data is not saved, the case setting only
affects the current data display.

The case setting cannot be changed unless INITCASE=Y is specified on the OPTIONS
statement in the initialization file. If this value is not specified, the case setting is always
set to UPPER and cannot be changed.

When data is stored in the database or queue files, it is compressed using control codes
for repeated characters.

Nondisplayable Data (hex)

Nondisplayable data that is contained in text that is edited using the CA 7 text editor can
cause unpredictable panel output or a terminal disconnect. Avoid editing files
containing such data.

TSO/ISPF Editor Environment

The CA WA CA 7 Edition TSO/ISPF Interface allows for the fully integrated use of the ISPF
editor where text editing is required. Some of the previously described features are
available in the ISPF environment too. Some important differences exist, and these
differences are noted in this subtopic.

This subtopic explains the use of the ISPF editor only as supported under the CA WA CA
7 Edition TSO/ISPF Interface.

In the following explanations, two types of CA WA CA 7 Edition online terminal sessions

are compared and contrasted:
■ A directly connected CA WA CA 7 Edition terminal session
■ An ISPF connected CA WA CA 7 Edition terminal session

A CA WA CA 7 Edition online terminal session that is acquired outside of ISPF is

considered directly connected. A CA WA CA 7 Edition terminal session that is acquired
from an ISPF session is considered an ISPF connected session.

Regardless of how the terminal session is connected, the file that is edited in CA WA CA
7 Edition is always an EWF or Editor Work File. The format of the EWF differs depending
on the type of terminal session where the editing occurs.

When the editing takes place in a directly connected session (in a session where the
TSO/ISPF interface is not being used), the EWF is a file internal to CA WA CA 7 Edition.
CA WA CA 7 Edition handles the manipulation of data on the file entirely in its address
space in response to CA 7 editor commands that the user entered.

Chapter 11: Using the Edit Facility 367

TSO/ISPF Editor Environment

In an ISPF connected session (in a CA WA CA 7 Edition terminal session acquired under

ISPF), the EWF is a temporary data set that is dynamically allocated and is maintained by
programs running under the ISPF session. All data manipulation takes place in the TSO
user's address space using the ISPF editor.

In the TSO user's address space, the ISPF editor is used strictly for data manipulation.
The primary source or target file (for example, a JCL library) is never updated by the ISPF
session. All updates are handled by CA WA CA 7 Edition from the CA WA CA 7 Edition
address space. The previous discussion detailing the flow of data between primary
source/target, active area and EWF is valid not only for editing from a directly connected
session but also from an ISPF connected session.

Requesting Edit Functions from the ISPF Editor

Several CA WA CA 7 Edition functions can be requested from the editor panels that
cause termination of the edit session. These functions differ in the data movement that
takes place when the function is requested. In a directly connected CA WA CA 7 Edition
terminal session, the following subcommands are used to request these functions:
SAVE
Terminates the edit session and saves the contents of the EWF to the active area.
EXIT
Terminates the edit session without saving the contents of the EWF.
SS
Terminates the edit session, saves the contents of the EWF in the active area, and
saves the contents of the active area to the primary source.
SR
Terminates the edit session, saves the contents of the EWF in the active area, and
replaces the primary source with the contents of the active area.

368 Database Maintenance Guide

 TSO/ISPF Editor Environment

SS and SR processing differs from the descriptions offered above if queue JCL is being
edited.

All primary source/target updates are handled by CA WA CA 7 Edition; therefore, some

means must be provided to allow the user to indicate to the interface programs from
the editor, what CA WA CA 7 Edition is to do with the data in the EWF when the edit
session is terminated. In an ISPF connected CA WA CA 7 Edition terminal session, the
following ISPF edit macros can be used to request the CA WA CA 7 Edition edit functions
described previously:
CA7SAVE
Terminates the edit session. Sends EWF to CA WA CA 7 Edition and requests SAVE
processing. Deletes the temporary data set (EWF).
CA7EXIT
Terminates the edit session. Sends EXIT request to CA WA CA 7 Edition. Deletes the
temporary data set (EWF).
CA7SS
Terminates the edit session. Sends EWF to CA WA CA 7 Edition and requests SS
processing. Deletes the temporary data set (EWF).
CA7SR
Terminates the edit session. Sends EWF to CA WA CA 7 Edition and requests SR
processing. Deletes the temporary data set (EWF).

These are standard ISPF edit macros, provided as CLISTs. When one of these CLISTs is
invoked, the value of an internal variable is set. The interface programs retrieve the
value of the variable and request the appropriate CA WA CA 7 Edition edit function (for
example, SAVE, SS, SR, or EXIT).

Default Requests for CA WA CA 7 Edition Edit Functions

In an ISPF connected CA WA CA 7 Edition terminal session, a CA 7 editor function is
always requested when the editor is exited. This function can be requested either
explicitly, as in the case of one of the edit macros. Also, the function can be requested
by default if the editor is exited in any other way. For example, PF03 is set to END and
PF03 is pressed.

The CA 7 edit action that is requested by default is named in a message that appears
when the editor is entered.

IF DATA IS SAVED, THEN A CA-7 xxxx WILL BE PERFORMED

Chapter 11: Using the Edit Facility 369

TSO/ISPF Editor Environment

xxxx can be either EXIT, SAVE, SS, or SR. The default action is set to SR initially. The
default setting can be changed for subsequent edit sessions by issuing an edit macro.
For example, if the default that appears in the message is SR, and if the CA7SS edit
macro is used to terminate an edit session, on the next session, the default setting that
appears in the message is SS. This is the action that CA WA CA 7 Edition performs if the
edit session is terminated and data is saved. If data is not saved, CA7EXIT is requested
by default. For example, suppose that the following message appears when the editor is
entered for a member on a JCL library:

IF DATA IS SAVED, THEN A CA-7 SR WILL BE PERFORMED

Also suppose that an ISPF SAVE command is issued during the edit session. If the edit
session is terminated without issuing a CA WA CA 7 Edition edit macro, a CA WA CA 7
Edition SR is requested. In this case, if the user did not want the data to replace the JCL
member, a CA7EXIT would be required. An ISPF CANCEL would not suffice to prevent
the SR from being issued, because an ISPF SAVE command was entered. The only way to
avoid an implicit request for the default action is to enter the appropriate CA WA CA 7
Edition edit macro. AUTOSAVE ON is a common edit profile setting and in many cases
data can be saved automatically if data is changed. It is very important to be aware of
the default CA WA CA 7 Edition edit function that can be issued when leaving the edit
session.

In the following example, text for an existing member of a JCL PDS is updated.
1. Request the JCL panel by typing DB.7 on the top line.
2. Enter FE in the field marked FUNCTION. Enter the member name in the field
marked MEMBER. Enter all other information necessary to locate the member
(JCLID or DSN, and so forth), and press Enter.
3. The ISPF editor is invoked and data from the active area appears. Use ISPF editor
commands to make wanted changes.
4. Enter CA7SR from the command line to save the changes. To exit the editor without
saving any changes, enter CA7EXIT from the command line. If the default CA WA CA
7 Edition edit function is acceptable and if data was changed and if AUTOSAVE ON is
set in the edit profile, simply exit the editor using the ISPF END command (through
a PF KEY if wanted).

Special Considerations
This topic explains special considerations for using ISPF edit profile settings, PF/PA keys,
the SUBMIT function, and the size of data.

370 Database Maintenance Guide

 TSO/ISPF Editor Environment

ISPF Edit Profile Settings

In an ISPF connected CA WA CA 7 Edition terminal session, the EWF is a temporary data

set that is acquired only when needed by the interface programs and is deleted when
the user exits the editor. It is a temporary data set and it is not retained in the event of
abnormal termination, thus the recovery mode setting in the ISPF edit profile is of little
benefit.

Although the ISPF editor command to set CAPS OFF is valid in an ISPF connected session,
such a setting is effectively ignored because CA WA CA 7 Edition is handling all output to
the primary source/target. When the EWF is received, CA WA CA 7 Edition translates all
lowercase characters to uppercase prior to update of the active area.

Note: Edit facilities are restricted to character data whether the terminal session is
directly connected or ISPF connected. Even though in an ISPF connected session HEX ON
can be used to create unprintable hex data, this is strongly discouraged because the
response of CA WA CA 7 Edition to such data is unpredictable.

PF/PA Key Usage

Although both CA WA CA 7 Edition and ISPF allow command input through a PF key, in
the ISPF editor all PF keys are used for ISPF command input only.

Note: For more information about PF keys in an ISPF connected CA WA CA 7 Edition

terminal session., see the Systems Programming Guide.

The use of PA keys is strictly subject to ISPF restrictions. PA key interrupts are not
supported in an ISPF connected terminal session.

SUBMIT Function

If JCL is submitted using the ISPF SUBMIT function, CA WA CA 7 Edition does not track
the job. We recommend that the SUBMIT function be deactivated through an ISPF
command table for the CA7 application.

Note: For more information about command table modifications for the CA7
application, see the Systems Programming Guide.

Size of Data

The maximum number of lines (or records) that can be edited using the ISPF interface is
approximately 5000.

Chapter 11: Using the Edit Facility 371

Chapter 12: Internal Cross-Platform
Three formatted panels permit entry of data used explicitly by internal cross-platform
jobs during the submission process. The first two panels are for XPJOBs, and the third
panel is for agent jobs. Although the panels are not accessed through any menus, you
can use the panels' IDs (XN.n where n is 1, 2, or 3) as top line commands or enter them
through the DBM panel field FUNCTION. The command aliases for these panels are
XNODE, XPSWD, and AGPSWD.

This section contains the following topics:

XN.1 - XNODE Command (see page 373)
XN.2 - XPSWD Command (see page 376)
XN.3 - AGPSWD Command (see page 381)

XN.1 - XNODE Command

The XN.1 or XNODE command lets you define permanent nodes used by XPJOB jobs.

The CAICCI nodes to which internally submitted XPJOB jobs are routed for execution are
managed through an in-storage table. This table is initially built from the NODE records,
stored in the database. The database node records contain the node names (primary,
alternates 1 and 2), and the time of last command update if applicable. These nodes are
classified as permanent nodes. The data associated with nodes in the in-storage table
also includes the time of last transmission to the node or its alternates, and the number
of jobs transmitted since the last time CA WA CA 7 Edition Online was started.

If a node is not in the CA WA CA 7 Edition database but the node is in the in-storage
copy of the node table, it is classified as a temporary node. These node entries are
added dynamically if CA WA CA 7 Edition sends a job to a node that is not previously
defined. These temporary nodes can be added to the database if an XNODE ADD
function is executed.

To display the panel, enter:

■ XN.1 as the function on a DBM panel or the top line command.
■ XNODE as the function on a DBM panel or the top line command.

To exit the panel:

■ Press PF3 to return to the DB Menu panel except with the TSO/ISPF interface when
PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter a top line command for
another function.

Chapter 12: Internal Cross-Platform 373

XN.1 - XNODE Command

------------------------- CA-7 XPS Node Table Entry -------------------------

Function: xxxxxxxx (Add, Delete, Format, List, Update)

Node: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Description: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Alternate 1: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Alternate 2: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

State: xxxxxxx (Online, Offline, Stop)

PROGRAM: SMX1 MSG-INDX: nn -- XN.1 -- yy.ddd / hh:mm:ss

MESSAGE: Enter function, transfer or enter a command on the top line

Function
Specifies the function to perform. Value must be the name of some other panel or
one of the following:
ADD
Adds a new primary node definition to the active node table and to the
database. The ADD function does not perform updates against any existing
permanent node definition. Use the UPDATE function instead. It can be used to
make a temporary node entry a permanent node entry (thus adding it to the
database).
DELETE
Deletes an entry in the active node table and the database. This removes the
primary node entry.
FORMAT
Clears all fields on the XNODE panel.
LIST
Lists an entry in the active node table at the time of the command.
UPDATE
Updates the alternate node definitions, status information, or both.
Batch keyword: Positional parameter

374 Database Maintenance Guide

 XN.1 - XNODE Command

Node
Defines the primary node (the key) in the function being performed. This keyword is
required for all functions.
Limits: 1 to 44 alphanumeric characters. Although 44 characters are permitted in
this field, currently CA Common Services CAICCI only permits 8-character node
names.
Batch keyword: Positional parameter
Description
(Optional) Provides a 64-byte field for sites to describe the node. This field can
indicate anything a user wants and is not used in any CA WA CA 7 Edition data.
Suggestions for this field include the operating system (for example, UNIX,
Windows), location (for example, New York, Dallas), and other data relevant to the
platform.
Limits: 1 to 64 alphanumeric characters
Batch keyword: DES
Alternate 1|Alternate 2
(Optional) Names the alternate CAICCI nodes to use if the primary node is
unavailable. ALT1 must be specified before an ALT2 is used. Users may see an error
message if ALT2 is specified when the primary node does not have an ALT1 defined.
Even though a CAICCI node can be assigned as an alternate, that same CAICCI node
can also be used in a primary definition. CA WA CA 7 Edition only uses the primary
node's alternates if the primary node is unavailable at the time the job is submitted.
For example, NODE-A is defined with NODE-Z as its alternate. NODE-Z also has a
primary node definition, with NODE-G as its alternate. A job that is destined for
NODE-A when NODE-A is not available is routed to NODE-Z if possible. If NODE-Z is
unavailable, the job waits in the request queue until NODE-A or NODE-Z becomes
available. The job is only routed to NODE-G when NODE-G is added as an alternate
to NODE-A.
Limits: 1 to 44 alphanumeric characters
Batch Keyword: ALT1 or ALT2

Chapter 12: Internal Cross-Platform 375

XN.2 - XPSWD Command

State
(Optional) Changes the status of the node from online (active) to offline (inactive)
or stop. Offline states that only this node should not be used to send any data;
alternate nodes can be used. Stop status indicates that the primary and its alternate
nodes should not be used at all; no data sends occur to the primary or alternate
nodes.
If it is known that the node is unavailable for a maintenance window or extended
time, the operator can enter this command as the maintenance window begins.
This prevents CA WA CA 7 Edition from issuing messages if it detects the node is
offline when a job is submitted for that node.
Note: The status can appear as FAIL if the CAICCI connection is determined by CA
WA CA 7 Edition not to be active at the time of an XPJOB submission.
Limits: 1 to 7 characters
Batch Keyword: STATE

XN.2 - XPSWD Command

The XN.2 or XPSWD command displays a formatted panel to permit entry of
security-related data for XPJOB jobs. The panel is a secured panel, which means that
access to the panel and the information about it is controlled.

Note: For more information, see the Security Reference Guide.

If the XPDEF file initialization statement XSUBMIT keyword is set to N, the panel is
disabled for all users.

The XPSWD panel allows the definition of the user ID and optionally, the password and
Windows Domain name that an XPJOB job should use when building the request for
transmission. The Owner or Node field on the XPSWD panel information should match
the Owner or Node field in the actual XPJOB job definition (DB.10). Because multiple
XPJOB definitions can have the same Owner or Node, the XPSWD panel eliminates the
need to associate user-ID, password, and domain information with each XPJOB
definition.

376 Database Maintenance Guide

 XN.2 - XPSWD Command

The XPDEF initialization file statement PSWDLOC keyword determines the order in
which the XPSWD information is checked when building the request. Consider the
following setting:

XPDEF PSWDLOC=(DATABASE,NODE)

With this setting, CA WA CA 7 Edition looks at the XPSWD OWNER access records for
user-ID, password, and domain information before looking at XPSWD NODE access
records.

Note: For more information about this search hierarchy, see the Systems Programming
Guide.

For example, assume that XPJOB XYZJOBA is defined to the CA WA CA 7 Edition

database and its OWNER field is XUSERA. Using the XPSWD panel, you can create an
XUSERA OWNER access record where the user-ID is xuseraxpjobfromca7, and
xuserapswd is the password. When job XYZJOBA is requested, it includes
xuseraxpjobfromca7 and xuserapswd in the request it transmits to the target system. In
fact, any XPJOB definition that has an OWNER of XUSERA uses this same information in
the request it transmits to the target system.

Now, assume that XPJOB XYZJOBB has its OWNER field set to XUSERB and its NODE is
XNODEB. Using the XPSWD panel ,you create an XNODEB NODE access record where the
user-ID is xnodebxpjobfromca7 with no password or domain. Note that there is no
XUSERB OWNER record. When job XYZJOBB is requested, it includes
xnodebxpjobfromca7 in the request it transmits to target system XNODEB. As above, all
XPJOB jobs that are routed to XNODEB would use this same information (assuming no
OWNER access record matched the OWNER field in the XPJOB definition).

OWNER or NODE can be entered on the XPSWD panel but not both simultaneously.

The XPDEF PSWDLOC value can also be set to USER. When this value is used, the input
PARM data for the XPJOB job can be the source of the user-id, password, and domain
information.

Always in CA WA CA 7 Edition, the password is in nondisplay format. If a request is to

display the user ID and password, the password field is blank.

To display the panel, enter:

■ XN.2 as the function on a DBM panel or the top line command.
■ XPSWD as the function on a DBM panel or the top line command.

Chapter 12: Internal Cross-Platform 377

XN.2 - XPSWD Command

To exit the panel:

■ Press PF3 to return to the DB Menu panel except with the TSO/ISPF interface when
PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter a top line command for
another function.

------------------- CA-7 XPJOB User ID/Password Definition -------------------

Function: xxxxxxxx (Add, Delete, Format, List, Update)

Owner: xxxxxxxx
or Node: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

User ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Password: (Password Not Present)

Reconfirm PSWD:

Domain Name: xxxxxxxxxxxxxxx (Windows platform)

PROGRAM: SMX2 MSG-INDX: nn -- XN.2 -- yy.ddd / hh:mm:ss

MESSAGE: Enter function, transfer or enter a command on the top line

XPSWD
Indicates that the password command is entered, and a positional parameter.
Function
Specifies the function to perform. Value must be the name of some other panel or
one of the following values:
Add
Adds a user/password for an owner or node to the database when the same
named entity (owner or node) does not already exist.
Delete
Deletes an owner/node entity and its associated data from the database.
Format
Clears the panel of all input data.

378 Database Maintenance Guide

 XN.2 - XPSWD Command

List
Lists an owner or node entity. In batch, a formatted panel is not listed; only a
found or not found message is returned.
Update
Updates database information about an owner or node entity.
Batch Keyword: Positional parameter
OWNER
Indicates to create an owner record. This owner equates to the owner field of the
XPJOB job panel, so that multiple jobs all use the same user ID and optional
password/domain name. Enter OWNER or NODE, not both.
Limits: 1 to 8 alphanumeric characters
Batch keyword: OWNER
NODE
Defines a default user ID and password to use when PSWDLOC=NODE is coded and
used through the XPDEF PSWDLOC security hierarchy. The node must exist as a
permanent entry in the node table. Enter OWNER or NODE, not both.
Limits: 1 to 44 alphanumeric characters
Batch keyword: NODE
User ID
Defines the user ID to insert into the information sent to the alternate platform
with a job for execution. If a user specifies the ROOT user ID, a verification is made
against the XPDEF SUBROOT setting. If SUBROOT is set to NO, an error message is
displayed if root or ROOT is entered for the user ID.
Limits: 1 to 32 alphanumeric characters
Batch keyword: XPUSER
Password
(Optional) Defines the password associated with the user ID to insert into the
information sent to the alternate platform with a job for execution.
Note: In an online session, this is a non-displayable field.
Limits: 1 to 14 alphanumeric characters
Batch keyword: XPPSWD

Chapter 12: Internal Cross-Platform 379

XN.2 - XPSWD Command

Reconfirm PSWD
(Optional) Defines the password that is associated with the user ID, and this
password should match the PASSWORD field previously entered. If a match does
not occur, an error message appears asking for validation.
Note: In an online session, this field does not display.
Limits: 1 to 14 alphanumeric characters
Batch keyword: RXPPSWD
Domain Name
(Optional) Defines the domain name if the user ID and password are targeted for a
Windows (NT) platform. Windows permits multiple domains to be executing in one
machine, and this qualifies the user ID and password targeted for a specific domain
on a Windows operating system.
Limits: 1 to 15 alphanumeric characters
Batch keyword: XPDMN

(Password Present)/(Password Not Present) Message

The XPSWD panel displays the (Password Present)/(Password Not Present) message to
indicate the presence or absence of a password. The SASSHIS8 Transaction Detail report
(Report 02) and the Database Update Transaction Detail report (Report 12) do not
display the message.

The meaning of the message depends on the success of the function.

■ When successfully adding or updating, the message indicates whether a password is
associated with the record in the database.
■ If an add function is unsuccessful (an error message is received at the bottom of the
panel), the Password Not Present message indicates that you must reenter this
information to associate a password with the record.
Note: A password is not required.

380 Database Maintenance Guide

 XN.3 - AGPSWD Command

■ If an update function is unsuccessful (an error message is received at the bottom of

the panel), the Password Not Present message indicates that you must reenter this
information to update password information for this record. The information
already in the database is not updated unless the update completes successfully.
■ When the list function is successful, the message indicates the presence or absence
of a password for the record in the database.
■ The delete and format functions always display the Password Not Present message.

You have two options if you want to remove a password that is associated to an Owner
or Node Password record:
■ Delete the record and reenter it without a password.
■ Alternately, blank out the password using the Update function, which resets the
password to a null value.

XN.3 - AGPSWD Command

The XN.3 or AGPSWD command displays a formatted panel to permit entry of
security-related data for agent jobs. Because this is a secured panel, access to the panel
and the information on it is controlled. If the XPDEF file initialization statement
AGENTJOB keyword is set to NO, the panel is disabled for all users.

Note: For more information about secured panels, see the Security Reference Guide.

For agent jobs that require a password, the user ID, agent, job type, and optionally a
source field are used as a hierarchical key at job submission time to search a password
database. The password database supports specific entries for user ID and specific or
generic entries for agent, job type, and source. The search returns the most specific
match.

The AGPSWD panel allows for the definition, update, deletion, or existence check of
passwords associated with a hierarchical key composed of user ID, agent, job type, and
source. The source field is associated with a limited number of job types. The user ID is a
required field, and agent, job type, and source are optional fields. Wildcard characters
are not permitted in any of the four key fields. When adding or updating a password
record, if no data is supplied for an optional field (agent, job type, or source), that field
is treated like a generic * mask and matches all input values during the job submission
password search process.

Chapter 12: Internal Cross-Platform 381

XN.3 - AGPSWD Command

The password is never shown on the panel, and the LIST option only returns a message
indicating whether the password record was found.

To display the panel, enter:

■ XN.3 as the function on a DBM panel or the top line command.
■ AGPSWD as the function on a DBM panel or the top line command.

To exit the panel:

■ Press PF3 to return to the DB Menu panel except with the TSO/ISPF interface when
PF3 has been assigned to another function.
■ Move the cursor to the top line of the panel and enter a top line command for
another function.

------------------- CA-7 Agent User ID/Password Maintenance ------------------

Function: (Add, Delete, Format, List, Update)

User Id:

Agent:

Job Type:

Source:

Old Password: (for Update only)

New Password:

Verify Password:

PROGRAM: SMX3 MSG-INDX: 00 -- XN.3 -- yy.ddd / hh:mm:ss

MESSAGE: Enter function, transfer or enter a command on the top line

382 Database Maintenance Guide

 XN.3 - AGPSWD Command

This panel contains the following fields:

Function
Specifies the function to perform. Value must be the name of some other panel or
one of the following values:
Add
Adds a password record to the database when the same named entity does not
already exist.
Delete
Deletes a password record from the database.
Format
Clears the panel of all input data.
List
Verifies the existence of a password record through a displayed message. In
batch, a formatted panel is not listed; only a found or not found message is
returned.
Update
Updates a password record on the database.
Batch keyword: Positional parameter
User Id
Indicates a user ID that is passed with a password to an agent for authorization.
Limits: Two 64-byte lines composing 128 characters. The wildcard characters * and
? are not permitted.
Batch keyword: AG1, AG2
Agent
(Optional) Indicates the agent that is the target of a job submission and where the
user ID and password authorization takes place. If omitted on an add or update, it
indicates that this password record is eligible for selection for all agent values.
Limits: 1 to 16 characters. The wildcard characters * and ? are not permitted.
Batch keyword: AGENT

Chapter 12: Internal Cross-Platform 383

XN.3 - AGPSWD Command

Job Type
(Optional) Indicates the job type of the job that requires a user ID and password
authorization. If omitted on an add or update, it indicates that this password record
is eligible for selection for all job types.
Limits: 1 to 16 characters. The wildcard characters * and ? are not permitted.
Batch keyword: AGJOBTYP
Source
(Optional) Indicates the source field for a job that requires a user ID and password
authorization. This field applies to a limited number of job types. If omitted on an
add or update, it indicates that this password record is eligible for selection for all
source values.
Limits: 1 to 64 characters. The wildcard characters * and ? are not permitted.
Batch keyword: AGSOURCE
Old Password
(Optional) Defines the current password that is associated with the four key fields
(user ID, agent, job type, and source).
Note: This field does not display.
Limits: 1 to 32 characters. Used only on an UPDATE request.
Batch keyword: AGOLDPW
New Password
(Optional) Defines the new password to associate with the four key fields (user ID,
agent, job type, and source).
Note: This field does not display.
Limits: 1 to 32 characters. Used only on an ADD or UPDATE request.
Batch keyword: AGNEWPW
Verify Password
(Optional) Defines the new password again for confirmation purposes. If a match
with New Password does not occur, the panel displays an error message.
Note: This field does not display.
Limits: 1 to 32 characters. Used only on an ADD or UPDATE request.
Batch keyword: AGVERPW

384 Database Maintenance Guide

Chapter 13: Database Transportability
This section contains the following topics:
Overview (see page 385)
Assumptions (see page 387)
Database Extraction (see page 392)
Moving Jobs (see page 397)
Workstation Networks (see page 404)
Application Data Sets (see page 406)
PDS JCL Members (see page 408)
CA Librarian JCL (see page 410)
CA Panvalet JCL (see page 413)
Cataloged Procedures (see page 416)
Documentation (see page 418)
Schedules (see page 420)
Node and Access File (see page 425)
Agent DIV File (see page 426)
Create Command Files (see page 427)
Special Considerations (see page 434)
Virtual Resource Management Database Extracts (see page 436)
VRM Node and Access Transport Program (see page 440)
Automated Recovery Facility Database Extracts (see page 443)

Overview
Important! CA WA CA 7 Edition r11.1 provided cross-platform job definition through the
XPJOB command. In CA WA CA 7 Edition r11.3, the AGJOB command further enhanced
cross-platform job definition. Jobs defined using the XPJOB command, or the equivalent
DB.10 panel, cannot be transported to a pre-r11.1 level. Jobs defined using the AGJOB
command, or the equivalent DB.11 panel, cannot be transported to a pre-r11.3 level.

Occasionally, you may want or need to transfer work from one CA WA CA 7 Edition
database to another. One reason for doing this might be to better balance the workload
across multiple data centers. Another reason might be to move test applications into a
production database from a test database. Certainly, other reasons exist for transferring
information between databases.

Chapter 13: Database Transportability 385

Overview

The effort required to redefine manually the workload into another database, even with
online preformatted panels, can be sizeable. The amount of time typically available for
this activity is limited. In most cases, a weekend or after-hours is selected; whenever
production is relatively inactive. When the database move is done manually, the
accuracy is suspect, particularly when it is done hurriedly.

CA WA CA 7 Edition provides database transportability programs that, in batch mode

and with the Batch Terminal Interface (BTI) facility, provide assistance in transfers of
workload definitions.

The transportability process uses standard CA WA CA 7 Edition inquiry, Batch Terminal

Interface (BTI) and Database Maintenance (DBM) facilities to assist the user in relocating
workload definitions from one CA WA CA 7 Edition database to another or making mass
changes. This process assumes that the workload to be moved or changed is in good
running condition at the original (sending) site; that is, it is properly defined in the
original site's database and presumably being run (or ready to be run) there on a regular
basis.

Moving workload definitions from one database to another is a labor-intensive process.

The impact on both of the databases can be major. Certainly, the impact on any two (or
more) data centers involved in such a move is major. The movement of the following
and some other related items are beyond the realm of the functions performed by the
database transportability process:
■ Application data sets
■ Program libraries

This transportability process is only intended to simplify the CA WA CA 7 Edition

database portion of the total effort required. Some of the data sets and control reports
generated by this process can be of direct assistance, however, in moving other items
such as PROCLIBs.

The workload is placed in the new (receiving) database through various ADD commands
of the standard DBM functions. Therefore, the database that is to receive the definitions
of jobs and networks, can initially be empty or may contain definitions of other work.
When other work already exists in the database, the incoming work is effectively
merged into the database. The user should be sure that the incoming work does not
create any conflicts with preexisting work. The incoming work should have unique
names for the following:
■ Jobs
■ Networks
■ Data sets

and other items. Adding the work through DBM ensures that duplications do not occur.

386 Database Maintenance Guide

 Assumptions

This process does not actually add the work to the database. The process simply creates
data sets with which the user can perform necessary functions. Some of the data sets
contain standard BTI commands for performing DBM functions. Other data sets are for
handling CA Librarian, CA Panvalet, and PROCLIB members. (Movement of JCL can be
suppressed if the user wants to do that external to this process.)

These command data sets can be used any time after the user has reviewed, has
altered, or both the commands to accomplish the desired results. The data sets can then
be used whenever and wherever they are needed. The data sets must be generated
using the original site database, wherever it is located. Once created, the data sets can
be sent to whatever location needs them. Copies of the control reports that correspond
to the data sets could also be of value at the new site.

The user may find it helpful as a planning aid to run these jobs, multiple times if
necessary, just to get the reports that are produced. These reports provide an excellent
inventory organized into meaningful groups. That is, cataloged procedures are listed on
one report, DBM work on other separate reports, and so forth.

The process could be repeated as many times as necessary to get the correct results
without making any updates to any database. Once the user is satisfied that everything
has been properly considered and provided for, the process can then be run to create
the desired command data sets.

Assumptions
Not all of the process is automated. Some manual effort is required to ensure that the
total problem is properly solved. Other assumptions are also made that the user must
consider when using this process. The following address some of the particular
considerations for database movement using this process.

LOAD/RELOAD Status
All CPU jobs must have been loaded with the current JCL to ensure that all data sets
used by the jobs are properly identified and handled in the move. Any associated data
set documentation, cross-reference information, and so forth, are also dependent on
this. Any job that was in RELOAD status at the original site may have some data set
related errors in the new database definition. This is particularly true if JCL changes
reflect data sets not previously used that also have documentation and special
characteristics.

Chapter 13: Database Transportability 387

Assumptions

CA WA Restart Option Step Insertion

Whenever a job is defined in the original site database with INSERT-RMS=Y to cause the
CA WA Restart Option step to be automatically inserted by CA WA CA 7 Edition, the job
is moved assuming that CA WA Restart Option exists at the new site and the RMS step is
to continue to be inserted automatically.

If that is not the case, the final commands must have the INSRTRMS=Y keyword
manually edited (by the user) to the correct value before they are processed at the new
site.

Base Calendars
This process does not move base calendars. The commands generated to define and
resolve calendar schedules assume that the same calendars already exist at the new site
or that perpetual calendars are defined. They are further assumed to have the same
names as those used at the original site.

The user must manually define the necessary calendars at the new site. If necessary, the
BTI commands generated may be manually edited to reflect the correct calendar IDs
before the BTI run is made.

Calendar Schedules
All calendar oriented schedules are assumed to have been RESOLVed against the proper
Base Calendar. Without prior schedule resolution, the schedule is not correctly defined
by this process. (Any differences in calendar names between the two sites must be
manually edited into the BTI commands.)

DB.2.7 Schedule Modifications

This process has no facility to reapply any schedule changes that had been made
through the DB.2.7 facility. Information on schedules, just as it would appear in LJOB or
LSCHD output, is carried forward into the commands generated by this process. DB.2.7
changes have to be reapplied manually.

To assist the user in identifying those jobs that need such modifications reapplied at the
new site, the SASSDT30-02 control report, produced in the last step, includes a warning
message each time this condition is found. The message appears within a box of
asterisks on the report following the RESOLV command for the job's schedules.

388 Database Maintenance Guide

 Assumptions

NXTCYC Settings
In the event that normal scheduling of CPU jobs has been altered by a NXTCYC
command, that status is carried over to the database at the new site. This is
accomplished by generating the appropriate NXTCYC command into the DBMADDS2
data set.

For a discussion of the NXTCYC command, see the Command Reference Guide.

Execution JCL Libraries

This process provides the commands and JCL statements necessary to add the JCL to a
library at the new site. The execution JCL is added exactly as it appeared in LJCL output
at the original site except for embedded blank records. Any records that are completely
blank in positions 1-80 are ignored. The commands use the same member names as
those used at the original site.

It is also assumed that the new site uses the same number and types of JCL libraries as
those used at the original site. This is typically the case. Using a different DSORG value at
the new site makes it more difficult to use the generated commands because they are
generated assuming that the same DSORG is used and the commands are quite different
depending on the type of library being used.

It is further assumed that the libraries use the same JCLID or JCLLIB values. This is
probably not a good assumption because the chance of duplication across two data
centers is great, especially in the use of the default ID of zero. However, as long as a
one-to-one relationship exists between the libraries at the two sites, all references to
any one library in the generated BTI commands can be globally edited to another value
to reflect whatever JCLID or JCLLIB value is used at the new site.

The DBT discussion repeatedly uses JCL references, assuming jobs are CPU jobs.
However, when thinking of internal cross-platform jobs, the reader can substitute
PARMLIB or the parameters in the sentence without hesitation.

More information:

Cataloged Procedures (see page 390)

Chapter 13: Database Transportability 389

Assumptions

Cataloged Procedures
The user can bypass this feature by specifying JCL=N in the PARM for Job 2.

Otherwise, for each cataloged procedure executed in the production JCL, an

IEHPROGM-type SCRATCH command is generated. These commands can optionally be
used to delete the procedures at the original site once the move has been done and
verified to be correct at the new site.

The list of these generated commands can assist the customer in identifying which
cataloged procedures need to be moved to the PROCLIBs at the new site. Any such
movement of data must be handled by the customer external to this process. The list is
only an aid in accomplishing that task.

In-stream JCL Procedures

Although it is not a common practice for production jobs to use in-stream procedures
(bound by PROC and PEND statements in the JCL), this process allows up to 256 such
procedures within a single job. All other EXEC statements in the production JCL that
execute procedures are assumed to be executing cataloged procedures and are handled
as outlined in the prior discussion.

Workstation Networks
Only workstation networks directly related to a CPU job, through either a DB.3 or a
DB.2.5 function, are automatically moved by this process. If other networks are to be
moved, the user must handle them manually.

More information:

Unconnected Workstation Networks (see page 406)

User Level Documentation

This process ignores any documentation that was defined through the DB.4.3 panel. If
any such documentation is to be moved with the definition of the jobs, the customer
must handle that manually, external to this process.

CPU Job Considerations

Start the first line in the JCL member of a CPU job with a # or / character for correct
processing. Any subsequent lines do not have this restriction.

390 Database Maintenance Guide

 Assumptions

XPJOB/AGJOB Considerations
The XPJOB and AGJOB function DD is the same as Delete. In database transportability
(DBT), when deleting either job type from the source database, the Delete function is
always used, regardless of the parameter JOBDD=Y. Thus, you may see the function DD
used for a CPU job with JOBDD=Y, while seeing the function Delete with an XPJOB or
AGJOB job.

Commas in the Data

Because the information in the database is moved using BTI facilities, the use of
commas in some of the data fields creates conflicts with the syntax requirements of
batch commands. To help avoid such conflicts, this process replaces commas with
blanks whenever they are found embedded within any of these data fields:
■ User requirements (see DB.3.6)
■ REPORT-ID value for documentation
■ DESC value for documentation

If any such commas are required in the workload definition, they have to be manually
reinserted in the new database after the data has been moved.

Sequence Numbers
All of the commands generated by this process are sequence numbered in positions
75-80. The characters U7 are also in positions 73-74 of the commands. All sequence
numbers that previously existed within JCL statements are preserved by this process.
That is, wherever a JCL member is embedded within the generated commands, the
generated sequence is interrupted by the original JCL statements, all 80 positions. This
should be considered when browsing the generated command data sets. Control
reports listing the generated commands reflect the records, including sequence
numbers, as they appear within the data sets. Each data set has its own range of
sequence numbers.

User ID Security
All CPU jobs moved by this process carry the same User ID value to the new database.
(For more details on this facility, see the UID field on the DB.1 panel.) Any of the jobs
being moved create any conflicts with other User IDs in the new database, such conflicts
must be resolved manually by the user before the generated commands are processed
into the new database. New ID values could be manually edited into the generated
commands any time before they are processed.

Chapter 13: Database Transportability 391

Database Extraction

More information:

DB.1 - CPU Job Definition Panel (see page 34)

LINKed Documentation
Any documentation linked using the LINK field on any of the DB.4 panels cannot be
linked by this process because the documentation number must be known at the time
the add is done. It is assumed that the linked documentation is moved as some other
piece of this process and any linked documentation that shows up during this process is
ignored on that basis. The user must ensure that any linked documentation gets moved
as part of some other job, system, and so forth. The linking of the documentation
members then also has to be done manually after the adds have been made at the new
site.

Database Extraction
Database extraction is an iterative process. It uses multiple BTI runs alternated with
steps that examine database data. These steps produce command data sets that are
used in another BTI run to explode the database definitions. The last step produces
commands with which the user can accomplish the movement of the data from one
database to another.

You provide standard LJOB commands, LSYS commands, or both to first identify those
jobs that are moving. These commands can use any combination of selection options
but must omit the LIST= parameter because later programs expect the default formats.

Note: For more information about these commands, see the Command Reference
Guide.

392 Database Maintenance Guide

 Database Extraction

A BTI run is made using those commands. The program SASSDT10 that produces a
control report titled "Jobs Requested to be Moved" examines output from those
commands. The following is an example of this report:

SASSDT10-01 Jobs Requested to be Moved

SASSDT10-01 CA-7 DATA BASE TRANSPORTABILITY PAGE NO. 4

DATE: mm/dd/yy JOBS REQUESTED TO BE MOVED

D
U JOB ----JCL---- SYSTEM USR MAIN PROSE SCHED --NUMBER OF- LAST-RUN
P NAME ID MEMBER -NAME- -ID -ID- DSNBR DSNBR STP DDS RUNS DATE/TIME

DUSAXX07 002 DUSAXX07 PAYROLL 164 ALL 000893 *NONE* 011 047 0062 yyddd/1732
D DUSAXX23 002 DUSAXX23 PAYROLL 164 SY3 001259 000384 005 021 0018 yyddd/1456
DUSAXX05 002 DUSAXX05 PAYROLL 164 ALL *NONE* *NONE* 005 036 0074 yyddd/1824
XPSICOM1 000 ........ 000 XPJ *NONE* *NONE* 000 000 0000 yyddd/1724

NO. OF JOBS TO BE MOVED: 168

D INDICATES 'DUPLICATE' WHICH WAS IGNORED

Another data set is created containing more BTI commands necessary to review not only
the jobs but also the triggers, requirements, and JCL for those jobs. To accomplish this,
SASSDT10 generates a series of three commands for each nonduplicate job name listed
by the BTI step. Each of these commands is an LJOB command, with one each written
for the options LIST=STEPDD, LIST=TRIG, and LIST=RQMT, in that sequence. LIST=XPJOB
replaces LIST=STEPDD for XPJOBs. LIST=AGENT replaces LIST=STEPDD for AGJOBs. It is
this examination of the triggers and requirements that makes it possible for the
program to automatically include any workstation networks that are needed by these
jobs. This also allows the program to look one level in each direction from the requested
jobs to ensure that all related jobs are being moved. Jobs overlooked in the initial LJOB
commands, LSYS commands, or both are thus included in the final output as long as they
were no more than one level removed from the requested job.

After another BTI run, using the commands generated by SASSDT10, another program,
SASSDT20, examines the output and creates yet another data set of BTI commands to
list all of the database information that is needed to allow the work to be redefined into
another database. These commands are then the input to another BTI run.

Another control report is produced that indicates that commands were generated in
this step for each workload component to be moved. The commands generated by
SASSDT20 are listed beneath the command generated by SASSDT10 that listed the
component to be moved. If no commands were generated for any of the incoming
commands, the characters **NONE** appear.

Chapter 13: Database Transportability 393

Database Extraction

SASSDT20-01 Expansion of Requested Jobs

SASSDT20-01 CA-7 DATA BASE TRANSPORTABILITY PAGE NO. 29

DATE: mm/dd/yy EXPANSION OF REQUESTED JOBS

JOBNAME
*- GENERATED COMMANDS -------------------------------------------* SEQ.-NO.

DUSAXX05 (LIST=STEPDD)
LPROS,SYS=PAYROLL U7001722
LJOB,JOB=DUSAXX05,LIST=ALL U7001723
LJCL,JOB=DUSAXX05 U7001724
LPROS,JOB=DUSAXX05 U7001725
LPROS,JOB=DUSAXX05,STEP=STEP0050,DD=HISTFILE U7001726
LDSN,DSNBR=DS00008162,LIST=TRIG U7001727
LPROS,DSN=PAYROLL.HOURLY.HISTORY.DETAIL U7001728
LNTWK,NW=TIMECARD,LIST=ALL U7001729
LPROS,NW=TIMECARD U7001730

DUSAXX05 (LIST=TRIG)
**NONE**

DUSAXX05 (LIST=RQMT)
LJOB,JOB=DUSAXX09,LIST=ALL U7001731
LJCL,JOB=DUSAXX09 U7001732
LPROS,JOB=DUSAXX09 U7001733

To assist the user with the separate task of getting all of the necessary data sets
physically moved to the new site, a file of all data set names used by the jobs being
moved is also produced by SASSDT20. The ddname of this file is DATASETS. This is a
card-image data set containing the data set names beginning in position 1 of each
record. All records written to this data set contain a data set name. (No heading lines.)
The records are produced as the unique data set names occur in the data and therefore
are not in any particular meaningful sequence. The file produced can be listed as is or
could be sorted in data set name sequence before printing if desired.

Another BTI job is run using BTI commands produced by SASSDT20. When that run has
completed, the output produced contains all of the information needed to generate
commands with which the user can perform the move. The output from this BTI run is
used as input to the last program in this process, SASSDT30. Several card-image data
sets are created by SASSDT30.

Some of these are BTI data sets containing DBM commands, others are for handling JCL
libraries and are in another format.

394 Database Maintenance Guide

 Database Extraction

Two data sets contain add type commands for the new CA WA CA 7 Edition database.
That is necessary because the processing sequence of the commands is not the same as
the sequence in which the data becomes available to the programs that generate the
commands. For example, a JOBCONN function must await the definition of both the
connected items in the database before it can be performed. The user must process
these two data sets in the correct sequence at the new site to ensure correct definition
of the work in the database.

These data sets can be used whenever and wherever they are needed to accomplish the
appropriate database activity. They probably require several changes that the user must
make manually, using some text editor. Each data set created has a corresponding
control report to allow the user to review the data before making any changes.

The following figure shows how the final commands produced evolve from the initial
simple commands, with each one feeding subsequent commands. This sequence of
commands, the same sequence that would be required to manually examine the
workload for a move done without this process, could be repeated at an online CA WA
CA 7 Edition terminal to verify this process.

Command Evolution Process

The following topics discuss the specific types of workload definitions this process
handles and describe what is produced to permit moving the workload definitions.

Module SASSDT10:

/LOGON PARM=/LOGON= /LOGOFF

│ │ LJOB LSYS
│◄─────┘ │ │
▼ └─────┬───────┘
/LOGON │
┌────────────────┼───────────────┐
│ │ │
│ │ │
▼ ▼ ▼
LJOB,JOB= LJOB,JOB= LJOB,JOB=
LIST=STEPDD LIST=TRIG LIST=RQMT
LIST=XPJOB
LIST=AGENT

Chapter 13: Database Transportability 395

Database Extraction

Module SASSDT20:

PARM= LJOB,JOB= LJOB,JOB=,LIST=TRIG /LOGOFF

/LOGON /LOGON= LIST=STEPDD LJOB,JOB=,LIST=RQMT
│ │ LIST=XPJOB │
│ │ LIST=AGENT │
│◄────┘ ┌──┬──┬──┤ ┌──────┴───────┬───┐
▼ │ │ │ │ │ │ │
/LOGON │ │ │ │ │ │ │
/DISPLAY, │ │ │ ▼ ▼ │ │
ST=JCL │ │ │ LJOB,JOB=,LIST=ALL LJOB,JOB=,LIST=ALL │ │
│ │ │ LJCL,JOB= LJCL,JOB= │ │
│ │ │ LPROS,JOB= LPROS,JOB= │ │
│ │ │ ▼ │
│ │ ▼ LNTWK,NW=,LIST=ALL │
│ │ LDSN,LIST=TRIG LPROS,NW= │
│ │ LPROS,DSN= ▼
│ ▼ LDSN,LIST=TRIG
│ LPROS,JOB=,STEP=,DD= LPROS,DSN=
│
▼
LPROS,SYS=

396 Database Maintenance Guide

 Moving Jobs

Module SASSDT30:

PARM= LJOB,JOB=,LIST=NODD /LOGOFF

/LOGON /LOGON= │
│ │ │ /DISPLAY
│◄───┘ │ LJCL,JOB=
▼ │ │
/LOGON │ │ LDSN,LIST=TRIG
│ │ │
┌───────────────┘ │ │ LNTWK,NW=, LPROS,JOB=
│ │ └──┬────┐ │ LIST=ALL LPROS,DSN=
│ ┌──────┬─┬────┬─┬─┬┴────┬───┐ │ │ │ LPROS,SYS=
│ │ │ │ │ │ │ │ │ ▼ │ │ LPROS,NW=
│ ▼ │ │ │ │ │ ▼ │ DSN │ │ LPROS,JOB=,STEP=,DD=
│ JCL │ │ │ │ │ SCRATCH │ ADD, │ │ │
│ DELETE │ │ │ │ │ ┌───┘ ┌────┘ │ ┌─────┴──────┐
│ ┌───┘ ▼ │ │ │ │ │ │ │ │
│ │ DBM │ │ │ ▼ ▼ │ ▼ ▼
│ ▼ LOAD, │ │ │ -DLM SCHD │ PROSE PROSE
│ JCL JOB= │ │ └──────┐ TRGR │ DELETE,SYS EDIT
│ EDIT │ │ │ UPD,DTRG │ I ,
│ I , ┌─┘ │ ▼ │ ...
│ ... │ │ ++STATUS,DISABLE │ $IEND
│ $IEND ▼ └────────┐ │ XSEQ
│ XSEQ -OPT │ │ SAVE
│ SAVE -ADD ▼ │ SAVE,type
│ SAVE, ... ++ADD,DATA │ DESC=
│ ─EMOD │ FORM=,...
│ ┌──────────────┬─────────┬───────────┴──┬────────────────┐ REPORT
│ │ │ │ │ │ CLEAR
│ ▼ ▼ ▼ ▼ ▼
│ NETWORK NETWORK SCHD SCHD SCHD
│ ADD, DELETE ONWK INWK INWK
│ STAT= EDIT,NETWORK= FETCH,NETWORK= EDIT,NETWORK=
│ ADD,SCHID= REPL ADD,SCHID=
│ SAVE SAVE
│ SAVE,NETWORK= SAVE,NETWORK=
│ DBM
| RESOLV
└─┬─┬──┬───┬─┬─┬─────┬─┬─┬─────┬──────┬─┬─┬────────┬──────┬─┬────────┐
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │
│ │ ▼ │ │ ▼ │ │ ▼ │ │ │ ▼ │ │ ▼ ▼
│ │ JOB │ │ XPJOB │ │ AGJOB │ │ │ JOBCONN │ │ SCHD SCHD
│ │ UPD │ │ UPD │ │ UPD │ │ │ UPD,JDEP │ │ TRGR JOB
│ ▼ │ ▼ │ ▼ │ │ ▼ │ │ UPD,JTRG EDIT
│ JOB │ XPJOB │ AGJOB │ │ JOBCONN │ ▼ ADD,SCHID=
│ DELETE │ DELETE │ DELETE │ │ UPD,DSN │ SCHD SAVE
▼ ▼ ▼ ▼ ▼ ▼ TRGR SAVE,JOB=
JOB XPJOB AGJOB DBM JOBCONN JOBCONN UPD,NTRG DBM
ADD ADD ADD NXTCYC, UPD,NWK UPD,USR RESOLV

Moving Jobs
The following topics discuss adding jobs at the new site, deleting jobs at the original site,
and disabling jobs at the original site.

Chapter 13: Database Transportability 397

Moving Jobs

Add at New Site

For each job to be moved, a set of commands is generated into the DBMADDS1 data set
to perform the necessary DBM JOB function. Those commands are generated as follows:

For CPU jobs:

JOB
ADD,jobname,.........keywords and values...............,
.
................more keywords and values...............,
.

For XPJOB jobs:

XPJOB
ADD,jobname,.........keywords and values...............,
.
................more keywords and values...............,
.

For agent jobs:

AGJOB
ADD,jobname,.........keywords and values...............,
.
................more keywords and values...............,
.

Some historical information such as number of times run and number of times late are
not carried forward to the new site because the DB.1 panel has no input fields for those
values. The average CPU and elapsed time requirements are carried forward.

A number of keywords may be required to complete the definition of a job. Many of the
available parameters are optional.

To minimize the number of parameters used, most parameters are not included in the
generated commands if the value equals the usual CA WA CA 7 Edition default. Multiple
records may still be required to accommodate all of the needed keywords and values.
Normal BTI continuation conventions are observed for those records.

398 Database Maintenance Guide

 Moving Jobs

The LOAD function needs to be performed for each of the jobs sometime after they are
defined at the new site; therefore, the keyword RELOAD is included for all jobs with a
value of Y (that is, RELOAD=Y). This allows the jobs to be defined at the new site without
having to do a LOAD on each one of them at the time they are defined. This defers that
process until the job runs for the first time at the new site. If the number of jobs is very
high, it would take considerable time to perform individual LOADs all at once. The
RELOAD option is bypassed for both XPJOB and AGJOB jobs because they have no real
JCL to load.

Because it is likely that the JCL library ID values are different at the new site, ADD
commands for all job definitions include the keyword JCLID, even if the default ID of
zero was used. This makes it easier for the user to apply global changes to the
commands if necessary.

These commands are sequence numbered in positions 73 through 80. They are also
listed (with other DBM add functions for other related components being moved) on the
SASSDT30-01 Database Adds - Part 1 report. The following is an example of that report:

SASSDT30-01 Data Base Adds - Part 1

SASSDT30-01 CA-7 DATA BASE TRANSPORTABILITY PAGE NO. 265

DATE: mm/dd/yy DATA BASE ADDS - PART 1

*- COMMANDS GENERATED ------------------------------------------------* SEQ.-NO.

JOB U7017351
ADD,DUSAXX09,SYSTEM=PAYROLL,JOBNET=MONTHLY,USERID=164,JCLID=002, U7017352
RELOAD=Y,RETJCL=Y,INSRTRMS=Y,CONDCODE=004,RELOPR=LT,PRTY=200 U7017353
JCL U7017354
SAVE,DUSAXX09,JCLID=002 U7017355
XPJOB U7017356
ADD,XPSICOM1,CLASS=A,LTERM=MASTER, U7017357
NODE=TESTPLN, U7017358
EX1=(c:\nsm\bin\cau9test ), U7017359
XPTRACE=N U7017360
AGJOB U7017361
ADD,CA750006,MEMBER=CA750006,PRMLIB=200,CLASS=A,LTERM=MASTER, U7017362
AGJOBTYP=UNIX_JOB, U7017363
AGENT=UNIXAGENT, U7017364
AG1=(USERID0006 ) U7017365

NO. OF 'ADDS' FOR.

JOBS- 175 SYS PROSE- 2
JCL- 136 JOB PROSE- 174
NWKS- 248 NWK PROSE- 248
DSNS- 421 DD PROSE- 0
DSN PROSE- 329

Chapter 13: Database Transportability 399

Moving Jobs

More information:

DB.1 - CPU Job Definition Panel (see page 34)

DB.10 - XP Job Definition Panel (see page 50)
DB.11 - Agent Job Definition Panel (see page 64)

Requirements and Network Connections

Each job being moved is examined to determine what predecessor and successor
relationships exist in the database. These relationships are determined by examining the
connections that are defined in the database with the various DB.3 functions of CA WA
CA 7 Edition. Those connection types and their corresponding batch DB.3 function are as
follows:

JOB - JOBCONN,JOB
DSN - JOBCONN,DSN
NWK - JOBCONN,NWK
USR - JOBCONN,USR

JOB Connections

For each of the JOB type connections, a set of commands is generated into the
DBMADDS2 data set to perform the JOBCONN,JDEP function as follows:
JOBCONN
{?}
UPD,JDEP,jobname,OPT=A,SCHID=nnn,DEPJOB={-}depjobname [,LEADTM=nnnn]
{/}

A negative dependency is indicated through the use of a / preceding the depjobname

value. Prefixing the depjobname value with ? indicates a conditional dependency.

NWK Connections

For each of the NWK type connections, the following set of commands is generated into
the DBMADDS2 data set to perform the JOBCONN,NWK function:

JOBCONN
UPD,NWK,jobname,OPT=A,NETWORK=networkname
[,SCHID=nnn] [,NWKSCHID=nnn] [,LEADTM=nnnn]
[,SUBID=xxxxxxxx] [,DESC=description]

400 Database Maintenance Guide

 Moving Jobs

DSN Connections

For each of the DSN type connections, the following set of commands is generated into
the DBMADDS2 data set to perform the JOBCONN,DSN function:

JOBCONN
UPD,DSN,jobname,OPT=A,DSN=datasetname
[,SCHID=nnn] [,LEADTM=nn] [,PERM=Y]

USR Connections

For each of the USR type connections, the following set of commands is generated into
the DBMADDS2 data set to perform the JOBCONN,USR function:

JOBCONN
UPD,USR,jobname,OPT=A,USR=description [,SCHID=nnn]

To avoid conflicts with batch command syntax, any comma, parenthesis or apostrophe
found within the defined description text is replaced with a blank.

All commands generated for JOBCONN functions are sequence numbered in positions
73 through 80. They are also listed on the SASSDT30-02 Database Adds - Part 2 report.
SCHD commands for job, networks, and triggers are also produced in the DBMADDS2
data set and are listed on the report. The following is an example of that report:

SASSDT30-02 Data Base Adds - Part 2

SASSDT30-02 CA-7 DATA BASE TRANSPORTABILITY PAGE NO. 119

DATE: mm/dd/yy DATA BASE ADDS - PART 2

*- COMMANDS GENERATED ------------------------------------------------* SEQ.-NO.

JOBCONN U7008871
UPD,JDEP,DUSAXX09,OPT=C,SCHID=001,DEPJOB=DUSAXX10,LEADTM=99 U7008872
UPD,JDEP,DUSAXX09,OPT=C,SCHID=002,DEPJOB=/DUSAXX08 U7008873
SCHD U7008874
TRGR U7008875
UPD,JTRG,JOB=DUSAXX09,OPT=A,SCHID=001,TRGID=001,TJOB=DUSAXX11, U7008876
DOTM=1730,LEADTM=0115 U7008877

NO. OF 'ADDS' FOR: NXTCYC'S FOR:

SCHD/JTRGS- 128 JOBCONN/JOBS- 298 SKP- 2
SCHD/NTRGS- 24 JOBCONN/NWKS- 248 OFF- 5
SCHD/DTRGS- 4 JOBCONN/DSNS- 315
JOB/SCHDS- 19 JOBCONN/USRS- 43
NWK/SCHDS- 248

Chapter 13: Database Transportability 401

Moving Jobs

Delete at Original Site

For each job being moved, the following set of commands is generated into the
DBMDELTS data set to perform the DBM JOB or XPJOB deletion function at the original
site:

JOB
DELETE,jobname

XPJOB
DELETE,jobname

AGJOB
DELETE,jobname

The commands are sequence numbered in positions 73 through 80 and listed on the
SASSDT30-03 Database Deletes report. Some other deletion functions are also listed on
that report because their commands are written to the DBMDELTS data set.

Deletion of the JCL for the job is performed separately with another set of commands.
Deletion of associated documentation and schedules occurs automatically when the job
is deleted at the original site.

The DB.1 panel function DD not only deletes a job but also definitions of any data sets
for which this job was the last "using-job" reference. If the user wants to use that
function instead of the default DELETE function, the JOBDD keyword must be specified
in the PARM data for Job 3.

SASSDT30-03 Data Base Deletes

SASSDT30-03 CA-7 DATA BASE TRANSPORTABILITY PAGE NO. 18

DATE: mm/dd/yy DATA BASE DELETES

*- COMMANDS GENERATED ------------------------------------------------- SEQ.-NO.

JOB U7001119
DELETE,DUSAXX09 U7001120
JCL U7001121
DELETE,DUSAXX09,DSN=PAYROLL.JCLLIB,VOL=M80007 U7001122
XPJOB U7001123
DELETE,XPSICOM1 U7001124
AGJOB U7001125
DELETE,AGJOB01 U7001126

NO. OF 'DELETES' FOR:

JOBS- 175
JCL- 136
NWKS- 248
SYS/PROSE- 2

402 Database Maintenance Guide

 Moving Jobs

More information:

Job 3 (see page 431)

Disable at Original Site

Job definitions at the original site should be retained in that database until it is
confirmed that the job has run successfully at the new site at least once.

The DBMDELTS data set provides one set of commands to delete the definitions from
the original database. The DBMSTOPS data set enables the user to disable the job at the
original site without deleting the definition. This allows the definitions to be retained
without the work being scheduled again automatically by CA WA CA 7 Edition after the
work has been moved.

These commands are generated as follows:

JOB
UPD,jobname,ADATE=yyddd,ATIME=hhmm

XPJOB
UPD,jobname,ADATE=yyddd,ATIME=hhmm

AGJOB
UPD,jobname,ADATE=yyddd,ATIME=hhmm

The values for ADATE and ATIME are, by default, taken from the system internal clock at
the time that the command generation process is run. These values can be edited
manually by the user to any other values prior to using them or the user can provide
alternative values through the PARM keyword AFTER for Job 3.

Sequence numbers are placed in positions 73 through 80 and the commands are listed
on the SASSDT30-04 control report. The following is an example of that report:

(Any commands generated to disable workstation network schedules are also listed on
that report because they are also generated into the DBMSTOPS data set.)

Chapter 13: Database Transportability 403

Workstation Networks

SASSDT30-04 Data Base Disables

SASSDT30-04 CA-7 DATA BASE TRANSPORTABILITY PAGE NO. 22

DATE: mm/dd/yy DATA BASE DISABLES

*- COMMANDS GENERATED ------------------------------------------------* SEQ.-NO.

SCHD U7001098
INWK U7001099
FETCH,NETWORK=TIMECARD U7001100
REPL U7001101
JOB U7001102
UPD,DUSAXX09,ADATE=09027,ATIME=1452 U7001103
XPJOB U7001104
UPD,XPSICOM1,ADATE=09027,ATIME=1452 U7001105
AGJOB U7001106
UPD,AGJOB01,ADATE=09027,ATIME=1452 U7001107

NO. OF 'DISABLES' FOR:

JOBS- 175
SCHD/INWKS- 248

More information:

Job 3 (see page 431)

Workstation Networks
Workstation networks, both preprocessing and postprocessing, are handled by this
process implicitly when a network is either connected to a CPU job being moved or
triggers the execution of a CPU job being moved. (Only CPU jobs must be requested
explicitly by the user for movement.)

If any workstation networks do not meet these criteria but must be moved, they must
be moved manually.

More information:

Unconnected Workstation Networks (see page 406)

404 Database Maintenance Guide

 Workstation Networks

Add at New Site

For each network to be moved, commands to perform the DBM NETWORK function are
generated into the DBMADDS1 data set as follows:

NETWORK
ADD,networkname,type,SUBID=subidvalue,JOB=jobname,
STAT=(stationname1,stationname2,...,stationname9)

The values for these parameters are taken from information listed during an
intermediate step of this process with a LNTWK command with the LIST=ALL option.

Note: For more information about the LNTWK command, see the Command Reference
Guide.

Each of these commands is sequence numbered in positions 73 through 80 and each is

listed on the SASSDT30-01 control report.

Delete at Original Site

For each network name being moved, the following commands are generated into the
DBMDELTS data set to assist in deleting the network definition from the original
database:

NETWORK
DELETE,networkname

The networkname is the same as it was in the commands generated to add the network
at the new site.

Sequence numbers are placed in positions 73 through 80 of each command and each
command is listed on the SASSDT30-03 control report.

Disable at Original Site

The following topics discuss disabling networks at the original site.

Chapter 13: Database Transportability 405

Application Data Sets

Input Workstation Networks

Workstation networks have no "don't schedule after" facility. The way to prevent
networks from being scheduled again at the original site is to unRESOLVe the schedules
for the networks in that database.

To accomplish this, one set of commands to perform the SCHD,INWK replace function is
generated into the DBMSTOPS data set as follows:

SCHD
INWK
FETCH,NETWORK=networkname
REPL

These commands are sequence numbered in positions 73 through 80 and are listed on
the SASSDT30-04 control report.

Output Workstation Networks

Because schedules for output workstation networks are based on the associated CPU
job being scheduled and the CPU jobs are disabled through another set of commands,
no other commands are required to disable these networks at the original site.

Unconnected Workstation Networks

To include any workstation networks that cannot be automatically included based on a
connection or trigger definition, add two commands to the input (SYSIN DD) to Job 3, as
follows:

LNTWK,NW=networkname,LIST=ALL
LPROS,NW=networkname

Include one set of commands for each unique network name to be included in the
move.

More information:

Create Command Files (see page 427)

Application Data Sets

The following topics address application data sets.

406 Database Maintenance Guide

 Application Data Sets

Add at New Site

Because all of the CPU jobs moved to the new site go through the CA WA CA 7 Edition
LOAD process before running at the new site, this process only generates commands to
define data sets at the new site when any of the following is true:
■ Data set is permanent to CA WA CA 7 Edition globally
■ Data set is permanent to individual specific jobs
■ Data set has documentation defined for it
■ Data set triggers jobs

For each of these situations, commands to perform the DBM DSN function are
generated into the DBMADDS1 data set as follows:

DSN
ADD,DSN=datasetname [,TYPE=PERM] ,SMF=Y

Adding data set definitions in this way reduces the overhead of each LOAD function
when it is subsequently performed. It also ensures that the needed data set definitions
are in the database so that the documentation can be added, any schedule triggering
can be defined, or both. Each data set is automatically assigned a new CA WA CA 7
Edition data set number when the definition is made at the new site.

The TYPE=PERM parameter is only included for those data sets that were so designated
in the old database.

The commands are sequence numbered in positions 73 through 80. They are also listed
on the SASSDT30-01 control report.

More information:

Data Set Adds (see page 303)

Chapter 13: Database Transportability 407

PDS JCL Members

Delete at Original Site

No commands are generated to delete data set definitions at the original site. The DB.1
panel has a function value of DD available. That function causes data set definitions to
be deleted from the database at job deletion time if the job being deleted is the last
"using-job" reference to the data sets.

If such a deletion is important, consider the following:

■ Use the JOBDD keyword in the third job of the generation process, or
■ Edit manually the generated commands to delete jobs from the database at the
original site to replace the function value DELETE with DD before using the
generated commands.

Job 2 produces a file of data set names on the data set referenced by the ddname of
DATASETS. This file contains one record for each unique data set name that this process
is moving.

Such a file becomes a source from which batch commands could be produced to
perform any desired deletions of data set definitions at the original site. A data set
similar to any of the BTI data sets created by this process to do DBM functions could be
produced and processed to clean up the original database once the definitions were no
longer needed.

More information:

Job 2 (see page 429)

PDS JCL Members

If the user wants to handle the movement of JCL totally external to this process, without
any of these reports or commands being produced, the JCL=N parameter should be
included in the PARM for module SASSDT20.

The discussions in this section assume that the user wants to produce reports and
commands.

More information:

Create Command Files (see page 427)

408 Database Maintenance Guide

 PDS JCL Members

Add at New Site

If a job has an execution JCL member residing in a PDS library, a set of commands,
including the JCL, are generated into the DBMADDS1 data set, to perform the DBM JCL
function, as follows:

JCL
EDIT
I ,
.
.
. (JCL statements go here)
.
.
$IEND
XSEQ
SAVE
SAVE,membername,JCLID=nnn
CLEAR

The member name is the same as defined in the original database. The other
parameters allow the JCL to be placed in a library with the same sequence numbers that
existed before.

JCL statements carry whatever sequence numbers previously existed in positions 73

through 80. The other statements are sequence numbered consecutively in positions 73
through 80.

Each JCL and SAVE,membername,JCLID=nnn statement produced are listed on the

SASSDT30-01 control report. The actual JCL statements and the other generated
commands in each of these sets are not listed.

Only one such set of records is generated for any single member name no matter how
many jobs may have used this member name for their JCL.

The JCL for jobs that already include a $IEND cannot be moved with DBT. This JCL has to
be copied externally from the DBT process.

More information:

JCL and PARM Data Maintenance (see page 311)

Chapter 13: Database Transportability 409

CA Librarian JCL

Delete at Original Site

Each JCL member copied into the DBMADDS1 data set for moving to a new site also has
commands generated into the DBMDELTS data set to assist the user in cleaning up the
JCL libraries at the original site. The commands are in the following format:

JCL
DELETE,membername,DSN=datasetname,VOL=volser#

The membername is the member name used in the database. Values for DSN= and VOL=
are taken from the definitions of the JCL libraries defined to CA WA CA 7 Edition.

These commands are sequence numbered in positions 73 through 80 in the DBMDELTS

data set. Generated commands also are listed on the SASSDT30-03 control report.

Only one set of commands is generated for any single member name no matter how
many jobs may have used this member name for their JCL.

CA Librarian JCL
If the user wants to handle the movement of JCL totally external to this process, without
any of these reports or commands being produced, the JCL=N parameter should be
included in the PARM for module SASSDT20.

The discussions in this section assume that the user wants to produce reports and
commands.

More information:

Create Command Files (see page 427)

410 Database Maintenance Guide

 CA Librarian JCL

Add at New Site

If a job has an execution JCL member residing in a CA Librarian library, a set of records,
including the JCL, is placed in the LIBRADDS data set as follows:

-OPT NOINDEX,NORESEQ
-ADD membername,NOEXEC,NOLIST,NOPUNCH,SEQ=/73,8,10,10/
.
.
. (JCL statements go here)
.
.
-EMOD

The member name is the same as it was defined in the original database. For the
meanings of the various commands and parameters used here, see the CA Librarian
publications. -OPT, -ADD, and -EMOD statements are sequence numbered
consecutively, in positions 73 through 80. JCL statements, with their own original
sequence numbers are interspersed with these in the LIBRADDS data set. If the original
sequence numbers are desired at the new site, the user must manually delete the SEQ
parameter from the -ADD statement.

-OPT and -ADD statements produced are listed on the SASSDT30-06 control report that
is produced on the file referenced by the ddname DT30CR06. The actual JCL statements
and the -EMOD statements are not listed.

Any other CA Librarian control statements can be added to this data set prior to using it
at the new site. Because CA WA CA 7 Edition does not provide update access to CA
Librarian libraries, the user must assemble whatever job is needed to add this JCL to
another CA Librarian library at the new site. To determine how this is done, see the CA
Librarian publications.

The new library at the new site and the JCLID or JCLLIB values in the JOB commands
generated for the jobs that use this JCL must be coordinated to ensure correct
definitions.

Only one such set of records is generated for any single member name no matter how
many jobs may have used this member name for their JCL.

Chapter 13: Database Transportability 411

CA Librarian JCL

SASSDT30-06 Librarian JCL Member Adds

SASSDT30-06 CA-7 DATA BASE TRANSPORTABILITY PAGE NO. 48

DATE: mm/dd/yy LIBRARIAN JCL MEMBER ADDS

*- COMMANDS GENERATED ------------------------------------------------* SEQ.-NO.

-OPT NOINDEX,NORESEQ U7003673

-ADD DUSAXX03,NOEXEC,NOLIST,NOPUNCH,SEQ=/73,8,10,10/ U7003674
-OPT NOINDEX,NORESEQ U7003676
-ADD DUSAXX07,NOEXEC,NOLIST,NOPUNCH,SEQ=/73,8,10,10/ U7003677
-OPT NOINDEX,NORESEQ U7003679
-ADD DUSAXX05,NOEXEC,NOLIST,NOPUNCH,SEQ=/73,8,10,10/ U7003680
-OPT NOINDEX,NORESEQ U7003682
-ADD DUSAXX09,NOEXEC,NOLIST,NOPUNCH,SEQ=/73,8,10,10/ U7003683

NO. OF MEMBERS ADDED- 1,228

Delete at Original Site

Each JCL member copied into the LIBRADDS data set for moving to a new site also has a
command generated into the LIBRDELS data set to assist the user in cleaning up the JCL
libraries at the original site. The command has the following format:

-DLM membername

The membername is the member name used in the database. For other requirements,
see the CA Librarian publications.

Each -DLM command generated is listed on the SASSDT30-07 control report produced
on the file referenced by the ddname DT30CR07. These commands are sequence
numbered in positions 73 through 80 in the LIBRDELS data set.

Only one command is generated for any single member name no matter how many jobs
may have used this member name for their JCL.

412 Database Maintenance Guide

 CA Panvalet JCL

Following is a sample of the SASSDT30-07 report:

SASSDT30-07 Librarian JCL Member Deletes

SASSDT30-07 CA-7 DATA BASE TRANSPORTABILITY PAGE NO. 24

DATE: mm/dd/yy LIBRARIAN JCL MEMBER DELETES

*- COMMANDS GENERATED ------------------------------------------------* SEQ.-NO.

-DLM DUSAXX01 U7001220

-DLM DUSAXX02 U7001221
-DLM DUSAXX04 U7001222
-DLM DUSAXX06 U7001223
-DLM DUSAXX08 U7001224
-DLM DUSAXX03 U7001225
-DLM DUSAXX07 U7001226
-DLM DUSAXX05 U7001227
-DLM DUSAXX09 U7001228

NO. OF MEMBERS DELETED- 1,228

CA Panvalet JCL
If the user wants to handle the movement of JCL totally external to this process, without
any of these reports or commands being produced, the JCL=N parameter should be
included in the PARM for module SASSDT20.

The discussions in this section assume that the user wants to produce reports and
commands.

More information:

Create Command Files (see page 427)

Chapter 13: Database Transportability 413

CA Panvalet JCL

Add at New Site

If a job has an execution JCL member that resides in a CA Panvalet library, a set of
records, including the JCL, is placed in the PANVADDS data set as follows:

++ADD membername,DATA
.
.
. (JCL statements go here)
.
.

The member name is the same as it was defined in the original database. The literal
DATA preserves any sequence numbers being used in the JCL statements. ++ADD
statements are sequence numbered consecutively, in positions 73 through 80. JCL
statements, with their own original sequence numbers, are interspersed with these in
the PANVADDS data set.

The ++ADD statements produced are listed on the SASSDT30-08 control report that is
produced on the file referenced by the ddname of DT30CR08. The JCL statements
themselves are not listed.

Any other CA Panvalet control statements that the user may require can be added to
this data set before using it at the new site. Because CA WA CA 7 Edition does not
provide update access to CA Panvalet libraries, the user must assemble whatever job is
needed to add this JCL to another CA Panvalet library at the new site. To determine how
this is done, see the CA Panvalet publications.

The new library at the new site and the JCLID values in the JOB commands generated for
the jobs that use this JCL must be coordinated to ensure correct definitions at the new
site.

414 Database Maintenance Guide

 CA Panvalet JCL

Only one such set of records is generated for any single member name no matter how
many jobs may have used this member name for their JCL.

SASSDT30-08 Panvalet JCL Member Adds

SASSDT30-08 CA-7 DATA BASE TRANSPORTABILITY PAGE NO. 24

DATE: mm/dd/yy PANVALET JCL MEMBER ADDS

*- COMMANDS GENERATED ------------------------------------------------* SEQ.-NO.

++ADD DUSAXX01,DATA U7001220

++ADD DUSAXX02,DATA U7001221
++ADD DUSAXX04,DATA U7001222
++ADD DUSAXX06,DATA U7001223
++ADD DUSAXX08,DATA U7001224
++ADD DUSAXX03,DATA U7001225
++ADD DUSAXX07,DATA U7001226
++ADD DUSAXX05,DATA U7001227
++ADD DUSAXX09,DATA U7001228

NO. OF MEMBERS ADDED- 1,228

Disable at Original Site

Each JCL member copied into the PANVADDS data set for moving to a new site also has
a command generated into the PANVDELS data set to assist in cleaning up the JCL
libraries at the original site. The command has the following format:

++STATUS membername,DISABLE

The membername is the member name used in the database. For the meaning of the
DISABLE parameter and any other requirements that exist for this purpose, see the CA
Panvalet publications.

Each ++STATUS command generated is listed on the SASSDT30-09 control report

produced on the file referenced by the ddname DT30CR09. These commands are
sequence numbered in positions 73 through 80 in the PANVDELS data set.

Chapter 13: Database Transportability 415

Cataloged Procedures

Only one command is generated for any single member name no matter how many jobs
may have used this member name for their JCL.

Following is a sample of the SASSDT30-09 report.

SASSDT30-09 Panvalet JCL Member Deletes

SASSDT30-09 CA-7 DATA BASE TRANSPORTABILITY PAGE NO. 24

DATE: mm/dd/yy PANVALET JCL MEMBER DELETES

*- COMMANDS GENERATED ------------------------------------------------* SEQ.-NO.

++STATUS DUSAXX01,DISABLE U7001220

++STATUS DUSAXX02,DISABLE U7001221
++STATUS DUSAXX04,DISABLE U7001222
++STATUS DUSAXX06,DISABLE U7001223
++STATUS DUSAXX08,DISABLE U7001224
++STATUS DUSAXX03,DISABLE U7001225
++STATUS DUSAXX07,DISABLE U7001226
++STATUS DUSAXX05,DISABLE U7001227
++STATUS DUSAXX09,DISABLE U7001228

NO. OF MEMBERS DELETED- 1,228

Cataloged Procedures
If the user wants to handle the movement of JCL totally external to this process, without
any of these reports or commands being produced, the JCL=N parameter should be
included in the PARM for module SASSDT20.

The discussions in this section assume that the user wants to produce reports and
commands.

More information:

Create Command Files (see page 427)

416 Database Maintenance Guide

 Cataloged Procedures

Add at New Site

Normally, PROCLIBs are not made available to CA WA CA 7 Edition because the
processing of the production workload can be done without any such direct access.
Therefore, this process makes no attempt to gain access to PROCLIBs. Movement of any
cataloged procedures that may be required at the new site must be taken care of by the
user by some other means.

See the following discussion of deleting PROCs at the original site for a hardcopy report
that can be of assistance in identifying what cataloged procedures need to be moved. If
nothing else, that report can be used as a checklist for the member names that need to
be moved. If an entire library is being moved, this level of detail is not as important to
the user.

Delete at Original Site

Any PROCs executed by the JCL for any jobs being moved are candidates for deletion at
the original site. Because the complete JCL is available to the SASSDT30 job, the JCL
records are scanned to determine which cataloged procedures (PROCs) are being used.
A table, accommodating up to 256 in-stream procedure names per job, enables the
program to distinguish between in-stream and cataloged procedures.

If the cataloged procedures are no longer needed at the original site after the jobs are
moved, the statements that are generated can be used to perform such optional
deletions.

Only one statement is generated for each procedure name no matter how many jobs or
steps execute it. These statements are generated into the DELPROCS data set and are
listed on the SASSDT30-05 control report.

Chapter 13: Database Transportability 417

Documentation

Statements are generated in IEHPROGM format as follows:

SCRATCH MEMBER=membername,VOL=vvvvvv,DSNAME=

The member name is the same as it was in the JCL EXEC statements that referenced the
PROC. The character string vvvvvv and space for a data set name value are provided in
the statements. (CA WA CA 7 Edition has no inquiry facility to determine those values
for PROCLIBs.) A value to replace the character string vvvvvv and the proper value for
the DSNAME= value must be manually provided by the user before using the generated
statements.

SASSDT30-05 PROCLIB Member Deletes

SASSDT30-05 CA-7 DATA BASE TRANSPORTABILITY PAGE NO. 24

DATE: mm/dd/yy PROCLIB MEMBER DELETES

*- COMMANDS GENERATED ------------------------------------------------* SEQ.-NO.

SCRATCH MEMBER=DUSAXX01,VOL=VVVVVV,DSNAME= U7001220

SCRATCH MEMBER=DUSAXX02,VOL=VVVVVV,DSNAME= U7001221
SCRATCH MEMBER=DUSAXX04,VOL=VVVVVV,DSNAME= U7001222
SCRATCH MEMBER=DUSAXX06,VOL=VVVVVV,DSNAME= U7001223
SCRATCH MEMBER=DUSAXX08,VOL=VVVVVV,DSNAME= U7001224
SCRATCH MEMBER=DUSAXX03,VOL=VVVVVV,DSNAME= U7001225
SCRATCH MEMBER=DUSAXX07,VOL=VVVVVV,DSNAME= U7001226
SCRATCH MEMBER=DUSAXX05,VOL=VVVVVV,DSNAME= U7001227
SCRATCH MEMBER=DUSAXX09,VOL=VVVVVV,DSNAME= U7001228

NO. OF PROCLIB MEMBERS- 1,228

Documentation
The following topics address documentation.

418 Database Maintenance Guide

 Documentation

Add at New Site

CA WA CA 7 Edition supports six categories of user-defined documentation. The
transportability process handles five of these. Any user level documentation (as defined
through the DB.4.3 panel) is not handled. User documentation that has to be moved
must be moved manually.

For each documentation member that is to be moved, a set of commands to perform

the DBM PROSE function is generated into the DBMADDS1 data set in the following
format:

PROSE
EDIT
I ,
.
. (documentation data goes here)
.
$IEND
XSEQ
SAVE
SAVE,type,membervalues,
DESC=description value ........... ,
FORM=formid,CARR=carriageid,TRAIN=trainid,COPIES=copyvalue,
REPORT=reportid
CLEAR

All commands generated are sequence numbered in positions 73 through 80. Any
documentation extending past position 72 is truncated when moved to the new CA WA
CA 7 Edition database.

The type and membervalues parameters in the second SAVE command are one of the
following based on the type of documentation being moved:

Type Parameters

System SYS,SYSTEM=systemname
DD DD,JOB=jobname,STEP=stepname,DD=ddname
Job JOB,JOB=jobname
Network NWK,NETWORK=networkname
Dataset DSN,DSN=datasetname

For a user option for DD level documentation movement, see the DDPROSE keyword in
Job 2.

Chapter 13: Database Transportability 419

Schedules

The value for a DESC keyword comes from any documentation description defined in
the database. If no documentation description exists, the DESC keyword is not
produced. To avoid any possible conflicts with batch command syntax, any commas
found in the DESC text are replaced with spaces.

Values for the FORM, CARR, TRAIN, COPIES, and REPORT fields come from any
corresponding values defined in the database. If no values were defined for these items,
the commands are not produced. Any commas found within a defined report ID value
are replaced with spaces.

Only the PROSE and SAVE,type,... commands are listed on the SASSDT30-01 control
report. The other commands are only written to the DBMADDS1 data set.

More information:

Job 2 (see page 429)

Delete at Original Site

For SYS type documentation members ONLY, the following commands are generated
into the DBMDELTS data set to delete that documentation at the original site:

PROSE
DELETE,SYS,SYSTEM=systemname

All other documentation member deletions occur automatically whenever the job, data
set, or network is deleted.

Only one set of these commands is generated for each system name. Each of these
commands is sequence numbered in positions 73 through 80 and is listed on the
SASSDT30-03 control report.

Schedules
The following topics address schedules.

Add at New Site

The following topics address changes related to job schedules, job triggers, network
triggers, data set triggers, input networks, and output networks.

420 Database Maintenance Guide

 Schedules

Job Schedules

For defined schedule IDs for those jobs being moved, a set of commands to perform the
necessary DBM SCHD,JOB function is generated into the DBMADDS2 data set as follows:

SCHD
JOB
EDIT
ADD,SCHID=nnn,ROLL=x,INDEX=>nnn,TIME=(dotm,ldtm,sbtm),
frequency values, etc. ...
.
.
SAVE
SAVE,JOB=jobname,SCAL=yy
DBM
RESOLV,SCAL=yy,TEST=NO,JOB=jobname

All of the values used here are as they were defined in the database including the Base
Calendar ID. If the same Base Calendar names are not being used at the new site, these
have to be manually edited by the user to the correct value.

Whenever multiple schedule IDs are to be added for a single job, the ADD,... sequence is
repeated as necessary, between the EDIT and SAVE commands, to define all those
schedules at one time.

These commands are sequence numbered in positions 73 through 80 and listed on the
SASSDT30-02 control report.

If the job had a current schedule modification, made with the online DB.2.7 panel
function, a message to that effect is appended to the end of the listed records on report
SASSDT30-02. Any such changes have to be investigated and reapplied manually at the
new site after this schedule is defined in that database.

Job Triggers

For each job referenced as a triggered job by any of the jobs being moved, a set of
commands to perform the DBM SCHD,JTRG function is generated into the DBMADDS2
data set as follows:

SCHD
TRGR
UPD,JTRG,JOB=jobname,OPT=A,SCHID=nnn,TJOB=triggeredjob [,TRGID=nnn]
[,DOTM=hhmm] [,QTM=hhmm] [,LEADTM=hhmm] [,SBTM=hhmm]

The UPD command sequence is repeated as necessary, following the SCHD and TRGR
commands, to accommodate all jobs triggered by the same job.

These commands are sequence numbered in positions 73 through 80 and are listed on
the SASSDT30-02 control report.

Chapter 13: Database Transportability 421

Schedules

Network Triggers

Whenever a CPU job being moved indicates that it is triggered by a workstation

network, a set of commands to perform the SCHD,NTRG function is generated into the
DBMADDS2 data set as follows:

SCHD
TRGR
UPD,NTRG,NWK=networkname,OPT=A,SCHID=nnn,TJOB=triggeredjob
[,DOTM=hhmm] [,QTM=hhmm] [,LEADTM=hhmm] [,SBTM=hhmm]

The commands are sequence numbered in positions 73 through 80 and are listed on the
SASSDT30-02 control report.

Data Set Triggers

For each job shown as triggered by any data set accessed by any of the CPU jobs moved,
a set of commands to perform the necessary SCHD,DTRG function is generated into the
DBMADDS2 data set as follows:

SCHD
TRGR
UPD,DTRG,DSN=datasetname,OPT=A,SCHID=nnn,TJOB=triggeredjob [,TRGID=nnn]
[,DOTM=hhmm] [,QTM=hhmm] [,LEADTM=hhmm] [,SBTM=hhmm]

Because this process only moves jobs that are either explicitly requested or required by
those jobs and within one level of those requested, this could produce commands that
trigger some jobs that were not intended to be moved and may not have a job definition
generated by this process. To prevent unsuccessful updates, the user has to verify the
accuracy of this before trying to use the generated commands at the new site.

These commands are sequence numbered in positions 73 through 80 and are listed on
the SASSDT30-02 control report.

422 Database Maintenance Guide

 Schedules

Input Networks

For each input workstation network being moved to the new site, each schedule ID
defined has a set of commands generated into the DBMADDS2 data set to perform the
SCHD,INWK and RESOLV functions. These commands are in the following format:

SCHD
INWK
EDIT,NETWORK=networkname
ADD,SCHID=nnn,TIME=(dotm1,ldtm1,dody1,dotm2,...),
frequency values, etc. ...
.
.
SAVE
SAVE,NETWORK=networkname,SCAL=yy,ROLL=x,INDEX=>nnn
DBM
RESOLV,SCAL=yy,TEST=NO,NW=NW.networkname

Also, a DB.2.7 warning message sometimes appears on the control report, which we
discussed previously.

The ADD commands are repeated as many times as necessary between the EDIT and
SAVE commands to accommodate all schedule IDs to be defined. All parameter values
used are as they were defined in the original database including the Base Calendar ID
that the schedule references. If the Base Calendar ID at the new site is different, these
commands have to be manually edited to the correct value before being used.

Input network triggers are added.

Each command is sequence numbered in positions 73 through 80 and is listed on the

SASSDT30-02 control report.

More information:

Job Schedules (see page 421)

Chapter 13: Database Transportability 423

Schedules

Output Networks

For each output workstation network being moved, a set of commands to perform the
necessary SCHD,ONWK function is generated into the DBMADDS2 data set as follows:

SCHD
ONWK
EDIT,NETWORK=networkname
ADD,SCHID=nnn,TIME=(dotm1,ldtm1,dody1,dotm2,...)
.
.
SAVE
SAVE,NETWORK=networkname

The ADD command may be repeated, between the EDIT and SAVE commands, as many
times as necessary to define all of the schedule IDs that existed in the original database.

Each command is sequence numbered in positions 73 through 80 and is listed on the

SASSDT30-02 control report.

Delete at Original Site

The following topics discuss deleting at the original site.

Job Schedules

Because the schedules for jobs are automatically deleted whenever the job definition is
deleted from the database, this process generates no additional commands to delete
job schedules.

More information:

Disable at Original Site (see page 403)

Input Network Schedules

Because the schedules for input workstation networks are automatically deleted
whenever the network definition is deleted from the database, no additional commands
are needed to delete them.

Output Network Schedules

Because output networks are scheduled whenever their associated CPU job is
scheduled, no extra commands are necessary.

424 Database Maintenance Guide

 Node and Access File

More information:

Job Schedules (see page 421)

Node and Access File

Each XPJOB job that is selected for transport has its OWNER and XP NODE information
written to the VRMXREFS data set. The output has the following format:
Nxxxxx
Identifies the node name.
ONxxxxx
Identifies the node name.
OOxxxxx
Identifies the owner.

The N, ON, and OO prefixes indicate the record type in the database. These records are
used during the VRM database extract to generate transport transactions for Node
records (created using the XNODE command) and access records (created using the
XPSWD command). This is discussed in detail later in this section.

Each cross reference record is listed on the SASSDT30-10 control report produced on the
file referenced by the ddname DT30CR10. Following is a sample of the SASSDT30-10
report.

SASSDT30-10 VRM Cross Reference Entries

SASSDT30-10 CA-7 DATA BASE TRANSPORTABILITY PAGE NO. 1

DATE: 8/11/yy VRM CROSS REFERENCE ENTRIES
*- COMMANDS GENERATED ------------------------------------------------* SEQ.-NO
NTESTPLN U7000001
ONTESTPLN U7000002
OOCHRIS U7000003
NBNODE2 U7000004
ONBNODE2 U7000005
OOPAT U7000006
NCNODE1 U7000007
ONCNODE1 U7000008
OOSAM U7000009

Chapter 13: Database Transportability 425

Agent DIV File

Agent DIV File

AGJOB jobs that are selected for transport may also have selected information written
to the AGENTDIV data set. This only occurs if the USER field in the Agent job is not blank.
In these situations, the Jobname, Agent Job Type, Agent, and User (as seen on the DB.11
panel) are written to the AGENTDIV data set as a single line.

This file lets your site's security administrator cross reference this information with
security records that may have been added using the AGPSWD command. Agent jobs
typically require a User ID and Password to run on the remote platform. CA WA CA 7
Edition uses the AGPSWD command to define these entities. Site personnel who have
authority to issue the AGPSWD command must manually set up these security
definitions on the CA WA CA 7 Edition instance to which agent jobs are being
transported. We recommend using the AGENTDIV file output to assist in determining
what security definitions are required.

In addition, for each record written to the AGENTDIV file, three lines are written to the
SASSDT30-11 control report that is referenced by ddname DT30CR11:
■ The first line contains the job name, agent job type, and agent.
■ The second line contains the first 64 characters of the User field.
■ The third line contains the last 64 characters of the User field or blanks.

Following is a sample of the SASSDT30-11 report.

SASSDT30-11 Agent Jobs DIV File XREF

SASSDT30-11 CA-7 DATA BASE TRANSPORTABILITY PAGE NO. 1

DATE: mm/dd/yy AGENT JOBS DIV FILE XREF

*- COMMANDS GENERATED ------------------------------------------------* SEQ.-NO.

CA750003 UNIX_JOB UNIXAGENT U7000001
userid0003000000000000000000000000000000000000000000000000000003 U7000002
0000000000000000000000000000000000000000000000000000000000000003 U7000003
CA750006 UNIX_JOB UNIXAGENT U7000004
userid0006000000000000000000000000000000000000000000000000000006 U7000005
U7000006

426 Database Maintenance Guide

 Create Command Files

Create Command Files

The transportability process consists of multiple steps. It could be done with a single job.
The user probably wants to develop multiple jobs, however, so that the processing can
be manually verified between each of the three major iterations against the database.

During CA WA CA 7 Edition installation, the CA WA CA 7 Edition SYSGEN created three

jobs: CA07N810, CA07N820, and CA07N830, which can be used for CA WA CA 7 Edition
transportability processing.

The following discussions and examples assume that the user uses three different jobs
to perform this process. JCL parameters that require special consideration are indicated
in lowercase notation in the JCL examples. Unless unusually large numbers of jobs,
quantities of documentation, and numbers of networks are being moved, the space
allocations in the examples should be sufficient.

Before running any of the jobs, be sure to set the NLINE value in the TERM statement
for the batch terminal being used to the maximum value. This minimizes the number of
headings (and DASD space) required during the iterations of this process.

Note: For more information about this initialization file parameter, see the Systems
Programming Guide.

More information:

Special Considerations (see page 434)

Job 1
Refer to the CA07N810 JCLLIB member (from the SYSGEN process) for a sample JCL
member. The job has two steps.

The first step of this job is a standard BTI step.

Note: For more information about this step, see "Using Batch Terminals" in the Interface
Reference Guide.

Chapter 13: Database Transportability 427

Create Command Files

PARM Keywords

A CA WA CA 7 Edition operator ID should be provided in the PARM data in the last step.
A password can also be given. The format of the value for LOGON= is the same as it is
for the /LOGON command to CA WA CA 7 Edition, including the comma that separates
the operator ID and any password value being provided. Operator ID can be up to eight
characters in length. A maximum total of 65 characters is allowed for the operator ID,
the password value and the comma that separates them. Any characters following the
operator ID, and until a valid keyword (or end of PARM) is found, are assumed to be
password data.

The LOGON keyword is optional. The default operator ID is MASTER in the generated
/LOGON command and the command does not have a password value in it. If LOGON= is
entered with no data following the equal sign, the /LOGON command is generated
without an operator ID or a password.

If no LOGON value is provided or defaulted, the operator ID, and optionally the
password field, has to be provided manually, in the DT10OUT data set, before that
output data set can be processed by BTI (for SASSDT20).

Specifying Jobs to Move

The input to the BTI run is in the form of CA WA CA 7 Edition LJOB and/or LSYS
commands. They may be used in any combination to define the jobs to be moved. If any
workstation networks are to also be moved, the programs automatically include those
with a predecessor or successor relationship with any of the jobs specified. If others are
not connected to a job, they must be moved manually by the user.

Requirements for /LOGON and /LOGOFF commands are the same here as for any BTI
data set and must be supplied in addition to any LJOB or LSYS commands.

If the LSYS command is used, every job in the database with the same system name as
that indicated has commands generated to define the jobs into another database. This
assumes that the optional system name was entered for each of the desired jobs when
they were defined in the database. It may be safer to use the LJOB command with a
generic job name because job names are required in the database. Job naming
conventions usually make generic specification of the desired names relatively easy.
Multiple commands can be used as necessary to define all of the desired jobs.

Jobs that have any type of predecessor or trigger relationship with any of the jobs being
moved are also included in the final output command data sets produced by this
process. That is made possible by the look-aside process that enables automatic
inclusion of workstation networks. This look-aside process only looks one level in each
direction from a job that was requested to be moved.

428 Database Maintenance Guide

 Create Command Files

More information:

Workstation Networks (see page 404)

Data Sets Used/Created

The SYSPRINT output is passed to the second step as that its input.

The second step examines the output from the BTI step and generates another
card-image BTI data set through ddname DT10OUT. This data set is the input to Job 2.
The SASSDT10-01 control report is produced through the ddname DT10CR01. The report
can help determine whether this step ran correctly.

Job 2
After you verify that the jobs were identified correctly in Job 1, you can run Job 2.

Refer to the CA07N820 JCLLIB member (from the SYSGEN process) for a sample JCL
member. The job also has two steps.

This job performs another iteration against the database much like the first job. The
commands in the SYSIN data set for SASSBSTR produce listings for JCL, trigger, and
requirement information for each of the jobs to move. Module SASSDT20 examines the
BTI output (ddname DT20IN) and produces another card-image data set to be used in
Job 3 (ddname DT20OUT).

Chapter 13: Database Transportability 429

Create Command Files

PARM Keywords

A LOGON value should be provided in the PARM data for SASSDT20. This PARM value
has the same format and meaning as discussed for SASSDT10 in Job 1.

The user also has an option available that can significantly reduce the DASD
requirements and slightly reduce the runtime. If the user does not use DD level
documentation, as defined with the PROSE,DD online panel, DDPROSE=N should be
specified in the PARM data. N is the only acceptable value.

Without this specification, the program produces an LPROS command for each nonblank
stepname/ddname combination just to determine if any DD level documentation exists.
Such unnecessary commands can represent as much as 85 percent or more of the
number of commands needed to accomplish any one move. (Because it takes very little
time for each of these commands to execute, the elapsed time savings are negligible
compared to the DASD savings.) If the extra DASD space and runtime are of no
particular concern, DDPROSE=N should not be specified. This ensures that any such
existing documentation is included in the data being moved.

The user also has the option to ignore totally the movement of JCL, XPJOB PARM data,
or AGJOB PARM data. Code the parameter JCL=N in the PARM data for module
SASSDT20 to accomplish this. N is the only acceptable value. With this option specified,
JCL and PARM data are ignored here, and the user must handle the movement of these
elements totally external to this process. JCL=N in this job suppresses all of the JCL and
PARM data related reports and command data sets in Job 3 as well. It may be wise to
run these three jobs once without this option just to get the reports and again later with
this option if necessary.

More information:

Job 1 (see page 427)

Data Sets Used/Created

DT20WORK is a work file that SASSDT20 uses. The file must not have a DISP of MOD.

DATASETS contains one card-image record for each application data set name being
moved with the name beginning in position 1 of the record. (This data set can be useful
for producing sorted data set checklists to help with the physical movement of data sets
to the new site.)

The SASSDT20-01 control report (DT20CR01) can be used to verify accuracy before
running Job 3.

After you verify that Job 2 ran correctly, you can run Job 3.

430 Database Maintenance Guide

 Create Command Files

Job 3
Refer to the CA07N830 JCLLIB member (from the SYSGEN process) for a sample JCL
member. The job has two steps.

This job performs another iteration against the database, much like the first two jobs.
The commands in the SYSIN data set, from Job 2, produce listings for other database
elements that are to move. The user can also have manually included some LNTWK and
LPROS commands to include some workstation networks that did not have an explicit
connection to any of the jobs being moved. SASSDT30 examines the BTI output
(DBMLISTS) and creates several command data sets.

PARM Keywords

A LOGON value should be provided in the PARM data for SASSDT30. This keyword value
has the same format and meaning as that discussed for SASSDT10 in Job 1.

The user also has the following optional keywords that can be provided in the PARM for
the purposes indicated:
JOBDD=Y
Specifies to generate JOB deletes with the function value of DD instead of DELETE
so that dormant data sets can be deleted when the job is deleted. DD commands
require more execution time than DELETE commands whenever they are processed
against the database to do the actual deletes. This time could be significant if a
large number of commands are processed at once.
Note: For more information about this function, see the job definition panels.
Y is the only acceptable value.
AFTER=yyddd[hhmm]
Specifies "don't schedule after" values to use for the disable commands generated
to disable jobs at the original site. If not provided, the current system date and time
are used for this purpose. If only the Julian date is provided, the default time-of-day
is zeros (for the morning of the date entered).
Note: For more information about this function, see the job definition panels.

Chapter 13: Database Transportability 431

Create Command Files

BEFORE=yyddd[hhmm]
Specifies "don't schedule before" values to use for the add commands generated to
add jobs at the new site. If not provided, no value is generated and the work is
eligible to run at the new site as soon as it is completely defined in that database. If
only the Julian date is provided, the default time-of-day is zeros (for the morning of
the date entered).
Note: For more information about this function, see the job definition panels.
LOADS=Y
Specifies that LOAD commands are to be generated for each CPU job. When
specified, LOAD commands are generated into the DBMADDS2 data set after the
JCL has been processed for the job. This parameter cannot be used if JCL=N was
specified in Job 2 because that specification prevents any JCL from appearing in the
input to this job. (If necessary, multiple executions of this process could be run to
create the desired command data sets.) Y is the only acceptable value.
NODSNS
Specifies that DSN ADD commands are not generated in the output of this run. This
parameter can be used if data set definitions are not required at the receiving site.
By default, data set ADDs are generated.
DFLTOVRD=Y
Generates explicit keyword/value pairs (with default values) for most job definition
panel fields (see the following Exclude List).
Typically, explicit keyword/value pairs for job definition panel fields (and their
values) are not generated if the value specified matches the default value.
Generation of explicit keyword/value pairs is useful when the receiving CA WA CA 7
Edition system's DEFAULTJOB/DEFAULTXPJ/DEFAULTAG (see the DBASE
initialization statement) settings are different from the sending system's settings,
and the original job definition settings are still wanted. Y is the only acceptable
value for this parameter.
Exclude List: LIB, USE-OVR-LIB, SATISFACTION LEAD TIME (JOB & DSN), COND-CODE,
RO, DON'T SCHEDULE BEFORE/AFTER, LTERM, MSGCLASS.

More information:

Job 1 (see page 427)

DB.1 - CPU Job Definition Panel (see page 34)

432 Database Maintenance Guide

 Create Command Files

Command Data Sets

Module SASSDT30 examines the BTI output (through ddname DBMLISTS) and produces
card-image data sets containing the commands needed to accomplish the move. One
control report is produced for each of the command data sets. The following are the
data sets being created:

DDname Commands Report

DBMADDS1 DBM add commands - Part 1 DT30CR01
DBMADDS2 DBM add commands - Part 2 DT30CR02
DBMDELTS DBM delete commands DT30CR03
DBMSTOPS DBM disable commands DT30CR04
DELPROCS SCRATCH commands for PROCs DT30CR05
LIBRADDS CA Librarian JCL add modules DT30CR06
LIBRDELS CA Librarian delete commands DT30CR07
PANVADDS CA Panvalet JCL add modules DT30CR08
PANVDELS CA Panvalet disable commands DT30CR09
VRMXREFS VRM cross-reference entries DT30CR10
AGENTDIV Agent Jobs DIV File XREF DT30CR11

Details on the contents of these data sets and the examples of these control reports
were given previously.

It is very likely that some of these data sets require some manual editing and changing
before they can be used. For example, changing JCLID numbers must be taken care of by
editing these data sets. The control reports closely mirror the contents of the data sets,
including the generated sequence numbers. This makes it easier to locate specific
commands requiring changes.

The card-image data sets must be preserved as necessary for subsequent use at
whatever site is to process the commands.

DT30WORK is a work file used by SASSDT30. It must not have a DISP of MOD (the file is
opened and closed multiple times).

If no CA Panvalet or CA Librarian JCL is being used, those data sets and their control
reports may be DUMMYed or defined as NULLFILEs.

Chapter 13: Database Transportability 433

Special Considerations

More information:

Assumptions (see page 387)

Moving Jobs (see page 397)
Workstation Networks (see page 404)
Run at New Site (see page 436)

Special Considerations
Keep the following special considerations in mind during this process.

Design Limitations
The transportability process uses internal tables to keep from duplicating definition of
jobs, networks, and other items in the final output. These tables also ensure that a
minimum of commands are issued during the intermediate steps of this process.

Each of the three modules executed in the three jobs that constitute this process uses
tables for these purposes as follows:

Module Maximum# Component

SASSDT10 50,000 Job names
SASSDT20 5,000 Application system names
SASSDT20 50,000 Job names
SASSDT20 10,000 Workstation network names
SASSDT20 300,000 CA WA CA 7 Edition assigned data set numbers
SASSDT30 50,000 Execution JCL member names
SASSDT30 50,000 Cataloged procedure names
SASSDT30 256 In-stream procedures (maximum per job)

434 Database Maintenance Guide

 Special Considerations

All but one of these limits apply to the entire workload definition being moved. The only
exception is the limit of in-stream procedures, in SASSDT30, which is the maximum
number within any one execution JCL member. (This table is used to distinguish
between cataloged procedures and in-stream procedures.)

If any of these limitations are insufficient for any particular move, the user could:
■ Break it up into multiples of this process by only requesting a number of jobs that
does not exceed these limits, or
■ Make the coding changes to the programs for the appropriate values.

Add to the New Database

Once the appropriate command data sets have been physically taken to the new site,
the DBM adds (parts 1 and 2) must be processed by CA WA CA 7 Edition at that site. Any
JCL libraries for CA Panvalet or CA Librarian JCL also must be processed at that site.
Either a batch terminal job or a batch execution of CA WA CA 7 Edition could be used to
accomplish this. If using the batch execution of CA WA CA 7 Edition, see the Systems
Programming Guide for batch execution procedures.

Note: The DBMADDS1 and DBMADDS2 data sets must be processed in the correct
sequence. If DBMADDS1 is not processed first, all of the commands in DBMADDS2 are
rejected with error messages.

The user should review the amount of available space in the database at the new site
before attempting to add the new jobs. Comparing job counts and space allocations at
both sites, prior to performing this process, gives the user some idea of how much more
space, if any, is needed. This probably was already done when the initial plans were
being made for the movement of the workload to the other center. For guidelines about
calculating space requirements in the database, see the Systems Programming Guide.

Depending on the number of jobs, documentation lines, and other items being moved,
the volume of output from DBM when the commands are processed at the new site
could be very large. Normal batch terminal allocations would probably not be large
enough to hold all of this. Because documentation is added one record at a time, with a
response back after each line in batch, this process alone can require a large allocation.

The output from the maintenance against the new database should be carefully
reviewed for accuracy of definitions. Duplicates become obvious. Users must resolve
any duplication of names for jobs, networks, and other items manually.

Chapter 13: Database Transportability 435

Virtual Resource Management Database Extracts

Run at New Site

The work is eligible to be scheduled at the new site as soon as the work and its
schedules are completely defined in the database. If any delay is desired, the commands
for the jobs can include the "don't schedule before" parameters, BDATE and BTIME, to
accomplish this for jobs (not networks).

The user can provide this either by:

■ Using the BEFORE keyword in the PARM for Job 3, or
■ Manually editing the desired values into the generated records prior to adding the
work to the database.

Mass Changes at Existing Site

Even though the database transportability programs were developed to assist with the
transfer of work from one site to another, it can also be used to perform mass or global
changes at an existing site.

To accomplish such changes the desired work is identified by LJOB and LSYS commands,
as described in preceding sections, and the three jobs are run as indicated. Then desired
changes are made to the command files (DBMADDS1 and DBMADDS2). Such changes
could be renaming of jobs, systems, and data sets or just changing certain job options.
Next the ADD functions would be changed to UPD if not changing job or data set names
and any unnecessary commands deleted. Finally, a BTI job would process the command
files to apply the changes to the existing database.

After all changes are verified, use the DBMSTOPS or DBMDELTS to remove any obsolete
references.

Virtual Resource Management Database Extracts

The Virtual Resource Management (VRM) Database Transportability facility allows the
selection of jobs with connected resources from the database. It also selects node and
access resources that match node and access records that the SASSDT30 program
extracted. Three files, each containing a set of CA WA CA 7 Edition Batch Terminal
Interface commands in a fixed-block file format, are generated for transporting
information to a different database.

During the installation, the SYSGEN process created three jobs in the JCLLIB: CA07N840,
CA07N841, and CA07N845, which can be used for VRM database transportability
processing.

436 Database Maintenance Guide

 Virtual Resource Management Database Extracts

VRM DBT Program

The SASSDT60 program reads the VRM components and selects jobs based on
user-specified criteria. The program creates a DT60ADDS file that contains the CA WA
CA 7 Edition Batch Terminal Interface commands required to add the job to resource
connections to a different database. In addition to the Batch Terminal Interface
command file, a job selection report SASSDT60-01 is generated to report on any or all
jobs selected for this run.

The following is a SASSDT60-01 VRM Job Extract report sample:

SASSDT60-01 CA-7 DATA BASE TRANSPORTABILITY PAGE NO. 00001

DATE: 10/22/yy VRM JOB EXTRACT REPORT

JOBNAME RESOURCE NAME SCHED-ID STEPNAME USAGE FREE-TYPE

PAYROLL1 PAYROLL.INCOME.DATA 001 JS30 EXC SUCCESSFUL COMPLETION OF JOB STEP

SYS1.PAYROLL.DATA 002 SHR ALWAYS FREE RESOURCE
SYSX.TEST.SAMPDATA 000 ACCNT EXC FREE RESOURCE MANUALLY
SYS2.TABLE.DATA 000 JS60 SHR ALWAYS FREE RESOURCE
SYS3.VAULT.TAPE 000 UPDATE1 EXC ALWAYS FREE RESOURCE
PAYROLL.FILES.PAYCHECK 200 NODATA EXC ABNORMAL TERMINATION
PAYROLL2 SYS1.TEST1.DATA 000 JS10 SHR ALWAYS FREE RESOURCE
SYS1.TEST2.DATA 000 EXC ALWAYS FREE RESOURCE
SYS2.DDE.TEST.DATA 000 INCOME10 SHR ABNORMAL TERMINATION
SYSX.TEST.PROCS 000 SHR ALWAYS FREE RESOURCE
SYS4.USERS.DATA 000 SHR ALWAYS FREE RESOURCE
CAI.TEST.DATASET 000 JS100 EXC SUCCESSFUL COMPLETION OF JOB STEP
SYS1.VARS.SMAP.DASD.CHECKS 000 SHR SUCCESSFUL JOB COMPLETION
PAYROLL3 TL6642.TEST.DATA.PAY3 238 JS20 EXC SUCCESSFUL COMPLETION OF JOB STEP
SYSX.PROCS.USER.DATA 000 JS30 SHR ALWAYS FREE RESOURCE
SYS1.TEST.BENCH.DATA 000 EXC ABNORMAL TERMINATION
TL6642.PDS.TEST.DATA 238 JS1000 EXC ABNORMAL TERMINATION
SYS4.TEMP.FILEX 000 SHR FREE RESOURCE MANUALLY
PAYROLL4 HELP.TEMP.DATASET1 000 JS10 EXC SUCCESSFUL COMPLETION OF JOB STEP
HELP.TEMP.DATASET2 000 JS20 EXC SUCCESSFUL COMPLETION OF JOB STEP
SYS1.DUMPIT.DATA.TEMP.DATA 000 SHR ABNORMAL TERMINATION
SYSX.TL6642.HELP 000 JS30 SHR FREE RESOURCE MANUALLY
SYS2.SYS2.SYS2.SYS2.SYS2 000 EXC ABNORMAL TERMINATION
PAYROLL6 CICSREG1 000 STEP0099 ASX FREE RESOURCE MANUALLY
PAYROLL7 CICSREG8 000 ASX RESOURCE MUST BE INACTIVE
DB2 000 CRQ RESOURCE MUST BE INACTIVE

TOTAL JOB RECORDS EXTRACTED .... 00006

VRM DBT Job Extract JCL

The JCL is found in the SYSGEN’ed JCLLIB member CA07N840, The first step in Virtual
Resource Management Database Transportability is the execution of the SASSDT60
program.

Chapter 13: Database Transportability 437

Virtual Resource Management Database Extracts

PARM Keywords

The SASSDT60 program accepts two PARM values. The first parameter, REPORT
indicates that this is a report run only. The DT60ADDS file will not be generated;
however, a report will be produced. The SASSDT60-01 VRM Job Extract Report displays
the jobs and resource connections for the CA WA CA 7 Edition Batch Terminal Interface
commands that would have been generated if this had been an actual run.

The second parameter, ALLJOBS indicates that all jobs and their associated resource
connections will be extracted for this run. This allows bypassing the selection of specific
jobs using the SYSIN DD control cards. If the ALLJOBS PARM is coded, any control cards
found in the SYSIN DD are ignored.

The following are PARM examples:

//jobname job ..........

// EXEC PGM=SASSDT60,PARM='REPORT'

//jobname job ..........

// EXEC PGM=SASSDT60,PARM='REPORT,ALLJOBS'

SYSIN Control Cards

The SYSIN DD * file in the JCL allows selection of a specific job from the database. The
keyword JOB= is used to specify a fully qualified or generic job name. A generic job
name can be specified by coding an asterisk (*) on the trailing end of the qualifying job
name characters. At least one character is required. Comments may be included in the
SYSIN DD file by coding an asterisk in the first column (col 1). The number of control
cards that can be specified has no limit.

The following are SYSIN DD control card examples:

//SYSIN DD *
*
* Comment card (asterisk column 1)
*
* The following control card selects any job with the
* first three characters of PAY.
JOB=PAY*
*
* The following control card selects job TESTJOB1 only.
JOB=TESTJOB1
*
* The following control cards selects any job which begins
*with the letter Z.
JOB=Z*

438 Database Maintenance Guide

 Virtual Resource Management Database Extracts

Data Sets Used/Created

DBPARMS
These parameters describe your CA Datacom/AD database.
DT60ADDS
This file is the generated Batch Terminal Interface commands file. This file is used as
input into a CA WA CA 7 Edition BTI job to add the job to resource connections on a
different database.
SYSIN
This file contains the control cards that are used to specify which jobs are extracted
for this run.
JOBREPT
This file is the SASSDT60-01 VRM Job Extract Report file.

Note: The second step of the VRM Database Transportability process is to run a Batch
Terminal Interface job. The job uses the generated DT60ADDS file as SYSIN input to add
the job to resource connections on the target database.

The SASSDT60 program does not generate commands to define the number of available
resource count resources at the receiving site. To generate the commands manually, use
the RM.7 panel.

Chapter 13: Database Transportability 439

VRM Node and Access Transport Program

VRM Node and Access Transport Program

The SASSDT62 program is used to select node and access records that match the node
and access records extracted by the SASSDT30 program. The program creates two files.
The DT62NODE file contains the CA WA CA 7 Edition Batch Terminal Interface
commands required to add node resources to a different database. The DT62XPWD file
contains the commands required to add the access resources. Examples of both files are
shown in the following:

XNODE
ADD,XP63N01,
ALT1=AL6301,
ALT2=AL6301,
DES=TEST DESCRIPTION FOR NODE6301,
STATE=ONLINE

XPSWD
ADD,
NODE=XP63N01,
XPUSER=XP63U01,XPDMN=XP63D01
ADD,
OWNER=XP63O01,XPUSER=XP63U01,XPDMN=XP63D01

Note: STATE is always set to ONLINE, regardless of the setting in VRM.

VRM Node and Access Extract JCL

Sample JCL for this extract is found in the SYSGEN JCLLIB as member CA07N841.

440 Database Maintenance Guide

 VRM Node and Access Transport Program

PARM Keywords
The SASSDT62 program accepts one PARM value, which is not required. A value of
REPORT indicates that this is a report run only.

A value of PASSWORD indicates that encrypted password information is to be included

in the BTI transactions, assuming the records have associated passwords (the password
is not required when adding records with the CA WA CA 7 Edition XPSWD command).

If neither parameter is specified, the BTI transactions are created without password
information. Thus, you must specify the PASSWORD parameter if you wish to transport
associated password information.

Password information is never displayed in the reports, regardless of the PARM setting.

The following are PARM examples:

//jobname job
// EXEC PGM=SASSDT62,PARM='REPORT'

//jobname job
// EXEC PGM=SASSDT62,PARM='PASSWORD'

Data Sets Used/Created

The following data sets are used and created during the SASSDT62 process:
SORTIN
This file contains the cross-reference records generated during the SASSDT30
program execution and written to the VRMXREFS DD statement.
DBPARMS
These parameters describe your CA Datacom/AD database.
DT62NODE
This file is the generated Batch Terminal Interface commands file for the node
entries. This file is used as input into a CA WA CA 7 Edition BTI job to add the node
resource definitions on a different database.

Chapter 13: Database Transportability 441

VRM Node and Access Transport Program

DT62XPWD
This file is the generated CA WA CA 7 Edition Batch Terminal Interface commands
file for the node and owner access entries. This file is used as input into a CA WA CA
7 Edition BTI job to add the node and owner access resource definitions on a
different database.

Note: The final step of the VRM Database Transportability process is to run a Batch
Terminal Interface job (CA07N845). This job consists of two steps. The first step adds the
VRM records created in SASSDT60. The second step adds node records (DT62NODE) and
access records (DT62XPWD).

The Batch Terminal Interface mimics the interactive CA WA CA 7 Edition commands. The
XNODE command (DT62NODE) is processed to add node records. The XPSWD command
(DT62XPWD) is processed to add owner and node access records. Node access records
contained in the DT62XPWD file cannot be added when a corresponding node record
does not exist. Thus, the DT62NODE file must run through the Batch Terminal Interface
first.

Output Reports
SASSDT62 processing can produce the following reports:

NODEREPT is the SASSDT62-01 XPJOB Entries with Matching Node Records report file.

SASSDT63- 1 CA-7 DATA BASE TRANSPORTABILITY PAGE NO. 1

DATE: 08/30/yy XPJOB Entries with Matching Node Records

Primary Node Description

Alternate Node 1 Alternate Node 2
XP63N01 DESCRIPTION FOR NODE6301
AL6301 AL6301

NODPREPT is the SASSDT62-02 XPJOB Entries with Matching Node Access Records
report file.

SASSDT63- 2 CA-7 DATA BASE TRANSPORTABILITY PAGE NO. 1

DATE: 08/30/yy XPJOB Entries with Matching Node Access Records

Node User ID Domain

XP63N01 XP63U01 XP63D01
XP63N02 XP63U02 XP63D01

442 Database Maintenance Guide

 Automated Recovery Facility Database Extracts

OWNPREPT is the SASSDT62-03 XPJOB Entries with Matching Owner Access Records
report file.

SASSDT63- 3 CA-7 DATA BASE TRANSPORTABILITY PAGE NO. 1

DATE: 08/30/yy XPJOB Entries with Matching Owner Access Records

Owner User ID Domain

XP63O01 XP63U01 XP63D01
XP63O02 XP63U02 XP63D01
XP63O03 XP63U03 XP63D01

NMTCHRPT is the SASSDT62-04 XPJOB Entries with No Matching Node or Access

Records report file.

SASSDT63- 4 CA-7 DATA BASE TRANSPORTABILITY PAGE NO. 1

DATE: 08/30/yy XPJOB Entries with No Matching Node or Access Records

No matching Node record found for XP63N100

No matching Node record found for XP63N101
No matching Access record found for Node XP63N100
No matching Access record found for Node XP63N101
No matching Access record found for Owner XP63O101
No matching Access record found for Owner XP63O102

Automated Recovery Facility Database Extracts

The Automated Recovery Facility (ARF) Database Transportability facility is used to
extract ARFSET information from the database and generates Batch Terminal Interface
commands, in a fixed file format, for transport to a different database.

During CA WA CA 7 Edition installation, the CA WA CA 7 Edition SYSGEN created two

jobs: CA07N850 and CA07N855, which can be used for database transportability
processing.

The SASSDT70 program is used to read the database and extract ARFSET information
based on user-specified criteria. The program creates a DT70ADDS data set that
contains the CA WA CA 7 Edition Batch Terminal interface commands required to add
the ARFSET definitions to a different database component. Besides the DT70ADDS files,
an ARFSET selection report SASSDT72-01 is generated.

Chapter 13: Database Transportability 443

Automated Recovery Facility Database Extracts

The following is a SASSDT72-01 ARFSET Extract report sample:

SASSDT72-01 CA-7 DATA BASE TRANSPORTABILITY PAGE NO. 00001

DATE: 9/30/20yy ARFSET EXTRACT REPORT
----------------------------------------------------------------------------------------------------------------------------
ARFSET NAME UID RESPONDER
ARFTST01 000 MASTER
DEFINITION INDEX
001
TYPE SYSTEM REL OPR SCHID REL OPR RESTART COUNT REL OPR ENTRY MODE REL OPR
JC * EQ 000 EQ 000 GE * EQ
FROM DATE FROM TIME TO DATE TO TIME
01011975 0001 12312074 2359
- JOB COMPLETION CHECK -
PROCEDURE PROC REL OPR STEP STEP REL OPR PROGRAM PGM REL OPR COND TYPE COND REL OPR VALUE MASK
* EQ * EQ * EQ CC GE 0004

RESPONSE:
COMM MODE USERID MESSAGE TEXT
L USER015 JC - JOB COMPLETION CHECK
RESPONSE:
COMM MODE USERID MESSAGE TEXT
L USER015 JC - JOB COMPLETION CHECK
RESPONSE:
COMM MODE USERID MESSAGE TEXT
L USER015 SYSTEM=&SYSTEM SCHDID=&SCHDID JES#=&JES#
FINAL DISPOSITION
NO ACTION TAKEN
CA-11 BYPASS GDG USAGE PROCESS COND CODE START STEP END STEP
N N
----------------------------------------------------------------------------------------------------------------------------
ARFSET NAME UID RESPONDER
ARFTST02 000 MASTER
DEFINITION INDEX
001
TYPE SYSTEM REL OPR SCHID REL OPR RESTART COUNT REL OPR ENTRY MODE REL OPR
JC * EQ 000 EQ 000 GE * EQ
FROM DATE FROM TIME TO DATE TO TIME
01011975 0001 12312074 2359

ARF DBT Extract JCL

Sample JCL for the ARF data extraction is found in SYSGEN JCLLIB member CA07N850.
The first step in the ARF database transportability process is to extract ARFSETs from the
database.

444 Database Maintenance Guide

 Automated Recovery Facility Database Extracts

PARM Keywords

The SASSDT70 program accepts two parameter values. The first parameter, REPORT,
indicates that this is a report run only. The DT70ADDS file will not be generated;
however, a report will be produced. The SASSDT72-01 ARFSET Extract Report displays
the ARFSET definitions for the CA WA CA 7 Edition Batch Terminal Interface commands
that would have been generated if this had been an actual run.

The second parameter, ALLSETS indicates that all ARFSETs will be extracted for this run.
This allows bypassing the selection of specific ARFSETs using the SYSIN DD control cards.
If the ALLSETS PARM is coded, any control cards found in the SYSIN DD are ignored.

//jobname job ..........

// EXEC PGM=SASSDT70,PARM='REPORT'

//jobname job ..........

// EXEC PGM=SASSDT70,PARM='REPORT,ALLSETS'

The SYSIN DD * file in the JCL allows selection of a specific ARFSET from the ARF
database component. The keyword ARFSET= is used to specify a fully qualified or
generic ARFSET name. A generic ARFSET name can be specified by coding an asterisk (*)
on the trailing end of the qualifying set name characters. At least one character is
required. Comments may be included in the SYSIN DD file by coding an asterisk in the
first column (col. 1). The number of control cards that can be specified is limited only by
the amount of memory available to the program.

//SYSIN DD *
*
* Comment card (asterisk column 1)
* The following control card selects any ARFSET with the
* first three characters of PRD.
ARFSET=PRD*
*
* The following control card selects ARFSET TEST only.
ARFSET=TEST
*
* The following control cards selects any ARFSET which begins
*with the letter Z.
ARFSET=Z*

Chapter 13: Database Transportability 445

Automated Recovery Facility Database Extracts

Data Sets Used/Created

DBPARMS
These parameters describe your CA Datacom/AD database.
DT70ADDS
This file is the generated Batch Terminal Interface commands file. This file is used as
input into a CA WA CA 7 Edition BTI job to add the ARFSET definitions to a different
ARF database.
SYSIN
This file contains the control statements that are used to specify which ARFSETs are
extracted for this run.
ARFREPT
This file is the SASSDT72-01 ARFSET Extract Report file.

Note: The second step of the ARF Database Transportability process is to run a Batch
Terminal Interface job. The job uses the generated DT70ADDS file as SYSIN input to add
the ARFSET definitions on the target ARF database.

446 Database Maintenance Guide

Chapter 14: Job Name Rename
Function
The job name rename function is part of the online system. When used online, you can
rename a single job. When used with the batch terminal, you can specify multiple
commands as input.

Online Job Rename

Assume that you enter the following top line command:

JRENAME,CA07XX01,NEWJOB=CA07JM01

The command produces the following results:

---------------------------- Jobname Rename --------------------------PAGE 0001

Old Job Name CA07XX01 NEWJOB=CA07JM01 QCHK=NO UPDATE=YES LIST=YES
------------------------- JOB/STEP/DD Data Changed -----------------------
Jobname CA07XX01 changed to CA07JM01
Step S1 GEN1 # 001
DD SYSPRINT # 0001
DD SYSIN # 0002
DD SYSUT2 # 0003
DD SYSUT1 # 0004
Step S1 TRL1 # 002
DD STEPLIB # 0001
DD SYSUDUMP # 0002
DD SYSOUT # 0003
DD SYSIN # 0004
Step S1 GEN2 # 003
DD SYSPRINT # 0001
DD SYSIN # 0002
DD SYSUT2 # 0003
DD SYSUT1 # 0004

------------------------ DATASET/JOB/Cross Reference ----------------------

Dsn USR.DEVCA7.RPT.LOADLIB

Chapter 14: Job Name Rename Function 447

Online Job Rename

---------------------------- Jobname Rename --------------------------PAGE 0002

Old Job Name CA07XX01 NEWJOB=CA07JM01 QCHK=NO UPDATE=YES LIST=YES
Dsn USRDAL.L2B031.U7TEST01
Dsn USRDAL.L2B031.U7TEST02

------------------------ DATASET/STEP/Cross Reference ----------------------

Dsn USRDAL.L2B031.U7TEST01 Step# 001
Dsn USR.DEVCA7.RPT.LOADLIB Step# 002
Dsn USRDAL.L2B031.U7TEST02 Step# 003

-------------------------------- Prose ---------------------------------

Prose# 00041

--------------------------- Requirement Entries --------------------------

Predecessor USR.DEVCA7.RPT.LOADLIB Type DSN
Predecessor TESTOTNW Subid BOB Type NW Schid 000
Predecessor TESTOTNW Subid RPT1205 Type NW Schid 000
Successor CA07XX08 Type JOB Schid 001

--------------------------- Schedule Definitions -------------------------

Schid 001
Schid 002

---------------------------- Jobname Rename --------------------------PAGE 0003

Old Job Name CA07XX01 NEWJOB=CA07JM01 QCHK=NO UPDATE=YES LIST=YES
Schid 003
Schid 005
Schid 008
Schid 009
Schid 022

------------------------------ Triggered By ------------------------------

Triggered By CA75SCHD Type JOB Schid 012
Triggered By RBNETIN Type NW

SM26-00 Request Completed at 15:00:21 on yy.ddd

448 Database Maintenance Guide

 Batch Job Rename

Batch Job Rename

Executed as a batch process, you can issue multiple commands. Assume that you specify
the following commands as input:

JRENAME,AAAG1,NEWJOB=AAAG1JM
JRENAME,AAAG2,NEWJOB=AAAG2JM

The commands produce this report:

CAL2C501I ***** INPUT TO CA-7 CCI BATCH INTERFACE *****

/LOGON ********
JRENAME,AAAG1,NEWJOB=AAAG1JM
JRENAME,AAAG2,NEWJOB=AAAG2JM
/LOGOFF

CAL2C502I ***** END OF INPUT TO CA-7 CCI BATCH INTERFACE *****

120yy.ddd/15:07 JOB: USER001A(JOB14531) CA-7 CCI BATCH INTERFACE

CAL2C504I ***** RESPONSES RECEIVED FROM CA-7 *****

- yyddd 150723 /LOGON ********

CA-7.023 - r12 OPERATOR IS LOGGED ON TO TERMINAL CCIT1 AT 15:07:23 ON

- yyddd 150723 JRENAME,AAAG1,NEWJOB=AAAG1JM
1---------------------------- Jobname Rename --------------------------PAGE 0001
Old Job Name AAAG1 NEWJOB=AAAG1JM QCHK=NO UPDATE=YES LIST=YES
------------------------- JOB/STEP/DD Data Changed -----------------------
Jobname AAAG1 changed to AAAG1JM

--------------------------- Requirement Entries --------------------------

Predecessor DESPA03 Type DSN
Successor AAAGPRD Type JOB Schid 000

------------------------------ Triggered By ------------------------------

Triggered By AAAGPRD Type JOB Schid 000

-------------------------------------------------------------------------------
SM26-01 Request Completed at 15:07:23 on yy.ddd
- yyddd 150723 JRENAME,AAAG2,NEWJOB=AAAG2JM
1---------------------------- Jobname Rename --------------------------PAGE 0001
Old Job Name AAAG2 NEWJOB=AAAG2JM QCHK=NO UPDATE=YES LIST=YES
------------------------- JOB/STEP/DD Data Changed -----------------------
Jobname AAAG2 changed to AAAG2JM

-------------------------------- Prose ---------------------------------

Prose# 00893

SM26-01 Request Completed at 15:07:24 on yy.ddd

- yyddd 150724 /LOGOFF

CA-7.024 - r12 OPERATOR AT TERMINAL (CCIT1 ) LOGGED OFF AT 15:07:24 ON

Chapter 14: Job Name Rename Function 449

Batch Job Rename

450 Database Maintenance Guide

Appendix A: Using CA 7/PERSONAL
SCHEDULING
This section contains the following topics:
Overview (see page 451)
Panel Descriptions (see page 452)
Access CA 7/PERSONAL SCHEDULING (see page 455)
Add a Job (see page 457)
Submit a Job (see page 458)
Display a Job's Status (see page 459)
Implement CA 7/PS (see page 460)
CA 7/PS Messages (see page 462)

Overview
CA 7/PERSONAL SCHEDULING (CA 7/PS) is designed to extend the functionality of
scheduling jobs to virtually anyone within a company who has access to a terminal
connected to their mainframe. It is an easy way to set up and monitor jobs without
having to spend much time learning to use the various extended functions that are
available in CA WA CA 7 Edition.

Important! CA 7/PS was designed only for CPU job types; however all options except
ADD (define) can be used for any job type (for example, CPU or cross-platform). If you
want to ADD a job, it is automatically added as a CPU job. You cannot ADD an XPJOB or
an agent job using the PS panel.

CA 7/PS provides the following functions:

■ Add a job to CA WA CA 7 Edition
■ Schedule the job to run on a date/time basis
■ Run a one-time job without having to add it to CA WA CA 7 Edition
■ Run a job in sequence with another job
■ Display the last time that a job ran
■ Display the next time that the job is scheduled
■ Display information about a job that is running (or about to run)
■ Delete previously defined jobs

Appendix A: Using CA 7/PERSONAL SCHEDULING 451

Panel Descriptions

Panel Descriptions
The following is a CA 7/PERSONAL SCHEDULING panel.

-------------------------- CA-7 / PERSONAL SCHEDULING ------ yy.ddd / hh:mm:ss

FUNCTION===> (ADD,LIST,UPD,DEL,SUBMIT,STATUS,QUIT)

JOBNAME =>
JCL ID => JCL LIB =>

WHEN TO SCHEDULE:
PATTERN =>
TIME TO RUN => (0001-2400)

JOB RUNS AFTER => (JOBNAME - SUBMIT ONLY)

- - - - - - - STATUS INFORMATION (DISPLAY ONLY) - - - - - - -

MESSAGE: PS00-00 ENTER THE DESIRED FUNCTION AND JOB INFORMATION.

This panel contains the following fields:

FUNCTION
Determines the action to take when you press Enter. Available FUNCTIONS are the
following values:
ADD
Adds the job to CA WA CA 7 Edition. Note the following defaults (using the CA-7
CPU Job Definition panel for field names): the JOBNET field defaults to the
PATTERN name if one is entered, the SYSTEM field defaults to CA7PS, the
OWNER field is the USERID of the person adding the job and the UID is the UID
of the person adding the job. All other defaults are taken from the Personal
Scheduling or regular DEFAULTS job as defined at your installation.
LIST
Lists the information that has previously been defined to CA WA CA 7 Edition
using the ADD function, the UPD function, or both.

452 Database Maintenance Guide

 Panel Descriptions

UPD
Updates the CA WA CA 7 Edition information about the job with the
information provided in the other fields on this panel. If external security is
used, the person updating must have the same USERID as the OWNER field on
the JOB panel and the same UID (coids are not honored).
DEL
Deletes all of the job's information from CA WA CA 7 Edition.
SUBMIT
Submits the job listed in the JOBNAME field to the CPU. It runs without waiting
for the scheduled date/time. The PATTERN field is not honored with this
function. This function can be used to run a job without having to set up a
PATTERN and TIME for the job to be scheduled. The TIME field may be used to
establish a submission time of day within the next 24 hours. The JOB RUNS
AFTER field can be used to cause the job to wait on the execution of another
job that runs under CA WA CA 7 Edition control. To add the job to the
database, the ADD function must be used.
STATUS
Displays the current information about the job. This may include information
about when the job last ran, when it is scheduled to run next, and current
status if the job is executing or waiting to be submitted. The information is
displayed on the lower half of the panel, below the STATUS INFORMATION line.
These are the possible messages that can be displayed:
■ JOB IS NEXT SCHEDULED AT hhmm ON yy.ddd
■ JOB LAST RAN AT hhmm ON yy.ddd
■ JOB IS WAITING FOR JOB xxxxxxxx
■ JOB IS AWAITING EXECUTION
■ JOB IS ACTIVE ON CPU
■ JOB DOES NOT CURRENTLY HAVE A SCHEDULE
■ JOB IS NOT DEFINED IN THE CA-7 DATABASE
QUIT
Terminates the current session with CA WA CA 7 Edition.

Appendix A: Using CA 7/PERSONAL SCHEDULING 453

Panel Descriptions

JOBNAME
Indicates the job on which the indicated function is performed. The field may be 1-8
alphanumeric characters. Required.
JCL ID
Identifies the JCL data set which contains the execution JCL to be submitted. If used,
the value must be a numeric INDEX associated with the desired JCL data set (on the
JCL statement in the initialization file). The numeric INDEX specified must be a
number between 0 and 999. This field or the JCL LIB field is required if the job is not
defined in the database. JCL ID and JCL LIB are mutually exclusive.
Note: For more information about the initialization file, see the Systems
Programming Guide.
JCL LIB
Identifies the JCL data set which contains the execution JCL to be submitted. If used,
the value must be a symbolic INDEX associated with the desired JCL data set (on the
JCL statement in the initialization file). This field or the JCL ID field is required if the
job is not defined in the database. JCL ID and JCL LIB are mutually exclusive.
Note: For more information about the initialization file, see the Systems
Programming Guide.
PATTERN
Indicates the days that this job is going to run. Each site has a unique set of
PATTERN jobs defined that give you flexibility in scheduling your jobs. Optional.
If PATTERN is input and it is the same as the one already defined, then no changes
are made to the job's schedule, even if the schedule of the PATTERN job has
changed. To delete a PATTERN, enter =D in the PATTERN field and use the UPD
function.
TIME TO RUN
Indicates the time of the day(s) that this job is submitted. This value can be
specified from 0001 (one minute after midnight) through 2400 (midnight). Make
sure that you specify the correct hour (3:00 p.m. is specified as 1500). Required if
PATTERN is used.
TIME can also be used with the SUBMIT function to demand a job to be submitted
in the next 24 hours. If the time of day that is specified is less than the current time
of day, the job is submitted then on the following day.
JOB RUNS AFTER
Used to indicate that the job you are submitting must wait for another job to
complete before it can run. This field lets you establish sequencing for the job. This
field is only valid with the SUBMIT function. Optional.

454 Database Maintenance Guide

 Access CA 7/PERSONAL SCHEDULING

Access CA 7/PERSONAL SCHEDULING

To access CA 7/PS:
1. Log on to CA WA CA 7 Edition. This logon can be accomplished several ways. CA WA
CA 7 Edition may be accessed directly from your site's VTAM panel, through a
session manager, or through TSO/ISPF.
When you have logged on to CA WA CA 7 Edition successfully, a panel similar to the
following is displayed.

------------------------*** CA71 PRODUCTION INSTANCE ***---------------------

PLEASE ENTER LOGON DATA OR PRESS PF3 TO DISCONNECT

USERID : TERMINAL NAME : TRM001 DATE : yy.131

PASSWORD : VTAM APPLID : CAW TIME : 09:01:24
NEW PASSWORD : LUNAME : A99L100 LEVEL : r12
UID RESOURCE :
PARMS :

C A W O RK L O A D A U T OM A T I ON

CA 7 E DI T I ON

Copyright (C) 2013 CA.

All rights reserved.

Appendix A: Using CA 7/PERSONAL SCHEDULING 455

Access CA 7/PERSONAL SCHEDULING

2. Press Enter to display the following CA-7 Function Menu.

---------------------------- CA-7 FUNCTION MENU ------------------------------

FUNCTION ===>

APA - AUTOMATED PERFORMANCE ANALYSIS

AR - AUTOMATED RECOVERY FACILITY
DB - DATABASE MAINTENANCE
QM - QUEUE MAINTENANCE
RM - VIRTUAL RESOURCE MANAGEMENT
UT - UTILITIES
PS - PERSONAL SCHEDULING

HELP - TUTORIAL

PROGRAM: MNU0 MSG-INDX: 00 -- MENU -- 09.200 / 09:44:37

MESSAGE: SPECIFY DESIRED FUNCTION OR ENTER A COMMAND ON THE TOP LINE

3. Type PS from the CA-7 Function Menu. Press Enter.

The CA-7/PERSONAL SCHEDULING panel is now displayed, and you are ready to
perform any of the CA-7/PS functions.

Note: The PS command can also be used at the top line of any panel to display the
CA-7/PS panel.

456 Database Maintenance Guide

 Add a Job

Add a Job
------------------------- CA-7 / PERSONAL SCHEDULING ------ yy.ddd / hh:mm:ss

FUNCTION===> ADD (ADD,LIST,UPD,DEL,SUBMIT,STATUS,QUIT)

JOBNAME => MYJOB

JCL ID => 1 JCL LIB =>

WHEN TO SCHEDULE:
PATTERN => DAILY
TIME TO RUN => 0800 (0001-2400)

JOB RUNS AFTER => (JOBNAME - SUBMIT ONLY)

- - - - - - - STATUS INFORMATION (DISPLAY ONLY) - - - - - - -

MESSAGE: PS00-00 ENTER THE DESIRED FUNCTION AND JOB INFORMATION.

This panel shows the information that is used to schedule a job. The fields that are filled
in are:
■ FUNCTION
■ JOBNAME
■ JCL ID or JCL LIB
■ PATTERN
■ TIME TO RUN

The information supplied will cause the job to be submitted on a daily basis at 8:00 a.m..
The PATTERN name of DAILY may not be defined at your site, but there is probably an
equivalent one set up. When the job is submitted, the JCL will be copied from the JCL
library defined at your site with an index of 1.

Appendix A: Using CA 7/PERSONAL SCHEDULING 457

Submit a Job

Submit a Job
------------------------- CA-7 / PERSONAL SCHEDULING ------ yy.ddd / hh:mm:ss

FUNCTION===> SUBMIT (ADD,LIST,UPD,DEL,SUBMIT,STATUS,QUIT)

JOBNAME => MYJOB2

JCL ID => 1 JCL LIB =>

WHEN TO SCHEDULE:
PATTERN =>
TIME TO RUN => (0001-2400)

JOB RUNS AFTER => MYJOB (JOBNAME - SUBMIT ONLY)

- - - - - - - STATUS INFORMATION (DISPLAY ONLY) - - - - - - -

MESSAGE: PS00-00 THE SUBMIT WAS SUCCESSFUL.

This panel shows the information that is used to run a job. The fields that are filled in
are:
■ FUNCTION
■ JOBNAME
■ JCL ID or JCL LIB
■ JOB RUNS AFTER

The information supplied will cause the job to be submitted by CA WA CA 7 Edition

without having to wait for scheduling by date/time criteria. The JOB RUNS AFTER field
causes CA WA CA 7 Edition to verify that MYJOB runs before MYJOB2 will be submitted
to the CPU.

458 Database Maintenance Guide

 Display a Job's Status

Display a Job's Status

------------------------- CA-7 / PERSONAL SCHEDULING ------ yy.ddd / hh:mm:ss

FUNCTION===> STATUS (ADD,LIST,UPD,DEL,SUBMIT,STATUS,QUIT)

JOBNAME => MYJOB

JCL ID => JCL LIB =>

WHEN TO SCHEDULE:
PATTERN =>
TIME TO RUN => (0001-2400)

JOB RUNS AFTER => (JOBNAME - SUBMIT ONLY)

- - - - - - - STATUS INFORMATION (DISPLAY ONLY) - - - - - - -

- JOB IS NEXT SCHEDULED AT hhmm ON yy.ddd

- JOB LAST RAN AT hhmm ON yy.ddd
- JOB IS ACTIVE ON CPU

MESSAGE: PS00-00 STATUS SUCCESSFUL.

This panel is an example of the STATUS function. The fields that are entered are:
■ FUNCTION
■ JOBNAME

The status indicates the next date/time that the job is going to be scheduled to run, the
last date/time that it ran, and any current information if the job is in the process of
being run.

Note: If the job was not added through the Personal Scheduling panel, the time on the
JOB IS NEXT SCHEDULED AT will be all zeros.

Appendix A: Using CA 7/PERSONAL SCHEDULING 459

Implement CA 7/PS

Implement CA 7/PS
To implement CA 7/PERSONAL SCHEDULING:
1. Define the USERIDs to CA WA CA 7 Edition that will be using CA 7/PS.
If CA WA CA 7 Edition internal security is being used, the current Security module
must be modified to allow access to the PS00 application. The access levels required
are shown below. For more information about the internal security module, see the
Security Reference Guide
If command and panel access is being controlled using the CA WA CA 7 Edition
External Security Interface, the resource for the new panel may need to be defined
to the security package. The USERIDs that will be accessing CA 7/PS must be given
access to the CA WA CA 7 Edition application and the resource listed below, with
the appropriate access level.

Panel ID Resource Name Access Level Functions

PS L2PS READ(5) STATUS,LIST
ADD (10) ADD
UPD (10) UPD
DEL (10) DEL
SUBM (10) SUBMIT
None QUIT

2. Set up the PATTERN jobs.

The AL2PSBTI member of CAL2OPTN contains sample Batch Terminal commands to
define several PATTERN jobs to CA WA CA 7 Edition. The sample commands add
them to the CA WA CA 7 Edition database, define their schedules, and RESOLV the
schedules. The following is a list of the PATTERN jobs that are defined in the
CAL2OPTN member AL2PSBTI:
DAILY
Every available processing day of the calendar used.
MON
Mondays.
TUES
Tuesdays.
WED
Wednesdays.

460 Database Maintenance Guide

 Implement CA 7/PS

THU
Thursdays.
FRI
Fridays.
FIRST
First day of the month (actual or relative based on the calendar used).
LAST
Last day of the month (actual or relative based on the calendar used).
Before using the AL2PSBTI member as input to the CA WA CA 7 Edition batch
terminal, do the following:
■ Verify that no jobs are already defined to the CA WA CA 7 Edition database
with the preceding names. If there are, simply change the job names in the
sample AL2PSBTI member. Note that the jobs are not going to be scheduled by
CA WA CA 7 Edition because their schedules are turned off with the DONT
SCHEDULE BEFORE field set to 99999.
■ Supply valid SCAL values where SCAL is specified. The calendar (SCAL) specified
will determine whether the FIRST and LAST will be actual or relative days
(based on the specification of the OPTIONS=SCHDYONLY value) and whether
DAILY will include Saturdays and Sundays or only weekdays.
After running a batch terminal with the sample member, verify that the commands
were processed correctly without errors by examining the job's output. After this
verification is complete, the installation is complete and the implementation is well
under way.
3. Define Personal Scheduling Defaults Job (optional).
You may establish a DEFAULTS job specifically for personal scheduling. If you choose
not to, defaults are taken from the regular CA WA CA 7 Edition defaults job. For
example, you may want all Personal Scheduling jobs to be MAINT=Y while your
production work is normally MAINT=N. To establish a Personal Scheduling defaults
job:
■ Define the job to the CA WA CA 7 Edition database using the job definition
panel. Remember that some information (such as SYSTEM, OWNER, and UID)
are always overridden when a Personal Scheduling job is ADDed.
■ In your CA WA CA 7 Edition initialization file, add the following keyword to the
DBASE statement:
DEFAULTPS=jobname
4. Code Personal Scheduling Verification Exit (optional).
Refer to the Systems Programming Guide for information on adding and
implementing an exit to allow you to enforce local standards and conventions.

Appendix A: Using CA 7/PERSONAL SCHEDULING 461

CA 7/PS Messages

Defining Additional PATTERN Jobs

If any other PATTERN streams are desired, simply define them using the batch terminal
or using the CA WA CA 7 Edition online system. When defining any additional jobs, the
following items should be considered:
■ Add the jobs with EXEC=N and DONT SCHEDULE BEFORE=99999.
■ Schedule the PATTERN job as desired using the CA-7 CPU JOB SCHEDULING panel. A
PATTERN job may have up to 2 SCHIDs defined.
■ Ensure that the schedules are RESOLVed.

Note: The PATTERN jobs should have no more than two SCHIDs defined.

CA 7/PS Messages
The following are the messages.

PS00-00

ENTER THE DESIRED FUNCTION AND JOB INFORMATION.

Reason:
This prompt requests input information.

Action:
Self-explanatory.

PS00-00

THE xxxxxx WAS SUCCESSFUL.

[nnn DATASET(S) DELETED]
['DEFAULTS' JOB USED]

Reason:
The requested function was successful. The xxxxxx indicates the function that was
performed. If the DELete function was entered, nnn denotes the number of related data
sets that were deleted. 'DEFAULTS' JOB USED is appended to the message when an ADD
function was done and a DEFAULTS job was found in the database.

Action:
None.

462 Database Maintenance Guide

 CA 7/PS Messages

PS00-01

A SERIOUS ERROR OCCURRED. ERROR CODES: WIP - xx RC - yy

Reason:
An error has occurred attempting to process the requested function.

Action:
Report this error, with the diagnostic information, to the CA WA CA 7 Edition technical
staff at your site.

PS00-02

THE JOB WAS NOT FOUND.

Reason:
The requested job was not found on the CA WA CA 7 Edition database.

Action:
Check for correct input. If in error, correct and retry.

PS00-03

FUNCTION NOT SUCCESSFUL - DATABASE IS OUT OF SPACE.

Reason:
Part of the database is full, and the attempted function could not be completed
successfully.

Action:
Report this error to the personnel responsible for CA WA CA 7 Edition maintenance at
your site.

PS00-05

THE xxxxxxxxxxxxx DATA WAS INVALID OR OMITTED.

Reason:
The xxxxxxxxxxxxx indicates which field on the panel is causing the error.

Action:
Check for correct input. Ensure that all of the necessary fields were filled in with valid
information. If JOBNAME, verify that first seven characters of the job name match the
CA WA CA 7 Edition log dump job name.

Appendix A: Using CA 7/PERSONAL SCHEDULING 463

CA 7/PS Messages

PS00-07

THE JOB ALREADY EXISTS.

Reason:
An ADD function was requested for a job that is already defined in the CA WA CA 7
Edition database.

Action:
Use the UPD function when changing an existing job.

PS00-08

YOU ARE NOT AUTHORIZED TO ACCESS THAT JOB.

Reason:
A function was requested for a job with a USERID (OWNER on the CPU Job Definition
panel) or a UID that does not match yours.

Action:
Update the OWNER field on the CPU Job Definition panel with your USERID if you
require access to the job.

PS00-09

YOU ARE NOT AUTHORIZED TO DO THAT FUNCTION.

Reason:
You do not have the level of authority required to enter the function selected.

Action:
Contact your security administrator if you should be able to enter the function.

PS00-11

THE JOB IS NOT IN THE JCL LIBRARY SPECIFIED.

Reason:
The JCL member was not in the JCL library referenced.

Action:
Verify the location of the JCL and enter the correct JCL index. A /DISPLAY,ST=JCL topline
command in CA WA CA 7 Edition can show the JCL data sets and the index number
associated with them.

464 Database Maintenance Guide

 CA 7/PS Messages

PS00-12

THE SPECIFIED PATTERN IS NOT FOUND.

Reason:
The PATTERN that was entered is not defined to CA WA CA 7 Edition.

Action:
Perform the function with a valid PATTERN name.

PS00-13

THE PATTERN SCHEDULE IS INVALID.

Reason:
The PATTERN that was entered is either not RESOLVed or has more than two SCHIDs
associated with it.

Action:
Perform the function with a valid PATTERN name.

PS00-15

PATTERN AND TIME MUST BOTH BE SPECIFIED.

Reason:
These fields are both required when either one is entered.

Action:
Perform the function again with valid data in both PATTERN and TIME fields.

PS00-16

REQUEST REJECTED BY SASSXX14 USER EXIT

Reason:
Your installation user exit has rejected the request. The line following this message
contains a message from the installation user exit indicating why the request was
rejected.

Action:
Correct the problems indicated and reissue the request.

Appendix A: Using CA 7/PERSONAL SCHEDULING 465

CA 7/PS Messages

PS00-20

JOB IS NOT DEFINED AND NO JCL ID OR JCL LIB WAS SUPPLIED.

Reason:
A SUBMIT function was entered for a job that is not defined to CA WA CA 7 Edition and
no JCL ID or JCL LIB was specified.

Action:
Enter the JCL ID or the JCL LIB if the job is not defined in the CA WA CA 7 Edition
database.

PS00-21

THE JOB CAN NOT BE SUBMITTED.

Reason:
A SUBMIT function was entered for a job that cannot be brought into the CA WA CA 7
Edition request queue.

Action:
Contact your CA WA CA 7 Edition administrator, who may try a DEMAND command to
produce other messages.

PS00-22

CAN NOT RETRIEVE THE JCL FOR THE JOB.

Reason:
A SUBMIT function was entered for a job and there was a problem accessing the JCL.

Action:
Contact your CA WA CA 7 Edition administrator, who may try a DEMAND command to
produce other messages.

466 Database Maintenance Guide

 CA 7/PS Messages

PS00-23

CAN NOT RETRIEVE THE JCL FROM THE OVERRIDE LIBRARY.

Reason:
A SUBMIT function was entered for a job that is set up to execute from the override
library and there was a problem submitting that JCL.

Action:
Verify that the member exists in the override library (index 254). If the JCL should not be
in the override library, update the CPU JOB DEFINITION panel and change the USE-OVRD
LIBRARY from Y to N and resubmit. You may need to contact your CA WA CA 7 Edition
administrator to do a DEMAND command to produce different diagnostic messages.

PS00-24

A JOB IS ALREADY SCHEDULED WITH THE SAME DUE OUT TIME.

Reason:
A SUBMIT function was entered for a job while the same job is in the CA WA CA 7
Edition queues with the same due-out date and time.

Action:
Wait a few minutes and perform the SUBMIT function again if you want duplicate job
entries in the CA WA CA 7 Edition queues.

PS00-25

AN ERROR OCCURRED RETRIEVING THE SCHEDULE FOR THE JOB.

Reason:
The PATTERN job's schedule is in error.

Action:
Contact your CA WA CA 7 Edition administrator to determine the problem with the
PATTERN job's schedule.

Appendix A: Using CA 7/PERSONAL SCHEDULING 467

CA 7/PS Messages

PS00-26

CONFLICT IN JCLID AND JCLLIB FIELDS

Reason:
The JCL library for a job can only be specified by a JCLID or a JCLLIB, not both.

Action:
Specify either a JCLID or a JCLLIB and reenter.

PS00-30

xxxxxxxx is an yyyyy JOB- NO yyyyy ENVIRONMENT EXISTS

Reason:
xxxxxxxx is the job name. CA WA CA 7 Edition has been started with the cross-platform
job feature disabled where yyyyy denotes the cross-platform job type (Agent or XPJOB).

Note: For more information about the XPDEF statement, see the Systems Programming
Guide.

Action:
Enable the cross-platform job feature. Contact your installation specialist for assistance.

PS00-31

xxxxxxxx FAILURE GETTING yyyyyyyy INFO SASSJOBR RC=xx

Reason:
CA WA CA 7 Edition was unable to access yyyyyyyyy (agent information for agent jobs or
node/executable information for XPJOBs) for cross-platform job xxxxxxxx. As a result,
cross-platform job xxxxxxxx is not executed.

Action:
Note the message and return code provided, and contact CA Support at
http://ca.com/support for assistance.

468 Database Maintenance Guide

 CA 7/PS Messages

PS00-32

xxxxxxxx FAILURE GETTING yyyyyyyy INFO SASJE RC=xx

Reason:
CA WA CA 7 Edition was unable to access yyyyyyyyy (agent information for agent jobs or
node/executable information for XPJOBs) for cross-platform job xxxxxxxx. As a result,
cross-platform job xxxxxxxx is not executed.

Action:
Note the message and return code provided, and contact CA Support at
http://ca.com/support for assistance.

PS00-33

xxxxxxxx FAILURE ADDING yyyyyyyy SEGMENT EOF REACHED

Reason:
The yyyyyyyyy segment (agent information for agent jobs or node/executable
information for XPJOBs) for cross-platform job xxxxxxx could not be added to the queue
because it is full.

Action:
Perform one the following actions:
■ Enlarge the queue if the queue if full.
■ Post existing jobs before processing additional requests.
Contact your installation specialist for assistance.

PS00-34

xxxxxxxx FAILURE ADDING yyyyyyyy SEGMENT SQADD RC=xx

Reason:
The yyyyyyyyy segment (agent information for agent jobs or node/executable
information for XPJOBs) for cross-platform job xxxxxxx could not be added to the queue.

Action:
Note the message and return code provided, and contact CA Support at
http://ca.com/support for assistance.

Appendix A: Using CA 7/PERSONAL SCHEDULING 469

CA 7/PS Messages

PS00-99

AN INVALID MESSAGE NUMBER WAS SPECIFIED.

Reason:
An undefined message index number has been produced.

Action:
Contact your CA WA CA 7 Edition administrator who may need to contact CA Support.

470 Database Maintenance Guide