No announcement yet.

Problems with Shell

  • Filter
  • Time
  • Show
Clear All
new posts

  • Jim Cody
    Your problem statement was:
    Close #3
    Shell "Process_1"
    Shell "DEL File_1"
    Shell "DEL File_2"
    GoTo MAIN

    All of the sudden, it started to give me problems on one pc. It shells to "Process_1" and executes that .exe just fine. It even continues to del file_1 and file_2. However, the command window never closes and the program "freezes", it does not "GoTo Main"... The problem is that the shell to Process_1.exe is leaving the command window open in what appears to be a program "hang".
    I can't see where you have ruled out the possibility that your SHELL to Process_1 never completes.

    What if File_1 and File_2 were not actually created? They would then "appear" to have been deleted when you "hang." The symptoms you describe are really indicative of a failure in Process_1 when the two files were never created, and you never "got to" the DEL functions or to MAIN because the Shell to Process_1 never completed.

    I think the code you are looking at may be a "stalking horse." Check to see if the files actually get created and look for a reason why Process_1 fails to complete. Your problem suggests that you have a COBOL program (Process_1) that has compatibility issues with one of your PCs.
    Jim C.

    [This message has been edited by Jim Cody (edited October 12, 2003).]

    Leave a comment:

  • Michael Mattias
    Hint! I would *LOVE* to see the next release of PB platform aware
    What does that mean?

    A. The IDE knows on what platform it's running and does something different?
    No thanks, I like my IDE predictable.

    B. Generated code is optimized for the system on which it is compiled?
    No thanks, I don't use the same equipment as my customers.

    C. The generated code contains conditional executable code; which code executes is a function of the system on which the software is running?
    No thanks.. or come to think of it, you've finally come up with an excuse for me to try the #BLOAT metastatement.



    Leave a comment:

  • Mike Luther
    Lubos ..

    The advice to use the SLEEP function in PB in a case of multi-tasking
    task session access error problem isn't at all correct in my humble
    experience in OS/2's very good pre-emptive multitasking world.

    As discovered a long time ago, at least here, the SLEEP function is
    one of those portions of the PB toolset which appears to have no
    awareness of operating in a multi-tasking environment. I can't tell
    you the code which was assembled to provide it, but it loops closely
    enough so that the CPU is swamped with those loops. With no other
    way to operate since it dominates the CPU, many other sessions and
    tasks never do what they are supposed to do either.

    Yes, because OS/2 is PRE-EMPTIVE in nature, as a multi-tasker, a PB
    task with SLEEP running in it won't totally shut down the whole computer
    for the operator. Thus, for example, I can mouse over the desktop, hit
    another key to operate the desktop, or .. in some cases, continue to
    see a TCP/IP application in another task still running ... slowly ...

    More important, the issue, as seen from running my programs under the
    earlier forms of WINDOWS 95 and 98, is so serious, that there is simply
    no way to run, say several PB 3.5 applications with certain functions
    in use in them on these earlier WINDOWS platforms at all without totally
    rendering the computer useless for other work. Examples of such uses
    are trying to run my six-line telephone monitoring communications port
    program with fully interactive networked database information server
    and screen pop program in one session, my networked printer server for
    forms output, my facility management program, my database mining
    application; say those four different PB applications at the same time
    on a desktop. Even without the use of SLEEP, there are also other PB
    operations which make this difficult, or impossible unless the operating
    system is PRE-EMPTIVE in nature, which at least the earlier WIN versions
    simply could not do.

    And .. as noted, even in OS/2, there are MANY different DOS applications
    which have this problem. DOS was never designed as a multi-tasking deal
    at least as it evolved through the Microsoft era, that is for sure. So
    even in OS/2 .. we have what are called TASK BUSTERS that can force,
    in most cases, even a DOS program to give up time slices more applicably
    to the other things which must go on, like surfing the net, while
    watching and logging a phone line in an application written in PB.

    But there are other levels of task busting which can be used by a careful
    and knowledgeable PB programmer which make much of the use of his or her
    program able to release time slices on the CPU without the user ever
    realizing this thoughtful action has been done. In order to do this we
    must substitute some different code for the PB function which does not
    have this time slicing awareness.

    To do this, the first thing we need to know is what kind of am operating
    system is being used on which the PB application is running. Is it a
    WINDOWS box? Is it an OS/2 box? I've never even tried DOSEMU in LINUX
    so don't ask me about it. but that's got to be thought about too now.
    Then, depending on that answer, there are different ways to hand code
    what used to be the SLEEP function, which return the same functionality,
    but give up time slices to the CPU during the idle time they are seeing
    so that other things can be done.

    Remember that SLEEP can be broken by a keystroke! So too must you code
    the substitute for that PB function, if you wish to make it work like
    SLEEP was intended to work. This means the entire keyboard I/O routine
    must be then involved in your alter-SLEEP you write. And don't forget
    that the MOUSE, if you are using one, has to be involved in this here
    too, complete with the click and data return for it.

    In fact, what you realize, after you have done the development work
    to properly handle what is required, you are having to re-write the
    entire PB single byte INKEY$ function just to provide for this. In
    every PB program I ever write, just the INKEY$ function has to be
    surrounded by some 500 added lines of program code, to do what's needed
    in my total suite, as well as to provide for the absolutely needed time
    slice releasing for use on not only OS/2, but for WIN-95, WIN-98 and
    who knows what all else in the world of WIN for the user.

    Just your one line which says SLEEP in your suggestion, in at least one
    proper way to do what you suggested, is really, I think, a sigle INKEY$
    call which is bound into a time slice releasing timer loop. You have
    to time slice the whole box while you loop the system in your own code
    the hard way, by looking at the system clock and so on, until the right
    time period has passed.

    In my suite, that 500-odd lines of PB code, including in-line assembler,
    to properly do what you suggested, is a SUB which is CALLED to do this.
    And just like building communications towers or railroads, there sure
    is more than one way to do this properly. I'm just citing my case here.
    As thought .. you might wish to look at the in-line assmebler which it
    takes to do this job here.

         IF ISTRUE BIT(pbvHost, 8%) THEN '   In WIN environment
            ! push DS
            ! mov AX, &H1680
            ! int &H2F
            ! pop DS
         ELSE '                      Not in a WIN environment
            ! push DS                ; Save DS for PowerBASIC
            ! mov AX, &H8600         ; Place function $AH68in AX
            ! mov CX, &H00           ; Use less than 1000 MS delay
            ! mov DX, &H0A00         ; Try &H0A00 for a delay in DX
            ! int &H15               ; Call timer interrupt
            ! pop DS
         END IF
       Z0$ = INKEY$
    That's just for the keyboard I/O stroke capture. All the mouse code
    which similarly has to be time slice releasing aware is lots and lots
    more code as well. Plus if you wish to alter the granularity of the
    time slice release, you'll have to provide for other than the hard
    coded time set I show above.

    So just asking the computer to SLEEP to break this isn't going to work
    in any application that I've found, which is to be run in a multi-tasking
    environment, even in a good pre-emptive one.

    You also might want to be aware that the entire arena of ON TIMER, and
    the communications port stuff, is also bound up in these same time
    slice release problems for PB for DOS as used in other than straight
    DOS. While you are SLEEPING, as you suggest, maybe another PB program
    is controlling the loading chute for unloading cows out of a trailer
    into the pen! If you are fast enough, you might even be able to remove
    the whole chute for a few seconds to use it on another trailer if there
    are now cows close enough to the end of the trailer for a moment! But
    if you do, that chute had better be back in place for the next cows in
    the bunch .. or else they will all fall out the trailer and break
    their legs kawhomp!

    Don't laugh too hard. That is exactly what happens to real-time comm
    programs if you use SLEEP as you suggest, as well as comm port I/O
    routines in PB under multi-tasking work. The cows, in humor here, are
    the data bytes in the I/O stream which have no place to go, even if
    they are buffered, if SLEEP has destroyed the real-time cadence needed
    to keep all this together. And that in multiple PB applications as
    well like I use here.

    And it is *NOT* fair to criticize PB for no awareness of this. PB has
    done, I'm sure a wonderful job of taking care of the special needs of
    this in the work with PBCC and so on. I don't use the products for
    WIN though I have paid for them and have them here. So the SLEEP
    function may well be coded in them such that this is not an issue if
    you use the WIN tools for WIN work.


    Hint! I would *LOVE* to see the next release of PB platform aware!


    But you sure can't use the PB 3.5 for DOS tools for it and expect to not
    get in trouble in the multi-tasking world, as DOS originally provided
    for how to go to SLEEP!

    When In DOS we go to sleep, no fourteen angels watch to keep.
    Unless'n you put'em der, Massuh!

    Mike Luther
    [email protected]

    Leave a comment:

  • Lubos Svoboda
    it's difficult give an advice on basis a tiny piece of code, but
    Close #3
    Shell "Process_1"
    sleep 1
    Shell "DEL File_1"
    sleep 1
    Shell "DEL File_2"
    sleep 1
    GoTo MAIN

    Maybe, first of sleeps will enough.
    It looks stupid but helps sometimes.

    A view on PowerBASIC

    Leave a comment:

  • Kurt Schultz
    Originally posted by Bob Haynes:
    Hi Clay, I did not write the cobol exe that is displaying
    output to the dos window. However, I do know that in about
    ten other installations, the dos window always closed on its own.
    There must be some programming that closes the window.

    It's really odd because all of the sudden, I'm having this issue.
    The dos window does not close and the program freezes.


    If the code acts differently on this one machine, there's something different about the machine.

    As a guess, I'd say you should look at the DOS window's properties; I'd bet there's a difference between the properties of this one's window(s) and the properties of the window(s) on the other machines.

    This does not sound to me like a PB problem.


    Leave a comment:

  • Mike Luther
    Bob ..

    The issue issue of whether a shell child reqmains open and the next
    one opens while the first one is still open is even more complicated
    than many people think.

    I know you are likely not operating under OS/2, but let me share how
    this works even within the same executable and batch files here in OS/2
    in an attempt to help you.

    If you execute two SHELL statements in succession like that from within
    a PB 3.5 for DOS program, running in an OS/2 DOS-VDM program, in general
    it does exactly what you think is happening. The first one will execute
    and close. Then the second one will execute and close. Any errors that
    show up in the process will be focused, if I can use that word loosely
    here, in the actual shell process, but not necessarily carried back to
    your PB 3.5 program at all. Remember, the DOS programs, on exit, can
    leave error exit values from the program. We often do this as creators
    of our programs so as to provide exit instructions which can branch
    from a program that let the host program decide on some form of a
    pecking order with how to behave if certain exit conditions are
    different than others.

    If you are attempting to use this technique in a SHELL operation in
    PB 3.5 for DOS, operating in a DOS-VDM program in OS/2, exactly
    what straight DOS does will be done with your code ...

    mostly ..

    But that depends! Here is why and how. If the program you are trying
    to run does not necessarily behave in the exact manner on exit that
    you are contemplating, the HOST program that SHELLed the child, may
    not know that the process is really over, or .. may not know how it
    terminated as to any errors that were spawned on exit by the child.
    What does this mean.

    It has at least TWO different meanings in OS/2, and also as WINDOWS
    matures, as far as I know. First, your program which is the target
    of the SHELL as a child, may be just a common DOS program. But it may
    not! And depending on how the operating system is designed in which
    you are running this SHELL child deal, two different things can take

    In OS/2, running as a DOS-VDM so-called pure DOS program, your will
    get largely what you expect. But wait! It is possible to use a
    technique, and some programs have this technique built in, to spawn
    a different than straight DOS program or a Rational 4DOS program or
    other program. You can even call what you, Bob, think is a pure DOS
    program ... and .. under the covers, it is *NOT* at all such. For
    example, it is possible using PASCAL and evne the MircroSoft PB7
    Professional Bascom Compiler operation, to write code which will
    actually operate under DOS ... or ... even Native OS/2 in 16 bit mode
    as conventional DOS-like basic 16 color with bright makes 16 more
    color programs that run under native OS/2 or DOS and you can't tell
    the difference and how they are running on the OS/2 system just by
    looking. That even though it is a shell child, from a DOS program!

    Most folks really do not know that very early WIN-95 programs,
    with a few drivers installed, will run just fine on an OS/2
    system. You can even run several different ones at the same time
    on the desktop, too.

    Then what is the difference? Simple, in OS/2, the operating system
    is a VERY well orchestrated PRE-EMPTIVE operating system. While the
    SHELL statement you issue for that first command is clear to it, and
    your will be done, if, by chance this is a program that internally can
    be treated as ... an independent thread .. guess what?

    Suprise! You also have to 'tell OS/2' .. and perhaps the operating
    system in which your SHELL child group is running, whether this child
    can be assigned an independent thread and life of its own, or, must
    the big DADDY in the sky, the operating system, must specially restrict
    your child to FINISHING its job, before the next one runs. If, I,
    for example, use an OS/2 loader to run an OS/2 native program, in
    the SHELL child operation from PB 3.5 for DOS, and do not tell OS/2
    to make sure this program runs to exit BEFORE returning 'control'
    to the program that SHELLed this child ..

    -------> The first SHELL child will remain running on its own
    -------> and the second SHELL child will spawn right away!

    That is exactly, in a way, here, what may well be happening to you.
    Even though you are not running OS/2, but some form of WINDOWS, Bob.

    Even more interesing, you can SHELL to a BATCH file (.BAT) as well.
    When you do that, it gets even more interesting. Using the right
    tools, you can even get fouled up in the .BAT file. Or, in OS/2,
    these files are .CMD files and not .BAT files. But you have to be
    very careful to tell the operating system in a multi-tasking one,
    at times, exactly how to handle this stair-step child operation.

    Going backwards from native OS/2 programs and calling a DOS-VDM as
    a shell child is, grin, child's play. Except that, here too, you
    have to one way or another tell the system what to do from one
    child to the next. You REALLY have to watch your step in this
    world of mine if you go from native OS/2 to DOS children. And you
    even can call BATCH files, as SHELL children too.

    How do we do this in batch files, if you have no internal control
    over the program to do this as part of the batch operation?

    Simple, and you can do this too.. You can set a flag file on the
    disk that shows that the first child is active. Then, as part of
    the second file's operations sequence, you check for the presence
    of that flag file. You erase that flag file only after the first
    child is through running. The second program runs inside a timing
    loop. If the flag file is present, the second thread (child) enters
    a timed loop. At the end of the timed loop, the second child goes
    back and looks at the presence of that flag file again. If it is
    gone, it knows to execute, and off we go.

    You, of course, have to provide timed and error level exits so that
    if something goes wrong in the first child process, the second child
    will, perhaps, not run at all, or run in a different way since a
    condition that it needs for a normal run is missing.

    Complex error trap handling, if you will, but it can even be, to some
    extent, handled even within a BATCH file that is called by ONE of
    your SHELL statements, eliminating the need for the two separate
    ones you presently have, as I have suggested. Doing it this way,
    creating the batch file with a simple file write, is easy. Write
    the batch file from your program. SHELL to it. Then delete that
    batch file on re-entry to your program. Secret soy sauce and
    nobody normally will know what you are doing...

    In reality, when we get to the real level of programming for use
    with multiple task operating systems, this is all handled by what
    I know as semaphores, not disk flag files and so on. But you can,
    as illustrated, even in your world of PB DOS put this together in
    such a way that your DOS program can be run in the later world
    of mor complex systems. Just pay close attention to making sure
    how you can sequence those SHELL statements so you can be sure
    that they run in the sequence you desire ... and understand.

    WIN2000, WIN-XP and these later WINDOWS operating systems all are
    steps in this complex direction. Although I have the PBCC products
    and do not use them, I am sure that the PBCC tools have the way
    to do this built in to them as such.

    Just trying to help by trying to show how the process works from
    the way this happens for me all the time in my little world here.

    Mike Luther
    [email protected]

    Leave a comment:

  • Bob Haynes
    Hi Clay, I did not write the cobol exe that is displaying
    output to the dos window. However, I do know that in about
    ten other installations, the dos window always closed on its own.
    There must be some programming that closes the window.

    It's really odd because all of the sudden, I'm having this issue.
    The dos window does not close and the program freezes.



    Leave a comment:

  • Clay Clear

    I do not know about other operating systems, but, on my Win98SE
    machine, if a DOS program prints anything to the display, then Windows
    will not close the window when the program has terminated. You have
    to manually close the window with the "x" (system menu close button).
    On my box, if my DOS program does NOT print anything, then Windows
    automatically closes the window after the program has ended.


    Leave a comment:

  • Bob Haynes
    Michael wrote...
    The way you described your problem it sounded like your program was 'hanging' on the "delete_file_2" line

    Michael, I appologize for not being very clear. The command window
    that remains open is from the Process_1.exe program. I display
    a counter on the command window for that program and you can still
    see the the counter on the "frozen" window. However, File_1 and
    File_2 do get deleted.

    This is why I'm not sure what is going on. If my program does
    delete File_1 and File_2, I was assuming that it was done shelling
    to Process_1. And if it is done shelling to Process_1, then
    why is the command window not going away? Or does it shell to
    Process_1 and without waiting for Process_1 to finish, it
    deletes File_1 and File_2.

    Thank you...


    Leave a comment:

  • Bob Haynes
    Hi, I'm still playing with this program and it appears to me
    that when I execute the code...

    Shell "Process_1" that my program is running this exe but it is
    not waiting for it to completely finish before it moves to the
    next line of code, Shell "DEL File_1".

    I thought a Shell command would wait until the shelled program
    was completely unloaded before it moved to the next statement??

    Close #3
    Shell "Process_1"
    Shell "DEL File_1"
    Shell "DEL File_2"
    GoTo MAIN

    Thanks, Bob


    Leave a comment:

  • Michael Mattias
    The way you described your problem it sounded like your program was 'hanging' on the "delete_file_2" line

    Why I did it the way I did? Why SHELL a file delete when you have a function (KILL) which does the same thing, and using KILL your program has total control of the delete complete with error codes?

    As far as the command window staying open, either.. (and I'm not very good at these)..

    There might be a system option which controls "window behavior" of Console programs.
    ** OR **
    The command window might be closing, but then re-opening to do the "del" command.


    Leave a comment:

  • Mike Luther
    Mike's right ..

    An additional thought is to perhaps avoid using RESUME NEXT, if at all
    practical in your code and substitute hard numeric line labels. Yhat
    will let you take advantage of PB's excellent error handling and
    reporting capabilities which have so thoughtfully been assembled for
    your use.

    Yes, I understand numeric line labels have some unttactivelness for lots
    of people, but if you are doing this to get away from PB then I can
    only offer you another tip. Grin, it also helps even if you never leave
    the wonderful PB fold.

    You can build your own pointers to the practical line 'number' at which
    an error takes place by simply creating a global variable name for
    it. Then you hand create an equate at critical places which increment
    and also decrement that pointer as your code executes. By doing this
    on a global basis, I've successfully imitated the PB error handling in
    translation work of PB to C/C++ for research purposes.

    When your programs begin to include, or if they currently include the
    CALL or FUNCTION features, even if they are deeply nested into subroutines
    inside of subroutines, by carefully planning numeric line numbers to
    the allowable 65000 or so line numbers allowd, you can feed critical line
    numbers into all your work. That lets you go back, for example, and
    direct program operations to different places, depending on, in your own
    example, which of the lines blew up.

    The use of RESUME NEXT doesn't let you plan for alternative exits to
    the problems which can surface. RESUME #### as provided in PB does.
    And if you develope the habit of creating your own pointer variable to
    this, you can then use RESUME and then a CUSTOME LABEL, even if
    needed, that is a non-numeric label to continue.

    One place where this becomes very, very helpful, is in the use of the
    Btrieve files systems from Pervasive. Failures from within their own
    routines contain a complete custom set of error messages and a numeric
    pointer to each. You build a similar error to the way you have from PB
    to display and record these to an error log file to let you trace
    blowups that way, even to what to do when a customer comes calling, and
    you ask them to read the error dump file line for your report file,
    which is all taken and reported from this use of both hard numeric line
    numbers from the PB tools, plus your own pointers as needed, as well as
    what, say Btrieve told you too. It may even be helpful, for example,
    if this shell example you posted involves files that are on a different
    box somewhere on a LAN, to learn to use the INT21H custom error messages
    and others which really can drill down to what is wrong. Think about
    that. PB can't even reasonably be expected to cover all those complex
    error possibilities which you might really need some day.

    Last note. Courtesy of the VERY helpful teaching of Lance here, when
    you start to use CALLS, SUBS, and so on, especially if they are nested,
    use the concept provided in EXIT FAR to make sure the code collapses
    to the desired place where you really want to handle many errors. Then
    to isolate this stuff into local places in SUBS and so on, should what
    you be showing us be in one of them, you use the ON LOCAL ERROR game to
    try recovering locally what you can, prior to the final EXIT FAR which
    is the catch all rain bucket.

    Finally, consider investing carefully in the inexpensive tool called
    ULTRASHELL for PB's executables. I realize you showed us a simple
    command line level example here that causes you problems. But you
    can have problems that surface in the shell game which are memory
    space related problems. This tool gives you the ability to slush the
    main program code into upper memory creating far more memory for your
    use in the shell child process. Alan has done a wonderful job of that
    which greatly extends the issue.

    And as a post script, consider redirecting the video output of the
    shell operation into a NUL location. For some, but not all work,
    that way the user will never see what is going on in the shell game.

    You will grin from ear to ear the first day you pick up that shell
    and under it is the real trace data which tells you how that stray
    penny got there! It might even be a US 1909 SVDB cent which if all
    the wheat tips are on it would be worth over $500 that day!

    Mike Luther
    [email protected]

    [This message has been edited by Mike Luther (edited August 20, 2003).]

    Leave a comment:

  • Bob Haynes
    Thank you Michael for your reply. However, I am a little confused
    as to why this will solve my problem. Deleting of the two files
    is working ok. The problem is that the shell to Process_1.exe
    is leaving the command window open in what appears to be a program

    I'm not being argumentative...just trying to learn while getting
    my problem fixed!! I'm still a beginner....




    Leave a comment:

  • Michael Mattias
    Shell "DEL File_1"
    Shell "DEL File_2"
    New code:
     KILL "file_1"
        PRINT "Error #" & STR$(ERR) & " Killing file 'file_1'"
     END IF
     KILL "file_2"
        PRINT "Error #" & STR$(ERR) & " Killing file 'file_2'"
     END IF

    Leave a comment:

  • Bob Haynes
    started a topic Problems with Shell

    Problems with Shell

    Hello, I've been using the following code snippet with success
    for some time now:

    Close #3
    Shell "Process_1"
    Shell "DEL File_1"
    Shell "DEL File_2"
    GoTo MAIN
    All of the sudden, it started to give me problems on one pc.
    It shells to "Process_1" and executes that .exe just fine. It
    even continues to del file_1 and file_2. However, the command
    window never closes and the program "freezes", it does not "GoTo

    Does anyone have any ideas why this may be happening? Could it
    be a memory problem? I'm totally in the dark on this!

    Thanks for your help.