ADAORD, LIP, and Runtime

, , ,
1

I tried to improve the runtime of ADAORD REORFILE utiltity to reorder a file with 140,000,000 records.

The Manual points out that you can decrease the number of ASSO I/O operations by increasing the LIP parameter. This will reduce the time, when recreating the address converter (AC)

LIP = (ISNSIZE + RABNSIZE) * number of records
LIP = (4 + 4) * 140,000,000
LIP = 1,120,000,000 (=best performance) ???

ADA744:
ADAORD REORDER ASSOCIATOR and DATASTORAGE of single file

First run:
REGION=1000M LPB=32767,LIP=500000K
Start: 2008-07-14 10:04:04
Stop: 2008-07-15 13:08:54 (27 hours 8 min)
CPU 21MIN 45.75
135,649,250 Data Storage Records Processed.
Largest record has 549 bytes
1 hour between tape switches

Second run:
REGION=200M LPB=32767,LIP=180000K
Start: 2008-07-28 10:08:39
Stop: 2008-07-29 01:24:00 (15 hours 16 min)
CPU 21MIN 10.69
135,649,250 Data Storage Records Processed.
Largest record has 549 bytes
30 min between tape switches

It seems to me that ADAORD has problems to administer or access a huge LIP area.

Maybe someone from SAG can shed some light on this.

I also will discuss this during my presentation at the Natural Conference in Boston.

Thanks.
Dieter Storr

2

Yes, we used VTS, as Brian asked on SAG-L.

RMF shows a major difference in the MPM I/O activity. The bigger the LIP the more DATA volumes are used in a measured two-minute intervall and the EXCP rate drops from 1,145.0 to 575.1 per second.

It seems to me that the ADAORD code needs some improvements.

Dieter Storr

3

We solved our runtime problem.

Our space management group moved most of our ASSO and DATA disks to non-PAV volumes (non-parallel access). The bigger the LIP, the more was our I/O subsystem waiting to do parallel restores/regenerates. There is no bug in the ADAORD utility. Sorry, SAG, for this red herring.

Recommandation: check your environment, especially ADABAS, for non-PAV volumes. How? Use RMF monitor, for example.

After we moved to PAV volumes, one of our batch job stream was finished in 14:43 hours, instead of 78:21 hours.

Wow…

Have a great weekend.

Dieter Storr