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
- RFCS: logmode selection Bill Kelly