是否有可能或有人创建了一个流程，通过该流程，他们将DB2的LUW实例用于测试数据、本机和cobol过程，同时实际使用DB2的大型机版本来运行生产软件？也许另一个好问题是，这样做是否明智？
为了说明我为什么要问这个问题，我们公司目前在IBM大型机上运行我们的生产系统。然后，我们托管测试数据的方式也是在生产大型机中，在一个单独的逻辑分区（或LPAR）上。这方面的问题来自于这样一个事实，即我们的生产负载经常变得如此之高，以至于我们的开发LPAR资源匮乏，而使用大型机DB2检索数据的速度可能慢得令人望而却步。
现在，对于我们的测试系统问题，一些看似显而易见的解决方案是花费资源使大型机更快，甚至拥有一个专用的测试大型机（显然不必那么强大）。然而，正如所有与IBM合作过的人都知道的那样，那些可能更容易实现的解决方案的问题是，所涉及的成本极其巨大。甚至比处理一个缓慢的测试系统更令人望而却步（至少根据我们组织的权力，我没有第一手的知识）。
因此，这就引出了我在开头一段中提出的问题。在最终在大型机上运行生产DB2的同时，是否有管理DB2数据、本机过程和COBOL过程的LUW实例的方法？还有人累了吗？我觉得有很多潜在的问题，比如当我们其他部门的开发人员更新这些过程时，让COBOL过程更新到LUW实例，所以这可能不是一件明智的事情。
我认为这是不可行的，特别是因为这两个平台上SQL方言的差异——它们很小，但确实存在。而且，您将无法在两者之间传输过程，无论是SQL还是COBOL——您将不得不根据语言差异从源代码重新构建它们。
然而，即使您成功地实现了这一点，您的测试环境也不会反映目标，因此您正在测试的任何内容在生产中都不一定有效。
虽然DB2的三个版本之间存在显著差异，但基本功能通常非常相似。当然，如果UDB真的意味着这些特性在DB2中是通用的，并且每个特性都有许多其他特性没有的很酷的特性，那就太好了。然而，基础是存在的。
请参阅跨平台开发的SQL参考，以及为可移植DB2应用程序的开发人员选择的常见SQL特性
COBOL程序应该能够通过DRDA连接到任何DB2服务器，但也许我太天真了。当我在财富500强的大型企业环境中时，我们没有在不同的系统之间直接连接，而是通过MQ系列发送事务。