We like to talk about how most of our computers today would have been mainframes a scant 40 or 50 years ago. Because of that, many people who want to run IBM mainframes such as the IBM 360 or 370 use the Hercules emulator to run the big iron on their PCs. However, mainframe IBM computers used an odd style of terminal and emulating it on a PC isn’t always as satisfying. At least, that’s what [lowobservable] thought, so he decided to get a 3270 terminal working with Hercules.
Back in the bad old days of computing, there were two main styles of terminals. Some companies, for example DEC, essentially used terminals as a “glass teletype.” That is, the screen was an analog of a roll of paper — more or less — and the keyboard immediately sent things to the remote system. However, companies like IBM and HP favored a different approach. Their terminals dealt with screens full of data. The terminal was smart enough to let you fill in forms, edit text on the screen, and then you’d send the entire screen in one gulp. Both systems had pros and cons, but — as you might expect — the screen-oriented terminals were more complex.
The project turned out to be a lot of detective work. A lot of these old protocols were poorly documented or even secret. However, some datasheets for old interface chips had some details and eBay even had the chips in question. We had forgotten that the 3270 used 93 ohm coax, but we never knew why they picked that particular value.
It turns out there were two different styles of terminals. One required a very sophisticated controller that did most of the work. The other did most of the work locally. Either way, the mainframe only dealt with the processed data. Luckily, [lowobservable] is documenting what he’s learned on GitHub.
At the start of the project, [lowobservable] picked up a surplus terminal unit. However, it had a corrupt disk image so it wouldn’t work. It did, however, have a usable diagnostic disk that could talk to the terminal. This allowed some analysis of the traffic which helped answer some questions.
The end result is a controller that isn’t complete (yet) but it is workable. There are plans for an FPGA version that doesn’t rely on obsolete chips, too.
Of course, we wish we had a real IBM 360. You could settle for an AS400, though.
One advantage of 3270 and 5250 page-mode terminals (at least in the IBM world), is that you can pre-process much of your data before it gets fed to the program running on the big box. Data input fields on the screen could sanitise the input, e.g. you could specify alphabetic-only, numeric-only, acceptable inputs such as positive integers only, minimum and maximum values, and so on.
That feature alone saved having to do all the sanity checks in your software.
Ah, end-to-end trust, who would/could inject malicious data, eh? A quaint world…
In the times of only using local network connections, the chances of somebody injecting data were small…
the first display-oriented editor I ever used was “SPF” on IBM3270 terminals. It was pretty wonderful. Except for that sometimes coffee-break-sized time interval after you hit one of the “Send” keys before you got the next screen…
5250 with twinax cable connected to AS/400 was the weirdest thing I have ever worked with. No sane human being can comprehend RPG. There is 0 flexibility in these systems. Everything is the IBM way or the high way. There was a half day training course how to use the so called “full screen text editor” – which is anything but.
Because the beast is made for filling forms, free text edit was simply not possible in an intuitive way. Good riddance these are all in the past. They should be forgotten and all software tapes burned with a ritual dance.
Laughing for the next 20 years
I made some Continuous Integration for COBOL developers, using TurboHercules emulator running in a Docker container, loading zOS.
IBM is an evil company, they have threatened TurboHercules (an open source project) with 137 patents:
http://www.zoobab.com/ibm-turbohercules-patent-threat-letter
What happened in the 10 years after that?
Absolutely nothing.
In “older” firmware’s the boot floppy kept spinning endlessly in the 3272 and 3172 cluster controllers wearing the magnetic layer out totally. After a power failure the machine could not boot-up again and needed a fresh backup, including the specific configuration of the machine. Creating. I discovered that I could easily create a backup disk for the 3174 (the older 3274 used 8″ floppies, I still have some at home) using the only PC (an IBM AT) in the department that was used by several colleagues. At some point the process failed and also rendered the master disk unusable. Unsure what had happened I decided to inspect the boot sector of the disk. There was my answer, at the end of the boot sector it said: “Your PC is now Stoned!”
That damn virus was so common back in the day that I actually developed an ear for it, had a particular disk access pattern.
In the 1980’s ……VTAM ~ communications controller 3705/3725/3745 ~ MASTER console and ALT consoles required NON-SNA 3274 /3174 controller configration. Each attached 3270 terminal or 3287 printer had its own OS address. Example: 3274/3174 Cluster controller node: H15L02 had 32 OS addresses defined ~ terminal LU’s: T15A0201-T15A020F; T15A0211-T15021F. SNA configurations required only one OS host address per 3274/3174 controller node: H15L001 address 001 ~ terminal LU’s: T15A001-T15A032). Dynacom Elite was a frequently used terminal emulator software where I worked (PCS Health) . When TPX became available on the 360/370 mainframes, printing to a local or non-locally attached 3287 printer became a whole lot easier. Running coax end-to-end was a big pain, so happy when twisted-pair ~ BALUN became available! Lesson learned: your local IBM CE is not always 100% correct ~ DON’T REMOVE FLOPPY FROM NON-SNA 3274/3174 controller during normal business hours :(
Way back in the day this company called Data General made their laptop act like one of these terminals. I thought it was a major misuse of computing resources to take a perfectly good x86 system and force it to pretend it’s a 3270. But I guess them customers were making the call. (I had some development role in that stuff, but it now escapes me exactly what it was. But I still remember the laptop was awesome for its time.)
Back in the day I worked on a project where a dos program on a laptop used by sales guy collected sales info over their work day. When they got back to base our program connected to the mainframe and spoofed the data entry screens to get the data into an existing mainframe application. Weird days…
In the 90s, as PC’s became more prevalent and cheaper, the entire airline industry used this technique (or a variation). Make these hokey little PC programs that collect data out of ‘full-screen’ fields, then send the raw 3270 data back to the controller, and then the mainframes running the Assembler-based reservations/ops/crew control/departure control systems. It always seemed fragile, but I’ve got to say they were probably the most reliable bits of kit I’d ever worked with. (Although….apart from the local hardware: but at least if a terminal shat itself, the whole system wouldn’t collapse!).
The programming of these Assembler-based airline systems was tight: I mean really tight, borne of the days when every byte count due to 4K memory limits, the guys developing knew their stuff based on decades of work on them, and their testing techniques were incomparable to today. They had to be – you couldn’t have your airline stop operations for a day because someone forgot the difference between a ‘0’ and an ‘O’!. The result was that you could rely on them for 1000 tps rates with subsecond response times from Aachen to Zanzibar! Times change, languages and libraries are more disposable, and testing is not the thing it used to be – but the quality of the coding was something to be seen alright!
Thanks. I was one of those guys working on airline projects, counting my bytes to fit my program into that 4K. Imagine the euphoria on the day we were able to move up to 8K. The sky was now the limit! My first project was for Air Canada. In 1979 the requirement was to be able to do a transaction within 1.5 seconds from the time you hit the enter key till the response started to come back. From anywhere in the world, over a 2400/4800 baud network. We also made the equipment on that network (not the modems). When I retired, the specifications for the last project (not AC) was to do a transaction in a blazing 15 seconds and that was over a modern, FAST network. My how times have changed!
We might have met at 151 Front? I used to maintain the 7015 plated wire memories on the 4×4 1110 at AC. Even watched the CN tower top off from the maintenance room window :-)
No, I worked for Westinghouse in Burlington, and we made the 40x terminals and the concentrators for AC.
Ah, then you probably knew Dean and Manny, whom I hired to work for me at Computer Logics, terminal emulation for Univac.
I worked in Comms & Networking at WEBO. I do recall that we designed comms interface cards (SDLC, HDLC) for interfacing Novas and Eclipses to IBM machines, and maybe also an IBM data channel interface card?
IBM was king back in the 70s/80s, and DG wanted a piece of the pie. Being able to say your machines would connect and talk to IBM machines was a big deal. If you had an IBM mainframe, DG would sell you stuff to connect to it. Stuff you couldn’t get from IBM.
In 1980 or 1981 we had a 3158 mainframe whose market value was null and I decided to garbage it, allowing employees to pick any part they wanted.
For my own usage I kept the main console which was some kind of 3270 in order to replace the ksr33 l was using at home with my fully home made micro computer running CP/M on a Z80.
I made a direct access somewhere in this 327x specific device (a real hack!) and a tiny character translation for charset, EBCDIC ASCII, in the Bios.
My first display!
In the early 80’s we designed a pcb for both the Apple //e and Apple /// that could remotely connect to an IBM mainframe and act as a 3270 with 3274 terminal attached. We sold it to Apple. I designed the hardware (Z8 + Z8539SCC IIRC) and coded the SDLC protocol layers and Owen wrote the Apple code that emulated the terminal. Luke did the testing. All code loaded from an Apple floppy. We then built modems to do the connection. Fond memories:)
So? Why DID they pick 93 ohms?
My guess? So the installation would have to buy their coax from IBM.
Ha. Classic. Silly me, I’m here just wondering why a terminal is hooked up through coax at all? I never had to work with one of these. It doesn’t just use a serial port? Or was the coax just for the video signal? I should prolly just watch the video or RTFM but I’m starting to get to work for the day so I’ll have to save it for later.
The old amber-phosphor dumb terminal I have sitting in the den just uses rs-232 and a big beige XT keyboard. Still use it to ssh every now and then just for the sake of variety.
Google is your friend.
Start here: https://en.wikipedia.org/wiki/IBM_3270
I never worked with them either. Think of them as serial terminals, but without the smarts…they’re dumb, and IBM-like, which means clunky, external logic and really weird protocols to make them work. Like nothing you’ve ever seen before. No surprise that “glass teletypes” pushed them out. Except for banks and airlines. I remember seeing them there for a lot longer.
The “big iron” philosophy, applied to terminals :-)
Arguably, they’re not dumb – they’re more intelligent than your average (eg) VT220, as they deal with form processing and input validation locally.
It’s really very complex. I built the 3270 emulation for the Oracle n|c (both gen 1 and gen 2) under contract for Idea (in boston?) which was bug-for-bug compatible with the real 3270 – I still have some strange things in storage like a 122-key estonian keyboard. Worked better than IBM’s official 3270 emulator on the platform :)
Coax was used so you could have really long cable runs and a much higher data rate than rs-232. IBM always wanted to offload as much overhead from the CPU as possible. So these terminals were connected to an establishment controller box and that box finally connected to the mainframe. The establishment controller could use bus and tag or fiber as the connection to the mainframe. I think you could run fiber like 20km or so the mainframe could be in a different building.
For years I thought these old IBM systems were boring business trash but they did some incredible design work back then. They had hypervisors and virtual machines in the 1970s! Once these systems were installed they just simply worked forever and rarely needed intervention.
The “big iron” loads microcode for a support machine (an x86 box) so its upgradable on the fly. That’s also how you configure all the hardware like storage arrays and terminal controllers. Oh and the mainframes are serial locked to the support machine software. So if you lose that your mainframe can’t boot!
I remember them from the late ’80’s.
I had to interface a UNIX system of ours to a mainframe and exchange data. We did this through 3270 and some screen scraping/inputting via a 3270 emulator card.
I remember getting an IBM man in who did a little talk about it, when he got to 93 ohm co-ax my face must have been a picture! I blurted out “that’s not standard… anything”. He just smiled, and said “I know…”. My boss laughed – he knew what was going on!
Off the record, it was not impossible to use a different cable with a matching network change. Voided the crap out of the warranty. One does what one must when nearing system ripout. If you see one with a BNC and shielded toggle switch on it, now you know who to blame.
The terminals themselves were not real bright, but in combination with the controller (handled 16 units, IIRC), were quite capable compared to most, and fairly economical for a large install from the system point of view. They were actually a pleasure to use and rugged as heck, as well. Only thing around with a) detached keyboard, and b) decent keyswitches. As much as I liked the VT100 as a programmer, even under Unix, there was not a lot of support for things the 3270 handled natively, and the keyboards had a non-positive feel, though still better than many others (I mean you, televideo)
And they had that awesome solenoid clunker inside. It would shake walls.
I worked in a telco, fixing various terminals & keyboards – never IBM, most of those keyboards were real crap, no wonder non of that gear exists today.
people bag the PC clone ‘rubber dome’ keyboards – however they are light years ahead of what I had to fix. (as in they just keep working)
From Wikipedia:
“RG-62 is a 93 Ω coaxial cable originally used in mainframe computer networks in the 1970s and early 1980s (it was the cable used to connect IBM 3270 terminals to IBM 3274/3174 terminal cluster controllers). Later, some manufacturers of LAN equipment, such as Datapoint for ARCNET, adopted RG-62 as their coaxial cable standard. The cable has the lowest capacitance per unit-length when compared to other coaxial cables of similar size. “
What, no? Actual technical reasons?
Hams occasionally use the stuff to make phasing harnesses for multiple-element antennas… it’s close enough to 100 ohms for amateur work! http://wb5rmg.somenet.net/k5oe/Texas_Potato_Masher_2.html . I’ve got about 15 feet of the stuff left – a lifetime supply!
Actually, most HP terminals worked in both character mode AND block (page) mode.
On the HP1000 getting a terminal to give you a character at a time was PAINFUL. It was doable, but it wasn’t easy to set up. I do miss the FN keys under the screen though.
Well if you wanted to sell terminals past about 1978, you made sure they did everything.
Anything to use a beam spring keyboard in its natural environment.
Years ago I worked for a major auto manufacturer whose office areas were FILLED with 3270s. One evening, I happened to be working late, and observed a “penguin” (this is what we called the IBM service guys because of their corporate-mandated dress code) wandering up and down the aisles. I asked if I could help him, and he showed me a service ticket for a 3270 a few cubes away from where I sat. I showed him where he needed to go, and so off he went.
A few minutes later, out of the corner of my eye, I watched as he stood before the terminal, carefully lifted the 3270’s keyboard 2-3 feet, and then let ‘er fly. WHAM! The keyboard was heavy, and landed loud and hard.
Certain that something wasn’t right here, I rose from my cube, walked over to the penguin, and demanded to know what the hell he was doing. He sheepishly pointed to the IBM service bulletin he was working from. As it turns out, slamming a 3270 keyboard against a desk top was indeed the recommended action to correct certain types of keyboard malfunctions.
True story.
jammed ‘clacker’ solenoid, IIRC
I did not work with IBM 3270 keyboard, but with a (good) copy. So when a customer call and told me that the keyboard did nor work or it run without control, I always told them first to shake and turn the keyboard upside down. A little smash to the table also helped. And it did!!
Think on the woman that was sitting there the whole day with earrings , hair clips , the tip of a pencil etc. I have found a lot of funny stuff in those keyboard.
3270 still lives, mostly hidden and emulated, in the airline business
https://www.linkedin.com/pulse/monsters-from-past-airline-distribution-christian-kameir/?trk=mp-reader-card
“A lot of these old protocols were poorly documented or even secret. ” They weren’t secret, and they were extremely well docoumented by the vendors. Whether IBM, Sperry Univac or Control Data. I have 3270/SDLC and Uniscope docuemnts from that period (I worked for Univac 1968-1982, after which I worked for a company writing terminal emulators for CP/M and DOS). But the phrase makes things sound more impressive. a 1 miute glance at https://bitsavers.org would net you all the manuals you need, from that period.
Uniscopes were also block mode, but had a lovely feature where only data entry fields were transmitted, this was used extensively in airline reservation systems such as for United Airlines and Reservec at Air Canada in the 70’s/80’s.
Zilog SCC chips supported SDLC and other synchronous protocols as well, nothing was secret, seriously.
Reservec in the 80s used Air Canada’s own proprietary protocol unlike either ALC, Uniscope and the 3270 protocols. I know, because I developed the terminals they used from ’79 through about ’82. In my day… those days … I had written emulations for all of those protocols and airlines. Yes Uniscope terminals had a ‘forms’ mode, but the airlines didn’t use it … much.
Yes, the protocol manuals were definitely available. Used them to develop Bisync and SDLC with the venerable Zilog Z8530SCC. But there were protocol violation by IBM on various models. There was a company in the USA that knew most of the violations and they would check out your implementation for $$$.
How Awesome!!!
This is LU0 and LU2 comm types. The old mainframes only accepted a screen of data, not a stream of data. Burroughs, IBM, and others all used this – many for Banking applications. As mentioned above – SDLC synchronous protocols were used as opposed to asynchronous comms. 3270 was but one of many protocols, X12? It’s been a LONG time since I coded for that. When PC’s came out hard – many software companies, like the one I worked for, wrote screen software using the SDLC cards to do comms for Banks, using the PC for emulation and HLLAPI, Even as late as 1995. I’ve actually had to do protocol data tracing when they came out with the 16 byte FIFO on chip. It didn’t works in many applications and had to be disabled. Man I’m a dinosaur.
3270 is alive and well, in terminal emulation.
RTFM: man tn3270
The key benefit of the protocol is once the Machine filled the screen, and you did data entry, which could be constrained to data ranges, you hit the SEND key.
This sent the -changes-, so it was pretty damn efficient, and more importantly, users perceived it as “snappy” over in the day slow Internet connections, as opposed to telnet / ssh.
Banks, the airline industry, and basically all of the wired (former Bell) telcos in the US still use this interface, even if they have fronted it with screen-scraping GUI-looking interfaces.
The dead giveaway is if you tab to get from one field to the next on a data entry screen, there’s some 3270 in the mix somewhere.
I ‘member doing that for some end of day record keeping on something plugged into an AS/400 box, but I guess it was a descendant.
I’m not _quite_ old enough to have cut my teeth on big iron, but I did manage to use 3270s. In ’96 or so I had a seasonal gig taking phone orders for the Christmas rush for Harry & David (the Fruit of the Month Club people), and the whole operation was done in a sea of open-plan desks in the upper floor of an old Bell/US West building, each desk with a telephone and a terminal. I think they replaced the whole shebang with windows boxen the next season.
The next year must’ve been the time my fruit arrived spoiled.
B^)
RPG in the old days *was* very rigid, but not that difficult to deal with. More in common with assembler than with free-form languages, so perhaps more suited to those with that kind of mindset. The acronym comes from “Report Program Generator”, so it was designed for batch-style programs like payroll runs, and not best suited for interactive programs.
RPG these days is almost completely free-form, if you prefer it that way.
And it’s fast, at least compared to the same program in COBOL.
Walmart still uses a 3270 emulation program on a PC talking to an IBM mainframe to do their employee scheduling. Back in the day I used a real 3270 to edit with EDGAR on VM/370. I thought it was pretty good for a character style editor. I remember that the push/pull on/off switch doubled as a brightness, but often you would pull on it too hard and it would come off into your hand. Then if you tried to put the switch back into the terminal, you would end up turning the terminal off. Probably ending you session and losing all your edits. Not a good design. I think they fixed it in later versions. About that time, people inside IBM were working on a 3270 that had an Intel processor chip in it. It was always a hard sell because the chip was not testable using IBM’s test technology (LSSD).
I’ve got an AS400 from 1984, as well as one from the later 90s, and a Power 7 and Power 9 at my office both running i/OS.
I really should spin up the old AS400. I wonder if I could get it online and doing some pretty wild stuff.
Hi, what about a quick look here – perhaps it would be possible to merge the projects ?
Here’s the Link for a USB 5250 converter :
https://deskthority.net/viewtopic.php?f=7&t=23885&hilit=5351+USB
The headline is : “IBM 5251 terminal USB conversion (but not what you think)”
One of the CEs (Customer Engineers) at the university where I worked said that 93 ohms was picked because it was the output impedance of the ECL (Emitter Coupled Logic) used in the mainframes. Inside the mainframe, they used ‘trileads’ (think: 3 wire ribbon cables) of the same impedance to interconnect modules. The reason for the low loss of RG62 is that the inner conductor is wrapped is a spiral ‘filament’ and then a thin tube of insulator around that before the shield, which leaves mostly air between the inner conductor and the shield. This is necessary to get the impedance up to 93 ohms. I’ve run many miles of RG62!