COBOL vs Java 2戦目

1 ：06/09/13 〜 最終レス ：11/12/23

前スレです。
ttp://pc8.2ch.net/test/read.cgi/tech/1068819212/

2 ：

に

3 ：

このスレはjavaを冒涜してるのか
それともCOBOLを高く評価してるのか

4 ：

>>3
前スレを見る限り、COBOLの信頼性、汎用性、保守性を高く評価しつつ、
2007年問題に代表されるCOBOLER技術者激減を見据え、
COBOLからJavaに移行したらいいではないか、という提案をする
どちらかというとCOBOLマンセー者と、それに対するJava房と、
ときたま乱入するVagenとかCSPとかVisualAgeforJavaとかの房とは
なぜだかたまにWeb2.0とかはてながどうとかこうとかという話題の出る
ある種雑多な話題を扱う激熱スレです。

5 ：

>>3
未来なきJavaなど冒涜する気にもならない。

6 ：

>>5
おまいの未来無き人生に乾杯

7 ：

>>6
Javaばかり信奉していてもろくなことにはならない。
大事なことは、OOPやUMLなど本質を抑えること。
Javaがいいだの悪いだの、言語で騒いでも仕方ない。
結局、もっと優れた言語が現れればJavaも消えるし、
プロジェクトによっては既に言語が既定になっていることもあるだろう。
大事なのは目と本質。

8 ：

つうかそろそろ言語なんかどうでも良いんじゃね

9 ：

COBOL.JVM

10 ：

メインフレームでもJavaが採用され始めています
50年後には各自ちゅにCOBOLは死滅します

11 ：

javaは5年後に死滅

12 ：

jCOBOL

13 ：

俺はCOBOLの時代が来ると見ている。
開発の二大潮流は.NETとJavaだと俺は見ている。
それぞれの特徴は下記のとおり。
.NET：マルチ言語（C#、VB.NET、J#、C++/CLI、COBOL.NETなど）、シングルOS（Windows系のみが一般的）
Java：シングル言語（Javaのみ。当然だが）、マルチOS（JVM搭載すればOSは問わない）
ここで重要なのが.NETの場合、多彩な言語に対応しており、
開発者の得意な言語が使用できる、という特徴がある。
この場合、COBOLやCSPに馴染み深い開発者は、COBOL.NETで開発できるという
メリットが発生する。
しかし、JVMで動作するプログラムを作るには、COBOLでは不可能であり
Javaを覚えるしかない。
つまり、団塊の世代（所謂「COBOLの波を浴びた世代」）にとって、
Javaを初歩から覚えなくとも、COBOL.NETを使用すれば
それほどストレスなく開発できるのだ。
今後の.NETの普及が拡大するにつれ、このメリットは等比級数的に増大すると
我々は睨んでいる。

14 ：

Sun と MS は和解しているから、将来的に .Net で Java が動かないとも限らないのだが。

15 ：

仮に Sun が .Net で Java を動くようにしなかったとしても、
フリーの実装が出てこないとも限らないわけだが。

16 ：

>>14-15
つJ#

17 ：

>>13
つうかいまさら団塊の世代を労働者に回すよりも
消費者に回ってもらった方が世の中的にメリットが多いから早いところ引退させろってのが時代の流れ

18 ：

電光超特急コボリアン

19 ：

>>17
将来ある若人をCOBOLerにしても何も問題ないのではないか。
COBOLのニーズがあるなら、団塊の世代以外を技術者にしたてあげるのも
ひとつの方法だ。
それに、今の時代は生産者と消費者が同一であり、
ある場面では生産者、ある場面では消費者、というふうに
二面性を持っている（いわばポストモダンの「消費は美徳」）ので、段階の世代を労働者に回すからといって
それすなわちNOT消費者であるとはいえないと思う。

20 ：

帳票系はCOBOLが向いてるし、フロント処理はJavaが向いている。
両方使えばいんじゃね。
どっちも業務向き言語である事だし。

21 ：

>>16
アッチョンブリケ

22 ：

>>20
やっとまともで前向きな議論が。

23 ：

帳票って言語ってよりサードパーティ製のツール（ショボいとこだとExcel）で
なんとかするイメージが強いんだが
COBOLが帳票に向いているってのは、どの辺の事を言っているのかな。
歴史が長いからツールが充実しているって事なのかな。

24 ：

>>23
俺が去年仕事してた大企業では、実際にフロント処理はJavaで、帳票はCOBOLでやってた。
その前に仕事した金融系でも、全国の顧客への通知書はCOBOLでやってた。
EXCELとかで帳票も作ってたが社内の担当者向け。
逆に聞きたいのだが、全国規模の大企業クラスで顧客向け帳票をJavaとサードパーティ製のツールだけでやってる所ってあるの？

25 ：

いや、実はあんまり帳票系やったことないんだ（笑）
ただ、COBOLの優れているってのは何なのかな〜て思っただけで。
金融だと地銀をやったことあるけど、そこはExcelのテンプレート用意して、
サーバサイドでガリガリやってダウンロードっていう、あんまカッコよくない奴だったよ。
全国規模で言えば某メーカー系をやったことあるけど、
そこはVB.NET＋クリスタルレポートだった。
帳票だす端末は限られているとはいえ、せっかくのリッチクライアントなのにクライアントにインスコかよって思ったのは秘密だ。
Webで一番スマートなやりかたってなんなんだろうね。
やっぱPDFに落とすのかな？

26 ：

漏れの某地銀で仕事していて、M菱系の営業にだまされたっぽい
ふぁいぶりっじとか言うﾂｶｴﾈｰ電子化帳票な配布ｼｽﾃﾑ(なんだろうか?)
を使っているのをみた。
データの作成はPL1かCOBOLっぽかったが。
内心ではノーツがあるならそのインフラ使えばいいのに…。
と思う漏れがいた。

27 ：

>>25
＞Webで一番スマートなやりかたってなんなんだろうね。
＞やっぱPDFに落とすのかな？
スマートかどうかは知らんけど漏れは印刷用Web画面をタマに
用意しとくけど。
そこから印刷orPDFにするのはユーザー任せ

28 ：

帳票が向いてるつうよりあのでかい印刷機をぶん回せるからだろ
最近の奴らは見た事無いのかも知れないが高速プリンタとか言う
激早のラインプリンタを使えるのは汎用機位な物だ
1時間で数千頁位は出力出来るんじゃなかった？

29 ：

漏れは旧型の洗濯機と区別がつかないラインプリンタは見たこと
あるなぁ。印刷音もすざまじいモノがあったが。
ｲﾝﾀｰﾌｪｲｽもﾂｲﾝﾅｯｸｽとかいう今は亡き接続方だったような。
現役の部署もあると思うけど。
CanonのレーザープリンタにはIBMの5577(だったかなぁ）の
ｴﾐｭﾚｰｼｮﾝｶｰﾄﾞがあるし、Windowsにそういったプリンターの
ｴﾐｭﾚｰﾀｰってあるし、ｾﾞﾛｯｸｽとかにUNIX内蔵のプリンタとかは
汎用機とWindows印刷と混在出来るよ。
ﾘｺｰも同様の事ができたと思う。
今時だと途中で人身御供なPCが１台ほど必要になる場合もあるだろうけど、
ノーマル1P用紙で汎用的な帳票なら使えない事はない。
たぶん、一昔前のクレジットカードの明細用紙みたいな、特殊フォーマットの
帳票なんかがCOBOLで組んであって直すのがﾏﾝﾄﾞｸｾって理由なんじゃないかな。

30 ：

>>29
やりゃあ解るがWindowsでアレに出すと激しく遅い
直接ドライバ書くと汎用機並みに出力できるけどまあそういう事だ

31 ：

さすがにあの手のプリンタにWindowsから直接データ垂れ流す事はないだろう。
psにいったん変換して後はホスト任せだと思ったが。

32 ：

Windowsで出力すると遅いんすね。
IOCAとか使用してもダメなんでしょうね。

33 ：

そっか。
クレジットとかガス、電気、水道、携帯の明細とかだと
毎月毎月、何十万〜何百万（何千万？）枚も刷らなきゃいけなかったりするのか。
こゆ安定したバッチ処理はたしかにCOBOLの得意分野だ。

34 ：

>>33
COBOLじゃなくて汎用機（のプリンタ）の得意分野

35 ：

>>33
つーか、本質的にはCOBOLよりRPGのほうが得意 (環境限定だけどー)

36 ：

まー今時、ラインプリンタならWin用/unix用とかもあるしなー

37 ：

大企業の汎用機で使ってるのはﾗｲﾝﾌﾟﾘﾝﾀじなくて、ﾚｰｻﾞｰﾌﾟﾘﾝﾀだけどな。
小型車ほどあるでっかいやつ。

38 ：

>>35
漏れもRPGの方が得意だと思うが、他の言語(Java,SQL)を知ると
RPGは触りたくなくなる。

39 ：

プリンタと言えば、オフィスプリンタで４万ページ印刷したら32768ページ目から印字不良起こしたのを思い出す。

40 ：

32768ページって、
読み方によっては語呂合わせで
「プリンタみなとまるこのページ」
って読めるしね。
偶然にも。

41 ：

>>40
　　　　　　　　 　　　∧＿∧
　　　　　∧＿∧ 　（´<_ ｀　）　それはひょっとしてギャグでいっているのか？
　　　　 （ ´ _ゝ`）　/　　 ⌒i　
　　　　／　　　＼　 　　　|　|
　　　 /　　 　/￣￣￣￣/　|
　 ＿_(__ﾆつ/　ＦＭＶ　 / .| .|＿＿＿＿
　 　　　 ＼/＿＿＿＿/　（u　⊃
それはＡＡが違うだろう？
　　　　 ＼＼＼
　　　(⌒＼　 ∧＿∧
　　　 ＼ ヽヽ（　´_ゝ`）
　　　　 (mJ　　 　 ⌒＼
　　　　　 ﾉ　∩兄　/ ／
　　　　　（　 | .|∧＿∧ＯＫＯＫ。
　 ／＼丿　|　（　　　 ） 兄者マテ！落ち着けって！
　(___へ＿ノ ゝ＿＿ノ

42 ：

>>38
Java,SQLを知ると、RPGのよさも感じられると思うぞ。

43 ：

RPGのいいトコかー。
ｶﾞﾝｶﾞﾙとパック１０進数エリアに文字を叩き込むとか
文字エリアにパック１０進数を無理に叩き込んで、
コンパイルオプションでエラー無視にしとくと、
エラーが発生しても落ちない無敵のPGMが出来る事か？
いるんだよ…。マジでそういうRPGﾌﾟﾛｸﾞﾗﾏｰ
MONMSGをを全ｷｬﾝｾﾙしてたりさー。

44 ：

PGMは落ちなくてもテーブルに書けるのかと小一時間問い詰めたい

45 ：

>>44
文字化けしっぱなしでもテーブルに出力できるよ。
その後DFUと言うツールでデータ見たり、変更しようと思ったら
「フィールドに不正な値が入っています」とOSに怒られます。
そしたら16進数で直接データを編集できるツールで修正するか、
SQLで強制UPDATEとかしないと復活不可能だったり。
まあ、コレもKEYにﾃﾞﾀﾗﾒな値入れられていたら泣くしかないんだが。

46 ：

なにーRPGってそんな無理が通る仕様だったのか。
EDTFなんかでゴリゴリやるのと変わらんな。

47 ：

まあ、あれは必要は発明の母的な仕様かと。
例えばある機能を追加するのに修正するＰＧＭが２個、物理ファイルが１だとしても、
その物理ファイルを使用しているPGMが１００個あったとしたら
リコンパイル１００個に動作検証１００個しなきゃいけないじゃん。
で、そういう時は物理ファイルに仕込んでいたCOBOLerお得意の無意味なFILLERの
文字エリアにパック１０進数を読み書きする様にPGM修正を行い、
魔法のコンパイルオプションを使えば修正PGM2本だけ、動作検証２本だけ
でミッションクリティカル（ｗ）な業務の変更にも対応可能だ。
orz

48 ：

＠IT（あえて全角）を欠かさず読んでいる森崎さんwでも知らないような単語ばっかりだな。

49 ：

レベルチェック無視ってやつか

50 ：

そおいやRPGのスレってないんだな。
@ITは漏れも興味のある記事読んでいるけど、さすがに
RPGと言うかiSeriesの特有の世界について記事の
かけるエンジニアなんていないだろ。
漏れ自身が会社で唯一iSeriesでWebSphereAppricationServer
いじれる人間だしなぁ。技術的な交流が出来る人って
IBMの中の人しかいないので寂しいんだが（ｗ
iSeriesのエンジニアがいても90%がRPG+CLしか知らんヤツばっかだと思う。

51 ：

@ITにはVAGenすら載ってないので使えねぇなｗ

52 ：

>>51
そもそもそんな言語は使えねぇなｗ

53 ：

原価計算や減価償却などバッチ処理で複雑な計算をさせるならＣＯＢＯＬの方が効率良いのかな。
compute b = d - e.
compute a rounded =　(b / c) * 100.　
divide f into g remainder check digit.　みたいな。
ユーザインターフェースの部分はjavaでやってあげて、夜間のバッチ処理などはcobolとか・・・

54 ：

COBOLerの方は「複雑な計算はCOBOL(RPG)で」とよく言われて、
案件を自分のスタイルにハメようとした人がいたけど、
そのソースみたら別の意味で複雑（ｗ）だっただけだったな。
ユーザーインターフェイスはVBでもなんでもいいんだが、
バッチ処理なんかはSQLでいいよ。

55 ：

>>54
複雑すぎて保守性の悪いSQLはちょっと…。
何事もほどほどに…。

56 ：

SQLは見た目ほど複雑ではないと思う。
グダグダなストアドもタマにみるけどな・・・。

57 ：

帳票処理ってのは、書式付き出力が重要。
Javaは全部streamにしたから、これがない。
で、まだ、ドットプリンタで複写用紙を使っている企業は、COBOLの書式付き出力が必要。
レーザープリンタで処理している企業は、別に必要ないのだが。

58 ：

>>57
もっとちゃんと調べる習慣つけなきゃCOBOLの仕事以外じゃあ通用しないと思うよ。。
煽りじゃなくって。

59 ：

＞ドットプリンタで複写用紙を使っている企業は、COBOLの書式付き出力が必要。
目の前でWindows機(確かVB)でドットプリンタな印刷しているワケだが。
「COBOLが向いている」と言う意見ならともかく、「COBOLが必要」と言う
時点で世間からは相当なDQNと認定されてる可哀相なエンジニアだな。

60 ：

>>57は賞味期限切れですね

61 ：

俺はWinでも帳票処理できるが、ラインプリンタを使っている企業もプログラマも
多いと言いたいだけだよ。COBOLは過去の遺産を生かせるという意味はあるが、
江戸時代の遺産で100年も食っていけると思うSEは時代遅れだろ？
オフコンやらDOSを使っている企業も相当数あると思うがね。ピン折れでドットプリンタ
を買い換えるときにその価格の高さでシステムを乗り換える企業も多い。そんなもんだろ。

62 ：

日本の宅配業者はまだドットプリンタを使って帳票処理をしているが、
米国から輸入するとほとんどレーザプリンタで、処理していることが
わかる。
日本の企業の伝票優先主義が、根底にあると思うよ。

63 ：

それと >COBOLの書式付き出力が必要 とは何の関係が?

64 ：

つーか複写を重要としてるよな

65 ：

別に昔のシステムに関しての話なら、昔は昔の事情があって、
COBOLにラインプリンタとかの仕事が多かった、って意見は
それはそれでいいし、昔のブツを大切に使いつづける姿勢は
それはそれでいいと思うよ。
ただ世間で嫌われているCOBOLerは、そうやって昔のシステムが
リプレースの時期に、妙な意見を言い出すから、ウザいって事だな。
データベースにOracle選択しておいて、開発言語がSQLじゃなくて
COBOLって具合にな。
そして現在の技術を勉強せずにひたすらｸﾀﾞﾗﾈｪ、デスマを
繰り返したりするから始末におえん。
藻前ら索引って知ってるか？って感じだ。

66 ：

ん、、、、COBOLとSQLは一緒に使うもんじゃないの？

67 ：

>>66
確かCOBOLでSAM形式のファイルを作成してそれをOracleにロードしていた。
処理もSAM形式にしてCOBOLで処理していた。
だから、そのチームのエンジニアはOracleで運用・開発していると言っても、
RDBでもなんでもなくて、カラムが200〜300くらいあるデータを送ってくる。
Oracleは単なる詰め物と化していた。
で、COBOLerはありえない重複データを作成するミスがあっても平気で納品してくる。
受け取った漏れの運用・開発システム(DB2)がお約束で主キーの制約に
ひっかかってアベンドしますた。

68 ：

昔バッチ処理のパフォーマンス対応でそんなことやった気ガス。
SQL書くよりなんぼか早かった。
そういや五年くらい前、VB（旧）、Javaとそれぞれバッチを書いたけど、
どっちもパフォーマンスで爆死したな〜ｗ
今はどうなんだろうね、Javaで大量バッチはあまり聞かないけど、
当時よりはだいぶよくなったのかな。
最近は小物（ASPとかPHPばっかり…）しかやってないからわからないや。

69 ：

ほぼ全レコード舐めるような処理は、そりゃCOBOLなりRPGなりの方が早いわ。
SQL通していちいち最適化考えさせるより、開いて頭から逐次処理するだけだし。

70 ：

そーいや、どこぞ素人開発集団はスピードアップの為だろうけど、
AS/400でCPYFコマンドでなくて、OPNQRYコマンドで
ファイルコピーしていたな…。
で、「これでコピー速度が上がります」と自慢していたが、
あのコマンドは一切のエラーチェックをしないので、
お約束で不正なデータを垂れ流しにし、後続処理で10進ｴﾗｰやら
文字コードエラーがドカドカと大量生産していますた。
だから藻前らはSQL(CPYF)でシステムにちゃんとエラーチェックしてもらえと小一時間(ry
>>68
ちなみにそのデータの作成が早くてもOracleへのロード時間で
マイナスなので、全体から見るとパフォーマンス最悪で爆死です。
普通にSQLで処理汁と思いました。

71 ：

COBOLよりCSPの方が生産性もパフォーマンスもいいから
検討した方がいいよ。そんでもって書き換えちゃえ。

72 ：

Java win.

73 ：

団魂世代がいなくなるから、
COBOLできる人が必要になるって、
COBOLやってたやつがいってた。。。
どうなんだ？

74 ：

>>73
今までCOBOLで書かれていたプログラムを
COBOL以外の言語にリプレースする為に
COBOLを知ってる奴がいた方がいい。
そのプロジェクトに要件定義書とか仕様書というのが
存在しないならなおさら。
まー、COBOLしかできん奴とCOBOLもできる奴では
意味合いが違ってくるとｵﾓ。

75 ：

>>71
CSPの方が生産性がいいんですか？
Javaに書き換えた方がいいとの意見もありますが
コストを考えるとVisualCSP（当方あまり詳しくなくあっているか微妙。。。）
にした方がいいとの意見もあり、半信半疑です。。。
そもそも、CSPってメジャーな言語なの？
自分が知らないだけで業界の人からみるとデファクトスタンダードなのかな。。。

76 ：

ttp://blog.exbridge.info/archives/17613657.html
この話どーよ

77 ：

理想の姿だと思う。

78 ：

常識的に考えて、言語がCOBOLのままいくら頑張って最適化してもムダだろ。。

79 ：

TはTで色々とおかしなことやってるがな

80 ：

COBOLって配列とかOCCURSでサイズ決まってるのに、コンパイル時にメモリリークとかチェックしてくれないんだな。。
勝手に古いCOPY句使ってmakeするPGも駄目だが、余分な領域が別の変数の領域を上書きしちゃうのが実行時まで分からないとはorz
昔某交換機の時は、コンパイルするとアドレスは固定割付で、メモリリークは漏れなくコンパイル時にチェックできたのに。

81 ：

　

82 ：

RPGってAS400以外でも使えるの？

83 ：

昔、富士通かNECでも使えたと思うけど、今はないんじゃないか。

84 ：

トヨタ生産方式ならぬトヨタ開発方式と聞いて飛んできました。

85 ：

アベンドってアボートのこと？

86 ：

あぼ〜んの事じゃない？

87 ：

>>85
abnormal endのことだって、去年知った。

88 ：

ABEND = ABNORMAL END だな

89 ：

♪アベンド、アベンド 嬉しいなぁ〜　(^o^)

90 ：

標準語ではアベンドって何ていうの？

91 ：

お前らが言っているのは
「えんぴつ」の方が優れてるぞ！
いや「シャーペン」の方がイイに決まってるだろ！
って言ってるに過ぎないと思われ

92 ：

>>74
なぜ、それを人間がやらなければならない？

93 ：

おっと、間違えて開いてしまった。
こんなスレを素で開くようでは、おしまいである。

94 ：

JavaとCOBOLがリンク出来りゃいくね？

95 ：

>>94
つInterstage。俺はやりたくないけど。

96 ：

JavaとCOBOLは既に共存してるよね
オンラインなんかだと、
ユーザーインターフェースとその周辺：Java
中の処理：COBOL、アセンブラ
バッチでも、
ファイルをコード変換してサーバ側へ：JCLで汎用ツール呼び出し→サーバへ送る
どっちもできればいいんだろうけど、実際そんなに起用な人はそうそういない
「こういうことをJavaでやってほしいんだけど、それって大変？」とか、
「コボルってどこまでやってくれるの？」とか、
お互いに協力し合ってやってると思うけど。
大規模システムはCOBOL→UNIX-COBOLへツールで機械的に変換して、
サーバ上で稼動させるし
アナログ人間の俺はコボラーだけど、別にオープン系の人と対立なんか
しないけど

97 ：

両方できるけど、UIをJavaって選択肢は無いよ。
Java使うくらいならVB6でいんじゃね？
つか、普通にJava使えるってレベルの奴ならCOBOLに
メリットは感じないよ。
ただ、思った以上にJava使える(=ライブラリやフレームワークの知識がある)奴は
少ないってのが現状。

98 ：

UIをJavaってのは、Webアプリってことじゃないの？
俺はむしろ、自称JavaプログラマにCOBOLを使わせたいな。
どうせ業務アプリの殆どが、OOなんて必要ないし。
OO以前に、DBスキーマ見て仰天することも多いが。

99 ：

Javaは周辺技術が多すぎるからな。XML周りだけでも物凄い数のAPIがある。
JAXBのような知ってる奴が使えば大きく生産性をあげるツール＆APIもあっても、
学ぶのを止めたSEには一生気づかれないままとか寂しい運命の機能も多い。
正直、SEとコーダーを必要以上に分離しようとする日本の風習にJavaはあわない。

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 削除依頼 ▲
・　次のスレ
GPGPU#5
awkについて語るスレ $2
WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part12
XNA 質問・相談スレッド 2