Tag Archive for mainframe

Linux And Mainframe Blog Added To Big Iron Works Blogroll

Linux And Mainframe BlogIBM Research and Development’s Eberhard Pasch has such a strong mainframe pedigree, I’m a little embarrassed to have overlooked his blog here at Big Iron Works for as long as I have.  His Linux And Mainframe is an excellent, living resource dedicated to the meeting of Linus’s kernel and big iron.  Any blog that celebrates the 40th birthday of IBM’s VM/370 virtualization layer is a blog I’m duty-bound to link to!

The format of Mr. Pasch’s content is also a throwback to the engineering logs that the weblog grew out of.  It’s a log of issues and resolutions on the web. As such, it’s a perfect addition to any mainframer’s subscription reader.  Terse, valuable descriptions and contexts. Love it.

The Six Laws Of Software Design

A poster showing the Six Laws of Software Design

The Six Laws Of Software Design (Click to download at full size)

Whether it’s COBOL code written in the 60s or it’s a snazzy new Ruby on Rails app, fundamental laws of software design apply. Violate them at your peril.

Max Kanat-Alexander, a reader of the O’Reilly book Code Simplicity contributed this poster at O’Reilly’s Facebook page.  I loved it: and maybe you will too, if you can read it.  Which you can’t, not at the resolution it’s at on this page.  What you can do is click the image once, making it appear larger.  Click it again to see / download it in all its 1400 pixel wide glory, send it off to the large-format output of your choice, tack it on the wall and proudly announce to the world that In This Shop, We Follow The Law.

Or something like that.

Note Law #2 in particular: an elegant formula for determining the cost/benefit ratio of development.  The perfect thing to bring the corner-office people back down to earth the next time they come back from a conference all wild-eyed and desperate to implement some dubious set of capabilities for no especially good reason.

Executive Order: All US Government Agencies Must Deploy A Web API

Seal of the President
The Applications Programming Interface, that language-independent “exposure of functions to the outside world” as my CS prof once summed it up, is no longer an option for any of Uncle Sam’s many agencies.  All federal shops are, per executive order of President Barack Obama, now required to support a web API.

Government Mainframes To Open Up

Among other things, the order is meant to “ensur[e] the safe and secure delivery and use of digital services to protect information and privacy; requiring agencies to establish central online resources for outside developers and to adopt new standards for making applicable  Government information open and machine-readable by default;  aggregating agencies’ online resource pages for developers in  a centralized catalogue on www.Data.gov; and requiring agencies  to use web performance analytics and customer satisfaction measurement tools on all “.gov” websites.”

The order gives pause. Every government agency? Surely the NSA is not scrambling to grant remote public access to its considerable data holdings. Still, the order is plain, and one thing is for sure: www.data.gov is going to have a hell of a year.

The Year Of The API

Beyond this, I noticed that a landmark software patent lawsuit concerning API copyrightability was just lost by Oracle, and by extension, the boardrooms of big business.  I think we can declare 2012 the year of the API.  And in the mainframe world, that means good news for vendors plying the space between CICS and IMS, and more generally, the space between COBOL and Java.

 

 

 

HP Whitepaper: Five Myths About Cloud Computing

Picture of US Rep. Ed Iron Cloud III

State Rep. Ed Iron Cloud III (D-SD). Because his name is completely awesome and relevant to this post.

The Big Iron vs. Cloud Computing fight drags on.

Today, I was sent a new whitepaper from ITWhitepapers.com.  Hewlett-Packard wrote “Five Myths About Cloud Computing”.  I thought it was pretty interesting, as vendor-supplied research goes.

I mean, sure, it’s a whitepaper from a cloud vendor. Because that’s where it comes from, the “sell” part of it is right in there — HP’s Cloud offerings are myriad and this paper is at least as much about spreading awareness of HP’s cloud services as it is about properly contextualizing the cloud for enterprise IT folks.

But instead of the expected across-the-board rah-rah, this paper starts by debunking a common myth about the cloud: its cost is not the lowest. “Myth One: The public cloud is the most inexpensive way to procure IT services”.

There’s a subtle twist to this framing: what HP is doing there is not claiming a cloud approach per se to be more expensive, but rather the “public” cloud — a term that can mean different things in different contexts, but in the context of HP talking to enterprise IT, means competing services like Amazon EC2.  More sell.

And of course, baked within this thinking is a statement that leads directly back to Big Iron the kind of app your’re running should determine your best delivery paradigm:

Here’s a surprising fact: For resources that are needed constantly, enterprises can actually reduce costs by leveraging other cloud models, such as shared resources delivered via a private cloud. In cases like this, the private cloud actually is more cost-efficient than even the pay-as-you-use public cloud model. An analogy is the decision to rent or buy a car. For short-term use, a car rental is cost-effective because you pay based on what you consume. However, if you drive frequently and for a longer term, then owning a vehicle makes better financial sense. And beyond
price, there are other important issues to consider such as performance, security, compliance, service-level agreements, and availability.

Nothing surprising about that to the mainframe community! Performance, compliance, security, availability are our enduring strengths; we don’t fear comparison in any cloud context.

What’s the story in your shop?  Who’s advocating moving critical applications to the cloud, and how goes the discussion?

If you’d like to read the whole HP whitepaper, you can grab a copy here.

Ars Technica: How Mad Men sold computers in the 1960s and 1970s

DEC EAI 640 Ad Image from 1967

The DEC EAI 640: FORTRAN in the sunshine

Over at Ars Technica there’s a timely reflection on the marketing history of mainframes between the Kennedy and Carter administrations.  There’s quite a bit of fun learning about how the classic business marketing techniques of the era worked. The industry produced lots of print ads with art direction portraying a future where data entry clerks lounged and let the hardware do all the work.  Sometimes even outside, such as in the above photo  – presumably because stacks of punch-cards were somehow impervious to 1960s wind and weather?

For the full experience of the DEC EAI640 marketing, take a peek at a PDF of the full EAI640 brochure.

Most of the images in the Ars piece come from the truly awesome Computer History Museum of Mountain View, CA, the one place in Silicon Valley where the technologies and problem-solving of yesteryear aren’t forgotten by reflex.

 

 

BoA: Mainframe Careers Are Too Big To Fail

A bank entryway

Not bunk

The love affair between banks and mainframes, like all love affairs eventually do, needs some freshening up.

The biggest of the TBTF (Too Big To Fail) banks are a major recruiting presence on college campuses, according to CIO Magazine.

This is because the decline in the number of new college grads with any mainframe training has gotten the attention of (a more charitable way of saying “woken up”) execs at large financial institutions, prompting a type of foresight-fueled action for which these behemoth banks have never before been known.

Quite the opposite. In 2008, TBTF banks did everybody in the world the favor of loudly demonstrating that the underlying assumptions of “free market” capitalism were null and void; that the “most successful” of the banking sector were in fact enormous, staggering failures, and that these failures, huge as they were, carried no real consequences for the responsible parties in the corner offices.

In other words, the financial disaster of 2008 was the biggest job security story in business. By extension, plenty of that security extends to mainframe computing.

Underneath (way underneath) these failures were the mainframe shops, the engine rooms of finance. They did no failing whatsoever. High-volume, high-MIPS jobs running hard on big iron, keeping everything afloat, putting the bank’s money where it had to go.  (And putting plenty of other people’s money into the bank, but that’s for another post).

The criticality of these critical applications — call them “apps” and I’ll personally come over to sock you one — are the driver for this campus recruiting effort by banks and by Big Blue and other vendors.  They are simply too critical to pass along to other hardware.

And a decline in trained professionals plus a steady demand for these applications equals high demand, high pay and high job security.

That’s one reason why Kimberly Grim, SVP of Mainframe Engineering at Bank Of America calls mainframe systems “very safe”.  Because especially in the case of BoA, the business itself is very safe from failure. Its critical systems therefore share that safety.

And that’s also why over 600 colleges, universities and high schools around the world are participants in IBM’s Academic Initiative.  The word needs to get out about mainframes as a hedge against an uncertain technology employment world.

-Blue

 

EXEC CICS START BIGIRONWORKS

The 3270 Terminal

Howdy.  I’m Blue.  I’ve been around mainframes — Big Iron — since around the Y2K scare.  Sure, that was overblown, but I tell you, we found some bugs. Nothing that would lose track of a billion dollars of course, but misnamed reports and columns, that kind of stuff.

Now the IT world at large might scoff, but I think we did great work.  Given the monumentally limited attention spans and woeful skill sets of the management people in FIRE — finance, insurance and real estate — aka the people that depended on these reports, we actually were saving the world back then.  These corner-office types are people for whom the slightest distraction could lead to millions in lost time.

I’m not the most grizzled veteran.  Hell, I’m not even grizzled generally, and the last COBOL I wrote was on punch cards in high school in the 80s.  But I do have an abiding respect for the high priests of Big Iron and I’m always learning.  That’s what Big Iron Works is about: learning and sharing mainframe systems knowledge.  And trying to figure out how the world is going to run its banks and governments when we’re no longer around to slap the hands of the clueless away from screwing everything up.

So subscribe to the RSS feed, follow us on Twitter* and let’s get serious about Big Iron. Guerilla mainframe.

- Blue

 

 

*If you’re not already – there are over 3,100 followers of @bigironworks at press time!