Pat, You're right - in principle. CS IP developers are also right - but unimaginative.
RFC 2355 asserts that there are two types of TN3270E server logic: One where the SSCP-LU session is available and USS commands and messages can be "passed through" and one where there is no access to the SSCP-LU session. The SSCP-LU session is available where the TN3270E server logic is supported on an SNA Type 2.1 or 2.0 node with SSCP-dependent PU and LUs. This is what you call the "outboard emulator". I wonder what was in the mind of the RFC writer when he specified the "other" type of TN3270E server logic which does not have access to the SSCP-LU session, probably a server as a VTAM application but he doesn't say so. But, but, but a VTAM application can access SSCP-LU functions for session termination through the TERMSESS macro. What it cannot do is define itself to VTAM as being able to send USS commands to the SSCP and receive USS messages. RFC 2355 does not envisage the TN3270E server logic supporting a USS table in the same way that VTAM does but the CS IP TN3270E server logic does this for LOGON support. Combining TERMSESS capability and USS table support, the same USS service can be offered to a TN3270E client as TN3270E server logic with USS passthrough capability does also for LOGOFF support. This would incidentally necessarily include support for USS messages - including the famous USS message 5. Protocols are all about appearances. The CS IP TELNET server is not a Type 2.0 or 2.1 node with USS passthrough support but it can behave to the client as if it was - and does so already for LOGON support. My proposal is that the CS IP TELNET server should behave as if it was also for LOGOFF support. Note the benefit of having potentially the same behaviour at the TN3270E client whether the server has USS passthrough support (where the USS table in VTAM is used) or the server is pretending to have USS passthrough support (where the USS table in CS IP TN3270E server logic is used). To my mind the point about not following the RFC is irrelevant since the CS IP TN3270E server logic would be claiming USS passthrough capability as defined in the RFC rather than the lack of USS capability. We can forget about these poor implementations of TN3270E which can't play USS and the TN3270E clients need never encounter such a poor server. The RFC is actually wrong is specifying the two types so rigidly. It ought to distinguish between TN3270E server implementations which can support USS no matter how and those which cannot. (Perhaps I can send in a "comment" on these lines.) The CS IP TN3270E server logic is currently behaving as the former for LOGON support but behaving as the latter for LOGOFF support. This is obviously not consistent although I appreciate the RFC only worries about this capability issue in connection with LOGOFF support. A minor point, having now read the RFC - again, is that the CS IP TN3270E server logic does not follow the RFC in its implementation of the "lack of USS capability" LOGOFF support since the sequence is that used by VTAM non-SNA 3270 support rather than that defined by the RFC. Finally I should mention 'ibmtest". Back in 1969 when I participated in the UK "On-line Diagnostics" project the need was felt for a means to run basic tests to exercise the "teleprocessing" devices. In those days that meant 1050s and 2740s and the like. Since a component of these devices was the typewriter printer, there was a need to invoke test printouts. The project was aimed at being able to enter the test mode without the knowledge of the BTAM application program driving the device, then running the tests and finally returning control to the "multiple wait" within the BTAM program. When VTAM/SNA came along there was still one direct descendant of those devices, namely the 3767. I have always taken account of the "ibmtest" USS function when teaching USS but I've never seen too much of a use for it with 3270 devices. Perhaps it was created only to be a test facility for the 3767 - and maybe the 3770 series of SNA devices which could claim to be a descendant of the dearly remembered 1050 system. Anyhow I'm not going to insist on "ibmtest" support with TN3270E server logic. Chris Mason ----- Original Message ----- From: "Patrick O'Keefe" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Wednesday, 18 January, 2006 9:55 PM Subject: Re: TN3270 Question > On Mon, 16 Jan 2006 16:16:40 +0100, Chris Mason <[EMAIL PROTECTED]> > wrote: > > >... > >Once you do find the SysRq key, you can enter "logoff" without the > quotation > >marks* and VTAM, performing its SSCP role, will terminate the session > >between the application and the TELNET logical unit (LU) managed by the > >TELNET 3270 server. Ideally you could have the possibility to determine > the > >degree of "prejudice" you apply to the session termination request by > >specifying whether the application is to be asked politely, TYPE(COND) - > >COND for conditional, rudely, TYPE(UNCOND) - UNCOND for unconditional, or > >the application is to be given no chance to refuse, TYPE(FORCE). > >... > > Chris, > > Your posting prompted me to dig into the Tn3270E RFCs (1647 & 2355) a bit. > I don't see any updates to SysReq in 2355. RFC 1647 states that the > behavior of the server to a SysReq depends on whether the server has > access to the SSCP-LU session. An outboard emulator that looks like a > 3270 controler has access to that session; the zCS Tn3270 server does not; > it is simply a VTAM appl with an open ACB. (If defined with AUTH=CNMI I > guess it would have access to some SSCP functions, but I don't think > that was included in the design.) For servers without access to the > SSCP-LU function a very limited SysReq support is implemented. You can > toggle out of the LU-LU session and back (generating the 082B sense you > mentioned) and you can request LOGOFF which will generate UNBIND > Normal). > > The other things you mention are definitely not there, but they are not > supposed to be there according to the RFC. Servers could add extensions > (like the device support you discovered) but moving too far from the RFC > raises incompatability problems. > > Pat O'Keefe ---------------------------------------------------------------------- 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
