Re: USSTAB color question
- From: chrismason@xxxxxxxxxxxx (Chris Mason)
- Date: 24 May 2008 06:49:09 -0700
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.
just USS message 10 and USS message 7.Chris: You can have variable substitution in ***all*** USS messages, not
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 thestone 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!
-
requestsChris: The RFC defines two types of TN3270E server:
- a "pass-through" type which can support the passing of SSCP-LU
- 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 VTAMdoes 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 listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.
- Prev by Date: Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
- Next by Date: PAGEDEL - Was "Large Page Datasets APAR OA20749"
- Previous by thread: Re: USSTAB color question
- Next by thread: Re: USSTAB color question
- Index(es):
Relevant Pages
|
