On Wed, 8 Nov 2006 11:18:26 -0600, Jerry Ragland wrote: >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, 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
