-------------------------------------------------------- Week 12-A Notes for DAT2330 - Ian Allen - idallen@ncf.ca -------------------------------------------------------- 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 - Tue Feb 2, 2000 Today: 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 - we may have to go fishing to find the name of the proc we want - ask a human, 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) - see the end of Chapter 3 (p.52) for another PROC example - see the end of Chapter 5 (p.76) for examples of using PROCS to C.L.G. (compile/link/go) COBOL, PL/1, FORTRAN, and C++ - 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 print out of 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! - blanks start comments after third column - be careful - continuation cards must start in cols 4-16 Start of Step One ----------------- //COBTSTH1 JOB 1111HW,'MY NAME',CLASS=D - you get to choose a meaningful 8-character job name for this job - two positional parameters precede 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 - 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) - one DD statement will be used by the compiler - 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 text CLG diagram p.44)? - should I put in my JCL a DD statement to handle this 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 - must put COB DD statements before link statements before GO statements - the DD order within each step doesn't matter to MVS - the order of the three GO.whatever 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 (see example p.76)... ...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= classes are different from 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. (see p.121 for list) - 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 - see p.121 for list of DD parameters stored in dataset label - 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 info is in the existing dataset label (see p.121) - the job specifications say to delete the tape dataset if the step works - in this course we never code the third DISP parameter 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, 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" or job will end up on paper! - specification says to keep (but not catalog) the disk dataset - get the exact spelling of the DDnames right! - 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 course outline or MVSweekly.txt file to see what we do next; read ahead.