Using CMS: Contents
Chapter Top
Previous ChapterA VMBF job is a file containing the CMS and CP commands required to perform the desired actions, the same commands that would be typed in interactively if the job were run at the terminal. This file, together with any programs and data files needed, is submitted to VMBF using a special CMS command. The "owner" of the job (the person who submits the job file to VMBF) can monitor its progress and can cancel it at any time.
Once the job is complete, VMBF automatically returns the console log (a file containing all the terminal output generated by the job) to the owner's reader. Other files may be returned if the job contains SENDFILE or other file transfer commands. Any print or punch files generated by the job will automatically be sent to the owner's reader as well, unless the job file contains SPOOL commands redirecting this output.
This manual describes the CMS commands peculiar to VMBF and contains examples of VMBF jobs. It does not contain instructions on how to use package programs such as SAS or SPSS, or how to write programs in FORTRAN or other languages. For that information, please consult the manuals for the particular package or language. The reference material in this manual on particular BATCH commands is derived from the online help files distributed by IBM.
Command syntax:
In this manual certain conventions are used as follows:
<words in angle brackets> optional, may be omitted
if standard value is used
| indicates choice between
left | right
Commands and options can often be abbreviated. Abbreviations are indicated by upper case letters in the command descriptions.
The VM Batch Facility manages a set of virtual machines called task machines. VMBF accepts work from CMS users in the form of job files and schedules this work on its task machines. The scheduling of a job depends on the CLASS attribute the job owner assigns when he or she submits the job file to VMBF. The CLASS of a job indicates the maximum job duration to be allowed, the amount of central memory needed, print limits and the number of magnetic tape drives to be used A user may have no more than 20 VMBF jobs pending at any one time, regardless of the classes used.
Using XEDIT the user constructs a job file containing CMS and CP commands along with (if needed) REXX statements and the BATMOUNT command (BATMOUNT requests that a tape be mounted - see below). The file must be in the form of an EXEC written in the REXX language. Most VMBF jobs are very simple and almost no knowledge of REXX is required. When the job file is created, the user sends it to VMBF using the CMS command BATCH SUBMIT. The user assigns a CLASS to the job as part of the BATCH SUBMIT command.
VMBF is entirely independent of the user's logonid and so does not have automatic access to the user's disk files. All required data and programs need to be transferred along with the job itself using the APPEND option of BATCH SUBMIT (refer to the section on BATCH SUBMIT below).
VMBF assigns a serial number to the job (or the job's owner may assign a name of his/her choice). This number or name can be used to track the progress of the job. VMBF places the job in a queue, according to the job's CLASS. When the job reaches the top of the queue, if the time of day matches the "execution window" defined for the job CLASS and any time/date restrictions placed on the job by its owner, it will be executed by one of VMBF's task machines.
At any time, the user can check on his/her job's progress, using the BATCH STATUS command. The BATCH CHJOB command can be used to change some of the parameters controlling the job's performance (but not the actual contents of the job file), and the BATCH CANCEL command can be used to cancel the job before or during the time it is running. Jobs can be "chained" or linked together, so that one job will not be run until another job is complete or at least has reached a certain stage in its execution. This feature is useful if one job generates information that another job must use.
Upon completion of the job, VMBF will return a console log containing all terminal output, error messages, etc. related to the job. This file will appear in the user's reader and can be moved to the user's personal disk by the RECEIVE command or viewed in the reader by the SHOW command. Refer to the online help for these commands for details. Similarly, print and punch files will be returned to the job owner's reader, unless the job file specifies otherwise. Other output files must be directed to a printer or returned to the user's reader by CMS and CP commands within the job file.
For online information on the VM Batch Facility, type HELP BATCH MENU and browse through the menu items. The bibliography in the final section of this manual lists other sources of information.
In summary, to use the VM Batch Facility perform the following steps:
An EXEC file written using the REXX language can have any valid filename (eight or fewer alphanumeric characters) and must have EXEC as its filetype. For example, a REXX file could have name SAMPLE EXEC A.
The first line in the EXEC must be a REXX comment line, marked by the characters /* in columns 1 and 2, followed by any comment the creator of the file desires, and ending with the characters */ somewhere following the comment text.
The remaining lines in the EXEC file can be a mixture of CMS and CP commands and REXX language statements. In VMBF job files, very few REXX statements are needed. In fact, many VMBF job EXEC files contain nothing except the initial comment line and CMS and CP commands.
In a REXX EXEC, CP and CMS commands should be enclosed in quotes (single or double) to distinguish them from REXX statements.
Refer to the bibliography at the end of this manual for references on REXX. Online reference material is available via the command HELP REXX MENU.
Figure 1: Sample VMBF Job File /* Put a comment here */ trace e 'CP SPOOL PRINT FOR zz' 'BATMOUNT xx RING OUT ON 181 DEN 1600 PASS yyyy' 'SHARE SAS' 'FILEDEF INDATA DISK MYDATA FILE A (PERM' 'FILEDEF MORE TAP1 (RECFM FB LRECL 80 BLOCK 16000 PERM' 'SAS MYSAS' 'PRINT MYSAS LISTING A' 'SF MYSAS SASLOG A TO zz'
Notes:
BATCH SUBMIT SAMPLE (CLASS I APPEND(MYSAS SAS A, MYDATA FILE A)
When the user types in the BATCH SUBMIT command, VMBF responds with an acknowledgement and assigns the job an id number (or the user can assign a name). This name or id can be used to monitor the progress of the job. When the job is complete, the user receives a console log file in his/her reader. Figure 2 contains a sample console log file.
Figure 2: Console File from Sample Job
Job zz nn started on MAINE BATTAPE1 11/05/90 at 15:08:37
Request accepted for tape xx ring OUT on 181 dens 1600
TAPE 0880 ATTACHED TO BATTAPE1 0181
Tape xx has been mounted on your 181 ring OUT
SAS 191 100 as B/B-disk
PRT FILE 0016 SENT TO zz PRT AS ......
File MYSAS SASLOG A1 sent to zz at MAINE on ...
Computer Resource Usage Information
(Date 11/05/90 Time 15:13:19)
Accounting item Amount CRUs
----------------------------------------------
Virtual CPU Time 0.36 0.07
CP Time 0.24 0.05
SIOs 590 0.12
RDR Lines 3 0.00
PRT Lines 21 0.00
PUN Lines 15 0.00
----------------------------------------------
Total 0.24
Current account code - xxxxxx
Job zz nn ended on 11/05/90 at 15:13:19
Notice the accounting information at the end of the log. Users with chargeable accounts may want to save this information so they can keep track of expenditures.
In Figure 3, you will find a simpler example of a VMBF job file plus its accompanying SAS program. Practice using VMBF by typing in these two files and using the BATCH SUBMIT command shown to send them to Batch. Monitor the job's progress using the BATCH STATUS command. On completion of the job you should receive three files in your reader: the console log, the LISTING file and the SASLOG file. Use SHOW to view them, then use DISCARD from the RL display or the PURGE command to delete them.
Figure 3: A Practice Job for You to Try Create a file called EXAMPLE EXEC A containing the following lines (replace "userid" by your logonid). /* A Practice Job */ trace e 'SHARE SAS' 'SAS EXAMPLE' 'SF EXAMPLE LISTING A TO userid' 'SF EXAMPLE SASLOG A TO userid' Create a file called EXAMPLE SAS containing the following lines: OPTIONS LS=80; TITLE 'This example comes from p.742 of the SAS manual'; DATA NORMAL; DO N=1 TO 1000; X=10*RANNOR(53429) + 50; OUTPUT; END; PROC CHART; VBAR X/MIDPOINTS=20 TO 80 BY 5; Now send the job to VMBF by typing the following command: BATCH SUBMIT EXAMPLE (APPEND(EXAMPLE SAS A)
Use the BATCH SUBMIT command to send a job to the VM Batch Facility and have the job run.
Figure 4: BATCH SUBMIT Command Syntax BATCH SUBmit fn> <(options ...> Options: CLass classid APpend (list) ACcount acctid ID jobid WBegin hhmm WEnd hhmm | OPEN DAte mm/dd/yy | dd.mm.yy | HOLD PJ n REstart Yes | No SEconds nnnnnnnn PRint nnnn PUnch nnnn PArms (parm1 parm2 ...) CHain *.jobid.jobstep | userid.jobid.jobstep ERror DUmp | NODump | filename ++
Options can be listed in any order. The abbreviation of each option name is shown in upper case.
The following is the simplest form of the command:
BATCH SUBMIT filename
where "filename" is the filename of the EXEC file containing the job. The job will run in job class A (the default). It will run under the restrictions defined for job class A. These restrictions include:
Enter BATCH QUERY CLASS A or BATLIST CLASS A to review the restrictions of job class A.
BATCH SUBMIT has a number of options which set controls for a job and transfer copies of required files. Figure 4 lists the options.
Example of command (using option abbreviations):
BATCH SUB XYZ (CL I PR 10 ID TEST AP(X DATA A, Y SAS A)
Explanation of the options:
fn ft fm
Type in the fileid of the exec that the VM Batch Facility should run (the filetype "ft" must be EXEC). The filename is the only required entry. If not specified, the filetype and filemode will be defaulted to EXEC and *.
CLass id
"id" is the letter of the job class to which the job should be assigned. The job will line up to run with the other jobs of the class. It will run under the job control restrictions defined for the class.
If this option is omitted, the job is assigned to class A. To review all job classes, enter BATCH QUERY CLASS or BATLIST.
APpend (list)"list" is a list of fileids separated by commas. There is a maximum of 9 fileids which can be in the list. Each fileid should contain the filename, filetype and filemode of the file. When you submit the job, the VM Batch Facility will copy the listed files to VM Batch's A disk.
Instead of a list of files following the option APPEND, you can give the fileid of a single file which contains a list of files. In this way, you can copy more than 9 files to VM Batch. The "append list" file must have filetype APNDLIST and must contain one line for each file to be copied. The files must be listed, one per line with their complete fileid: filename filetype filemode. The append list is case sensitive, so use upper case for the fileids if your disk files have all upper case in their names.
There's no limit on the number of appended files you can list in an APNDLIST file. You can combine one or more APNDLIST files with other appended files as long as you don't list more than nine files in the APPEND option.
If you don't use the option, the VM Batch Facility assumes there are no appended files.
ACcount account
For "account", type in the account number to which the cost of running this job should be charged. If this option is omitted, the job is charged to the owner's default account (use the QUERY ACCOUNT command for information).
ID jobid
For "jobid", type in a name up to eight alphanumeric characters long. The jobid is used to identify the job in messages and in commands such as BATCH STATUS and BATCH CANCEL.
By default, the jobid will be a number based on the time of day the job is submitted.
WBegin hhmm
WEnd hhmm|OPEN Use these options if you want to have a job started only during a certain period of time. Use WBEGIN to set the time of day BEFORE which the job must not be started. The VM Batch Facility will hold the job until that time arrives.
Use WEND to set the time AFTER which the job must NOT be started. If it can't start the job by the WEND time, the VM Batch Facility will hold the job until the WBEGIN time arrives the next day. To have no WEND time, type in OPEN after WEnd. The job will be eligible to start any time after the WBEGIN time.
For "hhmm", type in times in 24 hour notation. For example, use 0900 for 9 AM, 1315 for 1:15 PM, 2359 for 11:59 PM. To have your job started any time during the day, type in 0000 and 2400 for the WBEGIN and WEND times.
DAte mm/dd/yy|dd.mm.yy|HOLD
To set a future date on which your job should be started, type in the date in either of the formats shown. The job will be eligible to start after the WBEGIN time on the date specified.
To have the VM Batch Facility hold a job without starting it, type HOLD after the DATE option. The job will be held without being started until you set a specific start date with the BATCH CHJOB command.
PJ n
For "n", type in a number from 0 to 9. 0 is highest priority, 9 is the lowest priority. Setting a high priority will start a job before other jobs that belong to you, and that are eligible to run in the same task machine, and that have lower priority, and the same start time. (Use BATLIST to view the task machines corresponding to job classes.)
Job priority is set to 9 if you don't use this option.
REstart Yes|No
The default is RESTART YES. The job will be restarted if there is a host system shut down while the job is running.
Type in NO if you do not want to have your job restarted.
Note: You can have your job resume execution from the point at which it was interrupted by using the BATCH JOBSTEP command. For more information, type HELP BATCH JOBSTEP.
SEconds nnnnnnnn
PRint nnnn
PUnch nnnn
These values, if used, override the defaults set for the job's class. The values cannot exceed the maximum for the class. Use BATCH QUERY to see the default and maximum settings. The SECONDS option sets an upper bound on the number of CPU seconds the job may use. If it exceeds the limit the job is canceled. The number, nnnnnnnn, can be from 1 to 99999999 and is in seconds. To limit the number of output records your job sends to the virtual printer, type in the number of records allowed. The number is in thousands, and can be from 0 to 9999. To limit the number of output records your job sends to the virtual punch, type in the number of records allowed. The number is in thousands, and can be from 0 to 9999. The punch limit includes any files sent from VMBF to your reader using SENDFILE or PUNCH.
If your job exceeds any of these limits, it will be automatically canceled.
PARMS (parm1 parm2 ...)
For parm1 parm2 ..., type in up to 18 characters (bytes) of input values. These values will be given to the job when the job starts. The input values must be enclosed in parentheses, but the parentheses and any leading and trailing blanks are not passed to the job.
If the job needs more than 18 characters of parameters, you can modify the job exec to pass parameters to itself. See Appendix A, "Preparing an EXEC" in the VM Batch Facility User's Guide (SC34-4094-1).
If you don't use the option, the VM Batch Facility assumes you have no input values to pass to the job.
In order to receive parameters, the job must also accept parameters passed to it by the VM Batch Facility. To do this, type in the following REXX statement at the start of your job EXEC:
parse arg status owner jobid jobstep rscs node monitor user_parms
This reads the eight parameters that the VM Batch Facility passes to each job. The parameters you specified will be in the "user_parms" parameter.
CHain *.jobid.jobstep|userid.jobid.jobstep
The start of the job will be delayed until the job you identify has reached the point in its processing that you specify.
To chain this job to another job YOU submitted, you can use the first format, beginning with "*".
To chain this job to a job submitted by another user, use the second format, starting with the userid of the owner of the other job.
For jobid, type in the name (jobid) of the other job. If you aren't sure of the name, use the BATCH STATUS command, or ask the job owner or an authorized user of the VM Batch Facility to check the name for you.
Optionally, you can type in a job step as well. If you don't use a job step, your job will start only when the other job has successfully completed. By typing in a job step, you can make this job eligible to start while the other job is still running.
The job step you type in should match the text of a BATCH JOBSTEP command in the other job exec. When that BATCH JOBSTEP command is executed, your job will be eligible to start.
ERror NODump|DUmp|filename
The default is NODUMP and if the job is canceled, no action is taken, although the console log is sent to the owner's reader.
If ERROR DUMP is specified and the job is canceled, all files on the 191 disk of the task machine that is running the job will be disk dumped to you. Having the job exec and other files back may help you determine how far your job ran before it was canceled.
By typing in the name of an exec after ERROR, you can have the exec run if your job is canceled. The exec will run in the same task machine that your job was running in. You can use the exec to send a warning message, do clean up after the cancellation, or other tasks that job execs are allowed to do. However, the exec must be either appended to the job or accessible to the task machine.
++ This option displays a screen containing the current option settings. This acts as a convenient reminder of the BATCH SUBMIT syntax and avoids the problem of a too-long command line.
Figure 5: BATLIST Command BATLIST
Use the BATLIST command to get three kinds of information:
The BATLIST command displays a convenient listing of the currently defined VMBF job classes and their corresponding task machines. The information is similar to that displayed by the BATCH QUERY command, but is easier to read. It is important to remember that the job classes defined on the MAINE, PORTLAND and FARMNTON cpus are not necessarily the same. Furthermore, UNET may adjust the classes and their default characteristics to meet changing load demands. Please check the current situation by entering the BATLIST command before submitting a job.
The sample BATLIST display in Figure 6 may not match the current class settings on any of the cpus. It is for illustration purposes only. Using the information in Figure 6, we see that class A has a default cpu time limit of 30 seconds, a virtual storage size of 4 megabytes and no restrictions on its execution window. Class G has a cpu time limit of 3000 seconds, virtual storage size of 14 megabytes and a start window of 6:00pm to 6:00am. Class I is like class A, except that it permits one tape to be mounted. Class N permits two tapes to be mounted simultaneously.
Figure 6: Sample BATLIST Display VMB Summary for MAINE on 10/30/96 at 14:08:08 Express Jobs: BATCH1 Ready.AEB 0000-2400 CLASS A: Que=0 Run=0 cpu=60 vstor=6144K 0000-2400 CLASS E: Que=0 Run=0 cpu=60 vstor=14336K 0000-2400 CLASS B: Que=0 Run=0 cpu=600 vstor=6144K 0000-2400 Long Jobs: BATCH2 Ready .AECFGT 0000-2400 CLASS A: Que=0 Run=0 cpu=60 vstor=6144K 0000-2400 CLASS E: Que=0 Run=0 cpu=60 vstor=14336K 0000-2400 CLASS C: Que=0 Run=0 cpu=3600 vstor=6144K 0000-2400 CLASS F: Que=0 Run=0 cpu=600 vstor=14336K 0000-2400 CLASS G: Que=0 Run=0 cpu=3600 vstor=14336K 1600-0600 CLASS T: Que=0 Run=0 cpu=10000 vstor=14336K 1800-0400 Long Jobs: BATCH3 Window not open .AECGTDH 1800-0800 CLASS A: Que=0 Run=0 cpu=60 vstor=6144K 0000-2400 CLASS E: Que=0 Run=0 cpu=60 vstor=14336K 0000-2400 CLASS C: Que=0 Run=0 cpu=3600 vstor=6144K 0000-2400 CLASS G: Que=0 Run=0 cpu=3600 vstor=14336K 1600-0600 CLASS T: Que=0 Run=0 cpu=10000 vstor=14336K 1800-0400 CLASS D: Que=0 Run=0 cpu=30000 vstor=6144K 1800-2400 CLASS H: Que=0 Run=0 cpu=30000 vstor=14336K 2200-2400 One Tape Jobs: BATTAPE1 Ready .IJKLM 0700-2400 CLASS I: Que=2 Run=0 cpu=600 vstor=6144K 0000-2400 CLASS J: Que=0 Run=0 cpu=60 vstor=14336K 0000-2400 CLASS K: Que=1 Run=0 cpu=600 vstor=14336K 1600-1000 CLASS L: Que=0 Run=0 cpu=3600 vstor=14336K 1600-0600 CLASS M: Que=0 Run=0 cpu=30000 vstor=14336K 2000-2400 Two Tape Jobs: BATTAPE2 Ready .NOPQ 0900-2400 CLASS N: Que=0 Run=0 cpu=600 vstor=6144K 0000-2400 CLASS O: Que=0 Run=0 cpu=600 vstor=14336K 1600-2400 CLASS P: Que=0 Run=0 cpu=3600 vstor=14336K 1600-0600 CLASS Q: Que=0 Run=0 cpu=30000 vstor=14336K 2200-2400 Special Jobs: BATSPECL Window not open .R 0900-0900 CLASS R: Que=0 Run=0 cpu=60 vstor=14336K 0000-2400 BATAUDIT Window not open DAUDIT 0000-0900 CLASS DAUDIT: Que=0 Run=0 cpu=600 vstor=6144K 0000-0900
Example of BATLIST:
BATLIST CL A NOJ
Explanation of options:
CLass classlist
Type in a class list to see the definitions of those classes in the classlist alone. The classes must have been defined to the VM BATCH Facility. Only those task machines serving any of the classes in the classlist are listed. Classlist must be of the form ".xxxxxxx" for Type 1 (single character) job classes or "xxxxxxxx" for Type 2 (2-8 character) job classes. A single Type 1 class may be specified as "x" (without the "."). ALL classes will be shown if CLass is not entered as an option.Task taskid
Type in a task machine id to see the definition of one task virtual machine. ALL task machines will be shown if TAsk is not entered as an option.DETAIL | NODETAIL Use the NODEtail option to eliminate static information (task machine's classes and window, and class' cpu seconds, virtual storage, and window) from the display. The default is DEtail.
JObs | NOJObs
Use the NOJObs option to eliminate individual job descriptions. The default is JObs.
Note the "windows" defined for each job class. For example, class G in task machine BATCH2 has window 1800-0600. This means that jobs in this class will not be started before 6 o'clock in the evening or after 6 in the morning. Once started, of course, a G class job will run to completion or until cancelled regardless of the window limits.
BATMOUNT is used in VMBF job files to request mounting of a tape. The format of the command is the same as the interactive MOUNT command. The command options are listed in Figure 7, and are explained below. Note the use of BATMOUNT in the sample job EXEC in Figure 1.
Figure 7: BATMOUNT Syntax BATMOUNTtapeid or CANCEL or QUERY where: tapeid : is the one to eight character alphanumeric identifier of the tape to be mounted or canceled. If tapeid is not specified in the BATMOUNT CANCEL command, the first pending tape mount is cancelled. options : can be any or all of the following: Keyword parameters ------- ---------------- RING IN | OUT ON | AS cuu | TAPn DEN 1600 | 6250 | CART PASS password | ? * comments
Example of command:
BATMOUNT TAPE TO9999 ON 181 RING OUT DEN 6250 PASS xxx
Explanation of options:
RING
specifies the status of the file protect ring: IN indicates that the tape may be read or written. OUT indicates read only status. If not specified, OUT is assumed.cuu
is the three character virtual address to be assigned to the attached tape. The symbolic names TAP1 and TAP2 may be used, or the numbers 181 and 182. The default is 181.DEN
specifies density of the tape. Valid densities are 1600, 6250 and CART. The default is 1600.PASSWORD
specifies the appropriate read or write password associated with the given tape number. If not specified, the word 'NULL' is used. If ? is specified, the message 'Enter tape password' is displayed (in the console log) and the correct tape password is read from the stack. See the section "Some Advanced Topics" for details on the stack.comments
are optional information for the operator, such as "This tape is a mini-reel". Note that the '*' and comments, if supplied, must appear last on the BATMOUNT command line.
Use the BATCH STATUS command to review the status of jobs being processed by the VM Batch Facility. Figure 8 lists the options.
Figure 8: BATCH STATUS Command BATCH STATus
Example of command:
BATCH STAT JOB SAMPLE
Explanation of options:
Active
Use this option to get the status of all jobs you have submitted that are queued (but not on hold) or running.ALL
Use this option to get the status of all jobs you have submitted to the VM Batch Facility, including completed jobs and jobs in hold.ALL is the default if you enter BATCH STATUS without any option.
JOB jobid
Enter the jobid of a particular job to get status information on that job alone. You must precede the jobid with JOB if the jobid you assigned to the job is "active", "all", "hold", "old", "queued", "running", or any valid abbreviation of those command options.Hold
Use this option to find out about jobs you've submitted that can't run because of some setup problem with the VM Batch Facility or because the DATE option has been set to HOLD. If you find any jobs that can't run because of a setup problem, contact the VM Batch Facility administrator.Old
Use this option to get information on jobs that have been completed or canceled. You can see the final status of completed or canceled jobs only once. After you have asked for final status, the VM Batch Facility erases the job status record to make way for new jobs.Queued
Use this option to get status information on all of your jobs that have not yet started to run, including these types of queued jobs:
- Jobs that are chained to other jobs.
- Jobs that are waiting for a future start time or start date, or start date, but are not in hold.
Running Use this option to get status messages on all of your job that are currently being executed or have been temporarily halted by a VM Batch Facility authorized user BATCH SUSPEND command.
Use the BATCH CANCEL command to cancel one or more of your own jobs. Figure 9 lists the options.
Figure 9: BATCH CANCEL Command BATCH CANCEL <JOB jobid>|<ALL>|<QUEUED>|<RUNNING>
Example of command:
BATCH CANCEL JOB SAMPLE
Explanation of options:
JOB jobid
Use this option to cancel just one job. For jobid, type in the name of the job to be canceled. To verify the jobid, (or job name), enter this command: BATCH STATUS ALL. You'll see information on all of your jobs; the jobid is the item of information that follows the userid in each status message.ALL
Use this option to cancel all of the jobs you have submitted to the VM Batch Facility. The VM Batch Facility will cancel:
- All of your running and suspended jobs. These jobs will be interrupted and won't be restarted.
- All of your queued jobs, including jobs in HOLD status.
QUEUED
Use this option to cancel all of the jobs you've submitted that haven't begun to run including jobs in HOLD.RUNNING
This option cancels all of your jobs that are currently being run or that have been suspended while running. Queued jobs that are waiting to run will not be affected.
You will receive a message confirming the cancellation of each job affected. If a running job is cancelled, a console log will be sent to your reader. Any jobs chained to a cancelled job will be automatically cancelled, unless the chained jobs have been started. Cancelled jobs will not be restarted (see RESTART option of the BATCH SUBMIT command). If the ERROR option was specified, the error action will be performed when the job is cancelled.
Use the BATCH CHJOB command to change the job control options of a job you have submitted. Figure 10 lists the options.
Figure 10: BATCH CHJOB Command BATCH CHJob jobid (options Options: CLass classid APpend (list) ACcount acctid ID jobid SEconds nnnnnnnn PRint nnnn PUnch nnnn WBegin hhmm WEnd hhmm | OPEN DAte mm/dd/yy | dd.mm.yy | HOLD PArms (parm1 parm2 ...) CHain *.jobid.jobstep | userid.jobid.jobstep REstart Yes | No ERror DUmp | NODump | filename PJ n ++
Example of command:
BATCH CHJOB JOB SAMPLE ( PR 20 PJ 5
Explanation of options:
To change any job control option, you must specify the jobid assigned to your job when you submitted it. The jobid can be chosen by you or generated automatically by VMBF. Refer to the description of the ID option of the BATCH SUBMIT command. All the options of the BATCH CHJOB command are described in detail in the section on BATCH SUBMIT. BATCH CHJOB can be used to alter those settings.
Use the BATCH QUERY command to get information on job classes and task machine status. This information is similar to that displayed by the BATLIST command, but in a different format. It also includes some items that BATLIST does not report, such as print and punch limits.
Figure 11: BATCH QUERY Command BATCH Query|
Example of command:
BATCH Q T ALL
Explanation of options:
Class ALL Use this option to see the definitions of all job classes defined. ALL is the default if you enter BATCH QUERY CLASS without specifying a value.
Class classid Type in the name of a particular class to see the definition of that class alone. The class must have been defined to the VM Batch Facility.
Task ALL Enter ALL to get information on all VM Batch Facility task virtual machines. ALL is the default if you enter BATCH QUERY TASK without specifying a value.
Task Hold Enter HOLD to find out which task machines have been temporarily halted by a VM Batch Facility authorized user. A task machine that's in HOLD status can't start any jobs until a VM Batch Facility authorized user restarts it.
Task REady READY returns information on task machines that are ready to run jobs but do not currently have jobs to run or task machines whose start time windows are not open.
Task Running Use this option to get information on task machines that are currently executing jobs or are suspended.
Task userid
Enter the userid of a task machine to get status information on that machine alone.
Figure 12: BATCH JOBSTEP Command BATCH Jobstep yourtext
Use the BATCH JOBSTEP command to accomplish any of these tasks:
If a job does not have BATCH JOBSTEP commands, the VM Batch Facility can report only when the job starts and when it ends in status messages. If you put BATCH JOBSTEP commands into the job exec, the VM Batch Facility can report when each command is executed as the job runs.
The RESTART YES option restarts a job from the beginning if the job is interrupted by a system shut down. If you add BATCH JOBSTEP commands to your job exec, you can have a restarted job resume execution from the last BATCH JOBSTEP command that was executed.
The CHAIN option lets you specify a particular job step as the starting point for a chained job. The VM Batch Facility can start the chained job as soon as the job it is chained to has executed the specified BATCH JOBSTEP command. Without BATCH JOBSTEP commands, chained jobs must wait until the job has finished running.
Usage Notes
- Getting information on the job step that has been executed: Use the VM Batch Status command to obtain job step information. The "Step" heading in the message shows the text of the last BATCH JOBSTEP command to be executed. As other BATCH JOBSTEP commands are executed, the job step text will be updated.
- Using BATCH JOBSTEP commands with chained jobs: If other jobs may be chained to a job step of a job of yours, be sure that the numeric value of the BATCH JOBSTEP text in the job rises from one BATCH JOBSTEP to the next. If the value of the job step text, in EBCDIC terms, does not rise from one job step to the next, a chained job may become eligible to start too early.
To determine whether a chained job can start, the VM Batch Facility compares the job step specified for the chained job with the current job step of your job. It uses the EBCDIC values of the job steps to make the comparison. The chained job becomes eligible to start if the job step specified in the CHAIN option is less than or equal to the current job step of your job, in terms of EBCDIC value.
Example of command:
BATCH J SASdone
Explanation of options:
yourtext
Type in a job step message from 1 to 8 characters long. It can include numbers and letters. It cannot have any blank spaces in it.
Use only a single BATCH JOBSTEP command, if possible, in jobs to which other jobs will be chained.
Keep job step text simple and use a standard format throughout a job, as in BATCH JOBSTEP POINTA, BATCH JOBSTEP POINTB, and so on.
Keep the sequence of values of EBCDIC code in mind. The numeric values of letters and numbers in EBCDIC code are arranged in this way:
"A" rising to "Z".
"0" has a higher value than "Z", rising to "9", which has the highest EBCDIC value of the numbers and letters that can be used in a BATCH JOBSTEP command.
A VMBF job must not ask for keyboard input, since there is noone to enter any. If a job "puts up a read request" the job's owner must have supplied the equivalent of keyboard input in another form. If no such data is supplied, the job will hang until it is eventually cancelled.
If you wish to run a program in VMBF which is normally executed interactively, and if this program expects interactive keyboard input, you must place the expected input in the "stack" using special REXX statements. The stack is a storage area where input lines can be stored in advance. If a program attempts to read from the keyboard, and there is material in the stack, the input will be drawn from the stack. .sp;Data can be stored in the stack in last-in-first-out order or in first-in-first-out order. The LIFO order requires that that a user "think backwards" - i.e., store material in the stack in reverse order. The FIFO order is more natural for most people.
The REXX statements to store material in the stack are queue and push, where queue uses FIFO and push uses LIFO. The following example EXEC uses the stack to store four responses which the SAS program requires. If the SAS program were run interactively, each of these four responses would be typed on a separate line.
/* This VMBF job uses the REXX queue statement */ trace e 'SHARE SAS' 'FI INDATA DISK MYDATA FILE A (PERM' queue 'SMITH-BOX9999' queue '5500' queue ' ' queue 'YES' 'SAS MYSASG' 'SF MYSASG SASLOG A TO IX9999'
The stacked keyboard input appears in the above sample job in four consecutive queue statements. The material must be placed in the stack before the SAS program is run. For more information on the REXX queue and push statements and other related REXX statements, refer to the manuals or online help.
VMBF will always return a console log to your reader when a job is complete (or cancelled). Users of older batch systems had to include a CP SPOOL command to accomplish this, but this is not necessary in VMBF. VMBF also automatically directs PRINT and PUNCH output to the job owner's reader. This means that a PRINT command in a VMBF EXEC file will not cause a file to be printed. Instead, the file will be sent to the owner's reader.
If you want to use PRINT commands to obtain hardcopy, or in some other way direct job output to a real printer, then you must include a CP SPOOL command in your VMBF job file to override the automatic spooling of print files. One format that could be used is:
'CP SPOOL PRINT FOR logonid ROUTE printer'
where 'logonid' is the job owner's id and 'printer' is a remote printer name. Any print files generated by the job will be sent to the named printer with the owner's logonid on the cover page. Other SPOOL options such as COPY and FORM can always be included.
For more information on the VM Batch Facility:
Online help: type HELP BATCH MENU
"VM Batch Facility User's Guide," IBM SC34-4094
For more information on REXX:
Online help: type HELP REXX MENU
"VM/SP System Product Interpreter User's Guide," IBM SC24-5238
"VM/SP System Product Interpreter Reference," IBM SC24-5239
"VM/SP System Product Interpreter Reference Summary," IBM SX24-5126
"Quick Guide to REXX," UNET Document 186
|
Using CMS: Contents |
Chapter Top |
Previous Chapter |
| Topic Index | Frequently Asked Questions | Document List | Return to User Services Home |