Re:
> If we do a FIND in Query on the Automatic Master for that X12 with certain
> Keys (that do NOT exist in the dataset), it takes several minutes to
> complete. It should take milliseconds. Ok... That's wierd.

Let's see what's actually going on here!

First, determine the PIN of your QUERY process:

   <break>
   :SHOWPROC

Lets's assume it's PIN 123.

Then, from another terminal, logged on as MANAGER.SYS:

   :debug
   pin #123; tr, i, d
   c

(don't forget the "#" character!)

Post/email the result and we'll look at it!

Another variation is to do the following (from your
MANAGER.SYS logon):

   :run query.pub.sys; debug
   pin #123; tr, i, d
now, enter RESUME at the original terminal, and then
scoot back to the MANAGER.SYS terminal (still in Debug) and
re-enter:
   pin #123; tr, i, d
several times.  The exit debug:

   c
and then
   exit (to exit QUERY)

BTW, this should have nothing to do with "empty" nodes in a B-Tree.
NM KSAM, as you would expect of any B-Tree system, doesn't allocate storage
nodes for every possible record slot when you create the file!

> This seems to have been fixed in MPE 7.0 but in 6.0 and 6.5 it seems to be a
> problem.

The stack traces (from the "tr" command above) should shed some light
on the cause of the problem.  If we see that the code is dwelling within
KSAM code most of the time, then that would imply a problem with KSAM.
As Rene pointed out, the Communicator doesn't generally carry bug fix notices.

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 *