Introduction

The CDT z Systems storage administration unit 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 CDT z Systems storage administration unit regarding questions or problems with direct access storage device (DASD) management.

DASD Dataset Migration

The Data Center uses an IBM software tool called hierarchical storage manager (HSM) for dataset migration. HSM is a data storage system that automatically moves data between high-cost and low-cost storage media. High-speed storage devices, such as DASD, are more expensive (per byte stored) than slower devices, like tape drives. Actively used data is stored on DASD (level 0). Less frequently used data is stored on tape (level 2) and moved back to DASD when needed.

This reduces storage costs for customers while ensuring that a sufficient amount of DASD space is available for ongoing processing. The following processes have been implemented to administer this policy.

Allocation on Primary DASD (Level 0)

Datasets that are assigned an esoteric of SYSDA, MISCDA, or TSODA, are initially allocated on DASD. These datasets are always online and can be accessed immediately. As the dataset gets older and is infrequently used, it is migrated to level 2.

Migration to Tape (level 2) Process

Inactive datasets are migrated from primary online DASD to tape. Migrated DASD datasets are re-cataloged to a pseudo volume called MIGRAT2. At this point, migrated datasets are unreadable to the end customer. However, a migrated dataset can be automatically recalled to online DASD by an HRECALL command, or by browsing, editing, displaying, or referencing it via a batch job. Additionally, customers will be prompted that the recall is coming from tape, and are notified when the recall is completed.

The management class assigned to a dataset defines the migration criteria. Most datasets in the general pools are eligible for migration after 7 days of non-use.

Data Backup and Recovery

Incremental backups are performed regularly on all data that resides in the data center managed pools, i.e. all volumes except dedicated volumes. (Dedicated volumes are assigned and billed to a customer who is responsible for all storage management activities for that volume.) All backups are written to high capacity tapes.

Incremental Backups

Incremental backups are performed by a software product called hierarchical storage manager (HSM), and are done at the dataset level. These are logical backups of the datasets that are newly created or have changed since they were last backed up. All SMS datasets in the general pools are backed up by HSM.

• Frequency – Datasets are backed up late evening/early morning after they are created or modified, every single day of the week on Rancho Cordova.
• Retention – The seven latest versions of a dataset are retained for a maximum of 30 days. If a dataset is deleted, the last backup copy is retained for 90 days.
• Off-site Storage – All backups are replicated off-site using a virtual tape server (VTS) for the defined retention period.
• Exceptions – Datasets that are in use at the time of the backups are skipped and NOT backed up.
• Restore – Customers can do their own restores via the HRECOVER panel. If additional help is needed, customers can initiate an incident ticket by contacting the Service Desk at (916) 464-4311.

Customer Responsibilities

• 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.
• Datasets that are in use during the CDT backup window.
• Database files.

Full Volume Backups

Full volume backups are performed by a software product called FDR. All system volumes are backed up on a weekly basis and kept for 30 days.

Allocating Data Sets

CDT customers may allocate DASD data sets via batch jobs by coding ‘UNIT=SYSDA’ in their JCL statements or dynamically via TSO session under ISPF option 3.2.

Retention

• All DASD datasets that are to be retained must be cataloged.
• Expiration dates assigned by the customer will be honored.
• Datasets without a retention period will be scratched per the management class constructs.
  Note:
  On Rancho Cordova, datasets with the default management class of MCSTD are scratched after 7 days of creation if a retention period is not specified.
  On Vacaville, datasets with the default management class of MCSTNDRD are scratched after 60 days of creation if a retention period is not specified.