IBM OS/390 manual Access Method, Job Name, Common Applications Naming Conventions

C.3.6 Access Method

At one point in time, many installations adopted a policy of distinguishing VSAM data from non-VSAM data. The reality behind this standard was that there were many functions that were not supported for VSAM and this was an easy way to recognize that data.

The main reason for this distinction was because of old VSAM catalogs and the ²ownership² of the volume and data by VSAM. In order to avoid these problems, you had to separate the VSAM data from the non-VSAM data by catalog. We have come a long way since then and this notion is no longer needed with the use of ICF catalogs. There should be no distinction because of access method.

C.3.7 Job Name

Some installations have used the name of the job which created this data set. This is certainly a piece of information which is very likely to change. It usually says very little about what this piece of data actually is, since the job usually creates all sorts of data set types. It is not a good practice to include this information as a part of the data set name.

C.4 Common Applications - Naming Conventions

This section will focus on some of the common MVS applications that tend to put out a fair amount of data on the system and the suggestions for an associated naming convention.

C.4.1 TSO Naming Conventions

TSO certainly has a very recognizable data set naming convention. The rules are fairly simple and easy to understand:

∙

∙

Three levels of qualification: userid.dsname.dstype

Standard set of data set types (for example, CLIST, FORT, PLI, CNTL, and so on)

All of the TSO functions, commands and also the ISPF/PDF functions tend to complement this naming convention. Therefore, for ease of use and transportability, it is generally a good idea to maintain this convention.

Some applications run with production-type data under TSO using the standard JCL PROCs, CLISTs, and PANELS that would be used for the normal production data. For example, consider a programming application that had a naming convention of:

library.dstype.project.version.release

where:

library: (PROD, DEVL, or TEST)

dstype: (SOURCE, MACRO, LOAD, OBJ, JCL, and so on)

project: (APPLIC1, APPLIC2, . . .)

version: (V1, V2, . . .)

release: (R1, R2, . . .)

It would certainly be acceptable for unit testing on certain data to be done under a TSO user ID such that the user ID would be substituted for the ²library² and all of the remaining qualifiers would stay the same. The key point here is the

Appendix C. DFSMS Naming Conventions 549