--------------------------- Week 12-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 - Tue Feb 2, 2000 -------------------------------------------------- Review the homework - "MVS JCL Example 1 Homework" -------------------------------------------------- Draw a flow diagram if you find it helpful - not required on job or exam - it can be as sparse or detailed as you please; it's for you only Most of the class examples are COBOL compiles - that's the most likely thing you will be doing on the job Use the specified COBCLG procedure - draw a dotted box for a procedure (not a program) - that means we must use dotted DDnames on our flow diagram arrows - our CLG step uses a PROC that contains three internal steps: - compile the source, link the object files, and "GO!" (run the program) - the PROC is called up from SYS1.PROCLIB when your job is submitted to JES - remember this name: SYS1.PROCLIB - refer to the MVS Job Flow diagram - a PROC is JCL (text) - it is not a binary program - we may have to go fishing to find the name of the PROC we want - ask a human, look around, or list the names contained in SYS1.PROCLIB - we must code only the JCL for the things not specified in the PROC - always need to specify where we get the COBOL source (no default) - remember to qualify our JCL DDnames with the matching step names in the proc - the two relevant step names were given in the specification: COB and GO - don't need to know the internal "link" step name; we use the PROC defaults - if you can't find out the internal PROC step names: - ask someone, or look for documentation on the proc - get a listing of the JCL contained in the PROC from SYS1.PROCLIB - make something up, submit the job, and watch for the JCL error messages (the listing of the PROC you use will be in the error output) - Note: an incorrect step name will be a JCL error, not a run-time error - the JES JCL processor will detect a mis-matched step name when you submit your JCL; JES will not be able to match the JCL DDname you wrote with any of the internal PROC step names - Why doesn't the link step have its step name mentioned in the specification, and why doesn't the link step have any DDnames that we have to supply? - because all the JCL for the link step is taken care of in the PROC - we don't need to alter the default link behaviour (in this example) - this is why we use a PROC: we only code the minimum JCL we need You must use the DDnames required by the programs you are running - MVS programs don't open dataset names; they open DDnames - DDnames connect programs (e.g. COBOL programs) to their datasets - your JCL must specify DD statements to connect the DDnames to the datasets - you cannot make up DDnames; they are compiled into the programs - DDnames are associated with the programs, not with the datasets - you can't usually expect that different programs (written by different people for different purposes) to open and use the same DDnames - except that IBM utilities usually print on SYSPRINT and read from SYSIN - SYSIN and SYSPRINT are good DDname guesses for IBM utilities Coding the JCL for Example 1 Homework ------------------------------------- - UPPER CASE ONLY (run your JCL through a Unix tr command!) - use fixed-width (monospace) font for JCL so that blanks are clear - UNIX VI does this automatically (text only) - choose a Courier or Terminal font, if using a word processor, and save the file as plain text - don't go past column 71 - use ":set ruler" in VIM (put it in your .vimrc) - no extraneous blanks are allowed! - blanks start comments after third column - be careful - continuation cards must start in cols 4-16 Start of Step One ----------------- //COBTSTH1 JOB 03F$HW1,'MY NAME',CLASS=D - you get to choose a meaningful 8-character job name for this job - two positional parameters precede optional keyword parameters on JOB card - use the specified account code - job account billing is often done even if it's your own computer - the MVS shop tracks which team uses more/less CPU Picking a CLASS= for the JOB card - not a random choice - you must calculate this correctly - the JOB CLASS indicates resources required by the *entire* job (all steps) - you can't experiment with this one - you must find out what they mean - submitting a job in the wrong class at work may cause job failure - class letters are different for each shop (and for each test and homework) - typically, low-alpha classes are better service, less resources - err on the higher side; but, don't put all your jobs in the longest-running class or they may not be scheduled until late in the day or (worse) on the weekend! - confusing letter sounds; use words: Able, Baker, Charlie, Dog, Easy, Fox //COBOLCLG EXEC PROC=COBCLG - you get to choose a meaningful 8-character step name for this step - don't call it an unhelpful name such as STEP1 or FIRST - this step uses a PROC (PROC=), not a program (PGM=) - a PROC is like a macro; it contains one or more hidden internal steps and step names and executes one or more programs - the PROCs were written by your local MVS system guru - a catalogued PROC must be from the system library (use the exact name) (what is the name of the library that contains system PROCs?) - check your flow diagram to count DD statements (one for each arrow) - we count 4 DD statements used with this PROC (two output, two input) - we add one DD statement to be used by the compiler - the compiler uses other DD statements; but, these are hidden in the JCL of the PROC we are using - three DD statements will be used by my compiled and running program - two internal PROC step names were given in the specification: COB and GO - if these weren't given, you'd have to fish for them by asking a human; or, generate a JCL error and look at the PROC listing - don't care about the name of the middle (link) step since we aren't coding any changes to this step (the PROC JCL is fine) - what is the output of the COB step inside the COBCLG proc? - what output does a compiler produce (refer to the CLG)? - should I put in my JCL a DD statement to handle this compiler output? - no, that's handled by the JCL in the PROC (which is why we use a PROC) - don't specify DD statements for things done correctly by the PROC - what is the ordering of DD statements for MVS? - order doesn't matter to MVS when using a simple program (EXEC PGM=) - order of statements when using EXEC PROC= *must* be in PROC step order - our PROC steps are: COB, ???, GO - must put our added COB DD statements before our added GO statement JCL - the DD order within each program (not proc) step doesn't matter to MVS - all the DD statements for a single program can be in any order - the order of the three GO.whatever DD statements doesn't matter - however, it matters to instructors who prefer large instream data *last* //COB.SYSIN DD * ...your actual COBOL source program goes here as in-stream data... ...this is fed to the COBOL compiler in step COB via the SYSIN DDname... /* - This instream data DD has to come first, because it's part of the COB step. All the COB DD statements must precede all the GO DD statements; because, that's the order of the steps in the COBCLG proc we're using. - you must specify DD statements in the order of the steps in the PROC - this is an MVS rule that must be followed - always remember the /* "EOF" to end the input stream for "DD *" The order of the DD statements within the GO step can follow the guideline of "output first, input last, instream data very last". (MVS doesn't care; it's just good style to put instream data at the bottom.) //GO.TRANSLOG DD SYSOUT=B - the SYSOUT parameter always means an output DD (spool queue) - SYSOUT= spool queue classes are different from JES JOB CLASS= classes - don't get JOB CLASS= classes confused with SYSOUT= classes - both classes are defined locally for each MVS shop (and each test) - use the classes given and defined for this example - pick the SYSOUT class that matches the output and the requirements - how much output? special forms? hold the output or not? - 600 lines is too much for SYSOUT queue "Able" - choose "Baker" //GO.MASTER DD DSN=PAYMAST,DISP=(OLD,PASS) - output DD: this is an "update" - write or read/write an existing dataset - OLD is used to update an existing dataset in place - MOD is only used to "extend the length of a sequential dataset" - we never use MOD in this course - DISP=(,KEEP) would have the dataset kept but deallocated - a tape would be dismounted and put back in storage - next step would request the same tape and the operator would have to go back to the store room and get it again (annoying) - don't leave the tape mounted unnecessarily; but, don't dismount it if it will be needed in the next step: code PASS - this abbreviated JCL only works because dataset is cataloged - no need to specify more detail to find the dataset because the catalog has the UNIT, VOL, SER, etc. information - no need to type in parameters that are retained in catalog - even offline (dismounted; in storage) datasets are catalogued - an existing dataset has I/O DCB (data control block) information stored in its "label" (part of the dataset reserved for information about the characteristics of the dataset) - no need to specify output DCB information here either - cataloged datasets are easy to find and use! - only need to code DSN and DISP for cataloged datasets - but you pay a little every month for the catalog entry... //GO.TRANIN DD DSN=TESTTRAN,DISP=(OLD,DELETE) - input DD: dataset is cataloged, making it easy to find and use - never need to specify I/O DCB parameters for an input dataset - the DCB (data control block) info is in the existing dataset label - the job specifications say to delete the tape dataset if the step works - in this course we never code the third DISP parameter (on failure) End of Step One - Beginning of Step Two --------------------------------------- //VERIFY EXEC PGM=VIEWDATA //PRT DD SYSOUT=D //DATATIN DD DSN=PAYMAST,DISP=(OLD,KEEP) // - you get to choose a meaningful 8-character step name for this step - this step uses a program (PGM=), not a proc (PROC=) - there are no hidden steps when using a program, no hidden programs - only one program runs in this step (it is not a PROC) - no need to preface your DDnames with an internal PROC step name - check your flow diagram to count DD statements (one for each arrow) - we count 2 DD statements (one output, one input) - output statements go first (style issue; not a JCL rule) - the specifications give the two DDnames: DATATIN, PRT - see example specification for classes of SYSOUT spool queues - we are asked to hold the output for TSO viewing - choose the sysout hold class SYSOUT=D - NOT "class A" SYSOUT=A or job will end up on paper! - specification says to keep (but not catalog) the disk dataset - the dataset is already cataloged; can't catalog it twice! - get the exact spelling of the DDnames right! - the DDname in the JCL must match the exact name needed by the program - the null statement "//" marks the end of this JOB 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.