Announcement

Collapse
No announcement yet.

Expansion Memory Fault help please?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Expansion Memory Fault help please?

    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]
    Mike Luther
    [email protected]

  • #2
    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.


    ------------------
    There are no atheists in a fox hole or the morning of a math test.
    If my flag offends you, I'll help you pack.

    Comment


    • #3
      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]
      Mike Luther
      [email protected]

      Comment


      • #4
        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>
        Lance
        mailto:[email protected]

        Comment


        • #5
          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]
          Mike Luther
          [email protected]

          Comment


          • #6
            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>
            Lance
            mailto:[email protected]

            Comment


            • #7
              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]
              Mike Luther
              [email protected]

              Comment


              • #8
                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>
                Lance
                mailto:[email protected]

                Comment


                • #9
                  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]
                  Mike Luther
                  [email protected]

                  Comment


                  • #10
                    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

                    Comment


                    • #11
                      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]
                      Mike Luther
                      mike.l[email protected]

                      Comment

                      Working...
                      X