If you use Dynamic Detail Dataset Expansion (DDX), you may lose some detail
entries (fortunately, the probability is VERY LOW and the circumstances
involve a very tiny and subtle multiprocessing timing window; but this is a
serious problem if you run into it). Fortunately, during more than three
years of heavy worldwide DDX use, only a handful of IMAGE users have
triggered this elusive bug. This speaks very highly of HP's implementation
of the DDX algorithm.
How do you find out whether you are using DDX or not? Use this DBUTIL
command:
>SHOW DBNAME CAPACITY
The rightmost column ("Dyn Exp") says "YES" or "NO". If you get an
"invalid parameter" message, you are in a pre-DDX IMAGE version.
---
Jon Bale, Hewlett-Packard CSY's Database Lab Manager, posted a thorough
message to comp.sys.hp.mpe (a.k.a. HP3000-L). Jon wrote that, if several
circumstances line up just right (or wrong, in this case):
... some data which is subsequently written to the data set is
placed "beyond" the end-of-file (EOF), and once the database is
closed and reopened, that data is inaccessible. If a program
attempts to read that data or add more data entries in the same
area, it gets an error -212, "Database is Corrupt."
The Service Request documenting this is SR #5003-367607.
...If you have and use one of the IMAGE/SQL structure maintenance
tools provided by HP or an independent vendor, that tool may also
have the capability to locate instances of this problem. If you
discover that one of your data sets is so afflicted, it may be
possible to correct the problem using the same tool.
---
HP has worked very hard in developing the appropriate patch(es), which you
should obtain from the HP Response Center and install as soon as possible
(refer to HP SR #5003-367607).
Meanwhile, if you have been using DDX and wish to determine the state of
your DDX-enabled datasets, Adager can certainly help you. We automatically
detect and correct various DDX problems that we have incorporated into our
verification algorithms during our last three years of full DDX support.
This includes EndOfFile (EOF) discrepancies as well as other, more subtle
problems (such as HighWaterMark inconsistencies, FreeEntry Count errors,
etc.)
During its pre-process consistency check, Adager analyzes all database
structures and reports the anomalies it finds. One of the
many tests that Adager makes is to determine whether the physical
characteristics of a dataset file are consistent with its root-file
specifications.
An anomaly like the DDX problem gets reported every time Adager opens any
database for which you have READ access (in other words, you don't even
have to be the database's creator and OTHER processes may be accessing the
database while you carry out this Adager checking).
If (and when) you receive an Adager message regarding a discrepancy, *you
may or may not* have lost any data, depending on several circumstances.
You may want to contact us and we can log on or direct you through the
necessary steps to determine the extent of the problem (if any).
_____________________________________________________________________
If Adager reports a discrepancy AND other users are accessing the database,
please DO NOT get them out of the database. Contact Adager immediately and
we will be delighted to guide you so that you can "gingerly" get all of your
users out of the database, hopefully without losing any data, if you catch
the problem in time.
_____________________________________________________________________
After detecting the problem, Adager lets you use its therapy mode to
adjust the relevant privileged database parameters (if you are running
Adager in session -- in exclusive update mode -- and as the database's
creator).
After correcting the problem, Adager's therapy functions can further assist
you in determining how much information was lost (if any) and the
identifying characteristics of such lost information.
Adager can also help you modify your DDX parameters to minimize the
probability of running into the DDX problem.
---
Adager's methodology has been field-proven for many years. Our software
and our specialists have helped many Adager (and non-Adager) users recover
their databases from all kinds of problems, ranging from hardware failures
to operator errors.
If you are not an Adager user and wish to diagnose your databases to
determine whether they have this DDX problem, we will be pleased to send
you -- free of charge and via overnight courier -- a short-lived production
version of Adager that you can use, with our compliments, to EXAMINE all of
your databases and, if necessary, to FIX your DDX problems.
As is our custom, there are no strings attached.
+---------------+
| |
| r | Ken [log in to unmask]
| e | http://www.adager.com
| g | Ken Paul Tel 208 726-9100
| a | Customer Support Fax 208 726-2822
| d | Adager Corporation
| A | Sun Valley, Idaho 83353-3000 U.S.A.
| |
+---------------+
|
