【コボル】COBOL不要論【ただのDSLだよね？】

1 ：デフォルトの名無しさん：2011/09/20(火) 00:06:43.84

COBOLでCOBOL書ける?

2 ：デフォルトの名無しさん：2011/09/20(火) 00:13:54.24

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

3 ：デフォルトの名無しさん：2011/09/20(火) 00:44:05.18

まさかの次スレ
前スレの名物困ったちゃん来るかなー

4 ：デフォルトの名無しさん：2011/09/20(火) 01:03:57.80

前スレ
【コボル】COBOL不要論【いらない】
http://hibari.2ch.net/test/read.cgi/tech/1248937976/

とりあえず出てた話題とか適当にピックアップ
・コボラーにかかれば基本情報で出てくる正規化をすればバッチ処理はいらないらしいよ。凄いね(繰り返し出た話題
・なにがCOBOLだ。Java+swingなんか冗談だろ、時代はVBだよ。なにせWindows Formsだ。一味違うぜ。HTMLなんかじゃ表現力が足りません。
・んなこたないJS凄いぜいやFlexだドットネットだと喚く方々の登場後うやむやに
・PCサーバと仮想化で全部解決。メインフレームは遺物。

概ねこのあたりから適当に気になったところ突けばCOBOL関係なくても回るスレだったようです

5 ：デフォルトの名無しさん：2011/09/20(火) 01:24:31.28

まだ不毛な主張を続けるのかよ。

6 ：デフォルトの名無しさん：2011/09/20(火) 02:28:00.27

続けなくていいです

7 ：デフォルトの名無しさん：2011/09/20(火) 05:32:15.83

>>1
修士課程の同僚がFに入社したが、COBOLでCOBOLコンパイラ書いてるって泣いてたような

8 ：デフォルトの名無しさん：2011/09/20(火) 09:04:15.49

今時ライブラリも使えずプログラマーが自分でロジックを考えないといけない
時代遅れなCOBOLなんてもう要らない。

9 ：デフォルトの名無しさん：2011/09/20(火) 10:03:20.75

なに言ってんだお前

10 ：デフォルトの名無しさん：2011/09/20(火) 13:53:08.36

ライブラリがあると自分でロジック考えなくていいんだw

11 ：デフォルトの名無しさん：2011/09/20(火) 14:38:48.30

>>10
今時ロジックや仕様みたいな下衆な作業はプログラムが組めないゴミSEの仕事だろ。
技術の進歩についていけない老害は黙ってろｗ

12 ：デフォルトの名無しさん：2011/09/20(火) 14:55:33.81

そのライブラリは誰が作るんだよ

13 ：デフォルトの名無しさん：2011/09/20(火) 16:25:34.63

>>11
ゴミコーダーさん乙
はやくSEになれるといいね

14 ：デフォルトの名無しさん：2011/09/20(火) 17:40:30.56

>>13
＞はやくSEになれるといいね

落ちぶれてどうするw

15 ：デフォルトの名無しさん：2011/09/20(火) 19:39:21.86

いくらライブラリがあるからって、
SEやPEを介さずに一から十まで自動的に全部システムを構築できるのか？
そういう機能があるのならJavaのこと見直すかな。

16 ：デフォルトの名無しさん：2011/09/21(水) 01:54:55.57

SEがコーダーより給料低いとこってあんのかな？
いや、確かに給料問わず昇格して人生落ちぶれたように感じられる奴はまま見るけどなw

17 ：デフォルトの名無しさん：2011/09/21(水) 08:52:18.23

大体プログラムが組めないゴミSEがPGより報酬がいい事自体間違っている。

18 ：デフォルトの名無しさん：2011/09/21(水) 13:59:04.83

>>17
会社の不満は上司に言えよ。

19 ：デフォルトの名無しさん：2011/09/21(水) 14:14:55.36

プログラムが組めないゴミSEがここ監視してんのかな

20 ：デフォルトの名無しさん：2011/09/21(水) 14:17:55.79

そもそもよくプログラミングせずSEになれたなそいつ
そいつってコードも読めずに設計してんの？設計じゃなく机上の空論に終わりそうなもんだが、そういう才能でもあんのかね
>>17は気の毒だが

21 ：デフォルトの名無しさん：2011/09/21(水) 15:15:22.35

ここの住民はSEを知らんらしい。
SEが設計なんてする分けないだろ。受注活動から人材調達、稼働後の
フォローといった、お前ら対人恐怖症供には出来ない作業を
やるんだよ。
接待ゴルフとかしないだろ。

22 ：デフォルトの名無しさん：2011/09/21(水) 15:24:06.01

営業から企画に運用管理まで全部やらせてんのかw
そんなんじゃ最初の肩書きなんてもう飾りになってるんだろうけど
その方は労わってあげたほうがいいと思うw

23 ：デフォルトの名無しさん：2011/09/21(水) 15:46:07.21

>>21のところは悲惨だよねw
PMの仕事を全部肩書SEに任せてるんだから…。
SE単価で馬車馬のようにこき使われてるんだろな。

ああ、だから設計をプログラマがやってるのかwww

24 ：デフォルトの名無しさん：2011/09/21(水) 16:30:28.94

>>21
プログラマーに必要なスキルは仕様を正確にコード化する技術であって
対人コミュニケーションのスキルなんて全く必要ないと思う。
そもそも他人と関わりたくないからPGの職に就いたのに。

25 ：デフォルトの名無しさん：2011/09/21(水) 17:17:19.23

>>24
＞>>21
＞プログラマーに必要なスキルは仕様を正確にコード化する技術であって
＞対人コミュニケーションのスキルなんて全く必要ないと思う。

そのレベルの作業は機械化されていってるけどな。
第一、コード化技術だけで充分なら、ハッカーがプログラマーでもある事の説明が付かないだろ。

26 ：デフォルトの名無しさん：2011/09/21(水) 17:59:46.30

>>25
> 第一、コード化技術だけで充分なら、ハッカーがプログラマーでもある事の説明が付かないだろ。
意味不明

27 ：デフォルトの名無しさん：2011/09/21(水) 18:15:55.85

>>25の言いたいことがよく分からないけど
少なくてもプログラマにもコミュニケーション能力は必要。
システム設計したSEに質問したり、上司やリーダーに報告とかいろいろある。
システム屋だったら一人だけで仕事なんて無理でしょ。

28 ：デフォルトの名無しさん：2011/09/21(水) 18:19:03.20

スレ違い

29 ：デフォルトの名無しさん：2011/09/21(水) 21:04:33.77

>>27
別に仕様書通りにきちんと納期までにコーディングするだけだから他人とコミュニケーションを取る必要は無い。
仕様上の矛盾なんてそもそもPGの責任ではないし、知ったことじゃない。
またリーダーへの報告も完了若しくは遅延等の最低限の報告のみでいいと思う。

実際自分も職場で丸一日人と会話をしないことなんてザラだし、むしろ他人と馴れ合うとは好きじゃないからプログラマになった。

30 ：デフォルトの名無しさん：2011/09/21(水) 21:26:04.86

君もスレ違いでは
いや現場がCOBOLならいいんだけど

そのスタンスは長持ちせんよ。上はミスを棚に上げて「気付いたんなら相談してくれ舐めてんのか」とか「気付かないとか頭使ってんのかこっちも一杯一杯なんだよ」などと平気で言うぞw

無口にやりすぎると「メール送りましたよね」「見てねえよ口答えすんな」コンボも珍しくないからな
上っ面だけでも仲良くやってると期待

31 ：デフォルトの名無しさん：2011/09/21(水) 22:30:32.25

>>30
> 上っ面だけでも仲良くやってると期待
>

コボラーってそういったつまらない人間関係やコミュニケーションばかりに気をまわしているから
肝心プログラミングのレベルが低いんだと思う。
本来プログラマーってPそういった人間関係なんて気にしなくていい職業じゃないの？

32 ：デフォルトの名無しさん：2011/09/21(水) 22:30:35.50

>>29
ドライだね～
一番下っ端の立場ならそれでいいのかもしれないけど…

33 ：デフォルトの名無しさん：2011/09/21(水) 22:41:51.89

ＳＥと比べたら、プログラマーにコミュニケーション能力はいらないかもね。
お客さんや上司や他のエンジニアとか、交渉事は全部ＳＥに任せてしまえばいいんだから。
でも、プログラマのままだと、給料は増えないし、責任のある仕事も担当させてもらえない。
一生プログラマで生きていく方が大変でしょ。

34 ：デフォルトの名無しさん：2011/09/21(水) 22:43:34.22

仮に愛想笑いや上っ面の謝罪で面倒ごと回避できるならいくらでもやるぜ
浮いた時間で肝心のプログラミングレベルの向上に励むもよし、趣味に潰すもよし

でも人間関係のくだらなさは上っ面じゃ回避し切れないのよね

35 ：デフォルトの名無しさん：2011/09/21(水) 22:49:35.83

>>33
責任のある仕事って、失敗したら人格レベルまでこき下ろされて、成功したら上の手柄になるって奴の事だろ
願い下げだよ

36 ：デフォルトの名無しさん：2011/09/21(水) 23:04:18.74

>>33
そもそも勤続年数に応じて出世しないといけない、という日本固有の古臭い考えたかだそもそも間違っている。

37 ：デフォルトの名無しさん：2011/09/21(水) 23:51:32.09

もう少し具体的にCOBOLプログラミングの話ができないものかな。

38 ：デフォルトの名無しさん：2011/09/22(木) 00:07:59.10

>>36
出世しなくてもいいけど、給料も増えないぞ。

39 ：デフォルトの名無しさん：2011/09/22(木) 00:21:53.31

>>38
報酬は勤続年数に応じて増えないとおかしいだろ。出世しないと給料が増えないって日本ぐらいだろ。
つか常識的に考えて営業やSEなんかよりPGの方が優秀なんだからPGの待遇をもっと改善すべき。

40 ：デフォルトの名無しさん：2011/09/22(木) 01:05:07.77

>>37
COBOL自体が劣ってるのはもはや自明であり議論の余地が無い
よって次スレも不要だったのだが立ってしまった以上とにかく埋めようという皆さんの涙ぐましい努力の結果がこの流れなんです
わかってあげてください

41 ：デフォルトの名無しさん：2011/09/22(木) 01:13:34.94

最近落ち目で他言語から叩かれまくりのJava
そのJava使いが唯一叩ける相手がCOBOLなんです
哀れだと思うなら叩かれてあげてください

42 ：デフォルトの名無しさん：2011/09/22(木) 20:55:24.43

>>40
文字列領域はREC定義で取得するのでよいのだが、
極めて使いやすい文字列処理ライブラリが標準で提供されたら、
COBOLの用途は少しは拡がるものだろうか。

43 ：デフォルトの名無しさん：2011/09/22(木) 21:01:25.51

極めた所でCOBOLの上だろ？
まあプアなphpくらいは目指せるんじゃないの

44 ：デフォルトの名無しさん：2011/09/22(木) 21:28:30.64

でもなんだかんだで基幹業務系や社会インフラ等、我々の社会で重要なシステムは未だ殆どCOBOLだという現実…。

45 ：デフォルトの名無しさん：2011/09/22(木) 21:37:47.93

>>44
いやCOBOLが…、というより他の言語が稼動するフラットフォームがあまりにも脆弱過ぎるのが
いまだにCOBOLをのさばらせている要因だと思う。
特にWindowsServerなんて20年以上昔のメインフレーム以下の安定性・信頼性だからそういった社会インフラ系のシステムを
メインフレーム+COBOLからWindows系に置き換えたら社会全体で中国の高鉄のような事故が多発してヘタすりゃ人類が滅亡しかねないw

まぁ最近はメインフレームからLinuxへのリプレースという話はよく耳にするけど、開発言語は一体何を使っているんだろうね…。

46 ：デフォルトの名無しさん：2011/09/22(木) 22:52:45.29

COBOL

47 ：デフォルトの名無しさん：2011/09/22(木) 23:04:27.76

>>46
それはない!!
Linuxだと恐らくC++かJAVA若しくはRuby辺りだと思う。

48 ：デフォルトの名無しさん：2011/09/23(金) 00:26:16.42

COBOL卒業した人は、何言語やってるの？
Java？VB？

49 ：デフォルトの名無しさん：2011/09/23(金) 16:42:14.08

>>48
Prolog

50 ：デフォルトの名無しさん：2011/09/23(金) 16:50:31.52

>>49
COBOLを10年やったら移れるのはそれしかないな。

51 ：デフォルトの名無しさん：2011/09/23(金) 18:13:08.12

前のスレのSQL正規化の人は、多分月次処理などを実運用中にテーブルをさらに新規に作成し、
ボタン一つで処理するので、そもそもバッチやCRONという概念が無いのだろう。
であるから正規化や、バッチは必要ない、COBOLにWinFORMやHTMLのボタンが無い、と言っているのだろうと解釈した。
普通、正規化と言ったらDBの設計だと思うのだが、この方法はACCESS等では可能なのかもしれないが、
実際どうなのだろうか。

52 ：デフォルトの名無しさん：2011/09/23(金) 18:30:55.50

SEとコーダーとテスターの業務って全部一人でやるもんだと思ってたんだけど違うの？
分業してるとこあるの？

53 ：デフォルトの名無しさん：2011/09/23(金) 20:06:09.88

漏れはＣＯＢＯＬ→Ｃ→ＪＡＶＡ→Ｃ＋＋

54 ：デフォルトの名無しさん：2011/09/23(金) 20:07:13.66

漏れはＣＯＢＯＬ→Ｃ→ＪＡＶＡ→Ｃ＋＋→LabVIEW
だった

55 ：デフォルトの名無しさん：2011/09/23(金) 21:42:37.63

まあ、ATMシステムをCOBOL→JAVAに代える勇気はないわな。

科学技術計算もFORTRANがしっかり残ってるし、CやC++よりも
最適化が進んでる。ポインタとか使わないのが標準だから。

56 ：デフォルトの名無しさん：2011/09/23(金) 23:30:27.37

>>48
漏れは、C→VB6→COBOL→VB.NET→JAVAだよ

57 ：デフォルトの名無しさん：2011/09/24(土) 02:51:42.98

20年後にはJAVAプログラマがコボラの後継者になる予感。

58 ：デフォルトの名無しさん：2011/09/24(土) 03:32:03.58

20年かかってその位置づけなら定年まで食ってけそうだな
その頃Rubyとか存在しとるんだろか？

59 ：デフォルトの名無しさん：2011/09/24(土) 08:27:15.95

一昔前は「JavaがCOBOLに取って代わる」と言われていたけどCOBOLは未だ健在でJavaが先に消えてしまったな…

60 ：デフォルトの名無しさん：2011/09/24(土) 10:12:45.30

金融関連のホストを一掃しないかぎりCOBOLは残ります

61 ：デフォルトの名無しさん：2011/09/24(土) 11:39:07.49

>>60
金融系のホストを脆弱なWindowsに置き換えたら毎日のようにトラブルが発生して経済が破綻してしまう!!
((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

62 ：デフォルトの名無しさん：2011/09/24(土) 11:43:03.80

>>61
なんでWindows一択なんだ…。東証みたいにLinuxを使えば?

63 ：デフォルトの名無しさん：2011/09/24(土) 11:48:30.62

>>62
LinuxはVBが使えないから論外。

64 ：デフォルトの名無しさん：2011/09/24(土) 14:08:16.17

つまりVBといいたい為に書いてるのか。

65 ：デフォルトの名無しさん：2011/09/24(土) 14:56:55.55

鯖にVBで何を作るんだ

66 ：デフォルトの名無しさん：2011/09/24(土) 16:52:46.73

つか世の中のシステムなんてVB+SQLに十分リプレース可能だろ。
基本情報の例題やプログラミング・SQLの参考書を見れば判ること。

67 ：デフォルトの名無しさん：2011/09/24(土) 17:04:40.08

>>66
そうね。パソコンもヤフオクで13000円くらいでノートを落とせばいいし。

68 ：デフォルトの名無しさん：2011/09/24(土) 18:16:11.68

C#あるのにVB？

69 ：デフォルトの名無しさん：2011/09/24(土) 18:32:04.23

なんでよりにもよってVB

70 ：デフォルトの名無しさん：2011/09/24(土) 19:18:28.78

VBはSIerのデフォルトスタンダード

71 ：デフォルトの名無しさん：2011/09/24(土) 19:19:37.40

>>68>>69
むしろVBを選択しないのが不思議…。C#なんて実績も無いただのゴミ

72 ：デフォルトの名無しさん：2011/09/24(土) 19:42:11.55

>>70
ぷっ

73 ：デフォルトの名無しさん：2011/09/24(土) 20:03:19.76

釣りのつもりならまだRubyの方が脈絡あるような
ちょっと何から突っ込んでほしいのか分かりませんが、MS限定ならPowerShellもいいよとかネタ振ってみよう

74 ：デフォルトの名無しさん：2011/09/24(土) 20:49:43.64

>>70
おいおい…

75 ：デフォルトの名無しさん：2011/09/24(土) 20:51:31.58

>>70
m9（＾Д＾）プギャー

76 ：デフォルトの名無しさん：2011/09/24(土) 21:39:28.07

1.0～2.0の頃はC#のほうが断然よかったが
ここ最近はVBも結構頑張ってると思う。2010（4.0）だと、もうそんな大差はない。

いや、厳密にいえば機能的にC#のほうが上のものもあるが、VBと差が出るほどフルにC#を使いこなそうとすると、色々変態チックになりがちなんで
VBのほうがまだ現実路線のような気がしなくもない。

と、最近C#2010,VB2010と続けて、こじんまりとしたシステムを開発してみてそう思った。
まあ前述したとおり、使いこなしている人はC#のほうが魅力的なのかもしれないけど。ふつうに使う分にはC系の構文なのかベーシック構文なのかの違いしかない。

77 ：デフォルトの名無しさん：2011/09/24(土) 22:29:09.19

情報システム構築する上でC#で出来てVB.Netで出来ない機能ってある？

78 ：デフォルトの名無しさん：2011/09/24(土) 22:34:33.03

普通に使う時こそ記述能力や可読性が大事じゃないの？
なんか君にかかればJavaScriptやPythonも変態チックで済まされそうで怖いな
現実路線どうこうじゃなく、記述能力が低い言語に満足しちゃって井の中の蛙になってるだけかもよ

79 ：デフォルトの名無しさん：2011/09/24(土) 22:41:37.30

使いこなせて無いだけかも知れんが
少なくとも開発してて、「ちくしょうC#じゃなきゃだめだー」って頭抱える様な事はなかったよｗ

80 ：デフォルトの名無しさん：2011/09/24(土) 22:53:04.82

まあなにがいいたいかっていうと、みんなVBに悪いイメージ持ちすぎなんだよな。
たしかにVB6とドットネットの最初の頃は悪かった。あれは本当に悪かったと思う。
でもVBもアレから進化してんだぜ。COBOLスレで言うこっちゃないと思うがｗ

81 ：デフォルトの名無しさん：2011/09/24(土) 23:53:23.52

安心しろ
お前は間違いなくCOBOLスレに相応しい逸材だよ

82 ：デフォルトの名無しさん：2011/09/25(日) 00:03:56.23

VB.NETは進化して使いやすくなったが、
結果ちょっと機能の足りないC#になっただけという

83 ：デフォルトの名無しさん：2011/09/25(日) 00:13:16.61

ラムダ式とか頑張ってるのは分かるんだけどね
どうせILレベルで一緒の物が出来上がるのなら、素直に書けるC#選ぶな
好みの問題で可能性狭めてどうするのよ

84 ：デフォルトの名無しさん：2011/09/25(日) 00:18:41.21

>>79
さすがはVB厨。PHPしか知らん奴と同じ事言って恥ずかしくないのw
もちろんCOBOLしか知らない奴も長年同じ事言ってたのだが、流石に今では通用しない事に気づいて黙るようになった

85 ：デフォルトの名無しさん：2011/09/25(日) 00:20:41.36

うえ理論で言ったら負けざるを得ないよな>>VB.NET
おれもC#よりVBのほうが上とは思わないし。

ただまあ、CLIレベルで一緒のものが出来上がるってんなら、COBOL.NETとか、どうなのよっておもうけどな
それはまた別の話か。

86 ：デフォルトの名無しさん：2011/09/25(日) 00:33:20.83

>>84
給料変わらなきゃそれで問題ないのさ
情報工学突き詰めたいならこんなスレ煽ってちゃだめよ

もう俺には最近の言語はよう使えん
俺もHaskell本買ってみたけど、ジジイにはろくに理解できんかったわい

87 ：デフォルトの名無しさん：2011/09/25(日) 00:46:20.51

実際、PHPで困ったことないよ(^O^)／
VB？うーん、、、f^_^;)

88 ：デフォルトの名無しさん：2011/09/25(日) 00:47:46.59

実際VB2010とC#2010を比べて非難してんなら問題ないけど。



両方つかって批判してんの？

89 ：デフォルトの名無しさん：2011/09/25(日) 01:02:43.75

ASP.NETを否定する訳じゃないが、むしろなんでVB選定することになったのか聞きたいな
なし崩し的にC系で書けるならC#一択だ、となってしまった所も多いだろう
VB.NETの文法的な良さってなんかある？好みでいい

90 ：デフォルトの名無しさん：2011/09/25(日) 01:09:35.73

C系の文法ってそんな優れてますかね

91 ：デフォルトの名無しさん：2011/09/25(日) 01:10:03.78

>>88
なんで両方使ってるんです？
うちではドトネトの初期で古いVB開発しかできない人は一斉に切られた

92 ：デフォルトの名無しさん：2011/09/25(日) 01:13:35.21

>>91
へえ。なんで？

93 ：デフォルトの名無しさん：2011/09/25(日) 01:15:33.92

>>90
JSとかまで含めたら、優れてるというよりもっとも一般的って所でしょう。Macがいくらかっこ良くても、個人用途での実用性を考えたら結局買わないのと一緒。
Cそのもので言えばどこまで行っても高級言語の皮を被ったアセンブラ。だから価値があるってだけで、決して見やすくないしあれなら僕はまだフォーマットした括弧だらけlispの方が好きです。

94 ：デフォルトの名無しさん：2011/09/25(日) 01:17:56.55

>>91
Java外注にシフトしました。

95 ：デフォルトの名無しさん：2011/09/25(日) 01:20:12.58

identification


俺の事も思いだせこの野郎

96 ：デフォルトの名無しさん：2011/09/25(日) 01:47:40.71

C系の構文が見やすいってのも宗教っぽい気がするガの。ほんとかよ

97 ：デフォルトの名無しさん：2011/09/25(日) 01:49:42.78

プロだったら言語に依らず、お客さんの要望に答えろって事だ。
新規開発で言語選定が可能なら、
コストや保守のし易さとかユーザーサイドで考えて選定すべきだ。
俺がC++得意だからとか、そういった理由で選んじゃいけない。

98 ：デフォルトの名無しさん：2011/09/25(日) 01:54:19.84

どんなに他言語ユーザーが息巻いてても、結局COBOLでもVBでもlispでも家族養えてるのなら問題ない
暇作って勉強くらいはするがね
C#君は食えてるのかね

99 ：デフォルトの名無しさん：2011/09/25(日) 02:24:31.62

>>97
C++は喩えにしてもどうかと思う。いくら得意でも、よほどキツくパフォーマンス要求されなきゃ避けるよ
ゲームでさえ緩い部分はスクリプト多用してるんだから

100 ：デフォルトの名無しさん：2011/09/25(日) 04:58:20.17

十年以上COBOL後継の本命はJAVAだったのであり、そのJAVAキラーとして
MSが遅ればせながら投入したのがC#。.NETの中で唯一JAVAやCの上に行く
可能性を持っている。そのことを考えれば、今後、VBが事務処理で大展開なんて
ありえない。

101 ：デフォルトの名無しさん：2011/09/25(日) 06:43:47.63

>>100
でも結局JavaがCOBOLに取って代わることはなく、COBOLが生き残りJavaは消えちゃったんだよね…。
うちの会社なんて中途半端にJavaに移行してしまったから今大変なことになっている。

102 ：デフォルトの名無しさん：2011/09/25(日) 09:01:14.37

他の言語を使えないジジイのために.NETという仕組みがあってだな
COBOLでもVBでもIL吐いてくれる
メンテを誰がするかは知らん

103 ：デフォルトの名無しさん：2011/09/25(日) 10:00:37.13

C#使う位ならJava使うよ。

104 ：デフォルトの名無しさん：2011/09/25(日) 10:17:55.23

ドットネット開発なら個人的にはbooがいいと思う。誰も使ってないしネームバリューもないけど。
C#が持ち上げられてるのはよーわからん。

105 ：デフォルトの名無しさん：2011/09/25(日) 22:31:48.67

COBOLの基幹システムをJavaでリプレースしようってPJにちょっとだけ関わったんだけど
なかなか面白かった。
PJサイドはJavaしか知らない奴が大半、ユーザー（一応システム部門）はCOBOLしか知らない
ので、可変長の文字列？それって何？って感じで実装の話になると全く言葉がかみ合わないの。
まあ運良く途中で抜けられたんだけどそのPJ多分エラいことになったんじゃないかな。

106 ：デフォルトの名無しさん：2011/09/25(日) 23:16:55.07

「あのね、悪いんですがクラスとかよくわからないモノ使わないでくれませんか？」
「これJava移植作業なんですけど？」
「あーあー、なんでわっかんないかなー。そりゃねJavaならオブジェクト指向ですか。多分その方が格好いいんでしょうけどね、こんなん俺ら分からないの。そこんとこ分かってる？」
（分かってない事以外わかんねーよ）

107 ：デフォルトの名無しさん：2011/09/25(日) 23:23:19.86

つうかPJサイドCOBOL勉強しろよ

108 ：デフォルトの名無しさん：2011/09/25(日) 23:33:38.41

>>106
COBOLのリプレースでJAVAなんか採用するからそうなる。
IT業界のデフォルトスタンダードであるVBを使えば幸せになれたのに…。

109 ：デフォルトの名無しさん：2011/09/25(日) 23:47:05.27

道具が良くても使い方を知らなきゃただのゴミだわな。
むかし日本が途上国に井戸掘りの機械を買って与えたが、使い方がわからなくてずっと放置されたまんま、あいかわらず飢餓の国があるらしい。

110 ：デフォルトの名無しさん：2011/09/25(日) 23:59:58.67

>>108
おまえの発言は釣り臭がひどくてダメです

111 ：デフォルトの名無しさん：2011/09/26(月) 00:06:42.04

VBと聞いたら親の仇かのように噛み付く奴がいるね
そしてまたいつものように内容がない

112 ：デフォルトの名無しさん：2011/09/26(月) 00:21:09.75

VBは昔のクラサバ移行で痛い目にあってるエンジニアが多いからなあ。旧VBのほうだけど。
一度ついたネガティブなイメージは、なかなかどうしても拭いきれないんでしょう。

大概は↑でも語られてる通り、COBOLとの設計思想の相違からくる無理が祟っての事なんだが

今はその役目（汚れ役）をJavaに譲ったけど
Javaもそのうち（いまでもそうか）戦犯のように語られるんだろうなあ。

113 ：デフォルトの名無しさん：2011/09/26(月) 00:23:04.02

COBOLでもVBでもJavaでもいいけど
それしか知らないアホがいるからイメージ悪くなる

114 ：デフォルトの名無しさん：2011/09/26(月) 02:56:58.64

>>105-106
それって、Cobolのソースコードをそのまま変換するようなのかな?
Move a to b
なら
なんかのライブラリ.move(a, b);
にするようなとか。

115 ：デフォルトの名無しさん：2011/09/26(月) 04:46:44.10

>>108
デフォルトスタンダードって何だよw
変な言葉作るなwww

116 ：デフォルトの名無しさん：2011/09/26(月) 04:59:08.96

>>105,>>106
そういう話はよく聞くよな。
ユーザーサイドとPJサイドが別会社だと、
連携が取れなかったり、責任の押し付けあいが起きてデスマ化する。

117 ：デフォルトの名無しさん：2011/10/03(月) 17:50:16.53

>>114
プログラムの改変はべたにやって動くかも知れんけど、
MFからCSに移行とかだとデータの変換で死ねる希ガス

118 ：デフォルトの名無しさん：2011/10/04(火) 15:35:02.77

移行前の時点で既にデータ不整合だったのを発見してしまって、そこから処理ロジックのミスが10年以上見過ごされていた事を知ってしまった、あの日( T_T)

119 ：デフォルトの名無しさん：2011/10/04(火) 17:45:02.69

>>118
深刻なバグでなければ放置なんて、よくあることじゃん。

120 ：デフォルトの名無しさん：2011/10/04(火) 19:21:30.73

月次処理すると残高が微妙に変わるだけなんだけどね

121 ：デフォルトの名無しさん：2011/10/04(火) 20:13:23.64

請求金額の端数処理とかあきらかにバクってても、直すと怒られたりする。
いままでと金額が変わると取引先側で稟議が必要とやらで大変なことになるとか。
言語リプレースしてもその仕様は引きずって、意図的にバクを再現する必要があったり。

122 ：デフォルトの名無しさん：2011/10/04(火) 20:42:52.13

>>119
ドキュメント、何それ？状態だったから、影響範囲が不明なんだよ。
結局、怪しいデータだけ手管理になつた。
一つだけ良かったのは、扱いにくいデータを怪しいデータ扱いして開発の手間を減らせた事。

123 ：デフォルトの名無しさん：2011/10/06(木) 21:42:06.07

http://my.chiebukuro.yahoo.co.jp/my/myspace_quedetail.php?writer=song_kawasaki

124 ：デフォルトの名無しさん：2011/10/07(金) 18:57:00.31

データの手管理って、
データベースを開いて直接データを操作してるってこと？
それともマスターメンテ画面を作ってそこから操作してるのかな？

125 ：デフォルトの名無しさん：2011/10/10(月) 18:37:09.61

コボルで書かれたシステムのデータの一部を統計解析するので
このソース読んでデータの抽出方法を考えてきてくれ
と言われて, トータル5k行くらいのソース渡されたんだが,
いざコードを読もうとすると, 脳みそが拒否反応を起こして
睡魔が襲ってきます

データ定義だけ読めば何とかなるもんですか???

126 ：デフォルトの名無しさん：2011/10/10(月) 19:06:52.48

>>125
たかが5000ステップくらいで拒否反応起こすような整理能力の無い脳みそでは
言語関係なくそもそもプログラマーとして向いていないと思う…。

まぁコーダーなら話は別だが…。

127 ：デフォルトの名無しさん：2011/10/10(月) 21:04:04.85

5000行なんてたいした事ないけど、
構造化されてないスパゲッティなプログラムだったら死ねる。

128 ：125：2011/10/10(月) 23:06:12.20

>>126
フツー， 他の言語だと1kに満たない行数で書いてあるんだが

129 ：デフォルトの名無しさん：2011/10/10(月) 23:29:14.42

5kはJava脳とかだときついかもな。
cでもしmain関数が5000行あったら気が狂うが、
さすがに構造化くらいされてんだろ？

130 ：125：2011/10/10(月) 23:34:05.78

>>129
FORTRANの5kは全然区にならないんだが
つか, FORTRAN屋だよ, 本職は

131 ：125：2011/10/10(月) 23:37:58.06

>>130
# echo 'FORTRANの5kは全然区にならないんだが' | sed '/区/苦/'
つか， java 何かで統計解析やったら日が暮れる

132 ：デフォルトの名無しさん：2011/10/10(月) 23:41:52.84

他の言語は、データ定義だけ読めば何とかなるもんなのか…

133 ：125：2011/10/10(月) 23:56:55.17

>>132
ほしいのは, どのファイルのこの部分をどの部分を取り出せば良いかの情報
一つのファイルに収まっていなければ, 他のファイルも同様に再帰的に読んでいけば良い
と思ったんだけど, そうはいかない???

134 ：デフォルトの名無しさん：2011/10/11(火) 00:00:59.07

ステップ数の長いプログラムは、面倒であっても紙に印刷してマーカー引いてる。
画面とにらめっこしても埒が明かないよ。

135 ：デフォルトの名無しさん：2011/10/11(火) 00:06:59.75

Fortran屋かー。なんかCOBOLやJavaとは対局な業種ってイメージだw
ところで充分目的が定まってるのなら専門の担当者にヒアリングした方が早いと思うぞ。
絡まってるところが皆無だったとしても、見当つけるのが一番早いのはそのコードに関わってた奴なんだし。
Javaでいくら綺麗に組まれてても、細切れファイル追いかけまくる作業は眠いしな

136 ：125：2011/10/11(火) 00:29:05.72

> 専門の担当者にヒアリング

なにぶん, 現在それがいない（システムをメンテするときはコボル屋さん
の会社に出してるらしい)ので, わけのわからない言語(lisp とか ml
とか haskellとか)を趣味でつつき倒してるおれにお鉢が回ってきた

DATA DIVISION, どのファイルに書き出してるかと
調べ始めたんだけど, いつも使ってる言語と違って構文違いすぎ
# おれにはついていけませんwwwWW

つか,
``lock もかけずに同じファイルに書き込んでるみたいなんだけど, これだいじょうぶなの???''
``おれのほしいデータは最終的にどのファイルに集約されるの???''

って, な感じで謎は深まるばかりです

137 ：デフォルトの名無しさん：2011/10/11(火) 00:51:26.87

なんか並んでる言語名見る限り、考え得る限りもっとも場違いな人選されたんじゃないですかね。
排他制御はシステムが面倒見てるはずだから気にしなくていいと思うけど、必要なデータがどこかに集約されてるとは期待しない方がいいかも。
初期設計時に想定してない集計だからこそ業務として発生し、依頼されてるのでしょうし。
不得手なら面倒でもフローチャートを書き出したほうが早いかもしれません。

138 ：デフォルトの名無しさん：2011/10/11(火) 00:56:36.33

数学屋に事務処理言語のまま渡すってどうなんだ
建築デザイナーに図面とつるはし渡すかのようなシュールさを感じるw

139 ：デフォルトの名無しさん：2011/10/11(火) 08:53:58.23

>>138
某リフォーム番組で無理やり資材加工させられる匠みたいたなｗ

140 ：デフォルトの名無しさん：2011/10/11(火) 19:40:21.03

コボルでフェラチオソフト作りたいよ。
わかりません

141 ：デフォルトの名無しさん：2011/10/11(火) 20:25:40.92

COBOLかー
もう１５年やってないなあ

そんな漏れは今モータ制御で交流理論と機械力学の勉強中
言語はC++が一番好きだけどたまにCOBOLが懐かしく感じる

142 ：デフォルトの名無しさん：2011/10/11(火) 21:37:10.31

すべて小文字にするだけで一気にお洒落なデータ指向言語に

143 ：デフォルトの名無しさん：2011/10/11(火) 21:42:43.06

COBOLでモータ制御

144 ：デフォルトの名無しさん：2011/10/11(火) 22:29:22.28

いまのCOBOLは小文字でもＯＫじゃなかったか。
なんか前に古い汎用機のリプレイスでＯＲＡＣＬＥ移行とかやったけど
変数名を全部ＯＲＡＣＬＥ－ＤＢに合わせてたな。（キャメルケースって奴？）

145 ：デフォルトの名無しさん：2011/10/12(水) 13:28:16.64

>>1
>>7
COBOLでCOBOLコンパイラ書いてるという噂は私も聞いた。

146 ：デフォルトの名無しさん：2011/10/12(水) 13:30:23.70

世界初のLISPインタープリタは、FORTRANで書かれたそう。

147 ：デフォルトの名無しさん：2011/10/12(水) 13:31:53.86

何を何で書いてもいいんじゃない？

148 ：デフォルトの名無しさん：2011/10/12(水) 15:26:22.93

フリーのcobolの開発がもうちょっとやる気あれば
PCでcobol使って遊べるのに

149 ：デフォルトの名無しさん：2011/10/12(水) 19:14:59.02

そんなに駄目な子なの？

150 ：デフォルトの名無しさん：2011/10/12(水) 20:01:12.64

フリーのCOBOLなかったっけ

151 ：デフォルトの名無しさん：2011/10/12(水) 20:15:58.94

FreeCOBOL.iNFO～フリーのWindows用COBOLコンパイラまとめ～
http://labs.netbata.com/cobol/

152 ：デフォルトの名無しさん：2011/10/12(水) 21:56:39.00

汎用機とシステムのセット販売で大企業の強大なバックアップを受けられることがウリのＣＯＢＯＬで
フリーの実装って需要あんのかね。
まあ学習用か。

153 ：デフォルトの名無しさん：2011/10/12(水) 23:07:55.16

プログラム言語云々なんて所詮数ある手段の一つに過ぎないからな…。

154 ：デフォルトの名無しさん：2011/10/15(土) 10:20:06.03

>>152
COBOLerを増やしたい、せめて維持したいがための撒き餌かも。

155 ：デフォルトの名無しさん：2011/11/06(日) 22:16:26.92

COBOL汎用機から、クラサバにリプレースしたものの、中身はエミュレーターでCOBOLが動いているのを知った時の絶望感は異常。

156 ：デフォルトの名無しさん：2011/11/07(月) 00:05:34.40

だって作りなおせないもの

157 ：デフォルトの名無しさん：2011/11/07(月) 11:48:58.00

ん？汎用機COBOLをクラサバCOBOLへ移植したんじゃなくて、
サバ(UNIX or Windows)上で汎用機のエミュレータが動いているの？

158 ：デフォルトの名無しさん：2011/11/08(火) 01:31:21.24

そして、GUIも
ドロップダウンメニューで選んで送信ボタン
ってのが裏で
画面のこの位置にカーソル持ってきて数字入れてえんたー
って実行されるように出来ているんだろうなあ。

159 ：デフォルトの名無しさん：2011/11/08(火) 20:11:31.78

>>158
soretyottotanosisou

160 ：デフォルトの名無しさん：2011/11/08(火) 22:20:50.61

>>158
何そのオンラインバッチもどき

161 ：デフォルトの名無しさん：2011/11/08(火) 22:48:08.95

COBOL to Javaの自動変換ツールは山のようにあるけど
余り利用されてないのかな？
すくなくとも言語にまつわる問題は一気に解決しそうなんだけど。

162 ：デフォルトの名無しさん：2011/11/08(火) 23:21:50.88

>>161
未だに古いシステムをリプレースできてないところは、そもそもシンプルな仕様変更さえ超怖い状況下にあるものばかり
コンバートしてテストして稼働出来るような部品であれば、都合さえつけばとっくにコンバートもシステム移行も終わってると思いますぜ

163 ：デフォルトの名無しさん：2011/11/08(火) 23:38:35.00

とある業務系では
if 1989
...10ベージ位の処理
if 1990
以下ry)と延々と、しかもプログラム中に散りばめてあった。

164 ：デフォルトの名無しさん：2011/11/08(火) 23:43:12.48

>>163
>if 1989
なにこれ？

165 ：デフォルトの名無しさん：2011/11/09(水) 00:43:05.77

あんま想像したくないけど、まさか西暦別で処理書いてんの？ｗ
流石に遺産コードにしても担当者生きてたら怒鳴り付けたいレベルですなあ

166 ：デフォルトの名無しさん：2011/11/09(水) 00:45:38.34

>>163
ソースコード変換以前の問題の事例ですねわかります

こんなの、javaに変換できたところで……。

167 ：デフォルトの名無しさん：2011/11/09(水) 00:53:57.61

年度・法律が変わると、帳票の指定様式が整合性無視で変わるという、涙物。
しかも、年度によっては複数年度過去まで遡って累計が必須。
唯一の救いは、過去に出した計算結果は絶対に変えてはいけないので、補正分データを追加すれば良かった事ぐらいかなw

168 ：デフォルトの名無しさん：2011/11/09(水) 02:11:49.09

一般的コボラ程度の涙ぐましさですね。
もちろん担当者様を揶揄しているわけではありますん

最後に関わったＮ系、その手の笑い話状態のプログラム減ってた気がする
遺産の重さに負けず、頑張って書き換えてる人はいるみたいだな

169 ：デフォルトの名無しさん：2011/11/09(水) 06:11:47.74

>>167
COBOLに限らず、現実的な業務APの開発現場であればありがちな話の気がします

仮にJavaやC#のようなOOPだと、帳票という概念を分析した上で、
・帳票 -- 抽象クラス
　　・1989年度版帳票 -- 具象クラス
　　・1990年度版帳票 -- 具象クラス
のようなクラス継承にするのかな？

170 ：デフォルトの名無しさん：2011/11/09(水) 23:30:12.40

何で一つのプログラムにいろんな処理を無理やり突っ込む作り方をするのかな。
処理を細かく分けれて組み合わせて作れば、メンテの負担も減るのに…。
すごく腹が立つ。

171 ：デフォルトの名無しさん：2011/11/19(土) 08:43:15.71

COBOL85 のコンパイラ書いてみようと思ってるんだが、
COBOL85 って LALR(1) じゃ解析できないよね？

172 ：デフォルトの名無しさん：2011/11/19(土) 17:43:22.82

>>171
このスレでLLだのLRだのが分かる香具師が何人いるやら…

173 ：デフォルトの名無しさん：2011/11/19(土) 21:51:48.66

>>171
コンパイラに使う言語に関心がある。
COBOL用じゃないけど、最近見たのは、Haskellで書いたやつ。

174 ：デフォルトの名無しさん：2011/11/19(土) 23:08:11.20

Cobolはすべてが言語仕様に入ってくるから大変だと思うけど。

175 ：デフォルトの名無しさん：2011/12/13(火) 14:37:48.70

同じ語で別の意味持ってたり、省略可能な項目も結構あるから字句解析も構文解析も面倒な予感

176 ：デフォルトの名無しさん：2011/12/17(土) 01:09:44.03

それでもC++よりは、まあ。

177 ：デフォルトの名無しさん：2012/02/10(金) 23:32:20.20

スレチなのだがＣＯＢＯＬで２０年ホスト系で働いてた隣のおっちゃんが、パッケージ化されてきたからクビになった。っていってたんだけど。どういう意味？

178 ：デフォルトの名無しさん：2012/02/15(水) 12:54:55.19

http://www.amazon.co.jp/dp/4274211312

179 ：デフォルトの名無しさん：2012/02/15(水) 19:45:57.72

>>178 これ、新刊だね。

180 ：デフォルトの名無しさん：2012/02/16(木) 07:54:13.67

コボルとはコロボックルの略である

181 ：デフォルトの名無しさん：2012/02/17(金) 08:10:24.89

むしろコボルト

182 ：デフォルトの名無しさん：2012/02/18(土) 19:18:25.54

コボルでラムダ関数みたいなことはどうやればいいの？

183 ：デフォルトの名無しさん：2012/02/19(日) 13:15:46.87

>>182
やめとけ

184 ：デフォルトの名無しさん：2012/02/19(日) 22:02:27.25

思い返すとCOBOLについては一切身銭を切ったことがないけど、
困ることが何もなかったのは色々と考えさせられますな。
最近の流行の言語は機能は豊富だけど、学習コストが高すぎるのよね。
IDEや入力補助がないとコードを書きあげられないのはどうなのかしら。

185 ：デフォルトの名無しさん：2012/02/22(水) 01:44:05.16

いや、最近の言語でもIDEなしでコード書けるし、
むしろコボルってIDEとか入力補助ないような非効率な開発を
まだ続けてるんだという驚き。

186 ：デフォルトの名無しさん：2012/02/22(水) 02:32:38.21

スレタイの「ただのDSL」呼ばわりが改めて沁みる問答だ

187 ：デフォルトの名無しさん：2012/02/22(水) 06:28:54.82

で最近のPGがよく口にする「関数が無いから組めません(ｷﾘｯ」となるわけですねｗ

まぁ最近の開発はGUI部品を貼り付けてクラスや関数をスクラッチして作成する簡単なお仕事だからな。
ちゃんとコードが書けるPGなんてPG全体で1割いるかどうかだからな・・・。

188 ：デフォルトの名無しさん：2012/02/22(水) 12:26:58.05

cobolもideあるけど只厨にはハードルが高すぎるな

189 ：デフォルトの名無しさん：2012/02/22(水) 12:32:15.26

>>186
趣味で(興味本位で)COBOLを触ろうなんて奴は、めったにいないから無問題

というか、COBOLでオプソなんて、ORCAくらいしか思いつかないけど、
他にもあるのかな？

190 ：デフォルトの名無しさん：2012/02/22(水) 12:39:38.79

>>187
まるで、コボラーなら「関数が無いから組めません(ｷﾘｯ」ってならないと
言ってるみたいだ。

191 ：デフォルトの名無しさん：2012/02/22(水) 13:55:52.63

昔いたコボルの現場で日付の論理チェックのサブルーチンで「日付チェックのクラスが無いから出来ないです！」といって
バンザイしてたC++プログラマなら見たことあるよ。

192 ：デフォルトの名無しさん：2012/02/22(水) 21:50:53.79

>>191
そういう人間をCOBOLの現場に連れてくるなよ w

193 ：デフォルトの名無しさん：2012/02/22(水) 23:05:40.64

「負数の数を含む剰余」ってどう定義されていますか?
処理系間で互換性はありますか?

194 ：デフォルトの名無しさん：2012/02/23(木) 00:13:07.60

かつては金融機関の勘定系（基幹系）システムは全部COBOLで動いていた。

設計思想が古かったり、2000年問題の主役の一人だったりで>>1みたいに嫌っているプログラマー多し。
だが、COBOLが愛される最大の理由は信頼性だろ
バグ1個で億単位の損害が出る分野には枯れた技術や枯れた言語が一番
こういうのだとバグが少ない（はず）
埃かぶったWindows3.0とかが取引先で現役とかザラですし
クレジットカードのシステム全部COBOLで動いてるらしいぞ

COBOLがダメな理由がない限り使い続けるほうがいいに決まってる。

最新の～～だったらこんなこともあんなこともできてー
ってたいていは必要の無い機能だし。
COBOLerとかいって笑う人多いけど、おまえら3000万口座で24時間365日絶対に止まってはいけないし
計算を間違えてはいけないシステム設計したことあんのかよ。

東京海上日動の新システムはCOBOLを採用
http://itpro.nikkeibp.co.jp/article/NEWS/20080906/314277/
COBOLこそスピード経営に必要 BY ジャパネットたかた
http://itpro.nikkeibp.co.jp/article/COLUMN/20100319/345984/

195 ：デフォルトの名無しさん：2012/02/23(木) 06:17:43.98

>>194

COBOLが嫌いな理由、コーディングしても楽しくない、ライブラリが充実していないので全てコードを自分で書かないといけない。
あとステップ数が異常に多くてコードが難解。

> COBOLerとかいって笑う人多いけど、おまえら3000万口座で24時間365日絶対に止まってはいけないし
> 計算を間違えてはいけないシステム設計したことあんのかよ。

なんで24時間365日絶対止まってはいけないの？OSのアップデートなどでWindowsを定期的に再起動するでしょ？
コボラーの常識ではアップデートなしの危険な状態で運用するのが当たり前なのw

普通は止まってはいけないシステムを設計するより止まっても支障ないような設計にするのが当たり前なのに・・・。

196 ：デフォルトの名無しさん：2012/02/23(木) 09:18:04.25

しかし言語が作られて何十年も経ってるのに、
未だにライブラリが揃ってないというのはどういうことか。

197 ：デフォルトの名無しさん：2012/02/23(木) 09:28:59.54

>>194
人間が作る以上、バグを無くす事なんて不可能だし
たとえプログラムにバグがなくてもOS側の問題でトラブルが発生するんだから365日無停止のシステムなんて構築不可能。

198 ：デフォルトの名無しさん：2012/02/23(木) 21:49:12.03

確かにCOBOLは計算一つ行うために延々と定義みたいな処理を何十行も繰り返さないといけないというヤバイ言語だな

だがコイツなら0.1を正確に表すことができるから
新人でも浮動小数点使って誤差出す初歩的なポカをやらなくて済むじゃん。
銭の計算は１０億で１円の誤差でもアウトだから。

199 ：デフォルトの名無しさん：2012/02/23(木) 22:01:53.89

1/3=?

200 ：デフォルトの名無しさん：2012/02/23(木) 22:12:36.55

>>197
バグ1個で万とか億とかの銭が大量に動いたりしたんじゃ、ヤバすぎるだろｗｗｗ

201 ：デフォルトの名無しさん：2012/02/23(木) 23:39:36.42

お前らそろそろVISUAL COBOLについて語ろうぜ

202 ：デフォルトの名無しさん：2012/02/23(木) 23:49:27.19

> 銭の計算は１０億で１円の誤差でもアウトだから。
なんでなんだろうね。商取引も相対誤差ε以下は許容するとかなって
いるといいのに。

203 ：デフォルトの名無しさん：2012/02/23(木) 23:58:30.91

>>200
そもそもバグなんてプログラマの責任じゃなく設計者の責任だろ

204 ：デフォルトの名無しさん：2012/02/24(金) 00:02:07.87

>>202
いや、今でも誤差は許容してるんじゃない？
１０進で何桁未満は切り捨てor四捨五入みたいなように決めておいて。

205 ：デフォルトの名無しさん：2012/02/24(金) 00:05:40.78

本当にあるこんな話

A「私、金融系のシステムリプレースやってるんです」
B「へえ～、COBOLからJavaに置き換えるのですか？」
A「いいえ逆です。JavaからCOBOLに置き換えるんです」
B「えっ？？？？」
A「Javaから、COBOLです」
B「(ﾟДﾟ)ﾊｧ?」

206 ：デフォルトの名無しさん：2012/02/24(金) 00:24:37.73

この業界に長くいると時々出くわすね
技術力はあるんだけど
「お金の計算をするシステム組んだことないんじゃないの？」
って人

207 ：デフォルトの名無しさん：2012/02/24(金) 00:31:34.58

>>206
そりゃそうだ。君が世間を知らなすぎるだけ。

208 ：デフォルトの名無しさん：2012/02/24(金) 00:50:01.39

>>206
最近はCPUって何？OSって何？とか言い出す人間がプログラムを組む時代だからな。

209 ：デフォルトの名無しさん：2012/02/24(金) 01:33:19.11

スーパーでも24時間営業の店とかあってNCRのノンストップ・コンピュータ(HP社に吸収されたタンデム社のOEM品？)を使ってるよね

210 ：デフォルトの名無しさん：2012/02/24(金) 01:47:14.48

>>204
いや、そういうんじゃなくて小数点７桁の数値を単純に数百万回加算しても誤差が出ないという話では？
初期のパソコンによく使われたZ-80とBasicの組合せでは0.001を単純に1000回足しても1に為らずに0.997とか0.999になってしまうものだった

211 ：210：2012/02/24(金) 05:16:39.68

確かi386とBasicの組合せ(OSはMS-DOS)でも出たような記憶があるんだよなあ
勿論1000回ぐらいじゃ出ないんだけど・・・

212 ：デフォルトの名無しさん：2012/02/24(金) 07:54:27.71

今、Excel2000のマクロで0.0001をFor～Next文で一万回足したら…orz

213 ：デフォルトの名無しさん：2012/02/24(金) 21:28:24.87

>>210>>212
0.1 を 1 万回足してもなかなか 1,000 ちょうどにはなってくれない場合がある。
コンピュータが 2 進数で動いていることの証拠なのだが、金融の世界ではかなり困ったことになる。

2進演算では、小数点以下の丸め誤差が発生してしまうためだ。

金融業界は怖いぞ～、この業界では超巨大な銭を扱っていて、
さまざまな金融商品を数十兆円単位で取引しているが・・・
0.1％の誤差があるだけであっという間に数百億円単位の損害を叩き出す大惨事になるというとんでもない世界
だから金融業界ではBCD演算が必須

COBOLは言語の仕様でBCD演算をサポートしているから銭の勘定では他の追随を許さない安定性がある。
他の言語でもできないというワケではないが、初めからついてる奴と、後付けの差は大きい。
要するに「そろばんや電卓での処理」をそのままプログラムに落とし込めるから金融系では確実に使える

蛇足だが、MSX（大昔の8ビットパソコン）にもBCD演算機能が存在する

214 ：デフォルトの名無しさん：2012/02/24(金) 21:36:36.13

BCD演算って他の言語でもライブラリとかで使えなかったっけ？

215 ：デフォルトの名無しさん：2012/02/24(金) 21:45:16.86

>>214
有るだろうけど(Excelだと通貨型)つまりは意識してデータの型を宣言しなければいけないという事

216 ：デフォルトの名無しさん：2012/02/24(金) 21:54:31.11

>>214
有っても確か演算処理が非常に遅かったはず・・・

217 ：デフォルトの名無しさん：2012/02/24(金) 22:07:42.48

パフォは一番悪いとかなんとか

218 ：デフォルトの名無しさん：2012/02/25(土) 04:41:57.43

>>216
COBOL使うようなマシンなら、CPUがBCD演算をサポートしてるんじゃない？

219 ：デフォルトの名無しさん：2012/02/25(土) 06:22:16.80

何か勘違いな部分もあるようなんで…
COBOLは言語の仕様で固定小数点演算(Binaryだと浮動小数点演算より高速だが有効桁が小さい)
扱える形式
Binary
BCD(pacdデシマル)
ゾーンデシマル(文字型数字)
何れでも小数点ありの変数として計算可

220 ：デフォルトの名無しさん：2012/02/25(土) 06:22:41.72

何か勘違いな部分もあるんで
COBOLは言語の仕様で固定小数点演算(Binaryだと浮動小数点演算より高速だが有効桁が小さい)
扱える形式
Binary
BCD(pacdデシマル)
ゾーンデシマル(文字型数字)
何れでも小数点ありの変数として計算可

221 ：デフォルトの名無しさん：2012/02/25(土) 06:32:19.92

ありゃ、二度書きしちまった^ ^;
小数点の位置を固定するので、ある意味integerとして計算できる

222 ：デフォルトの名無しさん：2012/02/25(土) 07:32:17.49

COBOL以外でBCDを高速で扱えるのはPL/1くらいか。

223 ：デフォルトの名無しさん：2012/02/25(土) 08:36:18.74

先ほども云ったようにコンパイル時に計算対象の変数、数値を解析して小数点位置を決めうちし計算するのでBinaryであっても0.1を１万回加算しても誤差がでる事がない

PL/I、俺自身は使った事無いけど使われなくなってしまったのは惜しいと思う。IBM、パソコン用にだしてくれないかなあ(格安で…)今出たらCOBOLもJavaが殆ど消え去りそうな気もするけど

224 ：デフォルトの名無しさん：2012/02/25(土) 12:34:10.68

システム構築、工程品質管理、その後の保守をする立場でいえば、COBOLは色々な面で有難いし、不要とは思わない

比較的まとまった規模の案件であれば、他言語併用でCOBOLはいまだに現役だし、これからも事務処理系や大量のデータを取り扱う分野で生き残ると思う
新規案件が減っている感じもしない

ちなみに、レベルの低いJava書きを排除するために、Java案件でも、人員資格にCOBOL必須と入れている

プログラマーにとっては、面白みはないが、毛嫌るす言語では無いと思うのが、個人的な意見
異論は認める

225 ：デフォルトの名無しさん：2012/02/25(土) 15:42:57.39

20年以上前にCOBOLを使っていて不満だった事
・ローカル変数が使えない(全てDATA DivisionのWORKING…で定義)
・構造体の拡張が出来ない・テーブルの動的拡張が出来ない

これくらいかな？
後はPL/Iの総称名が使えればなあとオンライン処理の時に思ったくらいかな

226 ：デフォルトの名無しさん：2012/02/25(土) 20:45:01.32

最後の部分は機種依存による制約にしか過ぎないのかな？
SDLC、HDLC等プロトコル手順毎にメーカー提供のサブルーチン名が異なっておりリンク時に静的結合しかできなかったんでため息をこぼすしかなかった

227 ：デフォルトの名無しさん：2012/02/25(土) 21:05:01.47

COBOL の区粗なところ
大量のデータをライブに扱えない
１ 日 n00GiB から nTiB 増えるデータは扱えない

228 ：デフォルトの名無しさん：2012/02/25(土) 23:41:52.56

>>224
金融業界や保険業界だと、Web製作すらCOBOL採用する暴挙をやらかすからなあ。

229 ：デフォルトの名無しさん：2012/02/25(土) 23:54:13.27

ＢＯＣＯＬぞ！

230 ：デフォルトの名無しさん：2012/02/26(日) 13:00:03.48

>>227
あまり問題無い気もするが、>>227の想定ってどんな状況なんだろうか？

まあ、どうしても無理なら、必要な所はC++とか、Javaで書けばいいだけじゃねぇ？

231 ：デフォルトの名無しさん：2012/02/26(日) 13:17:25.29

>>228
GUIがJavaで、裏はCOBOLってやつかな？
それならお互いの特性を使い合えるから、程度にもよるが、有りだと思う

ALL COBOLなら、ある意味、COBOLに掛ける情熱に尊敬する

232 ：デフォルトの名無しさん：2012/02/26(日) 14:37:40.85

>>230
C++やJavaは言語としてはいいけれどそれらを走らせるプラットホームが脆弱過ぎるのが困る・・。

233 ：デフォルトの名無しさん：2012/02/26(日) 14:38:49.55

>>228
NetCOBOL？

234 ：デフォルトの名無しさん：2012/02/26(日) 15:23:29.18

>>225
全く同じ不満を持っていたw
俺だけじゃなかったんだ

235 ：デフォルトの名無しさん：2012/02/26(日) 15:57:56.57

>>227 論理的な区切りが出来ないイメージデータ？

機種依存の部分でレコード長が32KB制限あるのはきつかったなあ(WORKING内の各テーブル等…)
リアルタイム集計やCAFISみたいにアプリレベルに近い部分で非同期処理があると、もうね…

236 ：デフォルトの名無しさん：2012/02/26(日) 17:20:12.63

>>227
COBOLだとどういう問題があるのですか？

237 ：デフォルトの名無しさん：2012/02/26(日) 19:12:25.27

>GUIがJava
そこももうどうかと思うなぁいまどき…

238 ：デフォルトの名無しさん：2012/02/26(日) 19:39:19.07

誰か不定長レコード(可変長じゃなくて)のファイル扱ったことある人いる？
俺あれだけは何に使うのか解らんかった(^ ^;

239 ：デフォルトの名無しさん：2012/02/27(月) 23:17:50.82

>>223
PL/IはIBMのメインフレームで使用されている言語だね。
COBOLとFORTRANとALGOLから当時としてはいいとこどりをして作られたが
マシンリソースを大量に必要となるため、ＩＢＭのメインフレーム以外では普及はしなかった
日本では三菱東京UFJ銀行、みずほ信託銀行など多数が使っている。
>>231
キャッシュカードやクレジットカードのポイント設定とか与信管理などをするWebサイトだったら
モロに勘定系システムだからCOBOLで動いていてもおかしくない

どうやら安田火災海上保険（現:損保ジャパン）は、自動車保険のインターネット見積りサイトは保険料の見積もりをする部分がCOBOLで動いているらしい。
↓がCOBOLで動くWebサイト（実は、コレはCOBOLで動く！！）
http://www.sompo-japan.co.jp/kinsurance/automobile/onestep/index.html

240 ：デフォルトの名無しさん：2012/02/28(火) 07:21:14.06

>>236
今のCOBOLは可変長出力ができるし、他の言語と
特別差はない。ポストスクリプトファイル出力なんか
だってするし。

241 ：デフォルトの名無しさん：2012/02/28(火) 08:48:14.81

>>238
そりゃ誰でも使ってるよ、LMなんかは不定長ファイルじゃないか。

242 ：デフォルトの名無しさん：2012/02/28(火) 09:48:35.35

Webというかhtmlファイルの大枠はCOBOLで書いて、
複雑な処理は別マシンでCOBOLがバッチ出力したファイルを
Prologで読み取らせて処理させ、JSファイルに出力させて置く、
というのは見たことがある。
問い合わせにリアルタイムでというのは無理そうだった。

243 ：デフォルトの名無しさん：2012/02/28(火) 20:49:25.84

>>242
バックエンドのバッチ部分はCOBOLで・・というのはわかるけど、htmlの出力部分をわざわざCOBOLで組む理由がわからん。

244 ：デフォルトの名無しさん：2012/02/28(火) 22:52:52.52

なんかコボルのシステムってエリアの領域が足りなくなって
計算おかしくなったりするのおおいイメージだったんだけど！
たとえば簡単にいうと、エリアに3文字しか入らないのに、
1200+300を計算すると、500になるとか。そういうバグ大杉。
まあ僕じゃなくてコボル40年のジジイが作ったやつだけどね！！

245 ：デフォルトの名無しさん：2012/02/28(火) 23:01:39.89

>>244
そりゃ桁あふれすれゃ不正な数値になるのは当たり前だろ・・。int型の変数に32768以上の数値をぶち込むのと同じ事

246 ：デフォルトの名無しさん：2012/02/28(火) 23:04:31.09

いまどきintが16bitなのか…

247 ：デフォルトの名無しさん：2012/02/28(火) 23:07:20.02

245は40代

248 ：デフォルトの名無しさん：2012/02/28(火) 23:37:08.98

桁あふれによるバクを発生させるなんてビギナーレベルの初歩的なミスだろ

249 ：デフォルトの名無しさん：2012/02/29(水) 00:52:00.96

いや桁あふれたらエラー吐けよコボルはそんなこともできないのか？

250 ：デフォルトの名無しさん：2012/02/29(水) 01:57:02.09

COBOLの場合、BCDだから演算とformattingが一体化してるんだっけ?
だとすると、
"1"500 (3桁) <- 1200(4桁) + 300(3桁)
という演算をやっているので、コンパイル時にわーにんぐが出てもよさそう
なものだいが。

251 ：249：2012/02/29(水) 02:14:59.58

>>241
機種によって違うのか
俺の使っていたマシンは固定長だったな
ソースライブラリは可変長(ヘッダー部にLength付きで扱い方はデルファイと同じ？)だったし
プリントファイルが不定長なんだろうけど入力側として使ったことがない
銀行の勘定系だと全銀オンラインがプリントイメージなので有るんだろうけど

>>249
ADD、SUBSTRACT、MULTI…、DIVIDには確かあったはず(ON SIZE ERRORの構文の後に命令)最もよほどの事が無い限り省略していたなあ
COMPUTE命令、MOVE(項目転送)命令にはないねえ

252 ：デフォルトの名無しさん：2012/02/29(水) 02:25:13.40

>>250
BCD、文字型数字で計算できるといってもコンパイル時にバイナリーに変換して計算、そしてOUT側の形式再変換したりが普通じゃなかったかな

253 ：デフォルトの名無しさん：2012/02/29(水) 02:38:23.18

>>243
順序が逆なんじゃないかな。元々COBOLで組まれていて、
対応できないというか、メインフレームでは危険な部分が
生じて例えばUNIXのシステムを追加した。
不整合な部分をJS出力で誤魔化した。

254 ：デフォルトの名無しさん：2012/02/29(水) 02:40:36.50

>>253
IF文の多いCOBOLと
IF文が消え去るPrologは
相性がいいよね。

255 ：デフォルトの名無しさん：2012/02/29(水) 08:30:54.63

>>254
COBOLからPrologプログラマへの転向は簡単かも知れないけど・・

256 ：デフォルトの名無しさん：2012/02/29(水) 19:09:09.12

よっしゃこれからProlog勉強する

257 ：デフォルトの名無しさん：2012/03/05(月) 22:59:07.08

Prologって仕事あるの？
何も勉強しないよりかはマシだけど
仕事無くて結局コボラー続けちゃうんじゃないの？

258 ：デフォルトの名無しさん：2012/03/06(火) 14:57:12.93

>>257
メインフレームでは無理だろう。
UNIX/Linux/OSX上では実は結構ある。

259 ：デフォルトの名無しさん：2012/03/06(火) 15:06:45.56

私の知る限りの話だが、年配の管理者に、この案件は
関数型言語でやりたいと申し出てもほとんど拒否されるが
Prologでというとすんなり通る。この言語不思議な地位にある。

260 ：デフォルトの名無しさん：2012/03/06(火) 16:14:30.30

>>258
＞UNIX/Linux/OSX上では実は結構ある。

Windowsで走らない時点で終わっていると思う。

261 ：デフォルトの名無しさん：2012/03/06(火) 17:56:45.41

>>254-260
貴様等、まとめてPrologスレへ逝け！w

262 ：デフォルトの名無しさん：2012/03/06(火) 18:10:47.65

>>260
古くからメインフレームのバックで動いてる環境という意味。
今やAndroidやMacの時代で今更Windowsなんて使わないだろう。

263 ：デフォルトの名無しさん：2012/03/06(火) 18:24:33.84

>>262
＞今やAndroidやMacの時代で今更Windowsなんて使わないだろう。

いいえ、世の中ほとんどがWindowsです。

日本のシェア1月
OSシェア
Windows 7：37.37%
Windows XP：27.51%
Windows Vista：18.71%
MacOS：6.64%
Android：4.00%
iPhone：2.88%
Windows 2000：0.27%
Linux：0.05%
Windows ME：0.09%

264 ：デフォルトの名無しさん：2012/03/06(火) 18:52:11.23

>>263
だから、現時点では Windows 7:37.37 OSX が多分12-3%
つまり 3 : 1
目を覆うばかりのWindowsの凋落ということだろう。

265 ：デフォルトの名無しさん：2012/03/06(火) 19:28:25.23

>>263
Linuxがゴミ過ぎてワロタ

266 ：デフォルトの名無しさん：2012/03/06(火) 19:30:42.01

最近じゃメインフレームもWindowsのエミュ上で走らせるのが常識なのに…

267 ：デフォルトの名無しさん：2012/03/06(火) 20:05:36.80

>>265
twitter利用者でのシェアは数%あるそうだから、そう単純ではない。

268 ：デフォルトの名無しさん：2012/03/06(火) 20:12:36.43

Windowsと併用してる人がだろ。

269 ：デフォルトの名無しさん：2012/03/06(火) 22:42:01.09

>>266
お前どっかのスレに居た人だな？ｗ

270 ：デフォルトの名無しさん：2012/03/06(火) 22:44:01.37

そういえば、あのスレ落ちていたな

271 ：デフォルトの名無しさん：2012/03/07(水) 06:51:28.68

はい、ソース。

Windows上で稼動するメインフレーム
http://wsmgr.jp.brothersoft.com/screenshot-50450.html

272 ：デフォルトの名無しさん：2012/03/07(水) 07:35:42.02

えーっ。VMwareか何かでOS/390なんかも動くの？

273 ：デフォルトの名無しさん：2012/03/07(水) 09:42:26.91

>>271
だからそれメインフレームじゃなくて端末だってば、まだ解らないの？ｗ

274 ：デフォルトの名無しさん：2012/03/07(水) 09:51:48.05

>>273
あ、>>266にエミュって書いてあるねw ごめん。
だけど、3270エミュレータならN88-BASICの時代からあるよ。

275 ：デフォルトの名無しさん：2012/03/07(水) 10:07:13.28

>>274
いや3270のエミュなら昔からあるだろう、そりゃ。
ただ件の彼は残念ながらずっと「『メインフレーム』をWindows上で稼働させるのが普通」
って言っちゃってるんだよ…

「端末はWWWで言うブラウザみたいなものだぞ、お前は2chの鯖がWindowsで動いてると思ってるのか？」
と指摘したら「鯖もWindowsに決まってる」と言いきっちゃったマジメに痛い子

276 ：デフォルトの名無しさん：2012/03/07(水) 11:12:39.88

>>271は荒らし
別スレで同じようなやり取り幾度も繰り返してる。

277 ：デフォルトの名無しさん：2012/03/07(水) 17:47:58.45

コボラーにコンピュータの常識が通用しない事がよくわかりましたｗ

278 ：デフォルトの名無しさん：2012/03/07(水) 19:04:28.54

>>277
そう思っていいから、Windowsと暮らしてなさい。

279 ：デフォルトの名無しさん：2012/03/07(水) 19:37:43.82

コボルか、何もかも懐かしい

280 ：デフォルトの名無しさん：2012/03/07(水) 22:03:17.36

>>278
今の世の中、ITの世界はむしろWindowsじゃないと成り立たないんじゃないの?

281 ：デフォルトの名無しさん：2012/03/07(水) 22:30:46.84

>>280
スマホがパソコン出荷を上回り、そのOSの50%以上がAndroid。
さらに、Macのシェアが世界的には15%に日本でも10%を超える。
Linuxは欧州の都市の公的コンピュータを席巻して、UNIXの
サーバーとしてのシェアも一定水準を確保。以上のことから
言えることは、UNIX系OSの大反撃が起きているということ。

282 ：デフォルトの名無しさん：2012/03/18(日) 22:29:17.98

コボラーに未来は無いと言われ続けて20年
どっこい生きてる基幹システムの中

保守要員としてならあと20年は戦える

283 ：デフォルトの名無しさん：2012/03/18(日) 22:53:55.48

基幹システムが壊れないといいね

284 ：デフォルトの名無しさん：2012/03/18(日) 23:33:41.03

>>283
基幹システムが壊れるってどういう意味だ？

まさか基幹システムがPCやサーバーみたいな固有のH/Wだと思っているのか・・・

285 ：デフォルトの名無しさん：2012/03/18(日) 23:47:02.76

壊れないは変か？
cobolで処理できない状況にならなきゃいいけどね

286 ：デフォルトの名無しさん：2012/03/19(月) 06:18:31.73

COBOLが優秀というよりCOBOL以外の言語が走るプラットフォーム、
特にWindowsが脆弱過ぎて基幹システムの運用に耐えられないだけなんだけどね。

287 ：デフォルトの名無しさん：2012/03/20(火) 01:09:53.29

>>283
そうだね。基幹システムで不具合が出たら、あっという間に億単位の損害ｗｗｗｗ

288 ：デフォルトの名無しさん：2012/03/20(火) 14:02:10.33

基幹システムがCOBOL以外のモノに移る可能性は常にある。
50代の技術者が定年までしがみつくには最適かもしれないが
2,30代の技術者が食ってくにはキツイ。

289 ：デフォルトの名無しさん：2012/03/20(火) 15:09:09.41

ホストでLinux, java,oracleが動く時代だぜ。
某銀行も保守はともかく新規でCOBOLを採用することはないと断言してるし。

290 ：デフォルトの名無しさん：2012/03/20(火) 17:04:08.46

Oracleって、メインフレーム上で動くの？
間接的な連携はできるらしいけど。

291 ：デフォルトの名無しさん：2012/03/20(火) 17:09:26.77

分散処理が出来るようになったからね
データベースだと、どこで管理するとかになってくるんじゃねえの
クラウドっていうのもその流れの一つでしょ

292 ：デフォルトの名無しさん：2012/03/20(火) 17:52:43.11

ホスト上でDB管理することで高い信頼性を維持してるのに
わざわざ信頼性の低いサーバーに分散とか意味わからないとか思ったけど
別システムのデータを直接引っ張ってこれるって意味なら、アリだな。

293 ：デフォルトの名無しさん：2012/03/20(火) 23:50:06.85

でも今時のPGみたいにパッチワークのようにコピペでしてコードを書く人間にはCOBOLは辛いかもね

294 ：デフォルトの名無しさん：2012/03/20(火) 23:56:37.24

>>290
現在はホストと言えばWindowsを指すのだが？

東京証券取引所の基幹システムとして稼動するWindows
http://itpro.nikkeibp.co.jp/article/NEWS/20090609/331590/?SS=imgview&FD=-654674548

HPCでもダントツのパフォーマンスをたたき出すWindows
http://cloud.watch.impress.co.jp/docs/interview/20101224_416025.html

Windows上で稼動するメインフレーム
http://wsmgr.jp.brothersoft.com/screenshot-50450.html

Linuxより57倍速いWindows!!
http://www.elecom.co.jp/business/pickup/nas/201102/index.html


一方Linuxは…
Linux Daily Topics：2011年9月2日　Kernel.orgがトロイの木馬の侵入被害に｜gihyo.jp … 技術評論社
http://gihyo.jp/admin/clip/01/linux_dt/201109/02

Linux カーネルの基盤サイトがクラッキングの被害に - japan.internet.com
http://japan.internet.com/webtech/20110902/2.html

Linux Daily Topics：2011年9月15日　狙われるLinux… 今度はLinux Foundationが標的に｜gihyo.jp … 技術評論社
http://gihyo.jp/admin/clip/01/linux_dt/201109/15

【経済】 東証でシステム障害　２４１銘柄の売買一時停止
http://uni.2ch.net/test/read.cgi/newsplus/1328146640/l50

295 ：デフォルトの名無しさん：2012/03/21(水) 00:27:36.44

これが噂のwindowsさんか…納得

296 ：デフォルトの名無しさん：2012/03/21(水) 06:17:33.11

ホストの意味も理解できないようでは・・・ 贔屓の引き倒しになりそう

297 ：デフォルトの名無しさん：2012/03/21(水) 06:25:02.86

>>294はLinuxスレで暴れているアンチだよ。通称ダダダ。
たしか勤め先のサーバーがWindowsから全てLinuxに置き換えられて
Linuxについていけない>>294はリストラされたとか。

故にLinuxが憎くて憎くてしょうがないらしい・・・

298 ：デフォルトの名無しさん：2012/03/23(金) 21:02:39.76

コボラーってもしかして昔ながらのホストマシン(笑)が未だに稼動していると信じているんだw

Windows全盛の今の時代でメインフレームすらWindowsで稼動している現代でまさにオカルト的な発想だわｗ

299 ：デフォルトの名無しさん：2012/03/23(金) 23:01:43.85

これじゃあリストラされても止むなし(^ω^)

300 ：デフォルトの名無しさん：2012/03/24(土) 08:43:04.54

>>299
確かにｗ
コボラーは技術が20年以上遅れているからどんどんリストラされている。

301 ：デフォルトの名無しさん：2012/03/25(日) 01:14:23.38

これは失笑ものだな

302 ：デフォルトの名無しさん：2012/03/25(日) 15:14:24.22

ダ「メインフレームは現在Windows上で動いている、証拠の画像だ」
住民「いやそれ、ただの端末だから…」
ダ「端末がWindowsならメインフレームもWindowsだろう」
住民「えーとな、メインフレームはWebサーバ、端末はブラウザみたいなもんなんだよ、例えば2chはWindowsから見れるだろう？」
ダ「2chの鯖もWindowsだろう？」
住民「いやBSDだが」
ダ「違う、Windows鯖だから見れるんだ」
住民（駄目だコイツ）

303 ：デフォルトの名無しさん：2012/03/26(月) 13:43:45.54

アンドロイド端末からＰＣを操作出来る→ＰＣのＯＳはアンドロイドだ間違いない(ｷﾘｯ)
こうですか(笑)

304 ：デフォルトの名無しさん：2012/03/27(火) 23:38:53.49

COBOL資産の他言語移行が進まないのは、
銀行や証券・生保など金融機関の勘定系システムで多く利用されているため
スケジュールと人員面で移行が困難なせいもあると思います。

特に金利計算なんかは100％ブラックボックスと化していて下手にいじると収集がつかなくなったりして。

「今でもCOBOLで問題なく動いているものを、
危険なリスクを背負ってまで他言語へ移行する理由もない」

・・・と経営層は判断するでしょうし。


バッチ処理に強いとか言われるけど、日本語環境ではいまだに全角／半角文字の混在処理が苦手だったり、
GOTO文使いまくって簡単にスパゲッティコードになったりするのはいい加減勘弁して欲しいです。

でもまだ当分現役なんだろうな・・・

例えば住宅ローンの場合は最長35年あるわけで、1970～1980年代のシステムがそっくりそのまま残っていて
そのままCOBOLで運用されてても不思議ではないです。ただ、今後積極的に使われることは少なくなってくるでしょう。

305 ：デフォルトの名無しさん：2012/03/28(水) 02:33:04.04

過去10年分のデータ食わして同じ結果になりました、みたいなテストができりゃ良いんだけどねえ
無理ゲーすぐる

306 ：デフォルトの名無しさん：2012/03/28(水) 06:18:31.54

未だにCOBOLが使われているのは他の言語やプラットフォームについていけない老害ばかりだからだろ。

VBとSQLで何百倍も低コストで何千倍も早いシステムが構築できる・・・。
COBOLが得意というバッチ処理でもCOBOLで何時間もかかる処理がSQLだと数秒で処理でる。

307 ：デフォルトの名無しさん：2012/03/28(水) 07:10:50.19

あれ辺だなあ、漏れがCOBOLやってた頃ふつうにＲＤＢ使ってたけどなあ

308 ：デフォルトの名無しさん：2012/03/28(水) 07:42:33.74

COBOLをやると落ちCOBOL

・・30年前のダジャレより

309 ：デフォルトの名無しさん：2012/03/28(水) 08:35:33.47

F通でもRDBⅡというのがありましたで（って今もあるんだろけど w

310 ：デフォルトの名無しさん：2012/03/28(水) 08:53:38.47

講師に聞いた事があるけどCOBOLのバッチ処理って何時間もかかるんだよね？
だから夜間しか処理出来ないとか。

WindowsのPCとSQLだと簡単なマクロで数秒て処理出来るのに・・

311 ：デフォルトの名無しさん：2012/03/28(水) 09:02:04.94

Windows爆速厨にデータ量を調べようとした形跡がないのが気になる

あるんだぞCOBOLしか知らんプログラマーが全文検索を
text optionとかないRDBでやろうとして検索対象を不定長stringの項目に放り込んで
オンライン検索に1画面5分かかりましたとかすごいことをやっている例が

チューニング頼まれて見てみると5分間Disk I/Oが100%張り付きww
聞いてみると「VSAMが使えないんでこうやるしかないかと思って…」

312 ：デフォルトの名無しさん：2012/03/28(水) 11:19:57.67

システム開発したこと無い奴のダメな営業トークみたいだな。
ユーザーも開発者もみんな不幸にされちまう。

313 ：デフォルトの名無しさん：2012/03/28(水) 11:40:23.84

流行るかどうかは微妙なとこだがNoSQLという流れもあるんだな。

314 ：デフォルトの名無しさん：2012/03/28(水) 11:45:01.50

>WindowsのPCとSQLだと簡単なマクロで数秒て処理出来るのに・・


これは実際に同じデータを与えて検証した上で言ってる事？

315 ：デフォルトの名無しさん：2012/03/28(水) 12:40:11.00

>>310
> 講師に聞いた事があるけどCOBOLのバッチ処理って何時間もかかるんだよね？
> WindowsのPCとSQLだと簡単なマクロで数秒て処理出来るのに・・

WindowsPCで数秒な処理ならメインフレームでは一瞬だよ
それに応答速度という点では、IMSなどの階層型データベースはRDBよりも高速だよ

316 ：デフォルトの名無しさん：2012/03/28(水) 14:25:29.96

>>310
問題はWindowsが1年間無停止とか出来ない事にある。

317 ：デフォルトの名無しさん：2012/03/28(水) 14:43:31.38

>>316
今時Windowsてわメインフレームが走る時代にWindowsが不安定とか一体何時の話だよｗｗ

東京証券取引所の基幹システムとして稼動するWindows
http://itpro.nikkeibp.co.jp/article/NEWS/20090609/331590/?SS=imgview&FD=-654674548

HPCでもダントツのパフォーマンスをたたき出すWindows
http://cloud.watch.impress.co.jp/docs/interview/20101224_416025.html

Windows上で稼動するメインフレーム
http://wsmgr.jp.brothersoft.com/screenshot-50450.html

Linuxより57倍速いWindows!!
http://www.elecom.co.jp/business/pickup/nas/201102/index.html


一方Linuxは…
Linux Daily Topics：2011年9月2日　Kernel.orgがトロイの木馬の侵入被害に｜gihyo.jp … 技術評論社
http://gihyo.jp/admin/clip/01/linux_dt/201109/02

Linux カーネルの基盤サイトがクラッキングの被害に - japan.internet.com
http://japan.internet.com/webtech/20110902/2.html

Linux Daily Topics：2011年9月15日　狙われるLinux… 今度はLinux Foundationが標的に｜gihyo.jp … 技術評論社
http://gihyo.jp/admin/clip/01/linux_dt/201109/15

【経済】 東証でシステム障害　２４１銘柄の売買一時停止
http://uni.2ch.net/test/read.cgi/newsplus/1328146640/l50

318 ：デフォルトの名無しさん：2012/03/28(水) 14:45:58.52

老害コボラーといい、UNIX/Linux使いといい、古臭いコンピュータを使い続けると脳味噌も腐るんだなｗ

319 ：デフォルトの名無しさん：2012/03/28(水) 22:55:22.18

お前は本当に馬鹿だな。
東証は取引時間帯以外ならシステム止められるじゃん。

320 ：デフォルトの名無しさん：2012/03/28(水) 23:44:52.30

>>318 ←ウインドウズしか使えないアホ発見ｗｗｗ

321 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/03/29(木) 05:30:17.02

それはちょっと前どこかで見た池沼コピペ君だからいじらないように

322 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/03/29(木) 05:32:59.66

>>317
その東証が去年末に大事故起こしてますよね。
ハードに精通せず、OS語るだけの3流エンジニアしかいないという事。

323 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/03/29(木) 05:55:56.15

>>322
> その東証が去年末に大事故起こしてますよね。
LinuxみたいなフリーフェアOSを使うからそんな事故が起こる。
Windowsを採用していれば事故は起こらなかったはず・・・。

324 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/03/29(木) 06:01:49.55

社保庁の消えた年金問題もCOBOLが原因だったらいしいねｗ

年金問題はコンピュータの問題
http://www.nikkeibp.co.jp/style/biz/column/tahara/070705_18th/index.html

325 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/03/29(木) 06:41:03.09

今時基幹システムにWindowsシステムを採用しないのはもはや罪だよな・・・

326 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/03/29(木) 06:42:33.23

全く使用するメリットが見出せないLinux

・安定性・信頼性
　Linux
　フリーソフトであるLinuxの安定性・信頼性はハッキリ言って問題外。
　1日連続で稼動させることすら困難。

　Windows
　いまやWindowsの安定性・信頼性はメインフレーム(汎用機)をも凌ぐ。
　世界中のメインフレームが全てWindowsServerに置き換わったのがその証拠。

・脆弱性
　Linux()
　Linuxで稼動している世界中のサーバーがクラックされまくっている。
　シェアが全くないLinuxはウイルス対策ソフトも皆無。

　Windows
　デフォルトスタンダードOSとしてあらゆる攻撃を受けてきたWindowsはいまや世界で一番強固なOSとなった。
　豊富なウイルス対策ソフトもさりながら、カーネルの構造的に絶対に外部からクラックされることが無いOSとなった。

コスト
　Linux
　フリーソフトなのでOSは無料。
　しかし上記内容により安定稼動させるのはほぼ不可能。
　またサポートが存在しないため自前で何とかするしかなくかえってコスト高となる。

　Windows
　OSは無料ではないが従来のメインフレームのOSと比較すると安価。
　もともと安定性に優れたOSであるため、誰にでも安定稼動させることが容易である。
　サポート面もマイクロソフトを始め、各ベンダーが完璧なサポートを行える体制となっている。
　またコンピュータOSとしてほぼ100%のシェアを誇っているので情報が豊富である。

327 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/03/29(木) 12:48:11.62

Windows上でCOBOLシステム動かしてるぜ！

328 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/04/03(火) 05:21:58.72

何年後か、MSが4-5年前のGMになることは必定だしな。
IBMだってあれだけ苦しんだんだから。

329 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/04/04(水) 23:34:56.89

全然話が変わるんだが、昔何処かのサイトで「人類最後のコボラー」みたいな話を読んだ記憶があるのだけど、誰か知らないかな？

330 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/04/05(木) 02:44:27.32

亀ネタだけど、Rubyが国際規格として承認されたね

331 ：営利利用に関するLR審議中＠詳細は自治スレへ：2012/04/06(金) 22:18:55.27

主にCOBOLが未だ死なない理由は・・・
・夜間処理等、定時で動くバッチシステムとしては比較的軽量。
UNIXサーバのシェルとの相性も悪くない。
・半世紀前からあるようなホスト現役の所とか、誤差がダメ！ゼッタイな金融機関等々、
大幅システム再構築を嫌がる所では重宝される。

いくらなんでも中小企業でメインフレーム(オフコン) + COBOLを現役で使用しているところは随分減ったと思うけど
民間の金融機関（特に保険）や社会インフラ系（鉄道・電気・水道・ガス）、各省庁ののバックエンドなどの
案件で扱ってる言語は、今でもCOBOLが入ってるメインフレームが大絶賛稼働中だよ。
ウォール街やTOPIXにて毎日取り引きされている何十億ドルもの株、債券、オプションなどもCOBOLを使ってるところが多い
ただそういったところでも一般ユーザーが目にするフロントエンド系は殆どオープン系だったりするから
エンドユーザーが稼動しているCOBOLを実際に目にすることは皆無だろうね。

一番問題なのはスパゲティコード化してる事。もはや解読不能。　
継ぎ接ぎだらけなのにさらに言語自体を理解してるやつがいなくてブラックボックス化なのに使うことは止められない
現在正常に動いているシステムがあったら、ソースは絶対いじるなってのはどこの業界も同じ。

332 ：デフォルトの名無しさん：2012/09/20(木) 12:04:16.27

IDENTIFICATION DIVISION.
PROGRAM-ID. AD3410SB.
AUTHOR. ASNN.
INSTALLATION. SYSTEM PROG.
DATE-WRITTEN. 2011.10.10.

333 ：デフォルトの名無しさん：2012/11/03(土) 17:18:33.69

システムまるごと捨てる思いがないと、COBOLは無くならないよ
最新言語に置き換えることは可能だけど、現行の再現は一部困難

トップがシステムごとCOBOL捨てます！って宣言しないとダメだねｗ

334 ：デフォルトの名無しさん：2012/11/04(日) 20:39:33.93

リライト案件もあるんだけど現行保障をしなきゃいかんてことで
COBOL設計をそのままJavaに置き換えただけの「見た目だけJava」が横行していたり。

なんというかCOBOLは死んでも精神は死んでないというか、はよ死んでくれというか。

335 ：デフォルトの名無しさん：2012/11/04(日) 23:51:42.18

企業の基幹システムなんざ今も昔も思想は大して変わらんからな…
変える必要が無いものをリスクを負ってまでわざわざ他の言語に変える必要な無いという事じゃね？

336 ：デフォルトの名無しさん：2012/11/05(月) 07:41:38.56

COBOLがいかんのじゃなくて、COBOL脳がいかんのだと思う

337 ：デフォルトの名無しさん：2012/11/05(月) 12:53:55.59

優秀なCOBOL脳はいまでも優秀、もう現場にはいないけどｗ
ダメなCOBOL脳は昔からダメ、そしていまでも現場に残ってるｗ

アルゴリズム（死語？ｗ）を理解してない奴ばっかり！

338 ：デフォルトの名無しさん：2012/11/06(火) 22:38:15.31

まあたしかにCOBOLみたいに書きたいんだったらCOBOLでいいじゃん
とJavaで１クラス１メソッドプログラムを見てそう思った。

339 ：デフォルトの名無しさん：2013/02/02(土) 21:09:25.29

この時期になんとか内定をもらったんですが、その会社はCOBOLが中心のようなんです
COBOLには将来性がないらしいですが、そんなに深刻なんですか？
あと、まったくのど素人なんですが、やっていけるものなんですかねえ

340 ：デフォルトの名無しさん：2013/02/02(土) 21:18:21.95

つべこべ言わずに勉強しろ

341 ：デフォルトの名無しさん：2013/02/02(土) 21:54:20.60

技術に興味を持って普段から色々と勉強してればそんな酷いことにはならないけど
COBOL「しか」できないようだと将来的に辛いだろうな。

342 ：デフォルトの名無しさん：2013/02/14(木) 20:16:09.41

>>339
今更の亀レスだが、、、
COBOLそのものはそんなに難しくはない
JCLやらなんやら覚える必要は勿論あるけど。

それ以上に難しいのが業務ロジック
なんでこんな処理をここでやる？ってのは業務を知らんと判らん

後、家では他の言語を勉強しとけ
C,Java etc

343 ：デフォルトの名無しさん：2013/02/15(金) 20:13:48.91

>>342
COBOL以外の言語に慣れた奴にとってはとても難しいと思うぞ

業務ロジックに関しては他の言語でもやってることじゃん

で、 「業務ロジックは俺に任せとけ!!!」な、 SEとかって日本固有の
馬鹿な職業ができる、と…

344 ：デフォルトの名無しさん：2013/02/16(土) 01:47:30.88

本屋でCOBOLの本を立ち読みしたことあるけど、コードを5行くらい読んだだけで
つらくなって棚に戻した

CやJavaに慣れちゃった者には、あれを受け入れることは生理的に難しい
Lispとかのほうがよっぽど受け入れやすいのではないかな

345 ：片山博文MZパンク ◆0lBZNi.Q7evd ：2013/02/23(土) 21:13:16.54

C/C++のバッチ処理とCOBOLのバッチ処理はどっちが早いですか？ 理由もお答え下さい。

346 ：片山博文MZパンク ◆0lBZNi.Q7evd ：2013/02/23(土) 21:56:18.29

誰も答えられないのかぁ？

347 ：デフォルトの名無しさん：2013/02/24(日) 00:12:35.81

設計の話じゃなくて早さの話になる言語はクソだし廃れる。

348 ：デフォルトの名無しさん：2013/03/03(日) 23:38:28.29

>>339
あのねえ。仕事は言語で覚えるより、仕事の内容で選んだ方がいいよ。

COBOLの会社は大抵は特定派遣の客先常駐で、自社に机がない所ばっかだから、そういうのでメンタルやられて、鬱病になる奴が多いよ。

なるべく自社内で開発してる会社を選んだ方がいいと思うよ。あとメンタルについてもキッチリとフォローしてくれる所。

349 ：デフォルトの名無しさん：2013/03/04(月) 09:33:44.44

>>1
30年近くも前だけど、COBOLで書いたPROLOGというのは
見たことがあるから、単なるDSLではないね。

350 ：デフォルトの名無しさん：2013/03/04(月) 20:54:34.32

それを言い出すと elisp あたりは COBOL よりハルカに柔軟に
どんな言語の処理系でも実装できる
でも elisp は emacs 専用の DSL だ

351 ：デフォルトの名無しさん：2013/03/27(水) 15:57:00.55

>>345
そもそも処理系もそれを動かすCPUや周辺機器すらもバッチ処理に特化した環境でやるCOBOLでしょ
Cはそれに特化した言語でもなければ、動かすマシンもそれに特化してるワケじゃない

352 ：片山博文MZパンク ◆0lBZNi.Q7evd ：2013/08/10(土) NY:AN:NY.AN

COBOLプログラムをJAVAに移植するためのライブラリってある？

353 ：デフォルトの名無しさん：2013/08/12(月) NY:AN:NY.AN

age

354 ：デフォルトの名無しさん：2013/12/25(水) 19:48:15.11

COBOL批判してる人も経営側になったら批判できんとおもうが。
現行COBOLから移行なんてすさまじいリスク。

355 ：デフォルトの名無しさん：2014/03/04(火) 20:47:38.84

早く古いシステムを排除しよっぜ

356 ：デフォルトの名無しさん：2014/03/05(水) 09:31:21.14

オープン系の基盤が未だに脆弱過ぎる現状ではCOBOLを駆逐するのはなかなか難しいんじゃない？
SoftBankですら基幹部分は未だにCOBOLで稼働しているし…

357 ：片山博文MZジェバンニ ◆T6xkBnTXz7B0 ：2014/03/06(木) 02:53:11.09

早くCOBOLに代わるものを作りたい

COBOLから他の言語へのコンバーターとか

358 ：片山博文MZジェバンニ ◆T6xkBnTXz7B0 ：2014/03/06(木) 03:18:55.80

変換で構造やロジックが失われるようなコンバーターはダメ

C++11で書いてみるか

359 ：デフォルトの名無しさん：2014/03/06(木) 05:55:56.55

cobol to javaコンバータがあるよ。

変換後のソースなぞ見たくもないけど

360 ：片山博文MZジェバンニ ◆T6xkBnTXz7B0 ：2014/03/06(木) 08:11:17.12

>>359
蟻がとう

361 ：デフォルトの名無しさん：2014/03/06(木) 08:59:31.08

>>360
あと、Cへのコンバータもあるよ。
オープンソースで。

362 ：デフォルトの名無しさん：2014/03/07(金) 03:46:44.18

でも、それって変換率99%とかって奴じゃないの？

363 ：デフォルトの名無しさん：2014/03/07(金) 11:30:25.69

GNU CobolはCへのトランスレータだよね。
http://sourceforge.net/projects/open-cobol/

364 ：デフォルトの名無しさん：2014/03/31(月) 19:38:37.71 ID:DtbGifhU

変換率100%ではなく必要なのは補償率100%

365 ：デフォルトの名無しさん：2014/04/11(金) 10:11:13.59 ID:rm3226Ee

小保ラーのみなさんこんにちわ

366 ：デフォルトの名無しさん：2014/04/11(金) 16:42:47.67 ID:8kKVOuK2

笹井なことにこだわんな

367 ：デフォルトの名無しさん：2014/08/06(水) 18:23:21.82 ID:D+VIlZrE

COBOLの面白さは、後にメンテする者が、いかにメンテし易い様に作るか、に尽きるな。

グローバル変数しかないところを、シンボル名の工夫でローカル変数的な扱いだと知らせる。
COPY句使えば継承もどきもできるが、読解牲が極端に悪くなるんでやらない。
SECTIONをモジュールと見なし、その中で機能を完結させる。

よーするに、
入力－編集－出力が一目で分かるような制御構造をこさえ、
SECTIONモジュール強度とかSECTIONモジュール結合度とか、SECTION間での基本的なところをキチンとさせたプログラムを書くのは、
自己満足でも楽しい。

後で読んだ人が「すげ～」って言うプログラムは、
概ね高度なテクニックよりも、
何をやりたいのかやろうとしてるのかが一発で分かる＝実装思想の一貫性が読み取れる
じゃないかと思ってる。

他の言語でも同じでないの？
　

368 ：デフォルトの名無しさん：2014/08/21(木) 23:27:03.61 ID:B+tsMt3g

>>367
メンテしやすいPGを心がけてる。

369 ：デフォルトの名無しさん：2014/08/22(金) 04:26:36.55 ID:cJuKMHCG

http://jobinjapan.jp/job-listing/keyword-cobol.html

370 ：デフォルトの名無しさん：2014/12/09(火) 23:24:10.62 ID:/gO7PMz6

COBOLの代替技術をまとめてくれ。

371 ：デフォルトの名無しさん：2014/12/10(水) 07:23:05.24 ID:58oVhltK

>>370
COBOLにローカル変数とスコープの概念を導入すれば、ほぼ一通りの物は書ける。

372 ：片山博文MZ ◆T6xkBnTXz7B0 ：2014/12/10(水) 10:29:31.67 ID:X4ZXIzIa

パックトBCDってもう古臭い技術だよな？ 4ビットで10進一桁なんてやらないっしょ？

373 ：デフォルトの名無しさん：2014/12/10(水) 10:38:29.07 ID:X4ZXIzIa

あげ

374 ：デフォルトの名無しさん：2014/12/10(水) 11:15:57.96 ID:X4ZXIzIa

なるほど。IEEE754-2008使えばいいんだ。

375 ：デフォルトの名無しさん：2014/12/10(水) 11:52:58.53 ID:X4ZXIzIa

IEEE754-2008が使えるから、COBOLは要らない。ファイナルアンサー？

376 ：デフォルトの名無しさん：2014/12/20(土) 21:00:40.83 ID:hZTUqQym

>>371
COBOL85からローカル変数はあるしCOBOL97にはクラスの概念もあるんじゃなかったかの？

377 ：デフォルトの名無しさん：2014/12/20(土) 23:38:37.34 ID:ju2bEFwe

>>376
そう、以前の記憶で最近のCOBOLはローカル変数導入したはずとgoogle先生に尋ねたんだが
どうにも見当たらなかったのさ。

378 ：デフォルトの名無しさん：2014/12/25(木) 11:47:31.00 ID:D1gJKcDI

COBOL2002さんはいつになったらオブジェクト指向言語として活躍するのかな…

379 ：デフォルトの名無しさん：2015/03/21(土) 23:23:00.32 ID:IxJMreKK

うちのシステム、COBOLからCOBOLに移行

380 ：デフォルトの名無しさん：2015/04/12(日) 14:08:18.42 ID:YcKO1mev

◆COBOL　は　はじまった　ばかり　だ

381 ：デフォルトの名無しさん：2015/08/13(木) 18:22:41.93 ID:TzobCxoU

◆COBOL　は　はじ、　まった　ばか　りーだー

382 ：デフォルトの名無しさん：2015/10/15(木) 14:01:10.37 ID:DKqxwJYd

【社会】損保ジャパンがCOBOL一掃を決断･2ch.net
http://daily.　2ch.net/test/read.cgi/newsplus/1444867000/

383 ：デフォルトの名無しさん：2015/10/26(月) 15:08:34.65 ID:yQmIbum5

かなC

384 ：デフォルトの名無しさん：2015/12/21(月) 12:59:39.69 ID:FdAwO3Sp

みずほ銀行はCOBOLで楽天銀行はjavaか？
それにしても東芝を330円で200万円分買ってしまったぞ
どうしてくれんだ？訴訟するか

385 ：デフォルトの名無しさん：2015/12/21(月) 19:07:41.09 ID:OqbIiNrA

売れ
200円まで待て

TOPへ TOPへ 　

		ブックマークへ