問題タブ [comp-3]

メインフレームから入ってくる一連のASCIIフラットファイルがC＃アプリケーションで処理されています。Packed Decimal（COMP-3）フィールドを備えた新しいフィードが導入されました。このフィールドは、数値に変換する必要があります。

ファイルは、ASCII転送モードを使用してFTP経由で転送されています。バイナリフィールドに、値の代わりに非常に低いASCIIコードまたは制御文字として解釈されるものが含まれている可能性があることを懸念しています。さらに悪いことに、FTPプロセスで失われる可能性があります。

さらに、フィールドは文字列として読み取られています。私はこの部分（つまり、ある種のストリーム）を回避する柔軟性を持っているかもしれませんが、ビジネスは私にプッシュバックを与えます。

要件は「HEXからASCIIに変換する」と読みましたが、明らかに正しい値が得られませんでした。どんな助けでもいただければ幸いです。変換プロセスのロジックを説明できる限り、言語固有である必要はありません。

Comp-3 データから固定幅の文字列に展開された固定幅のテキスト ファイルがあります。

次のフィールドを解釈する方法を知る必要があります。

これらは私のフラットファイルに次のように表示されます。

上記の数字が何を表すかを知る必要があります。

これは正しいです：

助けてくれてありがとう。ハム

Jon Skeet の .NET での EBCDIC 実装を使用して、メインフレーム システムから FTP を使用してバイナリ モードでダウンロードされた VSAM ファイルを読み取ります。このエンコーディングでの読み取り/書き込みには非常にうまく機能しますが、パック 10 進数値を読み取る機能はありません。私のファイルにはこれらが含まれており、それらを展開する必要があります (明らかに、より多くのバイトを犠牲にして)。

これどうやってするの？

私のフィールドは次のように定義されていますPIC S9(7)V99 COMP-3.

COBOLをRubyプログラムに変換するという冒険を続けて、10進数をcomp-3/パック10進数形式に変換する必要があります。これを行う簡単なRubyスクリプトまたはgemを知っている人はいますか？ベルンズ

COBOL プログラムを Ruby プログラムに変換する新しい冒険を始めています。comp-3/packed decimal 形式を数値に変換する必要があります。

別の以前の投稿から、数値から comp-3 に変換するコードがありますが、逆には変換しません。

いくつかの情報を含む ASCII 出力ファイルを作成していますが、2 つのフィールドでは日付と時刻をパック 10 進数フィールド (COMP-3) にする必要があります。SQL と SSIS を使用してファイルを生成しています。

複数のサイトを検索しましたが、日付/時刻をパック 10 進数フィールドに変換する方法がまだわかりません。どんな助けでも大歓迎です。

次のサイトhttp://www.simotime.com/datapk01.htm#TablePackedDecimalは、Packed フィールドに関する情報を提供しています。パックされたフィールドがどのように使用されるかは理解していますが、フィールドをパックする方法はよくわかりません。ありがとう！

テキスト フィールドと数値フィールドが混在する COBOL の「テープ形式」ダンプがあります。C# でファイルをバイナリ配列 (バイトの配列) として読み取っています。私はコピーブックを持っており、フォーマットはテキストフィールドにうまく並んでいます. COMP-3 フィールドもいくつかあります。これらのフィールドのデータは、BCD 形式と一致していないようです。私はデータがどうあるべきかを知っており、COMP-3 の生のバイトを持っています。最初に EBCDIC に変換しようとしましたが、良い結果は得られませんでした。それ以外の方法で COMP-3 番号を内部に保存する方法について何か考えはありますか? 以下は、PIC、生データ、および予想される数の 3 つの例です。数字の両側にアルファ データがあり、すべてが正しく並んでいるので、フィールドの位置が正しいことはわかっています。

最初の例: フィールドの PIC は 9(9) COMP-3 データには 5 バイトあり、16 進値は 02 01 20 91 22 です。結果のデータは日付 (00CCYYMMDD) になります。この特定の日付は 3-17-14 である必要があります。

2 番目の例: フィールドの PIC は S9(3) COMP-3 データには 2 バイトあり、16 進値は 0A 14 結果の値は 900 から 999 の間である必要があります。最後のニブルは、+ または - を示すために 0xC または 0xD である必要があります

3 番目の例: フィールドの PIC は S9(15)V99 COMP-3 です データには 9 バイトがあり、16 進値は 00 00 00 00 00 00 01 80 0C です 結果の値は 12.00 になるはずです

正しい方向に私を向けてくれたので、回答してくれた人々に感謝します。これは確かに ASCII/EBCDIC 表現の問題です。BCD は EBCDIC に格納されます。ASCII から EBCDIC への変換テーブルを使用すると、適切にフォーマットされた BCD 数字が生成されます。

このリンクを使用してデータをマッピングしました: http://shop.alterlinks.com/ascii-table/ascii-ebcdic-us.php

私のデータ: 0A 14 変換済み: 25 3C (253 は有効な値であることがわかりました。仕様は間違っていました) C = +、すべて良好

私のデータ: 01 80 0C (先頭のゼロを除く) 変換: 01 20 0C 12.00 C = +, 暗黙の 2 桁の形式, すべて良好

私のデータ: 02 01 20 91 22 変換済み: 02 01 40 31 7F 2014/03/17 (F は未使用のニブル)、すべて良好

Binary(7) として定義されている列を含む SQL Server テーブルがあります。これは、Comp-3 データ (パック 10 進数) を持つ COBOL プログラムからのデータで更新されます。数値を取得して Comp-3 値を作成する C# プログラムを作成しました。CLR統合を介してSQL Serverで利用できます。ストアドプロシージャのようにアクセスできます。

私の問題は、このプログラムから値を取得してバイナリ列に保存する必要があることです。既にそこにあるデータの行を選択すると、次のような値が表示されます。

0x00012F0000000F

表示されている値は、SQL テーブルに格納されている COBOL comp-3 (パック 10 進数) データです。このフィールドは Binary(7) として定義されていることに注意してください。2 つの値が連結され、ここに格納されます。符号なし値 12、および符号なし値 0。

0x00012F (長さ 3 文字) と 0x0000000F (長さ 4 文字) を連結して列に書き込む必要があります。

私の質問は 2 つの部分です。

1) プログラムから Comp-3 値の文字列表現を返すことができます。しかし、これがこの作業を行うために返す必要がある形式であるかどうかはわかりません。SQL を正しく使用するには、どの形式で SQL に返す必要がありますか?

2) これを変換して機能させるにはどうすればよいですか?

私が十分に明確だったことを願っています。消化するのは大変です...ありがとう！

ddを使用して ASCII に変換された、以前は EBCDIC でエンコードされたファイルであったファイルがあります。ただし、一部の行には、読みたい COMP-3 パック フィールドが含まれています。

たとえば、デコードしたい行の 1 つの文字列表現は次のとおりです。

読み取りたいフィールドは で指定されますPIC S9(09) COMP-3 POS. 3。つまり、3 番目のバイトから始まり、デコードすると 9 バイトの長さになります (したがって、COMP-3 仕様によると、エンコードすると 5 バイトの長さになります)。

私は COMP-3 仕様を理解しており、この特定の行では、このフィールドの整数値が であるべきであることも知っていますが315、フィールドを実際にデコードするために何をすべきかわかりません。ddまた、ファイルがASCIIに変換されたという事実がここで問題になるかどうかもわかりません。

誰かが以前に同様の問題に取り組んだことがありますか、それとも私が見逃している明らかなものがありますか? ありがとうございました！

Javaコードでcomp3およびEBCIDIC文字を変換しようとしていますが、処理されるデータ量が約5 GBであるため、メモリ不足の例外が発生します。私のコードは現在次のとおりです。

これにより、メモリ不足の例外が発生しますが、これは理解できますが、ファイル内のデータが行に分割されないため、ファイル スキャナーも使用できません。

これを処理する方法について誰かが正しい方向に私を向けることができますか

注: ファイルには異なる長さのレコードが含まれている可能性があるため、レコード長の継ぎ目に基づいてファイルを分割することはできません。