Judy MODIFY (F) LLA,REFRESH command is needed only when the USS table load module is stored in a partitioned data set in the "link list" concatenation. Such partitioned data sets are listed in the LNKLSTxx member of SYS1.PARMLIB. 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.
You reported before that you are storing the USS table load module for use with the TN3270 server into one of the partitioned data sets in the VTAMLIB concatenation. Note that partitioned data sets in the VTAMLIB concatenation is of no use to the main IP address space, typically using the name TCPIP, which is where your TN3270 server is running[1]. You must either a) change the linkage edit step[2] so that the USS object module is stored in a partitioned data set which appears in the STEPLIB concatenation of the main IP started task procedure or b) ensure that the partitioned data set in which the USS table load module is stored is one of the partitioned data sets which comprise the STEPLIB concatenation of the main IP started task procedure The VTAMLIB concatenation of the VTAM started task procedure, typically called NET, may well consist of a local partitioned data set into which locally created load modules are stored concatenated before the supplied SYS1.VTAMLIB partitioned data set. It may make sense to add this local VTAMLIB partitioned data set into the STEPLIB concatenation of the main IP started task procedure. Thus this partitioned data set may be regarded as a partitioned data set into which any local load modules associated with the Communications Server product are stored, whether associated with the IP or the SNA component (VTAM). If you do this you can retain the assembly and linkage edit job for the creation of VTAM load modules unchanged. If a partitioned data set such as I have described is not defined, now is maybe a good time to define such a data set and your USS table load module can be stored into it. Note that it is generally regarded as bad practice to store local modules into a partitioned data set created for storing load modules from IBM - or any vendor - products. In order to be sure that, when you use the VARY TCPIP,,OBEYFILE command, the new USS table load module is found, it may be a good idea to use a name different from that used for any earlier, presumably supplied, USS table load module. If the USS table load module cannot be found during processing of the VARY TCPIP,,OBEYFILE command, I would expect there to be an error message of some sort to show there had been a problem. If you believe you have followed my advice for all of this and still you perceive a problem, you had better show the following in your next post: a) your assembly and linkage edit job for USS table generation b) the started task procedure for the main IP address space, typically using the name TCPIP c) the USSTAB statement from the PROFILE file You can obscure any names you don't want the world to see by replacing them with lower case xxx or something obvious like that. On the other hand, if it all now works beautifully, please let us all know and even perhaps add an explanation of why it didn't work for you before. [1] If you are using a separate address space for your TN3270 server, whatever I say about the main IP address space will refer to the TN3270 address space. [2] You said "assembly job" but I expect that there is a linkage edit (or as it is called these days, "loader") step which converts the USS table object module output from the assembly step into an USS table load module. Chris Mason ----- Original Message ----- From: "Judy Ellis" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Wednesday, 03 January, 2007 10:31 PM Subject: Re: how to introduce change to USSTAB > Prior to your response, I reran my assembly job, refreshed LLA, and issued > the OBEYFILE pointing to my TCPPRFxx member, which contains USSTCP USSTABAM > and refreshed LLA. The command was successfully completed but I am still > unable to issue the CMD to access the monitors. ---------------------------------------------------------------------- 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
