Mikhail.Gurusov,

Эээ... А не хотите в поддержку обратиться? Поддержка скажет, какую информацию и как собрать.
Вообще, отработанность механизмов обращения в поддержку вендора - одина из важнейших вещей при обеспечении надёжности системы. "Поломаться" может всё, вопрос - как быстро можно обратиться к "починятелям". В некоторых случаях только вендор/команда разработки продукта вообще способны что-либо сделать.
Возможно, как раз ваш случай.


Тем не менее:
Как я понимаю, проблема невоспроизводима (не можете создать стенд/условия, при которых ошибка гарантированно возникнет). В этой ситуации обращаться к разработчикам/тестерам (короче, наблюдателям возникновения той ошибки) несколько бессмысленно.

Разве что запросить точное время возникновения ошибки и силами же админов восстановить данные ровно на тот момент и запустить запрос ещё раз.
Мороки много, результат не гарантирован (может, например, быть связан с наличием определённых параллельных запросов или состояния движка СУБД, что для system i считай самой операционки), но если удастся поймать проблему за хвост, считайте 90% дела сделано.

В то же время, если это SQL System Error (не могли бы Вы, кстати, привести более точное описание - код ошибки, полный текст, известно ли на каком конкретно SQL statement'е возникает?), то админы должны бы видеть что-то и у себя в логах...
BTW Оно может оказаться каким-нибудь банально прибитым коннектом по факту возникновения deadlock'а или чем-нибудь подобным, что есть вполне штатно, легитимно и относится скорее к ошибке дизайна приложения.
Имеют клиенты в подобных ситуациях свойство кричать страшным криком, что сервер у нас чуть не загнулся и аж не может больше принимать коннекты.

Вышеперечисленное - из общих соображений. В надежде на то, что основные принципы на System i в таких случаях не сильно отличаются от UDB/for LUW или чего-либо другого.

Mikhail.Gurusovспасибо за советы, вся прелесть System i в том, что это совершенно другая ветка разработки СУБД DB2, там только название общее, и, скорее всего, алгоритмы, но движки - совершенно разные.
Да, я в курсе.
С System i приходилось работать лишь опосредованно (в связке с LUW). Был, кстати, PMR - висли приложения, бегущие на sistem i, при обрыве DRDA коннектов со стороны LUW сервера (вот были у нас такикие странные приложения, напрямую работающие с AS/400 с базой под Win :O). Слава богу аналогичная картина воспроизвелась с Win клиентов, т.е. удалось свести тест кейз к одному продукту и платформе, что очень помогло при общении с саппортом.

Однако не могу не отметить, что не смотря на внутреннее разное устройство движков, IBM много делает для унификации как самого SQL, так и _диагностики_. Т.е. тот же SQL901N чётко говорит - да, системная ошибка, а не сообщение от бизнес-логики процедуры, в котором разработчику вдруг придумалось назвать ошибку "системной".
В первом случае либо самим (админам) глубоко лезть в логи и изучать детали, либо в поддержку.
Во втором - вопрос только к разработчикам процедуры.