Re:

> Ok, I recreated the scenario and now have the following stack trace.  Can
> anyone tell me what is going on?
>
> Carl
> NM  7) SP=41858368 RP=a.00484d48 xm_w_unlock_and_copyai_var+$2b0
> NM  8) SP=418582a8 RP=a.005cd1cc disc_sm_finish_write+$98
> NM  9) SP=41858228 RP=a.005cd100 ?disc_sm_finish_write+$8
>          export stub: 29c.002f5484 putdetail_340+$3048
> NM  a) SP=41858068 RP=29c.002f7480 nmdbput+$17c4

Looks like IMAGE hasn't detached the dataset from the XM.

There's a known problem in MPE that I reported several years ago,
that the internal routine xm_detachufid_without_purge (used by IMAGE
when AUTODEFER enabled) cannot successfully detach an HFS file from
the XM.   (there was a double bug: it failed to detach,
and it reported success!)

I suggested to HP that they implement something like:
xm_detachufid_and_filename_without_purge, which IMAGE could use
instead of the original routine.  (The original routine would be
expensive to fix...passing in the filename would make it easier to
solve the problem).

I've suggested an approach to Steve Cole, who's helping Carl in
this area.

--
Stan Sieler                                          [log in to unmask]
P.s.: please forgive typos/brevity,      http://www.allegro.com/sieler/
      I'm typing left-handed for awhile.