Mainframe Potpourri for Mid-April, 2009
Once again it's time for everyone's favorite Mainframe Blog featurette: The Mainframe Potpourri. Are you ready for some pseudo-random reads?
- Miya Knights writes about 21st Century Mainframes.
- An article in HPCwire, Hard Times May Boost Linux in Financial Services, mentions the Bank of New Zealand's efficiency gains with Linux on System z.
- InfoSec, an IT services company, takes advantage of the stimulus buzz and announces a Mainframe Services Stimulus Package.
- MetLife has far better disaster recovery capabilities now, thanks to mainframe technologies. Previously it took MetLife three days (!) to recover in the event of a disaster. Now they're down to 4 to 6 hours. For real, because they thoroughly tested and rehearsed. (Have you rehearsed your end-to-end disaster recovery plan lately? Don't forget to eliminate at least half your employees during the rehearsal, including your most "critical" IT employees, because they'll be busy protecting their families or gone in a real disaster.)
- Big Iron's Appeal to Young IT Pros, reports Baseline. In the same publication Elizabeth Bell writes about The Magic of Mainframes.
- The Guardian (U.K.) celebrates COBOL which just reached its 50th birthday. You're looking more beautiful (and useful) than ever, COBOL. Happy birthday!
- Big Iron Bucks a Trend, says Enterprise Systems Journal.
- Akhtar Pasha reports for Express Computer (India) on the growing success of System z among India's corporations and government agencies. (Full disclosure: I have supported some of these customers and/or associated IBM teams.)
- Will U.S. state governments ever get mainframe computing right? Or are they too busy making the same mistakes private industry did 20 years ago? You be the judge. Here are two dispatches, one from Texas, and the other from Florida. Of course, it'd be awfully nice if The Orlando Sentinel could report accurately on technology. I've read their article twice, and it's a mystery what's going on. Is Florida really running an actual System/360 or System/370? I doubt it, but that's what the article says.
- Jason Perlow has sage advice for Twitter, which is increasingly unable to scale and is experiencing various and growing service problems: buy a System z mainframe, maybe two. To which I'd add (if Twitter is reading): check out z/TPF. That's what Visa uses, and your application is an awful lot like Visa's. And you get to do all your programming in Linux. You guys can figure that out, right?
- Meet Bob Woods: musician, locomotive engineer, and mainframe programmer.
- Novell announces SUSE Linux Enterprise Server 11 for System z.
- Remember I said that IBM is investing heavily in new business intelligence capabilities for System z? There's yet another example to report: IBM announces InfoSphere Data Warehouse on System z.
- Using Microsoft .NET applications with DB2 for z/OS? Optimize them using pureQuery.
- Yes, it's 2009, but rewind to 1982 when IBM published The Economic Value of Rapid Response Time. Given today's ever more complex and delay-prone multi-multi-tier architectures versus the vastly simpler System z architectural pattern, that article is more relevant than ever. Learn well, Grasshopper.
- Marist College has published executive interviews from its Enterprise Computing Community Forum last month. There are some informative videos to watch.
- Can you make it to Belgium in early May? (Do you like fantastic chocolate?) Attend the System z Technical Conference.
- Or can you make it to Gaithersburg, Maryland, U.S.A. on April 21 and 22? Then you can attend the TCP/IP Networking Technologies Update, covering z/OS 1.9 and 1.10. There's no tuition charge. Contact Chris Newman by April 16 if you'd like to reserve a seat. First come, first served, just like z/OS with only a single WLM service class.
- Happy birthday, IBM mainframe! The revolution continues...with Portuguese subtitles:
|by Timothy Sipples||April 13, 2009 |
TrackBack URL for this entry:
Listed below are links to weblogs that reference Mainframe Potpourri for Mid-April, 2009:
What a pleasant surprise to see TPF mentioned and recommended.
How unfortunate that today in order to use TPF, you have to pay the extortionate price of at least 2 monthly licensing extortions(zOS, TPF) and one annual subscription extortion(Linux).
TPF is one of the best systems IBM has ever done. Too bad it is saddled with the overhead of zOS when it would have been relatively simple to require only TPF itself and one of linux or solaris. Solaris plus TPF would be an even more interesting approach because it could offer many of the advantages of VM. And to think it would only take a commitment to making a PL/I compiler with appropriate runtime support available on the unix/linux side to make this possible. No way to escape the zOS boondoggle though. Oh well.
Posted by: emes | Apr 13, 2009 9:06:24 AM
I'm not sure exactly what you're referring to, emes. You can now develop for z/TPF using gcc on Linux. While many z/TPF sites use z/OS -- certainly not a "boondoggle" -- that isn't a firm requirement. Are you thinking of the prior TPF/ESA, perhaps? Or ALCS?
Posted by: Timothy | Apr 13, 2009 9:34:06 AM
zTPF has a collection of programs which are referred to as 'offline' analysis and database recoup which are supplied as PL/I source code. This PL/I code at system generation or if modified requires a PL/I compiler which only runs on zOS. It is correct that application programs can be developed as you say, but the system side is not yet free of zOS bondage due to this PL/I requirement. If assembler H/HLASM is now available on Linux, only PL/I stands in the way of a zOS free system.
Posted by: emes | Apr 13, 2009 12:51:16 PM
z/OS bondage?!?! Good grief, I have no idea what you're talking about. It's an operating system that runs concurrently on the same machine, and a darn useful one.
But if there's some quota (?) on operating systems with the letter "z" in their names, I can speak to HLASM which is available for Linux on z. IBM program number (for IFLs) is 5799-TCQ. (But does "Linux on z" violate the z letter quota? :-)) The z/TPF documentation says this HLASM works fine.
As for PL/I, program number 5688-235, the PL/I compiler for z/VM, is available (and mentioned by TPF docs), and one would assume you'd be running Linux (and perhaps some instances of z/TPF for development) under z/VM, so perhaps this all fits technically. (But z/VM has the letter z in it, too, so who knows. :-)) Is it really necessary to modify and recompile that PL/I anyway? I'm less familiar with the PL/I offline programs you're talking about, so perhaps someone else can comment on how this works.
Posted by: Timothy | Apr 13, 2009 10:33:53 PM
If you want to learn about the concept here, two zTPF publications can make it abundantly clear. I think you may not be familiar with zTPF as a whole, which has a sysgen process that requires compilation of PL/I as part of the generation of an operating zTPF system, whether you change something or not. In addition, because the system generation process is highly linked to JCL procedures, there is almost no practical way to escape having to pay for zOS.
My point is that in order to run a zTPF system, you are compelled to pay money for an unnecessary zOS operating system whose costs are extortive compared to other alternatives. It would be substantially cheaper and more realistic to run zVM, linux, and zTPF save for not being able to get past JCL and PL/I compilation. I was once told that there were people who did manage to be able to eliminate zOS/OS390 some years ago with VM/ESA-zVM, but this seems to be difficult or impossible now.
Solaris would be even better than linux and even eliminate the need for zVM given its more refined workload management features, but for now, it is crippled into requiring zVM for the most elementary and essential aspects of i/o. It also just isn't production ready as yet. Solaris is an interestingly disruptive technology for the mainframe, assuming it is ever brought to full independent function. In fact, one interesting aspect of that are its real-time features which could in fact supplant any need for any IBM operating system, including zTPF.
Posted by: emes | Apr 14, 2009 12:05:14 AM
Let's use some real numbers here, shall we?
I'm going to make a number of assumptions, starting with assuming that Twitter would need to buy z/OS and the Enterprise PL/I compiler, as you assume. Twitter is clearly "new workload," so presumably it would qualify for zNALC z/OS. Let's price 3 MSUs (the minimum; can be softcapped and thus shoot well above 3 MSUs for periods of time) of zNALC z/OS (5694-A01) including C/C++ without Debug (we'll toss it in, but presumably Twitter would do almost everything with gcc on Linux), DFSMSdss, RMF, SDSF (not strictly required but we'll add it), and the Security Server. HLASM is included in the base. And we'll add Enterprise PL/I (5655-H31) Alternate Function (i.e. without Debug Tool). Total price? Under $1000 per month (U.S. price -- Twitter is in the U.S.), perhaps well under, depending on some other assumptions.
For perspective, that's roughly the same as the annual maintenance charge only (not including license) for a single Intel CPU of Oracle Database Enterprise Edition. It's quite a bit less than the annual maintenance charge for a single IFL for Linux on System z.
"Extortive" costs? If by "extortive" you mean "above zero," I guess so, but please, let's not get silly.
Posted by: Timothy | Apr 14, 2009 12:46:53 AM
Just a quick update: If I juggle the numbers, the highest (exact) price I can reach is $1049 per month (U.S.) using the above assumptions. The real exact price could be $1049 or something lower, depending on a few other assumptions.
Posted by: Timothy | Apr 14, 2009 1:09:16 AM
Oh dear, I made an error. If you replace DFSMSdss with DFSMSdss,hsm (more function), the price falls to $851 per month with the above assumptions. I should have remembered that little quirk. Sorry about that.
Posted by: Timothy | Apr 14, 2009 10:05:41 AM
Out of curiousity, if you used a more likely workload size more appropriate for the Twitter workload, say 1000 MSU, I wonder what the zOS costs would be?
Posted by: emes | Apr 14, 2009 1:58:26 PM
correction, I should have assumed your mention of approximately 2 P/390s worth of zOS was based on the development/compilation requirements. This then makes the TPF component the interesting price in the mix.
Posted by: emes | Apr 14, 2009 2:09:19 PM
Posted by: Cisco | Oct 13, 2009 6:14:06 PM
The comments to this entry are closed.