Hans Christian Andersen,
можно уточнить предварительно в какой кодировке вы привыкли работать?
- кодировка входного файла
- NLS проекта DataStage
- NLS базы конечной

Да уж...

Ладно, давайте в общем, чтобы прочитать поле файла с данными, записанными в какой-то кодировке, нужно чтобы Sequential File работал в этой кодировке с данным полем (настройка может наследоваться от проекта, переписываться настройками задания, переписываться настройками элемента, переписыватья настройками отдельного поля).

Предположим, у вас файл в 1251.
Всё остальное по настройкам к работе с русским не очень располагает, потому можно так:

- в настройках Sequential File для NLS ставите windows-1251 для данного примера.
- текстовые поля с русским отмечаете, как Unicode (эта опция задействует NLS-преобразования)
при этом если у вас размерность поля три СИМВОЛА, то varchar(3) Unicode корректно их прочтёт и дальше - это будет просто набор байт внутри задания DataStage, причём русский символ будет хранится двумя байтами.

Если вы внутри задания где-то, скажем в трансформере, снимете опцию Unicode для данного поля, оставив varchar(3), то получите неявное преобразование varchar(3) Unicode для 'ЯЯЯ' (6 байт) в varchar(3) (3 байта), которое приведёт к порче данных, будет Я (2 байта) + 1 байт нечитаемого символа, остальное вы убъёте, соответствующее предупреждение будет в журнале задания.

Возможно, что-то подобное вы и сделали. Если же вы протащите от одного файла до другого сквозь всё задание varchar(3) Unicode с указанием правильной кодировки для чтения и записи файлов, всё должно быть хорошо.
Наверное так.

Ну что ж, тогда и ответ глобально. =)

Я работал в основном либо на проектах UTF-8, либо на проектах windows-1251 с русским языком.
У вас проект в ISO8859-1 - это латинский алфавит. Без проверки я не могу сказать, с какими проблемами вы столкнётесь.

Полагаю также, что как только вы начнёте писать в базу данные, они будут ломаться по той причине, что клиенты СУБД работают у вас сейчас, скорее всего, в кодировке ОС.
Я предполагаю, что у вас UNIX/Linux раз кодировка ISO8859-1 для проекта.

Разделение полей по постоянной величине - это видимо поля с фиксированной длиной... Трудности перевода. =)

Работа с различными кодировками в DataStage подчиняется следующим правилам:
1. В Администраторе можете посмотреть какая NLS настроена для проекта, у вас ISO8859-1, значит для работы с русским вы будете вынуждены при разработке менять настройки на уровнях ниже.
2. Настройка на уровне проекта влияет на настройку NLS всех заданий, но её можно поменять на уровне задания, однако...
3. Вы можете указать NLS и на уровне элемента Sequential Stage (Stage -> NLS Map) и эта настройка перепишет настройки задания.
4. Если и так не хочется, то можете читать определённые колонки в нужной кодировке (Stage -> NLS Map -> Allow per-column mapping), а далее задаётся NLS Map на уровне колонок.

Указание правильной кодировки даст возможность заданию DataStage читать данные корректно.
Для текстовых полей должна выставляться также опция Unicode (Extended атрибут) в случае необходимости использования конвертации с использованием NLS Map-ов элемента (читаем файл в кодировке, отличной от кодировки задания).

Мне кажется логичным в вашем случае сделать перевод проекта DataStage на UTF-8 - вы сможете читать свой файлик без заморочек, либо 1251 - тогда с конвертацией в Sequential File элементе (Stage -> NLS Map -> UTF-8 + Unicode на полях), в последующих элементах Unicode с колонок можно будет снять (зависит!см.ниже). General NLS Settiing сделаете MS1251-CS в Administrator client.

При этом, если вы решитесь на UTF-8, то вы должны будет понимать, что латинские символы будут передаваться по линкам, как один байт, а русские, как два.
В кодировке 1251 - один байт и те, и другие символы. Японский не надо будет грузить в будущем? =)

Строковые функции в DataStage над текстовыми полями без опции Unicode работают в байтовом режие, попробуете сделать F[1,1] от буквы 'Я' - в проекте UTF-8 испортите данные, в проекте 1251 всё будет хорошо.
Если для поля задана опция Unicode, то работа идёт в посимвольном режиме в обоих случаях и данные испортить нельзя - получите 'Я'.

И в том и в другом случае, вам придётся при работе с СУБД познакомится ещё с рядом переменных, которые к DataStage отношения не имеют.
Вам надо будет указывать, что приложение (задание DataStage) работает с данными в кодировке UTF-8 или 1251: IANAAppCodePage (ODBC), DB2CODEPAGE (DB2), NLS_LANG (Oracle), ...
Иначе клиент СУБД будет просить данные в одной кодировке (ISO8859-1), DataStage будет их ожидать в другой - получите интересный результат.
Также можно перевести сервер на другую лоакль, либо можно будет поиграться с dsenv на предмет выставления работы процессов движка в нужной локали (локаль UTF-8.EN_US должна быть установлена).

Я бы вам посоветовал не менять резко боевой проект и продуктивный сервер, а потренироваться где-нибудь рядом.
Если вы во всём этом плохо ориентируетесь, то лучше обратиться в сервис (IBM, партнёры).

Давайте пример задания и файла с данными.
Только посмотреть обещаю не сразу, может, вечером.

Я бы не хотел Вас огорчать, не отвечая в Skype или любом другом средстве общения по Вашему желанию. У всех есть работа...

В архиве простой пример, корректно работает - пробуйте.

Но для начала настройте-ка своего Windows-клиента, чтобы он корректно отображал содержимое текстового файла с русскими символами. В архиве пример содержимого файла в картинке, так что, полагаю, справитесь - будете видеть к чему стремиться.

В администраторе DataStage тоже выставьте MS1251-CS (General->NLS->Client), перезапуск Desinger после этого обязателен.

Я максимально приблизился к вашим настройкам (ставил ISO8859-1 для проекта).
На всякий случай содержимое файла в hex после передачи на Linux (UTF-8 with BOM!):
[root@IIS912FULL tmp]# od -x HCA_UTF8_FL.txt
0000000 bbef d1bf d187 d082 77be 6f68 bad0 b0d0
0000020 bad0 000a
0000023

Передавайте файл с примером данных ТОЛЬКО в бинарном режиме, иначе рискуете его попортить.
Удачи.

Я хочу, чтобы Вы windows научили работать с русским, а после этого уже сказали, как взаимодествовать клиенту с сервером: IKC
Пользуйтесь документацией - она хорошая, правда.

Поддерживаю.

Предположим вы решили перейти на обработку в utf8, для этого:
1. Вы переводите ПРОЕКТЫ DataStage на работу в UTF8 (выбираете проект->NLS->Server Maps+Parallel Maps)
2. Эта настройка автоматически унаследуется на нижних уровнях где оставлены значения по умолчанию (Project Default), там где нзначения менялись пользователем - всё сохранится. Прочитайте, что я писал раньше про переопределение на нижних уровнях...
Например, если придёт файл в 1251 - вы сможете его прочитать заданием, работающим в utf8 в проекте с utf8, только надо будет элементу, читающему данный файл указать, что файл в соответствующей кодировке, чтобы чтение прошло корректно.
Разберётесь с примером, что я вчера выложил - будет понятнее.
3. Client настраивается так, чтобы бы корректно происходило взаимодействие и отображение символов. У меня 1251 при utf-ных серверах, но я работаю только с русским и английским (без национальных спец.симолов вроде умляутов), у себя - "будете посмотреть", может и utf8 поставите.

Очень плохо, что вы мечетесь и пробуете всё подряд. Менять один параметр за раз!

У меня 8.7 и 9.1, вам делал на 9.1 - что под рукой было, на 8.7 импортируется.

Предлагаю вам попробовать следующую последовательность действий:
1. Выставляете Client/Server в Administrator как он у вас был (WIN1252-CS?) - соответствие кодировке Windows.
У вас Windows в какой кодировке - 1252?
2. Пробуете импортировать, далее, смотря, что получаете.

Если будет крик о несоответствии версий, то можете попробовать открыть dsx и поправить Server version на 8.5.
Вообще, официально, переход с даунгрейдом версий не поддерживается, но версий, соответствующих вашим у меня нет.

От 8.0.1 отказались - эта версия снимается с поддержки вот-вот, а 8.5 - это промежуточная версия между очень хорошим 8.7 и стареющими 8.0-8.1:
Withdrawal from support
Program
number VRM date Program release name
5724-Q36 8.1.2 04/30/15 IBM InfoSphere Information Server
5724-Q36 8.0.1 09/30/14 IBM InfoSphere Information Server

И вообще, давно есть 9.1.2, а неделю назад IBM запилила 11.3! =)

Hans Christian Andersen,
ну собственно да.

Я попробовал читать только с использованием SeqFile - для fixed length полей не пошло, а так как время дорого - сделал, как делаю обычно - прочитал файл строками, а разбираю уже позже в Import Column Stage. =)

Кстати, именно такой способ чтения является довольно хорошим по производительности при работе с большими файлами, за счёт распределения процесса чтения и парсинга. Трансформер, кстати, несмотря на то, что его в техноте ставят, как альтернативу, будет работать медленнее, чем Import Column за счёт того, что вы будете делать множество обращений вида column[m,n] - для трёх полей не так критично, для большого количества полей, трансформер существенно проиграет. =)

Тема закрыта? =)