Filter
Top Products
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