IBM OS/390 User Manual
C.3.2 Application Location
If this application ever got moved to another site, then all of the data sets would
have to be renamed. In some cases, it could be important to name the data by a
location name, for example, CHICAGO. This could be perfectly acceptable in
certain cases. Suppose there were two telephone directory files,
have to be renamed. In some cases, it could be important to name the data by a
location name, for example, CHICAGO. This could be perfectly acceptable in
certain cases. Suppose there were two telephone directory files,
″
TELPHDIR.CHICAGO
″
and
″
TELPHDIR.PODUNK
″.
This would be okay. That
′
s
because it is very unlikely that either Chicago or Podunk would ever move.
Application workload is another story. For example, if an application currently
runs in Chicago, or Podunk, one might be tempted to include this as part of the
data set name for disaster/recovery purposes. If there is a chance of moving
these applications to run in a different location, then it would be a bad idea to
imbed it into a name.
runs in Chicago, or Podunk, one might be tempted to include this as part of the
data set name for disaster/recovery purposes. If there is a chance of moving
these applications to run in a different location, then it would be a bad idea to
imbed it into a name.
C.3.3 Management Criteria
This type of generic criteria that some people recommend is the notion of
identifying disaster/recovery data, or vital records, for example within the data
set name. In general, it is not a good idea to imbed management criteria within
the data set name, since it is mainly driven by the technology at hand. They may
also change for business reasons (for example, a change in the state laws).
identifying disaster/recovery data, or vital records, for example within the data
set name. In general, it is not a good idea to imbed management criteria within
the data set name, since it is mainly driven by the technology at hand. They may
also change for business reasons (for example, a change in the state laws).
If either the technology or the business reason changes, then the data set would
have to be renamed to match it. One should simply name the data for what it is
and keep its management policy separate.
have to be renamed to match it. One should simply name the data for what it is
and keep its management policy separate.
Therefore, it is not a good idea to specify qualifiers such as
″
DR
″
or
″
VITALREC
″.
By always naming the data for what it is, the policy for managing it can be kept
separately without ever needing to rename the data.
separately without ever needing to rename the data.
C.3.4 Output Device Type
This is a general class of information that is also based on a certain level of
technology. As technology improves, you may very well decide to change the
way it is managed. For example, you might put a data set qualifier of MICROFIC
to indicate that this data set should be put out to microfiche -- whereas
somewhere in the future, one could envision this same piece of data being put to
a high-speed link which is connected to some automated high-capacity storage
device.
technology. As technology improves, you may very well decide to change the
way it is managed. For example, you might put a data set qualifier of MICROFIC
to indicate that this data set should be put out to microfiche -- whereas
somewhere in the future, one could envision this same piece of data being put to
a high-speed link which is connected to some automated high-capacity storage
device.
Qualifiers such as
″
TAPE
″
or
″
DISK
″
or
″
T3480
″
or
″
T3490
″
should never be
coded in data set names. This type of qualifier is destined for change as newer
device technologies are created.
device technologies are created.
C.3.5 Expiration Date
The EXPDT and RETPD allocation keywords associated with the data set are
another form of management criteria in that they specify the purge date for data.
These keywords clearly put storage management in the hands of the end users.
another form of management criteria in that they specify the purge date for data.
These keywords clearly put storage management in the hands of the end users.
To change the policy, you must change the date associated with the data set.
This is just as bad as forcing the application to go back and re-figure the new
management criteria. It represents a policy of sorts and therefore, should be
separated from the name itself. This type of information should be allowed to
change without actually changing the name of the data.
This is just as bad as forcing the application to go back and re-figure the new
management criteria. It represents a policy of sorts and therefore, should be
separated from the name itself. This type of information should be allowed to
change without actually changing the name of the data.
548
VSE to OS/390 Migration Workbook