That is the correct behavior. If you are doing the output to a stream
object directly rather than using the STREAM resource (or USING with a
.File object), the stream is neither opened nor closed during the
processing. In fact, an OutputStream object need not support a close
method, so it would be wrong to attempt it.
Rick
On Wed, Apr 25, 2018 at 2:15 PM, Gil Barmwater <gbarmwa...@alum.rpi.edu>
wrote:
> All of the builds I have attempted were Windows REL32 but I've never
> experienced a hang at CreateProcess(). FWIW.
>
> I do have a question about a problem I'm seeing, however. The scenario is
> as follows: I've modified the test bed I wrote for the package I presented
> at the Symposium so it would run ADDRESS ... WITH commands instead. All of
> my tests run except when I run two particular tests consecutively. Each
> test runs fine standalone. Both tests use a file called 'abc1.txt' which
> contains 4 lines of rexx instructions, the last being 'exit'. The first
> test issues <address cmd rexx rexxtry with input using (smallFile)>, having
> first done <smallFile = .stream~new('abc1.txt')>. In other words,
> redirecting Input to a stream object. That works as expected. The second
> test issues <address cmd rexx abc1.txt with ...> . When run alone, it too,
> works as expected but if run immediately after the first test, it gets
> <Error 3.1: Failure during initialization: File
> "C:\Rexx\projects\addresswith\abc1.txt" is unreadable.> Suspecting the
> file may not have been closed by the first test, I added a
> <smallFile~close> immediately after the address ... with in that test and
> that fixed the problem. I attempted to find where the input stream object
> was processed in the C++ code but got lost <blush>. Any suggestions would
> be appreciated.
>
> BTW, I saw all the work that has gone into the address.testgroup and was
> very impressed! Nice work!
> Gil
>
> On 4/25/2018 12:40 PM, Erich Steinböck wrote:
>
> Erich will have to speak for the other platforms
>>
>
> Unix should be fine. I just noticed that somehow the latest commit,
> fixing the environment for spawn, didn't come through - did the commit now.
>
> For Windows there may still be work ahead. For me the new
> ADDRESS.testGroup doesn't run.
> But then I do have a very strange issue with addressWith Debug builds:
> each time a new rexx.exe is built, it will hang for a full minute (60
> seconds exactly) at CreateProcess() in the command handler (for any
> arbitrary command) before continuing. This may repeat two or three times,
> until it starts behaving normally again (no delay by CreateProcess). The
> issue will reappear as soon as I build a new version.
> This issue doesn't happen for Debug builds of trunk, and I've never
> witnessed it before.
> I treid swapping back the old command handler (all other Rick's changes
> still in place), but even then the issue is still there.
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> Oorexx-devel mailing
> listOorexx-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
> --
> Gil Barmwater
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
