Week 14 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 16, 2000 Misc Notes ---------- BLKSIZE= - use up to 4K (to match size of IBM paging device) - but ANSI tapes allow only up to 2K - best choice depends on output device - Kevin says "half track" blocking is also recommended in "real world" Mainframe Paging - Page DataSet - nucleus (O/S kernel) sits in memory ("memory resident") - program has an address space (e.g. 4GB) - program is some number of pages of, say, 4KB each - RAM divided into pages of same size - program pages are "paged" into RAM and "swapped" out to disk - IBM calls the paging disk space the "paging dataset" - win386.swp is the Win9x "paging dataset" - "page fault" happens when a swapped-to-disk page is needed in memory - must stop the program and fetch the page from disk to memory - may cause some other page in memory to be swapped to disk - Windows: Blue Screen Of Death (BSOD) "invalid page fault" - Win9x loses track of the page on disk and can't find it! - "working set" - the minimum number of RAM pages needed to keep your program running - Win9x system monitor can show you your paging statistics - Unix "vmstat" command does same thing - too much paging is bad - called "thrashing" - all the computer time is spent moving pages in and out of memory - very little useful work is being done Choosing buffer size for I/O - buffer is used to receive or contain data to be read/written to disk or tape; it must be "locked" in memory for transfer - if the buffer size fits in one page, you use one page - if the buffer is even one byte bigger than one page, you use at least two pages, so make best use of page size - buffer *must* be a multiple of LRECL - e.g. LRECL=200 ==> int(4096 / 200) * 200 = 4000 bytes - buffer *should* fit inside the natural device block size (usually 4K) - Note: a 4K block size is not 4000 bytes, it's 4096 bytes (4 * 1024) - the multiple of 80 closest to 4K ==> int(4096 / 80) * 80 = 4080 --------------------------------------------------------- Today: review the homework - "MVS JCL Example 3 Homework" --------------------------------------------------------- Approach: Cross out every line in job specification as you add it to JCL. Use a Flow Diagram if you find it useful. Coding the JCL for Example 3 Homework ------------------------------------- Document your guesses using JCL comments: //* NO DDNAMES OR STEP NAMES ARE GUESSED IN THIS JOB. //* WE EXPECT IT TO RUN. SEE COMMENT BELOW ABOUT CODING TYPRUN FIRST. //* //COBTSTH3 JOB 3111HW,'MY NAME',CLASS=E, // MSGCLASS=A,MSGLEVEL=(1,0),PRTY=0, - need more than 5000 lines of output! - must use big job class "E" to get unlimited print lines - job spec doesn't say what to do with the JCL listing - use default or choose a fast sysout queue (JCL listing is not many lines) - job spec says to get rid of JES allocation messages - job spec says lowest priority // TYPRUN=SCAN - Real-World Suggestion (not given in job specification): - code TYPRUN=SCAN for first run, to scan the JCL before queueing job up for long-waiting class E queue - don't want job to wait all day then fail on an JCL error at midnight - what types of errors does TYPRUN=SCAN find? - does not find errors in DDnames - does not find errors in IDCAMS input (or any instream input) - it *does* find errors related to JCL syntax and proc step names - don't need to scan JCL if you have run it before - don't scan JCL if you are trying out guesses in your DDnames - DDNames are run-time errors, not JCL errors - you need to run a program to see a DDname error - this job will not run twice - it deletes an input tape in step one - you can't "test" this job first! //COPY EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=A,DEST=MVS1.LESLIE //OUT DD DSN=MYTSTDAT,DISP=(NEW,PASS), // BLKSIZE=4000,RECFM=FB, // UNIT=DASD,SPACE=(4000,(150,2)) //IN DD DSN=TSTDATA,DISP=(OLD,DELETE), // UNIT=TAPES,VOL=SER=311111,LABEL=(,AL) - job spec says send the error/status messages to MVS1.LESLIE - we choose the output dataset name "MYTSTDAT" and pass it to next step - don't need to code DCB on existing datasets (e.g. input data) - DCB info is in the existing dataset label - don't need SPACE for input, or for tapes - have to include anything that is not defaulted, or that we want to modify - IDCAMS assumes output DCB same as input DCB - usually, the output requires reblocking to make best use of medium - look at DCB of IDCAMS input (as given in job spec) - input DCB for the ANSI tape is given as: DSORG=PS (all tapes), LRECL=100, BLKSIZE=100 (no blocking), RECFM=F - we want to write a disk dataset that has 4K blocks (IBM standard) - must reblock output to fit in 4K for best use of the disk dataset - calculate max number of 100-byte records that fit in 4K: - int(4096 / 100) * 100 = 4000 byte block size - code BLKSIZE=4000,RECFM=FB (fixed with blocking) for output - need SPACE for a new output disk dataset (not needed for tapes) - don't do SPACE in CYL or TRK -- too device dependent - SPACE should always use same block size as DCB BLKSIZE: 4000 - how much space (how many blocks needed) for primary extent? - we have about 6000 records of 100 bytes ==> 600,000 bytes of data - 600,000 bytes divided by 4000 = 150 blocks (of 4000 bytes) - how much space (how many blocks needed) for the secondary extents? - doesn't say what will be done with dataset - need to know if dataset will grow, and how it will grow - we assume test dataset is "one-shot" and won't be updated very often - use small secondary extent to allow for small error in size of test data - don't make secondary extent too big, or it will be wasted space - don't make it too small, or you'll run out of secondary extents - code SPACE=(4000,(150,2)) - NOTE: you only get 15 of these 2-block secondary extents without SMS - make sure the test data won't exceed 150+(2*15)=180 blocks of 4000 bytes - job spec says to delete the tape when done //SYSIN DD * REPRO INFILE(IN) OUTFILE(OUT) /* - REPRO is a standard IDCAMS copy operation Step Two -------- Compile, link, and run my program: //CLGTEST EXEC PROC=COBCLG - the three expected internal CLG proc step names were given in the job spec: - Compile: COB; Link: LKED; Go: TST - JCL for proc step COB must precede proc step LKED must precede proc step TST - style says put instream data last, where possible - but, *must* obey proc rules: COB, then LKED, then TST //COB.SYSIN DD * ...cobol source goes instream here... /* - cannot put this instream data last in JCL - it must go first, for first proc compile step "COB" //LKED.SYSLIB DD DSN=PVT.OBJLIB,DISP=(SHR,KEEP) - use our own subroutines from this library - this over-rides the SYSLIB DDname in step LKED in the COBCLG proc - remember to SHR and KEEP libraries! (don't use OLD or DELETE) - all LKED JCL must lie after COB and before TST (proc rules) //TST.DATOUT3 DD DSN=TESTOUT,DISP=(NEW,PASS), // BLKSIZE=4000,RECFM=FB, // UNIT=DASD,SPACE=(4000,(150,75)) - we choose the output dataset name "TESTOUT" and pass it to next step - read COBOL source to confirm that LRECL of this output is also 100 - LRECL is specified in COBOL source, as is DSORG - we only code in the JCL what is missing: BLKSIZE and RECFM - BLKSIZE: int(4K / 100) * 100 = 4000 bytes - why doesn't the output dataset DCB default to the same as the input? - because this isn't IDCAMS! It's my COBOL program! - need SPACE for a new output disk dataset - don't do SPACE in CYL or TRK -- too device dependent - SPACE should always use same block size as DCB BLKSIZE: 4000 - how much space (how many blocks needed) for primary extent? - we have about 6000 records of 100 bytes ==> 600,000 bytes of data - 600,000 bytes divided by 4000 = 150 blocks (of 4000 bytes) - how much space (how many blocks needed) for the secondary extents? - need to know if dataset will grow, and how it will grow - job spec says dataset grows 50% each update - 50% of 150 blocks is 75 blocks (of 4000 bytes) - don't make secondary extent too big, or it will be wasted space - don't make it too small, or you'll run out of secondary extents - code SPACE=(4000,(150,75)) - NOTE: you only get 15 of these 75-block secondary extents without SMS - after about 15 updates, this dataset will be "full" //TST.BKUP3 DD DSN=TESTBKUP,DISP=(NEW,KEEP), // BLKSIZE=4000,RECFM=FB, // UNIT=TAPES,VOL=SER=312222 - same COBOL for this dataset as for DATOUT3 - same DCB (this is not an ANSI tape - can use up to 4K blocks) - no need for special LABELs (uses IBM labels) - no SPACE needs to be specified for tapes (only for disks) - tape number is given; dataset is probably not in catalog - need UNIT and VOL=SER to find uncataloged tapes //TST.BILLS3 DD SYSOUT=L, // FLASH=BILL, // OUTLIM=2200 - put SYSOUT parameters in alphabetical order for this course - MVS doesn't care - FLASH parameter only works for laser printers - it flashes an image on the paper - less work for the operator; no need to line up the printing paper - SYSOUT=(,,form) forms parameter is for special paper, not a laser background - forms is for real paper loaded by the operator into the printer - FLASH is for a laser printer background form or image - 100 bills of "average" 20 lines each is about 2000 lines - add 10% for safety margin as per job spec ==> 2200 line limit //TST.DATIN DD DSN=MYTSTDAT,DISP=(OLD,KEEP) - this disk dataset "MYTSTDAT" was created and PASSed from previous step - no need for LABEL, UNIT, VOL, or DCB for PASSed dataset - look for what to do with this dataset when done - not given - we already deleted the tape from which this dataset was made - do the safe thing - KEEP the disk copy - must remember where it is (UNIT), due to lack of catalog info - system cannot find an uncataloged dataset based on its name only! Step Three ---------- //DUMPDISK EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=A,HOLD=YES //OUT DD SYSOUT=(D,,GRLN),BURST=YES,COPIES=2 //IN DD DSN=TESTOUT,DISP=(OLD,CATLG) //SYSIN DD * REPRO INFILE(IN) OUTFILE(OUT) /* - large volume of output lines forces sysout class D - the input disk dataset "TESTOUT" was created and PASSed from previous step - no need for LABEL, UNIT, VOL, or DCB for PASSed dataset - we were told to calalog the input dataset; we do it now - job spec says to HOLD the status messages for TSO - REPRO is a standard IDCAMS copy operation // 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.