Menu

#232 Script failing in System Service executing DOS command

open
nobody
None
5
2018-03-28
2005-07-25
Anonymous
No

I have been using Regina for some time and I have
several scripts I use for automation purposes. They
were reycled on Saturday (the day prior to the actual
failures). This problem just started to appear once I
started running multiple Rexx scripts at the same time
and both fail at the same Rexx instruction:

parse PATH cmd with output stem quiet. error stem
error.

Any help will be greatly appreciated.
/eric EricBitterman@hotmail.com

Version
-------
Rexx REXX-Regina_3.3(MT) 5.00 25 Apr 2004
Windows Microsoft Windows 2000; 5.00.2195;
Service pack 4

Problem 01
----------
In this failure, the Rexx script is executing CURL.exe to
obtain the contents of
a specific web page. It will run for some time and then it
seems like all of a
sudden it fails.

The C:\Rexx\ChkWebPage\ChkWebPage.REX exec has
terminated with a SYNTAX error.

The error occurred on line 377 and the return code is 48
RC=48 Failure in system service
Line=377 address PATH page.!Cmd with output
stem quiet. error stem error.

Press the ENTER key to continue...

Problem 02
----------
In this example, the Rexx script is executing the
PING.exe command. It used to be able to run for long
periods of time. Now it is failing quicker and more often.
This problem started to occur when the program above
started to execute.

991 +++ address PATH Arg(1) with
OUTPUT STEM QUIET. ERROR STEM ERROR.
891 +++ pingRC = Quiet(pingCmd, 2)
699 +++ userList.server.!PingRC = Ping
(server)
487 +++ call DoServers
Error 48 running "C:\Rexx\Monitor\MonServers.REX",
line 991: Failure in system service
Error 48.920: Low-level stream I/O error: creating
reirection for error: Broken pipe

Discussion

  • Eric Bitterman

    Eric Bitterman - 2005-07-30

    Logged In: YES
    user_id=285926

    Is this problem going to be looked into?

    It now appears that other programs running using the same
    type of parse statement are failing as well.

    Is it recommended that I rewrite the code to not use
    the "parse <cmd> with ..." statement?

    Or is the solution to start using OREXX?

    thanks
    /eric

     
  • Eric Bitterman

    Eric Bitterman - 2005-08-10

    Logged In: YES
    user_id=285926

    I have to apologize, the command I meant to say was:

    address PATH <dos_cmd> with output stem quiet. error
    stem error.

    When more than one Regina script executes that type of
    instruction, one of them seems to fail.

     
  • Eric Bitterman

    Eric Bitterman - 2005-09-16

    Logged In: YES
    user_id=285926

    Hello ??? Any chance for some sort of response?

     
  • cniggeler

    cniggeler - 2018-03-28

    I have recently encountered this issue as well in Rexx 3.91. Running on Win 7 Pro. A WORKAROUND is described below.

    Like Eric, I use stems for both output and error, and like Eric, I run shell commands repeatedly - in this recent case, hundreds of iterations. Slight difference: I use "address command" rather than "address system" to avoid issues with escaped characters that occur with 'system' but not with 'command'.

    Anyway, running the entire command in a cmd.exe for loop 200 times, which took about 6 hours, I found this situation occurred 4 times, and not on any set frequency (27, 53, 58, and 200).

    WORKAROUND: call a subroutine that runs the "address" command with a trap on syntax, look for RC=48, sleep for 1 sec, and retry the same command one more time. This has worked for me! A short example may clarify; I use divide by 0 to force a syntax error to demonstrate:

    signal on syntax name err
    do i=1 to 4
       say i
       if i=3 then call trydiv
    end
    return
    
    trydiv:
       say 3/0
    return
    
    err:
       say "in syntax," SIGL RC
    return
    

    The output:

    1
    2
    3
    in syntax, 9 42
    4
    

    I am also running Resource Monitor and I do not see any uptick that would indicate a memory leak. Baseline before starting a sequence is 3.98GB in use; runs between 4.01-4.08GB while running; then returns to 3.98 GB.

    The fact that this workaround works would seem to be less of a resource issue (like memory) and more like a timing issue?

     

Log in to post a comment.