アカウント名:
パスワード:
COBOLの数値って、十進数が直接扱えて必要な精度を指定できるから金計算向けだとはいいますけどね。 でも言語仕様としてはCOMP-1, COMP-2, COMP-3, COMP-4, COMP-5なんて謎の処理系というかハードウェア依存な形式がまかりとおっていて互換性は低いしわけわかんないよね。
この東京海上日動システムズの稲葉茂 取締役のおっしゃることに関してはさ、
このため同社は部品化とシステム構成のシンプル化に最も重きを置く。「COBOLはそれを最も実現しやすいと実証している。なぜなら5つのロジックと10の命令文で当社は30年間システムを保守できているからだ。
モデルはベテラン中心にCOBOLで開発していく
「開発1年・保守10年」
COBOLの将来はまだまだ明るい
「25年の間,システムの利用範囲は外に外にと広がっていった。そのたびに改修を加え,システムは本館の横に別館を建て増し,それを渡り廊下でつなぐような複雑な構造になった。保険商品も保険料の支払い方法もどんどん増え,それに伴いシステムは複雑さを増した」という。ビジネス面でこれらをお客様目線で見直し,シンプルにわかりやすくするのが,今回の抜本改革だ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
COMP-5 (スコア:3, 興味深い)
COBOLの数値って、十進数が直接扱えて必要な精度を指定できるから金計算向けだとはいいますけどね。
でも言語仕様としてはCOMP-1, COMP-2, COMP-3, COMP-4, COMP-5なんて謎の処理系というかハードウェア依存な形式がまかりとおっていて互換性は低いしわけわかんないよね。
この東京海上日動システムズの稲葉茂 取締役のおっしゃることに関してはさ、
ってのは、結局その会社のローカルコーディングルールを厳密に定めてごく狭い範囲の機能・パターンしか使用しないことに限定することでシステムをシンプルにして保守性やモジュールの流用可能性を確保したってことだよね。 それって言語の問題ではないと思う。 強いて言語に関係ある点をあげれば、その言語の持っている機能が貧弱すぎるか、もしくはその言語をフルに使いこなしたがる技術者がいないってことかな。 これは Java や C++ では確かに無理だわ。みな好きに書きたがる。 COBOLが主流だった時代はコンパイルどころかパンチの前にコードレビューするのも普通だったからそれでよかったんだろうし、今となっても からそれで済んでいるんだよね。 でも、この体制で開発したんじゃ なんてできるのかな。大いに疑問。 なんて、この人の話を信じる限りはありえないでしょ。 せいぜい限定用途では生き延びていく、くらいかな。この人の場合はサラリーマン人生そのものがその限定用途の中にすっぽりおさまっちゃってるからそれでいいのかもしれんけどね。 まあ、 って、要はリファクタリングをもって抜本改革なんて呼んじゃっているわけだし。本末転倒 (スコア:0)
ここでいう抜本改革って経営のレイヤーでのことを指してるんでしょ。経営での改革を実行する手段として、システムレベルでリファクタリングで済ませればそれにこしたことはないはず。「システム屋が見てスゴイのがかならずしも経営者が見て役に立つものじゃない」だよね。
Re: (スコア:0)
クライアント(親会社)の経営レベルの抜本改革が発生したら、この人の言っているようなリファクタリング程度じゃすまないでしょ。 まずシステム子会社なんてもんは切り離す(独立採算化)くらいのことは起きるわね。
Re: (スコア:0)
自分は4~5社のマシンのCOBOLを扱いましたが1ByteのBit数から違う
某社以外はCOBOL同士での互換性がありましたよ。
ただUNIXサーバーのCOBOLのマニュアルを見ましたが
その辺りのコンパイラの実装は怪しげでしたね。
(標準の規格を満たしていない部分があった記憶が有る)
互換性が怪しいのはどっちかっていうとファイルの入出力以外の
I/O関係でしょう。通信関連とか画面への入出力は先ず
互換性はないですし
Re: (スコア:0)
4~5社って、メインフレームの本家1社(米国)と、本家との互換性が売り物の国産2社と
ワードのビット数が違う米国1社と、そこの会社に買われてしまった米国1社と
ワードのビット数が違う複数のアーキテクチャを持ってる国産1社と
ミニコンの雄といわれた米国1社のあたりですか?
「互換機」2社が本家と互換があってビット数の違うアーキテクチャがそれぞれ互換がなくてだったらそんなに意外じゃないですが
それよりも状況はよいってことですか?
わたしが経験し
Re: (スコア:0)
両方をやっています。
でCOMPの互換性ですが本来COBOLはソースから見える
変数はメモリー上どう持つかまで決まっているはずなので互換性が
内のはコンパイラが標準じゃ無いだけな機がします。
UNIXのCOBOLは僕も数回扱いましたが数値が有る桁数を
超えたらREALに変換とかかなりヤバい実装があったのでCOBOLとして
ソース互換以外は危ういと思っています