At 12/3/98 10:01 AM , Therm-O-Link wrote:
>Stan Sieler writes:
>
>>Thank you. My point exactly. As I learned from Steve Cooper in 1978,
>>before I even started using MPE!, an application should *ALWAYS* check
>>that the database looks the way it expects it to look.
>>
>>BTW, that's not merely "because DBINFO does not find the item"...it's
>>also true if the item type or size changed.
>
>I have worked on several different computers using both hierarchal and
>relational data bases. I have seen literally thousands of programs
>(written by myself, my co-workers, and third-party vendors) that use
>those data bases. I have never seen one program that kept track of
>what the data base should look like and then compared it to the current
>data base to see if there was anything amiss.
>
>While I'm sure it is the 100% correct way of doing things, I imagine
>the overhead involved, both in terms of program complexity and maintenance,
>
>would be very daunting.
>
>Jim Phillips Manager of Information Systems
>E-Mail: [log in to unmask] Therm-O-Link, Inc.
>Phone: (330) 527-2124 P. O. Box 285
> Fax: (330) 527-2123 Garrettsville, Ohio 44231
We don't use DBINFO to check that the database is as the program expects,
but we do perform a version check.
Each of the databases has a stand-alone detail (limit of one record) named
CONF-DATA which contains configuration data (including the schema version
used to create the database). The COBOL people have version constants in
their copy libraries which correspond to the schema version. Those of us
SPL/SPLash! types have defines with values that correspond to the schema
version.
The first thing each program does check the version it has in its code
against the version value in the CONF-DATA dataset. If they don't match,
the program QUITs.
It is not a perfect system, but it is very useful in finding those programs
which no-one thought would be affected, and those programs which were not
updated because they "are obsolete and not used anymore" (and which of
course are still being used once a month by someone).
It has another advantage. Okay, you archived your database 3 years ago.
Now you need to run some report against that old data. Now you need to
find the programs (they are in the archive, right?) that match THAT
particular version of the database. It isn't that hard to do if you have
some way of displaying what database version the program is looking for.
Back in the good old days we used a secondary entry point "VERSION" which
displayed information like the program name, program version, library
version, database schema version, etc. When there was some doubt as to
whether the correct program had been RESTOREd from tape, the schema version
information displayed by running the program at the secondary entry point
eliminated any doubt.
The only problem we have had with this system was caused by a DBA failing
to follow policy. The policy was that whenever structural changes were
being made to the database, the security on the group containing the
database (normally set to ANY) would be set to GU (Group Users), as none of
the interactive end users and none of the production batch jobs log on with
capabilities sufficient to gain access to the database when the database
group is set to GU access. Needless to say, one time the DBA forgot to
change the security to GU, and just after the database structure had been
changed, but before the CONF-DATA record had been updated to reflect the
new schema version, the job scheduler kicked off a production job that
accessed the database. That happened several years ago, and there have
been no repeat incidents.
Oh, and by the way, people ARE converting their old archive tapes to newer
tape formats, aren't they? If not, just how do you expect to read those 9
track 1600 CPI tapes on your year-old 9xx box?
John
--------------------------------------------------------------
John Korb email: [log in to unmask]
Innovative Software Solutions, Inc.
The thoughts, comments, and opinions expressed herein are mine
and do not reflect those of my employer(s), or anyone else.
|
