Seamus McManus: Beekeeper; Father of Cloud Computing
A 2 minute 'history' of cloud computing, including the pivotal role of the mainframe. For a more factual account, see today's New York Time's article.
| by Tim Washer | June 15, 2009 in History Permalink | Comments (0) | TrackBack (0) |
A Tale of Two Mainframe customers – one growing and one leaving the mainframe
This is the tale of two mainframe customers. One customer
has achieved a period of tremendous growth in their business, processing
transactions on the mainframe, while reducing expenses and becoming more
resilient. The other business chose to get off the mainframe at a significant
cost and in all likelihood, spends more today than they would have on the
mainframe. What’s interesting is that at one time, they shared the same system
infrastructure. And Clerity, a consulting firm, would like you to believe that
the non-mainframe customer got tremendous value in the move. Here are their
stories.
In any basic computer architecture class, a student will
learn that the fewer the number of data moves, the better for performance. Now,
in an era of regulatory compliance and privacy considerations, that becomes
exceedingly true because each instance of data must now be auditable and
recoverable which implies additional costs for each extra instance of data.
This becomes important when considering an outsourced computing environment. It appears that SIAC never got this level of education, while its customer, DTCC seems to have excelled in this computer architecture class. Even funnier is that Clerity has decided that SIAC is a model customer…that doesn’t bode too well for their other consulting arrangements.
So what really happened?
DTCC’s trading business was growing tremendously. But let’s have them tell you, in their own words:
Sometimes "insourcing" pays off more than
outsourcing. Until last year, two DTCC subsidiaries outsourced all their
infrastructure support activities to the Securities Industry Automation
Corporation (SIAC). Now, following the completion of a multi-year initiative,
DTCC has cut costs and bolstered business continuity by insourcing the
activities previously performed by SIAC into DTCC’s infrastructure. The two
subsidiaries are National Securities Clearing Corporation (NSCC) and Fixed
Income Clearing Corporation (FICC). ……
On top of strengthening the industry's business
continuity and infrastructure, the project is yielding financial benefits,
enabling DTCC to cut the industry’s overall operating expenses. In 2006, by
leveraging DTCC's processing capabilities, insourcing has reduced DTCC's annual
operating expenses an estimated $42 million, said William Aimetti, DTCC’s chief
operating officer. This was one factor that enabled DTCC to lower its fees in
2006.
And going back to another DTCC newsletter, they explained that they got a 167% performance improvement, without a line of code change, because they reduced the number of data moves and connections necessary to process a transaction:
To keep ahead of transaction volumes that have been rising sharply over
the past several years, DTCC has significantly increased the capacity of its
mainframe database for equity processing. The system, called Trade Repository
Processing (TRP), can now process at least 160 million sides per day. This 167%
increase is nearly triple the previous capacity of 60 million sides.
What’s more, the TRP can handle the additional volume within the same time frames, thanks to changes that make the system perform more efficiently. In addition, for current volumes, the upgrade allows DTCC to deliver certain participant reports, such as the Consolidated Trade Summary, up to 45 minutes earlier.
DTCC was able to do all this without modifying any of their
customers applications. While DTCC was hosted on the SIAC systems, they found
that there were extra network hops and copies of data deployed. They also were
heavily dependent on SIAC to make changes to the infrastructure on a regular
basis. Because both of the SIAC systems were located in the New
York City area, DTCC was also afraid that a single
catastrophe would take out the redundant systems and affect their availability.
These were the fundamental concerns that led DTCC to move out on its own.
Prior to this decision, SIAC signed a multi year agreement for software, systems and services with IBM. This agreement included discounted pricing assuming capacity growth projections that SIAC provided as their objectives. By sharing the mainframe infrastructure with DTCC, SIAC dramatically reduced their own operational overhead which was predominantly associated with batch processing and account reconciliation in the evening, while DTCC used the same processing infrastructure for trade transactions during the day. Each had applications that overlapped each other though.
When DTCC pulled their two applications from the SIAC
system, SIAC was left with a lot of free daytime capacity, but still a
reasonably busy system in the evening. But SIAC was now completely responsible
for the costs of this system. The growth potential that they had promised to IBM
would no longer be possible and as such, the discounts they were offered were
no longer relevant. This underutilized
mainframe was now quite a bit more expensive to SIAC than it had been when it
was sharing the expense with DTCC. That’s a fact…nothing sweet about that.
Now SIAC could actually have downsized with their mainframe
and reduced their costs. Instead, they chose to “down size” to a distributed
environment. In doing so, they also needed to solve federally mandated business
resilience requirements, something they had ignored on their previous mainframe,
and build another data center.
So using SIAC’s own words:
In 2006, when the Shared Data Center team, the technology
arm of the New York Stock Exchange (NYSE), evaluated its internal
infrastructure in light of competitive market factors, changing regulations,
and anticipated future growth, the decision was made to replatform its 1,660
MIPS mainframe workload onto IBM System p Model 595 servers running AIX and
UniKix rehosting software from Clerity.
"Quite simply, we can now transact more business per
hour at a lower rate," said Francis Feldman, Vice President of the Shared Data Center
So let’s parse this a little bit. Notice the timeframe:
2006….it’s the same time that DTCC moved off the SIAC system. The 1660 MIPS is
the combined processing power for both DTCC and SIAC. The reality is that SIAC
NEVER used all that capacity themselves, even though they owned the system. So
while factually true, it wasn’t real. Changing regulations refers to the need
to develop a second site outside the New York metropolitan area. After converting the
applications, SIAC had to create automation and recovery scripts and deploy the
new servers at an alternative location as well. I am assuming that they
licensed the software for those systems as well. And this required changes
for all of SIAC’s customers as well. That cost certainly isn’t factored
into the migration costs for SIAC. Finally, I wonder what SIAC’s cost were when
they shared the infrastructure….is the new solution more or less than that
environment? Unfortunately, we’ll never know because the new environment
includes a new data center….but I could imagine it was less.
So, an alternative plan, at presumably far less expense, effort
and time, with little or no application changes, would have been to downsize
the mainframe to the size appropriate to SIAC’s new capacity requirements. To
meet the resiliency objectives, SIAC could have installed a mainframe in
another geographic location using IBM’s Capacity Backup pricing which would not
have charged for software usage except during a disaster, while still allowing
for regular disaster preparedness testing with no additional licensing costs. Many of IBM’s customers take advantage of this
model for availability processing.
And has availability improved? Click here for a list of outages that SIAC experienced in 2008. All types, but not associated with the mainframe. Perhaps SIAC changed their reporting structure in 2008, but I can’t find many outages listed in a search on 2007, though there is an awful lot of information dating back many years on their site.
As for SIAC, I don't know, but they don't spend nearly the amount of time bragging about their infrastructure as DTCC. That should give you a clue right there!
| by JimPorell | January 6, 2009 in Current Affairs, Economics, History, Systems Technology Permalink | Comments (1) | TrackBack (0) |
Who do you trust? RFG? Yes. HP? No
In my last entry, I talked about the misleading information that HP provided regarding a consulting report to get off the mainframe. In that dialog, I also referenced the same consulting group giving pro-mainframe support and then asked rhetorically, who do you trust, RFG or RFG? I’ve worked closely with Robert Francis Group and I was wondering why they would have done this.
Well, it looks like RFG is a lot more trustworthy than HP who misused the consulting report. Today, RFG put out a press release in which their headline reiterated:
RFG Still
Believes That the Mainframe Is One of the Best and Most Energy Efficient
Platform Options.
Well, it was certainly nice to see that and their explanation. Anyone hazard to guess when we might see a retraction or correction from HP?
| by JimPorell | November 17, 2008 in Economics, History, Innovation Permalink | Comments (2) | TrackBack (0) |
Of Hurricaines and Old Haunts
With one storm having hit New Orleans and another hammering South Texas, memories come back like flood waters. Thankfully, the Crescent City did not experience the trauma that we feared, a repeat of three years ago. Still, we all clung to our television and internet news feeds. To me, the names of the canals and streets and neighborhoods are all too familiar. I lived there once. It's where I met VM.
Back in the days when I was coasting through college, Mom and Dad were living in New Orleans. The Big Easy was the place where I went for the break. I needed a summertime job ... anything. Found a non-specific clerical job with a geologist at Shell Oil. Hey! That's cool! Working at One Shell Square! That geologist soon learned that I had a technical bent and set me to work on some minor programming he needed done. (This is another example of God throwing a gem in your path when you were not savvy enough to go digging for it.) The system was something called VM/SP.
This VM/SP thing was IBM all the way. Big hardware; big terminal. The terminal I used was a boat anchor of a thing, a 3270 model 5 with 27 lines and 132 columns. Strictly speaking, it was a dumb terminal but was the smartest dumb terminal I had yet encountered. There was a component of VM/SP called CMS, the Conversational Monitor System. The way you interacted with CMS was that you typed a bunch on the screen and the computer at the other end of the wire was sent all your typing at once.
At least once I snatched a glimpse of the 43xx series hardware in the machine room, There was some grand plan for these machines. (I later learned the plan was PROFS which Shell and many other large companies used for office email ... before there was an Internet.) VM really caught on at Shell and was used for years, especially thanks to PROFS, later called OfficeVision, but also because engineers could build their batch jobs for other systems using the excellent editor built into CMS and then punch those jobs to other systems for execution. VM is like "datacenter glue", nimbly connecting unlike systems.
But VM was more than just a spiffy interactive system. It presented every user with his own (virtual) System/370 computer. I asked about this for clarification: It's your own personal "machine"? Yes. Can you boot other operating systems? Yes. Sweet! I figured that Shell had paid through the nose for this fine technology. Only later did I learn that VM was one of the cheaper system products available. When I got back to school, I told friends and professors about this amazing system which allowed you to run other operating systems concurrently on one physical box. One of my professors was especially clued in and in his overview of operating systems he pronounced, "VM is the baby", the precious one.
Eventually my alma mater did get VM. And then there was BITNET and that whole story, which we should save for another time.
The baby has grown up: VM/HPO, VM/XA, VM/ESA, and now z/VM. Though PROFS and OfficeVision have fallen to stacked Dominos, VM has recently enjoyed the resurgence you all know about thanks to Linux. It's hypervisor is the finely tuned engine driving hundreds and sometimes thousands of virtual penguins. CMS hasn't changed much in appearance, so my old friends at Shell would still recognize it. While those in other shells (eg: on Linux) have no idea that they're being supported by a warm teddy bear of a host.
When Katrina hit, aside from the human tragedy, I wondered how One Shell Square faired. Funny how the mind goes to the familiar even in the most shocking circumstances. My sources tell me Shell still runs VM, but not like it once did.
-- R;
| by sirsanta | September 30, 2008 in History Permalink | Comments (1) | TrackBack (0) |
New York Times: "Why Old Technologies Are Still Kicking"
Few readers of this blog are unfamiliar with Stewart Alsop's 1991 claim that in five years' time the last mainframe would be unplugged. It's become a piece of good humor over the years - with even Stewart himself sharing in the laugh by appearing in the pages of one of IBM's annual reports to "eat his words."
Still, the issue has always been one considered from the point of "if."
On Sunday, the New York Times took a "why" look at the dynamics behind the comings and goings - and mostly the staying power - of various technologies. The article is called "Why Old Technologies Are Still Kicking," and is certainly worth a read.
Front and center in this reporting is the IBM mainframe. The article even includes a colorful (well, one of them is in color) pair of mainframe photos that not only show how far the mainframe has come, but how far fashion and hair style seem to have evolved during the mainframe's lineage. See below (and be sure to check out the Times article).
| by Kevin Acocella | March 25, 2008 in History Permalink | Comments (1) | TrackBack (0) |
Will Microsoft Windows be next on System z?
Anyone paying attention to the Sine Nomine demo, two weeks ago, now knows that Solaris is inevitably
coming to System z. In the wake of all of this, I have heard from a number of
you – and people throughout the industry about – you guessed it: “What’s next,
Windows?” I’m guessing many of you have
the same question. To really get at the
dynamics of this, we have to look to the past.
Back in the early 90's, Windows was not just on the x86
architecture (at the time, only on Intel – remember Wintel?). It was also running on
MIPS, Alpha and the PowerPC architecture. There's something a bit different
about the x86 architecture....this is a bit technical here, but it uses the Little Endian bit
representation within a byte while the RISC architectures under the popular
UNIX platforms and IBM's mainframe use Big Endian
architecture. Solaris and Linux were
written in a way that makes that bit representation transparent. But Microsoft
decided long ago that Windows would only run in Little Endian mode.
Back in 1994, there was a skunk works within the IBM
mainframe division that looked at running Windows NT as a native operating
system on what was then a 10-way S/390 platform. It figured out how to boot the
machine up as a Little Endian server and it could have run Windows across those
10 processors. But guess what? No hypervisor or virtualization capabilities
would exist. They have been written in Big Endian mode. So it would be an
entire mainframe dedicated to a single instance of Windows. My palm can do
that.
So, IBM realized then that this had no future in terms of
consolidation value. In turn, Microsoft decided to uniquely support the x86
architecture and the Alpha and MIPS implementations of Windows died a rather
quick death.
Next up was to bring some Windows portability to the
mainframe. So working with Bristol Technology (now a subsidiary of HP), IBM
looked at getting a set of Windows 32 bit APIs and its OLE and COM capabilities
on OS/390. This was just after IBM had announced its intention to brand OS/390
as a UNIX operating system. Bristol Technology had a license to the
Microsoft source code to facilitate that. Well, Microsoft must have gotten
afraid of the possibilities of Windows applications running easily on the
mainframe, so they took away the software license from
Bristol
. Bristol, in turn, sued them for unfair trade and they won. But by then, Microsoft’s approach had driven these types of developers from their platform. Today, Mainsoft Corporation provides a Windows portability layer across UNIX systems and z/OS, but we'll never see a day when Windows will run natively on the mainframe.
So what are the implications to the mainframe? Let’s start
with development tools for creating new applications. If you only use Microsoft
.Net development tooling, those solutions will be relegated to the Wintel
platform. Should those applications want to interoperate with the mainframe,
there are a variety of connectors that enable interoperability with both 3270
and SOAP/Web service based applications as well as distributed data requests. As mentioned earlier, you can use Mainsoft's technology to translate the .Net code into Java byte codes and run that on z/OS and Linux for System z as well. Therefore you get some developers synergy, but deployment options beyond Wintel platforms.
If you really want cross platform deployment from the Windows desktop environment, eclipse.org is an open standards group comprised of a number of leading tooling vendors to facilitate rapid application development, good tool integration and provide a flexible choice for platforms to which those applications can be deployed. Leveraging this tool set will facilitate exploitation of mainframe technology and is highly recommended to deliver the best qualities of service for software running on System z. IBM’s Rational Developer for z is an implementation of the eclipse capabilities for System z.
| by JimPorell | December 14, 2007 in History Permalink | Comments (7) | TrackBack (0) |
the greaterIBM connection
One of the many innovations Sam Palmisano has spearheaded at IBM is the idea of reaching out to "alumni". The first initiative was a few years ago when he hosted a reception for a group of former executives of the company. A few were retired but most were in senior positions in other companies. That was just the beginning and now the idea of reaching out has been expanded -- big time. The number of past and present IBMers is probably close to a million people. Establishing communications with such a huge base can be nothing but a good thing for the company.
When I left engineering school and joined IBM in 1967, it was common to look for a job at a company and expect to stay there your entire career. Nobody thinks that way anymore. If you tell someone you were with a company for decades, they might ask "what's the matter, couldn't you find any other jobs?". Another change is that in the old days if someone left the company they were considered a traitor and barred from coming back. Today, there are many executives that left the company at some point, got some experience at one or more other companies, and then brought that experience back into IBM. Some have come and gone multiple times. The turnover has strengthened the company.
And now we have social networks. In the early stages there was a perception that social networking meant eleven year-old girls on MySpace. Now businesses are realizing that it is more likely forty or fifty year-old business people on Facebook and Xing and LinkedIn and Plaxo Pulse. The Internet has enabled everyone to be connected to everyone. Whether it is reading blogs, posting to wikis, updating status on Facebook, or making new connections through viral invitations, it is clear that a big company like IBM has a lot to gain by "connecting" past, present, and future IBMers to each other and with the company. IBM calls it "the greaterIBM connection". On Monday evening the company hosted a greaterIBM reception at the Metrazur at Grand Central Station in New York. More than four hundred attended. It was good to reconnect with some colleagues I had not seen for quite a few years.
Will social networking payoff in business terms? Nobody knows for sure but in my opinion it is certain -- as soon as we see the New York Times run a front page story that social networking is a fad, in trouble or peaking out we will have confirmation that success is a sure thing. A short term inhibitor is that there are so many different social networks. As web standards evolve I am confident that we will have a world where people will create one profile and then be able to decide which part of their profile is accessible in which networks.
IBM sees the potential and is investing the time and resources to build a large and active network. The possibilities are endless -- collaboration on projects, networking to hire or get hired, crafting deals, referrals to and from IBM and its business partners. As a bonus, social networking is fun and good for morale. I look forward to continuing to be a part of the greaterIBM connection as it evolves. Upon e-tirement in 2001 after nearly four decades at IBM, I don't really feel like I left anyway! The stories that I have been writing since 1998 over at the patrickWeb blog fall into a number of categories. One section is devoted to "IBM Happenings". I am sure I will also be writing and linking at the greaterIBM connection along with others. Cross linking will increase the overall "connectedness". That's what the web is all about. I am really proud that IBM is taking networking and the blogosphere so seriously.
the greaterIBM connection
Greater IBM Wiki
| by John R Patrick | November 14, 2007 in History, Innovation, People Permalink | Comments (0) | TrackBack (0) |
Maximizing the Mainframe
eWeek and CIO Insight had a nice article on the resurgence of the mainframe. In the article the author, Darryl Taft likens that the mainframe continues to go on and on like the Energizer bunny.
The fun doesn't end there, though. Ben Worthen takes that article and posts to his blog at the Wall Street Journal: The Dinosaurs won't die! There's a lot of truth to that. We recently celebrated the 40th anniversary of the mainframe. I can remember when Carl Conti was the leader of the Data Processing Division back when the mainframe was 25 years old. At the time, he stated that the Dinosaurs lived for over 25 million years. As such, this dinosaur of a computer, at a mere 25 years then, had a long and storied life ahead of us. Still in its infancy then, this venerable mainframe has a long way to go.
In response to the WSJ blog, I posted the following:
Great post. You’re hitting on a really important trend: corporate data centers around the world are stuffed with too many computers that consume way too much energy, take up too much real estate and cost too much to administer. That’s a big reason for the renaissance of the IBM mainframe — one of the most technically advanced and secure computing systems in the world.
Reflecting over a billion dollars of investment over the past decade, the mainframe’s automated virtual environment sets the standard for consolidating large numbers of smaller servers to save space, labor and energy. And this is not just about the mainframe. The mainframe is open and plays nice with other hardware and software — including kiosks, desktops, ATMs, PDAs or web browsers as the new human computer interfaces (instead of those “old school” punch cards). This openness along with secure, reliable operations… makes it a great hub for global collaboration at companies running around the clock.
One excellent source of
information on the mainframe’s strengths is Gartner’s
recently-completed in-depth study of how one customer, Nationwide
Insurance, consolidated hundreds of smaller servers onto the system.
Nationwide projects its savings of $15 million over three years,
including a 50 percent decrease in hardware and operating system
support costs and an 80 percent reduction in floor space and energy
usage. You can read the full report here:
http://mediaproducts.gartner.com/gc/reprints/ibm/external/volume2/article13/pdf/article13.pdf
We've got plenty of history behind us and more to create with this constantly evolving Dinosaur and it will just keep on running.
| by JimPorell | July 24, 2007 in History Permalink | Comments (0) | TrackBack (1) |
Core Connectors
Greater IBM has made a "call for core connectors". Hmmm. Core connectors? What kind of cores are they that need to be connected? Most of the current IBMers are not old enough to remember "core" memory that was used in mainframes. Core connectors also sounds like something from a Lego parts list. Both of these thoughts are nostalgic but we all know that is not what IBM has in mind.
The goal is to build a social networking community -- a "place" where the possibilities are endless -- collaboration on projects, personal networking for jobs and deals, referrals to and from IBM, and networking just for the fun of it. One of the key questions being asked is how does Greater IBM get highly-networked 'core connectors' to spend the time to help get things going and spur organic growth of the community. Not easy for sure.
The challenge is that the people who are the best networkers are already so busy networking that it is hard to motivate them to take on yet another "channel" of communications. I encounter the same challenge at the numerous boards where I am privileged to serve and that have the same goals as IBM -- building their communities. I don't claim to have the magic answer but in short the best approach I have seen over the years is to apply tenacious program management, just as IBM is doing. Occasional emails from people encouraging the "cc's" to visit the blog and or group and post something eventually work. It is a given that the people with the most to contribute are also the ones with the least time and so the occasional nudge often causes things to happen.
The other angle is to publicize success stories about how the community has actually helped someone. It is best if the person actually helped tells their own story -- again perhaps with a little prodding. The successes are often subtle and indirect. It isn't that someone posts "I need a job" and they get an email with an offer for the dream job. More likely the job (or deal) comes from someone who knows someone who knows someone who read something about an opportunity or a person and then was able to make the connection. Sometimes there are multiple bank shots involved. Here is an example of what I mean.
I started writing "reflections" in 1996 and they evolved into my blog. In the early days of RSS (really simple syndication) many people didn't know what a blog reader was and didn't know how to include an RSS feed into their browser or news portal. I started enabling people to "subscribe" to my blog in a way that generates an email version of each story that I write. There are now more approximately 400 people who read patrickWeb via email. When readers like a story they tend to forward it to their friends and this results in more subscribers and more readers. Some of the readers are reporters. Sometimes a reporter will send an email asking for an interview. The interview gets covered in the press. XYZ Company decides to hold a conference for their customers and they call or visit the Washington Speakers Bureau to get an outside speaker. The WSB refers XYZ to the interview that was in the press and sets up an engagement for a paid speech. In some cases the story that lead to the chain of events may have had nothing to do with the ultimate subject of interest to XYZ -- it was the communications that lead to something that lead to something, etc. The same principles apply to getting a job or landing a deal.
Building the community and getting tangible results from it takes a lot of time and tenacity. Greater IBM is on the case and making progress. I encourage all of us out there with stories to tell to keep telling them. You never know where they will lead.
Other patrickWeb stories about blogging
Other patrickWeb stories about IBM
| by John R Patrick | August 27, 2006 in History, People Permalink | Comments (1) | TrackBack (0) |
Mainframe code presents problems?
A discussion thread from the IMS-Listserver, that has been going over the last few days:
Did anyone get a chance to read the following article?
This seems to imply that big banks will be migrating off the mainframe (IMS) real soon.
Also, it mentions SABRE which is American Airlines TPF (Transactions Processing Facility) also known as ACP (Airline Control Program). Most TPF applications are written in assembler. They are very small and very fast. TPF programs track everything from reservations on millions of airline flights, advanced seat selection and on-time performance of aircraft. I wonder how well a network of distributed servers can handle what is essentially a huge inventory application with very perishable product?
Any comments?
-----------------------------------------------------------------------
WOW. As an alumnus of the long defunct Eastern Airlines; this brings back memories that are older than I admit to being. Eastern collaborated with IBM on the original ACP and sold a copy to American for what was then the 'world record' price for a piece of software. It may still be the 'record'; depending on how you define 'single function' software.
Notably, AMR only speaks of the high cost of conversion. It doesn't sound to me like they are seriously considering replacement. If anyone from SABRE monitors this forum; it would be fascinating to hear how many transactions per second they are processing these days. That would spawn a discussion in this forum of whether or not IMS could yet handle that volume.
IMS transaction integrity would be a HUGE leap forward. When an ACP transaction died, the application program was responsible for backout/recovery/cleanup/everything. Ponder that the next time an airline can't find a record of your reservation.
I pursued converting Eastern's reservation system to IMS Fast Path in the mid 1980s. Our ACP group viewed that as a call for jihad and Eastern was spiraling into bankruptcy so rapidly that the only positive outcome was giving me something to discuss with Peggy Rader.
ACP/TPF was a brilliant piece of code for it's time; but, that was a long time ago. It never approached IMS Reliability. Dale
P.S. 'Financial' institutions will likely migrate away from IMS whenever someone produces a database & transaction processor that is more reliable than IMS (sometime after pigs learn to fly).
-----------------------------------------------------------------------
Great discussion! As an Alumnus of the defunct Piedmont Airlines and USAIR, I could not agree more with Dale. Brilliantly put. However, the sad news here is that the Mainframe is NOT a strategic direction for my corporation no matter what you say or what proof you have to show otherwise. No way to get anyone to look at the tremendous cost of running everything on a gazillion servers or how many people it takes to support those servers not to mention the non-24x7 availability.
The most puzzling thing to me is the three-day reorg. When was the last time one of those ran on the mainframe, IMS especially? Probably only one prior to converting it to make-sense products like MAXM Reorg or even Online Reorg if using HALDB.
I feel IBM let us all down. In technical conferences of the past, I have brought that topic up. IBM Marketing expected the individual corporate techies to drive technology and save the mainframe. That went away in the 80's and early 90's. Who listens to us now?
Now the CIO's get the common trade journals. Where was the mainframe being marketed there? Where was IMS, MVS, CICS or DB2 being marketed? No where. That, my friends, is the problem. Newer technologies came and crept up on us and our naivety felt the dependable nature of the Mainframe would win out. Wake up.
We all know we have the most stable systems around. You can't compare the response times or reliability with Open Systems. But let's make way for all those servers which are now beginning to take up areas in the data center that resemble the old DASD and CPU farms. My goodness, has anyone seen the new servers? They look just like old 360's. Try to convince upper management the Mainframe is the best investment and they now look at you like you just swallowed poison. How very tragic. I worked on both TPF and IMS at Piedmont
-----------------------------------------------------------------------
OK, the first thing I'm getting from this discussion is that at one time or another, just about every IMS DBA or systems programmer on earth must have worked for a major airline that has merged, gone belly-up, or come close. Count me in that group as an ex-US Airways alumnus.
<<begin rant>> Like others, I find this discussion fascinating. I'd been working as an IMS developer for less that a year in the early 80s when "friends" and trade publications began advising me that IMS was a dinosaur and would soon be eclipsed and replaced by DB2. The fact that we're all still discussing it tells you how accurate that prediction turned out to be.
During that same period, I attended night school at the University Pittsburgh ADA
At one of my recent employers (and there have been MANY), during an orientation session the CIO discussed the technology the company was using and would use in the future. There company hires a significant number of IROCs (Idiots Right Out of College), and most of them know only that CompSci educators have told them mainframe technology is outdated, and one questioned the CIO's statement that the mainframe was absolutely integral to the company's plans. The CIO put it into perspective by suggesting that rather than focusing on the terms "mainframe" and "servers" and seeing the two as being different species, that people unfamiliar with mainframes instead view them as the biggest, fastest, most powerful, most dependable, most cost effective servers imaginable, and understand that the mainframe is simply the best choice for many businesses processing high volumes of transactions and requiring speed and dependability above all else. Isn't that what IMS, z/OS and mainframes are all about? At most places I've been where both IMS and servers were used, the server application required far more DBAs and far more outages than IMS. When company executives make decisions to arbitrarily convert to server applications because that's what they see being hawked in magazines and trade journals, they're making technology decisions the same way they'd shop for a car, and that's a disservice to the companies for whom they're supposed to be guardians. <<end of rant>>
I agree with Ivan, who said earlier that the demise of mainframes and IMS has been greatly exaggerated. -----------------------------------------------------------------------
I really like the discussion this brings out, with Avram comments, I started out my career in 1969 with the state of Pennsylvania
After the end of the Vietnam war, I can remember working 7 days just to get 5 days work done, unemployment went sky high in the early 70's, but we still got the claims processed.
Today these systems even have GUI front ends on them, to give them the modern look. They are kinda of like the old Timex commercials, they take a lickin' and keep on ticking.
-----------------------------------------------------------------------
Re the question: "Anyone have any idea from IBM side for example, what's the relative revenue and profit between various *series? If mainframe is still profitable for IBM..."
Earlier someone posted a link to a NY Times article from this month that stated this;
"all mainframe-related hardware, software and services account for a quarter of its [IBM's] revenue and, more important, about half of I.B.M.'s total operating profit"
So one would assume pretty important then!
I know of a large company in the UK
So perhaps IBM think they can get more money from their customers by selling them non-mainframe products!?!
I think IBM need to encourage their mainframe customers to leverage their mainframe investment. All too often I think IBM is sending consultants who know nothing about mainframes through the doors of their customers. -----------------------------------------------------------------------
My concerns:
- Marketing for mainframe in individual shops, more and more shops the application people have access to business and not system people. Applications tend to market to business in silo view and don't need to worry about integrated application advantage at all. Business naturally will favour the slick views and the appearant savings. - Marketing for mainframe as a whole - Missing. Anyone have any idea from IBM side for example, what's the relative revenue and profit between various *series? If mainframe is still profitable for IBM, some money should be channel into making a better image. Or does IBM think a wild mazed IT environment is really the best thing for IBM? - Charge back scheme in various shops are probably more mature in the mainframe, and I wouldn't be surprised that many distributed system cost other than equipment is buried within the mainframe chargeback. - Software cost on mainframe - what a impressive system, that alone can bury mainframe, can't say anymore! - When your application enviornment start to migrate little bits to distributed enviroment, this creates an interesting inbalance because they will take all the easily done and cheap parts with them, leaving the difficult parts in the mainframe, thereby making the mainframe with higher percentage of mutants. After a few iterations, the applications left on host all look like dogs breakfast, and guess what, the system people have to deal with them. And then the application people say 'see, z is difficult and unmanageable' - a nice twist from 'the application is a mutant'.
On the other hand, I myself believe that distributed computing for high volume integrated environment is got to be hoax, we will be in high demand when the wave is over.
| by pwarmstrong | May 12, 2006 in Contest, History, Programming Permalink | Comments (1) | TrackBack (0) |
The postings on this site are our own and don’t necessarily represent the positions, strategies or opinions of our employers.
© Copyright 2005 the respective authors of the Mainframe Weblog.
