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が１台ほど必要になる場合もあるだろうけど、
ノーマル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

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

40 ：デフォルトの名無しさん：2006/10/13(金) 23:26:28

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

41 ：デフォルトの名無しさん：2006/10/25(水) 01:26:56

42 ：デフォルトの名無しさん：2006/10/27(金) 22:57:27

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

43 ：デフォルトの名無しさん：2006/10/27(金) 23:27:55

RPGのいいトコかー。

ｶﾞﾝｶﾞﾙとパック１０進数エリアに文字を叩き込むとか
文字エリアにパック１０進数を無理に叩き込んで、
コンパイルオプションでエラー無視にしとくと、
エラーが発生しても落ちない無敵の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が１００個あったとしたら
リコンパイル１００個に動作検証１００個しなきゃいけないじゃん。

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

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の中の人しかいないので寂しいんだが（ｗ

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

51 ：デフォルトの名無しさん：2006/11/25(土) 00:22:03

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

52 ：デフォルトの名無しさん：2006/12/23(土) 08:43:03

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

53 ：デフォルトの名無しさん：2006/12/26(火) 22:55:01

原価計算や減価償却などバッチ処理で複雑な計算をさせるならＣＯＢＯＬの方が効率良いのかな。
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)で」とよく言われて、
案件を自分のスタイルにハメようとした人がいたけど、
そのソースみたら別の意味で複雑（ｗ）だっただけだったな。

ユーザーインターフェイスは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とそれぞれバッチを書いたけど、
どっちもパフォーマンスで爆死したな～ｗ

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

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

69 ：デフォルトの名無しさん：2006/12/29(金) 10:06:05

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

70 ：デフォルトの名無しさん：2006/12/31(日) 22:44:02

そーいや、どこぞ素人開発集団はスピードアップの為だろうけど、
AS/400でCPYFコマンドでなくて、OPNQRYコマンドで
ファイルコピーしていたな…。

で、「これでコピー速度が上がります」と自慢していたが、
あのコマンドは一切のエラーチェックをしないので、
お約束で不正なデータを垂れ流しにし、後続処理で10進ｴﾗｰやら
文字コードエラーがドカドカと大量生産していますた。

だから藻前らはSQL(CPYF)でシステムにちゃんとエラーチェックしてもらえと小一時間(ry

>>68
ちなみにそのデータの作成が早くてもOracleへのロード時間で
マイナスなので、全体から見るとパフォーマンス最悪で爆死です。
普通にSQLで処理汁と思いました。

71 ：デフォルトの名無しさん：2007/01/13(土) 18:59:51

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

72 ：デフォルトの名無しさん：2007/02/06(火) 20:42:37

Java win.

73 ：デフォルトの名無しさん：2007/02/12(月) 06:31:52

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

どうなんだ？

74 ：デフォルトの名無しさん：2007/02/12(月) 11:23:34

>>73
今までCOBOLで書かれていたプログラムを
COBOL以外の言語にリプレースする為に
COBOLを知ってる奴がいた方がいい。

そのプロジェクトに要件定義書とか仕様書というのが
存在しないならなおさら。

まー、COBOLしかできん奴とCOBOLもできる奴では
意味合いが違ってくるとｵﾓ。

75 ：デフォルトの名無しさん：2007/02/14(水) 02:50:22

>>71

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

76 ：デフォルトの名無しさん：2007/02/18(日) 05:11:43

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

77 ：デフォルトの名無しさん：2007/02/18(日) 10:50:38

理想の姿だと思う。

78 ：デフォルトの名無しさん：2007/02/19(月) 00:31:15

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

79 ：デフォルトの名無しさん：2007/02/20(火) 21:03:11

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

80 ：デフォルトの名無しさん：2007/03/17(土) 00:57:42

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

81 ：デフォルトの名無しさん：2007/04/23(月) 01:51:54

82 ：デフォルトの名無しさん：2007/05/26(土) 05:48:57

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

83 ：デフォルトの名無しさん：2007/05/26(土) 08:54:05

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

84 ：デフォルトの名無しさん：2007/06/01(金) 03:02:03

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

85 ：デフォルトの名無しさん：2007/06/04(月) 00:18:03

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

86 ：デフォルトの名無しさん：2007/06/04(月) 00:18:53

あぼ～んの事じゃない？

87 ：デフォルトの名無しさん：2007/06/04(月) 01:26:22

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

88 ：デフォルトの名無しさん：2007/06/04(月) 05:27:57

ABEND = ABNORMAL END だな

89 ：デフォルトの名無しさん：2007/07/09(月) 10:43:15

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

90 ：デフォルトの名無しさん：2007/08/13(月) 02:08:33

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

91 ：デフォルトの名無しさん：2007/08/13(月) 02:16:28

お前らが言っているのは

「えんぴつ」の方が優れてるぞ！
いや「シャーペン」の方がイイに決まってるだろ！

って言ってるに過ぎないと思われ

92 ：デフォルトの名無しさん：2007/08/13(月) 15:43:18

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

93 ：デフォルトの名無しさん：2007/08/13(月) 17:45:33

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

94 ：デフォルトの名無しさん：2007/08/13(月) 18:39:39

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

95 ：デフォルトの名無しさん：2007/08/14(火) 06:04:14

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

96 ：デフォルトの名無しさん：2007/08/31(金) 00:31:04

JavaとCOBOLは既に共存してるよね

オンラインなんかだと、
ユーザーインターフェースとその周辺：Java
中の処理：COBOL、アセンブラ

バッチでも、
ファイルをコード変換してサーバ側へ：JCLで汎用ツール呼び出し→サーバへ送る

どっちもできればいいんだろうけど、実際そんなに起用な人はそうそういない
「こういうことをJavaでやってほしいんだけど、それって大変？」とか、
「コボルってどこまでやってくれるの？」とか、
お互いに協力し合ってやってると思うけど。

大規模システムはCOBOL→UNIX-COBOLへツールで機械的に変換して、
サーバ上で稼動させるし

アナログ人間の俺はコボラーだけど、別にオープン系の人と対立なんか
しないけど

97 ：デフォルトの名無しさん：2007/08/31(金) 00:42:26

両方できるけど、UIをJavaって選択肢は無いよ。
Java使うくらいならVB6でいんじゃね？

つか、普通にJava使えるってレベルの奴ならCOBOLに
メリットは感じないよ。

ただ、思った以上にJava使える(=ライブラリやフレームワークの知識がある)奴は
少ないってのが現状。

98 ：デフォルトの名無しさん：2007/08/31(金) 00:56:01

UIをJavaってのは、Webアプリってことじゃないの？

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

99 ：デフォルトの名無しさん：2007/08/31(金) 00:58:51

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

正直、SEとコーダーを必要以上に分離しようとする日本の風習にJavaはあわない。

100 ：デフォルトの名無しさん：2007/08/31(金) 01:01:49

>>98
WebアプリをCOBOLと連携って、聞いたことないぞ

101 ：デフォルトの名無しさん：2007/08/31(金) 01:04:37

COBOLerの作るDBスキーマは確かに凄まじい。
海外用にも使うからと品名カラムが１～１０まであったりするし、
スキーマをExcelで書くとA4 1枚に納まらないとか当たり前。
意図した非正規化ってのもあるから、一概には否定できんけど。

102 ：デフォルトの名無しさん：2007/09/01(土) 10:51:24

COBOL→安定して動作し続ける
JAVA→すぐに不具合起こして止まる
こんな印象しかねえや。

103 ：デフォルトの名無しさん：2007/09/02(日) 14:05:19

それは言語の問題じゃなくて言語を扱う人間の問題だろ

104 ：デフォルトの名無しさん：2007/10/15(月) 21:53:40

言語で不具合が起こるってことはほとんどないはずだけどね。
コーディングが悪いとか、結局人間の問題に帰結する。

COBOLのスピードが速いっていうのも、個人的にはあんまり信用していない。
最近のJavaは十分早い。（JavaVM以上のスピード出せるやつはまずいないし）
普通に何も考えないでコーディングしてたら大してスピード変わらないよ。
本当にそんなにスピード追求したければC++にはじめからすべきだと思われ。

むしろ、COBOLのよいところは汎用機とその周辺じゃないのかと。
その辺が使える状況が現在あるって言うのは結構なメリットだと思うけど。

>>98
別にOOである必要はないが、それにかわるようなことを勉強してるよな？
現実のあまりにもひどい問題には通用しないから勉強必要ないって言うのは、
技術者としては貧弱すぎる。他に、いい技術知ってるからそういうのだよね？

105 ：デフォルトの名無しさん：2007/10/31(水) 14:07:17

ＣＯＢＯＬ経験者急募

106 ：デフォルトの名無しさん：2007/11/02(金) 15:39:34

PG出世街道
JavaScrip -> java -> COBOL

107 ：デフォルトの名無しさん：2007/11/02(金) 15:55:59

JavaからCOBOLは無理だな。
経験が足りなすぎる。

108 ：デフォルトの名無しさん：2007/11/05(月) 23:20:47

経験が足り無すぎるって何？

109 ：デフォルトの名無しさん：2007/11/07(水) 13:31:21

>>80
それはリークとは言わないと思う。

あと、コンパイラの責任を大きいか。

110 ：デフォルトの名無しさん：2007/11/25(日) 15:14:50

ここまで読んで１つ言えることは

　　　　COBOL圧勝

111 ：デフォルトの名無しさん：2007/11/30(金) 05:16:23

>>100

VAGenとかCSPを勉強してから出直して来い。

112 ：デフォルトの名無しさん：2007/12/07(金) 23:14:00

いま会社でCOBOLやってるんだけど、他に言語覚えるとしたら何がよい？
将来性とか転職の有利さとかも踏まえて答えてもらえると嬉しい

113 ：デフォルトの名無しさん：2007/12/08(土) 02:03:53

>>112
C#

理由は習得のしやすさ
開発環境によるところが大きいけど

COBOLとC#覚えると不思議とVBが使える特典もある

114 ：デフォルトの名無しさん：2007/12/08(土) 08:49:31

しかし、C#の案件は劇少ない現実があるので転職しやすいかは運があるし、
そもそもCOBOLよりも不思議と仕事の単価が安かったりする。

115 ：112：2007/12/08(土) 09:38:02

>>113 >>114
サンクスです、参考にします
COBOLは儲かるって聞くけいててもいまいち実感なかったけど、
C#とかよりも単価高いんですか、ちょっとやる気がでてきました

116 ：デフォルトの名無しさん：2007/12/08(土) 11:04:41

ただ、この業界で収入を重視するならCOBOLとかC#とかの
問題ではなくてプログラマから脱出しないと、いつまでも底収入のままだけどな。

つか漏れはCOBOLを使っている現場の空気はあんまし好きじゃないな。
あの現場って責任転嫁するプログラマーの比率がズバ抜けて高い希ガス。

単価が高い安いに関してだが、COBOLを使える人材が中年から高齢者ばかりってのも
あるし。

中間管理側からすると「COBOLerは口だけで仕事遅いけど不思議と単価高い」と評価を
受けているケースが多い現実もある。

まー、一般PGMRが月40-60とするとCOBOLerは60-80か。
不当に高いと言えば高いよ。現実的には10-20辺りが妥当だと漏れは思うけど。ｗ

117 ：デフォルトの名無しさん：2007/12/08(土) 11:39:07

そんなテンション下がること言わないでくれよ。。。
まあどっちにしろCOBOLをやりたくてやってるわけじゃないんで
他の言語覚えて選択肢広げようと思います

118 ：デフォルトの名無しさん：2007/12/12(水) 09:03:27

つか、流行ってそうな言語手当たり次第全部覚えればいいじゃん
大した手間じゃなし

119 ：デフォルトの名無しさん：2008/01/10(木) 10:10:40

んだな、主流な言語はほとんど似たようなもんだし

120 ：デフォルトの名無しさん：2008/02/04(月) 04:33:13

塚、ＣＯＢＯＬもＪＡＶＡも考え方変わらないんじゃないの
結局上から下へ処理を実行していくわけだし。

121 ：デフォルトの名無しさん：2008/02/04(月) 06:24:20

並列処理による高速化でバッチ処理もJavaでバッチリ→バグでまくりで運用不可
やっぱりCOBOLでいい。

122 ：デフォルトの名無しさん：2008/02/04(月) 07:33:41

COBOLが動くマシンはそもそも並列処理できるはずだが・・・。

それにJavaを利用してマルチスレッドなバッチ処理って考えるCOBOLerの脳の構造が
イカれていると言う印象だが。

123 ：デフォルトの名無しさん：2008/02/16(土) 10:29:12

みなさんのお知恵をお借りしたいです。m(__ __)m
cobol + ORACLE10gです

下記のような事が可能と言われたのですが、
検証した結果無理でした。
再度、試みますが物理的に可能なんでしょうか？

手順①
INSERT
(COBOLE) PIC 9(09) COMP-3 ⇒ (ORACLE) CHAR 5
※この場合 ORACLE上では正しく表現されない事はOKとします。

手順②次に(上記の手順後)
(ORACLE) CHAR 5 ⇒ (COBOLE) PIC 9(09) COMP-3
この場合、INSERT時のCOBOLで入力した値が
正しく表現されると言われたのですが・・・
本当でしょうか？

検証した時には、
手順①
111111111 ⇒ 11111
手順②
11111 ⇒ 000012345

このように　再取得した値が000012345となり
当初の111111111ではなくなります。

124 ：デフォルトの名無しさん：2008/02/16(土) 22:34:38

マルチしすぎだろ

125 ：デフォルトの名無しさん：2008/05/24(土) 03:57:53

汎用機のCOBOLをAIXに移植したいのですが、
VAGenを使ってC++やJavaに変換するのと、
いちいち手操作で移行するのとどちらが楽ですか？

126 ：デフォルトの名無しさん：2008/06/06(金) 22:45:41

JAVAメインてやってるんですが、COBOLも覚えたいので
何か良いCOBOL本あったら教えてください。

127 ：デフォルトの名無しさん：2008/06/07(土) 00:32:45

>>126
言語経験者の方はコボラー養成ビデオで学習するのが一般的でつ
本ではピンとこないと思いまつ
会社の人にきいてみてくだつぁい
JCLも覚えないといけないのでビデオ学習が一番てっとり早いでつ
みなさんこれで覚えてくれまつよ

128 ：デフォルトの名無しさん：2008/06/08(日) 00:51:47

宗教じゃあるまいに

129 ：デフォルトの名無しさん：2008/06/23(月) 00:20:21

ビデオ、だと・・・？

130 ：デフォルトの名無しさん：2008/06/29(日) 08:45:34

汎用機からUNIXへの移行を考えているのですが
あまりにも大量のＣＯＢＯＬ資源のマイグレーションが発生しそうで
呆然としております。
ＶＡＧｅｎが使えるらしい、と聞いたんですが、本当かいな？

131 ：デフォルトの名無しさん：2008/07/09(水) 23:04:23

今日の日テレのミニ討論で社保庁の厚生年金まで500万件の不明があって、一つの原因に

"regacy program"

のため、と調査した委員が言っていた。regacy program = COBOLなんだろ？

132 ：デフォルトの名無しさん：2008/07/09(水) 23:05:24

COBOLer, 年金返してくれ。

133 ：デフォルトの名無しさん：2008/07/18(金) 15:47:12

>>123

それは内部的な問題ですので、
結果から言うと、無理ですねえ。

ＣＯＢＯＬ　ＰＩＣ　９（０９）ＣＯＭＰ－３　→　ＯＲＡＣＬＥ　ＮＵＭＢＥＲ　９
ＯＲＡＣＬＥ　ＮＵＭＢＥＲ　９　→　ＣＯＢＯＬ　ＰＩＣ９（０９）ＣＯＭＰ－３

だったらうまく行きますよ。

134 ：デフォルトの名無しさん：2008/07/18(金) 15:49:58

>>131

regacy じゃなくて legacy でしょ。

今どきの技術者はＣＯＢＯＬを読めないってことでしょ。
昔のプログラムはスパゲティだから、
構造化プログラミングでスッキリの文化で育った若者には、
読めないんだよ。

135 ：デフォルトの名無しさん：2008/07/18(金) 16:10:24

社保庁の問題は、ＣＯＢＯＬだからと言うのなら、
他のサーバー機を用意して、
(現在は、汎用機でしょ？)
イマドキの言語で作り直しなんかしようとしたら、
とんでもないカネと時間がかかる。
それに、バグも出る。

何年も安定してシステムを運用できるかというと、
それもＣＯＢＯＬより他の言語の方が、手間とカネがかかる。

それは社保庁の職員が言い訳をしているだけ。

136 ：デフォルトの名無しさん：2008/07/19(土) 01:24:07

いまいち意味判らん
最後の一行とそれ以外の間に、
他人向けの説明が欠落してないか？
書いてる時は自分の脳味噌基準で補足しちまうが、
他人にエスパーはできねえのです

137 ：デフォルトの名無しさん：2008/07/19(土) 10:28:11

ＣＯＢＯＬの方がシンプルで用途を特化した言語ですので、
まちがいが起こりにくいんですよ。
Ｌｅｇａｃｙ　Ｐｒｏｇｒａｍだからというのは、
その昔に作られたプログラムが悪いと言っているのです。
確かにそれはＣＯＢＯＬで書かれているのですが、
他の言語で作ったらまちがいは起こらないのかと言ったら、
そんな事は全くありません。
当時、ＣＯＢＯＬ以外の言語を選択していたら、
間違いは起こらなかったかといえば、そうではないはずです。
むしろ、もっとひどい間違いをしていたことでしょう。
ＣＯＢＯＬの方が、用途が特化されていてシンプルだからです。
コンピュータシステムというのは、
作ってしまった後、稼動している間もメンテナンスが必要です。
目的を事務処理に特化したＣＯＢＯＬは、
シンプルなので、メンテナンスに手間もお金も比較的かからないのです。
シンプルでない他の言語だったりすると、
プログラムの事もそうですが、動作環境のことで(その言語が動くコンピュータ本体の設定等のことです)
いろいろトラブルが出て、メンテナンスが大変なんですよ。
ＣＯＢＯＬだから悪いなどと言い出して、
他の環境、言語で作り直しなんかした日には、
とんでもないお金と時間が無駄になってしまいます。
ＣＯＢＯＬは用途、目的を事務処理に特化した言語です。
動作環境も、ほぼ汎用機ということで決まりきっています。
(このへんがトラブルが起こりにくい所以です)
他の環境や言語でやるよりも、まちがいは起こりにくいんですよ。
社保庁の職員の言っていることは、言い訳です。
というか、ここはプログラム板なので・・・。
言わなくても分かってもらえると思って書いたのです。
まだ、わかりにくいですかねえ・・・。
わからない人向けの説明ですので、わかる人のツッコミはごめんなさい。

138 ：デフォルトの名無しさん：2008/07/19(土) 17:43:39

>>137
COBOLが悪い訳じゃない、という点は賛成する。

しかし、これは電波とばしすぎ。
>ＣＯＢＯＬの方がシンプルで用途を特化した言語ですので、
>まちがいが起こりにくいんですよ。

139 ：デフォルトの名無しさん：2008/07/19(土) 17:49:39

そだね。間違えるのは人間だからね。
それは確かに。

それはそうとして、動作環境でトラブルが起こりにくい点は大きいでしょう。

140 ：デフォルトの名無しさん：2008/07/19(土) 18:28:36

別に古いプログラムだからってその点が問題じゃないよね。
テストする時だって、たいてい問題あるのはデータだし。
何万件もデータをおかしくしちゃうようなプログラムっていうのは、
いくらＬｅｇａｃｙ　Ｐｒｏｇｒａｍでも考えにくい。

年金記録が消えちゃうのは、
社保庁の人間がいいかげんな運用をしてるからでしょ。
言い訳をしちゃダメですよね。

141 ：デフォルトの名無しさん：2008/07/19(土) 19:07:09

＞それはそうとして、動作環境でトラブルが起こりにくい点は大きいでしょう。

iSeriesだったらCOBOLもJavaも両方動く。
でJavaの方がデバックやトレースや修正しやすい。

障害の頻度はCOBOLの方が圧倒的に多いです。
動作環境以前にテスト不足だったりデグレだったりで。

動作環境も大切だけど、テストしにくい言語は品質低いのが多いとｵﾓ。

失敗した担当者に事情を聞くと「ソースのここがこうだからココを直せば
問題ないはず。後は俺は知らん」と逆ギレと言うかなんというか、
机上の空論至上主義者が多い。

142 ：デフォルトの名無しさん：2008/07/19(土) 20:07:45

>>139

>動作環境でトラブルが起こりにくい点
こういう視点は大切ですね。　また、他の環境・言語で作り直すなんて
リスク・コストの面から適切でないことが多いと思います。

言いたいのはソフトウェアの品質について。
COBOLで作られたレガシーアプリのソースを読んだことあるが、
変数が全てグローバル変数なんて狂ってるとしか思えなかった。
あれは間違いを誘発する言語だと思う。

最近のCOBOLは違うんでしょうか？

143 ：デフォルトの名無しさん：2008/07/19(土) 20:34:14

>>105 プロが行きますか？

144 ：デフォルトの名無しさん：2008/07/19(土) 20:38:05

ＣＯＢＯＬはハードの維持費がかかる

145 ：デフォルトの名無しさん：2008/07/19(土) 21:03:58

この間、汎用機で開発してテスト費用が一ヶ月で１０００万取られたワケだが、
コストがこれだけかかるなら動作トラブル起きたら発狂モンだと思うけど。

リスク・コスト云々を言い出すとCOBOLerはナニ言ってんだ？って思うが。

#ちなみにテストだからこれでも安くて本番稼動はこの２・３倍ふっかけられる

146 ：デフォルトの名無しさん：2008/07/20(日) 14:55:29

ＣＯＢＯＬはローカル変数は一切使えません。
今でもそうです。
それは慣れの問題なので・・・。

コストは高い分、リスクは少ないでしょう。
そうですよね。
それで動作トラブル起きたら発狂しますよね・・・。

147 ：デフォルトの名無しさん：2008/07/20(日) 15:09:53

じゃぁ、リエントラントなコードとか書けないの？

148 ：デフォルトの名無しさん：2008/07/20(日) 16:25:18

そうですね。だめですねえ。
コンパイルするとき、
リンクって言って、
関数をまるまる取り込みます。
そういう力技で、それは実現します。
実行ファイルには、
関数そのものが個々の実行ファイルごとに、
まるごと取り込まれてるって感じです。
関数の引数と戻り値は、
グローバル変数(しかないんだけど)で、
関数の内部で使うものと同じ名前で
定義しておく必要があります。

149 ：デフォルトの名無しさん：2008/07/22(火) 20:58:16

TextSS

150 ：デフォルトの名無しさん：2008/07/22(火) 23:44:46

グローバル変数しかないって、クラクラしますね。
連中が訳の分からない命名規則を押し付けたがるのは、それが原因ですか。

151 ：デフォルトの名無しさん：2008/07/24(木) 21:46:12

ローカル変数を使う方法も無いではない。
（プログラム自身を入れ子にする）
しかし普及していない。

俺は以前、A4用紙両面刷りで厚さ1cmぐらいの大きいCOBOLの
リストを見たが、真に驚くべきは、1cmのうち7mmぐらいは、
DATA DIVISION、すなわち（グローバル）変数の定義で占められていたことだ！

152 ：デフォルトの名無しさん：2008/07/25(金) 22:42:55

純粋にCOBOL、JAVAを比較して（レガシーアプリなし、新規構築という条件）
COBOLが優れている点ってないのかな。実行速度が速いとか。
今のとこ"vs"って内容になってない気がする。

153 ：デフォルトの名無しさん：2008/07/26(土) 00:12:17

コボルが殿様でJavaは家来

154 ：デフォルトの名無しさん：2008/07/26(土) 10:47:49

>>152
俺が昔やってたCOBOLの業後バッチ処理だと、
DBの内容を全て固定長のシーケンシャルファイルに吐き出して、
入出力すべてシーケンシャルファイルのバッチプログラムを
数十段も連ねて、一番最後にDBにロードして、、、ということやっていた。

今ではJavaで、殆どSQLでDBをいじっちゃうけど、
処理速度で悩まされることが多い。
SQLをチューニングして何とかなる場合は、それでいいんだが、
DBMSの諸々の設定（あるいはバグ）の問題が絡んでくると厄介。

昔は良かったなぁ、と思うことがよくある。
別にJavaだって、シーケンシャルファイル多段処理方式を
作れば出来るだろうが、やっぱり実行速度が遅いし、
固定長レコードのシーケンシャルファイルを扱うプログラムは、
圧倒的にCOBOLが作りやすい。

155 ：デフォルトの名無しさん：2008/07/26(土) 12:50:22

>別にJavaだって、シーケンシャルファイル多段処理方式を
>作れば出来るだろうが、やっぱり実行速度が遅いし、

iSeriesにはそういうクラスがIBMから提供されているワケだが。
まあ、iSeriesの場合、COBOLよりもRPGの方がもっと高速なので、
COBOLが一番使いにくい言語となっているが。
#最速を言い出すとCになるのでアレだが。

そういうのはJavaが早い遅いではなく、「根本的な使い方や設計が間違っている」
だけかと。

SQLを使ったデータベース操作は「少ないリソースで効率的に運用する」のが
主眼にあるのに対してCOBOLとかで固定長レコードを扱う仕組みは
「横長ＤＢ設計、全レコード総なめ、全更新」と言う大味で無駄なリソース使いまくり
の設計思想なんだから、後者の設計思想でJava+SQLは相性悪いだろ。

156 ：デフォルトの名無しさん：2008/07/27(日) 15:18:08

Java＋SQLが悪いんじゃなくって、コボラが設計したテーブル構造が悪いケースが多いな。
いや、設計と言うのは言いすぎか。レガシーのファイル構造をコピーしているだけなんだから。

157 ：154：2008/07/27(日) 17:50:20

なんか　>>155 も >>156　も、
「>>154 が現在関わっているシステムは、昔の愚鈍な化石のようなコボラーが設計した、
しょうもない物で、それをもってJavaの非効率を言うことはできない」
という前提があるんだが、それは違うんだ。
　
例えばテーブルの設計で言うと、俺が今保守しているJava+SQLのシステムは、
正規化をやり過ぎて、何をするにしても、
テーブルを10個ぐらい join しないとまともな仕事ができない。
それで平気でjoin しまくった複雑なSQLが、処理速度を落としている。

主観的には、昔のCOBOLの多段バッチAPなら
5本を組み合わせて行うボリュームの処理を、
たった１つのSQL、１つのAPで行おうとしている感じ。

まぁテーブルの設計の問題もいろいろあるのだろうが、
昔のCOBOLシステムも、今考えれば結構良かったかもしれないなぁ、
という感想を持っている。

あるいは、考え方だけ昔のCOBOL多段方式を応用してもいいかもしれない。
すなわち、今のJava+SQL（長複雑）　APを、３つ位に分割して、
Java+SQL（簡単） + Java+SQL（簡単） + Java+SQL（簡単）
と作り直して実験してみたいなぁ、といつも思っているんだが、
日々の仕事で、そんな余裕はない。

158 ：デフォルトの名無しさん：2008/07/27(日) 19:13:59

>例えばテーブルの設計で言うと、俺が今保守しているJava+SQLのシステムは、
>正規化をやり過ぎて、何をするにしても、
>テーブルを10個ぐらい join しないとまともな仕事ができない。
>それで平気でjoin しまくった複雑なSQLが、処理速度を落としている。
>主観的には、昔のCOBOLの多段バッチAPなら
>5本を組み合わせて行うボリュームの処理を、
>たった１つのSQL、１つのAPで行おうとしている感じ。

漏れ、ABAA～ABB9みたいなテーブル数１０個以上で正規化もクソもない多段バッチ
のCOBOLのプログラム見たことあるけど。
こういう糞設計もCOBOLerが独壇場に感じる。
それにテーブル10個JOINしないと、の件もフカシが入っていると思うが。
本気だとしたら、それこそコボラーかAccessヲタが設計したんだろう。

ちなみに昔の人でもいい設計する人はいる。だからCOBOLと言う言語自体は全否定はしないが
実際に許せるレベルの設計できる人は万分の一程度だろうなぁ。

＞Java+SQL（簡単） + Java+SQL（簡単） + Java+SQL（簡単）
悪いんだが、処理速度の改善策としてこんな悪手を選択するエンジニアが
「COBOLの方式もよい」なんて発言するって事はRDBMSの基礎も
解っていない素人にしか思えん。

159 ：デフォルトの名無しさん：2008/07/29(火) 12:38:11

そうかな。凝るとろくなことないじゃん。

160 ：デフォルトの名無しさん：2008/07/29(火) 12:49:57

単純な処理の組み合わせで作った方が、
障害が起こったとき対処がラクだと思うよ。

161 ：154：2008/07/29(火) 23:04:31

>>158
>それにテーブル10個JOINしないと、の件もフカシが入っていると思うが。

フカシじゃない。遅いSQLを解析するときに、1行あたり単純な論理式一個
（and や or で改行する）に崩すんだが、それで500行になったりする。

>本気だとしたら、それこそコボラーかAccessヲタが設計したんだろう。

「どうせコボラーが作った正規化もクソもない横長テーブルなんだろ」
と言われて、いやそうじゃない、正規化しすぎて細切れになってしまったんだ、
と返答すると、それこそコボラーが設計したんだろうですかそうですか。

>悪いんだが、処理速度の改善策としてこんな悪手を選択するエンジニアが
>「COBOLの方式もよい」なんて発言するって事はRDBMSの基礎も
>解っていない素人にしか思えん。

確かに俺はSQLについてネットでシコシコ調べて市販の参考書買ってきて読んで、
という素人レベルだが、では、この場合の処理速度向上策はどうすべきか？
保守フェーズで、予算もシケている状況なんで、
「テーブル構造の見直し」
なんて夢みたいな話は抜きで。
冗談抜きで>>158に聴きたい。

162 ：デフォルトの名無しさん：2008/07/30(水) 00:23:55

自分が素人と思っているなら金払ってSIerに相談すれば？
漏れも遅いとか言いながらJava+SQLを選択する理由が解らんが。

163 ：デフォルトの名無しさん：2008/07/30(水) 02:39:46

>>161
リアルタイムでの参照は必要？
必要なければ、定期的に参照用テーブルにコピーするという手もある。

10テーブルをjoinしたぐらいでそんなに遅くなるってことは、インデックスが
きちんと設定されてないのかもね。インデックスの追加も無理？

164 ：154：2008/07/30(水) 07:47:12

出勤前にかきこ

>>162
>自分が素人と思っているなら金払ってSIerに相談すれば？

普段仕事出している外注に相談もしていろいろやってるよ。でも効果なし。

>漏れも遅いとか言いながらJava+SQLを選択する理由が解らんが。

なんとなくハイカラだったからじゃないの？
俺は開発の後期から入ってそのまま保守やってるからその辺は知らない。

>>161
>リアルタイムでの参照は必要？
必要なものとそうでないものがある。必要でないものについては、
参照用テーブルあるいはビューを使うというのがやっぱりベターか。

>インデックスが
>きちんと設定されてないのかもね。

お察しの通り。実際、デバッグ環境上でインデックスを一部追加して
"劇的に"速くなったケースもある。
でも、対象テーブルは日中オンラインで頻繁に更新されるものなので、
インデックス追加によるテーブル更新時のオーバーヘッドがどの位のものか、
正直よく分からないので、その方式は却下されちゃったよ。
デバッグ環境で実験することは出来ても、本番環境ではアクセス量が
圧倒的に違うからね。本番で試しにやってみる、ということも出来ないし。
結局、そのケースは俺がSQLをチクチク直して、"まぁまぁ"速くして対応した。

いろいろ考えてくれてありがとう。

165 ：デフォルトの名無しさん：2008/07/30(水) 11:22:50

レガシーからJavaへの移行では、やっぱり苦労しているところが多いみたいだね。

俺は、Enterprise Javaのコンサルもやってるから、そういうのの後始末をやらされることも多いよ。
最初からプロジェクトに入れてくれれば、皆幸せになれるのに、痛い目にあわないと分からないからなぁ。

166 ：デフォルトの名無しさん：2008/07/30(水) 18:33:20

そもそもレガシーからJavaへ移行とか考える方がおかしいと思うが。
あんなん、移行とか考えずに「作り直します」の方向性でやらないとやってられないが。

ただこういう時はレガシーな技術者が壮絶に非協力的なんだよなぁ。

167 ：デフォルトの名無しさん：2008/08/01(金) 18:30:04

移行はメインフレームから、ＵＮＩＸ－ＣＯＢＯＬへの移行の仕事が多いらしいですねえ。
ＵＮＩＸの方がメリットあるのかなあ・・・。どうなんでしょうねえ。

168 ：デフォルトの名無しさん：2008/08/01(金) 18:40:35

Solarisね。Ｆさん案件だと多いね。
俺も、汎用機／オフコンのコストに耐えられなくなったユーザがUNIX／Windowsに移行するのを何回か経験したけど、
まんま移行するならともかく、１からのリライトでCOBOL採用ってのは、今の時期かなりチャレンジャーだと思う。
（ちなみにフロントはVB.netとか、パワービルダとか、ビジネスロジックをCobolで書いたWeb。どれもヤバイべｗ）

169 ：デフォルトの名無しさん：2008/08/01(金) 18:44:38

おお、そういう話が聞きたかったのです。
うわー、そいつはトラブル多そうですね・・・。
ヤバイヤバイｗｗ

170 ：デフォルトの名無しさん：2008/08/01(金) 23:01:41

各社ともマイグレ用のミドルウェアを用意しているようだが、
こんなの使わされる客がかわいそうだ

玉石混淆の石だけが残っているってのが、COBOLer最大の問題点だな

171 ：デフォルトの名無しさん：2008/08/06(水) 22:19:47

COBOLerどもうぜー

技術では勝てないから心理戦かよ

172 ：デフォルトの名無しさん：2008/08/07(木) 14:37:04

どのへんがどう心理なんだよｗｗｗ

173 ：デフォルトの名無しさん：2008/08/08(金) 20:56:47

>>164
流れをちゃんと読んでないでカキコさせて貰う。

JOINが十個以上あるなんてのをJava+SQLで
処理する場合、n+1問題をわざと発生させるような
ソースを書いて、その替わりにCacheをアスペクトするような
格好にすると劇的に早くなる場合があるよ。

ま、データ構造と大きさ次第なんだけどね。

174 ：デフォルトの名無しさん：2008/08/08(金) 22:24:20

「場合があるよ」

非常に技術的な回答だ。

175 ：デフォルトの名無しさん：2008/08/09(土) 00:15:11

DB2とかだと小さいテーブルをオンメモリで処理するとかの機能があるから
変にJavaやCOBOLでアレコレするよりもRDBMSの最適化に任せた方が
いい場合もあるな。ｗ

あとしょーもない結合(1:男,2:女とか)するくらいならSQLのCASE文で済ませたほうが
速い場合がある。と言うか当たり前だけど大抵速いな。

176 ：デフォルトの名無しさん：2008/08/09(土) 08:56:51

死ね

177 ：デフォルトの名無しさん：2008/08/14(木) 19:22:35

会社でCOBOL経験者向けにjavaの勉強会の資料を作らなきゃいけないんだけど、
COBOLは静的変数しか無いのか。
メモリーと、オープン系と汎用機のアーキテクチャの話から入る感じが良さそうだな。
それが分かれば基本手続き指向なので言語的には問題無いのかな。

そういえばcobolでテーブル定義があれなのは、テーブル定義というか
データと表示が密接に関連してるからっぽいね。

178 ：デフォルトの名無しさん：2008/08/14(木) 21:30:20

コボラーに普通のプログラムを勉強させようとするのは酷すぎる
そっとしといてやれ

179 ：デフォルトの名無しさん：2008/08/15(金) 01:25:52

>>177
そんなことしたら、バッケンレコードを更新されるぞ。
面倒でも、構造化から教えてあげないと駄目なんじゃないの？

180 ：デフォルトの名無しさん：2008/08/15(金) 08:33:11

どうせコボル風にしか使えないけどな、あいつら

181 ：デフォルトの名無しさん：2008/08/15(金) 10:12:30

×　あいつら
○　おれら

182 ：デフォルトの名無しさん：2008/08/16(土) 08:06:48

COBOLer向けのJavaの講師をしていたことが有るけど、彼らはメソッドが理解
できない。
以前、真顔で「メソッドって2次入り口点なんですね」と言われたことがある。

プログラムが上から順番じゃなくて、呼ばれた順に実行されるというのも理解
できない。

それに、COBOLにあるのは変数じゃなくてレコードだから・・・変数の概念も
Javaとはだいぶ違うし・・・。

まさに>>178の言う通り。

183 ：デフォルトの名無しさん：2008/08/16(土) 09:00:42

>>182
Javaだからとも云えるな。私は完全なコボラーだったけれど、
30才過ぎてからLispとPrologを難なく覚えた。この二つの言語は
COBOLと似たところが全くなく、かつ単純な構文要素しかないから
素直な初心者として学習できた。Javaだったらそうはいかなかった
に違いない。COBOLの知識から意味を理解しようとしてしまう部分が
少なくないのではないか。学習課題もCOBOLよりはるかに多い。

184 ：デフォルトの名無しさん：2008/08/16(土) 13:57:21

オブジェクト指向って、色々なポイントがあるけどさ、
とりあえず抽象データ型として教えるってことはできんのかな？
要するにカプセル化だけ。
抽象データ型は、普通の手続き型言語とも相性がいいと思うんだけど。

185 ：デフォルトの名無しさん：2008/08/16(土) 21:15:41

なるほどLispとか全然違ってるほうが先入観無くて良いのかな。
確かにメモリ関係とか知らないのにオブジェクト指向分からんとか
言ってるのを見ると納得。

186 ：デフォルトの名無しさん：2008/08/17(日) 11:28:39

>>186
http://imepita.jp/20080726/075540

187 ：デフォルトの名無しさん：2008/08/19(火) 18:28:35

そう？
クラスとかメソッドとか、
要するに人様の作ったもんを使わせてもらうだけの話じゃないの？？

まあ、自分で作る場合もあるかもだけどさ。
単純に、文化の違いだよ。

188 ：デフォルトの名無しさん：2008/08/19(火) 22:20:31

多テーブルJOINは遅いがJOIN不要なテーブルまでJOINしてることがある。

・選択条件だけに使ってるテーブル。
　JOINから外して相関サブクエリ(EXISTS)にした方が良い。
　EXISTSは1件見つけたら処理中止するから速い。
・トランザクションレコードに比べて件数が多いマスタとJOINしてる場合。
　マスタの一部のレコードしか参照しないならスカラサブクエリにした方が速い。
　SELECT句が冗長になるが、EXISTSと合わせ技で30分以上かかってた処理を10秒で終わらせた時がある。

189 ：デフォルトの名無しさん：2008/08/20(水) 10:51:42

なんでテーブルの結合とかする必要があるの？？
トランザクションレコードを用意してるってことは、
更新は夜間とかに一気にやるんだよね。それはいいと思うんだけど。

190 ：デフォルトの名無しさん：2008/08/27(水) 10:20:48

結合なんかやるから遅いんじゃないの？？

191 ：デフォルトの名無しさん：2008/08/27(水) 23:25:12

やらなきゃいけないんだからしょうがないでしょ

192 ：デフォルトの名無しさん：2008/08/27(水) 23:35:40

仕事だもんな・・・ｗ

193 ：デフォルトの名無しさん：2008/08/28(木) 01:05:26

テーブルなんざ参照と更新だけでいいだろ。
なんでやらなきゃいけないのかも答えられないのか。

194 ：デフォルトの名無しさん：2008/08/28(木) 01:54:32

>>193
本気なのか釣りなのかわからんが（以下略）。

195 ：デフォルトの名無しさん：2008/08/28(木) 09:52:05

仕様に疑問があっても、
言われた通りに言われた事だけをやるのか。
テーブル別々に参照すればいいじゃないか。
なんで結合なんかしなきゃいかんのだ。
ＤＢなんだろ？ＣＯＢＯＬとかのファイルじゃないんだろ？？
レコード単位でしか見れないわけじゃないんだろ？
見たい、更新したいフィールドだけ、触ればいいのではないか？？
よけいな事しない方が速いだろ？

196 ：デフォルトの名無しさん：2008/08/29(金) 00:36:17

例えば、
在庫テーブル　　　　（品目コード、数量）　と
品目情報テーブル　（品目コード、名称、単価）

があって、在庫の一覧表（品目コード、名称、在庫額）を作りたい場合、
品目コードをキーに２つのテーブルを結合することを考えないか普通は？

197 ：デフォルトの名無しさん：2008/08/29(金) 09:52:57

そうか。なるほど。

その例の場合、
在庫テーブルと、品目情報テーブルを読み込んで、
在庫の一覧表テーブルを、新しく作れば良くない？？
結合とか、余計な機能使ったら、遅くならないの？？
っていうか、在庫の一覧表テーブルを、新しく作っても遅いじゃん。
最初から、在庫の一覧表テーブルは用意しておいて、
在庫額だけ、数量ｘ単価を（プログラムで）計算して、更新すれば良くない？？

198 ：デフォルトの名無しさん：2008/08/29(金) 12:41:41

>>197
在庫テーブルにはいつ追加、削除があるかもわからない。
在庫一覧テーブルを同時更新したとしても、最終的に、
在庫一覧表を表示する以前に一度は、
在庫一覧テーブルと在庫テーブル、品目情報テーブルの
整合性チェックをしなくてはならない。この事から、
在庫一覧表テーブルを用意しておいた方が速いとは必ずしも
言えない。

199 ：デフォルトの名無しさん：2008/08/29(金) 14:29:36

>>197
> 結合とか、余計な機能使ったら、遅くならないの？？

結合はRDBの基本中の基本なんだが。

頼むから、COBOLの世界から出てこないでくれ。
間違っても、DB設計なんて手を出さないでくれ。
こっちも、そちらの世界には手を出さないから。

200 ：デフォルトの名無しさん：2008/08/29(金) 14:31:34

基幹系の仕事はJavaには回ってこないから問題無い。

201 ：デフォルトの名無しさん：2008/08/29(金) 15:14:05

なるほど。そうだよね。
整合性チェックが必要だよね。

在庫テーブル、
品目情報テーブルを、
在庫一覧表テーブルは最初から用意しておいて、

整合性チェックをした方がいいと思うけどなあ。
在庫テーブルが読めなかったら、
無条件で在庫一覧表テーブルの在庫額には、
０をセットすればいいじゃない。

障害が起こった場合、
追いかけるときにそういう作りにしておく方がいいと思う。
在庫一覧表テーブルは、最初から用意しといた方がいいと俺は思う。
最初から存在するテーブルを更新するだけなんだから、
それで速度が落ちるとも思えないなあ。

ただ、整合性チェックとかは、
プログラムでやらないといけないよね。
プログラムがわからないＤＢ技術者の人は、
そういうのイヤがるのはわかるな。

202 ：デフォルトの名無しさん：2008/08/29(金) 15:59:11

30日、国際標準委員会は、日本代表の意見を採用し、COBOLの名称を

「COMAL」

に変更することにしました。日本語で、hard to handleの意味で、委員全員の
賛成の下、2009年にも、名称変更することになりました。なーんちゃって。

203 ：デフォルトの名無しさん：2008/08/29(金) 16:13:15

>>202
念のため商標登録しておきます。

204 ：デフォルトの名無しさん：2008/08/29(金) 22:17:25

>>202
リアルに茶吹きそうになったじゃまいか。

205 ：デフォルトの名無しさん：2008/08/29(金) 23:57:21

>>201
他にも、
購買契約テーブル（品目コード、購入先メーカーコード、購入年月日、購入数）
輸送契約テーブル（品目コード、輸送元コード、輸送先コード、etc）
日別在庫数遷移テーブル（品目コード、年月日、在庫数）
etc.

があって、それぞれ一覧表を作りたい場合、
購買契約一覧テーブル（略）
輸送契約一覧テーブル（略）
日別在庫数遷移一覧テーブル（略）
etc一覧テーブル（略）

を作るの？それらを全部リアルタイムで更新するの？
購買契約一覧テーブルは、品目名称だけじゃなくて、
購入先メーカー名称も必要だぜ。

206 ：デフォルトの名無しさん：2008/08/30(土) 00:52:13

マスタとトランザクションはきちんと持って、参照用はバッチで作成すれば良いのでは？

207 ：デフォルトの名無しさん：2008/08/30(土) 01:01:42

>ただ、整合性チェックとかは、
>プログラムでやらないといけないよね。
外部キー制約を設定すればいいんじゃない。

208 ：デフォルトの名無しさん：2008/08/30(土) 10:27:34

>>205

＞購買契約一覧テーブル（略）
＞輸送契約一覧テーブル（略）
＞日別在庫数遷移一覧テーブル（略）
＞etc一覧テーブル（略）

＞を作るの？それらを全部リアルタイムで更新するの？

うん。作ればいいじゃん。
そういうめんどくせーのはＰＧ的じゃないという意見もわからなくはないけど、
めんどくせー事をめんどくさがんないでやった方がまちがいが少ないよ。

リアルタイムで更新するかどうかは、データ量によると思うけど・・・。
トランザクションを持っといて、
夜中とかにまとめてバッチ処理してもいいし。
その方が普通かな。

＞購買契約一覧テーブルは、品目名称だけじゃなくて、
＞購入先メーカー名称も必要だぜ。

そんなの購入先メーカーコードをキーにして引っ張ればいいだけでしょ。
また整合性チェックすればいいんだよ。
めんどくさがらないで。

＞外部キー制約を設定すればいいんじゃない。

それもそうだけど、
プログラムで整合性チェックして、読み込めなかった時は、
メッセージ出すとかした方が、運用の人にやさしくない？

209 ：デフォルトの名無しさん：2008/08/30(土) 18:49:39

在庫一覧表を表示する以前に一度は、
>在庫一覧テーブルと在庫テーブル、品目情報テーブルの
>整合性チェックをしなくてはならない。この事から、
>在庫一覧表テーブルを用意しておいた方が速いとは必ずしも
>言えない。

ＳＱＬ文で一発で行えるにしても、
内部的には整合性チェックを行っている。
外部キー制約を設定するにしてもそう。
整合性チェックはプログラムで行い、
最初からテーブルを用意して、更新のみ行う方が速い。
最初から用意されているテーブルを更新するだけの方が速いのは自明の理。

それに、ＳＱＬの機能に頼らないで、
自力でプログラムで整合性チェックを行い、
結果をログやメッセージ等で追いかけられるようにしておけば、
運用、保守の面でも良い。

いろいろ勉強して、試してみたい気持ちをわかる。
それは、好きで仕事をしているんだから、大切な気持ちだ。

だけど、仕事はそうじゃない。

210 ：デフォルトの名無しさん：2008/08/30(土) 19:37:42

　　　　　　　　, -'"´ ￣｀丶､_
　　　　　　　　　 ,.∩　　　　　　　　｀ヽ
　　　　　　　　　〃∪'´￣｀二二人＼　ヽ
　　　　　　　　　| ツ´￣￣￣￣´　ヾヽ.　',
　　　　　　　　　|ﾊ　,ニ、　　,. - ､　| | | l |
　　　　　　　　　| ﾊｨハ　　 ,二ヽ. | | | | |　同じ板にコピペするとそのままだけど、
　　　　　　　　　| | |　じ'　　　|トJ〉　 /)} l | 違う板にコピペすると鬼のような怖い顔
　　　　　　　　　|　ﾊ　､'＿,　￣,,　厶ｲ川|　に変わる摩訶不思議な佳子様コピペ。
　　　　　　　　　l　l /＼　　　 ..　イV＼川 |
　　　　　　　　 ,'　l l　,ｲ｀l￣´ ／　　 /ヽl l
　　　　　　　　 l　| l ハ　`メ､　　　〃　ヽヽ､__ノ
　　　　　　　　 l　 ∨ └‐ｲ「ト--ｧ'´　　　ﾊヽ__ノ
　　　　　　　　　ヽ/　　}　 l」」　/　　　　　/ }`ー
　　　　　　　　　〈_n| 八　　　/ /　　　 /ノ
　　　　　　　　　〈二二人 c /＼/ /　, ｲ
　　　　　　　　　　/　 /厂／＼__>< ｛＿

211 ：デフォルトの名無しさん：2008/08/31(日) 00:13:32

>>209
あんたみたいのがいるから、IT技術者の地位が低下するんだ。
さっさと消えてくれ。

212 ：デフォルトの名無しさん：2008/08/31(日) 10:15:54

>>197
>結合とか、余計な機能使ったら、遅くならないの？？

>>196　の例ならば、たいして遅くならない。
select　
　Z.品目コード,　H.名称,　Z.数量 * H.単価
from
　在庫テーブル Z　left join　品目情報テーブル H
　on
　Z.品目コード = H.品目コード ;

在庫テーブルも品目情報テーブルも、品目コードがプライマリキーであることは明らかだから、結合キーが品目コードだけの上記SQLは十分速い。

>在庫テーブルと、品目情報テーブルを読み込んで、
>在庫の一覧表テーブルを、新しく作れば良くない？？

良くない。そんな事する方が圧倒的に遅い。

誤解しないで欲しいのだが、俺は別にSQL結合マンセーではない。場合によっては、>>197 の主張するとおり、中間的なテーブルを設けて処理する方法もアリだと思う。しかし、>>196 のような単純な例では、
　中間テーブル方式＞＞＞＞ SQLで必要情報を結合して取得する方式
コストを比較すればこうなる。

もし、在庫一覧表出力機能あるいはそれに類する物を設計する機会があるなら、中間テーブル方式にせよ、SQL結合方式にせよ、状況（データ構造、更新頻度、etc）によって適切な方式を選択する必要がある。
しかし、>>197 はどうも、SQLの結合に対して妙な偏見があり、無条件に中間テーブル方式を採用してしまうような気がする。技術者として、その姿勢にはいささか問題があるよ。

213 ：デフォルトの名無しさん：2008/08/31(日) 10:20:55

209の寝言はCOBOLerの妄想癖がよくあらわれていますね。

正直、現代においてはアフォなCOBOLerのつくったプログラムに
どれだけの人間が泣かされているか認識してほしいな。

まともな仕事してからCOBOLerは発言して欲しいな

214 ：デフォルトの名無しさん：2008/08/31(日) 10:44:30

>>212

ちゃんと読んどくれ。
いちいち作ったら遅いよ。そりゃそうだよ。
だから、「最初から作っといてソレを更新する」っていうお話。

それと、ログとかメッセージとか取ろうよっていうお話。
異常終了した時とか、プログラムで落ちた時の状態を取っとけるといいじゃない。

215 ：デフォルトの名無しさん：2008/08/31(日) 10:51:36

最初から作っとけばいいじゃんと言っているのです。
めんどくさいけど。
結合で毎回作るより速いでしょう。
プログラマ的でないと言う意見はわかる。
でも仕事だし。

趣味だったら、いろいろ凝るべきだと思う。

216 ：デフォルトの名無しさん：2008/08/31(日) 11:14:07

ああごめんなさい。作るじゃなくて引っ張るですよね。
＞結合で毎回作るより速いでしょう

俺もちゃんと読もう。

＞しかし、>>197 はどうも、SQLの結合に対して妙な偏見があり、
＞無条件に中間テーブル方式を採用してしまうような気がする。
＞技術者として、その姿勢にはいささか問題があるよ。

最初から結合した結果の項目を持ったＤＢ用意しとけばいいと思うんだけどなあ・・・。
そうだね。しょっちゅうは参照しないから、
いちいちＤＢは作りたくない場合なら、結合の方がいいよね。
でも、頻度が高いのなら、めんどくさいけど最初から作っておいた方がいいと思う。
速度が気になるというお話ですし・・・。頻度は高いのかと。

217 ：212：2008/08/31(日) 12:13:50

>>216

以下2方式を比較してみる。
(a) 検索毎に必要なテーブルを結合しつつselectして、一覧表を出力する
(b) 事前に中間テーブルを作っておいて、それを単純にselectして一覧表を出力する

●比較その１、
「在庫一覧表出力ボタンをクリックしてから、一覧画面なり帳票なりが出力完了するまでの時間」
　(a) ＞ (b)

●比較その２
「一覧表出力以外の部分に要するコスト（在庫更新時のオーバーヘッドなど）」
　(a) ＜ (b)

もし、「在庫一覧表はとにかく最高速で出るようにしてくれ！そのためにオンライン業務の在庫更新などが遅くなっても構わん！」
という業務用件であれば、方式(b)を選ぶべきである。
しかし現実にはそんなことは無い。在庫チェック担当者は、在庫一覧表が速く出る方が良いけれども、在庫の入出庫担当者は、在庫更新業務を速くしてくれ、と言うだろう。

そこで両方式の利点、欠点を秤にかけた上で、
「方式(a)の欠点である、検索時の速度低下は、今回のケースではそれ程でもない。ゆえに、(b)のコストを回避して、方式(a)を採用した方が、全体としてユーザーの満足度は向上する」
というのが>>212での主張である。

中間テーブル作るのが面倒だから(b)を回避するのではない。

218 ：デフォルトの名無しさん：2008/08/31(日) 13:48:26

>>216
在庫テーブルと品目テーブルにトリガを付ければいいんじゃない。

在庫テーブルと品目テーブルにトリガを付けて、
在庫の一覧テーブルを最新の状態に保とう、
ってことと同義でしょ。

219 ：デフォルトの名無しさん：2008/08/31(日) 15:48:18

>>217

>●比較その１、
>「在庫一覧表出力ボタンをクリックしてから、一覧画面なり帳票なりが出力完了するまでの時間」
>　(a) ＞ (b)

最新の状態に常に保たれていれば
ａ＜ｂじゃないかな。

そうですよねえ。
もともとのお話は、かなり処理に時間がかかっているとの事ですので・・・。
トリガを使うと、それはそれでやっぱり遅いかもですよねえ。

そうかといって、バッチ処理だと、
最新の状態は、常に保てないですよね・・・。
（そこが問題だからご指摘いただいてるんですよね）

そうなると、結合を使ったほうが良くなるね。
でも、それだと在庫の一覧テーブルいらないよね。

っていうか、
在庫の一覧テーブルが、
在庫テーブルと品目テーブルの項目を両方網羅してるんだから、
在庫テーブルと品目テーブルそのものがいらないんじゃん？？

そもそも、在庫が０になったら、
在庫テーブルをデリートするもともとの設計が悪いよ。

220 ：デフォルトの名無しさん：2008/08/31(日) 15:55:19

プログラムとか機能で速くしようと努力するより、
設計を見直すべきだと思うよ。

そもそも、結合よりも
在庫の一覧テーブルを作った方がいいと思うのも、
そういう理由だし。

好きで、勉強していろいろやりたいのはわかる。
でも、最近の若い人は、機能がない事をすぐ言い訳にするから、
あんまりＳＱＬとかの機能に頼るのは好かんのだよなあ・・・。
そういうと、若い人からコボラーだとかジジイだとか言われるんだけどさ。

221 ：デフォルトの名無しさん：2008/08/31(日) 18:36:03

RDBの基礎理論が集合論なんだから、それに従って設計・操作するのが当然。
それがいやなら、最初からRDBなんて使わなければ良い。

まずは正しく設計をした上で、性能が出ない部分にadhocな処理を加えるのが筋。
そんな簡単なことが守れないから、コボラーの作るDBは保守不可能となる。

222 ：デフォルトの名無しさん：2008/08/31(日) 18:36:59

RDBの事を知らんor不勉強なCOBOLerが
「SQLの機能に頼るのは好かん」とか
言うのは微妙だけどなー。

基本的にはRDBMSを熟知してから、設計＆実装し
それでも足りない機能があるならプログラムするってのは
わかるけど、COBOLerはRDBをファイルと同程度に
しか認識していないところがウザい。

223 ：デフォルトの名無しさん：2008/08/31(日) 19:47:57

やっぱり言い出したｗｗ
うんうんそうだね
勉強は大切だよ☆

224 ：212：2008/08/31(日) 20:20:49

>>219
>最新の状態に常に保たれていれば
>ａ＜ｂじゃないかな。
？？？

>>●比較その１、
>>「在庫一覧表出力ボタンをクリックしてから、一覧画面なり帳票なりが出力完了するまでの時間」
>>　(a) ＞ (b)
この不等号は、「(a)の方が多くの時間がかかる（遅い）」という意味だぞ。

>っていうか、
>在庫の一覧テーブルが、
>在庫テーブルと品目テーブルの項目を両方網羅してるんだから、
>在庫テーブルと品目テーブルそのものがいらないんじゃん？？

品目情報テーブルをなくしてしまったら、 >>205 の例に挙がっているような、品目を使う全てのテーブルに、必要に応じて名称やら単価やらを持たせる必要がある。
それである日、ある品目の単価が変更になったとしよう。単価あるいは金額を保持する全てのテーブルをそのタイミングで更新する必要がある。
またある日、ある品目の名称が変更になったとしよう。・・・・・（略）・・・

昔、マシンの性能が非力だった時代には、SQLでちょっとでも複雑なことをやろうとするととたんに速度低下をきたしたので、上記のような非正規化の設計にも意義があった。
しかし、今はそんな心配は無い。上記の非正規化設計によって得られるメリット
「検索時に速くなる」
なんてのははっきり言って極小であり、それよりも、デメリット
「更新時の煩雑さ」
の方がはるかに深刻である。

重ねて言うが、俺も、変に凝ってSQLのテクニックに溺れるようなのは問題だと思う。
しかし、更に重ねて言うが、>>212 で挙げたようなSQLは、ぜんぜん凝ってなどいない。ごく基本的、シンプルなSQLだ。これを見て「懲りすぎ、テクニックに溺れている」なんて言うならば技術者として問題だ。

225 ：デフォルトの名無しさん：2008/08/31(日) 23:40:54

>>223
あのさー…。
君の言ってることって、
RDBMSが理解ができない新人のヘリクツ、
って風に映るんだけど。

今まで自分が書いたレスを読んでごらんよ。
とても思慮が浅く、無知であることが分かるでしょう。

すこしは勉強なさい。

226 ：デフォルトの名無しさん：2008/09/01(月) 05:24:41

おそらく『彼』は、正規化もへったくれも無い、項目多量横長テーブルのシステムを
長いこと保守していて、それに誇りを抱いているんだろうな。

俺がいまちょっと関わっているシステムもそんな感じだ。
○○情報
××展開○○情報
△△履歴××展開○○情報
こんな感じのテーブルが腐るほどあり、大きなものだと項目が300近くあり、
しかも改修案件ごとに今でも項目が追加されている。

しかも、「◇◇区分」という項目を取得したい場合、たいがい、
３つぐらいのテーブルがその項目を持っている。
「ほとんどの場合」、その３つのテーブルは、同じ値の「◇◇区分」を持っているが、
処理の流れ、業務の綾によって微妙に異なる場合もあるらしく、
そういう時は、長年たずさわってきた重鎮の人に聞くわけさ。
「その場合は、××展開○○情報から取ってきた方がいいね」

『彼』ならこう言うだろうね。
「それが仕事だろ。趣味じゃないんだから」
「面倒臭がらずに、××展開○○情報とか△△履歴××展開○○情報とか保守すればいいじゃん」

それはやむを得ず行うことであって、決して望ましいことではない、
と『彼』に伝えるにはどうしたらいいだろうか？

227 ：デフォルトの名無しさん：2008/09/01(月) 07:53:08

そんな時のためのマテリアライズドビューですよ
最近のDBMSはハッシュ結合とかできるから結合が結合なしより遅いとは限らない。
寧ろ索引ついてない項目走査すると結局全列物理読出しするからその方が遅くなりうる。

仕事で面倒くさがるのは逆説的だが正しいと思う。
面倒くさいことを機械にやらせるためにシステム屋が存在するのだから。

228 ：デフォルトの名無しさん：2008/09/01(月) 08:50:34

面倒とかいう論点に持ち込むからそうなる

人はミスを犯すという観点から見たら、正規化するのが第一選択肢
そういう視点がないとしたら、システム屋として失格だろ

229 ：デフォルトの名無しさん：2008/09/01(月) 09:59:03

もともとが遅いっていう話で、速くするにはどうすればいい？っていう話だよ。

そうだね。そんなに遅くならないんだったら、
テーブルを分けたほうがいいよね。

ラクするのは客で、システム屋がラクするのはちょっと違うんじゃね？
（今度はどんな事いいだすかな？）

230 ：デフォルトの名無しさん：2008/09/01(月) 10:00:08

ＲＤＢだから、ただの索引付きファイルと違って、
いっぱい機能がつかえるもんね☆

231 ：デフォルトの名無しさん：2008/09/01(月) 10:11:26

>>229
もしかして、この話>>154あたりが起点なの?

232 ：デフォルトの名無しさん：2008/09/01(月) 10:40:37

おお、そこまで遡っては読んでなかったけど、
俺もそう思います☆

やり方がシンプルなほど、まちがいは少ないのです。

233 ：デフォルトの名無しさん：2008/09/01(月) 10:52:16

そして、速い。

234 ：デフォルトの名無しさん：2008/09/01(月) 10:53:20

そして、ごまかしが効かない。

235 ：デフォルトの名無しさん：2008/09/01(月) 10:57:48

＞そんな時のためのマテリアライズドビューですよ
＞最近のDBMSはハッシュ結合とかできるから結合が結合なしより遅いとは限らない。
＞寧ろ索引ついてない項目走査すると結局全列物理読出しするからその方が遅くなりうる。

＞仕事で面倒くさがるのは逆説的だが正しいと思う。
＞面倒くさいことを機械にやらせるためにシステム屋が存在するのだから。

そういう言葉を並べると素人はごまかせるけど、
言ってるコトはスゲーあいまい

ごまかしてはいけない。
あえて、平易な言葉と処理でなんとかするべきなのだ。
お前らみたいのがいるから、
客をだますインチキ商売だと誤解されてしまうのだ。

236 ：デフォルトの名無しさん：2008/09/01(月) 12:11:35

平易なことしか出来ないだけじゃないのか？

237 ：デフォルトの名無しさん：2008/09/01(月) 14:01:24

＞しかし、今はそんな心配は無い。上記の非正規化設計によって得られるメリット
＞「検索時に速くなる」
＞なんてのははっきり言って極小であり、それよりも、デメリット
＞「更新時の煩雑さ」
＞の方がはるかに深刻である。

彼に言わせれば、平易ではなく、煩雑らしいぞ。
品目が違えば、単価も違って当然でしょう。
品目が同じで単価が違うレコードはありえないんだから、
キー項目は、品目だけでしょ。
そんなに煩雑とも思えないけど・・・。

＞昔、マシンの性能が非力だった時代には、SQLでちょっとでも複雑なことをやろうとすると
＞とたんに速度低下をきたしたので、上記のような非正規化の設計にも意義があった。

どうしたら速くなる？っていう話なんだから、その通りだよ。
別に遅くならないんだったら、結合使ったっていいんじゃない。

＞重ねて言うが、俺も、変に凝ってSQLのテクニックに溺れるようなのは問題だと思う。
＞しかし、更に重ねて言うが、>>212 で挙げたようなSQLは、ぜんぜん凝ってなどいない。ごく基本的、シンプルなSQLだ。これを見て「懲りすぎ、テクニックに溺れている」なんて言うならば技術者として問題だ。

テクニックに溺れるのは良くないよ。
それをわかってくれていれば、いいと思うよ。

238 ：デフォルトの名無しさん：2008/09/01(月) 14:05:41

まあ、１行レスなら、突っ込みようがないよな。

一見難しい言葉と、あいまいな表現は、
いくらでも逃げられるからな。
どっちつかずな事を言っておけば、
自分は追及されることがない。
機械はあいまいな事を言われても動かない。

重ねて言う。ごまかしてはいけない。
あえて、平易な言葉と処理でなんとかするべきなのだ。
お前らみたいのがいるから、
インチキ商売だと誤解されてしまうのだ。

239 ：デフォルトの名無しさん：2008/09/01(月) 14:07:06

機械はあいまいな事を言われても動かないんだ。
そっちの方が技術者としてよっぽど問題だよ。

240 ：デフォルトの名無しさん：2008/09/02(火) 00:16:57

COBOL vs Java
両方やった俺が来ましたよ。

素データが x個集まって小隊
小隊が y個集まって中隊
中隊が z個集まって大隊
・・・・
てな風に、あるデータは上位データの構成要素、
という構造のデータを扱う局面に限ればCOBOLの方が書きやすい。
（ただし、上記の例ではx,y,zの値が固定であることが前提。
　可変にしようとするとCOBOLでは無理。たぶん）

241 ：デフォルトの名無しさん：2008/09/02(火) 02:59:04

>>238
皆が言っていることは、
必要としている機能を、
RDBMSが有しているのだからRDBMSの機能を使う。
ということ。
対し君は、
自分で作るべき。
と主張している。

｢既に開発、テストが済んでいる機能｣
と
｢新たに開発、テストを行う機能｣
どちらを採用するか、
という問いに、
皆は｢開発済み｣を選択し、
君は｢新規開発｣を選択している。

君は、
期間を要する方、
バグの危険性の高い方を選択している。

不自然だろ。

242 ：デフォルトの名無しさん：2008/09/02(火) 07:38:45

>>232
>やり方がシンプルなほど、まちがいは少ないのです。

その通り！
大量の非正規化テーブルをこしらえて毎回整合性をとらせるとか、
表示用の中間テーブルをこしらえて毎回整合性をとらせるとか、
そんな仕組みをシコシコ自前で作るより、RDBMSのリレーションの機能を活用して、
シンプルに情報を結合して取った方が、まちがいは少ないのです。

243 ：デフォルトの名無しさん：2008/09/02(火) 10:04:32

>｢既に開発、テストが済んでいる機能｣
>と
>｢新たに開発、テストを行う機能｣
>どちらを採用するか、
>という問いに、
>皆は｢開発済み｣を選択し、
>君は｢新規開発｣を選択している。

>君は、
>期間を要する方、
>バグの危険性の高い方を選択している。

>不自然だろ。

どうしたら速くなるか？っていうお話だよ。
設計を見直すべきだというお話。

この例では、別に複雑ではないが、
継ぎ足し、継ぎ足ししていると、
そのうちに手が入らないシステムになってしまう。
まあ、その方がカネが取れるといえばそうだけど、
そういう技術者ばかりだからダメなんだよ。

設計に良くない部分があるのなら、
早めに見直すべきだ。

何度も言うが、プログラムや機能より、設計。
結合の方が技術者は確かにラクでバグは少ないけど、
面倒くさがってはいけないよ。
その程度でバグ出す心配してるようじゃダメだよ。

244 ：デフォルトの名無しさん：2008/09/02(火) 11:47:30

そんな修正くらいでバグ出す心配するんだったら
なおさら機能に頼るクセなくさないとスキルがあがらないよ。
そんな修正くらいでバグ出す心配するようだったら
意見なんかしちゃダメだよ。

245 ：デフォルトの名無しさん：2008/09/02(火) 17:00:20

１件づつフェッチ（毎回ＳＱＬ投げて）して、昔のファイルシステムみたく１件づつ処理しているとか言うオチじゃないだろうか。

246 ：デフォルトの名無しさん：2008/09/03(水) 01:38:06

>>243

>設計を見直すべきだというお話。
その設計とやらが、
SQLによる複数テーブルの結合によるレコード取得を否定し、
複数テーブルから個別にレコード取得する方式を指し、
外部キーによる整合性の維持を否定し、
プログラムからの整合性チェックを指すならば、
それを設計とは誰も呼ばない。
それはムダと呼ばれ排除する為に皆が努力を重ねている。

それに対し君は、
そのような努力を怠る自らを慰める言い訳を探すかの如く、
皆の考えを否定する。

君は間違っている。

247 ：デフォルトの名無しさん：2008/09/03(水) 01:49:50

性能対策として表結合を使うべきか否かという議論だよね？
ケースバイケースが結論じゃないかな。
コーディング規約守ってると性能出ない時に性能優先する文脈なんだから。
ただ間違いなく「COBOLで全部作る」のは「DBMSの機能を利用する」より性能遅い。
今時のオプティマイザに勝てるコードを書ける人間ならCOBOLやるよりアナゴってるだろ。

248 ：デフォルトの名無しさん：2008/09/03(水) 04:02:36

10テーブル結合、くらいからナナメ読みした。
実行計画は見たのか？

249 ：デフォルトの名無しさん：2008/09/03(水) 10:55:59

別に結合を絶対に使っちゃイカンとは言ってない。
それは212氏とのやりとりで俺は237の書き込みで言っている。

>>246はちゃんと読め。
ちゃんと読んでない上に感情的だ。
最初に２つの表から、１つの表に移行する時に、
プログラムでやって、整合性チェックは必要だけど、
（まあそれも別に結合でやってもいけなくはないけど）
１つの表にしちゃってれば、速いでしょ。

自分たちが機能を使ってラクする事を、
ムダを省くって言ってるだけだろ。

>>247

そりゃ、ケースバイケースだと言われちゃうとなあ。
ＤＢの機能を利用しなきゃいけないようなファイルの持ち方をしていて、
コーディング規約とか、客の要望でどうにも変えられないようなら仕方ない。
そういう場合は、機能を使った方が速いよ。
それはそうとして、
ファイルの持ち方は、よく考えるべきでしょう。
ファイルの持ち方をシンプルにすれば、速くなるはずだよ。

250 ：デフォルトの名無しさん：2008/09/03(水) 10:58:38

＞｢既に開発、テストが済んでいる機能｣
＞と
＞｢新たに開発、テストを行う機能｣
＞どちらを採用するか、
＞という問いに、
＞皆は｢開発済み｣を選択し、
＞君は｢新規開発｣を選択している。

＞君は、
＞期間を要する方、
＞バグの危険性の高い方を選択している。

＞不自然だろ。

コレって、君たちがバカにしている、バカコボラーの発想じゃないの？
それじゃバカにされてもしようがないだろ。

251 ：デフォルトの名無しさん：2008/09/03(水) 11:31:08

まあいいや。
もういじめないよ。
ごめんね☆

252 ：デフォルトの名無しさん：2008/09/03(水) 11:32:57

ちょっと大人げなかった・・・。

253 ：デフォルトの名無しさん：2008/09/03(水) 11:40:40

ビートたけしは死ね

254 ：デフォルトの名無しさん：2008/09/03(水) 12:06:45

COBOLはリファクタリングという概念がなさそう。
まあ比較的新しい（業界的にね）概念だからしょうがないんだけども。

255 ：デフォルトの名無しさん：2008/09/03(水) 12:09:02

>>249
>>１つの表にしちゃってれば、速いでしょ。

なるほど。だからコボラさんの設計したシステムは横長レコードなのか。
これ、テストするときメンドクセーんだよな。

ビューというものはご存知ですかね。

256 ：デフォルトの名無しさん：2008/09/03(水) 16:37:37

>>249
客の要望とかコーディング規約以前に、
マスタと重複する項目をトランザクションに持たせるのは二重管理で冗長。
ジャーナル的に発注時点の情報を残さないといけないデータなら別だが。
(マスタ更新前後の情報を後で帳票に出す必要があるとかね。)
チェック処理とか更新処理とか追加するたびにB/T全体の性能が悪化する。
冗長なファイル設計が原因でジョブの数を最適化できなくて朝までにB/T終わりません
なんて客に言えないだろ？
余計なジョブを作らなくて良いようにB/T設計し、
そのためにテーブル構成も正規化し、
単体PGM内でも馬鹿なSQLを書かないようにする。
そこまで全部やってやっと安定した性能が得られる。
ちなみにこれ全部COBOLの話。

257 ：デフォルトの名無しさん：2008/09/03(水) 23:52:34

>>256

ありがとう。

258 ：デフォルトの名無しさん：2008/09/04(木) 01:08:00

>>249

>プログラムでやって、整合性チェックは必要だけど、
>（まあそれも別に結合でやってもいけなくはないけど）
>１つの表にしちゃってれば、速いでしょ。

検索時に速くなる、という果実に比べて、
整合性チェックを自前で作る必要がある、という対価が大きすぎる。
それにかかる工数はどうするのか？

「いやー、技術者たるもの、DBの機能なんかに頼らずに、
　一生懸命コードを書いて、己の力で整合性を担保すべきなのです！
　そのためにこれだけの工数が余計に必要なのです！
　ご協力願います！」
　
とお客さんに言うの？

>ファイルの持ち方をシンプルにすれば、速くなるはずだよ。

前に出てきた在庫一覧表の例でいうなら、
「在庫テーブルも品目情報テーブルも廃止して、
　在庫一覧テーブルに一本化する」
というのが、君の言う「シンプル」なのかい？

259 ：デフォルトの名無しさん：2008/09/04(木) 08:04:00

>>249

>それはそうとして、
>ファイルの持ち方は、よく考えるべきでしょう。
>ファイルの持ち方をシンプルにすれば、速くなるはずだよ。

・質問１
ここでファイルと呼んでいるのはテーブルとも読み替えていいのか？

・質問２
「シンプル」という響きのいい言葉で、書き手と読み手が
てんでバラバラに違うものをイメージしているかも知れない。
まずは君に、「シンプル」という言葉の定義を【明確に】してもらいたい。
「こういう状態がシンプルで、こういう状態がシンプルでない」
それによって、君の「シンプル」の定義を共有した上で議論したい。

260 ：デフォルトの名無しさん：2008/09/06(土) 12:00:52

なんか必死でageてる人間の意見がバカだって事は解る

261 ：デフォルトの名無しさん：2008/09/06(土) 13:15:47

>>260
そんなことわざわざ書く人の意見も。そういう私も。

262 ：デフォルトの名無しさん：2008/09/06(土) 15:24:17

COBOLは現役バリバリ
ttp://itpro.nikkeibp.co.jp/article/NEWS/20080906/314277/

263 ：デフォルトの名無しさん：2008/09/06(土) 17:05:46

>>262

すばらしい

264 ：デフォルトの名無しさん：2008/09/06(土) 20:47:42

なんつーか、システム全面再構築とかで、
300億、3万人月で旧システムから2000本
流用した。って、ずいぶんとボロい商売だと
言うのは解るけど、それは全面再構築では
なく単にシステム更改のレベルだと思うが。

265 ：デフォルトの名無しさん：2008/09/07(日) 00:12:35

>3年7カ月前に着手した第1次フェーズが終了し，
(中略)
>300億円，3万人月強を投じている。
3年7カ月=43ヶ月
延べ人数:43ヶ月×3万人月=1290,000人
一人当たりの月額:300億円÷1290,000人=23,255.81395円
一ヶ月2万4千円でお釣りが来る？
んーなワキャねーよなー、アハハハ。
それじゃCOBOL屋さんの1人月って幾らなんだよってことになるからな。
ハハハ･･･。

計算間違ってないか、もう一回やってみよ･･･。

266 ：デフォルトの名無しさん：2008/09/07(日) 00:40:26

>>265
人月 = 人*月で
700人 * 43ヶ月 ≒ 30000人月
ってことだよ。

267 ：デフォルトの名無しさん：2008/09/07(日) 01:45:33

うわ、オレ、バカ。
そっかトータル3万人月だよ。
だから一人当たりの月額は100万だ･･･よな。

ところで、
IBMやORACLEのSOA担当に聞いてみたいな。
このケースがSOAなら、
期間がどれくらいになって、
費用がどれくらいになるのか。

268 ：デフォルトの名無しさん：2008/09/07(日) 06:55:00

>>262
ビジネスロジックの書きやすさって何のことを言ってるんだろう？

シンプル化が重要なことには同意するが、COBOL が最も実現しやすいというのは分からないなぁ。

269 ：デフォルトの名無しさん：2008/09/08(月) 00:42:25

COBOLの「シンプル」は学習容易性。
保守容易性は寧ろより短いコードでより複雑なロジックが書ける「シンプル」さに依存すると思う。

270 ：デフォルトの名無しさん：2008/09/08(月) 09:03:58

>>268
ビジネスロジックなら論理型言語などの方が数段書きやすい。
ただ、動的に書き換わる環境などの記述するのには向かないから
あくまで、軽量なスクリプトとして使う。それでも大幅な改善が
見込めるはず。

271 ：デフォルトの名無しさん：2008/09/08(月) 10:49:19

いわゆる「業務系」ってやつに高度なビジネスロジックなんてあまりないけどな。

272 ：デフォルトの名無しさん：2008/09/08(月) 23:24:45

パズル系のサンプルコードと業務系の本番コードとの最大の違いは項目数じゃないかな？
条件分岐の際しばしば5～6個の項目を判定しないといけなくて、
マトリクスのパターン数が半端なくなる。
MOVE文が数千行延々と続いたりとか普通。
集団項目でMOVEしたり初期化したりできることだけがCOBOLの取り得と思った時がある。
勿論Xがスペースで初期化されるCOBOLねｗ

273 ：デフォルトの名無しさん：2008/09/09(火) 08:07:36

>>269
COBOLって、保守性とか可読性に貢献しそうな抽象化の機構がないよね
>>272
数千行延々と続くのを誇らしく言うのはコボラーだけ
他の言語に比べてステップ生産性が高いわけだよ
普通なら、恥ずかしくて言えない。まともの言語使ってるなら…

274 ：デフォルトの名無しさん：2008/09/09(火) 18:40:21

曲学阿世

275 ：デフォルトの名無しさん：2008/09/09(火) 20:50:38

ジャーナル的に受注時点のマスタ情報をトランザクションで持ってなきゃいけないとか、
法定項目だけで100以上あったりとか、
テーブル正規化すると移行が難しくなるから非正規化しとくとか、
色々ある訳よ。
テーブルがそうだとCOBOLで書こうがCで書こうが同じなんだよね。
だからsql*plusのdescを標準入力から食って
出力ファイルのCOPY句通りのレイアウトで出力する
Cのソースを自動生成するツールとか作ったよ？

276 ：デフォルトの名無しさん：2008/09/09(火) 21:13:32

>>275
>ジャーナル的に・・・
単価テーブル(顧客コード,商品コード,荷姿コード,契約時刻,契約単価)
のようなテーブルを各種持っているのではいけないのですか?

277 ：デフォルトの名無しさん：2008/09/10(水) 00:21:57

>>276
あんまりいくない
単価がコロコロ変わるなら仕方が無い

278 ：デフォルトの名無しさん：2008/09/10(水) 07:13:49

>>277
>>275の話題とは離れますが、
石油元売のガソリン仕切り価格は週決めですよね。一方、締めは
相変わらず月単位です。今日の商習慣では至極当たり前のことです。
むしろ、>>276のような持ち方を標準とするべきなんじゃないですか?

279 ：デフォルトの名無しさん：2008/09/10(水) 17:54:33

あんまりいくないけど
仕方がないって言ってるジャン
しつこい奴だね。

280 ：デフォルトの名無しさん：2008/09/10(水) 22:13:31

>>278
別に標準って程でもないと思う。
「ガソリン」だとか「野菜」だとか、そういう「時価もの」だったら、
そりゃその時点の単価をトランザクションに持つなり、
金額を算出して持っておくなりするのがいいだろうけど、
一定期間は同一単価で購買する、と取引先と契約している
ケースだって沢山あるだろう。
そういう場合は単価マスタで一元管理した方がいいでしょ。

心配なら、単価マスタを世代で管理すればいい。
・商品コード
・適用開始日
・適用終了日
・単価
・型式
・etc
とか。
これで後からでも「この時点の単価は幾らだった」と分かるよ。

281 ：デフォルトの名無しさん：2008/09/10(水) 23:20:25

>>280
そのパターンはよく使うが、期間でマスタ引くの面倒じゃない？
一意のバージョン番号振った方がいいと思うんだけど、どうだろう。

282 ：デフォルトの名無しさん：2008/09/11(木) 00:44:20

単価マスタくらいなら適用期間で世代管理すればよいと思うけど、
重たいマスタNo.1は何と言っても顧客マスタ。
電話会社の料金システムの時10億件くらいだったかな…
ホスト時代にはVOL50本くらい割り当てられてて、
顧客マスタ舐めるのは最後の手段とされていた。
当然、トランザクション発生時にトランザクションに乗っけて引き回す。
証券会社の時は100万件もなかったけど、
オープン化したせいか世代管理してくれなかった。
なので扱店変更はトランザクションにしか残らない。

283 ：デフォルトの名無しさん：2008/09/11(木) 07:48:43

マスタの件数がでかすぎていちいち参照なんかやってられないと言うのもあるのか
電話番号がプライマリキーだったりして

284 ：デフォルトの名無しさん：2008/09/11(木) 16:05:07

>>282
顧客マスタが10億件!! 大正時代くらいからの顧客が全部入ってるんだろうか。

285 ：デフォルトの名無しさん：2008/09/11(木) 22:56:50

多分加入数だから1人1件とは限らないのだよ。
とはいえ冗長な持ち方してそう…

286 ：デフォルトの名無しさん：2008/09/12(金) 01:13:27

モデリングがちゃんと出来てないから、契約と顧客がごっちゃになってるんでしょうね。
いかにもコボラーらしいシステムですね。

287 ：デフォルトの名無しさん：2008/09/12(金) 07:22:35

携帯電話の契約数が全国で1億件ちょっと
http://www.tca.or.jp/japan/database/daisu/yymm/0808matu.html
固定電話が5000万件ぐらい
http://www.johotsusintokei.soumu.go.jp/whitepaper/ja/h17/html/H2202200.html

さらに過去分の世代も管理しようとすると、
10億件ぐらい行ってしまうのかも知れないね。

288 ：デフォルトの名無しさん：2008/09/12(金) 08:56:52

契約書マスタ的なものか。私の名前が入力ミスで局線ごとに
違っていても一向に構わないとか。

289 ：デフォルトの名無しさん：2008/09/12(金) 11:08:56

【IT】「COBOLは現役バリバリ」、東京海上日動がシステム全面再構築でCOBOLを選んだワケ　開発者向けセミナー「XDev2008」 [08/09/08]
http://gimpo.2ch.net/test/read.cgi/bizplus/1220822531/

290 ：デフォルトの名無しさん：2008/09/12(金) 11:55:36

IT弱者のIT弱者によるIT弱者の為の無駄遣いだなｗ

291 ：デフォルトの名無しさん：2008/09/13(土) 03:47:46

>>289　上から続いている話のrootはこれ(>>262)なんだけど。マルチさん。
>2008年5月に，3年7カ月前に着手した第1次フェーズが終了し，
>　プロジェクトの要件では，「プログラミングと単体テストを5カ月で終了しなければいけないスケジュールを乗り切るには，
3年7カ月のプロジェクトで「プログラミングと単体テストを5カ月」は短過ぎると思わない?

292 ：デフォルトの名無しさん：2008/09/14(日) 03:16:22

残りの期間はどうするかの会議で使ったとか。

293 ：デフォルトの名無しさん：2008/09/14(日) 03:46:39

コンパイル通るまでが単体テストです。

294 ：デフォルトの名無しさん：2008/09/14(日) 05:10:13

この期間が短いが故に、既存の人的資源の利用が必須で、
COBOLの選択が現実的だったというニュアンスだ。
この期間にもう少し余裕が取れたら、どんな選択肢が
あり得たのか、それについてどんな検討がなされたのか
聞いてみたい。

295 ：デフォルトの名無しさん：2008/09/15(月) 21:11:12

これは恋のおまもりｶｷｺです｡このｶｷｺを3ヵ所以上の
所に貼り付けると｡｡｡
いままでずっと
片思いだった人と
両思いになれちゃったり☆彼氏･彼女が
できちゃったり☆
と､他にもいい事がたぁ～っくさんおこります!!
私の姉がこれを
冗談でやってみたところ･･･
その3日後好きな人に告られました!!
これを信じるか
信じないかは
あなたしだいですよっっ☆
みなさんも
良い恋愛を･･･!!

296 ：デフォルトの名無しさん：2008/09/28(日) 02:43:22

>>262
"現役バリバリ"が現役バリバリじゃない件。昭和かよって誰か突っ込め。

297 ：デフォルトの名無しさん：2008/09/29(月) 15:58:11

確かに新規案件は少ないかもしれないけど
現役で稼動しているのは間違い無い

298 ：デフォルトの名無しさん：2008/09/29(月) 16:16:02

>>289
東京海上日動解約しようかなぁ、不安になってきた。

299 ：デフォルトの名無しさん：2008/09/29(月) 16:17:57

> なぜなら5つのロジックと10の命令文で当社は30年間システムを保守できているからだ。

その下層のシステムに目を向けていないのが恐ろしい。

300 ：デフォルトの名無しさん：2008/09/29(月) 17:03:51

うんうん君たちは他言語を貶めて・・・。

そうじゃないぞ。

301 ：デフォルトの名無しさん：2008/10/04(土) 16:58:22

>>298
この案件持ってきたSIerは優秀すぎるだろ。

開発に、Jave要員とCOBOL要員を導入させ、
運用にも、Java要員とCOBOL要員を潜り込ませる。

単純に計算して、開発・運用の人件費は2倍。東京海上さんゴチですw

302 ：デフォルトの名無しさん：2008/10/05(日) 06:55:42

んとJavaとCOBOLだとCOBOLerの方が単価が高いし、変化とかに弱いから
単純ところか実際は２倍どころでは済まないんだろうなぁ。

303 ：デフォルトの名無しさん：2008/10/05(日) 12:55:23

優秀なSIerとは、

客先に悟られる事なく、不要な機能てんこ盛りのシステムを構築しする。

304 ：デフォルトの名無しさん：2008/11/02(日) 01:20:06

>>299
COBOLerって、レイヤー構造のシステムを考えられないみたいよ

305 ：デフォルトの名無しさん：2008/11/21(金) 00:07:39

335 名前：Trader＠Live![sage] 投稿日：2008/11/20(木) 23:28:05 ID:Fdp2sZ5x
韓国_天皇皇后両陛下陵辱事件
http://www.vipper.org/vip998412.flv.html

ＦＬＶプレーヤーの類で見てね。
ユーチューブで消されたようだ。誰かニコニコにアップしてくれないかね。

この事件で金大中大統領の支持率が、ガバッと上がった。
そして数ヵ月後、金大中大統領は、韓国のラジオ番組に出演した。

司会者から「あれは上手くやりましたね。胸がスーッとしました」
とか言われて得意になった金大中は、

「あれをやるために、わざわざ日王夫妻を呼んだのだよ」と言ったんだ。
これでまた支持率が上がった。まったく嫌になるね。

客人を招いてエスコートしてきたホストが、先に席について挨拶を始めてしまった。
しかも天皇皇后両陛下の道を塞いで、通せんぼした。
これはどこの国でも大変失礼なことなんだけど、韓国に留学した友人の話では、
韓国では失礼どころの話ではなく、到底許されない行為なんだそうだ。

306 ：デフォルトの名無しさん：2008/11/22(土) 20:08:17

age

307 ：デフォルトの名無しさん：2008/11/24(月) 11:34:51

面白いﾌﾞﾛｸﾞ見つけた

彼氏がCOBOL使ってた。別れたい…
雑記

COBOLだとソース印刷するとき時なんか恥ずかしいｗｗ

下向いちゃうしｗｗ

開発言語にはせめてJavaくらい使って欲しい・・・

フローチャート書かされたりコーディングシートとか使わされたりしたら・・・・もう最悪ｗｗ

せめて普通にC#やVB.Netぐらいは使って欲しい。

常識的に考えて欲しいだけなんです！

COBOLだからグローバル変数じゃないと使えないとか言われた時の恥ずかしさとか分かる？

あのね？たとえば週末40～50人ぐらいで本番リリースとか行くでしょ？

それぞれ自分のアプリケーションリリースするじゃない？

みんな普通にWebサービスとかRIAとかリリースするわけでしょ？

ホストの電文に項目一個増やすだけで20人くらい待機しに行ったら大恥かくでしょうがｗｗ

http://anond.hatelabo.jp/20081111000645

308 ：デフォルトの名無しさん：2008/11/24(月) 11:55:23

じゃあ彼氏がPythonやRuby使っていると別れないのか？
とネタにマジレスしてみる。

しかし、COBOL使っている連中は今時は案件が激減してるだろうなぁ。

309 ：デフォルトの名無しさん：2008/11/24(月) 14:45:12

PythonやRuby案件より多いだろ、ＪＫ

310 ：デフォルトの名無しさん：2008/11/24(月) 16:49:33

頭にPとかRがつく言語を使うおとこの人って・・

311 ：デフォルトの名無しさん：2008/11/24(月) 19:08:37

黒田さん？

312 ：デフォルトの名無しさん：2008/11/24(月) 19:13:23

R P# Pascal Prolog Postscript Perl PHP Python Ruby それが何か?

313 ：デフォルトの名無しさん：2008/11/24(月) 23:39:08

>>312
RPG PL/I も忘れないで。

314 ：デフォルトの名無しさん：2008/11/25(火) 08:25:36

>>312 P# とはなんぞや。

315 ：デフォルトの名無しさん：2008/11/28(金) 06:29:45

>>314
久しぶりに見たらレスがついてた。
F#と間違えたw　ごめんなさい。
P#はPrologからC#へのトランスレータで言語とは言えない。
.NETからPrologの推論を使うためのもの。

316 ：デフォルトの名無しさん：2008/12/02(火) 21:45:44

cobolの良い点->実行速度が速い？噂で聞いた
cobolの悪い点->
行番号邪魔。目障り。
A領域？B領域？好きなとこに書かせろ。
72文字まで？ifの入れ子どうすんだよ！
全部グローバル変数って・・・（苦笑）
"break"文ねーのかよ！
大文字でよみずれーよ！
hoge = 1;　が　MOVE 1 TO HOGE.ながったらしいわ！
if文に括弧（）使えなくて読みづらい

317 ：デフォルトの名無しさん：2008/12/02(火) 22:55:29

>>316
いくつか認識に誤りがある。

>行番号邪魔。目障り。
行番号は別に必須ではない。

>全部グローバル変数って・・・（苦笑）
サブルーチンというかサブ手続きを、PERFORM
で呼び出すのではなく、プログラムを入れ子にして
CALLで呼び出すようにすれば、手続き毎の
ローカル変数を持たせられる。
（ただ、このやり方はあまり行われない）

"break"文ねーのかよ！
GO TO で代用。

>大文字でよみずれーよ！
よみ【づ】れー　が正しい。

>if文に括弧（）使えなくて読みづらい
そんなことは無い。( ) は必須でないだけで、
別に使っても差し支えない。
こっちは「読みづらい」とちゃんと書いてるのね。

318 ：デフォルトの名無しさん：2008/12/03(水) 06:23:16

×COBOLが速い
○バカが書いてもそれなりの速度で動作する

無駄な動作てんこもりだから、やっぱり遅いけどな

COBOLの利点なんかないよ。さっさと滅べ

319 ：デフォルトの名無しさん：2008/12/03(水) 12:01:00

Javaで組んだバッチって最近は安定した？
前は使い物にならなかったけど、springバッチを知ってちょっと気になっている。

320 ：デフォルトの名無しさん：2008/12/03(水) 19:44:20

正直、バッチの安定度なんて作った奴の技量が９割以上占めてる感があるが･･･。

321 ：デフォルトの名無しさん：2008/12/07(日) 01:18:57

>>317
＞＞"break"文ねーのかよ！
＞GO TO で代用。
GO TOって行番号指定なの？それともラベル指定？
行番号指定だと、ソース修正したらGOTOも修正？
むしろGOTOでの指定って一般的なの？たぶんJavaに限らず構造化言語以降であれば、
よっぽどの理由が無い限り使わないのがGOTO文。特に行番号指定はありえない。
（ラベル指定はほかの選択肢が無ければ使うが、積極的に使うことはまずない）
ついでに質問なんだけど、ソース管理にホントにこんな風にするの？↓
//DEL 2008/12/05 ○○の理由で削除 st
// ～　古いソース　～
//DEL 2008/12/05 ○○の理由で削除 ed
//ADD 2008/12/05 ××の理由で追加 st
～　新しいソース　～
//ADD 2008/12/05 ××の理由で追加 ed

322 ：デフォルトの名無しさん：2008/12/07(日) 01:37:30

>>318
＞COBOLの利点なんかないよ。さっさと滅べ

俺もずっとそう思ってるし、本当にそう思うけど最近COBOLの利点が見えてきた。
保険系のシステム部門に入ったんだが、そこはシステム子会社に本社社員を出向させてるんだ。
本社社員は、当然システムの専門家じゃない人も紛れ込む。
ひどいときは、パソコンすらまともに扱えない子が来たり。
（最小化ボタンを押して「これで小さくなるんですか！？」と驚くくらいの）

で、そういった子たちは「最先端だから」ってことでJavaでシステム開発をする
期待の部署に配属されたわけだが・・・
教育担当として別会社から派遣された俺は正直死にそうだ。
同じように配属された、COBOL系に進んだ本社新人はすでにがりがり作業しているのに
こっちはもうすぐ年末だというのに、まだJavaScriptとJavaの違いで混乱されている。。。
泣きたい。馬鹿でも素人でも書けるCOBOLが、基幹系で使われる理由がなんとなく分かったような。。。
まぁ「え？何でパソコン代えても同じメールアドレス使えるんですか？」とのたまう新人様にも問題あるような気がする。

323 ：デフォルトの名無しさん：2008/12/07(日) 04:18:35

それは他人の芝は青く見える現象だと思います。

バカや素人で成果物が出来る度合いはJavaの方が上だしなぁ。

JavaなんかだとメソッドがgetXXXとかで、まあ深い意味はしらんでも
なんとなく使えるし、自然とプログラマはそういう流儀で組むようになるんだが
COBOLとかだと先人のｲﾐﾌﾒｲなルーチンをおっかける羽目になるから、
他人から見ると「がりがり作業」しているようにみえるかもしれんが、
実際は「くだらねぇ、コードのおっかけ作業」は多い。

そして基幹系ほど恐ろしい素人が部長やらの地位にいる。

324 ：デフォルトの名無しさん：2008/12/07(日) 10:18:41

>>321

>GO TOって行番号指定なの？それともラベル指定？
ラベル。

>ついでに質問なんだけど、ソース管理にホントにこんな風にするの？↓
>//DEL 2008/12/05 ○○の理由で削除 st
>// ～　古いソース　～
>//DEL 2008/12/05 ○○の理由で削除 ed
>//ADD 2008/12/05 ××の理由で追加 st
>～　新しいソース　～
>//ADD 2008/12/05 ××の理由で追加 ed

それはその現場のコーディング規約の問題であって、
言語の問題ではないな。

325 ：デフォルトの名無しさん：2008/12/07(日) 11:54:00

バージョン管理ソフトのなかった時代の産物だな。
COBOLに限らず、C/C++でもVBでもよくやってたよ。

いまは普通にcvsやsubversionを導入するだろう。

326 ：デフォルトの名無しさん：2008/12/07(日) 12:49:21

>>324 >>325
バージョン管理ソフトが無い現場のことで、COBOLもバージョン管理ソフトあるのね。
俺もVBの案件で当初subversionが無い現場だったのでやってたけど
Javaにかかわるよりsubversion使うようになって以来やってなかったんだが
COBOLで8年くらいやってた人が上級SEとして現場に入って、いきなりコーディング規約を変更して
ソースの管理は上述の方法でやれとなり、過去の分もコミットログから復帰できる分は復帰しろとなった。
「そのほうがソースの見通しがよくなる。前の修正が分かるから」だそうだ。。。

327 ：デフォルトの名無しさん：2008/12/07(日) 20:45:54

現実問題として前の修正なんか見たところで関係ないんだがな。

漏れのところはcvsとか導入していないので、ソースに変更履歴を
直接記入する方式のままだ。

今の最新状況は知らんが、COBOLとかはCで言うmakeや
javaで言うantがないんだから、そういう文化も仕方ない感があるが、
cvsが導入されている現場で、ソレをやられても単純にソースの可読性が
落ちて、ソースの解読ミスを誘発するので、あの文化はないに越した事はない。

＞「そのほうがソースの見通しがよくなる。前の修正が分かるから」

それな「漏れはこれまでこの方法でやってきた！」と言う
典型的な学習能力の無いCOBOLerの見本ですな。

328 ：デフォルトの名無しさん：2008/12/07(日) 21:58:17

>>326
> 「そのほうがソースの見通しがよくなる。前の修正が分かるから」だそうだ。。。
最後の「。。。」が哀愁を誘うな……。
俺は規約を作る側なので、「コードが読めなくなる。残すな。削れ」を規約に入れたが、古いコードには適用されないんだよねぇ。
おかげで、コメントアウトされてて、IDE使ってるから色も変わってるにもかかわらず、読んでる最中に古いコードに踏み込んでムキー!!っとなることがしばしば。
コメントで行食ってるから、コード全体を一望しづらいし。
最近は、発見し次第抹殺してから読むようにしてる。

329 ：デフォルトの名無しさん：2008/12/08(月) 10:32:40

COBOLみたいな古い言語だと
そういう古くからの伝統をバッドノウハウとして引き継いでいるプロジェクトが、確かに多い。

じゃあJavaはどうだ？っていうと、
新しい言語だけあって、そういうのに汚染されているのが、比較的少なかったりするけど
それでもたまに↑みたいな修正を強要をしたりする現場もある。
あとプログラム名をIDでふったりとか
（ASDF80010とか。なんだそりゃ？DBアクセスは80000番台か？みたいな）

まあ、上にたつ人が化石なら、もうしょうがねえって割り切るしかないな。

330 ：デフォルトの名無しさん：2009/01/08(木) 21:49:10

>>85
アボート＝アベンド

アボートはＮＥＣ汎用機で使っている呼び方
アベンドはＩＢＭ汎用機、富士通汎用機等で使っている呼び方

ようは言い方が違うだけかと思われます

331 ：デフォルトの名無しさん：2009/01/09(金) 09:53:25

>>325
バージョン管理ソフトを使っていても、
修正コメントは入れるだろ。

332 ：デフォルトの名無しさん：2009/01/09(金) 13:06:04

ソース納品時、
.svnとか入れないだろうし

リポジトリがクローズドな○○sdk配布
なんてよくあるわけだし

両方コメントいれとけよ

333 ：デフォルトの名無しさん：2009/01/10(土) 21:32:52

>>316
オブジェクト効率から言うと、アセンブラが１とすると
Cは１．５、COBOLは３くらいの差がある。

334 ：デフォルトの名無しさん：2009/01/11(日) 11:05:07

>>333
オブジェクト効率って聞いたことない用語だな
どこの会社のジャーゴンだよ

ソースコードに対するオブジェクトコードの生成比率か？

COBOLは10進演算をライブラリ関数をコールするんじゃなくて、
10進演算のためのコードを全部インライン展開すると聞いた
近代的なCPUのアーキテクチャ無視したメインフレーム時代の悪弊だな

だからCOBOLが速いというのは大嘘で、
バッチ処理ならJavaの方が4倍速いという実験結果が出てる
VM実行に負ける言語。それがCOBOLクォリティ

335 ：デフォルトの名無しさん：2009/01/11(日) 11:57:46

>>334
>バッチ処理ならJavaの方が4倍速いという実験結果が出てる

それは興味ある。ソース教えてくれ。

336 ：デフォルトの名無しさん：2009/01/11(日) 14:49:36

>>335
Java バッチ実用化に向けたフレームワークの開発
ttp://www.nri.co.jp/opinion/g_souhatsu/pdf/gs20070104.pdf

工夫のしどころはこういうところらしい

バッチ処理のループで、ループごとに入力データのオブジェクトを生成するのやめて、
一回だけ作って同じものを使い回す

入力データは必要な箇所だけ java.lang.String とかを作って、他は byte stream のまま持つ

337 ：デフォルトの名無しさん：2009/01/11(日) 20:33:09

暇だったから斜め読みしてたけど。。。

>>154-259
の流れが読んでて衝撃的だった、
仕事上で COBOLer の方々とは接点が無いけど、
DB設計に対する思想の違いというか、時代の違いなのかなぁ。
最終的には Case By Case なんだろうけど、
この程度の議論じゃ、分かり合えないんだろうなという気がしてきた。

338 ：デフォルトの名無しさん：2009/01/11(日) 20:34:49

>ループごとに入力データのオブジェクトを生成するのやめて
適用範囲にもよるけど、考え方は当たり前じゃね？

339 ：デフォルトの名無しさん：2009/01/11(日) 22:45:17

cobolのプロシージャディヴィジョンってメソッドみたいなもの？

340 ：デフォルトの名無しさん：2009/01/12(月) 05:32:33

>>338
実際に実験してデータを取った、ってところを評価すべきじゃね？
パフォーマンスが出ないCOBOLバッチを置き換えるときに、
それならJavaにしようか、ってのは、こういうデータが積み重なって、
初めて出てくると思う。
技術なんてものは、出来上がってしまえば、どんなものでも当たり前だよ。

>>339
乱暴な言い方をすれば、
アセンブラで言うところのcseg
DATA DIVISIONはdseg

341 ：デフォルトの名無しさん：2009/01/12(月) 10:44:47

>>336
そこの高速化云々はJavaの伝統的(?)な教本のEffective Javaに書いてあったり
する事なんだが。

工夫もなにも中級者(?)ならワリと常識だと思ったけど。

ってオレも２版買おうか迷ってる。

342 ：デフォルトの名無しさん：2009/01/12(月) 13:33:00

論点がずれてない？
常識だったら、JavaはCOBOLより速い、というソースの価値が落ちるの？

あらゆる高速化技術を持ってしてもCOBOLの方が速いと思いこんでいる
連中は、かなり多いんだよ

343 ：デフォルトの名無しさん：2009/01/12(月) 18:47:17

ソースの価値と言ってもな。

速さ云々とか言い出すなら、ＣとかSQLを使うべきだと思うが。

この場合はアルゴリズムが違うのに速い遅いを言うのがアフォっぽい希ガス。

344 ：デフォルトの名無しさん：2009/02/11(水) 17:21:42

おまえら、何十年と培ってきたCOBOLの資産をJavaに置き換えるのに
いくらかかると思ってるの？

345 ：デフォルトの名無しさん：2009/02/11(水) 17:25:57

ＣＯＢＯＬを保守するために毎年ベンダにいくら払っているの？

346 ：デフォルトの名無しさん：2009/02/11(水) 18:40:55

コボルがなくなるとコボラーが怒涛に迷います。
Javaやっている人は、どうにでもなると思います。
コボルをいじめないでください。

347 ：デフォルトの名無しさん：2009/02/11(水) 21:53:24

>>344
×資産
○負の遺産

348 ：デフォルトの名無しさん：2009/02/11(水) 23:11:36

メインフレーム＋COBOLの安定性をJavaで出せますか？
Java+Struts+Spring+Hibernateで超大規模金融系の基幹システムを作れますか？

349 ：デフォルトの名無しさん：2009/02/11(水) 23:47:56

某大手金融機関では、メインフレームLinuxを採用してCobolとJavaの共存をはかり、
新規開発分はほぼJavaに一本化されていますが、なにか。

350 ：デフォルトの名無しさん：2009/02/11(水) 23:52:59

＞メインフレーム＋COBOLの安定性をJavaで出せますか？
ぶっちゃけ楽勝だろう。
漏れの目の前でアベンドしまくっているメインフレーム＋COBOLのシステムが存在してる。
あれを越える安定性なんかチョロい。

＞Java+Struts+Spring+Hibernateで超大規模金融系の基幹システムを作れますか？
なんでStruts指定なのか解らんし、超大規模金融系って具体的にどこの銀行を指してんだ？
都銀(MUFG)レベルでいいなら、それにC,C++,Python,SQLくらい足せば余裕で可能だろう。

351 ：デフォルトの名無しさん：2009/02/11(水) 23:59:06

>>346
手続型言語なんて、どれも似たりよったりなのに何で路頭に迷うんだろ。
経験的には、2週間くらい学習すれば、困らない程度には使えるようになると思うんだが。
(Prologとか、発想の転換が必要な言語は除くけど)

352 ：デフォルトの名無しさん：2009/02/12(木) 00:00:20

高レベルなJavaの技術者で業務に詳しい人材を大量に集めることは可能なの？
無理だよね。
もう間をとってCかDelphiでいいじゃん。

353 ：デフォルトの名無しさん：2009/02/12(木) 00:05:23

Javaってたまに原因不明でスレッドダンプはいて氏んでる光景をみるよ。
怖くて使えない。
これからはFORTRANかLispだな。
といいながら、今、VC++の案件をしてるけど。

354 ：デフォルトの名無しさん：2009/02/12(木) 06:44:58

＞Javaってたまに原因不明でスレッドダンプ
スレッドダンプしてるなら原因わかってるじゃん。
OSごとコアダンプ吐いて死亡したならわからんだろうけど。

つかCOBOLでアベンドした時に担当者に聞くと「それはオレが作ったプログラムじゃないから
知らん。」とかなって人海戦術で関連プログラムをソースレベルで机上解析から始まるんだが、
正直、殺意しか沸いてこない。

COBOLerにはユニットテストと言う概念がないんだろうなぁ、と感じる。

355 ：デフォルトの名無しさん：2009/02/12(木) 07:39:17

>>352
業務に詳しいってのが既に痛いんだよな
業務をきっちり説明して仕様決めるのは、客の責任だろ？
そういうのを無茶苦茶にしてるから、いつまでたってもデスマーチなんだよ

356 ：デフォルトの名無しさん：2009/02/12(木) 21:08:38

>>355
うへｗこれは釣りなのか・・・
客が仕様決めるのは当たり前って・・・無理難題に無駄な機能のオンパレードですよ・・・
それこそデスマーチｗ

そもそも法律（税率など）が変わった時にちゃんと対応できるように作らないといけないから
知識がないとお客に提案も質問も出来ないよ。
金融に詳しくない人が金融系のシステムを作るとか俺なら絶対依頼も請負もしたくない
システム1時間止まっただけでも・・・・何億何兆円の損失が出るんだろう・・・・

357 ：デフォルトの名無しさん：2009/02/12(木) 21:42:56

>>356
そうやってロックインするんですね
わかります

358 ：デフォルトの名無しさん：2009/02/13(金) 00:09:13

すみません、このスレが2chで一番 COBOLER が多そうなので、質問させていた
だきたいのです。

COBOLの各処理系ごとの互換性はどのぐらいあるものなのでしょうか？

知人の小さな事務所に、COBOLで組まれた古い経理システムがあるのですが、サー
バがマイナーな某社UNIXサーバ(UNIXは独自。CPUがR5000なので、SGIのOEM提供
かもしれない）で、今後の保守も考えて、もっと一般的なx86 サーバに移行し
たいのだそうです。

自分はCOBOLはぜんぜん知らないのですが、Javaなら慣れています。もしCOBOL
の互換性が高いなら、COBOLを勉強しながら、CentOS + Open Cobolあたりに移
植できないかと思うのですが。

359 ：デフォルトの名無しさん：2009/02/13(金) 07:28:49

とりあえずJavaから見たらCOBOLの互換性はアレだろ。

360 ：デフォルトの名無しさん：2009/02/13(金) 07:52:39

どこのメーカーのコンパイラ使ってんのかわかんなきゃなんとも言えんが。
画面（オンライン）は間違いなく作り直しだろう。
あと、ＣＯＢＯＬっつーより環境周り（ＪＣＬ）でハマりそうな気もする。

361 ：358：2009/02/13(金) 12:23:24

ありがとうございます。

> どこのメーカーのコンパイラ使ってんのかわかんなきゃなんとも言えんが。
コンパイラとOSは分かりませんが、実はサーバはカ○オなんです。
ttp://w3.cjnet.co.jp/ADPS/ad75.html
これの2000年ごろの機種。

カ○オのサーバというのが初耳だったので、OEMかと思っていたのですが、実は
結構な実績があるようで、
（参考）コンピュータ博物館：日本のコンピュータ：オフィスコンピュータ
http://museum.ipsj.or.jp/computer/office/0011.html
OSもコンパイラも自社開発かもしれません。

自社開発なら他の処理系の資料は参考にならないから、ドキュメントやら開発
ツールやらを正規に購入しないと、既存のプログラムの解析もできないのかし
ら。とんでもない金額になりそう。

> 画面（オンライン）は間違いなく作り直しだろう。

なるほど。ちょっと調べてみました。

問題点と未来 - COBOL - Wikipedia
http://ja.wikipedia.org/wiki/COBOL#.E5.95.8F.E9.A1.8C.E7.82.B9.E3.81.A8.E6.9C.AA.E6.9D.A5
> 画面処理を行なうプログラム向けの、画面処理機能は各社固有の機能となっている。

OpenCOBOL - フォーラム
http://jp.opencobol.org/modules/newbb/viewtopic.php?forum=1&post_id=394&topic_id=103
> OPEN COBOL の現バージョン0.32では SCREEN SECTION はほぼ使えません。
> ...(略)...
> 事例でWEBベースの話が多いのも頷けます。

362 ：358：2009/02/13(金) 12:51:29

UNIXでtelnetのクライアントサーバアプリということだったので、Cみたいに、
パッチを少し当ててリコンパイルすれば、Linux上でも動くかと思ったのですが、
ぜんぜんそんな状況ではないんですねえ。

90年代の後半に、オープン系とか言ってUNIXとCOBOLでのサーバクライアントア
プリのブームがあったようですが、いまの基準ではとてもオープンとは言えな
いなあ。システムを組むときは選択の余地があっても、組み終わってから乗り
換えるのはすごく高コストなんだから。

当時導入されたサーバがそろそろ寿命になっているユーザ企業ってたくさんあ
ると思うんだけど、どうしてるんだろう。安価で高性能なPCサーバが普及して
いるのに、それを横目に、新規では誰も買わない高価なUNIXサーバを買わざる
をえないのかなあ。

とりあえず知人には「自分には無理」と言うことにします。
ありがとうございました。

363 ：デフォルトの名無しさん：2009/02/13(金) 16:50:17

COBOLのソースって、バージョン管理どうやってんの？
行番号が邪魔でdiffがまともに機能しないような気がするんだけど。
それとも行番号無しでcommitして、
実行前に行番号付け直すフィルタ噛ませるの？

364 ：デフォルトの名無しさん：2009/02/13(金) 22:56:25

>>363
そうかー、行番号つき言語って、冷静に考えたら当たり前だけど diff が取れ
ないのかー。悪夢だ。書ける気がしない。

365 ：デフォルトの名無しさん：2009/02/14(土) 17:24:47

コボル上がりのおっサンPGは、修正箇所にやたらコメントを挿入しまくる
そして、1年後コメントまみれの読みにくいソースファイルが出来上がってしまう

366 ：デフォルトの名無しさん：2009/02/15(日) 06:13:00

＞COBOLのソースって、バージョン管理どうやってんの？

古代言語はそういう高度な事はまずやっていない。

367 ：デフォルトの名無しさん：2009/02/15(日) 10:33:28

バージョン管理ソフトの導入コストが下がって
一般レベルの開発現場に降りてきたのって、まだ歴史浅いから。
今ヘンテココメントやっていたら馬鹿にしてもいいけど
昔の古いコードに文句を言うのは、それはちとかわいそうな気がする。

368 ：デフォルトの名無しさん：2009/02/18(水) 00:48:58

Java とか COBOL でプログラム書いてルーター作れるの?

369 ：デフォルトの名無しさん：2009/02/18(水) 07:12:07

Javaとか使ってる奴らは丸め誤差すら理解してなかったりするから困る。
事務計算で「たかが1円くらい違ってもいいじゃないですか！」なんて言ったりね。

370 ：デフォルトの名無しさん：2009/02/18(水) 09:36:29

>>369
つ BigDecimal

まあ経理処理をlongで実装したりするタワケモノが時々いるのは同意。
昔の俺とか。すみませんすみません。

つうかBigDecimalに四則演算子が使えるようになってほしかったな。
val1.add(val2) じゃなくて、val1 + val2 と書けるようになってほしかった。
Guy Steele が提案したけど却下されちゃったんだよな。残念。

演算子がオーバーロードされているのがStringだけってのは、Javaの駄目な
ところだと思う。

371 ：デフォルトの名無しさん：2009/02/18(水) 22:15:49

>>370
> つ BigDecimal
まともな分数の実装があれば biginteger(って言うんだっけ, java 方面？)
あれば必要ないし…

どの時点で丸めるかだけの問題っしょ?

372 ：デフォルトの名無しさん：2009/02/19(木) 08:24:35

別にCOBOL使っている奴でも丸め誤差気にしてない奴は
全然していないけどな。

演算子のオーバーロード云々はJavaに関しては中途半端な方向性だとは思うけど、
じゃあ、Pythonみたいに　'w' * 10　と書いて 'wwwwwwwwww' と出るのは
いい事なのか？って言われればJavaでソレが実現したらキモい印象しかないし。

つか、漏れの知っている金融系だと誤差が出るから数値は全て整数にしてたのを
見るのとCOBOLerもJavaの事はとやかく言えんと思うが。

373 ：デフォルトの名無しさん：2009/02/20(金) 16:34:02

COBOLの場合は丸め誤差を気にする必要がないんだと思う。
#つーか２進数程度でも理解不能らしいよ。COBOL上がりの人って。
COBOLには１０進数型っていうｽｸﾞﾚﾓﾉがあって。
こいつは数字１桁を表現するのに１バイトを使うぜいたく品で。
ただ、丸め誤差は固定小数点の１０進数のため問題が起きない。
桁あふれも、２進数のように256,65536,,,,のような数値じゃなくて、1000,100000とか
わかりやすいラインで起きる。利点が多いよねCOBOLって！ｗ
んでもってこの１０進数での数値型が標準らしい。Doubleの丸め誤差みたいな問題は普通おきないんだってさ。
#余談だが太古といえる昔には、数値の扱いの差で科学技術用（２進数）と商用（１０進数）の２種のコンピュータがあって
#古い書籍で商用：COBOL　科学計算：Fortran　ってあるのはその差らしい。あとCOBOL連中が汎用機っていうのは
#M/Fは４０年前は珍しい、２進数も１０進数も・・・科学計算も商用計算もできる汎用的なコンピュータだったからなんだってさ！

374 ：デフォルトの名無しさん：2009/02/20(金) 17:00:50

＞数字１桁を表現するのに１バイト
それは、ゾーン10進数でしょ？
あと、計算用にパック10進数というのもある。
こちらは、１バイトで2桁（最下位の符号部分以外）

＞２進数程度でも理解不能らしいよ
ごく普通に使ってたよ。"COMP-4"で。
（"COMP-4"の詳しい説明はここでは割愛）

375 ：デフォルトの名無しさん：2009/02/21(土) 06:19:32

ゾーンやパック１０進数を利点と捕らえるのもある種の自由だと思うけど
その分昔のマシンだと浮動小数点って概念ないのでは。

とりあえず気にする必要はBigDecimal型程度には本来あるはずだが。（ｗ

376 ：デフォルトの名無しさん：2009/02/21(土) 11:13:34

＞浮動小数点って概念ないのでは。

少しスレ違いになるが、もしCOBOLで対応できない場合は、
サブモジュールとしてアセンブラを使う。
汎用機のマシン語は「一般命令セット」の他に
「浮動少数点命令セット」、「特権命令セット」も用意されている。
「浮動少数点命令セット」は主にFORTRANコンパイラが吐き出すものだが。

その他、COBOLでバイナリ計算をする場合でも、あえてアセンブラを
つかう場合がある。例えばチェックデジットを求める場合などは、
10進演算ではパフォーマンスを食いすぎて極度に処理が遅くなる
場合がある。その場合はCOBOLモジュールからアセンブラサブモジュールを
呼び出し、バイナリ計算をする。ゾーン10進数の左4bitを
ゼロクリアし、ゾーン10進数をいきなりバイナリに変換して計算する。

377 ：デフォルトの名無しさん：2009/02/21(土) 17:33:17

COBOLには、計算途中の端数処理についての規約が定めてあって、
誤差を気にしていないのではなく、奴らはこの仕様が計算誤差の仕様だと言い張る。
だから、COBOLで計算したものだけが正解で、他の言語で計算したのは間違いという、ひでえ話

COBOLには一応バイナリで計算する機能もあるっぽい
配列の添字やら、件数の勘定やらを10進演算してたら遅くてかなわないし…
とか思ってたら、機能としてはあるけど、あんまり使われていないっぽい

10進演算がそんなに優れているなら、多くの言語が標準の型として持つはずじゃね？
そうじゃないってことは、大して重視されてないってことでしょ

378 ：デフォルトの名無しさん：2009/02/22(日) 12:59:21

ちょっと流れを無視するが、なんかまだ貼られていないので貼る。

へ箸ｷたのめも:DSL厨は一度は COBOL を学べ - livedoor Blog（ブログ）
http://blog.livedoor.jp/heitatta/archives/51408171.html

COBOLのお勉強(1) @ 2007年03月 @ ratio - rational - irrational @ IDM
http://idm.s9.xrea.com/ratio/2007/03/04/000592.html

> 今のところの印象としては、はっきり言ってこれは素晴らしい言語だ。激し
> く興奮しながらテキストを読んでいる。

あのYuguiさんに、ここまで言わせるとは。

379 ：デフォルトの名無しさん：2009/02/22(日) 16:05:21

あるコボラーの１日
ttp://sugiemon.exblog.jp/1668491/

wwwwwww

380 ：デフォルトの名無しさん：2009/02/23(月) 01:00:21

コボラーに敬意を払いたくなる小説だな

381 ：デフォルトの名無しさん：2009/02/23(月) 08:20:05

>>378
＞これを超える金融DSLは今のところない

個人的にはCOBOLよりもRPGの方がよっぽど特化していて金融向けに感じるが。
RPGに比べればまだ汎用性高いぞ。（ｗ

言語ヲタと言うか単にメジャーな流行モノをおっかけてるだけの人間の
一コメントとしてはいいんだけど、「すばらしい言語」と思うのは
可哀想な感性の人間だろうなぁ。

それか、仕事でCOBOLを使ったことのない幸せ者

382 ：デフォルトの名無しさん：2009/02/23(月) 13:38:30

>>377
で？経理処理に10進演算は必要無いって主張なのかな？

383 ：デフォルトの名無しさん：2009/02/23(月) 14:40:56

つか昔の機械は10進演算のレジスタがCPUにあっただけで、
それに言語がサポートしていた程度の認識だけど。

浮動小数点も同様だろ。

COBOLが優れているとか経理処理に向いているとは別物と言うか
変な人が後付けの理由で主張している様にしか思えん。

384 ：デフォルトの名無しさん：2009/02/23(月) 15:22:12

>>383
逆に整数が16bitでは困るということもあっただろう。
現実にProlog-KABAは16bitで困ったw

385 ：デフォルトの名無しさん：2009/02/23(月) 15:42:48

>>384
Prolog-KABAが無限多倍長の整数をサポートしていたら、事務計算の
歴史は変わっていただろうな。坂村健もそんなようなこと言ってたよ。

386 ：デフォルトの名無しさん：2009/02/23(月) 15:42:50

だからか知らんけど、どっかの銀行の勘定系のシステムの一部は
１００万単位でざっくりと計算していたな。（ｗ

事務や経理計算＝COBOLを神格化してるヴァカなCOBOLerがいるみたいだけど、
現実は言うほど厳密じゃないよな。

漏れも、仕事で過去案件でCOBOLからのリプレースした時に、SQLで計算させたら
結構な誤差が出たんだが、だからと言って過去に戻って集計しなおす事はやらんかったな。

まあ、数字とかを協会に提出した後だったし、昔のシステムとはおおらかなモノなんだろう。

387 ：デフォルトの名無しさん：2009/02/23(月) 15:50:19

むかし、大昔？、はパネルにランプ表示させて、デバッグを
やってた。ワンステップ進めては、コンパイル時に印刷した
シンボルテーブルを参照してボタンでアドレスいれてその
データを表示とか。
こんな場合は、数値は十進数でないと堪らないよね。

388 ：デフォルトの名無しさん：2009/02/23(月) 15:55:11

んな事言い出すと、パンチカードでデータを作成・入力していた場合は逆に
なんでもよく感じてくるんだが。（ｗ

389 ：デフォルトの名無しさん：2009/02/23(月) 16:05:42

>>383
＞つか昔の機械は10進演算のレジスタがCPUにあっただけで、
＞それに言語がサポートしていた程度の認識だけど。

違う。10進演算はあくまで”メモリ上”で行われる。
その10進演算コードをマシン語でみてみればわかる事だが、
オペランドはメモリをアドレッシングする「汎用レジスタ」が
用いられる。ちなみに「特権命令セット」を使う場合は、
「制御レジスタ」が用いられる。「浮動少数点命令セット」を
使う場合には「浮動少数点レジスタ」が使われる。

390 ：デフォルトの名無しさん：2009/02/23(月) 16:33:40

>>389
スマソ、言い切るのは間違いだな「１０進演算命令セット」が昔のCPUにもあるマシンもある、だな。
漏れの知っているマシンは１０演算のレジスタもあったが。

ちなみにそのマシンには浮動小数点の命令セットもレジスタも存在しなかった。

391 ：デフォルトの名無しさん：2009/02/23(月) 16:38:15

>>390
＞１０演算のレジスタもあったが。

なるほど。そういう環境もあるのですね。
断言してすいません。
ちなみに当方の環境はIBMのS/390でした。

392 ：デフォルトの名無しさん：2009/02/23(月) 16:43:08

結論として、みんなでIBMのAS/400を使えば良いと思うのだが。
COBOLもJavaもRPGも動くよ。たしかアセンブラが提供されて
いないと思ったが、それだけが残念。

393 ：デフォルトの名無しさん：2009/02/23(月) 16:48:19

>>392
Prologが動かなくて残念ｗ

394 ：デフォルトの名無しさん：2009/02/23(月) 16:51:51

>>393
Javaが動くなら、Java系のPrologは移植できるだろ。

395 ：デフォルトの名無しさん：2009/02/23(月) 18:19:04

>>392
そおいや、あのマシンはアセンブラはないんだよな。
と言うかあのマシンの設計思想からしてアセンブラは存在しないんだろうけど。

RPGかCをアセンブラと思うしかないな。

396 ：デフォルトの名無しさん：2009/02/24(火) 00:12:20

結論としては、ACOS6最強？

397 ：デフォルトの名無しさん：2009/02/24(火) 05:56:44

結論は、ＣＯＢＯＬプログラムを窓から投げ捨てろ

398 ：デフォルトの名無しさん：2009/02/24(火) 13:34:53

>>392 AS/400 ってまだ作ってたか?

399 ：デフォルトの名無しさん：2009/02/24(火) 13:59:15

>>398
確か、「ｉシリーズサーバ」？とか名前と変えて
まだあると思ったが。（うろ覚えスマソ）

400 ：デフォルトの名無しさん：2009/02/24(火) 14:06:05

>>393
メモリー管理が難しいから、汎用機では怖いでしょう。

401 ：デフォルトの名無しさん：2009/02/25(水) 19:59:36

>>400
IBMがなぜサポートしなかったのか。ちょっと不思議。

402 ：デフォルトの名無しさん：2009/02/25(水) 23:11:34

>>400
何をアフォなことをorz
一番しっかりしてるのが AS400 -> I series って進んだ系統

つか、 OS 内部がデータベース支援してるってこの系統しかしらんぞ

403 ：デフォルトの名無しさん：2009/02/26(木) 00:43:07

なんかくだらない話ばっかりだな

404 ：デフォルトの名無しさん：2009/02/26(木) 07:10:40

だったら、ageんなよ、カス

405 ：デフォルトの名無しさん：2009/02/26(木) 18:03:23

COBOLをネタにくだらなくない話が出来るならやってほしい

406 ：デフォルトの名無しさん：2009/02/26(木) 21:57:49

♪コボルる涙～

407 ：デフォルトの名無しさん：2009/02/26(木) 22:52:38

Javaを6年やって去年からCOBOL仕事をし始めたんだが、、
オープン系からCOBOLはキツイというのが正直な感想。

言語としてはJavaよりかなり簡単だと思うが、
Web系で統合環境に慣れてしまっていて、
全てを１から記述する作業でミスしまくり。。。
検証もデバックも面倒くさすぎて(これもミスしまくり）
軽く自信喪失な今日この頃。

なんか、俺って今まで結構適当に仕事してたんだな・・・と泣けてくる。

JavaからCOBOLで理解に苦しんだ点。
・変数の使い方
・リンケージ

共通域に変数定義して、値を退避→値設定→値を戻す、
こういう使い方って普通なの？？
コーディングしてて本当に怖い。

408 ：デフォルトの名無しさん：2009/02/26(木) 23:49:59

>>407 だいじょぶだよ
COBOL も Java も OS 書けないから
OS 書けない言語って屑言語だから安心していい

409 ：デフォルトの名無しさん：2009/02/27(金) 15:41:47

>>408 おいおい　COBOLは何時の時代の言語だよ

410 ：デフォルトの名無しさん：2009/02/27(金) 20:41:48

>COBOL も Java も OS 書けないから
とりあえず、JavaなOSのマシンはSUNが出してたと思うけどな

411 ：デフォルトの名無しさん：2009/02/28(土) 03:22:01

そーいえば、COBOLでCADを作ろうとした、社内の優秀なプログラマが挫折して辞めていった。
って話を読んだことがあるな。20年以上前だけどｗ
優秀なプログラマが何故、COBOLでプログラミングしようとしたのかは不明だけど

412 ：デフォルトの名無しさん：2009/02/28(土) 07:12:23

>>407
>共通域に変数定義して、値を退避→値設定→値を戻す、
>こういう使い方って普通なの？？

関数呼び出しで、スタックフレーム確保して、その中に値をpushするなんて
どの言語も書かないだろ？

そういう用途を超えて共通の機能はどんな言語も取り入れて、
プログラマの負担を軽減した

COBOLを除いて

413 ：デフォルトの名無しさん：2009/03/03(火) 18:24:59

Javaでちゃんとオブジェクト指向のプログラミングしてるやつって多いの？

414 ：デフォルトの名無しさん：2009/03/03(火) 19:47:02

>>413
あんまり多くないと思う。

ちゃんとした案件の設計者だったら、きちんとオブジェクト指向設計をしてい
るだろうけど、個々のプログラマはあんまり理解していない。

駄目な案件だと、設計者もプログラマも誰も理解してないことが多い。

参考）
静的オブジェクト指向は設計者が苦労を背負込むシステム
http://blogs.wankuma.com/nagise/archive/2008/05/10/137150.aspx

415 ：デフォルトの名無しさん：2009/03/14(土) 18:24:39

コボルのＮｅｔＤＢって、どうやって
習得するのでしょうか先輩に聞くしか無いのでしょうか
本とか見当たらなくて
マニュアルは読みにくいし・・・・

416 ：デフォルトの名無しさん：2009/03/15(日) 11:10:45

ＮｅｔＤＢはお金出して研究所で学ぶのか一般的ですよたぶん
わたしの周りではみんなそういった感じです

417 ：デフォルトの名無しさん：2009/03/15(日) 11:30:55

>>408 は COBOLer より頭が悪い

418 ：デフォルトの名無しさん：2009/03/15(日) 11:52:26

>>407　さんみたいな人多いいの？
オープン系からホスト系

419 ：デフォルトの名無しさん：2009/03/16(月) 13:45:39

JavaとCOBOLの連携なんてよくある。
Javaエンジニアだけど、ちと火を吹いてるからCOBOL側のビジネスロジック見てくれ、COBOL知らなくても見れば分かるから！
とかね。
大概の人は後悔するんだけども。

420 ：デフォルトの名無しさん：2009/03/17(火) 23:09:49

COBOLはソースだけ見ても
何がなんだかさっぱり分からないもんな。
Javaの記述になれてれば尚のこと。

421 ：デフォルトの名無しさん：2009/03/18(水) 11:55:55

>>420
おれもCOBOLのソースは可読性最悪だと思うけど、
分からない原因はどことお考えで？

422 ：デフォルトの名無しさん：2009/03/18(水) 13:04:22

Javaはメソッド名から動作に関して想像できるけど、COBOLなんかはサッパリわからんだろ。
グローバル変数しかないからしょーもないサブルーチンまで全て総ナメでソースを追わないといけないしなー。

COBOLはソースを紙に印刷しておいて、それとは別にメモ用紙とペンを持って、
端末画面でソースを検索して、解析ってノリだし。

あきらかにJavaと言うか開発IDEに慣れた身から苦行の嵐だ罠

423 ：デフォルトの名無しさん：2009/03/18(水) 23:04:11

>>421
最大の理由は処理単位が大きすぎること。
全体で関数一つ相当とか無理だろ、みたいな。

PERFORMはあるけど、呼び出し先と呼び出し元が独立してないし。

424 ：デフォルトの名無しさん：2009/03/19(木) 02:00:22

関数ではない。あれは意味のあるひとまとまりの処理。

425 ：デフォルトの名無しさん：2009/03/19(木) 08:04:46

>>424
言語仕様上関数と同じだろ。
それに意味の単位が大きすぎる。

426 ：デフォルトの名無しさん：2009/03/19(木) 08:07:08

PERFORMは返却値を扱う機構がないから、関数ではないわな
ただのサブルーチン

427 ：デフォルトの名無しさん：2009/03/19(木) 14:12:02

おまいらcall知らないの？

428 ：デフォルトの名無しさん：2009/03/19(木) 20:22:11

こやつめｗ

429 ：デフォルトの名無しさん：2009/03/19(木) 23:28:33

ＦＵＮＣＴＩＯＮは？

430 ：デフォルトの名無しさん：2009/03/24(火) 15:36:52

久しぶりにＣＯＢＯＬをやることになった。
Windows系のCOBOL2002だから少しは進歩しているかと思ったら
未だに行番号とかあるし、ＳＱＬ文もＤＢ依存の命令を使おうとしたら
PROCOBOLじゃないとだめだし、デバッガは使いづらいし、もういやだ

431 ：デフォルトの名無しさん：2009/03/24(火) 15:55:04

>>430
行番号省略できるだろ？

432 ：デフォルトの名無しさん：2009/03/24(火) 18:18:56

最新の処理系を採用しても最新の機能は使わせて貰えない不思議。
COBOLだってオブジェクトシステムあるんだぜ！

433 ：デフォルトの名無しさん：2009/03/24(火) 18:55:33

30年前にはPERFORMを多用するって非難されたw

434 ：デフォルトの名無しさん：2009/03/26(木) 22:47:33

まあ、その辺は、javaでもジェネリックス使うなとか言われるからなあ。
理由は「教育コストがかかるから」とかなんとか。

List<Hoge>とか、そんな教育コスト云々の話か？castのほうが怖くねえか？と思わなくもない。

435 ：デフォルトの名無しさん：2009/03/27(金) 12:26:32

「こんなの初めて」

436 ：デフォルトの名無しさん：2009/03/27(金) 14:32:06

>>431
先頭かラム位置からＩＦ　とか書きたいんだＹＯ。
省略可能なら、フリースタイルにしろよってこと。

437 ：デフォルトの名無しさん：2009/03/28(土) 11:48:43

>>434
その安全性を上司に説明すんのが面倒なんだよな

438 ：デフォルトの名無しさん：2009/03/28(土) 14:56:38

>>436
フリースタイルは無理だろ

>>437
バグなんかテストで潰すだろ、的な。

439 ：デフォルトの名無しさん：2009/04/02(木) 14:02:01

>>438
N88BASIC→QUICK BASICとなったような、ドラスチックな変化を望んだのさ。

440 ：デフォルトの名無しさん：2009/04/07(火) 20:39:52

>>430はえらいなぁ
俺なんてNetDBわからなくて、しんだ

441 ：デフォルトの名無しさん：2009/04/09(木) 21:14:58

20歳の新社会人ですがCOBOLを使う事になりました。
COBOLの経験は無いですが最後のコボラーになるのも悪く無いかなと思っています。

442 ：デフォルトの名無しさん：2009/04/09(木) 21:15:45

最後になれるわけないだろ

443 ：デフォルトの名無しさん：2009/04/09(木) 21:37:18

オンラインプログラムは頭おかしくなるよ

444 ：デフォルトの名無しさん：2009/04/09(木) 21:49:25

お気の毒に

445 ：デフォルトの名無しさん：2009/04/09(木) 23:26:17

いくら不景気だからって酷いことする会社もあるもんだな

446 ：デフォルトの名無しさん：2009/04/12(日) 13:09:08

cobolかあ
もう忘れたｗ
ビット操作やったことあるなあ

447 ：デフォルトの名無しさん：2009/04/12(日) 17:30:59

>>441
メインフレーム(汎用機)か?
こういう本が出てるので、参考にするといいぞ。高いけど。
メインフレーム実践ハンドブック
ttp://www.ric.co.jp/book/contents/book_823.html

448 ：デフォルトの名無しさん：2009/04/13(月) 22:07:47

>>447
もう二年早く教えて欲しかった

449 ：デフォルトの名無しさん：2009/04/15(水) 12:42:17

COBOL生誕 50 周年、しかしまだまだ現役 - スラッシュドット・ジャパン
http://slashdot.jp/developers/article.pl?sid=09/04/14/0019209

450 ：デフォルトの名無しさん：2009/04/15(水) 15:56:22

COBOLのプログラマは不足してるよ。
平均年齢は50歳前後だからねえ。
稼動しているCOBOL資産はまだまだ膨大だからねえ。
超大型システムのカーネルでCOBOLはまだ現役だよね、
それをJAVAとかＣに置き換えると言っても、
ストリーム型をオボジェクト型に切り替えるのは大変だよ、
そもそもストリーム型をオボジェクト型に変えるメリットもない。
言語を変えてもストリーム型にしかならないよね。
そうするんだろうね。

451 ：デフォルトの名無しさん：2009/04/15(水) 17:57:01

>>448
出たのが今年なんでな
残念ながら

452 ：デフォルトの名無しさん：2009/04/15(水) 18:06:41

なんか面白そうだ
うちにはないけどｗ

453 ：デフォルトの名無しさん：2009/04/15(水) 20:42:04

派遣切りとかされて仕事が無いおっさんに生活保護とか支給せずに
COBOLやらせりゃいいのにな

454 ：デフォルトの名無しさん：2009/04/15(水) 21:45:40

会社で、今実際に使ってるバッチ処理のCOBOLのソースを見て、
処理してる内容を解析してまとめろって言われた。
数百本ある上に、コメントなしで、意味不明な名前の付け方の変数だらけで、
おまけにGO TO使いまくり。
全然進まない orz

455 ：デフォルトの名無しさん：2009/04/30(木) 00:34:54

保守

456 ：デフォルトの名無しさん：2009/04/30(木) 22:13:38

マジで今更ＣＯＢＯＬとかありえねーよ？

企業とかは汎用機をやめたい為にＣＯＢＯＬ使える奴を捜してるんだぜ
汎用機　→　サーバー　が
ＣＯＢＯＬ　→　ＪＡＶＡ，Ｃ
なわけで誰も新規でＣＯＢＯＬを使おうなんて考えてねーよ
このデータ移行作業が糞面倒（コボラーを捜す）な上に超コスト（人件費糞高い）がかかるわけ
だから、そう簡単には実行出来ないしプロジェクト中止したところもたくさんあるんだＹｏ

ぶっちゃけ表向き汎用機動かしっぱなしで
裏でＪＡＶＡ，Ｃ使って新規作成サーバー化プロジェクトやってもおかしくねーよ

つまり、廃れ始めてるし色々な意味でヤバイ言語なんだよＣＯＢＯＬはよ

457 ：デフォルトの名無しさん：2009/05/01(金) 01:37:59

C#やVBじゃダメですか？
>>456　さん

458 ：デフォルトの名無しさん：2009/05/01(金) 03:41:09

>>447
この本買ったんだけどさ、メインフレームﾏﾝｾｰな話ばっかで５分で飽きた

メモリ管理やらジョブ管理の仕組みの話されても意味ない
そんなもん今時組み込みＯＳだってやってるっての

問題は、ＯＳとかミドルウェアの上に乗っかるアプリから見て、
アプリが動く環境がどう見えるかだろうに、
そういうところはまるで書かれていない

459 ：デフォルトの名無しさん：2009/05/01(金) 09:44:45

>>458
業務AP専業コーダ、乙

460 ：デフォルトの名無しさん：2009/05/01(金) 10:12:54

サーバーサイドでjavaを走らせる奴
うっとおしいので死んでください

461 ：デフォルトの名無しさん：2009/05/01(金) 17:15:44

>>454
似たような境遇だね
バグか仕様か判別不能な記述が一番困る。。

462 ：デフォルトの名無しさん：2009/05/01(金) 18:35:18

>>458
そういった本なら、神保町の古本屋行けば腐るほどある。

463 ：デフォルトの名無しさん：2009/05/02(土) 21:50:50

>>456
廃れ始めて・・・と言われて、もう10年どころでは無いんだが
オープン系しか知らない青二才か？ｗｗｗｗｗ

金融系をはじめ基幹系中枢部門では、ＣＯＢＯＬ以外の選択肢は
存在しない訳だが何か？

ＵＩを重視するとか、安定性を求めないのなら
オープン系が選択肢だろう。

464 ：デフォルトの名無しさん：2009/05/02(土) 22:12:14

ＣＯＢＯＬは廃れているが需要はあるから言語はなくなることはない
うちの部署ではＣＯＢＯＬを使える人がいないから多少重宝されている

465 ：デフォルトの名無しさん：2009/05/02(土) 22:13:18

>>459,463
コボラーの発想だな
今ではCOBOLなんて選択肢は、銀行ですらない
COBOLを捨てなかった銀行は、軒並み傾いていて、
オープン系で構築した銀行はすごいコストダウンに成功した

これが現実

466 ：デフォルトの名無しさん：2009/05/02(土) 22:32:19

これは自社の宣伝乙と言わざるを得ない。
軒並み傾いたとか流石に痛々しいな。

467 ：デフォルトの名無しさん：2009/05/02(土) 22:56:15

今ふと思ったんだけどCOBOLの浮動小数点計算って10進でやってるんだったよね？
2進だと四捨五入とか切捨てで誤差が出るためだったと思うんだけど、COBOL以外で
10進で計算してくれる言語ってあるのかな？

468 ：デフォルトの名無しさん：2009/05/02(土) 23:34:41

今時は、わざわざ10進で計算するより、やたら大きく精度を持っておくのが流行らしい。
Javaだと、BigDecimal/BigIntegerのような、任意精度の値を扱うクラスがある。
VBや.NETだと、Decimal型が29桁の有効桁数を保持できる。
ちなみにdoubleの有効桁数は15桁。

469 ：デフォルトの名無しさん：2009/05/03(日) 00:12:58

浮動小数点の計算をBCDでできないと意味ないし、
整数演算だったらバイナリーの方が計算楽だしね。

470 ：デフォルトの名無しさん：2009/05/03(日) 00:21:26

>>465
自分の狭い経験＝世間の常識と信じて疑わないアフォって
どこにでも居る罠

以前、某金融系の案件で、ＵＩは、オープン系ながら
それ以外は、UNIX COBOLで構築してたが　何か？
コストダウンしても、安定性が低ければ、意味ない件
え？安定性なんて関係ないシステムなのかｗｗｗｗｗ

471 ：デフォルトの名無しさん：2009/05/03(日) 02:06:21

ttp://pc11.2ch.net/test/read.cgi/linux/1222291980/
この糞ソフトCOBOLで作られたため、大変悪評だよ。

472 ：デフォルトの名無しさん：2009/05/03(日) 02:28:02

この糞ソフトJavaで作られたため、大変好評だよ。

473 ：デフォルトの名無しさん：2009/05/03(日) 04:40:10

某メガバンクも今後の開発ではCOBOLを使いまへーんって方針だしちまったしなあ。

この冷え込み方は、昔っから度々言われていた「COBOLはなくなる論」ってのと
レベルが違うと思うんだ。

474 ：デフォルトの名無しさん：2009/05/03(日) 05:27:23

>>470
信頼性なんかCOBOLにはない
メインフレームのハードの信頼性でしかない
技術の本質が分からないのが、コボラーだろ

>>473
そして、経営の本質が分からないのもコボラー
COBOLアプリの硬直性は救いようがない経営上のリスクだから

475 ：デフォルトの名無しさん：2009/05/03(日) 06:13:57

コボルみたいに仕様がきっちり決まってる言語ってAdaくらいしかないんじゃないの？
でもAdaに移行したって聞かないからやっぱCOBOL使ってるのかもな

476 ：デフォルトの名無しさん：2009/05/03(日) 06:46:26

>>475
仕様がきっちり決まっているのなら、なぜマイグレーションの時に
コンパイラ間の非互換の問題が出るのかｋｗｓｋ

477 ：デフォルトの名無しさん：2009/05/03(日) 12:03:34

>>474
あー言えば、こう言うで、延々とやってろ　カス。

478 ：デフォルトの名無しさん：2009/05/03(日) 14:56:51

450 ：デフォルトの名無しさん：2009/04/15(水) 15:56:22
COBOLのプログラマは不足してるよ。
平均年齢は50歳前後だからねえ。
稼動しているCOBOL資産はまだまだ膨大だからねえ。
超大型システムのカーネルでCOBOLはまだ現役だよね、
それをJAVAとかＣに置き換えると言っても、
ストリーム型をオボジェクト型に切り替えるのは大変だよ、
そもそもストリーム型をオボジェクト型に変えるメリットもない。
言語を変えてもストリーム型にしかならないよね。
そうするんだろうね。

479 ：デフォルトの名無しさん：2009/05/03(日) 15:11:45

COBOLのソース見たけどわけわかんね。
生産性の低さがCOBOLの流行らない理由じゃないの？
俺ならCOBOLなんて速攻で止めてLISPに変えるわな。

480 ：デフォルトの名無しさん：2009/05/03(日) 22:05:06

俺なら農業に転職したい

481 ：デフォルトの名無しさん：2009/05/03(日) 22:17:06

COBOLはそんなに悪くない言語と言うかああいうモンだと思うが、
老害が自分の居場所を守るために、アレコレとやっているから、
世代交代しつつある現場の人間が「COBOLなんかヤめようぜ」と
言っているのだろう。

と言うか漏れもその一人だけど、COBOLerはマジでウゼェ。
他者と協調するって事を知らんヤツが多すぎる。

482 ：デフォルトの名無しさん：2009/05/04(月) 15:09:19

今時COBOLにしがみついてる奴は、云われたことしか出来ない奴。
自発的に学ぶ人間は、いろいろ学んでるし普通にVBくらいは弄れる。

COBOL好きにはCOPY句とかの圧縮記法とかの効率性にしびれた人がいたな。

483 ：デフォルトの名無しさん：2009/05/04(月) 21:11:33

>>482
あんな抽象化もへったくれもないナイーブなテクニックに、一体何の意味があるのかと

484 ：デフォルトの名無しさん：2009/05/05(火) 14:51:41

>>482
それでも今時、ＶＢかよｗｗｗｗｗ

485 ：デフォルトの名無しさん：2009/05/05(火) 15:01:47

VBでいいよ。　つまらない仕事してるもの。

486 ：デフォルトの名無しさん：2009/05/05(火) 16:01:05

VBもC#みたくyieldとか実装してほしいお

487 ：デフォルトの名無しさん：2009/05/05(火) 23:29:49

久しぶりにキチンとした在庫のある本屋に行ってみた。
COBOL本の隣にhaskelと、Ocamlがおいてある。
なんか変なのｗｗ

488 ：デフォルトの名無しさん：2009/05/05(火) 23:57:09

>>487
マイナー言語の棚だろ。SmalltalkもPascalもBasic（N88)も同じ棚だぜ＠神保町三省堂

489 ：デフォルトの名無しさん：2009/05/06(水) 12:33:24

マイナー言語でプログラムを組むのもなかなかオツなもんですよ

490 ：デフォルトの名無しさん：2009/05/06(水) 12:38:48

python見つけた頃には、マイナーだったのにこんなに流行っちゃってもうやる気茄子でう。

491 ：デフォルトの名無しさん：2009/05/06(水) 18:22:58

捻くれてるねぇ

492 ：デフォルトの名無しさん：2009/05/06(水) 19:21:58

Pythonに関しては（日本で）メジャーになる前に既に無しでは戻れないくらいに
普及してしまった感があるが。

逆にRubyは無くても困らんのだが流行っているな。

493 ：デフォルトの名無しさん：2009/05/07(木) 13:19:35

優秀なプログラマはいくつものプログラミング言語を使いこなすものだが、現在の求人市場において、実際に需要の高い言語はどれなのだろうか。
Gustavo Duarte氏が求人サイトDice.com等で調べた結果によると、アメリカにおいてはJava(16479件)、C++(8080件)、C#(7780件)、
JavaScript(6749件)、Perl(5710件)、PHP(2641件)、Python(1408件)、COBOL(1207件)、Ruby(769件)、Lisp(33件)といった感じらしい。
とりあえずJavaとC/C++/C#、あとJavaScriptを覚えれば、当分仕事には困らないようである。COBOLのしぶとさも目立つ。
ちなみにHaskellやOCamlの求人は10以下だったそうだ。成長率では、C#とRubyが飛び抜けた伸びを示している。

http://slashdot.jp/developers/article.pl?sid=08/04/06/2313251
mhattaによる 2008年04月07日 8時45分の掲載

494 ：デフォルトの名無しさん：2009/05/07(木) 14:18:25

Lispの健闘に感心した

495 ：デフォルトの名無しさん：2009/05/08(金) 00:10:02

COBOL(1207件)
Ruby(769件)

Lisp(33件)

496 ：デフォルトの名無しさん：2009/05/08(金) 23:43:11

こぼるの案件数とLispの圧倒的抽象力がコラボすれば、今後１００年は安泰ってことか

497 ：デフォルトの名無しさん：2009/05/09(土) 01:57:07

裏でLispで動いてたゲームソフトもあったなぁ。
ま、COBOLは健在つか、言語とビジネスロジックの過密着が
問題になるくらいベタなやつ。　会計がリアルタイム処理に
完全移行する時代にならんと捨てられることも無いだろう。
帳票扱いも、Cで書いたらエライ手間。

498 ：デフォルトの名無しさん：2009/05/09(土) 02:43:05

>>497
>帳票扱いも、Cで書いたらエライ手間。

memcpy() とmemcmp() の嵐なんだよね

499 ：デフォルトの名無しさん：2009/05/09(土) 08:27:45

COBOLの記述方法を基準にしたら、どんな言語で書こうとエライ手間に決まっていると思うが。

と言うか今時の言語だとIDEのアシスト（型チェックとかも）があるから、
cpyやcmpの嵐でもCOBOLほど苦に感じない。

500 ：デフォルトの名無しさん：2009/05/09(土) 16:56:41

>>499
まあねぇ。　COBOLで覚えた技をどしても使いたいって人は
いるみたいだ。

501 ：デフォルトの名無しさん：2009/05/10(日) 03:49:58

実際問題、やっぱ事務処理は事務処理用言語の方が生産性高いんじゃね？
WEBアプリもWEBAP特化言語の方が生産性高い、と、スクリプトの人々は言うし。

502 ：デフォルトの名無しさん：2009/05/10(日) 05:12:24

そりゃそうだろ
例えは悪いがC++のSTLだってタイプした量の10倍以上の
意味を持ってるしコードもその程度肥大化する

要するに一つのワードにどの程度の重さを持たせてるかって
事だよな

Cはその重さが異様に軽いので何をやらせるにも大変

503 ：デフォルトの名無しさん：2009/05/10(日) 09:18:09

そりゃ、横長ＤＢを全件READして、ひたすらMOVやADD繰り返すだけの
「業務ロジック」をJavaにそのまま移植したら生産性低いだろ。

普通にデータはSQLで読み書き計算し、UIの部分をJavaなんかの言語で処理すれば
現代ではもっとも効率がいいだろう。

ただ昔の人って基本設計がド素人なのが多いので画面入出力・入力チェック・データの読み書き・
業務ロジックがグダグダに構成されていて移植困難だから「COBOLは今でも健在」とか
言われてるだけだろうなぁ。

んなん、設計段階からリニューアルする事がゆるされるならCOBOLのみとJava+SQLと
どっちが生産性高いか？きかれりゃ、間違いなく後者の方が生産性高いし。

504 ：デフォルトの名無しさん：2009/05/10(日) 10:25:13

固定長でBCDを使ったデータセットの使用が所与の条件だったら、
COBOL以外の選択肢は考えられんな。

505 ：デフォルトの名無しさん：2009/05/10(日) 11:58:51

戦闘機と旅客機の違い、
５０ｃｃチョイ乗りと４０ｔフルトレーラ、
漁船とマンモスタンカー、豪華客船

そんなとこかね。

506 ：デフォルトの名無しさん：2009/05/10(日) 12:00:46

>>504
FORTRAN、PL/1でも使えますが。
PL/1 を知ってるだけで、使ったことが無い。

507 ：デフォルトの名無しさん：2009/05/10(日) 14:54:48

コボラーの言う生産性って、コード行数の生産性でしょ？

コボラーのおかげで、ビジネスの生産性は落ちっぱなし

508 ：デフォルトの名無しさん：2009/05/10(日) 22:16:10

>>504
DB2/400とかはCOBOL以外にRPG,C,C++,Javaで使えたけど。
COBOLerの心のよりどころがソレってのも悲しいよな。

509 ：デフォルトの名無しさん：2009/05/12(火) 22:16:53

>>507
コード行数の生産性の話とおもいきや、ビジネスの生産性とはどういう事？

仮にCOBOLなら月10,000行の生産程度で作れる処理とする。
Javaだとコーディング量で測れない作業があり、2ヶ月や3ヶ月掛けないと作れない。
しかし、コボラー達が1ヶ月でシステム収めやがるから、Javaでは単価辺りの原価率が上がらないって事？

510 ：デフォルトの名無しさん：2009/05/13(水) 06:43:38

単にコボラーは「俺5000行のプログラム作っちゃった。俺SUGEEEE」ってアフォが多いだけだろ。

OOな設計は稀にしても、便利なクラスを作ったりして再利用性を高めたり、
便利なクラスの使い方を見つけてなるたけ、コード記述量を減らして品質とか生産性
あげる努力をしている。

つかコーティング量で測れない部分があるのはCOBOLも一緒だと思うが、
ソース管理やテスト系なんかはむしろJavaの方が遥かに進んでいるし。

511 ：デフォルトの名無しさん：2009/05/13(水) 18:06:55

>>507
COBOLの頃はFP法全盛だから、行数ではなく、機能数。

512 ：デフォルトの名無しさん：2009/05/13(水) 22:50:34

>FP法全盛

一時期流行ったけどマッハで廃れていったな。

513 ：デフォルトの名無しさん：2009/05/13(水) 22:56:37

クラス化うんぬん資源の再利用は、形態や手法は違えどCOBOL以外の言語もあたりまえに行うべき工程
それを鼻息荒くJavaの優位性として語るポイントとしては弱いとお思うんだが。

それにしても >>510 の関わっているプロジェクトは、JavaにしろCOBOLにしろ、これから船出感が有って面白そうだなあ。

514 ：デフォルトの名無しさん：2009/05/13(水) 23:02:11

とりあえずCOBOLerにはリファクタリングって概念ないと思うけど。

再利用と言うかコピー新規で内容が数行しか違わないサブルーチンが５・６個ありますが、なにか？
って感じだったなぁ。

営業日算出SUBとかで、「これが銀行用」「これが会社用」「これが普通のカレンダー用」で
○○年までVer、○○年までVerてな感じで･･･。

アフォかと。

515 ：デフォルトの名無しさん：2009/05/14(木) 06:37:57

実際に走ってるコードとソースは別というのを知らん野か。

516 ：デフォルトの名無しさん：2009/05/14(木) 06:41:20

>>510
論理設計さえしっかりしとけば構造化プログラミングだけでバグ数0でやれるのがCOBOL。
正体不明のバグだして右往左往するJavaとは違うのだよ。

517 ：デフォルトの名無しさん：2009/05/14(木) 07:31:43

>論理設計さえしっかりしとけば構造化プログラミングだけでバグ数0でやれるのがCOBOL。

そんな理想郷は見たことありません。

紙に手書きされたフローがあって、グダグダに修正されたプログラムを見せられて
バグ山盛りのCOBOLのプログラムをやまほど見たけど。

で、アベンドしたら「想定外の使い方です。これは仕様です。文句があるなら金払え」
ってノリです。

518 ：デフォルトの名無しさん：2009/05/14(木) 23:03:37

とりあえず、JAVAやってるひとは
業務ロジックはCOBOLで動いて、UIだけJAVAなんて仕事はしない方がいい。
腕がおちる。

519 ：デフォルトの名無しさん：2009/05/14(木) 23:13:44

業務を全部Cで書けばいい
頭がよくなるぞ
バグてんこ盛りだけど＼(^o^)／

520 ：デフォルトの名無しさん：2009/05/14(木) 23:23:24

理想郷に辿りつきました。

紙にすら書かれていない隠しクラスやメソッドがあって、行き当たりバッタリで作られたプログラムを見せられて
スパゲッティー化されたバグ満載のJavaプログラムがやまほど。

で、つい数年前導入したばかりというのに、ブラウザーやOS、Javaのメジャー、マイナーバージョンアップが有るたび
「動作保障外の環境です。これは仕様です。文句があるなら金払え」ってノリです。

難問を解決するだけで当分は飯が食えるとは、もうこの上ないシアワセです。

521 ：デフォルトの名無しさん：2009/05/15(金) 00:06:07

JavaでスパゲティなんてCOBOLのソレに比べたら屁みたいなモンだから
素直に羨ましいな。

522 ：デフォルトの名無しさん：2009/05/15(金) 00:11:10

Javaは一応ALGOL系だからスパゲッティに書く事が
そもそも困難な言語

523 ：デフォルトの名無しさん：2009/05/15(金) 00:30:37

COBOLのCOPY文がウザイんですが。
パッと見てどの項目使って処理してるかさっぱりわからん。
まあコンパイルリストに全部出てくるけど。

524 ：デフォルトの名無しさん：2009/05/15(金) 01:28:05

仕様書無しの場合、ヘボいOOのソースの読み難さは、ヘボい構造化の比では無い罠

525 ：デフォルトの名無しさん：2009/05/15(金) 01:31:11

そのヘボさを補うツール群があるわけだが、今時は … … …

526 ：デフォルトの名無しさん：2009/05/15(金) 01:35:01

ALGOL系ちゅうのは頭にあったが、そうか、そうなのか。(´･ω･`)ショボーン

COBOLはもうそろそろ１年になるが、かなり入り組んだソースも、へえそなのかぁ、こうしたいから
こう処理しようと・・・。
じゃあこの辺りで、要件を確定する計算必要じゃねえ？と、いった具合に、設計者が何をやらせようか、
思想が読み取りやすく思ってしまった。
何というのか、派手さはないが、実行環境も含め結構安定感を感じると言っていいのか・・・。

バッチ処理の処理手法としては、一度に100万件、200万件を一括処理する手法は、参考になる部分も
多くCOBOLは結構俺の肌には合ったようだった。

Javaの方といえば、絶対プログラム全体のイメージを固めずに、動かしながらその都度ソース書いてるぞ！
こんなのソース納品されても見たかねえよ！とか、プログラマー毎の癖を覚えたり、矯正するのが疲れて
来ているようだ。

その反面、酷いシステム屋だと設計書と中身が違っていて、いきあたりバッタリ開発された物だと、
気分的にとても追えた物じゃ無いが、障害発生率も高く、仕事が途切れず発生するので結構美味しいと思う自分が要る。

527 ：デフォルトの名無しさん：2009/05/15(金) 06:43:28

いきあたりばったりは言語関係ない。
無能なドカタがつくるとドレも似たようなモノ。

バッチ処理の手法云々も、あの方法しか出来ないので参考もなにもないけどナ。
ほぼ全ての言語でああいった一括処理の手法が普通に出来る。

528 ：デフォルトの名無しさん：2009/05/21(木) 01:20:19

agepan

529 ：デフォルトの名無しさん：2009/05/21(木) 01:25:36

COBOL初心者です。
IBMや富士通ではVSAM、ISAMを使ってデータを格納してる場合が多いですよね。
DB2やORACLEを実装した場合、SQLでそれらのデータセットをガチでアクセスできますか？

530 ：デフォルトの名無しさん：2009/05/21(木) 03:51:38

普通にできます。

531 ：デフォルトの名無しさん：2009/05/27(水) 01:42:19

agetoku

532 ：デフォルトの名無しさん：2009/05/31(日) 11:35:19

age

533 ：デフォルトの名無しさん：2009/06/13(土) 21:20:10

一応アゲ

534 ：デフォルトの名無しさん：2009/06/14(日) 04:49:22

索引純編成ファイルって、まだあるんだねえ
懐かしいねえ。

535 ：デフォルトの名無しさん：2009/06/18(木) 16:57:15

COBOLの良い所は、レコードとファイルを結び付ける事が簡単なことじゃないかな。

COBOLは使ったことないけど。

Java は何でも出来るけど、
何やるにしても面倒になりがちな気がする。

Javaは使ってるよ。

536 ：デフォルトの名無しさん：2009/06/18(木) 23:02:27

>COBOLの良い所は、レコードとファイルを結び付ける事が簡単なことじゃないかな。

awkの方が簡単じゃね？

レコードにカラムが100個くらい並んでいるクソ設計ならCOBOLが楽だろうけど。

537 ：デフォルトの名無しさん：2009/06/19(金) 22:10:42

javaが「何でも出来る」と感じるほど使い物にならんってことか

538 ：デフォルトの名無しさん：2009/06/19(金) 22:22:55

Javaを知らないCOBOLerの曲解が正直キモい

539 ：デフォルトの名無しさん：2009/06/19(金) 22:54:09

DSLが汎用言語より簡単なのは当たり前だよな。

540 ：デフォルトの名無しさん：2009/06/20(土) 01:16:35

>>539
まあ、そうだね。

COBOL は、その出生から、確かにビジネス(事務)向けの DSL だね。

事務的な処理をするソフトウェアを効率よく、
しかも、設計書のように整った形に書ける。

それが、 COBOL の思想だったはずだし、
事務的な処理がこの世からなくならない限りは、
その存在意義は残るだろうね。

それに、何より、これまでの蓄積があるからね。
それは、 FORTRAN と同じだね。

Java は、本来、家電向けのアプリを作るための言語だった。
今も、携帯関係に強いし、セットトップボックス(テレビにつなげる奴)用の
Java開発環境もあるらしい。

ところが、ワークステーション屋サーバー屋の Sun が作ってたから、
ビジネス方面に使いたかったろうし、使えると見て、
そちら方面に力を入れたんだろう。
言語設計自体は、洗練された汎用言語の物だったし、
だから、当然の如くビジネスにも使えた。

言語設計は、どうしても後発の Java の方がきれいで、
多方面にそれなりに使いやすくなっている。
ただ、 COBOL は事務専用言語として汎用言語には無い強みがあるはず。
それ以上でも、それ以下でもないな。

541 ：デフォルトの名無しさん：2009/06/20(土) 01:56:03

>>540
結局何も言ってないのと同じだね

542 ：デフォルトの名無しさん：2009/06/20(土) 06:09:19

昔は計算機が貴重だったから、すべてを計算機に合わせるというやり方もありだった。

事務処理をするなら、今はビジネスに合わせる方が、合理的。
COBOLは計算機側の効率を考えて、データを格納するように設計されたが、
それはビジネスの観点とは異なる。

COBOLはもはや事務処理言語として落第点。
COBOLで書いた今までのアプリは不良資産となってしまった。

543 ：デフォルトの名無しさん：2009/06/20(土) 06:24:27

COBOLはよく「事務処理に向いている」とか言うけど
現実には「事務処理にしか使えないが、その事務処理ですら
他の言語よりも使いにくい」と言う結論だけど。

「COBOLでなきゃ出来ない」とか「COBOLが一番効率的」ってケースは存在しない。

544 ：デフォルトの名無しさん：2009/06/20(土) 13:00:51

おまいら javaってそんなに事務処理のプログラム開発に使われてんの？
処理遅いしメモリー食いまくりで大規模なプログラム開発に向いてないように思うんだけどな。

545 ：デフォルトの名無しさん：2009/06/20(土) 13:50:34

Javaでできる、と言う奴は居るが、実際に組ませると5年で1円も誤差が出るような
プログラムを書いてくるんだが。

546 ：デフォルトの名無しさん：2009/06/20(土) 15:04:35

COBOL→メモリ食わない
COBOL→誤差出ない

こういう短絡思考が痛すぎる

547 ：デフォルトの名無しさん：2009/06/20(土) 15:04:36

COBOL→メモリ食わない
COBOL→誤差出ない

こういう短絡思考が痛すぎる

548 ：デフォルトの名無しさん：2009/06/20(土) 15:55:03

BCD演算すればよかろうがカス

549 ：デフォルトの名無しさん：2009/06/20(土) 16:06:03

BCDパッケージの信頼性を誰が保証してくれるかの問題が出てくるよ

550 ：デフォルトの名無しさん：2009/06/20(土) 16:44:43

COBOLのパッケージは誰が保証してるんだよ

551 ：デフォルトの名無しさん：2009/06/20(土) 16:55:17

COBOLはCSVファイル扱うのが、非常にめんどうだった。

昔、CSVファイルで出力する要件があったときに、
すごくメンバーの作ったプログラムの品質が悪かったんだよね。

552 ：デフォルトの名無しさん：2009/06/20(土) 18:53:05

COBOLは厳しい基準をパスしなければCOBOLを名乗れないんじゃなかったっけ？

javaは一応利権がらみでグダグダ言う所はあるけど、
演算精度や処理結果にグダグダ言う奴はいないだろ？

553 ：デフォルトの名無しさん：2009/06/20(土) 19:33:03

＞BCDパッケージの信頼性を誰が保証してくれるかの問題が出てくるよ

IBMのJDKでも使ってサポート契約結べば保障してくれるけど。
つか商用鯖で動かすOSやミドルウェアはベンダーがサポートしてるけど。

COBOLがメモリ食わなくて計算誤差でない、なんて幻想だな。
COBOLでもメモリ食いなプログラムはあるし、誤差が発生する。

＞COBOLは厳しい基準をパスしなければCOBOLを名乗れないんじゃなかったっけ？

厳しいもゆるいもCOBOL-88だったら満たすか満たさないかだけだろ。

そもそも事務処理特化言語のおかげで各処理系に依存している部分が多いし、
画面遷移とかはバラバラだし。

１０進演算とかの演算処理も処理系依存の部分があるので、そういった面では
Javaの方がキッチリしている。と言うかJavaDocのAPIとか読んでいると
くどいくらいに使用法に関して注意書きしているだろうに。

554 ：デフォルトの名無しさん：2009/06/20(土) 21:23:00

要するに、

>Javaでできる、と言う奴は居るが、実際に組ませると5年で1円も誤差が出るような
>プログラムを書いてくるんだが。

というのは嘘だな。

COBOLでも数円単位の誤差を出す馬鹿はいるし、Javaでも正確なプログラムを
書いてくる奴はいる。

要するに言語ではなくプログラマーの腕次第というわけだ。

555 ：デフォルトの名無しさん：2009/06/20(土) 22:19:27

どんなにJava厨が必死になろうともプログラマの質の低さはごまかせない。
8割はBCD演算がどうとか全く意識せずにlong型を使う。

556 ：デフォルトの名無しさん：2009/06/20(土) 22:29:01

>>555
そりゃチュブに下請けに出す位だからな（笑）

557 ：デフォルトの名無しさん：2009/06/20(土) 23:01:52

計算を全て整数でやっていた日本人のCOBOLerを知っている身としてはコメントが難しいな。

つか金融系の仕事していてlong使うヤツなんかいるのか？
2chの見過ぎだと思うが。

実在するならその会社名を晒してみろよ。ｗ

558 ：デフォルトの名無しさん：2009/06/21(日) 00:21:01

浮動小数点の演算で誤差がでないアルゴリズムなんて不可能だろ。
COBOLの場合はその誤差が規定されてるんじゃなかったっけ？

559 ：デフォルトの名無しさん：2009/06/21(日) 00:39:37

丸めの話が混じると一気にカオスになる。
計算途中で丸め処理が入ったりすることも結構あるからな。

560 ：デフォルトの名無しさん：2009/06/21(日) 07:02:06

＞COBOLの場合はその誤差が規定されてるんじゃなかったっけ？

誤差を仕様と言い切るか、少数点以下第４位まで四捨五入やら切り捨てと
プログラム仕様にて決めて、後はその範囲内でシコシコと計算するだけ。

ここで、>>559の言う様に「このプログラムでは切り捨て」とか「このプログラムでは
四捨五入」とかきて、酷いときは「このプログラムは少数点以下第２位で算出」とか
あるので、現実問題COBOLで1円単位の誤差なんて日常茶飯事だ。

金融系だと「営業店ブロックの残高を合計してから平残」と「支店毎の平残を算出
してからブロック毎の平均」とかやればどんな言語だろうが、誤差は出る。

誤差が出るのは仕方ないが、そういうのを仮にSQLでDecimal型を使いつつ
プルーフしていくと、大抵COBOLで設計されているシステムの誤差の大きさには
感動を覚える。ｗ

いや、COBOLerに言わせれば仕様なんだろうし、それは仕方ないとこっちも思うが、
そんなCOBOLerが声だかに演算精度を自慢しているとなんだかな？ってのはある。

561 ：デフォルトの名無しさん：2009/06/21(日) 08:50:13

>>557
>つか金融系の仕事していてlong使うヤツなんかいるのか？

いるよ。JavaじゃなくてVB.NETだったからdoubleだけど。
初めて聞いたときはひっくり返ったわ。

ちなみに名前は出せん。

562 ：デフォルトの名無しさん：2009/06/21(日) 11:28:44

おまいらもうちょっと勉強してから言えよ

COBOLは式の計算途中の端数処理が言語仕様で決まっているんだ
普通の言語は、そういう細かいところは、実装者に任せるんだけど
コボラの言ってる誤差云々は、こういう意味。
コボラはCOBOLしか知らないから、他の言語とどこが違うか説明できないんだよ。

COBOLって四捨五入は言語機能としてあるけど、
切上げは未だに +0.9 してとかマジックナンバーでやらないといけない変な言語だ
端数端数ってうるさいくせに
負の数の端数処理なんか、考えたこともないんだろう、コボラは

563 ：デフォルトの名無しさん：2009/06/21(日) 11:49:01

一応、サンプル出しておくと

z = a/b + c/d

とかがすべてのコンパイラで同じ結果になるように言語仕様が決まっているってこと

随分くだらないことに拘っているんだな、という貴方は正常
これはすべて井の中の蛙が為せる業

564 ：デフォルトの名無しさん：2009/06/21(日) 20:09:51

＞いるよ。JavaじゃなくてVB.NETだったからdoubleだけど。

Javaじゃねーし。
COBOLerの難癖も大概にしとけよ。

しかも名前出せないんじゃ脳内妄想と言われても仕方ない。

565 ：デフォルトの名無しさん：2009/06/21(日) 21:45:36

でも、JavaにしろCにしろ、海外のサンプル見てると通貨をdoubleであらわしている例が多いね。
てか、ほとんどがdoubleか。

まぁ、奴ら補助単位があるからdoubleなんだろうけど、見るたびに違和感を感じてしまう。
そういうの読んで言語覚えただけで、まともな教育を受けてないとしたら、doubleで実装してしまう
奴も居るのかも知れんなぁとは思う。

でも、それって言語の問題ではないわな。

566 ：デフォルトの名無しさん：2009/06/21(日) 22:32:52

doubleは整数の範囲では誤差が出ないし有効桁数が
16桁保証されているから使われるんでしょうね

C++ならBCD型をユーザ定義して使ったり初めからメーカー側
で用意してくれている事もありますが

567 ：デフォルトの名無しさん：2009/06/21(日) 22:50:58

うちはJavaしかやってないが、コーディング規約でfloat/doubleは使用禁止。
BigDecimal使え、ということにしている。

568 ：デフォルトの名無しさん：2009/06/21(日) 23:23:40

BigDecimal見てみたら、powerはあるけどlogがないね。
金融でも使いそうな気がするんだけど。
あるいは、そういう分野はFortranの出番か？

569 ：デフォルトの名無しさん：2009/06/22(月) 00:08:38

漏れはスパコン使ったことないのだが計算最速伝説はFortranなのか。

570 ：デフォルトの名無しさん：2009/06/22(月) 00:12:08

>>569
いやC/C++でもそのコンパイラがrestrictあるいは__restrictを
サポートしていたらFortranと変わらない

問題はポインタの範囲が重なるエイリアス問題があって最適化
が効かないので一般的にはFortranの方が速いとされているんだ

でもrestrictはそれを承知でいいから最適化してくれというコンパイラ
への指示なのでこれが使えるとFortranのアドバンテージはなくなる

571 ：デフォルトの名無しさん：2009/06/23(火) 10:12:16

俺はfortranが速いのはベクトル計算に特化した最適化が可能だからと聞いたけどなぁ。
それと後ライブラリーの質かな。
でもそんなのはベクトルプロセッサーを持ってないパソコンだと意味無いし
うちのパソコンに入ってるCとfortranのコンパイラを見る限り
そんなに差はないよ。

572 ：デフォルトの名無しさん：2009/06/23(火) 10:26:51

今はCコンパイラの質の向上に特に力が入れられているから
実質上差はなくなってきてるよ

CodeGearとかのコンパイラは別として、M$とかIntel製のCコンパイラが
吐くバイナリは元のソースの見当が付かない位に最適化される

573 ：デフォルトの名無しさん：2009/06/23(火) 10:33:19

>>572 スパコン上のコンパイラの話じゃなかったのか？

574 ：デフォルトの名無しさん：2009/06/23(火) 12:11:32

COBOLの言語仕様でできないこと
1行改行して終了

575 ：デフォルトの名無しさん：2009/06/23(火) 20:56:07

時々思うことですが、
新人にオブジェクト指向的な言語を習得させるのは
言語もさることながら、フレームワークなど、個人が知識および知恵を蓄積する必要があり、
まともに使えるようになるのに時間が掛るんです。
使いこなせるようになった人の場合は生産性が飛躍的に伸びる傾向があるというところでしょうか。

初期の段階での習得のしやすさでは生産性はCOBOLやRPGだと思いますが、
あくまでも使いこなせる人と比較した場合はどこかの時点で逆転するんでしょうね。

汎用機およびメインフレームのターミナル、ファイル、プリンタなど限定されたの
機能および安定度によるところが大きいのではないでしょうか

576 ：デフォルトの名無しさん：2009/06/23(火) 21:22:10

>>575
もうメインフレームみたいな硬直したハードじゃビジネスが成立しないからな
今時汎用機なんて言ったら笑われるで

577 ：デフォルトの名無しさん：2009/06/23(火) 21:45:47

>>576
社会基盤として最重要で、なおかつ汎用機ではないと実現できないものとか
そういう新しいニーズがないと先細る一方なんでしょう。
大抵はPCサーバで十分ですからね。

578 ：デフォルトの名無しさん：2009/06/23(火) 22:48:22

>>575の考えるマトモの領域がドコにあるのか知らないけど、
JavaとRPGを対象として単純なCRUDなアプリを組むだけならRPGの方が生産性は上だろう。

が、RPGとPythonとか比較するとPythonの方が圧倒的に生産性は上だし習得も容易だ。

でも、Pythonはメモリ食いだしスピードもRPGと比べるまでも無いノリだから
単純な比較は意味ないな。今はPCサーバの性能向上で気にならないレベルではあるが。

個人的にはオブジェクト指向言語だからと言って企業は盲目的に新人教育言語としてJava
教えるのはヤめて、PythonとSQLさえ教えておいて欲しい。

＞使いこなせるようになった人の場合は生産性が飛躍的に伸びる傾向があるというところでしょうか。

正直、そのレベルに到達できる人は少ないと感じるが。
オブジェクト指向云々よりもな正規表現やらSQLのクエリをスラスラ書ける方が
現場で役に立つからなぁ。

COBOLerがログから必死で検索したり、印刷したダンプを目を細めながら追いかけているのは
現代においてはマヌケだし。

579 ：デフォルトの名無しさん：2009/06/23(火) 23:32:22

要約するとCOBOL VS Javaスレですが、下記のレイヤーに分かれるんでしょうか。
HW層メーカー固有ハードウエア VS オープン系ハードウエア
OS層　メーカー固有OS VS オープン系OS
DB層横長テーブル VS 正規化されたDB
Language層手続き型言語 VS オブジェクト指向
その他帳票（とくに複写で大量印刷）

＞オブジェクト指向云々よりもな正規表現やらSQLのクエリをスラスラ書ける方が
正規表現やSQLは必須ですね。

＞COBOLerがログから必死で検索したり、印刷したダンプを目を細めながら追いかけているのは
＞現代においてはマヌケだし。
そうですね。もう少し理論的な仕事のやり方が良いと思います。

580 ：デフォルトの名無しさん：2009/06/23(火) 23:43:32

>＞オブジェクト指向云々よりもな正規表現やらSQLのクエリをスラスラ書ける方が
>正規表現やSQLは必須ですね。

入力文字列の妥当性チェックを正規表現で実装したら
「他の担当者がメンテできないような物を使うな」って叱られた事があるな。
if文と文字列操作関数で実装するのが当然だとかで。

581 ：デフォルトの名無しさん：2009/06/23(火) 23:49:11

短期的に現場で役立たせるためには、OOPLより必要なものは多いね。
でも、そればっかりやらせてると、次代の人材が育たない。

あと、SQLは大事だと思うけど、SQLのテクニック的な部分だけやってもしょうがないと思う。
DB設計が出来る用にまでなって欲しい。これがきちんとできる人は、OOにも対応しやすいと思う。

582 ：デフォルトの名無しさん：2009/06/23(火) 23:50:48

>>580
「正規表現を使えないような技術者なんて居ませんよ。」
しれっと、言ってやれ。

後のことは知らんが、そんな所にいつまでも居ないほうが良いだろ。

583 ：デフォルトの名無しさん：2009/06/24(水) 00:03:34

Javaもエキスパートになればなるほど、他人から理解されにくいノリがあるけど。

病気みたいにinterfaceを強制されたり、意味あるのか胡散臭い継承使えとかな、
ゲームプログラムみたいな分野ではあの手の設計は意味あるとは感じるが、
事務処理だと、関係なくねーか？って規約があったりなかったり。

DB設計は言語も出来て当たり前だけど、OOのフレームワークに引っ張られすぎない様に
バランス感覚が必要なのはあるな。
COBOLerの横長は酷いけど、なんでもサロゲートキーやらAutoNumberもアレなので。

584 ：デフォルトの名無しさん：2009/06/24(水) 00:05:12

>>580
>入力文字列の妥当性チェックを正規表現で実装したら
>「他の担当者がメンテできないような物を使うな」って叱られた事があるな。
>if文と文字列操作関数で実装するのが当然だとかで。
それをしたくないための正規表現なんですけど。そういうの聞くとちょっと寂しいですなｗ

>>581
>DB設計が出来る用にまでなって欲しい。これがきちんとできる人は、OOにも対応しやすいと思う。
これは難しいところですよね。DB設計って想像力ある人のほうが上手にできますよね

585 ：デフォルトの名無しさん：2009/06/24(水) 00:48:56

・メソッド内で使う変数はすべてメソッドの先頭で宣言すること
・変数宣言と同時に代入は行わず、宣言部に続けて初期化部を設け、そこで行うこと（定数除く）
・変数には型を表す接頭辞をつける事
・例外エラーはすべてメソッド内で処理すること
・Mapはメモリを消費するので極力使わないこと

Javaの規約で結構お目にかかるんだけど、妙な習慣やら用語やら・・・
これが文化交流ってやつか

586 ：デフォルトの名無しさん：2009/06/24(水) 02:34:26

言語の機能だけを見たら、 COBOL と Java の差は小さくなって来てるように思うけど……

587 ：デフォルトの名無しさん：2009/06/24(水) 03:37:32

>>580 >>582 >>584
正規表現の問題点を本気で考えたこともないんだな。

588 ：デフォルトの名無しさん：2009/06/24(水) 06:33:28

その問題点を挙げてみろよ

589 ：デフォルトの名無しさん：2009/06/24(水) 14:52:56

>>585
生産性を下げることにより工数を膨らませようという方針だね。
さらに、保守性の低下による継続的な収入も見込める。
いいお客さんに恵まれているな。

590 ：デフォルトの名無しさん：2009/06/24(水) 15:22:02

少々おかしくても決まったことは従わないと。
勝手にやっていい立場になれないなら

591 ：デフォルトの名無しさん：2009/06/24(水) 15:26:13

>>585
＞変数には型を表す接頭辞をつける事
いまどき印刷してコードを確認しないのに、この発想がわからない。
型情報はIDEの表示で良いのに・・・

>>589
無駄に工数を増やすことで、本来無い利益を得ているなら、
顧客の利益を損ねているということですね。

せっかくのオブジェクト指向なのですから、
ユニットテスト100%,コードカバレッジ100%,ビルドの自動化,配布の自動化とか
現代の技術でも完璧にできるとは言えませんが、システムの安定稼働のためのテストなどそっちの方面で頑張って欲しいものです。

592 ：デフォルトの名無しさん：2009/06/24(水) 15:36:05

なんでこんなマイナー言語同士で戦ってるの？
今からこのスレはIronRuby vs. JRubyにしようぜ

593 ：デフォルトの名無しさん：2009/06/24(水) 19:17:25

>>591
重箱の隅をつつくようで申し訳ないがコードカバレッジ100%なんて現実的に不可能

594 ：デフォルトの名無しさん：2009/06/24(水) 19:25:44

>>587
OK、君の意見を聞こうか

595 ：デフォルトの名無しさん：2009/06/24(水) 21:14:39

>>593
C0なら…やっぱ無理か。

カバレッジを指標にするなら、カバレッジを達成できない理由を分析できるスキルが必要だと思うが、
そもそも、数値を指標としたがる組織の殆どが、内容についての分析が出来ない組織なんだよなぁ。

596 ：デフォルトの名無しさん：2009/06/24(水) 22:13:51

メソッドを検証するためのユニットテストは複数あってしかるべきと思うし、
100％に満たない場合の対象メソッドは、ロジックを見直す又はクラス構造を変更するなりして満たすようにするべき。
満たないケースはやはり理由を明確にしておくというのが望ましいのでしょうか。
かといってユニットテストを有効に適用できない部分もあるので、まだまだ発展途上ではあります。

個人的には現行のツールで複合的にカバー率がUPしてしまうというのも問題あるんじゃない？と思いますがこの辺を管理するのは難しい。
ソフトウエアの変更による影響範囲を自動で確認できるのは最高のメリットなので有効活用するべきです。

よってユニットテストができない言語はダメだと結論となります。

597 ：デフォルトの名無しさん：2009/06/24(水) 22:19:26

言語の問題ではないと思うがね。どんな言語でもやり方はあるもんだ。

598 ：デフォルトの名無しさん：2009/06/24(水) 22:42:29

言語の問題ではないのは事実だが、実際の効率やノウハウを言い出すと
COBOLよりかはJavaの方がマシだ罠。

ただ、これは言語云々よりも人間の問題だと感じるけど。
COBOLでも前に利用したテストデータを再利用やら、そういう工夫をしている人はしているし、
酷いのだと「机上で影響がないのを確認しました」といってテストを省くヤツもいる。

599 ：デフォルトの名無しさん：2009/06/24(水) 23:11:28

よし、オブジェクティブCOBOLの出番だ

600 ：デフォルトの名無しさん：2009/06/25(木) 17:42:16

ネットで調べただけですが、
オブジェクト指向COBOLって多重継承なんですね。知らなかった。

COBOL2002

IDENTIFICATION DIVISION.
CLASS-ID. 当座 INHERITS 預金.
IDENTIFICATION DIVISION.
OBJECT.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 残高 PIC S9(9).
PROCEDURE DIVISION.
METHOD-ID. 預け入れ.
:
END　METHOD　預け入れ.
END OBJECT.
END CLASS 当座.

Java
public class 当座 : 預金 {
　　private　int 残高;
　　public void 預け入れ(){
　　　:
　　}
}

601 ：デフォルトの名無しさん：2009/06/25(木) 20:56:07

今まで書いた不良資産をCOBOL2002を使ってオブジェクト指向で書き直すか？
書き直さないと、オブジェクト指向の御利益ない。
だがそんなことするくらいなら、COBOL捨てて他の言語に移行するだろうな

で、正規表現の件はどうなった？

602 ：デフォルトの名無しさん：2009/06/25(木) 22:00:45

>>600
コボルってこんな長いのかw

603 ：デフォルトの名無しさん：2009/06/26(金) 00:35:22

正規表現がこのスレに関係あるのか？

プログラマーが正規表現の事を分からないというのなら、
そのプログラマーに正規表現の事を調べさせればいい。

正規表現のライブラリが信頼できないというなら、
どうしてコンパイラやそのランタイムライブラリが信頼できるというのか。

正規表現の問題って何だ？

正規表現の話は、スレ違いだ。もう終わりにしよう。

604 ：デフォルトの名無しさん：2009/06/26(金) 00:45:23

正規表現の問題は、>>587が答えないから引きずってるわけですが、
く憶測すると、正規表現に問題があるというヤシは正規表現を理解していない、
もしくは理解したくないという人が多い場合に問題になるということではないのかね？
Javaオンリーなら別に互換性の問題は出ないし、そこしかありえない。

605 ：デフォルトの名無しさん：2009/06/26(金) 01:18:33

もし、正規表現の問題というのが >>604 の憶測の通りなら、
プロジェクトマネジメントの問題であって、正規表現の問題ではないだろう。

606 ：デフォルトの名無しさん：2009/06/26(金) 01:23:45

607 ：デフォルトの名無しさん：2009/06/26(金) 01:36:18

COBOLって構文の単語がやたら長いな。
C++マンセーな俺にはCOBOLは無理かもしれん。

608 ：デフォルトの名無しさん：2009/06/26(金) 01:48:38

>>604
マネジメントの問題ならそもそも正規表現すらしらない人材を登用しないと思うよ。

609 ：デフォルトの名無しさん：2009/06/26(金) 01:49:40

>>605
マネジメントの問題ならそもそも正規表現すらしらない人材を登用しないと思うよ。

610 ：587：2009/06/26(金) 07:10:55

通りすがりに揶揄ったら、私の発言待ちになっていたか。要するに
プログラム言語と表現のクラスが違うからということだと思うけど、
1) 表現の複雑さに対する歯止めをどうするのか。
2) ステッパ的な意味での検証をどうするか。
プログラム言語が構造的で、その構造の入口、出口の情報を押さえ、
その状態を観察可能なツールによって支えられているのに対して、
正規表現は入り口のデータと適用されたデータの二種類しかない。
実務の文字列に於いては、パターンの出現位置や繰り返し回数は
予測不能であることが多く、適合したパターンの前、後ろに対して、
予期しない適合が起こっていないか、未検査対象が残っていないか、
などの検証コードの付記が必要になる場合も多い。きっちりとした
論理的コードの記述を簡略化した付けであり、そのことが結果的に
デバッグを困難にする。

611 ：デフォルトの名無しさん：2009/06/26(金) 07:34:55

仮にログから特定ドメインのメアドを抜けって言われたら、
COBOLで実装するのと正規表現で実装するのとでは、
どう考えても、正規表現の方がマシだよな。

仮にCOBOLで実装したとしても、
＞1) 表現の複雑さに対する歯止めをどうするのか。

正直COBOLのコードで実装したら複雑さなんてハンパねーぞ。
正規表現に比べて、まず実装のミスが発生するだろう。

＞2) ステッパ的な意味での検証をどうするか。

別にCOBOLで実装してもテストケースが減ることはないが。

612 ：587：2009/06/26(金) 09:38:18

COBOLで文字列解析かい。JAVAでの話と思っていたが。
複雑な文字検索や解析が必要な場合は、「COBOLではできません」と
断るのが正解だとおもうけど。
私はPrologなので、正規表現の表現時間と勝負はするが、ほとんど
負ける。しかし複雑な解析は文脈自由文法のクラスで記述するべき
だと思う。それによってより複雑化する場合に簡単に対処できるし、
新たな文字列を生成する作業も一体に進めることができる。
Prologの述語appendの組合せだけで進む解析記述は双方向の検証が
どの部分にあっても可能だ。そして教育コストはゼロだ。

正規表現の問題が現場で話題にならないとすると、それは文字列解析
を致命的な影響のでる業務で未だ利用していないからではないか？

613 ：デフォルトの名無しさん：2009/06/26(金) 17:57:06

それって、正規表現の問題か？
適材適所が大事だねって話じゃないか？

614 ：デフォルトの名無しさん：2009/06/26(金) 17:58:53

>>612
テストの問題かと思っていたら、そんなことかい。

純粋な正規表現で入れ子になってるかどうかを判定しようという香具師はただのバカだろ。
道具の選択を間違ってる。

以上、終了。問題なし、ということがわかった。

615 ：デフォルトの名無しさん：2009/06/26(金) 22:14:32

>Prologの述語appendの組合せだけで進む解析記述は双方向の検証が
>どの部分にあっても可能だ。そして教育コストはゼロだ。

誰もPrologの話はしていない点について。

>正規表現の問題が現場で話題にならないとすると、それは文字列解析
>を致命的な影響のでる業務で未だ利用していないからではないか？

ぶっちゃけどんな業務だよ。

単に昔正規表現で失敗して痛い目にあったのを正規表現の性にしているだけだろ。

616 ：デフォルトの名無しさん：2009/06/26(金) 22:40:16

正規表現として適切なサイズ（表現とでもいった方がよいのか）はあるのかも
人間の理解力には個人差があるから、どこで線引きするかは判断が難しい。。
比較的シンプルな文字列解析　例えば、電子メールアドレス、電話番号、郵便番号、URLのチェックとかこの程度のものは正規表現が良いでしょう。
ソースコード解析、HTMLドキュメント解析など、そういう規模の部類は正規表現オンリーで無理でしょうから、クラス化すべきでしょう。

複雑な正規表現は危険な存在ではあるも事実、ただ現代のシステム開発の現場では、そういう部類の要求は少ないと思う。

617 ：デフォルトの名無しさん：2009/06/26(金) 23:55:27

「正規表現の問題」というより、「正規表現の限界」という事だと思う

618 ：デフォルトの名無しさん：2009/06/28(日) 20:24:40

構文解析とは関係ないよね。
単に「マッチする／しない」の話であって、特定のパターンにマッチするかどうかで
解析できるような構文には正規表現が使えるというだけの事でしょ。

正規表現は、複雑になるとコードを読む人が何にマッチするのか把握しづらくなるのが欠点。
たとえば、正規表現からマッチする入力・マッチしない入力を想定できるかというと、
"FILE[0-9]{2}[DU]\\.[Cc][Ss][Vv]" 程度なら簡単だけど、
ttp://www.din.or.jp/~ohzaki/mail_regex.htm にあるようなレベルでは考え込む。
↑は対応する仕様が特定できるから成り立つわけで

619 ：デフォルトの名無しさん：2009/06/28(日) 20:56:23

なるほど、すごい例が出てきましたけど、
厳密に準拠するというのはそんなに難しい事だったのか。あたしも勉強不足ですな；；

逆に考えると、若干、穴がある正規表現だが、他の方法でカバーするような運用が望ましいというのが落とし所なのでしょうか？

620 ：デフォルトの名無しさん：2009/06/28(日) 21:12:36

受理できるアルファベット限られてるわけだし…
なんで正規表現が問題になってるんだ???

621 ：デフォルトの名無しさん：2009/06/28(日) 21:40:25

そうですね、ここはCOBOL vs Javaのスレなので、
話を切り替えてみましょうか。

結局COBOLの問題というのは、コンピュータの歴史の問題なんだと思う。
オートメーション化する過程で、当時のコンピュータで処理する言語としてCOBOLしかなかったわけだ。

システム設計、プログラミング方式が確立していない時代の遺産で、
なおかつ社会基盤として成立しているものが多いというところかな。

当時の構築に関わった人間は、現代のコンピュータがこれほど高性能になるとは考えていなかっただろうし、
日本やアメリカなどでは、過去の遺産とどう付き合うか、どう有効活用していくか、
もしくは再構築するのか、悩ましいのではないのでしょうか。

日本の場合はベンダーによる文字コード（漢字）、パック、ゾーンに見られるエンコーディングの差異、
SNA、JCA、全銀手順にみられるネットワーク方式の陳腐化、
特注品を好むのが（これはビジネスの競争上の理由だと思うが）
問題を複雑にしている。

オブジェクト指向も万能ではないことは認める
言語として柔軟性が高い反面、適切な構造を設計できない場合は最悪な状態に陥ると思う。

建築などの分野と違って、技術革新によりパラダイムシフトが起きるスパンが短いことで、
基礎となる設計が揺らいでしまうという、なんとも不安定な分野である。

私の考える歴史的な経緯や語りたいことは以上ですが、東京海上日動にみられるようなCOBOLを選択してしまう理由について
なぜ企業はオープン系の技術に全面改修に踏み切らずにいるのか意見を聞いてみたい。

http://gimpo.2ch.net/test/read.cgi/bizplus/1220822531/

622 ：デフォルトの名無しさん：2009/06/28(日) 23:02:16

>>621

制御系や科学技術計算系にこんな話題が発生しないのはなぜなの?
COBOLで制御や科学技術計算をやってみてもらいたいもんだ

SEと呼ばれる職種も含めて、要求をうまくモデル化できない土方使ってるから
こうなったんでしょ?

> 建築などの分野と違って、技術革新によりパラダイムシフトが起きるスパンが短いことで、

製造とか建築とかはもっとうまく技術革新を採り入れてるよね
製造とか建築とかのオフィスからドラフターがなくなって何年たつよ

> なぜ企業はオープン系の技術に全面改修に踏み切らずにいるのか意見を聞いてみたい。

現場のSEと呼ばれる摩訶不思議な職種の人間がアフォ
それにわをかけてプログラマって呼ばれる職種の人間がアフォ
だからじゃない?

623 ：デフォルトの名無しさん：2009/06/28(日) 23:26:36

馬鹿だから、という答えは一切の思考を伴わずに書けるから楽だよね～

624 ：デフォルトの名無しさん：2009/06/29(月) 00:05:32

この業界の難しいところは、
厳格な基準みたいのが定めにくいんだよね。
テクノロジーの種類が多いのとニーズが変わりやすいから・・・

個人的には、まず設計のみプログラミング知らないひとは不要だと思う。
設計＋プログラミング＝SE、プログラミング＝PG（SE候補）でいいんだよね

あとはPM＞SEっていうのが意味分からない、
PM=SEだと思うし、そもそもプロジェクトマネージメントとシステムをデザインする仕事は別だから。

まぁ不勉強な人でも入り込みやすい業種であるのも事実。

625 ：デフォルトの名無しさん：2009/06/29(月) 20:20:08

PM>SEがあるとしたらライン職制にしたがって役割を割り振ってるからだろ
ライン関係なくPM>SEな職場なんてあるのか？

626 ：デフォルトの名無しさん：2009/06/29(月) 21:24:20

何の仕事でも、金をかき集めてこれる奴が一番偉いんだよ。

627 ：デフォルトの名無しさん：2009/06/30(火) 00:29:44

>>626のような考えが馬鹿な営業を増殖させる事になったんだろうな。

628 ：デフォルトの名無しさん：2009/06/30(火) 07:37:28

今に始まった話しでもないがの。馬鹿でかい金額をぶん回せる奴は昔っから強い。

629 ：デフォルトの名無しさん：2009/06/30(火) 11:33:51

>>628
バブル馬鹿発見

630 ：デフォルトの名無しさん：2009/06/30(火) 15:37:27

>>628 を馬鹿呼ばわりしたところで現実は変えられない罠

631 ：デフォルトの名無しさん：2009/06/30(火) 17:33:56

サイフ握ってる奴は強敵だよなｗ
仕事くださいm(_ _)m

632 ：デフォルトの名無しさん：2009/07/08(水) 08:20:18

質問
コボルで、条件に合わない場合、ABENDさせる設計書をよく見るが、
JAVAの場合どうですか？って、JavaにABENDという考えがあるのですか？

633 ：デフォルトの名無しさん：2009/07/08(水) 10:35:48

System.exit(1)とかやったら強制的に終了するよ。
普通はファイルやデータベース接続なんかのリソースを閉じたり、
適切にログ吐いたりっていうような後始末をきちんとしてから終了するから、
異常終了という意味でのABENDは非常手段だと思うけどね。

COBOLだとその辺のリソースの後始末やらロギング部分は、
JCLとか？のフレームワーク側でやってくれてるから、
プログラマは単純にABENDすれば良いだけなんだけど、
Javaの方がプログラマの裁量に任せるところがあって面倒／難しいとは思いますね。

634 ：デフォルトの名無しさん：2009/07/08(水) 21:49:52

>>633
あなた、言語の話とOSの話が混乱してるぞ。

635 ：デフォルトの名無しさん：2009/07/08(水) 22:01:21

JavaでWebなら、システムを強制終了（アベンド）するんじゃなくて
強制的にエラーページに飛ばして、「ただいま回線が混雑しております。しばらくたってからアクセスしてください」
とか、そんな感じのメッセージ出してお茶を濁すんじゃないかと。

636 ：デフォルトの名無しさん：2009/07/08(水) 22:45:17

>>632
何がいいたいんだ？ ABEND だって, メッセージ吐くだけで OS に丸投げじゃん

>>634
そんな話なら exit する時の hook 仕掛けといて等っパースクリプト
書いときゃ済む話だろ?

637 ：デフォルトの名無しさん：2009/07/09(木) 22:54:16

>>636
634だが。
日本語で頼む。

638 ：デフォルトの名無しさん：2009/07/09(木) 23:06:56

コボラーとジャバー。あほ同士なんだから仲良くしなさい！

639 ：デフォルトの名無しさん：2009/07/09(木) 23:08:43

>>632
作るもの（運用要件）による。別にCOBOLがどうとか、ＪＡＶＡがどうとか、そんなことは関係ない。
２ｃｈのサービスなら別にシステム停止してもなんも生活に影響ないけど、
ＡＴＭがとまっちまったら、みんな困るだろ？

そゆ場合は、なんか問題あってもサービスを止めるんじゃなくて、エラーはエラーとして検知しつつ
なんとか回復の方向に持っていくのがセオリーだ。

>>コボルで、条件に合わない場合、ABENDさせる設計書をよく見るが、

たぶｊん、その見ているシステムは、そんなに重要なシステムじゃあ、ないんだろう。
クリティカルなシステムなら、アベンドなんて、そうそうありえないぞ。

640 ：デフォルトの名無しさん：2009/07/10(金) 23:42:02

>>639
>たぶｊん、その見ているシステムは、そんなに重要なシステムじゃあ、ないんだろう。
>クリティカルなシステムなら、アベンドなんて、そうそうありえないぞ。

コード上の出現頻度と動作上の出現頻度は別物だ。

641 ：デフォルトの名無しさん：2009/07/11(土) 08:59:56

不正な処理を継続するより、一度止めちゃった方が健全。

642 ：デフォルトの名無しさん：2009/07/11(土) 09:25:58

>>641
最低限の終了処理はやるべきだろ

産業用ロボットとかだと、一部のサブシステムだけが勝手に停止すると、
人を殺したりしてしまうんだが

643 ：デフォルトの名無しさん：2009/07/11(土) 10:57:17

>不正な処理を継続するより、一度止めちゃった方が健全

COBOLってさ、RDBMSのCOMMIT、ROLLBACKって制御できるのかしら、
一度止めた方がというのは考えは、ファイルとかRDBMSの状態を処理途中で中断するという意味？

644 ：デフォルトの名無しさん：2009/07/11(土) 11:16:35

5年前に俺が新人の頃触ってたCOBOL74では、
DBのRollback/Commitは制御できた。
但しABENDとかするとロックが残ったままになってしまい、
こっぴどく怒られた記憶がある。

645 ：デフォルトの名無しさん：2009/07/11(土) 11:35:25

COBOLというか汎用機ではJOBという概念があって、
JOB単位で後処理とか例外処理への分岐とか指定出来ちゃうわけさ。
バッチ処理は割りと見境なくABENDさせることが多いな。
精査系やオンライン系はよほどのことがないとABENDさせないぞ。

646 ：デフォルトの名無しさん：2009/07/11(土) 12:00:07

入力データから出力データがはっきりしている場合は、ABENDで良いって発想なのか。

バッチ系で本来ある方法としては、データの不整合が発生した場合は
不整合を切り分けして、それだけ後で再処理に回すとか、
正常な場合は更新・出力するとかそういうフローになるんでないの？

ABENDした後の復旧ってどういう作業を想定しているのかしら。

647 ：デフォルトの名無しさん：2009/07/11(土) 12:48:13

想定外のデータが来たら再処理がおおいんでないか？
想定外のエラーはABENDしかないと思うが。

と思いつつも、今漏れが関わっているカード会社の仕組みは超絶的に手抜き思想で、
想定外データが来ても即ABENDだったりするが。

ABENDそのものにどーこー言う気はないが、JOBを再投入するのに壮絶な手間が
かかるJOBフロー組まれていると鬱になるな。

648 ：デフォルトの名無しさん：2009/07/11(土) 14:17:57

想定外のデータというのも抽象的だが、
例えば1000件のデータをバッチ処理するとしよう、
1000件のデータに関連性がなく、
その内に想定内のデータが900件ならそれは正常に処理して、
残りの100件は想定外だから元のデータを見直して再処理するでOKでないの？

全件が想定内のデータじゃないとまずいケース、例えばクロス集計とかなら話が別だが。

あとは規模にもよるのかもしれないが、1000件程度なら再度全件処理でいいという発想でよいけど、
処理時間が相応にかかる場合は切り分けしたフローのほうが現実的じゃないのかな

いずれにせよ運用者が負担になるような、システムは良い設計とは言えないと思うし、
負担が大きい部分はその原因を探りシステムを見直す、または運用フローを見直すというのが
正しい答えなんじゃないかと。。

649 ：デフォルトの名無しさん：2009/07/15(水) 08:27:49

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

650 ：デフォルトの名無しさん：2009/07/21(火) 18:12:51

古いと言う概念ではUNIXもかなり古い、バッチ処理でCOBOLでソースを書いた時とJAVAで書いたときの生産性は、どちらの方が良いのでしょうか、又どちらの方が分かり易い（メンテナンス性）のでしょうか？
これで、COBOLが負けてしまうようでは、勝ち目はないと思いまが？
unix系OSはどんどん進化しているのですが、COBOLは進化しないのですか？
又、コボラーはそれを望まないのですか？

651 ：デフォルトの名無しさん：2009/07/21(火) 19:14:29

この手のVSスレでそういう質問しても結論出ないし、燃料にしかならんよ
燃料のつもりで書いたならいいけど

652 ：デフォルトの名無しさん：2009/07/21(火) 21:15:09

つか、COBOLだって進化してるし。
新しいCOBOLはJAVAライクなオブジェクト指向だってもってる。

>>又、コボラーはそれを望まないのですか？
まあ、これはあるかな。
せっかくのリッチな機能も使う側が理解してなくて、結局旧態依然なコーディングしかしてないこと。

653 ：デフォルトの名無しさん：2009/07/22(水) 00:08:39

そもそも、それがコボラーの定義のような。
COBOL使ってるってだけじゃ、コボラーには当てはまらない。

654 ：デフォルトの名無しさん：2009/07/22(水) 02:28:27

COBOLの頃のコーディングは「製造」工程と考えられていた。

OOP以降になると、コーディングは「設計」工程の延長。
だけど今でも製造工程なんだよね

655 ：デフォルトの名無しさん：2009/07/22(水) 16:43:01

COBOLか....何もかも皆懐かしい。

656 ：デフォルトの名無しさん：2009/07/22(水) 23:17:23

>>654
>OOP以降になると、コーディングは「設計」工程の延長。
>だけど今でも製造工程なんだよね

なんかわかるな、システム設計の成果物である設計書が、
OOPLを知らない人向けになってるのもそうだし
ぶっちゃけUMLを活用しているところなんて皆無じゃない？
構造を説明するというのにプログラミング言語というのが嫌な人が多いんだろうね。

657 ：デフォルトの名無しさん：2009/07/23(木) 02:24:01

ユースケースとアクティビティは書く。これは上流工程の話だな。

クラス図、シーケンス図は書かんなあ。
いわゆるJaaでWebだとフレームワーク使うことが前提で、
フレームワークのお作法に則ればある程度形（これアクション、これDAOみたく）になるから、
いわゆるモジュールの一覧みたいなのは作っても、図には起こさんな。

コメントうって、あとjavadocみたいな。

658 ：デフォルトの名無しさん：2009/07/23(木) 23:47:02

GPLライセンスのツールによるCOBOLからJavaへの自動移行
http://www.infoq.com/jp/news/2009/07/cobol-to-java

記事貼りで悪いが、こういう記事を見ると、恐怖を感じるというか、
自動コンバートなんてのが流行った暁には、
レガシーコードがCOBOLからJavaに映っただけじゃんとおもったりする。

659 ：デフォルトの名無しさん：2009/07/24(金) 00:55:19

Ｊａｖａであることに意義があるのかな。
そんなにＣＯＢＯＬがキライなのか

660 ：デフォルトの名無しさん：2009/07/24(金) 01:36:42

>>659
人が居ないってことでしょ。
実質的には似たようなことをやっていたとしても、Javaならその先がある気がする。
それに対して、COBOLじゃ一生同じことをやっていくのかと思わせる。

661 ：デフォルトの名無しさん：2009/07/24(金) 03:39:09

発注する立場の人間に「これはｲｲ」と思わせたら勝ち。
javaの方が若くて丈夫で単価の安い土方多いんだし…

662 ：デフォルトの名無しさん：2009/07/24(金) 20:59:05

20年前のコボラーですが、このスレについて行けますか？ｗ

663 ：デフォルトの名無しさん：2009/07/24(金) 22:50:01

「ついて行けますか」という疑問をもてる時点で、「コボラー」の定義から外れるのではなかろうか？

664 ：デフォルトの名無しさん：2009/07/26(日) 10:40:02

cobolの開発ってやったことないから全然わからんが、興味ある。
http://q.hatena.ne.jp/1248422316

665 ：デフォルトの名無しさん：2009/07/29(水) 16:37:46

ＣＯＢＯＬをやるなら、ＪＣＬが必須なのだが話題になってないな。
ＪＣＬはjavaのデブロイデスクリプタに似ている

666 ：デフォルトの名無しさん：2009/07/29(水) 21:02:46

java開発 => C開発 => VB開発 => COBOL保守と渡り歩いて最近、昔のJCLなんか
触ってたりしてるけど、COBOLの方がまだいいな。スレッド無いし…
中間ファイルあるだけ不具合の発見し易かったりする。

Swing使うとイベントディスパッチスレッドルール違反で落ちまくって大変な目に遭う。
java Applet <=> java Servlet <=> C Service <=> JCL <=> COBOL <=> DB
という華麗なシステムのおかげで、言語としては、どちらも糞としか見えない。 orz

Java=マルチスレッド系とCOBOL=基幹系かな？
データベースを上手く作れば良いのだろうけど、
昔のオフコンスペックで安定稼動させる事ができるならCOBOLが上かと…

>>642
Java(CORBA)で作成された制御システムを保守したけど、10日で1回、
原因不明の動作不全で落ちているのがあったよ。怖いよね。
こいつもマルチスレッドでオブジェクト崩壊起こしてた。
スレッドダンプが拾えなくてしんどかった…

667 ：デフォルトの名無しさん：2009/07/29(水) 22:15:10

Swingアプリはサーブレットと同じノリで作ると、>>666みたいにハマる。

668 ：デフォルトの名無しさん：2009/07/29(水) 23:29:28

>>666 >>667
こういうのが信頼落とすんだろうな,薄っぺらすぎ、低能もいいところだろ

669 ：デフォルトの名無しさん：2009/07/30(木) 07:28:07

>>666
エンジニアとして落ち目街道まっしぐらってトコが可哀想なノリがあるな・・・。
全てが喪前が原因で不安定と言うワケではないが、
基幹系でも毎日STEP当てて不安定をごまかしている運用もあるから、
JCL+COBOLが安定ってのは幻想だ。

安定に関しては言語云々よりも人の質が大きく左右する。

670 ：デフォルトの名無しさん：2009/07/30(木) 12:02:32

ハメラレタンダ。
糞技術者どもの10数年前の不快な技術、不快なコード、
ずっとバグ隠蔽していた前任が逃げて仕事が、こっちに来たんだよ。
第一、CVS、SVN、VSS、全て存在しないとかいってほざいて辞めたし…

でもいいや、今は生きている。
とりあえず予算通れば…奴らも大人しくなる。

>>669
仕事無い時は別のC#案件とか入るし、顧客対応とかもう疲れた。

>>668
とりあえずスレッドパターンだけ話せるレベルまで、
ちゃんと新人に教えてくれているなら許す。

671 ：デフォルトの名無しさん：2009/07/30(木) 19:58:59

COBOLって再帰関数書けるの？

672 ：デフォルトの名無しさん：2009/07/30(木) 20:26:28

30分で調べられる範囲で自分で調べた
COBOL2002とかいう規格だと再帰はサポートされているんだな
あと、戻り値と引数が使える関数！もサポートされてるな
後気になるのは、COBOLにはグローバル変数しかないという話を聞くが
ローカル変数/スタックは使えるのか
また、今広く使われているCOBOLの規格はどれなのか

引き続き解答を募集

673 ：デフォルトの名無しさん：2009/07/30(木) 20:32:36

いまだにCOBOL88が多いかな。

674 ：デフォルトの名無しさん：2009/07/30(木) 21:25:54

ＣＯＢＯＬ８５しか知らない

675 ：デフォルトの名無しさん：2009/07/30(木) 23:52:18

それにしても
WinMergeのプラグインの功績大きいよな…
COBOLコードのDIFFが取れるようになった御陰で、
改修し易くなったぉ。

676 ：デフォルトの名無しさん：2009/07/31(金) 00:28:00

でも、改修履歴のコメントばっかりで何が何だか分からないって落ちはない？

SCC使ってるのに、あの慣習を持ち込む奴は、さっさと死ぬべきだよね。

677 ：デフォルトの名無しさん：2009/07/31(金) 01:02:23

ごめん、SCCって意味わかんなかった。VSSの拡張子なんだね。
SVN、CVS、VSS(総称SCM)の利点が使えるから>>676の言い分は共感できる。

でもさ、本番機（SCMが無い環境）にしか開発環境を用意していない所もある。
セキュリティ強化によってソース改修をSCMに頼れない場所だってあるんだ。

あの慣習も場合によっては必要かと…最低悪だよう。

678 ：デフォルトの名無しさん：2009/07/31(金) 01:18:38

>>677
こちらこそ、ごめんなさい。SCMのtypoです。

でも、この意味が良くわからない。
>でもさ、本番機（SCMが無い環境）にしか開発環境を用意していない所もある。
>セキュリティ強化によってソース改修をSCMに頼れない場所だってあるんだ。

本番機にしかソースがないってこと？
それじゃぁ、本番機が飛んだりしたら元に戻せないのでは？
それに、開発環境とSCMのサーバは別に同じである必要は無いし。

679 ：デフォルトの名無しさん：2009/07/31(金) 01:19:13

>>672
再帰なんて言語仕様の問題じゃなくて処理系やOSの問題だろ
何十年も前のACOSのアセンブラだって再帰は使えてた

680 ：デフォルトの名無しさん：2009/07/31(金) 01:30:14

>>678
おぉ、サンクス。そんなツールあるんだ、初めて知ったよ。
検索で一撃で出なかったので、詳細教えてくれない？

>本番機にしかソースがないってこと？
色々事情があってね。セキュリティとか気にする上からのお達しなんだ。
開発環境も本番機に接続…笑えるでしょ？

681 ：デフォルトの名無しさん：2009/07/31(金) 06:06:35

再帰を分かってないアホがいるな

682 ：デフォルトの名無しさん：2009/07/31(金) 06:55:49

typoって拡張子の意味だったのか…

683 ：デフォルトの名無しさん：2009/07/31(金) 11:53:26

>>680
SCMは、ソースコード管理ツール一般ですね。特定のツールではなく。
SCMと打とうとして、まちがってSCCと打ってしまったのです。

しかし、恐ろしい環境ですね。本番機からダム端がぶら下がっている感じ？
ところで、もともとの私のレスは「SCM使ってるのに…」という文脈なんで、
あなたの環境では、コメント入れるのもしょうがない気はします。
なんか解決策ないのかなとは思うけど、そちらの方面には詳しくないので。

酷いところだと、JSPにHTMLコメントで履歴残してたりして、クライアントに駄々漏れ…
それこそセキュリティ上問題があるだろと思うんだけど。

684 ：デフォルトの名無しさん：2009/07/31(金) 14:46:28

>>683
>>JSPにHTMLコメントで履歴残してたりして
そうか！JSP内にJavaコメントとして残せば良いんだ！(ピコーン)

685 ：デフォルトの名無しさん：2009/07/31(金) 16:44:45

汎用機にバージョン管理システムなんてあるの？

686 ：デフォルトの名無しさん：2009/07/31(金) 18:28:48

AS/400は駄目だった、IFSとかあるのにね。

Java も COBOLもSCMが無ければただの（略）で、OKですか？
リファクタリングも糞もないよね。

687 ：デフォルトの名無しさん：2009/07/31(金) 18:52:51

>>683
>SCM使ってるのに…
そうだね。レス違いだったよ。

SCM使えるのに管理コードのコメント加えるのは氏んで良いと思う。
どんな言語だろうとも。

688 ：デフォルトの名無しさん：2009/08/01(土) 19:16:08

納品までのどこかの時点で、SCMの管理下から外れるからだろう。
リポジトリを誰が管理するのかという観点で考えられていないことが
多いと思う。

開発～単体テストくらいの期間だけSCM使ったり、逆にリリース管理用に
テスト完了したものしか登録させてもらえなかったり…

689 ：デフォルトの名無しさん：2009/08/01(土) 23:25:02

バージョン管理だなあ
ＡＰとデータのバージョン管理なのだが難しいのはデータのほう。
ＡＰのほうは目視でスタンプ見てでも何とかなるだろう。
あんぽんたらふうが。

690 ：デフォルトの名無しさん：2009/08/02(日) 21:09:51

ソースコードバージョン管理システムは、普段何をを何使ってる？

CVS（Concurrent Versions System)
SVN(Subversion)
VSS(Microsoft Visual SourceSafe)
Git
その他（MSのなんとかサーバとか）

691 ：デフォルトの名無しさん：2009/08/02(日) 22:04:03

うちはSubversionだね、Javaだけど

COBOL言語の場合は知らないけど、どうしてるんだろうね

692 ：デフォルトの名無しさん：2009/08/02(日) 22:16:24

言語に依存しないだろ。。。そういうのは。。。

693 ：デフォルトの名無しさん：2009/08/02(日) 22:37:03

Suvbersionってやっぱにんきなのかん。

694 ：デフォルトの名無しさん：2009/08/03(月) 00:15:22

無償で集中型だと、他に選択肢がないでしょ。
分散型なら沢山あるけど、日本語ファイル名やGUIに難があったりして、環境を選ぶよ。

695 ：デフォルトの名無しさん：2009/08/03(月) 06:38:29

このスレ何のスレ？

とりあえずオフコンじゃ無理だけど、COBOLはSVNだな...
WINDOSで使えるCOBOLの場合は亀に依存してる。
あのツールはDIFFツールを自前や別ツール指定できるし、Winmergeプラグイン大活躍。
最新バージョンは知らないケド、VSS6.0dじゃ無理。

696 ：デフォルトの名無しさん：2009/08/03(月) 07:53:43

汎用機のCOBOL開発でバージョン管理を活用したい場合は、
ソースをオープン系OS(Win or Unix)のSVNに入れといて、
コード編集はテキストエディタでゴリゴリ書いて、
コンパイルはSVNからEXPORTしたものをFTPかなんかで転送して、
汎用機に反映してコンパイルって感じなの？

697 ：デフォルトの名無しさん：2009/08/03(月) 08:46:02

いまだに区分データセット使ってたりして。

698 ：デフォルトの名無しさん：2009/08/03(月) 09:56:59

コボラならソースにコメント埋め込んで、あとはエクセルで台帳管理だろJK

もうやめたい。

699 ：デフォルトの名無しさん：2009/08/03(月) 11:53:01

>>698
バージョン管理は悩ましいな。台帳管理が一番いいと思うがなあ。
完全自動化は無理だし、第一、人間の思考回路とか、そういうものは
変わってないからな。完全に落ち着いた状態ならシステムで
やり易いだろうが、管理の境界点では不特定要素がかなり出てくる。
そんなとき、システムがこうだからと言っても、運用側からしたら
そんなこと知ったことじゃない。運用管理の難しさの一つのキモですな。

700 ：デフォルトの名無しさん：2009/08/03(月) 13:14:22

別に、SCM使ったからと言って構成管理が自動化できるわけじゃないんだが。

バージョン番号を決めるのも、どのバージョンをリリースするかを決めるのも人間がやるしかない。
SCMは、構成管理に必要な機能の一部を提供してくれているに過ぎない。

SCMに変な幻想を抱いていたり、逆に使えないと思っているのは、
単純に構成管理そのものを理解していないからじゃないか？

701 ：デフォルトの名無しさん：2009/08/03(月) 13:42:26

SCMなんて単純にテキストエディタのUNDO管理／変更履歴機能程度に
考えておいた方が色々気が楽だと思うけどなぁ。
ウチの場合は、開発中は自由にSubversion/CVSにコミットしていって、
(もちろんコンパイル／デプロイできるのが当然条件だけど)、
本番リリース前のwar+ソース一式だけtarやzipで固めて、
共有ディレクトリに置いて管理してる。

698は要約するとめんどくさいから要らない、って言ってるだけに見えるけど、
Javaとかのオープン系で上記の管理してるんかね？

702 ：デフォルトの名無しさん：2009/08/03(月) 14:47:25

>>698はただの皮肉だと思う。ソースは>>698を書いた俺。
まーでも開発、試験はツール使って管理しててもだ、
本番リリースだけは台帳つくって人間が管理なんてのはよくある話
、なんだかんだでつぶしが利くし
ごくたまにデグレがあってあたふたするけどｗ

最近は台帳というより、リリースノートをウィキで書いたり、
あとボーランドとかベンダーの出してる商用の要件管理ツール（と連動する構成管理、リリース管理）を使ったりなんかもするけど
何が正しい運用なのかは、いまだに答えが出てこないなあ。

703 ：デフォルトの名無しさん：2009/08/03(月) 16:30:07

>>701
> Javaとかのオープン系で上記の管理してるんかね？
Java はあまりやらないけど, BTS と SCM はないと生きてけないな
それ以外にも, プロジェクトに合わせた, サポート用のスクリプトは結構作る

704 ：701：2009/08/03(月) 17:09:42

701だけどアンカ間違えた。
>>699だよ、言いたいのは。
とりあえずソース管理なんてそんなご大層なもんじゃなくって、
テキストファイルのバックアップ程度のもんなんだから、
難しく考えずに導入して試して見ろ、とゆいたかっただけです。
後、仕事しような＞俺

705 ：デフォルトの名無しさん：2009/08/03(月) 21:21:30

やっぱオフコンにはバージョン管理がないのか～
バージョン管理のいいところは、差分が取れる、編集者・編集日時が誰かわかる、タグが付けられるだな。
設計書、スクリプト類、テストデータなんかも入れて使ってる。

使い勝手の良いBTSって無いですよね。Excel管理とかになってしまう。

706 ：デフォルトの名無しさん：2009/08/03(月) 21:36:25

699やけど、ツールもいいと思うよ。
見事にツールだけで壷に嵌るケースもあると思う
しかしだね、俺が今まで経験した多くのプロジェクトでもでね、
例えば、30本に新規作成や改変やったとしてだね、本番移行は、そのうちの
25本だけなんてよくある話だよ。それとね、システムの性質によっては、
ある特定日に合わせて順を追って移行することもある。
従って、バージョンの管理も本番系、テスト系、それぞれ別個にある。
石橋を叩いても渡らないくらいの用心してやらんとチョンボが出る。
日本のだね、ソフト開発はね、テスト工程以降がマジで手薄だ。
作ったら終わりのような腐ったよなエセＳＥが多い。
運用はね、実は難しいのだよ、わかってる？

707 ：デフォルトの名無しさん：2009/08/03(月) 22:40:34

>例えば、30本に新規作成や改変やったとしてだね、本番移行は、そのうちの
>25本だけなんてよくある話だよ。それとね、システムの性質によっては

よくある話でもなくて、そのエセSEの計画がムチャクチャだっただけでは。

運用が実は難しいと言うか、バカなSEがいるようにバカな運用も普通に多いと感じる。

708 ：デフォルトの名無しさん：2009/08/04(火) 00:34:25

バカなSEほど簡単な案件に複雑な運用をして、難しい難しいって言うよね。
ソースの版を管理するのと、どれをリリースするか、って別次元の話じゃん。
依存性のある単位でパッケージングなり、台帳管理なりしておいて、
ソース管理から取り出してリリースすればいいじゃん。
ソース管理を複数持つとか、無駄以外の何者でもないよ。
後、30本の改変やって25本だけリリースしたとして、
残りの5本に依存した機能が必要だったらどうするつもりなんだろうね？
後、石橋を叩いて渡らないって、仕事はするけど成果物出さないの？
それって顧客が怒らない？

709 ：デフォルトの名無しさん：2009/08/04(火) 00:40:03

>>708
馬鹿なSEとか、複雑な運用とか、難しいとか
だいたい抽象的すぎるだろ表現が、具体的な書いてもらわんと批評できんわ。
そんなんは居酒屋でやってくれ。

710 ：デフォルトの名無しさん：2009/08/04(火) 00:55:59

居酒屋というよりマー板向きの話題だろ

711 ：デフォルトの名無しさん：2009/08/04(火) 00:56:25

>>708
まあ経験を積めば見えてくるさ
機会があればだけどね。

712 ：デフォルトの名無しさん：2009/08/04(火) 00:59:35

プロジェクト管理が出来ていないのを、バージョン管理ツールで埋め合わせは出来ないな。
バージョン管理以前の問題だ。

発注側が馬鹿だから、SIerの評価が出来ない。
SIerも馬鹿だから、エンジニアの評価が出来ない。
結果、金ばかり掛けて使えないシステムが出来上がると。

713 ：デフォルトの名無しさん：2009/08/04(火) 03:58:48

冗長に書いてみる。
例えばA,B,C,D,E,Fの６業務のAPに改修が必要となったとする。
それぞれ５本のソースから出来ており、互いに依存はしない。
（業務Aを構成するA1～A5は、他のB～Fの業務で使われることは無い。
　B1～B5・・・・・F1～F5　も同様）

これらを同時にリリースできればいいのだが、業務フローの都合上、
Fのみ、来月の月次処理の後でなければいけないとすると、
A～Eの25本だけをまずリリースすることになる。
F1～F5の５本については、リリースする日まで、
　甲：現在、稼動しているバージョン
　乙：改修を加えたバージョン
の２系統を管理する必要がある。

Fのリリースだけ伸びることが初めから分かっているなら、
改修スケジュールをFだけ遅らせればいいだろう、
という声が聞こえてきそうだが、30本まとめてやらざるを得ないこともあるね。
例えばちょうど年度末の時期で、来年度は改修予算ガタ落ちだとすると、
今年度中に30本片付けておきたい、とか。　

ここで25本リリース後、業務Fに未知の不具合が発覚し、
調査の結果、F4に潜在バグが見つかったとすると、
（１）それが致命的バグで、緊急を要するのであれば、
　　　F4甲に対して修正を加え、緊急リリース
（２）それが致命的でなく、だましだまし使えるのであれば、
　　　業務方には来月月次まで待ってもらう約束を取り付け、
　　　F4乙に対して修正を加え、リリースはあとで
できれば（２）にもっていきたいね。

ここで、「じつはF3の改修は業務Bにも影響するんです」
となると・・・・・もう嫌っ！

714 ：デフォルトの名無しさん：2009/08/04(火) 06:16:48

>>713
A-E の改修が完了した時点で, リリースブランチ切ればいいって話でもないのかな?

F をリリースする前の突発的な変更は、リリースブランチでやっておいて F を
リリースするときに必要であれば F にマージ。

F の改修はリリースブランチの変更を意識することなくヘッドブランチで作業
F の回収中に必要性が判明した A-E への変更もリリースブランチを意識する必要なし

程度のことはできるけど………

715 ：デフォルトの名無しさん：2009/08/04(火) 06:38:54

運用管理の話しに花が咲いていますね。
まさにシステムは生き物だというのを、明確に実感できるセクションだね。
プログラムのこと、データのこと、顧客運用のこと、総合的な視野を
持っていないといけないね。運用管理に関してはJavaもCOBOLもない訳でね、
安全サイドに立脚して考えていかないといけないね。
その中で、ツールを使えるところは使うし、手作業のとこは手作業で、
可能であれば技術者の思考の余地が少なくなる方向で出来上がれば
いいのではないかな。

716 ：デフォルトの名無しさん：2009/08/04(火) 10:59:25

>>713
完全に独立しているなら、最初から別々に管理しておけば良いとも思うが、
そうはできない理由があるとする。

改修開始前のソースをベースラインとし、トランクではA～Eの改修を行う。
また、ベースラインからブランチを作成し、そちらでFの改修を行う。

A～Eの改修後、リリースバージョンにタグを打つ。その後、ブランチでのFの改修をマージ。
この状態でF4に致命的バグ、緊急リリースが必要なら、先ほど打ったタグからブランチを作成し、
これに対し改修を実施する。これなら、Fに対する来期向けの改修がリリースに含まれない。
もちろん、ブランチに対しても、リリースバージョンにはタグを打っておく。

緊急改修の内容は、緊急リリース終了後にトランクにマージ。
Fの正式リリースはトランクからビルドする。当然、そのバージョンにもタグを打っておく。
これは、次の改修が発生した場合のベースラインとなる。

最終的に、次のタグが残ることとなる。
1. ベースライン（改修前）
2. A～Eリリース
3. F緊急改修リリース（A～Eの改修も含まれる）
4. F正式リリース（A～Eの改修、F緊急改修も含まれる）

SIだけやってると、構成管理が適当でもなんとかなったりするけど、現状で困っているなら、
一度じっくりと勉強してみるといいと思う。
Subversionのドキュメントで、「こんな場合はこうする」ってのがあったと思うんだが、
今見てみたらつながらなかった。

717 ：デフォルトの名無しさん：2009/08/04(火) 16:56:43

いったいここはなんのすれだ？

718 ：デフォルトの名無しさん：2009/08/04(火) 18:21:37

コボラー？

719 ：デフォルトの名無しさん：2009/08/04(火) 18:37:40

COBOLは使った事が無い

720 ：デフォルトの名無しさん：2009/08/04(火) 23:39:35

おまいらこんな所で油売ってないで台帳の棚卸し作業に戻るんだ。

721 ：デフォルトの名無しさん：2009/08/05(水) 00:48:38

今日も汎用機側の項目表とにらめっこする仕事がはじまるお……

722 ：デフォルトの名無しさん：2009/08/05(水) 01:02:59

AS/400とかまだ現役なのかな。RPG2とかいうカラム指定の
意味不明な言語があったな

723 ：デフォルトの名無しさん：2009/08/05(水) 01:10:19

RPGのカラム指定は恐ろしく生産性が高いよ。
現代のインテルセンスというより、エラー＋タッチ＆GOみたいな感じ？（ニュアンス伝わらなかったらすまない）

オブジェクト指向ではないけど、同名フィールド名で、同じ型なら多重定義できるから
使い方によってはすさまじく効率が良いプログラミングが可能。

724 ：デフォルトの名無しさん：2009/08/05(水) 01:18:00

大企業の基幹システムは見事なまでにＣＯＢＯＬばっかりだよな。
用語辞書に名前が載るような鉄道系巨大システム開発やったことあるが
もはや触れないと言っていた。当時はディスクが高価でね1バイトで
8個のフラグ操作とかやってるからな。汎用機は高額だからメーカーも
受注生産でも対応するだろうし、基幹システムのJAVA化には
踏み切らない、もしくは、それは緩やかなものになると思う。
IBM、HITAC、FACOM、ACOS、MELCOMこんなもんだろう。
20XX年までに汎用機から完全撤退とか、そういう話になれば
そりゃあ面白いだろうけどなあ。これからのネックは人材だろうよ。
COBOL技術者は高齢だからなw、40代、50代、60代だろう。
慌てて若者のCOBOL教育もやってるみたいだけどね。間に合わないよな。
やりたがらないだろうし。これからのパラダイムが動いてさ、
大きなシステム改修とかが発生したら、どうするんだろうな。
若き技術者が苦労しながらやっていくんだろうと思う。

725 ：デフォルトの名無しさん：2009/08/05(水) 01:24:54

>>724
COBOLがそうだから自分が偉いとでもいいたい勘違い野郎か？

726 ：デフォルトの名無しさん：2009/08/05(水) 06:34:07

＞大企業の基幹システムは見事なまでにＣＯＢＯＬばっかりだよな。

正確には昔からある大企業だろうけど。
GoogleやらYahooがCOBOL使っているとはとても思えんが。

727 ：デフォルトの名無しさん：2009/08/05(水) 06:57:34

オレゆとりだから、2chでグダグダ書かれた長文もちゃんと読む人スゴいと思う

728 ：デフォルトの名無しさん：2009/08/05(水) 07:01:11

>>723
WebSphereユーザ？欲しいなと思っていたけど、使い勝手悪くない？
やっぱSCMも使えないし、インテリセンスはJavaに劣るよ。最新バージョンはもっと良いの？
未だにエミュレータでTelenetアクセスでCUIで打ち込んでいるよ…

>>722
最新はRPG/ILE、Sysstem i（iSeries）って名を変えてさ、現役どころか進化してるよ。
Shiftコードは汎用機の問題点かと、これさえなければなー。
標識フラグは嫌だ。配列も変数のサイズ制限あるし…
あの変なクラスやメンバ、オブジェクトと言うファイルシステムは、Javaエンジニアには理解できん。IFSの方がまだいい。
普通にフォルダ、ファイル、属性と表現してくれ欲しい。

開発、保守、運用、ホトンド顧客説明とバグ修正テスト、要件管理ばっか…
要件管理を仕様書に取り入れて仕変したりする。
Java→C/C++、RPGⅢ→PHP4→ASP、C#.Net、COBOL85
色々やっているが、一番Javaが開発しやすい。Log4J、JUnitも使い易いから。
マルチスレッドはしんどいけど…

>>669
>エンジニアとして落ち目街道まっしぐらってトコが可哀想なノリがあるな・・・。

折れの中での一番の技術と思っているのはソーシャルハッキング。
嘘や勘違いの中から真実を抽出する技術は重要と思う…orz
おすすめ２ちゃんねるのスレで「会社で使えない奴、それはワタシ／アイツ」で
「被害妄想と言えばいいよ」というレス見て、このカードは使えるなと思った。

ちなみにそんな折れは20代後半…orz
もう寝る。

729 ：デフォルトの名無しさん：2009/08/05(水) 07:08:14

>>727
ゆとりは関係ない。出来る奴はできるし、出来ない奴はできない。
顧客対応が一番むずいよ。言語そのものが話してる途中で変わるから。

730 ：デフォルトの名無しさん：2009/08/05(水) 20:28:17

javaはマルチプラットフォームによってコンパイルが２度入るから、動作自体は結構遅いけどな。

731 ：デフォルトの名無しさん：2009/08/05(水) 20:51:49

>>730
COBOLよりは速いから心配すんな

732 ：デフォルトの名無しさん：2009/08/05(水) 21:11:02

>>730-731
このやり取り何回目よ

733 ：デフォルトの名無しさん：2009/08/05(水) 22:20:22

javaより遅いってアホなの？死ぬの？

734 ：デフォルトの名無しさん：2009/08/05(水) 23:51:16

とりあえずCOBOLはFORTRANやRPGよりは遅いな。ｗ

あとCOBOLでcgi作ったことないから解らんが、htmlを返す様な処理なら
色々な意味でJavaの方が速いもしくは楽だと思うけど。

735 ：デフォルトの名無しさん：2009/08/05(水) 23:57:28

>>734
COBOLとRPGを速度を比較するなら
AS400で、おんなじ内容の処理で計測必要があるとおもうが。
それとFORTRANとの比較自体意味なくないか？

736 ：デフォルトの名無しさん：2009/08/06(木) 00:11:45

COBOLは1週間あれば誰でも覚えられるがあまり実用的じゃないな
最も銀行とかでかい企業で基幹部分いじってるって言うなら別だけど

737 ：デフォルトの名無しさん：2009/08/06(木) 01:04:50

AS/400は20年くらい前にちびっとやったことある。
いまだ現役とは恐れ入る。確かに名機だったがね。

738 ：デフォルトの名無しさん：2009/08/06(木) 12:29:22

今日知ったJavaの不具合だけど、1つのメソッドが64k以上になると、
コンパイル出来ないって言うJVMの仕様があるらしいね。
COBOLのプログラムを機械的に移行するツールとか使った場合なんかに、
この制限を突破しちゃって、これだからJavaは～とか叩かれないかしら。

739 ：デフォルトの名無しさん：2009/08/06(木) 12:59:30

不具合とはひどい話だな

64kも書くようなメソッドを作る香具師はバカ。
オブジェクト指向分かってないし、
そんな複雑なものを作ったら、そもそもテストができん。

COBOLのプログラム間共有領域は2kとかの制限の方が、よほどおかしな話

740 ：デフォルトの名無しさん：2009/08/06(木) 13:19:02

COBOLのステートメントが80桁なので、
単純に割り算すると8191行ぐらいのステップになるのかな？

実際には80桁使い切るステートメントはありえないので、もうちょっと行は増えるのか。

741 ：デフォルトの名無しさん：2009/08/06(木) 13:37:22

>>738
> 1つのメソッドが64k以上になると、コンパイル出来ないって言うJVMの仕様
バイトコードのサイズじゃなかったっけ?

742 ：デフォルトの名無しさん：2009/08/06(木) 23:19:07

>>738
ある意味、どんなコードなのか見てみたいｗ

743 ：デフォルトの名無しさん：2009/08/06(木) 23:39:04

昔２万行くらいあるCOBOLソースをメンテしたこと歩けど
それでもいくつかのブロックに分かれていたからなあ。

俺も元がどんなプログラムなのか見てみたいわな。

744 ：デフォルトの名無しさん：2009/08/07(金) 00:59:15

ソースで12000ステップというの組んだことある。
DBはADABASで。64ｋというのロードサイズだったら結構あるんでは？

745 ：デフォルトの名無しさん：2009/08/07(金) 01:38:04

ジェネレータやコンバーターを通すととんでもないソースを
吐くことも多いからその辺じゃない？
プログラムは小さくてもコピー句がでかくて、
それを読み書きするJavaのコードが際限なく生成されてたり。

746 ：デフォルトの名無しさん：2009/08/07(金) 02:22:54

>>738
誰も困らない仕様を不具合と呼ぶ前に、巨大メソッドを吊し上げろよｗ

747 ：デフォルトの名無しさん：2009/08/07(金) 07:11:15

スレの流れを読まないでレスしてみる。
64kのバグはCOBOL→Java変換で起こったと…

748 ：デフォルトの名無しさん：2009/08/07(金) 14:31:59

UMLや簡易言語からCOBOLのソースを自動生成するツールが
使われていることがあって、このソースは見れたものじゃない。
そこからさらにJavaのソースを自動生成したとすると、
混沌ぶりが二倍二倍！

749 ：デフォルトの名無しさん：2009/08/07(金) 14:52:50

ちなみに上記の64k制限は以前にJSPのコンパイルで引っかかったことがある。
元のJSPのサイズだけで40KB近くあって、中にスクリプトレットが大量に埋め込まれているんだぜ。

ところで誰かJRubyとかJythonみたいな感じでJCOBOLとか作らないかな？
出たらスレタイの不毛な議論も無くなり、
COBOLer≒JCOBOL技術者≒Java技術者とか言って売り込めるんだけど。

750 ：デフォルトの名無しさん：2009/08/07(金) 21:04:15

COBOLのプログラムをオブジェクト指向的な作りのJavaクラスに自動変換できるとは思えない。

よってCOBOLのレガシーコードが、COBOLなんちゃってフレームワークなJavaレガシーコードになるのがオチ
COBOLなんちゃってフレームワークなJavaレガシーコードのソースなんかメンテしたくないわな。

ただ、パフォーマンスとか信頼性の点でまともに動作するなら、最新のIDE、SCM等を活用できるので評価したい。
まともな頭を持ってる人なら、変換後に全プログラムの動作確認が必要と判断するので、
テストする工数と新しく作り直した場合の工数のどっちが多いかという検討をするだろう。

自動変換が難しい部分は、Javaで作り直しという選択でも良いのかもしれんが。。

>>749
COBOLの場合は、コピー句があるからそんな代物は作れないと思う。

>>748
それ最悪だね。そういうCASEツールで作られたもので、なおかつ変換したいというのは悪夢だな。

751 ：デフォルトの名無しさん：2009/08/07(金) 22:44:15

>>749
不毛ではないよ。COBOLを窓から投げ捨てれば万事解決。

752 ：デフォルトの名無しさん：2009/08/07(金) 23:36:14

配備プロパティをPlug-in通して環境を指定したいんだけど、どうすりゃいい？
バージョン勝手に変えてくれるからJavaは言う事聞かなくて困るよ。

あとJavaコントロールパネル、反映されないのは何故だろう。
Windowsの場合レジストリに書き込んでるのだろうか…
JREの仕組みを教えてエロい人。

753 ：デフォルトの名無しさん：2009/08/08(土) 01:53:28

>>752
お前は馬鹿まで読んだ。

754 ：デフォルトの名無しさん：2009/08/08(土) 20:04:58

COBOLはredefinesとか７７とかあったな。

755 ：デフォルトの名無しさん：2009/08/08(土) 21:07:45

66や88が使えるようなプログラマーは現場で煙たがられる。
だから誰も口にしないし、知らないふりをする。

756 ：デフォルトの名無しさん：2009/08/11(火) 22:27:11

COBOL88は響きが良いね。
世代限定でウケる

757 ：デフォルトの名無しさん：2009/08/12(水) 10:10:07

>>754－775が言ってるのはDATA DIVISIONのレベル番号のことだろう。
77がレコードに依存しない変数の宣言。
88がEnumもどきの奇妙な変数？の宣言。
66が・・・うむむ思い出せん。

758 ：デフォルトの名無しさん：2009/08/12(水) 21:37:25

77か、懐かしいな。。

759 ：デフォルトの名無しさん：2009/08/13(木) 01:32:14

さすがに77は新規に使ったことないな。メンテならある。
COBOLソートが苦手だったなあ。通常はＪＣＬでソートマクロを
使うけど仕様上どうしてもってのが、あったなあ。

760 ：デフォルトの名無しさん：2009/08/14(金) 12:52:12

ソートか、、、大変だったな、、、

761 ：デフォルトの名無しさん：2009/08/18(火) 20:46:58

素朴な疑問。
COBOL資産をどうするのかという話があるが、例えばJavaの場合に、
色んなフレームワークなどに依存して開発を行い運用をしていたとしてだね、
世の中のＩＴ事情が変化して活気的な新たなフレームワークなりが出現するか、
もしくは、時代の流れにマッチしなくなり改修も難しいとなったときに、
COBOL→JAVAコンバートよりも、比較にならないくらい一大事にならないかな。
現有資産について、将来そのような必ず訪れる事柄について
どう考えるよ？

762 ：デフォルトの名無しさん：2009/08/18(火) 21:10:01

>>761
> 現有資産について、将来そのような必ず訪れる
実際はもう起きはじめてるんじゃね?

Javaが依存してる単純なOO的考え方なんて細粒度の並列化なんて
出来ないわけだから…
まぁ、「ご愁傷さま」としか言いようがないわな

# 現在使われてる、「全部のライブラリが細粒度並列に対応する」
# なんて無理ちゃうか?

763 ：デフォルトの名無しさん：2009/08/18(火) 21:30:09

COBOLの問題はビジネスロジックとその他の部分がべったり癒着しているとか再利用が効かない点で、
Javaとかでまともにフレームワーク使って作ってあれば、ちゃんと分離されてるだろう

ビジネスロジックは時代や技術が変わっても生き残る
どっちがいいかは火を見るより明らか

764 ：デフォルトの名無しさん：2009/08/18(火) 21:38:20

ロジックは思考だか生き残るさ。
ただそれを実現する手段方法、具体的には、プログラムや設定ファイルが、
Javaと見ても周辺機構で違うってことだね。
そういった手段方法が、通用しなくなったときに、どうやって移植するか、
COBOLはほとんど言語的なものしかないがJavaなどが得意とするWeb系は、
言語そのものよりも、実現のために周辺機構のウエイトが高い。
また、そういった機構も種類が多く、たとえば10年後に移植しようとする場合に、
COBOLで言うところのCOBOL技術者という括りですまない。
Ａ社の場合はJava言語プラス、Ａフレームワーク精通者であるとか、
その細分化は技術者確保をも難しくする。
現在においても若きプログラマはフレームワーク依存だけで育ったものも多く、
さてエディタで作成したJavaアプリ改修となっただけで、ちょっと困った
状況ってあるんじゃない？

765 ：デフォルトの名無しさん：2009/08/18(火) 21:48:01

発想がね大量消費の発想そのもののまま、走り続けているね。
世の中リサイクルが叫ばれているけど、現在の開発思考は、
産むための道具のリサイクルを唱えているからねえ。
産んだ後の子守、親が死んだ後の生きかたを示してないよな。
ＣＯＢＯＬより、もっと恐ろしい未来が見えるよ。

766 ：デフォルトの名無しさん：2009/08/18(火) 21:58:46

画期的な何かが、なんなのかがわからないと検討しようもないが。
その画期的な何かで新しい利益を生むなら対応するだろう。

時代のニーズに対応できない企業は廃れる。
それはITに限らずの話だ。

767 ：デフォルトの名無しさん：2009/08/18(火) 22:35:31

>>761
まともなアーキテクトなら、ライブラリ・フレームワーク依存の部分と、
ビジネスロジックの部分は分割するよ。

そうしないと、テストも大変だし。

768 ：デフォルトの名無しさん：2009/08/18(火) 23:42:15

>>761
俺流ライブラリや俺流フレームワークが満載なCOBOLが言う台詞でないと思うが。

769 ：デフォルトの名無しさん：2009/08/19(水) 03:56:18

COBOLの時代の教訓から、業務依存の部分とシステム依存の部分を
分離する努力が為されてきたわけだから、状況は良くなっているはず。

ただ、COBOLの発想を押しつけられたプロジェクトは悲惨だろうな。
解決されたはずの問題が再び…受注ｳﾊｳﾊになればいいねｗｗ

770 ：デフォルトの名無しさん：2009/08/19(水) 07:40:18

いまでもjava1.4で開発せいよというプロダクトは結構あるぜ。

771 ：デフォルトの名無しさん：2009/08/19(水) 08:48:56

>>770
あるんだろうなあ。サポート切れてんのになあ。

772 ：デフォルトの名無しさん：2009/08/19(水) 20:34:23

この間VB4.0の案件が流れてきたときはマジでワロタ。
まあ工場なんていまだMS-DOSが動いていたりするからなあ。

773 ：デフォルトの名無しさん：2009/08/20(木) 06:29:01

それはそれで微笑ましく感じるんだが。
PC-98ｶﾞﾝｶﾞﾚって

774 ：デフォルトの名無しさん：2009/08/21(金) 13:09:48

VB4いまだ現役か。。10年位稼働してるならかなり良い出来なんでないかな。
ハードウエアの老朽化で置き換え不可になった場合はどうするのだろうか。

COBOLやJavaに限らず、ソフトウエアって扱いが難しいよな。

775 ：デフォルトの名無しさん：2009/08/24(月) 21:10:34

NetCOBOLで作られたアプリで出力された、"ORGANIZATION INDEXED"なファイルを、
NetCOBOLの入っていない環境で読み書きしたいんですが(言語はJava)、
なんか良い手段ありますでしょうか？
　内部のデータ構造はわかってるのですが、どう読んだらいいかがわからない……

776 ：デフォルトの名無しさん：2009/08/25(火) 21:39:12

NETCOBOLの入っている環境で、TEXTファイルへ変換するしかないと思う。
これはNETCOBOL付属のユーティリティがあるはず。

Javaで直接読むには、NETCOBOLのINDEXファイルの形式をリバースエンジニアリングするしかないと思う。

777 ：デフォルトの名無しさん：2009/08/25(火) 22:22:39

>>775
ランダムアクセスで読み書きできそう、試してみて。
索引主キー中心にレコード抽出する。
レベルが下位になると繰り返されるからその所の長さを測るのが厄介かも。
単純にレコード長で格納されていると難しくないんだろうけど・・・

あとVectorとかのフリーウェアとかでも構造を指定すると索引ファイルの中身を読むツールあったと思う。
参考になると思う。

778 ：デフォルトの名無しさん：2009/08/26(水) 02:49:01

>>756
ギャラガ88でも思い出したかい？

779 ：デフォルトの名無しさん：2009/08/26(水) 03:50:29

>>774
JavaはWeb主体だし、サーバー側だけの問題だし
コンピューターの種類も選ばないから最強だよ

780 ：デフォルトの名無しさん：2009/08/26(水) 10:06:25

JavaはSunのRun anywhereの思想に則って普及したから、
まぁ他の開発言語に比べれば動作環境が幅広いのは助かるよね。
何を以て最強とするか、って定義は難しいけど、
動作環境が多様なので、仕事が多く、プログラマの数もそれなりに確保できる、
って点では、オープンな環境では一番成功してるんじゃないかな。
汎用機系みたいなクローズ環境や、phpみたいな特化用途言語と比較すると、
個別に劣る部分はあるだろうけど。

個人的にはSwing/AWTのGUI部分強化きぼんぬ

781 ：デフォルトの名無しさん：2009/08/28(金) 17:29:36

JavaもバージョンUP繰り返してるから、
改修したい場合に旧ランタイム、旧フレームワークをどうするかという
問題はあるんでないの？
COBOLのマイグレーションで（汎用機 -> オープン系）よりかはマシだと思うけど。

782 ：デフォルトの名無しさん：2009/08/28(金) 18:20:54

別にバージョンアップしない自由もあるわけだが。
それはJavaに限らない問題だろう。

ウチのシステムの場合はハードやらOSがサポート切れになったらついで(?)に
土台のハードから入れ替えて関連ソフトウェアもアップデートするけど、
その時にそれなりの工数もらって色々検討して移行するなり切り替えてテストするから、
COBOLの様に永遠に過去の遺産を引きずる事はないな。

システムを改修するレベルがよく解らんけど、既存のシステムに機能追加とか
ちょっとした修正だとJVMのバージョン上げるとか、やらんと思うが。

Webサーバーをポコポコと立てる様な仕事だとビミョーだろうけど。

783 ：デフォルトの名無しさん：2009/08/28(金) 18:53:22

COBOLの最大の問題は言語や実行環境にあるんじゃない
使っている人間が技術者としてレベルが低いやつが多いってことが最大の問題なんだ

784 ：デフォルトの名無しさん：2009/08/28(金) 20:28:56

何億円もかけてcobolからjavaにコンバートする意味あるの？

785 ：デフォルトの名無しさん：2009/08/28(金) 20:50:26

結局、汎用機の保守費用が、現行のビジネス環境として釣り合わないから
マイグレーションするんでしょ。
競争原理が働き難い（値段が下がらない）、メーカーの利権化がしやすい、
特定ソフトが高額、サポートが不便、開発生産性が低いとか
特定ベンダーべったりは安心・安全だと思うが、そういったマイナスの面はあるよね。

786 ：デフォルトの名無しさん：2009/08/28(金) 23:10:33

正直なところ、何で何億円も掛かるのかと思うよ。
収益のコアとなるような業務なら、本来は内製で開発すべき。

787 ：デフォルトの名無しさん：2009/08/29(土) 14:45:41

必要に応じて社員を自由に雇用・解雇・配置転換できるような会社なら可能だな

788 ：デフォルトの名無しさん：2009/08/29(土) 16:04:34

納入先の業務形態を深く理解してない出来ないコボラーなんて存在価値ないからねー

789 ：デフォルトの名無しさん：2009/08/29(土) 16:12:36

>>788
それは別にcobolに限らずそうじゃね？　程度の差こそあれ。

790 ：デフォルトの名無しさん：2009/08/29(土) 17:55:20

アホ言語同士仲良くしなさい

791 ：デフォルトの名無しさん：2009/08/29(土) 18:02:59

キーー！！じゃあアホじゃない言語って何なのよ

792 ：デフォルトの名無しさん：2009/08/29(土) 19:13:18

cobolとjava以外全部

793 ：デフォルトの名無しさん：2009/08/29(土) 22:01:04

よし！VB！

794 ：デフォルトの名無しさん：2009/08/30(日) 00:41:03

つまりクラサバはVB6、WebはPHPが最強言語と言うわけですね、判ります。

795 ：デフォルトの名無しさん：2009/08/30(日) 01:09:07

そんなことどこかに書いてあんの。あほなの、死ぬの？

796 ：デフォルトの名無しさん：2009/08/31(月) 06:59:58

もうみんなC++かPythonでいいよ。

797 ：デフォルトの名無しさん：2009/09/05(土) 07:42:30

つアセンブラ

798 ：デフォルトの名無しさん：2009/09/06(日) 00:32:15

会社のCOBOLのIDEバージョンうｐしたらeclipseが採用されてた

799 ：デフォルトの名無しさん：2009/09/06(日) 02:47:07

C → awk/perl/C++ → Java/JavaScript/C#
と育ってきた俺は、{}がないと違和感を感じる。

800 ：デフォルトの名無しさん：2009/09/06(日) 21:35:28

Java → C/C++ → VB → COBOLやPL/SQLと育ってきた俺は、
C#とか{}があると幸せを感じる。

801 ：デフォルトの名無しさん：2009/09/06(日) 21:58:21

カッコなんで邪魔なだけ。
pythonに目覚めた俺はインデントこそ至高。

802 ：デフォルトの名無しさん：2009/09/06(日) 22:52:50

カッコさえあれば、他に何もいらない。
Ｌｉｓｐに目覚めた俺はＳ式こそ至高。

803 ：デフォルトの名無しさん：2009/09/07(月) 00:36:21

endがないと生きていけないんです。

804 ：デフォルトの名無しさん：2009/09/07(月) 02:49:06

Prologしか知らない僕は何もいらない。

805 ：デフォルトの名無しさん：2009/09/08(火) 23:07:35

行番号が無いの？フロー制御できないじゃん

と本気で思っていた中２の夏

806 ：デフォルトの名無しさん：2009/09/10(木) 03:54:06

>>804
っ.

807 ：デフォルトの名無しさん：2009/09/10(木) 06:18:09

>>802
だが、カッコだらけのコードを読まされる方にとっては、M式だな

808 ：デフォルトの名無しさん：2009/09/11(金) 09:39:41

>>805
俺もProlog.
pythonのインデントが滑稽に見える。

809 ：デフォルトの名無しさん：2009/09/11(金) 13:41:54

>>807
ちゃんと綺麗に書かれたコードを読むだけなら、慣れで何とかなる。
だが、大量の閉じ括弧の途中に1文追加するとなると、エディタのサポートが無いと辛いな。

810 ：デフォルトの名無しさん：2009/09/11(金) 19:04:08

>>789
いまどきはEclipseでCOBOL開発できるんだ。IBM?

COBOLでまともな（現代的な）開発環境を見たことないんだよな。

811 ：デフォルトの名無しさん：2009/09/11(金) 19:13:48

>>810
富士通のCOBOL85
とかそれなりにビジュアルプログラミングできるべさ

COBOLは死ぬ死ぬ詐欺
敷居が他の言語に比べ低い上に、メンテナンス性が低い割にコードが読みやすいから何とかなる。

>>783
今はマシンパワーが大きくなっているから
メモリとかの心配しないくていいし
プログラマはヘボでもいいよ、要は動けばいい。

ひどいコードでも動くし、形になるならそれでいいだろう。

812 ：デフォルトの名無しさん：2009/09/11(金) 20:15:40

＞敷居が他の言語に比べ低い上に、メンテナンス性が低い割にコードが読みやすいから何とかなる。

Pythonに比べれば圧倒的に敷居が高い上にコードは読みにくい。

813 ：デフォルトの名無しさん：2009/09/11(金) 20:19:39

JAVAのコードは解りやすい

814 ：デフォルトの名無しさん：2009/09/11(金) 20:20:35

理由はMVCが分離されてるから

815 ：デフォルトの名無しさん：2009/09/11(金) 20:25:16

>>807
emacsのコマンド一発で自動整形。
そしたらPythonみたく、ほとんどインデントだけで制御構造がわかる。なれたLisperはカッコなぞ見ないのだｗ
C系言語とちがってこの手の自動整形コマンドの精度が高いのも
あのカッコのおかげなんだぜ。

だけど>>809の言うとおり、いざコードをメンテしようとすると結構しんどいｗ

>>811
超大量夜間バッチだとパフォーマンスは結構シビアだぞ。
まあでもCOBOLでパフォーマンスチューニングってーと
どっちかってーとCOBOL云々よりSQLのメンテでどうにかなること多いけど。

816 ：デフォルトの名無しさん：2009/09/12(土) 01:29:48

コボルいらねー

817 ：デフォルトの名無しさん：2009/09/12(土) 14:49:39

今や敷居は高い部類に入ってしまうね
言語そのものより、入手のしやすさや動作するプラットホームの関係でな
言語そのものの敷居はそんなに高くは無いよ

818 ：デフォルトの名無しさん：2009/09/12(土) 18:20:42

趣味で覚えるような言語ではないから、プラットフォームは関係あるまい

819 ：デフォルトの名無しさん：2009/09/12(土) 18:39:20

主流言語が技術情報や実行環境の入手が安易かどうかという時代に
COBOLは旧態依然すぎる。

身近なところから改善したり、何かに応用する分野には向いてないよ。

820 ：デフォルトの名無しさん：2009/09/13(日) 00:16:56

昔は商業高校とかでもCOBOLを教えていたらしいけどな･･･。

学校とかじゃ「死んだ言語」扱いだろ。

今や老害ホイホイな言語と言う印象しかない。

821 ：デフォルトの名無しさん：2009/09/13(日) 09:09:48

COBOL　java VB

822 ：デフォルトの名無しさん：2009/09/15(火) 01:27:43

ところでJavaな人はScalaにいったりするの？

823 ：デフォルトの名無しさん：2009/09/15(火) 02:01:55

Scala勉強してるけど、Scalaの仕事がない。
自前でやるしかないな。

824 ：デフォルトの名無しさん：2009/09/15(火) 06:36:25

仕事は、まだないかもしれないけど勉強してる人は結構いそう

825 ：デフォルトの名無しさん：2009/09/15(火) 07:04:13

Haskellを完全に無視してるせいかも知れないけど、
米国では案件も求人も多いらしい。

826 ：デフォルトの名無しさん：2009/09/15(火) 12:30:55

アメリカ良いなぁ。
俺が行ってたとこも、リリース前なのに9時５時で、金曜の夕方はビアバッシュ。
ランチもフリーだし、オフィスも広いし、植え込みにはハチドリが飛んでるし。

日本はもう１０年ほど失われそうだし、まじでアメリカに脱出したい。

827 ：デフォルトの名無しさん：2009/09/15(火) 12:43:42

元々棄民の国だし半数以上に怠け者DNAが流れてる国だからね
自覚して規格化やら勝者優先社会構築してるのはスバラスイ訳だ

828 ：デフォルトの名無しさん：2009/09/15(火) 14:48:40

関数型並列実行プログラミングがはやってくるんかなぁ
クラウドとか、なにかで劇的に変化する要素があると面白いんだがな

829 ：デフォルトの名無しさん：2009/09/16(水) 01:15:55

業務系は今のところ５年遅れているから、５年後に報われる。

かも

830 ：デフォルトの名無しさん：2009/09/16(水) 06:26:04

オイオイ、漏れのところは軽く１０年はおくれているぜ！

orz

831 ：デフォルトの名無しさん：2009/09/16(水) 06:32:38

業務系は保守的だからね。
枯れた技術のほうが上層部に好まれるんだよ。

832 ：デフォルトの名無しさん：2009/09/16(水) 11:02:22

未だPL/I→COBOLとかやってたりするからな…

833 ：デフォルトの名無しさん：2009/09/16(水) 21:40:54

数年前やれ新技術だとEJB2やRoRに飛びついたプロジェクトがどうなったことやら。

834 ：デフォルトの名無しさん：2009/09/16(水) 22:35:09

>>831
最新技術を触りつつ枯れるのを待っていたのなら充分武器になるけど、
孫請けあたりまで行くと、単に初めて見る新技術だからな…

835 ：デフォルトの名無しさん：2009/09/16(水) 22:41:16

PL/Iって導入実績少なそうで大変そう、しかもCOBOLかよ。
どんなバツゲームなんだよ

836 ：デフォルトの名無しさん：2009/09/20(日) 01:12:42

【コンピュータ】まだまだ現役：プログラミング言語のCOBOLが誕生50周年 [09/09/19]
ttp://anchorage.2ch.net/test/read.cgi/bizplus/1253376523/

837 ：デフォルトの名無しさん：2009/09/27(日) 20:45:06

設計の相談に対して「理解している方法でいいんじゃない？」
と答えていたら、こちらに作業が振って来やがった・・・orz

UMLのクラス図からしてJ2EE/DAOパターンの採用なのに
ビジネスロジック１６クラス、DAOクラス９クラスを残り1ヶ月だと？
DbUnitとかのテストケースなど一つもないじゃんか・・・
ってかこんなに機能あるのに１クラスにまとめてんじゃねー。

何はどうであれ、他人の作業には口を出すのは藪蛇だったorz

838 ：デフォルトの名無しさん：2009/09/29(火) 00:33:19

有能かつ頼りにならない人物を目指すんだ。

839 ：デフォルトの名無しさん：2009/09/29(火) 01:09:11

難しいこと言うね

840 ：デフォルトの名無しさん：2009/09/29(火) 17:50:17

その話だけだと楽勝の範囲だけど

841 ：デフォルトの名無しさん：2009/09/29(火) 21:14:07

設計から割当てられれば楽勝の範囲だったんだろうな。

842 ：デフォルトの名無しさん：2009/10/01(木) 14:31:07

まだまだ現役：プログラミング言語のCOBOLが誕生50周年
http://busynes.blog68.fc2.com/blog-entry-498.html

843 ：デフォルトの名無しさん：2009/10/01(木) 17:09:13

> まだまだ現役：プログラミング言語のCOBOLが誕生50周年
だからどうした？

fortran も lisp も現役だが…

844 ：デフォルトの名無しさん：2009/10/02(金) 00:04:48

あれ、コンピュータ言語で消滅したのってあるの？
使い手が０人になりましたみたいに。。カウントできねーかｗ

845 ：デフォルトの名無しさん：2009/10/02(金) 00:10:05

消滅というか、作者がうｐデートを辞めた言語なら・・

846 ：デフォルトの名無しさん：2009/10/02(金) 01:48:00

Uvaとかは消滅で良いんじゃないか

847 ：デフォルトの名無しさん：2009/10/02(金) 02:16:04

B言語も消滅してると思う

848 ：デフォルトの名無しさん：2009/10/03(土) 00:35:54

brainf**kやその派生みたいなネタ言語は
カウントのしようがない

849 ：デフォルトの名無しさん：2009/10/03(土) 01:02:01

Basic系は消滅してるの多そうだけど。
昔に使ってたX68kのX-Basicとかは本機とともに消滅したんだろうなｗ

どの辺をいわゆるACTIVEな言語かと判定するかだよね。

850 ：デフォルトの名無しさん：2009/10/04(日) 13:18:51

>>849
　　　∧∧
　　（´･ω･）　おやすみ・・・
　＿|　⊃／(＿＿_
／　└-(＿＿＿_／
￣￣￣￣￣￣￣

851 ：デフォルトの名無しさん：2009/10/06(火) 05:22:36

ＣＯＢＯＬ標準は８５？

852 ：デフォルトの名無しさん：2009/10/15(木) 00:52:14

Javaもそろそろレガシー言語之なんじゃね？

853 ：デフォルトの名無しさん：2009/10/15(木) 21:01:39

Javaの場合はむしろ枯れることを狙ってるように思う

854 ：デフォルトの名無しさん：2009/10/17(土) 14:56:02

COBOL が枯れているってホントかな。
新しい規格をつくって新しい技術を取り込もうとする動きを止めてる訳ではないだろうし。

そもそも、言語が枯れるという事に意味があるのかな。

処理系やライブラリが枯れるというのなら分かるけど。

855 ：デフォルトの名無しさん：2009/10/17(土) 18:39:34

言語仕様変更はライブラリよりキツイだろ

856 ：デフォルトの名無しさん：2009/10/18(日) 10:04:42

＞COBOL が枯れているってホントかな。

とりあえずJavaみたいにJava1.4以降とかJavaSE6が必要とか
そういう心配はほとんどないな。

エンジニアも新しい事を覚える気はゼロだし。

857 ：デフォルトの名無しさん：2009/10/18(日) 10:40:38

すごくゆっくりではあるけど、一応新しい仕様は追加されてんだよな。
使わない（使えない／使わせない）だけで。
言語が枯れてるのかエンジニアが枯れているのかラインが微妙。

858 ：デフォルトの名無しさん：2009/10/18(日) 13:18:54

漏れのところだとCOBOLのプログラム修正とかをステップ管理しているんだから、
ある種、効率の悪い言語の方が工数とかブン取れるのでCOBOLは老人にとっては美味しい
メシの種だろう。

とりあえずエンジニアが枯れているので、言語が枯れてしまったのだろう。

スレチだがパンチカード言語(?)のRPGがIBMによって未だに進化し続けてるのが怖いわ。

859 ：デフォルトの名無しさん：2009/10/19(月) 00:44:10

IBMはRPGにもう期待してないでしょ

860 ：デフォルトの名無しさん：2009/10/22(木) 22:08:06

IBMが期待しているかどうか知らんが、構造体っぽいのをサポートしたり、
servletの様に呼び出せたり、Cの関数呼べる様にしたり、Javaのクラスのメソッド呼び出せたり、
SQLのスカラー関数記述出来たり、ストアド化できたり、xml解析したりと、老害には追従不可能な
進化しているな。

外国の一部のエンジニアは好んで使っているフシがあるが、日本はてんでダメだろう。

861 ：デフォルトの名無しさん：2009/10/22(木) 22:10:36

へぇそうなんだ。
生産性でいったらRPGかなりいいもんな。

XML解析とか、SQLなら日本じゃJavaとか.NETに行くんだろうね。普通

862 ：デフォルトの名無しさん：2009/10/25(日) 06:48:24

昔はRPGといえば宣言型言語の嚆矢みたいに言われたものだけど、
最近は手続き型に分類されてるね。デシジョンテーブルを使った
プログラミング言語という評価が適切でないくらい、いろんな
要素を取り込んでしまったということかな。

863 ：デフォルトの名無しさん：2009/12/01(火) 01:31:00

JavaってWebやらないかぎり
viでシコシコ作ってるほうが楽なんだよな。

864 ：デフォルトの名無しさん：2009/12/12(土) 11:00:39

すげぇなviでシコシコだなんて、
emacsならまだしも、俺には無理だ。

３クラス位までしか楽にコーディング出来ないな。

>>860
最新のIAサーバ/AS400とか買わないといけないのか？
無論、古いマシンでは動くはずもないし、
無償のx86版のAS400とかRPGコンパイラとか出てくれれば普及するんだろうけどね。
開発するにしても難しいのでは？と思う。

新旧資産を使いこなすには、それなりの設計が必要そうだね。

865 ：デフォルトの名無しさん：2009/12/12(土) 13:44:35

>>864
> AS400
もう作ってないだろ

866 ：デフォルトの名無しさん：2009/12/12(土) 17:34:47

>>864
POWER5の稼動するAS/400の開発機だとILE-RPGとがデフォがインスコされているはず。
あとJavaは全機種に強制的にインスコされてているはず。

漏れのところはCL,RPG,COBOL,C,C++,Java,ILE-RPG,SQL(?)くらいの言語が
AS/400上で稼動している。あとODBC経由でその他モロモロ。

と言うか現行名称はPower Systemだったよーな。

＞新旧資産を使いこなすには、それなりの設計が必要そうだね。

AS/400は必要ない。普通にコンパイルしたオブジェクトならソースがなくても、そのまま稼動する。
S/38くらいの時代の資産はちょっと頭使う様になる。

現行はPOWER6で来年くらいにPOWER7モデルが出る予定。

867 ：デフォルトの名無しさん：2009/12/12(土) 18:16:17

sage進行ｗ

>>866
もうAS/400とは言わないのか。

ところで
①Java1.4(JBuilder6) ⇒ Java 6(Eclipse)
②COBOL85(HITACHI製)⇒COBOL2002(HITACHI製)の
おまいらならどっち選ぶ？

868 ：デフォルトの名無しさん：2009/12/12(土) 22:09:22

COBOLのCALLみたいにロードモジュールを呼ぶのって、Javaではどうすればやれるんですか？

869 ：デフォルトの名無しさん：2009/12/13(日) 13:11:16

java.lang.Runtimeで直接叩くか、JNL使うんじゃね？
直接COBOLのロードモジュールは読めないと思う。
JavaとCOBOLの間にCプログラムのラッパーを作ることで出来るとはず。

ちなみにJava ⇔ COBOL間なら
Java Servlet←プロセス間通信→Cサービス←メモリ共有→CのDLL＋COBOLのプログラムmake時にリンク
とかなり手数のかかる手法を見たことある。

870 ：デフォルトの名無しさん：2009/12/13(日) 20:59:18

>>864
viもちゃんと戦えるんだぜ
コマンドは大量に覚えることになるが
…っつってもそこはemacsも同じか

871 ：デフォルトの名無しさん：2009/12/13(日) 22:23:13

>>868
それが何ものかわからんから、何とも言えない
コボラーって、COBOLの用語でしか語らないから、何も分からんのだよ

メモリ上でどういう操作になるのか説明してほしいんだが

872 ：デフォルトの名無しさん：2009/12/15(火) 00:29:59

まぁいわゆるインスタンスを生成して、呼び出すってことが正解なんじゃねーの？

873 ：デフォルトの名無しさん：2009/12/15(火) 00:49:04

それだとPERFORMに近いな。

874 ：デフォルトの名無しさん：2009/12/15(火) 00:52:24

外部モジュールに当たるものが、.classなのか.jarなのかわかんね～。

875 ：デフォルトの名無しさん：2009/12/15(火) 00:55:23

COBOLER?

876 ：デフォルトの名無しさん：2009/12/15(火) 01:14:04

>> 873
たぶんその回答だと意味がわかっていないと思うな。

877 ：デフォルトの名無しさん：2009/12/15(火) 20:17:18

>>874
あぁ読む人によってはそう見えるね。
Javaで外部ライブラリ読むってことだったのか。

それだったら環境パスにライブラリ置いてimportしろってね。
てっきりDLLかEXEと思ってたよ。

878 ：デフォルトの名無しさん：2009/12/15(火) 23:14:40

クラスライブラリを使うのとCALLはだいぶ違うだろ。

879 ：デフォルトの名無しさん：2009/12/16(水) 19:52:01

COBOLをどのOSのもとで使ってるかで違ってくろるだろうな。
IBMのメインフレームのアーキテクチだったら、.
その例えはあってると思うけどな。

880 ：デフォルトの名無しさん：2009/12/25(金) 09:50:25

MOVE "HOGEORDER" TO MYMEMORY-ORDER.
MOVE "FUGADATA" TO MYMEMORY-DATA.
CALL "MYUTIL" USING "MYMEMORY".

MyUtil.order("fugaData");

881 ：デフォルトの名無しさん：2009/12/29(火) 00:44:22

Javaから入ったから逆にCOBOLが全然読めないｗ

882 ：デフォルトの名無しさん：2009/12/29(火) 01:53:37

>>881
読めないじゃなくて読む気がねぇだろう

おれはもう40代だ
しかし、COBOLからjava、.netまで面倒をみている。
言語の特性をつかめ

883 ：デフォルトの名無しさん：2009/12/29(火) 13:41:51

>>882
言語の特性をつかめって、COBOLの知識が前提の話な。
代わって>>882を日本語に１行に翻訳すると、「COBOLの勉強しろよ。」

>>880はどうやってインスタンス化してるの？
class.getName("xxx.xxx.xxx.MyUtil");か？

またどうやってロードしてるの？
xxx.xxx.xxx.MyUtil.classを環境フォルダに置いているだけなの？

初めてのケースだから手順が全く読めん。

884 ：871：2009/12/29(火) 14:43:40

OSのアーキテクチャに依存して言語仕様が決まっているなんてバカな話はありえない。

しょうがないから調べたよ
http://docs.hp.com/cgi-bin/doc3k/B3150090013.11820/167

CALLは、（まだメモリにロードされていない）外部プログラムを呼び出す。
CALL "FOO" のようにリテラルも書けるし、CALL $VAR のように変数も書ける。
→ 実際にプログラムが動くまで何が呼ばれるか分からない。

885 ：デフォルトの名無しさん：2009/12/29(火) 18:58:02

>>882さんみたいのが、勝利者だと思ふ。
以外にCOBOLのシステムをJavaでリプレースする案件が、
貴重だったりする。

886 ：デフォルトの名無しさん：2009/12/29(火) 22:52:58

>>885
そこまで読めないだろ。
COBOLをJavaにリプレースするなんて話、
何所から沸いてきたんだ？

887 ：デフォルトの名無しさん：2010/01/26(火) 22:07:56

>>884
>CALLは、（まだメモリにロードされていない）外部プログラムを呼び出す。
リンケージによるんでないの。

888 ：デフォルトの名無しさん：2010/05/03(月) 13:53:25

すいません。教えていただきたいのですが、
javaからRuntimeでcobolのexeは実行できるのでしょうか。
御忙しいとは思いますが御教授していただけないでしょうか。

889 ：デフォルトの名無しさん：2010/05/03(月) 14:04:06

>>781
逆にＣＯＢＯＬより悲惨だと思うよ。
ＣＯＢＯＬは、プロシジャーの問題だけだけど、
ＪＡＶＡの場合、フレームワークが提供されなくなった、
古くなったで、もうね、悲惨も良いところ。

890 ：デフォルトの名無しさん：2010/05/03(月) 20:53:41

>>888
できる

891 ：デフォルトの名無しさん：2010/05/04(火) 12:15:34

COBOLのマイグレーションってたいへんなの？

892 ：デフォルトの名無しさん：2010/05/05(水) 08:57:45

>>891
COBOLというよりオブジェクト指向のみで構造化プログラムは全く未経験の人には相当つらいみたい・・・。
この前入社してきたJAVA/C++暦10年以上の人間にCOBOLで組んでもらったら完全にバンザイしていた。

彼曰く、「JavaやC++なら必要な機能はメソッドなり関数なりで大抵用意されているからそれらを組み合わせるだけで
大抵組めるが、COBOLはそれらも含めて全部コードを書かないといけないから、とてもじゃないけど組めない。」　だそうな…。

893 ：デフォルトの名無しさん：2010/05/05(水) 15:01:01

>>892
それは構造化プログラミングとか、オブジェクト指向とか関係ない問題だな。
コボラーは何でもそういう語り方するよな。だからダメなんだ。

便利なフレームワークがあろうが、充実したクラスライブラリがあろうが、
足りないものは出てきて、そいつらはスクラッチで作るしかない。
それはアセンブラから超高級言語まで等しく同じ。言語パラダイムも関係ない。
出来ないと言ってる香具師は、単にタコなだけ。

>>891
COBOLは関数のような重要な抽象化機構の導入が著しく遅れていて、
全部グローバル変数＆サブルーチンだけで書けという点がひどすぎる。
つまり、可読性と保守性が著しく悪い。

ローカル変数はプログラムを書く上でとても重要で、アセンブラでさえ
レジスタやスタックがローカル変数として機能するから、
COBOLはアセンブラ以下のクソ言語。

894 ：デフォルトの名無しさん：2010/05/05(水) 16:07:42

マイグレーションってCOBOL2002でやらないの？

895 ：デフォルトの名無しさん：2010/05/05(水) 16:09:58

PC-COBOLとメインフレーム系のCOBOLで捕らえ方が違うかもしれんね。

896 ：デフォルトの名無しさん：2010/05/05(水) 16:11:57

セクションじゃなくてサブモジュールを使えばいいだけじゃないのかな。

897 ：デフォルトの名無しさん：2010/05/05(水) 17:11:36

○○が使えないからこの言語はクソ、みたいに言語の一部分だけをとらめえて完全否定するあたり
>>893から激しくコボラー臭がするんだけとw

この前も連中、Numeric型の変数が使えない、戻り値が一つ指定出来ないからJAVAはクソ、とか言って
COBOL以外の言語を全否定していたわ。まあ色々突っ込みたかったけど、触らぬ神になんとやらでスルーしたけど…。

あとCOBOLは保守性が悪いってよく耳にするが、そんなこと言っているのは一部のコボラーだけだそ。
あんなもんただ単に自分がやっている仕事の大変さをアピールするために誇張して言っているだけ。

確かにボリュームだけはでかいから慣れない間は面食らうが、慣れりゃどうってことはない、
ただボリュームがでかい、ただそれだけのこと。

そもそも可読性や保守性なんて作り手の技量の問題で言語はあまり関係ない。

898 ：デフォルトの名無しさん：2010/05/05(水) 19:27:20

どうでもいいけど、「COBOLは全部グローバル変数」ってのは違うぞ。
広く使われている第3次規格（というか、COBOL85）で、サブルーチンを
外PERFORMで呼ぶのではなく、プログラムを入れ子で作成し、外側
プログラムから内側プログラムをCALLすることができる。
この場合、外側と内側の変数スコープは切り離される。

899 ：デフォルトの名無しさん：2010/05/05(水) 19:57:20

>>898
それは初めて知ったけど、実際にどのくらい使われてます？

900 ：デフォルトの名無しさん：2010/05/05(水) 21:16:08

>>899
20年位前のシステムならともかくここ10年に構築されたシステムは結構つかわれているけど?
もしかして世間ではあまり使われていないのかな…。

901 ：デフォルトの名無しさん：2010/05/05(水) 21:21:42

なぜか純血コボラーはプログラムをモジュルー化するのを物凄く嫌うんだよなぁ…。
以前、機能ごとにモジュール化することを提案したら目上のコボラー共に総出で叩かれたよ…orz

902 ：デフォルトの名無しさん：2010/05/05(水) 21:25:58

帳票毎単位のモジュール化を提案しなかったお前が悪い。

903 ：デフォルトの名無しさん：2010/05/05(水) 21:38:16

モジュール分割って普通にSEの仕事じゃないのかな。

904 ：デフォルトの名無しさん：2010/05/06(木) 20:03:46

>>903
> モジュール分割って普通にSEの仕事じゃないのかな。
プログラマの仕事だが、コーダーの仕事ではない。

905 ：デフォルトの名無しさん：2010/05/06(木) 20:05:54

いまどきは設計者もプログラマーも一緒
設計しかできないってのも意味がないと思うけどね

906 ：デフォルトの名無しさん：2010/05/06(木) 20:07:19

そりゃコーダーは何も考えないでただ指示された作業をこなすだけだからな。
いわば土方と一緒…。

907 ：デフォルトの名無しさん：2010/05/06(木) 20:18:34

>>897
俺は>>893に一票。
というか、あんたがCOBOLERじゃないの？

> あとCOBOLは保守性が悪いってよく耳にするが、そんなこと言っているのは一部のコボラーだけだそ。
> あんなもんただ単に自分がやっている仕事の大変さをアピールするために誇張して言っているだけ。

いや、確かにCOBOLは保守性が悪いよ。Dijkstra先生も認めていらっしゃる。
プログラマによっては多少マシになるが、二度と保守したくないと思うには充分な糞さ。
PROCEDURE DIVISION. が30000行を越える糞ソースを修正したときそう思った。

> 確かにボリュームだけはでかいから慣れない間は面食らうが、慣れりゃどうってことはない、
> ただボリュームがでかい、ただそれだけのこと。

自分で１から組めればそうかもね。
だけど、現実はつぎはぎだらけのソースを修正する仕事ばっかりで、新規案件なんてほとんどない。

> そもそも可読性や保守性なんて作り手の技量の問題で言語はあまり関係ない。

技量を伴ったCOBOLERが少なすぎるってことかな。

908 ：デフォルトの名無しさん：2010/05/06(木) 20:39:51

>>907
>>993=>>907
自演乙w

909 ：デフォルトの名無しさん：2010/05/06(木) 20:45:19

>>908=>>897だろw
なんか反論あるなら、聞いてやるからレスしてみ？

> >>993=>>907
半年先までこのスレにいるかどうかなんてわからんよ

910 ：デフォルトの名無しさん：2010/05/06(木) 20:54:06

>>909
ただのネタ振りでそこまで必死にならんでも…。

ごめんよ・・・まさか本当に>>907が>>993否w>>893本人とは思ってもみなかったわw
あと>>897にも余計な濡れ衣を着せさせてしまってなんか悪いことしたなw

911 ：デフォルトの名無しさん：2010/05/06(木) 20:55:27

気にするな。

912 ：デフォルトの名無しさん：2010/05/06(木) 20:57:10

なんかいつのまにかコボラーに苛められて心が病んでしまった人が集うスレと化してきたなぁ。

913 ：デフォルトの名無しさん：2010/05/06(木) 20:58:24

コボラーが苛めることのできる奴ってのが想像できん

914 ：デフォルトの名無しさん：2010/05/07(金) 05:48:29

COBOLの問題点の一つに、共通にすべきところを関数とかで共通にできない、
あるいはしにくいから、既存のプログラムをコピーしてちょっとだけ違うものを
大量に増殖させて、いざ修正となると、横並び修正とかやってるじゃん。

こんな言語のどこが保守性がいいんだよ。言語の冗長さが招いた弊害。
内部プログラムじゃ、結局引数の設定とか面倒だし、
こんなんじゃ使われないだろうな、と思うよ。

>>913
前のプロジェクトでは散々文句言ってやったが、コボラーをいじめても
あいつら何も変われないから面白くないよ

915 ：デフォルトの名無しさん：2010/05/07(金) 19:05:22

>>914
それはCOBOL言語の問題というよりコボラーの問題だと思う…。

以前コボラーにJAVAで組ませてたら10000ステップ超えのメインクラスを自信満々に組んできおったわw

916 ：デフォルトの名無しさん：2010/05/07(金) 20:45:56

コボラーの手に掛かればJavaだろうがC++だろうがC#だろうが、全てCOBOLチックなコードになるからな…恐るべしw

917 ：デフォルトの名無しさん：2010/05/07(金) 21:24:04

そういう奴らってCALL知らないのか？

918 ：デフォルトの名無しさん：2010/05/25(火) 14:59:59

COBOL誕生50周年
http://iiyu.asablo.jp/blog/2010/05/25/5111701

919 ：デフォルトの名無しさん：2010/06/04(金) 18:48:03

>>915
> 以前コボラーにJAVAで組ませてたら10000ステップ超えのメインクラスを自信満々に組んできおったわw

いろんな意味で、さすがコボラだと関心すらした。

920 ：デフォルトの名無しさん：2010/06/06(日) 19:28:23

>>914
リプレース案件なんかだと、既存バグでたまたまそうなってるだけの計算結果であっても、
システム側の都合で勝手に数字を変えられないので、バグ結果を再現させたり、
本来共通化できるはずのところも実装方法とその結果が微妙に違ってて共通化してはいけなかったり
ホント負の遺産意外の何者でも無い‥

921 ：デフォルトの名無しさん：2010/06/06(日) 21:28:17

コードの不良債権ってやつだな。
結局、長年に最適な状態で保守していなかったのが原因で、
リプレースが原因ではなかろう。

そういうところはリプレースが原因と言い放ちそうだが、
まぁいかんせん当時作った人間がいないから、
何故そうなのかというのがわからんことはあるよな・・・わりとそういうのあるから気持ち悪いがｗ

922 ：デフォルトの名無しさん：2010/11/27(土) 18:06:05

保守して評価されるならやるけどさ、
俺の職場じゃ手を入れても何の評価もされないし、
手を入れたプログラムが落ちてたらデータの使用者から
何勝手にいじくってんだって電話来るぞ。

だから極限まで触らない。

923 ：デフォルトの名無しさん：2010/12/21(火) 02:23:34

俺もコボラーだけど、10000ステップ越えのプログラムやgoto文の嵐には殺意が沸く。

924 ：デフォルトの名無しさん：2010/12/22(水) 03:28:27

>10000ステップ越えのプログラム
なんてざらじゃないか？
10000ステップ越えのサブルーチンなら頭抱えるがw

925 ：デフォルトの名無しさん：2010/12/22(水) 07:27:47

横長データベース、ファイルシステムなら
データの取得、作成だけで数百～千行くらい行くからね。
それにデータチェックが加わればコード量２～３倍くらい膨れ上がるし。

それでも1万行は詰め込みすぎだと思うけど。いやよく見るけどさｗ
もう少しモジュール分割しろよっていう。
少なくともファイルアクセス部分（いわゆるDAOに当たる部分）を外出しモジュール化するだけで↑の例はだいぶすっきりするはず。

926 ：デフォルトの名無しさん：2011/02/17(木) 20:22:21

奴隷は、奴隷の境遇に慣れ過ぎると、驚いた事に自分の足を繋いでいる鎖の自慢をお互いに始める。
どっちの鎖が光ってて重そうで高価か、などと。そして鎖に繋がれていない自由人を嘲笑さえする。
だが奴隷達を繋いでいるのは実は同じたった１本の鎖に過ぎない。そして奴隷はどこまでも奴隷に過ぎない。

過去の奴隷は、自由人が力によって征服され、やむなく奴隷に身を落とした。
彼らは、一部の甘やかされた特権者を除けば、奴隷になっても決してその精神の自由までをも譲り渡すことはなかった。
その血族の誇り、父祖の文明の偉大さを忘れず、隙あらば逃亡し、あるいは反乱を起こして、
労働に鍛え抜かれた肉体によって、肥え太った主人を血祭りにあげた。

現代の奴隷は、自ら進んで奴隷の衣服を着、首に屈辱のヒモを巻き付ける。
そして、何より驚くべきことに、現代の奴隷は、自らが奴隷であることに気付いてすらいない。
それどころか彼らは、奴隷であることの中に自らの唯一の誇りを見い出しさえしている。

(リロイ・ジョーンズ　1968年、NYハーレムにて)

927 ：デフォルトの名無しさん：2011/03/08(火) 16:46:51.10

どこかにないかなねぇ、ＣＯＢＯＬの仕事

928 ：デフォルトの名無しさん：2011/03/09(水) 22:11:56.77

COBOLは古くから基幹システムに多く見られたけど（バッチ処理・帳票作成・O/Lマスタ更新etc）
現時点において未だにリビルドしないで運用してる企業は無いと思うんだけどな。

そこら辺ってどうなん？

データウェアハウス(ETL)なんてのが数年前から当たり前のように使われているのに
基幹システムに何ら手を加えないで、I/Fトランスのみで取り込みしてるとは思えないんだよね。
データが誇大で大量であるのは認めざるをえないけど、今時のサーバ系統のCPUなんてのは
大型のCPUとか処理能力に負けないと思うけどね、それにHDD自体もビルのフロア一杯に
大型ロッカーみたいなモノ敷き詰めなくてもコンパクトに成っていると思うしね。

まあ俺なんかも昔は古臭いコボラー出身だったけどなｗ
俺がSEやってた時なんてのは16年も前のことだからな、今はWeb関連の小さな会社持ってるけど
当時を振り返ってみると、止める時期に丁度、再構築のプロジェクトが発足するとかしないとかの
噂が流れてたときだったな一部の社内システムで移行テストなんかのプロジェクト要員に
選ばれるかどうかという話も出てたが、これからは違う道を歩みべきと思って断ったけどね。

当時でも昔からの遺産を大事に壊さないように、仕様変更の度にデグレ出ないようにと気を使ったけどね。
うまく処理してる所が異常でると、何万ステップとも思える遺産を深いネストと馬鹿みたいにデカイ
サブRTNを追いかけ回さないといけないからねｗ
一番やっかいなのが仕様書が修正履歴で何倍にも膨れ上がってて、ソース見たほうが早いかもよと
先輩によく言われたことがあったｗ
まあ、再構築するにしても、基盤整備（システムフロー・ドキュメントとか現状ソースとのすり合せ等）から
始めないと手のつけようが無いというか、処理を零してしまう恐れが多々起こるような感じだった。
まあ、遺産なんでね、修正仕様が反映されていなかったりするのも意外と多いんだよね。

だから再構築といっても、コストとリスクを考えると中々手が出せなかったのは覚えているけどね。
とにかく当時は、巧くいってる物はムダに触るなと言ってる上の連中が多かったからなｗ
今、どうなっているんだろうな、なんとなく見てみたい気がするｗ

929 ：デフォルトの名無しさん：2011/03/09(水) 23:04:28.22

>>928
浜松町にある会社につとめてた？

930 ：928：2011/03/09(水) 23:17:32.68

ObjectWorks+ を造った会社に居た事はあるｗ

931 ：デフォルトの名無しさん：2011/03/09(水) 23:28:08.77

ＩＴは時代とともにニーズが変わるからね。
いつまでも古い遺産を抱えていてはビジネスにマイナスの影響がでる。
定期的に変えていくことが正解

932 ：デフォルトの名無しさん：2011/03/10(木) 07:25:10.50

COBOLでもなく、Javaでもなく、Rubyが至高の言語

933 ：デフォルトの名無しさん：2011/03/10(木) 21:51:07.43

ＣＯＢＯＬは画面系はまったく弱い

934 ：デフォルトの名無しさん：2011/03/11(金) 00:08:22.36

言語も重要だけど開発環境の良しあして大きいと思う。

935 ：デフォルトの名無しさん：2011/03/11(金) 02:34:01.51

>>931
要件定義まで巻き戻してン億～ン十億投じる覚悟のある奴はあんまりいない。

「できるかできないかわからない新システムに投資」って不安 + 「新機能の追加が遅れる」マイナスの影響
と
「既存のシステムを継ぎ接ぎして動く保障の高いシステムを動かす」安心感

のどっちがユーザーにとって感情的に満足できるかっつったら後者らしい。
どっちがマシ？　というレベルの話だけどな。

ユーザーから見たらぶっちゃけソフトそのものなんてどうでもいい。
一関数一万行のCOBOLコードがあろうがなかろうが関係ない。
ソフトを使うことによる効率化の成果が欲しいわけ。

936 ：629：2011/03/11(金) 17:52:42.83

>>930
あんたとリアルの知り合いのような気がしてきた（笑

937 ：928,930：2011/03/12(土) 22:49:53.87

>>629
ほんとかよ、まあ、当時は意外と面白い連中が多かったけどな。
実は、証シス1部にも居た事はあるｗ

アンタは？

938 ：928,930：2011/03/13(日) 21:58:27.25

>>629

よ、アンタは？
俺は、その後に懐かしの国際証券とNTT（浜松町）で仕事を請負でやったことはあるけどね。

939 ：デフォルトの名無しさん：2011/04/09(土) 17:08:07.40

>>926
プログラマーも奴隷だな。
人は皆、金の奴隷だ。

940 ：デフォルトの名無しさん：2011/05/31(火) 07:57:27.44

仕事があれば奴隷でもいいよ。

941 ：デフォルトの名無しさん：2011/05/31(火) 10:23:14.64

対価がもらえれば奴隷でかまわない

942 ：デフォルトの名無しさん：2011/06/07(火) 17:32:25.07

奴隷の方が、仕事も睡眠時間も食事の時間も決められててマシだよ
って大学の助手が言ってた

943 ：デフォルトの名無しさん：2011/06/07(火) 17:41:44.95

奴隷の監督は酒池肉林どころか
明日は我が身の中間管理職だからな。
責任だけがのしかかるという。

944 ：天使 ◆uL5esZLBSE ：2011/07/05(火) 20:00:39.41

↓↓↓
[[[[[[[[ ほんとかよ、まあ、当時は意外と面白い連中が多かったけどな。 ]]]]]]]](爆ッッ
↑↑↑↑↑↑↑(←嘲ッッッッ笑ッッ！！爆笑ッッ!笑!!
↓↓↓
[[[[[[[[[ 実は、証シス1部にも居た事はあるｗ ]]]]]]]]]（←爆ッッッッ笑ッ!!爆ッッッッ笑ッ!!爆ッッッッ笑ッッ！！

945 ：↑：2011/07/20(水) 11:12:39.20

幼稚園児か・・・

946 ：デフォルトの名無しさん：2011/08/12(金) 09:11:04.17

>>944
何が、そう、君を、そう、させるんだー！

947 ：デフォルトの名無しさん：2011/12/22(木) 22:58:51.23

COBOLCOBOLCOBOLC
OBOLCOBOLCOBOLCO
BOLCOBOLCOBOLCOB
OLCOBOLCOBOLCOBO
LCOBOLCOBOLCOBOL

948 ：デフォルトの名無しさん：2011/12/22(木) 23:15:20.27

　　　　LCOBO　COBLCO　COBO　　COBOC　COLCOBO
　　　　　OBO　　OL　BO　　BO　　　　BOL 　　　LC　　OL
BOLC　　BOL　 OLOBOLC　　LC　　　LC　　　LCOBOLCO
OLBOLCOB　　CO　　　OBO　OBO　COB　　CO　　　　　BOL
　COBOLC　BOLCOBOLCOB　　COBL　　COBOLCOBOLCOB

949 ：デフォルトの名無しさん：2011/12/23(金) 04:01:35.91

Cool Cool Cool

950 ：デフォルトの名無しさん：2012/03/01(木) 23:20:29.55

かつては世界中の金融機関の勘定系（基幹系）システムは全部COBOLで動いていた。

設計思想がやたらと旧かったり、2000年問題の主役の一人だったりで嫌っているプログラマー多し。
だが、COBOLが愛される最大の理由は信頼性だろ
バグ1個で億単位の損害が出る分野には「枯れた技術」や「枯れた言語」が一番いい。
バグや障害などが出尽くした、またはバグがあっても対処方法などが判明している
大抵のとんでもないバグは摘出されているから、バグ1個で大損害とかというところでも安心して使える

COBOLがダメな理由がない限り使い続けるほうがいいに決まってる。

開発者は、新しい技術を扱っていた方が楽しかったりするので、
新しい技術を追いがちですが、未知のバグが潜んでいたり、その分スペックが要求されたりする
新しい言語（技術）に価値があるのではなく、何ができるかに価値があるのですから、別に新しい言語でなくても問題ない

東京海上日動の新システムはCOBOLを採用
http://itpro.nikkeibp.co.jp/article/NEWS/20080906/314277/
COBOLこそスピード経営に必要 BY ジャパネットたかた
http://itpro.nikkeibp.co.jp/article/COLUMN/20100319/345984/
不具合が最も多いのは Java アプリケーション、少ないのは COBOL
http://www.computerworld.com/s/article/9222503/Java_apps_have_most_flaws_Cobol_apps_the_least_study_finds

951 ：デフォルトの名無しさん：2012/03/02(金) 00:35:23.23

うん

952 ：デフォルトの名無しさん：2012/09/09(日) 18:14:04.04

まだ>>９５０みたいなことをネタで言ってる奴がいるのかというｗ

953 ：デフォルトの名無しさん：2012/09/16(日) 12:00:25.25

少しスレチだがJava 6のリファレンスが遂に無くなったな
アクセスするとOracleのトップに飛ばされる
どうやらJavaは本格的にEnglish onlyになるらしい

954 ：デフォルトの名無しさん：2012/10/14(日) 19:49:33.04

>>953
http://docs.oracle.com/javase/jp/6/api/

955 ：デフォルトの名無しさん：2012/12/12(水) 21:18:35.85

ハロワで26歳無職ニートがCOBOLラン系の職につこうとしているので
アドバイスください。

956 ：デフォルトの名無しさん：2013/01/18(金) 19:27:04.02

知識よりも上司との人間関係や体力

957 ：デフォルトの名無しさん：2013/11/04(月) 18:16:44.71

保守age

958 ：片山博文MZコスモ ◆T6xkBnTXz7B0 ：2013/11/06(水) 03:59:17.55

COBOLのプログラムをJAVAに移植するのに役立つライブラリは何でしょうか？

959 ：デフォルトの名無しさん：2013/11/06(水) 16:36:15.39

>>958
http://toro.2ch.net/test/read.cgi/tech/1316444803/352

960 ：デフォルトの名無しさん：2014/04/02(水) 06:24:59.22 ID:YuPkVvCA

20年くらいCOBOLしか触ってないおっさんがJAVAの入門書みて勉強してるんだけど
なんか作る気にならんとやる気でないね(´･ω･`)

961 ：デフォルトの名無しさん：2014/04/02(水) 06:50:22.09 ID:UxJPt08w

COBOLのコンパイラとか

962 ：デフォルトの名無しさん：2014/04/02(水) 08:14:53.44 ID:GIdJz2NO

モチベーションの源はエロだよ
静止画でも動画でもいい、自分用のエロDBを作ってみるんだ

963 ：デフォルトの名無しさん：2014/06/05(木) 01:32:37.38 ID:wuUUC+ej

>>960
(´･ω･`)入(´･ω･`)ﾅｶｰﾏ

964 ：デフォルトの名無しさん：2014/06/08(日) 07:54:35.39 ID:3YpOp6yu

自分も20年位のCOBOLERだけど、何か目的が無いと
全く勉強が進まない。
最近はフリーウェアなりシェアウェアなりでかなり便利な
ツールがあるからそれを上手に利用するのが良いですね。
物作りに携わってきた人間としては寂しいですが。
汎用機のCOBOLERがPCで何か作ろうとすると、OpenCOBOL
って有効なツールなんだろうか？

965 ：デフォルトの名無しさん：2014/07/14(月) 22:40:28.27 ID:4A74nF8C

>>963
ムカツクw

966 ：デフォルトの名無しさん：2014/07/16(水) 16:38:00.99 ID:FUxHai3/

(´･ω･`)←最近見かけるＡＡだが、これ見るとむかつく。今後一切禁止だ。わかったな。??

967 ：デフォルトの名無しさん：2014/07/16(水) 17:45:26.19 ID:VVSFNUoz

あい(´･ω･`)

968 ：デフォルトの名無しさん：2014/07/17(木) 17:23:13.85 ID:uZH0ckts

>>966
わかった(´･ω･`)

969 ：デフォルトの名無しさん：2014/07/18(金) 16:21:03.21 ID:dLPMex84

(´･ω･`)