LUW DB2 для тестирования с DB2 на IBM Mainframe для производства
Возможно ли, или кто-нибудь создал процесс, с помощью которого они используют экземпляр LUW DB2 для своих тестовых данных, собственных и cobol процедур, в то время как на самом деле используют версию мэйнфрейма DB2 для запуска своего рабочего программного обеспечения? И, вероятно, еще один хороший вопрос, который нужно задать, будет ли это вообще разумно?
Чтобы дать некоторое представление о том, почему я задаю этот вопрос, наша компания в настоящее время по шею погружена в наш мэйнфрейм IBM для запуска нашей производственной системы. То, как мы затем проводим наш тест данные также находятся в нашем производственном мейнфрейме, на отдельном логическом разделе (или LPAR). Проблема с этим возникает из-за того, что часто бывает так, что наша производственная нагрузка становится настолько высокой, что наша разработка LPAR испытывает нехватку ресурсов, и использование мэйнфрейма DB2 для извлечения наших данных может быть непомерно медленным.
Теперь некоторые, казалось бы, очевидные решения для наших проблем тестовой системы состояли бы в том, чтобы тратить ресурсы на то, чтобы сделать мэйнфрейм быстрее, или даже иметь выделенный протестируйте мэйнфрейм (который явно не должен быть таким мощным). Проблема, хотя с теми, которые, вероятно, легче реализовать решения, как знает каждый, кто работал с IBM, заключается в том, что связанные с этим затраты чрезвычайно существенны. Даже более запретительный, чем работа с медленной тестовой системой (по крайней мере, по мнению сильных мира сего в нашей организации, я не обладаю знаниями из первых рук).
Итак, это подводит меня к вопросам, поднятым в моем первом абзаце. Есть ли вообще способы, чтобы управлять экземпляром LUW данных DB2, нативными процедурами и процедурами COBOL, в то время как в конечном счете запустить рабочую DB2 на мэйнфрейме? Кто-нибудь еще устал это делать? Я чувствую, что есть много потенциальных проблем, таких как получение обновлений процедуры COBOL для экземпляра LUW, когда разработчики в других наших отделах обновляют эти процедуры, так что, возможно, это даже не умная вещь.
2 ответа:
Я не думаю, что это возможно, особенно из-за различий в диалектах SQL на этих двух платформах-они небольшие, но они существуют. И вы не сможете переносить процедуры, будь то SQL или COBOL, между ними-вам придется перестраивать их из исходных текстов, опять же, с учетом языковых различий.
Даже если вам удастся сделать это, однако, вашатестовая среда не будет отражать цель, поэтому то, что вы тестируете, не обязательно будет действителен в производстве.
Хотя существуют значительные различия между тремя выпусками DB2, основы в целом довольно схожи. Конечно, было бы неплохо, если бы UDB на самом деле означал, что функции были универсальными в DB2, и есть много интересных функций, которые у каждого из них есть, но у других нет.
См. Справочник по SQL для кросс-платформенной разработки и избранные общие функции SQL для разработчиков портативных приложений DB2
Коболь программы должны быть способны подключаться через DRDA к любому серверу DB2, но, возможно, я наивен. Когда я был в большой корпоративной среде Fortune 500, мы не подключались напрямую между различными системами,а отправляли транзакции через серию MQ.