Announcement

Collapse
No announcement yet.

Batch files calling PB programs in complicated ways

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

  • Batch files calling PB programs in complicated ways

    I seem to have discovered another problem

    I have a program which OPENS an INPUT file, FILESCANS it and then INPUTS to end of file with a DO UNTIL EOF/LOOP

    The program is always SHELL'ed from another program

    Works perfectly

    The program actually is also workable (in test data mode) if I call it direct or if I compile and run it direct from the compiler. It works perfectly in both those cases.

    But if I call the 'other program' from a batch file which then calls the DO UNTIL EOF/LOOP program, then the DO UNTIL EOF/LOOP instruction corrupts the program. It corrupts it in a number of ways but the easiest way to explain is that if I add a 'PRINT "JJ": WAITKEY$ immediately after the LOOP then it displays JJ and does not Wait - and then it goes crazy.

    If I change the DO UNTIL to a For x = number_of_records (as determined by the Filescan), read a record, NEXT - it works perfectly in any mode. (Changing nothing else)

    Maybe the EOF is not referring to the right file - but a printed out CURDIR$ implies that it does, and anyway, the OPEN and FILESCAN (which precede the EOF of course) do refer to the right file. And I would not have thought that even if the EOF is wrong, it should not corrupt. And I do not think the EOF is causing a runtime error but I need to double check this.

    I may not be describing the problem absolutely correctly. But I think I am

    It has taken me man days to find it - I almost gave up sometimes.

    I think that there are some real issues with PB programs called from batch files in another directory

    Any comments anyone?

    [latest PBCC, Windows 10, no funny stuff that I am aware of]

    Kerry


    [I]I made a coding error once - but fortunately I fixed it before anyone noticed[/I]
    Kerry Farmer

  • #2
    Update:

    I am now almost 100% positive that the DO UNTIL EOF/LOOP instructions in themselves do not cause a runtime error to be generated

    [Update handled with full data trail standards enforced!!!!!]
    [I]I made a coding error once - but fortunately I fixed it before anyone noticed[/I]
    Kerry Farmer

    Comment


    • #3
      I think that there are some real issues with PB programs called from batch files in another directory
      To answer your question directly: No, there is not now nor has there ever been any 'issue' in any PB program which would cause it to behave differently if started from a batch or command file. You claimed to eliminate specifically only DO..LOOP syntax from "problem" consideration; my statement is far more inclusive.

      I HAVE seen, however, any number of "trouble reports" here which were really nothing more than the program's failure to handle the current directory correctly.

      And of course, relevant here, "Allegedly failing code not shown."

      And maybe too, you should just include your OPEN/DO..LOOP/CLOSE code in a DLL to make it part of the same process. (Requires PB/Windows; compiler in use not shown)

      MCM
      Michael Mattias
      Tal Systems Inc.
      Racine WI USA
      mmattias@talsystems.com
      http://www.talsystems.com

      Comment


      • #4
        Thanks Michael for that assurance.

        It will give direction to my ongoing investigation.

        PS I did mention my compiler - see final note!
        [I]I made a coding error once - but fortunately I fixed it before anyone noticed[/I]
        Kerry Farmer

        Comment


        • #5
          Kerry, can you create a skeletal program with exactly and only enough code to demonstrate the problem?

          Comment


          • #6
            Chris

            I acknowledge that I should

            But a) I have solved (as in 'got around') the problem and b) I am time poor.

            My program worked in non-batch mode and did not work in batch mode - same compile - I could not see the difference

            I changed the instructions as above (that is two lines) and it worked in both modes

            I have two reservations about this. It was a little bit difficult to test - you had to generate the batch file etc - so maybe I stuffed up, but I do not think so.

            The other development is that the system used a number of SHELLs - and some were wrong and had to be corrected , so I may have had a re-entry problem under the batch test - but again, I do not think so - and even if I did, I could not explain the differences.

            But before anyone does any more work on this - I need a simple test bed.
            [I]I made a coding error once - but fortunately I fixed it before anyone noticed[/I]
            Kerry Farmer

            Comment


            • #7
              My program worked in non-batch mode and did not work in batch mode - same compile - I could not see the difference
              My money is on some kind of pathing error of either commission or omission.

              The other development is that the system used a number of SHELLs - and some were wrong and had to be corrected
              If the program does what you saysin post #1, no SHELLs are needed. But let's say you DO have some SHELL in there...iand your code looks like ....
              Code:
                   SHELL  "programname"
              .. it should probably be changed to.....
              Code:
                 SaveDir = CURDIR$
                 pdi = SHELL "programname"        ' note change to FUNCTION from STATEMENT
                 hProc = OpenProcess (pid., other options)
                 WaitForSingleObject  hProc, timeout_value 
                 CloseHandle  hProc
                 Chdir     SaveDir
              .. because "programname" can change the current directory.... and oh, look, a pathing errror of omission.


              (Above code detail using ==> Win 32: Monitor Process with ShellExecuteEx June 22, 2001
              (A SHELL replacement)

              But before anyone does any more work on this - I need a simple test bed.
              You don't need a test bed so much as you will need a way to keep me from saying, "Code not shown,"


              MCM
              Michael Mattias
              Tal Systems Inc.
              Racine WI USA
              mmattias@talsystems.com
              http://www.talsystems.com

              Comment

              Working...
              X