Richard B. Brightwell" <[log in to unmask]> said:
>"Spivey, John" <[log in to unmask]> wrote:
>
>>We have a very large (8.8 million entries) detail dataset with two
image
>>keys (1 manual, 1 auto) and two Superdex keys and DDX. Recently, it
was
>>given the Image/SQL treatment and approx. 1.3 million entries were
>>removed from it. A couple of days later, broken chain errors began to
>>spring up. Adager noticed that the EOF in Image was different than the
>>EOF as seen from a LISTF. We are currently in the process of repairing
>>this database and were wondering if anyone out there has had a similar
>>problem. Adager thinks that a DET PACK or some such similar operation
>>was aborted, but we don't like to touch this dataset because of its
size
>>unless absolutely necessary.
>
>>John Spivey
>>Sumitomo Electric Lightwave
>><[log in to unmask]>
>>919-541-8390
>
>The guys at Adager are stone-cold *experts* when it comes to Image
>data bases. I'd belive what they told me.
>
>Richard B. Brightwell
>Sr. Systems Software Engineer
>HBO & Company
Thank you. We certainly do our best (and spend many sleepless nights and
weekends in the pursuit of excellence). For everyone's peace of mind,
Sumitomo is up. Sumitomo's crack support team was able to go back into
production at at 4:00am on Monday. Kathy and John certainly deserve
praise
for their quick and intelligent treatment of the potentially devastating
challenge they faced.
Adager, due to my paranoid ways, is usually the messenger that brings bad
news out into the open. I have written a ridiculous amount of "if"
statements that check "useless" cross references and redundancies. So,
one
of these paranoid "if" statements generally finds out trouble spots that
look "ok" to normal, decent, non-paranoid systems that just go about
minding their own business. I'm sorry to report that this is only
getting
"worse" (if you don't like the messenger to tell you bad news), because,
as
we discuss this, I'm heavily involved in water-proofing, even more, the
whole DDX subsystem in Adager. Naturally, if you PREFER to hear bad news
as soon as possible so you can do something about potential problems
ASAP,
then you may think of this as getting "better". I cannot please
everyone,
so there you have it, straight from the horse's mouth.
We are keeping track of this issue at Sumitomo and are researching all
the
possible angles with the engineers at Hewlett-Packard's Response Centers.
There are so many variables and parameters involved, including DDX,
SuperDex, DBPUT, DBDELETE, Adager, IMAGE in general, MPE, and so on.
For everyone's information, the good people at Sumitomo are the ones who
discovered, a few moons ago, the fundamental problem in the
operating-system service called by DBPUT (when DDX required so) to expand
a
dataset automatically. As soon as it became obvious that Sumitomo was
not
crying "wolf," everyone immediately went to work on the challenge and, as
soon as the reason for the problem was found, HP spent a sleepless
weekend
fixing it.
So, whenever Sumitomo speaks, we all listen. Stay tuned...
+---------------+
| |
| r | Alfredo [log in to unmask]
| e | http://www.adager.com
| g | F. Alfredo Rego Tel 208 726-9100
| a | Manager, Theoretical Group Fax 208 726-2822
| d | Adager Corporation
| A | Sun Valley, Idaho 83353-3000 U.S.A.
| |
+---------------+
Just to clear a couple of things up about the problems we here at
Sumitomo had last year regarding the DDX expansion problem. True, it was
HP that fixed the bug in their code, but hats truly go off to Denys B.
who spent the time to write us a program that fixed the huge, gaping
black hole in our data and got our production lines running again, and to
Ken and Rene at Adager who sat with me for hours over the phone
diagnosing the problem through the night. It was a bad time and all
those guys really made it go a lot easier.
Kathy Parker
Sumitomo
[log in to unmask]
|
