RE: Classic Traps -- I need your input!

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.