アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
簡単だけど難しい方法 (スコア:2, すばらしい洞察)
難点:彼らはCOBOL以外でもCOBOL風コードを書く
# マジでお願いします
Re:簡単だけど難しい方法 (スコア:3, おもしろおかしい)
あるRDBMSを使った環境に移植された元COBOLプログラム。テーブル定義を見ると「data varchar2(1024)」の列が一つだけ。そしてプログラムの側には、その「レコード」を構造体で分割して処理するコードが見つかった。
あぁ、DATA DIVISIONの名残がこんなところに…… orz
Re:簡単だけど難しい方法 (スコア:1)
全件読んでキーブレイクするコード書くんじゃねぇ
Re: (スコア:0)
コントロールブレイクじゃね？ データベースが登場する以前じゃないかと思うけど、
磁気テープ読み取り装置に２本の磁気テープをセットして、両方に記録されたデータを
読みくらべするやつね。 シーケンシャルにテープに記録されたデータのケツまで一度
読み終われば処理が終わってるってやつ。 ランダムアクセスだとテープ巻戻してまた
読み位置探してなんて、テープの読み取り順番待ってる次の人のこと考えなきゃいけな
かった時代の知恵って？
Re: (スコア:0)
一件読んで、保存しといた前のレコードのキーと比べて、違ってたらなんか特別なことするのがブレイク
要するに印刷で最初だけキーを表示したり小計とか計算するやつ
DBならNDBでもRDBでも頭から順に全件読むことはないよな
Re: (スコア:0)
出来ないことが多い人も多いね。ループ内で頻繁にSQLなげてるとかひどすぎるのをよく見る。
結果パフォーマンスが出なくてやりなおしにさせたことが何度もある人は多いと思う。
Re:簡単だけど難しい方法 (スコア:1)
サーバのメモリも16G, 32Gっていう時代ですから、マルチメディアデータ以外は全部オンメモリでも何とか
なったりするんですよね。
まあ、普通ならORマッパーにお任せで、プログラマはそんなの気にしないものかもしれませんが。
Re: (スコア:0)
マウスでクリックだなんだの対話しなくていいからね。 予約系だとオンラインで空席探すとかだから対話できることが必須。
こういうのはバッチじゃだめ。 大砲の弾をドカンと発射したら、最近のミサイルじゃないんだから途中であっち曲がれ、ここ
で落ちろとかできない。 だから、弾道を計算するならバッチがいい、バッチで十分、つまり、対話なしで可、対話のしようも
ないと。 SABRE [wikipedia.org]とENIAC [wikipedia.org]ね。
Re: (スコア:0)
元々、COBOLはシーケンシャルファイルを読んでシーケンシャルファイル（紙でも）に吐き出す言語です。
そこにRDBアクセスを取り込ませたのが混乱の始まりでしょう。
４個５個もの入力ファイルが有って、３個４個の出力ファイルが有る仕様。
COBOL本来の実装スタイルから大きく逸脱しています。
そこを事務系・金計算系というだけで無理やりCOBOLで実装しようとする。
RDBアクセスを伴ったCOBOLコードに保守性を期待するのは無理です。
なにせ、初めのCOBOLコードが最適なコーディングスタイルを失ってるんですから。