Filter
Top Products
There are two basic pieces of information that one should be able to obtain from
the data set name:
1. Who owns it?
2. What is it?
The following section will highlight all of the basic components that could
potentially be used in a data set naming standard.
C.2 Components of a Data Set Name
Not all of the following levels of qualification are necessary for naming data sets.
Instead, these represent some common levels of qualification that one tends to
find in a good and meaningful data set naming convention. Some of the
qualifications make sense for certain types of data while other levels don′t. This
list is intended to be a superset of all possible types of qualification levels.
Also, not all of these levels have to be coded as a separate level of qualification
(that is, separated by periods). Other possibilities are via positional characters
within a given qualifier. The one exception to this is the High-Level Qualifier
(HLQ). You should not create unnecessary numbers of these due to positional
characters. This is explained in more detail in the next section.
C.2.1 High-Level Qualifier (HLQ)
The HLQ should identify who ″owns″ the data. This could be for things such as
billing purposes, or simply for locating the owner in case of a problem. It may
represent a user ID, a project, an application, a business unit or a group. It may
also represent a sharing of the same set of data by a set of individuals from a
security standpoint (for example, as the notion of RACF userid and groupid).
There should be no other levels of qualification imbedded in this portion that
would tend to artificially multiply the number of HLQs in an installation. The goal
should always be to minimize the number of HLQs to the point that they serve
the management purpose (that is, billing, identification and so on).
It may be important to even have a standard convention within the HLQ. For
example, all TSO user IDs begin with a ″$″ as the first character -- this would
allow the Storage Administrator to easily avoid filter collisions in ACS Routines.
Again, the goal of doing this would be to allow the Storage Administrator to do
his job more easily in that all TSO data could be simply filtered out. The trade-off
here, of course, would be with the usability of the TSO LOGON IDs.
Another trade-off would be the intent of managing groups of application data. It
may be more important, for example, to associate certain TSO LOGONs with the
particular application area so that large applications could easily be identified
and moved by filtering on the first character of the HLQ. There is also a usability
problem here in that the TSO user would have to keep changing his ID if his job
changed from one large application to another. This also means that electronic
mail might be a problem if individual users have a lot of LOGON ID changes --
this also has some security implications as well (electronic mail being sent to
the wrong ID).
Note: As a personal recommendation from the author, it has been found that
one tends to cause more problems by choosing user IDs that will definitely
change due to such things as career changes. A better way is to have
544 VSE to OS/390 Migration Workbook