Optimising mainframe DASD

24/7 Disk Management

RealTime Defrag (RTD) for z/OS and DB2 

RTD is the only product in the world to optimise disk space utilisation while your z/OS DASD is in use.


 - 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.



Returns allocated but unused space to the system

Supports all dataset types (DSORGs) 
Full or Partial Space Release
Optional PDS Compression (prior to Space Release)


Combines the extents of a dataset

Avoid E37 abends
Improves application performance
Partial combine may be performed


Move datasets into contiguous groups

Increases the size of free extents
Reduce the Fragmentation Index
Improves performance
Reduces B37 Abends


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.

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.





Contact Us

Automating your Enterprise