IBM's Language Environment (LE) is doing it exactly this way.
R13 points always to the savearea and after the savearea comes
the dynamic storage needed. So there is no need to have two regs,
one for the savearea and one for the dynamic storage. But by the
way, LE needs R12 for the common anchor area (CAA).
Tobias
Am 09.08.2010, 19:46 Uhr, schrieb Charles Mills <[email protected]>:
I think John may be speaking of the convention in which one GETMAINs a
large
area to be used (1) as an R13 savearea for called programs and (2) the
area
beyond the standard savearea is used for "automatic" variables. There is
a
risk if called programs use more storage than expected and the area
so-used
extends into the program's variables.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf
Of Walt Farrell
Sent: Friday, August 06, 2010 9:08 AM
To: [email protected]
Subject: Re: linkage conventions
On Fri, 6 Aug 2010 01:30:56 +0000, john gilmore <[email protected]>
wrote:
There is a sense in which all is now clear (or at least very much
clearer).
The exchanges between Tom Marchant and Peter Relson were very helpful.
What remains is probably intractable, but I find
. . . B can never determine. B documents its requirements and assumes
that
its caller has met these requirements . . .
curiously unsatisfying.
How and, in particular, where B is to document its requirements is left
up
in the air. All will be well until
there is an error of substance or a documentation lag, and then . . .
My practice---It is habitual in much compiled code too---of supplying
myself with LIFO scratch storage by
enlarging DSAs will make my code particularly vulnerable to such errors.
We shall all come to regret this state of affairs, but when I think
about
how to proceed differently nothing
useful occurs to me. The problem is easy to state: DSAs of too many
different sizes are now required in
subtly different circumstances; but they may well be practically
inescapable.
This discussion has been about standard z/OS linkage conventions, where
the
caller provides a savearea and the called program is responsible for
allocating its own dynamic storage by its own means.
Presumably you know whom you're calling, and from their documentation you
know what size savearea each of them requires you to allocate. And you
allocate a savearea large enough to satisfy the maximum required by
anyone
you are calling.
If you're worried that you might not have the latest documentation, and
thus
someone may require something larger, why not just start modifying your
programs so you always allocate the maximum size currently documented in
the
z/OS linkage conventions? Then you can call anyone.
I'm not quite sure what you're talking about here, John, but it seems you
might be talking about some other linkage convention, where the caller
provides all the dynamic storage needed by the called program, and if so
that's something very different. Yes, in that case, the called program
might
need a way to figure out how much storage it had been given, but that's
not
what we've been discussing.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
