2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

COBOL vs Java 2戦目

1 :デフォルトの名無しさん:2006/09/13(水) 22:37:48
前スレです。

ttp://pc8.2ch.net/test/read.cgi/tech/1068819212/

2 :デフォルトの名無しさん:2006/09/13(水) 23:47:12


3 :デフォルトの名無しさん:2006/09/16(土) 21:16:42
このスレはjavaを冒涜してるのか
それともCOBOLを高く評価してるのか

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

5 :デフォルトの名無しさん:2006/09/18(月) 04:22:12
>>3

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

6 :デフォルトの名無しさん:2006/09/18(月) 04:25:52
>>5
おまいの未来無き人生に乾杯

7 :デフォルトの名無しさん:2006/09/18(月) 06:06:59
>>6
Javaばかり信奉していてもろくなことにはならない。
大事なことは、OOPやUMLなど本質を抑えること。
Javaがいいだの悪いだの、言語で騒いでも仕方ない。
結局、もっと優れた言語が現れればJavaも消えるし、
プロジェクトによっては既に言語が既定になっていることもあるだろう。
大事なのは目と本質。

8 :デフォルトの名無しさん:2006/09/18(月) 10:48:52
つうかそろそろ言語なんかどうでも良いんじゃね

9 :デフォルトの名無しさん:2006/09/18(月) 19:47:20
COBOL.JVM

10 :デフォルトの名無しさん:2006/09/19(火) 07:13:51
メインフレームでもJavaが採用され始めています
50年後には各自ちゅにCOBOLは死滅します

11 :デフォルトの名無しさん:2006/09/20(水) 04:56:07
javaは5年後に死滅

12 :デフォルトの名無しさん:2006/09/21(木) 15:56:16
jCOBOL

13 :デフォルトの名無しさん:2006/09/23(土) 04:15:22
俺は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 :デフォルトの名無しさん:2006/09/23(土) 07:40:24
Sun と MS は和解しているから、将来的に .Net で Java が動かないとも限らないのだが。


15 :デフォルトの名無しさん:2006/09/23(土) 07:41:41
仮に Sun が .Net で Java を動くようにしなかったとしても、
フリーの実装が出てこないとも限らないわけだが。


16 :デフォルトの名無しさん:2006/09/23(土) 08:28:11
>>14-15

つJ#

17 :デフォルトの名無しさん:2006/09/23(土) 17:05:59
>>13
つうかいまさら団塊の世代を労働者に回すよりも
消費者に回ってもらった方が世の中的にメリットが多いから早いところ引退させろってのが時代の流れ

18 :デフォルトの名無しさん:2006/09/24(日) 13:16:44
電光超特急コボリアン

19 :デフォルトの名無しさん:2006/09/30(土) 02:19:46
>>17

将来ある若人をCOBOLerにしても何も問題ないのではないか。
COBOLのニーズがあるなら、団塊の世代以外を技術者にしたてあげるのも
ひとつの方法だ。

それに、今の時代は生産者と消費者が同一であり、
ある場面では生産者、ある場面では消費者、というふうに
二面性を持っている(いわばポストモダンの「消費は美徳」)ので、段階の世代を労働者に回すからといって
それすなわちNOT消費者であるとはいえないと思う。

20 :デフォルトの名無しさん:2006/09/30(土) 03:06:05
帳票系はCOBOLが向いてるし、フロント処理はJavaが向いている。
両方使えばいんじゃね。
どっちも業務向き言語である事だし。

21 :デフォルトの名無しさん:2006/09/30(土) 04:40:35
>>16
アッチョンブリケ

22 :デフォルトの名無しさん:2006/09/30(土) 06:17:22
>>20

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

23 :デフォルトの名無しさん:2006/09/30(土) 09:17:44
帳票って言語ってよりサードパーティ製のツール(ショボいとこだとExcel)で
なんとかするイメージが強いんだが
COBOLが帳票に向いているってのは、どの辺の事を言っているのかな。
歴史が長いからツールが充実しているって事なのかな。

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

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

26 :デフォルトの名無しさん:2006/09/30(土) 22:44:21
漏れの某地銀で仕事していて、M菱系の営業にだまされたっぽい
ふぁいぶりっじとか言うツカエネー電子化帳票な配布システム(なんだろうか?)
を使っているのをみた。

データの作成はPL1かCOBOLっぽかったが。

内心ではノーツがあるならそのインフラ使えばいいのに…。
と思う漏れがいた。

27 :デフォルトの名無しさん:2006/09/30(土) 22:53:18
>>25
>Webで一番スマートなやりかたってなんなんだろうね。
>やっぱPDFに落とすのかな?

スマートかどうかは知らんけど漏れは印刷用Web画面をタマに
用意しとくけど。

そこから印刷orPDFにするのはユーザー任せ

28 :デフォルトの名無しさん:2006/10/01(日) 01:44:39
帳票が向いてるつうよりあのでかい印刷機をぶん回せるからだろ
最近の奴らは見た事無いのかも知れないが高速プリンタとか言う
激早のラインプリンタを使えるのは汎用機位な物だ

1時間で数千頁位は出力出来るんじゃなかった?

29 :デフォルトの名無しさん:2006/10/01(日) 07:42:59
漏れは旧型の洗濯機と区別がつかないラインプリンタは見たこと
あるなぁ。印刷音もすざまじいモノがあったが。

インターフェイスもツインナックスとかいう今は亡き接続方だったような。
現役の部署もあると思うけど。

CanonのレーザープリンタにはIBMの5577(だったかなぁ)の
エミュレーションカードがあるし、Windowsにそういったプリンターの
エミュレーターってあるし、ゼロックスとかにUNIX内蔵のプリンタとかは
汎用機とWindows印刷と混在出来るよ。
リコーも同様の事ができたと思う。

今時だと途中で人身御供なPCが1台ほど必要になる場合もあるだろうけど、
ノーマル1P用紙で汎用的な帳票なら使えない事はない。

たぶん、一昔前のクレジットカードの明細用紙みたいな、特殊フォーマットの
帳票なんかがCOBOLで組んであって直すのがマンドクセって理由なんじゃないかな。

30 :デフォルトの名無しさん:2006/10/01(日) 16:11:22
>>29
やりゃあ解るがWindowsでアレに出すと激しく遅い
直接ドライバ書くと汎用機並みに出力できるけどまあそういう事だ

31 :デフォルトの名無しさん:2006/10/01(日) 20:17:46
さすがにあの手のプリンタにWindowsから直接データ垂れ流す事はないだろう。
psにいったん変換して後はホスト任せだと思ったが。

32 :デフォルトの名無しさん:2006/10/01(日) 22:33:58
Windowsで出力すると遅いんすね。
IOCAとか使用してもダメなんでしょうね。

33 :デフォルトの名無しさん:2006/10/03(火) 10:20:46
そっか。
クレジットとかガス、電気、水道、携帯の明細とかだと
毎月毎月、何十万〜何百万(何千万?)枚も刷らなきゃいけなかったりするのか。
こゆ安定したバッチ処理はたしかにCOBOLの得意分野だ。

34 :デフォルトの名無しさん:2006/10/03(火) 10:54:07
>>33
COBOLじゃなくて汎用機(のプリンタ)の得意分野

35 :デフォルトの名無しさん:2006/10/03(火) 11:14:06
>>33
つーか、本質的にはCOBOLよりRPGのほうが得意 (環境限定だけどー)

36 :デフォルトの名無しさん:2006/10/03(火) 11:36:09
まー今時、ラインプリンタならWin用/unix用とかもあるしなー

37 :デフォルトの名無しさん:2006/10/03(火) 13:13:40
大企業の汎用機で使ってるのはラインプリンタじなくて、レーザープリンタだけどな。
小型車ほどあるでっかいやつ。

38 :デフォルトの名無しさん:2006/10/03(火) 20:38:54
>>35
漏れもRPGの方が得意だと思うが、他の言語(Java,SQL)を知ると
RPGは触りたくなくなる。

39 :デフォルトの名無しさん:2006/10/03(火) 23:26:08
プリンタと言えば、オフィスプリンタで4万ページ印刷したら32768ページ目から印字不良起こしたのを思い出す。

40 :デフォルトの名無しさん:2006/10/13(金) 23:26:28
32768ページって、
読み方によっては語呂合わせで
「プリンタみなとまるこのページ」
って読めるしね。
偶然にも。

41 :デフォルトの名無しさん:2006/10/25(水) 01:26:56
>>40
            ∧_∧
     ∧_∧  (´<_ ` ) それはひょっとしてギャグでいっているのか?
     ( ´ _ゝ`) /   ⌒i 
    /   \     | |
    /    / ̄ ̄ ̄ ̄/ |
  __(__ニつ/ FMV  / .| .|____
      \/____/ (u ⊃

それはAAが違うだろう?
     \\\
   (⌒\  ∧_∧
    \ ヽヽ( ´_ゝ`)
     (mJ     ⌒\
      ノ ∩兄 / /
     (  | .|∧_∧OKOK。
  /\丿 | (    ) 兄者マテ!落ち着けって!
 (___へ_ノ ゝ__ノ


42 :デフォルトの名無しさん:2006/10/27(金) 22:57:27
>>38
Java,SQLを知ると、RPGのよさも感じられると思うぞ。

43 :デフォルトの名無しさん:2006/10/27(金) 23:27:55
RPGのいいトコかー。

ガンガルとパック10進数エリアに文字を叩き込むとか
文字エリアにパック10進数を無理に叩き込んで、
コンパイルオプションでエラー無視にしとくと、
エラーが発生しても落ちない無敵のPGMが出来る事か?


いるんだよ…。マジでそういうRPGプログラマー
MONMSGをを全キャンセルしてたりさー。

44 :デフォルトの名無しさん:2006/10/30(月) 11:26:58
PGMは落ちなくてもテーブルに書けるのかと小一時間問い詰めたい

45 :デフォルトの名無しさん:2006/10/30(月) 21:50:01
>>44
文字化けしっぱなしでもテーブルに出力できるよ。

その後DFUと言うツールでデータ見たり、変更しようと思ったら
「フィールドに不正な値が入っています」とOSに怒られます。

そしたら16進数で直接データを編集できるツールで修正するか、
SQLで強制UPDATEとかしないと復活不可能だったり。

まあ、コレもKEYにデタラメな値入れられていたら泣くしかないんだが。

46 :デフォルトの名無しさん:2006/10/31(火) 11:25:59
なにーRPGってそんな無理が通る仕様だったのか。
EDTFなんかでゴリゴリやるのと変わらんな。

47 :デフォルトの名無しさん:2006/10/31(火) 18:51:28
まあ、あれは必要は発明の母的な仕様かと。

例えばある機能を追加するのに修正するPGMが2個、物理ファイルが1だとしても、
その物理ファイルを使用しているPGMが100個あったとしたら
リコンパイル100個に動作検証100個しなきゃいけないじゃん。

で、そういう時は物理ファイルに仕込んでいたCOBOLerお得意の無意味なFILLERの
文字エリアにパック10進数を読み書きする様にPGM修正を行い、
魔法のコンパイルオプションを使えば修正PGM2本だけ、動作検証2本だけ
でミッションクリティカル(w)な業務の変更にも対応可能だ。

orz

48 :デフォルトの名無しさん:2006/11/02(木) 00:24:17
@IT(あえて全角)を欠かさず読んでいる森崎さんwでも知らないような単語ばっかりだな。

49 :デフォルトの名無しさん:2006/11/02(木) 10:10:10
レベルチェック無視ってやつか

50 :デフォルトの名無しさん:2006/11/04(土) 23:17:45
そおいやRPGのスレってないんだな。

@ITは漏れも興味のある記事読んでいるけど、さすがに
RPGと言うかiSeriesの特有の世界について記事の
かけるエンジニアなんていないだろ。

漏れ自身が会社で唯一iSeriesでWebSphereAppricationServer
いじれる人間だしなぁ。技術的な交流が出来る人って
IBMの中の人しかいないので寂しいんだが(w

iSeriesのエンジニアがいても90%がRPG+CLしか知らんヤツばっかだと思う。

51 :デフォルトの名無しさん:2006/11/25(土) 00:22:03
@ITにはVAGenすら載ってないので使えねぇなw

52 :デフォルトの名無しさん:2006/12/23(土) 08:43:03
>>51
そもそもそんな言語は使えねぇなw

53 :デフォルトの名無しさん:2006/12/26(火) 22:55:01
原価計算や減価償却などバッチ処理で複雑な計算をさせるならCOBOLの方が効率良いのかな。
compute b = d - e.
compute a rounded = (b / c) * 100. 
divide f into g remainder check digit. みたいな。
ユーザインターフェースの部分はjavaでやってあげて、夜間のバッチ処理などはcobolとか・・・

54 :デフォルトの名無しさん:2006/12/26(火) 23:09:09
COBOLerの方は「複雑な計算はCOBOL(RPG)で」とよく言われて、
案件を自分のスタイルにハメようとした人がいたけど、
そのソースみたら別の意味で複雑(w)だっただけだったな。

ユーザーインターフェイスはVBでもなんでもいいんだが、
バッチ処理なんかはSQLでいいよ。

55 :デフォルトの名無しさん:2006/12/27(水) 00:30:28
>>54
複雑すぎて保守性の悪いSQLはちょっと…。
何事もほどほどに…。

56 :デフォルトの名無しさん:2006/12/27(水) 00:33:44
SQLは見た目ほど複雑ではないと思う。
グダグダなストアドもタマにみるけどな・・・。

57 :デフォルトの名無しさん:2006/12/27(水) 17:49:19
帳票処理ってのは、書式付き出力が重要。
Javaは全部streamにしたから、これがない。
で、まだ、ドットプリンタで複写用紙を使っている企業は、COBOLの書式付き出力が必要。
レーザープリンタで処理している企業は、別に必要ないのだが。

58 :デフォルトの名無しさん:2006/12/27(水) 23:30:14
>>57
もっとちゃんと調べる習慣つけなきゃCOBOLの仕事以外じゃあ通用しないと思うよ。。
煽りじゃなくって。

59 :デフォルトの名無しさん:2006/12/28(木) 06:57:15
>ドットプリンタで複写用紙を使っている企業は、COBOLの書式付き出力が必要。

目の前でWindows機(確かVB)でドットプリンタな印刷しているワケだが。

「COBOLが向いている」と言う意見ならともかく、「COBOLが必要」と言う
時点で世間からは相当なDQNと認定されてる可哀相なエンジニアだな。

60 :デフォルトの名無しさん:2006/12/28(木) 13:00:05
>>57は賞味期限切れですね

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

62 :57:2006/12/28(木) 15:09:08
日本の宅配業者はまだドットプリンタを使って帳票処理をしているが、
米国から輸入するとほとんどレーザプリンタで、処理していることが
わかる。

日本の企業の伝票優先主義が、根底にあると思うよ。

63 :デフォルトの名無しさん:2006/12/28(木) 15:43:23
それと >COBOLの書式付き出力が必要 とは何の関係が?

64 :デフォルトの名無しさん:2006/12/28(木) 15:43:29
つーか複写を重要としてるよな

65 :デフォルトの名無しさん:2006/12/28(木) 16:03:35
別に昔のシステムに関しての話なら、昔は昔の事情があって、
COBOLにラインプリンタとかの仕事が多かった、って意見は
それはそれでいいし、昔のブツを大切に使いつづける姿勢は
それはそれでいいと思うよ。

ただ世間で嫌われているCOBOLerは、そうやって昔のシステムが
リプレースの時期に、妙な意見を言い出すから、ウザいって事だな。
データベースにOracle選択しておいて、開発言語がSQLじゃなくて
COBOLって具合にな。

そして現在の技術を勉強せずにひたすらクダラネェ、デスマを
繰り返したりするから始末におえん。

藻前ら索引って知ってるか?って感じだ。

66 :デフォルトの名無しさん:2006/12/28(木) 16:07:29
ん、、、、COBOLとSQLは一緒に使うもんじゃないの?

67 :デフォルトの名無しさん:2006/12/28(木) 16:17:51
>>66
確かCOBOLでSAM形式のファイルを作成してそれをOracleにロードしていた。
処理もSAM形式にしてCOBOLで処理していた。
だから、そのチームのエンジニアはOracleで運用・開発していると言っても、
RDBでもなんでもなくて、カラムが200〜300くらいあるデータを送ってくる。
Oracleは単なる詰め物と化していた。

で、COBOLerはありえない重複データを作成するミスがあっても平気で納品してくる。
受け取った漏れの運用・開発システム(DB2)がお約束で主キーの制約に
ひっかかってアベンドしますた。

68 :デフォルトの名無しさん:2006/12/28(木) 23:41:28
昔バッチ処理のパフォーマンス対応でそんなことやった気ガス。
SQL書くよりなんぼか早かった。

そういや五年くらい前、VB(旧)、Javaとそれぞれバッチを書いたけど、
どっちもパフォーマンスで爆死したな〜w

今はどうなんだろうね、Javaで大量バッチはあまり聞かないけど、
当時よりはだいぶよくなったのかな。

最近は小物(ASPとかPHPばっかり…)しかやってないからわからないや。

69 :デフォルトの名無しさん:2006/12/29(金) 10:06:05
ほぼ全レコード舐めるような処理は、そりゃCOBOLなりRPGなりの方が早いわ。
SQL通していちいち最適化考えさせるより、開いて頭から逐次処理するだけだし。

19 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)