Stan,

Our testing confirms what you say below.  We ran the same job stream against
a non-jumbo data set and all the references to XM in the stack traces
disappeared.  Our through put also increased.

I have an open call with HP and will see if there is a fix or work around.
As soon as I know something I will pass it on.

Carl

> -----Original Message-----
> From: [log in to unmask] [mailto:[log in to unmask]]
> Sent: Tuesday, November 02, 1999 5:36 PM
> To: [log in to unmask]
> Cc: [log in to unmask]
> Subject: Re: [HP3000-L] 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.
>