ESP Workload Managercommandref52

ESP Workload Manager
Version 5.2
Command Reference
ESP-CR-02
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.
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
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 **
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 Apostrophes or Comma , Ellipsis Lower Case Italics parameter Uppercase parameter OR-bar ( | )
Underline ______ Parentheses ( ) and special characters Single parameter in square brackets [ ] Stacked parameters in braces { } { } Stacked parameters in square brackets [ ] [ ] Stacked parameters with OR-bars ( | ) and square brackets [ ] |[ ] Stacked parameters in square brackets within braces {[ ]}
Meaning Must be entered as shown. Must be entered as shown. The parameter can be repeated. Do not enter ellipsis. A parameter must be substituted. User supplied variable or character string. The parameter must be spelled as shown. You can enter the command and the parameter in either upper or lower case. Indicates an exclusive value on left or right of bar. You must enter one of the items. You cannot enter more than one. If you do not enter one of the parameters, the system supplies the underlined parameter, which is the default. Parameter enclosed in parentheses is mandatory and must be entered as shown. Optional parameter, do not type the brackets. Mandatory, you must enter one of the parameters. You cannot enter more than one. Optional parameter, you can enter one value, or none.
Optional, mutually exclusive parameters. Enter one or none.
Mandatory, you must enter one of these parameters. You can enter more than one.
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
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 7
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 8
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
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 10
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
11
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 12
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
13
14
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 Criteria
Description 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.
Continued on next page
15
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.
Example 2
The following ABANDON DEPENDENCIES statement submits a job without its 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.
Example 3
The following ABANDON DEPENDENCIES statement submits a job without its 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.
16
ABANDON RESOURCES Statement
Overview
The ABANDON RESOURCES statement is used to submit a job without its resource dependencies at a specified time.
Type
Syntax
The syntax of the ABANDON RESOURCES statement is:

ABANDON RESOURCES criteria
Parameter Criteria
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 SUBMISSION statement. For information on abandoning a jobs predecessor dependencies, see the ABANDON DEPENDENCIES 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.
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.
17
ABANDON RESOURCES Statement, Continued
Example 2
The following ABANDON RESOURCES statement submits a job without meeting 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.
Example 3
The following ABANDON RESOURCES statement submits a job without meeting 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.
18
ABANDON SUBMISSION Statement
Overview
The ABANDON SUBMISSION statement is used to bypass job submission at a specified time.
Type
Syntax
The syntax of the ABANDON SUBMISSION statement is:

ABANDON SUBMISSION criteria
Parameter Criteria
Description 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 COMMAND ===> Jobname ___ PAYJOB1 ___ PAYJOB2 ___ PAYJOB3 APPL PAYROLL PAYROLL PAYROLL PNODE EXEC PREDWAIT PREDWAIT Row 1 of 3, Col 1 SCR ===> CSR STATUS EXECUTING STEP1 COMPLETE, EXEC ABANDONED 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 SUBMISSION statement. Specifying ABANDON SUBMISSION does not override a:
Manual hold Time dependency Resource dependency. Continued on next page
19
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.
20
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 ABANDON SUBMISSION 9PM JOB PAYJOB7 RUN WORKDAYS ABANDON SUBMISSION 9PM 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.
21
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]
Parameter count
Description 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.
22
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.
23
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.
Type
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.
24
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]...)]
Parameter EXECTIME CPUTIME factor
JOBS
jobname
Description Indicates that an adjustment is to be made to the execution time (or elapsed run time) of the requested job(s). Indicates that an adjustment is to be made to the CPU time of the requested job(s). 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. 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. 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.
25
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.
26
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.
Type
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]...})}
Parameter jobname
ADD DROP A N U
Description Indicates a jobname up to eight characters. Enclose multiple job names in parentheses, separated by a blank or a comma. Jobnames may be qualified. Indicates that the specified job(s) be added to the currently defined AFTERs. Indicates that the specified job(s) be dropped from the currently defined AFTERs. Release on abnormal termination of a predecessor. This includes condition code failures. Release on successful termination of a predecessor. This is the default. 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.
27
AFTER Statement, Continued
Example 1
The following AFTER statement is used to indicate job relationships:

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL 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.
28
Example 3
The following AFTER and AFTER ADD statements are used to indicate job relationships:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB6 RUN DAILY ENDJOB JOB PAYJOB7 RUN DAILY ENDJOB JOB PAYJOB8 RUN DAILY AFTER PAYJOB6 AFTER ADD(PAYJOB7) ENDJOB
In the above example, PAYJOB8 is submitted after the successful completion of PAYJOB6 and PAYJOB7.
Example 4
The following AFTER statements are used to indicate job relationships:

APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB9 RUN DAILY ENDJOB JOB PAYJOB10 RUN DAILY AFTER PAYJOB9 ENDJOB JOB PAYJOB11 CONDITIONAL RUN DAILY AFTER (PAYJOB10(A)) ENDJOB
In the above example, PAYJOB10 is submitted after the successful completion of PAYJOB9. PAYJOB11 is conditional upon the abnormal completion of PAYJOB10. If PAYJOB10 completes successfully, PAYJOB11 is bypassed.
29
Example 5
The following AFTER and AFTER ADD statements are used to indicate job relationships:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB12 RUN DAILY ENDJOB JOB PAYJOB13 RUN DAILY ENDJOB JOB PAYJOB14 RUN DAILY AFTER ADD(PAYJOB12) AFTER ADD(PAYJOB13) ENDJOB
In the above example, PAYJOB14 is submitted after the successful completion of 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))
30
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.
Type
General command.
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]
Parameter AGENT name
Description Displays the contents of the Agent Definition file. 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. Lists the contents of the Agent Definition file for the named Agent. This is the default. Result:
LIST
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
31
AGENT Command, Continued
ALL
CM_OWNED DM_OWNED ORPHANS FLUSH
QUIESCE RESTART
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. Lists all Agents owned by the central Manager. Lists all Agents owned by Distributed Manager(s). Lists all Agents that currently have no owner assigned. Purges all pending messages for each specified Agent. In ESP Version 5 Release 2, FLUSH is used with the ESPCOM command. Holds all messages to be sent to the named Agent until the RESTART command is issued. 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.

32
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)
33
AGENTMSG Command
Overview
The AGENTMSG command is used to issue commands and send messages to Agents.
Type
General command.
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()]
Parameter date time agentname from
Description Indicates the date the message is sent. Specify the actual date or use a period(.) as a placeholder, if omitting the date. Indicates the time the message is sent. Specify the actual time or use a period(.) as a placeholder, if omitting the time. The name of the target Agent. 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.
34
AGENTMSG Command, Continued
Syntax cont Parameter objectname Description 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 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.
CONTROL
35
AGENTMSG Command, Continued
Syntax cont Parameter MGRADDR Description 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. Indicates the new port number. Indicates the new IP address.
port( ) 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
36
AGENTRCV Command
Overview The AGENTRCV command is used to define and display the Managers receiver function for communication with ESP agents.
Type
General command.
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]
Parameter name
DEFINE DELETE LIST HALT QUIESCE RESTART
Description 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. Defines an Agent receiver to the ESP subsystem and starts it. Stops an Agent receiver and deletes it from the ESP subsystem. Displays the status of the ESP subsystems Agent receiver(s). This is the default. Stops an Agent receiver without deleting it. Stops an Agent receiver without deleting it. An alias of HALT. Restarts an Agent receiver that has been HALTed or QUIESCEd.
37
AGENTRCV Command, Continued
Syntax (continued) Parameter SET PORT Description Sets an Agent receiver parameter dynamically. 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. TCP/IP port number. 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. Specifies where Agent messages are received in an APPC/APPN network. 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. APPC LU (Logical Unit) name. 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 with the PORT parameter. APPC TP (Transaction Program) name.
portnumber SYMDEST
symdest LU
luname TPNAME
tpname
38
Syntax (continued) Parameter LOGMODE Description 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 with the PORT parameter. APPC logmode name. 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. Indicates the polling interval in seconds for an APPC agent receiver. If omitted, the default is 5 seconds. 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. 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. Specifies encrypted data will be accepted. Specifies that both encrypted and unencrypted data can be received.
logmode POLLINGINTERVAL
interval1
interval2
DUMPMSGS/ NODUMPMSGS
ENCRYPT NOENCRYPT
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.
39
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.
40
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.
Type
General command.
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)]
Parameter ADD ALTER DELETE LIST xxxx
Description Add an Alert definition. Alter the Event identifier of a previously defined Alert definition. Delete an Alert definition. Display one or more Alert definitions. This is the default. One to four-character logical identifier of the Alert definition. This identifier is used in conjunction with a NOTIFY statement in an ESP Procedure. 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.
eventid
41
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.
42
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.
43
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).
44
ALTCAL Command
Overview
The ALTCAL command is used to modify an existing calendar definition.
Type
General command.
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]...)]
Parameter calname LOGICAL/ ABSOLUTE hh:mm day workday
Description Indicates the name of the calendar to be modified. 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). Modifies the start time of a logical day. Indicates the first day of the week. 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.
45
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.
46
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.
Type
General command.
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)]}
Parameter eventid classname cal1 cal2 hours,minutes
evdsid sym1-sym3
newsys oldsys
Description Indicates an Event identifier. It may contain asterisks and hyphens when a group of Events are to be altered at one time. Indicates a new ESP class, up to eight alphanumeric characters, the first of which must be alphabetic. Indicates a calendar name, up to eight alphanumeric characters, the first of which is alphabetic. Indicates a calendar name, up to eight alphanumeric characters, the first of which is alphabetic. 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). Indicates the ID of an Event data set. This allows you to limit changes to a particular Eventset in a non-SAF environment. 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. Indicates an ESP system ID. This is the SYSTEM identifier to which you are changing. 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.
47
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. 2. 3. 4. Use the LIST command with the ALL parameter in Page mode Type EDIT Make the required changes and then save them to a data set (i.e. CREATE) 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.
48
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.
49
ALTGROUP Command
Overview
The ALTGROUP command is used to modify an existing group definition.
Type
General command.
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]...)]}
Parameter groupname eventdsid deptid
OPER NOOPER UREAD RACID
NORACID cal1 cal2
Description Indicates the specific name of an ESP group. Indicates the logical identifier of the Event database used to store Events prefixed with the group name. 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. Indicates that Events having this group name as a prefix can contain operator commands. Removes the OPER attribute. Indicates that universal read access is available for any Event defined using this group prefix. 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. Indicates that the security attributes of the group name should no longer be used when ESP processes an Event. Indicates the name of the first default calendar, up to eight alphanumeric characters. Indicates the name of the second default calendar, up to eight alphanumeric characters.
50
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.
51
ALTSIG Command
Overview
The ALTSIG command is used to alter the number of generations of a signal.
Type
General command.
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)
Parameter signalname
genno
Description 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. 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.
52
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.
Type
General command.
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)]}
Parameter jobname
PREFIX
Description 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. 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. 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. Indicates that you want the job to be tracked. Indicates that you do not want the job to be tracked. Indicates the name of the tracking model to be associated with the job or jobs. Indicates the number of ancestors of a job that are to remain on the job index data set.
ownerid
TRACK NOTRACK modelname indexcount
Related information
For information on tracking workload, see the ESP Workload Manager Administrators Guide.
53
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.
54
ALTUSER Command
Overview
The ALTUSER command is used to alter the definition of a user.
Type
General command.
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]...)]
Parameter userid USERID groupname PREFIX password
eventdsid histfile
Description Indicates the name of the user entry to be modified. Indicates the user ID is to be used as an Event name prefix. Indicates the group that is to be used as the Event name prefix. Requests the current TSO profile data set prefix is used as the Event name prefix. 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. Indicates the logical identifier of the Event database used to store Events prefixed with the user ID. Indicates the history file ID or mask to which the user has access.
55
ALTUSER Command, Continued
Syntax (continued) Parameter deptid Description Indicates a department name of up to eight characters to which this user belongs. It may contain asterisks and may also have a hyphen in the last character position. Indicates the user can access the Administrator command set of ESP. Indicates Events having the user ID as a prefix can contain operator commands. Indicates the user can define and access Events with any group prefix. Allows the user to define P-Nodes, tracking models and job tracking parameters. 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. 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 will not be able to use the RACID option which is only available with the DEFGROUP command to a user with the SPECIAL attribute. Indicates the user can connect any user to any group within the same department, or department sub-group. Indicates the user can define calendars and assign their use to other users within the same department, or department sub-group. Removes the SPECIAL attribute. Removes the OPER attribute. Removes the ANY attribute. Removes the SCHED attribute. Removes the USERDEF attribute. Removes the GROUPDEF attribute. Removes the CONNECTDEF attribute. Indicates the name of the authorization table assigned to the user. Indicates the name of the first default calendar, up to eight characters. Indicates the name of the second default calendar, up to eight characters.
SPECIAL OPER ANY SCHED USERDEF
GROUPDEF
CONNECTDEF CALENDARDEF
NOSPECIAL NOOPER NOANY NOSCHED NOUSERDEF NOGROUPDEF NOCONNECTDEF tabname cal1 cal2
56
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.
57
APPL Statement
Overview
The APPL statement is used to identify the name of an Application, and to indicate certain processing options for the Application.
Type
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)]
Parameter
applid
WAIT HOLD POST_WHILE_WAITING
NOPOST_WHILE_WAITING
NOPOST_OLDEST
Description Indicates an Application identifier up to eight alphanumeric or national characters. The first character can not be numeric. Indicates that concurrent processing of different generations of an Application is not permitted. Indicates that the Application is to be generated on hold. 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. Indicates that EXTERNAL and MANUAL jobs within the Application are not posted complete if the Application is in: APPLWAIT SUBAPPL WAIT JOB_ANCESTOR_WAIT. 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.
58
APPL Statement, Continued
Syntax (continued) Description 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.
Parameter
59
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 Manager Users Guide. 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.

60
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 Continued on next page
61
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) JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL SUBAPPL ACCREC
62
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.

63
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)] [ENCPARM2(userinfo)] [ENCPARM3(userinfo)] [ENCPARM4(userinfo)] [ENCPARM5(userinfo)] [ENCPARM6(userinfo)] [ENCPARM7(userinfo)] [ENCPARM8(userinfo)] [ENCPARM9(userinfo)] [ENCPARMA(userinfo)] [ENCPARMB(userinfo)] [ENCPARMC(userinfo)] [FROMSTEP(stepname)] [TOSTEP(stepname)] [VERIFY|NOVERIFY] [RESTART]} {UNWAIT} Continued on next page
64
Syntax (continued) Parameter

jobname
ANCESTOR
APPLICATION(applspec)
OLDEST SETREASON
REASON(string)
BYPASS/UNBYPASS
Description 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. 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. 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. Indicates the action is to be performed on the oldest incomplete generation of the Application. Sets a User Status field to the specified string. When you specify SETREASON, you must also specify REASON. SETREASON can be abbreviated to SET. 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. 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.
65
Syntax (continued) Description 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),...)
Parameter
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. Continued on next page
66

SUCCESSORS(joblist)
Description 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)
SUBAPPL(subappl) TAG(tag) VERIFY/ NOVERIFY DATASET(dsname) MEMBER (membername) READY REQUEST/ UNREQUEST
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. Inserts the job as a member of the specified subApplication. Associate this tag with the inserted job. 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. Indicates an explicit JCL library name (may include member name). Indicates an explicit overriding JCL member name. Remove all job dependencies (except resources) from a job (including time, predecessors, manual hold). 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.
67

RESET
Description 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 overdue. This corresponds to the DUEOUT INPUT time. LATEEND(time) Indicates a time at which, if a job has not ended execution, it is to be considered overdue. This corresponds to the 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.
68

DATASET(dsname) MEMBER(membername) JOBNAME(name) RRJOBID(jobid)
USER1-USER4
ENCPARM1-ENCPARM9 and ENCPARMA-ENCPARMC FROMSTEP(stepname)
TOSTEP(stepname)
RESTART
UNWAIT
Description Indicates an explicit JCL library name form which a job is to be resubmitted (may include member name). Indicates an explicit JCL library member for resubmission of the job. Indicates the job name for rerun, if different from the original job name. 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. 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. Indicates parameters of data for resubmitting a job using ESP Encore. Up to 60 characters of information can be specified for each parameter. 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. 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. Indicates the job is to be restarted using ESP Encore. It can only be used in conjunction with the RESUB function. 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).
69
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 Applications, see the ESP Workload Manager Users Guide. 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.

70
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) Continued on next page
71
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.
72
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.
73
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]
Parameter applspec
COMPLETE HOLD
RELEASE UNWAIT OLDEST
Description 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. Completes an Application. Holds an Application. This stops submission of jobs in the Application and places the Application in APPLHOLD status. Releases an Application, i.e. remove from APPLHOLD status. Removes an Application from APPLWAIT status. 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 Applications, see the ESP Workload Manager Users Guide. For information on manipulating jobs belonging to Applications, see the APPLJOB Command - Manipulate Application Jobs.
74
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.
75
BACKOUT
Overview
Use the BACKOUT command if you experience serious difficulties that require you to revert to a previous release of ESP.
Type
General command.
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
76
BKUPEVS Command
Overview
The BKUPEVS command is used to initiate the immediate backup of an Event data set.
Type
General command.
Authority
OPER authority is required to issue the BKUPEVS command.
Syntax
The syntax of the BKUPEVS command is:

BKUPEVS eventdsid
Parameter eventdsid
Description 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.
77
BKUPHIST Command
Overview
The BKUPHIST command is used to initiate the immediate backup of a history data set.
Type
General command.
Authority
OPER authority is required to issue the BKUPHIST command.
Syntax
The syntax of the BKUPHIST command is:

BKUPHIST histfid
Parameter histfid
Description 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.
78
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.
Type
General command.
Authority
OPER authority is required to issue the BKUPINDX command.
Syntax
The syntax of the BKUPINDX command is:

BKUPINDX [?|schedule]
Parameter ? schedule
Description Requests the time of the next scheduled backup be displayed. 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.
79
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.
80
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.
Type
General command.
Authority
OPER authority is required to issue the BKUPJNDX command.
Syntax
The syntax of the BKUPJNDX command is:

BKUPJNDX [?|schedule]
Description Requests that the time of the next scheduled backup be displayed. 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. Information is lost on cold start of ESP.
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.
81
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.
82
BKUPUDEF Command
Overview
The BKUPUDEF command is used to initiate the immediate backup of the User Definition data set or set a backup schedule.
Type
General command.
Authority
OPER authority is required to issue the BKUPUDEF command
Syntax
The syntax of the BKUPUDEF command is:

BKUPUDEF [schedule]
Description Requests that the time of the next scheduled backup be displayed. 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. Information is lost on cold start of ESP.
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.
83
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.
84
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]
Parameter field
length
SPACE n EJECT SUBTOTAL
Description Indicates the name of a field where you want the break to occur. This field must have been specified in a previous DISPLAY section. Indicates the number of characters of the display field to be checked. When a mismatch occurs within this number of characters, a break occurs. Indicates n blank lines are to be printed when a section break occurs. Requests a new page be forced when a break occurs. 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.
85
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.
86
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.
Type
General command.
Syntax
The syntax of the CALENDAR command is:

CALENDAR calendar1[,calendar2]
Parameter calendar1 calendar2
Description Indicates the name of a calendar. Cal1 is searched first for any special day, period and holiday definitions. 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 Manager Users Guide. For information on defining and deleting calendars, see the DEFCAL and DELCAL commands.
87
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.
88
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.
Type
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]
Parameter JOB(jobmask)
STEP(stepname)
PROC(procstep)
PROGRAM(progname)
RC(num)
RC(num1:num2)
Description 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. 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. 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. 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. 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. 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.
89
CCCHK Statement, Continued
Syntax (continued) Parameter RC(Sccc) RC(Unnnn) Description Indicates a system abend code, such as S0C1 or SB37. The ccc must be three hexadecimal digits. Indicates a user abend code, such as U0001 or U0462. The nnnn must be exactly four decimal digits, and cannot exceed 4095. Indicates that the job has not failed. OK is the default. 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. 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. Indicates that the job should be stopped immediately. No other steps should be executed. Only one of CONTINUE or STOP may be specified.
OK FAIL
CONTINUE
STOP
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.
90
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.
91
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 JCLLIB CYBER.JCL.CNTL 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 jobs when completion codes are matched:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL CCCHK RC(1:4095) FAIL STOP JOB PAYJOB2 CCCHK RC(8) OK CONTINUE
In the above example, any job in the PAYROLL Application is considered to have 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.
Example 3
APPL PAYROLL JCLLIB CYBER.JCL.CNTL CCCHK RC(1:4095) FAIL STOP JOB PAYJOB3 CCCHK PROGRAM(IEBGENER) RC(12) OK CONTINUE
In the above example, any job in the PAYROLL Application is considered to have failed and stops processing immediately if a condition code of greater than 0 is 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.
92
Example 4
APPL PAYROLL JCLLIB CYBER.JCL.CNTL CCCHK RC(1:4095) FAIL STOP 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
In the above example, any job in the PAYROLL Application is considered to have failed and stops processing immediately if a condition code of greater than 0 is 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.
93
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.
Type
Syntax
The syntax of the CCFAIL statement is:

CCFAIL (stepname,operator,value)
Parameter stepname
operator
value
Description 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. Specify valid comparison operators as follows: >= or GE <= or LE > or GT < or LT = or EQ = or NE 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.
94
CCFAIL Statement, 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 JCLLIB CYBER.JCL.CNTL CCFAIL (*,GT,4) 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 4.
Example 2
The following locally placed CCFAIL statement identifies when ESP should consider a job as failed:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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.
95
CCFAIL Statement, Continued
Example 3
The following locally placed CCFAIL statement identifies conditions when ESP should consider a job to have failed:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL 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.
96
CELLTRC Command
Overview
The CELLTRC command is used to trace storage cell usage. This can be useful when diagnosing problems involving uncontrolled storage allocation.
Type
General command.
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.
97
CELLTRC Command, 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 SIZE SIZE SIZE SIZE 8, 16, 32, 64, 128, COUNT COUNT COUNT COUNT COUNT 0, 17, 59, 31, 32, ACTIVITY ACTIVITY ACTIVITY ACTIVITY ACTIVITY 0 42 104 85 427
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 ... ...
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 CYBXI000+0054 ADDR 023583FC, BASE 02357708, COUNT 3, BYTES CYBXI003+0CF4 128 32 -
---- 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 Continued on next page
98
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.
99
CHECKEXC Statement
Overview
The CHECKEXC statement is used to indicate that ESP should check the last nonblank 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.
Type
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.
100
CHECKEXC Statement, Continued
Example 1
The following CHECKEXC statement indicates that ESP should check the last nonblank 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 nonblank 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 //STEP001 //STEP002 //STEP003 JOB EXEC PGM=ABC%Z EXEC PGM=DEF 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.

101
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 .
102
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 userdefined 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.
Type
General command.
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]
Parameter classname
HOLD RELEASE
SUSPEND RESUME EXEMPT DEEXEMPT RESET
Description 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. Indicates Events in classes described by the class name are placed in a hold queue at their scheduled time. 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. Indicates Events in classes described by the class name are bypassed at their scheduled execution time. Indicates the SUSPEND restriction is removed for the classes described by the class string. Indicates Events in classes described by the class name are exempt from class hold or suspend restrictions. Removes the EXEMPT restriction. Removes any restrictions from the specified class name.
103
CLASS Command, Continued
Syntax (continued) Parameter FLUSH Description Indicates any Events on the specified class hold queues are flushed and will not execute. This does not affect future scheduled executions. 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. Indicates the IGNORE restriction is removed for the classes described by the class name. Displays any class hold queues for the specified classes. This is the default.
IGNORE
PROCESS LIST
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.

104
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.
105
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.
106
CLRSYSMS Command
Overview
The CLRSYSMS command is used to clear system message interceptions which were defined using the SYSMSGS command.
Type
General command.
Authority
OPER authority is required to issue the CLRSYSMS command.
Syntax
The syntax of the CLRSYSMS command is:

CLRSYSMS ID(xxxx)
Parameter ID(xxxx)
Description 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.
107
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.
Type
General command.
Authority
OPER authority is required to issue the CMDPRFX command.
Syntax
The syntax of the CMDPRFX command is:

CMDPRFX character F stcname,
Parameter character
Description 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
108
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
Parameter comment
Description 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. For information on working with ESP Events, see the ESP Workload Manager 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).
109
CONNECT Command
Overview
The CONNECT command is used to tell ESP which user belongs to which group.
Type
General command.
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]
Parameter userid groupname EXECUTE
READ UPDATE
Description Indicates the name of the user to be connected to the group. Indicates the name of the group to which the user is to be connected. 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. Indicates the user ID is permitted to display an Event, list the schedule and display the status of jobs the Event submits. 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.
110
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 Administrators Guide. 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.
111
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.
Type
General command.
Authority
OPER authority is required to issue the CONSOLE command.
Syntax
The syntax of the CONSOLE parameter is:

CONSOLE [*|ucmid|0|name]
Parameter * ucmid 0 name
Description Requests the console issuing the command is made the primary console. Indicates a one or two digit console UCMID. Indicates no console. Messages routed by routing code on to the active Master console. 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.
Example 2

CONSOLE *
In the above example, the issuing console assumes the role of the primary console.
112
CONSOLE Command, Continued
Example 3

CONSOLE BOSS
In the above example, a console named BOSS is set as the primary console.
113
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.
Type
Reporting command.
Syntax
The syntax of the COPY command is:

COPY {DATASET(dsname)} {FILE(filename)} [SELECT|ALL|REJECT] [EXTEND]
Parameter dsname filename SELECT
ALL REJECT
EXTEND
Description Indicates the name of the output data set. This is mutually exclusive with the filename option. Indicates the name of the file to which the data is to be written. This is mutually exclusive with the dsname option. Indicates only records matching any selection criteria are copied. If no CRITERIA section exists in the report definition, all records are copied. Indicates all records in the input file(s) are copied to the output file. Indicates the copy is restricted to any records that fail to match any selection criteria. If no criteria section exists, no records are copied. 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
114
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.
115
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]
Parameter datasetname
NONE genno
JOBNAME JOBID
Description 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. Indicates no JCL copy is needed. This can only be used at the job level in an Application. 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. Indicates the member name used for storing the JCL for a job is the same as the jobname. This is the default. 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.
116
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
For information on working with ESP Events, see the ESP Workload Manager 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.
117
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 JCLLIB CYBER.JCL.CNTL COPYJCL CYBER.COPYLIB.CNTL JOBID JOB PAYJOB1 RELEASE PAYJOB2 JOB PAYJOB2 RELEASE PAYJOB3 COPYJCL NONE JOB PAYJOB3 ENDJOB SELECT (PAYJOB1,PAYJOB2,PAYJOB3)
In the above example, ESP writes a copy of all submitted jobs within the 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.
EVENT ID(CYBER.PAYROLL) INVOKE CYBBS01.PROCLIB.CNTL(PAYROLL) COPYJCL CYBER.COPYLIB.CNTL GEN(0) JOBNAME ENDDEF
In the above example, ESP writes a copy of all submitted jobs within the PAYROLL Application to the current generation of CYBER.COPYLIB.CNTL and stores the jobs by job name.
118
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.
Type
Syntax
The syntax of the COREQ statement is:

COREQ {jobname} {jobname[,jobname]...} {ADD(jobname[,jobname]...)} {DROP(jobname[,jobname]...)}
Parameter jobname ADD
DROP
Description Indicates a jobname in up to eight characters. Enclose multiple job names in parentheses, separated by a blank or a comma. 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. 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. For information on Applications, see the ESP Workload Manager Users Guide.
119
COREQ Statement, Continued
Example 1
The following COREQ statement identifies job relationships within an Application:

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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.
Example 2

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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.
Example 3

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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.
120
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 JCLLIB CYBER.JCL.CNTL 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.
121
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.
Type
General command.
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]]
Parameter name
Description 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.
122
CPU Command, Continued
ACTIVE (continued) Parameter INACTIVE Description 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. 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.
DEL FORCE
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.
123
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.
Type
Reporting command.
Syntax
The syntax of the CRITERIA command is:

CRITERIA field operator value
Parameter field
operator
Description Indicates a field name keyword (such as JOBNAME). For a detailed list of the history reporting fields, see the ESP Workload Manager Users Guide. Indicates a comparison operator in either their letter or symbol form:

value
LT or < LE or <= EQ NE or = GT or > GE or >= 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
124
CRITERIA Command, Continued
Example 1
The following CRITERIA command specifies selection criteria:

CRITERIA APPLSYS EQ PAYROLL
In the above example, jobs that belong to the PAYROLL Application are selected.
Example 2

CRITERIA APPLSYS EQ PAYROLL CRITERIA JOBNAME EQ P-
In the above example, jobs that belong to the PAYROLL Application, or jobs that start with P, are selected.
Example 3

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.
Example 4

CRITERIA ENDT GT 09:00 TODAY
In the above example, jobs that have completed execution since 9 am today are selected.
125
CRITERIA Command, Continued
Example 5

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.
Example 6

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.
Example 7

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.
126
CRITPATH Command
Overview
The CRITPATH command is used to enable or disable Critical Path analysis on this ESP system.
Type
General command.
Authority
OPER authority is required to issue the CRITPATH command.
Syntax
The syntax of the CRITPATH command is:

CRITPATH [DISABLE|ENABLE|ON]
Operand DISABLE
Description Disallows critical path analysis on this system. Critical path analysis cannot be used on this system when disabled. This is the default. Allows critical path analysis on this system. Then specify CRITPATH ON within the Applications where you want critical path analysis performed. Turn on critical path analysis for all Applications. It can be turned off within an Application using the CRITPATH OFF statement.
ENABLE
ON
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 DISABLE DISABLE DISABLE ENABLE ENABLE ENABLE ON ON ON And the CRITPATH Application statement is set to OFF ON Not specified OFF ON Not specified OFF ON Not specified Then critical path analysis is Not calculated Not calculated Not calculated Not calculated Calculated Not calculated Not calculated Calculated Calculated
127
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.
128
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 ON
Description 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. 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.
OFF
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
For information on critical path analysis, see the ESP Workload Manager Users 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 JCLLIB CYBER.JCL.CNTL CRITPATH ON JOB PAYJOB1
In the above example, critical path analysis is turned on for the PAYROLL Application.
129
CRITPATH Application Statement, Continued
Example 2
The following CRITPATH command turns off critical path analysis:

APPL PAYROLL JCLLIB CYBER.JCL.CNTL CRITPATH OFF JOB PAYJOB2
In the above example, critical path analysis is turned off for the PAYROLL Application.
130
DAB Command
Overview
The DAB command is used to display all or selected jobs from the abended queue.
Type
General command.
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]
Parameter jobstring
minutes time
TIME DATE PROD
Description Indicates one or more jobname prefixes to limit the display to a particular group of jobs. The string can contain asterisks and a hyphen. Indicates only jobs that abended in the last n minutes are to be displayed. 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. Indicates the time of the abend is displayed together with the completion code. Indicates the date of the abend is displayed together with the completion code. 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.
131
DAB Command, Continued
Related information
For information on displaying abended jobs using the CSF, see the ESP Workload Manager Users Guide. 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.
132
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.
Type
Syntax
The syntax of the DATASET statement is:

DATASET dsname [member]
Parameter dsname member
Description Indicates the name of the data set. 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 Manager Users Guide.
Example 1
The following DATASET statement indicates an alternative JCL library for a job within an Application:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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. Continued on next page
133
DATASET Statement, Continued
Example 2
The following DATASET statement indicates an alternative JCL library and member for a job within an Application:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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.
Example 3
APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB5 RUN DAILY IF TODAY(FEB 21, 1998) THEN DATASET CYBER.ALTJCL.CNTL ENDJOB
In the above example, if today is February 21st, 1998, ESP submits PAYJOB5 from CYBER.ALTJCL.CNTL.
Example 4
APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB6 RUN DAILY IF DAYS_FROM(FEB 1,1998) GE 0 AND DAYS_TO(FEB 22,1998) GE 0 THEN DATASET CYBER.ALTJCL.CNTL ENDJOB
In the above example, ESP submits PAYJOB6 from CYBER.ALTJCL.CNTL, from February 1st, 1998 up to and including, February 22nd, 1998.
134
DATEFORM Command
Overview
The DATEFORM command is used to set the date format used in schedule statements.
Type
General command.
Authority
OPER authority is required to issue the DATEFORM command.
Syntax
The syntax of the DATEFORM command is:

DATEFORM [YMD|MDY|DMY]
Parameter YMD MDY DMY
Description Sets the date format to YY/MM/DD. This is the default. Sets the date format to MM/DD/YY. 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.

135
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.
136
DATEFORM Reporting Command
Overview
The DATEFORM reporting command is used to customize the format of date fields displayed in an ESP history report.
Type
Reporting command.
Syntax
The syntax of the DATEFORM command is:

DATEFORM [YMD|MDY|DMY|JULIAN|YM]
Parameter YMD MDY DMY JULIAN YM
Description Sets the date format to DAYYYYYMMDD.

MON19980524
Sets the date format to DAYMMDDYY.

MON052498
Sets the date format to DAYDDMMMYY. This is the default.

MON24MAY98
Sets the date format to DAYDDDYY.

MON14498
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 history reporting, see the ESP Workload Manager Users Guide. For information on setting the date format used in schedule statements, see the DATEFORM command.
137
DATEFORM Reporting Command, Continued
Example 1
The following DATEFORM command formats the dates used in a history report:
REPORT HISTFILE HIST1 FROM 8AM YESTERDAY CRITERIA APPLSYS EQ PAYROLL 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 PAYJOB1 PAYJOB2 PAYJOB3 PAYJOB3 JOB NO 1234 1235 1236 1378 COMP CODE 0 0 S0C1 0 START DATE MON16497 MON16497 MON16497 TUE16597 END DATE MON16497 MON16497 MON16497 TUE16597
138
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.
Type
General command.
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]
Parameter tabname jobname
authstring
ADD
REPLACE
Description Indicates the name of the authorization table in up to eight alphanumeric characters. 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. 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. Indicates this is a new authorization table definition. The definition fails if a definition with the same name already exists. This is the default. 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.
139
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.
140
DEFAT Command, Continued
Example 2

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.
Example 3

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 JOB1 JOB2 JOB1 Account AC02 AC02 ACO2A Access ALLOWED ALLOWED DISALLOWED
141
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.
Type
General command.
Syntax
The syntax of the DEFAULT command is:

{DEFAULT|DEFLT} {[USER{(userid|NONE)}]} {[GROUP{(racfgroupid|(NONE)}]} {[PASSWORD{(password)|(NONE)}]}
Parameter userid
racfgroupid
password
NONE
Description 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. 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. Indicates the password you want ESP to place as an operand of the PASSWORD keyword on the job card for JCL submitted by ESP. 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 Manager Administrators Guide.
142
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.
143
DEFCAL Command
Overview
The DEFCAL command is used to define an ESP calendar. Use calendars to define scheduling terms that satisfy specific processing situations.
Type
General command.
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)] [DEPARTMENT(deptid)] [LOGICAL|ABSOLUTE] [SHIFT(hh:mm)] [WEEKSTART(day)] [WORKDAYS(workday[,workday]...)]
Parameter calname
string
deptid
LOGICAL/ ABSOLUTE hh:mm day workday
Description Indicates the name of the calendar. Can be up to eight alphanumeric or national characters ($, #, @). The first character must be alphabetic. 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. Indicates a department name of up to eight characters to 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. Indicates a logical calendar or an absolute calendar. The default is ABSOLUTE (i.e. days begin at midnight). Note: Absolute calendars are recommended. Indicates the start time of a logical day. If specified, your logical day is shifted forward by the specified time. Indicates the first day of the week. This overrides the default specified in the ESP Initialization Parameters. Indicates which days are to be considered workdays. Separate each with a comma. This overrides the default specified in the ESP Initialization Parameters.
144
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 Administrators Guide. For information on using special calendars in an Event, see the ESP Workload Manager Users Guide. 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.
145
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 ===> DEFAULT ===> WORKDAYS: SUNDAY MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY SATURDAY ===> ===> ===> ===> ===> ===> ===> Y Y Y Y Y (Hours and Minutes, e.g. 08:01) (Enter L for logical, A for absolute) (Enter Y against each day that is to be eligible as a workday. Leave all blank to pick up installation default)
FIRST DAY OF WEEK ===> MON ANY MORE? ===>
(SUN, MON etc. Blank for installation default)
(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.
146
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.
Type
General command.
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) [DEPARTMENT(deptid)] [AUTH(OPER)] [UREAD] [RACID] [CALENDAR(cal1[,cal2]...)]
Parameter groupname eventdsid
deptid
OPER UREAD RACID
cal1 cal2
Description Indicates a one to eight character group name. Indicates in up to eight characters the logical identifier of the Event database used to store Events prefixed with the group name defined. 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. Indicates Events having this group name as a prefix can contain operator commands. Indicates universal read access is available for any Event defined using this group prefix. Indicates the group name should be used for security attributes when ESP processes an Event rather than the ID of the defining user. Indicates the name of the first default calendar for Events that start with the group prefix, up to eight characters. Indicates the name of the second default calendar, up to eight characters.
147
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
For information on defining groups, see the ESP Workload Manager Administrators 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.
148
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.
149
DEFHOL Command
Overview
The DEFHOL command is used to define a holiday.
Type
General command.
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)]
Parameter holidayname
starttime
endtime
duration x,units
calname
Description Indicates the name of a holiday. Can be up to 16 alphanumeric or national characters ($, #, @). The underscore character can also be used. 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. 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. Indicates the length of the holiday in hours. 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. Indicates the name of the calendar in which the holiday is to be defined, otherwise user ID defaults are used.
150
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 Workload Manager Users Guide. 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) DEFHOL CHRISTMAS START(25 DECEMBER 1989) FOR(24) DEFHOL CHRISTMAS START(25 DECEMBER 2000) FOR(24)
In the above example, multiple holidays with the same name - CHRISTMAS are defined as 24 hour holidays in three successive years.
151
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 31st until January 2nd 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 5th, 1998 at 4 pm ending January 6th, 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.
152
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.
Type
General command.
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)]
Parameter name id
ADD
REPLACE seqno
ownerid
Description Indicates the name of the P-Node, in up to 16 characters. 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 applies only if you are using ESPs internal security. Indicates this is a new definition. The request fails if a definition with the same name already exists. ADD is the default. Replaces a current P-Node definition of same name. 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. 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.
153
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 Manager Advanced Users Guide. 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.
154
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)
155
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.
Type
General command.
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)]
Parameter repname dsname
serial
unitname primary
secondary
EXTEND
Description Indicates a one to eight character alphanumeric logical report name. 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. 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. Indicates the name of the output device type, using up to eight characters. Indicates the primary allocation you want to assign, in parentheses. You must specify after this whether you are allocating CYLINDERS, TRACKS or BLOCKS. 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. Indicates the output should be added to the end of the data set. If you do not specify EXTEND, the data set is overwritten.
156
DEFPRINT Command - DATASET Option, Continued
Syntax (continued) Parameter length V Description Indicates the logical record length for each line of output. Specify the number of characters you want in each line. Indicates variable length records. This is the default. The line length is four bytes less than what you specified under LRECL. Indicates fixed length records. Indicates the number of lines on each page, including titles and footings. Indicates the size in bytes of a block allocation unit. Indicates the actual length of blocks on a data set. The limit is 32767 bytes.
F lines size block
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.
157
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.
158
DEFPRINT Command - FILE Option
Overview
Type
General command.
Syntax
The syntax of the DEFPRINT command is:

DEFPRINT repname DDNAME(file) [EXTEND] [LRECL(length)] [RECFM{(V)|(F)}] [PAGELENGTH(lines)] [BLOCK(size)] [BLKSIZE(block)]
Parameter repname file
serial
unitname primary
secondary
EXTEND
length V
Description Indicates a one to eight character alphanumeric logical report name. 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. 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. Indicates the name of the output device type, using up to eight characters. Indicates the primary allocation you want to assign, in parentheses. You must specify after this whether you are allocating CYLINDERS, TRACKS or BLOCKS. 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. Indicates the output should be added to the end of the data set. If you do not specify EXTEND, the data set is overwritten. Indicates the logical record length for each line of output. Specify the number of characters you want in each line. Indicates variable length records. This is the default. The line length is four bytes less than what you specified under LRECL.
159
DEFPRINT Command - FILE Option, Continued
Syntax (continued) Parameter F lines size block Description Indicates fixed length records. Indicates the number of lines on each page, including titles and footings. Indicates the size in bytes of a block allocation unit. Indicates the actual length of blocks on a data set. The limit is 32767 bytes.
Usage notes
Related information
For information on ending a report print definition, see the ENDPRINT command. 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. 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

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.
160
DEFPRINT Command - SYSOUT Option
Overview
Type
General command.
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]
Parameter repname class destcode n type length V
F lines char SPIN
Description Indicates a one to eight alphanumeric logical report name. Indicates a one-character class number. Indicates a destination code of up to eight characters. If you do not specify DEST, the destination defaults to LOCAL. Indicates the number of copies you want printed. The maximum is 240 copies. Indicates the type of form you want to use for printing, using up to four characters. Indicates the logical record length for each line of output. Specify the number of characters you want in each line. Indicates variable length records. This is the default. The line length is four bytes less than what you have specified under LRECL. Indicates fixed length records. Indicates the number of lines on each page, including titles and footings. Indicates the universal character set type you want to be used on the printer for this printout. Indicates the data should be made available for printing as soon as you enter the ENDPRINT command.
Usage notes
161
DEFPRINT Command - SYSOUT Option, Continued
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 data set, see the DEFPRINT command DATASET 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

DEFPRINT DEPT123 SYSOUT(J)
In the above example, output for report DEPT123 is directed to a sysout class of J.
162
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
Parameter nn
Description 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 Workload Manager Advanced Users Guide.
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.
163
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.
Type
General command.
Syntax
The syntax of the DEFSIG command is:

DEFSIG signalname [GEN(genno)]
genno
Description 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. 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 Workload Manager Users Guide.
164
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.
165
DEFSPEC Command
Overview
The DEFSPEC command is used to define a special day or period.
Type
General command.
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)]
Parameter specname
date
schedule
calname cal1, cal2
Description 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. 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. 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. Indicates the calendar in which the special day or period is to be defined. This is the TARGET calendar on the ISPF panel. 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.
166
DEFSPEC Command, Continued
Syntax (continued) Parameter x, units Description 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. For information on defining and deleting holidays, see the DEFHOL and DELHOL 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.
167
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 1st are defined up to the year 2001 in the calendar ACCT1. Each fiscal year is retained on the system for two calendar years.
168
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.
Type
General command.
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]
Parameter name
dsn
user
ADD REPLACE
Description Indicates the name of the symbol library. It can consist of up to eight alphanumeric characters, the first of which must be alphabetic. 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. 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. Indicates this is a new definition, and is not to replace an existing entry, if there is one. This is the default. Indicates this definition replaces an existing one.
169
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 Manager Advanced Users Guide. 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.
170
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.
171
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.
Type
General command.
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]
Parameter jobname modelname
TRACK NOTRACK indexcount
ownerid
PREFIX
Description Indicates the job or job prefix to be defined. If a prefix is defined, the jobname should contain asterisks or a hyphen. 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. Indicates you want the job to be tracked. This is the default. Indicates you do not want the job tracked. 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. Indicates an ownership string for the job(s). It may contain asterisks or a hyphen. This applies if your are using ESPs internal security. 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.
172
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 Administrators Guide. 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 DEFTJ DEFTJ DEFTJ PAYJOB99 MODEL(PAYSPEC) INDEX(10) PAY- MODEL(PAYREG) PREFIX TEST- NOTRACK - 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.
173
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.
Type
General command.
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)]
Parameter name TRACK NOTRACK
Description Indicates the name of the tracking model, in up to eight characters. Indicates you want jobs using this model tracked. This is the default. Indicates jobs using this model are not tracked. This is normally specified in the job tracking definition table.
174
DEFTM: Define Tracking Model, Continued
Syntax (continued) Parameter pnode Description 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. Indicates this is a new definition. This is the default. The request fails if a definition with the same name already exists. Indicates the model is to be replaced. This parameter must be used if a definition with the same name exists. 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. 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. 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. Indicates the name of the Event to be triggered whenever any job using this model starts. Indicates the name of the Event to be triggered whenever any job using this model ends (i.e. successful or unsuccessful). 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. Indicates the name of the Event to be triggered whenever any job using this model abends. This does not include condition code failures. Indicates the name of the Event to be triggered for each step end of any job using this model.
ADD
REPLACE indexcount
histfid
groupname
JOBSTARTEVENT JOBENDEVENT
JOBFAILEVENT
JOBABENDEVENT
STEPENDEVENT
175
Syntax (continued) Parameter STEPFAILEVENT Description 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. 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.
STEPABENDEVENT
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 Manager Users Guide.
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.
176
Example 2

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.
Example 3

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.
177
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.
Type
General command.
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)}] [PASSWORD(password)] [HISTFILE(histfile)] [DEPARTMENT(deptid)] [(OPER)|(NOOPER)] [(SPECIAL)|(NOSPECIAL)] [(ANY)|(NOANY)] [AUTH[(SCHEDULER)|(NOSCHEDULER)]] [(USERDEF)|(NOUSERDEF)] [(GROUPDEF)|(NOGROUPDEF)] [(CONNECTDEF)|(NOCONNECTDEF)] [(CALENDARDEF)|(NOCALENDARDEF)] [AUTHTAB(tabname)] [CALENDAR(cal1[,cal2]...)]
Parameter userid eventdsid
USERID groupname PREFIX password
Description Indicates a one to eight character TSO user ID to be defined. 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. Indicates the user ID is to be used as an Event name prefix. This is the default. Indicates the group which to use as the Event name prefix. Indicates the current TSO profile data set prefix is used as the Event name prefix. 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.
178
DEFUSER Command, Continued
Syntax (continued) Parameter histfile Description 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. Indicates a department name of up to eight characters to which this user belongs. It may contain asterisks and may also have a hyphen in the last character position. Indicates the user can access commands relating to Administration. Indicates the user can issue operator commands. Indicates the user can define and access Events with any group prefix. Indicates the user can define P-Nodes, tracking models and job tracking parameters. 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. The DEPARTMENT keyword must be used with this keyword. 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. Indicates a user can connect any user to any group within the same department or department subgroup. Indicates a user defines calendars and makes them available to other users within the same department or department subgroup. Removes the SPECIAL attribute. Removes the OPER attribute. Removes the ANY attribute. Removes the SCHEDULER attribute. Removes the USERDEF attribute. Removes the GROUPDEF attribute. Removes the CONNECTDEF attribute. Removes the CALENDARDEF attribute. Removes the USERDEF attribute. Indicates the name of the authorization table assigned to the user, up to eight characters.
deptid
SPECIAL OPER ANY SCHEDULER USERDEF
GROUPDEF
CONNECTDEF CALENDARDEF
NOSPECIAL NOOPER NOANY NOSCHEDULER NOUSERDEF NOGROUPDEF NOCONNECTDEF NOCALENDARDEF NOUSERDEF tabname
179
Syntax (continued) Parameter cal1 cal2 Description Indicates the name of the first default calendar, up to eight characters. 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.
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 Administrators Guide. 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.
180
Example 2

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.
Example 3

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.
Example 4

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.
181
DELAT Command
Overview
The DELAT command is used to delete an authorization table. This command applies only if you are using ESPs internal security.
Type
General 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
Parameter tabname
Description 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 Administrators Guide.
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.
182
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.
Type
General command.
Authority
OPER authority is required to issue the DELAYINT command.
Syntax
The syntax of the DELAYINT parameter is:

DELAYINT [nn|5]
Parameter nn
Description 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..
183
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.
Type
Syntax
The syntax of the DELAYSUB statement is:

DELAYSUB criteria
Parameter criteria
Description 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.
184
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 APPLJOB or AJ command. 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 JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL 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 Continued on next page
185
DELAYSUB Statement, Continued
Example 3
The following DELAYSUB statement sets the delayed submission time based on the day of the week:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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
186
DELCAL Command
Overview
The DELCAL command is used to delete a calendar and all the holidays and special days within it.
Type
General command.
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
Parameter calname
Description 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.
187
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
Parameter criteria
Related information
For information on working with ESP Events, see the ESP Workload Manager 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 2nd, 1998.
188
DELETE Command - General
Overview
The DELETE command is used to delete an Event definition.
Type
General command.
Syntax
The syntax of the DELETE command is:

{DELETE|DEL} eventid
Parameter eventid
Description 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
For information on working with ESP Events, see the ESP Workload Manager 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.
189
DELGROUP Command
Overview
The DELGROUP command is used to delete a group definition. This command applies only if you are using ESPs internal security.
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
Parameter groupname
Description Indicates the name of the group to be deleted.
Related information
For information on defining groups, see the ESP Workload Manager Administrators Guide. For information on defining groups, see the DEFGROUP command. For information on displaying information about a group, see the LISTGRP command.
Example 1
The following DELGROUP command deletes a group:

DELGROUP ACCOUNTS
In the above example, the ACCOUNTS group is deleted.
190
DELHOL Command
Overview
The DELHOL command is used to delete a holiday definition.
Type
General command.
Authority
You can delete only holidays defined in your first default calendar, or in calendars to which you have access.
Syntax
The syntax of the DELHOL command is:

{DELHOL|DELH} holidayname START(starttime) [CALENDAR(calname)]
Parameter holidayname starttime
calname
Description Indicates the 1 to 16 character name of the holiday Indicates the starting time and date of the holiday. If the date specification contains separators, it should be enclosed in quotes. 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. 3. The SYSTEM calendar. The first matching holiday entry found is deleted.
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.
191
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.
192
DELPN Command
Overview
The DELPN command is used to delete a P-Node definition.
Type
General command.
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
Parameter pnode
Description Indicates the name of the P-Node being deleted.
Related information
For information on defining processing nodes (P-Nodes), see the ESP Workload Manager Advanced Users Guide. 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.
193
DELSIG Command
Overview
The DELSIG command is used to delete a signal.
Type
General command.
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
Description Indicates the name of the signal. If the prefix is omitted, the current group or user prefix is used.
Related information
For information on signal processing, see the ESP Workload Manager Advanced Users Guide. For information on defining signals, see the DEFSIG command. For information on posting a generation of a signal, see the SIGPOST command. For information on altering the numbers of generations of a signal, see the ALTSIG 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.
194
DELSPEC Command
Overview
The DELSPEC command is used to delete a special day or period definition.
Type
General command.
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)]
Parameter specname date
calname
Description Indicates a 1 to 16 character name of a special day or period. Indicates the starting time and date of the special day or period. If the date specification contains separators, it should be enclosed in quotes. 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. 3. The SYSTEM calendar. 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.
195
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 26th, 1998 is deleted.
196
DELSYML Command
Overview
The DELSYML command is used to delete a symbol library.
Type
General command.
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
Parameter name
Description 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.
197
DELTJ Command
Overview
The DELTJ command is used to delete tracked job definitions from the job index file.
Type
General command.
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]
Parameter jobname
PREFIX
Description 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. 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 job tracking definition tables, see the ESP Workload Manager Administrators Guide. 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.
198
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
199
DELTM Command
Overview
The DELTM command is used to delete a tracking model definition.
Type
General command.
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
Parameter model
Description 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.
200
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.
Type
General command.
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
Parameter userid
Description 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. For information on changing a users definition, see the ALTUSER 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.
201
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.
Type
Syntax
The syntax of the DESELECT statement is:

DESELECT {jobname|(jobname[,jobname])} [JOB|SUBAPPL]
Parameter jobname JOB SUBAPPL
Description Indicates a jobname. Enclose multiple jobnames in parentheses, separated by a blank or comma. Indicates a job is being deselected for submission. This is the default. 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.
202
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 JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL 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.
203
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 JCLLIB CYBER.JCL.CNTL 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 SELECT (PAYJOB10,PAYJOB11) 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
204
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.
Type
General command.
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)]}
Parameter NONE AUTH SPECIAL
OPER ANY
GROUP PREFIX groupid USERID evdb
Description Indicates no unauthorized users may access the system. Indicates the attributes to be assigned to the user. Indicates the user is allowed full access to ESP, including holiday and special day definitions as well as group and user definitions. Indicates the user is allowed to issue ESP operator commands. Indicates the user is allowed to access any Event, even though he is not connected to the group in which the Event is defined. Indicates the default GROUP to which the user is assigned. Indicates the TSO profile prefix should be used. This is the default if the GROUP keyword is not specified. Indicates the group prefix of your choice, using up to eight characters. Indicates the user ID should be used as a group prefix for Events. 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.
205
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 Administrators Guide.
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.
206
DFPNODE Command
Overview
The DFPNODE command is used to display or set the default P-Node for the issuing system console or TSO session.
Type
General command.
Authority
OPER authority is required to issue the DFPNODE command.
Syntax
The syntax of the DFPNODE command is:

DFPNODE [pnodename]
Parameter pnodename
Description 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
For information on posting a job complete from a manual P-Node, see the POST command. For information on defining and deleting manual P-Nodes, see the DEFPN and DELPN commands. For information on defining processing nodes (P-Nodes), see the ESP Workload Manager Advanced Users Guide.
207
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
208
DISCONN Command
Overview
The DISCONN command is used to remove the authority of a user to access a group prefix.
Type
General command.
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)
Parameter userid groupname
Description Indicates the user ID to be disconnected. 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.
209
DISPLAY Command
Overview
The DISPLAY command is used to specify which reporting fields you want to display when creating history reports.
Type
Reporting command.
Syntax
The syntax of the DISPLAY command is:

DISPLAY field [length] [title1] [title2]
Parameter field length
title1 title2
Description Indicates the name of a field to be displayed. 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. Indicates a title, enclosed in quotes. 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 Workload Manager Users Guide. 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).
210
DISPLAY Command, Continued
Example 2

DISPLAY JOBNAME,RDRON,RDRONDATE,TEXCP 5 TAPE EXCPS DEXCP 6 DISK EXCPS
In the above example, the following fields are displayed as part of a history report: 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).
Example 3

DISPLAY JOBNAME 15,CMPC
In the above example, the following fields are displayed as part of a history report: Job name, padded on the right with blanks to a width of 15 (JOBNAME) Completion code (CMPC).
211
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 ID RS TC HC RL BF
Description NETID RESOURCE TAPES NHOLD RELEASE BEFORE
Abbreviation AF NC AB NR OH LN
Description AFTER NORMAL ABNORMAL NETREL OPHOLD LASTNET

212
DJCDATA Statement, Continued
Syntax Parameter name Description 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. 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. 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. 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. 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. 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. 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. 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.
op
resname
TC(t)
HC(num)
RL(jobname)
BF(jobname)
213
Syntax (continued) Parameter AF(jobname) Description 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. 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. 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. This is the default. 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. 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.
NC
AB
NR
214
Syntax (continued) Parameter OH Description 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. 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. 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. This is the default. 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.
LN
ABCMP
NRCMP
This parameter is for use only with JES3. 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

215
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.
216
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.
217
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
Parameter netid
Description 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.
218
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 JCLLIB CYBER.JCL.CNTL 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.
219
DN Command
Overview
The DN command is used to display the names of jobs, TSO users and started tasks on the P-Node queues.
Type
General command.
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]
Parameter pnodename
jobname
tsuname
stcname
mins
Description 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. 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. 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. Indicates the name(s) of started tasks 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. 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.
220
DN Command, Continued
Syntax (continued) Parameter AT(time) Description 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. Indicates the time the job entered the P-Node queue is displayed. Indicates the date the job came into the P-Node queue is displayed. 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. 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. Indicates the system ID, where the JOB/STC/TSU was last posted from, be displayed.
TIME DATE COMPRESSED
DUE
SID
Usage notes
As an alternative to using the DN command to display the names of jobs on the PNode 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. For information on defining processing nodes (P-Nodes), see the ESP Workload Manager Advanced Users Guide. For information on posting a job complete from a manual P-Node, see the POST command. For information on monitoring and controlling workload using the CSF, see the ESP Workload Manager Users Guide.
Example 1
The following DN command displays all queues:

DN
In the above example, all P-Node queues are displayed.

221
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.
222
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:
IF TODAY(LAST WORKDAY OF MONTH) THEN 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.
223
DO Statement, Continued
Example 2
The following DO and ENDDO statements are used to identify the start and end of a 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 1st. If the number of days from January 1st is greater than 7, ESP: Resumes and then triggers an Event called CYBER.YECHEQUE Sends a message to user CYB02.
Example 3
The following DO and ENDDO statements are used to identify the start and end of a 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)
224
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
Parameter dsname
Description 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.
225
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 JCLLIB CYBER.JCLLIB.CNTL 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.
Example 2
APPL PAYROLL JCLLIB CYBER.JCLLIB.CNTL DOCLIB CYBER.DOCLIB.CNTL 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.
Example 3
DJCNET PAYROLL JCLLIB CYBER.JCLLIB.CNTL DOCLIB CYBER.DOCLIB.CNTL 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.
226
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.
Type
General command.
Authority
OPER authority is required to issue the DQ command.
Syntax
The syntax of the DQ command is:

DQ [QUEUE(pnodename],pnodename]...)]
Parameter pnodename
Description 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 defining processing nodes (P-Nodes), see the ESP Workload Manager Advanced Users Guide. 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.
227
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.
228
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.
Type
Syntax
The syntax of the DSNAME statement is:

DSNAME dsname [JOBNAME(jobname)] [RENAME] [ANYCLOSE] [COUNT(n)]
Parameter dsname
JOBNAME(jobprefix)
RENAME
ANYCLOSE
COUNT(n)
Description 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. 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. Indicates the trigger should occur if a data set is renamed to dsname. The new data set name becomes the triggering data set name. 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. 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.
229
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 Manager Users Guide.
230
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.
231
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)
232
DSTRDLY Command
Overview
The DSTRDLY command is used to delay data set triggered Events or data set trigger objects when data set activity occurs.
Type
General command.
Authority
OPER authority is required to issue the DSTRDLY command.
Syntax
The syntax of the DSTRDLY command is:

DSTRDLY [nn|0]
Parameter nn
Description 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. For information on data set triggering at the Event level, see the ESP Workload Manager Users Guide.
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 Continued on next page
233
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.
234
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.
Type
General command.
Authority
OPER authority is required to issue the DSTREXCL command.
Syntax
The syntax of the DSTREXCL command is:

DSTREXCL {pgmname} [(pgmname[,pgmname]...)]
Parameter pgmname
Description 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.
235
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
236
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.
Type
Syntax
The syntax of the DSTRIG command is:

DSTRIG dsname [JOB(jobname)] [MULTIPLE] [PRIMED] [RENAME] [ANYCLOSE] [COUNT(n)] [CURRENT(n)]
Parameter dsname
jobname
MULTIPLE
PRIMED
RENAME
Description 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. 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. 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. 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. 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.
237
DSTRIG Command, Continued
Syntax (continued) Parameter ANYCLOSE Description 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. 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. 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.
COUNT
CURRENT
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.
238
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 data set triggering at the Event level, see the ESP Workload Manager Users Guide. 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. For information on data set triggering at the job level, see the DSTRIG or DSNAME 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.
239
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.
240
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.
241
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.
Type
Syntax
The syntax of the DSTRIG statement is:

{DSTRIG|DT} name[.qualifier] [REQUEST] [HOLD] [CONDITIONAL]
Parameter name qualifier
REQUEST HOLD
CONDITIONAL
Description Indicates a workload object name in up to eight characters. Indicates a workload object qualifier in up to eight characters. It must immediately follow the workload object name separated by a period. Indicates this is an on-request workload object. 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. 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.
242
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 data set triggering at the Event level, 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
243
DSTRST Command
Overview
The DSTRST command is used to control data set triggering activity.
Type
General command.
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]
Parameter SUSPEND RESUME QUIESCE
RESTART LOG
NOLOG
Description Suspends data set triggering. All data set triggers are ignored. Indicates data set trigger processing is resumed. This is the opposite of SUSPEND. 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. Indicates data set triggering is restarted, and all detected triggers processed. This is the opposite of QUIESCE. 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. Deactivates data set trigger logging.
Usage notes
To display the status of data set triggering, issue the DSTRST command with no operands.
Related information
For information on data set triggering at the job level, see the DSTRIG or DSNAME statements. For information on data set triggering at the Event level, see the ESP Workload Manager Users Guide.
Example 1
The following DSTRST command displays data set trigger options:

OPER DSTRST
In the above example, data set trigger options are displayed.

244
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.
245
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.
Type
Syntax
The syntax of the DUEOUT statement is:

DUEOUT pnodename time
Parameter pnodename
Description 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.
246
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 PNode 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.
247
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.
248
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 JCLLIB CYBER.JCL.CNTL 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.
249
DURATION Statement
Overview
The DURATION statement is used to tell ESP what duration to use for Critical Path.
Type
Syntax
The syntax of the DURATION statement is:

DURATION value
Parameter value
Description 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.
250
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.
Type
Syntax
The syntax of the EARLYSUB statement is:

EARLYSUB criteria
Parameter criteria
Description 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.
251
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 APPLJOB or AJ command. 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 JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL 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.
252
EARLYSUB Statement, Continued
Example 3
The following EARLYSUB statement sets the delayed submission time based on the day of the week:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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:
IF TODAY(LAST WORKDAY OF MONTH) THEN EARLYSUB 11PM ELSE EARLYSUB 9PM
253
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.
Type
General command.
Syntax
The syntax of the ECHO command is:

ECHO character string
Parameter character string
Description 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.
254
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.
255
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.
Type
General command.
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)]
Parameter DISPLAY
SET DELETE CLASS
MPL
Description 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. Alter the specified EI class settings. Delete the specified EI class. All TDRs queued to the deleted class are moved to class 0. 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. 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.
256
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 the ESP Workload Manager Installation Guide.
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.

257
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:

EICLASS SET CLASS(0) MPL(1) EICLASS SET CLASS(5) MPL(1) EICLASS SET CLASS(10) MPL(1)
In the above example: 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:

EICLASS SET CLASS(99) MPL(1)
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.
258
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.
Type
General command.
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.
259
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.
Type
Syntax
The syntax of the ELSE statement is:

ELSE action
Parameter ELSE
action Usage notes
Description 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. Indicates the action that should be taken.
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. For information on using ESPs Control Language, see the ESP Workload Manager Users Guide. For information on advanced usage of ESPs Control Language, see the ESP Workload Manager Advanced Users Guide.
260
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.
261
END Command
Overview
The END command is used to end the ESP terminal session or batch execution.
Type
General command.
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 Manager Users Guide.
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: USERDEF: INDEX: JOBINDEX: QUEUE: TRAKFILE: EVENTSET: HISTFILE: APPLFILE: JTDT: UPDT: --> END CYB2.ESP510.CKPT, ALT NONE CYB2.ESP510.USERDEF, BKUP NONE CYB2.ESP510.INDEX, BKUP NONE CYB2.ESP510.JOBINDEX CYB2.ESP510.QUEUE, ALT NONE CYB2.ESP510.TRAKFILE CYB2.ESP510.EVENT1 CYB2.ESP510.HISTFILE CYB2.ESP510.APPLFILE CYB2.ESP510.PARMLIB(JOBDEF1) CYB2.ESP510.PARMLIB(PROFILE)
In the above example, system data sets allocated to ESP are displayed (LDSN). Enter END to terminate this Line mode session.
262
ENDDEF Command
Overview
The ENDDEF command is used to end an Event definition.
Type
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. For information on Events, see the ESP Workload Manager Users Guide.
Example 1
The following is an example of an Event definition:

EVENT ID(CYBER.PAYROLL) SCHEDULE DAILY AT 8AM INVOKE CYB.ESP.PROCS(PAYROLL) ENDDEF
In the above example: 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.
263
ENDDO Statement
Overview
The ENDDO statement is used to identify the end of one or more action statements.
Type
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. 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 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.
264
ENDDO Statement, Continued
Example 2
The following DO and ENDDO statements indicate a set of action statements:

APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB1 RUN WORKDAYS IF TODAY(MONDAY) THEN 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.
265
%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.
266
%ENDEXCL Statement, Continued
Example 2
The following %EXCLUDE statement used in JCL ends the exclusion of a DD statement on Mondays:
%EXCLUDE DAY(MONDAY) //INPUT05 DD DSN=CYBER.INPUT.DATA,DISP=SHR %ENDEXCL
In the above example, the DD statement INPUT05 is excluded on Mondays.
267
ENDHC Command
Overview
The ENDHC command is used to stop routing of output as specified by a HARDCOPY command.
Type
General 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
In the above example: 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.
268
%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.
Type
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
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 %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.
269
%ENDINCL Statement, Continued
Example 2
The following %ENDINCL statement used in JCL ends the inclusion of a DD statement on Mondays:
%INCLUDE DAY(MONDAY) //INPUT05 DD DSN=CYBER.INPUT.DATA,DISP=SHR %ENDINCL
In the above example, DD statement INPUT05 is included on Mondays.
270
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.
Type
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 JCLLIB CYBER.JCL.CNTL 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.
271
ENDJOB Statement, Continued
Example 2
The following ENDJOB statement is used to end job definitions:

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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.
272
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 Workload Manager Advanced Users Guide. 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
In the above example: 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.
273
ENDPRINT Command
Overview
The ENDPRINT command is used to close each of the report data files opened with the DEFPRINT command.
Type
General command.
Syntax
The syntax of the ENDPRINT command is:

ENDPRINT reptname
Parameter reptname
Description 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

DEFPRINT XREF DDNAME(MODEL1) MODEL CYBER.SAD.DATA 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
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.
274
ENDR Command
Overview
The ENDR command ends a history report definition and starts the report generation phase.
Type
Reporting command.
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 CRITERIA APPLSYS EQ PAYROLL DISPLAY JOBNAME JOBNO APPLSYS CMPC ENDR
In the above example: 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.
275
ENDTEMPL Statement
Overview
The ENDTEMPL statement is used to indicate the end of a template definition.
Type
Syntax
The syntax of the ENDTEMPL statement is:

ENDTEMPL
Related information
For information on working with templates, see the ESP Workload Manager Advanced Users Guide. 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 JCLLIB CYBER.JCL.CNTL 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.
276
ESP Statement
Overview
The ESP statement is used to issue any ESP command from within an ESP Procedure.
Type
Syntax
The syntax of the ESP statement is:

ESP command
Parameter command
Description 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.
277
ESP Statement, Continued
Example 2
The following ESP statement is used to complete a task when a resource is available:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL 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.
278
ESPCOM Command
Overview
The ESPCOM command is used to display and control ESP communications activity between the ESP Agents and ESP Workload Manager.
Type
General command.
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}
Parameter LIST
DEST agentname QUIESCE RESTART FLUSH
Description 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. Use to specify an individual Agent. Name of the target Agent you want to view or manipulate. Use with the DEST keyword to QUIESCE an individual Agent. Use with the DEST keyword to RESTART an individual Agent. 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
279
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.
Type
General command.
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.
280
ESPCTR Command, Continued
Example 1
The following ESPCTR command displays usage statistics:

OPER ESPCTR APPCMP APPCRE EVXEQ JOBSUB 499,499,13,143 737,737,27,211 2220,2220,43,594 1190,1190,13,365
In the above example: 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 *******************************
281
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.
Type
Syntax
The syntax of the ESPNOMSG statement is:

ESPNOMSG command
Parameter command
Description 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.
282
ESPNOMSG Statement, Continued
Example 2
The following ESPNOMSG statement is used to complete a task when a resource is available:
APPL WAIT4 JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL 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.
283
//*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
Parameter symbol
Description 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.
284
//*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 # //PAYJOB1 JOB CYB,CLASS=A,MSGCLASS=0 #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.
285
EVENT Command
Overview
The EVENT command is used to start an Event definition.
Type
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)]
Parameter eventid
Description 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. Indicates this is a new Event. If one already exists with the same name, the new definition is ignored. This is the default. Indicates this is a new Event. If one already exists with the same name, it is to be replaced. 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).
ADD REPLACE classname
286
EVENT Command, Continued
Syntax (continued) Description 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.
Parameter
287
Syntax (continued) Parameter EICLASS(eiclassname) Description 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 Events, see the ESP Workload Manager Users Guide. For information on Event initiators, see the ESP Workload Manager Installation Guide.
288
Example 1

EVENT ID(CYBER.PAY1) SCHEDULE 8AM DAILY INVOKE CYBER.ESP.PROCS(PAY1) ENDDEF
In the above example: The EVENT command starts the Event definition The SCHEDULE and INVOKE Events statements define the Event The ENDDEF command ends the Event definition.
289
Example 2

EVENT ID(CYBER.PAY2) REPLACE SUSPEND OWNER(FRED) SCHEDULE 9AM DAILY INVOKE CYBER.ESP.PROCS(PAY2) ENDDEF
In the above example: 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. The ENDDEF command ends the Event definition.
Example 3

EVENT ID(CYBER.PAY3) SYSTEM(E510) CLASS(PROD) ITU SCHEDULE 9AM DAILY INVOKE CYBER.ESP.PROCS(PAY2) ENDDEF
In the above example: 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. The ENDDEF command ends the Event definition.
Example 4

EVENT ID(CYBER.PAYROLL) EICLASS(99) SCHEDULE 8PM WORKDAYS INVOKE CYBER.PROCLIB.CNTL ENDDEF
In the above example, an Event initiator class of 99 is assigned to CYBER.PAYROLL.
290
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.
Type
General command.
Authority
OPER authority is required to issue the EVENTOPT command.
Syntax
The syntax of the EVENTOPT command is:

EVENTOPT [WTO|NOWTO] [VS|NOVS]
Parameter WTO NOWTO VS NOVS
Description Allows Write to Operator from within an Event. This is the default Disallows Write to Operator from within an Event. Allows the use of MVS commands from within an Event. This is the default. 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
For information on Events, see the ESP Workload Manager Users Guide.
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.
291
EVENTSET Command
Overview
The EVENTSET command is used to define or alter the definition of an Event data set.
Type
General command.
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]
Parameter eventdsid dsname newdsname backupdsname NOBACKUPDSNAME schedule
Description Indicates a unique identifier of up to eight characters. Indicates the name of a VSAM KSDS defined with the right attributes. Indicates a VSAM KSDS similar to the above. Indicates a non-VSAM sequential data set. Used to remove the backupdsname, if already specified. 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. Indicates a new Event data set is being defined. If not specified, DEFINE is the default. 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. Indicates an Event data set is to be reopened. Indicates an Event data set is to be closed and de-allocated from ESP. Indicates an existing specification is changed without the need to open or close the data set. Indicates all prior schedule requests for Events on the deferred queue are flushed. Succeeding schedule requests are honored.
DEFINE DELETE
OPEN CLOSE SET FLUSH
292
EVENTSET Command, Continued
Syntax (continued) Parameter SHR NOSHR JOURNAL Description Indicates the data set is to be shared. Indicates the data set is not to be shared. This is the default. Indicates a record be written to SMF each time an Event is defined, updated or deleted (refer to SMFREC Initialization Parameter). 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. Indicates the Time Driven Requests (TDRs) are built.
NOJOURNAL
BUILDSCHED
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.
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.
293
EVENTSET Command, Continued
Related information
For information on the EVENTSET Initialization Parameter, see the ESP Workload Manager Installation Guide. For information on Events, see the ESP Workload Manager Users Guide.
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
294
%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.
Type
Syntax
The syntax of the %EXCLUDE statement is:

%EXCLUDE [FROM(fromdate)] [TO(todate)] [DAY(dayofweek[,dayofweek]...)] [EVENT(eventid)] [IF(expression)] [COPYJCL]
Parameter fromdate todate
dayofweek
eventid
expression COPYJCL
Description Indicates a time and date specification in any format that is valid in a schedule statement. 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. 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. 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. Value of a logical expression. 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.

295
%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 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 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.
296
Example 1
The following %EXCLUDE statement used in a symbolic variable library requests the exclusion of data on Mondays:
%EXCLUDE DAY(MONDAY) 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 statement on Mondays:
%EXCLUDE DAY(MONDAY) EVENT(CYBER.PAYROLL) //INPUT05 DD DSN=CYBER.INPUT.DATA,DISP=SHR %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.
297
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) //STEP3 EXEC PGM=PGM2 %EXCLUDE FROM(MAY 1,1997) TO(MAY 5,1997) //STEP4 EXEC PGM=PGM3 %EXCLUDE IF(ESPAHH GE 08 AND ESPAHH LE 14 AND TODAY(WED)) //STEP5 EXEC PGM=PGM4 %ENDEXCL
In the above example: 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))
298
EXIT Statement
Overview
The EXIT statement is used to quit from your current point in an ESP Procedure.
Type
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 Workload Manager Users Guide.
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.
299
EXIT Statement, Continued
Example 2
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)
In the above example: 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.
Example 4
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.
300
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 JCLLIB CYBER.JCL.CNTL JOB PAYJOB1 RUN WORKDAYS RELEASE PAYJOB2 IF TODAY(MONDAY) THEN EXIT ENDJOB JOB PAYJOB2 RUN WORKDAY IF TODAY(MONDAY) THEN 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 Jobname APPL PNODE STATUS ___ PAYJOB1 PAYROLL COMPLETE COMPLETED AT 13.14 21 APR ___ PAYJOB2 PAYROLL SUBERROR Submit Error, Quit
301
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.
Type
Syntax
The syntax of the EXPECT command is:

EXPECT criteria
Parameter 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 Events, see the ESP Workload Manager Users Guide. For information on creating schedule activity reports, see the ESP Workload Manager Users Guide. 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.
302
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.
Type
Syntax
The syntax of the FILENAME statement is:

FILENAME pathto\filename [CREATE|UPDATE|DELETE]
Parameter pathto filename
CREATE
Description Indicates the fully qualified path to the directory where the file filename exists or is created. Indicates the name of the file whose activity triggers the release of the job named in the associated FILE_TRIGGER statement. 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. 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. 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.
UPDATE
DELETE
Usage notes
The FILENAME statement must be used within the scope of a FILE_TRIGGER statement to describe the trigger.
303
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.
304
FILE_TRIGGER Statement
Overview
The FILE_TRIGGER statement defines a workload object associated with a nonMVS file trigger and is used in conjunction with the FILENAME statement to build file dependency, at the job level, into ESP Applications.
Type
Syntax
The syntax of the FILE TRIGGER statement is:

{FILE_TRIGGER|FM} name[.qualifier] [REQUEST] [CONDITIONAL]
Parameter name qualifier
REQUEST CONDITIONAL
Description Indicates a workload object name in up to eight characters. Indicates a workload object qualifier in up to eight characters. It must immediately follow the workload object name separated by a period. Indicates this is an on-request job. 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.
305
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.
306
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.
Type
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 builtin symbolic variable (ESPADD) was typed incorrectly (EXXPADD).
307
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).
308
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)]
Parameter name applname jobname
Description Indicates the name of the flow chart by a name of up to 7 characters. Indicates the name of an Application to be exported. Indicates the name or names of jobs to be exported. Several names can be specified, if separated by a comma. The names can contain asterisks and end with a hyphen for a generic 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 Workload Manager Users Guide. For information on exporting data that describes an ESP Application in a format usable by MS Project, see the GENPROJ command. For information on exporting data that describes an ESP Application in a format 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.
309
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.
Example 2
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) JOB(PAY-) GO
In the above example, ESP: Exports the jobnames, start and end times for jobs with PAY in the first three positions, within the PAYROLL Application Identifies a flowchart called PAYROLL Proceeds with the copy process.
310
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]
Parameter n DELETE footing string
Description Indicates which footing line is being defined, or deleted. n can be a value from one to seven. The default is 1. Indicates the specified footing line is to be deleted. 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: Parameter %CE %DATE %DAY %DD %DDDD %DOW# %EVAL Description Centers the Parameter within the output line. Full date, e.g. SUNDAY 4th JANUARY 1998. Day of week name, e.g. MONDAY. Day of month number, i.e. from 01 to 31. Julian day or day of year number. E.g. 365 for last day. Day of week number, e.g. 1 for Sunday, 7 for Saturday, regardless of calendar settings. Returns the numeric value of an expression. An outputformat descriptor may follow the parameter to request leading blanks or zeros. Hour, in 24-hour format, e.g. 14. Returns the length of the Parameter. Month number, e.g. 01 if the month is January. First three characters of the month, e.g. JAN. Minute of the hour. Month name, e.g. JANUARY. The current page number. Justifies the parameter on the right side of the output line. Seconds. Time, in 24-hour format, e.g. 14.30.00.
%HH %LENGTH %MM %MMM %MM %MONTH %PAGE %RJ %SSS %TIME
311
FOOTING Command, Continued
Usage notes (continued) Parameter %YEAR %YY Description Year, e.g. 1999. 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 //STEP001 EXEC PGM=ESP,PARM='SUBSYS(E510)',REGION=4M //STEPLIB DD DSN=CYB2.ESP510Q.SSCPLINK,DISP=SHR //SYSPRINT DD SYSOUT=* //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.
312
//* 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.
Type
Syntax
The syntax of the // * FROM statement is:

//*FROM criteria
Parameter 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 Advanced Users Guide.
313
//* 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 //PAYJOB1 JOB CYB,CLASS=A,MSGCLASS=0
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 //PAYJOB2 JOB CYB,CLASS=A,MSGCLASS=0
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 //PAYJOB3 JOB CYB,CLASS=A,MSGCLASS=0
In the above example, temporary JCL for PAYJOB3 is used from 9 am on November 27, 1998 until 4 pm on November 30, 1998.
314
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)]
Parameter starttime endtime
Description Indicates a free format starting time. Use any valid schedule criteria that resolve to a single date and time. 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.
315
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 29th, 1999 to January 4th, 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
316
GENDOC Command
Overview
Use the GENDOC command to convert an existing job documentation library to a documentation library usable by ESP.
Type
General command.
Syntax
The syntax of the GENDOC command is:

GENDOC inputdataset outputdataset [LEVEL(memname[,memname]...)] [SNUM]
Parameter inputdataset outputdataset
memname
SNUM
Description Indicates the name of the input data set, enclosed in quotes, which must be a PDS. 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. 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 multiplecharacter wildcard. ABC- matches any member name beginning with ABC while A*C matches any threecharacter name beginning with A and ending with C. If the LEVEL keyword is omitted, all members are copied. 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.
317
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 indicating that all specifications are complete and that the copy process should proceed, see the GO command. For information on ESPs job documentation facility, see the ESP Workload Manager Users Guide. 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
In the above example, ESP: 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. Proceeds with the copy process.
318
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.
Type
Reporting command.
Syntax
The syntax of the GENFLOW command is:

GENFLOW inputdsn outputdsn
Parameter inputdsn outputdsn
Description Indicates the name of the scheduled activity data set, enclosed in quotes. 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 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 identifying a flowchart, see the FLOW command. For information on indicating that all specifications are complete and that the copy process should proceed, see the GO command. For information on creating graphical representations of workload, see the ESP Workload Manager Users Guide. For information on exporting data that describes an ESP Application in a format usable MS Project, see the GENPROJ command.
319
GENFLOW Command, Continued
Example 1
The following GENFLOW, FLOW and GO commands are used to export data describing an ESP Application in a format usable by Timeline:
GENFLOW ESP.DAILY.SADGEN CYB.PC.TRANSFER FLOW PAYROLL APPL(PAYROLL) GO
In the above example, ESP: Exports the jobnames, start and end times of 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.
320
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.
Type
Reporting command.
Syntax
The syntax of the GENPROJ command is:

GENPROJ applname[.gen|OLDEST] DATASET(outputdsn)
Parameter applname
Description 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 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. Indicates the oldest incomplete generation of the Application to be used as input. If all generations are complete, you cant use OLDEST.
outputdsn
OLDEST
321
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 2. Use a PC file transfer program to send the data to a PC 3. Execute the Cybermation supplied utility CONVERT.EXE on your PC 4. Access MS Project to view and print flowcharts
Related information
For information on creating graphical representations of workload, see the ESP Workload Manager Users Guide. For information on exporting data that describes an ESP Application in a format 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.
322
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
Parameter prefix
criteria
Description Indicates a user-defined string of up to 55 characters that becomes the prefix for the symbols you generate with this statement. Schedule criteria that resolve to a single date and time.
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.
323
GENTIME Command, Continued
The GENTIME command generates the following 15 customized date and time symbolic variables: Variable prefixDATE prefixYY prefixYEAR prefixMM prefixMMM prefixMONTH prefixDAY prefixDD prefixDDD PrefixDDQL prefixDOW# prefixTIME prefixHH prefixMN prefixSS Description The Event date in full. Example: Sunday 4th January 1998 The last two digits of the year Example: 98 The Year. Example: 1998 The number of month. Example: 01 for January The first three characters of month. Example: Jan The name of month. Example: January The name of the day of the week. Example: Monday The number of actual day of month. Example: 09 The Julian day, or the number day in the year. Example: 365 The ordinal qualifier for the day. Example: st, nd, rd or th The number of day in week as specified in a calendar. Example: 1 for Sunday (ESP default) The time in 24-hour format. Example: 14.55.32 The hour in 24-hour format. Example: 14 The minute of hour. Example: 55 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.
324
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 18th, 1998: %NWDMM resolves to 02 %NWDDD resolves to 049 %NWDYY resolves to 98 %NWDDOW# resolves to 4 %NWDDATE resolves to Wednesday February 18th, 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.
325
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
In the above example: 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 1ST 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
326
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 Manager Users Guide. For information on creating graphical representations of workload, see the ESP Workload Manager Users Guide.
Example 1
GENDOC JOBDOC.DATA ESP.JOBDOC.DATA LEV(A,B) SNUM 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.
Example 2
The following GENFLOW, FLOW and GO commands are used to export data describing an ESP Application in a format usable by Timeline:
GENFLOW ESP.DAILY.SADGEN CYB.PC.TRANSFER FLOW PAYROLL APPL(PAYROLL) GO
In the above example, the GO command indicates that the GENFLOW specification is complete and that the copy process should start.
327
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.
Type
General command.
Syntax
The syntax of the GROUP command is:

{GROUP|GR} [groupprefix] [USERID] [PREFIX]
Parameter groupprefix
USERID PREFIX
Description Indicates up to eight characters to be the prefix for unqualified Event descriptive names. (You must be connected to the group specified.) Indicates the current TSO USERID is used to prefix unqualified Event names. 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 Administrators Guide. For information on defining and deleting groups, see the DEFGROUP and DELGROUP commands. For information on displaying information about a group, see the LISTGRP command.
328
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
329
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.
Type
General command.
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)]
Parameter dsname
serial
unitname primary
secondary
EXTEND
length V
Description 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. 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. Indicates the name of the output device type, using up to eight characters. Indicates the primary allocation you want to assign, in parentheses. You must specify this if you are allocating CYLINDERS, TRACKS or BLOCKS. 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 are allocating 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. Indicates the output should be added to the end of the data set. If you do not specify EXTEND, the data set is overwritten. Indicates the logical record length for each line of output. Specify the number of characters you want in each line. Indicates variable length records. This is the default. The line length is four bytes less than what you specified under LRECL.
330
HARDCOPY Command - DATASET Option, Continued
Syntax (continued) Parameter F lines size block Description Indicates fixed length records. Indicates the number of lines on each page, including titles and footings. Indicates the size in bytes of a block allocation unit. Indicates the actual length of blocks on a data set. The limit 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.
331
HARDCOPY Command - FILE Option
Overview
Syntax

{HARDCOPY|HCPY} DDNAME(file) [EXTEND] [LRECL(length)] [RECFM{(V)|(F)}] [PAGELENGTH(lines)] [BLOCK(size)] [BLKSIZE(block)]
Parameter file EXTEND length V
F lines size block
Description Indicates a file name using up to eight characters. Indicates that the output should be added to the end of the data set. Indicates the logical record length for each line of output. Specify the number of characters you want in each line. Indicates variable length records. This is the default. The line length is four bytes less than what you specified under LRECL. Indicates fixed length records. Indicates the number of lines on each page, including titles and footings. Indicates the size in bytes of a block allocation unit. Indicates the actual length of blocks on a data set. The limit 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 command, see the ENDHC command.
Example 1

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.
332
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.
333
HARDCOPY Command - SYSOUT Option
Overview
Type
General command.
Syntax

{HARDCOPY|HCPY} SYSOUT(class) [DEST(destcode)] [COPIES(n)] [FORM(type)] [LRECL(length)] [RECFM{(V)|(F)}] [PAGELENGTH(lines)] [UCS(char)] [SPIN]
Parameter class destcode n type length V
F lines char SPIN
Description Indicates a one-character class number. Indicates a destination code of up to eight characters. If you do not specify DEST, the destination defaults to LOCAL. Indicates the number of copies you want printed. The maximum is 240 copies. Indicates the type of form you want to use for printing, using up to four characters for the code. Indicates the logical record length for each line of output. Specify the number of characters you want in each line. Indicates variable length records. This is the default. The line length is four bytes less than what you have specified under LRECL. Indicates fixed length records. Indicates the number of lines on each page, including titles and footings. Indicates the universal character set type you want to be used on the printer for this printout. 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 command, see the ENDHC command.
334
HARDCOPY Command - SYSOUT Option, Continued
Example 1

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.
335
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.
Type
Reporting command.
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
Parameter hfid
Description 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 history reporting, see the ESP Workload Manager Users Guide. For information on displaying history files, see the LISTHIST command. For information on working with history files, see the ESP Workload Manager Administrators Guide.
336
HISTFILE Command - Reporting, Continued
Example 1

REPORT HISTFILE HIST1 FROM 7AM YESTERDAY CRITERIA APPLSYS EQ PAYROLL DISPLAY JOBNAME JOBNO APPLSYS CMPC ENDR
In the above example: The REPORT command invokes the report processor The HISTFILE command indicates that HIST1 is to be scanned The FROM, CRITERIA and DISPLAY report statements define the report 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)
337
HISTFILE Command - Definition/Alteration
Overview
Used to define or alter the definition of an ESP history data set.
Type
General command.
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]
Description 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.
Parameter
338
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 Administrators Guide. 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.
339
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.
Type
Syntax
The syntax of the HOLD command is:

HOLD criteria
Parameter criteria
Description 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 Events, see the ESP Workload Manager Users Guide. For information on decrementing an Events hold count that was previously incremented via a HOLD command, see the RELEASE command.
340
HOLD Command - Event Level, Continued
Example 1

EVENT ID(CYBER.PAYROLL) 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:
EVENT ID(CYBER.PAYROLL) DSTRIG PAYROLL.INPUT HOLD DAILY AT 9AM RELEASE DAILY AT 11AM SUBMIT CYBER.JCL.CNTL(PAYJOB1) /* FOLLOWING EXECUTIONS PENDING: /* DATASET TRIGGER BY JOB ACCJOB9 AT 09.15.00 ON THU FEB, 1998 /* DSN PAYROLL.INPUT ENDDEF
Example 2

EVENT ID(CYBER.PAYROLL) DSTRIG PAYROLL.INPUT HOLD 9AM FEB 14, 1998 ONCE RELEASE 11AM FEB 14, 1998 ONCE SUBMIT CYBER.JCL.CNTL(PAYJOB2) ENDDEF
In the above example, HOLD and RELEASE commands are used to prevent PAYJOB2 from being submitted between 9 am and 11 am on February 14 1998.
341
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.
Type
General command.
Syntax
The syntax of the HOLD command is:

HOLD eventid
Parameter eventid
Description 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 Events, see the ESP Workload Manager Users Guide. 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.
342
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.
343
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.
Type
Syntax
The syntax of the IF statement is:

IF expression
Parameter expression
Description Indicates an expression that can be evaluated to return a true or false value.
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. The ELSE statement is used in conjunction with an IF statement when the expression that follows the IF statement returns a false value. 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
For information on using ESPs Control Language, see the ESP Workload Manager Users and Advanced Users Guides. For more information on specifying conditional logic, see the THEN and ELSE statements.
344
IF Statement, Continued
Example 1
The following logic is used to process different action statements:

IF %ESPADAY = MONDAY THEN SEND TODAY IS MONDAY U(USR01) ELSE SEND TODAY IS %ESPADAY U(USR01)
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 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.
Example 3
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.
345
%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]
Parameter fromdate todate dayofweek
eventid
expression COPYJCL
Description Indicates a time and date specification in any format that is valid in a schedule statement. Indicates a time and date specification in any format that is valid in a schedule statement. 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. 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. Value of a logical expression. 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.
346
%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.
Note: Before using the %INCLUDE 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 ending the selective inclusion of JCL and DATA, see the %ENDINCL statement.
347
Example 1
The following %INCLUDE statement used in a symbolic variable library requests the inclusion of data on Mondays:
%INCLUDE DAY(MONDAY) 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 statement on Mondays:
%INCLUDE DAY(MONDAY) //INPUT05 DD DSN=CYBER.INPUT.DATA,DISP=SHR %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.
348
Example 4
The following %INCLUDE statements used in JCL request the inclusion of various steps:
//CYBERJOB JOB CYB999,CLASS=A,MSGCLASS=S //STEP1 EXEC PGM=IEFBR14 %INCLUDE IF(ESPSDATE=ESPADATE) //STEP2 EXEC PGM=PGM1 %INCLUDE IF(ESPATIME GT 07.59.00) //STEP3 EXEC PGM=PGM2 %INCLUDE FROM(MAY 1,1997) TO(MAY 5,1997) //STEP4 EXEC PGM=PGM3 %INCLUDE IF(ESPAHH GE 08 AND ESPAHH LE 14 AND TODAY(WED)) //STEP5 EXEC PGM=PGM4 %ENDINCL
In the above example: 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))
349
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}
Parameter DISPLAY
Description Displays a TCP/IP object. The following options are supported: INET DISPLAY ACTIVE CLOSE INET DISPLAY HOST_CACHE INET DISPLAY TCPIP INET DISPLAY TRACE Display of all active TCP/IP sockets. Displays the current TCP/IP close option. (RESET or SHUTDOWN) Displays the ESP TCP/IP host cache entries. Displays information on the current TCP/IP stack. Displays TCP/IP tracing facility. 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. Displays all the INET command options. Purges a TCP/IP socket or all TCP/IP sockets running under a specified task. Displays the TCP/IP address of a host. The short form is: INET Q H hostname.
ACTIVE CLOSE HOST_CACHE TCPIP TRACE FLUSH
HELP PURGE QUERY HOST hostname
350
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. Displays a list of currently active TCP/IP sockets. Displays a list of currently active TCP/IP sockets and their respective task IDs. Displays a list of currently active TCP/IP sockets and their respective task IDs. Sets a TCP/IP object. Indicates a print data set for the TRACE log SYSOUT. 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. 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. Spins a TCP/IP object. Currently the only supported option is: INET SPIN TRACE
socketid TASK taskid SET SYSOUT(class) CLOSE
HOST_CACHE TTL
SPIN
START
The TCP/IP trace sysout file is closed and deallocated. A new one is then immediately allocated and opened. Starts a TCP/IP object. Currently the only supported option is: INET START TRACE
STOP
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. 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.
351
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)
352
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.
Type
General command.
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)]
Parameter DEFINE DISPLAY
DELETE serverid
clientname
applname
Description Indicates a new server transaction be added. Indicates information on all (or specific) servers for the current Application be displayed. Information displayed includes serverid, client name and TP Application name. Indicates the deletion of a transaction server. Indicates a logical server identifier of up to 25 characters. This identifier is specified on the INFOSERV command when sending a request. Indicates a client name of up to eight characters for your Application. This client must be defined to Infoserv via the CLIDEF command. 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.
353
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.
354
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.
Type
General command
Syntax
The syntax of the INFOMSG command is:

INFOMSG SET|RESET [PREFIX(string)]
Parameter SET
PREFIX(string)
RESET
Description Indicates messages should be displayed within the body of the screen. This includes the full message text and ESP message number. Indicates displayed messages should be prefixed with a user specified string. PREFIX can be abbreviated to PR. This parameter is optional. 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.
355
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_.
356
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)]
Parameter START
SET
STOP
initnum
classname
cpunumber
Description 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. 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. 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. Indicates a number, range of numbers, or list of numbers and ranges of numbers. Each number must be within the range 1999. Indicates up to eight character class names or list of class names assigned to this initiator. The first character must be alphabetic. 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.
357
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 how ESP processes workload in your environment, see the ESP Workload Manager Advanced Users Guide. 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)
In the above example: 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)
358
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.
Type
Reporting command.
Syntax
The syntax of the INPUT command is:

INPUT {DATASET(dsname)} {FILE(filename)}
Parameter dsname filename
Description Indicates the name of the input data set. This is mutually exclusive with the FILE option. 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
Example 1

REPORT INPUT DATASET(CYBER.ESP.HISTORY1) FROM 7AM YESTERDAY CRITERIA APPLSYS EQ PAYROLL DISPLAY JOBNAME JOBNO APPLSYS CMPC 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.
359
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.
Type
Syntax
The syntax of the INPUTDS statement is:

INPUTDS dsname(genno)
Parameter dsname genno
Description Indicates the name of tape input data set. 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.
360
INPUTDS Statement, Continued
Example 1
The following INPUTDS statements indicate the tape data sets associated with each job in an Application:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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.
361
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...]
Parameter varname
Description 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 Workload Manager Advanced Users Guide.
362
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.
Example 2

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

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.
363
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.
364
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)
Parameter dataset
member
Description Indicates the name of the data set that contains the ESP Procedure. The data set and member must be enclosed in quotes. 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 Workload Manager Users Guide. For information on invoking an ESP Procedure from another ESP Procedure, see the ESP Workload Manager Users Guide.
Example 1
The following is an example of an Event definition that invokes an ESP Procedure:

EVENT ID(CYBER.PAYROLL) SCHEDULE 10PM WEEKDAYS INVOKE CYBER.PROCS.CNTL(PAYJOBS) ENDDEF
In the above example, the PAYJOBS ESP Procedure is invoked every weekday at 10 pm.
365
INVOKE Command, Continued
Example 2
The following is an example of an ESP Procedure that invokes another ESP Procedure:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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 builtin or user defined symbolic variables required by the jobs in the PAYROLL Application.
366
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.
Type
Syntax
The syntax of the JCLLIB statement is:

JCLLIB 'dsname'
Parameter dsname
Description 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.
367
JCLLIB Statement, Continued
Example 1
The following JCLLIB statement identifies the JCL library to be used:

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL JOB PAYJOB3 RUN DAILY REL PAYJOB4 MEMBER PAYJOB99 JOB PAYJOB4 RUN DAILY DATASET CYBER.ALTJCL.CNTL ENDJOB
In the above example: 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.
368
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.
369
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.
Type
General command.
Authority
OPER authority is required to issue the JESCOMCH command.
Syntax
The syntax of the JESCOMCH command is:

JESCOMCH character
Parameter character
Description 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.
370
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.
Type
General command.
Authority
OPER authority is required to issue the JESTYPE command.
Syntax
The syntax of the JESTYPE command is:

JESTYPE [2|3] [DJC|NODJC]
Parameter 2 3 DJC NODJC
Description Indicates JES2 is in use. This is the default. Indicates JES3 is in use. Indicates normal processing for DJC networks. 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.
371
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.
Type
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)]
Parameter jobname qualifier REQUEST NOREQUEST TASK NOTASK OWNER
LINK NOLINK PROCESS
Description Indicates a jobname of up to eight characters. Indicates a job qualifier of up to eight characters. It must immediately follow the jobname separated by a period. Indicates this is an on-request job. Indicates this is not an on-request job. This is the default. Indicates this is a task that requires manual completion. ESP does not try to submit JCL for a TASK. Indicates this is not a task that requires manual completion. This is the default. 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. Indicates this is a task that does not require manual completion. ESP does not try to submit JCL for a LINK. Indicates this is a task that does require manual completion. This is the default. Indicates you want to use a LINK to issue commands.
372
JOB Statement, Continued
NOPROCESS MANUAL NOMANUAL string
NODE
NONODE INHERIT NOINHERIT EXTERNAL
NOEXTERNAL hh:mm
applname criteria
CONDITIONAL
NOCONDITIONAL HOLD
NOHOLD
Indicates you do not want to use a LINK to issue commands. This is the default. Indicates this job is manually submitted, outside of ESP. Indicates this job is not being submitted, outside of ESP. This is the default. Indicates an authorization string as defined by the AUTHSTR Initialization Parameter. This can only be used with the EXTERNAL and MANUAL keywords. 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. Indicates a job is not a node for inheriting job relationships. This is the default. This is the default. Indicates job relationships should not be inherited. Indicates a job is submitted by another ESP Application. The EXTERNAL parameter is used to build interApplication dependencies. Indicates a job is not submitted by another ESP Application. This is the default. 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. Indicates the name of the Application that submits the job. 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. Indicates this job may or may not execute. The Application this job belongs to is considered complete when all NOCONDITIONAL jobs are complete. Indicates this job must complete in order for the Application to be considered complete. This is the default. 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. Indicates a job is not to be placed on manual hold when ESP generates the Application. This is the default.
373
CRITICAL
NOTCRITICAL docmember
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. Indicates this job does not represent a critical point in the Application. This is the default. 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.
374
Related information
For information on ending a job definition, see the ENDJOB statement. For information on Applications, see the ESP Workload Manager Users Guide.
Example 1
The following is an example of an ESP Application:

APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB1 RUN DAILY ENDJOB
In the above example, the JOB statement is used to identify PAYJOB1 as part of the PAYROLL Application.
Example 2

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

APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB BALANCE.RPT TASK RUN DAILY ENDJOB
In the above example, BALANCE.RPT represents a manual task and must be marked complete.
375
Example 4

APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB3 EXTERNAL RUN DAILY REL PAYJOB4 JOB PAYJOB4.%ESPSDAY(1:3) DUEOUT EXEC 9PM RUN DAILY ENDJOB
In the above example: 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.
Example 5

APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB5 RUN DAILY REL (PAYJOB6(A)) JOB PAYJOB6 CONDITIONAL RUN DAILY ENDJOB
In the above example, PAYJOB6 is defined as a conditional job that is submitted only if PAYJOB5 terminates abnormally.
376
Example 6

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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.
Example 7

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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) Continued on next page
377
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
378
JOBATTR Statement
Overview
The JOBATTR statement is used to change a jobs attributes within the scope of a JOB statement or in job documentation.
Type
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)]
Parameter attributes
Description 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.
379
JOBATTR Statement, Continued
Related information
For information on identifying the names of jobs in an Application, see the JOB statement. For information on Applications, see the ESP Workload Manager Users Guide.
Example 1
The following JOBATTR statement changes a jobs attributes:

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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.
Example 2

APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB2 IF TODAY(FRIDAY) THEN JOBATTR HOLD IF TODAY(LAST WORKDAY OF MONTH) THEN JOBATTR REQUEST RUN DAILY ENDJOB
In the above example: 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.
380
JOBATTR Statement, Continued
Example 3

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL 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.
381
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.
Type
General command.
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]
Parameter jobname jobid abid
AFTER CCFAIL COREQ
Description Indicates the name of the job for which you want to display information (i.e. PDS member name). Indicates the JES jobid of the job for which you want to display information. Displays information concerning the specified ABEND code(s). If ABENDS is specified without Parameters, all possible ABEND codes for the job are displayed. Displays names of jobs that are predecessors to this job, and release this job for processing. Displays condition codes that should cause a job to fail. Displays names of other jobs that are automatically selected and can run concurrently with this job.
382
JOBINFO Command, Continued
Syntax (continued) Parameter DATASET DJCDATA DUEOUT FUNCTION HISTFILE INPUTDS MEMBER Description Displays the JCL library used for the job. Displays ESP/DJC net control statements for this job. Displays due out times from P-Nodes. Indicates the function of the job. Displays the name of the history-recording file for the job. Displays the tape data sets required for the job. Indicates the member name in which ESP finds the jobs execution JCL. The default is member name equal to jobname. Displays information concerning all specified message ID(s). If MESSAGES is specified without parameters, all possible messages for the job are displayed. Displays the name of the tracking model for the job. Displays a string of operator data (e.g. a title). Displays names of the P-Nodes specified for the job. Displays the names of jobs that are automatically selected and executed following execution of this job. Displays the names of jobs that are automatically selected and executed before execution of this job. Displays the programmer name. Displays the names of jobs that are successors to this job, and which this job releases for processing. Displays information contained in user-defined fields. Up to 50 fields can be requested separated by a comma. Displays all job documentation information for this job. This is the default.
msgid
MODEL OPERDATA PNODES POSTREQ PREREQ PROGRAMMER RELEASE field ALL
383
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 Consolidated Status Facility Page mode or line mode Command BD or ED JOBINFO Retrieved from Library specified in the ESP Application. DOCLIB in ESP Application or JOBDOC DD allocated to your TSO session JOBDOC DD allocated to the ESP started task. JOBDOC DD allocated to the ESP started task.
Page mode or line mode Operator console
OPER JOBINFO F ESP,JOBINFO
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.
384
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.
Example 3

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

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.
385
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.
Type
Reporting command.
Syntax
The syntax of the JOBMAP command is:

JOBMAP DSN(dsname) [APPL(appl_id)] [JOBINDEX] [APPLINDEX] [RESINDEX] [NODISPLAY(list)]
Parameter DSN(dsname) APPL(appl_id)
JOBINDEX APPLINDEX RESINDEX NODISPLAY(list)
Description Indicates the name of the map data set created by the MAPGEN command. 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. Produces an index of jobs after the job information pages. Produces an index of Application after the job information pages. Produces an index of resources after the job information pages. 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.
386
JOBMAP Command, Continued
Suppressed fields
The NODISPLAY parameter lists fields that are not to be displayed, as follows:
Value EVENT CALENDAR JCLDS SCOPE CLASS PGMER TAPES ELAPSED CPU HOLDCOUNT PRED SUCC RESOURCE PROC TAG
Information Suppressed Event name Calendar name(s) JCL data set and member name 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
387
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.
388
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 -------PAYJOB1 APPL NAME --------APPL1 TYPE ---JOB SCHEDULING ------------SCHEDULED: QUALIFIER: EVENT: CALENDAR(S): JCL: SCOPE: CLASS: PROGRAMMER: TAPES:
DAILY CYBER.PAYROLL SYSTEM CYBER.JCL(PAYJOB1) FRED REEL DRIVES: REEL MOUNTS: CART DRIVES: CART MOUNTS: 0H 0M 0S
0 0 0 0
ELAPSED:
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.
389
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 -------PAYJOB1 PAYJOB2 PAYJOB3 APPL NAME --------PAYROLL PAYROLL PAYROLL PAGE ---1 2 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 --------PAYROLL JOB NAME -------PAYJOB1 PAYJOB2 PAYJOB3 PAGE ---1 2 2
END OF LIST
390
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.
Type
General command.
Syntax
The syntax of the JOBRES command is:

JOBRES JOB(name.qual) APPLICATION(name.gen) RESOURCE(n1,res1,n2,res2,)
Parameter name name.gen n1,res1
Description Indicates the name of the job that requires resource modifications. Indicates the name and generation number of the Application in which the job resides. 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)
391
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.
Type
Reporting command.
Syntax
The syntax of the JOBTREE command is:

JOBTREE DSN(dsname) JOB(job_id) [APPL(appl_id)]
Parameter DSN(dsname) JOB(job_id) APPL(appl_id)
Description Indicates a fully qualified data set name of the map data set created by the MAPGEN command. Indicates the name of the job for which the information is produced. 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.
392
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.
Example 2

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.
Example 3

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.
Example 4

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.
393
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.
Type
General command
Authority
OPER authority is required to issue the JTPEXCL command.
Syntax
The syntax of the JTPEXCL command is:

JTPEXCL [pgmname] (pgmname[,pgmname]...)] [ADD|DELETE]
Parameter pgmname ADD DELETE
Description Indicates a valid program name. Indicates new information is to be added to the specification for program exclusion. This is the default. 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 Manager Installation Guide.
Example 1
The following JTPEXCL command displays excluded programs:

JTPEXCL
In the above example, all excluded programs are displayed.

394
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.
395
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
Parameter labelname
Description Indicates a valid label name consisting of up to 16 alphanumeric characters.
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 ESP Workload Manager Users Guide.
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: SELECT (PAYJOB1,PAYJOB2)
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.
396
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.
397
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.
398
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.
Type
General command.
Syntax
The syntax of the LABEL command is:

LABEL source_string target_string {BEFORE} {AFTER} {REPLACE} {OVERLAY} {INLINE} {ANY}
Parameter source_string
target_string
BEFORE AFTER REPLACE OVERLAY
INLINE
ANY
Description 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. 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. Indicates the target string is placed on a line of its own just ahead of the line containing the source string. Indicates the target string is placed on a line of its own just after the line containing the source string. Indicates the line containing the source string is deleted and a line containing just the target string is inserted instead. 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. 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. 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.
399
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 For information on indicating that all specifications are complete and that the copy process should proceed, see the GO command. For information on job documentation, see the ESP Workload Manager Users 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.
Example 1
In the above example, ESP: 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 **. 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. Places the label RESTART: on its own line before any line starting with the string RESTART PROCEDURES. Proceeds with the copy process.
400
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.
Type
Syntax
The syntax of the LATESUB statement is:

LATESUB criteria
Parameter 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.
401
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.
402
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 COMMAND ===> SCR ===> PAGE 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
403
LAX Command
Overview
The LAX command is used to display external jobs in active Applications.
Type
General command.
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 Applications, see the ESP Workload Manager Users Guide. For information on posting external or manual jobs complete, see the APPL statement or the ESP Workload Manager Advanced Users Guide.
404
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 JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL 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.
405
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.
Type
General command.
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.
406
LDSN Command
Overview
The LDSN command is used to produce a display of the current system data sets allocated to ESP.
Type
General command.
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.
407
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.
Type
General command.
Syntax
The syntax of the LDTE command is:

LDTE
Related information
For information on data set triggering at the Event level, see the ESP Workload Manager Users Guide. For information on data set triggering at the job level, see the ESP Workload Manager Users Guide. 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.
408
LDTREL Command
Overview
The LDTREL command is used to display the entries from the Data set Trigger Exclude list.
Type
General command.
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.
409
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.
Type
General command.
Syntax
The syntax of the LDXE command is:

LDXE
Related information
For information on data set triggering at the Event level, see the ESP Workload Manager Users Guide. For information on data set triggering at the job level, see the ESP Workload Manager Users Guide. 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 PAYROLL.1 CYBER.CYCLES (WOB)--------------DATASET (WAIT4.DS) CYBER.PAYROLL.DATA,ANYCLOSE USER.INPUT.CYCLE
In the above example, data sets that are checked for closures, creation or renames are displayed.
410
LIBSUB Command
Overview
The LIBSUB command is used to submit JCL from a Librarian data set to the internal reader.
Type
Syntax
The syntax of the LIBSUB command is:

LIBSUB dsname [(member)]
Parameter dsname
member
Description 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. 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.
411
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.
412
LIST Command
Overview
The LIST command is used to display Event information.
Type
General command.
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]
Parameter groupprefix levelname
ALL
SYSTEM classname TIMESEQ
eventid dsname
MOD
Description Indicates the current group prefix. 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. 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. Indicates the ID of the ESP system that is to execute the Event is included in the display. Indicates the display is restricted to Events with the specified class name. Indicates the Event names are to be displayed in execution time sequence order rather than alphanumeric collating sequence. Indicates the name of a specific Event to be displayed. 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 Indicates the data set receiving output is appended to.
413
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 Events, see the ESP Workload Manager Users Guide. 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.
414
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.
415
LISTAPPL Command
Overview
The LISTAPPL command is used to display Application information. The short form of this command name is LAP.
Type
General command.
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]
Parameter applname
Description 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. 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. Displays all incomplete Applications. This is the default if not specified. Displays information about each job. This includes successor and predecessor information for each job, as well as resource information. 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.
COMPLETE
INCOMPLETE ALL
JOBS
416
LISTAPPL Command, Continued
Syntax (continued) Parameter PREDECESSORS Description Displays the names of any predecessors for each complete job. The PREDECESSORS parameter is used in conjunction with the ALL parameter. Displays the names of any successors for each complete job. The SUCCESSORS parameter is used in conjunction with the ALL parameter. Displays all jobs on the critical path if critical path analysis is turned on. Displays all jobs not on the critical path if critical path analysis is turned on. Displays in a structured view each job or qualified job you have specified. Displays the status of each Application, without detailing the jobnames. Display is limited to the subApplication specified. Requests a display of the oldest incomplete generation of an Application. Displays in hexadecimal format Application record information for problem diagnosis.
SUCCESSORS
CRITPATH NOTCRITPATH JOB(jobname) STATUS SUBAPPL OLDEST DUMP
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.
417
Related information
For information on displaying active Applications from the CSF, see the ESP Workload Manager Users Guide. For information on manipulation jobs in active Applications, see the APPLJOB or AJ command. For information on critical path analysis, see the ESP Workload Manager Users 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.
418
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, PREDECESSORS: (NONE) SUCCESSORS: PAYJOB2, PAYJOB3 PAYJOB2, HC=1 ANTICIPATED END TIME: 21.00 ON WEDNESDAY JANUARY 28TH, PREDECESSORS: PAYJOB1 SUCCESSORS: PAYJOB4 PAYJOB3, HC=1 ANTICIPATED END TIME: 21.00 ON WEDNESDAY JANUARY 28TH, PREDECESSORS: PAYJOB1 SUCCESSORS: PAYJOB4 PAYJOB4, HC=2 ANTICIPATED END TIME: 21.00 ON WEDNESDAY JANUARY 28TH, PREDECESSORS: PAYJOB2, PAYJOB3 SUCCESSORS: (NONE)
1998
1998
1998
1998
419
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 ANTICIPATED END TIME: 21.00 ON WEDNESDAY JANUARY 28TH, - CRITICAL PATH PREDECESSORS: (NONE) SUCCESSORS: PAYJOB2, PAYJOB3 PAYJOB2, HC=1 ANTICIPATED END TIME: 21.00 ON WEDNESDAY JANUARY 28TH, PREDECESSORS: PAYJOB1 SUCCESSORS: PAYJOB4 PAYJOB3, HC=1 ANTICIPATED END TIME: 21.00 ON WEDNESDAY JANUARY 28TH, - CRITICAL PATH PREDECESSORS: PAYJOB1 SUCCESSORS: PAYJOB4 PAYJOB4, HC=2 ANTICIPATED END TIME: 21.00 ON WEDNESDAY JANUARY 28TH, - CRITICAL PREDECESSORS: PAYJOB2, PAYJOB3 SUCCESSORS: (NONE)
1998
1998
1998
1998
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.
420
LISTAPTF Command
Overview
The LISTAPTF command is used to display information on the current status of the Application file.
Type
General command.
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
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.
421
LISTAT Command
Overview
The LISTAT command is used to display the contents of an authorization table.
Type
General command.
Syntax
The syntax of the LISTAT command is:

LISTAT tabname [DECOMPILE]
Parameter tabname
DECOMPILE
Description 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. 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-,ACOEXCLUDE: -,AC02
In the above example, the contents of an authorization table are displayed.

422
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.
423
LISTCAL Command
Overview
The LISTCAL command is used to display information about a calendar.
Type
General command.
Syntax
The syntax of the LISTCAL command is:

{LISTCAL|LCAL} calname
Parameter calname
Description 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
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 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.
424
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.
425
LISTCKPT Command
Overview
The LISTCKPT command is used to display statistics on the Checkpoint data set.
Type
General command.
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
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.
426
LISTEVS Command
Overview
The LISTEVS command is used to display the status of any or all of the Event data set.
Type
General command.
Authority
OPER authority is required to issue the LISTEVS command.
Syntax
The syntax of the LISTEVES command is:

LISTEVS [eventdb]
Parameter eventdb
Description 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
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

427
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.
428
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.
Type
General command.
Syntax
The syntax of the LISTGRP command is:

{LISTGRP|LG} [groupname]
Parameter groupname
Description 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. For information on defining groups, see the ESP Workload Manager Administrators Guide. For information on the System Authorization Facility (SAF), see the ESP Workload Manager Administrators Guide.
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.
429
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.
430
LISTHIST Command
Overview
The LISTHIST command is used to display the status of any or all of the history files.
Type
General command.
Authority
OPER authority is required to issue the LISTHIST command.
Syntax
The syntax of the LISTHIST command is:

LISTHIST [histfid]
Parameter histfid
Description 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
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.
431
LISTHOL Command
Overview
The LISTHOL command is used to list previously defined holidays.
Type
General command.
Syntax
The syntax of the LISTHOL command is:

{LISTHOL|LH} name [GROUP(groupname)] [CALENDAR(calname)] [FROM(fromdate)] [TO(todate)]
Parameter name
groupname calname fromdate
todate
Description 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. Indicates holidays from the default calendars of the specified group are displayed. Indicates the name of the calendar to be searched. This parameter is mutually exclusive with the GROUP parameter. 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. 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.
432
LISTHOL Command, Continued
Related information
For information on defining and deleting holidays, see the DEFHOL and DELHOL 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 VICTORIA_DAY 00.00 ON MON 18TH MAY 98 MEMORIAL_DAY 00.00 ON MON 25TH MAY 98 XMAS 00.00 ON FRI 25TH DEC 98 ---- 5 HOLIDAYS DISPLAYED ---JAN 98 TO MAY 98 TO MAY 98 TO DEC 98 TO 00.00 ON FRI 2ND
00.00 ON TUE 19TH 00.00 ON TUE 26TH 00.00 ON SAT 26TH
In the above example, holidays defined on the SYSTEM calendar are displayed.
433
LISTJTML Command
Overview
The LISTJTML command is used to list internal tracking model data.
Type
General command.
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
For information on displaying the definition of tracking models, see the LTM 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.
434
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.
Type
General command.
Syntax
The syntax of the LISTPN command is:

{LISTPN|LPN} name
Parameter name
Description 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
For information on defining and deleting manual P-Nodes, see the DEFPN and DELPN commands. For information on defining processing nodes (P-Nodes), see the ESP Workload Manager Advanced Users Guide.
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 CYBBS01 HISTFILE P-NODE CYBBP01 HISTFILE P-NODE CYBBP01 HISTFILE P-NODE CYBBP01 HISTFILE DISTRIB DEFINED AT 10.23 ON WED 28JAN98 BY
- NONE, OWNER(CYBBS01), SEQUENCE(140) EXEC DEFINED AT 15.47 ON MON 24NOV97 BY - NONE, OWNER(CYBBP01), SEQUENCE(120) INPUT DEFINED AT 15.47 ON MON 24NOV97 BY - NONE, OWNER(CYBBP01), SEQUENCE(110) OUTPUT DEFINED AT 15.47 ON MON 24NOV97 BY - NONE, OWNER(CYBBP01), SEQUENCE(130)
435
LISTQ Command
Overview
The LISTQ command is used to display information about the current status of the QUEUE data set.
Type
General command.
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 FORMATTED AT 12.33.25 ON MONDAY NOVEMBER 17TH, 1997 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.
436
LISTSADL Command
Overview
The LISTSADL command is used to display the current SADLINKs defined.
Type
General command.
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.
437
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.
Type
General command.
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]
Parameter starttime
endtime
levelname count
eventdsid class OVERDUE SUSPENDED
Description Indicates a valid start time. This may include a date. If the specification includes blanks or commas, place it within quotes. Indicates the end time and can include a date. If the specification includes blanks or commas, place it within quotes. Indicates a generic Event name specification. It may contain asterisks and hyphens. 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. Indicates the identifier of an Event data set whose deferred queue is to be displayed. Indicates the name of a held class. Indicates entries from the OVERDUE queue are displayed. Indicates all suspended Events are displayed.
438
LISTSCH Command, Continued
Syntax (continued) Parameter DATE FLUSHED Description Indicates the date is included in the display as well as the time. 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. Indicates scheduled Events, as well as Events that are expected to execute (EXPECT command) are displayed.
NONSCHED
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 Events, see the ESP Workload Manager Users Guide. 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.
439
LISTSCH Command, Continued
Example 1
The following is a sample of the display produced by the LISTSCH command:

LISTSCH 15.00.00 15.30.00 17.45.00 20.00.00 PROD.PAYROLL PROD.CLAIMS CYBER.LIFE70 CYBBS01.FRED 15.00.00 16.00.00 19.15.00 06.00.00 PROD.BILLING USER01.TEST TEST.INVENTORY 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.
440
LISTSIG Command
Overview
The LISTSIG command is used to display all generations of a signal.
Type
General command.
Syntax
The syntax of the LISTSIG command is:

{LISTSIG|LSIG} signalname [ALL] [PENDING]
ALL
PENDING
Description 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. 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. Display only signals with pending Events.
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 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 Workload Manager Users Guide. For information on defining and deleting signals, see the DEFSIG and DELSIG 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.
441
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.
442
LISTSPEC Command
Overview
The LISTSPEC command is used to list special days and periods.
Type
General command.
Syntax
The syntax of the LISTSPEC command is:

{LISTSPEC|LS} name [GROUP(groupname)] [CALENDAR(calname)] [FROM(fromdate)] [TO(todate)] [COMPRESS] [RETAIN]
Parameter name
groupname calname fromdate
todate
COMPRESS
RETAIN
Description 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. Indicates special days/periods from the default calendars of the specified group are displayed. Indicates the name of the calendar to search. This parameter is mutually exclusive with the GROUP parameter. Indicates a start date for the special days displayed. Only special days/periods that fall on or after this date are displayed. Indicates an ending date for the special days/periods displayed. Only special days/periods on or before this date are displayed. 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 Indicates the display include the length of time the special day/period is retained (if retained).
443
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 ESP Workload Manager Users Guide. 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.
444
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 00.00 ON FRIDAY FEBRUARY 20TH, 1998 00.00 ON FRIDAY FEBRUARY 27TH, 1998 ---- 3 DATES LISTED ------- 3 SPECIAL DAYS DISPLAYED ----
In the above example, special days and periods defined on the SYSTEM calendar are displayed.
445
LISTSYML Command
Overview
The LISTSYML command is used to display information on the symbol libraries to which you have access.
Type
General command.
Syntax
The syntax of the LISTSYML command is:

{LISTSYML|LSL} symlib
Parameter symlib
Description 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
For information on setting symbol libraries, see the ESP Workload Manager Users Guide. For information on invoking user symbolic variables, see the ESP Workload Manager Advanced Users 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.
446
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.
447
LISTTRAK Command
Overview
The LISTTRAK command is used to display information about the current status of the job tracking file
Type
General command.
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 FORMATTED AT 17.33.37 ON MONDAY NOVEMBER 17TH, 1997 9896 SLOTS TOTAL, 8127 AVAILABLE, NEXT IS 6979
The above example displays information about the current status of the job tracking file.
448
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.
Type
General command.
Syntax
The syntax of the LISTUSER command is:

{LISTUSER|LU} userid
Parameter userid
Description 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 Administrators Guide. For more information on departments, see the ESP Workload Manager Administrators Guide. 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. For information on changing a users definition, see the ALTUSER command.
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.

449
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.
450
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.
Type
General command.
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.
451
LJ Command
Overview
The LJ command is used to display the status of a job being tracked by ESP.
Type
General command.
Syntax
The syntax of the LJ command is:

LJ jobname [ANCESTOR(genno)] [ALL] [STEPS] [SUBMIT] [PNODE] [STATUS] [DUEOUT] [INFODATA] [EXTENDED|X]
Parameter jobname
genno
ALL
STEPS SUBMIT
PNODE STATUS DUEOUT INFODATA
EXTENDED or X
Description 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. 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. Indicates all the information for the job is displayed. This is the same as specifying STEPS, SUBMIT, PNODE, and INFODATA. This is the default. Indicates step statistics are to be displayed for the job. 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. Displays the PNODE(s) for each job. Displays the current status of the job. Displays P-Node due out times for the job. Displays the Information Management record number associated with this job if one was generated using the Information Management interface. Displays more detailed date and time information.
452
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 Workload Manager Users Guide. 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.
453
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-SUNITSREGIONCMPC S1 IEFBR14 0 0 0 0 0:00.02 168 0 PNODE----OUT------DATE--QTIME-POST_BY--SYSINPUT 16.01.02 28JAN 0 SYSA EXEC 16.01.03 28JAN 1 SYSTEM SYSA OUTPUT * 10M54
4K
In the above example, detailed date and time information is displayed for PAYJOB4 using the EXTENDED or X parameter of the LJ command.
454
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.
Type
General command.
Syntax
The syntax of the LOAD command is:

LOAD 'dsname'
Parameter dsname
Description 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.
455
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 1998 PROD.BILLING 1998 NEXT DUE AT 20.00.00 ON THU JAN 29TH, NEXT DUE AT 09.00.00 ON THU JAN 29TH,
456
LOADAGDF Command
Overview
The LOADAGDF command is used to load the Agent definition file.
Type
General command
Authority
OPER authority is required to issue the LOADAGDF command.
Syntax
The syntax of the LOADAGDF command is:

LOADAGDF dsname
Parameter dsname TEST
Description Indicates a sequential data set or a member of a partitioned data set, enclosed in quotes. 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.
457
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.
Type
General command.
Authority
OPER authority is required to issue the LOADJTDT command.
Syntax
The syntax of the LOADJTDT command is:

LOADJTDT dsname
Parameter dsname
Description 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 job tracking definition tables, see the ESP Workload Manager Administrators Guide. For information on tracking definition entries in a job tracking definition table, see the TRACKDEF statement. For information on defining wildcard characters used in a job tracking definition table, see the WILDCARD statement.
458
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.
459
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.
Type
General command
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 the CSF, see the ESP Workload Manager Users Guide. 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.
460
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.
Type
General command.
Authority
OPER authority is required to issue the LOADUPDT command.
Syntax
The syntax of the LOADUPDT command is:

LOADUPDT dsname
Parameter dsname
Description 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.
461
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.
Type
General command.
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)]
Parameter dsname
schedule
Description Indicates the name(s) of the trace data set(s) to access for Event log information. Separate data set names with a comma. 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.
462
LSAR Command
Overview
The LSAR command is used to extract data from a scheduled activity data set to produce a standard scheduled activity report.
Type
General command.
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]
Parameter dsname
Description 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. 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. 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. Indicates the identifier for an ESP/DJC or JES3 job network. The use of asterisks and a hyphen for masking is permitted. 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. 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.
jobname
groupname
netid application
jcldsn
463
LSAR Command, Continued
Syntax (continued) Parameter schedule Description 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. 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. 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. 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. 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.
TIMESEQ
STATUS
tapeds
PROJECTED
464
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
For information on scheduled activity reporting, see the ESP Workload Manager 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)' //STEPLIB DD DSN=CYB2.ESP510Q.SSCPLINK,DISP=SHR //SYSPRINT DD SYSOUT=* //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.
465
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.
Example 3

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.
Example 4

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.
Example 6

LSAR DSN(CYBER.SAD) APPL(PAYROLL)
In the above example, a status display on scheduled activity information for the PAYROLL Application is produced.
466
Example 7

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.
467
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.
Type
General command.
Authority
OPER authority is required to issue the LSYS command.
Syntax
The syntax of the LSYS command is:

LSYS [sysid]
Parameter sysid
Description 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
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

468
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
469
LSYSMSGS Command
Overview
The LSYSMSGS command displays information on all the system messages that are currently being intercepted by ESP.
Type
General command.
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.
470
LTCELL Command
Overview
The LTCELL command is used to display tracking cell (TCELL) information, including the size and current usage of each cell.
Type
General command.
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
471
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.
Type
General command
Syntax
The syntax of the LTJ command is:

LTJ jobname [PREFIX] [OWNER(ownerid)] [MODEL(modelname)] [INDEX]
Parameter jobname
PREFIX
ownerid
modelname
INDEX
Description 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. Indicates the prefix entries are displayed rather than job definitions. This is not applicable if you are using job tracking definition tables. 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. 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. 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 Workload Manager Users Guide. For information on displaying the status of a job being tracked by ESP, see the LJ command.
472
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 J08719 J08717 J08673 J08630 J08474 J08414 J08408 J08365 J08364 ON ON ON ON ON ON ON ON ON ON RDR RDR RDR RDR RDR RDR RDR RDR RDR RDR AT AT AT AT AT AT AT AT AT AT 20.00 20.00 20.00 18.00 16.01 08.00 20.00 20.00 18.00 18.00 THU THU THU THU THU THU WED WED WED WED 29JAN98, 29JAN98, 29JAN98, 29JAN98, 29JAN98, 29JAN98, 28JAN98, 28JAN98, 28JAN98, 28JAN98, ENDED, ENDED, ENDED, ENDED, ENDED, ENDED, ENDED, ENDED, ENDED, ENDED, CC CC CC CC CC CC CC CC CC CC 0, 0.0 MINS_EXEC, 0:00 CPU 0, 0.0 MINS_EXEC, 0:00 CPU 0, 0.0 MINS_EXEC, 0:00 CPU 0, 0.0 MINS_EXEC, 0:00 CPU S806, 0.0 MINS_EXEC, 0:00 CPU 0, 0.0 MINS_EXEC, 0:00 CPU 0, 0.0 MINS_EXEC, 0:00 CPU 0, 0.0 MINS_EXEC, 0:00 CPU 0, 0.0 MINS_EXEC, 0:00 CPU 0, 0.0 MINS_EXEC, 0:00 CPU
In the above example, a display of the index for PAYJOB1 is generated.
473
LTM Command
Overview
The LTM command is used to display the definition of one or more tracking models.
Type
General command.
Syntax
The syntax of the LTM command is:

LTM name
Parameter name
Description 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. For information on job tracking definition tables, see the ESP Workload Manager Administrators Guide.
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.
474
LTZONE Command
Overview
The LTZONE command is used to display the current time zone settings.
Type
General command.
Syntax
The syntax of the LTZONE command is:

LTZONE
Related information
For information on defining ESP data sets, see the ESP Workload Manager 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 0 LOCAL 5.00W 3 Z 0.00E 7 MST 7.00W 10 EDT 4.00W 13 PDT 7.00W 17 CENTRAL 6.00W 20 ATLANTIC 4.00W ! CODE--ZONE------OFFSET ! CODE--ZONE------OFFSET ! 1 UTC 0.00E ! 2 GMT 0.00E ! 5 EST 5.00W ! 6 CST 6.00W ! 8 PST 8.00W ! 9 AST 4.00W ! 11 CDT 5.00W ! 12 MDT 6.00W ! 14 ADT 3.00W ! 16 EASTERN 5.00W ! 18 MOUNTAIN 7.00W ! 19 PACIFIC 8.00W ! 21 NFNDLAND 3.30W
In the above example, the current time zone settings are displayed
475
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.
Type
Reporting command.
Syntax
The syntax of the MAPGEN command is:

MAPGEN DATASET(dsname)EVENT(name)
Parameter DATASET(dsname)
Description 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 Indicates an Event descriptive name (without the prefix) and may contain wildcards. Does not work with the Event owner as the descriptive name.
EVENT(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.
476
MAPGEN Command, Continued
Example 1
The following is an example of a batch job to create a job mapping data set:
//jobname JOB ... //STEP1 EXEC PGM=IEFBR14 //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)
477
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.
Type
General command.
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)
Parameter user
central manager userid agentname
Description 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. Indicates the SAF user ID the user/agentname combination should map to. 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.
478
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)]
Parameter initnum servernum
Description Indicates the maximum number of initiators available on all CPUs. Up to 999 initiators may be specified. 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.
479
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)
In the above example: 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.
480
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.
Type
Syntax
The syntax of the MEMBER statement is:

MEMBER membername
Parameter membername
Description 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. For information on specifying an optional JCL library for an individual job, see the DATASET statement.
Example 1
The following MEMBER statement specifies the member name where ESP finds a jobs execution JCL
APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB1 MEMBER PAYJOB99 RUN WORKDAYS ENDJOB
In the above example, ESP submits PAYJOB1s execution JCL from member PAYJOB99.
481
MEMBER Statement, Continued
Example 2
The following JCLLIB, MEMBER and DATASET statements are used to specify different JCL libraries and members:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB2 RUN DAILY REL PAYJOB3 MEMBER PAYJOB99 JOB PAYJOB3 RUN DAILY DATASET CYBER.ALTJCL.CNTL ENDJOB
In the above example: 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 JCLLIB CYBER.JCL.CNTL JOB PAYJOB4 RUN DAILY REL PAYJOB5 MEMBER BACKUP JOB PAYJOB5 RUN DAILY REL PAYJOB6 DATASET CYBER.ALTJCL.CNTL JOB PAYJOB6 RUN DAILY DATASET CYBER.ALTJCL.CNTL MEMBER BACKUP ENDJOB
In the above example: 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.
482
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}
Parameter AGENT (agents) (port) DISPLAY
HELP LIST
Description Used to send notification to all Agents. Indicates the unique name of the Agent, as defined in the AGENTDEF file. You can specify the - wildcard suffix. Used to tell an Agent to which Agent receiver port number to connect. 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). Displays MGRADDR command options. 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.
483
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
484
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
Parameter date
time
to from re
Description 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. 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. Indicates the network address of the destination, as seen from the sender. Indicates the address of the sender. 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.
485
MGRMSG Command, Continued
Syntax continued Parameter verb Description 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. Indicates a modifier for the verb. If omitted, a period(.) should be used as a placeholder.
verbmodifier
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 ACTION Description Requests some action be applied to a workload object, such as Hold or Release. The verb modifier indicates the actual action. Indicates a change of state for the object. The new object state is supplied in the verb modifier field. Indicates a response is being made for a request sent to an agent. It does not indicate a change of state for the object.
STATE RESPONSE
ACTION verb modifiers
The following verb modifiers can be used with the ACTION verb:
Verb modifier BYPASS DROPDEP
DROPRES
HOLD
Description Turns on the BYPASS indicator for the object. 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. 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. Turns on the HOLD flag for the object.
486
ACTION verb modifiers continued Verb modifier INSERT Description Causes a new workload object to be inserted into the application. For a description of the variable keywords available, see below. Requests the object be immediately placed in the READY state. Any dependencies, hold states or delay submit times are dropped. Indicates the object can have the HOLD attribute removed. This may cause a change of state for the object. Turns on the REQUESTED indicator of an object. Requests one or more of the objects properties be modified. For a description of the variable keywords available, see below. Request the object be scheduled for re-execution. For a description of the variable keywords available, see below. Turns off the BYPASS indicator of an object. Turns off the REQUESTED indicator of an object. Removes the ancestor wait attribute of the object. Causes the Update_SCBE method of the object to be invoked. Variable data is object implementation defined.
READY
RELEASE REQUEST RESET RESUB UNBYPASS UNREQUEST UNWAIT UPDATESCBD
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.
487
INSERT and RESET actions continued Keyword Conditional Doclib() Docmem() Dsname() EarlySub() Espprocfile() External* Hold LateEnd() LateSub() Manual* Pred() Description Indicates this is a conditional job. Specifies the name of the library containing documentation for the object. Member name of documentation library entry. Submit data set name. Time before when object should not be readied. Specifies the name of the library containing the objects definition (ESP Procedure file) Indicates object refers to an object in another application. Requests the object be placed in a manual hold condition. Time/Date when an object should complete to avoid becoming overdue. Time/Date when an object should start to avoid becoming overdue. Indicates this object is a manually submitted MVS job. 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. Specifies the priority the workload object is to have. This is a number from 0 99. Indicates whether Event processing is required for tasks or links. Specifies a minimum delay time to be added to a job after its last dependency has been met. Indicates the object has the REQUEST attribute. In order to run, it has to be explicitly requested. 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. This indicates the scheduled time an external object must possess in order to match this object definition.
Priority() Process RelDelay() Request Resource()
Scheduled*()
488
INSERT and RESET actions continued Keyword Statements() Description 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) Specifies the name of the subappl to which the object belongs. 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. Specifies a tag for the object. Specifies the object type. This should be JOB, LINK, TASK or the long or short name of a workload object class.
Subappl*() Succ()
Tag() Type*()
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 From() Jobid() RestartParm() To() User1() User2() User3() User4() Description Restart point. Identifier of original job being restarted. Parameter string to be passed to the restart processor. Last processing step to be rerun. User restart variable 1. User restart variable 2. User restart variable 3. User restart variable 4.
489
STATE verb
The following verb modifiers can be used with the STATE verb: Verb modifier Active Description 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. 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. Specifies the completion code for the object. Indicates the FAILED condition should be set. Indicates intervention is required for the object. Sets the job number field of the object. Supplies a value for the MNPOINT variable for the execution of an Alert. Indicates the Activate subroutine of the APPL Manager should not be invoked for this state change. Resets the FAILED indicator for an object. Turns off the intervention required condition for an object. Indicates the Application tracking record should not be updated to disk as a result of this state change message. Requests the end time for the object be set from the timestamp of this message. Requests the start time of the object be set from the time field of this message. Specifies a system status string that should be attached to this object. Identifies a new tag field for this object.
Alert()
Cmpc() Failed Intvrq Jobno() MNPoint() NoActivate NoFailed NoIntvrq NoUpdateATR SetEnd SetStart Status() Tag()
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.
490
MODEL Statement
Overview
The MODEL statement is used to specify the name of the tracking model to be used for this job.
Type
Syntax
The syntax of the MODEL statement is:

MODEL modelname
Parameter modelname
Description 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
For information on displaying the definition of tracking models, see the LTM command. For information on defining and deleting a tracking model definition, see the DEFTM and DELTM commands. For information on tracking definition entries in a job tracking definition table, see the TRACKDEF statement. For information on using tracking models, see the ESP Workload Manager Administrators Guide. For information on job tracking definition tables, see the ESP Workload Manager Administrators Guide.
Example 1
The following MODEL statement specifies the name of the tracking model:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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.
491
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]
Parameter dsname schedule
NOCLASS
Description Indicates the data set name of scheduled activity data set, enclosed in quotes, to be used for MODEL processing. 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. 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.
492
MODEL Command, Continued
Related information
For information on ending the model process, see the ENDMODEL command. For information on how ESP processes workload in your environment, see the ESP Workload Manager Advanced Users Guide.
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.
493
MODEL Command, Continued
Example 4

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 RPT1 JR1 FROM('4PM TODAY ENDING 4PM TOMORROW) ENDMODEL ENDPRINT RPT1
In the above example: 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 process The ENDPRINT command creates a report.
494
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.
Type
Syntax
The syntax of the MONITOR statement is:

MONITOR groupname
Parameter groupname
Description 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.
495
MONITOR Statement, Continued
Example 1
The following MONITOR statement identifies a monitor group prefix:

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL MONITOR CYBER JOB PAYJOB2 REL PAYJOB3 JOB PAYJOB3 REL PAYJOB4 JOB PAYJOB4 ENDJOB SELECT (PAYJOB2,PAYJOB3,PAYJOB4)
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.
496
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]...)]
Parameter repname JR1 JR2 ER1 ER2 RR1 RR2 schedule
cpunumber
Description Indicates a one to eight alphanumeric character logical report name as defined by the DEFPRINT command. Generates a Scheduled Jobs Cross Reference report. Can also be specified as JOB_REPORT_1. Generates a Projected End Time report. Can also be specified as JOB_REPORT_2. Generates a Job Exception report. Can also be specified as EXCEPTION_REPORT_1. Generates a Dueout Exception report. Can also be specified as EXCEPTION_REPORT_2. Generates the Resource Utilization On Systems report. Can also be specified as RESOURCE_REPORT_1. Generates the Resource Utilization By Job report. Can also be specified as RESOURCE_REPORT_2. 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. 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.
497
MREPORT Command, Continued
Syntax (continued) Parameter jobname Description 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
For information on how ESP processes workload in your environment, see the ESP Workload Manager Advanced Users Guide.
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).
498
MREPORT Command, Continued
Example 3

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 RPT1 JR1 FROM('4PM TODAY ENDING 4PM TOMORROW) ENDMODEL ENDPRINT RPT1
In the above example: 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 process The ENDPRINT command creates a report.
499
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.
Type
General command.
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)]
Parameter id
id1:id2
codes
ROUTE DESC DELROUTE DELDESC TYPE
Description 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. 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. Indicates a number, range of numbers or list of numbers and ranges of numbers. Each number must be within the range 016. Indicates one or more routing codes are added when the message is issued. Indicates one or more descriptor codes are added when issuing the messages. Indicates one or more routing codes are deleted from those normally used for the message. Indicates one or more descriptor codes are deleted from those normally used for the message. Indicates the new message type: I informational message W warning message E error message S severe error message
500
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.
501
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]
Parameter n1 N2
LIST OFF
Description When specified on its own, this causes ESP to cancel an Event once it exceeds this number of messages. 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. Displays MSGLIMIT settings. 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.
502
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.
503
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.
Type
General command.
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)]
Parameter INFO WARNING ERROR SEVERE codes
ROUTE DESC DELROUTE DELDESC
Description Indicates an informational message. Indicates a warning message. Indicates an error message. Indicates a severe error message. Indicates a number, range of numbers or list of numbers and ranges of numbers. Each number must be within the range 016. Indicates one or more routing codes are added when the message is issued. Indicates one or more descriptor codes are added when issuing the messages. Indicates one or more routing codes are deleted from those normally used for the message. Indicates one or more descriptor codes are deleted from those normally used for the message.
504
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.
505
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.
506
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.
Type
General command.
Syntax
The syntax of the NEXT command is:

NEXT [count] eventid
Parameter count eventid
Description Indicates a number from 1 to 99, specifying the number of execution times you want to be displayed. The default is 1. 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 SCHED AT 21.00.00 ON SCHED AT 21.00.00 ON SCHED AT 21.00.00 ON SCHED AT 21.00.00 ON MONDAY FEBRUARY 2ND, 1999 TUESDAY FEBRUARY 3RD, 1999 WEDNESDAY FEBRUARY 4TH, 1999 THURSDAY FEBRUARY 5TH, 1999 FRIDAY FEBRUARY 6TH, 1999
In the above example, the next 5 executions of CYBER.PAYROLL are displayed.

507
NEXT Command, Continued
Example 2

ESP2494W NEXT PROCESSING ENDED AFTER 200 SUSPENDED SCHEDULES NEXT 10 CYBER.PAYROLL SCHED AT 17.00.00 ON WEDNESDAY FEBRUARY 18TH, 1998 SCHED AT 17.00.00 ON THURSDAY FEBRUARY 19TH, 1998 SCHED AT 17.00.00 ON FRIDAY FEBRUARY 20TH, 1998 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 22nd, 1998, with no scheduled resume.
Example 3

NEXT 5 CYBER.PAYROLL SCHED AT 17.00.00 ON SCHED AT 17.00.00 ON SCHED AT 17.00.00 ON SCHED AT 17.00.00 ON SCHED AT 17.00.00 ON WEDNESDAY FEBRUARY 18TH, 1998 THURSDAY FEBRUARY 19TH, 1998 FRIDAY FEBRUARY 20TH, 1998 SATURDAY FEBRUARY 21ST, 1998 HOLD(1) SUNDAY FEBRUARY 22ND, 1998
In the above example, the Event is held at the time of execution and release prior to the next execution.
508
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.
Type
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.
509
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.
Type
General command.
Syntax
The syntax of the NODE parameter is:

NODE name [ADD|DEL|LIST|SET] [ROUTEJCL('/* XEQ nnn')] [ACTIVE|INACTIVE]
Operand name
Description 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. Indicates this is a new definition. Deletes one or more existing definitions. Displays list of one or more existing definitions. This is the default. Modifies attributes of existing definitions. Indicates a JCL image that, when inserted into a jobs JCL, causes the job to be routed to the appropriate CPU or node. Indicates a node be considered active. This is the default. Indicates a node be considered inactive. ESP will not attempt to schedule a job to that node or CPU while it is inactive.
ADD DEL LIST SET ROUTEJCL ACTIVE 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, NODE, and RESFILE parameters in the ESP Workload Manager Installation Guide. You also need to define CPU after defining NODE. It is recommended that you use the CPU and NODE names that JES knows.
510
NODE Command, Continued
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 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.
511
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.
Type
Syntax
The syntax of the NORUN statement is:

NORUN criteria
Parameter 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 Applications, see the ESP Workload Manager Users Guide. 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.
512
NORUN Statement, Continued
Example 1
The following NORUN identifies an exception to a jobs schedule criteria:

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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.
Example 2

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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.
Example 3

APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB3 NORUN WEDNESDAY ENDJOB
In the above PAYJOB3 is scheduled for submission every time the Event invoking this Application executes, except on Wednesdays.
513
NORUN Statement, Continued
Example 4

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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.
Example 5

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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 3rd, 13th and the 23rd day of each month:
NORUN 3RD 13TH 23RD DAY OF MONTH
Indicates that a job is not selected for submission on the 1st 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
514
NOSCHED Command
Overview
The NOSCHED command is used to specify when a scheduled Event should not execute.
Type
Syntax
The syntax of the NOSCHED command is:

NOSCHED criteria
Parameter 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
For information on specifying schedule criteria, see the ESP Workload Manager 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.
Example 1

EVENT ID(CYBER.PAYROLL) 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.
515
NOSCHED Command, Continued
Example 2

EVENT ID(CYBER.PAYJOB) SCHEDULE 5PM DAILY NOSCHED 5PM FEBRUARY 14, 1998 ONCE SUBMIT CYBER.JCL.CNTL(PAYJOB1) ENDDEF
In the above example, CYBER.PAYROLL is scheduled to execute every day at 5pm, except on February 14th, 1998.
516
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.
Type
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)]
Parameter SUBMIT JOBSTART OVERDUE ABEND FAILURE
JOBEND
RESUB userid name
rcode dcode
Description Indicates notification should take place at job submit time. Indicates notification should take place at job start time. Indicates notification should take place when a job becomes overdue from any processing node. Indicates notification should take place when a job ABENDs. This excludes condition code failures. Indicates notification should take place when a job fails. This includes condition codes failures caused by either the CCCHK or CCFAIL statements. 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. Indicates notification should take place when a job resubmitted through ESP ends. Indicates up to three TSO user IDs to receive notification. 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. Indicates route code value between 1 and 128 to receive notification. Separate each route code with a comma. Indicates descriptor code value between 1 and 16 to receive notification. Separate each descriptor code with a comma.
517
NOTIFY Statement, Continued
Syntax (continued) Parameter Description 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.
518
Example 1
The following NOTIFY statement notifies users when each job within the Application starts:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL NOTIFY JOBSTART USERS(CYB01,CYB02) JOB PAYJOB1 REL PAYJOB2 JOB PAYJOB2 REL PAYJOB3 JOB PAYJOB3 ENDJOB SELECT (PAYJOB1,PAYJOB2,PAYJOB3)
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 JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL 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.
519
Example 4
The following NOTIFY statement triggers an Event associated with an alert identifier:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL NOTIFY ABEND ALERT(INFO) JOB PAYJOB7 REL PAYJOB8 JOB PAYJOB8 ENDJOB SELECT (PAYJOB7,PAYJOB8)
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 JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL 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.
520
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 JCLLIB CYBER.JCL.CNTL 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.
521
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.
Type
Syntax
The syntax of the ON command is:

ON type {ADVANCE} {DELAY} {IGNORE} [n DAYS] [n WEEKDAYS]
Parameter type
Description 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. Indicates the Event is to be advanced (i.e. run earlier) by a specified number of days or weekdays. Indicates the Event is to be delayed (i.e. run later) by a specified number of days or weekdays. Specifies if the Event falls on one of the specified days, it is to be bypassed. Indicates the number of days or weekdays the Event is to be advanced or delayed. Indicates n equals the number of days for the schedule to be advanced or delayed. This includes Saturdays and Sundays. Indicates n equals the number of weekdays for the schedule to be advanced or delayed. This excludes Saturdays and Sundays.
ADVANCE DELAY IGNORE n DAYS WEEKDAYS
522
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 Manager Users Guide. For information on scheduling criteria see, Schedule Criteria in the ESP Workload Manager Users Guide. 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:
EVENT ID(CYBER.PAYROLL) SCHEDULE MONDAY AT 6AM EVERY 14 DAYS ON HOLIDAY DELAY 1 DAY INVOKE CYBER.PROCLIB.CNTL(PAYROLL) 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.
523
ON Command, Continued
Example 2
The following is an example of a scheduled Event definition that advances the Event execution on holidays:
EVENT ID(CYBER.PAYROLL) SCHEDULE 4PM 15TH DAY OF MONTH ON HOLIDAY ADVANCE 1 DAY INVOKE CYBER.PROCLIB.CNTL(PAYROLL) ENDDEF
In the above example, CYBER.PAYROLL is schedule at 4 pm on the 15th 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 execution on holidays:
EVENT ID(CYBER.PAYROLL) SCHEDULE FIRST DAY OF THE MONTH ON HOLIDAY IGNORE INVOKE CYBER.PROCLIB.CNTL(PAYROLL) ENDDEF
In the above example, CYBER.PAYROLL is scheduled on the first day of the month. On holidays the Event is bypassed.
Example 4
The following is an example of a scheduled Event definition that delays the Event execution on holidays:
EVENT ID(CYBER.PAYROLL) SCHEDULE 8AM FIRST DAY OF MONTH ON HOLIDAY DELAY 7 DAYS INVOKE CYBER.PROCLIB.CNTL(PAYROLL) 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.
Example 5
The following is an example of a scheduled Event definition that delays the Event execution on holidays:
EVENT ID(CYBER.PAYROLL) SCHEDULE 4PM 15TH DAY OF MONTH ON HOLIDAY DELAY 1 WEEKDAY INVOKE CYBER.PROCLIB.CNTL(PAYROLL) ENDDEF
In the above example, CYBER.PAYROLL is scheduled at 4 pm on the 15th day of the month. On holidays the Event is delayed 1 weekday.
524
OPTIONS Statement
Overview
The OPTIONS statement is used to override the default processing options for jobs belonging to Applications.
Type
Syntax
The syntax of the OPTIONS statement is:

OPTIONS [INHERIT|NOINHERIT] [GENNET|NOGENNET] [MANUALSUBMIT|NOMANUALSUBMIT| [TRACKMANUAL|NOTRACKMANUAL] [AUTOVARS|NOAUTOVARS] [RESTARTSTEP|NORESTARTSTEP]
Parameter INHERIT NOINHERIT GENNET
NOGENNET
MANUALSUBMIT NOMANUALSUBMIT TRACKMANUAL NOTRACKMANUAL AUTOVARS NOAUTOVARS RESTARTSTEP
NORESTARTSTEP
Description Indicates job relationships are inherited. This is the default. Indicates job relationships are not inherited. Indicates DJC/JES3 NET control cards are generated for jobs in a DJCNET. This is not applicable to ESP Applications. This is the default. 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. Indicates jobs are manually submitted. Indicates jobs will not be manually submitted. This is the default. Indicates jobs are tracked manually. Indicates jobs are not tracked manually. Indicates ESP allows the use of the automatic variable insertion feature. This is the default. Indicates ESP does not allow the use of the automatic variable insertion feature. Indicates a restart step is added to each job in an Application as identified by the ERMSTEP initialization parameter. Indicates a restart step is not added to each job in an Application. This is the default.
525
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 Applications, see the ESP Workload Manager Users Guide. For information on overriding inherited relationships, see the ESP Workload Manager Advanced Users Guide. For information on using the automatic variable insertion feature, see the ESP Workload Manager Advanced Users Guide. 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 JCLLIB CYBER.JCL.CNTL 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.
526
Example 2

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL 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.
527
Example 4

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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.
528
PANSUB Command
Overview
The PANSUB command is used to submit JCL from a Panvalet data set to the internal reader.
Type
Syntax
The syntax of the PANSUB command is:

PANSUB dsname[(member)] [MEMBER(member)]
Parameter dsname
member
Description 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. 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
For information on submitting JCL from an Event, see the ESP Workload Manager Users Guide.
Example 1
The following is an example of an Event definition that submits JCL from a PANVALET data set:
EVENT ID(CYBER.PANJOB1) SCHEDULE 9AM FIRST MONDAY OF MONTH PANSUB PANDS.DATA(PAYJOB1) ENDDEF
In the above example, PAYJOB1 is submitted from PANVALET data set PANDS.DATA.
529
PANSUB Command, Continued
Example 2
The following is an example of an Event definition that submits JCL from a 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.
530
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.
Type
General command.
Syntax
The syntax of the PASSWORD command is:

PASSWORD oldpswd newpswd
Parameter oldpswd newpswd
Description Indicates your current password. 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 Administrators Guide.
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.
531
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.
Type
Syntax
The syntax of the PNODES statement is:

PNODES {pnode} {(pnode[,pnode])}
Parameter pnode
Description 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.
532
PNODES Statement, Continued
Related information
For information on defining processing nodes (P-Nodes), see the ESP Workload Manager Advanced Users Guide. For information on defining and deleting manual P-Nodes, see the DEFPN and DELPN commands. 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 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 JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL 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.
533
PNODES Statement, Continued
Example 2
The following PNODES statement specifies two user-defined processing nodes:

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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..
534
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.
Type
General command.
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]
Parameter job|jobnumber
pnodename
FORCE PURGE
Description 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. 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. Indicates the job is posted as complete at a P-Node, even though it is not currently queued to that P-Node. 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 defining processing nodes (P-Nodes), see the ESP Workload Manager Advanced Users Guide. For information on displaying job on PNODE queues, see the DN command.
535
POST Command, Continued
Example 1
The following PNODES statement specifies a user defined processing node:

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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
536
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.
Type
Syntax
The syntax of the POSTREQ statement is:

POSTREQ {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]...})}
Parameter jobname
ADD DROP A
U N
Description Indicates a jobname in up to eight characters and may include a qualifier in up to eight characters. Enclose multiple job names in parentheses, separated by a blank or a comma. Indicates the specified job(s) be added to those currently defined as POSTREQs for the job. Indicates the specified job(s) be dropped from those currently defined as POSTREQs. Indicates the specified job(s) are released on abnormal termination, including condition code failures, of a predecessor. Indicates the specified job(s) are released on any termination of a predecessor. 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.
537
POSTREQ Statement, Continued
Related information
For information on specifying job relationships, see the AFTER, RELEASE, PREREQ, and POSTREQ statements. For information on Applications, see the ESP Workload Manager Users Guide.
Example 1
The following POSTREQ statement identifies job relationships within an Application:

APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB1 RUN WORKDAYS POSTREQ PAYJOB2 ENDJOB
In the above example, PAYJOB2 is automatically selected for submission and runs after PAYJOB1 successfully completes.
Example 2

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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.
Example 3

APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB7 RUN DAILY POSTREQ (PAYJOB8(A)) JOB PAYJOB8 ENDJOB
In the above example, PAYJOB8 is automatically selected for submission and runs after the abnormal termination of PAYJOB7. If PAYJOB7 completes successfully, PAYJOB8 is not eligible for submission.
538
Example 4
The following POSTREQ and CLANG statements identify job relationships within an Application:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB9 RUN WORKDAYS POSTREQ (PAYJOB10,PAYJOB11) IF TODAY(FRIDAY) THEN POSTREQ ADD(PAYJOB12,PAYJOB13) JOB PAYJOB10 JOB PAYJOB11 JOB PAYJOB12 JOB PAYJOB13 ENDJOB
In the above example: 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 JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL JOB LINKIT LINK PROCESS RUN DAILY PREREQ (PAYJOB17,PAYJOB18,PAYJOB19) POSTREQ (PAYJOB20,PAYJOB21,PAYJOB22) ENDJOB
In the above example, a link represents the completion of the first three jobs, and releases the second group of three jobs.
539
Example 7
The following POSTREQ statement identifies job relationships for qualified jobs within an Application:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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.
540
PREALLOC Command
Overview
The PREALLOC command is used to pre-allocate a data set.
Type
General command.
Authority
OPER authority is required to issue the PREALLOC command.
Syntax
The syntax of the PREALLOC command is:

PREALLOC [dataset] [ALLOC|UNALLOC]
Parameter dsname ALLOC UNALLOC
Description Indicates the data set name. Indicates the data set be allocated. Indicates a previously allocated data set be restored to nonpreallocated 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
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.

541
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.
542
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.
Type
Syntax
The syntax of the PREREQ statement is:

PREREQ {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]...})}
Parameter jobname
ADD DROP A U N
Description Indicates a jobname in up to eight characters and may include a qualifier in up to eight characters. Enclose multiple job names in parentheses, separated by a blank or a comma. Indicates the specified job(s) be added to those currently defined as PREREQs. Indicates the specified job(s) be dropped from those currently defined PREREQs. Indicates the specified job(s) release the job you are defining on abnormal termination, including condition code failures. Indicates the specified job(s) release the job you are defining on any termination. 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. 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 definitions for PREREQ jobs are required only if you need to specify requirements for these jobs.
543
PREREQ Statement, Continued
Related information
For information on specifying job relationships, see the AFTER, RELEASE, COREQ, and POSTREQ statements. For information on deselecting jobs for submission, see the NORUN and DESELECT statements. For information on Applications, see the ESP Workload Manager Users Guide.
Example 1
The following PREREQ statement identifies job relationships within an Application:

APPL PAYROLL JCLLIB CYBER.JCL. JOB PAYJOB2 RUN WORKDAYS PREREQ PAYJOB1 ENDJOB
In the above example, PAYJOB1 is automatically selected for submission and runs before PAYJOB2.
Example 2

APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB3 JOB PAYJOB4 JOB PAYJOB5 JOB PAYJOB6 RUN WORKDAYS PREREQ (PAYJOB3,PAYJOB4,PAYJOB5) ENDJOB
In the above example, PAYJOB3, PAYJOB4 and PAYJOB5 are automatically selected for submission and run before PAYJOB6.
Example 3

APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB7 JOB PAYJOB8 RUN WORKDAYS PREREQ (PAYJOB7(U)) ENDJOB
In the above example, PAYJOB7 is automatically selected for submission and runs before PAYJOB8. PAYJOB8 runs whether PAYJOB7 completes successfully or not.
544
Example 4
The following PREREQ and CLANG statements identify job relationships within an Application:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB9 JOB PAYJOB10 JOB PAYJOB11 JOB PAYJOB12 JOB PAYJOB13 RUN WORKDAYS PREREQ (PAYJOB9,PAYJOB10) IF TODAY(MONDAY) THEN PREREQ ADD(PAYJOB11,PAYJOB12) ENDJOB
In the above example: 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.
Example 5

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL JOB LINKIT LINK PROCESS RUN WORKDAYS PREREQ (PAYJOB17,PAYJOB18,PAYJOB19) POSTREQ (PAYJOB20,PAYJOB21,PAYJOB22) ENDJOB
In the above example, a link represents the completion of the first three jobs, and releases the second group of three jobs.
545
Example 7
The following PREREQ statement identifies job relationships for qualified jobs within an Application:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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.
546
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.
Type
Syntax
The syntax of the PRIORITY statement is:

PRIORITY n
Parameter n
Description 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.
547
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 JCLLIB CYBER.JCL.CNTL 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.
548
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)]
Parameter uuuu
eventset histid cccc dddd
Description Indicates an Event prefix specification (normally equivalent to a security user ID). The specification may include wildcards. Indicates the logical ID (eight character internal name) of an Event data set. It must be a specific name. Indicates the logical ID (eight character internal name) of a History file. The specification may include wildcards. Indicates the name of a calendar to be used as the first default calendar. 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.
549
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)
In the above example: 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.
550
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.
Type
General command.
Authority
OPER authority is required to issue the PURGSCHF command.
Syntax
The syntax of the PURGSCHF command is:

PURGSCHF criteria
Parameter criteria
Description 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.
Example 2

OPER PURGSCHF NOW LESS 36 HOURS
In the above example, information older than 36 hours is purged from the SCHDFILE.
551
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.
Example 4

OPER PURGSCHF NOW
In the above example, information older than the current time is purged.
552
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.
Type
General command.
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.
553
QUIT Statement
Overview
The QUIT statement is used to quit an ESP Procedure and the Event that invoked it.
Type
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 Workload Manager Users Guide.
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)
In the above example: 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.
554
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 JCLLIB CYBER.JCL.CNTL JOB PAYJOB1 RUN WORKDAYS RELEASE PAYJOB2 IF TODAY(TUESDAY) THEN EXIT SEND TODAY IS NOT MONDAY U(USR01) ENDJOB JOB PAYJOB2 RUN WORKDAY IF TODAY(MONDAY) THEN 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 COMMAND ===> SCR ===> PAGE Jobname APPL PNODE STATUS ___ PAYJOB1 PAYROLL COMPLETE COMPLETED AT 13.14 21 APR ___ PAYJOB2 PAYROLL SUBERROR Submit Error, Quit
555
QUPDATE Command
Overview
The QUPDATE command is used to force ESP to do a JES status and update PNode queue information.
Type
General command.
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
For information on displaying P-Node information, see the LISTPN command.
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.
556
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.
Type
General command.
Authority
OPER authority is required to issue the RACROUTE command.
Syntax
The syntax of the RACROUTE command is:

RACROUTE [ON|OFF] [ITU|NOITU]
Parameter ON OFF ITU NOITU
Description Indicates ESP should issue a SAF RACINIT before executing Events. Indicates ESP should not issue a SAF RACINIT before executing Events. This is the default. Inherit Trigger User - Indicates all triggered Events use the triggering user ID and associated security profile. 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 the System Authorization Facility (SAF), see the ESP Workload Manager Administrators Guide. For information on using RACROUTE at the Initialization Parameter level, see the ESP Workload Manager Installation Guide.
557
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.
558
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]
Parameter time
interval DELAY
ADDITIONAL count
NOMAXIMUM
Description 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. Indicates a whole number of minutes. 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. Indicates that additional job submission will take place with every re-execution. Indicates the maximum number of times the Event is reexecuted. A value between 1 and 255 can be specified. There is no default. 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.
559
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)
In the above example: 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
In the above example: 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 JCLLIB CYBER.JCL.CNTL 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.
560
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
561
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.
Type
Syntax
The syntax of the RELCOUNT statement is:

RELCOUNT n
Parameter n
Description 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 JCLLIB CYBER.JCL.CNTL 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.
562
RELCOUNT Statement, Continued
Example 2
APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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
In the above example, when ESP builds the Application, PAYJOB8 has a hold count of 4. By specifying a RELCOUNT of 3 for PAYJOB8, ESP releases this job when its hold count becomes 3. This means ESP releases PAYJOB8 when any one of its predecessors completes successfully.
Example 3
APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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
In the above example, when ESP builds the Application, PAYJOB1 has a hold count of 2. By specifying a RELCOUNT of 1 for PAYJOB1, ESP releases this job when either data set trigger object completes.
563
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.
Type
Syntax
The syntax of the RELDELAY statement is:

RELDELAY nnn
Parameter nnn
Description 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 Applications, see the ESP Workload Manager Users Guide. 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 Workload Manager Users Guide. For information on manipulating jobs within Applications or subApplications, see the APPLJOB or AJ command. If you need to delay more than 255 minutes, use the REEXEC statement.
564
RELDELAY Statement, Continued
Example 1
The following RELDELAY statement delays the submission of a specific job:

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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 COMMAND ===> Jobname APPL GEN PNODE HC ___ PAYJOB1 PAYROLL 131 COMPLETE 0 ___ PAYJOB2 PAYROLL 131 WAITING 0 Row 1 of 3, Col 1 SCR ===> PAGE
STATUS COMPLETED AT 21.54 03 FEB WAITING UNTIL 21.59 03 FEB
Example 2
The following RELDELAY statement delays a LINK:

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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.
565
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.
Type
Syntax
The syntax of the RELEASE command is:

RELEASE criteria
Parameter criteria
Usage notes
The RELEASE command is used in conjunction with the HOLD command to make a previously postponed Event eligible for execution. 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 make a previously bypassed Event eligible for execution.
Related information
For information on Events, see the ESP Workload Manager Users Guide. 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.
566
RELEASE Command - Event Level, Continued
Example 1

EVENT ID(CYBER.PAYROLL) 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.
Example 2

EVENT ID(CYBER.PAYROLL) SCHEDULE 6PM DAILY HOLD 5PM LAST DAY OF MONTH RELEASE 9PM LAST DAY OF MONTH SUBMIT CYBER.JCL.CNTL(PAYJOB2) ENDDEF
In the above example, HOLD and RELEASE commands are used to prevent PAYJOB2 from being submitted between 5 pm and 9 pm on the last day of the month.
Example 3

EVENT ID(CYBER.PAYROLL) SCHEDULE 8AM WORKDAYS HOLD 7:59 FEB 13,1998 ONCE RELEASE 10:01 FEB 13,1998 ONCE SUBMIT CYBER.JCL.CNTL(PAYJOB3) ENDDEF
In the above example, HOLD and RELEASE commands are used to prevent PAYJOB3 from being submitted between 7:59 and 10:01 on February 13, 1998 only.
567
RELEASE Command - General
Overview
The RELEASE command decrements the hold count associated with an Event. It is used in conjunction with the HOLD command.
Type
General command
Syntax
The syntax of the RELEASE command is:

RELEASE eventid
Parameter eventid
Description 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 a previously postponed Event eligible for execution. Note: The SUSPEND command is used in conjunction with the RESUME command to make a previously bypassed Event eligible for execution.
Related information
For information on overdue Events, see the SCHEDULE command. For information on Events, see the ESP Workload Manager Users Guide. 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.
568
RELEASE Statement
Overview
The RELEASE statement is used to identify a successor to a job. The successor is released upon completion of this job.
Type
Syntax
The syntax of the RELEASE statement is:

RELEASE {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]...})}
Parameter jobname
ADD DROP A
U N
Description 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. Indicates the specified job(s) be added to those currently defined RELEASEs. Indicates the specified job(s) be dropped from those currently defined RELEASEs. Indicates the specified job(s) are released on abnormal termination, including condition code failures, of a predecessor. Indicates the specified job(s) are released on any termination of a predecessor. 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. The termination parameters (A,U,N) are available only for jobs in an Application. 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.
569
RELEASE Statement, Continued
Example 1
The following RELEASE statements identifies job relationships within an Application:

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL 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.
Example 3

APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB7 RUN WORKDAYS RELEASE (PAYJOB8(A)) JOB PAYJOB8 CONDITIONAL 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.
570
RELEASE Statement, Continued
Example 4

APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB9 RUN WORKDAYS RELEASE (PAYJOB10(U)) JOB PAYJOB10 CONDITIONAL 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 JCLLIB CYBER.JCL.CNTL JOB PAYJOB11 RUN WORKDAYS RELEASE ADD(PAYJOB12) RELEASE ADD(PAYJOB13) 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 JCLLIB CYBER.JCL.CNTL JOB PAYJOB14 RUN DAILY RELEASE PAYJOB15 RELEASE ADD(PAYJOB16) 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.
571
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.
Type
General command.
Syntax
The syntax of the REMOVE command is:

REMOVE string
Parameter string
Description 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 For information on indicating that all specifications are complete and that the copy process should proceed, see the GO command. For information on job documentation, see the ESP Workload Manager Users Guide.
572
REMOVE Command, Continued
Example 1
In the above example, ESP will: 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 semicolon on any line beginning with STEP. The semicolon 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. Proceed with the copy process.
573
REPORT Command
Overview
The REPORT command is used to begin a report definition.
Type
Reporting command.
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.
Example 1

REPORT FROM 7AM YESTERDAY CRITERIA APPLSYS EQ PAYROLL DISPLAY JOBNAME JOBNO APPLSYS CMPC ENDR
In the above example: 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.
574
RESDEF Command
Overview
The RESDEF command is used to define, display, delete or update resources.
Type
General command
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]
Parameter name
ADD DEL LIST SET
Description 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). Indicates you are defining a new resource. Deletes one or more existing resource definitions. Displays a list of one or more existing resource definitions. This is the default. Modifies attributes of a resource definition. Resource type and scope cannot be modified.
575
RESDEF Command, Continued
Syntax (continued) Parameter ENTERPRISE Description Indicates the resource is equally available across the entire enterprise - a single resource pool is shared by all MVS images. This is the default. Indicates one resource counter is available for each JESPLEX. This maintains one resource pool for each node. Indicates one resource counter is maintained for each MVS image. Defines a threshold resource type. Defines a renewable resource type. This is the default. Defines a depletable resource type. Displays jobs that are currently executing and holding a resource. This is used with LIST. Displays jobs waiting for a resource. This is used with LIST. Refers to the node name defined when the system topology was specified. Limits LIST or SET to a specific node. Refers to the node name defined when the system topology was specified. Limits LIST or SET to a specific CPU. Sets maximum counter value for resource you are defining. Sets available value for resource you are defining. Indicates either the IBM generic or esoteric device name that ESP is to monitor. Indicates jobs are to be routed to other nodes on which the resource is available. Indicates jobs are not to be routed to other nodes on which a resource is available. This is the default.
GLOBAL LOCAL THRESHOLD RENEWABLE DEPLETABLE OWNERS WAITERS NODE(xxx) CPU(xxx) MAX(n) AVAIL(n) DEVICE(xxxxx) GRAVITY NOGRAVITY
576
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 CPU T2 ADD NODE(TORONTO) ROUTEJCL(/*JOBPARM SYSAFF=T2) ORDER(2) CPU T3 ADD NODE(TORONTO) ROUTEJCL(/*JOBPARM SYSAFF=T3) ORDER(3) 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.
577
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 TORONTO MVSA Local Renewable Max=2 Avail=2
RESDEF CICS SET MAX(4) Resource CICS Local Renewable TORONTO MVSA Max=4 Avail=4 RESDEF CICS SET AVAIL(6) Resource CICS Local Renewable TORONTO MVSA Max=4 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 Continued on next page
578
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 requesting resources, see the RESOURCE statement. For information on specifying default resources, see the RESDFLT command. For information on resources, see the ESP Workload Manager Users Guide.
Example 1
The following RESDEF command displays all resources:

RESDEF - LIST
In the above example, all existing resource definitions are displayed.

579
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.
Example 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.
Example 4

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.
580
Example 6

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)
In the above example: 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.
581
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.
582
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.
Type
General command.
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)]
Parameter Description 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.
583
RESDFLT Command, Continued
Syntax (continued) Parameter Description 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.
584
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 requesting resources, see the RESOURCE statement. 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. For information on resources, see the ESP Workload Manager Users 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.

585
Example 3

RESDFLT SCRATCH(SCRTAPES) RESDEF SCRTAPES ADD GLOBAL DEPLETABLE AVAIL(500)
In the above example: 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. 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.
586
Example 5

RESDFLT ELAPSEDTIME(ELAPSE) RESDEF ELAPSE ADD LOCAL THRESHOLD AVAIL(60)
In the above example: The RESDFLT Initialization Parameter or command indicates ESP should make 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)
587
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.
Type
Syntax
The syntax of the RESOLVE statement is:

RESOLVE identifier
Parameter identifier
Description 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
For information on identifying an external scheduled activity data set, see the 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.
588
RESOLVE Statement, Continued
Example 1
The following RESOLVE statement is used to resolve an external dependency:

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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.
589
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.
Type
Syntax
The syntax of the RESOURCE statement is:

RESOURCE {resname1[,resname2]} {(count,resname1[,count,resname2]...)} {ADD(count,resname1[,count,resname2]...)} {DROP(resname1[,resname2])}
Parameter resname count,resname
ADD
DROP(resname)
Description Indicates a resource name using up to eight alphanumeric characters. Has a default value of 1. 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. 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. 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.
590
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. For information on resources, see the ESP Workload Manager Users Guide.
Example 1
The following RESOURCE statement identifies a resource requirement for a specific job:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB1 RUN WORKDAYS RESOURCE (1,CICS) ENDJOB
In the above example, PAYJOB1 requires 1 unit of a resource called CICS.

591
Example 2
The following RESOURCE statements identify resource requirements:

APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB2 RUN WORKDAYS REL PAYJOB3 RESOURCE (1,IMS) JOB PAYJOB3 RUN WORKDAYS RESOURCE (1,T3480,2,SCRATCH) ENDJOB
In the above example: 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 JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL 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.
592
Example 5
The following RESOURCE statement drops a default resource and identifies a resource requirement:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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.
593
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.
Type
General command.
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. For information on resources, see the ESP Workload Manager Users Guide.
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
594
RESTART Command
Overview
The RESTART command is used to take ESP out of the quiesced state, restarting Event scheduling and Application processing.
Type
General command.
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 ESP1977I ESP RELEASE 5.1.0.000 STATUS ESP1978I EVENT SCHEDULING ACTIVE ESP1979I DATASET TRIGGERING ACTIVE
In the above example, Event scheduling and Application processing are active as noted by the ESP1978I message - EVENT SCHEDULING ACTIVE.
595
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.
Type
General command
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)]
Parameter EVENTSET INDEX USERDEF JOBINDEX HISTFILE dsname bkupdsname smfno
newdsn
schedule
Description Indicates the name of an Event data set. Indicates the name of the Index data set. Indicates the name of the User Definition data set. Indicates the name of the Job Index data set. Indicates the name of a History data set. Indicates the data set name of file to be restored. Indicates the data set name of most current backup from which the file is to be restored. Indicates the record number used for journalling updates to SMF file. This corresponds to your SMFREC Initialization Parameter. 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. 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.
596
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 //SYSPRINT DD SYSOUT=* //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.
597
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.
Type
Syntax
The syntax of the RESUME command is:

RESUME criteria
Parameter criteria
Usage notes
The RESUME command is used in conjunction with the SUSPEND command to make a previously bypassed Event eligible for execution. The RELEASE command is used in conjunction with the HOLD command to make a previously postponed Event eligible for execution. 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 Events, see the ESP Workload Manager Users Guide. For information on suspending an Events execution, see the SUSPEND command. For information on decrementing an Events hold count, see the RELEASE command.
598
RESUME - Event Level, Continued
Example 1

EVENT ID(CYBER.PAYROLL) DSTRIG PAYROLL.INPUT SUSPEND DAILY AT 9AM RESUME DAILY AT 11AM SUBMIT CYBER.JCL.CNTL(PAYJOB1) 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.
Example 2

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.
599
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.
Type
General command.
Syntax
The syntax of the RESUME command is:

RESUME eventid
Parameter eventid
Description 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. The SUSPEND command is used in conjunction with the RESUME command to make a previously bypassed Event eligible for execution. Note: The RELEASE command is used in conjunction with the HOLD command to make a previously postponed Event eligible for execution.
Related information
For information on Events, see the ESP Workload Manager Users Guide. 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.
600
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 Advanced Users Guide.
Example 1
The following REXXON and REXXOFF statements turn REXX processing on and off:
APPL PAYROLL JCLLIB 'CYBER.JCL.CNTL' 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.
601
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]
Parameter GEN
NOGEN PROC
NOPROC
Description 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. Indicates that REXX processing is not active during Application generation mode. 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. 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 Advanced Users Guide. For information on turning REXX processing off, see the REXXOFF statement.
602
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 JCLLIB 'CYBER.JCL.CNTL' 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.
603
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.
604
ROSSUB Command
Overview
The ROSSUB command is used to submit JCL from a ROSCOE data set to the internal reader.
Type
Syntax
The syntax of the ROSSUB command is:

ROSSUB dsname
Parameter dsname
Description 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 ESP Workload Manager Users Guide.
Example 1
The following is an example of an Event definition that submits JCL from a ROSCOE data set:
EVENT ID(CYBER.ROSJOBS) SCHEDULE 9AM FIRST MONDAY OF MONTH ROSSUB RDS.JOBS ENDDEF
In the above example a ROSCOE data set is submitted at 9 am on the first Monday of the month.
605
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.
Type
Syntax
The syntax of the ROUTE statement is:

ROUTE XEQ(nodename)
Parameter nodename
Description 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 Advanced Users Guide. For information on routing jobs to other JES nodes using ESP Resources, see the ESP Workload Manager Users Guide. For information on inter-system tracking, see the TP Server Installation and Users Guide.
606
ROUTE Statement, Continued
Example 1
The following ROUTE statement routes a job to another JES node:

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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.
607
RUN Statement
Overview
The RUN statement is used to identify a jobs schedule frequency. ESP allows multiple RUN statements for the same job.
Type
Syntax
The syntax of the RUN statement is:

RUN criteria
Parameter criteria
Description 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.
608
RUN Statement, Continued
Related information
For information on Applications, see the ESP Workload Manager Users Guide. For information on specifying schedule criteria, see the ESP Workload Manager 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 JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL 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.
609
Example 4
The following RUN statements identify when a job is selected for submission:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL JOB PAYJOB7 RUN 5TH DAY OF MONTH PLUS 0 WORKDAYS ENDJOB
In the above example, PAYJOB7 is scheduled for submission on the 5th day of each month. If the 5th day of the month is not a workday, PAYJOB7 is selected for submission on the first workday after the 5th day of the month.
610
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 JCLLIB CYBER.JCL.CNTL 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 1st, 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 JCLLIB CYBER.JCL.CNTL 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.
611
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).
Type
Reporting command.
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]
Parameter sardb schedule
starttime
codsn
Description Indicates the name of the data set to store scheduled activity information. 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. 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. 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.
612
SADGEN Command, Continued
Syntax (continued) Parameter evdb Description 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. Indicates an Event group prefix. Asterisks and a hyphen may be used for masking. Indicates one or more ESP Event class names. Separate each with a comma. Asterisks and a hyphen may be used for masking. Indicates a threshold in minutes. Any Event that executes more frequently than this threshold interval is not simulated. The default is 120. Displays all the commands that ESP simulates to create the scheduled activity database. Indicates the name of a sequential data set where the JCL for each job generated by the SADGEN is stored. Indicates a one-character alphanumeric jobclass to be assigned to each job written to the JCLOUT data set. Indicates a one-character alphanumeric msgclass to be assigned to each job written to the JCLOUT data set. Indicates a quoted string or list of strings that is inserted as the first step to each job written to the JCLOUT data set. 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.
prefix classname
mins
TRACE jcldsn jobclass msgclass string NOHIST
613
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.
614
Related information
For information on scheduled activity reporting, see the ESP Workload Manager Users Guide. For information on modeling, see the ESP Workload Manager Advanced Users 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. For information on resolving dependencies through a scheduled activity data set, see the RESOLVE 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.
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 //SYSPRINT DD SYSOUT=* //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.
Example 2
The following is an example of JCL that could be used to produce a schedule activity data set:
//jobname JOB //STEP1 EXEC ESP,PARM=SAR //SYSPRINT DD SYSOUT=* //SYSIN DD * SADGEN DATASET(CYBER.SAD) 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.
615
Example 3
The following is an example of JCL that could be used to produce a scheduled activity data set:
//jobname JOB //STEP1 EXEC ESP,PARM=SAR //SYSPRINT DD SYSOUT=* //SYSIN DD * SADGEN DATASET(CYBER.SAD) FROM(8AM TODAY) TO(8AM TOMORROW) THRESH(60) /*
In the above example, the SADGEN command generates a scheduled activity data 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.
616
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.
Type
General command.
Authority
OPER authority is required to issue the SADLINK command.
Syntax
The syntax of the SADLINK command is:

SADLINK identifier DATASET(dsname) [GROUP(groupname)]
Parameter identifier dsname groupname
Description Indicates an internal identifier of a scheduled activity data set. Up to eight alphanumeric characters are allowed. Indicates the name of a sequential data set used for storing scheduled activity data. 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. 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. For information on displaying current SADLINK, see the LISTSADL command.
617
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.
618
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.
Type
General command.
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
Parameter identifier
Description 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. For information on identifying an external scheduled activity data set, see the SADLINK command. For information on resolving dependencies through a scheduled activity data set, see the RESOLVE command. For information on displaying current SADLINK, see the LISTSADL command.
619
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.
Example 2
The following is an example of JCL that could be used to produce a schedule 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 //STEP1 EXEC ESP,PARM=SAR //SYSPRINT DD SYSOUT=* //SYSIN DD * SADGEN DATASET(CYBER.SAD) FROM(8AM TODAY) TO(8AM TOMORROW) //STEP2 EXEC PGM=ESP,PARM=SUBSYS(ESPM),COND=(0,NE) //SYSPRINT DD SYSOUT=* //SYSIN DD * SADLOAD SAD1 /*
In the above example, the SADGEN command generates a scheduled activity data 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.
620
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).
Type
General command.
Syntax
The syntax of the SADUPD command is:

SADUPD [DATASET(sardb)]
Parameter sardb
Description 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. For information on scheduled activity reporting, see the ESP Workload Manager 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 //STEP1 EXEC ESP,PARM=SAR //SYSPRINT DD SYSOUT=* //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.
621
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.
Type
General command.
Syntax
The syntax of the SAFGRANT command is:

SAFGRANT (userid1[,userid2]...) (resource[,resource]...)
Parameter userid resource
Description Indicates the user Id or RACF group to be PERMITed to the resource specified. A list of user IDs can be specified. 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 the System Authorization Facility (SAF), see the ESP Workload Manager Administrators Guide. For information on identifying the SAF resource class at the Initialization Parameter level, see the ESP Workload Manager Installation Guide.
622
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.
623
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.
Type
General command.
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
Parameter DSALLOC
NODSALLOC MVSCMD
NOMVSCMD
Description 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. Indicates ESP is not to perform a SAF resource check prior to dynamically allocating any data set. This is the default. Indicates ESP is to use the MVSCMD.cmdstring resource when verifying an Events authority to execute an MVS command. Indicates ESP is to use the OPER resource instead of the MVSCMD.cmdstring resource. This is the default.
624
SAFOPTS Command, Continued
NOMVSCMD (continued) Parameter UTOKEN Description 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 the System Authorization Facility (SAF), see the ESP Workload Manager Administrators Guide. For information on identifying the SAF resource class at the Initialization Parameter level, see the ESP Workload Manager Installation Guide. For information on defining SAF options at the Initialization Parameter level, see the ESP Workload Manager Installation Guide.
625
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.
626
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.
Type
General command.
Syntax
The syntax of the SAFRDEF command is:

SAFRDEF (resource1[,resource2]...) [UACC(NONE|READ|UPDATE|ALTER)]
Parameter resource1
UACC()
Description 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. 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
For information on the System Authorization Facility (SAF), see the ESP Workload Manager Administrators Guide. For information on identifying the SAF resource class at the Initialization Parameter level, see the ESP Workload Manager Installation Guide.
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.
627
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.
Type
General command.
Syntax
The syntax of the SAFRDEL command is:

SAFRDEL(resource1[,resource2]...)
Parameter resource
Description 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
For information on the System Authorization Facility (SAF), see the ESP Workload Manager Administrators Guide.
Example 1
The following SAFRDEL command deletes a SAF resource:

SAFRDEL (GROUP.OPS)
In the above example, the GROUP.OPS resource is deleted.
628
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.
Type
General command.
Syntax
The syntax of the SAFREVOK command is:

SAFREVOK (userid1[,userid2]...)(resource1[,resource2]...)
Parameter userid Resource
Description Indicates the user ID or RACF group to have access revoked. A list of user IDs can be specified. 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. For information on the System Authorization Facility (SAF), see the ESP Workload Manager Administrators Guide.
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.
629
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.
Type
General command.
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]
Parameter dsname * eventid printdsn trjobname
trdsname
schedtime
jobname symchar
Description Indicates the data set containing the JCL to be scanned. Indicates that input is to come from the SYSIN file. Indicates the name of the Event for the job. Indicates the data set to which the JCL is copied. This data set cannot be a PDS. 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. Indicates the name of a data set that causes a data set trigger. The trdsname parameter is passed to the ESPTRDSN symbolic variable. 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. Indicates the name of the job to be displayed, if the data set contains a concatenation of multiple jobs. Indicates a one-byte symbol-introducer character. It defaults to %.
630
SCAN Command, Continued
Syntax (continued) Parameter sdsn truname Description Indicates the name or names of data sets to be read for the purposes of symbolic variable generation. 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. 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. Indicates the name of the defining user for this Event that is passed to the ESPUSER symbolic variable. Indicates the current group name that is passed to the ESPGROUP symbolic variable. Indicates any required calendars to be retrieved for this Event scan. Indicates that the scan includes any JCL that is generated to the COPYJCL data set (i.e. any JCL generated by %INCLUDE/EXCLUDE logic).
trvolser
userid groupname cal COPYJCL
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.
631
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.
632
SCHEDULE Command
Overview
The SCHEDULE command is used to define schedule criteria for an Event, which generally includes a time and a frequency.
Type
Syntax
The syntax of the SCHEDULE command is:

{SCHEDULE|SCHED|SCH} criteria [OVERDUE{(count)}] [ONCE]
Parameter criteria count
ONCE
Description Schedule criteria. 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. 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.
633
SCHEDULE Command, Continued
Related information
For information on specifying schedule criteria, see the ESP Workload Manager Users Guide. For information on defining when an Event will execute, see the ESP Workload Manager Users Guide. 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:
EVENT ID(CYBER.PAYROLL) SCHEDULE 4PM WORKDAYS INVOKE CYBER.PROCS.CNTL(PAYROLL) ENDDEF
In the above example, CYBER.PAYROLL is scheduled for execution at 4 pm workdays.
Example 2
EVENT ID(CYBER.PAYROLL) SCHEDULE 4PM WEEKDAYS SCHEDULE 2PM WEEKENDS INVOKE CYBER.PROCS.CNTL(PAYROLL) ENDDEF
In the above example, CYBER.PAYROLL is scheduled for execution at 4 pm weekdays and 2 pm on weekends.
Example 3
EVENT ID(CYBER.PAYROLL) SCHEDULE 8AM WORKDAYS NOSCHED 8AM LAST WORKDAY OF MONTH INVOKE CYBER.PROCS.CNTL(PAYROLL) 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.
634
Example 4
EVENT ID(CYBER.PAYROLL) SCHEDULE 9AM 2ND-LAST DAY OF MONTH INVOKE CYBER.PROCS.CNTL(PAYROLL) 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.
Example 5
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.
Example 6
EVENT ID(CYBER.PAYROLL) SCHEDULE EVERY 4 HOURS ROUND STARTING 8AM WEEKDAYS INVOKE CYBER.PROCS.CNTL(PAYROLL) ENDDEF
In the above example, CYBER.PAYROLL is scheduled for execution on weekdays every 4 hours starting at 8 am.
Example 7
EVENT ID(CYBER.PAYROLL) SCHEDULE 8AM FEB21,1998 ONCE INVOKE CYBER.PROCS.CNTL(PAYROLL) ENDDEF
In the above example, CYBER.PAYROLL is scheduled at 8 am only on February 21st, 1998. The Event is scheduled for automatic deletion 24 hours after this time.
635
Example 8
EVENT ID(CYBER.PAYROLL) SCHEDULE 10PM FRIDAY SCHEDULE 10PM LAST WORKDAY OF MONTH INVOKE CYBER.PROCS.CNTL(PAYROLL) 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.
636
SECURE Statement
Overview
The SECURE statement is used to secure any symbol.
Type
Syntax
The syntax of the SECURE statement is:

SECURE variable
Parameter variable
Description 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.
637
SELECT Statement
Overview
The SELECT statement is used to identify that a job or subApplication should be selected as part of an Application.
Type
Syntax
The syntax of the SELECT statement is:

SELECT {jobname|(jobname[,jobname])} [JOB|SUBAPPL]
Parameter jobname JOB SUBAPPL
Description Indicates a jobname. Enclose multiple jobnames in parentheses, separated by a blank or comma. Indicates a job is selected for submission. This is the default. 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 Applications, see the ESP Workload Manager Users Guide. 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.
638
SELECT Statement, Continued
Example 1
The following SELECT statement selects multiple jobs for submission:

APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB1 REL PAYJOB2 JOB PAYJOB2 ENDJOB SELECT (PAYJOB1,PAYJOB2)
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 JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL 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.
639
Example 4
The following SELECT statement selects multiple jobs for submission on a specific days:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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 JCLLIB CYBER.JCL.CNTL 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
In the above example: 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.
640
Example 6
The following SELECT statement selects multiple jobs on specific days:

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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.
641
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.
Type
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)]
Parameter message text * userid
console routing code rospfx
NONDEL NOW
name
Description 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. 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. Indicates the UCM ID of the console that is to receive the message. Indicates the MCS routing code for a message to be sent to one or more operator consoles. Value between 1 and 128. 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. Indicates the message is marked as non-roll-deletable, if it is transmitted to a console. 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. 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.
642
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 JCLLIB CYBER.JCL.CNTL 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.
643
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)
644
SETPRINT Command
Overview
The SETPRINT command is used to set the default output environment for TITLE processing.
Type
General command.
Syntax
The syntax of the SETPRINT command is:

SETPRINT repname
Parameter repname
Description 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.
645
SETWIDTH Command
Overview
The SETWIDTH command is used to set the width of output.
Type
General command.
Syntax
The syntax of the SETWIDTH command is:

SETWIDTH nnn
Parameter nnn
Description 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 CRITERIA APPLSYS EQ PAYROLL 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.
646
SHADOW Command
Purpose
The SHADOW command is used to display and manipulate a Shadow Manager.
Type
General command.
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)]
Parameter STATUS ASSUMEPRIMARY ASSUMEPRIMARY FORCE
Description Displays the status of the primary/shadow complex. Indicates the Shadow Manager should take over the duty of the primary manager. Indicates the Shadow Manager should take over the duty of the primary manager, whether the primary manager is still active or not. Indicates the Shadow Manager should relinquish its duty as primary manager and shutdown. Indicates the Shadow Manager should relinquish its duty as primary manager. Indicates the Shadow Manager should relinquish its duty as primary manager, shutdown, and hold the primary role for a specified number of minutes.
SHUTDOWN SHUTDOWN RELINQUISH hold_interval
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.
647
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.
648
SIGCYCLE Command
Overview
The SIGCYCLE command is used to cycle a signal, it creates a new current generation.
Type
General command.
Syntax
The syntax of the SIGCYCLE command is:

SIGCYCLE signalname
Description 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.
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. 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
For information on defining and deleting signals, see the DEFSIG and DELSIG commands. For information on posting a generation of a signal, see the SIGPOST command. For information on displaying all generation of a signal, see the LISTSIG command. For information on signal processing, see the ESP Workload Manager Advanced Users Guide.
649
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:

EVENT ID(CYBER.PAYROLL) SCHEDULE 8PM WORKDAYS SIGCYCLE CYBER.SIGNAL1 ENDDEF
In the above example, a new generation of CYBER.SIGNAL1 is created at 8 pm each workday.
650
SIGPOST Command
Overview
The SIGPOST command is used to post a generation of a signal complete.
Type
General command.
Syntax
The syntax of the SIGPOST command is:

SIGPOST signalname [GEN(genno)]
Parameter signalname genno
Description Indicates the name of the signal. If the prefix is omitted, the current group or user prefix is used. 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
For information on resetting the generation number of a signal, see the SIGCYCLE command. For information on signal processing, see the ESP Workload Manager Advanced Users Guide. For information on defining and deleting signals, see the DEFSIG and DELSIG commands. For information on identifying that a signal must be marked complete before execution of an Event, see the SIGWAIT command. For information on displaying all generation of a signal, see the LISTSIG 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.

651
SIGPOST Command, Continued
Example 2

SIGPOST CYBER.SIGNAL2 GEN(-1)
In the above example, the -1 relative generation of CYBER.SIGNAL2 is posted complete.
Example 3

SIGPOST CYBER.SIGNAL3 GEN(123)
In the above example, generation 123 of CYBER.SIGNAL3 is posted complete.
Example 4

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.
Example 5

EVENT ID(CYBER.PAYROLL5) SCHEDULE 10PM WORKDAYS 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.
652
SIGWAIT Command
Overview
The SIGWAIT command is used to identify a signal that must be marked complete before execution of the Event.
Type
Syntax
The syntax of the SIGWAIT command is:

SIGWAIT signalname [GEN(genno)]
Parameter signalname genno
Description Indicates the name of the signal. If the prefix is not specified the current group prefix is used. 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
For information on signal processing, see the ESP Workload Manager Advanced Users Guide. For information on defining and deleting signals, see the DEFSIG and DELSIG commands. For information on posting a generation of a signal, see the SIGPOST command. For information on resetting the generation number of a signal, see the SIGCYCLE command. For information on altering the numbers of generations of a signal, see the ALTSIG 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.
653
SIGWAIT Command, Continued
Example 1
The following SIGWAIT command identifies a signal which must be marked complete:
EVENT ID(CYBER.PAYROLL) SCHEDULE 8PM WORKDAYS SIGWAIT PROD.DATA GEN(0) INVOKE CYBER.PROCS.CNTL(PAYROLL) ENDDEF
In the above example, CYBER.PAYROLL does not execute until PROD.DATA is posted complete and the schedule criteria are satisfied.
654
SIMULATE Command
Overview
The SIMULATE command is used to simulate the functions of an Event.
Type
General command.
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)] [PASSWORD(password)] [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] Continued on next page
655
SIMULATE Command, Continued
Syntax (continued) Parameter EVENT(eventid) SCHED(schedtime) Description Indicates the name of the Event for which you want to simulate processing. 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. Indicates the data set to which the JCL is copied. You can specify an asterisk (*) to view the JCL at your terminal. 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. Requests a simulation of what is written to the COPYJCL library Indicates the names of jobs to which you want to restrict the simulation. Specifying jobname+ includes jobname in the simulation plus its successors. Indicates the name of the job being rerun. Indicates the job that caused the triggering action. Indicates the name of the data set that caused the triggering action. Indicates the volume serial number of the data set that caused the triggering action. Indicates the unit name of the data set that caused the triggering action. Indicates the user ID under which to simulate the Event. Indicates the group value under which to simulate the Event. Indicates the password value under which to simulate the Event. Indicates a list of data set names of symbol libraries to be used.
PRINT(printdsn)
JCLDS
COPYJCL ROOTJOB
JOB TRJOB(trigger_jobname) TRDSN(trigger_dsname) TRVOL(trigger_volume) TRUNIT(trigger_unit) USER GROUP PASSWORD SYMLIB
656
Syntax (continued) Parameter WOB Description Generates a WOB module directory for use in the simulation. If not specified, the directory belonging to the subsystem is used. 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. Indicates a symbol substitution character to be used. Indicates the USER variables passed to the Event. Each variable can be up to 80 characters. 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. 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. 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. 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. 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.
VARS(variable_list)
SYMBOL USER1, USER2, USER3 and USER4 NOLISTPROC
JCLSCAN(exit_module)
NOREXX
NOTSELECTED
INHERIT
657
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.
Example 2

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.
658
Example 3

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(*) Continued on next page
659
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 ADDITIONAL OPTIONS COMMAND ===> DISPLAY PROCEDURE ===> N (blank, N SIMULATE DATASET TRIGGER ===> (blank, N SIMULATE SIGNALS ===> (blank, N SIMULATE MONITOR EVENT ===> (blank, N JCLSCAN EXIT NAME ===> (blank or SUPPRESS REXX ===> (blank, N SHOW NOT SELECTED ===> (blank, N SHOW INHERITANCE ===> (blank, N -------------------- ESP or Y) or Y) or Y) or Y) name) or Y) or Y) 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)
660
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 SIMULATE DATASET TRIGGER SIMULATE SIGNALS SIMULATE MONITOR EVENT JCLSCAN EXIT NAME SUPPRESS REXX SHOW NOT SELECTED SHOW INHERITANCE ===> ===> Y ===> ===> ===> ===> ===> ===> (blank, N (blank, N (blank, N (blank, N (blank or (blank, N (blank, N (blank, N or Y) or Y) or Y) or Y) name) or Y) or Y) 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.
661
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.
Type
General command.
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.
662
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.
Type
Reporting command.
Syntax
The syntax of the SORT command is:

SORT field {A|D}
Parameter field A D
Description Indicates the name of a field. Indicates sorting in ascending sequence. This is the default. 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 history reporting, see the ESP Workload Manager Users Guide. 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 CRITERIA APPLSYS EQ PAYROLL 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).
663
SORT Command, Continued
Example 2
The following SORT command specifies the fields to be sorted:

REPORT FROM 8AM YESTERDAY CRITERIA APPLSYS EQ PAYROLL 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).
664
SPACE Command
Overview
The SPACE command is used to space output by one or more lines to make the output easier to read.
Type
General command.
Syntax
The syntax of the SPACE command is:

SPACE [count]
Parameter count
Description 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).
665
SPINLOG Command
Overview
The SPINLOG command is used to spin ESPs audit log to a sysout class.
Type
General command.
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.
666
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.
Type
General command.
Authority
OPER authority is required to issue the SPUSER command.
Syntax
The syntax of the SPUSER command is:

SPUSER userid
Parameter userid
Description 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 level, see the ESP Workload Manager Installation Guide.
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.
667
STATUS Command
Overview
The STATUS command is used to display the current ESP processing status.
Type
General command.
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 ESP1977I ESP RELEASE 5.1.0.000 STATUS ESP1978I EVENT SCHEDULING ACTIVE ESP1979I DATASET TRIGGERING 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.
668
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.
Type
Syntax
The syntax of the STEPEND statement is:

STEPEND STEPNAME(stepname) PROCSTEP(procstep) RELRES(n1,resname1,n2,resname2, )
Parameter stepname procstep n1,resname
Description Indicates the name of the job step. Indicates the name of the proc step. 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 JCLLIB CYBER.JCLLIB.CNTL 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 JCLLIB CYBER.JCLLIB.CNTL 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.
669
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.
Type
Syntax
The syntax of the SUBAPPL statement is:

SUBAPPL subapplid [WAIT|NOWAIT]
Parameter subapplid
WAIT
NOWAIT
Description 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. 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. 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.
670
SUBAPPL Statement, 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 Manager Users Guide. For information on manipulating subApplications using the CSF, see the ESP Workload Manager Users Guide. 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 the APPLJOB or AJ command.
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.

671
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 JCLLIB CYBER.JCL.CNTL 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 process at the same time. BILLJOB1 and BILLJOB2 are grouped together into the BILLING subApplication. Different generations of the BILLING subApplication can process at the same time.
672
Example 4
The following SUBAPPL statements identify jobs for subApplications within an Application:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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.
673
Example 5
The following Application invokes 4 separate members, each containing a subApplication:

APPL PAYROLL JCLLIB CYBER.JCLLIB.CNTL 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.
674
SUBMIT Command
Overview
The SUBMIT command is used to submit JCL into the internal reader.
Type
Syntax
The syntax of the SUBMIT command is:

{SUBMIT|SUB} dsname [GENERATION(genno)] [LEVEL{(levelname[,levelname]...)|(*)}]
Parameter dsname
genno levelname
Description 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. Indicates a generation number for a generation data group (GDG). It must be zero or a negative number. 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
For information on submitting JCL from an Event, see the ESP Workload Manager Users Guide.
675
SUBMIT Command, Continued
Example 1
The following is an example of an Event definition that submits JCL:

EVENT ID(CYBER.PAYJOB1) SCHEDULE 9AM FIRST MONDAY OF MONTH SUBMIT CYBER.JCL.CNTL(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 SUBMIT CYBER.JCL.CNTL(PAYJOB2) SUBMIT CYBER.JCL.CNTL(PAYJOB3) ENDDEF
In the above example, PAYJOB2 and PAYJOB3 are submitted at 10 am on the last day of the month from CYBER.JCL.CNTL.
Example 3

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.
Example 4

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.
676
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 SUBMIT CYBER.JCL.CNTL(PAYJOB4)
In the above example, if today is not the last day of the month, ESP submits PAYJOB4 from CYB.JCL.CNTL.
677
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.
Type
Syntax
The syntax of the SUSPEND command is:

SUSPEND criteria
Parameter criteria
Usage notes
The RESUME command is used in conjunction with the SUSPEND command to make a previously bypassed Event eligible for execution. 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: The RELEASE command is used in conjunction with the HOLD command to make a previously postponed Event eligible for execution.
Related information
For information on Events, see the ESP Workload Manager Users Guide. 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.
Example 1

EVENT ID(CYBER.PAYROLL1) DSTRIG PAYROLL.INPUT SUSPEND DAILY AT 9AM RESUME DAILY AT 11AM SUBMIT CYBER.JCL.CNTL(PAYJOB1) 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.
678
SUSPEND Command - Event Level, Continued
Example 2

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.
Example 3

EVENT ID(CYBER.PAYROLL2) SCHEDULE 9PM PST WORKDAYS SUSPEND 8PM PST MARCH 2,1998 ONCE RESUME 10PM PST MARCH 2,1998 ONCE SUBMIT CYBER.JCL.CNTL(PAYJOB2) 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.
679
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.
Type
General command.
Syntax
The syntax of the SUSPEND command is:

SUSPEND eventid
Parameter eventid
Description 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 make a previously bypassed Event eligible for execution. The RELEASE command is used in conjunction with the HOLD command to make a previously postponed Event eligible for execution.
Related information
For information on Events, see the ESP Workload Manager Users Guide. 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.
680
SYMLIB Command
Overview
The SYMLIB command is used to request the inclusion of one or more symbolic variable libraries
Type
Syntax
The syntax of the SYMLIB command is:

{SYMLIB|SYM} {symname} {symname[,symname]...}
Parameter symname
Description 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
For information on setting symbol libraries, see the ESP Workload Manager Users Guide. For information on invoking user symbolic variables, see the ESP Workload Manager Advanced Users Guide. For information on defining a symbol library, see the DEFSYML command. For information on displaying information about symbol libraries, see the LISTSYML command.
681
SYMLIB Command, Continued
Example 1
The following SYMLIB command references a symbolic variable library:

EVENT ID(CYBER.PAYROLL1) SYMLIB DATES INVOKE CYBER.PROCS.CNTL(PAYROLL) 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:
EVENT ID(CYBER.PAYROLL1) INVOKE CYBER.PROCS.CNTL(PAYROLL) INVOKE CYBER.SYMBOLS.CNTL(DATES) ENDDEF
Example 2
The following SYMLIB command references two symbolic variable libraries:

EVENT ID(CYBER.PAYROLL2) SYMLIB MDATES PDATES INVOKE CYBER.PROCS.CNTL(PAYROLL) 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.
682
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.
Type
General command.
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]
Parameter text
DISABLE
ENABLE
IGNORE
Description 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. 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. 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. 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.
683
SYSMSGS Command, Continued
Syntax (continued) Parameter CANCEL CCFAIL JCLERROR WARN Description Indicates interception of this message text should generate an MVS cancellation of the job (system abend code 222). Indicates interception of this message should cause a condition code failure. Indicates interception of this message should cause a JCL error. 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. Indicates interception of this message should only occur for time sharing users (TSUs). Indicates interception of this message should only occur for started tasks (STCs). 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. Indicates a column or range of columns where the specified message text should begin. The default is column 1. Indicates up to 4 jobnames (or jobname strings), thus limiting the system message interception for a particular job, or set of jobs. Indicates the Event to be triggered when the system message is intercepted. EVENT can be abbreviated as EV. 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. 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. 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. Indicates the job name should be embedded within the message when it is rebroadcast on the console. Indicates the message should be rebroadcast as a WTO message. Indicates extra blanks are to be removed from the text.
TSU STC ID(xxxx)
nn jobname
eventid m
rcode
dcode
JOBNAME WTO COMPRESS
684
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.
Example 2

SYSMSGS IEF142I NAME(PAYJOB1) EVENT(CYBER.PAYSTEP)
In the above example, whenever an IEF142I system message is generated for PAYJOB1, trigger Event CYBER.PAYSTEP.
685
Example 3

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 specific message ID:
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 specific message ID:
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 specific message ID:
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.
686
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.
Type
Syntax
The syntax of the TAG statement is:

TAG string
Parameter string
Description 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
For information on Applications, see the ESP Workload Manager Users Guide. For information on the CSF, see the ESP Workload Manager Users Guide.
Example 1
The following TAG statement associates a character string with a specific job:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL JOB PAYJOB1 TAG CRITICAL JOB RUN WORKDAYS ENDJOB
In the above example, PAYJOB1 is tagged with the character string CRITICAL JOB.
687
TAG Statement, Continued
Example 2
The following TAG statement associates a character string with an entire Application:
APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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
Associates a character string with a job:

JOB PAYJOB6 TAG TIME 18:00 ENDJOB
Associates a character string with a job:

JOB PAYJOB7 TAG DIVISION 123 ENDJOB
688
TEMPLATE Statement
Overview
The TEMPLATE statement is used to name a template and identify any parameters and variables available during template processing.
Type
Syntax
The syntax of the TEMPLATE statement is:

TEMPLATE name ([posct] [parms...]) [LOCALVARIABLES|GLOBALVARIABLES]
Parameter TEMPLATE name posct
parms LOCALVARIABLES GLOBALVARIABLES
Description Indicates the beginning of the template definition. Indicates the name the template. Indicates the number of positional parameters. Positional parameters must be passed to the template in the order specified. Indicates any positional, keyword, or keyword(value) parameters. Defines variables to be used only with the body of the template. Defines variables to be used within or outside the body of the template. This is the default.
689
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 Advanced Users Guide. For information on ending a template definition, see the ENDTEMPL statement.
690
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.
691
Example 3

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. The following is an example of passing data to the template:
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 JCLLIB CYBER.JCLLIB.CNTL 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.
692
Example 5

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
The following is an example of passing data to the template:

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.
693
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.
Type
Syntax
The syntax of the TEMPLIB statement is:

TEMPLIB dsname
Parameter dsname
Description 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. For information on specifying an optional JCL library for an individual job, see the 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.
694
TEMPLIB Statement, Continued
Example 1
The following TEMPLIB statement identifies an override JCL library:

APPL PAYROLL JCLLIB CYBER.JCL.CNTL 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 //PAYJOB1 JOB CYB,CLASS=A,MSGCLASS=0
In the above example, ESP uses JCL for PAYJOB1 between December 31st, 1999 at 9 am and January 5th, 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 JCLLIB CYBER.JCL.CNTL 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 1st, 1999, ESP uses the temporary JCL if it exists in CYBER.OVERRIDE.99001. Otherwise, it uses JCL from CYBER.JCL.CNTL.
695
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.
Type
General command.
Syntax
The syntax of the TEST command is:

TEST [(n)] criteria
Parameter n criteria
Description Indicates how many times the schedule criteria are to be cycled. The default is 1. 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 00.00.00 00.00.00 00.00.00 00.00.00 FRIDAY FEBRUARY 27TH, 1998, DAY 058 TUESDAY MARCH 31ST, 1998, DAY 090 THURSDAY APRIL 30TH, 1998, DAY 120 FRIDAY MAY 29TH, 1998, DAY 149 TUESDAY JUNE 30TH, 1998, DAY 181 Continued on next page
696
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 3rd Saturday in May:

TEST 3RD SATURDAY OF MAY
697
THEN Statement
Overview
The THEN statement is used in conjunction with an IF statement when the expression that follows the IF statement returns a true value.
Type
Syntax
The syntax of the THEN statement is:

THEN action-statement
Parameter THEN
action-statement
Description 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. Indicates the action to be taken.
Usage notes
When you use an IF statement, the expression that follows it must return a true or false value. The THEN statement is used in conjunction with an IF statement when the 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.
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 expression that follows the IF statement returns a false value.
Related Statements
For information on using ESPs Control Language, see the ESP Workload Manager Users Guide. For information on conditional processing, see the IF, ELSE and DO statements.
698
THEN Statement, Continued
Example 1
The following logic is used to process different 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 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 15th day of the month and TUESDAY, and if so PAYJOB1 is selected to run.
Example 3
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.
699
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
Parameter criteria
Description 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. For information on modeling, see the ESP Workload Manager Advanced Users 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.
700
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.
Type
General command.
Syntax
The syntax of the TITLE command is:

TITLE n [SET] [DELETE] [title string}
Parameter n SET DELETE title string
Description Indicates which title line you are defining; the range is 1-7. The default is 1. Indicates the title for subsequent pages is to be set. An immediate page eject does not occur. Indicates the specified title line is to be deleted. 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: Parameter %CE %DATE %DAY %DD %DDDD %DOW# %EVAL Description Centers the Parameter within the output line. Full date, e.g. SUNDAY 4th JANUARY 1998. Day of week name, e.g. MONDAY. Day of month number, i.e. from 01 to 31. Julian day or day of year number. E.g. 365 for last day. Day of week number, e.g. 1 for Sunday, 7 for Saturday, regardless of calendar settings. Returns the numeric value of an expression. An outputformat descriptor may follow the parameter to request leading blanks or zeros. Hour, in 24-hour format, e.g. 14. Returns the length of the Parameter. Month number, e.g. 01 if the month is January. first three characters of the month, e.g. JAN. Minute of the hour.
%HH %LENGTH %MM %MMM %MM
701
TITLE Command, Continued
Usage notes (continued) Parameter %MONTH %PAGE %RJ %SSS %TIME %YEAR %YY Description Month name, e.g. JANUARY. The current page number. Justifies the parameter on the right side of the output line. Seconds. Time, in 24-hour format, e.g. 14.30.00. Year, e.g. 1999. 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 CRITERIA APPLSYS EQ PAYROLL 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 //STEP001 EXEC PGM=ESP,PARM='SUBSYS(E510)',REGION=4M //STEPLIB DD DSN=CYB2.ESP510Q.SSCPLINK,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSIN DD * TITLE '%CE(ESP DATASETS)' LDSN /*
In the above example, a title is associated with the output produced by an ESP command.
702
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
703
TRACE Command
Overview
The TRACE command is used to activate the trace facility and allows trace options to be set.
Type
General command
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]
Parameter SET(id) RESET(id) SWITCH
CLOSE
OPEN
REUSE
WRITE STATUS
Description Indicates one or more record identifiers you want to trace. You can specify a list of identifiers and a range of identifiers. Indicates one or more record identifiers you no longer want to trace. 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. 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. 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. 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. Writes to the trace data set to clear any buffered data. 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.
704
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.
705
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.
706
TRACEDEF Command
Overview
The TRACEDEF command is used to identify the data sets to be used to record information collected by the TRACE facility.
Type
General command.
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)]
Parameter dsname
size, count
Description 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. 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 the ESP Workload Manager Installation Guide. For information on activating the trace facility, see the TRACE command. For information on trace commands, see the ESP Diagnostic and Recovery Guide.
707
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.
708
TRACEPRT Command
Overview
The TRACEPRT command is used to print trace data.
Type
General command.
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...])]
Parameter dsn criteria id appl job
Description Indicates the name of one or more trace data sets. Indicates any valid schedule criteria that represent a time range. Indicates a trace ID to print. Ranges are supported. Allows selection by Application name. Wildcards are supported. 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.

709
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.
710
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)]
Parameter NAME(string)
JOB/STC/TSU
RACID(string) CLASS(classid) ACCOUNT1 ACCOUNT2 ACCOUNT3 ACCOUNT4 PGMR(string) NOTRACK MODEL
Description 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. 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. Indicates the security system user ID associated with the job. Indicates the jobs execution class. This can be up to eight characters in a JES3 environment. Indicates the jobs first account number. Only the first eight characters are checked. Indicates the jobs second account number. Indicates the jobs third account number. Indicates the jobs fourth account number. Indicates the programmer name field associated with the job. All 20 character positions can be checked. Indicates a job matching the TRACKDEF entry not be tracked. 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.
711
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 job tracking definition tables, see the ESP Workload Manager Administrators Guide. 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.
712
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.

713
Example 3

WILDCARD WILDCARD WILDCARD TRACKDEF TRACKDEF TRACKDEF TRACKDEF TRACKDEF TRACKDEF TRACKDEF TRACKDEF # 09 /* NUMERICS */ $ AZ /* ALPHABETICS */ + 09AZ /* ALPHANUMERIC */ JOB NAME(DUMMYJOB) NOTRACK JOB NAME(CYBJOB) MODEL(CYBMODEL) JOB NAME($$$$####) MODEL(PRODJOBS) ACCOUNT1(CYB3000) MODEL(TESTJOBS) RACID(CYBFM) MODEL(DEMOMDL) JOB CLASS(G) MODEL(MODELG) JOB NAME() MODEL(MODEL1) 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 tracking definition statement indicates ESP does not track a job called
st
DUMMYJOB
The 2 tracking definition statement indicates ESP uses model CYBMODEL to
nd
track jobs where names begin with CYBJOB

The 3 tracking definition statement indicates ESP uses tracking model
rd
PRODJOBS to track jobs whose names consist of four alphabetic characters followed by four numeric characters The 4th tracking definition statement indicates ESP uses tracking model TESTJOBS to track jobs where the first account number is CYB3000 The 5th tracking definition statement indicates ESP uses tracking model DEMOMDL to track jobs with a RACID that begins with CYBFM The 6th tracking definition statement indicates ESP uses tracking model MODELG to track class G jobs The 7th and 8th tracking statements indicate ESP will track all other jobs and started tasks using model MODEL1.
714
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)
715
TRACKING Command
Overview
The TRACKING command is used to enable or disable the ESP tracking facility.
Type
General command.
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]
Parameter COLLECT
NOCOLLECT
STORE NOSTORE
LOG NOLOG
Description 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). 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. Indicates tracking data from SMF be stored in the TRAKFILE and the History data set(s) be updated. 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. Reserved for future use. Reserved for future use.
716
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.
717
TRACKOPT Command
Overview
The TRACKOPT command is used to set various tracking options.
Type
General command.
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]
Parameter STC NOSTC TSU NOTSU SYSMSGS NOSYSMSGS MASTER SLAVE JAT NOJAT
Description Indicates started tasks should be tracked. Indicates tracking of started tasks should not occur. Indicates TSO users should be tracked. Indicates tracking of TSO users should not occur. Indicates system messages should be intercepted. Indicates interception of system messages should not occur. Indicates this as the MASTER system for Application processing. Indicates this as a SLAVE system. Indicates a Job Authorization Table is to be used. This only applies if you are using ESPs internal security. Indicates Job Authorization Tables are not used. This only applies if you are using ESPs internal security.
718
TRACKOPT Command, Continued
Syntax (continued) Parameter TRACK_PURGE NOTRACK_PURGE POST_OLDEST NOPOST_OLDEST Description Indicates jobs are tracked through the OUTPUT P-Node. Indicates jobs are not tracked through the OUTPUT PNode. Indicates External and Manual jobs are posted complete in the oldest active generation of an Application. 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 the ESP Workload Manager Installation Guide. For information on setting up tracking, see the ESP Workload Manager Administrators Guide.
719
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.
720
TRDFLT Command
Overview
The TRDFLT command specifies an installation-default to be used when an Event is triggered manually.
Type
General command.
Authority
OPER authority is required to issue the TRDFLT command.
Syntax
The syntax of the TRDFLT command is:

TRDFLT {ADD} {REPLACE}
Parameter ADD REPLACE
Description Indicates a manual trigger of an Event should be performed in addition to the next scheduled execution. 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 on Events, see the ESP Workload Manager Users Guide. 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.
721
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.
Type
General command.
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...)] Continued on next page
722
TRIGGER Command, Continued
Parameter eventid REPLACE
ADD
trigtime
NOXEQ sysid FORCE SATISFY userinfo HOLD
ROOT
Description Indicates the name of the Event to be triggered. If prefix is not specified, your current group prefix is used. Indicates this execution is to replace only the next scheduled execution of the Event. The TRDFLT Initialization Parameter sets the default. 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. 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. Bypasses the next scheduled execution. Indicates the ID of the system on which you want the Event to execute. Trigger Event ignoring any signals. Trigger Event satisfying any signals. Indicates up to 80 characters of user data enclosed in single quotes. 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. 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.
723
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.
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.
724
Example 2
The following TRIGGER command triggers an Event at a specific time:

TRIGGER CYBER.PAYROLL AT(3PM TODAY)
In the above example, the TRIGGER command brings forward the next scheduled 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 1ST.
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)
In the above example, the TRIGGER command brings forward the next scheduled 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+)
In the above example, the TRIGGER command brings forward the next scheduled 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.
725
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.
726
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.
Type
General command.
Authority
OPER authority is required to issue the TRYJOIN command.
Syntax
The syntax of the TRYJOIN command is:

TRYJOIN MEMBER(member)
Parameter member
Description 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
727
UNALLOC Command
Overview
The UNALLOC command is used to unallocate a data set from ESP.
Type
General command
Authority
OPER authority is required to issue the UNALLOC command.
Syntax
The syntax of the UNALLOC command is:

UNALLOC dsname
Parameter dsname
Description 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.
728
//* 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.
Type
Syntax
The syntax of the //* UNTIL statement is:

//*UNTIL criteria
Parameter 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.
729
//* 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 //PAYJOB1 JOB CYB,CLASS=A,MSGCLASS=0
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 //PAYJOB3 JOB CYB,CLASS=A,MSGCLASS=0
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.
730
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.
731
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.
Type
General command.
Syntax
The syntax of the USER command is:

USER userid/password
Parameter userid password
Description Indicates your user ID. 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 //SYSPRINT DD SYSOUT=* //SYSIN DD * USER USER01/APPLES
In the above example, USER01 is identified as a valid ESP user.
732
USERMOD Command
Overview
The USERMOD command is used to define the ESP user modifications to be implemented.
Type
General command
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]
Parameter usermodid SET RESET LIST
Description Indicates a number, list of numbers, or range of numbers from 1-255. Turn on the usermod. Turn off the usermod. 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.

733
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.
734
VS Command
Overview
The VS command is used to issue a command to the operating system.
Type
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)]
Parameter command text
cc
Description Indicates the text of the command, enclosed within quotes. If the text contains embedded quotes, they should be doubled up. 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 Manager Users Guide.
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.

735
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.
736
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
Parameter char string
Description Wildcard character. 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 tracking definition entries in a job tracking definition table, see the TRACKDEF statement. For information on job tracking definition tables, see the ESP Workload Manager Administrators Guide. For information on loading job tracking definition tables (JTDT), see the LOADJTDT command.
737
WILDCARD Statement, Continued
Example 1

WILDCARD WILDCARD WILDCARD TRACKDEF TRACKDEF TRACKDEF # 09 /* NUMERICS */ $ AZ /* ALPHABETICS */ + 09AZ /* ALPHANUMERIC */ JOB NAME(DUMMYJOB) NOTRACK JOB NAME(PAY) MODEL(PAYMODEL) 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 1st tracking definition statement indicates ESP does not track a job called DUMMYJOB. The 2nd tracking definition statement indicates ESP uses model PAYMODEL to track jobs where names begin with PAY The 3rd tracking definition statement indicates ESP uses tracking model PRODJOBS to track jobs whose names consist of four alphabetic characters followed by four numeric characters.
738
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
Parameter member
Description 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 D520 D521 SYSA 0081 D521 D521 Master D520 D522 SYSA 007D D522 D522 Slave D520 D523 SYSA 006D D523 D521 Shadow Status Active Active 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 Continued on next page
739
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 Group=D520, Member=D521, TermOpt=Quiesce Group Member System ASID Jobname D520 D521 SYSA 0081 D521 D520 D522 SYSA 007D D522 SSID ESP D521 Master D522 Slave Status Active Active
740
XCF DISPLAY Command
Overview
The XCF DISPLAY command is used to view system attributes of your XCF group.
Type
ESP XCF command.
Entering commands
Syntax
The syntax of the XCF DISPLAY command is:

XCF {DISPLAY|D} {ACTIVE|A} {GROUP|G} {SERVICE|S} {SYSTEM|SYS} {TRACE|TR}
Parameter ACTIVE GROUP SERVICE SYSTEM TRACE
Description Displays the active XCF Service listener(s) on the Master ESP and the connection(s). Displays the status of your XCF group. Displays the status of the XCF Services in the group. Displays all systems in the Sysplex. Displays the status of the Trace log.
741
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 Listener DSTRIG Listener ROUTING D522 DSTRIG D522 ROUTING Status Active Active Active Active Connection 1,1 2,2
DISPLAY ACTIVE cont
This is an example of the same command when entered from a Slave ESP subsystem:
XCF D A Group=D520, Member=D522 Partner Service D521 DSTRIG D521 ROUTING Status Active Active Connection 1,1 2,2
Example DISPLAY GROUP
The following example shows the short form of the DISPLAY GROUP command when entered from the Master ESP subsystem:
XCF D G Group=D520, Member=D521, TermOpt=Quiesce Group Member System ASID Jobname D520 D521 SYSA 006B D521 D520 D522 SYSA 006C D522 D520 D523 SYSA 006D D523 SSID D521 D522 D521 ESP Master Slave Shadow Status Active Active Active
XCF D G Group=D520, Member=D522, TermOpt=Quiesce Group Member System ASID Jobname D520 D521 SYSA 006B D521 D520 D522 SYSA 006C D522 D520 D523 SYSA 006D D523 SSID D521 D522 D521 ESP Master Slave Shadow Status Active Active Active
742
XCF DISPLAY Command, Continued
Example DISPLAY SERVICE
The following example shows the short form of the DISPLAY SERVICE command when entered from the Master ESP subsystem:
XCF D S Service DSTRIG ROUTING Status Active Active Group D520 D520 Member D521 D521
XCF D S Service DSTRIG ROUTING Status Active Active Group D520 D520 Member D522 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
743
XCF FORCE Command
Overview
The XCF FORCE command is used to terminate an active ESP XCF member abnormally with code S00C.
Type
ESP XCF command.
Entering commands
Syntax
The syntax of the XCF FORCE command is:

XCF FORCE {MEMBER|M} member
Parameter member
Description Indicates the name of the ESP subsystem you want to terminate.
Example
The following display shows member D522 as active.

XCF DISPLAY GROUP Group=D520, Member=D521, TermOpt=Quiesce Group Member System ASID Jobname D520 D521 SYSA 0081 D521 D520 D522 SYSA 007D D522
SSID ESP D521 Master D522 Slave
Status Active Active
The following example shows removing XCF member D522:

XCF FORCE MEMBER D522 ESP4232I XCF member D522 forced, Group=D520 Continued on next page
744
XCF FORCE Command, Continued
Example cont
The following display shows the XCF group with the forced member.
XCF DISPLAY GROUP Group=D520, Member=D521, TermOpt=Quiesce Group Member System ASID Jobname D520 D521 SYSA 0081 D521 D520 D522 SYSA 007D D522 SSID ESP D521 Master D522 Slave Status Active 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 Group=D520, Member=D521, TermOpt=Quiesce Group Member System ASID Jobname D520 D521 SYSA 0081 D521 SSID ESP D521 Master Status Active
745
XCF HELP Command
Overview
The XCF HELP command is used to display the list of ESP XCF commands available.
Type
ESP XCF command.
Entering commands
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 DELETE MEMBER member DISPLAY ACTIVE|ACTIVITY DISPLAY GROUP|GROUPS DISPLAY SERVICE|SERVICES DISPLAY SYSTEM|SYSTEMS DISPLAY TRACE FORCE MEMBER member HELP PURGE CONNECTION connection PURGE SERVICE service SET TERMOPT LEAVE|QUIESCE SET TRACE SYSOUT(class) SPIN TRACE START SERVICE service START TRACE STOP GROUP STOP MEMBER member STOP SERVICE service STOP TRACE VERIFY MEMBER member Short Form DEL M|MEM member D A|ACT D G|GR D S|SERV D SYS D TR FORCE M|MEM member H|? PG CON connection PG S|SERV service T TO L|Q T TR S(class) SP TR S S|SERV service S TR P G|GR P M|MEM member P S|SERV service P TR VER M|MEM member
746
XCF PURGE Command
Overview
The XCF PURGE command is used to terminate and restart an ESP XCF Service.
Type
ESP XCF command.
Entering commands
Syntax
The syntax of the XCF PURGE command is:

XCF {PURGE|PG} {SERVICE|SERV|S} service {CONNECTION|CON} connection
Parameter SERVICE service CONNECTION connection
Description Used to specify a Service function in the XCF group. Indicates the name of the ESP XCF Service you want to terminate and restart. Used to specify a connection number of the listener. 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 Group=D520, Member=D521 Partner Service Listener TRACKING Listener DSTRIG D522 TRACKING D522 DSTRIG Status Active Active Active Active Connection 6,10 7,11 Continued on next page
747
XCF PURGE Command, Continued
The following example shows purging an ESP XCF Service: PURGE SERVICE cont
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 Group=D520, Member=D521 Partner Service Listener DSTRIG Listener TRACKING D522 DSTRIG D522 TRACKING Status Active Active Active Active Connection 7,11 8,12
Example PURGE CONNECTION
The following example shows purging a connection:

XCF PURGE CONNECTION 3 ESP4225I Connection 3 purged
748
XCF SET TERMOPT Command
Overview
The XCF SET TERMOPT command is used to preset how the ESP XCF member will terminate the XCF group.
Type
ESP XCF command.
Entering commands
Syntax
The syntax of the XCF SET TERMOPT commands is:

XCF {SET|T} {TERMOPT|TO} {LEAVE|L} {QUIESCE|Q}
Parameter TERMOPT
LEAVE
Description 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. 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. 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.
QUIESCE
749
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.
750
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.
Type
ESP XCF command.
Entering commands
Syntax
The syntax of the XCF SET TRACE command is:

XCF {SET|T} {TRACE|TR} {SYSOUT|S}(class)
Parameter (class)
Description 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.
751
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.
Type
ESP XCF command.
Entering commands
Syntax
The syntax of the XCF SPIN TRACE command is:

XCF {SPIN|SP} {TRACE|TR}
Parameter SPIN TRACE
Description Used to send trace data to output and start a new trace file. Indicates XCF Trace facility.
Example
The following example shows the short form of the SPIN TRACE command:
XCF SP TR
Related information
752
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.
Type
ESP XCF command.
Entering commands
Syntax
The syntax of the XCF START SERVICE command is:

XCF {START|S} {SERVICE|SERV|S} service
Parameter SERVICE service
Description Used to specify a Service function in the XCF group. 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.
753
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.
Type
ESP XCF command.
Entering commands
Syntax
The syntax of the XCF START TRACE command is:

XCF {START|S} {TRACE|TR}
Parameter TRACE
Description Indicates XCF Trace facility.
Example
The following example shows the short form of the START TRACE command:
XCF S TR
Related information
754
XCF STOP GROUP Command
Overview
The XCF STOP GROUP command is used to stop all the ESP XCF members in the XCF group.
Type
ESP XCF command.
Entering commands
Syntax
The syntax of the XCF STOP GROUP command is:

XCF {STOP|P} {GROUP|G}
Parameter GROUP
Description Indicates an XCF group.
755
XCF STOP MEMBER Command
Overview
The XCF STOP MEMBER command is used to stop an ESP XCF Member.
Type
ESP XCF command.
Entering commands
Syntax
The syntax of the XCF STOP MEMBER command is:

XCF {STOP|P} {MEMBER|M} member
Parameter MEMBER member
Description Used to specify a Member name in the XCF group. 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
756
XCF STOP SERVICE Command
Overview
The XCF STOP SERVICE command is used to stop an ESP XCF Service.
Type
ESP XCF command.
Entering commands
Syntax
The syntax of the XCF STOP SERVICE command is:

XCF {STOP|P} {SERVICE|SERV|S} service
Parameter SERVICE service
Description Used to specify a Service function in the XCF group. 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.
757
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.
Type
ESP XCF command.
Entering commands
Syntax
The syntax of the XCF STOP TRACE command is:

XCF {STOP|P} {TRACE|TR}
Parameter TRACE
Description Indicates XCF Trace facility.
Example
The following example shows the short form of the XCF STOP TRACE command:
XCF P TR
Related information
758
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.
Type
ESP XCF command.
Entering commands
Syntax
The syntax of the XCF VERIFY command is:

XCF {VERIFY|VER} {MEMBER|M} member
Parameter MEMBER member
Description Used to specify a Member name in the XCF group. 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.
759
XMITMDL: Identify Tracking Models To Transmit
Overview
The XMITMDL command tells ESP which tracking models are to be transmitted, and to which node.
Type
General command.
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]...)
Parameter ADD DELETE LIST modelname
nodeid
Description Indicates that new information is to be added to the specification of tracking data transmitted. Delete model or node from previous XMITMDL definition. List models and nodes previously defined. This is the default. 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. 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
760
% %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
761
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 LJ 452 LOAD .................................................................. 455 LOADAGDF ....................................................... 457 LOADJTDT......................................................... 458 LOADSCHF ........................................................ 460 LOADUPDT........................................................ 461 LOGPRT.............................................................. 462
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 a sub-Application................................................... 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
763
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
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
765
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 a sub-Application................................................... 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
766
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 schedule criteria................................................... 638 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
767
LISTSCH ................................................................. 438 LISTSIG .................................................................. 441 LISTSPEC ............................................................... 443 LISTSYML.............................................................. 446 LISTTRAK .............................................................. 448 LISTUSER............................................................... 449 LISTXMEZ.............................................................. 451 LJ 452 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
768
R RACF resources, defining........................................ 627 RACINIT ................................................................. 557 RACROUTE ............................................................ 557 Readying a job ....................................................................... 63 a sub-Application................................................... 63 Real resources, refreshing ........................................ 594 REEXEC.................................................................. 559 Re-executing ESP Procedures.................................. 559 RELCOUNT ............................................................ 562 RELDELAY ............................................................ 564 RELEASE................................................ 566, 568, 569 Releasing a job ....................................................................... 63 a sub-Application................................................... 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 a sub-Application................................................... 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
769
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
770
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
Sub-Applications...................................................... 416 deselecting ........................................................... 202 identifying............................................................ 670 schedule criteria................................................... 638 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 a sub-Application................................................... 63 Undefined symbols................................................... 307 Undefined symbols,allowing...................................... 44 Unrequesting a job ....................................................................... 63 a sub-Application................................................... 63 Unwaiting a sub-Application................................................... 63 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
771
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
772
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.
773
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
774

ESP Workload Managercommandref52

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ESP Workload Managercommandref52

Hochgeladen von

Copyright:

Verfügbare Formate

ESP Workload Manager

Issuing console commands

Issuing OPER commands

Issuing commands in batch

Wildcards and masking

To display all calendars with names containing XY in character positions 3 and 4:

To display all calendars with two-character names:

The Syntax diagrams in this manual use the following conventions:

Optional, mutually exclusive parameters. Enter one or none.

JOBRES MAPUSER MGRADDR MGRMSG TRYJOIN

The following statements have been added: ABSORB DURATION STEPEND

ABANDON DEPENDENCIES Statement

ESP Application statement.

The syntax of the ABANDON DEPENDENCIES statement is:

Description Schedule criteria that resolve to a single date and time.

Specifying ABANDON DEPENDENCIES does not override a:

ABANDON DEPENDENCIES Statement, Continued

ABANDON RESOURCES Statement

ESP Application statement.

The syntax of the ABANDON RESOURCES statement is:

Description Schedule criteria that resolve to a single date and time.

Specifying ABANDON RESOURCES does not override a:

ABANDON RESOURCES Statement, Continued

In the above example, PAYJOB3 is submitted at:

ABANDON SUBMISSION Statement

ESP Application statement.

The syntax of the ABANDON SUBMISSION statement is:

Usage notes continued

ABANDON SUBMISSION Statement, Continued

ABANDON SUBMISSION Statement, Continued

In the above example, If PAYJOB9 is not submitted by 3 am:

OPER authority is required to issue the ABENDLIM command.

The syntax of the ABENDLIM command is:

ABENDLIM Command, Continued

This following ABENDLIM command displays the abend queue size:

The following ABENDLIM command sets the abend queue size:

ESP Application statement.

The syntax of the ABSORB statement is:

Example Absorb statement

Absorption is available for the following types of resources: Renewable Depletable.

The syntax of the ADJUST command is:

Parameter EXECTIME CPUTIME factor

The ADJUST command is only available with Modeling.

ADJUST Command, Continued

In the above example:

ESP Application statement.

The syntax of the AFTER statement is:

AFTER Statement, Continued

The following AFTER statement is used to indicate job relationships:

The following AFTER statement is used to indicate job relationships:

AFTER Statement, Continued

The following AFTER statements are used to indicate job relationships:

AFTER Statement, Continued

Indicates that PAYJOB5 is to be released after an abnormal termination of PAYJOB1:

OPER authority is required to issue the AGENT command.

The syntax of the AGENT command is:

Parameter AGENT name

AGENT Command, Continued

CM_OWNED DM_OWNED ORPHANS FLUSH

The following is an example of the AGENT command:

Response received from the above command:

In this example, the Agent HP is quiesced.

In this example, the Agent HP is restarted.