两个想法...
您的第一个示例表明对 MVS 文件名的基本误解。
与 Unix、DOS 或 MS Windows 不同,没有文件夹或“路径”之类的东西。整个 MVS 文件在系统目录中由其唯一的数据集名称定义,该名称不能超过 44 个字符。该文件的组织结构可能不同,可能有也可能没有内部目录或索引。它可以是简单的平面文件、PDS、VSAM、GDG 或数据库等。您必须了解正在使用的文件类型才能正确使用它。
在这种情况下,您将其称为“库”,并进一步指出该库有一个成员名称,强烈暗示该文件是作为 PDS 数据集组织的。作为 PDS,有一个内部目录,可以有多个成员,但单个成员名称不能超过 8 个字节。成员名称计入文件名的 44 字节名称空间限制。正如 Erf 所指出的,PDS 成员名称仅限于字母、数字和一些国家字符。成员内的数据是按顺序访问的。
在您的第一个示例中,您指出成员名称是:user_id.xyz.someFile
该名称显然无效,因为它超过了 8 个字节的限制。如果您缩短了名称,您的示例可能会起作用。事实上,在您更正的示例中,您通过创建一个名为“someFile”的 PDS 成员解决了非法成员名称问题,这是完全有效的。
第二个想法......
你说“如果你在这个命令上使用完整的 MVS 数据集路径,你会得到一个错误。”
该声明听起来不正确,表明您可能不允许 FTP 会话自动将用户 ID 附加到您的文件名。虽然允许 FTP 默认您的文件名工作正常,但在大多数情况下,您应该明确限定整个 MVS 文件名。
如果没有撇号,默认情况下 FTP 应该将您的用户 ID 附加到 MVS 文件名。以下名称是等价的...
@"ftp://xx.xx.xx.xx//libary_name(aMember)"
@"ftp://xx.xx.xx.xx//'user_id.libary_name(aMember)'"
使用撇号,FTP 要求您明确命名完全限定的 MVS 文件名。 它不会为您附加用户 ID。
此示例显示了差异:
@"ftp://xx.xx.xx.xx//libary_name(aMember)" <- user_id.libary_name(aMember)
@"ftp://xx.xx.xx.xx//'xyz.libary_name(aMember)'" <- xyz.libary_name(aMember)
您提到如果没有撇号,FTP 将无法工作。这让我很惊讶。您是否尝试过使用 C# 转义双引号 (\") 字符来代替?我认为这也可以。