Re: array handling

Rich

This is not elegant code, but once upon a time I added a message to a
maintenance program to the user at end-job that provided some statistics on
the file they just maintained & suggestions for what it needed thanks to the
work they had just done ... this included REORG, tell programmer about new
size of array ... it was mainly in S/36 era where we had to make physical
size of file larger to accommodate space for growth.

I have also seen programs that allow much more space for arrays than we can
reasonably expect to need.  There might be some rule of thumb out there for
work fields being larger than needed NOW, but we have seen with Y2K that
there needs to be more rigorous planning sometimes.  I used to work at a
retail chain with fixed format lengths in pre-36 days in which all currency
fields were up to 9,999.99 & rarely was anything much more over a few hundred
dollars, then we started carrying some really expensive pianos & organs & the
software was not ready to handle them.  The first I knew of this was when a
punched card operator asked me how to enter a transaction ... I suggested
splitting it into several transactions, and went to ask boss about this ...
my solution was accepted with no conversion authorized.

Well just as fields need to be large enough to handle reasonable future
growth, so do arrays.  But we also want something to tell us as the ceiling
is approached, so it comes as no surprise.

>  (I don't recall if an array
>  allows you to order the values; will this counter the binary search?)
>
>  Load your table until it's full; note which value is the high value
>  in the table, then chain to your file for every record that won't fit
>  in the table (and send a message to the programmer in charge!).

In RPG/400 there is SORTA = Sort all contents of an array.
Now in Rich case he has a pair of entries, but I have something similar,
where a printing program (shop floor documents) needs a chart of field
contents relevant to that document & it would be nice if it was ordered, so
the print program calls the array manipulation program, passing as a
parameter the key to what's relevant, then the called program populates
compound elements with the pieces (actually more than 2 pieces) in sequence
by which to use for ordering, then when all done with population, SORTA the
whole thing with result being communicated to parent program via a shared
data structure.  In this case I did not have to sweat size of array heavily,
since limiting factor is what fits on final shop document, but because there
are more elements than can fit, some of the stuff in the array is related to
selection criteria for what should be included.

Basically it is a summarized product structure ... we are making this part
for WHERE USED & when more possibilities than fit on final report, priority
given to those that are actually in current production or MRP requirements.
The compound array includes the latter facts to help in the prioritization of
what to include in the final selection.

I give this example to explain that SORTA works very nicely thankyou, and by
using compound field within initial element design, I keep the partner fields
together.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
BPCS 405 CD Manager / Programmer @ Global Wire Technologies Incorporated
http://www.globalwiretechnologies.com = new name same quality wire
engineering company: fax # 812-424-6838