Re: Error Indicator on Write

["David Morris" <dmorris@xxxxxxxxxxxxx>]

Simon,

I was just referring to your statement "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 difference over a year would probably add up 
to less time in a year than 
it takes to key in this message.  I was assuming you meant multiple READs.  As 
I re-read your statement I see 
that is not necessarily the case.  My assumption was based on the belief that 
it would make absolutely no 
sense to do a SETLL single READ when looking for a specific key.  If what you 
intended was SETLL 
followed by READE, all bets are off.  However, if you meant multiple READs 
follow the SETLL and a 
program can take advantage of blocking, which is sometimes tricky, you can see 
a real performance 
improvement.  This doesn't mean that it will always be an improvement, but in 
the case of a CHAIN and 
READ vs SETLL and READ, I think blocking would usually provide an improvement 
which would 
be substantially more than CHAIN/READ vs SETLL/READ.

I made a simple change to our I/O modules (the only convoluted part was having 
to do an override to compile,) 
to support blocking with READE by providing my own key compare.  I then ran 
benchmarks using live 
data and transactions, and saw an average improvement of over 33%.  The worst 
case was about 5% 
improvement.

David Morris

>>> "Simon Coulter" <shc@flybynight.com.au> 03/15/99 06:41AM >>>
Hello David,

I don't see that blocking will necessarily provide much help.  CHAIN and SETLL 
are generally used with keyed 
files (although there is no requirement for that **).  In these cases the I/O 
is random.  Having the index 
resident in main store will help but blocking keyed files often does more harm 
than good.  Maybe I'm just 
missing your point.

Although isn't BLOCK(*YES) an option on the open in C?

** Fun trick in RPG 101 -- Create an example file keyed on customer number; 
choose customer numbers that are 
multiples of 10 (10, 20, 30, etc), add records such that RRN 1 has key 10, RRN 
2 has key 20, etc.  Explain 
the use of CHAIN and the 'K' on the F-spec.  What the confusion during the labs 
as the students puzzle out 
why a request for customer 10 returns data for customer 100 and 100 fails with 
record not found.  Anyone spot 
what the students invariably do?

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.                      «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
//--- forwarded letter -------------------------------------------------------
> X-Mailer: Novell GroupWise 5.5
> MIME-Version: 1.0
> Date: Tue, 09 Mar 99 10:23:42 -0700
> From: "David Morris" <dmorris@plumcreek.com>
> To: MIDRANGE-L@midrange.com 
> Reply-To: MIDRANGE-L@midrange.com 
> Subject: Re: Error Indicator on Write

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