"Disturbed" > Disturbing.
I am obliged to guess at what part of my post you found "disturbing". I concluded it must be the point I raised regarding support for the LOGOFF command, no other point being available as a candidate. It is indeed a shame that Bill Kelly - to give a name to the author of RFC 2355 - didn't appreciate that there was a capability, enormously useful in support of a troubled - one might even say disturbed - end user when work is not progressing as hoped. That missed capability can be described in the following manner: 1. The end-user has established the TN3270E TCP connection concatenated to the SNA session with, for example, TSO with the aid of the LOGON command. 2. The end-user has become "stuck" in some way, no response from the application or the application is not behaving as he or she expected. Ideally, the following would be possible, with the end-used needing to have been trained only how to manage 3 and 4. 3. The end-user would invoke the SysReq function, single key or combination of keys with a tricky "order of press". 4. The end-user would press enter.[1] 5. There would now be instructions over how to proceed which would include the number of the "help desk", and a number of parameters specific to that end-users connection/session which the "help desk" would need properly to identify the end-user: - the client IP address - the client name obtained from the name server system [2] - the SNA-oriented TELNET server LU name Incidentally, also with what RFC 2355 allows in the implementation of the LOGON command, the variables are available for presentation at this time and, in case anyone is of the opinion that this is all some relic of a bygone age, there is - sound the trumpets! - support for IPv6 in the "client IP address" field. It appears that Bill Kelly - not having attended my classes! - was unaware of the possibility behind steps 3, 4 and 5 which has always existed for the case of the SNA end-to-end session - obviously just with regard to the "LU name" field - since the @@LUNAME variable was introduced. This is the great - and "disturbing" - shame! - [1] The message which appears here is number 5, "Unsupported function". All this means is that, according to design, VTAM or, in this case, the SNA-oriented TELNET server, do not take any action relating to session management as a result of receiving no data - but, but, but - there is nothing whatsoever to prevent the canny system programmer using any or all of the available variables to populate the resulting message 5! [2] It is not actually made clear in the section 16.4.3, "USSMSG macroinstruction" of the z/OS Communications Server IP Configuration Reference where these fields are described that this field must be optional: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b4b0/16.4.3 The SNA-oriented TELNET server will only obtain the client host name from the name server system when (it thinks!) it needs so to do in order to map, for example, LU names to particular client work-stations by "host name". As for the case of providing the name field in the CV X'64' information propagated to the application, this reference to the name server system can be induced by setting up, in effect, a dummy HNGROUP set of statements in the PROFILE data set. - Chris Mason On Sat, 7 Jan 2012 15:53:11 -0500, Ford Prefect <ford...@gmail.com> wrote: >Disturbing. > >On Fri, Jan 6, 2012 at 9:56 AM, Chris Mason <chrisma...@belgacom.net> wrote: > >> ... >> >> Incidentally, while scanning for the changes, I noticed some mendacity! >> It's actually not really the fault of the Communications Server developers >> that the SNA-oriented TELNET server can mimic the action of VTAM only for >> the *LOGON* command. Rather it is a deficiency of RFC 2355. In order >> completely to support the following claim: >> >> <quote> >> >> For ease of migration, Telnet simulates SNA USS processing very closely. >> >> </quote> >> >> full implementation of the handling of the *LOGOFF* command would be >> required. Unfortunately, while having done a good job for the most part the >> author of RFC 2355 fell down very badly in the area of the USS LOGOFF >> command - more's the pity for end users and their help desk support. >> >> - >> >> Chris Mason ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
