Tom, I saw that one too. My guess is that the warning about having multiple datasets is that NIP processing has to read the directory trees of every PDS it encounters and go through the work of discarding the duplicates. Back when I started working on MVS on a 4.3 MIP 4381, this processing could have had a significant impact on IPL times. Just a hunch.
Rex -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Schmidt Sent: Thursday, November 09, 2006 10:55 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IPL with CLPA On Thu, 9 Nov 2006 10:16:19 -0600, Pommier, Rex R. wrote: >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." Rex, But under the "Syntax rules for LPALSTxx" section in Init and Tuning Reference it also says: "Be careful not to specify the same data set name more than once in the LPALSTxx members. This applies to data sets with and without a VOLSER specified. The same data set name is concatenated as many times as it appears in all specified LPALSTxx members. Specifying the data set name more than once can cause additional processing during IPL, when the CLPA processes." I find it odd that the section I quoted is immediately ahead of the section that you quoted. I suspect that, perhaps, the "ignored" processing is either something added later (and the documentation was not properly updated to reflect the change) or else they have a funny (odd) way of 'actively ignoring' extra datasets which causes additional processing. I would, however, take the book's meaning to be that the module directory is NOT updated (at least as of, say, MVS 4.3 era; it may have been a usermod we had taht provided that function... maybe even one that I wrote (?) in order to override the default SYS1.LPALIB insertion that MVS used to provide - whether you wanted it to or not). >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. Jerry (and Rex), All good advice. I would recommend running an AMBLIST LISTLPA and 2 AMBLIST LISTLOADs with SYSLIB pointing to (one each) the two SDFHLPA libraries on disk. That way you could establish the module sizes, both in storage and on disk in order to diagnose this, ahem, issue. -- 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
