|
midrange.com
If you're on V5R2 another alternative if you can't change the application
(which is by far the best solution) would be to use the new Reply Handling
Exit Program (found in the Information Center under Programming/APIs/APIs
by category/Message Handling/Reply Handling). I just wrote a quick test
case where I replace the default (Enter) value with 'D' for RPG0102. You
would need to check for more messages, but this might do the trick for you
so long as you know what errors are possible.
One warning. The Information Center is being updated to reflect that debug
breakpoints do not work when using this exit point, so developing the exit
program should be done on a development system (or one where any errors in
the exit program will not cause major problems with production work). This
lack of debug support is most likely going to be a permanent restriction
due to some system internals that I'm not going to get into).
Bruce
"Booth Martin"
<Booth@xxxxxxxxxxxx> To:
<midrange-l@xxxxxxxxxxxx>
Sent by: cc:
midrange-l-bounces@x Subject: Re: Catching errors
on user screens
idrange.com
06/26/2003 08:58 AM
Please respond to
Midrange Systems
Technical Discussion
In a similar situation with the mandate of "we don't modify vendor code" I
used a trigger on the file with the disasters. At least that way I could
stop their program and alert them. In that instance I used a *BEFORE
trigger and if they were using invalid data I could have them do it over
and
over til they got it right. The audit journals were inaccurate for that
entry of course but the client preferred that to busted production. In
your
instance I suppose you could have a message sent to your screen saying "Go
see User X. S/He's doing it agaIn"
---------------------------------------------------------
Booth Martin http://www.MartinVT.com
Booth@xxxxxxxxxxxx
---------------------------------------------------------
-------Original Message-------
From: Midrange Systems Technical Discussion
Date: Thursday, June 26, 2003 3:52:29 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Catching errors on user screens
Hiya,
well, as one of our apps we have an old BPCS implementation. The users of
the app are very inexperienced and tend to create lots
of user problems.
Worst of all, when one of the programs crashes, they just ignore the
problem and press enter until the error screen goes away. When
I'm lucky they will call they had a problem, but normally they wait until
consequential errors occur.
Any trick to stop these users cold at the error screen? I preach to them
every other day to at least press 'D' and Enter, so I get a dump.
But most of the time they'll just do enter.
Thanks,
Oliver
_______________________________________________
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
