On Mon, Mar 16, 2015 at 10:03 AM, Walt Farrell <[email protected]> wrote:
> Using fork() is not a problem, John, and has long been recommended as one
> separation mechanism that would allow safer mixing of APF and non-APF
> programs.
>
> The DDs will be the big problem, especially (as in Charles's case) where he's
> invoking a program he does not control. That program will expect the DDs to
> be allocated locally, and will expect to use typical MVS I/O macros to access
> > them.
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.
>
> Having the child process DYNALLOC the data sets can work, with some effort as
> you mentioned, but only if they can be allocated with DISP=SHR. Any
> requirement for DISP=MOD or OLD will require that the DDs remain solely
> allocated to the parent process. Of course, the parent could deallocate the
> DDs, but that will only work if they're not needed in a subsequent jobstep or
> by the parent process itself, later.
Right, and is more of a PITA if the job is using something like CA-11.
Or, even worse, data set triggering in CA-7.
>
> --
> Walt
>
--
If you sent twitter messages while exploring, are you on a textpedition?
He's about as useful as a wax frying pan.
10 to the 12th power microphones = 1 Megaphone
Maranatha! <><
John McKown
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
