До начала использования CTMS user-exit type 3, которые стали обнавлять соответствующие записи в DB2 таблицах, загрузка данных в CTMS таблицы через задание не представляла собой проблему. Подготорил файлик, запустил задание и все - таблица настроена.
Но время не стоит на месте и в целях повышения производительности было принято решение создавать DB2 таблицы для часnоиспользуемых CTMS таблиц и в программах осуществлять доступ именно к DB2. CТMSный фронтэнд использовать только как средство для настройки, а обновление данных возложить на CTMS user-exit (третий тип - это тот самый, который вызывается уже после обновления/удаления/втсавки записи в CTMS).
После этих изменений, задание, которое раньше замечательно использовалось для загрузки данных начало валиться с user abend 3042. Описание было бестолковых и мы уже начали подумывать о том, что такой способ загрузке в принципе нельзя использовать.
Но ведь нерешаемых проблем не существует, не так ли? Проведя некоторое количество экспериментов проблему получилось побороть =)
Для начала был создан план RWF600 (по имени стандартной ECMVS программы, которая осуществляет загрузку данных), в который были включены DB2 packages для DB2'шных CTMS'ных user-exits. Сделали BIND плану и перешли к модификации задания загрузки CTMS.
Были подключилы стандартные объявления DB2 подсистемы, а в шаг запуска RWF600 к имебщимся путям STEPLIB были добавлены DB2 пути:
// INCLUDE MEMBER=&DSNLOAD
Тот же include был сделан и в секции объявления DD DFSESL.
Думаете помогло? Отнюдь =) Задание продолжало валиться =) Последним шагом, который помог решить проблему стало изменение параметров вызова RWF600:
//STEP010 EXEC PGM=DFSRRC00, // REGION=2048K, // PARM=(BMP,RWF600,RWF600P,,,С00100,,,,,,,,IMSID,,)
RWF600P - используемое PSB.
IMSID - идентификатор IMS подсистемы.
С таким набором параметров задание успешно отработало, чем в последствии значительно облегчило жизнь =)
Отправить комментарий