Pat You can have variable substitution in ***all*** USS messages, not just USS message 10 and USS message 7. It's the substitution of variables in USS message 5 which is at the heart of my help desk scenario which, since there's so much misunderstanding here I'd better cover in more detail:
1. An end user gets into trouble - it happens from time to time I believe - and calls the help desk. 2. The Help desk says "Well, I need to know something about your workstation." Please do the following: a. Invoke the SYSREQ function (all end users have been instructed how to do this) b. Press Enter[1] c. Tell me what you see in white[2] d. Invoke the SYSREQ function again e. The rest depends on what the end user reports and may conclude with the following: p. Invoke the SYSREQ function yet again q. Enter LOGOFF r. Whether and how the application is accessed again is at the discretion of the help desk [1] This will return USS message 5 - if USS support operates as it is supposed to, that is, VTAM does and the TN3270 server (supported by the deficient RFC) doesn't. If the end-user is clumsy - I guess some might be - and enters some characters one of the following will happen - again assuming proper USS support: a) a valid LOGON command - USS message 6 b) a valid LOGOFF command - USS message 10 (TN3270E parameters may intervene) c) other - USS message 1 or 2 Except for b - which should be avoided by being clumsy-proofed - any of these messages can have the key "white"[see 2] information inserted. [2] I am supposing that the IP address and the LU name - and possibly other useful variables - have been set up to show in white (protected/intense) as has been encouraged by one of the responders in this thread! You are correct that USS message 7 is a bit special in that only the RUNAME and SENSE variables are valid in USS message 7. What's the problem with the "ACB name"? The RFC doesn't read to me as allowing "Servers are free to support more than LOGOFF if they want." and that is the interpretation of the Communications Server IP component. - You have obliged me to revisit section 10.5 The SYSREQ Function of RFC 1647 (and 2355 - no significant changes found) and here are my comments indicating precisely where Mr Kelly has got it wrong: - There is a quite correct comment that only SCS (not 3270 data stream) is allowed on the SSCP-LU session. It's interesting to note that VTAM relaxes this limitation for the case of non-SNA 3270 - necessarily[3] - and the limitation is relaxed in the case of the TN3270E server - even when the LU-LU session uses the SNA version of the mode table entry. - The 3270 session states are a bit more complicated than as described. The states should be covered as follows: - No sessions -- nothing - Only SSCP-LU -- SYSREQ toggles between unowned (question mark) and SSCP-LU (stick man) - Both SSCP-LU and PLU-SLU -- SYSREQ toggles between PLU-SLU (square blob) and SSCP-LU (stick man) - The RFC defines two types of TN3270E server: - a "pass-through" type which can support the passing of SSCP-LU requests - a "convert" type which must convert unformatted flow to formatted flow Note that my description of the second type allows a proper implementation of the intent of USS flows while the RFC just gives up!!! This is where it all goes wrong with the RFC: the point where the RFC says "this makes full support of the SYSREQ key impossible." - rubbish!!![4] Note that TN3270E cannot be a "pass-through" type - you cannot specify SSCPFM=USSSCS on an APPL statement - but it is perfectly capable of being a "convert" type. Unfortunately Mr Kelley seems to be unaware of the subtleties of VTAM programming when implementing a secondary LU. I'd need to check again but I believe last time I examined this hole in the RFC I checked that each of the USS LOGOFF options had its equivalent in the VTAM API. (It goes without saying that each of the USS LOGON options has its equivalent in the VTAM API.) What I'm after is support for USS when an LU-LU session exists in the same way as when an LU-LU session does not exist - for the "convert" type of TN3270E server. There is no technical reason why this cannot be done. All the necessary mechanisms are described in the RFC. It just needs an understanding that the VTAM API to which the "convert" type of TN3270E server has access on behalf of the TN3270E client can do everything that is defined in the usual VTAM-supplied USS messages. No unnecessary short cuts please! [3] Non-SNA 3270 as emulated by VTAM also has the SSCP-assisted LOGOFF limitation. Relying on my presentation material - since I haven't done it in ages - and also, mea culpa, there are no additional notes, a "stuck" non-SNA 3270 end user needs to do the following: - Press RESET - assuming this is necessary in order to unlock the keyboard - Key logoff - Press TEST REQ Well, I had to be sure and indeed this handy function is described where it logically belongs even if not where it might be expected given that it is an end user function of 3270 devices. It is covered in the "Test Request" section of Chapter 11, "Programming for the IBM 3270 Information Display System" in the Communications Server SNA Programming manual - where everyone can so easily find it! [4] The RFC doesn't actually say but I assume the "pass-through" type describes those "outboard" TN3270E server implementations where the 3270 secondary LUs are represented within VTAM as LU statements with SSCPFM=USSSCS specified. The RFC's other type, the one I define as the "convert" type, as far as I can see - maybe I'm being blinkered in some way, can only be the Communications Server TN3270E server (or equivalent product which can coexist with VTAM). Chris Mason ---------------------------------------------------------------------- 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
