Command Ref 52

ESP Workload Manager
Version 5.2
Command Reference
ESP-CR-02
2
Second Edition (October 1999)
This edition applies to Version 5 Release 2 of ESP Workload Manager Documentation.
The software and related manuals are protected by copyright law.
ESP Workload Manager Documentation
1992-1998,1999 Cybermation Inc.
All rights reserved.
No portion of this publication may be reproduced, stored in a retrieval system, or transmitted in
any form or by any means without express written permission of Cybermation Inc.,
80 Tiverton Court, Markham, Ontario, L3R 0G4, Canada, (905)-479-4611.
www.cybermation.com
U.S. Government Users. RESTRICTED RIGHTS - Use, Duplication or Disclosure restricted by
GSA ADP Schedule Contract with Cybermation Inc.
Trademark Notice:
ESP Workload Manager is a registered trademark of Cybermation Inc.
All other brand and product names are trademarks or registered trademarks of their respective
companies.
3
Introduction
Overview
This manual The ESP Workload Manager Command Reference contains all the commands and
statements available to ESP users. Use it as a reference for when you want a
complete description of the commands (or statements) and all valid keywords and
parameters. Use the examples to see how each command and statement might be
used.
If you know the command you want to use, and are familiar with its options, but
simply want to see the syntax, use the ESP Command Quick Reference.
Entering
commands
ESP commands may be entered in Line mode, Page mode, batch, or loaded from a
data set (using the LOAD command). Many can also be entered from a system
console.
ESP statements must be entered in a data set specific to the type of statement used.
Consult the ESP Workload Manager Users Guide for more background material on
any part of the Command Reference.
Issuing console
commands
To issue a command from the system console, use the MODIFY command, as in
F ESP, where ESP is the started task name. For example:
F ESP,STATUS
Issuing OPER
commands
To issue a command that requires OPER authority from TSO, precede it with
OPER. For example:
OPER STATUS
Issuing
commands in
batch
To issue a command in batch, use the following JCL after your job card:
//EXEC PGM=ESP,REGION=4000K
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
ESP command
.
.
.
ESP command
Continued on next page
4
Overview, Continued
Subsystem
name
If the subsystem name for ESP is not ESP, you need to type the subsystem name
when entering a command in batch. For example, if the subsystem name is ESPA,
type:
//EXEC PGM=ESP,PARM=SUBSYS(ESPA),REGION=4000K
Steplib If the TSO command processor is not in a LINKLIST library, you need STEPLIB or
JOBLIB statement in your JCL. Your statement may look like:
//STEPLIB DD DSN=CYB.ESP.LOAD,DISP=SHR
Wildcards and
masking
Many of the commands permit the use of a wildcard character and generic masking.
Use the asterisk (*) as a wildcard to match any character, and a hyphen (-) for
masking.
For example, to display all calendars:
LISTCAL
To display all calendars with names containing XY in character positions 3 and 4:
LISTCAL **XY-
To display all calendars with two-character names:
LISTCAL **
5
Syntax Diagrams
Input ESP is not case sensitive. Even though we show commands in uppercase, when you
type a command on the command line, you do not need to type the command in
uppercase letters.
Syntax
conventions
The Syntax diagrams in this manual use the following conventions:
Notation Meaning
Apostrophes or Must be entered as shown.
Comma , Must be entered as shown.
Ellipsis The parameter can be repeated. Do not enter ellipsis.
Lower Case Italics
parameter
A parameter must be substituted. User supplied variable
or character string.
Uppercase parameter The parameter must be spelled as shown. You can enter
the command and the parameter in either upper or lower
case.
OR-bar ( | ) Indicates an exclusive value on left or right of bar. You
must enter one of the items. You cannot enter more than
one.
Underline ______ If you do not enter one of the parameters, the system
supplies the underlined parameter, which is the default.
Parentheses ( ) and
special characters
Parameter enclosed in parentheses is mandatory and must
be entered as shown.
Single parameter in
square brackets [ ]
Optional parameter, do not type the brackets.
Stacked parameters in
braces { }
{ }
Mandatory, you must enter one of the parameters. You
cannot enter more than one.
square brackets [ ]
[ ]
Optional parameter, you can enter one value, or none.
Stacked parameters
with OR-bars ( | ) and
square brackets
[ ]
|[ ]
Optional, mutually exclusive parameters. Enter one or
none.
square brackets within
braces {[ ]}
Mandatory, you must enter one of these parameters. You
can enter more than one.
6
Summary of Changes
Introduction This manual contains information previously presented in ESP-CR-01, which
supports ESP Workload Manager version 5.1.
Changed
Information
This manual contains terminology, maintenance and editorial changes. A vertical
line to the left of the text indicates technical changes or additions to the text.
New
Information
The following commands have been added:
AGENT
AGENTMSG
ESPCOM
ESP XCF commands:
DELETE
DISPLAY
FORCE
HELP
PURGE
SET
SPIN TRACE
START
STOP
VERIFY
JOBRES
MAPUSER
MGRADDR
MGRMSG
TRYJOIN
The following statements have been added:
ABSORB
DURATION
STEPEND
7
Introduction ................................................................................................................................................... 3
Overview............................................................................................................................................... 3
Syntax Diagrams................................................................................................................................... 5
Summary of Changes............................................................................................................................ 6
ABANDON DEPENDENCIES Statement ......................................................................................... 15
ABANDON RESOURCES Statement ............................................................................................... 17
ABANDON SUBMISSION Statement .............................................................................................. 19
ABENDLIM Command...................................................................................................................... 22
ABSORB Statement ........................................................................................................................... 24
ADJUST Command............................................................................................................................ 25
AFTER Statement............................................................................................................................... 27
AGENT Command ............................................................................................................................. 31
AGENTMSG Command..................................................................................................................... 34
AGENTRCV Command..................................................................................................................... 37
ALERTDEF Command ...................................................................................................................... 41
ALLOWUNDEF Statement................................................................................................................ 44
ALTCAL Command........................................................................................................................... 45
ALTEVENT Command...................................................................................................................... 47
ALTGROUP Command...................................................................................................................... 50
ALTSIG Command............................................................................................................................. 52
ALTTJ Command............................................................................................................................... 53
ALTUSER Command......................................................................................................................... 55
APPL Statement.................................................................................................................................. 58
APPLJOB Command - Controlling Jobs and subAppls ..................................................................... 63
APPLJOB Command - Controlling Applications............................................................................... 74
BACKOUT......................................................................................................................................... 76
BKUPEVS Command......................................................................................................................... 77
BKUPHIST Command ....................................................................................................................... 78
BKUPINDX Command ...................................................................................................................... 79
BKUPJNDX Command...................................................................................................................... 81
BKUPUDEF Command...................................................................................................................... 83
BREAK Command ............................................................................................................................. 85
CALENDAR Command ..................................................................................................................... 87
CCCHK Statement.............................................................................................................................. 89
CCFAIL Statement ............................................................................................................................. 94
CELLTRC Command......................................................................................................................... 97
CHECKEXC Statement.................................................................................................................... 100
CLASS Command ............................................................................................................................ 103
CLRSYSMS Command.................................................................................................................... 107
CMDPRFX Command...................................................................................................................... 108
COM Command................................................................................................................................ 109
CONNECT Command...................................................................................................................... 110
CONSOLE Command ...................................................................................................................... 112
COPY Command .............................................................................................................................. 114
COPYJCL Statement ........................................................................................................................ 116
COREQ Statement ............................................................................................................................ 119
CPU Command................................................................................................................................. 122
CRITERIA Command....................................................................................................................... 124
CRITPATH Command ..................................................................................................................... 127
CRITPATH Application Statement .................................................................................................. 129
DAB Command ................................................................................................................................ 131
DATASET Statement ....................................................................................................................... 133
DATEFORM Command................................................................................................................... 135
DATEFORM Reporting Command.................................................................................................. 137
8
DEFAT Command............................................................................................................................ 139
DEFAULT Command....................................................................................................................... 142
DEFCAL Command ......................................................................................................................... 144
DEFGROUP Command.................................................................................................................... 147
DEFHOL Command ......................................................................................................................... 150
DEFPN Command ............................................................................................................................ 153
DEFPRINT Command - DATASET Option .................................................................................... 156
DEFPRINT Command - FILE Option.............................................................................................. 159
DEFPRINT Command - SYSOUT Option....................................................................................... 161
DEFPRIO Command ........................................................................................................................ 163
DEFSIG Command........................................................................................................................... 164
DEFSPEC Command........................................................................................................................ 166
DEFSYML Command ...................................................................................................................... 169
DEFTJ Command ............................................................................................................................. 172
DEFTM: Define Tracking Model.................................................................................................... 174
DEFUSER Command ....................................................................................................................... 178
DELAT Command............................................................................................................................ 182
DELAYINT: Delay Interval ............................................................................................................ 183
DELAYSUB Statement .................................................................................................................... 184
DELCAL Command ......................................................................................................................... 187
DELETE Command - Event Definition........................................................................................... 188
DELETE Command - General.......................................................................................................... 189
DELGROUP Command.................................................................................................................... 190
DELHOL Command......................................................................................................................... 191
DELPN Command............................................................................................................................ 193
DELSIG Command........................................................................................................................... 194
DELSPEC Command........................................................................................................................ 195
DELSYML Command...................................................................................................................... 197
DELTJ Command............................................................................................................................. 198
DELTM Command........................................................................................................................... 200
DELUSER Command....................................................................................................................... 201
DESELECT Statement ..................................................................................................................... 202
DFLTUSER Command..................................................................................................................... 205
DFPNODE Command ...................................................................................................................... 207
DISCONN Command ....................................................................................................................... 209
DISPLAY Command........................................................................................................................ 210
DJCDATA Statement ....................................................................................................................... 212
DJCNET Statement .......................................................................................................................... 218
DN Command................................................................................................................................... 220
DO Statement.................................................................................................................................... 223
DOCLIB Statement........................................................................................................................... 225
DQ Command................................................................................................................................... 227
DSNAME Statement......................................................................................................................... 229
DSTRDLY Command ...................................................................................................................... 233
DSTREXCL Command .................................................................................................................... 235
DSTRIG Command .......................................................................................................................... 237
DSTRIG Statement ........................................................................................................................... 242
DSTRST Command.......................................................................................................................... 244
DUEOUT Statement ......................................................................................................................... 246
DURATION Statement..................................................................................................................... 250
EARLYSUB Statement .................................................................................................................... 251
ECHO Command.............................................................................................................................. 254
EICLASS Command......................................................................................................................... 256
EJECT Command ............................................................................................................................. 259
ELSE Statement................................................................................................................................ 260
9
END Command................................................................................................................................. 262
ENDDEF Command ......................................................................................................................... 263
ENDDO Statement ........................................................................................................................... 264
%ENDEXCL Statement ................................................................................................................... 266
ENDHC Command ........................................................................................................................... 268
%ENDINCL Statement..................................................................................................................... 269
ENDJOB Statement .......................................................................................................................... 271
ENDMODEL Command .................................................................................................................. 273
ENDPRINT Command ..................................................................................................................... 274
ENDR Command.............................................................................................................................. 275
ENDTEMPL Statement .................................................................................................................... 276
ESP Statement .................................................................................................................................. 277
ESPCOM Command......................................................................................................................... 279
ESPCTR Command .......................................................................................................................... 280
ESPNOMSG Statement .................................................................................................................... 282
//*ESPSYMBOL Statement.............................................................................................................. 284
EVENT Command............................................................................................................................ 286
EVENTOPT Command .................................................................................................................... 291
EVENTSET Command..................................................................................................................... 292
%EXCLUDE Statement ................................................................................................................... 295
EXIT Statement ................................................................................................................................ 299
EXPECT Command.......................................................................................................................... 302
FILENAME Statement ..................................................................................................................... 303
FILE_TRIGGER Statement.............................................................................................................. 305
FLAGUNDEF Statement.................................................................................................................. 307
FLOW Command.............................................................................................................................. 309
FOOTING Command ....................................................................................................................... 311
//* FROM Statement......................................................................................................................... 313
FROM Command.............................................................................................................................. 315
GENDOC Command ........................................................................................................................ 317
GENFLOW Command ..................................................................................................................... 319
GENPROJ Command ....................................................................................................................... 321
GENTIME Command....................................................................................................................... 323
GO Command................................................................................................................................... 327
GROUP Command ........................................................................................................................... 328
HARDCOPY Command - DATASET Option ................................................................................. 330
HARDCOPY Command - FILE Option ........................................................................................... 332
HARDCOPY Command - SYSOUT Option.................................................................................... 334
HISTFILE Command - Reporting .................................................................................................... 336
HISTFILE Command - Definition/Alteration .................................................................................. 338
HOLD Command - Event Level ....................................................................................................... 340
HOLD Command - General.............................................................................................................. 342
IF Statement ...................................................................................................................................... 344
%INCLUDE Statement..................................................................................................................... 346
INET Command................................................................................................................................ 350
INFOCOMM Command................................................................................................................... 353
INFOMSG Command....................................................................................................................... 355
INIT Command................................................................................................................................. 357
INPUT Command ............................................................................................................................. 359
INPUTDS Statement......................................................................................................................... 360
INTEGER Statement ........................................................................................................................ 362
INVOKE Command.......................................................................................................................... 365
JCLLIB Statement ............................................................................................................................ 367
JESCOMCH Command.................................................................................................................... 370
10
JESTYPE Command......................................................................................................................... 371
JOB Statement .................................................................................................................................. 372
JOBATTR Statement........................................................................................................................ 379
JOBINFO Command ........................................................................................................................ 382
JOBMAP Command......................................................................................................................... 386
JOBRES Command .......................................................................................................................... 391
JOBTREE Command........................................................................................................................ 392
JTPEXCL Command........................................................................................................................ 394
JUMPTO Statement.......................................................................................................................... 396
LABEL Command............................................................................................................................ 399
LATESUB Statement ....................................................................................................................... 401
LAX Command................................................................................................................................. 404
LCMDPRFX Command ................................................................................................................... 406
LDSN Command .............................................................................................................................. 407
LDTE Command............................................................................................................................... 408
LDTREL Command.......................................................................................................................... 409
LDXE Command .............................................................................................................................. 410
LIBSUB Command........................................................................................................................... 411
LIST Command ................................................................................................................................ 413
LISTAPPL Command....................................................................................................................... 416
LISTAPTF Command....................................................................................................................... 421
LISTAT Command........................................................................................................................... 422
LISTCAL Command ........................................................................................................................ 424
LISTCKPT Command ...................................................................................................................... 426
LISTEVS Command......................................................................................................................... 427
LISTGRP Command......................................................................................................................... 429
LISTHIST Command........................................................................................................................ 431
LISTHOL Command ........................................................................................................................ 432
LISTJTML Command ...................................................................................................................... 434
LISTPN Command ........................................................................................................................... 435
LISTQ Command.............................................................................................................................. 436
LISTSADL Command...................................................................................................................... 437
LISTSCH Command......................................................................................................................... 438
LISTSIG Command.......................................................................................................................... 441
LISTSPEC Command....................................................................................................................... 443
LISTSYML Command ..................................................................................................................... 446
LISTTRAK Command...................................................................................................................... 448
LISTUSER Command ...................................................................................................................... 449
LISTXMEZ Command ..................................................................................................................... 451
LJ Command..................................................................................................................................... 452
LOAD Command.............................................................................................................................. 455
LOADAGDF Command................................................................................................................... 457
LOADJTDT Command .................................................................................................................... 458
LOADSCHF Command.................................................................................................................... 460
LOADUPDT Command ................................................................................................................... 461
LOGPRT Command ......................................................................................................................... 462
LSAR Command............................................................................................................................... 463
LSYS Command............................................................................................................................... 468
LSYSMSGS Command .................................................................................................................... 470
LTCELL Command.......................................................................................................................... 471
LTJ Command .................................................................................................................................. 472
LTM Command ................................................................................................................................ 474
LTZONE Command ......................................................................................................................... 475
MAPGEN Command........................................................................................................................ 476
MAPUSER Command...................................................................................................................... 478
11
MAXINITS Command ..................................................................................................................... 479
MEMBER Statement ........................................................................................................................ 481
MGRADDR Command .................................................................................................................... 483
MGRMSG Command....................................................................................................................... 485
MODEL Statement ........................................................................................................................... 491
MODEL Command........................................................................................................................... 492
MONITOR Statement....................................................................................................................... 495
MREPORT Command...................................................................................................................... 497
MSG Command ................................................................................................................................ 500
MSGLIMIT Statement...................................................................................................................... 502
MSGTYPE Command ...................................................................................................................... 504
NEXT Command .............................................................................................................................. 507
NOCHECKEXC Statement .............................................................................................................. 509
NODE Command.............................................................................................................................. 510
NORUN Statement ........................................................................................................................... 512
NOSCHED Command...................................................................................................................... 515
NOTIFY Statement........................................................................................................................... 517
ON Command................................................................................................................................... 522
OPTIONS Statement......................................................................................................................... 525
PANSUB Command ......................................................................................................................... 529
PASSWORD Command ................................................................................................................... 531
PNODES Statement .......................................................................................................................... 532
POST Command............................................................................................................................... 535
POSTREQ Statement........................................................................................................................ 537
PREALLOC Command .................................................................................................................... 541
PREREQ Statement .......................................................................................................................... 543
PRIORITY Statement ....................................................................................................................... 547
PROFILE Statement ......................................................................................................................... 549
PURGSCHF Command .................................................................................................................... 551
QUIESCE Command........................................................................................................................ 553
QUIT Statement ................................................................................................................................ 554
QUPDATE Command ...................................................................................................................... 556
RACROUTE Command ................................................................................................................... 557
REEXEC Statement.......................................................................................................................... 559
RELCOUNT Statement .................................................................................................................... 562
RELDELAY Statement .................................................................................................................... 564
RELEASE Command - Event Level................................................................................................. 566
RELEASE Command - General ....................................................................................................... 568
RELEASE Statement ........................................................................................................................ 569
REMOVE Command........................................................................................................................ 572
REPORT Command.......................................................................................................................... 574
RESDEF Command.......................................................................................................................... 575
RESDFLT Command........................................................................................................................ 583
RESOLVE Statement ....................................................................................................................... 588
RESOURCE Statement..................................................................................................................... 590
RESREFR Command........................................................................................................................ 594
RESTART Command....................................................................................................................... 595
RESTORE Command....................................................................................................................... 596
RESUME - Event Level.................................................................................................................... 598
RESUME - General .......................................................................................................................... 600
REXXOFF Statement ....................................................................................................................... 601
REXXON Statement......................................................................................................................... 602
ROSSUB Command ......................................................................................................................... 605
ROUTE Statement ............................................................................................................................ 606
12
RUN Statement ................................................................................................................................. 608
SADGEN Command......................................................................................................................... 612
SADLINK Command ....................................................................................................................... 617
SADLOAD Command...................................................................................................................... 619
SADUPD Command......................................................................................................................... 621
SAFGRANT Command.................................................................................................................... 622
SAFOPTS Command........................................................................................................................ 624
SAFRDEF Command ....................................................................................................................... 627
SAFRDEL Command ....................................................................................................................... 628
SAFREVOK Command.................................................................................................................... 629
SCAN Command .............................................................................................................................. 630
SCHEDULE Command.................................................................................................................... 633
SECURE Statement .......................................................................................................................... 637
SELECT Statement........................................................................................................................... 638
SEND Command .............................................................................................................................. 642
SETPRINT Command ...................................................................................................................... 645
SETWIDTH Command .................................................................................................................... 646
SHADOW Command ....................................................................................................................... 647
SIGCYCLE Command ..................................................................................................................... 649
SIGPOST Command......................................................................................................................... 651
SIGWAIT Command........................................................................................................................ 653
SIMULATE Command..................................................................................................................... 655
SMFSTATS Command..................................................................................................................... 662
SORT Command............................................................................................................................... 663
SPACE Command ............................................................................................................................ 665
SPINLOG Command........................................................................................................................ 666
SPUSER Command .......................................................................................................................... 667
STATUS Command.......................................................................................................................... 668
STEPEND Statement........................................................................................................................ 669
SUBAPPL Statement ........................................................................................................................ 670
SUBMIT Command.......................................................................................................................... 675
SUSPEND Command - Event Level ................................................................................................ 678
SUSPEND Command - General ....................................................................................................... 680
SYMLIB Command.......................................................................................................................... 681
SYSMSGS Command....................................................................................................................... 683
TAG Statement ................................................................................................................................. 687
TEMPLATE Statement .................................................................................................................... 689
TEMPLIB Statement ........................................................................................................................ 694
TEST Command ............................................................................................................................... 696
THEN Statement............................................................................................................................... 698
TIME Command............................................................................................................................... 700
TITLE Command.............................................................................................................................. 701
TRACE Command............................................................................................................................ 704
TRACEDEF Command .................................................................................................................... 707
TRACEPRT Command .................................................................................................................... 709
TRACKDEF Command.................................................................................................................... 711
TRACKING Command .................................................................................................................... 716
TRACKOPT Command.................................................................................................................... 718
TRDFLT Command.......................................................................................................................... 721
TRIGGER Command........................................................................................................................ 722
TRYJOIN Command ........................................................................................................................ 727
UNALLOC Command...................................................................................................................... 728
//* UNTIL Statement ........................................................................................................................ 729
USE Command ................................................................................................................................. 731
USER Command............................................................................................................................... 732
13
USERMOD Command ..................................................................................................................... 733
VS Command.................................................................................................................................... 735
WILDCARD Statement .................................................................................................................... 737
XCF DELETE Command................................................................................................................. 739
XCF DISPLAY Command ............................................................................................................... 741
XCF FORCE Command ................................................................................................................... 744
XCF HELP Command...................................................................................................................... 746
XCF PURGE Command................................................................................................................... 747
XCF SET TERMOPT Command ..................................................................................................... 749
XCF SET TRACE Command........................................................................................................... 751
XCF SPIN TRACE Command ......................................................................................................... 752
XCF START SERVICE Command.................................................................................................. 753
XCF START TRACE Command ..................................................................................................... 754
XCF STOP GROUP Command........................................................................................................ 755
XCF STOP MEMBER Command.................................................................................................... 756
XCF STOP SERVICE Command..................................................................................................... 757
XCF STOP TRACE Command ........................................................................................................ 758
XCF VERIFY Command.................................................................................................................. 759
XMITMDL: Identify Tracking Models To Transmit ...................................................................... 760
14
15
ABANDON DEPENDENCIES Statement
Overview The ABANDON DEPENDENCIES statement is used to submit a job without its
predecessor dependencies once it meets a specified time. This does not override a
manual hold, a time dependency, or a resource dependency for a job.
Type ESP Application statement.
Syntax The syntax of the ABANDON DEPENDENCIES statement is:
ABANDON DEPENDENCIES criteria
Parameter Description
Criteria Schedule criteria that resolve to a single date and time.
Usage notes Specifying ABANDON DEPENDENCIES does not override a:
Manual hold
Time dependency
Resource dependency.
Related
information
For information on abandoning a submission time for a job, see the ABANDON
SUBMISSION statement.
For information on abandoning a jobs resource requirements, see the ABANDON
RESOURCES statement.
For information on manipulating jobs within Applications or subApplications, see the
APPLJOB or AJ command.
For information on Applications, see the ESP Workload Manager Users Guide.
16
ABANDON DEPENDENCIES Statement, Continued
Example 1 The following ABANDON DEPENDENCIES statement submits a job without its
predecessor dependency:
JOB PAYJOB1
RUN DAILY
RELEASE PAYJOB2
ENDJOB
JOB PAYJOB2
RUN DAILY
ABANDON DEPENDENCIES 9PM
ENDJOB
In the above example, PAYJOB2 is submitted at 9 pm or when PAYJOB1
completes, whichever comes first.
predecessor dependency:
JOB PAYJOB3
RUN DAILY
RELEASE PAYJOB4
ENDJOB
JOB PAYJOB4
RUN DAILY
DELAYSUB 6PM
ABANDON DEPENDENCIES 7PM
ENDJOB
In the above example, PAYJOB4 is not submitted until 6 pm, and its dependency on
PAYJOB3 is abandoned at 7 pm.
predecessor dependency, but not until a resource is available:
JOB PAYJOB5
RUN DAILY
RELEASE PAYJOB5
ENDJOB
JOB PAYJOB6
RUN DAILY
RESOURCE (1,T3480)
ABANDON DEPENDENCIES NOW PLUS 2 HOURS
ENDJOB
In the above example, PAYJOB6 has a dependency on PAYJOB5 that is abandoned
2 hours from the time the Application is scheduled. However, PAYJOB6 is not
submitted until 1 unit of a resource called T3480 is available.
17
ABANDON RESOURCES Statement
Overview The ABANDON RESOURCES statement is used to submit a job without its
resource dependencies at a specified time.
Syntax The syntax of the ABANDON RESOURCES statement is:
ABANDON RESOURCES criteria
Criteria Schedule criteria that resolve to a single date and time.
Usage notes Specifying ABANDON RESOURCES does not override a:
Manual hold
Time dependency.
Related
information
For information on abandoning a submission time for a job, see the ABANDON
For information on abandoning a jobs predecessor dependencies, see the
ABANDON DEPENDENCIES statement.
For information on manipulating jobs within Applications or subApplications, see the
Example 1 The following ABANDON RESOURCES statement submits a job without meeting
its resource requirement:
JOB PAYJOB1
RUN DAILY
RESOURCE (1,T3480)
ABANDON RESOURCES 9PM
ENDJOB
In the above example, PAYJOB1 is submitted at 9 pm or when 1 unit of a resource
called T3480 is available, whichever comes first.
18
ABANDON RESOURCES Statement, Continued
its resource requirement:
JOB PAYJOB2
RUN DAILY
RESOURCE (1,CICSUP)
ABANDON RESOURCES NOW PLUS 1 HOUR
ENDJOB
In the above example, PAYJOB2 is submitted 1 hour from the time the Application
was scheduled or when 1 unit of a resource called CICSUP is available, whichever
comes first.
its resource requirement based on the day of the week:
JOB PAYJOB3
RUN DAILY
RESOURCE (1,CICSUP)
IF TODAY(MONDAY) THEN -
ABANDON RESOURCES 7AM
ELSE -
ABANDON RESOURCES 9AM
ENDJOB
In the above example, PAYJOB3 is submitted at:
7 am on Mondays or when 1 unit of a resource called CICSUP is available
9 am on all other days or when 1 unit of a resource called CICSUP is available.
19
ABANDON SUBMISSION Statement
Overview The ABANDON SUBMISSION statement is used to bypass job submission at a
specified time.
Syntax The syntax of the ABANDON SUBMISSION statement is:
ABANDON SUBMISSION criteria
Criteria Schedule criteria that resolve to a single date and time when the
Application builds.
Usage notes When a jobs submission is abandoned, ESP flags the job with a status of EXEC
ABANDONED on the CSF, but retains the PREDWAIT PNODE until the job's
predecessors complete. Once the predecessors complete, the job is then bypassed.
The following example shows an abandoned jobs PNODE and STATUS
information:
Consolidated Status: View PAYROLL Row 1 of 3, Col 1
COMMAND ===> SCR ===> CSR
Jobname APPL PNODE STATUS
___ PAYJOB1 PAYROLL EXEC EXECUTING STEP1
___ PAYJOB2 PAYROLL PREDWAIT COMPLETE, EXEC ABANDONED
___ PAYJOB3 PAYROLL PREDWAIT WAITING, HC=1
In the above example, PAYJOB2s submission was abandoned, but it retained the
PREDWAIT PNODE. It waits for PAYJOB1 to complete before it becomes
bypassed.
Usage notes
continued
If you want to run PAYJOB3 immediately when PAYJOB2 is bypassed, use the
ABANDON DEPENDENCIES statement in combination with the ABANDON
Specifying ABANDON SUBMISSION does not override a:
Manual hold
Time dependency
Resource dependency.
20
ABANDON SUBMISSION Statement, Continued
Related
information
For information on abandoning a jobs predecessor dependencies, see the
ABANDON DEPENDENCIES statement.
For information on abandoning a jobs resource requirements, see the ABANDON
RESOURCES statement.
For information on manipulating jobs within Applications or subApplications, see
the APPLJOB or AJ command.
Example 1 The following ABANDON SUBMISSION statement abandons the submission of a
job at a specific time:
JOB PAYJOB1
RUN DAILY
REL PAYJOB2
ENDJOB
JOB PAYJOB2
RUN DAILY
ABANDON SUBMISSION 9PM
ENDJOB
In the above example, submission of PAYJOB2 is abandoned at 9 pm if PAYJOB1
is not complete by that time.
Example 2 The following ABANDON SUBMISSION statement abandons the submission of a
job at a specific time:
JOB PAYJOB3
RUN DAILY
REL PAYJOB4
ENDJOB
JOB PAYJOB4
RUN DAILY
ABANDON SUBMISSION NOW PLUS 1 HOUR
ENDJOB
In the above example, PAYJOB4s submission is abandoned 1 hour from the time
the Application was scheduled if PAYJOB3 has not completed by that time.
21
ABANDON SUBMISSION Statement, Continued
Example 3 The following ABANDON SUBMISSION statement abandons the submission of
multiple jobs:
APPL PAYROLL
JCLLIB CYBER.JCL.CNTL
JOB PAYJOB5
RUN WORKDAYS
REL PAYJOB6
JOB PAYJOB6
RUN WORKDAYS
REL PAYJOB7
JOB PAYJOB7
RUN WORKDAYS
ENDJOB
In the above example, if PAYJOB5 does not complete by 9 pm, PAYJOB6 and
PAYJOB7 are not run.
Note: To abandon a group of jobs, consider using subApplications. You can then
use Alert processing to bypass a group of jobs with one command. Refer to the ESP
Workload Manager Advanced Users Guide.
Example 4 The following ABANDON SUBMISSION and ABANDON DEPENCENCIES
statements are used to abandon the submission of a job and allow the abandoned
jobs successor to be submitted.
JOB PAYJOB8
RUN DAILY
REL PAYJOB9
ENDJOB
JOB PAYJOB9
RUN DAILY
REL PAYJOB10
ABANDON SUBMISSION 03.00
ABANDON DEPENDENCIES 03.01
ENDJOB
JOB PAYJOB10
RUN DAILY
ENDJOB
In the above example, If PAYJOB9 is not submitted by 3 am:
Submission is abandoned
Dependency on PAYJOB8 is dropped at 3:01
PAYJOB9 is marked complete, and the hold count of PAYJOB10 is decremented
ABANDON DEPENDENCIES time is slightly later than the ABANDON
SUBMISSION time to avoid timing problems.
22
ABENDLIM Command
Overview The ABENDLIM command is used to display or set the abend queue size for jobs
that ESP is tracking which produce a non-zero return code.
Type General command.
Authority OPER authority is required to issue the ABENDLIM command.
Syntax The syntax of the ABENDLIM command is:
ABENDLIM [count]
count Indicates the abend queue size. There is no default. If a count
is not specified, the abend queue size is displayed.
Usage notes When ESP detects that one of the jobs it is tracking abends or produces a non-zero
return code, it adds an entry to a list of abended jobs. The entry identifies the
jobname, job number, termination time and completion code.
The ABENDLIM command specifies how long the list is to be allowed to grow.
Once the list has grown to its full size, i.e. the count you specify, each newly
abended job causes the removal of the oldest job from the list. Thus, specifying
ABENDLIM 100 causes ESP to keep track of the last 100 abended jobs.
It is not required that an ABENDLIM count be specified, as job abend information
can be displayed using other commands, i.e. LJ, LTJ jobname I and the CSF.
If an ABENDLIM count is specified, you can display abended jobs using the DAB
(display abended jobs) command.
If you increase the ABENDLIM count, ESP begins to store a longer list of jobs from
the point at which you issue the command. For example, if you change ABENDLIM
from 20 to 100, you will not immediately see any changes in a DAB display.
23
ABENDLIM Command, Continued
Related
information
For information on displaying the abended queue, see the DAB (display abended
queue) command.
For information on displaying job information, see the LJ (list job status) command.
For information on displaying job information, see the LTJ (list a tracked job
definition) command.
For information on displaying abended jobs using the CSF, see the ESP Workload
Manager Users Guide.
Example 1 This following ABENDLIM command displays the abend queue size:
ABENDLIM
In the above example, when the ABENDLIM command is issued with no count
parameter, the following display is produced indicating the abend queue size and the
number of abended jobs:
ABEND QUEUE MAX = 20, 4 CURRENTLY QUEUED
Example 2 The following ABENDLIM command sets the abend queue size:
ABENDLIM 100
In the above example, the abend queue size is set to 100, indicating that ESP keeps
track of the last 100 abended jobs.
24
ABSORB Statement
Overview The ABSORB statement is used to reserve a quantity of resources for jobs that
require a large resource count. Resource Absorption reserves the resources that are
available at the time the job is next in the queue and holds them while waiting to
accumulate the remainder of resources required for that job. Jobs with smaller
resource requirements cannot use the reserved resource. The ABSORB statement
prevents jobs with large resource requirements incurring a processing delay.
Syntax The syntax of the ABSORB statement is:
ABSORB
Usage The ABSORB statement will only ABSORB resources if the request is for less than
or equal to the maximum resource defined. An ABSORB statement is coded within
the scope of the job statement, above the RESOURCE statement, where Resource
Absorption is to occur. ABSORB can also be used at the Application level.
Example
Absorb
statement
This example shows coding an ABSORB statement within the scope of the job
statement:
APPL ABSRES
JCLLIB CYBER.JCLLIB.CNTL
JOB JOBX
RUN DAILY
ABSORB
RESOURCE (4,T3480)
ENDJOB
When JOBX is first in the queue, the Resource Manager begins the process of
reserving the required resources, 4 units of T3480. Jobs that follow JOBX in the
queue that require less than or equal to the same resource, and are the same job
priority, will not be submitted before JOBX.
Note:
A job with a higher priority and the same resource requirements will take the
resources and run before the lower priority job with the ABSORB statement. Once
the higher priority job completes, or has the resources it needs, the process of
gathering resources starts again.
Types of
resources
Absorption is available for the following types of resources:
Renewable
Depletable.
25
ADJUST Command
Overview The ADJUST command is used to adjust the execution time or CPU time for one or
more jobs when using ESPs modeling feature to forecast future workload.
Type Model command.
Syntax The syntax of the ADJUST command is:
ADJUST [EXECTIME(factor)]
[CPUTIME(factor)]
[JOBS(jobname[,jobname]...)]
EXECTIME Indicates that an adjustment is to be made to the execution time
(or elapsed run time) of the requested job(s).
CPUTIME Indicates that an adjustment is to be made to the CPU time of
the requested job(s).
factor Indicates the adjustment factor expressed as a percentage.
Prefix the adjustment factor with a + or - sign, which
allows the MODEL processor to determine whether the
execution time or CPU time should be increased or decreased.
JOBS Limits the adjustment(s) to one or more jobnames or job
prefixes. The adjustment(s) are applied to all jobs in the
modeling period if the JOBS keyword is not specified.
jobname Indicates one to eight alphanumeric character jobname or list of
jobnames to which the adjustment(s) apply. Asterisks or a
hyphen as the last character may be used to perform masking.
Restriction The ADJUST command is only available with Modeling.
Usage notes ESP estimates a jobs execution time and CPU time based on historical data. An
adjustment factor alters these estimates. You can adjust the execution time or CPU
time for one or more jobs.
This may be useful when elapsed run times for jobs vary greatly at different times of
the year, such as at year-end.
Related
information
For information on forecasting future workload, see the ESP Workload Manager
Users and Advanced Users Guides.
26
ADJUST Command, Continued
Example 1 The following ADJUST command adjusts the CPU time and execution time for all
jobs in the modeling period:
ADJUST EXECTIME(-10) CPUTIME(-30)
In the above example:
The execution time is adjusted by -10%
The CPU time is adjusted by -30%.
Example 2 The following ADJUST command adjusts the execution time for specific jobs:
ADJUST EXECTIME(+300) JOBS(ACC-,YEND****)
In the above example, the execution time is adjusted by +300% for all jobs
beginning with ACC, or having YEND as the first 4 characters of their jobnames.
Example 3 The following ADJUST command adjust the execution time for a specific job on a
specific day:
IF TODAY(LAST DAY OF MONTH) THEN -
ADJUST EXECTIME(+200) JOB(PAYJOB1)
In the above example, the execution time is adjusted by +200% for PAYJOB1 on the
last day of the month.
27
AFTER Statement
Overview The AFTER statement is used to specify any job(s) which are predecessors to a job
and should indicate a release to this job upon completion. The default is successful
completion.
Syntax The syntax of the AFTER statement is:
AFTER {jobname}
{(jobname{(A)|(U)|(N)[,jobname(A)|(U)|(N]...})}
{ADD(jobname{(A)|(U)|(N)[,jobname(A)|(U)|(N]...})}
{DROP(jobname{(A)|(U)|(N)[,jobname(A)|(U)|(N]...})}
jobname Indicates a jobname up to eight characters. Enclose multiple job
names in parentheses, separated by a blank or a comma.
Jobnames may be qualified.
ADD Indicates that the specified job(s) be added to the currently
defined AFTERs.
DROP Indicates that the specified job(s) be dropped from the currently
defined AFTERs.
A Release on abnormal termination of a predecessor. This
includes condition code failures.
N Release on successful termination of a predecessor. This is the
default.
U Release on any termination of a predecessor.
Usage notes Use AFTER to indicate the names of job(s) that are predecessors to this job and
which will decrement the hold count on this job upon completion.
The termination parameters (A, U, N) are available only for jobs in an Application.
Note: This is different from the way the AFTER support on a DJCDATA statement
works.
Related
information
For information on other ways specifying predecessor and successor relationships,
see the RELEASE, PREREQ and POSTREQ statements.
For information on specifying predecessor and successor relationships, see the ESP
Workload Manager Users Guide.
For jobs in JES3 or DJC jobnets, see the ABNORMAL and NORMAL parameters
as documented in the JES3 or DJC Users Guide.
28
AFTER Statement, Continued
Example 1 The following AFTER statement is used to indicate job relationships:
APPL PAYROLL
JOB PAYJOB1
RUN DAILY
ENDJOB
JOB PAYJOB2
RUN DAILY
AFTER PAYJOB1
ENDJOB
In the above example, PAYJOB2 is submitted after the successful completion of
PAYJOB1.
Example 2 The following AFTER statement is used to indicate job relationships:
APPL PAYROLL
JOB PAYJOB3
RUN DAILY
ENDJOB
JOB PAYJOB4
RUN DAILY
ENDJOB
JOB PAYJOB5
RUN DAILY
AFTER (PAYJOB3(U),PAYJOB4)
ENDJOB
In the above example, PAYJOB5 is submitted after any termination of PAYJOB3
and the successful completion of PAYJOB4.
29
Example 3 The following AFTER and AFTER ADD statements are used to indicate job
relationships:
APPL PAYROLL
JOB PAYJOB6
RUN DAILY
ENDJOB
JOB PAYJOB7
RUN DAILY
ENDJOB
JOB PAYJOB8
RUN DAILY
AFTER PAYJOB6
AFTER ADD(PAYJOB7)
ENDJOB
PAYJOB6 and PAYJOB7.
Example 4 The following AFTER statements are used to indicate job relationships:
APPL PAYROLL
JOB PAYJOB9
RUN DAILY
ENDJOB
JOB PAYJOB10
RUN DAILY
AFTER PAYJOB9
ENDJOB
JOB PAYJOB11 CONDITIONAL
RUN DAILY
AFTER (PAYJOB10(A))
ENDJOB
PAYJOB9. PAYJOB11 is conditional upon the abnormal completion of
PAYJOB10. If PAYJOB10 completes successfully, PAYJOB11 is bypassed.
30
Example 5 The following AFTER and AFTER ADD statements are used to indicate job
relationships:
APPL PAYROLL
JOB PAYJOB12
RUN DAILY
ENDJOB
JOB PAYJOB13
RUN DAILY
ENDJOB
JOB PAYJOB14
RUN DAILY
AFTER ADD(PAYJOB12)
AFTER ADD(PAYJOB13)
ENDJOB
PAYJOB12 and PAYJOB13.
Other examples Here are more examples using the AFTER statement:
Indicates that PAYJOB4 has 3 predecessors that must complete successfully before
it is submitted:
JOB PAYJOB4
AFTER (PAYJOB1,PAYJOB2,PAYJOB3)
Indicates that PAYJOB5 is to be released after an abnormal termination of
PAYJOB1:
JOB PAYJOB5
AFTER (PAYJOB1(A))
Indicates that PAYJOB6 is to be released after all three of the following conditions
are met:
The successful completion of PAYJOB1
An abnormal termination of PAYJOB2
Any termination of PAYJOB3.
JOB PAYJOB6
AFTER PAYJOB1
AFTER ADD(PAYJOB2(A))
AFTER ADD(PAYJOB3(U))
31
AGENT Command
Overview The AGENT command is used to display the contents of the Agent Definition file
(AGENTDEF), and controls the flow of messages to the Agent.
Authority OPER authority is required to issue the AGENT command.
Syntax
The syntax of the AGENT command is:
OPER AGENT [name]
[name LIST(ALL|CM_OWNED|DM_OWNED|ORPHANS)]
[name FLUSH|QUIESCE|RESTART]
AGENT Displays the contents of the Agent Definition file.
name Name specifies the name of the target Agent as defined in the
Agent Definition file.
Note:
Can be a valid Agent name as defined in the Agent
Definition file, or wild cards (any character wild card)
or * (single character wild card).
If name is not specified, the command is equal to:
AGENT LIST, which lists the contents of the Agent
Definition file for all Agents attached to this Central
Manager.
LIST Lists the contents of the Agent Definition file for the named
Agent. This is the default.
Result:
Name of the Agent
IP address and port of the Agent
Communication protocol
Prefixing options
Encryption options
Character set
OS platform
Retry interval
Owning Manager
Active sessions
32
AGENT Command, Continued
ALL Lists all types of Agents, including those owned by the
Central Manager, those owned by a Distributed Manager, and
those that have no current owner.
CM_OWNED Lists all Agents owned by the central Manager.
DM_OWNED Lists all Agents owned by Distributed Manager(s).
ORPHANS Lists all Agents that currently have no owner assigned.
FLUSH Purges all pending messages for each specified Agent. In ESP
Version 5 Release 2, FLUSH is used with the ESPCOM
command.
QUIESCE Holds all messages to be sent to the named Agent until the
RESTART command is issued.
RESTART Resumes sending messages to the named Agent. Used
following the use of QUIESCE.
Example 1 The following is an example of the AGENT command:
OPER AGENT
Response received from the above command:
HP_CHI
Address 131.50.25.12
Port 3001
CommType TCP/IP, No prefixing, No encryption, Charcode ASCII,
OS UNIX
Retry Interval 0
Owned by 131.50.30.15
No active session for this Agent.
In this example, there is only one Agent attached to the Workload Manager where
the command was issued.
Example 2 The following is an example of the AGENT command used to hold the messages to
an Agent:
OPER AGENT HP QUIESCE
In this example, the Agent HP is quiesced.
Example 3 The following is an example of the AGENT command used to restart the sending of
messages to the Agent after a QUIESCE command was issued:
OPER AGENT HP RESTART
In this example, the Agent HP is restarted.
33
AGENT Command, Continued
Example 4 The following is an example of the AGENT command used to purge message
queues:
OPER AGENT HP- FLUSH
In this example, the wildcard (-) is used resulting in message queues of all Agents
whose names begin with HP being purged.
Example 5 The following is an example of the AGENT command used to list all Agents owned
by Distributed Manager(s):
OPER AGENT LIST(DM_OWNED)
34
AGENTMSG Command
Overview The AGENTMSG command is used to issue commands and send messages to
Agents.
Authority OPER authority is required to issue the AGENTMSG command.
To issue the AGENTMSG command, you require read access to the SAF resource:
AGENTMSG.verbsubverb.name.
Syntax
The syntax of the AGENTMSG command is:
AGENTMSG {date|.} {time|.} agentname {from|.} {objectname|.}
[CONTROL SETINITS|SHUTDOWN|CANCEL|FLUSH|REFRESH|CLRFILES]
[MGRADDR port()|address()]
date Indicates the date the message is sent. Specify the actual date
or use a period(.) as a placeholder, if omitting the date.
time Indicates the time the message is sent. Specify the actual time
or use a period(.) as a placeholder, if omitting the time.
agentname The name of the target Agent.
from Indicates who the message is from. Specify who the message
is from or use a period(.) as a placeholder, if omitting who it
is from.
35
AGENTMSG Command, Continued
Syntax cont
objectname The name of the UNIX workload object to which the
command refers. This is a multi-option field. For commands
that are not related to a specific workload object, specify a
period(.) in place of the object name.
Note: To cancel the script, specify the name in the following
format: jobname/appl.gen/MAIN
CONTROL Indicates the action to be taken, keywords entered as shown.
The following are the options used with CONTROL:
SETINITS nnnn
Sets the maximum number of initializations allowed
on the Agent.
Nnnn is the new number.
Results in the workload object being ignored.
SHUTDOWN
Instructs the Agent to shutdown after the work that
was executing completes.
CANCEL
Stops the specified workload object if it has already
started.
Removes the specified workload object from the
input queue, if it has not already started.
FLUSH
Flushes the specified workload object from
the input queue, if it has not already started
execution.
Does not effect the workload object, if the WOB has
already started.
Sends status back to the Manager.
REFRESH
Causes the Agent to reload the security file.
CLRFILES
Clears the schedwork file and commlog file.
36
AGENTMSG Command, Continued
Syntax cont
MGRADDR Tells the Agent to respond to messages from the Manager on
a new IP address and port. Is used when the Manager is
moved to a new machine, or when you want the Agent to take
direction from a different Manager. This is a temporary
change, until the next time the Agent is restarted.
port( ) Indicates the new port number.
address( ) Indicates the new IP address.
Examples The following example shows using the AGENTMSG command to shutdown the
Agent named UNIX_CHICAGO:
AGENTMSG . . UNIX_CHICAGO . . CONTROL SHUTDOWN
In the next example, the Agent named UNIX_RENO is told to cancel the workload
object emp.date in generation 3 of the application EMPADDR:
AGENTMSG . . UNIX_RENO . emp.data/EMPADDR.3/MAIN CONTROL
CANCEL
37
AGENTRCV Command
Overview The AGENTRCV command is used to define and display the Managers receiver
function for communication with ESP agents.

Authority OPER authority is required to issue the AGENTRCV command.
Syntax The syntax of the AGENTRCV statement is:
OPER AGENTRCV
[DEFINE] [NAME(name)]
[DELETE]
[LIST]
[HALT]
[QUIESCE]
[RESTART]
[SET]
[PORT(portnumber)]
[SYMDEST(symdest)]
[LU(luname) TPNAME(tpname) LOGMODE(logmode)]
[POLLINGINTERVAL(interval1[,interval2])]
[{DUMPMSGS|NODUMPMSGS}]
[ENCRYPT|NOENCRYPT]
name Indicates a unique 1 to 8 character agent receiver
name. The first character must be alphabetic or a
national character. It is optional for the DISPLAY
and LIST options and required for all other
options.
DEFINE Defines an Agent receiver to the ESP subsystem
and starts it.
DELETE Stops an Agent receiver and deletes it from the
ESP subsystem.
LIST Displays the status of the ESP subsystems Agent
receiver(s). This is the default.
HALT Stops an Agent receiver without deleting it.
QUIESCE Stops an Agent receiver without deleting it. An
alias of HALT.
RESTART Restarts an Agent receiver that has been HALTed
or QUIESCEd.
38
AGENTRCV Command, Continued
Syntax (continued)
SET Sets an Agent receiver parameter dynamically.
PORT Indicates the TCP port number of a TCP/IP Agent
receiver. This parameter is only valid with the
DEFINE and SET options. If specified with the
SET option, the Agent receiver must be in a halted
state. This parameter is mutually exclusive with
the,
POLLINGINTERVAL LOGMODE, LU,
MESSAGEQUEUENAME, SYMDEST and
TPNAME parameters.
portnumber TCP/IP port number.
SYMDEST Indicates a symbolic destination name in the
APPC side information file that represents the
Agent LU (Logical Unit) and TP (Transaction
Program) name, and the LOGMODE name of the
session on which the APPC conversation is to be
carried. This parameter may only be specified
with the DEFINE and SET options. This
parameter is mutually exclusive with the PORT
parameter.
symdest Specifies where Agent messages are received in an
APPC/APPN network.
LU Indicates the LU (Logical Unit) name of an APPC
Agent receiver. This parameter may only be
specified with the DEFINE and SET options. If
specified with the DEFINE option and the
SYMDEST parameter is omitted, then the
LOGMODE and TPNAME parameters must also
be specified. This parameter is mutually exclusive
with the PORT parameter.
luname APPC LU (Logical Unit) name.
TPNAME Indicates the TP (Transaction Program) name of
the APPC Agent. This parameter may only be
specified with the DEFINE and SET options. If
specified with the DEFINE option and the
SYMDEST parameter is omitted, then the
LOGMODE and LU parameters must also be
specified. This parameter is mutually exclusive
tpname APPC TP (Transaction Program) name.
39
Syntax (continued)
LOGMODE Indicates the mode name designating the network
properties for the session to be allocated for the
APPC conversation with the Agent. This
parameter may only be specified with the DEFINE
and SET options. If specified with the DEFINE
option and the SYMDEST parameter is omitted,
then the LU and TPNAME parameters must also
be specified. This parameter is mutually exclusive
logmode APPC logmode name.
POLLINGINTERVAL Indicates polling intervals for an APPC receiver.
This parameter is only valid with the DEFINE and
SET options. It is mutually exclusive with the
PORT parameter.
interval1 Indicates the polling interval in seconds for an
APPC agent receiver. If omitted, the default is 5
seconds.
interval2 Indicates the polling interval in seconds for an
APPC agent receiver if an error occurs. This
value should be higher than interval1. If
omitted, interval1 is used.
DUMPMSGS/
NODUMPMSGS
All the specified agent receivers messages are
written to the console in a dump format
(DUMPMSGS). May only be specified with the
DEFINE and SET options.
ENCRYPT Specifies encrypted data will be accepted.
NOENCRYPT Specifies that both encrypted and unencrypted
data can be received.
Usage notes Agent clients of versions earlier than 1.2 must connect to an Agent receiver that
specifies PREFIXING. Agent clients version 1.2 or later provide an option
(CommMsgPrefix=Y - see the Agent documentation for details) to specify
PREFIXING.
An Agent that specifies CommMsgPrefix=Y must connect to an Agent receiver that
specifies PREFIXING. All other Agents must connect to an Agent receiver that
specifies (or defaults to) NOPREFIXING. Cybermation recommends the use of
PREFIXING wherever possible.
Prefixing
update
In ESP Workload Manager Version 5 Release 2 the PREFIXING|NOPREFIXING
keywords are obsolete. ESP Workload Manager automatically determines if
prefixing is used or not.
40
Example 1 The following AGENTRCV command displays agent receivers:
AGENTRCV
In the above example, the status of the ESP subsystems agent receivers are
displayed
Example 2 The following AGENTRCV command is used to define and start a TCP/IP agent
receiver:
AGENTRCV DEFINE NAME(CYBTCPIP) PORT(6664)
In the above example, an agent receiver named CYBTCPIP is started and will listens
for incoming connections on TCP/IP port 6664.
Example 3 The following AGENTRCV command is used to stop a TCP/IP agent receiver:
AGENTRCV HALT NAME(CYBTCPIP)
or
AGENTRCV QUIESCE NAME(CYBTCPIP)
In the above example, an agent receiver named CYBTCPIP is stopped using either
HALT or QUIESCE.
Example 4 The following AGENTRCV command is used to reset the TCP port: of the above
TCP/IP agent receiver to 6667:
AGENTRCV SET NAME(CYBTCPIP) PORT(6667)
In the above example, the TCP/IP port is reset to port 6667 for an agent receiver
named CYBTCPIP.
41
ALERTDEF Command
Overview The ALERTDEF command is used to define and display alert definitions. An Alert
definition points to an Event that is automatically triggered when the Alert is
processed as part of a NOTIFY statement.
Authority OPER authority is required to issue the ALERTDEF command.
Syntax The syntax of the ALERTDEF command is:
ALERTDEF {ADD|ALTER|DELETE|LIST}
[ID(xxxx)]
[EVENT(eventid)]
ADD Add an Alert definition.
ALTER Alter the Event identifier of a previously defined Alert
definition.
DELETE Delete an Alert definition.
LIST Display one or more Alert definitions. This is the default.
xxxx One to four-character logical identifier of the Alert definition.
This identifier is used in conjunction with a NOTIFY statement
in an ESP Procedure.
eventid Name of the Event to be automatically triggered when this
Alert is invoked as a result of workload reaching a particular
stage in processing, i.e. jobend or failure.
42
ALERTDEF Command, Continued
Usage notes The Alert feature enables ESP to trigger an Event for all jobs, or only specific jobs,
in an ESP Application. You can trigger the Event at different monitor points, such as
time of job submission, job start time, or when a job becomes overdue at any
processing stage. These correspond to the different processing points supported on
the NOTIFY statement.
To use the Alert feature, take these three steps:
1. Use the NOTIFY statement in an ESP Application to identify when to trigger the
Alert.
2. Define the Alert with the ALERTDEF command.
3. Define the Event triggered by the Alert.
Alerts can be defined dynamically; i.e. via Page mode, but are not retained across
recycles of ESP. To ensure that Alert definitions are retained across recycles of
ESP, insert the appropriate ALERTDEF commands in the ESP Workload Manager
Initialization Parameters.
Related
information
For information on triggering Events automatically when workload reaches a
particular stage in processing, see the ESP Workload Manager Users Guide.
For information on notifying users or consoles, or triggering an Event when
workload reaches a particular stage in processing, see the NOTIFY statement.
Example 1 The following ALERTDEF command defines an Alert and associates that Alert with
an Event name:
ALERTDEF ADD ID(INFO) EVENT(CYBER.CREATE_RECORD)
In the above example, an Alert with a logical identifier of INFO is defined and
associated with an Event called CYBER.CREATE_RECORD, which is
automatically triggered when the following NOTIFY statement appears in an ESP
Application:
NOTIFY ABEND ALERT(INFO)
Example 2 The following ALERTDEF command alters an alert to associate it with a new Event
name:
ALERTDEF ALTER ID(INFO) EVENT(CYBER.CREATE_INFO_RECORD)
In the above example, an alert with a logical identifier of INFO is altered to
associate it with a new Event - CYBER.CREATE_INFO_RECORD.
43
ALERTDEF Command, Continued
Example 3 The following ALERTDEF command displays all Alerts:
ALERTDEF
In the above example, all defined Alerts are displayed.
Example 4 The following ALERTDEF command deletes an alert:
ALERTDEF DELETE ID(INFO)
In the above example, an alert with a logical identifier of INFO is deleted.
Example 5 The following ALERTDEF command displays an alert:
ALERTDEF ID(INFO)
In the above example, an alert with a logical identifier of INFO is displayed.
44
ALLOWUNDEF Statement
Overview The ALLOWUNDEF statement is used to turn off the flagging of undefined
symbols in a symbolic variable library data set.
Type Symbolic variable library statement.
Syntax The syntax of the ALLOWUNDEF statement is:
ALLOWUNDEF
Restriction The ALLOWUNDEF statement cannot be used in ESP Procedures.
Usage notes The ALLOWUNDEF statement complements the FLAGUNDEF statement, which
requests the flagging of undefined symbols.
ALLOWUNDEF turns off the flagging so that undefined symbols can be processed
without an error message being issued.
By default, ESP allows undefined symbols.
Related
Statements
For information on flagging undefined symbols, see the FLAGUNDEF statement.
Example 1 The following FLAGUNDEF and ALLOWUNDEF statements turn the flagging of
undefined symbols on and off:
FLAGUNDEF
A=%BC
ALLOWUNDEF
B=%XY
In the above example, when ESP encounters these undefined symbols while
submitting a job:
A=%BC results in an error message - flagging is on (FLAGUNDEF)
B takes on the value of %XY - flagging is off (ALLOWUNDEF).
45
ALTCAL Command
Overview The ALTCAL command is used to modify an existing calendar definition.
Authority SPECIAL or CALENDARDEF authority is required to issue the ALTCAL
command in non-SAF environments. With SAF you control access to calendars
using the CALENDAR.calname resource.
Syntax The syntax of the ALTCAL command is:
{ALTCAL|ALTC} calname
[LOGICAL|ABSOLUTE]
[SHIFT(hh:mm)]
[WEEKSTART(day)]
[WORKDAYS(workday[,workday]...)]
calname Indicates the name of the calendar to be modified.
LOGICAL/
ABSOLUTE
Indicates a logical or absolute calendar. If you are modifying
from an absolute calendar to a logical calendar, you need to
specify both logical and SHIFT(hh:mm).
hh:mm Modifies the start time of a logical day.
day Indicates the first day of the week.
workday Indicates which days are to be considered workdays.
Separate each with a blank or comma.
Usage notes Cybermation recommends you use absolute calendars because of their ease of use.
Related
information
For information on defining and deleting calendars, see the DEFCAL and DELCAL
commands.
For information on working with calendars, see the ESP Workload Manager
Administrators Guide.
Example 1 The following ALTCAL command modifies the first day of the week:
ALTCAL PAYROLL WEEKSTART(MONDAY)
In the above example, the first day of the week is changed to MONDAY on the
PAYROLL calendar.
46
ALTCAL Command, Continued
Example 2 The following ALTCAL command modifies the start time of each logical day:
ALTCAL FISCAL SHIFT(09:00)
In the above example, each logical day on the FISCAL calendar is changed to start a
9 am.
47
ALTEVENT Command
Overview The ALTEVENT command is used to change certain characteristics of one or more
Events. Specify any number of parameters to cause multiple changes to a single
Event or group of Events to which you have access.
Authority You can only alter Events to which you have access.
Syntax The syntax of the ALTEVENT command is:
ALTEVENT eventid
{[CLASS(classname)]}
{[CALENDAR(cal1[,cal2]...)]}
{[ADD(hours,minutes)|SUBTRACT(hours,minutes)]}
{[EVENTSET(evdsid)]}
{[SYMLIB(sym1[,sym2]...)]}
{[SYSTEM(newsys,oldsys)]}
eventid Indicates an Event identifier. It may contain asterisks and
hyphens when a group of Events are to be altered at one time.
classname Indicates a new ESP class, up to eight alphanumeric
characters, the first of which must be alphabetic.
cal1 Indicates a calendar name, up to eight alphanumeric
characters, the first of which is alphabetic.
cal2 Indicates a calendar name, up to eight alphanumeric
characters, the first of which is alphabetic.
hours,minutes Indicates the changes you want to make to the scheduled
execution times. You can add or subtract hours and minutes
to compute a new set of time and date schedules. If you only
want to change the time by a certain number of minutes,
specify a zero in the hours field, e.g. ADD(0,45).
evdsid Indicates the ID of an Event data set. This allows you to limit
changes to a particular Eventset in a non-SAF environment.
sym1-sym3 Indicates one, two or three-replacement symbol-library
names, separated by a blank or comma. An asterisk is
permitted instead of a name if you want to change one symbol
library without affecting others.
newsys Indicates an ESP system ID. This is the SYSTEM identifier
to which you are changing.
oldsys Indicates an ESP system ID on which an ESP subsystem is
running. It may contain asterisks and a hyphen. It limits
changes to Events to be executed on the specified system ID.
This is the SYSTEM identifier from which you are changing.
48
ALTEVENT Command, Continued
Usage notes Use the SYSTEM parameter to change Events queued to a specific system or
systems. This is required when the ESP system identifier changes.
If you are altering the system ID or changing execution times, the schedule is altered
at the next scheduled scan. If the Event is already scheduled on another system, it
executes on that system. When the next days schedule is built, the new system ID
is taken into account. In the same way, the schedule changes come into effect
following the schedule scan.
To alter other characteristics of an Event or group of Events such as JCL library:
1. Use the LIST command with the ALL parameter in Page mode
2. Type EDIT
3. Make the required changes and then save them to a data set (i.e. CREATE)
4. Use the LOAD command to load the data set to ESP.
Note: When the ALTEVENT command contains asterisks or a hyphen, all matching
entries are altered. If you are unsure which Events a particular command affects,
use a LIST command to test the specified mask.
You cannot alter the Eventset for one or more Events with the ALTEVENT
command.
Related
information
For information on working with Events, see the ESP Workload Manager Users
Guide.
Example 1 The following ALTEVENT command changes the system on which a group of
Events execute to an alternative system:
ALTEVENT MYGROUP.- SYSTEM(PROD TEST)
In the above example, Events in MYGROUP are altered to execute on system
PROD, instead of system TEST.
Example 2 The following ALTEVENT command changes the class associated with a group of
Events:
ALTEVENT PROD.PAY- CLASS(PAYJOBS)
In the above example, Events that start with PROD.PAY have their Event class
changed to PAYJOBS.
49
ALTEVENT Command, Continued
Example 3 The following ALTEVENT command changes the symbol library that a group of
Events access:
ALTEVENT MYGROUP.- SYMLIB(SYSSM1,MYSYM)
In the above example, Events in MYGROUP are altered to access symbol libraries
SYSSM1 and MYSYM.
Note: If you want to change the second or third SYMLIB without affecting an
intervening one, specify an asterisk in the place of the unaffected SYMLIB as
follows:
ALTEVENT PROD.- SYMLIB(* * PRODSYMS)
In the above example, the third SYMLIB is changed to PRODSYMS. The first and
second SYMLIBS remain the same.
Example 4 The following ALTEVENT command advances the scheduled execution time of an
Event:
ALTEVENT CYBER.EARLY SUBTRACT(0,30)
In the above example, CYBER.EARLYs scheduled execution time is advanced
(brought forward) by 30 minutes.
Example 5 The following ALTEVENT command changes the system identifier:
ALTEVENT - SYSTEM(SYSB,SYSA) EVENTSET(CLIENT1)
In the above example, the system identifier is changed from SYSA to SYSB, for all
Events in Eventset CLIENT1.
Example 6 The following ALTEVENT command alters the calendars referenced by an Event:
ALTEVENT PAYROLL.JOBS CALENDAR(*,PAYCAL3)
In the above example, PAYROLL.JOBS secondary calendar is changed to reference
PAYCAL3.
Example 7 The following ALTEVENT command delays the scheduled execution time of an
Event:
ALTEVENT PROD.DAILY ADD(2,30)
In the above example, all of the PROD.DAILY Events have their scheduled
execution time delayed by 2 hours and 30 minutes.
50
ALTGROUP Command
Overview The ALTGROUP command is used to modify an existing group definition.
Authority SPECIAL or GROUPDEF authority is required to issue the ALTGROUP command.
Note: ALTGROUP is applicable only when using ESP Workload Managers
internal security.
Syntax The syntax of the ALTGROUP command is:
{ALTGROUP} groupname
{ALTG}
{[EVENTSET(eventdsid)]}
{[DEPARTMENT(deptid)]}
{[AUTH {(OPER)|(NOOPER)]}
{[UREAD|NOUREAD]}
{[RACID|NORACID]}
{[CALENDAR(cal1[,cal2]...)]}
groupname Indicates the specific name of an ESP group.
eventdsid Indicates the logical identifier of the Event database used to
store Events prefixed with the group name.
deptid Indicates a department name of up to eight characters to
which this group belongs. It may contain asterisks and may
also have a hyphen in the last character position.
OPER Indicates that Events having this group name as a prefix can
contain operator commands.
NOOPER Removes the OPER attribute.
UREAD Indicates that universal read access is available for any Event
defined using this group prefix.
RACID Indicates that the security attributes of the group name should
be used when ESP processes an Event rather than the ID of
the defining user.
NORACID Indicates that the security attributes of the group name should
no longer be used when ESP processes an Event.
cal1 Indicates the name of the first default calendar, up to eight
alphanumeric characters.
cal2 Indicates the name of the second default calendar, up to eight
51
ALTGROUP Command, Continued
Usage notes To set the second default calendar without affecting the setting of the first calendar,
code an asterisk (*) as the first calendar name. To nullify a calendar, specify
NONE.
Related
information
For information on defining groups, see the ESP Workload Manager Administrators
Guide.
Example 1 The following example alters the second default calendar for a group:
ALTGROUP GROUP1 CALENDAR(* CAL3)
In the above example, GROUP1s secondary calendar is altered to reference CAL3.
The first default calendar is left as is.
Example 2 The following example alters various attributes of a group:
ALTGROUP GROUP27 DEPARTMENT(ACCOUNTS)-
NOUREAD AUTH(NOOPER)
In the above example, GROUP27:
Is assigned to a department called ACCOUNTS
Has its universal read access removed
Has its ability to issue operator commands removed.
52
ALTSIG Command
Overview The ALTSIG command is used to alter the number of generations of a signal.
Authority You can only alter a signal beginning with the prefix of your user ID or a group to
which you have access.
Syntax The syntax of the ALTSIG command is:
ALTSIG signalname GEN(genno)
signalname Indicates a signal name in the format prefix.signalname,
where signalname is 1-16 alphanumeric characters. If the
prefix is not specified, the current group prefix set by the
GROUP command is used.
genno Indicates the number of generations of a signal that are to be
stored.
Related
information
For information on defining and working with signals, see the ESP Workload
Manager Advanced Users Guide.
For information on defining and deleting signals, see the DEFSIG and DELSIG
commands.
Example 1 The following example alters the number of generations of a signal:
ALTSIG CYBER.SIGNAL1 GEN(10)
In the above example, CYBER.SIGNAL1 is altered to store 10 generations.
Example 2 The following example alters the number of generations of a signal:
ALTSIG DAILY_SIGNAL2 GEN(7)
In the above example, DAILY_SIGNAL2 is altered to store 7 generations. If the
current group is PROD, then PROD.DAILY_SIGNAL2 is altered.
53
ALTTJ Command
Overview The ALTTJ command is used to change selected characteristics of a tracked job.
Normally tracked jobs are defined in a Job Tracking Definition Table and this
command is not required.
Authority SCHEDULER or a matching ownership string is required to issue the ALTTJ
command.
Syntax The syntax of the ALTTJ command is:
ALTTJ jobname
{[PREFIX]}
{[OWNER(ownerid)]}
{[TRACK|NOTRACK]}
{[MODEL(modelname)]}
{[INDEX(indexcount)]}
jobname Indicates the job definition or definitions to be altered. The
jobname can contain asterisks or a hyphen, requesting that all
job definitions matching the mask be altered.
PREFIX Indicates that the entry being altered is a jobname prefix entry
rather than an explicit job entry.
Note: This parameter is only applicable if you are not using a
job tracking definition table.
ownerid Indicates an ownership string for the job(s). It consists of up
to eight alphanumeric characters, including asterisks or a
hyphen. This is only valid in non-SAF environments.
TRACK Indicates that you want the job to be tracked.
NOTRACK Indicates that you do not want the job to be tracked.
modelname Indicates the name of the tracking model to be associated with
the job or jobs.
indexcount Indicates the number of ancestors of a job that are to remain
on the job index data set.
Related
information
For information on tracking workload, see the ESP Workload Manager
54
ALTTJ Command, Continued
Example 1 The following example alters the tracking model associated with a group of jobs:
ALTTJ PA- MODEL(PAYROLL)
In the above example, all jobs beginning with PA are associated with a tracking
model called PAYROLL.
Example 2 The following example alters characteristics associated with a specific job:
ALTTJ WEEKLYBK TRACK MODEL(MODEL2)
In the above example, WEEKLYBK should now be tracked and be associated with
a tracking model called MODEL2.
55
ALTUSER Command
Overview The ALTUSER command is used to alter the definition of a user.
Authority SPECIAL or USERDEF authority is required to issue the ALTUSER command.
Note: ALTUSER is applicable only when using ESP Workload Managers internal
security.
Syntax The syntax of the ALTUSER command is:
{ALTUSER|ALTU} userid
[GROUP(USERID)|(groupname)|(PREFIX)]
[PASSWORD(password)]
[EVENTSET(eventdsid)]
[HISTFILE(histfile)]
[DEPARTMENT(deptid)]
[AUTH[(OPER) |(NOOPER)]
[(SPECIAL) |(NOSPECIAL)]
[(ANY) |(NOANY)]
[(SCHED) |(NOSCHED)]
[(USERDEF) |(NOUSERDEF)]
[(GROUPDEF) |(NOGROUPDEF)]
[(CONNECTDEF) |(NOCONNECTDEF)]
[(CALENDARDEF)|(NOCALENDARDEF)]]
[AUTHTAB(tabname)]
[CALENDAR(cal1[,cal2]...)]
userid Indicates the name of the user entry to be modified.
USERID Indicates the user ID is to be used as an Event name prefix.
groupname Indicates the group that is to be used as the Event name
prefix.
PREFIX Requests the current TSO profile data set prefix is used as
the Event name prefix.
password Indicates a password of up to eight characters which is to
be associated with the user ID for accessing the ESP
command through a batch job. This applies only if you are
not using a security product.
eventdsid Indicates the logical identifier of the Event database used
to store Events prefixed with the user ID.
histfile Indicates the history file ID or mask to which the user has
access.
56
ALTUSER Command, Continued
Syntax (continued)
which this user belongs. It may contain asterisks and may
SPECIAL Indicates the user can access the Administrator command
set of ESP.
OPER Indicates Events having the user ID as a prefix can contain
operator commands.
ANY Indicates the user can define and access Events with any
group prefix.
SCHED Allows the user to define P-Nodes, tracking models and
job tracking parameters.
USERDEF Indicates the user can define other users within the same
department, or department sub-group, provided they use
the same Eventset. This user can define other users with
equal or lesser authority than him or herself. The
DEPARTMENT parameter must also be used with this
keyword.
GROUPDEF Indicates the user can define other groups within the same
the same Eventset. This user can define groups with equal
or less authority than his or her own group, but will not be
able to use the RACID option which is only available with
the DEFGROUP command to a user with the SPECIAL
attribute.
CONNECTDEF Indicates the user can connect any user to any group
within the same department, or department sub-group.
CALENDARDEF Indicates the user can define calendars and assign their use
to other users within the same department, or department
sub-group.
NOSPECIAL Removes the SPECIAL attribute.
NOANY Removes the ANY attribute.
NOSCHED Removes the SCHED attribute.
NOUSERDEF Removes the USERDEF attribute.
NOGROUPDEF Removes the GROUPDEF attribute.
NOCONNECTDEF Removes the CONNECTDEF attribute.
tabname Indicates the name of the authorization table assigned to
the user.
cal1 Indicates the name of the first default calendar, up to eight
characters.
cal2 Indicates the name of the second default calendar, up to
eight characters.
57
ALTUSER Command, Continued
Usage notes To set the second default calendar without affecting the setting of the first calendar,
code an asterisk as the first calendar name. To nullify a calendar, specify NONE.
Related
information
For information on defining users, groups, departments, and so on, see the ESP
Workload Manager Administrators Guide.
Example 1 The following ALTUSER command changes a users attributes:
ALTUSER USER1 AUTH(SPECIAL,ANY,OPER)
In the above example, USER1s authority attributes are changed to SPECIAL, ANY
and OPER.
Example 2 The following ALTUSER command changes a users calendar information:
ALTUSER USER2 CALENDAR(* NONE)
In the above example, USER2s second default calendar is removed.
Example 3 The following ALTUSER command allows a user access to history files:
ALTUSER GX991 HISTFILE(HIST-)
In the above example, GX991 is allowed to access any history file beginning with
HIST.
Example 4 The following ALTUSER command changes a users authorization table:
ALTUSER CYTR AUTHTAB(AT0001)
In the above example, an authorization table called AT0001 is assigned to CYTR.
58
APPL Statement
Overview The APPL statement is used to identify the name of an Application, and to indicate
certain processing options for the Application.
Syntax The syntax of the APPL statement is:
APPL applid
[WAIT]
[HOLD]
[POST_WHILE_WAITING|NOPOST_WHILE_WAITING]
[JOB_ANCESTOR_WAIT(LAST|ANY)]
[NOPOST_UNTIL_READY|POST_OLDEST|NOPOST_OLDEST]
[INDEX(nn)]
[SAF_PROF_APPL|SAF_PROF_GROUP]
[OWNER(CENTRAL_MANAGER|manager)]
applid Indicates an Application identifier up to eight
alphanumeric or national characters. The first
character can not be numeric.
WAIT Indicates that concurrent processing of different
generations of an Application is not permitted.
HOLD Indicates that the Application is to be generated on
hold.
POST_WHILE_WAITING Indicates that EXTERNAL and MANUAL jobs
within the Application are posted complete even if
the Application is in:
APPLWAIT
SUBAPPL WAIT
JOB_ANCESTOR_WAIT.
This is the default.
NOPOST_WHILE_WAITING Indicates that EXTERNAL and MANUAL jobs
within the Application are not posted complete if
the Application is in:
APPLWAIT
SUBAPPL WAIT
JOB_ANCESTOR_WAIT.
NOPOST_OLDEST Indicates that EXTERNAL and MANUAL jobs
are posted complete in all active generations of an
Application. This is the default. This overrides
the TRACKOPT setting for this Application.
59
APPL Statement, Continued
Syntax (continued)
POST_OLDEST Indicates that EXTERNAL and MANUAL jobs
are posted complete in the oldest active generation
of an Application. This overrides the TRACKOPT
setting for this Application.
NOPOST_UNTIL_READY Prevent each job in this Application from being
marked complete until the job has been readied.
JOB_ANCESTOR_WAIT(LAST) Prevent each job in this Application from being
submitted until a previous run of the same job has
completed. LAST requires that the job be
complete in the previous generation.
JOB_ANCESTOR_WAIT(ANY) Prevent each job in this Application from being
submitted until a previous run of the same job has
completed. ANY requires that the job be complete
in all previous generations.
INDEX(nn) Indicates the number of generations of the
Application to be retained on the APPLFILE. The
default is 20; the maximum allowed is 99.
SAF_PROF_GROUP Indicates that jobs within the Application are to be
protected by the GROUP.groupname and
GROUPX.groupname resources. This is only
applicable if SAF is used for ESP security. This is
the default.
SAF_PROF_APPL Indicates that jobs within the Application are to be
protected by the APPL.applname.jobname and
APPLX.applname.jobname resources. This is only
applicable if SAF is being used for ESP security.
NOTIFY_SUBAPPL_COMPLETE Indicates that ESP should generate a console
message (i.e. ESP1276) when a subApplication
completes.
OWNER Indicates the name of the owning ESP Manager
for this Application, and for Links and Tasks in
this Application. Specify a valid Manager name as
defined in the AGENTDEF file, up to 16
alphanumeric characters in length, where the first
character must be alpha or a national character. If
you do not specify OWNER,
CENTRAL_MANAGER is the default. The
owning Manager is the only one with authority to
update the status of an Application.
60
Usage notes Use the WAIT parameter to specify that an Application should not begin processing
until the previous generation of the Application is complete. By default, ESP allows
concurrent processing of different generations of the same Application. If you select
the WAIT parameter, you can use other keywords to control posting of jobs.
Use the JOB_ANCESTOR _WAIT keyword when you want to allow concurrent
processing of two generations of an Application but want to ensure that a previous
run of a job (i.e. in the prior, or in all previous generations) has completed prior to
submitting the same job.
The NOPOST_UNTIL_READY option prevents a job from being considered
complete until it is readied (i.e. all dependencies met). This is useful where a job in
an Application requires the completion of a manually submitted predecessor that
runs multiple times.
When an EXTERNAL or MANUAL job completes and multiple generations of the
Application exist, ESP must decide which generation of the Application to post the
job complete in. You can use the POST_OLDEST or NOPOST_OLDEST
keywords to control this, but the recommended method is to use EXTERNAL
SCHEDULED(criteria) on the JOB statement.
Use the INDEX parameter to control the number of generations of the Application to
retain on the APPLFILE. An incomplete Application is not deleted unless the
number of generations exceeds 99; ESP temporarily expands the index when
necessary.
Only one APPL statement is allowed in an ESP Application.
If you are running a distributed Application and you want it to be able to complete
when the mainframe is unavailable, specify a Distributed Manager as the owner.
Related
Statements
For information on manipulating Applications, subApplications, jobs within
Applications or jobs within subApplications, see the APPLJOB or AJ command, or
the CSF.
For information on displaying Applications or subApplications, see the LISTAPPL
OR LAP command.
For information on displaying Application file information, see the LISTAPTF
command.
For information on Applications and subApplications, see the ESP Workload
For information on posting EXTERNAL or MANUAL jobs complete when multiple
generations of an Application exist, see the JOB statement.
Example 1 The following APPL statement identifies a name for an ESP Application:
APPL PAYROLL
In the above example, PAYROLL is used to identify this ESP Application.
61
Example 2 The following WAIT parameter on the APPL statement identifies a certain
processing option for an ESP Application:
APPL PAYROLL WAIT
In the above example, no more than one generation of the PAYROLL Application
can process at the same time.
Example 3 The following INDEX parameter on the APPL statement identifies a certain
processing option for an ESP Application:
APPL PAYROLL INDEX(50)
In the above example, the number of generations of the PAYROLL Application
retained in the ESP Application file is 50.
Example 4 The following WAIT and NOPOST_WHILE_WAITING parameters on the APPL
statement identify certain processing options for an ESP Application:
APPL PAYROLL WAIT NOPOST_WHILE_WAITING
More than one generation of the PAYROLL Application can process at the same
time
External and manual jobs are not marked complete in any generation of the
PAYROLL Application that is waiting for another generation of the same
Application to complete.
Example 5 The following POST_OLDEST parameter on the APPL statement identifies a
certain processing option for an ESP Application:
APPL PAYROLL POST_OLDEST
In the above example, external and manual jobs are marked complete only in the
oldest active generation of the PAYROLL Application.
Example 6 The following example defines the central ESP Manager as the owning Manager of
this Payroll Application Monday to Friday, and the Distributed Manager DMCHI as
the owning ESP Manager on weekends:
IF TODAY(WEEKEND) THEN
APPL PAYROLL OWNER(DMCHI)
ELSE
APPL PAYROLL
ENDDO
JCLLIB
TEMPLIB
62
Example 7 The following INDEX and JOB_ANCESTOR_WAIT(LAST) parameters on the
APPL statement identify certain processing options for an ESP Application:
APPL PAYROLL INDEX(10) JOB_ANCESTOR_WAIT(LAST)
JOB PAYJOB1
10 generations of the PAYROLL Application are retained in the ESP Application
file
More than one generation of the PAYROLL Application can process at the same
time, but each job must wait until its ancestor job (i.e. in previous generation) is
complete.
Other examples Here are more examples using the APPL statement.
Indicates that Application PAYROLL is to be generated on hold:
APPL PAYROLL HOLD
Indicates that external and manual jobs are marked complete even if the Application
is in:
APPLWAIT
SUBAPPL WAIT
JOB_ANCESTOR_WAIT.
APPL PAYROLL POST_WHILE_WAITING
Indicates that jobs within the PAYROLL Application are to be protected by the
APPL.applname.jobname and APPLX.applname.jobname resources, if SAF is being
used for ESP security:
APPL PAYROLL SAF_PROF_APPL
Indicates that ESP should generate a console message when each subApplication
within the PAYROLL Application completes:
APPL PAYROLL NOTIFY_SUBAPPL_COMPLETE
SUBAPPL ACCREC
63
APPLJOB Command - Controlling Jobs and subAppls
Overview The APPLJOB command is used to control jobs, subApplications and Applications.
The short form of this command name is AJ.
For purposes of clarity, the APPLJOB command description is split into two
sections Controlling Jobs and Applications, and Controlling Applications. If you
want to control an Application, see APPLJOB Command - Controlling
Applications.
Type ESP Application command.
64
APPLJOB Command - Controlling Jobs and subAppls, Continued
Syntax The syntax of the APPLJOB command is:
{APPLJOB|AJ} jobname
[ANCESTOR(number)]
[APPLICATION(applspec)]
[OLDEST]
{SETREASON}
[REASON(string)]
{BYPASS|UNBYPASS}
{COMPLETE}
{DROPDEP[(jobname[,jobname]...)]}
{DROPRES}
{HOLD|RELEASE}
{INSERT [PREDECESSORS(name[,name]...)]
[SUCCESSORS(name[,name]...)]
[ATTRIBUTES(type)]
[SUBAPPL(name)]
[TAG(tag)]
[VERIFY|NOVERIFY]
[DATASET(dsname)]
[MEMBER(membername)]}
{READY}
{REQUEST|UNREQUEST}
{RESET [DROPEXEC(time)]
[DELAYSUB(time)|EARLYSUB(time)]
[LATESUBMIT(time)]
[LATESTART(time)]
[LATEEND(time)]
[ABANDONRESOURCETIME(time)]
[ABANDONDEPENDENCYTIME(time)]}
{RESUBMIT [DATASET(dsname)]
[MEMBER(membername)]
[JOBNAME(name)]
[RRJOBID(jobid)]
[USER1(userinfo)]
[USER2(userinfo)]
[USER3(userinfo)]
[USER4(userinfo)]
[ENCPARM1(userinfo)]
[ENCPARMA(userinfo)]
[ENCPARMB(userinfo)]
[ENCPARMC(userinfo)]
[FROMSTEP(stepname)]
[TOSTEP(stepname)]
[VERIFY|NOVERIFY]
[RESTART]}
{UNWAIT}
65
Syntax (continued)
jobname The jobname parameter can take any of the
following forms:
nnnn JES job number
job 1-8 alphanumeric jobname
job.qual 1-8 alphanumeric jobname followed
by 1-8 alphanumeric job qualifier
subapplid 1-8 alphanumeric subApplication
identifier.
ANCESTOR Indicates the number of generations to go back.
Can be specified as + or -; both are treated the
same (e.g. -2 and 2 both mean 2 generations back
from current). The default is 0, i.e. current
generation.
APPLICATION(applspec) Optional. However, it is mandatory when
REQUEST, RESUB or INSERT are specified. If
the job is not yet submitted, the jobname must be
augmented by the Application name. If more
than one generation of the Application is active,
the relative or obsolete generation of the
Application (or the OLDEST keyword) must also
be specified. This is in the form aaa.nnn where
aaa is the Application name and nnn is the
absolute generation number, or aaa.-rrr where
rrr is the relative generation, 0 being the most
recent.
OLDEST Indicates the action is to be performed on the
oldest incomplete generation of the Application.
SETREASON Sets a User Status field to the specified string.
When you specify SETREASON, you must also
specify REASON. SETREASON can be
abbreviated to SET.
REASON(string) Specifies a reason for a particular action to be
performed. It can consist of up to 28 characters
enclosed in single quotes. Use a period(.) to reset
this field. The information in this field is
displayed in the User Status and Status fields of
the Consolidated Status Panel.
BYPASS/UNBYPASS The BYPASS keyword is used to indicate that a
job is no longer required. As soon as the
dependencies are met, the job is bypassed.
Successor jobs are posted as in a normal job
completion. If a job is BYPASSED, it can be
UNBYPASSED at any time up to submission.
66
Syntax (continued)
COMPLETE Simulates normal completion of a job. This immediately
posts successor jobs and EXTERNAL references. It can
be used in a situation where the job failed, but a rerun is
not necessary. The command can also be used prior to a
job beginning execution.
DROPDEP (jobname) If DROPDEP is specified without any parameters, all
predecessor relationships from a job are removed by
marking all the predecessor dependencies as satisfied.
You can also drop individual dependencies by
specifying predecessor jobs.
DROPRES Removes all resource requirements for this job.
HOLD Place a job on manual hold.
RELEASE Release a job from manual hold.
INSERT Indicates that the job specified is to be inserted into the
Application specified by the APPL parameter.
PREDECESSORS(joblist) Indicates predecessor jobs that must complete
successfully prior to the job specified. It can only be
used in conjunction with the INSERT keyword. The
default is none.
joblist specifies job names to be used for an insert
request. A maximum of 50 job names can be specified.
The job names can have a conditional relationship
associated with them as follows:
(jobname(cond),jobname,jobname(cond),...)
Where jobname is the name of a job and cond is a
conditional relationship as follows:
U - insert on unconditional completion
N - insert on normal completion only (default)
A - insert on abnormal completion only.
67
Syntax (continued)
SUCCESSORS(joblist) Indicates successor jobs that must run after the job
specified completes successfully. It can only be used in
conjunction with the INSERT keyword. The default is
none.
joblist specifies job names to be used for an insert request.
A maximum of 50 job names can be specified. The job
names can have a conditional relationship associated with
them as follows:
(jobname(cond),jobname,jobname(cond),...)
Where jobname is the name of a job and cond is a
conditional relationship as follows:
U - insert on unconditional completion
N - insert on normal completion only (default)
A - insert on abnormal completion only.
ATTRIBUTES(type) Specifies the attributes of the job. The following are
valid: JOB, TASK, LINK, CONDITIONAL, HOLD,
REQUEST, MANUAL and EXTERNAL. The default is
JOB. It can only be used in conjunction with the INSERT
keyword.
SUBAPPL(subappl) Inserts the job as a member of the specified
subApplication.
TAG(tag) Associate this tag with the inserted job.
VERIFY/
NOVERIFY
Verify or do not verify that a data set and member exist by
opening and closing. This can be used with the INSERT
and RESUB actions.
DATASET(dsname) Indicates an explicit JCL library name (may include
member name).
MEMBER
(membername)
Indicates an explicit overriding JCL member name.
READY Remove all job dependencies (except resources) from a
job (including time, predecessors, manual hold).
REQUEST/
UNREQUEST
Indicate whether an on-request job is required. The job
must be identified as an on-request job by use of the
REQUEST keyword on the JOB statement in ESPPROC.
A job can be requested or unrequested up to the time of
submission. If it is not requested at the time of
submission, the job is bypassed. Normal end is signaled to
successor jobs.
68
Syntax (continued)
RESET Reset a time associated with a job. The
times that can be reset are:
DROPEXEC
DELAYSUB/EARLYSUB
LATESUBMIT
LATESTART
LATEEND
ABANDONRESOUCETIME
ABANDONDEPENDENCYTIME.
DROPEXEC(time) Indicates a time after which a job is not to
be submitted. This corresponds to the
ABANDON SUBMISSION time.
DELAYSUB | EARLYSUB(time) Indicates a time before which a job is not
to be submitted. This corresponds to the
DELAYSUB or EARLYSUB time.
LATESUBMIT(time) Indicates a time at which, if a job has not
been submitted, it is to be considered
overdue. This corresponds to the
LATESUB time.
LATESTART(time) Indicates a time at which, if a job has not
started executing, it is to be considered
DUEOUT INPUT time.
LATEEND(time) Indicates a time at which, if a job has not
ended execution, it is to be considered
DUEOUT EXEC time.
ABANDONRESOURCETIME(time) Indicates a time at which any resources for
which a job is waiting are to be ignored,
and the job is dropped from the Resource
Managers control and readied. This
corresponds to the ABANDON
RESOURCES time.
ABANDONDEPENDENCYTIME(time) Indicates a time at which any predecessors
for which a job is waiting, are ignored,
and the job is readied for submission. This
corresponds to the ABANDON
DEPENDENCIES time.
RESUBMIT Identifies the job is to be resubmitted.
The last data set from which the job was
submitted is used, unless you use the
DATASET keyword to specify an
alternate data set.
69
Syntax (continued)
DATASET(dsname) Indicates an explicit JCL library name form which a
job is to be resubmitted (may include member name).
MEMBER(membername) Indicates an explicit JCL library member for
resubmission of the job.
JOBNAME(name) Indicates the job name for rerun, if different from the
original job name.
RRJOBID(jobid) Specifies the JES job number of the job being rerun.
It can only be used for jobs being restarted using ESP
Encore. By default, this corresponds to the previous
run of the job.
USER1-USER4 Indicates user parameters for resubmitted jobs. These
are passed to the USER1-USER4 ESP symbolic
variables. Initially these variables are set to a null
string ().
Up to 80 characters of information can be specified
for each parameter.
ENCPARM1-ENCPARM9
and
ENCPARMA-ENCPARMC
Indicates parameters of data for resubmitting a job
using ESP Encore. Up to 60 characters of
information can be specified for each parameter.
FROMSTEP(stepname) Specifies the first step of the job to be rerun. Use
(stepname.procstepname) for steps within a
Procedure. The default is the first step. Can only be
used with ESP Encore.
TOSTEP(stepname) Specifies the last step of the job to be rerun. Use
(stepname.procstepname) for steps within a
Procedure. The default is the last step. Can only be
used with ESP Encore.
RESTART Indicates the job is to be restarted using ESP Encore.
It can only be used in conjunction with the RESUB
function.
UNWAIT Removes a job, or subApplication, from wait status
when it is waiting on a previous generation of the
same job (i.e. job ancestor wait), or subApplication
(i.e. sub-appl wait).
70
Usage notes If an EXTERNAL job is marked complete in the home Application, ESP marks that
job complete in all other active Applications to which the job belongs.
The APPLJOB command can be issued from a system console to complete an entire
Application, or a job within an Application. This functionality requires USERMOD
35.
The APPLJOB command can be used to manipulate jobs and subApplications. The
keywords which can be used with subApplications are:
BYPASS and UNBYPASS
REQUEST and UNREQUEST
HOLD and RELEASE
COMPLETE
READY
UNWAIT.
Related
information
For information on manipulating entire Applications, see the APPLJOB Command -
Manipulate Applications.
Example 1 The following AJ command requests a job:
AJ PAYJOB1 REQUEST APPL(PAYROLL.0)
In the above example, PAYJOB1 is requested.
Example 2 The following AJ command resubmits a job from a different library:
AJ PAYJOB2 RESUB APPL(PAYROLL.0) DATASET(CYBER.COPY.JCL)
In the above example, PAYJOB2 is resubmitted from CYBER.COPY.JCL.
Example 3 The following AJ command holds a job by jobname:
AJ PAYJOB3 HOLD APPL(PAYROLL.0)
In the above example, PAYJOB3 is held.
Example 4 The following AJ command marks a job complete by job number:
AJ 154 COMPLETE APPL(PAYROLL.0)
In the above example, job number 154 is marked complete.
71
Example 5 The following AJ command inserts a job into an Application:
AJ PAYJOB4 INSERT APPL(PAYROLL.293) PREDECESSORS(PAYJOB3) -
SUCCESSORS(PAYJOB5)
In the above example, PAYJOB4 is inserted into generation 293 of the PAYROLL
Application. It runs after PAYJOB3 completes successfully, but before PAYJOB5.
Example 6 The following AJ command inserts a task into an Application:
AJ REPORT.BALANCE INSERT APPL(PAYROLL) PREDECESSORS(PAYJOB6) -
ATTRIBUTES(TASK)
In the above example, a task called REPORT.BALANCE is inserted into the current
generation of the PAYROLL Application. It runs after PAYJOB6 completes
successfully.
Example 7 The following AJ command requests a subApplication:
AJ REQJOBS REQUEST APPL(PAYROLL.0)
In the above example, a subApplication called REQJOBS is requested. Each
REQUEST job in this subApplication is requested. This eliminates the need to
request each job individually.
Example 8 The following AJ command bypasses a subApplication:
AJ PAYJOBS BYPASS APPL(PAYROLL.0)
In the above example, a subApplication called PAYJOBS is bypassed. This
indicates that all remaining jobs in this subApplication are no longer required.
Example 9 The following AJ command resets a jobs delayed submission time:
AJ PAYJOB7 RESET DELAYSUB(9PM) APPL(PAYROLL.0)
In the above example, PAYJOB7s delayed submission time is reset to 9 pm.
Example 10 The following AJ command holds a job with a reason:
AJ PAYJOB8 HOLD REASON(WAITING FOR TAPE 09999)
APPL(PAYROLL.0)
The following AJ command releases a job and resets the reason field to null:
AJ PAYJOB8 RELEASE REASON(.) APPL(PAYROLL.0)
72
Example 11 The following AJ command inserts a job on hold:
AJ PAYJOB9 INSERT ATTRIBUTES(HOLD) APPL(PAYROLL.0)
In the above example, PAYJOB9 is inserted on hold into the current generation of
the PAYROLL Application.
Example 12 The following AJ command resubmits a job using original JCL library. The
character string ,RESTART=STEP20 is passed to the JCL as the USER1 variable.
AJ PAYJOB10 RESUB USER1(,RESTART=STEP20) APPL(CYBER1)
The following is a sample jobcard and the corresponding jobcard used for
resubmission:
PAYJOB10 JOB...MSGCLASS=X%USER1
resolves to:
PAYJOB10 JOB...MSGCLASS=X,RESTART=STEP20
Example 13 PAYJOB11 is resubmitted using the USER2 symbolic variable. It is used to pass a
run type parameter to a restart program. For the first run of the job, the run type
parameter is P; on the resubmit of the job, the run type parameter is R.
In JCL:
//STEP1 EXEC UCC11RMS,RUNTYPE=%USER2
In ESP Procedure or Symbol Library:
IF USER2= THEN USER2=P
On Resubmit:
AJ PAYJOB11 RESUB USER2(R) APPL(PAYROLL)
Example 14 The following AJ command inserts a job with two predecessors into an Application:
AJ PAYJOB12 INSERT PREDECESSORS(PAYJOB10,PAYJOB11)
APPL(PAYROLL.0)
In the above example, PAYJOB12 is inserted into the current generation of the
PAYROLL Application. It runs after PAYJOB10 and PAYJOB11 complete
successfully.
Example 15 The following AJ command inserts a job into an Application with one predecessor:
AJ PAYJOB13 INSERT APPL(PAYROLL.0) PREDECESSORS(PAYJOB11(U))
In the above example, PAYJOB13 is inserted into the current generation of the
PAYROLL Application. It runs after PAYJOB11 completes, whether or not it is
successful.
73
Example 16 The following AJ command inserts a link into an Application:
AJ LINKIT INSERT APPL(PAYROLL.0) PREDECESSOR(PAYJOB14) -
SUCCESSOR(PAYJOB15) ATTRIBUTE(LINK)
In the above example, a link called LINKIT is inserted into the current generation of
the PAYROLL Application. It runs after PAYJOB14 completes successfully, but
before PAYJOB15.
Example 17 The following AJ command is issued from a system console to complete a job:
F ESPM,AJ PAYJOB16 COMPLETE APPL(PAYROLL.0)
In the above example, PAYJOB16 is completed.
Example 18 The following AJ command set the User Status Field:
AJ PAYJOB17 SETREASON REASON(WAITING FOR TAPE)
APPL(PAYROLL.0)
In the above example, the User Status Field for PAYJOB17 indicates that the job is
waiting for a tape.
Example 19 The following AJ command resubmits a job:
AJ PAYJOB18 RESUB RESTART APPL(PAYROLL.0)
In the above example, PAYJOB18 is resubmitted and ESP Encore is used.
Example 20 The following series of AJ commands insert a job with a time dependency:
AJ PAYJOB19 INSERT ATTRIBUTE(HOLD) APPL(PAYROLL.0)
AJ PAYJOB19 RESET DELAYSUB(9PM) APPL(PAYROLL.0)
AJ PAYJOB19 RELEASE APPL(PAYROLL.0)
In the above example, PAYJOB19 is inserted on hold into the current generation of
the PAYROLL Application. PAYJOB19s submission time is set to 9 pm and then
released from hold.
74
APPLJOB Command - Controlling Applications
Overview The APPLJOB command is used to control jobs, subApplications and Applications.
The short form of this command name is AJ.
For purposes of clarity, the APPLJOB command description is split into two
sections Controlling Jobs and Applications, and Controlling Applications. If you
want to control jobs or subApplications, see APPLJOB Command - Controlling
Jobs and subAppls.
Type ESP Application command.
Syntax The syntax of the APPLJOB
{APPLJOB|AJ} ALL APPL(applspec) [COMPLETE]
[HOLD]
[RELEASE]
[UNWAIT]
[OLDEST]
applspec Indicates the Application name. If more than one generation
of the Application is active, the relative or absolute
generation of the Application (or the OLDEST keyword)
must also be specified. This is in the form aaa.nnn where
aaa is the Application name and nnn is the absolute
generation number, or aaa.-rrr where rrr is the relative
generation, 0 being the most recent.
COMPLETE Completes an Application.
HOLD Holds an Application. This stops submission of jobs in the
Application and places the Application in APPLHOLD
status.
RELEASE Releases an Application, i.e. remove from APPLHOLD
status.
UNWAIT Removes an Application from APPLWAIT status.
OLDEST Indicates the action is performed on the oldest active
generation of the Application.
Usage notes When you complete an Application, the next generation of the Application can
process.
Related
information
For information on manipulating jobs belonging to Applications, see the APPLJOB
Command - Manipulate Application Jobs.
75
APPLJOB Command - Controlling Applications, Continued
Example 1 Marking the current generation of an Application complete:
AJ ALL APPL(PAYROLL.0) COMPLETE
In the above example, the current generation of the PAYROLL Application is
completed.
Example 2 Marking the -1 generation of an Application complete:
AJ ALL APPL(PAYROLL.-1) COMPLETE
In the above example, the -1 generation of the PAYROLL Application is completed.
Example 3 The following AJ command is issued from a system console to complete an
Application:
F ESP,AJ ALL COMPLETE APPL(PAYROLL.0)
In the above example, the current generation of the PAYROLL Application is
completed.
Example 4 The following AJ command removes an Application from APPLWAIT status:
AJ ALL UNWAIT APPL(PAYROLL.293)
In the above example, the generation 293 of the PAYROLL Application is removed
from APPLWAIT status.
Example 5 The following AJ command releases an Application:
AJ ALL RELEASE APPL(PAYROLL.0)
In the above example, the current generation of PAYROLL is released. This
removes it from APPLHOLD status.
76
BACKOUT
Overview Use the BACKOUT command if you experience serious difficulties that require you
to revert to a previous release of ESP.
Authority OPER authority is required to issue the BACKOUT command.
Syntax The syntax of the BACKOUT command is:
BACKOUT {V510}
{V451}
{V442}
{V441}
{V440}
Usage notes The BACKOUT command converts any Events in initiator classes other than 0 to
class 0 so they can be used with previous releases of ESP.
When you issue the BACKOUT command, you see a message indicating backout is
beginning. When completed, a message is written to the audit log identifying the
number of TDRs moved to Event initiator class 0.
For more information on Event initiator classes, see the ESP Workload Manager
Installation Guide.
Example To back out the current release, and bring up release 4.5.1 of ESP:
BACKOUT V451
77
BKUPEVS Command
Overview The BKUPEVS command is used to initiate the immediate backup of an Event data
set.
Authority OPER authority is required to issue the BKUPEVS command.
Syntax The syntax of the BKUPEVS command is:
BKUPEVS eventdsid
eventdsid Indicates the identifier of the Event data set using up to eight
characters.
Usage notes The BKUPEVS command schedules an immediate backup of an Event data set. The
data set is backed up to a non-VSAM data set whose name must be defined by the
BKUPDSNAME parameter on an EVENTSET command or Initialization Parameter.
Related
information
For information on defining or altering an Event Data set, see the EVENTSET
parameter in the ESP Workload Manager Installation Guide.
Example The following BKUPEVS command initiates an Event Data set backup:
BKUPEVS EVENT1
In the above example, EVENT1 is immediately backed up.
78
BKUPHIST Command
Overview The BKUPHIST command is used to initiate the immediate backup of a history data
set.
Authority OPER authority is required to issue the BKUPHIST command.
Syntax The syntax of the BKUPHIST command is:
BKUPHIST histfid
histfid Indicates the identifier of the history recording database using
up eight characters.
Usage notes The BKUPHIST command schedules an immediate backup of a history file
(HISTFILE). The data set is backed up to a non-VSAM data set whose name must
be defined by the BKUPDSNAME parameter on a HISTFILE command or
Initialization Parameter.
Related
information
For information on defining or altering a History data set, see the HISTFILE
parameter in the ESP Workload Manager Installation Guide.
Example 1 The following BKUPHIST command initiates an History data set backup:
BKUPHIST HIST1
In the above example, HIST1 is backed up immediately.
79
BKUPINDX Command
Overview The BKUPINDX command is used to initiate the immediate backup of the Index
data set, set the backup schedule, or display the next scheduled backup time.
Authority OPER authority is required to issue the BKUPINDX command.
Syntax The syntax of the BKUPINDX command is:
BKUPINDX [?|schedule]
? Requests the time of the next scheduled backup be displayed.
schedule Indicates the regular backup schedule.
Usage notes The BKUPINDX command sets the time schedule for the regular Index data set
backup. The backup is made to the data set specified on the INDEX Initialization
Parameter identified by the BACKUPDATSET parameter. If a schedule time is
omitted, an immediate backup takes place.
The BKUPINDX command has to be issued only once because the schedule is
checkpointed. It can be reissued at any time if schedule changes are needed.
Information is lost on cold start of ESP.
Related
information
For information on Index file structure and recovery, see the ESP Workload
Manager Diagnostics and Recovery Guide.
For information on defining the Index data set, see the ESP Workload Manager
Installation Guide.
Example 1 The following BKUPINDX command initiates an Index data set backup:
BKUPINDX
In the above example, the Index data set is immediately backed up.
80
BKUPINDX Command, Continued
Example 2 The following BKUPINDX command displays the scheduled backup time:
BKUPINDX ?
In the above example, the next scheduled backup time of the Index data set is
displayed.
Example 3 The following BKUPINDX command schedules an Index data set backup:
BKUPINDX DAILY AT 6AM
In the above example, the Index data set is scheduled for backup at 6am every day.
81
BKUPJNDX Command
Overview The BKUPJNDX command is used to initiate the immediate backup of the job index
database, set the backup schedule, or display the time of the next scheduled backup
time.
Authority OPER authority is required to issue the BKUPJNDX command.
Syntax The syntax of the BKUPJNDX command is:
BKUPJNDX [?|schedule]
? Requests that the time of the next scheduled backup be
displayed.
schedule Indicates the regular backup schedule.
Usage notes The BKUPJNDX command sets the time schedule for the Job Index data set backup.
The backup is made to the data set identified by the BACKUPDATASET parameter
on the JOBINDEX Initialization Parameter. If a schedule time is omitted, an
immediate backup will take place.
The BKUPJNDX command has to be issued only once because the schedule is
checkpointed. It can be reissued at any time if schedule changes are needed.
BKUPJNDX commands can be stored in ESPs cold start Initialization Parameters.
Related
information
For information on defining the Job Index data set, see the ESP Workload Manager
Installation Guide.
Example 1 The following BKUPJNDX command initiates a Job Index data set backup:
BKUPJNDX
In the above example, the Job Index data set is backed up immediately.
82
BKUPJNDX Command, Continued
Example 2 The following BKUPJNDX command displays the scheduled backup time:
BKUPJNDX ?
In the above example, the next scheduled backup time of the Job Index data set is
displayed.
Example 3 The following BKUPJNDX command schedules a Job Index data set backup:
BKUPJNDX DAILY AT 6AM
In the above example, the Job Index data set is scheduled for backup at 6 am every
day.
83
BKUPUDEF Command
Overview The BKUPUDEF command is used to initiate the immediate backup of the User
Definition data set or set a backup schedule.
Authority OPER authority is required to issue the BKUPUDEF command
Syntax The syntax of the BKUPUDEF command is:
BKUPUDEF [schedule]
? Requests that the time of the next scheduled backup be
displayed.
schedule Indicates the regular backup schedule
Usage notes The BKUPUDEF command sets the time schedule for the regular User Definition
data set backup. The backup is made to the data set identified by the
BACKUPDATSET parameter on the USERDEF Initialization Parameter. If a
schedule time is omitted, an immediate backup takes place.
The BKUPUDEF command has to be issued only once because the schedule is
checkpointed. It can be reissued at any time if schedule changes are needed. If the
system is down when a backup is to take place, the backup commences as soon as
ESP is restarted.
BKUPUDEF commands can be stored in ESPs cold start Initialization Parameters.
Example 1 The following BKUPUDEF command initiates a User Definition data set backup:
BKUPUDEF
In the above example, the User Definition data set is backed up immediately.
84
BKUPUDEF Command, Continued
Example 2 The following BKUPUDEF command displays the scheduled backup time:
BKUPUDEF ?
In the above example, the next scheduled backup time of the User Definition data set
is displayed.
Example 3 The following BKUPDEF command schedules a User Definition data set backup:
BKUPUDEF DAILY AT 6AM
In the above example, the User Definition data set is scheduled for backup at 6 am
every day.
85
BREAK Command
Overview The BREAK command is used to request section breaks at specified parts of a
history report to produce blank lines, a new page or subtotals. A break makes the
history report easier to read and analyze.
Type Reporting command.
Syntax The syntax of the BREAK command is:
BREAK field
length
[SPACE n]
[EJECT]
[SUBTOTAL]
field Indicates the name of a field where you want the break to
occur. This field must have been specified in a previous
DISPLAY section.
length Indicates the number of characters of the display field to be
checked. When a mismatch occurs within this number of
characters, a break occurs.
SPACE n Indicates n blank lines are to be printed when a section break
occurs.
EJECT Requests a new page be forced when a break occurs.
SUBTOTAL Requests a subtotal be printed.
Usage notes Use the BREAK subcommand to define at which points in the report you want to:
Force a new page
Print any number of blank lines
Produce a subtotal.
You can specify several break elements in a break section.
ESP subtotals only meaningful fields such as CPUTIME and DEXCP, but not
JOBNO.
Related
information
For information on history reporting, see the ESP Workload Manager Users Guide.
86
BREAK Command, Continued
Example 1 The following BREAK command is used to produce a subtotal, start a new page and
print a blank line:
REPORT
FROM 8AM YESTERDAY
CRITERIA APPLSYS EQ PAYROLL
DISPLAY JOBNAME JOBNO ACCOUNT CPUTIME
SORT ACCOUNT JOBNAME
BREAK ACCOUNT 3 EJECT SUBTOTAL
BREAK JOBNAME 2 SPACE 1
ENDR
When the first three characters of the account name change, a subtotal is printed
and a new page started
When the first two characters of the jobname change, one blank line is left.
87
CALENDAR Command
Overview The CALENDAR command is used to indicate one or two calendars to be used for
processing, in addition to the SYSTEM calendar. It is normally used as an Event
definition command.
Syntax The syntax of the CALENDAR command is:
CALENDAR calendar1[,calendar2]
calendar1 Indicates the name of a calendar. Cal1 is searched first for
any special day, period and holiday definitions.
calendar2 Indicates the name of a calendar. Cal2 is searched second for
any special day, period and holiday definitions.
Usage notes You can use the CALENDAR command to specify up to two additional calendars
for an Event, so that you can schedule Events and jobs in terms that might be unique
to your calendar.
If you do not specify a calendar, ESP uses the calendar(s) assigned by default to the
group or user that owns the Event.
ESP merges holiday definitions in all calendars associated with an Event. When
special days or periods use the same name in different calendars, ESP uses the first
definition it finds. ESP searches in this order:
1. The first calendar you define for the Event, or first default calendar.
2. The second calendar you define for the Event, or second default calendar.
3. The SYSTEM calendar.
You can also use the CALENDAR command in a batch job and in Page mode to
specify a calendar. You can specify one calendar only.
Related
information
For information on setting special calendars, see the ESP Workload Manager Users
Guide.
For information on using calendars and using calendar terms, see the ESP Workload
For information on defining and deleting calendars, see the DEFCAL and DELCAL
commands.
88
CALENDAR Command, Continued
Example 1 The following CALENDAR command requests that a calendar be used for an Event:
EVENT ID(CYBER.FISCAL_JOBS)
CALENDAR FISCAL
SCHEDULE FIRST DAY OF FISCAL_MONTH
INVOKE CYBER.PROCLIB.CNTL(FISCJOBS)
ENDDEF
In the above example, CYBER.FISCAL_JOBS looks at the FISCAL calendar first to
determine what FISCAL_MONTH means, so ESP knows when to schedule the
Event. If ESP does not find FISCAL_MONTH on the FISCAL calendar, ESP then
looks at the SYSTEM calendar to see if FISCAL_MONTH is defined there.
Note: If FISCAL_MONTH is not defined on either calendar, you receive Event
definition errors, i.e. ESP does not permit you to save an Event that contains invalid
schedule criteria.
Example 2 The following CALENDAR command indicates the name of a calendar to be
searched for holidays:
CALENDAR FISCAL
LISTHOL -
In the above example, the FISCAL calendar and the SYSTEM calendar are searched
for holidays.
89
CCCHK Statement
Overview The CCCHK facility is designed to detect errors in condition codes. It offers the
capability to immediately stop a failing job, without running any subsequent steps
regardless of the COND parameters.
Unless either the FAIL or STOP condition is seen on a matching CCCHK statement,
ESP Workload Manager will not interrupt the flow of the job.
Syntax The syntax of the CCCHK statement is:
CCCHK [JOB(jobmask)]
[STEP(stepname)]
[PROC(procstep]
[PROGRAM(progname)]
[RC(num)|RC(num1:num2)|RC(Sccc)|RC(Unnnn)]
[OK|FAIL]
[CONTINUE|STOP]
JOB(jobmask) Indicates a string that matches a job name. It may
contain the wildcard characters - and * which stand
for any string and any character respectively. This
parameter is optional. If this parameter is missing, this
statement matches with any jobname.
STEP(stepname) Indicates a step within the job. It refers to the label field
on the EXEC statement in the users JCL. This
parameter is optional. If this parameter is missing, then
this statement matches with any stepname.
PROC(procstep) Indicates a particular step within a catalogued or
instream procedure. Specifically, it refers to the label on
the EXEC statement inside a cataloged procedure or an
instream procedure. (It does not refer to the name of the
procedure.) This statement must be used in conjunction
with the STEP parameter.
PROGRAM(progname) Indicates the name of the program being executed by the
step, as found in the PGM parameter on the EXEC
statement of the job. This parameter is optional.
RC(num) Indicates a condition code of num, where num is an
integer between 0 and 4095 inclusive. This value
represents a condition code, not a user abend code. The
RC parameter is required, either in this format or one of
the formats that follow.
RC(num1:num2) Indicates a condition code between num1 and num2
inclusive. The value of num2 must not be smaller than
num1. These values represent condition codes only, not
user abend codes.
90
CCCHK Statement, Continued
Syntax (continued)
RC(Sccc) Indicates a system abend code, such as S0C1 or SB37.
The ccc must be three hexadecimal digits.
RC(Unnnn) Indicates a user abend code, such as U0001 or
U0462. The nnnn must be exactly four decimal digits,
and cannot exceed 4095.
OK Indicates that the job has not failed. OK is the default.
FAIL Indicates that the job should be considered failed. When
the job has failed, it may or may not continue, depending
upon the value of CONTINUE/STOP.
CONTINUE Indicates that the job should continue processing with
the next step, whether or not the job was deemed to have
failed. This is the default.
STOP Indicates that the job should be stopped immediately.
No other steps should be executed. Only one of
CONTINUE or STOP may be specified.
CCCHK and
CCFAIL
ESP can control condition code checking of jobs using either the CCCHK or
CCFAIL statement. CCCHK was developed to replace CCFAIL and is not intended
for use in combination with CCFAIL. If the two statements are used together, both
sets of checks are performed, and if either one indicates a failure, then the job will
be considered a failure for reason CCFAIL. CCFAIL step (named ESPCCFCK) will
not be inserted into any job which uses CCCHK.
CCCHK
statements
There is a limit of 281 CCCHK statements from all sources for a single job.
Usage notes If a step abends, and a matching CCCHK statement specifies CONTINUE, the job
proceeds as usual. That is, the subsequent steps are given an opportunity to execute,
but they are bypassed as usual unless their COND parameter specifies EVEN or
ONLY. However when STOP is specified on the CCCHK statement the job is
flushed immediately, and not even the COND=EVEN or COND=ONLY steps
execute.
Several CCCHK statements may be active for a single job, allowing for an
accumulation of effect that is not achievable with CCFAIL. For example, one
CCCHK statement might indicate a particular action, and other statements might
indicate some exceptional cases.
91
Usage notes
continued
CCCHK statements may be associated with specific stepnames or specific programs.
For example, a CCCHK statement can indicate an action to be taken only when
IEBGENER abends a certain way.
The CCCHK statement may appear in the ESP Initialization Parameters and in an
ESP Procedure. Within an ESP Procedure, they may appear within or outside the
scope of a job.
When a job is executing, all pertinent CCCHK statements are searched sequentially
whenever any jobstep ends. The statements that are pertinent to a job include those
in the ESP Initialization Parameters, those in the ESP Procedure outside of the scope
of a job, and those that are within the scope of a job being executed. The statements
are searched in the following order:
1. Those in an ESP Procedure within the scope of a job
2. Those in an ESP Procedure but not within the scope of a job
3. Those in ESP Workload Manager Initialization Parameters.
At the end of each step, these CCCHK statements are searched until a statement is
found that matches the JOB, STEP, PROGRAM, and RC parameters of the step that
just ended. Searching then stops and the first matching CCCHK statement is used to
determine the disposition of the job.
If FAIL was specified on the first matching CCCHK statement, then the job is
considered failed.
If OK was specified for a particular step, then the job is not considered failed, unless
the matching CCCHK statement from another step indicates FAIL.
Note: If the matching CCCHK statement from any step indicates FAIL, the job is
considered failed.
If CONTINUE was specified on the first matching CCCHK statement, the job
proceeds with the next step. That step may be bypassed if it contains certain COND
parameters on its EXEC statement.
If STOP was specified, the job stops immediately, with no other steps being
executed.
Related
Statements
For information on using ESP to insert trailer steps into JCL to check condition
codes, see the ESP Workload Manager Advanced Users Guide.
92
Statement
usage
The CCCHK statement can be used for all jobs within an Application or specific
jobs within an Application.
Example 1 The following globally placed CCCHK statement indicates how ESP should handle
jobs when completion codes are matched:
APPL PAYROLL
CCCHK RC(1:4095) FAIL
JOB PAYJOB1
In the above example, any job in the PAYROLL Application is considered to have
failed if any step within any job produces a condition code greater than 0.
Example 2 The following local and global CCCHK statements indicate how ESP should handle
APPL PAYROLL
CCCHK RC(1:4095) FAIL STOP
JOB PAYJOB2
CCCHK RC(8) OK CONTINUE
failed and stops processing immediately if a condition code of greater than 0 is
produced. A condition code of 8 for PAYJOB2 is considered to be acceptable and
processing continues for PAYJOB2.
APPL PAYROLL
JOB PAYJOB3
CCCHK PROGRAM(IEBGENER) RC(12) OK CONTINUE
produced. A condition code of 12 produced by program IEBGENER for job
PAYJOB3 is acceptable, the job is not flagged as failed, and processing continues
for this job.
93
APPL PAYROLL
JOB PAYJOB4
CCCHK STEP(STEP001) RC(SB37) FAIL STOP
JOB PAYJOB5
CCCHK STEP(STEP001) PROC(STEP020) RC(1:12) OK CONTINUE
CCCHK STEP(STEP004) RC(8) FAIL STOP
produced.
If step STEP01 receives a system B37 abend for job PAYJOB4 the job is flagged as
failed and processing stops immediately. Note that any subsequent step with
COND=EVEN or COND=ONLY is not executed.
A condition code between 1 and 12 for job PAYJOB5 produced by step STEP01
procstep STEP020 is acceptable and the job is not flagged as failed. But if step
STEP04 produces a condition code of 8, then PAYJOB5 should be flagged as failed
and processing stops immediately.
Ignore an
abend
CCCHK does provide the ability to ignore an abend. With the new capability, a
history will be maintained by CCCHK of each job step which had a completion code
(not a condition code), and whether or not there was a matching CCCHK statement
with OK. At the end of the job, if there are no other failure conditions of any kind,
and each and every completion code, system or user, was marked OK, and none of
them were of the CANCEL type (system completion code in the form X22), then the
application manager will be signalled to treat the job as successful. Successors will
then be released.
This processing is only done at the end of the job, and has no effect on the normal
handling by MVS and JES of a job which had a step abend. Monitors at the job step
level will see an abend, just as they always have. COND parameters of EVEN and/or
ONLY will be required to cause steps after the abended step to be executed.
Displays of the job by LJ, LTJ, or LAP will still show the abend, as will history
reporting. Alert processing will consider the job a success, not a failure.
94
CCFAIL Statement
Overview The CCFAIL statement is used to identify which condition codes should cause ESP
to consider a job as failed and prevent successor jobs from being submitted. The
CCFAIL statement can be used for all jobs within an Application or for specific jobs
within an Application.
Syntax The syntax of the CCFAIL statement is:
CCFAIL (stepname,operator,value)
stepname Indicates a stepname. You must use the exact job or PROC
stepname. For procs, use stepname.procstepname. An asterisk (*)
represents any step.
stepname indicates the name of a step within the job. It refers to
the label field on the EXEC statement in the JCL.
procstepname indicates a particular step within a catalogued or
instream procedure. Specifically, it refers to the label on the
EXEC statement inside a cataloged procedure or an instream
procedure. This parameter is optional. If this parameter is
missing, this statement matches with any procstepname.
operator Specify valid comparison operators as follows:
>= or GE
<= or LE
> or GT
< or LT
= or EQ
= or NE
value Specifies the value of the condition code for which you want to
check.
Usage notes You can use the CCFAIL statement as a global option for all jobs in an Application
or within the scope of a job statement for an individual job. A job specific CCFAIL
statement overrides the global CCFAIL statement.
Multiple condition codes can be specified by separating each (stepname, operator
and value) with a blank. If the specified condition codes are met, the job is flagged
and a message is sent to the operators console and to the user ID listed in the JES
NOTIFY parameter, after the job has completed. ESP treats the job as an
unsuccessful completion, and holds dependent jobs.
95
CCFAIL Statement, Continued
Usage notes
continued
When ESP submits a job, it adds a trailer step to the job that executes only if the
condition codes specified for failure are not met. Otherwise, the trailer step does not
execute and the job fails with a JOB FAILED JCL ERROR condition. Steps after
a bad condition code execute unless you have COND parameters in the JCL to
bypass them.
Note: The CCFAIL statement is limited by what you can do with the COND
parameter in JCL.
Related
Statements
For information on checking condition codes, see the CCCHK statement.
Note: ESP can control condition code checking of jobs by using either the CCFAIL
or CCCHK statement. CCCHK was developed to replace CCFAIL and is not
intended for use in combination with CCFAIL. If the two statements are used
together, both sets of checks are performed, and if either one indicates a failure, then
the job will be considered a failure for reason CCFAIL. CCFAIL step (named
ESPCCFCK) will not be inserted into any job which uses CCCHK.
For information on using ESP to insert trailer steps into JCL to check condition
codes, see the ESP Workload Manager Advanced Users Guide.
Example 1 The following globally placed CCFAIL statement identifies when ESP should
consider a job as failed:
APPL PAYROLL
CCFAIL (*,GT,4)
JOB PAYJOB1
failed if any step within any job produces a condition code greater than 4.
Example 2 The following locally placed CCFAIL statement identifies when ESP should
consider a job as failed:
APPL PAYROLL
JOB PAYJOB1
CCFAIL (STEP004,GT,8)
In the above example, PAYJOB1 is considered to have failed if STEP004 produces a
condition code greater than 8.
96
CCFAIL Statement, Continued
Example 3 The following locally placed CCFAIL statement identifies conditions when ESP
should consider a job to have failed:
APPL PAYROLL
JOB PAYJOB3
CCFAIL (STEPJ.STEPP,GT,0)
In the above example, PAYJOB3 is considered to have failed if procstep STEPP
within job step STEPJ produces a condition code greater than 0.
Example 4 The following local and globally placed CCFAIL statements identify when ESP
should consider a job as failed:
APPL PAYROLL
CCFAIL (*,GT,8)
JOB PAYJOB4
CCFAIL (STEP002,GT,4)
In the above example, any job in the PAYROLL Application except PAYJOB4 is
considered to have failed if any step produces a condition code greater than 8.
PAYJOB4 is considered to have failed if STEP002 produces a condition code
greater than 4.
Note: Any condition code for the other steps in PAYJOB4 is accepted as good,
because a job-specific CCFAIL statement overrides a globally-placed CCFAIL
statement.
Example 5 The following local and globally placed CCFAIL statements identify conditions
when ESP should consider a job as failed:
APPL PAYROLL
CCFAIL (*,GT,8)
JOB PAYJOB5
CCFAIL (STEP001,GT,8) (STEP002,GT,4) (STEP003,GT,8)
In the above example, any job in the PAYROLL Application except PAYJOB5 is
considered to have failed if any step produces a condition code greater than 8.
PAYJOB5 is considered failed if any of the following occur:
STEP001 produces a condition code greater than 8
STEP002 produces a condition code greater than 4
STEP003 produces a condition code greater than 8.
Note: If you dont want the locally placed CCFAIL statement to override the
globally placed CCFAIL statement, specify each step and the appropriate CCFAIL
statement for that step, as coded above.
97
CELLTRC Command
Overview The CELLTRC command is used to trace storage cell usage. This can be useful
when diagnosing problems involving uncontrolled storage allocation.
Authority OPER authority is required to issue the CELLTRC command.
Syntax The syntax of the CELLTRC command is:
CELLTRC
Usage notes A snapshot data set must first be created. This data set will contain the storage cell
snapshots that are generated by the CELLTRC command. The following DCB
attributes should be used:
DSORG=PS,RECFM=VB,LRECL=137,BLKSIZE=6144
The following DD statement must be added to the ESP subsystem cataloged
procedure:
//CELLTRC DD DISP=SHR,DSN=celltrc.dataset
Start the subsystem with the following command. Note that the @CELLTRC
keyword must be the first parameter in the PARM string. Once activated, cell
tracing remains active only during the current execution of ESP. To keep cell
tracing active, the @CELLTRC keyword must be used each time ESP is started:
S ESP,PARM=@CELLTRC,...
The CELLTRC command causes the subsystem to generate a storage cell snapshot
and place it in the cell trace data set that is named in the CELLTRC DD statement.
It may be issued from an MVS console or from Page mode.
To deactivate cell tracing, restart the subsystem without using the @CELLTRC
keyword.
98
CELLTRC Command, Continued
Usage notes
continued
The storage cell snapshot consists of three sections: the cell pool header display, the
cell display, and the cell summary.
The cell pool header display shows the available cell size and how many of each size
are currently allocated. The COUNT field indicates how many cells of a particular
size are allocated, while the ACTIVITY field shows the number of gets and frees
done for this cell size:
SIZE 8, COUNT 0, ACTIVITY 0
The cell display describes each individual cell that is presently allocated. Its size
and requestor CSECT are shown, along with up to 64 bytes of its contents. Also
shown is the CSECT that called the requestor CSECT. The offset within each
CSECT from which the request was made is also shown:
CELL SIZE 128, REQUESTED BY CYBXI000+0054, CALLED BY
CYBXR003+0CA6
+0 00039F80 00000000 000076F3 00873C54 00000000 ...
+20 00039FA0 00000000 00000000 003D2448 003D2450 ...
CELL SIZE 32, REQUESTED BY CYBXI003+0CF4, CALLED BY
CYBJS107+0DB8
+0 003D2448 00000000 008876F3 00000000 00000000 ...
...
Usage notes
continued
The cell summary lists the number of cells that are currently allocated, but arranged
by requestors base address and requesting address, and by the requestors callers
base address and calling address. The following example shows that 3 cells of size
32 are currently allocated, having been requested by CYBXI003 at offset 0CF4 who
was called by CYBJS107 at offset 0DB8. The base address of the CYBXI003
CSECT is at 02357708, and the request was made from address 023583FC:
---- STORAGE ALLOCATED BY REQUESTORS ADDRESS
ADDR 0234574C, BASE 023456F8, COUNT 1, BYTES 128 -
CYBXI000+0054
ADDR 023583FC, BASE 02357708, COUNT 3, BYTES 32 -
CYBXI003+0CF4
---- STORAGE ALLOCATED BY REQUESTORS CALLERS ADDRESS
ADDR 02365E38, BASE 02365080, COUNT 3, BYTES 32 -
CYBJS107+0DB8
ADDR 02358C36, BASE 02357F90, COUNT 1, BYTES 128 -
CYBXR003+0CA6
99
CELLTRC Command, Continued
Example The following CELLTRC command is used to trace storage cell usage:
CELLTRC
In the above example, storage cell usage is generated and placed in the cell trace
data set named in the CELLTRC DD statement.
100
CHECKEXC Statement
Overview The CHECKEXC statement is used to indicate that ESP should check the last non-
blank character of every card image written to the internal reader. If the symbolic
variable is representing that last non-blank character is set to a (not sign), the
card image is deleted. If the symbol variable is set to blank, null, or to any other
string, the card image is not deleted. The CHECKEXC statement cannot be used in
an ESP Procedure.
Syntax The syntax of the CHECKEXC statement is:
CHECKEXC
Usage notes Enter the CHECKEXC statement anywhere in a symbolic library data set. Multiple
exclusion symbols can be used.
Define the symbolic variable that is to represent the last non-blank character, either
in a symbol library data set, or in an ESP Procedure. The value can be a blank
character, null character or any other character string.
Use the symbol in your JCL wherever you want to exclude a JCL statement.
Reference the symbolic variable library and ESP Procedure (if you defined the
symbolic variable in an ESP Procedure) in the Event that submits the JCL.
To turn the feature off, specify NOCHECKEXC.
Note: The recommended method for including and excluding JCL is to use
%INCLUDE IF and %EXCLUDE IF.
Related
Statements
For information on turning off the checking of the last non-blank character of every
card image written to the internal reader, see the NOCHECKEXC statement.
For information on selectively including JCL, see the %INCLUDE statement.
For information on selectively excluding JCL, see the %EXCLUDE statement.
101
CHECKEXC Statement, Continued
Example 1 The following CHECKEXC statement indicates that ESP should check the last non-
blank character of every card image written to the internal reader, and set the value
of a symbolic variable:
CHECKEXC
X=
In the above example, when %X appears as the last non-blank character on any
card image written to the internal reader, that card image is excluded.
The following example uses the exclusion symbol (defined above) in JCL:
//PAYJOB1 JOB
//STEP001 EXEC PGM=ABC
//STEP002 EXEC PGM=DEF%X
In the above example, when ESP submits PAYJOB1, STEP002 is excluded.
Example 2 The following CHECKEXC statement indicates that ESP should check the last non-
blank character of every card image written to the internal reader, and set the value
of a symbolic variable on specific days:
CHECKEXC
Z=
%INCLUDE DAY(MONDAY,THURSDAY)
Z=
%ENDINCL
In the above example, on Mondays and Thursdays, the last non-blank character of a
card image is set to , excluding that card image.
The following is an example of using the exclusion symbol (defined above) in JCL:
//PAYJOB2 JOB
//STEP001 EXEC PGM=ABC%Z
//STEP002 EXEC PGM=DEF
//STEP003 EXEC PGM=GHI%Z
In the above example, when ESP submits PAYJOB2 it includes:
STEP002 each time
STEP001 and STEP003 each time except on Mondays and Thursdays, because the
value of Z is set to on those days.
102
CHECKEXC Statement, Continued
Example 3 The following shows how to exclude JCL by using a symbolic variable library and
an ESP Procedure.
The following CHECKEXC statement is specified in a symbolic variable data set:
CHECKEXC
In the above example, CHECKEXC is specified to indicate that ESP should check
the last non-blank character of every card image written to the internal reader.
The following IF/THEN/ELSE logic is specified in an ESP Procedure to set the
value of the symbolic variable:
IF TODAY(FIRST WORKDAY OF MONTH) THEN FWM=
ELSE FWM=
In the above example, the value of a symbolic variable called FWM is set to on
the last workday of each month.
The following example uses the exclusion symbol (defined above) in JCL:
//PAYJOB3 JOB
//STEP001 EXEC PGM=JKL
//STEP002 EXEC PGM=MNO%FWM
In the above example, when ESP submits PAYJOB3 it includes:
STEP001 each time
STEP002 each time except on the first workday of each month, because the value
of FWM is set to .
103
CLASS Command
Overview The CLASS command is used to display and manipulate class queues. When an
Event is defined, it can be associated with a particular class. A class is a user-
defined string of up to eight characters that can be used to group Events logically
together. If a class name is omitted from an Event definition, the Event name prefix
is used as the class name.
Authority OPER authority is required to issue the CLASS command.
Syntax The syntax of the CLASS command is:
{CLASS|CL} classname
[HOLD|RELEASE]
[SUSPEND|RESUME]
[EXEMPT|DEEXEMPT]
[RESET|FLUSH]
[IGNORE|PROCESS]
[LIST]
classname Indicates a class name specification of up to eight characters.
The specification may include wildcards. Several class names
can be specified. They should be entered within parentheses
and separated by blanks or commas.
HOLD Indicates Events in classes described by the class name are
placed in a hold queue at their scheduled time.
RELEASE Indicates any Events held in class queues described by the
class name are released and placed on the overdue queue. A
message is issued indicating how many Events were released
in each class.
SUSPEND Indicates Events in classes described by the class name are
bypassed at their scheduled execution time.
RESUME Indicates the SUSPEND restriction is removed for the classes
described by the class string.
EXEMPT Indicates Events in classes described by the class name are
exempt from class hold or suspend restrictions.
DEEXEMPT Removes the EXEMPT restriction.
RESET Removes any restrictions from the specified class name.
104
CLASS Command, Continued
Syntax (continued)
FLUSH Indicates any Events on the specified class hold queues are
flushed and will not execute. This does not affect future
scheduled executions.
IGNORE Indicates Events in classes described by the class name are
ignored at their scheduled execution time only on the ESP
system that issued the CLASS command with the IGNORE
parameter.
PROCESS Indicates the IGNORE restriction is removed for the classes
described by the class name.
LIST Displays any class hold queues for the specified classes. This
is the default.
Usage notes The CLASS command allows you to manipulate a group of Events.
If the CLASS command is entered with no parameters, the current list of restrictions
is displayed, along with the names of any class hold queues and the number of
Events in each.
The class restriction lists and hold queues are checkpointed and are retained across
warm starts. A cold start clears all the queues and class restriction lists.
The scope of the CLASS command is that of the current system only, and not of any
other systems sharing the same data sets. Issue the CLASS command on each
system that you want to affect.
Holding a class affects active Applications by preventing any further job submission
until you release the class or exempt the associated Event.
If you suspend a class associated with an active Application, the Application stops
processing and does not continue when you resume the class.
Related
information
For information on starting an Event definition, see the EVENT command.
For information on working with ESP Events, see the ESP Workload Manager
Users Guide.
For information on putting ESP into a quiesced state, see the QUIESCE command.
Example 1 The following CLASS command displays all classes:
CLASS
In the above example, all class queues are displayed.
105
Example 2 The following CLASS commands hold an Event class:
CLASS PROD HOLD LIST
In the above example, all Events associated with the PROD class are held.
Note: By specifying LIST (above) you will receive the following message:
FOLLOWING CLASSES EXEMPT(E), HELD(H) SUSPENDED(S) IGNORED(I)
PROD1(S), PROD2(S)
Example 3 The following CLASS command holds specific Event classes:
CLASS - HOLD;CLASS **PA- EXEMPT
In the above example, all Event classes are held, except for those Event classes with
characters PA in positions three and four.
Example 4 The following CLASS command resumes a previously held Event class:
CLASS PROD RESUME
In the above example, all Events associated with the PROD class are resumed.
Example 5 The following CLASS command suspends all Event classes except one.
CLASS - SUSPEND;CLASS PAY EXEMPT LIST
In the above example, all Event classes are suspended, except the Event classes
associated with the PAY class.
Note: By specifying LIST (above), you receive the following message:
FOLLOWING CLASSES EXEMPT(E), HELD(H) SUSPENDED(S) IGNORED(I)
PAY(E), -(S)
Example 6 The following CLASS command holds specific Event classes:
CLASS (CLNT1,CLNT2) HOLD
In the above example, all Event classes CLNT1 and CLNT2 are held.
106
Example 7 The following CLASS command flushes all classes:
CLASS - FLUSH
In the above example, all class hold queues are flushed and do not execute. This
does not affect future scheduled executions.
107
CLRSYSMS Command
Overview The CLRSYSMS command is used to clear system message interceptions which
were defined using the SYSMSGS command.
Authority OPER authority is required to issue the CLRSYSMS command.
Syntax The syntax of the CLRSYSMS command is:
CLRSYSMS ID(xxxx)
ID(xxxx) Indicates an identifier consisting of four alphanumeric
characters to clear a specific message intercept. To clear all
system message intercepts, code ID(*).
Related
information
For information on intercepting messages written to the system message data set, see
the SYSMSGS command.
For information on displaying information on all system messages that are currently
being intercepted by ESP, see the LSYSMSGS command.
Example 1 The following CLRSYSMS command clears a specific system intercept:
CLRSYSMS ID(0022)
In the above example, a system message intercept whose identifier is 0022 is
cleared.
Example 2 The following CLRSYSMS command clears all system message intercepts:
CLRSYSMS ID(*)
In the above example, all system message intercepts are cleared.
108
CMDPRFX Command
Overview The CMDPRFX command allows you to substitute the string the F stcname,
(where stcname is the started task name for ESP) with a single character. This
allows you to enter a single character instead of specifying F stcname, when
modify commands to ESP are entered from a system console.
Authority OPER authority is required to issue the CMDPRFX command.
Syntax The syntax of the CMDPRFX command is:
CMDPRFX character F stcname,
character Indicates a single character, which is to be substituted for the
F stcname string, where stcname is the name of your ESP
started task.
Usage notes Do not choose an MVS command character, i.e. C (Cancel), Z (Halt) or F (Modify)
and so on, to represent the F ESP, string.
Related
information
For information on displaying whether command prefixing is in effect or not, see the
LCMDPRFX command.
Example 1 The following CMDPRFX command substitutes a single character for the
F ESPPROD, string:
CMDPRFX # F ESPPROD,
In the above example, # is substituted for F ESPPROD, when modify commands to
ESP are entered from a system console.
As a result of setting the command prefix to #, you can enter the following command
from a system console to trigger an Event.
# TRIGGER CYBER.PAYROLL ADD
109
COM Command
Overview The COM command is used to add any number of comments, anywhere in an Event
between the EVENT command and the ENDDEF command. ESP ignores any
comments when an Event is triggered.
Type Event definition command.
Syntax The syntax of the COM command is:
COM comment
comment Any string.
Usage notes If you have more than one comment, you must use COM at the beginning of each
comment line.
Related
information
For information on starting an Event definition, see the EVENT command.
For information on ending an Event definition, see the ENDDEF command.
Users Guide.
Example 1 The following COM command is used to add a comment to an Event:
EVENT ID(CYBER.PAYJOBS)
COM THIS IS AN EVENT TO SUBMIT PAYROLL JOBS EVERY THURSDAY
SCHEDULE 19:00 THURSDAYS
SUBMIT PROD.JCL.CNTL(PAYJOB1)
SUBMIT PROD.JCL.CNTL(PAYJOB2)
ENDDEF
In the above example, a comment is added to the Event indicating what the Event is
doing (submitting jobs) and when the Event is to submit those jobs (Thursdays).
110
CONNECT Command
Overview The CONNECT command is used to tell ESP which user belongs to which group.
Authority SPECIAL or CONNECTDEF authority is required to issue the CONNECT
command in a non-SAF environment.
Note: CONNECT is applicable only when using ESP Workload Managers internal
security.
Syntax The syntax of the CONNECT command is:
{CONNECT|CON} userid
GROUP(groupname)
[EXECUTE]
[READ]
[UPDATE]
userid Indicates the name of the user to be connected to the group.
groupname Indicates the name of the group to which the user is to be
connected.
EXECUTE Indicates the user ID is permitted to trigger an Event; with
additional READ access, the user can control jobs in an
Application created by an Event with the following
restrictions: unable to insert jobs or resubmit a job with a
different JCL library.
READ Indicates the user ID is permitted to display an Event, list the
schedule and display the status of jobs the Event submits.
UPDATE Indicates the user ID is permitted to define or update an Event
definition; with additional READ access, the user can control
jobs in an Application created by an Event with no
restrictions.
111
CONNECT Command, Continued
Usage notes A user with an authority attribute of ANY has access to any Group. Such a user
does not need to be connected to any Group.
If you do not define a type of access, i.e. READ, EXECUTE or UPDATE, the user
has unrestricted access to Events with the Group prefix.
You can connect a user to more than one group. When you connect a user to more
than one group, that user can use the GROUP command in Page mode to switch
between his or her user ID and any group he or she can access. This is useful when
using commands where a group prefix is required.
When you display a group, ESP lists all the users connected to that group.
When you display a user, ESP lists all the groups to which a user is connected. If
there are any access restrictions to a group, they are listed in parenthesis. ESP uses
the following abbreviations for access permissions: R (READ), X (EXECUTE), and
U (UPDATE).
Related
information
For information on removing a users access from a Group prefix, see the
DISCONN command.
For information on working with users and groups, see the ESP Workload Manager
For information on listing a user definition, see the LISTUSER command.
Example 1 The following CONNECT command connects a user to a group:
CONNECT USER1 GROUP(PROD)
In the above example, USER1 is connected to PROD. USER1 has full access to
Events with the PROD prefix because READ, EXECUTE or UPDATE were not
specified.
Example 2 The following CONNECT command connects a user to a group:
CONNECT USER2 GROUP(TEST) EXECUTE
In the above example, USER2 is connected to TEST. USER2 is permitted to trigger
Events with the TEST prefix. If READ access is given to USER2 in addition to
EXECUTE access, USER2 is able to control jobs in an Application created by an
Event, but unable to insert jobs or resubmit a job with a different JCL library.
112
CONSOLE Command
Overview The CONSOLE command is used to set the owning or primary console. All
general message traffic is directed to the owning console.
Authority OPER authority is required to issue the CONSOLE command.
Syntax The syntax of the CONSOLE parameter is:
CONSOLE [*|ucmid|0|name]
* Requests the console issuing the command is made the
primary console.
ucmid Indicates a one or two digit console UCMID.
0 Indicates no console. Messages routed by routing code on to
the active Master console.
name Indicates the one-to-eight character name of an active console
in the ESP complex.
Usage notes A primary console must be an active one with the capability for both input and
output. If no operands are specified, the current primary console information is
displayed. The console must be active when the request is issued.
Example 1 The following CONSOLE command sets a primary console:
CONSOLE 2
In the above example, console 2 is set as the primary console.
CONSOLE *
In the above example, the issuing console assumes the role of the primary console.
113
CONSOLE Command, Continued
CONSOLE BOSS
In the above example, a console named BOSS is set as the primary console.
114
COPY Command
Overview The COPY command is used to specify an output data set or file to receive all or
subsets of the job history record read in from the input source. The COPY
command is useful when you want to separate data in a history file into one or more
files.
Syntax The syntax of the COPY command is:
COPY {DATASET(dsname)}
{FILE(filename)}
[SELECT|ALL|REJECT]
[EXTEND]
dsname Indicates the name of the output data set. This is mutually
exclusive with the filename option.
filename Indicates the name of the file to which the data is to be
written. This is mutually exclusive with the dsname option.
SELECT Indicates only records matching any selection criteria are
copied. If no CRITERIA section exists in the report
definition, all records are copied.
ALL Indicates all records in the input file(s) are copied to the
output file.
REJECT Indicates the copy is restricted to any records that fail to
match any selection criteria. If no criteria section exists, no
records are copied.
EXTEND Indicates the data to be copied be added to the end of the
output data set rather than to replace existing data.
Usage notes There is no restriction to the number of COPY commands that can be included in a
single report definition; records are copied in their original sequence.
ESP writes to any format sequential data set. If a data set is new and you have not
yet specified a record format for it, ESP uses the following default:
LRECL=4096
RECFM=VBS
BLKSIZE=6144
Related
information
115
COPY Command, Continued
Example 1 The following COPY command copies data into two separate files:
REPORT
HISTFILE HIST1
CRITERIA RDRON GT TODAY LESS 12 WEEKS
COPY SELECT FILE(DISK1)
COPY REJECT FILE(TAPE1)
In the above example, records less than 12 weeks old when the request is made are
copied the file DISK1. Records that are more than 12 weeks old when the request is
made are copied to the file TAPE1.
116
COPYJCL Statement
Overview The COPYJCL statement is used to generate a copy of the JCL for every job ESP
submits. When you use the COPYJCL statement you must specify the library that is
to receive the copy, followed by either the JOBNAME or JOBID keyword. This
working copy of the JCL can be used for job re-submission. ESP keeps track of
where the job was submitted from and the JCL that was used.
Type ESP Event statement, ESP Application statement.
Syntax The syntax of the COPYJCL statement is:
COPYJCL {datasetname|NONE}
[GENERATION(genno)]
[JOBNAME|JOBID]
datasetname Indicates the name of an existing partitioned data set to which
you have update authority. This is the data set to which the JCL
copy is made.
NONE Indicates no JCL copy is needed. This can only be used at the
job level in an Application.
genno Indicates the name of an existing GDG and optional generation
number. The generation number should be a zero or a negative
number. GENERATION can be abbreviated to GEN.
JOBNAME Indicates the member name used for storing the JCL for a job is
the same as the jobname. This is the default.
JOBID Indicates the member name used for storing the JCL for a job is
the JES jobid. It is in the form JOBnnnnn, where nnnnn is the
job number.
117
COPYJCL Statement, Continued
Usage notes You can specify COPYJCL in the Event definition of any Event that submits jobs.
This copy is written to a member of a PDS, providing a working copy of the JCL
with, where applicable, all symbolic variables resolved and NET cards (for
DJC/JES3) are included.
You can also specify COPYJCL within an Application definition to identify one or
more jobs for which you want to use COPYJCL. This gives you the advantage of
using COPYJCL for specific jobs.
The JOBNAME keyword requests that the member name used for storing the JCL
for a job is the same as the jobname. This is the default. Each submission of a
particular job overwrites the previous copy of that jobs JCL.
Use the JOBID keyword when you want ESP to store the copy of the JCL by job
number. ESP creates a member name starting with JOB, followed by a fivedigit
JES job number. The system assigns this number sequentially. A member is not
overwritten until its fivedigit number reoccurs.
Note: With either option (JOBNAME or JOBID), you can write the JCL to a PDS
GDG (generation data group).
Related
Statements
Users Guide.
For information on identifying JCL, see the ESP Workload Manager Users Guide.
Example 1 The following COPYJCL statement used in an ESP Event indicates that ESP should
write a copy of all submitted jobs to a PDS:
EVENT ID(CYBER.PAYROLL)
INVOKE CYBBS01.PROCLIB.CNTL(PAYROLL)
COPYJCL CYBER.COPYLIB.CNTL JOBNAME
ENDDEF
In the above example, ESP writes a copy of all submitted jobs within the
PAYROLL Application to CYBER.COPYLIB.CNTL and stores the jobs by
jobname.
118
COPYJCL Statement, Continued
Example 2 The following COPYJCL statement used in an ESP Application indicates that ESP
should write a copy of all submitted jobs except PAYJOB2 to a PDS:
APPL PAYROLL
COPYJCL CYBER.COPYLIB.CNTL JOBID
JOB PAYJOB1
RELEASE PAYJOB2
JOB PAYJOB2
RELEASE PAYJOB3
COPYJCL NONE
JOB PAYJOB3
ENDJOB
SELECT (PAYJOB1,PAYJOB2,PAYJOB3)
PAYROLL Application excluding PAYJOB2 to CYBER.COPYLIB.CNTL and
stores the jobs by JES jobid.
Example 3 The following COPYJCL statement used in an ESP Event indicates that ESP should
write a copy of all submitted jobs to a GDG.
INVOKE CYBBS01.PROCLIB.CNTL(PAYROLL)
COPYJCL CYBER.COPYLIB.CNTL GEN(0) JOBNAME
ENDDEF
PAYROLL Application to the current generation of CYBER.COPYLIB.CNTL
and stores the jobs by job name.
119
COREQ Statement
Overview The COREQ statement is used to specify the name(s) of any other job that is
selected automatically whenever the specified job is selected. The specified job and
all of its co-requisites are allowed to execute simultaneously.
Syntax The syntax of the COREQ statement is:
COREQ {jobname}
{jobname[,jobname]...}
{ADD(jobname[,jobname]...)}
{DROP(jobname[,jobname]...)}
jobname Indicates a jobname in up to eight characters. Enclose multiple
job names in parentheses, separated by a blank or a comma.
ADD Indicates the specified job(s) be added to those currently
defined COREQs. If a previous COREQ statement was
specified in the ESPPROC, the job(s) is added to these as well.
DROP Indicates the specified job(s) be dropped from those currently
defined COREQs.
Usage notes A COREQ statement overrides any previous COREQ statement for the same job
unless the ADD keyword is specified. COREQ can be used with any job to name
other jobs that must be selected for execution whenever this job is selected.
The COREQ statement specifies jobs that are selected when the specified job is
selected. It does not cause the COREQ jobs to inherit any of the relationships of the
specified job. The appropriate relationships need to be specified using PREREQ,
POSTREQ, AFTER, or RELEASE statements.
The COREQ statement forces selection of the co-requisite jobs - no SELECT
statement or RUN statement is required.
Related
Statements
For information on specifying job relationships, see the AFTER, RELEASE,
PREREQ, and POSTREQ statements.
120
COREQ Statement, Continued
Example 1 The following COREQ statement identifies job relationships within an Application:
APPL PAYROLL
JOB PAYJOB1
RUN MONDAY
COREQ PAYJOB2
JOB PAYJOB2
ENDJOB
In the above example, whenever PAYJOB1 is selected, ESP always selects
PAYJOB2. There is no relationship between PAYJOB1 and PAYJOB2.
APPL PAYROLL
JOB PAYJOB3
RUN WORKDAYS
COREQ (PAYJOB4,PAYJOB5,PAYJOB6)
JOB PAYJOB4
JOB PAYJOB5
JOB PAYJOB6
ENDJOB
In the above example, PAYJOB3, PAYJOB4, PAYJOB5 and PAYJOB6 are selected
for submission and will run simultaneously on workdays.
APPL PAYROLL
JOB PAYJOB7
RUN WORKDAYS
COREQ (PAYJOB8,PAYJOB9)
COREQ ADD(PAYJOB10,PAYJOB11)
JOB PAYJOB8
JOB PAYJOB9
JOB PAYJOB10
JOB PAYJOB11
ENDJOB
In the above example, whenever PAYJOB7 is selected, ESP always selects
PAYJOB8, PAYJOB9, PAYJOB10 and PAYJOB11.
121
COREQ Statement, Continued
Example 4 The following COREQ and RELEASE statements are used to:
Indicate jobs that can run simultaneously
Indicate a relationship between jobs.
APPL PAYROLL
JOB PAYJOB12
RUN DAILY
RELEASE PAYJOB13
JOB PAYJOB13
RUN FRIDAY
COREQ (PAYJOB14,PAYJOB15,PAYJOB16)
ENDJOB
PAYJOB12 runs every day
On Fridays PAYJOB12, PAYJOB14, PAYJOB15 and PAYJOB16 run
simultaneously, because the COREQ jobs do not inherit any relationship to
PAYJOB13
PAYJOB13 runs after PAYJOB12 successfully completes.
122
CPU Command
Overview The CPU command is used in conjunction with the NODE parameter, to define the
resource topology of your network. The CPU command defines each CPU within a
node.
Syntax The syntax of the CPU parameter is:
CPU name [ADD|DEL|LIST|SET]NODE(nodename)
[ROUTEJCL(/*JOBPARM SYSAFF=...)]
[ORDER(nn)]
[CURRENT]
[ACTIVE|INACTIVE]
[DEL[FORCE]]
name Indicates the name to identify this CPU. This must be a
unique name. When used with NODE, you may have the
name correspond to, for example, an existing JES node name
or SMF id, but this is not mandatory. The asterisk (*) and
hyphen (-) may be used as wild card characters for masking
the name with all parameters except ADD.
ADD Indicates this is a new definition.
DEL Deletes one or more existing definitions.
LIST Displays list of one or more existing definitions. This is the
default.
SET Modifies attributes of existing definitions.
NODE(nodename) Indicates the node of which the CPU is a member as specified
by the NODE parameter.
ROUTEJCL Indicates a JCL image that, when inserted into a jobs JCL,
causes the job to be routed to the appropriate CPU or node.
ORDER(nn) Allows the installation to define a search sequence. When
ESP tries to schedule a job, it scans for resource availability
by CPU, searching the CPUs in sequence defined by the
ORDER value. If two CPUs have the necessary resources to
execute a job, ESP schedules the job to the one with the
lowest ORDER value.
CURRENT Indicates the CPU on which the ESP subsystem doing the
submission is executing. No ROUTE JCL is generated for
jobs on the current system.
ACTIVE Indicates a CPU or node be considered active. This is the
default.
123
CPU Command, Continued
ACTIVE (continued)
INACTIVE Indicates a CPU or node be considered inactive. ESP does
not attempt to schedule a job to that node or CPU while it is
inactive.
DEL FORCE Indicates the specified CPU is to be deleted. The FORCE
option is only valid when deleting the last defined CPU.
Note: The CPU must be inactive to be deleted.
Usage notes The CPU command is generally used at the Initialization Parameter level, and is
used in conjunction with the NODE parameter to define the resource topology of
your network.
Related
information
For information on defining the resource topology of your network, see the CPU,
NODE, and RESFILE parameters in the ESP Workload Manager Installation Guide.
For information on Resources, see the ESP Workload Manager Users Guide.
Example 1 The following CPU command displays all defined CPUs:
CPU - LIST
In the above example, all CPUs defined as part of the resource topology are
displayed.
Example 2 The following CPU command first inactivates a specific CPU, then deletes that
CPU:
CPU T1 SET INACTIVE
then
CPU T1 DEL FORCE
In the above example, T1 is inactivated and then deleted.
Example 3 The following NODE and CPU commands define a node and CPU:
NODE TORONTO ADD
CPU T1 ADD NODE(TORONTO) CURRENT
In the above example, a single node called TORONTO is defined, and a single CPU
called T1 is defined as a member of the TORONTO node.
124
CRITERIA Command
Overview The CRITERIA command is used to specify selection criteria when producing ESP
history reports. You can specify several field, operator and value groups.
Syntax The syntax of the CRITERIA command is:
CRITERIA field operator value
field Indicates a field name keyword (such as JOBNAME).
For a detailed list of the history reporting fields, see the ESP
operator Indicates a comparison operator in either their letter or
symbol form:
LT or <
LE or <=
EQ
NE or =
GT or >
GE or >=
value Indicates the value against which comparisons should be
made. Its format depends on the field type.
Usage notes You can specify several criteria sections in a single report using multiple criteria
commands. ESP selects a job if it satisfies any criteria section.
You can specify several criteria elements on 1 criteria statement. To be selected a
job must satisfy all criteria.
You can also use the OR and AND logical operators.
If you want to compare a field to a null string, use a blank enclosed in single quotes,
as in .
If you do not specify a CRITERIA section in your report, ESP selects all records that
meet the time criteria.
Related
information
125
CRITERIA Command, Continued
Example 1 The following CRITERIA command specifies selection criteria:
In the above example, jobs that belong to the PAYROLL Application are selected.
CRITERIA JOBNAME EQ P-
In the above example, jobs that belong to the PAYROLL Application, or jobs that
start with P, are selected.
CRITERIA APPLSYS EQ PAYROLL JOBNAME EQ P-
In the above example, jobs that belong to the PAYROLL Application, and jobs that
start with P, are selected.
CRITERIA ENDT GT 09:00 TODAY
In the above example, jobs that have completed execution since 9 am today are
selected.
126
CRITERIA Command, Continued
CRITERIA JOBNAME EQ XYZ- CPUTIME GT 11L00 TEXCP GT 0 -
STATUS EQ COMPLETE
In the above example, jobs which meet all of the following criteria are selected:
Have names beginning XYZ
Consume more than 11 seconds of CPU time
Perform I/O to tape
And which have completed processing.
CRITERIA TEXCP GT 0 OR DEXCP GT 10000
CRITERIA JOBNAME EQ ABC- OR JOBNAME EQ A*
In the above example, jobs which meet any of the following criteria are selected:
Have more than 10000 EXCPs to DASD devices
Perform I/O to tape
Have names beginning ABC
Two-character names that begin with A.
CRITERIA ESPSUB EQ YES AND APPLSYS NE
In the above example, all jobs submitted by ESP that do not belong to an
Application are selected.
127
CRITPATH Command
Overview The CRITPATH command is used to enable or disable Critical Path analysis on this
ESP system.
Authority OPER authority is required to issue the CRITPATH command.
Syntax The syntax of the CRITPATH command is:
CRITPATH [DISABLE|ENABLE|ON]
Operand Description
DISABLE Disallows critical path analysis on this system. Critical path
analysis cannot be used on this system when disabled. This is
the default.
ENABLE Allows critical path analysis on this system. Then specify
CRITPATH ON within the Applications where you want
critical path analysis performed.
ON Turn on critical path analysis for all Applications. It can be
turned off within an Application using the CRITPATH OFF
statement.
Usage notes By default, critical path analysis is turned off or disabled for all Applications that
ESP generates. To control usage of critical path analysis a CRITPATH initialization
statement, a CRITPATH Application statement and a CRITPATH command are
provided. The following chart summarizes how ESP handles critical path analysis
based on various CRITPATH parameter and statement settings:
If the CRITPATH
initialization parameter is
set to
And the CRITPATH
Application statement is
set to
Then critical path
analysis is
DISABLE OFF Not calculated
DISABLE ON Not calculated
DISABLE Not specified Not calculated
ENABLE OFF Not calculated
ENABLE ON Calculated
ENABLE Not specified Not calculated
ON OFF Not calculated
ON ON Calculated
ON Not specified Calculated
128
CRITPATH Command, Continued
Usage notes,
contd
If critical path analysis is activated by coding either CRITPATH ON in the
Initialization Parameters, or CRITPATH ENABLE in the Initialization Parameters
and CRITPATH ON in the Application, but no jobs are coded with the CRITICAL
keyword, ESP calculates the path to the job that will finish last and identifies that
path as the critical path.
Related
Statements
For information on critical path analysis, see the ESP Workload Manager Users
Guide.
For information on specifying whether critical path analysis is to be performed for
an Application, see the CRITPATH Application statement.
For information on overriding historical elapsed time defaults, see the DURATION
statement.
Example 1 The following CRITPATH command turns on critical path analysis:
CRITPATH ON
In the above example, critical path analysis is turned on for all Applications
generated by ESP on this system. If required, critical path analysis can be turned off
for specific Applications by coding CRITPATH OFF in the Application definition.
Example 2 The following CRITPATH command enables critical path analysis:
CRITPATH ENABLE
In the above example, critical path analysis is enabled for this ESP system. To turn
on critical path analysis for an Application, code CRITPATH ON in the Application
definition.
Example 3 The following CRITPATH command disables critical path analysis:
CRITPATH DISABLE
In the above example, critical path analysis is disabled for this ESP system. To turn
off critical path analysis for an Application, code CRITPATH OFF in the
Application definition.
129
CRITPATH Application Statement
Overview This CRITPATH statement is used to specify whether critical path analysis is to be
performed for this Application.
Type ESP Application statement
Syntax The syntax of the CRITPATH statement is:
CRITPATH [ON|OFF]
Operand Description
ON Turns on Critical Path analysis for this Application.
Note: Critical Path analysis must also be enabled for this ESP
system. Enable it using the CRITPATH Initialization
Parameter, or the CRITPATH operator command.
OFF Turns off Critical Path analysis for this Application. Use this
option when Critical Path analysis is turned on in the
Initialization Parameter, but you dont want to perform the
analysis for this specific Application.
Usage notes The CRITPATH statement works in conjunction with the CRITPATH Initialization
Parameter or the CRITPATH command to turn Critical Path analysis on or off. The
CRITPATH Initialization Parameter and command are used to enable Critical Path
analysis on the system. To perform the analysis, you need to turn Critical Path
analysis on, using the CRITPATH statement.
Related
information
Guide.
For information on enabling or disabling critical path analysis, see the CRITPATH
command.
Example 1 The following CRITPATH command turns on critical path analysis:
APPL PAYROLL
CRITPATH ON
JOB PAYJOB1
In the above example, critical path analysis is turned on for the PAYROLL
Application.
130
CRITPATH Application Statement, Continued
Example 2 The following CRITPATH command turns off critical path analysis:
APPL PAYROLL
CRITPATH OFF
JOB PAYJOB2
In the above example, critical path analysis is turned off for the PAYROLL
Application.
131
DAB Command
Overview The DAB command is used to display all or selected jobs from the abended queue.
Authority OPER authority is required to issue the DAB command.
Syntax The syntax of the DAB command is:
DAB [LEVEL(jobstring)]
[LAST(minutes)|FROM(time)]
[TIME]
[DATE]
[PROD]
jobstring Indicates one or more jobname prefixes to limit the display to
a particular group of jobs. The string can contain asterisks
and a hyphen.
minutes Indicates only jobs that abended in the last n minutes are to be
displayed.
time Indicates only jobs that abended after that specified time are
to be displayed. This must be a time in the past. The time
and date can be specified in free format. If the time and date
contain blanks or commas, enclose the whole string within
quotes.
TIME Indicates the time of the abend is displayed together with the
completion code.
DATE Indicates the date of the abend is displayed together with the
completion code.
PROD Indicates an updated display of ABENDed jobs (i.e. only
those still in ABEND status). This keyword applies only to
jobs in an Application.
Usage notes The DAB command displays jobs from the abended queue. The size of the abended
queue is set with the ABENDLIM command.
The jobname, job number and completion code fields are always displayed. Jobs are
displayed in reverse chronological order; that is the most recently abended jobs are
shown first. This command can be issued from a system console.
132
DAB Command, Continued
Related
information
For information on displaying abended jobs using the CSF, see the ESP Workload
For information on displaying or setting the abend queue size for jobs that ESP is
tracking, see the ABENDLIM command.
Example 1 The following DAB command displays all abended jobs:
DAB
In the above example, all abended jobs on the queue up to the limit set by the
ABENDLIM command are displayed.
Example 2 The following DAB command displays specific jobs:
DAB LEVEL(PR- PAY-) FROM(1AM) TIME
In the above example, jobs with names beginning with PR and PAY that have
abended since 1:00 am, are displayed.
Example 3 The following DAB command displays abended jobs within the last hour:
DAB LAST(60) TIME
In the above example, jobs that have abended in the last 60 minutes are displayed.
The time each job abended is also displayed.
Example 4 The following DAB command displays an updated list of abended jobs:
DAB PROD
In the above example, an updated display of ABENDed jobs is displayed, i.e. only
those jobs still in abend status.
133
DATASET Statement
Overview The DATASET statement is used to specify the JCL library and optional member
name to be used for a particular job. The DATASET statement must be placed
within the scope of a JOB statement.
Syntax The syntax of the DATASET statement is:
DATASET dsname
[member]
dsname Indicates the name of the data set.
member If this is a PDS, it optionally specifies the member name. If the
member name is omitted, the job name is the default.
Usage notes The DATASET you specify applies only to this particular job. DATASET is used
to identify the JCL library and optionally the member name to be used for a
particular job. This overrides, for this job only, the default JCL library already
named in a JCLLIB statement.
Related
Statements
For information on specifying different JCL libraries, see the ESP Workload
Example 1 The following DATASET statement indicates an alternative JCL library for a job
within an Application:
APPL PAYROLL
JOB PAYJOB1
RUN DAILY
RELEASE PAYJOB2
JOB PAYJOB2
RUN DAILY
DATASET CYBER.ALTJCL.CNTL
ENDJOB
In the above example, when ESP submits jobs in the PAYROLL Application:
PAYJOB1 is submitted from CYBER.JCL.CNTL
PAYJOB2 is submitted from CYBER.ALTJCL.CNTL.
134
DATASET Statement, Continued
Example 2 The following DATASET statement indicates an alternative JCL library and
member for a job within an Application:
APPL PAYROLL
JOB PAYJOB3
RUN DAILY
RELEASE PAYJOB4
JOB PAYJOB4
RUN DAILY
DATASET CYBER.ALTJCL.CNTL(PAYJOB99)
ENDJOB
In the above example, when ESP submits jobs in the PAYROLL Application:
PAYJOB3 is submitted from CYBER.JCL.CNTL
PAYJOB4 is submitted from member PAYJOB99 within data set
CYBER.ALTJCL.CNTL.
APPL PAYROLL
JOB PAYJOB5
RUN DAILY
IF TODAY(FEB 21, 1998) THEN -
ENDJOB
In the above example, if today is February 21
st
, 1998, ESP submits PAYJOB5 from
CYBER.ALTJCL.CNTL.
APPL PAYROLL
JOB PAYJOB6
RUN DAILY
IF DAYS_FROM(FEB 1,1998) GE 0 AND -
DAYS_TO(FEB 22,1998) GE 0 THEN -
ENDJOB
In the above example, ESP submits PAYJOB6 from CYBER.ALTJCL.CNTL, from
February 1
st
, 1998 up to and including, February 22
nd
, 1998.
135
DATEFORM Command
Overview The DATEFORM command is used to set the date format used in schedule
statements.
Authority OPER authority is required to issue the DATEFORM command.
Syntax The syntax of the DATEFORM command is:
DATEFORM [YMD|MDY|DMY]
YMD Sets the date format to YY/MM/DD. This is the default.
MDY Sets the date format to MM/DD/YY.
DMY Sets the date format to DD/MM/YY.
Usage notes ESP recognizes the date format xx/xx/xx. The DATEFORM command instructs ESP
how to interpret this format. Only one of the date formats is valid at your
installation. This is normally specified in the ESP Initialization Parameters.
The DATEFORM command only affects dates in the format xx/xx/xx. You can still
use terms like May 24, 1997 and 24MAY97 regardless of this setting.
Related
information
For information on setting the date format used in schedule statements, see the
DATEFORM Initialization Parameter in the ESP Workload Manager Installation
Guide.
For information on setting the date format used to customize the format of date
fields when using ESPs history reporting facility, see the ESP Workload Manager
Users Guide.
Example 1 The following DATEFORM example displays the current date:
DATEFORM
In the above example, the current date format setting is displayed.
136
DATEFORM Command, Continued
Example 2 The following DATEFORM command sets the date format:
DATEFORM MDY
In the above example, a schedule statement 05/24/97 is interpreted as May 24, 1997.
137
DATEFORM Reporting Command
Overview The DATEFORM reporting command is used to customize the format of date fields
displayed in an ESP history report.
Syntax The syntax of the DATEFORM command is:
DATEFORM [YMD|MDY|DMY|JULIAN|YM]
YMD Sets the date format to DAYYYYYMMDD.
MON19980524
MDY Sets the date format to DAYMMDDYY.
MON052498
DMY Sets the date format to DAYDDMMMYY. This is the default.
MON24MAY98
JULIAN Sets the date format to DAYDDDYY.
MON14498
YM Sets the date format to DAYYYYYMM.
MON199805
Usage notes The DATEFORM command, used to set the date format used in schedule
statements, and the DATEFORM reporting command used to control the formatting
of dates in history reports, are completely different in their context; they are two
separate commands.
Related
information
For information on setting the date format used in schedule statements, see the
DATEFORM command.
138
DATEFORM Reporting Command, Continued
Example 1 The following DATEFORM command formats the dates used in a history report:
REPORT
HISTFILE HIST1
FROM 8AM YESTERDAY
DATEFORM JULIAN
DISPLAY JOBNAME JOBNO CMPC EXECSDATE ENDDATE
ENDR
In the above example, all jobs in the PAYROLL Application are displayed using a
Julian date format as follows:
JOBNAME JOB COMP START END
NO CODE DATE DATE
PAYJOB1 1234 0 MON16497 MON16497
PAYJOB2 1235 0 MON16497 MON16497
PAYJOB3 1236 S0C1 MON16497 MON16497
PAYJOB3 1378 0 TUE16597 TUE16597
139
DEFAT Command
Overview The DEFAT command is used to define or alter an authorization table, limiting
access to tracked job data. An authorization table provides a way to control access
to job tracking data. This command only applies if you are using ESPs internal
security.
Authority SPECIAL authority is required to issue the DEFAT command.
Syntax The syntax of the DEFAT command is:
DEFAT tabname
INCLUDE(jobname,authstring[,jobname,authstring]...)
[EXCLUDE(jobname,authstring[,jobname,authstring]...)
[ADD|REPLACE]
tabname Indicates the name of the authorization table in up to eight
jobname Indicates a jobname, in up to eight characters, which you use
as the first half of a jobname/authstring pair. The jobname
can contain asterisks or a hyphen for masking.
authstring Indicates a string of up to eight characters, which must match
one of the fields identified with a job. The fields are defined
in the AUTHSTR Initialization Parameter. The authstring
can contain asterisks or a hyphen for masking. It forms the
second half of the jobname/authstring pair.
ADD Indicates this is a new authorization table definition. The
definition fails if a definition with the same name already
exists. This is the default.
REPLACE Indicates an authorization table is being replaced. This
parameter is necessary if an authorization table with the same
name exists, and you want to change it.
140
DEFAT Command, Continued
Usage notes The authorization string may be any of the account number fields or a security user
ID, as decided by the installation. To access job-tracking information, the name of
the tracked job and the account number or user ID related to the job must have an
exact match in the authorization table assigned to the user requesting the tracking
data.
A user is associated with an authorization table via the DEFUSER command.
The INCLUDE section of the authorization table gives specific control over tracked
job information. It does this by listing jobname/authstring pairs (any number can be
specified in one DEFAT command). The user to whom an authorization table is
assigned can access any of the jobs listed in the INCLUDE section of the table,
provided the name and authstring of the job matches a jobname/authstring pair in the
table.
The EXCLUDE feature is useful when the INCLUDE section specifies a generic
group of jobs by the use of asterisks or a hyphen. Specific jobs within such a group
can be excluded with the EXCLUDE parameter.
If you want to edit or change the authorization table, use the DEFAT command with
the REPLACE parameter.
Related
information
For information on defining or altering authorization tables, see ESP Workload
Manager Administrators Guide.
For information on associating an authorization table with a user, see the DEFUSER
command.
For information on specifying one of jobs related fields used to identify the
ownership of a job, see the ESP Workload Manager Installation Reference Guide.
Example 1 The following DEFAT command defines an authorization table:
DEFAT AUTHTAB1 INCLUDE(JOB1,PROD,JOB2,PROD)
In the above example, the first jobname is JOB1, and the authorization string that
makes up the pair is PROD. PROD represent the user ID for the job and the
AUTHSTR Initialization Parameter has been set to RACUSER. JOB2 is paired with
the same authstring. JOB1 and JOB2 using account PROD are, therefore, accessible
to users who have the authorization table AUTHTAB1 assigned to them.
141
DEFAT Command, Continued
DEFAT AUTHTAB2 INCLUDE(ABC-,AC0-,XYZ-,AC0-) EXCLUDE(-,AC02)
In the above example, the authorization string is the first account number as defined
by the AUTHSTR Initialization Parameter. Any jobname beginning with the three
characters ABC or XYZ, with an account number that begins with AC0, excluding
AC02.
DEFAT AUTHTAB3 INCLUDE(JOB1,AC02,JOB2,ACO2)
The following table shows whether a user whose authorization table is AUTHTAB3
is allowed access to various jobname/account combinations.
Jobname Account Access
JOB1 AC02 ALLOWED
JOB2 AC02 ALLOWED
JOB1 ACO2A DISALLOWED
142
DEFAULT Command
Overview The DEFAULT command is used to define default values for use on job card JCL
submitted by ESP. This command can be used only if you are using ESPs internal
security.
Syntax The syntax of the DEFAULT command is:
{DEFAULT|DEFLT} {[USER{(userid|NONE)}]}
{[GROUP{(racfgroupid|(NONE)}]}
{[PASSWORD{(password)|(NONE)}]}
userid Indicates the user ID you want ESP to place as an operand of
the USER keyword on the job card for JCL submitted by
ESP.
racfgroupid Indicates the group name you want ESP to place as an
operand of the GROUP keyword on the job card for JCL
submitted by ESP.
password Indicates the password you want ESP to place as an operand
of the PASSWORD keyword on the job card for JCL
submitted by ESP.
NONE Use this if you want to nullify a previous setting. The
corresponding operand on the job card is left unmodified.
Usage notes The DEFAULT command is not commonly used as the use of USER and
PASSWORD on job cards is not very common.
The DEFAULT command provides the ability to set defaults for jobs submitted by
ESP. If any of these parameters is already specified on a job card, it is not
overridden.
Related
information
For information on the user ID used for job submission, see the ESP Workload
143
DEFAULT Command, Continued
Example 1 The following DEFAULT command defines default values for job cards of jobs
submitted by ESP:
DEFAULT USER(RACUSER1) GROUP(PAYROLL) PASSWORD(MYSECRET)
In the above example, the default user ID is RACUSER1, the default group is
PAYROLL, and the default password is MYSECRET, on the job card for submitted
JCL.
144
DEFCAL Command
Overview The DEFCAL command is used to define an ESP calendar. Use calendars to define
scheduling terms that satisfy specific processing situations.
Authority SPECIAL or CALENDARDEF authority is required in a non-SAF environment to
issue the DEFCAL command. With SAF, you control access to calendars using the
CALENDAR.calname resource.
Syntax The syntax of the DEFCAL command is:
{DEFCAL|DEFC} calname
[OWNER(string)]
[LOGICAL|ABSOLUTE]
[SHIFT(hh:mm)]
[WEEKSTART(day)]
[WORKDAYS(workday[,workday]...)]
calname Indicates the name of the calendar. Can be up to eight
alphanumeric or national characters ($, #, @). The first
character must be alphabetic.
string Indicates a user/group in up to eight characters. It may
contain asterisks and may also have a hyphen in the last
character position. This controls who can alter or delete the
calendar. It doesnt control who can define holidays and
special days for the calendar. This applies only if you are
using ESPs internal security.
which this calendar belongs. It may contain asterisks and
may also have a hyphen in the last character position. This
applies only if you are using ESPs internal security.
LOGICAL/
ABSOLUTE
Indicates a logical calendar or an absolute calendar. The
default is ABSOLUTE (i.e. days begin at midnight).
Note: Absolute calendars are recommended.
hh:mm Indicates the start time of a logical day. If specified, your
logical day is shifted forward by the specified time.
day Indicates the first day of the week. This overrides the default
specified in the ESP Initialization Parameters.
workday Indicates which days are to be considered workdays.
Separate each with a comma. This overrides the default
specified in the ESP Initialization Parameters.
145
DEFCAL Command, Continued
Usage notes When ESP is installed, a calendar called SYSTEM is defined. All Events have read
access to the SYSTEM calendar.
Note: The SYSTEM calendar should contain only those scheduling entries that all
ESP users need.
Once a calendar is defined, users that have access can define holidays, special days
and special period entries to be placed in it.
You can also define a calendar using ESPs ISPF interface - Option M from the ESP
Main Menu.
Related
information
For information on defining calendars, see the ESP Workload Manager
For information on using special calendars in an Event, see the ESP Workload
For information on using calendars, see the ESP Workload Manager Users Guide.
For information on defining and deleting holidays, see the DEFHOL and DELHOL
commands.
For information on defining and deleting special days, see the DEFSPEC and
DELSPEC commands.
For information on altering the attributes of a calendar, see the ALTCAL command.
For information on displaying information about calendars, see the LISTCAL
command.
For information on assigning default calendars to users in a SAF environment, see
the ESP Workload Manager Administrators Guide.
For information on assigning default calendars to users in a non-SAF environment,
see the DEFUSER and DEFGROUP commands.
Example 1 The following DEFCAL command defines the system calendar:
DEFCAL SYSTEM
In the above example, the system calendar is defined. The first day of the week, and
the workdays are determined by the ESP Initialization Parameters.
Example 2 The following DEFCAL command defines a calendar:
DEFCAL CAL1 OWNER(CYBER) WEEKSTART(SUN) -
WORKDAYS(MON,TUE,WED,THU,FRI)
In the above example, CAL1 is defined. The first day of the week is Sunday and
workdays are Monday through Friday, inclusive.
146
DEFCAL Command, Continued
Example 3 The following is an example of defining a calendar using ESPs ISPF interface:
ESP -------------------------- DEFINE A CALENDAR ------------------------- ESP
COMMAND ===>
NAME OF CALENDAR ===> FISCAL
OWNER ===>
DEPARTMENT ===>
LOGICAL DAY START ===> (Hours and Minutes, e.g. 08:01)
DEFAULT ===> (Enter L for logical, A for absolute)
WORKDAYS: SUNDAY ===> (Enter Y against each day that is
MONDAY ===> Y to be eligible as a workday. Leave all
TUESDAY ===> Y blank to pick up installation default)
WEDNESDAY ===> Y
THURSDAY ===> Y
FRIDAY ===> Y
SATURDAY ===>
FIRST DAY OF WEEK ===> MON (SUN, MON etc. Blank for installation default)
ANY MORE? ===> (Enter Y to define more calendars)
In the above example, a calendar called FISCAL is defined. The first day of the
week is Monday and workdays are Monday through Friday, inclusive.
147
DEFGROUP Command
Overview The DEFGROUP command is used to define a group to ESP. Defining a group and
connecting users to it allows you to manage and control access to and use of ESP at
a group level. This command only applies if you are using ESPs internal security.
Authority SPECIAL or GROUPDEF authority is required to issue the DEFGROUP command.
Syntax The syntax of the DEFGROUP command is:
{DEFGROUP|DEFG} groupname
EVENT(eventdsid)
[AUTH(OPER)]
[UREAD]
[RACID]
groupname Indicates a one to eight character group name.
eventdsid Indicates in up to eight characters the logical identifier of the
Event database used to store Events prefixed with the group
name defined.
which this group belongs. It may contain asterisks and may
OPER Indicates Events having this group name as a prefix can
contain operator commands.
UREAD Indicates universal read access is available for any Event
defined using this group prefix.
RACID Indicates the group name should be used for security
attributes when ESP processes an Event rather than the ID of
the defining user.
cal1 Indicates the name of the first default calendar for Events that
start with the group prefix, up to eight characters.
cal2 Indicates the name of the second default calendar, up to eight
characters.
148
DEFGROUP Command, Continued
Usage notes The default calendars are used by Events that have no explicit calendar
specification. They are searched in the order specified. All Events automatically
have access to the SYSTEM calendar, which is searched after the default calendars.
A user with an authority attribute of ANY has access to any Group. Such a user does
not need to be connected to any Group.
ESP controls access to Events by the high level prefix under which the Event is
stored. If a user saves an Event using an ESP user ID as the high level prefix, only
that user and users with ANY authority can access the Event. When any member
of a group saves an Event using the ESP group name as the high level prefix, any
member of that group and users with ANY authority have access to the Event.
You can also define and list a group using ESPs ISPF interface - Option M from the
ESP Main Menu.
Related
information
Guide.
For information on defining and deleting users, see the DEFUSER/DELUSER
commands.
For information on deleting groups, see the DELGROUP command.
For information on displaying information about a group, see the LISTGRP
command.
For information on altering a group definition, see the ALTGROUP command.
For information on connecting and disconnecting users to and from groups, see the
CONNECT and DISCONN commands.
Example 1 The following DEFGROUP command defines an ESP group and assigns an Event
data set:
DEFGROUP PROD EVENTSET(EVENT1) RACID
In the above example, a group called PROD is defined and Event data set EVENT1
is assigned to the group. Events are processed under the groupname.
Example 2 The following DEFGROUP command defines an ESP group, assigns an Event data
set and a default calendar:
DEFGROUP PAYGRP EVENTSET(EVENT2) CALENDAR(FISCAL)
In the above example, a group called PAYGRP is defined and Event data set
EVENT2 is assigned to the group. PAYGRPs default calendar is FISCAL.
149
DEFGROUP Command, Continued
Example 3 The following DEFGROUP command assigns a department to a group:
DEFGROUP SCHED EVENTSET(EVENT1) DEPARTMENT(PRODSUPP)
AUTH(OPER)
In the above example, SCHED is defined as part of the PRODSUPP department.
SCHED has the authority to issue ESP operator commands.
150
DEFHOL Command
Overview The DEFHOL command is used to define a holiday.
Authority You can define holidays only in the calendar defined as your first default calendar,
or in calendars to which you have access. If you do not have any default calendars
defined, the holiday is automatically stored in the SYSTEM calendar.
Syntax The syntax of the DEFHOL command is:
{DEFHOL|DEFH} holidayname
START(starttime)
END(endtime)|FOR(duration)
[RETAIN{(2,days)|(x,units)}]
[CALENDAR(calname)]
holidayname Indicates the name of a holiday. Can be up to 16
alphanumeric or national characters ($, #, @). The underscore
character can also be used.
starttime Indicates the starting time and date of the holiday. If the date
specification contains separators, it should be enclosed in
quotes. You have the option to specify UNTIL followed by a
time and date specification, which tells ESP when the holiday
ends. If you use UNTIL, you must enclose the entire
specification in quotes.
endtime Indicates the time and date the holiday ends. It is mutually
exclusive with the FOR parameter, and with UNTIL or
ENDING in the START parameter. Specifying a
combination of these terms produces unpredictable results.
duration Indicates the length of the holiday in hours.
x,units Indicates the number of days, weeks or years after each
occurrence of the holiday that you want to remain on the
system for reference. The default is two days. If you specify
a number but no units, this value automatically defaults to
days. This determines how long you can refer back to a
holiday after it occurs.
calname Indicates the name of the calendar in which the holiday is to
be defined, otherwise user ID defaults are used.
151
DEFHOL Command, Continued
Usage notes The time duration for a holiday is 24 hours, unless you specify otherwise. You can
define multiple holidays with the same name, but you must define each one
separately. As an alternative to defining two back-to-back 24 hour holidays
individually, you can define one holiday with a duration of 48 hours.
In an Event definition, you can schedule based on holidays or use an ON command
such as on holiday. This allows you to bypass, delay or advance the schedule if it
normally falls on a holiday or a particular day of the week.
You can also define and list a holiday using ESPs ISPF interface - Option L from
the ESP Main Menu.
ESP deletes a holiday after its retain count expires. It does this whenever an update
is made to the calendar containing the holiday.
For logical day processing, holidays should be defined in ABSOLUTE terms even if
stored in a LOGICAL calendar.
Related
information
For information on specifying holiday names in schedule criteria, see the ESP
For information on deleting holidays, see the DELHOL command.
For information on defining and deleting special days and periods, see the
DEFSPEC and DELSPEC commands.
For information on displaying holiday information, see the LISTHOL command.
For information on advancing, delaying, or ignoring Event processing, see the ON
command.
For information on displaying information about a calendar, see the LISTCAL
command.
Example 1 The following DEFHOL commands define a holiday for three years:
DEFHOL CHRISTMAS START(25 DECEMBER 1998) FOR(24)
In the above example, multiple holidays with the same name - CHRISTMAS are
defined as 24 hour holidays in three successive years.
152
DEFHOL Command, Continued
Example 2 The following DEFHOL command defines a holiday with a specific start and end
using UNTIL with the START keyword to define the end time for a holiday. Note
the use of quotes:
DEFHOL NEW_YEARS START(31ST DEC UNTIL 2ND JAN)
In the above example, NEW_YEARS is defined to start on December 31
st
until
January 2
nd
at 00:00.
Example 3 The following DEFHOL command defines a holiday in a specific calendar:
DEFHOL DAYOFF START(4PM JAN 5, 1998) -
END(4PM JAN 6, 1998) RETAIN(6,MONTHS) CALENDAR(MYCAL)
In the above example, DAYOFF is defined to start on January 5
th
, 1998 at 4 pm
ending January 6
th
, 1998 at 4 pm. The definition of DAYOFF resides on MYCAL
for 6 months after it occurs.
Note You should not need to use logical calendars. Logical calendars can cause
unanticipated results. Cybermation recommends you use absolute calendars because
of their ease of use, and because they can handle almost all scheduling requirements.
153
DEFPN Command
Overview The DEFPN command is used to define a processing node (P-Node) to ESP, and
which users or consoles are allowed to perform a POST to it. ESP tracks jobs
through some P-Nodes automatically. After a job passes through the output phase,
you can identify additional (manual) P-Nodes for the job. These processing phases
may include bursting of output, distribution and so on.
Authority SCHEDULER authority is required in a non-SAF environment to issue the DEFPN
command. With SAF, you control the ability to use P-Nodes using the
PNODE.pnodename resource.
Syntax The syntax of the DEFPN command is:
DEFPN name
[USERS(id[,id]...)]
[ADD|REPLACE]
[SEQUENCE(seqno)]
[OWNER(ownerid)]
name Indicates the name of the P-Node, in up to 16 characters.
id Indicates the ID(s) of the users or system consoles that can
post a job out of this P-Node. The ID strings can contain
asterisks or a hyphen for masking. Console Ids are in the
form SYSCONnn, where nn is the console UCMID. This
ADD Indicates this is a new definition. The request fails if a
definition with the same name already exists. ADD is the
default.
REPLACE Replaces a current P-Node definition of same name.
seqno Indicates the relative sequence number used when displaying
queues. When a DQ or DN command is used, the P-Node
queues are displayed according to their sequence numbers.
The sequence numbers can be in the range 0 to 255.
ownerid Specifies the name of the user(s) who can alter or delete this
P-Node definition. The owner ID can contain asterisks or a
hyphen for masking. This applies only if you are using ESPs
internal security.
154
DEFPN Command, Continued
Usage notes At installation time, the INPUT, EXEC and OUTPUT P-Nodes are defined. ESP
tracks jobs through these P-Nodes automatically.
A job does not need to complete a manual P-Node for a successor job to run. If you
need to set up job dependencies with a manual phase of a job, consider using tasks
in an ESP Application.
Once you have defined the P-Node name, authorized users can type the POST
command to post a job as having completed processing at a specific P-Node.
Related
information
For information on defining processing nodes (P-Nodes), see the ESP Workload
For information on deleting manual P-Nodes, see the DELPN command.
For information on displaying P-Node information, see the LISTPN command.
For information on posting a job complete from a manual P-Node, see the POST
command.
For information on specifying the name of a P-Node through which a job has to pass
before it can be marked complete, see the PNODES statement.
Example 1 The following DEFPN commands define automatic P-Nodes that ESP uses to track
jobs:
DEFPN INPUT
DEFPN EXEC
DEFPN OUTPUT
In the above example, P-Nodes that ESP uses to track jobs are defined. ESP
automatically assigns sequence numbers.
Example 2 The following DEFPN command defines a P-Node and identifies which users can
post a job from which consoles:
DEFPN BURSTER USERS(SYSCON02,SYSCON01,PROD-) SEQ(150) -
OWNER(SCH-)
In the above example, BURSTER is defined. System consoles 1 and 2 and users
with IDs beginning with PROD can post a job from this P-Node. When the queue is
displayed, the relative sequence number for this P-Node is 150. Only users with IDs
beginning with SCH can alter or delete this entry.
155
DEFPN Command, Continued
Example 3 The following DEFPN command defines or replaces a P-Node to represent the
distribution of output:
DEFPN DISTRIB USERS(SYSCON03,SCH-) REPLACE
In the above example, ESP user beginning with SCH can issue the POST command
from system console 03.
Once a P-Node is defined (above), you can use that P-Node as a job requirement as
follows:
JOB PAYJOB1
PNODES DISTRIB
RUN DAILY
ENDJOB
To post PAYJOB1 complete from the DISTRIB P-Node, authorized users can issue
the following POST command:
POST PAYJOB1 PNODE(DISTRIB)
156
DEFPRINT Command - DATASET Option
Overview The DEFPRINT command defines a logical report name to which output is directed.
It defines the characteristics of an auxiliary output device and associates the logical
report name to it. Output can be directed to a sysout class, data set, or DD file.
Syntax The syntax of the DEFPRINT data set option command is:
DEFPRINT repname
DATASET(dsname)
[VOLUME(serial)]
[UNIT(unitname)]
[SPACE(primary,[secondary])TRACKS|BLOCKS|CYLINDERS]
[EXTEND]
[LRECL(length)]
[RECFM{(V)|(F)}]
[PAGELENGTH(lines)]
[BLOCK(size)]
[BLKSIZE(block)]
repname Indicates a one to eight character alphanumeric logical report
name.
dsname Identifies the data set name to which the output is diverted.
You should include a member name if you are diverting
output to a PDS.
serial Identifies the volume serial number (up to six characters) for
the data set if you are specifying a new data set, or if you are
using an existing data set that is not catalogued.
unitname Indicates the name of the output device type, using up to eight
characters.
primary Indicates the primary allocation you want to assign, in
parentheses. You must specify after this whether you are
allocating CYLINDERS, TRACKS or BLOCKS.
secondary Indicates the secondary allocation you want to assign, in
parentheses. If you use this parameter, you must use the
appropriate keyword to specify whether you allocate
CYLINDERS, TRACKS or BLOCKS. If you are specifying
primary and secondary allocation, specify one of these
keywords after the secondary allocation specified. Do not use
parentheses.
EXTEND Indicates the output should be added to the end of the data
set. If you do not specify EXTEND, the data set is
overwritten.
157
DEFPRINT Command - DATASET Option, Continued
Syntax (continued)
length Indicates the logical record length for each line of output.
Specify the number of characters you want in each line.
V Indicates variable length records. This is the default. The
line length is four bytes less than what you specified under
LRECL.
F Indicates fixed length records.
lines Indicates the number of lines on each page, including titles
and footings.
size Indicates the size in bytes of a block allocation unit.
block Indicates the actual length of blocks on a data set. The limit
is 32767 bytes.
Usage notes You must use the ENDPRINT command to close each data file you opened with
DEFPRINT.
Related
information
For information on ending a report print definition, see the ENDPRINT command.
For information on directing output to a file, see the DEFPRINT command - File
Option.
For information on directing output to a sysout class, see the DEFPRINT command -
SYSOUT Option.
For information on requesting that a data type printout be directed to a data set,
sysout class or DD file from Page mode, see the HARDCOPY command.
For information on setting the default output environment for TITLE processing, see
the SETPRINT command.
For information on defining a title to be displayed at the top of the next and
subsequent pages of printed data, see the TITLE command.
Example 1 The following DEFPRINT command defines a logical report name:
DEFPRINT CYBRPT1 DATASET(ESP.MODEL.REPORT1)
In the above example, CYBRPT1 is associated with a preallocated data set. Output
is directed to ESP.MODEL.REPORT1.
158
DEFPRINT Command - DATASET Option, Continued
Example 2 The following DEFPRINT command dynamically allocates a data set:
DEFPRINT CYBRPT2 DATASET(ESP.MODEL.REPORT2) -
SPACE(2,1) TRACKS VOLUME(CYB001) -
LRECL(150) RECFM(FBA) BLKSIZE(15000)
In the above example, ESP.MODEL.REPORT2 is dynamically allocated and
assigned a logical identifier of CYBRPT2. Output is directed to
ESP.MODEL.REPORT2.
159
DEFPRINT Command - FILE Option
Syntax The syntax of the DEFPRINT command is:
DEFPRINT repname
DDNAME(file)
[EXTEND]
[LRECL(length)]
[RECFM{(V)|(F)}]
[PAGELENGTH(lines)]
[BLOCK(size)]
[BLKSIZE(block)]
repname Indicates a one to eight character alphanumeric logical report
name.
file Indicates the data set name to which the output is diverted.
You should include a member name if you are diverting
output to a PDS.
serial Indicates the volume serial number (up to six characters) for
the data set if you are specifying a new data set, or if you are
using an existing data set that is not catalogued.
characters.
parentheses. You must specify after this whether you are
allocating CYLINDERS, TRACKS or BLOCKS.
parentheses. If you use this parameter, you must use the
appropriate keyword to specify whether you allocate
parentheses.
overwritten.
V Indicates variable length records. This is the default. The line
length is four bytes less than what you specified under
LRECL.
160
DEFPRINT Command - FILE Option, Continued
Syntax (continued)
and footings.
is 32767 bytes.
DEFPRINT.
Related
information
For information on directing output to a data set, see the DEFPRINT command -
DATASET Option.
For information on directing output to a sysout class, see the DEFPRINT command -
SYSOUT Option.
DEFPRINT JR1RPT DDNAME(RPTDD1) LRECL(133) RECFM(F)
In the above example, output for report JR1RPT is routed to a file. The logical
record length for each line of output written to RPTDD1 should be 133, in fixed
length records.
161
DEFPRINT Command - SYSOUT Option
Syntax The syntax of the DEFPRINT command is:
DEFPRINT repname
SYSOUT(class)
[DEST(destcode)]
[COPIES(n)]
[FORM(type)]
[LRECL(length)]
[RECFM{(V)|(F)}]
[PAGELENGTH(lines)]
[UCS(char)]
[SPIN]
repname Indicates a one to eight alphanumeric logical report name.
class Indicates a one-character class number.
destcode Indicates a destination code of up to eight characters. If you
do not specify DEST, the destination defaults to LOCAL.
n Indicates the number of copies you want printed. The
maximum is 240 copies.
type Indicates the type of form you want to use for printing, using
up to four characters.
line length is four bytes less than what you have specified
under LRECL.
and footings.
char Indicates the universal character set type you want to be used
on the printer for this printout.
SPIN Indicates the data should be made available for printing as
soon as you enter the ENDPRINT command.
DEFPRINT.
162
DEFPRINT Command - SYSOUT Option, Continued
Related
information
For information on directing output to a file, see the DEFPRINT command - File
Option.
For information on directing output to a data set, see the DEFPRINT command -
DATASET Option.
DEFPRINT DEPT123 SYSOUT(J)
In the above example, output for report DEPT123 is directed to a sysout class of J.
163
DEFPRIO Command
Overview The DEFPRIO command is used to assign a default priority to all jobs with no
priority specified in their JCL for the purposes of modeling. Priorities can range
from 1 to 15, with 15 being the highest.
Type MODEL command.
Syntax The syntax of the DEFPRIO command is:
DEFPRIO nn
nn Indicates a default priority in the range 1-15. The highest
priority is 15. If not specified, the default is 3.
Usage notes Use the DEFPRIO command to assign a default selection priority to all jobs without
one. This is normally the default job priority defined on your system.
Within a job class, the model processor selects jobs for execution in order of
priority. A job with a higher priority is selected for execution sooner; jobs with the
same priority are selected on a first-in first-out basis.
This command only applies to modeling. It does not affect actual job execution.
Related
information
For information on ESPs modeling feature, see Advanced Forecasting in the ESP
Example 1 The following DEFPRIO command sets a default priority:
DEFPRIO 12
In the above example, a default priority of 12 is set for all jobs whose JCL does not
already contain a priority statement.
164
DEFSIG Command
Overview The DEFSIG command is used to define a signal. A signal can represent a manual
task, such as the arrival of a tape, or an automated task, such as the successful
completion of a job. Signals are commonly used with DJC/JES3 networks, which do
not offer the flexibility of Applications.
Syntax The syntax of the DEFSIG command is:
DEFSIG signalname
[GEN(genno)]
signalname Indicates the name of the signal. A signal has a two-part
name consisting of a prefix which is a group name (or user
ID), followed by a description of up to 16 characters. If
prefix is not specified, the current group prefix is used.
genno Indicates the number of generations of a signal to be stored.
The default, if not specified, is 1.
Usage notes Signals cause an ESP Event to wait for a condition in addition to its schedule criteria
before it executes. A signal may represent a manual task, such as the arrival of an
input tape, or an automated task, such as the completion of a job.
Signals are available only at the Event level. If you are using an Application and
need to set up conditions at the job level for jobs in the Application, the best method
is through tasks.
Related
information
For information on signal processing, see the ESP Workload Manager Advanced
Users Guide.
For information on cycling a signal, see the SIGCYCLE command.
For information on posting a generation of a signal, see the SIGPOST command.
For information on identifying that signal must be marked complete before
execution of the Event, see the SIGWAIT command.
For information on altering the numbers of generations of a signal, see the ALTSIG
command.
For information on displaying all generation of a signal, see the LISTSIG command.
For information on setting up job level conditions in Applications, see the ESP
165
DEFSIG Command, Continued
Example 1 The following DEFSIG command defines a signal:
DEFSIG CYBER.DAILY_SIGNAL1 GEN(7)
In the above example, CYBER.DAILY_SIGNAL1 is defined with 7 generations to
be stored.
Example 2 The following DEFSIG command defines a signal:
DEFSIG SIGNAL2 GEN(5)
In the above example, SIGNAL2 is defined using the current group/user prefix with
five generations to be stored. If the current group prefix is TX5312, the signal name
is TX5312.SIGNAL2.
166
DEFSPEC Command
Overview The DEFSPEC command is used to define a special day or period.
Authority You can only define special days in the calendar defined as your first default
calendar, or in calendars to which you have access. If you do not have any default
calendars defined, the special day is stored automatically in the SYSTEM calendar.
Syntax The syntax of the DEFSPEC command is:
DEFSPEC specname
ON(date)|REPEAT(schedule)
[CALENDAR(calname)]
[USING(cal1[,cal2]...)]
[RETAIN(x,units)]
specname Indicates a name for the special day you are defining, using
up to 16 characters. The name may include the underscore,
numerics, and national characters. Blanks are not allowed.
date Indicates the date and time on which the special day occurs,
or specifies the beginning date and time of a single special
period. You must specify at least two special periods of the
same name so that ESP knows when the first period ends. If
the date specification contains separators, it must be enclosed
in quotes. ON is mutually exclusive with the REPEAT
parameter.
schedule Use this parameter when specifying multiple special days or
regular periods with the same name. It allows you to specify
more occurrences of an existing special day or period
definition without having to completely redefine them.
Specify a valid schedule criteria, that defines when the
special day or period should repeat itself (such as every 15th
workday at 9 am, 6 times, until 15th June). If you use
separators, enclose the statement in quotes. REPEAT is
mutually exclusive with the ON parameter.
calname Indicates the calendar in which the special day or period is to
be defined. This is the TARGET calendar on the ISPF panel.
cal1, cal2 Indicates up to two calendar names. The USING parameter is
used if you refer to a special day or period in the REPEAT
parameter. The calendars you specify with USING tell ESP
where to find the special day or period definitions to which
you are referring. This is the SOURCE calendar on the ISPF
panel.
167
DEFSPEC Command, Continued
Syntax (continued)
x, units Indicates the number of days, weeks or years after each
occurrence of the special day or period that you want it to
remain on the system for reference. The default is two days.
If you specify a number but no units, this value automatically
defaults to days.
Usage notes If you define 2 special days with the same name, ESP treats the time between them
as a special period.
You cannot use ON and REPEAT together. You must, however, use one of these
two options after specifying the required special day/period name.
If you use the REPEAT parameter without using the n TIMES parameter, and
without specifying either an UNTIL or ENDING date, ESP uses one year as a
default. You can only use the n TIMES parameter if you use REPEAT.
Use the RETAIN parameter to ensure that a special day definition remains on the
system for more than the default of two days after the special day (or first day of a
special period) has passed. For example, you probably want to ensure that any fiscal
month definition remains on the system for at least one year, so you can refer to the
9TH FISCAL_MONTH OF FISCAL_YEAR. Specify RETAIN(1,YEAR) or
RETAIN(365) (if units are omitted, this defaults to days). If all payroll days need
to be referred to for at least six months after they pass, you would specify:
RETAIN(6,MONTHS). ESP deletes a special day after the retain count expires. It
does this whenever an update is made to the calendar containing the special day.
You can also define and list special days and periods using ESPs ISPF interface -
Option L from the ESP main menu.
Related
information
For information on specifying special days or periods in schedule criteria, see the
ESP Workload Manager Users Guide.
For information on deleting special days or periods, see the DELSPEC command.
commands.
For information on displaying special day and period information, see the
LISTSPEC command.
For information on displaying information about a calendar, see the LISTCAL
command.
168
DEFSPEC Command, Continued
Example 1 The following DEFSPEC command defines a special day:
DEFSPEC YEAR_END ON(LAST WORKDAY OF AUG) USING(CAL1) -
CALENDAR(CAL2)
In the above example, YEAR_END is defined as the last workday of August of the
current year, in the CAL2 calendar. CAL1 is used as a reference for workdays.
Example 2 The following DEFSPEC command defines multiple special days:
DEFSPEC PAYROLL_DAY -
REPEAT(THU EVERY 2 WEEKS UNTIL JAN3,1998) -
RETAIN(365)
In the above example, PAYROLL_DAY is defined and occurs every two weeks on
Thursdays. The special day definition is to remain on the system for one year.
Example 3 The following DEFSPEC command defines multiple special periods:
DEFSPEC SESSION REPEAT(39 TIMES EVERY 4 WEEKS STARTING -
1ST JAN) RETAIN(1 YEAR)
In the above example, 39 special periods called SESSION, which occur regularly,
are defined every four weeks starting on 1st January. The special period definition is
to remain on the system for 1 year.
Example 4 The following DEFSPEC command defines multiple special days:
DEFSPEC FISCAL_YEAR REPEAT (1MAY YEARLY UNTIL 30APR2001) -
CAL(ACCT1) RETAIN(2 YEARS)
In the above example, fiscal years starting May 1
st
are defined up to the year 2001 in
the calendar ACCT1. Each fiscal year is retained on the system for two calendar
years.
169
DEFSYML Command
Overview The DEFSYML command is used to define or alter a symbol library. This allows
ESP to reference a collection of data sets using a logical identifier.
Authority SPECIAL, SCHEDULER or CALENDARDEF authority is required to issue the
DEFSYML command in non-SAF environments. With SAF, you control access to
symbol libraries using the SYMLIB.symname resource.
Syntax The syntax of the DEFSYML command is:
DEFSYML name
[DATASET(dsn[,dsn]...)]
[USERS(user[,user]...)]
[ADD|REPLACE]
name Indicates the name of the symbol library. It can consist of up
to eight alphanumeric characters, the first of which must be
alphabetic.
dsn Indicates one or more data sets to be scanned when the
symbol library set is referenced by an Event. The names
should be the valid names of data sets. If a data set is a PDS,
then each member containing symbols must be specified.
Separate each with a blank or comma.
user Indicates one or more user or group prefixes or masks, to
restrict access to the symbol library sets. Asterisks and a
hyphen can be used for generic masks. If no user IDs are
specified, access to the symbol library set is not restricted.
This applies only if you are not using SAF.
ADD Indicates this is a new definition, and is not to replace an
existing entry, if there is one. This is the default.
REPLACE Indicates this definition replaces an existing one.
170
DEFSYML Command, Continued
Usage notes To use a symbol library, use the SYMLIB command in an Event definition.
Users can define their own variables and use builtin symbolic variables in JCL,
command input, and in job definitions. A user can define and work with symbolic
variables in either a symbolic variable library or an ESP Procedure.
When symbolic variable libraries are used to store user defined symbolic variables,
the ability to use ESPs IF-THEN-ELSE language construct is lost.
If you want to use IF-THEN-ELSE type statements in combination with user defined
symbolic variables, you need to store those definitions in a member of a PDS and
invoke that member from your Event or ESP Procedure.
If you need to alter a symbol library definition, use the DEFSYML command with
the replace option.
Related
information
For information on setting symbol libraries, see the ESP Workload Manager Users
Guide.
For information on invoking user symbolic variables, see the ESP Workload
For information on displaying information on symbol libraries, see the LISTSYML
command.
For information on deleting a symbol library, see the DELSYML command.
For information on requesting the inclusion of one or more symbolic variable
libraries, see the SYMLIB command.
Example 1 The following DEFSYML command defines a symbolic variable library:
DEFSYML SYMSET1 DA(ESP.SYMLIB(DATEPARM))
In the above example, SYMSET1 is defined and consists of the member
DATEPARM of the ESP.SYMLIB data set.
Example 2 The following DEFSYML command defines a symbolic variable library:
DEFSYML SYMSET2 DA(CYBER.PAYROLL.SYMBOLS, -
CYBER.COMMON.SYMBOLS(DATE))
In the above example, SYMSET2 is defined and consists of the sequential data set
CYBER.PAYROLL.SYMBOLS and the member DATE of the PDS
CYBER.COMMON.SYMBOLS.
171
DEFSYML Command, Continued
Example 3 The following DEFSYML command replaces a current symbolic variable library
definition:
DEFSYML SYMSET1 DA(ESP.SYMLIB(DATEPARM)) REPLACE
In the above example, the current SYMSET1 definition is replaced.
172
DEFTJ Command
Overview The DEFTJ command is used to define the tracking parameters for a job, either by
full jobname or jobname prefix. The preferred method for defining tracked jobs is a
Job Tracking Definition Table.
Authority SCHEDULER authority or a matching ownership string is required to issue the
DEFTJ command in a non-SAF environment. With SAF, you control access to
ESPs Tracked Job commands using the TJD.jobname resource.
Syntax The syntax of the DEFTJ command is:
DEFTJ jobname
MODEL(modelname)
[TRACK|NOTRACK]
[INDEX(indexcount)]
[OWNER(ownerid)]
[PREFIX]
jobname Indicates the job or job prefix to be defined. If a prefix is
defined, the jobname should contain asterisks or a hyphen.
modelname Indicates the name of the tracking model to be associated with
the job(s). This is required unless you specify NOTRACK.
You can override this using the MODEL statement for a job
in an Application.
TRACK Indicates you want the job to be tracked. This is the default.
NOTRACK Indicates you do not want the job tracked.
indexcount Indicates the number of ancestors of a job that are to remain
on the job index data set. This defaults to the index count
specified on the tracking model for the job.
ownerid Indicates an ownership string for the job(s). It may contain
asterisks or a hyphen. This applies if your are using ESPs
internal security.
PREFIX Indicates the entry being defined is a jobname prefix entry
rather than a full jobname. Use this keyword if the jobname
contains asterisks or a hyphen.
173
DEFTJ Command, Continued
Usage notes All tracked jobs must be associated with a tracking model.
As an alternative to using the DEFTJ command to tell ESP what to track, you can
use a job tracking definition table (JTDT) to identify the characteristics of the jobs
you want ESP to track. ESP can track jobs based on jobname, execution class,
programmer name, account number, job type or the user ID associated with the jobs.
Job tracking definition tables provide greater flexibility defining the properties of
the jobs you want ESP to track and are therefore recommended.
Related
information
For information on job tracking definition tables, see the ESP Workload Manager
For information on defining or altering a tracking model, see the DEFTM command.
For information on displaying tracked jobs, see the LTJ and LJ commands.
For information on changing characteristics of a tracked job, see the ALTTJ
command.
For information on deleting a tracked job definition, see the DELTJ command.
Example 1 The following DEFTJ commands define what ESP will track:
DEFTJ PAYJOB99 MODEL(PAYSPEC) INDEX(10)
DEFTJ PAY- MODEL(PAYREG) PREFIX
DEFTJ TEST- NOTRACK
DEFTJ - MODEL(MODEL1) PREFIX
PAYJOB99 is associated with the PAYSPEC tracking model. Ten instances of
PAYJOB99 are retained on the job index file.
Jobs starting with PAY are associated with the PAYREG tracking model
Jobs starting with TEST are not tracked
All other jobs are associated with the MODEL1 tracking model.
174
DEFTM: Define Tracking Model
Overview The DEFTM command is used to define or alter a job tracking model. A tracking
model allows you to keep the tracking characteristics that apply to a job or group of
jobs in one place. Each job you want ESP to track must have an associated tracking
model.
Authority SPECIAL authority is required to issue the DEFTM command in a non-SAF
environment. With SAF, you control access to tracking models using the
MODEL.modelname resource.
Syntax The syntax of the DEFTM command is:
DEFTM name
[TRACK|NOTRACK]
[PNODE(pnode[,pnode]...)]
[ADD|REPLACE]
[INDEX
(10)|(indexcount)]
[HISTFILE(histid)]
[MONITOR(groupname)]
[JOBSTARTEVENT(eventname)]
[JOBENDEVENT(eventname)]
[JOBFAILEVENT(eventname)]
[JOBABENDEVENT(eventname)]
[STEPENDEVENT(eventname)]
[STEPFAILEVENT(eventname)]
[STEPABENDEVENT(eventname)]
name Indicates the name of the tracking model, in up to eight
characters.
TRACK Indicates you want jobs using this model tracked. This is
the default.
NOTRACK Indicates jobs using this model are not tracked. This is
normally specified in the job tracking definition table.
175
DEFTM: Define Tracking Model, Continued
Syntax (continued)
pnode Indicates the name of a processing node through which a
job has to pass before it can be considered complete. If
more than one P-Node is specified, the jobs must pass
through the P-Nodes in the order specified. The P-Node
name can be followed by a parenthesized string containing
a due-out time. This can be an actual time in the form
HH.MM, or an elapsed time in the form +HH.MM.
The P-Nodes INPUT, EXEC, and OUTPUT do not have to
be specified unless using a due-out time. This is not
commonly used with ESP Applications.
ADD Indicates this is a new definition. This is the default. The
request fails if a definition with the same name already
exists.
REPLACE Indicates the model is to be replaced. This parameter must
be used if a definition with the same name exists.
indexcount Indicates the number of ancestors of a job that are to
remain on the job index data set. This value should be at
least as large as the highest number of similarly named
jobs to be active in the job queues at one time. The default
is 10 jobs.
histfid Indicates the identifier of a job history recording data set
(its logical name) that is to receive history data for jobs
using this tracking model. This allows you to REPORT on
the jobs.
groupname Indicates any job using this model should check for
monitor points and should search Events with this ESP
group prefix for a monitor Event. You can override this
using the MONITOR statement for a job in an ESP
Application.
JOBSTARTEVENT Indicates the name of the Event to be triggered whenever
any job using this model starts.
JOBENDEVENT Indicates the name of the Event to be triggered whenever
any job using this model ends (i.e. successful or
unsuccessful).
JOBFAILEVENT Indicates the name of the Event to be triggered whenever
any job using this model fails. This Event is triggered
when a job abends or fails on condition codes.
JOBABENDEVENT Indicates the name of the Event to be triggered whenever
any job using this model abends. This does not include
condition code failures.
STEPENDEVENT Indicates the name of the Event to be triggered for each
step end of any job using this model.
176
Syntax (continued)
STEPFAILEVENT Indicates the name of the Event to be triggered for each
failing step end of any job using this model. This
includes abends and condition code failures.
STEPABENDEVENT Indicates the name of the Event to be triggered whenever
a step abends for a job using this model. This does not
include condition code failures.
Usage notes The DEFTM command allows you to centralize the definition of tracking
characteristics that can be assigned to one job, or a group of jobs. Jobs are normally
associated with a tracking model using a job tracking definition table.
A tracking model specifies:
A name for the model
The manual processing nodes (PNodes) through which a job passes
The number of ancestors of a job ESP should keep on the job index data set, job
monitor Events or the prefix of job monitor Events and the logical name of a
history recording data set.
Related
information
For information on displaying the definition of tracking models, see the LTM
command.
For information on deleting a tracking model definition, see the DELTM command.
For information on tracking definition entries in a job tracking definition table, see
the TRACKDEF statement.
For information on using tracking models and job tracking definition tables, see the
ESP Workload Manager Administrators Guide.
For information on using job monitoring and alert processing, see the ESP Workload
Example 1 The following DEFTM command defines a tracking model:
DEFTM MODEL1
In the above example, tracking model MODEL1 is defined and keeps the ten most
recent executions (default) of each job associated with this tracking model on the
job index data set. No history data is stored for jobs using this model.
177
DEFTM TESTJOBS INDEX(3)
In the above example, tracking model TESTJOBS is defined and keeps the three
most recent executions of each job associated with this tracking model on the job
index data set.
DEFTM PRODJOBS INDEX(10) HISTFILE(HIST1)
In the above example, tracking model PRODJOBS is defined and keeps the ten most
recent executions of each job associated with this tracking model on the job index
data set. History data for jobs using this model are stored in the history file whose
logical name is HIST1.
Example 4 The following DEFTM command defines a tracking model and specifies a monitor
Event to be triggered:
DEFTM STEPMON HISTFILE(HIST1) STEPENDEVENT(CYBER.STEPEND)
In the above example, tracking model STEPMON is defined. History data for jobs
using this tracking model are stored in the history file with logical name is HIST1.
ESP triggers a monitor Event called CYBER.STEPEND at each end of step for jobs
using this model.
Example 5 The following DEFTM command alters a tracking model definition:
DEFTM MODEL1 HISTFILE(HIST1) INDEX(5) REPLACE
In the above example, tracking model MODEL1s current definition is replaced with
this new definition.
Example 6 The following DEFTM command defines a tracking model and specifies a monitor
Event to be triggered:
DEFTM MODELSTC JOBSTARTEVENT(CYBER.START_STC) -
JOBENDEVENT(CYBER.END_STC)
In the above example, tracking model MODELSTC is defined. ESP triggers a
monitor Event called CYBER.START_STC each time a started task using this
model starts. ESP also triggers a monitor Event call CYBER.END_STC each time a
started task using this model ends.
178
DEFUSER Command
Overview The DEFUSER command is used to define a user to ESP. You must define each
user to ESP before it can access and use ESP. This command applies only if you are
using ESPs internal security.
Authority SPECIAL or USERDEF authority is required to issue the DEFUSER command in a
non-SAF environment.
Syntax The syntax of the DEFUSER command is:
{DEFUSER|DEFU} userid
EVENTSET(eventdsid)
[GROUP{(USERID)|(groupname)|(PREFIX)}]
[HISTFILE(histfile)]
[(OPER)|(NOOPER)]
[(SPECIAL)|(NOSPECIAL)]
[(ANY)|(NOANY)]
[AUTH[(SCHEDULER)|(NOSCHEDULER)]]
[(USERDEF)|(NOUSERDEF)]
[(GROUPDEF)|(NOGROUPDEF)]
[(CONNECTDEF)|(NOCONNECTDEF)]
[(CALENDARDEF)|(NOCALENDARDEF)]
[AUTHTAB(tabname)]
userid Indicates a one to eight character TSO user ID to be defined.
eventdsid Indicates, in up to eight characters, the logical identifier of
the Event database used to store Events prefixed with the user
ID. Use EVENTSET(NONE) to prohibit a user from defining
Events.
USERID Indicates the user ID is to be used as an Event name prefix.
groupname Indicates the group which to use as the Event name prefix.
PREFIX Indicates the current TSO profile data set prefix is used as the
Event name prefix.
password Indicates a password of up to eight characters which is to be
associated with the user ID for accessing the ESP command
through a batch job. This is required only if you are not using
a host security package.
179
DEFUSER Command, Continued
Syntax (continued)
histfile Indicates the history file ID or mask, using up to eight
characters, which can contain asterisks or a hyphen.
This controls access to the history files for reporting.
which this user belongs. It may contain asterisks and
may also have a hyphen in the last character position.
SPECIAL Indicates the user can access commands relating to
Administration.
OPER Indicates the user can issue operator commands.
ANY Indicates the user can define and access Events with any
group prefix.
SCHEDULER Indicates the user can define P-Nodes, tracking models
and job tracking parameters.
USERDEF Indicates the user can define other users within the same
the same Eventset. This user can define other users with
equal or lesser authority. The DEPARTMENT keyword
must be used with this keyword.
GROUPDEF Indicates the user can define other groups within the
same department, or department sub-group, provided
they use the same Eventset. This user can define groups
with equal or less authority than his or her own group,
but is not be able to use the RACID option, which is
only available with the DEFGROUP command to a user
with the SPECIAL attribute. The DEPARTMENT
keyword must also be used with this keyword.
CONNECTDEF Indicates a user can connect any user to any group
within the same department or department subgroup.
CALENDARDEF Indicates a user defines calendars and makes them
available to other users within the same department or
department subgroup.
NOSPECIAL Removes the SPECIAL attribute.
NOANY Removes the ANY attribute.
NOSCHEDULER Removes the SCHEDULER attribute.
NOGROUPDEF Removes the GROUPDEF attribute.
NOCONNECTDEF Removes the CONNECTDEF attribute.
NOCALENDARDEF Removes the CALENDARDEF attribute.
tabname Indicates the name of the authorization table assigned to
the user, up to eight characters.
180
Syntax (continued)
cal1 Indicates the name of the first default calendar, up to
eight characters.
cal2 Indicates the name of the second default calendar, up to
eight characters.
Usage notes Default calendars are used by Events that have no explicit calendar specification.
They are searched in the order specified. All Events automatically have access to
the system calendar, which is searched after the default calendars. A user has
update access to the calendar listed as his first default calendar if that calendar does
not have a department assigned, even though his user ID may not be included in the
ownership string of the calendar. Authority attributes are independent of each other.
For example, if you have SPECIAL authority, you do not automatically have any
other authority attributes.
Usage notes
continued
When you delete a user, none of the Events the user defined will execute.
Cybermation supplies a utility, CYBESU01, you can use to change the ownership of
an Event.
You can also define users using ESPs ISPF interface. Choose Option M from the
ESP Main Menu.
Related
information
For more information on departments, see the ESP Workload Manager
For information on using authorization tables to control access to job tracking data,
see the ESP Workload Manager Administrators Guide.
For information on calendars, see the CALENDAR command.
For information on deleting a user, see the DELUSER command.
For information on displaying a user, see the LISTUSER command.
For information on changing a users definition, see the ALTUSER command.
Example 1 The following DEFUSER command defines a user to ESP:
DEFUSER CYBUSR1 EVENTSET(EVENT1)
In the above example, CYBUSR1 is defined with no authority and Events for this
user are stored in the Event database with logical name EVENT1.
181
DEFUSER CYBUSR2 EVENTSET(EVENT1) -
AUTH(SPECIAL,ANY,OPER,SCHEDULER)
In the above example, CYBUSR2 has been given the authority to do the following:
Access commands relating to Administration
Define and access Events with any group prefix
Issue operator commands
Define P-Nodes, tracking models and job tracking parameters.
DEFUSER CYBUSR3 EVENTSET(EVENT1) CALENDAR(CAL1) -
HISTFILE(HIST1) AUTH(SCHEDULER)
In the above example, CYBUSR3. The Event data set is EVENT1; the first default
calendar is CAL1, access is allowed to the history file HIST1, and the user is
allowed to define tracking models, job tracking parameters and processing nodes.
DEFUSER CYBUSR4 EVENTSET(EVENT1) DEPT(MTS-) -
AUTH(GROUPDEF,USERDEF,CALENDARDEF,CONNECTDEF) -
HISTFILE(HISTF1)
In the above example, CYBUSR4 has been given the authority to do the following:
Define and administer any department that begins with the string MTS and is
therefore able to define other departmental sub-groups such as MTS1, MTS2,
and so on.
Define other groups and users within his own department or sub-group of
departments because of the GROUPDEF and USERDEF keywords. The groups
and users that CYBUSR4 defines can have the same or less authority, and must
use the same Eventset, EVENT1.
Define calendars, connect other users to groups and sub-groups that he has access.
182
DELAT Command
Overview The DELAT command is used to delete an authorization table. This command
Authority SPECIAL authority is required in a non-SAF environment to issue the DELAT
command.
Syntax The syntax of the DELAT command is:
DELAT tabname
tabname Indicates the name of the authorization table to be deleted,
which consists of up to eight characters.
Related
information
For information on defining authorization tables, see the DEFAT command.
For information on authorization tables, see the ESP Workload Manager
Example 1 The following DELAT command deletes an authorization table:
DELAT ATAB01
In the above example, ATAB01 is deleted. A user that has been assigned ATAB01
will no longer be able to access job-tracking data.
183
DELAYINT: Delay Interval
Overview The DELAYINT command is used to set the interval for re-triggering an Event
when required data sets are not available.
Authority OPER authority is required to issue the DELAYINT command.
Syntax The syntax of the DELAYINT parameter is:
DELAYINT [nn|5]
nn Indicates a delay interval in minutes. Specify a value from 1
to 15 minutes. The default is 5.
Usage notes If an Event requires a data set that is not available at the trigger time because it is in
use by another user, ESP tries again at the specified DELAYINT time to re-trigger
the Event.
The DELAYINT is normally specified as an Initialization Parameter.
If the DELAYINT command is entered dynamically, for example from Page mode, it
overrides the default Initialization Parameter setting until an IPL is performed.
Related
information
For information on the DELAYINT Initialization Parameter, see the ESP Workload
Manager Installation Guide.
Example 1 The following DELAYINT displays the Event re-triggering interval:
OPER DELAYINT
In the above example, ESP displays the interval for re-triggering an Event when
required data sets are not available.
Example 2 The following DELAYINT command causes ESP to retry access to a data set:
OPER DELAYINT 1
In the above example, ESP retries in 1 minute if a required data set, for example JCL
library, is not available at trigger time..
184
DELAYSUB Statement
Overview The DELAYSUB statement is used to specify a job for delayed submission relative
to the scheduled time of the Event. If the Event is not scheduled the delayed
submission time is relative to the time the Application is generated.
Syntax
The syntax of the DELAYSUB statement is:
DELAYSUB criteria
criteria Schedule criteria that resolve to a single date and time when the
Application builds.
Usage notes Use the DELAYSUB statement within the scope of a JOB statement to request that a
job not be submitted until a specified time, even though its predecessors have
completed. This time parameter can request any date or time relative to the time the
Application was schedule or generated.
If you trigger an Event with a time/date in the past, ESP does not honor
DELAYSUB statements, except those that use the term REALNOW.
Although less commonly used, the DELAYSUB statement can be placed outside the
scope of any JOB statements (globally) to delay all jobs that are placed after that
globally placed DELAYSUB statement. Using this method sets a delayed
submission time for all jobs within the Application, except for those specifying the
DELAYSUB statement within the scope of the JOB statement. Jobs that have their
delayed submission time set as a result of a globally placed DELAYSUB statement
can have those delayed submission times reset only on a job by job basis, and not as
a group.
Jobs that are inserted into active Applications do not have delayed submission time
associated with them. If you want to insert a job into an active Application and
associate a delayed submission time with that job you will have to:
1. Insert the job on hold using the IJ CSF line command
2. Reset the jobs delayed submission time (Earliest submit time field)
3. Release the job using the A CSF line command.
185
DELAYSUB Statement, Continued
Related
Statements
Note: The DELAYSUB and EARLYSUB statements perform the same function.
For information on resetting time dependencies, see the ESP Workload Manager
Users Guide.
For information on manipulating jobs within Application or subApplications, see the
For information on specifying time dependencies, see the ESP Workload Manager
Users Guide.
Example 1 The following DELAYSUB statement sets the delayed submission time of a job:
APPL PAYROLL
JOB PAYJOB1
DELAYSUB 9PM
RUN WORKDAYS
ENDJOB
In the above example, PAYJOB1 has a delayed submission time of 9 pm relative to
the time the PAYROLL Application is generated.
Example 2 The following DELAYSUB statement sets the delayed submission time based on the
day of the week:
APPL PAYROLL
JOB PAYJOB2
DELAYSUB 9PM
IF TODAY(WEEKEND) THEN DELAYSUB 6PM
RUN DAILY
ENDJOB
In the above example, PAYJOB2 has a delayed submission time of:
9 pm on weekdays
6 pm on weekends
186
DELAYSUB Statement, Continued
Example 3 The following DELAYSUB statement sets the delayed submission time based on the
day of the week:
APPL PAYROLL
JOB PAYJOB3
DELAYSUB 4PM
RELEASE PAYJOB4
ENDJOB
JOB PAYJOB4
RELEASE PAYJOB5
ENDJOB
DELAYSUB 7PM
JOB PAYJOB5
RELEASE PAYJOB6
ENDJOB
JOB PAYJOB6
ENDJOB
SELECT (PAYJOB3,PAYJOB4,PAYJOB5,PAYJOB6)
PAYJOB3 has a delayed submission time of 4pm
PAYJOB4 does not have a delayed submission time
PAYJOB5 & PAYJOB6 have delayed submission times of 7pm.
Other examples Here are more examples using the DELAYSUB statement.
Sets the delayed submission to 10 minutes after the scheduled time of the Event:
DELAYSUB NOW PLUS 10 MINUTES
Sets the delayed submission time to 10pm two workdays from the scheduled time of
the Event:
DELAYSUB 10PM TODAY PLUS 2 WORKDAYS
Sets the delayed submission time to 11 pm on the last workday of the month, and to
9 pm on all other days this job is submitted:
IF TODAY(LAST WORKDAY OF MONTH) THEN -
DELAYSUB 11PM
ELSE -
DELAYSUB 9PM
187
DELCAL Command
Overview The DELCAL command is used to delete a calendar and all the holidays and special
days within it.
Authority SPECIAL or CALENDARDEF authority is required in a non-SAF environment to
issue the DELCAL command. With SAF, you control access to calendars using the
CALENDAR.calname resource.
Syntax The syntax of the DELCAL command is:
{DELCAL|DELC} calname
calname Indicates a one to eight character calendar name to be deleted.
Usage notes Deleting a calendar should only take place when you are sure no Event or
Applications use schedule terms in the calendar.
Related
information
For information on calendars, see the ESP Workload Manager Administrators
Guide.
For information on defining calendars, see the DEFCAL command.
Example 1 The following DELCAL command deletes a calendar:
DELCAL PAYCAL
In the above example, PAYCAL and its entire contents, (for example holidays,
special days and special periods), are deleted.
188
DELETE Command - Event Definition
Overview The DELETE command, when used in an Event definition, is used to delete an
Event at a scheduled time.
Type Event command.
Syntax The syntax of the DELETE command is:
{DELETE|DEL} criteria
criteria Schedule criteria that resolve to a single date and time.
Related
information
Users Guide.
For information on deleting an Event, outside an Event definition, see the DELETE
Command - General.
Example 1 The following DELETE command deletes an Event at a scheduled time:
DELETE 10AM FIRST DAY OF YEAR
In the above example, an Event is deleted at 10 am on the first day of the year.
Example 2 The following DELETE command deletes an Event at a scheduled time:
DELETE 11PM MARCH 2,1998
In the above example, an Event is deleted at 11 pm on March 2
nd
, 1998.
189
DELETE Command - General
Overview The DELETE command is used to delete an Event definition.
Syntax
The syntax of the DELETE command is:
{DELETE|DEL} eventid
eventid Indicates the name of an Event to be deleted. If no prefix is
specified, your current GROUP prefix is used.
Usage notes The specified Event is deleted at the time the command is entered, even if the Event
is currently scheduled.
Related
information
Users Guide.
For information on displaying Events, see the LIST command.
For information n scheduling a deletion of an Event, see the DELETE Command -
Event Definition.
Example 1 The following DELETE command deletes an Event definition:
DELETE CYBER.PAYROLL
In the above example, CYBER.PAYROLL is deleted.
190
DELGROUP Command
Overview The DELGROUP command is used to delete a group definition. This command
Type General command
Authority SPECIAL or GROUPDEF authority is required to issue the DELGROUP command.
Syntax The syntax of the DELGROUP command is:
{DELGROUP|DELG} groupname
groupname Indicates the name of the group to be deleted.
Related
information
Guide.
For information on defining groups, see the DEFGROUP command.
command.
Example 1 The following DELGROUP command deletes a group:
DELGROUP ACCOUNTS
In the above example, the ACCOUNTS group is deleted.
191
DELHOL Command
Overview The DELHOL command is used to delete a holiday definition.
Authority You can delete only holidays defined in your first default calendar, or in calendars to
Syntax The syntax of the DELHOL command is:
{DELHOL|DELH} holidayname
START(starttime)
[CALENDAR(calname)]
holidayname Indicates the 1 to 16 character name of the holiday
starttime Indicates the starting time and date of the holiday. If the date
specification contains separators, it should be enclosed in
quotes.
calname Indicates the name of the calendar in which the holiday is
defined.
Usage notes You must delete one holiday at a time.
The holiday name and start time must match an existing definition for the command
to work. The time and date specification must be accurate to within one minute.
If you do not specify a calendar name, the following calendars are searched in the
order listed.
1. The first default calendar as defined in your user ID entry.
2. The second default calendar as defined in your user ID entry.
The first matching holiday entry found is deleted.
Usage notes
continued
Normally you do not need to delete holiday definitions. Holidays are automatically
deleted after the retention period expires, as per the time period specified when the
holiday was defined.
192
DELHOL Command, Continued
Related
information
For information on defining holidays, see the DEFHOL command.
For information on displaying holiday information, see the LISTHOL command.
Example 1 The following DELHOL command deletes a holiday:
DELHOL TEMPORARY START(FEB 22,1998) CAL(UCAL2)
In the above example, TEMPORARY is deleted from the UCAL2 calendar.
193
DELPN Command
Overview The DELPN command is used to delete a P-Node definition.
Authority SCHEDULER authority is required in a non-SAF environment to issue the DELPN
command. With SAF, you control access to P-Nodes using the PNODE.pnodename
resource.
Syntax The syntax of the DELPN command is:
DELPN pnode
pnode Indicates the name of the P-Node being deleted.
Related
information
For information defining manual P-Nodes, see the DEFPN command.
Example 1 The following DELPN command deletes a P-Node:
DELPN DISTRIB
In the above example, the DISTRIB manual P-Node is deleted.
194
DELSIG Command
Overview The DELSIG command is used to delete a signal.
Authority You can delete only those signals beginning with a prefix to which you have access.
Syntax The syntax of the DELSIG command is:
DELSIG signalname
signalname Indicates the name of the signal. If the prefix is omitted, the
current group or user prefix is used.
Related
information
Users Guide.
For information on defining signals, see the DEFSIG command.
command.
For information on displaying all generations of a signal, see the LISTSIG
command.
Example 1 The following DELSIG command deletes a signal:
DELSIG CYBER.SIGNAL1
In the above example, CYBER.SIGNAL1 is deleted.
Example 2 The following DELSIG command deletes a signal:
DELSIG SIGNAL2
In the above example, SIGNAL2 is deleted. If, for example the current group prefix
is PROD, then PROD.SIGNAL2 is deleted.
195
DELSPEC Command
Overview The DELSPEC command is used to delete a special day or period definition.
Authority You can delete only special days or periods defined in your first default calendar, or
calendars to which you have access.
Syntax The syntax of the DELSPEC command is:
DELSPEC specname
ON(date)
[CALENDAR(calname)]
specname Indicates a 1 to 16 character name of a special day or period.
date Indicates the starting time and date of the special day or
period. If the date specification contains separators, it should
be enclosed in quotes.
calname Indicates the name of the calendar in which the special day is
to be deleted.
Usage notes You must delete one special day at a time.
The special day and start time must match an existing definition for the command to
work. The time and date specification must be accurate to within one minute.
If you do not specify a calendar name, the following calendars are searched in the
order listed. The first matching special day/period entry found is deleted.
1. The first default calendar as defined in your user ID entry.
2. The second default calendar as defined in your user ID entry.
Normally you do not need to delete special days. Special days are automatically
deleted after the retention period expires, as per the time period specified when the
special day was defined.
196
DELSPEC Command, Continued
Related
information
For information on using special days, see the ESP Workload Manager Users
Guide.
For information on defining special days or periods, see the DEFSPEC command.
For information on displaying special day and period information, see the
LISTSPEC command.
Example 1 The following DELSPEC command deletes a special day:
DELSPEC PAYROLL_DAY ON(26TH NOVEMBER 1998)
In the above example, PAYROLL_DAY, which falls on November 26
th
, 1998 is
deleted.
197
DELSYML Command
Overview The DELSYML command is used to delete a symbol library.
Authority SPECIAL, SCHEDULER or CALENDARDEF authority is required to issue the
DELSYML command in non-SAF environments. With SAF, you control access to
symbol libraries using the SYMLIB.symname resource.
Syntax The syntax of the DELSYML command is:
DELSYML name
name Indicates the name of the symbolic variable library to be
deleted.
Usage notes The DELSYML command deletes the logical identifier of the symbol library.
Related
information
For information on displaying symbol libraries, see the LISTSYML command.
For information on defining a symbol library, see the DEFSYML command.
Example 1 The following DELSYML command deletes a symbol variable library:
DELSYML USRSYMS
In the above example, USRSYMS is deleted.
Note: Only the logical identifier (USRSYMS) is deleted and not the data sets
associated with the identifier when the symbolic library was defined.
198
DELTJ Command
Overview The DELTJ command is used to delete tracked job definitions from the job index
file.
Authority SCHEDULER authority or a matching ownership string is required to issue the
DEFTJ command in a non-SAF environment. With SAF, you control access to
ESPs Tracked Job commands using the TJD.jobname resource.
Syntax The syntax of the DELTJ command is:
DELTJ jobname
[PREFIX]
jobname Indicates the name of the job, or job prefix to delete. Only if
a job prefix is deleted can the name contain asterisks and a
hyphen.
PREFIX Indicates a prefix entry is being deleted. This applies only if
you are not using a Job Tracking Definition Table.
Usage notes Normally you should not need to delete tracked job definitions.
The preferred method for deleting and altering tracked job definitions is a Job
Tracking Definition Table.
Related
information
For information on changing characteristics of a tracked job, see the ALTTJ
command.
Example 1 The following DELTJ command a tracked job definition:
DELTJ PAYJOB99
In the above example, PAYJOB99 is deleted from the job index file.
199
DELTJ Command, Continued
Example 2 The following DELTJ command deletes multiple tracked job definitions:
DELTJ ABC- PREFIX
In the above example, any job whose name starts with the characters ABC is deleted
from the job index file. Jobs with this prefix that are already tracked continue to be
tracked as specific entries were built. These can be deleted individually if required.
This example applies only if you are not using a Job Tracking Definition table
200
DELTM Command
Overview The DELTM command is used to delete a tracking model definition.
Authority SPECIAL authority is required to issue the DELTM command in a non-SAF
environment. With SAF, you control access to tracking models using the
MODEL.modelname resource.
Syntax The syntax of the DELTM command is:
DELTM model
model Indicates the name of the tracking model to be deleted.
Usage notes Caution should be used when deleting tracking models. Tracking models contain
tracking characteristics that may apply to a large number of jobs. If a tracking
model is deleted, ESP no longer tracks all jobs associated with that tracking model.
Related
information
For information on displaying a tracking model, see the LTM command.
For information on defining a tracking model, see the DEFTM command.
For information on tracking definition entries in a Job Tracking Definition Table,
see the TRACKDEF statement.
For information on using tracking models, and Job Tracking Definition Tables, see
the ESP Workload Manager Administrators Guide.
Example 1 The following DELTM command deletes a tracking model definition:
DELTM MODELTST
In the above example, MODELTST is deleted.
201
DELUSER Command
Overview The DELUSER command is used to delete a user definition from ESP. The
command applies only if you are using ESPs internal security.
Authority SPECIAL or USERDEF authority is required to issue the DELUSER command in a
non-SAF environment.
Syntax The syntax of the DELUSER command is:
{DELUSER|DELU} userid
userid Indicates the name of the user definition to be deleted.
Related
information
For information on defining users, see the ESP Workload Manager Administrators
Guide.
For information on defining a user, see the DEFUSER command.
For information on displaying a user, see the LISTUSER command.
Example 1 The following DELUSER command deletes a user:
DELUSER CYBUSR9
In the above example, CYBUSR9 is deleted and is no longer able to access ESP.
202
DESELECT Statement
Overview The DESELECT statement is used to deselect a job or subApplication. Deselected
jobs are not built as part of the Application. Use the DESELECT statement to
handle exceptions to regular schedule criteria.
Syntax The syntax of the DESELECT statement is:
DESELECT {jobname|(jobname[,jobname])} [JOB|SUBAPPL]
jobname Indicates a jobname. Enclose multiple jobnames in
parentheses, separated by a blank or comma.
JOB Indicates a job is being deselected for submission. This is the
default.
SUBAPPL Indicates all jobs within a subApplication are being
deselected for submission.
Usage notes You can deselect a group of jobs using the SUBAPPL parameter.
You can use more than one DESELECT statement.
The DESELECT statement identifies that a previously selected job should not be
selected as part of the Application. It can be used only after you have specified a
SELECT or RUN statement for the jobs involved.
If the DESELECT statement is used for any job that has PREREQ, POSTREQ or
COREQ specified, the jobs that these statements refer to are deselected
automatically.
Jobs that are specified as PREREQ, POSTREQ or COREQs can not explicitly be
deselected using a DESELECT statement.
Jobs that are selected to run using a RUN statement can be deselected using a
DESELECT statement.
ESP allows multiple SELECT and DESELECT statements for the same job or
subApplication.
You should normally code your DESELECT statements after your SELECT
statements since ESP processes the statements in the order specified.
203
DESELECT Statement, Continued
Related
Statements
For information on selecting a job or subApplication for submission, see the
SELECT statement.
For information on selecting and deselecting jobs or subApplications for
submission, see the ESP Workload Manager Users Guide.
Example 1 The following DESELECT statement is used to deselect a job on Fridays:
APPL PAYROLL
JOB PAYJOB1
RELEASE PAYJOB2
JOB PAYJOB2
ENDJOB
SELECT (PAYJOB1,PAYJOB2)
IF TODAY(FRIDAY) THEN DESELECT PAYJOB2
In the above example, when the PAYROLL Application is generated PAYJOB1 and
PAYJOB2 are always selected, except on Fridays, when PAYJOB2 is deselected.
Example 2 The following DESELECT statement is used to deselect two jobs on the first
workday of the month:
APPL PAYROLL
JOB PAYJOB5
RUN DAILY
POSTREQ PAYJOB6
JOB PAYJOB6
ENDJOB
IF TODAY(FIRST WORKDAY OF MONTH) THEN DESELECT PAYJOB5
In the above example, when the PAYROLL Application is generated ESP runs
PAYJOB5 and PAYJOB6 daily, except on the first workday of the month, when
both PAYJOB5 and PAYJOB6 are deselected. This is because a DESELECT
statement is used for PAYJOB5, which has a POSTREQ of PAYJOB6.
204
DESELECT Statement, Continued
Example 3 The following statements are used to:
select subApplications
select jobs within an Application
deselect a subApplication
deselect a job within an Application.
APPL PAYROLL
JOB ACCJOB1
SUBAPPL ACCPAY
ENDJOB
JOB ACCJOB2
SUBAPPL ACCPAY
ENDJOB
JOB BILJOB1
SUBAPPL BILLING
ENDJOB
JOB BILJOB4
SUBAPPL BILLING
ENDJOB
JOB PAYJOB10
ENDJOB
JOB PAYJOB11
ENDJOB
SELECT (ACCPAY,BILLING) SUBAPPL
IF TODAY(LAST WORKDAY OF MONTH) THEN DESELECT BILLING -
SUBAPPL
IF TODAY(MONDAY) THEN DESELECT ACCJOB2
The ACCPAY and BILLING subApplications are selected
PAYJOB10 and PAYJOB11 are selected
The BILLING subApplication is not selected on the last workday of the month
ACCJOB2 is not selected on Mondays.
Other examples Here are more examples of using the DESELECT statement.
Indicates a job is not selected for submission:
DESELECT PAYJOB1 or DESELECT PAYJOB1 JOB
Indicates two subApplications are not selected for submission:
DESELECT (PREPJOBS,POSTJOBS) SUBAPPL
205
DFLTUSER Command
Overview The DFLTUSER command is used to define the characteristics of an undefined user
communicating with ESP for the first time. This command is needed only if you are
not using a host security product with password protection.
Authority SPECIAL authority is required to issue the DFLTUSER command.
Syntax The syntax of the DFLTUSER command is:
DFLTUSER {[NONE]}
{[AUTH {(SPECIAL)|(OPER)|(ANY)}]}
{[GROUP{(PREFIX)|(groupid)|(USERID)}]}
{[EVENTID(evdb)]}
NONE Indicates no unauthorized users may access the system.
AUTH Indicates the attributes to be assigned to the user.
SPECIAL Indicates the user is allowed full access to ESP, including
holiday and special day definitions as well as group and user
definitions.
OPER Indicates the user is allowed to issue ESP operator
commands.
ANY Indicates the user is allowed to access any Event, even though
he is not connected to the group in which the Event is
defined.
GROUP Indicates the default GROUP to which the user is assigned.
PREFIX Indicates the TSO profile prefix should be used. This is the
default if the GROUP keyword is not specified.
groupid Indicates the group prefix of your choice, using up to eight
characters.
USERID Indicates the user ID should be used as a group prefix for
Events.
evdb Indicates the identifier of an Event database, using up to eight
characters. This Event database contains the Events that the
user defines, prefixed by his or her own user ID.
Usage notes The GROUP keyword specifies the default GROUP to which the user is assigned.
This command has to be reissued only when any specifications are to be modified.
206
DFLTUSER Command, Continued
Related
information
For information on defining and deleting users to ESP, see the DEFUSER and
DELUSER commands.
For information on defining users and groups, see the ESP Workload Manager
Example 1 The following DFLTUSER command defines the characteristics of an undefined
user to ESP:
DFLTUSER GROUP(USERID) EVENT(EVENT1)
In the above example, any user who is not defined to ESP has their user ID assigned
as their ESP group prefix, and all their Event definitions are stored in the Event
database called EVENT1.
207
DFPNODE Command
Overview The DFPNODE command is used to display or set the default P-Node for the issuing
system console or TSO session.
Authority OPER authority is required to issue the DFPNODE command.
Syntax The syntax of the DFPNODE command is:
DFPNODE [pnodename]
pnodename Indicates the name of the default P-Node. If this Parameter is
omitted, the current default P-Node is displayed.
Usage notes The DFPNODE command makes it easier for a TSO user or system console operator
to POST a job from a P-Node because the PNODE parameter of the POST command
is not needed. The PNODE parameter on the POST command can still be used to
override the default P-Node.
The default P-Node is retained across sessions and IPLs until reset by another
DFPNODE command.
Related
information
command.
For information on defining and deleting manual P-Nodes, see the DEFPN and
DELPN commands.
208
DFPNODE Command, Continued
Example 1 The following DFPNODE command sets a default P-Node:
DFPNODE BURSTER
In the above example, BURSTER is set as the default P-Node for the issuing console
or user ID. To post jobs from a default P-Node issue the POST command as
follows:
POST MYJOB
POST OTHERJOB
209
DISCONN Command
Overview The DISCONN command is used to remove the authority of a user to access a group
prefix.
Authority SPECIAL or CONNECTDEF authority is required to issue the DISCONN command
in a non-SAF environment.
Syntax The syntax of the DISCONN command is:
{DISCONN|DISCON} userid
GROUP(groupname)
userid Indicates the user ID to be disconnected.
groupname Indicates the name of the group from which the user is being
disconnected.
Usage notes The DISCONN command applies only if your are using ESPs internal security.
It may be necessary to restrict a users access to a Group prefix. You may have to do
this if, for example, the user moves out of that group to another area of your
organization, or to another company.
Related
information
For information on connecting a user to a group, see the CONNECT command.
For information on listing a user definition, see the LISTUSER command.
Example 1 The following DISCONN command disconnects a user from a group:
DISCONN FRED GROUP(BILLING)
In the above example, FRED is disconnected from the BILLING group.
210
DISPLAY Command
Overview The DISPLAY command is used to specify which reporting fields you want to
display when creating history reports.
Syntax The syntax of the DISPLAY command is:
DISPLAY field
[length]
[title1]
[title2]
field Indicates the name of a field to be displayed.
length Indicates an optional length. This can be used to create more
space between columns. Fields are left justified, blanks are
padded on the right to the length specified.
title1 Indicates a title, enclosed in quotes.
title2 Indicates a second title, enclosed in quotes.
Usage notes Once the DISPLAY section is started, several field names can be entered one after
another, along with optional lengths and titles, separated by a comma. The specified
fields are placed on the report detail line in the order specified.
If the length of the titles exceeds the length of the field, the column width adjusts to
accommodate the titles.
Related
information
For information on history reporting including a list of valid fields, see the ESP
For information on beginning a report definition, see the REPORT command.
Example 1 The following DISPLAY command indicates the fields to display:
DISPLAY APPLSYS JOBNAME JOBNO EXECST ENDT
In the above example, the following fields are displayed as part of a history report:
Application name (APPLSYS)
Job name (JOBNAME)
Job number (JOBNO)
Execution start time (EXECST)
Execution end time (ENDT).
211
DISPLAY Command, Continued

DISPLAY JOBNAME,RDRON,RDRONDATE,TEXCP 5 TAPE EXCPS -
DEXCP 6 DISK EXCPS
Job name (JOBNAME)
Time at which ESP read the job into the system (RDRON)
Date at job submission (RDRONDATE)
Tape EXCP count to 5 digits, with a title of TAPE EXCPS (TEXCP)
Disk EXCP count to 6 digits, with a title of DISK EXCPS (DEXCP).

DISPLAY JOBNAME 15,CMPC
Job name, padded on the right with blanks to a width of 15 (JOBNAME)
Completion code (CMPC).

212
DJCDATA Statement

Overview The DJCDATA statement is used to introduce DJC (Dependent Job Control) or
JES3 statements for a job.

Type ESP Application statement, DJC Network statement.

Syntax The syntax of the DJCDATA statement is:
DJCDATA [ID(name)]
[RS([op][n,]resname[,[op][n,]resname...])]
[TC(t)]
[HC(num)]
[RL(jobname[,jobname]...)]
[AB(jobname[,jobname]...)]
[AF(jobname[,jobname]...)]
[NC{(F)|(D)|(R)}]
[AB{(F)|(D)|(R)}]
[NR(netid,jobname[,netid,jobname]...)]
[OH{(NO)|(YES)}]
[LN{(R)|(N)|(C)}]
[NRCMP{(HOLD|(NOHO)|(FLSH)}]
[ABCMP{(NOKP)|(KEEP)}]
Syntax
abbreviations
The following keyword abbreviations are used:

Abbreviation Description Abbreviation Description
ID NETID AF AFTER
RS RESOURCE NC NORMAL
TC TAPES AB ABNORMAL
HC NHOLD NR NETREL
RL RELEASE OH OPHOLD
BF BEFORE LN LASTNET
213
DJCDATA Statement, Continued
Syntax
name Indicates the name of the jobnet containing this job. The name
can be up to eight alphanumeric characters, the first of which
must be alphabetic. This overrides the DJCNET setting.
op A logical operator indicating that the resource must be
unavailable or that less than the indicated quantity (n) of the
resource must be available. Use a negative quantity of a
resource to indicate that a job provides a resource; use a not
sign to indicate that the unavailability of a resource is
required; use the less than sign (<) to indicate that less than
the indicated quantity must be available. This parameter
requires DJC 3.6.0 and up.
n Used only with a quantum resource. This specifies the number
of units of the specified resource that must be available for the
job to be eligible for execution. It is separated from the
resource name by a comma. The default is 1.
resname Indicates the name of a resource that must exist before a job
can become eligible for execution. The resource specified can
be a real or abstract resource. A logical resource is specified
without a count (n). A combination of quantum, either real or
abstract, and logical resources can be specified, up to a
maximum of 64.
TC(t) Indicates the number of tape drives required that must be online
and available to the system for this job to be released. The
range is up to 999. The TC parameter applies to either 3420
(reel to reel) or 3480 (cartridge) tape drives, or applies
indiscriminately, depending on a DJC Installation Parameter.
This parameter can be specified alone, without being part of a
DJC jobnet.
HC(num) Indicates the number of immediate predecessor job completions
required before this job can be released for execution. The
range is up to 32,767. This count should not include any job
referenced by the AFTER, POSTREQ, PREREQ or RELEASE
statements in an ESP Procedure. In these cases, the count is
adjusted automatically.
RL(jobname) Indicates the name(s) of jobs in the specified jobnet that are
successors to this job. Up to 50 names can be specified,
separating each by a comma.
BF(jobname) Indicates the name(s) of up to seven jobs already in the system
before which this job must run. Separate each job name with a
comma. BEFORE dynamically increments the hold count on
the successor job(s). If a successor job is not in the system
when this job is read in, the successors hold count is not
incremented, and BEFORE is ignored. BEFORE can refer to
any job, whether or not it is part of a dependent jobnet.
214
Syntax (continued)
AF(jobname) Indicates the name(s) of up to seven job(s) already in the
system after which this job must run. Separate each job name
with a comma. AFTER dynamically increments the hold count
on this job to correspond to the appropriate number of AFTER
jobnames specified. If any predecessor job is not in the system
when this job is read in, its AFTER count is ignored. AFTER
can refer to any job, whether or not it is part of a dependent
jobnet.
NC Indicates the action to be taken for this job when any
predecessor terminates normally:
D - decrement the NHOLD count of this job. If the
NHOLD count goes to zero, this job becomes eligible for
execution. This is the default.
F - flush this job from the system. The job is canceled, and
any output is printed. To any successor job, this appears as
an abnormal termination.
R - retain this job in the system and do not decrement the
NHOLD count. This suspends the job and its successors
from execution until either the predecessor job is
resubmitted, or the operator decreases the NHOLD count.
AB Indicates the action to be taken for this job when any
predecessor terminates abnormally:
R - retain this job in the system and do not decrement the
NHOLD count. This suspends the job and its successors
from execution until either the predecessor job is
resubmitted, or the operator decreases the NHOLD count.
D - decrement the NHOLD count of this job. If the NHOLD
count goes to zero, this job becomes eligible for execution.
F - flush this job from the system. The job is cancelled, and
any output is printed. To any successor job, this appears as
an abnormal termination.
NR Indicates a net release. This job is a predecessor to a job in
another jobnet.
netid specifies the NETID name of the successor job.
jobname identifies the name of the successor job.
You can specify up to fourteen jobs in other jobnets, separating
each netid-jobname pair with a comma.
Note: JES3 only supports 1 NETID per net release statement.
215
Syntax (continued)
OH Indicates whether the job is to be placed into dependent job
operator hold:
NO - specifies that the job is to be processed normally,
without operator intervention. This is the default.
YES - specifies that the job is placed in dependent job
network operator hold. This prevents execution of this job
until the operator explicitly releases it.
LN Indicates the disposition of a previous jobnet with the same
name:
N - this is not the first job of a new jobnet and normal
processing should take place. This is the default.
R - this is the first job of a new jobnet. Any jobs already on
the system that are in a jobnet with the same NETID, are
released.
C - this is the first job of a new jobnet. Any jobs already on
the system that are in a jobnet with the same NETID, are
canceled.
ABCMP Indicates what action JES3 is to take if the job abnormally
terminates:
NOKP - purge the DJC network if the job abnormally
terminates and has not been resubmitted by the time the
other jobs in the network have completed. JES3 purges the
network unless successor jobs or sub-networks are missing.
KEEP - keep the DJC network in the system until either the
job is resubmitted and completes normally or the operator
forces the network from the system.
This parameter is for use only with JES3.
NRCMP Indicates that a network job, which completed normally is
being resubmitted and that JES3 must erase all references to the
job before the job re-enters the network. The actions for JES3
to take are:
HOLD - hold the job until the operator releases it. This is
the default.
NOHO - allow the job to be scheduled as system resources
become available.
FLSH - flush the job from the system.
This parameter is only for use with JES3
216

Usage notes To use this statement, you must have JES3 or Cybermations DJC (Dependent Job
Control) product installed.
It is recommended that you use the job statement elements AFTER, RELEASE
or one of the requisite statements for job dependency purposes because the required
NET card information is then automatically built for you. If DJCDATA is
specified, any parameters used are merged with the NET card information
automatically generated in the ESP Procedures, without being checked.
The DJCDATA statement can only be used for a job in either a DJC jobnet or an
ESP Application. If a job belongs to neither of these then use a job specific
automatic variable to insert the required DJC parameters.
For a job defined in an ESP Application, you can use the RS parameter to identify
DJC resource requirements.

Related
Statements
For information on Dependent Job Control Card specifications, see the DJC Users
Guide.

Example 1 The following DJCDATA statement is used to request two tape drives and release a
job in another network:
JOB PAYJOB1
DJCDATA NETID(PAYNET) TC(2) NR(OTHERNET,PAYJOB99)
ENDJOB
In the above example, PAYJOB1:
Is part of a net called PAYNET
Requires two tape drives
Releases PAYJOB99, which belongs to a net called OTHERNET after its
successful completion.

Example 2 The following DJCDATA statement is used to request two separate resources:
JOB PAYJOB2
DJCDATA RS(1,CICS,1,SCRTAPES)
ENDJOB
In the above example, PAYJOB2:
Requires 1 unit of a resource called CICS
Requires 1 unit of a resource call SCRTAPES.
217

Example 3 The following DJCDATA statement is used to request that a job wait until a
resource is not available:
JOB PAYJOB3
DJCDATA RS(IMSUP)
ENDJOB
In the above example, PAYJOB3 waits until a resource called IMSUP is not
available.

Example 4 The following DJCDATA statement is used to request that a job only run when the
quantity of a resource is less than 5:
JOB PAYJOB4
DJCDATA RS(<5,SCRTAPES)
ENDJOB
In the above example, PAYJOB4 runs only when the available number of units of a
resource called SCRTAPES is less than 5.
Example 5 The following DJCDATA statement is used to define a job on operator hold:
JOB PAYJOB5
DJCDATA OH(YES)
ENDJOB
In the above example, PAYJOB5 is defined on operator hold.

218
DJCNET Statement

Overview The DJCNET statement is used to identify that jobs with dependencies are
controlled by DJC (Dependent Job Control) or by JES3. It also specifies the default
network name for dependent jobs.

Type DJC Network statement.

Syntax
The syntax of the DJCNET statement is:
DJCNET netid

netid Indicates a job network identifier. The maximum length of the
netid is 8 characters. The first character cannot be a number.
The netid applies unless:
You override the netid name with the DJCDATA statement
at the job level
Another DJCNET statement with a different netid appears
in the same ESP Procedure.

Usage notes In ESP you can define groups of related jobs as either a DJC or JES3 job network or
an ESP Application. Applications provide more flexibility and are easier to work
with.
At the initiator stage, ESP submits network jobs to the JES queue when the Event is
scheduled or triggered. Each job requires a NET control statement in its JCL that
identifies:
The specific network to which it belongs
The dependent actions that are necessary (e.g. completion of a predecessor job)
before JES can initiate the job.
The DJCNET statement allows you to specify the default net identifier for jobs in an
ESP Procedure.
Jobs defined using DJC or JES3 networks are not available for viewing or
manipulation via the Consolidated Status Facility (CSF) or the Application status
panels. The CSF and Application status panels are available only for jobs belonging
to ESP Applications.
Jobs defined using job networks are viewed and controlled using JES commands.
219
DJCNET Statement, Continued

Related
information
For information on DJC, see the DJC Users Guide.
For information on using DJC or JES3 statements for a job, see the DJCDATA
statement.

Example 1 The following DJCNET statement is used to group related jobs into a DJC network:
DJCNET PAYROLL
JOB PAYJOB1
RUN DAILY
RELEASE PAYJOB2
JOB PAYJOB2
RUN DAILY
RELEASE PAYJOB3
JOB PAYJOB3
RUN DAILY
ENDJOB
In the above example, PAYJOB1, PAYJOB2 and PAYJOB3 are grouped together in
a DJC network called PAYROLL.

220
DN Command

Overview The DN command is used to display the names of jobs, TSO users and started tasks
on the P-Node queues.


Authority OPER authority is required to issue the DN command.

Syntax The syntax of the DN command is:
DN [QUEUE(pnodename[,pnodename]...)]
[JOB[(jobname[,jobname]...)]]
[TSU[(tsuname[,tsuname]...)]]
[STC[(stcname[,stcname]...)]]
[OVERDUE(mins)]
[AT(time)]
[TIME]
[DATE]
[COMPRESSED]
[DUE]
[SID]

pnodename Indicates the name or names of P-Node(s) to be displayed.
Several names can be specified, enclosed in parentheses and
separated by a blank or comma. The names can contain
asterisks and end with a hyphen for a generic specification.
jobname Indicates the name or names of jobs to be displayed. Several
names can be specified, if separated by a comma. The names
can contain asterisks and end with a hyphen for a generic
specification.
tsuname Indicates the name(s) of TSO users to be displayed. Several
names can be specified if separated by a comma. The names
can contain asterisks and end with a hyphen for generic
specification.
stcname Indicates the name(s) of started tasks to be displayed. Several
specification.
mins Indicates an overdue amount. Jobs are displayed if they are
overdue by the specified number of minutes. If OVERDUE is
specified with no Parameters, 0 is assumed.
221
DN Command, Continued
Syntax (continued)
AT(time) Used together with the DUE or OVERDUE keywords,
requests a display of jobs that would be overdue if not
complete at the specified time. The time can contain a free
format date and time specification. It should be enclosed in
quotes if it contains a blank or comma.
TIME Indicates the time the job entered the P-Node queue is
displayed.
DATE Indicates the date the job came into the P-Node queue is
displayed.
COMPRESSED Indicates the display is compressed to get as many entries on
a line as possible. In addition, only the first eight characters
of a P-Node name are displayed.
DUE Indicates the dueout time for each job is displayed. Jobs that
do not have a dueout time are marked as having no due time.
To identify a job as having a dueout time, use the DUEOUT
or LATESUB Application statements.
SID Indicates the system ID, where the JOB/STC/TSU was last
posted from, be displayed.
Usage notes As an alternative to using the DN command to display the names of jobs on the P-
Node queues, you can use the Consolidated Status Facility (CSF) for monitoring and
controlling jobs in Applications.

Related
information
For information on displaying the number of jobs on each queue, see the DQ
command.
command.
For information on monitoring and controlling workload using the CSF, see the ESP

Example 1 The following DN command displays all queues:
DN
In the above example, all P-Node queues are displayed.
222
DN Command, Continued

Example 2 The following DN command displays the execution P-Node:
DN QUEUE(EXEC) JOB(-)
In the above example, all jobs on the execution P-Node are displayed.

Example 3 The following DN command displays specific jobs:
DN JOB(A-,B-) QUEUE(INPUT) DATE TIME
In the above example, jobs with names that start with A or B in the INPUT queue
are displayed. The date and time the jobs entered their respective queues are also
shown.

Example 4 The following DN command displays overdue jobs:
DN OVERDUE(10) AT(6AM) DUE
In the above example, any job that would be more than ten minutes overdue if it
does not complete by 6 am is displayed. The due time for each job is displayed as
well as the jobname, number and P-Node name.

223
DO Statement

Overview The DO statement is used to identify the start of a set of instructions.

Type ESP Control Language (CLANG) statement.

Syntax The syntax of the DO statement is:
DO

Usage notes The DO statement is normally used in conjunction with THEN and ELSE
statements. It groups instructions together, until an ENDDO statement is
encountered.
You do not require a DO statement if you have only one instruction. DO must follow
immediately after THEN or ELSE, or begin the continuation line. Do not use a
continuation character ( or +) on a DO statement.
The DO statement does not have to be used in conjunction with a THEN or ELSE
statement.

Related
information
For information on ending a set of instructions, see the ENDDO command.
For information on using ESPs Control Language, see the ESP Workload Manager
Users Guide.

Example 1 The following DO and ENDDO statements are used to identify the start and end of a
set of instructions:
DO
SELECT PAYJOB2
SEND SUBMITTING MONTH END JOB USER(CYB01)
ENDDO
In the above example, on the last workday of the month, ESP:
Selects PAYJOB2
Sends a message to user CYB01.
224
DO Statement, Continued

set of compound action statements:
IF DAYS_FROM(JAN) GT 7 THEN DO
ESP RESUME CYBER.YECHEQUE
ESP TRIGGER CYBER.YECHEQUE ADD
SEND YEAR-END CHEQUES TRIGGERED U(CYB02)
ENDDO
In the above example, an ESP built-in function (DAYS_FROM) is used to calculate
the number of days from January 1
st
. If the number of days from January 1
st
is
greater than 7, ESP:
Resumes and then triggers an Event called CYBER.YECHEQUE
Sends a message to user CYB02.

set of instructions:
APPL PAYROLL
JCLLIB CYBBS01.JCLLIB.CNTL
JOB PAYJOB3
RUN DAILY
DO
SEND MESSAGE #1 U(CYB03)
SEND MESSAGE #2 U(CYB03)
ENDDO
ENDJOB
In the above example, when the PAYROLL Application is generated PAYJOB3 is
submitted and two messages are sent to user CYB03.
Note: In this example, the DO - ENDDO pairing is not used in conjunction with a
THEN or an ELSE statement.

Example 4 The following DO and ENDDO statements are used to identify the start and end of
an instruction:
IF ACTIVE(CICS) THEN -
DO
SEND CICS IS ACTIVE CN(01)
ENDDO
In the above example, there is only one instruction to process if the IF statement
returns a true value. You can use DO and ENDDO to identify the start and end of
the instruction.
Alternatively, you could use the following:
IF ACTIVE(CICS) THEN -
SEND CICS IS ACTIVE CN(01)

225
DOCLIB Statement

Overview The DOCLIB statement is used to identify the name of the job documentation
library to be used throughout an ESP Procedure. Specifying a DOCLIB statement
allows you to use control and user description information, which are components of
ESPs job documentation feature.

Type ESP Procedure statement.

Syntax The syntax of the DOCLIB statement is:
DOCLIB dsname

dsname Indicates the name of the PDS where the job documentation
resides.

Usage notes A job documentation entry is a member of a partitioned data set (PDS). Each entry
consists of the following information:
Control information - information that ESP uses directly when processing a job,
such as the JCL library, job dependencies, and schedule frequency.
User description - other information you wish to store about a job. For example,
ABEND codes, messages, restart instructions, and so on.
You can retrieve job documentation information by the Consolidated Status Facility
(CSF), or the JOBINFO (JI) command.
You can access job documentation information directly from CSF with the following
commands. ESP retrieves the information from the data set identified by the
DOCLIB statement in an ESP Procedure.
BD - browse job documentation
ED - edit job documentation.
The DOCLIB statement can be used to specify the job documentation library you
want used throughout the ESP Procedure. For any job, the documentation library
member with the same name is accessed unless overridden with a DOCMEM
keyword for the job.
Multiple DOCLIB statements can be specified throughout an ESP Procedure.
Where the DOCLIB statements are placed determines where ESP looks to obtain job
documentation information. A DOCLIB statement applies to all jobs that follow it,
until a new DOCLIB statement occurs.
226
DOCLIB Statement, Continued

Related
Statements
For information on using job documentation, see the ESP Workload Manager Users
Guide.

Example 1 The following DOCLIB statement is used to identify the name of the job
documentation library:
APPL PAYROLL
DOCLIB CYBER.DOCLIB.CNTL
JOB PAYJOB1
JOB PAYJOB2
JOB PAYJOB3
ENDJOB
In the above example, ESP retrieves job documentation information from
CYBER.DOCLIB.CNTL for all jobs in the PAYROLL Application.

APPL PAYROLL
JOB PAYJOB4
JOB PAYJOB5
DOCLIB CYBER.ALT.DOCLIB.CNTL
JOB PAYJOB6
ENDJOB
In the above example, ESP retrieves job documentation information for jobs in the
PAYROLL Application as follows:
For PAYJOB4 and PAYJOB5, ESP looks in CYBER.DOCLIB.CNTL for job
documentation information
For PAYJOB6, ESP looks in CYBER.ALT.DOCLIB.CNTL for job
documentation information.

DJCNET PAYROLL
JOB PAYJOB7
JOB PAYJOB8
JOB PAYJOB9
ENDJOB
In the above example, ESP retrieves job documentation information from
CYBER.DOCLIB.CNTL for all jobs in a DJC network called PAYROLL.

227
DQ Command

Overview The DQ command is used to display the names of all or selected P-Node queues,
along with the number of jobs in each queue.


Authority OPER authority is required to issue the DQ command.

Syntax The syntax of the DQ command is:
DQ [QUEUE(pnodename],pnodename]...)]

pnodename Indicates the name or names of the P-Node to be displayed.
Several names can be specified, enclosed in parentheses and
separated by a blank or comma. The names can contain
asterisks and can end with a hyphen for a generic
specification.

Usage notes As an alternative to using the DQ command to display the P-Node queues, you can
use the Consolidated Status Facility (CSF) for monitoring and controlling jobs in
Applications.

Related
information
For information on displaying the names of the jobs in each queue, see the DN
command.
For information on the CSF, see the ESP Workload Manager Users Guide.

Example 1 The following DQ command displays all P-Node queues:
DQ
In the above example, all P-Node queues and the corresponding number of jobs in
each of those P-Node queues are displayed.
228
DQ Command, Continued

Example 2 The following DQ command displays a specific P-Node queue:
DQ QUEUE(EXEC)
In the above example, the EXEC (execution) P-Node is displayed, along with the
number of jobs in this P-Node queue.

Example 3 The following DQ command displays a specific P-Node queue:
DQ QUEUE(INPUT EXEC)
In the above example, the INPUT (input) and EXEC (execution) P-Nodes are
displayed, along with the number of jobs in these P-Node queues.

229
DSNAME Statement

Overview The DSNAME statement is used in conjunction with the DSTRIG workload object,
and is used to build a data set dependency at the job level into ESP Applications.
This statement can identify the creation, closure or renaming of a data set by a job,
started task, or TSO user.


Syntax The syntax of the DSNAME statement is:
DSNAME dsname
[JOBNAME(jobname)]
[RENAME]
[ANYCLOSE]
[COUNT(n)]

dsname Indicates the full name or generic prefix of a data set. A
generic prefix is specified by attaching a hyphen - to
the end of the name. The data set name should start with
the high-level index, because the current TSO data set
prefix is not used. Use of quotation marks is optional.
JOBNAME(jobprefix) Indicates the full name or generic prefix of a jobname.
A generic prefix is signified by a trailing hyphen -.
This can also be a TSO ID.
RENAME Indicates the trigger should occur if a data set is renamed
to dsname. The new data set name becomes the
triggering data set name.
ANYCLOSE Indicates the trigger should occur on any output closure
of the specified data set, rather than just the closure of a
newly created data set. If you do not use this parameter,
the trigger occurs only if the specified data set is created.
COUNT(n) Indicates the trigger should occur every n closures of the
specified data set, where n is a number from 0 - 255.
The default is 1.
230
DSNAME Statement, Continued

Usage notes The DSTRIG statement defines workload objects associated with an MVS data set
trigger. Within the scope of the DSTRIG workload object, the DSNAME statement
is used to describe the trigger.
If you use COUNT, the CSF STATUS field displays this value and the current
count.
Only one DSNAME statement is allowed per data set trigger object.
ESP does not complete a data set trigger object when the data set closes during the
abnormal termination of a task or job step.
You can use the JOB parameter to restrict the trigger to a specific job, started task or
TSO user. A batch job running under a user ID does not affect the trigger.
SMF records Data set triggering is based on the creation of certain SMF records. SMF record
types 14, 15 and 64 represent the closing of a data set.
Type 14 records are generated by the system when a non-VSAM data set is closed,
after it is opened for input. In such a case, the data set was only read by the opening
program, but not updated. No data set triggering should take place, and therefore
ESP ignores these records.
Type 15 records are generated when a non-VSAM data set is closed, after having
been opened for output. A new data set might have been created (DISP=NEW) or an
existing data set might have been rewritten or updated (DISP=OLD or MOD).
If ANYCLOSE was specified in the DSTRIG statement, the data set trigger object is
completed when a type 15 record is detected by ESP. If ANYCLOSE was not
specified, ESP checks to see if the type 15 record represents a new data set being
created. If so, the data set trigger object is completed. If an existing data set was
updated, the trigger does not take place.
Type 15 records are also generated when end-of-volume (EOV) processing takes
place. These records are ignored by ESP. ESP also ignores records pertaining to
VIO or temporary data sets.
Type 64 records are generated when a VSAM data set is closed or when EOV
processing takes place. As with type 15 records, EOV records are ignored. ESP
also ignores TCLOSE records (CLOSE TYPE=T) and records not pertaining to the
DATA component of a VSAM cluster.
Related
information
For information on data set triggering at the job level, see the DSTRIG statement.
For information on Application, see the ESP Workload Manager Users Guide.
For information on data set triggering at the Event level, see the ESP Workload
231

Example 1 The following example builds a job-level data set-trigger dependency:
APPL PAYROLL
JCLLIB CYB.JCL.CNTL
DSTRIG WAIT4.DLY
DSNAME PROD.DAILY.ACCNTS
RUN DAILY
REL PAYJOB2
JOB PAYJOB2
RUN DAILY
ENDJOB
In the above example, WAIT4.DLY is used to build a job-level dependency with the
closure of a newly created data set called PROD.DAILY.ACCNTS.

Example 2 The following example builds a job-level data set-trigger dependency:
APPL PAYROLL
JCLLIB CYB.JCL.CNTL
DSTRIG WAIT4.WKLY
DSNAME PROD.WEEKLY.ACCNTS ANYCLOSE
RUN DAILY
REL PAYJOB4
JOB PAYJOB4
RUN DAILY
ENDJOB
In the above example, WAIT4.WKLY is used to build a job-level dependency with
any closure of a data set called PROD.WEEKLY.ACCNTS.
232

Other examples Here are more examples using the DSNAME Statement.
Trigger occurs after every second closure of a data set:
DSNAME CYBER.CYCLES COUNT(2)
Trigger occurs when a data set is renamed to SYS1.TEMP.DATA:
DSNAME SYS1.TEMP.DATA RENAME
Trigger occurs when a generation is created:
DSNAME USER1.PAYROLL.G-
Trigger occurs when a generation is created by a specific job:
DSNAME USER1.PAYROLL.G- JOB(ABC)

233
DSTRDLY Command

Overview The DSTRDLY command is used to delay data set triggered Events or data set
trigger objects when data set activity occurs.


Authority OPER authority is required to issue the DSTRDLY command.

Syntax The syntax of the DSTRDLY command is:
DSTRDLY [nn|0]

nn Number of seconds to delay. The default is zero.

Usage notes Data set triggered Events or data set trigger objects may trigger too soon after a data
set has been closed. This parameter causes a global delay of data set triggers. For
example, a data set trigger may occur after a data set is created but prior to the data
set being cataloged.
This is normally coded as an ESP Initialization Parameter.
To display what the data set trigger delay value is currently set to issue the
DSTRDLY command with no operands.

Related
information
For information on data set triggering at the job level, see the DSTRIG or DSNAME
statements.

Example 1 The following DSTRDLY command displays the data set trigger delay value:
OPER DSTRDLY
In the above example, issuing DSTRDLY with no operand produces the following
display indicating that the current data set trigger delay value is set to zero:
DATASET TRIGGER DELAY VALUE CURRENTLY SET AT 0 SECONDS
234
DSTRDLY Command, Continued

Example 2 The following DSTRDLY command sets the data set trigger delay value:
DSTRDLY 15
In the above example, data set triggered Events or data set trigger objects are
delayed by 15 seconds.

235
DSTREXCL Command

Overview The DSTREXCL command is used to flag an entry in the Data set Trigger Exclude
list as invalid. These entries are not actually deleted from the list. Entries flagged
as inactive are converted to lowercase.


Authority OPER authority is required to issue the DSTREXCL command.

Syntax The syntax of the DSTREXCL command is:
DSTREXCL {pgmname}
[(pgmname[,pgmname]...)]

pgmname Indicates the name of a program to be flagged as no longer
part of the Data set Trigger Exclude list.

Usage notes The Data set Trigger Exclude list consists of a list of programs that are not eligible
for data set triggering. The DSTREXCL Initialization Parameter specifies these.
Once this list has been built, you use the DSTREXCL command to flag an entry in
the Data set Trigger Exclude list as invalid.

Related
information
For information on adding an entry to the Data set Trigger Exclude list, see the
DSTREXCL Initialization Parameter in the ESP Workload Manager Installation
Guide.
For information on displaying the Data set Trigger Exclude list, see the LDTREL
command.
236
DSTREXCL Command, Continued

Examples The following DSTREXCL Initialization Parameter indicates that a specific program
is not eligible for data set triggering:
DSTREXCL PGM999
Issue the LDTREL to display the Data set Trigger Exclude list:
DSTRIG exclude PGM=PGM999
To flag an entry in the Data set Trigger Exclude list as invalid, issue the following
DSTREXCL command from Page mode:
DSTREXCL PGM999
In the above example, PGM999 is flagged as being invalid. PGM999 is not actually
deleted from the list, its entry is converted to lowercase as follows:
DSTRIG exclude PGM=pgm999

237
DSTRIG Command

Overview The DSTRIG command is used to trigger an Event automatically by the creation,
closure or renaming of a data set by a job, started task or TSO user. Triggering can
be restricted to data sets created by a specific job or group of jobnames. Events can
also be made to wait for triggers from activity in more than one data set. ESP
accomplishes data set triggering by watching all SMF records generated by the
system. SMF record type 14, 15 and 64 are the records that represent the closing of
a data set.


Syntax The syntax of the DSTRIG command is:
DSTRIG dsname [JOB(jobname)]
[MULTIPLE]
[PRIMED]
[RENAME]
[ANYCLOSE]
[COUNT(n)]
[CURRENT(n)]

dsname Indicates the full name or generic prefix of a data set. A
generic prefix is specified by attaching a hyphen - to the end
of the name. You can use a hyphen only at the end of the
name. The data set name should start with the high-level
index, because the current TSO data set prefix will not be
used.
jobname Indicates the full name or generic prefix of a jobname. A
generic prefix is signified by a trailing hyphen -. This can
also be a TSO ID.
MULTIPLE Indicates closure of at least one other data set is needed to
trigger this Event. The Event does not execute until all
specified data set triggers are detected. MULTIPLE must be
specified on each DSTRIG command for the required data
sets.
PRIMED Indicates a data set trigger was already detected for this data
set. This parameter is used only when redefining an Event,
when one of the specified multiple data set triggers is already
detected.
RENAME Indicates the trigger should also occur if a data set is renamed
to the dsname specified. The new data set name becomes the
triggering data set name.
238
DSTRIG Command, Continued
Syntax (continued)
ANYCLOSE Indicates the trigger should occur on any output closure of the
specified data set, rather than just the closure of a newly
created data set. If you do not use this parameter, an Event is
triggered only if the specified data set is created.
COUNT Indicates the Event is to be scheduled for every n triggers,
where n is a number from 0 to 255. A value of 0 results in a
schedule for each trigger, as does a value of 1. It defaults to
1.
CURRENT Used with the COUNT parameter, it optionally sets the initial
trigger count. The value n can range from 0 to 255. It
defaults to 0.

Usage notes ESP does not trigger a data set triggered Event when the data set closes during an
abnormal termination of a task or job step. Allocating a partitioned data set in ISPF
or executing an IEFBR14 will also not satisfy a data set triggered Event.
The DSTRIG command is used to request that the Event is triggered on the creation
or closure of a data set. The trigger actually occurs at the time the data set is closed.
If multiple files in a step reference the data set, the trigger occurs only if the file
being closed is the one that specifies DISP=NEW.
Several DSTRIG commands can be specified for one Event, and each can maintain
separate counters. If the Event also contains SCHEDULE commands, executions
caused by the time schedules do not affect the DSTRIG counters. If you want an
Event to wait on both schedule criteria and data set close criteria, use the
HOLD/RELEASE Event definition commands or the data set triggering feature
within an ESP Application.
When an Event needs more than one data set closure to be eligible for execution, use
the MULTIPLE keyword on each corresponding DSTRIG command. Individual
data set closures are detected, but the Event does not execute until all other DSTRIG
commands with the MULTIPLE keyword also detect data set closures.
You can use the JOB parameter to restrict the trigger to a specific job, started task or
TSO user. A batch job running under a user ID does not affect the trigger.
239
SMF records

Type 14 records are generated by the system when a non-VSAM data set is closed,
after it is opened for input. In such a case, the data set was only read by the opening
program, but not updated. No data set triggering should take place, and therefore
ESP ignores these records.
Type 15 records are generated when a non-VSAM data set is closed, after having
been opened for output. A new data set might have been created (DISP=NEW) or an
existing data set might have been rewritten or updated (DISP=OLD or MOD).
If ANYCLOSE was specified in the DSTRIG statement, the Event is triggered when
ESP detects a type 15 record. If ANYCLOSE was not specified, ESP checks to see
if the type 15 record represents a new data set being created. If so, the Event is
triggered. If an existing data set was updated, the trigger does not take place.
Type 15 records are also generated when end-of-volume (EOV) processing takes
place. ESP ignores these records. ESP also ignores records pertaining to VIO or
temporary data sets.
Type 64 records are generated when a VSAM data set is closed or when EOV
processing takes place. As with type 15 records, EOV records are ignored. ESP
also ignores TCLOSE records (CLOSE TYPE=T) and records not pertaining to the
DATA component of a VSAM cluster.

Related
information
For information on displaying data set triggered Events, see the LDXE command.
For information on displaying data sets being checked for closures, creations or
renames, see the LDTE command.
statements.

Example 1 The following Event triggers upon any closure of a specific data set:
EVENT ID(CYB.PAYDLY)
DSTRIG PROD.PAYROLL.FILE123 ANYCLOSE
INVOKE CYB.ESP.PROCS(PAYDLY)
ENDDEF
In the above example, any closure of PROD.PAYROLL.FILE123 automatically
triggers this Event.
240

Example 2 The following Event triggers upon the creation of a data set:
EVENT ID(CYB.PAYWKLY)
DSTRIG PROD.PAYROLL.G- JOB(PAYJOB1)
SUBMIT CYB.JCL.CNTL(PAYWKLY)
ENDDEF
In the above example, when a generation of PROD.PAYROLL is created by
PAYJOB1, this Event is automatically triggered.

Example 3 The following Event triggers upon any closure of a specific data set and the creation
of another data set:
EVENT ID(CYB.PAYMTH)
DSTRIG PROD.PAYROLL.FILE999 ANYCLOSE MULTIPLE
DSTRIG PROD.PAYROLL.G- JOB(PAYJOB2) MULTIPLE
INVOKE CYB.ESP.PROCS(PAYMTH)
ENDDEF
In the above example, coding MULTIPLE on each DSTRIG command indicates that
this Event is not triggered until both of the following criteria have been met:
Any closure of PROD.PAYROLL.FILE999
PAYJOB2 creates a generation of PROD.PAYROLL.

Example 4 The following Event triggers every 255 closures of a specific data set:
EVENT ID(CYB.PAYBKUP)
DSTRIG PROD.ESP.COPYJCL ANYCLOSE COUNT(255)
INVOKE CYB.ESP.PROCS(PAYBKUP)
ENDDEF

Example 5 The following Event triggers when a data set is renamed:
EVENT ID(CYB.PAYMTH)
DSTRIG CYB.ESP.DATA RENAME
INVOKE CYB.ESP.PROCS(PAYMTH)
ENDDEF
In the above example, when a data set is renamed to CYB.ESP.DATA, this Event is
automatically triggered.
241
Example 6 The following Event triggers when a user closes a data set:
EVENT ID(PROD.POST)
DSTRIG CICS.WORLD.WIDE ANYCLOSE JOB(USERWK)
INVOKE PROD.ESP.PROCS(POST)
ENDDEF
In the above example, when USERWK closes the CICS.WORLD.WIDE data set, the
PROD.POST Event triggers. If, however, USERWK submits a job that closes the
data set, ESP uses the job name, not the user ID to determine if the Event should
trigger.
242
DSTRIG Statement

Overview The DSTRIG statement defines a workload object associated with an MVS data set
trigger and is used in conjunction with the DSNAME statement to build a data set
dependency at the job level into ESP Applications.


Syntax The syntax of the DSTRIG statement is:
{DSTRIG|DT} name[.qualifier]
[REQUEST]
[HOLD]
[CONDITIONAL]

name Indicates a workload object name in up to eight characters.
qualifier Indicates a workload object qualifier in up to eight
characters. It must immediately follow the workload object
name separated by a period.
REQUEST Indicates this is an on-request workload object.
HOLD Indicates the workload object is to be placed on manual
hold when ESP generates the Application. You can release
a workload object from manual hold using the CSF or the
APPLJOB (AJ) command. The object completes
automatically while in this state.
CONDITIONAL Indicates this workload object may or may not execute.
The Application this workload object belongs to is
considered complete when all NOCONDITIONAL
workload objects are complete.

Usage notes The DSTRIG statement defines a workload object that represents an MVS data set
trigger.
Use the DSNAME statement to identify the requirements of the data set trigger.
When these requirements are met, ESP completes the data set trigger object.
Only one DSNAME statement can be used per data set trigger workload object.
A data set trigger object can have a time dependency, or a predecessor dependency,
or it can be defined on hold. Each of these conditions prevents the data set object
from completing.
You can manipulate (for example holding and resetting the time) a data set trigger
object before it becomes ready (the dependencies are met). Once it is ready, the only
action you can take against it is complete.
243
DSTRIG Statement, Continued

Related
information
For information on data set triggering at the job level, see the DSNAME statement.
For information on Application, see the ESP Workload Manager Users Guide.
For information on displaying data set triggers, see the LDXE command.

Example 1 The following example builds a job-level data set trigger dependency:
APPL PAYROLL
JCLLIB CYB.JCL.CNTL
DSTRIG WAIT4.DLY
DSNAME PROD.DAILY.ACCNTS
RUN DAILY
REL PAYJOB2
JOB PAYJOB2
RUN DAILY
ENDJOB
In the above example, WAIT4.DLY is used to build a job-level dependency with the
closure of a newly created data set - PROD.DAILY.ACCNTS.

Other examples Here are more examples using the DSTRIG statement.
Indicates a conditional data set trigger object that does not need to complete for the
Application to complete:
DSTRIG FILEA CONDITIONAL
RUN DAILY
DSNAME CYBER.WEEKLY
ENDJOB
Indicates a time requirement for a data set trigger object. If the data set is created
prior to 6 pm, INPUT.DATA is not completed:
DSTRIG INPUT.DATA
RUN DAILY
DELAYSUB 6PM
DSNAME CYBER.BILLING
ENDJOB

244
DSTRST Command

Overview The DSTRST command is used to control data set triggering activity.


Authority OPER authority is required to issue the DSTRST command.

Syntax The syntax of the DSTRST command is:
DSTRST{[SUSPEND|RESUME]}
{[QUIESCE|RESTART]}
[LOG|NOLOG]

SUSPEND Suspends data set triggering. All data set triggers are ignored.
RESUME Indicates data set trigger processing is resumed. This is the
opposite of SUSPEND.
QUIESCE Indicates data set triggering is quiesced. Data set triggers are
detected but no action is taken until this command is issued
with the RESTART parameter.
RESTART Indicates data set triggering is restarted, and all detected
triggers processed. This is the opposite of QUIESCE.
LOG Activates data set trigger logging. A message is placed in the
audit log each time a data set is closed, and notifies you
which Event is triggered.
NOLOG Deactivates data set trigger logging.

Usage notes To display the status of data set triggering, issue the DSTRST command with no
operands.

Related
information
statements.

Example 1 The following DSTRST command displays data set trigger options:
OPER DSTRST
In the above example, data set trigger options are displayed.
245
DSTRST Command, Continued

Example 2 The following DSTRST command reactivates data set triggering:
OPER DSTRST RESUME LOG
In the above example, data set triggering is reactivated following a suspension.
Data set trigger logging is also activated.

246
DUEOUT Statement

Overview The DUEOUT statement is used to indicate a due out time for a job from one or
more stages in processing. If the job has not completed the specified stage in
processing by the due out time, the status field shows OVERDUE in the
Consolidated Status Facility (CSF) display of the job.


Syntax The syntax of the DUEOUT statement is:
DUEOUT pnodename
time

pnodename Indicates a P-Node for which you want to specify a due out
time. The P-Nodes are as follows:
INPUT - indicates the time when a job should start
EXEC - indicates the time when a job should complete
successfully. For links, tasks, and data set trigger objects,
EXEC represents the time when it should be marked
complete.
OUTPUT - indicates the time when the job should be
posted through output, if you are tracking through output.
Manual - indicates manually defined processing stages.
Note: The P-Nodes used with the DUEOUT statement differ
from CSF P-Nodes.
time The time the job is due out of the specified processing stage.
This can be specified in any format but must resolve to a single
date and time when the Application builds.
247
DUEOUT Statement, Continued

Usage notes The DUEOUT statement cannot be used outside the scope a job statement.
If the P-Node specified is not found in the jobs tracking model definition or, a P-
Node specified on the P-Nodes element, the due out time and P-Node are added to
the end of the P-Node list for this job. The most common p-Nodes used for a job in
an ESP Application are INPUT and EXEC.
The time parameter can request any time relative to the time the Application was
generated or DJC network submitted.
The DUEOUT statement overrides or sets the time by which this job should be
posted out of the P-Node named. If not posted by this time, a message is sent to the
operator and the job is listed in the overdue queue display (DN OVERDUE
command).
ESP can also send a message or trigger an Event when a job becomes overdue from
the INPUT or EXEC processing nodes using a NOTIFY statement.
The DUEOUT statement propagates dueout times upstream, i.e. to all predecessors
of the job where a DUEOUT statement is specified. These dueout times are set
relative to the average elapsed times according to the information obtained from
ESPs history file.

Related
information
For information on flagging a job as late for submission, see the LATESUB
statement.
For information providing notification on job status, see the ESP Workload Manager
Advanced Users Guide.

Example 1 The following DUEOUT statement indicates the time when a job is flagged as
overdue:
JOB PAYJOB1
DUEOUT EXEC 3AM
ENDJOB
In the above example, if PAYJOB1 has not successfully completed the execution
phase by 3 am, ESP flags it as overdue and the CSF shows OVERDUE in the Status
field for the job. The 3 am time is relative to the scheduled time of the Event. In
this example, if the Event is scheduled at 2 am, but is held up until 4 am, PAYJOB1
is overdue when the Application builds.
248

Example 2 The following DUEOUT statement indicates the time when a task is flagged as
overdue:
JOB WAIT4.TAPE TASK
DUEOUT EXEC NOW PLUS 2 HOURS
ENDJOB
In the above example, if WAIT4.TAPE is not marked complete 2 hours after the
scheduled time of the Event, it is flagged as overdue and the CSF shows OVERDUE
in the Status field for this task.

Example 3 The following DUEOUT statement indicates the time when a job is flagged as
overdue:
JOB PAYJOB2
DUEOUT EXEC REALNOW PLUS 30 MINUTES
ENDJOB
In the above example, if PAYJOB2 has not completed successfully 30 minutes after
the trigger time of the corresponding Event, it is flagged as overdue and the CSF
shows OVERDUE in the Status field for the job.

Example 4 The following DUEOUT and ALERT statements indicate the time when a job is
flagged as overdue, and that a message is sent to a user:
JOB PAYJOB3
NOTIFY OVERDUE USER(CYB01)
DUEOUT EXEC 7AM
ENDJOB
In the above example, if PAYJOB3 is not successfully complete by 7 am:
It is flagged as overdue and the CSF shows OVERDUE in the Status field for
the job
A message indicating that PAYJOB3 is overdue is sent to CYB01.
249

Example 5 The following DUEOUT and ALERT statements indicate the time when jobs within
an Application are flagged as overdue, and that an Alert Event is triggered:
APPL PAYROLL
NOTIFY OVERDUE ALERT(LATE)
JOB PAYJOB4
DUEOUT INPUT 7AM
RUN DAILY
RELEASE PAYJOB5
JOB PAYJOB5
DUEOUT EXEC 11AM
RUN DAILY
ENDJOB
In the above example, a globally-placed NOTIFY statement and job specific
DUEOUT statements are used to:
Indicate that if any job within the PAYROLL Application becomes overdue, it is
flagged as overdue and the CSF shows OVERDUE in the Status field for the job
Trigger an Alert Event associated with an identifier of LATE.
This technique is useful if you want to provide notification of job status on all jobs
within an Application, as the DUEOUT statement is not available outside the scope
of a job statement.
250
DURATION Statement
Overview The DURATION statement is used to tell ESP what duration to use for Critical Path.
Syntax The syntax of the DURATION statement is:
DURATION value
value Indicates the elapsed time estimate, in minutes, for a job.
Usage notes Situations may arise where you want to override historical elapsed times. For
example, on the last day of the month, a job on the critical path may run longer than
normal. Or maybe no historical information exists for a job on the critical path,
because this is the first run of the job. In these situations, you can override historical
elapsed time defaults (that ESP would normally use when calculating Critical Path)
by using the DURATION statement to specify an estimated duration for the job.
Example
The following example sets the elapsed time estimate for job A to 120 (minutes) on
the last day of the month:
JOB A
RUN WORKDAYS
IF TODAY(LAST DAY OF MONTH) THEN DURATION 120
ENDJOB
Related
Statements
For information on how to enable Critical Path analysis, see the CRITPATH
command.
For information on specifying Critical Path analysis on individual Applications, see
the CRITPATH Application statement.
For information on Critical Path analysis, see the ESP Workload Manager Users
Guide.
251
EARLYSUB Statement
Overview The EARLYSUB statement is used to specify a job for delayed (or early)
submission relative to the scheduled time of the Event. If the Event is not
scheduled, the delayed submission time is relative to the time the Application is
generated.
Syntax The syntax of the EARLYSUB statement is:
EARLYSUB criteria
criteria Schedule criteria that resolves to single date and time.
Usage notes Use the EARLYSUB statement within the scope of a JOB statement to request that a
job not be submitted until a specified time, even though its predecessors have
completed. This time parameter can request any date or time relative to the time the
Application was schedule or generated.
If you trigger an Event with a time/date in the past, ESP does not honor
EARLYSUB statements, except those that use the term REALNOW.
Although less commonly used, the EARLYSUB statement can be placed outside the
scope of any JOB statements (globally) to delay all jobs that are placed after that
globally placed EARLYSUB statement. Using this method sets a delayed
submission time for all jobs within the Application, except for those specifying the
EARLYSUB statement within the scope of the JOB statement. Jobs that have their
delayed submission time set as a result of a globally placed EARLYSUB statement
can have those delayed submission times reset only on a job by job basis, and not as
a group.
Jobs that are inserted into active Applications do not have delayed submission time
associated with them. If you want to insert a job into an active Application and
associate a delayed submission time with that job you will have to:
1. Insert the job on hold using the IJ CSF line command
2. Reset the jobs delayed submission time (Earliest submit time field)
3. Release the job using the A CSF line command.
252
EARLYSUB Statement, Continued
Related
Statements
Note: The DELAYSUB and EARLYSUB statements perform the same function.
For information on resetting time dependencies, see the ESP Workload Manager
Users Guide.
For information on manipulating jobs within Application or subApplications, see the
For information on specifying time dependencies, see the ESP Workload Manager
Users Guide.
Example 1 The following EARLYSUB statement sets the delayed submission time of a job:
APPL PAYROLL
JOB PAYJOB1
EARLYSUB 9PM
RUN WORKDAYS
ENDJOB
In the above example, PAYJOB1 has a delayed submission time of 9 pm relative to
the time the PAYROLL Application was generated.
Example 2 The following EARLYSUB statement sets the delayed submission time based on the
day of the week:
APPL PAYROLL
JOB PAYJOB2
EARLYSUB 9PM
IF TODAY(WEEKEND) THEN EARLYSUB 6PM
RUN DAILY
ENDJOB
In the above example, PAYJOB2 has a delayed submission time of:
9 pm on weekdays
6 pm on weekends.
253
EARLYSUB Statement, Continued

Example 3 The following EARLYSUB statement sets the delayed submission time based on the
day of the week:
APPL PAYROLL
EARLYSUB 4PM
JOB PAYJOB3
RELEASE PAYJOB4
ENDJOB
JOB PAYJOB4
RELEASE PAYJOB5
ENDJOB
JOB PAYJOB5
RELEASE PAYJOB6
ENDJOB
JOB PAYJOB6
EARLYSUB 4PM
ENDJOB
SELECT (PAYJOB3,PAYJOB4,PAYJOB5,PAYJOB6)
In the above example, all jobs in the PAYROLL Application have a delayed
submission time of 4 pm, with the exception of PAYJOB6 that has a delayed
submission time of 7 pm.

Other examples Here are more examples using the EARLYSUB statement.
Sets the delayed submission time to 10 minutes after the scheduled time of the
Event:
EARLYSUB NOW PLUS 10 MINUTES
Sets the delayed submission time to 10 minutes after the trigger time of the Event:
EARLYSUB REALNOW PLUS 10 MINUTES
Sets the delayed submission time to 10 pm two workdays from the scheduled time of
the Event:
EARLYSUB 10PM TODAY PLUS 2 WORKDAYS
Sets the delayed submission time to 11 pm on the last workday of the month, and to
9 pm on all other day that this job is submitted:
EARLYSUB 11PM
ELSE -
EARLYSUB 9PM

254
ECHO Command

Overview The ECHO command is used to echo data back to your terminal. You can use it to
test the symbols produced by GENTIME commands, symbolic variables, ESP
control language (CLANG) statements and ESP built-in functions. Issue the ECHO
command from page/line mode or from an ESP Procedure for testing purposes prior
to permanently storing symbolic variables.


Syntax The syntax of the ECHO command is:
ECHO character string

character string Any character string. Enclosed in quotes.

Usage notes The ECHO command cannot be issued from a system console.

Related
information
For information on generating customized date and time variables, see the
GENTIME command.
For information on symbolic variables, see the ESP Workload Manager Advanced
Users Guide.
For information on ESP built-in functions and ESPs control language (CLANG),
see the ESP Workload Manager Users Guide.

Example 1 The following ECHO command displays some of the symbols produced by a
GENTIME command:
GENTIME XX FIRST WORKDAY OF MONTH STARTING TODAY
ECHO %XXMM %XXDD %XXYY
In the above example, a set of date and time variables is generated with the prefix
XX, corresponding to the first workday of the month. The values of three of these
variables are then echoed back to your terminal.
255
ECHO Command, Continued

Example 2 The following ECHO command tests the value returned by a built-in function:
IF TODAY(LAST WORKDAY OF MONTH) THEN ECHO TRUE
ELSE ECHO FALSE
In the above example, if today is the last workday of the month, the character string
TRUE is echoed, else the string FALSE is echoed back to your terminal.

256
EICLASS Command

Overview The EICLASS command is used to control Event Initiator (EI) class definition and
manipulation. This allows different Events to have their own dedicated set of Event
initiators and provides a means of prioritizing Event and workload submission for
installations that trigger multiple Events at the same time.


Authority OPER authority is required to issue the EICLASS command.

Syntax The syntax of the EICLASS command is:
EICLASS [DISPLAY|SET|DELETE]
[CLASS(nnn)]
[MPL(nn)]

DISPLAY Displays the specified EI class settings. If DISPLAY, SET or
DELETE are not specified, this is the default. This keyword
has an alias of LIST.
SET Alter the specified EI class settings.
DELETE Delete the specified EI class. All TDRs queued to the deleted
class are moved to class 0.
CLASS Indicates the target EI class. nnn must be a number from 0 to
255. If DELETE is specified, nnn cannot be 0. If SET or
DELETE is specified, CLASS must be specified.
MPL Indicates the maximum number of initiators to be defined for
the specified class. nn is a value from 0 to 16. If SET is
specified, MPL must be specified. If DISPLAY is specified,
MPL is ignored.
257
EICLASS Command, Continued

Usage notes Define and manipulate Event initiator classes via Initialization Parameters and
commands. For each class, a dedicated set of Event initiators is defined.
EICLASS commands issued from Page mode are not retained across recycles of
ESP. To retain EICLASS settings across recycles, insert the EICLASS command(s)
in your Initialization Parameters.
For class 0, no explicit definition is required. If class 0 is not defined, it is created
automatically with an MPL of 1.
The Event initiator class is specified via the EICLASS keyword on the EVENT
statement. There is no panel support for the EICLASS keyword.
SAF authorization controls the use of Event initiator classes. For any non-zero class
specified on an Event, a SAF security check will occur. The requester must have
READ access to the resource EVENTINITCLASS.nnn resource in order to use the
Event initiator class nnn.
All Application generation for an Event is routed through the specified EICLASS. If
an Event initiator is not available and one cannot be created, the Event waits until an
initiator of the required class becomes available. If an Event is triggered for which
there is no defined class, it is routed through class 0.
The Application Manager also makes use of Event initiator classes for workload
submission. Optionally, JOBEND and STEPEND monitors can make use of Event
initiator classes if USERMOD 36 is active. USERMOD 36 allows JOBEND and
STEPEND monitor Events to honor non-zero Event initiator class requests.
The EICLASS keyword is available on both the LISTSCH and EVENT commands.

Related
information
For information on Event Streaming and the EICLASS Initialization Parameter, see
the ESP Workload Manager Installation Guide.
For information on Events, see the ESP Workload Manager Users Guide.
For information on defining Events, see the EVENT command.
For information on displaying scheduled Events, see the LISTSCH command.
For information on setting usermods, see the USERMOD Initialization Parameter in

Example 1 The following EICLASS command is used to set an Event initiator:
EICLASS SET CLASS(5) MPL(1)
In the above example, one Event initiator is set to class 5.
258
EICLASS Command, Continued
Example 2 The following example displays the EI class settings:
OPER EICLASS
Example 3 The following EICLASS commands set Event initiator classes:
One event initiator to class 0
One event initiator to class 5
One event initiator to class 10.

Example 4 The following EICLASS command sets an Event initiator class:
The following Event definition specifies an Event initiator class:
EVENT ID(CYBER.PAYROLL) EICLASS(99)
SCHEDULE 8PM WORKDAYS
INVOKE CYBER.PROCLIB.CNTL(PAYROLL)
ENDDEF
In the above example, CYBER.PAYROLL uses Event initiator 99, is scheduled at 8
pm each workday, and invokes the PAYROLL ESP Procedure.

259
EJECT Command

Overview The EJECT command is used to advance the output listing to a new page and is only
valid when the output is directed to a data set. If the output is routed to a terminal,
the EJECT command is ignored.


Syntax The syntax of the EJECT command is:
EJECT

Usage notes The EJECT command can be used in batch and with the HARDCOPY and
DEFPRINT commands.

Example 1 The following EJECT command advances output to a new page:
//ESPCMD JOB CYB3000,CLASS=A,MSGCLASS=X
//STEP001 EXEC PGM=ESP,PARM='SUBSYS(E510)',REGION=4M
//STEPLIB DD DSN=CYB2.ESP510Q.SSCPLINK,DISP=SHR
//SYSPRINT DD DSN=CYBER.COMMAND.OUTPUT,DISP=SHR
//SYSIN DD *
LIST LEVEL(CYBER.PAY-)
EJECT
LIST LEVEL(CYBER.MFG-)
/*
In the above example, two commands are issued in batch to list Events. The EJECT
command is used to display the payroll Events (CYBER.PAY-) and the
manufacturing Events (CYBER.MFG-) on separate pages.

260
ELSE Statement

Overview The ELSE statement is used in conjunction with an IF statement when the
expression that follows the IF statement returns a false value.


Syntax The syntax of the ELSE statement is:
ELSE action

ELSE Can only be used when IF and THEN statements have already
been specified. Defines the action to be taken when evaluation
of an IF statement returns a false value. To specify multiple
actions you must use the DO and ENDDO statements.
action Indicates the action that should be taken.

Usage notes When you use an IF statement, the expression that follows it must return a true or
false value. You can use any number of nested IF statements.
The THEN statement is used in conjunction with an IF statement when the
expression that follows the IF statement returns a true value.
If multiple action statements must be processed, you must begin and end compound
action statements with the DO and ENDDO language elements.
If you do not include an ELSE statement after an expression returning a false value,
ESP passes control to the next line.
If an ELSE statement continues to another line, use a line continuation character (
or +). If there is no continuation character, ESP ignores the ELSE statement.

Related
Statements
For information on conditionally processing an instruction or group of instructions,
see the IF and THEN statements.
Users Guide.
For information on advanced usage of ESPs Control Language, see the ESP
261
ELSE Statement, Continued

Example 1 The following logic is used to process different action statements:
IF %ESPADAY = MONDAY THEN -
SEND TODAY IS MONDAY U(CYB01)
ELSE -
SEND TODAY IS %ESPADAY U(CYB01)
In the above example, ESP determines if the actual day is equal to Monday. If the
evaluation of this expression is true, ESP sends a message to user CYB01 indicating
that today is Monday. If the evaluation of this expression is false, ESP sends a
message to user CYB01 indicating what day it is.

Example 2 The following logic is used to set the value of a user defined symbolic variable:
IF ESPSMM<5 THEN DO
GENTIME LAST TODAY LESS 1 YEAR
FINANCIAL_YEAR=%LASTYY%ESPSYY
ENDDO
ELSE DO
GENTIME NEXT TODAY PLUS 1 YEAR
FINANCIAL_YEAR=%ESPSYY%NEXTYY
ENDDO
In the above example, a user defined symbolic variable called
FINANCIAL_YEAR consists of two, 2digit year numbers, and is set as follows:
If the scheduled month is January, February, March or April, use last year
followed by this year
For any other month, use current year followed by next year.

262
END Command

Overview The END command is used to end the ESP terminal session or batch execution.


Syntax The syntax of the END command is:
END

Usage notes To access ESP in Line mode, enter either of the following:
TSO ESP SUB(subsys)- from the ISPF command line, where subsys is the
ESP subsystem name
@LINEMD - from within Page mode
Enter END when you have finished with ESP in Line mode for that particular
session.

Related
information
For information on accessing ESP as a program in TSO, see the ESP Workload

Example 1 To access the ESP in Line mode enter the following from the ISPF command line,
where SUB specifies the ESP subsystem name:
Command ===> TSO ESP SUB(E510)
Once in Line mode, enter ESP commands as required:
--> LDSN
CHECKPOINT: CYB2.ESP510.CKPT, ALT NONE
USERDEF: CYB2.ESP510.USERDEF, BKUP NONE
INDEX: CYB2.ESP510.INDEX, BKUP NONE
JOBINDEX: CYB2.ESP510.JOBINDEX
QUEUE: CYB2.ESP510.QUEUE, ALT NONE
TRAKFILE: CYB2.ESP510.TRAKFILE
EVENTSET: CYB2.ESP510.EVENT1
HISTFILE: CYB2.ESP510.HISTFILE
APPLFILE: CYB2.ESP510.APPLFILE
JTDT: CYB2.ESP510.PARMLIB(JOBDEF1)
UPDT: CYB2.ESP510.PARMLIB(PROFILE)
--> END
In the above example, system data sets allocated to ESP are displayed (LDSN).
Enter END to terminate this Line mode session.

263
ENDDEF Command

Overview The ENDDEF command is used to end an Event definition.


Syntax The syntax of the ENDDEF command is:
ENDDEF

Usage notes If the ENDDEF command is omitted when creating an Event, ESP adds this omitted
command.

Related
information
For information on defining Events, see the EVENT command.

Example 1 The following is an example of an Event definition:
SCHEDULE DAILY AT 8AM
INVOKE CYB.ESP.PROCS(PAYROLL)
ENDDEF
The definition begins with the EVENT command and the Events name
The SCHEDULE command tells ESP when to schedule the Event
The INVOKE invokes an ESP Procedure
The ENDDEF command indicates the end of the definition.

264
ENDDO Statement

Overview The ENDDO statement is used to identify the end of one or more action statements.


Syntax The syntax of the ENDDO statement is:
ENDDO

Usage notes Use the ENDDO statement in conjunction with the DO statement to indicate the end
of a set of action statements.

Related
Statements
For information on identifying the start of a set of compound action statements, see
the DO statement.
Users Guide.

set of action statements:
IF X = BILLING THEN DO
SEND BILLING JOB WILL RUN TODAY CN(01)
INVOKE CYBER.PROCLIB.CNTL(BILLING)
ENDDO
In the above example, if the value of a variable called X is equal to BILLING:
A message is sent to the console
The BILLING Application is invoked.
265
ENDDO Statement, Continued

Example 2 The following DO and ENDDO statements indicate a set of action statements:
APPL PAYROLL
JOB PAYJOB1
RUN WORKDAYS
DO
DELAYSUB 4PM
LATESUB 5PM
ENDDO
ENDJOB
In the above example, if today is Monday, PAYJOB1s delayed submission time is
set to 4 pm, and its late submission time is set to 5 pm.
266
%ENDEXCL Statement

Overview The %ENDEXCL statement is used to end the exclusion of JCL or to end the
exclusion of control statements from a symbolic variable library.

Type ESP control statement used in JCL, symbolic variable library statement.

Syntax The syntax of the %ENDEXCL statement is:
%ENDEXCL

Restriction The %ENDEXCL statement cannot be used in ESP Procedures.

Usage notes The %ENDEXCL statement must start in Column 1. If you want to include a
statement with the characters %ENDEXCL starting in column 1, but to have it
treated as data rather than a control statement, code %%ENDEXCL. The first
percent sign is removed.
Note: Before using the %ENDEXCL statement, check with your system
administrator to ensure no changes were made during your ESP installation that
affect the way ESP recognizes these statements. For example, another product may
make conflicting use of these terms, in which case your system administrator can
change them.

Related
information
For information on selectively excluding JCL and DATA, see the %EXCLUDE
statement.
For information on selectively including JCL and DATA, see the %INCLUDE
statement.
Example 1 The following %EXCLUDE statement used in a symbolic variable library ends the
exclusion of data on Mondays:
%EXCLUDE DAY(MONDAY)
PARM=ABC
%ENDEXCL
In the above example, the symbol PARM does not take on the value of ABC on
Mondays.
267
%ENDEXCL Statement, Continued

Example 2 The following %EXCLUDE statement used in JCL ends the exclusion of a DD
statement on Mondays:
//INPUT05 DD DSN=CYBER.INPUT.DATA,DISP=SHR
%ENDEXCL
In the above example, the DD statement INPUT05 is excluded on Mondays.

268
ENDHC Command

Overview The ENDHC command is used to stop routing of output as specified by a
HARDCOPY command.


Syntax The syntax of the ENDHC command is:
ENDHC

Usage notes The ENDHC command is only available in Line mode or Page mode.
When ESP encounters the ENDHC command, it stops writing output data to a data
set, DD file or SYSOUT class.

Related
information
For information on routing command output, see the HARDCOPY command.

Example The following is an example of routing command output:
HARDCOPY DATASET(CYB.COMMAND.OUTPUT(DATA))
GENTIME AA TODAY
GENTIME BB TODAY PLUS 2 WORKDAYS
GENTIME CC LAST WORKDAY OF MONTH STARTING TODAY
ENDHC
The HARDCOPY command tells ESP to route command output to a member of
a PDS
Three GENTIME commands are issued to created customized date and time
variables
The ENDHC command indicates that ESP is to stop the routing of command
output.

269
%ENDINCL Statement

Overview The %ENDINCL statement is used to end the inclusion of JCL or to end the
inclusion of control statement(s) from a symbolic variable library.


Syntax The syntax of the %ENDINCL statement is:
%ENDINCL

Usage notes The %ENDINCL statement cannot be used in ESP Procedures.
The %ENDINCL parameter must start in Column 1. If you want to include a
statement with the characters %ENDINCL starting in column 1, but to have it
treated as data rather than a control statement, code %%ENDINCL. The first percent
sign is removed.
Before using the %ENDINCL statement, check with your system administrator to
ensure no changes were made during ESP installation that affect the way ESP
recognizes these statements. For example, another product may make conflicting
use of these terms, in which case your system administrator can change them.

Related
information
statement.
For information on selectively including JCL and DATA, see the %INCLUDE
statement.
Example 1 The following %ENDINCL statement used in a symbolic variable library ends the
inclusion of data on Mondays:
%INCLUDE DAY(MONDAY)
PARM=ABC
%ENDINCL
In the above example, the PARM takes on the value of ABC on Mondays.
270
%ENDINCL Statement, Continued

Example 2 The following %ENDINCL statement used in JCL ends the inclusion of a DD
%ENDINCL
In the above example, DD statement INPUT05 is included on Mondays.

271
ENDJOB Statement

Overview The ENDJOB statement is used to indicate the end of a job definition. It is not
required to end every JOB statement with an ENDJOB statement, but it is required
to use an ENDJOB statement after defining all of your jobs and when using
statement at a global level between jobs.


Syntax The syntax of the ENDJOB statement is:
ENDJOB

Usage notes The scope of the JOB statement includes all statements up to an ENDJOB statement
or the next JOB statement. ESP processes commands based on where they are
placed within an Application as follows:
ESP processes commands outside the scope of JOB statements when the
Application is generated and every time a job becomes eligible (i.e. all
dependencies met)
ESP processes commands within the scope of a JOB statement only when the
job becomes eligible (i.e. all dependencies met)
Statements placed within the scope of a job are referred to as job specific
statements; whereas statements placed outside the scope of a job statement are
referred to as global statements.

Related
Statements
For information on identifying the name of a job in an Application, see the JOB
statement.
For information on identifying jobs, see the ESP Workload Manager Users Guide.

Example 1 The following ENDJOB statements are used to end two job definitions:
APPL PAYROLL
JOB PAYJOB1
RUN DAILY
RELEASE PAYJOB2
ENDJOB
JOB PAYJOB2
RUN DAILY
ENDJOB
In the above example, the first ENDJOB statement is used to indicate the end of the
job definition for PAYJOB1. The second ENDJOB statement is used to indicate the
end of the job definition for PAYJOB2.
272
ENDJOB Statement, Continued

Example 2 The following ENDJOB statement is used to end job definitions:
APPL PAYROLL
JOB PAYJOB1
RUN DAILY
RELEASE PAYJOB2
JOB PAYJOB2
RUN DAILY
ENDJOB
In the above example, the ENDJOB statement is used to indicate the end of all
defined jobs within the PAYROLL Application.

273
ENDMODEL Command

Overview The ENDMODEL command is used to end the model definition mode and invokes
the MODEL generation processor.

Type Model command.

Syntax The syntax of the ENDMODEL command is:
ENDMODEL

Related
information
For information on how ESP processes workload in your environment, see the ESP
For information on beginning the model process, see the MODEL command.

Example 1 The following is an example of a model definition:
DEFPRINT XREF DDNAME(MODEL1)
MODEL CYBER.SAD -
START('4PM TODAY ENDING 4PM TODAY PLUS 5 DAYS')
MAXINITS 8
INIT START(1:8) CLASS(A,B,C,D)
MREPORT XREF JR1 FROM('4PM TODAY ENDING 4PM TOMORROW)
ENDMODEL
ENDPRINT XREF
The DEFPRINT command directs output to a DD name
The MODEL command invokes the model processor
The MAXINITS and INIT commands define initiators
The MREPORT command selects the modeling report to be generated
The ENDMODEL command ends the model definition and invokes the MODEL
generation processor
The ENDPRINT command creates a report.

274
ENDPRINT Command

Overview The ENDPRINT command is used to close each of the report data files opened with
the DEFPRINT command.


Syntax The syntax of the ENDPRINT command is:
ENDPRINT reptname

reptname A one to eight-alphanumeric character logical report name.

Usage notes The report name ended by the ENDPRINT command is assigned on the DEFPRINT
command.

Related
information
For information on defining a report file, see the DEFPRINT command.

Example The following is an example of a model definition:
MODEL CYBER.SAD.DATA -
MAXINITS 8
MREPORT XREF JR1 FROM('4PM TODAY ENDING 4PM TOMORROW)
ENDMODEL
ENDPRINT XREF
In the above:
The DEFPRINT command directs output to a DD name. The logical report name
is XREF.
The MODEL command invokes the model processor.
The START, MAXINITS, INIT START and MREPORT model statements
define the model.
The ENDMODEL command ends the model definition and invokes the MODEL
generation processor.
The ENDPRINT command closes the logical report called XREF and ESP
creates the report.

275
ENDR Command

Overview The ENDR command ends a history report definition and starts the report generation
phase.


Syntax The syntax for the ENDR command is:
ENDR

Related
information
For information on beginning a report definition, see the REPORT command.
For information on history reports, see the ESP Workload Manager Users Guide.

Example 1 The following is an example of a history report definition:
REPORT
FROM 7AM YESTERDAY
DISPLAY JOBNAME JOBNO APPLSYS CMPC
ENDR
The REPORT command invokes the report processor
The FROM, CRITERIA and DISPLAY report statements define the report
The ENDR command ends the report definition and initiates report generation.

276
ENDTEMPL Statement

Overview The ENDTEMPL statement is used to indicate the end of a template definition.


Syntax The syntax of the ENDTEMPL statement is:
ENDTEMPL

Related
information
For information on working with templates, see the ESP Workload Manager
For information on defining templates, see the TEMPLATE statement.

Example 1 The following ENDTEMPL statement is used to indicate the end of a template
definition:
APPL PAYROLL
TEMPLATE PRTJOBS (1,JOBNAME)
JOB %JOBNAME
RUN DAILY
ENDJOB
ENDTEMPL
PRTJOBS PAYJOB1
PRTJOBS PAYJOB2
PRTJOBS PAYJOB3
In the above example, the PAYROLL Application is defined using a template called
PRTJOBS. The ENDTEMPL statement ends the PRTJOBS template definition.

277
ESP Statement

Overview The ESP statement is used to issue any ESP command from within an ESP
Procedure.


Syntax The syntax of the ESP statement is:
ESP command

command Any valid ESP command.

Usage notes As part of an Application you may want to issue ESP commands. This is useful, for
example, when you want to manipulate jobs, trigger Events, and perform displays.
Use the ESP or ESPNOMSG statement in an Application to issue an ESP command.
ESPNOMSG suppresses responses from the command.

Related
Statements
For information on issuing ESP commands and having the response from the
command suppressed, see the ESPNOMSG statement.

Example 1 The following ESP statement is used to trigger an Event:
JOB TRIGGER.EVENT LINK PROCESS
RUN DAILY
ESP TRIGGER CYBER.ACCTJOB ADD
ENDJOB
In the above example, the TRIGGER.EVENT link issues an ESP command to
trigger an Event called CYBER.ACCTJOBS.
278
ESP Statement, Continued

Example 2 The following ESP statement is used to complete a task when a resource is
available:
APPL PAYROLL
JOB WAIT4.CICS TASK
RUN ANY
RELEASE PAYJOB1
RESOURCE (1,CICS)
ESP AJ WAIT4.CICS COMPLETE APPL(WAIT4.0)
ENDJOB
JOB PAYJOB1
RUN ANY
ENDJOB
In the above example, when a resource called CICS becomes available, ESP issues
an APPLJOB command to complete a task called WAIT4.CICS. After
WAIT4.CICS completes PAYJOB1 is released.

Example 3 The following ESP statements are used to insert a job into an Application, and to
complete a task:
APPL PAYROLL
JOB PAYJOB1
RUN DAILY
RELEASE INSERT.JOB
JOB INSERT.JOB LINK PROCESS
RUN DAILY
ESP AJ PAYJOB99 INSERT APPL(BILLING.0)
ENDJOB
In the above example, when PAYJOB1 successfully completes, an ESP command is
issued to insert PAYJOB99 into the current generation of the BILLING Application.

279
ESPCOM Command
Overview The ESPCOM command is used to display and control ESP communications activity
between the ESP Agents and ESP Workload Manager.
Authority OPER authority is required to issue the ESPCOM command.
Syntax The syntax of the ESPCOM command is:
ESPCOM {LIST} [DEST(agentname)]
{QUIESCE}
{RESTART}
{FLUSH}
LIST Lists the attributes of the COMMQ checkpoint data set in use.
This is the default. When the DEST keyword is included, the
status of the specified Agent is also displayed.
DEST Use to specify an individual Agent.
agentname Name of the target Agent you want to view or manipulate.
QUIESCE Use with the DEST keyword to QUIESCE an individual
Agent.
RESTART Use with the DEST keyword to RESTART an individual
Agent.
FLUSH Use with the DEST keyword to purge all pending messages
for each specified Agent.
Example The following is an example of the response from the default ESPCOM command:
OPER ESPCOM
CommQ data set name: CYBER.ESP.ESPCOMQ
size: 1474560 bytes
used: 320 bytes
1 senders are defined, 0 of them quiesced
280
ESPCTR Command

Overview The ESPCTR command is used to display ESP internal activities relating to Events,
Applications and jobs. These counters represent the activity for this ESP system
only. No counts are shown for any ESP slave systems or any other remote ESP
systems.


Authority OPER authority is required to issue the ESPCTR command.

Syntax The syntax of the ESPCTR command is:
ESPCTR [RESET]

Usage notes Use the ESPCTR command to display statistics on Applications completed or
created, Events executed, and jobs submitted. These activities are measured in the
following intervals: this year, this month, this day, since the last ESP start.
An ESP cold start or the ESPCTR RESET command resets all the values to zero.

Related
information
For information on displaying ESP internal activities from the ESP Main Menu, see
the USE command.
281
ESPCTR Command, Continued

Example 1 The following ESPCTR command displays usage statistics:
OPER ESPCTR
APPCMP 499,499,13,143
APPCRE 737,737,27,211
EVXEQ 2220,2220,43,594
JOBSUB 1190,1190,13,365
APPCMP refers to the number of Applications completed
APPCRE refers to the number of Applications created
EVEXQ refers to the number of Events executed
JOBSUB refers to the number of jobs submitted by ESP.
The statistics are listed in the following order (from left to right): this year, this
month, this day, since last ESP start.
Note: Entering USE from the ESP main menu produces the identical statistics to
that of the ESPCTR command (above), only formatted differently.
ESP ---------------------------------- Usage ----------------- Row 1 to 4 of 4
Command ===> Scroll ===> PAGE

This This This Since Last
Activity Year Month Day ESP Start
------------------------------------------------------------------------------
Applications completed 499 499 13 143
Applications created 737 737 27 211
Events executed 2220 2220 43 594
Jobs submitted 1190 1190 13 365
******************************* Bottom of data *******************************
282
ESPNOMSG Statement

Overview The ESPNOMSG statement is used to issue any ESP command from within an ESP
Procedure and suppress responses from the command. Warnings and errors
responses are not suppressed.


Syntax The syntax of the ESPNOMSG statement is:
ESPNOMSG command

command Any valid ESP command.

Usage notes When most commands execute, they issue some kind of response. This response is
routed to the user who owns the Event. To reduce message clutter, the ESPNOMSG
statement can by used to suppress responses, unless a severe error occurs.
As part of an Application, you may want to issue ESP commands. This is useful, for
example, when you want to manipulate jobs, trigger Events, and perform displays.
Use the ESP or ESPNOMSG statement in an Application to issue an ESP command.
ESPNOMSG suppresses responses from the command.

Related
Statements
For information on issuing ESP commands, see the ESP statement.

Example 1 The following ESPNOMSG statement is used to trigger an Event:
JOB TRIGGER.EVENT LINK PROCESS
RUN DAILY
ESPNOMSG TRIGGER CYBER.ACCTJOB ADD
ENDJOB
In the above example, the TRIGGER.EVENT link issues an ESP command to
trigger an Event called CYBER.ACCTJOB. The response from the ESP command
(i.e. EVENT TRIGGERED) is suppressed as a result of specifying ESPNOMSG in
front of the ESP TRIGGER command.
283
ESPNOMSG Statement, Continued

Example 2 The following ESPNOMSG statement is used to complete a task when a resource is
available:
APPL WAIT4
JOB WAIT4.CICS TASK
RUN ANY
RELEASE PAYJOB1
RESOURCE (1,CICS)
ESPNOMSG AJ WAIT4.CICS COMPLETE APPL(WAIT4.0)
ENDJOB
JOB PAYJOB1
RUN ANY
ENDJOB
In the above example, when a resource called CICS becomes available, ESP issues
an APPLJOB command to complete a task called WAIT4.CICS. After
WAIT4.CICS completes, PAYJOB1 is released. The response from the ESP
command is suppressed as a result of specifying ESPNOMSG.

Example 3 The following ESPNOMSG statements are used to insert a job into an Application,
and to complete a task:
APPL PAYROLL
JOB PAYJOB1
RUN DAILY
RELEASE INSERT.JOB
JOB INSERT.JOB LINK PROCESS
RUN DAILY
ESPNOMSG AJ PAYJOB99 INSERT APPL(PAYROLL.0)
ENDJOB
In the above example, when PAYJOB1 successfully completes, an ESP command is
issued to insert PAYJOB99 into the current generation of the PAYROLL
Application. The response from the ESP command is suppressed as a result of
specifying ESPNOMSG.

284
//*ESPSYMBOL Statement

Overview The //*ESPSYMBOL statement is used to change the symbol introducer character,
normally the percent sign (%). The symbol introducer is the character that identifies
symbolic variables to ESP.
Using the //*ESPSYMBOL statement in JCL you can change the symbol introducer
character to identify another character as the symbol introducer character.
Additionally, changing the symbol introducer character allows you to use the
percent sign (%) in your JCL and not have ESP interpret the percent sign (%) as the
symbol introducer character.

Type ESP control statement used in JCL.

Syntax The syntax of the //*ESPSYMBOL statement is:
//*ESPSYMBOL symbol

symbol Any single alphanumeric or national character.

Restriction The //*ESPSYMBOL statement is only available in JCL.

Usage notes Place the character you want to use as the symbol introducer character in column 14,
separated from the //*ESPSYMBOL statement by a single blank.
If the symbol introducer character is changed, the change remains in effect:
For the rest of the job during Application process mode, i.e. other jobs are not
affected
Until ESP encounters another //*ESPSYMBOL statement.
If an individual member contains multiple jobs, the change remains in effect for all
jobs within that individual member.

Related
information
For information on changing the symbol introducer using an ESP Initialization
Parameter, refer to the SYMBOL statement in the ESP Workload Manager
Installation Guide.
285
//*ESPSYMBOL Statement, Continued

Example 1 The following //*ESPSYMBOL statement used in JCL sets the symbol introducer
character:
//*ESPSYMBOL ?
//PAYJOB1 JOB CYB,CLASS=A,MSGCLASS=0
?INCLUDE DAY(MONDAY)
//STEP001 EXEC PGM=PGM1,PARM=DATE=?ESPSYY?ESPSDDD
?ENDINCL
In the above example, the symbol introducer character is changed from a % to a ?.
Subsequent symbol variables reference the ? as the symbol introducer character, and
therefore include STEP001 on Mondays.

Example 2 The following //*ESPSYMBOL statements used in JCL set and reset the symbol
introducer character:
//*ESPSYMBOL #
#INCLUDE IF(TODAY(LAST WORKDAY OF MONTH))
//STEP001 EXEC PGM=PGM1,PARM=DATE=#ESPSYY#ESPSDDD
#ENDINCL
//*ESPSYMBOL %
//STEP02 EXEC PGM=PGM2,PARM=%ESPAHH%ESPAMN
In the above example, the symbol introducer character is changed from a % to a #.
Subsequent symbol variables reference the # as the symbol introducer character, and
include STEP001 on last workday of the month. The symbol introducer character is
then reset to a % to avoid JCL errors in later steps that refer to the % as the symbol
introducer character.

286
EVENT Command

Overview The EVENT command is used to start an Event definition.


Syntax The syntax of the EVENT command is:
EVENT ID(eventid) [ADD|REPLACE]
[CLASS(classname)]
[SYSTEM(sysid)]
[AUTODELETE]
[HOLD(count)]
[SUSPEND(count)]
[MAXPEND(nn)]
[OWNER(userid)
[INHERIT_TRIGGER_USER]
[EICLASS(eiclassname)]

eventid Is the name of the Event. The name can be in the form
gggg.dddd, or dddd alone. Here gggg is the user/group prefix
and dddd is the descriptive name. If the prefix is omitted, the
prefix set by the GROUP command takes effect. If the Event
ID is specified in the label field, the prefix should be omitted.

Both the prefix and the descriptive name should consist of
alphanumeric characters, the first of which must be
alphabetic. The descriptive name may also contain the
underscore _ as an alphabet extender. The prefix can be up
to eight characters long, while the descriptive name has a
maximum length of 16 characters.
ADD Indicates this is a new Event. If one already exists with the
same name, the new definition is ignored. This is the default.
REPLACE Indicates this is a new Event. If one already exists with the
same name, it is to be replaced.
classname Defines to which logical ESP class the Event will belong. If
this is omitted, the Event name prefix is used as a class name
(up to eight characters).
287
EVENT Command, Continued
Syntax (continued)
sysid Indicates the ID of the ESP system to execute the
Event. You may use asterisks or a hyphen for
masking. If this parameter is omitted, the current
system is used. To specify that the Event may
execute on any one of the systems available, use
SYSTEM(-). If the Event invokes an Application,
this should specify the ESP system identifier of the
master.
AUTODELETE Indicates if any members of a PDS required for job
submission is not found, (or in the case of
PANVALET, is disabled), an error condition is not
raised. This means that ESP continues to process the
Event as long as at least one of the data sets required
for submission of the job is available. However, if all
the SUBMIT commands within an Event definition
specify deleted or disabled members, then the Event
is deleted from the schedule. This is not the default.
HOLD Indicates the Event is placed initially in the held state.
Refer to the HOLD command General.
SUSPEND Indicates the Event is placed initially in the
suspended state. Refer to the SUSPEND command
General.
count Sets HOLD or SUSPEND count. If not specified, the
default is 1.
MAXPEND(nn) Indicates the maximum number of pending signals for
the Event.
OWNER(userid) Indicates the owner of the Event. If this parameter is
not specified, the last user to modify the Event
becomes the owner. Ownership in a SAF
environment affects only which TSO user gets the
failure messages.
USER(userid ) Indicates an overriding RACF user ID for the Event.
When the Event executes, it automatically takes on
the security attributes of the OWNER. Normally if
this parameter is not specified, the last user to modify
the Event in a non-SAF environment, or the Event
high-level qualifier in a SAF environment, becomes
the owner.
INHERIT_TRIGGER_USER Indicates the user ID of the user triggering the Event
should be used for job submission. When the Event
executes, it automatically takes on the security
attributes of the user ID triggering the Event. It
overrides any USER() value. This can be abbreviated
to ITU.
288
Syntax (continued)
EICLASS(eiclassname) Indicates the Event initiator class, which allows
prioritization of Events and workload submission.
SPECIAL authority is required to use this parameter
in a non-SAF system. With SAF, you need READ
access to EVENTCLASS.nnn.

Usage note To specify OWNER(user), the person attempting to create or update the Event must
have SPECIAL or ANY authority in a non-SAF system, and READ access to
prefix.SETOWNER.user in a SAF system. This is in addition to having update
access to the Event. If either authority is missing, the define/update request fails.
Browse or edit generates the OWNER keyword if it was used when the Event was
previously saved. The user may remove the operand and save the Event, in which
case ownership reverts to the users own id.
To specify USER(user), the person attempting to create or update the Event must
have SPECIAL authority in a non-SAF system, and READ access to
prefix.RACID.user in a SAF system. This is in addition to having update access to
the Event. If either authority is missing, the definition or update request fails.
Browse or edit generates the USER keyword if it was used when the Event was
previously saved. The user may remove the operand and save the Event, in which
case the user ID reverts to the high level qualifier. If INHERIT_TRIGGER_USER is
in effect for the Event, or at the system level (RACROUTE parameter), that user ID
supersedes the one in the Event if the Event is executed as a result of a TRIGGER
command (as opposed to being scheduled). The EVENTSAF user exit may override
any ESP-selected user ID.
It is possible to specify both OWNER and USER for the same Event, in which case
the defining user must have UPDATE access to the Event, and READ access to
prefix.SETOWNER.user, and READ access to prefix.RACID.user. If any one of
those checks fails, the definition request fails.
You can also define Events using ESPs ISPF interface - Option E.2 from the ESP
main menu.

Related
information
For information on ending an Event definition, see the ENDDEF command.
For information on deleting an Event definition, see the DELETE command.
For information on Event initiators, see the ESP Workload Manager Installation
Guide.
289

EVENT ID(CYBER.PAY1)
SCHEDULE 8AM DAILY
INVOKE CYBER.ESP.PROCS(PAY1)
ENDDEF
The EVENT command starts the Event definition
The SCHEDULE and INVOKE Events statements define the Event
The ENDDEF command ends the Event definition.
290

EVENT ID(CYBER.PAY2) REPLACE SUSPEND OWNER(FRED)
SCHEDULE 9AM DAILY
ENDDEF
The EVENT command starts the Event definition.
The REPLACE parameter is needed to replace the Event definition when it is
updated, if one already exists with the same name.
The SUSPEND parameter indicates that the Event is to be placed in a suspended
state. It does not execute until resumed.
The OWNER parameter indicates that FRED is the owner of the Event.
The SCHEDULE and INVOKE Events statements define the Event.

EVENT ID(CYBER.PAY3) SYSTEM(E510) CLASS(PROD) ITU
SCHEDULE 9AM DAILY
ENDDEF
The EVENT command starts the Event definition.
The SYSTEM parameter indicates the system where this Event is to execute.
The CLASS parameter indicates to which logical group this Event belongs.
The ITU parameter indicates that the user ID of the user triggering this Event
should be used for batch submission. This user ID applies only when the Event
is manually triggered.
The SCHEDULE and INVOKE Events statements define the Event.
EVENT ID(CYBER.PAYROLL) EICLASS(99)
INVOKE CYBER.PROCLIB.CNTL
ENDDEF
In the above example, an Event initiator class of 99 is assigned to
CYBER.PAYROLL.
291
EVENTOPT Command
Purpose The EVENTOPT command is used to allow or disallow the issue of Write to
Operator (WTO) operations from within an Event. EVENTOPT also allows or
disallows the use of system commands from within an Event. EVENTOPT is
normally used as an Initialization Parameter.
Authority OPER authority is required to issue the EVENTOPT command.
Syntax The syntax of the EVENTOPT command is:
EVENTOPT [WTO|NOWTO]
[VS|NOVS]
WTO Allows Write to Operator from within an Event. This is the
default
NOWTO Disallows Write to Operator from within an Event.
VS Allows the use of MVS commands from within an Event.
NOVS Disallows the use of MVS commands from within an Event.
Usage notes The EVENTOPT command supersedes the EVENTWTO command.
If you specify no operands with the EVENTOPT command, the current status is
displayed.
Related
information
Example 1 This following EVENTOPT command indicates Event restrictions:
EVENTOPT NOWTO NOVS
In the above example, neither WTOs nor system commands are allowed from within
an Event.
292
EVENTSET Command
Overview The EVENTSET command is used to define or alter the definition of an Event data
set.
Authority OPER authority is required to issue the EVENTSET command.
Syntax The syntax of the EVENTSET command is:
EVENTSET eventdsid
[DSNAME(dsname)]
[NEWDSNAME(newdsname)]
[BACKUPDSNAME(backupdsname)|NOBACKUPDSNAME]
[SCANTIME(schedule)]
[DEFINE|DELETE|OPEN|CLOSE|SET|FLUSH]
[SHR|NOSHR]
[JOURNAL|NOJOURNAL]
[BUILDSCHED]
eventdsid Indicates a unique identifier of up to eight characters.
dsname Indicates the name of a VSAM KSDS defined with the right
attributes.
newdsname Indicates a VSAM KSDS similar to the above.
backupdsname Indicates a non-VSAM sequential data set.
NOBACKUP-
DSNAME
Used to remove the backupdsname, if already specified.
schedule Indicates a time schedule using the same syntax as the ESP
command processor schedule statements. If the text string
contains blanks or commas, it should be enclosed within
quotes.
DEFINE Indicates a new Event data set is being defined. If not
specified, DEFINE is the default.
DELETE Indicates the Event data set is deleted. The associated VSAM
data set will NOT be deletedonly the logical Event ID is
deleted from ESP. The Event data set must be closed first.
DELETE must be issued from a system console.
OPEN Indicates an Event data set is to be reopened.
CLOSE Indicates an Event data set is to be closed and de-allocated
from ESP.
SET Indicates an existing specification is changed without the
need to open or close the data set.
FLUSH Indicates all prior schedule requests for Events on the
deferred queue are flushed. Succeeding schedule requests are
honored.
293
EVENTSET Command, Continued
Syntax (continued)
SHR Indicates the data set is to be shared.
NOSHR Indicates the data set is not to be shared. This is the default.
JOURNAL Indicates a record be written to SMF each time an Event is
defined, updated or deleted (refer to SMFREC Initialization
Parameter).
NOJOURNAL Indicates no records be written to SMF when the Event file is
updated. Use this keyword to cancel a previous JOURNAL
request. This is the default.
BUILDSCHED Indicates the Time Driven Requests (TDRs) are built.
Usage notes This command is used to define and initialize an Event data set. Use the DEFINE
keyword along with DSNAME and SCANTIME parameters. The identifier is the
permanent name to be associated with that logical entity.
When a user or group prefix is defined, an Event data set is assigned to it. The
assignment is the logical identifier, rather than the actual data set name. This allows
the data set name to be changed, or a new data set to be assigned at a later time.
The Event data set is scanned at regular intervals to produce a schedule. This is
normally done at 24 hour intervals. If the SCANTIME keyword is omitted, the
default is 6 am daily. If a backup data set is specified, the backup is performed
automatically while the schedule scan is taking place.
Usage notes
continued
The OPEN and CLOSE options are used when external manipulation of the data set
is necessary. For example, if the data set is to be renamed or restored from a
backup, these steps should be followed:
1. Issue the EVENTSET eventdsid CLOSE command.
2. Rename the data set or perform any other necessary function.
3. Issue the EVENTSET eventdsid OPEN command. If the data set has been
renamed or copied to another data set, you can specify a new name through the
NEWDSNAME parameter.
When ESP encounters an I/O error on an Event data set, it issues an error message
and closes the data set. Remedial action can then take place. When the problem is
corrected, the EVENTSET OPEN command causes ESP to resume operation with
the data set.
Any Events scheduled for execution while the corresponding data set is in the
suspended state are queued for deferred execution. When the data set is available
again, execution can resume. Activity on other data sets can proceed as normal.
294
EVENTSET Command, Continued
Related
information
For information on the EVENTSET Initialization Parameter, see the ESP Workload
Example 1 The following EVENTSET command defines an Event data set:
EVENTSET EVENT1 DEFINE DSNAME(ESP.EVENT1)-
SCAN(5AM DAILY) BACKUP(ESP.BACKUP.EVENT1) SHR
In the above example, a new shared Event data set called EVENT1 is defined. The
actual VSAM data set name is ESP.EVENT1, and the backup data set is
ESP.BACKUP.EVENT1, which is used every morning at 5:00 am. when EVENT1
is scanned.
Other examples Here are more examples using the EVENTSET command.
Indicates the EVENT1 is closed and de-allocated from ESP:
OPER EVENTSET EVENT1 CLOSE
Indicates that no records be written to SMF when the Event file is updated:
OPER EVENTSET EVENT1 SET NOJOURNAL
295
%EXCLUDE Statement
Overview The %EXCLUDE statement requests selective exclusion of JCL and DATA based
on criteria such as time, date, day of the week and Event ID, or a combination of
these parameters. The %EXCLUDE statement is used to exclude portions of JCL or
to exclude control statements from a symbolic variable library.
Syntax The syntax of the %EXCLUDE statement is:
%EXCLUDE [FROM(fromdate)]
[TO(todate)]
[DAY(dayofweek[,dayofweek]...)]
[EVENT(eventid)]
[IF(expression)]
[COPYJCL]
fromdate Indicates a time and date specification in any format that is
valid in a schedule statement.
todate Indicates a time and date specification in any format that is
valid in a schedule statement. If no time is specified, it does
not include this day.
dayofweek Indicates a valid day of week name, which can be abbreviated
to the first three characters. Several day of week names can be
specified, separated by blanks or commas.
eventid Indicates a valid Event name, which can contain the prefix and
descriptive name, or just the descriptive name of the Event. If
the prefix is omitted, the prefix of the current Event is assumed.
Several Event IDs can be specified, separated by blanks or
commas.
expression Value of a logical expression.
COPYJCL Indicates that the exclusion should apply to the copy of the JCL
written to a library as a result of the COPYJCL statement.
Note: Applies to JCL tailoring only, and not symbolic variable
libraries.
Restriction The %EXCLUDE statement cannot be used in an ESP Procedure.
296
%EXCLUDE Statement, Continued
Usage notes The %EXCLUDE parameter must start in Column 1. If you want to use a statement
with the characters %EXCLUDE starting in column 1, but have it treated as data
rather than a control statement, code %%EXCLUDE. The first percent sign is
removed.
The %EXCLUDE statement can be continued onto a second line by placing a + or
- on the last non-blank character of the line. A + strips leading blanks from the
next line, whereas a - does not. Only one continuation per statement is allowed.
The scope of an %EXCLUDE statement excludes data until one of the following
statements is encountered:
%EXCLUDE statement
%INCLUDE statement
%ENDEXCL statement
%ENDINCL statement.
If no parameters are specified, the data following the %EXCLUDE statement is
always excluded.
If you specify a FROM date but no TO date, a TO date of January 1st 2042 is
assumed. Similarly, if you omit a FROM date, a date of January 1st 1900 is
assumed.
If no time is specified, 00:00 is assumed for the FROM and TO parameters.
The FROM and TO parameters are based on the scheduled date.
ESP decides what to exclude in the JCL when it submits the job.
Note: Before using the %EXCLUDE statement, check with your system
change them.

Related
information
For information on selectively including JCL and data, see the %INCLUDE
statement.
For information on ending the selective exclusion of JCL and data, see the
%ENDEXCL statement.
For information on selectively excluding JCL, see the CHECKEXC statement.
297

Example 1 The following %EXCLUDE statement used in a symbolic variable library requests
the exclusion of data on Mondays:
PARM=ABC
%ENDEXCL
In the above example, the value of PARM resolves to ABC every day except
Mondays.

Example 2 The following %EXCLUDE statement used in JCL requests the exclusion of a DD
%EXCLUDE DAY(MONDAY) EVENT(CYBER.PAYROLL)
%ENDEXCL
In the above example, DD statement INPUT05 is excluded on Mondays if the Event
that submitted the job is called CYBER.PAYROLL.

Example 3 The following %EXCLUDE and %INCLUDE statements create a modified copy of
the JCL that ESP writes to the COPYJCL library:
%EXCLUDE COPYJCL
//PAYJOB1 JOB CYB,CLASS=A,MSGCLASS=S
%INCLUDE COPYJCL
//PAYJOB1 JOB CYB,CLASS=A,MSGCLASS=S,RESTART=STEP002
%ENDINCL
In the above example, ESP modifies a copy of the JCL that is written to the
COPYJCL library to include a restart step on the job card.
298

Example 4 The following %EXCLUDE statements used in JCL request the exclusion of
various steps:
//CYBERJOB JOB CYB999,FRED,CLASS=A,MSGCLASS=S
//STEP1 EXEC PGM=IEFBR14
%EXCLUDE IF(ESPSDATE=ESPADATE)
//STEP2 EXEC PGM=PGM1
%EXCLUDE IF(ESPATIME GT 07.59.00)
%EXCLUDE FROM(MAY 1,1997) TO(MAY 5,1997)
%EXCLUDE IF(ESPAHH GE 08 AND ESPAHH LE 14 AND -
TODAY(WED))
%ENDEXCL
STEP1 executes whenever ESP submits the job
STEP2 is excluded when the actual and scheduled dates are equal
STEP3 is excluded when the actual time is greater than 07.59.00
STEP4 is excluded from May 1,1997 to midnight May 4,1997. This is based on
the scheduled date.
STEP5 is excluded if the actual hour is between 8 am and 2 pm and the
scheduled day is Wednesday.

Other examples Here are more examples using the %EXCLUDE statement.
Request exclusion if the value of CYCLE_NUMBER is equal to 9:
%EXCLUDE IF(CYCLE_NUMBER=9)
Request exclusion if the actual hour is greater than 09 and today is not Friday:
%EXCLUDE IF(ESPAHH GT 09 AND TODAY(NOT FRIDAY))
Request exclusion if a started task called CICSPROD is active:
%EXCLUDE IF(ACTIVE(CICSPROD))
Request exclusion if today is the last day of the year:
%EXCLUDE IF(TODAY(LAST DAY OF YEAR))

299
EXIT Statement

Overview The EXIT statement is used to quit from your current point in an ESP Procedure.


Syntax The syntax of the EXIT statement is:
EXIT

Usage notes Use EXIT to quit from your current point in a Procedure. ESP continues to process
pending requests up to the point at which you use EXIT. ESP also processes any
action statements in the calling Event, or other ESP Procedures invoked in the same
Event.
ESP ignores EXIT statements within the scope of a JOB statement during
Application generation. During Application processing, EXIT within the scope of a
JOB statement causes ESP to process all statements up to the EXIT and submit the
job.

Related
Statements
For information on quitting an entire process and the Event that invoked it, see the
QUIT statement.
For information on using ESPs Control Language in Procedures, see the ESP

Example 1 The following EXIT statement is used to exit from the current point in an ESP
Procedure:
PAYROLL:ESPPROC
IF TODAY(DEC 31,1999) THEN
DO
INVOKE CYBER.PROC.CNTL(ALTPAY)
EXIT
ENDDO
/* REGULAR PROCEDURE */
In the above example, if today is December 31, 1999, then ESP invokes an
alternative ESP Procedure called PROD.PROC.CNTL(ALTPAY)and then exits.
On all other days that this Application is invoked, the regular ESP Procedure is
invoked.
300
EXIT Statement, Continued

Procedure:
IF ACTIVE(CICS) THEN JUMPTO STOP
ELSE JUMPTO GO
STOP:
VS F CICS,SHUTDOWN
REEXEC IN(5)
EXIT
GO:
VS F ESP,TRIGGER PROD.NIGHTLY
In the above example, if CICS is active on the current system, ESP jumps to the
label called STOP. ESP issues the operator command, schedules reexecution in 5
minutes, and exits this Procedure.
If CICS is not active on the current system, ESP jumps to the label called GO and
issues a command to trigger an Event.

Example 3 The following Procedure shows the differences when using EXIT and QUIT:
IF TODAY(CHRISTMAS) THEN QUIT
IF TODAY(HOLIDAY) THEN DO
SEND NO WORK TODAY U(BOSS)
EXIT
ENDDO
SEND LET US CONTINUE PROCESSING U(CYB01)
If today is CHRISTMAS, ESP quits the ESP Procedure and no instructions are
processed
If today is not CHRISTMAS but it is a holiday, ESP sends a message and exits
the Procedure at that point
If none of the above conditions are true, ESP sends a message indicating it will
continue processing.

Procedure:
IF ESPSDAY = FRIDAY THEN DO
SEND NO PROCESSING TODAY U(USR01)
EXIT
ENDDO
In the above example, if today is FRIDAY, ESP sends the message and exits the
ESP Procedure at that point.
301
EXIT Statement, Continued

Example 5 The following QUIT statement is used to quit the ESP Procedure:
IF ESPSDAY = FRIDAY THEN DO
SEND NO PROCESSING TODAY U(USR01)
QUIT
ENDDO
In the above example, if today is FRIDAY, ESP quits the ESP Procedure, without
sending the message.

Example 6 The following Procedure shows the differences when using EXIT and QUIT within
the scope of the JOB statement:
APPL PAYROLL
JOB PAYJOB1
RUN WORKDAYS
RELEASE PAYJOB2
EXIT
ENDJOB
JOB PAYJOB2
RUN WORKDAY
QUIT
ENDJOB
In the above example, when the PAYROLL Application is generated on a Monday:
PAYJOB1 is submitted
PAYJOB2 is not submitted and receives an error.
The following is an example of the CSF display when the above Application is
generated:
ESP Consolidated Status: View PAYROLL -- Row 1 of 2, Col 1
COMMAND ===> SCR ===> PAGE
___ PAYJOB1 PAYROLL COMPLETE COMPLETED AT 13.14 21 APR
___ PAYJOB2 PAYROLL SUBERROR Submit Error, Quit

302
EXPECT Command

Overview The EXPECT command is used to tell ESP when an Event is expected to execute.
Use this in Events without SCHEDULE statements if you want the Events activities
reflected when creating scheduled activity reporting.


Syntax The syntax of the EXPECT command is:
EXPECT criteria


Usage notes If you want to display Events that do not have SCHEDULE commands, such as
Events triggered by data set activity, you can use the EXPECT subcommand.
If an Event has not triggered by the expected time, the Event continues to wait.
If you trigger an Event containing an EXPECT command, with the REPLACE
option, ESP calculates the next expected execution of the Event.

Related
information
For information on scheduling criteria, see the ESP Workload Manager Users
Guide.
For information on creating schedule activity reports, see the ESP Workload
For information on displaying the schedule, see the LISTSCH command.

Example 1 The following EXPECT command tells ESP when to expect an Event to execute:
EVENT ID(CYBER.PAYJOB)
EXPECT 10AM WORKDAYS
DSTRIG CYB.INPUT.DATA ANYCLOSE
SUBMIT CYB.JCL.CNTL(PAYJOB1)
ENDDEF
In the above example, this Event does not have a SCHEDULE statement because it
is triggered by data set activity and is not reflected in either a scheduled activity
report or on a LISTSCH command. The EXPECT command ensures that
CYBER.PAYJOB is reflected when scheduled activity reports are produced and
when the schedule is listed.

303
FILENAME Statement

Overview The FILENAME statement is used in conjunction with the FILE_TRIGGER
workload object, and is used to build a non-MVS file dependency at the job level
into ESP Applications.


Syntax The syntax of the FILENAME statement is:
FILENAME pathto\filename [CREATE|UPDATE|DELETE]

pathto Indicates the fully qualified path to the directory where the
file filename exists or is created.
filename Indicates the name of the file whose activity triggers the
release of the job named in the associated FILE_TRIGGER
statement.
CREATE Indicates the trigger is to occur when the file is created. This
is the default.
Note: If the file exists when the job is readied, the trigger
occurs immediately.
UPDATE Indicates the trigger is to occur when the file is updated (i.e.,
the time stamp on the file changes).
Note: If the file does not exist when the job is readied, the
trigger does not occur. If the file is subsequently created, the
trigger occurs immediately.
Note: If the file exists when the job is readied and is then
deleted, the trigger does not occur. Deleting a file is not
considered an update.
Warning: The UPDATE trigger is time-sensitive. If the
system time on the Manager and Agent is not synchronized,
the trigger may not function as expected.
DELETE Indicates the trigger is to occur when the file is deleted.

Note: If the file does not exist when the job is readied, the
trigger occurs immediately.

Usage notes The FILENAME statement must be used within the scope of a FILE_TRIGGER
statement to describe the trigger.
304
FILENAME Statement, Continued

Related
information
For information on defining a workload object associated with a non-MVS file
trigger, see the FILE_TRIGGER statement.

Example 1 The following example builds a job level file trigger dependency:
FILE_TRIGGER PAY1.PAYSCRIPT
AGENT HPUX_TORONTO
FILENAME /pay/sched CREATE
RUN DAILY
REL PAYJOB2
ENDJOB
In the above example, PAY1.PAYSCRIPT is used to build a job-level dependency
when the non-MVS file /pay/sched is created.

305
FILE_TRIGGER Statement

Overview The FILE_TRIGGER statement defines a workload object associated with a non-
MVS file trigger and is used in conjunction with the FILENAME statement to build
file dependency, at the job level, into ESP Applications.


Syntax The syntax of the FILE TRIGGER statement is:
{FILE_TRIGGER|FM} name[.qualifier]
[REQUEST]
[CONDITIONAL]

name Indicates a workload object name in up to eight characters.
qualifier Indicates a workload object qualifier in up to eight
characters. It must immediately follow the workload object
name separated by a period.
REQUEST Indicates this is an on-request job.
CONDITIONAL Indicates this job may or may not execute. The Application
this job belongs to is considered complete when all
NOCONDITIONAL jobs are complete.

Usage notes Within the scope of a FILE_TRIGGER statement, a FILENAME statement must be
used to describe the trigger.

Related
information
For information on building a non-MVS file dependency, see the FILENAME
statement.
For information on identifying the name of a job in an Application, see the JOB
statement.
306
FILE_TRIGGER Statement, Continued

Example 1 The following example builds a job level file trigger dependency:
APPL PAYROLL
JCLLIB CYB.ESP.JCL
FILE_TRIGGER WAIT4.DLY
AGENT AIXV120
FILENAME /usr/sched/data UPDATE
RUN DAILY
REL B
JOB B
RUN DAILY
ENDJOB
In the above example, WAIT4.DLY is used to build a job level dependency when
the non-MVS file /usr/sched/data is updated.

307
FLAGUNDEF Statement

Overview The FLAGUNDEF statement finds references to undefined symbols in a symbol
library data set. It then checks subsequent symbol references and issues an error
message if it finds any more undefined symbols.


Syntax The syntax of the FLAGUNDEF statement is:
FLAGUNDEF

Usage notes The FLAGUNDEF statement cannot be used in ESP Procedures.
If ESP flags an undefined symbol while submitting a job, ESP:
Deletes the job and requests the user correct and resubmit the job
Identifies the job on the CSF with a PNODE of SUBERROR, and a status of
Submit Error, JCL missing.
The FLAGUNDEF statement affects all subsequent symbol reference processing
until an ALLOWUNDEF statement is encountered.
If ESP encounters an undefined symbol, ESP processes undefined symbols without
producing an error message, i.e. ALLOWUNDEF is the default.

Related
Statements
For information on turning off the flagging of undefined symbols, see the
ALLOWUNDEF statement.
For information on symbolic variables, see the ESP Workload Manager Advanced
Users Guide.

Example 1 The following FLAGUNDEF statement flags an undefined symbol in a symbolic
variable library:
INTEGER X
FLAGUNDEF
X=%EXXPADD/7+1
In the above example, ESP flags X as an undefined symbol because an ESP built-
in symbolic variable (ESPADD) was typed incorrectly (EXXPADD).
308
FLAGUNDEF Statement, Continued

Example 2 The following FLAGUNDEF and ALLOWUNDEF statements turn the flagging of
undefined symbols on and off:
FLAGUNDEF
A=%BC
ALLOWUNDEF
B=%XY
In the above example, when ESP encounters these undefined symbols while
submitting a job:
A=%BC results in an error message - flagging is on (FLAGUNDEF)
B takes on the value of %XY - flagging is off (ALLOWUNDEF).
309
FLOW Command
Overview The FLOW command is used in conjunction with the GENFLOW command to
identify a flow chart by a name of up to seven characters. The FLOW command
also identifies jobs and/or Applications to be exported.
Type Reporting command
Syntax The syntax of the FLOW command is:
FLOW name
[APPL(applname)]
[JOB(jobname)]
name Indicates the name of the flow chart by a name of up to 7
characters.
applname Indicates the name of an Application to be exported.
jobname Indicates the name or names of jobs to be exported. Several
specification.
Usage notes The following summarizes how to generate flowcharts with ESP and Timeline:
1. Issue the GENFLOW command indicating the input and output data sets
2. Issue the FLOW command to identify the flow chart
3. Issue the GO command to indicate all specifications are complete and that the
copy process should proceed
4. Use a PC file transfer program to send the data to a PC
5. On the PC, use a file editor to edit the file
6. Access Timeline to import, view and print flowcharts
Related
information
For information on creating graphical representations of workload, see the ESP
For information on exporting data that describes an ESP Application in a format
usable by MS Project, see the GENPROJ command.
usable by Timeline, see the GENFLOW command.
For information on indicating that all specifications are complete and that the copy
process should proceed, see the GO command.
310
FLOW Command, Continued
Example 1 The following GENFLOW, FLOW and GO commands are used to export data
describing an ESP Application in a format usable Timeline:
GENFLOW CYBER.SAD CYBER.FLOW
FLOW PAYROLL APPL(PAYROLL)
GO
In the above example, ESP:
Exports the jobnames, start and end times for all jobs in the PAYROLL
Application
Identifies a flowchart called PAYROLL
Proceeds with the copy process.

Note: After the above is completed transfer the file to a PC, edit that file and use
Timeline to import, view and print the PAYROLL flowchart.

describing an ESP Application in a format usable Timeline:
GENFLOW CYBER.SAD CYBER.FLOW
FLOW PAYROLL APPL(PAYROLL) JOB(PAY-)
GO
Exports the jobnames, start and end times for jobs with PAY in the first three
positions, within the PAYROLL Application
311
FOOTING Command

Overview The FOOTING command is used to define a line to be displayed at the bottom of the
page when output is directed to a data set. Use the FOOTING command when
generating history or modeling reports, or issuing an ESP command. Up to seven
title and footing lines can be active at any time.

Type General command, reporting command.

Syntax The syntax of the FOOTING command is:
FOOTING [n]
[DELETE]
[footing string]

n Indicates which footing line is being defined, or deleted. n
can be a value from one to seven. The default is 1.
DELETE Indicates the specified footing line is to be deleted.
footing string Indicates the footing to be displayed. It should be enclosed
within quotes. If the footing contains quotes, use two quotes
in place of each imbedded quote.

Usage notes The following are built-in variables which you can use in a footing string:

%CE Centers the Parameter within the output line.
%DATE Full date, e.g. SUNDAY 4
th
JANUARY 1998.
%DAY Day of week name, e.g. MONDAY.
%DD Day of month number, i.e. from 01 to 31.
%DDDD Julian day or day of year number. E.g. 365 for last day.
%DOW# Day of week number, e.g. 1 for Sunday, 7 for Saturday,
regardless of calendar settings.
%EVAL Returns the numeric value of an expression. An output-
format descriptor may follow the parameter to request leading
blanks or zeros.
%HH Hour, in 24-hour format, e.g. 14.
%LENGTH Returns the length of the Parameter.
%MM Month number, e.g. 01 if the month is January.
%MMM First three characters of the month, e.g. JAN.
%MM Minute of the hour.
%MONTH Month name, e.g. JANUARY.
%PAGE The current page number.
%RJ Justifies the parameter on the right side of the output line.
%SSS Seconds.
%TIME Time, in 24-hour format, e.g. 14.30.00.
312
FOOTING Command, Continued
Usage notes (continued)
%YEAR Year, e.g. 1999.
%YY Last two characters of year, e.g. 99.

Example 1 The following FOOTING command defines a line to be displayed at the bottom of
each page:
FOOTING PAYROLL GROUP EVENTS
LIST ALL LEVEL(PAYROLL)
In the above example, a footing Payroll Group Events is defined to accompany the
output from the LIST command which requests a display of Events in the group
called PAYROLL.

Example 2 The following history report uses the FOOTING command to display an additional
line of information at the bottom of each page:
//HISTRPT JOB CYB3000,CLASS=A,MSGCLASS=X
//SYSIN DD *
REPORT
FROM 7AM TODAY LESS 1 WEEK
CRITERIA JOBNAME EQ PAY-;
DISPLAY JOBNAME,JOBNO,EXECSDATE,ENDDATE,CMPC
SORT JOBNAME
FOOTING '%DATE %CE(PAYROLL JOBS) %RJ(PAGE %PAGE)'
ENDR
In the above example, the following are displayed at the bottom of each page:
The current date
PAYROLL JOBS, which is justified in the center of the page
The page number, which is justified on the right side of the page.

Example 3 The following FOOTING command defines a line to be displayed at the bottom of
each page:
FOOTING CALENDARS %RJ(PAGE %PAGE)
In the above example, a footing CALENDARS is defined. . The page number is to
be justified on the right side of the page.

313
//* FROM Statement

Overview The //* FROM statement is used in combination with the TEMPLIB statement to
indicate that temporary JCL for a job is to be used from a particular date. The
TEMPLIB statement is used in an ESP Procedure to indicate a temporary or override
JCL library.


Syntax The syntax of the // * FROM statement is:
//*FROM criteria


Usage notes The //* FROM statement is used in a JCL library that was identified as a temporary
JCL library using the TEMPLIB statement.
A single blank separates the //* and the FROM.
The //* FROM statement is only available in JCL and must start in card column 1. It
must be the first statement in the JCL. ESP checks the //* FROM date to determine
whether the JCL should be used. If no time is specified, the start-of-day time is used
(default midnight 00.00).
ESP compares the scheduled time and date of the Event to the criteria on the //*
FROM statement to decide whether to use the JCL in the TEMPLIB for a job. If the
//* FROM date and time has passed, ESP uses the JCL from the last defined JCLLIB
in the Application.

Related
information
For information on further limiting the window in which temporary JCL is used, see
the //* UNTIL statement.
For information on specifying a temporary or override JCL library, see the
TEMPLIB statement.
For information on tailoring JCL that ESP submits, see the ESP Workload Manager
314
//* FROM Statement, Continued

Example 1 The following // * FROM statement used in the JCL indicates a time and date from
when temporary JCL should be used:
//* FROM 9AM MAY 24,1999
In the above example, temporary JCL for PAYJOB1 is used from 9am on May 24,
1999.
Note: If PAYJOB1 is submitted at 10 am, but the Event was scheduled at 8 am, ESP
submits PAYJOB1 from the default JCL library (JCLLIB) not the temporary JCL
library (TEMPLIB).

Example 2 The following //* FROM statement used in the JCL indicates a time and date from
when temporary JCL should be used:
//* FROM AUGUST 6, 1998
In the above example, temporary JCL for PAYJOB2 is used from 00:00 (default) on
August 6, 1998.

Example 3 The following //* FROM and //* UNTIL statements used in the JCL indicate a time
and date window when temporary JCL should be used:
//* FROM 9AM NOVEMBER 27, 1998
//* UNTIL 4PM NOVEMBER 30, 1998
In the above example, temporary JCL for PAYJOB3 is used from 9 am on
November 27, 1998 until 4 pm on November 30, 1998.

315
FROM Command

Overview The FROM command is used to indicate a time range for the history reporting. This
allows you to limit your search based on the job submission time in the history file.
You can use any valid schedule statement.

Type Report command.

Syntax The syntax of the FROM command is:
FROM starttime
[TO(endtime)]

starttime Indicates a free format starting time. Use any valid schedule
criteria that resolve to a single date and time.
endtime Indicates a free format, end time specification. (Defaults to
now). Use any valid schedule criteria that resolve to a single
date and time.

Usage notes The FROM parameter restricts history record extraction based on job submission
time. If an end time is not specified, the current time is assumed.

Related
information
For information on reporting, see the ESP Workload Manager Users Guide.

Example 1 The following history report uses the FROM command to specify a time range for
the history file search:
REPORT
FROM 7AM TODAY
CRITERIA JOBNAME EQ PAY;
DISPLAY JOBNAME,JOBNO,EXECSDATE,ENDDATE,CMPC
ENDR
In the above example, all jobs with PAY in the first three positions run since 7 am
this morning are displayed in this report.
316
FROM Command, Continued

Example 2 The following history report uses the FROM command to specify a time range for
the history file search:
REPORT
FROM 8AM YESTERDAY TO 4PM TODAY
CRITERIA JOBNAME EQ PAY-;
DISPLAY JOBNAME,JOBNO,ACCOUNT,RDRON,DEXCP,TEXCP
ENDR
In the above example, all jobs with PAY in the first three positions run between 8
am yesterday and 4 pm today are displayed in this report.

Other examples Here are more examples using the FROM command.
Limit a history file search from 8 am yesterday to 8 am today:
FROM 8AM YESTERDAY TO 8AM TODAY
Limit a history file search from December 29
th
, 1999 to January 4
th
, 2000:
FROM DEC 29TH 1999 TO JAN 4TH 2000
Limit a history file search from 8 am one week ago to now:
FROM 8AM TODAY LESS 1 WEEK

317
GENDOC Command

Overview Use the GENDOC command to convert an existing job documentation library to a
documentation library usable by ESP.


Syntax The syntax of the GENDOC command is:
GENDOC inputdataset outputdataset
[LEVEL(memname[,memname]...)]
[SNUM]

inputdataset Indicates the name of the input data set, enclosed in quotes,
which must be a PDS.
outputdataset Indicates the name of an output PDS, enclosed in quotes. The
record format or record length does not have to match that of
the input data set.
memname Indicates strings that identify the members to be copied. You
can use wildcards in these strings. The * wildcard character
is a single character wildcard, while - is the multiple-
character wildcard. ABC- matches any member name
beginning with ABC while A*C matches any three-
character name beginning with A and ending with C. If
the LEVEL keyword is omitted, all members are copied.
SNUM Indicates the last eight characters of a fixed-length record
should be discarded during the copy process.

Usage notes The GENDOC command identifies the input data set, the members to be copied, and
the output data set. It also lets you identify changes you want to make when the old
job documentation is converted.
There are two methods for converting documentation. The method you use depends
on how you want to use your existing job documentation:
If want to use ESP to retrieve your existing job documentation in its present
format, you can insert a USERDESC label in each job documentation member.
If you want ESP to modify the data to allow retrieval of information by label
name, you can use the GENDOC command.
318
GENDOC Command, Continued

Related
information
For information on identifying lines that are not to be copied to the output data set,
see the REMOVE command.
For information on altering or replacing lines in the output data set, or inserting lines
at different locations, see the LABEL command.
For information on ESPs job documentation facility, see the ESP Workload
For information on displaying information from a job documentation library, see the
JOBINFO command.
For information on identifying a job documentation library in an Application, see
the DOCLIB statement.

Example 1 The following GENDOC command is used to convert existing job documentation:
GENDOC JOBDOC.DATA ESP.JOBDOC.DATA LEVEL(JT-,JV-) SNUM
In the above example, all members beginning with JT and JV are copied from
JOBDOC.DATA to ESP.JOBDOC.DATA, suppressing any line numbers in the
right-hand eight columns of each source member record.

Example 2 The following GENDOC, REMOVE, LABEL and GO commands are used to
convert existing job documentation:
GENDOC JOBDOC.DATA ESP.JOBDOC.DATA LEV(A,B) SNUM
REMOVE **
LABEL SYSOUT REVIEW SYSOUT_REVIEW INLINE
LABEL STEP*** @: OVERLAY
LABEL RESTART PROCEDURES RESTART: BEFORE
GO
Copies all members beginning with A and B from the data set
JOBDOC.DATA to the data set ESP.JOBDOC.DATA, suppressing any line
numbers in the righthand 8 columns of each source member record.
Does not copy any lines containing **.
Replaces any lines starting with SYSOUT REVIEW with the character string
SYSOUT_REVIEW.
Overlays the colon on any line beginning with STEP. The colon is positioned
after the 3rd character following the string STEP.
Places the label RESTART: on its own line before any line starting with the
string RESTART PROCEDURES.
319
GENFLOW Command
Overview The GENFLOW command is used to export data that describes an ESP Application
in a format usable by the PC-based project management software, Timeline. ESP
uses information from a Scheduled Activity file and exports the jobname, start and
end time fields.
Syntax The syntax of the GENFLOW command is:
GENFLOW inputdsn outputdsn
inputdsn Indicates the name of the scheduled activity data set, enclosed
in quotes.
outputdsn Indicates the name of an output data set, enclosed in quotes.
The output data set can be a sequential data set or a member
of a PDS.
Usage notes The following summarizes how to generate flowcharts with ESP and Timeline:
1. Issue the GENFLOW command indicating the input and output data sets
2. Issue the FLOW command to identify the flow chart
3. Issue the GO command to indicate all specifications are complete and that the
copy process should proceed
5. On the PC use a file editor to edit the file
6. Access Timeline to import, view and print flowcharts.
Related
information
For information on identifying a flowchart, see the FLOW command.
usable MS Project, see the GENPROJ command.
320
GENFLOW Command, Continued
describing an ESP Application in a format usable by Timeline:
GENFLOW ESP.DAILY.SADGEN CYB.PC.TRANSFER
GO
Exports the jobnames, start and end times of jobs in the PAYROLL Application

Note: After the above is completed, transfer the file to a PC, edit that file and use
Timeline to import, view and print the PAYROLL flowchart.

321
GENPROJ Command

Overview The GENPROJ command is used to export data that describes an existing ESP
Application in a format usable by the PC based project management software, MS
Project. ESP exports the following fields:
jobname
subApplication name
start & end dates
duration
Late start & late end times
percent complete
tag.


Syntax The syntax of the GENPROJ command is:
GENPROJ applname[.gen|OLDEST]
DATASET(outputdsn)

applname Indicates the name of the Application to be used as input. An
absolute or relative generation number (gen) can also be
specified as follows:
applname.0 indicates the most recent generation
applname.-n indicates the nth previous generation
applname.n indicates the absolute generation n
outputdsn Indicates the name of an output data set enclosed in quotes.
The output data set can be a sequential data set or a member
of a PDS. It can be VB or FB formats with an LRECL at
least 72 bytes long. ESP does not write records longer than
72 bytes in length. ESP assigns the default attributes of
RECFM= FB, LRECL= 80, BLKSIZE= 3120 to data sets that
are allocated without DCB attributes.
OLDEST Indicates the oldest incomplete generation of the Application
to be used as input. If all generations are complete, you cant
use OLDEST.
322
GENPROJ Command, Continued
Usage notes The Application used as input must be available on the APPLFILE (i.e. accessible
via the LISTAPPL command). It can be in either an active or complete state.
Information such as average or actual duration, starts date, end date, percent
complete, late start time, late end time, etc. are exported and can be viewed.
The file created by GENPROJ can be transferred to a PC and then imported into
Microsoft Project for viewing or printing.
The following summarizes how to generate flowcharts with ESP and MS Project:
1. Issue the GENPROJ command indicating the name of an active Application, and
the output data set. The copy process should proceed
3. Execute the Cybermation supplied utility CONVERT.EXE on your PC
4. Access MS Project to view and print flowcharts
Related
information
usable by Timeline, see the GENFLOW command.
Example 1 The following GENPROJ command extracts data from an Application:
GENPROJ PAYROLL.0 DATASET(PAYROLL.FLOWCHRT)
In the above example, a file is generated called PAYROLL.FLOWCHRT that
contains a description of the current generation of the PAYROLL Application.
MS Project can then import this file.
Example 2 The following GENPROJ command extracts data from an Application:
GENPROJ PAYROLL OLDEST DATASET(PAYROLL.FLOWCHRT)
In the above example, a file is generated called PAYROLL.FLOWCHRT that
contains a description of the oldest incomplete generation of the PAYROLL
Application. MS Project can then import this file.
323
GENTIME Command
Overview The GENTIME command is used to customize date and time symbols for any
scheduling criteria. It may be required to use date and time symbolic variables other
than ESPs built-in symbolic variables. Using the GENTIME command you create a
set of customized date and time symbolic variables.
Type ESP Procedure statement, symbolic variable library statement.
Syntax The syntax of the GENTIME statement is:
GENTIME prefix criteria
prefix Indicates a user-defined string of up to 55 characters that
becomes the prefix for the symbols you generate with this
statement.
Usage notes The prefixes ESPA and ESPS are reserved for ESPs builtin symbols and
cannot be used in the GENTIME command.
You can test the symbols produced by a GENTIME command prior to storing the
generated symbols permanently in a symbol library or ESP Procedure. Enter the
following commands in Page mode or Line mode:
Enter the GENTIME command with your prefix and criteria.
Enter the ECHO command to send the symbols back to your terminal for
display.

Note: When you use a GENTIME command for testing or demonstration purposes,
the generated symbols are only temporary. They are lost when you exit from the ESP
Main Menu.
When specifying the criteria in your GENTIME command via Page mode, it is
advised to use STARTING to establish effective time and get results consistent
with your ESP Procedures.
GENTIME variables are commonly used in JCL.
324
GENTIME Command, Continued

Usage notes
continued
The GENTIME command generates the following 15 customized date and time
symbolic variables:

Variable Description
prefixDATE The Event date in full.
Example: Sunday 4
th
January 1998
prefixYY The last two digits of the year
Example: 98
prefixYEAR The Year.
Example: 1998
prefixMM The number of month.
Example: 01 for January
prefixMMM The first three characters of month.
Example: Jan
prefixMONTH The name of month.
Example: January
prefixDAY The name of the day of the week.
Example: Monday
prefixDD The number of actual day of month.
Example: 09
prefixDDD The Julian day, or the number day in the year.
Example: 365
PrefixDDQL The ordinal qualifier for the day.
Example: st, nd, rd or th
prefixDOW# The number of day in week as specified in a calendar.
Example: 1 for Sunday (ESP default)
prefixTIME The time in 24-hour format.
Example: 14.55.32
prefixHH The hour in 24-hour format.
Example: 14
prefixMN The minute of hour.
Example: 55
prefixSS The number of seconds past the minute.
Example: 32

You can choose to use any of the variables you generate with the GENTIME
command.

Related
Statements
For information on testing dates and times produced by the GENTIME command,
see the ESP Workload Manager Advanced Users Guide.
325

Example 1 The following GENTIME command is used to generate customized date and time
variables:
GENTIME NWD TODAY PLUS 1 WORKDAY
In the above example, a series of 14 customized date and time based variable are
generated that refer to the next workday. Each of the 14 variables are prefixed with
NWD.
For example, if this GENTIME command was processed on February 18
th
, 1998:
%NWDMM resolves to 02
%NWDDD resolves to 049
%NWDYY resolves to 98
%NWDDOW# resolves to 4
%NWDDATE resolves to Wednesday February 18
th
, 1998.

Example 2 The following GENTIME command is used to generate customized date and time
variables:
GENTIME FWM FIRST WORKDAY OF MONTH STARTING TODAY
In the above example, a series of 14 customized date and time based variable are
generated that refer to the first workday of the current month. Each of the 14
variables are prefixed with FWM.

Example 3 The output from the first GENTIME command, in the following example, is used as
input to another GENTIME command:
GENTIME PWK TODAY LESS 1 WEEK
GENTIME PWD %PWKDATE LESS 1 WORKDAY
In the above example, the first GENTIME command generates a series of date and
time variables that refer to one week ago. Each of the variables are prefixed with
PWK. This date is then used in the second GENTIME to generate another series
of date and time variable that refer to workday prior to one week ago. Each of these
variables are prefixed with PWD.
326

Example 4 The following GENTIME commands are used to establish a run frequency for a job
in an Application:
APPL PAYROLL
JCLLIB 'CYBER.JCL.CNTL'
GENTIME AA LAST WORKDAY OF WEEK STA TODAY LESS 1 WEEK
GENTIME BB LAST WORKDAY OF MONTH STA TODAY LESS 1 MONTH
JOB PAYJOB1
IF TODAY('NOT LAST WORKDAY OF WEEK') AND -
TODAY('LAST WORKDAY OF MONTH') THEN RUN TODAY
IF TODAY('1ST FRI OF MONTH') AND %AADATE EQ %BBDATE THEN RUN
TODAY
ENDJOB
If the last workday of the week is not the last workday of the month then run
PAYJOB1 today
If the last workday of the week is the last workday of the month then PAYJOB1
on the 1
ST
Friday of the next month.

Other examples Here are more examples using the GENTIME command.
Seven days after today:
GENTIME AA TODAY PLUS 7 DAYS
Two workdays prior to today:
GENTIME BB TODAY LESS 2 WORKDAYS
One week prior to today:
GENTIME CC TODAY LESS 1 WEEK
First workday of previous month:
GENTIME DD FIRST WORKDAY OF MONTH STARTING TODAY LESS 1 MONTH
Next day:
GENTIME EE TODAY PLUS 1 DAY
Next workday:
GENTIME FF TODAY PLUS 1 WORKDAY
Two days after today:
GENTIME GG TODAY PLUS 1 DAY

327
GO Command

Overview The GO command is used in conjunction with the GENDOC and GENFLOW
commands. It indicates that the GENDOC or GENFLOW specification is complete
and the copy process should begin.

Type General command, reporting command.

Syntax The syntax of the GO command is:
GO

Related
information
For information on ESPs job documentation facility, see the ESP Workload

REMOVE ** LABEL RESTART PROCEDURES RESTART: BEFORE
GO
In the above example, the GO command indicates that the GENDOC specification is
complete and that the copy process should start.

describing an ESP Application in a format usable by Timeline:
GENFLOW ESP.DAILY.SADGEN CYB.PC.TRANSFER
GO
In the above example, the GO command indicates that the GENFLOW specification
is complete and that the copy process should start.
328
GROUP Command

Overview The GROUP command is used in Page mode to switch between a users user ID and
any group (that is the high level prefix) the user can access. It is useful when using
commands where a group prefix is required, such as TRIGGER.


Syntax The syntax of the GROUP command is:
{GROUP|GR} [groupprefix]
[USERID]
[PREFIX]

groupprefix Indicates up to eight characters to be the prefix for
unqualified Event descriptive names. (You must be
connected to the group specified.)
USERID Indicates the current TSO USERID is used to prefix
unqualified Event names.
PREFIX Indicates the current TSO data set name prefix is used as the
prefix for unqualified Event names.

Usage notes The value of the group prefix is retained from session to session, until it is reset.
The initial value is USERID. The group prefix for Events is similar in concept to
the TSO data set name prefix.
If the GROUP command is entered without any operands, your current group prefix
is displayed.
The GROUP command can be used with or without the SAF interface.

Related
information
For information on ESP users and groups, see the ESP Workload Manager
For information on defining and deleting groups, see the DEFGROUP and
DELGROUP commands.
command.
329
GROUP Command, Continued

Example 1 The following GROUP command displays the current group prefix:
GROUP
In the above example, the current group prefix is displayed.

Example 2 The following GROUP command switches a user IDs access to another group:
GROUP PROD
In the above example, the default prefix is switched to PROD. To trigger an Event
called PROD.PAYROLL, this user can issue the TRIGGER command without
having to specify the group prefix, as follows:
TRIGGER PAYROLL vs. TRIGGER PROD.PAYROLL

330
HARDCOPY Command - DATASET Option

Overview
The HARDCOPY command is used to request that a data type printout be diverted
to a data set, sysout class or DD file. Each option is documented separately. The
HARDCOPY command cannot be used in batch.

Syntax The syntax of the HARDCOPY command is:
{HARDCOPY|HCPY} DATASET(dsname)
[VOLUME(serial)]
[UNIT(unitname)]
[SPACE(primary[,secondary]){CYLINDERS}]
{TRACKS}]
{BLOCKS}]
[EXTEND]
[LRECL(length)]
[RECFM{(V)|(F)}]
[PAGELENGTH(lines)]
[BLOCK(size)]
[BLKSIZE(block)]

dsname Indicates the data set name, enclosed in quotes, to which the
output should be diverted. You should include a member
name if you are diverting output to a PDS.
serial Indicates the serial number (up to six characters) for the data
set if you are specifying a new data set, or if you are using an
existing data set that is not catalogued.
characters.
parentheses. You must specify this if you are allocating
CYLINDERS, TRACKS or BLOCKS.
parentheses. If you use this parameter you must use the
appropriate keyword to specify whether you are allocating
parentheses.
overwritten.
LRECL.
331
HARDCOPY Command - DATASET Option, Continued
Syntax (continued)
and footings.
is 32767 bytes.

Usage notes Use this command in Page mode when you want to direct output to a data set.

Related
information
For information on stopping the routing of output as specified by a HARDCOPY
command, see the ENDHC command.

Example 1 The following HARDCOPY command diverts output:
HARDCOPY DATASET(PRINT1A.REPS) SPACE(2,1) TRACKS
VOLUME(AX401B)
In the above example, output is diverted to the PRINT1A.REPS data set, with a
primary allocation of two tracks and a secondary allocation of one track, on the
volume serial AX401B.

Example 2 The following HARDCOPY command diverts output to a data set:
HARDCOPY DATASET(CYB.HRDCPY)
L LEVEL(PROD-)
ENDHC
In the above example, output produced by the LIST command is diverted to the
CYB.HRDCPY data set.

332
HARDCOPY Command - FILE Option

Overview The HARDCOPY command is used to request that a data type printout be diverted

{HARDCOPY|HCPY} DDNAME(file)
[EXTEND]
[LRECL(length)]
[RECFM{(V)|(F)}]
[PAGELENGTH(lines)]
[BLOCK(size)]
[BLKSIZE(block)]

file Indicates a file name using up to eight characters.
EXTEND Indicates that the output should be added to the end of the
data set.
LRECL.
and footings.
is 32767 bytes.

Usage notes Use this command in Page mode when you want to direct output to a DD name.

Related
information
For information on stopping the routing of outputs specified by a HARDCOPY

HARDCOPY DDNAME(HISTREC1) LRECL(80) RECFM(F) EXTEND
In the above example, output is diverted to the HISTREC1 file. The logical record
length for each line of output should be 80, in fixed length records. All output is
added to the end of the file.
333
HARDCOPY Command - FILE Option, Continued

Example 2 The following HARDCOPY command diverts output to a file:
HARDCOPY DDNAME(HRDCPY)
L LEVEL(PROD-)
ENDHC
In the above example, output produced by the LIST command is diverted to the
HRDCPY file.

334
HARDCOPY Command - SYSOUT Option

Overview The HARDCOPY command is used to request that a data type printout be diverted


{HARDCOPY|HCPY} SYSOUT(class)
[DEST(destcode)]
[COPIES(n)]
[FORM(type)]
[LRECL(length)]
[RECFM{(V)|(F)}]
[PAGELENGTH(lines)]
[UCS(char)]
[SPIN]

class Indicates a one-character class number.
destcode Indicates a destination code of up to eight characters. If you
do not specify DEST, the destination defaults to LOCAL.
n Indicates the number of copies you want printed. The
maximum is 240 copies.
type Indicates the type of form you want to use for printing, using
up to four characters for the code.
line length is four bytes less than what you have specified
under LRECL.
and footings.
char Indicates the universal character set type you want to be used
on the printer for this printout.
SPIN Indicates that the data should be made available for printing
as soon as you enter the ENDHC (end hardcopy) command.

Usage notes Use this command in Page mode when you want to direct output to SYSOUT.

Related
information
For information on stopping the routing of output as specified by a HARDCOPY
335
HARDCOPY Command - SYSOUT Option, Continued

HARDCOPY SYSOUT(1) DEST(RMT1) FORM(ANC8) SPIN
In the above example, output is diverted to SYSOUT class 1. The destination is
RMT1 and the form is ANC8. The data is available as soon as the ENDHC
command is specified.

Example 2 The following HARDCOPY command diverts output to sysout class S:
HARDCOPY SYSOUT(S)
L LEVEL(PROD-)
ENDHC
In the above example, output produced by the LIST command is stored under your
user ID.

336
HISTFILE Command - Reporting

Overview The HISTFILE command is used as part of a report definition. HISTFILE specifies
the identifiers of the HISTORY files to scan in order to generate a history report.


Authority You may be restricted to history files to which you have access. This is controlled
via your ESP administrator. In SAF environments access is specified in the User
Profile Definition Table. In non-SAF environments access is specified via the
DEFUSER command.

Syntax The syntax of the HISTFILE command is:
HISTFILE hfid

hfid Indicates the history file identifier of up to eight characters.
Several identifiers can be specified if enclosed in parentheses
and separated by blanks or commas.

Usage notes If you omit this parameter, all history files to which you are permitted access are
scanned.

Related
Statements
For information on defining or altering the history file, see the HISTFILE command,
or the HISTFILE Initialization Parameter in the ESP Workload Manager Installation
and Reference Guide.
For information on defining or altering the history file, see the HISTFILE command
in the ESP Workload Manager Installation Guide.
For information on displaying history files, see the LISTHIST command.
For information on working with history files, see the ESP Workload Manager
337
HISTFILE Command - Reporting, Continued

REPORT
HISTFILE HIST1
FROM 7AM YESTERDAY
ENDR
The HISTFILE command indicates that HIST1 is to be scanned
The ENDR command ends the report definition and initiates report generation

Other examples Here are more examples using the HISTFILE command.
Indicates that history files with HIST in the first 4 positions are used:
HISTFILE HIST-
Indicates that HIST1 and HIST2 are used:
HISTFILE (HIST1,HIST2)

338
HISTFILE Command - Definition/Alteration

Overview Used to define or alter the definition of an ESP history data set.


Authority OPER authority is required to issue the HISTFILE command.

Syntax The syntax of the HISTFILE command is:
HISTFILE histfid
[DSNAME(dsname)]
[NEWDSNAME(newdsname)]
[BACKUPDSNAME(backupdsname)|NOBACKUPDSNAME]
[DEFINE|DELETE|OPEN|CLOSE|SET]
[SHR|NOSHR]
[JOURNAL|NOJOURNAL]
[BACKUPTIME(schedule)|NOBACKUPTIME]

histfid Indicates a unique identifier of up to eight characters.
dsname Indicates the name of a VSAM KSDS.
newdsname Indicates the name of a VSAM KSDS.
backupdsname Indicates a non-VSAM sequential data set.
NOBACKUPDSNAME Used to remove the backupdsname, if already specified.
DEFINE Indicates a new History file database is being defined. If
not specified, DEFINE is assumed.
DELETE Indicates a HISTFILE definition is to be deleted. The
associated VSAM data set is NOT deleted, only the
logical HISTFILE ID is deleted.
OPEN Indicates a histfile is to be reopened.
CLOSE Indicates a HISTFILE is to be closed and de-allocated.
SET Indicates an existing specification is changed without the
need to open or close the data set.
SHR Indicates the data set is to be shared.
NOSHR Indicates the data set is not to be shared.
JOURNAL Indicates a record be written to SMF each time a history
record is inserted, updated or deleted.
NOJOURNAL Indicates no records be written to SMF when the
HISTFILE is updated. Use this keyword to cancel a
previous JOURNAL request.
schedule Indicates a time schedule using the same syntax as ESP
schedule statements. If the text string contains blanks or
commas, it should be enclosed within quotes.
NOBACKUPTIME Used to remove the backuptime, if already specified.
339
HISTFILE Command - Definition/Alteration, Continued

Usage notes The HISTFILE command is used to define and initialize a job history data set. Use
the DEFINE keyword along with the DSNAME Parameter. The identifier (up to
eight characters) is the name to be associated with that logical entity.
When a tracking model is defined, a job history file ID can be specified. This
identifies to which data set the history data is written. Use of the ID rather than the
data set name allows the actual data set name to be changed without having to alter
all references to it.
The BACKUPTIME keyword specifies a time at which time the HISTFILE is
automatically backed up to the BACKUPDSNAME data set.
You can also backup a history file with the BKUPHIST command.

Related
information
For information on working with history files, see the ESP Workload Manager
For information on displaying history files, see the LISTHIST command.

Example 1 The following HISTFILE command defines a history file:
HISTFILE HISTF1 DEFINE DSNAME(ESP.HISTFILE) SHR
In the above example, a new history recording file called HISTF1 is defined. The
actual data set used is ESP.HISTFILE, and its disposition is shared.

Example 2 The following HISTFILE command sets the journal option:
HISTFILE HISTF1 SET JOURNAL
In the above example, records are written to SMF each time a history record is
inserted, updated or deleted.

Example 3 The following HISTFILE command closes a history file:
HISTFILE HISTF1 CLOSE
In the above example, HIST1 is closed and de-allocated from ESP.
340
HOLD Command - Event Level

Overview The HOLD command at the Event level is used to hold an Event from being
processed by ESP at a particular time. When ESP encounters a HOLD command in
an Event, it increments the Events hold count by one at the time and date specified
in the command. While the hold count is greater than zero, the Events execution is
postponed until the hold count is decremented by the RELEASE command.


Syntax The syntax of the HOLD command is:
HOLD criteria

criteria Schedule criteria.

Usage notes The RELEASE command is used in conjunction with the HOLD command to make
a previously postponed Event eligible for execution.
If an Event is in both a suspended and a held state when due for scheduling, the
Event is considered suspended.
When the hold count of an Event is reduced to zero, the Events overdue count
specified at definition time, on the SCHEDULE command, determines the number
of times the Event should execute. The default overdue count is 1.
Issuing a HOLD command against an Event that invokes an Application takes effect
on the next scheduled execution of that Event. An active Application that has a
HOLD command issued against the Event that invokes it does not cause that
Application to stop processing. Use the APPLJOB or AJ command to manipulate
Applications and jobs belonging to Applications.
If you are using a time zone on your HOLD command, you should use the same
timezone on your RELEASE command. If the Event has a schedule statement, the
same time zone should be used on the SCHEDULE, HOLD and RELEASE
commands.
Note:
The RESUME command is used in conjunction with the SUSPEND command to
make a previously bypassed Event eligible for execution.

Related
information
For information on decrementing an Events hold count that was previously
incremented via a HOLD command, see the RELEASE command.
341
HOLD Command - Event Level, Continued

DSTRIG PAYROLL.INPUT
HOLD DAILY AT 9AM
RELEASE DAILY AT 11AM
SUBMIT CYBER.JCL.CNTL(PAYJOB1)
ENDDEF
In the above example, HOLD and RELEASE commands are used to prevent
PAYJOB1 from being submitted between 9 am and 11 am. If the
PAYROLL.INPUT data set is created during 9 am and 11 am, the Event waits.
The following is an example of the comments ESP adds to the Event if the
PAYROLL.INPUT is created between 9 am and 11 am:
HOLD DAILY AT 9AM
/* FOLLOWING EXECUTIONS PENDING:
/* DATASET TRIGGER BY JOB ACCJOB9 AT 09.15.00 ON THU FEB, 1998
/* DSN PAYROLL.INPUT
ENDDEF

HOLD 9AM FEB 14, 1998 ONCE
RELEASE 11AM FEB 14, 1998 ONCE
ENDDEF
PAYJOB2 from being submitted between 9 am and 11 am on February 14 1998.

342
HOLD Command - General

Overview The HOLD command is used to hold an Event from being processed by ESP. This
increments the Events hold count. While the hold count is greater than zero, the
Events execution is postponed until the hold count is decremented by the
RELEASE command.


Syntax The syntax of the HOLD command is:
HOLD eventid

eventid Indicates a valid Event name. If the prefix is omitted the
current prefix as set by the GROUP command is used.

Usage notes Holding an Event is different from suspending it.
If the scheduled time for an Event comes up while it is in the suspended state, the
Event execution is bypassed, and it is not considered overdue.
If the Event is in a held state, it is placed in an overdue status. When the Event is
finally released, the overdue count is checked to see whether execution should
proceed. The Event is checked immediately for every occurrence missed while in
the held state, up to the overdue limit count specified when the Event was defined.
If an Event is in both a suspended and hold state when due for scheduling, the hold
state is ignored, and the Event is considered suspended.
The HOLD command is used in conjunction with the RELEASE command. (The
SUSPEND command goes hand in hand with the RESUME command).

Related
information
For information on decrementing an Events hold count that was previously
incremented via a HOLD command, see the RELEASE command.
For information on bypassing and resuming an Events execution, see the
SUSPEND and RESUME commands.
343
HOLD Command - General, Continued

Example 1 The following HOLD command postpones the execution of an Event:
HOLD CYBER.PAYROLL
In the above example, CYBER.PAYROLL is held, incrementing its hold count to 1.
To decrement the hold count, use the RELEASE command to make
CYBER.PAYROLL eligible for execution.

344
IF Statement

Overview The IF statement is used to conditionally process an instruction or group of
instructions depending on the evaluation of an expression. The IF statement is used
in conjunction with the THEN and ELSE statements.


Syntax The syntax of the IF statement is:
IF expression

expression Indicates an expression that can be evaluated to return a true or
false value.

false value. You can use any number of nested IF statements.
The ELSE statement is used in conjunction with an IF statement when the
If a THEN or ELSE statement continues to another line, use a line continuation
character ( or +). If there is no continuation character, ESP ignores the THEN or
ELSE statements.
You must begin and end compound action statements with DO and ENDDO
language elements.
When ESP encounters an IF statement that evaluates as false, ESP skips everything
until an ELSE or ENDDO statement is encountered, this includes any symbolic
variable declarations. Symbolic variable declarations coded within an IF statement
block that evaluate as false will result in a variable not defined error message. If you
want a symbolic variable to be available inside and outside an IF statement block,
declare it outside.

Related
Statements
Users and Advanced Users Guides.
For more information on specifying conditional logic, see the THEN and ELSE
statements.
345
IF Statement, Continued

Example 1 The following logic is used to process different action statements:
SEND TODAY IS MONDAY U(USR01)
ELSE -
SEND TODAY IS %ESPADAY U(USR01)
evaluation of this expression is true, ESP sends a message indicating that today is
Monday to USR01. If the evaluation of this expression is false, ESP sends a
message to USR01 indicating what today is.

Example 2 The following logic is used to determine when a job runs:
JOB PAYJOB1
IF TODAY(FIRST DAY OF MONTH) AND TODAY(TUESDAY) THEN -
RUN TODAY
ENDJOB
In the above example, ESP determines if today is the first day of the month and
TUESDAY, and if this condition is true then PAYJOB1 is selected to run.

IF ESPSMM<5 THEN DO
ENDDO
ELSE DO
ENDDO
In the above example, a user defined symbolic variable called
FINANCIAL_YEAR which consists of two, 2digit year numbers, and is set as
follows:
if the current month is January, February, March or April, use last year
followed by this year
for any other month, use current year followed by next year.

346
%INCLUDE Statement

Overview The %INCLUDE statement requests selective inclusion of JCL and DATA based on
criteria such as time, date, day of the week and Event ID, or a combination of these
parameters. The %INCLUDE statement is used to include portions of JCL or to
include control statements from a symbolic variable library.

Type ESP control statement used in JCL and in symbolic variable library statement.

Syntax The syntax of the %INCLUDE statement is:
%INCLUDE [FROM(fromdate)]
[TO(todate)]
[DAY(dayofweek[,dayofweek]...)]
[EVENT(eventid)]
[IF(expression)]
[COPYJCL]

fromdate Indicates a time and date specification in any format that is
todate Indicates a time and date specification in any format that is
dayofweek Indicates a valid day of week name, which can be abbreviated
to the first three characters. Several day of week names can be
specified, separated by blanks or commas.
eventid Indicates a valid Event name, which can contain the prefix and
descriptive name, or just the descriptive name of the Event. If
the prefix is omitted, the prefix of the current Event is assumed.
Several Event IDs can be specified, separated by blanks or
commas.
expression Value of a logical expression.
COPYJCL Specifies the inclusion should apply to the copy of the JCL
written to a library as a result of the COPYJCL statement.

Note: Applies to JCL tailoring only, and not to symbolic
variable libraries.
347
%INCLUDE Statement, Continued

Usage notes The %INCLUDE statement cannot be used in an ESP Procedure.
The %INCLUDE parameter must start in Column 1. If you want to include a
statement with the characters %INCLUDE starting in column 1, but to have it
treated as data rather than a control statement, code %%INCLUDE. The first percent
sign is removed.
The %INCLUDE statement can be continued onto a second line by placing a + or
- on the last non-blank character of the line. A + strips leading blanks from the
next line, whereas a - does not. Only one continuation per statement is allowed.
The scope of an %INCLUDE statement includes data until one of the following
statements is encountered:
%INCLUDE statement
%EXCLUDE statement
%ENDINCL statement
%ENDEXCL statement.
If no parameters are specified, the data following the %INCLUDE statement is
always included.
If you specify a FROM date but no TO date, a TO date of January 1st 2042 is
assumed. Similarly, if you omit a FROM date, a date of January 1st 1900 is
assumed.
If no time is specified, 00:00 is assumed for the FROM and TO parameters.
The FROM and TO parameters are based on the scheduled date.
ESP decides what to include in the JCL when it submits the job.

Usage notes
continued
Note: Before using the %INCLUDE statement, check with your system
change them.

Related
information
statement.
For information on ending the selective inclusion of JCL and DATA, see the
%ENDINCL statement.
348

Example 1 The following %INCLUDE statement used in a symbolic variable library requests
the inclusion of data on Mondays:
PARM=ABC
%ENDINCL
In the above example, the value of PARM resolves to ABC on Mondays.

Example 2 The following %INCLUDE statement used in JCL requests the inclusion of a DD
%ENDINCL
In the above example, the DD statement INPUT05 is included on Mondays.

Example 3 The following %INCLUDE statement used in a symbolic variable library requests
the inclusion of data on different days of the week:
%INCLUDE IF(TODAY(MON,WED,FRI))
DIVISION=123
%INCLUDE IF(TODAY(TUE,THU,SAT))
DIVISION=456
%ENDINCL
In the above example, the value of DIVISION resolves to 123 on Monday,
Wednesday or Friday and to 456 on Tuesday, Thursday or Saturday. These days
refer to the scheduled days of the Event.
349

Example 4 The following %INCLUDE statements used in JCL request the inclusion of various
steps:
//CYBERJOB JOB CYB999,CLASS=A,MSGCLASS=S
%INCLUDE IF(ESPSDATE=ESPADATE)
%INCLUDE IF(ESPATIME GT 07.59.00)
%INCLUDE FROM(MAY 1,1997) TO(MAY 5,1997)
%INCLUDE IF(ESPAHH GE 08 AND ESPAHH LE 14 AND -
TODAY(WED))
%ENDINCL
STEP1 is included whenever ESP submits the job
STEP2 is included when the actual and scheduled date are equal
STEP3 is included when the actual time is greater than 07.59.00
STEP4 is included from May 1,1997 to midnight on May 4,1997. This is based
on the scheduled date.
STEP5 is included if the actual is between 8am and 2pm and the scheduled day
is Wednesday.

Other examples Here are more examples using the %INCLUDE statement.
Request inclusion if the value of CYCLE_NUMBER is equal to 9:
%INCLUDE IF(CYCLE_NUMBER=9)
Request inclusion if the actual hour is greater that 09 and today is not Friday:
%INCLUDE IF(ESPAHH GT 09 AND TODAY(NOT FRIDAY))
Request inclusion if a started task called CICSPROD is active:
%INCLUDE IF(ACTIVE(CICSPROD))
Request inclusion if today is the last day of the year:
%INCLUDE IF (TODAY(LAST DAY OF YEAR))

350
INET Command

Overview The INET command is used to display and manipulate TCP/IP attributes.

Authority OPER authority is required to issue the INET command.

Syntax The syntax of the INET command is:
INET {DISPLAY} {ACTIVE}
{CLOSE}
{HOST_CACHE}
{TCPIP}
{TRACE}
{FLUSH HOST_CACHE}
{HELP}
{PURGE {ID socketid|TASK taskid}}
{QUERY HOST hostname}
{SET} {TRACE} SYSOUT(class)
{CLOSE {RESET|SHUTDOWN}}
{HOST_CACHE TTL(seconds)}
{SPIN} {TRACE}
{START} {TRACE}
{STOP} {TRACE}

DISPLAY Displays a TCP/IP object. The following options are
supported:
INET DISPLAY ACTIVE
CLOSE
INET DISPLAY HOST_CACHE
INET DISPLAY TCPIP
INET DISPLAY TRACE
ACTIVE Display of all active TCP/IP sockets.
CLOSE Displays the current TCP/IP close option.
(RESET or SHUTDOWN)
HOST_CACHE Displays the ESP TCP/IP host cache entries.
TCPIP Displays information on the current TCP/IP stack.
TRACE Displays TCP/IP tracing facility.
FLUSH FLUSH HOST_CACHE flushes the ESP TCP/IP host cache.
This is useful if a host cache entry has become invalid
because of a modification to a host entry in the TCP/IP
networks Domain Name System (DNS) configuration.
HELP Displays all the INET command options.
PURGE Purges a TCP/IP socket or all TCP/IP sockets running under a
specified task.
QUERY HOST
hostname
Displays the TCP/IP address of a host. The short form is:
INET Q H hostname.
351
INET Command, Continued
ID Requests that an active socket be purged.
Note: This option is not supported if IBMs IUCV is the
TCP/IP stack.
socketid Displays a list of currently active TCP/IP sockets.
TASK Displays a list of currently active TCP/IP sockets and their
respective task IDs.
taskid Displays a list of currently active TCP/IP sockets and their
respective task IDs.
SET Sets a TCP/IP object.
SYSOUT(class) Indicates a print data set for the TRACE log SYSOUT.
CLOSE This parameter should only be used under the direction of
Cybermation technical support. It tells ESP and Workstation
server how to close a TCP/IP connection, either gracefully
(SHUTDOWN) or forcefully (RESET). The default is
SHUTDOWN.
HOST_CACHE
TTL
Used to activate or de-activate ESP TCP/IP host caching, or
to reset the time to live(TTL) interval. Seconds is the time to
live value within the range 0-99999999. A value of zero(0)
de-activates ESP TCP/IP host caching. This command can
also be specified in the Initialization Parameters.
SPIN Spins a TCP/IP object. Currently the only supported option
is:
INET SPIN TRACE
The TCP/IP trace sysout file is closed and deallocated. A
new one is then immediately allocated and opened.
START Starts a TCP/IP object. Currently the only supported option
is:
INET START TRACE
A TCP/IP trace sysout file is allocated and opened. Before
the TCP/IP trace file can be started, it must be set to a sysout
class by the INET SET TRACE SYSOUT(class) command.
STOP Stops a TCP/IP object. Currently the only supported option
is:
INET STOP TRACE
The TCP/IP trace file is closed and de-allocated.
Example 1 The following INET command is used to list INET options:
INET HELP
In the above example, all of the INET command parameters are displayed.
352
INET Command, Continued

Example 2 The following INET command is used to display TCP/IP sockets:
INET DISPLAY ACTIVE
In the above example, all active TCP/IP sockets are displayed.
Example 3 The following INET command is used to purge all TCP/IP sockets:
INET PURGE TASK 78E0
In the above example, all TCP/IP sockets running under task ID 78E0 are purged.
Examples of
Host Caching
TTL
The following short form of the INET SET HOST_CACHE command activates ESP
TCP/IP host caching and sets the time to live interval for each host cache entry to
one hour:
INET T HC TTL(3600)
The following short form of the INET SET HOST_CACHE command deactivates
ESP TCP/IP host caching:
INET T HC TTL(0)
353
INFOCOMM Command

Overview The INFOCOMM command is used to control transaction servers used in sending
Infoserv requests. Transaction server identifiers are used on the INFOSERV
command when issuing requests.


Authority OPER authority is required to issue the INFOCOMM command.

Syntax The syntax of the INFOCOMM command is:
INFOCOMM {DEFINE|DISPLAY|DELETE}
[serverid]
[CLIENT(clientname)]
[TPAPPL(applname)]

DEFINE Indicates a new server transaction be added.
DISPLAY Indicates information on all (or specific) servers for the
current Application be displayed. Information displayed
includes serverid, client name and TP Application name.
DELETE Indicates the deletion of a transaction server.
serverid Indicates a logical server identifier of up to 25 characters.
This identifier is specified on the INFOSERV command when
sending a request.
clientname Indicates a client name of up to eight characters for your
Application. This client must be defined to Infoserv via the
CLIDEF command.
applname Indicates a 1-44 character TP Application name of the
Infoserv task to which this transaction server will send its
requests. The applname is defined in the Infoserv TP
parameter data set.

Usage notes For each client defined to Infoserv you must define a transaction server that will
transmit requests to Infoserv via the LU6.2 Communications Facility (TP Server).
INFOCOMM definitions are normally stored in the ESP Initialization Parameter
data set.
354
INFOCOMM Command, Continued

Related
information
For information on ESP Workload Managers interface to IBMs
Information/Management product, see the Infoserv Installation and Users Guide.
For information on generating a request that is sent to Infoserv, see the INFOSERV
command.
For information on inter-system communication, see the TP Server Installation and
Users Guide.

Example 1 The following INFOCOMM command defines a transaction server:
INFOCOMM DEFINE INFO1 CLIENT(ESP) TPAPPL(INFOSERV_MAIN)
In the above example, a new transaction server called INFO1 is defined. The client
name for this Application is ESP and must be defined to Infoserv using the CLIDEF
command. The INFO1 transaction server will send requests to the
INFOSERV_MAIN TP Application.

Example 2 The following INFOCOMM command is used to display transaction servers:
INFOCOMM DISPLAY
In the above example, all existing transaction servers are displayed.

Example 3 The following INFOCOMM command is used to delete a transaction server:
INFOCOMM DELETE INFO1
In the above example, a transaction server called INFO1 is deleted.

355
INFOMSG Command

Overview The INFOMSG command is used to display informational, warning and error
messages in the body of the screen. Normally these messages are displayed in the
upper right corner of the screen with an alarm sound.


Syntax The syntax of the INFOMSG command is:
INFOMSG SET|RESET
[PREFIX(string)]

SET Indicates messages should be displayed within the body of the
screen. This includes the full message text and ESP message
number.
PREFIX(string) Indicates displayed messages should be prefixed with a user
specified string. PREFIX can be abbreviated to PR. This
parameter is optional.
RESET Indicates messages should be returned to their normal
position in the upper right corner of the screen.

Usage notes The INFOMSG command is valid only from within Page mode.
If you exit from Page mode and re-enter, you need to re-issue the INFOMSG
command.
When the INFOMSG command is set, messages are within the screen text.
You can have the messages prefixed with any string by specifying a string when
issuing the INFOMSG command.

Example 1 The following is an example of what an informational message looks like when the
INFOMSG command is not set:
ESP -------------------------------- NO MATCHING APPLICATIONS
COMMAND ===>

----------------------- TOP OF DATA --------------------------
LAP PAYROLL OLDEST
In the above example, a request is made to display the oldest generation of the
PAYROLL Application. An informational message indicates there are no matching
Applications.
356
INFOMSG Command, Continued

Example 2 The following is an example of what an informational message looks like when the
INFOMSG command is set:
ESP --------------------------------------- ROW 1 COLUMN 1 --
COMMAND ===>
----------------------- TOP OF DATA --------------------------
INFOMSG SET
LAP PAYROLL OLDEST
ESP1142W NO MATCHING APPLICATIONS DEFINED OR AUTHORIZED
In the above example, a request is made to display the oldest generation of the
PAYROLL Application. An informational message indicates there are no matching
Applications is displayed within the body of the screen.

Example 3 The following INFOMSG command resets informational messages:
INFOMSG RESET
In the above example, informational messages are displayed in the upper corner of
the screen.

Example 4 The following INFOMSG command prefixes information messages:
INFOMSG SET PREFIX(INFO_)
In the above example, informational messages are prefixed with INFO_.

357
INIT Command

Overview The INIT command is used to define and manipulate initiators in your model
process similar to the way you manipulate initiators using JES. The INIT command
is one of the components involved in defining your environment to produce
modeling reports that forecast how ESP processes a group of jobs in your particular
environment.

Type Model command.

Syntax The syntax of the INIT command is:
INIT {START(initnum)}
{SET(initnum)}
{STOP(initnum)}
[CLASS(classname)]
[CPU(cpunumber)]

START Indicates the initiator(s) in initnum is started on the specified
CPU. If the initiator is currently in a drained state, its
status is changed to inactive. The INIT START command
is ignored if the initiator is not currently in a drained state.
SET Indicates the class(es) of the initiator(s) in initnum are reset to
the specified classname. Any classes previously assigned to
the initiator(s) are replaced. The CPU that an initiator has
been started on may not be altered with the SET keyword.
STOP Indicates the initiator(s) in initnum is stopped. Any jobs
running in the specified initiator(s) is allowed to complete
and the initiator status is changed to drained.
initnum Indicates a number, range of numbers, or list of numbers and
ranges of numbers. Each number must be within the range 1-
999.
classname

Indicates up to eight character class names or list of class
names assigned to this initiator. The first character must be
alphabetic.
cpunumber Indicates a CPU number where the initiators are to be started.
The valid range is 0-7 (up to eight CPUs supported). If not
specified, the default is 0. The CPU keyword should only be
specified with the START keyword.
358
INIT Command, Continued

Usage notes Use the MAXINITS command to define the maximum number of initiators for the
model. This should include initiators across all CPUs. A maximum of 999 initiators
can exist for each model.
Initially, the number of initiators you specify on the MAXINITS command are in a
drained state. At any time during modeling, you can manipulate initiators on any
CPU.
Use INIT START, SET and STOP to start, alter and drain initiators any time during
the model process.

Related
information
For information on defining the maximum number of initiators, see the MAXINITS
command.
For information on beginning and ending the model process, see the MODEL and
ENDMODEL commands.

Example 1 The following INIT commands define initiators to be used during a model process:
MAXINITS 20
INIT START(1:10) CLASS(A,B,C)
INIT START(11:15) CLASS(D,E)
INIT START(16:20) CLASS(F)
Initiators 1 to 10 are started and set to classes A, B and C
Initiators 11 to 15 are started and set to class D and E
Initiators 16 to 20 are started and set to class F
Note: Any time during the model process you can manipulate initiators similar to
the way initiators are manipulated in your environment using the START, SET and
STOP parameters of the INIT command. For example, if required, initiators 16 to
20 could be drained by issuing the following command:
INIT STOP(16:20)
359
INPUT Command
Overview The INPUT command is used to request that ESP read in other records from a data
set other than an active history file. Use any VSAM, KSDS, ESDS or non-VSAM
sequential data set as input. The data records must be of the exact same format as the
ESP history file records.
Syntax The syntax of the INPUT command is:
INPUT {DATASET(dsname)}
{FILE(filename)}
dsname Indicates the name of the input data set. This is mutually
exclusive with the FILE option.
filename Indicates the name of the input file name. This is mutually
exclusive with the DATASET option.
Usage notes This option is most useful when used with files created as a result of the COPY
reporting command or when the ESP subsystem is down. The INPUT command
does not require the presence of the subsystem.
Specify any number of INPUT commands - they may be intermixed with HISTFILE
statements. The data sets are processed in the order of their respective INPUT
statements.
Related
information
REPORT
INPUT DATASET(CYBER.ESP.HISTORY1)
FROM 7AM YESTERDAY
ENDR
In the above example, the INPUT command is used to request that ESP read history
records from CYBER.ESP.HISTORY1 instead of the active history file.
360
INPUTDS Statement
Overview The INPUTDS statement is used to extract tape volume serial information during a
scheduled activity data set generation run. ESP references the tape management
catalog when it generates the scheduled activity data set.
Syntax The syntax of the INPUTDS statement is:
INPUTDS dsname(genno)
dsname Indicates the name of tape input data set.
genno Indicates a relative generation number. This must be zero or a
negative number.
Usage notes ESP can generate a data set using this extracted information and feed the data set
into the TMS or CA1 tape pull program.
To use the INPUTDS statement to generate a data set to use as input to the TMS or
CA1 tape pull program, take the following steps:
1. Use the INPUTDS statement in the ESP Application, identifying the tape data
sets associated with each job
2. Generate a scheduled activity using the SADGEN command in a batch job
3. Use the LSAR subcommand specifying TAPEPULL(dsname), where dsname is
the preallocated PDS to store tape data set information
4. Reinitialize the TAPEPULL data set before you generate the scheduled activity
data set
5. Use this PDS as input to the TMS or CA1 tape pull program.
Related
Statements
For information on extracting tape information, see the ESP Workload Manager
Users Guide.
361
INPUTDS Statement, Continued
Example 1 The following INPUTDS statements indicate the tape data sets associated with each
job in an Application:
APPL PAYROLL
JOB PAYJOB1
RUN DAILY
RELEASE PAYJOB2
INPUTDS PROD.PAY.ACCT(-1)
ENDJOB
JOB PAYJOB2
RUN DAILY
INPUTDS PROD.PAY.BACKUP(0)
ENDJOB
In the above example, two input data sets are identified as follows:
For PAYJOB1, -1 generation of PROD.PAY.ACCT is identified as its input
data set
For PAYJOB2, the current generation of PROD.PAY.BACKUP is identified
as its input data set.

362
INTEGER Statement

Overview The INTEGER statement is used to define an integer variable before its first
assignment statement.

Type ESP Procedure statement, Symbolic variable library statement.

Syntax The syntax of the INTEGER statement is:
INTEGER varname[,varname...]

varname Indicates the name of the variable to be defined. A list of
variable names can be specified, separating each with a
comma or space.

Usage notes Use integer symbols if you want to assign arithmetic values or expressions to them,
and manipulate them as numbers, such as A=2+2 and NUMBER=999. You must
first use an INTEGER statement to define an integer symbol before you can assign a
value to it.
An integer variable differs from a character variable in the way the value is stored.
When you assign a string to an integer variable, the string must consist of a valid
arithmetic expression. The expression is evaluated and the result stored as a full
word binary number.
If you assign a character string to an integer variable, ESP evaluates the character
string as if it were an arithmetic expression and then stores the result as an integer.
If you want an INTEGER variable to be available inside and outside an IF block,
then declare it outside of the block.
An integer assigned a value within the scope of a JOB statement is available only for
that job in Application process mode. In Application generation mode, an integer
has the value assigned to it by the last executed assignment statement.
ESPs built-in symbolic variables, ESPA and ESPS, are not available in Page mode,
and can not be assigned to integer variables in Page mode.

Related
information
For information on working with user defined symbolic variables, see the ESP
363
INTEGER Statement, Continued

Example 1 The following INTEGER statement defines an integer variable:
INTEGER X
X=2
In the above example, variable X is defined as an integer variable and assigned the
value of 2.

INTEGER A
A=5*25
In the above example, variable A is defined as an integer variable and assigned the
value of 125.

INTEGER B
B=%ESPADOW#
In the above example, variable B is defined as an integer variable and assigned the
value of the current day of the week number. If, for example, today is Thursday, B
is assigned a value of 5.

Example 4 The following INTEGER statement defines integer variables:
INTEGER C,D
D=%ESPSDDD
C=(%D-1)/7+1
In the above example, variables C and D are first defined as integer variables. D is
assigned the current day of year number. C is then given a value that resolves to the
week of year number.
Note: %ESPSDDD represents a number but is stored in character format. In order
to work with this as a number, you must first assign it to an integer variable.
364
INTEGER Statement, Continued

Example 5 The following INTEGER statement defines a integer variables outside an IF block:
INTEGER E,F
E=222
F=444
IF TODAY(MONDAY) THEN PARM=%E
ELSE PARM=%F
In the above example, defining the integer outside the IF block, makes it available
inside and outside the block.

365
INVOKE Command

Overview The INVOKE command is used to invoke an ESP Procedure. The INVOKE
command can be used as part of an Event definition, or from within an ESP
Procedure to invoke another ESP Procedure.

Type Event definition command, ESP Procedure command.

Syntax The syntax of the INVOKE command is:
INVOKE dataset(member)

dataset Indicates the name of the data set that contains the ESP
Procedure. The data set and member must be enclosed in
quotes.
member Indicates the name of the member that contains the ESP
Procedure you want invoked.

Usage notes To invoke an ESP Procedure from an Event, you must first create the Procedure and
then define the Event to invoke that Procedure.
ESP allows multiple INVOKE commands within an Event or ESP Procedure.
However, an Event can only generate one Application. To invoke more than one
Application requires one Event per Application.

Related
information
For information on invoking an ESP Procedure from an Event, see the ESP
For information on invoking an ESP Procedure from another ESP Procedure, see the

Example 1 The following is an example of an Event definition that invokes an ESP Procedure:
SCHEDULE 10PM WEEKDAYS
INVOKE CYBER.PROCS.CNTL(PAYJOBS)
ENDDEF
In the above example, the PAYJOBS ESP Procedure is invoked every weekday at 10
pm.
366
INVOKE Command, Continued

Example 2 The following is an example of an ESP Procedure that invokes another ESP
Procedure:
APPL PAYROLL
INVOKE CYBER.SYMBOLS.CNTL(DATES)
JOB PAYJOB1
RUN WORKDAYS
REL PAYJOB2
JOB PAYJOB2
RUN WORKDAYS
ENDJOB
In the above example, every time the PAYROLL Application is invoked, the
DATES ESP Procedure is also invoked. The DATES ESP Procedure contains built-
in or user defined symbolic variables required by the jobs in the PAYROLL
Application.

367
JCLLIB Statement

Overview The JCLLIB statement is used to identify the JCL library you want to use for all jobs
following this statement. When ESP encounters a JOB statement, it uses the JCL
member in the JCLLIB with the same name as the job. You can use the MEMBER
statement to override this action.


Syntax The syntax of the JCLLIB statement is:
JCLLIB 'dsname'

dsname Indicates the name of the data set where the JCL resides. The
data set name must be enclosed in quotes.

Usage notes This statement can be used to specify the JCL library you want to use throughout the
ESP Application unless it is explicitly overridden for a particular job with the
DATASET statement. This means that you only have to specify the JCL library
once for each Application. Unless the member name is explicitly overridden with
the MEMBER statement, the member name is assumed to be the same as the
jobname.

Related
information
For information on identifying JCL libraries, see the ESP Workload Manager Users
Guide.
For information on specifying a temporary or override JCL library, see the
TEMPLIB statement.
For information on specifying an optional JCL library for an individual job, see the
DATASET statement.
For information on specifying the member name in which ESP finds a jobs
execution JCL, see the MEMBER statement.
368
JCLLIB Statement, Continued

Example 1 The following JCLLIB statement identifies the JCL library to be used:
APPL PAYROLL
JOB PAYJOB1
RUN DAILY
REL PAYJOB2
JOB PAYJOB2
RUN DAILY
ENDJOB
In the above example, ESP submits all jobs in the PAYROLL Application from
CYBER.JCL.CNTL.

Example 2 The following JCLLIB, MEMBER and DATASET statements specify different JCL
libraries and members:
APPL PAYROLL
JOB PAYJOB3
RUN DAILY
REL PAYJOB4
MEMBER PAYJOB99
JOB PAYJOB4
RUN DAILY
ENDJOB
ESP uses the default JCL library CYBER .JCL.CNTL to submit PAYJOB3s
execution JCL from member PAYJOB99
ESP uses CYBER.ALTJCL.CNTL to submit PAYJOB4s execution JCL.

Example 3 The following JCLLIB statement specifies the PANVALET library to be used:
PROD.ESP.JOBS as the default JCL library.
APPL PAYROLL
JCLLIB PAN-PROD.ESP.JOBS
JOB PAYJOB1
RUN DAILY
REL PAYJOB2
JOB PAYJOB2
RUN DAILY
ENDJOB
In the above example, ESP will submit all jobs in the PAYROLL Application from a
PANVALET library called PROD.ESP.JOBS.
369
JCLLIB Statement, Continued

Example 4 The following JCLLIB statements identify different JCL libraries for job in an
Application:
APPL PAYROLL
JCLLIB CYBER.JCL.LIB1
JOB PAYJOB1
RUN DAILY
ENDJOB
JOB PAYJOB2
RUN DAILY
ENDJOB
JCLLIB CYBER.JCL.LIB2
JOB PAYJOB3
RUN DAILY
ENDJOB
In the above example, ESP submits PAYJOB1 and PAYJOB2 from
CYBER.JCL.LIB1. ESP submits PAYJOB3 from CYBER.JCL.LIB2.

370
JESCOMCH Command

Overview The JESCOMCH command is used to specify the character used to prefix JES
commands. Normally this is specified as an Initialization Parameter.


Authority OPER authority is required to issue the JESCOMCH command.

Syntax The syntax of the JESCOMCH command is:
JESCOMCH character

character Indicates the character used as a JES command prefix. If a
punctuation character (such as a semi-colon) is used, it must
be enclosed in quotes. The default character is $.

Usage notes Use this command if your installation uses a character other than the dollar ($)
symbol to prefix JES commands. Use single quotes to enclose the chosen prefix if it
is a punctuation character.

Related
information
For information on specifying a character used to prefix JES commands at the
initialization parameter level, see the ESP Workload Manager Installation Guide.

Example 1 The following JESCOMCH command specifies a character used to prefix JES
commands:
JESCOMCH #
In the above example, the number sign (#) is used to prefix JES commands.

371
JESTYPE Command

Overview The JESTYPE command is used to specify the type of JES used by your installation.
Normally this is specified as an Initialization Parameter.


Authority OPER authority is required to issue the JESTYPE command.

Syntax The syntax of the JESTYPE command is:
JESTYPE [2|3]
[DJC|NODJC]

2 Indicates JES2 is in use. This is the default.
3 Indicates JES3 is in use.
DJC Indicates normal processing for DJC networks.
NODJC Indicates existing DJC networks should be processed as
Applications.

Usage notes This command enables ESP to detect differences in processing requirements for the
JES3 subsystems compared with JES2. You may use the NODJC parameter to have
existing DJC networks converted to Applications without the need to modify
individual ESP Procedures.

Related
information
For information on specifying the type of JES used by your installation at the
Initialization Parameter level, see the ESP Workload Manager Installation Guide.

Example 1 The following JESTYPE command specifies the type of JES in use:
JESTYPE 3
In the above example, JES3 is the subsystem in use.

372
JOB Statement

Overview The JOB statement is used to identify the name of a job in an Application. The JOB
statement must be used before identifying other job requirements such as
predecessor and successor relationships and run frequencies.


Syntax The syntax of the JOB statement is:
JOB jobname[.qualifier]
[REQUEST|NOREQUEST]
[TASK [OWNER(Applowner|manager)]|NOTASK]
[LINK [PROCESS|NOPROCESS] [OWNER(Applowner|manager)]|NOLINK]]
[MANUAL|NOMANUAL[SCOPE(hh.mm,hh.mm)]
[AUTHSTR(string)]]
[NODE|NONODE]
[INHERIT|NOINHERIT]
[EXTERNAL|NOEXTERNAL[SCOPE(hh.mm,hh.mm)]
[AUTHSTR(string)]
[APPLID(applname)]
[SCHEDULED(criteria)]]
[CONDITIONAL|NOCONDITIONAL]
[HOLD|NOHOLD]
[CRITICAL|NOTCRITICAL]
[DOCMEM(docmember)]

jobname Indicates a jobname of up to eight characters.
qualifier Indicates a job qualifier of up to eight characters. It must
immediately follow the jobname separated by a period.
REQUEST Indicates this is an on-request job.
NOREQUEST Indicates this is not an on-request job. This is the default.
TASK Indicates this is a task that requires manual completion.
ESP does not try to submit JCL for a TASK.
NOTASK Indicates this is not a task that requires manual completion.
OWNER Indicates the name of the owning ESP Manager for Links
and Tasks. Specify a valid Manager name, up to 16
alphanumeric characters in length, where the first character
must be alpha or a national character. If you do not specify
OWNER, the owning Manager of the Application is the
default. The owning Manager is the only one with authority
to update the status of a workload object.
LINK Indicates this is a task that does not require manual
completion. ESP does not try to submit JCL for a LINK.
NOLINK Indicates this is a task that does require manual completion.
PROCESS Indicates you want to use a LINK to issue commands.
373
JOB Statement, Continued
NOPROCESS Indicates you do not want to use a LINK to issue
commands. This is the default.
MANUAL Indicates this job is manually submitted, outside of ESP.
NOMANUAL Indicates this job is not being submitted, outside of ESP.
string Indicates an authorization string as defined by the
AUTHSTR Initialization Parameter. This can only be used
with the EXTERNAL and MANUAL keywords.
NODE Indicates a job is a node for inheriting job relationships. No
relationships pass through a node. A relationship between a
predecessor and a successor to the node exists only when
ESP selects the node. Inherited relationships among the
node and its successors still exist.
NONODE Indicates a job is not a node for inheriting job relationships.
INHERIT This is the default.
NOINHERIT Indicates job relationships should not be inherited.
EXTERNAL Indicates a job is submitted by another ESP Application.
The EXTERNAL parameter is used to build inter-
Application dependencies.
NOEXTERNAL Indicates a job is not submitted by another ESP
Application. This is the default.
hh:mm Indicates the number of hours ESP is to do a backward
and/or forward search in the scheduled activity data set for
a job. The first parameter indicates how far back the
Application manager should look; the second parameter
indicates how far ahead it should look. This parameter can
be a maximum of 12 characters. SCOPE can be used with
the EXTERNAL and MANUAL keywords for jobs in an
Application.
applname Indicates the name of the Application that submits the job.
criteria Indicates a scheduled time or range for the scheduled time
of the Event that submits the job or the trigger time issued
for non-scheduled Events.
CONDITIONAL Indicates this job may or may not execute. The Application
this job belongs to is considered complete when all
NOCONDITIONAL jobs are complete.
NOCONDITIONAL Indicates this job must complete in order for the
Application to be considered complete. This is the default.
HOLD Indicates a job is to be placed on manual hold when ESP
generates the Application. You can release a job from
manual hold using the CSF or the APPLJOB (AJ)
command.
NOHOLD Indicates a job is not to be placed on manual hold when
ESP generates the Application. This is the default.
374
CRITICAL Indicates this job represents a critical point in the
Application. The longest path to this job, in terms of
execution time (based on history) is identified as the critical
path.
NOTCRITICAL Indicates this job does not represent a critical point in the
docmember Indicates a job documentation member with a name other
than the jobname should be referenced. The default is to
reference a member name the same as the jobname.

Usage notes The JOB statement defines the beginning of a job definition. The ENDJOB
statement or another JOB statement signifies the end of a job definition. You must
use an ENDJOB statement after defining all of your jobs.
ESP processes commands based on where they are placed within an Application as
follows:
ESP processes commands outside the scope of JOB statements when the
Application is generated and every time a job becomes eligible (i.e., all
dependencies met)
ESP processes commands within the scope of a JOB statement only when the
job becomes eligible (i.e., all dependencies met).
Statements placed within the scope of the job are referred to as job specific
statements, whereas statements placed outside the scope of a job statement are
referred to as global statements.
You can define jobs in any order. ESP submits the jobs based on how you define the
job relationships.
By default, the member name of the JCL library used is the same as the jobname. To
override this, use the MEMBER statement and specify the name of the member that
contains the JCL for the job. The jobname must match the name specified on the job
card.
A NOINHERIT job that is not selected blocks any dependency chain passing
through it. Thus, any job released either directly or indirectly by such a job is
independent of any ancestor(s) of the blocking job.
A NOINHERIT job that is selected does not allow a dependency chain to emanate
from it. In other words, such a job releases any selected immediate successor(s), but
does not pursue dependency chains through any unselected successor(s).
If you want to use Links and Tasks when the mainframe is unavailable, specify a
Distributed Manager as the OWNER of the Link or Task using the OWNER
parameter on the JOB or APPL statements.
375

Related
information
For information on ending a job definition, see the ENDJOB statement.

Example 1 The following is an example of an ESP Application:
APPL PAYROLL
JOB PAYJOB1
RUN DAILY
ENDJOB
In the above example, the JOB statement is used to identify PAYJOB1 as part of the
PAYROLL Application.

APPL PAYROLL
JOB PAYJOB1
RUN DAILY
REL PAYJOB2
JOB PAYJOB2 REQUEST
RUN DAILY
ENDJOB
In the above example, PAYJOB2 is defined as an on-request job.

APPL PAYROLL
JOB BALANCE.RPT TASK
RUN DAILY
ENDJOB
In the above example, BALANCE.RPT represents a manual task and must be
marked complete.
376

APPL PAYROLL
JOB PAYJOB3 EXTERNAL
RUN DAILY
REL PAYJOB4
JOB PAYJOB4.%ESPSDAY(1:3)
DUEOUT EXEC 9PM
RUN DAILY
ENDJOB
PAYJOB3 is defined as submitted by another ESP Application. The
EXTERNAL parameter is used to build a dependency between jobs from
different Applications
PAYJOB4 is a qualified job. The sub-string of an ESP built-in symbolic
variable is used to comprise the jobname. For example, if this Application was
scheduled on Wednesday, PAYJOB4s jobname resolves to PAYJOB4.WED. If
PAYJOB4 is not completed by 9 pm, it is flagged as overdue.

APPL PAYROLL
JOB PAYJOB5
RUN DAILY
REL (PAYJOB6(A))
RUN DAILY
ENDJOB
In the above example, PAYJOB6 is defined as a conditional job that is submitted
only if PAYJOB5 terminates abnormally.
377

APPL PAYROLL
JOB PAYJOB7 EXTERNAL SCHEDULED(YESTERDAY)
RUN LAST WORKDAY OF MONTH
REL PAYJOB8
JOB PAYJOB8
RUN LAST WORKDAY OF MONTH
ENDJOB
In the above example, PAYJOB7 is submitted by another ESP Application. On the
last workday of the month, ESP ensures PAYJOB7 from the previous day
completed. PAYJOB8 waits until this dependency is met. The RUN statement for
PAYJOB7 reflects the day on which you want ESP to check if the dependency is
satisfied.
APPL PAYROLL
CRITPATH ON
JOB PAYJOB1
RUN DAILY
REL (PAYJOB2,PAYJOB3)
JOB PAYJOB2
RUN DAILY
REL PAYJOB4
JOB PAYJOB3
RUN DAILY
REL PAYJOB4
JOB PAYJOB4 CRITICAL
RUN DAILY
ENDJOB
In the above example, PAYJOB4 is identified as the critical point in the PAYROLL
Application. ESP calculates the longest path to this job based on historical
execution times and identifies this path as the critical path.
Example 8 The following example defines a Distributed Manager as the owning Manager of
this Link:
JOB A LINK OWNER(DMCHI)
378

Other examples Here are more examples of using the JOB statement.
Indicates that a message is sent when critical jobs within the Application have
completed successfully:
JOB CRITICAL.POINT LINK PROCESS
AFTER (PAYJOB1,PAYJOB2,PAYJOB3)
RUN DAILY
SEND CRITICAL JOBS COMPLETED AT %ESPATIME USER(CYB01)
ENDJOB
Indicates a manually submitted job. ESP looks back 24 hours to see if the job has
completed successfully. If it has not, ESP waits until it does:
JOB PAYJOB1 MANUAL SCOPE(-24)
RUN DAILY
REL PAYJOB2
ENDJOB
Indicates this job is submitted as part of the BILLING Application. ESP posts
PAYJOB1 complete, when todays scheduled run of PAYJOB1 completes
successfully in the BILLING Application. If PAYJOB1 has already completed
successfully when this Application is generated, ESP marks PAYJOB1 complete at
generation time:
JOB PAYJOB1 EXTERNAL SCHEDULED(TODAY) APPLID(PAYROLL)
RUN DAILY
REL PAYJOB2
ENDJOB
Indicates you wish to reference a job documentation member with a name other than
the jobname:
JOB PAYJOB1 DOCMEM(SPECIAL)
RUN DAILY
ENDJOB

379
JOBATTR Statement

Overview The JOBATTR statement is used to change a jobs attributes within the scope of a
JOB statement or in job documentation.


Syntax The syntax of the JOBATTR statement is:
JOBATTR [EXTERNAL|NOEXTERNAL]
[MANUAL|NOMANUAL]
[LINK|NOLINK]
[TASK|NOTASK]
[REQUEST|NOREQUEST]
[PROCESS|NOPROCESS]
[CONDITIONAL|NOCONDITIONAL]
[HOLD|NOHOLD]
[INHERIT|NOINHERIT]
[NODE|NONODE]
[SCHEDULED(criteria)]
[SCOPE(hh.mm,hh.mm)]
[AUTHSTR(authstring)]
[APPLID(applname)]

attributes Indicates the attributes of the job you want to change. You
can specify more than one attribute by separating them with a
comma or space. The attributes are listed above. For more
information on the job attributes listed above see the JOB
statement.

Usage notes You may want to define a job with different attributes in special situations. For
example, on a particular day you may want to define a job on hold, whereas on other
days you do not want the job defined on hold. Instead of defining the job multiple
times with job qualifiers or using IF logic around a JOB statement, you can use the
JOBATTR statement.
Using JOBATTR statements in conjunction with IF logic, allows jobs to have
cumulative job attributes. For example, if a job is a conditional job on Mondays,
and a request job on the first workday of the month, combining JOBATTR
statements with IF logic provides for a cumulative effect when Monday is also the
first workday of the month; i.e. the job is a conditional request job.
380
JOBATTR Statement, Continued

Related
information
For information on identifying the names of jobs in an Application, see the JOB
statement.

Example 1 The following JOBATTR statement changes a jobs attributes:
APPL PAYROLL
JOB PAYJOB1
IF TODAY(MONDAY) THEN JOBATTR HOLD
RUN DAILY
ENDJOB
In the above example, PAYJOB1s attributes are changed to define the job on hold
every Monday.

APPL PAYROLL
JOB PAYJOB2
IF TODAY(FRIDAY) THEN JOBATTR HOLD
IF TODAY(LAST WORKDAY OF MONTH) THEN JOBATTR REQUEST
RUN DAILY
ENDJOB
PAYJOB2 runs daily
On Fridays, PAYJOB2 has an attribute of HOLD
On the last workday of the month, PAYJOB2 has an attribute of REQUEST.
When the last workday of the month is a Friday, PAYJOB2 has attributes of
HOLD and REQUEST.
381
JOBATTR Statement, Continued

APPL PAYROLL
JOB PAYJOB3
IF TODAY(SUNDAY) THEN +
JOBATTR EXTERNAL SCHEDULED(YESTERDAY)
RUN SATURDAY SUNDAY
REL PAYJOB4
JOB PAYJOB4
RUN SUNDAY
ENDJOB
In the above example, PAYJOB3 uses the JOBATTR statement to define the job as
an External job on Sundays. On Sunday, ESP looks back to the previous day
(YESTERDAY) to see if PAYJOB3 completed successfully. If it has, PAYJOB3 is
marked complete when the Application is built, otherwise it waits for PAYJOB3 to
complete.

Example 4 The following JOBATTR statements changes a jobs attributes:
APPL PAYROLL
JOB PAYJOB1 CRITICAL
RUN WORKDAYS
IF TODAY(LAST WORKDAY OF MONTH) THEN JOBATTR NOTCRITICAL
ENDJOB
In the above example, PAYJOB1s attributes are changed on the last workday of the
month such that critical path analysis is performed every day except the last
workday of the month.

382
JOBINFO Command

Overview The JOBINFO command is used to display job documentation. You can display all
information for a job or display selected information as identified by fields and
labels.


Authority OPER authority is required to issue the JOBINFO command.

Syntax The syntax of the JOBINFO command is:
{JOBINFO|JI} {jobname}
{jobid }
[ABENDS[(abid[,abid]...)]]
[AFTER]
[CCFAIL]
[COREQ]
[DATASET]
[DJCDATA]
[DUEOUT]
[FUNCTION]
[HISTFILE]
[INPUTDS]
[MEMBER]
[MESSAGES[(msgid[,msgid]...)]]
[MODEL]
[OPERDATA]
[PNODES]
[POSTREQ]
[PREREQ]
[PROGRAMMER]
[RELEASE]
[FIELD(field[,field...])]
[ALL]

jobname Indicates the name of the job for which you want to display
information (i.e. PDS member name).
jobid Indicates the JES jobid of the job for which you want to
display information.
abid Displays information concerning the specified ABEND
code(s). If ABENDS is specified without Parameters, all
possible ABEND codes for the job are displayed.
AFTER Displays names of jobs that are predecessors to this job, and
release this job for processing.
CCFAIL Displays condition codes that should cause a job to fail.
COREQ Displays names of other jobs that are automatically selected
and can run concurrently with this job.
383
JOBINFO Command, Continued
Syntax (continued)
DATASET Displays the JCL library used for the job.
DJCDATA Displays ESP/DJC net control statements for this job.
DUEOUT Displays due out times from P-Nodes.
FUNCTION Indicates the function of the job.
HISTFILE Displays the name of the history-recording file for the job.
INPUTDS Displays the tape data sets required for the job.
MEMBER Indicates the member name in which ESP finds the jobs
execution JCL. The default is member name equal to
jobname.
msgid Displays information concerning all specified message ID(s).
If MESSAGES is specified without parameters, all possible
messages for the job are displayed.
MODEL Displays the name of the tracking model for the job.
OPERDATA Displays a string of operator data (e.g. a title).
PNODES Displays names of the P-Nodes specified for the job.
POSTREQ Displays the names of jobs that are automatically selected and
executed following execution of this job.
PREREQ Displays the names of jobs that are automatically selected and
executed before execution of this job.
PROGRAMMER Displays the programmer name.
RELEASE Displays the names of jobs that are successors to this job, and
which this job releases for processing.
field Displays information contained in user-defined fields. Up to
50 fields can be requested separated by a comma.
ALL Displays all job documentation information for this job. This
is the default.
384
Usage notes Use the JOBINFO command at any time to display job information in any amount of
detail. You can request a display of one field only, such as FUNCTION, or any
combination of available keywords. Separate fields with a comma or a space. You
must specify the word FIELD for retrieving user-defined fields.
The information displayed comes directly from the job documentation library. If
any overrides were specified, for example in an ESP Procedure, this is not reflected
in the display that is generated.
Although you can specify multiple fields, ESP can only display data on a particular
field if you have coded it in your job documentation member.
If no optional fields are specified, all job documentation information on the job is
displayed. There are two versions of the command.
If JOBINFO is specified from a system console or from ESPs line or Page
mode preceded by OPER, information is retrieved from the JOBDOC libraries
identified in the started task Procedure.
If JOBINFO is specified from a TSO terminal without being preceded with
OPER, the JOBDOC libraries allocated in your LOGON Procedure or CLIST
are used.
Using the CSF to retrieve job documentation information (BD or ED), you cannot
select individual fields, as with the JOBINFO command.
The following table summarizes where and how you can retrieve job documentation
information:

Origin Command Retrieved from
Consolidated Status Facility BD or ED Library specified in the ESP
Application.
Page mode or line mode JOBINFO DOCLIB in ESP Application
or JOBDOC DD allocated to
your TSO session
Page mode or line mode OPER JOBINFO JOBDOC DD allocated to the
ESP started task.
Operator console F ESP,JOBINFO JOBDOC DD allocated to the
ESP started task.

Related
information
For information on job documentation, see the ESP Workload Manager Users
Guide.
For information on specifying a job documentation library in an ESP Application,
see the DOCLIB statement.
385

Example 1 The following JOBINFO command displays all job documentation information:
JOBINFO PAYJOB1
In the above example, all job documentation information for PAYJOB1 is displayed.

Example 2 The following JOBINFO command displays job documentation information:
JOBINFO PAYJOB2 FUNCTION DUEOUT ABENDS(SB37)
In the above example, information on the function, due out time and the specific
ABEND (SB37) information for job PAYJOB2 is displayed.

JOBINFO PAYJOB3 FIELD(PAGER)
In the above example, information about a user defined field is requested.

JI PAYJOB4 MESSAGES(Z001,X446) FIELD(SEVERITY,PAGER)
In the above example, information about for PAYJOB4 on two specific messages
and two user-defined fields is requested.

386
JOBMAP Command

Overview The JOBMAP command is used in conjunction with the MAPGEN command to
produce a list containing detailed information about jobs in Applications, including
their relationships to one another.


Syntax The syntax of the JOBMAP command is:
JOBMAP DSN(dsname)
[APPL(appl_id)]
[JOBINDEX]
[APPLINDEX]
[RESINDEX]
[NODISPLAY(list)]

DSN(dsname) Indicates the name of the map data set created by the
MAPGEN command.
APPL(appl_id) Indicates the name of the Application for which the
information is to be produced. If this parameter is omitted,
jobs from all Applications are selected.
JOBINDEX Produces an index of jobs after the job information pages.
APPLINDEX Produces an index of Application after the job information
pages.
RESINDEX Produces an index of resources after the job information
pages.
NODISPLAY(list) Indicates certain information is to be suppressed on the
output. This is a list of values. The possible values and the
data suppressed are listed below.
387
JOBMAP Command, Continued

Suppressed
fields
The NODISPLAY parameter lists fields that are not to be displayed, as follows:

Value Information Suppressed
EVENT Event name
CALENDAR Calendar name(s)
JCLDS JCL data set and member name
SCOPE Scope (externals and manuals only)
CLASS Job class
PGMER Programmer name
TAPES Tape drives and mounts (both cartridge and reel)
ELAPSED Elapsed execution time
CPU CPU time
HOLDCOUNT Hold count
PRED List of predecessor jobs
SUCC List of successor jobs
RESOURCE List of resources
PROC ESP Procedure data set and member name
TAG Tag
388

Usage notes Since the JOBMAP command uses the job mapping data set as input, you can report
only on jobs contained in that data set.
Special index pages to the primary report are produced only if the JOBINDEX,
APPLINDEX or RESINDEX parameters are specified on the JOBMAP command.
The job information pages contain the following for each job in the schedule:
Job name
Application name
Job type (job, request, manual, external, etc.)
Scheduled time
Event name
Calendar name(s)
JCL data set and member name
Indication if the JCL data set is a JCLLIB or TEMPLIB
Scope (externals and manuals only)
Job class
Programmer name
Tape drives and mounts (both cartridge and reel)
Elapsed execution time
CPU time
Hold count
List of predecessor jobs
List of successor jobs
List of resources
ESP Procedure data set and member name
Tag.

Related
information
For information on creating a job mapping data set, see the MAPGEN command.
For information on producing a job descendent tree report, see the JOBTREE
command.
389

Example 1 The following JOBMAP command produces a job map report:
JOBMAP DSN(CYBER.MAPGEN)
In the above example, a job map report is produced and information is obtained from
the CYBER.MAPGEN job mapping data set.
The following is a sample of the information produced by the above JOBMAP
command:
JOB NAME APPL NAME TYPE SCHEDULING
-------- --------- ---- -------------
PAYJOB1 APPL1 JOB SCHEDULED: DAILY
QUALIFIER:
EVENT: CYBER.PAYROLL
CALENDAR(S): SYSTEM
JCL: CYBER.JCL(PAYJOB1)
SCOPE:
CLASS:
PROGRAMMER: FRED
TAPES: REEL DRIVES: 0
REEL MOUNTS: 0
CART DRIVES: 0
CART MOUNTS: 0
ELAPSED: 0H 0M 0S

Example 2 The following JOBMAP command produces a job map report and suppresses certain
information:
JOBMAP DSN(CYBER.MAPGEN) NODISPLAY(ELAPSED,TAPES,CPU)
In the above example, a job map report is produced. Run time information, tape data
and CPU time information are suppressed. Information for this job map is obtained
from the CYBER.MAPGEN job mapping data set.
390

Example 3 The following JOBMAP command produces job map, job index and Application
index reports:
JOBMAP DSN(CYBER.MAPGEN) APPL(PAYROLL) JOBINDEX APPLINDEX
In the above example, a job map, job index and Application index reports are
produced for the PAYROLL Application. Information is obtained from the
CYBER.MAPGEN job mapping data set.
The following is a sample of the job index page produced by the above JOBMAP
command:
JOB INDEX PAGE
JOB NAME APPL NAME PAGE
-------- --------- ----
PAYJOB1 PAYROLL 1
PAYJOB2 PAYROLL 2
PAYJOB3 PAYROLL 2
END OF LIST
The following is a sample of the Application index page produced by the above
JOBMAP command:
APPLICATION INDEX PAGE
APPL NAME JOB NAME PAGE
--------- -------- ----
PAYROLL PAYJOB1 1
PAYJOB2 2
PAYJOB3 2
END OF LIST

391
JOBRES Command
Overview The JOBRES command is used to add new resource requirements for a job and
change existing resource requirements for a job. This is done after the Application
has been generated, but before the workload object is readied. If the workload object
is already waiting for resources (RESWAIT state), it is too late.
Syntax
The syntax of the JOBRES command is:
JOBRES JOB(name.qual) APPLICATION(name.gen)
RESOURCE(n1,res1,n2,res2,)
name Indicates the name of the job that requires resource
modifications.
name.gen Indicates the name and generation number of the Application
in which the job resides.
n1,res1 Used to specify the quantity and resource name that will be
set.
Usage notes JOBRES does not add or subtract from the original resource quantity specified, it
strictly sets the new quantity.
You can drop a resource requirement by specifying (0,resname).
Resources not specified in the JOBRES command remain unchanged.
Example The following example shows the full statement syntax:
JOBRES JOB(myjob.q1) APPLICATION(cyber.22) -
RESOURCE(1,db2tab1,3,t3480)
392
JOBTREE Command
Overview The JOBTREE command is used in conjunction with the MAPGEN command to
produce a job descendent tree from the job mapping data set.


Syntax The syntax of the JOBTREE command is:
JOBTREE DSN(dsname)
JOB(job_id)
[APPL(appl_id)]

DSN(dsname) Indicates a fully qualified data set name of the map data set
created by the MAPGEN command.
JOB(job_id) Indicates the name of the job for which the information is
produced.
APPL(appl_id) Indicates the name of the Application for which the
information is to be produced. If this parameter is omitted,
jobs from all Applications are examined for a match. If the
job is in more than one Application, ESP uses the first
instance it finds.

Usage notes Since the JOBTREE command uses the job mapping data set as input, you can only
report on jobs contained in that data set.

Related
information
For information on creating a job mapping data, set see the MAPGEN command.
For information on producing a job map report, see the JOBMAP command.
393
JOBTREE Command, Continued

Example 1 The following JOBTREE command produces a job descendent tree report:
JOBTREE DSN(CYBER.MAPGEN) JOB(PAYJOB1) APPL(PAYROLL)
In the above example, a job map for PAYJOB1 in the PAYROLL Application is
produced, the information is obtained from the CYBER.MAPGEN job mapping data
set.
The following provides a sample of the information produced by the above
JOBTREE command:
JOB DESCENDENT TREE
PAYJOB1 PAYROLL
PAYJOB2 PAYROLL
PAYJOB3 PAYROLL
In the above example, PAYJOB1 releases PAYJOB2 and PAYJOB3.

JOBTREE DSN(CYBER.MAPGEN) JOB(PAYJOB.RUN1) APPL(PAYROLL)
In the above example, a job map for PAYJOB.RUN1 in the PAYROLL Application
is produced, the information is obtained from the CYBER.MAPGEN job mapping
data set.

JOBTREE DSN(CYBER.MAPGEN) JOB(PAYJOB2)
In the above example, a job map for PAYJOB2 is produced, information is obtained
from the CYBER.MAPGEN job mapping data set.

JOBTREE DSN(CYBER.MAPGEN) JOB(PAYJOB3) APPL(PAYROLL)
JOBTREE DSN(CYBER.MAPGEN) JOB(PAYJOB3) APPL(BILLING)
In the above example, a job map for PAYJOB3 in the PAYROLL and BILLING
Applications is produced, the information is obtained from the CYBER.MAPGEN
job mapping data set.

394
JTPEXCL Command

Overview The JTPEXCL command is used to provide a means to exclude a named program
from affecting the job tracking completion status of the job. Normally this
command is coded, with the ADD option, as an ESP Initialization Parameter.


Authority OPER authority is required to issue the JTPEXCL command.

Syntax The syntax of the JTPEXCL command is:
JTPEXCL [pgmname]
(pgmname[,pgmname]...)]
[ADD|DELETE]

pgmname Indicates a valid program name.
ADD Indicates new information is to be added to the
specification for program exclusion. This is the default.
DELETE Delete excluded programs from a previous JTPEXCL
definition.

Usage notes Sometimes the last step in a job executes regardless (i.e. COND=EVEN) of the
execution of other steps in the job. This step normally performs some cleanup
activity. The JTPEXCL command allows you to exclude the name of the program
this last step executes from affecting the job tracking completion status of the job.
Use the JTPEXCL command with no parameters to display the programs excluded
from job tracking status.

Related
information
For information on excluding programs from affecting job completion status at the
Initialization Parameter level, see the JTPEXCL command in the ESP Workload

Example 1 The following JTPEXCL command displays excluded programs:
JTPEXCL
In the above example, all excluded programs are displayed.
395
JTPEXCL Command, Continued

Example 2 The following JTPEXCL command excludes a program from job tracking status:
JTPEXCL CLEANUP
In the above example, CLEANUP is excluded from affecting the job tracking
completion status of the job.

Example 3 The following JTPEXCL command deletes a previously defined exclusion:
JTPEXCL CLEANUP DELETE
In the above example, CLEANUP is deleted and no longer affects the job tracking
completion status of the job.
396
JUMPTO Statement

Overview The JUMPTO statement is used to cause a forward search within an ESP Procedure
to find the next label of the name given in the JUMPTO statement. Use the
JUMPTO statement to skip over whole sections of an ESP Procedure. You can use
a JUMPTO statement with or without an IF statement.

Type ESP Procedure Statement.

Syntax The syntax of the JUMPTO statement is:
JUMPTO labelname

labelname Indicates a valid label name consisting of up to 16

Usage notes The JUMPTO statement is often used with IF-THEN-ELSE statements.
JUMPTO allows you to skip whole processing sections of a Procedure under certain
conditions.
Labels used in conjunction with JUMPTO statements can be up to 16 characters.
The first character must be an alphabetic character and you must type a colon after
the last character.

Related
information
For information on ESPs control language (CLANG) and ESP Procedures, see the

Example 1 The following JUMPTO statement causes a forward search through an ESP
Procedure:
IF TODAY(LAST WORKDAY OF FISCALYR) THEN JUMPTO LSTWDYR
SELECT PAYJOB99
EXIT
LSTWDYR:
In the above example, if today is the last workday of the fiscal year ESP jumps to the
LSTWDYR label and selects PAYJOB1 and PAYJOB2; otherwise PAYJOB99 is
selected.
397
JUMPTO Statement, Continued

Example 2 The following JUMPTO statements cause forward searches based on what day this
ESP Procedure is invoked:
APPL FRED
JCLLIB 'CYBBS01.JCLLIB.CNTL'
IF TODAY('MONDAY') THEN JUMPTO MONDAY
IF TODAY('NOT MONDAY') THEN JUMPTO NOT_MONDAY
MONDAY:
INVOKE 'CYBER.PROCLIB.CNTL(SPECIAL)'
EXIT
NOT_MONDAY:
INVOKE 'CYBER.PROCLIB.CNTL(REGULAR)'
EXIT
In the above example, if today is:
Monday, ESP jumps to the MONDAY label, invokes the SPECIAL ESP
Procedure, and then exits.
Not Monday, ESP jumps to the NOT_MONDAY label, invokes the REGULAR
ESP Procedure, and then exits.
Example 3 The following JUMPTO statements causes a forward search based on whether or not
a started task is active:
IF ACTIVE(CICS) THEN JUMPTO STOP
ELSE JUMPTO GO
STOP:
VS F CICS,SHUTDOWN
REEXEC IN(5)
EXIT
GO:
VS F ESP,TRIGGER PROD.PAYROLL
In the above example, if the CICS started task is active, ESP jumps to the STOP
label and issues the shutdown command, schedules a re-execution of the Event in 5
minutes, and exits. If CICS is not active ESP jumps to the GO label and issues a
command to trigger the PROD.PAYROLL Event.
398
JUMPTO Statement, Continued
Example 4 The following JUMPTO statements cause forward searches based on the name of a
job:
JUMPTO %MNJOB
CICS1:
ESP TRIGGER PROD.CICS1BKUP
EXIT
CICS2:
ESP TRIGGER PROD.CICS2BKUP
EXIT
CICS3:
ESP TRIGGER PROD,CICS3BKUP
EXIT
In the above example, this common ESP Procedure is invoked as a result of a job
monitor Event. If CICS1, CICS2 or CICS3 abend, a generic job monitor Event is
automatically triggered, and invokes this ESP Procedure. ESP jumps to the
appropriate label (based on the jobname, represented by %MNJOB), triggers an
Event, and exits.
399
LABEL Command
Overview The LABEL command is used in conjunction with the GENDOC, REMOVE and
GO commands when converting a non-ESP job documentation library to a
documentation library usable by ESP. The LABEL command alters or replaces lines
in the output data set, or inserts lines at different locations in the output data set.
Syntax The syntax of the LABEL command is:
LABEL source_string target_string
{BEFORE}
{AFTER}
{REPLACE}
{OVERLAY}
{INLINE}
{ANY}
source_string Indicates a string to be scanned. It can contain the *
wildcard character. If the ANY keyword is not used, the
source string is expected to be the first non-blank character
data on the line.
target_string Indicates a new string. If the target string contains the
character @, the @ is replaced by the actual source string.
If the source string is specified with wildcard characters, the
wildcard characters are replaced with the actual characters
found.
BEFORE Indicates the target string is placed on a line of its own just
ahead of the line containing the source string.
AFTER Indicates the target string is placed on a line of its own just
after the line containing the source string.
REPLACE Indicates the line containing the source string is deleted and a
line containing just the target string is inserted instead.
OVERLAY Indicates the target string overlay the source string in the
record. The target string is moved to the line being copied,
starting at the same column as the source string. If the target
string is longer than the source string, data following the
source string may be overlaid.
INLINE Indicates the target string be used to replace the source string.
If the strings are of unequal length, subsequent data is shifted
left or right.
ANY Indicates the source string can be located anywhere on an
input line. The default is to look for the source string as the
first non-blank data on a line.
400
LABEL Command, Continued
Usage notes The GENDOC command identifies the input data set, members to be copied, and the
output data set. It also lets you identify changes you want to make when the old
documentation converts.
Use the REMOVE, LABEL and GO commands in conjunction with the GENDOC
command to customize the conversion of non-ESP job documentation to ESP job
documentation.
Related
information
For information on converting existing job documentation, see the GENDOC
command.
For information on identifying lines that are not to be copied to the output data set
during the conversion, see the REMOVE command
Guide.
For information on displaying job documentation information, see the JOBINFO
command, or the ESP Workload Manager Users Guide.
For information on identifying a job documentation library in an Application, see
the DOCLIB statement.
REMOVE **
GO
Replace any lines starting with SYSOUT REVIEW with the character string
SYSOUT_REVIEW.
Overlays the semicolon on any line beginning with STEP. The semicolon is
positioned after the 3rd character following the string STEP.
401
LATESUB Statement
Overview The LATESUB statement indicates a late submission time for a job. This is the
latest acceptable submission time before the job is flagged as overdue.
Syntax The syntax of the LATESUB statement is:
LATESUB criteria
Usage notes ESP can provide notification when a jobs late submission time is exceeded. For
example, you may want to send a message, or trigger an Event.
From the CSF, you can filter on overdue jobs.
The LATESUB statement can be used for any type of workload object and must be
placed within the scope of a job statement (all statements up to an ENDJOB
statement or the next JOB statement).
The LATESUB time for a link or task represents the time when all of its
dependencies should be met, as there is no actual job submission.
The LATESUB statements date and time criteria are relative to the scheduled time
of the Event.
LATESUB does not force the submission of a job when its late submission time is
exceeded. To force submission of a job regardless of dependencies use the
ABANDON DEPENDENCIES statement. To bypass a job after a specified time
and submit successor jobs, use the ABANDON SUBMISSION statement.
To identify that a job has not started or finished by a specific time, use the
DUEOUT statement.
The LATESUB statement propagates dueout times upstream, i.e. to all predecessors
of the job where a LATESUB statement is specified. These dueout times are set
relative to the average elapsed times according to the information obtained from
ESPs history file.
Related
information
For information on providing notification on job status, see the NOTIFY statement.
For information on triggering an Event based on a job exceeding its late submission
time, see the ESP Workload Manager Advanced Users Guide.
402
LATESUB Statement, Continued
Example 1 The following LATESUB statement specifies a late submission time of 22:00:
JOB A
RUN DAILY
LATESUB 22:00
ENDJOB
In the above example, job A is flagged as overdue if ESP has not submitted the job
by 22:00.
Example 2 The following LATESUB statement specifies a late submission time of 6pm every
day except Monday:
JOB A
RUN DAILY
IF TODAY(MONDAY) THEN LATESUB 4PM
ELSE LATESUB 6PM
ENDJOB
In the above example, job A is flagged as overdue if ESP has not submitted it by 6
pm every day except on Monday, when the late submission time is 4 pm.
Example 3 The following LATESUB statement specifies a late submission time of 4 pm for a
link that issues an operator command:
JOB SET.INITS LINK PROCESS
RUN DAILY
LATESUB 4PM
VS $SI1-5
ENDJOB
In the above example, job SET.INITS is flagged as overdue if its dependencies are
not satisfied by 4 pm.
403
LATESUB Statement, Continued
Example 4 The following Event has a scheduled execution time of 9 pm:
EVENT ID(CYBER.TEST)
SCHEDULE 9PM DAILY
INVOKE 'CYBBS01.PROCLIB.CNTL(TEST)'
ENDDEF
The following job has a late submission time of 10 pm:
JOB A
RUN DAILY
LATESUB 10PM
ENDJOB
The following CSF display shows the status of a job flagged as overdue:
ESP Consolidated Status: View TEST Row 1 of 2, Col 1
Jobname APPL GEN STATUS
___ A TEST 8 SUBMITTED OVERDUE
In the above example, an Event (CYBER.TEST) missed its scheduled execution
time due to system problems. When the Event was triggered at 11 pm, job A was
submitted and flagged as overdue in the CSF.
Other examples Here are more examples using the LATESUB statement.
Flags the job as overdue if it is not submitted 10 minutes after the scheduled
execution time of the Event:
LATESUB NOW PLUS 10 MINUTES
Flags the job as overdue if it is not submitted by 7am tomorrow:
LATESUB 7AM TOMORROW
Flags the job as overdue if it is not submitted 2 hours after the Event is triggered:
LATESUB REALNOW PLUS 2 HOURS
404
LAX Command
Overview The LAX command is used to display external jobs in active Applications.
Authority OPER authority is required to issue the LAX command.
Syntax The syntax of the LAX command is:
LAX
Usage notes Use the EXTERNAL keyword as part of a JOB statement to tell ESP the job is part
of another Application. This allows you to establish relationships between jobs in
different Applications.
Related
information
For information on posting external or manual jobs complete, see the APPL
statement or the ESP Workload Manager Advanced Users Guide.
405
LAX Command, Continued
Example 1 The following is an example of an Application containing an external job that runs
as part of another Application:
APPL BILLING
JOB PAYJOB99 EXTERNAL
RUN WORKDAYS
REL BILJOB1
JOB BILJOB1
RUN WORKDAYS
ENDJOB
The following is an example of the Application where the External job (above)
actually runs:
APPL PAYROLL
JOB PAYJOB99
RUN WORKDAYS
ENDJOB
The following LAX command displays External jobs in active Applications:
LAX
BILLING.28: PAYJOB99
--- 1 APPLS DISPLAYED
In the above example, the LAX command displays the name of the External job and
the Application that job belongs to.
406
LCMDPRFX Command
Overview The LCMDPRFX command is used to display whether command prefixing is in
effect or not. If command prefixing is in effect, LCMDPRFX displays the character
to be substituted for the F stcname,, (where stcname is the started task name for
ESP) string when issuing modify commands to ESP from a system console.
Authority OPER authority is required to issue the LCMDPRFX command.
Syntax The syntax of the LCMDPRFX command is:
LCMDPRFX
Related
information
For information on substituting a character for the F ESP string, see the
CMDPRFX command.
Example 1 The following LCMDPRFX displays the character that is substituted for the F
ESP, string:
OPER LCMDPRFX
'#' 'F ESP,'
In the above example, the number sign (#) was previously set as the character to be
substituted for the F ESP string when issuing modify commands to ESP from a
system console.
407
LDSN Command
Overview The LDSN command is used to produce a display of the current system data sets
allocated to ESP.
Syntax The syntax of the LDSN command is:
LDSN
Related
information
For information on defining ESP data sets, see the ESP Workload Manager
Installation Guide.
Example 1 The following is an example of the display produced by the LDSN command:
LDSN
CHECKPOINT: CYBER.ESP510.CKPT, ALT NONE
USERDEF: CYBER.ESP510.USERDEF, BKUP NONE
INDEX: CYBER.ESP510.INDEX, BKUP NONE
JOBINDEX: CYBER.ESP510.JOBINDEX, BKUP
CYBER.ESP510.BKUP.JOBINDEX
QUEUE: CYBER.ESP510.QUEUE, ALT NONE
TRAKFILE: CYBER.ESP510.TRAKFILE
EVENTSET: CYBER.ESP510.EVENT1
HISTFILE: CYBER.ESP510.HISTFILE
APPLFILE: CYBER.ESP510.APPLFILE
JTDT: CYBER.ESP510.PARMLIB(JOBDEF1)
UPDT: CYBER.ESP510.PARMLIB(PROFILE)
In the above example, current system data sets allocated to ESP are displayed.
408
LDTE Command
Overview The LDTE command is used to list data sets being checked for data set activity as
specified by the DSTRIG command in an Event definition or by the DSNAME
statement in an Application.
Syntax The syntax of the LDTE command is:
LDTE
Related
information
For information on data set triggering at the job level, see the ESP Workload
For information on displaying data sets being checked for closures, creations or
renaming, see the LDXE command.
Example 1 The following is an example of the display produced by the LDTE command:
LDTE
THE FOLLOWING DATASET(S) ARE BEING CHECKED FOR DATASET
TRIGGERS
CYBER.PAYROLL.DATA CREATE-CLOSE
USER.INPUT.CYCLE ANYCLOSE
2 DATASET TRIGGERS FOUND
In the above example, data sets checked for data set activity are displayed.
409
LDTREL Command
Overview The LDTREL command is used to display the entries from the Data set Trigger
Exclude list.
Authority OPER authority is required to issue the LDTREL command.
Syntax The syntax of the LDTREL command is:
LDTREL
Usage notes The Data set Trigger Exclude list consists of a list of programs that are not eligible
for data set triggering. The DSTREXCL Initialization Parameter specifies these.
Use the DSTREXCL command to flag an entry in the Data set Trigger Exclude list
as invalid.
Related
information
For information on flagging an entry in the Data set Trigger Exclude list as invalid,
see the DSTREXCL command.
For information on adding an entry to the Data set Trigger Exclude list at the
Initialization Parameter level, see the ESP Workload Manager Initialization
Reference Guide.
Example 1 The following is an example of the output produced by the LDTREL command:
LDTREL
DSTRIG exclude PGM=USRPGM
In the above example, USRPGM is not eligible for data set triggering.
410
LDXE Command
Overview The LDXE command is used to list data set names and the corresponding Events or
Applications waiting for data set activity. Data set trigger requirements are
identified by the DSTRIG command in an Event definition or by the DSNAME
statement in an Application.
Syntax The syntax of the LDXE command is:
LDXE
Related
information
For information on data set triggering at the job level, see the ESP Workload
For information on displaying data set triggered Events, see the LDTE command.
Example 1 The following is an example of the display produced by the LDXE command:
LDXE
EVENT/APPL (WOB)--------------DATASET
PAYROLL.1 (WAIT4.DS) CYBER.PAYROLL.DATA,ANYCLOSE
CYBER.CYCLES USER.INPUT.CYCLE
In the above example, data sets that are checked for closures, creation or renames
are displayed.
411
LIBSUB Command
Overview The LIBSUB command is used to submit JCL from a Librarian data set to the
internal reader.
Syntax The syntax of the LIBSUB command is:
LIBSUB dsname
[(member)]
dsname Indicates a valid LIBRARIAN data set name. You do not
have to specify LIB- as a data set identifier, because using
the LIBSUB command implies the use of a LIBRARIAN data
set.
member Indicates a member name, which can consist of up to 8
characters if specified.
Usage notes Several LIBSUB commands may be specified in a single Event. The input data are
effectively concatenated together, so that data from several data sets can be joined
together to form one or more jobs.
In the same Event, you can also use the SUBMIT command, as well as submitting
from ROSCOE and PANVALET data sets.
To submit Librarian jobs as part of an Application, prefix the Librarian data set with
LIB- on the JCLLIB statement, as follows:
APPL PAYROLL
JCLLIB LIB-LIB01A.DATA
JOB PAYJOB1
RUN DAILY
ENDJOB
Related
information
For information on submitting JCL from an Event, see the ESP Workload Manager
Users Guide.
For information on identifying a JCL library, see the JCLLIB statement.
412
LIBSUB Command, Continued
Example 1 The following is an example of an Event definition that submits JCL from a
LIBRARIAN data set:
EVENT ID(CYBER.ONELIBJOB)
SCHEDULE 9AM FIRST MONDAY OF MONTH
LIBSUB LIB01A.DATA(PRODCNTL)
ENDDEF
In the above example, PRODCNTL is submitted at 9am on the first Monday of the
month from the LIBRARIAN data set LIB01A.DATA.
413
LIST Command
Overview The LIST command is used to display Event information.
Syntax The syntax of the LIST command by LEVEL is:
{LIST|L} [LEVEL{(groupprefix)|(levelname)}]
[ALL]
[SYSTEM]
[CLASS(classname)]
[TIMESEQ]
[PRINT(dsname)]
[MOD]
The syntax of the LIST command by EVENT is:
{LIST|L} EVENT(eventid)
[ALL]
[PRINT(dsname)]
[MOD]
groupprefix Indicates the current group prefix.
levelname Enter up to 24 characters in the level name. All Events whose
names begin with the specified string are displayed. The
level name can contain asterisks and a hyphen anywhere but
in the prefix.
ALL Indicates all available information on the Event(s) is
displayed. If this parameter is omitted, the display is limited
to the next execution time. The information displayed with
the ALL option is enough to redefine the Event in its entirety.
SYSTEM Indicates the ID of the ESP system that is to execute the
Event is included in the display.
classname Indicates the display is restricted to Events with the specified
class name.
TIMESEQ Indicates the Event names are to be displayed in execution
time sequence order rather than alphanumeric collating
sequence.
eventid Indicates the name of a specific Event to be displayed.
dsname Indicates the name of a data set to receive the output. The
record format of the data set is preserved. ESP can write
fixed, variable or undefined records, blocked or unblocked
MOD Indicates the data set receiving output is appended to.
414
LIST Command, Continued
Usage notes When issuing the LIST command from Page mode, that is under the ISPF interface,
you must use the abbreviated form of the LIST command (L).
An asterisk indicates that any character in the asterisk location acts as a match.
A hyphen indicates that any character in that or subsequent character positions is
considered a match.
If the level name contains a period, the part to the left of the period indicates the
prefix (group or userid), while the part to the right indicates the descriptive name.
If a prefix is specified, it cannot contain asterisks or a hyphen. If the level name
does not contain a period, it is assumed to be a prefix if:
It contains eight characters or less, and
It does not contain either asterisks or a hyphen.
Otherwise it is assumed to be a descriptive name.
The PRINT parameter of the LIST command is useful when changes are required for
multiple Events. The following summarizes how to accomplish this:
Issue the LIST command with the PRINT parameter for the desired group of
Events
Edit the data set as required
Issue the LOAD command to re-load the edited Events
Related
information
For information on loading ESP commands from a data set, see the LOAD
command.
Example 1 The following LIST command displays Event name and execution times:
L LEVEL(PROD)
In the above example, the names and next execution times of all Events defined to
the PROD group prefix are displayed.
Example 2 The following LIST command writes the results to a data set:
L LEVEL(PROD) ALL PRINT(ESP.EVENTS)
In the above example, the complete definitions of all Events defined to the PROD
group prefix are written to the ESP.EVENTS data set.
415
LIST Command, Continued
Example 3 The following LIST command displays Event name and execution times:
LIST LEVEL(CYBER.BKUP-)
In the above the names of all Events beginning with BKUP defined to the CYBER
group prefix are displayed.
Note: The above LIST command is not abbreviated as it is issued from a batch job.
Example 4 The following command displays specific Events with my current group prefix:
L LEVEL(A-)
In the above example, all Events that start with my current group prefix, followed by
A and any number of characters are displayed.
Example 5 The following LIST command displays Events in execution time sequence:
L LEVEL(PROD.**PR-) TIMESEQ SYS
In the above example, the execution time and system ID of all Events defined to the
PROD group prefix whose names have a PR in character positions three and four are
displayed in execution time sequence.
Example 6 The following LIST command displays information about a specific Event:
L EVENT(CYBER.PAYROLL) ALL
In the above example, all available information for CYBER.PAYROLL is displayed.
416
LISTAPPL Command
Overview The LISTAPPL command is used to display Application information. The short
form of this command name is LAP.
Syntax The syntax of the LISTAPPL command is:
{LISTAPPL|LAP} applname[.gen]
[COMPLETE|INCOMPLETE]
[ALL]
[PREDECESSORS]
[SUCCESSORS]
[CRITPATH|NOTCRITPATH]
[JOBS]
[JOB(jobname[,jobname]...)]
[STATUS]
[SUBAPPL(subapplname)]
[OLDEST]
[DUMP]
applname The applname parameter can contain a generic specification
with the * and - acting as single and multi-character
wildcards. An absolute or relative generation number can
also be specified with a specific applname as follows:
applname.0 - displays the most recent generation of
Application.
applname.-n - displays the nth previous
generation of the Application.
applname.n - displays the absolute generation n
of the Application.
COMPLETE Omission of the COMPLETE keyword results in a display of
Applications that still have active or incomplete jobs, unless
an absolute or relative generation number is specified. The
COMPLETE keyword requests that completed Applications
are also included in the display.
INCOMPLETE Displays all incomplete Applications. This is the default if
not specified.
ALL Displays information about each job. This includes successor
and predecessor information for each job, as well as resource
information.
JOBS Displays the names of each job in an Application. The
display is divided into two sections: jobs that have completed
and jobs that have yet to complete.
417
LISTAPPL Command, Continued
Syntax (continued)
PREDECESSORS Displays the names of any predecessors for each complete
job. The PREDECESSORS parameter is used in
conjunction with the ALL parameter.
SUCCESSORS Displays the names of any successors for each complete job.
The SUCCESSORS parameter is used in conjunction with
the ALL parameter.
CRITPATH Displays all jobs on the critical path if critical path analysis
is turned on.
NOTCRITPATH Displays all jobs not on the critical path if critical path
analysis is turned on.
JOB(jobname) Displays in a structured view each job or qualified job you
have specified.
STATUS Displays the status of each Application, without detailing the
jobnames.
SUBAPPL Display is limited to the subApplication specified.
OLDEST Requests a display of the oldest incomplete generation of an
Application.
DUMP Displays in hexadecimal format Application record
information for problem diagnosis.
Usage notes The LISTAPPL command displays information from the APPLFILE.
The LISTAPPL command displays anticipated end times for all jobs in an
Application.
When critical path analysis is turned on the LISTAPPL command:
Displays all jobs on the critical path with a label of CRITICAL PATH
Displays the job in the Application that is coded with the CRITICAL keyword
with a label of CRITICAL
Displays all jobs that are not on the critical path.
The LISTAPPL command cannot be issued from a system console.
Use the LAP command with the ALL keyword to give a structured view of an active
Application or with other keywords to give a summary of active or completed
Applications. You can limit the display to specific generations of an Application and
to specific jobs within an Application.
418
Related
information
For information on displaying active Applications from the CSF, see the ESP
For information on manipulation jobs in active Applications, see the APPLJOB or
AJ command.
Guide.
Example 1 The following LAP command displays an active generation of an Application:
LAP PAYROLL.0 ALL
In the above example, a structured view of the PAYROLL Application is displayed.
Example 2 The following LAP command displays the previous generation of an Application:
LAP PAYROLL.-1 ALL
In the above example, the status of the -1 generation of the PAYROLL Application
is displayed.
Example 3 The following LAP command displays all generations of an Application that are
stored on the APPLFILE:
LAP PAYROLL COMPLETE
In the above example, all complete and incomplete generations of the PAYROLL
Application are displayed.
Example 4 The following LAP command displays a specific job within an Application:
LAP PAYROLL.0 JOB(PAYJOB1)
In the above example, a structured view of PAYJOB1 within the PAYROLL
Application is displayed.
Example 5 The following LAP command displays a subApplication:
LAP FINANCE.0 SUBAPPL(PAYROLL) ALL
In the above example, a structured view of the PAYROLL subApplication within the
FINANCE Application is displayed.
419
Example 6 The following LAP command displays specific jobs within an active generation of
an Application:
LAP PAYROLL JOB(PAYJOB1,PAYJOB2,PAYJOB3) OLDEST
In the above example, a structured view of PAYJOB1, PAYJOB2 and PAYJOB3
within the oldest incomplete generation of the PAYROLL Application are displayed.
Example 7 The following LAP command displays predecessors and successors for each job in
an Application:
LAP PAYROLL.-2 ALL PRED SUCC
In the above example, the predecessors and successors of each job in the -2
generation of the PAYROLL Application, and whether those predecessors or
successors are complete, are displayed.
Example 8 The following LAP command display the names of each job in an Application:
LAP PAYROLL.0 JOBS
In the above example, a summary of complete and incomplete jobs within the
PAYROLL Application is displayed.
Example 9
The following is an example of the display produced by the LAP command (LAP
PAYROLL.105 ALL) with critical path analysis turned off:
APPL PAYROLL GEN 105
CREATED AT 13.04 ON WEDNESDAY JANUARY 28TH, 1998
BY EVENT CYBER.PAYROLL
PAYJOB1, HC=0
SUBMISSION AT 21.00 ON WEDNESDAY JANUARY 28TH, 1998
ANTICIPATED END TIME: 21.00 ON WEDNESDAY JANUARY 28TH, 1998
PREDECESSORS: (NONE)
SUCCESSORS: PAYJOB2, PAYJOB3
PAYJOB2, HC=1
PREDECESSORS: PAYJOB1
SUCCESSORS: PAYJOB4
PAYJOB3, HC=1
SUCCESSORS: PAYJOB4
PAYJOB4, HC=2
PREDECESSORS: PAYJOB2, PAYJOB3
SUCCESSORS: (NONE)
420
Example 10 The following is an example of the display produced by the LAP command with
critical path analysis turned on:
APPL PAYROLL GEN 105
CREATED AT 13.04 ON WEDNESDAY JANUARY 28TH, 1998
BY EVENT CYBER.PAYROLL
PAYJOB1, HC=0
SUBMISSION AT 21.00 ON WEDNESDAY JANUARY 28TH, 1998
- CRITICAL PATH
PREDECESSORS: (NONE)
SUCCESSORS: PAYJOB2, PAYJOB3
PAYJOB2, HC=1
SUCCESSORS: PAYJOB4
PAYJOB3, HC=1
- CRITICAL PATH
SUCCESSORS: PAYJOB4
PAYJOB4, HC=2
- CRITICAL
PREDECESSORS: PAYJOB2, PAYJOB3
SUCCESSORS: (NONE)
In the above example, a structured view of the PAYROLL Application is displayed.
Jobs on the critical path are displayed with the CRITICAL PATH label, and the
critically identified job in the Application is displayed with the CRITICAL label.
421
LISTAPTF Command
Overview The LISTAPTF command is used to display information on the current status of the
Application file.
Authority OPER authority is required to issue the LISTAPTF command.
Syntax The syntax of the LISTAPTF command is:
LISTAPTF
Usage notes The information displayed includes data set name, date and time formatted, and
current allocation status.
Related
information
Installation Guide.
Example 1 The following is an example of the display produced by the LISTAPTF command:
OPER LISTAPTF
DATASET CYB2.ESP510.APPLFILE
FORMATTED AT 17.33.55 ON MONDAY NOVEMBER 17TH, 1997
3600 SLOTS TOTAL, 3464 AVAILABLE, NEXT IS 928
In the above example, information on the current status of the Application file is
displayed.
422
LISTAT Command
Overview The LISTAT command is used to display the contents of an authorization table.
Syntax The syntax of the LISTAT command is:
LISTAT tabname
[DECOMPILE]
tabname Indicates the name of the authorization table you want
displayed. The name consists of up to eight characters. You
can specify asterisks or a hyphen for masking.
DECOMPILE Indicates you want the authorization table to be displayed in
the same way in which it was defined. The DECOMPILE
option generates a DEFAT (define authorization table)
command you could feed directly back into ESP.
Usage notes An authorization table provides a way of controlling access to job tracking data. For
instance, you may not want to allow one customer to view job-tracking information
for another customers jobs. The use of an authorization table means that access to
data for tracked jobs depends on the jobname and on an authorization string.
The DEFAT command is used to define or alter an authorization table, limiting
access to tracked job data. An authorization table provides a way of controlling
access to job tracking data.
The LISTAT command is not used with the SAF interface.
Related
information
For information on defining or altering an authorization table, see the DEFAT
command or the ESP Workload Manager Administrators Guide.
Example 1 The following is an example of the display produced by a LISTAT command:
LISTAT AUTHTAB1
JOB AUTH TABLE: AUTHTAB1
DEFINED AT 11.30 ON FRI 2JAN99 BY CYBBP01
INCLUDE: ABC-,ACO-, XYZ-,ACO-
EXCLUDE: -,AC02
In the above example, the contents of an authorization table are displayed.
423
LISTAT Command, Continued
Example 2 The following LISTAT command displays the authorization table the way it was
defined:
LISTAT AUTHTAB1 DECOMPILE
In the above example, AUTHTAB1 is displayed the same way in which it was
defined.
424
LISTCAL Command
Overview The LISTCAL command is used to display information about a calendar.
Syntax The syntax of the LISTCAL command is:
{LISTCAL|LCAL} calname
calname Indicates a name or generic level of the calendar or calendars
displayed. It can be up to eight characters long and can also
contain asterisks and a hyphen.
Usage notes After you have defined a calendar, and those users with update access have defined
their scheduling terms in the calendar, you or any other user may want to review
information about the calendar.
Like the users who defined their scheduling terms in the calendar, you may need to
review the calendar information for troubleshooting and maintenance. Other users
who automatically have read access to the calendar may find it useful to review the
calendar information before using it in an Event.
If you do not specify a calendar name, the most recently retrieved calendars are
displayed. A set of calendars is retrieved as a result of a LISTHOL, LISTSPEC,
EVENT, CALENDAR or prior LISTCAL command. If no calendars were
previously retrieved, you are prompted to enter a calendar name.
Related
information
commands.
For information on defining and deleting special days, see the DEFSPEC and
DELSPEC commands.
For information on altering the attributes of a calendar, see the ALTCAL command.
For information on defining calendars, see the ESP Workload Manager
Administrators Guide or the DEFCAL command.
For information on using special calendars in an Event, the ESP Workload Manager
Users Guide.
For information on using calendars, see the ESP Workload Manager Users Guide.
425
LISTCAL Command, Continued
Example 1 The following is an example of the display produced by the LISTCAL command:
LISTCAL SYSTEM
CALENDAR NAME: SYSTEM
DEPARTMENT: NONE
DEFINED: AT 15.42 ON THU 23RD SEP 1993 BY CYBSM04
OWNER: USR01
WORKDAYS: MON TUE WED THU FRI
WEEK STARTS: MON
SIZE: 280 BYTES
HOLIDAYS: CHRISTMAS, NEW_YEARS, CHRISTMAS, NEW_YEARS
SPECIAL DAYS: INVENTORY_DAY(1)
In the above example, the contents of the SYSTEM calendar are displayed.
Example 2 The following LISTCAL command displays specific calendars:
LISTCAL PAY-
In the above example, the contents of all calendars with PAY in the first 3 positions
are displayed.
426
LISTCKPT Command
Overview The LISTCKPT command is used to display statistics on the Checkpoint data set.
Authority OPER authority is required to issue the LISTCKPT command.
Syntax The syntax of the LISTCKPT command is:
LISTCKPT
Usage notes The information displayed by this command includes the Checkpoint data set name,
the maximum size available, and the current usage.
Related
information
Installation Guide.
Example 1 The following is an example of the display produced by the LISTCKPT command:
OPER LISTCKPT
PRIMARY CHECKPOINT CYB2.ESP510.CKPT
MAX CHECKPOINT SIZE 737280
HIGHEST ADDRESS USED 3232
32 BYTES IMBEDDED FREE SPACE
In the above example, statistics on the Checkpoint data set are displayed.
427
LISTEVS Command
Overview The LISTEVS command is used to display the status of any or all of the Event data
set.
Authority OPER authority is required to issue the LISTEVS command.
Syntax The syntax of the LISTEVES command is:
LISTEVS [eventdb]
eventdb Indicates the logical name of an Event data set. If this
parameter is omitted, all the Event data sets are displayed.
Usage notes If an Event data set is closed when the LISTEVS command is issued, the status is
displayed as follows:
****DATASET IS IN SUSPENDED STATE
Related
information
Installation Guide.
Example 1 The following is an example of the display produced by the LISTEVS command:
LISTEVS
EVENTSET EVENT1, DSN=CYB2.ESP510.EVENT1 SHR NOJRNL
NEXT SCAN AT 06.00 ON WEDNESDAY JANUARY 28TH, 1998
BACKUP DATASET CYB2.ESP510.BACKUP.EVENT1
In the above example, the status of the EVENT1 data set is displayed.
Example 2 The following LISTEVS command displays all Event data sets:
LISTEVS
In the above example, all Event data sets are displayed
428
LISTEVS Command, Continued
Example 3 The following LISTEVS command displays a specific Event data set:
LISTEVS EVENT1
In the above example, the status of the EVENT1 data set is displayed.
429
LISTGRP Command
Overview The LISTGRP command is used to display information on your current group or any
other group to which you are connected. The LISTGRP command is available only
in non-SAF environments.
Syntax The syntax of the LISTGRP command is:
{LISTGRP|LG} [groupname]
groupname Indicates the logical name of the group definition to be
displayed. It may contain asterisks and the last character can
be a hyphen if you want to use masking. If the group name is
omitted, your current group is displayed.
Usage notes The information displayed by this command includes the group attributes and the
names of the users who are connected to the group.
Related
information
For information on defining and deleting groups, see the DEFGROUP and
DELGROUP commands.
For information on altering a group definition, see the ALTGROUP command.
Guide.
For information on the System Authorization Facility (SAF), see the ESP Workload
Example 1 The following LISTGRP command displays your current group.
LISTGRP
In the above example, a group name is omitted and your current group is displayed.
430
LISTGRP Command, Continued
Example 2 The following LISTGRP command displays a specific group:
LISTGRP GROUP1
In the above example, GROUP1 is displayed.
Example 3 The following LISTGRP command displays multiple groups:
LISTGRP PAY-
In the above example, all groups beginning with PAY are displayed.
Example 4 The following LISTGRP command displays all groups:
LISTGRP -
In the above example, all groups are displayed.
431
LISTHIST Command
Overview The LISTHIST command is used to display the status of any or all of the history
files.
Authority OPER authority is required to issue the LISTHIST command.
Syntax The syntax of the LISTHIST command is:
LISTHIST [histfid]
histfid Indicates the logical name of a HISTFILE using up to eight
characters. It may contain asterisks and a hyphen. If this
Parameter is omitted, all the history files are displayed.
Related
information
Installation Guide.
Example 1 The following is an example of the display produced by the LISTHIST command:
OPER LISTHIST
HISTFILE HIST1, DSN=CYB2.ESP510.HISTFILE SHR NOJRNL
NO BACKUP TIME SET
NO BACKUP DATASET
In the above example, the status of the HIST1 history file is displayed.
Example 2 The following LISTHIST command displays a specific history file:
LISTHIST HIST1
In the above example, the HIST1 history file is displayed.
Example 3 The following LISTHIST command displays specific history files:
LISTHIST HIST-
In the above example, all history files with HIST in the first four positions are
displayed.
432
LISTHOL Command
Overview The LISTHOL command is used to list previously defined holidays.
Syntax The syntax of the LISTHOL command is:
{LISTHOL|LH} name
[GROUP(groupname)]
[CALENDAR(calname)]
[FROM(fromdate)]
[TO(todate)]
name Indicates a full or generic name. It may contain asterisks and
a hyphen. An asterisk indicates that any character in that
position is considered a match. A hyphen indicates that all
subsequent characters are considered a match. If this
parameter is omitted, all holidays are displayed. Code - if
you are using any other parameters and want all the holidays
to be displayed.
groupname Indicates holidays from the default calendars of the specified
group are displayed.
calname Indicates the name of the calendar to be searched. This
parameter is mutually exclusive with the GROUP parameter.
fromdate Indicates a start date for the holidays to be displayed. Only
holidays that fall on or after this date are displayed. If no
year is specified, ESP uses the current year.
todate Indicates an ending date for the holidays to be displayed.
Only holidays that fall on or before this date is displayed. If
no year is specified, ESP uses the current year.
Usage notes If no group name or calendar name is specified, the most recently retrieved set of
calendars is displayed. If no calendars were retrieved in the current command
session, the default calendars for the current group are displayed.
A start and/or end date can be specified to restrict the displayed holidays to a
specific time period. Holidays are displayed in time sequence order within each
calendar.
The display can be restricted to holidays containing a specified character string. The
first parameter specifies a holiday name or generic holiday name. If you want all
holidays to be displayed but need to use another parameter, specify a hyphen (-) as
the first parameter.
To specify a date, use any format ESP recognizes. If the date contains any blanks or
commas, enclose the string in quotes.
433
LISTHOL Command, Continued
Related
information
commands.
Example 1 The following LISTHOL command displays holidays currently defined:
LISTHOL
In the above example, a holiday name is omitted and the defined holidays in your
default calendar are displayed.
Example 2 The following LISTHOL command displays all holidays up to a specific date:
LISTHOL - CALENDAR(CAL1) TO(SEPT30TH)
In the above example, all holidays in the CAL1 and the SYSTEM calendar up to the
end of September are displayed.
Example 3 The following LISTHOL command displays specific holidays for a given year:
LISTHOL N*W- GROUP(PAYROLL) FROM(1JAN2001) TO(31JAN2001)
In the above example, all the holidays in the year 2001 that begin with N and have
W in position three of the name are displayed. The calendars to be searched are
the default calendars for the PAYROLL group.
Example 4 The following is an example of the display produced by the LISTHOL command:
CALENDAR SYSTEM
NEW_YEARS 00.00 ON THU 1ST JAN 98 TO 00.00 ON FRI 2ND
JAN 98
VICTORIA_DAY 00.00 ON MON 18TH MAY 98 TO 00.00 ON TUE 19TH
MAY 98
MEMORIAL_DAY 00.00 ON MON 25TH MAY 98 TO 00.00 ON TUE 26TH
MAY 98
XMAS 00.00 ON FRI 25TH DEC 98 TO 00.00 ON SAT 26TH
DEC 98
---- 5 HOLIDAYS DISPLAYED ----
In the above example, holidays defined on the SYSTEM calendar are displayed.
434
LISTJTML Command
Overview The LISTJTML command is used to list internal tracking model data.
Authority OPER authority is required to issue the LISTJTML command.
Syntax The syntax of the LISTJTML command is:
LISTJTML
Usage notes The DEFTM command defines a tracking model and allows you to centralize the
definition of tracking characteristics, which can be assigned to one job, or a group of
jobs. Jobs are normally associated with a tracking model in a job tracking definition
table.
Related
information
command.
For information on defining and deleting a tracking model, see the DEFTM and
DELTM commands.
Example 1 The following is an example of the display produced by the LISTJTML command:
OPER LISTJTML
1 TRACKING MODEL BUFFER
5398 MODELS LOCATED IN INCORE BUFFERS
88 MODELS LOCATED VIA READ TO JOBINDEX
In the above example, tracking model data is displayed.
435
LISTPN Command
Overview The LISTPN command is used to display the definition of one or more P-Node
entries. A P-Node represents a stage a job goes through during processing.
Syntax The syntax of the LISTPN command is:
{LISTPN|LPN} name
name Indicates the name of the P-Node entry to be displayed. It
may contain asterisks and a hyphen to display several
matching entries.
Usage notes The INPUT, EXEC and OUTPUT P-Nodes are normally defined when installing
ESP. Any data defined using the DEFPN command is displayed.
Related
information
DELPN commands.
Example 1 The following LISTPN command displays an individual P-Node:
LISTPN EXEC
In the above example, the EXEC P-Node is displayed.
Example 2 The following is an example of the display produced by the LISTPN command:
LISTPN -
P-NODE - DISTRIB DEFINED AT 10.23 ON WED 28JAN98 BY
CYBBS01
HISTFILE - NONE, OWNER(CYBBS01), SEQUENCE(140)
P-NODE - EXEC DEFINED AT 15.47 ON MON 24NOV97 BY
CYBBP01
HISTFILE - NONE, OWNER(CYBBP01), SEQUENCE(120)
P-NODE - INPUT DEFINED AT 15.47 ON MON 24NOV97 BY
CYBBP01
P-NODE - OUTPUT DEFINED AT 15.47 ON MON 24NOV97 BY
CYBBP01
436
LISTQ Command
Overview The LISTQ command is used to display information about the current status of the
QUEUE data set.
Authority OPER authority is required to issue the LISTQ command.
Syntax The syntax of the LISTQ command is:
LISTQ
Usage notes The information displayed by this command includes the time the QUEUE data set
was formatted, the amount of space allocated and the amount of space used, and the
MINHOLD, MINDORM, and MAXDORM values.
Related
information
For information on defining ESP data sets see, the ESP Workload Manager
Installation Guide.
Example 1 The following is an example of the display produced by the LISTQ command.
OPER LISTQ
QUEUE DATASET CYB2.ESP510.QUEUE
MAXIMUM SIZE 737280 BYTES
HIGHEST ADDRESS USED 72160, 6112 BYTES IMBEDDED FREE SPACE
MINHOLD 100, MINDORM 100, MAXDORM 100
In the above example, the current status of the QUEUE data set is displayed.
437
LISTSADL Command
Overview The LISTSADL command is used to display the current SADLINKs defined.
Authority OPER authority is required to issue the LISTSADL command.
Syntax The syntax of the LISTSADL command is:
LISTSADL
Usage notes The SADLINK command identifies an external SAD file with an internal identifier.
Each time ESP initializes, or in response to a SADLOAD command, the contents of
the SAD file are read and necessary information retained in a main-storage resident
look-up table. To request that the look-up table be used to resolve external linkages,
specify the correct SADLINK identifier on the RESOLVE statement in an ESP
Procedure.
Related
information
For information on scheduled activity reporting, see the ESP Workload Manager
Users Guide.
For information on generating a data set that is used in the creation of scheduled
activity reports, see the SADGEN command.
For information on identifying an external scheduled activity data set, see the
SADLINK command.
For information on refreshing an in-core table containing scheduled activity data set,
see the SADLOAD command.
For information on resolving dependencies through a scheduled activity data set, see
the RESOLVE command.
Example 1 The following LISTSADL command displays SADLINKs:
LISTSADL
In the above example, all currently defined SADLINKs are displayed.
438
LISTSCH Command
Overview The LISTSCH command is used to display the Event names and times of the current
schedule cycle (normally 24 hours). These elements include the names and
execution times of all the Events in the schedule, and the overdue, held, or deferred
queues.
Authority OPER authority is required to issue the LISTSCH command.
Syntax The syntax of the LISTSCH command is:
{LISTSCH|LSCH} [FROM(starttime)]
[TO(endtime)]
[LEVEL(levelname)]
[MAXENTRY{(200)|(count)}]
[DEFERRED(eventdsid)]
[HELD(class)]
[OVERDUE]
[SUSPENDED]
[DATE]
[FLUSHED]
[NONSCHED]
starttime Indicates a valid start time. This may include a date. If the
specification includes blanks or commas, place it within
quotes.
endtime Indicates the end time and can include a date. If the
specification includes blanks or commas, place it within
quotes.
levelname Indicates a generic Event name specification. It may contain
asterisks and hyphens.
count Indicates a number from 1-1000. It specifies the maximum
number of entries to be displayed. This prevents a WTO
buffer shortage when output is directed to a console.
eventdsid Indicates the identifier of an Event data set whose deferred
queue is to be displayed.
class Indicates the name of a held class.
OVERDUE Indicates entries from the OVERDUE queue are displayed.
SUSPENDED Indicates all suspended Events are displayed.
439
LISTSCH Command, Continued
Syntax (continued)
DATE Indicates the date is included in the display as well as the
time.
FLUSHED Indicates entries that have been flushed from deferred queue
should be displayed. This Parameter is only valid with the
DEFERRED keyword. Flushed entries remain in the deferred
queue only while the system is quiesced. As soon as the
system is restarted, the entries are removed from the queue.
NONSCHED Indicates scheduled Events, as well as Events that are
expected to execute (EXPECT command) are displayed.
Usage notes The MAXENTRY keyword is only available with the console version of the
LISTSCH command.
Display portions of the schedule by using the FROM and TO keywords. The display
can also be restricted to various Event names.
The LISTSCH command does not display the names or submission times for
individual jobs within Events. To display the schedule for jobs refer to scheduled
activity reporting.
The LISTSCH command displays only scheduled Events. If you want to display
Events that do not have SCHEDULE commands, such as Events triggered by data
set activity you can use the EXPECT command when you define these Events. Use
the NONSCHED keyword on LISTSCH to include expected Events in the display.
The LISTSCH command displays Events from the current time up to the next
scheduled scan, which is normally at 6 am. Events triggered with the ADD option
are displayed on a LISTSCH command, even if the trigger time is past the next scan
time.
Related
information
For information on defining schedule criteria for an Event, see the SCHEDULE
command.
For information on telling ESP when an Event is expected to execute, see the
EXPECT command.
For information on displaying the next scheduled executions of an Event, see the
NEXT command.
440
LISTSCH Command, Continued
Example 1 The following is a sample of the display produced by the LISTSCH command:
LISTSCH
15.00.00 PROD.PAYROLL 15.00.00 PROD.BILLING
15.30.00 PROD.CLAIMS 16.00.00 USER01.TEST
17.45.00 CYBER.LIFE70 19.15.00 TEST.INVENTORY
20.00.00 CYBBS01.FRED 06.00.00 SCAN EVENT1
In the above, all entries on the current schedule are displayed.
Example 2 The following LISTSCH command displays Events:
LISTSCH DATE
In the above example, all Events are displayed, and the date is included in the
display. This is useful when you trigger Events for a time/date beyond the next scan
time.
Example 3 The following LISTSCH command displays specific Events:
LISTSCH LEVEL(GROUP1.PAY-)
In the above example, Events names beginning with PAY in group GROUP1 are
displayed.
Example 4 The following LISTSCH command displays held Events:
LISTSCH HELD(ABC)
In the above Events that are held in class ABC are displayed.
Example 5 The following LISTSCH command displays deferred Events:
LISTSCH DEFERRED(EVENT1)
In the above example, the names of Events deferred by the unavailability of the
Eventset with ID EVENT1 are displayed.
Example 6 The following LISTSCH command displays scheduled and expected Events between
specific times:
LISTSCH LEVEL(PROD) FROM(8PM) TO(11PM) NONSCHED
In the above example, scheduled and expected Events that belong to the PROD
group, with times between 8 pm and 11 pm, are displayed.
441
LISTSIG Command
Overview The LISTSIG command is used to display all generations of a signal.
Syntax The syntax of the LISTSIG command is:
{LISTSIG|LSIG} signalname
[ALL]
[PENDING]
signalname Indicates the name of the signal. If a prefix is not specified,
the current group or user is used. Signal name may contain
an asterisk (*) for wildcard characters and/or a hyphen (-) for
masking.
ALL Displays all information about signals. If ALL is not
specified and the signal name contains an asterisk (*) or a
hyphen (-), only summary information is displayed.
PENDING Display only signals with pending Events.
Signals are only available at the Event level. If you are using an Application and
need to set up conditions at the job level for jobs in the Application, the best method
is through tasks.
Related
information
For information on signals, see the ESP Workload Manager Advanced Users Guide.
For information on using tasks to set up conditions at the job level, see the ESP
commands.
For information on instructing an Event to wait for the posting of a signal, see the
SIGWAIT command.
For information on posting a signal, see the SIGPOST command.
For information on resetting the generation number of a signal, see the SIGCYCLE
command.
For information on changing the generation number of a signal, see the ALTSIG
command.
442
LISTSIG Command, Continued
Example 1 The following LSIG command displays information about a specific signal:
LSIG CYBER.SIGNAL99 ALL
In the above example, information about all generations of CYBER.SIGNAL99 is
displayed.
Example 2 The following LSIG command displays information for specific signals:
LSIG CYBER-
In the above example, summary information for all signals starting with the prefix
CYBER is displayed.
Example 3 The following LSIG command displays information for pending signals:
LSIG CYBER.- PENDING
In the above example, summary information for all signals starting with CYBER that
have pending Events is displayed.
443
LISTSPEC Command
Overview The LISTSPEC command is used to list special days and periods.
Syntax The syntax of the LISTSPEC command is:
{LISTSPEC|LS} name
[GROUP(groupname)]
[CALENDAR(calname)]
[FROM(fromdate)]
[TO(todate)]
[COMPRESS]
[RETAIN]
name Indicates a full or generic name of a special day/period. It
may contain asterisks and a hyphen. An asterisk indicates
that any character in that position is considered a match. A
hyphen indicates that all subsequent characters are considered
a match. If this parameter is omitted, all special days/periods
are displayed. Code a hyphen - if you are using any other
parameters and want all special days/periods displayed.
groupname Indicates special days/periods from the default calendars of
the specified group are displayed.
calname Indicates the name of the calendar to search. This parameter
is mutually exclusive with the GROUP parameter.
fromdate Indicates a start date for the special days displayed. Only
special days/periods that fall on or after this date are
displayed.
todate Indicates an ending date for the special days/periods
displayed. Only special days/periods on or before this date
are displayed.
COMPRESS Indicates a compact display is used. Several date and time
entries for each special day are placed on a display line rather
than the usual one entry per line. The number of entries per
line depends on the terminal screen width, or the output data
set logical record length
RETAIN Indicates the display include the length of time the special
day/period is retained (if retained).
444
LISTSPEC Command, Continued
Usage notes If no group name or calendar name is specified, the most recently retrieved set of
calendars is displayed. If no calendars were retrieved in the current command
session, the default calendars for the current group are displayed.
A start and/or end date can be specified to restrict the displayed special days/periods
to a specific time period. Special days/periods are displayed in time sequence order
within each calendar.
The display can be restricted to special days/periods containing a specified character
string. The first parameter specifies a special day/period name or generic name. If
you want all special days/periods to be displayed but need to use another parameter,
specify a hyphen (-) as the first parameter.
To specify a date, use any format that ESP recognizes. If the date contains any
blanks or commas, enclose the string in quotes.
Related
information
For information on specifying special days or periods in schedule criteria, see the
For information on defining and deleting special days or periods, see the DEFSPEC
and DELSPEC commands.
Example 1 The following LISTSPEC command displays special days and periods:
LISTSPEC or LS
In the above example, all the currently defined special days and periods from the
most recently retrieved set of calendars or default calendars are displayed.
Example 2 The following LISTSPEC command displays special days and periods on a specific
calendar:
LS - CALENDAR(PAYROLL)
In the example, all currently defined special days and periods on the PAYROLL
calendar are displayed.
Example 3 The following LISTSPEC command displays specific special days and periods for a
given year:
LISTSPEC P*Y- GR(PAYROLL) FROM(1JAN2002) TO(31DEC2002)
In the above example, all special days or periods in 2002 that begin with P and have
Y in position three of the name are displayed. The calendars to be searched are the
default calendars for the PAYROLL group.
445
LISTSPEC Command, Continued
Example 4 The following is an example of the display produced by the LISTSPEC command:
CALENDAR SYSTEM
FISCAL_YEAR_END
00.00 ON WEDNESDAY SEPTEMBER 30TH, 1998
---- 1 DATE LISTED ----
INVENTORY_DAY
00.00 ON FRIDAY FEBRUARY 6TH, 1998
00.00 ON FRIDAY MARCH 6TH, 1998
00.00 ON TUESDAY APRIL 7TH, 1998
---- 3 DATES LISTED ----
PAYDAY
00.00 ON FRIDAY JANUARY 30TH, 1998
---- 3 DATES LISTED ----
---- 3 SPECIAL DAYS DISPLAYED ----
In the above example, special days and periods defined on the SYSTEM calendar
are displayed.
446
LISTSYML Command
Overview The LISTSYML command is used to display information on the symbol libraries to
Syntax The syntax of the LISTSYML command is:
{LISTSYML|LSL} symlib
symlib Indicates the name of a symbol library set defined using the
DEFSYML command. It may contain asterisks and a hyphen
for generic masking.
Usage notes The information displayed includes the names of the data sets comprising the
symbol library set and user IDs or user ID masks with permitted read access to the
symbols.
Related
information
Guide.
For information on defining and deleting a symbol library, see the DEFSYML and
DELSYML commands.
Example 1 The following LISTSYML command displays a symbol library:
LISTSYML SYM1
In the above example, the attributes of the SYM1 symbol library are displayed.
Example 2 The following LSL command displays all symbol libraries:
LSL -
In the above example, the attributes of all symbol libraries to which you have access
are displayed.
447
LISTSYML Command, Continued
Example 3 The following is an example of the display produced by the LISTSYML command:
SYMLIB PAYSYM DEFINED BY USER01 AT 15.17 ON WEDNESDAY
JANUARY 28TH, 2002
DATASETS: CYBER.SYMBOLS.CNTL(DATES)
USERS: USER01
In the above example, the attributes of the PAYSYM symbol library are displayed.
448
LISTTRAK Command
Overview The LISTTRAK command is used to display information about the current status of
the job tracking file
Authority OPER authority is required to issue the LISTTRAK command.
Syntax The syntax of the LISTTRAK command is:
LISTTRAK
Usage notes The information displayed by this command includes when the data set was
formatted and the current allocation status including the number of free slots.
Example 1 The following is an example of the display produced by the LISTTRAK command:
OPER LISTTRAK
TRAKFILE CYB2.ESP510.TRAKFILE
9896 SLOTS TOTAL, 8127 AVAILABLE, NEXT IS 6979
The above example displays information about the current status of the job tracking
file.
449
LISTUSER Command
Overview The LISTUSER command is used to display a user definition. The LISTUSER
command is available only in non-SAF environments. The information displayed
includes authority attributes, default calendars, Eventset and Histfile access, and the
names of the groups to which the user is connected.
Syntax The syntax of the LISTUSER command is:
{LISTUSER|LU} userid
userid Indicates the name of the user definition to be displayed. It
may contain asterisks and the last character can be a hyphen if
you want to use masking. If the user ID is not specified, your
user ID definition is displayed.
Related
information
For information on defining users and groups, see the ESP Workload Manager
For more information on departments, see the ESP Workload Manager
For information on using authorization tables to control access to job tracking data,
see the ESP Workload Manager Administrators Guide.
For information on calendars, see the CALENDAR command.
For information on defining and deleting users, see the DEFUSER and DELUSER
commands.
Example 1 The following LISTUSER command displays all users:
LU -
In the above example, all users are displayed.
Example 2 The following LU command displays your user definition:
LU
In the above example, your user definition is displayed.
450
LISTUSER Command, Continued
Example 3 The following LU command displays a specific user entry:
LU USER1
In the above example, USER1 is displayed.
Example 4 The following LISTUSER command displays multiple users:
LISTUSER PROD-
In the above example, all users whose IDs begin with PROD are displayed.
451
LISTXMEZ Command
Overview The LISTXMEZ command is used to display cross memory tracking elements. A
cross-memory element (XME) is used to pass job and data set information between
address spaces and ESP systems.
Authority OPER authority is required to issue the LISTXMEZ command.
Syntax The syntax of the LISTXMEZ command is:
LISTXMEZ
Example 1 The following is an example of the display produced by the LISTXMEZ command:
OPER LISTXMEZ
CKPT SPACE USED BY JOB TRACKING XMES 824
MAX ALLOWED: NO LIMIT
0 XMES FOR A TOTAL OF 0(X'00000000') BYTES
QUEUE SPACE USED BY JOB TRACKING XMES 0
MAX ALLOWED: 128000 (DEFAULT)
0 XMES FOR A TOTAL OF 0(X'00000000') BYTES
In the above example, the cross-memory tracking elements are displayed.
452
LJ Command
Overview The LJ command is used to display the status of a job being tracked by ESP.
Syntax The syntax of the LJ command is:
LJ jobname
[ANCESTOR(genno)]
[ALL]
[STEPS]
[SUBMIT]
[PNODE]
[STATUS]
[DUEOUT]
[INFODATA]
[EXTENDED|X]
jobname Indicates the name or JES job number of the job to be
displayed. If the ID is all numeric, it is assumed to be a job
number, otherwise it is treated as a jobname. A job name
and job number can be specified together, with the job
number enclosed in parentheses, immediately following the
job name.
genno Indicates the ancestor generation number, with zero the most
recent job, 1 or -1 the previous job and so on. This operand
is ignored whenever a job number is specified. This operand
defaults to zero if a job name is used and no generation
number is specified.
ALL Indicates all the information for the job is displayed. This is
the same as specifying STEPS, SUBMIT, PNODE, and
INFODATA. This is the default.
STEPS Indicates step statistics are to be displayed for the job.
SUBMIT Indicates submission information, including JCL source data
set, Event name, data set trigger name if any, etc., is
displayed. This information is available only if ESP
submitted the job.
PNODE Displays the PNODE(s) for each job.
STATUS Displays the current status of the job.
DUEOUT Displays P-Node due out times for the job.
INFODATA Displays the Information Management record number
associated with this job if one was generated using the
Information Management interface.
EXTENDED or X Displays more detailed date and time information.
453
LJ Command, Continued
Usage notes ESP can track the progress of all or selected jobs, even those it did not schedule.
ESP provides real time information for each job step, including such information as
stepname, completion code, CPU time, elapsed time, and number of tape mounts.
You can request ESP to track jobs, started tasks (STCs), TSO users (TSUs), and
system messages. ESP must be set up to track jobs in an ESP Application.
The LJ command displays information from ESPs tracking file (TRAKFILE). The
amount of data stored on this file depends on its size. ESP re-uses slots in the
TRAKFILE as required.
Related
information
For information on displaying job level information from the CSF, see the ESP
For information on displaying tracked jobs, see the LTJ command.
For information on job tracking, see the ESP Workload Manager Administrators
Guide.
Example 1 The following LJ command display a job:
LJ PAYJOB1 STATUS
In the above example, the status of PAYJOB1 is displayed.
Example 2 The following LJ command displays a job by its JES job number:
LJ 1234
In the above example, a job whose JES job number is 1234 is displayed.
Example 3 The following LJ command displays a jobs Information Management record:
LJ PAYJOB2 INFODATA
In the above example, PAYJOB2s Information Management record is displayed.
Example 4 The following LJ command displays step level statistics:
LJ PAYJOB2 STEPS
In the above example, step level statistics are displayed for PAYJOB2.
454
LJ Command, Continued
Example 5 The following LJ command displays the second ancestor of a job:
LJ PAYJOB3 ALL AN(2)
In the above example, the second ancestor or -2 generation of PAYJOB3 is
displayed.
Example 6 The following is an example of the display produced by the LJ command.
LJ PAYJOB4 X
PAYJOB4 J08324, IN OUTPUT QUEUE SINCE 16.01.03 28JAN, CC 0
SUBMITTED BY ESP AT 16.01.03 ON WED 28JAN, EVENT CYBER.PAYROLL
JCL FROM CYBER.JCL.CNTL(PAYJOB4)
PROGRAMMER USR01, ACCOUNT CYB3000
JOB IS IN APPL PAYROLL
STEPNAME-PROCSTEP-PROGNAME--EXCP-#T-S-N-CPU-TIME-SUNITS-
REGIONCMPC
S1 IEFBR14 0 0 0 0 0:00.02 168 4K
0
PNODE----OUT------DATE--QTIME-POST_BY--SYS-
INPUT 16.01.02 28JAN 0 SYSA
EXEC 16.01.03 28JAN 1 SYSTEM SYSA
OUTPUT * 10M54
In the above example, detailed date and time information is displayed for PAYJOB4
using the EXTENDED or X parameter of the LJ command.
455
LOAD Command
Overview The LOAD command is used to load a series of ESP commands for execution.
Enter your commands into a PDS or sequential data set and issue the LOAD
command from Page mode to process these ESP commands.
Note: The LOAD command cannot be used in ESPs Initialization Parameters.
Syntax The syntax of the LOAD command is:
LOAD 'dsname'
dsname Indicates a valid data set name. The current user prefix is
added if the data set name is not enclosed within quotes. A
member name can be included within the data set
specification. The input data set can be sequential,
partitioned or VSAM ESDS. All record formats are
supported.
Usage notes One use of the LOAD command is to load Event definitions from a data set. Several
Event definitions can be included in one data set or member.
The LOAD command is useful when you have a number of repetitious commands to
execute (e.g. setting up holidays, defining users, reporting, etc.
456
LOAD Command, Continued
Example 1 The following is an example of a PDS member - CYBER.ESP.DATA(CMDS)
which contains ESP commands:
SMFSTATS
LDSN
LIST LEVEL(PROD)
To process the above ESP commands, issue the LOAD command from Page mode
as follows:
LOAD CYBER.ESP.DATA(CMDS)
The following is an example of the display produced by issuing the above LOAD
command:
SMFSTATS
ESP SUBSYSTEM INITIALIZED AT 10.11.59 ON THURSDAY DECEMBER
18TH, 1997
1490750 ENTRIES TO SMFWTM, 583358 BY BRANCH ENTRY AND 907392
BY SVC
168304 ENTRIES TO ESP PHASE 2
9562 JOB STARTS, 304 STC STARTS, 933 TSU STARTS, 20969 STEP
ENDS
LDSN
CHECKPOINT: CYB2.ESP510.CKPT, ALT NONE
USERDEF: CYB2.ESP510.USERDEF, BKUP NONE
INDEX: CYB2.ESP510.INDEX, BKUP NONE
JOBINDEX: CYB2.ESP510.JOBINDEX, BKUP
CYB2.ESP510.BKUP.JOBINDEX
QUEUE: CYB2.ESP510.QUEUE, ALT NONE
TRAKFILE: CYB2.ESP510.TRAKFILE
EVENTSET: CYB2.ESP510.EVENT1
HISTFILE: CYB2.ESP510.HISTFILE
APPLFILE: CYB2.ESP510.APPLFILE
JTDT: CYB2.ESP510.PARMLIB(JOBDEF1)
UPDT: CYB2.ESP510.PARMLIB(PROFILE)
LIST LEVEL(PROD)
PROOD.PAYROLL NEXT DUE AT 20.00.00 ON THU JAN 29TH,
1998
PROD.BILLING NEXT DUE AT 09.00.00 ON THU JAN 29TH,
1998
457
LOADAGDF Command
Overview The LOADAGDF command is used to load the Agent definition file.
Authority OPER authority is required to issue the LOADAGDF command.
Syntax The syntax of the LOADAGDF command is:
LOADAGDF dsname
dsname Indicates a sequential data set or a member of a partitioned
data set, enclosed in quotes.
TEST Indicates that all syntax and logical checks are performed, but
the table is not loaded.
Usage notes The LOADAGDF command is normally included in the ESP Initialization
Parameters to load the Agent definition file each time ESP initializes.
After making any changes to the Agent definition file, you can use the LOADAGDF
command to dynamically load a new table.
Related
information
For information on cross platform workload management, see the appropriate ESP
Workload Manager Extension Installation and User Guides.
Example 1 The following LOADAGDF command loads an agent definition file:
LOADAGDF CYBER.PARMLIB(AGENTDEF)
In the above example, AGENTDEF is loaded from CYBER.PARMLIB.
Example 2 The following LOADAGDF command tests an agent definition file:
LOADAGDF CYBER.PARMLIB(AGENTDEF) TEST
In the above example, ESP performs all syntax and logical checks on this Agent
definition file.
458
LOADJTDT Command
Overview The LOADJTDT command is used to load the job tracking definition table into the
system. ESP uses this table to determine what it needs to track.
Authority OPER authority is required to issue the LOADJTDT command.
Syntax The syntax of the LOADJTDT command is:
LOADJTDT dsname
dsname Name of sequential data set or PDS member containing the
job tracking definition table.
Usage notes Normally the job tracking table is loaded when ESP initializes.
You can replace the currently active job tracking definition table with a new table at
any time by reissuing the LOADJTDT command with the data set name that
contains the new table.
If more than one copy of ESP uses the same job tracking definition table, you need
to issue the LOADJTDT command for each ESP system.
The job tracking definition table is used for any job that ESP encounters and
overrides any other tracking definitions.
The job tracking definition table overrides any other tracking definitions in the
system, such as those defined with the DEFTJ command.
Related
information
For information on defining wildcard characters used in a job tracking definition
table, see the WILDCARD statement.
459
LOADJTDT Command, Continued
Example 1 The following LOADJTDT command loads a job tracking definition table:
OPER LOADJTDT CYBER.PARMLIB(JOBDEF1)
In the above example, JOBDEF1 is loaded from CYBER.PARMLIB.
460
LOADSCHF Command
Overview The LOADSCHF command is used to copy schedule information from a sequential
workfile to a VSAM file that can be viewed from the CSF.
Authority OPER authority is required to issue the LOADSCHF command.
Syntax The syntax of the LOADSCHF command is:
LOADSCHF
Usage notes The LOADSCHF command allows you to see future, scheduled workload from the
CSF. This is not a common practice.
The LOADSCHF command loads the schedule workfile into core and copies it into
the VSAM schedule file, both of which are identified by the SCHDFILE
Initialization Parameter. The schedule workfile must be a scheduled activity data
set. Information contained in the workfile is merged with old information.
The file must be seeded with Events that are scheduled to execute by the
SADGEN command, in a batch job, prior to loading.
Related
information
For information on purging information from the SCHDFILE, see the PURGSCHF
command.
For information on generating a scheduled activity data set, see the SADGEN
command.
Example 1 The following LOADSCHF command loads schedule information:
OPER LOADSCHF
In the above example, schedule information is loaded from a sequential workfile to a
VSAM file so that it can be viewed from the CSF.
461
LOADUPDT Command
Overview The LOADUPDT command is used to load the User Profile Definition Table from a
data set. The User Profile Definition Table contains one or more PROFILE
statements. User Profile Definition Tables are required only if the SAF interface is
being used.
Authority OPER authority is required to issue the LOADUPDT command.
Syntax The syntax of the LOADUPDT command is:
LOADUPDT dsname
dsname Indicates the fully qualified data set name, and can include a
member name. The data set can be any fixed or variable
length file with a record length of 80 or greater.
Usage notes You can issue the command in the ESP initialization data set, or once ESP is active
you can issue the command from your console. Once you have loaded the table, ESP
refers to the table, not to the data set. ESP always refers to the currently loaded
table.
The User Profile Definition Tables needs to be loaded after making changes.
If you are running more than one ESP system, you need to load the User Profile
Definition Table on each system.
Related
information
For information on identifying the Event prefix and the EVENTSET that ESP uses
to store the Event, see the PROFILE statement.
For information on using SAF, see the ESP Workload Manager Administrators
Guide.
Example 1 The following LOADUPDT command load the User Profile Definition Table:
LOADUPDT CYBER.PARMLIB(PROFILE)
In the above example, PROFILE is loaded from CYBER.PARMLIB.
462
LOGPRT Command
Overview The LOGPRT command is used to display Event log data collected in the trace data
set(s) during a specified time period.
Authority SPECIAL authority is required to issue the LOGPRT command in a non-SAF
environment.
Syntax The syntax of the LOGPRT command is:
LOGPRT DSN(dsname[,dsname]...)
[FROM(schedule)]
dsname Indicates the name(s) of the trace data set(s) to access for
Event log information. Separate data set names with a
comma.
schedule Indicates schedule criteria. The keyword UNTIL can be
used to restrict the time range. If UNTIL is not used, the
current time is used as the end time.
Usage notes This command is not normally used, as the same information is stored in ESPs audit
log. Immediately before using the LOGPRT command, issue the TRACE WRITE,
TRACE CLOSE and TRACE OPEN operator commands to ensure that the
LOGPRT command accesses all current trace data. Trace data set information is
displayed via the TRACE STATUS operator command.
Related
information
For information on printing a trace data set, see the TRACEPRT command.
Example 1 The following LOGPRT command displays logged information:
LOGPRT DSN(CYB.ESP.TRACE1) FROM(6PM YESTERDAY -
UNTIL 5AM TODAY)
In the above example, information logged between 6 pm the previous day and 5 am
this morning in CYB.ESP.TRACE1 data set is displayed.
463
LSAR Command
Overview The LSAR command is used to extract data from a scheduled activity data set to
produce a standard scheduled activity report.
Syntax The syntax of the LSAR command is:
LSAR DSN(dsname)
[JOB(jobname[,jobname]...)]
[GROUP(groupname)]
[NET(netid)]
[APPL(application)]
[JCL(jcldsn)]
[FROM(schedule)]
[TO(schedule)]
[TIMESEQ]
[STATUS]
[TAPEPULL(tapeds)]
[PROJECTED]
dsname Indicates the name of the scheduled activity data set that
contains scheduled activity information, enclosed in quotes.
Note: The scheduled activity data set is generated using the
SADGEN command.
jobname Indicates the name of the job(s) for which you want to display
a scheduled activity report. The use of asterisks and a hyphen
for masking is permitted to select a group of jobnames. If this
parameter is omitted, then data on all scheduled jobs is
generated.
groupname Indicates an ESP group name prefix for which you want to
generate a scheduled activity report. The use of asterisks and
a hyphen for masking is permitted.
netid Indicates the identifier for an ESP/DJC or JES3 job network.
The use of asterisks and a hyphen for masking is permitted.
application Indicates the name of an Application for which you want to
display a scheduled activity report. The use of asterisks and a
hyphen for masking is permitted.
jcldsn Indicates the name of a JCL data set. It cannot be enclosed in
quotes. Only jobs whose JCL that resides in this data set are
included in the scheduled activity report.
464
LSAR Command, Continued
Syntax (continued)
schedule Indicates a valid schedule statement. If the statement
contains separators then it must be enclosed in quotes. The
keywords ENDING or UNTIL can be used to restrict the
time range selected.
TIMESEQ Indicates the display of scheduled activity should be sorted in
ascending time sequence according to the schedule time for
the job. If this keyword is omitted, the display is sorted in
alphabetical sequence by jobname. If more than one
occurrence of a job is scheduled, the jobnames are sorted by
time sequence within a jobname category.
STATUS Indicates an updated status display is required instead of the
regular schedule display. This gives the status of all the jobs
in the schedule, as well as time and percentage of schedule
still remaining. Actual start and end times, completion code
and rerun indicators are also displayed. This can only be used
after the SADUPD command has generated updated
information.
tapeds Indicates the name of a preallocated PDS used to store tape
data set information. A member is created for each job,
which can then be used as input to the TMS or CA1, tapepull
program. This parameter is used in conjunction with the
INPUTDS Application statement.
PROJECTED Creates a Projected vs. Actual report. This report shows
projected start/end times based on MODEL processing and
actual start/end times. Prior to running this report, a model
must be run to update the projected times in the SAD file, and
the SADUPD command must be used to update the SAD file
with actual run information.
465
Usage notes Since the LSAR command uses information from a scheduled activity data set, you
can only display information that was written to that data set using the SADGEN
command.
If you do not use the FROM keyword, the starting time for the scheduled activity
report defaults to NOW. If you do not use either ENDING or UNTIL with the
FROM keyword, and you do not specify TO, then the scheduled activity report
contains all data stored in the scheduled activity data set as generated by the
SADGEN command.
You may only generate a scheduled activity report on a group to which you have
access. If you want a report on all scheduled jobs, then you do not need to use any
of these selection keywords. Use the STATUS keyword to obtain a scheduled
versus actual report (i.e. after the SADUPD command) or use the TAPEPULL
keyword if you are using the tapepull facility.
The DSN parameter must be the first parameter after the LSAR command.
To produce scheduled activity reports online, use option S - Schedule Activity from
the ESP Main Menu.
Related
information
Users Guide.
For information on modeling, see the ESP Workload Manager Advanced Users
Guide.
For information on generating scheduled activity data set, see the SADGEN
command.
For information on updating a scheduled activity data set with actual information,
see the SADUPD command.
Example 1 The following is an example of JCL that could be used to produce a schedule
activity report:
//jobname JOB
//STEP1 EXEC PGM=ESP,PARM='SUBSYS(E510)'
//SYSIN DD *
LSAR DSN('CYBER.SAD')
/*
In the above example, the LSAR command is run in batch to produce a scheduled
activity report.
Note: Before running this job, ensure the scheduled activity data set contains
schedule activity information. To generate a scheduled activity data set, use the
SADGEN command in batch only. You may combine the SADGEN and LSAR
commands in the same job by running a step for each command.
466
Example 2 The following LSAR command produces a scheduled activity report:
LSAR DSN(CYBER.SAD) JOB(PAY-) -
FROM(8PM TODAY UNTIL 8AM TOMORROW) TIMESEQ
In the above example, a report is produced on activity scheduled in the 12-hour
period starting at 8 pm tonight using the CYBER.SAD scheduled activity data set.
The display is restricted to jobnames beginning with the characters PAY, and is
presented in scheduled time sequence.
LSAR DSN(CYBER.SAD) TO(2:30AM TOMORROW)
In the above example, scheduled activity information on all jobs scheduled for
submission from NOW until 2:30 am tomorrow morning is produced. The display is
presented in jobname sequence, by default. Data is extracted from the CYBER.SAD
data set.
LSAR DSN(CYBER.SAD) STATUS
In the above example, a status display of scheduled activity information as stored in
the CYBER.SAD scheduled activity data set is produced. This data set must have
been updated using the SADUPD command.
Example 5 The following LSAR command produces a report showing each jobs projected and
actual start and end times:
LSAR DSN(CYBER.SAD) PROJECTED
In the above example, a Projected vs. Actual report is produced using information
stored in the CYBER.SAD scheduled data set.
LSAR DSN(CYBER.SAD) APPL(PAYROLL)
In the above example, a status display on scheduled activity information for the
PAYROLL Application is produced.
467
LSAR DSN(CYBER.SAD) JCL(PROD.BACKUP.JCL)
In the above example, a status display on scheduled activity information for jobs
residing in PROD.BACKUP.JCL is produced.
468
LSYS Command
Overview The LSYS command is used to display information about the current ESP system
and can optionally provide information about other systems sharing the same
QUEUE data set.
Authority OPER authority is required to issue the LSYS command.
Syntax The syntax of the LSYS command is:
LSYS [sysid]
sysid Indicates the ESP system identifier you want to display
information about. The ESP system identifier is specified
using the SYSID Initialization Parameter. This field can
contain asterisks and a hyphen. If this field is omitted,
information about the current system is displayed.
Usage notes The type of information this command displays includes the CPU model, CPU
serial, the system ID on which ESP is running, the checkpoint data set name, and the
time of the last access to the QUEUE data set.
Related
information
Installation Guide.
Example 1 The following is an example of the display produced by the LSYS command.
OPER LSYS
SYS: E510, SMF ID SYSA, CPU SERIAL 003655, MODEL 9672
LAST QUEUE ACCESS AT 21.42.32 ON THURSDAY JANUARY 29TH,
1998
CHECKPOINT DATASET CYB2.ESP510.CKPT
In the above example, information about the current ESP system is displayed
Example 2 The following LSYS command displays an ESP system:
LSYS E510
In the above example, information about the E510 system is displayed
469
LSYS Command, Continued
Example 3 The following LSYS command displays specific ESP systems:
LSYS ESP-
In the above example, information about ESP systems with ESP in the first three
positions is displayed
470
LSYSMSGS Command
Overview The LSYSMSGS command displays information on all the system messages that are
currently being intercepted by ESP.
Authority OPER authority is required to issue the LSYSMSGS command.
Syntax The syntax of the LSYSMSGS command is:
LSYSMSGS
Related
information
For information on intercepting system messages written to the system message data
set, see the SYSMSGS command.
For information on clearing system messages, see the CLRSYSMS command.
Example 1 The following is an example of the display produced by the LSYSMSGS command:
OPER LSYSMSGS
'IEF142I' ID(0001), NAME(PAYJOB1), EVENT(CYBER.PAYSTEP)
'NOT CATLGD' ID(0002), COL(50:60), WTO, JOBNAME, CANCEL
'IEF253I' ID(0010), DESC(2), NAME(A-), EVENT(CYBER.CAN),
CANCEL
In the above example, information on all the system messages intercepted by ESP is
displayed.
471
LTCELL Command
Overview The LTCELL command is used to display tracking cell (TCELL) information,
including the size and current usage of each cell.
Syntax The syntax of the LTCELL command is:
LTCELL
Usage notes TCELLs are required to pass job start, step end, job end and job purge information
to the ESP subsystem.
Related
information
For information on defining tracking storage cells, see the TCELL Initialization
Parameter in the ESP Workload Manager Installation Guide.
Example 1 The following is an example of the display produced by the LTCELL command.
CELSIZE-POOLSZ-MAXSIZE-CURRUSE-MAXUSED-GETMAINS-OVERFLOW
104 100 5100 0 63 0 0
160 100 5100 0 28 0 0
168 100 5100 0 31 0 0
In the above example, tracking cell information is displayed
472
LTJ Command
Overview The LTJ command is used to display the definition for a tracked job or group of
tracked jobs as stored in the job index file.
Syntax The syntax of the LTJ command is:
LTJ jobname
[PREFIX]
[OWNER(ownerid)]
[MODEL(modelname)]
[INDEX]
jobname Indicates the name of the job or jobs to be displayed. The job
name specification can contain asterisks and a hyphen so you
can select groups of jobs through masking.
PREFIX Indicates the prefix entries are displayed rather than job
definitions. This is not applicable if you are using job
tracking definition tables.
ownerid Displays only jobs with ownership strings equal to or
superseding the specified ownership string. It consists of up
to eight alphanumeric characters and can contain asterisks
and a hyphen. This is not applicable if you are using job
tracking definition tables.
modelname Displays only jobs having a matching track model name. The
model name can consist of up to eight alphanumeric
characters, including asterisks or a hyphen.
INDEX Indicates a display of the index for the job is generated. The
job number, submission date and time, current status and
completion code of each indexed job is listed.
Usage notes The LTJ command displays the tracking characteristics of a job, as defined in the
job tracking definition table or through the DEFTJ command, rather than the
tracking data on a particular submission of a job.
Related
information
For information on displaying job level information from the CSF, see the ESP
For information on displaying the status of a job being tracked by ESP, see the LJ
command.
473
LTJ Command, Continued
Example 1 The following LTJ command displays tracking status:
LTJ PAYJOB1
In the above example, the tracking status of PAYJOB1 is displayed.
Example 2 The following LTJ command displays all jobs using specific tracking models:
LTJ - MODEL(PROD-)
In the above example, all jobs using tracking models with names beginning with
PROD are displayed.
Example 3 The following LTJ command displays index information for a specific job:
LTJ PAYJOB1 INDEX
In the above example, the job index information for the job PAYJOB1 is displayed.
The last n submissions of the job are displayed, where n is limited by the index
count, which was already defined for the job.
Example 4 The following is an example of the display produced by the LTJ command with the
INDEX parameter specified:
LTJ PAYJOB1 INDEX
JOB PAYJOB1, MODEL MODEL1, OWNER NONE, 10 JOBS INDEXED, 10 MAX
J08720 ON RDR AT 20.00 THU 29JAN98, ENDED, CC 0, 0.0 MINS_EXEC, 0:00 CPU
J08630 ON RDR AT 16.01 THU 29JAN98, ENDED, CC S806, 0.0 MINS_EXEC, 0:00 CPU
J08414 ON RDR AT 20.00 WED 28JAN98, ENDED, CC 0, 0.0 MINS_EXEC, 0:00 CPU
In the above example, a display of the index for PAYJOB1 is generated.
474
LTM Command
Overview The LTM command is used to display the definition of one or more tracking models.
Syntax The syntax of the LTM command is:
LTM name
name Indicates the name of the tracking model to be displayed. It
can contain asterisks and a hyphen to select multiple
matching entries.
Usage notes The DEFTM command allows you to centralize the definition of tracking
characteristics that can be assigned to one job, or a group of jobs. Jobs are normally
associated with a tracking model via a job tracking definition table.
Any data defined through the DEFTM command is displayed. The field
NOPRINTDATA of the display is reserved for future use.
Related
information
For information on defining/altering and deleting a tracking model, see the DEFTM
and DELTM commands.
Example 1 The following LTM command displays a tracking model:
LTM MODEL1
In the above example, the definition for the MODEL1 tracking model is displayed.
Example 2 The following LTM command displays all tracking models:
LTM -
In the above example, all tracking models are displayed.
475
LTZONE Command
Overview The LTZONE command is used to display the current time zone settings.
Syntax The syntax of the LTZONE command is:
LTZONE
Related
information
Installation Guide.
For information on defining time zones, see the TIMEZONE Initialization Parameter
in the ESP Workload Manager Installation Guide.
Example 1 The following is an example of the display produced by the LTZONE command.
LTZONE
CODE--ZONE------OFFSET ! CODE--ZONE------OFFSET ! CODE--ZONE------OFFSET
0 LOCAL 5.00W ! 1 UTC 0.00E ! 2 GMT 0.00E
3 Z 0.00E ! 5 EST 5.00W ! 6 CST 6.00W
7 MST 7.00W ! 8 PST 8.00W ! 9 AST 4.00W
10 EDT 4.00W ! 11 CDT 5.00W ! 12 MDT 6.00W
13 PDT 7.00W ! 14 ADT 3.00W ! 16 EASTERN 5.00W
17 CENTRAL 6.00W ! 18 MOUNTAIN 7.00W ! 19 PACIFIC 8.00W
20 ATLANTIC 4.00W ! 21 NFNDLAND 3.30W
In the above example, the current time zone settings are displayed
476
MAPGEN Command
Overview The MAPGEN command is used to create a job mapping data set that can then be
used by the JOBMAP and JOBTREE commands to produce detailed job level
information.
Syntax The syntax of the MAPGEN command is:
MAPGEN DATASET(dsname)EVENT(name)
DATASET(dsname) Indicates a fully qualified data set name. This data set
must be sequential, preallocated and should specify the
following DCB attributes:
RECFM=VBS
LRECL=32756
BLKSIZE=16384
BLKSIZE=27998 - for 3390 devices
EVENT(name) Indicates an Event descriptive name (without the prefix)
and may contain wildcards. Does not work with the Event
owner as the descriptive name.
Usage notes The MAPGEN command is available only as a batch job step.
Events may be scheduled or may require manual or data set triggers. There is no
need for these events to have been executed previously as history data is not
required for the jobs. If history data is available, this historical information is
incorporated into the job mapping report.
Related
information
For information on producing a job map report, see the JOBMAP command.
For information on producing a job descendent tree report, see the JOBTREE
command.
477
MAPGEN Command, Continued
Example 1 The following is an example of a batch job to create a job mapping data set:
//jobname JOB ...
//MAPGEN DD DSN=MY.MAPGEN,DISP=(,CATLG),
// UNIT=SYSDA,SPACE=(TRK,(40,20)),
//
DCB=(DSORG=PS,RECFM=VBS,LRECL=32756,BLKSIZE=16384)
//STEP2 EXEC ESP,PARM='SAR'
//SYSPRINT DD SYSOUT=A
//SYSIN DD *
MAPGEN DATASET('CYBER.MAPGEN') EVENT(PAY-)
/*
In the above example, a job mapping data set for all jobs invoked by Events whose
descriptive name begins with PAY is generated.
Note: The MAPGEN command must be executed through the ESP subsystem
started task Procedure with a special parm (PARM=SAR or PARM=SAD).
Other examples Here are more examples using the MAPGEN command.
Generates a job mapping data set for all jobs :
MAPGEN DATASET(CYBER.MAPGEN) EVENT(-)
Generates a job mapping data set for all jobs invoked by an Event with a descriptive
name of PAYROLL:
MAPGEN DATASET(CYBER.MAPGEN) EVENT(PAYROLL)
478
MAPUSER Command
Overview The MAPUSER command is used to map a non-SAF user ID to a valid SAF user ID
in the Agent Definition File. It is part of the encrypted message read by the ESP
Manager for authentication purposes.
MAPUSER can also be used as an OPER command in ESP to show the current
mapping status.
Authority OPER authority is required to issue the MAPUSER command.
Syntax The syntax of the MAPUSER command is:
MAPUSER user TO(central manager userid) AGENT(agentname)
user Indicates the server user ID to be mapped. The user parameter
is case sensitive and supports wildcards. It has a maximum
length of 32 alpha/numeric characters.
central manager
userid
Indicates the SAF user ID the user/agentname combination
should map to.
agentname Indicates the name of the Agent the user ID came from.
Example In the following example, the Manager is instructed to use CYBJD01 for security
checks when it sees the user ID jdoe, from Agent hp_toronto.
MAPUSER jdoe TO(CYBJD01) AGENT(hp_toronto)
This is an example of the display the command OPER MAPUSER will produce.
The attributes of the MAPUSER command are defined in the AGENTDEF file.
479
MAXINITS Command
Overview The MAXINITS command is used to define the maximum number of initiators
available on all systems in your model process. The MAXINITS command is one of
the components involved in defining your environment to produce modeling reports
which forecast how ESP processes groups of jobs in your particular environment.
Type Model command.
Syntax The syntax of the MAXINITS command is:
MAXINITS initnum
[SERVERS(servernum)]
initnum Indicates the maximum number of initiators available on all
CPUs. Up to 999 initiators may be specified.
servernum Indicates the maximum number of dummy initiators in the
range 1-99 to service ESP links and tasks. If not specified,
the default is 20. The SERVERS keyword should not be used
unless required.
Usage notes Use the MAXINITS command to define the maximum number of initiators for the
model. This should include initiators across all CPUs. A maximum of 999 initiators
can exist for each model.
All initiators specified by the MAXINITS command is defined to the MODEL
processor in the drained state. Each initiator must be started by the INIT
command as required.
Use INIT START, SET and STOP to start, alter and drain initiators any time during
the model process.
Server initiators are transparent to the user. They are internal initiators used to
schedule ESP links and tasks. By default, there are 20 of these initiators available at
any one time.
There is no need to specify the SERVERS keyword unless your installation
schedules a large number of manual task or link jobs at the same time. Because
these are dummy jobs requiring no system resources, they can be scheduled as
soon as their predecessors complete. An increase in the number of server initiators
allows more of these dummy jobs to be scheduled at the same time, increasing
throughput.
Related
information
For information on how ESP processes workload in your environment, see
Advanced Forecasting in the ESP Workload Manager Advanced Users Guide.
480
MAXINITS Command, Continued
Example 1 The following MAXINITS and INIT commands define initiators to be used during a
model process:
MAXINITS 20
INIT START(1:10) CLASS(A,B,C)
INIT START(11:15) CLASS(D,E)
INIT START(16:20) CLASS(F)
The maximum number of initiators available during the model process is 20
Initiators 1 to 10 are started and set to classes A, B and C
Initiators 11 to 15 are started and set to class D and E
Initiators 16 to 20 are started and set to class F.
Note: Any time during the model process you can manipulate initiators similar to
the way initiators are manipulated in your environment using the START, SET and
STOP parameters of the INIT command. For example, if required, initiators 16 to
20 can be drained by issuing the following command:
INIT STOP(16:20)
Example 2 The following MAXINITS command defines initiators to be used during a model
process:
MAXINITS 100 SERVERS(50)
In the above example, 100 initiators are available during the model process to
schedule regular jobs; 50 server initiators are available to schedule ESP links and
tasks.
481
MEMBER Statement
Overview The MEMBER statement is used to specify the member name where ESP finds a
jobs execution JCL. The default member name is equal to the job name.
Syntax The syntax of the MEMBER statement is:
MEMBER membername
membername Indicates a member name in up to eight characters.
Usage notes When ESP encounters a JOB statement for a job, it uses the JCL member in the
JCLLIB with the same name as the job. Use the MEMBER statement to override
this action.
The name on the JOB statement must match the job name on the job card in the JCL
member.
Related
information
For information on identifying a JCL library, see the JCLLIB statement.
DATASET statement.
Example 1 The following MEMBER statement specifies the member name where ESP finds a
jobs execution JCL
APPL PAYROLL
JOB PAYJOB1
MEMBER PAYJOB99
RUN WORKDAYS
ENDJOB
In the above example, ESP submits PAYJOB1s execution JCL from member
PAYJOB99.
482
MEMBER Statement, Continued
Example 2 The following JCLLIB, MEMBER and DATASET statements are used to specify
different JCL libraries and members:
APPL PAYROLL
JOB PAYJOB2
RUN DAILY
REL PAYJOB3
MEMBER PAYJOB99
JOB PAYJOB3
RUN DAILY
ENDJOB
ESP uses the default JCL library CYBER .JCL.CNTL to submit PAYJOB2s
execution JCL from member PAYJOB99
ESP uses CYBER.ALTJCL.CNTL to submit PAYJOB3s execution JCL.
Example 3 The following JCLLIB, MEMBER and DATASET statements are used to specify
different JCL libraries and members:
APPL PAYROLL
JOB PAYJOB4
RUN DAILY
REL PAYJOB5
MEMBER BACKUP
JOB PAYJOB5
RUN DAILY
REL PAYJOB6
JOB PAYJOB6
RUN DAILY
MEMBER BACKUP
ENDJOB
ESP uses the default library of CYBER.JCL.CNTL to submit PAYJOB4s
execution JCL from member BACKUP
ESP uses library CYBER.ALTJCL.CNTL to submit PAYJOB5s execution JCL
ESP uses library CYBER.ALTJCL.CNTL to submit PAYJOB6s execution JCL
from member BACKUP.
483
MGRADDR Command
Overview The MGRADDR command is used to notify one or more Agents of the ESP
Managers address (host name or TCP/IP address), so the Agent knows to which
Agent receiver to connect.
Authority OPER authority is required to issue the MGRADDR command.
Syntax The syntax of the MGRADDR command is:
MGRADDR {AGENT}
{AGENT(agents)}
{AGENT(agents) PORT(port)}
{DISPLAY}
{HELP}
{LIST}
AGENT Used to send notification to all Agents.
(agents) Indicates the unique name of the Agent, as defined in the
AGENTDEF file. You can specify the - wildcard suffix.
(port) Used to tell an Agent to which Agent receiver port number to
connect.
DISPLAY Displays the local ESP Managers address and home TCP/IP
address. (They are the same if MANAGER TCP/IP is
specified in the AGENTDEF file).
HELP Displays MGRADDR command options.
LIST Displays the local ESP Managers address and home TCP/IP
address. (They are the same if MANAGER TCP/IP is
specified in the AGENTDEF file).
Usage notes The MGRADDR command is useful if the ESP Master is stopped on one system and
started on another because the TCP/IP address changes.
484
MGRADDR Command, Continued
Examples of
Agent
notification
To send Manager address notification to all Agents, enter the following:
MGRADDR AGENT
or
MGRADDR AGENT(-)
To send Manager address notification to Agents with name prefix CYB, enter the
following:
MGRADDR AGENT(CYB-)
To send Manager address notification to Agent CYBAIX, and to tell it to connect to
Agent receiver TCP/IP port 5451, enter the following
MGRADDR AGENT(CYBAIX) PORT(5451)
Displaying the
manager
address
To display the local ESP Managers address and home TCP/IP address, enter one of
the following:
MGRADDR
MGRADDR DISPLAY
MGRADDR LIST
485
MGRMSG Command
Overview The MGRMSG command is used to request actions to be performed, by the
Manager, on workload objects, and report object state changes.
Type Automation Framework Message used from an ESP Procedure, or page mode and
line mode.
Authority MGRMSG checks to see if the user has appropriate access (READ or UPDATE) to
an Application before performing the requested action.
Syntax The syntax of the MGRMSG command is:
MGRMSG (date|.|*} {time|.} {to|.} {from|.} re verb
verbmodifier
date Indicates the date the message is sent. The format of the date
is YYYYMMDD. If omitted, a period(.) or asterisk(*) should
be used as a placeholder. An asterisk is interpreted as the
current date and time, and will cause the next field to be
ignored.
time Indicates the time the message is sent. If omitted, a period(.)
should be used as a placeholder. The format of the time is
HHMM[SS[TH]][{+|-}hhmm]. Where HH is the current hour
in 24-hour format, MM is minutes into the hour, SS and TH
are seconds and hundredths of seconds. The time may
immediately be followed by a time zone. A time zone is
specified with a - indicating a time zone EAST of the Prime
Meridian, and + indicates a time zone that is WEST.
to Indicates the network address of the destination, as seen from
the sender.
from Indicates the address of the sender.
re Indicates the name of the object to which this message refers.
In the case of ESP Applications, the object name is in the
form, oooo[.qqqq]/aaaaa.ggggg/fffff. Where oooo is the
object name, qqqq is the optional qualifier, aaaaa is the
Application name, ggggg is the generation number of the
Application and fffff is the appl file name. Currently, there is
only one appl file, and its name is MAIN. This field uniquely
identifies this object across the entire system management
scope.
486
MGRMSG Command, Continued
Syntax
continued
verb Indicates the intent of the message. Verbs define large areas
of action, for example, ACTION, STATE and RESPONSE.
See the table below for descriptions of verbs.
verbmodifier Indicates a modifier for the verb. If omitted, a period(.)
should be used as a placeholder.
Examples The following are examples of Automation Framework messages:
19941102 102322-0500 AIX01 APPLMGR@PROD UJ1/AIXAPPL01.1/MAIN
RUN . Data(
19941102 1023 APPLMGR@PROD AIX01 UJ1/AIXAPPL01.1/MAIN STATE
Complete CMPC(0)
Verbs The ESP Application Manager accepts messages with the following verbs:
Verb Description
ACTION Requests some action be applied to a workload object, such
as Hold or Release. The verb modifier indicates the actual
action.
STATE Indicates a change of state for the object. The new object
state is supplied in the verb modifier field.
RESPONSE Indicates a response is being made for a request sent to an
agent. It does not indicate a change of state for the object.
ACTION verb
modifiers
The following verb modifiers can be used with the ACTION verb:
Verb modifier Description
BYPASS Turns on the BYPASS indicator for the object.
DROPDEP Drops some or all predecessor dependencies for the object.
Variable data consists of the keyword Pred, followed by a list
of object names in parentheses. Blanks or commas can separate
object names. If this keyword is omitted, all dependencies will
be dropped.
DROPRES Drops some or all resources. Variable data consists of the
keyword Resource, followed by a list of resource names in
parentheses. Blanks or commas can separate resource names. If
this keyword is omitted, all resource requirements will be
dropped.
HOLD Turns on the HOLD flag for the object.
487
ACTION verb
modifiers
continued
INSERT Causes a new workload object to be inserted into the
application. For a description of the variable keywords
available, see below.
READY Requests the object be immediately placed in the READY state.
Any dependencies, hold states or delay submit times are
dropped.
RELEASE Indicates the object can have the HOLD attribute removed. This
may cause a change of state for the object.
REQUEST Turns on the REQUESTED indicator of an object.
RESET Requests one or more of the objects properties be modified. For
a description of the variable keywords available, see below.
RESUB Request the object be scheduled for re-execution. For a
description of the variable keywords available, see below.
UNBYPASS Turns off the BYPASS indicator of an object.
UNREQUEST Turns off the REQUESTED indicator of an object.
UNWAIT Removes the ancestor wait attribute of the object.
UPDATESCBD Causes the Update_SCBE method of the object to be invoked.
Variable data is object implementation defined.
Examples The following are examples of ACTION verb modifiers. Note the fields in the
message are case sensitive. The Manager converts the object name and verb to
uppercase, but all other fields are left in their original case.
MGRMSG * . applmgr aix01 JOB2/APPL1.5/MAIN ACTION HOLD
MGRMSG * . applmgr aix01 JOB2/APPL1.5/MAIN ACTION RESUB
MGRMSG * . applmgr aix01 JOB2/APPL1.5/MAIN ACTION DROPDEP -
Pred(JOB2)
INSERT and
RESET actions
The following is a description of the variable keywords available with the INSERT
and RESET actions. Keywords marked with an asterisk and underlined are ignored
with a RESET request.
Keyword Description
AbandonDependency() Time/Date when dependencies are to be dropped.
AbandonSubmission() Time/Date when submission of the object to execution is
to be abandoned.
Appl*() Specifies the name of an application for an external object.
Authstr*() Specifies the authorization string that is associated with an
external object.
AverageCPU() Average CPU time consumed, in the form mmmss.
AverageElapsed() Average elapsed time in the form mmmss.
488
INSERT and
RESET actions
continued
Keyword Description
Conditional Indicates this is a conditional job.
Doclib() Specifies the name of the library containing documentation for
the object.
Docmem() Member name of documentation library entry.
Dsname() Submit data set name.
EarlySub() Time before when object should not be readied.
Espprocfile() Specifies the name of the library containing the objects
definition (ESP Procedure file)
External* Indicates object refers to an object in another application.
Hold Requests the object be placed in a manual hold condition.
LateEnd() Time/Date when an object should complete to avoid becoming
overdue.
LateSub() Time/Date when an object should start to avoid becoming
overdue.
Manual* Indicates this object is a manually submitted MVS job.
Pred() Specifies the names of any predecessor objects. There is no limit
to the number of objects specified here. The object names are in
the form nnnn.qqqq for a qualified object, or nnnn for an object
without a qualifier. Object names can be separated by blanks or
commas.
Priority() Specifies the priority the workload object is to have. This is a
number from 0 99.
Process Indicates whether Event processing is required for tasks or links.
RelDelay() Specifies a minimum delay time to be added to a job after its last
dependency has been met.
Request Indicates the object has the REQUEST attribute. In order to run,
it has to be explicitly requested.
Resource() Specifies resources the object requires in order to be eligible for
execution. Parameters are specified in the form nnnn,rrrr where
nnnn is a numeric quantity and rrrr is the name of a resource. A
resource requirement can be nullified by setting the quantity to
zero. The quantity can be omitted, in which case it defaults to 1.
For example,
Resource(CICS01,2,TAPES,3,SCRATCH,DBTABLE1)
requests 1 unit of CICS01 and DBTABLE1, 2 units of TAPES
and 3 units of SCRATCH.
Scheduled*() This indicates the scheduled time an external object must
possess in order to match this object definition.
489
INSERT and
RESET actions
continued
Keyword Description
Statements() Specifies one or more statements that should be executed as part
of the processing of the Event/Procedure that is invoked when
this object is readied. Separate each statement with a semicolon.
These statements will be executed after all procedure statements
have been processed. An object need not be defined in the ESP
Procedure. For example, to specify an Agent name and exit code,
specify Statements(Agent AIX01;EXITCODE0-5 SUCCESS)
Subappl*() Specifies the name of the subappl to which the object belongs.
Succ() Specifies the names of any successor objects. There is no limit to
the number of objects specified here. The object names are in the
form nnnn.qqqq for a qualified object, or nnnn for an object
without a qualifier. Blanks or commas can separate object
names.
Tag() Specifies a tag for the object.
Type*() Specifies the object type. This should be JOB, LINK, TASK or
the long or short name of a workload object class.
Examples The following are examples of INSERT and RESET actions:
MGRMSG * . applmgr . JOB5/APPLA.5/MAIN ACTION INSERT Type(Job) -
Hold Pred(JOB2,JOB3.A) Earlysub(21.00 Today) Tag(STREAM1)
* . applmgr . JOB2/APPLA.4/MAIN ACTION RESET Pred(JOB1) -
AbandonSubmission(6pm)
RESUB action The following is a description of the variable keywords available with the RESUB
action:
Keyword Description
From() Restart point.
Jobid() Identifier of original job being restarted.
RestartParm() Parameter string to be passed to the restart processor.
To() Last processing step to be rerun.
User1() User restart variable 1.
490
STATE verb The following verb modifiers can be used with the STATE verb:
Active Indicates after the state of the object has been modified, the
Activate subroutine of the APPL Manager should be invoked.
This should be specified if the state change would be
expected to cause one or more objects to become eligible to
be readied.
Alert() Indicates the name of an Alert to be invoked. Specifying *
causes the Event that created the Application to be invoked as
a monitor Event. If this keyword is specified, also supply a
monitor point name via the MNPOINT keyword.
Cmpc() Specifies the completion code for the object.
Failed Indicates the FAILED condition should be set.
Intvrq Indicates intervention is required for the object.
Jobno() Sets the job number field of the object.
MNPoint() Supplies a value for the MNPOINT variable for the execution
of an Alert.
NoActivate Indicates the Activate subroutine of the APPL Manager
should not be invoked for this state change.
NoFailed Resets the FAILED indicator for an object.
NoIntvrq Turns off the intervention required condition for an object.
NoUpdateATR Indicates the Application tracking record should not be
updated to disk as a result of this state change message.
SetEnd Requests the end time for the object be set from the
timestamp of this message.
SetStart Requests the start time of the object be set from the time field
of this message.
Status() Specifies a system status string that should be attached to this
object.
Tag() Identifies a new tag field for this object.
RESPONSE
verb
Response messages have no predefined variable data. They are generated as a
response to an inquiry originated by the Application Manager or a workload object
implementation package.
491
MODEL Statement
Overview The MODEL statement is used to specify the name of the tracking model to be used
for this job.
Syntax The syntax of the MODEL statement is:
MODEL modelname
modelname Indicates a tracking model name in up to eight characters.
Usage notes The MODEL statement overrides the tracking model specified in the job tracking
definition table, for a job.
Related
information
command.
For information on defining and deleting a tracking model definition, see the
DEFTM and DELTM commands.
For information on using tracking models, see the ESP Workload Manager
Example 1 The following MODEL statement specifies the name of the tracking model:
APPL PAYROLL
JOB PAYJOB1
RUN DAILY
REL PAYJOB2
JOB PAYJOB2
RUN FRIDAY
MODEL ALTMODL
ENDJOB
In the above example, ESP uses tracking model ALTMODL for PAYJOB2
regardless of the entry in the job tracking definition table.
492
MODEL Command
Overview The MODEL command is used to activate the model processor. The model
processor updates the projected start and end times for jobs in the scheduled activity
data set. In additional to activating the model processor, the MODEL command
indicates the start of the model period.
Type Model command.
Syntax The syntax of the MODEL command is:
MODEL dsname
[START(schedule)]
[NOCLASS]
dsname Indicates the data set name of scheduled activity data set,
enclosed in quotes, to be used for MODEL processing.
schedule Indicates the start of the model period. If the statement
contains separators, it must be enclosed in quotes. The start
period defaults to now (current time/date) if not specified.
If no end time is specified, the default is the start time plus 12
hours.
NOCLASS Specifies class processing is bypassed for this model.
Initiator classes are not required when starting initiators and if
specified, are ignored. The NOCLASS option distorts your
modeling output. Jobs are selected for execution by any
available initiator regardless of their class. This could result
in major discrepancies between the forecast and actual
completion times of your workload. This option should be
used only in cases where an installation uses homogeneous
initiator classes or where you are interested only in a
Scheduled Jobs Cross-Reference (JR1) report.
Usage notes You cannot activate the model processor through ISPF panels or through an ESP
Procedure. Modeling is normally done in batch.
The START keyword defines the timeframe used to extract records from the
scheduled activity data set. Only jobs within the timeframe are used in the MODEL
generation.
After entering the MODEL command from Line mode or Page mode, the ESP
MODEL processor is activated and you can enter MODEL commands. Model
processor activation is indicated by:
The MODEL --> prompt from line mode
Or the MODEL MODE prompt in the upper left corner of the screen from Page
mode.
493
MODEL Command, Continued
Related
information
For information on ending the model process, see the ENDMODEL command.
Example 1 The following MODEL command activates the model processor:
MODEL CYBER.SAD
In the above example, jobs scheduled between now and now plus 12 hours (default)
are used in the MODEL generation.
Example 2 The following MODEL command activates the model processor and indicates the
start of the model period:
MODEL CYBER.SAD START(6AM TODAY ENDING 6AM TOMORROW)
In the above example, only jobs scheduled between 6 am today and 6 am tomorrow
are used in the MODEL generation.
Example 3 The following MODEL command activates the model processor and indicates the
start of the model period and that class processing be bypassed:
MODEL CYBER.SAD START(8AM TODAY ENDING 8PM TODAY) NOCLASS
In the above example, only jobs scheduled between 8 am today and 8 pm today are
used in the MODEL generation. Job classes are ignored. This is useful for
generating a Scheduled Jobs Cross-Reference (JR1) report to see job relationships.
494
MODEL Command, Continued
MODEL CYBER.SAD -
MAXINITS 8
MREPORT RPT1 JR1 FROM('4PM TODAY ENDING 4PM TOMORROW)
ENDMODEL
ENDPRINT RPT1
The ENDMODEL command ends the process
495
MONITOR Statement
Overview The MONITOR statement is used to identify the prefix of your job monitor Event
when you define your job in an Application. This prefix must be your user ID or a
group to which you have access. The job monitor Event must use a specific naming
convention.
Syntax The syntax of the MONITOR statement is:
MONITOR groupname
groupname Indicates an ESP Event group name prefix in up to eight
characters.
Usage notes When jobs are submitted, ESP detects that a specific monitor Event or a monitor
group exists for the job. A monitor group acts as a high level index to point ESP to
high-level Event prefixes. ESP uses the monitor group specified in an Application,
tracking model, or job documentation. ESP then searches and locates the monitor
Event. The identifier of the monitor Event must match the appropriate job and group
combination. A monitor Event states the monitoring requirements, including
monitor point and ESP action.
Specifying a MONITOR group within an Application does not override generic job
monitor Events defined using a tracking model.
The MONITOR statement can be used at a global level within an Application or at
the job level for a specific job. The MONITOR statement can not be used for jobs
defined as EXTERNAL or MANUAL in an Application. If you need to monitor an
EXTERNAL job, code the MONITOR statement in the Application where the job is
submitted, i.e. the home Application. If you need to monitor a MANUAL job, you
must identify the MONITOR group in a tracking model, using the DEFTM
command.
Related
information
For information on job monitoring, see the ESP Workload Manager Advanced
Users Guide.
For information on specifying a monitor group or generic job monitor Event, within
a tracking model definition, see the DEFTM command.
496
MONITOR Statement, Continued
Example 1 The following MONITOR statement identifies a monitor group prefix:
APPL PAYROLL
JOB PAYJOB1
RUN MONDAY
MONITOR PROD
ENDJOB
In the above example, PROD is identified as the monitor group for PAYJOB1. ESP
searches for Events with the PROD prefix that conform to the following naming
convention:
PROD.PAYJOB1_monitorpoint
Therefore, if a job end job monitor Event is defined for PAYJOB1, triggers the
following Event when PAYJOB1 ends.
PROD.PAYJOB1_JOBEND
Note: The same results can be achieved by identifying the monitor group within a
tracking model definition instead of within an Application. The following is an
example of the tracking model definition command:
DEFTM MODEL1 MONITOR(PROD) HISTFILE(HIST1) INDEX(5)
Example 2 The following MONITOR statement identifies a monitor group prefix for an entire
Application:
APPL PAYROLL
MONITOR CYBER
JOB PAYJOB2
REL PAYJOB3
JOB PAYJOB3
REL PAYJOB4
JOB PAYJOB4
ENDJOB
In the above example, CYBER is identified as the monitor group for all jobs within
the PAYROLL Application. ESP searches for Events with the CYBER prefix.
Therefore, if a step end monitor Event is defined for PAYJOB4, ESP triggers
CYBER.PAYJOB4_STEPEND after every step within PAYJOB4 ends.
497
MREPORT Command
Overview The MREPORT command is used to select the reports containing the modeling
output and specify the time range for each report.
Type Model command.
Syntax The syntax of the MREPORT command is:
MREPORT repname
{JR1|JR2}
{ER1|ER2}
{RR1|RR2}
[FROM(schedule)]
[CPU(cpunumber)]
[JOBS(jobname[,jobname]...)]
repname Indicates a one to eight alphanumeric character logical report
name as defined by the DEFPRINT command.
JR1 Generates a Scheduled Jobs Cross Reference report. Can also be
specified as JOB_REPORT_1.
JR2 Generates a Projected End Time report. Can also be specified as
JOB_REPORT_2.
ER1 Generates a Job Exception report. Can also be specified as
EXCEPTION_REPORT_1.
ER2 Generates a Dueout Exception report. Can also be specified as
EXCEPTION_REPORT_2.
RR1 Generates the Resource Utilization On Systems report. Can also
be specified as RESOURCE_REPORT_1.
RR2 Generates the Resource Utilization By Job report. Can also be
specified as RESOURCE_REPORT_2.
schedule Indicates a valid schedule statement. If the statement contains
separators, it must be enclosed in quotes. The keywords
ENDING or UNTIL can be used to restrict the time range
selected. An EVERY keyword can also be specified to control
the reporting increment. If the FROM keyword is not specified,
the default is now every two minutes until 6 am tomorrow.
cpunumber Indicates the CPU number for which the report is generated.
The valid range is 0-7 (up to eight CPUs supported). If not
specified, all CPUs are reported on. The CPU keyword is used
only when a RESOURCE_REPORT_1 (RR1) report is
requested.
498
MREPORT Command, Continued
Syntax (continued)
jobname Indicates a one to eight alphanumeric jobname or list of
jobnames to be included in the report. Asterisks or a hyphen as
the last character may be used to perform masking. The JOBS
keyword should be used only if you wish to limit a report to
certain jobnames or job prefixes. All jobs are reported on by
default if the JOBS keyword is not specified.
Usage notes The recommended data width for all reports is 133 with a record format of FBA.
Related
information
Example 1 The following MREPORT command selects the modeling report to be generated:
MREPORT CYBER1 RESOURCE_REPORT_1 -
FROM(6AM TODAY EVERY 5 MINUTES ENDING 6AM TOMORROW)
In the above example, generation of the Resource Utilization by System Report
(RR1) is requested. The report is generated at 5-minute intervals.
Example 2 The following MREPORT command selects the modeling report to be generated:
MREPORT OUTDSN RR2 FROM(8:15 JAN1 TO 9:15 JAN2) CPU(3)
In the above example, generation of the Resource Utilization by Job (RR2) is
requested. Only LOCAL resources defined to CPU3 will appear on the report. The
report is generated at 2-minute intervals (default).
499
MREPORT Command, Continued
MODEL CYBER.SAD -
MAXINITS 8
MREPORT RPT1 JR1 FROM('4PM TODAY ENDING 4PM TOMORROW)
ENDMODEL
ENDPRINT RPT1
The ENDMODEL command ends the process
500
MSG Command
Overview The MSG command is used to add or delete routing or descriptor codes to an ESP
message or range of ESP messages. It can also change the message type.
Authority OPER authority is required to issue the MSG command.
Syntax The syntax of the MSG command is:
MSG {(id[,id]...)}
{(id1:id2)}
[ROUTE(codes)]
[DESC(codes)]
[DELROUTE(codes)]
[DELDESC(codes)]
[TYPE(I|W|E|S)]
id Indicates a number in the range 200 to 950. A list of numbers
can be specified, enclosed in parentheses and separated by
blanks or commas.
id1:id2 Indicates two numbers each in the range 200 to 950, separated
by a colon, which specify a range of message Ids. A list of
ranges can be specified, enclosed in parentheses and
separated by blanks or commas.
codes Indicates a number, range of numbers or list of numbers and
16.
ROUTE Indicates one or more routing codes are added when the
message is issued.
DESC Indicates one or more descriptor codes are added when
issuing the messages.
DELROUTE Indicates one or more routing codes are deleted from those
normally used for the message.
DELDESC Indicates one or more descriptor codes are deleted from those
TYPE Indicates the new message type:
I informational message
W warning message
E error message
S severe error message
501
MSG Command, Continued
Usage notes When a message is about to be issued, the routing and descriptor codes are modified
according to the above specification. The routing and descriptor codes for the
message class, as set by the MSGTYPE command, are also set. The order of
Application is:
1. DELROUTE and DELDESC from message type (MSGTYPE command).
2. ROUTE and DESC from message type (MSGTYPE command).
3. DELROUTE and DELDESC from individual message modifier (MSG
command).
4. ROUTE and DESC from individual message modifier (MSG command).
Related
information
For information on adding or deleting routing or descriptor codes to groups of
messages, see the MSGTYPE command.
Example 1 The following are examples of MSG and MSGTYPE commands:
MSGTYPE INFORMATION ROUTE (1:3,10,12)
MSGTYPE WARNING ROUTE (1:3,8,10,12) DESC(1)
MSG (500:510,525) DESC(2)
MSG 530 TYPE(W) DELDESC(1)
In the above example, messages 500 to 550 are informational messages, and
messages 551 to 559 are warning messages.
After these commands are entered:
All informational messages have routing codes 1,2,3,10 and 12 added.
Warning messages have routing codes 1,2,3,8,10 and 12 added along with
descriptor code 1.
Messages 500 to 510 and 525 would also have descriptor code 2 added, although
they remain informational messages.
Message 530 is converted to a warning message, and has the warning message
routing and descriptor codes added. However, the descriptor code of 1 is
deleted for message 530.
502
MSGLIMIT Statement
Overview The MSGLIMIT statement is used to allow you to limit the number of console
messages generated by an Event. MSGLIMIT can be used to suppress excess
messages or to cancel Events that exceed a certain limit.
Type ESP Application statement. General command.
Authority OPER authority is required to issue the MSGLIMIT command.
Syntax The syntax of the MSGLIMIT command is:
MSGLIMIT [n1[,n2]
[LIST][OFF]
n1 When specified on its own, this causes ESP to cancel an
Event once it exceeds this number of messages.
N2 Entering two parameters on MSGLIMIT causes excess
messages to be suppressed while allowing the Event to
continue. Any message beyond the first n1 from the Event is
suppressed. However, if the total number of messages
exceeds n2, the Event is canceled.
LIST Displays MSGLIMIT settings.
OFF Inactivates the message limits.
Usage notes If a Procedure contains a MSGLIMIT statement then its value overrides the default
value set by an operator command or Initialization Parameter. MSGLIMIT applies
to the Event that invokes the ESP Procedure.
Example 1 The following MSGLIMIT command displays the message limit settings:
MSGLIMIT -
In the above example, the current message limit setting are displayed.
Example 2 The following MSGLIMIT command sets the message limit:
MSGLIMIT 100
In the above example, the message limit is set to 100. When an Event exceeds 100
messages, the Event is canceled.
503
MSGLIMIT Statement, Continued
Example 3 The following MSGLIMIT command suppresses messages or cancels an Event:
MSGLIMIT 40,100
In the above example, any message beyond the first 40 from an Event is suppressed.
However, if the total number of messages (including the suppressed ones) exceeds
100, the Event is canceled.
504
MSGTYPE Command
Overview The MSGTYPE command is used to add or delete routing or descriptor codes to
groups of ESP messages based on their message type.
Authority OPER authority is required to issue the MSG command.
Syntax The syntax of the MSGTYPE command is:
MSGTYPE {INFO|I}
{WARNING|W}
{ERROR|E}
{SEVERE|S}
[ROUTE(codes)]
[DESC(codes)]
[DELROUTE(codes)]
[DELDESC(codes)]
INFO Indicates an informational message.
WARNING Indicates a warning message.
ERROR Indicates an error message.
SEVERE Indicates a severe error message.
codes Indicates a number, range of numbers or list of numbers and
16.
ROUTE Indicates one or more routing codes are added when the
message is issued.
DESC Indicates one or more descriptor codes are added when
issuing the messages.
DELROUTE Indicates one or more routing codes are deleted from those
DELDESC Indicates one or more descriptor codes are deleted from those
505
MSGTYPE Command, Continued
Usage notes When a message is to be issued, the message type indicator is used to locate the
message type attributes. Any message type attributes are combined with the
attributes of the message itself to form the final attributes. The order of Application
of attributes when both MSG and MSGTYPE apply to a message is:
1. DELROUTE and DELDESC from message type (MSGTYPE command).
2. ROUTE and DESC from message type (MSGTYPE command).
3. DELROUTE and DELDESC from individual message modifier (MSG
command).
4. ROUTE and DESC from individual message modifier (MSG command).
Related
information
For information on adding or deleting routing or descriptor codes to a message or
range of messages, see the MSG command.
Example 1 The following are examples of MSG and MSGTYPE commands:
MSGTYPE INFORMATION ROUTE (1:3,10,12)
MSGTYPE WARNING ROUTE (1:3,8,10,12) DESC(1)
MSG (500:510,525) DESC(2)
MSG 530 TYPE(W) DELDESC(1)
In the above example, messages 500 to 550 are informational messages, and
messages 551 to 559 are warning messages.
After these commands are entered:
All informational messages have routing codes 1,2,3,10 and 12 added.
Warning messages have routing codes 1,2,3,8,10 and 12 added along with
descriptor code 1.
Messages 500 to 510 and 525 would also have descriptor code 2 added, although
they remain informational messages.
Message 530 is converted to a warning message, and has the warning message
routing and descriptor codes added. However, the descriptor code of 1 is
deleted for message 530.
Example 2 The following MSGTYPE command adds routing codes:
MSGTYPE I ROUTE(1,2,5)
MSGTYPE I ROUTE(6) DESC(2)
In the above example, informational messages will have routing codes 1,2,5 and 6
and descriptor code 2. If you want to reset any prior setting, specify 0 as the first
routing or descriptor code.
506
MSGTYPE Command, Continued
Example 3 The following resets routing and descriptor codes:
MSGTYPE I ROUTE(0,6) DESC(0,2)
In the above example, previous routing and descriptor code settings are reset before
adding the new values.
507
NEXT Command
Overview The NEXT command allows you to display the next scheduled executions of an
Event. The NEXT command lets you specify the number of execution times you
want to test, up to a maximum of 99. As long as your Event contains at least one
SCHEDULE or EXPECT command, ESP computes the execution times and dates
for the number of executions you specify.
Syntax The syntax of the NEXT command is:
NEXT [count]
eventid
count Indicates a number from 1 to 99, specifying the number of
execution times you want to be displayed. The default is 1.
eventid Indicates the name of an Event.
Usage notes The NEXT command simulates the schedule commands in an Event to compute the
next n execution times.
The use of the HOLD, RELEASE, SUSPEND and RESUME commands affects the
display.
If an Event is suspended at the time of display, with no scheduled resume, ESP
issues a message and no scheduled executions are displayed.
Related
information
For information on testing schedule criteria before using in an Event, see the TEST
command.
Example 1 The following is an example of the output produced by the NEXT command:
NEXT 5 CYBER.PAYROLL
SCHED AT 21.00.00 ON MONDAY FEBRUARY 2ND, 1999
SCHED AT 21.00.00 ON TUESDAY FEBRUARY 3RD, 1999
SCHED AT 21.00.00 ON WEDNESDAY FEBRUARY 4TH, 1999
SCHED AT 21.00.00 ON THURSDAY FEBRUARY 5TH, 1999
SCHED AT 21.00.00 ON FRIDAY FEBRUARY 6TH, 1999
In the above example, the next 5 executions of CYBER.PAYROLL are displayed.
508
NEXT Command, Continued
ESP2494W NEXT PROCESSING ENDED AFTER 200 SUSPENDED SCHEDULES
SCHED AT 17.00.00 ON SATURDAY FEBRUARY 21ST, 1998
SCHED AT 17.00.00 ON SUNDAY FEBRUARY 22ND, 1998
In the above example, the Event is suspended after February 22
nd
, 1998, with no
scheduled resume.
SCHED AT 17.00.00 ON SATURDAY FEBRUARY 21ST, 1998 HOLD(1)
SCHED AT 17.00.00 ON SUNDAY FEBRUARY 22ND, 1998
In the above example, the Event is held at the time of execution and release prior to
the next execution.
509
NOCHECKEXC Statement
Overview The NOCHECKEXC statement is used to indicate that ESP should not check the
last non-blank character of every card image written to the internal reader. The
NOCHECKEXC statement cannot be used in an ESP Procedure.
Syntax The syntax of the NOCHECKEXC statement is:
NOCHECKEXC
Usage notes The NOCHECKEXC statement is used in conjunction with the CHECKEXC
statement which checks the last non-blank character of card images written to the
internal reader. If the last character is a (not sign), the card image is deleted.
NOCHECKEXC turns off the CHECKEXC feature. The default is
NOCHECKEXC.
Related
Statements
For information on turning on the checking of the last non-blank character of every
card image written to the internal reader, see the CHECKEXC statement.
For information on selectively including JCL, see the %INCLUDE statement.
For information on selectively excluding JCL, see the %EXCLUDE statement.
Example 1 The following NOCHECKEXC statement indicates that ESP should not check the
last non-blank character of every card image written to the internal reader:
NOCHECKEXC
In the above example, coding NOCHECKEXC cancels, or turns off the
CHECKEXC feature.
510
NODE Command
Overview The NODE parameter is used, together with the CPU parameter, to define the
resource topology of your network. The NODE parameter defines each system
node.
Syntax The syntax of the NODE parameter is:
NODE name [ADD|DEL|LIST|SET]
[ROUTEJCL('/* XEQ nnn')]
[ACTIVE|INACTIVE]
Operand Description
name Indicates the name to identify this NODE. This may
correspond to an existing JES node name or SMF id. The
asterisk (*) and hyphen (-) may be used as wild card
characters for masking name with all parameters except
ADD.
ADD Indicates this is a new definition.
DEL Deletes one or more existing definitions.
LIST Displays list of one or more existing definitions. This is the
default.
SET Modifies attributes of existing definitions.
ROUTEJCL Indicates a JCL image that, when inserted into a jobs JCL,
causes the job to be routed to the appropriate CPU or node.
ACTIVE Indicates a node be considered active. This is the default.
INACTIVE Indicates a node be considered inactive. ESP will not attempt
to schedule a job to that node or CPU while it is inactive.
Usage notes The CPU command is generally used at the Initialization Parameter level, and is
used in conjunction with the NODE parameter to define the resource topology of
your network.
For information on defining the resource topology of your network see the CPU,
You also need to define CPU after defining NODE.
It is recommended that you use the CPU and NODE names that JES knows.
511
NODE Command, Continued
Related
information
For information on defining the resource topology of your network, see the CPU,
For information on Resources, see the ESP Workload Manager Users Guide.
Example 1 The following NODE command displays all defined NODEs:
NODE - LIST
In the above example, all nodes defined as part of the resource topology are
displayed.
Example 2 The following NODE and CPU commands define a node and CPU:
NODE TORONTO ADD
CPU T1 ADD NODE(TORONTO) CURRENT
In the above example, a single node called TORONTO is defined, and a single CPU
called T1 is defined as a member of the TORONTO node.
512
NORUN Statement
Overview The NORUN statement is used to handle exceptions to a jobs regular schedule
criteria. The NORUN statement tells ESP when not to select a job for submission.
Syntax The syntax of the NORUN statement is:
NORUN criteria
Usage notes The NORUN statement is equivalent to: IF TODAY(schedule criteria) THEN
DESELECT job.
Multiple NORUN statements are allowed.
Use the RUN statement to cause a job to be scheduled. When both RUN and
NORUN statements are encountered, ESP uses the last one that applies. Therefore,
you should normally specify RUN statements before NORUN statements.
If a NORUN statement is used without a RUN statement for a job, the job is
scheduled each time the Event executes except when the NORUN schedule criteria
is satisfied.
The NORUN statement can not be used in conjunction with the following
scheduling terms: EVERY, UNTIL, ENDING, TOMORROW, YESTERDAY and
STARTING.
The NORUN statement must be used within the scope of a JOB statement.
Related
information
For information on specifying schedule criteria, see the ESP Workload Manager
Users Guide.
For information on selecting jobs for submission, see the RUN, SELECT,
POSTREQ, PREREQ and COREQ statements.
513
NORUN Statement, Continued
Example 1 The following NORUN identifies an exception to a jobs schedule criteria:
APPL PAYROLL
JOB PAYJOB1
RUN WORKDAYS
NORUN FIRST WORKDAY OF MONTH
ENDJOB
In the above example, PAYJOB1 is scheduled for submission on workdays, except
on the first workday of the month.
APPL PAYROLL
JOB PAYJOB2
RUN DAILY
NORUN FIRST WORKDAY OF MONTH
NORUN LAST WORKDAY OF MONTH
ENDJOB
In the above PAYJOB2 is scheduled for submission every day, except on the first
and last workday of each month.
APPL PAYROLL
JOB PAYJOB3
NORUN WEDNESDAY
ENDJOB
In the above PAYJOB3 is scheduled for submission every time the Event invoking
this Application executes, except on Wednesdays.
514
NORUN Statement, Continued
APPL PAYROLL
JOB PAYJOB4
RUN WORKDAYS
IF TODAY(FIRST FRI OF MONTH) AND -
TODAY(FIRST WORKDAY OF MONTH) THEN NORUN TODAY
ENDJOB
In the above example, PAYJOB4 is scheduled for submission on workdays. If today
is the first Friday of the month and the first workday of the month, the job is not
selected for submission.
APPL PAYROLL
JOB PAYJOB5
RUN FRIDAY
NORUN FIRST FRIDAY OF MONTH
NORUN LAST FRIDAY OF MONTH
ENDJOB
In the above example, PAYJOB5 is scheduled for submission on Fridays. If today
is the first Friday of the month, or the last Friday of the month, the job is not
selected for submission.
Other examples Here are more examples of using the NORUN statement.
Indicates that a job is not selected for submission on holidays:
NORUN HOLIDAY
Indicates that a job is not selected for submission on the 3
rd
, 13
th
and the 23
rd
day of
each month:
NORUN 3RD 13TH 23RD DAY OF MONTH
Indicates that a job is not selected for submission on the 1
st
day of the fiscal year:
NORUN 1ST DAY OF FISCAL YEAR
Indicates that a job is not selected for submission, i.e. the job is turned off:
NORUN ANY
515
NOSCHED Command
Overview The NOSCHED command is used to specify when a scheduled Event should not
execute.
Syntax The syntax of the NOSCHED command is:
NOSCHED criteria
Usage notes In addition to a SCHEDULE command, use any number of NOSCHED commands
to specify when an Event should not execute.
Use the same time on your NOSCHED statement as on your SCHEDULE statement.
If no time is specified on the NOSCHED statement, the default is 00:00. For
example, if you say SCHEDULE 5PM, you should use NOSCHED 5PM.
The NEXT command which lists the next execution times of an Event, reflects
NOSCHED commands.
Related
information
Users Guide.
For information on specifying when an Event should execute, see the SCHEDULE
command.
For information on specifying when a job should not be scheduled, see the NORUN
statement.
SCHEDULE 5PM DAILY
NOSCHED 5PM LAST WORKDAY OF MONTH
INVOKE CYBER.JCL.CNTL(PAYROLL)
ENDDEF
In the above example, CYBER.PAYROLL is scheduled to execute every day at
5pm, except on the last workday of the month.
516
NOSCHED Command, Continued
EVENT ID(CYBER.PAYJOB)
SCHEDULE 5PM DAILY
NOSCHED 5PM FEBRUARY 14, 1998 ONCE
ENDDEF
In the above example, CYBER.PAYROLL is scheduled to execute every day at
5pm, except on February 14
th
, 1998.
517
NOTIFY Statement
Overview The NOTIFY statement is used to notify users or consoles, or trigger an Event when
one or more of the following conditions are met: SUBMIT, JOBSTART, RESUB,
OVERDUE, ABEND, FAILURE and JOBEND. The NOTIFY statement is
available only for jobs belonging to Applications.
Syntax The syntax of the NOTIFY statement is:
NOTIFY [SUBMIT]
[JOBSTART]
[RESUB]
[OVERDUE]
[ABEND]
[FAILURE]
[JOBEND]
[USERS(userid[,userid]...)]
[SYSTEM(name)]
[ROUTE(rcode[,rcode]...)]
[DESC(dcode[,dcode]...)]
[ALERT(xxxx)]
SUBMIT Indicates notification should take place at job submit time.
JOBSTART Indicates notification should take place at job start time.
OVERDUE Indicates notification should take place when a job becomes
overdue from any processing node.
ABEND Indicates notification should take place when a job ABENDs. This
excludes condition code failures.
FAILURE Indicates notification should take place when a job fails. This
includes condition codes failures caused by either the CCCHK or
CCFAIL statements.
JOBEND Indicates notification should take place when a job ends. This
includes any job end (successful or unsuccessful). This Parameter
can also be specified as END.
RESUB Indicates notification should take place when a job resubmitted
through ESP ends.
userid Indicates up to three TSO user IDs to receive notification.
name Indicates the name of a Sysplex member. This is not the ESP
system name it is the name by which MVS knows the member of
the Sysplex. Can be used to route a NOTIFY command in a
Sysplex environment to wherever the user is logged on. Use an
asterisk to indicate the message goes wherever ESP is running.
rcode Indicates route code value between 1 and 128 to receive
notification. Separate each route code with a comma.
dcode Indicates descriptor code value between 1 and 16 to receive
notification. Separate each descriptor code with a comma.
518
NOTIFY Statement, Continued
Syntax (continued)
ALERT(xxxx) Indicates an Event associated with a logical alert identifier should
be triggered. This logical identifier must have been previously
specified using an ALERTDEF command. Alternatively, an
asterisk (*) can be used to trigger the same Event which invoked
this ESP Procedure.
Usage notes The Alert feature enables ESP to trigger an Event for all jobs, or only specific jobs,
in an ESP Application.
To use the Alert feature, you need to take these three steps:
1. Use the NOTIFY statement in an ESP Application to identify when to trigger the
Alert.
2. Define the Alert with the ALERTDEF command.
3. Define the Event triggered by the Alert.
Alerts can be defined dynamically, i.e. via Page mode, but are not retained across
recycles of ESP. To ensure that alert definitions are retained across recycles of ESP,
insert the appropriate ALERTDEF commands in the ESP Workload Manager
Initialization Parameters.
Up to two global NOTIFY statements can be used. The NOTIFY statement can be
used within the scope of a job statement in which case all global NOTIFY
statements are overridden. Up to two NOTIFY statements can be used within the
scope of a job statement.
Related
information
For information on triggering Events automatically when workload reaches a
particular stage in processing, see the ESP Workload Manager Advanced Users
Guide.
For information on defining and displaying alert definitions, see the ALERTDEF
command.
519
Example 1 The following NOTIFY statement notifies users when each job within the
Application starts:
APPL PAYROLL
NOTIFY JOBSTART USERS(CYB01,CYB02)
JOB PAYJOB1
REL PAYJOB2
JOB PAYJOB2
REL PAYJOB3
JOB PAYJOB3
ENDJOB
In the above example, when each job within the PAYROLL Application starts, users
CYB01 and CYB02 receive notification. The notification is a pre-formatted
message that looks like this:
JOB PAYJOB1(J09368) STARTED AT 02.15.01 ON 01 FEB 98, APPL
PAYROLL
Example 2 The following NOTIFY statement notifies a user if a specific job abends:
APPL PAYROLL
JOB PAYJOB4
NOTIFY ABEND USERS(CYB01) ROUTE(2) DESC(2)
RUN WORKDAYS
ENDJOB
In the above example, if PAYJOB4 abends, notification is sent to user CYB01 and
all consoles with route code 2. Descriptor code 2 is used to highlight the message.
Example 3 The following NOTIFY statements notifies various users if specific jobs abend:
APPL PAYROLL
NOTIFY ABEND USERS(CYB01)
JOB PAYJOB5
NOTIFY ABEND USERS(CYB02)
RUN WORKDAYS
REL PAYJOB6
JOB PAYJOB6
RUN WORKDAYS
ENDJOB
In the above example, notification is sent to user CYB01 for any job in the
PAYROLL Application that abends, except for PAYJOB5 where notification is sent
to user CYB02.
520
Example 4 The following NOTIFY statement triggers an Event associated with an alert
identifier:
APPL PAYROLL
NOTIFY ABEND ALERT(INFO)
JOB PAYJOB7
REL PAYJOB8
JOB PAYJOB8
ENDJOB
In the above example, if any job within the PAYROLL Application abends, an alert
Event associated with the INFO identifier is triggered.
Note: The INFO identifier is defined using the ALERTDEF command.
Example 5 The following NOTIFY statement triggers an Event associated with an alert
identifier:
APPL PAYROLL
NOTIFY OVERDUE ALERT(LATE)
JOB PAYJOB9
RUN WORKDAYS
REL PAYJOB10
JOB PAYJOB10
RUN WORKDAYS
ENDJOB
In the above example, if any job within the PAYROLL Application becomes
overdue, an alert Event associated with the LATE identifier is triggered.
Example 6 The following NOTIFY statement notifies a user when jobs within an Application
start and end:
APPL PAYROLL
NOTIFY JOBSTART JOBEND USERS(CYB01)
JOB PAYJOB11
RUN WORKDAYS
REL PAYJOB12
JOB PAYJOB12
RUN WORKDAYS
ENDJOB
In the above example, when each job within the PAYROLL Application starts and
ends, user CYB01 receives notification.
521
Example 7 The following NOTIFY statement retriggers the same Event and ESP Procedure.
/*Check invocation
IF MNJOB NE THEN DO
IF MNPOINT=OVERDUE AND MNJOB=WAIT4 AND MNQUAL=TAPE
THEN +
ESP AJ ALL COMPLETE APPL(%MNAPPL..%MNAPPLGEN)
EXIT
ENDDO
/*Regular processing
APPL TAPEJOBS
NOTIFY OVERDUE ALERT(*)
JOB WAIT4.TAPE TASK
DUEOUT EXEC 7PM
RUN DAILY
RELEASE NEXTJOB
ENDJOB
JOB NEXTJOB
RUN DAILY
ENDJOB
In the above example, this Application should be marked complete if a task called
WAIT4.TAPE has not been marked complete by 7 pm. The ESP Procedure tests the
MNJOB (monitor jobname) variable to see if ESP is invoking the Procedure due to
the triggering of an Event or due to the ALERT keyword:
If MNJOB is a null string, ESP generates the Application
Otherwise, the ESP Procedure is being invoked by the Alert. ESP verifies the
monitor point and the name of the overdue job, and completes the Application.
522
ON Command
Overview The ON command is used in conjunction with the SCHEDULE command to
advance, delay or ignore Event processing if the Event falls on a holiday, weekday,
weekend or particular day of the week.
Syntax The syntax of the ON command is:
ON type
{ADVANCE}
{DELAY}
{IGNORE}
[n DAYS]
[n WEEKDAYS]
type Indicates a type of day. This can be any of the following:
HOLIDAY - Installation defined holidays. The
LISTHOL command is used to display the holidays
currently defined by the installation.
WEEKDAY - Any day of the week except Saturday and
Sunday.
WEEKEND - A Saturday or Sunday.
dayname - The name of a single day of the week, e.g.
Saturday, Monday, etc.
ADVANCE Indicates the Event is to be advanced (i.e. run earlier) by a
specified number of days or weekdays.
DELAY Indicates the Event is to be delayed (i.e. run later) by a
specified number of days or weekdays.
IGNORE Specifies if the Event falls on one of the specified days, it is
to be bypassed.
n Indicates the number of days or weekdays the Event is to be
advanced or delayed.
DAYS Indicates n equals the number of days for the schedule to be
advanced or delayed. This includes Saturdays and Sundays.
WEEKDAYS Indicates n equals the number of weekdays for the schedule to
be advanced or delayed. This excludes Saturdays and
Sundays.
523
ON Command, Continued
Usage notes You must use the keyword HOLIDAY, which includes all holidays in the calendars
associated with the Event. You cannot use a specific holiday name, such as
CHRISTMAS.
Your scheduling criteria for Event execution may create conflicts. For example, if
you want the Event to execute on the second day of every month, but it cannot run
on a weekend, tell ESP to either:
Advance the Event (run it sooner than usual) by any number of days or
weekdays
Delay the event (run it later than usual) by any number of days or weekdays
Ignore the Event (do not run it at all).
If the processing of an ON command results in an Event time earlier than the
previous execution of the Event, that schedule time is ignored. An ON statement
affects only the scheduling of an Event through a SCHEDULE statement.
SUSPEND, RESUME, HOLD and RELEASE are not subject to ON condition
testing.
Use the NEXT command to display the next execution times of an Event. Changes
due to an ON statement are reflected.
Related
information
For information on Events, see Processing ESP Events in the ESP Workload
For information on scheduling criteria see, Schedule Criteria in the ESP Workload
For information on specifying when a scheduled Event should not execute, see the
NOSCHED command.
Example 1 The following is an example of a scheduled Event definition that delays the Event
execution on a specific day:
SCHEDULE MONDAY AT 6AM EVERY 14 DAYS
ON HOLIDAY DELAY 1 DAY
ENDDEF
In the above example, CYBER.PAYROLL is scheduled at 6 am every 14 days.
When a particular Monday falls on a holiday, the Event is delayed by one day. If the
next day is also a holiday, the Event is delayed again until it falls on a day that is not
a holiday. However, to calculate the next Event time, 14 days are added to the
original Monday, even though it was a holiday.
524
ON Command, Continued
Example 2 The following is an example of a scheduled Event definition that advances the Event
execution on holidays:
SCHEDULE 4PM 15TH DAY OF MONTH
ON HOLIDAY ADVANCE 1 DAY
ENDDEF
In the above example, CYBER.PAYROLL is schedule at 4 pm on the 15
th
day of the
month. On holidays, the Event is advanced 1 day.
Example 3 The following is an example of a scheduled Event definition that ignores the Event
SCHEDULE FIRST DAY OF THE MONTH
ON HOLIDAY IGNORE
ENDDEF
In the above example, CYBER.PAYROLL is scheduled on the first day of the
month. On holidays the Event is bypassed.
SCHEDULE 8AM FIRST DAY OF MONTH
ON HOLIDAY DELAY 7 DAYS
ENDDEF
In the above example, CYBER.PAYROLL is scheduled at 8 am on the first day of
the month. On holidays the Event delayed 7 days.
SCHEDULE 4PM 15TH DAY OF MONTH
ON HOLIDAY DELAY 1 WEEKDAY
ENDDEF
In the above example, CYBER.PAYROLL is scheduled at 4 pm on the 15
th
day of
the month. On holidays the Event is delayed 1 weekday.
525
OPTIONS Statement
Overview The OPTIONS statement is used to override the default processing options for jobs
belonging to Applications.
Syntax The syntax of the OPTIONS statement is:
OPTIONS [INHERIT|NOINHERIT]
[GENNET|NOGENNET]
[MANUALSUBMIT|NOMANUALSUBMIT|
[TRACKMANUAL|NOTRACKMANUAL]
[AUTOVARS|NOAUTOVARS]
[RESTARTSTEP|NORESTARTSTEP]
INHERIT Indicates job relationships are inherited. This is the
default.
NOINHERIT Indicates job relationships are not inherited.
GENNET Indicates DJC/JES3 NET control cards are generated
for jobs in a DJCNET. This is not applicable to ESP
Applications. This is the default.
NOGENNET Indicates DJC/JES3 NET control cards are not
generated for jobs in a network. This can be used if
the jobs you are submitting already have NET control
cards.
MANUALSUBMIT Indicates jobs are manually submitted.
NOMANUALSUBMIT Indicates jobs will not be manually submitted. This is
the default.
TRACKMANUAL Indicates jobs are tracked manually.
NOTRACKMANUAL Indicates jobs are not tracked manually.
AUTOVARS Indicates ESP allows the use of the automatic variable
insertion feature. This is the default.
NOAUTOVARS Indicates ESP does not allow the use of the automatic
variable insertion feature.
RESTARTSTEP Indicates a restart step is added to each job in an
Application as identified by the ERMSTEP
initialization parameter.
NORESTARTSTEP Indicates a restart step is not added to each job in an
526
OPTIONS Statement, Continued
Usage notes The OPTIONS statement is normally used before your job definitions. OPTIONS
RESTARTSTEP/NORESTARTSTEP is available at the job level as well as the
SubApplication level for jobs in an Application.
You can use different keywords on a JOB statement to override the
MANUALSUBMIT/NOMANUALSUBMIT and the INHERIT/NOINHERIT
options.
It is not necessary to specify NOGENNET for jobs defined in an Application.
Related
information
For information on overriding inherited relationships, see the ESP Workload
For information on using the automatic variable insertion feature, see the ESP
For information on adding a restart step, see the ESP Workload Manager Advanced
Users Guide.
For information on rerunning/restarting jobs belonging to Applications, see the ESP
Encore Users Guide.
Example 1 The following OPTIONS statement overrides processing options for an Application:
APPL PAYROLL
OPTIONS RESTARTSTEP
JOB PAYJOB1
RUN DAILY
REL PAYJOB2
JOB PAYJOB2
RUN DAILY
REL PAYJOB3
JOB PAYJOB3
RUN DAILY
OPTIONS NORESTARTSTEP
ENDJOB
In the above example, the OPTIONS RESTARTSTEP statement is used to add a
restart step to each job in the PAYROLL Application, except for PAYJOB3.
527
APPL PAYROLL
OPTIONS NOINHERIT
JOB PAYJOB4
RUN DAILY
REL PAYJOB5
JOB PAYJOB5
RUN FRIDAY
REL PAYJOB6
JOB PAYJOB6
RUN DAILY
ENDJOB
In the above example, the OPTIONS NOINHERIT statement is used to indicate that
successors to a job are not to inherit job relationships and that relationships among a
job and its successors exist only if there is a definition starting the relationship. If it
is not Friday, no relationship exists between PAYJOB4 and PAYJOB6.
Example 3 The following OPTIONS statement identifies processing options for a
subApplication:
APPL PAYROLL
JOB RECJOB1
SUBAPPL RECEIVE
RUN DAILY
REL RECJOB2
JOB RECJOB2
SUBAPPL RECEIVE
RUN DAILY
ENDJOB
OPTIONS RESTARTSTEP
JOB PAYJOB1
SUBAPPL PAYABLE
REL PAYJOB2
RUN DAILY
JOB PAYJOB2
SUBAPPL PAYABLE
RUN DAILY
ENDJOB
In the above example, the OPTIONS RESTARTSTEP statement is used at the
subApplication level to add a restart step to each job in the PAYABLE
subApplication.
528
APPL PAYROLL
OPTIONS MANUALSUBMIT
JOB PAYJOB6
RUN DAILY
REL PAYJOB7
JOB PAYJOB7
RUN DAILY
REL PAYJOB8
JOB PAYJOB8
RUN DAILY
ENDJOB
In the above example, the OPTIONS MANUALSUBMIT statement is used to
identify each job in the PAYROLL Application as manually submitted. This is
useful when another product is submitting work and you want to monitor this work
through the CSF.
529
PANSUB Command
Overview The PANSUB command is used to submit JCL from a Panvalet data set to the
internal reader.
Syntax The syntax of the PANSUB command is:
PANSUB dsname[(member)]
[MEMBER(member)]
dsname Indicates a valid PANVALET data set name. You do not
have to specify PAN- as a data set identifier because using
the PANSUB command implies the use of a PANVALET
data set.
member Indicates a member name, which can consists of up to eight
characters if specified as part of the data set name or up to ten
characters as a parameter of the MEMBER keyword.
Usage notes Several PANSUB commands may be specified in a single Event. The input data are
effectively concatenated together, so that data from several data sets can be joined to
form one or more jobs.
In the same Event you can also use the SUBMIT command, and submit JCL from
ROSCOE and LIBRARIAN data sets.
To submit JCL from a PANVALET library as part of an Application, use PAN- as a
prefix for your data set name on the JCLLIB statement.
Related
information
Users Guide.
PANVALET data set:
EVENT ID(CYBER.PANJOB1)
PANSUB PANDS.DATA(PAYJOB1)
ENDDEF
In the above example, PAYJOB1 is submitted from PANVALET data set
PANDS.DATA.
530
PANSUB Command, Continued
PANVALET data set:
EVENT ID(CYBER.PANJOB2)
SCHEDULE 7PM LAST WORKDAY OF MONTH
PANSUB CYB.JCL MEMBER(LONGJOB999)
ENDDEF
In the above example, LONGJOB999 is submitted from PANVALET data set
CYB.JCL. Using the MEMBER keyword allows names up to 10 characters.
531
PASSWORD Command
Overview The PASSWORD command is used to alter the ESP password associated with your
user ID. This command only applies if you do not have a host security product such
as RACF, ACF2 or Top Secret.
Syntax The syntax of the PASSWORD command is:
PASSWORD oldpswd
newpswd
oldpswd Indicates your current password.
newpswd Indicates the new password you want to use.
Usage notes If you are not using a security product and would like to allow the user access to
ESP through a batch job, you can assign a password to the user.
Related
information
For information on ESPs internal security, see the ESP Workload Manager
Example 1 The following PASSWORD command alters an ESP password:
PASSWORD APPLES ORANGES
In the above example, the password associated with your user ID is changed from
APPLES to ORANGES.
532
PNODES Statement
Overview The PNODES statement is used to specify the name(s) of any user-defined
Processing nodes through which the job must pass before it can be marked as
complete.
Note: The Application Manager submits successor jobs to those identified with the
PNODES statement when the predecessors successfully complete.
Syntax The syntax of the PNODES statement is:
PNODES {pnode}
{(pnode[,pnode])}
pnode Indicates a P-Node name in up to eight characters. Enclose
multiple P-Node names in parentheses, separated by a blank
or comma.
Usage notes This element is used to define any additional user-defined processing nodes for a
job, overriding the P-Nodes specified in the jobs tracking model. The P-Nodes
represent post-execution phases, they cannot be used for pre-processing.
A job does not need to complete any manual phases for a successor job to run. If
you need to set up job dependencies with a manual phase of a job, consider using
tasks in an ESP Application.
Once you define the P-Node name, authorized users can simply type the POST
command to post a job as complete at a specific P-Node.
CSF PNODES fields, such as INPUT, EXEC, COMPLETE and FAIL apply only to
jobs in an ESP Application and do not include postexecution phases.
Once a P-Node is defined, all users have read access to it.
533
PNODES Statement, Continued
Related
information
DELPN commands.
command.
For information on specifying the name of a P-Node when defining a tracking
model, see the DEFTM command.
For information on using a TASK workload object to identify manual processing
points in an Application, see the ESP Workload Manager Users Guide.
Example 1 The following PNODES statement specifies a user-defined processing node:
APPL PAYROLL
JOB PAYJOB1
RUN WORKDAYS
REL PAYJOB2
PNODES BALANCE
JOB PAYJOB2
RUN WORKDAYS
ENDJOB
In the above example, PAYJOB1 must be posted out of the BALANCE P-Node
before the Tracking Manager considers it complete. PAYJOB2 is released when
PAYJOB1 completes; it does not wait for PAYJOB1 to be posted, from the
BALANCE P-Node.
Similar results could be accomplished using a TASK workload object to represent a
manual process (the balancing of a report) and is coded as follows:
APPL PAYROLL
JOB PAYJOB1
RUN WORKDAYS
REL BALANCE.RPT
JOB BALANCE.RPT TASK
RUN WORKDAYS
REL PAYJOB2
JOB PAYJOB2
RUN WORKDAYS
ENDJOB
In the above example, when the report produced by PAYJOB1 is balanced, a user
completes BALANCE.RPT using the APPLJOB (AJ) command, or via the CSF.
PAYJOB2 is then released.
534
PNODES Statement, Continued
Example 2 The following PNODES statement specifies two user-defined processing nodes:
APPL PAYROLL
JOB PAYJOB3
RUN WORKDAYS
REL PAYJOB4
PNODES (BURSTER,DISTRIB)
JOB PAYJOB4
RUN WORKDAYS
ENDJOB
In the above example, PAYJOB3 must be posted out of the BURSTER and
DISTRIB P-Nodes before the Tracking Manager considers it complete. PAYJOB4
is released when PAYJOB3 completes; it does not wait for PAYJOB3 to be posted
from these manual P-Nodes..
535
POST Command
Overview The POST command is used to post a job complete from a manually defined P-Node
as defined in an Application using the PNODES statement.
Authority OPER authority is required to issue the POST command.
Syntax The syntax of the POST command is:
POST {job(jobnumber)}
[PNODE(pnodename)]
[FORCE|PURGE]
job|jobnumber Indicates the name or number of the job to be posted. If a job
number is specified, it should consist of numeric digits only.
To uniquely identify a job, both a job name and job number
can be specified. In this format, the job number is enclosed in
parentheses immediately following the job name. There
should be no intervening blanks or commas.
pnodename Indicates the name of the P-Node on which the job completed
processing. The job must currently be queued to that P-Node
unless FORCE or PURGE is also specified. If this parameter
is omitted, the default P-Node for the console or user is used.
The default P-Node is specified by the DFPNODE command.
FORCE Indicates the job is posted as complete at a P-Node, even
though it is not currently queued to that P-Node.
PURGE Indicates the job is removed from any P-Node queue and is
marked as complete.
Usage notes A job does not need to complete any manual phases for a successor job to run. If
you need to set up job dependencies with a manual phase of a job, consider using
tasks in an ESP Application.
Once you have defined the P-Node name, authorized users can simply type the
POST command to post a job as complete at a specific P-Node.
Related
information
For information on displaying job on PNODE queues, see the DN command.
536
POST Command, Continued
Example 1 The following PNODES statement specifies a user defined processing node:
APPL PAYROLL
JOB PAYJOB1
RUN WORKDAYS
PNODES BALANCE
ENDJOB
In the above example, PAYJOB1 must be posted out of the BALANCE P-Node
before it is considered complete. To display the BALANCE P-Node issue the
following command:
DN QUEUE(BALANCE)
BALANCE: PAYJOB1 09812
Issue the POST command, using one of the following methods, to complete
PAYJOB1 from the BALANCE P-Node:
POST PAYJOB1 PNODE(BALANCE)
or
POST 9812 PNODE(BALANCE)
or
POST PAYJOB1(9812) PNODE(BALANCE)
or
DFPNODE BALANCE - sets the default P-Node
POST PAYJOB1
537
POSTREQ Statement
Overview The POSTREQ statement is used to specify the names of any other jobs that must
run after this job executes. ESP automatically selects the jobs for submission
whenever this job is selected for processing.
Syntax The syntax of the POSTREQ statement is:
POSTREQ {jobname}
jobname Indicates a jobname in up to eight characters and may include
a qualifier in up to eight characters. Enclose multiple job
defined as POSTREQs for the job.
defined as POSTREQs.
A Indicates the specified job(s) are released on abnormal
termination, including condition code failures, of a
predecessor.
U Indicates the specified job(s) are released on any termination
of a predecessor.
N Indicates the specified job(s) are released on normal
termination of a predecessor. This is the default.
Usage notes POSTREQ can be used with any job to name other jobs that should be selected after
this job completes (default is successful completion). POSTREQ dynamically
creates dependencies between this job and the jobs you specify as postrequisites.
This POSTREQ statement automatically forces selection of the postrequisite jobs--
no SELECT statement or RUN statement needs to be specified for them.
Completion of a job decrements the hold count on each postrequisite job.
A POSTREQ statement in an ESP Procedure overrides any previous POSTREQ
statement for the same job unless the ADD keyword is specified.
The termination parameters (A,U,N) are available only for jobs in an Application.
For jobs in a DJC jobnet, use the ABNORMAL and NORMAL parameters as
documented in the DJC Users Guide.
Job definition for POSTREQ jobs are required only if you need to specify
requirements for these jobs.
538
POSTREQ Statement, Continued
Related
information
PREREQ, and POSTREQ statements.
Example 1 The following POSTREQ statement identifies job relationships within an
Application:
APPL PAYROLL
JOB PAYJOB1
RUN WORKDAYS
POSTREQ PAYJOB2
ENDJOB
In the above example, PAYJOB2 is automatically selected for submission and runs
after PAYJOB1 successfully completes.
Application:
APPL PAYROLL
JOB PAYJOB3
RUN WORKDAYS
POSTREQ (PAYJOB4,PAYJOB5,PAYJOB6)
JOB PAYJOB4
JOB PAYJOB5
JOB PAYJOB6
ENDJOB
In the above example, PAYJOB4, PAYJOB5 and PAYJOB6 are automatically
selected for submission and runs after PAYJOB3 successfully completes.
Application:
APPL PAYROLL
JOB PAYJOB7
RUN DAILY
POSTREQ (PAYJOB8(A))
JOB PAYJOB8
ENDJOB
after the abnormal termination of PAYJOB7. If PAYJOB7 completes successfully,
PAYJOB8 is not eligible for submission.
539
Example 4 The following POSTREQ and CLANG statements identify job relationships within
an Application:
APPL PAYROLL
JOB PAYJOB9
RUN WORKDAYS
POSTREQ (PAYJOB10,PAYJOB11)
IF TODAY(FRIDAY) THEN POSTREQ ADD(PAYJOB12,PAYJOB13)
JOB PAYJOB10
JOB PAYJOB11
JOB PAYJOB12
JOB PAYJOB13
ENDJOB
PAYJOB10 and PAYJOB11 are automatically selected for submission and run
after PAYJOB9 successfully completes
PAYJOB12 and PAYJOB13 are automatically selected for submission on
Fridays and run after PAYJOB9 successfully completes
Example 5 The following POSTREQ ADD statements are used to indicate job relationships:
APPL PAYROLL
JOB PAYJOB14
RUN DAILY
POSTREQ ADD(PAYJOB15)
POSTREQ ADD(PAYJOB16)
ENDJOB
In the above example, PAYJOB15 and PAYJOB16 are automatically selected for
submission and run after PAYJOB14 successfully completes.
Example 6 The following PREREQ and POSTREQ statements simplify job relationships:
APPL PAYROLL
JOB LINKIT LINK PROCESS
RUN DAILY
PREREQ (PAYJOB17,PAYJOB18,PAYJOB19)
ENDJOB
In the above example, a link represents the completion of the first three jobs, and
releases the second group of three jobs.
540
Example 7 The following POSTREQ statement identifies job relationships for qualified jobs
APPL PAYROLL
JOB PAYJOB23.RUN1
RUN DAILY
POSTREQ PAYJOB23.RUN2
ENDJOB
In the above example, PAYJOB23.RUN2 is automatically selected for submission
and runs after PAYJOB23.RUN1 successfully completes.
541
PREALLOC Command
Overview The PREALLOC command is used to pre-allocate a data set.
Authority OPER authority is required to issue the PREALLOC command.
Syntax The syntax of the PREALLOC command is:
PREALLOC [dataset]
[ALLOC|UNALLOC]
dsname Indicates the data set name.
ALLOC Indicates the data set be allocated.
UNALLOC Indicates a previously allocated data set be restored to non-
preallocated status.
Usage notes ESP bypasses dynamic allocation for each pre-allocated data set when access to the
data set is needed.
Use one PREALLOC statement for each data set you wish to pre-allocate.
This statement can be issued as a command with no operands to display the current
pre-allocation list of data sets, and with the UNALLOC operand to restore a
previously allocated data set to non-preallocated status.
Related
information
Installation Guide.
Example 1 The following PREALLOC command displays the current pre-allocation list:
OPER PREALLOC
In the above example, the current pre-allocation list is displayed.
Example 2 The following PREALLOC command pre-allocates a data set:
OPER PREALLOC CYBER.JCL.CNTL ALLOC
In the above example, CYBER.JCL.CNTL is pre-allocated for used by ESP.
542
PREALLOC Command, Continued
Example 3 The following PREALLOC command unallocates a data set:
OPER PREALLOC CYBER.ESP.PROCS UNALLOC
In the above example, CYBER.ESP.PROCS is unallocated from ESP.
543
PREREQ Statement
Overview The PREREQ statement is used to specify the names of any other jobs that must
complete before this job can execute. ESP automatically selects the jobs for
submission whenever this job is selected for processing.
Syntax The syntax of the PREREQ statement is:
PREREQ {jobname}
jobname Indicates a jobname in up to eight characters and may include
a qualifier in up to eight characters. Enclose multiple job
defined as PREREQs.
defined PREREQs.
A Indicates the specified job(s) release the job you are defining
on abnormal termination, including condition code failures.
U Indicates the specified job(s) release the job you are defining
on any termination.
N Indicates the specified job(s) released the job you are defining
on normal termination. This is the default.
Usage notes PREREQs can be used with any job to name other jobs that should be selected
before this job is allowed to execute. PREREQs dynamically create dependencies
between this job and the jobs you specify as prerequisites. This PREREQ statement
automatically forces selection of the prerequisite jobs, no SELECT or RUN
statement needs to be specified for them.
A PREREQ statement in an ESP Procedure overrides any previous PREREQ
statement for the same job unless the ADD keyword is specified.
For jobs in a DJC jobnet, use the ABNORMAL and NORMAL parameters as
documented in the DJC Users Guide.
Job definitions for PREREQ jobs are required only if you need to specify
requirements for these jobs.
544
PREREQ Statement, Continued
Related
information
COREQ, and POSTREQ statements.
For information on deselecting jobs for submission, see the NORUN and
DESELECT statements.
Example 1 The following PREREQ statement identifies job relationships within an Application:
APPL PAYROLL
JCLLIB CYBER.JCL.
JOB PAYJOB2
RUN WORKDAYS
PREREQ PAYJOB1
ENDJOB
before PAYJOB2.
APPL PAYROLL
JOB PAYJOB3
JOB PAYJOB4
JOB PAYJOB5
JOB PAYJOB6
RUN WORKDAYS
ENDJOB
In the above example, PAYJOB3, PAYJOB4 and PAYJOB5 are automatically
selected for submission and run before PAYJOB6.
APPL PAYROLL
JOB PAYJOB7
JOB PAYJOB8
RUN WORKDAYS
PREREQ (PAYJOB7(U))
ENDJOB
before PAYJOB8. PAYJOB8 runs whether PAYJOB7 completes successfully or
not.
545
Example 4 The following PREREQ and CLANG statements identify job relationships within an
Application:
APPL PAYROLL
JOB PAYJOB9
JOB PAYJOB10
JOB PAYJOB11
JOB PAYJOB12
JOB PAYJOB13
RUN WORKDAYS
PREREQ (PAYJOB9,PAYJOB10)
IF TODAY(MONDAY) THEN PREREQ ADD(PAYJOB11,PAYJOB12)
ENDJOB
PAYJOB9 and PAYJOB10 are automatically selected for submission and run
before PAYJOB13
PAYJOB12 and PAYJOB13 are automatically selected for submission on
Mondays and run before PAYJOB13.
APPL PAYROLL
JOB PAYJOB14
RUN WORKDAYS
PREREQ ADD(PAYJOB15)
PREREQ ADD(PAYJOB16)
ENDJOB
In the above example, PAYJOB15 and PAYJOB16 are automatically selected for
submission and run before PAYJOB14.
Example 6 The following PREREQ and POSTREQ statements simplify job relationships:
APPL PAYROLL
JOB LINKIT LINK PROCESS
RUN WORKDAYS
ENDJOB
In the above example, a link represents the completion of the first three jobs, and
releases the second group of three jobs.
546
Example 7 The following PREREQ statement identifies job relationships for qualified jobs
APPL PAYROLL
JOB PAYJOB23.RUN2
RUN WORKDAYS
PREREQ PAYJOB23.RUN1
ENDJOB
In the above example, PAYJOB23.RUN1 is automatically selected for submission
and runs before PAYJOB23.RUN2.
547
PRIORITY Statement
Overview The PRIORITY statement is used in conjunction with ESP resources to specify the
relative priority of a workload object within an ESP group. The maximum value is
99, while the minimum priority value is 0. The default is 0.
Syntax The syntax of the PRIORITY statement is:
PRIORITY n
n Indicates a number between 0 and 99. The higher the
number, the higher the priority of the job associated with it.
The default is 0.
Usages notes The PRIORITY statement allows you to prioritize jobs within an ESP group. ESP
uses the PRIORITY statement when two or more jobs within the same ESP group
require the same resource at the same time. In this case, ESP queues the higher
priority job ahead of the lower priority job. The queuing sequence of jobs in other
groups is not affected.
The ESP group name is determined by the Event prefix (i.e. first part of the Event
identifier). For example:
CYBER.nnn identifies a job belonging to the CYBER group
PROD.nnn identifies jobs in the PROD group.
For instance, a job that is assigned a priority in a group called CYBER is only
compared to other jobs in the CYBER group, and not to jobs in another group called
PROD.
The PRIORITY statement applies only to renewable and depletable resources.
Related
information
For information on resources, see the ESP Workload Manager Users Guide.
For information on requesting resources, see the RESOURCE statement.
548
PRIORITY Statement, Continued
Example 1 The following PRIORITY statements are used to prioritize jobs within the same ESP
group that require the same resource:
APPL PAYROLL
JOB PAYJOB1
RUN DAILY
REL (PAYJOB2,PAYJOB3)
JOB PAYJOB2
PRIORITY 99
RUN DAILY
RESOURCE (1,CICS)
JOB PAYJOB3
PRIORITY 9
RUN DAILY
RESOURCE (1,CICS)
ENDJOB
In the above example, PAYJOB2 has a priority of 99 and is queued ahead of
PAYJOB3, which has a priority of 9. Both jobs belong to the same ESP group and
both jobs require 1 unit of the CICS resource.
549
PROFILE Statement
Overview A PROFILE statement is used to identify the Event prefix and the EVENTSET that
ESP uses to store Events. Optionally, the statement may also identify a History file
from which a user can report and the default calendars that the Event uses.
Type User Profile Definition Table statement.
Syntax The syntax of the PROFILE statement is:
PROFILE USER(uuuu)EVENTSET(eventset)
[HIST(histid)]
[CALENDAR1(cccc)]
[CALENDAR2(dddd)]
uuuu Indicates an Event prefix specification (normally equivalent
to a security user ID). The specification may include
wildcards.
eventset Indicates the logical ID (eight character internal name) of an
Event data set. It must be a specific name.
histid Indicates the logical ID (eight character internal name) of a
History file. The specification may include wildcards.
cccc Indicates the name of a calendar to be used as the first default
calendar.
dddd Indicates the name of a calendar to be used as the second
default calendar.
Usage notes The order of PROFILE statements in the User Profile Definition Table is important,
with the most generic statement as the last one in the table. This sequence takes into
account the fact that ESP scans the table from top to bottom until it finds a
PROFILE statement that matches the prefix of the new Event.
The profile name can include the ESP wildcard characters * and -. The *
matches a single character, and the - matches any remaining characters.
As a minimum, ESP requires a User Profile Definition Table loaded from a data set
that contains a single PROFILE statement that sets the Eventset default for all new
Events.
The HISTFILE parameter allows wildcard specifications. This is useful in cases
where it is desired to allow individual users to process history reports based on more
than one history file. Only one HISTFILE specification may be entered for a given
PROFILE definition.
550
PROFILE Statement, Continued
Related
information
For information on using SAF, see the ESP Workload Manager Administrators
Guide.
For information on loading the User Profile Definition Table, see the LOADUPDT
command.
Example 1 The following PROFILE statement tells ESP where to save all new Events:
PROFILE USER(-) EVENTSET(EVENT1)
In the above example, ESP stores all new Events in the EVENT1 Eventset.
Example 2 The following PROFILE statement tells ESP where to save specific Events:
PROFILE USER(PROD) EVENTSET(EVENT1) CALENDAR1(CYBER) -
HIST(HIST1)
In the above example, ESP stores Events with a prefix of PROD in the EVENT1
Eventset. This example also indicates these Event use the CYBER calendar and the
user has access to the HIST1 history file.
Example 3 The following PROFILE statements show multiple entries in a UPDT:
PROFILE USER(PAY) EVENTSET(PAYEVS) CALENDAR1(PAYCAL)
PROFILE USER(PROD) EVENTSET(PRODEVS) CALENDAR1(PROD)
PROFILE USER() EVENTSET(EVENT1)
The first PROFILE statement tells ESP to store Events with a prefix of PAY- in
the PAYEVS Eventset. It also indicates that these Events use the PAYCAL
calendar.
The second PROFILE statement tells ESP to store Events with a prefix of
PROD- in the PRODEVS Eventset. It also indicates that these Events use the
PROD calendar.
The third PROFILE statement tells ESP to store all other Events in the EVENT1
Eventset.
551
PURGSCHF Command
Overview The PURGSCHF command is used to purge completed schedule information from
the SCHDFILE. This affects what a user sees on the CSF. Information should be
purged regularly to prevent space problems.
Authority OPER authority is required to issue the PURGSCHF command.
Syntax The syntax of the PURGSCHF command is:
PURGSCHF criteria
criteria Schedule criteria that resolve to a single date and time in the
past.
Usage notes The PURGSCHF command purges only completed jobs. Unless you set a
USERMOD, ESP purges only completed jobs in completed Applications.
The PURGSCHF command does not use any calendar, not even the system calendar,
when resolving schedule criteria. If you need to purge schedule information based
on a calendar term, such as workdays, use the GENTIME command to generate an
actual date, and use the generated symbolic as part of the PURGSCHF command.
Related
information
For information on the Consolidated Status Facility, see the ESP Workload Manager
Users Guide.
Example 1 The following PURGSCHF command purges schedule information:
OPER PURGSCHF TODAY LESS 1 WEEK
In the above example, information older than 1 week is purged from the SCHDFILE.
OPER PURGSCHF NOW LESS 36 HOURS
In the above example, information older than 36 hours is purged from the
SCHDFILE.
552
PURGSCHF Command, Continued
Example 3 The following PURGSCHF command is used in conjunction with the GENTIME
command to purge schedule information:
GENTIME XX TODAY LESS 2 WORKDAYS
ESP OPER PURGSCHF %XXDATE
In the above example, the GENTIME command is used to generate the actual date.
The customized date is then used as part of the PURGSCHF command to purge
information from the previous 2 workdays.
Note: The above commands reside in an ESP Procedure and are invoked by an ESP
Event.
OPER PURGSCHF NOW
In the above example, information older than the current time is purged.
553
QUIESCE Command
Overview The QUIESCE command is used to put ESP into a quiesced state. While ESP is in a
quiesced state Event scheduling and Application processing are quiesced. Jobs that
are running when ESP is quiesced continue to run. No new jobs are submitted.
Authority OPER authority is required to issue the QUIESCE command
Syntax The syntax of the QUIESCE command is:
QUIESCE
Usage notes If ESP is being restarted, you can bring it up in a quiesced state by using the
QUIESCE option on the start command.
Related
information
For information on taking ESP out of the quiesced state, see the RESTART
command.
Example 1 The following QUIESCE command quiesces Event scheduling and Application
processing:
OPER QUIESCE
In the above example, ESP is quiesced, which is displayed using the STATUS
command as follows:
OPER STATUS
ESP1977I ESP RELEASE 5.1.0.000 STATUS
ESP1978I EVENT SCHEDULING QUIESCED
ESP1979I DATASET TRIGGERING ACTIVE
In the above example, ESP is in a quiesced state as noted by the ESP1978I message -
EVENT SCHEDULING QUIESCED.
554
QUIT Statement
Overview The QUIT statement is used to quit an ESP Procedure and the Event that invoked it.
Syntax The syntax of the QUIT statement is:
QUIT
Usage notes Use QUIT to quit a process. If you use QUIT, ESP does not process any pending
requests from this or any other Procedure invoked by the same Event.
ESP ignores QUIT statements within the scope of a JOB statement during
Application generation. During Application processing, QUIT within the scope of a
JOB statement causes ESP not to process any statements for the job and ESP does
not submit the job.
Related
Statements
For information on quitting from your current point in a procedure, see the EXIT
statement.
For information on using ESPs Control Language in Procedures, see the ESP
Example 1 The following procedure shows the differences between using EXIT and QUIT:
IF TODAY(CHRISTMAS) THEN QUIT
IF TODAY(HOLIDAY) THEN DO
SEND NO WORK TODAY U(USER01)
EXIT
ENDDO
SEND LET US CONTINUE PROCESSING U(USER02)
If today is CHRISTMAS, ESP quits the ESP Procedure and no instructions are
processed
If today is not CHRISTMAS, but it is a holiday, ESP sends a message and exits
the Procedure at that point
If none of the above conditions is true, ESP sends a message indicating that
processing will continue.
555
QUIT Statement, Continued
Example 2 The following procedure shows the differences between using EXIT and QUIT
within the scope of the job statement:
APPL PAYROLL
JOB PAYJOB1
RUN WORKDAYS
RELEASE PAYJOB2
IF TODAY(TUESDAY) THEN -
EXIT
SEND TODAY IS NOT MONDAY U(USR01)
ENDJOB
JOB PAYJOB2
RUN WORKDAY
QUIT
ENDJOB
In the above example, when the PAYROLL Application is generated on a Monday:
PAYJOB1 is submitted, and a message is issued if it isnt Monday
PAYJOB2 is not submitted and receives an error.
The following is an example of the CSF display after PAYJOB1 completes on
Monday:
ESP Consolidated Status: View PAYROLL -- Row 1 of 2, Col 1
___ PAYJOB1 PAYROLL COMPLETE COMPLETED AT 13.14 21 APR
___ PAYJOB2 PAYROLL SUBERROR Submit Error, Quit
556
QUPDATE Command
Overview The QUPDATE command is used to force ESP to do a JES status and update P-
Node queue information.
Authority OPER authority is required to issue the QUPDATE command.
Syntax The syntax for the QUPDATE command is:
QUPDATE
Usage notes The QUPDATE command allows any job flushed from the system to be recognized.
ESP automatically posts these jobs through the EXEC and OUTPUT processing
nodes and marks each as a JCL ERROR.
Related
information
Example 1 The following QUPDATE command updates P-Node queue information:
OPER QUPDATE
In the above example, ESP does a JES status and automatically posts any flushed
jobs through the EXEC and OUTPUT P-Nodes.
557
RACROUTE Command
Overview The RACROUTE command is used to specify how an Event is processed for
security purposes. You specify whether ESP should issue a SAF RACINIT prior to
executing Events, and how the user ID associated with the Event is determined. The
RACROUTE command must be set to ON in environments using the System
Authorization Facility (SAF). RACROUTE is normally coded as an Initialization
Parameter.
Authority OPER authority is required to issue the RACROUTE command.
Syntax The syntax of the RACROUTE command is:
RACROUTE [ON|OFF]
[ITU|NOITU]
ON Indicates ESP should issue a SAF RACINIT before executing
Events.
OFF Indicates ESP should not issue a SAF RACINIT before
executing Events. This is the default.
ITU Inherit Trigger User - Indicates all triggered Events use the
triggering user ID and associated security profile.
NOITU No Inherit Trigger User - Indicates all triggered Events use
the high-level prefix of the Event definition, unless USER is
specified in the Event definition. Only those Events that have
ITU in the Event definition use the triggering user ID. This is
the default.
Usage notes If RACROUTE is set to ON, ESP issues a SAF call prior to executing Events. This
ensures Events are processed under ownership of the user ID that defined the Event.
If RACROUTE is set to OFF, ESP processes Events under the ownership of the ESP
started task.
The ITU option affects Events only when the TRIGGER command is issued.
Related
information
For information on using RACROUTE at the Initialization Parameter level, see the
ESP Workload Manager Installation Guide.
558
RACROUTE Command, Continued
Example 1 The following RACROUTE command specifies how Events are processed for
security purposes:
OPER RACROUTE ON
In the above example, ESP issues a SAF RACINIT before executing Events.
559
REEXEC Statement
Overview The REEXEC statement is used to request re-execution of the ESP Procedure at a
specific time or after a certain time interval.
Type ESP Application statement
Syntax The syntax of the REEXEC statement is:
REEXEC {AT(time)|IN(interval)}
[DELAY|ADDITIONAL]
[MAXIMUM(count)|NOMAXIMUM]
time Schedule criteria that resolve to a single date and/or time. If
no time is implied, the start time of a day is used. Enclose
parameter in quotes.
interval Indicates a whole number of minutes.
DELAY Indicates that when the Procedure is re-executed, job
submission is delayed until the conditional processing is true.
All other functions are executed. This is the default.
ADDITIONAL Indicates that additional job submission will take place with
every re-execution.
count Indicates the maximum number of times the Event is re-
executed. A value between 1 and 255 can be specified.
There is no default.
NOMAXIMUM The default is 255.
Usage notes This statement is used to request re-execution of an ESP Procedure at a specified
time or after a certain interval. The Event that invoked the ESP Procedure
containing the REEXEC statement is scheduled for re-execution.
The variable %ESPREEXEC# can be used to check the number of times a Procedure
was re-executed. The variable is set to zero initially and cannot take on a value
greater than 255.
ESP stores the number of reexecutions in a symbolic variable called
ESPREEXEC#. If you use REEXEC within the scope of a JOB statement in an
Application, ESP reexecutes only the code associated with that job, and maintains
a separate ESPREEXEC# for each job.
Related
information
For information on re-executing an ESP Procedure, see the ESP Workload Manager
Users Guide.
560
REEXEC Statement, Continued
Example 1 The following REEXEC command is used in conjunction with the ACTIVE built-in
function to check the status of a started task:
IF ACTIVE(CICS) THEN DO
SEND CICS IS DUE TO COME DOWN CN(01)
REEXEC IN(5)
ENDDO
ELSE SUBMIT PROD.JCL.CNTL(CICSBKUP)
If CICS is active, ESP sends a message to console id 01 and reexecutes the
Procedure in 5 minutes.
If CICS is not active, ESP submits the CICSBKUP from PROD.JCL.CNTL.
Example 2 The following REEXEC command is used in conjunction with the JOBONQ built-in
function to check for a specific job on the input queue:
INTEGER COUNT
COUNT=JOBONQ(RMTJOB,X,IH)
IF COUNT=1 THEN VS $AJ%XJOBNO1
ELSE DO
IF ESPREEXEC#<5 THEN REEXEC IN(30)
ELSE SEND I GIVE UP ON RMTJOB U(USER01)
ENDDO
If RMTJOB is on the input queue on hold, ESP releases the job.
If RMTJOB is not on the input queue on hold, ESP checks the number of re
executions. If the number of reexecutions is less than 5, ESP reexecutes the
Procedure in 30 minutes. Otherwise, ESP sends a message.
Example 3 The following REEXEC command delays the submission of a job:
APPL PAYROLL
JOB PAYJOB1
RUN DAILY
RELEASE PAYJOB2
JOB PAYJOB2
RUN DAILY
IF %ESPREEXEC#=0 THEN REEXEC AT(REALNOW PLUS 5 HOURS)
ENDJOB
In the above example, PAYJOB2 is delayed for 5 hours after PAYJOB1 completes.
561
REEXEC Statement, Continued
Other examples Here are more examples using the REEXEC statement.
Indicates re-execution in 5 minutes:
REEXEC IN(5)
Indicates re-execution at the start of the next workday:
REEXEC AT(TODAY PLUS 1 WORKDAY)
Indicates re-execution in 6 hours:
REEXEC AT(REALNOW PLUS 6 HOURS)
Indicates re-execution in five minutes for a maximum of five times:
REEXEC IN(5) MAXIMUM(5)
Indicates re-execution in one minute for an unlimited time:
REEXEC IN(1 MINUTE) NOMAXIMUM
562
RELCOUNT Statement
Overview The RELCOUNT statement is used to specify the hold count when a job becomes
eligible for submission. By default, ESP does not consider a job eligible for
submission until its hold count is 0.
Syntax The syntax of the RELCOUNT statement is:
RELCOUNT n
n Indicates a positive integer representing the number of
outstanding predecessors before this job is eligible for
execution.
Usage notes If RELCOUNT is not specified, a job is not eligible for execution until all
predecessors are complete (that is, its hold count is reduced to zero).
Related
information
For information on Applications, see the ESP Workload Manager Users and
Advanced Users Guides.
Example 1 The following RELCOUNT statement specifies when a job is eligible for
submission:
APPL PAYROLL
JOB PAYJOB1
RUN DAILY
REL PAYJOB3
JOB PAYJOB2
RUN DAILY
REL PAYJOB3
JOB PAYJOB3
RUN DAILY
RELCOUNT 1
ENDJOB
In the above example, when ESP builds the Application, PAYJOB3 has a hold count
of 2. By specifying a RELCOUNT of 1 for PAYJOB3, ESP releases this job when
its hold count becomes 1. ESP releases PAYJOB3 when either PAYJOB1 or
PAYJOB2 completes successfully.
563
RELCOUNT Statement, Continued
submission:
APPL PAYROLL
JOB PAYJOB4
RUN DAILY
JOB PAYJOB5
RUN DAILY
JOB PAYJOB6
RUN DAILY
JOB PAYJOB7
RUN DAILY
JOB PAYJOB8
AFTER(PAYJOB4,PAYJOB5,PAYJOB6,PAYJOB7)
RUN DAILY
RELCOUNT 3
ENDJOB
its hold count becomes 3. This means ESP releases PAYJOB8 when any one of its
predecessors completes successfully.
submission:
APPL PAYROLL
DSTRIG FILEA
RUN DAILY
RELEASE PAYJOB1
DSNAME CYBER.ESP.FILEA
DSTRIG FILEB
RUN DAILY
RELEASE PAYJOB1
DSNAME CYBER.ESP.FILEB
JOB PAYJOB1
RUN DAILY
RELCOUNT 1
ENDJOB
either data set trigger object completes.
564
RELDELAY Statement
Overview The RELDELAY statement is used to delay job submission at the time that a job
becomes eligible for submission. The RELDELAY statement uses minutes as its
unit of measure. You can delay job submission up to 255 minutes.
Syntax The syntax of the RELDELAY statement is:
RELDELAY nnn
nnn Indicates a positive integer representing the number of
minutes to delay submission. The maximum value allowed is
255; the default is 0.
Usage notes When a job becomes eligible for submission, ESP delays submission by the number
of minutes specified by the RELDELAY statement for the job. If a job requires ESP
resources, the RELDELAY takes effect before the check for resource availability.
At the time a job is delayed for submission, the status field on the CSF indicates the
resolved time and date of the RELDELAY statement, i.e. the number of minutes
after the delayed job becomes eligible for submission. You can reset this resolved
time and date using the APPLJOB (AJ) command or the CSF to reset the earliest
submit time.
Related
information
For information on delaying the submission of a job relative to the time the Event is
scheduled or triggered, see the DELAYSUB statement.
For information on monitoring and manipulating jobs from the CSF, see the ESP
For information on manipulating jobs within Applications or subApplications, see
If you need to delay more than 255 minutes, use the REEXEC statement.
565
RELDELAY Statement, Continued
Example 1 The following RELDELAY statement delays the submission of a specific job:
APPL PAYROLL
JOB PAYJOB1
RUN DAILY
REL PAYJOB2
JOB PAYJOB2
RUN DAILY
RELDELAY 5
ENDJOB
In the above example, when PAYJOB1 completes successfully, PAYJOB2 becomes
eligible for submission and the RELDELAY statement delays the submission of
PAYJOB2 by 5 minutes.
Note: At the time PAYJOB2 is delayed for submission, the status field on the CSF
indicates the resolved time and date of the RELDELAY statement, i.e. 5 minutes
after PAYJOB2 becomes eligible for submission, as follows:
E510 Consolidated Status: View PAYROLL - Row 1 of 3, Col 1
Jobname APPL GEN PNODE HC STATUS
___ PAYJOB1 PAYROLL 131 COMPLETE 0 COMPLETED AT 21.54 03 FEB
___ PAYJOB2 PAYROLL 131 WAITING 0 WAITING UNTIL 21.59 03 FEB
Example 2 The following RELDELAY statement delays a LINK:
APPL PAYROLL
JOB PAYJOB3
RUN DAILY
REL FRED
JOB FRED LINK PROCESS
RUN DAILY
SEND LINKS CAN USE THE RELDELAY STATEMENT TOO (USR01)
RELDELAY 2
REL PAYJOB4
JOB PAYJOB4
RUN DAILY
ENDJOB
In the above example, a LINK (FRED), which is normally marked complete by ESP
as soon as its dependencies are met, is delayed by 2 minutes after becoming eligible
for submission, that is, after PAYJOB3 completes successfully.
566
RELEASE Command - Event Level
Overview When used in an Event definition, the RELEASE command decrements the hold
count associated with the Event at a specified time. When the hold count reaches
zero, the Event is eligible for execution. It is used in conjunction with the HOLD
command.
Syntax The syntax of the RELEASE command is:
RELEASE criteria
Usage notes The RELEASE command is used in conjunction with the HOLD command to make
ESP processes any pending actions. For example, if an Event missed its scheduled
time while on hold, ESP processes the Event based on the OVERDUE count on the
Events SCHEDULE statement.
If you are using a time zone on your RELEASE command, it should match the
timezone on your HOLD command. If the Event has a schedule statement, the same
time zone should be used on the SCHEDULE, HOLD and RELEASE commands.
Note:
The SUSPEND command is used in conjunction with the RESUME command to
Related
information
For information on holding an Event, see the HOLD command.
For information on releasing a held Event outside of an Event definition, see the
RELEASE Command - General.
For information on overdue Events, see the SCHEDULE command.
567
RELEASE Command - Event Level, Continued
HOLD DAILY AT 9AM
ENDDEF
PAYJOB1 from being submitted between 9 am and 11 am.
SCHEDULE 6PM DAILY
HOLD 5PM LAST DAY OF MONTH
RELEASE 9PM LAST DAY OF MONTH
ENDDEF
PAYJOB2 from being submitted between 5 pm and 9 pm on the last day of the
month.
SCHEDULE 8AM WORKDAYS
HOLD 7:59 FEB 13,1998 ONCE
RELEASE 10:01 FEB 13,1998 ONCE
ENDDEF
PAYJOB3 from being submitted between 7:59 and 10:01 on February 13, 1998
only.
568
RELEASE Command - General
Overview The RELEASE command decrements the hold count associated with an Event. It is
used in conjunction with the HOLD command.
Syntax The syntax of the RELEASE command is:
RELEASE eventid
eventid Indicates a valid Event name. If no prefix is specified, ESP
uses the current prefix, set by the GROUP command.
Usage notes ESP processes any pending actions. For example, if an Event missed its scheduled
time while on hold, ESP processes the Event based on the OVERDUE count on the
Events SCHEDULE statement.
The specified Event has its HOLD count decremented immediately.
The RELEASE command is used in conjunction with the HOLD command to make
Note:
Related
information
For information on overdue Events, see the SCHEDULE command.
For information on holding an Event, see the HOLD command.
For information on using RELEASE within an Event, see the RELEASE Command -
Event Level.
Examples 1 The following RELEASE command releases an Event:
RELEASE CYBER.PAYROLL
In the above example, CYBER.PAYROLL was previously held and is now eligible
for execution if the hold count was 1. Otherwise, the hold count was decrement by 1.
569
RELEASE Statement
Overview The RELEASE statement is used to identify a successor to a job. The successor is
released upon completion of this job.
Syntax The syntax of the RELEASE statement is:
RELEASE {jobname}
jobname Indicates a jobname in up to eight characters. Enclose
multiple job names in parentheses, separated by a blank or a
comma. Jobnames may be qualified.
defined RELEASEs.
defined RELEASEs.
A Indicates the specified job(s) are released on abnormal
termination, including condition code failures, of a
predecessor.
U Indicates the specified job(s) are released on any termination
of a predecessor.
N Indicates the specified job(s) are released on normal
termination of a predecessor. This is the default.
Usage notes The default is successful completion.
The RELEASE statement increases the hold count of any successor jobs that you
name, assuming this job and the successor jobs are selected for execution.
For jobs in JES3 or DJC jobnets, the ABNORMAL and NORMAL parameters as
documented in the JES3 or DJC Users Guide.
Related
information
For information on other ways specifying predecessor and successor relationships,
see the AFTER, PREREQ and POSTREQ statements.
For information on specifying job relationships and selecting jobs for submission,
see the ESP Workload Manager Users Guide.
570
RELEASE Statement, Continued
Example 1 The following RELEASE statements identifies job relationships within an
Application:
APPL PAYROLL
JOB PAYJOB1
RUN WORKDAYS
RELEASE PAYJOB2
JOB PAYJOB2
RUN WORKDAYS
ENDJOB
In the above example, PAYJOB2 is defined as a successor to PAYJOB1 and is
eligible for submission upon the successful completion of PAYJOB1.
Example 2 The following RELEASE statement identifies job relationships within an
Application:
APPL PAYROLL
JOB PAYJOB3
RUN WORKDAYS
RELEASE (PAYJOB4,PAYJOB5,PAYJOB6)
JOB PAYJOB4
RUN WORKDAYS
JOB PAYJOB5
RUN WORKDAYS
JOB PAYJOB6
RUN FRIDAYS
ENDJOB
In the above example, PAYJOB4, PAYJOB5 and PAYJOB6 are defined as
successors to PAYJOB3 and are eligible for submission upon the successful
completion of PAYJOB3.
Application:
APPL PAYROLL
JOB PAYJOB7
RUN WORKDAYS
RELEASE (PAYJOB8(A))
RUN WORKDAYS
ENDJOB
In the above example, PAYJOB8 is defined as a conditional successor to PAYJOB7
and is eligible for submission upon the abnormal termination of PAYJOB7. If
PAYJOB7 completes successfully, PAYJOB8 is not eligible for submission.
571
RELEASE Statement, Continued
Application:
APPL PAYROLL
JOB PAYJOB9
RUN WORKDAYS
RELEASE (PAYJOB10(U))
RUN WORKDAYS
ENDJOB
In the above example, PAYJOB10 is defined as a conditional successor to
PAYJOB9 and is eligible for submission after PAYJOB9 completes, successfully or
not.
Example 5 The following RELEASE and RELEASE ADD statements are used to indicate job
relationships:
APPL PAYROLL
JOB PAYJOB11
RUN WORKDAYS
RELEASE ADD(PAYJOB12)
JOB PAYJOB12
RUN WORKDAYS
JOB PAYJOB13
RUN WORKDAYS
ENDJOB
In the above example, PAYJOB12 and PAYJOB13 are submitted after the
successful completion of PAYJOB11.
Example 6 The following RELEASE and RELEASE ADD statements are used to indicate job
relationships:
APPL PAYROLL
JOB PAYJOB14
RUN DAILY
RELEASE PAYJOB15
ENDJOB
JOB PAYJOB15
RUN DAILY
JOB PAYJOB16
RUN DAILY
ENDJOB
In the above example, PAYJOB15 and PAYJOB16 are submitted after the
successful completion of PAYJOB14.
572
REMOVE Command
Overview The REMOVE command is used in conjunction with the GENDOC, LABEL and
GO commands when converting an existing job documentation library to a
documentation library usable by ESP. The REMOVE command identifies lines that
are not to be copied to the output data set.
Syntax The syntax of the REMOVE command is:
REMOVE string
string Indicates any character string enclosed in quotes.
Usage notes The GENDOC command identifies the input data set, members to be copied, and the
output data set. It also lets you identify changes you want to make when the old
documentation converts.
Use REMOVE, LABEL and GO in conjunction with the GENDOC command to
customize the conversion of existing job documentation to ESP job documentation.
Related
information
For information on converting existing job documentation, see the GENDOC
command.
For information on altering or replacing lines in the output data set during the
conversion, see the LABEL command
Guide.
573
REMOVE Command, Continued
REMOVE **
GO
In the above example, ESP will:
Replaces any lines starting with SYSOUT REVIEW with the character string
SYSOUT_REVIEW.
Overlays the semicolon on any line beginning with STEP. The semicolon is
positioned after the 3rd character following the string STEP.
Proceed with the copy process.
574
REPORT Command
Overview The REPORT command is used to begin a report definition.
Syntax The syntax of the REPORT command is:
REPORT
Usage notes The ENDR command must end the report definition. For more information, see the
ENDR command.
REPORT
FROM 7AM YESTERDAY
ENDR
The ENDR command ends the report definition and initiates report generation.
575
RESDEF Command
Overview The RESDEF command is used to define, display, delete or update resources.
Authority OPER authority is required to issue the RESDEF command in non-SAF
environments. With SAF, you control access to resources using the
RESOURCE.resname resource.
Syntax The syntax of the RESDEF command is:
RESDEF name [ADD|DEL|LIST|SET]
[ENTERPRISE|GLOBAL|LOCAL]
[THRESHOLD|RENEWABLE|DEPLETABLE]
[OWNERS|WAITERS]
[NODE(xxx)][CPU(xxx)]
[MAX(n)][AVAIL(0)]
[DEVICE(xxxxx)]
[GRAVITY|NOGRAVITY]
name Indicates the resource name using up to eight alphanumeric
characters. (When using the LIST, DEL or SET parameters,
the resource name may include the asterisk (*) and hyphen (-)
wild card characters for masking).
ADD Indicates you are defining a new resource.
DEL Deletes one or more existing resource definitions.
LIST Displays a list of one or more existing resource definitions.
SET Modifies attributes of a resource definition. Resource type
and scope cannot be modified.
576
RESDEF Command, Continued
Syntax (continued)
ENTERPRISE Indicates the resource is equally available across the entire
enterprise - a single resource pool is shared by all MVS
images. This is the default.
GLOBAL Indicates one resource counter is available for each
JESPLEX. This maintains one resource pool for each node.
LOCAL Indicates one resource counter is maintained for each MVS
image.
THRESHOLD Defines a threshold resource type.
RENEWABLE Defines a renewable resource type. This is the default.
DEPLETABLE Defines a depletable resource type.
OWNERS Displays jobs that are currently executing and holding a
resource. This is used with LIST.
WAITERS Displays jobs waiting for a resource. This is used with LIST.
NODE(xxx) Refers to the node name defined when the system topology
was specified. Limits LIST or SET to a specific node.
CPU(xxx) Refers to the node name defined when the system topology
was specified. Limits LIST or SET to a specific CPU.
MAX(n) Sets maximum counter value for resource you are defining.
AVAIL(n) Sets available value for resource you are defining.
DEVICE(xxxxx) Indicates either the IBM generic or esoteric device name that
ESP is to monitor.
GRAVITY Indicates jobs are to be routed to other nodes on which the
resource is available.
NOGRAVITY Indicates jobs are not to be routed to other nodes on which a
resource is available. This is the default.
577
Usage notes -
defining a
resource
Before you use the resources feature, a data set called the RESFILE needs to be
defined and identified in the ESP Initialization Parameters. CPU and NODE
definitions are also required. The RESFILE is used to store the following
information:
System topology
Resource definitions
Allocation of resources, i.e. jobs that have resources allocated to them and jobs
waiting to allocate resources.
When you define a resource, you need to:
Name the resource
Use the ADD keyword to indicate you are defining a new resource
Indicate the scope of the resource - local, global, or enterprise
Indicate the type of resource - renewable, depletable, or threshold
Indicate if the resource represents a real device
Indicate the CPU to which the resource applies
Indicate whether the resource has gravity
Specify the quantities of the resource available and maximum.
Resource definitions are stored in the RESFILE. If ESP is started with the
RESFORM option, information stored in the RESFILE is lost. A useful technique to
ensure that system topology and resource definitions are not lost on a reformat
(RESFORM) of the RESFILE, is to code the following in your ESP Initialization
Parameters:
IF RESFORM THEN DO
NODE TORONTO ADD ROUTEJCL(/*XEQ TORONTO)
CPU T1 ADD NODE(TORONTO) ROUTEJCL(/*JOBPARM SYSAFF=T1) ORDER(1)
CURRENT
RESDEF T3480 ADD LOCAL RENEWABLE MAX(5) CPU(T1)
RESDEF CICSUP ADD GLOBAL THRESHOLD AVAIL(0)
RESDEF DB2TAB1 ADD GLOBAL RENEWABLE AVAIL(3)
ENDDO
If you are using the resource feature extensively and have a large number of
resources defined, it may not be desirable to code all your resource definitions in the
ESP Initialization Parameters. An alternative method is to store your resource
definitions in a data set and issue the LOAD command to process the RESDEF
commands, in the event the RESFILE is reformatted.
Note: The LOAD command cannot be used in ESPs Initialization Parameters.
578
Usage notes -
resource counts
You can specify maximum and available counts for a resource. For depletable and
threshold resources, there is only one quantity. You can specify either maximum
(MAX) or available (AVAIL). For renewable resources, there are maximum and
available quantities. Maximum is the total quantity of the resource that exists;
available is the current quantity.
When setting a renewable resource:
Setting the MAX count automatically adjusts the AVAIL count.
Setting the AVAIL count has no effect on the MAX count.
The following is an example of the display produced when a resource is listed and
what happens when the MAX and AVAIL counts are manipulated:
RESDEF CICS LIST
Resource CICS Local Renewable
TORONTO MVSA Max=2 Avail=2
RESDEF CICS SET MAX(4)
RESDEF CICS SET AVAIL(6)
Usage notes -
resource counts
The following is an example of the display produced when a resource is listed and
what happens when the AVAIL count is changed for a threshold resource:
RESDEF DAYSHIFT LIST
Resource DAYSHIFT Local Threshold
TORONTO MVSA Avail=1
RESDEF DAYSHIFT SET AVAIL(2)
Resource DAYSHIFT Local Threshold
TORONTO MVSA Avail=2
579
Usage notes -
Real resources
Real resources are intended to work in a single CPU environment, as there is no
capability to be aware of the status of devices on any CPU other than the one where
the master ESP is running. Therefore real resources should be defined as LOCAL
and RENEWABLE, using the MAX parameter to identifying the number of devices
being made available to ESP submitted jobs, as follows:
RESDEF T3480 ADD LOCAL RENEWABLE MAX(5) DEVICE(3480)
The following is an example of the display produced when listing the above
resource:
RESDEF T3480 LIST
Resource T3480 Local Renewable
TORONTO MVSA Max=5 Avail=5 Real=5
ESP ensures there are sufficient online, unallocated devices available to satisfy the
resource requirements for the current job.
For example, if job PAYJOB1 requires 3 units of a real resource called T3480, and
ESP sees 3 available, but only 2 devices are actually online and unallocated, ESP
waits for resources and PAYJOB1 goes into a RESWAIT state.
Related
information
For information on specifying default resources, see the RESDFLT command.
Example 1 The following RESDEF command displays all resources:
RESDEF - LIST
In the above example, all existing resource definitions are displayed.
580
Example 2 The following RESDEF command defines a resource:
RESDEF IMS ADD LOCAL RENEWABLE MAX(3) CPU(TOR1)
In the above example, IMS is a local, renewable resource with a quantity of 3. IMS
resides on the TOR1 MVS image and is used to represent access to an IMS region.
The maximum number of jobs requiring 1 unit of the IMS resource that can run
concurrently is 3.
RESDEF NITESHFT ADD GLOBAL THRESHOLD AVAIL(1)
In the above example, NITESHFT is a global, threshold resource with a quantity of
1. NITESHFT represents a time period when specific jobs can run. The NITESHFT
resource can be manipulated, using the SET parameter at the appropriate times to
ensure night shift jobs run between 1 am - 8 am for example.
RESDEF PAYJOB1 ADD LOCAL THRESHOLD AVAIL(0)
In the above example, PAYJOB1 is a local, threshold resource with a quantity of 0.
PAYJOB1 is used to represent the completion of a job. The PAYJOB1 resource can
be manipulated, using the SET parameter after the successful completion of
PAYJOB1 to allow successor jobs to be submitted.
Example 5 The following RESDEF command defines a real resource:
RESDEF T3480 ADD LOCAL RENEWABLE DEVICE(3480)
In the above example, T3480 is a local, renewable resource representing 3480
cartridge drives. The number of tape drives currently on-line and not allocated is
compared with ESPs internal counters to determine when jobs that require the
T3480 resource are eligible for submission.
581
RESDEF CICS ADD LOCAL RENEWABLE MAX(1) CPU(TOR2) GRAVITY
In the above example, CICS is a local, renewable resource with a quantity of 1.
CICS resides on the TOR2 MVS image and is used to represent access to a CICS
region. The GRAVITY attribute indicates that the CICS resource is available to
jobs on other nodes. If a job on another node requires the CICS resource, the
appropriate routing information is inserted into the requesting jobs JCL as per the
system topology statements.
Example 7 The following RESDFLT and RESDEF commands define a default resource:
RESDFLT SCRATCH(SCRTAPES)
RESDEF SCRTAPES ADD GLOBAL DEPLETABLE AVAIL(500)
The RESDFLT Initialization Parameter or command indicates ESP should make
default resource assignments for scratch tapes
The RESDEF command defines a global, depletable resource with a quantity of
500. ESP uses historical information to assign scratch tape resource
requirements to each job in an Application.
Note: Once default resources are turned on, every Application generated by ESP
uses default resources. To drop a default resource code the following:
RESOURCE (0,SCRTAPES)
Example 8 The following RESDEF command modifies the attributes of an existing threshold
resource:
RESDEF LOWPRIO SET AVAIL(1)
In the above example, the available quantity of the LOWPRIO resource is set to one.
582
Example 9 The following RESDEF command modifies the attributes of an existing depletable
resource:
RESDEF SCRTAPES SET AVAIL(550)
In the above example, the available quantity of the SCRTAPES resource is set to
550.
Example 10 The following RESDEF command modifies the attributes of an existing renewable
resource:
RESDEF CICSUP SET MAX(2)
In the above example, the quantity of the CICSUP resource is set to two.
Example 11 The following RESDEF command deletes a resource:
RESDEF COCONUT DELETE
In the above example, the COCONUT resource is deleted.
Example 12 The following RESDEF command displays a specific resource:
RESDEF DBASE LIST OWNERS WAITERS
In the above example, jobs using, and jobs waiting for, the DBASE resource are
displayed.
583
RESDFLT Command
Overview The RESDFLT command is used to identify the default resources you want to use.
ESP can make default resource assignments automatically for the following: # of
tape drives needed, # of scratch tapes needed, % CPU absorption, total CPU time
used, total elapsed time used, and total print lines generated.
Authority OPER authority is required to issue the RESDFLT command.
Syntax The syntax of the RESDFLT command is:
RESDFLT [LIST]
[CARTRIDGE(cart)]
[SCRATCHCART(scratch)]
[CPUABSORPTION(cpuabs)]
[CPUTIME(cputime)]
[ELAPSEDTIME(elapsed)]
[PRINTLINES(prlines)]
LIST Displays the current default resources.
cart Indicates the name of a cartridge tape resource. It should be a global
renewable resource and should identify a device name. ESP requests
a value equal to the average tape drive high water mark for a job, i.e.
the average of the maximum number of tape drives required by the
job at any one moment in time. Resource names are restricted to 8
characters.
scratch Indicates the name of a scratch tape resource. It should be defined as
a depletable resource. This resource should be adjusted to the
number of scratch tapes made available to ESP jobs. Resource names
are restricted to 8 characters.
584
RESDFLT Command, Continued
Syntax (continued)
cpuabs Indicates a resource that reflects CPU absorption. When ESP
submits a job, it looks at the average CPU absorption, calculated as
CPU time divided by elapsed time and expressed as a percentage. It
then assigns that many units of the named resource. For example, if
a job uses 10% of the CPU when it executes, ESP requests 10 units
of the CPU absorption resource. This resource should be defined as
a local renewable resource. Assign a value equal to the maximum
CPU utilization you want for ESP submitted jobs. For example, if
you want ESP to submit jobs that only use up to 80 percent of the
CPU, set this value to 80. Resource names are restricted to 8
characters.
cputime Indicates the name of a resource that represents the total CPU time
used by a job, expressed in seconds. This is normally a threshold
local resource. You can use it to limit the execution of jobs that
require more than a certain threshold of CPU time. Resource names
are restricted to 8 characters.
elapsed Indicates the name of a resource that represents total elapsed time
used by a job, expressed in minutes. This is normally a threshold
local resource. You can use it to prevent submission of jobs that
require more than a certain threshold of elapsed time. For example,
if you are scheduling a shutdown of a certain MVS system, you can
set the maximum availability of the resource to the number of
minutes before the scheduled shutdown. ESP does not submit a job
that can, on average, complete prior to the scheduled shutdown time.
This value can be adjusted down automatically, as the scheduled
time draws closer, through an automation program or through an
ESP Event. Resource names are restricted to 8 characters.
prlines Indicates the name of a resource that represents the total print lines
generated by a job. This is normally a global threshold or depletable
resource. You can use it to limit submission of jobs that require
more than a certain quantity of spool space. This is determined by
the spool size in your installation. Resource names are restricted to
8 characters.
585
Usage notes The RESDFLT command is normally stored as an ESP Initialization Parameter,
otherwise it disappears with each restart of ESP.
Once you have identified the default resources your installation requires, use the
RESDEF command to specify the resource type - renewable, depletable or threshold,
and the scope of the resource - local, global or enterprise.
You can use one or more default resources.
The information used to assign default resources is based on information contained
in the Job Index file. ESP bases the default resource levels it assigns on an average
of the samples found in this file. The number of samples depends on the index count
specified when the Job Tracking Model was defined. Only information from normal
job completions, and not from abends, is used. The information is updated each time
a new generation of an Application is created.
Once default resources are turned on, every Application generated by ESP uses
default resources. To drop a default resource, request zero unit of the resource. For
example:
Related
information
For information on defining resource, see the RESDEF command.
For information on specifying default resource at the initialization parameter level,
see the ESP Workload Manager Installation Guide.
Example 1 The following RESDFLT command displays default resources:
OPER RESDFLT LIST
In the above example, all default resources are displayed.
Example 2 The following RESDFLT command defines two default resources:
OPER RESDFLT SCRATCH(SCRTAPES)
OPER RESDFLT ELAPSEDTIME(ELAPSE)
or
OPER RESDFLT SCRATCH(SCRTAPES) ELAPSEDTIME(ELAPSE)
In the above example, two default resources are defined.
586
RESDFLT SCRATCH(SCRTAPES)
RESDEF SCRTAPES ADD GLOBAL DEPLETABLE AVAIL(500)
default resource assignments for scratch tapes.
The RESDEF command defines a global, depletable resource with a quantity of
500.
ESP uses historical information to assign scratch tape resource requirements to
each job in an Application. ESP automatically decrements the SCRTAPES
resource as jobs run.
Note: Once default resources are turned on, all Applications generated by ESP use
default resources. To drop the SCRTAPES default resource, code the following:
After creating more scratch tapes, use the following command to set the new count:
RESDEF SCRTAPES SET AVAIL(750)
Example 4 The following RESDFLT command changes the name assigned to a default
resource:
OPER RESDFLT SCRATCH(BLANKTAP)
In the above example, the name previously assigned to this default resource is
changed to BLANKTAP.
587
RESDFLT ELAPSEDTIME(ELAPSE)
RESDEF ELAPSE ADD LOCAL THRESHOLD AVAIL(60)
default resource assignments for elapsed time used by a job.
The RESDEF command defines a local, threshold resource with a quantity of
60.
ESP uses historical information to prevent submission of jobs that require more
than a certain threshold of elapsed time.
The following is an example of a recursive ESP Procedure that could be used to
notify users of a system shutdown and prevent long-running jobs from starting using
the ELAPSE default resource defined above:
/* PASS NUMBER OF MINUTES TO SHUTDOWN USING USER1
/* PARAMETER WHEN TRIGGERING THE EVENT
/*
/* SEND MESSAGE, DECREMENT TIME AND RETRIGGER EVENT IN
/* 1 MINUTE IF TIME >= 0
/*
INTEGER TIME
TIME=USER1
SEND SYSTEM COMING DOWN IN %TIME MINUTES USER(CYB01)
ESP RESDEF ELAPSE SET AVAIL(%TIME)
TIME=TIME1
IF TIME>=0 THEN ESP TRIGGER OPER.SHUTDOWN +
USER1(%TIME) AT(NOW PLUS 1 MINUTE)
588
RESOLVE Statement
Overview The RESOLVE statement is used to instruct ESP to look at a scheduled activity data
set to resolve an External job dependency. ESP automatically selects the job if it is
found.
Syntax The syntax of the RESOLVE statement is:
RESOLVE identifier
identifier Indicates a one to eight character internal identifier of a
scheduled activity data set. This corresponds to the
SADLINK Initialization Parameter.
Usage notes ESP can use a scheduled activity data set (SAD file) to resolve external
dependencies. If ESP finds the job is scheduled, it selects the External job as part of
the Application. Otherwise, it doesnt select the External job.
The SADLINK statement gives an external SAD file an internal identifier. Each
time ESP initializes, or in response to a SADLOAD command, the contents of the
SAD file is read and necessary information retained in a table in main storage. You
can request that the look-up table be used to resolve External job dependencies by
specifying the correct SADLINK identifier on the RESOLVE statement in an
Application.
A more commonly used method to control the resolution of External jobs is to use
the EXTERNAL and SCHEDULED parameters on the JOB statement, as this
provides the most control for synchronizing Applications.
Related
information
SADLINK command.
For information on refreshing an in-core table containing a scheduled activity data
set, see the SADLOAD command.
For information on displaying current SADLINK, see the LISTSADL command.
For information on building inter-Application dependencies, see the EXTERNAL
statement.
589
RESOLVE Statement, Continued
Example 1 The following RESOLVE statement is used to resolve an external dependency:
APPL PAYROLL
RESOLVE SADDLY
JOB PAYJOBX EXTERNAL
REL PAYJOB1
JOB PAYJOB1
REL PAYJOB2
RUN DAILY
JOB PAYJOB3
RUN DAILY
ENDJOB
In the above example, the RESOLVE statement instructs ESP to look at the
scheduled activity data, with the identifier SADDLY, to see if PAYJOBX is
scheduled. If PAYJOBX is found, ESP selects PAYJOBX as part of the
Application. Otherwise, it doesnt select the External job.
590
RESOURCE Statement
Overview The RESOURCE statement is used to identify resources required by individual jobs
or by an entire Application. An individual job or Application can request any
number of resources. You can use resources for any type of workload object except
links.
Syntax The syntax of the RESOURCE statement is:
RESOURCE {resname1[,resname2]}
{(count,resname1[,count,resname2]...)}
{ADD(count,resname1[,count,resname2]...)}
{DROP(resname1[,resname2])}
resname Indicates a resource name using up to eight alphanumeric
characters. Has a default value of 1.
count,resname Indicates the number of units of the resource required by the
job or Application. Resname can be specified with or without
a count. If no count specified, the default is 1.
ADD Indicates this resource requirement is in addition to the
existing resource requirements. A count and the resource
name must also be used when specifying ADD.
DROP(resname) Indicates the resource requirement be dropped. When
specified within a JOB...ENDJOB pair, the resource
requirement is dropped only for that job. When specified
outside a JOB...ENDJOB pair, the resource requirement is
dropped until the next occurrence of the RESOURCE
statement outside a JOBENDJOB pair.
591
RESOURCE Statement, Continued
Usage notes The RESOURCE statement contains the number of units of a specific resource that a
job requires followed by the resource name.
If you want to request more than one resource for a job, string your resource
specifications together. If your specification of a jobs resource requirements takes
up more than one line, you should use the hyphen or plus sign + as line
continuation characters.
When you use a RESOURCE statement within an Application definition to provide
specific resource information for an individual job, you place the statement between
the JOB ... ENDJOB pair. The RESOURCE statement then affects only that
individual job. It also overrides any resources that occur before the JOB...ENDJOB
pair. Use the ADD keyword in this situation.
If the RESOURCE statement is specified outside the scope of a JOB...ENDJOB
pair, the RESOURCE statement applies to the jobs that follow it, until a new
RESOURCE statement occurs outside the scope of a JOBENDJOB pair.
The resource requirements apply to all jobs and tasks but not to links. Jobs inserted
into an Application after it is generated do not inherit any resource requirements.
Once default resources are turned on, every Application generated by ESP uses
default resources. You do not drop ESP default resource requirements with the
DROP keyword. To drop a default resource, request zero units of the resource. For
example:
The resource information defined to a job is used for scheduling and during
MODEL processing.
Related
information
For information on specifying the relative priority of jobs within an ESP group, see
the PRIORITY statement.
For information on specifying default resources, see the RESDFLT command.
For information on defining resources, see the RESDEF command.
Example 1 The following RESOURCE statement identifies a resource requirement for a
specific job:
APPL PAYROLL
JOB PAYJOB1
RUN WORKDAYS
RESOURCE (1,CICS)
ENDJOB
In the above example, PAYJOB1 requires 1 unit of a resource called CICS.
592
Example 2 The following RESOURCE statements identify resource requirements:
APPL PAYROLL
JOB PAYJOB2
RUN WORKDAYS
REL PAYJOB3
RESOURCE (1,IMS)
JOB PAYJOB3
RUN WORKDAYS
RESOURCE (1,T3480,2,SCRATCH)
ENDJOB
PAYJOB2 requires 1 unit of a resource called IMS
PAYJOB3 requires 1 unit of a resource call T3480 and 2 units of a resource
called SCRATCH.
Example 3 The following RESOURCE statements identify resource requirements on specific
days:
APPL PAYROLL
JOB PAYJOB4
RUN WORKDAYS
REL PAYJOB5
RESOURCE (1,NITESHFT)
IF TODAY(FRIDAY) THEN RESOURCE DROP(NITESHFT)
ENDJOB
In the above example, PAYJOB4 requires 1 unit of a resource called NITESHFT,
except on Fridays when resource requirements for PAYJOB4 are dropped.
Example 4 The following RESOURCE statement drops a default resource for an Application:
APPL PAYROLL
RESOURCE (0,ELAPSED)
JOB PAYJOB5
RUN WORKDAYS
REL PAYJOB6
JOB PAYJOB6
RUN WORKDAYS
REL PAYJOB7
JOB PAYJOB7
RUN WORKDAY
ENDJOB
In the above example, the RESOURCE statement instructs ESP not to assign the
default resource called ELAPSED for any job within the PAYROLL Application.
593
Example 5 The following RESOURCE statement drops a default resource and identifies a
resource requirement:
APPL PAYROLL
JOB PAYJOB8
RUN WORKDAYS
RESOURCE (0,ELAPSED,1,LOWPRIO)
ENDJOB
In the above example, the RESOURCE statement instructs ESP not to assign the
default resource called ELAPSED to PAYJOB8. PAYJOB8 requests 1 unit of a
resource called LOWPRIO.
594
RESREFR Command
Overview The RESREFR command is used in conjunction with real resources, for example
tape devices, to refresh the device list if tape devices are added or deleted
dynamically.
Authority OPER authority is required to issue the RESREFR command.
Syntax The syntax of the RESREFR command is:
RESREFR
Usage notes RESREFR refreshes resource status, alleviating problems with jobs going into a
RESWAIT status when resources are available. For example, if a job is waiting for
a tape drive, and a tape drive is varied online, ESP does not see this, RESREFR
refreshes the device list so that jobs do not unnecessarily wait.
Related
information
For information on defining resources, see the RESDEF command.
Example 1 The following RESREFR command refreshes resource status:
OPER RESREFR
In the above example, the device list is refreshed with any dynamically added or
deleted tape devices. Any jobs waiting for an available resource have their
RESWAIT status refreshed.
Note: Automate the process by which resource status is refreshed by defining an
Event at regular intervals to issue the RESREFR command, as follows:
EVENT ID(CYBER.RESOURCE_REFRESH)
SCHEDULE EVERY 10 MINUTES
VS F ESP,RESREFR
ENDDEF
595
RESTART Command
Overview The RESTART command is used to take ESP out of the quiesced state, restarting
Event scheduling and Application processing.
Authority OPER authority is required to issue the RESTART command.
Syntax The syntax of the RESTART command is:
RESTART
Usage notes Use the RESTART command after ESP has been quiesced using the QUIESCE
command or the QUIESCE start-up option.
When Event scheduling is restarted, ESP acts as if it was down for the entire time it
was in the quiesced state. That is, Events scheduled to execute while ESP was
quiesced are considered to be overdue. The overdue parameter of each overdue
Event is examined to determine whether it should be executed or bypassed.
Related
information
For information on putting ESP into a quiesced state, see the QUIESCE command.
For information on displaying the current ESP processing status, see the STATUS
command.
Example 1 The following RESTART command restarts Event scheduling and Application
processing:
OPER RESTART
In the above example, ESP is restarted, which is displayed using the STATUS
command as follows:
OPER STATUS
ESP1978I EVENT SCHEDULING ACTIVE
In the above example, Event scheduling and Application processing are active as
noted by the ESP1978I message - EVENT SCHEDULING ACTIVE.
596
RESTORE Command
Overview The RESTORE command is used to restore the Event, History, Userdef, Index and
Job index data sets. The RESTORE command restores an ESP data set from the
backup copy of its most current state using journalled SMF entries.
Syntax The syntax for the RESTORE command is:
RESTORE {EVENTSET(dsname)}
{INDEX(dsname)}
{USERDEF(dsname)}
{JOBINDEX(dsname)}
{HISTFILE(dsname)}
BACKUP(bkupdsname)
SMFID(smfno)
[NEWDSNAME(newdsn)]
[FROMTIME(schedule)]
EVENTSET Indicates the name of an Event data set.
INDEX Indicates the name of the Index data set.
USERDEF Indicates the name of the User Definition data set.
JOBINDEX Indicates the name of the Job Index data set.
HISTFILE Indicates the name of a History data set.
dsname Indicates the data set name of file to be restored.
bkupdsname Indicates the data set name of most current backup from
which the file is to be restored.
smfno Indicates the record number used for journalling updates to
SMF file. This corresponds to your SMFREC Initialization
Parameter.
newdsn Indicates an optional data set name of an existing empty
VSAM file where the data set is restored. This data set must
have the same attributes as dsname.
schedule Any valid schedule statement. If the statement contains
separators, it must be enclosed in quotes. If specified, this
time is used instead of the backup file time.
Usage notes This command can be used only if you are journalling updates to the file you wish to
restore.
597
RESTORE Command, Continued
Related
information
For information on restoring ESP data sets, see the ESP Workload Manager
Installation Guide and the ESP Workload Manager Diagnostics and Recovery
Guide.
Example 1 The following is an example of JCL that could be used to restore an ESP data set:
//RESTORE JOB
//STEP01 EXEC PGM=ESP,PARM='SUBSYS(ESPM)'
//STEPLIB DD DSN=CYB2.ESP510.SSCPLINK,DISP=SHR
//JOURNAL DD DSN=SYS1.SMF.BACKUP(0),DISP=SHR
// DD DSN=SYS1.SMF.BACKUP(-1),DISP=SHR
//SYSIN DD *
UTIL
RESTORE HISTFILE('CYB2.ESP510.HISTFILE') +
NEWDSNAME('CYB2.ESP510.NEW.HISTFILE') +
BACKUP('CYB2.ESP510.BACKUP.HISTFILE') +
SMFID(240)
/*
In the above example, the restore processor merges all of the history file updates
with the last HISTFILE backup and produces a new, up-to-date version of the
history file.
598
RESUME - Event Level
Overview When used in an Event definition, the RESUME command is used to decrement the
suspend count associated with an Event at a particular time. When the suspend
count reaches zero, the Event is eligible for execution.
Syntax The syntax of the RESUME command is:
RESUME criteria
Usage notes The RESUME command is used in conjunction with the SUSPEND command to
If you are using a time zone on your SUSPEND command, you should use the same
time zone on your RESUME command. If the Event has a schedule statement, the
same time zone should be used on the SCHEDULE, SUSPEND and RESUME
commands.
Related
information
For information on suspending an Events execution, see the SUSPEND command.
For information on decrementing an Events hold count, see the RELEASE
command.
599
RESUME - Event Level, Continued
SUSPEND DAILY AT 9AM
RESUME DAILY AT 11AM
ENDDEF
In the above example, SUSPEND and RESUME commands are used to prevent
PAYJOB1 from being submitted between 9 am and 11 am. If a data set trigger
happens between these times, ESP ignores it.
EVENT ID(CYBER.TIMEMSG)
SCHEDULE WORKDAYS HOURLY ROUND STARTING TODAY
SEND THE TIME IS %ESPATIME U(CYB01)
SUSPEND 16:01 WORKDAYS
RESUME 7:59 WORKDAYS
ENDDEF
In the above example, SUSPEND and RESUME commands are used to send a
message between 8 am and 4 pm on workdays.
600
RESUME - General
Overview The RESUME command is used to decrement the suspend count associated with an
Event. When the suspend count reaches zero, the Event is eligible for execution.
Syntax The syntax of the RESUME command is:
RESUME eventid
eventid Indicates a valid Event name. If no prefix is specified, the
prefix as set by the GROUP command is used.
Usage notes The specified Event has its SUSPEND count decremented immediately.
Note:
Related
information
For information on suspending an Events execution, see the SUSPEND command.
For information on decrementing an Events hold count, see the RELEASE
command.
Examples 1 The following RESUME command resumes an Event:
RESUME CYBER.PAYROLL
In the above example, CYBER.PAYROLL was previously suspended and is now
eligible for execution, if the suspend count was at 1. Otherwise, the suspend count
was decrement by 1.
601
REXXOFF Statement
Overview The REXXOFF statement is used to turn REXX processing off.
Type CLANG statement.
Syntax The syntax of the REXXOFF statement is:
REXXOFF
Usage notes To add REXX expressions to ESP, you must turn REXX on and off using CLANG.
CLANG is always present as the primary command language in ESP.
Related
information
For information on turning REXX processing on, see the REXXON statement.
For information on using REXX with ESP, see the ESP Workload Manager
Example 1 The following REXXON and REXXOFF statements turn REXX processing on and
off:
APPL PAYROLL
REXXON GEN
DO I=1 TO 10
"JOB PAYJOB"I
" RUN ANY"
IF I <> 10 THEN " RELEASE PAYJOB"I+1
"ENDJOB"
END
REXXOFF
In the above example, REXX is turned on from ESP to generate an Application
consisting of 10 sequential jobs, and then REXX is turned off.
602
REXXON Statement
Overview The REXXON statement is used to turn REXX processing on by invoking the
REXX interpreter. When ESP encounters a REXXON statement, it reads the REXX
procedural statements until it encounters a REXXOFF statement.
Type CLANG statement
Syntax The syntax for the REXXON statement is:
REXXON [GEN|NOGEN]
[PROC|NOPROC]
GEN Indicates that REXX processing is active during Application
generation mode. This is the default. Use this option if you
are using REXX to generate your Application.
NOGEN Indicates that REXX processing is not active during
Application generation mode.
PROC Indicates that REXX processing is active during Application
process mode. This is the default. Use this option if you are
using REXX to process you Application.
NOPROC Indicates that REXX processing is not active during
Application process mode.
Usage notes To add REXX expressions to ESP, you must turn REXX on and off using CLANG.
CLANG is always present as the primary command language in ESP.
You can activate REXX processing at either the generation or processing stages of
an Application. To invoke or suppress REXX processing at either the generation or
processing stage of an Application, enter the GEN or PROC keywords after the
REXXON statement as follows:
Type REXXON GEN PROC or REXXON to turn on REXX in the generation and
processing stages of an Application.
Type REXXON GEN to turn on REXX in the generation stage only.
Type REXXON PROC to turn on REXX in the processing stage only.
Related
information
For information on using REXX with ESP, see the ESP Workload Manager
For information on turning REXX processing off, see the REXXOFF statement.
603
REXXON Statement, Continued
Example 1 The following REXXON statement turns REXX processing on:
REXXON
SAY THIS IS REXX SPEAKING
REXXOFF
In the above example, REXX is turned on from ESP to send a message back to your
terminal and then turned off again.
Example 2 The following REXXON statement turns REXX processing on and returns
information about a job on the CSF:
REXXON
NUM=JOBONCSF(PAYJOB1,'X')
SAY 'THERE ARE ' NUM 'OCCURENCES OF JOB ' JOBNAME()
DO I=1 TO NUM
SAY JOBNAME() 'IS IN APPL ' XAPPL.I
END
REXXOFF
In the above example, ESP turns on REXX to return information about a job
currently on the CSF.
Example 3 The following REXXON statement turns REXX processing on to generate an
Application:
APPL PAYROLL
REXXON GEN
DO I=1 TO 10
"JOB PAYJOB"I
" RUN ANY"
IF I <> 10 THEN " RELEASE PAYJOB"I+1
"ENDJOB"
END
REXXOFF
In the above example, REXX is turned on from ESP to generate an Application
consisting of 10 sequential jobs.
604
REXXON Statement, Continued
Example 4 The following REXXON statement turns REXX processing on and defines special
days:
REXXON
ALLOCX DA(CYB01.DATES) F(MYINDD) SH
if rc \= 0 then
do
REEXEC IN(1)
EXIT
end
address MVS EXECIO * DISKR MYINDD (STEM LINE. FINIS
do i=1 to line.0
Date=line.i
ESP DEFSPEC PAY_DAY ON(Date) CAL(PAYROLL)
end
FREEX FILE(MYINDD)
REXXOFF
In the above example, REXX is turned on from ESP to read each line of a data set
containing dates and then issue the DEPSPEC command for the specified dates.
605
ROSSUB Command
Overview The ROSSUB command is used to submit JCL from a ROSCOE data set to the
internal reader.
Syntax The syntax of the ROSSUB command is:
ROSSUB dsname
dsname Indicates a valid ROSCOE data set name. You do not have to
specify ROS- as a data set identifier because using the
ROSSUB command implies the use of a ROSCOE data set. If
you omit the ROSCOE prefix from the data set name, ESP
uses the ROSCOE prefix of the user defining the Event.
Usage notes The ROSSUB command submits JCL from a ROSCOE data set into the internal
reader. Several ROSCOE commands may be specified in a single Event. The input
data are effectively concatenated together, so that data from several data sets can be
joined to form one or more jobs. In the same Event you can also use the ESP
SUBMIT command and submit JCL from LIBRARIAN and PANVALET data sets.
You can also use the ROSSUB command in an ESP Procedure.
Related
information
For information on submitting JCL from an Event see, Processing ESP Events in the
ROSCOE data set:
EVENT ID(CYBER.ROSJOBS)
ROSSUB RDS.JOBS
ENDDEF
In the above example a ROSCOE data set is submitted at 9 am on the first Monday
of the month.
606
ROUTE Statement
Overview The ROUTE statement is used to insert a /*ROUTE statement in a jobs JCL. This
routes a job to a different node for execution.
Syntax The syntax of the ROUTE statement is:
ROUTE XEQ(nodename)
nodename Indicates a one to eight character JES node name to where
this job is routed for execution.
Usage notes If you use the ROUTE statement to route a job to another JES node, you should
ensure there is tracking data being sent between the two nodes. Check with your
ESP system administrator before using this feature.
Another method for routing jobs to other nodes is to use ESP Resources. Using this
feature, ESP automatically inserts the appropriate routing information to ensure jobs
are routed to the required JES node.
Related
information
For information on routing jobs to other JES nodes, see the ESP Workload Manager
For information on routing jobs to other JES nodes using ESP Resources, see the
For information on inter-system tracking, see the TP Server Installation and Users
Guide.
607
ROUTE Statement, Continued
Example 1 The following ROUTE statement routes a job to another JES node:
APPL PAYROLL
JOB PAYJOB1
RUN DAILY
REL PAYJOB3
JOB PAYJOB2
RUN DAILY
REL PAYJOB3
ROUTE XEQ(NODE2)
JOB PAYJOB3
RUN DAILY
RELCOUNT 1
ENDJOB
In the above example, ESP adds a /*ROUTE card to the JCL it submits for
PAYJOB2 to route it to NODE2.
608
RUN Statement
Overview The RUN statement is used to identify a jobs schedule frequency. ESP allows
multiple RUN statements for the same job.
Syntax The syntax of the RUN statement is:
RUN criteria
criteria The schedule criteria must resolve to a single date and time
when the Application builds.
Usage notes The RUN statement is equivalent to the following:
IF TODAY(criteria) THEN SELECT job.
In order for a job to be selected for submission, either a RUN, SELECT, PREREQ,
POSTREQ or COREQ statement is required.
The RUN statement can not be used in conjunction with the following scheduling
terms: EVERY, UNTIL, ENDING, TOMORROW, YESTERDAY and STARTING.
The schedule criteria must resolve to a single date and time when the Application
builds.
If a job has a time dependency for submission, you must use either an EARLYSUB
or a DELAYSUB statement. The statement RUN 5PM DAILY is not valid.
Use the NORUN statement to cause a job not to be scheduled. When both RUN and
NORUN statements for a job are encountered, the last one which applies overrides.
Normally, the NORUN statement should follow your RUN statement.
RUN statements are used within the scope of a JOB statement. This allows you to
look at a job definition and see the schedule frequency for the job. Many criteria can
be handled with RUN statements without the need for using IF TODAY type
logic.
609
RUN Statement, Continued
Related
information
Users Guide.
For information on selecting jobs for submission, see the SELECT, POSTREQ,
PREREQ and COREQ statements.
For information on deselecting jobs for submission, see the NORUN and
DESELECT statements.
Example 1 The following RUN statement selects a job for submission:
APPL PAYROLL
JOB PAYJOB1
RUN WORKDAYS
ENDJOB
In the above example, PAYJOB1 is selected for submission on workdays.
Example 2 The following RUN statements identify when each job is selected for submission:
APPL PAYROLL
JOB PAYJOB2
RUN DAILY
REL PAYJOB3
JOB PAYJOB3
RUN FRIDAY
ENDJOB
In the above example, PAYJOB2 is selected for submission every day and
PAYJOB3 is selected for submission on Fridays.
Example 3 The following RUN statements identify when a job is selected for submission:
APPL PAYROLL
JOB PAYJOB4
RUN MONDAY
RUN 1ST WORDKAY OF MONTH
ENDJOB
In the above example, PAYJOB4 is scheduled for submission on Mondays and on
the first workday of each month.
610
Example 4 The following RUN statements identify when a job is selected for submission:
APPL PAYROLL
JOB PAYJOB5
RUN MONDAY
NORUN 1ST WORKDAY OF MONTH
ENDJOB
In the above example, PAYJOB5 is scheduled for submission on Mondays, except
on the first workday of the month.
Example 5 The following RUN statement is used in conjunction with IF logic to identify when
a job is selected for submission:
APPL PAYROLL
JOB PAYJOB6
IF TODAY('LAST WORKDAY OF MONTH') AND -
TODAY('NOT LAST WORKDAY OF WEEK') THEN RUN TODAY
ENDJOB
In the above example, PAYJOB6 is scheduled for submission if today is the last
workday of the month, but not if it is the last workday of the week.
Example 6 The following RUN statement identifies when a job is selected for submission:
APPL PAYROLL
JOB PAYJOB7
RUN 5TH DAY OF MONTH PLUS 0 WORKDAYS
ENDJOB
In the above example, PAYJOB7 is scheduled for submission on the 5
th
day of each
month. If the 5
th
day of the month is not a workday, PAYJOB7 is selected for
submission on the first workday after the 5
th
day of the month.
611
Example 7 The following RUN statement is used in conjunction with IF logic, a built-in
function and a user-defined symbolic variable to identify when a job is selected for
submission:
APPL PAYROLL
JOB PAYJOB8
INTEGER X
X=DAYS_FROM(JANUARY 1,1999)
IF X//14*14=X THEN DO
RUN TODAY
NORUN HOLIDAY
ENDDO
ENDJOB
In the above example, PAYJOB8 is scheduled for submission every 14 days, after
January 1
st
, 1999, except if it is a holiday.
Example 8 The following RUN statement is used in conjunction with IF logic, a built-in and a
user defined symbolic variables to identify when a job is selected for submission:
APPL PAYROLL
GENTIME A LAST DAY OF MONTH STARTING TODAY
GENTIME B LAST SUN OF MONTH STARTING TODAY
GENTIME C LAST SAT OF MONTH STARTING TODAY
JOB PAYJOB9
IF %ADATE NE %BDATE THEN -
RUN %ADATE
ELSE -
RUN %CDATE
ENDJOB
In the above example, PAYJOB9 is selected for submission on the last day of the
month, if the last day of the month is not the last Sunday of the month. If the last
day of the month is the last Sunday of the month, then PAYJOB9 is selected for
submission on the last Saturday of the month.
612
SADGEN Command
Overview The SADGEN command is used to generate a data set, which is used in the creation
of scheduled activity reports. It must be executed through the ESP subsystem started
task Procedure with a special parm (PARM=SAR or PARM=SAD).
Syntax The syntax of the SADGEN command is:
SADGEN DATASET(sardb)
[FROM(schedule)]
[TO(schedule)]
[LOGICALDAYSTART(starttime)]
[CARRYOVER(codsn)]
[EVENTSET(evdb)]
[LEVEL(prefix)]
[CLASS(classname[,classname]...)]
[THRESH(mins)]
[TRACE]
[JCLOUT(jcldsn)]
[JOBCLASS(jobclass)]
[MSGCLASS(msgclass)]
[RMGRDATA(string[,string]...)]
[NOHIST]
sardb Indicates the name of the data set to store scheduled activity
information.
schedule Indicates valid schedule criteria. If the statement contains
separators then it must be enclosed in quotes. The keywords
ENDING or UNTIL can be used to restrict the time range
selected. Defaults are from now to 6 am tomorrow. You
cannot specify a time in the past; you can only specify a time
in the future. The start time for a SADGEN run is the later of
the start time specified in the SADGEN command and the
time at which the command is processed.
starttime Indicates a valid schedule statement. If the statement
contains separators, it must be enclosed in quotes. The
LOGICALDAYSTART keyword specifies the start time of
your logical processing day; it should match the one specified
on your calendar. This keyword is not required unless you
use logical day processing.
codsn Indicates the name of a previously scheduled activity data set
(data set name or DD name) whose outstanding jobs are to be
merged with the sardb data set.
613
SADGEN Command, Continued
Syntax (continued)
evdb Indicates the name of one or more Event databases that
should be scanned to generate scheduled activity data.
Asterisks and a hyphen may be used for masking. The default
is to scan all existing Event data sets.
prefix Indicates an Event group prefix. Asterisks and a hyphen may
be used for masking.
classname Indicates one or more ESP Event class names. Separate each
with a comma. Asterisks and a hyphen may be used for
masking.
mins Indicates a threshold in minutes. Any Event that executes
more frequently than this threshold interval is not simulated.
The default is 120.
TRACE Displays all the commands that ESP simulates to create the
scheduled activity database.
jcldsn Indicates the name of a sequential data set where the JCL for
each job generated by the SADGEN is stored.
jobclass Indicates a one-character alphanumeric jobclass to be
assigned to each job written to the JCLOUT data set.
msgclass Indicates a one-character alphanumeric msgclass to be
assigned to each job written to the JCLOUT data set.
string Indicates a quoted string or list of strings that is inserted as
the first step to each job written to the JCLOUT data set.
NOHIST Indicates job history data is not retrieved when creating the
scheduled activity data set. This keyword should be specified
only if you are not using ESPs job tracking facility.
614
Usage notes To generate data used for scheduled activity reporting, ESP must simulate all the
Events and ESP Procedures it is to execute in a specified period. ESP does this by
executing the ESP subsystem started task procedure in batch with a special
parameter (PARM=SAR or PARM=SAD). The output that ESP generates by this
simulation forms a scheduled activity data set.
The default space requirement for the SADGEN data set is 10 primary cylinders and
5 secondary cylinders. To change these defaults, specify SADGEN(p,s) where p is
the number of primary cylinders and s, the number of secondary cylinders. For
example: PARM=SAD(25,10) results in SPACE=(CYL,(25,10)).
ESP does not reflect an Event in the scheduled activity data set unless it contains
either a SCHEDULE or EXPECT command.
You can also create multiple schedule activity data sets. You may want to generate
separate data sets on scheduled activity for the next day or for the next week, or you
may want different data sets for different production groups.
When a scheduled activity data set is generated, it contains a record for each job that
is submitted within the time range you have specified. If a time range is not
specified, the default provided is from NOW to 6AM TOMORROW. Data is
stored in alphabetical sequence by job name and is displayed using the LSAR
command.
A sequential data set must be allocated before using the SADGEN command to
write data to it.
The scheduled activity data set may be used for reporting, modeling, or to resolve
External dependencies.
Use of the EVENTSET, LEVEL and CLASS keywords, allows you to select and
control the scheduled activity data you want to be stored. The THRESH option
allows you to change the frequency of Events to be simulated. The TRACE option
is used to verify all of the functions that each Event or ESP Procedure performs
when it is scheduled.
615
Related
information
Users Guide.
Guide.
For information on extracting data from the scheduled activity data set, see the
LSAR command.
For information on updating a scheduled activity data set with actual information,
see the SADUPD command.
SADLINK command.
Example 1 The following is an example of JCL that can be used to produce a scheduled activity
data set:
//jobname JOB
//STEP1 EXEC ESP,PARM=SAR
//SYSIN DD *
SADGEN DATASET(CYBER.SAD) -
FROM(8AM TODAY) TO(8AM TOMORROW)
/*
In the above example, the SADGEN command generates a scheduled activity data
set. CYBER.SAD contains information on all Events scheduled or expected to
execute between 8 am today and 8 am tomorrow.
activity data set:
//jobname JOB
//SYSIN DD *
FROM(8AM TODAY) TO(8AM PLUS 1 WEEK) -
EVENTSET(EVENT1) -
LEVEL(PROD-)
/*
In the above example, the SADGEN command scans the EVENT1 Event data set to
generate a scheduled activity data set. CYBER.SAD contains information on all
Events beginning with PROD, which are scheduled or expected to execute between
8 am today and 8 am next week.
616
Example 3 The following is an example of JCL that could be used to produce a scheduled
activity data set:
//jobname JOB
//SYSIN DD *
FROM(8AM TODAY) TO(8AM TOMORROW) -
THRESH(60)
/*
set. CYBER.SAD contains information on Events that are scheduled between 8 am
today and 8 am tomorrow. Events that are scheduled more frequently than once an
hour are not included.
617
SADLINK Command
Overview The SADLINK command is used to assign an identifier to a scheduled activity data
set for resolving External job dependencies. Normally the SADLINK command is
used as an Initialization Parameter.
Authority OPER authority is required to issue the SADLINK command.
Syntax The syntax of the SADLINK command is:
SADLINK identifier
DATASET(dsname)
[GROUP(groupname)]
identifier Indicates an internal identifier of a scheduled activity data set.
Up to eight alphanumeric characters are allowed.
dsname Indicates the name of a sequential data set used for storing
scheduled activity data.
groupname Indicates the owning group. Any user who has either
operator authority or update access to the owning group can
issue a SADLOAD command to refresh the in-core table.
This applies only if you are using ESPs internal security.
Usage notes The SADLINK command assigns an identifier to a SAD (schedule activity data set)
file. Each time ESP initializes, or in response to a SADLOAD command, the
contents of the SAD file are read and information stored in a main-storage table. To
request this table be used to resolve External job dependencies, specify the
SADLINK identifier on the RESOLVE statement in an Application.
Related
information
For information on generating a scheduled activity data set, see the SADGEN
command.
For information on identifying a scheduled activity data set at the Initialization
Parameter level, see the ESP Workload Manager Installation Guide.
618
SADLINK Command, Continued
Example 1 The following SADLINK command identifies a scheduled data set:
SADLINK SAD1 DATASET(CYBER.SAD)
In the above example, CYBER.SAD is assigned an internal identifier of SAD1. No
owning group is specified.
Example 2 The following SADLINK command identifies a scheduled data set:
SADLINK SAD2 DATASET(CYBER.SAD) GROUP(PROD)
In the above example, CYBER.SAD is assigned an internal identifier of SAD2.
PROD is identified as the owning group.
619
SADLOAD Command
Overview The SADLOAD command is used to refresh a table containing scheduled activity
data set (SAD) information. It should be used whenever there is an update to the
SAD file. You can automatically issue the SADLOAD command in batch following
the generation of the SAD file.
Authority OPER authority is required to issue the SADLOAD command. A user with update
access to the owning group (as specified in a SADLINK command) is also
authorized.
Syntax The syntax of the SADLOAD command is:
SADLOAD identifier
identifier Indicates the internal identifier of a scheduled activity data
file (SAD file), as identified by a SADLINK command.
Usage notes The SADLOAD command causes the contents of the specified SAD file to be read
and the necessary information stored in a table in main-storage. You can request
that the look-up table be used to resolve External job dependencies by specifying the
correct SADLINK identifier on the RESOLVE statement in an ESP Procedure. The
SADLOAD command should be issued whenever the SAD file is updated.
Related
information
For information generating a scheduled activity data set, see the SADGEN
command.
SADLINK command.
620
SADLOAD Command, Continued
Example 1 The following SADLOAD command refreshes the in-core table:
OPER SADLOAD SAD1
In the above example, the in-core table containing scheduled activity information is
refreshed.
activity data set and issue a SADLOAD command. In this example the name of the
ESP started task is ESP, the name of the ESP subsystem is ESPM:
//jobname JOB
//SYSIN DD *
FROM(8AM TODAY) TO(8AM TOMORROW)
//STEP2 EXEC PGM=ESP,PARM=SUBSYS(ESPM),COND=(0,NE)
//SYSIN DD *
SADLOAD SAD1
/*
set CYBER.SAD. It contains information on all Events that are scheduled or
expected to execute between 8 am today and 8 am tomorrow. STEP2 defines an
automatic SADLOAD command that occurs whenever the ESP command processor
executes.
621
SADUPD Command
Overview The SADUPD command is used to update a scheduled activity data set with actual
information. It must be executed through the ESP subsystem started task Procedure
with a special parm (PARM=SAR or PARM=SAD).
Syntax The syntax of the SADUPD command is:
SADUPD [DATASET(sardb)]
sardb Indicates the name of a scheduled activity data set previously
created using the SADGEN command. It does not need to be
enclosed in quotes.
Usage notes Note that unlike the SADGEN command, only the DATASET keyword is required
for SADUPD. The updated scheduled activity data set can be displayed using the
STATUS keyword on the LSAR command.
The scheduled activity update feature provides you with actual start and end times
for jobs.
Related
information
For information on extracting data from the scheduled activity data set, see the
LSAR command.
Users Guide.
For information generating a scheduled activity data set, see the SADGEN
command.
Example 1 The following is an example of JCL that can be used to update the scheduled
activity data set:
//jobname JOB
//SYSIN DD *
SADUPD DATASET(CYBER.SAD)
In the above example, the scheduled activity information in CYBER.SAD is
updated. The name of the ESP started task is ESP.
622
SAFGRANT Command
Overview The SAFGRANT command is used to initialize or change access a user has to a SAF
resource. This command can be used only if you are using RACF as your security
product.
Syntax The syntax of the SAFGRANT command is:
SAFGRANT (userid1[,userid2]...)
(resource[,resource]...)
userid Indicates the user Id or RACF group to be PERMITed to the
resource specified. A list of user IDs can be specified.
resource Indicates the resource for which the PERMITs are issued. A
list of resources can be specified.
Usage notes Use the SAFGRANT command to initialize or change a users access to a resource.
This command simulates RACFs RDEFINE and PERMIT commands. ESP issues
the RDEFINE and PERMIT commands to complete the SAFGRANT request. You
can specify several user IDs and multiple resource names in a single SAFGRANT
command.
If you specify a resource you have not yet defined, ESP automatically defines the
resource for you. ESP knows the general classname and resource prefix, based on
the SAFCLASS Initialization Parameter. Therefore, do not specify these in the
SAFGRANT command. When ESP defines a resource in this way, it assigns
UACC(NONE) to the resource.
Related
information
For information on revoking access to SAF resources, see the SAFREVOK
command.
For information on identifying the SAF resource class at the Initialization Parameter
level, see the ESP Workload Manager Installation Guide.
623
SAFGRANT Command, Continued
Example 1 The following SAFGRANT command grants access to SAF resources:
SAFGRANT (DEV,SUPPORT,USR01) (ONLINE,GROUP.PAYROLL)
In the above example, RACF groups DEV and SUPPORT, and user USR01 are
granted read access to the ONLINE and GROUP.PAYROLL SAF resources.
624
SAFOPTS Command
Overview The SAFOPTS command is used to control processing options for the SAF
interface. This statement is normally included in the Initialization Parameter data
set.
Authority OPER authority is required to issue the SAFOPTS command.
Syntax The syntax of the SAFOPTS command is:
SAFOPTS [DSALLOC|NODSALLOC]
[MVSCMD|NOMVSCMD]
[UTOKEN|NOUTOKEN]
[SIM3RDPARTY|NOSIM3RDPARTY]
[MSGSUPP|NOMSGSUPP]
[OPERCMDS|NOOPERCMDS
DSALLOC Indicates ESP is to perform a SAF resource check before
dynamically allocating any data set. If the requestor does
not have at least read access to the DSALLOC.dsname
resource, where dsname is the name of the data set ESP is
allocating, the allocation fails. When ESP allocates the data
set on behalf of an Event, ESP uses the Events prefix for
the resource check. Otherwise, it uses its own user ID for
the resource check.
NODSALLOC Indicates ESP is not to perform a SAF resource check prior
to dynamically allocating any data set. This is the default.
MVSCMD Indicates ESP is to use the MVSCMD.cmdstring resource
when verifying an Events authority to execute an MVS
command.
NOMVSCMD Indicates ESP is to use the OPER resource instead of the
MVSCMD.cmdstring resource. This is the default.
625
SAFOPTS Command, Continued
NOMVSCMD (continued)
UTOKEN Indicates ESP performs a Third Party RACHECK using a
SAF user token. When a client makes a request, the host
system performs a SAF TOKEN EXTRACT in the clients
environment and passes the token to ESP (the server) for
verification. RACF 1.9 or higher supports SAF user tokens.
If you are using a different security product, ensure it
supports SAF TOKEN EXTRACT and Third Party
RACHECK.
NOUTOKEN Indicates ESP performs a Third Party RACHECK on the
user ID of the client. This is the default.
SIM3RDPARTY Indicates ESP simulates Third Party RACHECK processing
since the host security product does not support Third Party
RACHECK. Do not specify this option together with the
UTOKEN option.
NOSIM3RDPARTY Indicates ESP uses normal Third Party RACHECK
processing. This is the default.
MSGSUPP Indicates ESP suppresses violation messages when
performing a RACHECK. If a violation occurs, the security
system product tracks it internally.
NOMSGSUPP Indicates ESP issue violation messages. This is the default.
We recommend you use this option during testing.
OPERCMDS Indicates ESP is to use the OPERCMD.cmdname resource,
rather than the more general OPER resource, when
verifying a users authority to execute an ESP operator
command.
NOOPERCMDS Indicates ESP use the OPER resource instead of the
OPERCMD.cmdname resource. This is the default.
Usage notes You can use the SAFOPTS command to display the current SAF options. An
example is shown below.
Related
information
continued
For information on defining SAF options at the Initialization Parameter level, see the
ESP Workload Manager Installation Guide.
626
SAFOPTS Command, Continued
Example 1 The following SAFOPTS command displays SAF options:
OPER SAFOPTS
SAF Options: NoMsgSupp NoDsAlloc NoMvsCmd NoUToken NoSim3rdParty NoOperCmds
SAF Class: DSNR, Prefix ESP
In the above example, the current SAF options and the name of the SAF resource
class are displayed.
Example 2 The following SAFOPTS turns on message suppression:
OPER SAFOPTS MSGSUPP
In the above example, ESP suppresses violation messages when performing a
RACHECK.
627
SAFRDEF Command
Overview The SAFRDEF command allows you to define RACF resources for use with ESP.
This command can be used only if you are using RACF as your security product.
Syntax The syntax of the SAFRDEF command is:
SAFRDEF (resource1[,resource2]...)
[UACC(NONE|READ|UPDATE|ALTER)]
resource1 Indicates the resource to be defined. The resource classname
and optional resource prefix specified on the ESP
SAFCLASS statement are used to build the RDEFINE RACF
command. A list of resources to be defined can be specified.
UACC() Indicates the access for the user against the resource. NONE
is the default.
Usage notes The SAFRDEF command works by issuing RACF RDEFINE commands.
Related
information
Example 1 The following SAFRDEF command defines two SAF resources:
SAFRDEF (GROUP.OPS,GROUP.SUPPORT) UACC(READ)
In the above example, SAF resources GROUP.OPS and GROUP.SUPPORT, are
created, both with a Universal Access of READ.
628
SAFRDEL Command
Overview The SAFRDEL command is used to delete one or more SAF resources. This
command applies only if you are using RACF for ESP security.
Syntax The syntax of the SAFRDEL command is:
SAFRDEL(resource1[,resource2]...)
resource Indicates the resource to be deleted. The resource classname
and optional resource prefix specified on the ESP
SAFCLASS statement are used. A list of resources to be
deleted can be specified.
Related
information
Example 1 The following SAFRDEL command deletes a SAF resource:
SAFRDEL (GROUP.OPS)
In the above example, the GROUP.OPS resource is deleted.
629
SAFREVOK Command
Overview The SAFREVOK command is used to remove a RACF user or group from the
access list of a SAF resource. This command applies only if you are using RACF
for ESP security.
Syntax The syntax of the SAFREVOK command is:
SAFREVOK (userid1[,userid2]...)(resource1[,resource2]...)
userid Indicates the user ID or RACF group to have access revoked.
A list of user IDs can be specified.
Resource Indicates the resource against which access is to be revoked.
A list of resources can be specified.
Related
information
For information on granting access to resources, see the SAFGRANT command.
Example 1 The following SAFREVOK command revokes access to SAF resources:
SAFREVOK (DEV,SUPPORT,USR01) (ONLINE,GROUP.PAYROLL)
In the above example, RACF groups DEV and SUPPORT, and user USR01 are
revoked access to the ONLINE and GROUP.PAYROLL SAF resources.
630
SCAN Command
Overview The SCAN command is used to scan a JCL data set or member for valid ESP control
statement syntax. It can check what ESP submits at any time in the future. It can
also place a working copy of a jobs JCL into a work data set.
Syntax The syntax of the SCAN command is:
SCAN {dsname|*}
EVENT(eventid)
[PRINT(printdsn)]
[TRJOB(trjobname)]
[TRDSN(trdsname)]
[SCHED(schedtime)]
[JOB(jobname)]
[SYMBOL(symchar)]
[SYMLIB(sdsn[,sdsn]...)]
[TRUNIT(truname)]
[TRVOL(trvolser)]
[USER(userid)]
[GROUP(groupname)]
[CALENDARS(cal1[,cal2]...)]
[COPYJCL]
dsname Indicates the data set containing the JCL to be scanned.
* Indicates that input is to come from the SYSIN file.
eventid Indicates the name of the Event for the job.
printdsn Indicates the data set to which the JCL is copied. This data
set cannot be a PDS.
trjobname Indicates a jobname for a simulated data set trigger. The
jobname is that of the job creating the data set. The
trjobname parameter is passed to the ESPTRJOB symbolic
variable.
trdsname Indicates the name of a data set that causes a data set trigger.
The trdsname parameter is passed to the ESPTRDSN
symbolic variable.
schedtime Indicates the schedule time for the job. This can be any time
specification valid on a SCHEDULE statement. If it contains
separator characters (comma or blanks), enclose it in quotes.
jobname Indicates the name of the job to be displayed, if the data set
contains a concatenation of multiple jobs.
symchar Indicates a one-byte symbol-introducer character. It defaults
to %.
631
SCAN Command, Continued
Syntax (continued)
sdsn Indicates the name or names of data sets to be read for the
purposes of symbolic variable generation.
truname Indicates the generic device type on which the data set is
created causing a data set trigger. The truname parameter is
passed to the ESPTRUNI symbolic variable.
trvolser Indicates the volume serial of the device on which the data set
is created causing a data set trigger. The trvolser parameter is
passed to the ESPTRVOL symbolic variable.
userid Indicates the name of the defining user for this Event that is
passed to the ESPUSER symbolic variable.
groupname Indicates the current group name that is passed to the
ESPGROUP symbolic variable.
cal Indicates any required calendars to be retrieved for this Event
scan.
COPYJCL Indicates that the scan includes any JCL that is generated to
the COPYJCL data set (i.e. any JCL generated by
%INCLUDE/EXCLUDE logic).
Usage notes The SCAN command is used to:
Scan a data set or member to check any imbedded ESP control statements.
Retrieve a working copy of a previously submitted job.
Generate a working copy of a job to be submitted.
Once a JCL data set contains ESP control statements, that data set cannot be
submitted other than through ESP. This is because the ESP control statements cause
a JCL error. In case of ESP being unavailable, use the SCAN command in batch, to
generate a valid copy of the JCL and write the output to a data set. That data set can
then be submitted through other means.
632
SCAN Command, Continued
Example 1 The following SCAN command allows you to:
Search for ESP control statements within data sets and member of a PDS
Retrieve a working copy of a job that you want to submit
Write the output from the working copies of the jobs to a data set.
SCAN CYBER.JCL.CNTL(PAYJOB1) EVENT(CYBER.PAYROLL)
SCHED(24 MAY 2001) SYMLIB(ESP.SYMBOLS(MYSYM))
CYBER.JCL.CNTL(PAYJOB1) tells ESP where it can find the JCL for MYJOB
EVENT(CYBER.PAYROLL) is the Event that submits the job
SCHED(24TH MAY 2001) is the schedule criteria
SYMLIB (ESP.SYMBOLS(MYSYM)) contains symbol definitions for the job.
Note: If ESP is down you must run the SCAN command in batch. If ESP is up, you
can use any mode.
633
SCHEDULE Command
Overview The SCHEDULE command is used to define schedule criteria for an Event, which
generally includes a time and a frequency.
Syntax The syntax of the SCHEDULE command is:
{SCHEDULE|SCHED|SCH} criteria
[OVERDUE{(count)}]
[ONCE]
count Indicates an overdue count, a number from 0 to 10. Indicates
how many overdue occurrences of an Event are to be
scheduled when an Event misses its scheduled times, perhaps
after a system outage. The default is 1.
ONCE Indicates the specified schedule is executed only once.
Usage notes Specify as many SCHEDULE commands as you need for an Event. The Event is
executed at each time and date included in each schedule statement except for any
criteria specified on a NOSCHED command. If any times and dates from two or
more separate schedule statements coincide, the Event is executed only once at that
time.
An Event is considered to be overdue when something prevents it from executing at
its scheduled time. The following reasons can make an Event overdue:
A system outage
The Event is on hold
The Events class is on hold
Unavailability of Event initiator
ESP being placed in the quiesced state
The Event data set being suspended at the scheduled execution time.
The overdue count, set by the OVERDUE parameter, specifies how many overdue
occurrences of an Event are to be scheduled when normal scheduling is resumed.
The default setting for the overdue count is one. If a count of zero is set, the Event
is bypassed and executes at its next scheduled time.
Specify ONCE to request that the schedule statement is executed once only and is
then deleted. If, at that point, no more schedule elements exist and no data set
triggers are defined for the Event, the entire Event is scheduled for deletion 24 hours
later.
634
SCHEDULE Command, Continued
Related
information
Users Guide.
For information on defining when an Event will execute, see the ESP Workload
For information on specifying when an Event should not execute, see the
NOSCHED command.
Example 1 The following SCHEDULE command defines the schedule criteria for an Event:
INVOKE CYBER.PROCS.CNTL(PAYROLL)
ENDDEF
In the above example, CYBER.PAYROLL is scheduled for execution at 4 pm
workdays.
SCHEDULE 4PM WEEKDAYS
SCHEDULE 2PM WEEKENDS
ENDDEF
In the above example, CYBER.PAYROLL is scheduled for execution at 4 pm
weekdays and 2 pm on weekends.
SCHEDULE 8AM WORKDAYS
NOSCHED 8AM LAST WORKDAY OF MONTH
ENDDEF
In the above example, CYBER.PAYROLL is scheduled for execution 8 am
workdays, except at 8 am on the last workday of the month.
635
SCHEDULE 9AM 2ND-LAST DAY OF MONTH
ENDDEF
In the above example, CYBER.PAYROLL is scheduled for execution at 9 am from
the second day of the month to the last day of the month.
EVENT ID(CYBER.CMDS)
SCHEDULE 10AM WORKDAYS OVERDUE(0)
INVOKE CYBER.PROCS.CNTL(CMDS)
ENDDEF
In the above example, CYBER.CMDS is scheduled for execution 10 am workdays.
If CYBER.CMDS misses its schedule execution time it does not execute.
SCHEDULE EVERY 4 HOURS ROUND STARTING 8AM WEEKDAYS
ENDDEF
In the above example, CYBER.PAYROLL is scheduled for execution on weekdays
every 4 hours starting at 8 am.
SCHEDULE 8AM FEB21,1998 ONCE
ENDDEF
In the above example, CYBER.PAYROLL is scheduled at 8 am only on February
21
st
, 1998. The Event is scheduled for automatic deletion 24 hours after this time.
636
SCHEDULE 10PM FRIDAY
SCHEDULE 10PM LAST WORKDAY OF MONTH
ENDDEF
In the above example, CYBER.PAYROLL is scheduled for execution at 10 pm on
Fridays and on the last workday of the month. When the last workday of the month
is a Friday, the Event executes only once.
637
SECURE Statement
Overview The SECURE statement is used to secure any symbol.
Syntax The syntax of the SECURE statement is:
SECURE variable
variable Indicates the name of the secured symbolic variable.
Usage notes A secured symbol is one that contains sensitive data, such as a password, and
consequently requires additional security. ESP exerts control over secured symbols
based on how ESP processes the symbol.
These are some of the controls that ESP exerts on secured symbols:
ESP only produces the assigned values for JCL submitted to the internal reader
ESP does not produce the assigned values when writing JCL to a COPYJCL
library
SEND or VS subcommands do not produce the assigned values
You cannot assign a secured symbol to another symbol, i.e., a secured symbol
cannot appear to the right of the equal sign (=) in an assignment statement.
Related
information
For information on defining symbolic libraries, see the DEFSYML command.
Example 1 The following is an example of how to identify a secured symbol:
PASSWORD=OPEN
SECURE PASSWORD
In the above example, ESP resolves the symbolic %PASSWORD only when it
encounters the symbol in JCL it submits to the internal reader.
Note: These statements are coded in a symbolic variable library.
638
SELECT Statement
Overview The SELECT statement is used to identify that a job or subApplication should be
selected as part of an Application.
Syntax The syntax of the SELECT statement is:
SELECT {jobname|(jobname[,jobname])} [JOB|SUBAPPL]
jobname Indicates a jobname. Enclose multiple jobnames in
parentheses, separated by a blank or comma.
JOB Indicates a job is selected for submission. This is the default.
SUBAPPL Indicates all jobs within a subApplication are being selected
for submission.
Usage notes The SELECT statement must be used after you have defined your job. If the
SELECT statement is used for any job that has COREQ, POSTREQ or PREREQ
specified, the jobs that these statements refer to are selected automatically.
Differentiate between whether or not you want to select a job or subApplication
using the JOB or SUBAPPL keywords. JOB is the default.
Selecting a subApplication allows you to select a group of jobs with one statement
instead of selecting each job individually.
You cannot select a job and a subApplication using the same SELECT statement.
RUN statements are used within the scope of a JOB statement. This allows you to
look at a job definition and see the schedule frequency for the job. Many criteria can
be handled with RUN statements without the need for using IF TODAY type
logic.
SELECT statements allow you to easily see all the jobs with the same criteria.
Changing the criteria for these jobs requires a change to a single SELECT statement.
Related
information
For information on selecting jobs for submission, see the RUN, POSTREQ,
PREREQ and COREQ statements.
For information on deselecting jobs for submission, see the DESELECT statement.
639
SELECT Statement, Continued
Example 1 The following SELECT statement selects multiple jobs for submission:
APPL PAYROLL
JOB PAYJOB1
REL PAYJOB2
JOB PAYJOB2
ENDJOB
In the above example, PAYJOB1 and PAYJOB2 are selected for submission
whenever the PAYROLL Application is invoked.
Example 2 The following SELECT statement selects multiple jobs for submission on a specific
days:
APPL PAYROLL
JOB PAYJOB3
REL PAYJOB4
JOB PAYJOB4
ENDJOB
IF TODAY(WORKDAY) THEN SELECT (PAYJOB3,PAYJOB4)
In the above example, PAYJOB3 and PAYJOB4 are selected for submission on
workdays.
Example 3 The following SELECT statement selects a subApplication for submission:
APPL PAYROLL
SUBAPPL PREPJOBS
JOB PAYJOB5
REL PAYJOB6
JOB PAYJOB6
REL PAYJOB7
JOB PAYJOB7
REL PAYJOB8
JOB PAYJOB8
ENDJOB
SELECT PREPJOBS SUBAPPL
In the above example, the PREPJOBS subApplication is selected for submission
whenever the PAYROLL Application is invoked.
640
Example 4 The following SELECT statement selects multiple jobs for submission on a specific
days:
APPL PAYROLL
JOB PAYJOB5
REL PAYJOB6
JOB PAYJOB6
REL PAYJOB7
JOB PAYJOB7
ENDJOB
IF TODAY(WORKDAYS) THEN SELECT PAYJOB5
IF TODAY(WEDNESDAY) THEN SELECT PAYJOB6
IF TODAY(FRIDAY) THEN SELECT PAYJOB7
PAYJOB5 is selected for submission on workdays
PAYJOB6 is selected for submission on Wednesdays
PAYJOB7 is selected for submission on Fridays.
Example 5 The following statements are used to:
Select subApplications
Select a job within an Application
Deselect a subApplication
Deselect a job within an Application.
APPL PAYROLL
JOB ACCJOB1
SUBAPPL ACCPAY
ENDJOB
JOB ACCJOB2
SUBAPPL ACCPAY
ENDJOB
JOB BILJOB1
SUBAPPL BILLING
ENDJOB
JOB BILJOB4
SUBAPPL BILLING
ENDJOB
JOB PAYJOB10
ENDJOB
SELECT (ACCPAY,BILLING) SUBAPPL
SELECT PAYJOB10
IF TODAY(LAST WORKDAY OF MONTH) THEN DESELECT BILLING
SUBAPPL
IF TODAY(MONDAY) THEN DESELECT ACCJOB2
The ACCPAY and BILLING subApplications are selected
PAYJOB10 is selected
The BILLING subApplication is not selected on the last workday of the month
ACCJOB2 is not selected on Mondays.
641
Example 6 The following SELECT statement selects multiple jobs on specific days:
APPL PAYROLL
JOB PAYJOB8
REL PAYJOB9
JOB PAYJOB9
ENDJOB
IF TODAY(WORKDAYS) THEN SELECT (PAYJOB8,PAYJOB9)
IF TODAY(1ST WORKDAY OF MONTH) THEN DESELECT PAYJOB9
In the above example, PAYJOB8 and PAYJOB9 are selected for submission on
workdays. On the first workday of the month, PAYJOB9 is deselected for
submission.
642
SEND Command
Overview The SEND command is used to send a message to yourself, another user, a group of
users, or an operator console. By default, messages are sent now if a user is logged
on. If a user is not logged on, messages can be queued to the broadcast data set until
the user logs on.
Syntax The syntax of the SEND command is:
{SEND|SE} message text
[USER{(*)|(userid[,userid]...)}]
[CN(console)]
[OPER(routing code)]
[ROSPFX(rospfx[,rospfx]...)]
[NONDEL]
[NOW]
[SYSTEM(name)]
message
text
Indicates a message to be transmitted, enclosed within quotes. If
the message contains imbedded quotes, they should be doubled up.
The message can be up to 124 characters.
* Indicates the message is to be sent to the current user ID. This is
the default. USER can be abbreviated to U.
userid Indicates one or more TSO user IDs to whom the message is sent.
If a list of user IDs is specified, separate each one with a blank or
comma.
console Indicates the UCM ID of the console that is to receive the message.
routing code Indicates the MCS routing code for a message to be sent to one or
more operator consoles. Value between 1 and 128.
rospfx Indicates one or more ROSCOE users, identified by ROSCOE
prefix, to whom the message is sent. If a list of prefixes is
specified, separate each one with a blank or comma.
NONDEL Indicates the message is marked as non-roll-deletable, if it is
transmitted to a console.
NOW Indicates the message be sent now if the user is logged on. If the
user is not logged on, the message is not queued to the broadcast
data set.
name Indicates the name of a SYSPLEX member. This is not the ESP
system name, its the name by which MVS knows the member of
the SYSPLEX. Can be used to route a SEND command in a
SYSPLEX environment to wherever the use is logged on. Use an
asterisk to indicate the message goes wherever ESP is running.
643
SEND Command, Continued
Usage notes You can include several SEND commands in an Event.
A SEND command can also be issued from an ESP Procedure.
Related
information
For information on sending messages, see the ESP Workload Manager Users
Guide.
Example 1 The following SEND command sends a message to a specific user:
EVENT ID(CYBER.MESSAGE)
SCHEDULE 8AM DAILY
SEND THE TIME IS %ESPATIME USER(USR01)
ENDDEF
In the above example, USR01 is sent a message at 8 am everyday, indicating the
current time (represented by the %ESPATIME symbolic variable).
Example 2 The following SEND command sends a message to a console:
EVENT ID(CYBER.CICS_JOBEND)
SEND CICS ENDED CN(01) NONDEL
ENDDEF
In the above example, a non-roll-deletable message is sent to console 01, indicating
that a CICS region has ended.
Example 3 The following SEND commands are used in conjunction with ESP built-in symbolic
variables to send messages when the Application starts and completes:
APPL PAYROLL
JOB START.APPL LINK PROCESS
RUN DAILY
REL PAYJOB1
SEND %ESPAPPL..%ESPAPGEN STARTED AT %ESPATIME USER(USR01)
JOB PAYJOB1
RUN DAILY
REL PAYJOB2
JOB PAYJOB2
RUN DAILY
REL END.APPL
JOB END.APPL LINK PROCESS
RUN DAILY
SEND %ESPAPPL..%ESPAPGEN COMPLETED AT %ESPATIME
USER(USR01)
ENDJOB
In the above example, two messages are sent to USR01, the first when the
PAYROLL Application starts and the second when it ends.
644
SEND Command, Continued
Other examples Here are more examples using the SEND command.
Indicates the message is sent now if the user is logged on. If the user is not logged
on the message is not queued to the broadcast data set:
SEND SCHEDULING IS EASY WITH ESP USER(CYB01) NOW
Indicates the message is sent to a user in a SYSPLEX environment:
SEND SCHEDULING IS EASY WITH ESP USER(CYB01) SYSTEM(SYSA)
Indicates a message is sent to two users, if either user is not logged on the message
is queued to the broadcast data set, until the user logs on:
SEND SCHEDULING IS EASY WITH ESP U(CYB01,CYB02)
645
SETPRINT Command
Overview The SETPRINT command is used to set the default output environment for TITLE
processing.
Syntax The syntax of the SETPRINT command is:
SETPRINT repname
repname Indicates a one to eight alphanumeric logical report name, as
identified by a DEFPRINT command.
Related
information
For information on defining titles, see the TITLE command.
For information on defining a logical report name, see the DEFPRINT command.
Example 1 The following SETPRINT command shows how titles can be set for a report:
SETPRINT CYBRPT1
TITLE 1 CYBERMATION INC.
TITLE 2 DATA CENTER OPERATIONS REPORT
In the above example, the titles are set for the CYBPRT1 report.
646
SETWIDTH Command
Overview The SETWIDTH command is used to set the width of output.
Syntax The syntax of the SETWIDTH command is:
SETWIDTH nnn
nnn Indicates the column width of a report. The default is 80.
Usage notes You can use this command to format output, for example, when issuing display
commands from Page mode.
If you set the width in Page mode, it is reset when you exit from ESP.
Related
information
For information on setting column width in a History report, see the DISPLAY
command.
Example 1 The following SETWIDTH command is used in an ESP history report to indicate the
column width of the report:
REPORT
SETWIDTH 80
FROM 8AM TODAY
DISPLAY JOBNAME JOBNO EXECST CMPC
ENDR
In the above example, the history report produced by this series of reporting
commands is 80 columns.
Example 2 The following SETWIDTH command is used in Page mode:
SETWIDTH 132
LSAR DSNAME(CYBER.SADFILE)
In the above example, the width of output produced by an LSAR command is set to
132 columns.
647
SHADOW Command
Purpose The SHADOW command is used to display and manipulate a Shadow Manager.
Authority OPER authority is required to issue the SHADOW command.
Syntax
The syntax of the SHADOW parameter is:
SHADOW STATUS
[ASSUMEPRIMARY|ASSUMEPRIMARY FORCE]
[SHUTDOWN|SHUTDOWN RELINQUISH]
[HOLD(hold_interval)]
STATUS Displays the status of the primary/shadow
complex.
ASSUMEPRIMARY Indicates the Shadow Manager should take over
the duty of the primary manager.
ASSUMEPRIMARY FORCE Indicates the Shadow Manager should take over
the duty of the primary manager, whether the
primary manager is still active or not.
SHUTDOWN Indicates the Shadow Manager should relinquish
its duty as primary manager and shutdown.
SHUTDOWN RELINQUISH Indicates the Shadow Manager should relinquish
its duty as primary manager.
hold_interval Indicates the Shadow Manager should relinquish
its duty as primary manager, shutdown, and hold
the primary role for a specified number of
minutes.
Usage notes When the ESP Shadow Manager determines that a hardware or software problem
exists on the primary ESP system, ensure that the primary ESP system is completely
down before issuing the SHADOW ASSUMEPRIMARY command.
648
SHADOW Command, Continued
Related
information
For information on the ESP Shadow Manager, see the ESP Shadow Manager
Installation and Users Guide.
For information on identifying Shadow Managers, see the ESP Workload Manager
Installation Guide.
Example 1 The following SHADOW command displays the primary/shadow complex:
OPER SHADOW STATUS
Example 2 The following SHADOW command is used to take over primary Manager duties:
OPER SHADOW ASSUMEPRIMARY
In the above example, the Shadow Manager determines that a hardware or software
problems exists on the primary ESP system and takes over the duty of the primary
Manager.
Example 3 The following SHADOW command is used to relinquish primary Manager duties:
OPER SHADOW RELINQUISH HOLD(20)
In the above example, the Shadow Manager relinquishes its duty as primary
Manager and holds the primary role for 20 minutes.
649
SIGCYCLE Command
Overview The SIGCYCLE command is used to cycle a signal, it creates a new current
generation.
Syntax The syntax of the SIGCYCLE command is:
SIGCYCLE signalname
signalname Indicates the name of the signal. If the prefix is not specified,
the current group or user prefix is used. Signalname may
contain * for wildcard and/or - for masking.
Each signal has a generation number. ESP does not automatically reset the
generation number of a signal after a signal posts. A cycling process resets the
signal. Cycling increments the generation number to the next higher number.
If the maximum number of generations already exists, ESP deletes the oldest
generation. The signal definition statement specifies the maximum number of
generations. You can view this information using the LISTSIG subcommand.
The SIGCYCLE command can be used in an Event. It can also be used in Page
mode, an ESP Procedure, or batch.
Related
information
commands.
Users Guide.
650
SIGCYCLE Command, Continued
Example 1 The following SIGCYCLE command creates a new generation of a signal:
SIGCYCLE TESTSIG
In the above example, the next generation of TESTSIG is cycled. If the current
group prefix is CYBER, ESP cycles the CYBER.TESTSIG signal.
Example 2 The following SIGCYCLE command creates a new generation of a signal:
SIGCYCLE CYBER.SIGNAL1
ENDDEF
In the above example, a new generation of CYBER.SIGNAL1 is created at 8 pm
each workday.
651
SIGPOST Command
Overview The SIGPOST command is used to post a generation of a signal complete.
Syntax The syntax of the SIGPOST command is:
SIGPOST signalname
[GEN(genno)]
signalname Indicates the name of the signal. If the prefix is omitted, the
current group or user prefix is used.
genno Indicates the generation, either relative or absolute, of the
signal to be marked complete. A relative number must be
zero or negative. If not specified, default is GEN(0), the
current generation.
Usage notes ESP does not automatically reset a signals generation number when it posts the
current generation. To reset the signal, use the SIGCYCLE command.
The SIGPOST command can be used in an Event, or issued from Page mode, an ESP
Procedure, or batch.
Related
information
command.
Users Guide.
commands.
For information on identifying that a signal must be marked complete before
execution of an Event, see the SIGWAIT command.
Example 1 The following SIGPOST command posts a signal complete:
SIGPOST CYBER.SIGNAL1
In the above example, the current generation of CYBER.SIGNAL1 is posted
complete.
652
SIGPOST Command, Continued
SIGPOST CYBER.SIGNAL2 GEN(-1)
In the above example, the -1 relative generation of CYBER.SIGNAL2 is posted
complete.
SIGPOST CYBER.SIGNAL3 GEN(123)
In the above example, generation 123 of CYBER.SIGNAL3 is posted complete.
GROUP CYBER
SIGPOST MYSIGNAL
In the above example, the group prefix is set to CYBER, and the current generation
on CYBER.MYSIGNAL is posted complete.
EVENT ID(CYBER.PAYROLL5)
SIGPOST CYBER.SIGNAL5 GEN(-1)
ENDDEF
In the above example, the -1 relative generation of CYBER.SIGNAL5 is posted
complete at 10 pm on workdays.
653
SIGWAIT Command
Overview The SIGWAIT command is used to identify a signal that must be marked complete
before execution of the Event.
Syntax The syntax of the SIGWAIT command is:
SIGWAIT signalname
[GEN(genno)]
signalname Indicates the name of the signal. If the prefix is not specified
the current group prefix is used.
genno Indicates an absolute or relative generation number of a
signal. The default is 0 (current generation).
Usage notes To instruct an Event to wait for posting of a signal, insert the SIGWAIT command in
the scheduled Event. You can use more than one SIGWAIT command if the Event is
to wait for posting of different signals or different generations of the same signal.
The SIGWAIT command can be used only in conjunction with a SCHEDULE
statement. The Event waits until both the schedule criteria and signal conditions are
satisfied before execution.
Related
information
Users Guide.
commands.
command.
command.
For information on displaying all generations of a signal, see the LISTSIG
command.
For information on specifying the maximum number of pending signals for an
Event, see the EVENT command - MAXPEND parameter.
654
SIGWAIT Command, Continued
Example 1 The following SIGWAIT command identifies a signal which must be marked
complete:
SIGWAIT PROD.DATA GEN(0)
ENDDEF
In the above example, CYBER.PAYROLL does not execute until PROD.DATA is
posted complete and the schedule criteria are satisfied.
655
SIMULATE Command
Overview The SIMULATE command is used to simulate the functions of an Event.
Syntax The syntax of the SIMULATE command is:
SIMULATE EVENT(eventid)
[SCHED(schedtime)]
[PRINT(printdsn)]
[JCLDS]
[COPYJCL]
[ROOTJOB(job1[,job2]...)]
[JOB(jobname)]
[TRJOB(trigger_jobname)]
[TRDSN(trigger_dsname)]
[TRVOL(trigger_volume)]
[TRUNIT(trigger_unit)]
[USER(user_id)]
[GROUP(group_id)]
[SYMLIB(sym_dsn1[,sym_dsn2]...)]
[RTYPE(run_type)]
[WOB(module1[,module2]...)]
[VARS(variable_list)]
[SYMBOL(sym_char)]
[USER1(user_data1)]
[USER2(user_data2)]
[USER3(user_data3)]
[USER4(user_data4)]
[NOLISTPROC]
[JCLSCAN(exit_module)]
[NOREXX]
[NOTSELECTED]
[INHERIT]
656
SIMULATE Command, Continued
Syntax (continued)
EVENT(eventid) Indicates the name of the Event for which you want
to simulate processing.
SCHED(schedtime) Indicates the schedule time to be used for the
simulation. This can be any time specification valid
on a SCHEDULE command that resolves to a time
and date. If it contains separator characters
(commas or blanks), enclose it within quotes. The
default is the next scheduled time.
PRINT(printdsn) Indicates the data set to which the JCL is copied.
You can specify an asterisk (*) to view the JCL at
your terminal.
JCLDS Displays the JCL libraries used for each job. This
includes libraries and members identified by
JCLLIB, TEMPLIB, DATASET and MEMBER
statements in an ESP Procedure.
COPYJCL Requests a simulation of what is written to the
COPYJCL library
ROOTJOB Indicates the names of jobs to which you want to
restrict the simulation. Specifying jobname+
includes jobname in the simulation plus its
successors.
JOB Indicates the name of the job being rerun.
TRJOB(trigger_jobname) Indicates the job that caused the triggering action.
TRDSN(trigger_dsname) Indicates the name of the data set that caused the
triggering action.
TRVOL(trigger_volume) Indicates the volume serial number of the data set
that caused the triggering action.
TRUNIT(trigger_unit) Indicates the unit name of the data set that caused
the triggering action.
USER Indicates the user ID under which to simulate the
Event.
GROUP Indicates the group value under which to simulate
the Event.
PASSWORD Indicates the password value under which to
simulate the Event.
SYMLIB Indicates a list of data set names of symbol libraries
to be used.
657
Syntax (continued)
WOB Generates a WOB module directory for use in the
simulation. If not specified, the directory belonging
to the subsystem is used.
VARS(variable_list) Provides a list of variable names and values, e.g.
varname(value). These variables can include
monitor and signal variables. The maximum length
of the text in the list is 255 characters.
SYMBOL Indicates a symbol substitution character to be used.
USER1, USER2, USER3
and USER4
Indicates the USER variables passed to the Event.
Each variable can be up to 80 characters.
NOLISTPROC Indicates unless errors are detected, the text of any
invoked Procedures is not listed. If this parameter is
omitted, the text of the Procedure is listed. If an
error is detected, the error messages are always
listed.
JCLSCAN(exit_module) Defines the name of the module used as the
JCLSCAN exit module. If this parameter is omitted,
no JCLSCAN exit processing is performed for
simulated job submissions.
NOREXX Indicates all input text between a REXXON and a
REXXOFF statement is ignored. If this parameter is
omitted, the in-line REXX code is interpreted by
REXX.
NOTSELECTED Indicates a list is to be produced of all jobs not
selected, for any reason. If this parameter is
omitted, no list is produced for jobs that were not
selected.
INHERIT Indicates if a successor was inherited, the inherited
relationships are identified in the output report. If
this parameter is omitted, no indication is made for
jobs that are inherited.
658
Usage notes For the Event you select, the SIMULATE command tells you which jobs ESP
submits, any messages it sends, how it substitutes symbolic variables, and so on. The
SIMULATE command is particularly useful with ESP Procedures because you can
use it to see how the complex and conditional components of your Procedure run at
a particular date and time. ESP also displays error messages if it encounters
problems, such as syntax errors or successor loops in an Application. You can
simulate an Event for a day on which it is not normally scheduled; ESP simulates
what would happen if the Event was triggered on that particular day.
Use the SIMULATE command to emulate the functions of any Event. If you use
SIMULATE with no parameters, the next scheduled occurrence of the Event is
simulated. If no scheduled time exists for an Event, ESP will assumes NOW. Use
the SCHED parameter to specify any valid schedule criteria to be used for the
simulation. This allows you to find out what happens if the Event executes on any
particular date.
Using the PRINT parameter with SIMULATE requests that a copy of the JCL,
which would be used at the time you are simulating, is made to a data set of your
choice. The generated JCL has any symbols appropriately substituted. If you are
using ESPs JCL Tailoring facility, any %INCLUDE and %EXCLUDE statements
are resolved. This means that you are able to see the JCL to be used at different
times.
You can also simulate Events using ESPs ISPF interface - Option E.3 from the ESP
Main Menu.
Related
information
Example 1 The following SIMULATE command simulates the functions of an Event:
SIMULATE EVENT(CYBER.PAYROLL) SCHED(LAST WORKDAY OF MONTH)
In the above example, the functions that CYBER.PAYROLL performs on the last
workday of the month are simulated.
SIMULATE EVENT(CYBER.PAYROLL1) SCHED(TOMORROW) ROOTJOB(A,D+)
In the above example, the functions that CYBER.PAYROLL1 performs on the next
day are simulated. The simulation is restricted to job A and job D and its
successors.
659
SIMULATE EVENT(CYBER.PAYROLL2) SCHED(MON) USER1(PAYJOB1)
In the above example, the functions that CYBER.PAYROLL2 performs on Monday,
when the USER1 field is set to PAYJOB1 are simulated.
Other examples Here are more examples using the SIMULATE command.
Simulates an Event and displays the JCL libraries used for each job:
SIMULATE EVENT(CYBER.PAYROLL) JCLDS
Simulates an Event. The name of the module used as the JCLSCAN exit module:
SIMULATE EVENT(CYBER.PAYROLL) JCLSCAN(CHECKJCL)
Simulates an Event. All input text between a REXXON and REXXOFF statement is
ignored:
SIMULATE EVENT(CYBER.PAYROLL) NOREXX
Simulates an Event. If a successor was inherited, the inherited relationships are
identified:
SIMULATE EVENT(CYBER.PAYROLL) INHERIT
Simulates a job monitor Event and identifies monitor variables used by the Event:
SIMULATE EVENT(CYBER.PAYJOB1_JOBEND) +
VARS(MNJOB(PAYJOB1),MNAPPL(PAYROLL))
Simulates an Event and passes a USER variable to the Event:
SIMULATE EVENT(CYBER.PAYROLL) USER1(PAYJOB1)
Simulates an Event for the last day of the month. The output is sent to your
terminal:
SIMULATE EVENT(CYBER.PAYROLL) SCHED(LAST DAY OF MONTH) +
PRINT(*)
660
Example 4 The following is an ISPF example, it requests that during simulation of an Event, the
text of any invoked ESP Procedure is not listed:
ESP -------------------- SIMULATE EVENT EXECUTION -------------------- ESP
ADDITIONAL OPTIONS
COMMAND ===>
DISPLAY PROCEDURE ===> N (blank, N or Y)
SIMULATE DATASET TRIGGER ===> (blank, N or Y)
SIMULATE SIGNALS ===> (blank, N or Y)
SIMULATE MONITOR EVENT ===> (blank, N or Y)
JCLSCAN EXIT NAME ===> (blank or name)
SUPPRESS REXX ===> (blank, N or Y)
SHOW NOT SELECTED ===> (blank, N or Y)
SHOW INHERITANCE ===> (blank, N or Y)
The following is an example of the display produced when the ESP Procedure text is
not listed:
ESP ----------------------- EVENT CYBER.PAYROLL ---------------------------ESP
COMMAND ===>
INVOKE CYBER.PROCLIB(PAYROLL)
SIMULATION OF EVENT CYBER.PAYROLL AT 07.39.26 ON MONDAY MAY 30TH, 1997
JOBS: PAYJOB1, PAYJOB99
2 JOBS SELECTED FOR SUBMISSION
JOB TYPE-JOBNAME--HC-RELEASES
JOB PAYJOB1 0 (NONE)
REQUEST PAYJOB99 0 (NONE)
TASK PAYJOB2 0 (NONE)
MAN SUB PAYJOB3 0 (NONE)
LINK PAYJOB4 0 (NONE)
EXTERNAL PAYJOB5 0 (NONE)
661
Example 5 The following is an ISPF example, it illustrates the simulation of a data set triggered
Event:
ESP -------------------- SIMULATE EVENT EXECUTION -------------------- ESP
ADDITIONAL OPTIONS
COMMAND ===>
DISPLAY PROCEDURE ===> (blank, N or Y)
SIMULATE DATASET TRIGGER ===> Y (blank, N or Y)
SIMULATE SIGNALS ===> (blank, N or Y)
SIMULATE MONITOR EVENT ===> (blank, N or Y)
JCLSCAN EXIT NAME ===> (blank or name)
SUPPRESS REXX ===> (blank, N or Y)
SHOW NOT SELECTED ===> (blank, N or Y)
SHOW INHERITANCE ===> (blank, N or Y)
Entering Y in the above panel presents you with the following panel, where you can
specify the data set name, the triggering job name, volume serial or unit that caused
the triggering action, as follows:
ESP ---------------------- SIMULATE EVENT EXECUTION ---------------------- ESP
DATASET TRIGGER OPTIONS
COMMAND ===>
DATASET NAME ===> CYBER.TEST.DATA
TRIGGERING JOB NAME ===>
VOLUME SERIAL ===>
UNIT ===>
The following is an example of the display produced when data set name field in
entered:
ESP ----------------------- EVENT CYBER.PAYROLL ---------------------------ESP
COMMAND ===>
INVOKE CYBER.PROCLIB(PAYROLL)
APPL PAYROLL
JCLLIB CYBER.JCLLIB
JOB PAYJOB1
RUN DAILY
RELEASE PAYJOB2
JOB PAYJOB2
RUN DAILY
ENDJOB
SIMULATION OF EVENT CYBER.PAYROLL AT 07.39.26 ON MONDAY MAY 30TH, 1997
JOBS: PAYJOB1, PAYJOB2
2 JOB SELECTED FOR SUBMISSION
JOB TYPE-JOBNAME--HC-RELEASES
JOB PAYJOB1 0 (PAYJOB1)
JOB PAYJOB2 1 (NONE)
Note: You are not testing if this Event is triggered by this data set, you are testing
the Event as if it was triggered by the data set name you specify. ESP resolves
symbolic variables based on this name.
662
SMFSTATS Command
Overview The SMFSTATS command is used to display SMF statistics. The display includes
the number of job starts, started task starts, TSO user starts and step ends since the
ESP subsystem initialized.
Syntax The syntax of the SMFSTATS command is:
SMFSTATS
Example 1 The following is an example of the display produced by the SMFSTATS command:
SMFSTATS
ESP SUBSYSTEM INITIALIZED AT 11.35.47 ON SATURDAY FEBRUARY
7TH, 1998
18959 ENTRIES TO SMFWTM, 8328 BY BRANCH ENTRY AND 10631 BY SVC
1904 ENTRIES TO ESP PHASE 2
70 JOB STARTS, 2 STC STARTS, 12 TSU STARTS, 194 STEP ENDS
In the above example, since ESP initialized there were:
70 job starts
2 started task starts
12 TSO user starts
194 step ends.
663
SORT Command
Overview The SORT command is used to specify an ascending or descending sort sequence
for any of the entries specified by the DISPLAY command in an ESP history report.
Syntax The syntax of the SORT command is:
SORT field
{A|D}
field Indicates the name of a field.
A Indicates sorting in ascending sequence. This is the default.
D Indicates sorting in descending sequence.
Usage notes Several sort fields can be specified, one after the other, separated by a blank.
Related
information
For information on specifying fields to display on your history report, see the
DISPLAY command.
Example 1 The following SORT command specifies the fields to be sorted:
REPORT
FROM 8AM YESTERDAY
DISPLAY JOBNAME CPUTIME DEXCP EXECST
SORT CPUTIME D DEXCP
ENDR
In the above example, history data is sorted by decreasing use of CPU time
(CPUTIME). If two or more jobs have matching CPU times, they are displayed in
sequence of ascending DASD EXCP counts (DEXCP).
664
SORT Command, Continued
Example 2 The following SORT command specifies the fields to be sorted:
REPORT
FROM 8AM YESTERDAY
DISPLAY JOBNAME JOBNO INPUTQT EXECQT
SORT JOBNAME EXECQT
ENDR
In the above example, history data is sorted by ascending jobname (JOBNAME). If
two or more jobs have the same name, they are displayed in sequence of ascending
execution queue time (EXECQT).
665
SPACE Command
Overview The SPACE command is used to space output by one or more lines to make the
output easier to read.
Syntax The syntax of the SPACE command is:
SPACE [count]
count Indicates the number of lines to be advanced. The default is
1.
Usage notes The SPACE command can be used in Page mode or in batch.
Example 1 The following SPACE command inserts spaces in an output listing:
LISTSPEC
SPACE 4
LISTHOL
In the above example, four blank lines are inserted between the special day listing
(LISTSPEC) and the holiday display (LISTHOL).
666
SPINLOG Command
Overview The SPINLOG command is used to spin ESPs audit log to a sysout class.
Authority OPER authority is required to issue the SPINLOG command.
Syntax The syntax of the SPINLOG command is:
SPINLOG
Usage notes The sysout class, and optionally the form number for spinning the audit log, is
identified by the AUDITLOG Initialization Parameter.
Related
information
For information on setting the print characteristics of ESPs audit log, see the
AUDITLOG parameter in the ESP Workload Manager Installation Guide.
Example 1 The following is an example of the display produced by the SPINLOG command.
OPER SPINLOG
ESP1023I Auditlog dataset spun with 262 records to sysout
class E
In the above example, 262 records are spun to sysout class E.
667
SPUSER Command
Overview The SPUSER command is used to identify the initial user who must access ESP to
perform the user and group definitions. The SPUSER command is meaningful only
in non-SAF environments.
Authority OPER authority is required to issue the SPUSER command.
Syntax The syntax of the SPUSER command is:
SPUSER userid
userid Indicates the TSO user ID of the initial user.
Usage notes This SPUSER command is normally stored in the ESP cold Initialization Parameter
data set.
Related
information
For information on defining an initial user to ESP at the Initialization Parameter
Example 1 The following SPUSER command identifies the initial user:
OPER SPUSER USR01
In the above example, USR01 is identified as the initial user. USR01 has access to
ESP to define users.
668
STATUS Command
Overview The STATUS command is used to display the current ESP processing status.
Authority OPER authority is required to issue the STATUS command.
Syntax The syntax of the STATUS command is:
{STATUS|ST}
Usage notes The STATUS command displays the following information:
The current ESP release number.
Whether ESP is quiesced or active.
Whether data set triggering is suspended or active.
The names of any suspended Event data sets.
Example 1 The following is an example of the display produced by the STATUS command:
OPER STATUS
ESP1978I EVENT SCHEDULING ACTIVE
In the above example, the current release of ESP is 5.1.0, ESP is active, data set
triggering is active and there are not suspended Event data sets.
669
STEPEND Statement
Overview The STEPEND statement is used to release resources back to the resource pool at
job step-end. You may release part or all of the resources back to the resource pool.
The STEPEND statement is coded within the scope of the job statement. You can
have more than one STEPEND statement in one job.
Syntax The syntax of the STEPEND statement is:
STEPEND STEPNAME(stepname) PROCSTEP(procstep)
RELRES(n1,resname1,n2,resname2, )
stepname Indicates the name of the job step.
procstep Indicates the name of the proc step.
n1,resname Indicates the quantity and name of the resource to be released.
Example The following shows releasing one unit of a resource after STEP1, PROCA:
APPL ONE
JOB JOBA
RUN DAILY
RESOURCE (6,T3480)
STEPEND STEPNAME(STEP1) PROCSTEP(PROCA) RELRES(1,T3480)
ENDJOB
The following shows releasing two more units of the same resource later in the same
job:
APPL ONE
JOB JOBA
RUN DAILY
RESOURCE (5,T3480)
STEPEND STEPNAME(STEP3) PROCSTEP(PROCB) RELRES(2,T3480)
ENDJOB
Ensure the stepnames and procsteps you specify match your JCL exactly. You can
release resources by specifying just a procstep and not a stepname, if that is how
your JCL is tailored.
Resource types Step-level resource release is available for renewable resources only.
Note Step-level Resource Release only works if USERMOD 11 is off. When USERMOD
11 is on, the Application Manager does not get step-end notification.
670
SUBAPPL Statement
Overview The SUBAPPL statement is used to identify the logical name of a subApplication
within an Application. Choose a subApplication name different than that of any
jobname within the Application.
Syntax The syntax of the SUBAPPL statement is:
SUBAPPL subapplid [WAIT|NOWAIT]
subapplid Indicates a subApplication identifier of up to eight
alphanumeric characters. The first character can not be
numeric. The name of the subApplication must be different
from any job within the Application.
WAIT Indicates concurrent processing of different generations of the
same subApplication is not permitted. ESP ensures that a
subApplication waits for the previous generation of the same
subApplication to complete. This can be specified at the
Application or the subApplication level.
NOWAIT Indicates concurrent processing of different generations of the
same subApplication is permitted. This is the default.
Usage notes You may choose to use a subApplication to:
Break up a large Application into smaller groups of jobs
Combine smaller Applications into one common Application and use
subApplications to group related jobs together. This may alleviate the need for
establishing inter-Application relationships, that is, EXTERNAL jobs.
Using a subApplication allows you to:
Display and manipulate all jobs in a subApplication using a single command.
Select or deselect all jobs in a subApplication using a single command.
Use the CSF to filter based on the subApplication.
Control concurrent processing of different generations of the same
subApplication.
Report on subApplications.
671
SUBAPPL Statement, Continued
Usage notes
continued
You can use the SUBAPPL statement at a global level or at a job level. A job level
setting overrides a global setting.
You can select jobs within a subApplication by selecting each job or the
subApplication.
Related
information
For information on Applications and subApplications, see the ESP Workload
For information on manipulating subApplications using the CSF, see the ESP
For information on reporting on subApplications, see the ESP Workload Manager
Users Guide.
For information on selecting or deselecting entire subApplications, see the SELECT
and DESELECT statements.
For information on manipulating jobs within Applications and subApplications, see
Example 1 The following SUBAPPL statement identifies a job as belonging to a
subApplication:
JOB MYJOB
SUBAPPL PREPJOBS
ENDJOB
In the above example, MYJOB is identified as belonging to the PREPJOBS
subApplication.
672
Example 2 The following SUBAPPL statements identify subApplications:
APPL PAYROLL
JCLLIB CYB.PROD.JCL
JOB PAYJOB1
SUBAPPL ACCTPAY WAIT
JOB PAYJOB2
SUBAPPL ACCTPAY
JOB RECJOB1
SUBAPPL ACCTREC
JOB RECJOB2
SUBAPPL ACCTREC
ENDJOB
SELECT (ACCTPAY,ACCTREC) SUBAPPL
PAYJOB1 and PAYJOB2 are grouped together into the ACCTPAY
subApplication. Each generation of the ACCTPAY subApplication must wait for
the previous generation to complete.
RECJOB1 and RECJOB2 are grouped together into the ACCTREC
subApplication. Different generations of the ACCTREV subApplication can
process at the same time.
Example 3 The following SUBAPPL statements identify subApplications:
APPL PAYROLL
SUBAPPL ACCTPAY WAIT
JOB PAYJOB1
JOB PAYJOB2
ENDJOB
SUBAPPL BILLING
JOB BILLJOB1
JOB BILLJOB2
ENDJOB
PAYJOB1 and PAYJOB2 are grouped together into the ACCTPAY
subApplication. Different generations of the ACCTPAY subApplication can
BILLJOB1 and BILLJOB2 are grouped together into the BILLING
subApplication. Different generations of the BILLING subApplication can
673
Example 4 The following SUBAPPL statements identify jobs for subApplications within an
Application:
APPL PAYROLL
JOB PAYJOB1
DELAYSUB 10PM
RUN DAILY
REL (REGJOB1,SPECJOB1)
ENDJOB
JOB REGJOB1
SUBAPPL REGULAR
RUN DAILY
REL REGJOB2
ENDJOB
JOB REGJOB2
SUBAPPL REGULAR
RUN DAILY
REL PAYJOB99
ENDJOB
JOB SPECJOB1 REQUEST
SUBAPPL SPECIAL
RUN DAILY
REL SPECJOB2
ENDJOB
JOB SPECJOB2 REQUEST
SUBAPPL SPECIAL
RUN DAILY
REL PAYJOB99
ENDJOB
JOB PAYJOB99
RUN DAILY
ENDJOB
REGJOB1 and REGJOB2 are grouped together into the REGULAR
subApplication
SPECJOB1 and SPECJOB2 are grouped together into the SPECIAL
subApplication. Each job in the SPECIAL subApplication is identified as on
request jobs, i.e. they may or may not run.
PAYJOB1 and PAYJOB99 do not belong to a subApplication. PAYJOB1 has a
delayed submission time of 10 pm.
Note: If this Application is triggered early in the day, it provides the opportunity to
request jobs within the SPECIAL subApplication prior to 10 pm.
674
Example 5 The following Application invokes 4 separate members, each containing a
subApplication:
APPL PAYROLL
INVOKE CYBER.PROCS.CNTL(ACCPAY)
INVOKE CYBER.PROCS.CNTL(ACCREC)
INVOKE CYBER.PROCS.CNTL(BILLING)
INVOKE CYBER.PROCS.CNTL(REPORTS)
In the above example, the PAYROLL Application consists of
An APPL statement identifies the name of the Application
A JCLLIB statement tells ESP where to find each jobs execution JCL
4 INVOKE statements identify the subApplications comprising the PAYROLL
Application.
The following are examples of the invoked members:
SUBAPPL ACCPAY
JOB ACCJOB1
JOB ACCJOB99
SUBAPPL ACCREC
JOB RECJOB1
JOB RECJOB99
SUBAPPL BILLING
JOB BILJOB1
JOB BILJOB99
SUBAPPL REPORTS
JOB RPTJOB1
JOB RPTJOB99
Note: This method of subApplication organization is not required, but may provide
an option when an Application contains many subApplications, with each
subApplication containing many jobs.
675
SUBMIT Command
Overview The SUBMIT command is used to submit JCL into the internal reader.
Syntax The syntax of the SUBMIT command is:
{SUBMIT|SUB} dsname
[GENERATION(genno)]
[LEVEL{(levelname[,levelname]...)|(*)}]
dsname Indicates a valid data set name. The current user prefix is
added if the data set name is not enclosed within quotes. You
can include a member name within the data set specification.
genno Indicates a generation number for a generation data group
(GDG). It must be zero or a negative number.
levelname Indicates a one to eight character string, or an asterisk. A list
of level names, separated by blanks or commas, can be
specified.
* Indicates all members are to be submitted, in alphabetical
sequence, by member name.
Usage notes A single Event can submit more than one job. If there are relationships between the
jobs you are submitting, you must use an Application, not an Event to submit them.
The SUBMIT command can also be issued from an ESP Procedure.
Multiple members of a PDS may be submitted with one SUBMIT command.
Specify member names in full or by generic level. You can also request all members
of a PDS be submitted by specifying LEVEL(*). Note that when using the
LEVEL keyword, members of the PDS are read in alphabetical sequence by member
name.
A data set (including a PDS) that is part of a GDG can also be used as a source for
JCL. Use the GENERATION keyword to specify the relative generation number.
This number must be 0 or negative.
Related
information
Users Guide.
676
SUBMIT Command, Continued
Example 1 The following is an example of an Event definition that submits JCL:
EVENT ID(CYBER.PAYJOB1)
ENDDEF
In the above example, PAYJOB1 is submitted at 9 am on the first Monday of the
month from CYBER.JCL.CNTL.
Example 2 The following is an example of an Event definition that submits two jobs:
EVENT ID(CYBER.PAYJOBS)
SCHEDULE 10AM LAST DAY OF MONTH
ENDDEF
In the above example, PAYJOB2 and PAYJOB3 are submitted at 10 am on the last
day of the month from CYBER.JCL.CNTL.
EVENT ID(CYBER.ALLJOBS)
SCHEDULE 8PM MONDAY
SUBMIT CYBER.JCL.CNTL LEVEL(*)
ENDDEF
In the above example, all members of CYBER.JCL.CNTL are submitted at 8 pm
Mondays.
EVENT ID(CYBER.ALLJOBS)
SCHEDULE 9PM MONDAY
SUBMIT CYBER.JCL.CNTL LEVEL(A-,BP-)
ENDDEF
In the above example, all members that start with A or BP are submitted at 9 pm
on Mondays from CYBER.JCL.CNTL.
677
SUBMIT Command, Continued
Example 5 The following SUBMIT command is used with a built-in function in an ESP
Procedure to submit JCL:
IF TODAY(NOT LAST DAY OF MONTH) THEN -
In the above example, if today is not the last day of the month, ESP submits
PAYJOB4 from CYB.JCL.CNTL.
678
SUSPEND Command - Event Level
Overview When used in an Event definition, the SUSPEND command increments the suspend
count of the Event. While the suspend count is greater than zero, Event execution is
bypassed.
Syntax The syntax of the SUSPEND command is:
SUSPEND criteria
Usage notes The RESUME command is used in conjunction with the SUSPEND command to
If you are using a time zone on your SUSPEND command, you should use the same
time zone on your RESUME command. If the Event has a schedule statement, the
same time zone should be used on the SCHEDULE, SUSPEND and RESUME
commands.
Note:
Related
information
For information on holding or releasing an Events execution, see the HOLD and
RELEASE commands.
For information on decrementing an Events suspend count that was previously
incremented using the SUSPEND command, see the RESUME command.
SUSPEND DAILY AT 9AM
RESUME DAILY AT 11AM
ENDDEF
In the above example, SUSPEND and RESUME commands are used to prevent
PAYJOB1 from being submitted between 9 am and 11 am. If the data set trigger
happens between these times, ESP ignores it.
679
SUSPEND Command - Event Level, Continued
EVENT ID(CYBER.TIMEMSG)
SCHEDULE WORKDAYS HOURLY ROUND STARTING TODAY
SEND THE TIME IS %ESPATIME U(CYB01)
SUSPEND 16:01 WORKDAYS
RESUME 7:59 WORKDAYS
ENDDEF
In the above example, SUSPEND and RESUME commands are used to limit the
sending of a message to each hour between 8 am and 4 pm on workdays.
SCHEDULE 9PM PST WORKDAYS
SUSPEND 8PM PST MARCH 2,1998 ONCE
RESUME 10PM PST MARCH 2,1998 ONCE
ENDDEF
In the above example, SUSPEND and RESUME commands are used to bypass the
Event between 8 pm and 10 pm Pacific Standard Time, on March 2, 1998 only.
680
SUSPEND Command - General
Overview When used outside an Event definition, the SUSPEND command increments the
suspend count associated with an Event. When the suspend count is greater than
zero, event execution is bypassed.
Syntax The syntax of the SUSPEND command is:
SUSPEND eventid
eventid Indicates a valid Event name. If no prefix is specified, the
current prefix as set by the GROUP command is used.
Usage notes The specified Event has its SUSPEND count incremented immediately.
The RESUME command is used in conjunction with the SUSPEND command to
Related
information
For information on incrementing on holding or releasing an Events execution, see
the HOLD and RELEASE commands.
For information on decrementing an Events suspend count that was previously
incremented using the SUSPEND command, see the RESUME command.
Examples 1 The following SUSPEND command suspends an Event:
SUSPEND CYBER.PAYROLL
In the above example, CYBER.PAYROLL is suspended and not eligible for
execution.
681
SYMLIB Command
Overview The SYMLIB command is used to request the inclusion of one or more symbolic
variable libraries
Syntax The syntax of the SYMLIB command is:
{SYMLIB|SYM} {symname}
{symname[,symname]...}
symname Indicates the name of an existing SYMLIB of up to eight
characters. You can specify several names by enclosing the
list within parentheses and separating each item with a blank
or comma.
Usage notes The SYMLIB command requests the inclusion of any number of symbolic variable
libraries as defined with the DEFSYML command. A symbolic variable library is a
collection of sequential data sets or members or partitioned data sets. Each Event
can request one or more symbol libraries.
If the same symbol is defined in more than one symbol library referenced in an
Event, the last value of the symbol is used.
Related
information
Guide.
For information on defining a symbol library, see the DEFSYML command.
For information on displaying information about symbol libraries, see the
LISTSYML command.
682
SYMLIB Command, Continued
Example 1 The following SYMLIB command references a symbolic variable library:
SYMLIB DATES
ENDDEF
In the above example, when ESP processes CYBER.PAYROLL1, it opens the data
set associated with DATES and uses this information to perform symbolic variable
substitution.
Note: These same results can be accomplished by invoking an ESP Procedure that
stores symbolic variables, as follows:
INVOKE CYBER.SYMBOLS.CNTL(DATES)
ENDDEF
Example 2 The following SYMLIB command references two symbolic variable libraries:
SYMLIB MDATES PDATES
ENDDEF
In the above example, when ESP processes CYBER.PAYROLL2, it opens the data
sets associated with MDATES and PDATES and uses this information to perform
symbolic variable substitution.
683
SYSMSGS Command
Overview The SYSMSGS command is used to intercept messages written to the system
message data set. Use ESP to cancel a job, fail a job, trigger an Event or issue a
WTO message when a specific message is intercepted.
Authority OPER authority is required to issue the SYSMSGS command.
Syntax The syntax of the SYSMSGS command is:
SYSMSGS [text]
[DISABLE|ENABLE|IGNORE]
[CANCEL|CCFAIL|JCLERROR|WARN]
[TSU]
[STC]
[ID(xxxx)]
[COL(nn[:nn])]
[NAME(jobname[,jobname]...)
[EVENT(eventid)]
[COUNT(m)]
[ROUTE(rcode)]
[DESC(dcode)]
[JOBNAME]
[WTO]
[COMPRESS]
text Indicates the part of the message text that defines the message
you want intercepted. This can be a message identifier, a
prefix or any part of the message text. This parameter must
not be specified if the DISABLE, ENABLE or IGNORE
keywords are specified. However, it must be specified if these
keywords are not specified. The maximum length of this
field is 32 bytes.
DISABLE Temporarily suspends an existing entry for the specified
message ID and prevents its interception. Note that the ID
parameter must be specified and no other parameter may be
specified, including the message text.
ENABLE Re-enables a suspended entry for the specified message ID.
Note that the ID parameter must be specified and no other
parameter may be specified, including the message text.
IGNORE Invalidates and deletes an existing entry for the specified
message ID and prevents its interception. Note that the ID
parameter must be specified and no other parameter may be
specified, including the message text.
684
SYSMSGS Command, Continued
Syntax (continued)
CANCEL Indicates interception of this message text should generate an
MVS cancellation of the job (system abend code 222).
CCFAIL Indicates interception of this message should cause a
condition code failure.
JCLERROR Indicates interception of this message should cause a JCL
error.
WARN Indicates ESP generates a warning message when this
message is intercepted. The messages are displayed when an
LTJ command is issued for the job that issued the message.
Note that no action takes place with this option, only a
warning message is issued.
TSU Indicates interception of this message should only occur for
time sharing users (TSUs).
STC Indicates interception of this message should only occur for
started tasks (STCs).
ID(xxxx) Indicates an identifier consisting of 4 alphanumeric
characters. You can assign an ID when you define
SYSMSGS, else ESP assigns the next available sequential
number. The identifier controls the order of search when ESP
is tracking system messages. It must be used with DISABLE,
ENABLE and IGNORE. Specify ID(*) for all.
nn Indicates a column or range of columns where the specified
message text should begin. The default is column 1.
jobname Indicates up to 4 jobnames (or jobname strings), thus limiting
the system message interception for a particular job, or set of
jobs.
eventid Indicates the Event to be triggered when the system message
is intercepted. EVENT can be abbreviated as EV.
m Indicates the Event is to be scheduled for every m
interceptions of the system message, where m is a number
from 0 to 255. A value of 0 results in a schedule for each
interception, as does a value of 1. It defaults to 1.
rcode Indicates the routing code that identifies the console to which
this message should be sent. If it is omitted, the default
routing code is 2.
dcode Indicates the descriptor code that is to apply to this message.
If it is omitted, the default descriptor code is 6. Use DESC(2)
for a non-deletable message.
JOBNAME Indicates the job name should be embedded within the
message when it is rebroadcast on the console.
WTO Indicates the message should be rebroadcast as a WTO
message.
COMPRESS Indicates extra blanks are to be removed from the text.
685
Usage notes This command causes failure of a job or the triggering of an Event, through the
interception of pre-defined message ID or message text. The message can be issued
from a console or from an authorized terminal, and routed to any specified console.
Ensure that the SYSMSGS parameter is first specified with the TRACKOPT
command or ESP Initialization Parameter. If TRACKOPT SYSMSGS is not
specified, system messages are not intercepted.
The message text must not be specified for the DISABLE, ENABLE or IGNORE
parameters. These parameters require that the ID parameter also be specified and no
other parameters are allowed.
SYSMSGS must be specified on the system that does the tracking. If ESP is tracking
on the Master, enter this on the Master. If ESP is tracking on the Slave, enter this on
the Slave. TRACKOPT SYSMSGS must also be specified on the tracking system.
When the SYSMSGS command is first used to identify message interception, it
takes effect immediately. Use the ENABLE parameter only after a SYSMSGS ID
has been disabled.
Related
information
For information on clearing system message interceptions, see the CLRSYSMS
command.
For information on displaying information on all system messages that are currently
intercepted by ESP, see the LSYSMSGS command.
Example 1 The following SYSMSGS command intercepts messages:
SYSMSGS NOT CATLGD COL(50:60) CANCEL WTO JOBNAME
In the above example, whenever a NOT CATLGD system message is generated
starting anywhere between columns 50 and 60, cancel the job and embed the
jobname when the message is rebroadcast as a WTO.
SYSMSGS IEF142I NAME(PAYJOB1) EVENT(CYBER.PAYSTEP)
In the above example, whenever an IEF142I system message is generated for
PAYJOB1, trigger Event CYBER.PAYSTEP.
686
SYSMSGS IEF253I ID(0010) NAME(J-,K-) CANCEL EV(CYBER.CAN)
DESC(2)
In the above example, whenever an IEF253I system message is generated for jobs
with 2 character names beginning with J or K, cancel the job and trigger Event
CYBER.CAN. Highlight the message using descriptor code 2. Assign an ID of 0010
to this system message interception.
Example 4 The following SYSMSGS command ignores system message interception for a
specific message ID:
SYSMSGS IGNORE ID(0023)
In the above example, all message system interception processing for system
message ID 0023 is ignored.
Example 5 The following SYSMSGS command disables system message interception for a
SYSMSGS DISABLE ID(0002)
In the above example, all system message interception processing for system
message ID 0002 is disabled.
Example 6 The following SYSMSGS command enables system message interception for a
SYSMSGS ENABLE ID(0002)
In the above example, all system message interception processing for system
message ID 0002 is enabled.
Example 7 The following SYSMSGS command activates system message interception for a
SYSMSGS IEC161I NAME(UT-) WARN COUNT(99)
In the above example, whenever 99 IEC161I system messages have been generated
for jobnames beginning with UT, a warning message is issued.
687
TAG Statement
Overview The TAG statement is used to tag jobs in an Application with a character string up
to 16 characters in length. The TAG statement can be job specific or can apply to
all jobs in an Application.
Syntax The syntax of the TAG statement is:
TAG string
string Indicates a character string in up to 16 characters. If the
string contains separator characters (comma or blanks),
enclose it within quotes. This string may contain ESP
symbolic variables.
Usage notes Using the TAG statement allows you to:
Filter jobs with a common characteristic using the CSF
Pass information to JCL using the %ESPAPTAG symbolic variable.
Related
information
Example 1 The following TAG statement associates a character string with a specific job:
APPL PAYROLL
JOB PAYJOB1
TAG CRITICAL JOB
RUN WORKDAYS
ENDJOB
In the above example, PAYJOB1 is tagged with the character string CRITICAL
JOB.
688
TAG Statement, Continued
Example 2 The following TAG statement associates a character string with an entire
Application:
APPL PAYROLL
TAG %ESPSDAY(1:3)
JOB PAYJOB2
RUN WORKDAYS
REL PAYJOB3
JOB PAYJOB3
RUN WORKDAYS
REL PAYJOB4
JOB PAYJOB4
RUN WORKDAYS
ENDJOB
In the above example, a symbolic variable is used to tag all jobs in the PAYROLL
Application with the 3-character day of the week name (e.g. MON for Monday).
Other examples Here are more examples using the TAG statement.
Associates a character string with a job:
JOB PAYJOB5
TAG IMPORTANT
ENDJOB
JOB PAYJOB6
TAG TIME 18:00
ENDJOB
JOB PAYJOB7
TAG DIVISION 123
ENDJOB
689
TEMPLATE Statement
Overview The TEMPLATE statement is used to name a template and identify any parameters
and variables available during template processing.
Syntax The syntax of the TEMPLATE statement is:
TEMPLATE name ([posct] [parms...])
[LOCALVARIABLES|GLOBALVARIABLES]
TEMPLATE Indicates the beginning of the template definition.
name Indicates the name the template.
posct Indicates the number of positional parameters.
Positional parameters must be passed to the template
in the order specified.
parms Indicates any positional, keyword, or keyword(value)
parameters.
LOCALVARIABLES Defines variables to be used only with the body of the
template.
GLOBALVARIABLES Defines variables to be used within or outside the body
of the template. This is the default.
690
TEMPLATE Statement, Continued
Usage notes Once you use the TEMPLATE statement, specify the statements you want to process
each time the template is used. End the template with the ENDTEMPL statement.
To use a template, specify its name and identify the parameters you are passing to it.
Template processing involves the expansion of a template so that ESP can perform
substitution. For example, if a template is used to define an Application consisting
of 5 jobs, the template is expanded 5 times. During the expansion of the template,
ESP substitutes the appropriate values as per the template definition statements, to
generate the Application.
Templates provide a simplified method of entering data when there is a high degree
of repetition and are useful for defining similar jobs and using other repetitive code.
Templates allow you to use and enforce standards and reduce maintenance.
Templates are available any where CLANG is available:
Page mode
Line mode
ESP Initialization Parameters
ESP Procedures.
Templates are available for use at any time while the same command environment is
active (e.g. Page mode, ESP Event, etc.)
Multiple templates can be used within the input stream (e.g. Application definition).
Related
Statements
For information on working with templates, see the ESP Workload Manager
For information on ending a template definition, see the ENDTEMPL statement.
691
Example 1 The following template is used to define similar jobs in an Application:
APPL PAYROLL
JCLLIB CYBBP01.TESTJOBS.CNTL
TEMPLATE ACCPAY (1,JOBNAME)
JOB %JOBNAME
SUBAPPL ACCPAY
RUN DAILY
TAG CRITICAL
ENDJOB
ENDTEMPL
ACCPAY ACCJOB1
ACCPAY ACCJOB2
ACCPAY ACCJOB3
The TEMPLATE statement indicates:
The name of the template is ACCPAY
One positional parameter called JOBNAME is available for substitution during
template processing.
During the expansion of the template ESP substitutes the appropriate value for
JOBNAME as follows:
ACCJOB1 runs daily, belongs to the ACCPAY subApplication and has a tag of
CRITICAL associated with it
ACCJOB 2 runs daily, belongs to the ACCPAY subApplication and has a tag of
CRITICAL associated with it
ACCJOB3 runs daily, belongs to the ACCPAY subApplication and has a tag of
CRITICAL associated with it.
Example 2 The following is an example of a TEMPLATE definition:
TEMPLATE ANYHOL (3,NAME,DATE,YEAR)
DEFHOL %NAME START(%DATE %YEAR)
ENDTEMPL
In the above example, three positional parameters are defined and must be passed to
the template in the specified order - NAME, DATE and YEAR.
The following is an example of passing data to the template:
ANYHOL XMAS DECEMBER25 1999
In the above example, NAME has the value XMAS, DATE has the value
DECEMBER25, YEAR has the value 1999.
692
TEMPLATE ANYHOL (1,NAME,DATE())
DEFHOL %NAME START(%DATE)
ENDTEMPL
In the above example, one positional parameter is identified and must be passed to
the template in the specified order. This represents the name of a holiday. The
DATE can be specified using any scheduling term ESP recognizes.
ANYHOL XMAS DATE(DECEMBER 25,1999)
In the above example, NAME has the value XMAS and DATE has the value
DECEMBER 25, 1999.
Example 4 The following template is used to define similar jobs in an Application:
APPL PAYROLL
TEMPLATE PAY (1 JOBNAME FREQ(DAILY) NEXT())
JOB %JOBNAME
IF FREQ NE THEN RUN %FREQ
IF NEXT NE THEN RELEASE (%NEXT)
TAG PJOB
ENDJOB
ENDTEMPL
PAY PAYJOB1 NEXT(PAYJOB2,PAYJOB3)
PAY PAYJOB2 NEXT(PAYJOB4)
PAY PAYJOB3 FREQ(WEEKDAYS) NEXT(PAYJOB4)
PAY PAYJOB4 NEXT(PAYJOB5)
PAY PAYJOB5 FREQ(LAST WORKDAY OF MONTH)
In the above example, the TEMPLATE statement indicates:
The name of the template is PAY.
One positional parameter is available for substitution during template processing.
This represents the jobname.
The FREQ variable has the value DAILY.
The NEXT variable is set to null, but can be passed to the template.
During the expansion of the template, ESP substitutes the appropriate value as
follows:
PAYJOB1 runs daily and releases PAYJOB2 and PAYJOB3
PAYJOB2 runs daily and releases PAYJOB4
PAYJOB3 runs Wednesdays and releases PAYJOB4
PAYJOB4 runs daily and releases PAYJOB5
PAYJOB5 runs on the last workday of the month and has no successors.
693
TEMPLATE REGJOB (1,NAME,RUN(),NORUN(),REL())
JOB %JOB
IF RUN NE THEN RUN %RUN
IF NORUN NE THEN NORUN %NORUN
IF REL NE THEN RELEASE %REL
ENDJOB
ENDTEMPL
REGJOB PAYJOB1 RUN(LAST DAY OF MONTH) REL(PAYJOB2)
REGJOB PAYJOB2 RUN(WORKDAYS) NORUN(FRIDAY) REL(PAYJOB3)
REGJOB PAYJOB3 RUN(WED)
As a result of the first statement: NAME has the value PAYJOB1, RUN has the
value LAST DAY OF MONTH, REL has the value PAYJOB2.
As a result of the second statement: NAME has the value PAYJOB2, RUN has
the value WORKDAYS, NORUN has the value FRIDAY, REL has the value
PAYJOB3.
As a result of the third statement: NAME has the value PAYJOB3, RUN has the
value WED.
694
TEMPLIB Statement
Overview The TEMPLIB statement is used to identify the temporary or override JCL library
you want to use as the default for all jobs following this statement. ESP uses JCL
from this library for job submission if it exists. Otherwise it uses JCL from the most
recent JCLLIB statement.
Syntax The syntax of the TEMPLIB statement is:
TEMPLIB dsname
dsname Indicates the name of the data set where the override JCL
resides.
Usage notes This statement identifies the temporary JCL library to be used as the default for all
jobs following this statement. The member name is assumed to be the same as the
job name. If a temporary library is specified, and the job exists in this library, ESP
submits the job from the library. Otherwise, ESP uses the JCL library from the most
recent JCLLIB statement. The //* UNTIL and //* FROM statements can be used to
control the use of temporary JCL.
When using TEMPLIB for a job, it is not necessary to have the job in the JCLLIB if
it exists in the TEMPLIB.
ESP does not automatically delete the job from TEMPLIB when it completes.
Related
information
For information on identifying JCL libraries, see the ESP Workload Manager Users
Guide.
For information on specifying a JCL library, see the JCLLIB statement.
DATASET statement.
Related
information
continued
For information on specifying the member name in which ESP will find a jobs
execution JCL, see the MEMBER statement.
For information on limiting the window in which temporary JCL is used, see the
//* FROM and //* UNTIL statements.
695
TEMPLIB Statement, Continued
Example 1 The following TEMPLIB statement identifies an override JCL library:
APPL PAYROLL
TEMPLIB CYBER.OVERRIDE.CNTL
JOB PAYJOB1
RUN WORKDAYS
ENDJOB
Note: To limit the window in which ESP uses temporary JCL, use the //* FROM
and/or //* UNTIL statements as follows:
//* FROM 9AM DECEMBER 31,1999
//* UNTIL 5PM JANUARY 4TH, 2000
In the above example, ESP uses JCL for PAYJOB1 between December 31
st
, 1999 at
9 am and January 5
th
, 2000 at 5 pm, if it exists in CYBER.OVERRIDE.CNTL.
Otherwise ESP uses JCL from CYBER.JCL.CNTL.
Example 2 The following TEMPLIB statement is used to ensure that JCL from the appropriate
scheduled date is used:
APPL PAYROLL
TEMPLIB CYBER.OVERRIDE.%ESPSYY%ESPSDDD
JOB PAYJOB2
RUN WORKDAYS
ENDJOB
In the above example, ESP uses JCL for PAYJOB2 if it exists in the temporary JCL
library. The name of the temporary library consists of two symbolic variables:
%ESPSYY is the 2-digit scheduled year; %ESPSDDD is the 3-digit Julian day.
Each day ESP uses a different TEMPLIB.
For example, if the scheduled execution date of the Event that invokes this
Application is January 1
st
, 1999, ESP uses the temporary JCL if it exists in
CYBER.OVERRIDE.99001. Otherwise, it uses JCL from CYBER.JCL.CNTL.
696
TEST Command
Overview The TEST command is used to test schedule criteria, prior to actually using them.
This tests any date or schedule specification. ESP responds with the actual date and
time. If you specify a number in parentheses after the TEST commands, ESP
displays as many subsequent dates and times as you indicated.
Syntax The syntax of the TEST command is:
TEST [(n)] criteria
n Indicates how many times the schedule criteria are to be
cycled. The default is 1.
criteria Indicates criteria.
Usage notes You can also test schedule criteria using ESPs ISPF interface - Option E.4 from the
ESP Main Menu.
Related
information
For information on testing schedule criteria, see the ESP Workload Manager Users
Guide.
Example 1 The following TEST command tests schedule criteria:
TEST (5) LAST WORKDAY OF MONTH
In the above example, the last workday in each of the next 5 months are displayed,
as follows:
00.00.00 FRIDAY FEBRUARY 27TH, 1998, DAY 058
00.00.00 TUESDAY MARCH 31ST, 1998, DAY 090
00.00.00 THURSDAY APRIL 30TH, 1998, DAY 120
00.00.00 FRIDAY MAY 29TH, 1998, DAY 149
00.00.00 TUESDAY JUNE 30TH, 1998, DAY 181
697
TEST Command, Continued
Other examples Here are more examples using the TEST command.
Tests the next 10 workdays :
TEST (10) WORKDAYS
Tests the last workday of the year:
TEST LAST WORKDAY OF YEAR
Tests the first workday of each month starting in November, for the next year:
TEST (12) 6PM FIRST WORKDAY OF MONTH STARTING NOVEMBER
Tests the next 5 holidays:
TEST (5) HOLIDAY
Tests the 3
rd
Saturday in May:
TEST 3RD SATURDAY OF MAY
698
THEN Statement
Overview The THEN statement is used in conjunction with an IF statement when the
Syntax The syntax of the THEN statement is:
THEN action-statement
THEN Can only be used when the IF statement is already specified.
Defines the action to be taken when evaluation of an IF
statement returns a true value. To specify multiple actions, use
the DO and ENDDO statements.
action-statement Indicates the action to be taken.
false value.
expression that follows the IF statement returns a true value. When a true value is
returned by the IF statement, ESP processes the statements following the THEN
statement.
If multiple statements are required to be processed, you must begin and end
compound action statements with DO and ENDDO language elements.
Usage notes
continued
If a THEN statement continues to another line, use a line continuation character (
or +). If there is no continuation character, ESP ignores the THEN statement.
The ELSE statement is used in conjunction with an IF statement when the
Related
Statements
Users Guide.
For information on conditional processing, see the IF, ELSE and DO statements.
699
THEN Statement, Continued
Example 1 The following logic is used to process different statements:
SEND TODAY IS MONDAY U(CYB01)
ELSE -
SEND TODAY IS %ESPADAY U(CYB01)
evaluation of this expression is true, ESP sends a message indicating that today is
Monday to CYB01. If the evaluation of this expression is false, ESP sends a
message to CYB01 indicating what today is.
Example 2 The following logic is used to determine when a job runs:
JOB PAYJOB1
IF TODAY(15TH DAY OF MONTH) AND TODAY(TUESDAY) THEN -
RUN TODAY
ENDJOB
In the above example, ESP determines if today is the 15
th
day of the month and
TUESDAY, and if so PAYJOB1 is selected to run.
IF ESPSMM<5 THEN DO
ENDDO
ELSE DO
ENDDO
In the above example, a user-defined symbolic variable called
FINANCIAL_YEAR, which consists of two, 2digit year numbers, is set as
follows:
If the current month is January, February, March or April, use last year followed
by this year
For any other month, use current year followed by next year.
700
TIME Command
Overview The TIME command is used to set the start time of a model sub-period. This allows
you to change environmental factors in the modeling period at specified times.
Type Model command.
Syntax The syntax of the TIME command is:
TIME criteria
criteria Indicates any valid schedule criteria that denote the start of
the sub-period. If the statement contains separators then it
must be enclosed in quotes. The time is relative to the period
specified on the MODEL command.
Usage notes A TIME command remains in effect until another TIME command is issued or until
the end of the modeling period is reached. Any number of TIME commands can be
issued for a modeling period. If not specified, the default is the start time specified
on the MODEL command.
Related
information
For information on beginning and ending the model process, see the MODEL and
ENDMODEL commands.
Guide.
Example 1 The following TIME command is used in conjunction with the INIT command to set
the start time of a model sub-period:
TIME 02:00
INIT SET(15) CLASS(X)
In the above example, an initiator class is set at 2 am.
701
TITLE Command
Overview The TITLE command is used to define a title to be displayed at the top of the next
and subsequent pages of printed data. It also skips to the top of the next page.
Syntax The syntax of the TITLE command is:
TITLE n
[SET]
[DELETE]
[title string}
n Indicates which title line you are defining; the range is 1-7.
The default is 1.
SET Indicates the title for subsequent pages is to be set. An
immediate page eject does not occur.
DELETE Indicates the specified title line is to be deleted.
title string Indicates the title to be displayed. It should be enclosed
within quotes. If you want to use quotes in the title line itself,
double them up.
Usage notes Up to seven title and footing lines can be active at any time. If you specify Title 1
and Title 3, a blank line is placed between the two title lines you specify. If neither
SET nor DELETE is specified, an immediate page eject occurs.
The following are built-in variables which you can use in a title string:

%CE Centers the Parameter within the output line.
%DATE Full date, e.g. SUNDAY 4
th
JANUARY 1998.
%DAY Day of week name, e.g. MONDAY.
%DD Day of month number, i.e. from 01 to 31.
%DDDD Julian day or day of year number. E.g. 365 for last day.
%DOW# Day of week number, e.g. 1 for Sunday, 7 for Saturday,
regardless of calendar settings.
%EVAL Returns the numeric value of an expression. An output-
format descriptor may follow the parameter to request leading
blanks or zeros.
%HH Hour, in 24-hour format, e.g. 14.
%LENGTH Returns the length of the Parameter.
%MM Month number, e.g. 01 if the month is January.
%MMM first three characters of the month, e.g. JAN.
%MM Minute of the hour.
702
TITLE Command, Continued
Usage notes (continued)
%MONTH Month name, e.g. JANUARY.
%PAGE The current page number.
%RJ Justifies the parameter on the right side of the output line.
%SSS Seconds.
%TIME Time, in 24-hour format, e.g. 14.30.00.
%YEAR Year, e.g. 1999.
%YY Last two characters of year, e.g. 99.
Related
information
For information on reporting, see the ESP Workload Manager Users Guide.
Example 1 The following TITLE command is used in a history report:
REPORT
TITLE '%CE(PAYROLL APPLICATION REPORT FOR %DATE)'
FROM 7AM TODAY LESS 2 DAYS
DISPLAY APPLSYS,JOBNAME,JOBNO,RDRONDATE
ENDR
In the above example, a title is associated with this history report.
Example 2 The following TITLE command is used in a modeling report:
DEFPRINT REPORT1 DATASET(ESP.MODEL.REPORT1)
TITLE 1 %CE(CYBERMATION INC.)
TITLE 2 %CE(DATA CENTER OPERATIONS)
In the above example, two titles are associated with this model report.
Example 3 The following TITLE command is used in a batch job:
//ESPCOMND JOB
//SYSIN DD *
TITLE '%CE(ESP DATASETS)'
LDSN
/*
In the above example, a title is associated with the output produced by an ESP
command.
703
TITLE Command, Continued
Other examples Here are more examples of using the TITLE command.
Deletes title 3 from this point on:
TITLE 3 DELETE
Defines a title without generating a page break:
TITLE 4 SET QUARTERY RESULTS
704
TRACE Command
Overview The TRACE command is used to activate the trace facility and allows trace options
to be set.
Authority OPER authority is required to issue the TRACE command
Syntax The syntax of the TRACE parameter is:
TRACE [SET(id[:id])]
[RESET(id[:id])]
[SWITCH|CLOSE|OPEN|STATUS|WRITE]
[REUSE]
SET(id) Indicates one or more record identifiers you want to trace.
You can specify a list of identifiers and a range of identifiers.
RESET(id) Indicates one or more record identifiers you no longer want to
trace.
SWITCH Requests the data set currently in use for the trace facility be
freed. The next trace data set is activated automatically.
With this option, data sets are activated in the sequence in
which they were first defined. Once the last data set in the
sequence is closed, the first trace data set to be defined is
used.
CLOSE Requests the closure of the trace data set currently in use, but
prevents switching to the next trace data set. The buffers
defined using TRACEDEF automatically continue to hold
trace data in core until a TRACE OPEN command is issued.
OPEN Requests opening of the trace data set most recently active.
This is used after TRACE CLOSE is issued to reactivate the
same trace data set.
REUSE Indicates the data set currently in use for the trace facility be
checkpointed so that subsequent writes to it begin at the
checkpoint rather than at the start of the data set.
WRITE Writes to the trace data set to clear any buffered data.
STATUS Displays information indicating where the trace facility is
active. Display includes how many records were written
since trace was activated, the current trace data sets in use,
and which data set is currently active.
705
TRACE Command, Continued
Usage notes TRACE is useful as a problem-solving tool. On occasion Cybermation Technical
Support personnel may ask you to SET a specific trace record ID to provide
information to help with trouble shooting.
If you wish to capture only records relating to Event processing (i.e. type 601), use
the ESPPARM AUDITLOG ddname in the ESP started task procedure or the
AUDITLOG Initialization Parameter. This allows the use of a pre-allocated
SYSOUT for Event activity and eliminates the need to use the TRACEDEF and
TRACE commands.
Related
information
For information on trace commands and a list of trace records, see the ESP
Diagnostic and Recovery Guide.
For information on displaying Event log data collected in the trace data set, see the
LOGPRT command.
For information on printing trace data, see the TRACEPRT command.
Example 1 The following TRACE command activates the trace facility:
OPER TRACE SET(602:604,607)
In the above example, a trace is activated and specifies that record IDs 602 through
604, and 607 should be traced.
Example 2 The following TRACE command checkpoints the data set currently used for the
trace facility:
OPER TRACE SWITCH REUSE
In the above example, the current data set used for the trace facility is checkpointed
before switching to the next trace data set. When the current trace data set is later
reused, records are written starting at the checkpoint.
Example 3 The following TRACE command turns off the trace facility for specific records:
OPER TRACE RESET(602:604)
In the above example, the trace is turned off for record Ids 602 through 604.
706
TRACE Command, Continued
Example 4 The following TRACE commands write out buffered data and close the trace data
set:
OPER TRACE WRITE
OPER TRACE CLOSE
In the above example, prior to printing the trace data set, the buffered data is written
out and the trace data set is closed.
707
TRACEDEF Command
Overview The TRACEDEF command is used to identify the data sets to be used to record
information collected by the TRACE facility.
Authority OPER authority is required to issue the TRACEDEF command.
Syntax The syntax of the TRACEDEF parameter is:
TRACEDEF DSN(dsname[,dsname]...)
[BUF(size,count)]
dsname Indicates the name of one or more data sets to be used as trace
data sets. Separate data set names with a blank or comma.
Specifying multiple trace data sets allows you to use the
SWITCH parameter with TRACE to free up one trace data set
and switch to another.
size, count Indicates the buffers you want to use for the trace data sets
you define. Size specifies the buffer size and count identifies
how many buffers are required. This defaults to (4096,4)-
(four buffers, each one 4096 bytes).
Usage notes Before using the TRACE facility, you must allocate one or more trace data sets.
You must identify these data sets to ESP with the TRACEDEF command.
You do not have to specify any DCB attributes when you initially allocate the data
sets, because ESP does this automatically.
Trace data sets use: DCB=(RECFM=VB,LRECL=4096,BLKSIZE=4100).
The buffers you define continue to hold trace data until each one becomes full. At
this point, the data is written automatically to the trace data set and another buffer is
used.
Related
information
For information on defining a trace data set at the initialization parameter level, see
For information on activating the trace facility, see the TRACE command.
For information on trace commands, see the ESP Diagnostic and Recovery Guide.
708
TRACEDEF Command, Continued
Example 1 The following TRACEDEF command defines 2 trace data sets:
TRACEDEF DSN(ESPCYB.TRACE1, ESPCYB.TRACE2) BUF(23400,3)
In the above example, two trace data sets that each have three 23400 byte buffers are
defined.
709
TRACEPRT Command
Overview The TRACEPRT command is used to print trace data.
Authority OPER authority is required to issue the TRACEPRT command
Syntax The syntax of the TRACEPRT command is:
TRACEPRT DSN(dsn[,dsn])
[FROM(criteria)]
[SELECT(id[:id])]
[APPL(appl[,appl...])]
[JOB(job[,job...])]
dsn Indicates the name of one or more trace data sets.
criteria Indicates any valid schedule criteria that represent a time
range.
id Indicates a trace ID to print. Ranges are supported.
appl Allows selection by Application name. Wildcards are
supported.
job Allows selection by jobname. Wildcards are supported.
Usage notes Issue the TRACEPRT command in batch or from Page mode, after collecting trace
data from a TRACE command.
Note:
For Cybermation diagnostic purposes, the contents of the raw trace data set are
required.
Related
information
For information on using the TRACE command, see the TRACE command.
For information on trace commands, see the ESP Diagnostic and Recovery Guide.
Example 1 The following TRACEPRT command prints a trace data set:
TRACEPRT DSN(CYBER.TRACE1) FROM(6AM YESTERDAY UNTIL 6AM
TODAY)
In the above example, CYBER.TRACE1 is printed from 6 am yesterday to 6 am
today.
710
TRACEPRT Command, Continued
Example 2 The following TRACEPRT command prints trace data based on an Application
name:
TRACEPRT DSN(CYBER.TRACE1) APPL(PAYROLL)
In the above example, trace data set information for the PAYROLL Application is
printed.
Example 3 The following TRACEPRT command prints a range of trace IDs:
TRACEPRT DSN(CYBER.TRACE1) SELECT(601:603)
In the above example, trace IDs 601 to 603 are printed.
711
TRACKDEF Command
Overview The TRACKDEF statement is used to specify tracking definitions in a Job Tracking
Definition Table.
Type Job Tracking Definition Table Statement.
Syntax The syntax of the TRACKDEF statement is:
TRACKDEF [NAME(string)]
[JOB]
[STC]
[TSU]
[RACID(string)]
[PGMR(string)]
[CLASS(classid)]
[ACCOUNT1(string)]
[ACCOUNT2(string)]
[ACCOUNT3(string)]
[ACCOUNT4(string)]
[NOTRACK]
[MODEL(modelname)]
NAME(string) Indicates a one to eight character jobname to be matched on.
Asterisks or a hyphen are used to perform masking. NAME
can also be specified as JOBNAME.
JOB/STC/TSU Indicate jobs, started tasks or TSO users be tracked. If these
keywords are not used, the TRACKDEF entry is not specific
and all will apply.
RACID(string) Indicates the security system user ID associated with the job.
CLASS(classid) Indicates the jobs execution class. This can be up to eight
characters in a JES3 environment.
ACCOUNT1 Indicates the jobs first account number. Only the first eight
characters are checked.
ACCOUNT2 Indicates the jobs second account number.
ACCOUNT3 Indicates the jobs third account number.
ACCOUNT4 Indicates the jobs fourth account number.
PGMR(string) Indicates the programmer name field associated with the job.
All 20 character positions can be checked.
NOTRACK Indicates a job matching the TRACKDEF entry not be
tracked.
MODEL Indicates the name of the tracking model to be associated with
a job, started task or TSO user. If neither NOTRACK or
MODEL is specified, NOTRACK is assumed. The MODEL
keyword must be used if a job is to be tracked. You can
override this using the MODEL statement for a job in an
Application.
712
TRACKDEF Command, Continued
Usage notes A job tracking definition table identifies the characteristics of the jobs you want ESP
to track. ESP can track jobs based on jobname, execution class, programmer name,
account number, job type, or the user ID associated with the job.
Job tracking definition tables allow the following:
You can define your own wildcard characters in the table. These characters give
you great flexibility in defining the property of the job you want ESP to use as the
job tracking parameter.
You are not restricted to a job name or prefix when defining the tracking
parameter. Instead, you can choose from a larger set of properties of the job when
defining the parameter. For example, you can choose the jobs execution class, or
the name of the programmer.
A job tracking definition table consists of a set of ESP WILDCARD and
TRACKDEF statements, respectively, in a sequential data set or in a member of a
PDS. The use of WILDCARD is optional.
The order of the TRACKDEF statements is important. When tracking data is
received for a job, ESP scans the TRACKDEF entries in sequence until a match is
found. ESP then takes the action specified by that entry. The entry can identify
whether the job is to be tracked or not. If the job is to be tracked, the default
tracking model for the job is specified. If no matching entry is found, the job is not
tracked.
To track STCs or TSUs, you must identify these are to be tracked using the
TRACKOPT command or ESP Initialization Parameter. You can use TRACKDEF
statements to identify which STCs or TSUs to track.
You can also test a job tracking definition table using ESPs ISPF interface - Option
M.4 from the ESP Main Menu.
Related
information
For information on loading job tracking definition tables (JTDT), see the
LOADJTDT command.
For information on defining wildcard characters used in a job tracking definition
table, see the WILDCARD statement.
For information on defining a tracking model, see the DEFTM command.
For information on displaying the status of tracked jobs, see the LJ command.
For information on specifying tracking options, see the TRACKOPT command.
713
Example 1 The following TRACKDEF command specifies a tracking definition:
TRACKDEF NAME(-) MODEL(MODEL1)
In the above example, all jobs are tracked using tracking model MODEL1.
Example 2 The following is an example of a job tracking definition table:
TRACKDEF JOB NAME(J) MODEL(PRODJOBS)
TRACKDEF JOB NAME(U) MODEL(TESTJOBS)
The first tracking definition statement indicates ESP uses tracking model
PRODJOBS to track all jobs that start with the letter J.
The second statement indicates ESP uses tracking model TESTJOBS to track all
jobs that start with the letter U.
714
WILDCARD # 09 /* NUMERICS */
WILDCARD $ AZ /* ALPHABETICS */
WILDCARD + 09AZ /* ALPHANUMERIC */
TRACKDEF JOB NAME(DUMMYJOB) NOTRACK
TRACKDEF JOB NAME(CYBJOB) MODEL(CYBMODEL)
TRACKDEF JOB NAME($$$$####) MODEL(PRODJOBS)
TRACKDEF ACCOUNT1(CYB3000) MODEL(TESTJOBS)
TRACKDEF RACID(CYBFM) MODEL(DEMOMDL)
TRACKDEF JOB CLASS(G) MODEL(MODELG)
TRACKDEF JOB NAME() MODEL(MODEL1)
TRACKDEF STC NAME() MODEL(MODEL1)
The first wildcard character # matches all numeric characters
The $ wildcard character matches the alphabetic characters, A through Z,
inclusive
The + wildcard character matches the alphanumeric characters, A through Z,
inclusive, and the digits 0 through 9, inclusive
The 1
st
tracking definition statement indicates ESP does not track a job called
DUMMYJOB
The 2
nd
tracking definition statement indicates ESP uses model CYBMODEL to
track jobs where names begin with CYBJOB
The 3
rd
tracking definition statement indicates ESP uses tracking model
PRODJOBS to track jobs whose names consist of four alphabetic characters
followed by four numeric characters
The 4
th
TESTJOBS to track jobs where the first account number is CYB3000
The 5
th
DEMOMDL to track jobs with a RACID that begins with CYBFM
The 6
th
MODELG to track class G jobs
The 7
th
and 8
th
tracking statements indicate ESP will track all other jobs and
started tasks using model MODEL1.
715
Other examples Here are more examples using the TRACKDEF statement.
Class T jobs regardless of jobname are not tracked:
TRACKDEF NAME(-) CLASS(T)
Track all class P jobs using the tracking model PROD:
TRACKDEF CLASS(P) MODEL(PROD)
Track all started tasks starting with the prefix CICS using the model JOBMON:
TRACKDEF STC NAME(CICS-) MODEL(JOBMON)
Track all jobs submitted by ESP:
TRACKDEF MODEL(DEFAULT)
Track all jobs regardless of jobname. The default tracking model to be used is
obtained by concatenating the first two characters of the jobname with the characters
MODEL. The job DX12345 uses the model DXMODEL:
TRACKDEF JOB NAME(-) MODEL(NAME(1:2),MODEL)
Do not track jobs with a programmer name field starting with CYBED:
TRACKDEF PGMR(CYBED-) NOTRACK
Track jobs starting with X using the model XSYS:
TRACKDEF JOB NAME(X-) MODEL(XSYS)
716
TRACKING Command
Overview The TRACKING command is used to enable or disable the ESP tracking facility.
Authority OPER authority is required to issue the TRACKING command.
Syntax The syntax of the TRACKING command is:
TRACKING [COLLECT|NOCOLLECT]
[STORE|NOSTORE]
[LOG|NOLOG]
COLLECT Indicates SMF recording is activated. SMF tracking data is
stored in the TRAKFILE and the History data set(s) is
updated (unless NOSTORE is specified).
NOCOLLECT Indicates SMF recording is deactivated. No SMF data is
collected, no tracking data is written to the TRAKFILE and
the History data set(s) is NOT updated.
STORE Indicates tracking data from SMF be stored in the
TRAKFILE and the History data set(s) be updated.
NOSTORE Indicates the tracking processor be quiesced. No tracking
data is written to the TRAKFILE and the History data set is
not updated. The data is temporarily buffered to the
checkpoint data set until STORE is requested.
LOG Reserved for future use.
NOLOG Reserved for future use.
717
TRACKING Command, Continued
Usage notes If no options are specified, the current tracking settings are displayed (the NOLOG
field of the display is reserved for future use). If an option is specified, it is added to
the current tracking settings.
The COLLECT and STORE options should be active if you wish to perform normal
tracking functions.
The COLLECT and NOCOLLECT keywords control the collection of SMF data
that is used by the tracking processor to update the TRAKFILE and the History data
set(s). When NOCOLLECT is specified, SMF data is not captured and the tracking
is lost.
The NOSTORE keyword can be used to quiesce the tracking processor temporarily.
All tracking functions including Job Monitoring are suspended when NOSTORE is
specified. This is useful when you need to perform maintenance on an ESP History
File. Tracking data is buffered to the checkpoint data set until STORE is requested.
When STORE is specified to bring the tracking processor out of quiesced state, any
data that was buffered is written to the TRAKFILE and the History data set(s) is
updated.
Note: The tracking processor should not be left in the NOSTORE mode for long
periods of time as the checkpoint data set could fill up causing tracking data to be
lost.
Related
information
For information on tracking, see the ESP Workload Manager Administrators Guide.
Example 1 The following TRACKING command displays tracking settings:
OPER TRACKING
In the above example, current tracking settings are displayed.
Example 2 The following TRACKING command sets tracking options:
OPER TRACKING COLLECT STORE
In the above example, SMF recording is activated. SMF tracking data is collected
and stored in the TRAKFILE and the History data set is updated.
Example 3 The following TRACKING command quiesces the tracking processor:
OPER TRACKING NOSTORE
In the above example, the tracking processor is quiesced.
718
TRACKOPT Command
Overview The TRACKOPT command is used to set various tracking options.
Authority OPER authority is required to issue the TRACKOPT command.
Syntax The syntax of the TRACKOPT command is:
TRACKOPT [STC|NOSTC]
[TSU|NOTSU]
[SYSMSGS|NOSYSMSGS]
[MASTER|SLAVE]
[JAT|NOJAT]
[TRACK_PURGE|NOTRACK_PURGE]
[POST_OLDEST|NOPOST_OLDEST]
STC Indicates started tasks should be tracked.
NOSTC Indicates tracking of started tasks should not occur.
TSU Indicates TSO users should be tracked.
NOTSU Indicates tracking of TSO users should not occur.
SYSMSGS Indicates system messages should be intercepted.
NOSYSMSGS Indicates interception of system messages should not occur.
MASTER Indicates this as the MASTER system for Application
processing.
SLAVE Indicates this as a SLAVE system.
JAT Indicates a Job Authorization Table is to be used. This only
applies if you are using ESPs internal security.
NOJAT Indicates Job Authorization Tables are not used. This only
applies if you are using ESPs internal security.
719
TRACKOPT Command, Continued
Syntax (continued)
TRACK_PURGE Indicates jobs are tracked through the OUTPUT P-Node.
NOTRACK_PURGE Indicates jobs are not tracked through the OUTPUT P-
Node.
POST_OLDEST Indicates External and Manual jobs are posted complete
in the oldest active generation of an Application.
NOPOST_OLDEST Indicates External and Manual jobs are posted complete
in all generations of an Application. This is the default.
Usage notes If no options are specified, the current tracking options are displayed (the NOLOG
field of the display is reserved for future use). If an option is specified, it is added to
the current tracking options.
TRACKOPT should be specified on each system in a multi-access spool
environment. It is normally specified as an ESP Initialization Parameter.
The MASTER and SLAVE keywords apply only to Application processing. One
system should be identified as the MASTER system and any other systems should
be identified as the SLAVE systems. All Events that create Applications should be
scheduled on the MASTER system.
TRACKOPT is normally specified as an Initialization Parameter. If you use the
TRACKOPT command, options specified in the Initialization Parameters are
overridden. The information is saved in the checkpoint data set, which means that it
is retained across IPLs. However, for a cold start, any information specified in the
Initialization Parameters is used.
When an EXTERNAL or MANUAL job completes and multiple generations of an
Application exist, ESP must decide which generation of the Application to post the
job complete in. Use the POST_OLDEST or NOPOST_OLDEST keywords to
control this.
Most installations do not need to track jobs through to purge. If this is the case,
TRACKOPT NOTRACK_PURGE should be specified. This allows data to be
stored on ESPs TRAKFILE for a longer period of time.
Related
information
For information on setting tracking options at the Initialization Parameter level, see
For information on setting up tracking, see the ESP Workload Manager
720
TRACKOPT Command, Continued
Example 1 The following TRACKOPT command displays tracking options:
OPER TRACKOPT
In the above example, current tracking options are displayed.
Example 2 The following TRACKOPT command sets tracking options:
OPER TRACKOPT STC SYSMSGS
In the above example, started tasks and system messages are tracked
Example 3 The following TRACKOPT command sets tracking options:
OPER TRACKOPT NOSTC
In the above example, the tracking of started tasks is turned off.
721
TRDFLT Command
Overview The TRDFLT command specifies an installation-default to be used when an Event is
triggered manually.
Authority OPER authority is required to issue the TRDFLT command.
Syntax The syntax of the TRDFLT command is:
TRDFLT {ADD}
{REPLACE}
ADD Indicates a manual trigger of an Event should be performed in
addition to the next scheduled execution.
REPLACE Indicates a manual trigger replaces the next scheduled
execution for an Event. This is the normal default.
Usage notes The option you specify on the TRDFLT command applies until the next time ESP
initializes. This command is normally specified as an ESP Initialization Parameter.
You can override the TRDFLT setting when you use the TRIGGER command for an
Event.
Related
information
For information of triggering Events, see the TRIGGER command.
Example 1 The following TRDFLT command specifies a default for manually triggered Events.
TRDFLT ADD
In the above example, the installation default for manually triggered Events is set to
ADD, i.e. Events are triggered in addition to their regularly scheduled execution
unless the REPLACE option is specified on the TRIGGER command.
722
TRIGGER Command
Overview The TRIGGER command is used to trigger the execution of an Event. The Event
execution either replaces the next scheduled execution (that is brings forward the
next execution), or it can be a temporary addition to the schedule.
Authority TRIGGER can be issued either as an ESP operator (OPER) command or as an ESP
general sub-command.

When issued as an ESP OPER command, access is enabled to all Events, but the
issuer must have authorization for OPER commands (or to the TRIGGER command
explicitly if SAFOPTS OPERCMDS is in effect).

When issued as an ESP general sub-command, access is restricted to Events for
whose prefix the issuer is authorized. Authorization is required for the ESP.GROUP
Event prefix RACF resource (UPDATE authority) or for the ESP.GROUP Event
prefix RACF resource (READ authority).
Syntax The syntax of the TRIGGER command is:
{TRIGGER|TR} eventid
[REPLACE|ADD]
[AT(trigtime)]
[NOXEQ]
[SYSTEM(sysid)]
[FORCE|SATISFY]
[USER1(userinfo)]
[USER2(userinfo)]
[USER3(userinfo)]
[USER4(userinfo)]
[HOLD]
[ROOT(jobname...)]
723
TRIGGER Command, Continued
eventid Indicates the name of the Event to be triggered. If prefix is
not specified, your current group prefix is used.
REPLACE Indicates this execution is to replace only the next scheduled
execution of the Event. The TRDFLT Initialization
Parameter sets the default.
ADD Indicates this execution is to be made in addition to the
normal schedule. The normal schedule is not changed. The
TRDFLT Initialization Parameter sets the default.
trigtime Indicates a time, and optionally a date, at which the trigger is
to occur. If you use blanks or commas, enclose the string in
quotes. If this parameter is omitted, the current time is used.
If this parameter specifies a time/date in the past, the Event is
triggered now.
NOXEQ Bypasses the next scheduled execution.
sysid Indicates the ID of the system on which you want the Event to
execute.
FORCE Trigger Event ignoring any signals.
SATISFY Trigger Event satisfying any signals.
userinfo Indicates up to 80 characters of user data enclosed in single
quotes.
HOLD Can be used to place an Application on hold when the Event
being triggered generates an Application. No activity will
take place in the Application until it is released using the
APPLJOB command or CSF.
ROOT Indicates one or more jobnames belonging to the Application
generated by this Event. This requests that only those jobs
specified are to be submitted. Each jobname specification
can be an individual jobname or can include a plus sign (+) to
indicate that this job and all successors are to be selected.
ESP builds the named jobs as part of the Application
regardless of their frequency. Any successors of the named
jobs will only be included if their other selection criteria (in
terms of date and time) are satisfied.
Usage notes When using the ADD option, the Event is scheduled for execution as if a
SCHEDULE statement is being processed. The REPLACE option brings forward
the next scheduled activity for that Event. If the next statement in the Event is a
HOLD statement, it is processed by the TRIGGER, rather than by an execution of
the Event. Before issuing a TRIGGER REPLACE, you should be aware of the next
action to be processed for that Event. A TRIGGER ADD always causes the
execution of an Event.
724
Usage notes
continued
Use the AT keyword to specify a future time and date for the trigger to occur. If the
REPLACE option is used, the trigger replaces the next scheduled execution on or
after the specified time. The ADD option results in an additional execution.
The NOXEQ keyword is used to suppress an already scheduled Event execution. If
the AT keyword is not used, the next scheduled execution is suppressed. If a time is
specified through an AT keyword, a schedule entry for the specified time is searched
for, and if found, it is marked for deletion. The NOXEQ option is used to suppress
the execution of an Event already on the schedule, which usually spans no more than
24 hours. Use the LISTSCH command to display the schedule if you are unsure.
Usage notes
continued
If you wish to re-trigger an Event that has already executed, you can use a trigger
time in the past. Variables are resolved and jobs selected based on this past date.
Triggering an Event for a time in the past does not honor DELAYSUB or
EARLYSUB statements coded in an Application, unless REALNOW is used in the
schedule criteria, i.e. DELAYSUB REALNOW PLUS 10 MINUTES.
The USER1-USER4 fields can be used to pass user data to the Event (and
consequently any ESPPROC the Event invokes) being triggered. This user data
replaces the %USER1-%USER4 variables, respectively, when they are encountered.
Use the ROOT parameter if you wish to build an Application of certain jobs. This is
useful if you wish only to run, or rerun, part of an Application.
If you trigger an Event manually, the SYSTEM identifier in the Event is ignored.
To trigger an Event on a particular system, use the SYSTEM parameter on the
TRIGGER command.
You can also trigger Events using ESPs ISPF interface - Option E.3 from the ESP
Main Menu.
Related
information
Example 1 The following TRIGGER command triggers an Event:
TRIGGER CYBER.PAYROLL
In the above example, the TRIGGER command brings forward the next scheduled
execution of CYBER.PAYROLL for immediate execution assuming the TRDFLT
Initialization Parameter is set to REPLACE.
725
Example 2 The following TRIGGER command triggers an Event at a specific time:
TRIGGER CYBER.PAYROLL AT(3PM TODAY)
execution of CYBER.PAYROLL and schedules it for 3 pm today.
Example 3 The following TRIGGER command triggers an additional execution of an Event at a
specific time:
TRIGGER CYBER.PAYROLL AT(9AM JULY 1ST) ADD
In the above example, the TRIGGER command triggers an additional execution of
CYBER.PAYROLL and schedules it for 9 am on JULY 1
ST
.
Example 4 The following TRIGGER command suppresses an Events execution:
TRIGGER CYBER.PAYROLL NOXEQ AT(9PM)
In the above example, the TRIGGER command suppresses the execution of
CYBER.PAYROLL, which is scheduled for 9 pm that evening.
Example 5 The following TRIGGER command triggers an Event and passes user data:
TRIGGER CYBER.PAYROLL USER1(PAYJOB99)
execution of CYBER.PAYROLL and passes user data, in this case a jobname is
passed to an ESP Procedure invoked by this Event.
Example 6 The following TRIGGER command triggers an Event at a specific time to build an
Application containing certain jobs:
TRIGGER CYBER.PAYROLL AT(4PM TODAY) REPLACE -
ROOT(PAYJOB1,PAYJOB6+)
execution of CYBER.PAYROLL and schedules it for 4 pm today. The Application
invoked by this Event is built with jobs PAYJOB1, PAYJOB6 and PAYJOB6s
successors.
726
Example 7 The following TRIGGER command triggers an Event for a time in the past:
TRIGGER CYBER.PAYROLL AT(YESTERDAY) ADD -
ROOT(PAYJOB1,PAYJOB3,PAYJOB5+)
In the above example, CYBER.PAYROLL is triggered as if it were yesterday. The
Application invoked by this Event is built with jobs PAYJOB1, PAYJOB3,
PAYJOB5 and PAYJOB5s successors.
Note: Any date-specific symbolic variables resolve to yesterdays date.
Example 8 The following TRIGGER command triggers an Event on a specific system:
TRIGGER CYBER.PAYROLL SYSTEM(ESPM)
In the above example, CYBER.PAYROLL executes on system ESPM.
727
TRYJOIN Command
Overview The TRYJOIN command is used when an ESP subsystem could not join its XCF
group when it was started. This occurs when, from within ESP, an ESP subsystem is
started with a conflicting member name. For example, another active XCF member
with the same name already exists.
Authority OPER authority is required to issue the TRYJOIN command.
Syntax
The syntax of the TRYJOIN command is:
TRYJOIN MEMBER(member)
member Indicates the member name under which ESP joins the XCF
group. It can be up to 16 alphanumeric or national characters.
It must not be specified as MISSING.
This overrides the MEMBER operand in the SYSPLEX
statement.
Message Upon successful initialization into the XCF group, the following message is issued:
MESSAGE: 4303I
ESP xxxx has joined XCF group yyyy as member zzzz
728
UNALLOC Command
Overview The UNALLOC command is used to unallocate a data set from ESP.
Authority OPER authority is required to issue the UNALLOC command.
Syntax The syntax of the UNALLOC command is:
UNALLOC dsname
dsname Indicates the data set name to be unallocated.
Usage notes This command may be required when ESP wont let go of a data set. This
sometimes happens when a user uses some REXX code and does not free the file.
Related
information
For information on unallocating data sets preallocated with the PREALLOC
command, see the PREALLOC command.
Example 1 The following UNALLOC command unallocates a data set from ESP:
OPER UNALLOC SYS3.ESP.TESTPROC
In the above example, SYS3.ESP.TESTPROC is unallocated from ESP.
729
//* UNTIL Statement
Overview The //* UNTIL statement is used in combination with the TEMPLIB statement to
indicate that temporary JCL for a job is to be used until a particular date. The
TEMPLIB statement is used in an ESP Procedure to indicate a temporary/override
JCL library.
Syntax The syntax of the //* UNTIL statement is:
//*UNTIL criteria
Usage notes The //* UNTIL statement is used in a JCL library that has been identified as a
temporary JCL library using the TEMPLIB statement.
A single blank separates the //* and the UNTIL.
The //* UNTIL statement is only available in JCL and must start in card column 1
and must be the first statement in the JCL. ESP checks the UNTIL date to
determine whether the JCL should be used. If no time is specified, the start-of-day
time is used (default 00:00).
ESP compares the scheduled time and date of the Event to the criteria on the //*
UNTIL statement to decide whether or not it uses the JCL in the TEMPLIB for a
job. If the //* UNTIL date and time has passed ESP uses the JCL from the last
defined JCLLIB in the Application.
Related
information
For information on further limiting the window in which temporary JCL is used, see
the //* FROM statement.
For information on specifying a temporary/override JCL library, see the TEMPLIB
statement.
730
//* UNTIL Statement, Continued
Example 1 The following //* UNTIL statement used in the JCL indicates a time and date until
which temporary JCL should be used:
//* UNTIL 9AM MAY 24,1998
In the above example, temporary JCL for PAYJOB1 is used until 9 am on May 24,
1998.
Example 2 The following //* UNTIL statement used in the JCL indicates a time and date until
which temporary JCL should be used:
//* UNTIL AUGUST 6, 1998
//PAYJOB2 JOB CYB,CLASS=A,MSGCLASS=O
In the above example, temporary JCL for PAYJOB2 is used until 00:00 (default) on
August 6, 1998.
Example 3 The following //* FROM and //* UNTIL statements used in the JCL indicate a time
and date window when temporary JCL should be used:
//* FROM 9AM NOVEMBER 27, 1998
//* UNTIL 4PM NOVEMBER 30, 1998
In the above example, temporary JCL for PAYJOB3 is used from 9 am on

November 27,1998 up to, but not including, 4 pm on November 30, 1998.
731
USE Command
Overview The USE command is used to display statistics relating to Events, Applications and
jobs. These statistics represent the activity for this ESP system only. No counts are
shown for any ESP slave systems or any other remote ESP systems.
Type ESP Main Menu command.
Syntax The syntax of the USE command is:
USE
Usage notes Enter the USE command from the ESP main menu or the ESPCTR command from
Page mode to display ESP internal activity. Both commands produce the same
results but the formatting of those results is different.
Use the USE command to displays statistics on Applications completed,
Applications created, Events executed and jobs submitted. These activities are
measured on the following intervals: this year, this month, this day, since last ESP
start.
These counters are reset with an ESP cold start or with the ESPCTR command.
Related
information
For information on displaying ESP internal activities, see the ESPCTR command.
Example 1 The following is an example of the display produced by the USE command.
This This This Since Last
Activity Year Month Day ESP Start
------------------------------------------------------------------------------
Applications completed 499 499 13 143
Applications created 737 737 27 211
Events executed 2220 2220 43 594
Jobs submitted 1190 1190 13 365
In the above example, ESP internal activities are displayed.
732
USER Command
Overview The USER command is used to identify you as a valid ESP user when invoking ESP
in batch. This command is not necessary if you are using a security product.
Syntax The syntax of the USER command is:
USER userid/password
userid Indicates your user ID.
password Indicates your current ESP password.
Usage notes When your user ID was defined, a password was assigned to it. The PASSWORD
command is used to change your password.
Related
information
For information on altering the ESP password associated with your user ID, see the
PASSWORD command.
Example 1 The following USER command identifies a valid ESP user:
//JOB1 JOB ...
//S1 EXEC PGM=ESP,REGION=4000K
//SYSIN DD *
USER USER01/APPLES
In the above example, USER01 is identified as a valid ESP user.
733
USERMOD Command
Overview The USERMOD command is used to define the ESP user modifications to be
implemented.
Authority OPER authority is required to issue the USERMOD command
Syntax The syntax of the USERMOD statement is:
USERMOD [SET(usermodid[:usermodid])]
[RESET(usermodid[:usermodid])]
[LIST]
usermodid Indicates a number, list of numbers, or range of numbers from
1-255.
SET Turn on the usermod.
RESET Turn off the usermod.
LIST List the active usermods.
Usage notes User modification status is preserved across a restart of ESP, but not an IPL.
You can specify both SET and RESET in the same USERMOD statement. In this
case, SET is processed before RESET.
USERMODs are normally set in the ESP Initialization Parameters.
Related
information
For information on activating the usermods available with ESP, see the ESP
Workload Manager Installation Guide.
Example 1 The following USERMOD command displays USERMODs:
OPER USERMOD
In the above example, active USERMODs are displayed.
734
USERMOD Command, Continued
Example 2 The following USERMOD command turns on a USERMOD:
OPER USERMOD SET(33)
In the above example, USERMOD 33 is activated.
Example 3 The following USERMOD command turns on two USERMODs:
OPER USERMOD SET(33,36)
In the above example, USERMODs 33 and 36 are activated.
Example 4 The following USERMOD turns on a range of USERMODs:
OPER USERMOD SET(33:36)
In the above example, USERMODs 33, 34, 35 and 36 are activated.
Example 5 The following USERMOD turns off a USERMOD:
OPER USERMOD RESET(33)
In the above example, USERMOD 33 is deactivated.
Example 6 The following USERMOD command activates user modifications:
OPER USERMOD SET(1,5:7,18,22:27)
In the above example, USERMODs 1, 5-7, 18 and 22-27 are activated.
Example 7 The following USERMOD command activates and deactivates user modifications:
OPER USERMOD SET(5:9) RESET(7)
In the above example, because SET is processed before RESET, the results of the
above example are as follows:
USERMODs 5-9 are activated
USERMOD 7 is deactivated.
735
VS Command
Overview The VS command is used to issue a command to the operating system.
Authority OPER authority is required to issue the VS command. Some commands may have
been restricted by your security system or by a user exit.
Syntax The syntax of the VS command is:
VS command text
[UCMID(cc)]
command text Indicates the text of the command, enclosed within quotes. If
the text contains embedded quotes, they should be doubled
up.
cc Indicates the UCMID that receives output from the command.
Usage notes You can use VS to issue operation system command such as JES commands and
MVS commands, including ESP operator commands.
Multiple VS commands are allowed in an Event. VS commands can be issued from
an ESP Procedure.
Related
information
For information on issuing operating system commands, see the ESP Workload
Example 1 The following VS command issues a JES2 command:
EVENT ID(CYBER.INIT_START)
SCHEDULE 6AM DAILY
VS $SI1-10
ENDDEF
In the above example, initiators 1 through 10 are started at 6 am daily.
736
VS Command, Continued
Example 2 The following VS command starts a started task:
EVENT ID(CYBER.START_IMS)
SCHEDULE 6AM DAILY
VS S IMS10
ENDDEF
In the above example, IMS10 is started at 6 am daily.
Example 3 The following VS command triggers an Event :
JOB MORE.WORK LINK PROCESS
RUN DAILY
VS F ESPM,TRIGGER CYBER.BACKUPS
ENDDEF
In the above example, a VS command is placed within a job definition to trigger
CYBER.BACKUPS.
Example 4 The following VS command shuts down a started task:
EVENT ID(CYBER.START_IMS)
SCHEDULE 6AM DAILY
VS F CICS,CSMT SHU,Y UCMID(05)
ENDDEF
In the above example, a command is issued as if it came from console 05.
737
WILDCARD Statement
Overview The WILDCARD statement is used to define wildcard characters for use in defining
tracked jobs.
Type Job Tracking Definition Table Statement.
Syntax The syntax of the WILDCARD statement is:
WILDCARD char
string
char Wildcard character.
string Consists of a string containing all the valid characters that the
wildcard can match.
Usage notes The wildcard character can be any printable character, with the exception of the
comma, blank, left or right parentheses, semicolon or quote. A - between two
characters indicates a range of valid characters, starting with the character on the left
and extending through the EBCDIC sequence to the character on the right, inclusive.
Use of the WILDCARD statement is optional. It can be used when you have strict
naming standards for jobs.
Related
information
For information on loading job tracking definition tables (JTDT), see the
LOADJTDT command.
738
WILDCARD Statement, Continued
WILDCARD # 09 /* NUMERICS */
WILDCARD $ AZ /* ALPHABETICS */
WILDCARD + 09AZ /* ALPHANUMERIC */
TRACKDEF JOB NAME(DUMMYJOB) NOTRACK
TRACKDEF JOB NAME(PAY) MODEL(PAYMODEL)
TRACKDEF JOB NAME($$$$####) MODEL(PRODJOBS)
The first wildcard character # matches all numeric characters
The $ wildcard character matches the alphabetic characters, A through Z,
inclusive
The + wildcard character matches the alphanumeric characters, A through Z,
inclusive, and the digits 0 through 9, inclusive
The 1
st
tracking definition statement indicates ESP does not track a job called
DUMMYJOB.
The 2
nd
tracking definition statement indicates ESP uses model PAYMODEL to
track jobs where names begin with PAY
The 3
rd
PRODJOBS to track jobs whose names consist of four alphabetic characters
followed by four numeric characters.
739
XCF DELETE Command
Overview The XCF DELETE command is used to remove quiesced or failed XCF member(s)
from the XCF group.
Type ESP XCF command.
Entering
commands
All ESP XCF commands may be issued via:
ESP page mode, option G from the ESP main menu
ESP line mode
MVS MODIFY command
ESP Workstation.
Syntax The syntax of the XCF DELETE command is:
XCF {DELETE|DEL} {MEMBER|M} member
member Indicates the name of the ESP subsystem you want to delete
from the XCF group.
Example
Displaying the
member to
Delete.
The following display shows XCF member D523 as quiesced.
XCF DISPLAY GROUP
Group=D520, Member=D521, TermOpt=Quiesce
Group Member System ASID Jobname SSID ESP Status
D520 D521 SYSA 0081 D521 D521 Master Active
D520 D522 SYSA 007D D522 D522 Slave Active
D520 D523 SYSA 006D D523 D521 Shadow Quiesced
Example
Issuing the
DELETE
command
The following example shows removing XCF member D523:
XCF DELETE MEMBER D523
ESP4234I XCF member D523 deleted, Group=D520
740
XCF DELETE Command, Continued
Example
Confirming the
member is
deleted.
The following display shows the XCF group with the quiesced member removed.
XCF DISPLAY GROUP
741
XCF DISPLAY Command
Overview The XCF DISPLAY command is used to view system attributes of your XCF group.
Entering
commands
ESP line mode
MVS MODIFY command
ESP Workstation.
Syntax The syntax of the XCF DISPLAY command is:
XCF {DISPLAY|D} {ACTIVE|A}
{GROUP|G}
{SERVICE|S}
{SYSTEM|SYS}
{TRACE|TR}
ACTIVE Displays the active XCF Service listener(s) on the Master
ESP and the connection(s).
GROUP Displays the status of your XCF group.
SERVICE Displays the status of the XCF Services in the group.
SYSTEM Displays all systems in the Sysplex.
TRACE Displays the status of the Trace log.
742
XCF DISPLAY Command, Continued
Example
DISPLAY
ACTIVE
The following example shows the short form of the DISPLAY ACTIVE command
when entered from the Master ESP subsystem:
XCF D A
Group=D520, Member=D521
Partner Service Status Connection
Listener DSTRIG Active
Listener ROUTING Active
D522 DSTRIG Active 1,1
D522 ROUTING Active 2,2
DISPLAY
ACTIVE cont
This is an example of the same command when entered from a Slave ESP
subsystem:
XCF D A
D521 ROUTING Active 2,2
Example
DISPLAY
GROUP
The following example shows the short form of the DISPLAY GROUP command
XCF D G
D520 D521 SYSA 006B D521 D521 Master Active
D520 D522 SYSA 006C D522 D522 Slave Active
D520 D523 SYSA 006D D523 D521 Shadow Active
subsystem:
XCF D G
D520 D521 SYSA 006B D521 D521 Master Active
D520 D522 SYSA 006C D522 D522 Slave Active
D520 D523 SYSA 006D D523 D521 Shadow Active
743
XCF DISPLAY Command, Continued
Example
DISPLAY
SERVICE
The following example shows the short form of the DISPLAY SERVICE command
XCF D S
Service Status Group Member
DSTRIG Active D520 D521
ROUTING Active D520 D521
subsystem:
XCF D S
Service Status Group Member
DSTRIG Active D520 D522
ROUTING Active D520 D522
Example
DISPLAY
SYSTEM
The following example shows the short form of the DISPLAY SYSTEM command:
XCF D SYS
Sysplex=SYSAPLEX, System=SYSA
System Status
SYSA Active
Example
DISPLAY
TRACE
The following example shows the short form of the DISPLAY TRACE command:
XCF D TR
ESP4263I XCF TRACE active, sysout class X
744
XCF FORCE Command
Overview The XCF FORCE command is used to terminate an active ESP XCF member
abnormally with code S00C.
Entering
commands
ESP line mode
MVS MODIFY command
ESP Workstation.
Syntax The syntax of the XCF FORCE command is:
XCF FORCE {MEMBER|M} member
member Indicates the name of the ESP subsystem you want to
terminate.
Example The following display shows member D522 as active.
XCF DISPLAY GROUP
The following example shows removing XCF member D522:
XCF FORCE MEMBER D522
ESP4232I XCF member D522 forced, Group=D520
745
XCF FORCE Command, Continued
Example cont The following display shows the XCF group with the forced member.
XCF DISPLAY GROUP
D520 D522 SYSA 007D D522 D522 Slave Failed
This example shows using the DELETE command to remove the forced member
(D522) from the group.
XCF DELETE MEMBER D522
ESP4234I XCF member D522 deleted, Group=D520
The following display shows the remaining member(s) in the group.
XCF DISPLAY GROUP
746
XCF HELP Command
Overview The XCF HELP command is used to display the list of ESP XCF commands
available.
Entering
commands
ESP line mode
MVS MODIFY command
ESP Workstation.
Syntax The syntax of the XCF HELP command is:
XCF {HELP|H|?}
Example
HELP
command
The following display is the response from the XCF HELP command:
Long Form Short Form
DELETE MEMBER member DEL M|MEM member
DISPLAY ACTIVE|ACTIVITY D A|ACT
DISPLAY GROUP|GROUPS D G|GR
DISPLAY SERVICE|SERVICES D S|SERV
DISPLAY SYSTEM|SYSTEMS D SYS
DISPLAY TRACE D TR
FORCE MEMBER member FORCE M|MEM member
HELP H|?
PURGE CONNECTION connection PG CON connection
PURGE SERVICE service PG S|SERV service
SET TERMOPT LEAVE|QUIESCE T TO L|Q
SET TRACE SYSOUT(class) T TR S(class)
SPIN TRACE SP TR
START SERVICE service S S|SERV service
START TRACE S TR
STOP GROUP P G|GR
STOP MEMBER member P M|MEM member
STOP SERVICE service P S|SERV service
STOP TRACE P TR
VERIFY MEMBER member VER M|MEM member
747
XCF PURGE Command
Overview The XCF PURGE command is used to terminate and restart an ESP XCF Service.
Entering
commands
ESP line mode
MVS MODIFY command
ESP Workstation.
Syntax The syntax of the XCF PURGE command is:
XCF {PURGE|PG} {SERVICE|SERV|S} service
{CONNECTION|CON} connection
SERVICE Used to specify a Service function in the XCF group.
service Indicates the name of the ESP XCF Service you want to
terminate and restart.
CONNECTION Used to specify a connection number of the listener.
connection Indicates the connection number of the listener on the Master
ESP.
Example -
PURGE
SERVICE
The following display shows the status of the XCF group:
XCF DISPLAY ACTIVE
Listener TRACKING Active
D522 TRACKING Active 6,10
748
XCF PURGE Command, Continued
PURGE
SERVICE cont
The following example shows purging an ESP XCF Service:
XCF PURGE SERVICE TRACKING
ESP4221I Listener and 1 connection purged, Service=TRACKING,
Group=D520, Member=
The following display shows the status of the XCF group after the TRACKING
Service has been purged. Note how the TRACKING Service has been restarted with
a new connection.
XCF DISPLAY ACTIVE
Listener TRACKING Active
D522 TRACKING Active 8,12
Example -
PURGE
CONNEC-
TION
The following example shows purging a connection:
XCF PURGE CONNECTION 3
ESP4225I Connection 3 purged
749
XCF SET TERMOPT Command
Overview The XCF SET TERMOPT command is used to preset how the ESP XCF member
will terminate the XCF group.
Entering
commands
ESP line mode
MVS MODIFY command
ESP Workstation.
Syntax The syntax of the XCF SET TERMOPT commands is:
XCF {SET|T} {TERMOPT|TO} {LEAVE|L}
{QUIESCE|Q}
TERMOPT Used to preset how the XCF member terminates the XCF
group. Entered from the ESP XCF member you are logged on
to or previously defined in the Initialization Parameters of the
SYSPLEX Statement.
LEAVE This is the default for an XCFLOCAL configuration. It tells
ESP to enter a LEAVE state when it terminates normally
from the XCF group. LEAVE means a member goes into an
undefined state and no record of its existence is maintained
by XCF.
If QUIESCE and LEAVE are omitted and the local system
(MVS image) is a member of a sysplex (i.e. uses a coupling
data set), QUIESCE is the default.
If the local MVS system is not a member of a sysplex (i.e.
IEASYSnn member specifies PLEXCFG=XCFLOCAL),
LEAVE takes effect unconditionally.
QUIESCE This is the default for a sysplex configuration. It tells ESP to
enter a Quiesced state when it terminates normally. A
Quiesced XCF member is disassociated from XCF Services,
but XCF retains a record of its existence. Quiesced members
of an ESP XCF group are included in the response to the ESP
subcommand XCF DISPLAY GROUP.
750
XCF SET TERMOPT Command, Continued
Example
TERMOPT
command
The following example shows setting ESP to terminate with a Quiesced state using
the short form of the SET TERMOPT command:
XCF T TO Q
ESP4242I XCF TERMOPT set to QUIESCE, Group=D520, Member=D521
Example
TERMOPT in
the SYSPLEX
statement
The following example shows setting ESP to terminate with a Quiesced state using
the TERMOPT operand in the SYSPLEX Initialization Parameter:
SYSPLEX GROUP(D520) MEMBER(D521) TERMOPT(QUIESCE)
Related
information
For more information on the SYSPLEX Initialization Parameter, see the ESP
Workload Manager Installation Guide.
For more information on ESP and XCF, see the ESP Workload Manager Users
Guide.
751
XCF SET TRACE Command
Overview The XCF SET TRACE command is used to define a sysout class for trace data
output. XCF SET TRACE can be coded in the Initialization Parameter data set or
entered on the fly when trace data is required. It is recommended to put it in your
Initialization Parameter data set.
Entering
commands
ESP line mode
MVS MODIFY command
ESP Workstation.
Syntax The syntax of the XCF SET TRACE command is:
XCF {SET|T} {TRACE|TR} {SYSOUT|S}(class)
(class) Indicates an output class for sysout.
Example The following example shows the short form of the SET TRACE command to set
trace data to a sysout class of X:
XCF T TR S(X)
Related
information
For more information about the XCF Trace facility, see the ESP Workload Manager
Users Guide.
752
XCF SPIN TRACE Command
Overview The XCF SPIN TRACE command is used to spool trace data from the current trace
file to output and start a new trace file. This command is used when the trace file is
started upon initialization of the ESP subsystem and kept running for the duration of
the subsystem session.
Entering
commands
ESP line mode
MVS MODIFY command
ESP Workstation.
Syntax The syntax of the XCF SPIN TRACE command is:
XCF {SPIN|SP} {TRACE|TR}
SPIN Used to send trace data to output and start a new trace file.
TRACE Indicates XCF Trace facility.
Example The following example shows the short form of the SPIN TRACE command:
XCF SP TR
Related
information
Users Guide.
753
XCF START SERVICE Command
Overview The XCF START SERVICE command is used to restart an XCF Service, on the fly,
after it has been stopped.
Entering
commands
ESP line mode
MVS MODIFY command
ESP Workstation.
Syntax The syntax of the XCF START SERVICE command is:
XCF {START|S} {SERVICE|SERV|S} service
service Indicates the name of the XCF Service you want to restart.
Usage notes XCF Services are registered and activated via the XCF START SERVICE
command. The following commands must be coded in the Initialization Parameter
data set.
XCF START SERVICE TRACKING
XCF START SERVICE DSTRIG
The above commands are also used to restart a Service, on the fly, after it has been
stopped.
Related
information
For more information on XCF Services, see the ESP Workload Manager Users
Guide.
754
XCF START TRACE Command
Overview The XCF START TRACE command is used to initialize and activate the XCF Trace
file. The XCF START TRACE command can be used after the XCF SET TRACE
command in the Initialization Parameter data set if you want to start the trace file
upon initialization of the ESP subsystem. Otherwise, the XCF START TRACE
command is entered on the fly when you need to capture data.
Entering
commands
ESP line mode
MVS MODIFY command
ESP Workstation.
Syntax The syntax of the XCF START TRACE command is:
XCF {START|S} {TRACE|TR}
Example The following example shows the short form of the START TRACE command:
XCF S TR
Related
information
Users Guide.
755
XCF STOP GROUP Command
Overview The XCF STOP GROUP command is used to stop all the ESP XCF members in the
XCF group.
Entering
commands
ESP line mode
MVS MODIFY command
ESP Workstation.
Syntax The syntax of the XCF STOP GROUP command is:
XCF {STOP|P} {GROUP|G}
GROUP Indicates an XCF group.
756
XCF STOP MEMBER Command
Overview The XCF STOP MEMBER command is used to stop an ESP XCF Member.
Entering
commands
ESP line mode
MVS MODIFY command
ESP Workstation.
Syntax The syntax of the XCF STOP MEMBER command is:
XCF {STOP|P} {MEMBER|M} member
MEMBER Used to specify a Member name in the XCF group.
member Indicates the name of the ESP subsystem you are targeting.
Example The following example shows the short form of the XCF STOP MEMBER
command:
XCF P M D523
ESP4231E XCF member D523 stopped, Group=D520
757
XCF STOP SERVICE Command
Overview The XCF STOP SERVICE command is used to stop an ESP XCF Service.
Entering
commands
ESP line mode
MVS MODIFY command
ESP Workstation.
Syntax The syntax of the XCF STOP SERVICE command is:
XCF {STOP|P} {SERVICE|SERV|S} service
service Indicates the name of the Service you want to stop.
Example The following example shows the short form of the XCF STOP SERVICE
command:
XCF P S TRACKING
ESP4220I XCF service TRACKING stopped, Group=D520, Member=D521
Related
information
For more information on XCF Services, see the ESP Workload Manager Users
Guide.
758
XCF STOP TRACE Command
Overview The XCF STOP TRACE command is used to stop the trace file after data has been
captured and to spool the captured data to the preset sysout class specified by the
XCF SET TRACE command.
Entering
commands
ESP line mode
MVS MODIFY command
ESP Workstation.
Syntax
The syntax of the XCF STOP TRACE command is:
XCF {STOP|P} {TRACE|TR}
Example The following example shows the short form of the XCF STOP TRACE command:
XCF P TR
Related
information
Users Guide.
759
XCF VERIFY Command
Overview The XCF VERIFY command is used to verify that two ESP XCF members have the
same view of what their connections are. VERIFY is typically used after a PURGE
command has been executed on a Service or a Connection.
Entering
commands
ESP line mode
MVS MODIFY command
ESP Workstation.
Syntax
The syntax of the XCF VERIFY command is:
XCF {VERIFY|VER} {MEMBER|M} member
MEMBER Used to specify a Member name in the XCF group.
member Indicates the name of the ESP subsystem you are targeting.
Example The following example shows the short form of the XCF VERIFY command:
XCF VER M D522
ESP4243I Verify request transmitted to XCF member D522,
Group=D520.
760
XMITMDL: Identify Tracking Models To Transmit
Overview The XMITMDL command tells ESP which tracking models are to be transmitted,
and to which node.
Authority OPER authority is required to issue the XMITMDL command.
Syntax The syntax of the XMITMDL command is:
XMITMDL [ADD|DELETE|LIST]
MODEL(modelname[,modelname]...)
NODE(nodeid[,nodeid]...)
ADD Indicates that new information is to be added to the
specification of tracking data transmitted.
DELETE Delete model or node from previous XMITMDL definition.
LIST List models and nodes previously defined. This is the default.
modelname Name of tracking model, associated with the jobs, for which
data is to be transmitted. Wildcard characters can be used to
signify a group of tracking models. Multiple tracking models
can be specified.
nodeid For NJE, this is the logical identifier of each node to receive
tracking data (as identified on the ISCXMTR statement); for
LU6.2, this is the Application name of the target TP server.
Multiple nodes can be specified.
Usage notes XMITMDL must be issued from a MASTER ESP system.
Example 1 To identify that all tracking data for model XSYS be sent to ESP_SYSTEM_A,
where this is the Application name of the target TP server, specify:
OPER XMITMDL ADD MODEL(XSYS) NODE(ESP_SYSTEM_A)
Example 2 To display cross-system tracking models:
OPER XMITMDL LIST
761
%
%ENDEXCL ........................................................... 266
%ENDINCL............................................................. 269
%EXCLUDE ........................................................... 295
%INCLUDE............................................................. 346
/
//* FROM................................................................. 313
//* UNTIL................................................................ 729
//*ESPSYMBOL...................................................... 284
A
ABANDON DEPENDENCIES................................. 15
ABANDON RESOURCES........................................ 17
ABANDON SUBMISSION ...................................... 19
Abend limit ................................................................ 22
Abended jobs ........................................................... 131
ABENDLIM.............................................................. 22
ABSORB ................................................................... 24
Accessing ESP command through batch job.............. 55
Activating user modifications .................................. 733
ADJUST .................................................................... 25
AFTER....................................................................... 27
Agent commands
AGENT ................................................................. 31
AGENTMSG......................................................... 34
AGENTRCV......................................................... 37
Agent definition file
loading................................................................. 457
testing .................................................................. 457
Agent receivers, manipulating.................................... 37
AJ......................................................................... 63, 74
ALERTDEF............................................................... 41
Alerts, defining .......................................................... 41
ALLOWUNDEF........................................................ 44
ALTCAL.................................................................... 45
ALTEVENT .............................................................. 47
ALTGROUP.............................................................. 50
ALTSIG..................................................................... 52
ALTTJ ....................................................................... 53
ALTUSER ................................................................. 55
APPL.......................................................................... 58
Application file,displaying....................................... 421
Application processing,restarting............................. 595
Applications
completing............................................................. 74
holding................................................................... 74
processing options ................................................. 58
releasing................................................................. 74
resource requirements.......................................... 590
stopping processing ............................................. 553
unwaiting ............................................................... 74
APPLJOB ............................................................ 63, 74
Authorization tables
deleting................................................................ 182
displaying ............................................................ 422
B
Backing out new release of ESP ................................ 76
Backing up
Eventset ................................................................. 77
History file............................................................. 78
Index file................................................................ 79
Job Index file ......................................................... 81
Userdef file ............................................................ 83
BACKOUT ................................................................ 76
BKUPEVS ................................................................. 77
BKUPHIST................................................................ 78
BKUPINDX............................................................... 79
BKUPJNDX............................................................... 81
BKUPUDEF .............................................................. 83
BREAK...................................................................... 85
Bypassing
a job....................................................................... 63
a sub-Application................................................... 63
Event execution ................................................... 723
job submission ....................................................... 19
C
CALENDAR.............................................................. 87
Calendars
changing................................................................. 45
defining................................................................ 144
deleting ................................................................ 187
displaying............................................................. 424
naming ................................................................. 424
referencing............................................................. 87
CCFAIL ..................................................................... 94
CELLTRC.................................................................. 97
CHECKEXC............................................................ 100
Checkpoint data set, displaying................................ 426
CLASS..................................................................... 103
CLRSYSMS............................................................. 107
CMDPRFX .............................................................. 108
COM........................................................................ 109
Command output
data set ................................................................. 330
file........................................................................ 332
sysout ................................................................... 334
Commands
ABENDLIM.......................................................... 22
ADJUST ................................................................ 25
AJ..................................................................... 63, 74
ALERTDEF........................................................... 41
ALTCAL ............................................................... 45
ALTEVENT .......................................................... 47
ALTGROUP.......................................................... 50
ALTSIG................................................................. 52
ALTTJ ................................................................... 53
ALTUSER............................................................. 55
APPLJOB........................................................ 63, 74
BACKOUT............................................................ 76
BKUPEVS............................................................. 77
BKUPHIST ........................................................... 78
BKUPINDX .......................................................... 79
BKUPJNDX.......................................................... 81
BKUPUDEF.......................................................... 83
BREAK.................................................................. 85
CALENDAR.......................................................... 87
762
CELLTRC............................................................. 97
CLASS................................................................. 103
CLRSYSMS ........................................................ 107
CMDPRFX.......................................................... 108
COM.................................................................... 109
CONNECT.......................................................... 110
CONSOLE........................................................... 112
COPY.................................................................. 114
CPU..................................................................... 122
CRITERIA........................................................... 124
CRITPATH ......................................................... 127
DAB .................................................................... 131
DATEFORM............................................... 135, 137
DEFAT................................................................ 139
DEFAULT........................................................... 142
DEFCAL.............................................................. 144
DEFGROUP........................................................ 147
DEFHOL............................................................. 150
DEFPN................................................................ 153
DEFPRINT.......................................... 156, 159, 161
DEFPRIO............................................................ 163
DEFSIG............................................................... 164
DEFSPEC............................................................ 166
DEFSYML .......................................................... 169
DEFTJ ................................................................. 172
DEFTM............................................................... 174
DEFUSER........................................................... 178
DELAT................................................................ 182
DELAYINT......................................................... 183
DELCAL ............................................................. 187
DELETE...................................................... 188, 189
DELGROUP........................................................ 190
DELHOL............................................................. 191
DELPN................................................................ 193
DELSIG............................................................... 194
DELSPEC............................................................ 195
DELSYML.......................................................... 197
DELTJ ................................................................. 198
DELTM............................................................... 200
DELUSER........................................................... 201
DFLTUSER......................................................... 205
DFPNODE........................................................... 207
DISCONN........................................................... 209
DISPLAY............................................................ 210
DN....................................................................... 220
DQ....................................................................... 227
DSTRDLY........................................................... 233
DSTREXCL ........................................................ 235
DSTRIG .............................................................. 237
DSTRST.............................................................. 244
ECHO.................................................................. 254
EICLASS............................................................. 256
EJECT ................................................................. 259
END..................................................................... 262
ENDDEF............................................................. 263
ENDHC............................................................... 268
ENDMODEL....................................................... 273
ENDPRINT......................................................... 274
ENDR.................................................................. 275
ESPCTR.............................................................. 280
EVENT................................................................ 286
EVENTOPT......................................................... 291
EVENTSET......................................................... 292
EXPECT.............................................................. 302
FLOW.................................................................. 309
FOOTING............................................................ 311
FROM.................................................................. 315
GENDOC ............................................................ 317
GENFLOW.......................................................... 319
GENPROJ............................................................ 321
GENTIME........................................................... 323
GO....................................................................... 327
GROUP................................................................ 328
HARDCOPY....................................... 330, 332, 334
HISTFILE.................................................... 336, 338
HOLD.......................................................... 340, 342
INET.................................................................... 350
INFOCOMM....................................................... 353
INFOMSG........................................................... 355
INIT..................................................................... 357
INPUT ................................................................. 359
INVOKE.............................................................. 365
JESCOMCH........................................................ 370
JESTYPE............................................................. 371
JOBINFO............................................................. 382
JOBMAP ............................................................. 386
JOBTREE............................................................ 392
JTPEXCL ............................................................ 394
LABEL ................................................................ 399
LAP...................................................................... 416
LAX..................................................................... 404
LCMDPRFX........................................................ 406
LDSN................................................................... 407
LDTE................................................................... 408
LDTREL.............................................................. 409
LDXE .................................................................. 410
LIBSUB............................................................... 411
LIST..................................................................... 413
LISTAPPL........................................................... 416
LISTAPTF........................................................... 421
LISTAT ............................................................... 422
LISTCAL............................................................. 424
LISTCKPT .......................................................... 426
LISTEVS............................................................. 427
LISTGRP............................................................. 429
LISTHIST............................................................ 431
LISTHOL ............................................................ 432
LISTJTML........................................................... 434
LISTPN ............................................................... 435
LISTQ.................................................................. 436
LISTSADL .......................................................... 437
LISTSCH............................................................. 438
LISTSIG.............................................................. 441
LISTSPEC........................................................... 443
LISTTRAK.......................................................... 448
LISTUSER .......................................................... 449
LISTXMEZ ......................................................... 451
LJ452
LOAD.................................................................. 455
LOADAGDF ....................................................... 457
LOADJTDT......................................................... 458
LOADSCHF........................................................ 460
LOADUPDT........................................................ 461
LOGPRT.............................................................. 462
763
LSYS................................................................... 468
LSYSMSGS ........................................................ 470
LTCELL.............................................................. 471
LTJ ...................................................................... 472
LTM.................................................................... 474
LTZONE ............................................................. 475
MAPGEN............................................................ 476
MAXINITS ......................................................... 479
MODEL............................................................... 492
MREPORT.......................................................... 497
MSG.................................................................... 500
MSGTYPE .......................................................... 504
NEXT .................................................................. 507
NODE.................................................................. 510
NOSCHED.......................................................... 515
ON....................................................................... 522
PANSUB............................................................. 529
PASSWORD....................................................... 531
POST................................................................... 535
PREALLOC ........................................................ 541
PURGSCHF ........................................................ 551
QUIESCE............................................................ 553
QUPDATE .......................................................... 556
RACROUTE........................................................ 557
RELEASE.................................................... 566, 568
REMOVE............................................................ 572
REPORT.............................................................. 574
RESDEF.............................................................. 575
RESDFLT............................................................ 583
RESREFR............................................................ 594
RESTART ........................................................... 595
RESTORE........................................................... 596
RESUME..................................................... 598, 600
ROSSUB ............................................................. 605
SADGEN............................................................. 612
SADLINK............................................................ 617
SADLOAD.......................................................... 619
SADUPD............................................................. 621
SAFGRANT........................................................ 622
SAFOPTS............................................................ 624
SAFRDEF............................................................ 627
SAFRDEL ........................................................... 628
SAFREVOK........................................................ 629
SCAN.................................................................. 630
SCHEDULE........................................................ 633
SEND .................................................................. 642
SETPRINT .......................................................... 645
SETWIDTH ........................................................ 646
SHADOW........................................................... 647
SIGCYCLE.......................................................... 649
SIGPOST............................................................. 651
SIGWAIT............................................................ 653
SIMULATE......................................................... 655
SMFSTATS......................................................... 662
SORT................................................................... 663
SPACE................................................................. 665
SPINLOG............................................................ 666
SPUSER.............................................................. 667
STATUS.............................................................. 668
SUBMIT.............................................................. 675
substitution string ................................................ 108
SUSPEND................................................... 678, 680
SYMLIB.............................................................. 681
SYSMSGS........................................................... 683
TEST ................................................................... 696
TIME................................................................... 700
TITLE.................................................................. 701
TRACE................................................................ 704
TRACEDEF......................................................... 707
TRACEPRT......................................................... 709
TRACKING......................................................... 716
TRACKOPT........................................................ 718
TRDFLT.............................................................. 721
TRIGGER............................................................ 722
UNALLOC.......................................................... 728
USE ..................................................................... 731
USER................................................................... 732
USERMOD.......................................................... 733
VS........................................................................ 735
XMITMDL.......................................................... 760
Comments in an Event ............................................. 109
Completing
a job....................................................................... 63
an Application........................................................ 74
Condition codes
checking................................................................. 94
Conditional processing............................................. 344
CONNECT............................................................... 110
Connecting users to groups ...................................... 110
CONSOLE............................................................... 112
Console, setting primary .......................................... 112
Converting
DJC networks....................................................... 371
job documentation libraries ......................... 317, 399
COPY....................................................................... 114
COPYJCL................................................................ 116
COREQ.................................................................... 119
Co-requisite job........................................................ 119
CPU, defining........................................................... 122
Creating a job mapping data set ............................... 476
CRITERIA............................................................... 124
Critical path analysis
enabling or disabling............................................ 127
turning on for an Application............................... 129
CRITPATH...................................................... 127, 129
CSF,purging data ..................................................... 551
D
DAB......................................................................... 131
Data set Trigger Delay ............................................. 233
Data set triggering.................................................... 229
at Event level ....................................................... 237
controlling............................................................ 244
delaying ............................................................... 233
displaying data set trigger objects........................ 410
displaying data set triggered Events..................... 410
displaying excluded programs ............................. 409
excluding programs.............................................. 235
listing data sets..................................................... 408
workload object ................................................... 242
Data sets
764
displaying ............................................................ 407
job mapping......................................................... 476
preallocating ........................................................ 541
restoring............................................................... 596
trace ..................................................................... 707
DATASET............................................................... 133
Date and time variables............................................ 323
Date formats,schedule criteria.................................. 135
DATEFORM................................................... 135, 137
Deactivating user modifications............................... 733
Deallocating a data set ............................................. 728
DEFAT .................................................................... 139
DEFAULT ............................................................... 142
Default resources ..................................................... 583
DEFCAL.................................................................. 144
DEFGROUP ............................................................ 147
DEFHOL.................................................................. 150
Defining
a footing............................................................... 311
a title.................................................................... 701
Alerts ..................................................................... 41
authorization table ............................................... 139
calendars...................................................... 144, 424
date and time variables ........................................ 323
Event data set....................................................... 292
Events .................................................................. 286
File trigger workload objects............................... 305
group prefixes...................................................... 169
groups .................................................................. 147
History file........................................................... 338
holidays ....................................................... 150, 151
initial user to ESP................................................ 667
jobs ...................................................................... 372
P-nodes .......................................................... 56, 153
RACF resources................................................... 627
resources.............................................................. 575
signals.................................................................. 164
special days and periods ...................................... 444
special days or periods......................................... 166
Symbol libraries................................................... 169
symbolic library sets............................................ 169
tracked jobs ................................................. 172, 711
tracking models.................................................... 174
users..................................................................... 178
DEFPN..................................................................... 153
DEFPRINT
data set................................................................. 156
file........................................................................ 159
sysout................................................................... 161
DEFPRIO................................................................. 163
DEFSIG................................................................... 164
DEFSPEC................................................................ 166
DEFSYML............................................................... 169
DEFTJ...................................................................... 172
DEFTM.................................................................... 174
DEFUSER................................................................ 178
DELAT .................................................................... 182
Delaying job submission.......................................... 564
Delaying submission ................................................ 184
DELAYINT ............................................................. 183
DELAYSUB............................................................ 184
DELCAL.................................................................. 187
DELETE .......................................................... 188, 189
Deleting
a signal................................................................. 194
a special day or period......................................... 195
an Event ............................................................... 188
Events .................................................................. 189
holidays................................................................ 191
P-node.................................................................. 193
RACF resources................................................... 628
resources.............................................................. 575
tracked job definition........................................... 198
tracking model ..................................................... 200
DELGROUP ............................................................ 190
DELHOL.................................................................. 191
DELPN..................................................................... 193
DELSIG................................................................... 194
DELSPEC................................................................ 195
DELSYML............................................................... 197
DELTJ...................................................................... 198
DELTM.................................................................... 200
DELUSER................................................................ 201
DESELECT.............................................................. 202
DFLTUSER ............................................................. 205
DFPNODE............................................................... 207
Diagnostic tracing .................................................... 704
DISCONN................................................................ 209
Disconnecting a user from a group........................... 209
DISPLAY................................................................. 210
Display width, setting............................................... 646
Displaying
a tracked job definition........................................ 472
a user definition ................................................... 449
Alerts ..................................................................... 41
Application file usage .......................................... 421
Applications......................................................... 416
calendars.............................................................. 424
checkpoint data set............................................... 426
cross-memory elements........................................ 451
current ESP status................................................ 668
current schedule................................................... 438
current status of the Application.......................... 421
data set names...................................................... 407
data set triggers.................................................... 408
ESP data sets........................................................ 407
ESP system information....................................... 468
Event data set....................................................... 427
Event definitions.................................................. 413
excluded programs for data set triggering............ 409
external jobs......................................................... 404
fields in History Report........................................ 210
groups .................................................................. 429
History file........................................................... 431
holidays................................................................ 432
job documentation information............................ 382
job statistics ......................................................... 452
job tracking file.................................................... 448
names of Events................................................... 414
next execution times .................................... 414, 507
P-nodes ................................................................ 435
QUEUE data set................................................... 436
queues.................................................................. 227
queues.................................................................. 220
765
resources.............................................................. 575
SADLINKs.......................................................... 437
scheduled activity report...................................... 463
signals.................................................................. 441
sub-Applications.................................................. 416
symbol libraries ................................................... 446
system messages .................................................. 470
TCP/IP attributes ................................................. 350
time zone settings ................................................ 475
tracking cell information...................................... 471
tracking models.................................................... 474
TRAKFILE.......................................................... 448
user definitions .................................................... 449
user modifications................................................ 733
DJC specifications ................................................... 212
DJCDATA............................................................... 212
DJCNET .................................................................. 218
DN ........................................................................... 220
DO ........................................................................... 223
DO, ending............................................................... 264
DOCLIB .................................................................. 225
DQ ........................................................................... 227
Dropping dependencies.............................................. 15
Dropping resources .................................................... 17
Dropping submit time dependency............................. 19
DSNAME................................................................. 229
DSTRDLY............................................................... 233
DSTREXCL............................................................. 235
DSTRIG........................................................... 237, 242
DSTRST .................................................................. 244
Due out time job submission.................................... 401
DUEOUT................................................................. 246
DURATION............................................................. 250
E
Early submission time .............................................. 251
EARLYSUB ............................................................ 251
ECHO ...................................................................... 254
Echoing character strings ......................................... 254
EICLASS ................................................................. 256
EJECT...................................................................... 259
ELSE........................................................................ 260
Enabling user modifications..................................... 733
END......................................................................... 262
ENDDEF.................................................................. 263
ENDDO................................................................... 264
ENDHC.................................................................... 268
Ending
a model definition................................................ 273
an Event definition............................................... 263
Line mode............................................................ 262
ENDJOB.................................................................. 271
ENDMODEL........................................................... 273
ENDPRINT.............................................................. 274
ENDR ...................................................................... 275
ENDTEMPL............................................................ 276
error messages.......................................................... 657
ESP .......................................................................... 277
ESP commands
issuing from a Procedure ............................. 277, 282
ESP Procedures,invoking......................................... 365
ESP tracking definition table.................................... 458
ESPCOM................................................................. 279
ESPCTR................................................................... 280
ESPNOMSG............................................................ 282
EVENT .................................................................... 286
Event data set ............................................. See Eventset
Event definition commands
COM.................................................................... 109
DSTRIG............................................................... 237
ENDDEF ............................................................. 263
EXPECT.............................................................. 302
INVOKE.............................................................. 365
LIBSUB............................................................... 411
NOSCHED.......................................................... 515
ON....................................................................... 522
PANSUB ............................................................. 529
RELEASE............................................................ 566
RESUME............................................................. 598
ROSSUB.............................................................. 605
SCHEDULE ........................................................ 633
SEND................................................................... 642
SIGCYCLE.......................................................... 649
SIGPOST............................................................. 651
SIGWAIT ............................................................ 653
SUBMIT.............................................................. 675
SUSPEND........................................................... 678
SYMLIB.............................................................. 681
VS........................................................................ 735
Event definitions,displaying..................................... 413
Event log, displaying................................................ 462
Event messages,limiting........................................... 502
EVENTOPT............................................................. 291
Events
allowing or disallowing WTO ............................. 291
altering schedule .................................................. 522
changing................................................................. 47
classes.................................................................. 103
comments............................................................. 109
default for triggering............................................ 721
deleting ................................................................ 189
displaying............................................................. 413
displaying next scheduled execution.................... 507
displaying schedule.............................................. 438
expected time....................................................... 302
holding................................................................. 342
initiator classes .................................................... 256
overdue ................................................................ 633
resuming .............................................................. 600
schedule criteria................................................... 633
scheduled deletion ............................................... 188
scheduled hold ..................................................... 340
scheduled release of............................................. 566
scheduled resume................................................. 598
scheduled suspension........................................... 678
scheduling exception............................................ 515
simulating ............................................................ 655
starting definition................................................. 286
stopping processing ............................................. 553
suspending ........................................................... 680
triggering ............................................................. 722
triggering with Alerts............................................. 41
766
Eventset
backing up ............................................................. 77
defining................................................................ 292
displaying ............................................................ 427
EVENTSET............................................................. 292
Excluding
JCL...................................................................... 295
programs from tracking ....................................... 394
EXIT........................................................................ 299
Exiting from a Procedure ......................................... 299
EXPECT.................................................................. 302
External job dependencies ....................................... 588
External jobs
displaying ............................................................ 404
F
File trigger dependencies ......................................... 303
File trigger workload objects ................................... 305
FILE_TRIGGER...................................................... 305
FILENAME ............................................................. 303
FLAGUNDEF.......................................................... 307
FLOW...................................................................... 309
Flow charting
MS Project........................................................... 321
Timeline....................................................... 309, 319
FOOTING................................................................ 311
Formatting output..................................................... 259
Frequency of job ...................................................... 608
FROM...................................................................... 315
G
GENDOC................................................................. 317
GENFLOW.............................................................. 319
GENPROJ................................................................ 321
GENTIME ............................................................... 323
GENTIME variables................................................ 324
GO ........................................................................... 327
GROUP.................................................................... 328
Group definitions,changing........................................ 50
Group prefix,setting ................................................. 328
Groups
connecting users .................................................. 110
defining................................................................ 147
definitions............................................................ 429
deleting................................................................ 190
displaying ............................................................ 429
H
HARDCOPY (DATASET option)........................... 330
HARDCOPY (File option)....................................... 332
HARDCOPY (Sysout option) .................................. 334
HISTFILE........................................................ 336, 338
displaying ............................................................ 431
History file
altering................................................................. 338
backing up ..................................................... 78, 339
defining................................................................ 338
displaying ............................................................ 431
History Report
date format........................................................... 137
ending.................................................................. 275
fields displayed .................................................... 210
formatting .............................................................. 85
input data set ........................................................ 359
output data set ...................................................... 114
selection criteria................................................... 124
specifying History file.......................................... 336
specifying sort order ............................................ 663
starting ................................................................. 574
time range ............................................................ 315
HOLD ...................................................................... 342
HOLD (Event definition) ......................................... 340
Holding
a job....................................................................... 63
an Application........................................................ 74
Holding Events................................................. 340, 342
Holiday processing,Events....................................... 522
Holidays
defining................................................................ 150
Deleting ............................................................... 191
displaying............................................................. 432
multiple................................................................ 151
I
IF 344
Including JCL........................................................... 346
Index file,backing up.................................................. 79
INET ........................................................................ 350
INFOCOMM............................................................ 353
INFOMSG................................................................ 355
Infoserv requests,sending......................................... 353
Inheriting relationships,simulating........................... 655
INIT ......................................................................... 357
Initiator classes, Events............................................ 256
Initiators
controlling for modeling ...................................... 357
maximum for modeling........................................ 479
INPUT...................................................................... 359
Input data set,tape processing .................................. 360
INPUTDS................................................................. 360
Inserting
a job....................................................................... 63
a job with a time dependency................................. 73
INTEGER ................................................................ 362
INVOKE.................................................................. 365
Invoking an ESP Procedure ..................................... 365
J
JCL
changing symbol introducer................................. 284
copy of submitted ................................................ 116
default values for job card ................................... 142
member name....................................................... 481
scanning............................................................... 630
submitting from a Librarian data set .................... 411
submitting from a Panvalet data set ..................... 529
submitting from an Event..................................... 675
submitting from ROSCOE data set ...................... 605
temporary use....................................................... 729
JCL library ............................................................... 133
identifying............................................................ 367
override................................................................ 694
temporary............................................................. 694
767
temporary use ...................................................... 313
JCL scan exit
simulating ............................................................ 655
JCL tailoring
excluding JCL...................................................... 295
including JCL ...................................................... 346
JCLLIB.................................................................... 367
JES
changing command character .............................. 370
changing type....................................................... 371
issuing commands from an Event ........................ 735
specifing the type................................................. 371
JES3 statements ....................................................... 212
JESCOMCH............................................................. 370
JESTYPE................................................................. 371
JOB.......................................................................... 372
Job attributes............................................................ 372
changing .............................................................. 379
Job documentation
converting to ESP format..................................... 317
displaying ............................................................ 382
Job documentation library........................................ 225
converting.................................................... 399, 572
Job Index file,backing up........................................... 81
Job mapping............................................................. 386
data set................................................................. 476
successor reports.................................................. 392
Job monitor Events,simulating................................. 655
Job monitoring,group prefix .................................... 495
Job network identifier .............................................. 218
Job Tracking Definition Table
entries .................................................................. 711
loading................................................................. 458
wildcards ............................................................. 737
Job tracking,excluding programs ............................. 394
JOBATTR................................................................ 379
JOBINFO................................................................. 382
JOBMAP.................................................................. 386
JOBRES................................................................... 391
Jobs
abended................................................................ 131
bypassing............................................................... 63
completing............................................................. 63
controlling ............................................................. 63
co-requisite .......................................................... 119
data set dependency............................................. 229
data set triggers.................................................... 242
defining................................................................ 372
delayed release..................................................... 564
deselecting................................................... 202, 512
displaying statistics.............................................. 452
dropping dependencies .......................................... 63
due out times........................................................ 246
early submission time .......................................... 251
ending definition.................................................. 271
hold count ............................................................ 562
holding................................................................... 63
identifying predecessors ...................................... 543
identifying successors.......................................... 537
inheriting dependencies ....................................... 525
inserting................................................................. 63
inserting with a time dependency........................... 73
late submission time............................................. 401
listing details........................................................ 386
notification........................................................... 517
overdue ................................................................ 246
post requisites ...................................................... 537
prerequisites......................................................... 543
processing options ............................................... 525
readying ................................................................. 63
releasing................................................................. 63
requesting............................................................... 63
resetting times........................................................ 63
resource requirements.......................................... 590
restart step............................................................ 525
restarting................................................................ 63
resubmitting........................................................... 63
routing to another node........................................ 606
run frequency....................................................... 608
scheduling exceptions.......................................... 512
selecting............................................................... 638
successor information .......................................... 392
successors ............................................................ 569
tagging ................................................................. 687
tracking................................................................ 711
unbypassing ........................................................... 63
unrequesting........................................................... 63
unwaiting ............................................................... 63
JOBTREE ................................................................ 392
JTPEXCL................................................................. 394
JUMPTO.................................................................. 396
L
LABEL..................................................................... 399
LAP.......................................................................... 416
Late submission time................................................ 401
LATESUB................................................................ 401
LAX......................................................................... 404
LCMDPRFX............................................................ 406
LDSN....................................................................... 407
LDTE....................................................................... 408
LDTREL.................................................................. 409
LDXE....................................................................... 410
Librarian data set, submitting JCL ........................... 411
LIBSUB................................................................... 411
Limiting Event messages.......................................... 502
Line mode, ending.................................................... 262
LIST......................................................................... 413
LISTAPPL ............................................................... 416
LISTAPTF ............................................................... 421
LISTAT.................................................................... 422
LISTCAL................................................................. 424
LISTCKPT............................................................... 426
LISTEVS ................................................................. 427
LISTGRP ................................................................. 429
LISTHIST................................................................ 431
LISTHOL................................................................. 432
LISTJTML............................................................... 434
LISTPN.................................................................... 435
LISTQ...................................................................... 436
LISTSADL............................................................... 437
768
LISTSCH................................................................. 438
LISTSIG .................................................................. 441
LISTSPEC ............................................................... 443
LISTSYML.............................................................. 446
LISTTRAK.............................................................. 448
LISTUSER............................................................... 449
LISTXMEZ.............................................................. 451
LJ452
LOAD...................................................................... 455
LOADAGDF............................................................ 457
Loading
Agent definition file............................................. 457
ESP commands.................................................... 455
Job Tracking Definition Table............................. 458
schedule file......................................................... 460
User Profile Definition Table .............................. 461
LOADJTDT............................................................. 458
LOADSCHF ............................................................ 460
LOADUPDT............................................................ 461
LOGPRT.................................................................. 462
LSAR....................................................................... 463
LSYS........................................................................ 468
LSYSMSGS............................................................. 470
LTCELL................................................................... 471
LTJ........................................................................... 472
LTM......................................................................... 474
LTZONE.................................................................. 475
M
MAPGEN ................................................................ 476
MAPUSER............................................................... 478
Masking,Job Tracking Definition Table .................. 737
MAXINITS.............................................................. 479
MEMBER................................................................ 481
Member name,JCL library ....................................... 481
Messages
customizing.......................................................... 504
customizing for ESP............................................ 500
displaying in Page mode...................................... 355
error ..................................................................... 657
intercepting system.............................................. 683
Sending................................................................ 642
MGRADDR............................................................. 483
MGRMSG................................................................ 485
MODEL........................................................... 491, 492
Modeling
changing times....................................................... 25
ending definition.................................................. 273
reports.................................................................. 497
starting definition................................................. 492
Modeling commands
ADJUST................................................................ 25
DEFPRIO............................................................ 163
ENDMODEL....................................................... 273
INIT..................................................................... 357
MAXINITS ......................................................... 479
MODEL............................................................... 492
MREPORT.......................................................... 497
TIME................................................................... 700
MONITOR............................................................... 495
MREPORT .............................................................. 497
MS Project file ......................................................... 321
MSG......................................................................... 500
MSGLIMIT.............................................................. 502
MSGTYPE............................................................... 504
MVS commands,issuing from an Event ................... 735
N
NEXT....................................................................... 507
NOCHECKEXC ...................................................... 509
NODE ...................................................................... 510
NORUN................................................................... 512
NOSCHED............................................................... 515
NOTIFY................................................................... 517
Numeric variables .................................................... 362
O
ON............................................................................ 522
Operating system command,issuing ......................... 735
OPTIONS................................................................. 525
Output spacing ......................................................... 665
Overdue Events........................................................ 633
Overdue jobs ............................................................ 246
Override JCL library................................................ 694
P
Page mode,display ................................................... 355
PANSUB.................................................................. 529
Panvalet data set, submitting.................................... 529
PASSWORD............................................................ 531
Permitting access to a resource ................................ 622
P-Nodes
assigning to a job ................................................. 532
displaying............................................................. 435
setting defaults..................................................... 207
specifies the name................................................ 153
PNODES.................................................................. 532
POST........................................................................ 535
Post requisite jobs .................................................... 537
Posting a job from a P-Node .................................... 535
Posting a Signal........................................................ 651
Postponing job submission....................................... 564
POSTREQ................................................................ 537
PREALLOC............................................................. 541
Predecessors
identifying.............................................................. 27
optional ................................................................ 562
Prefix for ESP console commands ........................... 406
PREREQ.................................................................. 543
Prerequisite jobs....................................................... 543
Printing trace data .................................................... 709
PRIORITY............................................................... 547
Priority of modeling jobs ......................................... 163
Procedures,exiting from........................................... 299
PROFILE ................................................................. 549
Purging CSF Information......................................... 551
PURGSCHF............................................................. 551
Q
QUEUE data set,displaying...................................... 436
QUIESCE................................................................. 553
QUIT........................................................................ 554
QUPDATE............................................................... 556
769
R
RACF resources, defining........................................ 627
RACINIT................................................................. 557
RACROUTE............................................................ 557
Readying
a job....................................................................... 63
Real resources, refreshing........................................ 594
REEXEC.................................................................. 559
Re-executing ESP Procedures.................................. 559
RELCOUNT............................................................ 562
RELDELAY ............................................................ 564
RELEASE................................................ 566, 568, 569
Releasing
a job....................................................................... 63
an Application ....................................................... 74
Event.................................................................... 566
Event for processing............................................ 568
REMOVE ................................................................ 572
Removing
job dependencies ................................................... 67
lines in job documentation conversion ................ 572
REPORT.................................................................. 574
Report output
data set................................................................. 156
file........................................................................ 159
sysout................................................................... 161
Reporting commands
BREAK ................................................................. 85
COPY.................................................................. 114
CRITERIA........................................................... 124
DATEFORM....................................................... 137
DISPLAY............................................................ 210
ENDR.................................................................. 275
FROM.................................................................. 315
HISTFILE............................................................ 336
INPUT................................................................. 359
REPORT.............................................................. 574
SADGEN............................................................. 612
SORT................................................................... 663
Reporting,scheduled activity.................................... 463
Requesting
a job....................................................................... 63
RESDEF .................................................................. 575
RESDFLT................................................................ 583
Resetting times of a job.............................................. 63
RESOLVE ............................................................... 588
Resource
ABSORB statement ............................................... 24
RESOURCE............................................................. 590
Resources
default .................................................................. 583
defining................................................................ 575
deleting................................................................ 575
displaying ............................................................ 575
job priority........................................................... 547
job requirements .................................................. 590
refreshing............................................................. 594
setting .................................................................. 575
RESREFR................................................................ 594
RESTART................................................................ 595
Restarting
Application processing ........................................ 595
Event proccessing................................................ 595
RESTORE................................................................ 596
Restoring ESP data sets............................................ 596
RESUME ......................................................... 598, 600
Resuming an Event........................................... 598, 600
Revoking access to RACF resources........................ 629
REXX processing
ending .................................................................. 601
starting ................................................................. 602
REXXOFF ............................................................... 601
REXXON................................................................. 602
ROSCOE data sets,submitting JCL from................. 605
ROSSUB.................................................................. 605
ROUTE.................................................................... 606
Routing jobs to another node ................................... 606
RUN......................................................................... 608
Run frequency.......................................................... 608
S
SADGEN................................................................. 612
SADLINK................................................................ 617
SADLINKs,displaying ............................................. 437
SADLOAD............................................................... 619
SADUPD.................................................................. 621
SAF security options ................................................ 624
SAFGRANT............................................................. 622
SAFOPTS ................................................................ 624
SAFRDEF................................................................ 627
SAFRDEL................................................................ 628
SAFREVOK............................................................. 629
SCAN....................................................................... 630
SCHEDULE............................................................. 633
Schedule criteria
Events .................................................................. 633
jobs ...................................................................... 638
sub-Applications .................................................. 638
testing .................................................................. 696
Schedule frequency of job........................................ 608
Scheduled activity data set
creating ................................................................ 612
internal identifier ................................................. 617
loading................................................................. 619
updating ............................................................... 621
Scheduled Activity Report,displaying...................... 463
Scheduled Events,displaying.................................... 438
Scheduling deletion of an Event............................... 188
SECURE.................................................................. 637
Securing symbols ..................................................... 637
Security options,SAF ............................................... 624
SELECT................................................................... 638
SEND....................................................................... 642
Sending a message ................................................... 642
SETPRINT............................................................... 645
Setting
group prefix ......................................................... 328
resources .............................................................. 575
tracking options ................................................... 718
770
SETWIDTH............................................................. 646
SHADOW................................................................ 647
SIGCYCLE.............................................................. 649
Signals
changing number ................................................... 52
cycling ................................................................. 649
defining................................................................ 164
deleting................................................................ 194
displaying ............................................................ 441
posting ................................................................. 651
waiting on ............................................................ 653
SIGPOST................................................................. 651
SIGWAIT ................................................................ 653
SIMULATE............................................................. 655
Simulating
inheriting relationships ........................................ 655
job monitor Events .............................................. 655
USER variables ................................................... 655
Simulating,an Event ................................................. 655
Skipping procedure code.......................................... 396
SMF recording,controlling....................................... 716
SMF records,data set triggers................................... 239
SMF statistics........................................................... 662
SMFSTATS............................................................. 662
SORT....................................................................... 663
Sorting report data ................................................... 663
SPACE..................................................................... 665
Spacing output ......................................................... 665
Special days,defining ............................................... 166
SPINLOG ................................................................ 666
Spinning Audit Log.................................................. 666
SPUSER................................................................... 667
Starting Agent receivers............................................. 37
Statements
%ENDEXCL....................................................... 266
%ENDINCL........................................................ 269
%EXCLUDE....................................................... 295
%INCLUDE........................................................ 346
//* FROM............................................................. 313
//* UNTIL............................................................ 729
//*ESPSYMBOL ................................................. 284
ABANDON DEPENDENCIES............................. 15
ABANDON RESOURCES ................................... 17
ABANDON SUBMISSION.................................. 19
ABSORB............................................................... 24
AFTER.................................................................. 27
ALLOWUNDEF ................................................... 44
APPL..................................................................... 58
CCFAIL................................................................. 94
CHECKEXC........................................................ 100
COPYJCL............................................................ 116
COREQ ............................................................... 119
CRITPATH ......................................................... 129
DATASET........................................................... 133
DELAYSUB........................................................ 184
DESELECT......................................................... 202
DJCDATA........................................................... 212
DJCNET.............................................................. 218
DO....................................................................... 223
DOCLIB.............................................................. 225
DSNAME............................................................ 229
DSTRIG............................................................... 242
DUEOUT............................................................. 246
DURATION........................................................ 250
EARLYSUB........................................................ 251
ELSE.................................................................... 260
ENDDO............................................................... 264
ENDJOB.............................................................. 271
ENDTEMPL........................................................ 276
ESP...................................................................... 277
ESPNOMSG........................................................ 282
EXIT.................................................................... 299
FILE_TRIGGER ................................................. 305
FILENAME......................................................... 303
FLAGUNDEF...................................................... 307
IF 344
INPUTDS............................................................ 360
INTEGER............................................................ 362
JCLLIB................................................................ 367
JOB...................................................................... 372
JOBATTR ........................................................... 379
JUMPTO ............................................................. 396
LATESUB........................................................... 401
MEMBER............................................................ 481
MODEL............................................................... 491
MONITOR .......................................................... 495
MSGLIMIT ......................................................... 502
NOCHECKEXC.................................................. 509
NORUN............................................................... 512
NOTIFY .............................................................. 517
OPTIONS............................................................ 525
PNODES.............................................................. 532
POSTREQ........................................................... 537
PREREQ.............................................................. 543
PRIORITY........................................................... 547
PROFILE............................................................. 549
QUIT ................................................................... 554
REEXEC.............................................................. 559
RELCOUNT........................................................ 562
RELDELAY........................................................ 564
RELEASE............................................................ 569
RESOLVE........................................................... 588
RESOURCE ........................................................ 590
REXXOFF........................................................... 601
REXXON ............................................................ 602
ROUTE................................................................ 606
RUN..................................................................... 608
SECURE.............................................................. 637
SELECT .............................................................. 638
STEPEND ........................................................... 669
SUBAPPL............................................................ 670
TAG..................................................................... 687
TEMPLATE........................................................ 689
TEMPLIB............................................................ 694
THEN.................................................................. 698
TRACKDEF........................................................ 711
WILDCARD........................................................ 737
STATUS .................................................................. 668
STEPEND................................................................ 669
Stopping
Agent receivers ...................................................... 37
Event processing.................................................. 553
Storage cells, tracing.................................................. 97
SUBAPPL................................................................ 670
771
Sub-Applications...................................................... 416
deselecting........................................................... 202
identifying............................................................ 670
Submission, delaying ............................................... 184
SUBMIT.................................................................. 675
Submitting JCL from an Event................................. 675
Successor jobs.......................................................... 569
Suppressing response from ESP commands............. 282
SUSPEND........................................................ 678, 680
Suspending
an Event ....................................................... 678, 680
Symbolic variable libraries
defining................................................................ 169
deleting................................................................ 197
displaying ............................................................ 446
including in an Event ........................................... 681
Symbolic variable library statements
%ENDINCL........................................................ 269
%EXCLUDE....................................................... 295
%INCLUDE........................................................ 346
FLAGUNDEF ..................................................... 307
GENTIME........................................................... 323
INTEGER............................................................ 362
SECURE.............................................................. 637
Symbolic variables
allowing undefined ................................................ 44
changing introducer character in JCL.................. 284
excluding data...................................................... 100
footing string ....................................................... 311
integers ................................................................ 362
title string............................................................. 701
SYMLIB.................................................................. 681
SYSMSGS............................................................... 683
System identifier, displaying.................................... 468
System messages
clearing................................................................ 107
displaying ............................................................ 470
intercepting.......................................................... 683
T
TAG......................................................................... 687
tape pull list.............................................................. 360
TCELLs,displaying.................................................. 471
TCP/IP attributes
address................................................................. 483
displaying ............................................................ 350
setting .................................................................. 350
TEMPLATE ............................................................ 689
Templates
ending.................................................................. 276
starting................................................................. 689
TEMPLIB................................................................ 694
Temporary JCL,limiting use .................................... 729
TEST........................................................................ 696
Testing,schedule criteria .......................................... 696
THEN....................................................................... 698
TIME ....................................................................... 700
Time dependencies,late submission time ................. 401
Time period for modeling ........................................ 700
Time zones,displaying ............................................. 475
Timeline ................................................................... 319
TITLE ...................................................................... 701
Titles,defining .......................................................... 701
TRACE .................................................................... 704
Trace data sets
displaying............................................................. 462
identifying............................................................ 707
Trace data,printing ................................................... 709
TRACEDEF............................................................. 707
TRACEPRT............................................................. 709
Tracing,storage cell usage.......................................... 97
TRACKDEF ............................................................ 711
Tracked job definitions,displaying........................... 472
Tracking
enabling and disabling ......................................... 716
excluding programs.............................................. 394
setting options...................................................... 718
TRACKING............................................................. 716
Tracking model
overriding definition ............................................ 491
Tracking models
cross-system tracking........................................... 760
defining................................................................ 174
deleting ................................................................ 200
displaying............................................................. 474
displaying buffers ................................................ 434
replacing .............................................................. 174
TRACKOPT ............................................................ 718
TRAKFILE,displaying............................................. 448
TRDFLT .................................................................. 721
TRIGGER................................................................ 722
Trigger default ......................................................... 721
Triggering an Event.................................................. 722
TRYJOIN................................................................. 727
U
UNALLOC............................................................... 728
Unallocating a data set ............................................. 728
Unbypassing
a job....................................................................... 63
Undefined symbols................................................... 307
Undefined symbols,allowing...................................... 44
Unrequesting
a job....................................................................... 63
Unwaiting
an Application........................................................ 74
Updating
queues.................................................................. 556
scheduled activity dataset .................................... 621
Usage
of ESP,displaying ................................................ 731
Usage, displaying..................................................... 280
USE.......................................................................... 731
USER....................................................................... 732
User definition file,backing up................................... 83
User definitions
changing................................................................. 55
displaying............................................................. 449
772
User modifications ................................................... 733
User Profile Definition Table
loading................................................................. 461
specifying user profiles........................................ 549
User profiles............................................................. 549
USER variables,simulating ...................................... 655
USERMOD.............................................................. 733
Users
connecting to a group .......................................... 110
defining................................................................ 178
deleting................................................................ 201
V
VS............................................................................ 735
W
WILDCARD............................................................ 737
Workdays, specifying............................................... 144
WTO,allowing or disallowing.................................. 291
X
XCF comands
STOP SERVICE.................................................. 757
XCF commands
DELETE.............................................................. 739
DISPLAY............................................................ 741
FORCE ................................................................ 744
HELP................................................................... 746
PURGE................................................................ 747
SET TERMOPT .................................................. 749
SET TRACE........................................................ 751
SPIN TRACE ...................................................... 752
START SERVICE............................................... 753
START TRACE .................................................. 754
STOP GROUP..................................................... 755
STOP MEMBER................................................. 756
STOP TRACE ..................................................... 758
VERIFY............................................................... 759
XMEs,displaying...................................................... 451
XMITMDL .............................................................. 760
773
Readers Comment Form
ESP v.5.2 CR-02
We want to
hear from you!
Please use this form to communicate your comments about this publication, its
organization or subject matter. All comments will be considered when conducting
future revisions to the manual.
Note: Your comments are provided with the understanding that Cybermation may
use or distribute whatever information you supply in any way it believes appropriate
without incurring any obligation to you.
Page
Number Comment
Do you wish a
reply to your
comments?
Cybermation will reply to your comments, if you request it. Please provide us with
your name and address below.
Name
Company
Address
Fax
E-mail
Note: Please note that comments that justify a reply should be of a more technical
nature (e.g. beyond comments about typographical errors.
774
Mail this form to:
Cybermation Inc.
80 Tiverton Court
Markham, Ontario
L3R 0G4
Attn: Information Development
or Fax it to:
Information Development
(905) 479-5474

Command Ref 52

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Command Ref 52

Uploaded by

Copyright:

Available Formats

ESP Workload Manager

In the above example, temporary JCL for PAYJOB3 is used from 9 am on

You might also like