As mainframe guys, we know that one of the key strengths of the System z platform with the z/OS operating system is that it is designed to run to 100% utilization. Managing jobs, tasks, and transactions, he assigns workload to resources based upon priorities. Now, that means you need a discrete name for each kind of workload. Without a name, there is no ‘handle’ for Workload manager to associate things like service levels and priorities and velocities so that he can figure out whether that piece of workload deserves whatever amount resource and computing capability. There is also a long-established technique on the mainframe that involves compiling programs so everything gets resolved including the database access component -- where SQL statements get converted into access paths using the right indexes, getting to the right databases, etc. This process gets done ahead of time to make actual runtime execution more effective. Okay, that is not too exciting and most of you probably are well aware of what it means for program to get compiled ahead of execution time rather than being interpreted dynamically at runtime.
Now let’s turn to the distributed world where one of the paradigms is interpretive rather than precompiled and where (surprise, surprise) many of the technicians supporting the environment did not spend the last few decades of their lives working with the mainframe. It turns out that if you don’t know how to specifically classify your workload flowing to DB2, that all the distributed workload, (whether it is Java or.Net) gets put in to a bucket which automatically defaults to a low priority and low allocation of resources and service. If enough care is not paid to differentiate the incoming workload and provide it with the ‘handle’ we talked about above, all of the subsystems of the mainframe, (including your DB2 database, workload manager, security, monitoring and reporting components) can’t give your application the attention it deserves. Also, while there have been some techniques to accomplish it, being able to associate or buying static packages to distributed application programs is something that has not been done very much; due both to awareness and the perceived heavy lifting associated with those techniques (see SQLJ).
While there have been ways to do both of these techniques, distributed and glasshouse folks do not always talk as much as they should, and the techniques were not always particularly easy, with a low threshold level, or were just considered ‘heavy lifting’. A good example of this was something called SQLJ which, while it enables the use of static SQL, has had very low adoption rates. Now, with the advent of pureQuery (which is been out about a year) distributed workload can take advantage of the concept of static packages (that precompiled effect) and ,as a part of the larger data studio suite, pureQuery delivers techniques to the distributed technicians to more easily classify their workload as it shows up to DB2 on the mainframe.
If you do utilize these two techniques, not only is this distributed workload finally eligible for workload manager to give him whatever level of service he needs, but that workload can benefit from the efficiencies of static packages on the mainframe (since the programs now have an easier way to bind them to his deployed programs).
Okay, so now we have a ticket to the party and can use a lot of the same mechanisms that COBOL programs or batch jobs have historically used to get their fair share of resources. One of the key things in this means is that distributed workload can integrate better with the mainframe. It can more effectively use the data on the enterprise data hub. The kinds of response times available to these distributed applications from the mainframe can be far more predictable with better performance. There is even a security benefit, since using these static packages means that users are authorized at the package level and there is not a potential exposure of direct database access.
If you are an architect or an IT manager, this also has large implications for designing applications across your whole infrastructure; including applications that work with other enterprises and partners. Do you have applications that need to go to other locations? Or that would like to become real time, federating data from multiple sources, integrated into business process management flows, and relying on applications and information across platforms and networks? Are you starting to look at master data management, greater infrastructure integration with endpoint devices, or folding in new groups of users that just happened to reside on different networks, platforms are infrastructures? Having a way for your workload to integrate better with enterprise resources, level the playing field for use of resources, and achieve better performance and predictability can be a huge step in an end to and systems design.
Oh, and by the way, it should be no surprise that there are also new opportunites for zIIP engine usage.