On Mon, Feb 13, 2017 at 11:51 AM, Paul Gilmartin <
0000000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Mon, 13 Feb 2017 11:32:36 -0600, John McKown wrote:
> >
> >
> <snip>
>
> >
> I was thinking of BPX1PIP and BPXWDYN( "alloc path('/dev/fd/[pipe
> output]') ..." ).
> No generated pathname.
>
Ah. I hadn't thought of that. An interesting idea, but having already used
a UNIX subroutine, I guess I figured it was easier to use another UNIX
subroutine rather that setting up an FD along with an OPEN / READ loop /
CLOSE.
>
> >> Does BPX1ATM dup() descriptors as spawn() does? If so the parent must
> >> close() its copy of the input descriptor or it never sees EOF. Happens
> to
> >> me all the time.
> >
> >BPX1ATM is "attach_and_exec_mvs", which basically seems, to me, to be a
> >wrapper around the ATTACHX function. So the HLASM program is a subtask of
> >the COBOL program.
> >
> I take that as "doesn't dup()."
>
Right, I should have said that explicitly. Why would it? What use would a
dup() serve? Both tasks (aka "threads") are running in the same UNIX
process and so (should?) have access to all of that process' file
descriptors.
>
> >There is a BPX1SEL (
> >https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.
> 0/com.ibm.zos.v2r1.bpxb100/sel.htm?view=kc
> >) which I guess could be used. But, at least to me, using the BPX1ATM is
> >conceptually easier. ...
> >
> You need something like select() if you want to monitor multiple
> input streams, such as stdout and stderr from a child process.
>
Yes, but that is not the case here. I think that the HLASM is basically
being used as a "QSAM for RACF" type interface.
>
> -- gil
>
>
--
Our calculus classes are an integral part of your education.
Maranatha! <><
John McKown
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
