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