-------------------------------------------------------- Week 14-A Notes for DAT2330 - Ian Allen - idallen@ncf.ca -------------------------------------------------------- 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 Winter 2003 These notes are largely based on lectures by Harold Smith: - DAT2330 - Harold Smith Class - Wed Feb 16, 2000 Mainframe Paging - the Page Dataset ----------------------------------- - nucleus (O/S kernel) sits in memory ("memory resident") - an application program may have a large memory address space (e.g. 4GB) - the program is divided into some number of memory pages of, say, 4KB each - the real RAM is divided into "page frames" of same size (4KB) - application program pages are "paged" into RAM and "swapped" out to disk - only a few of the 4GB of pages are in memory simultaneously - IBM calls the paging disk space the "paging dataset" - Windows call it the "swap file" for virtual memory ("win386.swp") - Unix/Linux also has a "swap partition" or swap file - too much paging is bad (see "thrashing", below) - a "page fault" happens when a page that is on disk is needed in memory - must stop the running program and fetch the page from disk to memory - may cause some other page in memory to be swapped to disk - how to choose what page to take out of memory and put back on disk? - Least Recently Used (LRU) is a common algorithm - page only has to be copied out of memory if it has been modified - unmodified pages can be fetched from disk again; modified pages have to be saved to and retrieved from the swap file - a bit (the "dirty bit") indicates whether a page has been modified while in memory - Windows problem: Blue Screen Of Death (BSOD) "invalid page fault" - Win9x loses track of the page on disk and can't find it! - definition: "thrashing" - excessive paging - the computer is spending most of its time moving pages in and out of memory and not getting any "real" work done - happens when there is not enough real RAM to keep all the programs running before the next page fault happens - definition: the "working set" of pages - the minimum number of real RAM pages needed to keep a program running smoothly without "thrashing" - Win9x system monitor can show you your paging statistics - Unix/Linux "vmstat" command does same thing BLKSIZE= - use up to 4K (to match size of the disk block on an IBM paging device) - but ANSI tapes allow only up to 2K - best choice depends on output device - Kevin Solomon says "half track" blocking is also recommended in "real world" applications that use large amounts of disk Choosing a good buffer size for I/O - 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 the actual transfer - if the buffer size fits in one memory page, you use one page - if the buffer is even one byte bigger than one page, you use at least two memory pages - calculate I/O buffers to best make use of the machine page size - an I/O 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 for IBM mainframes - Note: a 4K block size is not 4000 bytes, it's 4096 bytes (4 * 1024) - the multiple of 80 closest to 4K ==> integer(4096 / 80) * 80 = 4080 - the multiple of 100 closest to 4K ==> integer(4096 / 100) * 80 = 4000 - etc. --------------------------------------------------------- Today: review the homework - "MVS JCL Example 3 Homework" --------------------------------------------------------- Approach: Cross out every line in job specification as you add it to JCL. - use this approach on tests to save time and minimize confusion Use a Flow Diagram if you find it useful. - flow diagrams are never required and never marked Coding the JCL for Example 3 Homework ------------------------------------- Document your guesses (if there are any) 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 - the JCL listing is not very many lines - use the system default (don't specify MSGCLASS); or, choose a fast sysout queue - job spec says to get rid of JES allocation messages - this is the second positional parameter to MSGLEVEL - job spec says lowest priority - same for both JES2 and JES3 // TYPRUN=SCAN # this is optional (not specified) - Real-World Suggestion (this was not given in the job specification): - code TYPRUN=SCAN for the first run, to scan the JCL before queueing job up for long-waiting CLASS=E queue - don't want the 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 DDname spelling - does not find errors in IDCAMS input (or any instream input) - it *does* find errors related to JCL syntax, including PROC step names - you don't need to scan the JCL if you have run it before - you don't need to scan the 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 - Warning: 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), // DCB=(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 - if the dataset name is not given, make one up - this is a "choice", not a "guess"; it does not require a comment - don't need to code DCB on existing datasets (e.g. input data) - DCB is only needed for NEW datasets - DCB for existing datasets is in the dataset label - don't need SPACE for existing datasets, including all input datasets - SPACE is only used for NEW output disk datasets, never for tapes - our JCL should include only parameters that are not defaulted, or parameters that have the wrong defaults and that we want to change - IDCAMS REPRO assumes the output DCB is the same as the input DCB - output DSORG, LRECL, BLKSIZE, and RECFM come from the input dataset - look at DCB of the IDCAMS input dataset (given in the job spec) - input DCB for the ANSI tape is given in the job spec as: DSORG=PS (all tapes), LRECL=100, BLKSIZE=100 (no blocking), RECFM=F - look at the required DCB of the output dataset on disk - input DSORG is correct for output; don't specify it in the JCL - input LRECL is correct for output; don't specify it in the JCL - input BLKSIZE and RECFM are not good for an output disk - we want to write a disk dataset that has 4K blocks (IBM standard) - BLKSIZE=100 is not good use of the output block size of 4K - 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: - integer(4096 / 100) * 100 = 4000 byte block size - code BLKSIZE=4000,RECFM=FB (fixed with blocking) for output - don't specify parameters that have the correct defaults - need SPACE for a NEW output disk dataset (never needed for tapes) - SPACE is needed to prevent disk fragmentation - 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) - NOTE: always round up any fraction - how much space (how many blocks needed) for the secondary extents? - doesn't say what will be done with dataset - need to know if the 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 the maximum dataset size - Exercise: calculate the maximum size of this dataset - maximum size is 1 primary extent of 150 blocks plus 15 secondary extents of 2 blocks each (each block is 4000 bytes) Answer: (150+(2*15)) blocks of 4000 bytes = 180 blocks of 4000 bytes = 720,000 bytes - job spec says to delete the input tape when done - the tape isn't used in any other steps; delete it here //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 coding for the DDnames in this step must be in PROC step order - 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 COB.SYSIN 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 step LKED DDnames must lie after COB and before TST (proc step order) //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 - this is a "choice", not a "guess"; no comment is required - 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: integer(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 a COBOL program! - COBOL programs do *not* copy the input DCB to output DCB - need SPACE for a new output disk dataset (to prevent fragmentation) - 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) - NOTE: always round up any fraction - 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" - Exercise: calculate the maximum size of this dataset - maximum size is 1 primary extent of 150 blocks plus 15 secondary extents of 75 blocks each (each block is 4000 bytes) Answer: (150+(75*15)) blocks of 4000 bytes = 1275 blocks of 4000 bytes = 5,100,000 bytes //TST.BKUP3 DD DSN=TESTBKUP,DISP=(NEW,KEEP), // BLKSIZE=4000,RECFM=FB, // UNIT=TAPES,VOL=SER=312222 - spec says use the same COBOL info 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) - don't code parameters that have correct defaults - no SPACE needs to be specified for tapes (only for disks) - tape number is given; dataset is therefore probably not in catalog - need UNIT and VOL=SER to find uncataloged tapes - the correct UNIT value "TAPES" is given in the job spec //TST.BILLS3 DD SYSOUT=L,FLASH=BILL,OUTLIM=2200 - JCL style: put SYSOUT parameters in alphabetical order - but know that MVS doesn't care - FLASH parameter only works for laser printers - it flashes a predefined image (e.g. letterhead) on the paper - less work for the operator; no need to line up the printing paper - SYSOUT=(class,,form) forms parameter is for special paper - special forms is 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 a PASSed dataset - only need DSN= and DISP= for passed datasets - passed datasets are very easy to use! - look for what to do with this dataset when done - not given in job spec - we already deleted the tape from which this dataset was made - do the safe thing if the job spec doesn't say what to do - 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 us to use 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 - only need DSN= and DISP= for passed datasets - passed datasets are very easy to use! - we were told to calalog the input dataset; we do it now (after last use) - 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.