Dynamic LPA processing will typically do no better and no worse than any other fetch that was targeted to the LNKLST. It is quite possible that the problem is due to what the posts have indicated, namely (typically) something now in in an extent that is not part of the LNKLST that your space has defined.
However, for releases prior to z/OS 1.9, there is a bug that is being fixed (at z/OS 1.7 and z/OS 1.8) when you have multiple LNKLST sets involved and the operation is not occurring within a space for which the IPL-time LNKLST is that space's LNKLST. (The supported case of this is when a new LNKLST set was activated, and then a newly started job or address space uses the CSVDYLPA programming interface. I say it that way because it could also happen if you used the unpredicatably dangerous LNKLST UPDATE operation to update the LNKLST for ASID=1 and then issued the SETPROG LPA command or its analog via SET PROG=xx). . APAR OA24903 has been taken for this problem, and a ++APAR is available. The basic explanation of the processing problem is that the system ends up doing things partly with one DCB/DEB (the one for the LNKLST current for the issuing address space) and partly with another DCB/DEB (the one for the IPL-time LNKLST). As has been stated, you can use the DSNAME or DDNAME parameters of CSVDYLPA and avoid this problem even know. Alternately (and this really is the intended thing to do, not refreshing LLA), have someone create a new LNKLST set just like the old one and activate it and then start your application. For example, SETPROG LNKLST DEFINE NAME(COPY) COPYFROM(CURRENT) SETPROG LNKLST ACTIVATE NAME(COPY) Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
