Several situations can arise where the 3270 style terminal will lock the keyboard, refuse any further keystrokes, and display a symbolic error message on the bottom line (Operator Information Area or OIA). It can occur after some screen of information has been sent to the mainframe but a response has not been received. It also can occur if the user attempts something invalid, like typing a character into an area of the screen that is a protected field.
The terminal should refuse to honor any further keystrokes until the RESET key is pressed. That removes the symbolic error message from the OIA and the terminal begins accepting further input. However, the behavior of oec did not match that.
With the released version of oec, when such a condition arose, the symbolic error message appeared in the OIA but the keyboard responded to any and all keypresses. Further, the error message was removed on the very next keypress, even though it wasn't a RESET.
Andrew modeled it the way he did because it matched what he saw from TN3270 client software. He had noted that the arrow keys, TAB and other keys worked right after the lockup condition. I tried with Vista 3270 and reproduced the results.
I dug into this further, since it contradicted both my experience with 3270 terminals years ago and what the manuals said would happen. I discovered that TN3270 software, for the convenience of the user, will unlock the keyboard automatically, in effect pushing the RESET key just before whatever key the user had next struck.
It was a configuration option in the Vista 3270 software and once I deselected that choice, the behavior strictly conformed to the IBM manuals and real 3270 terminals. No key would be accepted other than RESET once the terminal locked up.
I then added code in oec that will set and remember the locked state, silently throwing away any keystroke other than RESET. When RESET was typed, it cleared the OIA error messages and turned off the locked keyboard flag.
NUMERIC LOCK BEHAVIOR INSTALLED
The numeric lock feature or option operates when in any unprotected numeric field. Attributes that define fields can specify them as protected or not, numeric or available for any character, hidden or visible, and determine if the light pen can be detected when placed in the field.
Numeric lock will behave just like having toggled the Num Lock key. When on, it treats each key as representing the character printed on the upper half of the keycap. For example, the keycap that has K on the lower half has the digit 5 on the upper cap. Without having to hit Num Lock or the up shift key, the keycap is interpreted as 5 anytime you press it while in a numeric field.
The feature is more restrictive, however, than just forcing the upshift. Numeric Lock only permits the digits, decimal point, minus sign or DUP key. For instance, the keycap that has E on the lower half has a right parenthesis on the upper half. Hitting the keycap will be rejected because the upshifted character is not valid in a numeric field.
The hardware allows an override from this behavior while in a numeric field. If you push the up-shift key (upwards arrow on the keycap), you can choose the upper half characters that are NOT numeric. Up shift and the E keycap will enter a right parenthesis. The downward arrow key, down shift, allows entry of any of the lower half characters. Down shift and E keycap will enter an E into that numeric field.
I had previously mentioned implementing this, but I gave more details on how it works and frankly had refined the implementation significantly. If not over-riding with up-shift or down-shift, whenever an invalid character is attempted, the OIA shows a symbolic error message and the keyboard is locked up until RESET is pressed.
CLEAR FUNCTION NOT RESETTING ATTRIBUTES
The way that the CLEAR key (ALT plus CURS SEL keycap) is handled is unique within oec, being handled in a different module than all the other keys. It did clear the screen of all characters, but somehow the code still remembered the fields that were protected. A CLEAR should remove all attributes and fields, leaving the screen not only erased but consisting of a single long unprotected field with no attributes.
I moved the implementation to a different spot, where it would leverage the code that ensures the fields and attributes are updated properly This produces the correct behavior in accordance with the IBM manuals and real terminal behavior.
No comments:
Post a Comment