兩個想法...
你的第一個例子表明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