I can only speak for myself, but when I started it was at a big shop (10,000+ users) that had 8 separate processors and 28 Systems Programmers to keep things going. They were split into several/many areas within the main group TCAM, VTAM, CICS, IMS, JES, Performance & capacity, TSO, Production support, Hardware support and several others that I can't remember right now. Back then, not only did we have to deal with problems in our various areas, but we also had to worry about the source code (microfiche) from IBM. Moving from release to release was a very difficult thing. The site had "just" migrated from MVT to MVS 5 years earlier and it was apparently a huge undertaking. I was not yet an employee then, but I heard the stories.
28 probably seems like a lot of people now. I know it does to me because I am currently responsible for sole (and partial) support of a number of sites, but at the time the company that hire me felt that they needed more people and that's why I was hired, straight out of college. I spent almost half the first year "learning" how each of the sub-groups did their work (so they could decide where I fit best). They were running MVS 3.7 and were more than happy to stay there forever even though MVS 3.8 had been out for a long while. Our boss though wanted to jump to the newly released MVS/SP, but no one wanted to take on the project which was estimated at 6 man-years. I had zero experience in MVS when I started (we had DOS/VS in college) and couldn't even spell MVS/SP, but I was designated the sole Systems Programmer in the "OS Migration Group". One guy, six-man-year project, what can go wrong? I was sent to 3 separate 1 week IBM "internals" classes and a 2 week hands-on installation of VM. When I got to work after the last class, I was told that "my" processor had arrived and was in the process of being installed in the computer room. Anyone who has worked around 370's already knows the size of the beast, and 8 of them in the same room take up a lot of space. Over on the far side, next to the "chillers" was a tiny 4341, (which I thought initially was a control unit for one of the new printers), But no, it turned out to be my "box". While the other guys were using 3330's (hundreds and hundreds of them) and a bunch of 3350's, I had a couple nice little strings of 3380's. I was handed the 3 boxes of tapes and manuals that came in the mail while I was gone, and told to "take my time". They were used to taking months to install MVS 3.8, it took about 2 hours to get VM up, and by the end of the weekend I had MVS/SP system up and running. I went to my boss on the following Monday as I was waiting for the CICS installation jobs to finish and asked when we could start the conversion to the "new" box and he literally laughed at me, until I convinced him to try to log on to TSO. I ended up re-installing MVS/SP 10 or 15 times over the next few weeks so that the other systems people could "monitor" how to do it, but they just didn't seem to get it. They were used to multiple source and load module tapes and multiple long I/O gens and building nucleus modules almost by hand with all of their "extra" code, and all I needed to do was load up a few volumes from tape and IPL. I was only at the site for 4 years, but we went from 28 people to 8 by the time I left. From 8 370's down to 3 4341's (one of which was for testing). The DASD "farm" went from hundreds of strings 3330's and a few strings of 3350's to just 90 strings of 3380's (which was a capacity upgrade) and IBM had already started to make things OCO, so new versions of the various components were shipped without a lot of the fiche that the older Systems programmers depended on to "make things work". All the fiche for MVS/SP that was released fit into one box. At the time, I wasn't sure that some of them knew why they were installing the system mods any more, and I spent a lot of time trying figure out what needed to be refitted and what was no longer necessary. No one was fired, but those that didn't retire just plain wanted "something to do" and there just wasn't as much to be done. It wasn't that there wasn't a lot of "work" to be done, it just wasn't as "interesting" for them. As time went on, I figured out way to automate a lot of what we had to do. Thinking back on it, that was probably where I first dreamed up a lot of the automation routines I ended up writing over they rest of my career. Many of the older Systems Programmers just didn't "get it" when it came to maintaining things through parameters and exits, they had a hard time not being able to decide where they wanted to "insert" their code. By forcing sites to use exit points instead of letting everyone insert their code wherever they felt like it was a death blow to many of the existing Systems Programmers. For them, everything was taken away from them. I saw the exits as a opportunity to do things once and probably never have to worry about it again, they saw it as "dumbing down" the operating system. The advantage for me was that it was impossible for any of them to "know" the whole system well, they actually felt responsible for the millions of lines of code that made up their individual part(s) of the system that they maintained. I on the other hand felt no need to "see" the millions ( I think MVS 3.7 was 50+ million lines) of lines of code, and could almost care less about the intricacies of what each module was doing. I couldn't change the code, so why worry over it. But I COULD "see" how the system worked together, and how exits would allow me to bridge the parts to get things done they never dreamed possible. While you could no longer see and know all of the code that makes up JES, or SRM or IOS, you could learn how they worked and how to affect them via the parms and exits, and more importantly, you could see that they really did work together and could see ways to make them work together better. I have a fairly good memory, I read things once and remember them (sometimes too well), so I was able to begin to visualize how the system was "supposed" to work, (notice I didn't say how it actually worked:)) and how the pieces all fit together. Remembering hundreds of parameters and how they work is infinitely easier than trying to memorize millions of lines of code. After that job, I ended up working at IBM for quite a while both directly and through other companies, so I was able to be not just exposed to the exit points, but I was able to create the exit points and make life a little easier for myself. It's not all that different from the way the older Systems Programmers worked, but they never really thought about the future ease for anyone but themselves, whereas I would approach the code with the intention of making things easier for the Systems Programmers in the field. I was actually able to straddle both types of positions. I was able to see the benefits of having the base code and the benefits of using exits instead of refitting the mods over and over again. For example, shortly after I started working on MVS I wrote JES modification code to two JES modules be able to send the Maximum condition codes when jobs ended via a TSO SEND command to whoever the "NOTIFY=" was for, but when the code was removed, changing to using JES exits instead came naturally and it just so happened that the two modules I had changed now how exits available (well, one of them did, the other was pretty close). Now, years later, I can use those exits for purposes that they were never intended, and even do exit-type processing without even using the original IBM supplied exit points themselves. So the logical extension of those original JES Condition Code mods inside JES, and making it so that I can now send the condition codes (and a whole lot more) via email directly from z/OS without requiring exits, or in fact, any changes at all to the system became a whole lot easier to design. Over 200 sites use it every day. Things like this would never have been possible had IBM not "dumbed-down" the system. There would probably still be a lot more people working a lot harder and getting a lot less done. In the future, I see that the operating system will need to merge even more with the rest of the technical environment. Interacting with the mainframe doesn't need to be hard to do, secure, YES, dependable, YES, but not hard. That's the advantage that we have over the other platforms. I have found that the easier you make it for people to do the things they need to do, and do quickly, the more they will be able to innovate. Innovation drives the technology business, stagnation kills it. A lot of the ISV products over the years have fallen by the way-side not because they were poorly written, but because it failed to innovate. You can't expect a client to keep running your software if you don't continue to give them the tools and ability they need to get today's work done. Yesterday's work isn't important any more, 20 years of having done it well doesn't matter when the average user has been with the company for 3 years, and many of the ISV's failed to grasp that. IBM had to learn that lesson the hard way and they have alternated between kicking themselves and playing catch-up ever since. Most companies don't have the pockets necessary to be able to make those kinds of mistakes and keep going. CA also has been slow to learn, they probably have purchased and designed more products that they don't sell any more than the ones that they do. What will happen in the future? Here's a example of what I think will happen. Why hasn't the method for submitting jobs into the system changed over the past 30 years? Is it because there is no better way to do it? Is it because there is only one way to get it done? Of course not. Wouldn't it be cool to be able to have a complete job scheduler on your Iphone, or how about 5,000 of them, one on every users Iphone? Do you want Interactive output management built into that? Why not? The only thing stopping most of this type of design is that Iphone people don't understand mainframes, and mainframe people don't understand how to write Iphone stuff. That's the kind of thing the "next" mainframe generation will need to solve, and I think they will be able to do it. Sorry for the long message, I could go on, but my wife just told me that she want's to go dancing. Brian ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
