Управление появлением новых линий в мэйнфрейме IBM - PullRequest
Новая
       1

Управление появлением новых линий в мэйнфрейме IBM

2 голосов
/ 30 августа 2010

Все,

Итак, я загружаю текстовый файл из C # в мейнфрейм IBM MVS.Файл конвертируется в ebcdic с использованием библиотек C #, и он работает хорошо, так как я могу читать данные на мэйнфрейме.Проблема в новых линиях.Текстовый файл содержит 10 строк данных, и при его просмотре в среде мэйнфрейма все данные присутствуют.Но новых строк нет, так как каждая новая строка из текстового файла переводится как 0D25, то есть CRLF.Этот сегмент отображается как ... на экране.
Я не хочу, чтобы эти 2 точки имели шестнадцатеричное значение 0D25, потому что мне нужно, чтобы они фактически помещали данные в следующую строку, как в текстовом файле.Файл имеет переменную длину блока один раз на мэйнфрейме.Как я могу добиться того же форматирования, что и текстовый файл, при просмотре загруженного файла в MVS?

пример: ПРОСМОТР ТЕКСТА ФАЙЛА

12345
23456
12346


IBM MAinFrame View

12345..23456..12346

или если достигнута длина блока ..

12345..2345
6..12346

Спасибо

1 Ответ

4 голосов
/ 30 августа 2010

Если вы выполняете перевод ASCII-EBCDIC вне процесса передачи по FTP, я должен предположить, что вы переводите в двоичном режиме (в противном случае перевод будет выполнен снова , и ваши данные будутбыть плохим).

Если это так, то я вполне уверен, что вы сами несете ответственность за преобразование концов строк.Двоичные переводы не будут пытаться преобразовать окончания строк.Вам нужно будет разметить строки до желаемой длины и полностью удалить окончания строк перед отправкой на хост.

Например, если вы передадите этот файл: 

12345
67890

вверх в двоичном режиме, используя literal site recfm=vb, вы получите следующее (показано в редакторе ISPF с hex on): 

000001                    
       3333300333330044444
       12345DA67890DA00000
--------------------------

Вы можете видеть, что он просто передал байты как есть, в том числе CR / LF.Если вы переключитесь в режим ASCII в FTP и загрузите снова, вы получите: 

000001 12345        
       FFFFF44444444
       1234500000000
--------------------
000002 67890        
       FFFFF44444444
       6789000000000
--------------------

Здесь символы были преобразованы в правильные кодовые точки EBCDIC, а окончания строк были преобразованы в отступы с пробелами EBCDIC.

Полагаю, мой первый вопрос к вам будет звучать так: «Почему вы делаете перевод вне FTP?»

IBM вкладывает немалые деньги в обеспечение того, чтобы она принимала все виды различных кодировок и переводила их в правильную кодовую страницу.Маловероятно, что автономное решение будет работать на всех интернационализированных версиях z / OS, а также на собственной IBM.

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

Если вы этого не сделаете знать, какими будут свойства целевого набора данных (например, если вы переносите элемент в PDS), последний вариант может быть единственным жизнеспособным.

...