On Mon, Apr 17, 2017 at 2:46 PM, Paul Gilmartin <
0000000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Mon, 17 Apr 2017 14:07:25 -0500, John McKown wrote:
> >
> >But I was wondering what other EXEC ??? pre-processor might be created if
> >IBM were to release (or just license under NDA) this interface. What was I
> >thinking of? Well, maybe an EXEC UNIX or maybe call it EXEC SYSCALL (to
> >match REXX SYSCALL), to more tightly integrate some UNIX facilities into
> >COBOL. Not that I'm disparaging the excellent BPXUNIX() subroutine which
> >can be used. I just think that something like:
> >
> >EXEC UNIX Z'cd ~/junk'
> >
> >is easier to understand than:
> >
> >CALL "BPXUNIX" USING Z"cd ~/junk"
> >
> Note that either of these would do a chdir() in a separate subshell,
> not affecting the caller's current working directory.
>
OK, thanks for reminding me that BPXWUNIX() runs in a separate shell. I
just plain forgot. But I don't understand you saying "either of these". How
can you say that about EXEC UNIX when you don't know the implementation
used for the non-existent EXEC UNIX co-processor? I will agree say that
implementing the EXEC UNIX would be a "bother" since it would need to know
to map the "cd" command into a call to BPX1CHD. Along with all the other
shell "built in" commands.
>
> I have a simple Rexx EXEC which does tilde substitution then SYSCALL chdir.
> If called as a TSO comand it changes the current working directory for the
> rest of the session, for better or for worse. Authors of Rexx EXECS should
> not assume that in the TSO environment CWD is guaranteed to be HOME.
>
> >or, hardest to understand, but "best" for diagnostic use (and what the
> EXEC
> >UNIX might actually do):
> >
> >77 CHDIR PIC X(100) VALUE Z'cd ~/junk'.
> >77 CHDIR-LEN PIC S9(9) BINARY VALUE +9.
> >...
> >CALL BPX1CHD USING CHDIR, CHDIR-LEN, RETURN_VALUE, RETURN_CODE,
> REASON_CODE.
> >
> Might the existing Rexx SYSCALL API be invoked other than from Rexx?
> Might not be very useful since so many SYSCALLs depend on the Rexx
> variable pool.
>
Now that is a very interesting idea. It would make implementing an EXEC
SYSCALL (vice EXEC UNIX) much easier! Perhaps something could be done by
using IRXINIT to initialize a REXX environment. Of course, I guess one
could argue that everything which could be done in this environment could
be done with a CALL instruction.
EXEC SYSCALL Z'cd ~/junk'
could be implemented almost as well by doing:
CALL SYSCALL USING Z'cd ~/junk' SYSCALL-RESULTS.
Where SYSCALL-RESULTS could look something like:
01 SYSCALL-RESULTS.
05 RETURN-VALUE PIC S9(9) BINARY.
05 RETURN-CODE PIC S9(9) BINARY.
05 RETURN-CODE PIC S(9) BINARY
I may not have been accurate enough in my thoughs on the EXEC UNIX (which,
as I feared, has become the focal point of the discussion as opposed to the
"opening up" of the EXEC co-processor API). It was just meant as a general
thought of something that could be done via another co-processor for the
EXEC verb.
>
> -- gil
>
>
--
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion
Maranatha! <><
John McKown
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
