When IBM brought out the /360 mainframe in 1964, one thing that took some getting your head around was processing Condition Codes.
Many operations set a “condition code” which indicated the result of the operation and which could be tested by a Branch-On-Condition instruction:
BC xx,yyyy = Branch to yyyy on Condition xx
Part of the problem was syntax – the term “Condition Code” had two meanings:
IBM at it’s best
This special system was built specifically for NYSE to report trading data.
Two /360 Model 50s, RPQ’d to function like Model 65s.
RPQ’d to use Channel-to-Channel to signal each other
RPQ’d to fetch from LCS
LCS non-volatile memory, configured:
or 4megs simplex
or two separate 2-meg units.
RPQ’d to feed the LCS’s 4-byte memory fetch to accomodate the /360-50’s 2-byte memory fetch. Continue reading
I joined IBM in 1963 and began working on Unit Record installations (punch card equipment). I found the work sometimes challenging but always enjoyable, as I’ve noted elsewhere in this thread. I moved from a sales office to a datacenter in the TimeLife building in NYC. In addition to the datacenter, IBM had an education center and part of Systems Development Division. In the datacenter, I learned the 1401, 1460, 7090, 7044 and 7044/94 Directly Coupled System which used the 7044 as a front-end for I/O and job scheduling and let the 7094 devote itself to number crunching.
When the System /360 was announced in April 1964, we were all given a day’s “training” but only the senior Systems Engineers really got their hands on the new system initially. I recall all of us being puzzled about how the /360 could have 16 Condition Codes expressed with only two bits. It took awhile to get our heads around that and it still confuses people new to the hardware. Continue reading
When I worked for SIAC, the IT subsidiary of NYSE/AMEX, we used to keep an MVT Abend Dump around to use when interviewing prospective programmers and Systems Programmers.
We’d hand the dump to prospects and wait for their reaction. The guys who said, “The program bombed”, without looking deeper were immediately crossed off our list. We finally interviewed a guy who spent 10 minutes examining the code and scratching his head before admitting, “I can’t figure it out. It’s impossible. That failure couldn’t have been caused by that instruction”.
….but I found it hilarious. Continue reading
In April 1964, IBM announced the System /360, an entirely new line of mainframes. It was a complete replacement for their existing hardware and all mainframe users were expected to move to the new platform. To ease the transition, they implemented various emulators but it was still a massive undertaking for both IBM and their customers.
I spent about 50 years working on IBM mainframes and I wish the Wintel world were as easy to master as the mainframe world. Today’s CISC mainframes have a much larger instruction set than Intel systems. This means there’s a lot more to learn but it also allows the code to be much cleaner, elegant and coherent and by reducing the number of instructions, reduces the logical complexity of programs and thus reduces errors. Coding in Assembler does require a knowledge of the hardware as well as the principles of programming and logic. I’d venture to say that if all the people coding high-level or scripting languages had to understand their hardware at the instruction level, most would be doing something else for a living.
In the Wintel world, it’s not uncommon for a new release of the Operating System to ‘break’ programs that previously worked. Given that users are running both Microsoft and third-party code, it’s understandable that problems crop up. IBM’s mainframe OS, on the other hand, has a reputation for being 100% backward compatible. A program that would run on OS PCP 1.0 will run on the latest zOS version. This is because IBM puts a LOT of effort into making sure new code is compatible with old code.
In 50+ years of working with the OS, I’ve only known of one upgrade that broke anything, when the logic of Write-To-Operator and Write-To-Operator-Reply functions changed. And that problem could be fixed by a simple re-assemble or re-compile, as long as the programmers were using IBM’s coding tools. Continue reading
I began working for IBM in 1963, on Unit Record accounts, and there was as much fun and challenge in wiring a 604 or 403 board as trying to stuff a 13K program into a 12K 1401 or debug the various releases of software for the S/360. I spent 5 years at IBM, then 5 more years at a software house, a year freelancing, then 24 years at NYSE and its subsidiary SIAC. From 2000 to 2013 I worked at HealthQuest.
From 1968-1972, I worked for Complex Systems, a software house specializing in TP code. I did application programming but spent most of my time doing Systems Programming, Systems Engineering and Systems Design.
NYSE was one of our primary clients and I consequently spent a lot of time on the 1/2 floor overlooking the machine room at 11 Wall St. I admit to being a bit of a maverick, including my attire. I was particularly noted for a dark blue ‘western-cut’ suit, navy blue Stetson and black cowboy boots (which got me christened ‘Midnight Cowboy’).
Some equipment arrived in bubblewrap and I laid out a stretch of it about 2 feet wide and 15 feet long, just outside the control center and the offices of the VP in charge. I did my best impression of a flamenco dancer, pounding my way poppingly down the corridor, ending with a grand flourish right outside the VP’s door.
My ‘ta da!’ moment was somewhat dimmed by the discovery that the VP was entertaining an Executive VP whose jaw dropped in shock at my dramatic performance. Right then I was very glad to be a consultant rather than an employee. 😀