# ADAORD, LIP, and Runtime **URL:** \ **Category:** Forum\ **Tags:** Adabas-Natural, Adabas, Adabas-on-Mainframes, Adabas-Utilities-on-Mainframes\ **Created:** [July 30, 2008, 3:16am UTC](https://techcommunity.softwareag.com/t/adaord-lip-and-runtime/78652 "2008-07-30T03:16:00Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Dieter\_W\_Storr](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/dieter_w_storr/32/91_2.png) [@Dieter\_W\_Storr](https://techcommunity.softwareag.com/u/Dieter_W_Storr)\ **Post date:** [July 30, 2008, 3:16am UTC](https://techcommunity.softwareag.com/t/adaord-lip-and-runtime/78652/1 "2008-07-30T03:16:00Z")
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 ---
**Author:** ![Dieter\_W\_Storr](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/dieter_w_storr/32/91_2.png) [@Dieter\_W\_Storr](https://techcommunity.softwareag.com/u/Dieter_W_Storr)\ **Post date:** [July 31, 2008, 5:23am UTC](https://techcommunity.softwareag.com/t/adaord-lip-and-runtime/78652/2 "2008-07-31T05:23:23Z")
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 ---
**Author:** ![Dieter\_W\_Storr](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/dieter_w_storr/32/91_2.png) [@Dieter\_W\_Storr](https://techcommunity.softwareag.com/u/Dieter_W_Storr)\ **Post date:** [October 17, 2008, 10:53pm UTC](https://techcommunity.softwareag.com/t/adaord-lip-and-runtime/78652/3 "2008-10-17T22:53:29Z")
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 > **[Storr Consulting, Inc. - Index](http://www.storrconsulting.com)** > > Mainframe and PC Solutions, Software and Hardware, > Concepts, Design, Performance Analysis, Data Modelling, > Teaching English and Art ---
**Author:** ![system](https://global.discourse-cdn.com/techcommunity/original/3X/c/d/cd19967bb605d28a72d77eb83a1cae22f3df2eb8.svg) [@system](https://techcommunity.softwareag.com/u/system)\ **Post date:** [April 2, 2021, 2:50pm UTC](https://techcommunity.softwareag.com/t/adaord-lip-and-runtime/78652/4 "2021-04-02T14:50:41Z")