|
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 +---
As an Amazon Associate we earn from qualifying purchases.
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.