Why does any programmer need to care where the environment variables are stored? As long as they are stored such that they “. . . become part of the environment” and that “. . . altering the string shall change the environment”, why would one care where they are in storage? It just makes no sense to me to concern oneself where they are stored.
If anyone wants the non-standard storage behavior from pre-z/OS V1R2, they can choose to use the C putenv() function to which you pointed that says it recognizes and responds to that environment variable instead of using the assembler-callable LE ceebenv() function to which I pointed. The link you provided to the C function putenv() is NOT the same as the LE ceebenv() function to which I pointed. In fact, I would guess that the C putenv() function probably USES the function to which I pointed to perform its task. I am sorry to say that your comments so far appear merely pedantic to me, and in particular not very useful to the OP. If there is a substantive reason for the OP to care about these kinds of details, please elaborate. Peter From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Paul Gilmartin Sent: Wednesday, October 4, 2023 2:27 PM To: [email protected] Subject: Re: Assembler access to USS functions On Wed, 4 Oct 2023 16:06:38 +0000, Farley, Peter wrote: >Perform setenv(). Adds, changes, or deletes an environment variable in the >environment list. > >OK, it says “set” env not “put” env. Semantics appear the same. > No. Single Unix says: <https://pubs.opengroup.org/onlinepubs/9699919799/functions/putenv.html*tag_16_466_03> ..., the string pointed to by string shall become part of the environment, so altering the string shall change the environment. And OMvS says (less clearly, IMO): <https://www.ibm.com/docs/en/zos/2.2.0?topic=functions-putenv-change-add-environment-variable> Note: Starting with, z/OS® V1R2, the storage used to define the environment variable pointed to by envvar is added to the array of environment variables. This is not true for setenv(), which makes a copy of the value. >That environment variable _EDC_PUTENV_COPY seems intended to permit an >obsolete storage location (pre-z/OS V1R2 it says) for environment variables. >Why would you want that? > IBM provided the option for users who had come to depend on the non-standard behavior, which they considered more intuitive. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
