No announcement yet.

PGM-CTR errors

  • Filter
  • Time
  • Show
Clear All
new posts

  • PGM-CTR errors

    In compile, my programs run fine. When I turn them into EXE
    files however, I encounter the pgm-ctr error. The following is
    the most common one.

    7 at pgm-ctr 308

    I can't even tell which program is triggering this error
    because my program constantly shells another EXE file. I have one
    "control" program that shells which ever program needed to run. Only
    variables in the "Control" program need to stay intact- the
    shelled to EXE variables do not need to be preserved.

    If Invntry < MinReqs then
    if Invntry < 0 then
    Shell "C:\stock\autordr.exe"
    Shell "c:\Stock\MinReqs.exe" :'Min inventory required!
    end if
    if Invntry > 40 then
    Shell "C:\Stock\Ovrstck.exe":' TOO MUCH inventory!
    end if
    end if

    And so on. Is there a way to determine which line and program s
    triggering this type of error? I am hoping for a relatively easy
    way to do this so I can do it myself. I counted the Shells, and
    I have a total of 37 SHELLs. Is that the problem?



  • #2
    I would recommend putting a pause before each shell. Your
    code modified: This is not exact of course, but it'll give
    you the idea.

    If Invntry < MinReqs then
    if Invntry < 0 then

    print;"Shelling to autordr.exe"
    while instat=0:wend
    temp$ = inkey$

    Shell "C:\stock\autordr.exe"

    print;"Shelling to MinRegs.exe"
    while instat=0:wend
    temp$ = inkey$

    Shell "c:\Stock\MinReqs.exe" :'Min inventory required!
    end if
    if Invntry > 40 then

    print;"Shelling to Ovrstock.exe"
    while instat=0:wend
    temp$ = inkey$

    Shell "C:\Stock\Ovrstck.exe":' TOO MUCH inventory!
    end if
    end if

    This should give you the program where the error occurs. Then
    you should be able to take care of it from there.


    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.


    • #3
      The "pgm-ctr" error is NOT a "prgm-ctr" error. "Error 7" (insufficient memory) is the important value, and you can use the IDE option "Compile/Find Error" to convert a "pgm-ctr" into a distinct line of source code.

      Oops, forgot: if you are shelling your own PB/DOS programs, you can trap the errors simply by installing error traps with ON ERROR GOTO xxx. In your error-handler, you can PRINT the name of the program, the error code and ERRADR (ERRADR returns a "pgm-ctr" value which you can then trace back to a source code line as shown above).


      [This message has been edited by Michael Mattias (edited August 14, 2001).]
      Michael Mattias
      Tal Systems Inc. (retired)
      Racine WI USA
      [email protected]


      • #4
        Michael, currently I only check for a few errors at the ON ERROR,
        the rest of them I simply RESUME NEXT. I will fix it to report
        each and every error. I had been using ERRADR wrong, thanks for
        pointing that out. A BIG thank you!




        • #5
          But wait!

          Isn't there more here? Grin!

          RESUME NEXT has a price tag, doesn't it? If you use it you
          generate a larger finished product as to the operational size
          of your program, no? Next means the code has to know where next
          is, as I understand all this.

          As well, I may be learning something here again too, but isn't
          the whole intrinsic error level operation keyed to NUMERIC line

          I think I've learned a long time ago that an error only romps
          back to the closest NUMERIC line label. For code stability
          purposes I've never asked an error routine to ever even return
          to a non-numeric line label. At least in BASIC. Can PB RESUME
          at a non-numeric label? I think so, but it doesn't trap an
          error to same as far as I know.

          I wish it did in some further incantation of whatever, but I'm
          not holding my breath or an avoidance on that wish.

          That said, if I have to have error trap location information
          in a block of code which doesn't have numeric line lables, I
          create my own numeric trace variable pointer as the block
          executes. Sort of my own line numbers if you please. Then
          on error I can analyze that checkpoint variable and tell where
          to resume even if there are no line lables that PB could use
          to tell me other than even, say, only the first line in the
          program has a number (10) for example.

          That's particulary important when using in-line assembler, such
          as a Btrieve file interface where things can go bump. You either
          get to use line numbers for a trace purpose only, or code your
          own substitute for that, as you wish.

          As well, for very, very large projects, I've found it convenient
          to plan for the lowest level subroutine library modules to carry
          further and further numbers for the line labels toward the
          allowable cap level of 64555 or so. Your master line numbers in
          these subroutimes are, for example, all above 50000. That way
          you can create one key numeric line number lable in each SUB at the
          beginning of it, with the few critical other numeric lables at
          critical places in it. That will let you trap back to the places
          where things go wrong down deeper in nested code.

          From there we use, as Lance Edmonds taught me quite a while ago
          here, to be sure and use EXIT FAR to properly reflect back where
          we went bumppity bump! The use of this is NOT, as best as I
          can tell enhanced at all by the concept of RESUME NEXT. In fact,
          isn't such a thing totally counterproductive and at odds with
          the assignment of numerical line lables? They are limited you
          know! And you can have a number of lines of code inbetween
          consecutive numeric line labels as well.

          What would happen to RESUME NEXT in that case?

          Inquiring mind wants to know!

          I think one is wise to contemplate all this for another interesting

          If you ever have to port PowerBASIC to another language, one of
          the things you will greatly miss is ... numeric line labels!
          They are both a pest and savior, as you may have already discovered.

          In a major port process for to take PB source to C of C++, I think
          you will find that you'll wind up creating pseudo-lables for each
          of the line lables you have in the PB source! That's what I wound
          up doing in the translator here.

          From there I created a trace trap integer counter for each location
          which takes the place of that line number. It then is the directive
          for the error trap routine you have to then use in the other
          programming forum to do what is so easy in PB.

          Since we started at RESUME NEXT for this pig trail,

          how would you suggest one contemplate finding
          the NEXT acorn for an error ****ing piglette,
          without a numeric ear tag for each step 'e takes?

          No, for those who have read Winnie The Pooh, I think RESUME NEXT
          is rather akin to poor Pooh with the honey bucket stuck on 'is
          head. A real bother indeed ..

          Plus ..

          It becomes a heck of a lot more introspective if your programs
          are up in the 25,000 line source range, I clue you. As does
          the burden of RESUME NEXT from an overhead standpoint.

          The code's not done, 'till there's too much to run!

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


          • #6
            PB supports Line Numbers, put a Line Number in front of each Line
            and break the code smaller in each line, then use on error goto
            and check the error code then use resume (resume next is risky)



            • #7
              Sorry, I forget to tell you can use "PRINT ERR,ERL" to check code



              • #8
                Michael- You are right about RESUME NEXT being risky. Blame my
                college professor. Her opinion, at the time anyway, was to
                track on paper what errors you wanted to catch. Then write
                +only+ for those. Assume I have written a routine for the
                errors I want to trap, then my next statement after the error
                point would go back to "default" values for the variables so
                the program could continue. I thought it was risky and asked
                her if it wasn't better to prepare for all errors? Her response?
                "Do it my way for the grade. I like RESUME NEXTs, and you will
                too!" It is a habit I am working on breaking.

                Doris, thank you for pointing out using line numbers. Previously
                I was NOT a line number user due to the fact my Quickbasic did
                not allow line numbers in SELECT CASE statements? I was pleased
                to find that not the case with PB. Now I got to number all my
                routines now.



                • #9
                  You don't need to number all Lines, only those you suspect
                  a problem, like the one on "SHELL".



                  • #10
                    ERL reports the most recently numbered line executed.
                    ERRADR reports the "pgm-ctr" which you can then use to find the line of source code.

                    Compile/Find Error is such a really cool feature of the DOS compiler; it should get more use.

                    RESUME NEXT?

                    If you use ...
                     ON ERROR ERROR RESUME NEXT
                    .. and don't check ERR after each possible ERR-generating statment, you are (IMPO) trolling for trouble.

                    Better you should write your code for development with ...
                    ON ERROR GOTO somewhere
                    ..and after you have the major errors out and have code in place where ERR is EXPECTED (i.e., disk not ready, file not found), recompile, changing 'GOTO somewhere' with RESUME NEXT.


                    Michael Mattias
                    Tal Systems Inc. (retired)
                    Racine WI USA
                    [email protected]


                    • #11
                      From Michael:

                      .. and don't check ERR after each possible ERR-generating
                      statment, you are (IMPO) trolling for trouble.

                      You are right. I have a rudementary routine now that tells me the
                      Error Number and Line Number (if there is one).




                      • #12
                        Now ..

                        You are right. I have a rudementary routine now that tells me
                        the Error Number and Line Number (if there is one).
                        as you do this, think about one more step. Even if you do not have
                        a hard Line Number in view of (if there is one.), there is one
                        more thing you can do.

                        You can carry an otherwise not used integer variable that is
                        set to what might have been a line number at various points in
                        your program!

                        It doesn't have to be a for-real line number.

                        You just keep making it larger and larger, just line line numbers
                        only just like

                                LNR% = 1
                                LNR% = 2
                        Then if something blows up between LNR% = 1 and LNR% = 2, you just
                        look at the value of LNR% and that takes the place of the formal
                        line number in the error trap routine! If at the time the error
                        takes place the value of LNR% is equal to one (1), you have your
                        conditional answer on what label you should return to on RESUME.

                        The error happened somewhere between LNR% = 1 and LNR% = 2.

                        Takes the place of formal line numbers, kind of!

                        Of course PB does the work for you with numeric labels. But the
                        point is that the logic process on how this works may come in
                        very handy when you might want to consider error trapping in other
                        than raw PB code .. in assembler .. or C or whatever!

                        If you know how to use line numbers for choosing the place to which
                        you wish to RESUME in BASIC, that's one thing. But if you understand
                        the process by which this works, you can immediately jump to the
                        same or at least similar capability in other ways. And that goes
                        not only to the process of error happenings, but the whole basic
                        process of IF / THEN on which error trapping is just a specialized
                        sugar coated variation on the theme.

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