RTD is the only product in the world to optimise disk space utilisation while your z/OS DASD is in use.
FEATURES AND BENEFITS :
- Disk Space Recovery Around the Clock
- Automatic Optimisation in Real Time
- Batch Window Constraint Relief (BWCR)
- Stabilised Production by Avoiding x37 Abends
- Reduced Energy Consumption through Efficient DASD Usage
- Meet SLA's
- Efficient use of current DASD
- Delayed purchase of additional DASD
- Reduce overall growth rate
- No impact on system performance
Easy to install and manage through ISPF user interface - no MVS hooks and can run in simulation mode.
Highly scalable and easy to maintain. Data centres with a capacity ranging from 80 to 315,000 MIPS trust our solutions 24 hours a day, 7 days a week.
Recover disk space around the clock. RTD is always on, optimising disk space and improving performance.
Significantly reduces mainframe storage costs and not forgetting datacentre energy costs.
Supports all dataset types (DSORGs)
Full or Partial Space Release
Optional PDS Compression (prior to Space Release)
Avoid E37 abends
Improves application performance
Partial combine may be performed
Increases the size of free extents
Reduce the Fragmentation Index
Reduces B37 Abends
DFDSS must allocate the entire DASD Volume for the full amount of time required to perform a DEFRAG. RTD only allocates those datasets which it must move and only for the time required to move the dataset. Datasets which are in use will be bypassed for the current interval and processed during a subsequent interval. Since RTD runs continuously, the volumes are always in an optimal state. With DFDSS the volumes are optimal once a day or once a week. RTD does not require a Batch window to perform its functions. It works constantly keeping your DASD environment in an optimal, stable state.
You should consider RTD if:
1. The Batch window is too small to process all the Defrag jobs.
2. DASD volumes are under-utilized and jobs are terminated due to "out-of-space" conditions.
RTD processes all types of datasets.
Yes, RTD can process DB2 datasets.
DB2 (and probably the other data base subsystems) has a way to release data sets if nobody wants them. The theory is that access to the file would cause a slight delay as DB2 re-opened and primed the buffers. For DB2, the data base administrator sets the DSMAX parameter in DSNZPARM to a low number.
Then at inactive time:
- DB2 looks around and closes all but the most recently used files.
- RTD, processing its normal intervals finds the data base closed and operates on the data set. This is unique, because RTD only "holds" a data set for a few milliseconds, and therefore DB2 can quickly get the database reopened if someone appears
This is an important advantage for databases. If a user wants the data set after it has been closed by the subsystem, RTD only holds the data set for a few seconds and the file would be re-opened and the end user would never know the file had been worked on.
RTD processes datasets on the first volume for multi-volume datasets.
RTD processes database volumes the same as other volumes. However, one must realize that RTD will not process allocated datasets. Hence, individual databases will only be processed when they are not allocated.
Control parameters for RTD are entered via a user-friendly ISPF interface. The RTD Administrator defines which volumes (or SMS Storage Groups) will be processed, which functions will be performed, and the time interval for performing these functions. The control parameters may be changed at any time and become effective immediately.
RTD users tell us that RTD pays for itself within 6 to 12 months. Savings result from:
Increased DASD space utilization. Prior to RTD this is about 70-75%; with RTD this increases to 80-95%. Purchasing new DASD can be delayed.
Reduced number of Job abends due to space-not-available.
Increased stability of the production environment.
Reduced resources needed to perform Storage Management.
RTD users see DASD space utilization increase from 70-75% to 80-95%. The Fragmentation Index is reduced by 200-500 points.
The RTD processing interval can be defined on a volume-by-volume and function-by-function basis. In general, volume processing intervals are set at 30 or 60 minutes.
RTD uses standard MVS ENQs to allocate datasets which it would like to process. If the RTD ENQ request fails, RTD will bypass the dataset. During the next processing interval RTD may again attempt to allocate the dataset. If it is known that certain datasets are always allocated, the user can, if desired, easily exclude these from RTD processing.
Installation takes from 30 to 60 minutes. Defining the global parameters and the first volumes for RTD processing takes about 15 minutes. Other volumes are then added as required. Since RTD supports easy-to-use masking facilities, a few control parameters are sufficient for the entire DASD configuration. Once the parameters have been set, RTD users look at the Log every few weeks just to see how RTD is doing. That's all there is to it.
RTD processes both SMS and non-SMS managed volumes. RTD works independently of SMS. That is, RTD processing depends only on the parameters defined in the RTD control dataset. Additionally, SMS class names may be used for defining selection criteria to RTD.
Yes. Most RTD users have large DASD configurations (20 TB or more). Since RTD supports multi-tasking and requires a minimum of resources, a number of volumes may be processed concurrently.
No, this is not necessary. The critical factor for dataset allocation is the size of the 5 largest extents. All allocations (be they primary or secondary) must be contained in a maximum of 5 extents. If this is not possible, the allocation (and the job) will fail. RTD's goal is to ensure that the 5 largest extents are as large as possible. RTD reduces the possibility of job abends due to space not available.
RTD was designed to use a minimum of system resources. Hence, there is very little to do in the way of tuning. However, knowledge of the environment can be used to further reduce RTD resource utilization. For example, if it is known that certain volumes contain many datasets that are allocated for a certain time-frame, one can tell RTD to only process these volumes outside of this time-frame.
If all of the DASD volumes are shared (or accessible from a particular CPU) then RTD should run on only one system which has access to all of the volumes. If the volumes are not shared, RTD must run on each CPU with exclusive access to the volumes.
No. Since RTD only runs on one system, there are no special considerations for a Parallel Sysplex environment.