Not TSO/E rather just plain old TSO. Not HLASM rather its predecessor Assembler F (IFOX00). Still, if you get the hang of the 1970s version, the 2020s version is just adding stuff. And some of the stuff it is adding is less unfamiliar (like Unix and Java)
About the only thing that's truly limiting about using such an old release of MVS is the 24-bit addressing and maybe the older pre-XA I/O architecture.
Having a simulated 3033 running at 10+ MIPS is pretty nice though. (:
> About the only thing that's truly limiting about using such an old release of MVS is the 24-bit addressing
I've never used it, but there's a hacked up version that adds 31-bit addressing [0].
It is truly a hack though – porting 24-bit MVS to XA is a monumental task, not primarily due to address mode (you can always ignore new processor modes, just like how a 286-only OS will happily run on a 386 without realising it is doing so), but rather due to the fundamental incompatibility in the IO architecture.
The "proper" way to do it would be to have some kind of hypervisor which translates 370 IO operations to XA – which already exists, and has so for decades, it is called VM/XA, but sadly under IBM copyright restrictions just like MVS/XA is. I suppose someone could always write their own mini-hypervisor that did this, but the set of people with the time, inclination and necessary skills is approximately (if not exactly) zero.
So instead the hacky approach is to modify Hercules to invent a new hybrid "S/380" architecture which combines XA addressing with 370 IO. Given it never physically existed, I doubt Hercules will ever agree to upstream it.
Also, IIRC, it doesn't implement memory protection/etc for above-the-line addresses, making "MVS/380" essentially a single-tasking OS as far as 31-bit code goes. But the primary reason for its existence is that GCC can't compile itself under 24-bit since doing so consumes too much memory, and for that limited purpose you'd likely only ever run one program at a time anyway.
I guess the other way of solving the problem would been to have modify GCC to do application-level swapping to disk - which is what a lot of historical compilers did to fit big compiles into limited memory. But I guess making those kinds of radical changes to GCC is too much work for a hobby. Or pick a different compiler altogether – GCC was designed from the beginning for 32-bit machines, and probably alternatives would go better in very limited memory – but people had already implemented 370 code generation for GCC (contemporary GCC supports 64-bit and 31-bit; I don't think contemporary mainline GCC supports 24-bit code generation any more, but people use an old version or branch which did.) I wonder about OpenWatcom, since that's originally a 370 compiler, and I believe the 370 code generator is still in the source tree, although I'm not sure if anybody has tried to use it.
Yeah, I've wondered what the lift would be to backport XA I/O to MVS 3.8j, among other things, but given that it's a pretty pervasive change to the system, I'm not surprised to learn that it's pretty heavy.
To your note about a hypervisor though: I did consider going this route. I already find VM/370 something of a more useful system anyway, and having my own VM/XA of sorts is an entertaining prospect.
It arguably doesn't require anything as remotely complex/feature-rich as full VM/XA: it wouldn't need to support multiple virtual machines, or complicated I/O virtualisation.
Primarily just intercept SIO/etc instructions, and replace them with the XA equivalent.
Another idea that comes to mind: you could locate the I/O instructions in MVS 3.8J and patch them over with branches to some new "I/O translation" module. The problem I think with that, is while the majority of IO goes through a few central places in the code (IOS invoked via SVC call made by EXCP), there's I/O instructions splattered everywhere in less central parts of the system (VTAM, TCAM, utilities, etc).
I leaned into the "well, what if my own VM/XA" because, uh, VM/CMS has the odd distinction among IBM's operating systems of the era of being both (1) source available and (2) site-assemblable. I've gone through my fair share of CMS and CP generations, which felt like a more complete rebuild of those nuclei than the MVS sysgens I've done.
That there makes me feel a little less confident in an MVS 3.8j patching effort.
Not TSO/E rather just plain old TSO. Not HLASM rather its predecessor Assembler F (IFOX00). Still, if you get the hang of the 1970s version, the 2020s version is just adding stuff. And some of the stuff it is adding is less unfamiliar (like Unix and Java)