Interesting. I never used much IBM hardware, and always assumed that their terminals used EBCDIC and not ASCII.
The HP 2648A terminal also had a "block mode", and the RTE screen editor used it. It was one of the first screen editors I ever used (in 1984). (I had used WordStar on CP/M as early as 1979.)
> I never used much IBM hardware, and always assumed that their terminals used EBCDIC and not ASCII.
Generally this is true. But around this era I used a ton of 3151 terminals on AIX, IBM's version of Unix. They were connected to the RS/6000 line of AIX machines. Good times! These machines, as Unix machines, talked in ASCII to their terminals. There was a whole line of port concentrators which would like you connect something like 32 ASCII terminals to a little block about the size of a modern ethernet router, and you could connect 4 of so of these blocks to a device in the main machine.
As someone who wishes more people got some programming exposure to IBM z and how it works differently than minicomputer derived operating systems (both *nix and Windows count here), I think this is awesome.
Indeed. The deeply alien nature of MVS and its descendants is fascinating. It's not only a difference in commands, but also the underlying concepts that don't map cleanly to concepts we got used to in Unix and Windows that causes a lot of confusion. For instance, a TSO user being unable to log in from different terminals at the same time confused me a lot until someone told me TSO users are not the same as Unix users. Also, a VM is not the same as a VMWare VM.
That, and datasets, which are not really hierarchical.
Yes there's a hierarchy (with . as a separator), but it's more naming convention than a description of the underlying filesystem. You can create projects.foo.code.bar without having any entity (like a Unix directory) for projects.foo first.
MCP, the only OS older than z/OS in active maintenance, even more alien than IBM’s, does more or less the same. It had at one time a hierarchical file system, but at some point they decided it was pointless and adopted a naming convention instead.
I was trying to get around it on SimH, with the B5500 version. Definitely deserves the name.
Reading your comments, I suddenly realized that Win NT comes from PRISM which come from VMS so it also derived from minicomputer era. Interesting, never thought about that.
I think MS-DOS comes from CP/M which was also sort of rooted in the minicomputer era.
"Originally, we were targeting NT to the Intel i860 (code-named 'N-Ten)', a RISC processor that was horribly behind schedule. Because we didn't have any i860 machines in-house to test on, we used an i860 simulator. That's why we called it NT, because it worked on the 'N-Ten.'"
So NT from VMS is not true as pointed out above. However a funning one that is suppose to be true is from the 2001 Space Odyssey series. The name of the insane AI was H.A.L.
Also true about IBM I (AKA AS400), which is also still in somewhat wide use.
Most People seem to at least know that mainframes and Cobol exist, even if they've never seen them. IBM I (and its primary language, RPG) are similar in importance to the global economy and just as different from Nix and Windows systems, but they seem to be far less known.
They're also far easier to get access to, there's a free modern system that you can get an account on at pub400.com. With Z/OS, you're stuck with Hercules emulating some ancient version from the 80's which there's barely any documentation for.
The IBM Z mainframes seem really neat. I don't have a use case for using one of course, but I wish IBM had like a weak virtual system for training that was open for the public to play with.
It is cool stuff. I got plenty of exposure. My father worked on airline, bank, and credit card systems. and now does work for the IRS on the tax processing mainframes. He's literally "old man yells at cloud".
We connected our two IBM 4381s (VM/CMS) to our BT mega/kilostream serial network using VT200 (and VT00 & VT52)-emulating terminals via an IBM 7171 protocol converter. I had the somewhat unenviable task of programming this beast, but it worked well enough, and (like all IBM gear) was very well documented. This would be mid-1980s. The 7171 was good because it meant we didn't have to replace all our terminals.
Block mode was sort of the text terminal version of today's web SPA's.
I worked with one at a chemical company back in the 90's, and they were wonderfully efficient. Only send a single chunk of data when needed, not a constant stream of individual keypresses that have to be interpreted and processed.
Super cool project. The block mode on the 3151 was way ahead of its time — kind of wild how it handled forms locally like that. Love the idea of hooking it up to a mainframe via your translator. Also yeah… we really need to bring back spiral cables.
At an old job we had a 3151 connected to an RS/6000 with AIX among other Wyse serial terminals. I suspect it came with the RS/6000 and they bought all the cheaper Wyse terminals later. Purely character mode in this configuration. I had no idea it supported any kind of block mode. Fascinating!
I'm freaking out... At 50:28 he says "...everything is green..." when referring to the monochrome terminal of the 3151, I'm seeing Cyan... is this the end?
One of the hardest things to deal with is the accelerating loss of documentation of these old systems. Unless you are lucky, you end up spelunking around weird and not very safe looking URLs looking for redbooks or specs, or, like some medieval historian, trying to figure out what X said by reading some commentary or rebuttal produced decades later that mentions X.
Case in point: in the late 90s I was a user of a product called SNAP-IX, that aimed to convert between SNA/terminals and TCP/IP client server. It was produced by a small UK company, Data Connection, that then got swallowed up and repurposed and ultimately eaten up by some cloud company, and all the documentation, manuals, specs, and knowledge evaporated. Somebody somewhere might have a pdf library, but you'll never find it. They had kept that product going for 25 years. Pfft. Gone.
As soon as we drop the line rates back down to 1200, sure. Actually there are a lot of spiral cables readily available on the market because clicky keyboard guys resurrected the category but they only support the lowest and most ancient USB protocols.
You can make up anything on Amazon and neither Intel nor the USB-IF has the resources to go after fly-by-night six-random-letter companies selling this stuff.
I agree with you the cable I linked to is likely lying about capabilities. I looked at reputable brands, and while they do make spiral cables, none of them certify those cables for more than 480Mbps. Exactly as you were saying previously.
Interesting. I never used much IBM hardware, and always assumed that their terminals used EBCDIC and not ASCII.
The HP 2648A terminal also had a "block mode", and the RTE screen editor used it. It was one of the first screen editors I ever used (in 1984). (I had used WordStar on CP/M as early as 1979.)
https://en.wikipedia.org/wiki/EBCDIC
https://terminals-wiki.org/wiki/index.php/HP_2648A
http://www.bitsavers.org/pdf/hp/1000/RTE-A/92077-90039_RTE-A...
> I never used much IBM hardware, and always assumed that their terminals used EBCDIC and not ASCII.
Generally this is true. But around this era I used a ton of 3151 terminals on AIX, IBM's version of Unix. They were connected to the RS/6000 line of AIX machines. Good times! These machines, as Unix machines, talked in ASCII to their terminals. There was a whole line of port concentrators which would like you connect something like 32 ASCII terminals to a little block about the size of a modern ethernet router, and you could connect 4 of so of these blocks to a device in the main machine.
Good info. I've also used AIX, but more recently (after 1995). By then, I think EBCDIC had lost the standards battle.
Their mainframe terminals do, and that's one of the conversions their script has to make.
The 3151 was designed to integrate with other systems where ASCII was already prevalent.
Huh. It actually is ASCII and not EBCDIC. I didn't know ASCII block mode terminals existed:
https://terminals-wiki.org/wiki/index.php/IBM_3151
https://www.ardent-tool.com/3151/
This is very cool!
As someone who wishes more people got some programming exposure to IBM z and how it works differently than minicomputer derived operating systems (both *nix and Windows count here), I think this is awesome.
Indeed. The deeply alien nature of MVS and its descendants is fascinating. It's not only a difference in commands, but also the underlying concepts that don't map cleanly to concepts we got used to in Unix and Windows that causes a lot of confusion. For instance, a TSO user being unable to log in from different terminals at the same time confused me a lot until someone told me TSO users are not the same as Unix users. Also, a VM is not the same as a VMWare VM.
That, and datasets, which are not really hierarchical.
Yes there's a hierarchy (with . as a separator), but it's more naming convention than a description of the underlying filesystem. You can create projects.foo.code.bar without having any entity (like a Unix directory) for projects.foo first.
MCP, the only OS older than z/OS in active maintenance, even more alien than IBM’s, does more or less the same. It had at one time a hierarchical file system, but at some point they decided it was pointless and adopted a naming convention instead.
I was trying to get around it on SimH, with the B5500 version. Definitely deserves the name.
Reading your comments, I suddenly realized that Win NT comes from PRISM which come from VMS so it also derived from minicomputer era. Interesting, never thought about that.
I think MS-DOS comes from CP/M which was also sort of rooted in the minicomputer era.
Dave Cutler, the head of the NT project came from DEC where he did VMS. Big lawsuit when MS hired him.
https://en.m.wikipedia.org/wiki/Dave_Cutler
Yeah that's what I read in Showstoppers too.
WNT = V + 1, M + 1, S + 1
"Originally, we were targeting NT to the Intel i860 (code-named 'N-Ten)', a RISC processor that was horribly behind schedule. Because we didn't have any i860 machines in-house to test on, we used an i860 simulator. That's why we called it NT, because it worked on the 'N-Ten.'"
-- Mark Lucovsky
Distinguished Engineer, Windows Server Architect
https://web.archive.org/web/20110720042038/http://www.winsup...
So NT from VMS is not true as pointed out above. However a funning one that is suppose to be true is from the 2001 Space Odyssey series. The name of the insane AI was H.A.L.
H>I
A>B
L>M
I found surprising that IBM's CMS had commands like "DIR" and "TYPE".
Also true about IBM I (AKA AS400), which is also still in somewhat wide use.
Most People seem to at least know that mainframes and Cobol exist, even if they've never seen them. IBM I (and its primary language, RPG) are similar in importance to the global economy and just as different from Nix and Windows systems, but they seem to be far less known.
They're also far easier to get access to, there's a free modern system that you can get an account on at pub400.com. With Z/OS, you're stuck with Hercules emulating some ancient version from the 80's which there's barely any documentation for.
There's a bunch of documentation for MVS 3.8J (or OS/VS2) on Bitsavers.
IBM provide free 1-year Z access via the Zxplore program.
The IBM Z mainframes seem really neat. I don't have a use case for using one of course, but I wish IBM had like a weak virtual system for training that was open for the public to play with.
Z Xplore at least used to include Z series access.
https://ibmzxplore.influitive.com/users/sign_in
I didn't know about this! Is it truly free of charge? Seems too good to be true.
Haven't used it for a couple of years, but I think it's still a free login ID with 1-year validity. You can re-apply every year.
Hercules:
http://www.hercules-390.eu/
Guidance and discussion:
https://news.ycombinator.com/item?id=23268307
It is cool stuff. I got plenty of exposure. My father worked on airline, bank, and credit card systems. and now does work for the IRS on the tax processing mainframes. He's literally "old man yells at cloud".
We connected our two IBM 4381s (VM/CMS) to our BT mega/kilostream serial network using VT200 (and VT00 & VT52)-emulating terminals via an IBM 7171 protocol converter. I had the somewhat unenviable task of programming this beast, but it worked well enough, and (like all IBM gear) was very well documented. This would be mid-1980s. The 7171 was good because it meant we didn't have to replace all our terminals.
Wow, Kilostream. There's a name I never thought I'd hear again :-)
Block mode was sort of the text terminal version of today's web SPA's.
I worked with one at a chemical company back in the 90's, and they were wonderfully efficient. Only send a single chunk of data when needed, not a constant stream of individual keypresses that have to be interpreted and processed.
Super cool project. The block mode on the 3151 was way ahead of its time — kind of wild how it handled forms locally like that. Love the idea of hooking it up to a mainframe via your translator. Also yeah… we really need to bring back spiral cables.
At an old job we had a 3151 connected to an RS/6000 with AIX among other Wyse serial terminals. I suspect it came with the RS/6000 and they bought all the cheaper Wyse terminals later. Purely character mode in this configuration. I had no idea it supported any kind of block mode. Fascinating!
I'm freaking out... At 50:28 he says "...everything is green..." when referring to the monochrome terminal of the 3151, I'm seeing Cyan... is this the end?
That's a "green screen" that is tending cyan. As opposed to an orange screen.
It's the white balance of the camera. Ambient light is making it overcompensate the screen and make it more blue.
This is amazing. I wonder if 3270 and 5150 terminals can be set to an ASCII/VT100 mode - they are much more common on eBay than serial ones.
One of the hardest things to deal with is the accelerating loss of documentation of these old systems. Unless you are lucky, you end up spelunking around weird and not very safe looking URLs looking for redbooks or specs, or, like some medieval historian, trying to figure out what X said by reading some commentary or rebuttal produced decades later that mentions X.
Case in point: in the late 90s I was a user of a product called SNAP-IX, that aimed to convert between SNA/terminals and TCP/IP client server. It was produced by a small UK company, Data Connection, that then got swallowed up and repurposed and ultimately eaten up by some cloud company, and all the documentation, manuals, specs, and knowledge evaporated. Somebody somewhere might have a pdf library, but you'll never find it. They had kept that product going for 25 years. Pfft. Gone.
building compilers for discursive ASCII 3151 machine code to source in 3270's
extricating terminal interfaces whether in binary, object-oriented abstracted languages is a feature in UNIX paradigms
Very cool
Here's another, recently-started YT channel focussed on mainframes: ErnieTech's Little Mainframes https://www.youtube.com/channel/UCdi4FOLU9-kSiiE7tVuVyjg .
His homepage is also a wealth of information: https://sites.google.com/view/ernietech/home
We need to bring back spiral cables.
As soon as we drop the line rates back down to 1200, sure. Actually there are a lot of spiral cables readily available on the market because clicky keyboard guys resurrected the category but they only support the lowest and most ancient USB protocols.
This looks like a spiral cable which supports USB4 40Gbps:
https://www.amazon.co.uk/AWADUO-Charging-Extension-Compatibl...
You can make up anything on Amazon and neither Intel nor the USB-IF has the resources to go after fly-by-night six-random-letter companies selling this stuff.
I agree with you the cable I linked to is likely lying about capabilities. I looked at reputable brands, and while they do make spiral cables, none of them certify those cables for more than 480Mbps. Exactly as you were saying previously.
I kind of want those, but remember how hard it is to untangle the loops, and I'm already over it.