I talked to the author of the code.
1) The original program that this code was coded within actually was a
glue phase that replaced a vendor provided phase that was always called
using an api macro provided by the vendor to the customer.
2) At one point, the vendor was 24bit, but later changed to 31bit. Also,
the vendor changed from BALR to BASSM (with a short use of BSM during
one intermediate update).
3) This glue phase has always calling additional modules using BASSM and
those modules were always 31bit.
4) The original vendor macro was used in a lot of programs and they did
not want to recompile everything every time the vendor changed the api
macro. So, the glue code had to handle a lot of quarks in how it was called.
So, the glue phase had to handle the following situations over several
releases of the vendor product:
1) 24bit using BALR
2) 31bit using BALR
3) 31bit using BSM
4) 31bit using BASSM
Eventually, his special entry macro was used by others even when they
did not need the special functionality.
Tony Thigpen
Martin Truebner wrote on 8/12/20 5:15 AM:
Binjamin,
your sequence
LA 14,0(,14) Fix-up address (in case 24 bit)
BSM 14,0 Now BSM 0,14 will restore the current amode
Will clear the amode-bit and BSM will set to that mode (0=24) and go
there.
If you are very lucky you are never called in 31 bit mode then the code
will not do any harm
If you are called in 31 bit mode then you could be lucky and the
truncated address is nonsense in 24 bit mode- but ....
--
Martin Trübner; everything around "PoOps of z/arch"
Teichstraße 39E
D-63225 Langen
F: +49 6103 71254
M: +49 171 850 7132
E: [email protected]
