On Wed, 7 Dec 2016 16:22:26 -0500, Phil Smith III wrote: > >It's an API, called via the COBOL "CALL" verb or equivalent. The code it >calls runs the TIOT, and if it finds a particular DD, it behaves >differently. Yes, we could use an environment variable, but that isn't what >it does now. > If you can invoke your COBOL wrapper from shell, just do that.
If you can't, you need a different wrapper. I suggest > > >The question arose (internally): "If I run a (probably C) program from USS >that calls the API, can I define this optional DD from the calling >environment?" (like, that's the point of the DD-that it's an externally >defined thing, not requiring a change to the actual program). It looks like >BPXWDYN will do it from Rexx, but-that isn't usable from a shell script? >Your earlier post implied that. > You can call a Rexx EXEC from shell. chmod it executable and put it in PATH. It can create a DD with BPXWDYN (which works from shell, TSO, IRXJCL, probably others). The EXEC can invoke your API or the COBOL wrapper with address LINKMVS. If you're shell-timid, test it under IRXJCL; TSO may give capabilities unavailable under shell. The Rexx EXEC may (but isn't guaranteed to) run in a separate address space, so any allocations it performs with BPXWDYN or otherwise are FREEd when it exits. I exploit this, lazily, by not FREEing in Rexx under shell. Sometimes it's frustrating that those allocations are unavailable in the parent environment. (I'll leave discussion of _BPX_SHAREAS=MUST for later.) Are you using your DD only as a flag, or do you actually do I/O to it? As long as your program doesn't do TSO RECEIVE you're probably OK. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
