We are currently on uv 10.2.4 and AIX 5.3.0.0
We are about to bring the os up to 5.3.7.1
The following was pasted from the matrix:
UV AIX
10.2.4 5.3
5.2
5.1
does this mean that AIX 5.3.x.y would all be good for 10.2.4 ?
Thanks,
Schalk
> 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/
