On Monday, December 06, 2004, at 08:40PM, Sampath Ravindhran <[EMAIL
PROTECTED]> wrote:
>
>I have an application that spawns a detached process to run a Perl
>script, within which it expects to read a bunch of lines from STDIN. To
>do this, I have a simple construct like
>-----------
>while (<STDIN>)
>{
> $myline = $_;
> (process my input line...)
>}
>------------
>
>Before calling the perl script in the detached process, I define
>sys$input to the mailbox device the parent had created.
>
>When the parent process writes text lines into the mailbox, I find that
>the detached process *does* receive them. After writing the necessary
>lines, I send an EOF character (decimal 26) to the mailbox expecting it
>to terminate read from STDIN and proceed further with the execution of
>the Perl script. However, that doesn't happen and the Perl execution
>remains in this while loop forever. Closing the channel of the mailbox
>after the write operation is not a desirable option at this point
It sounds like what you need is the equivalent of decc$write_eof_to mailbox.
See
http://h71000.www7.hp.com/doc/732FINAL/5763/5763pro_027.html#decc_write_eof_mbx__sec
Since I don't know how that's implemented, I don't know if you could just wrap
some XS around it and make it callable from Perl. But it's also not clear to
me in your example if the parent process is in Perl or something else. If it's
in C, give the above a try and see if it works. I suspect it's just doing a
special $QIO to the mailbox channel in a way that bypasses interpretation of
the EOF character by the CRTL writes. If the parent is in Perl, you could also
try calling VMS::Stdio::binmode on the filehandle before sending the EOF
character. I really have no idea whether that will work, but it's something to
try.
