KR editions 22 to 25

KR 22: MVS/JCL

We'll change track this week into JCLs.....but before going into JCLs we'll take a look at some basics in MVS..... 

When you request for a dataset in MVS, there are a few levels of allocation: 

1.) at the unit level 

2.) at the volume level 

Unit is also known as device. DASD is a device, TAPE is another device and so on. When we ask (or request) for a dataset, MVS has to first identify the device where the dataset resides. This unit will be allocated to your job. DASDs are sharable (i.e. 2 or more jobs can use the same DASD at the same time). But TAPES are not sharable (TAPE is a sequential device and if you want to read the 100th record, you should go through the first 99 to reach the 100th). So if your job requests for a dataset on a TAPE, then that TAPE is effectively locked (no one else can access the device till your job releases it). 

You can request for the device using a device address or a generic (group) name. Device address is a unique 3-digit Hexadecimal address which we wouldn't be able to remember. So we generally use the generic (or esoteric) name - example: SYSDA (refers to DASDs), 3350, 3390, TAPE. When we say SYSDA, we are not speciifying which DASD we want (MVS will decide which one to choose) but when we use a device address we are specifying the particular DASD (or device) to be used. 

You can also specify a volume (using a serial number) and MVS will choose that volume or else you can let MVS find out a volume from the catalog (i.e. if you don't specify a volume). What's a volume? A stack of metal plates coated with a metal oxide for storing data forms a disk pack or DASD or a volume. Every DASD has a unique volume-serial number (VOL-SER). When we ask for a dataset, MVS should first locate a UNIT (device), then a volume and finally the required dataset on that volume. 

KR 23: SMS

SMS (Storage Management Subsystem): 

This is an optional feature in MVS and it manages user datasets. It helps in simplifying JCLs as well (the programmer needn't worry about the DD parameters like UNIT, VOL, LRECL, RECFM etc...). 

There are some SMS parameters which we encounter frequently: 

1.) STORCLAS: This has to be coded to make the data set SMS-managed. This parameter replaces the UNIT and VOL parameter. This is related to storage of the dataset. 

2.) DATACLAS: could define any of the following parameters: RECFM, LRECL, AVGREC, SPACE, VOL etc... 

For example if the admin has defined a DATACLAS called COBOL with RECFM=FB, LRECL=80 then whenever you specify DATACLAS=COBOL in your JCL for a new dataset, that dataset will be created with RECFM of FB and LRECL of 80. It's kind of like a substitution. 

3.) MGMTCLAS: This parameter isn't used for replacing any DD parameter. This is used with regard to management of the dataset. Some uses are: 

    -to determine when the dataset has to be migrated to an archival storage. 

    -to determine how often a backup of the dataset needs to be created. 

    -how often the dataset should be compressed, etc... 

Should we always code these SMS parameters in our JCLs? Generally not a must since there will be some default values assigned at the client side. 

KR 24: DISP parameter

We'll get into a little JCL today regarding the DISP DD parameter in JCLs:

We use the DISP parameter to determine the current state of a data set and also tell the system what it has to do after the step completes (or in other words; how to dispose of the dataset after the step completes). The DISP parameter can take 3 parameters: 

1.) current state (called status) 

2.) what to do with the dataset if step ends normally (called normal-disp) 

3.) what to do with the dataset if the step abends (called abnormal-disp) 

DISP=(status, normal-disp, abnormal-disp) 

Default values: 

By default (if you don't specify the abnormal-disp), abnormal-disp will take the same value as normal-disp.

If status is not specified, then the status is taken to be NEW. In this case you'll need to code the UNIT and SPACE parameters.

If status is NEW and if we don't specify the normal-disposition, the normal-disp is taken as DELETE (which means that when the step completes normally, the dataset will be deleted).

KR 25: DISP cont.

The KR series has sucessfully completed a quarter century (KR batting 25*)...........hooray :-) 

In this edition we're continuing with the DISP parameter. 

DISP = (status, normal-disposition, abnormal-disposition) 

Let's look at the status parameter (which we sometimes confuse):     

• NEW- A new dataset has to be created and we'll specify the UNIT and SPACE parameter.
• OLD- The dataset exists and the operating system will search for the dataset. Using OLD we will have exclusive access of the dataset (i.e. only this step can use the dataset and no one else is permitted to use it at the same time). If we write to this dataset, we'll be deleting all existing data and then writing fresh (WE CAN'T APPEND).
• SHR- The dataset exists and we permit shared access (i.e. simulataneously many steps can read the dataset).
• MOD- There are 2 scenarios:
  a.) The dataset exists - records are appended at the end of the file.
  b.) The dataset doesn't exist - then the dataset is created (in other words the MOD becomes NEW).
  In both cases we have exclusive access.

Go back to the main contents page