--------------------------- Week 13-B 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 - Thu Feb 10, 2000 --------------------------------------- MVS JCL Example 3 and attached homework --------------------------------------- New Parameters -------------- For //DDname DD ... SYSOUT=(class,,form) [using special forms] BURST= COPIES= FLASH= HOLD= OUTLIM= SPACE=(blksize,(primary,secondary)) New item: modifying SYSLIB SYSOUT=(class,,form) [using special forms] - special form name is third positional parameter - used to tell operator to change paper in printer for this output - operator has to align the paper with the printed output - special forms may cause output to be delayed until printer isn't busy and the special form paper can be installed and lined up - let second SYSOUT parameter default (two adjacent commas) BURST= - YES to have continuous form fan-fold paper split at the perforations into individual sheets by the operator - a mechanical "burster" machine is very noisy! - may also apply to continuous-sheet laser printers that cut their output into individual pages at the printer - doesn't apply to single-sheet printers (ignored) COPIES= - request multiple copies of the spooled output - each copy counts towards your SYSOUT and job CLASS= line limits FLASH= - (laser printer only) specify a background form to print first - your data text will print on top of the background form - easy to use; no special forms alignment required by operators HOLD= - means: don't send this to the printer; hold it before printing - hold the output in the spool queue for pick-up and viewing via TSO - may be used on any SYSOUT queue if there is no special TSO SYSOUT queue OUTLIM= - limit the number of lines of output - typically only done while testing your code, to prevent errors - production programs are presumed to work correctly and don't need this; indeed, an incorrect value may cause a production program that is working correctly to fail due to "too many" output lines SPACE=(blksize,(primarycount,secondarycount)) - request a specific amount of disk (not tape) output space - never need to specify space for a tape (tapes don't fragment!) - blksize is the same number as you choose for the DCB BLKSIZE - many JCL shops use TRK or CYL sizes; but, they are device-dependent - primarycount and secondarycount are counts of blksize blocks e.g. SPACE=(4096,(100,10)) requests an initial allocation of 100 4K blocks (409600 bytes) called the "primary extent", with growth in chunks of 10 4K blocks (40960 bytes) called "secondary extents". - Warning: Unless SMS is in use, you only get 15 secondary extents before your dataset is out of space and has to be copied to a new dataset with new SPACE parameters! - Midterm question: given SPACE=(4000,(100,10)), what is the maximum number of bytes that can be stored in this non-SMS dataset? Answer: 1 primary extent of 4000 * 100 (400,000 bytes) + 15 secondary extents of 4000 * 10 (600,000 bytes) therefore MAXIMUM DATASET SIZE = (1,000,000 bytes) Modifying SYSLIB ---------------- The linker (link editor) searches a language library to find all the object code needed to make your program complete. (e.g. The linker searches COBOL libraries to link a COBOL program.) You can change this library by over-riding the SYSLIB DDname in the Link step in the Compiler/Link/Go procedure. (You must know the internal step name of the Link step in the PROC.) Review: The Compile, Link, and Go process Review: Rules for ordering DD statements when using a PROC Coding the JCL for Example #3 ----------------------------- Step One -------- A Compile, Link, and GO step using a cataloged procedure (EXEC PROC=). The CBL step name in the proc is given, but not the DDname by which the compiler will read the COBOL source program. - you can't always look in the PROC to find out a DDname, since some DDnames don't have default values in the PROC (e.g. the compiler source input) - the DDname we are looking for is in the compiler, not in the PROC - though the PROC may supply a "default" compiler input dummy DD statement - only by running the compiler will we generate a run-time error message to tell us what DDname to use, if we guess wrongly - this is a run-time error from the compiler, not a JCL error from JES Can TYPRUN=SCAN on the JOB card detect an invalid DDname? - no, since SCAN doesn't run any programs - programs (PGM=xxx) must run to detect incorrect DDnames - in a long-wait job queue, scanning JCL first is a good idea - but we won't detect the DDname guesses until actual run time DDnames are coded inside the programs (PGM=xxx) we run - DDnames connect the programs to the world (their datasets) - the programs don't know the names of the files (datasets), only the DDnames. We code JCL to connect the program DDnames to dataset names (or to SYSOUT spool queues, or to instream data). - MVS programs don't contain the *names* of any datasets (files)! - they only contain 8-character (or less) *DDnames* - your JCL connects the program DDnames to: datasets, queues, instream Need to modify LINK step of PROC to use a different link library - we have our own subroutines in our own library that we want to use - need to bring in a different library - we are *replacing* the COBOL standard link library - this is not SYS1.LINKLIB, which is actually a library of executable *programs* (e.g. IDCAMS), not a library of *object code* modules - the specification says that the linker program running in step LINK expects to find its standard library on DDname SYSLIB - refer to diagram of Compile-Link-Go process - see where link editor expects to add subroutine libraries - this "SYSLIB" DDname for the link editor is defined in the PROC - we can use our JCL to *over-ride* the given SYSLIB in that step - we are not adding a *new* DDname, we are *changing* an existing one - we lose access to original library given in the PROC, unless we also add that library to our own JCL (not done in this course) We are missing the DDname for the special forms INVC output - this DDname lies inside our test COBOL program (not in the compiler!) - the PROC definitely will not have it listed - TYPRUN=SCAN will not discover the error - this is a DDname guess, a run-time error, not a JCL error - need to look at the COBOL source code for the program we are running - read the instream source and find the SELECT statement - if you don't read COBOL, or don't have the source, run the job and look at the run-time error messages from the program - when the program runs, it will look for its compiled-in DDnames - note the DDname that is missing, fix your JCL, and re-run the job Document your guesses using JCL comments. (Comments may be mixed-case): //* I am guessing several DDnames in Step One. //* I need to see the run-time error messages to fix this JCL. //* //CBLTSTE3 JOB 04W$EX3,'MY NAME',CLASS=E, - CLASS=E is the only job class that allows multi-tapes *and* special forms - would prefer not to run in this slow class - we may end up waiting behind another long-running job - may not be scheduled until much later (night or weekend!) - no limits to output; runaway job will be very expensive! - we want to see our DDname errors quickly - may sit a long time in CLASS=E before job is run // MSGCLASS=A, - MSGCLASS is the JES (JCL) SYSOUT message queue, not a job class - note that this installation has no TSO SYSOUT HOLD spool queue - we can't code HOLD= on the JOB card - HOLD= is a DD SYSOUT parameter! - there are other ways of having your JCL listing held for TSO // MSGLEVEL=(0,0), - we can safely set JCL to minimum messages right away (as specified) - our guesses are run-time DDname guesses, not JCL step name guesses - no need to waste paper printing the JCL (including PROCs) listing // PRTY=7 - find out which version of JES to determine actual top priority - medium priority is approx integer(15 / 2) = 7 - no decimal points! integers only! //CLG EXEC PROC=COBOLCLG - we are using a cataloged procedure named COBOLCLG - the over-ride DD statements we supply to this PROC (below) must follow the MVS order of the internal steps inside the PROC being used //* I am guessing this compiler input DDname - not given in job spec. //* This will generate a compiler run-time error giving the right DDname. //* SYSIN is a pretty good guess for input to an IBM program. //* //CBL.SYSIN DD * ...COBOL source program goes instream here... /* - we weren't given the DDname for the compiler input in step CBL - document your guesses using JCL comments (run time or JCL error?) - we don't have the source for the compiler to find out the DDname - ask around; copy existing JCL; or, run the job and look at the errors - order of DD statements: - all the proc step CBL JCL must come before all proc step LINK JCL - we can't put this source program instream data last; it must appear before the LINK step DDnames //LINK.SYSLIB DD DSN=TEAM1.MODLIB,DISP=(SHR,KEEP) - this over-rides the SYSLIB DDname in the LINK step of the PROC COBOLCLG - UNIT and VOL are only required to find an *uncataloged* volume - we assume this lib was catalogued, since we weren't told where it was - must specify at least UNIT if dataset is uncataloged - cataloged datasets are very easy to use! - DCB is (almost) never required for an existing dataset - the DCB info is retained in the label on the dataset itself - LABEL is only required for non-IBM (e.g. ANSI) tape labels - DISP=SHR: we want to share this library, not exclusively lock it - SHR: read only, shared with others, no modifications - remember always to SHR libraries - KEEP the library, don't delete it! //GO.TSTOUT3 DD DSN=TESTOUT,DISP=(NEW,PASS), // DCB=(BLKSIZE=4000,RECFM=FB), - we pick the new dataset name (it was not specified) - this is a "choice", not a "guess"; any syntactically correct name will do - we will pass the dataset by name to the next step - this is a NEW dataset, we must specify the 4 DCB parameters - always code DSN and DISP first on DD statements, followed by DCB - shortcut: the "DCB=" keyword and its parentheses are optional! - DCB parameters were promoted to "real" (not sub-) parameters - only specify the DCB parameters that are absolutely necessary - parameters specified in the program must not appear in JCL - the COBOL program specified DSORG and LRECL; but, not block size - therefore, we only code the missing BLKSIZE and RECFM - always specify RECFM when you specify BLKSIZE - FB means fixed length records (typical of COBOL): blocking used - 4000 is closest multiple of LRECL=100 below 4K: - integer(4K / 100) * 100 = 4000 bytes // UNIT=DASD, - the shop specifications say "DASD" is the way to specify uncataloged disks - there is no need for VOL=SER to force use of particular disk volume - VOL=SER= almost never done for online disk datasets - UNIT and VOL=SER are not needed for PASSed or cataloged datasets // SPACE=(4000,(125,25)) - we always need to code SPACE for a NEW *disk* dataset (not for tapes) - may want large, unfragmented, reserved disk space (fast processing) - may want to use minimal space and risk fragmenting disk (slower processing) - some JCL shops calculate space using tracks (TRK) or cylinders (CYL) - hardware dependent - first SPACE parameter is the block size (must match program DCB block size) - next, specify number of primary blocks and number of extent blocks - these two numbers are *counts* of blocks; not block sizes - go back to question and examine space needs: - 5000 records of 100 bytes each = 500,000 byte output dataset - we already coded (above) that our BLKSIZE=4000 - 500,000 divided by 4000 = 125 primary blocks needed - must specify secondary space extents for future dataset growth - specifying growth increment controls dataset fragmentation on disk - you need to know your application to pick this well (ask around) - our job specification says growth is 20% per update - 20% of 125 blocks is 25 blocks - Note: without SMS, we only get 15 secondary extents before dataset is "full" and needs to be re-allocated with fewer extents //* I am guessing the DDname of this output - not given in job spec. //* This will generate a run-time error from my program when it runs. //* I should look in the COBOL source for the DDname but maybe I'm too lazy. //* //GO.LAZYGUES DD SYSOUT=(C,,INVC),BURST=YES, - we weren't given the DDname for this output; we have to guess - document your guesses using JCL comments (run-time or JCL error?) - since you will have the COBOL source instream, you can look in the source to find the DDnames yourself - no need to guess! - run-time error will tell you the actual DDname when the program runs - SYSOUT C: SYSOUT is always a JES output spool queue - 2000 lines and special forms means SYSOUT class "Charlie" - SYSOUT INVC: special forms is third positional parameter - both commas are needed! (three positional parameters) - BURST: separate the pages at the perforations - only applies to printers that use continuous sheet paper // OUTLIM=2100 - limit number of output lines (in case of runaway job!) - OUTLIM= is used for programs being tested, not production jobs - safety net so that you don't bankrupt your boss's JCL account - the MVS SYSOUT spool queue class usually has its own output lines limit //GO.TSTMSG DD SYSOUT=A,HOLD=YES - hold any output for TSO screen viewing - don't need any special HOLD SYSOUT queue - user doesn't have to come looking for the output in the queue - this TSO user gets notification when output is available //GO.TSTIN DD DSN=ATB.TESTDATA,DISP=(OLD,KEEP) - catalogued dataset is easy to find and easy to use! - no need for UNIT or VOL=SER! (they are in the catalog) - existing dataset doesn't need any DCB (it's in the label) Step Two -------- Print out the TESTOUT dataset for verification. This is a standard IDCAMS copy (REPRO) operation with 4 DDnames: //VERIDISK EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=A,HOLD=YES - this installation has no SYSOUT class to hold output for TSO - another way to hold the output is HOLD=YES on the DD card - might be coded as Y or might be coded as YES; ask around //OUT DD SYSOUT=L,COPIES=2,FLASH=DATA - order multiple SYSOUT parameters alphabetically (e.g. COPIES before FLASH) - specify the laser printer SYSOUT spool queue - flash the "DATA" form behind the text being printed as we print each page - two copies are required (both count towards JOB CLASS= resource limits) //IN DD DSN=TESTOUT,DISP=(OLD,CATLG) - this is the PASSed test data from the previous step (same name) - passed dataset is easiest to specify! - only code DSN= and DISP= for cataloged and passed datasets - no need for LABEL, DCB, UNIT, or VOL=SER= - we were told to catalog this tape for future use - this is the last time we use this dataset; catalog it now //SYSIN DD * REPRO INFILE(IN) OUTFILE(OUT) /* // - request a standard IDCAMS copy operation - no need to re-block output that is going to a SYSOUT queue - if this were changed to output to a disk or to tape, we should specify BLKSIZE= and RECFM=FB to avoid inter-block gaps End of job. To get a listing of just the JCL from this file, use the Unix command: $ grep '^/' thisfile Do the "MVS JCL Example 3 Homework" question; we will review it next class.