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/
