3:仕様書無しさん2018/05/26 22:36:32ID:
仕事はあるある
10:仕様書無しさん2018/06/06 05:18:55ID:
まだあるのかこれ
11:仕様書無しさん2018/06/10 13:59:30ID:
マイグレーション元のCOBOLと、マイグレーション先のJavaの両方できれば当分需要ありそうだよなあ。片方できるのはいっぱいいるけど両方は全然いない。
まあマイグレーションって基本ブラック案件だから、できないほうがいいのかもしれないが。
12:仕様書無しさん2018/06/10 16:06:27ID:
COBOL捨てるならマイグレーションとかしないで、新規システムにするだけじゃないの。
13:仕様書無しさん2018/06/10 18:30:03ID:
以前の仕組みを理解している人がいない
14:仕様書無しさん2018/06/10 20:09:38ID:
だったら、
古いのは捨てる
古いのはそのまま使う
のどちらかだろう?

後者ならCOBOLの出番があるが、
そのまま使うならjavaの出番はない
15:仕様書無しさん2018/06/11 08:17:09ID:
COBOLシステムの大規模改修自体が出来ないから、そのまま使ってるんですが?
だから運用で対応するわけね
16:仕様書無しさん2018/06/11 20:45:51ID:
COBOLはあまりに量が多すぎて、その上継ぎ足し継ぎ足しで使われてて
(ただし仕様書は継ぎ足されない)基本何してるのかもさっぱりわかんないから
COBOL捨てるって選択をいれると、まず金の面で話にならねえからなあ
18:仕様書無しさん2018/06/29 18:00:29ID:
世の中には無くなる無くなると言われながら、
何だかんだで残ってるものがいっぱいあるよね。
COBOLもその1つ。
21:仕様書無しさん2018/07/14 21:09:07ID:
企業の事務処理全般が手書きが常識の時代から
全てIT化するのが常識の時代へ移り変わったのはバブル景気の時

企業は節税目的もあって一斉にIT化に費用を掛けた
当時技術者の数がまったく足りなくて、いち早く技術者として一人前になれる
ある意味簡易な言語がCOBOLであり
高度なことができないからかえって安全な言語だった

その時に作られた膨大なシステムがほぼCOBOLだから
これを駆逐するのは多分あと100年経っても無理だと思うんだぜーーー

私は還暦後のアルバイトとしてコボラーに戻る予定
今は流行りの言語やってるけど周りの若い子の
すぐ諦める姿勢には苦笑いしかでないわ
それは言語の仕様の問題じゃなくて、あなたの根気の問題じゃねーの?って
内容の愚痴をさも正当な理由かのように、愚痴愚痴と煩いわ
22:仕様書無しさん2018/07/14 23:57:30ID:
古いCOBOL資産は改修しない方向なんだよ
運用でカバーする
23:仕様書無しさん2018/07/15 00:07:31ID:
他の言語も大差ないのでは?
COBOLよりは遥かにマシだと思うけど
24:仕様書無しさん2018/07/15 01:19:03ID:
バブルな時ってパソコンと言えばMS-DOS
業務用としては非力すぎるのでバブル期に導入されたのは
メインフレームやオフコン
それらはほぼ独自OSで使える言語はほんの少しだけ
選択肢は基本的にCOBOLしかなかったんだよね
もちろんUNIXとかも日本に上陸してたから素のCで組むこともできたけど
新人を急遽C使いするぐらいならCOBOL使いにした方が安全かつ安上がりなんだよ
28:仕様書無しさん2018/07/26 16:52:29ID:
バッチ処理部分をOpenCOBOL化してUI部分をPHP、Pythonで作れればJavaより安く作れる
30:仕様書無しさん2018/08/05 13:00:09ID:
お金の計算をできるのはCOBOLだけだ。
ゆえに、銀行でつかわれるのだ。
31:仕様書無しさん2018/08/05 16:45:24ID:
C#、Javaは計算出来るが金額計算には向かない
それを無理やり金融機関でシステム移行に提案したのは大手Sier
この人たちの罪は大きい
32:仕様書無しさん2018/08/05 19:40:42ID:
実際には桁の大きい10進数計算が正確にできればいいだけだよな。
で、そういうのはライブラリで出回ってて既に言語は関係なくなっているように思うのだがなあ。
かといってその一歩を踏み出す勇気はないと。金扱ってるのでリスクは極限まで下げたい。
ということでCOBOLは生き続けているんだろうな。
34:仕様書無しさん2018/08/06 16:52:48ID:
>>32
>>ライブラリ
OpenJDKででも存在してれば、ね
実際メガバンクは自前で金額計算部分を銀行個々でライブラリ化してるだろう
それをライセンス徴収開始で御破算にするのは今更出来ない
みずほはプログラマ確保のし易さからJava採用したが、結果的に納期に間に合わず外国人が実装してた
りそなみたいにCOBOLでUI部分も作れるなら、その方が賢かったが三菱UFJへの対抗から安易にJavaへの移行を決定して未だに苦労してる
33:仕様書無しさん2018/08/05 21:57:42ID:
既に稼働しているCOBOL資源が多過ぎて、それら全部変えるにはコストも時間も掛かり過ぎるし、
別の言語で新たに起こし直す以上どうしたってリスクも避けられないからな。
35:仕様書無しさん2018/08/06 21:54:24ID:
産みの苦しみだな
38:仕様書無しさん2018/08/08 16:53:40ID:
みずほがグダグダなのは取締役連中がダメだから、が一番大きいけどね
遅かれ早かれ逝くと思う
42:仕様書無しさん2018/08/10 23:17:38ID:
今はC#やってるんだけど、同じようなバッチ処理を作ってもC#だとめちゃ早く作れる
色々な便利機能がついてるから
同じことをCOBOLで作ろうと思うと2〜3倍は時間がかかると思う

だからCOBOLがダメだって話じゃないよ

最後にCOBOLの開発案件にかかわったのは3年前だけど
COBOLの開発なのに、そのスケはおかしーーーーんじゃないの?ってぐらい
開発期間が異常に短くてスケ通りにまったく進まないどころか
スケで予想されてる2〜3倍は時間がかかったので下請け会社は大赤字だったみたい

で、このスケを引いて見積もり書いたのも仕事発注した窓口もJavaしかやったことありませんって人だった
これだからCOBOLわーーーーーって陰口言いまくりだったみたいだけど
COBOLで納得して仕事受けたんちゃうんかい!って思った

今日はC#で作業領域の集団項目とかREDEFINEとかCOPY句機能が使えたらなーーーとボーっと考えてた
いちいち、newとかnewとかうぜーーーーーよ!
そして集団項目と再定義使わせろ
45:仕様書無しさん2018/08/11 06:07:11ID:
>>42
それはJavaでの開発した事無い会社が悪い
COBOLでの開発経験有る会社ならそんなスケジュールしないでしょ
そもそもオブジェクト指向言語のJavaでの開発工数とCOBOLの開発工数を同じ感覚でやってたらアホとしか言えんわw
48:仕様書無しさん2018/08/11 22:22:46ID:
C#ってjavaのようなものなんでしょ
50:仕様書無しさん2018/08/12 00:26:51ID:
>>48
言語仕様はC++ベースは同じ
問題はCOBOLの様に金額計算や小数点計算に向かない事
59:仕様書無しさん2018/08/17 12:24:47ID:
COBOLの数値精度の精度が高いんじゃなく、やれることが限られてるため誰がプログラム作っても計算精度に差がないこと
60:仕様書無しさん2018/08/17 13:35:47ID:
>>59
その上、計算コードが読み易い
他の言語は人によって読めないから
61:仕様書無しさん2018/08/17 16:34:24ID:
そうだよね
COBOLの計算式は本当に算数のようで
プログラム未経験者でも見やすいと思う

他の言語は自由がききすぎて
お金の計算、特に利息などの少数以下の取り扱いが
どの段階でどの様に丸めるかとか
あーんまり考えたことない技術者だらけだと思う
丸め方で積み重なれば数億の損害になったりするから
ここは非常にシビアなところなんだけどね
62:仕様書無しさん2018/08/17 20:32:26ID:
>>61
実際メガバンクでCOBOL→Javaに移行した所は全く誤差が無い、とは言えない危険性が有る
経営者が気づいて無さそうだが
74:仕様書無しさん2018/08/20 01:14:26ID:
そもそもコボラーは技術者じゃないよ
昔は商業高校でCOBOL教えていた
だからCOBOLしかやったことない40過ぎのおばちゃんのスキルシート見ると最終学歴が商業高校だったりする
実務的には簿記をやるレベルってことさ
76:仕様書無しさん2018/08/20 03:09:32ID:
そういう人達を排除した結果がCOBOL→Javaだった
で、オラクルに梯子外された
108:仕様書無しさん2018/08/28 02:28:18ID:
某銀行
銀行側「なぜこんなバグが見つけられなかったの?」
開発会社「作業人数不足です」
銀行側「募集かけろよ!」
開発会社「もう市場にCOBOLのエンジニアはいません」
銀行側「育成しろよ!新入社員いるべ?」
開発会社「え!?いや…
114:仕様書無しさん2018/08/29 02:01:42ID:
Javaももうすぐ死ぬしなあ
昔の人の知恵を馬鹿にしちゃ駄目だよね
132:仕様書無しさん2018/09/24 17:34:49ID:
もう三十年近く前から無くなる無くなると言われて無くならないのがCOBOL
133:仕様書無しさん2018/09/24 17:58:06ID:
言語変えるリスクとメンテナンス性考えれば無くす必要性無いから
地方の金融システムでもまだ残ってる
134:仕様書無しさん2018/09/24 20:28:24ID:
全体の割合から言うと、もう無くなったと言ってもいいレベルだろう
135:仕様書無しさん2018/09/24 22:55:38ID:
願望書いてもCOBOLはなくならないよ?
136:仕様書無しさん2018/09/24 23:16:59ID:
COBOL無くせってうるさいヤツは若いヤツらだけ
185:仕様書無しさん2018/10/27 19:03:38ID:
COBOLより先にVBやC#、Javaが先にオワコンになるなんて想像もしなかったわ
186:仕様書無しさん2018/10/28 13:50:42ID:
安定稼働しているから触らなくてもいいからでしょ
187:仕様書無しさん2018/10/28 15:21:31ID:
年号と消費税は変更する必要がある
221:仕様書無しさん2018/11/05 16:11:00ID:
COBOLは大きな案件変動も無く、プログラマ増加も無く続く
何も変わらない
大体、新人にCOBOL学習させたら辞めるし
銀行(地方)とかのシステム部で新人にCOBOL修得させようとしたらその新人が辞めるパターンが常
222:仕様書無しさん2018/11/06 21:13:28ID:
大きな変化は無いかも知れないけど、決して楽な仕事でもないからなあ。
223:仕様書無しさん2018/11/08 21:57:47ID:
贅沢なこと言うなよ
エラー出まくり野良VBAのメンテするより楽で稼げるよ
224:仕様書無しさん2018/11/09 01:13:32ID:
>>223
それな
225:仕様書無しさん2018/11/09 01:15:54ID:
て言うかぁ、バグってることにも気付かないのがCOBOLのシステム〜ぅ
228:仕様書無しさん2018/11/24 18:04:52ID:
COBOLに限らないのかも知れないが、大昔に作られたでかいプログラムのソースは大抵訳分からないよなw
238:仕様書無しさん2018/12/27 21:37:41ID:
キャッチアンドリリースの繰り返し
決してずっと居てほしくはない
それがコボラーの扱われ方