Future Proof File Designs/Methods

Pickering, John (NORBORD) PICKERIJ@norbord.com
Wed, 16 Jun 1999 15:40:43 -0400


Given the environment ...
>Powerhouse 7.29
>HP Image

In spite of your concern about the complexity, I firmly believe that any
system should have a "compile everything" job stream. Probably 2 jobs, one
for Qdesign and another for Qtp and Quiz. This may actually be the single
most important "future-proofing" tool!

With new "even more y2k compliant" versions of PH being delivered regularly,
a "compile everything" job makes installation simple. With an Image
maintenance tool (e.g. Adager, DBGeneral), database changes are easily
accomplished and then the system can be easily recompiled. This frees one
from the lousy design decisions made because "it's too hard to change the
database" or "it's too hard to recompile the system". The dataset with the
filler is never the one which needs the new items:-)

If faced with maintenance of a system without such jobs I will bite the
bullet and create them. This may entail some housekeeping such as program
and subfile renaming so that a sorted list of the programs will be in a
compileable sequence. This also means that the PH component to be used to
compile the source file must be determined from the file name (not always
obvious in HP 3000 shops). The job should derive the program list itself
(i.e. from a LISTF on MPE, from whatever passes for a directory list on
other OS's) rather than relying on lazy programmers to keep a manual list up
to date.

My Qdesign job purges all existing compiled screens (great for cleaning up
the junk) and then compiles all of the screens in the production source
group. My Qtp and Quiz job purges all the compiled runs and reports and then
compiles all the Qtp and Quiz in the production source group. Since this
runs in batch and usually after hours I don't care too much about machine
abuse so I run a fresh Qtp or Quiz for each source file. This saves me from
the nasty problem of inheritance of "set" values between runs and reports.

And permanent subfiles are a lousy idea too!

/rant :-)

John Pickering
JWP Systems Inc.
Toronto


= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.