Week 12-A Notes for DAT2330 - Ian Allen 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 Spring 2002 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 - CLG 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 - 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 contents of SYS1.PROCLIB - we must add 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 for another example - remember to qualify the DDnames with the matching step names in the proc - two relevant step names were given in the specification: COB and GO - don't need to know internal "link" step name; using 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 and watch for the JCL error messages - an incorrect step name will be a JCL error, not a run-time error - the JES JCL processor will detect the mis-matched step name - 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) You must use the DDnames required by the programs you are running - DDnames connect programs to their datasets - programs don't contain dataset names; they contain DDnames - your JCL must 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 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 - don't go past column 71 - use ":set ruler" in Unix VIM (not available in VI) - no extraneous blanks - continuation cards must start in cols 4-16 - blanks start comments after third column - be careful 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 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 - 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 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, Charie, 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 - catalogued proc must be from the system library (use the exact name) - check your flow diagram to count DD statements (one for each arrow) - we count 3 DD statements (two output, one input) - 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 - ask a human, or generate a JCL error and look at the PROC listing - what is the output of the COB step inside the COBCLG proc? - what output does a compiler produce (refer to CLG diagram p.44)? - should I put in my JCL a DD statement to handle this output? - no, that's handled by 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 of DD statements when using a 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 - however, it matters to instructors who want large instream data *last* //COB.SYSIN DD * ...your actual COBOL source program goes here (see p.76)... ...this is fed to the COBOL compiler 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 - always remember the /* 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? //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" - never used in this course - DISP=(,KEEP) would have the dataset 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 - this abbreviated JCL only works because dataset is cataloged - no need to specify more detail to find the dataset because the catalog has the VOL, SER, UNIT, 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 - existing dataset has DCB information stored in its label - 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! //GO.TRANIN DD DSN=TESTTRAN,DISP=(OLD,DELETE) - input DD: dataset is cataloged, making it easy to find - never need to specify 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 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 - 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.