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
