Expansion Memory Fault help please?

[Mike Luther]

Thanks Tom.

I'm the injured bystander here. If what you say is true, than
IBM is the one who needs the interface information and statement
from you that attempts to place the ball in their court. You
might note that the issue of DOS and such is a shared technology
issue between they and Microsoft, yet, as I understand it.

Thus what I need is all of the things I will have to have to see,
if quietly, without fan-fare, I can get it in front of a few key
people at IBM to FIX the problem, if it is in their house.

Having been through a couple rounds of this for real, where the
vendor is at arm's length in these sort of issues, what will likely
happen is that they will ask me, for example, for the applicable
DUMP failure I have here, plus your statement given here. I have no
idea if I can raise enough attention to get the issue examined. If I
were the program source, that's a different story; I'm not.

The key issue is simple. If IBM *IS* at fault with the issue and
their code is genuinely broken, as you claim, in respect to EMM, then
they, I think, will want to fix it. And .. contrary to what you
offer, the issue is not one of M/S compliance at all, in that, in this
case they have to think about that as well, even for WIN 3.1. In the
case of WIN 3.1, even it is compliant to the standard and Y2K certified
from IBM. It has to be, to the extent that everything else like it
can be. They have to stand on the heritage compliance for certain
issues even if others do not, so said to me. As I gather all this,
they have to even if MS thinks they do not or does not.

I'll see if anyone will look at it. No guarantees. I'm just the
mule who is being bashed by the runnaway plow.

Again, I'm *NOT* claiming anything is wrong with PB. I only want to
quit getting rammed from behind with the Go-Devil!




------------------
Mike Luther
[email protected]

[Tom Hanlin]

Mike, you simply need a working EMS implementation. Technically,
it's the LIMM/EMS 4.0 specification but, that doesn't really tell
you anything useful. To find a different spec, you'd have to dig
up an old 8088 PC using an early EMS add-on card. The problem is
not with the spec, it's with buggy EMS implementations. This can
readily be fixed if you're using MS-DOS or Windows. I gather such
is not the case with OS/2.

------------------
Tom Hanlin
PowerBASIC Staff

[Mike Luther]

Lance ..

Again, I am not at all either being critical of PB or saying anything
about fault. I a seriously trying to get something on the table in
the open so that people FAR more capable than I am can help get a
PowerBASIC problem solved.

The following is part of the on-going dialog with NORMAN which illustrates
exactly why PB really needs to cooperate with public postings about
what it defines as a standard for the tools it uses and now, more
than ever, may have to cooperate with other systems, even in DOS environments.

Subject: Re: Second SYS3175 error on
To: Mike Luther <[email protected]>
From: [email protected]
Date: Mon, 28 Oct 2002 10:53:16 -0500


I don't think I ever got this feedback to you:

Thanx for the info and process dump, analyzing the dump now...
In the mean time, try to add OS2.INI and OS2SYS.INI to the exclude list in
"Common settings->Exclude" in the configuration editor. That will verify if
flushing the INI files are the cause of the problem. Also it may be a good
idea to exclude the output path for the powerbasic compiler. What may be
causing the problem here is that powerbasic gets confused when trying to
open a temporary file that is still locked by NVC for scanning.

Regards,
Matt Allen
Technical Support
Norman Data Defense Systems, Inc.
[email protected]
(703) 279-6654

Neither you, I, Bob, or anyone in your extremely capable entourage
in any way created the need for any ability to have to check every
single file that is written or used in a system during DOS. And,
in humor, it can also, frankly, be a problem in OS/2 as well, but
at the moment isn't, so lets not get into bashing anything. Nobody
cares about OS/2 and the worth of creating the mess in it, perhaps,
whatever, but the issue *IS* possible and those of us who use it
can't affort to pass on the problems to other souls who may be affected
by playing Ostrich and sticking our heads in the sand.

I'm posting the above quote because it is a very logical and thoughtful
suggestion by a thoroughly reputable organization on why PowerBASIC's
product may be failing in today's environments. Just the above may
be what is needed for some serious thought, both internally for the
crew, as well as externally for many others here. OS/2 isn't the
only environment under which the above scenario may be critical. Your
PB 3.5 product is, I think, used by others in DOS sessions even in the
WIN environment, no? Or at least from the postings, folks are sure trying
to do that!

Now... please.

Will you kindly post EXACTLY what the design and EMS or upper memory
requirements for LIM SPEC and so on memory are here for the PB 3.5
compiler product? I don't promise anything. But if I CAN get someone
to look at the DUMP that DOES have the training to see where the error
is that comes up SYS3170, it may either get PB the needed help to
correct the problem. or may equally, get IBM to fix its error in how
they implement LIM SPEC memory. It sure isn't MY error.

And ..

You've got yet another poster in a brand new thread asking for help with
the EMM issues in relation to DRDos... just today, if I read it right.
Defining the standard in public so that we can take the issue forward to
people who HAVE the tools to point to the possible problems is critical.

The important suggestion in the quote above that may help lots of
folks would never have happened, at least from my end, unless I had
uncovered it from the DUMP and data which was offered to you folks,
but which you note PB has no ability to use.

Thanks.



------------------
Mike Luther
[email protected]

[Lance Edmonds]

Mike, I've suggested a way forward for you, but if you want additional information or want to approach this another way, then you will need to contact Bob Zale directly to discuss this matter.

Thanks!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Mike Luther]

Lance ..

The problem that is faced here is that unless you encounter the same error when compiling on a Microsoft-based
PC, then we can conclude that there a difference in how IBM have implemented EMS support with how the
various other EMS memory managers handle it (and where PB/DOS compiles just fine for thousands of other
customer!).

Or to put it another way: if PB.EXE compiles the code with other brands of EMS managers, but not under IBM's
implementation, the problem is clearly with the IBM implementation.

I'm not interested in fussing over opinions. I'm interested in trying to solve a
problem with an application I need which fails in an environment in which I need
it, and as well, in one which my yet have far more significance than many may
suppose. That's for the future to decide and far beyond my control, your control,
or whatever.

Now, in order to take this forward, if it can be done, I need something. I need for
you to post very explicitly, exactly what LIM SPEC standard you folks base the PB 3.5
product upon.

Please post that here ...

It very well may be an IBM fault. However until the exact ground rules are known here
it isn't fair to anyone to say anything about fault. I may well be able to get it
corrected at IBM if what you say is true. What is, I think, over a million and a half
still registered IBM PC-DOS 7 users can't be all that bad, no? If it is an IBM fault,
I think they obviously will want to fix such a serious flaw.

BTW ... I think it may be possible to get you a sample Bootable CD-ROM version of eCs's
brand new Version 1.1 overlay template for the latest OS/2 4.52 MCP2 product for use. Not
only that but you can, as well, with it, as far as I know, run a complete totally current
OS/2 operation as a pure disk image under WIN XP or WIN 2000 or whatever, from CONNECTIX.
If what I think is correct, is provided by CONNECTIX as well. That, or install WIN XP, or
any flavor of WIN directly under the C2 sercurable OS/2 if you like as a guest operating
system. No, the eCs ain't C2, but the sample has the INNOTEK interface in at, I think.
At WarpStock, 2002, in Austin October 5-6th last, I *THINK* I heard correctly, that eCs,
was intending to release a total of just under a million and a half such sampler disks as
part of a mass marketing issue in Europe at some time in the near future, but we need to
check with them as to that correct number.

Cross platform operational capability between systems may well turn out to be far more
important in the somewhat near future for folks than some may want to think about ...
both ways .... huge


Thanks..


------------------
Mike Luther
[email protected]

[Lance Edmonds]

Thank you for your kind offer of the dump file, but since we do not support OS/2 nor have any machines here that run it, it will serve no useful purpose.

The differences in your results between compilation with PBC.EXE and PB.EXE can easily be explained: PBC.EXE will have much more conventional memory available than PB.EXE so less demands will be made on the EMS manager, and hence the problem is just not being hit. If you reduce the amount of free conventional memory available to match PB.EXE's allocation, you stand a good chance of having your EMS exception appear there too.

The problem that is faced here is that unless you encounter the same error when compiling on a Microsoft-based PC, then we can conclude that there a difference in how IBM have implemented EMS support with how the various other EMS memory managers handle it (and where PB/DOS compiles just fine for thousands of other customer!).

Or to put it another way: if PB.EXE compiles the code with other brands of EMS managers, but not under IBM's implementation, the problem is clearly with the IBM implementation.

The only way I can see to move forward on this problem is for you to compile on a non-OS/2 PC and compare the results. Sorry! I can;t see any other way to evaluate the problem without that crucial comparison.

Sorry!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Mike Luther]

Lance ..

Actually, I don't recall a single report of a compile-time EMS error ever
coming through. You could report the problem to IBM and see if they can
fix the problem in their O/S2 EMS manager. (Do they still support O/S2?
Is it more than 7 years old now?)

Compile time error straight out of the PB 3.5 IDE Lance. If you have never
had a report of fatal errors during compile time for PB 3.5 for DOS, have
a look at your first. I have hundreds like it over time. This one is
is for the PB 3.5 IDE with the following fully successfully compiled
executable with PBC, not the PB 3.5 IDE and with the same settings
for options for both, thank you.

PRBILL EXE 425087 10-23-02 3:11a 26319 lines - Profnl case biller

From:

PRBILL BAS 198016 10-23-02 3:09a *ZIPLOG Profnl billing

Which compiles perfectly with with the use of the PBC, no problems.

PowerBASIC Compiler Version 3.50 Copyright (c) 1989-1999 by Robert S. Zale
PowerBASIC Inc. * Carmel, CA, USA
C:\ZLOG\PRBILL.BAS
23373 statements, 26319 lines
Compile time: 00:07.3 Compilation speed: 216000 lines/minute
295744 bytes code, 19056 bytes data, 4096 bytes stack
Segments(9): 43k/36k/49k/27k/18k/58k/15k/13k/34k

The IDE trashes the exact same system session window.

Here's the precise flaw for your reference, PowerBASIC's code failure
and none of IBM's problem at all:

------------------------------------------------------------

10-23-2002 06:32:40 SYS3170 PID 02ec TID 0001 Slot 0077
C:\OS2\PMSHELL.EXE
10f620dc
e11cfee7
EAX=00000000 EBX=00000241 ECX=0000a504 EDX=00000000
ESI=0000fffe EDI=00000002
DS=6d85 DSACC=**** DSLIM=********
ES=8464 ESACC=**** ESLIM=********
FS=0000 FSACC=**** FSLIM=********
GS=0000 GSACC=**** GSLIM=********
CS:EIP=0000:00000006 CSACC=**** CSLIM=********
SS:ESP=6d85:000012ea SSACC=**** SSLIM=********
EBP=0000130e FLG=000a2286

IBM is VERY specific about who is responsible for these errors. Officially,
SYS3170; the exact text for the error is precisely:

C:\ZLOG>help sys3170

SYS3170: A program in this session encountered a problem and
cannot continue.

EXPLANATION: The process was ended because the program generated
an unhandled fatal user (non-system) exception through DosRaiseException.

ACTION: If you purchased this program, contact the supplier of the
program. If you are the developer of this program, refer to the

What this means is that the PowerBASIC PB 3.5 IDE, not my code and
absolutely *NOT* the IBM operating system, generated an unhandled
fatal user (non-system) exception through DosRaiseException. It's
PowerBASIC's problem totally, not IBM's. You folks are the developer
of the program, my supplier. So at least IBM says in writing, Lance.

Specifically, the following can be used with STARTUP.CMD in OS/2 to
assist you in finding such an error. It is a utility tool that can be
run in the OS/2 CONFIG.SYS file to help a developer like you trace
the problems:

PROCDUMP SET /PROC:PB.EXE
PROCDUMP ON /L:d:\logit

A -related- PDUMP.000 for this error for the crew to see where this
problem is in the PB IDE code is on hand here for that precise error,
Lance, all ready for you folks. It is, in raw form, some 4.8MB of code
for you to work from.

Directory of D:\*******

. <DIR> 10-22-02 1:29p
.. <DIR> 10-22-02 1:29p
PDUMP 000 4862164 10-23-02 6:32a

In archived form it is:

PDUMP000 ZIP 1608741 10-23-02 3:20p

For the needed added use of what your PB 3.5 IDE is using for system
resources, IBM's THESEUS notes of a typical session like this with the
PB IDE and the source loaded for compile shows as follows:

General Information about the Process with PID = 00A7, name = 'VDM':
PTDA address = FEE36C20

Threads for this Process:
---- priority ----
TID Th_# TCB TSD class level actual state
0001 0078 FA20FC98 F9877000 02 00 0200 0001 Ready

Exit List:
(none)

Open Files (MaxFH=88):
---- handles ---
Process System Flags File name // Flags...
0000 014B 00 C:\TEMP\BOUT2.TRN //

This process type does not have an environment.
< End of THESEUS4 (v 4.000.00) output @ 1:04:47 on 10-24-2002 >

That BOUT2.TRN issue is the resident Btrieve engine and the Tenberry
Rational 4G tool, with the required Btrieve PMSWITCH code that I
must have to run the application. Without it I could have some
740K of useable memory. Sadly, all I have useful is about 684K
free of lower memory for this use, Lance.

Together with the PROCDump, there should be enough information for
PB to figure out where they may have it wrong as to the reason
for the DosRaiseException error, Lance. With respect to your thought
that:

(Do they still support O/S2? Is it more than 7 years old now?)

Answer is, absolutely YES. You can officially ask IBM for help for
this problem, fully operationally, through December 31, 2004, officially.
That includes any conflict you may have in the PB code with anything
which results in what IBM says is 'your' problem. That includes all
the device drivers, the entire operating system, wherever that error
may be. I'm using NOTHING that isn't official IBM or fully known and
stable compatible tools with it, with one exception.

I have instability problems which have suddenly shown up with NORMAN
5.42's on-line virus protection operation. Their product is also
involved in an open case with them at this time, including any collateral
issues that they might find in relation to your crew's product issues
here. They *DO* have the complete OS/2 interface and programming
support to use the tools. You can bet I will forward anything that
they find to you if they do uncover anything, Lance.


Specifially, for IBM. As far as I know, IBM will be glad to open up a
problem report for you folks. If your contention is that it is IBM's
problem, sure, that may turn out to be true. It isn't that you don't
'support' OS/2 Lance. You don't, in fact, have a product that is
supported for native OS/2. That's sad, in my opinion, but ..

What is important is that the SAME issues we are facing will hold also,
as far as I know for IBM's PC-DOS 7, which is pure native DOS. Not only
is it pure DOS, but it is Y2K certified DOS and it is support, per
what I think correct, way out beyond 2008 now. To my belief, the
entire US Federal Reserve System and all the money in the whole USA
Federal banking system, between it and OS/2's operation, is totally
dependent on the PC-DOS and OS/2 version of it Lance. Officially,
it was noted in the trade rags, that the entire attempt to move it
to WIN was totally abandoned last year over security and other issues
that simply make it still totally unreplaceable... for starters. Lance.

Thus, as far as I know, if it *IS* a problem with IBM's code, they'll fix
it for free. As far as I know, and I think it correct, you can check
my view, there will be *NO* problem getting it into the OS/2 and PC-DOS
7 user's hands with no questions asked through December 31, 2004. Not
officially, but from company sources, 2006 and even 2008 are likely
realistic useful dates for this kind of thinking, Lance.

Not only that, but the PB code so cleaned up, or the IBM code so cleaned
up, whichever, or both, will solidly be in your support portfolio for
everything you could do in this regard with the PB compiler all the way
from hardware from about 1986 through all of 2004; for sure; case closed.

That's real service, in my humble opinion, Lance.

OTOH, if it is YOUR problem as to PB's issue on the DosRaiseException
error, they may want payment for helping the crew. I sorta personally
doubt they would ask for that from y'all. Yes, PB is a very seriously
important and VERY respectable operation. To my knowledge IBM has done
lot of help without getting paid for a lot of people. They've even helped
little Mikey dog several times and it's gone both ways as to who has been
at fault. They are terribly sincere about taking care of things where
economic damage is at issue, Lance.

Do you folks want the PROCDump for this error? I'll be happy to
furnish it for your help. And/or IBM if you wish to try to open up
a PMR request?




------------------
Mike Luther
[email protected]

[Lance Edmonds]

Sorry Mike, the specs beyond the fact that the IDE can use up to 4Mb of EMS during compilation are not available. we use EMS memory in a manner that compiles with the LIM EMS spec though.

Actually, I don't recall a single report of a compile-time EMS error ever coming through. You could report the problem to IBM and see if they can fix the problem in their O/S2 EMS manager. (Do they still support O/S2? Is it more than 7 years old now?)

In any case, the problem you are facing is that PowerBASIC does not support O/S2, nor can we help configure O/S2 EMS memory options... we'e never used or configured O/S2. Therefore, your best way forward would be to use a plain MS-DOS or Windows machine to compile on (and maybe transfer the compiled files across the network to the O/S2 machine for testing if need be).



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Mike Luther]

Mell ..

I've tried your suggestion with both a WIN-95 and WIN-98 box. There
isn't enough available memory for the Tenberry manager/Btrieve operation
needed during development and all the other time slicing and other support
needed for me on either one to even get close to the ability to even
compile or develop any of the larger programs at all. None of the suite
even would have been possible, for a long time now, except under OS/2 or ...
perhaps QEMM under pure DOS as far as development issues. And that wouldn't
solve the problem of multiple DOS sessions in pre-emptive mode that I
need for the project at all.

Except for the horrible performance deterioration in any form of WIN-95
and WIN-98 operations with multiple instances of PB executables in the
same box in separate sessions at the same time and worse for networked
stuff, the executables WILLl run fine on the WIN-95 and WIN-98 stuff.
There appears to be no problem in available memory or the memory managers
for that.

Besides .. according to what's been handed to me by clients, Federal
law here in the USA requires that I be able to support and completely
access and run all of the suite for seven years from the last date I
deliver any of it for what I've furnished.

The likelihood of being able to comply with that is virtually nil, as
I see it, in any onward march into the WIN world. I pity PB with the
task of trying to make the product line move forward for support into
the current offerings of the WIN world and yet backwards to what I expect
is a substantial number of sincere embedded system and dedicated sustems
users for the tool set.

I don't deny that there are tools which would let me move off this
to the WIN world that are readily available from PB and are excellent
tools. However they don't provide the forward and backward compatibility
that will be required.

What I would like is whatever techical requirements are really needed to
analyze the problems I see every now and then in this upper memory issue.
Technical support data like Quarterdeck provided with QEMM. I don't
claim to be really swift at any of this, only want the things that might
help me to learn and seek answers..

I can furnish complete PROCDUMP SYS error level trace data for whatever
is needed for the errors, but that isn't going to get anywhere without
the same sort of platform used here. Just such a dump for the last
two SYS3170 errors in session foldup at this is over 6MB each. I can
also furnish the entire THESEUS complete session and memory analysis of
each of these if needed. And, if needed, I can even furnish the complete
complete DUMP for the entire system at about 60MB of DUMP data as
needed. But that's totally beyond the reasonable ability of the crew
to handle any of that.

What I really need is the design specs for what this thing expects to
see from an EMS operation, if possible. What is the standard and where
should I look to see what really is happening, if I can learn to use
the tools that are here from IBM to help me.




------------------
Mike Luther
[email protected]

[Mel Bishop]

I am assuming you are having compile problems with IBM's OS/2
instead of windows. As I understand the situation, PB/DOS is
geared towards the windows flavor of O/S's. OS/2's
extended/expanded memory manager may be "not up to the task" of
dealing with PB/DOS.

If the above assumptionis correct, try switching to a windows
machine and see what shakes loose.


------------------

[Mike Luther]

Will someone please lay out a reasonable discussion of how the Expansion
Memory Fault error arises in PB 3.5?

Because of the size of the programs and the issues with OS/2 and so
so on I don't expect that it'll be demonstrable. However, in that
there are a very substantial number of switches and configuration
changes in OS/2 that can be applied to how upper memory is handled,
much like QEMM, it just might be possible I can do some good if I
only know enough to know where to look. In QEMM we had MPT and so
on to troubleshoot all of this stuff and curiously, it even works in
OS/2 DOS-VDM sessions if I recall right, at least for some of the things
one can debug.

I can understand a 'stable' error which shows up at some readily
visible 'limit' of this or that.

What I can't understand is why, of a half dozen programs all using
virtually the same libray modules and much of the same code, a
couple SMALLER ones will pop the error in the PB-IDE, yet LARGER
ones will not!

Nor do I understand why the PBC command line compiler will handle
all the compile jobs in question, including the SMALLER ones that
the PB IDE will not.

If someone will simply share the ways that this error can be popped
in the PB IDE, maybe I can debug the environment here. I'm not saying
in any way the PB is at fault, or anyone is at fault.

Thanks ..



------------------
Mike Luther
[email protected]