× 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 15-May-2015 07:57 -0500, Gad Miron wrote:

We have a Java-Windows application that uploads text files (one at a
time) to the iSeries/System i/AS400 machine and then calls a Stored
Procedure to process the file uploaded.
The SP calls an RPG program that in turn conditionally call other
RPG/CL programs.
all of the above is executed in a QZDASOINIT job (spawned
especially?)

Sometimes one of the RPG/CL programs in the process "bombs" (with a
CPFXXX) but the guy using th Java application is not aware of it, it
is the SYSOPR actually that sees the MSGW status of the QZDASOINIT
job and calls a programmer to look at it.

Now,
Is there a way to trap the errors and inform the Java application
user that there was an error ?
This, *without* inserting MONITOR lines in the RPG programs and
manually returning some kind of a return code?

The Java programmer tell me she can trap an error but an error is
not received. (perhaps it is another QZDASOINIT job? )

Any advice will be appreciated


Wait long enough, and the SQL will terminate the SQL stored procedure due to a timeout; I do not recall the default, but probably the QAQQINI allows changing that.... but probably not he best to pursue.

If there is no desire to change the CL and RPG programs that will be called in that code path to perform without inquiring for the Language's Default Handler [for which the inquiry message is the effect for an unmonitored error\message], then ensure the jobs run with an Inquiry Message Reply (INQMSGRPY) handling option of something other than Required (*RQD) so that the operator never gets an opportunity to handle the message [or use the Exit program feature for inquiry message reply handling so that a program can make the decision instead of the operator who might simply defer to the programmer]. If the System Reply List (*SYSRPYL) is chosen, then either ensure the appropriate value for the Message Reply (RPY) for the Reply List Entry (RPYLE) for the message [range] is chosen to allow for the necessary doc collection [e.g. D=Dump] or else ensure similar effect using the message's Default (DFT) just as if the Default (*DFT) were chosen for reply handling [which is the remaining choice for InqMsgRpy handling].

Irrespective of how the SQL stored procedure completes due to the message being replied, the Java will then eventually get control, as providing the reply allows continuation of progress. If instead the effect was termination by SQL timeout then the Java requester gets the "Statement Canceled" sqlstate and the Java interface presumably would see that as an error as with any other negative sqlcode. If the effect was continuation due to the programs /recovering/ from the condition(s) that was initially un-handled for which the generic language-specific "help me" message inquired and then replied-to with an automatic reply [similarly if the operator or programmer had entered the reply], then the Java interface presumably gets no error and the results [assuming the /recovery/ was purposeful rather than code improperly _ignoring_ failure conditions]. If the effect was that the message reply effected exception-percolation back to the SQL stored procedure for which there may be either a default handling [but no inquiry reply, just set the sqlstate=bad_thing] or is coded with handling [e.g. with Declare Exit Handler], then that procedure returns either with a negative outcome and the Java interface likely sees that failing return-code as an error or the SQL stored procedure could /handle/ the condition and give the Java interface what was requested [e.g. result set] and return with an sqlstae indicating just a warning rather than a failure or perhaps obfuscates entirely [legitimately or not] the underlying difficulties and just returns the sqlstate=00000 indicating everything is golden.

If the SP is just the native program defined to the SQL as an External, then the same applies except the final bit about the SQL Stored Procedure for which there is none. Regardless, run via the SQL, if the native programs inquire, they cause waits... until there is a reply provided; no different than at the local\emulated WS, but for whatever reason the effect is perceived differently when the client does not have constant access to [because they are not directly working at] the WS, so often best to code the programs to use their own error handling instead of the Language Run-time Default Handler for which the effect is [typically] an Inquiry Message that awaits a reply and thus holds-up processing until that reply is received [by whatever means].


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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.