SOE - 2.4.00E - SOEEXEC Program Reference

Scheduler Operational Environment (Early-Release) – Version 2.4.00ESOEEXEC Program Reference

Scheduling Operational Environment 2.4 SOEEXEC Program Reference

1 Scheduler Operational Environment ................................................................................ 3 1.1 Introduction ............................................................................................................... 3 1.2 Running SOEEXEC programs .................................................................................. 3

2 SOEEXEC Program Documentation ............................................................................... 4 2.1 ADDAPPL – Add an application to the Current Plan .............................................. 4

2.1.1 Function ............................................................................................................. 4 2.1.2 Process control .................................................................................................. 4 2.1.3 Running the command ....................................................................................... 4

2.2 CPSRUPD – Update resources in the Current Plan .................................................. 5 2.2.1 Function ............................................................................................................. 5 2.2.2 Process control .................................................................................................. 5 2.2.3 Running the command ....................................................................................... 6

2.3 CSVBUILD – Generate applications from a CSV file ............................................. 6 2.3.1 Function ............................................................................................................. 6 2.3.2 Process control .................................................................................................. 7 2.3.3 Running the command ....................................................................................... 9

2.4 IAXREF – Input Arrival Cross Reference .............................................................. 10 2.4.1 Function ........................................................................................................... 10 2.4.2 Process control ................................................................................................ 11 2.4.3 Running the command ..................................................................................... 11

2.5 JOBFIND – Find the applications for a job ............................................................ 13 2.5.1 Function ........................................................................................................... 13 2.5.2 Process control ................................................................................................. 14 2.5.3 Running the command ..................................................................................... 16

2.6 JOBUPD – Update applications for a job ............................................................... 17 2.6.1 Function ........................................................................................................... 17 2.6.2 Process control ................................................................................................. 18 2.6.3 Running the command ..................................................................................... 21

2.7 MODOP – Modifying operations in the Current Plan ............................................ 22 2.7.1 Function ........................................................................................................... 22 2.7.2 Process control ................................................................................................ 23 2.7.3 Running the command ..................................................................................... 30

2.8 NOESCAPE – Protecting against unconnected applications .................................. 31 2.8.1 Function ........................................................................................................... 31 2.8.2 Process control ................................................................................................ 32 2.8.3 Running the command ..................................................................................... 32

2.9 PERIODWK – Generate week number variables for a period ............................... 32 2.9.1 Function ........................................................................................................... 32 2.9.2 Process control ................................................................................................ 33 2.9.3 Running the command ..................................................................................... 34

2.10 SUBLINK – Submit and Link an occurrence ....................................................... 35 2.10.1 Function ......................................................................................................... 35 2.10.2 Process control ............................................................................................... 35 2.10.3 Running the command ................................................................................... 37

Copyright IBM 2010 Page 2


1 Scheduler Operational Environment

1.1 IntroductionThe Scheduler Operational Environment (SOE) is a REXX based tool set to give easy access to the features of the Tivoli Workload Scheduler for z/OS Program Interface (PIF) for Scheduling Teams and Operators.

SOE can be extended by SOEEXEC programs, these are REXX programs that utilize SOE functions to tackle specific tasks or functions.

SOE is delivered with a set of programs in the SOEEXEC library.

1.2 Running SOEEXEC programsProviding you have included the SOEEXEC library in the SYSPROC concatenation in the EQQYXJCL procedure, SOEEXEC programs can be run by EQQYXJCL, naming the SOEEXEC program with the CMD symbolic parameter.

//RUNPIF EXEC EQQYXJCL, // SUBSYS=TWSA, // CMD=CSVBUILD //OUTBL DD SYSOUT=* //INPUTDEF DD * MAP(JOB,RC,PRED,FORM,.,WS) ADID(FRED) FORM(DD0001) WS(CPU1)POLICY(60<26,5<51,3) UPDATE(Y) FIRSTWS(DUMM) LASTWS(DUMM) DESCR(Excel Application) ODESCR(Scheduling) OWNER(TWS) //CSVFILE DD * JOBA JOBB,4,JOBA,DD0002,HELLO,WAIT JOBC,,JOBA JOBQ,,GOODBYE JOBD,,'JOBB JOBC' JOBQ

Additional DD statements may then be required for the specific program. Consult the documentation for the program concerned for other JCL requirements.

WARNING: Input files to SOEEXECs can be catalogued datasets or instream data within the JCL. The command strings can be extremely long, and in the case of Comma Separated Value files much longer than 80 bytes. Care should be taken with SOEEXEC jobs using instream data to disable “line numbers” (UNNUM or NUMBER OFF in PDF Edit). As it is quite conceivable numeric data could form part of the input the SOEXEC code cannot reliably determine whether numbers in columns 73 to 80 were intended as data, or line numbers, so the whole of the input file, regardless of record length, is always treated as input to the process.



2 SOEEXEC Program Documentation

2.1 ADDAPPL – Add an application to the Current Plan

2.1.1 FunctionThe ADDAPPL program adds an application to the current plan.

2.1.2 Process control The program is controlled by keywords in the ARGS symbolic for the EQQYXJCL procedures.

Each keyword having the value contained with parenthesis and separated from the next keyword by a space.

The following keywords are available –• ADID – The name of the Application to submit (required).• IA – The input arrival time to use, if not specified TWS will allocate the current

or next available time that is available for this application.

2.1.3 Running the commandThe ADDAPPL program uses the EQQYXJCL procedure with no additional DD statements.

The JCL for running the command must specify ADDAPPL as the command//RUNPIF EXEC EQQYXJCL, // SUBSYS=TWSA, // CMD=ADDAPPL,// ARGS=’ADID(ADHOC) IA(0904261530)’



2.2 CPSRUPD – Update resources in the Current Plan

2.2.1 FunctionThe CPSRUPD program allows Special Resources to be updated in the current plan. A single resource can be set explicitly or multiple resources can be set by use of wildcards.

The program will search for all matching resources that are NOT in the desired status and issue SRSTAT commands to set them. This means that resources already in the required status will NOT generate additional events.

If the desired availability and the default availability for a resource are the same, then by default the SRSTAT will RESET the availability to the default. If you specify RESET(NO) then the SRSTAT will explicitly set the override availability to the desired state.

2.2.2 Process control The program is controlled by keywords in the ARGS symbolic for the EQQYXJCL procedures. Alternatively you can provide the keywords as SYSIN.


The following keywords are available –• SR – The name of the Special Resource to set. Wildcards can be used (required).• AVAIL(YES/NO) – The availability you want to set (required).• MATCHTYP – If your resource name includes spaces, % or * characters as part of

the name then you may need to use MATCHTYP to select the correct resource. With MATCHTYP not specified the resource name to search for is considered to be everything up to the first space, everything beyond is ignored and % and * are treated as wildcards. With MATCHTYP specified spaces, % and * are treated as normal characters and the following matches can be performed.

o MATCHTYP(EXA) – An exact match will be performed looking for something with the whole name exactly as typed.

o MATCHTYP(PFX) – Will search for resources that begin with the name specified.

o MATCHTYP(SFX) – Will search for resources that end with the name specified

• RESET(YES/NO) – Whether to RESET the resource if AVAIL matches the default availability (default YES).



• SUBSYS – Targets the SRSTAT command to a specific tracker. If omitted SOE will use the SUBSYS as determined by OPTIONS TRACKERS settings.

• UPDATE(YES/NO) – Allows you to run the command to see what it would have done without performing any changes by specifying UPDATE(NO) (default YES)

2.2.3 Running the commandThe CPSRUPD program uses the EQQYXJCL procedure with no additional DD statements.

The JCL for running the command must specify ADDAPPL as the command//RUNPIF EXEC EQQYXJCL, // SUBSYS=TWSA, // CMD=CPSRUPD,// ARGS=’SR(MY.SRTYPE.*) AVAIL(N)’

2.3 CSVBUILD – Generate applications from a CSV file

2.3.1 FunctionThe CSVBUILD program will generate a primitive application, or suite of applications, from a comma separated value (CSV) file. The primitive application will simply have the jobs and dependencies defined, with some operations attributes set. They will not include run cycles, special resources or other such features not directly contained on an operation record. CSVFILE can be used to create the primitive applications which can then amended afterwards using the dialogs or other means, to add more detailed features.

The CSV file can contain jobs, dependencies, workstations, highest return code, form definition and duration. The code can easily be extended to include other operation attributes as needed. The absolute minimum for the CSV file is that there must be a column for the names of the jobs to run, and a column for dependencies.

The columns in the CSV file can be mapped to the relevant operation attributes with the MAP keyword. This removes any requirement to format the CSV file to meet the requirements of the program.

The program will take the entire content of the CSV file and create a workflow for all of the operations, and then break this into multiple applications if necessary, based on your operation numbering POLICY. If only one application is created the application name is exactly the same as the one specified in the control statements. If the number of operations causes an application split, then the application names will be numerically suffixed. If the supplied application name is already 16 characters long, the suffix will be overlayed over the last few characters.

Each generated Application will have a START and END operation to tie unattached dependencies to.



Dependencies made to jobs defined later in the list will still be made, so it is not necessary to sort the CSV file into estimated execution order. The program WILL highlight dependencies to jobs NOT in the list as external predecessors, which will be defined as being to an application called EXTERNAL_PRED, with the operation number and workstation being the same as used for the END tie up operation. These place holder dependencies will require manual amendment in the resulting primitive application.

Multiple instances of the same jobname can be used, any dependencies made to multiple jobs will always be to the most recently specified in the list before the job making the dependency.

If the dependencies would define a loop, all operations in the loop are reported without generating an application.

It is possible to produce Batch Loader output, for review or later implementation on a later system, or the program will call SOE directly to update the database with the new applications.

2.3.2 Process control The INPUTDEF file is used to control the translation of the CSV file into Application Definitions. The file contains various keywords of the format –KEYWORD(VALUE) KEYWORD(VALUE) KEYWORD(VALUE)


MAP(field,field,field)

The MAP keyword defines which columns of the CSV file relate to details within an operation

• JOBN – The job name you want to search for.• PRED – The predecessors, multiple predecessors should be contained within the same “cell” separated by spaces.



• FORM – The form number• HIGHRC – The Highest Return Code• WSID – The Workstation• DURATION – The estimated duration in seconds• . – A period is used as a placeholder for columns that do not contain information pertinent to the creation of the Application.

e.g. MAP(.,JOBN,HIGHRC,WSID,FORM,.,DURATION)

This example shows the Job name being in column 2, highest return code in 3, workstation in 4, form number in 5 and duration in 7.

POLICY(op<total,op<total,op)

The POLICY keyword defines the Operation Interval policy. Each level of the POLICY defines what operation number to use when the total number of operations in the CSVFILE is less than a specified threshold, with a “catch all” interval at the end.

e.g.POLICY(10<26,5<51,3) Uses an interval of 10 for less than 26 operations, and interval of 5 for less than 51 operations and an interval of 3 for anything higher.

POLICY(5) simply sets the catch all at 5 meaning the interval will be 5 regardless of the number of operations in the CSVFILE.

SKIP(n)

The SKIP keyword specifies how many rows to skip at the beginning of the file before starting processing, to account for header rows in spreadsheets that are used to generate the CSV files e.g. SKIP(3) will skip 3 rows and commence processing with row 4.

UPDATE(Y/N)

The UPDATE keyword specifies whether the generated Batch Loader is to update the TWS database (Y) or simply output the Batch Loader to OUTBL (N).

ADID(application-name)

The ADID keyword defines the Application name to create. If the number of operations results in more than one Application being generated, the names will be suffixed with a numeric count. If the Application name and the numeric suffix



would exceed 16 characters, the numeric suffix will overlay the end of the application name.

e.g. ADID(ABCDAILY) will create ABCDAILY if only one application is needed, or ABCDAILY1, ABCDAILY2 etc if a split occurs.

DESCR(text) OWNER(owner_ID) ODESCR(text) PRIORITY(n) ADVALFROM(yymmdd) STATUS(A/P) GROUP(authority_group) CALENDAR(calendar_ID) ADGROUPID(application_group) DLIMFDBCK(deadline_limit_for_feedback) DSMOOTHING(deadline_smoothing)

These keywords perform the same function as their Batch Loader equivalents in the resulting application.

FIRST(op_num) FIRSTWS(ws_id) FIRSTJOB(jobname)LAST(op_num) LASTWS(ws_id) LASTJOB(jobname)

These keywords define the operation number, workstation and jobname of the first and last operations generated in the application to tie up dependencies. The defaults are as follows –FIRST(1) FIRSTWS(NONR) FIRSTJOB(START) LAST(255) LASTWS(NONR) LASTJOB(END)

<Batch-Loader-Token>(value)

Any Batch Loader tokens for ADOP (see Managing the Workload chapter 11) can be used to set defaults for the mapped columns that have no values e.g. FORM(DD0001) creates a default value of DD0001 for any operation that does not have a value in the mapped column for form number.

They can also be used to create lookup tables to translate input values by suffixing the keyword name with a hyphen and a lookup value, with the replacement value being specified within parenthesis.e.g. FORM-MY.FIRST.JCLLIB(DD0001)FORM-MY.SECOND.JCLLIB(DD0002)

will use DD0001 as the form number for any column that contained MY.FIRST.JCLLIB and DD0002 for any column that contained MY.SECOND.JCLLIB.

This technique can be used for any of the mapped columns.

2.3.3 Running the commandIn addition to normal SOE JCL requirements, CSVBUILD needs the following DD statements allocated.DD Name Purpose AttributesOUTBL Capture Batch Loader output when running

with UPDATE(N).Can be an output dataset or SYSOUT. Typically FB 80



INPUTDEF Contains the control statements that define the behavior of the job.

Input dataset or instream SYSIN. Typically FB 80. Line numbers not tolerated.

CSVFILE The comma separated value file containing the jobs and dependencies.

Input dataset or instream SYSIN. For multiple predecessors allow for a long record length. Line numbers not tolerated.

The JCL for running the command must specify CSVBUILD as the command//RUNPIF EXEC EQQYXJCL, // SUBSYS=TWSA, // CMD=CSVBUILD //OUTBL DD SYSOUT=* //INPUTDEF DD * MAP(JOB,HIGHRC,PRED,FORM,.,WSID) ADID(FRED) FORM(DD0001) WSID(CPU1)POLICY(60<26,5<51,3) UPDATE(Y) FIRSTWS(DUMM) LASTWS(DUMM) DESCR(Excel Application) ODESCR(Scheduling) OWNER(TWS) //CSVFILE DD * JOBA JOBB,4,JOBA,DD0002,HELLO,WAIT JOBC,,JOBA JOBQ,,GOODBYE JOBD,,'JOBB JOBC' JOBQ

2.4 IAXREF – Input Arrival Cross Reference

2.4.1 FunctionThe IAXREF program builds a list of external dependencies and shows the input arrival times that are most likely to be used to resolve the dependency. It is not definitive as in some instances there could be multiple run cycles involved, so time could vary depending on day. In these cases the first run cycle is used to source the input arrival time.

The output looks like this –------------ P R E D E C E S S O R ----------- ------------- S U C C E S S O R -------------- ADID WSID OP# JOBNAME DY TIME SRC ADID WSID OP# JOBNAME DY TIME SRC ================ ==== === ======== == ==== === ================ ==== === ======== == ==== === BANTEST001 CPU1 005 BANTEST6 00 ---- UKN -> BANTEST002 NONR 003 BANTEST6 00 ---- UKN DEANO2 ---- 255 -------- -- ---- NTF -> DEANOTEST NONR 001 FINDMEJU 00 ---- UKN WHEREAREYOU ---- 001 -------- -- ---- NTF -> DEANOTEST NONR 001 FINDMEJU 00 ---- UKN DEANO1 MAN1 001 FIRST 00 ---- UKN -> DEANO2 MAN1 001 FIRST 00 ---- UKN HIPPODAILY NONR 010 HIPAA 00 1800 APL -> HIPPOMTHLY NONR 001 00 1800 APL HIPPODAILY NONR 010 HIPAA 00 1800 APL -> HIPPOWKLY NONR 010 HIPAQ 00 1800 APL BANK#DAILY#001 NONR 255 END 00 1800 APL -> BANK#DAILY#001 NONR 001 START 00 1800 APL GNU#DAILY#001 CPU1 020 GNUD104 00 1800 APL -> BANK#DAILY#001 CPU1 025 TESTJOB5 00 1800 APL TEST#EXTDEP1 NONR 001 FIRST 00 ---- UKN -> TEST#EXTDEP2 NONR 001 FIRST 00 ---- UKN TEST#EXTDEP2 NONR 001 FIRST 00 ---- UKN -> TEST#EXTDEP3 NONR 001 FIRST 00 ---- UKN TEST#GRPMEM1 NONR 001 00 ---- UKN -> TEST#GRPMEM2 NONR 001 00 ---- UKN TEST#GRPMEM2 NONR 001 00 ---- UKN -> TEST#GRPMEM3 NONR 001 00 ---- UKN TEST#LOOKAHEAD1 CPU1 010 JOBLOOK1 00 0200 APL -> TEST#LOOKAHEAD1 NONR 001 START 00 0200 APL



The Predecessor details on the left, the successor details on the right. Each side has the following columns –

• ADID – Application ID• WSID – Workstation name• OP# - Operation number• JOBNAME – Job name• DY – Input Arrival Day• TIME – Input Arrival Time• SRC – Where the Input Arrival time came from

SRC can be one of the following values• OPR – The input arrival was specified on the operation• APL – The input arrival was specified on run cycles in the Application Definition• GRP – The input arrival was specified on run cycles in the Group Definition• UKN – No input arrival was specified at any level• NTF – The predecessor was not found in the database

2.4.2 Process control The program is controlled by keywords in the SCOPE DD statement. The keywords are filter keywords to select the Applications to be used to form the cross reference. The program is only intended for a small scope of cross referencing and not intended for large full database cross referencing.


The following keywords are available –• ADID – The name of the Application.• GROUP – Authority Group Name• GROUPDEF – Application Group name• MONITOR(Y/N) – Application has monitored operations• OWNER – Owner ID• STATUS(A/P) – Status: A=Active or P=Pending• VALID(yymmdd) – Date on which the application must be valid• VALFROM(yymmdd) – Valid from date• VALTO(yymmdd) – Valid to date

Note: These keywords are the standard keywords for LIST ADCOM. Wildcards and comparitors can be used. However TYPE should not be used as the program needs to separately extract applications and groups.

2.4.3 Running the commandThe IAXREF program uses the EQQYXJCL procedure with one additional DD statement. The SCOPE DD statement is used to define the scope of the cross reference.



The JCL for running the command must specify ADDAPPL as the command//RUNPIF EXEC EQQYXJCL, // SUBSYS=TWSA, // CMD=IAXREF//SCOPE DD *OWNER(DEANO) VALID(=) STATUS(A)



2.5 JOBFIND – Find the applications for a job

2.5.1 FunctionThe JOBFIND program will find all the applications in which a named job is defined. It will return the following information for each instance.

• Application name• Valid From• Status• Workstation• Jobname • Operation Number• Next used Operation• Next unused Operation• Tag to show which Job+Workstation query the result came from

The list can be sent to the SOE log (SYSTSPRT), a DD statement or the REXX stack.

The output is space delimited and can be output with headers and aligned.

Warning: TWS is not designed with Job Name as a key field for the database, the JOBFIND may function help alleviate that, but the process may be slow depending on the size of the database being searched.



2.5.2 Process controlALIGN(Y/N)



The ALIGN keyword determines whether the output will be aligned. If the HEADER keyword is set to Y then ALIGN will be ignored and be considered to be set to Y.

ALIGN defaults to Y unless DATA is set to * when the default is N.

DATA(*|ddname|SYSTSPRT)

The DATA keyword specifies where to send the output, the options are –• * - Send the output to the external data queue. The data is send with no header

row and space delimited. If HEADER is not specified it defaults to N. If ALIGN is not specified it defaults to N.

• ddname – Send the output to the named ddname. If HEADER is not specified it defaults to Y. If ALIGN is not specified it defaults to Y.

• SYSTSPRT – Send the output data in amongst the SOE message log. If HEADER is not specified it defaults to Y. If ALIGN is not specified it defaults to Y.

HEADER(Y/N)

The HEADER keyword determines whether the output will have column headers output ahead of the data. If the HEADER keyword is set to Y then ALIGN will be ignored and be considered to be set to Y.

HEADER defaults to Y unless DATA is set to * when the default is N.

INFILE(*|ddname)



The INDSN keyword allows a list of jobnames to be specified either via the REXX stack or via a DD name.

JOBFIND will take the first word of each input row, either space or comma delimited, to be the job name.

INFILE and JOB can be specified together, and BOTH will be searched.

@JOBN(jobname)

The @JOBN keyword names the job you wish to find (required)

@WSID(jobname)

The @WSID keyword names the workstation on which job you wish to find must be defined (optional)

@ADSTAT(A/P)

The @ADSTAT keyword restricts the search to applications of status A or P. Though the @ADSTAT keyword is only specified in the argument, it also applies to all jobs included for searching using the INFILE keyword.

@VALID(yymmdd)

The @VALID keyword restricts the search to applications that are valid on the specified date. Though the @VALID keyword is only specified in the argument, it also applies to all jobs included for searching using the INFILE keyword.

@VALFROM(yymmdd)

The @VALFROM keyword restricts the search to applications by the Valid-From date. Though the @VALFROM keyword is only specified in the argument, it also applies to all jobs included for searching using the INFILE keyword.

@VALTO(yymmdd)

The @VALTO keyword restricts the search to applications by the Valid-To date. Though the @VALTO keyword is only specified in the argument, it also applies to all jobs included for searching using the INFILE keyword.

2.5.3 Running the commandIn addition to normal SOE JCL requirements, CSVBUILD needs the following DD statements allocated.DD Name Purpose Attributes<output> The information output from the command

is written to the file specified in the DATA keyword.

Can be an output dataset or SYSOUT. Typically FB 80



The JCL for running the command must specify JOBFIND as the command and pass the arguments in the ARGS symbolic parameter.//RUNPIF EXEC EQQYXJCL, // SUBSYS=TWSA, // CMD=JOBFIND, // ARGS='@JOB(ZAPPED) HEADER(Y) INFILE(MOREJOBS) DATA(*)'//OUTDATA DD SYSOUT=* //MOREJOBS DD * FRED* TWSC*

2.6 JOBUPD – Update applications for a job

2.6.1 FunctionThe JOBUPD program will find all the applications in which a named job is defined and then perform the requested updates for that job with the Applications.

The updates can be anything performed by the Batch Loader keywords for the ADOP statement.

Because the input could be a simple minor update to a single job, or many fields to many jobs, JOBUPD will work in one of two modes –

1. ARG Mode. The ARGS symbolic is used to pass a single job to update and a few arguments to perform updates.

2. MAP Mode. The ARGS symbolic is used to pass a mapping of columns in a CSV file and the CSV file contains the information to perform the updates for one or more jobs.

Warning: TWS is not designed with Job Name as a key field for the database, the JOBUPD function may help alleviate that, but the process may be slow depending on the size of the database being searched.



2.6.2 Process control@JOBN(jobname)

The @JOBN keyword names the job you wish to update. The JOBN keyword can than be used to change it.

This is an ARG mode keyword.

@WSID(workstation)

The @WSID keyword names the workstation on which the job you wish to update must be defined. The WSID keyword can then be used to change it.

This is an ARG mode keyword.

@ADSTAT(A/P)

The @ADSTAT keyword restricts the search to applications of status A or P. Though the @ADSTAT keyword is only specified in the argument, it also applies to all jobs included for searching within the CSVFILE.



@VALID(yymmdd)

The @VALID keyword restricts the search to applications that are valid on the specified date. Though the @VALID keyword is only specified in the argument, it also applies to all jobs included for searching within the CSVFILE.

@VALFROM(yymmdd)

The @VALFROM keyword restricts the search to applications by the Valid-From date. Though the @VALFROM keyword is only specified in the argument, it also applies to all jobs included for searching within the CSVFILE.

@VALTO(yymmdd)

The @VALTO keyword restricts the search to applications by the Valid-To date. Though the @VALTO keyword is only specified in the argument, it also applies to all jobs included for searching within the CSVFILE.

MAP(field,field,field)

The MAP keyword defines which columns of the CSV file relate to details within an operation. The MAP can either be the number of a row in the CSV file that contains the field name for each column in the relevant column, or it can be a sequence of comma separated field names.

The field names can be -• @JOBN – The field that specifies the job name to identify the operation to update. There MUST be a column mapped to @JOBN. JOBN (i.e. without the @ sign) can be used to map to a new job name to update the selected row to. • @WSID – The field that specified the workstation on which the job to be updated must already exist (optional). WSID (i.e. without the @ sign) can be used to map to a new workstation name to update the selected row to.• <loader argument> – Any valid Batch Loader argument for the ADOP statement can be used as a mapping field, except PREOPNO, PREJOBN and PREWSID. Refer to the Managing the Workload manual, for more information.• . – A period is used as a placeholder for columns that do not contain information pertinent to the creation of the Application.

e.g. MAP(.,@JOBN,HIGHRC,WSID,FORM,.,DURATION)



This example shows the Job name being in column 2, highest return code in 3, workstation in 4, form number in 5 and duration in 7.

e.g. MAP(1)

This example points to row 1 of the CSV file, each cell in this row will contain the name of the field represented by that column.

This is a MAP mode keyword.SKIP(n)

The SKIP keyword specifies how many rows to skip at the beginning of the file before starting processing, to account for header rows in spreadsheets that are used to generate the CSV files e.g. SKIP(3) will skip 3 rows and commence processing with row 4.

If you are using a MAP row within the CSV file, you must use the SKIP keyword to avoid that row.

This is a MAP mode keyword.

PRED(job job)

The PRED keyword contains a space separated list of job names to make as a predecessor to the job. If the job is found inside the same application as the @JOBN job then only an internal predecessor will be made, regardless of whether the application is found in more applications.

If the predecessor needs to be restricted to a job on a particular workstation then use the format job/workstation to specify each predecessor. The Status and Validity of the application will be restricted to the same as the job to which the predecessor is being added.

e.g.



PRED(ABC123 XYZ789) will make any instance of these jobs predecessors.

PRED(DEF456/C* GHI321) will only make instances of job DEF456 on a workstation beginning with C a predecessor, but all instances of job GHI321.

Note: When specified in the ARGS symbolic this is an ARG mode keyword, but the same keyword can be mapped as a column to apply to individual CSV file records

UPDATE(Y/N)

The UPDATE keyword determines whether JOBUPD will apply the updates automatically.

• YES – The updates are applied to the database.• NO – The Batch Loader is written to the OUTBL DD statement and not

processed (default).• SCAN – The Batch Loader is run against TWS in SCAN mode to validate

the syntax but perform no updates.

This keyword works for both MAP and ARG mode.

<loader argument>

Any valid Batch Loader argument for the ADOP statement can be used as a updating field, except PREOPNO, PREJOBN and PREWSID. Refer to the Managing the Workload manual, for more information.

These are ARG mode keywords.

2.6.3 Running the commandIn addition to normal SOE JCL requirements, JOBUPD needs the following DD statements allocated.DD Name Purpose AttributesCSVFILE The comma separated value file containing

the jobs and dependencies. The CSVFILE is only read if MAP has been specified.

Input dataset or instream SYSIN. For multiple predecessors allow for a long record length. Line numbers not tolerated.

OUTBL The Batch Loader generated by this command to perform the updates will be written to OUTBL if UPDATE(N) is specified or allowed to default.

Can be an output dataset or SYSOUT. Typically FB 80



The JCL for running the command must specify JOBFIND as the command and pass the arguments in the ARGS symbolic parameter.//RUNPIF EXEC EQQYXJCL, // SUBSYS=TWSA, // CMD=JOBFIND, // ARGS='JOB(ZAPPED) HEADER(Y) INFILE(MOREJOBS) DATA(*)'//OUTDATA DD SYSOUT=* //MOREJOBS DD * FRED* TWSC*

2.7 MODOP – Modifying operations in the Current Plan

2.7.1 FunctionThe MODOP program is designed to simplify the process of finding and updating operations in the Current Plan. TWS itself is fairly rigid with respect to modifying operations in the current plan, you have to be explicit to identify the individual operation you want to update, and if you want to modify more than one operation, or choose from a possible list of operations then this can be very complicated.

MODOP allows you to run commands against operations using three sets of keywords –• Arguments to identify the potential operations to update, using combinations of

Application ID, Jobname, Workstation, Input Arrival, Operation and Status.• Arguments to choose from the list of identified operations which one or ones you

wish to update.• Arguments specific to the action to be performed.

The commands that can be run against identified operations consists of –



• EXECUTE – Which will cause an operation to be executed even if the workstation is closed or job submission is disabled.

• HOLD – Which will manually hold and operation, preventing TWS from automatically submitting the operation once all other prerequisites have been met.

• MODIFY – Which allows operation attributes to be modified.• MOVETO – Which allows you to move identified operations to a different

workstation.• NOP – Which will cause TWS to NOP (No Process) an operation. This means that

when all prerequisites have been met the operation will be marked as complete.• RELEASE – Which will manually release a previously held operation. If there are

other prerequisites in place, such as predecessors, it will still wait for those to be complete before the operation is allowed to run.

• UNNOP – Which will remove the NOP action from an operation that is waiting to run.

NOTE: Use of MODOP can produce a lot of updates to the Current Plan if using the COUNT(0) feature. This can be across many different occurrences. The MODOP process will automatically perform a PIF EXECUTE MCPBLK command after every change of occurrence to ensure no more than 255 operations are modified in a single transaction.

2.7.2 Process control The MODOP command has a single argument for use in the ARGS symbolic –

• UPDATE(NO|YES) – This determines whether MODOP will actually perform the updates. If NO is specified the MODOP command will report what it intends to do to each identified operation but will not perform any updates.

The SYSIN file is used to specify which operations to modify and what actions to carry out.

Each command may have its own specific arguments, followed by common arguments to identify and select the operations.

<command> <arguments> ADID(<adid>) JOBNAME(<jobn>) OPNO(<opno>)WSNAME(<wsid>) DATE(<iadate>) TIME(<time>) STATUS(<status>) RANGE(<range>) POSITION(EARLIEST|LATEST) COUNT(<count>)NOW(<now>) MATCHTYP(EXA|PFX|SFX)



Identification keywords:These keywords are used to identify the potential operations to update, any combination of these keywords can be used –

• ADID(<adid>) – Will search for operations within applications with name <adid> for the operations to update. Wildcards * and % can be used.

• JOBNAME(<jobname>) – Will search for jobs named <jobname>. Wildcards * and % can be used.

• OPNO(<opno>) – Will search for an operation numbered <opno>. Wildcards cannot be used.

• WSNAME(<wsname>) – Will search for operations scheduled on the <wsname> workstation. Wildcards * and % can be used.

• STATUS(<status>) – If not specified MODOP will by default only select operations in a Waiting Status (W). You can use the ¬= modifier in this argument to specify all statuses except one, e.g. STATUS(C¬=) will select all statuses except Complete (C). The STATUS keyword can only contain a single status, if you wish to perform the same action for multiple statuses you must use multiple command statements. STATUS(*) will by default select all valid status values, you can search for the actual status value of * by additionally coding MATCHTYP(EXA).

• DATE(<yymmdd>) – Will search for operations scheduled with a particular application input arrival date in the format YYMMDD. Wildcards cannot be used, but relative dates can be used –

o = - The current dateo +n – The current date +n days e.g. DATE(+1) is tomorrowo –n – The current date –n days e.g. DATE(-1) is yesterday

• TIME(<hhmm>) – Will search for operations scheduled at a particular application input arrival time in the format HHMM. TIME cannot be used without DATE. Wildcards cannot be used, but relative times can be used –

o = - The current time.o +n – The current time +n minutes e.g. DATE(+60) is on hour in the futureo –n – The current time –n minutes e.g. DATE(-30) is half an hour ago

Selection keywords:These keywords are used to select which operations to modify from the list found by the identification keywords.



• RANGE(<yymmddhhmm> TO <yymmddhhmm>) – Will limit the selection to only operations within the specified application input arrival range. The format is YYMMDDHHMM but if you omit the time 0000 will be used for the “from” time and 2359 will be used for the “to” time. You can specify open ended ranges such as RANGE(TO 091231) or RANGE(090101 TO), RANGE(090101) equates to RANGE(0901010000 TO 0901012359). Wildcards cannot be used, but relative dates can be used –

o = - The current dateo +n – The current date +n days e.g. DATE(+1) is tomorrowo –n – The current date –n days e.g. DATE(-1) is yesterday

• POSITION(EARLIEST|LATEST) – Will determine where to start in the list of identified operations for processing. EARLIEST will start at the operation with the earliest Input Arrival date, LATEST will start with the latest. How many operations it then modifies depends upon the COUNT keyword.

• The COUNT keyword determines how many operations to modify. The default is 1, so POSITION(EARLIEST) would modify only the earliest operation it found within the RANGE, whereas POSITION(LATEST) would only modify the latest. Any positive number will modify that number of operations from the starting position inclusive, if you specify a number higher than the number it finds matching the criteria, all operations will be modified. A value of COUNT(0) will modify however many operation are found matching the criteria. A negative value will modify however many operations are found minus the number in count e.g. POSITION(EARLIEST) COUNT(-1) will modify all except the latest operation found.

Note: RANGE keywords are processed before POSITION and COUNT e.g. you may find 20 operations, but the range may filter that down to 10. POSITION will start at the earliest or latest operation within the 10, and at most you will be able to select 10 operations for modification.

Performance considerationsThe “Identification keywords” will perform a query against the TWS Current Plan, and extract information for every operation it finds that matches. The “Selection keywords” will then filter down this information before taking action. The more precise you can be in the “Selection keywords” the faster the MODOP process will complete. So consider how many matches you might expect to find on the current plan at any one time using the “Selection keywords” when considering the estimated duration of the MODOP job.

Precise targeting is particularly important if you are using the RELEASE keyword for the MOVETO command, as RELEASE requires detailed information to be retrieved from the current plan for every operation identified by the “Identification Keywords”.

Relative Date and Variables:The DATE, TIME and RANGE keywords can use =, + or – to produce relative dates. By default the date and time is the current date and time when the command is processed.



However you may want this to be relative to the Input Arrival time of the job running the commands. To do this there is the NOW keyword.

e.g. MOVETO NONR JOB(MYJOB) WSNAME(CPU1) NOW(&OYMD1.) DATE(-1)

In this example MODOP will look for MYJOB with an input arrival date one day previous to the input arrival of the job running MODOP.

Note: It does not matter what order NOW and DATE are in the command, NOW is always processed before DATE, TIME and RANGE.

If the SYSIN for MODOP is specified within the JCL of a job submitted by TWS, and JCL Tailoring is enabled (VARSUB(SCAN) or //*%OPC SCAN) then all JCL variables will be resolved by TWS before the job is submitted.

However, if the job is not submitted by TWS, or the SYSIN is contained within a dataset, rather then in the JCL, then providing the MODOP job is at least being tracked by TWS it can still resolve some of the TWS JCL tailoring variables itself.

Note: MODOP’s own internal TWS variable support is not as extensive as the in-built TWS JCL Tailoring facility. The variables supported by MODOP are – OADID, ODD, ODMY1, ODMY2, OHH, OHHMM, OMM, OYMD1, OYMD2, OYY, OJOBNAME, OOPNO and OWSID. For MODOP to resolve the variables correctly variable names must be delimited with either a period (.), comma (,), space ( ) or ampersand (&).

Note: DATE, TIME and RANGE all refer to the Application Input Arrival time, not the Operation Input Arrival time.

EXECUTE Command:The EXECUTE command allows you cause an operation to be submitted that may otherwise wait for special resources, workstation shutdown or job submission being disabled. If the operation still has predecessors outstanding it cannot be executed.

The syntax of the command is –EXECUTE <identification> <selection>

Where –• <identification> are keywords to identify the operations to update (as above).• <selection> are keywords to select the operations from the list (as above).

HOLD Command:The HOLD command allows you to add a Manual Hold condition to an operation. This means the operation will wait to be manually released once all of its prerequisites have been met.

The syntax of the command is –



HOLD <identification> <selection>


MODIFY Command:The MODIFY command allows you to modify the attributes on an operation.

The syntax of the command is –MODIFY <identification> <selection> <attributes>

Where –• <identification> are keywords to identify the operations to update (as above).• <selection> are keywords to select the operations from the list (as above).• <attributes> are additional keywords to specify the changes you wish to make

to the operation. The following keywords are available, for full details see the MODIFY CPOP command in the SOE Users Guide and reference –

o AEC – Automatic error completiono AJR – Automatic job hold/release



o ASUB – Automatic job submissiono CLATE – Cancel if lateo CLNTYPE – Dataset cleanup typeo DEADWTO – Issue deadline WTOo DESC – Operation descriptiono DURATION – Duration in 100th of secondo EDUR – Estimated duration HHMM o ERRCODE – Error codeo EXPJCL – Expanded JCL optiono FORM – Form number or blankso HRC – Highest successful return codeo JCLASS – Job classo JOBCRT – Critical jobo JOBPOL – Workload monitor late job policyo MONITOR – Monitor by external producto OPDL – Operation deadlineo OPIA – Operation input arrivaleo PSUSE – Parallel server useo R1USE – Workstation resource 1 useo R2USE – Workstation resource 2 useo RERUT - Reroutableo RESTA - Restartableo TIMEDEP – Time dependent operationo USERDATA – User data fieldo USRSYS – User SYSOUT supporto WLMSCLS – WLM Service class



MOVETO Command:The MOVETO command allows you to move an operation to a new workstation, providing this is an operation that is eligible to do this e.g. operations on FTA workstations cannot be moved. For example you might want to move an operation to a Non-Reporting workstation to cause the job to be skipped once all its predecessors have completed

The syntax of the command is –MOVETO <wsid> <identification> <selection> [RELEASE(INT|EXT|ALL)]

Where –• <wsid> is the name of the workstation to move the operation to. • <identification> are keywords to identify the operations to update (as above).• <selection> are keywords to select the operations from the list (as above).• RELEASE is an optional keyword that can cause the operation’s successors to be

released. The valid values are –o INTERNAL - release only internal successorso EXTERNAL - release only external successorso ALL - release all internal and external successors

Note: To release internal successors the application must be designed in such a way that the removal of the dependencies does not create an inconsistent application. If the result of removing internal dependencies would result in some operations becoming entirely separate from the rest of the occurrence then the command will fail.

NOP Command:The NOP command allows you specify a No Process condition against an operation. This means that when the operation’s prerequisites have been met TWS will mark the operation complete.

The syntax of the command is –NOP <identification> <selection>




RELEASE Command:The RELEASE command allows you to remove a Manual Hold condition from an operation. This means that the operation will be able to execute once all of its prerequisites have been met.

The syntax of the command is –RELEASE <identification> <selection>


UNNOP Command:The UNNOP command allows you remove a No Process condition against an operation. This means that when the operation’s prerequisites have been met TWS will no longer mark the operation complete.

The syntax of the command is –UNNOP <identification> <selection>


2.7.3 Running the commandIn addition to normal SOE JCL requirements, MODOP needs no additional DD statements allocated.

Note: The MODOP parser uses the full 80 columns of SYSIN for command input so ensure JCL sequence numbers are turned off.

The JCL for running the command must specify MODOP as the command//RUNPIF EXEC EQQYXJCL, // SUBSYS=TWSA, // CMD=MODOP //SYSIN DD * MOVETO MAN1 JOBNAME(MYJOB) WSNAME(CPU1)MOVETO MAN1 JOBNAME(MYJOB) WSNAME(CPU1) NOW(&OYMD1) DATE(=)MOVETO MAN1 JOBNAME(MYJOB) WSNAME(CPU1) NOW(&OYMD1) DATE(-1)MOVETO MAN1 JOBNAME(MYJOB) WSNAME(CPU1) POSITION(LATEST)MOVETO NONR JOBNAME(MYJOB) WSNAME(CPU1) COUNT(0)MOVETO NONR JOBNAME(MYJOB) WSNAME(CPU1) COUNT(-1)MOVETO NONR JOBNAME(MYJOB) WSNAME(CPU1) NOW(&OYMD1) RANGE(TO -1) COUNT(0)



In the preceding example the first command moves the earliest example of MYJOB from workstation CPU1 to workstation MAN1. Which in this case is a manual workstation, thus stopping MYJOB actually running and holding all the successors.

The second command does the same thing but to the earliest instance of MYJOB with the same input arrival date as the job running MODOP.

The third command does the same thing again, but this time for the earliest instance of MYJOB with an input arrival date the day preceding the input arrival of the job running MODOP.

The fourth command again does the same thing, this time for the latest instance of MYJOB.

The fifth command moves ALL instances of job MYJOB from workstation CPU1 to workstation NONR. Which in this case is a non reporting workstation, so essentially stops MYJOB running, but allows successors to run.

The sixth command takes all but the very latest occurrence of MYJOB on workstation CPU1 and moves them to workstation NONR.

The final command takes all occurrences of MYJOB with input arrival dates earlier than the input arrival of the MODOP job. Note the COUNT(0) is on the following line as continuation is automatic until MODOP encounters a new command as the first word on a line. The RANGE of “TO -1” will take any input arrival up to and including the day before the input arrival of MODOP.

2.8 NOESCAPE – Protecting against unconnected applications

2.8.1 FunctionWhen the Current Plan is extended it is possible that an application could start immediately if external predecessors have not resolved correctly and there are no time dependent or manual operations within the application.

The NOESCAPE function provides a safety net to help avoid some of these sort of “escapee” applications running when they were not expected.

The premise of the function is that you run the job immediately prior to the Current Plan extend job, telling it how long an extension is about to be made to the plan, and it will identify any occurrences that may run immediately when the Current Plan is extended. If any are identified NOESCAPE will fail with RC=8, causing the Current Plan extend to be delayed until it can be investigated and corrected.



Note: Even with this check in place it is still possible that some operations may start early, that are not “behind” the external predecessor, time dependency or manual operation, but at least part of the application will be held by at least one of these elements. NOESCAPE will only identify occurrences that have no delaying factors at all.

2.8.2 Process control The ARGS symbolic is used to control the NOESCAPE function.

There are two possible keywords –• EXTEND(<hhmmm>|<yymmddhhmm>) – Determines when the new plan will be

extended until. The input can either be Hours and Minutes to extend by, or a date and time to extend to.

• WS(<wsid>,[<wsid>],[…]) – Identifies workstations to be considered as manual workstations. You can specify one or more workstations separated by commas.

2.8.3 Running the commandIn addition to normal SOE JCL requirements, NOESCAPE needs no additional DD statements allocated.

The JCL for running the command must specify NOESCAPE as the command//RUNPIF EXEC EQQYXJCL, // SUBSYS=TWSA, // CMD=NOESCAPE,// ARGS=’EXTEND(02400) WS(MAN1)’

In the preceding example the plan is being extended 24 hours and MAN1 is a manual workstation.

2.9 PERIODWK – Generate week number variables for a period

2.9.1 FunctionThe PERIODWK program generates a series of dependent variables to enable JCL to determine the week number within an interval of a TWS non-cyclic period.

The process will read the specified TWS Period and generate dependent variables for each week within each interval. Whatever day an interval starts on will be day 1 of the week and each new week will start in a further 7 days.

Each week variable will default to N, and then only on specified dates will it be set to Y. The dates can be made dependent on any of the following TWS supplied variables –

• ODMY1• ODMY2



• OYMD1• OYMD2• OYYDDD• OLYMD• OLYYDDD• CDDMMYY• CYYDDD• CYYMMDD

2.9.2 Process control The program is controlled by keywords either in the ARGS symbolic for the EQQYXJCL procedure, or within SYSIN. If the same keywords are entered in both the ARGS values will override the SYSIN value.


The following keywords are available –• DATEVAR – The name of the TWS supplied date variable that will provide the

“input” date to set the appropriate week number variable. The value can be one of the following variable names ODMY1, ODMY2, OYMD1, OYMD2, OYYDDD, OLYMD, OLYYDDD, CDDMMYY, CYYDDD or CYYMMDD.

• MAXWEEK – The highest week variable to guarantee the existence of. The default value is 6.

• MONTH – Whether to create unique tables for each month (YES or NO). The default value is YES. If YES is specified the table names will be derived from the TABLE keyword suffixed with the year and month, e.g. MONTHVARS0912 for December 2009.

• OWNER – The OWNER to set for the table. This value is needed to create new table instances as OWNER is a required value for a TWS JCL Variable table.

• PERIOD – The name of the period to calculate week numbers for.• TABLE – The name of the table to create/update. If MONTH is set to NO then TABLE

will contain the absolute table name, if set to YES it will be the prefix of the tables created for each month.

• UPDATE – Whether to perform updates to the database (YES or NO). If set to NO the process will generate the Batch Loader for you to review, but will not apply it. The default values is NO.

• VARPFX – The prefix to use for the variables created by this process. The default is WKNUM. For each week being generated the variable will be suffixed by the two character week number, e.g. WKNUM01, WKNUM02 etc.



2.9.3 Running the commandThe PERIODWK program uses the EQQYXJCL procedure with no additional DD statements.

The JCL for running the command must specify PERIODWK as the command//RUNPIF EXEC EQQYXJCL, // CMD=PERIODWK, // SUBSYS=TWSA //OUTBL DD SYSOUT=* //SYSIN DD * PERIOD(CYCLE) VARPFX(WEEK#) TABLE(MONTHVARS) DATEVAR(OYYDDD) OWNER(TWS) UPDATE(Y)

This example creates tables with the naming convention of MONTHVARSyymm containing variables WEEK#01, WEEK#02, WEEK#03, WEEK#04, WEEK#05 and WEEK#06. These week variables will be dependent on the occurrence julian date.

This could be processed with JCL similar to the following example//*%OPC SCAN//*%OPC TABLE NAME=MONTHVARS&OYYMM//* JULIAN DATE = &OYYDDD//*%OPC BEGIN ACTION=INCLUDE,COMP=(&WEEK#06..EQ.Y)//* THIS LINE OF JCL ONLY APPEARS ON WEEK 6//*%OPC END ACTION=INCLUDE



2.10SUBLINK – Submit and Link an occurrence

2.10.1 FunctionThe SUBLINK program will submit an occurrence into the current plan. Optionally it can also find an operation already in the current plan and make itself dependent on this operation and a predecessor to all the successors of this operation, effectively inserting the entire application after the named job.

Note: When inserting the application it will assume that operation 1 is the first operation in the application and operation 255 is the last. The first and last operation numbers can be overridden either by your SOE Site or Controller default members, or individually by FIRST and/or LAST arguments to SUBLINK. It is therefore required that any applications to be submitted using SUBLINK must have a First and Last operation, and have the necessary internal dependencies made to ensure the inserts application flows as expected. The First and Last operation can be the same operation if necessary.

2.10.2 Process controlProcess control statements for SUBLINK are coded within the CMDIN file.SUBMIT(application-name)

The SUBMIT keyword names the application you wish to submit to the current plan (mandatory).

ALIAS(application-name)

The ALIAS keyword provides an alternate name for the occurrence on the current plan, to allow the application to run under a name other than the one in the database (optional).

IA(yymmddhhmm)

The IA keyword defines the Input Arrival time for the application you are about to submit, if omitted normal rules apply, in that the current time, or nearest available unused minute, for the named occurrence, will be used. Note that regardless of the input arrival time of the Submitted application, the Target operation and its successors, dependencies will always be made by the SUBLINK process.

@ADID(application-name)

The @ADID keyword names the application in which the operation, that you want to connect the submitted occurrence to, is located.

@IA(yymmddhhmm)

The @IA keyword names the input arrival time of the application in which the operation, that you want to connect the submitted occurrence to, is located.

@OPNO(nnn)



The @OPNO keyword names the operation number of the operation, that you want to connect the submitted occurrence to.

@JOBN(nnn)

The @JOBN keyword names the jobname of the operation, that you want to connect the submitted occurrence to.

@WSID(workstation-name)

The @WSID keyword names the workstation of the operation, that you want to connect the submitted occurrence to.

Note: Any combination of @ADID, @IA, @OPNO, @JOBN and @WSID can be specified as long as they can uniquely identify a single operation in WAITING status. If multiple operations are identified SUBLINK will fail RC=8. If NO operations are identified the setting of the REQD argument determines the behavior.

LINK(PRED/SUCC/BOTH/NONE)

The LINK keyword defines how the submitted occurrence is to be connected to the operation defined by @ADID, @IA, @OPNO, @JOBN and @WSID.

The field names can be -• PRED – The identified operation becomes a predecessor to the submitted occurrence. • SUCC – The successors of the identified operation become successors to the submitted occurrence.• BOTH – The identified operation becomes a predecessor to the submitted occurrence and the successors of the identified operation become successors to the submitted occurrence (default if an operation is nominated to link to).• NONE – No linkage is done (default if no operation is nominated).

FIRST(nnn)

The FIRST keyword specifies the operation within the submitted application, from which dependencies will be made. If not specified SUBLINK will use the SOE default FIRST operation.

LAST(nnn)

The LAST keyword specifies the operation within the submitted application, to which dependencies will be made. If not specified SUBLINK will use the SOE default LAST operation.



REQD(YES/NO/CONDITIONAL)

The REQD keyword determines what to do if @ADID, @IA, @OPNO, @JOBN or @WSID arguments where specified, but no operations were found matching the criteria in a waiting status.

• YES – The target operation is required. If none are found, no submission is performed and SUBLINK ends with RC=8 (default).

• NO – The target operation is not required, it will be linked to only if present.

• CONDITIONAL - If a target operation is not found nothing will be submitted and SUBLINK will end RC=0.

2.10.3 Running the commandIn addition to normal SOE JCL requirements, SUBLINK needs the following DD statements allocated.DD Name Purpose AttributesCMDIN Process control statements for this comman. Input dataset or instream

SYSIN. Line numbers not tolerated.

The JCL for running the command must specify JOBFIND as the command and pass the arguments in the ARGS symbolic parameter.//RUNPIF EXEC EQQYXJCL, // SUBSYS=TWSA, // CMD=SUBLINK //CMDIN DD * SUBMIT(ADHOC1) ALIAS(NEWNAME) @JOBN(TWSCCPEX) LAST(005)

In this example an Application called ADHOC1 is retrieved from the database and added to the Current Plan with the name of NEWNAME. A job called TWSCCPEX is searched for, and if a single instance is found it will be made a predecessor to operation 001 of NEWNAME (001 is the default first operation) and the successors to TWSCCPEX will automatically be made a successor to operation 005 of NEWNAME (the LAST(005) nominates the logical last operation of NEWNAME).

Note: When using SUBLINK multiple times to submit an occurrence depending on the same operation, the occurrences will run in the reverse order to the order to which they were submitted. This is because after the first submission, the inserted application becomes a successor to the target operation, and as the second submission gains all of the successors of the target operation the second SUBLINKed occurrence automatically becomes a predecessor to the first.


Documents

SOE - 2.4.00E - SOEEXEC Program Reference