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
