Week 13 Notes for DAT2330 - Ian Allen Supplement to Text, outlining the material done in class and lab. Remember - knowing how to find out the answer is more important than memorizing the answer. Learn to fish! RTFM![*] ([*] Read The Fine Manual) ==================================== MVS - O/S 390 - Job Control Language ==================================== -IAN! idallen@ncf.ca July 2001 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 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 for tests - they will change! Today: review the homework - "MVS JCL Example 2 Homework" --------------------------------------------------------- Review: Flow Diagram Review: JCL Errors Review: Run-Time Errors You can use the same DDnames in different steps (not in the same step) Coding the JCL for Example 2 Homework ------------------------------------- Review: JCL syntax Review: New Parameters Step One -------- Review: IBM Utility IDCAMS Review: IDCAMS DCB handling for input/output Review: Cataloged and Uncataloged datasets IDCAMS SYSIN control statements - tell IDCAMS what to do, how to do it - IDCAMS can do many things - IDCAMS lets us select our own DDnames - as long as they match the REPRO statements - (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.) JCL comments tell what guesses I made and how my guesses affect my JCL coding. //* 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. //* THERE ARE NO DDNAME GUESSES. //* DEPENDING ON THE JES VERSION, HIGHEST PRTY MAY BE 14 OR 15. //* ANSI TAPES HAVE A MAXIMUM BLOCK SIZE OF 2K (2048 BYTES). //* I DECIDED TO SEND ALL UNSPECIFIED SYSOUT TO THE HOLD QUEUE FOR TSO VIEWING. //* //COBTSTH2 JOB 2111HW,'MY NAME',CLASS=D, - positional parameters must always be first, and in this order - keyword parameters can vary; but, use the order I give so that you remember them and I can mark them - pick job class closest to start of alphabet (D usually better than E) - 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 - you may be told to write your JCL with only one parameter per line - makes editing (and commenting) the JCL easy - uses up a lot of screen space, though... - let's try it... // MSGCLASS=D, - we decide to send all unspecified output, including JCL, to the HOLD queue "D" for TSO viewing // 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 PROC expansion: (1,1) - "input stream JCL" means the JCL that we supply (not from the PROC) - when learning parameters, go to the book first - ask in class or the news group if the book is unclear - (2, means do list JCL, but not the PROCs. ,1) means print all allocation messages // PRTY=14, - request highest priority in the job queue - in which queue? in the CLASS=D queue - PRTY differs betwen JES2(15) and JES3(14) - 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 - do not run any programs or allocate any datasets - does not detect run-time errors! - this will confirm that our "GO.xxx" step guess is right (or wrong) //CREATAPE EXEC PGM=IDCAMS - IDCAMS: code the four DD names with instream data last (prof preference) //SYSPRINT DD SYSOUT=D - sysout queue "Dog" is the HOLD queue - pick it up via TSO //OUT DD DSN=MYTSTDAT,DISP=(NEW,PASS), // DCB=(BLKSIZE=2000,RECFM=FB), - I invent the dataset name; next step will use same name - instream data appears as punch card data - 80 characters - DSORG defaults to instream (PS); don't need to specify it - LRECL defaults to instream (80); don't need specify it - if your specification disagrees with actual data, your job dies! - must re-block the tape output to avoid inter-block gap waste - need to set up fixed blocking (FB) - ANSI label insists on BLKSIZE between 18 and 2048 bytes (p.227) - choose a good block size for an ANSI label tape - int(2K / 80) * 80 = 2000 bytes // LABEL=(,AL), - ANSI Label selection is second *positional* parameter - what is the first parameter, and what is its default value? // UNIT=SYSSQ,VOL=SER=211111 - request is for specific tape number, must not use UNIT=SCRATCH - UNIT and VOL=SER occur together for specific uncataloged datasets - even used for DASD, e.g: UNIT=DASD,VOL=SER=USRPK001 - except that VOL=SER is rare on DASD //SYSIN DD * REPRO INFILE(IN) OUTFILE(OUT) /* //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. /* Step Two -------- Review: Compile, Link, and Go Review: Using Procedures Review: Ordering of DD Statements Review: Documenting your guesses //CLGTEST EXEC PROC=COBCLG //* NOTE: I AM GUESSING THE PROC "GO" STEP NAME; IT WAS NOT PROVIDED. - document your guesses! //COB.SYSIN DD * ...cobol program source goes instream here... /* - proc COB step JCL must come before proc GO step JCL //GO.PRINT DD SYSOUT=D - must hold this 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) - update step means dataset already exists - existing dataset doesn't need DCB (it's in the dataset label) - unspecified disposition: KEEP is the only reasonable choice (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 the name for this NEW dataset (name was not specified) - COBOL program specified everything in DCB except blocking - choose a good block size for an IBM (not ANSI) tape - int(4K / 20) * 20 = 4080 bytes - 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 - just PASS it to the next step // UNIT=SYSSQ,VOL=SER=212222 - request is for specific tape number, must not use UNIT=SCRATCH - UNIT and VOL=SER occur together for specific uncataloged datasets //GO.TPIN DD DSN=MYTSTDAT,DISP=(OLD,KEEP) - this is the test data on tape: same dataset name as previous step - a passed dataset doesn't need any LABEL, DCB, UNIT, or VOL specified - specification says to keep the tape; but, don't catalog it Start of Step Three ------------------- Use IDCAMS to display the transaction log on the printer. //DISPTRAN EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=D - I choose to hold the IDCAMS status/error messages for TSO //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 //SYSIN DD * REPRO INFILE(IN) OUTFILE(OUT) /* // End of job. To get a listing of just the JCL from this file, use the Unix command: $ grep '^/' thisfile Look at course outline or MVSweekly.txt file to see what we do next; read ahead.