そもそも既存はどんなロジック？ COBOL使う必要あったの？ Javaとかじゃダメだったの？ まとめ TLを見てると以下の記事が少し話題になってました。 tech.nikkeibp.co.jp tech.nikkeibp.co.jp 対象の記事は有料会員じゃないと見れないのだけど事例としては以下みたい。 リソース - ユーザー事例 - COBOL製品 ユーザー事例 : マイクロフォーカス さて、この記事の驚きポイントは「１億レコードくらいのDB処理をCOBOL + Windowsサーバに変える事で性能を維持しつつコストを1/5くらいにした」という事でしょう。 「せっかく7割もあったCOBOLに変えるとか時代に逆行しすぎ！」
SAStruts＋DBFluteでの開発が終わり、またCOBOLで書かれたシステムの保守が始まる・・・。 あぁ、楽しかったSAStruts、楽しかったDBFlute、楽しかったJava。 ということで、この辺りで一度、COBOLから学んだことについてまとめてみようと思う。 僕が今、主にかかわっているシステムはクライアント側がVB(Windows)、サーバ側がCOBOL(UNIX)で出来ている。そして更にバックボーンには、メインフレームが構えている。メインフレーム側の構成は主にPL/1＋JCLで、もちろんDBは階層型だ。 そんなシステムを２年近く保守してきた中で気付いたことを書いて行こうと思う。 カプセル化やスコープの重要性 今更何を言っているのかと思う方もいると思うけど、マジなんだ。僕が初めて学んだ言語はC言語でそれからC++、Javaと続き、その後LL言語にも手を出し始めた。C++を始め
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
