Hi Dave, Since you are considering an XDCUSS(A) suite, I presume they will of necessity be LE POSIX(ON) programs, so the LE function ceebenv() function documented in the LE Vendor Interfaces manual should be available to assembler code to interrogate the environment variables.
I also remember seeing comments (possibly in the Vendor Interfaces manual) that the environment array may have its address in the CAA somewhere, or reachable from the CAA at any rate, and if your code doesn’t always have the CAA address at hand there is also an assembler interface to get the CAA address which is documented in either the Vendor Interfaces manual or in the normal LE reference manual. HTH Peter From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of David Cole Sent: Thursday, October 5, 2023 6:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Assembler access to USS functions Hi Jon, Hi Peter, I must say, your insights have been quite helpful. Thank you! Jon, You raise a good point. I neglected to say why I wanted to get at the environment variables. Ok, here's why... Classic z/XDC uses keyword ddnames as a very easy way to pass a fair number of processing settings into z/XDC. It's easy for the user to use, and it's super easy for z/XDC to find. We are considering writing a XDCUSS[A] analog to XDCCALL[A], and we'd like to continue using the keyword ddname approach for passing settings into z/XDC. * However, my developer says that's not feasible, so I'm looking for alternative approaches. * To my naive mind, it seems to me that environmental variables could be such an alternative. * However, my developer says that environmental variables, while available to C programs, are unavailable to assembler. * I find that astonishing. My developer has had little prior experience with USS; however, he is an extraordinarily quick study, and has assimilated a lot of knowledge in a very short time. Nevertheless, I thought I'd appeal to the broader community in the hopes of learning what more experienced minds have to say. So our initial goal is to use environment variables for z/XDC's internal control purposes. But once that is accomplished, the broader purpose of providing displays to the user will probably be undertaken. Dave At 10/5/2023 02:22 AM, Jon Perryman wrote: >On Thu, 5 Oct 2023 05:46:48 +0000, Farley, Peter ><peter.far...@broadridge.com> wrote: > > >Why does any programmer need to care where the environment > variables are stored? > >Normally, I would agree but XDC is a very special case with very >broad requirements. As a full z/OS system debugger, Dave Cole has >many requirements that are atypical. E.g. does he want the ability >to display environment variables from all processes instead of just >the process being debugged? He also has restrictions such as >debugging SRB, SVC, PC routines and more. More than likely, he >doesn't want to use SRB's & IRB's to gather the data when access >registers are simpler. > -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN