7 ms·

If you want unfamiliar, try MVS on IBM s/370 mainframes. Version 3.8j (from the early 80s) is readily available, and runs great on the Hercules emulator: https:

by anyfoo 2y ago

If you want unfamiliar, try MVS on IBM s/370 mainframes. Version 3.8j (from the early 80s) is readily available, and runs great on the Hercules emulator: https://www.jaymoseley.com/hercules/installMVS/iMVSintroV8.htm https://www.jaymoseley.com/hercules/installMVS/iMVSintroV8.h... It made me realize just how many fundamental things that I completely took for granted in the "modern" computing world, were ultimately just concepts derived from UNIX (even for OSes that you'd think have little relation to it at all), and how there were (and in some capacity still are) very, very different worlds out there.

PaulHoule 2y ago
In the 1980s a clear case of this was that MS-DOS 2.0 had system calls for file operations that basically worked like Unix whereas MS-DOS 1's filesystem API looked like CP/M. It's an interesting story that IBM really struggled to develop an OS which was "universal" the way the "360" was supposed to be universal. The answer they came to was VM which would let you run different OSes for your batch jobs, interactive sessions, transaction managers, databases, etc. Contrast that to Unix, VAX/VMS or Windows NT where you can run all those things under one OS. In 1970 though, IBM had no idea how to do that. Note today a Z installation is very likely to have Linux in the mix https://www.ibm.com/z/linux https://www.ibm.com/z/linux so it is no problem running your POSIX app together with traditional mainframe apps. Also there is a Java runtime https://www.ibm.com/docs/en/zos-basic-skills?topic=zos-java https://www.ibm.com/docs/en/zos-basic-skills?topic=zos-java so you can host your Java apps.
- anyfoo 2y ago
  > In the 1980s a clear case of this was that MS-DOS 2.0 had system calls for file operations that basically worked like Unix whereas MS-DOS 1's filesystem API looked like CP/M. I honestly don't think that's a good example. On the contrary, I think it actually obscures what I mean, and would lead the casual reader to assume that things were actually much less different than they actually were. Both MS-DOS and CP/M still had the very clear and almost identical concept of a "file" in the first place. I don't know if CP/M (and in turn CMS) was inspired by UNIX in that way, or whether the "file" concept came from a different common ancestor, but it's worth repeating that MVS has more or less nothing like that "file" concept. MVS had "datasets" and "partitioned datasets", which I often see people relating to "files" and "directories" through a lens colored by today's computing world. But if you start using it, you quickly realize that the semblance is actual pretty minimal. (If you use the 1980s MVS 3.8j, that is.) Both datasets and partitioned datasets require you to do things that even the simplest of filesystems (e.g. FAT12 for MS-DOS) do on their own and completely transparently to the user (or even developer). And moreover, datasets/members are usually (not always) organized as "records", sometimes indexed, sometimes even indexed in a key-value manner. This goes so fundamentally with the system that it goes down into the hardware, i.e. the disk itself understands the concept of indices, record lengths and even keyed records with associated values. MS-DOS, CP/M, and practically all modern systems, instead see "files" as a stream of bytes/words/octets or whatever. A lot of this has been abstracted away and "pulled" into the modern and familiar "file" concept the closer you get to z/OS, but that's what MVS back then was like. A C64 with its 1541 is closer to old school MVS than MS-DOS and CP/M both are, because an 1541 supports both "sequential" files (byte streams) and "relative" files (indexed record sets), and because it provides relatively high level interface to circumvent that altogether and work with the disk ("volume" in MVS parlance) more directly. There's even a "user defined" file type. However, altogether the 1541 is closer to MS-DOS and CP/M again, because usually (not always!) you leave the block allocation to the system itself. Like you always do in a modern system and MS-DOS or CP/M, there is basically no sane way around it (at best you can slightly "tweak" it). That's not even touching on what "batch processing", and associated job control languages and reader/printer/puncher queues, mean in practice. It's so alien to the world of nowadays.
  - sillywalk 2y ago
    > This goes so fundamentally with the system that it goes down into the hardware, i.e. the disk itself understands the concept of indices, record lengths and even keyed records with associated values. Interesting, so the disk controller firmware understood records / data sets? I believe Filesystems with files that could be record-oriented in addition to bytestreams were also common e.g. VMS had RMS on Files-11; the MPE file system was record-oriented until it got POSIX with MPE/IX. Tandem NonStop's Enscribe filesystem also has different types of record-oriented files in addition to unstructured files. I assume it was a logical transition for businesses transferring from punch-cards or just plain paper "records" to digital ones.
    - anyfoo 2y ago
      > Interesting, so the disk controller firmware understood records / data sets? Yep. The disk was addressed by record in a fundamental manner: https://en.wikipedia.org/wiki/Count_key_data https://en.wikipedia.org/wiki/Count_key_data An offshoot of this is that the Hercules mainframe emulator reflects that in its disk image format, which unlike other common disk image formats is not just an opaque stream of bytes/words. > I assume it was a logical transition for businesses transferring from punch-cards or just plain paper "records" to digital ones. Yeah, that is a sensible assumption. In general, MVS's "not-filesystem" world looks in a lot of ways like an intermediary between paper records/tapes and actual filesystems.
      - skissane 2y ago
        > Yep. The disk was addressed by record in a fundamental manner: https://en.wikipedia.org/wiki/Count_key_data https://en.wikipedia.org/wiki/Count_key_data Well, mainstream hard disks (what IBM calls "FBA") are also addressed by record in a fundamental manner. It is just that the records (sectors) are fixed length–often hard disks support a small selection of sector sizes (e.g. 512, 520, 524 or 528 byte sectors for older 512 byte sector HDDs; 4096, 4112, 4160, or 4224 byte sectors for the newer 4096 byte sector HDDs; the extended sector sizes are designed for use by RAID, or by certain obscure operating systems that require them, e.g. IBM AS/400 systems) Floppies were closer to IBM mainframe hard disks than standard FBA hard disks are. Floppies can have tracks with sectors of different sizes, and even a mix of different sector sizes on a single track; IBM standard floppies (used by PCs) have two different types of sectors, normal and deleted (albeit almost nobody ever used deleted sectors); standard PC floppy controllers have commands to do searches of sectors (the SCAN commands–but little software ever used them, and by the 1990s some FDCs were even omitting support for them to reduce complexity). And although z/OS still requires CKD (actually ECKD) hard disks, newer software (e.g. VSAM, PDSE, HFS, zFS) largely doesn't use the key field (hardware keys), instead implementing keys in software (which turns out to be faster). However, the hardware keys are still required because they are an essential part of the on-disk structure of the IBM VTOC dataset filesystem. Actually, the Linux kernel contains support for the IBM VTOC dataset filesystem. [0] Except as far as Linux is concerned, it is not a filesystem, it is a partition table format. [1] I think part of the point of this, is if you have a mixed z/OS and z/Linux environment, you can store your z/Linux filesystems inside a VTOC filesystem. Then, if you end up accessing one of your z/Linux filesystem volumes from z/OS, people will see it contains a Linux filesystem dataset and leave it alone – as opposed to thinking "oh, this volume is corrupt, I better format it!" because z/OS can't read it > In general, MVS's "not-filesystem" world looks in a lot of ways like an intermediary between paper records/tapes and actual filesystems. I think the traditional MVS filesystem really is a filesystem. Sure, it is weird by contemporary mainstream standards. But by the standards of historical mainframe/minicomputer filesystems, less so. [0] https://github.com/torvalds/linux/blob/v6.10/arch/s390/include/uapi/asm/vtoc.h#L90 https://github.com/torvalds/linux/blob/v6.10/arch/s390/inclu... [1] https://github.com/torvalds/linux/blob/v6.10/block/partitions/ibm.c#L168 https://github.com/torvalds/linux/blob/v6.10/block/partition...
kens 2y ago
Yes, looking at IBM stuff is like being in a parallel universe where everything you take for granted is slightly off. You have token-ring instead of Ethernet, you have SNA (or something) instead of TCP/IP. Characters are EBCDIC, not ASCII. Terminals are connected with coax, not RS-232. For hardware, chips are packaged in metal instead of plastic. Circuit boards are a weird grid. Even the terminology and schematic symbols are different: if it looks like an AND gate, it's an OR gate.
- whartung 2y ago
  From the "If I could" files, I would have liked to spent 5 years on an AS/400, trying to make it work for whatever company I was working for. The best way to learn this stuff is simply apply it, trying to solve problems. Going from a High School PET to a College CDC NOS/VM Cyber 730 to a RSTS/E PDP 11/70 was very education cross section of computing that really opened my eyes. If I had gone to school only a few years later, it would have been all PCs, all the time, and I would have missed that little fascinating window. But I never got to go hands on with an IBM or an AS/400, and I think that would have been interesting before diving into the Unix world.
  - PaulHoule 2y ago
    The OS for the AS/400 is really remarkable as a "path not taken" by the industry and remarkably advanced. Many of the OO architecture ideas that became popular with Java were baked into the OS https://en.wikipedia.org/wiki/IBM_AS/400 https://en.wikipedia.org/wiki/IBM_AS/400 and of course it started out with a virtual machine in the late 1970s.
    - anyfoo 2y ago
      Yes, AS/400 / IBM i is the other IBM OS I like to play with (I have an actual AS/400e at home), and in a lot of ways I consider it to be the polar opposite of MVS on the mainframe: Where MVS seems to be missing very simple abstractions that I took for granted, AS/400 abstracts way more than I'm used to, differently, and most importantly far away from the very, very "file-centric" view of today's systems that was derived from UNIX. It indeed shows you what computing could have been, had AS/400 been more open and had those ideas spread farther. Before I got to know AS/400, I thought UNIX was great, and that it rightfully took over computing. Now, not so much, and I've started to see how detrimental the "everything is a file" concept that UNIX brought into the world actually was to computing in general.
rbanffy 2y ago
Easy way to do it: docker run -it --rm -p 3270:3270 rbanffy/vm370ce This will set up a VM/370 Community Edition running on a beefy virtual 4381. Direct your 3270 terminal to port 3270 and check the README at https://github.com/rbanffy/vm370 https://github.com/rbanffy/vm370 for some bearings.
lproven 2y ago
> It made me realize just how many fundamental things that I completely took for granted in the "modern" computing world, were ultimately just concepts derived from UNIX Oh so very much yes. And the flipside of this is that it's very very hard to get new ideas into the heads of people who only know and have only ever seen computers running Unix-style or Unix-inspired computers. Some examples: The product that the inventors of Unix did next was Plan 9. It's still alive and in development. Some things that Plan 9 takes as givens that blow Unix folks' minds: * There is no one true view of the filesystem. It's all namespaces and every process can (and normally would) see a different namespace. They are all correct and there is no one valid underlying view: it's all relative, and all interpreted. * Everything really is a file. For example the contents of a window on screen is a file. Arguably if your GUI doesn't do this, is it really Unix-like? * There's no keyboard-driven command-line editing because of course your computer has a graphical screen and you can just use the mouse. Why would you pretend your input window is a 1970s 80x25 text terminal? What's the point of that? Then Plan 9 evolved into Inferno. It breaks more assumptions. * C is not low level any more because computers have evolved very far away from the machines C was designed for. C has no native standard build-in way to represent matrices of 256-bit values and apply SIMD transformations to them as one operation, and no way to farm out 10000 threads to 1000 compute units. So, throw C in the bin, and replace it with something a bit more abstract. * Computers have different types of CPUs. So, compile source± to intermediate code and embed the runtime in the kernel. No need for a JVM or any other runtime; no need for WASM or eBPF; it's stock. * Any binary can execute on any CPU. Computers can have more than one type of CPU and compiled code can move between them without translation. Or to move further afield... * The Unix tradition puts the filesystem at the centre of the design. Not all do. So some OS designs do not have filesystems and do not have the concept of files. It's objects all the way down. * Some OSes and some languages don't have compilers or interpreters or binaries. That's a 1970s implementation detail and it was eliminated 50+ years ago. This kind of stuff can be much more powerful than the Unix model, but folks reared on Unix dismiss these ideas as toys, not understanding that clinging to a 1970s idea built on computers which are less powerful than toys today is limiting them.

by anyfoo 2y ago

PaulHoule 2y ago

In the 1980s a clear case of this was that MS-DOS 2.0 had system calls for file operations that basically worked like Unix whereas MS-DOS 1's filesystem API looked like CP/M. It's an interesting story that IBM really struggled to develop an OS which was "universal" the way the "360" was supposed to be universal. The answer they came to was VM which would let you run different OSes for your batch jobs, interactive sessions, transaction managers, databases, etc. Contrast that to Unix, VAX/VMS or Windows NT where you can run all those things under one OS. In 1970 though, IBM had no idea how to do that. Note today a Z installation is very likely to have Linux in the mix https://www.ibm.com/z/linux https://www.ibm.com/z/linux so it is no problem running your POSIX app together with traditional mainframe apps. Also there is a Java runtime https://www.ibm.com/docs/en/zos-basic-skills?topic=zos-java https://www.ibm.com/docs/en/zos-basic-skills?topic=zos-java so you can host your Java apps.

anyfoo 2y ago
> In the 1980s a clear case of this was that MS-DOS 2.0 had system calls for file operations that basically worked like Unix whereas MS-DOS 1's filesystem API looked like CP/M. I honestly don't think that's a good example. On the contrary, I think it actually obscures what I mean, and would lead the casual reader to assume that things were actually much less different than they actually were. Both MS-DOS and CP/M still had the very clear and almost identical concept of a "file" in the first place. I don't know if CP/M (and in turn CMS) was inspired by UNIX in that way, or whether the "file" concept came from a different common ancestor, but it's worth repeating that MVS has more or less nothing like that "file" concept. MVS had "datasets" and "partitioned datasets", which I often see people relating to "files" and "directories" through a lens colored by today's computing world. But if you start using it, you quickly realize that the semblance is actual pretty minimal. (If you use the 1980s MVS 3.8j, that is.) Both datasets and partitioned datasets require you to do things that even the simplest of filesystems (e.g. FAT12 for MS-DOS) do on their own and completely transparently to the user (or even developer). And moreover, datasets/members are usually (not always) organized as "records", sometimes indexed, sometimes even indexed in a key-value manner. This goes so fundamentally with the system that it goes down into the hardware, i.e. the disk itself understands the concept of indices, record lengths and even keyed records with associated values. MS-DOS, CP/M, and practically all modern systems, instead see "files" as a stream of bytes/words/octets or whatever. A lot of this has been abstracted away and "pulled" into the modern and familiar "file" concept the closer you get to z/OS, but that's what MVS back then was like. A C64 with its 1541 is closer to old school MVS than MS-DOS and CP/M both are, because an 1541 supports both "sequential" files (byte streams) and "relative" files (indexed record sets), and because it provides relatively high level interface to circumvent that altogether and work with the disk ("volume" in MVS parlance) more directly. There's even a "user defined" file type. However, altogether the 1541 is closer to MS-DOS and CP/M again, because usually (not always!) you leave the block allocation to the system itself. Like you always do in a modern system and MS-DOS or CP/M, there is basically no sane way around it (at best you can slightly "tweak" it). That's not even touching on what "batch processing", and associated job control languages and reader/printer/puncher queues, mean in practice. It's so alien to the world of nowadays.
- sillywalk 2y ago
  > This goes so fundamentally with the system that it goes down into the hardware, i.e. the disk itself understands the concept of indices, record lengths and even keyed records with associated values. Interesting, so the disk controller firmware understood records / data sets? I believe Filesystems with files that could be record-oriented in addition to bytestreams were also common e.g. VMS had RMS on Files-11; the MPE file system was record-oriented until it got POSIX with MPE/IX. Tandem NonStop's Enscribe filesystem also has different types of record-oriented files in addition to unstructured files. I assume it was a logical transition for businesses transferring from punch-cards or just plain paper "records" to digital ones.
  - anyfoo 2y ago
    > Interesting, so the disk controller firmware understood records / data sets? Yep. The disk was addressed by record in a fundamental manner: https://en.wikipedia.org/wiki/Count_key_data https://en.wikipedia.org/wiki/Count_key_data An offshoot of this is that the Hercules mainframe emulator reflects that in its disk image format, which unlike other common disk image formats is not just an opaque stream of bytes/words. > I assume it was a logical transition for businesses transferring from punch-cards or just plain paper "records" to digital ones. Yeah, that is a sensible assumption. In general, MVS's "not-filesystem" world looks in a lot of ways like an intermediary between paper records/tapes and actual filesystems.
    - skissane 2y ago
      > Yep. The disk was addressed by record in a fundamental manner: https://en.wikipedia.org/wiki/Count_key_data https://en.wikipedia.org/wiki/Count_key_data Well, mainstream hard disks (what IBM calls "FBA") are also addressed by record in a fundamental manner. It is just that the records (sectors) are fixed length–often hard disks support a small selection of sector sizes (e.g. 512, 520, 524 or 528 byte sectors for older 512 byte sector HDDs; 4096, 4112, 4160, or 4224 byte sectors for the newer 4096 byte sector HDDs; the extended sector sizes are designed for use by RAID, or by certain obscure operating systems that require them, e.g. IBM AS/400 systems) Floppies were closer to IBM mainframe hard disks than standard FBA hard disks are. Floppies can have tracks with sectors of different sizes, and even a mix of different sector sizes on a single track; IBM standard floppies (used by PCs) have two different types of sectors, normal and deleted (albeit almost nobody ever used deleted sectors); standard PC floppy controllers have commands to do searches of sectors (the SCAN commands–but little software ever used them, and by the 1990s some FDCs were even omitting support for them to reduce complexity). And although z/OS still requires CKD (actually ECKD) hard disks, newer software (e.g. VSAM, PDSE, HFS, zFS) largely doesn't use the key field (hardware keys), instead implementing keys in software (which turns out to be faster). However, the hardware keys are still required because they are an essential part of the on-disk structure of the IBM VTOC dataset filesystem. Actually, the Linux kernel contains support for the IBM VTOC dataset filesystem. [0] Except as far as Linux is concerned, it is not a filesystem, it is a partition table format. [1] I think part of the point of this, is if you have a mixed z/OS and z/Linux environment, you can store your z/Linux filesystems inside a VTOC filesystem. Then, if you end up accessing one of your z/Linux filesystem volumes from z/OS, people will see it contains a Linux filesystem dataset and leave it alone – as opposed to thinking "oh, this volume is corrupt, I better format it!" because z/OS can't read it > In general, MVS's "not-filesystem" world looks in a lot of ways like an intermediary between paper records/tapes and actual filesystems. I think the traditional MVS filesystem really is a filesystem. Sure, it is weird by contemporary mainstream standards. But by the standards of historical mainframe/minicomputer filesystems, less so. [0] https://github.com/torvalds/linux/blob/v6.10/arch/s390/include/uapi/asm/vtoc.h#L90 https://github.com/torvalds/linux/blob/v6.10/arch/s390/inclu... [1] https://github.com/torvalds/linux/blob/v6.10/block/partitions/ibm.c#L168 https://github.com/torvalds/linux/blob/v6.10/block/partition...

kens 2y ago

Yes, looking at IBM stuff is like being in a parallel universe where everything you take for granted is slightly off. You have token-ring instead of Ethernet, you have SNA (or something) instead of TCP/IP. Characters are EBCDIC, not ASCII. Terminals are connected with coax, not RS-232. For hardware, chips are packaged in metal instead of plastic. Circuit boards are a weird grid. Even the terminology and schematic symbols are different: if it looks like an AND gate, it's an OR gate.

whartung 2y ago
From the "If I could" files, I would have liked to spent 5 years on an AS/400, trying to make it work for whatever company I was working for. The best way to learn this stuff is simply apply it, trying to solve problems. Going from a High School PET to a College CDC NOS/VM Cyber 730 to a RSTS/E PDP 11/70 was very education cross section of computing that really opened my eyes. If I had gone to school only a few years later, it would have been all PCs, all the time, and I would have missed that little fascinating window. But I never got to go hands on with an IBM or an AS/400, and I think that would have been interesting before diving into the Unix world.
- PaulHoule 2y ago
  The OS for the AS/400 is really remarkable as a "path not taken" by the industry and remarkably advanced. Many of the OO architecture ideas that became popular with Java were baked into the OS https://en.wikipedia.org/wiki/IBM_AS/400 https://en.wikipedia.org/wiki/IBM_AS/400 and of course it started out with a virtual machine in the late 1970s.
  - anyfoo 2y ago
    Yes, AS/400 / IBM i is the other IBM OS I like to play with (I have an actual AS/400e at home), and in a lot of ways I consider it to be the polar opposite of MVS on the mainframe: Where MVS seems to be missing very simple abstractions that I took for granted, AS/400 abstracts way more than I'm used to, differently, and most importantly far away from the very, very "file-centric" view of today's systems that was derived from UNIX. It indeed shows you what computing could have been, had AS/400 been more open and had those ideas spread farther. Before I got to know AS/400, I thought UNIX was great, and that it rightfully took over computing. Now, not so much, and I've started to see how detrimental the "everything is a file" concept that UNIX brought into the world actually was to computing in general.

rbanffy 2y ago

Easy way to do it: docker run -it --rm -p 3270:3270 rbanffy/vm370ce This will set up a VM/370 Community Edition running on a beefy virtual 4381. Direct your 3270 terminal to port 3270 and check the README at https://github.com/rbanffy/vm370 https://github.com/rbanffy/vm370 for some bearings.

lproven 2y ago

> It made me realize just how many fundamental things that I completely took for granted in the "modern" computing world, were ultimately just concepts derived from UNIX Oh so very much yes. And the flipside of this is that it's very very hard to get new ideas into the heads of people who only know and have only ever seen computers running Unix-style or Unix-inspired computers. Some examples: The product that the inventors of Unix did next was Plan 9. It's still alive and in development. Some things that Plan 9 takes as givens that blow Unix folks' minds: * There is no one true view of the filesystem. It's all namespaces and every process can (and normally would) see a different namespace. They are all correct and there is no one valid underlying view: it's all relative, and all interpreted. * Everything really is a file. For example the contents of a window on screen is a file. Arguably if your GUI doesn't do this, is it really Unix-like? * There's no keyboard-driven command-line editing because of course your computer has a graphical screen and you can just use the mouse. Why would you pretend your input window is a 1970s 80x25 text terminal? What's the point of that? Then Plan 9 evolved into Inferno. It breaks more assumptions. * C is not low level any more because computers have evolved very far away from the machines C was designed for. C has no native standard build-in way to represent matrices of 256-bit values and apply SIMD transformations to them as one operation, and no way to farm out 10000 threads to 1000 compute units. So, throw C in the bin, and replace it with something a bit more abstract. * Computers have different types of CPUs. So, compile source± to intermediate code and embed the runtime in the kernel. No need for a JVM or any other runtime; no need for WASM or eBPF; it's stock. * Any binary can execute on any CPU. Computers can have more than one type of CPU and compiled code can move between them without translation. Or to move further afield... * The Unix tradition puts the filesystem at the centre of the design. Not all do. So some OS designs do not have filesystems and do not have the concept of files. It's objects all the way down. * Some OSes and some languages don't have compilers or interpreters or binaries. That's a 1970s implementation detail and it was eliminated 50+ years ago. This kind of stuff can be much more powerful than the Unix model, but folks reared on Unix dismiss these ideas as toys, not understanding that clinging to a 1970s idea built on computers which are less powerful than toys today is limiting them.