usability of the system and the need to manage it differently based on what set
of data this actually is.
C.4.2 VSAM Data Set Naming Conventions
Many companies have decided that it is a good idea to associate all of the VSAM
components with the base cluster by some recognition pattern. Some of the
reasons behind this have to do with billing, and also with the usability of doing
catalog locates and so on, to find all of the associated components easily with
available software technology.
The normal standard that has been adopted in most cases is the first portion of
the name being the cluster name and the component name of DATA, INDEX, or
AIX name. For example, consider a VSAM cluster of X.Y.Z that was a KSDS with
two AIXs which were also keyed data sets. Also, assume that there were two
path names defined over the alternate indexes. The set of names would be:
X.Y.Z
X.Y.Z.DATA
X.Y.Z.INDEX
X.Y.Z.PATH1
X.Y.Z.AIX1
X.Y.Z.AIX1.DATA
X.Y.Z.AIX1.INDEX
X.Y.Z.PATH2
X.Y.Z.AIX2
X.Y.Z.AIX2.DATA
X.Y.Z.AIX2.INDEX
C.4.3 DB2 Naming Conventions
The standard data set naming convention for all DB2 data sets is the following:
hlq.DSNDBx.dbname.tblspacename.I0001.A00n
where:
DSNDBx is
•
DSNDBC
-- cluster
•
DSNDBD
-- data component
•
DSNDBI
-- index component
dbname -- database name (user selected)
tblspacename -- table space name (user selected)
I0001 -- hard-coded constant
A00n -- where ″n″ is system generated for extensions to the table space
Although the DB2 naming convention is certainly distinguishable, it is difficult to
associate different management policies for different sets of data within a
particular database. For example, in a programming application, one can easily
imagine different management policies for things such as SOURCE, MACRO,
SCRIPT and so on, versus things such as OUTLIST, LISTING, TESTLIST, LIST,
ASMLIST and so on.
Not all data within an application has the same management criteria --in the
case of DB2 applications, it is difficult to place distinguishable characteristics
550 VSE to OS/390 Migration Workbook