James Trudeau writes:

>>> James Trudeau <[log in to unmask]> 05/01/97 07:15am
>>>
Howdy,
Last week we had an application fail with dreaded "Broken Chain"
message.  To keep it
short: it wasn't really a broken chain.  With a bunch of help from Adager
we found that
there were 2,305 records missing from the dataset.  Further investigation
turned up
52 blocks of hosed (technical term for set to binary zeros) records
beginning on an
even block boundry near the end of the records in the set.  The suspect
is DDX.

I'm still working with Adager and the HPRC, but we don't have much to go
on as it
was a production database and I had to repair the damage ASAP
thereby destroying
any evidence.  Anyone else had similar problems?  Adager knows of
two others but
the story is similar - evidence destroyed.

Miscellaneous details.
Media length = 92, entry length 84, block factor 44.
Records in set = approx 27,750,000, max records allowed = approx
30,000,000,
increment = 5016.
OS is 5.0 patched to 5.0.5
disc space is 12GB with 16% permanent free on a 987/100.

Can't think of anything else.  Gotta go now , I gotta ship a beer up to
those Adager guys.
-----------------------------------------------------------------------------------
We have had the same problem, it appears that under some unknown
condition, DDX will expand the internal Image numbers, but the MPE eof
does not move out.  Since Image relies on it's own internal numbers for
DBPUT to determine if writes worked, and doesn't check MPE eof,
DBPUTs merrily write to the bit bucket.  The SR for this problem is
5003-367607.  Understand however, this has occurred only once, about
5 weeks ago, and we have had DDX enabled on 3500 detail data sets
since mid 1995.

Mike Berkowitz
Guess? Inc.