After Jim Phillips groaned:

>> This is an update to the system abort 1144 from Subsys 101
>> .....
>> "Query aborted due to a stack overflow"
>> ......
>> When I asked about being on the latest release of the O/S
>> (I *think* this machine just has plain, old 5.5 with no
>> powerpatches), the HPRC thought that might be a good
>> idea, but basically, he had no idea why this abort happened.

Gary Jackson asked:

> Was it CM Query or NM Query?

We just gained a bunch of in-house customers that were
running an old but fairly large and complex app on the LAST
MPE/V machine I know of locally (a Series 70).  What may
(or may not) be semi-associated with this thread:

The local owners of our Series 70 apps tested their software
fairly extensively on our 959 in 1999;  all appeared to be well
(and their application manager kept good notes, indicating
which sub-systems had been tested and passed on our 959).

Then now when they moved to our 959 for real, they found out
at least one of the (unchanged) CM PROGs that worked fine
in 1999 crashed with a stack UNDERFLOW....  now... what
has changed ??..  hmmm...:  well (obviously), we are now in
the post-Y2K era.  Note I have no hard evidence of any kind
that our CM problem was caused by going through the Y2K
boundary;  just that it's the only thing we know that is different.

Anyway, I note in Jim's above their QUERY abort occurred on
what he thinks is a vanilla 5.5 system.  IIRC HP sez you should
be on >= PP6 to be fully Y2K compliant on everything;  even
though a lot of stuff was "generally" Y2K compliant well prior
to that....  but also IIRC, 5.5 PP zippo is NOT Y2K compliant
in a number of respects....   NOW:

Can we therefore conclude Jim's QUERY abort is a latent Y2K
problem ??..  of course not...  but:  I ditto Gary's question:
CM or NM QUERY ??....

Also, to be sure you have NM QUERY:  Remember that
*prior* to MPE 6.0, if you do a "standard" HP update what
you automatically get as QUERY is *CM* QUERY, *not* NM:
To get NM QUERY as QUERY you need to (every update):
RENAME QUERY,QUERYCM
COPY QUERYNM,QUERY

One other thought:  Any chance your version of QUERY
somehow got wildly out of sync with the version of IMAGE ??
FWIW we are running Vers C.07.25 of TurboIMAGE (recent
but not latest);  corresponding version of QUERY is N.03.14...

STILL one more (really low odds, I expect) thought:  If by odd
chance you were booted on a staging group and then cut an
SLT *before* COMMITting that STAGE to BASE, be advised
that while you can apparently be comfortable that you got all
IMAGE Procedures in XL.PUB.SYS that were staged, the
same is NOT necessarily true of the associated TurboIMAGE
Program Files (DBSCHEMA, DBUTIL, etc. (I speak from a
somewhat extended period of fairly frustrating experience (HP
Lab has confirmed a PATCHIX / STAGEMAN problem in this
area;  don't know latest fix status off the top) ) )....

Ken Sletten