2 Technical basics
Although I said above that the user of this book should have some skills in z/OS, I will give hereafter introductions to some important technical things.
2.1 Data sets
Processing of data is the main task of a z/OS system. Therefore, data sets are very important elements of this computing system.
 |
Remark: All information concerning data sets are containing in the following manual: z/OS V2R1 DFSMS Using Data Sets Form Number: SC23-6855 |
2.1.1 Allocation of data sets
The most used methods to allocate a data set are:
– Using JCL during running of a batch job Example: Create a new sequential data set on disk.
– By a TSO/ISPF user using ISPF menus or running procedures that contain ALLOC statements.
– Example: Create the same data set as above within a REXX program: dsn = "TESTUSR.TE33ST.X01"
2.1.2 Naming conventions for data set names
Basic structure of a DSN:
– A DSN is a structure of qualifiers subdivided by dots.
– A DSN is maximally 44 characters long including the dots between the qualifiers but without an eventually available member name with its brackets.
– A DSN consists of minimal two qualifiers.
– Each qualifier in a DSN is one to eight characters long, the first must be alphabetic (A to Z) or national (# @ $). The remaining seven characters are either alphabetic, numeric (0 - 9), national or hyphen (-).
– The number of qualifiers may be generally unlimited but the 44 character maximum length of the DSN bound it. This means there are maximal 22 qualifiers possible because a dot follows each qualifier without the last one.
– A DSN may expand by a member name enclosed in brackets.
For example, the following names are invalid data set names:
A name that is longer than eight characters (HLQ.ABCDEFGHI.XYZ)
A name that contains two successive periods (HLQ..ABC)
A name that ends with a period (HLQ.ABC.).
A name that contains a segment that does not start with an alphabetic or national character (HLQ.123.XYZ)
2.1.3 The relevance of qualifiers
Two parts of a DSN have a special impact when the z/OS system handles the data set. These parts are the first and the last qualifier. They are abbreviated → HLQ and →LLQ.
2.1.3.1 The high level qualifier (HLQ)
The first qualifier of a DSN is the High Level Qualifier. This qualifier has an important impact when the system handles the data set:
– The master catalog contains an alias entry for each HLQ used by TSO/ISPF users.
– This entry is normally the user’s name.
– This entry points to a user catalog.
– All information of user data sets then contains the user catalog.
– All data sets with the same HLQ are in the same user catalog.
Example: LISTCAT of an alias entry in a Master Catalog:
 |
Caution: If a user attempts to create a data set with a wrong HLQ, the system tries to catalog the data set in the master catalog. Nevertheless, a normal user has no UPDATE rights on the master catalog. Therefore, leads this attempt to an error. If you get such an error, first check the HLQ for correctness. |
Error messages when a user tries to allocate a data set with a wrong HLQ:
2.1.3.2 The last level qualifier (LLQ)
The LLQ is relevant to the data set characteristics and contents. Especially for ISPF data sets containing source codes of some programming languages e.g. COBOL, PL1, REXX and JCL. Example: The ISPF Editor interprets the LLQ to set the correct language depending on colored code for sources.
The SMS (Storage Management Service) system may contain standard allocation values for data sets with special LLQs.
Before I explain how you can work with data sets, I give a short description of data set types. A comprehensive description of data set types is in the following manual found:
z/OS V2R1 DFSMS Using Data Sets Form Number: SC23-6855
2.1.4.1 Partitioned data sets (PDS and PDSE)
At a glance:
– This is the most used data set type when we work with ISPF.
– The name means: These data sets are partitioned.
– A partitioned data set contains in its space members together with their data.
– A partitioned data set must reside on ONE disk volume.
– You can concatenate multiple data sets for input operations that are on the same or different volumes.
– Each member logically builds a complete data set. Therefore, the system handles it as a discrete collection of data.
– A partitioned data set arranges member names in ascending alphabetical order.
– The member names can have up to eight alphanumeric characters. The rules to build alphanumeric names can be above in section 2.1.2 Naming conventions for data set names on page 17 found. The same rules are also valid for member names.
There are two types of Partitioned Data sets: PDS and PDSE.
2.1.4.2 PDS
Description:
– A PDS can have maximal 16 extents.
– The space of a PDS is into two areas divided: The directory and the data area.
– The directory contains the member names with pointers to the data part of the member in the data area.
– The member’s directory of a PDS has a discrete number of directory blocks. The SPACE parameter of the allocation statement defines the number of blocks.
– The directory is located within the first extent of the PDS space. The directory can only contain a limited number of member names. When the directory has reached the maximum of member names, it is impossible to store more members in this PDS. There is no simple way to extent the number of directory blocks. There are utilities on the marked to expand a PDS directory dynamically. One of these utilities is PDSFAST sold by the company: Software Engineering of Amerika (SEA).
– The system writes the data of new or changed members always behind the data area of the last stored member. When a member changed and then restored under the same name, the data area that the member occupied earlier becomes free. This free space cannot be reclaimed until the PDS is compressed (online, or batch using the IEBCOPY utility).
– A store operation for a member fails if:
– The directory is full
– All 16 extents are full
– The disk is full
This method to put the data of each new or again stored member to the end of the data area has important benefits:
The NEWCOPY technique:
It is possible to update a PDS concurrently by more than one user working on some LPARs. Active programs on load libraries of transaction servers as CICS and IMS may be updated even these systems are running. The transaction system uses the old program until the operator refreshes it manually, because the server has saved the position of all programs when it starts. The server does not use the new version of such a program until it is by an operator command refreshed. In CICS, the refresh is by the command NEWCOPY performed. Of course, a PDS can only be compressed when all affected systems are shut down.
2.1.4.3 PDSE
A PDSE type data set is within the z/OS also called a LIBRARY.
– A PDSE can have up to 123 extents.:
– The member’s directory of a PDSE is located within the whole space of the data set. There is no limit to store additional members unless:
– All 123 extents are full.
– The disk is full.
– A PDSE is not compressible.
– When a member is stored, all free space will used. Newly formed gaps will immediately reused.
– The directory is physically located in the data space. Due to this, there is no limit for the number of members stored in a PDSE.
– The data space can grow up to a maximum of 123 extents on one disk volume.
– A compress is not necessary and not allowed.
Disadvantages of a PDSE:
– Concurrent updating of a PDSE by more than one LPAR is critical. This leads to a destruction of this data set.
– The performance of a very large PDSE containing thousands of members is remarkably lower than a same PDS is.
Example: Data Set Information of a PDSE:
I copied the data set of the PDS example to a PDSE. See the differences:
Screen 2.2: Data set information of a PDSE
Tips for using PDS versus PDSE:
– Load libraries for transactional server systems must be of type PDS.
– If several LPARS must use the same load library, allocate a PDS.
– User libraries only updated by one LPAR should be as PDSE allocated. The managing of a PDSE is much more convenient for the user.
– A library of thousands of members works faster when it is a PDS.
Consider the following rules when you allocate a PDS/PDSE:
– LRECL: 0 to 32760 Bytes (0 only for RECFM=U → Load libraries)
– RECFM: F, FB, FBA, V, VB, VBA, U
– DSORG: always PO
|
Remark: PDS and PDSE members processing is sequential. |
To allocate a PDS/PDSE member use the following statements:
2.1.5 Other data set types
Sequential data sets
This data set type is for ISPF user not very important. The LOG and LIST data sets in ISPF are sequential organized. The ISPF Edit and Browse facilities processes this data set type. Sequential data sets are expandable to over more than one volume.
VSAM data sets
The EDIT and BROWSE functions of ISPF cannot handle this data set type.
DB2 databases
The EDIT and BROWSE functions of ISPF cannot handle this data set type.
|
Remark: Some data managing systems for ISPF on the market are able to handle nearly all z/OS data sets types. One of these is IBM's File Manager for z/OS. See the section 1.15.3 File Manager for z/OS on page 14. |
2.1.6 Concatenated data sets basics
The z/OS offers the ability that many DD statements and many concatenated data sets in one job step to use. The maximum number of usable DD and concatenated data sets depends on the TIOT value in the ALLOXxx member in the data set SYS1.PARMLIB. See the section 9.7.1 Display of parmlib member ALLOCxx on page 174.
The following data set types may be concatenated:
– Sequential Data sets
– Partitioned Data sets
Rules:
– A string of concatenated data sets can only for input opened. It is unusable for output operations.
– All concatenated data sets must have the same record format (RECFM). The block size (BLKSIZE) may be different.
– If the RECFM is FB then the LRECL of all concatenated data sets must have the same length.
– Members of partitioned data sets as well as sequential data sets can appear in the same concatenation several times.
See a sample JCL using the IDCAMS utility to copy a combination of members and sequential data sets to one sequential output data set:
JCL 2.1: Copy job for concatenated data sets
2.1.7 Partitioned concatenated data sets
For ISPF, concatenated data sets are very important. Before ISPF can start, allocations of many data sets are required. The LOGON procedure runs under control of TSO and allocates all necessary data sets.
The following DD allocations must be available before ISPF starts. If ONE of these DD is not available, the ISPF start fails.
Table 2.1: Necessary data sets when ISPF starts
| Name | Used for | Remarks |
| ISPPROF | user profiles | output and input, no concatenation |
| ISPLLIB | programs used by ISPF | read only chain |
| ISPMLIB | message texts | read only chain |
| ISPPLIB | panel definitions | read only chain |
| ISPSLIB | ISPF skeletons | read only chain |
| ISPTLIB | ISPF tables input | read only chain |
| SYSPROC or SYSEXEC | command procedures | read only chain |
|
tip: You can use the ISPF utility DDLIST to display your current libraries and their allocated data sets. The following text shows a partly excerpt of the output of DDLIST: |
As you can see, for almost DD definitions concatenations are used.
ISPTABL and ISPPROF are the only ISPF data sets used by ISPF itself for output. ISPF stores changed ISPF tables back into these data sets. Therefore, there must be a library allocation without concatenated data sets.
A special case is the DD pair ISPTABL and ISPTLIB:
ISPF processes ISPTABL and ISPTLIB as follows:
ISPTABL→ ISPF uses this DD to store new and changed tables.
ISPTLIB → ISPF uses this DD to read tables.
As you can see in the above excerpt of a DDLIST display, the data set USER1.ISPPROF is the only data set in the allocation of ISPTABL and the first data set in the ISPTLIB concatenation. This construction guarantees that a changed member can always found at the next call for it.
Advantage of partitioned concatenated data sets:
When a member is in a chain of partitioned data sets searched, the first occurrence of this member will found and used even if there are additional members of the same name in a data set further down in the chain.
Examples:
– If a panel member in ISPPLIB is normally located in the third data set of the chain is changed and then written to the first data set of the chain it is found and used in the future always in the first data set of the chain.
– DDLIST was used to search the procedure member $DOC in all concatenated data sets. See the following excerpt of the DDLIST output:
When the procedure $DOC called for execution by ISPF the first occurrence contained in data set USER1.NEW.REXX is found and executed.
2.1.8 Sequential concatenated data sets
Basics:
The reading program sees the chain of concatenated data sets as one data set. The I/O system of z/OS reads sequential concatenated data sets as one data set. This means, there are all records of a chain of data sets read.
– The records are coming in, as they are located in the sequence of the data sets.
– The end of file condition is indicated when the last record of the last data set in the chain is reached.
Advantage of sequential concatenated data sets:
The I/O system reads collections of sequential data sets in one go.
|
Remark: |
| Members of partitioned data sets may be as a normal sequential data set used. Therefore, the input in the example below can be a mix of PDS members and sequential data sets. |
|
Caution: If a partitioned data set appears in such a concatenation without a member name, the IDCAMS utility copies only the directory of the PDS to output and no warning and no error message appears. |
JCL 2.2: Example job to copy a chain of concatenated data sets to one data set
2.1.9 Abbreviations concerning data sets
The following table shows some abbreviations and their meaning for data set handling:
Table 2.2: Abbreviations concerning data sets
| Abbr. | Full Name | Description |
| DSN | Data Set Name | name of a data set |
| PDS | Partitioned Data Set | partitioned Data Set |
| PDSE | Partitioned Data Set Extended | partitioned Data Set Extended |
| HLQ | High Level Qualifier | 1st qualifier of a DSN |
| LLQ | Last Level Qualifier | last qualifier of a DSN |
| VOLSER | Volume Serial Number | name of a disk volume |
| ENQ | enqueue | term to hold a resource |
| DEQ | dequeue | term to free a resource |
| DSLIST | Data Set List | collection of data set names |