Re: Error Indicator on Write

["David Morris" <dmorris@xxxxxxxxxxxxx>]

Simon,

I agree you should use the write with exception test if the write is expected 
to work.  One minor addition, because this was presented as the definitive 
answer and I wouldn't want it to be anything less, is that when the CHAIN or 
SETLL opcode is used to test for existence prior to a write consider using 
the BLOCK(*YES) keyword.  This will help ensure you actually get the 
cheapest solution, and potentially makes more difference than a 
SETLL over CHAIN.

David Morris

>>> "Simon Coulter" <shc@flybynight.com.au> 03/08/99 02:04AM >>>
Hello All,

This topic has raised a few questions.  Here is the definitive answer 
(Conceited? Watashi?).

The original append was asking why the indicator in the LO column was set on 
even if no duplicate record was 
in the file.  Simple, because the LO column is the generic error column.  Most 
RPG programmers ASSUME it 
indicates a duplicate record but that is just lazy coding.  I can't tell you 
why the error indicator was set 
on for this application but there should be information in the joblog, or 
QSYSOPR, or the file feedback area 
in the RPG program.

Now to the root of the problem.

Never assume the error indicator means duplicate key.  Write code that can 
gracefully check if the problem is 
really a duplicate key.  If the error indicator is on then check the *STATUS 
field in the file feedback area 
(INFDS) for a code of 01021 which indicates duplicate key or duplicate RRN.  If 
the code is something else 
then determine if you can handle it programmatically or exit to a graceful 
error handler.  This can all be 
done as a SELECT statement in a generic error subroutine.

You should write the code to handle the expected case.  If you expect the WRITE 
to work and only sometimes 
fail due to duplicates then code the WRITE and catch the error.  If you expect 
duplicates to mostly exist 
then check for the record before the write.  Checking should be dome with CHAIN 
if you want to process the 
data in the program or SETLL if you are simply checking existence.  The raison 
d'etre behind these 
recommendations is avoiding exception overhead and data overhead.

Checking for existence is cheaper than attempting the write and having it fail 
but only if the commonest case 
is finding a duplicate.  SETLL is cheaper than CHAIN because the system does 
not move the data into program 
storage.  A CHAIN is cheaper than a SETLL followed by a READ if an exact match 
is requested (key or RRN).

The File Status Code section of the RPG manual contains all the information you 
will need to write robust 
code that KNOWS what is happening and never needs to ASSUME what may have 
caused an error.  Use the tools 
appropriately.

Regards,
Simon Coulter.

«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
«» FlyByNight Software         AS/400 Technical Specialists       «»
«» Eclipse the competition - run your business on an IBM AS/400.  «»
«»                                                                «»
«» Phone: +61 3 9419 0175      Mobile: +61 0411 091 400           «»
«» Fax:   +61 3 9419 0175      mailto: shc@flybynight.com.au      «»
«»                                                                «»
«» Windoze should not be open at Warp speed.                      «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---