Managing TSO Data

The following are the main benefits of managing TSO data:

TSO data sets benefit from DFSMShsm's fully automatic availability and space management for these data sets.
These data sets are usually smaller and have lower I/O activity than production data sets, and typically do not have predictable access or update patterns. Automation of these management services relieves application developers from time-consuming storage management tasks.
You can use DASD for TSO data sets more efficiently by specifying immediate release of unused space through management class.
Unused space is released at data set CLOSE time if you specify Partial Release=YES IMMED (or COND IMMED, to ensure that space is not released unless secondary space is specified) in the management class assigned to the TSO data set. This causes unused space to be released immediately if a secondary allocation is specified.
You can simplify JCL development requirements for your application developers and improve space usage for data sets with SMS data classes.
Using the DATACLAS parameter to supply DD statement parameters for frequently allocated data types benefits both you and application developers.
Some benefits of data classes are:
- Standards enforcement: The JCL simplification is attractive to application developers, and provides an incentive to conform to data set naming standards to fully automate data class assignment.
- Optimal block size usage: When allocation is assisted by data class specification, the system determines the optimal block size for the data set based on the device selected by SMS.
Using DFSMS's program management, you can store source and load libraries currently organized as PDSs in PDSE format.
The PDSE format is supported only by the program management binder and loader, not by the linkage editor. Unlike PDSs, PDSEs do not require periodic compression to consolidate fragmented space for reuse. You do not have to recreate PDSEs when the number of members expands beyond the PDS's available directory blocks. PDSEs are supported by many of the utilities that currently support PDSs. Members in PDSEs can be read and written concurrently by multiple systems.

SMS allocates TSO data in the PRIMExx and LARGExx storage groups, based on data set size. Data sets larger than 285 MB are directed to the LARGExx storage group. Listing data sets, SYSPRINT from compilers and linkage editors, are automatically deleted by DFSMShsm after a short life on primary storage. Active source, object, and load libraries exist on primary storage indefinitely. If these data sets are not used, they are migrated by DFSMShsm to migration level 1, but are recalled automatically when accessed by a user.

Multiple versions of backups of TSO data sets are maintained to minimize the effect of accidental deletion of application programmer data, such as source or JCL libraries. These data sets receive better-than-average availability service.

TSO data sets do not have high performance requirements in comparison to other data categories, and are assigned standard performance services.

The major tasks for managing TSO data include:

Review the planning considerations for data migration to system management, including fallback contingencies.
Design and test performance and availability services for TSO data.
Design and test backup and space management services for TSO data.
Determine your physical space requirements for TSO data and add volumes to the PRIMExx and LARGExx storage groups.
Determine any additional resources required for DFSMShsm space and availability management.
Activate new configuration.
Migrate TSO data.
Design and test automated data allocation, using data classes.