COBOL で組まれたシステムのデータに関して

質問

8年程前に組まれた、COBOLベースのシステムからデータを抽出したくて困っています。

データの実体は、見つけておりそれがバイナリデータである事までは確認出来ています。
そのデータを変換して、データの中身を確認したいのです。

バイナリデータ⇒16進数データ(.hex)にまでは変換出来たのですが、
それ以降、どうすれば良いのかがわかりません。

別途、COBOLプログラムを組んでデータを抽出する事も考えましたが、
COBOLの知識が皆無で、それをやるのは最終手段だと考えています。

仮に上記のような要件を満たす為に他にどのような情報が必要かもよく分かりませんので、
その辺も含めて教えて頂ければと思います。

回答No.13

kinta03

＃１２です。
マタマタ記述間違いが有りました。

　　　　05　郵便番号-R１　　REDEFINES　　郵便番号.
　　　　　　　　　　　　　　　　　　　　　　　　↓↓
　　　　05　郵便番号-R１　　REDEFINES　　郵便番号１.
と
　　　　05　郵便番号-R２　　REDEFINES　　郵便番号.
　　　　　　　　　　　　　　　　　　　　　　　　↓↓
　　　　05　郵便番号-R２　　REDEFINES　　郵便番号２.
です。御免なさい。

回答No.12

kinta03

お疲れ様です。
COBOLのレコード定義(COPY句用)の解析の参考に成ればと思い簡単な解説をしておきます。

01　KNJ-REC.
　　03　KNJ01000.
　　　　05　KNJ01010　　　　PIC X(04).
　　　　05　KNJ01020　　　　PIC X(02).
　　　　05　KNJ01030　　　　PIC X(02).
　　03　KNJ02000.
　　　　05　KNJ02010　　　　PIC 9(04).
　　　　05　KNJ02020　　　　PIC 9(02).
　　　　05　KNJ02030　　　　PIC 9(02).
　　03　FILLER　　　　　PIC X(02).

の様に「01,03,05」と番号が付いているのはデータ構造のツリーを表しています。
「01,02,03」でも良いのですがツリーの変更をする時に番号を一個ずつズラス必要が有るので大抵ひとつ飛ばしで番号を振って行きます。
このツリーがrecord-setの様なものです。

ちなみに「PIC X(nn)」はTextを表しています。nnは桁数です。
漢字専用などの時は N(nn)とかK(nn) などと表現する場合もあります。

実際のデータは↓の様な形で入っています。
+----+--+--+----+--+--+--+
|XXXX|XX|XX|9999|99|99|XX|
+----+--+--+----+--+--+--+
これを全部ひとくくりにしたrecord-setがKNJ-RECになります。
このKNJ-RECの中にまたrecord-setが存在します、それがKNJ01000やKNJ02000になります。
このrecord-setの構造は
KNJ01000
+----+--+--+
|XXXX|XX|XX|
+----+--+--+
KNJ02000
+----+--+--+
|9999|99|99|
+----+--+--+
となります。
record-setの様な物には「PIC なになに」が続いていません。
「01,03,05」に続くのが変数名になります（KNJ-RECもKNJ01000もKNJ01010も全て変数名として利用します）
変数名を付けない「名無しの権平」も有ります「FILLER」がそうです。予備などに使用します。

簡単なレコード記述を日本語で記述してみます。
01　個人情報レコード.
　　03　氏名.
　　　　05　氏　　　　　　　PIC X(10).
　　　　05　名　　　　　　　PIC X(10).
　　03　住所　　OCCURS　2.
　　　　05　郵便番号　　　　PIC 9(07).
　　　　05　郵便番号-R　　REDEFINES　　郵便番号.
　　　　　　07　郵便番号上　　　PIC 9(03).
　　　　　　07　郵便番号下　　　PIC 9(04).
　　　　05　都道府県市町村　PIC X(20).
　　　　05　町名番地　　　　PIC 9(20).
　　03　生年月日.
　　　　05　西暦　　　　　　PIC 9(04).
　　　　05　月　　　　　　　PIC 9(02).
　　　　05　日　　　　　　　PIC 9(02).
　　03　性別　　　　　　PIC 9(01).

大体レコードの構造が解ると思います。
ここで見慣れない「REDEFINES」が出てきたと思います。これは郵便番号を７桁の数字で宣言しているのを更に３桁と４桁でも扱えるように再定義しています。「郵便番号-R」は後で説明する「FILLER」でもかまいません。
さらに見慣れない「OCCURS」が出てきたと思います。これは配列宣言で住所(1)と住所(2)が有ると宣言しています。
住所のrecord-setが配列になっています。住所の要素である郵便番号や郵便番号上や郵便番号下も(1)や(2)を付けて参照します。
書き換えると
　　03　住所１.
　　　　05　郵便番号１　　　　PIC 9(07).
　　　　05　郵便番号-R１　　REDEFINES　　郵便番号.
　　　　　　07　郵便番号上１　　　PIC 9(03).
　　　　　　07　郵便番号下１　　　PIC 9(04).
　　　　05　都道府県市町村１　PIC X(20).
　　　　05　町名番地１　　　　PIC 9(20).
　　03　住所２.
　　　　05　郵便番号２　　　　PIC 9(07).
　　　　05　郵便番号-R２　　REDEFINES　　郵便番号.
　　　　　　07　郵便番号上２　　　PIC 9(03).
　　　　　　07　郵便番号下２　　　PIC 9(04).
　　　　05　都道府県市町村２　PIC X(20).
　　　　05　町名番地２　　　　PIC 9(20).
と、同じに成りますが配列にしたほうがスマートになる場合もあります。

前回の説明と今回の説明でレコード定義(COPY句用)とdata-dumpで大よその分析が出来ると思います。

（注意）ファイル・システムに付いて
DOSやWinのCOBOLで使用しているファイルは
索引ファイル　　　(ORGANIZATION IS INDEX)
相対ファイル　　　(ORGANIZATION IS RELATIVE)
固定長の順ファイル(ORGANIZATION IS SEQUENTIAL)
可変長の順ファイル(ORGANIZATION IS LINE SEQUENTIAL)
などが有ります。これは「SELECT句」の所に書いてあります。
順ファイの二つには問題が有りませんが索引や相対ファイには注意が必要です。

相対ファイはレコードの削除フラグが追加されている場合が有ります。
dumpを見るときには注意してください。

索引ファイルは索引部とデータ部が１ファイルに成っている事が有ります。
この場合dumpで索引部とデータ部を注意深く切り分けて下さい。
また、これにも削除フラグが有ります。大抵は索引部とデータ部の両方に持っています。
データのリカバリー時などデータ部だけを見てリカバリーを行うものが多かったのでデータ部にも削除フラグが無いと無効なデータまで拾うからです。
「DATA-FILE.IDX」と「DATA-FILE.DAT」の様に索引部とデータ部が２ファイルに成っている物もあります。
この場合は索引部とデータ部の切り分けの手間は有りませんが削除フラグには注意して下さい。

以上、最終手段のCOBOLを使わない方向で数回説明をしてきました。
あとは、ご健闘をお祈りします。
なおソース類も見つかった様ですので、後はコンパイラーが有るかも探して見て下さい。
そうすれば最終手段でCOBOLの書ける人を連れてきてエディタで見れるように変換してもらえますので。

回答No.11

kinta03

＃１０です。
一つ訂正が有ります。

＞「SIGN-EBCDIC」の場合は"{ABCDEFGHI"や"}JKLMNOPQR"を
＞元のEBCDICのままで0xC0～0xC9や0xD0～0xD9のコードで使います。
＞データをホストから移すとき変換可能文字のみ変換して
＞それ以外をそのままで移行した場合などコレが多いです。

と、しましたが最後の２行は無視して下さい。

＞「SIGN-EBCDIC」の場合は"{ABCDEFGHI"や"}JKLMNOPQR"を
＞元のEBCDICのままで0xC0～0xC9や0xD0～0xD9のコードで使います。

のみ、見てください。

「SIGN-EBCDIC」もたまに使います。
数年前に新サーバーに移行した某県庁の人事給与システムでもUNIXサーバー上で何故か「SIGN-EBCDIC」になっていました。
以前のCOBOLコンパイラーがデフォルトで「SIGN-EBCDIC」を使う仕様に為っていたせいだと思いますが。移行作業中にデータの化けが発生してdumpを見て気付きました。
この時はトアル問題があってNECの新サーバーでNECコンパイラーが使えずコンパイラーもMF-COBOLに変えたのでCOBOL.DIRの設定がして無くて（って言うか担当者が解っていなかった）自分がCOBOL.DIRの雛形を作りました。
って、余計な話ですね！？

回答No.10

kinta03

お疲れ様です。
Win系で稼動中の様ですので文字コードはEBCDICはマズ有りません。
以前PC用(DOS/Win)にEBCDICが扱えるCOBOLコンパイラーを探したのですが見つけられませんでした。
よっぽどのコンパイラーで無い限り有り得ません(有ってもIBM-EBCDIC漢字のみの対応でしょう)。

今回は、COBOLでの数値表現に付いて簡単に説明します。

元々のCOBOLが実装されたのはEBCDIC系だったので
EBCDICでの表現とそれをASCIIにした場合での表現を記載します。
ASCIIと言ってもPCなどで当たり前の８bit文字コード(半角カタカナ含む)と
読み替えて考えて下さい。

ここでEBCDICにおける次の30個の文字を頭に置いてください。
　　"0123456789"は0xF0～0xF9で表現します。
　　"{ABCDEFGHI"は0xC0～0xC9で表現します。
　　"}JKLMNOPQR"は0xD0～0xD9で表現します。
１番目の0xF0～0xF9はサイン無し又はプラスで使用
２番目の0xC0～0xC9はプラスでサインの桁に使用
３番目の0xD0～0xD9はマイナスでサインの桁に使用

サイン付きの場合は一番下の桁にサインをつける事が一般的ですが
たまに一番上に付けるコンパイラーも有ります。

サインの種類もASCIIの場合「SIGN-ASCII」と「SIGN-EBCDIC」が有ります。
「SIGN-ASCII」の場合は"{ABCDEFGHI"や"}JKLMNOPQR"を
EBCDIC→ASCIIに変換したASCIIコードが入ります。
　　"{ABCDEFGHI"は0x7B,0x41～0x49。
　　"}JKLMNOPQR"は0x7D,0x4A～0x52。
パックド10進数(後述)などを含まない場合EBCDIC→ASCII変換で
そのままデータが移せるのでコレが多いです。
また、データをtext-dumpして見た時にEBCDICもASCIIも同じに見えるので
ホスト系(EBCDIC)から移った人などはコレが多いです。

「SIGN-EBCDIC」の場合は"{ABCDEFGHI"や"}JKLMNOPQR"を
元のEBCDICのままで0xC0～0xC9や0xD0～0xD9のコードで使います。
データをホストから移すとき変換可能文字のみ変換して
それ以外をそのままで移行した場合などコレが多いです。

レコード記述の例。
03　ATAI1　PIC 9(5).　　　　　(5)は桁数
03　ATAI2　PIC S9(5).　　　　 Sはサイン付き
03　ATAI3　PIC 9(5)　COMP-3.　単にCOMPと書く
03　ATAI4　PIC S9(5)　COMP-3.　　コンパイラーも有る

上記４パターン(５桁)に値が格納されたと、想定します。

１．ATAI1はサイン無しの値。５BYTEで格納
　EBCDICで12345は
　　格納文字　1,2,3,4,5
　　hex-code　F1,F2,F3,F4,F5
　ASCIIで12345は
　　格納文字　1,2,3,4,5
　　hex-code　31,32,33,34,35

２．ATAI2はサイン付きの値。５BYTEで格納
　EBCDICで+12345は
　　格納文字　1,2,3,4,E
　　hex-code　F1,F2,F3,F4,C5
　　　又は
　　格納文字　1,2,3,4,5
　　hex-code　F1,F2,F3,F4,F5
　ASCIIでは+12345は
　　格納文字　1,2,3,4,E
　　hex-code　31,32,33,34,45　　SIGN-ASCII
　　格納文字　1,2,3,4,ナ
　　hex-code　31,32,33,34,C5　　SIGN-EBCDIC
　　　又は
　　格納文字　1,2,3,4,5
　　hex-code　31,32,33,34,35
　EBCDICで-12345は
　　格納文字　1,2,3,4,N
　　hex-code　F1,F2,F3,F4,D5
　ASCIIでは-12345は
　　格納文字　1,2,3,4,N
　　hex-code　31,32,33,34,4E　　SIGN-ASCII
　　格納文字　1,2,3,4,ユ
　　hex-code　31,32,33,34,D5　　SIGN-EBCDIC

３．ATAI3はサイン無しの値。３BYTEで格納(パックド10進数)
　EBCDICで12345は
　　hex-code　12,34,F5
　ASCIIでは12345は
　　hex-code　12,34,35
　(注)６桁の場合は４BYTEに格納されます
　　123456だったら
　　hex-code　01,23,45,F6
　　hex-code　01,23,45,36
　　の様に。

４．ATAI4はサイン付きの値。３BYTEで格納(パックド10進数)
　　（注）パックド10進数はSIGN-EBCDICが多い
　EBCDICで+12345は
　　hex-code　12,34,C5
　　　又は
　　hex-code　12,34,F5
　ASCIIでは+12345は
　　hex-code　12,34,45　　SIGN-ASCII
　　hex-code　12,34,C5　　SIGN-EBCDIC
　　　又は
　　hex-code　12,34,35
　EBCDICで-12345は
　　hex-code　12,34,D5
　ASCIIでは-12345は
　　hex-code　12,34,4E　　SIGN-ASCII
　　hex-code　12,34,D5　　SIGN-EBCDIC

以上、簡単に書いてみました。
参考にでもなれば幸いです。
オブザーバーの方々、突っ込みヨロシク！！

回答No.9

IDii24

おそらくEBCDICのファイルだと思いますよ。WindowsでEBCDICを格納するDBなんか使うとは思えないし、COBOLのプログラムを移植して、コストもかかるからEBCDIC形式はそのままのプログラムにしてファイルで書き込んでるだけでしょう。
でも変換ソフトだと読めるものと読めないものもありますので、一概にEBCDIC変換では読めないかもしれません。とりあえずASCII変換ソフトで試し読み。ダメならEBCDICコード表をつかって変換PGを自分で作成して見る事だと思います。
でも他の質問にもありますが、フォーマットも知らないのでは無理では？
もともとオフコンなどで動いていたのを移植したか？

回答No.8

wormhole

>フォーマットと言うのは、やはりコンパイラによる変換方式の違いみたいなものなのでしょうか？

バイナリデータの
何バイト～何バイトが文字列
何バイト～何バイトが整数値
何バイト～何バイトが実数値
などバイナリデータの構造の事です。
他の回答者がいわれてるファイルレイアウトやデータ定義書と同じ事です。

>汎用機は経験がなく、アプリケーションもC#でwindowsアプリケーション組んだぐらいしか経験ないので、いまいちわからないんです(汗)

汎用機の経験は関係ないです。
最悪、COBOLのソースからフォーマットを調べる事になりますが
もしそれもないとなると調べるのは困難です(暗号を解くようなもんです)。

>>２．COBOLコンパイラーは何？
>これがわかりません。ネットで調べてみても情報がないのですが、

あなたの会社で開発したもしくはどこかの会社に開発を依頼した業務アプリケーションの実行ファイルがどのコンパイラでコンパイルされてるかどうかなんて情報がネットに転がってるわけないでしょ・・・

補足

>他の回答者がいわれてるファイルレイアウトやデータ定義書と同じ事です

RDBで言うところのテーブル定義書という事ですね。仕様書の類は一切存在しないようです。

>あなたの会社で開発したもしくはどこかの会社
>に開発を依頼した業務アプリケーションの実行ファイルがどのコンパイラで
>コンパイルされてるかどうかなんて情報がネットに転がってるわけないでしょ・・・

大丈夫です。そんな情報がネットに転がっていない事ぐらいわかっていますので。
コンパイラの種別を既存アプリケーションもしくは、ソースから調べる方法がないかどうか
ネットで探した結果そのような情報に行きつけていないということです。
誤解を招く記載で申し訳ありません。

回答No.7

TreatMeGently

８年前に組み込んだ会社にコンタクトを取って設計仕様書か何かを頂くのが良いかと思われます。
　８年前というと２００５年ですので、その時にメインフレームからＷｉｎｄｏｗｓへ移植されたと思います。又は昔一度ＤＯＳへ移植されて、２００５年にＷｉｎｄｏｗｓへ移植されたと思います。
　８年前に新規作成ならデータベースが発達していましたのでもうＣＯＢＯＬは使いません。ＣＯＢＯＬで作られたデータだからＣＯＢＯＬで代々クロスコンパイルして移植してきたと考えるのが妥当です。

　従って、８年前に移植した会社にコンタクトを取らないと何も分かりません。
　ファイル設計書かＣＯＢＯＬのソースプログラムが無いと無理ですね。
　ファイルの構成仕様書もファイルアクセスの手順（ソース）もどちらも不明では難しいですね。
　年号も今年が昭和８８年で運用している可能性も有りませんか。？

補足

>８年前に組み込んだ会社にコンタクトを取って設計仕様書か何かを頂くのが良いかと思われます。

可能であればそのようにしたいのですが、クライアントの意向では難しそうです。

>８年前というと２００５年ですので、
>その時にメインフレームからＷｉｎｄｏｗｓへ移植されたと思います。
>又は昔一度ＤＯＳへ移植されて、２００５年にＷｉｎｄｏｗｓへ移植されたと思います。

クライアントが発注した先が、個人のプログラマ様で汎用機関連の仕事をされていたらしく、
細かな経緯はわかりませんが、その方の経験からCOBOLを選択されたらしいです。

>８年前に新規作成ならデータベースが発達していましたのでもうＣＯＢＯＬは使いません。
>ＣＯＢＯＬで作られたデータだからＣＯＢＯＬで代々クロスコンパイルして移植してきたと
>考えるのが妥当です。

>従って、８年前に移植した会社にコンタクトを取らないと何も分かりません。

そうですね。自分も移植性等を考えると同じ選択をすると思いますが、
製作者とはコンタクトが取れず（クラインとの意向で）真相はわかりません。

>ファイルの構成仕様書もファイルアクセスの手順（ソース）もどちらも不明では難しいですね。

そうですか。回答ありがとうございます。

>年号も今年が昭和８８年で運用している可能性も有りませんか。？

ちょっとご質問の意図がわからないのですが、運用上西暦扱いで特にそのような問題はなさそうです。

回答No.6

kinta03

＃４です。

＞XPで動作しています
そうなるとShift-JISの漢字コードですかね？

＞COBOLコンパイラーは
COBOLで作成された「.EXE」をDUMPして見て下さい。
どこぞにメーカー名とかバージョンらしき物が混ざっていればラッキーです。

＞仕様書と呼べるものはまったくありません
＞システムの『copy』ディレクトリにそれらしいファイル
そのファイルがレコード定義のインクルード(COPY句)ファイルだと思います。
このような↓記述ファイルが有りませんか？
１．ファイル定義記述
　　　　　 SELECT　SYA-MAST　　ASSIGN　　　　　　　　　TO　SYA-NAME
　　　　　　　　　　　　　　　 ORGANIZATION　　　　　　IS　INDEXED
　　　　　　　　　　　　　　　 ACCESS MODE　　　　　　 IS　DYNAMIC
　　　　　　　　　　　　　　　 RECORD KEY　　　　　　　IS　SYA01000
　　　　　　　　　　　　　　　 ALTERNATE RECORD KEY　　IS
　　　　　　　　　　　　　　　　　　　　　　　 SYA-AK1 =　 SYA06000
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 SYA01000
　　　　　　　　　　　　　　　 FILE STATUS　　　　　　 IS　FST-SYA.
２．レコード定義記述
　　　 FD　SYA-MAST
　　　　　 LABEL RECORD　　　　IS　STANDARD.
　　　 01　SYA-REC.
　　　　　 03　SYA01000　　　　PIC X(06).
　　　*　　　　~~~~~~~~社員番号
　　　　　 03　SYA02000　　　　PIC N(07).
　　　*　　　　~~~~~~~~社員名
　　　　　 03　SYA03000.
　　　*　　　　~~~~~~~~各種　区分コード
　　　　　　　 05　SYA03010　　　　PIC X(01).
　　　*　　　　　　~~~~~~~~稼働人時集計区分
　　　　　　　 05　SYA03020　　　　PIC X(01).
　　　*　　　　　　~~~~~~~~身分区分
　　　　　　　 05　SYA03030　　　　PIC X(01).
　　　*　　　　　　~~~~~~~~月給区分
　　　　　　　 05　SYA03040　　　　PIC X(01).
　　　*　　　　　　~~~~~~~~月中途入社区分
　　　　　 03　SYA04000.
　　　*　　　　~~~~~~~~配属期間
　　　　　　　 05　SYA04010　　　　PIC 9(08).
　　　*　　　　　　~~~~~~~~配属開始
　　　　　　　 05　SYA04020　　　　PIC 9(08).
　　　*　　　　　　~~~~~~~~配属終了
　　　　　 03　SYA05000.
　　　*　　　　~~~~~~~~契約時間
　　　　　　　 05　SYA05010　　　　PIC 9(01).
　　　*　　　　　　~~~~~~~~契約時間フラグ
　　　　　　　 05　SYA05020.
　　　*　　　　　　~~~~~~~~契約時間帯
　　　　　　　　　 07　SYA05021　　　　PIC 9(04).
　　　*　　　　　　　　~~~~~~~~開始時間
　　　　　　　　　 07　SYA05022　　　　PIC 9(04).
　　　*　　　　　　　　~~~~~~~~終了時間
　　　　　　　 05　SYA05030.
　　　*　　　　　　~~~~~~~~契約休憩時間帯
　　　　　　　　　 07　SYA05031　　　　PIC 9(04).
　　　*　　　　　　　　~~~~~~~~開始時間
　　　　　　　　　 07　SYA05032　　　　PIC 9(04).
　　　*　　　　　　　　~~~~~~~~終了時間
　　　　　 03　SYA06000　　　　PIC 9(02).
　　　*　　　　~~~~~~~~社員表示順(グループ)コード
　　　　　 03　SYA07000　　　　PIC X(01).
　　　*　　　　~~~~~~~~店長／担任フラグ
　　　*----
　　　　　 03　　　FILLER　　　PIC X(04).

上記、レイアウトが崩れるので全角スパースに変換してます。それでもズレてしまうけど・・・
このようなファイルが無いか確認してみて下さい。

補足

補足遅れて申し訳ないです。
まさに仰られているデータがあったので確認しておりました。

>そうなるとShift-JISの漢字コードですかね？

だと思います。バイナリエディタで確認するとShift_jisコードで内容が確認出来るので
そうだと予想しています。

>COBOLで作成された「.EXE」をDUMPして見て下さい。
>どこぞにメーカー名とかバージョンらしき物が混ざっていればラッキーです。

確認出来ませんでした。少し見ただけなのでもう少し時間を掛けて確認してみます。

>そのファイルがレコード定義のインクルード(COPY句)ファイルだと思います。
>このような↓記述ファイルが有りませんか？

まさに仰られるファイルがありました。
それぞれのファイルコメントに何のデータを保持しているのかのコメントはあるのですが、
それぞれの項目に関しては、明確な記述がありません。

> 07　SYA05032　　　　PIC 9(04).

コード 識別ID バイト数
といった感じですかね？読み方は調べれば分かることなので、少し調べて解析してみようと
思います。

確認に時間を取ってしまい、補足が遅くなり申し訳御座いません。

回答No.5

notnot

COBOLかどうかはあまり関係なくて、そのファイルのレイアウトドキュメントが必要です。
無いと無理です。あれば簡単です。

補足

そうですか。回答ありがとうございます。

回答No.4

kinta03

お疲れ様です。
COBOLですか・・・
自分の知ってる範囲でも現役で動いてますね。

COBOLではバイナリ・データに当たるのはパックドデシマルですが
コンパイラーによっては純粋なバイナリを扱える物も有ります。

COBOLを使わない方向で言うと
次の点を確認し補足してください。

１．動作環境は？
　　ホスト系／オフコン系／UNIX系／Windows系／その他
２．COBOLコンパイラーは何？
　　文字コードやシフトイン／シフトアウトの扱いが変わります。
　　例えば同じEBCDICでもNEC,富士通,IBMで拡張文字のマッピングが異なる
　　数値データのサインの扱いも変わります。
　　インデック／リラティブ・ファイルの構造が違います。
　　レコードの削除方法も違います（削除フラグなど）
３．ファイル（レコード）定義書の有り／無し？
　　公開して頂ければ変換方法などの参考にできます。

稼動中のCOBOLコンパイル環境が有れば
COBOLの出来る人を頼んでファイルを
変換してもらった法が一番良いと思います。
データDUMPを解析するより間違いが有りません。

補足

ご質問頂いた内容を分かる範囲で補足します。

>１．動作環境は？
Windows　系です。現在は、XPで動作しています。

>２．COBOLコンパイラーは何？
これがわかりません。ネットで調べてみても情報がないのですが、
コンパイル済み。もしくは、システム内の『source』ディレクトリのファイルを参照して
わかるもんなのでしょうか？

>３．ファイル（レコード）定義書の有り／無し？
無いです。とにかく仕様書と呼べるものはまったくありません。
システムの『copy』ディレクトリにそれらしいファイルはあるのですが・・。