4. PJS TSO Commands
Note: If you plan to use PJS under ISPF, you can skip this chapter.
The Personal Job Scheduler (PJS) TSO command set contains three sets of commands:
·
PJS Job Request Commands, which enable you to create,
delete, list, and modify job requests. The commands are:
PJREQADD
PJREQDEL
PJREQLST
PJREQMOD
Job request commands are discussed in Section 4.1.
·
PJS Calendar Commands, which enable you to create, delete,
list, and modify calendars. The commands are:
PJCALADD
PJCALDEL
PJCALIST
PJCALMOD
Calendar commands are discussed in Section 4.2.
·
PJS Event Commands, which enable you to list, post, and
reset events. The commands are:
PJEVLIST
PJEVPOST
PJEVRSET
Event commands are discussed in Section 4.3.
Commands are listed in alphabetical order. Each command description begins with a discussion of the command keyword followed by discussions of command parameters. The parameters are listed in functional order.
PJS job request commands enable you to create, delete, list, and modify job requests. The TSO commands are:
PJREQADD which enables you to create a job request. The job request is placed on the PJS Request Queue, so PJS can submit your job for execution. To create a job request, specify the name of the data set that contains the job and the time you want the job submitted. Many other options are available. PJREQADD is discussed in Subsection 4.1.1.
PJREQDEL which enables you to delete a job request from the PJS Request Queue. PJREQDEL is discussed in Subsection 4.1.2.
PJREQLST which displays a list of job requests. The characteristics and values of each job request are displayed. PJREQLST is discussed in Subsection 4.1.3.
PJREQMOD which enables you to modify an existing job request. PJREQMOD is discussed in Subsection 4.1.4.
Commands are listed in alphabetical order. Each command description begins with a discussion of the command keyword followed by discussions of command parameters. The parameters are listed in functional order.
Use the PJREQADD command to place a job request on the PJS Request Queue:
|
PJREQADD [OWNER(owner‑ID)]
JCLDSN(dsname[(member)])
[NOSAVE|SAVE]
[STRTDATE[(mm/dd/[cc]yy)|(*+ddd)]]
STRTTIME{(hh:mm[AM|PM])|(*+{hh:mm|hh|:mm})}
[ ONCE | MINUTES[(nnn)] | HOURS[(nnn)] | DAYS[(nnn)] | WEEKDAYS(day1[[,day2]...]) | WEEKS[(nnn)] | EOM[(nn)] | MONTHS[(nn)] | YEARS[(nn)] | CALENDARS([owner‑ID.]cal‑name[,...]) ]
[ENDDATE{(mm/dd/[cc]yy)|(*+ddd)}]
[ENDTIME{(hh:mm[AM|PM])|(*+{hh:mm|hh|:mm})}]
[EVENTS([owner‑ID.]event‑name[/NOPREPOST|/PREPOST][,...])]
[POSTEVENTS([owner‑ID.]event‑name[,...])]
[WINDOWTIME(hh:mm)]
[WINDOWOPT([DISABLE|ERROR|SKIP])]
[DISABLED|ENABLED]
|
PJREQADD begins the PJREQADD command, which you can use to put a job request on the PJS Request Queue. PJRA is a synonym of PJREQADD. You can also specify PJADD or PJA: these synonyms are included for compatibility with PJS 1.0.
Use the parameters described in the remainder of this subsection to specify job request characteristics. Only two types of parameters are required:
· The JCLDSN parameter tells PJS the name of the data set that contains the job to be executed. For more information, please refer to 4.1.1.2 How to Specify the Data Set Name.
· The STRTTIME parameter tells PJS when to submit the job for execution. For more information, please refer to 4.1.1.3 How to Specify the Time of Submission.
Although only the JCLDSN and STRTTIME parameters are required, the optional parameters provide power and flexibility. Although some parameters have prerequisites, you can specify parameters in any order.
With one exception, any of the values specified in any of the parameters can be changed or deleted by using the PJREQMOD command, which is discussed in Subsection 4.1.4. The exception is the value specified in the OWNER parameter, which is discussed in 4.1.1.1 How to Specify an OWNER.
4.1.1.1 How to Specify an OWNER
This parameter is optional:
OWNER specifies who will "own" the job request. The default is your current TSO user‑ID. You don't have to use this parameter unless you are creating a job request for another owner.
To complete this parameter, use the (owner‑ID) format, where:
owner‑ID specifies who will "own" the job request. For more information on the owner‑ID specification, please refer to Section 3.1.
4.1.1.2 How to Specify the Data Set Name
This parameter is required:
JCLDSN is short for JCL Data Set Name. This keyword tells PJS that the job request will specify a sequential data set or the member of a partitioned data set. The data set or member contains the job you want PJS to submit for execution.
To complete this parameter, specify the data set name by using the (dsname[(member)]) format, where:
dsname is either the name of a sequential data set or the prefixes for a partitioned data set. Use TSO syntax and site standards to enter this value:
If you specify 'dsname', where dsname is enclosed by quotes, the dsname is treated as a fully qualified data set name.
If you specify dsname, without quotes, the TSO data set prefix is automatically prepended to dsname to form prefix.dsname. In most cases, prefix is your TSO user‑ID.
member is the name of a member of a partitioned data set. If you typed in the name of a sequential data set, omit this specification.
DATASET and DSNAME are synonyms of JCLDSN.
4.1.1.3 How to Use the PJS JCL Spool
The optional SAVE or NOSAVE parameters determine whether you place a copy of your job JCL on the PJS JCL Spool. These keywords are mutually exclusive.
If you place job JCL on the PJS JCL Spool, PJS can provide protection from accidental modification or unauthorized access. However, if your site uses a security package such as RACF, your job JCL may already be protected from intrusive access.
The default for PJS JCL Spool use was determined when PJS was installed. Your site may require you to specify either NOSAVE or SAVE, or you may be able to specify either keyword. For more information, please contact your Site Administrator or the person who installed PJS.
SAVE tells PJS to place a copy of the job JCL on the PJS JCL Spool. When the job is submitted, the JCL on the PJS JCL Spool will be executed.
Later, if you decide to remove the job JCL from the PJS JCL spool, you can specify the NOSAVE keyword in the PJREQMOD command. If you change the job JCL and want to apply the changes to future job submissions, you can specify the RESAVE keyword, which replaces the old JCL with the new. For more information on the PJREQMOD command, please refer to Subsection 4.1.4.
NOSAVE tells PJS not to place a copy of the job JCL on the PJS JCL Spool. When the job is submitted, the JCL in a private data set or in a publicly available data set will be executed.
Later, if you decide to place a copy of the job JCL on the PJS JCL spool, you can specify the SAVE keyword in the PJREQMOD command. For more information on the PJREQMOD command, please refer to Subsection 4.1.4.
4.1.1.4 How to Specify the Date of Submission
This parameter is optional:
STRTDATE tells PJS which day you want to submit the job for execution. The default is the current system date, which is usually today's date.
If you decide to specify a value, you can specify an absolute date in the (mm/dd/yyyy) format or a relative date in the (*+ddd) format. For more information on date specifications, please refer to Section 3.6.
DATE and RUNDATE are synonyms of STRTDATE.
4.1.1.5 How to Specify the Time of Submission
This parameter is required:
STRTTIME tells PJS what time you want to submit the job for execution. Because the time parameter is required, there is no default. You must specify a valid time.
You can specify an absolute time in the (hh:mm[AM|PM]) format or a relative time in the (*+{hh:mm|hh|:mm}) format. For more information on time specifications, please refer to Section 3.5.
RUNTIME and TIME are synonyms of STRTTIME.
4.1.1.6 How to Specify a Frequency Option
A frequency option specifies how often PJS is to submit the job for execution. All of the following parameters are optional. The default is ONCE, which means that the job is submitted only one time.
You can specify periodic submission by using one of the MINUTES through YEARS parameters, or you can specify arbitrary submissions by using the CALENDARS parameter. Each time the job is submitted, PJS updates the job request on the PJS Request Queue. If you select MINUTES or HOURS, PJS updates the run time and, if needed, the run date. The other parameters update the run date but not the run time.
You can only specify one of the following parameters:
ONCE means that the specified job is submitted for execution only one time. After the job is submitted, PJS places the job request in COMPLETE or ERROR status. The job request remains on the PJS Request Queue until it is deleted or modified. This is the default.
MINUTES(nnn) means that the job is to be submitted for execution every nnn minutes, where nnn is a value from 1 through 999. The default is 1.
For example, MINUTES means that the job is submitted every minute, and MINUTES(30) means that the job is submitted every half‑hour.
MINS is a synonym of MINUTES.
HOURS(nnn) means that the job is to be submitted for execution every nnn hours, where nnn is a value from 1 through 999. The default is 1.
For example, HOURS means that the job is submitted every hour, and HOURS(12) means that the job is submitted every half‑day.
DAYS(nnn) means that the job is to be submitted for execution every nnn days, where nnn is a value from 1 through 999. The default is 1.
For example, DAYS means that the job is submitted every day, and DAYS(3) means that the job is submitted every third day.
DAILY is a synonym of DAYS.
WEEKDAYS means that the specified job is submitted for execution every week on each specified day. To specify weekdays, use the (day1[[,day2]...]) format, where:
day is one of the following:
SUNDAY
MONDAY
TUESDAY
THURSDAY
FRIDAY
SATURDAY
You can use any abbreviation sufficient to distinguish one day from another, for example, TU for Tuesday, SA for Saturday, or F for Friday.
You can specify the days in any order: WEEKDAYS (TUESDAY,MONDAY) is a valid statement, as is WEEKDAYS(MONDAY,TUESDAY).
WKDAYS and DOW are synonyms for WEEKDAYS.
WEEKS(nnn) means that the job is to be submitted for execution every nnn weeks, where nnn is a value from 1 through 999. The default is 1.
For example, WEEKS means that the job is submitted every week, and WEEKS(3) means that the job is submitted every third week.
WEEKLY is a synonym of WEEKS.
EOM(nn) means that the job is to be submitted nn days before the end of each month, where nn is a value from 0 through 27. The default is 0.
If you specify EOM, the job is submitted each month on the last day of the month, for example, May 31 or June 30. If you specify EOM(3), the job is submitted three days before the end of each month, for example, May 28 or June 27.
MONTHS(nn) means that the job is to be submitted for execution every nn months, where nn is a value from 1 through 99. The default is 1.
For example, if you specify MONTHS, the job is submitted each month. If you specify MONTHS(3), the job is submitted once every three months.
Caution: If the number of days in a month is less than the value of STRTDATE, PJS does not submit your job during that month.
For example, if the start date for a monthly job is January 31, PJS assumes you want to submit the job on the 31st of each month and that every month has 31 days. To calculate the next run date, it adds 31 days to January 31: the next run date is February 31st. The job is actually submitted 31 days from January 31. In most years, the next actual run date is March 3, so the job is not submitted during the month of February. The job is next submitted on March 31, so the monthly job is submitted twice in March.
You can avoid this problem by specifying a start date that begins no later than the 28th day of the month. For example, if you specify MONTHS and a start date of January 16, PJS will submit the job on the 16th of each month. For more information on how to specify a start date with STRTDATE, please refer to 4.1.1.4 How to Specify the Date of Submission
MOS and MONTHLY are synonyms for MONTHS.
YEARS(nn) means that the job is to be submitted for execution every nn years, where nn is a value from 1 through 99. The default is 1.
For example, if you specify YEARS, the job is submitted each year. If you specify YEARS(3), the job is submitted once every three years.
YRS is a synonym of YEARS.
CALENDARS means that PJS will submit the job for execution on the date or dates specified in a calendar. This enables you to specify an arbitrary set of submission dates. Before you can use this keyword, you must have created at least one calendar. For information on how to create a PJS calendar, please refer to Section 4.2.
To complete this parameter, specify at least one calendar‑ID with the ([owner‑ID.]cal‑name[,...]) format, where:
owner‑ID specifies who "owns" the calendar.
cal‑name is the name of the calendar.
For more information on the calendar‑ID, please refer to Section 3.3.
You can specify up to three calendars in a CALENDARS parameter. If you specify more than one calendar, PJS only submits the job on the dates that are selected on every calendar.
4.1.1.7 How to Specify an End Date
This parameter is optional. If you specify a frequency option, you may want to specify a date on which PJS stops submitting the job. If you specify or accept ONCE as a frequency option, you do not need to specify an end date.
ENDDATE tells PJS the date on which it will stop submitting the job for execution.
If you decide to specify a value, you can specify an absolute date in the (mm/dd/[cc]yy) format or a relative date in the (*+ddd) format. For more information on date specifications, please refer to Section 3.6.
The value of the date must be equal to or greater than the value of the date specified or accepted for the STRTDATE parameter.
4.1.1.8 How to Specify an End Time
This parameter is optional:
ENDTIME tells PJS at what time it is to stop submitting the job for execution. If you plan to use the end time parameter, you must also enter the STRTTIME and ENDDATE parameters.
You can specify an absolute time in the (hh:mm[AM|PM]) format or a relative time in the (*+{hh:mm|hh|:mm}) format. For more information on time specifications, please refer to Section 3.5.
If the value of the STRTDATE and ENDDATE parameters are both equal to the same date, then the value specified for ENDTIME must be greater than the value specified for STRTTIME.
4.1.1.9 How to Specify Job Request Events
This parameter is optional:
EVENTS specifies at least one event. The PJS System Task will submit the job only if all events have been posted. This keyword enables you to create event dependencies that must be satisfied before a job can be submitted.
Before you can use event‑related commands such as PJEVPOST, you must use the PJREQADD or PJREQMOD command to tell PJS that at least one job request event is specified; you do not need to define the event beforehand. Event notification can reside in a job, or you can manage event notification manually. For more information on PJS events, please refer to Section 4.3.
To complete this parameter, use the ([owner‑ID.]event‑name[/PREPOST|/NOPREPOST][,...]) format, where:
owner‑ID specifies who "owns" the event.
event‑name is the name of the event. The event does not have to exist. For more information, please refer to Section 3.4.
/PREPOST means that the job request event will be posted in the job request record whenever the event is posted. PJS doesn't care when the event is posted. This is the default.
/NOPREPOST means that the event will not be posted in the job request record if the event is posted before the job is scheduled for its next submission.
You can specify up to 50 events for a job request. If you plan to post job request events now, you can use the POSTEVENTS parameter, which is discussed in 4.1.1.10 How to Post Job Request Events.
4.1.1.10 How to Post Job Request Events
This parameter is optional:
POSTEVENTS posts job request events in the current job request. You must specify a valid EVENTS parameter if you plan to specify POSTEVENTS.
Only job request events in the current job request you are creating with the PJREQADD command can be posted by the POSTEVENTS parameter; identical job request events in other job requests are not posted.
To complete this parameter, use the ([owner‑ID.]event‑name[,...]) format, where:
owner‑ID specifies who "owns" the event.
event‑name is the name of the event.
For more information on how to specify an event‑ID, please refer to Section 3.4. After the job is submitted, all job request events are automatically reset. If you want PJS to resubmit the job, the job request events must be posted again.
4.1.1.11 How to Specify a Submit Window
Both WINDOWTIME and WINDOWOPT are optional parameters. However, if your system is down often, or if you plan to make use of events, you may want to use these parameters:
WINDOWTIME specifies a window of time during which PJS can submit your job. A job can be submitted late because PJS was down or because events were not posted. While the time window is open, PJS may resume operation or the events may be posted. If your job isn't submitted while the time window is open, the action specified by the WINDOWOPT parameter is taken. The WINDOWOPT parameter is discussed below.
The WINDOWTIME parameter requires you to specify a time relative to the value specified in the STRTTIME parameter to determine when the window closes. For example, if submission time is 10:00 and you want to open a time window for two hours, you can enter a relative time value of 2:00. The time window will close at 12:00. For more information on STRTTIME, please refer to 4.1.1.5 How to Specify the Time of Submission.
To specify the time relative to the value entered in the STRTTIME parameter, use the (hh:mm) format, where:
hh is the number of hours. Valid values are 00 through 99.
mm is the number of minutes. Valid values are 00 through 99.
WTIME is a synonym of WINDOWTIME.
WINDOWOPT tells PJS what to do if the job cannot be submitted within the time window specified by the WINDOWTIME parameter. You must specify a value for WINDOWTIME if you plan to use this parameter.
You can specify one of the following:
DISABLE places the job request in DISABLED status. The job request remains on the PJS Request Queue, but it is inactive. PJS cannot submit the job.
ERROR places the job request in ERROR status. The job request remains on the PJS Request Queue until it is modified or deleted. This is the default.
SKIP causes PJS to behave as if the job was submitted. PJS calculates a new run date and time, and resets all job request events. When the new start time value is reached, PJS will attempt to submit the job.
To reactivate a job request in DISABLED or ERROR status, you can specify the ENABLED keyword in the PJREQMOD command. If any of these actions are taken, you may want to enter a greater value for the WINDOWTIME parameter as well as checking to make sure that date and time specifications are still valid. For more information on the PJREQMOD command, please refer to Subsection 4.1.4.
WOPT is a synonym of WINDOWOPT.
4.1.1.12 How to Disable the Job Request
The DISABLED and ENABLED parameters are optional and mutually exclusive:
DISABLED puts the job request in DISABLED status. The job request is placed on the PJS Job Request Queue, but PJS cannot submit the job for execution. The job request is completely inert.
You can use this keyword to hold a place for a job request on the Job Request Queue, and to temporarily prevent job submission. To activate the job request, specify the ENABLED keyword in the PJREQMOD command. For more information on the PJREQMOD command, please refer to Subsection 4.1.4.
ENABLED puts the job request in WAIT status. The job request is placed on the PJS Job Request Queue. PJS can submit the job for execution.
Later, if you want to deactivate the job request but keep the job request on the PJS Job Request Queue for future use, you can specify the DISABLED keyword in the PJREQMOD command. For more information on the PJREQMOD command, please refer to Subsection 4.1.4.
ENABLED is the default.
Use the PJREQDEL command to delete a job request from the PJS Request Queue:
|
PJREQDEL [owner‑ID.]req‑number
|
PJREQDEL begins the PJREQDEL command, which you can use to delete a job request from the PJS Request Queue. PJRD is a synonym of PJREQDEL. You can also specify PJDELETE, PJDEL, or PJD: these synonyms are included for compatibility with PJS 1.0.
The only parameter is the request‑ID which is required. The request‑ID is a positional parameter, and must immediately follow the TSO command name.
4.1.2.1 How to Specify the request‑ID
This parameter is required. For information on how to specify a request‑ID, you can refer to Section 3.2, then use the [owner‑ID.]req‑number format to identify the job request you plan to modify:
owner‑ID specifies who "owns" the job request on the PJS Request Queue.
req‑number is the number PJS assigned to the job request you plan to modify. If you cannot remember the number, use the PJREQLST command, which is described in Subsection 4.1.3.
Use the PJREQLST command to display a list of job requests on the PJS Request Queue:
|
PJREQLST ID([owner‑ID.]req‑number) OWNER(owner‑ID) ALL
SUMMARY DETAIL
|
PJREQLST begins the PJREQLST command, which you can use to display a list of job requests and their characteristics. PJRL is a synonym of PJREQLST. You can also specify PJLIST or PJL: these synonyms are included for compatibility with PJS 1.0.
If you specify PJREQLST alone, PJS will display all of your job requests. Each listing will display the request‑ID, the status of the job request, the next date and time of submission, the frequency, events information, the data set name, and the member name. To display a different set of job requests, or to specify how much information will be displayed, please refer to the following subsections:
4.1.3.1 How to List One Job Request
This parameter is optional:
ID means that you want to list just one job request. To complete this specification, use the ([owner‑ID.]req‑number) format, where:
owner‑ID specifies who "owns" the job request to be listed.
req‑number is the request‑number that PJS assigned to the job request.
For more information on the request‑ID specification, please refer to Section 3.2.
4.1.3.2 How to List All Job Requests For an Owner
This parameter is optional:
OWNER means that you want to list all of the job requests that belong to one owner or user. Because authorization is site‑specific, your site may not allow you to list the job requests that belong to another owner‑ID or user‑ID. To complete this parameter specification, use the (owner‑ID) format, where:
owner‑ID specifies who "owns" the job requests you want to list. For more information on the owner‑ID specification, please refer to Section 3.1.
The default is to list your own job requests.
4.1.3.3 How to List All Job Requests
This parameter is optional:
ALL means that you want to list all existing job requests. Because authorization is site‑specific, your site may not allow you to list the job requests that belong to another owner‑ID or user‑ID.
4.1.3.4 How to Specify the Amount of Displayed Information
Both DETAIL and SUMMARY are optional parameters:
DETAIL displays all available information relevant to each job request. DETAIL displays all SUMMARY information, and provides much more information on submission dates and times. A listing for one job request will occupy more than one line. This is the default when the ID parameter is specified.
SUMMARY only displays the request‑ID, the status of the job request, the next date and time of submission, the frequency, events information, the data set name, and the member name for each listed job request. On most terminals, a listing for one job request will occupy only one line. This is the default when the ALL or OWNER parameter is specified.
Use the PJREQMOD command to change an existing job request on the PJS Request Queue:
|
PJREQMOD [owner‑ID.]req‑number
[JCLDSN(dsname[(member)])]
[NOSAVE|RESAVE|SAVE]
[STRTDATE[(mm/dd/[cc]yy)|(*+ddd)]]
[STRTTIME{(hh:mm[AM|PM])|(*+{hh:mm|hh|:mm})}
[ ONCE | MINUTES[(nnn)] | HOURS[(nnn)] | DAYS[(nnn)] | WEEKDAYS(day1[[,day2]...]) | WEEKS[(nnn)] | EOM[(nn)] | MONTHS[(nn)] | YEARS[(nn)] | CALENDARS([owner‑ID.]cal‑name[,...]) | ADDCALENDARS([owner‑ID.]cal‑name[,...]) | DELCALENDARS([owner‑ID.]cal‑name[,...]) ]
[ENDDATE{(mm/dd/[cc]yy)|(*+ddd)}|NOENDDATE]
[ENDTIME{(hh:mm[AM|PM])|(*+{hh:mm|hh|:mm})}|NOENDTIME
[ EVENTS([owner‑ID.]event‑name [/NOPREPOST|/PREPOST][,...]) | ADDEVENTS([owner‑ID.]event‑name [/NOPREPOST|/PREPOST][,...]) | DELEVENTS([owner‑ID.]event‑name[,...]) | NOEVENTS ]
[POSTEVENTS([owner‑ID.]event‑name[,...])
[RESETEVENTS([owner‑ID.]event‑name[,...])]
[NOWINDOW|WINDOWTIME(hh:mm)]
[WINDOWOPT([DISABLE|ERROR|SKIP])]
[DISABLED|ENABLED]
|
PJREQMOD begins the PJREQMOD command, which you can use to modify an existing job request on the PJS Request Queue. PJRM is a synonym of PJREQMOD. You can also specify PJMODIFY, PJMOD, or PJM: these synonyms are included for compatibility with PJS 1.0.
All parameters are optional, except for the request‑ID. However, to modify the job request, you must specify at least one of the other parameters.
The request‑ID is a positional parameter, and must immediately follow the TSO command name. You can specify the other parameters in any order.
4.1.4.1 How to Specify the request‑ID
This parameter is required. For information on how to specify a request‑ID, you can refer to Section 3.2, then use the [owner‑ID.]req‑number format to identify the job request you plan to modify:
owner‑ID specifies who "owns" the job request on the PJS Request Queue.
req‑number is the number PJS assigned to the job request you plan to modify. If you cannot remember the number, use the PJREQLST command, which is described in Subsection 4.1.3.
4.1.4.2 How to Modify the Data Set Name
This parameter is optional:
JCLDSN specifies a new data set. The current data set specification is replaced.
JCLDSN is short for JCL Data Set Name. This keyword tells PJS that the job request will specify a sequential data set or the member of a partitioned data set. The data set or member contains the job you want PJS to submit for execution.
To complete this parameter, specify the data set name by using the (dsname[(member)]) format, where:
dsname is either the name of a sequential data set or the prefixes for a partitioned data set. Use TSO syntax and site standards to enter this value:
If you specify 'dsname', where dsname is enclosed by quotes, the dsname is treated as a fully qualified data set name.
If you specify dsname, without quotes, the TSO data set prefix is automatically prepended to dsname to form prefix.dsname. In most cases, prefix is your TSO user‑ID.
member is the name of a member of a partitioned data set. If you typed in the name of a sequential data set, omit this specification.
DATASET and DSNAME are synonyms of JCLDSN.
If you change the JCL Data Set, and previously specified the SAVE option to place a copy of job JCL on the PJS JCL Spool, you may need to specify RESAVE to replace a copy of the current job JCL with new job JCL. For more information, please refer to 4.1.4.3 How to Use the PJS JCL Spool.
4.1.4.3 How to Use the PJS JCL Spool
SAVE, NOSAVE, and RESAVE are optional parameters that determine whether a copy of your job JCL is placed on the PJS JCL Spool.
If you place job JCL on the PJS JCL Spool, PJS can provide protection from accidental modification or unauthorized access. However, if your site uses a security package such as RACF, your job JCL may already be protected from intrusive access.
The default for PJS JCL Spool use was determined when PJS was installed. Your site may require you to specify either NOSAVE or SAVE, or you may be able to specify either keyword. If you cannot specify SAVE, you cannot specify RESAVE. For more information, please contact your Site Administrator or the person who installed PJS.
SAVE tells PJS to place a copy of the job JCL on the PJS JCL Spool. When the job is submitted, the JCL saved in the PJS JCL Spool will be executed.
NOSAVE tells PJS not to place a copy of the job JCL on the PJS JCL Spool. When the job is submitted, the JCL will be submitted directly from the data set specified by the JCLDSN parameter.
RESAVE tells PJS to replace the copy of the job JCL on the PJS JCL Spool. If you specify RESAVE for a job request that does not have a copy of job JCL saved, PJS will display an error message.
4.1.4.4 How to Specify a New Date of Submission
This parameter is optional:
STRTDATE tells PJS which day you want to submit the job for execution. The current STRTDATE value is replaced.
If you decide to specify a value, you can specify an absolute date in the (mm/dd/[cc]yy) format or a relative date in the (*+ddd) format. For more information on date specifications, please refer to Section 3.6.
DATE and RUNDATE are synonyms of STRTDATE.
4.1.4.5 How to Specify a New Time of Submission
This parameter is optional:
STRTTIME tells PJS what time you want to submit the job for execution. The current STRTTIME value is replaced.
You can specify an absolute time in the (hh:mm[AM|PM]) format or a relative time in the (*+{hh:mm|hh|:mm}) format. For more information on time specifications, please refer to Section 3.5.
RUNTIME and TIME are synonyms of STRTTIME.
4.1.4.6 How to Specify a New Frequency Option
A frequency option specifies how often PJS is to submit the job for execution. All of the following parameters are optional.
You can specify periodic submission by using one of the MINUTES through YEARS parameters, or you can specify arbitrary submissions by using the CALENDARS parameter. Each time the job is submitted, PJS updates the job request on the PJS Request Queue. If you select MINUTES or HOURS, PJS updates the run time and, if needed, the run date. The other parameters update the run date but not the run time.
In most cases, the current frequency option is replaced. Only the ADDCALENDARS and DELCALENDARS parameters modify, but do not replace the current option.
You can only specify one of the following parameters:
ONCE means that the specified job is submitted for execution only one time. After the job is submitted, PJS places the job request in COMPLETE or ERROR status. The job request remains on the PJS Request Queue until it is deleted or modified. This is the default.
MINUTES(nnn) means that the job is to be submitted for execution every nnn minutes, where nnn is a value from 1 through 999. The default is 1.
For example, MINUTES means that the job is submitted every minute, and MINUTES(30) means that the job is submitted every half‑hour.
MINS is a synonym of MINUTES.
HOURS(nnn) means that the job is to be submitted for execution every nnn hours, where nnn is a value from 1 through 999. The default is 1.
For example, HOURS means that the job is submitted every hour, and HOURS(12) means that the job is submitted every half‑day.
DAYS(nnn) means that the job is to be submitted for execution every nnn days, where nnn is a value from 1 through 999. The default is 1.
For example, DAYS means that the job is submitted every day, and DAYS(3) means that the job is submitted every third day.
DAILY is a synonym of DAYS.
WEEKDAYS means that the specified job is submitted for execution every week on each specified day. To specify weekdays, use the (day1[[,day2]...]) format, where:
day is one of the following:
SUNDAY
MONDAY
TUESDAY
THURSDAY
FRIDAY
SATURDAY
You can use any abbreviation sufficient to distinguish one day from another, for example, TU for Tuesday, SA for Saturday, or F for Friday.
You can specify the days in any order: WEEKDAYS (TUESDAY,MONDAY) is a valid statement, as is WEEKDAYS(MONDAY,TUESDAY).
WKDAYS and DOW are synonyms for WEEKDAYS.
WEEKS(nnn) means that the job is to be submitted for execution every nnn weeks, where nnn is a value from 1 through 999. The default is 1.
For example, WEEKS means that the job is submitted every week, and WEEKS(3) means that the job is submitted every third week.
WEEKLY is a synonym of WEEKS.
EOM(nn) means that the job is to be submitted nn days before the end of each month, where nn is a value from 0 through 27. The default is 0.
If you specify EOM, the job is submitted each month on the last day of the month, for example, May 31 or June 30. If you specify EOM(3), the job is submitted three days before the end of each month, for example, May 28 or June 27.
MONTHS(nn) means that the job is to be submitted for execution every nn months, where nn is a value from 1 through 99. The default is 1.
For example, if you specify MONTHS, the job is submitted each month. If you specify MONTHS(3), the job is submitted once every three months.
Caution: If the number of days in a month is less than the value of STRTDATE, PJS does not submit your job during that month.
For example, if the start date for a monthly job is January 31, PJS assumes you want to submit the job on the 31st of each month and that every month has 31 days. To calculate the next run date, it adds 31 days to January 31: the next run date is February 31st. The job is actually submitted 31 days from January 31. In most years, the next actual run date is March 3, so the job is not submitted during the month of February. The job is next submitted on March 31, so the monthly job is submitted twice in March.
You can avoid this problem by specifying a start date that begins no later than the 28th day of the month. For example, if you specify MONTHS and a start date of January 16, PJS will submit the job on the 16th of each month. For more information on how to specify a start date with STRTDATE, please refer to 4.1.4.4 How to Modify the Date of Submission.
MOS and MONTHLY are synonyms for MONTHS.
YEARS(nn) means that the job is to be submitted for execution every nn years, where nn is a value from 1 through 99. The default is 1.
For example, if you specify YEARS, the job is submitted each year. If you specify YEARS(3), the job is submitted once every three years.
YRS is a synonym of YEARS.
CALENDARS means that PJS will submit the job for execution on the day or days specified in a calendar. This enables you to specify an arbitrary set of submission dates. Before you can use this keyword, you must have created at least one calendar. For information on how to create a PJS calendar, please refer to Section 4.2.
To complete this parameter, specify at least one calendar‑ID with the ([owner‑ID.]cal‑name[,...]) format, where:
owner‑ID specifies who "owns" the calendar.
cal‑name is the name of the calendar.
For more information on the calendar‑ID, please refer to Section 3.3. You can specify up to three calendars in a CALENDARS parameter. If you specify more than one calendar, PJS only submits the job on the dates that are selected on every calendar.
ADDCALENDARS adds at least one more calendar to the calendars already specified for the job request. Before you can use this command, you must have at least one calendar specified for the job request. If you have not already specified a calendar, you can use the CALENDARS parameter to add one. This parameter assumes that at least two calendars exist and are available for your use. For information on how to create a PJS calendar, please refer to Section 4.2.
To complete this parameter, specify at least calendar‑ID with the ([owner‑ID.]cal‑name[,...]) format, where:
owner‑ID specifies who "owns" the calendar.
cal‑name is the name of the calendar.
For more information on the calendar‑ID, please refer to Section 3.3. You can specify up to two calendars in an ADDCALENDARS parameter. Each job request can have up to three calendars specified. If you specify more than one calendar, PJS only submits the job on the dates that are selected on every calendar.
DELCALENDARS deletes at least one calendar from the job request but leaves at least one calendar still specified for the job request. Before you can use this command, you must have at least two calendars specified for the job request.
To complete this parameter, specify at least calendar‑ID with the ([owner‑ID.]cal‑name[,...]) format, where:
owner‑ID specifies who "owns" the calendar.
cal‑name is the name of the calendar.
For more information on the calendar‑ID, please refer to Section 3.3. You can specify up to two calendars in a DELCALENDARS parameter. However, at least one calendar must remain specified for the job request. If you wish to delete all the calendars for a job request, you should specify a different frequency option instead.
4.1.4.7 How to Specify, Replace, or Delete an End Date
These parameters are optional:
ENDDATE tells PJS the date on which it will stop submitting the job for execution.
If you decide to specify a value, you can specify an absolute date in the (mm/dd/[cc]yy) format or a relative date in the (*+ddd) format. For more information on date specifications, please refer to Section 3.6.
The value of the date must be equal to or greater than the value of the date specified or accepted for the STRTDATE parameter.
NOENDDATE removes the ENDDATE value previously specified in a PJREQADD or PJREQMOD command. PJS will continue to submit the job for execution until you delete the job request.
You cannot specify this parameter unless the job request has a value for ENDDATE. If the request has a value for ENDTIME and you specify NOENDDATE, you should also specify NOENDTIME. However, if you specify NOENDTIME, you do not also have to specify NOENDDATE.
ENDTIME and NOENDTIME are discussed in 4.1.4.8 How to Specify, Replace, or Delete an End Time.
4.1.4.8 How to Specify, Replace, or Delete an End Time
These parameters are optional:
ENDTIME tells PJS at what time it is to stop submitting the job for execution. If you plan to use the end time parameter, you must also enter the STRTTIME and ENDDATE parameters.
You can specify an absolute time in the (hh:mm[AM|PM]) format or a relative time in the (*+{hh:mm|hh|:mm}) format. For more information on time specifications, please refer to Section 3.5.
If the values of the STRTDATE and ENDDATE parameters are both equal to the same date, then the value specified for ENDTIME must be greater than the value specified for STRTTIME.
NOENDTIME removes the ENDTIME value previously specified in a PJREQADD or PJREQMOD command. There is no time at which PJS will stop submitting the job for execution.
You cannot specify this parameter unless the job request has a value for ENDTIME. If you specify NOENDDATE, you should also specify NOENDTIME.
4.1.4.9 How to Specify, Add, or Delete Job Request Events
These parameters are optional. To specify or replace all job request events, use EVENTS. To add job request events to existing job request events, use ADDEVENTS. To delete job request events from existing job requests, use DELEVENTS. To delete all job request events, use NOEVENTS.
EVENTS specifies the events for this job request. Any existing events are replaced with those specified. The PJS System Task will submit the job only if all events have been posted. This keyword enables you to create event dependencies that must be satisfied before a job can be submitted.
Before you can use event‑related commands such as PJEVPOST, you must use the PJREQADD or PJREQMOD command to tell PJS that at least one job request event is specified. You do not need to define the event beforehand. Event notification can reside in a job, or you can manage event notification manually. For more information on PJS events, please refer to Section 4.3.
To complete this parameter, use the ([owner‑ID.]event‑name[/PREPOST|/NOPREPOST][,...]) format, where:
owner‑ID specifies who "owns" the event.
event‑name is the name of the event. The event does not have to exist. For more information, please refer to Section 3.4.
/PREPOST means that the job request event will be posted in the job request record whenever the event is posted. PJS doesn't care when the event is posted. This is the default.
/NOPREPOST means that the event will not be posted in the job request record if the event is posted before the job is scheduled for its next submission.
You can specify up to 50 events for a job request. If you plan to post job request events now, you can use the POSTEVENTS parameter, which is discussed in 4.1.4.10 How to Post Job Request Events.
ADDEVENTS adds additional events to the events already specified for the job request. For more information on PJS events, please refer to Section 4.3.
To complete this parameter, use the ([owner‑ID.]event‑name[/PREPOST|/NOPREPOST][,...]) format, where:
owner‑ID specifies who "owns" the event.
event‑name is the name of the event. The event does not have to exist. For more information, please refer to Section 3.4.
/PREPOST means that the job request event will be posted in the job request record whenever the event is posted. PJS doesn't care when the event is posted. This is the default.
/NOPREPOST means that the event will not be posted in the job request record if the event is posted before the job is scheduled for its next submission.
You can specify up to 50 events for a job request. If you plan to post job request events now, you can use the POSTEVENTS parameter, which is discussed in 4.1.4.10 How to Post Job Request Events.
DELEVENTS removes individual events from the job request. For more information on PJS events, please refer to Section 4.3.
To complete this parameter, specify at least event‑ID with the ([owner‑ID.]event‑name[,...]) format, where:
owner‑ID specifies who "owns" the event.
event‑name is the name of the event. The event must be specified on the job request.
For information on how to specify an event‑ID, please refer to Section 3.4.
NOEVENTS removes all the events from the job request. The job request will not be event‑dependent, only time‑dependent: PJS will submit the job for execution whenever the system reaches the calculated value for the date and time of submission.
4.1.4.10 How to Post Job Request Events
This parameter is optional:
POSTEVENTS posts job request events in the current job request. Only job request events in the current job request can be posted by the POSTEVENTS parameter. Identical job request events in other job requests are not posted.
To complete this parameter, specify at least event‑ID with the ([owner‑ID.]event‑name[,...]) format, where:
owner‑ID specifies who "owns" the event.
event‑name is the name of the event. The event must be specified on the job request.
For information on how to specify an event‑ID, please refer to Section 3.4.
Posting an already posted job request event has no effect, and no error is generated.
After the job is submitted, all job request events are automatically reset. If you want PJS to resubmit the job, the job request events must be posted again.
4.1.4.11 How to Reset Job Request Events
This parameter is optional:
RESETEVENTS resets job request events in the current job request. Only job request events in the current job request can be reset by the RESETEVENTS parameter. Identical job request events in other job requests are not reset.
To complete this parameter, specify at least event‑ID with the ([owner‑ID.]event‑name[,...]) format, where:
owner‑ID specifies who "owns" the event.
event‑name is the name of the event. The event must be specified on the job request.
For information on how to specify an event‑ID, please refer to Section 3.4.
Resetting a job request event that has not been posted has no effect, and no error is generated.
4.1.4.12 How to Specify, Replace, or Delete a Submit Window
These parameters are optional:
WINDOWTIME specifies a window of time during which PJS can submit your job. A job can be submitted late because PJS was down or because events were not posted. While the time window is open, PJS may resume operation or the events may be posted. If your job isn't submitted while the time window is open, the action specified by the WINDOWOPT parameter is activated. The WINDOWOPT parameter is discussed below.
The WINDOWTIME parameter requires you to specify a time relative to the value specified in the STRTTIME parameter to determine when the window closes. For example, if submission time is 10:00 and you want to open a time window for two hours, you can enter a relative time value of 2:00. The time window will close at 12:00. For more information on STRTTIME, please refer to 4.1.4.5 How to Specify the Time of Submission.
To specify the time relative to the value entered in the STRTTIME parameter, use the (hh:mm) format, where:
hh is the number of hours. Valid values are 00 through 99.
mm is the number of minutes. Valid values are 00 through 99.
WTIME is a synonym of WINDOWTIME.
WINDOWOPT tells PJS what to do if the job cannot be submitted within the time window specified by the WINDOWTIME parameter. You must specify a value for WINDOWTIME if you plan to use this parameter.
You can specify one of the following:
DISABLE places the job request in DISABLED status. The job request remains on the PJS Request Queue, but it is inactive. PJS cannot submit the job.
ERROR places the job request in ERROR status. The job request remains on the PJS Request Queue until it is modified or deleted. This is the default.
SKIP causes PJS to behave as if the job was submitted. PJS calculates a new run date and time, and resets all job request events. When the new start time value is reached, PJS will attempt to submit the job.
To reactivate a job request in DISABLED or ERROR status, you can specify the ENABLED keyword in the PJREQMOD command. If any of these actions are taken, you may want to enter a greater value for the WINDOWTIME parameter as well as checking to make sure that date and time specifications are still valid. For more information on the PJREQMOD command, please refer to Subsection 4.1.4.
WOPT is a synonym of WINDOWOPT.
NOWINDOW removes the time window from the job request.
ENABLED puts the job request in WAIT status. The job request is placed on the PJS Job Request Queue. PJS can submit the job for execution.
4.1.4.13 How to Enable or Disable the Job Request
The DISABLED and ENABLED parameters are optional and mutually exclusive:
DISABLED puts the job request in DISABLED status. The job request is placed on the PJS Job Request Queue, but PJS cannot submit the job for execution. The job request is completely inert.
You can use this keyword to hold a place for a job request on the Job Request Queue, and to temporarily prevent job submission. To activate the job request, specify the ENABLED keyword.
ENABLED puts the job request in WAIT status. The job request is placed on the PJS Job Request Queue. PJS can submit the job for execution.
You can use this keyword to reactivate a job request that has been placed in DISABLED or ERROR status.
PJS calendar commands enable you to create, delete, list, and modify calendars. The TSO commands are:
PJCALADD which enables you to create a calendar. To create a calendar, select the dates on which you plan to have PJS submit jobs for execution. You must use this command before you specify a calendar in a job request. PJCALADD is discussed in Subsection 4.2.1.
PJCALDEL which enables you to delete a calendar. PJCALDEL is discussed in Subsection 4.2.2.
PJCALIST which displays a list of calendars. The characteristics and values of each calendar are displayed. PJCALIST is discussed in Subsection 4.2.3.
PJCALMOD which enables you to modify an existing calendar. PJCALMOD is discussed in Subsection 4.2.4.
Commands are listed in alphabetical order. Each command description begins with a discussion of the command keyword followed by discussions of command parameters. The parameters are listed in functional order.
Use the PJCALADD command to create a PJS calendar:
|
PJCALADD [owner‑ID.]cal‑name
{ DATES(date|date1:date2[,...]) | EXCLUDE(date|date1:date2[,...]) }
|
PJCALADD begins the PJCALADD command, which you can use to create a PJS calendar. PJCA is a synonym of PJCALADD.
You must use this command to create a calendar before you can specify that a job request will use a calendar. After you create a calendar, you can use the CALENDARS parameter of the PJREQADD or PJREQMOD command. PJS will submit the job for execution on each of the dates specified in the calendar. For more information on these commands, please refer to Section 4.1.
The calendar‑ID is a positional parameter, and must immediately follow the TSO command name. In addition, you must also specify either the DATES or the EXCLUDE parameter.
4.2.1.1 How to Specify the calendar‑ID
This parameter is required. For more information on how to specify a calendar‑ID, please refer to Section 3.3, then use the [owner‑ID.]cal‑name format, where:
owner‑ID specifies who "owns" the calendar.
cal‑name is the name of the calendar.
4.2.1.2 How to Select Dates by Inclusion
This parameter is not required, but you must specify either the DATES or the EXCLUDE parameter.
DATES specifies the dates to be included in the calendar. This parameter assumes that each date from the current system date on is not selected unless it is included.
To specify the dates you wish to select, use the (date|date1:date2[,...]) format, which enables you to specify single dates or ranges of dates. Each date specified can be an absolute date in the (mm/dd/[cc]yy) format or a relative date in the (*+ddd) format. For more information on date specifications, please refer to Section 3.6.
INCLUDE is a synonym for DATES.
4.2.1.3 How to Select Dates by Exclusion
This parameter is not required, but you must specify either the DATES or the EXCLUDE parameter.
EXCLUDE specifies the dates to be excluded from the calendar. This parameter assumes that each date from the current system date on is selected unless it is excluded.
To specify the dates you wish to exclude, use the (date|date1:date2[,...]) format, which enables you to specify single dates or ranges of dates. Each date specified can be an absolute date in the (mm/dd/[cc]yy) format or a relative date in the (*+ddd) format. For more information on date specifications, please refer to Section 3.6.
Use the PJCALDEL command to delete a PJS calendar:
|
PJCALDEL [owner‑ID.]cal‑name
|
PJCALDEL begins the PJCALDEL command, which you can use to delete a PJS calendar. PJCD is a synonym of PJCALDEL.
Deleting the calendar can affect every job request in which that calendar is specified. If you delete the calendar, check the job requests in which the calendar was specified. You may need to use the PJREQMOD command to ensure that PJS will continue to submit the job.
If you want to delete a calendar specification from a job request and leave the calendar intact, use the PJREQMOD command with either the DELCALENDARS parameter, or a different frequency option, such as DAYS(nnn) or EOM(nn). A new frequency specification automatically deletes the current calendar specification. For more information on PJREQMOD, please refer to Subsection 4.1.4.
The only parameter is the calendar‑ID. which is required. The calendar‑ID is a positional parameter, and must immediately follow the TSO command name.
4.2.2.1 How to Specify the calendar‑ID
This parameter is required. For more information on how to specify a calendar‑ID, please refer to Section 3.3, then use the [owner‑ID.]cal‑name format, where:
owner‑ID specifies who "owns" the calendar.
cal‑name is the name of the calendar.
Use the PJCALIST command to display a list of PJS Calendars:
|
PJCALIST ID([owner‑ID.]cal‑name) OWNER(owner‑ID) ALL
SUMMARY DETAIL
|
PJCALIST begins the PJCALIST command, which you can use to display a list of calendars and their characteristics. PJCL is a synonym of PJCALIST.
If you specify PJCALIST alone, PJS will display all of your calendars. Of the dates selected on each calendar, only the next date selected will be displayed. To display a different set of calendars, or to specify how much date information will be displayed, please refer to the following subsections:
4.2.3.1 How to List One Calendar
This parameter is optional:
ID means that you want to list just one calendar. To complete this specification, specify a calendar‑ID in the ([owner‑ID.]cal‑name) format, where:
owner‑ID specifies who "owns" the calendar to be listed.
cal‑name is the name of the calendar.
For more information on the calendar‑ID specification, please refer to Section 3.3.
4.2.3.2 How to List All Calendars for an Owner
This parameter is optional:
OWNER means that you want to list all of the calendars that belong to one owner or user. Because authorization is site‑specific, your site may not allow you to list the calendars that belong to another owner‑ID or user‑ID. To complete this parameter specification, use the (owner‑ID) format, where:
owner‑ID specifies who "owns" the calendars you want to list. For more information on the owner‑ID specification, please refer to Section 3.1.
The default is to list your own calendars.
4.2.3.3 How to List All Calendars
This parameter is optional:
ALL means that you want to list all existing calendars. Because authorization is site‑specific, your site may not allow you to list the calendars that belong to another owner‑ID or user‑ID.
4.2.3.4 How to Specify the Amount of Displayed Information
Both DETAIL and SUMMARY are optional parameters:
DETAIL displays every date selected on each calendar. A listing for one calendar can occupy more than one line. This is the default when the ID parameter is specified.
SUMMARY only displays the next date selected on each calendar. On most terminals, a listing for one job request will occupy only one line. This is the default when the ALL or OWNER parameter is specified.
Use the PJCALMOD command to modify a PJS calendar:
|
PJCALMOD [owner‑ID.]cal‑name
{ DATES(date|date1:date2[,...]) | EXCLUDE(date|date1:date2[,...]) | ADDDATE(date|date1:date2[,...]) | DELDATE(date|date1:date2[,...]) }
|
PJCALMOD begins the PJCALMOD command, which you can use to modify a PJS calendar by adding, deleting, or replacing date specifications. PJCA is a synonym of PJCALADD.
You must specify an existing calendar‑ID and one of the date selection options: The calendar‑ID is a positional parameter, and must immediately follow the TSO command name. You can specify the other parameters in any order.
4.2.4.1 How to Specify the calendar‑ID
This parameter is required. For more information on how to specify a calendar‑ID, please refer to Section 3.3, then use the [owner‑ID.]cal‑name format, where:
owner‑ID specifies who "owns" the calendar.
cal‑name is the name of the calendar.
4.2.4.2 How to Replace All Selected Dates by Inclusion
This parameter is not required, but you must specify one the DATES, EXCLUDE, ADDDATES, or DELDATES parameters.
DATES specifies the dates to be included in the calendar. This parameter assumes that each date from the current system date on is not selected unless it is included. Any previously selected dates are replaced.
To specify the dates you wish to select, use the (date|date1:date2[,...]) format, which enables you to specify single dates or ranges of dates. Each date specified can be an absolute date in the (mm/dd/[cc]yy) format or a relative date in the (*+ddd) format. For more information on date specifications, please refer to Section 3.6.
INCLUDE is a synonym for DATES.
4.2.4.3 How to Replace All Selected Dates by Exclusion
This parameter is not required, but you must specify one the DATES, EXCLUDE, ADDDATES, or DELDATES parameters.
EXCLUDE specifies the dates to be excluded from the calendar. This parameter assumes that each date from the current system date on is selected unless it is excluded. Any previously selected dates are replaced.
To specify the dates you wish to exclude, use the (date|date1:date2[,...]) format, which enables you to specify single dates or ranges of dates. Each date specified can be an absolute date in the (mm/dd/[cc]yy) format or a relative date in the (*+ddd) format. For more information on date specifications, please refer to Section 3.6.
4.2.4.4 How to Add Selected Dates to a Calendar
This parameter is not required, but you must specify one the DATES, EXCLUDE, ADDDATES, or DELDATES parameters.
ADDDATES adds additional dates to the dates already specified for the calendar. Previously selected dates are not affected.
To specify the dates you wish to select, use the (date|date1:date2[,...]) format, which enables you to specify single dates or ranges of dates. Each date specified can be an absolute date in the (mm/dd/[cc]yy) format or a relative date in the (*+ddd) format. For more information on date specifications, please refer to Section 3.6.
4.2.4.5 How to Remove Selected Dates from a Calendar
This parameter is not required, but you must specify one the DATES, EXCLUDE, ADDDATES, or DELDATES parameters.
DELDATES removes the specified dates from the calendar.
To specify the dates you wish to remove, use the (date|date1:date2[,...]) format, which enables you to specify single dates or ranges of dates. Each date specified can be an absolute date in the (mm/dd/[cc]yy) format or a relative date in the (*+ddd) format. For more information on date specifications, please refer to Section 3.6.
PJS event commands enable you to list, post, and reset events. The TSO commands are:
PJEVLIST which displays a list of events. The characteristics and values of each event are displayed. PJEVLIST is discussed in Subsection 4.3.1.
PJEVPOST which enables you to post an event. The event must have been specified in at least one job request by using the PJREQADD or PJREQMOD command. If the event is not posted at time of submission, PJS cannot submit the job for execution. Posting an event satisfies an event dependency in at least one job request. PJEVPOST is discussed in Subsection 4.3.2.
PJEVRSET which enables you to reset an event. This command removes the event posting in at least one job request. If the event is not posted at time of submission, PJS cannot submit the job for execution. Resetting an event can create an event dependency that must be satisfied in at least one job request. PJEVRSET is discussed in Subsection 4.3.3.
Commands are listed in alphabetical order. Each command description begins with a discussion of the command keyword followed by discussions of command parameters. The parameters are listed in functional order.
Use the PJEVLIST command to display a list of PJS events:
|
PJEVLIST ID([owner‑ID.]event‑name) OWNER(owner‑ID) ALL
|
PJEVLIST begins the PJEVLIST command, which you can use to display a list of events and their characteristics. PJEL is a synonym of PJEVLIST.
If you specify PJEVLIST alone, PJS will display all of your events. To display a different set of events please refer to the following subsections:
This parameter is optional:
ID means that you want to list just one event. To complete this specification, specify an event‑ID in the ([owner‑ID.]event‑name) format, where:
owner‑ID specifies who "owns" the event to be listed.
event‑name is the name of the event.
For more information on the event‑ID specification, please refer to Section 3.4.
4.3.1.2 How to List All Events for an Owner
This parameter is optional:
OWNER means that you want to list all of the events that belong to one owner or user. Because authorization is site‑specific, your site may not allow you to list the events that belong to another owner‑ID or user‑ID. To complete this parameter specification, use the (owner‑ID) format, where:
owner‑ID specifies who "owns" the events you want to list. For more information on the owner‑ID specification, please refer to Section 3.1.
The default is to list your own events.
4.3.1.3 How to List All Events
This parameter is optional:
ALL means that you want to list all existing events. Because authorization is site‑specific, your site may not allow you to list the events that belong to another owner‑ID or user‑ID.
Use the PJEVPOST command to post an event:
|
PJEVPOST [owner‑ID.]event‑name
|
PJEVPOST begins the PJEVPOST command, which you can use to post an event. PJEP is a synonym of PJEVPOST.
You must specify an existing event‑ID: The event‑ID is a positional parameter, and must immediately follow the TSO command name.
This command puts the event record into POST PENDING status. After the next scan interval elapses, the PJS System Task posts the job request event in job requests that have reached their date and time of submission, and in job requests that allow preposting. If the date and time of submission was not reached, and the job request event does not allow preposting, the job request event is not posted. After the PJS System Task finishes processing, POST PENDING status is removed from the event record.
If you want to post an event for only specific job requests, you can use the POSTEVENTS parameter of the PJREQMOD command to post the job request event for each job request. For more information on this command, please refer to Subsection 4.1.4.
The only parameter is the event‑ID, which is required. The event‑ID is a positional parameter, and must immediately follow the TSO command name.
4.3.2.1 How to Specify the event‑ID
This parameter is required. For more information on how to specify an event‑ID, please refer to Section 3.4, then use the [owner‑ID.]event‑name format, where:
owner‑ID specifies who "owns" the event.
event‑name is the name of the event to be posted.
Use the PJEVRSET command to reset an event:
|
PJEVRSET [owner‑ID.]event‑name
|
PJEVRSET begins the PJEVRSET command, which you can use to reset an event, i.e., remove the posting from an event. PJER is a synonym of PJEVRSET.
You must specify an existing event‑ID: The event‑ID is a positional parameter, and must immediately follow the TSO command name.
This command puts the event record into RESET PENDING status. After the next scan interval elapses, the PJS System Task resets the job request event in every relevant job request. After the PJS System Task finishes processing, RESET PENDING status is removed from the event record.
If you want to reset an event for only specific job requests, you can use the RESETEVENTS parameter of the PJREQMOD command to reset the job request event for each job request. For more information on this command, please refer to Subsection 4.1.4.
The only parameter is the event‑ID, which is required. The event‑ID is a positional parameter, and must immediately follow the TSO command name.
4.3.3.1 How to Specify the event‑ID
This parameter is required. For more information on how to specify an event‑ID, please refer to Section 3.4, then use the [owner‑ID.]event‑name format, where:
owner‑ID specifies who "owns" the event.
event‑name is the name of the event to be reset.
Copyright İ Northrop Grumman, 1990, 2004. All rights reserved.