Look at the mainframe correctly-it's a key part of the business

Have you ever heard such a statement? An IT senior manager talking about the application infrastructure of the organization. He is optimistic about the "modern" aspects of the Environment: multi-tier client-server systems, WEB-oriented development using languages such as PERL, Python, and Ruby, and service-oriented architectures.

If you ask the IT senior manager about the IBM System z Server They are using, the answer may well be dismissive: "Oh, that's our legacy system." The word "left" sounds like a bit of shame.

I've been working on mainframe systems for 30 years, and my response to such comments is often this (but silently in my heart): "Legacy systems, what do you mean?" Is it the system that runs the application that keeps the factory running, keeps the wagons on track, and maintains the flow of customer bills? Aren't these apps the apps that bring you profit and keep your business alive? Do you think this is a legacy system? ”

But I won't argue with them, usually I'll just say: "Speaking of your System Z server, it's important to note that the DB2 on this platform are excellent data providers for modern, multi-tiered, service-oriented applications, and you're very concerned about these applications, aren't you?" If this doesn't convince you, go and see what your own development team is doing recently. ”

This is a somewhat ironic situation. Programmers in this organization may tell DB2 for z/OS database administrators that they do not want to use mainframes at all, but these programmers are perfectly receptive to writing JDBC calling code in Java programs, and the goal of JDBC invocation is mainframe DB2 databases.

Is this a paradox? But I don't think that's the case. I believe that when developers say they don't want to use a mainframe, the real intention is not to dislike the platform, but to dislike the green screen and the 3270 interface. If developers are able to use interfaces that are freely available, such as JDBC, ODBC, or ADO. NET) retrieves data from a relational database (or persists the data to a relational database), they are not concerned about whether the target data delivery system is DB2 for z/OS. For developers, the platform is just a channel. What they really care about is getting the data needed for the program in a familiar way. Are these data stored on mainframes? No problem.

Similarly, how do we explain how the mainframe DB2 workloads in their organizations are still growing at a steady pace when it executives mention their desire to get out of the mainframe platform? Is IT department staff ignoring the boss's opinion? The answer is, of course, negative. I think the real desire of such it executives is to get rid of legacy application architectures, which are often marked by mainframes since they originated 20-30 of years ago. The mainframe was the only viable option (at least in many people's minds) for a truly large-scale, mission-critical application. This architecture is inherently monolithic, with no physical separation between the user interface, business, and data access logic, and there is virtually no logical separation, which makes efficient use of CPU resources, but is extremely flexible. Today's businesses need agility. Agile, scalable application architectures are critical to organizations. In this chaotic situation, it is often impossible to realize that, according to the needs of the organization, mainframes and DB2 are extremely suitable for such architectures, and may even be "a perfect match".

Don't take care of the conversation. What is the actual situation?

Some mainframe professionals think they are about to be eliminated and are helpless to wait for the big guys to junkyard. Interestingly, some of them did not even realize what was happening in front of them.

I usually do something like this in the DB2 for z/OS site: Get the DB2 monitor calculation Detail report for the busiest hour of the day. The data in such reports can be grouped by connection type to facilitate viewing activities such as CICS-DB2 workloads, mass DB2 workloads, and DRDA (i.e. client-server) workloads. Most DB2 monitor products produce such reports.

Gets the average of the CPU time (that is, "2" CPU time) that is used in the DB2 each time the transaction is processed. This results in a per-calculation trace, which is typically the per-transaction time of the CICS and DRDA workload, and the time of the batch workload. Multiplies the results by the number of reports. The product is the total CPU cost of the SQL statement for this part of the entire DB2 workload.

Guess what? Client-server activity is often the fastest growing component of the entire mainframe DB2 workload and, in some cases, even the highest proportion of workloads, both over cics-db2 and in batches of DB2. People who actually manage DB2 for z/OS systems may not be aware of this. Are they absent-minded at work? Of course not. The reason is simply that they are too focused on the individual workload elements: they want to help Java developers access the DB2 data here, support the. NET application server to access the DB2, handle PHP DB2 drivers, and so on, so they cannot grasp the overall picture from a macro perspective; in other words, they don't notice DB2 For z/OS has become the preferred data server for all types of "modern" applications.

If programmers don't think of themselves as mainframe professionals, why do they use mainframes in their own code? First, as I mentioned earlier, there are almost DB2 drivers for any language that developers want to use. The IBM Data Server Driver Package is the most convenient way to get these drivers. Second, the developer is guided by the location where the data resides. The organization's large number of data assets are often located in mainframes (typically managed by DB2). If there is an open interface for this class of data in the mainframe (which is true in most cases), why not migrate the data to another system? Why can't I access data directly from the original location? In the area of business intelligence and data warehousing, the trend of accessing data originating from mainframes on mainframes has become mainstream, and in order to perform data analysis using DB2 for z/OS, businesses are increasingly avoiding migrating data from mainframes to other platforms that people think are more BI-friendly.

There are also certain types of IT managers who require development work on DB2 for z/OS (usually a variety of "modern" development efforts). The reason is not just that the data is often in the mainframe, but that the mainframe is the safest, most scalable, and most available data delivery platform for the organization.

What's the cost? Before giving DB2 on System z a "most expensive" hat on the basis of hearsay theory, first take a closer look. How much floor space does your mainframe (which may be used to run large workloads) occupy, compared to how much floor space does the other platforms used in your environment occupy? How about energy consumption? How many support staff do you need? With some simple comparative analysis, you realize that System Z actually delivers considerable value to your organization in a very cost-effective way.

Update your DB2 knowledge

I want to add a simple postscript to the story. At some sites, some IT staff believe that mainframe DB2 distributed databases handle the actual environment originating from the the 1990s, and therefore deny using DB2 for z/OS for client-server applications. Do you think all content from DDF (DB2 distributed data tools) runs at the same priority level? Absolutely not. As early as many years ago, the actual situation is no longer the case.

Do you think that all of the SQL executed in the client-server context is dynamic? This knowledge is also outdated. For example, you can package static SQL statements on a DB2 server as a stored procedure in order to (of course, in an open manner) invoke it from a client connected to the network. Do you think the security in the DB2 client-server environment is too lax? Take a look at features such as the roles and trusted contexts that DB2 9 delivers, and use these features to enhance data access control if SQL comes from an application server outside of the mainframe. Conclusion: The more you know about the current status of DB2 for z/OS, the more you want to base it on your multi-tier applications.

Next time, if you hear any more about a "legacy system" hat on a large nose, delve into the specifics. First, mainframes and DB2 are the main servers in your organization. Second, see the facts. The so-called legacy system may be the best client-server database platform in your enterprise. Your developers or other staff members may well be aware of these facts. You should listen to their opinions. You will have no other loss than to buy them a cup of coffee.