Mainframe Solutions

Dave Lytle

My personal 45 year odyssey of working with “Big Iron” as the Mainframe celebrates its 50th anniversary.

by Dave Lytle on ‎04-13-2014 10:39 AM (3,141 Views)

So my story really begins on April 7th, 1964, the day that the world was introduced to an incredible new technology that would change the way business, academia and common people would conduct their activities from that time forth. For 50 years the mainframe has been a part of the human experience and it will remain so for many decades to come. I know that this is common knowledge for most of you but if you drive a car or fly on airplanes or do online banking or trade stocks or any of a myriad of other activities then you have involved yourself in one way or another with mainframe computing.


Mainframes are not as universal as personal computers and not as prevalent as smartphones but without mainframes, the world, as we know it, just wouldn't be the same. It was the mainframe S/360 computer that NASA depended upon to put a man on the moon. And as you probably know, S/360 was IBM’s first system built on "solid logic" semiconductor technology and one in which different models could talk to each other, unique at that time. The System/360 ushered in a whole new way of thinking about designing and building computer systems, a perspective that seems so fundamental to us today that we may not realize it was rather radical 50 years ago.


Few of us (I was 15 years old at the time) remember the big bet that IBM made on the System/360 in the early 1960s. IBM gambled the fate of their company on this one system. During the 1960s it cost IBM $5 billion to develop the S/360. That is about $38 billion US dollars in today’s money. Those first IBM mainframes were very slow by present standards, running at between one to 50MHz. The largest modern systems run at almost 5500MHz (550 Ghz) so it would take about 100 of the biggest of those early mainframes to provide comparable processing power to a single zEC12 today. And the early S/360 didn't have much memory, with but 8KB in small machines and up to 8MB in the largest models. I remember working at a company in Florida in the early 1970s who wanted to upgrade their S/360 model 30 with 8k of memory. The list cost was $1 million dollars – I don’t know what they wound up actually paying for it.


As you know, IBM rated its initial IBM mainframes' single CPU speeds at less than one Million Instructions Per Second (MIPS, otherwise known as a 'meaningless indicator of processor speed'). Today's descendants of the S/360 are vastly more powerful. If MIPS were still in use today, IBM would claim that its largest zEnterprise System mainframes offers over 75,000 MIPS of aggregate processing power in a single processing complex. Some reports state that the largest mainframes account for 1.1 million transactions per second, or 34 trillion every year. That is significantly more than all tweets, Facebook likes and Google searches carried out over the same period.


The mainframe’s famous “Green Screens” changed the way the System/360 could be used away from traditional computing of the time. Originally, mainframes did batch processing, where a job was submitted via its also famous “punched cards”. The machine would churn through the data and return the results. The green screens paved the way for more interactive sessions using a machine interface. In fact, 3270 terminals were always 80 columns wide which was equal to the number of columns on a punch card.


The evolution of the mainframe went from the System/360 to the System/370, System/390, four zSeries machine styles, System z9, System z10 and most recently zEnterprise System mainframes.


And although the software as well as the hardware on the mainframe has evolved, most mainframe software remains backwards compatible. Compare the mainframe’s 50 years of longevity to one of IBM’s largest competitors in the software market. This month, April 2014, Microsoft ends support for its Windows XP OS after a mere decade since its release. The mainframe can celebrate its historic 50th Birthday all the while knowing that applications written for the S/360 can still run today on zEnterprise – a legacy of unmatched capability. With very few restrictions, and probably a new assembly or compile, most applications written for the S/360 in the 1960s would still run on the zEC12 mainframe today. And since trillions of dollars have been spend by customers on mainframe legacy applications, that is pretty good news.


And while enterprise usage of cloud storage has been growing exponentially, IBM estimates that four-fifths of the world's corporate data still resides on a mainframe – and the mainframe was the earliest, and remains the most powerful, cloud computing machine in existence.


I grew up in rural Florida, in a small town where the nearest computer was probably about 30 miles away at the University of Florida. Certainly I had never seen one. I was a junior in high school in 1964 thinking about taking a girl to the prom. I wasn’t much interested in technology back in those idyllic days and April 7, 1964 came and went for me as just another day. But after a stint in the Air Force, my father had a heart-to-heart talk with me about my future and he suggested that I consider a career with computers. Now I’m not great at math, and my perception at the time was that computers were math beasts, so I was hesitant. But he took me over to Florida Technical College (FTC) in Melbourne, Florida to talk with the staff about their training. They convinced me that the computer can do the math, and other tasks, if I could logically tell it what I needed it to do. And so my first step into computers was completed in May 1968.


In 1968 FTC was teaching the manual wiring for machines like the reproducing punch (still a lot of them in business at that time) as well as RPG, COBOL and Assembler programming languages. So I spent a year learning all I could about programming computers. The school had a S/360 model 20 with a Tape Operating System, 8K of core memory, two 7-track tape drives, a multi-function card machine (MFCM) and a line printer (man I thought that thing was fast at the time). Having taken typing in high school I was just amazed at how the printer could print a whole line at a time on the computer paper. Really cool! The compilers and assemblers were on the tape drives, as was most of the operating system, so we learned to use tape early on. There were no disk devices for the training. I did pretty well on all the subjects and graduated 3rd in my class. And now it was time to find a job.


I created a (short) resume and submitted it to many companies. And I went to a firm called Management Recruiters who did personnel placement. It was they who found me a job in Jacksonville, Florida with Computer Technology, Inc. as a computer programmer for $500 per month. It only took me about 2 weeks from the time I began looking for a job to shaking hands on a job offer. And so my second step into computers was completed in June 1969 – almost 45 years ago.


CTI was a high-flying, computer service bureau company that was doing the data processing for one of the very large banks headquartered in Jacksonville.  I was placed into the trust department and began writing COBOL programs as needed. CTI had a S/360 model 30, model 40 and model 50 that they used for their clients work processing. CTI sent myself and 5 others up to Chicago to a six-week internal OS and programming class right after they hired us. That was really my first taste of getting inside how a computer really does what it does; how a business uses its computer systems; and how our work shaped how flexible and profitable it could all be. It was fantastic training. After returning to Jacksonville, and a bit later on, the company started processing BANKAMERICARD credit card statements for that same bank. CTI decided to do it on a small S360/20 processor and to use RPG as the programming code. So I was briefly transferred over to help with that effort. All of this was taking place at a time when it was common to discuss “snow white and the seven dwarfs” during a coffee break. Snow white, of course, was IBM. And the seven dwarfs were Burroughs, Control Data (CDC), General Electric, Honeywell, National Cash Register (NCR), RCA and Univac. They were the dwarfs because their market share was so insignificant in comparison to IBM’s presence in the market. In the 1970's, after GE and RCA left the business, the remaining firms were nicknamed the “BUNCH” as an acronym for the first letters of the remaining firm's names: Burroughs, Univac, NCR, Control Data, and Honeywell. This was the state of the market as I was first learning and then building up my computer skills and craft.


In these early days of computers, the size of a mainframe made it easy to distinguish it from other types of computer. If it was big enough to walk around then it was a mainframe. If you could get it in your living room it was a mini-computer, and if you could carry it then it was a micro. Personal computers were a pipe dream at the time. And here is a bit of trivia for you. Whether a worker in an office environment has ever used a mainframe or not, today’s personal computers have a legacy from the mainframe that is seen on most modern keyboards. The "escape" key was invented as a common way to exit from a menu system on early mainframes and now has a similar use on PCs.


One of my best stories comes from my time with CTI. CTI was located on the third floor of the Gulf Life office tower in Jacksonville, Fla. There were huge windows on three sides of the computer room. A bit after I joined the company, the S/360 50 I believe it was began crashing at night, only at night. IBM sent in its taskforce, but weeks went by with no fix.


Our building was on the banks of the St. Johns River and there was a lot of commercial ship traffic. Some technicians thought that electronic emissions from ships might be interfering with our computers. I remember coming into work one day and all of the big computer room windows were covered in aluminum foil to block out those emissions. No joy, still had crashes.


One of the IBM technicians decided to stay on the operations floor all night. CTI was a first-class company that took visitors and customers through the data center, so it looked fabulous–nice windows, the location on the river and carpet-covered floor tiles. Our receptionist was a former Miss Florida. During the day our operations staff members were very professional. But when management left for the day, things got a little more casual.


It turned out that one of the night shift operators would roll his chair across the floor from the operator console to a tape drive to mount a new tape in response to a tape mount request. Then he’d roll his chair back to the console and he would do that all night long. One humid night, while the IBM tech watched, the guy rolled over to the printers, put in more paper and then rolled back to the operator console. He touched his keypad on the console and the Model 50 croaked on the spot.


It was discovered that the operator was rolling around on carpeted floor tiles and building up static. If conditions were just right when he touched his console he zapped the console with static and the processor went down. The IBM tech figured it out immediately from seeing it happen. He re-checked the grounding and sure enough there was a hard to find break in one of the grounding connections. IBM put extra grounding on all of the computers, had CTI remove all of the carpeted floor tiles and we never had that problem again. That’s how crazy things could sometimes get in those early days.


My third step was a stumble. In early 1971 CTI faced a financial crisis with the result that four of us programmers and a few operators were terminated during a reduction in force (RIF). Although it is a shock to anyone’s morale and self-image to be released from a job, I cleaned up my resume once again and began casting about for a new programming job. It took about 4 months but I finally landed a programming job in Jacksonville at Blue Cross – Blue Shield. Being a much larger company than CTI, I felt like my opportunities for advancement would be better at BCBS. So I landed on my feet and began integrating myself into their non-profit culture as a COBOL applications programmer.


After a few years of working as a programmer it was time to get a raise. I was making about $10K per year by then. I spoke with my boss and asked for a $1,200/year raise - $100/month. Well that conversation did not turn out well. BCBS didn’t give “big” raises like that very often. I was told it was unlikely that I’d get it. Surprisingly, after all of the due diligence was done, I got it and it was such a huge morale booster for me at that time. I think some others benefitted from my persistence on that matter.


1973 was a big year for me. I graduated Magna **bleep** Laude from Jones College with a BS in Business Administration. Also in 1973 I was offered a transfer from applications programming to the systems programming group and accepted it. So this fourth step found me finally getting involved with the belly of the beast. BCBS sent me to the entire suite of IBM systems programmer training classes in 1973-1975, mostly in Atlanta. The best one of all, basically the last one to take, was the IBM OS Class. A tough and rigorous 2-week, hands-on class, it was designed to put all of our knowledge to the test and build our comfort level and confidence. We were assigned to 3-person teams. Each team was given a daily assignment. I remember on the first day the instructor told us, “I will lecture for ½ a day. Then I will give you an assignment. You will turn in the assignment promptly the following morning. I don’t care if you get the lab work done in 1 hour or if it takes you all night long. If I don’t have it on my desk by 9am you are out of this class. I will be here until 9PM to help answer questions.” WOW. And he meant it. We had a System/360 m30 and we were all writing SVCs and reader and exit routines and every team was crashing the m30 with their bad code. Then the next team had to IPL the m30 to do their testing which usually also crashed the m30. And so on. It was grueling. There were many all-nighters for all of the teams during those two weeks. And a few people didn’t make the cut. Some of the students left voluntarily but a few others were removed for not getting the work done. But boy did we survivors learn some cool stuff. Of course IBM can’t or won’t teach classes like that anymore. Various laws must forbid it. But that is the pressure-cooker kind of environment that systems programmers worked in real life and that class really helped prepare us for real world, very detailed systems programming challenges and helped shape my professional career.


About 1976 as I recall, several cool things started happening at BCBS. Internally it was decided to offer COBOL and Assembler training classes to employees. I was chosen as one of the instructors. It was very fulfilling to help fellow employees master programming languages so that they could enhance their own careers. And it was in 1976 that BCBS began moving from MVT to SVS and then to MVS. I was doing sysgens and IOgens on weekends and was in charge of the shared HASP (pre-JES2) for SVS. When we began the conversion to MVS it was crazy. We had a S/360 m168AP (attached processor) for our production work and a new S/370 m158 was brought in and we used it to get to SVS and then to MVS. It took us at least 18 months to convert from SVS to MVS. I remember that in 1977 I was in the middle of reading a dump one day, to fix an MVS problem, when I heard that Elvis had died. It is strange that humans remember eventful moments in the way that we do.


The SUPERZAP utility became our friend as we corrupted VTOCs and such during our MVS testing and had to fix them. We did not have VM so we could not do IPLs during the week. That is what weekends were for. We had a local IBM Programming Support Representative (PSR) and had others brought in on occasion during the migration. We got dump after dump after dump as we tried to get new functions to work. IBM PSRs were amazing. I learned so much about reading dumps and doing troubleshooting during that time. It is a shame that our current crop of systems programmers don’t get their hands dirty anymore, like we did in those days, digging through massive dumps to solve problems. And it is a shame that PSRs have become extinct as well. But to make the long story short – we made it! By the end of 1978 BCBS was an MVS shop.


The other project that stands out in my mind from BCBS was a security project. The company decided not to buy RACF. The result was that our systems group had to create a security system. We wrote reader and exit processing code to create that security system that we called “RIMS” – Resource Information Management System. It was a cool little system and once again taught me a lot about the internals of MVS. Long after I left them, I had occasion to visit BCBS in 1999. They were in the midst of getting ready for the Y2K issues by doing coding updates. An old friend was walking me around the systems programming area and I happened to notice some printer pages with assembler code. I looked it over and was amazed to find that it was code that I had written 20 years earlier. They were still using it and in the middle of modifying it for Y2K. Made me feel kind of proud.


I left BCBS in December 1978 and took the fifth step of my career. I had reinvented myself from an applications programmer to a systems programmer. And now I was going to reinvent myself into a support role for a computer hardware vendor. So I joined Amdahl Corporation in January 1979. I was hired to support a customer in Jacksonville that was using an Amdahl V6. The reason Amdahl was successful was because their price-performance ratio was higher than IBM's, they were air cooled when IBM's were water cooled, and their customer service was outstanding. Amdahl believed that all of its software support people should be cross-trained into hardware so that we could replace memory boards that might fail on a system and do other semi-easy hardware tasks. I was sent to Sunnyvale, Ca. for eight weeks of cross training at the Amdahl campus. It was my first trip to California but far from my last. The cross training class was hectic but fun. I met many great people and started the process of becoming a computer vendor rather than a computer user. In 1982 I was promoted to become a technical services consultant where I sold education and consulting services to our southeastern US customer base. That promotion is what moved me from Jacksonville, Florida to Atlanta, Georgia. At the end of 1982 I was again promoted, this time to a District SE Manager. During all of this time with Amdahl I was working with medium to large mainframe users and my prior career as a customer user was very helpful.


Unfortunately, Amdahl came out with a new computer system that just wasn’t ready from prime time, the 5860. This machine had many, many problems and worked my staff to death. It was not a pleasant time during my career and was very stressful. On the bright side, during my time in Atlanta, the sales manager used me several times to do product presentations and help enable our sales efforts. I realized that I really liked that role compared to my support role where even 120% effort was just what was expected. I found it to be very difficult to gain recognition in a post-sales SE or SE management support role at Amdahl. So in early 1983 I decided to reinvent myself away from support and into pre-sales as I took my sixth career step by leaving Amdahl and joining Storage Technology Corp.


StorageTek was such a fun place to work. Great managers and great people in general. It was a company at which I would work for 15 years. After spending several weeks in Louisville, Colorado in my new hire class of 30 people I was ready to help enable tape and disk sales back in Atlanta. STK had taken advantage of a gap that IBM created when they terminated sales of their 3350 disk products and couldn’t get their new 3380 disk systems to market because of engineering and manufacturing problems. STK was selling 8650s all over the place. Unfortunately, 8650s also had problems and many platter assemblies had to be changed out, some more than once. But STK did have the 4470 9-track tape drive and they were superior to any other on the market for a while. So the majority of my first 10 years at STK were spent in competition with IBM and Memorex in selling tape and disk. During this period Memorex brought out the first disk control unit with cache. Soon after, all the vendors were touting the benefits of cached storage. And in 1987 STK introduced the first automated tape library system for the half-inch cartridge tape marketplace. The 4410 Automated Cartridge System (ACS) consisted of four elements: a 4480 Cartridge Subsystem (control units and cartridge drives), one or more Library Storage Modules (LSMs) with attached Library Control Units (LCUs), a Library Management Unit (LMU) and a Host Software Component (HSC). The 4400 ACS was divided into two independent components--the data path and the library control path. Each LSM could hold approximately 5500 cartridges and multiple LSMs could be interconnected via a pass-through port. It was revolutionary technology. I was on the sales team that sold one of the first of these devices to SunTrust Bank in Atlanta. Later on I worked with Clemson University to create a partnership that resulted in Clemson creating and packaging the Expert Library Manager software and selling it to StorageTek ACS users.


In 1990 I was promoted to District SE Manager and had SE resources scattered across the southeastern USA. During this time STK was developing a revolutionary disk platform whose project name was Iceberg – as its development lab was very cold. There were many fits and starts with this first RAID 6 product but the 9200 Iceberg finally came to market in 1994. Since it used compression and RAID 6 with garbage data collection, the system offered more useable space than it had physical space. This new concept was quite an obstacle for sales and took quite a bit of sales effort to educate prospects on its benefits. And just as the 9200 was beginning to sell well, IBM bought the rights from STK so that IBM sales teams could sell it. IBM rebranded it the RVA and it sold quite well for some years. But many of the employees at STK were demoralized that they had done all of the upfront work and then IBM got all the glory for the product. During my tenure at STK I went to Sales Performance Club six times and I was awarded Worldwide Outstanding SE of the Year twice. But after 15 years it was once again time to reinvent myself and move along.


In 1998 I took my seventh career step and joined REAL Applications, LTD., an IBM business partner headquartered in Woodland Hills, California which was a subsidiary of Camino Real Resources, Inc., a 3rd party leasing company. I was hired to sell storage solutions across the southeastern USA. This career reinvention was from a pre-sales role to a sales role. Of course, for years I had seen salesmen on my teams raking in the big bucks. As many systems engineers do, I had often thought to myself that if non-technical people like my reps could sell storage devices and make big money – so could I! Oh, if only that were so. I stayed with this job for 2 years without much success. I did sell some storage here and there but I certainly was not what I would consider to be successful. I just was not any good at cold calling as that takes training and talent to do well and was not my forte. However, it was at REAL that I got involved with Fibre Channel switches. Customers were beginning to make the move from direct-attached storage to switched-storage and I got to be on the leading edge of that technology shift. Besides the fact that I was just not cut out to be a salesman, the leasing company that owned REAL was having some legal problems. So rather than sticking it out and continuing to fail I decided it was time to find a new work home. And my SAN experience was key in leading me to my eighth career step when I was offered a job at McDATA Corporation in 2000.


McDATA, headquartered in Broomfield, Colorado, was a company with a rich history in the mainframe data center. They had created SNA products as well as pioneering the first high availability ESCON director (9032-3) which IBM OEM’d from them. Purchased by EMC in 1995, McDATA engineered and sold the first director-class (five-9s of availability) fibre channel switching device known as the ED5000. And those 1 Gbps, 32-port machines often sold for a quarter of a million dollars each!


Based in Atlanta I was the SE with responsibility for pre-sales support in Georgia, Alabama and part of Tennessee. It was a great experience working with such a mature company that had created that first high availability ESCON director and they were already selling their 1 Gbps FC director and were in the latter stages of development of the 2 Gbps director which would soon be called the Intrepid 6140.


 McDATA always used its partners to sell its products rather than selling them direct. That meant that the McDATA sales teams really had two customers to convince about our capabilities – the end user and the partner that was selling the product. That was quite a challenge and really improved my personal technical and selling skills. I also learned quite a bit about sales reps who were good at farming (working with existing customers) and those who were better at hunting (finding new customers). They are two unique skill sets and a single sales rep can seldom do both equally well. Fortunately, I was very successful and had a great time as an SE at McDATA from 2000 to 2004. Then I was offered a worldwide role as a FICON Solutions Architect which I accepted. I think of this as my ninth career step since it took me out of a local sphere of influence in the southeastern USA and put me on the world stage for the first time. So for the next three years I provided product presentations and updates and classes to clients all over the world. And I worked with McDATA corporate to create competitive materials that were used worldwide to win mainframe-centric switching business when competing against Brocade and Cisco. It was an exhilarating time. Most people retire so that they can travel. Here I was being paid to travel by McDATA to some of the world’s great cities like London and Paris and Tokyo. And then, as always happens, things changed again.


Brocade made a number of offers to purchase McDATA over the years but finally conditions were ripe in 2006 and the McDATA board of directors accepted an offer. During much of 2006 I still had to compete against Brocade even though I knew that Brocade would complete its acquisition and bring McDATA into its fold in early 2007 – business is pretty strange sometimes. Not all employees from McDATA were asked to move to Brocade but, luckily, I was and so I became a FICON Global Solution Specialist at Brocade, where I am obviously currently employed.


At Brocade, I a member of a select team of subject matter experts (aka Solutioneers) where my specific focus is on FICON and System z technologies. In this role I am a regular speaker at industry and vendor conferences such as SHARE, HP Tech Forum, and EMC Tech Conferences as well as at Brocade Conferences. I helped to create the Brocade Certified Architect for FICON (BCAF) professional examination and was a key contributor to the 9 module “Fundamentals of Brocade Mainframe Networking” class that supports the BCAF examination. I am also a published author on Mainframe I/O and FICON in particular. I have written articles that have appeared in zJournal and the CMG Proceedings and will soon have articles published in the Enterprise Executive magazine. And I get to meet many of the IBM doer’s and shaker’s in the mainframe world. What could be more fun? This job should close out the working epoch of my life as I look forward to retirement in the next few years. But man, what a ride it has been – and I still enjoy doing it every single day. Where-oh-where have these 45 years gone?


I hope this blog brought back some memories that you also hold near and dear. For some of you I hope I’ll inspire you to “reinvent” yourselves into newer, better more challenging jobs and careers. I guess in a few years when I retire I will be re-inventing myself again for the 10th time. You will find, as I have, that re-inventing one’s self is a lifelong process that usually gets easier as time goes along.


So I would encourage you to embrace change – it is going to happen anyway! Change is one of the few constants in technology and in industry. As many of us know, if you do not like what is happening with your company, or in your life, right now, well just wait a quarter or two – it will all change again – so embrace it.

by on ‎04-26-2014 03:27 AM

how can brocade be used as softwate application


by on ‎04-26-2014 03:28 AM

can i use this as a freelancer , like open source


by Dave Lytle on ‎04-27-2014 04:32 AM

Hello Ariffcal,


Brocade provides several pieces of software that can be used to manage switches. The premier management tool that we offer is Network Advisor. It is a fabric wide management platform for both FC and IP. From Network Advisor, for example, one could also launch a specific switches element manager (Webtools). We also provide a free SAN Health Check tool which is probably the best free tool from a vendor available to help you understand all of the assets within a fabric and how they are currently deployed and used.


Brocade does not have any general purpose software applications other than switch management and information.


As far as your 2nd question is concerned, I am not sure what you are asking me about being a freelancer. Can you please explain that more fully?


Thank you.