Pat There are a few misunderstandings to clear up here - and some more explanations. For complicated reasons[1] I operate from the archives rather than e-mails. In order to try to reduce ambiguities I'm going to have to be more adventurous over quoting the text upon which I am commenting.
- >>> Pat: IBM allows of substitution of some variables in MSG7 and MSG10. >> Chris: You can have variable substitution in ***all*** USS messages, not just USS message 10 and USS message 7. > Pat: I understand the value of the messages and substitutions in them, ... I hope now I have put the parts of the conversation together where that misunderstanding came from. - I started composing comments on the ACBNAME problem but they became so extensive that I have created a new post. - > Pat: VTAM has supported different ACB and LU names in APPL defs since the stone age. While thinking through how we got into thus ACBNAME mess, I decided that the operand was probably introduced with multiple domain SNA which puts the SNA "stone age" in about 1979! - >> Chris: 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 > Pat: The other kind of Tn3270 server - like z/CS's - has APPL LUs and VTAM does not do USS processing there. The server, rather than VTAM, is acting as the SSCP for the clients. The server sends the USS messages; the server processes the USS commands. When what I call the "convert" type of TN3270E server processes an USS command and there is no session in place, it happily *converts* the partner LU (application) name, the mode name and the data to values in fields set up for the REQSESS macro. In effect, it is converting an *Unformatted* System Services request to a *Formatted* System Services request since, after all, any APPL statement implicitly specifies SSCPFM=FSS (in the same way that a LOCAL statement sort-of implicitly specifies SSCPFM=USS3270 although, because of the "print bit" oddity, you can specify SSCPFM=USS3270 or USS3275). USS and FSS are two sides of the same coin; they are both about the requests which establish - and terminate - sessions. In the "pass-though" case, it is business as usual and the owning VTAM performs the conversion from USS to FSS in order to create the formatted request, some flavour of INIT. In the "convert" case, the TN3270E server performs the conversion from USS to VTAM macro specifications from which VTAM creates the formatted request. As far as the end-user is concerned and as far as the VTAM which processes the formatted request is concerned, the process is identical - just as it should be - for the LOGON case. What I'm after is for all of that to apply in exactly the same way for the LOGOFF case, substituting TERMSESS for REQSESS, some flavour of TERM for some flavour of INIT and the TYPE value in place of LU name, mode name and data - along with the same USS commands, specifically the LOGOFF versions obviously, and messages as usual being used. After all what is the TN3270E server doing with the inflexible LOGOFF command but issuing an inflexible TERMSESS? (See some more notes below.) In a phrase much loved by a very popular British columnist, presenter and, inevitably, best-selling author, "How hard can it be?" - Naturally the above applies to the rest of what you said. - Except for the point about commenting on the RFC. Perhaps I should take "Request for Comment" literally. [1] Except for IBMTCP-L which has to be run from e-mails - as far as I can tell - so I operate that list from GMAIL. I'm commuting sporadically between Brussels and Plymouth - from where the Mayflower *left*[2] obviously! - and, away from home, my usual ISP refuses to accept e-mails, hence the reliance on the archives. [2] Did you know the departure city was supposed to be Southampton but they had some trouble and had to put into Plymouth. Not a good omen! --- Before your response appeared, I'd been thinking a bit more about this issue and prepared the following. I guess an expression involving a dog and a bone comes to mind! Section 10.5 of RFCs 1647 and 2355 contain an incompatibility as far as the TN3270E client end user experience is concerned. Let us assume that an organisation is using an outboard TN3270E server and is operating USS functions according to the "pass-through" specifications. Perhaps they decided to recustomize the LOGOFF command as LOGOUT. Perhaps their IBM technical specialists persuaded them that it would be better to use the TN3270E server built into the Communications Server IP component. You can see where I'm going can't you? Now the poor put-upon TN3270 client end users will be obliged to use the LOGOFF command whenever they get into trouble. It gets worse. Let us assume that the TN3270E client end users or the help desk on their behalf have invested in working out the relative merits of customizing the nature of the SSCP-assisted LOGOFF in order to do the minimum damage to the application functions when this drastic measure needs to be adopted. From the days when the organisation was a pure SNA shop a hierarchy of potency has been used following the archetypical USS LOGOFF TYPE operand translated to whichever local language suited the monoglot TN3270E client end users: LOGOUT translates to LOGOFF TYPE(COND) LOGOUT Maintenant translates to LOGOFF TYPE(UNCOND) LOGOUT Immediatement translates to LOGOFF TYPE(FORCE) or something along those lines. All this subtlety is necessarily lost when the hidebound TN3270E server is used. I suspect - but so much disdain is there for the LOGOFF function that nowhere in the Communications Server IP Configuration Guide is it actually stated - that the default value, UNCOND, for the TYPE operand of the LOGOFF command is assumed and that that option is reflected over the VTAM API. Fortunately the HOLD operand has no relevance in the context of the TN3270E client server connection - although I guess it could if used to maintain the connection or cause disconnection. When LUSESSIONPEND is in effect, the connection is not automatically dropped and, if applicable, the USS 10 message is presented. It's interesting that, if LOGOFF is entered now when no LU-LU session is in progress, it is used to cause disconnection. I would prefer that a specific USS command, such as DISConnect - which would be open to translation of course - were implemented for that function in order to avoid any possibility of confusion. I suppose I had better defend my contention that the TYPE operand can be supported by the TN3270E server mapping the COND, UNCOND or FORCE text to the VTAM API in order to leave no wriggle room. Just as the REQSESS macro is used to implement whatever is specified with the LOGON command, the TERMSESS macro could be used to implement whatever is specified with the LOGOFF command. The mapping goes as follows: TYPE(COND) - TERMSESS OPTCD=COND The application can take its time over terminating the session. This may allow tidy management of associated resources. TYPE(UNCOND) - TERMSESS OPTCD=UNCOND The PLU VTAM terminates the session immediately if the SSCP receives the CDTERM request. TYPE(FORCE) - TERMSESS OPTCD=UNBIND The SLU VTAM terminates the session immediately. Sometimes this degree of granularity can be useful. --- Interestingly enough the possibility of the end-user experience being changed when switching from a "pass-through" to a "convert" type of TN3270E server means that there need be no inhibition on the TN3270E server developers ignoring Mr Kelly's ignorance and giving the necessarily "convert" type TN3270E server the appearance of a "pass-through" TN3270E server. Why should anyone care? In other words, any appeal that the TN3270E developers make to not being in conformance with the RFC can be thrown out of court on its ear! 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
