--------------------------- Week 14-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 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 blocking characteristics of 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 (ANSI tapes: 2K) - 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 04W$HW3,'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! //IDCAMSCP EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=A,HOLD=YES //OUT DD DSN=DISKTEST,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 TSO. - we choose the output dataset name "DISKTEST" 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=TSTOUTPT,DISP=(NEW,PASS), // BLKSIZE=4000,RECFM=FB, // UNIT=DASD,SPACE=(4000,(150,75)) - we choose the output dataset name "TSTOUTPT" 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" (without SMS) - 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=BKUPKEEP,DISP=(NEW,KEEP), // BLKSIZE=4000,RECFM=FB, // UNIT=TAPES,VOL=SER=312222 - we choose the output dataset name "BKUPKEEP" and keep it - this is a "choice", not a "guess"; no comment is required - 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=DISKTEST,DISP=(OLD,KEEP) - this disk dataset "DISKTEST" 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=TSTOUTPT,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 "TSTOUTPT" 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 (remember the //). 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.