Ted Thanks for the correction. I took Mark Zelden's reference to LNKLST and added "xx" without thinking about the alternative.[1] Having now tried to be sure by checking the manuals I see that LNKLST is often used as an abbreviation for "linklist" and that, as you point out, PROGxx is the recommended way to define the "linklist". It even reminds me that I converted all my education/test virtual MVSs from LNKLSTxx to PROGxx, very probably the MVS release PROGxx appeared, because I liked to keep up to date.
The reason for the delay in responding - not that a response was obligatory - is that I decided I had to do some research in order to see whence Dr No was getting his response to your post - and, in essence, I failed.[2] I have discovered that it is possible to define which "libraries" make up the set managed by the LLA facility using the CSVLLSxx member of SYS1.PARMLIB. Thus it is possible that, for example, a partitioned data set containing the USS module which is *not* in the "linklist" could be identified in the CSVLLAxx member and so, in order to ensure that the new USS module was "seen", it would be necessary to enter the MODIFY LLA,REFRESH command. It is also possible that, by use of the CSVLLAxx member, partitioned data sets in the "linklist" can be removed from being managed by the LLA facility and so, in order to ensure that the new USS module was "seen", assuming that the USS module was stored in such a partitioned data set, it would *not* be necessary to enter the MODIFY LLA,REFRESH command. However having a partitioned data set in the "linklist" not managed by the LLA facility appears to be something that would happen only as part of some maintenance sequence and would not apply generally. So, I would like to suggest that the "flat" in "it's flat wrong" is, itself "flat wrong". I would have preferred a comment along the lines of "Not necessarily, even substituting PROGxx for LNKLSTxx. Please see what you can do with CSVLLAxx."[3] I would even not insist absolutely on the "Please". It would appear Dr No has gone off the rails - I'm not sure I've been participating in this list long enough to add the adverb "finally". There's also the unusual employment in list exchanges of this type of the third person singular. This looks like a case of "If I can catch him once upon the hip, I will feed fat the ancient grudge I bear him." But I mustn't be entirely negative over Dr No's contribution. Despite the typical exhaustion such interventions can cause, my research unearthed the LLACOPY call. If such a call were used during VARY OBEYFILE processing whenever modules such as the USS modules are referenced, maybe there would be no need to remind the creator of a new USS module to concern him/herself with MODIFY LLA,REFRESH. I have run this suggestion up the IBMTCP-L list flagpole ... "LLACOPY and VARY OBEYFILE", 17 Jan. Incidentally, Mark was very right to insist that the "linklist" should be considered. Under "USS table customization:" in section 2.2.1.10.2, "Using the Telnet USS and INTERPRET support", in z/OS Communications Server IP Configuration Guide, we find the sentence "The tables must reside in a data set that is in the system's linklist or is in the STEPLIB statement of the TCP/IP startup procedure." Thus, if the original poster, Judy Ellis, was going by the manual, she may well have been using a partitioned data set in the "linklist". Chris Mason [1] FWIW, there's a similar "error" in the documentation. In section 1.6.1, "LLA and Module Search Order" under 1.6, "Improving Module Fetch Performance With LLA" in z/OS V1R8.0 MVS Initialization and Tuning Guide, we find "6. SYS1.LINKLIB and libraries concatenated to it through the LNKLSTxx member of parmlib." as the last item listed after "When a program requests a module, the system searches for the requested module in various system areas and libraries, in the following order:". I may be guilty but I'm in good company. <g> [2] The research took in the following: z/OS V1R8.0 MVS Initialization and Tuning Guide 1.4.5.1 The Search Order the System uses for Programs 1.6 Improving Module Fetch Performance With LLA z/OS V1R8.0 MVS Initialization and Tuning Reference 21.0 Chapter 21. CSVLLAxx (library lookaside (LLA) list) 59.0 Chapter 59. LNKLSTxx (LNKLST concatenation) 67.0 Chapter 67. PROGxx (Authorized program list, exits, LNKLST sets and LPA) Did I miss something? [3] Using a CSVLLAxx member even includes the possibility to use MODIFY LLA, UPDATE=xx so that, with a customised CSVLLAxx member, it would be possible to limit the "refresh" to an individual module, the "screwdriver" approach. Perhaps that's what I was supposed to have suggested in place of MODIFY LLA,REFRESH, the "sledgehammer" approach. Chris Mason ----- Original Message ----- From: "Ted MacNEIL" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Thursday, 04 January, 2007 8:21 AM Subject: Re: how to introduce change to USSTAB > >If you are storing your USS table load module in a partitioned data set which is *not* listed in the LNKLSTxx member of SYS1.PARMLIB, you do *not* need to use the MODIFY (F) LLA,REFRESH command. > > Not entirely correct. > We have a Link List, but we do not use LNKLSTxx. > We use PROGxx, only, for Link & APF. > > When in doubt. > PANIC!! ---------------------------------------------------------------------- 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
