Это зависит от типа целевого «файла», в который вы загружаете.
Если вы загружаете на элемент с фиксированным размером блока (например, FB80), вам необходимо убедиться, что все строки заполнены пробелами, прежде чем передать его (в двоичном режиме).
Передачи в текстовом режиме не подходят для двоичных файлов (и ваши файлы являются двоичными, если они содержат упакованные десятичные дроби - для FTP нет надежного способа обнаружения реальных символов конца строки).
Вам потребуется исправить конвертер Windows ASCII-в-EBCDIC, чтобы иметь возможность генерировать записи фиксированной длины.
Единственный другой вариант - использование сценария REXX на мэйнфрейме, но для этого все равно потребуется возможность определить разницу между реальным маркером конца строки и этим маркером в двоичных данных.
Возможно, вы могли бы сказать о наличии упакованного десятичного знака в силу того факта, что он состоял из нибблов BCD, последний из которых 0xC или 0xD, но это также могло привести к ложным срабатываниям или отрицаниям.
Мой совет: когда вы конвертируете его из ASCII в EBCDIC, одновременно добавьте строки к нужной длине записи.
Еще один момент, на который я хотел бы обратить внимание: если вы просто хотите посмотреть файлы на мэйнфрейме (не используйте их из кода, требующего EBCDIC), редактор ISPF содержит несколько новых команд (начиная с z / OS 1.9, если я правильно помню).
SOURCE ASCII
будет отображать данные в формате ASCII, а не EBCDIC. Кроме того, команда LF
позволяет вам массировать поток ASCII в элементе FB, чтобы правильно исправить окончания строки.