考虑到:我是AS400平台的新手，最多
问题:我们需要将可变宽度，管道分隔的ASCII文件从Windows 2003服务器传输到运行在V6R1上的FTP服务器。文件到达后被正确地翻译成EBCDIC，但是它们非常大。一个3.5Mb的文件变成一个200+ Mb的成员。一个9Gb的文件失败是因为我们碰到了某种配额。
有趣的事实:当在二进制模式下执行时(没有翻译)，文件在服务器端显示为FILENAME。具有一个名为FILENAME.MBR的成员的文件。传输大小是正确的，但由于ASCII编码，本机工具无法读取该文件。 有趣的事实:这已经在三台V6R1机器上进行了测试，结果相同。所以我很确定这是正常的行为，只是我不太理解。我的直觉是服务器在向文件添加新行时扩展了文件，但我现在真的没有更好的猜测了。有人见过这种行为吗?你知道怎样才能避免这种行为吗?
提前感谢任何花时间贡献的人。非常感谢。
IBM i FTP服务器可以处理"经典" QSYS中的对象。LIB文件系统(在这个系统中，像文件这样的对象驻留在单个库层中)或集成文件系统(一个类似于Windows和Unix中使用的分层文件系统)上的流文件。
听起来像是要将文件发送到QSYS中的物理文件(PF)中。LIB文件系统。PF具有固定长度的记录，因此您可能会在大多数记录的末尾看到一些空闲空间。您可以使用DSPFD CL命令查看PF中有多少条记录和记录长度。
如果要发送文件到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客户端连接时，您可以使用QUOTE HELP命令从IBM i FTP服务器中看到一些有趣的帮助信息。
在AS/400上有许多可用的文件系统。标准文件系统实际上是DB/2。库是一个数据库/模式，物理文件是一个表，成员是一个表分区，逻辑文件是一个索引/视图。IFS是一个基于流的普通文件系统。
Ascii模式将以EOL字符(CR/LF)结尾的文本映射到单个物理文件记录。二进制模式忽略EOL字符，并在每个记录中传输尽可能多的原始数据。有关详细信息，请参阅文件传输协议参考。
使用DSPFD命令查看文件定义。最大记录长度表示固定长度的记录大小。将其乘以要上传的记录数，以计算上传后需要多少空间。很有可能"中档人士"为您创建了一个记录长度长得离谱的文件。对于他们来说，用更合适的记录长度重新创建文件应该是微不足道的，这样您就不会浪费太多的空间。
在创建文件时定义了最大记录数，以防止磁盘被填满。这些值可以在DSPFD命令中找到:初始记录数、记录增量数和最大增量数。这些值可以根据需要使用CHGPF命令和SIZE参数进行更改。
另一个选择是上传到IFS文件系统，并让"中级人员"直接从IFS处理文件。这是Scott Klement在RPGIV中使用IFS的教程。