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
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.