LUW DB2 For Test With DB2 on IBM Mainframe For Production

Question

Is it possible, or has anyone, created a process by which they use an LUW instance of DB2 for their test data, native, and cobol procedures, while actually using a mainframe version of DB2 to run their production software? And probably another good question to ask is, would this even be a smart thing to do?

To give some background for why I ask this question, our company is currently neck deep in our IBM mainframe to run our production system. The way we then host our test data is also within our production mainframe, on a separate logical partition (or LPAR). The problem with this comes from the fact that there are frequent times where our production load becomes so high that our development LPAR becomes starved of resources, and using mainframe DB2 to retrieve our data can be prohibitively slow.

Now some seemingly obvious solutions for our test system troubles would be to spend resources on making the mainframe faster, or even to have a dedicated test mainframe (which clearly doesn't have to be as powerful). The problem though with those likely easier to implement solutions, as everyone who's worked with IBM knows, is that the costs involved are extremely substantial. Even more prohibitive than than dealing with a slow test system (at least according to the powers that be in our organization, I do not have the first hand knowledge).

So, that lead me to the questions raised in my opening paragraph. Are there even ways to manage an LUW instance of DB2 data, native procedures, and COBOL procedures, while ultimately running production DB2 on a mainframe? Has anyone else even tired to do this? I feel like there are alot of potential issues, such as getting COBOL procedure updates to the LUW instance when developers in our other departments update those procedures, so maybe this isn't even a smart thing to do.

Answer 1

I don't think this is feasible, particularly because of the differences in SQL dialects on these two platforms -- they are small, but they do exist. And you won't be able to transfer procedures, whether SQL or COBOL, between the two -- you will have to rebuild them from sources, again, subject to the language differences.

Even if you manage to make this work, however, your test environment won't reflect the target, so whatever you're testing won't necessarily be valid in production.

Answer 2

While there are significant differences between the three editions of DB2, the basics are generally pretty similar. Granted, it would be nice if UDB actually meant that the features were Universal across DB2, and there are many cool features that each of them have that the others don't. Yet the basics are there.

See The SQL Reference for Cross-Platform Development and Selected common SQL features for developers of portable DB2 applications

COBOL programs should be able to connect via DRDA to any DB2 server, but perhaps I am being naive. When I was in a large Fortune 500 enterprise environment, we did not connect directly between different systems, but sent transactions via MQ Series.