0001デフォルトの名無しさん2011/09/20(火) 00:06:43.84
COBOLでCOBOL書ける?
>>476
Linuxみたいなフリーウェアなんて不安定すぎて業務システムじゃ使えないと思う
業務用で使うならWindowsくらい信頼性が高くないとだめ 0478デフォルトの名無しさん2019/09/24(火) 12:40:42.20ID:1Nes97xL
ちょっと待った！
Windowsの信頼性が、どうだって？
｢それはもしかしてギャグのつもりで言ってるのか？｣
知らんけどｗ
>>478
Linuxより信頼性が高いと言う意味じゃね？ >>477
Windowsサーバーの金融系システムは旧ユニシス系の一部地銀だけだよ >>479
まさか
LinuxサーバーはWindowsサーバーの同等以上だよ >>476
勘定系はCOBOLメインフレーム残して
周辺はJavaでレッドハットエンタープライズだとよ
ライセンスかかるシステム更改するからそら何千億円も予算かかるわな COBOLプログラマ、みずほ銀行案件から解放されて大勢あぶれてるらしいが、、
そもそもニーズの方が多いからね
0485デフォルトの名無しさん2020/04/06(月) 18:49:47.25ID:a0GoWO+s
0486デフォルトの名無しさん2020/04/06(月) 20:39:28.86ID:NTuQcwE+
こういうのって何でアップデートしないで
古いプログラムで管理してんの？
COBOLじゃないと出来ないことなの？
0487デフォルトの名無しさん2020/04/06(月) 21:02:03.42ID:jD8bzoth
アメリカの知事さん困っているよ
>>486
COBOLがどうとかじゃなくて、
1. 当時の手法でやってるため、複雑怪奇なコードが何千万行もある。
2. 当時の考え方のやつが指揮をしてるため、改善案に対してことごとく動いてるから改善するなと圧力をかける
この２つでアップデートが実質不可能になってる そんなの無視してC言語で作り直したバージョンどこかに作らせればいいのに
>>489
無理。「俺は長年コボラー共を指揮してきた。俺の決定以外は何も認めん」
この一言で終わり >>489
ワロタ
Cで作り直すくらいなら自社でCOBOLプログラマーを育成し続けたほうが1000倍効率的 0492デフォルトの名無しさん2020/04/07(火) 23:00:17.06ID:Fb6a6l1J
>>494
古くからある大手企業の基幹システムの殆どは未だはCOBOLがフツーに稼働してるよ 30年前「COBOLはもう時代遅れ」
今現在「COBOLはもう時代遅れ」
30年後「COBOLはもう時代遅れ」
COBOL「ボクノ テイネンハ イツ？」
現実にはIBMがあるかぎり常に最前線なんだよなぁ
規格も更新されつづけてるし
金融機関じゃほぼCOBOLらしいけど
計算の処理や管理ってそんなに他の言語で作り直すの面倒なのか
作り直しても得るものが何もないからじゃないか？
パフォーマンスは低下する、機能は旧システムより劣化する、
止まったときの事は何も考慮されてない、作り直しの課程でバグを量産する
若い人は最新の言語で作り直せば、古くてダメな言語が足を引っ張ってた部分を全部解決
みたいに幻想抱いてるけどさ、そもそもダメな言語でもなんでもないっていう
アメリカじゃ時代遅れすぎて使えるやつボランティア募集するくらいダメな言語じゃん
>>499
COBOLの問題
1. 汎用機+ベンダー依存だからめっちゃ高コスト
2. 再利用性が低い言語仕様なのでコピペ量産+変更に対して脆弱
レガシーシステム以外でCOBOLが使われないのは主に2の理由
コストは汎用機脱却で10分の1になるケースとかざらにある
ただハード・OS・言語・ミドルウェアのすべてが統合管理できる事の価値を理解してない会社は移行後に痛い目見る 再利用性なんて幻想だぞ、特にJava
やろうとすればするほど泥沼にはまる
汎用機だから高コストはちょっとわからんなぁ
高品質なサポート受けられるし、信頼性高いし、トータルでは安上がりなんじゃ？
ソース継ぎ足しすぎて同じ動作するものを他の言語で作ったら余計複雑化するからもうCOBOL使うしか無いってだけ？
プログラム数やステップ数は多いけど
1つ1つのプログラム自体はそんなに複雑なものじゃない
移行しない一番の理由は事なかれ主義
COBOLを使い続けてるところの大半は
前例主義でリスクを取りたがらない文化が染み付いてる
0507デフォルトの名無しさん2020/04/15(水) 23:09:15.68ID:NI3EKOWz
多分、対応できないのは
「えっ、コンピュータって大体WindowsやMacやLinuxと同じ感覚で使えるものじゃないんですか？」
って部分でCOBOLじゃなさそう
そもそも重要な部分に使われてる言語ならボランティアで募集してるのが頭おかしい
普通に高給で募集しろよ
COBOLで作ってても既存のオンラインプログラムをスケールさせるのに
わざわざ新しくCOBOLプログラマーを雇う必要はないよね
それにWebをCOBOLで作ってるとも思えないから
発注側が中身を何も理解してないだけのように見える
COBOL=高コスト
はOpenCOBOLで解決出来る
0512デフォルトの名無しさん2020/04/23(木) 11:55:12.91ID:/9l83X+Q
ﾁﾝｹなプライドばかりがいっちょ前な、使えない中高年SE
ってイメージがつきまとうかと(゜ω゜)
ﾁﾝｹなプライドばかりがいっちょ前な、使えない若手SE
に書き換えるとあっというまにWeb系に当てはまるという
0514デフォルトの名無しさん2020/04/24(金) 15:45:40.86ID:V4ZZaTWw
結局、本質はいっしょなんだな、これがヽ(゜Д゜)ノ
0515デフォルトの名無しさん2020/07/24(金) 04:11:29.96ID:xb3CAx+q
GOTOキャンペーンでもCOBOLは大活躍です！
>>505
COBOLプログラムの置き換えはかなりお金かかるのよ
数百億円単位平気でいくから
コードを書いた古いプログラマはもうおらず
暗号と化したコードの解読から… 汎用機時代はPL/IやFortrunで中間処理してCOBOLで印刷というシステムが多かったのに、なんでCOBOLだけソフトウェアクライシス何だろうと考えた
俺が新人だった90年代初めでさえCOBOLプログラマの減少は問題になってたと思い出したわ
我々の武器は３つ
COBOL、PL/I、RPG、それとREXX
みずほ銀行で障害
2/28が日曜日の場合のバグかな
それかうるう年計算ミスか
DSLなら必要だろう、よく出来てる
新たなCOBOLを再発明してどうなる
>>不要論
最近COBOLの案件多いよ
オープンCOBOLに組み換えするパターンとJavaに置き換えるパターンに分かれてる
>>523
>>オープンCOBOL
ほとんどNetCOBOLだね
NetCOBOLは制限事項が多い
GnuCOBOLって見かけ無いな りそなはMF-COBOL
LinuxでSQL Server
固定長レコード特化なcobolのロジックを汎用言語に移植したらとても残念な事になると思う…得にjavaとか向かんでしょ
だからとて新規に固定長レコード特化な言語作ったらキーワード違うだけのcobolにしかならんでしょ
0527デフォルトの名無しさん2022/08/23(火) 17:11:05.08ID:z4kEZKAc
Identification Division