It looks like Stan hit the nail square on the head.  The stand-alone detail
dataset  is a jumbo.   Records were being added to the detail using
SUPRTOOL, autodefer enabled (mode 3) through SUPRTOOL.  Analysis of the
stack trace indicated that the XM was still attached to the dataset and XM
was the cause of the semaphore blocks.  The fact that the file was not
detached from the XM was verified by analysis of the file label.  Another
test was run but this time autodefer was enabled directly through DBUTIL.
Again an analysis of the stack trace indicated that XM was still attached to
the dataset.  (THE SCARY PART FOLLOWS).  An analysis of the file label
indicated that the non-HFS portion of the dataset had autodefer enabled and
was detached from the XM as was the root file.  However, all of the
associated HFS files had autodefer disabled.
Evidently,  SUPRTOOL is smart enough to detect this issue and not operate on
a database in an inconsistent state, however DBUTIL does not provide the
same level of protection.

Steve

=================================
Steve Cole
Outer Banks Solutions, Inc.
[log in to unmask]
www.outerbankssolutions.com
Phone: 919.231.2171  Fax: 919.231.7077
Sales:   800.558.5336
=================================



----- Original Message -----
From: <[log in to unmask]>
To: <[log in to unmask]>
Sent: Tuesday, November 02, 1999 6:35 PM
Subject: Re: Performance question


> 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.