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.comm
+---


+---
| 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
+---