On Fri, 23 May 2008 06:26:51 -0500, Chris Mason
<[EMAIL PROTECTED]> wrote:
>...
>You can have variable substitution in ***all*** USS messages, not
just USS
>message 10 and USS message 7. ...
>...
Chris, I understand the value of the messages and substitutions in
them, but I still don't think that's all the fault of the RFC. More on
this in a few lines.
>...
>What's the problem with the "ACB name"?
I got that same response at SHARE when I complained to a couple
of the TCP/IP designers at SHARE once. I was suprised by that
response then and I'm surprised to here it from you now.
At my last shop I had a set of Tn3270 defs shared aomg LPARs.
Being lazy, I used the same ACB names on all LPARs and used
a system symbol in the applid (LUname). Sure, I could have used
the system symbol in both LUname and ACBname. But why???
VTAM has supported different ACB and LU names in APPL defs
since the stone age. So when "luname" was displayed in MSG10
it was really the the ACB name (containing no LPAR identifier).
Anyway, if they were going to use the ACBname they should have
called the substitution phrase @ACBNAME. :-)
>...
>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 ...
LIkewise. In fact, I had to go back and forth between your posting
and the RFC a number of times and discovered I had completely
misinterpreted parts of what Mr Kelly was saying. And, yes, I
agree he got it wrong.
>
>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]
> ...
Perhaps if the RFC had said "real" or "actual" it would have been
correct. As you surmised, the "pass-through" mode must be the
outbourd implementations where VTAM's USS processes are really
involved. USS commands really can be passed over to the SSCP-LU
sessions, and VTAM will really send USS message back on those
sessions.
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.
>... Unfortunately Mr Kelley seems to be unaware of the
>subtleties of VTAM programming when implementing a secondary LU.
Perhaps. Or maybe he was just being literal. You can't pass the
input to VTAM as a USS command so it isn't real USS processing.
It's too bad the RFC used the term "SSCP-LU session" when talking
about USS processing. Too bad they didn't say
The design of some TN3270E servers allows them to fully support
the SYSREQ key because they are allowed to send USS
commands to the USS command processor.
Then the USS command processor could have been in either VTAM
or the server.
Maybe it's time to comment on the RFC. It hasn't been updated
since 1998 and is still a "Standard track RFC", not a "Standard".
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
