Re: NBRRCDS and BLOCK(*YES)

--
--
[ Picked text/plain from multipart/alternative ]
This is an interesting problem.  3 million records does not seem like a huge
number. I am not convinced that there is an advantage of 9 programs running
vs 1 program running, especially where there is a selection process being
done by the logicals.

If I understood you correctly and there are 6 separate ancillary files then
another choice that could be considered is UpdatePrimary on the large file
and then UpdateSecondary on each of the 6 ancillary files, with MR (Matching
Record).  This process brings each record with the same PNO to the processor
at the same time with no need for chaining.   It is a very fast process to
run, and is unbelievably easy to program once you understand it. (It is hard
to understand because so much is done automatically, and you have the
feeling that "It can't be this simple".)

 I am not sure how often you need to reorganize.  If you reorganize and
during the next period there are relatively few new records added then a
reorganize won't take long, but processing the file with a few
out-of-sequence records at the end won't take much longer either.

Another possibility that comes to mind would be to use a dataque.  Read from
the primary file only, sending a dataque record.  A work program listens to
the dataque and grabs the record and looks up the ancillary files and
processes the PNO. If the dataque gets busy, start another instance of the
work program.  Start 6 instances of the work program.  Heck, start 15
instances of the work program.  In this scenario there would be no need or
reason to read the primary file in keyed order.

---------------------------------------------------------
Booth Martin   http://www.MartinVT.com
Booth@MartinVT.com
---------------------------------------------------------

-------Original Message-------

From: rpg400-l@midrange.com
Date: Thursday, December 26, 2002 01:54:37
To: rpg400-l@midrange.com
Subject: Re: NBRRCDS and BLOCK(*YES)

thanks a lot for a detailed clarification on the file order and how
reorganize helps.

Unfortunately, I cant get rid of multi-format logical file due to various
reasons (pardon me for not providing the reasons here)
Regarding "Is there some real reason the records must be processed in Key
Sequence
instead of Arrival Sequence?" .....

Since there are too many records, in real time, the program is submitted in
batch with the complete 3+ million records broken down smaller units using
the PNO range in the select criteria in the DDS. In other words there are 9
such multi-format logical, with select criteria range being different. Each
logical if for one job being submitted so that all runs in parallel.

The update in the program is also to all formats (following the update to
first format, all other formats are getting updated) and hence keyed order
is important here (i.e) if a record in format1 with a particular PNO is
processed, then all other formats would also have the same PNO being
processed and hence being updated uniformly. The application functionality
is such that all the 6 physical files have a record (during insert) for any
given PNO. This might not happen in arrival sequence.

After reading the explanations, I am trying to find out when to do a
reorganize for all these physical files (as reorganize itself takes ample
amount of time) .... depending on when the inserts happen, so that the
reorganize can be done well in advance during batch process in parallel to
some other job to save time,
there by taking advantage of NBRRCDS.
--
[ IMSTP.gif of type image/gif deleted ]
--