On Mon, Feb 13, 2017 at 10:58 AM, Paul Gilmartin <
0000000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Mon, 13 Feb 2017 09:44:51 -0600, John McKown wrote:
> >
> >> 3. Is it possible to have the Assembler routine place the extracted
> data into a unix
> >> pipe or a C type=memory file and then i can retrieve it ?
> >
> >You can call the UNIX BPX* routines from COBOL, so you can use something
> >like BPX1PIP to create an unnamed pipe. The COBOL program could then pass
> >the "write_file_descriptor" to the HLASM program as a parm. The COBOL
> >program would use BPX1RED to read from the read_file_descriptor. The HLASM
> >
> Is this better than using BPXWDYN('ALLOC ...') the descriptor and using
> conventional COBOL I/O)?
>
Better? Not really. Just different. And doesn't require a MKFIFO with
"random" name.
>
> >would use BPX1WRT to write to the passed in descriptor. But critically
> >important is that the HLASM program must be ATTACHX'd (BPX1ATM service can
> >do this) and not LINK'd to (as a normal COBOL CALL would do). Otherwise
> >
> 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.
>
> >you'll most likely get a lock out with either the TCB either waiting in
> the
> >COBOL code for the HLASM to write some thing, or in the HLASM code waiting
> >(buffer full) for the COBOL to read something. I just wanted to throw this
> >last in for completeness. You might also need some way to communicate to
> >the COBOL routine that the HLASM routine has written an "EOF" and has
> ended.
> >
> close() the input end of the pipe should suffice. COBOL should see EOF.
>
Ah. I hadn't thought of that. Thanks for the info.
>
>
> On Mon, 13 Feb 2017 16:45:33 +0100, Peter Hunkeler wrote:
> >
> >Any you'd need to run the Cobol and the assembler routine in parallel,
> not as main routine calling a subroutine. UNIX pipes need both ends to be
> acitve for them to work.
> >
> I've sometimes cheated on this, mostly with stderr, assuming that
> any error messages will fit in a 131KB buffer. Hard to handle both
> stdout and stderr otherwise in a Rexx parent. Is there a select()
> SYSCALL?
>
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. Mainly because the HLASM routine would not need to
"return" to the COBOL routine except at the very end. Otherwise, Scott
could just do a normal CALL to "get the next record" and have the HLASM
routine be able to "read next" the RACF information, which would mean
saving "positioning" information over the CALL. I also got the impression
that the HLASM and COBOL are pretty much already written at using a
"socket" type interface is mainly to eliminate the use of an intermediate
"disk file buffer". It would also enhance security some because the data
would never make it to a disk device, just memory.
I was also thinking of the COBOL program passing a record buffer address to
the HLASM program, then coordinating access to the buffer using a semaphone
(may require two?) (on == ready to read; off == ready to write), but that
looked a bit more difficult to me.
>
> -- 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
