为什么 PC 到 AS400 的 ASCII FTP 传输会导致 AS400 端的文件增长非常大？
鉴于：我充其量是 AS400 平台的新手
问题：我们需要将可变宽度、管道分隔的 ASCII 文件从 Windows 2003 服务器传输到在 V6R1 上运行的 FTP 服务器。文件到达并正确转换为 EBCDIC，但它们很大。 3.5Mb 文件变成 200+ Mb 成员。 9Gb 文件失败是因为我们遇到了某种配额。
有趣的事实：以二进制模式（无翻译）完成时，该文件在服务器端显示为 FILENAME.FILE，其中有一个名为 FILENAME.MBR 的成员。传输大小正确，但由于 ASCII 编码，本机工具无法读取该文件。
有趣的事实：这已在三台 V6R1 机器上进行了尝试，结果相同。所以我相当确定这是正常行为，我只是不太理解。
我的直觉是服务器正在扩展文件，因为它向其中添加了新行——但目前我确实没有更好的猜测。有人以前见过这种行为吗？您知道如何避免这种行为吗？
预先感谢任何花时间做出贡献的人。我很感激。
GIVEN: I am a novice on the AS400 platform, at best
PROBLEM: We need to transfer variable width, pipe-delimited ASCII files from a Windows 2003 server to an FTP server running on V6R1. The files arrive and are properly translated to EBCDIC, but they are huge. A 3.5Mb file becomes a 200+ Mb member. A 9Gb file fails because we bump up against some manner of quota.
INTERESTING FACT: When done in binary mode (no translation), the file appears on the server side as FILENAME.FILE with one member named FILENAME.MBR. The transfer size is correct, but the file is not readable by native tools because of the ASCII encoding.
INTERESTING FACT: This has been tried on three V6R1 machines with the same results. So I'm fairly certain this is normal behavior that I just do not understand well.
My gut feeling here is that the server is extending the file as it adds new rows to it -- but I really don't have a better guess that that at this point. Has anyone seen this behavior before, and do you know what it takes to avoid it?
Thanks in advance to anyone taking the time to contribute. I do appreciate it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
IBM i FTP 服务器可以处理“经典”QSYS.LIB 文件系统中的对象（其中您有诸如驻留在单层库中的文件之类的对象）或流集成文件系统（类似于分层文件系统）上的文件Windows 和 Unix 中使用的内容）。
听起来您正在将文件发送到 QSYS.LIB 文件系统中的物理文件 (PF) 中。 PF 具有固定长度的记录，因此您可能会在大多数记录的末尾看到一些空闲空间。您可以使用 DSPFD CL 命令查看 PF 中有多少条记录以及记录长度。
如果要将文件发送到 PF，FTP 服务器默认使用名称格式 0，即 QSYS.LIB 文件系统。在此模式下，您将发送到 PF，如下所示：
如果要将文件发送到流文件，则必须首先向 FTP 服务器发送命令：
这会将 FTP 服务器切换到 IFS 命名模式。因此，当您发送文件时，您需要指定要将其发送到的目录。例如：
如果您要发送可变长度记录，则 IFS 流文件将不会像物理文件中那样存在松弛。
如果管道分隔文件包含单个布局，您可以使用 CPYFRMIMPF CL 命令将其映射到具有实际记录格式的 PF，这可能是更“本机”的方法。但是，如果它是更复杂的文件格式，您可能需要编写一个 ILE RPG 程序来将流文件转换成它需要的任何形式。 这里有一些关于从 ILE RPG 访问流文件的精彩教程。
另请注意，从命令行 FTP 客户端连接时，您可以使用
QUOTE HELP命令从 IBM i FTP 服务器查看一些有趣的帮助信息。The IBM i FTP server can either deal with objects in the "classic" QSYS.LIB file system (where you have objects such as files residing in a single layer of libraries) or stream files on the Integrated File System (a hierarchical file system similar to what's used in Windows and Unix).
It sounds like you're sending the file into a Physical File (PF) in the QSYS.LIB file system. A PF has fixed-length records, so you're probably seeing some slack space at the end of most records. You can see how many records are in the PF and the record length using the
DSPFDCL command.If you want to send the file to a PF, the FTP server defaults to name format 0, which is the QSYS.LIB file system. In this mode you'd send to a PF such as this:
If you want to send the file to a stream file, you have to first send a command to the FTP server:
This switches the FTP server into IFS naming mode. As a result, when you send the file you'll need to specify what directory you want to send it to. For example:
If you're sending up variable-length records, that IFS stream file will have no slack as you'd see in a Physical File.
If the pipe-delimited file contains a single layout, you can use the
CPYFRMIMPFCL command to map it into a PF with an actual record format, which is probably the more "native" way to do it. If it's a more complex file format, however, you might have to write an ILE RPG program to convert the stream file into whatever form it needs to be in. Here are some great tutorials on accessing stream files from ILE RPG.Also note that you can see some interesting help info from the IBM i FTP server using the
QUOTE HELPcommand while connected from a command-line FTP client.网上有许多可用的文件系统 AS/400。标准文件系统实际上是 DB/2。库是数据库/模式，物理文件是表，成员是 表分区，逻辑文件是索引/视图。 IFS 是一个普通的基于流的文件系统。
Ascii 模式将以 EOL 字符 (CR/LF) 结尾的文本映射到单个物理文件记录。二进制模式忽略 EOL 字符并流式传输每条记录中适合的原始数据。有关更多信息，请参阅文件传输协议参考。
使用 DSPFD 命令查看该文件定义。 最大记录长度将指示固定长度记录大小。将其乘以要上传的记录数即可计算上传后需要多少空间。很可能“中档人员”为您创建了一个记录长度长得离谱的文件。对于他们来说，重新创建具有更合适的记录长度的文件应该很简单，这样您就不会浪费太多空间。
创建文件时定义了最大记录数，以防止磁盘填满。您可以在 DSPFD 中找到这些值命令为初始记录数、增量记录数和最大增量数。可以使用 CHGPF 命令与 SIZE 参数。
另一种选择是上传到 IFS 文件系统，并让“中端人员”直接从 IFS 处理文件。这是 Scott Klement 的在 RPGIV 中使用 IFS 的教程。
There are many file systems available on the AS/400. The standard file system is really DB/2. A library is a database/schema, a physical file is a table, a member is a table partition, and a logical file is an index/view. The IFS is a normal stream based file system.
Ascii mode will map text ending with an EOL character (CR/LF) to a single physical file record. Binary mode ignores EOL characters and streams as much raw data as will fit in each record. For more information see the File Transfer Protocol reference.
Use the DSPFD command to view the file definition. The Maximum record length will indicate the fixed length record size. Multiply that by the number of records to be uploaded to calculate how much space it will require once uploaded. Chances are the 'mid-range folks' created a file for you with an absurdly long record length. It should be trivial for them to recreate the file with a more appropriate record length so that you don't waste too much space.
There is a maximum number of records defined when a file is created to prevent the disk from filling up. You can find those values in the DSPFD command as Initial number of records, Increment number of records, and Maximum number of increments. Those values can be changed as required using the CHGPF command with the SIZE parameter.
Another option would be to upload to the IFS file system and have the 'mid-range folks' process the file directly from the IFS. Here's a Scott Klement tutorial for Working with the IFS in RPGIV.