Jerry You'll get the latest information regarding setting up the IPL process these days from other contributors. It's a few years now since I dabbled with IPLing MVS.
However there's one form of words that you use which worries me and indicates you may have a false concept of what CLPA does. The words are "CLPA enabled" and you use them in this post and you original post. "CLPA" is defined in summary in "z/OS V1R8.0 MVS Initialization and Tuning Reference" as follows: <quote> CLPA - Causes NIP to load the link pack area with the modules contained in the LPALST concatenation. Also, CLPA purges VIO data set pages that were used in the previously initialized system. Thus, CLPA implies CVIO. </quote> NIP = nucleus initialisation program (or process) "CLPA" is defined in detail in "z/OS V1R8.0 MVS Initialization and Tuning Reference" as follows: <quote> CLPA (See also the MLPA parameter for temporary additions to the LPA, and the CVIO parameter for the deletion of VIO data sets.) This parameter causes NIP to load the LPA with all modules contained in the LPALST concatenation. Modules listed in the specified LPA pack list member (IEAPAKxx) are packed together, preferably in one-page groups. (See description of IEAPAKxx.) Modules not in the pack list are loaded in size order, large modules first, then smaller modules to fill unused space. PLPA pages are written to auxiliary storage. Only one set of PLPA pages can exist in paging space. Modules in the LPALST concatenation must be reenterable and refreshable because the system uses the processor's page protection facility, which enforces read-only access to each PLPA page. CLPA should be specified after the installation has modified a data set in the LPALST concatenation and wants to reload the PLPA with new or changed modules. Note: CLPA also implies CVIO, so that VIO data set pages on local page data sets are automatically purged. (See the description of CVIO for further information.) The CLPA parameter is not needed at the first IPL. NIP detects the cold start condition internally, noting that the PLPA has not been loaded. If CLPA is not specified, NIP tries to find a usable PLPA in the existing page data sets. If NIP is successful, a quick start or a warm start occurs, and the auxiliary storage manager (ASM) obtains the records that specify where the PLPA pages reside on auxiliary storage. It then reestablishes the previous set of PLPA pages. The old PLPA may be reused for any number of system initializations, if CLPA is not specified. However, page data sets that contain the last used set of PLPA pages must be mounted. If they are not, the operator is asked to mount them. If the operator bypasses mounting, ASM initialization requests a different page data set and forces a "cold" start. NIP then reestablishes the PLPA as it does when CLPA is specified. In this cold start, both the previously established PLPA and existing VIO data set pages are logically deleted from paging space. The fixed LPA and the modified LPA, however, are not automatically reused in a quick start or a warm start. They must be respecified. Existing VIO data set pages on local page data sets are retained in a warm start, unless the CVIO or CLPA parameter is forced. Such pages are not retained in a quick start or a cold start. (See the description of the CVIO parameter.) If CLPA is specified and a set of PLPA pages already exists on a paging data set, NIP frees the existing PLPA and updates the appropriate records to reflect the new PLPA pages on auxiliary storage. NIP loads the LPA from the LPALST concatenation, as previously described. IBM suggests that you have an IEASYSxx member that does not specify CLPA. This permits you to load the initial program without rebuilding the PLPA if it is not possible to access your LPA data sets. </quote> I have always thought that "CLPA" stands for "create link pack area" but I could be wrong, either way, that's effectively what it does. You'll note the recommendation *not* to have CLPA permanently specified in your IEASYSxx member. After a change to the "LPALST concatenation", CLPA need be specified for one IPL and one IPL only. There is no concept of a system (or environment) having been "CLPA enabled". The only operation that is "CLPA enabled" is the IPL process. Once the IPL is complete there is no difference between a system where CLPA was specified in IEASYSxx and one where it was not. At least that's the way it was when I last played with these things and I see no change in the text I just pasted from the manuals. Chris Mason ----- Original Message ----- From: "Jerry Ragland" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <IBM-MAIN@BAMA.UA.EDU> Sent: Wednesday, 08 November, 2006 6:18 PM Subject: Re: IPL with CLPA Thanks for the reply Rex. Yes, IEASYSAW is the member used during the IPL. From the logs - "*IEA247I USING IEASYSAW FOR z/OS 01.04.00 HBB7707" IEASYSAW contents - CLOCK=00, SELECT CLOCK00 CLPA, CMB=(UNITR,COMM,GRAPH,CHRDR), ADDITIONAL CMB ENTRIES . . . LPA=DB, SELECT LPALST00 MAXUSER=250, SYS TASKS PLUS INITS PLUS TSOUSERS MLPA=DI, DI FOR IMS in IEASYSAW LPA is given as DB. In the LPALSTDB file the **.SDFHLPA is added correctly. LPALSTDB file - . . SYS1.SICELPA, SYS1.CICSTS31.CICS.SDFHLPA(DSK32E), CICSTS22.CICS.SDFHLPA(S4CIC1), . . from the replies I understand that specifying CLPA parameter in IEASYSAW will automatically enable CLPA during IPL and all the **.SDFHLPA members will be added to the LPA area. In that case my environment is CLPA enabled. Is there a way to check the contents of LPA area? Is there any other reason for the modules not included in the LPA area? -Jerry. ---------------------------------------------------------------------- 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