On Sun, 01 Jul 2012 18:22:22 -0400, Edward Jaffe <edja...@phoenixsoftware.com>
wrote:
Storage for all data areas and control blocks can be backed above the 2 GB bar
even if your program is running in 24-bit mode. This means that you can code
either of the following:
* LOC=(BELOW,ANY)
* LOC=(BELOW,64)
on the GETMAIN or STORAGE macro.
Recommendation: Code the second value as 64.
Note: Code LOC=(BELOW,ANY) or LOC=(BELOW,24) when using tape devices
that do not support 64-bit IDAWs.
This recommendation assumes the AMODE(24)/RMODE(24) program is coded using
re-entrant programming techniques and is actively being maintained by someone
with enough "smarts" to seek out all eligible GETMAINs, specify a backing
location other than the default, and test to be sure everything works as
expected. Note that many older programs are not re-entrant and have no control
over the backing of the storage into which they are loaded. (The system has no
choice but to use 24-bit backing.)
Ed,
Sorry but I don't understand what re-entrancy has to do with how storage is
backed.
Care to explain?
Also, I assume by "have no control over the backing of storage" you meant that
most older programs don't specify the required backing for their GETMAIN? That's
probably true, but my assertion was that it's a trivial low-risk change to even
older programs to add a 64 as the second value of a LOC in all GETMAINs as the
"DFSMS Macro Instructions for Data Sets" recommends. For those with no LOC
parameter,
specify LOC=(RES,64).
As far as requiring "smarts" to see out eligible GETMAINs, my point was that it
shouldn't require any. Heck, even I was able to change all our storage
allocations
years ago to use 64-bit backing and haven't ever had a problem resulting from
that. I can assure you that I don't have the smarts to look for eligible
GETMAINs
as I wouldn't even know what to look for. What would I look for?
The only thing I can think of is looking for stuff that uses real addresses or
that uses services that use real addresses. And I'm painfully aware of the
minute
quatity of code we have that does that, as would, I think/hope, anyone else that
had such code.
In any case, my not particularly original recommendation was simply a response
to
concerns about real 24-bit (and 31-bit, while we're at it) storage. I simply
proposed
what I feel is a very low-risk, low-impact way of addressing such concerns. If
you're
not worried about real 24-bit storage then you shouldn't bother. If you're
looking
for absolutely no-risk solutions, I wish you luck.
But, as we all know, there are plenty of sites that don't actively or even
reactively
maintain anything. If something breaks, a lot of effort is expended to work
around
the problem rather than fixing it. Fortunately, IBM's (and most mainframe
vendors)
dedication to backward compatibility, ensure that old stuff rarely breaks. But,
*any* recommendations that involve code changes are obviously going to be
ignored
at sites in lights out mode.
--
Cheers,
Alex Kodat
Sirius Software
