--------------------------- Week 13-A Notes for DAT2330 --------------------------- -Ian! D. Allen - idallen@idallen.ca Remember - knowing how to find out the answer is more important than memorizing the answer. Learn to fish! RTFM! (Read The Fine Manual) These notes are largely based on lectures by Harold Smith: - DAT2330 - Harold Smith Class - Wed Feb 9, 2000 Strategy for handling complex JCL specifications ------------------------------------------------ Specifications for JCL aren't always in the best order to write JCL: (e.g. sometimes it says at the top of the specification to delete or catalog a tape "when you are done", i.e. at job end) Strategy: Cross out every clause in the job specification as you add it to the JCL. You're done when no un-crossed-out lines remain! Don't copy JOB and SYSOUT queue letters onto your crib sheet for tests - the queue letters and details will change for each test. -------------------------------------------------- Review the homework - "MVS JCL Example 2 Homework" -------------------------------------------------- You can use the same DDnames in different steps (not in the same step); the DDnames are compiled into the programs used in the EXEC statement. Coding the JCL for Example 2 Homework ------------------------------------- From last week: Review: JCL syntax Review: JCL Errors Review: Run-Time Errors Review: IBM Utility IDCAMS Review: IDCAMS DCB handling for input/output Review: Cataloged and Uncataloged datasets Review: New Parameters: MSGCLASS=, MSGLEVEL=, PRTY=, TYPRUN= DCB=(DSORG=,LRECL=,BLKSIZE=,RECFM=) LABEL=(,AL), UNIT=, VOL=SER= Step One -------- JCL comments tell what guesses I made and how my guesses affect my JCL coding. Comments should also say why you did not code something exactly as given in the job specification. (State your assumptions!) You can put the comments at the top of your job, or you can put them in front of the step in which they apply. //* The "GO" step name is a guess. (It was not specified.) //* If I can't find documentation to confirm it, I will use MSGLEVEL=(1,1) //* to get a PROC listing so that I can see the actual PROC step name. //* An incorrect guess will produce a JCL error. //* There are no DDname guesses in the homework. //* ANSI tapes have a maximum block size of 2K (2048 bytes). //* Depending on the JES version, highest PRTY may be 14 or 15. //* I decided to send all unspecified SYSOUT to the hold queue for TSO viewing. //* (This was not in the job specification.) //* //COBTSTH2 JOB 03F$HW2,'MY NAME',CLASS=D, - positional parameters must always be first, and in the given exact order - keyword parameters can vary in order (MVS doesn't care) - see the jclStyle.txt file for style issues on choosing a good order - pick job class closest to start of alphabet (D usually better than E) - don't pick too small, or your job will get thrown out - don't pick too large, or your job will wait for resources that it will never need, or will get stuck behind a huge job using many resources - which queue does CLASS=D apply to? - to the JES job queue, *not* the SYSOUT printer queue - choose CLASS=D based on overall resource requirements of this job - flow diagram is good to see how many simultaneous tape drives - count the maximum tape drives used *by one single program*; not the total number of tape drives in all steps - on the job, you may be told to write your JCL with only one JCL parameter per line (using continuation card syntax) - makes editing (and commenting) the JCL easy - uses up a lot of vertical screen space, though... - let's try it in this file here - one parameter per line... // MSGCLASS=D, - we decide to send all unspecified output, including JCL, to the HOLD queue "D" for TSO viewing - since this was *not* in the specification, I use a JCL comment to indicate what I am doing and why // MSGLEVEL=(2,1), - this specifies the level of detail of JES messages - job specifications say not to show PROCs; but, we don't know if step name GO.xxx is correct, so we should probably ask for full PROC expansion: (1,1) the first time we run this, and code TYPRUN=SCAN too (see below) - "input stream JCL" means the JCL that we supply (not from the PROC) - when learning parameters, go to the IBM JCL Reference Manual first - ask in class or the news group if the manual is unclear - (2,0) means do list my JCL, but not the PROCs JCL (0,1) means print all device allocation messages (e.g. tape drives used) // PRTY=14, - request highest priority in the job queue - in which job queue? in the CLASS=D queue - PRTY differs betwen JES2(max 15) and JES3(max 14) - put this on your crib sheet for tests - pick 14 (JES3) to be safe here - on the job: ask - higher priority may cost more; may be restricted // TYPRUN=SCAN - "SCAN" means send JCL to JES and *only* scan for JCL errors - want to pre-scan the JCL so that final submission will run, when scheduled - SCAN means do not run any programs or allocate any datasets - SCAN does not detect run-time errors! - SCAN only detects JCL errors! - this will confirm that our "GO.xxx" step guess is right (or wrong) - guessing a step name incorrectly is a JCL error (no program has to run for JES to detect the error) //CREATAPE EXEC PGM=IDCAMS - IDCAMS: code the four DD names with instream data last (style preference): //SYSPRINT DD SYSOUT=D - sysout queue "Dog" is the HOLD queue - pick up the output via TSO //OUT DD DSN=MYTSTDAT,DISP=(NEW,PASS), // DCB=(BLKSIZE=2000,RECFM=FB), - I invent the new output dataset name; next step will use same name - real-world dataset names are much longer, e.g. DSN=XS02947.SYSALL.GLOBAL.STAGE1.COPYBOOK - a new dataset needs to have its DCB set up when first opened - either the program or the JCL has to set up the new output DCB - IDCAMS defaults the output DCB to be a copy of the input DCB - we can over-ride the defaults if we don't like them (and we don't) - instream data always appears to be punch card data - instream data is always: DCB=(DSORG=PS,LRECL=80,BLKSIZE=80,RECFM=F) - physical sequential, 80 characters wide, fixed with no blocking - IDCAMS output DSORG defaults to be a copy of the DSORG of the instream data (PS); don't need to specify DSORG for output - IDCAMS output LRECL defaults to be a copy of the LRECL of the instream data (80); don't need to specify LRECL for output - NOTE: if your DCB specification disagrees with what the program is actually using to write the data, your job dies! - don't specify DCB parameters that have good defaults! - IDCAMS output BLKSIZE defaults to be a copy of the BLKSIZE of the instream data (80 - no blocking!); this is very inefficient for tapes - writing only 80 bytes at a time on the tape means many between-block gaps - must re-block the tape output (BLKSIZE) to avoid inter-block gap waste - must change RECFM from F (fixed) to FB (fixed with blocking) - ANSI label tape requires a BLKSIZE between 18 and 2048 bytes - choose a good block size for an ANSI label tape - Calculate max block size: integer(2K / 80) * 80 = 2000 bytes - we must always specify RECFM=FB with BLKSIZE= // LABEL=(,AL), - ANSI tape label specification is the second *positional* parameter - what is the first parameter, and what is its default value? - don't specify the first parameter; let it default - this is the only special LABEL we learn in this course - IBM defaults to creating the tape with IBM standard labels if you don't specify ANSI "AL" labels // UNIT=SYSSQ,VOL=SER=211111 - the request is for a specific tape number, must not use UNIT=SCRATCH - a "SCRATCH" tape is a blank one selected by the operator - UNIT and VOL=SER occur together for specific uncataloged datasets - cataloged datasets don't need any of this - the UNIT and VOL/SER info is stored in the system catalog - may be used for DASD as well as tape, e.g: UNIT=DASD,VOL=SER=USRPK001 - except that VOL=SER is rare on DASD unless it is a removable disk //SYSIN DD * REPRO INFILE(IN) OUTFILE(OUT) /* IDCAMS SYSIN control statements: - the control statements tell IDCAMS what to do, how to do it - IDCAMS can do many things - we have to select the REPRO operation - IDCAMS lets us select our own DDnames for the files to copy - the DDnames in the REPRO statements must match the DDnames in the JCL - (this is the only place in this course where we get to pick our own DDnames - everywhere else we must use the DDnames specified in the program we are using in the EXEC statement.) //IN DD * ... About 1000 test records go here. The syntax of these lines is ... dictated by the input requirements of the COBOL program reading them. ... You would type in these records using your TSO editor, or copy ... them instream here from somewhere else. /* - above are the usual IDCAMS input statements, with instream data last - make sure that the INFILE and OUTFILE names match your JCL DDnames - an error in the syntax of the REPRO statement is not a JCL error; it would not be noticed until IDCAMS runs to read the REPRO statement Step Two -------- Step two is a Compile, Link, and GO step using a PROC. A C.L.G.-type PROC contains (at least) three internal steps to run the three programs needed. Review: Compile, Link, and Go Review: Using Procedures (EXEC PROC=) Review: MVS Required Ordering of DD Statements (must follow PROC step order) Review: Documenting your guesses in JCL comments //* NOTE: I am guessing the PROC "GO" step name; it was not provided. //* An incorrect guess will produce a JCL error (not run-time). //* //CLGTEST EXEC PROC=COBCLG - document your guesses! - an incorrect internal step guess is detected by JES when it tries to merge your JCL with the JCL in the PROC you are using - an incorrect internal step guess is a JCL error - use the correct MSGLEVEL to get a PROC listing to find the right name //COB.SYSIN DD * ...the actual COBOL program source goes instream here... ...remember to make notes like this about your instream data... /* - the PROC we are using has the COB step before the GO step, so in our JCL we must code all our COB step JCL before the GO step JCL - this is an MVS rule - JCL must appear in PROC step order //GO.PRINT DD SYSOUT=D - must hold this output for TSO (using sysout queue "Dog") - doesn't say how much output will appear - guess that it will be a hard copy of all the transactions? - guess this output will be about 1000 lines (for 1000 transactions)? //GO.UPDTDSK DD DSN=TSTMAST,DISP=(OLD,KEEP) - a cataloged dataset doesn't need UNIT or VOL (they're in the catalog) - cataloged datasets are really easy to use! - an update step means that the dataset must already exist - an existing dataset doesn't need a DCB (it's in the dataset label) - you only need a DCB for a *NEW* output dataset - the specifications didn't give us a disposition for this dataset - KEEP or PASS are the only reasonable choices; we choose KEEP (it doesn't make sense to update a file and then delete it!) //GO.XACTLG21 DD DSN=TRANSLOG,DISP=(NEW,PASS), // DCB=(BLKSIZE=4080,RECFM=FB), - I choose a name for this NEW dataset (the name was not specified) - a "choice" is not a "guess"; as long as the choice is syntactically correct, I can choose any name I want; it doesn't have to be "correct" - this is a *NEW* output dataset - either the program or the JCL must specify the four DCB parameters: DSORG, LRECL, BLKSIZE, and RECFM - the COBOL program source specified everything in DCB except the blocking - choose a good block size for an IBM labelled (not ANSI) tape - integer(4K / 20) * 20 = 4080 bytes (recall 4K = 4*1024) - always code RECFM=FB with BLKSIZE= - don't specify parameters that aren't needed (DSORG, LRECL) - don't generate conflicts with program-specified parameters - we shouldn't catalog this tape until we are finished with it - if you specified CATLG instead of PASS, the tape would be dismounted! - just PASS the tape to the next step and catalog it later // UNIT=SYSSQ,VOL=SER=212222 - the request is for a specific tape number, must not use UNIT=SCRATCH - a "scratch" tape is a blank one selected by the operator - UNIT and VOL=SER occur together for specific uncataloged datasets - cataloged datasets don't need any of this - the UNIT and VOL/SER info is stored in the system catalog //GO.TPIN DD DSN=MYTSTDAT,DISP=(OLD,KEEP) - this is the test data on tape: use the same dataset name as previous step - a PASSed dataset doesn't need any LABEL, DCB, UNIT, or VOL specified - PASSed datasets, like cataloged datasets, are very easy to use! - only need DSN and DISP for PASSed datasets - specification says to keep the tape; but, don't catalog it - putting things in the system catalog costs money Start of Step Three ------------------- Use IDCAMS to display the transaction log on the printer. This is a standard IDCAMS copy (REPRO) operation; so, it will use the standard four IDCAMS DDnames: //DISPTRAN EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=D - I choose to hold the IDCAMS status/error messages for TSO (The job specification didn't say what to do.) //OUT DD SYSOUT=B - need a sysout queue for about 1000 lines of output //IN DD DSN=TRANSLOG,DISP=(OLD,CATLG) - specification says to catalog this tape after last use; this is last use //SYSIN DD * REPRO INFILE(IN) OUTFILE(OUT) /* // - standard IDCAMS control statement to copy IN to OUT - remember the leading blank before REPRO! End of job (remember the //). Additional Practice: Practice Lab1 (lab1.txt, lab1notes.txt, lab1answer.txt). To get a listing of just the JCL from this file, use the Unix command: $ grep '^/' thisfile Look at the course outline or the weekly.txt file (under JCL Notes) to see what we do next. Details on each of the parameters can be found by looking up the parameter in the IBM MVS JCL Reference Manual index.