2010-08-30 46 views
2

全部,控制IBM大型機中新行的外觀

所以我將C#中的文本文件上傳到IBM MVS大型機。該文件使用C#庫轉換爲ebcdic,並且運行良好,因爲我可以讀取大型機上的數據。問題是新的線路。該文本文件有10行數據,並在大型機環境中查看時,所有數據都存在。但是沒有新行,因爲它將文本文件中的每一行都作爲0D25,即CRLF。該段在屏幕上顯示爲..
我不希望有兩個點的十六進制讀數爲0D25,因爲我需要它實際將數據放在下一行,因爲它在文本文件中。該文件在主機btw上是可變塊長度一次。在MVS上查看上傳文件時,如何實現與文本文件相同的格式?

例如: 文本文件查看


IBM大型機查看

12345..23456..12346

,或者如果塊長度已經達到..

12345..2345
6..12346

感謝

回答

4

如果你正在做的在FTP傳輸過程之外的ASCII-EBCDIC轉換,我不得不假設你正在以二進制模式進行傳輸(否則翻譯將會再次執行,並且你的數據會很糟糕)。

如果是這樣的話,那麼我非常肯定你自己也要爲換行結束負責。二進制轉移不會嘗試轉換行結尾。在發送給主機之前,您需要將線路填充到所需的長度並完全刪除線路結尾。

舉例來說,如果你傳輸文件:

12345 
67890 

了以二進制方式使用literal site recfm=vb,你會得到以下(在ISPF編輯器hex on所示):

000001      
     3333300333330044444 
     12345DA67890DA00000 
-------------------------- 

你可以看到它只是按原樣傳輸字節,包括CR/LF。如果您切換到FTP ASCII模式並重新上傳,您可以:

000001 12345   
     FFFFF44444444 
     1234500000000 
-------------------- 
000002 67890   
     FFFFF44444444 
     6789000000000 
-------------------- 

這裏,角色已經轉換爲正確的EBCDIC代碼點和線的結局已演變成與EBCDIC空格填充。

我想我的第一個問題是:「你爲什麼要在FTP之外進行翻譯?「

IBM投入了相當多的資金來確保它能夠接受各種不同的編碼並將它們轉換成正確的代碼頁。獨立解決方案不太可能適用於所有國際化版本的z/OS以及IBM自己的。

如果你要必須在客戶端進行轉換並以二進制模式進行傳輸,那麼您必須讓客戶端進行行結束轉換和填充,或者後處理文件傳輸後,如用REXX腳本。

如果你不知道知道 wh在目標數據集的屬性將是(例如,如果您要轉移到PDS中的成員),後一個選項可能是唯一可行的選項。