Почему FTP-передача с ПК на AS400 в формате ASCII приводит к очень большому увеличению размера файла на стороне AS400?

ДАНО: я новичок на платформе AS400, в лучшем случае

ПРОБЛЕМА: Нам необходимо передать ASCII-файлы переменной ширины, разделенные конвейером, с сервера Windows 2003 на FTP-сервер, работающий на V6R1. Файлы приходят и правильно переводятся в EBCDIC, но они огромные. Файл размером 3,5 Мб становится участником размером 200+ Мб. Файл размером 9 ГБ не работает, потому что мы натыкаемся на какую-то квоту.

ИНТЕРЕСНЫЙ ФАКТ: при выполнении в двоичном режиме (без перевода) файл отображается на стороне сервера как ИМЯ ФАЙЛА.ФАЙЛ с одним элементом с именем ИМЯ ФАЙЛА.MBR. Размер передачи правильный, но файл не читается встроенными инструментами из-за кодировки ASCII.

ИНТЕРЕСНЫЙ ФАКТ: Это было опробовано на трех машинах V6R1 с одинаковыми результатами. Так что я вполне уверен, что это нормальное поведение, которое я просто плохо понимаю.

Мое внутреннее ощущение здесь таково, что сервер расширяет файл, добавляя в него новые строки, но у меня действительно нет лучшего предположения, что это на данный момент. Кто-нибудь видел такое поведение раньше, и знаете ли вы, что нужно, чтобы избежать этого?

Заранее благодарим всех, кто найдет время внести свой вклад. Я ценю это.


ibm-midrange
person Jon Lent    schedule 15.07.2011    source источник
comment
Длина записи установлена ​​​​на самую длинную строку в заголовке, тогда каждая строка будет занимать это место слишком быстро.   -  person Thorbjørn Ravn Andersen    schedule 07.08.2012

Ответы (2)


arrow_upward
6
arrow_downward

FTP-сервер IBM i может работать либо с объектами в «классической» файловой системе QSYS.LIB (где у вас есть такие объекты, как файлы, находящиеся в одном уровне библиотек), либо с потоковыми файлами в интегрированной файловой системе (иерархическая файловая система, аналогичная к тому, что используется в Windows и Unix).

Похоже, вы отправляете файл в физический файл (PF) в файловой системе QSYS.LIB. PF имеет записи фиксированной длины, поэтому вы, вероятно, видите некоторое свободное пространство в конце большинства записей. Посмотреть количество записей в PF и длину записи можно с помощью команды DSPFD CL.

Если вы хотите отправить файл на PF, FTP-сервер по умолчанию использует формат имени 0, который соответствует файловой системе QSYS.LIB. В этом режиме вы должны отправить в PF, например:

SEND myfile.txt DMCLIB/MYFILE.MYMBR

Если вы хотите отправить файл в потоковый файл, вы должны сначала отправить команду на FTP-сервер:

QUOTE SITE NAMEFMT 1

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

SEND myfile.txt /home/dmc/myfile.txt

Если вы отправляете записи переменной длины, у этого файла потока IFS не будет резерва времени, как в физическом файле.

Если файл с разделителями вертикальной черты содержит один макет, вы можете использовать команду CPYFRMIMPF CL, чтобы отобразить его в PF с фактическим форматом записи, что, вероятно, является более «родным» способом сделать это. Однако, если это более сложный формат файла, вам, возможно, придется написать программу ILE RPG для преобразования потокового файла в любую форму, в которой он должен быть. Вот несколько отличных руководств по доступу к потоковым файлам из ILE RPG.

Также обратите внимание, что вы можете увидеть интересную справочную информацию от FTP-сервера IBM i, используя команду QUOTE HELP при подключении из FTP-клиента командной строки.

person dmc    schedule 15.07.2011
comment
Значит, большой размер возникает из-за свободного места в физическом файле? Как вы упомянули, мы отправляем в физический файл, используя NAMEFMT 1, чтобы люди среднего уровня могли читать его классическим способом. - person Jon Lent; 15.07.2011
comment
Да, это мое предположение. Если вы знаете, насколько широка средняя запись, и сравните ее с длиной записи физического файла, вы должны получить представление о величине резерва. Также обратите внимание, что если вы отправляете на PF, вы используете NAMEFMT 0. - person dmc; 15.07.2011
comment
Технически QUOTE SITE NAMEFMT 1 не требуется, если сервер явно не настроен на принудительное использование NAMEFMT 0 в качестве значения по умолчанию, и исходная ссылка в сценарии FTP на любой путь к файловой системе имеет формат NAMEFMT 1. По умолчанию сервер автоматически переключится на первое использование одного из двух форматов. После установки любого начального формата его можно изменить только с помощью команды NAMEFMT на сервере. - person user2338816; 04.04.2014

arrow_upward
3
arrow_downward

На АС/400. Стандартная файловая система на самом деле DB/2. Библиотека — это база данных/схема, физический файл — это таблица, член — это таблица раздел, а логический файл — это индекс/представление. IFS — это обычная файловая система на основе потоков.

В режиме Ascii текст, оканчивающийся символом EOL (CR/LF), отображается в одну запись физического файла. Двоичный режим игнорирует символы EOL и передает столько необработанных данных, сколько поместится в каждой записи. Дополнительные сведения см. в справочнике по протоколу передачи файлов.

Используйте команду DSPFD для просмотра файла. определение. Параметр Максимальная длина записи указывает размер записи фиксированной длины. Умножьте это на количество загружаемых записей, чтобы рассчитать, сколько места потребуется после загрузки. Скорее всего, «люди среднего уровня» создали для вас файл с абсурдно длинной записью. Для них должно быть тривиальным воссоздание файла с более подходящей длиной записи, чтобы вы не тратили слишком много места.

При создании файла определяется максимальное количество записей, чтобы диск не заполнялся. Эти значения можно найти в DSPFD. команды как Начальное количество записей, Увеличить количество записей и Максимальное количество приращений. При необходимости эти значения можно изменить с помощью CHGPF с параметром SIZE параметр.

Другим вариантом может быть загрузка в файловую систему IFS, а «люди среднего уровня» обрабатывают файл непосредственно из IFS. Вот учебник Скотта Клемента по Работа с IFS в RPGIV.

person James Allman    schedule 15.07.2011