Hi,

Re:
> NM* 0) SP=41853bc0 RP=a.004b9ea4 xm_deallocaterecord+$118
> NM  1) SP=41853b78 RP=a.00488d90 xm_unlockresource+$430
> NM  2) SP=41853ab8 RP=a.006098f4 xm_w_commitrecord+$118
> NM  3) SP=418539b8 RP=a.004bbbf4 xm_end_user_trans+$184
> NM  4) SP=418538b8 RP=a.00baed28 tm_ksm_space+$bf0
> NM  5) SP=418537f8 RP=a.00c4162c tm_ksamxl+$390
> NM  6) SP=41853478 RP=a.00eadb84 FSPACE+$5e4
> NM  7) SP=41853378 RP=a.00ead56c ?FSPACE+$8
>          export stub: 3d5.00813f64
> NM  8) SP=418530f8 RP=3d5.00776358
> NM  9) SP=41852c38 RP=3d5.00777f6c
> NM  a) SP=41852bd8 RP=3d5.0070e210
> NM  b) SP=41852808 RP=3d5.0070e024
>          export stub: bf9.000915bc
> NM  c) SP=41852708 RP=bf9.0001d374
> NM  d) SP=418524e8 RP=bf9.0001c23c
> NM  e) SP=418522c8 RP=bf9.00000000

bf9 is your program Space ID (QUERY?)
3d5 is probably XL.PUB.SYS's Space ID
a is NL.PUB.SYS's Space ID

So, we see QUERY calling something (probably DBFIND ... that's where
the second technique, RUN QUERY...;DEBUG helps, because it would allow
us to see the procedure names in QUERY)

So...FSPACE is being called (presumably by the B-Tree routines).

IIRC, that's done in only 2 routines ... one is used to position our
view of the B-Tree at the "end" (highest key value), and one is used
to find the record prior to the current record (for mode 6 DBGETs).

Still....what the heck is FSPACE doing, calling XM routines?!?!?!?!
That looks like a design flaw / bug (in KSAM) to me!

I suspect that's what was fixed, as you reported the problem doesn't
occur in later releases.

I'll look a bit more into this.

Stan
--
Stan Sieler
[log in to unmask]
www.allegro.com/sieler/wanted/index.html

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *