Week 10 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

These notes largely based on lectures by Harold Smith:
  - DAT2330 - Harold Smith Class - Thu Jan 20, 2000

- Bring your MVS textbook to all classes and labs
  - note which things are important, and which are not
  - how much to study in each the chapter?
    - enough to do the homework!
    - see the course outline for the statements and parameters

- shall we have only one MVS test? or two?
  - better to split the one test into two, everyone agrees
  - so we will have two tests: one 10% one 20% (final exam)
    - date to be determined

- MVS vs OS/390
  - MVS - old name dating back to 1970's
  - OS/390 is new name for MVS (OS/390 merges UNIX with MVS)

MVS - The SHOCK of JCL (page 1)
- book is effective (with help); few mistakes; good
- O/S of future for big mainframes
- author objects to amount of JCL used to copy a file
- dates from an era where machines were expensive and people cheap
- not all the complexity is superfluous - MVS has more control
  - MVS has good reasons for the complexity - you get very fine control
  - multi-user, need to bill to particular programmers/users
    - cost recovery
  - special input/output requirements
  - detailed (and thus complex) control over resource allocaton
  - priority relative to other jobs (can't do in windows)
- re-examine the JCL on page 1
  - give a good name to the job, e.g. SMITHPAY instead of RT83838 (8 char)
    - need to name jobs when there are many of them
  - give a readable job title in quotes
- execute a program - might have many parameters on this statement
  - suppose I submit a program that might not run
  - suppose it loops, forever
  - I'm not watching it (it's a batch job)
  - it might eat the machine
  - specify a parameter to EXEC to limit cpu time

MVS Concepts and Vocabulary (Chapter 2)
MVS Syntax (Chapter 4)
- I will not read you these chapters - study them yourselves to learn
  the precise meanings of the terms as they come up in the JCL
- MVS calls files datasets
- SYSOUT=A controls the type of printing (spool) queue
  - windows has very primitive spool control (in system tray)
  - can even have MVS machine decollate and burst
- DSN= ; can specify whether or not to share the dataset
- DSN=(new,catlg) ; you can catalog everything, including offline
  storage; pointer to every file on every tape and disk
  UNIT=SYSDA ; what type of output medium
- Blocking:
  - bit->byte(character)->field->record->dataset(file)->database
  - Can put multiple logical records into one physical disk block.
  - Gaps between blocks on disk/tape may be several hundred bytes long
  - poor usage of space
  - MVS lets you adjust block size
  - logical record vs. physical record
    - blocking factor (number of grouped logical records)
      - how many logical records per physical block?
      - if your record is 80 bytes, how many fit in a 4K block?
      - if your record is 100 bytes, how many fit in a 4K block?
- SPACE= ; how to allocate space
  Supose I know that a file will grow to some size; can't reserve
  space in windows - files fragment.  MVS will let me reserve size;
  if job overflows, specify how much new space to alocate.
  We usually care about allocation, since that's why we use MVS.
- Need way to pass options to programs.
  - Win: can specify moves and copies depending on shift and ctrl keys!
    - behaviour also depends on destination!
    - friendly?
  - Unix - flags; DOS - switches
  - MVS - use IDCAMS utility
    - IDCAMS has half a dozen operations!
    - REPRO - specifies what thing IDCAMS will do
    - IDCAMS is a "DEBE - Did Everything But Eat" program
    - SYSIN DDname specifies command line stream that says what to do
    - Unix would have separate commands for the functions in IDCAMS
- commas at line end continue lines, if next line starts with a blank
- embedded blanks cause JCL errors or cause trailing items to be
  takes as "comments" and ignored
- I/O, CPU, main storage, DASD - direct access storage device, tape
- "hard drive" not used because mainframes only had hard drives
- 5-platter, 14-inch, one pound arm - joke program to rock the disk
- "random access devices" - "random" is a poor word, says IBM
- "floppy disk" isn't good, call them "diskettes", says IBM
- Application Programmers (you) vs System Programmers vs Operators
  - may have to ask the System Pgmr who installed MVS about some things
- NOTE: in Win and Unix we teach you some system programming
  In MVS we do not attempt to teach you any system programming
  - not installation of MVS, nor tuning, nor debugging
  - MVS system operators: watch the system constantly,
    responding to requests from JCL
    - put paper in printer; fetch tape; cancel job; adjust forms, etc.
- Text: Virtual Storage (p.17 has an error; fix the error)
  - program cannot be loaded from disk to disk; must go through memory
    - part of the program will page to disk if memory fills up
    - Win: win386.swp
    - disk is not the same as virtual storage
  - could run a 5MB program in 2MB, with 3MB on swap
  - bringing missing pages into memory is a Page Fault
    - windows loses track of pages - invalid page fault
  - the swap file in MVS is named the: PDS - Page Data Set
  - PDS is hierarchical: stepped on fast and slow disk
- DSORG (sequential, direct access, VSAM, partitioned, etc.)
  - not possible in Windows (only sequential)
  - VSAM - virtual storage access method (better than ISAM)
    - index to file - like a dictionary of where things are on disk
- SYSGEN - system generation, installation, and tailoring (naming things)
- EBCDIC vs ASCII - MVS uses EBCDIC!
- MVS/SP (16MB addr space) vs MVS/XA (2GB addr space)
- MVS/ESA (16TB addr space, more than one addr space per pgm, VIO datasets)
- SMS (Storage Management Subsystem - extension)
  - if SMS is installed, it affects how the JCL is coded
  - may allow you to have more "defaults" and specify less

The Compile Link and Go (CLG) process (p.44) - Figure 3.5
- show CGL diagram: compiler, link-edit, execute
- you should be somewhat familiar with this process
  - how much did your program development environment hide?
  - MVS "PROCs" hide some of it; but, you have to understand it
- program development: compiler, load, and GO
  - this task will make up most of your future job
- compile source into object code
- link object and libraries (subroutine library) into a load module
  - why have link libraries?
  - could supply *all* the source and eliminate the linkage editor
  - don't reinvent the wheel (VSAM access code is a subroutine)
  - compiling all that extra code is expensive
  - compiled subroutines are already translated, ready to link
- we will learn to code the CLG process under MVS

MVS Job Flow diagram - what is it like to be an MVS programmer?
- see job flow diagram
- Example: update exiting COBOL programs
- sit at a PC (emulating terminal) and connect to MVS via TSO/ISPF
  Time-Sharing Option, Interactive Structured Productivity Facility
- edit COBOL program on screen (interactive; but, not graphical!
- prepare JCL and maybe the COBOL source "in stream"
- send job JCL from TSO to JES (Job Entry Subsystem)
  - JES is doorway to batch world of MVS
- JES checks the JCL and queues it based on resources and priority
- your job goes in a queue
  - you wait milliseconds or hours for the resources you requested
- your JCL may include a "PROC" (Procedure)
  - system's stored JCL procedures come from dataset SYS1.PROCLIB
  - you can "pull a PROC" and merge your JCL with it
  - you only specify the essential things that differ from the PROC
- JES loads your program into an Application Program Region
  - virtual storage space
  - you can pull in programs from dataset SYS1.LINKLIB
  - your program can access tape and disk
- Summary:
  1) pull a JCL "PROC" to do the CLG steps for us
  2) CLG PROC pulls compiler, linkage editor from SYS1.LINKLIB
  3) the "GO" step pulls my program off DASD and executes it (need a loader)
  4) my output goes to the output spool queues that I have chosen
  5) spool queue may lead to printer, or back to the TSO screen

Learning JCL - looking at job streams and imitating
- front of textbook has all the parameters
  - this index is condensed and very easy to use
- JOB statement starts the JOB stream
- EXEC indicates a new STEP
  - a step is an execution of a program
- DD statements attach I/O devices to the programs
  - the name to left of keyword "DD" is the Data Definition name (DDname)
  - each part of a DDname is limited to 8 characters; but, you may
    have several parts, e.g. GO.SYSIN, COBOL.SYSPRINT, etc.
  - DD names chosen by programmer who wrote the programs
    - you will find them mentioned in the program source

Flow Diagrams
- draw "flow diagrams" before coding the JCL
- show each step in the JOB
- show how the steps work together
  - one step's output may become next step's input
- use arrows to show each input and output for each step
  - show the DDnames of each input and output by
    putting the DDnames on the arrows between the boxes

Example: Flow Diagram of "PAYROLL" JOB (11347),SMITH
- (see flow diagram)

- the JOB name is PAYROLL
  - Box: put job name as title of this flow diagram
    along with programmer name (SMITH)
  - has three steps (three EXEC statements)

- the first of the three steps in this job is named CRETAP
  - Box: put the step name in box along with name of what program or
    procedure is being executed in this step (IDCAMS, here)
  - Arrows: specify the I/O done by this step
    - four DD statements mean four arrows
    - two input arrows (SYSIN, SYSUT1)
    - two output arrows (SYSPRINT, SYSUT2)
    - SYSPRINT
      - likely for IDCAMS error messages
      - goes to SYSOUT in the "A" output class
        - what output class "A" means is defined locally
	- see your sysadmin for the list of classes
    - SYSUT2
      - has DISP=(NEW,PASS) therefore it is an output DDname
      - the dataset name is given as DSN=PAYDATA
      - in the real world, the name will likely be much more complex,
	requiring your account name and other details
    - SYSIN
      - IDCAMS reads from SYSIN to know what to do
      - instructions to IDCAMS are short and usualy embedded directly
	into the JCL as "instream" data using the "DD *" syntax
      - Oval: an oval in a Flow Diagram indicates instream data
        - label it as "control statements"
    - SYSUT1
      - more "instream" data
      - Oval: this data is also represented as an oval
        - label it as "payroll data"

- the second of the three steps in this job is named PRTCHKS
  - Box: put the step name in box along with name of what program or
    procedure is being executed in this step (PAYROLL1, here)
  - Arrows: specify the I/O done by this step
    - three DD statements mean three arrows
    - one input arrow (PAYIN)
    - two output arrows (SYSPRINT, CHKOUT)
  - SYSPRINT
    - goes to SYSOUT - is it the paycheques being printed(?)
    - no - the next DD statement would seem to be the cheques
    - SYSPRINT DDname is probably for errors or a log file; not cheques
  - CHKOUT
    - SYSOUT=B - goes to the output spool queue named "B"
    - this is not the usual "A" queue; it's probably the the cheques
      being printed on a special printer
  - PAYIN
    - DD statement mentions as input DSN=PAYDATA, the same dataset
      that was output in the previous (CRETAP) step
    - DSN must be unique

- the third of the three steps in this job is named PRTREG
  - print the payroll register created in step 1?
  - Arrows: specify the I/O done by this step
    - three DD statements mean three arrows
    - one input arrow (PAYIN)
      - (can re-use same DDname in different steps)
    - two output arrows (SYSPRINT, REGOUT)
  - SYSPRINT
    - error listing?
  - REGOUT
    - payroll registry, sent to yet another spool queue "C"
    - a limit is placed on the number of print lines
  - PAYIN
    - this is, again, the same dataset generated by step 1
    - we read it a second time