問題タブ [cobol]

ここにあるいくつかの質問を読むと、リファクタリングや再コーディングが悪夢であるという理由だけでなく、単に特定の理由で、膨大な量の COBOL コードが「世の中に」存在し続けているというのが一般的なコンセンサスのようです。市場セグメント (金融など) で、独自の能力を十分に発揮できることが証明されています。しかし、その原因となっているのは言語について何なのでしょうか? 数十年前の何かが、メモリ管理などのすべての相応の改善により、より現代的な言語に対して独自に保持するのに十分なパフォーマンスを維持するにはどうすればよいでしょうか? COBOLコンパイラなどは、バックグラウンドで静かに改善されただけですか? それとも、特定の一連の操作に対して非常に効率的であることを意味する、言語に固有の何かがありますか?

Cobol Copybook から XSD に変換するツールを知っている人はいますか? またはXML。

SECTIONCOBOL にとの両方があるのはなぜPARAGRAPHですか?

SECTIONCOBOL の設計者がs とs の両方を作成した理由を誰か説明できますPARAGRAPHか? NEXT SENTENCEこれらはCOBOLの最初のリリース以来存在していたので、それらの存在の本当の理由はずっと前になくなったのではないかと思います（後方互換性のために言語仕様に残っているものの、明示的なスコープターミネータの導入以来必要ではなくなったものと同様です） ）。

私の推測では、SECTIONプログラム オーバーレイをサポートするために導入された可能性があります。SECTIONには、その一部であるプログラム オーバーレイを識別するために、それに関連付けられたオプションの PRIORITY 番号があります。ただし、COBOL の最新の実装のほとんどは、PRIORITY 番号 (およびオーバーレイ) を無視するか、削除しています。

現在、の一部でSECTIONs がまだ必要であることがわかりますが、これを正当化する理由は見つかりません。との間に意味的な違いは見られませんが、は に従属しています。DECLARATIVEPROCEDURE DIVISIONSECTIONPARAGRAPHPARAGRAPHSECTION

一部の COBOL ショップでは、の使用を禁止していますSECTION(PARAGRAPH北米では一般的なようです)。PARAGRAPH他の人は賛成して禁止しSECTIONます（ヨーロッパでは一般的なようです）. さらに、それぞれがいつ適切であるかについてのガイドラインを持っているものもあります。これらはすべて、私には非常に恣意的なものに思えます。疑問が生じます。そもそも、なぜそれらが言語仕様に組み込まれたのでしょうか? そして、それらは今日の関連性を持っていますか?

この質問に答える場合は、回答を裏付ける参考文献も示していただければ幸いです。

ありがとう

C＃アプリケーションのSQLクエリを介してCOBOLパックフィールドを更新しようとしています。現在、COBOLパックフィールドは、MS SQLデータベースの文字列（char（50））に格納されています。

COBOLデータ型=4バイトの2進数（「PICS9（9）COMP」）：

次のステートメントを使用してデータを抽出できます。データ更新のためにこのプロセスを逆にする方法がわかりません。

CAST（CAST（SUBSTRING（{列名}、{開始}、4）AS VARBINARY（4））AS BIGINT）AS {Alias_Name}

助言がありますか？

ありがとう、

ブレナン・マン

私は友人と、さまざまなタイプの IT ワーカーが予想外の失業 (レイオフ、会社の廃業、時代遅れのスキルなど) に対して相対的に脆弱であることについて話しました。

COBOL 開発者 (またはメンテナー?) は、経済状況や彼らの状態に関係なく、自分の立場で非常に安定しているように見えます。一方では非常に多くの重要な COBOL コードが存在し、他方では COBOL のノウハウの数が減少しているため、IT の世界で自分の道を歩み始めて、勉強してインターンするための相対的な安全な仕事を探している人を推薦することは、実際には理にかなっています。コボルで！

どう思いますか ？

入力ファイルには次のようなレコードがあります: 8712351,8712353,8712353,8712354,8712356,8712352,8712355

COBOLを使用して、上記のファイルから重複を削除し、出力ファイルに書き込む必要があります。レコードを読み取り、出力ファイルに書き込む単純なロジックを作成しました。

上記のファイルから重複 (たとえば、8712353、8712352) を削除するロジックをどこに置く必要がありますか?

プログラムロジックは次のとおりです。

tnput ファイルを次のように昇順で並べ替えました。

8712351,8712353,8712353,8712354,8712356,8712352,8712355,8712352,8712355

そしてそれはうまくいきました、そして以下は修正されたコードです：

しかし、ファイルが昇順でも降順でもない場合、重複を削除する前にソート ロジックを記述する必要があるとします。これについて以下のコードを更新するにはどうすればよいですか? 私が試したように、入力ファイル構造が次のような場合、これを行うことに成功しませんでした:

8712351,8712353,8712353,8712354,8712356,8712352,8712355,8712352,8712355

RijndaelManaged を使用して .net で暗号化された cobol の文字列を復号化する方法を探しています。私はアルゴリズムを制御できるので、Rijdnael である必要はありませんが、データが暗号化されていることを確認する必要があるだけです。

ヘルプアドバイスをいただければ幸いです。

ありがとうショーン

[編集] - データは、作成した ac# Windows サービスで暗​​号化されます。データは、tcpip を介して Windows サービスからデータを取得する COBOL システムによって復号化する必要があります。暗号化アルゴリズムは (Windows サービスで) 変更でき、cobol で復号化できる限り、Rijndael である必要はありません。

Oracle の長さ 16 の PIC S9 に相当するものは何ですか? タイムスタンプを保存するために必要です。

私はまだ、cobol-Projects を含むプロジェクトで cobol コンパイラの必要性を排除しようとしています。

次のビルド動作を作成することは可能ですか:

構成がデバッグの場合は、ExCobol.cblproj で ProjectReferences を使用します。構成が DebugVB の場合は、ExCobol.dll で FileReferences を使用します。

はいの場合、それを達成する方法は?

プロジェクトファイルでタグを使用するとうまくいくと思います。

そして、これは DebugVB 構成のための COBOL コンパイラーの必要性を本当になくしますか?

IO ファイルが存在しない場合に IO ファイルを開こうとした場合に cobol がスローする例外をキャッチし、新しいファイルを作成する方法を知っている人はいますか?