LDW@USCMVSA.BITNET (Leonard D Woren) (06/01/89)
Moving large data areas to the end of the program is only a stopgap solution. Someday, the program will be modified again and it will be out of addressibility again, and there will not be a quick fix available. A better solution is to break up the code into subroutines, each with it's own local base register. You can then have one global base for common variables and small common service routines, and any number of local-based routines. My logon exit routine (for TSO) is 22 routines, almost 4000 lines of source, 20K of object, and only 2 base registers for code, plus one for the main workarea. No matter how big it gets, it will never need more than 2 code base registers. There is a savearea stack, and subroutine entry/ exit macros.
MICHAEL@MAINE.BITNET (Michael Johnson) (06/01/89)
While moving data areas to the end of the program MAY be only a stopgap
solution, it does have merit. It is a lot less work than reorganizing the
code entirely and will usually do the job nicely. Which isn't to say that your
solution isn't elegent, Leonard. It's a pretty standard way to write code for
large systems.
One problem that the solutions proposed so far have is that they generated
address constants. In release 6 of CMS this is not a problem at all, since
there are fully relocatable modules in R6. But for earlier releases, being
free of address constants can be important. You can avoid address constants
by coding something like this..
BASE CSECT ,
USING BASE,R12
.
.
L Rx,ADATA
ALR Rx,R12
.
.
ADATA DC AL4(DATA-BASE)
While this approach uses an extra two byte instruction, it has the advantage
of not generating a relocatable address constant. I've used this many times in
code that I wanted to be absolutely ADCON free.
Michael Johnson "We are the Priests of the Temples
University of Maine System of Syrinx. Our great computers fill
Computing and Data Processing Services the hallowed halls." - Neil Peart