RE: SQLRPG error MONMSG possible ?

Good info on using %error & %status.  I knew about %error but hadn't seen
%status before.

Per the argument about using the error indicator on a WRITE or UPDATE, I
wasn't speaking so much about using indicators as I was speaking to
anticipating an error occurring because the existence of a duplicate key was
not checked prior to the WRITE or UPDATE.  It seems to me that there is much
more overhead associated with a file I/O error than there would be with a
SETLL.  On the issue of what happens more, the error or a successful
update/write, you make a good point from a performance point of view.  I
suppose that if you're only getting a few duplicate key errors from writing
1,000,000 records, you probably would see a performance benefit for testing
for the output error rather over the SETLL *EQ.  However, I'd be hard
pressed to believe that the lone SETLL *EQ in amongst all the other things
that happen in the cycle of writing a record would have any significant
impact on the overall performance.  (sounds like another benchmark test!)

While I think it would be quite a stretch to imagine a record being slipped
in from another job between a SETLL *EQ and a WRITE / UPDATE, the use of
%error and %status would be most beneficial for this and all the other
possible errors.  I presume that you use them Rob?  Do you still use the
*PSSR or do you just test for these errors inline after the WRITE / UPDATE?

On the argument of using SETLL *EQ vs. testing for an error on output, this
is beginning to look a lot like the topic of coding READ loops, i.e. two
READs and one DOW structure or one READ and a DOU and IF structure combo.
To each their own.

- Dan Bale
> -----Original Message-----
> From: Rob Berendt [SMTP:rob@dekko.com]
> Sent: Friday, April 07, 2000 12:59 PM
> To:   RPG400-L@midrange.com
> Subject:      RE: SQLRPG error MONMSG possible ?
> 
> Your first argument can be simplified by avoiding indicators at all 
> and using RPG IV.  Use the (e) extender on your WRITE or UPDATE and 
> check %error and, for details, %status.  Therefore bypassing an INFDS 
> for these simple functions.  Using these is not a lack of planning - 
> it is good planning.  You can check for all errors without the overhead 
> of SETLL.  Especially when you consider this - Which will happen more 
> - the error or a successful update/write?
> 
> Your second argument assumes that all file I/O is done via RPG, and 
> only this particular RPG program.  In the age of Client Server, web 
> and whatnot we have to rely more on database integrity.  The key 
> should not be removed.  This is a very conscious act.
> 
> I can think of a few reasons for why doing the SETLL is bad programming 
> practice.
> 1)  Performance reasons - your coding for the error happening more than 
>     the success.
> 2)  A record may appear between your SETLL and your WRITE.  
>     This would be better trapped by the %error and %status.
> 
> 
> 
> 
> 
> DBale@lear.com on 04/07/2000 11:33:58 AM
> Please respond to RPG400-L@midrange.com@Internet
> To:   RPG400-L@midrange.com@Internet
> cc:    
> Fax to:       
> Subject:      RE: SQLRPG error MONMSG possible ?
> 
> Istv;n,
> 
> Guess I should have prefaced that with "IMHO" (In My Humble? Opinion).
> 
> Using an error indicator on the WRITE or UPDATE operations shows a lack of
> planning; it says to me that the original programmer didn't anticipate
> ever
> having a duplicate key error and, when the error finally reared its ugly
> head, the programmer quickly slapped in an error indicator to get the
> program running again.  Using a SETLL *EQ before a WRITE or UPDATE with a
> minimal amount of comments makes it clear that the programmer expected the
> possibility of duplicate keys and took appropriate action to avoid causing
> an "error" indicator to be turned on.
> 
> Opinions aside, here are a few practical reasons for avoiding using an
> error
> indicator to check for duplicate key errors:
> 1) There are other errors besides duplicate key errors that can cause  the
> WRITE or UPDATE error indicator to be turned on; how, then, will you know
> what the exact error is (unless you're monitoring for the error in the
> INFDS)?  Of course, if you took the effort to monitor errors in the INFDS,
> you probably extended the effort to use a SETLL *EQ to check for the
> existence of the record.
> 2) I never presume that the UNIQUE keyword has been defined for a given
> access path.  What if somebody removed the UNIQUE keyword from the file,
> either inadvertantly or for good reason unrelated to your reliance of
> using
> that to catch duplicate keys?  IMHO, UNIQUE is a machine-level safeguard
> to
> prevent duplicates that would corrupt the integrity of the data, and it
> should never be used as a crutch to support a programming practice for
> which
> a technique exists to test for the existence of the key regardless of
> whether UNIQUE is specified.
> 
> It is my opinion that every database needs at least one access path with a
> unique key.  It may well be that the field that makes the key unique is
> nothing more than a sequence number or the RRN.  I'm no expert on database
> design (and others are asked to comment on this), but I seem to recall
> from
> long ago that one of C. Date's rules for good design speaks to this.
> 
> - Dan Bale
> 
> > -----Original Message-----
> > From:       Istv;n Rudas [SMTP:Istvan@Rudas.net]
> > Sent:       Thursday, April 06, 2000 6:56 PM
> > To: RPG400-L@midrange.com
> > Subject:    RE: SQLRPG error MONMSG possible ?
> > 
> > At 13:01 06.4.2000 -0400, DAN BALE wrote:
> > 
> > >... ... you will avoid the message that's slowing you down.  However,
> > this is
> > >considered to be a bad programming practice.  (... ... )
> > 
> > Dan Bale: please would you express more precisely, WHY this is
> 'considered
> > to be a bad programming practice'?
> > 
> > Since a lot of years I use this error-indicator, making after the
> > WRITE-statement the error-handling: this could be (not often used) just
> > writing to an error-protocol file with sendmessage to the operator after
> > LR, but most likely (=nearly always) I have the so-called Unique key,
> when
> > making the databasedesign, always added with an additional (internal)
> > numeric field as last portion of the whole key: so I add +1 to it when
> the
> > error-indicator was *ON until it is *OFF, this means that the program
> has
> > never to STOP with the "blue screen of death" /cpyr bill g./, and I can
> > alarm the operator/user/human at the program end (or other logical
> > transaction end) with a message if interactive, or a protocol file or a
> > list if it runs batch, where he has to look for this "duplicate key" in
> > the
> > sense of the application, but not-duplicate for the machine!  
> > 
> > (Would this be only a theoretical discussion, I would say, yes + guilty,
> I
> > am quite never using a UNIQUE key even if I write it in the DDS; as
> > practical application maker I say, that it is unique until the moment
> when
> > something goes wrong and in this moment I leave NOT the responsibility
> for
> > answering to a CPF (C G I R?) to a user who is not a programmer - then
> > something has to be wrong with MY data design and its ME who has to
> react
> > with a better design).--- Of course, the question of alarming or not
> > depends of the nature of the application, as in many cases it could be
> > nonimportant to allow more "unique" records (as you mention, then look
> > first for the highest key with Setll and so on), then use an internal
> > numeric field, see above.
> > 
> > If your comment was, to use the error indicator and then NOT doing some
> > error handling=doing nothing, then we are meaning the same, this can be
> > very stupid and is really not professional.
> > 
> > Thank you for answering
> > Istv;n (from Austria)
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---