Edward There is (still I guess) an aspect of the VM logon panel, copied in the NetView logon panel[1], which, to my mind indicated a lack of understanding of "human factors" in the implementation of the 3270 data stream and its effect on the operator experience.
When deciding whether or not to use the "autoskip" bit in the attribute character which defined the end of an input field, my opinion is that it should depend on whether the data to be entered necessarily fills the entire input field or may not. If the input data is guaranteed to fill the field, then the use of the "autoskip" bit is appropriate. Ideally such a field will be part of a sequence of such fields so that reaching for the tab key will not be necessary within the whole sequence. If the input data is *not* guaranteed to fill the field, then the use of the "autoskip" bit is *not* appropriate. The operator will be assured that use of the tab key will always be required after having keyed the current character data. If such a field is part of a sequence of fields, it may even be better ergonomics to require the use of the tab key for every one of the fields - even if one or two meet the "guaranteed to fill" criterion. The VM and NetView logon panels use the "autoskip" bit universally as if the programmer thought "neat" (or "cool") when reading up on the 3270 data stream capabilities for the first time and never missed an opportunity to use it - it's when you are irritated by such tricks that such evil thoughts come to mind. The irritations arose actually with NetView. In general I always used the tab key after entering a userid and then my password. If the userid I happened to be using filled the whole field - I guess it would happen to have been eight characters long - I used the tab key as usual - I'd have been concentrating on the keyboard as now since I'm a fairly fast - and clumsy - two finger man - and the password would have appeared for the world and his dog to see in the PROFILE field. I believe something similar happened with the VM logon panel. Now, of course, some will say, "But surely you have only one userid and so how can this ever be a problem; you will either need to use the tab key or you will never need to use the tab key." Such people lack imagination. If you are a systems programmer in charge of - I'll stick to NetView although I believe the same would happen in VM - an automation system, you may well need to log on as one of the "automation operators" in order to sort out a problem and the automation userids could have a variety of lengths with some being eight characters long. Ideally there should have been an IBM corporate directive to impose the principle I outlined above - especially where failure to apply the principle could expose passwords. As it is it's as if there was a "de facto" opposite corporate directive. And I wonder how many vendor products have copied VM and NetView assuming that IBM always leads the way to "best practice". Chris Mason [1] I can't recall whether or not the "mistake" was also present in the TSO/E logon panel. It's easy to check. ----- Original Message ----- From: "Edward Jaffe" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <IBM-MAIN@BAMA.UA.EDU> Sent: Sunday, 03 September, 2006 5:11 PM Subject: Re: APAR OA16111, BlueZone, and Vista (Was: >27x132?) ... > The VM guys did a *much* better job on their logon panel, which *was* > "official" VM from the start. They obviously understood 3270 a whole lot > better. > > -- > Edward E Jaffe > Phoenix Software International, Inc > 5200 W Century Blvd, Suite 800 > Los Angeles, CA 90045 > 310-338-0400 x318 > [EMAIL PROTECTED] > http://www.phoenixsoftware.com/ ---------------------------------------------------------------------- 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