I found that problem in the RESULTS or older application where most data records were dim'd to (100). The original file sizes were around 50-70 attributes and it appeared to have some room for growth. Since it was written in 1980-82, there has been some opportunity for growth.
Some of my Microdata clients truncate if the data record is 105 atts. The last 5 atts are unavailable on the READ and lost on the WRITE. Other implementations put the balance of the fields in the last dim'd element. Thus there's an offset. PRINT REC(100)<3> maybe the same as PRINT REC(103). Since each dim'd element is a variable, each element can be a whole dynamic array, char(254)'s included. This Jurrasic Pick code was popular then due to the burden of typing EXTRACT and REPLACE instead of <>. Regarding a universal approach, you may be lucky with consistently named variables. RESULTS was not that consistent and it required more manual work. Often times these new fields may not be for all the records in the data file. Thus, the creation of a new field that only a handful of records may need seems like a waste of a field. Thus my SPARE fields concept. This required the addition of a SPARE file per regular data file. Since the application runs pretty well with everything as it is, these new fields may be just for a single purpose and not application-wise. So you still have CUSTOMER and then you have CUSTOMER.SPARE. My 2 programs, SPARE01 and SPARE02 are the field defining program (01) and the data entry (02). An administrator uses SPARE01 to define the fields which includes creating the cross-file dict items. Thus you can say LIST CUSTOMER SPARE.EMAIL and it appears that the EMAIL field is part of the original data record. SPARE02 is added to each file-maintenance program to have a new screen with the maintenance of the fields as defined earlier. Pretty simple and not intended to be that sophisticated, application-wise. Also include to DELETE the SPARE record when the primary record is DELETED. Many of my clients enjoy these subs as they are constantly adding new fields, ie EMAIL, Web sites, more phone numbers, cell numbers, etc. None of these fields are required and no SPARE records are created unless that CUSTOMER needs a spare field. My 3 cents. Mark Johnson ----- Original Message ----- From: "George Gallen" <[EMAIL PROTECTED]> To: "Ardent List" <[email protected]> Sent: Thursday, May 12, 2005 10:45 AM Subject: [U2] I'm in an Array quandry, any suggestions... > I'm modifying some programs that were written about 15-20 years ago, > there must be 30 or 40 that > interact with each other. > > Here is the problem. > All the programs use dimensioned arrays, and they were dimensioned to > exactly what was needed > at the time, now I need to add 4 fields to one program. But I'm afraid > if another program reads this > newly created array, it will bomb out with an array out of bounds > error. > > What is on my side, is all the programs that reference these files, all > use the same variable name. > > My initial thought was to write a small program that will > 1. open a program > 2. search for a dimension of the suspect variable(s) > 3. increase it's dimension level > 4. write the program back out > 5. recompile the program (I don't believe any are cataloged) > > Any other ideas? > > George Gallen > Senior Programmer/Analyst > Accounting/Data Division > [EMAIL PROTECTED] > ph:856.848.1000 Ext 220 > > SLACK Incorporated - An innovative information, education and management > company > http://www.slackinc.com > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
