Barry Schrager Looks at the State of Mainframes
Reg Harbeck talks with Barry Schrager who recounts his career and explains what’s missing among today's mainframe operators and administrators.
By Reg Harbeck03/20/2017
Reg Harbeck talks with Barry Schrager who recounts his career and explains what’s missing among today's mainframe operators and administrators. Listen to the interview via the orange play button or read the transcript below.
Reg: Hello. This is Reg Harbeck and I'm here today with Barry Schrager, who is the author of ACF2 and the founder of the SHARE SECurity project. I have the honor of learning about Barry's background both with the mainframe and with SHARE and any other area to do with the mainframe ecosystem, especially with computing security. Barry, if I can get you maybe to introduce yourself and tell us about your background and how you got to where you are right now.
Barry: Sure. I started off life in the computer facility at the University of Illinois in Chicago. My first computer that I ever met and used was an IBM 1620, and when I was a student they moved to the IBM 360-[Model] 50, and I started using that. That was on OS/MFT and MVT and so on. I actually—obviously did very well because they asked me to come back after I graduated, although I did spend one semester at Northwestern University working on a master's degree. Then I went part-time after that.
So when I came back, we installed MVS and I installed TSO. One of the issues was that we had what you would call in today's environment, student hackers. Their goal was to screw people up and crash the system. So one of the things we had to deal with was—you know I had professors who had basically read-only data that they wanted their students to deal with. I had research—graduate students who had research data that was getting overlaid, and so that caused me to take a guy who was working for me, Eb Klemens, and together we worked on a pretty basic arrangement.
I created what we called Resident Account and that validated users as they entered the system. Then Eb used that identification to say, if the high level index matches your user ID or whatever you want to call it, then you own that data. If the first character of the second-level index is a dollar sign, it's yours only. If it's a pound sign, everybody else has read access and if it is something else, it's open season or whatever you want to call it.
That was the beginning of security and that work led me to discussions within SHARE, and SHARE asked me to form the data security project. They asked me in '72. Interestingly enough in '72, a guy named Eldon Worley and I gave a presentation together on our views of the future of data security in the mainframe area. Of course, Eldon is the author of RACF, so this is 40 years ago that Eldon and I were together giving a presentation—
Barry: ... which is significant. Anyway, so then as time went on, I improved the—you know IBM came out with a RACF product that—we produced a series of requirements in '74 from the project. IBM came out with its RACF product in ’76, which was not Eldon's RACF—this was a predecessor to Eldon's RACF that didn't meet very many of the requirements. Significantly the ones it didn't meet were protection by default and what I called algorithmic grouping of the users and resources—what in ACF2 I called pattern masking and RACF calls it generic profiles in today's world and language. IBM basically, when I confronted them with it, they said it was not possible to do those things. That led me to want to create something that met those requirements. So I took what we had—what Eb Klemens and I had done at the University of Illinois and improved it. I basically created the ACF2 rule compiler and the interpreter and so on.
Let me get this straight—in early 1977, I got the prototype working, and it really was a prototype. I mean the rule compiler was written in PL/1 and things like that. I mean it was not a commercial version, but it did prove that the concept worked. And I—where did I go? My boss, Dr. Tom Brown, the Director of the Computer Center, went to the University of Illinois Foundation asking for support in making it into a commercial product because we had several people who asked me for it to be distributed and it just wasn't usable. The University of Illinois Foundation said, "is it in a commercial working state yet?" My boss said no, and they said "well we don't want anything to do with it."
Then Ron Murray, from your neck of the woods in beautiful Ontario, Canada, called me up and said "Look, I'll pay for it. Come up and do it. We'll pay your expenses. You can have the computer time" and so on. The thing that happened at the same time was that General Motors was really disappointed with RACF. They had Delco division, which had RACF installed 18 months now, and had only 3 percent of their data protected. General Motors Research was at 5 percent after two years. This was just an unacceptable level as far as audit was concerned. They were interested in pushing me a little to be able to push IBM. I don't know if you remember Martin King—
Reg: Oh yeah. Examine.
Barry: Martin created Examine, but Martin King was as an auditor for General Motors at the time. General Motors basically said to me at the time, "if you get it working, let us know."
Barry: I went up to London, Ontario, in the middle of the winter and got it working. Eb Klemens and I, and then Scott Krueger joined us later. Then General Motors installed it at Pontiac Motor Division. In three months, Pontiac had it at 100 percent data protection.
Barry: Then Assembly Division came next, and so on. The thing that Martin King told me at—you know, maybe 10 years later, not at the time—was that "you know, General Motors wasn't really pushing you." He said they were pushing you to try and get IBM to fix RACF. He said it just worked so well they just said go on. So General Motors at the end of the first year, this is in ’78, sent out a letter—the audit group sent out a letter to all the divisions saying, "you know we think data security is important. We want you to install either ACF2 or RACF. Both meet our criteria. However, you should understand that the installations who have installed ACF2"—and he listed them all—"were at 100 percent data protection within six months." Now RACF—these are the installations that had it—none of them are over 5 percent data protection. We don't know what percentage should be protected, but we know 5 percent ain't it. But we certainly agree 100 percent is it.
Reg: Hmm. Yeah.
Barry: So that was the beginning of ACF2.
Reg: Cool. Now I understand that since then RACF kind of got brought up to the same standard. Do you know much about that story?
Barry: Well IBM—when RACF was a complete failure, my understanding is they went to Eldon, who had been working on his own project. They asked Eldon to come in and basically rework his stuff into something that would fit within the RACF structure. At that point in time, they created the generic profiles and protection by default and things like that.
Reg: Cool. So basically by around the 1980s ACF2 and RACF were both running at 100 percent meeting the requirements?
Barry: I would say in mid- to late-80s.
Reg: Okay and of course by—
Barry: Because Eldon didn't come back into the game until like '83 to '84.
Reg: Ahhh. Okay. Of course by that time Top Secret existed as well. Now how much—how conversant are you with its entry into the group of three as it were?
Barry: Not much. I remember—I remember it being introduced and I forgot the name of the company.
Reg: CGI or I think CGA products.
Barry: CGA Allen or something like that?
Barry: And it wasn't doing that well. It's interesting because Top Secret, if you look at how it works, it's completely opposite, directly opposite of AFC2 and RACF.
Reg: Right. It is user-oriented.
Barry: RACF is based upon the resource and figures out who can get it. Top Secret is: here are the users; what can they get to?
Reg: Right. Right.
Barry: But I mean they both solve the same issue, answer the same question. Top Secret never bothered us until it was bought by CA. Then CA started giving it away.
Reg: Hmmm. Ahh.
Barry: It's hard for a little company to fight CA, a company as big as CA, because Top Secret wasn't a bad product. So here's an alternative. It's free, baby. Take it.
Reg: Yeah. No, I hear you. So eventually ACF2 joined the CA pool as well, I guess when—
Barry: No. I refused to sell to CA.
Reg: Ahh. So you sold it to UCCEL. UCCEL and they sold it to CA.
Barry: Yeah and I don't know whether they were in conversations with CA at the time because it was only like 7 to 8 months later.
Reg: Ahh. Interesting.
Barry: They were sold to CA.
Reg: Now of course you stayed very active in the mainframe security space even after selling ACF2. In fact you were involved with an effort to define a really idealized version of mainframe security based on a relational database. It didn't take off but it had some really neat concepts—called DEADBOLT, about what? Just under a decade ago now.
Barry: Right. What happened was that—when I sold to UCCEL I had a five-year non-compete and so I was out of the business for all then. Eb Klemens asked me to come back. Eb, of course, did ACF2 with me and he had quit SKK before we sold to UCCEL and so therefore he was not under any kind of non-compete. He actually rejoined us.
Eb went to UCCEL and then CA, then left CA and formed his own company, EKC, Inc. He called me up and asked me to come back, and so I did the first access analysis products for both data sets and resources, and I also did it for RACF. So those are still products that Eb is selling.
Then I left Eb and went to Neon Systems to work with the Shadow product. So I did things like DB2 two-phase commit support. Then they were trying to sell their company and they started cutting costs and I was one of the people who, according to Wayne Morton, the technical support manager, was your name sorted to the top because of your salary and basically you got cut. But that was a John Moores investment company, and about a month after that happened, John asked me to form a group to create DEADBOLT because he wanted to create a new, really customer oriented, software company.
Barry: John put in some really poor middle management and it fell apart, but it would have been a great product. I had it all set to be tested at the U.S. Senate and so on, and then, to save money, they terminated all the people who could stand in front a group and get instant respect. It was really weird.
Reg: Well it was certainly an interesting part of the history of the mainframe you know that whole experience. One of the things I'm really finding as I dig deeper and deeper into the mainframe ecosystem is just how important each individual personality in the mainframe is in terms of what happens next on the mainframe, and just how right now the personalities that seem to be predominating are—a lot of them who are very, very conservative about trying anything new or taking any risks. I feel like we're getting to a tipping point sometime in the next five years where that is going to flip upside down. There is going to be a whole lot of new risks coming. What are your thoughts on that?
Barry: I think that the problem is that the mainframe now—and we're talking about stuff that has been running for 30 years—I'm now on a long-term contract with a very large organization and I see, you know, stuff that is there since, you know, 2000s. That's not bad but it means that—and now the people have changed over several times and of course you get the situation where the people who have only been there a couple of years are afraid to touch anything. Also you don't have the—when we were in the mainframe community, everybody grew up through the mainframe and learned how to program and things like that. Now you got basically people who know how to operate it and administer it. They don't know how to program it.
Reg: Hmmm. Right.
Barry: So that's what we are running into.
Reg: So we've got a little bit of time left just for any closing thoughts—if you have any additional thoughts about the mainframe, security, SHARE, anything else just to sort of tie up this conversation with.
Barry: You know, security is a big effort. The company CA has to put time and money and effort into it. Unfortunately, I see they're cutting staff. So I mean, that's key. ACF2 and Top Secret which are close—certainly ACF2 is close to my heart—and it's a great product. I'm now using it as a customer. It's great but you know the mainframe has to be—we have to keep expanding its usage and everything else and keep it up to date and on top of things because it is conceived as the centralized processor, whereas everything is distributed. I don't know how—I mean I understand how you can manage—it's easy to manage a mainframe with two Sysplexes—I mean two individual boxes in a room or three boxes in a room but I just can't conceive of 500 servers or 1,000 servers, you know, all wired together and actually working, doing something.
Reg: Well Barry, thank you so much for taking the time for this conversation. It's been a really great source of insight. I certainly appreciate every opportunity. I always learn something when I talk to you.
Barry: Great. It's nice talking to you, Reg.
Reg Harbeck is a mainframe enthusiast who has worked IT and mainframes for over three decades. He's the chief strategist at Mainframe Analytics ltd.
See more by Reg Harbeck