Mainframes, SOA & Sex
As you can imagine, most of these suggestions, or the spirit and tone of them at least, work not only for most consumer software, but also with enterprise software, in both cases, social or otherwise. Simple, very open, interoperable by virtue of Plain Old XML (POX) APIs into your system are a quick and easy win.
We've talked with many people in the mainframe space -- selling mainframes or software and services that involve mainframes -- of late about how SOA is helping drive more use of and visibility for the services that mainframes provide. Wrapping a web service (usually SOAP) around a mainframe's "functionality" (to avoid using the word "services" again ;>) opens the mainframe up to more people. As Chip said last night (not an exact quote), "if you've got a web service wrapped around it, I don't care what the back-end is, I just use the service if it's good."
It's kind of like the way screen are used to eliminate bias in symphony try-outs, as outlined in Blink. Before the use of screens to hide the sex of the musicians trying out, women rarely got selected. Once that industry started putting screens up to hide the candidates sex, more women got hired.
Some people will avoid using mainframe based services simply because they think mainframes aren't cool. Surely all that Intel Inside stuff is better, right? As can always be pointed out, people are more the drivers of technical decisions than the underlying technology. Wrap a web service around the mainframe, and you've widened the audience, adding more "nodes" to your network, and increased the mainframe's value.
More important to the analogy back to simple APIs, if you remove all the clutter, access restrictions, and bias from things like WS-*, roach motels, and sex you can focus on the service being provided: be that service submitting a PO, offering a resume, or playing music.
As far as I know, mainframes are pretty damn good at the last two. With SOA putting the screen up nobody will claim dude looks like a lady... or vice-versa.
|by James Governor||March 27, 2006 |
Permalink | Comments (3) | TrackBack (1)
Questions for the mainframe commmunity: Ruby, RACF?
Initially I just posted some answers to my blog. But actually it makes sense to surface the questions here too. You guys are the experts right. So how about it? Ruby and RACF futures?
1. Does Ruby run on Z/OS? If not, anyone game to work with me to port it? Hopefully, if we port it, the folks in the media will tell the story of how open source can also be created by folks who work in large enterprises and not just software vendors.
3. Does anyone know of any open source equivalents to RACF? Ideally looking for something that plugs into the SAF interface.
4. When will EnterpriseDB run on Z/OS (other than on Linux on the host) or for that matter MySQL?
5. Anyone know of a COBOL SOAP stack? Not interested in all those fancy integration products
6. Any thoughts on how to integrate SXORE and/or Infocard with RACF?
7. As I understand, the Mono Project now runs on the mainframe. Should folks in the enterprise consider running .NET applications there?
I tend to think the notion of a mainframe shop deciding to run an "open source equivalent of RACF" has two hopes- Bob Hope and No Hope. But note that James is not asking how to replace the mainframe, just how to do more interesting things with it.
Some might ask why James is both critiquing Ruby, and asking for porting help. Well I guess its called being a contrarian. So do any of you know about Ruby on z? I suggested Netrexx but that's of course answering a direct question with an alternative... never a great look.
|by James Governor||March 20, 2006 in Application Development |
Permalink | Comments (6) | TrackBack (0)
Its the I/O Stupid: Linux on z
Steve makes an incredibly important point that anyone trying to argue the benefits of mainframe economics needs to take onboard. There is a lot of FUD out there about mainframe cost of ownership, but I/O is the missing element of a successful pushback.
Its like when you run calaculate costs of running DB2 and WebSphere on the mainframe. Competitor FUD calculates total costs without understanding the benefits of collapsing the different tiers into one system. There are cost and performance benefits, predicated on taking I/O hits out of the system.
When asked why run Linux on the mainframe Steve says:
First, the mainframe I/O subsystem is something that no other platform has: If you have to do a great deal of I/O to disks, the mainframe is your best choice. A single mainframe (not even a sysplex here) can address devices 0000-FFFF. That is potentially 256 100 megabit channels, each addressing 256 devices: 65k devices! on one computer. Now put that into a sysplex! The scale of it is just amazing, and there is another goodie tucked in there: the mainframe does not use it's CPU's to do I/O: It has "channel processors" separate that handle that. When a CPU wants to do I/O, it writes it to memory, taps the channel processor on the shoulder that the I/O is there in RAM ready to go, and then moves on to other work. The I/O processor takes care of getting it shoved down the channels, and does all the waiting for devices to respond to commands, etc.
That last bit is why fairly slow MF processors get a lot of work done. All they do is work. No I/O breaks.
What follows then is that transaction related stuff: data warehouses, RDB's, etc, all work better on the mainframe than anywhere else. As long as the workload is I/O and not CPU intensive, the mainframe is the best platform. In fact, any given CPU on the mainframe is not all that fast by todays AMD Opteron standards. it is just that on a PC based server, when you do I/O, you are doing it with the main CPU: All processor wait at the same speed, so you end up not getting all the goodness of a fast processor in an I/O intensive environment if the server is PC technology based.
The mainframe community needs to get FAR better at making this case. Every day people with a vested interest in seeing money spent on alternatives make incorrect economic claims about the advantages of other archietctures. The mainframe community knows mainframe I/O, and partition to partition calls with no overhead, are key advantages, but for some reason let others control the debate.
Wouldn't it make sense to establish some benchmarks that show the mainframe off in its best light, rather than playing on a playing field defined by CPU as a measure of performance?
|by James Governor||March 16, 2006 |
Permalink | Comments (12) | TrackBack (0)
CNET: z/OS meets Zen
Mainframe haiku: Stephen Shankland’s March 10th post on the CNET blog quotes a few poems from the mainframe contest, including this one from Van Landrum at the University of South Alabama:
The wind blows softly
Through the leaves of autumn. Wait,
That's just the mainframe
|by Timothy Sipples||March 13, 2006 |
Permalink | Comments (0) | TrackBack (0)
Whoa Little Penquins
Careful what you ask for because you might just get it.
Rick and Jim asked for Linux on z/VM ... and they got it ... big time!
Nationwide's current slogan is "Life comes at you Fast"
and Linux has come at Jim and Rick fast.
If you're going to
thist week (March 5-10), be sure to catch
their tag-team sessions on Tuesday, numbers 9212 and 9213 at 3 and 4:30.
The title is appropriately "Linux on VM - from Woe to Whoa!".
Reigning in these flightless tuxedos is like herding cats.
(Oh, my, ... we've gone and borrowed yet more from advertising,
and we may have abused another knight's title in the process.)
The challenge is to deliver solutions which fly while preserving
the advantage of V12N. There is a real need to have resource sharing,
but that objective must come second, behind basic system operation.
So Rick and Jim are battling the bulge of the CPU chewers
and the memory munchers.
|by sirsanta||March 4, 2006 |
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.