まだ某APIに関して調査してないので、某システムで使えるかどうかは謎。

ORCAのアーキテクチャ(言語とデータベース)
http://www.nurs.or.jp/~ogochan/essay/archives/956

要するにそういうことです。そして、同じ危険はあらゆる「わりと便利なもの」が抱えている問題だと。

> OpenCOBOL

これの最初のコードは、私の業務命令で作らせたものです。今は開発者も私も、当時の会社を辞めちゃってるわけですが。

COBOLは仕事で使ったことはないのだけど，COBOLだからどうの，っていうのは本質論じゃないですよね．
こんなのもあるらしいし．

OpenCOBOL
http://www.opencobol.org/

COBOLの言語仕様に馴染まないで読むのも気が重くなる(Pythonと同じくらい)人ですけど、確かにCOBOLがよく使われてたから「負の遺産」なんやろ！的な物が多いですね。
「とにかく動かせ」って感じでずぶずぶのスパゲッティであっても許容されつづけた結果、可読性も移植性もダメダメなコードが蔓延してるという
…一昔前のアセンブラやC、今だとASP.NETやJava、PHPの商業プログラマがハマりやすいあたりと同じ原因の物が（基幹系の事故の原因とか聞いていると）多そうですね。

まぁ、初期の設計段階で練れ！コーディングにかかる時間を多少削ってでもデバッグ工数で取り返せるから！って持論で仕事やって来て（で部下がついてるときは叩き込む）ますけど、いやがられるんですよねorz
日本の電機業界が納期優先で特に下請けの仕事は買い切りが大多数だからしかたないんでしょうけどorz

それCOBOLの責任じゃないです。メインフレーム*ビジネス*の責任。だから、メインフレーム上のオンラインプログラムって、みんな同じ問題を抱えてます。

でも、今時メインフレーム捨てるというつもりなら、Linux上でもWindows上でもエミュレータ動かせばいいって話もあるんですよね。「捨てる」くらいの時代のものだから、そんなpoorな環境でも十分過ぎるくらい高速だし。

メインフレーム上で動いていたTPモニタくらいだったら、いくらでもオープン系で動かせるはずなのに、メーカはそれをやらないんです。不思議ですね。

Rubyは、まだまだなんじゃないんでしょうか？あれをエンタープライズっていうと、安定性、互換性、速度のリスクを覚悟しておくか、しばらく見守るかが普通の選択だと思います。

僕はCOBOLをあんまり使ったことがないので印象で語ってるから間違ってるかもしれないですがｗ

それはCOBOLの問題じゃないですね。あくまでも、「COBOLプログラマ」が「現状のプラットフォーム」にということです。

JavaはSunが頑張ったお陰で、EJBの範囲であれば互換性があるので良いですが、Rubyは互換性の全くないフレームワークがいったいいくつあるのやら… Rubyな人達は簡単に「作り直せばいい」とか言ってくれるけど、「エンタープライズ」なアプリでそれが通るかどうか…

> OOPもできちゃうオープンソースなコンパイラ、実行系があれば

OOPは出来ないけどオープンソースなコンパイラはあります。まぁOOPまで出来る(2002規格を完全実装した)コンパイラなんてのは、世の中に数える程しかないんですが。