Peter Knapper wrote to Will Honea on 11-29-1999

PK> Ummm, I am not sure how you figured that one, but SQAFIXP 
PK> is not a DOS App, its an OS/2 Text mode executable. Here is 
PK> the beginning of the file -

ASS-U-ME'd it  from the MSC library reference.  That RTL dates back
a while and I have some unpleasant memories of it.  So it's a new
compile with an old compiler.  From the registers, it looks like the
crash is right about the spot that the session memory allocation is
being initialized during startup but it would take a load map to be
sure.
 
I just looked at the APAR list for fp40 and the only thing I found
that might relate is:

APAR= PJ25937
 DOSSUBALLOCMEM POOL IS CORRUPTED IF A SIGNAL IS RECEIVED
 DURING API PROCESSING.

This was fixed in fp40.  The large majority of 3175's addressed in the
Warp 3 fixpaks are related to PMMERGE.DLL hence the suggestion to try
the program in a full screen session or booted to the command line. 
I've spent the last year chasing some elusive 3175 traps in DOSCALL1
from Warp 3 - to the point of having IBM in to analyze the core dumps -
with a notable lack of success.  To date, fp 38 has been the most
reliable on the hardware we're using but 40 seems to be doing quite
well so far.  I've only had it deployed for 3 months but a lot of
nagging little nits seem to have been put to rest.  I can't comment re.
fp 39 since we skipped that one while chasing the gremlins in fp 38.
OTOH, fp 40 broke some longtime reliable WinOS2 apps for some user
groups so flip a coin...

Will Honea 
--- Maximus/2 2.02