×
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.
On 20/01/2009, at 8:56 AM, David Wright wrote:
Is there a way to capture this type of error in *PSSR, display an
error panel, and allow processing to continue once the lock is
resolved? Basically looking for a way to tell the PSSR that it is ok
to resume the program and retry the operation on this specific type of
error.
Is that possible?
You can't do what you want. There are two reasons:
1) *PSSR is not invoked automatically for file I/O errors. It will
only be invoked for file I/O errors if you coded *PSSR as the INFSR
for the file.
2) *PSSR when invoked by the run-time exception handler is
effectively a GOTO. Lest that start yet another round of inane "GOTO
is bad/no it's not" appends let me say that the problem is not with
the GOTO per se but rather with the lack of a COMEFROM. That is when
the PSSR was invoked you don't know where you were in the program so
you don't know where to return. The PSDS and INFDS will help you
determine a potential starting point but you'll need to code TAGs at
each of those points and you'll need to branch to the TAG label from
within the *PSSR via (you guessed it) GOTO.
The *PSSR does support an automatic return function but it's
designed to work within the cycle (oh, crikey, there we go again,
another proscribed word) and as such the return points available are
all cycle entry points. The only ones of any use in a non-cycle
program are *DETC (start at the top of detail calcs i.e., your C
specs) and *CANCL (end the program). I doubt you want to start at the
top of the C-specs again and *CANCL is only marginally better than
the default exception handler.
So unless you already have the *PSSR specified as the INFSR (unlikely
since you state the original authors did no error handling) you can't
invoke the *PSSR to handle the error without modifying the source so
you might as well do it properly while you're in there.
Finally, the RPG exception handler does not support a "retry"
function. You can continue at Get Input (another cycle entry point),
cancel, or you can take various kinds of dump.
If you search the archives you'll find this topic has been discussed
frequently. I've written stuff about generic exception handling and
you'll find ways to use the *PSSR to catch and collect diagnostic
information for unexpected program and file errors. However, your
situation is NOT UNEXPECTED. Encountering record locks is an expected
part of writing code on a multi-user system. You've inherited code
written by idiots but your proposed approach is simply a bandage on
the SYMPTOM. You really need to fix the PROBLEM and that can only be
done by adding record lock handling code to your programs. You'll
find discussion and examples on that in the archives too.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
