The everlasting problem of only 4K per base register


Every assembler programmer at some point in his/her career has made resolutions to do it (the base register assignment) different next time.

This is all very nice for your own programs. But what about these 3 or 4 (or more) programs that came as a heritage and must be kept running?

I have seen shops where for every new thing (feature..call it whatever you want) they had to remove another thing.

When IBM introduced relative and immediate feature (around 1985) I never thought of changing my habits and adapt to these new instructions.

My approach has changed.
I see the relative instructions as a great way to help the average shop (as well as the all assembler shops) out of the dilemma of maintaining code which was constructed the wrong way to start with and are in no position to restructure it from scratch.

Solution.
With a minor modification to the intro/prolog of your code as shown below and IBMs COPY IEABRC all branch instructions (RS types only) are changed to relative branch instructions.
The relative instructions cover a range of 64K before and 64K after the instruction (that is 16 base regs).
The saveage is in reduction of base registers for the code. If you only need one base for the code and 3 for the data there is not much you can gain.

And the poor VSE shop.
Until IBM gets the magic round toit, I decided to undig a piece of code I wrote in October 2002 (and forgot about it). It does work different (and of course better) that IBMs tool. My solution consists of
  1. a SETCF function which is cataloged as part of the install.
  2. a COPY book, which is cataloged as part of the install. 
This method works in z/OS as well and I am willing to pass on code for MVS as well, if someone does not want to use IEABRC. I know that Roland Schiradin did do parts of SHOWMVS with it.

Code change.
The prolog of a program has to be adopted. Same is true for the beginning of your definitions. You can vary what and how you do it. Here is what I do:

after saving registers 
    BALR  R3,0
    AHI   R3,BASE_COVERED-*
    USING BASE_COVERED,R3
after all your code in front of the data-definitions I insert (and move the LTORG)
BASE_COVERED  DS  0D
    LTORG
rest of data definitions goes here

Other problems.
Yes there are a few. But nothing that can not be solved. The most annoying I found (in other peoples programs) is the use (and incorrect use) of flags in instructions (NOP/B).

Another thing is macros with inline data. Mostly there are versions for RENT coding. This does fix it in most of the cases.

There are macros, that do not play well in  an area without a base (they NEED a base register or their operands do). If you can make it a case, report it to IBM. Here is what I have collected so far from you. You may notice that these are only VSE. The simple reason is: there is a commitment in the "other" op-sys to fix problems becaus of lack of base register coverage asap.
  Contact me if you have an addition (or a removal).
1 CALL (V-const is generated in code instead of using a literal)
1 EOJ (name of phase to load is inline instead of a literal)
0 LIBRDCB (the adress of EODAD, NOTFND, ERRAD, and SRVEXIT can only be specified as registers)
1 AMODESW (the adress of label for going high/low is loaded with LA)
1 GETVCE (althru MFG is possible it does not fix the problem of adressability)
1 DUMP (as in EOJ and) ICM 15,8,* to load a negative value to R15 (!!!!)
1 STORAGE OBTAIN - simple solution would be a JAS 15,label and then L 15,0(,15) in place of a B (or copy from z/OS)

Circumvention till code is fixed:
1= temporary addressablity is needed
0= Circumvention is in text

Outlook Extra info.
I did during WAVV 2008 and 2007 have a session on this very subject.
The material used in these sessions is here. Can be used to convince co-workers "et al" of the advantage of converting one or the other program to "no base for the code" method.
Also: modifieng a pgm without doing anything for the init-coding could easy reveal SIIS-problems (since modification to the code is no longer easy).
Flip-chart & DEMO-program & switch-macros

While this is fairly neutral op-sys-wise, "Jumpify_Your_Code_2011.pdf" was the title of a more z/OS-centric presentation on the same topic. May want to find the Author: Edward Jaffe.
Excellent presentation even without Edward Jaffe (the speaker) (as opposed to my material above).

If you have any question feel free to contact me.