On Thu, 22 May 2008 06:31:49 -0500, Chris Mason
<[EMAIL PROTECTED]> wrote:
>...
>You may be sure that VTAM - let alone the TN3270E server - will not be
>interested in managing "Read Partition Query" exchanges on the
SSCP-LU
>session - either the real one or the emulated one.
>...
And even if it were interested, we're talking about a hard-coded
datastream containing the extended color attributes. The most
VTAM or a Tn3270 server could do would be to refuse to send the
message.
>I detect a tendency in your and Edward's responses to regard the
>possibility to use the enhancements to the 3270 data stream ...
>...as just a set of enhancements. ...
I can't speak for Ed but I was addressing this in the context of the
original post which refered to changing the colors.
>... If we assume that the
>possibilities are either basic or enhanced, then, if two sets of
>messages can be specified, one of each, it would make some sort of
>sense for VTAM or the TN3270E server to ask which applied and
>use the appropriate set. However, since the enhanced set can
>logically be constructed only on the basis of what
>is contained in the reply, even all this rigmarole doesn't make sense.
>
I'm afraid I agree.
>But, but, but I hear you say, you're making too much of a fuss.
Actually, I would have said "Yabut, yabut, yabut, ...".
>... What if the enhancement is understood to be limited to just
>colours and maybe extended highlighting such as underscores
>and reverse video. Unfortunately, this wouldn't work in the case
>of the 3290 which would happily claim to be "queryable" but would
>return only the possibility to present orange characters.
As I recall, the 3290's QUERY reply was very truthful regarding its
support of color. It supported all 7 and promised to present each
one as ... uh, actually, I don't remember. "Defualt" probably.
And its default was orange.
>...
>There is a glaring deficiency in the TN3270E RFC - USS messages
>***are*** involved in the case of the traditional SSCP-LU session
>in the exchanges over the SSCP-LU session. ... and the substitution
>of variables ...
Actually, this complaint should be directed at the server, not the
RFCs. Both RFC 1647 and 2355 include "SSCP-LU-DATA" Tn3270
Data messages.
IBM allows of substitution of some variables (as you mentioned
earlier in the thread) in MSG7 and MSG10. LUname is almost one
of them. The key for substitution is "@@LUNAME". Too bad they
insert the ACB name instead.
>...
>Very stupidly RFC 1647 imagines that the only use for the SYSREQ
>function while a session is in place is to invoke the SSCP-assisted
>logoff. ...
Once again, this is a defect of the server, not the RFCs. The set
"logoff" as the minimum to be supported.
>From RFC 1647
...
user may then enter any valid Unformatted Systems Services
commands, which are defined in the USS table associated with
the SLU. The most common USS command users employ
is "LOGOFF," ...
...
Servers that are not allowed to send USS commands on the SSCP-
LU session should behave as follows:
- if the user transmits the string LOGOFF (upper or lower case),
the server should send an Unbind SNA RU to the host ...
- if the user transmits anything other than LOGOFF, the server
should respond with the string "COMMAND UNRECOGNIZED" ...
Servers are free to support more than LOGOFF if they want.
(IBMTEST would be nice.)
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
----------------------------------------------------------------------
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
