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/
