981コメント392KB

COBOL vs Java 2戦目

レス数が950を超えています。1000を超えると書き込みができなくなります。

0001デフォルトの名無しさん

2006/09/13(水) 22:37:48

前スレです。

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

0002デフォルトの名無しさん

2006/09/13(水) 23:47:12

に

0003デフォルトの名無しさん

2006/09/16(土) 21:16:42

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

0004デフォルトの名無しさん

2006/09/17(日) 22:59:36

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

0005デフォルトの名無しさん

2006/09/18(月) 04:22:12

>>3

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

0006デフォルトの名無しさん

2006/09/18(月) 04:25:52

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

0007デフォルトの名無しさん

2006/09/18(月) 06:06:59

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

0008デフォルトの名無しさん

2006/09/18(月) 10:48:52

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

0009デフォルトの名無しさん

2006/09/18(月) 19:47:20

COBOL.JVM

0010デフォルトの名無しさん

2006/09/19(火) 07:13:51

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

0011デフォルトの名無しさん

2006/09/20(水) 04:56:07

javaは5年後に死滅

0012デフォルトの名無しさん

2006/09/21(木) 15:56:16

jCOBOL

0013デフォルトの名無しさん

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の普及が拡大するにつれ、このメリットは等比級数的に増大すると
我々は睨んでいる。

0014デフォルトの名無しさん

2006/09/23(土) 07:40:24

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

0015デフォルトの名無しさん

2006/09/23(土) 07:41:41

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

0016デフォルトの名無しさん

2006/09/23(土) 08:28:11

>>14-15

つJ#

0017デフォルトの名無しさん

2006/09/23(土) 17:05:59

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

0018デフォルトの名無しさん

2006/09/24(日) 13:16:44

電光超特急コボリアン

0019デフォルトの名無しさん

2006/09/30(土) 02:19:46

>>17

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

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

0020デフォルトの名無しさん

2006/09/30(土) 03:06:05

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

0021デフォルトの名無しさん

2006/09/30(土) 04:40:35

>>16
アッチョンブリケ

0022デフォルトの名無しさん

2006/09/30(土) 06:17:22

>>20

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

0023デフォルトの名無しさん

2006/09/30(土) 09:17:44

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

0024デフォルトの名無しさん

2006/09/30(土) 13:43:14

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

0025デフォルトの名無しさん

2006/09/30(土) 20:21:04

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

0026デフォルトの名無しさん

2006/09/30(土) 22:44:21

漏れの某地銀で仕事していて、M菱系の営業にだまされたっぽい
ふぁいぶりっじとか言うﾂｶｴﾈｰ電子化帳票な配布ｼｽﾃﾑ(なんだろうか?)
を使っているのをみた。

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

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

0027デフォルトの名無しさん

2006/09/30(土) 22:53:18

>>25
＞Webで一番スマートなやりかたってなんなんだろうね。
＞やっぱPDFに落とすのかな？

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

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

0028デフォルトの名無しさん

2006/10/01(日) 01:44:39

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

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

0029デフォルトの名無しさん

2006/10/01(日) 07:42:59

漏れは旧型の洗濯機と区別がつかないラインプリンタは見たこと
あるなぁ。印刷音もすざまじいモノがあったが。

ｲﾝﾀｰﾌｪｲｽもﾂｲﾝﾅｯｸｽとかいう今は亡き接続方だったような。
現役の部署もあると思うけど。

CanonのレーザープリンタにはIBMの5577(だったかなぁ）の
ｴﾐｭﾚｰｼｮﾝｶｰﾄﾞがあるし、Windowsにそういったプリンターの
ｴﾐｭﾚｰﾀｰってあるし、ｾﾞﾛｯｸｽとかにUNIX内蔵のプリンタとかは
汎用機とWindows印刷と混在出来るよ。
ﾘｺｰも同様の事ができたと思う。

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

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

0030デフォルトの名無しさん

2006/10/01(日) 16:11:22

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

0031デフォルトの名無しさん

2006/10/01(日) 20:17:46

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

0032デフォルトの名無しさん

2006/10/01(日) 22:33:58

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

0033デフォルトの名無しさん

2006/10/03(火) 10:20:46

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

0034デフォルトの名無しさん

2006/10/03(火) 10:54:07

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

0035デフォルトの名無しさん

2006/10/03(火) 11:14:06

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

0036デフォルトの名無しさん

2006/10/03(火) 11:36:09

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

0037デフォルトの名無しさん

2006/10/03(火) 13:13:40

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

0038デフォルトの名無しさん

2006/10/03(火) 20:38:54

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

0039デフォルトの名無しさん

2006/10/03(火) 23:26:08

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

0040デフォルトの名無しさん

2006/10/13(金) 23:26:28

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

0041デフォルトの名無しさん

2006/10/25(水) 01:26:56

0042デフォルトの名無しさん

2006/10/27(金) 22:57:27

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

0043デフォルトの名無しさん

2006/10/27(金) 23:27:55

RPGのいいトコかー。

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

いるんだよ…。マジでそういうRPGﾌﾟﾛｸﾞﾗﾏｰ
MONMSGをを全ｷｬﾝｾﾙしてたりさー。

0044デフォルトの名無しさん

2006/10/30(月) 11:26:58

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

0045デフォルトの名無しさん

2006/10/30(月) 21:50:01

>>44
文字化けしっぱなしでもテーブルに出力できるよ。

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

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

まあ、コレもKEYにﾃﾞﾀﾗﾒな値入れられていたら泣くしかないんだが。

0046デフォルトの名無しさん

2006/10/31(火) 11:25:59

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

0047デフォルトの名無しさん

2006/10/31(火) 18:51:28

まあ、あれは必要は発明の母的な仕様かと。

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

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

orz

0048デフォルトの名無しさん

2006/11/02(木) 00:24:17

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

0049デフォルトの名無しさん

2006/11/02(木) 10:10:10

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

0050デフォルトの名無しさん

2006/11/04(土) 23:17:45

そおいやRPGのスレってないんだな。

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

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

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

0051デフォルトの名無しさん

2006/11/25(土) 00:22:03

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

0052デフォルトの名無しさん

2006/12/23(土) 08:43:03

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

0053デフォルトの名無しさん

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とか・・・

0054デフォルトの名無しさん

2006/12/26(火) 23:09:09

COBOLerの方は「複雑な計算はCOBOL(RPG)で」とよく言われて、
案件を自分のスタイルにハメようとした人がいたけど、
そのソースみたら別の意味で複雑（ｗ）だっただけだったな。

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

0055デフォルトの名無しさん

2006/12/27(水) 00:30:28

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

0056デフォルトの名無しさん

2006/12/27(水) 00:33:44

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

0057デフォルトの名無しさん

2006/12/27(水) 17:49:19

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

0058デフォルトの名無しさん

2006/12/27(水) 23:30:14

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

0059デフォルトの名無しさん

2006/12/28(木) 06:57:15

＞ドットプリンタで複写用紙を使っている企業は、COBOLの書式付き出力が必要。

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

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

0060デフォルトの名無しさん

2006/12/28(木) 13:00:05

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

006157

2006/12/28(木) 15:07:16

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

006257

2006/12/28(木) 15:09:08

日本の宅配業者はまだドットプリンタを使って帳票処理をしているが、
米国から輸入するとほとんどレーザプリンタで、処理していることが
わかる。

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

0063デフォルトの名無しさん

2006/12/28(木) 15:43:23

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

0064デフォルトの名無しさん

2006/12/28(木) 15:43:29

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

0065デフォルトの名無しさん

2006/12/28(木) 16:03:35

別に昔のシステムに関しての話なら、昔は昔の事情があって、
COBOLにラインプリンタとかの仕事が多かった、って意見は
それはそれでいいし、昔のブツを大切に使いつづける姿勢は
それはそれでいいと思うよ。

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

そして現在の技術を勉強せずにひたすらｸﾀﾞﾗﾈｪ、デスマを
繰り返したりするから始末におえん。

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

0066デフォルトの名無しさん

2006/12/28(木) 16:07:29

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

0067デフォルトの名無しさん

2006/12/28(木) 16:17:51

>>66
確かCOBOLでSAM形式のファイルを作成してそれをOracleにロードしていた。
処理もSAM形式にしてCOBOLで処理していた。
だから、そのチームのエンジニアはOracleで運用・開発していると言っても、
RDBでもなんでもなくて、カラムが200～300くらいあるデータを送ってくる。
Oracleは単なる詰め物と化していた。

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

0068デフォルトの名無しさん

2006/12/28(木) 23:41:28

昔バッチ処理のパフォーマンス対応でそんなことやった気ガス。
SQL書くよりなんぼか早かった。

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

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

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

0069デフォルトの名無しさん

2006/12/29(金) 10:06:05

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

0070デフォルトの名無しさん

2006/12/31(日) 22:44:02

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

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

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

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

0071デフォルトの名無しさん

2007/01/13(土) 18:59:51

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

0072デフォルトの名無しさん

2007/02/06(火) 20:42:37

Java win.

0073デフォルトの名無しさん

2007/02/12(月) 06:31:52

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

どうなんだ？

0074デフォルトの名無しさん

2007/02/12(月) 11:23:34

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

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

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

0075デフォルトの名無しさん

2007/02/14(水) 02:50:22

>>71

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

0076デフォルトの名無しさん

2007/02/18(日) 05:11:43

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

0077デフォルトの名無しさん

2007/02/18(日) 10:50:38

理想の姿だと思う。

0078デフォルトの名無しさん

2007/02/19(月) 00:31:15

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

0079デフォルトの名無しさん

2007/02/20(火) 21:03:11

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

0080デフォルトの名無しさん

2007/03/17(土) 00:57:42

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

0081デフォルトの名無しさん

2007/04/23(月) 01:51:54

0082デフォルトの名無しさん

2007/05/26(土) 05:48:57

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

0083デフォルトの名無しさん

2007/05/26(土) 08:54:05

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

0084デフォルトの名無しさん

2007/06/01(金) 03:02:03

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

0085デフォルトの名無しさん

2007/06/04(月) 00:18:03

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

0086デフォルトの名無しさん

2007/06/04(月) 00:18:53

あぼ～んの事じゃない？

0087デフォルトの名無しさん

2007/06/04(月) 01:26:22

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

0088デフォルトの名無しさん

2007/06/04(月) 05:27:57

ABEND = ABNORMAL END だな

0089デフォルトの名無しさん

2007/07/09(月) 10:43:15

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

0090デフォルトの名無しさん

2007/08/13(月) 02:08:33

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

0091デフォルトの名無しさん

2007/08/13(月) 02:16:28

お前らが言っているのは

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

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

0092デフォルトの名無しさん

2007/08/13(月) 15:43:18

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

0093デフォルトの名無しさん

2007/08/13(月) 17:45:33

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

0094デフォルトの名無しさん

2007/08/13(月) 18:39:39

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

0095デフォルトの名無しさん

2007/08/14(火) 06:04:14

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

0096デフォルトの名無しさん

2007/08/31(金) 00:31:04

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

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

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

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

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

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

0097デフォルトの名無しさん

2007/08/31(金) 00:42:26

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

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

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

0098デフォルトの名無しさん

2007/08/31(金) 00:56:01

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

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

0099デフォルトの名無しさん

2007/08/31(金) 00:58:51

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

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

0100デフォルトの名無しさん

2007/08/31(金) 01:01:49

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

0101デフォルトの名無しさん

2007/08/31(金) 01:04:37

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

0102デフォルトの名無しさん

2007/09/01(土) 10:51:24

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

0103デフォルトの名無しさん

2007/09/02(日) 14:05:19

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

0104デフォルトの名無しさん

2007/10/15(月) 21:53:40

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

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

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

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

0105デフォルトの名無しさん

2007/10/31(水) 14:07:17

ＣＯＢＯＬ経験者急募

0106デフォルトの名無しさん

2007/11/02(金) 15:39:34

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

0107デフォルトの名無しさん

2007/11/02(金) 15:55:59

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

0108デフォルトの名無しさん

2007/11/05(月) 23:20:47

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

0109デフォルトの名無しさん

2007/11/07(水) 13:31:21

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

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

0110デフォルトの名無しさん

2007/11/25(日) 15:14:50

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

　　　　COBOL圧勝

0111デフォルトの名無しさん

2007/11/30(金) 05:16:23

>>100

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

0112デフォルトの名無しさん

2007/12/07(金) 23:14:00

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

0113デフォルトの名無しさん

2007/12/08(土) 02:03:53

>>112
C#

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

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

0114デフォルトの名無しさん

2007/12/08(土) 08:49:31

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

0115112

2007/12/08(土) 09:38:02

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

0116デフォルトの名無しさん

2007/12/08(土) 11:04:41

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

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

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

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

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

0117デフォルトの名無しさん

2007/12/08(土) 11:39:07

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

0118デフォルトの名無しさん

2007/12/12(水) 09:03:27

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

0119デフォルトの名無しさん

2008/01/10(木) 10:10:40

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

0120デフォルトの名無しさん

2008/02/04(月) 04:33:13

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

0121デフォルトの名無しさん

2008/02/04(月) 06:24:20

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

0122デフォルトの名無しさん

2008/02/04(月) 07:33:41

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

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

0123デフォルトの名無しさん

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ではなくなります。

0124デフォルトの名無しさん

2008/02/16(土) 22:34:38

マルチしすぎだろ

0125デフォルトの名無しさん

2008/05/24(土) 03:57:53

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

0126デフォルトの名無しさん

2008/06/06(金) 22:45:41

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

0127デフォルトの名無しさん

2008/06/07(土) 00:32:45

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

0128デフォルトの名無しさん

2008/06/08(日) 00:51:47

宗教じゃあるまいに

0129デフォルトの名無しさん

2008/06/23(月) 00:20:21

ビデオ、だと・・・？

0130デフォルトの名無しさん

2008/06/29(日) 08:45:34

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

0131デフォルトの名無しさん

2008/07/09(水) 23:04:23

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

"regacy program"

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

0132デフォルトの名無しさん

2008/07/09(水) 23:05:24

COBOLer, 年金返してくれ。

0133デフォルトの名無しさん

2008/07/18(金) 15:47:12

>>123

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

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

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

0134デフォルトの名無しさん

2008/07/18(金) 15:49:58

>>131

regacy じゃなくて legacy でしょ。

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

0135デフォルトの名無しさん

2008/07/18(金) 16:10:24

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

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

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

0136デフォルトの名無しさん

2008/07/19(土) 01:24:07

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

0137デフォルトの名無しさん

2008/07/19(土) 10:28:11

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

0138デフォルトの名無しさん

2008/07/19(土) 17:43:39

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

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

0139デフォルトの名無しさん

2008/07/19(土) 17:49:39

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

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

0140デフォルトの名無しさん

2008/07/19(土) 18:28:36

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

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

0141デフォルトの名無しさん

2008/07/19(土) 19:07:09

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

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

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

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

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

0142デフォルトの名無しさん

2008/07/19(土) 20:07:45

>>139

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

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

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

0143デフォルトの名無しさん

2008/07/19(土) 20:34:14

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

0144デフォルトの名無しさん

2008/07/19(土) 20:38:05

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

0145デフォルトの名無しさん

2008/07/19(土) 21:03:58

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

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

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

0146デフォルトの名無しさん

2008/07/20(日) 14:55:29

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

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

0147デフォルトの名無しさん

2008/07/20(日) 15:09:53

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

0148デフォルトの名無しさん

2008/07/20(日) 16:25:18

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

0149デフォルトの名無しさん

2008/07/22(火) 20:58:16

TextSS

0150デフォルトの名無しさん

2008/07/22(火) 23:44:46

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

0151デフォルトの名無しさん

2008/07/24(木) 21:46:12

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

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

0152デフォルトの名無しさん

2008/07/25(金) 22:42:55

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

0153デフォルトの名無しさん

2008/07/26(土) 00:12:17

コボルが殿様でJavaは家来

0154デフォルトの名無しさん

2008/07/26(土) 10:47:49

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

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

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

0155デフォルトの名無しさん

2008/07/26(土) 12:50:22

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

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

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

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

0156デフォルトの名無しさん

2008/07/27(日) 15:18:08

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

0157154

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（簡単）
と作り直して実験してみたいなぁ、といつも思っているんだが、
日々の仕事で、そんな余裕はない。

0158デフォルトの名無しさん

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の基礎も
解っていない素人にしか思えん。

0159デフォルトの名無しさん

2008/07/29(火) 12:38:11

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

0160デフォルトの名無しさん

2008/07/29(火) 12:49:57

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

0161154

2008/07/29(火) 23:04:31

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

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

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

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

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

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

0162デフォルトの名無しさん

2008/07/30(水) 00:23:55

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

0163デフォルトの名無しさん

2008/07/30(水) 02:39:46

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

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

0164154

2008/07/30(水) 07:47:12

出勤前にかきこ

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

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

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

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

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

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

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

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

0165デフォルトの名無しさん

2008/07/30(水) 11:22:50

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

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

0166デフォルトの名無しさん

2008/07/30(水) 18:33:20

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

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

0167デフォルトの名無しさん

2008/08/01(金) 18:30:04

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

0168デフォルトの名無しさん

2008/08/01(金) 18:40:35

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

0169デフォルトの名無しさん

2008/08/01(金) 18:44:38

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

0170デフォルトの名無しさん

2008/08/01(金) 23:01:41

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

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

0171デフォルトの名無しさん

2008/08/06(水) 22:19:47

COBOLerどもうぜー

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

0172デフォルトの名無しさん

2008/08/07(木) 14:37:04

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

0173デフォルトの名無しさん

2008/08/08(金) 20:56:47

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

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

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

0174デフォルトの名無しさん

2008/08/08(金) 22:24:20

「場合があるよ」

非常に技術的な回答だ。

0175デフォルトの名無しさん

2008/08/09(土) 00:15:11

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

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

0176デフォルトの名無しさん

2008/08/09(土) 08:56:51

死ね

0177デフォルトの名無しさん

2008/08/14(木) 19:22:35

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

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

0178デフォルトの名無しさん

2008/08/14(木) 21:30:20

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

0179デフォルトの名無しさん

2008/08/15(金) 01:25:52

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

0180デフォルトの名無しさん

2008/08/15(金) 08:33:11

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

0181デフォルトの名無しさん

2008/08/15(金) 10:12:30

×　あいつら
○　おれら

0182デフォルトの名無しさん

2008/08/16(土) 08:06:48

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

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

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

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

0183デフォルトの名無しさん

2008/08/16(土) 09:00:42

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

0184デフォルトの名無しさん

2008/08/16(土) 13:57:21

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

0185デフォルトの名無しさん

2008/08/16(土) 21:15:41

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

0186デフォルトの名無しさん

2008/08/17(日) 11:28:39

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

0187デフォルトの名無しさん

2008/08/19(火) 18:28:35

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

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

0188デフォルトの名無しさん

2008/08/19(火) 22:20:31

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

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

0189デフォルトの名無しさん

2008/08/20(水) 10:51:42

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

0190デフォルトの名無しさん

2008/08/27(水) 10:20:48

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

0191デフォルトの名無しさん

2008/08/27(水) 23:25:12

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

0192デフォルトの名無しさん

2008/08/27(水) 23:35:40

仕事だもんな・・・ｗ

0193デフォルトの名無しさん

2008/08/28(木) 01:05:26

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

0194デフォルトの名無しさん

2008/08/28(木) 01:54:32

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

0195デフォルトの名無しさん

2008/08/28(木) 09:52:05

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

0196デフォルトの名無しさん

2008/08/29(金) 00:36:17

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

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

0197デフォルトの名無しさん

2008/08/29(金) 09:52:57

そうか。なるほど。

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

0198デフォルトの名無しさん

2008/08/29(金) 12:41:41

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

0199デフォルトの名無しさん

2008/08/29(金) 14:29:36

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

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

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

0200デフォルトの名無しさん

2008/08/29(金) 14:31:34

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

0201デフォルトの名無しさん

2008/08/29(金) 15:14:05

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

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

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

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

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

0202デフォルトの名無しさん

2008/08/29(金) 15:59:11

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

「COMAL」

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

0203デフォルトの名無しさん

2008/08/29(金) 16:13:15

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

0204デフォルトの名無しさん

2008/08/29(金) 22:17:25

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

0205デフォルトの名無しさん

2008/08/29(金) 23:57:21

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

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

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

0206デフォルトの名無しさん

2008/08/30(土) 00:52:13

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

0207デフォルトの名無しさん

2008/08/30(土) 01:01:42

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

0208デフォルトの名無しさん

2008/08/30(土) 10:27:34

>>205

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

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

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

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

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

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

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

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

0209デフォルトの名無しさん

2008/08/30(土) 18:49:39

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

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

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

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

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

0210デフォルトの名無しさん

2008/08/30(土) 19:37:42

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

0211デフォルトの名無しさん

2008/08/31(日) 00:13:32

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

0212デフォルトの名無しさん

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

0213デフォルトの名無しさん

2008/08/31(日) 10:20:55

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

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

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

0214デフォルトの名無しさん

2008/08/31(日) 10:44:30

>>212

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

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

0215デフォルトの名無しさん

2008/08/31(日) 10:51:36

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

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

0216デフォルトの名無しさん

2008/08/31(日) 11:14:07

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

俺もちゃんと読もう。

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

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

0217212

2008/08/31(日) 12:13:50

>>216

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

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

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

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

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

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

0218デフォルトの名無しさん

2008/08/31(日) 13:48:26

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

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

0219デフォルトの名無しさん

2008/08/31(日) 15:48:18

>>217

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

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

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

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

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

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

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

0220デフォルトの名無しさん

2008/08/31(日) 15:55:19

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

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

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

0221デフォルトの名無しさん

2008/08/31(日) 18:36:03

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

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

0222デフォルトの名無しさん

2008/08/31(日) 18:36:59

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

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

0223デフォルトの名無しさん

2008/08/31(日) 19:47:57

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

0224212

2008/08/31(日) 20:20:49

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

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

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

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

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

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

0225デフォルトの名無しさん

2008/08/31(日) 23:40:54

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

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

すこしは勉強なさい。

0226デフォルトの名無しさん

2008/09/01(月) 05:24:41

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

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

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

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

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

0227デフォルトの名無しさん

2008/09/01(月) 07:53:08

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

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

0228デフォルトの名無しさん

2008/09/01(月) 08:50:34

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

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

0229デフォルトの名無しさん

2008/09/01(月) 09:59:03

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

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

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

0230デフォルトの名無しさん

2008/09/01(月) 10:00:08

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

0231デフォルトの名無しさん

2008/09/01(月) 10:11:26

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

0232デフォルトの名無しさん

2008/09/01(月) 10:40:37

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

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

0233デフォルトの名無しさん

2008/09/01(月) 10:52:16

そして、速い。

0234デフォルトの名無しさん

2008/09/01(月) 10:53:20

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

0235デフォルトの名無しさん

2008/09/01(月) 10:57:48

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

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

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

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

0236デフォルトの名無しさん

2008/09/01(月) 12:11:35

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

0237デフォルトの名無しさん

2008/09/01(月) 14:01:24

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

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

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

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

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

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

0238デフォルトの名無しさん

2008/09/01(月) 14:05:41

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

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

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

0239デフォルトの名無しさん

2008/09/01(月) 14:07:06

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

0240デフォルトの名無しさん

2008/09/02(火) 00:16:57

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

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

0241デフォルトの名無しさん

2008/09/02(火) 02:59:04

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

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

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

不自然だろ。

0242デフォルトの名無しさん

2008/09/02(火) 07:38:45

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

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

0243デフォルトの名無しさん

2008/09/02(火) 10:04:32

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

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

>不自然だろ。

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

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

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

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

0244デフォルトの名無しさん

2008/09/02(火) 11:47:30

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

0245デフォルトの名無しさん

2008/09/02(火) 17:00:20

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

0246デフォルトの名無しさん

2008/09/03(水) 01:38:06

>>243

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

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

君は間違っている。

0247デフォルトの名無しさん

2008/09/03(水) 01:49:50

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

0248デフォルトの名無しさん

2008/09/03(水) 04:02:36

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

0249デフォルトの名無しさん

2008/09/03(水) 10:55:59

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

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

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

>>247

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

0250デフォルトの名無しさん

2008/09/03(水) 10:58:38

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

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

＞不自然だろ。

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

0251デフォルトの名無しさん

2008/09/03(水) 11:31:08

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

0252デフォルトの名無しさん

2008/09/03(水) 11:32:57

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

0253デフォルトの名無しさん

2008/09/03(水) 11:40:40

ビートたけしは死ね

0254デフォルトの名無しさん

2008/09/03(水) 12:06:45

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

0255デフォルトの名無しさん

2008/09/03(水) 12:09:02

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

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

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

0256デフォルトの名無しさん

2008/09/03(水) 16:37:37

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

0257デフォルトの名無しさん

2008/09/03(水) 23:52:34

>>256

ありがとう。

0258デフォルトの名無しさん

2008/09/04(木) 01:08:00

>>249

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

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

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

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

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

0259デフォルトの名無しさん

2008/09/04(木) 08:04:00

>>249

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

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

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

0260デフォルトの名無しさん

2008/09/06(土) 12:00:52

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

0261デフォルトの名無しさん

2008/09/06(土) 13:15:47

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

0262デフォルトの名無しさん

2008/09/06(土) 15:24:17

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

0263デフォルトの名無しさん

2008/09/06(土) 17:05:46

>>262

すばらしい

0264デフォルトの名無しさん

2008/09/06(土) 20:47:42

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

0265デフォルトの名無しさん

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人月って幾らなんだよってことになるからな。
ハハハ･･･。

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

0266デフォルトの名無しさん

2008/09/07(日) 00:40:26

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

0267デフォルトの名無しさん

2008/09/07(日) 01:45:33

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

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

0268デフォルトの名無しさん

2008/09/07(日) 06:55:00

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

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

0269デフォルトの名無しさん

2008/09/08(月) 00:42:25

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

0270デフォルトの名無しさん

2008/09/08(月) 09:03:58

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

0271デフォルトの名無しさん

2008/09/08(月) 10:49:19

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

0272デフォルトの名無しさん

2008/09/08(月) 23:24:45

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

0273デフォルトの名無しさん

2008/09/09(火) 08:07:36

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

0274デフォルトの名無しさん

2008/09/09(火) 18:40:21

曲学阿世

0275デフォルトの名無しさん

2008/09/09(火) 20:50:38

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

0276デフォルトの名無しさん

2008/09/09(火) 21:13:32

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

0277デフォルトの名無しさん

2008/09/10(水) 00:21:57

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

0278デフォルトの名無しさん

2008/09/10(水) 07:13:49

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

0279デフォルトの名無しさん

2008/09/10(水) 17:54:33

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

0280デフォルトの名無しさん

2008/09/10(水) 22:13:31

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

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

0281デフォルトの名無しさん

2008/09/10(水) 23:20:25

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

0282デフォルトの名無しさん

2008/09/11(木) 00:44:20

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

0283デフォルトの名無しさん

2008/09/11(木) 07:48:43

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

0284デフォルトの名無しさん

2008/09/11(木) 16:05:07

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

0285デフォルトの名無しさん

2008/09/11(木) 22:56:50

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

0286デフォルトの名無しさん

2008/09/12(金) 01:13:27

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

0287デフォルトの名無しさん

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億件ぐらい行ってしまうのかも知れないね。

0288デフォルトの名無しさん

2008/09/12(金) 08:56:52

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

0289デフォルトの名無しさん

2008/09/12(金) 11:08:56

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

0290デフォルトの名無しさん

2008/09/12(金) 11:55:36

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

0291デフォルトの名無しさん

2008/09/13(土) 03:47:46

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

0292デフォルトの名無しさん

2008/09/14(日) 03:16:22

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

0293デフォルトの名無しさん

2008/09/14(日) 03:46:39

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

0294デフォルトの名無しさん

2008/09/14(日) 05:10:13

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

0295デフォルトの名無しさん

2008/09/15(月) 21:11:12

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

0296デフォルトの名無しさん

2008/09/28(日) 02:43:22

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

0297デフォルトの名無しさん

2008/09/29(月) 15:58:11

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

0298デフォルトの名無しさん

2008/09/29(月) 16:16:02

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

0299デフォルトの名無しさん

2008/09/29(月) 16:17:57

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

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

0300デフォルトの名無しさん

2008/09/29(月) 17:03:51

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

そうじゃないぞ。

0301デフォルトの名無しさん

2008/10/04(土) 16:58:22

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

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

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

0302デフォルトの名無しさん

2008/10/05(日) 06:55:42

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

0303デフォルトの名無しさん

2008/10/05(日) 12:55:23

優秀なSIerとは、

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

0304デフォルトの名無しさん

2008/11/02(日) 01:20:06

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

0305デフォルトの名無しさん

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

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

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

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

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

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

0306デフォルトの名無しさん

2008/11/22(土) 20:08:17

age

0307デフォルトの名無しさん

2008/11/24(月) 11:34:51

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

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

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

下向いちゃうしｗｗ

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

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

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

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

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

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

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

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

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

http://anond.hatelabo.jp/20081111000645

0308デフォルトの名無しさん

2008/11/24(月) 11:55:23

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

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

0309デフォルトの名無しさん

2008/11/24(月) 14:45:12

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

0310デフォルトの名無しさん

2008/11/24(月) 16:49:33

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

0311デフォルトの名無しさん

2008/11/24(月) 19:08:37

黒田さん？

0312デフォルトの名無しさん

2008/11/24(月) 19:13:23

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

0313デフォルトの名無しさん

2008/11/24(月) 23:39:08

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

0314デフォルトの名無しさん

2008/11/25(火) 08:25:36

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

0315デフォルトの名無しさん

2008/11/28(金) 06:29:45

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

0316デフォルトの名無しさん

2008/12/02(火) 21:45:44

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

0317デフォルトの名無しさん

2008/12/02(火) 22:55:29

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

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

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

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

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

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

0318デフォルトの名無しさん

2008/12/03(水) 06:23:16

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

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

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

0319デフォルトの名無しさん

2008/12/03(水) 12:01:00

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

0320デフォルトの名無しさん

2008/12/03(水) 19:44:20

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

0321デフォルトの名無しさん

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

0322デフォルトの名無しさん

2008/12/07(日) 01:37:30

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

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

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

0323デフォルトの名無しさん

2008/12/07(日) 04:18:35

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

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

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

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

0324デフォルトの名無しさん

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

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

0325デフォルトの名無しさん

2008/12/07(日) 11:54:00

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

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

0326デフォルトの名無しさん

2008/12/07(日) 12:49:21

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

0327デフォルトの名無しさん

2008/12/07(日) 20:45:54

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

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

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

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

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

0328デフォルトの名無しさん

2008/12/07(日) 21:58:17

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

0329デフォルトの名無しさん

2008/12/08(月) 10:32:40

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

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

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

0330デフォルトの名無しさん

2009/01/08(木) 21:49:10

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

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

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

0331デフォルトの名無しさん

2009/01/09(金) 09:53:25

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

0332デフォルトの名無しさん

2009/01/09(金) 13:06:04

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

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

両方コメントいれとけよ

0333デフォルトの名無しさん

2009/01/10(土) 21:32:52

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

0334デフォルトの名無しさん

2009/01/11(日) 11:05:07

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

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

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

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

0335デフォルトの名無しさん

2009/01/11(日) 11:57:46

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

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

0336デフォルトの名無しさん

2009/01/11(日) 14:49:36

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

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

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

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

0337デフォルトの名無しさん

2009/01/11(日) 20:33:09

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

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

0338デフォルトの名無しさん

2009/01/11(日) 20:34:49

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

0339デフォルトの名無しさん

2009/01/11(日) 22:45:17

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

0340デフォルトの名無しさん

2009/01/12(月) 05:32:33

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

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

0341デフォルトの名無しさん

2009/01/12(月) 10:44:47

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

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

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

0342デフォルトの名無しさん

2009/01/12(月) 13:33:00

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

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

0343デフォルトの名無しさん

2009/01/12(月) 18:47:17

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

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

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

0344デフォルトの名無しさん

2009/02/11(水) 17:21:42

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

0345デフォルトの名無しさん

2009/02/11(水) 17:25:57

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

0346デフォルトの名無しさん

2009/02/11(水) 18:40:55

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

0347デフォルトの名無しさん

2009/02/11(水) 21:53:24

>>344
×資産
○負の遺産

0348デフォルトの名無しさん

2009/02/11(水) 23:11:36

メインフレーム＋COBOLの安定性をJavaで出せますか？
Java+Struts+Spring+Hibernateで超大規模金融系の基幹システムを作れますか？

0349デフォルトの名無しさん

2009/02/11(水) 23:47:56

某大手金融機関では、メインフレームLinuxを採用してCobolとJavaの共存をはかり、
新規開発分はほぼJavaに一本化されていますが、なにか。

0350デフォルトの名無しさん

2009/02/11(水) 23:52:59

＞メインフレーム＋COBOLの安定性をJavaで出せますか？
ぶっちゃけ楽勝だろう。
漏れの目の前でアベンドしまくっているメインフレーム＋COBOLのシステムが存在してる。
あれを越える安定性なんかチョロい。

＞Java+Struts+Spring+Hibernateで超大規模金融系の基幹システムを作れますか？
なんでStruts指定なのか解らんし、超大規模金融系って具体的にどこの銀行を指してんだ？
都銀(MUFG)レベルでいいなら、それにC,C++,Python,SQLくらい足せば余裕で可能だろう。

0351デフォルトの名無しさん

2009/02/11(水) 23:59:06

>>346
手続型言語なんて、どれも似たりよったりなのに何で路頭に迷うんだろ。
経験的には、2週間くらい学習すれば、困らない程度には使えるようになると思うんだが。
(Prologとか、発想の転換が必要な言語は除くけど)

0352デフォルトの名無しさん

2009/02/12(木) 00:00:20

高レベルなJavaの技術者で業務に詳しい人材を大量に集めることは可能なの？
無理だよね。
もう間をとってCかDelphiでいいじゃん。

0353デフォルトの名無しさん

2009/02/12(木) 00:05:23

Javaってたまに原因不明でスレッドダンプはいて氏んでる光景をみるよ。
怖くて使えない。
これからはFORTRANかLispだな。
といいながら、今、VC++の案件をしてるけど。

0354デフォルトの名無しさん

2009/02/12(木) 06:44:58

＞Javaってたまに原因不明でスレッドダンプ
スレッドダンプしてるなら原因わかってるじゃん。
OSごとコアダンプ吐いて死亡したならわからんだろうけど。

つかCOBOLでアベンドした時に担当者に聞くと「それはオレが作ったプログラムじゃないから
知らん。」とかなって人海戦術で関連プログラムをソースレベルで机上解析から始まるんだが、
正直、殺意しか沸いてこない。

COBOLerにはユニットテストと言う概念がないんだろうなぁ、と感じる。

0355デフォルトの名無しさん

2009/02/12(木) 07:39:17

>>352
業務に詳しいってのが既に痛いんだよな
業務をきっちり説明して仕様決めるのは、客の責任だろ？
そういうのを無茶苦茶にしてるから、いつまでたってもデスマーチなんだよ

0356デフォルトの名無しさん

2009/02/12(木) 21:08:38

>>355
うへｗこれは釣りなのか・・・
客が仕様決めるのは当たり前って・・・無理難題に無駄な機能のオンパレードですよ・・・
それこそデスマーチｗ

そもそも法律（税率など）が変わった時にちゃんと対応できるように作らないといけないから
知識がないとお客に提案も質問も出来ないよ。
金融に詳しくない人が金融系のシステムを作るとか俺なら絶対依頼も請負もしたくない
システム1時間止まっただけでも・・・・何億何兆円の損失が出るんだろう・・・・

0357デフォルトの名無しさん

2009/02/12(木) 21:42:56

>>356
そうやってロックインするんですね
わかります

0358デフォルトの名無しさん

2009/02/13(金) 00:09:13

すみません、このスレが2chで一番 COBOLER が多そうなので、質問させていた
だきたいのです。

COBOLの各処理系ごとの互換性はどのぐらいあるものなのでしょうか？

知人の小さな事務所に、COBOLで組まれた古い経理システムがあるのですが、サー
バがマイナーな某社UNIXサーバ(UNIXは独自。CPUがR5000なので、SGIのOEM提供
かもしれない）で、今後の保守も考えて、もっと一般的なx86 サーバに移行し
たいのだそうです。

自分はCOBOLはぜんぜん知らないのですが、Javaなら慣れています。もしCOBOL
の互換性が高いなら、COBOLを勉強しながら、CentOS + Open Cobolあたりに移
植できないかと思うのですが。

0359デフォルトの名無しさん

2009/02/13(金) 07:28:49

とりあえずJavaから見たらCOBOLの互換性はアレだろ。

0360デフォルトの名無しさん

2009/02/13(金) 07:52:39

どこのメーカーのコンパイラ使ってんのかわかんなきゃなんとも言えんが。
画面（オンライン）は間違いなく作り直しだろう。
あと、ＣＯＢＯＬっつーより環境周り（ＪＣＬ）でハマりそうな気もする。

0361358

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ベースの話が多いのも頷けます。

0362358

2009/02/13(金) 12:51:29

UNIXでtelnetのクライアントサーバアプリということだったので、Cみたいに、
パッチを少し当ててリコンパイルすれば、Linux上でも動くかと思ったのですが、
ぜんぜんそんな状況ではないんですねえ。

90年代の後半に、オープン系とか言ってUNIXとCOBOLでのサーバクライアントア
プリのブームがあったようですが、いまの基準ではとてもオープンとは言えな
いなあ。システムを組むときは選択の余地があっても、組み終わってから乗り
換えるのはすごく高コストなんだから。

当時導入されたサーバがそろそろ寿命になっているユーザ企業ってたくさんあ
ると思うんだけど、どうしてるんだろう。安価で高性能なPCサーバが普及して
いるのに、それを横目に、新規では誰も買わない高価なUNIXサーバを買わざる
をえないのかなあ。

とりあえず知人には「自分には無理」と言うことにします。
ありがとうございました。

0363デフォルトの名無しさん

2009/02/13(金) 16:50:17

COBOLのソースって、バージョン管理どうやってんの？
行番号が邪魔でdiffがまともに機能しないような気がするんだけど。
それとも行番号無しでcommitして、
実行前に行番号付け直すフィルタ噛ませるの？

0364デフォルトの名無しさん

2009/02/13(金) 22:56:25

>>363
そうかー、行番号つき言語って、冷静に考えたら当たり前だけど diff が取れ
ないのかー。悪夢だ。書ける気がしない。

0365デフォルトの名無しさん

2009/02/14(土) 17:24:47

コボル上がりのおっサンPGは、修正箇所にやたらコメントを挿入しまくる
そして、1年後コメントまみれの読みにくいソースファイルが出来上がってしまう

0366デフォルトの名無しさん

2009/02/15(日) 06:13:00

＞COBOLのソースって、バージョン管理どうやってんの？

古代言語はそういう高度な事はまずやっていない。

0367デフォルトの名無しさん

2009/02/15(日) 10:33:28

バージョン管理ソフトの導入コストが下がって
一般レベルの開発現場に降りてきたのって、まだ歴史浅いから。
今ヘンテココメントやっていたら馬鹿にしてもいいけど
昔の古いコードに文句を言うのは、それはちとかわいそうな気がする。

0368デフォルトの名無しさん

2009/02/18(水) 00:48:58

Java とか COBOL でプログラム書いてルーター作れるの?

0369デフォルトの名無しさん

2009/02/18(水) 07:12:07

Javaとか使ってる奴らは丸め誤差すら理解してなかったりするから困る。
事務計算で「たかが1円くらい違ってもいいじゃないですか！」なんて言ったりね。

0370デフォルトの名無しさん

2009/02/18(水) 09:36:29

>>369
つ BigDecimal

まあ経理処理をlongで実装したりするタワケモノが時々いるのは同意。
昔の俺とか。すみませんすみません。

つうかBigDecimalに四則演算子が使えるようになってほしかったな。
val1.add(val2) じゃなくて、val1 + val2 と書けるようになってほしかった。
Guy Steele が提案したけど却下されちゃったんだよな。残念。

演算子がオーバーロードされているのがStringだけってのは、Javaの駄目な
ところだと思う。

0371デフォルトの名無しさん

2009/02/18(水) 22:15:49

>>370
> つ BigDecimal
まともな分数の実装があれば biginteger(って言うんだっけ, java 方面？)
あれば必要ないし…

どの時点で丸めるかだけの問題っしょ?

0372デフォルトの名無しさん

2009/02/19(木) 08:24:35

別にCOBOL使っている奴でも丸め誤差気にしてない奴は
全然していないけどな。

演算子のオーバーロード云々はJavaに関しては中途半端な方向性だとは思うけど、
じゃあ、Pythonみたいに　'w' * 10　と書いて 'wwwwwwwwww' と出るのは
いい事なのか？って言われればJavaでソレが実現したらキモい印象しかないし。

つか、漏れの知っている金融系だと誤差が出るから数値は全て整数にしてたのを
見るのとCOBOLerもJavaの事はとやかく言えんと思うが。

0373デフォルトの名無しさん

2009/02/20(金) 16:34:02

COBOLの場合は丸め誤差を気にする必要がないんだと思う。
#つーか２進数程度でも理解不能らしいよ。COBOL上がりの人って。
COBOLには１０進数型っていうｽｸﾞﾚﾓﾉがあって。
こいつは数字１桁を表現するのに１バイトを使うぜいたく品で。
ただ、丸め誤差は固定小数点の１０進数のため問題が起きない。
桁あふれも、２進数のように256,65536,,,,のような数値じゃなくて、1000,100000とか
わかりやすいラインで起きる。利点が多いよねCOBOLって！ｗ
んでもってこの１０進数での数値型が標準らしい。Doubleの丸め誤差みたいな問題は普通おきないんだってさ。
#余談だが太古といえる昔には、数値の扱いの差で科学技術用（２進数）と商用（１０進数）の２種のコンピュータがあって
#古い書籍で商用：COBOL　科学計算：Fortran　ってあるのはその差らしい。あとCOBOL連中が汎用機っていうのは
#M/Fは４０年前は珍しい、２進数も１０進数も・・・科学計算も商用計算もできる汎用的なコンピュータだったからなんだってさ！

0374デフォルトの名無しさん

2009/02/20(金) 17:00:50

＞数字１桁を表現するのに１バイト
それは、ゾーン10進数でしょ？
あと、計算用にパック10進数というのもある。
こちらは、１バイトで2桁（最下位の符号部分以外）

＞２進数程度でも理解不能らしいよ
ごく普通に使ってたよ。"COMP-4"で。
（"COMP-4"の詳しい説明はここでは割愛）

0375デフォルトの名無しさん

2009/02/21(土) 06:19:32

ゾーンやパック１０進数を利点と捕らえるのもある種の自由だと思うけど
その分昔のマシンだと浮動小数点って概念ないのでは。

とりあえず気にする必要はBigDecimal型程度には本来あるはずだが。（ｗ

0376デフォルトの名無しさん

2009/02/21(土) 11:13:34

＞浮動小数点って概念ないのでは。

少しスレ違いになるが、もしCOBOLで対応できない場合は、
サブモジュールとしてアセンブラを使う。
汎用機のマシン語は「一般命令セット」の他に
「浮動少数点命令セット」、「特権命令セット」も用意されている。
「浮動少数点命令セット」は主にFORTRANコンパイラが吐き出すものだが。

その他、COBOLでバイナリ計算をする場合でも、あえてアセンブラを
つかう場合がある。例えばチェックデジットを求める場合などは、
10進演算ではパフォーマンスを食いすぎて極度に処理が遅くなる
場合がある。その場合はCOBOLモジュールからアセンブラサブモジュールを
呼び出し、バイナリ計算をする。ゾーン10進数の左4bitを
ゼロクリアし、ゾーン10進数をいきなりバイナリに変換して計算する。

0377デフォルトの名無しさん

2009/02/21(土) 17:33:17

COBOLには、計算途中の端数処理についての規約が定めてあって、
誤差を気にしていないのではなく、奴らはこの仕様が計算誤差の仕様だと言い張る。
だから、COBOLで計算したものだけが正解で、他の言語で計算したのは間違いという、ひでえ話

COBOLには一応バイナリで計算する機能もあるっぽい
配列の添字やら、件数の勘定やらを10進演算してたら遅くてかなわないし…
とか思ってたら、機能としてはあるけど、あんまり使われていないっぽい

10進演算がそんなに優れているなら、多くの言語が標準の型として持つはずじゃね？
そうじゃないってことは、大して重視されてないってことでしょ

0378デフォルトの名無しさん

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さんに、ここまで言わせるとは。

0379デフォルトの名無しさん

2009/02/22(日) 16:05:21

あるコボラーの１日
ttp://sugiemon.exblog.jp/1668491/

wwwwwww

0380デフォルトの名無しさん

2009/02/23(月) 01:00:21

コボラーに敬意を払いたくなる小説だな

0381デフォルトの名無しさん

2009/02/23(月) 08:20:05

>>378
＞これを超える金融DSLは今のところない

個人的にはCOBOLよりもRPGの方がよっぽど特化していて金融向けに感じるが。
RPGに比べればまだ汎用性高いぞ。（ｗ

言語ヲタと言うか単にメジャーな流行モノをおっかけてるだけの人間の
一コメントとしてはいいんだけど、「すばらしい言語」と思うのは
可哀想な感性の人間だろうなぁ。

それか、仕事でCOBOLを使ったことのない幸せ者

0382デフォルトの名無しさん

2009/02/23(月) 13:38:30

>>377
で？経理処理に10進演算は必要無いって主張なのかな？

0383デフォルトの名無しさん

2009/02/23(月) 14:40:56

つか昔の機械は10進演算のレジスタがCPUにあっただけで、
それに言語がサポートしていた程度の認識だけど。

浮動小数点も同様だろ。

COBOLが優れているとか経理処理に向いているとは別物と言うか
変な人が後付けの理由で主張している様にしか思えん。

0384デフォルトの名無しさん

2009/02/23(月) 15:22:12

>>383
逆に整数が16bitでは困るということもあっただろう。
現実にProlog-KABAは16bitで困ったw

0385デフォルトの名無しさん

2009/02/23(月) 15:42:48

>>384
Prolog-KABAが無限多倍長の整数をサポートしていたら、事務計算の
歴史は変わっていただろうな。坂村健もそんなようなこと言ってたよ。

0386デフォルトの名無しさん

2009/02/23(月) 15:42:50

だからか知らんけど、どっかの銀行の勘定系のシステムの一部は
１００万単位でざっくりと計算していたな。（ｗ

事務や経理計算＝COBOLを神格化してるヴァカなCOBOLerがいるみたいだけど、
現実は言うほど厳密じゃないよな。

漏れも、仕事で過去案件でCOBOLからのリプレースした時に、SQLで計算させたら
結構な誤差が出たんだが、だからと言って過去に戻って集計しなおす事はやらんかったな。

まあ、数字とかを協会に提出した後だったし、昔のシステムとはおおらかなモノなんだろう。

0387デフォルトの名無しさん

2009/02/23(月) 15:50:19

むかし、大昔？、はパネルにランプ表示させて、デバッグを
やってた。ワンステップ進めては、コンパイル時に印刷した
シンボルテーブルを参照してボタンでアドレスいれてその
データを表示とか。
こんな場合は、数値は十進数でないと堪らないよね。

0388デフォルトの名無しさん

2009/02/23(月) 15:55:11

んな事言い出すと、パンチカードでデータを作成・入力していた場合は逆に
なんでもよく感じてくるんだが。（ｗ

0389デフォルトの名無しさん

2009/02/23(月) 16:05:42

>>383
＞つか昔の機械は10進演算のレジスタがCPUにあっただけで、
＞それに言語がサポートしていた程度の認識だけど。

違う。10進演算はあくまで”メモリ上”で行われる。
その10進演算コードをマシン語でみてみればわかる事だが、
オペランドはメモリをアドレッシングする「汎用レジスタ」が
用いられる。ちなみに「特権命令セット」を使う場合は、
「制御レジスタ」が用いられる。「浮動少数点命令セット」を
使う場合には「浮動少数点レジスタ」が使われる。

0390デフォルトの名無しさん

2009/02/23(月) 16:33:40

>>389
スマソ、言い切るのは間違いだな「１０進演算命令セット」が昔のCPUにもあるマシンもある、だな。
漏れの知っているマシンは１０演算のレジスタもあったが。

ちなみにそのマシンには浮動小数点の命令セットもレジスタも存在しなかった。

0391デフォルトの名無しさん

2009/02/23(月) 16:38:15

>>390
＞１０演算のレジスタもあったが。

なるほど。そういう環境もあるのですね。
断言してすいません。
ちなみに当方の環境はIBMのS/390でした。

0392デフォルトの名無しさん

2009/02/23(月) 16:43:08

結論として、みんなでIBMのAS/400を使えば良いと思うのだが。
COBOLもJavaもRPGも動くよ。たしかアセンブラが提供されて
いないと思ったが、それだけが残念。

0393デフォルトの名無しさん

2009/02/23(月) 16:48:19

>>392
Prologが動かなくて残念ｗ

0394デフォルトの名無しさん

2009/02/23(月) 16:51:51

>>393
Javaが動くなら、Java系のPrologは移植できるだろ。

0395デフォルトの名無しさん

2009/02/23(月) 18:19:04

>>392
そおいや、あのマシンはアセンブラはないんだよな。
と言うかあのマシンの設計思想からしてアセンブラは存在しないんだろうけど。

RPGかCをアセンブラと思うしかないな。

0396デフォルトの名無しさん

2009/02/24(火) 00:12:20

結論としては、ACOS6最強？

0397デフォルトの名無しさん

2009/02/24(火) 05:56:44

結論は、ＣＯＢＯＬプログラムを窓から投げ捨てろ

0398デフォルトの名無しさん

2009/02/24(火) 13:34:53

>>392 AS/400 ってまだ作ってたか?

0399デフォルトの名無しさん

2009/02/24(火) 13:59:15

>>398
確か、「ｉシリーズサーバ」？とか名前と変えて
まだあると思ったが。（うろ覚えスマソ）

0400デフォルトの名無しさん

2009/02/24(火) 14:06:05

>>393
メモリー管理が難しいから、汎用機では怖いでしょう。

0401デフォルトの名無しさん

2009/02/25(水) 19:59:36

>>400
IBMがなぜサポートしなかったのか。ちょっと不思議。

0402デフォルトの名無しさん

2009/02/25(水) 23:11:34

>>400
何をアフォなことをorz
一番しっかりしてるのが AS400 -> I series って進んだ系統

つか、 OS 内部がデータベース支援してるってこの系統しかしらんぞ

0403デフォルトの名無しさん

2009/02/26(木) 00:43:07

なんかくだらない話ばっかりだな

0404デフォルトの名無しさん

2009/02/26(木) 07:10:40

だったら、ageんなよ、カス

0405デフォルトの名無しさん

2009/02/26(木) 18:03:23

COBOLをネタにくだらなくない話が出来るならやってほしい

0406デフォルトの名無しさん

2009/02/26(木) 21:57:49

♪コボルる涙～

0407デフォルトの名無しさん

2009/02/26(木) 22:52:38

Javaを6年やって去年からCOBOL仕事をし始めたんだが、、
オープン系からCOBOLはキツイというのが正直な感想。

言語としてはJavaよりかなり簡単だと思うが、
Web系で統合環境に慣れてしまっていて、
全てを１から記述する作業でミスしまくり。。。
検証もデバックも面倒くさすぎて(これもミスしまくり）
軽く自信喪失な今日この頃。

なんか、俺って今まで結構適当に仕事してたんだな・・・と泣けてくる。

JavaからCOBOLで理解に苦しんだ点。
・変数の使い方
・リンケージ

共通域に変数定義して、値を退避→値設定→値を戻す、
こういう使い方って普通なの？？
コーディングしてて本当に怖い。

0408デフォルトの名無しさん

2009/02/26(木) 23:49:59

>>407 だいじょぶだよ
COBOL も Java も OS 書けないから
OS 書けない言語って屑言語だから安心していい

0409デフォルトの名無しさん

2009/02/27(金) 15:41:47

>>408 おいおい　COBOLは何時の時代の言語だよ

0410デフォルトの名無しさん

2009/02/27(金) 20:41:48

>COBOL も Java も OS 書けないから
とりあえず、JavaなOSのマシンはSUNが出してたと思うけどな

0411デフォルトの名無しさん

2009/02/28(土) 03:22:01

そーいえば、COBOLでCADを作ろうとした、社内の優秀なプログラマが挫折して辞めていった。
って話を読んだことがあるな。20年以上前だけどｗ
優秀なプログラマが何故、COBOLでプログラミングしようとしたのかは不明だけど

0412デフォルトの名無しさん

2009/02/28(土) 07:12:23

>>407
>共通域に変数定義して、値を退避→値設定→値を戻す、
>こういう使い方って普通なの？？

関数呼び出しで、スタックフレーム確保して、その中に値をpushするなんて
どの言語も書かないだろ？

そういう用途を超えて共通の機能はどんな言語も取り入れて、
プログラマの負担を軽減した

COBOLを除いて

0413デフォルトの名無しさん

2009/03/03(火) 18:24:59

Javaでちゃんとオブジェクト指向のプログラミングしてるやつって多いの？

0414デフォルトの名無しさん

2009/03/03(火) 19:47:02

>>413
あんまり多くないと思う。

ちゃんとした案件の設計者だったら、きちんとオブジェクト指向設計をしてい
るだろうけど、個々のプログラマはあんまり理解していない。

駄目な案件だと、設計者もプログラマも誰も理解してないことが多い。

参考）
静的オブジェクト指向は設計者が苦労を背負込むシステム
http://blogs.wankuma.com/nagise/archive/2008/05/10/137150.aspx

0415デフォルトの名無しさん

2009/03/14(土) 18:24:39

コボルのＮｅｔＤＢって、どうやって
習得するのでしょうか先輩に聞くしか無いのでしょうか
本とか見当たらなくて
マニュアルは読みにくいし・・・・

0416デフォルトの名無しさん

2009/03/15(日) 11:10:45

ＮｅｔＤＢはお金出して研究所で学ぶのか一般的ですよたぶん
わたしの周りではみんなそういった感じです

0417デフォルトの名無しさん

2009/03/15(日) 11:30:55

>>408 は COBOLer より頭が悪い

0418デフォルトの名無しさん

2009/03/15(日) 11:52:26

>>407　さんみたいな人多いいの？
オープン系からホスト系

0419デフォルトの名無しさん

2009/03/16(月) 13:45:39

JavaとCOBOLの連携なんてよくある。
Javaエンジニアだけど、ちと火を吹いてるからCOBOL側のビジネスロジック見てくれ、COBOL知らなくても見れば分かるから！
とかね。
大概の人は後悔するんだけども。

0420デフォルトの名無しさん

2009/03/17(火) 23:09:49

COBOLはソースだけ見ても
何がなんだかさっぱり分からないもんな。
Javaの記述になれてれば尚のこと。

0421デフォルトの名無しさん

2009/03/18(水) 11:55:55

>>420
おれもCOBOLのソースは可読性最悪だと思うけど、
分からない原因はどことお考えで？

0422デフォルトの名無しさん

2009/03/18(水) 13:04:22

Javaはメソッド名から動作に関して想像できるけど、COBOLなんかはサッパリわからんだろ。
グローバル変数しかないからしょーもないサブルーチンまで全て総ナメでソースを追わないといけないしなー。

COBOLはソースを紙に印刷しておいて、それとは別にメモ用紙とペンを持って、
端末画面でソースを検索して、解析ってノリだし。

あきらかにJavaと言うか開発IDEに慣れた身から苦行の嵐だ罠

0423デフォルトの名無しさん

2009/03/18(水) 23:04:11

>>421
最大の理由は処理単位が大きすぎること。
全体で関数一つ相当とか無理だろ、みたいな。

PERFORMはあるけど、呼び出し先と呼び出し元が独立してないし。

0424デフォルトの名無しさん

2009/03/19(木) 02:00:22

関数ではない。あれは意味のあるひとまとまりの処理。

0425デフォルトの名無しさん

2009/03/19(木) 08:04:46

>>424
言語仕様上関数と同じだろ。
それに意味の単位が大きすぎる。

0426デフォルトの名無しさん

2009/03/19(木) 08:07:08

PERFORMは返却値を扱う機構がないから、関数ではないわな
ただのサブルーチン

0427デフォルトの名無しさん

2009/03/19(木) 14:12:02

おまいらcall知らないの？

0428デフォルトの名無しさん

2009/03/19(木) 20:22:11

こやつめｗ

0429デフォルトの名無しさん

2009/03/19(木) 23:28:33

ＦＵＮＣＴＩＯＮは？

0430デフォルトの名無しさん

2009/03/24(火) 15:36:52

久しぶりにＣＯＢＯＬをやることになった。
Windows系のCOBOL2002だから少しは進歩しているかと思ったら
未だに行番号とかあるし、ＳＱＬ文もＤＢ依存の命令を使おうとしたら
PROCOBOLじゃないとだめだし、デバッガは使いづらいし、もういやだ

0431デフォルトの名無しさん

2009/03/24(火) 15:55:04

>>430
行番号省略できるだろ？

0432デフォルトの名無しさん

2009/03/24(火) 18:18:56

最新の処理系を採用しても最新の機能は使わせて貰えない不思議。
COBOLだってオブジェクトシステムあるんだぜ！

0433デフォルトの名無しさん

2009/03/24(火) 18:55:33

30年前にはPERFORMを多用するって非難されたw

0434デフォルトの名無しさん

2009/03/26(木) 22:47:33

まあ、その辺は、javaでもジェネリックス使うなとか言われるからなあ。
理由は「教育コストがかかるから」とかなんとか。

List<Hoge>とか、そんな教育コスト云々の話か？castのほうが怖くねえか？と思わなくもない。

0435デフォルトの名無しさん

2009/03/27(金) 12:26:32

「こんなの初めて」

0436デフォルトの名無しさん

2009/03/27(金) 14:32:06

>>431
先頭かラム位置からＩＦ　とか書きたいんだＹＯ。
省略可能なら、フリースタイルにしろよってこと。

0437デフォルトの名無しさん

2009/03/28(土) 11:48:43

>>434
その安全性を上司に説明すんのが面倒なんだよな

0438デフォルトの名無しさん

2009/03/28(土) 14:56:38

>>436
フリースタイルは無理だろ

>>437
バグなんかテストで潰すだろ、的な。

0439デフォルトの名無しさん

2009/04/02(木) 14:02:01

>>438
N88BASIC→QUICK BASICとなったような、ドラスチックな変化を望んだのさ。

0440デフォルトの名無しさん

2009/04/07(火) 20:39:52

>>430はえらいなぁ
俺なんてNetDBわからなくて、しんだ

0441デフォルトの名無しさん

2009/04/09(木) 21:14:58

20歳の新社会人ですがCOBOLを使う事になりました。
COBOLの経験は無いですが最後のコボラーになるのも悪く無いかなと思っています。

0442デフォルトの名無しさん

2009/04/09(木) 21:15:45

最後になれるわけないだろ

0443デフォルトの名無しさん

2009/04/09(木) 21:37:18

オンラインプログラムは頭おかしくなるよ

0444デフォルトの名無しさん

2009/04/09(木) 21:49:25

お気の毒に

0445デフォルトの名無しさん

2009/04/09(木) 23:26:17

いくら不景気だからって酷いことする会社もあるもんだな

0446デフォルトの名無しさん

2009/04/12(日) 13:09:08

cobolかあ
もう忘れたｗ
ビット操作やったことあるなあ

0447デフォルトの名無しさん

2009/04/12(日) 17:30:59

>>441
メインフレーム(汎用機)か?
こういう本が出てるので、参考にするといいぞ。高いけど。
メインフレーム実践ハンドブック
ttp://www.ric.co.jp/book/contents/book_823.html

0448デフォルトの名無しさん

2009/04/13(月) 22:07:47

>>447
もう二年早く教えて欲しかった

0449デフォルトの名無しさん

2009/04/15(水) 12:42:17

COBOL生誕 50 周年、しかしまだまだ現役 - スラッシュドット・ジャパン
http://slashdot.jp/developers/article.pl?sid=09/04/14/0019209

0450デフォルトの名無しさん

2009/04/15(水) 15:56:22

COBOLのプログラマは不足してるよ。
平均年齢は50歳前後だからねえ。
稼動しているCOBOL資産はまだまだ膨大だからねえ。
超大型システムのカーネルでCOBOLはまだ現役だよね、
それをJAVAとかＣに置き換えると言っても、
ストリーム型をオボジェクト型に切り替えるのは大変だよ、
そもそもストリーム型をオボジェクト型に変えるメリットもない。
言語を変えてもストリーム型にしかならないよね。
そうするんだろうね。

0451デフォルトの名無しさん

2009/04/15(水) 17:57:01

>>448
出たのが今年なんでな
残念ながら

0452デフォルトの名無しさん

2009/04/15(水) 18:06:41

なんか面白そうだ
うちにはないけどｗ

0453デフォルトの名無しさん

2009/04/15(水) 20:42:04

派遣切りとかされて仕事が無いおっさんに生活保護とか支給せずに
COBOLやらせりゃいいのにな

0454デフォルトの名無しさん

2009/04/15(水) 21:45:40

会社で、今実際に使ってるバッチ処理のCOBOLのソースを見て、
処理してる内容を解析してまとめろって言われた。
数百本ある上に、コメントなしで、意味不明な名前の付け方の変数だらけで、
おまけにGO TO使いまくり。
全然進まない orz

0455デフォルトの名無しさん

2009/04/30(木) 00:34:54

保守

0456デフォルトの名無しさん

2009/04/30(木) 22:13:38

マジで今更ＣＯＢＯＬとかありえねーよ？

企業とかは汎用機をやめたい為にＣＯＢＯＬ使える奴を捜してるんだぜ
汎用機　→　サーバー　が
ＣＯＢＯＬ　→　ＪＡＶＡ，Ｃ
なわけで誰も新規でＣＯＢＯＬを使おうなんて考えてねーよ
このデータ移行作業が糞面倒（コボラーを捜す）な上に超コスト（人件費糞高い）がかかるわけ
だから、そう簡単には実行出来ないしプロジェクト中止したところもたくさんあるんだＹｏ

ぶっちゃけ表向き汎用機動かしっぱなしで
裏でＪＡＶＡ，Ｃ使って新規作成サーバー化プロジェクトやってもおかしくねーよ

つまり、廃れ始めてるし色々な意味でヤバイ言語なんだよＣＯＢＯＬはよ

0457デフォルトの名無しさん

2009/05/01(金) 01:37:59

C#やVBじゃダメですか？
>>456　さん

0458デフォルトの名無しさん

2009/05/01(金) 03:41:09

>>447
この本買ったんだけどさ、メインフレームﾏﾝｾｰな話ばっかで５分で飽きた

メモリ管理やらジョブ管理の仕組みの話されても意味ない
そんなもん今時組み込みＯＳだってやってるっての

問題は、ＯＳとかミドルウェアの上に乗っかるアプリから見て、
アプリが動く環境がどう見えるかだろうに、
そういうところはまるで書かれていない

0459デフォルトの名無しさん

2009/05/01(金) 09:44:45

>>458
業務AP専業コーダ、乙

0460デフォルトの名無しさん

2009/05/01(金) 10:12:54

サーバーサイドでjavaを走らせる奴
うっとおしいので死んでください

0461デフォルトの名無しさん

2009/05/01(金) 17:15:44

>>454
似たような境遇だね
バグか仕様か判別不能な記述が一番困る。。

0462デフォルトの名無しさん

2009/05/01(金) 18:35:18

>>458
そういった本なら、神保町の古本屋行けば腐るほどある。

0463デフォルトの名無しさん

2009/05/02(土) 21:50:50

>>456
廃れ始めて・・・と言われて、もう10年どころでは無いんだが
オープン系しか知らない青二才か？ｗｗｗｗｗ

金融系をはじめ基幹系中枢部門では、ＣＯＢＯＬ以外の選択肢は
存在しない訳だが何か？

ＵＩを重視するとか、安定性を求めないのなら
オープン系が選択肢だろう。

0464デフォルトの名無しさん

2009/05/02(土) 22:12:14

ＣＯＢＯＬは廃れているが需要はあるから言語はなくなることはない
うちの部署ではＣＯＢＯＬを使える人がいないから多少重宝されている

0465デフォルトの名無しさん

2009/05/02(土) 22:13:18

>>459,463
コボラーの発想だな
今ではCOBOLなんて選択肢は、銀行ですらない
COBOLを捨てなかった銀行は、軒並み傾いていて、
オープン系で構築した銀行はすごいコストダウンに成功した

これが現実

0466デフォルトの名無しさん

2009/05/02(土) 22:32:19

これは自社の宣伝乙と言わざるを得ない。
軒並み傾いたとか流石に痛々しいな。

0467デフォルトの名無しさん

2009/05/02(土) 22:56:15

今ふと思ったんだけどCOBOLの浮動小数点計算って10進でやってるんだったよね？
2進だと四捨五入とか切捨てで誤差が出るためだったと思うんだけど、COBOL以外で
10進で計算してくれる言語ってあるのかな？

0468デフォルトの名無しさん

2009/05/02(土) 23:34:41

今時は、わざわざ10進で計算するより、やたら大きく精度を持っておくのが流行らしい。
Javaだと、BigDecimal/BigIntegerのような、任意精度の値を扱うクラスがある。
VBや.NETだと、Decimal型が29桁の有効桁数を保持できる。
ちなみにdoubleの有効桁数は15桁。

0469デフォルトの名無しさん

2009/05/03(日) 00:12:58

浮動小数点の計算をBCDでできないと意味ないし、
整数演算だったらバイナリーの方が計算楽だしね。

0470デフォルトの名無しさん

2009/05/03(日) 00:21:26

>>465
自分の狭い経験＝世間の常識と信じて疑わないアフォって
どこにでも居る罠

以前、某金融系の案件で、ＵＩは、オープン系ながら
それ以外は、UNIX COBOLで構築してたが　何か？
コストダウンしても、安定性が低ければ、意味ない件
え？安定性なんて関係ないシステムなのかｗｗｗｗｗ

0471デフォルトの名無しさん

2009/05/03(日) 02:06:21

ttp://pc11.2ch.net/test/read.cgi/linux/1222291980/
この糞ソフトCOBOLで作られたため、大変悪評だよ。

0472デフォルトの名無しさん

2009/05/03(日) 02:28:02

この糞ソフトJavaで作られたため、大変好評だよ。

0473デフォルトの名無しさん

2009/05/03(日) 04:40:10

某メガバンクも今後の開発ではCOBOLを使いまへーんって方針だしちまったしなあ。

この冷え込み方は、昔っから度々言われていた「COBOLはなくなる論」ってのと
レベルが違うと思うんだ。

0474デフォルトの名無しさん

2009/05/03(日) 05:27:23

>>470
信頼性なんかCOBOLにはない
メインフレームのハードの信頼性でしかない
技術の本質が分からないのが、コボラーだろ

>>473
そして、経営の本質が分からないのもコボラー
COBOLアプリの硬直性は救いようがない経営上のリスクだから

0475デフォルトの名無しさん

2009/05/03(日) 06:13:57

コボルみたいに仕様がきっちり決まってる言語ってAdaくらいしかないんじゃないの？
でもAdaに移行したって聞かないからやっぱCOBOL使ってるのかもな

0476デフォルトの名無しさん

2009/05/03(日) 06:46:26

>>475
仕様がきっちり決まっているのなら、なぜマイグレーションの時に
コンパイラ間の非互換の問題が出るのかｋｗｓｋ

0477デフォルトの名無しさん

2009/05/03(日) 12:03:34

>>474
あー言えば、こう言うで、延々とやってろ　カス。

0478デフォルトの名無しさん

2009/05/03(日) 14:56:51

450 ：デフォルトの名無しさん：2009/04/15(水) 15:56:22
COBOLのプログラマは不足してるよ。
平均年齢は50歳前後だからねえ。
稼動しているCOBOL資産はまだまだ膨大だからねえ。
超大型システムのカーネルでCOBOLはまだ現役だよね、
それをJAVAとかＣに置き換えると言っても、
ストリーム型をオボジェクト型に切り替えるのは大変だよ、
そもそもストリーム型をオボジェクト型に変えるメリットもない。
言語を変えてもストリーム型にしかならないよね。
そうするんだろうね。

0479デフォルトの名無しさん

2009/05/03(日) 15:11:45

COBOLのソース見たけどわけわかんね。
生産性の低さがCOBOLの流行らない理由じゃないの？
俺ならCOBOLなんて速攻で止めてLISPに変えるわな。

0480デフォルトの名無しさん

2009/05/03(日) 22:05:06

俺なら農業に転職したい

0481デフォルトの名無しさん

2009/05/03(日) 22:17:06

COBOLはそんなに悪くない言語と言うかああいうモンだと思うが、
老害が自分の居場所を守るために、アレコレとやっているから、
世代交代しつつある現場の人間が「COBOLなんかヤめようぜ」と
言っているのだろう。

と言うか漏れもその一人だけど、COBOLerはマジでウゼェ。
他者と協調するって事を知らんヤツが多すぎる。

0482デフォルトの名無しさん

2009/05/04(月) 15:09:19

今時COBOLにしがみついてる奴は、云われたことしか出来ない奴。
自発的に学ぶ人間は、いろいろ学んでるし普通にVBくらいは弄れる。

COBOL好きにはCOPY句とかの圧縮記法とかの効率性にしびれた人がいたな。

0483デフォルトの名無しさん

2009/05/04(月) 21:11:33

>>482
あんな抽象化もへったくれもないナイーブなテクニックに、一体何の意味があるのかと

0484デフォルトの名無しさん

2009/05/05(火) 14:51:41

>>482
それでも今時、ＶＢかよｗｗｗｗｗ

0485デフォルトの名無しさん

2009/05/05(火) 15:01:47

VBでいいよ。　つまらない仕事してるもの。

0486デフォルトの名無しさん

2009/05/05(火) 16:01:05

VBもC#みたくyieldとか実装してほしいお

0487デフォルトの名無しさん

2009/05/05(火) 23:29:49

久しぶりにキチンとした在庫のある本屋に行ってみた。
COBOL本の隣にhaskelと、Ocamlがおいてある。
なんか変なのｗｗ

0488デフォルトの名無しさん

2009/05/05(火) 23:57:09

>>487
マイナー言語の棚だろ。SmalltalkもPascalもBasic（N88)も同じ棚だぜ＠神保町三省堂

0489デフォルトの名無しさん

2009/05/06(水) 12:33:24

マイナー言語でプログラムを組むのもなかなかオツなもんですよ

0490デフォルトの名無しさん

2009/05/06(水) 12:38:48

python見つけた頃には、マイナーだったのにこんなに流行っちゃってもうやる気茄子でう。

0491デフォルトの名無しさん

2009/05/06(水) 18:22:58

捻くれてるねぇ

0492デフォルトの名無しさん

2009/05/06(水) 19:21:58

Pythonに関しては（日本で）メジャーになる前に既に無しでは戻れないくらいに
普及してしまった感があるが。

逆にRubyは無くても困らんのだが流行っているな。

0493デフォルトの名無しさん

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分の掲載

0494デフォルトの名無しさん

2009/05/07(木) 14:18:25

Lispの健闘に感心した

0495デフォルトの名無しさん

2009/05/08(金) 00:10:02

COBOL(1207件)
Ruby(769件)

Lisp(33件)

0496デフォルトの名無しさん

2009/05/08(金) 23:43:11

こぼるの案件数とLispの圧倒的抽象力がコラボすれば、今後１００年は安泰ってことか

0497デフォルトの名無しさん

2009/05/09(土) 01:57:07

裏でLispで動いてたゲームソフトもあったなぁ。
ま、COBOLは健在つか、言語とビジネスロジックの過密着が
問題になるくらいベタなやつ。　会計がリアルタイム処理に
完全移行する時代にならんと捨てられることも無いだろう。
帳票扱いも、Cで書いたらエライ手間。

0498デフォルトの名無しさん

2009/05/09(土) 02:43:05

>>497
>帳票扱いも、Cで書いたらエライ手間。

memcpy() とmemcmp() の嵐なんだよね

0499デフォルトの名無しさん

2009/05/09(土) 08:27:45

COBOLの記述方法を基準にしたら、どんな言語で書こうとエライ手間に決まっていると思うが。

と言うか今時の言語だとIDEのアシスト（型チェックとかも）があるから、
cpyやcmpの嵐でもCOBOLほど苦に感じない。

0500デフォルトの名無しさん

2009/05/09(土) 16:56:41

>>499
まあねぇ。　COBOLで覚えた技をどしても使いたいって人は
いるみたいだ。

0501デフォルトの名無しさん

2009/05/10(日) 03:49:58

実際問題、やっぱ事務処理は事務処理用言語の方が生産性高いんじゃね？
WEBアプリもWEBAP特化言語の方が生産性高い、と、スクリプトの人々は言うし。

0502デフォルトの名無しさん

2009/05/10(日) 05:12:24

そりゃそうだろ
例えは悪いがC++のSTLだってタイプした量の10倍以上の
意味を持ってるしコードもその程度肥大化する

要するに一つのワードにどの程度の重さを持たせてるかって
事だよな

Cはその重さが異様に軽いので何をやらせるにも大変

0503デフォルトの名無しさん

2009/05/10(日) 09:18:09

そりゃ、横長ＤＢを全件READして、ひたすらMOVやADD繰り返すだけの
「業務ロジック」をJavaにそのまま移植したら生産性低いだろ。

普通にデータはSQLで読み書き計算し、UIの部分をJavaなんかの言語で処理すれば
現代ではもっとも効率がいいだろう。

ただ昔の人って基本設計がド素人なのが多いので画面入出力・入力チェック・データの読み書き・
業務ロジックがグダグダに構成されていて移植困難だから「COBOLは今でも健在」とか
言われてるだけだろうなぁ。

んなん、設計段階からリニューアルする事がゆるされるならCOBOLのみとJava+SQLと
どっちが生産性高いか？きかれりゃ、間違いなく後者の方が生産性高いし。

0504デフォルトの名無しさん

2009/05/10(日) 10:25:13

固定長でBCDを使ったデータセットの使用が所与の条件だったら、
COBOL以外の選択肢は考えられんな。

0505デフォルトの名無しさん

2009/05/10(日) 11:58:51

戦闘機と旅客機の違い、
５０ｃｃチョイ乗りと４０ｔフルトレーラ、
漁船とマンモスタンカー、豪華客船

そんなとこかね。

0506デフォルトの名無しさん

2009/05/10(日) 12:00:46

>>504
FORTRAN、PL/1でも使えますが。
PL/1 を知ってるだけで、使ったことが無い。

0507デフォルトの名無しさん

2009/05/10(日) 14:54:48

コボラーの言う生産性って、コード行数の生産性でしょ？

コボラーのおかげで、ビジネスの生産性は落ちっぱなし

0508デフォルトの名無しさん

2009/05/10(日) 22:16:10

>>504
DB2/400とかはCOBOL以外にRPG,C,C++,Javaで使えたけど。
COBOLerの心のよりどころがソレってのも悲しいよな。

0509デフォルトの名無しさん

2009/05/12(火) 22:16:53

>>507
コード行数の生産性の話とおもいきや、ビジネスの生産性とはどういう事？

仮にCOBOLなら月10,000行の生産程度で作れる処理とする。
Javaだとコーディング量で測れない作業があり、2ヶ月や3ヶ月掛けないと作れない。
しかし、コボラー達が1ヶ月でシステム収めやがるから、Javaでは単価辺りの原価率が上がらないって事？

0510デフォルトの名無しさん

2009/05/13(水) 06:43:38

単にコボラーは「俺5000行のプログラム作っちゃった。俺SUGEEEE」ってアフォが多いだけだろ。

OOな設計は稀にしても、便利なクラスを作ったりして再利用性を高めたり、
便利なクラスの使い方を見つけてなるたけ、コード記述量を減らして品質とか生産性
あげる努力をしている。

つかコーティング量で測れない部分があるのはCOBOLも一緒だと思うが、
ソース管理やテスト系なんかはむしろJavaの方が遥かに進んでいるし。

0511デフォルトの名無しさん

2009/05/13(水) 18:06:55

>>507
COBOLの頃はFP法全盛だから、行数ではなく、機能数。

0512デフォルトの名無しさん

2009/05/13(水) 22:50:34

>FP法全盛

一時期流行ったけどマッハで廃れていったな。

0513デフォルトの名無しさん

2009/05/13(水) 22:56:37

クラス化うんぬん資源の再利用は、形態や手法は違えどCOBOL以外の言語もあたりまえに行うべき工程
それを鼻息荒くJavaの優位性として語るポイントとしては弱いとお思うんだが。

それにしても >>510 の関わっているプロジェクトは、JavaにしろCOBOLにしろ、これから船出感が有って面白そうだなあ。

0514デフォルトの名無しさん

2009/05/13(水) 23:02:11

とりあえずCOBOLerにはリファクタリングって概念ないと思うけど。

再利用と言うかコピー新規で内容が数行しか違わないサブルーチンが５・６個ありますが、なにか？
って感じだったなぁ。

営業日算出SUBとかで、「これが銀行用」「これが会社用」「これが普通のカレンダー用」で
○○年までVer、○○年までVerてな感じで･･･。

アフォかと。

0515デフォルトの名無しさん

2009/05/14(木) 06:37:57

実際に走ってるコードとソースは別というのを知らん野か。

0516デフォルトの名無しさん

2009/05/14(木) 06:41:20

>>510
論理設計さえしっかりしとけば構造化プログラミングだけでバグ数0でやれるのがCOBOL。
正体不明のバグだして右往左往するJavaとは違うのだよ。

0517デフォルトの名無しさん

2009/05/14(木) 07:31:43

>論理設計さえしっかりしとけば構造化プログラミングだけでバグ数0でやれるのがCOBOL。

そんな理想郷は見たことありません。

紙に手書きされたフローがあって、グダグダに修正されたプログラムを見せられて
バグ山盛りのCOBOLのプログラムをやまほど見たけど。

で、アベンドしたら「想定外の使い方です。これは仕様です。文句があるなら金払え」
ってノリです。

0518デフォルトの名無しさん

2009/05/14(木) 23:03:37

とりあえず、JAVAやってるひとは
業務ロジックはCOBOLで動いて、UIだけJAVAなんて仕事はしない方がいい。
腕がおちる。

0519デフォルトの名無しさん

2009/05/14(木) 23:13:44

業務を全部Cで書けばいい
頭がよくなるぞ
バグてんこ盛りだけど＼(^o^)／

0520デフォルトの名無しさん

2009/05/14(木) 23:23:24

理想郷に辿りつきました。

紙にすら書かれていない隠しクラスやメソッドがあって、行き当たりバッタリで作られたプログラムを見せられて
スパゲッティー化されたバグ満載のJavaプログラムがやまほど。

で、つい数年前導入したばかりというのに、ブラウザーやOS、Javaのメジャー、マイナーバージョンアップが有るたび
「動作保障外の環境です。これは仕様です。文句があるなら金払え」ってノリです。

難問を解決するだけで当分は飯が食えるとは、もうこの上ないシアワセです。

0521デフォルトの名無しさん

2009/05/15(金) 00:06:07

JavaでスパゲティなんてCOBOLのソレに比べたら屁みたいなモンだから
素直に羨ましいな。

0522デフォルトの名無しさん

2009/05/15(金) 00:11:10

Javaは一応ALGOL系だからスパゲッティに書く事が
そもそも困難な言語

0523デフォルトの名無しさん

2009/05/15(金) 00:30:37

COBOLのCOPY文がウザイんですが。
パッと見てどの項目使って処理してるかさっぱりわからん。
まあコンパイルリストに全部出てくるけど。

0524デフォルトの名無しさん

2009/05/15(金) 01:28:05

仕様書無しの場合、ヘボいOOのソースの読み難さは、ヘボい構造化の比では無い罠

0525デフォルトの名無しさん

2009/05/15(金) 01:31:11

そのヘボさを補うツール群があるわけだが、今時は … … …

0526デフォルトの名無しさん

2009/05/15(金) 01:35:01

ALGOL系ちゅうのは頭にあったが、そうか、そうなのか。(´･ω･`)ショボーン

COBOLはもうそろそろ１年になるが、かなり入り組んだソースも、へえそなのかぁ、こうしたいから
こう処理しようと・・・。
じゃあこの辺りで、要件を確定する計算必要じゃねえ？と、いった具合に、設計者が何をやらせようか、
思想が読み取りやすく思ってしまった。
何というのか、派手さはないが、実行環境も含め結構安定感を感じると言っていいのか・・・。

バッチ処理の処理手法としては、一度に100万件、200万件を一括処理する手法は、参考になる部分も
多くCOBOLは結構俺の肌には合ったようだった。

Javaの方といえば、絶対プログラム全体のイメージを固めずに、動かしながらその都度ソース書いてるぞ！
こんなのソース納品されても見たかねえよ！とか、プログラマー毎の癖を覚えたり、矯正するのが疲れて
来ているようだ。

その反面、酷いシステム屋だと設計書と中身が違っていて、いきあたりバッタリ開発された物だと、
気分的にとても追えた物じゃ無いが、障害発生率も高く、仕事が途切れず発生するので結構美味しいと思う自分が要る。

0527デフォルトの名無しさん

2009/05/15(金) 06:43:28

いきあたりばったりは言語関係ない。
無能なドカタがつくるとドレも似たようなモノ。

バッチ処理の手法云々も、あの方法しか出来ないので参考もなにもないけどナ。
ほぼ全ての言語でああいった一括処理の手法が普通に出来る。

0528デフォルトの名無しさん

2009/05/21(木) 01:20:19

agepan

0529デフォルトの名無しさん

2009/05/21(木) 01:25:36

COBOL初心者です。
IBMや富士通ではVSAM、ISAMを使ってデータを格納してる場合が多いですよね。
DB2やORACLEを実装した場合、SQLでそれらのデータセットをガチでアクセスできますか？

0530デフォルトの名無しさん

2009/05/21(木) 03:51:38

普通にできます。

0531デフォルトの名無しさん

2009/05/27(水) 01:42:19

agetoku

0532デフォルトの名無しさん

2009/05/31(日) 11:35:19

age

0533デフォルトの名無しさん

2009/06/13(土) 21:20:10

一応アゲ

0534デフォルトの名無しさん

2009/06/14(日) 04:49:22

索引純編成ファイルって、まだあるんだねえ
懐かしいねえ。

0535デフォルトの名無しさん

2009/06/18(木) 16:57:15

COBOLの良い所は、レコードとファイルを結び付ける事が簡単なことじゃないかな。

COBOLは使ったことないけど。

Java は何でも出来るけど、
何やるにしても面倒になりがちな気がする。

Javaは使ってるよ。

0536デフォルトの名無しさん

2009/06/18(木) 23:02:27

>COBOLの良い所は、レコードとファイルを結び付ける事が簡単なことじゃないかな。

awkの方が簡単じゃね？

レコードにカラムが100個くらい並んでいるクソ設計ならCOBOLが楽だろうけど。

0537デフォルトの名無しさん

2009/06/19(金) 22:10:42

javaが「何でも出来る」と感じるほど使い物にならんってことか

0538デフォルトの名無しさん

2009/06/19(金) 22:22:55

Javaを知らないCOBOLerの曲解が正直キモい

0539デフォルトの名無しさん

2009/06/19(金) 22:54:09

DSLが汎用言語より簡単なのは当たり前だよな。

0540デフォルトの名無しさん

2009/06/20(土) 01:16:35

>>539
まあ、そうだね。

COBOL は、その出生から、確かにビジネス(事務)向けの DSL だね。

事務的な処理をするソフトウェアを効率よく、
しかも、設計書のように整った形に書ける。

それが、 COBOL の思想だったはずだし、
事務的な処理がこの世からなくならない限りは、
その存在意義は残るだろうね。

それに、何より、これまでの蓄積があるからね。
それは、 FORTRAN と同じだね。

Java は、本来、家電向けのアプリを作るための言語だった。
今も、携帯関係に強いし、セットトップボックス(テレビにつなげる奴)用の
Java開発環境もあるらしい。

ところが、ワークステーション屋サーバー屋の Sun が作ってたから、
ビジネス方面に使いたかったろうし、使えると見て、
そちら方面に力を入れたんだろう。
言語設計自体は、洗練された汎用言語の物だったし、
だから、当然の如くビジネスにも使えた。

言語設計は、どうしても後発の Java の方がきれいで、
多方面にそれなりに使いやすくなっている。
ただ、 COBOL は事務専用言語として汎用言語には無い強みがあるはず。
それ以上でも、それ以下でもないな。

0541デフォルトの名無しさん

2009/06/20(土) 01:56:03

>>540
結局何も言ってないのと同じだね

0542デフォルトの名無しさん

2009/06/20(土) 06:09:19

昔は計算機が貴重だったから、すべてを計算機に合わせるというやり方もありだった。

事務処理をするなら、今はビジネスに合わせる方が、合理的。
COBOLは計算機側の効率を考えて、データを格納するように設計されたが、
それはビジネスの観点とは異なる。

COBOLはもはや事務処理言語として落第点。
COBOLで書いた今までのアプリは不良資産となってしまった。

0543デフォルトの名無しさん

2009/06/20(土) 06:24:27

COBOLはよく「事務処理に向いている」とか言うけど
現実には「事務処理にしか使えないが、その事務処理ですら
他の言語よりも使いにくい」と言う結論だけど。

「COBOLでなきゃ出来ない」とか「COBOLが一番効率的」ってケースは存在しない。

0544デフォルトの名無しさん

2009/06/20(土) 13:00:51

おまいら javaってそんなに事務処理のプログラム開発に使われてんの？
処理遅いしメモリー食いまくりで大規模なプログラム開発に向いてないように思うんだけどな。

0545デフォルトの名無しさん

2009/06/20(土) 13:50:34

Javaでできる、と言う奴は居るが、実際に組ませると5年で1円も誤差が出るような
プログラムを書いてくるんだが。

0546デフォルトの名無しさん

2009/06/20(土) 15:04:35

COBOL→メモリ食わない
COBOL→誤差出ない

こういう短絡思考が痛すぎる

0547デフォルトの名無しさん

2009/06/20(土) 15:04:36

COBOL→メモリ食わない
COBOL→誤差出ない

こういう短絡思考が痛すぎる

0548デフォルトの名無しさん

2009/06/20(土) 15:55:03

BCD演算すればよかろうがカス

0549デフォルトの名無しさん

2009/06/20(土) 16:06:03

BCDパッケージの信頼性を誰が保証してくれるかの問題が出てくるよ

0550デフォルトの名無しさん

2009/06/20(土) 16:44:43

COBOLのパッケージは誰が保証してるんだよ

0551デフォルトの名無しさん

2009/06/20(土) 16:55:17

COBOLはCSVファイル扱うのが、非常にめんどうだった。

昔、CSVファイルで出力する要件があったときに、
すごくメンバーの作ったプログラムの品質が悪かったんだよね。

0552デフォルトの名無しさん

2009/06/20(土) 18:53:05

COBOLは厳しい基準をパスしなければCOBOLを名乗れないんじゃなかったっけ？

javaは一応利権がらみでグダグダ言う所はあるけど、
演算精度や処理結果にグダグダ言う奴はいないだろ？

0553デフォルトの名無しさん

2009/06/20(土) 19:33:03

＞BCDパッケージの信頼性を誰が保証してくれるかの問題が出てくるよ

IBMのJDKでも使ってサポート契約結べば保障してくれるけど。
つか商用鯖で動かすOSやミドルウェアはベンダーがサポートしてるけど。

COBOLがメモリ食わなくて計算誤差でない、なんて幻想だな。
COBOLでもメモリ食いなプログラムはあるし、誤差が発生する。

＞COBOLは厳しい基準をパスしなければCOBOLを名乗れないんじゃなかったっけ？

厳しいもゆるいもCOBOL-88だったら満たすか満たさないかだけだろ。

そもそも事務処理特化言語のおかげで各処理系に依存している部分が多いし、
画面遷移とかはバラバラだし。

１０進演算とかの演算処理も処理系依存の部分があるので、そういった面では
Javaの方がキッチリしている。と言うかJavaDocのAPIとか読んでいると
くどいくらいに使用法に関して注意書きしているだろうに。

0554デフォルトの名無しさん

2009/06/20(土) 21:23:00

要するに、

>Javaでできる、と言う奴は居るが、実際に組ませると5年で1円も誤差が出るような
>プログラムを書いてくるんだが。

というのは嘘だな。

COBOLでも数円単位の誤差を出す馬鹿はいるし、Javaでも正確なプログラムを
書いてくる奴はいる。

要するに言語ではなくプログラマーの腕次第というわけだ。

0555デフォルトの名無しさん

2009/06/20(土) 22:19:27

どんなにJava厨が必死になろうともプログラマの質の低さはごまかせない。
8割はBCD演算がどうとか全く意識せずにlong型を使う。

0556デフォルトの名無しさん

2009/06/20(土) 22:29:01

>>555
そりゃチュブに下請けに出す位だからな（笑）

0557デフォルトの名無しさん

2009/06/20(土) 23:01:52

計算を全て整数でやっていた日本人のCOBOLerを知っている身としてはコメントが難しいな。

つか金融系の仕事していてlong使うヤツなんかいるのか？
2chの見過ぎだと思うが。

実在するならその会社名を晒してみろよ。ｗ

0558デフォルトの名無しさん

2009/06/21(日) 00:21:01

浮動小数点の演算で誤差がでないアルゴリズムなんて不可能だろ。
COBOLの場合はその誤差が規定されてるんじゃなかったっけ？

0559デフォルトの名無しさん

2009/06/21(日) 00:39:37

丸めの話が混じると一気にカオスになる。
計算途中で丸め処理が入ったりすることも結構あるからな。

0560デフォルトの名無しさん

2009/06/21(日) 07:02:06

＞COBOLの場合はその誤差が規定されてるんじゃなかったっけ？

誤差を仕様と言い切るか、少数点以下第４位まで四捨五入やら切り捨てと
プログラム仕様にて決めて、後はその範囲内でシコシコと計算するだけ。

ここで、>>559の言う様に「このプログラムでは切り捨て」とか「このプログラムでは
四捨五入」とかきて、酷いときは「このプログラムは少数点以下第２位で算出」とか
あるので、現実問題COBOLで1円単位の誤差なんて日常茶飯事だ。

金融系だと「営業店ブロックの残高を合計してから平残」と「支店毎の平残を算出
してからブロック毎の平均」とかやればどんな言語だろうが、誤差は出る。

誤差が出るのは仕方ないが、そういうのを仮にSQLでDecimal型を使いつつ
プルーフしていくと、大抵COBOLで設計されているシステムの誤差の大きさには
感動を覚える。ｗ

いや、COBOLerに言わせれば仕様なんだろうし、それは仕方ないとこっちも思うが、
そんなCOBOLerが声だかに演算精度を自慢しているとなんだかな？ってのはある。

0561デフォルトの名無しさん

2009/06/21(日) 08:50:13

>>557
>つか金融系の仕事していてlong使うヤツなんかいるのか？

いるよ。JavaじゃなくてVB.NETだったからdoubleだけど。
初めて聞いたときはひっくり返ったわ。

ちなみに名前は出せん。

0562デフォルトの名無しさん

2009/06/21(日) 11:28:44

おまいらもうちょっと勉強してから言えよ

COBOLは式の計算途中の端数処理が言語仕様で決まっているんだ
普通の言語は、そういう細かいところは、実装者に任せるんだけど
コボラの言ってる誤差云々は、こういう意味。
コボラはCOBOLしか知らないから、他の言語とどこが違うか説明できないんだよ。

COBOLって四捨五入は言語機能としてあるけど、
切上げは未だに +0.9 してとかマジックナンバーでやらないといけない変な言語だ
端数端数ってうるさいくせに
負の数の端数処理なんか、考えたこともないんだろう、コボラは

0563デフォルトの名無しさん

2009/06/21(日) 11:49:01

一応、サンプル出しておくと

z = a/b + c/d

とかがすべてのコンパイラで同じ結果になるように言語仕様が決まっているってこと

随分くだらないことに拘っているんだな、という貴方は正常
これはすべて井の中の蛙が為せる業

0564デフォルトの名無しさん

2009/06/21(日) 20:09:51

＞いるよ。JavaじゃなくてVB.NETだったからdoubleだけど。

Javaじゃねーし。
COBOLerの難癖も大概にしとけよ。

しかも名前出せないんじゃ脳内妄想と言われても仕方ない。

0565デフォルトの名無しさん

2009/06/21(日) 21:45:36

でも、JavaにしろCにしろ、海外のサンプル見てると通貨をdoubleであらわしている例が多いね。
てか、ほとんどがdoubleか。

まぁ、奴ら補助単位があるからdoubleなんだろうけど、見るたびに違和感を感じてしまう。
そういうの読んで言語覚えただけで、まともな教育を受けてないとしたら、doubleで実装してしまう
奴も居るのかも知れんなぁとは思う。

でも、それって言語の問題ではないわな。

0566デフォルトの名無しさん

2009/06/21(日) 22:32:52

doubleは整数の範囲では誤差が出ないし有効桁数が
16桁保証されているから使われるんでしょうね

C++ならBCD型をユーザ定義して使ったり初めからメーカー側
で用意してくれている事もありますが

0567デフォルトの名無しさん

2009/06/21(日) 22:50:58

うちはJavaしかやってないが、コーディング規約でfloat/doubleは使用禁止。
BigDecimal使え、ということにしている。

0568デフォルトの名無しさん

2009/06/21(日) 23:23:40

BigDecimal見てみたら、powerはあるけどlogがないね。
金融でも使いそうな気がするんだけど。
あるいは、そういう分野はFortranの出番か？

0569デフォルトの名無しさん

2009/06/22(月) 00:08:38

漏れはスパコン使ったことないのだが計算最速伝説はFortranなのか。

0570デフォルトの名無しさん

2009/06/22(月) 00:12:08

>>569
いやC/C++でもそのコンパイラがrestrictあるいは__restrictを
サポートしていたらFortranと変わらない

問題はポインタの範囲が重なるエイリアス問題があって最適化
が効かないので一般的にはFortranの方が速いとされているんだ

でもrestrictはそれを承知でいいから最適化してくれというコンパイラ
への指示なのでこれが使えるとFortranのアドバンテージはなくなる

0571デフォルトの名無しさん

2009/06/23(火) 10:12:16

俺はfortranが速いのはベクトル計算に特化した最適化が可能だからと聞いたけどなぁ。
それと後ライブラリーの質かな。
でもそんなのはベクトルプロセッサーを持ってないパソコンだと意味無いし
うちのパソコンに入ってるCとfortranのコンパイラを見る限り
そんなに差はないよ。

0572デフォルトの名無しさん

2009/06/23(火) 10:26:51

今はCコンパイラの質の向上に特に力が入れられているから
実質上差はなくなってきてるよ

CodeGearとかのコンパイラは別として、M$とかIntel製のCコンパイラが
吐くバイナリは元のソースの見当が付かない位に最適化される

0573デフォルトの名無しさん

2009/06/23(火) 10:33:19

>>572 スパコン上のコンパイラの話じゃなかったのか？

0574デフォルトの名無しさん

2009/06/23(火) 12:11:32

COBOLの言語仕様でできないこと
1行改行して終了

0575デフォルトの名無しさん

2009/06/23(火) 20:56:07

時々思うことですが、
新人にオブジェクト指向的な言語を習得させるのは
言語もさることながら、フレームワークなど、個人が知識および知恵を蓄積する必要があり、
まともに使えるようになるのに時間が掛るんです。
使いこなせるようになった人の場合は生産性が飛躍的に伸びる傾向があるというところでしょうか。

初期の段階での習得のしやすさでは生産性はCOBOLやRPGだと思いますが、
あくまでも使いこなせる人と比較した場合はどこかの時点で逆転するんでしょうね。

汎用機およびメインフレームのターミナル、ファイル、プリンタなど限定されたの
機能および安定度によるところが大きいのではないでしょうか

0576デフォルトの名無しさん

2009/06/23(火) 21:22:10

>>575
もうメインフレームみたいな硬直したハードじゃビジネスが成立しないからな
今時汎用機なんて言ったら笑われるで

0577デフォルトの名無しさん

2009/06/23(火) 21:45:47

>>576
社会基盤として最重要で、なおかつ汎用機ではないと実現できないものとか
そういう新しいニーズがないと先細る一方なんでしょう。
大抵はPCサーバで十分ですからね。

0578デフォルトの名無しさん

2009/06/23(火) 22:48:22

>>575の考えるマトモの領域がドコにあるのか知らないけど、
JavaとRPGを対象として単純なCRUDなアプリを組むだけならRPGの方が生産性は上だろう。

が、RPGとPythonとか比較するとPythonの方が圧倒的に生産性は上だし習得も容易だ。

でも、Pythonはメモリ食いだしスピードもRPGと比べるまでも無いノリだから
単純な比較は意味ないな。今はPCサーバの性能向上で気にならないレベルではあるが。

個人的にはオブジェクト指向言語だからと言って企業は盲目的に新人教育言語としてJava
教えるのはヤめて、PythonとSQLさえ教えておいて欲しい。

＞使いこなせるようになった人の場合は生産性が飛躍的に伸びる傾向があるというところでしょうか。

正直、そのレベルに到達できる人は少ないと感じるが。
オブジェクト指向云々よりもな正規表現やらSQLのクエリをスラスラ書ける方が
現場で役に立つからなぁ。

COBOLerがログから必死で検索したり、印刷したダンプを目を細めながら追いかけているのは
現代においてはマヌケだし。

0579デフォルトの名無しさん

2009/06/23(火) 23:32:22

要約するとCOBOL VS Javaスレですが、下記のレイヤーに分かれるんでしょうか。
HW層メーカー固有ハードウエア VS オープン系ハードウエア
OS層　メーカー固有OS VS オープン系OS
DB層横長テーブル VS 正規化されたDB
Language層手続き型言語 VS オブジェクト指向
その他帳票（とくに複写で大量印刷）

＞オブジェクト指向云々よりもな正規表現やらSQLのクエリをスラスラ書ける方が
正規表現やSQLは必須ですね。

＞COBOLerがログから必死で検索したり、印刷したダンプを目を細めながら追いかけているのは
＞現代においてはマヌケだし。
そうですね。もう少し理論的な仕事のやり方が良いと思います。

0580デフォルトの名無しさん

2009/06/23(火) 23:43:32

>＞オブジェクト指向云々よりもな正規表現やらSQLのクエリをスラスラ書ける方が
>正規表現やSQLは必須ですね。

入力文字列の妥当性チェックを正規表現で実装したら
「他の担当者がメンテできないような物を使うな」って叱られた事があるな。
if文と文字列操作関数で実装するのが当然だとかで。

0581デフォルトの名無しさん

2009/06/23(火) 23:49:11

短期的に現場で役立たせるためには、OOPLより必要なものは多いね。
でも、そればっかりやらせてると、次代の人材が育たない。

あと、SQLは大事だと思うけど、SQLのテクニック的な部分だけやってもしょうがないと思う。
DB設計が出来る用にまでなって欲しい。これがきちんとできる人は、OOにも対応しやすいと思う。

0582デフォルトの名無しさん

2009/06/23(火) 23:50:48

>>580
「正規表現を使えないような技術者なんて居ませんよ。」
しれっと、言ってやれ。

後のことは知らんが、そんな所にいつまでも居ないほうが良いだろ。

0583デフォルトの名無しさん

2009/06/24(水) 00:03:34

Javaもエキスパートになればなるほど、他人から理解されにくいノリがあるけど。

病気みたいにinterfaceを強制されたり、意味あるのか胡散臭い継承使えとかな、
ゲームプログラムみたいな分野ではあの手の設計は意味あるとは感じるが、
事務処理だと、関係なくねーか？って規約があったりなかったり。

DB設計は言語も出来て当たり前だけど、OOのフレームワークに引っ張られすぎない様に
バランス感覚が必要なのはあるな。
COBOLerの横長は酷いけど、なんでもサロゲートキーやらAutoNumberもアレなので。

0584デフォルトの名無しさん

2009/06/24(水) 00:05:12

>>580
>入力文字列の妥当性チェックを正規表現で実装したら
>「他の担当者がメンテできないような物を使うな」って叱られた事があるな。
>if文と文字列操作関数で実装するのが当然だとかで。
それをしたくないための正規表現なんですけど。そういうの聞くとちょっと寂しいですなｗ

>>581
>DB設計が出来る用にまでなって欲しい。これがきちんとできる人は、OOにも対応しやすいと思う。
これは難しいところですよね。DB設計って想像力ある人のほうが上手にできますよね

0585デフォルトの名無しさん

2009/06/24(水) 00:48:56

・メソッド内で使う変数はすべてメソッドの先頭で宣言すること
・変数宣言と同時に代入は行わず、宣言部に続けて初期化部を設け、そこで行うこと（定数除く）
・変数には型を表す接頭辞をつける事
・例外エラーはすべてメソッド内で処理すること
・Mapはメモリを消費するので極力使わないこと

Javaの規約で結構お目にかかるんだけど、妙な習慣やら用語やら・・・
これが文化交流ってやつか

0586デフォルトの名無しさん

2009/06/24(水) 02:34:26

言語の機能だけを見たら、 COBOL と Java の差は小さくなって来てるように思うけど……

0587デフォルトの名無しさん

2009/06/24(水) 03:37:32

>>580 >>582 >>584
正規表現の問題点を本気で考えたこともないんだな。

0588デフォルトの名無しさん

2009/06/24(水) 06:33:28

その問題点を挙げてみろよ

0589デフォルトの名無しさん

2009/06/24(水) 14:52:56

>>585
生産性を下げることにより工数を膨らませようという方針だね。
さらに、保守性の低下による継続的な収入も見込める。
いいお客さんに恵まれているな。

0590デフォルトの名無しさん

2009/06/24(水) 15:22:02

少々おかしくても決まったことは従わないと。
勝手にやっていい立場になれないなら

0591デフォルトの名無しさん

2009/06/24(水) 15:26:13

>>585
＞変数には型を表す接頭辞をつける事
いまどき印刷してコードを確認しないのに、この発想がわからない。
型情報はIDEの表示で良いのに・・・

>>589
無駄に工数を増やすことで、本来無い利益を得ているなら、
顧客の利益を損ねているということですね。

せっかくのオブジェクト指向なのですから、
ユニットテスト100%,コードカバレッジ100%,ビルドの自動化,配布の自動化とか
現代の技術でも完璧にできるとは言えませんが、システムの安定稼働のためのテストなどそっちの方面で頑張って欲しいものです。

0592デフォルトの名無しさん

2009/06/24(水) 15:36:05

なんでこんなマイナー言語同士で戦ってるの？
今からこのスレはIronRuby vs. JRubyにしようぜ

0593デフォルトの名無しさん

2009/06/24(水) 19:17:25

>>591
重箱の隅をつつくようで申し訳ないがコードカバレッジ100%なんて現実的に不可能

0594デフォルトの名無しさん

2009/06/24(水) 19:25:44

>>587
OK、君の意見を聞こうか

0595デフォルトの名無しさん

2009/06/24(水) 21:14:39

>>593
C0なら…やっぱ無理か。

カバレッジを指標にするなら、カバレッジを達成できない理由を分析できるスキルが必要だと思うが、
そもそも、数値を指標としたがる組織の殆どが、内容についての分析が出来ない組織なんだよなぁ。

0596デフォルトの名無しさん

2009/06/24(水) 22:13:51

メソッドを検証するためのユニットテストは複数あってしかるべきと思うし、
100％に満たない場合の対象メソッドは、ロジックを見直す又はクラス構造を変更するなりして満たすようにするべき。
満たないケースはやはり理由を明確にしておくというのが望ましいのでしょうか。
かといってユニットテストを有効に適用できない部分もあるので、まだまだ発展途上ではあります。

個人的には現行のツールで複合的にカバー率がUPしてしまうというのも問題あるんじゃない？と思いますがこの辺を管理するのは難しい。
ソフトウエアの変更による影響範囲を自動で確認できるのは最高のメリットなので有効活用するべきです。

よってユニットテストができない言語はダメだと結論となります。

0597デフォルトの名無しさん

2009/06/24(水) 22:19:26

言語の問題ではないと思うがね。どんな言語でもやり方はあるもんだ。

0598デフォルトの名無しさん

2009/06/24(水) 22:42:29

言語の問題ではないのは事実だが、実際の効率やノウハウを言い出すと
COBOLよりかはJavaの方がマシだ罠。

ただ、これは言語云々よりも人間の問題だと感じるけど。
COBOLでも前に利用したテストデータを再利用やら、そういう工夫をしている人はしているし、
酷いのだと「机上で影響がないのを確認しました」といってテストを省くヤツもいる。

0599デフォルトの名無しさん

2009/06/24(水) 23:11:28

よし、オブジェクティブCOBOLの出番だ

0600デフォルトの名無しさん

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 預け入れ(){
　　　:
　　}
}

0601デフォルトの名無しさん

2009/06/25(木) 20:56:07

今まで書いた不良資産をCOBOL2002を使ってオブジェクト指向で書き直すか？
書き直さないと、オブジェクト指向の御利益ない。
だがそんなことするくらいなら、COBOL捨てて他の言語に移行するだろうな

で、正規表現の件はどうなった？

0602デフォルトの名無しさん

2009/06/25(木) 22:00:45

>>600
コボルってこんな長いのかw

0603デフォルトの名無しさん

2009/06/26(金) 00:35:22

正規表現がこのスレに関係あるのか？

プログラマーが正規表現の事を分からないというのなら、
そのプログラマーに正規表現の事を調べさせればいい。

正規表現のライブラリが信頼できないというなら、
どうしてコンパイラやそのランタイムライブラリが信頼できるというのか。

正規表現の問題って何だ？

正規表現の話は、スレ違いだ。もう終わりにしよう。

0604デフォルトの名無しさん

2009/06/26(金) 00:45:23

正規表現の問題は、>>587が答えないから引きずってるわけですが、
く憶測すると、正規表現に問題があるというヤシは正規表現を理解していない、
もしくは理解したくないという人が多い場合に問題になるということではないのかね？
Javaオンリーなら別に互換性の問題は出ないし、そこしかありえない。

0605デフォルトの名無しさん

2009/06/26(金) 01:18:33

もし、正規表現の問題というのが >>604 の憶測の通りなら、
プロジェクトマネジメントの問題であって、正規表現の問題ではないだろう。

0606デフォルトの名無しさん

2009/06/26(金) 01:23:45

0607デフォルトの名無しさん

2009/06/26(金) 01:36:18

COBOLって構文の単語がやたら長いな。
C++マンセーな俺にはCOBOLは無理かもしれん。

0608デフォルトの名無しさん

2009/06/26(金) 01:48:38

>>604
マネジメントの問題ならそもそも正規表現すらしらない人材を登用しないと思うよ。

0609デフォルトの名無しさん

2009/06/26(金) 01:49:40

>>605
マネジメントの問題ならそもそも正規表現すらしらない人材を登用しないと思うよ。

0610587

2009/06/26(金) 07:10:55

通りすがりに揶揄ったら、私の発言待ちになっていたか。要するに
プログラム言語と表現のクラスが違うからということだと思うけど、
1) 表現の複雑さに対する歯止めをどうするのか。
2) ステッパ的な意味での検証をどうするか。
プログラム言語が構造的で、その構造の入口、出口の情報を押さえ、
その状態を観察可能なツールによって支えられているのに対して、
正規表現は入り口のデータと適用されたデータの二種類しかない。
実務の文字列に於いては、パターンの出現位置や繰り返し回数は
予測不能であることが多く、適合したパターンの前、後ろに対して、
予期しない適合が起こっていないか、未検査対象が残っていないか、
などの検証コードの付記が必要になる場合も多い。きっちりとした
論理的コードの記述を簡略化した付けであり、そのことが結果的に
デバッグを困難にする。

0611デフォルトの名無しさん

2009/06/26(金) 07:34:55

仮にログから特定ドメインのメアドを抜けって言われたら、
COBOLで実装するのと正規表現で実装するのとでは、
どう考えても、正規表現の方がマシだよな。

仮にCOBOLで実装したとしても、
＞1) 表現の複雑さに対する歯止めをどうするのか。

正直COBOLのコードで実装したら複雑さなんてハンパねーぞ。
正規表現に比べて、まず実装のミスが発生するだろう。

＞2) ステッパ的な意味での検証をどうするか。

別にCOBOLで実装してもテストケースが減ることはないが。

0612587

2009/06/26(金) 09:38:18

COBOLで文字列解析かい。JAVAでの話と思っていたが。
複雑な文字検索や解析が必要な場合は、「COBOLではできません」と
断るのが正解だとおもうけど。
私はPrologなので、正規表現の表現時間と勝負はするが、ほとんど
負ける。しかし複雑な解析は文脈自由文法のクラスで記述するべき
だと思う。それによってより複雑化する場合に簡単に対処できるし、
新たな文字列を生成する作業も一体に進めることができる。
Prologの述語appendの組合せだけで進む解析記述は双方向の検証が
どの部分にあっても可能だ。そして教育コストはゼロだ。

正規表現の問題が現場で話題にならないとすると、それは文字列解析
を致命的な影響のでる業務で未だ利用していないからではないか？

0613デフォルトの名無しさん

2009/06/26(金) 17:57:06

それって、正規表現の問題か？
適材適所が大事だねって話じゃないか？

0614デフォルトの名無しさん

2009/06/26(金) 17:58:53

>>612
テストの問題かと思っていたら、そんなことかい。

純粋な正規表現で入れ子になってるかどうかを判定しようという香具師はただのバカだろ。
道具の選択を間違ってる。

以上、終了。問題なし、ということがわかった。

0615デフォルトの名無しさん

2009/06/26(金) 22:14:32

>Prologの述語appendの組合せだけで進む解析記述は双方向の検証が
>どの部分にあっても可能だ。そして教育コストはゼロだ。

誰もPrologの話はしていない点について。

>正規表現の問題が現場で話題にならないとすると、それは文字列解析
>を致命的な影響のでる業務で未だ利用していないからではないか？

ぶっちゃけどんな業務だよ。

単に昔正規表現で失敗して痛い目にあったのを正規表現の性にしているだけだろ。

0616デフォルトの名無しさん

2009/06/26(金) 22:40:16

正規表現として適切なサイズ（表現とでもいった方がよいのか）はあるのかも
人間の理解力には個人差があるから、どこで線引きするかは判断が難しい。。
比較的シンプルな文字列解析　例えば、電子メールアドレス、電話番号、郵便番号、URLのチェックとかこの程度のものは正規表現が良いでしょう。
ソースコード解析、HTMLドキュメント解析など、そういう規模の部類は正規表現オンリーで無理でしょうから、クラス化すべきでしょう。

複雑な正規表現は危険な存在ではあるも事実、ただ現代のシステム開発の現場では、そういう部類の要求は少ないと思う。

0617デフォルトの名無しさん

2009/06/26(金) 23:55:27

「正規表現の問題」というより、「正規表現の限界」という事だと思う

0618デフォルトの名無しさん

2009/06/28(日) 20:24:40

構文解析とは関係ないよね。
単に「マッチする／しない」の話であって、特定のパターンにマッチするかどうかで
解析できるような構文には正規表現が使えるというだけの事でしょ。

正規表現は、複雑になるとコードを読む人が何にマッチするのか把握しづらくなるのが欠点。
たとえば、正規表現からマッチする入力・マッチしない入力を想定できるかというと、
"FILE[0-9]{2}[DU]\\.[Cc][Ss][Vv]" 程度なら簡単だけど、
ttp://www.din.or.jp/~ohzaki/mail_regex.htm にあるようなレベルでは考え込む。
↑は対応する仕様が特定できるから成り立つわけで

0619デフォルトの名無しさん

2009/06/28(日) 20:56:23

なるほど、すごい例が出てきましたけど、
厳密に準拠するというのはそんなに難しい事だったのか。あたしも勉強不足ですな；；

逆に考えると、若干、穴がある正規表現だが、他の方法でカバーするような運用が望ましいというのが落とし所なのでしょうか？

0620デフォルトの名無しさん

2009/06/28(日) 21:12:36

受理できるアルファベット限られてるわけだし…
なんで正規表現が問題になってるんだ???

0621デフォルトの名無しさん

2009/06/28(日) 21:40:25

そうですね、ここはCOBOL vs Javaのスレなので、
話を切り替えてみましょうか。

結局COBOLの問題というのは、コンピュータの歴史の問題なんだと思う。
オートメーション化する過程で、当時のコンピュータで処理する言語としてCOBOLしかなかったわけだ。

システム設計、プログラミング方式が確立していない時代の遺産で、
なおかつ社会基盤として成立しているものが多いというところかな。

当時の構築に関わった人間は、現代のコンピュータがこれほど高性能になるとは考えていなかっただろうし、
日本やアメリカなどでは、過去の遺産とどう付き合うか、どう有効活用していくか、
もしくは再構築するのか、悩ましいのではないのでしょうか。

日本の場合はベンダーによる文字コード（漢字）、パック、ゾーンに見られるエンコーディングの差異、
SNA、JCA、全銀手順にみられるネットワーク方式の陳腐化、
特注品を好むのが（これはビジネスの競争上の理由だと思うが）
問題を複雑にしている。

オブジェクト指向も万能ではないことは認める
言語として柔軟性が高い反面、適切な構造を設計できない場合は最悪な状態に陥ると思う。

建築などの分野と違って、技術革新によりパラダイムシフトが起きるスパンが短いことで、
基礎となる設計が揺らいでしまうという、なんとも不安定な分野である。

私の考える歴史的な経緯や語りたいことは以上ですが、東京海上日動にみられるようなCOBOLを選択してしまう理由について
なぜ企業はオープン系の技術に全面改修に踏み切らずにいるのか意見を聞いてみたい。

http://gimpo.2ch.net/test/read.cgi/bizplus/1220822531/

0622デフォルトの名無しさん

2009/06/28(日) 23:02:16

>>621

制御系や科学技術計算系にこんな話題が発生しないのはなぜなの?
COBOLで制御や科学技術計算をやってみてもらいたいもんだ

SEと呼ばれる職種も含めて、要求をうまくモデル化できない土方使ってるから
こうなったんでしょ?

> 建築などの分野と違って、技術革新によりパラダイムシフトが起きるスパンが短いことで、

製造とか建築とかはもっとうまく技術革新を採り入れてるよね
製造とか建築とかのオフィスからドラフターがなくなって何年たつよ

> なぜ企業はオープン系の技術に全面改修に踏み切らずにいるのか意見を聞いてみたい。

現場のSEと呼ばれる摩訶不思議な職種の人間がアフォ
それにわをかけてプログラマって呼ばれる職種の人間がアフォ
だからじゃない?

0623デフォルトの名無しさん

2009/06/28(日) 23:26:36

馬鹿だから、という答えは一切の思考を伴わずに書けるから楽だよね～

0624デフォルトの名無しさん

2009/06/29(月) 00:05:32

この業界の難しいところは、
厳格な基準みたいのが定めにくいんだよね。
テクノロジーの種類が多いのとニーズが変わりやすいから・・・

個人的には、まず設計のみプログラミング知らないひとは不要だと思う。
設計＋プログラミング＝SE、プログラミング＝PG（SE候補）でいいんだよね

あとはPM＞SEっていうのが意味分からない、
PM=SEだと思うし、そもそもプロジェクトマネージメントとシステムをデザインする仕事は別だから。

まぁ不勉強な人でも入り込みやすい業種であるのも事実。

0625デフォルトの名無しさん

2009/06/29(月) 20:20:08

PM>SEがあるとしたらライン職制にしたがって役割を割り振ってるからだろ
ライン関係なくPM>SEな職場なんてあるのか？

0626デフォルトの名無しさん

2009/06/29(月) 21:24:20

何の仕事でも、金をかき集めてこれる奴が一番偉いんだよ。

0627デフォルトの名無しさん

2009/06/30(火) 00:29:44

>>626のような考えが馬鹿な営業を増殖させる事になったんだろうな。

0628デフォルトの名無しさん

2009/06/30(火) 07:37:28

今に始まった話しでもないがの。馬鹿でかい金額をぶん回せる奴は昔っから強い。

0629デフォルトの名無しさん

2009/06/30(火) 11:33:51

>>628
バブル馬鹿発見

0630デフォルトの名無しさん

2009/06/30(火) 15:37:27

>>628 を馬鹿呼ばわりしたところで現実は変えられない罠

0631デフォルトの名無しさん

2009/06/30(火) 17:33:56

サイフ握ってる奴は強敵だよなｗ
仕事くださいm(_ _)m

0632デフォルトの名無しさん

2009/07/08(水) 08:20:18

質問
コボルで、条件に合わない場合、ABENDさせる設計書をよく見るが、
JAVAの場合どうですか？って、JavaにABENDという考えがあるのですか？

0633デフォルトの名無しさん

2009/07/08(水) 10:35:48

System.exit(1)とかやったら強制的に終了するよ。
普通はファイルやデータベース接続なんかのリソースを閉じたり、
適切にログ吐いたりっていうような後始末をきちんとしてから終了するから、
異常終了という意味でのABENDは非常手段だと思うけどね。

COBOLだとその辺のリソースの後始末やらロギング部分は、
JCLとか？のフレームワーク側でやってくれてるから、
プログラマは単純にABENDすれば良いだけなんだけど、
Javaの方がプログラマの裁量に任せるところがあって面倒／難しいとは思いますね。

0634デフォルトの名無しさん

2009/07/08(水) 21:49:52

>>633
あなた、言語の話とOSの話が混乱してるぞ。

0635デフォルトの名無しさん

2009/07/08(水) 22:01:21

JavaでWebなら、システムを強制終了（アベンド）するんじゃなくて
強制的にエラーページに飛ばして、「ただいま回線が混雑しております。しばらくたってからアクセスしてください」
とか、そんな感じのメッセージ出してお茶を濁すんじゃないかと。

0636デフォルトの名無しさん

2009/07/08(水) 22:45:17

>>632
何がいいたいんだ？ ABEND だって, メッセージ吐くだけで OS に丸投げじゃん

>>634
そんな話なら exit する時の hook 仕掛けといて等っパースクリプト
書いときゃ済む話だろ?

0637デフォルトの名無しさん

2009/07/09(木) 22:54:16

>>636
634だが。
日本語で頼む。

0638デフォルトの名無しさん

2009/07/09(木) 23:06:56

コボラーとジャバー。あほ同士なんだから仲良くしなさい！

0639デフォルトの名無しさん

2009/07/09(木) 23:08:43

>>632
作るもの（運用要件）による。別にCOBOLがどうとか、ＪＡＶＡがどうとか、そんなことは関係ない。
２ｃｈのサービスなら別にシステム停止してもなんも生活に影響ないけど、
ＡＴＭがとまっちまったら、みんな困るだろ？

そゆ場合は、なんか問題あってもサービスを止めるんじゃなくて、エラーはエラーとして検知しつつ
なんとか回復の方向に持っていくのがセオリーだ。

>>コボルで、条件に合わない場合、ABENDさせる設計書をよく見るが、

たぶｊん、その見ているシステムは、そんなに重要なシステムじゃあ、ないんだろう。
クリティカルなシステムなら、アベンドなんて、そうそうありえないぞ。

0640デフォルトの名無しさん

2009/07/10(金) 23:42:02

>>639
>たぶｊん、その見ているシステムは、そんなに重要なシステムじゃあ、ないんだろう。
>クリティカルなシステムなら、アベンドなんて、そうそうありえないぞ。

コード上の出現頻度と動作上の出現頻度は別物だ。

0641デフォルトの名無しさん

2009/07/11(土) 08:59:56

不正な処理を継続するより、一度止めちゃった方が健全。

0642デフォルトの名無しさん

2009/07/11(土) 09:25:58

>>641
最低限の終了処理はやるべきだろ

産業用ロボットとかだと、一部のサブシステムだけが勝手に停止すると、
人を殺したりしてしまうんだが

0643デフォルトの名無しさん

2009/07/11(土) 10:57:17

>不正な処理を継続するより、一度止めちゃった方が健全

COBOLってさ、RDBMSのCOMMIT、ROLLBACKって制御できるのかしら、
一度止めた方がというのは考えは、ファイルとかRDBMSの状態を処理途中で中断するという意味？

0644デフォルトの名無しさん

2009/07/11(土) 11:16:35

5年前に俺が新人の頃触ってたCOBOL74では、
DBのRollback/Commitは制御できた。
但しABENDとかするとロックが残ったままになってしまい、
こっぴどく怒られた記憶がある。

0645デフォルトの名無しさん

2009/07/11(土) 11:35:25

COBOLというか汎用機ではJOBという概念があって、
JOB単位で後処理とか例外処理への分岐とか指定出来ちゃうわけさ。
バッチ処理は割りと見境なくABENDさせることが多いな。
精査系やオンライン系はよほどのことがないとABENDさせないぞ。

0646デフォルトの名無しさん

2009/07/11(土) 12:00:07

入力データから出力データがはっきりしている場合は、ABENDで良いって発想なのか。

バッチ系で本来ある方法としては、データの不整合が発生した場合は
不整合を切り分けして、それだけ後で再処理に回すとか、
正常な場合は更新・出力するとかそういうフローになるんでないの？

ABENDした後の復旧ってどういう作業を想定しているのかしら。

0647デフォルトの名無しさん

2009/07/11(土) 12:48:13

想定外のデータが来たら再処理がおおいんでないか？
想定外のエラーはABENDしかないと思うが。

と思いつつも、今漏れが関わっているカード会社の仕組みは超絶的に手抜き思想で、
想定外データが来ても即ABENDだったりするが。

ABENDそのものにどーこー言う気はないが、JOBを再投入するのに壮絶な手間が
かかるJOBフロー組まれていると鬱になるな。

0648デフォルトの名無しさん

2009/07/11(土) 14:17:57

想定外のデータというのも抽象的だが、
例えば1000件のデータをバッチ処理するとしよう、
1000件のデータに関連性がなく、
その内に想定内のデータが900件ならそれは正常に処理して、
残りの100件は想定外だから元のデータを見直して再処理するでOKでないの？

全件が想定内のデータじゃないとまずいケース、例えばクロス集計とかなら話が別だが。

あとは規模にもよるのかもしれないが、1000件程度なら再度全件処理でいいという発想でよいけど、
処理時間が相応にかかる場合は切り分けしたフローのほうが現実的じゃないのかな

いずれにせよ運用者が負担になるような、システムは良い設計とは言えないと思うし、
負担が大きい部分はその原因を探りシステムを見直す、または運用フローを見直すというのが
正しい答えなんじゃないかと。。

0649デフォルトの名無しさん

2009/07/15(水) 08:27:49

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

0650デフォルトの名無しさん

2009/07/21(火) 18:12:51

古いと言う概念ではUNIXもかなり古い、バッチ処理でCOBOLでソースを書いた時とJAVAで書いたときの生産性は、どちらの方が良いのでしょうか、又どちらの方が分かり易い（メンテナンス性）のでしょうか？
これで、COBOLが負けてしまうようでは、勝ち目はないと思いまが？
unix系OSはどんどん進化しているのですが、COBOLは進化しないのですか？
又、コボラーはそれを望まないのですか？

0651デフォルトの名無しさん

2009/07/21(火) 19:14:29

この手のVSスレでそういう質問しても結論出ないし、燃料にしかならんよ
燃料のつもりで書いたならいいけど

0652デフォルトの名無しさん

2009/07/21(火) 21:15:09

つか、COBOLだって進化してるし。
新しいCOBOLはJAVAライクなオブジェクト指向だってもってる。

>>又、コボラーはそれを望まないのですか？
まあ、これはあるかな。
せっかくのリッチな機能も使う側が理解してなくて、結局旧態依然なコーディングしかしてないこと。

0653デフォルトの名無しさん

2009/07/22(水) 00:08:39

そもそも、それがコボラーの定義のような。
COBOL使ってるってだけじゃ、コボラーには当てはまらない。

0654デフォルトの名無しさん

2009/07/22(水) 02:28:27

COBOLの頃のコーディングは「製造」工程と考えられていた。

OOP以降になると、コーディングは「設計」工程の延長。
だけど今でも製造工程なんだよね

0655デフォルトの名無しさん

2009/07/22(水) 16:43:01

COBOLか....何もかも皆懐かしい。

0656デフォルトの名無しさん

2009/07/22(水) 23:17:23

>>654
>OOP以降になると、コーディングは「設計」工程の延長。
>だけど今でも製造工程なんだよね

なんかわかるな、システム設計の成果物である設計書が、
OOPLを知らない人向けになってるのもそうだし
ぶっちゃけUMLを活用しているところなんて皆無じゃない？
構造を説明するというのにプログラミング言語というのが嫌な人が多いんだろうね。

0657デフォルトの名無しさん

2009/07/23(木) 02:24:01

ユースケースとアクティビティは書く。これは上流工程の話だな。

クラス図、シーケンス図は書かんなあ。
いわゆるJaaでWebだとフレームワーク使うことが前提で、
フレームワークのお作法に則ればある程度形（これアクション、これDAOみたく）になるから、
いわゆるモジュールの一覧みたいなのは作っても、図には起こさんな。

コメントうって、あとjavadocみたいな。

0658デフォルトの名無しさん

2009/07/23(木) 23:47:02

GPLライセンスのツールによるCOBOLからJavaへの自動移行
http://www.infoq.com/jp/news/2009/07/cobol-to-java

記事貼りで悪いが、こういう記事を見ると、恐怖を感じるというか、
自動コンバートなんてのが流行った暁には、
レガシーコードがCOBOLからJavaに映っただけじゃんとおもったりする。

0659デフォルトの名無しさん

2009/07/24(金) 00:55:19

Ｊａｖａであることに意義があるのかな。
そんなにＣＯＢＯＬがキライなのか

0660デフォルトの名無しさん

2009/07/24(金) 01:36:42

>>659
人が居ないってことでしょ。
実質的には似たようなことをやっていたとしても、Javaならその先がある気がする。
それに対して、COBOLじゃ一生同じことをやっていくのかと思わせる。

0661デフォルトの名無しさん

2009/07/24(金) 03:39:09

発注する立場の人間に「これはｲｲ」と思わせたら勝ち。
javaの方が若くて丈夫で単価の安い土方多いんだし…

0662デフォルトの名無しさん

2009/07/24(金) 20:59:05

20年前のコボラーですが、このスレについて行けますか？ｗ

0663デフォルトの名無しさん

2009/07/24(金) 22:50:01

「ついて行けますか」という疑問をもてる時点で、「コボラー」の定義から外れるのではなかろうか？

0664デフォルトの名無しさん

2009/07/26(日) 10:40:02

cobolの開発ってやったことないから全然わからんが、興味ある。
http://q.hatena.ne.jp/1248422316

0665デフォルトの名無しさん

2009/07/29(水) 16:37:46

ＣＯＢＯＬをやるなら、ＪＣＬが必須なのだが話題になってないな。
ＪＣＬはjavaのデブロイデスクリプタに似ている

0666デフォルトの名無しさん

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回、
原因不明の動作不全で落ちているのがあったよ。怖いよね。
こいつもマルチスレッドでオブジェクト崩壊起こしてた。
スレッドダンプが拾えなくてしんどかった…

0667デフォルトの名無しさん

2009/07/29(水) 22:15:10

Swingアプリはサーブレットと同じノリで作ると、>>666みたいにハマる。

0668デフォルトの名無しさん

2009/07/29(水) 23:29:28

>>666 >>667
こういうのが信頼落とすんだろうな,薄っぺらすぎ、低能もいいところだろ

0669デフォルトの名無しさん

2009/07/30(木) 07:28:07

>>666
エンジニアとして落ち目街道まっしぐらってトコが可哀想なノリがあるな・・・。
全てが喪前が原因で不安定と言うワケではないが、
基幹系でも毎日STEP当てて不安定をごまかしている運用もあるから、
JCL+COBOLが安定ってのは幻想だ。

安定に関しては言語云々よりも人の質が大きく左右する。

0670デフォルトの名無しさん

2009/07/30(木) 12:02:32

ハメラレタンダ。
糞技術者どもの10数年前の不快な技術、不快なコード、
ずっとバグ隠蔽していた前任が逃げて仕事が、こっちに来たんだよ。
第一、CVS、SVN、VSS、全て存在しないとかいってほざいて辞めたし…

でもいいや、今は生きている。
とりあえず予算通れば…奴らも大人しくなる。

>>669
仕事無い時は別のC#案件とか入るし、顧客対応とかもう疲れた。

>>668
とりあえずスレッドパターンだけ話せるレベルまで、
ちゃんと新人に教えてくれているなら許す。

0671デフォルトの名無しさん

2009/07/30(木) 19:58:59

COBOLって再帰関数書けるの？

0672デフォルトの名無しさん

2009/07/30(木) 20:26:28

30分で調べられる範囲で自分で調べた
COBOL2002とかいう規格だと再帰はサポートされているんだな
あと、戻り値と引数が使える関数！もサポートされてるな
後気になるのは、COBOLにはグローバル変数しかないという話を聞くが
ローカル変数/スタックは使えるのか
また、今広く使われているCOBOLの規格はどれなのか

引き続き解答を募集

0673デフォルトの名無しさん

2009/07/30(木) 20:32:36

いまだにCOBOL88が多いかな。

0674デフォルトの名無しさん

2009/07/30(木) 21:25:54

ＣＯＢＯＬ８５しか知らない

0675デフォルトの名無しさん

2009/07/30(木) 23:52:18

それにしても
WinMergeのプラグインの功績大きいよな…
COBOLコードのDIFFが取れるようになった御陰で、
改修し易くなったぉ。

0676デフォルトの名無しさん

2009/07/31(金) 00:28:00

でも、改修履歴のコメントばっかりで何が何だか分からないって落ちはない？

SCC使ってるのに、あの慣習を持ち込む奴は、さっさと死ぬべきだよね。

0677デフォルトの名無しさん

2009/07/31(金) 01:02:23

ごめん、SCCって意味わかんなかった。VSSの拡張子なんだね。
SVN、CVS、VSS(総称SCM)の利点が使えるから>>676の言い分は共感できる。

でもさ、本番機（SCMが無い環境）にしか開発環境を用意していない所もある。
セキュリティ強化によってソース改修をSCMに頼れない場所だってあるんだ。

あの慣習も場合によっては必要かと…最低悪だよう。

0678デフォルトの名無しさん

2009/07/31(金) 01:18:38

>>677
こちらこそ、ごめんなさい。SCMのtypoです。

でも、この意味が良くわからない。
>でもさ、本番機（SCMが無い環境）にしか開発環境を用意していない所もある。
>セキュリティ強化によってソース改修をSCMに頼れない場所だってあるんだ。

本番機にしかソースがないってこと？
それじゃぁ、本番機が飛んだりしたら元に戻せないのでは？
それに、開発環境とSCMのサーバは別に同じである必要は無いし。

0679デフォルトの名無しさん

2009/07/31(金) 01:19:13

>>672
再帰なんて言語仕様の問題じゃなくて処理系やOSの問題だろ
何十年も前のACOSのアセンブラだって再帰は使えてた

0680デフォルトの名無しさん

2009/07/31(金) 01:30:14

>>678
おぉ、サンクス。そんなツールあるんだ、初めて知ったよ。
検索で一撃で出なかったので、詳細教えてくれない？

>本番機にしかソースがないってこと？
色々事情があってね。セキュリティとか気にする上からのお達しなんだ。
開発環境も本番機に接続…笑えるでしょ？

0681デフォルトの名無しさん

2009/07/31(金) 06:06:35

再帰を分かってないアホがいるな

0682デフォルトの名無しさん

2009/07/31(金) 06:55:49

typoって拡張子の意味だったのか…

0683デフォルトの名無しさん

2009/07/31(金) 11:53:26

>>680
SCMは、ソースコード管理ツール一般ですね。特定のツールではなく。
SCMと打とうとして、まちがってSCCと打ってしまったのです。

しかし、恐ろしい環境ですね。本番機からダム端がぶら下がっている感じ？
ところで、もともとの私のレスは「SCM使ってるのに…」という文脈なんで、
あなたの環境では、コメント入れるのもしょうがない気はします。
なんか解決策ないのかなとは思うけど、そちらの方面には詳しくないので。

酷いところだと、JSPにHTMLコメントで履歴残してたりして、クライアントに駄々漏れ…
それこそセキュリティ上問題があるだろと思うんだけど。

0684デフォルトの名無しさん

2009/07/31(金) 14:46:28

>>683
>>JSPにHTMLコメントで履歴残してたりして
そうか！JSP内にJavaコメントとして残せば良いんだ！(ピコーン)

0685デフォルトの名無しさん

2009/07/31(金) 16:44:45

汎用機にバージョン管理システムなんてあるの？

0686デフォルトの名無しさん

2009/07/31(金) 18:28:48

AS/400は駄目だった、IFSとかあるのにね。

Java も COBOLもSCMが無ければただの（略）で、OKですか？
リファクタリングも糞もないよね。

0687デフォルトの名無しさん

2009/07/31(金) 18:52:51

>>683
>SCM使ってるのに…
そうだね。レス違いだったよ。

SCM使えるのに管理コードのコメント加えるのは氏んで良いと思う。
どんな言語だろうとも。

0688デフォルトの名無しさん

2009/08/01(土) 19:16:08

納品までのどこかの時点で、SCMの管理下から外れるからだろう。
リポジトリを誰が管理するのかという観点で考えられていないことが
多いと思う。

開発～単体テストくらいの期間だけSCM使ったり、逆にリリース管理用に
テスト完了したものしか登録させてもらえなかったり…

0689デフォルトの名無しさん

2009/08/01(土) 23:25:02

バージョン管理だなあ
ＡＰとデータのバージョン管理なのだが難しいのはデータのほう。
ＡＰのほうは目視でスタンプ見てでも何とかなるだろう。
あんぽんたらふうが。

0690デフォルトの名無しさん

2009/08/02(日) 21:09:51

ソースコードバージョン管理システムは、普段何をを何使ってる？

CVS（Concurrent Versions System)
SVN(Subversion)
VSS(Microsoft Visual SourceSafe)
Git
その他（MSのなんとかサーバとか）

0691デフォルトの名無しさん

2009/08/02(日) 22:04:03

うちはSubversionだね、Javaだけど

COBOL言語の場合は知らないけど、どうしてるんだろうね

0692デフォルトの名無しさん

2009/08/02(日) 22:16:24

言語に依存しないだろ。。。そういうのは。。。

0693デフォルトの名無しさん

2009/08/02(日) 22:37:03

Suvbersionってやっぱにんきなのかん。

0694デフォルトの名無しさん

2009/08/03(月) 00:15:22

無償で集中型だと、他に選択肢がないでしょ。
分散型なら沢山あるけど、日本語ファイル名やGUIに難があったりして、環境を選ぶよ。

0695デフォルトの名無しさん

2009/08/03(月) 06:38:29

このスレ何のスレ？

とりあえずオフコンじゃ無理だけど、COBOLはSVNだな...
WINDOSで使えるCOBOLの場合は亀に依存してる。
あのツールはDIFFツールを自前や別ツール指定できるし、Winmergeプラグイン大活躍。
最新バージョンは知らないケド、VSS6.0dじゃ無理。

0696デフォルトの名無しさん

2009/08/03(月) 07:53:43

汎用機のCOBOL開発でバージョン管理を活用したい場合は、
ソースをオープン系OS(Win or Unix)のSVNに入れといて、
コード編集はテキストエディタでゴリゴリ書いて、
コンパイルはSVNからEXPORTしたものをFTPかなんかで転送して、
汎用機に反映してコンパイルって感じなの？

0697デフォルトの名無しさん

2009/08/03(月) 08:46:02

いまだに区分データセット使ってたりして。

0698デフォルトの名無しさん

2009/08/03(月) 09:56:59

コボラならソースにコメント埋め込んで、あとはエクセルで台帳管理だろJK

もうやめたい。

0699デフォルトの名無しさん

2009/08/03(月) 11:53:01

>>698
バージョン管理は悩ましいな。台帳管理が一番いいと思うがなあ。
完全自動化は無理だし、第一、人間の思考回路とか、そういうものは
変わってないからな。完全に落ち着いた状態ならシステムで
やり易いだろうが、管理の境界点では不特定要素がかなり出てくる。
そんなとき、システムがこうだからと言っても、運用側からしたら
そんなこと知ったことじゃない。運用管理の難しさの一つのキモですな。

0700デフォルトの名無しさん

2009/08/03(月) 13:14:22

別に、SCM使ったからと言って構成管理が自動化できるわけじゃないんだが。

バージョン番号を決めるのも、どのバージョンをリリースするかを決めるのも人間がやるしかない。
SCMは、構成管理に必要な機能の一部を提供してくれているに過ぎない。

SCMに変な幻想を抱いていたり、逆に使えないと思っているのは、
単純に構成管理そのものを理解していないからじゃないか？

0701デフォルトの名無しさん

2009/08/03(月) 13:42:26

SCMなんて単純にテキストエディタのUNDO管理／変更履歴機能程度に
考えておいた方が色々気が楽だと思うけどなぁ。
ウチの場合は、開発中は自由にSubversion/CVSにコミットしていって、
(もちろんコンパイル／デプロイできるのが当然条件だけど)、
本番リリース前のwar+ソース一式だけtarやzipで固めて、
共有ディレクトリに置いて管理してる。

698は要約するとめんどくさいから要らない、って言ってるだけに見えるけど、
Javaとかのオープン系で上記の管理してるんかね？

0702デフォルトの名無しさん

2009/08/03(月) 14:47:25

>>698はただの皮肉だと思う。ソースは>>698を書いた俺。
まーでも開発、試験はツール使って管理しててもだ、
本番リリースだけは台帳つくって人間が管理なんてのはよくある話
、なんだかんだでつぶしが利くし
ごくたまにデグレがあってあたふたするけどｗ

最近は台帳というより、リリースノートをウィキで書いたり、
あとボーランドとかベンダーの出してる商用の要件管理ツール（と連動する構成管理、リリース管理）を使ったりなんかもするけど
何が正しい運用なのかは、いまだに答えが出てこないなあ。

0703デフォルトの名無しさん

2009/08/03(月) 16:30:07

>>701
> Javaとかのオープン系で上記の管理してるんかね？
Java はあまりやらないけど, BTS と SCM はないと生きてけないな
それ以外にも, プロジェクトに合わせた, サポート用のスクリプトは結構作る

0704701

2009/08/03(月) 17:09:42

701だけどアンカ間違えた。
>>699だよ、言いたいのは。
とりあえずソース管理なんてそんなご大層なもんじゃなくって、
テキストファイルのバックアップ程度のもんなんだから、
難しく考えずに導入して試して見ろ、とゆいたかっただけです。
後、仕事しような＞俺

0705デフォルトの名無しさん

2009/08/03(月) 21:21:30

やっぱオフコンにはバージョン管理がないのか～
バージョン管理のいいところは、差分が取れる、編集者・編集日時が誰かわかる、タグが付けられるだな。
設計書、スクリプト類、テストデータなんかも入れて使ってる。

使い勝手の良いBTSって無いですよね。Excel管理とかになってしまう。

0706デフォルトの名無しさん

2009/08/03(月) 21:36:25

699やけど、ツールもいいと思うよ。
見事にツールだけで壷に嵌るケースもあると思う
しかしだね、俺が今まで経験した多くのプロジェクトでもでね、
例えば、30本に新規作成や改変やったとしてだね、本番移行は、そのうちの
25本だけなんてよくある話だよ。それとね、システムの性質によっては、
ある特定日に合わせて順を追って移行することもある。
従って、バージョンの管理も本番系、テスト系、それぞれ別個にある。
石橋を叩いても渡らないくらいの用心してやらんとチョンボが出る。
日本のだね、ソフト開発はね、テスト工程以降がマジで手薄だ。
作ったら終わりのような腐ったよなエセＳＥが多い。
運用はね、実は難しいのだよ、わかってる？

0707デフォルトの名無しさん

2009/08/03(月) 22:40:34

>例えば、30本に新規作成や改変やったとしてだね、本番移行は、そのうちの
>25本だけなんてよくある話だよ。それとね、システムの性質によっては

よくある話でもなくて、そのエセSEの計画がムチャクチャだっただけでは。

運用が実は難しいと言うか、バカなSEがいるようにバカな運用も普通に多いと感じる。

0708デフォルトの名無しさん

2009/08/04(火) 00:34:25

バカなSEほど簡単な案件に複雑な運用をして、難しい難しいって言うよね。
ソースの版を管理するのと、どれをリリースするか、って別次元の話じゃん。
依存性のある単位でパッケージングなり、台帳管理なりしておいて、
ソース管理から取り出してリリースすればいいじゃん。
ソース管理を複数持つとか、無駄以外の何者でもないよ。
後、30本の改変やって25本だけリリースしたとして、
残りの5本に依存した機能が必要だったらどうするつもりなんだろうね？
後、石橋を叩いて渡らないって、仕事はするけど成果物出さないの？
それって顧客が怒らない？

0709デフォルトの名無しさん

2009/08/04(火) 00:40:03

>>708
馬鹿なSEとか、複雑な運用とか、難しいとか
だいたい抽象的すぎるだろ表現が、具体的な書いてもらわんと批評できんわ。
そんなんは居酒屋でやってくれ。

0710デフォルトの名無しさん

2009/08/04(火) 00:55:59

居酒屋というよりマー板向きの話題だろ

0711デフォルトの名無しさん

2009/08/04(火) 00:56:25

>>708
まあ経験を積めば見えてくるさ
機会があればだけどね。

0712デフォルトの名無しさん

2009/08/04(火) 00:59:35

プロジェクト管理が出来ていないのを、バージョン管理ツールで埋め合わせは出来ないな。
バージョン管理以前の問題だ。

発注側が馬鹿だから、SIerの評価が出来ない。
SIerも馬鹿だから、エンジニアの評価が出来ない。
結果、金ばかり掛けて使えないシステムが出来上がると。

0713デフォルトの名無しさん

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にも影響するんです」
となると・・・・・もう嫌っ！

0714デフォルトの名無しさん

2009/08/04(火) 06:16:48

>>713
A-E の改修が完了した時点で, リリースブランチ切ればいいって話でもないのかな?

F をリリースする前の突発的な変更は、リリースブランチでやっておいて F を
リリースするときに必要であれば F にマージ。

F の改修はリリースブランチの変更を意識することなくヘッドブランチで作業
F の回収中に必要性が判明した A-E への変更もリリースブランチを意識する必要なし

程度のことはできるけど………

0715デフォルトの名無しさん

2009/08/04(火) 06:38:54

運用管理の話しに花が咲いていますね。
まさにシステムは生き物だというのを、明確に実感できるセクションだね。
プログラムのこと、データのこと、顧客運用のこと、総合的な視野を
持っていないといけないね。運用管理に関してはJavaもCOBOLもない訳でね、
安全サイドに立脚して考えていかないといけないね。
その中で、ツールを使えるところは使うし、手作業のとこは手作業で、
可能であれば技術者の思考の余地が少なくなる方向で出来上がれば
いいのではないかな。

0716デフォルトの名無しさん

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のドキュメントで、「こんな場合はこうする」ってのがあったと思うんだが、
今見てみたらつながらなかった。

0717デフォルトの名無しさん

2009/08/04(火) 16:56:43

いったいここはなんのすれだ？

0718デフォルトの名無しさん

2009/08/04(火) 18:21:37

コボラー？

0719デフォルトの名無しさん

2009/08/04(火) 18:37:40

COBOLは使った事が無い

0720デフォルトの名無しさん

2009/08/04(火) 23:39:35

おまいらこんな所で油売ってないで台帳の棚卸し作業に戻るんだ。

0721デフォルトの名無しさん

2009/08/05(水) 00:48:38

今日も汎用機側の項目表とにらめっこする仕事がはじまるお……

0722デフォルトの名無しさん

2009/08/05(水) 01:02:59

AS/400とかまだ現役なのかな。RPG2とかいうカラム指定の
意味不明な言語があったな

0723デフォルトの名無しさん

2009/08/05(水) 01:10:19

RPGのカラム指定は恐ろしく生産性が高いよ。
現代のインテルセンスというより、エラー＋タッチ＆GOみたいな感じ？（ニュアンス伝わらなかったらすまない）

オブジェクト指向ではないけど、同名フィールド名で、同じ型なら多重定義できるから
使い方によってはすさまじく効率が良いプログラミングが可能。

0724デフォルトの名無しさん

2009/08/05(水) 01:18:00

大企業の基幹システムは見事なまでにＣＯＢＯＬばっかりだよな。
用語辞書に名前が載るような鉄道系巨大システム開発やったことあるが
もはや触れないと言っていた。当時はディスクが高価でね1バイトで
8個のフラグ操作とかやってるからな。汎用機は高額だからメーカーも
受注生産でも対応するだろうし、基幹システムのJAVA化には
踏み切らない、もしくは、それは緩やかなものになると思う。
IBM、HITAC、FACOM、ACOS、MELCOMこんなもんだろう。
20XX年までに汎用機から完全撤退とか、そういう話になれば
そりゃあ面白いだろうけどなあ。これからのネックは人材だろうよ。
COBOL技術者は高齢だからなw、40代、50代、60代だろう。
慌てて若者のCOBOL教育もやってるみたいだけどね。間に合わないよな。
やりたがらないだろうし。これからのパラダイムが動いてさ、
大きなシステム改修とかが発生したら、どうするんだろうな。
若き技術者が苦労しながらやっていくんだろうと思う。

0725デフォルトの名無しさん

2009/08/05(水) 01:24:54

>>724
COBOLがそうだから自分が偉いとでもいいたい勘違い野郎か？

0726デフォルトの名無しさん

2009/08/05(水) 06:34:07

＞大企業の基幹システムは見事なまでにＣＯＢＯＬばっかりだよな。

正確には昔からある大企業だろうけど。
GoogleやらYahooがCOBOL使っているとはとても思えんが。

0727デフォルトの名無しさん

2009/08/05(水) 06:57:34

オレゆとりだから、2chでグダグダ書かれた長文もちゃんと読む人スゴいと思う

0728デフォルトの名無しさん

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
もう寝る。

0729デフォルトの名無しさん

2009/08/05(水) 07:08:14

>>727
ゆとりは関係ない。出来る奴はできるし、出来ない奴はできない。
顧客対応が一番むずいよ。言語そのものが話してる途中で変わるから。

0730デフォルトの名無しさん

2009/08/05(水) 20:28:17

javaはマルチプラットフォームによってコンパイルが２度入るから、動作自体は結構遅いけどな。

0731デフォルトの名無しさん

2009/08/05(水) 20:51:49

>>730
COBOLよりは速いから心配すんな

0732デフォルトの名無しさん

2009/08/05(水) 21:11:02

>>730-731
このやり取り何回目よ

0733デフォルトの名無しさん

2009/08/05(水) 22:20:22

javaより遅いってアホなの？死ぬの？

0734デフォルトの名無しさん

2009/08/05(水) 23:51:16

とりあえずCOBOLはFORTRANやRPGよりは遅いな。ｗ

あとCOBOLでcgi作ったことないから解らんが、htmlを返す様な処理なら
色々な意味でJavaの方が速いもしくは楽だと思うけど。

0735デフォルトの名無しさん

2009/08/05(水) 23:57:28

>>734
COBOLとRPGを速度を比較するなら
AS400で、おんなじ内容の処理で計測必要があるとおもうが。
それとFORTRANとの比較自体意味なくないか？

0736デフォルトの名無しさん

2009/08/06(木) 00:11:45

COBOLは1週間あれば誰でも覚えられるがあまり実用的じゃないな
最も銀行とかでかい企業で基幹部分いじってるって言うなら別だけど

0737デフォルトの名無しさん

2009/08/06(木) 01:04:50

AS/400は20年くらい前にちびっとやったことある。
いまだ現役とは恐れ入る。確かに名機だったがね。

0738デフォルトの名無しさん

2009/08/06(木) 12:29:22

今日知ったJavaの不具合だけど、1つのメソッドが64k以上になると、
コンパイル出来ないって言うJVMの仕様があるらしいね。
COBOLのプログラムを機械的に移行するツールとか使った場合なんかに、
この制限を突破しちゃって、これだからJavaは～とか叩かれないかしら。

0739デフォルトの名無しさん

2009/08/06(木) 12:59:30

不具合とはひどい話だな

64kも書くようなメソッドを作る香具師はバカ。
オブジェクト指向分かってないし、
そんな複雑なものを作ったら、そもそもテストができん。

COBOLのプログラム間共有領域は2kとかの制限の方が、よほどおかしな話

0740デフォルトの名無しさん

2009/08/06(木) 13:19:02

COBOLのステートメントが80桁なので、
単純に割り算すると8191行ぐらいのステップになるのかな？

実際には80桁使い切るステートメントはありえないので、もうちょっと行は増えるのか。

0741デフォルトの名無しさん

2009/08/06(木) 13:37:22

>>738
> 1つのメソッドが64k以上になると、コンパイル出来ないって言うJVMの仕様
バイトコードのサイズじゃなかったっけ?

0742デフォルトの名無しさん

2009/08/06(木) 23:19:07

>>738
ある意味、どんなコードなのか見てみたいｗ

0743デフォルトの名無しさん

2009/08/06(木) 23:39:04

昔２万行くらいあるCOBOLソースをメンテしたこと歩けど
それでもいくつかのブロックに分かれていたからなあ。

俺も元がどんなプログラムなのか見てみたいわな。

0744デフォルトの名無しさん

2009/08/07(金) 00:59:15

ソースで12000ステップというの組んだことある。
DBはADABASで。64ｋというのロードサイズだったら結構あるんでは？

0745デフォルトの名無しさん

2009/08/07(金) 01:38:04

ジェネレータやコンバーターを通すととんでもないソースを
吐くことも多いからその辺じゃない？
プログラムは小さくてもコピー句がでかくて、
それを読み書きするJavaのコードが際限なく生成されてたり。

0746デフォルトの名無しさん

2009/08/07(金) 02:22:54

>>738
誰も困らない仕様を不具合と呼ぶ前に、巨大メソッドを吊し上げろよｗ

0747デフォルトの名無しさん

2009/08/07(金) 07:11:15

スレの流れを読まないでレスしてみる。
64kのバグはCOBOL→Java変換で起こったと…

0748デフォルトの名無しさん

2009/08/07(金) 14:31:59

UMLや簡易言語からCOBOLのソースを自動生成するツールが
使われていることがあって、このソースは見れたものじゃない。
そこからさらにJavaのソースを自動生成したとすると、
混沌ぶりが二倍二倍！

0749デフォルトの名無しさん

2009/08/07(金) 14:52:50

ちなみに上記の64k制限は以前にJSPのコンパイルで引っかかったことがある。
元のJSPのサイズだけで40KB近くあって、中にスクリプトレットが大量に埋め込まれているんだぜ。

ところで誰かJRubyとかJythonみたいな感じでJCOBOLとか作らないかな？
出たらスレタイの不毛な議論も無くなり、
COBOLer≒JCOBOL技術者≒Java技術者とか言って売り込めるんだけど。

0750デフォルトの名無しさん

2009/08/07(金) 21:04:15

COBOLのプログラムをオブジェクト指向的な作りのJavaクラスに自動変換できるとは思えない。

よってCOBOLのレガシーコードが、COBOLなんちゃってフレームワークなJavaレガシーコードになるのがオチ
COBOLなんちゃってフレームワークなJavaレガシーコードのソースなんかメンテしたくないわな。

ただ、パフォーマンスとか信頼性の点でまともに動作するなら、最新のIDE、SCM等を活用できるので評価したい。
まともな頭を持ってる人なら、変換後に全プログラムの動作確認が必要と判断するので、
テストする工数と新しく作り直した場合の工数のどっちが多いかという検討をするだろう。

自動変換が難しい部分は、Javaで作り直しという選択でも良いのかもしれんが。。

>>749
COBOLの場合は、コピー句があるからそんな代物は作れないと思う。

>>748
それ最悪だね。そういうCASEツールで作られたもので、なおかつ変換したいというのは悪夢だな。

0751デフォルトの名無しさん

2009/08/07(金) 22:44:15

>>749
不毛ではないよ。COBOLを窓から投げ捨てれば万事解決。

0752デフォルトの名無しさん

2009/08/07(金) 23:36:14

配備プロパティをPlug-in通して環境を指定したいんだけど、どうすりゃいい？
バージョン勝手に変えてくれるからJavaは言う事聞かなくて困るよ。

あとJavaコントロールパネル、反映されないのは何故だろう。
Windowsの場合レジストリに書き込んでるのだろうか…
JREの仕組みを教えてエロい人。

0753デフォルトの名無しさん

2009/08/08(土) 01:53:28

>>752
お前は馬鹿まで読んだ。

0754デフォルトの名無しさん

2009/08/08(土) 20:04:58

COBOLはredefinesとか７７とかあったな。

0755デフォルトの名無しさん

2009/08/08(土) 21:07:45

66や88が使えるようなプログラマーは現場で煙たがられる。
だから誰も口にしないし、知らないふりをする。

0756デフォルトの名無しさん

2009/08/11(火) 22:27:11

COBOL88は響きが良いね。
世代限定でウケる

0757デフォルトの名無しさん

2009/08/12(水) 10:10:07

>>754－775が言ってるのはDATA DIVISIONのレベル番号のことだろう。
77がレコードに依存しない変数の宣言。
88がEnumもどきの奇妙な変数？の宣言。
66が・・・うむむ思い出せん。

0758デフォルトの名無しさん

2009/08/12(水) 21:37:25

77か、懐かしいな。。

0759デフォルトの名無しさん

2009/08/13(木) 01:32:14

さすがに77は新規に使ったことないな。メンテならある。
COBOLソートが苦手だったなあ。通常はＪＣＬでソートマクロを
使うけど仕様上どうしてもってのが、あったなあ。

0760デフォルトの名無しさん

2009/08/14(金) 12:52:12

ソートか、、、大変だったな、、、

0761デフォルトの名無しさん

2009/08/18(火) 20:46:58

素朴な疑問。
COBOL資産をどうするのかという話があるが、例えばJavaの場合に、
色んなフレームワークなどに依存して開発を行い運用をしていたとしてだね、
世の中のＩＴ事情が変化して活気的な新たなフレームワークなりが出現するか、
もしくは、時代の流れにマッチしなくなり改修も難しいとなったときに、
COBOL→JAVAコンバートよりも、比較にならないくらい一大事にならないかな。
現有資産について、将来そのような必ず訪れる事柄について
どう考えるよ？

0762デフォルトの名無しさん

2009/08/18(火) 21:10:01

>>761
> 現有資産について、将来そのような必ず訪れる
実際はもう起きはじめてるんじゃね?

Javaが依存してる単純なOO的考え方なんて細粒度の並列化なんて
出来ないわけだから…
まぁ、「ご愁傷さま」としか言いようがないわな

# 現在使われてる、「全部のライブラリが細粒度並列に対応する」
# なんて無理ちゃうか?

0763デフォルトの名無しさん

2009/08/18(火) 21:30:09

COBOLの問題はビジネスロジックとその他の部分がべったり癒着しているとか再利用が効かない点で、
Javaとかでまともにフレームワーク使って作ってあれば、ちゃんと分離されてるだろう

ビジネスロジックは時代や技術が変わっても生き残る
どっちがいいかは火を見るより明らか

0764デフォルトの名無しさん

2009/08/18(火) 21:38:20

ロジックは思考だか生き残るさ。
ただそれを実現する手段方法、具体的には、プログラムや設定ファイルが、
Javaと見ても周辺機構で違うってことだね。
そういった手段方法が、通用しなくなったときに、どうやって移植するか、
COBOLはほとんど言語的なものしかないがJavaなどが得意とするWeb系は、
言語そのものよりも、実現のために周辺機構のウエイトが高い。
また、そういった機構も種類が多く、たとえば10年後に移植しようとする場合に、
COBOLで言うところのCOBOL技術者という括りですまない。
Ａ社の場合はJava言語プラス、Ａフレームワーク精通者であるとか、
その細分化は技術者確保をも難しくする。
現在においても若きプログラマはフレームワーク依存だけで育ったものも多く、
さてエディタで作成したJavaアプリ改修となっただけで、ちょっと困った
状況ってあるんじゃない？

0765デフォルトの名無しさん

2009/08/18(火) 21:48:01

発想がね大量消費の発想そのもののまま、走り続けているね。
世の中リサイクルが叫ばれているけど、現在の開発思考は、
産むための道具のリサイクルを唱えているからねえ。
産んだ後の子守、親が死んだ後の生きかたを示してないよな。
ＣＯＢＯＬより、もっと恐ろしい未来が見えるよ。

0766デフォルトの名無しさん

2009/08/18(火) 21:58:46

画期的な何かが、なんなのかがわからないと検討しようもないが。
その画期的な何かで新しい利益を生むなら対応するだろう。

時代のニーズに対応できない企業は廃れる。
それはITに限らずの話だ。

0767デフォルトの名無しさん

2009/08/18(火) 22:35:31

>>761
まともなアーキテクトなら、ライブラリ・フレームワーク依存の部分と、
ビジネスロジックの部分は分割するよ。

そうしないと、テストも大変だし。

0768デフォルトの名無しさん

2009/08/18(火) 23:42:15

>>761
俺流ライブラリや俺流フレームワークが満載なCOBOLが言う台詞でないと思うが。

0769デフォルトの名無しさん

2009/08/19(水) 03:56:18

COBOLの時代の教訓から、業務依存の部分とシステム依存の部分を
分離する努力が為されてきたわけだから、状況は良くなっているはず。

ただ、COBOLの発想を押しつけられたプロジェクトは悲惨だろうな。
解決されたはずの問題が再び…受注ｳﾊｳﾊになればいいねｗｗ

0770デフォルトの名無しさん

2009/08/19(水) 07:40:18

いまでもjava1.4で開発せいよというプロダクトは結構あるぜ。

0771デフォルトの名無しさん

2009/08/19(水) 08:48:56

>>770
あるんだろうなあ。サポート切れてんのになあ。

0772デフォルトの名無しさん

2009/08/19(水) 20:34:23

この間VB4.0の案件が流れてきたときはマジでワロタ。
まあ工場なんていまだMS-DOSが動いていたりするからなあ。

0773デフォルトの名無しさん

2009/08/20(木) 06:29:01

それはそれで微笑ましく感じるんだが。
PC-98ｶﾞﾝｶﾞﾚって

0774デフォルトの名無しさん

2009/08/21(金) 13:09:48

VB4いまだ現役か。。10年位稼働してるならかなり良い出来なんでないかな。
ハードウエアの老朽化で置き換え不可になった場合はどうするのだろうか。

COBOLやJavaに限らず、ソフトウエアって扱いが難しいよな。

0775デフォルトの名無しさん

2009/08/24(月) 21:10:34

NetCOBOLで作られたアプリで出力された、"ORGANIZATION INDEXED"なファイルを、
NetCOBOLの入っていない環境で読み書きしたいんですが(言語はJava)、
なんか良い手段ありますでしょうか？
　内部のデータ構造はわかってるのですが、どう読んだらいいかがわからない……

0776デフォルトの名無しさん

2009/08/25(火) 21:39:12

NETCOBOLの入っている環境で、TEXTファイルへ変換するしかないと思う。
これはNETCOBOL付属のユーティリティがあるはず。

Javaで直接読むには、NETCOBOLのINDEXファイルの形式をリバースエンジニアリングするしかないと思う。

0777デフォルトの名無しさん

2009/08/25(火) 22:22:39

>>775
ランダムアクセスで読み書きできそう、試してみて。
索引主キー中心にレコード抽出する。
レベルが下位になると繰り返されるからその所の長さを測るのが厄介かも。
単純にレコード長で格納されていると難しくないんだろうけど・・・

あとVectorとかのフリーウェアとかでも構造を指定すると索引ファイルの中身を読むツールあったと思う。
参考になると思う。

0778デフォルトの名無しさん

2009/08/26(水) 02:49:01

>>756
ギャラガ88でも思い出したかい？

0779デフォルトの名無しさん

2009/08/26(水) 03:50:29

>>774
JavaはWeb主体だし、サーバー側だけの問題だし
コンピューターの種類も選ばないから最強だよ

0780デフォルトの名無しさん

2009/08/26(水) 10:06:25

JavaはSunのRun anywhereの思想に則って普及したから、
まぁ他の開発言語に比べれば動作環境が幅広いのは助かるよね。
何を以て最強とするか、って定義は難しいけど、
動作環境が多様なので、仕事が多く、プログラマの数もそれなりに確保できる、
って点では、オープンな環境では一番成功してるんじゃないかな。
汎用機系みたいなクローズ環境や、phpみたいな特化用途言語と比較すると、
個別に劣る部分はあるだろうけど。

個人的にはSwing/AWTのGUI部分強化きぼんぬ

0781デフォルトの名無しさん

2009/08/28(金) 17:29:36

JavaもバージョンUP繰り返してるから、
改修したい場合に旧ランタイム、旧フレームワークをどうするかという
問題はあるんでないの？
COBOLのマイグレーションで（汎用機 -> オープン系）よりかはマシだと思うけど。

0782デフォルトの名無しさん

2009/08/28(金) 18:20:54

別にバージョンアップしない自由もあるわけだが。
それはJavaに限らない問題だろう。

ウチのシステムの場合はハードやらOSがサポート切れになったらついで(?)に
土台のハードから入れ替えて関連ソフトウェアもアップデートするけど、
その時にそれなりの工数もらって色々検討して移行するなり切り替えてテストするから、
COBOLの様に永遠に過去の遺産を引きずる事はないな。

システムを改修するレベルがよく解らんけど、既存のシステムに機能追加とか
ちょっとした修正だとJVMのバージョン上げるとか、やらんと思うが。

Webサーバーをポコポコと立てる様な仕事だとビミョーだろうけど。

0783デフォルトの名無しさん

2009/08/28(金) 18:53:22

COBOLの最大の問題は言語や実行環境にあるんじゃない
使っている人間が技術者としてレベルが低いやつが多いってことが最大の問題なんだ

0784デフォルトの名無しさん

2009/08/28(金) 20:28:56

何億円もかけてcobolからjavaにコンバートする意味あるの？

0785デフォルトの名無しさん

2009/08/28(金) 20:50:26

結局、汎用機の保守費用が、現行のビジネス環境として釣り合わないから
マイグレーションするんでしょ。
競争原理が働き難い（値段が下がらない）、メーカーの利権化がしやすい、
特定ソフトが高額、サポートが不便、開発生産性が低いとか
特定ベンダーべったりは安心・安全だと思うが、そういったマイナスの面はあるよね。

0786デフォルトの名無しさん

2009/08/28(金) 23:10:33

正直なところ、何で何億円も掛かるのかと思うよ。
収益のコアとなるような業務なら、本来は内製で開発すべき。

0787デフォルトの名無しさん

2009/08/29(土) 14:45:41

必要に応じて社員を自由に雇用・解雇・配置転換できるような会社なら可能だな

0788デフォルトの名無しさん

2009/08/29(土) 16:04:34

納入先の業務形態を深く理解してない出来ないコボラーなんて存在価値ないからねー

0789デフォルトの名無しさん

2009/08/29(土) 16:12:36

>>788
それは別にcobolに限らずそうじゃね？　程度の差こそあれ。

0790デフォルトの名無しさん

2009/08/29(土) 17:55:20

アホ言語同士仲良くしなさい

0791デフォルトの名無しさん

2009/08/29(土) 18:02:59

キーー！！じゃあアホじゃない言語って何なのよ

0792デフォルトの名無しさん

2009/08/29(土) 19:13:18

cobolとjava以外全部

0793デフォルトの名無しさん

2009/08/29(土) 22:01:04

よし！VB！

0794デフォルトの名無しさん

2009/08/30(日) 00:41:03

つまりクラサバはVB6、WebはPHPが最強言語と言うわけですね、判ります。

0795デフォルトの名無しさん

2009/08/30(日) 01:09:07

そんなことどこかに書いてあんの。あほなの、死ぬの？

0796デフォルトの名無しさん

2009/08/31(月) 06:59:58

もうみんなC++かPythonでいいよ。

0797デフォルトの名無しさん

2009/09/05(土) 07:42:30

つアセンブラ

0798デフォルトの名無しさん

2009/09/06(日) 00:32:15

会社のCOBOLのIDEバージョンうｐしたらeclipseが採用されてた

0799デフォルトの名無しさん

2009/09/06(日) 02:47:07

C → awk/perl/C++ → Java/JavaScript/C#
と育ってきた俺は、{}がないと違和感を感じる。

0800デフォルトの名無しさん

2009/09/06(日) 21:35:28

Java → C/C++ → VB → COBOLやPL/SQLと育ってきた俺は、
C#とか{}があると幸せを感じる。

0801デフォルトの名無しさん

2009/09/06(日) 21:58:21

カッコなんで邪魔なだけ。
pythonに目覚めた俺はインデントこそ至高。

0802デフォルトの名無しさん

2009/09/06(日) 22:52:50

カッコさえあれば、他に何もいらない。
Ｌｉｓｐに目覚めた俺はＳ式こそ至高。

0803デフォルトの名無しさん

2009/09/07(月) 00:36:21

endがないと生きていけないんです。

0804デフォルトの名無しさん

2009/09/07(月) 02:49:06

Prologしか知らない僕は何もいらない。

0805デフォルトの名無しさん

2009/09/08(火) 23:07:35

行番号が無いの？フロー制御できないじゃん

と本気で思っていた中２の夏

0806デフォルトの名無しさん

2009/09/10(木) 03:54:06

>>804
っ.

0807デフォルトの名無しさん

2009/09/10(木) 06:18:09

>>802
だが、カッコだらけのコードを読まされる方にとっては、M式だな

0808デフォルトの名無しさん

2009/09/11(金) 09:39:41

>>805
俺もProlog.
pythonのインデントが滑稽に見える。

0809デフォルトの名無しさん

2009/09/11(金) 13:41:54

>>807
ちゃんと綺麗に書かれたコードを読むだけなら、慣れで何とかなる。
だが、大量の閉じ括弧の途中に1文追加するとなると、エディタのサポートが無いと辛いな。

0810デフォルトの名無しさん

2009/09/11(金) 19:04:08

>>789
いまどきはEclipseでCOBOL開発できるんだ。IBM?

COBOLでまともな（現代的な）開発環境を見たことないんだよな。

0811デフォルトの名無しさん

2009/09/11(金) 19:13:48

>>810
富士通のCOBOL85
とかそれなりにビジュアルプログラミングできるべさ

COBOLは死ぬ死ぬ詐欺
敷居が他の言語に比べ低い上に、メンテナンス性が低い割にコードが読みやすいから何とかなる。

>>783
今はマシンパワーが大きくなっているから
メモリとかの心配しないくていいし
プログラマはヘボでもいいよ、要は動けばいい。

ひどいコードでも動くし、形になるならそれでいいだろう。

0812デフォルトの名無しさん

2009/09/11(金) 20:15:40

＞敷居が他の言語に比べ低い上に、メンテナンス性が低い割にコードが読みやすいから何とかなる。

Pythonに比べれば圧倒的に敷居が高い上にコードは読みにくい。

0813デフォルトの名無しさん

2009/09/11(金) 20:19:39

JAVAのコードは解りやすい

0814デフォルトの名無しさん

2009/09/11(金) 20:20:35

理由はMVCが分離されてるから

0815デフォルトの名無しさん

2009/09/11(金) 20:25:16

>>807
emacsのコマンド一発で自動整形。
そしたらPythonみたく、ほとんどインデントだけで制御構造がわかる。なれたLisperはカッコなぞ見ないのだｗ
C系言語とちがってこの手の自動整形コマンドの精度が高いのも
あのカッコのおかげなんだぜ。

だけど>>809の言うとおり、いざコードをメンテしようとすると結構しんどいｗ

>>811
超大量夜間バッチだとパフォーマンスは結構シビアだぞ。
まあでもCOBOLでパフォーマンスチューニングってーと
どっちかってーとCOBOL云々よりSQLのメンテでどうにかなること多いけど。

0816デフォルトの名無しさん

2009/09/12(土) 01:29:48

コボルいらねー

0817デフォルトの名無しさん

2009/09/12(土) 14:49:39

今や敷居は高い部類に入ってしまうね
言語そのものより、入手のしやすさや動作するプラットホームの関係でな
言語そのものの敷居はそんなに高くは無いよ

0818デフォルトの名無しさん

2009/09/12(土) 18:20:42

趣味で覚えるような言語ではないから、プラットフォームは関係あるまい

0819デフォルトの名無しさん

2009/09/12(土) 18:39:20

主流言語が技術情報や実行環境の入手が安易かどうかという時代に
COBOLは旧態依然すぎる。

身近なところから改善したり、何かに応用する分野には向いてないよ。

0820デフォルトの名無しさん

2009/09/13(日) 00:16:56

昔は商業高校とかでもCOBOLを教えていたらしいけどな･･･。

学校とかじゃ「死んだ言語」扱いだろ。

今や老害ホイホイな言語と言う印象しかない。

0821デフォルトの名無しさん

2009/09/13(日) 09:09:48

COBOL　java VB

0822デフォルトの名無しさん

2009/09/15(火) 01:27:43

ところでJavaな人はScalaにいったりするの？

0823デフォルトの名無しさん

2009/09/15(火) 02:01:55

Scala勉強してるけど、Scalaの仕事がない。
自前でやるしかないな。

0824デフォルトの名無しさん

2009/09/15(火) 06:36:25

仕事は、まだないかもしれないけど勉強してる人は結構いそう

0825デフォルトの名無しさん

2009/09/15(火) 07:04:13

Haskellを完全に無視してるせいかも知れないけど、
米国では案件も求人も多いらしい。

0826デフォルトの名無しさん

2009/09/15(火) 12:30:55

アメリカ良いなぁ。
俺が行ってたとこも、リリース前なのに9時５時で、金曜の夕方はビアバッシュ。
ランチもフリーだし、オフィスも広いし、植え込みにはハチドリが飛んでるし。

日本はもう１０年ほど失われそうだし、まじでアメリカに脱出したい。

0827デフォルトの名無しさん

2009/09/15(火) 12:43:42

元々棄民の国だし半数以上に怠け者DNAが流れてる国だからね
自覚して規格化やら勝者優先社会構築してるのはスバラスイ訳だ

0828デフォルトの名無しさん

2009/09/15(火) 14:48:40

関数型並列実行プログラミングがはやってくるんかなぁ
クラウドとか、なにかで劇的に変化する要素があると面白いんだがな

0829デフォルトの名無しさん

2009/09/16(水) 01:15:55

業務系は今のところ５年遅れているから、５年後に報われる。

かも

0830デフォルトの名無しさん

2009/09/16(水) 06:26:04

オイオイ、漏れのところは軽く１０年はおくれているぜ！

orz

0831デフォルトの名無しさん

2009/09/16(水) 06:32:38

業務系は保守的だからね。
枯れた技術のほうが上層部に好まれるんだよ。

0832デフォルトの名無しさん

2009/09/16(水) 11:02:22

未だPL/I→COBOLとかやってたりするからな…

0833デフォルトの名無しさん

2009/09/16(水) 21:40:54

数年前やれ新技術だとEJB2やRoRに飛びついたプロジェクトがどうなったことやら。

0834デフォルトの名無しさん

2009/09/16(水) 22:35:09

>>831
最新技術を触りつつ枯れるのを待っていたのなら充分武器になるけど、
孫請けあたりまで行くと、単に初めて見る新技術だからな…

0835デフォルトの名無しさん

2009/09/16(水) 22:41:16

PL/Iって導入実績少なそうで大変そう、しかもCOBOLかよ。
どんなバツゲームなんだよ

0836デフォルトの名無しさん

2009/09/20(日) 01:12:42

【コンピュータ】まだまだ現役：プログラミング言語のCOBOLが誕生50周年 [09/09/19]
ttp://anchorage.2ch.net/test/read.cgi/bizplus/1253376523/

0837デフォルトの名無しさん

2009/09/27(日) 20:45:06

設計の相談に対して「理解している方法でいいんじゃない？」
と答えていたら、こちらに作業が振って来やがった・・・orz

UMLのクラス図からしてJ2EE/DAOパターンの採用なのに
ビジネスロジック１６クラス、DAOクラス９クラスを残り1ヶ月だと？
DbUnitとかのテストケースなど一つもないじゃんか・・・
ってかこんなに機能あるのに１クラスにまとめてんじゃねー。

何はどうであれ、他人の作業には口を出すのは藪蛇だったorz

0838デフォルトの名無しさん

2009/09/29(火) 00:33:19

有能かつ頼りにならない人物を目指すんだ。

0839デフォルトの名無しさん

2009/09/29(火) 01:09:11

難しいこと言うね

0840デフォルトの名無しさん

2009/09/29(火) 17:50:17

その話だけだと楽勝の範囲だけど

0841デフォルトの名無しさん

2009/09/29(火) 21:14:07

設計から割当てられれば楽勝の範囲だったんだろうな。

0842デフォルトの名無しさん

2009/10/01(木) 14:31:07

まだまだ現役：プログラミング言語のCOBOLが誕生50周年
http://busynes.blog68.fc2.com/blog-entry-498.html

0843デフォルトの名無しさん

2009/10/01(木) 17:09:13

> まだまだ現役：プログラミング言語のCOBOLが誕生50周年
だからどうした？

fortran も lisp も現役だが…

0844デフォルトの名無しさん

2009/10/02(金) 00:04:48

あれ、コンピュータ言語で消滅したのってあるの？
使い手が０人になりましたみたいに。。カウントできねーかｗ

0845デフォルトの名無しさん

2009/10/02(金) 00:10:05

消滅というか、作者がうｐデートを辞めた言語なら・・

0846デフォルトの名無しさん

2009/10/02(金) 01:48:00

Uvaとかは消滅で良いんじゃないか

0847デフォルトの名無しさん

2009/10/02(金) 02:16:04

B言語も消滅してると思う

0848デフォルトの名無しさん

2009/10/03(土) 00:35:54

brainf**kやその派生みたいなネタ言語は
カウントのしようがない

0849デフォルトの名無しさん

2009/10/03(土) 01:02:01

Basic系は消滅してるの多そうだけど。
昔に使ってたX68kのX-Basicとかは本機とともに消滅したんだろうなｗ

どの辺をいわゆるACTIVEな言語かと判定するかだよね。

0850デフォルトの名無しさん

2009/10/04(日) 13:18:51

>>849
　　　∧∧
　　（´･ω･）　おやすみ・・・
　＿|　⊃／(＿＿_
／　└-(＿＿＿_／
￣￣￣￣￣￣￣

0851デフォルトの名無しさん

2009/10/06(火) 05:22:36

ＣＯＢＯＬ標準は８５？

0852デフォルトの名無しさん

2009/10/15(木) 00:52:14

Javaもそろそろレガシー言語之なんじゃね？

0853デフォルトの名無しさん

2009/10/15(木) 21:01:39

Javaの場合はむしろ枯れることを狙ってるように思う

0854デフォルトの名無しさん

2009/10/17(土) 14:56:02

COBOL が枯れているってホントかな。
新しい規格をつくって新しい技術を取り込もうとする動きを止めてる訳ではないだろうし。

そもそも、言語が枯れるという事に意味があるのかな。

処理系やライブラリが枯れるというのなら分かるけど。

0855デフォルトの名無しさん

2009/10/17(土) 18:39:34

言語仕様変更はライブラリよりキツイだろ

0856デフォルトの名無しさん

2009/10/18(日) 10:04:42

＞COBOL が枯れているってホントかな。

とりあえずJavaみたいにJava1.4以降とかJavaSE6が必要とか
そういう心配はほとんどないな。

エンジニアも新しい事を覚える気はゼロだし。

0857デフォルトの名無しさん

2009/10/18(日) 10:40:38

すごくゆっくりではあるけど、一応新しい仕様は追加されてんだよな。
使わない（使えない／使わせない）だけで。
言語が枯れてるのかエンジニアが枯れているのかラインが微妙。

0858デフォルトの名無しさん

2009/10/18(日) 13:18:54

漏れのところだとCOBOLのプログラム修正とかをステップ管理しているんだから、
ある種、効率の悪い言語の方が工数とかブン取れるのでCOBOLは老人にとっては美味しい
メシの種だろう。

とりあえずエンジニアが枯れているので、言語が枯れてしまったのだろう。

スレチだがパンチカード言語(?)のRPGがIBMによって未だに進化し続けてるのが怖いわ。

0859デフォルトの名無しさん

2009/10/19(月) 00:44:10

IBMはRPGにもう期待してないでしょ

0860デフォルトの名無しさん

2009/10/22(木) 22:08:06

IBMが期待しているかどうか知らんが、構造体っぽいのをサポートしたり、
servletの様に呼び出せたり、Cの関数呼べる様にしたり、Javaのクラスのメソッド呼び出せたり、
SQLのスカラー関数記述出来たり、ストアド化できたり、xml解析したりと、老害には追従不可能な
進化しているな。

外国の一部のエンジニアは好んで使っているフシがあるが、日本はてんでダメだろう。

0861デフォルトの名無しさん

2009/10/22(木) 22:10:36

へぇそうなんだ。
生産性でいったらRPGかなりいいもんな。

XML解析とか、SQLなら日本じゃJavaとか.NETに行くんだろうね。普通

0862デフォルトの名無しさん

2009/10/25(日) 06:48:24

昔はRPGといえば宣言型言語の嚆矢みたいに言われたものだけど、
最近は手続き型に分類されてるね。デシジョンテーブルを使った
プログラミング言語という評価が適切でないくらい、いろんな
要素を取り込んでしまったということかな。

0863デフォルトの名無しさん

2009/12/01(火) 01:31:00

JavaってWebやらないかぎり
viでシコシコ作ってるほうが楽なんだよな。

0864デフォルトの名無しさん

2009/12/12(土) 11:00:39

すげぇなviでシコシコだなんて、
emacsならまだしも、俺には無理だ。

３クラス位までしか楽にコーディング出来ないな。

>>860
最新のIAサーバ/AS400とか買わないといけないのか？
無論、古いマシンでは動くはずもないし、
無償のx86版のAS400とかRPGコンパイラとか出てくれれば普及するんだろうけどね。
開発するにしても難しいのでは？と思う。

新旧資産を使いこなすには、それなりの設計が必要そうだね。

0865デフォルトの名無しさん

2009/12/12(土) 13:44:35

>>864
> AS400
もう作ってないだろ

0866デフォルトの名無しさん

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モデルが出る予定。

0867デフォルトの名無しさん

2009/12/12(土) 18:16:17

sage進行ｗ

>>866
もうAS/400とは言わないのか。

ところで
①Java1.4(JBuilder6) ⇒ Java 6(Eclipse)
②COBOL85(HITACHI製)⇒COBOL2002(HITACHI製)の
おまいらならどっち選ぶ？

0868デフォルトの名無しさん

2009/12/12(土) 22:09:22

COBOLのCALLみたいにロードモジュールを呼ぶのって、Javaではどうすればやれるんですか？

0869デフォルトの名無しさん

2009/12/13(日) 13:11:16

java.lang.Runtimeで直接叩くか、JNL使うんじゃね？
直接COBOLのロードモジュールは読めないと思う。
JavaとCOBOLの間にCプログラムのラッパーを作ることで出来るとはず。

ちなみにJava ⇔ COBOL間なら
Java Servlet←プロセス間通信→Cサービス←メモリ共有→CのDLL＋COBOLのプログラムmake時にリンク
とかなり手数のかかる手法を見たことある。

0870デフォルトの名無しさん

2009/12/13(日) 20:59:18

>>864
viもちゃんと戦えるんだぜ
コマンドは大量に覚えることになるが
…っつってもそこはemacsも同じか

0871デフォルトの名無しさん

2009/12/13(日) 22:23:13

>>868
それが何ものかわからんから、何とも言えない
コボラーって、COBOLの用語でしか語らないから、何も分からんのだよ

メモリ上でどういう操作になるのか説明してほしいんだが

0872デフォルトの名無しさん

2009/12/15(火) 00:29:59

まぁいわゆるインスタンスを生成して、呼び出すってことが正解なんじゃねーの？

0873デフォルトの名無しさん

2009/12/15(火) 00:49:04

それだとPERFORMに近いな。

0874デフォルトの名無しさん

2009/12/15(火) 00:52:24

外部モジュールに当たるものが、.classなのか.jarなのかわかんね～。

0875デフォルトの名無しさん

2009/12/15(火) 00:55:23

COBOLER?

0876デフォルトの名無しさん

2009/12/15(火) 01:14:04

>> 873
たぶんその回答だと意味がわかっていないと思うな。

0877デフォルトの名無しさん

2009/12/15(火) 20:17:18

>>874
あぁ読む人によってはそう見えるね。
Javaで外部ライブラリ読むってことだったのか。

それだったら環境パスにライブラリ置いてimportしろってね。
てっきりDLLかEXEと思ってたよ。

0878デフォルトの名無しさん

2009/12/15(火) 23:14:40

クラスライブラリを使うのとCALLはだいぶ違うだろ。

0879デフォルトの名無しさん

2009/12/16(水) 19:52:01

COBOLをどのOSのもとで使ってるかで違ってくろるだろうな。
IBMのメインフレームのアーキテクチだったら、.
その例えはあってると思うけどな。

0880デフォルトの名無しさん

2009/12/25(金) 09:50:25

MOVE "HOGEORDER" TO MYMEMORY-ORDER.
MOVE "FUGADATA" TO MYMEMORY-DATA.
CALL "MYUTIL" USING "MYMEMORY".

MyUtil.order("fugaData");

0881デフォルトの名無しさん

2009/12/29(火) 00:44:22

Javaから入ったから逆にCOBOLが全然読めないｗ

0882デフォルトの名無しさん

2009/12/29(火) 01:53:37

>>881
読めないじゃなくて読む気がねぇだろう

おれはもう40代だ
しかし、COBOLからjava、.netまで面倒をみている。
言語の特性をつかめ

0883デフォルトの名無しさん

2009/12/29(火) 13:41:51

>>882
言語の特性をつかめって、COBOLの知識が前提の話な。
代わって>>882を日本語に１行に翻訳すると、「COBOLの勉強しろよ。」

>>880はどうやってインスタンス化してるの？
class.getName("xxx.xxx.xxx.MyUtil");か？

またどうやってロードしてるの？
xxx.xxx.xxx.MyUtil.classを環境フォルダに置いているだけなの？

初めてのケースだから手順が全く読めん。

0884871

2009/12/29(火) 14:43:40

OSのアーキテクチャに依存して言語仕様が決まっているなんてバカな話はありえない。

しょうがないから調べたよ
http://docs.hp.com/cgi-bin/doc3k/B3150090013.11820/167

CALLは、（まだメモリにロードされていない）外部プログラムを呼び出す。
CALL "FOO" のようにリテラルも書けるし、CALL $VAR のように変数も書ける。
→ 実際にプログラムが動くまで何が呼ばれるか分からない。

0885デフォルトの名無しさん

2009/12/29(火) 18:58:02

>>882さんみたいのが、勝利者だと思ふ。
以外にCOBOLのシステムをJavaでリプレースする案件が、
貴重だったりする。

0886デフォルトの名無しさん

2009/12/29(火) 22:52:58

>>885
そこまで読めないだろ。
COBOLをJavaにリプレースするなんて話、
何所から沸いてきたんだ？

0887デフォルトの名無しさん

2010/01/26(火) 22:07:56

>>884
>CALLは、（まだメモリにロードされていない）外部プログラムを呼び出す。
リンケージによるんでないの。

0888デフォルトの名無しさん

2010/05/03(月) 13:53:25

すいません。教えていただきたいのですが、
javaからRuntimeでcobolのexeは実行できるのでしょうか。
御忙しいとは思いますが御教授していただけないでしょうか。

0889デフォルトの名無しさん

2010/05/03(月) 14:04:06

>>781
逆にＣＯＢＯＬより悲惨だと思うよ。
ＣＯＢＯＬは、プロシジャーの問題だけだけど、
ＪＡＶＡの場合、フレームワークが提供されなくなった、
古くなったで、もうね、悲惨も良いところ。

0890デフォルトの名無しさん

2010/05/03(月) 20:53:41

>>888
できる

0891デフォルトの名無しさん

2010/05/04(火) 12:15:34

COBOLのマイグレーションってたいへんなの？

0892デフォルトの名無しさん

2010/05/05(水) 08:57:45

>>891
COBOLというよりオブジェクト指向のみで構造化プログラムは全く未経験の人には相当つらいみたい・・・。
この前入社してきたJAVA/C++暦10年以上の人間にCOBOLで組んでもらったら完全にバンザイしていた。

彼曰く、「JavaやC++なら必要な機能はメソッドなり関数なりで大抵用意されているからそれらを組み合わせるだけで
大抵組めるが、COBOLはそれらも含めて全部コードを書かないといけないから、とてもじゃないけど組めない。」　だそうな…。

0893デフォルトの名無しさん

2010/05/05(水) 15:01:01

>>892
それは構造化プログラミングとか、オブジェクト指向とか関係ない問題だな。
コボラーは何でもそういう語り方するよな。だからダメなんだ。

便利なフレームワークがあろうが、充実したクラスライブラリがあろうが、
足りないものは出てきて、そいつらはスクラッチで作るしかない。
それはアセンブラから超高級言語まで等しく同じ。言語パラダイムも関係ない。
出来ないと言ってる香具師は、単にタコなだけ。

>>891
COBOLは関数のような重要な抽象化機構の導入が著しく遅れていて、
全部グローバル変数＆サブルーチンだけで書けという点がひどすぎる。
つまり、可読性と保守性が著しく悪い。

ローカル変数はプログラムを書く上でとても重要で、アセンブラでさえ
レジスタやスタックがローカル変数として機能するから、
COBOLはアセンブラ以下のクソ言語。

0894デフォルトの名無しさん

2010/05/05(水) 16:07:42

マイグレーションってCOBOL2002でやらないの？

0895デフォルトの名無しさん

2010/05/05(水) 16:09:58

PC-COBOLとメインフレーム系のCOBOLで捕らえ方が違うかもしれんね。

0896デフォルトの名無しさん

2010/05/05(水) 16:11:57

セクションじゃなくてサブモジュールを使えばいいだけじゃないのかな。

0897デフォルトの名無しさん

2010/05/05(水) 17:11:36

○○が使えないからこの言語はクソ、みたいに言語の一部分だけをとらめえて完全否定するあたり
>>893から激しくコボラー臭がするんだけとw

この前も連中、Numeric型の変数が使えない、戻り値が一つ指定出来ないからJAVAはクソ、とか言って
COBOL以外の言語を全否定していたわ。まあ色々突っ込みたかったけど、触らぬ神になんとやらでスルーしたけど…。

あとCOBOLは保守性が悪いってよく耳にするが、そんなこと言っているのは一部のコボラーだけだそ。
あんなもんただ単に自分がやっている仕事の大変さをアピールするために誇張して言っているだけ。

確かにボリュームだけはでかいから慣れない間は面食らうが、慣れりゃどうってことはない、
ただボリュームがでかい、ただそれだけのこと。

そもそも可読性や保守性なんて作り手の技量の問題で言語はあまり関係ない。

0898デフォルトの名無しさん

2010/05/05(水) 19:27:20

どうでもいいけど、「COBOLは全部グローバル変数」ってのは違うぞ。
広く使われている第3次規格（というか、COBOL85）で、サブルーチンを
外PERFORMで呼ぶのではなく、プログラムを入れ子で作成し、外側
プログラムから内側プログラムをCALLすることができる。
この場合、外側と内側の変数スコープは切り離される。

0899デフォルトの名無しさん

2010/05/05(水) 19:57:20

>>898
それは初めて知ったけど、実際にどのくらい使われてます？

0900デフォルトの名無しさん

2010/05/05(水) 21:16:08

>>899
20年位前のシステムならともかくここ10年に構築されたシステムは結構つかわれているけど?
もしかして世間ではあまり使われていないのかな…。

0901デフォルトの名無しさん

2010/05/05(水) 21:21:42

なぜか純血コボラーはプログラムをモジュルー化するのを物凄く嫌うんだよなぁ…。
以前、機能ごとにモジュール化することを提案したら目上のコボラー共に総出で叩かれたよ…orz

0902デフォルトの名無しさん

2010/05/05(水) 21:25:58

帳票毎単位のモジュール化を提案しなかったお前が悪い。

0903デフォルトの名無しさん

2010/05/05(水) 21:38:16

モジュール分割って普通にSEの仕事じゃないのかな。

0904デフォルトの名無しさん

2010/05/06(木) 20:03:46

>>903
> モジュール分割って普通にSEの仕事じゃないのかな。
プログラマの仕事だが、コーダーの仕事ではない。

0905デフォルトの名無しさん

2010/05/06(木) 20:05:54

いまどきは設計者もプログラマーも一緒
設計しかできないってのも意味がないと思うけどね

0906デフォルトの名無しさん

2010/05/06(木) 20:07:19

そりゃコーダーは何も考えないでただ指示された作業をこなすだけだからな。
いわば土方と一緒…。

0907デフォルトの名無しさん

2010/05/06(木) 20:18:34

>>897
俺は>>893に一票。
というか、あんたがCOBOLERじゃないの？

> あとCOBOLは保守性が悪いってよく耳にするが、そんなこと言っているのは一部のコボラーだけだそ。
> あんなもんただ単に自分がやっている仕事の大変さをアピールするために誇張して言っているだけ。

いや、確かにCOBOLは保守性が悪いよ。Dijkstra先生も認めていらっしゃる。
プログラマによっては多少マシになるが、二度と保守したくないと思うには充分な糞さ。
PROCEDURE DIVISION. が30000行を越える糞ソースを修正したときそう思った。

> 確かにボリュームだけはでかいから慣れない間は面食らうが、慣れりゃどうってことはない、
> ただボリュームがでかい、ただそれだけのこと。

自分で１から組めればそうかもね。
だけど、現実はつぎはぎだらけのソースを修正する仕事ばっかりで、新規案件なんてほとんどない。

> そもそも可読性や保守性なんて作り手の技量の問題で言語はあまり関係ない。

技量を伴ったCOBOLERが少なすぎるってことかな。

0908デフォルトの名無しさん

2010/05/06(木) 20:39:51

>>907
>>993=>>907
自演乙w

0909デフォルトの名無しさん

2010/05/06(木) 20:45:19

>>908=>>897だろw
なんか反論あるなら、聞いてやるからレスしてみ？

> >>993=>>907
半年先までこのスレにいるかどうかなんてわからんよ

0910デフォルトの名無しさん

2010/05/06(木) 20:54:06

>>909
ただのネタ振りでそこまで必死にならんでも…。

ごめんよ・・・まさか本当に>>907が>>993否w>>893本人とは思ってもみなかったわw
あと>>897にも余計な濡れ衣を着せさせてしまってなんか悪いことしたなw

0911デフォルトの名無しさん

2010/05/06(木) 20:55:27

気にするな。

0912デフォルトの名無しさん

2010/05/06(木) 20:57:10

なんかいつのまにかコボラーに苛められて心が病んでしまった人が集うスレと化してきたなぁ。

0913デフォルトの名無しさん

2010/05/06(木) 20:58:24

コボラーが苛めることのできる奴ってのが想像できん

0914デフォルトの名無しさん

2010/05/07(金) 05:48:29

COBOLの問題点の一つに、共通にすべきところを関数とかで共通にできない、
あるいはしにくいから、既存のプログラムをコピーしてちょっとだけ違うものを
大量に増殖させて、いざ修正となると、横並び修正とかやってるじゃん。

こんな言語のどこが保守性がいいんだよ。言語の冗長さが招いた弊害。
内部プログラムじゃ、結局引数の設定とか面倒だし、
こんなんじゃ使われないだろうな、と思うよ。

>>913
前のプロジェクトでは散々文句言ってやったが、コボラーをいじめても
あいつら何も変われないから面白くないよ

0915デフォルトの名無しさん

2010/05/07(金) 19:05:22

>>914
それはCOBOL言語の問題というよりコボラーの問題だと思う…。

以前コボラーにJAVAで組ませてたら10000ステップ超えのメインクラスを自信満々に組んできおったわw

0916デフォルトの名無しさん

2010/05/07(金) 20:45:56

コボラーの手に掛かればJavaだろうがC++だろうがC#だろうが、全てCOBOLチックなコードになるからな…恐るべしw

0917デフォルトの名無しさん

2010/05/07(金) 21:24:04

そういう奴らってCALL知らないのか？

0918デフォルトの名無しさん

2010/05/25(火) 14:59:59

COBOL誕生50周年
http://iiyu.asablo.jp/blog/2010/05/25/5111701

0919デフォルトの名無しさん

2010/06/04(金) 18:48:03

>>915
> 以前コボラーにJAVAで組ませてたら10000ステップ超えのメインクラスを自信満々に組んできおったわw

いろんな意味で、さすがコボラだと関心すらした。

0920デフォルトの名無しさん

2010/06/06(日) 19:28:23

>>914
リプレース案件なんかだと、既存バグでたまたまそうなってるだけの計算結果であっても、
システム側の都合で勝手に数字を変えられないので、バグ結果を再現させたり、
本来共通化できるはずのところも実装方法とその結果が微妙に違ってて共通化してはいけなかったり
ホント負の遺産意外の何者でも無い‥

0921デフォルトの名無しさん

2010/06/06(日) 21:28:17

コードの不良債権ってやつだな。
結局、長年に最適な状態で保守していなかったのが原因で、
リプレースが原因ではなかろう。

そういうところはリプレースが原因と言い放ちそうだが、
まぁいかんせん当時作った人間がいないから、
何故そうなのかというのがわからんことはあるよな・・・わりとそういうのあるから気持ち悪いがｗ

0922デフォルトの名無しさん

2010/11/27(土) 18:06:05

保守して評価されるならやるけどさ、
俺の職場じゃ手を入れても何の評価もされないし、
手を入れたプログラムが落ちてたらデータの使用者から
何勝手にいじくってんだって電話来るぞ。

だから極限まで触らない。

0923デフォルトの名無しさん

2010/12/21(火) 02:23:34

俺もコボラーだけど、10000ステップ越えのプログラムやgoto文の嵐には殺意が沸く。

0924デフォルトの名無しさん

2010/12/22(水) 03:28:27

>10000ステップ越えのプログラム
なんてざらじゃないか？
10000ステップ越えのサブルーチンなら頭抱えるがw

0925デフォルトの名無しさん

2010/12/22(水) 07:27:47

横長データベース、ファイルシステムなら
データの取得、作成だけで数百～千行くらい行くからね。
それにデータチェックが加わればコード量２～３倍くらい膨れ上がるし。

それでも1万行は詰め込みすぎだと思うけど。いやよく見るけどさｗ
もう少しモジュール分割しろよっていう。
少なくともファイルアクセス部分（いわゆるDAOに当たる部分）を外出しモジュール化するだけで↑の例はだいぶすっきりするはず。

0926デフォルトの名無しさん

2011/02/17(木) 20:22:21

奴隷は、奴隷の境遇に慣れ過ぎると、驚いた事に自分の足を繋いでいる鎖の自慢をお互いに始める。
どっちの鎖が光ってて重そうで高価か、などと。そして鎖に繋がれていない自由人を嘲笑さえする。
だが奴隷達を繋いでいるのは実は同じたった１本の鎖に過ぎない。そして奴隷はどこまでも奴隷に過ぎない。

過去の奴隷は、自由人が力によって征服され、やむなく奴隷に身を落とした。
彼らは、一部の甘やかされた特権者を除けば、奴隷になっても決してその精神の自由までをも譲り渡すことはなかった。
その血族の誇り、父祖の文明の偉大さを忘れず、隙あらば逃亡し、あるいは反乱を起こして、
労働に鍛え抜かれた肉体によって、肥え太った主人を血祭りにあげた。

現代の奴隷は、自ら進んで奴隷の衣服を着、首に屈辱のヒモを巻き付ける。
そして、何より驚くべきことに、現代の奴隷は、自らが奴隷であることに気付いてすらいない。
それどころか彼らは、奴隷であることの中に自らの唯一の誇りを見い出しさえしている。

(リロイ・ジョーンズ　1968年、NYハーレムにて)

0927デフォルトの名無しさん

2011/03/08(火) 16:46:51.10

どこかにないかなねぇ、ＣＯＢＯＬの仕事

0928デフォルトの名無しさん

2011/03/09(水) 22:11:56.77

COBOLは古くから基幹システムに多く見られたけど（バッチ処理・帳票作成・O/Lマスタ更新etc）
現時点において未だにリビルドしないで運用してる企業は無いと思うんだけどな。

そこら辺ってどうなん？

データウェアハウス(ETL)なんてのが数年前から当たり前のように使われているのに
基幹システムに何ら手を加えないで、I/Fトランスのみで取り込みしてるとは思えないんだよね。
データが誇大で大量であるのは認めざるをえないけど、今時のサーバ系統のCPUなんてのは
大型のCPUとか処理能力に負けないと思うけどね、それにHDD自体もビルのフロア一杯に
大型ロッカーみたいなモノ敷き詰めなくてもコンパクトに成っていると思うしね。

まあ俺なんかも昔は古臭いコボラー出身だったけどなｗ
俺がSEやってた時なんてのは16年も前のことだからな、今はWeb関連の小さな会社持ってるけど
当時を振り返ってみると、止める時期に丁度、再構築のプロジェクトが発足するとかしないとかの
噂が流れてたときだったな一部の社内システムで移行テストなんかのプロジェクト要員に
選ばれるかどうかという話も出てたが、これからは違う道を歩みべきと思って断ったけどね。

当時でも昔からの遺産を大事に壊さないように、仕様変更の度にデグレ出ないようにと気を使ったけどね。
うまく処理してる所が異常でると、何万ステップとも思える遺産を深いネストと馬鹿みたいにデカイ
サブRTNを追いかけ回さないといけないからねｗ
一番やっかいなのが仕様書が修正履歴で何倍にも膨れ上がってて、ソース見たほうが早いかもよと
先輩によく言われたことがあったｗ
まあ、再構築するにしても、基盤整備（システムフロー・ドキュメントとか現状ソースとのすり合せ等）から
始めないと手のつけようが無いというか、処理を零してしまう恐れが多々起こるような感じだった。
まあ、遺産なんでね、修正仕様が反映されていなかったりするのも意外と多いんだよね。

だから再構築といっても、コストとリスクを考えると中々手が出せなかったのは覚えているけどね。
とにかく当時は、巧くいってる物はムダに触るなと言ってる上の連中が多かったからなｗ
今、どうなっているんだろうな、なんとなく見てみたい気がするｗ

0929デフォルトの名無しさん

2011/03/09(水) 23:04:28.22

>>928
浜松町にある会社につとめてた？

0930928

2011/03/09(水) 23:17:32.68

ObjectWorks+ を造った会社に居た事はあるｗ

0931デフォルトの名無しさん

2011/03/09(水) 23:28:08.77

ＩＴは時代とともにニーズが変わるからね。
いつまでも古い遺産を抱えていてはビジネスにマイナスの影響がでる。
定期的に変えていくことが正解

0932デフォルトの名無しさん

2011/03/10(木) 07:25:10.50

COBOLでもなく、Javaでもなく、Rubyが至高の言語

0933デフォルトの名無しさん

2011/03/10(木) 21:51:07.43

ＣＯＢＯＬは画面系はまったく弱い

0934デフォルトの名無しさん

2011/03/11(金) 00:08:22.36

言語も重要だけど開発環境の良しあして大きいと思う。

0935デフォルトの名無しさん

2011/03/11(金) 02:34:01.51

>>931
要件定義まで巻き戻してン億～ン十億投じる覚悟のある奴はあんまりいない。

「できるかできないかわからない新システムに投資」って不安 + 「新機能の追加が遅れる」マイナスの影響
と
「既存のシステムを継ぎ接ぎして動く保障の高いシステムを動かす」安心感

のどっちがユーザーにとって感情的に満足できるかっつったら後者らしい。
どっちがマシ？　というレベルの話だけどな。

ユーザーから見たらぶっちゃけソフトそのものなんてどうでもいい。
一関数一万行のCOBOLコードがあろうがなかろうが関係ない。
ソフトを使うことによる効率化の成果が欲しいわけ。

0936629

2011/03/11(金) 17:52:42.83

>>930
あんたとリアルの知り合いのような気がしてきた（笑

0937928,930

2011/03/12(土) 22:49:53.87

>>629
ほんとかよ、まあ、当時は意外と面白い連中が多かったけどな。
実は、証シス1部にも居た事はあるｗ

アンタは？

0938928,930

2011/03/13(日) 21:58:27.25

>>629

よ、アンタは？
俺は、その後に懐かしの国際証券とNTT（浜松町）で仕事を請負でやったことはあるけどね。

0939デフォルトの名無しさん

2011/04/09(土) 17:08:07.40

>>926
プログラマーも奴隷だな。
人は皆、金の奴隷だ。

0940デフォルトの名無しさん

2011/05/31(火) 07:57:27.44

仕事があれば奴隷でもいいよ。

0941デフォルトの名無しさん

2011/05/31(火) 10:23:14.64

対価がもらえれば奴隷でかまわない

0942デフォルトの名無しさん

2011/06/07(火) 17:32:25.07

奴隷の方が、仕事も睡眠時間も食事の時間も決められててマシだよ
って大学の助手が言ってた

0943デフォルトの名無しさん

2011/06/07(火) 17:41:44.95

奴隷の監督は酒池肉林どころか
明日は我が身の中間管理職だからな。
責任だけがのしかかるという。

0944天使 ◆uL5esZLBSE

2011/07/05(火) 20:00:39.41

↓↓↓
[[[[[[[[ ほんとかよ、まあ、当時は意外と面白い連中が多かったけどな。 ]]]]]]]](爆ッッ
↑↑↑↑↑↑↑(←嘲ッッッッ笑ッッ！！爆笑ッッ!笑!!
↓↓↓
[[[[[[[[[ 実は、証シス1部にも居た事はあるｗ ]]]]]]]]]（←爆ッッッッ笑ッ!!爆ッッッッ笑ッ!!爆ッッッッ笑ッッ！！

0945↑

2011/07/20(水) 11:12:39.20

幼稚園児か・・・

0946デフォルトの名無しさん

2011/08/12(金) 09:11:04.17

>>944
何が、そう、君を、そう、させるんだー！

0947デフォルトの名無しさん

2011/12/22(木) 22:58:51.23

COBOLCOBOLCOBOLC
OBOLCOBOLCOBOLCO
BOLCOBOLCOBOLCOB
OLCOBOLCOBOLCOBO
LCOBOLCOBOLCOBOL

0948デフォルトの名無しさん

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

0949デフォルトの名無しさん

2011/12/23(金) 04:01:35.91

Cool Cool Cool

0950デフォルトの名無しさん

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

0951デフォルトの名無しさん

2012/03/02(金) 00:35:23.23

うん

0952デフォルトの名無しさん

2012/09/09(日) 18:14:04.04

まだ>>９５０みたいなことをネタで言ってる奴がいるのかというｗ

0953デフォルトの名無しさん

2012/09/16(日) 12:00:25.25

少しスレチだがJava 6のリファレンスが遂に無くなったな
アクセスするとOracleのトップに飛ばされる
どうやらJavaは本格的にEnglish onlyになるらしい

0954デフォルトの名無しさん

2012/10/14(日) 19:49:33.04

>>953
http://docs.oracle.com/javase/jp/6/api/

0955デフォルトの名無しさん

2012/12/12(水) 21:18:35.85

ハロワで26歳無職ニートがCOBOLラン系の職につこうとしているので
アドバイスください。

0956デフォルトの名無しさん

2013/01/18(金) 19:27:04.02

知識よりも上司との人間関係や体力

0957デフォルトの名無しさん

2013/11/04(月) 18:16:44.71

保守age

0958片山博文MZコスモ ◆T6xkBnTXz7B0

2013/11/06(水) 03:59:17.55

COBOLのプログラムをJAVAに移植するのに役立つライブラリは何でしょうか？

0959デフォルトの名無しさん

2013/11/06(水) 16:36:15.39

>>958
http://toro.2ch.net/test/read.cgi/tech/1316444803/352

0960デフォルトの名無しさん

2014/04/02(水) 06:24:59.22ID:YuPkVvCA

20年くらいCOBOLしか触ってないおっさんがJAVAの入門書みて勉強してるんだけど
なんか作る気にならんとやる気でないね(´･ω･`)

0961デフォルトの名無しさん

2014/04/02(水) 06:50:22.09ID:UxJPt08w

COBOLのコンパイラとか

0962デフォルトの名無しさん

2014/04/02(水) 08:14:53.44ID:GIdJz2NO

モチベーションの源はエロだよ
静止画でも動画でもいい、自分用のエロDBを作ってみるんだ

0963デフォルトの名無しさん

2014/06/05(木) 01:32:37.38ID:wuUUC+ej

>>960
(´･ω･`)入(´･ω･`)ﾅｶｰﾏ

0964デフォルトの名無しさん

2014/06/08(日) 07:54:35.39ID:3YpOp6yu

自分も20年位のCOBOLERだけど、何か目的が無いと
全く勉強が進まない。
最近はフリーウェアなりシェアウェアなりでかなり便利な
ツールがあるからそれを上手に利用するのが良いですね。
物作りに携わってきた人間としては寂しいですが。
汎用機のCOBOLERがPCで何か作ろうとすると、OpenCOBOL
って有効なツールなんだろうか？

0965デフォルトの名無しさん

2014/07/14(月) 22:40:28.27ID:4A74nF8C

>>963
ムカツクw

0966デフォルトの名無しさん

2014/07/16(水) 16:38:00.99ID:FUxHai3/

(´･ω･`)←最近見かけるＡＡだが、これ見るとむかつく。今後一切禁止だ。わかったな。

0967デフォルトの名無しさん

2014/07/16(水) 17:45:26.19ID:VVSFNUoz

あい(´･ω･`)

0968デフォルトの名無しさん

2014/07/17(木) 17:23:13.85ID:uZH0ckts

>>966
わかった(´･ω･`)

0969デフォルトの名無しさん

2014/07/18(金) 16:21:03.21ID:dLPMex84

(´･ω･`)

0970デフォルトの名無しさん

2014/07/19(土) 15:53:33.07ID:Cwdz+lv0

(´･ω･`)

0971デフォルトの名無しさん

2014/07/20(日) 10:40:06.76ID:3pOnY1IX

(´･ω･`)

0972デフォルトの名無しさん

2014/07/21(月) 11:58:40.02ID:BmFMTb9i

(´･ω･`)

0973デフォルトの名無しさん

2014/07/21(月) 14:11:52.55ID:U2gOsErh

(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)
(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)
(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)
(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)
(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)

0974デフォルトの名無しさん

2014/07/21(月) 14:13:25.76ID:BmFMTb9i

0975デフォルトの名無しさん

2014/07/21(月) 23:06:50.93ID:j5G8Tlmh

(´･ω･`)禁止かー

0976デフォルトの名無しさん

2014/07/22(火) 12:04:32.46ID:havteLkU

>>975
(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)
(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)
(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)
(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)
(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)

0977デフォルトの名無しさん

2014/07/23(水) 11:49:24.60ID:jFdfy/1M

0978デフォルトの名無しさん

2014/07/24(木) 12:25:36.82ID:RQB1t2Re

0979デフォルトの名無しさん

2014/07/25(金) 11:53:17.67ID:RkXLEhxK

0980デフォルトの名無しさん

2014/07/26(土) 11:43:06.60ID:J2SMgHsx

0981デフォルトの名無しさん

2014/07/26(土) 11:43:33.11ID:J2SMgHsx

レス数が950を超えています。1000を超えると書き込みができなくなります。