The function of this chapter is to establish guidelines, rules, and procedures for the allocation and use of data storage .
The DTS Department of Technology Services, Data Management Unit (DMU) is responsible for direct access space allocation, development and enforcement of direct access data management standards, and data management, except for those instances noted in this chapter where the customer is explicitly responsible.
Customers may contact the DTS Department of Technology Services Data Management Unit (DMU) regarding questions or problems with Direct Access Storage Device (DASD Direct Access Storage Device) management.
Primary DASD Direct Access Storage Device volumes (i.e., SYSDA or TSODA) are where batch and online allocation of data sets occurs. A migrated data set is where a DASD data set, which exists on a primary DASD volume, is copied and compressed to either off-line DASD or tape pools. A customer can access (i.e., browse,edit) their migrated data sets from these pools by the process of a Recall (automatic restoring).
DMU will migrate cataloged SYSDA or TSODA data sets from Primary online DASD volumes to off-line DASD (level 1) or tape (level 2) in order to maintain a sufficient amount of Primary online DASD space for ongoing processing. The following processes have been implemented to administer this policy.
Inactive data sets are migrated from Primary online DASD (SYSDA or TSODA), compressed and placed on a separate pool of DASD volumes. Migrated DASD data sets are re-cataloged to a pseudo volume called MIGRAT. At this point, migrated data sets are unreadable to the end customer. However, a migrated data set can be automatically recalled to primary online DASD (level 0) by browsing, editing or displaying it.
Data sets residing in the primary online storage pools SYSDA or TSODA are subject to the migration process.
Data sets residing on SYSDA or TSODA that have not been used (browsed,edited) in the preceding 35 days are candidates for migration to off-line DASD level 1.
Migrated data sets having no expiration dates will be assigned a two year expiration date while in MIGRAT status. If a migrated data set (MIGRAT status) has reached it's assigned expiration date, it will be scratched immediately. Migrated data sets having valid expiration dates will be scratched after reaching their customer assigned expiration date.
Inactive data sets are migrated from off-line DASD (level 1) to tape (level 2). Tape (level 2) migrated data sets retain the catalog status of MIGRAT. Customers can automatically recall migrated data sets by browsing, editing or displaying them. Additionally, customers will be prompted that recall is coming from tape and that they will be notified when recall is completed.
Data sets residing on off-line DASD (level 1) for a period of 25 days (60 days total of non-usage) are candidates for migration to tape level 2.
If a migrated data set (MIGRAT status) has reached its assigned expiration date, it will be scratched immediately. Migrated data sets having valid expiration dates will be scratched after reaching their customer assigned expiration date.
DMU creates backup copies of all DASD Direct Access Storage Device data sets stored on DTS Department of Technology Services System volumes and on volumes managed by DMU. The backups of the System volumes assures expeditious recovery of the Data Center from any loss of critical System data or hardware. The backups of DTS Department of Technology Services managed volumes are taken primarily to assist customers recover from an unavoidable loss of data. For example, the loss of a head/disk assembly (HDA), which usually causes the loss of all data on a disk volume, can be recovered, i.e., data restored onto a replacement volume, with data current as of the problem Unknown underlying cause of one or more incidents. volume's last backup. Post-backup changes, i.e., data set changes, additions, and deletions, cannot be recovered by DMU.
The DTS Department of Technology Services backups cannot copy data sets that are in use at the time the backup jobs are executed. Therefore, customers should ensure that backups of their critical data sets are taken as needed.
|
Volume Pools |
Frequency |
Retention |
|
ADABAS |
Daily |
12 Days |
|
ADABAS |
Weekly |
49 Days |
|
ADABAS |
Monthly |
15 Months |
|
SYSTEM |
Daily & Weekly |
21 Days |
|
TSODA |
Daily & Weekly |
21 Days |
|
SYSDA |
Daily & Weekly |
21 Days |
|
DTS Department of Technology Services |
Daily & Weekly |
21 Days |
|
VM Virtual Machine OR Voice Mail |
Daily & Weekly |
21 Days |
ADABAS - volumes used for production and test ADABAS data bases supported and backed up by the DTS Department of Technology Services Data Base Software Support Section.
SYSTEM - volumes essential to providing data processing services, e.g., software such as MVS Multiple Virtual Storage, JES2 Job Entry Subsystem 2, VTAM Virtual Telecommunications Access Method – IBM International Business Machines Corporation software that controls communication and the flow of data in an SNA System Network Architecture – IBM’s proprietary network architecture and protocols. network by providing SNA application programming interfaces and SNA networking functions., CICS Customer Information Control System, IDMS Integrated Database Management System and DB2 Data Base Product.
SYSDA - volumes provided for batch space allocations.
TSODA - volumes provided for TSO Temporary Suspension Order OR Time Sharing Option space allocations.
DTS Department of Technology Services - volumes used for customer dedicated space.
VM - all volumes on the VM System.
Customers are responsible for:
More frequent backups, if required, of critical data stored on DASD volumes.
Creating long-term (retention period) backups, if needed, of data stored on DASD volumes.
All backups of data stored on customer dedicated volumes.
All backups of data base files supported and controlled by dedicated, online monitors.
Off-site storage, as needed, of their backups.
DMU provides data set restoration service from the DTS Department of Technology Services backups during normal working hours, 7:30 A.M. to 5:00 P.M., Monday through Friday. After-hours restore requests are subject to billing and must be approved by a customer supervisor; the billing exception is HHSDC-caused data loss.
DMU stores backups for operational recovery in the Disaster Off-site Library (DOSL Disaster Off-site Library), which is located off-site in a secure, concrete-reinforced vault.
The second-oldest (-1) generations of the weekly, full-volume backups are sent to DOSL Disaster Off-site Library after the latest or current (0) generations are created.
The third-oldest (-2) generations are returned from DOSL Disaster Off-site Library. The "Off-site Storage Schedule" on page 4-7shows which volume pool backups are stored off-site; their age at the time they are sent; the length of time stored off-site; and the extent of risk, in number of days, of volume changes (data set changes, deletions and additions) that could be lost if a disaster occurs at DTS Department of Technology Services.
Customers with the need to create and store more current backups of critical data sets are responsible for taking the additional backups, and sending them off-site.
For information on sending vital data to DOSL Disaster Off-site Library, see "Off-site Storage Schedule" below.
|
Volumes |
Age |
Off-Site |
Recovery Point |
|
ADABAS |
9 days |
7 days |
9 to 16 days |
|
SYSTEM |
8 days |
7 days |
8 to 15 days |
|
TSODA |
8 days |
7 days |
8 to 15 days |
|
SYSDA |
8 days |
7 days |
8 to 15 days |
|
VM |
8 days |
7 days |
8 to 15 days |
The following services are provided to customer departments:
Backups - DMU copies DTS Department of Technology Services DASD Direct Access Storage Device managed volumes to tape. The latest copies are retained on-site for full-volume and data set restores. The older copies are sent off site for operational (disaster) recovery.
DMU does not backup customer-dedicated DASD volumes except by prior agreement.
Customers are encouraged to backup their dedicated volumes; the DMU provides special backup programs to backup full-volumes.
To ensure proper recovery of a volume, only the DMU is authorized to restore volumes backed up with these programs.
DMU restores data sets from backups, provides additional sort-work files on request, and provides consultation services to customers interested in effective data management.
DMU provides DASD storage reports to customer departments. Please contact your departmental coordinator for report information.
DTS Department of Technology Services customers may allocate DASD data sets via batch jobs by coding 'UNIT=SYSDA' in their JCL Job Control Language statements or dynamically via TSO Temporary Suspension Order OR Time Sharing Option session under ISPF Interactive System Productive Facility option 3.2.
Naming standards are established as a basis for departmental data set identification. Be certain prior to using or allocating DASD data sets that the customer is fully acquainted with IBM International Business Machines Corporation constraints and considerations.
Additional information on calculating efficient blocksizes on DASD or cost comparisons between storing data on tape versus DASD, see TSO/ISPF option H.SPA. For further information, consult your JCL manual.
DTS Department of Technology Services customers are required to contact their manager or departmental coordinator in order to establish a departmental high level qualifier. The format is:
DSN=MMXXXXXX.OPTION.OPTION
Where: MM = the required departmental high level qualifier.
XXXXXX = either the departmental TSO Temporary Suspension Order OR Time Sharing Option user ID, departmental project or application high level qualifier.
OPTION = Optional departmental qualifier.
The high level index indicator is established in the master catalog by the DTS Department of Technology Services Technology Division before being used.
OPTION is at departmental discretion.
All DASD Direct Access Storage Device data sets that are to be retained must be cataloged.
If a DASD data set has been assigned an expiration date by the customer, that date will honored and will not be scratched until expiration date has been reached.
The 99365 expiration date will always be a "no scratch" date. You cannot expire a data set on 99365 because this is not a real date. Customers are advised to use the previous date of 99364 or the date 2000.001.
DASD data sets can be scratched by un-cataloging them or deleting them through SPF option 3.2, 3.4 or by TSO command statements.
When a data set is no longer needed, it can also be uncataloged through a batch job by coding JCL Job Control Language statements, 'DISP=(OLD,UNCATLG)' or 'DISP=(OLD,DELETE)' without specifying a volume reference. Scratching using 'DISP=(OLD,DELETE)', with a volume reference is not sufficient because it does not clean up the catalog entry for that data set.
As discussed in previous sections, DTS Department of Technology Services migrates DASD Direct Access Storage Device data sets from primary DASD volumes (i.e., SYSDA/TSODA) to either off-line DASD or tape storage hierarchy based on frequency of usage. This procedure is used to allow the end customer to automatically retrieve migrated DASD data with relative ease.
DTS Department of Technology Services presently uses non-IBM software products in order to implement this procedure. This philosophy of automatically moving data from primary DASD to storage hierarchy devices is a piece of what IBM International Business Machines Corporation calls System Managed Storage (SMS System Manage Storage). IBM's line of storage software products are all part of their Data Facility family of products. IBM's DFSMS Data Facility System Managed Storage software product provides many of the same benefits that the other vendors use to administer DASD but also allows the end customer to choose how their data is to be managed.
DFSMS promises to be more sensitive to online versus batch requirements. DFSMS also relaxes many JCL Job Control Language parameter requirements. Customers will no longer be required to be experts in DASD management, they can know focus on their real area of expertise, the application.
With DFSMS, a customer can now assign a DASD data set its Data Class (DC), which describes attributes, Management Class (MC Management Class), which describes the management of that data set, and Storage Class (SC), describing hardware performance requirements. This procedure will allow DTS Department of Technology Services to administer the flow of a data set allocation based on its assigned class attributes.
DTS Department of Technology Services and the Storage Management Group (SMG) have developed SMS Management Classes and Data Classes for customer use. This facility allows customers to specify new levels of data management services. To request this new level of data management services, specify the MGMTCLAS (Management Class) parameter on your DD JCL statement or on the TSO Temporary Suspension Order OR Time Sharing Option ALLOCATE command.
MGMTCLAS parameter syntax examples:
MGMTCLAS=MCSHORT <---- on DD JCL statement.
MGMTCLAS(MCSHORT) <---- on TSO ALLOCATE command.
The following lists Management Class (MC) services that are available.
MCSTD - Standard Service - DASD data sets are moved from primary storage to migration level 1 (ML1) storage after 35 days of non-use. After 25 days of non-use at ML1, it is moved to ML2 storage. This is equivalent to the current data management standards.
MCSHORT - Short Term Residency/Fast migration service - DASD data sets are moved from primary storage directly to migration level 2 (ML2) storage after 2-5 days of non-use. This could be used for data that is only used briefly but still is to be retained.
MCINTERM - Intermediate Term Residency/Fast migration service -DASD data sets are moved from primary storage to migration level 1 (ML1) storage after 10 days of non-use. This data will stay on ML1 storage. This could be used for data that is only used briefly but needs to be quickly recalled if needed.
MCLONG - Long Term Service - DASD data sets are moved from primary storage directly to migration level 2 (ML2) after 35 days of non-use. This could be used for data that needs to be kept for auditing or accounting requirements.
MCTEMPR - DASD data sets are NOT moved and NOT backed up. These data sets will be deleted after 3 days of creation date. This could be used for test data that does not need to be retained after it's use.
If you have questions regarding SMS allocations, contact::
Your departmental storage administrator.
DTS Department of Technology Services Data Management help desk. 739-7556
DTS Department of Technology Services Systems Software Support. 739-7811
Additionally, a DATACLAS (Data Class) parameter can be used to simplify allocations of new data sets.
CC
