-
プログラマー
-
COBOLって今需要増えてるの？Part7
-
UPLIFTで広告なしで体験しましょう！快適な閲覧ライフをお約束します！
■前スレ
COBOLって今需要増えてるの？Part5 [無断転載禁止]©2ch.net
http://medaka.2ch.ne...cgi/prog/1481468519/
COBOLって今需要増えてるの？Part6©2ch.net
https://medaka.5ch.n...cgi/prog/1497126175/ - コメントを投稿する
-
髪の毛は増えてない！
-
仕事はあるある
-
> 999 名前： 仕様書無しさん [sage] 投稿日： 2018/05/26(土) 19:52:09.83
> >>996
> COBOLの現場は今でもCOBOL85が主流だから
> FUNCTIONの出る幕ないよね
利用者定義関数のことなら確かにCOBOL2002からだけど、
組み込み関数ならCOBOL85の時点でとっくに実装されてた。 -
組み込み関数って第3次追補1規格だから、
日本に入ってくるのが遅かったんじゃないの？
古いCOBOL85の仕様書には載ってなくても不思議はない。 -
第3次追補1規格は米国では1989年、日本でも1992年制定か。それでもなかなか古いね。
-
EVALUATE ZERO
WHEN FUNCTION MOD(YEAR 400)
DISPLAY '閏年'
WHEN FUNCTION MOD(YEAR 100)
DISPLAY '平年'
WHEN FUNCTION MOD(YEAR 004)
DISPLAY '閏年'
WHEN OTHER
DISPLAY '平年'
END-EVALUATE. -
まだあるのかこれ
-
マイグレーション元のCOBOLと、マイグレーション先のJavaの両方できれば当分需要ありそうだよなあ。片方できるのはいっぱいいるけど両方は全然いない。
まあマイグレーションって基本ブラック案件だから、できないほうがいいのかもしれないが。 -
COBOL捨てるならマイグレーションとかしないで、新規システムにするだけじゃないの。
-
以前の仕組みを理解している人がいない
-
だったら、
古いのは捨てる
古いのはそのまま使う
のどちらかだろう？
後者ならCOBOLの出番があるが、
そのまま使うならjavaの出番はない -
COBOLシステムの大規模改修自体が出来ないから、そのまま使ってるんですが？
だから運用で対応するわけね -
COBOLはあまりに量が多すぎて、その上継ぎ足し継ぎ足しで使われてて
（ただし仕様書は継ぎ足されない）基本何してるのかもさっぱりわかんないから
COBOL捨てるって選択をいれると、まず金の面で話にならねえからなあ -
こりゃCOBOLがなくなるな
-
世の中には無くなる無くなると言われながら、
何だかんだで残ってるものがいっぱいあるよね。
COBOLもその1つ。 -
>>17の願望でしかないもんなぁ
-
絶滅危惧種のウナギの価格が暴騰しているのと一緒
かつて中国産のうなぎは150円も出せば買えたが今は何千円もするだろ
しかも引退したオッサン達が仕様書もろくに作らずに、こねクリ回したスパゲッティコード
これは罰ゲーム、前世代のケツ吹きだから、若い人はやりたがらないということ
コボラーのジョークがウィキペディアにまでのってるw
https://ja.m.wikipedia.org/wiki/COBOL
IDENTIFICATION DIVISION
ENVIRONMENT DIVISION
DATA DIVISION
PROCEDURE DIVISION
だったような
商業高校の情報系ってまだCOBOLやってるのかな？ -
企業の事務処理全般が手書きが常識の時代から
全てIT化するのが常識の時代へ移り変わったのはバブル景気の時
企業は節税目的もあって一斉にIT化に費用を掛けた
当時技術者の数がまったく足りなくて、いち早く技術者として一人前になれる
ある意味簡易な言語がCOBOLであり
高度なことができないからかえって安全な言語だった
その時に作られた膨大なシステムがほぼCOBOLだから
これを駆逐するのは多分あと100年経っても無理だと思うんだぜーーー
私は還暦後のアルバイトとしてコボラーに戻る予定
今は流行りの言語やってるけど周りの若い子の
すぐ諦める姿勢には苦笑いしかでないわ
それは言語の仕様の問題じゃなくて、あなたの根気の問題じゃねーの？って
内容の愚痴をさも正当な理由かのように、愚痴愚痴と煩いわ -
古いCOBOL資産は改修しない方向なんだよ
運用でカバーする -
他の言語も大差ないのでは？
COBOLよりは遥かにマシだと思うけど -
バブルな時ってパソコンと言えばMS-DOS
業務用としては非力すぎるのでバブル期に導入されたのは
メインフレームやオフコン
それらはほぼ独自OSで使える言語はほんの少しだけ
選択肢は基本的にCOBOLしかなかったんだよね
もちろんUNIXとかも日本に上陸してたから素のCで組むこともできたけど
新人を急遽C使いするぐらいならCOBOL使いにした方が安全かつ安上がりなんだよ -
>>23
COBOLはオープンシステムでも動くけど、PL/1はどうにもならないよ -
>>24
4GLなんかが流行ったね -
>>22
Javaライセンスの影響でOpenCOBOLの評価が変わる -
バッチ処理部分をOpenCOBOL化してUI部分をPHP、Pythonで作れればJavaより安く作れる
-
C#やJavaだと%で余り算出してる人が、いざCOBOLになるとわざわざ使いもしない商格納用の変数定義までしてDIVIDE文を使う不思議。
-
お金の計算をできるのはCOBOLだけだ。
ゆえに、銀行でつかわれるのだ。 -
C#、Javaは計算出来るが金額計算には向かない
それを無理やり金融機関でシステム移行に提案したのは大手Sier
この人たちの罪は大きい -
実際には桁の大きい10進数計算が正確にできればいいだけだよな。
で、そういうのはライブラリで出回ってて既に言語は関係なくなっているように思うのだがなあ。
かといってその一歩を踏み出す勇気はないと。金扱ってるのでリスクは極限まで下げたい。
ということでCOBOLは生き続けているんだろうな。 -
既に稼働しているCOBOL資源が多過ぎて、それら全部変えるにはコストも時間も掛かり過ぎるし、
別の言語で新たに起こし直す以上どうしたってリスクも避けられないからな。 -
>>32
>>ライブラリ
OpenJDKででも存在してれば、ね
実際メガバンクは自前で金額計算部分を銀行個々でライブラリ化してるだろう
それをライセンス徴収開始で御破算にするのは今更出来ない
みずほはプログラマ確保のし易さからJava採用したが、結果的に納期に間に合わず外国人が実装してた
りそなみたいにCOBOLでUI部分も作れるなら、その方が賢かったが三菱UFJへの対抗から安易にJavaへの移行を決定して未だに苦労してる -
産みの苦しみだな
-
>>35
産みの苦しみだよね -
>>34
苦労してるね -
みずほがグダグダなのは取締役連中がダメだから、が一番大きいけどね
遅かれ早かれ逝くと思う -
やはりCOBOL復活だな
-
今はC#やってるんだけど、同じようなバッチ処理を作ってもC#だとめちゃ早く作れる
色々な便利機能がついてるから
同じことをCOBOLで作ろうと思うと２〜３倍は時間がかかると思う
だからCOBOLがダメだって話じゃないよ
最後にCOBOLの開発案件にかかわったのは３年前だけど
COBOLの開発なのに、そのスケはおかしーーーーんじゃないの？ってぐらい
開発期間が異常に短くてスケ通りにまったく進まないどころか
スケで予想されてる２〜３倍は時間がかかったので下請け会社は大赤字だったみたい
で、このスケを引いて見積もり書いたのも仕事発注した窓口もJavaしかやったことありませんって人だった
これだからCOBOLわーーーーーって陰口言いまくりだったみたいだけど
COBOLで納得して仕事受けたんちゃうんかい！って思った
今日はC#で作業領域の集団項目とかREDEFINEとかCOPY句機能が使えたらなーーーとボーっと考えてた
いちいち、newとかnewとかうぜーーーーーよ！
そして集団項目と再定義使わせろ -
途中で送信しちゃったわ
集団項目から集団項目への転送も簡単にやらせろーーーー
せめてコレポン使わせて・・・ -
コレポンって楽な機能だよね
-
>>42
それはJavaでの開発した事無い会社が悪い
COBOLでの開発経験有る会社ならそんなスケジュールしないでしょ
そもそもオブジェクト指向言語のJavaでの開発工数とCOBOLの開発工数を同じ感覚でやってたらアホとしか言えんわw -
【料金搾取】SEの結婚障害原因【無能残業】
☆偽装請負多重派遣SEの結婚相手の犠牲原因☆
両親や親戚に反対されましたが、偽装請負多重派遣会社に高額搾取金を提供したり時間外労働違反で家事をしないSEと結婚してしまい、生活困難で中絶と離婚をしました。現在は犯罪損害のない相手と共働き生活をして、数億円損失を防げました。
・モラルがない
・キモい
・ファッションセンスがない
・コミュニケーションが苦手
・コンピューターが趣味
・プログラムの料金以上の不利益生産
・プログラムの巨額利益を客先に提供
・プログラムの巨額報酬を人売に提供
・プログラムの知的財産を人売に提供
・ITスキルが高いのに低料金請求
・高度情報処理技術者なのに請求料金不足
・高利益なのに請求料金不足
・高生産なのに請求料金不足
・高需要なのに請求料金不足
・学習多いのに請求料金不足
・人員不足なのに早期退職
・会社員なのに早期退職
・PC使用過多で不健康
・運動不足で不健康
・高稼働で不健康
・高稼働で家事困難
・低収入で生活困難
・低収入なのに鬱病多発
・低収入なのに早死多発
・不利益なのに断らない
・偽装請負の多重派遣損害あるのに稼働
・裁判官が技術判断不能だから賠償困難
【IT業界】独身が多い職業の象徴として「ITエンジニア」が取り上げられる
http://itpro.nikkeib...110200713/?ST=spleaf -
C#ってjavaのようなものなんでしょ
-
ボラクルが関わってないからリスクが大違い
-
やはりCOBOLが一番。日本人はなぜか古くても良いものを大事にしないからおかしい。
-
金融系でJavaへ移行してライセンスの話で梯子外された中小企業は死亡状態
-
具体的に何がどうしたんだ？
-
実業務でこんな大きな数を扱うことはまず無いだろうが、
FUNCTION INTEGER(FUNCTION LOG10(999999999999999999))が18を返してきた。
OpenCOBOLとIBM Enterprise COBOL for z/OSで確認。 -
あくまでも思い込みです
-
なんでコボルは数値計算が強いの？
今の言語でも結構な精度だと思うけど、何が違ってどんな技術的理由によるの？ -
COBOLの数値精度の精度が高いんじゃなく、やれることが限られてるため誰がプログラム作っても計算精度に差がないこと
-
そうだよね
COBOLの計算式は本当に算数のようで
プログラム未経験者でも見やすいと思う
他の言語は自由がききすぎて
お金の計算、特に利息などの少数以下の取り扱いが
どの段階でどの様に丸めるかとか
あーんまり考えたことない技術者だらけだと思う
丸め方で積み重なれば数億の損害になったりするから
ここは非常にシビアなところなんだけどね -
COBOL需要、と言うか金融系では再評価されてる
-
その根拠は？
-
>>64
うーんたぶんだけど
他の言語だと技術者の粒が揃わず品質にバラつきが出やすいからじゃないかな？
今私はオブジェクト指向言語を使ってるけど、
バージョンアップ対応で元のソースを解読してると
何度も何度も車輪の発明をしてて馬鹿かとしか思えなかった
言語としては優れてるのかもしれないけど
技術者およびマネージャーの意思疎通が図られておらず
どいつもこいつもオレ天才やらオレ無双の独りよがりなコーディングしてるわ
その点、COBOLだと強制的にある程度の画一性や品質が確保される -
>>どいつもこいつもオレ天才やらオレ無双の独りよがりなコーディングしてるわ
それはVB4,5,6の時でも有った話
実質、プログラマのメンタルは変わってない
それがオブジェクト指向でも発揮されてコードが他人に理解しにくくなってる
>>その点、COBOLだと強制的にある程度の画一性や品質が確保される
この一点につきる -
>>65
それ金融系がということじゃなく、根拠は自分がそう思ってるだけだよね -
数値計算だけ特別にクラス作って処理すれば、他言語でもコボルの代わりになれる？
-
数値計算といってもCOBOLで使われるのはあくまでも整数計算のみ
固定小数点のね -
要は小学生で習う程度の算数計算に強いだけじゃん
金勘定の基本は算数だけどさ -
>>72
あなたが技術者でないことはわかった -
そもそもコボラーは技術者じゃないよ
昔は商業高校でCOBOL教えていた
だからCOBOLしかやったことない40過ぎのおばちゃんのスキルシート見ると最終学歴が商業高校だったりする
実務的には簿記をやるレベルってことさ -
蛇腹ーは簿記すら理解できないじゃん。。。
-
そういう人達を排除した結果がCOBOL→Javaだった
で、オラクルに梯子外された -
話がずれてるのは何でだろうね
-
COBOLが再評価されてるって、JavaからCOBOLへのシステム再構築があるってことか
マジで？ -
>>78
Java→COBOLは無いよ
そういう所はライセンス払ってJava継続するかスクリプト系言語に変えるかしか無い
COBOL→Javaへ移行検討してた所が方針見直してCOBOLのままオープン化するって事 -
>>79
なんでそこでスクリプト系言語が出てくるんだ？ -
そんな事例聞いたことないのだけど、ソースは自分がそう思ったとかじゃないよね。
-
だから一旦、Javaに移行したらJavaの蟻地獄にはまって抜けれ無いよ
-
goto文だらけのCOBOLよりマシ
-
今は構造化プログラミングでGOTO文地獄って少なくなってる
-
GOTOはEXIT行き以外は禁止のとこがほとんどだよね
↑に戻るのは頭がおかしいのか？扱いされる -
COBOLは一回開発しちゃうと同じソースをメンテしてメンテして使いまわすから
むかーしのGOTO地獄とフラグ地獄をたまに見かけるよね
むかしのマシンが非力かつ高額な時に、負荷が少なく高速で実行できるからってことで
GOTOを多用してたからまあ仕方ない -
古いソースはね
今はほとんど構造化プログラミングでしょ
GOTO文がほとんど無しでサブルーチン化
むかーしのプログラムを修正する時にGOTO文とフラグの嵐みたいなのに当たると相当の苦痛を強いられる -
gotoを使わないことが構造化プログラミングだとドヤ顔で言いIF文のネストをひたすら繰り返す老害コボラー。
-
>>88
小学校から国語やりなおしたら？ -
PERFORMの飛び先にPERFORM二つ
またその飛び先にPERFORM三つ
そして最後にあるのは、MOVE文のみ。
若造よ、これが構造化プログラミングなのだよ！
あと内部PERFORMは禁止な。 -
老人は構造化プログラミングが〜と言い、若手はオブジェクト指向プログラミングが〜と言う
そしてお互いに馬鹿にする
これが底辺プログラマです -
COBOLでオブジェクト指向ってNETCOBOLで出来たと思うが
.NET環境でCOBOL使わないならCOBOLにオブジェクト指向なんて不要だし、ほとんど構造化プログラミングで済む
適材適所だわな
オブジェクト指向プログラミング出来る言語は重要だが、それが足かせになってる言語も有る
Javaが最たるモノだが -
確かに固定小数点の数の、四則演算及び整数乗の計算精度は高いね。
>>74
その頃はまだ誰もが大学に行くのが当たり前という時代では無かったから、
実はそこそこ頭もいいんだけど親の稼ぎの問題等で高卒って人も時々いる。
でも、今30代以下の人で、大学に行ってなかったり、定員割れしてるような大学出身の人は、極一部を除いて驚くほど頭の悪い人が多い。
例えば1〜12月や日〜土曜日を英語で書けない、ヘボン式のローマ字表記を知らない、小学校で習う程度の漢字の読み書きが出来ないとか。 -
やたら人のあらを探して見下すことを言うのも老コボラーの特徴だね
-
汎用機COBOL→オープンシステム化は有る
-
>>95
富士通のSEから聞いた話で、その後に
汎用機COBOL←オープンシステムに戻ってくるのが
100件に1件くらいの割合であったってさ。
ウチも最後はエミュレータで締めたけど。
まあ、減っていく一方に変わりはない。 -
オープン系やったことなら解るけど、開発環境がまるで違う。コマンドメインの古くさい汎用系で開発なんかしたくなくなるぞ。
-
昔で言う汎用機はもう存在しない
汎用機OSを載っけたサーバーがあるのみ -
>>99
こっちはエミュだけど
http://www.fujitsu.c...0/option/osiv-xsp-4/
これは汎用機じゃないの？
http://www.fujitsu.c.../gs213634/index.html
↑今すぐ読める無料コミック大量配信中！↑
