Re: Advice on Performance and Record lock considerations.

On Mon, Oct 27, 2008 at 9:33 AM, Brown, Stephen GRNRC
<Stephen.Brown@xxxxxxxxx> wrote:

Thanks Charles.

Looking at your response I am kind of using your 3rd suggestion, I'm not
using a DTAQ (have been warned off them in the past) but I am setting up
the source file to act like one I guess.

Who warned you off of them? I'd be willing to bet it wasn't one of
the experts like Scott, Jon, Bob, Barbara, ect.

The key reason to use queues instead of a DB file, is that the I/O
cost for queues is significantly smaller than a DB file. May not be a
factor if you're not dealing with lots of records at a time.

Here's something to consider, the OS itself makes extensive use of queues.

The source and detailed files are not journalled, the source is really
just a trigger to creating the detail. The idea was to create a set of
transaction records containing file updates that could be processed one
by one. Another point I didn't mention is that the "explosion" from
source to detail is not fixed. This process needs to look up a file to
determine which linked accounts should be updated. This is variable
depending on at what member level the change is made at.

From a performance standpoint, the extra I/O could hurt. If the

performance is not up to requirements, you might be able to make
improvements here. At the very least, your could for example check to
see if the record you need has already been read in instead of
automatically doing the chain. Depending on the size and/or
selectivity of the rows needed, SETOBJACC or having your program
cache/pre-load records may make a big difference. Of course if the
records you're accessing change, then that's another can of worms.

The source record is created within the Trigger program over the main
file, I check for a particular change looking at the bef/aft image of
the record and write to the source file as need be.

The interval will probably be set to say 15-30 secs when in production.
I have used Block(NO) on all write and updates, are you saying block is
only relevant if the file is set to output only ?

From the manual:

3. One of the following is true:
a. The file is an output file.
b. If the file is a combined file, then it is an array or table file.
c. The file is an input-only file; it is not a record-address file
or processed by a record-address file; and none of the following
operations are used on the file: READE, READPE, SETGT, SETLL, and
CHAIN. (If any READE or READPE operations are used, no record blocking
will occur for the input file. If any SETGT, SETLL, or CHAIN
operations are used, no record blocking will occur unless the
BLOCK(*YES) keyword is specified for the input file.)

HTH,
Charles