Dianne is correct. Your code looks like it was built by a CASE tool. Jerry Banker
> -----Original Message----- > From: Dianne Ackerman [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 05, 2008 9:28 AM > To: [email protected] > Subject: Re: [U2] INCLUDE weirdo > > Whatever salary you're making, it's not enough! :) > -Dianne > > Dennis Bartlett wrote: > > >Currently the system uses the following coding structure: > > > >OPEN 'HPMAST.FILE' TO F1 ELSE STOP > >OPEN 'HPCONTRACT' TO F2 ELSE STOP > >OPEN 'HPTRANS.FILE' TO F3 ELSE STOP > >READ F1R FROM F1, KEY THEN... > >READ F2R FROM F2, KEY THEN... > >READ F3R FROM F3, KEY THEN... > >F1R<36,X> = F2R<13> / F3R<82> * F1R<8> + F3R<43> > > > >Just understanding the code takes a lot of backwards and forwards thru > code. > > > >This wouldn't be so bad if they had at least standardised of F1 always > being > >HPMAST, but they didn't, so the next program does this > > > >OPEN 'HPCONTRACT' TO F1 ELSE STOP > >OPEN 'HPTRANS.FILE' TO F2 ELSE STOP > >OPEN 'HPMAST.FILE' TO F3 ELSE STOP > >READ F1R FROM F1, KEY THEN... > >READ F2R FROM F2, KEY THEN... > >READ F3R FROM F3, KEY THEN... > >F1R<36,X> = F2R<13> / F3R<82> * F1R<8> + F3R<43> > > > >The formula at the bottom looks identical to the formula above but > it's a > >totally different file / field combo. Multiply this by around 1700 > programs > >and you begin to get a sense of what I face. If a program hits a file > or > >record error it simply stops with no feedback to the user that the > update is > >complete. Data integrity is an illusion. > > > >The system has been migrated from Pick, but without all the code being > >converted. As a result one has to try compile with a PICK compile, and > if > >that fails, try a universe style compile. The dictionaries for the > most part > >contain only F1, F2, F3 with the heading correct some of the time, and > >fields in use that do not appear in the dictionaries. > > > >Thus far I have started changing code to always open HPMAST to > F.HPMAST, and > >to always read HPMAST into HPMAST.R. Code takes on a whole new meaning > when > >you know what file you're working with. > > > >An additional swing is that every summary total is always calculated - > >nothing is stored. This means that every program that ever displays > ARREARS > >for example has the code to calculate arrears in it. That makes 200 > separate > >routines with the exact same code in it, just with differing file > variables > >(ie not a simple swap out). > > > >The code needs to be changed, errors need to be trapped, and > duplicated code > >weeded out but the time to rewrite complete code doesn't exist. Using > >included code allows me (the only full time programmer) to phase in > the > >changes as time permits. > > > >The idea is to phase the new code into the system as and when a > program is > >modified. Most programs create qpointers to the various (15) branches, > then > >open the the qpointed files. The method of doing this varies > considerably > >from program to program, with a bewildering array of possible file > handles - > >my plan is to create "ideal" code for opening, reading, writing files, > >stored in SNIPPETS. > > > >I have started converting the opens to a standard, eg F.HPMAST, and > read a > >standard record, eg HPMAST.R. Keys variables are set to a standard to > allow > >the use of INCLUDES. Standardises READ includes, WRITE includes all > preset > >with error trapping code. > > > >The theory behind the includes thing is that one can still produce a > full > >listing of the code to debug if required. One can change just a read > and > >write in a program without having to get involved in other files in > the > >routine (really messy but allows the process to start and proceed on a > very > >part time basis). > > > >Recompiling everything is far less tiring than trying to concentrate > and not > >leave out code whilst being moved from fire to fire, besides which > having it > >all in SNIPPETS allows me to get it right in one place and know that > >correction is being filtered into the whole system by a simple > recompile. > > > > > > > >Adrian Womack wrote: > > > > > > > >>Does anyone else think it's bad practice to have code in INCLUDES? > >>Surely it would be much better to have the INITIATE.FEEDBACK & > >>GIVE.FEEDBACK routines written as subroutines, and then simply call > them > >>from the appropriate spots. > ------- > 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/
