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.