COBOLは、私はいくつかのレガシーCOBOLコードを変換するに取り組んでおり、このような文に出くわしたんだ

INSPECT WS-LOCAL-VAR REPLACING ALL X'0D25' BY ' '

私はINSPECTことを理解-VAR、パターンX'0D25 'と一致し、スペースで置き換えます。私は理解していない何

は「0D25」の外にXの目的です。オンラインで見つかったすべてのREPLACING ALLの例は、パターンマッチングのためにcharリテラル以外のものを使用していません。

はどのようにXが置換されたパターンに影響しますか？

COBOLはEBCDICマシン上で実行されていて、入力ファイルは、Windowsマシンから来ています。

2016-05-06 arseniy

"X"は、リテラルが16進文字コードとして解釈されているとします。私はOPがどんな貢献をしているのか分からない。 –

私はどういたしまして – arseniy

（私は疑問に誤って書かれていた）進コードを持つ文字「0D25」に基づいて、より多くのCOBOLの経験を持つ同僚を見つけ、あなたが正しいことを確認し、それが一致した： - } –

COBOLはEBCDIC機（メインフレーム/ AS400）上で実行されているとのWindowsマシン ???からのファイルです。

Ebcdicには、行末文字「」x'25 'がasciiの2（\ r、\ n）に付けられています。 X'0D25'はのWindowsエンド・オブ・ラインマーカー\ rを\ nはのEBCDIC表現です。 Ebcdicでは、0Dは有効な文字ではありません。問題の可能性

ソース：メインフレーム/ AS400に転送Windowsのテキストファイルの

悪い変換。 Windows上の
のJava（およびおそらく他の現代語）。 Windows上のJavaは、標準ライターを使用してEbcdic Textファイルを書き込むことをサポートしています。しかし、Windowsでは、\ rがで有効なEBCDIC文字ではなく、x'0D25 'を含む壊れたファイルを取得しても、Javaは\ r \ nと書いています。
あなたがメインフレームにRの\ nは \ハードコードプログラムを動かして、それを実行する場合は、ファイル内のx'0d25' を取得します。

2016-05-06 23:43:27

EBCDIC X」 0D 'は依然としてCR文字です。ファイル転送がソース・システムから行の終わりを適切に変換しないように思えますが、X'0A 'LF文字をEBCDICと同等のX'25'に変換しています。 –

Xは文字列内の文字は16進数であることを示しています。この場合、X"0D"はリターンキャリッジ文字を示し、X"25"は％記号（ASCIIシステムを想定）を示します。

同様の表記法は、国文字列（N" こんにちは"）およびブール/ビット列（B"0101010"）及びそれらのそれぞれの進同等物（NX"01F5A4"とBX"2A"）を示すために使用されます。

2016-05-07 10:45:34

答えて