Валян,

1. Выполняется ли этот запрос без ошибок из командной строки db2 ?
2. PF.MAN - это таблица или VIEW ? DDL этого объекта можете опубликовать?
3. Есть мысли что такое T0.DATNPP и откуда оно появилось ?
4. Изменится ли ошибка, если убрать сортировку (ORDER BY M.FA, M.IM)
5. Изменится ли ошибка, если запрос записать так:
SELECT * FROM PF.MAN WHERE FA LIKE 'ИВАНОВ%' ORDER BY FA, IM
6. Как выглядит блок кода, который выполняет запрос? Соединение с базой через пул соединений WAS?
7. Будет ли такая же ошибка при выполнении запросов из Standalone-приложения.
Пример Standalone-программы есть здесь: Проблема соединения с удаленными базами

Сбор доп. диагностики:
8. Версия и фикс сервера DB2 (команда db2level)
9. Версия и фикс WebSphere Application Server (команда versionInfo)
10. Версия драйвера для доступа к db2?

Валян,

Судя по логу используется некий Kodo JDO, это явно посредник. С таким не работал.
Проблема может быть связана еще и с ним.

Нужно смотреть где и как настраиваются параметры соединения с СУБД внутри WebSphere AS + Kodo JDO и к свойствам соединения дописывать параметры для формирования трассы драйвером DB2, аналогично тому, как это сделано в TestCon.
После этого нужно будет перезапустить WebSphere AS (для чистоты эксперимента) и выполнить запрос, дающий ошибку.
Должен сформироваться файл трассы, в котором будет фиксироваться конечный SQL-оператор, который получил драйвер для исполнения, и результаты его выполнения. Возможно ситуация прояснится.
Дальше, рекомендую написать простейший сервлет, который будет обращаться к СУБД и выполнять этот запрос в "чистом виде" без посредников (Kodo и т.п.). Если запрос будет выполняться без ошибок, то проблема в посреднике.

PS: Я очень надеюсь, что для работы с СУБД используется пул соединений сервера приложений, как и положено.

Валян,

Тогда основное подозрение на Kodo JDO.
Там нужно проверять:
1. Что он обращается к пулу соединений WAS, а не пытается открывать соединения самостоятельно.
2. После выполнения п.1, включить трассировку на пуле соединений, перезагрузить WAS, выполнить запрос, получить ошибку и после этого смотреть в файл трассы. Скорее всего посредник формирует неправильный SQL-оператор. В любом случае в трассе JDBC-драйвера DB2 будет более очевидно что именно дает ошибку.
3. По факту анализа или менять настройки/код, или обновлять библиотеку Kodo, если окажется что это баг. Ну или выбирать другого JDO-посредника.

PS: Касательно фикспаков.
На WAS фикспак нужно ставить 100%, т.к. у вас версия 7.0.0.0, т.е. базовый релиз.
На сегодняшний момент актуальный фикс: Fix Pack 19 (7.0.0.19) : Fix list for IBM WebSphere Application Server V7.0

Сервер DB2 у Вас версии 8.1.18, т.е. база имеет последний актуальный фикспак. Но т.к. поддержка 8-ки прекращена, то нужно думать о миграции в версию 9.x.

Валян,

С какого места непонятно?
Что такое пул соединений на сервере приложений и как к нему обращаться - есть в документации.
Понятие пула - это J2EE Reference, процесс его настройки (Provider+DataSource) и привязки приложения (binding) - документация по администрированию WAS.
Настройка Kodo JDO - должна быть описана где-то в нем самом. Я с ним не работал, поэтому этот момент подробнее расписать не могу.

Включение трассировки для драйвера DB2 включается параметрами в пуле соединений.
Требуется выставить свойства (они там есть в списке Custom Properties):
traceFile=<полный путь к файлу>
traceFileAppend=true
traceLevel=58295

Документация:
Configuring a JDBC provider and data source
Configuring a JDBC provider using the administrative console
Configuring a data source using the administrative console

Можно попробовать настроить трассировку так, как описано в документе по первой ссылке: WAS DocumentationTip: The JDBC trace log exists only if the JDBC trace service is active during server start up. Activate the service in the administrative console. For more information, see Enabling trace at server startup. Specify WAS.database as the trace group and select com.ibm.ws.db2.logwriter as the trace string.