A Legacy of Wisdom: The Dr. John Ehrman Interview – Part III

EDITOR’S NOTE: This article is part of a series inspired by an interview with the late Dr. John Ehrman, conducted by Reg Harbeck at SHARE Atlanta in 2012. Catch up on the series by reading Reg’s introductory article here,  Part I by Ray Mullins here, and Part II by Reg Harbeck here.


What did the “father of HLASM” and one of the great supporters of SHARE indicate was a key ingredient of success in the mainframe ecosystem? The fun of the mainframe!

As anyone who knew Dr. John Ehrman realized, not only did he care deeply about everything he was committed to, he also had fun with it. He discussed the role he played in the success of Rexx, XEDIT, and VM as follows:

“We were one of the early test sites for Rex and for XEDIT. Rex at that time was spelled with a single X. XEDIT in particular was such an advance on any of the other editors available that our users were turning up bugs at a great rate. And some IBM executive came out and said, ‘Well there are so many errors in this thing, we’ll have to kill the product.’ And the managers had to say, ‘No, no, no! They are finding bugs because we like it; it’s products that nobody likes that don’t show any bugs.’ And so, we’d like to think that we helped to keep Rexx, XEDIT, and VM going. I’m sure we did our small part.”

Dr. Ehrman just kept having fun, trending toward his historically important participation in the development of mainframe Assembler, as he related:

“Also, at that same time, because Stanford’s an educational institution, we had allowed eager young lads who wanted to learn more about programming on big machines to come and take on an unpaid job just doing some fun programming. And a number of them turned out to be very, very bright and were eventually hired as assistant programmers, one of whom who went on to join IBM at the TJ Watson Research Center and became responsible for all of IBM’s infrastructure at the Sydney Olympics in, I think, the year 2000.

“One of these young gents got very interested in Assembler—at that time, the IBM Assembler H, which has its own interesting history. It was developed as a skunkworks project by what they call the Assembler Mission in San Jose. And the official sequence series of products at the time, things like Assemblers E, F, was what came with most OS systems. H was done to experiment with some fairly advanced program analysis techniques.”

As the fun and Dr. Ehrman’s contributions continued, he soon joined IBM as an employee and participated in straightening out some Fortran monkey business:

“I happened to be at a SHARE meeting, when an IBMer asked, ‘Have you ever thought about leaving SLAC?’ It was an opportune time, so I interviewed and got a job with IBM at the Santa Teresa Lab, now called Silicon Valley, in ’83.

“My starting date was supposed to be April 1st, which I thought was appropriate, but they invited me to an offsite meeting for all the languages staff on the preceding Friday. So my official start date was March 29, or something like that.

“I joined the Fortran team and immediately started going to SHARE conferences as an IBM rep to the Fortran project. It was a lot of fun because, at the time, Fortran was a very, very strong, actively used language in many places. It was the primary tool for scientific computation. One of the shortcomings of Fortran at the time was that it was at the Fortran 66 level, which had no program structuring facilities, and the new standard, Fortran 77, had come out with a number of improvements. IBM had been a little slow to adopt this so, when I got there, they had pretty much done an analysis of what they would do with a Fortran 77 product. Unfortunately, the people who had done the analysis decided all that was really needed was to support the standard, but not backward compatibility with existing programs. So, when the brand-new VS Fortran compiler came out, it turned out that most existing programs would fail, primarily because the VS Fortran compiler insisted on adhering tightly to the standard and, in some places, making existing Fortran code fail.

“There was one very large customer who had a large business analysis program [comprising] something like 50,000 lines that, when compiled with the initial Fortran compiler, got about 100,000 diagnostics. At the same time, coincidentally, Fujitsu came out with their processors—clones, if you like—of the 360, and a compiler, which the same analysis program went through with just one or two bugs. [It] would go into execution when those were fixed, went through runtime bugs and everything was fine. And, at that point, this very large customer called the IBM vice president to their site and said, ‘You either fix this or we dump all of our hardware.’ At that point, things got fairly exciting in the Fortran group at Santa Teresa Lab. [At] the next couple of SHARE meetings, the meetings of the Fortran project were noisy. Lots of what I’ll call ‘suggestions’ being made. And eventually they pretty well got turned around and the number of user improvements and suggestions had been embodied. It turned into a much better product with a lot of very useful diagnostics.”

All this time, his involvement with SHARE and GUIDE continued to advance, as did his journey to the heart of the future of HLASM… stay tuned!

Recent Stories
SHARE Phoenix: Women in IT Initiative Makes a Splash

SHARE: GAO’s Mainframe Risk Claims Debunked

Lost in Translation