|
J
O B A B O T CONVERTING YOUR JOB TO RUN AUTOMATICALLY The first step in automating your job with Jobabot is preparing your code for automation: Jobabot can use your existing code with no changes however, if you do this you will not be getting the full benefit of Jobabot automation. The jobabot ideal is to allow computers to work for you, and have you work less; on the computer that is! A Jobabot script differs from the standard script your running now in three ways. Jobabot scripts have: 1) "Tokens" Briefly, Tokens are substituted for changes you would be required to make to your code every time you run the job. Bullet Proofing is standardization and additional pieces of code that are added to your script to ensure that your job will have the best chance of finishing with a zero return code. Residence on your C: drive is a way of saying that you can edit your code with the word processor on your PC rather than the archaic TSO editor. TOKENS are used in all three files that you will create for monthly automation; JOBS, SCRIPT, and CHK4FILE files. Most tokens take the place of dates in filenames and formula references. All tokens are enclosed in square brackets the legal tokens are YY for year and MM for month. Example a monthly file name BCSS305.RIF.X9709.SAS with tokens it looks like this BCSS305.RIF.X[YYMM].SAS. You can also subtract months from the current date using the minus sign and a numeric value. Like this X[YYMM-3] if in the job file current is set to YY=97 MM=10 then X9707 will be the date used for the file. You can subtract any number of months including -12 for one year, -18 for a year and a half and -24 for two years back. You can use this for input and output files as well as field names in program scripts. You may also use the * with or without brackets in a file name like this: CIP.TIBP.A130D2.MAIN.ARRIVED.D[YYMM-1]* This will cause JOBABOT to check for all files that match in this case there are 4 or 5 files for each month. You can use this feature to locate and use for input groups of files with similar names. (more on this later) Another useful token is PREFIX this takes the place of the user-ID, JOBABOT will replace the token PREFIX with the information in the prefix= aspect of the JOB file. As mentioned previously more than one user id may be listed, in that case JOBABOT always defaults to the first user-ID listed for output files and tries the others in the case of input files in a effort to locate them under different user Ids. Jobabot scripts: JCL scripts that have been standardized, enhanced, and use tokens to replace variable date information that changes with each job run. There are several necessary standard conventions you must follow to have you script work with JOBABOT as well as some important suggestions that will help you program to always run. Listed here are the rules of JOBABOT script writing. Rule #1 use correct user-ID combined with only 1 letter for the job name Example: //BCSS305Z The JCL JOB HEADER information; notice the use of the token PREFIX though not absolutely necessary to use a token here it is important that the user-ID be the correct user-ID that JOBABOT is running under, otherwise it will not be able to check on the job, this error will cause JOBABOT to resubmit your job every time it runs. JOBABOT jobs only get one letter job names thieone below is named “C”. Rule#2 Never use NOTIFY in you JCL job Header There is no NOTIFY statement in a JOBABOT job, NOTIFY here will cause JOBABOT to crash when the NOTIFY message interrupts the ISPF screen display. Example of working JCL header: //PREFIXC
JOB (XXXXX),'OPEN2BUY',MSGCLASS=X,MSGLEVEL=(1,1), //
CLASS=F,TIME=220 Rule #3 use the standardized file label names when building JCL scripts for JOBABOT Examples: //IN1 //IN2 //OUT1 //OUT3 //SORTIN //SORTOUT //DELETE01 Complete examples of each are forthcoming in the text. Rule #4 Always use a delete step before your work step. The delete step helps make your program run more reliably by making sure that there is no output file by the same name as the one listed in your next step. If your program gets a bad re-queue or fails to return a 0 return code it will be run again and some output files from the previous attempt may be left behind. when you program encounters them it will fail with a CAT 2 error. Here is an example of a delete step //STEP00
EXEC PGM=IEFBR14 //DELETE00
DD DSN=PREFIX.RIF.X[YYMM], //
DISP=(MOD,DELETE),UNIT=SYSDA,SPACE=(TRK,0) NOTE: this SAME CODE IS USESED FOR ALL FILES, DISK, AUTO, or TAPE use this type of code in your script before each step. The DSN= file name is the same as the output file in the following work step. When there is no file this step will still not cause your program to fail. Rule #5 One token per line. JOBABOT interprets only one token per line, a second token will be passed as is to the submission script and will cause a JCL error. For example: It is natural to write code as shown by these two lines of SAS: BAL9709=CBAL9709+PBAL9709; FEE9709=
PUR9709+ PAY9709*0.015; But for automation the lines should be broken up into something like this: BAL[YYMM]=
CBAL[YYMM]+
PBAL[YYMM]; FEE[YYMM]=
PUR[YYMM]+
PAY[YYMM]*0.015; INPUT and OUTPUT files can both use the token PREFIX, just remember that the first prefix listed in your job file must be the user-ID that the JOBABOT program is using to sign on with. The first ID listed is default for all files starting with OUT, DELETE, or SORTOUT. For files starting with IN the program first looks for the file name using the first listed user-ID if this file exists then that file name is used. If the file is not found under the first ID and there is more than one listed in the JOB file the program will check for each possible file stopping with the first found file, if no files are found JOBABOT will still try and run the program. If you want your program to run only when all of the input files are available then you must list those files in the CHK4FILE list. (explained in the next section) Here are some examples: //IN1 DD DSN=PREFIX.RIF.CHOICE.X[YYMM].NEWWOBK.R6.SASD, //
DISP=SHR,UNIT=AUTO //IN2
DD DSN=PREFIX.RIF.CHOICE.X[YYMM-12].SAS, //
DISP=SHR,UNIT=AUTO //OUT
DD DSN=PREFIX.RIF.CHOICE.X[YYMM].NEWWOBK.R12.SASD, //
UNIT=SYSDA,DISP=(NEW,CATLG,DELETE), //
SPACE=(CYL,(50,10),RLSE) Rule #6 SAS workspace and sort-space must be large enough to allow for future expansion Many programs require large work and/or sort spaces under SAS. NOTE: The terms WORK SPACE and SORT SPACE under SAS are not at all interchangeable. Unfortunately the defaults offered by SAS for these areas are usually inadequate or may become to small when the amount of data increases by even a little in a subsequent running of your monthly job. Allocating large SAS workspaces like this: //WORK
DD UNIT=SYSDA,SPACE=(CYL,(500,200),RLSE) Can cause your program to time out due to a lack of system resources. When SAS sorts a large data set it may engage the HOSTS sort utility to help it get the job done and dynamically allocate the space for the job, unfortunately there is a limit to how much space can be automatically allocated under this setup. A way to avoid both problems is show in the example below this code is taken from the BKPMIS job and has been run several times on the system: //PRESTEP4
EXEC PGM=IEFBR14
//SASWORK
DD DISP=(NEW,PASS,DELETE),
//
UNIT=SYSDA,
//
DATACLAS=SASMV
//* //STEP04
EXEC PGM=IEFBR14 //DELETEA4
DD DSN=PREFIX.PERFDATA.M[YYMM].SASA, //
DISP=(MOD,DELETE),UNIT=SYSDA,SPACE=(TRK,0) //DELETEB4
DD DSN=PREFIX.RIF.SORTED.M[YYMM].SASA, //
DISP=(MOD,DELETE),UNIT=SYSDA,SPACE=(TRK,0) //* //SAS4
EXEC SAS,REGION=6000K,COND=(0,LT), //
OPTIONS='WORK=WORK SYNCSORT OBS=MAX ERRORS=0' //WORK
DD DSN=*.PRESTEP4.SASWORK,DISP=(OLD,DELETE) //* //SORTWK01
DD UNIT=SYSDA,SPACE=(CYL,(200,100),RLSE) //SORTWK02
DD UNIT=SYSDA,SPACE=(CYL,(200,100),RLSE) //SORTWK03
DD UNIT=SYSDA,SPACE=(CYL,(200,100),RLSE) //SORTWK04
DD UNIT=SYSDA,SPACE=(CYL,(200,100),RLSE) //SORTWK05
DD UNIT=SYSDA,SPACE=(CYL,(200,100),RLSE) //SORTWK06
DD UNIT=SYSDA,SPACE=(CYL,(200,100),RLSE) //SORTWK07
DD UNIT=SYSDA,SPACE=(CYL,(200,100),RLSE) //SORTWK08
DD UNIT=SYSDA,SPACE=(CYL,(200,100),RLSE) //SORTWK09
DD UNIT=SYSDA,SPACE=(CYL,(200,100),RLSE) //SORTWK10
DD UNIT=SYSDA,SPACE=(CYL,(200,100),RLSE) //* //IN1
DD DSN=CIMS.VB.FISCRIF.MCARD.M[YYMM],DISP=OLD,UNIT=AUTO //
DD DSN=CIMS.VB.FISCRIF.MGOLD.M[YYMM],DISP=OLD,UNIT=AFF=IN1 //
DD DSN=CIMS.VB.FISCRIF.VISA.M[YYMM],DISP=OLD,UNIT=AFF=IN1 //
DD DSN=CIMS.VB.FISCRIF.PVISA.M[YYMM],DISP=OLD,UNIT=AFF=IN1 //
DD DSN=CIMS.VB.FISCRIF.CHOICE.M[YYMM],DISP=OLD,UNIT=AFF=IN1 //OUT1
DD DSN=PREFIX.PERFDATA.M[YYMM].SASA, //
DISP=(NEW,CATLG,DELETE),UNIT=AUTO //OUT2
DD DSN=PREFIX.RIF.SORTED.M[YYMM].SASA,LABEL=RETPD=360, //
DISP=(NEW,CATLG,DELETE),UNIT=AUTO,VOL=(,,,12) //SYSIN
DD *
PROC FORMAT;
VALUE $DELQ '*'='0'
'A'='1' 'B'='2' 'C'='3' 'D'='4' 'E'='5' 'F'='6'
'0'='0' '1'='1' '2'='2'
'3'='3' '4'='4' '5'='5' '6'='6'; DATA
OUT1.A;
INFILE IN1 MISSOVER;
INPUT
@1
ACCTNUM PD9.
@016 DBM[YYMM]
PD4.
@020 DELQ[YYMM] $12.
@;
IF DELQ[YYMM]
IN('************') THEN DELETE;
ELSE INPUT
@033 LIM[YYMM] PD3.
@043 STAT[YYMM] $2.
@070 BK[YYMM]
$1.
@138 WO[YYMM]
$1.
@150 CBAL[YYMM] PD4.2
@154 PBAL[YYMM] PD4.2
@235 REG[YYMM]
$1.
@229 STR[YYMM]
PD2.
@447 LBK[YYMM]
$1.
@448 LWO[YYMM]
$1.
@116 SVC[YYMM]
PD3.2
@74
LATE[YYMM] PD3.2
@129 PUR[YYMM]
PD2.
@135
PAY[YYMM] PD2.;
BAL[YYMM]=
CBAL[YYMM]+
PBAL[YYMM];
FEE[YYMM]=
PUR[YYMM]+
PAY[YYMM]*0.015;
PROC SORT DATA=OUT1.A
OUT=OUT2.A; BY ACCTNUM; All of these above steps taken together create one section of JOBABOT JCL code. The PRESTEP4 step pre-allocate the workspace rather than causing the system to look for one large 500 cylinder block this step using DATACLAS=SASMV allows the system to allocate 5 100 cylinder blocks over 5 different disks. Then in order to use this space as a work space in SAS step SAS4 the line //WORK DD DSN=*.PRESTEP4.SASWORK,DISP=(OLD,DELETE) is a referback, note the * it is used to referback to this space from the previous step. The SORTWORK space is much larger than using SORT=999, but as you can see it requires some additional lines in the EXEC and options statement. /SAS4 EXEC SAS,REGION=6000K,COND=(0,LT), // OPTIONS='WORK=WORK SYNCSORT OBS=MAX ERRORS=0' The above lines tells SAS to use the HOST SORT and the lines: And these lines... //SORTWK01
DD UNIT=SYSDA,SPACE=(CYL,(200,100),RLSE) //SORTWK02
DD UNIT=SYSDA,SPACE=(CYL,(200,100),RLSE) etc.... ... define the sort work space. Using these conventions in your script will allow Jobabot to re-write your code with the correct substitutions every time it runs the program. Allocating work and sort space as outlined above will give your program the best chance of running udder adverse system conditions like low disk space and over utilization. Should your job jail or be cancel for any reason, Jobabot will resubmit the job and your program will not abend due to a leftover output file from a previous run as long as you use the delete steps. All of these things combined is the 'bullet proofing'. For me using the TSO editor is just to much of trip back in time. Editing scripts on the PC with a world processor or even the Windows Notepad beats the TSO editor hands down. Using Jobabot should cut your use of the TSO editor down quite substantiality. Saving
your Jobabot JCL script If
you are using WORD to edit your script, check these things as you save
your code: 1)
There must be one blank line as the last line in the script General
tips for Jobabot scripts Ideally
your code has previously been developed and run several times on the
mainframe. When converting to Jobabot automation there is more than one
approach that will work for you. Many
times the code you have been running is broken up into several steps,
and you may even be in the habit of submitting these jobs under the same
name so that they will run one after another.
You ran still do this with Jobabot, simply by giving them the
same job name in the JCL script just as you normally would. Another
approach is to combine all of the separate programs into one long job.
Or simply allow Jobabot to submit each step after the previous
step has created ft's output. These
last two suggestions will take more 'real clock" time to complete
your job, but they allow Jobabot the best chance of completing your job
under adverse system conditions. One
advantage you will have with Jobabot is that your job ran be submitted
in the early morning hours as soon as system files are available and
should your job be canceled Jobabot will resubmit your job even over the
week end or late at night. When
Jobabot runs your job it will 'rewrite' your Jobabot "script' into a
'submission' script. If you
are having problems with your script you can open the resulting
submission script to make sure that Jobabot is correctly interpreting
the tokens. The submission
scripts are in the SUBMIT directory C:\ALPAHA\SUBMIT\JOBNAME.JCL where job name is the name you have given to the job, the Jobabot name not
the JCL name. More about
this in the next section. With your Jobabot script written you are now ready for the easy part, Using Jobabot and Automation with Jobabot Job Control. (previous sections in this web)
|