RFCS: logmode selection

Bill Kelly <kellywh@mail.auburn.edu> Wed, 13 October 1993 12:49 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03047; 13 Oct 93 8:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03043; 13 Oct 93 8:49 EDT
Received: from list.nih.gov by CNRI.Reston.VA.US id aa08492; 13 Oct 93 8:49 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 6700; Wed, 13 Oct 93 08:47:31 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 6698; Wed, 13 Oct 93 08:44:54 EDT
Date: Wed, 13 Oct 1993 07:20:43 -0500
Reply-To: Bill Kelly <kellywh@mail.auburn.edu>
X-Orig-Sender: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bill Kelly <kellywh@mail.auburn.edu>
Subject: RFCS: logmode selection
X-To: IETF TN3270E Working Group List <TN3270E@LIST.NIH.GOV>
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
In-Reply-To: <9310122031.AA28483@ducserv.duc.auburn.edu>
Message-ID: <9310130849.aa08492@CNRI.Reston.VA.US>

(Once again, I stubbornly change the subject field to reflect the fact
that we are talking about the standards track RFC, not the 'current
practices' one.)

On Tue, 12 Oct 1993, Robert G. Moskowitz wrote:

> Bill Kelly said:
>
> >But if we require that a TN3270E server do a Read Partition Query, and
> >that all TN3270E clients be able to respond to it, then there won't be a
> >need for older host apps to be able to do an RPQ.  The server will select
> >a logmode based on the client's reply; that logmode may or may not have
> >the 'extended data stream' bit turned on, but it will certainly have a
> >primary (and perhaps an alternate) presentation space size.  Host
> >applications would continue to function as they do today - if the logomode
> >had the eds bit on, the app *can* (but doesn't have to) send an RPQ.  The
> >only difference between this and traditional tn3270 is that the server
> >assigns logmodes based on Query Replies from the clients rather than from
> >a mapping of Telnet terminal-types to logmode names.
>
> Sounds OK but...
>
> These apps are REALLY DUMB.  The logmode is very specific.  Some of them are
> mod 2s without EABs, others are mod 4s without EABs.  No other LOGMODEs need
> apply.  How would the client specify that it want to be a particular type?
>
> Bob

There are probably others on the list who can answer this better, because
they have experience in building and interpreting Query Replies.  In
general, though, I'd say the client will send a Query Reply (Usable Area)
which will contain a 'Base' segment indicating the number of rows and
columns (and buffer size) for the primary display area; the Query Reply
could (in the case of model 3, 4, 5 or 'other' emulation) also include an
'Alternate Usable Area Self-Defining Parameter', which specifies the
number of rows and columns in the alternate display area.  The server will
have to use these values to select a logmode containing the corresponding
settings in the PSERVIC field.

The client could refrain from including any Query Replies for Highlight,
Color, or Character Set; this would indicate to the server that a logmode
with the 'eds' bit turned off should be selected and presented to the host
application.

The bottom line is that a 'dumb' (non-EAB, model 2, for example) terminal
can be emulated by clients simply by sending in the appropriate set of
Query Replies.  The server will select a logmode that represents a minimal
function terminal, and the 'dumb' host applications can get the needed
info from the logmode (or Bind image, as the case may be).

On a different tack, I've been wondering - should we leave unspecified
exactly how a server comes up with logmode names/Bind images?  Some shops
use the IBM-supplied table (ISTINCLM, in the case of VTAM) exclusively,
some use a combination of IBM-supplied and user-defined tables.  Any
thoughts on this from anyone?  Fred, you're a server person; how do you
think it should work?

Also, some help on terminology and how this works in a non-VTAM
environment would be greatly appreciated.

Thanks,
Bill

Bill Kelly               phone: (205) 844-4512
Auburn University     Internet: kellywh@mail.auburn.edu