Clarification on LPALSTXX.

[Viswanathchandru]

Dear all,
Upto my understanding here with the manuals, Adding routines/load modules will enhance the system performance as they are obtained in the central memory instead of DASD's. Here in my shop i have a routine that has to be added to the LPALSTXX which may/maynot improve my performance. How do i check the improvement in performance? say before and after. Do i have any utilities/routines/or the records from the SMF would help me in measuring the performance? Hope i'm clear. Please let me know in case if i need to give more input. Apologies if i'm wrong.

Thanks,
Viswa

[steve-myers]

You put a load module in LPA for two reasons.

• It is actually used by two (or more) jobs most of the time. By inserting the module in LPA you are using just one copy of the module in storage.
• The module is used repeatedly. In other words the module is loaded thousands of times a day. Program fetch is fairly efficent, but not doing it is more efficent.

I've been doing this for 40+ years and I don't know any practical way of directly measuring the performance improvement by placing a module in LPA. Unless you know, for a fact, that at least one of the two reasons to put a module into LPA exists, it is not worth the effort.

Few user programs actually meet either reason and are really reenterable. I would test this very carefully before placing the module in LPA. I had a program fail for this reason: it was slightly embarassing.

[BillyBoyo]

Can you describe how the routine/load module is used?

I don't think it is very likely that putting it in the LPA is going to give you a noticeable payback in performance terms. You'd have to have thousands of jobs using the routine each day to begin to notice much saving with it being in the LPA vs simply load it from DASD. I don't even know that thousands would be enough, but if you don't have even that, then I don't think performance would be a reason to put it in the LPA.

[Viswanathchandru]

Thanks steve and billy for addressing the post and for your valuable time!.

I thought we can visualize the performance change as we do it in CICS VSAM tunning( by analyzing the SMF 110) . Thanks a lot for addressing the post!! thanks again!

then I don't think performance would be a reason to put it in the LPA.

Yes agreed! this is not only on the performance basis. But also to eliminate the maximum no of I/O operations that happens.

Thanks,
Viswa

[BillyBoyo]

Can you outline how the routine is being/to be used?

[Robert Sample]

But also to eliminate the maximum no of I/O operations that happens.

What system statistics or measurements do you have that indicate there is a problem now? How often is the module used? How is the module used? Has your site management agreed to your idea of adding this module to the LPA? It seems to me that you're focused on the positives of doing this without adequately considering the negatives.

[enrico-sorichetti]

putting thins in lpa is usually for storage related issues ,
one copy serves many

for load and directory related issues VLF and DLF should be more than enough

[Viswanathchandru]

Thanks all for your valuable comments and time!

Billy wrote:Can you outline how the routine is being/to be used?

To be very honest the routine is not written by me! Its from the Application team and it seems to be an exit routine for their batch jobs.

Robert wrote: What system statistics or measurements do you have that indicate there is a problem now?

Apologize this was my question previously. And i got a reply from the experts saying this cant be visualized.

Robert wrote: Has your site management agreed

Good interpretation. They didn't agree for this process now.

Enrico wrote: or load and directory related issues VLF and DLF should be more than enough

Yes agreed!!

Thanks all for your time and support!!

Thanks
Viswa