Blogs

Hey, What Are You Calling a “Legacy System”?

Put the mainframe into perspective—it’s a vital part of businesses

Have you ever heard something like this? An IT executive is talking about his organization’s application infrastructure. He enthusiastically describes the “modern” aspects of the environment: the multitiered, client-server systems; the web-oriented development using languages such as PERL, Python, and Ruby; and the service-oriented architecture.

If you ask the IT executive about the IBM System z servers also in use, the response might be a dismissive, “Oh, that’s our legacy system,” with “legacy” sounding like an apologetic term.

I’ve worked with mainframe systems for 30 years, and my gut reaction to such a comment—only voiced internally, of course—might be, “Legacy system, you say? Would that be the system that runs the applications that keep your factories humming, your trucks rolling, and your customer invoices flowing? You know, the applications that make you money and keep your business alive? You mean that legacy system?”

Rather than pick a fight, though, I’d actually say something like this: “Speaking of that System z server of yours, you must be aware that DB2 on that platform is a great data provider for those modern, multitiered, service-oriented applications on which you’re focused, right? If you’re not convinced of that, see what your own development teams are up to these days.”

And that’s the irony of the situation. The programmers at this organization might tell a DB2 for z/OS DBA that they don’t want to have anything to do with a mainframe, while those same programmers are fine with coding a JDBC call in a Java program that targets a mainframe DB2 database.

Are these people speaking out of both sides of their mouths? I don’t think so. I believe that when a developer says that he doesn’t want to deal with a mainframe, what he’s expressing is not a dislike of the platform but rather a disinclination to deal with things like green screens and the 3270 interface. If that developer can use an interface that’s natural for him—such as JDBC, ODBC, or ADO.NET—to retrieve data from (or persist data to) a relational database, why should he care whether the target data-serving system is DB2 for z/OS? To him, the platform is just plumbing. All he really cares about is getting the data his program needs in a way that’s familiar to him. Is that data on a mainframe? Okay, fine.

Similarly, when an IT executive indicates that she’d like to move away from the mainframe platform, what are we to make of that when the mainframe DB2 workload in her shop is not just stable, but growing? Are people in the IT department ignoring the boss? No. I think that what the IT executive really wants is to move away from an old-style application architecture that is sometimes identified with mainframes because it dates from 20 to 30 years ago—a time when mainframes were almost the only viable choice (in the minds of many) for really large-scale, mission-critical applications. That architecture—monolithic in nature, with no physical separation and barely any logical separation between user interface, business, and data access logic—was very CPU-efficient but quite inflexible. Agility is what businesses need these days. An agile, extensible application architecture is seen as critical for organizations. What sometimes gets lost in the shuffle is the realization that mainframes and DB2 are a great fit for this type of architecture—maybe even the best fit, depending on the organization’s needs.

Never mind the talk. What’s actually going on?

And so it is that some mainframe people feel that they are just playing out the string, waiting for the day when the Big Iron gets unplugged and carted out to the loading dock. The funny thing is, some of these folks don’t even realize the extent to which a sea change is underway, right under their noses.

Here’s something I like to do when I’m at a DB2 for z/OS site: get a DB2 monitor accounting detail report for a busy one- or two-hour period of the day. The data in the report should be grouped by connection type so you can see activity for the CICS-DB2 workload, the batch-DB2 workload, the DRDA (that is, client-server) workload, and so on. Most DB2 monitor products can produce such a report.

Take the average in-DB2 CPU time (aka “class 2” CPU time) per occurrence. That would be per accounting trace record—usually, per transaction for CICS and DRDA workloads, and per job for a batch workload. Multiply that by the number of occurrences reported. The product is the total CPU cost of SQL statement execution for that component of the overall DB2 workload.

Guess what? It’s quite often the case that client-server activity represents the fastest-growing component of the overall mainframe DB2 workload, and in some cases it’s already the largest workload component—bigger than CICS-DB2, bigger than batch-DB2. Yet the people who actually administer the DB2 for z/OS system may not be aware of this. Are they asleep at the wheel? Hardly. It’s just that they’ve been so focused on individual workload elements—helping a Java developer access DB2 data here, enabling .NET application server access to DB2 there, working with the PHP DB2 driver—that they haven’t seen what’s happening in the big-picture sense; namely, that DB2 for z/OS is becoming the data server of choice for all kinds of “modern” applications.

And why are programmers voting with their code, even if they don’t at all see themselves as mainframe people? First, as I’ve alluded to previously, there is a DB2 driver for just about any language a developer wants to use. These are most conveniently available via the IBM Data Server Driver Package. Second, the developers are going where the data is. Quite commonly, the bulk of an organization’s data assets are mainframe-based (and often managed by DB2). If open interfaces to that data on the mainframe exist—and they most certainly do—then why move the data to some other system? Why not just access it where it lives? This trend of accessing mainframe-sourced data on the mainframe is playing out in spades in the area of business intelligence and data warehousing, as companies increasingly eschew moving mainframe-based data to some supposedly BI-friendly platform in favor of doing data analytics with DB2 for z/OS.

Then there are the IT management types who are directing development efforts (usually of the “modern” variety) to DB2 for z/OS. They do this not just because the data is often there, but because the mainframe is seen as the organization’s most secure, most scalable, and most highly available data-serving platform.

And cost? Before you assign the “most expensive” label to DB2 on System z based on something you heard from somebody, take a closer look. How much floor space does your mainframe take—in running what is probably a large workload—versus other platforms used in your environment? How much energy does it consume? What’s the size of the support staff? Do a little comparative analysis, and you might see that System z is, in fact, delivering major value to your organization in a very cost-effective way.

Get current on your DB2 knowledge

Here’s a little epilogue to this story. At some sites, the tide of DB2 for z/OS usage for client-server applications is being held back by some IT people whose thinking about mainframe DB2 distributed database processing is rooted in 1990s reality. Do you think everything coming through DDF (the DB2 distributed data facility) runs at the same priority? No way. It’s been years since that was true.

Do you think that all SQL executed in a client-server context is dynamic? That thinking is also way out of date. Among other things, you can package static SQL statements on the DB2 server side in the form of stored procedures that can be invoked (in an open fashion, to be sure) from network-attached clients. Do you think that security is too loosey-goosey in a DB2 client-server environment? Read up on roles and trusted contexts—features delivered in DB2 9 that can be used to majorly tighten up data access control when SQL is coming in from off-mainframe application servers. Bottom line: the more you know about DB2 for z/OS as it exists now, the more you’ll like it as the data foundation for your multitier applications.

So the next time you hear the term “legacy system” applied to the mainframe, dig a little deeper. First, give the mainframe and DB2 props for functioning as your organization’s server workhorse in that role. Second, open your eyes. That so-called legacy system may be the best client-server database platform in your enterprise. Chances are, you have people—developers and others—who’ve already figured that out. Find out what they know. It might not cost you more than a cup of coffee.

[followbutton username='IBMdatamag' count='false' lang='en' theme='light']