Semen Popov,

1. Непонятная версия драйвера JDBC. 3.50.152 - это от v9.5 FP0(GA).
Т.е. ни 8.2, ни 9.7. Проверить, откуда он взялся и заменить.
Желательно вообще пересоздать пул соединений на сервере приложений, задействовав драйвер от текущей версии.
Если WAS и DB2 на одной машине, желательно настроить Type2 соединение.

Отсутствующие пакеты JDBC-драйвера можно дополнить следующим образом:
java -Duser.language=en -classpath db2jcc.jar com.ibm.db2.jcc.DB2Binder -url "jdbc:db2://<IP-сервера>:<порт>/<имя базы>" -user <имя пользователя> -password <пароль пользователя> -action replace

Вторая странность, что понадобился пакет SYSLN303.
По умолчанию (size=3) создаются пакеты SYSLN300, SYSLN301, SYSLN302.
Обычно это означает, что открыто большое количество курсоров одновременно, что бывает при рекурсии, зацикливании или программной ошибке. Можно попробовать выполнить провязку пакетов JDBC указав больший размер (Напр. -size 5), если потребует пакет SYSLN305, то скорее всего это ошибка.

Для WAS7 и выше рекомендую создать новый провайдер, используя провайдер "DB2 Using IBM JCC Driver". Указать в нем (переменные DB2_JCC_DRIVER_PATH и DB2_JCC_DRIVER_NATIVEPATH) пути к драйверу и двоичным библиотекам текущей версии.
Пример: C:\IBM\SQLLIB\java и C:\IBM\SQLLIB\BIN.
Сохранить провайдер и, на основе этого провайдера создать пул соединений, указав в параметрах тип 2 и имя нужной базы.

Semen PopovЕвгений ХабаровОтсутствующие пакеты JDBC-драйвера можно дополнить следующим образом:
java -Duser.language=en -classpath db2jcc.jar com.ibm.db2.jcc.DB2Binder -url "jdbc:db2://<IP-сервера>:<порт>/<имя базы>" -user <имя пользователя> -password <пароль пользователя> -action replace


Попробовал выполнить и получил результат:


Архив db2jcc.jar должен быть доступен в каталоге, из которого запускается команда, или же нужно указать полный путь к db2jcc.jar в опции -classpath

Semen PopovSemen Popov...
Почему использовался старый драйвер (из AppServer\lib\ext), когда были заданы конкретные пути - не знаю. Теперь вроде используется новый.
...

Кажется я догадываюсь, почему драйвер использовался из AppServer\lib\ext. Провайдер и источники данных созданы в области "Узел, Сервер", а переменные проинициализированы в области "Узел". Получается, что переменные не были видны. Я правильно понимаю, что и переменные надо было инициализировать в области "Узел, Сервер"?
lib\ext является более приоритетным (идет в classpath раньше), нежели пути, указанные в настройках провайдера. Это кроме случая, когда провайдер создается с собственным(изолированным) Classloader-ом.

Semen PopovЕвгений ХабаровАрхив db2jcc.jar должен быть доступен в каталоге, из которого запускается команда, или же нужно указать полный путь к db2jcc.jar в опции -classpath
Выдало для 49 пакетов:


Но SYSLN303 среди них не оказалось. Это нормально?
Да, это нормально.
Цитирую собственный абзац.
Евгений ХабаровПо умолчанию (size=3) создаются пакеты SYSLN300, SYSLN301, SYSLN302.
Обычно это означает, что открыто большое количество курсоров одновременно, что бывает при рекурсии, зацикливании или программной ошибке.
Можно попробовать выполнить провязку пакетов JDBC, указав больший размер (Напр. -size 5), если потребует пакет SYSLN305, то скорее всего это ошибка.
Т.е. если выполнить Binder с доп. ключем -size 5, то будут пакеты SYSLN300-SYSLN304.
java -Duser.language=en -classpath db2jcc.jar com.ibm.db2.jcc.DB2Binder -url "jdbc:db2://<IP-сервера>:<порт>/<имя базы>" -user <имя пользователя> -password <пароль пользователя> -size 5

Semen PopovЕвгений Хабаровпропущено...

lib\ext является более приоритетным (идет в classpath раньше), нежели пути, указанные в настройках провайдера. Это кроме случая, когда провайдер создается с собственным(изолированным) Classloader-ом.
Спасибо. А не могли бы тогда пояснить, в чем отличие создания провайдера, источника данных, переменных WebSphere в различных областях? Я тут посмотрел у себя, как настроены различные приложения, и увидел, что провайдеры, источники, переменные настроены по-разному - в различных областях. Что следует учитывать, выбирая ту или иную область, создавая объекты в WebSphere?
Уровень, на котором определен ресурс или переменная имеет большое значение в конфигурации ND.
Он определяет "область видимости" переменной или ресурса.
При совпадении названий более "гранулярное" определение будет перекрывать более общее. Т.е. определение переменной или ресурса с одинаковым именем, заданное на уровне сервера(server), перекроет определение, заданное на уровне узла (node) или ячейки (cell).

В конфигурации ND ресурс и пути к классам описываются на уровне ячейки или кластера (если ресурс должен быть общедоступным).
Но, если на конкретном узле(сервере) пути будут другими, то для такого узла переменная "переопределяется" на уровне узла.
Т.е. имеем описание ресурса в единственном экземпляре, но можем "подменить" параметры, заданные переменными, для конкретного узла или сервера.

Для Standalone сервера уровень определения ресурса/переменной является менее критичным, но желательно ресурсы задавать на одном уровне, дабы не плодить сущности. В своих Stadalone конфигурациях обычно использую уровень узла, но не могу утверждать, что это является best practices.

Подробнее описано по ссылкам:
WebSphere variables
Administrative console scope settings