Johnny, By saying you have had some success, do you mean that you changed the source of USSN (in whichever library that is located), assembled and linkage edited this source into a USSN load module in ADCD.ZOSV14S.VTAMLIB replacing the existing USSN load module?
Note that the source library has significance only for the assembler step and is of no interest whatsoever to the VTAM procedure. Now we have three more problems: 1. How to modify a JCL procedure The fact that a library (partitioned data set) in a procedure resides on a different volume is of no interest to a procedure just so long as the library is either cataloged or the DD-statement includes a reference to the volume. In the days when I played with MVS (what z/OS used to be called) JCL, your strategy of varying the volume with your JOHNNY.VTAMLIB offline would not have worked, the procedure would have failed and maybe would have created that IEF861I message. I assume removing the modification to JCL applies to the VTAM procedure. 2. How to run an assembler/linkage edit job. We can't really help a great deal here. It's all about how you run your system which I am having to guess from your reference to "lap" is an experimental system just for you on a laptop. Fortunately you talk about setting up those data sets on a separate volume and you even talk about varying the volume online and offline so perhaps your volume is somehow not online when you run the assembler/linkage edit job - just a guess. 3. How to use USS tables with CS IP TELNET 3270 as opposed to VTAM local non-SNA 3270 display devices I have to make a big assumption here in that port 3270 means that some sort of supporting software in the clever system on your assumed laptop provides the appearance of a channel-attached 3270 display device emulating - let's get back to basics - a 3272 control unit and a 3277-2 (although I'd be surprised if it didn't support the more advanced 3270 data stream capabilities of a 3174-1D and the many display devices that could attach to a 3174-1D - which is where we came in on this thread after all). If that big assumption is correct, it means that with port 3270 we are dealing purely with VTAM in terms of z/OS software, or more precisely these days, purely the SNA side of CS. If you are using port 23, you will, by default, be using TELNET. Here, if TELNET 3270 is negotiated, the USS table operates rather differently. The first point being that you need to place the USS load module in a library which can be accessed by the procedure supporting the TELNET 3270 server logic however you have that set up in your system. In principle the USS module can be the same load module. If you look at those notes I sent you, you'll see that the USS table load module name - USSN in the example you have been using - must be provided on a statement in a member of VTAMLST, probably a LOCAL statement. This is where VTAM finds the name of a USS table module. In the case of CS IP TELNET 3270, the name of the USS table is provided in the statements relating to TELNET - which used to have to be in the PROFILE data set but which can now be in a data set accessed by a separate TELNET procedure I believe. When CS IP TELNET sets up a session with CS SNA (VTAM) VTAM knows nothing about any USS tables (in definition terms, SSCPFM=FSS is assumed for the TELNET 3270 secondary APPL statement). The TELNET 3270 server in CS IP simulates the USS table processing purely over the TELNET 3270 TCP connection - and then only partially but that's another sorry story. After all this I still wonder where the 3270 emulation is coming from in the case of both the use of port 3270 and port 23. I'm afraid that, when asking for help, you shouldn't assume complete familiarity with what sounds like a wonderful playpen for getting familiar with z/OS. I further suspect that you have been sold falsely on the idea that you do not need to understand all the tricky bits and pieces that have been clobbered together under - I guess - the ADCD system label. Perhaps you can supply an URL where I can read about the essentials of this ADCD system and can perhaps disentangle the confusion they have led you into. I now have read Terry's contribution. It would appear that, in order to try to avoid you actually having to understand what you are doing - always a futile objective in my experience - this USER set of libraries has been set up in such a way that the USER.VTAMLIB is available to both the VTAM procedure and the procedure supporting the TELNET 3270 logic so that you can be unaware - in principle - that you modify simultaneously both the USS module as processed by VTAM and the USS module as processed by the TELNET 3270 server. Chris Mason ----- Original Message ----- From: "Johnny Luo" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Sunday, 08 January, 2006 10:38 AM Subject: Re: Manuals on modifying VTAM logon screen? Chris,I tried to do some modification carefully and it now works. It's a good beginning though I only changed the display contents of logon screen,no color,no hilight,no other functions. There are two questions here. 1,I checked VTAM procedure in JES2 proclib ADCD.ZOSV14S.PROCLIB(You know, the sytem which I use for test is in fact an ADCD ZOS on lap) and found its VTAMLIB concatenation like this: user.vtamlib adcd.zosv14s.vtamlib sys1.vtamlib The user.vtamlib is empty and USSN module is in ADCD.ZOSV14S.VTAMLIB. My plan is to place my own module in JOHNNY.VTAMLIB which resides on a different volume and then add my own lib to the top of VTAMLIB concatenation. So if VTAM failed during IPL,I can vary the volume which JOHNNY.VTAMLIB resides on offline and then restart VTAM. Then I placed USSTAB source I modified in JOHNNY.VTAM.SOURCE and the destination load module in JOHNNY.VTAMLIB.I modified the JCL and submitted it to compile and link. But the job failed. The system says it's waiting for data sets.I checked the log and got the message: *IEF861I* *FOLLOWING* *RESERVED* *DATA* *SET* *NAMES* UNAVAILABLE TO IBMUSERA DSN=JOHNNY.VTAM.SOURCE DSN=JOHNNY.VTAMLIB It's strange.No other users or jobs are using these two data sets,why they're unvailable to my job? 2,So I canceled my modification to JCL and resubmitted it.This time there is no problem.However,after re-IPL,the new logon sreen only works when you connect to it using port 3270.On the other side,if you use TCPIP port 23, the logon screen is still the old one.Why does this happen? -- Best Regards, Johnny Luo ---------------------------------------------------------------------- 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
