On Thu, 8 Dec 2016 09:27:05 -0500, Phil Smith III wrote: > >.we don't want to switch from the DD DUMMY to environment variables >globally, because there are too many customer programs out there, right. So >yes, a Rexx wrapper is likely the answer. Adding the environment variable >check would also be possible, but since There Can Be Only One, and we don't >want the overhead of the getenv() in every case (running the TIOT is cheap), >we'd probably have to take the "If no DD DUMMY, *then* do the getenv()", but >that will still have impact on the many cases that don't need any such >setting. > How does the cost of running the TIOT compare to getenv()? Really? Has anyone measured it? And you needn't call getenv(); you can run the environment passed as a parameter to the program.
One can tweak the requirement to make a solution easier, harder, or impossible: Suppose your user's program invokes a subroutine with fork() (BPX4EXC), and that subroutine invokes your API. DDs are not passed through fork(). And which, if any, environment variables are passed in the argument to fork() is at the caller's discretion. In the absurd extreme, suppose your user's program exists as stored JCL, submitted with the TSO SUBMIT command, and your user is unwilling to modify that JCL, and you'd like to allocate your DD in the TSO session and have it available in the batch job. Can't. --gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
