Ibm midrange 为什么PC到AS400、ASCII FTP传输会导致AS400端的文件增长非常大？

GIVEN:我充其量只是AS400平台的新手

问题：我们需要将可变宽度、管道分隔的ASCII文件从Windows 2003服务器传输到V6R1上运行的FTP服务器。文件到达并被正确地翻译成EBCDIC，但它们是巨大的。一个3.5Mb的文件将成为200+Mb的成员。9Gb文件失败是因为我们遇到了某种形式的配额

有趣的事实：当以二进制模式（无翻译）完成时，文件在服务器端显示为FILENAME.file，其中一个成员名为FILENAME.MBR。传输大小正确，但由于ASCII编码，本机工具无法读取文件

有趣的事实：这已经在三台V6R1机器上进行了试验，结果相同。所以我相当肯定这是正常的行为，我只是不太理解

我的直觉是服务器正在扩展文件，因为它向其中添加了新行——但我现在真的没有更好的猜测。以前有人见过这种行为吗？你知道怎样才能避免它吗

---

提前感谢任何花时间贡献的人。非常感谢。

IBM I FTP服务器既可以处理“经典”QSYS.LIB文件系统中的对象（其中有对象，例如驻留在单个库层中的文件），也可以处理集成文件系统（类似于Windows和Unix中使用的分层文件系统）上的流文件

听起来像是将文件发送到QSYS.LIB文件系统中的物理文件（PF）。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模式将以下线字符（CR/LF）结尾的文本映射到单个物理文件记录。二进制模式忽略下线字符，并将尽可能多的原始数据流放入每条记录中。有关更多信息，请参阅

使用命令查看文件定义。最大记录长度将指示固定长度的记录大小。将其乘以要上传的记录数，计算上传后需要多少空间。很有可能是“中档人士”为您创建了一个记录长度超长的文件。对于他们来说，用更合适的记录长度重新创建文件应该是很简单的，这样您就不会浪费太多空间

创建文件时定义了最大记录数，以防止磁盘被填满。您可以在命令中找到这些值，如初始记录数、增量记录数和最大增量数。可以根据需要使用带参数的命令更改这些值

---

另一种选择是上传到IFS文件系统，让“中端人士”直接从IFS处理文件。下面是斯科特·克莱门特的教程。

那么，是物理文件中的松弛导致了较大的大小？正如您所提到的，我们正在使用NAMEFMT 1发送到一个物理文件，以便中端用户能够以经典方式阅读它。是的，这是我的猜测。如果您知道一条平均记录的宽度，并将其与物理文件的记录长度进行比较，那么您应该了解松弛量。另请注意，如果您向PF发送文件，您使用的是NAMEFMT 0。从技术上讲，只要服务器未明确配置为强制将

NAMEFMT 0

作为默认值，并且您在FTP脚本中对任何文件系统路径的初始引用为

NAMEFMT 1

格式，则不需要

QUOTE SITE NAMEFMT 1

。默认情况下，服务器将自动切换到两种格式之一的首次使用。设置任何初始格式后，只能通过向服务器发出

NAMEFMT

命令来更改它。记录长度设置为标题中最长的行，则每行将占用该空间的速度太快。