两个想法...
你的第一个例子表明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文件名。 它不会为您追加用户标识。
这个例子显示的区别:
@"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#转义双引号(\“)字符来代替?我认为这也可以。
它看起来存在与括号内的命名惯例有关的问题。服务器不喜欢超过8个字符的文件名,它们必须是字母或数字,没有别的。 – Erf 2010-08-31 14:56:25
这是正确的。您正在使用PDS数据集,并且该PDS数据集中的任何成员名称中都不能超过8个字符。实际上,您正在使用包含1-n个单独成员的单个数据集(文件)。每个成员都是一个逻辑数据块,可以通过8个字符的名称进行引用,并在不影响该数据集内的其他成员的情况下进行操作。 PDS维护一个内部目录结构,以便在数据被修改时跟踪每个成员。 – MikeC 2011-06-24 02:17:35