Paul Gilmartin wrote: >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.
OK, I admit I haven't measured it. Not sure what "run the environment" means, please elaborate? >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. Well that's an interesting point. So neither the DD nor the environment variable approach is necessarily the right choice here. In such a case, they'd have to specify the choice in the API call. >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. Again, if they don't want to modify the JCL, then they can specify it in the API call. Not clear to me how an environment variable is easier to set than a DD for a submitted job, though. Are you saying that TSO SUBMIT carries environment variables from the TSO session into submitted jobs? That would surprise me (pleasantly)! This is all a theoretical problem at this point, BTW -nobody has raised this with us; I'm just trying to think it through in advance. As everyone is all too aware, consciously doing USS-ish things is sadly rare in the real world,. Hey, it's only been, what, 20 years? Stuff takes time to catch on. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
