DOS/360 had:
- typically 32K or 64K core
- no R15 = EP, no R14 = ret.addr no R13 = SA
- right or wrong, I remember R0 or R1 for UPSI switches
- no program relocation at LOAD time
- LE resolved A(..) to real addresses of either the BG, P1 or P2 (fixed
size) partition
The code you show was made self-relocating and looks "adapted" rather
than properly converted.
IMHO it wasn't an "early OS/360" which had PARM-field replacing UPSI and
R15-R1 Convention.
Andreas Geissbuehler
On 2017-03-11 07:52, Tony Thigpen wrote:
I am working on some REALLY old code. Some of the code has dates back
in 1967! The oldest date found is 5/9/67.
This code is still running daily. That's as good as 50 years later.
The only reason we are touching the code is because we are migrating
this application from z/VSE to z/OS.
I don't know the original operating system, but I expect it was
DOS/360. But, it could have been an early OS/360.
Anyway, I am seeing some code that am interested to know about,
historically.
For instance, it appears that USING could not support multiple
registers. I see this code sequence in the 'start' macro:
USING *,3 ESTABLISH REG 3
USING *+4095,4 AND REG 4
USING *+2*4095,5 AND REG 5 AS BASE REGS
Also, it appears that R15 was not standardized to have the programs
entry address because they used:
&NAME BALR 3,0 INITALIZE REG 3
LA 3,0(3)
BCTR 3,0
BCTR 3,0
LA 4,4095(3) AND REG 4
LA 5,4095(4) AND REG 5
(FYI: The above code snippets were contiguous.)
Also, when they needed to call a subroutine, it appears they did not
yet have =A(xxx) constants, because they had to manually adjust the
address:
L 15,=V(UPSI) LOAD REG 15 WITH UPSI ROUTINE ADDRESS
AR 15,3 ADD RELOCATION FACTIR FROM REG 3
BAL 14,4(15) BRANCH TO UPSI RETURN IN REG 14
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
