Tom, and Jerry, (and I'm not going to make any jokes....) Are you sure about the concatenation sequence? (I almost said "issue" but decided not to) According to the z/OS 1.4 documentation, and this what I remember from eons ago, that the first occurrence of a module is the one loaded into the PLPA, not the subsequent ones. Here is the line from the Init and Tuning reference:
"If a module exists in more than one library in the concatenation, the first occurrence of the module is placed in the PLPA. Later occurrences are ignored." Jerry, A couple things to check, which you probably already have.... Does the missing module in fact exist in the CICS 3.1 library? Do you have a fixed LPA (check member IEAFIXxx) that may have the older module(s) in it? Is the CICS 3.1 library a PDS or a PDSE? PDSEs (at least as of 1.4) are not eligible for LPA residency. Are the older modules in the MLPA? This would be member IEALPAxx. Both the FLPA and MLPA override the PLPA. Rex -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Schmidt Sent: Thursday, November 09, 2006 3:59 AM To: [email protected] Subject: Re: IPL with CLPA Jerry, I believe that I see what the root problem is: You have two libraries with several identically named members in them, that you have loaded into your PLPA. I also believe that MVS has, in fact, loaded both copies of each module (one from CICS/TS 3.1 and another from CICS/TS 2.2) into the PLPA. I also believe that the CLPA was performed successfully (FSVO success). However, and this is a significant departure from typical contents search (i.e., STEPLIB) processing: when the PLPA directory is built, it is built top-down - which is analogous to STEPLIB search - BUT each identically- named module's address is overlaid by the subsequent module's location. To demonstrate, lets say that we have two modules named "A" - one in CICSTS31 and a second (with different contents) in CICSTS22. Lets also say that the CICSTS31 library appears first in the LPALST member, followed by the CICSTS22 library. The processing performed by CLPA (LPA build, I think) loads the contents from CICSTS31 (first) and builds directory entries for each. It then loads the contents from CICSTS22 and either builds or updates any and all directory entries for each. That means that a module named "A" is loaded into the link pack area (PLPA in this case) not just once, but twice... but the directory entry will only point to the LAST module's memory; the first (CICSTS31) will not have a directory entry since it was overlaid by the second. Those of you who don't believe and would like to experiment (I have, but a long time ago) can add an alias to, say, module A and see if you find it. Better yet, don't add an alias and use a tool (or build your own) to scan the PLPA virtual storage for the first copy of the module. It will be there, but without a directory point it will be difficult to find using defined interfaces. Jerry, if you need access to both the CICS/TS 3.1 and CICS/TS 2.2 SDFHLPA contents you will need to put one (or both) into your corresponding CICS region's (or regions') STEPLIB concatenation in order to maintain the one- to-one relationship. (The SDFHLPA library does not have to be in the LPA after all, but it does need to be in the APF if it is not in your LPA.) That, I believe, is the root issue. (Sorry for the "missing comma" red- herring.) -- Tom Schmidt Madison, WI ---------------------------------------------------------------------- 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
