Subject: Forwarded: [Re: TN3270E Extensions draft]

From: Michael Boe <[email-masked]>
Date: Wed, 15 Jul 1998 08:57:29 -0700 (PDT)

Folks,

This is some discussion on Gene's TN3270E Extensions draft which is forthcoming
(he had distributed a rough draft to a few people to make sure it was close to
what was desired).  The discussion quickly turned to technical points....and
the purpose of the list is to discuss those technical points.

So here's the discussion. I'll be forwarding the Draft to the list shortly.

/msb

------- Begin Forwarded Message -------
> Derek W. Bolton wrote:

> > > > >    The client MUST return a positive response to the server and
> > > > >    enter AID inhibit mode.  However, the keyboard remains unlocked.
> > >
> > > > @DB1:
> > > > No, the keyboard is locked.  See bullet 3 in Figure 9-5 in [1].  I
> > > > wrongly acceded to Jim's earlier claim that the keyboard should not be
> > > > locked.  Then I found this perfectly clear statement in [1] that it
> > > > should be.  I sent a follow-up mail to Jim, but he didn't respond to
> > > > the point.
> >
> > > I had the same argument last January with Jim.  He appeared to say
> > > that the documentation was wrong, and that he was right :-).
> >
> > It would be relatively straightforward for Jim or one of his
> > colleagues to test this.  Rather harder for anyone else.
> >
> > Maybe we can argue this is outside the scope of the tn3270e spec.
> > This aspect of the behavior does not affect the interface between
> > client and server, so it should be left as something for client
> > vendors to do as they see fit - follow the 3270 manuals, Jim's
> > views, or whatever they think makes functional sense.  (In my
> > view, the first and third are the same.)

Another approach is to say, well, the manuals are the spec.  If the
3174 behaves differently then that is either a bug or a value-added
feature.  Which of those it is depends on which is the preferable way
to behave functionally.  I have not seen any argument from Jim that
not locking the keyboard is functionally better.

> GP: I thought it was odd that the keyboard was not locked in this
> situation.But I went ahead with the way it was in the list mail I
> had.  I missed the later discussion.  This is why I wanted you guys
> to get a first look.

> > Maybe it's a terminology issue.  Gene, what does "AID inhibit mode"
> > mean?  How is it different from keyboard lock?  I can't find any
> > reference to it in GA23-0061-02 or GA23-0218-06.  (I've tried to
> > search the on-line version of GA23-0218, but the server is always
> > 'busy'.  Should be able to get it through
> > http://www.s390.ibm.com/os390/bkserv/hw and selecting the 3174
> > bookshelf.

> GP: AID inhibit mode may be OpenConnect-ese, I doubt you will find
> it in SNA (IBM) manuals.  It refers to the times the client is not
> supposed to forward 3270 AID messages to the server.  Although the
> client may send Sysreq or ATTN.

So far it sounds just like keyboard locked.  The question is
whether non-AID keystrokes go through into the screen buffer
or stay waiting in the type-ahead buffer.  My guess is that
they stay in the type-ahead buffer, in which case AID inhibited
is the same as keyboard locked, and the paragraph of the draft
quoted above is self-contradictory.

> It also refers to type-ahead mode, when the user has hit RESET and
> is entering keyboard data and AID keys that are buffered at the
> client.  The client is not allowed to forward the buffered AID
> messages until WCC keyboard restore and EOR state indicate it is the
> client's turn.

In all the years I've worked with SNA 3270, nobody I worked with
understood why the RESET key can locally clear keyboard lock.  Jim is
the first person who has been able to explain this to me.  The answer
is that it cannot in general do so!  It is only when the Host sends CD
without restoring the keyboard.  (This corresponds to the SYSTEM LOCK
state in the OIA.)  In this single case, the user can override the
Host's non-sending of keyboard restore and unlock the keyboard using
the RESET key.

The other main uses of RESET are to clear error conditions which cause
the keyboard to be disabled (so not even type-ahead works), and to
clear insert mode.  In fact, I was wrong to say that RESET always
clears the type-ahead queue.  If there is an error condition to be
cleared by the RESET, or the keyboard is in INSERT mode, then the
RESET will clear those conditions but not the type-ahead queue.  To
clear the type-ahead queue as well, a second RESET would be needed.

I don't understand your phrase "type-ahead mode, when the user has hit
RESET".  Type-ahead mode operates with the keyboard locked (but not
disabled).  If the user presses RESET, it may or may not unlock the
keyboard, as described above.  If it does, the user was previously in
keyboard disabled mode and is now in normal data entry mode, not
type-ahead mode.  If it does not unlock it then the user was probably
already in type-ahead mode and pressing RESET made no difference.

The general gating structure for alphanumeric input is:

  character -> |  --->  typeahead --> | --->  screen buffer
  input        |        queue         |
               ?                      ?
            unlocked ||            unlocked
            (enabled &&
             typeahead_
             feature)

I hope that's clearer.  If not, press RESET.  No, I mean, if not,
please read "Reset Function" in chapter 4, and appendix E of
the 3174 Functional Description.  (It's available on-line, but
the ppdbooks.pok.ibm.com server is hardly ever working!)

Regards,
  Derek

> This terminology issue will be eliminated when I correct this
> paragraph as you suggest.  But if there are other terminology issues
> I appreciate you calling me on them.  I need to use TN3270E-ese as
> much as possible.

> > > Also, this conversation should really really really be happening on
> > > the listserv, not just "amongst us chicks."  Gene, after correcting
> > > the problems that Derek has brought up, could you send to new
> > > version [email-masked] for posting as an I-D?

> > > Also, the draft doesn't "update" RFC2355; it extends it.  Probably
> > > best to put nothing there.
> >

> I'll make the suggested changes.  If issues for discussion remain,
> are the editorial notes OK to leave in?  It may help get the ball
> rolling.  Should I post to the TN3270E list first?  Or go directly
> to the ietf?

> Thanks,
> Gene

-------  End Forwarded Message  -------