RE: Classic Traps -- I need your input!

[Al Mac Wheel <macwheel99@xxxxxxxxxx>]

Error Message handling needs to be designed for real people, at real 
companies, in the interests of overall productivity of problem resolution.

Some companies get packaged software, then hire people to do clerical work 
with the software, in which the end users do not have a thorough 
understanding of the big picture, just their narrow data entry focus, how 
to do their tiny part of the big picture.

Some packaged software comes with error messages to the user in which they 
are supposed to take option A B C D E or F, that assumes they have a good 
understanding of the implications of each.  The average user does not read 
the error message, does not press F1 for explanation of the choices, does 
not call IT for help, just presses the enter key again and again until the 
computer gets a move on, does not tell anyone they had some 
problem.  Occasionally if they get a lot of this hassle, IT is told they 
were doing data entry (not what kind of data entry) and they got an error 
message (not what error message).

Often the default, what happens if you press the enter key, can cause a 
cascade of other problems.  There needs to be a competent log of what was 
going on that led to the error condition so that a person familiar with the 
application, not just IT, can later reconstruct how to get the situation 
repaired.

Some screen i/o is designed such that the user could key in say 20 values, 
each of which could be examined for validity.  A program comes back with an 
error message that ONE of these fields is no good, the user fixes it, then 
the program comes back with error message that another ONE is no good, the 
user fixes it, the program finds the next ONE at a time.  There are more 
productive ways for user input to be managed.

> I agree... I was always taught that the user should not be confronted with
> error messages.
>
>
> Michael Schutte
> Admin Professional
> Bob Evans Farms, Inc.
>
>
>
> midrange-l-bounces@xxxxxxxxxxxx wrote on 04/01/2008 09:30:26 AM:
>
> > One of my biggest issues is programmers who use the "Global Monitor
> > Message" {GMM}.  The "MONMSG CPF0000 EXEC(Goto EOP)" is a great tool
> > that is not used properly.
> >
> > There are a lot of "experts" who have "standard error handling routines"
> > that resend the messages back to the job's message queue & do nothing
> > else with the error.  The program does not tell anyone about the error
> > unless a programmer actually reads the joblogs.  I have seen a 6 hour
> > job finish in 10 minutes because of the GMM, all because of a simple
> > authority problem.
> >
> > These "standard error handling routines" need to be modified to actually
> > tell someone "Hey, there is an error here!"  The message should be sent
> > to the QSYSOPR message queue & not the user, because in my experience,
> > the users will ignore the message & do whatever they can to get rid of
> > it, including shutting down the connection.
> >
> > The GMM should never be used in a nightly job stream or for that matter
> > any long running process.
> >
> > The GMM should be used if you are writing commands or creating menus.
> >
> >
> >
> > \Vincent
> > --
> > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/midrange-l.
> >
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.