On Mon, 16 Mar 2015 10:24:02 -0500, John McKown wrote:
>>
>> The DDs will be the big problem, ...
>
>Right. That is the real problem. Of course, what _might / could_ be
>done is to use pipes. On the parent side, for each DD, create an
>unnamed pipe. Use a structure to logically associate a pipe fd with a
>DD. Pass this information to the child. The child then dynamically
>allocates a DD to /dev/fd{n} where {n} is the pipe fd number. The
>"other program" invoked by the child driver does an OPEN on the DD and
>[BQ]SAM I/O. This actually does I/O to the associated pipe fd. When
>the child does this I/O to the pipe, the parent "knows" (because it
>has set itself up properly) that I/O has occurred on the pipe and it
>does the appropriate I/O to the associated DD on the parent side. This
>is, kind of, what I think that Co:Z data set pipes does to access DD
>statements in their UNIX utilities.
>
I suspect that BPXWUNIX does something similar. FILEDATA(RECORD)
makes this more practical than in days of yore, but a UNIX program
must be alerted to expect it if it's not allocated to a DD on both ends.
And while it _might / could_ work for PS data sets, the user is SoL if
he tries it on a library, I suspect.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
