Greetings
 
earlier I wrote:
> I get a strange error when trying to access a TI database.
<...>
> <suprtool output>
<...>
> Error:  An IMAGE call failed while trying to describe sets
>
> TURBOIMAGE ERROR AT $00195898; RETURN STATUS = -1
> DBINFO, MODE 202, ON #1 OF MYDB.PUB.KEM
> MPE FILE ERROR 52 RETURNED BY FOPEN ON DATA SET #1
<...>
> <QUERY output>
<...>
> SET NAME:
> FOPEN FAILURE 1 52
 
Thanks for all input and advice. For those interested, here is a short
explanation (for those not, please excuse the waste of bandwidth):
 
At our site-
-every day old entries from PRODDB is moved to DBOLD
-every month a job
 1)MPEX:renames DBOLD@ to DBO@
 2)MPEXstores DBO@(CODE=PRIV) to tape
 3)MPEXrename DBO@(CODE=PRIV) to DBOLD@
 4)verify tape
 5)DBUTIL >erase DBOLD
(I didn't design this ;-})
The renames, I'm told, are there to minimize work (no name conflicts
with "current" DBOLD) when old DBOLDs has to be restored and/or
modified.
The problem occured when someone restored an old DBO and forgot to purge
it before the monthly job started. So, the MPEXrename failed (file
exists), the store worked (i.e. both "current" DBOLD and the old DBO was
stored), the second MPEXrename failed (since the first failed), tape
verified OK (there was a DBO), so DBUTIL> erase worked (hepp!).
Fortunately, since the storeset included both DBs, no harm was done (I
figured). But on restoring DBOLD I found the errors discribed earlier.
 
Apparently IMAGE rootfiles includes the filenames of the sets, and one
of the failed MPEXrenames was successful in updating the rootfile but
not in renaming the DB. It all went away after a few extra
MPEXrenames.(!)
I'm sure something can be learned from this :-). I learned that Image
rootfiles contain some important information (hmm) and that maybe I
should take a serious check on some of our jobs.
Sorry for the ranting and thanks again for the help
/per