I only want to gurantee that the program does not go into MSGW status,
so that is not an issue in this case. Beside, Monitor will not catch
SQL error either.
For SQL, I've created two standard export procedures that I normally
call after an embeded SQL is executed. They are: utilCheckSQLStatus and
utilCheckSQLStatus_Esc. The first one returns a flag to tell caller if
SQL error has occurred, the later will send *escape message (which will
trigger *pssr or monitor to catch it) when it detected a SQL error. The
code for these two procedures look like below.
Note: These two procedues has code to call other export procedures.
Codes for those other procedures are not included in this email (for
example: sndMsg procedure is a wrapper for QMHSNDPM api).
******************************************************************
* check SQL status -
******************************************************************
P utilCheckSQLStatus...
P B export
D pi n
D piSQLState like(svUtilReffldSQLState)
D const
D piSQLCode like(svUtilReffldSQLCode)
D const
D piRtnMsgID like(svUtilReffldMsgID)
D options(*nopass :*omit)
D piRtnMsgText like(svUtilReffldMsgText)
D options(*nopass :*omit)
* variables
D myRtnMsgID s like(svUtilReffldMsgID)
D mySQLCODE ds qualified
D Value 1 10s 0
D last4Char 7 10
D last5Char 6 10
/free
if %subst(piSQLState :1 :2) <> '00' and
%subst(piSQLState :1 :2) <> '01' and
%subst(piSQLState :1 :2) <> '02';
// construct SQL message ID
mySqlcode.value = %abs(piSQLCode);
if mySQLCode.value <= 9999;
myRtnMsgID = 'SQL' + mySQLCode.last4Char;
else;
myRtnMsgID = 'SQ' + mySQLCode.last5Char;
endif;
if %parms() >= 3 and %addr(piRtnMsgID) <> *null;
piRtnMsgID = myRtnMsgID;
endif;
if %parms() >= 4 and %addr(piRtnMsgText) <> *null;
monitor;
piRtnMsgText = rtvMsgd(myRtnMsgID :'QSQLMSG');
on-error;
endmon;
endif;
return not @SUCCESSFUL;
endif;
return @SUCCESSFUL;
/end-free
P utilCheckSQLStatus...
P E
******************************************************************
* check SQL status - send escape message if SQL is error status
******************************************************************
P utilCheckSQLStatus_Esc...
P B export
D pi
D piSQLState like(svUtilReffldSQLState)
D const
D piSQLCode like(svUtilReffldSQLCode)
D const
D piPgmName like(svUtilReffldPgmName)
D const options(*nopass :*omit)
D piPssrID like(svUtilReffldPSSRID)
D const options(*nopass :*omit)
* variables
D myMsg S 256 varying
/free
if %subst(piSQLState :1 :2) <> '00' and
%subst(piSQLState :1 :2) <> '01' and
%subst(piSQLState :1 :2) <> '02';
myMsg = 'Error occurred when running SQL statement. ' +
'SQLSTATE = ' + piSQLState + ', ' +
'SQLCODE = ' + %char(pisqlCode);
if %parms() >= 3 and %addr(piPgmName) <> *null;
myMsg += ', Program Name = ' + %trim(piPgmName);
endif;
if %parms() >= 4 and %addr(piPssrID) <> *null;
myMsg += ', PSSR ID = ' + piPssrID;
endif;
sndMsg('CPF9898' :myMsg :'*ESCAPE');
endif;
/end-free
P utilCheckSQLStatus_Esc.
"Needles,Stephen J" <SNEEDLES@xxxxxxxxxxxxx> wrote in message
news:<mailman.2517.1285689832.2702.rpg400-l@xxxxxxxxxxxx>...
Because *PSSR won't be automatically invoked when an SQL fails
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of hockchai Lim
Sent: Tuesday, September 28, 2010 10:55 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Convert from free to fixed
There is no doubt that one should use monitor on places where failure is
likely to occur and handle that specific error accordingly. But if I
want
to guarantee that my RPG program never goes into a MSGW status, I
usually
use *pssr. Why wrap the entire main procedure with an ugly monitor
opcode
when I can use a *pssr to provide me that guarantee.
"Luke Gerhardt" <lgerhardt@xxxxxxxxx> wrote in message
news:mailman.2500.1285687705.2702.rpg400-l@xxxxxxxxxxxxxxx
But...using monitor/endmon you can handle errors at point of failure
and
not just try to end the whole thing 'gracefully' at the first sign of
danger. I don't believe you get any such granularity with *pssr.
/free
// convert potential text field into numeric
monitor;
field_number = field_text;
on-error;
field_number = default_number;
endmon;
// display 132-wide screen
monitor;
open my_display_file;
exfmt wide_screen;
on-error;
call program_to_display_132_screen_error
endmon;
/end-free
I do the second process to call a small RPG program that displays a
warning that the workstation is not configured to display a 132-wide
screen. I don't believe I could do multiple error recovery in-line
and
handle specific errors as easily with *pssr, could I? (honest question
as
I am not 100% familiar with *pssr)
However, if you stage the monitor/endmon around your whole monolithic
program as you did in your example, then yes, you get none of the real
benefits of the function. You really need to wrap the parts of your
code
that need handled with their own monitor blocks.
On 2010/09/28 11:03, rpg400-l-request@xxxxxxxxxxxx wrote:
date: Tue, 28 Sep 2010 09:32:29 -0500
from: "hockchai Lim"<lim.hock-chai@xxxxxxxxxxxxxxx>
subject: Re: Convert from free to fixed
So, instead of using *pssr, you would rather do below in the main
procedure?
For clarity of code, I would rather use *pssr for this. I guess each
person
has his/her own preference:).
/free
// global error monitor
monitor;
//code for main procedure goes here
on-error;
// handle something is wrong somewhere;
endmon;
*inlr = *on;
/end-free
midrange.com
