OSDev.org

I see mainframes getting no love on the OSDev scene, very scarce number of OSes made by hobbysts for mainframes.

So I decided to give mainframe some love

Fully Public domain so other people can also give it some love:
https://github.com/SuperLeaf1995/uDOS

Try it out! (You'll need Hercules):
https://github.com/SuperLeaf1995/uDOS/releases

Then simply run it with:

Nice! What kind of mainframe does it run on?

I admit I don't often think of mainframes when I think of OS dev, but sometimes I do get a hankering for a wall of technology, preferably with spinning tape drives, and old-style terminals. Or maybe that one minicomputer with a chrome cabinet monitor and keyboard. I just don't have anywhere to put one.

Somewhat like that!, but add 64-bits and the "modern" stuff

It runs on z/Arch (the modern mainframe, big blocks with no funny spinning drives or retro terminals), and on the s/390 (the one with the funny terminals & spinning disks).



Awww , that's unfortunate. But understandable since the only hobby OSes for mainframes are:
- ZZSA, which is some sort of recovery disk intended to rescue MVS3.8j systems?
- uDOS
- PDOS
- z/Linux, if you call that hobby
That's it, that's the whole mainframe scene, so yeah.

Pretty much a given, seeing that physical hardware has never been really accessible to hobbyists, and that emulators that would run on hobbyist-accessible hardware didn't really become available until mainframes were pretty much irrelevant by number of units shipped.

Though I probably would count academically-developed OS as "hobby" OSes at the mainframe scale: Among buyers that can afford mainframe hardware, academic institutions (and specifically the faculty and students of their CS departments) are the closest thing to "hobbyists" that you'll find. So that would include things like MTS (on IBM) and ITS (on the PDP-10, which is sometimes classified as a mainframe rather than a mini). Still not a lot of "hobby" OSes as the market was never very big.

I'd really like to see a hobby, or otherwise source-available OS for z/Archictecture that makes use of the access register feature of the architecture, given that it's a feature that exists pretty much nowhere else. z/Linux goes with the Unix flat address space paradigm, z/OS is not made available to hobbyist users running hercules, MTS / MVS / VM/370 etc. date back to before ESA/390 (or, in the case of late versions of MVS, is not available to hobbyist users).

MVS 3.8j and PDOS offers those features

I thought the sufficiently late versions of MVS were not hobbyist available?

Oh yeah my bad, sorry, in such a case z/PDOS is the only MVS-like OS for the mainframe right now that runs on modern machines (it does not replicate z/OS).

Ah, fun!

@linguofreak: Relevance isn't a consideration for every OS dev, but yeah, the rarity of mainframes must have a lot to do with it. The few hobbyists who have one are likely to be into retrocomputing and want to run the old OSs, so when it comes to new software, 2 new OSs, 1 port and a maintenance tool is pretty good.

wxwisiasdf : Do you know if there are any freely-available compilers (for any language) for S/390 / z/Arch that make use of the access-register feature? GCC almost certainly deals only with a flat address space, and I imagine that whatever IBM uses to write z/OS, etc. is proprietary and quite expensively licensed.

I only know of GCCMVS, it allows you to inline HLASM assembly onto it, there are also PL/I and FORTRAN compilers available for TK4 and MVS3.8J, all of that is free - however I don't know if they use access registers when compiling. z390 might use it but I haven't checked. I think you mostly have to do it by hand on HLASM. Since most compilers apparently assume only a single address space is used.

I'm not really counting inline assembly, because even though that would allow you to load access registers, you'd then be presenting the compiler with an environment that it wouldn't know how to deal with.



Yeah, pretty much what I'm afraid of.

I wonder if one could port OpenWatcom or something: having roots in the segmented x86 era, it knows how to deal with non-flat addressing...