Archive for September, 2010
Generation Data Group (GDG)
Posted by Rui Miguel Feio in MVS, Storage, Tech - Mainframe on September 18, 2010
GDG is a collection of historically related non-VSAM data sets that are arranged in chronological order. Each data set within a GDG is called a generation data set (GDS) or generation.
Within a GDG, the generations can have like or unlike DCB attributes and data set organizations. If the attributes and organizations of all generations in a group are identical, the generations can be retrieved together as a single data set.
Generation data sets can be sequential, PDSs, or direct (BDAM). Generation data sets cannot be PDSEs, UNIX files, or VSAM data sets. The same GDG may contain SMS and non-SMS data sets.
Advantages to grouping related data sets include:
- All of the data sets in the group can be referred to by a common name.
- The operating system is able to keep the generations in chronological order.
- Outdated or obsolete generations can be automatically deleted by the operating system.
To define a GDG you must first create a GDG base. This base defines the base portion of the dataset names used by the GDGs as well as defining how many generations (files) can be stored within the GDG. Once this maximum number of generations is reached, creating a new generation will result in the oldest generation being discarded. A GDG can hold up to 255 generations.
The files within a GDG are assigned names derived from the name of the base and have a generation number added to the end so as to give each file a unique name.
For example:
GDG base name: TEST.DATASET
The first file created within this GDG will be given the name TEST.DATASET.G0001V00
Subsequent files will be named by incrementing the generation number:
G0002V00, G0003V00, etc. all the way up to G9999V00
Once the G9999V00 generation number is reached the numbering will start again from G0001V00.
Notes:
1. The two zeroes on the end of the name are now usually used for version control.
2. Only one version is kept for each generation.
Generation data sets have sequentially ordered absolute and relative names that represent their age. The operating system’s catalog management routines use the absolute generation name (ex: TEST.DATASET.G0002V00). The relative name is a signed integer used to refer to the latest (0), the previous (-1) and the next (+1), and so forth, generation.
Example:
Previous: TEST.DATASET(-1)
Current: TEST.DATASET(0)
Next: TEST.DATASET(+1)
Next +1: TEST.DATASET(+2)
Referencing the entire GDG
It is possible to reference the entire GDG as if it were a single file by using the base name instead of an absolute or relative file reference. All files within the GDG will then be processed starting from the oldest generation and ending with the latest one. Note that to be able to reference all of the generations at once in this way that all of the files need to be defined with the common Data Control Block information (ex: the same record length). If the files within a GDG are never to be referenced this way then there is no requirement that they have any file attributes in common.
Rolled in and rolled off
When a GDG contains its maximum number of active generation data sets in the catalog, defined in the LIMIT parameter, and a new GDS is rolled in at the end-of-job step, the oldest generation data set is rolled off from the catalog. If a GDG is defined using DEFINE GENERATIONDATAGROUP EMPTY and is at its limit, then when a new GDS is rolled in, all the currently active GDSs are rolled off.
JCL most common operands
Posted by Rui Miguel Feio in JCL, Tech - Mainframe on September 9, 2010
1. JOB Statement
| REGION= | Requests specific memory resources to be allocated to the Job |
| NOTIFY= | User to be notified at job completion |
| USER= | Userid to assume authority to the Job |
| TIME= | Limits the amount of time a program can run |
| TYPRUN= | Delays or holds the Job from running |
| CLASS= | Directs JCL to execute on a particular Input queue |
| MSGCLASS= | Directs Job output to a particular Output queue |
| MSGLEVEL= | Controls the number of system messages to be received |
2. EXEC Statement
| PGM= | Executable program name |
| PROC | Procedure name |
| PARM= | Parameters known by and passed to the program |
| COND= | Boolean logic for controlling the execution of other EXEC steps in this job |
| TIME= | Imposes a time limit |
3. DD Statement
| DSN= | Name of the data set |
| DISP= | Data Set disposition (see below for more information) |
| SPACE= | Amount of disk storage request for a new data set |
| SYSOUT= | Defines a print location (and the Output queue or data set) |
| VOL=SER= | Volume name, disk name, or tape name |
| UNIT= | System disk, tape, special device type, or esoteric |
| DEST= | Routes Output to a remote destination |
| DCB= | Data Set Control Block: LRECL, RECFM, BLKSIZE, DSORG |
| LABEL= | Tape label expected (No Label or Standard Label followed by the Data Set location) |
| DUMMY | Results in a NULL Input or throwing away data written to this DD name |
| * | Input data or control statements follow |
DISP parameter
Define as DISP=(status, normal end, abnormal end)
Status
| NEW |
|
| OLD | This job is to have exclusive access to the data set while it is running |
| SHR | Several concurrent jobs can share access to this data set while they are running |
| MOD |
|
Normal and Abnormal Ends
| DELETE | Delete and uncatalog the data set at the end of the job step |
| KEEP | Keep the data set at the end of the job step but do not catalog |
| CATLG | Keep the data set at the end of the job step and catalog it |
| UNCATLG | Keep the data set but uncatalog it at the end of the job step |
| PASS | Allow a later job step to specify a final disposition |
Virtual Storage Access Method (VSAM)
Posted by Rui Miguel Feio in Glossary, MVS, Storage, Tech - Mainframe on September 9, 2010
VSAM applies to both a data set type and the access method used to manage various user data types.
VSAM data sets are held on direct access storage devices (DASD) auxiliary storage. VSAM divides its data set storage into control areas (CA), which are further divided into control intervals (CI). Control intervals are the unit of data transmission between virtual and auxiliary storage. Each one is of fixed size and, in general, contains a number of records. A KSDS or ESDS can have records that extend over more than one control interval. These are called spanned records.
VSAM is primarily used for applications.
VSAM types:
KSDS:
- Key-Sequenced Data Set
- This is the most common use for VSAM
- Each record has one or more key fields and a record can be retrieved (or inserted) by key value.
- To find the physical location of a record in a KSDS, VSAM creates and maintains an index. This relates the key of each record to the record’s relative location in the data set. When you add or delete records, this index is updated accordingly.
- It provides random access of data.
- Starting with releases of DFSMS/MVS 1.4 and later, a data set can be greater than 4GB in size if it is defined as extended format and extended addressability in the storage class
- The KSDS cluster has two components in it:
- Index component
- Data component
ESDS:
- Entry-Sequenced Data Set
- Keeps records in sequential order
- Each record is identified by its Relative Byte Address (RBA)
- Records are held in the order in which they were first loaded into the data set.
- New records added to an ESDS always go after the last record in the data set.
- You cannot delete records or alter their lengths. After a record has been stored in an ESDS, its RBA remains constant.
- When browsing, records are retrieved in the order in which they were added to the data set.
- A standard ESDS (32 bit RBA) cannot contain more than 4 gigabytes (GB) of data. However, there is a different kind of ESDS that supports 64-bit Extended Relative Byte Addresses (XRBAs) and which is therefore not subject to the 4GB limit
RRDS:
- Relative Record Data Set
- RRDS records are identified by their Relative Record Number (RRN). The first record in the data set is RRN 1, the second is RRN 2, and so on.
- Provides random access and assumes the application program has a way to derive the desired record numbers.
- Records in an RRDS can be fixed or variable length records, and the way in which VSAM handles the data depends on whether the data set is a fixed or variable RRDS.
- A fixed RRDS has fixed-length slots predefined to VSAM, into which records are stored. The length of a record on a fixed RRDS is always equal to the size of the slot. VSAM locates records in a fixed RRDS by multiplying the slot size by the RRN (which you supply on the file control request), to calculate the byte offset from the start of the data set.
- A variable RRDS, on the other hand, can accept records of any length up to the maximum for the data set. In a variable RRDS VSAM locates the records by means of an index.
- A fixed RRDS generally offers better performance. A variable RRDS offers greater function.
- With releases of DFSMS/MVS 1.5 and later, a data set can be greater than 4 GB in size if it is defined as extended format and extended addressability in the storage class.
LDS:
- Linear Data Set
- It’s in effect a byte-stream data set and is the only form of a byte-stream data set in traditional z/OS files (as opposed to z/OS Unix files).
- A number of z/OS system functions use this format heavily, but is rarely used by application programs.
- It is a VSAM data set with a control interval size multiple of 4096 bytes.
- In a sense, a LDS is a non-VSAM file with some of the VSAM facilities, such as the use of IDCAMS and VSAM specific information in the catalog.
- The most common LDS exploiter is DB2
- Like the ESDS and RRDS, an LDS contains a data component only.
Linklist
Posted by Rui Miguel Feio in Glossary, MVS, Tech - Mainframe on September 8, 2010
- Linklist is used to improve the performance of program management and mechanisms utilized to locate and fetch Load modules, such as LLA and VLF.
- Linklist is a group of system and a user-defined Load library that is a continuation of SYS1.LINKLIB and also indicates the search order the system uses for programs.
- Can have PDS and PDS/E libraries in its concatenation.
- The data sets are concatenated in the order in which they appear in the Linklist, and the system creates a Data Extent Block (DEB) describing the data sets concatenated to SYS1.LINKLIB and their extents.
- By default Linklist begins with:
- SYS1.LINKLIB
- SYS1.MIGLIB
- SYS1.CSSLIB
- The linklist concatenation can be defined in PARMLIB members PROGxx or LNKLSTxx.
Notes:
When determining which data sets LLA and VLF are to manage, try to limit the choices to production Load libraries that are rarely changed. This avoids a refresh of LLA or VLF operations.
Virtual Lookaside Facility (VLF)
Posted by Rui Miguel Feio in Glossary, MVS, Tech - Mainframe on September 4, 2010
- VLF keeps objects (for example Load modules) in Virtual Storage in order to save I/O operations that would load such objects.
- Designed primarily to improve performance by retrieving the most currently used objects from Virtual Storage rather then performing repetitive I/O operations from DASD.
- VLF can be configured by using PARMLIB member COFVLFxx.
Examples of some VLF exploiters:
- LLA (for Load modules)
- TSO (for REXX and CLIST procedures)
- CAS – Catalog Address Spaces (for User Catalog entries)
- RACF records from its database
Library Lookaside (LLA)
Posted by Rui Miguel Feio in Glossary, MVS, Tech - Mainframe on September 4, 2010
- It’s a program management z/OS component that keeps in Virtual Storage Directory entries from Load module libraries, thereby speeding up the fetch of a Load module.
- LLA improves the performance of Load Module Directory searching on the system.
- LLA can be a user of VLF facilities to keep copies of Load modules in VLF data spaces.
- LLA manages Linklist libraries by default.
- Code CSVLLAxx Parmlib member to include, modify or remove libraries.
- Specify LLA with SUB=MSTR to prevent LLA from failing if JES2 fails.
- Because LLA manages Linklist libraries by default, we only need to determine which non-Linklist libraries LLA is to manage.
- If we don’t want LLA to manage particular Linklist libraries, we must explicitly remove such libraries from LLA management by using the CSVLLAxx Parmlib member.
- When used with VLF, LLA reduces the I/O required to fetch Load modules from DASD.
Note:
SUB=MSTR indicates that the MASTER Subsystem will be the subsystem that will process the task.
What is a VTAM major node?
Posted by Rui Miguel Feio in Glossary, Tech - Mainframe, VTAM on September 4, 2010
A major node is a list of parameters that define a specific type of network device or group of related devices that VTAM can address.
To define the attachment of any device or set of devices to VTAM, you need to code a major node member in the VTAMLST data set.
Useful VTAM commands
Posted by Rui Miguel Feio in Tech - Mainframe, VTAM on September 4, 2010
1. Display commands
| D NET,VTAMOPTS | Display VTAM options, including SUBAREA Number, NETID, SSCPNAME, SSCPID |
| D NET,BFRUSE | Display information about VTAM¢s virtual storage and buffer pool usage |
| D NET,APPLS | Display the applications (APPLIDS) that VTAM knows about |
| D NET,PATHTAB | Display the status of communications PATHs between subareas in the VTAM network |
| D NET,MAJNODES | Display details about major nodes |
| D NET,ID=… | Display information about the specified VTAM resource |
| D NET,ID=…,E | Display more information about the specified VTAM resource |
2. Vary commands
| V NET,ACT,ID=… | Activate the specified resource |
| V NET,INACT,ID=… | Deactivate the specified resource |
| V NET,INACT,ID=…,I | Immediately deactivate the specified resource |
| V NET,INACT,ID=…,F | Force-deactivate the specified resource |
| V NET,ACQ,ID=… | Acquire the specified resource (NCP or non-switched PU) without activating it – used during network recovery whereby this VTAM can take ownership of another VTAM¢s resource |
3. Modify commands
| F NET,TNSTAT,CNSL=YES | Activate the VTAM tuning statistics display and output to the console |
| F NET,NOTNSTAT | Deactivate the VTAM tuning statistics display |
| F NET,TRACE,… | Initiate or Modify VTAM tracing |
| F NET,NOTRACE,… | Terminate VTAM tracing |
4. Halt commands
| Z NET | Terminate VTAM processing normally |
| Z NET,QUICK | Terminate VTAM processing immediately without waiting for normal termination of existing sessions – should only be used when normal termination does not complete successfully |
| Z NET,CANCEL | Abends VTAM – should only be used when both Z NET and Z NET,QUICK are unsuccessful |
Modified Link Pack Area (MLPA)
Posted by Rui Miguel Feio in Glossary, MVS, Tech - Mainframe on September 4, 2010
- It’s defined in SYS1.PARMLIB(IEALPAxx).
- Can be used to contain reenterable load modules from APF-Authorized libraries that are to be part of the pageable extension to the Link Pack Area (LPA) during the current IPL.
- Can only have PDS files. PDS/Es are not allowed.
- LPA modules that have been replaced through IEALPAxx are not physically removed from the PLPA or from the PLPA directory. They are however, logically replaced, because when one of them is requested, MLPA is searched first and then the system does not examine the LPA directory that contains the name of the replaced module.
- The system searches FLPA before MLPA for a particular module and selects the module from MLPA only if the module is not also in the FLPA.
- You may use IEALPAxx to temporarily add or replace SVC or ERP routines. Another possible application would be the testing of replacement LPA modules that have been altered by PTFs.
- Modules with an RMODE of 24 are placed in the MLPA, while those with an RMODE of ANY are placed in the extended MLPA.
Fixed Link Pack Area (FLPA)
Posted by Rui Miguel Feio in Glossary, MVS, Tech - Mainframe on September 4, 2010
- It’s defined in SYS1.PARMLIB(IEAFIXxx).
- It’s a non-pageale area of storage.
- It’s loaded at IPL time from IEAFIXxx.
- The data sets in its concatenation must be in the Master Catalog.
- The Load modules must be kept in Fixed Storage Frames, ie, they cannot be paged out.
- This area should be used only for Load modules that should not allow page faults because of integrity considerations.
- Modules must be reenterant and refreshable.
- The advantage of using the FLPA is the reduction in the Central Storage available for paging old jobs and starting new jobs.
- Any library that includes modules for the FLPA must be a PDS. We cannot use PDS/Es in the LPALST concatenation.
- Because Fixed modules are not paged, we can save I/O time and paging overhead by placing moderately used modules into FLPA.
- The price for this performance improvement is the reduction in Storage available for paging old jobs and starting new jobs.
- Modules with an RMODE of 24 are placed in the FLPA, while those with an RMODE of ANY are placed in the extended FLPA.
Content:
- Load modules from LPALST concatenation, the LNKLST concatenation, SYS1.MIGLIB, and SYS1.SVCLIB can be included in the FLPA.
Notes:
- Pages referenced frequently tend to remain in Central Storage even if they are not Fixed.
Follow Me!