The function of this chapter is to establish guidelines, rules, and procedures for the allocation and use of data storage.
The OTech, 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 OTech Data Management Unit (DMU) regarding questions or problems with Direct Access Storage Device (DASD) management.
DASD Data Set Migration
Primary DASD 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.
Migration To Off-line DASD (level 1) Process
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.
Off-line DASD (level 1) Migration Criteria
- 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.
Migration To Tape (level 2) Process
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.
Tape (level 2) Migration Criteria
- 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.
Data Backup and Recovery
OTech Backup Responsibilities
DMU creates backup copies of all DASD data sets stored on OTech 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 OTech 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 volume's last backup. Post-backup changes, i.e., data set changes, additions, and deletions, cannot be recovered by DMU.
The OTech 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.
OTech Backup Schedule
|SYSTEM||Daily & Weekly||21 Days|
|TSODA||Daily & Weekly||21 Days|
|SUSDA||Daily & Weekly||21 Days|
|OTech||Daily & Weekly||21 Days|
|VM||Daily & Weekly||21 Days|
Volume Pool Descriptions:
- ADABAS - volumes used for production and test ADABAS data bases supported and backed up by the OTech Data Base Software Support Section.
- SYSTEM - volumes essential to providing data processing services, e.g., software such as MVS , JES2, VTAM, CICS, IDMS and DB2.
- SYSDA - volumes provided for batch space allocations.
- TSODA - volumes provided for TSO space allocations.
- OTech - volumes used for customer dedicated space.
- VM - all volumes on the VM System.
Customer Backup Responsibilities
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.
Data Set Restores
DMU provides data set restoration service from the OTech 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.
Off-site Storage for Disaster Recovery
DMU stores backups for operational recovery in the Disaster Off-site Library (DOSL), 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 after the latest or current (0) generations are created.
The third-oldest (-2) generations are returned from DOSL. 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 OTech .
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, see "Off-site Storage Schedule" below.
|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 OTech DASD 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.
Allocating Data Sets
OTech 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.
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 constraints and considerations.
Additional information on calculating efficient block sizes 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.
OTech customers are required to contact their manager or departmental coordinator in order to establish a departmental high level qualifier. The format is:
Where: MM = the required departmental high level qualifier.
XXXXXX = either the departmental TSO 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 OTech Technology Division before being used.
OPTION is at departmental discretion.
- All DASD 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.
Deleting/Un-cataloging disk data sets
- 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 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.
System Managed Storage
As discussed in previous sections, OTech migrates DASD 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.
OTech 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 calls System Managed Storage (SMS). IBM's line of storage software products are all part of their Data Facility family of products. IBM's DFSMS 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 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), which describes the management of that data set, and Storage Class (SC), describing hardware performance requirements. This procedure will allow OTech to administer the flow of a data set allocation based on its assigned class attributes.
OTech 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 ALLOCATE command.
MGMTCLAS parameter syntax examples:
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.
- OTech Data Management help desk. 739-7556
- OTech Systems Software Support. 739-7811
Additionally, a DATACLAS (Data Class) parameter can be used to simplify allocations of new data sets.