Bob Blackmun
Recollections, 1961 - 1982
I came to Cornell almost 40 years ago as a freshman engineer in the fall of 1961. A lot of what I remember is tied in with computing. I remember the Engineering College had started a whole new curriculum that year and we were the first class of that curriculum. They had us do an introduction to computing part of the introductory course in "What it's like to be an Engineer" and they taught us CORC. Conway, Maxwell and Walker had done CORC on the 220, I guess Dave Freeman did it on the 1604. We started out on the 220. I remember going over to Rand Hall and learning how to program. It was really exciting. But what I remember now looking back, is that it was kind of the tip of what I remember best about Cornell and what Cornell did for me, was teach me to want to innovate and do new and exciting things. CORC was incredible at the time, and to me, looking back again, it revolutionized teaching and learning about computing. You didn't get wrapped up in mundane details. You could keep your eye on getting the logic of the program to work and the program, CORC, was telling me about my syntax errors. To me that was truly an amazing thing. And I look back at it and it's still amazing. It was a technology thing that had real application.
I remember then the following year there was a sign up in the computing lab that they were looking for consultants to teach the next freshman class. I don't know who I talked to, if it was Bessel or you, but I got a job as a consultant. That was either the beginning, although I'm not sure what that was the beginning of. I remember doing that. Then I remember I learned how to operate the 1604 working with Amos (Ziegler) and Dave (Pulleyn). That's how I remember Amos because Amos' and Dave's style on teaching people how to run the 1604 were exact opposites. But then I also remember, and I don't remember if it was you or Bessel, to go over and see Tom Harp, the football coach, about taking over maintaining and running a (Scouting Report) program that had been developed by a graduate student. They used to take all this data when they scouted an opponent and put it into this horrendous statistical analysis. You and I today would call that a database. I learned all these database techniques and all these strange ways of cramming data into 32K of memory. Bev Reed came in on Sunday morning and punched in the data and I came in and fired up the computer and ran the reports and checked them all and took them over to an assistant coach in the football office. But I really remember just being amazed at this very, very, innovative creative application doing very sophisticated data analysis for sports teams on line too! This was a batch program, which produced a big printout to find what they wanted. I also remember learning a lot about programming techniques. I taught myself Fortran at that point. But I remember that as something I inherited and took over and learned an enormous amount from.
I remember using a lot of what I learned, when I think it was with Bessel as you were in graduate school when I was in the MBA program when I ended up writing a program for Pete Jackson that analyzed the class size experience of Cornell students. Again we were taking data we got from Machine Records before Computing Services started. We got these data tapes and I had to figure out the formats, etc and take this humongous amount of data and figure out how to cram it into 32K of memory. Actually, it was less than that of course but that's all we had for programs and data and everything. We didn't use tapes as we were tying to create this big array which we could analyze the data, so again, trying to create a big database. If we had the technology we had 20 years later, it would have been trivial to do. I was thinking about this the other day because part of the project I now have in my organization is a fairly large data warehouse project. We are using an ETL tool from Informatica rather than writing the transformations and so forth, our people have learned this elaborate tool. I was thinking the other day, "Where were you 35 or so years ago when I was trying to take all this really ugly nasty data which is basically student registrations. Now, we collect student registrations from our 58 colleges and we do all this horrendous processing to put them into a big database. Before we developed the database we were doing with flat files on an IBM mainframe. So, looking back early on at Cornell we tried to do things that couldn't be done through really clever people figuring out how to do it. I remember Walt Bilofsky and John Berenberg and Dave Bessel and that crew and all the strange and wonderful things they did with the operating system. They were just ahead of their time. I don't think anybody else even thought about doing those things.
You probably remember that I worked on the "Best of CAUSE "publication that we did in 1991 on CAUSE's 20th Anniversary. One of the tasks I was asked to look at was the organization of computing in Higher Education. I went back through all the CAUSE magazines looking at when organizations had decided to combine academic and administrative computing, which was thought to be this wonderful innovation. Cornell did that back in 1966-67. We had no idea how to do that. I don't know if it was Dick Conway's idea but he was in charge of it and it turned out to be extremely hard to do, not because of the technology but because of the people and the politics. It was really hard to fit the different mentalities and cast of characters together.
Then of course when Computer Services was formed and put everybody on a shared computer, IBM's time-sharing software didn't work. So Conway and Maxwell and so forth started working on that. Eric McWilliams came after that and he brought in Bill Worley. I remember Bill Worley, over a weekend, writing a really crude brute-force time sharing system. They had this huge extended core memory and he just allocated a piece of this extended core memory to every user logged on and that will be where their stuff will work. As I said, over a weekend he developed this system. The others in Conway's skunk works were Howie Elder, Howie Morgan and I almost think Worona started to appear on the scene.
This group did two things. They wrote the student batch, which was remote batch entry and of course that was necessitated by the fact that the Computer Center was five miles off campus at Langmuir. But the other thing that it allowed was the Finger Lakes Regional Computing organization. I also remember sitting, when you were in the basement at Upson, picking up the phone one day and there was this guy named Dave Smallen.. He said, "I'm Dave Smallen. I'm from Hamilton College and I want to talk to you about remote access to Cornell's computing facilities." You and John Aiken and Al Personius were shuttling back and forth to Clinton to talk to Dave Smallen. (That lasted until the late 1980s when personal computers and superminis came along and Hamilton could provide their own services.) The Finger Lakes Computing organization only proved that if you give colleges access to computing, they will eventually and pretty quickly develop their own computing capabilities. I do remember all this innovation.
What about CRBE? I think that might have been the thing that Worley did. It was terminal access. It was very crude and brute force and didn't scale but it did the job, but it was real quick and dirty. I also remember Bill very much because Bill's thought process was to walk up and down the hall and think about something and then run into his office and write it down. And then he'd come back out. We knew that something important was going on because Bill was circling the building. He was one of these people who would just get in the "zone" and he'd innovate and figure these things out.
We were talking early about the Library Acquisitions systems that was done, the Alumni system that was done, these were all administrative applications that were done long before commercial packages were developed. They were very hard to do. They all evidenced Art Peterson's rule. He was the University Controller and he had three rules of administrative data processing. I must have learned them well because I repeat them to a lot of people even today:
- It's not going to work as well as you say,
- It's going to cost more than you say, and
- It's going to take longer than you say.
I kid people, only half kidding, that Art Peterson's rule is alive and well. Everything always costs more and takes longer and has less functionality. (Rudan commented that the recent rule he learned from Steve Worona, so called Worona's Rule was, "The sooner you start, the longer it takes!") I think that's probably very true. In fact, if I were going to criticize what we did way back then was we always started when we had this flash of brilliance.
I learned much later in my career, when I moved to a public university where it takes 2 or 3 years to get the money to do something. That the time that you spend getting the money to do something also let's you do a much better job planning for it, both politically and technically. So, when you get the money finally to go ahead and do something you have thought it through, you've carefully planned it, it has been vetted by everybody and there aren't any detractors. This project which I mentioned earlier, we started four years ago and we just went live with the first piece of it at the beginning of July. It's going pretty well because we over planned it. But back in the early days of Cornell, we didn't' have that problem. It's not that we needed money or we were looking for it as we didn't have a lot of money, but we had clever people who would have a flash one day that something was needed, and the next day they would figure out how they were going to do it, and the next day after that, they were off and doing it. Steve Worona's mail system was like that too. He saw that there was a need, and instead of going out and getting a grant, he evolved it and people would say, "Why don't you do this, or I don't like that." You may remember that the most famous part of Steve's mail system was that people wanted to be able to read their mail without the sender knowing that they had read it. So he invented the "Peek" command which allowed people to peek at their email without the sender receiving an acknowledgement. They found out that if I sent you an email and I got an acknowledgement that you read it, I would be demanding an answer. That's why acknowledgements disappeared because people said they preferred the peek command. There were many of us who only peeked at their mail and never opened it.
The whole notion of a shared administrative/academic computing center created just unbelievable complexity in terms of the operating system, in terms that operations had to worry about, the competing demands. One of the things it taught me, and I carried it when I went to North Carolina 19 years ago, is that when you are going to share resources you can't share resources that don't exist. I may have learned that from you when we had to deal with the UCB and computing allocations and budgets. The leverage that Conway and others talked about that we are going to somehow take these, inadequately funded administrative computing, inadequately funded academic computing, this opportunity to do regional computing with no money. You may remember that our regional computing organization grant had the smallest grant that NSF could give. There were 8 or 10 grants and ours was the smallest one. (Rudan noted that he wrote that grant as his last task before leaving for graduate school and that his recollection is that we were one of 3 funded!) It was the smallest one. I think we knew after the fact that one of the things that NSF was looking for was "How much is too small?" We found out how much was too small because we didn't have enough money to do it, and the university did not have any money, and the 360/67 failed us. I think a lot of what we learned, in some ways negative lessons, although at the time we always felt very positive about what we were doing and giving presentations. I also remember Ivy League directors meetings, which were basically, brag sessions where every director was bragging what they were doing besides acting as a support group and information sharing.
It also took us a while to recognize that the capacity planning model was one which said we were out of capacity when the system was running at 80% and not at 100% which was the carryover from the job shop model. I was involved in those discussions. This is where the priority system came from and that I worked on so hard for many years. If you had priority pricing you would take up that extra capacity with low priority work that didn't need to get done but could be done in the otherwise idle time. That was the whole idea that the dynamic priority pricing model but of course it neglected the fact some people had real money and some people had funny money. It's interesting. I'm involved with the North Carolina Research and Educational Network at MCNC where we have a gigabit network running in the center of the state. So people are involved with the Internet Engineering Task Forces and so forth. It's the first place that "Abilene" actually ran within the RTP. We're worried about quality of service and differentiated service. I'll tell you why we are worried about it. In the North Carolina network we have a gateway to the Commercial Internet that consists of 4 OC-3's that are 100% saturated for about 12 hours a day. The CIO at UNC-Chapel Hill, Marion Moore, says, "Of course, IP is a very efficient protocol. It will in fact let you be 100% utilized." The question is what kind of response are you getting? In other words, back to the 80% issue, we are asking the wrong question. The question might have been, as I perceive it now, "What kind of results are you producing, what are the outcomes rather than the inputs?"
What's interesting is that we keep talking about these quality of service issues. We started a project in North Carolina to instrument the Internet at the campus level, because the campuses have to share the cost of this gateway, which is about $1.5 Million a year now. Some of the larger campuses like Chapel Hill are paying a couple of hundred thousand a year as their share. I was the chairman of the committee that figured out the cost sharing algorithm — so we came up with the formula which was 50% E & G budget and 50% headcount. It means the big ones pay through the nose and they should, as they're the ones, which can make the best use of it, and besides they're the ones connected to the gigabit network and generate most of the demand. But the quality of service issues really are a lot of the same things we wrestled with in trying to figure out time sharing scheduling and all those other things. Cogger was involved at one point and Worona too, trying to figure out how to optimize.
The one I remember was the shortest first job scheduler. We had shortest first with aging, and that was great with batch jobs, but it falls apart with timesharing. The Internet queuing model, quality of service model and so forth, are the same thing. If all you are talking about is ftping stuff, its pretty easy, but when you're talking about real time, IP video is the "killer" application. I don't mean killer in the sense that spreadsheet made the Apple micro popular, but the killer app. One of the things I remember about working at Cornell was that the good news was we had bright ideas and innovation but my criticism would be that when we got to the "killer" app we would stop and go off in some other direction. One of the so-called killer apps would be Bill Worley's crude brute force time-sharing. It worked fine as long as you had a very limited number of people using it. Then the next thing that came along was TSO under MVS and what we learned about that very quickly was that it just ate resources - it ate memory, it ate cpu cycles and so forth and we had to again innovate and go with VM. We now know that VM was distributed computing that happened to be folded onto a mainframe. All the things that we can do with distributed computing, networked PCs, networked workstations, those were all the fundamental design of VM. I think we knew it at the time. I remember Bob Cowles when we were architecting the systems to do the NBER project. He understood how that all worked and that it really was the early hardware implementation of the idea of distributed computing. Long before SUN or anybody had ever thought about the "network is the computer" kind of stuff.
So I think, in many cases things were innovated or maybe discovered or invented at Cornell and I don't think we really knew what they were. In the 70s in particular we were faced with financial survival. We started in the 1960s and continued in the 70s and I guess on into the beginning of the Ken King era trying to do too much with too little. It goes back to my axiom that I think I've learned partly from that environment and subsequent environments that when you try to do too much with too little the safety valve will be that your customers will start to scream at each other and at you. When I was at the University of North Carolina at Charlotte I said that my measure of whether I was doing my job well was that everybody was equally upset - that the administrators thought they were getting the short end of the stick and so did the academics. Because, if anybody was totally satisfied then they had too much resource at the expense of somebody else. That was a balancing act I learned at Cornell out of necessity.
To me the greatest software invention, that I ever put my hands on, and I thought that Cornell missed the boat at the time, and I recall I lobbied for it, was an APL application called ADRS - A Department Reporting System. I used it constantly and I thought that we missed the boat in using it to promote end user computing. I used it for everything. It was a spreadsheet before spreadsheets came out, sometime in the late 1970s, and I tried to promote the idea that we should set up a unit to support end user computing. In fact the article I wrote for CAUSE/EFFECT in 1986 or 87, my co-authors and I won the Contributor of the Year Award for, was about the evolution of end user computing. To me, the part that I contributed to the article was the central notion that here we had a mainframe package, that IBM Canada had used to set up Information Centers, the first end user computing organization and this was this tremendous opportunity. And it was one of the few that I thought we missed at Cornell and I often wondered if it was that we didn't invent the software.
It was under Hank Vaughan that Cornell started looking at what to do about administrative systems. I remember there was a critical point that they were looking at Adabas/Natural on one hand and FOCUS on the other hand. They correctly figured out that FOCUS was more for end user computing, although it really wasn't, it was a programming language, and Adabas/Natural were for building databases and systems. I remember lobbying, although it wasn't my job or anything, that we ought to get into end user computing. They argued that we can't get into end user computing because we have no data to grab and manipulate. It was sort of the early data warehouse idea. But they wanted to do transaction processing rather than data warehousing and Adabas was and still is a pretty good transaction processing database. We run our data warehouse on Informix and there are actually two versions of Informix one for transaction processing and one for queries. You load all your transactions in one and then you migrate to the other. So, nothing has changed - the more things change, the more they stay the same, or something like that.
The 1970s were a very difficult time, because we didn't have enough money and we had rapidly escalating demand for computing services. Computing was starting to catch on and it wasn't a specialized thing anymore. Everybody wanted to do it. There was a groundswell that we picked up on but didn't do anything about, of distributed computing. I remember one report that said there were more MIPS in minicomputers on campus than there were in the campus mainframe. I'm sure it was true. In the central organization, at least to our credit, we hadn't oppose doing that openly, but more for political reasons than technical reasons that we couldn't win that battle so we chose not to fight. This was the Goeff Chester period.
The prevailing attitude, largely promoted by Conway, was still the "computer utility" model. It was easy to provide access, but what we forgot about was that what people wanted was control. They wanted services, they wanted control, and they didn't much care that it was cheaper, because it was less effective. Conway pretty much dictated the UCB. (Rudan recalled hiring Fred Hiltz for the express purpose of helping others with their minicomputer acquisitions. They had a better distributed computing model in that they could buy their own machine and then operate it very cheaply.) That's a good example of distributed end user computing. You remember a little later our great innovation was Distributed Academic Computing - Doug Gale and Alison Brown, picking up on end user computing. I remember that staff wiring boards to build microcomputers. I remember that they had a secretary or office assistant in that organization who was really good with a soldering gun. The first micro we had on campus was a Z80 that Alison and this person literally soldered the boards. I also remember the single board computers we bought for doing training that a bunch of staff put together. So in one way, Cornell was kind of early I guess in getting into that kind of distributed computing but I always thought we were very late in recognizing that and embracing it because we were really playing catch up on campus. There was a lot of distributed computing going on, particularly in the various labs in Physics and Chemistry and the central organization finally got involved in it, when sort of everybody else wanted it as well and didn't have the brain power or whatever that the physicists and chemists had to be able to get money.
I revisit the idea (of the central computer and central organization) literally every week of my life now. The state government in North Carolina still is operating on the notion of let's have this great big mainframe and monolithic organization that is now struggling to support people doing distributed computing, and we can save money too! So, almost daily I think back to the lessons that I learned in the 70s at Cornell. When we were going out for our request for proposals for our administrative system project that we now have, one of the vendors called me up and said they wanted to send me up a monograph called, "Shared Services", and what it was, was the monolithic mainframe model - all of your colleges would send their data to a central organization to be entered. I said, "Wait a minute, wait a minute, I was there and tell you what, it will never work!"
One of the things that I'm proudest of is that on our watch, supercomputing was invented. In the large scale, wide dispersion model, what you and I think of as the Ken Wilson model - let's have lots of people doing supercomputing, let's have it be the norm. It's real interesting. I don't know if you know a guy named Thom Dunning who just came to North Caroline as our head of supercomputing and high performance computing at MCNC. I was really scared when Tom came there because he sounded like an old supercomputing guy. I think he came from either San Diego or NCSA, one of the two. I wanted to call him up and say, "Tom, I have one name for you to remember, and that's Ken Wilson, remember Ken Wilson, study the oracle Ken Wilson, because he was the one who turned his Nobel Prize into the NSF Supercomputing Initiative by his bully pulpit." I went to a meeting with Tom a couple of weeks ago and I was delighted to hear that he really is a disciple of Ken Wilson. He just hides its well.
I agree that Ken Wilson strongly preached parallel computing but there was also the organizational model that Ken preached. It was the first time we had a partnership of the central computing organization and the users jointly invested in setting up and operating the system. The first FPS 190L, the wire wrapped box that Al Personius shepherded so well, was the first time that the computing center and a group of users had mutually invested in buying something and hanging it on a mainframe. I always thought that was a great model. It was one of the first times that was done, and as best as I can tell, it not only worked well at that point in time but really gave birth to the Theory Center. The Theory Center was after my days but I always felt like the Theory Center was, in some sense, the logical outgrowth of the cooperative mode and some cooperation continued. (Rudan agreed that the Computing Center gave birth to the supercomputing initiative of the Theory Center since it started and fostered that type of computing and provided the initial technical and operations staff.) The irony today, is that the only real supercomputing going on today is on IBM SP2s. IBM turned out to be absolutely right, although it was Ken Wilson's vision started at Cornell and (picked up by Irving Waldawsky-Berger and others in IBM. Rudan also noted the irony in that all that IBM/Cornell supercomputing innovation did not prevent the NSF from withdrawing funding from the supercomputer program at the Theory Center)
The other thing that started at Cornell, that my good friend Carl Malstrom at NC State was heavily involved in, was the outreach program (the Smart Node program). At one point before NSF made, I think, a seriously wrong decision. The direction we were going, we collectively, because the computing institutions in North Carolina were a part of it, was a Branscom Pyramid, a hierarchy of SP2 systems. I find it interesting that now, our North Carolina supercomputing center has SP2 systems has the latest proposal, ta-da — has a hierarchical organization involving all of the campuses having some level of supercomputing and level of expertise. I proposed this 10 years ago in North Carolina at the time that the Theory Center was booming but it was viewed as odd as it was not running a big Cray. Remember, San Diego, NCSA, Pittsburgh, the NSF funded centers were running big Crays; North Carolina, Alabama and several other state funded academic supercomputing centers were running big Crays. Everybody was running big Crays except Cornell! And now — guess what folks, Cray was bought by SGI and is gone. Now our big machine is an SGI Origin, a big vector machine. It's a Unix box, nothing special. Campuses now own Origins.
It comes full circle. One of the major innovations I was going to talk about was what we are working on now at the Community College level. That is to get an NSF Advanced Technology and Education grant to set up a program in supercomputing technology, high performance computing, to train people to set up small clusters of Dell boxes, or whatever, to do PVM. PVM is the distributed computing system that runs on Intel boxes. PVM is still around and there's beginning to be a market in the commercial world for setting up parallel computing systems made up of clusters. There's enough of a market that they are saying that we need to train some people at the operational level, the technical support level. The neatest part of that one is that the center of that activity is the Maui High Performance Computing center in Hawaii that Cornell started. Of course, Maui is the area where most of this activity is being led from, in terms of the training of technicians and so forth, because the only academic institution on the island of Maui is the Maui Community College and it's highly affiliated with the Science Center. It all comes back around.
Back to the 1970s. In any environment where there is a lot of innovation going on, some things work really, really well and other things fail miserably. And sometimes it's not clear when you start. The whole business with the National Bureau of Economic Research (NBER) for example, for 3 years was like a bonanza and then the contract ended. They wanted something that was a better deal for them and Cornell thought they had been giving them to good a deal. The joke you and I used to talk about with Sam Lawrence was that a 50-50 coin to Sam was unfair. Sam wanted a 60-40 deal or a coin that came up heads twice as often as tails. That was our downfall on a lot of those things. We didn't have enough money and we were trying to sort of leverage other people's money. I also say that deliberately because I remember how close we came to doing a computer lease deal with that company called OPM. We came within a gnat's eyelash and if Ralph Roger Barnard had not had this, just this intuition that there was something wrong (we would have gone ahead). We came that close to a major disaster because of wanting too good a deal. I think that some of the other things that went wrong the NBER and of course, the infamous Medical College thing. The Medical College thing to me was politically and economically wanting too much and it couldn't be delivered technically. Because in fact, the Medical College had done some amazing innovations too. They had taken a hardware APL assist and APL itself and they had optimized the hell out of it. They'd optimized themselves into a dead end; they'd painted themselves into a corner with very sticky paint. We helped them out of their corner at great expense to all of us. They couldn't get out of their corner by themselves and we couldn't get them out their corner with technical innovation.
Part of the reason we got into that mess is that we had in fact done really well with technical innovation through the 60s. On your watch in the Computing Center the 1604 did things that 1604s weren't supposed to do. Bilofsky, Behrenberg, Bessel, and Al Esserman and others, John Emler, did all kinds of things that were theoretically possible, but hadn't been done. They made it work beautifully even though it was using slave labor because they were students. Then on into the 70s with what we did with VM and so forth resulted in a very, very strong history in technical innovation. But those really didn't roll over into what I'll call economic and political innovation. It's much harder to do. How are we going to get control of the Medical College? Well, they got a mess in computing so we'll send John Rudan, Bob Blackmun, Doug Van Houweling, George Cameron down there to straighten out the college. We knew much after the fact was that the Medical College had a dean who was selling himself and got into trouble for doing Valium ads. Ted Cooper. He got into trouble touting Valium for the company. It taught me a very important lesson that technical innovation is necessary and exciting but rarely sufficient. I learned that on a couple of projects at UNC Charlotte where we did rally neat things. We did a wonderful computing environment based on Athena and the stuff from Carnegie-Mellon. We did a great job for the College of Engineering in setting up 400 to 500 workstations and servers and they had this wonderful computing environment. The trouble was that the people who did it, did it by putting in 100-hour workweeks and innovating like crazy. When they were all done, the Dean of Engineering said and the Chancellor said, "Thank you very much, keep doing it." They said, "Wait, we've done this, we've proved it can be done, now we are going to have to set up a support organization to keep it going." They said, "we don't think so." They never said, they just didn't do it and within two years the whole thing had basically crumbled.
So I think one of the lessons that I've learned and learned it and applied it over and over again is that you can do really good technical innovation but you've got to be able to manage it with people and money. It's a little like the two triangles I've seen in high performance computing. One is Ken Wilson's triangle where he talks about theory, experimentation and simulation as being the three legs. There are a couple of guys [Bob Panoff & Bob Gotwals] in Durham {Shordor Foundation, www.shordor.org] who talk about architecture, applications and algorithms. You have to have your architecture, your applications and your algorithms matching. They are saying that's why you can't just take out a vector computer and put in a massively parallel system. You have a different architecture that requires different algorithms to do the same applications or requires you to rethink your applications. And, the same thing has proven to be true in administrative technology. It's really critical to have the technical innovations but that alone won't get you where you need to be. I think the Internet community has learned that big time. The whole Internet thing has just been this wonderful technical innovation and so forth but there are questions of how are we going to pay for this, how are we going to govern and manage it, and how are we going to plan for success? It is the case that we run ahead with innovation and assume the rest will follow but it often doesn't.
I have a former colleague at UNC Charlotte who I don't think invented it but he calls it the law of unintended consequences. Where technology itself is neutral, it's not good or bad, the consequences vary all over the place. There's a guy at NC State, in the Library there, John Isenhower, who helped the Web when he was at NCSA. He knows Tim Berners-Lee and talks to him every week, says the same thing — the Web was never designed for what it is and had they known it would turn out this way, they would have done it a different way.
[JWR} Do you recall the crisis days of the 60s, do you remember when you rode around with the Registrar's system in the trunk of your car? [RRB] I remember the Willard Straight incident. What I really remember was taking the payroll checks to Mr. Peterson's house in the trunk of my car, to store them in his house. When we completed a payroll run, rather than keeping them in the vault in Day Hall or keeping them someplace at Langmuir, I put the checks, printed and blank, in the trunk of my car and drove to Mr. Peterson's house and gave them to him. He kept them stored in his home. At that time we didn‘t have any place to safe keep things and I remember having drawers of cards and reels of magnetic tape that I would take home with me. Different members of the management team took different things home with them as our rudimentary off-site storage. We also invented off site storage. But the one I remember most is taking payroll checks to the University Controller's house and delivering them to him and he took them to work the next day. I also remember at the height of that (incident) that the management team took turns, in 4-hour shifts, guarding Langmuir. We spent 4 hours, midnight to four, or four to eight, or whatever it was, walking around the roof on Langmuir Lab. We were up on the roof and we weren't to do anything but if something happened, we would then call Campus Police. Thank goodness nothing ever happened. My sister was an undergraduate at Wisconsin when the Army Research Lab there was bombed. We were very worried that that was going to happen at Cornell. One of the unintended consequences of moving the computing center off campus, because we could. I think for a number of years some of the senior people in the administration secretly felt like they didn't want computing to move back on campus. Not only because of space utilization but also for security reasons. There was a lingering feeling that if the computing center had been on campus, it would have been blown up. That despite all the disadvantages, the major one being lack of contact with campus people and the isolation on being off campus, there was that advantage.
I should recall that I left Cornell in 1982 and went to UNC Charlotte where I was director of computing until 1996. When I went there they had just celebrated passing the 10,000 level in enrollment and they are now at about just 18,000. They have been growing very rapidly. When I was interviewed there I observed it was an exciting building opportunity. Computing was about where it should have been at an institution half as large, five or 10 years earlier. They were really back in the dark ages. In 14 years we moved them forward, although it really only took about 10 years. I was ready to move on.
(We talked about general ideas like the pros and cons of a matrix organization for the computing center, something we experienced at Cornell in the early 90s)
Summary Comments
My current title is Associate Vice President for Information Resources and Technology, North Carolina Community College System Office
59 institutions that provide world class workforce training for North Carolina
I'm sort of the system CIO. We have an internal staff of about 40 people and we act in effect as a software vendor for our colleges.
Each college operates a Unix box that runs the software that we supply.
Basically, each college is autonomous and provides its own equipment and support staff and makes its own decisions about their micro labs and that sort of thing.
In fact, they make their own decisions and buy their own equipment to run the administrative software.
The interesting thing is that they elected on their own to run the software we supply.
We don't do any academic computing [centrally] but we provide a lot of technical advice and support for networking and we coordinate the state contracts and support agreements.
A few of our colleges have the equivalent to a CIO at the campus level that has academic computing and administrative computing.
In a lot of the cases, particularly at the smaller colleges, academic computing is the province of a particular academic dean or department chair.
They'll have a technician maybe supporting their faculty and they'll have their own computing labs but the central campus organization will be responsible for networking, for the administrative systems, for the Web servers and that kind of stuff. We provide them with a lot of advice and standards for networking but we are only responsible for statewide networking. What we are trying to set up is a regional support model for our administrative systems, where campuses will work together around one of the 4 larger colleges where we've set up regions. It's the Ken Wilson hierarchical model that our previous information services director who retired, had the same idea, but he didn't have the vehicle to do it. The new administrative project provided the vehicle.
Prepared by John W. Rudan on August 1, 2001