×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
The *PSSR will not act recursively if you do the following
begSR *PSSR ;
Monitor ;
Dump(A) ; // Or other error-handler line
On-Error ;
Return ;
endSR ;
In a message dated 4/21/2009 9:16:55 P.M. Jerusalem Daylight Time,
rpg400-l@xxxxxxxxxxxxxxxx writes:
*PSSR and DUMP(A) will work -- but I personally avoid that scenario.
My problem with *PSSR is that it handles it's own errors. i.e. if an
error occurs while *PSSR is running, the same *PSSR gets called again...
it results in a mess.
I prefer to use MONITOR for that reason. Use MONITOR across your whole
subprocedure, and put the DUMP(A) in the ON-ERROR section. I also find
it helpful to have a QCMDEXC('DSPJOBLOG OUTPUT(*PRINT)': xx) in my
ON-ERROR as well... (actually.. I usually find DSPJOBLOG more useful
than DUMP -- I never really liked dumps...)
If you really want to be fancy, write a CL program that takes the dump &
job log, creates an e-mail, and sends them to whomever is responsible
for the program.
This works well because users are rarely able to give you useful
information when a program crashes. (In fact, they often avoid calling
you altogether, in my experience.) This way, you always get good error
information.
Arthur Marino wrote:
I'm reading up on *pssr and dump(a) as we speak. Thanks, all.
midrange.com
