> Does this imply that program objects can never be in LPA, not merely
> that such objects can't be accessed until late in the IPL processing?

No. At least "no" based on the meaning of LPA. But perhaps you meant PLPA.

> Does that imply that soon COBOL programs will not be eligible for LPA?
No. Similarly.

Program objects (in PDSEs) have been eligible for dynamic LPA since 
dynamic LPA was introduced.
They have not been, and will likely never be, eligible for PLPA, MLPA, or 
FLPA.

So it is the case that newer-version COBOL programs are not eligible for 
PLPA, MLPA, or FLPA. 

Prior to z/OS 1.11, the earliest you could reasonably get program objects 
into (dynamic) LPA was via a statement in COMMNDxx.

As of z/OS 1.11, you can use "deferred LPA Wait" to put LPA statements in 
the IPL-time PROGxx and have them processed at the tail end of IPL.
An application that needs to know if that deferred LPA processing has 
completed can use the CSVDLPAW program or the CSVDYLPA REQUEST=DEFLPAWAIT 
programming interface.

Jim Mulder pointed out to me that the PROGxx documentation is incorrect in 
having failed to delete a relevant statement.

What is there and correct (under "using the LPA statement")
Use the LPA statement to specify:
-- Modules that are to be added to the LPA at the end of the IPL. This is 
needed only for program objects within PDSEs but can be used for load 
modules within PDSs.
-- etc


What is there and incorrect (under "syntax format of the LPA statements") 
and will be removed:
Note: LPA ADD and LPA DELETE cannot be used during IPL. They are for use 
in PROGxx members pointed to by SET PROG=xx after IPL.

Peter Relson
z/OS Core Technology Design


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to