Week 11 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 July 2001 These notes are largely based on lectures by Harold Smith: - DAT2330 - Harold Smith Class - Wed Jan 26, 2000 - DAT2330 - Harold Smith Class - Thu Jan 27, 2000 Do the homework questions; they relate to the tests - don't study the JCL book - too much stuff Components of an O/S used to test a program - critical C.L.G. sequence - see p.44 - memorize diagram on p.44 (edit, compile, link, go) - review these components wrt. testing a job: (boot, shell, task mgmt, memory, i/o, security, net, utilities, help) - need boot to load kernel - don't load all of O/S at boot; load KERNEL or NUCLEUS - might not include all device drivers in kernel (might not have choice!) - need shell to start up the compiler - compiler calls on O/S (data mgmt) to read the data - need memory management (virtual memory - bigger than RAM) - need some CPU cycles to run the job - task manager will schedule me - device drivers let O/S access physical devices - need linkage editor (linker) to link your code with already existing code - after linking, load the program itself Review the O/S terms wrt. testing a program: kernel, batch vs. interactive processing, spooling, batch files (procs) Last class: sample JCL, flow diagrammed and analysed - JCL checklist - Basics (see course outline for details) - see the course outline for the list of things we learn each week - see also the file MVSweekly.txt Using pre-defined JCL in your shop - a procedure (PROC) is used for long and/or complex JCL - the system's COBOL CLG PROC is maybe 40-50 lines of JCL! - use existing PROC - don't re-invent it! - see the end of Chapter 3 for an example of proc usage --------------------------------------------------- Review of JCL homework: Find the errors in TESTPROG --------------------------------------------------- - UPPER CASE ONLY for JCL - learn JCL by looking at existing JCL - teach yourself syntax by finding the most errors - style: - put output statements first (output never has instream data) - put input statements last (input DD may have instream data) - put instream data very last in the step, when possible - order of DD doesn't matter to JES (except when over-riding a PROC) JOB statement for TESTPROGRAM: - remove leading blanks - shorten job name to 8 chars or less - remove the blanks after commas - put two positional parameters first - move class=b after positional parameters - MESGLVL spelled wrong: MSGLEVEL - Flow Diagram: title top of diagram TESTPROG Step ONE - first EXEC statement: PGM=IDCAMS - shorten step name to 8 characters - Style: use meaningful 8-character job and step names, not "STEP1" - Flow Diagram: make this a solid box containing MAKETAPE, IDCAMS - four DD statements (after EXEC, before next EXEC in next step): - SYSPRINT DD - label the flow arrow going out to print spool queue - some queues may route print to screen, not to printer - label SYSPRINT print sheet "error messages" for IDCAMS - IDC AMS: Access Method Services (IDC - IBM prefix) - IN DD DSN=TESTDATA - error: DDName "IN" is used twice in same job step - this is a "NEW" dataset; therefore it must be output - rename it to OUT (look at the IDCAMS input stream REPRO line) - label arrow OUT going to TAPE - unit name "TAPE" is an MVS sysgen parameter (SYSSQ, CART, etc.) - next continuation line must start with slash slash blank - indent continuation over to line up with third column - but stop before column 16! - SYSIN DD * - input for this dataset comes from JCL input stream - put instream data last, so that it doesn't space the rest of the JCL down the page - use oval shape on flow diagram, label incoming arrow SYSIN - this SYSIN data is for IDCAMS, telling it what to do - label the oval "control statements" - these are equivalent to DOS flags, switches, UNIX options - having to put all these flags on the EXEC statement would make the statement too long, so we use a separate SYSIN stream to control IDCAMS - IN DD * - instream data - draw an oval, label it as "test data" - look down to next step to see how data will be used - looks like test data for the COBOL program - Use "/*" to end instream data; must start in first column - JES *always* splits jobs on //XXX JOB - you cannot ever have //XXX JOB in instream data Step TWO - second EXEC statement: PGM=IDCAMS - change comment to have //* instead of // - remove blanks around "=" - FlowDiagram: use a square, solid box titled PRTTAPE, IDCAMS - four DD statements: - SYSPRINT DD - label on flow arrow going out to print spool queue - remove blanks around "=" - label as "error messages" for IDCAMS - WRITE DD - remove blanks around "=" - label as "tape records" (look at what we're copying) - SYSIN DD * - make sure there is a space before the asterisk - draw an oval for instream data "control statements" - REPRO statemnt (IDCAMS) cannot start in column 1 - missing /* must follow REPRO line - names must match DDnames: change IN to READ and OUT to WRITE - READ DD - label on arrow coming from passed tape from previous step - DSN=TEST DATA - no blanks, 8 characters for each qualified name - maximum length of 5 times 8 qualified names - usually need to have qualified name - ask the sysadmin - simple name not permitted in system catalog - Windows limits full pathnames to 260 bytes from root to end! - Unix limits pathnames to 1024 bytes - DISP=(,PASS) must have leading comma to select positional default for first parameter Step THREE - third EXEC statement: PROC=COBOLCLG - change comment to have //* instead of // - remove blanks around "=" - Flow Diagram: proc's get a dotted box - Remember: "dotted boxes need dotted DD names" - label it COMLKTST COBOLCLG - four DD statements: - one DD statement is for the COBOL step (the compiler) - three DD statements are for the GO step (my running program) - COBOL.SYSIN DD * - COBOL is the stepname of the step in the PROC "COBOLCLG" - DD statement is followed by instream cobol program, ending in /* - DD statements for a PROC must appear in same order as the steps in the PROC (find out the order from the manual or a sysadmin) - oval for instream data with arrow into PROC box labelled COBOL.SYSIN - oval itself is labelled "cobol source" - GO.PRTOUT DD - GO is the name of the "go" step in the PROC - GO step is where my COBOL program runs and accesses its DDNames - how do you find out the GO step name? - try something and look at JCL errors, or ask someone, or look it up - fix the continuation (can't continue after "=") - put OUTLIM=2000 together on the next line - arrow leading to print spool queue; label the arrow GO.PRTOUT - label print queue "test output" - GO.DSKOUT DD - arrow leading out from proc labelled GO.DSKOUT - destination is a disk dataset, name the dataset TESTOUT - unbalanced parentheses on SPACE - cannot indent past column 16 - must stop before column 72 (71 is last usable column) - GO.TPIN DD - arrow from TESTDATA tape leading into PROC dotted box - label the arrow with the DDname GO.TPIN - this TPIN is the input data for the running program - fix spelling: CATALOG --> CATLG ----------- Study Guide ----------- - I'm not teaching everything you need to know - I concentrate on things that are difficult to understand - you learn the basic things (e.g. continuation rule) Go through each job stream, identifying parameters (look them up) - VOL=SER=127536 - a serial number never changes for a tape - DSN may give it a new name - COBOLCLG is three programs - compile, link, go - why specify OUTLIM=2000 ? - because nobody is watching the spool queue and if your program loops and prints a million lines, MVS will print it and send you the bill! - SPACE= - allocate a bit more than you need - you control growth of the dataset - more on this in later examples --------------------------------------- MVS JCL Example 1 and attached homework --------------------------------------- - instructions to test a program (usually COBOL) - how do we actually code JCL (as on the job) - we will assume many defaults - few things to learn to start out - this will be a real, working job - look up each of the parameters as we explore it - start with a flow diagram (not formal; only to help visualize) Step One - Flow Diagram ----------------------- - what are we being asked to do? - develop JCL to compile and run a program - start with title on flow diagram - 8 chars - read chapter 4 as you code (I won't teach it) - flow diagram: COBOLTST - JOHN SMITH - how many boxes for compile, link, and run COBOL? - this requires three programs, which means three steps (three EXEC needed) - refer to "the CLG process" flow diagram Figure 3.5 - I can do all three steps in one EXEC - use a catalogued procedure: COBOLCLG - procedures come from SYS1.PROCLIB - call in this already-written procedure (similar to a "macro") - one box, a dotted box in the flow diagram - three step names in the proc (see specifications): COMP, LINK, TEST - these are the names of the three hidden steps inside the PROC - our DDnames must be given in this order in our JCL - different coding for PROC= and program (PGM=) steps - a proc doesn't have all the info about the job - e.g. missing OUTLIM for printing? - e.g. what kind of test data is needed? - e.g. where does output go? - e.g. where does the input come from? - can specify information that over-rides default assumptions made by the PROC and that supplies missing information - flow diagram: create a dotted box - we choose the step name for the dotted box: CLG - put the name of the PROC in the middle of the box: COBOLCLG - order of DDnames must match order of steps in PROC: COMP, LINK, TEST - draw instream COBOL source program as an oval labelled "cobol source" - program is on SYSIN DDname, but SYSIN to which step in the PROC? - must qualify DD name; must know names of three steps inside the PROC - must use step name chosen by PROC writer - how to find out what DDname was used by the PROC writer? - Ask; or, try something! JCL Error messages will tell me. - arrow labelled COMP.SYSIN goes from source oval to main PROC box - HINT: cross out each sentence in the assignment as you do it. - anything left over will need doing - nothing more to do for the COMP step in the proc - nothing at all to do for the LINK step in the proc - the "go" step of CLG is named "TEST" according to the specifications - the specifications indicate that it will require four DDnames - draw another oval for instream Test Data, label "test data" - where does test data come from? From DD name INDATA in step TEST - DD name is TEST.INDATA on arrow from oval to dotted box - "dotted boxes require dotted DDnames on their arrows" - why not test programs with live data on datasets? - maybe it might damage the real data (could back it up?) - live data may not test all my conditions - may only test the IF part of IF ELSE - design the test data to exercise all parts of the program - an update step is both input and output - dataset must already exist for an update step - actual dataset has a name (DSN) of TESTMAST - DDname derived from examining actual COBOL code - find the DDname used in the SELECT statement - SELECT MAST-FILE ASSIGN TO UPDTMST <= UPDTMST is the DDname FD MAST-FILE <== MAST-FILE is the internal, COBOL name RECORD CONTAINS 100 CHARACTERS BLOCK CONTAINS 10 RECORDS - we must specify the DDname UPDTMST in step TEST - arrow labelled as TEST.UPDTMST points to TESTMAST disk symbol - why not put DSname (actual name of dataset) right in the source? - would hard-wire the program to that dataset - have to rewrite the program to change datasets - want one level of indirection - another level of redirection gives COBOL a MAST-FILE name - the DSname may have to change if we port to another o/s - insulate cobol from change in DDname - tape DSname is PRODLIST for the LSTIN DDname - draw a tape symbol and label it with the name PRODLIST - we must specify the DDname LSTIN in step TEST - draw an arrow labelled TEST.LSTIN - print some output - DDname is PRINTOP in step TEST - arrow is labelled TEST.PRINTOP Step Two - Flow Diagram ----------------------- - EXEC VERDATA step - this is an actual program, not a cataloged procedure - draw a solid (not dotted) box for a PGM= step - label the step "VERIFY" and put the program name VERDATA inside - draw an input arrow from disk symbol and the dataset labelled TESTMAST that was created in the previous step (step one) - the arrow needs a DDname; but, the input DDname is not given in the specifications! - you cannot invent your own DDName - must use the one expected by the program - go fish for name of DDname for program VERDATA - program probably in SYS1.LINKLIB - find the documentation - but: production programs may not have source - you can always: run the job and see what run-time errors you get - guess at INPUT or SYSIN for the DDname, label the arrow - also need missing DDname for print output (for TSO) - the output DDname is also not given in the specifications - guess at OUTPUT or SYSPRINT for the DDname, label the arrow - end of Flow Diagram Coding the JCL for Example 1 ---------------------------- - 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 ----------------- //CBLTSTE1 JOB 1000EX,'MY NAME',CLASS=B - you get to choose a meaningful 8-character job name for this job - watch out for positional parameters on JOB statement - keyword parms follow two positional 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 - CLASS: indicates resources required by the *entire* job (all steps) - similar to priority, but technically not a priority - defined by each MVS shop; check with your sysadmin (will be different for each homework and on tests) - see examples for sample classes - complex jobs may take longer to set up and run - use letter closest to A for best turn around time - check out which class satisfies job, closest to A - operator may kill or extend job when it runs out of resources - automated software may do this, not a human - Depending on the resource limits of your job classes, chosing a job CLASS is determined by ether the *maximum* or the *total* resources used by your job. CLASS is determined by: - the sum *total* number of print (SYSOUT) lines, in all steps, no matter whether the lines are sent to a real printer or back to you via to TSO - the sum *total* amount of computer time used, in all steps - the *maximum* number of tape drives being used simultaneously in any *one* step - NOTE: *not* the total number, only the *maximum* number - the *maximum* memory used in any one step NOTE: *not* the sum total of all memory, only the *maximum* memory //CLG EXEC PROC=COBOLCLG - 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 5 DD statements (two output, three input) - three internal proc step names were given in the specification: COBOL, LINK, and TEST (compile step, link step, go step) - if these weren't given, you'd have to fish for them - what is the output of the COBOL step inside the COBOLCLG proc? - what does a compiler produce (refer to CLG diagram p.44)? - should I put in my JCL a DD statement for this output? - no, that's handled by the proc (which is why we use a 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 COBOL DD statements before LINK statements before STEP statements - the DD order within each step doesn't matter to MVS - matters to instructors who want instream data *last* //COMP.SYSIN DD * ...your actual COBOL source program goes here (see p.76)... ...this is fed to the COBOL compiler... /* - This instream data DD has to come first, because it's part of the COMP step. All the COMP DD statements must precede all the TEST DD statements; because, that's the order of the steps in the COBOLCLG proc we're using. - you must specify DD statements in the order of the steps in the proc - this is an MVS rule - remember the /* to end the COBOL stream The order of the DD statements within the TEST 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.) //TEST.PRINTOP DD SYSOUT=A - the SYSOUT parameter always means an output DD (spool queue) - SYSOUT= classes are different from job CLASS= classes - don't get them mixed up - 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? //TEST.UPDTMST DD DSN=TESTMAST,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 has positional parameters (but it, itself, is not positional) - second parm says what to do with dataset if step succeeds - third says what to do if step fails (default is usually okay; leave it out) - leave it out; but, no trailing commas allowed (see Chapter 4) - 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! //TEST.LSTIN DD DSN=PRODLIST,DISP=(OLD,KEEP) - 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) - what do we do with the dataset after the step ends - question doesn't say what to do - safe thing is to keep it - if you code "PASS" at end of a job it probably means "KEEP" //TEST.INDATA DD * ...lots of test data appears in the input stream here... /* - Instream data goes *last* in the JCL stream, so that it doesn't separate the rest of the JCL. (This is a style guideline; not an MVS JCL rule.) End of Step One - Beginning of Step Two --------------------------------------- //VERIFY EXEC PGM=VERDATA //* NOTE: I AM GUESSING BOTH OF THE DDNAMES; THEY WERE NOT PROVIDED. //SYSPRINT DD SYSOUT=D //SYSIN DD DSN=TESTMAST,DISP=(OLD,DELETE) // - 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) - we are guessing at the DDnames; they weren't specified - program run-time error messages will tell us the real names - JCL cannot detect incorrect DDnames - only when you run the program will it detect the missing DDname - 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 DELETE the dataset at the end of the job - this is the last job step, we code "DELETE" - 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 Do the "MVS JCL Example 1" homework question; we will review it next class.