COBOLって今需要増えてるの?Part7
レス数が900を超えています。1000を超えると表示できなくなるよ。
> 999 名前: 仕様書無しさん [sage] 投稿日: 2018/05/26(土) 19:52:09.83
> >>996
> COBOLの現場は今でもCOBOL85が主流だから
> FUNCTIONの出る幕ないよね
利用者定義関数のことなら確かにCOBOL2002からだけど、
組み込み関数ならCOBOL85の時点でとっくに実装されてた。 >>4
私の勉強不足かもしれないけど
組み込み関数の存在自体知らないわ
職場に据え付けのCOBOL85の言語仕様書には
そのようなものは記述されていなかったからなんだけどね >>5
たまたま>>5が知らなかっただけだろうね。
組み込み関数自体は特段マイナーなものではない。
テーブル内の特定の項目の最大値や合計値等を求める場合に
テーブルを1から最後までループしていたり、
ある数をある数で割った余りだけが必要(商は不要)な場合に、
わざわざWORKING-STORAGEに使いもしない商格納用の変数を定義して
DIVIDE文を使ってたりするソースを見ると、無駄なことしてるなあって思う。 組み込み関数って第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もその1つ。 絶滅危惧種のウナギの価格が暴騰しているのと一緒
かつて中国産のうなぎは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はどうにもならないよ >>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への移行を決定して未だに苦労してる みずほがグダグダなのは取締役連中がダメだから、が一番大きいけどね
遅かれ早かれ逝くと思う >>30
VBだって通貨型の変数あるじゃん
だからといってVBで開発はしないと思うけど >>39
有る
しかし、DB上で定義するだけで無く、途中の計算し易さとか編集のし易さがVBはCOBOLに劣る
VBプログラマーの一時しのぎ主義も問題として有る
(とりあえず動けば良い) 今はC#やってるんだけど、同じようなバッチ処理を作ってもC#だとめちゃ早く作れる
色々な便利機能がついてるから
同じことをCOBOLで作ろうと思うと2〜3倍は時間がかかると思う
だからCOBOLがダメだって話じゃないよ
最後にCOBOLの開発案件にかかわったのは3年前だけど
COBOLの開発なのに、そのスケはおかしーーーーんじゃないの?ってぐらい
開発期間が異常に短くてスケ通りにまったく進まないどころか
スケで予想されてる2〜3倍は時間がかかったので下請け会社は大赤字だったみたい
で、このスケを引いて見積もり書いたのも仕事発注した窓口もJavaしかやったことありませんって人だった
これだからCOBOLわーーーーーって陰口言いまくりだったみたいだけど
COBOLで納得して仕事受けたんちゃうんかい!って思った
今日はC#で作業領域の集団項目とかREDEFINEとかCOPY句機能が使えたらなーーーとボーっと考えてた
いちいち、newとかnewとかうぜーーーーーよ!
そして集団項目と再定義使わせろ 途中で送信しちゃったわ
集団項目から集団項目への転送も簡単にやらせろーーーー
せめてコレポン使わせて・・・ >>42
それはJavaでの開発した事無い会社が悪い
COBOLでの開発経験有る会社ならそんなスケジュールしないでしょ
そもそもオブジェクト指向言語のJavaでの開発工数とCOBOLの開発工数を同じ感覚でやってたらアホとしか言えんわw 【料金搾取】SEの結婚障害原因【無能残業】
☆偽装請負多重派遣SEの結婚相手の犠牲原因☆
両親や親戚に反対されましたが、偽装請負多重派遣会社に高額搾取金を提供したり時間外労働違反で家事をしないSEと結婚してしまい、生活困難で中絶と離婚をしました。現在は犯罪損害のない相手と共働き生活をして、数億円損失を防げました。
・モラルがない
・キモい
・ファッションセンスがない
・コミュニケーションが苦手
・コンピューターが趣味
・プログラムの料金以上の不利益生産
・プログラムの巨額利益を客先に提供
・プログラムの巨額報酬を人売に提供
・プログラムの知的財産を人売に提供
・ITスキルが高いのに低料金請求
・高度情報処理技術者なのに請求料金不足
・高利益なのに請求料金不足
・高生産なのに請求料金不足
・高需要なのに請求料金不足
・学習多いのに請求料金不足
・人員不足なのに早期退職
・会社員なのに早期退職
・PC使用過多で不健康
・運動不足で不健康
・高稼働で不健康
・高稼働で家事困難
・低収入で生活困難
・低収入なのに鬱病多発
・低収入なのに早死多発
・不利益なのに断らない
・偽装請負の多重派遣損害あるのに稼働
・裁判官が技術判断不能だから賠償困難
【IT業界】独身が多い職業の象徴として「ITエンジニア」が取り上げられる
http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/110200713/?ST=spleaf >>45
COBOLで開発した事無い企業、だわ
間違い >>48
言語仕様はC++ベースは同じ
問題はCOBOLの様に金額計算や小数点計算に向かない事 やはりCOBOLが一番。日本人はなぜか古くても良いものを大事にしないからおかしい。 金融系でJavaへ移行してライセンスの話で梯子外された中小企業は死亡状態 実業務でこんな大きな数を扱うことはまず無いだろうが、
FUNCTION INTEGER(FUNCTION LOG10(999999999999999999))が18を返してきた。
OpenCOBOLとIBM Enterprise COBOL for z/OSで確認。 >>54
それ、どっちもモジュールはCに変換されるヤツだな
Cに変換された後のバグじゃね >>52
今必死こいてOpenJDK化してるんじゃね
オラクル特許侵害する様なプログラムソース作ったら訴えられるのに なんでコボルは数値計算が強いの?
今の言語でも結構な精度だと思うけど、何が違ってどんな技術的理由によるの? COBOLの数値精度の精度が高いんじゃなく、やれることが限られてるため誰がプログラム作っても計算精度に差がないこと >>59
その上、計算コードが読み易い
他の言語は人によって読めないから そうだよね
COBOLの計算式は本当に算数のようで
プログラム未経験者でも見やすいと思う
他の言語は自由がききすぎて
お金の計算、特に利息などの少数以下の取り扱いが
どの段階でどの様に丸めるかとか
あーんまり考えたことない技術者だらけだと思う
丸め方で積み重なれば数億の損害になったりするから
ここは非常にシビアなところなんだけどね >>61
実際メガバンクでCOBOL→Javaに移行した所は全く誤差が無い、とは言えない危険性が有る
経営者が気づいて無さそうだが >>64
うーんたぶんだけど
他の言語だと技術者の粒が揃わず品質にバラつきが出やすいからじゃないかな?
今私はオブジェクト指向言語を使ってるけど、
バージョンアップ対応で元のソースを解読してると
何度も何度も車輪の発明をしてて馬鹿かとしか思えなかった
言語としては優れてるのかもしれないけど
技術者およびマネージャーの意思疎通が図られておらず
どいつもこいつもオレ天才やらオレ無双の独りよがりなコーディングしてるわ
その点、COBOLだと強制的にある程度の画一性や品質が確保される >>どいつもこいつもオレ天才やらオレ無双の独りよがりなコーディングしてるわ
それはVB4,5,6の時でも有った話
実質、プログラマのメンタルは変わってない
それがオブジェクト指向でも発揮されてコードが他人に理解しにくくなってる
>>その点、COBOLだと強制的にある程度の画一性や品質が確保される
この一点につきる >>65
それ金融系がということじゃなく、根拠は自分がそう思ってるだけだよね 数値計算だけ特別にクラス作って処理すれば、他言語でもコボルの代わりになれる? 数値計算といってもCOBOLで使われるのはあくまでも整数計算のみ
固定小数点のね >>68
正解
COBOLで外部モジュール作ってJavaとかPHPから使えば良い
>>69
小数点付き計算やわり算の誤差が無い部分がCOBOLのメリット
それを外部モジュールで作る >>67
COBOLが金融に強いのは>>61に書いた通りだよ 要は小学生で習う程度の算数計算に強いだけじゃん
金勘定の基本は算数だけどさ そもそもコボラーは技術者じゃないよ
昔は商業高校でCOBOL教えていた
だからCOBOLしかやったことない40過ぎのおばちゃんのスキルシート見ると最終学歴が商業高校だったりする
実務的には簿記をやるレベルってことさ そういう人達を排除した結果がCOBOL→Javaだった
で、オラクルに梯子外された COBOLが再評価されてるって、JavaからCOBOLへのシステム再構築があるってことか
マジで? >>78
Java→COBOLは無いよ
そういう所はライセンス払ってJava継続するかスクリプト系言語に変えるかしか無い
COBOL→Javaへ移行検討してた所が方針見直してCOBOLのままオープン化するって事 >>79
なんでそこでスクリプト系言語が出てくるんだ? そんな事例聞いたことないのだけど、ソースは自分がそう思ったとかじゃないよね。 だから一旦、Javaに移行したらJavaの蟻地獄にはまって抜けれ無いよ 今は構造化プログラミングでGOTO文地獄って少なくなってる GOTOはEXIT行き以外は禁止のとこがほとんどだよね
↑に戻るのは頭がおかしいのか?扱いされる COBOLは一回開発しちゃうと同じソースをメンテしてメンテして使いまわすから
むかーしのGOTO地獄とフラグ地獄をたまに見かけるよね
むかしのマシンが非力かつ高額な時に、負荷が少なく高速で実行できるからってことで
GOTOを多用してたからまあ仕方ない 古いソースはね
今はほとんど構造化プログラミングでしょ
GOTO文がほとんど無しでサブルーチン化
むかーしのプログラムを修正する時にGOTO文とフラグの嵐みたいなのに当たると相当の苦痛を強いられる gotoを使わないことが構造化プログラミングだとドヤ顔で言いIF文のネストをひたすら繰り返す老害コボラー。 PERFORMの飛び先にPERFORM二つ
またその飛び先にPERFORM三つ
そして最後にあるのは、MOVE文のみ。
若造よ、これが構造化プログラミングなのだよ!
あと内部PERFORMは禁止な。 老人は構造化プログラミングが〜と言い、若手はオブジェクト指向プログラミングが〜と言う
そしてお互いに馬鹿にする
これが底辺プログラマです COBOLでオブジェクト指向ってNETCOBOLで出来たと思うが
.NET環境でCOBOL使わないならCOBOLにオブジェクト指向なんて不要だし、ほとんど構造化プログラミングで済む
適材適所だわな
オブジェクト指向プログラミング出来る言語は重要だが、それが足かせになってる言語も有る
Javaが最たるモノだが 確かに固定小数点の数の、四則演算及び整数乗の計算精度は高いね。
>>74
その頃はまだ誰もが大学に行くのが当たり前という時代では無かったから、
実はそこそこ頭もいいんだけど親の稼ぎの問題等で高卒って人も時々いる。
でも、今30代以下の人で、大学に行ってなかったり、定員割れしてるような大学出身の人は、極一部を除いて驚くほど頭の悪い人が多い。
例えば1〜12月や日〜土曜日を英語で書けない、ヘボン式のローマ字表記を知らない、小学校で習う程度の漢字の読み書きが出来ないとか。 やたら人のあらを探して見下すことを言うのも老コボラーの特徴だね >>95
富士通のSEから聞いた話で、その後に
汎用機COBOL←オープンシステムに戻ってくるのが
100件に1件くらいの割合であったってさ。
ウチも最後はエミュレータで締めたけど。
まあ、減っていく一方に変わりはない。 >>96
戻るメリットって無い様な、、
オープン化したらオープン化のままCOBOL使えって オープン系やったことなら解るけど、開発環境がまるで違う。コマンドメインの古くさい汎用系で開発なんかしたくなくなるぞ。 昔で言う汎用機はもう存在しない
汎用機OSを載っけたサーバーがあるのみ FUJITSU Server GS21と書かれているが
汎用機OSを載っけた鯖じゃないのかね まあ国民支配のための道具じゃないんだし
汎用機と言えどもサーバーだよ >>104
お前さんの脈略もないカキコをみてると確かにそう思うよ 某銀行
銀行側「なぜこんなバグが見つけられなかったの?」
開発会社「作業人数不足です」
銀行側「募集かけろよ!」
開発会社「もう市場にCOBOLのエンジニアはいません」
銀行側「育成しろよ!新入社員いるべ?」
開発会社「え!?いや… 人売会社が人集めの為に空案件を出す
それを見てまだまだ仕事が沢山あると勘違い >>108
銀行のシステム子会社は新卒でcobolやるやん サマータイム、元号変更、GoogleのJavaScript無効
やる事多くてCOBOLから他の言語へ移行なんて同時に出来ない Javaももうすぐ死ぬしなあ
昔の人の知恵を馬鹿にしちゃ駄目だよね これからもJavaよりCOBOLの需要が無いことは判ってるよね まだJavaの仕事があると思ってるんだ!
作っちゃったシステムのお守りくらいしかないだろ
しかしどうすんだよJavaで作っちゃった奴 今もCOBOL運用してる所はある程度保守予算有る所だからね
Javaに移行した所はシステム保守費用抑えるためだったのに、それがアダに 汎用機COBOLからのマイグレーション案件多いのは保守経費削減も理由に有るでしょ どこを見て多いと言ってるのか解らないけど、
それはCOBOLにはマイグレ案件しかないと言う証ではないのか >>120
マイグレーション案件以外も少数なら有るよ
実際探していないなら探してみ
マイグレーションもCOBOL→別言語って訳でも無いから
COBOL→別言語、全くのオープン環境
って思ってるならお前さんがそういうシステムハウスに所属してるから、その願望が強いからでは 探すってまさかネットで出回ってる案件のことじゃないよね
本当に募集してるかも怪しい AS/400サポート期限せまってるからマイグレーション案件増えてるみたいね >>124
現役だけど一部バージョンが2019.01月でサポート終わる
それの移行案件が出てるIBMのまま移行するか他のオープンシステムに移行するか
JavaライセンスでCOBOL→Java移行熱は無くなった >>125
COBOL移行熱が冷めたのはもう殆どのCOBOLがすでに駆逐されたからじゃないの?
少なくとも自分はCOBOLか走っている環境なんて一度も見たことないし 俺はJavaもCもC#も、走ってるの見たことないなあ ハローワーク求人100,078件の平均月給193,400円〜256,400円
その中から
COBOLの求人211件の平均月給250,400円〜433,000円
https://jobinjapan.jp/job-listing/keyword-cobol.html
Javaの求人643件の平均月給224,100円〜406,700円
https://jobinjapan.jp/job-listing/keyword-java-pg.html
という具合に現実社会ではCOBOLが高級待遇。 そりゃ今や特殊言語だから
Javaは案件多いがメンテナンス主体でプログラマーも多い もう三十年近く前から無くなる無くなると言われて無くならないのがCOBOL 言語変えるリスクとメンテナンス性考えれば無くす必要性無いから
地方の金融システムでもまだ残ってる 全体の割合から言うと、もう無くなったと言ってもいいレベルだろう 若いプログラマー確保する為にJava に移行したらライセンス発生でバカを見る cobolなんて見たことないから別になくなっても全く困らない現実
cobolしかやったことないじぃさんがなくなるかどうかこだわっている事実 クソみたいな仕事しか回して貰えない>>138かわいそすw >>140
それは君のやってることの解説?
話ははぐれてないと思うんだが 金融機関とか結構COBOLでのシステムが残ってるが、若手社員にCOBOLやせずに派遣で乗りきろうとしてる所多い
でもそれで結構人件費かかってるから最近は若手社員へCOBOL習得させる方向に動いている
りそなみたいにCOBOLのままオープン化してる所がメガバンクでも出てるからね
りそなはWindowsPCでMF-COBOLでシステム構築してるし、当分、COBOL以外へ組み換えしない windowsPCでCOBOL動かしてるのかw
スゲー 世の中の動きについて行けてないアホが多いのはなんでだぜ?
スゲーじゃなくて知らなかったことを恥じるべきだ windowsPCでコボルの基幹系システム動くわけ無いだろw >>143
バカですか?
開発をWindowsPCでやってるって話 りそな銀行のシステムぐらい見て来い
Linuxサーバー+SQL Server+MF-COBOLでWeb上でCOBOLが稼働してる 開発の末端の人間なんてそんなもんよ
自分が見た世界だけが全て そうだね、windowsPCとしか言えないのはその先に何が繋がっているのか解らない、ネットで見ただけで知ったかぶりしてるだけなんだろう りそなは自動機監視もUNIXCOBOLでやってるけど品質ボロボロの糞システムだった。
まあ不治痛だから仕方ないが。 無職のコボラーはハロワに行けよ
案件がいっぱいあるらしいぞ 藁 ハロワなんかに流すわけないだろ
だからおまえには見えないんだな ちゃんとハロワに行ったのか
行かないと仕事見つからないぞ 藁 COBOLの需要はあってもあなたの需要はありません コボラーに出来ることは既存プログラムの簡単な改修のみです。新規で最初からコーディングは出来ません。 コボルはレガシー資産なので1980年代頃に作られたものをいまだに保守しているのだ 今日でリリースされるコボラーのおじちゃん、さようなら 85ってevaluateが使えるようになったやつだっけ?endifが使えなくてピリオドってのが昔のだったよね。懐かしい。
今は発注側だからそこら辺疎い。メインフレームの開発やってましたね。 periodの呪縛から永遠に逃れられないのがCOBOL
老眼には辛いよねっ ビリオド様からの有難いお言葉です
『ENDなんていらねぇ、俺が全てを止めてやる!』 現役コボラーだけど年収は900万ぐらいだな
仕事はいっぱいある
嘘には騙されるなよ 資産多いからプログラマー数に対しては多い
Javaはプログラマー数多いからCOBOLより今後単価下がる COBOLの不利な話すると何故かJavaの話題にすり替えようとする不思議 大規模な基幹系の開発言語でCOBOL以外にJavaしかないからじゃないの? JavaってCOBOLと比べてもオワコンじゃん
まだそれに気づいてないジャバラーいるの? javaじゃなくコボルの話しようぜ
もう話題がない位オワコンじゃないよね 全くオワコンではない。
が過去の焼き直しや手直しばかりでツマラナイだけ。 コボラーとしてはSQLで楽しむしかないと思っている
どんだけスピードアップをはかれるか
その辺で自己満足して楽しむ
後は共通ルーチンのブラッシュアップとか・・・ >>179
なんで?話題はあるよ?
つまんないだけだもん。 N,FがなくなってもCOBOLは他企業でやっていける時代 COBOLより先にVBやC#、Javaが先にオワコンになるなんて想像もしなかったわ 他言語はどーでもいい
コボルは終わってる
案件探しは残飯をあさるようなもの それでもいいと言うのなら
腐りかけの残飯も美味しく食えるのだろう >>189
プログラマー数と比べれば十分ご馳走だよ
Javaの方が厳しいと思うぞ Javaプログラマは増えすぎたから、なんちゃってプログラマが溢れるのはしょうがないが、案件がなかなか出てこないCOBOLとは現状が違う javaはどーでもええけど、ジャワティーはなくならんとってー COBOLは開発時点でサポート料やライセンス必要だがJavaは本稼働環境にライセンスがかかって開発時点では無料のまま
開発だけで終わるって教育機関だけだろ
だから金融系企業や中小企業でJavaでシステム刷新した所は漏れ無くライセンス課される
COBOLはOpenCOBOLに移行すれば開発も実行環境で使用も無料になる
OpenCOBOL利用してる実例は少ないが今後増えると思われる >>199
Javaのライセンスについて
大企業はライセンス料さえ払えば同じバージョンを長年サポートしてもらえてウハウハ
中小企業はそもそもパッチなんて当てずノンサポートで導入したバージョンをそのまま使い続けるのでライセンスなんて関係ない
と勝手に予想 >>201
>>大企業はライセンス料さえ払えば同じバージョンを長年サポートしてもらえてウハウハ
それで耐えられる企業ならね
>>中小企業はそもそもパッチなんて当てずノンサポートで導入したバージョンをそのまま使い続けるのでライセンスなんて関係ない
そんな中小企業が存続出来る訳が無い
信用無くなって潰れる >>201
>大企業はライセンス料さえ払えば同じバージョンを長年サポートしてもらえてウハウハ
アホか
いくら払ってもさっくり切るよ
ボラクル様を舐めちゃいけない >>203
Oracle様の意固地さは半端無いからな
業界一の融通の無さだからな
だからOracle製品避けるヤツが多い
JavaとMySQLユーザーは将来不自由になるのが決定済み DBもOracleを使っているような企業ならJavaのライセンス料なんて微々たるもんじゃないの?知らんけど >>205
まーね
OracleDB自体から逃げる企業も増えてる OracleDB+Javaのシステム使ってる所はそのままJava使うだろうけど
問題はDBがOracleじゃない所
そういう所はJava諦める方向に動く
COBOL→Javaに移行した金融系企業もOracle使ってない所は、今後選択に悩む >>208
いらん
MariaDBがPostgreSQLで事足りる Javaのライセンス料と言ってもメインフレームはもとより、MS、VMWareなどの年間サポート料と比べたらかなり安いと思うけど、
個人ならばともかく、企業が基幹システムとして使用する場合、Javaのサポート料が高いと思う企業ってどんな環境なんだ? ライセンス問題でJavaへの移行が低迷することはあっても
古い遅い高いの三拍子が揃ったCOBOLが返り咲くことは無いと思う >>210
中小ソフトウェアハウスが納入してる中小企業 >>211
OpenCOBOLと言うのが有ってですな
既に実用的に長崎県庁とかで稼働してる
NECや富士通のオフコンCOBOLをOpenCOBOLにマイグレーション
DBはMySQL
ハードウエアのライセンス料金のみにライセンス料を圧縮した >>214
ハードやODのサポート料は払えるのに言語のライセンス料は払えないって意味が分からん
パッケージを無償で使用して更に永遠にサポートもしろって言っているようなもんやん >>216,217
ハード、OSは仕方ない
まあOSもLinuxでフリーに出来る
何から何までサポート料金払う余裕が有るかどうかの話 従業員20人以内の会社でもECサイト作ってるぐらいなのに、そんな企業がライセンスまみれのシステム運用出来るか、って話 COBOLは大きな案件変動も無く、プログラマ増加も無く続く
何も変わらない
大体、新人にCOBOL学習させたら辞めるし
銀行(地方)とかのシステム部で新人にCOBOL修得させようとしたらその新人が辞めるパターンが常 大きな変化は無いかも知れないけど、決して楽な仕事でもないからなあ。 贅沢なこと言うなよ
エラー出まくり野良VBAのメンテするより楽で稼げるよ て言うかぁ、バグってることにも気付かないのがCOBOLのシステム〜ぅ コードがめちゃくちゃでバグの原因が分からず、バグで出来た不正データを潰すプログラムを追加するか保守で都度パッチをあてるのが、COBOLのシステムなのだ ネスト階層が10以上あって、命名基準が連番の謎フラグが何個も存在し各所で使い回している。
そんなリソースに当たった時の地獄っぷりといったら… COBOLに限らないのかも知れないが、大昔に作られたでかいプログラムのソースは大抵訳分からないよなw >>235
中小企業でオフコン使ってる所がオープン化に使うかどうかだな キャッチアンドリリースの繰り返し
決してずっと居てほしくはない
それがコボラーの扱われ方 京都市のNECのCOBOL/Sを金額
安いところがやってるんだね
キャルよk 新卒でCOBOLやる事になりました。
不安…もう就職希望出しちゃったし 若いやつが入ってくると尻や股間をつかんで反応を楽しむ
コボラーオヤジがいるから気をつけろよ
これマジにいるから >>244
ちょっとくらい使えなくてもクビにならないスキルを身につけることになるからいいのでは >>244
大丈夫だ、第二新卒というパイがまだある コボラーの現場って40代以上が多いせいか昭和から変わってない所あるので、パワハラモラハラセクハラ普通だよ COBOLは逆に楽しそうな気がする
普段は一般人が触れない機械触れるんでしょ? 操作は普通にWindowsPCで端末エミュレータですが、何か
本体はサーバーで汎用機用OSのっけてますが、何か でも端末でログインしてその上で普段見ないような専用のテキストエディタでコーディングしたりするんでしょ?
それだけでもうカッコいいわ・・・ スキルが他で役に立たないがCOBOL出来れば仕事に困らんよ
いってい需要有るから
まあOpenCOBOL(Linux,MAC OSで動く)やマイクロフォーカスCOBOL(オープン)出来れば、オープン系のスキルも付く ISPFやPFDに慣れるとCOBOLのためにWindowsのエディタなんてトロくて使ってらんないよ COBOLの需要多くてええなあ、RPGなんて全然ないよ。 >>258
IBMの端末とエディタは広がるからいいよね
日立のは広がらないから、あーもうっ 平成が終わりすっかり廃墟となったこのスレですが
今年をもって情報技術者試験からコボルが消えてなくなりますよ
いよいよコボルもレガシーシステムを残すのみで終焉の時を迎えたようです >>271
試験科目から消えても過去の資産は消滅しない
ゆえに仕事は残るし新人でもCOBOLやらされる人は出てくる
何も変わらんよ 改元によるコンピュータシステムの不具合の多くが、(当然ながら)??#COBOL??チックな不具合に見える。 主に、公共系や勘定系。
こういう状況ゆえCOBOLの仕事は消滅しない だからCOBOLやめたがってるんだろ
いつまでもレガシィ遺産を残すわけにはいかない COBOLで出来たシステムが日本の競争力の源泉なのに、
レガシーだガラパゴスだと言って捨てさせたがるのは、
一体どちらの売国奴勢力ですか?
自民+通産省は米国に国を売りたがりだし、
中共に売りたがる有象無象もいるし
共産党に頑張ってもらいたいところだが奴らは自滅したがりだし
どうにもならんな レガシーとか言っても
新システム作って出力結果の保証が大変だから
乗り換えが簡単で安ければやるでしょ
メインフレームの維持費って結構高いのにやらない > 乗り換えが簡単で安ければ
意外とこの条件が厳しいんだよなあ。
>>276
そもそもCOBOL自体が米国による米国向け言語なんですがそれは。 別にCOBOLの擁護をしてるわけではない。
COBOLで作られたシステムの話をしてるんだけども。
それに、では例えばJavaは日本向けの言語なんですか?という話で、
COBOLだけことさらに米国向けだというのはおかしい話。 COBOLが英語文法を元にしてるからそんな言い方したんだろうな
かつては日本語コボルなんてありましたが... 実は科学技術分野ではフォートランもまだまだ現役なんだけど、やってる人見たことないでしょ
それだけ専門的な人しか使わないこと
でもCOBOLは専門的な分野では余り使われないし、徐々に終わってきた感がある Javaも普通にアメリカやな。
ただ、言語の誕生経緯や、>>280の言うように英文を基にしていることから、
他のアメリカ産のプログラム言語と比べても
より英語圏の人間向けという印象は強いかも知れないな。 新人研修でJavaをやっても出来が悪いと同僚たちと別れじぃさんだらけのコボルの現場に配属
悲しいね、しかしコボルの現場は最後の砦だ。ここで頑張れば這い上がれるかもしれないぞ。 日本語拡張されて使いやすいよ、COBOL
変数名に日本語使いまくる文化が実に心地良い 大昔のプロローグの様だ
プロローグでは漢字コードをEUCにすると
変数名に日本語がつかえた 変数名に日本語が使える言語自体はそう珍しいものでもなくね?
VBでもPythonでも普通に使えるし。 いちいち転送をMOVEとか冗長なのだよ
使いづらいし見づらい 000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. EUCLID.
000300 DATA DIVISION.
000400 WORKING-STORAGE SECTION.
000500 01 R PIC 9(9).
000600 LINKAGE SECTION.
000700 01 M PIC 9(9).
000800 01 N PIC 9(9).
000900 PROCEDURE DIVISION USING M N.
001000 PERFORM UNTIL N = ZERO
001100 COMPUTE R = FUNCTION MOD(M N)
001200 COMPUTE M = N
001300 COMPUTE N = R
001400 END-PERFORM.
001500 COMPUTE RETURN-CODE = M.
001600 EXIT PROGRAM.
def euclid(m, n):
while n != 0:
m, n = n, m % n
return m
何だかんだでCOBOLも結構好きだわ。
情報処理技術者試験のCOBOLの選択問題はむず過ぎて即C言語に変えたけど(その結果午後は9割超え)
来年の春から代わりにPythonの選択問題が新設されるみたいだから、久しぶりに受けてみようかな。 (-2) ** 5 = -32なのに、(-32) ** 0.2 = 2となるCOBOLの不思議。
EnterpriseCOBOLだけかも知れないけどね。因みに(-16) ** 0.25 = 2になる。 Javaでいいの作ってて
ExcelVBAに回されたけど頑張ってもっといいの作って
上機嫌だった隣のおっちゃんが突然険悪になって
ふざけんなくそちくしょうもろもろ言い出した
画面にはCOBOLのコードらしきものが… ○○で作ってて
△△で作ってて
××の保守をやらされたら
険悪になりそうではある COBOLじゃないけど、naturalとかidealとかやってる人いない?
いないか。いないよね… 4GLってCOBOLソースを出力するツールのことなんでしょう? まーね
それゆえ特殊過ぎてオープン化の障害にもなってる NEC IDL2とか吐き出されたCOBOLソースが特殊なんで結局修正が必要
NEC→IBMへのマイグレーションでIDL2のCOBOLをIBMへ移行出来る様に修正するパターンになる 政府自身が現行COBOLのシステムをAWSへクラウド移行する
COBOLは残る コボラーの殆どはAWSって何?というレガシーしか興味ない親父だからね パソコンしかコンピュータを知らない連中よりはマシよ
本物のコンピュータを知ってるから 今はIA機が本物のコンピュータだよ
いつまでも過去の遺物であるメインフレームを使う銀行屋保険屋はオワコン産業 それは保険も銀行も一切利用してない仙人だけが言えるセリフだよ 結局さ、ものを知らないガキがマウンティングとりたくてCOBOL貶してるだけなのよな PLの話だと大手金融開発でJavaは使用されなくなりオンライン開発でもCが使用されなくなる。
そして、学生向けの本も一気に消えた。しかし、COBOLは10進数計算という強みがあるから現場では需要はある。 既にあるものを作り変えた結果、想定外の動作をしたらクライアントがギャーギャー五月蝿いやんけ。
結局COBOLは無くならないというか無くせないでしょ。 COBOLはわかりにくいし生産性悪いからJavaに置き換えるべきだ
でもJavaは? COBOLが分かりにくいのはお間抜けコボラーのコーディングのせい
出来ることの範囲はJavaにくらべてはるかに少ない Javaなら生産性も保守性もいいのか?って言われるとまったくそんなことないだろ
COBOLじゃなくてグランドデザインと運用の問題だから日本人が徒党を組んでる限り解決しない >>310
精神年齢は幼いけど、実年齢はかなり行っちゃってるおじさんの場合もある >>311
金融系ではCOBOLは残ると思う
他の業種はJavaに行ってたのがライセンスうんぬんでJava減ってるね
.NETが盛り返してる DBやOS、ライブラリのライセンス料、サーバーやクラウドの利用料は払えるのに開発言語にはライセンス料を払えない不思議・・・ 金融系だとJavaは廃止されると言われた。
だから、教育機関でも講義からJavaを廃止したし、今後は一気に減ると思う。
進数計算はJavaよりもCOBOLが上だし、Javaはモックに問題があるしまともなシステムでは使用されるはずがない。 今後JavaがどつなるかはわからないけどCOBOLが返り咲くことは無いと思うよ
というか特定の言語でしか食っていけない時点でプログラマとして終わっていると思う COBOLは来年より情報処理試験から消える
長い間ご苦労様でした
これから誰も新しく覚えようとはしないでしょう PCで流行らなかったからいずれは試験のような表舞台からは消える運命よ
汎用機とオフコンのある限り脈々と伝承されていく
GUIは苦行だろうけどMSかBolandがアマチュア用に安く出してればもっと延命されたのでは
MFやFの業務用だけじゃ裾野が広がりようがなかった まあ、パソコンだけがコンピュータな人々にとってはそうかもね >>325
>>GUIは苦行だろうけどMSかBolandがアマチュア用に安く出してればもっと延命されたのでは
マイクロソフトとボーランド(今はエンバカデロ)がCOBOLのPC用コンパイラ作る訳無い
当時、商売にならんと思ったからな
現在になって結果的に、その判断は間違いだったが
メインフレーム捨ててUNIX、Linux、Windowsでオープン系COBOLが動き出した21世紀においてはマイクロソフトorエンバカデロ、どっちかが出してれば売れてただろうね オープン系どうのじゃなくてCOBOL言語そのものが古いんだよ ちなみにアセンブラは情報処理試験に残るよ
高級言語としてCOBOLは古くてもう不要と言うこと 情報処理試験から消えても
現場からは消えない
それが現実 新しい技術について行けずCOBOLしか書けない人は大変ね コボル使ってるのと使ってないのとじゃ、会社の安定感が違うね。
コボルを知らない情シスの会社って、スグ潰れそうなニワカ企業ってイメージ。 COBOLをコボルって書く人はCOBOLすら知らないエセコボラー メモリ破壊の悪人C言語は現場からも学校からも消えた。
メリットが消えて、リスクのみ残す無駄な使用だから淘汰されても仕方ない。
COBOLの方が進数計算とかでわずかに出番ある。 コボル経験者で募集するとマジで50〜60代しか来ないからな
早く何とかしないと誰もいなくなってしまう
コボルのシステムは廃止すべき
上の人間は現状問題ないからいいだろう程度でしか思ってないから
問題なんだよ >>339
ポインタを使いこなせない、ポインタのポインタとか全く理解できない
自称技術者のうんこ人間がまんま同じ事を言ってたな コボラーはCOBOLしか使えないからな
ポインタ?オブジェクト指向?何それ?がデフォの世界 ポインタもオブジェクト指向もCOBOLに実装されてる定期 いくらCOBOLに実装されてもそれを使えるコボラーがいない定期 オブジェクト指向やるなら別にコボルにする必要ない
レガシーシステムが残っているためコボルが存在する オブジェクト指向はともかく、ポインタは使ってるCOBOLでもケースは多い。
ただし、CALLするときのUSINGにポインタを指定して、
呼び先のプログラムで「SET ポインタ名 TO ADDRESS OF □□-AREA」からの、
呼び元で「SET ADDRESS OF ○○-AREA TO ポインタ名」みたいなパターンが殆どだけど。 ポインタは使ってるCOBOLでもケースは多い
→ ポインタはCOBOLでも使ってるケースは多い COBOLプログラマが減るので相対的に増えるんじゃないか。その代わりどんどん集約され固定メンバになる 需要が増えてるならそういう会社が若いやつ雇うんじゃね?
14万円で 需要は増えてない
規模が小さいため人を増やせず一時的に人手不足となるケースが有るぐらい COBOLやろうと思ったら汎用機のお作法もわかってないといけないのですか? 汎用機の作法って何ぞ?
JCLとか画面の入出力とか? さすがに画面は置き換えられてる気がするが
帳票のお作法は覚えた方が良いのかもしらんが
メーカーによって違いそうw COBOL離れてだいぶ経つけど、汎用機系の現場って残業する人が努力家みたいな風潮あったけど、最近も変わらず?まぁ現場によりけりか…
定時あがりに慣れたから残業あるとこ無理だなー 定時で帰るのは甘え
最近のエンジニアは軟弱すぎて困る 仕事終わってんの意味もなく残業してるやつが多いよな エンドユーザーが大手なら働き方改革で残業するなってお達しがあるよな
残業してるのって、無能か残業代目当てかみんなしてるからしてるみたいなやつだよね 汎用機COBOLでデバッグにDISPLAY文使うのは昭和の時代から変わってません デバッグ終わってもDISPLAY貼ったままなんだよな 単体テスト終わったらDISPLAYは取るようにしてください >>374
規格上は7桁目にDを入れるとデバッグ行になる仕様だけど使ったことがない モニター上でデバッグするのでなくて紙出ししてで机上デバッグするのが汎用機コボラー
ペーパーレス化なんて認めない
引き出しの中はリストで一杯 汎用機のエディタは行数桁数スクロール固定なので、画面上でデバッグなんて無理無理
変えられるのはウインドウサイズのみ
そして全画面にしても文字が大きくなるだけ
老眼には優しい ASPENは行数指定でスクロールできたよ?
ISPFもそのくらいできるだろ ♯がシャープで、#、#が井桁だから、記号としては別物。
&の正式名称は「アンパサンド」だけど、それを略すなら「アンパ」より「アンド」の方が自然に感じる。
他には_(アンダースコア)を「アンスコ」って略す人もいるよね。 >>382
キーボードの刻印を見るに、井桁だよなあ ハイフンをハイフォン(ハイホン)と読む人もまあまあいるけどこれはかなり違和感あるな。
hyphenの発音記号を調べても「オ」に対応するような発音記号は無いし、
ネット上の英和辞書に付いてるネイティブの音声ファイルを聞いても「オ」とは聞こえない。 エ「クソ」ンをエッソと言い換えたように
ハイ「フン」を配本と言い換えたのだろう 「日本」の「本」の発音も、F→H→Pと変遷してるらしく
(今は「にほん」から「にっぽん」への移行中)、
ハイフンもハイホンに移行し終わったあたりなのではなかろうか。
そのうちハイプンになると思われる。 スクロールバーがないから自由にスクロール出来ずスクロールは画面単位やカーソル位置までとか固定されているエディタがまだまだ現役なのだ >>385
実際にはハイフンではなく、マイナス記号だからな。 このスレはオープンCOBOLの話がほとんど出てこない。不思議ですね。 オープンCOBOLって何?
昔UNIX-COBOLやったことあったけど殆どはZ/OSだな Visual COBOLを使っていると、ここで悪く言われていることが的外れなのがよくわかるよ。 >>382
C#をマイクロソフトは「Cシャープ」と呼ぶ不思議
#はナンバーサインと分かってもシャープと言ってしまう
電話の記号もシャープって呼ぶもんね
それと電話機の「×に-」のスターマークも「×に|」のアスタリスクって呼んでる
スマホのキーパッドは*になっているから
固定電話のスターマークも変わるかもね >>390
富士通のpowerAEとか使ったりしてた
日立のCOBOL2002は開発しやすかった オープン系開発の話が過去形なのが笑える
やっぱCOBOLは汎用機主流なんだね >>394
英語キーボードでは井桁を入力できないし、文字として存在しない。 >>394
英語キーボードではシャープ記号を入力できないし、文字として存在しない。 変数名はアルファベット3文字+連番で台帳を使って管理
80行24桁の画面設計用紙で画面設計し
会議室に集まって手書きのコーディングシートを使ってコードレビューする
鞄の中には常にフローチャート用の定規を常備(IBMのロゴ入り)
そんな感じのとこ、今もあるのかなぁ WEBプログラミングしてるとたまにCOBOLでやったほうが楽なんじゃないかと思うことがある >>403
たぶん、COBOLでやってると、WEBは楽だったなあと思う部分も出てくると思うんだ
上手い具合に混ぜられるといいんだけどね >>407-409
おまえらCOBOL書けないんだろ?
他人が作ったフレームワークに乗っかるだけのクズなんだろう? コボラーもIDENTIFICATION DIVISIONからもう書けないよ
コピペしてるだけ SQLでごちゃごちゃやらずに素直にドカッと引っ張ってきて select文をread文と同じ扱いにするのがコボラー COBOLのサブルーチン追ってく感覚でクラスとメソッドおってくんだがよくわかんなくなってくる COBOLはプログラムの先頭でまとめて変数とか定数を定義するブロックスコープとかがないので大量に操作していると頭がこんがらがる JAVAなんて糞
COBOLだけで食っていけるのが真のコボラーなんじゃよ COBOLが古い言語というのは知ってたけどもう還暦のようで
需要尽きないものなんすね >>428
COBOLが悪いわけではなく、COBOLが想定している環境がいまとなっては特殊すぎて、何もかも高コストになる。
だから徐々にCOBOLの使用が減っている。 COBOLがダメっていってるのは
Lotus1-2-3がダメって言ってるのと大して変わらんよ
今でも十分すぎるほど使える なんかディスってるように見えたかな
息が長いというか、淘汰されないもんなんだなぁと思っただけですサーセン COBOLの需要というより汎用機の需要だな
セキュリティ最優先の業種は汎用機優先になる 10数年ぐらい前にデータセンターでテープとか使って立ち会いとかしてたな。懐かしいw
今は流石に無くなったよな?
別業種行ったので分からん。 COBOLの古いことによる欠点はオンライン処理が辛いことと
フレームワークとの分担が上手くいってないことだと思う
だからバッチ処理なら今でも便利に使えるし、
ハケンが触れるフロントエンドには出てこないだけのこと テープって穴あきのほう?それともぐるぐるまわる磁気テープ?
今でも磁気テープは新しい規格が出来て現役だよ >>431
COBOLと同等以上の安定性を持ったシステムが開発されたら置き換わるだろうね
汎用機との組み合わせで少なく見積もっても30年くらい安定して稼働しているので
検証が大変だと思うけど頑張ってな >>432
汎用機は隔離していないとセキュリティがザルだから使い物にならない。 >>437
汎用機が安定しているのは汎用機をいじってないから。 某官庁ではメインサイト被災後の復旧時にバックアップサイトとの通信が不可能は場合は
磁気テープで受渡しする手順になってます
なので磁気媒体はこの先も無くならないです >>438
逆に現代のハッカー(笑)はたとえコンソールの前まで行ってもまともに操作できないんじゃ… >>442
コンソールじゃなくてカードリーダーのところに行かなければ
ジョブを投入することが出来ないじゃないか 最近はRPAでホストコンピュータの自動操作してたりするんだけど、これPCがハッキングされたらホストにも入れてしまいそうだよ >>442
コンソールじゃなくてカードリーダーのところに行かなければ
ジョブを投入することが出来ないじゃないかね COBOLのままリホストする例も有る
COBOL自体は無くならない おにぃさんおにぃさん、ちょっとこっち
今ならいいコボルの案件あるよ COBOLの案件で入ってjavaにマイグレーションされて、そのままコピペ開発でjavaのなんとかやってるけど、本質的に理解できてない COBOL→Java、と言う間違ったマイグレーションが王道化した結果、技術者の人件費低下&技術力低下を招いた コボラーオヤジ、自称コンピューター歴30年以上のベテランSEがWindowsの使い方解らなくて派遣の姉ちゃんに教わってた そうかわからないフリすれば若い子とイチャイチャできるのか
良いこと聞いた ツールでCOBOLを一気にJavaに変換
エラーを手作業で変換してオープン化プロジェクト完了
そしてメンテナスに困る >>459
>>メンテナンスに困る
まさに今はその状況があちこちで見られる
ツールで一気に移行して後の消費税増税や軽減税率対応したら、そりゃおかしくなるわw でも汎用機orオフコンからIAにCOBOLのまま移植するのかなり大変じゃないの?
楽々ならパッケージカスタマイズとかも流行らんかったろ 地方の役所はみんな問題を抱えている
有名なのが
京都市の基幹系システム刷新プロジェクトの遅延 ↑
キャノンソリューションが受託したな
今ごろ火吹いてるだろうけど >>461
やり方次第
オープンCOBOLと言っても
富士通のNETCOBOL(.NET上で稼働)
マイクロフォーカスCOBOL
GNU COBOL
分かってるだけでこれだけ種類有る
で、中身のCOBOL言語仕様はほぼ統一されてる
ホストとしてUNIXサーバーにするかLinuxサーバーにするかWindowsサーバーにするかも選べる
ライセンスフリーでJavaが移行先言語になってたがOracleのせいでそれもダメになった cobolのソースでIF文のネストが100STEP以上続いてたのは笑ったわ そろそろjavaの勉強しようかなと。
おすすめの本教えて そうだ、メンテでもCOBOLで書いてJavaにコンバートしよう コボラーはユーザ登録して喜んで読みなさい
ttps://japan.zdnet.com/extra/ibm_1911/35144817/
おや、よくみるとPRの文字が
...これ提灯記事じゃん マイクロフォーカスに関してはねえ、、
現に利用してる所が限られる
ライセンス料もそれなりに払える所だけね
GNU COBOLとかに関する記事の方が役に立つよ コボラーも年々人が減ってきている
案件で人を探してもなかなか見つからない
COBOLの案件は割に合わなく将来性も無いから新しく人を育てないからだ 無理に育て無くて良い
若いヤツはCOBOL嫌いだし 仕事とられたくないんだろ
若くて優秀な奴が来たらコボル知ってるだけが取り柄なジジィは即クビだもんな 好き嫌いの問題?
ピーマン食べれないお子ちゃまかよ > 若くて優秀な奴が来たらコボル知ってるだけが取り柄なジジィは即クビだもんな
若くて優秀な人がなんでわざわざコボルみたいな保守案件選ぶの?
コボル爺と仕事取り合う時点で優秀じゃないよね >>483
まあ、その通りだな
適材適所って有るし
COBOLの現場に好きで来る若いプログラマっていない
twitterでもCOBOLやらされてブーブー言ってるヤツ多い かと言ってJavaの現場も今やフレームワーク決まっててツールでコード生成してる現場有るからJavaの現場も若いプログラマにはメリットが無くなりつつ有る
まだJavaの現場の方が若いプログラマが活躍出来る
単価は上がるかはアレだが 若いプログラマで優秀なヤツやゲームやAI、モバイル開発へ行く
ビジネスシステム開発なんて泥臭い所に来ても体と心壊してしまうだけ ゲーム開発ってSE・PGの中でも特に労働環境悪い部類に入ると思うぞ。
保険屋や銀行に常駐しているSE・PG(そいつらの大半がコボラー)の
労働環境も決して良いとは言えないが、それよりも酷いんじゃないだろうか。 ロースキルでもやっていける
若手は配属されないから切られる心配もない
コボルなんて知ってるやつも少ないから工数も多めに出して余った時間は適当に遊んでる
定年まで安泰じゃ、ワハハ >>487
ゲーム開発は労働環境悪いがシニアプログラマでは無理だからな
必然的に若いプログラマ中心になる COBOLやPL/Iに求められるのは金勘定が上手く行ってるか
その流れで帳票が上手く出力出来るか
金勘定がコードで追える言語でオープン環境すんなり使えるモノが出て来ない限り代わりは無い
C#は微妙に惜しいのよね Javaの銀行って炎上しまくる案件がめちゃ多いよね。
年号が変わったときも150時間超えの残業で死にそうな顔の人多かったw 西暦→和暦変換部分をオブジェクト化してないからじゃ無いか
外部オブジェクト化してりゃ本体ビルドしなくても移行出来るでしょ
テストは必要だが
帳票系は見て確認必要だが
要はシステムの作り方次第だが、Javaのオブジェクト志向とか考えずに実装されてるからでは 通常の設計なら日付周りはサブルーチン→モジュール→オブジェクト化って流れ
そうなって無いなら、その程度の所って事になる >>492
閏年の計算なんてJavaに限らずシステムに実装されてるだろう?
でも間違う馬鹿が必ずいる
要はそういうことだよ 何だかんだ言っても再雇用組なんて少数派だし、
ジジイばかりとか言いつつ所詮は40代とか50代だろ?
コボラーは実年齢以上に老害化している人が多いのか、
或いは数としては少数の再雇用組が異常に幅を利かせているのか? COBOLにオブジェクト指向が必要な部分ってあるんですかね?
なんか余計な機能のように思えてならないんですが COBOLにオブジェクト指向とは無理矢理過ぎて笑える ふと疑問に思ったんだが、汎用的な銀行のシステムを作って
それをいろんな銀行に使わせるみたいなことってできないのか?
老舗銀行でそれはできないとしても、これから新規に開業する銀行ならできると思うんだけど
老舗銀行が新規に銀行作って、顧客に新しい銀行に口座を移してもらうことで
システムを新しいものに入れ替えるみたいなことは無理なのか? 各銀行にプライドがあるからな
日本人はその手の効率化はできない そもそも地銀は結構共同システム多いんじゃなかった? 15年前、某大手携帯会社のシステムはオープンCOBOLだった。javaに移行するなんて話あったけどどうなったんだろうな >>502
多い
りそな系列とか(マイクロフォーカスCOBOL)
ユニシス系は.NET >>499
昔、第●勧銀と富●通が「bank 〜〜」ってのを作って
他の地銀に売ってたな 某社のジュリアンデートカレンダーが配布される時期になったな
何気に手帳が重宝するんだよね >>507
知らねえよ
俺に聞くなって言ってるだろ! ...わからないことは何でも聞けよと言ってたのに。。。 >>509
聞けよじゃなくて、あらかじめ文書にしてくれませんかね? >>512
どれだよ
インデックス化するとか番号振るとかしろよ 本人はできる奴だと思ってるから始末に負えない
マニュアルぐらい読めよ、すぐ人に聞かないでさ 君はオペレーターかね
せめてプログラマらしく0C7とか言いなよ プログラマだけど0c7は滅多になかったな。テスト環境がショボいからb37よくおきてた こんなん回ってきたわ。
周りほとんどDXレポート知ってて驚いた。こぼらーもそういうの見てるんだな。
ついにCOBOLなくなるんかね。
2025年には何も変わってなさそうだけど。
https://forms.gle/vT4PE1E6Y8ei5ZLo8 「COBOLなくなる」ネタっていつからあるんだ? 90年代にはもうあった? 90年代はオフコン残ってて現役バリバリだったような
Javaが出てきてからじゃないかな?
古くてダメな言語だから最新の正しいオブジェクト指向言語に置き換えましょう
みたいな怪しい宗教が発生したあたり コボルのシステムのほとんどはなくなるけど少しは残るだろう
もうその状態ではCOBOLはなくなったと言ってもいいでしょう >>527
4GLが流行ったのは90年代前半だったか80年代後半だったか
ちょっと記憶が曖昧だけど、なんかその辺
Javaが出てくる10年くらい前だよ VBAじゃなくJavaだけど、うちのコボラーは1クラス数千ステップのコードをドヤ顔で書いてくるわ
しかもコピペで冗長コードを大量生産
オブジェクト指向?なにそれおいしいの?状態 ステップ数が金に直結するなら迷わずそうするだろ?
短く書くのは技術の安売り コボラー「モジュール化して共有するより、多少冗長的でも一つのクラスにまとめた方がコードが追いやすいだろ」 下手に内部で条件分岐すると組み合わせが多くて間違いやすいしな コボラーだかjavaをやりはじめた
ソース追ってクラスを遡ってくと何やってるかさっぱりわこらん コボラーだかjavaをやりはじめた
ソース追ってクラスを遡ってくと何やってるかさっぱりわからん セクション構造のプログラムのEXIT直前へのGO TOは多用するが、
中途半端な部分にラベルを作ってそこへのGO TOはコボラーでも嫌がる人が多い。 新卒で入った頃は純粋GO TO制御なプログラムよりもPERFORM 段落 THRU 段落が多用されてることに最初は面食らったな
あの構文を継承した言語ってあるの? COBOLの後継言語がない
科学技術と商業用のいいとこ取りを仕様としたPL/Iは失敗した PL/1なんて銀行とかの勘定系みたいなショボいシステム位でしか使われてないやん コボラーはPL/1のポインターの使い方が解らなくて挫折するらしいね 挫折はしなかったけど、最初ポインタの初期化忘れやってST障害出した。 COBOLの現場って古い人が多いから
残業する人は頑張ってるから偉いとかそんな考えの現場やっぱ多いんかね
徹夜自慢とか >>563
そんなことないよ?
大体年寄りは徹夜なんかできん 年寄りは通院で休暇が多い
大したこと出来ないし倒れられても困るから残業もやらせられない COBOLerのEOL対応どうすっぺか
汎用機はAWSが延命してくれたけど、COBOLerが次々EOLを迎えていく COBOLの場合、技術的に難しい仕事ってのはそうそう無いけど、
だからと言って楽な仕事かと言われるとそうでもないのが辛いところだよな。
客先常駐も多い上に、コボラーが常駐するような客先って、
馬鹿の一つ覚えみたいにセキュリティセキュリティ騒いでるようなとこばっかだし。 OpenCOBOLは日本語対応してないような・・・?
日本語1文字が可変長なのも気持ち悪い >>573
対応してる
長崎県県庁システムの例が有る マジか・・・
ここに希少なAS400コボラーおるで。 COBOL2020とか名前変えたら
かっこいいのに
昔、FORTRAN77ってのがあったな
ピンクレディのカルメン77と
かぶってかっこいい名前だと思った >>580
今時はCOBOL2000だろ。未だに85使ってる奴とかいるの? COBOL85の次はCOBOL2002で、更にその次はCOBOL2014だったはず コボラーからなんちゃってジャバラーになったがCOBOLの仕事あるのかな
でもCOBOLってテバッグやテストが面倒よね >>588
金融系システムとして金額計算にCOBOLを敢えて止める必要性は無かった
結果的にJava有償ライセンス化も発生した そうか?
COBOLでトランザクションの管理なんかやったらそりゃ生産性低いだろうけどさ
それは使う場所間違えてるってだけの話 昔はやってたね。
テストとかもやってたけど酷かったよ。
バグ直さずにコメントアウトとかw 昔はSEとかPGとかって職業が少なかったからでしょ。
情報システム部なんて部署すらもない会社も多かった 外部委託が当たり前になった時代にいまどき自社で情シス持っている会社なんてあるの? いくでもあるでしょう
完全外部委託でも情シスある企業だってあるし。 誰が完結してるって話をしてるんだっけ?
急に変な条件持ち出すなよ 今はIT企画部とか情報戦略部とかよくわからない名称になってる情報処理部門 昔は区分けがSEとPG位だったのが、今やなんとかエンジニアの種類が増えたこと マシンエンジニア
カーエンジニア
プラントエンジニア
システムエンジニア
他、何よ 機械系エンジニアを無視して「エンジニアです」と名乗る人達はエンジニア代表です COBOLをjavaにマイグレーションしたなんちゃってjava開発やって2年
コピペ開発でなんとかなってるが、javaよくわからんまま開発しているよ DISPLAY貼りまくってデバッグ終わったら、そのディスプレイ全部削除するん? >>615
削除する
で、間違って関係ないとこ消して障害 GO TO TRAVEL.
〜
TRAVEL:
この後のコーディグは何が書かれてる? >>DISPLAY貼りまくってデバッグ終わったら、そのディスプレイ全部削除するん?
正規表現をつかえば、置換で、DISPLAY行みんなペロって消えるから問題ないよ。 大手保険会社・銀行が全部潰れない限りは無くならないんじゃね?w 昔ドコモの顧客管理システムCOBOLだったけど、さすがにjavaになったよな? みずほ以外にも銀行はたくさんあるし、(例え大手に絞っても)あらゆる銀行・保険屋でJava等の他言語に完全移行は困難かと。
例えそれが実現したとしても、その頃今生きている人の内何人がこの世にいるだろうか?ってくらい先になりそう。 >>627
移行しきれていない
旧みずほ 富士通5台、バックアップ5台
旧みずほコーポ 日立6台
みずほ信託 IBM2台+バックアップ1台
の3系統を統合
メインフレームが19台から4台(うちバックアップ1台)に減った デジタル庁でCOBOL絶滅の行政指導が発動され空前のマイグレ需要が起きるんや るーるる るーるる るるるるるー
るーるる るーるる るるるるるー
こぼる コボル COBOL
流行る 覚える 廃れる
バグる 焦る 募るー >>636
今更、COBOL→Javaへ移行するのか?
デスマーチの嵐になる 大切なコボラーを守るため、コロナ対策として自宅から職場まで送迎はリムジンだよ コボラーはあなたのそばにいる
ほら振り返るとそこには... 某携帯会社の基幹システムはCOBOLだったけど、もうかわったんかな? いまだに基幹系が全部コボルって思う人いるんだよな
基幹システムの奥底でひっそりと稼働してるのがコボル 今の現場COBOL要員で入ったが、マイグレーションでjavaに変わった。移行後そのままjavaでの開発要員にいつのまにか変わってた。
かれこれ2年COBOLから離れてるからもうCOBOL忘れてかけてる >>671
そうそうコアな部分でひっそりと稼働してるんだよね
難し過ぎるから恐ろしくて誰も手が出せない
根本的な載せ替えは無理無理 JCは青年会議所のことだよ
知らないの?
検索してみ 押収品をみてニヤニヤしたいおまわりさんが通報して欲しがってるんだったりして >>697
減って無い
もともとPL/Iが多いからね
PL/I→COBOL移行が終わったぐらいでしょ コボラー卒業したけど、java案件なくなったらコボラーに戻れるかな COBOL案件なんて短期で数は少ないからブランク空きまくりだよ >>702
選びまくってるんじゃ無いの
東京、名古屋、大阪なら一定数案件有るよ
OSとか選んでたらそりゃブランク空くでしょ その案件は本当に存在するの
人集めの空案件にはもう振り回されたくない 銀行はコロナ禍でJavaとReactの若手作業員を大量に退職させた >>706
結果COBOLに回帰した
オープン系COBOLだから現代的 >>698
PL/Iは印刷メーカーが使っていたな
今はどうなのか知らんが... 新規システム構築が無いので終わってますよ
現行システムメンテで生きてるだけ >>714
>>新規システム構築
COBOLに関してはOpenCOBOL化の案件がちょこちょこ有るよ
Javaとかも少数だが新規案件有るがほとんどメンテ案件 それ既存システムの再構築でしょ
新規システムじゃないので数は限られてる COBOLで全くの新規は無いと思う
COBOL→JavaとかCOBOL→VB.NETとか組み換えは結構有る COBOL→Java移行で、割と中心的な立場で仕事したことある人っています?保険のシステムで。
コンサルがいい感じの話をしてくるんだけど、イマイチ信用できず。 そもそもCOBOL→JavaだとJavaの有償ライセンス化でダメなのが見えてる
今は有償ライセンス買うならC#でもVB.NETへの移行でも良いからね
そこまでするなら富士通のNetCOBOLやマイクロフォーカスのVisual COBOLでも良いし >>723
コンバートツール使うならアレだが一から移行だと火を吹く現場になるだろうね >>724
>>NetCOBOL
横浜銀行はNetCOBOL+PostgreSQL+Linuxだったな >>723
実績を聞いてみれば良いじゃん、そのコンサルに 723です。情報ありがとう。コンサルとは直接話できる立場ではないんですが、コンバートツールは使うと思います。コンサルはほぼコンバートできると言ってるみたいですが、問題になるのはコンバートできない部分かと。
アセンブラとかJCL資産もあります。成功体験ある人いますかね? cobol案件とか聞いただけでうまくいきそうにないんだが
末端で働ていて、どうしてもうまくいかなった場合
どうするの? 誰の責任になるの?
さすがに仕様通り出来なかったでは許されないよね?
どうなるの? >>729
そもそもJavaにコンバートするのがね
オープン系に移行するにもオープンCOBOLとか有るだろうに >>732
COBOLをやりたがる人が少ないから
ジャバラーはいくらでもいるし COBOLという言語は嫌いじゃないけど、COBOLメインのプロジェクトの客先常駐率が高過ぎるのがネック 汎用機だとテレワークがないと思うのは間違え
客先常駐しか出来ないと考えられられてたのは一昨年まででしたね
今はリモートで開発も普通です コロナ渦で本番データを使わない限りリモートワークも可能と言うことになった
今まで客先常駐が普通だと思ってた中高年コボラーの人には衝撃的でしたね >>742
銀行の勘定系システムと言うと多少は関連する仕事に携わった者なら
中核機能と理解してるから、IBMから離れて大丈夫なのか不安に思う。
FinTech等で金の流れが既存システムと違う動きをした時が替えて行く好機なのか。
更にはソフトだけではなく使うサーバーも信頼に足りる性能、堅牢さが必要なので
IBM、HP等以外思当たらない。因みに携わった仕事は銀行業務のフロント・エンド。
>>747
単純な質問に対し、攻撃的になる点については何かあるのかと勘繰りはする。 AS400は良かった
いろんな爺ぃからそんな声が聞こえてきます デバッグがめんどくさい
display文とかいれてよくやってた >>750
IBM汎用機の中身がサーバーと言う点では大きな懸念はないけど
問題は「AWS」(の特徴)が大丈夫なのかと言う点。↓のような噂もある。
プログラマの雑談部屋 ★149
4仕様書無しさん2021/06/28(月) 22:34:58.15>>8
AWSってどんどんサービス発表するけどわけわかんねえよ
被ってるサービスも多すぎるし
簡単になるどころか逆に複雑すぎる
5仕様書無しさん2021/06/28(月) 22:43:09.81
動いてるコードは触るなとかいうクソ方針だからどんどんコードが冗長になっていきやがる >>753
元レス読めよ
5のコメントしてるやつは国内クラウド業者であってAWSじゃない人だよ >>751
AS/400はRPGが主流なイメージある 緊急停止ボタンを押し込んでズドン!という快音を聞きたい スモールビジネスが陥る罠
マイケルE.ガーバーは、「大半のスモールビジネスは、同様の間違いをしている」と言っています。
それは、たとえば、独立した方がいいと思い込んでいる美容師は、美容院を開き、ひたすらに仕事に
追われることになる。料理が得意だからと自分の店を持つことを夢見た料理人は、レストランを開き、
ひたすらに仕事に追われることになる。このような人たちは、どんな種類の仕事であっても、揃って
致命的な思い込みをしているというのです。
その思い込みとは、職人としての仕事、つまり、髪を切ったり、料理をつくったりする技能があれば、
その分野のビジネスを成功させることができるというものです。ビジネスの中心となる専門的な能力を
身につけることと、ビジネスを成功させることは、まったく別問題だというのに。
「独立熱に浮かされた“職人型社長”」と「真の“起業家”」の視点の違いを理解しないまま起業すれば、
大半は破滅的な結末を迎えることになるのです。
マイケル・E・ガーバーは、多くの起業家が失敗している理由を
「職人」「マネージャー」「起業家」という3つの人格から説明しています。
成功できない起業家は、職人レベルの仕事しかしておらず
経営者としての思考も行動もできていないからだとガーバーは指摘しています。
経営者の多くは、職人としての仕事
例えば、美味しい料理を提供できればよいと考え、レストランを開業しますが
この職人型の起業では、成功はおぼつきません。
職人型の社長は、独立しただけで、ただただ自分のためだけに働いているのです。
料理をつくるのを楽しんでいるだけでは、ビジネスは成功しません。
真の起業家は、経営者が現場にいなくても収益を生みだす仕掛けをつくり
組織を成長させることを考え、成功を手に入れるのです。 コボラーって50代以上しかいないの
ttp://blog.livedoor.jp/job_soku/archives/7167533.html
ttp://blog.livedoor.jp/job_soku/archives/7916299.html 45で元コボラー
テレワークで残業なしで夜間立ち会いなしの現場ならまたCOBOLやりたい COBOLもテレワークの時代だけど、短期で空白期間が多くなるから、次の見込みがないとリストラされるよ >>761
あなたみたいな楽したいと思う人が一番いらない >>761
コボラーの現場は昭和から変わってないから
無能でも無駄に残業したほうが頑張ってると思われる 今の案件見てもわかる通りCOBOLだってテレワークの時代なんだぜ
あと働き方改革の波はコボラーの現場にも押し寄せているから意味のない残業も無しな でも本番データ確認するのに、セキュリティルームに設置の専用端末でしけアクセスできない場合はさすがに出社?
それもリモートで可なの? 本番データ確認するのは権限の関係もありテレワークでは無理だけど、それは別にCOBOLに限った事じゃないよね >>766
コロナ禍でCOBOLでも開発はリモート端末によるテレワークで行うが一気に進んだようです 自宅にネット環境がないのでテレワーク出来ない、そんな人が居るのもコボラーさんです 昔は寮から職場のホストにダイヤルアップして仕事させられてたと教わった
30年かけて元に戻ったな 主記憶48KBにテープドライブ2つくらいのシステムでCOBOLやりたいなぁ…… 枕草子の中宮定子の親戚に
原子
というのがいたなあ
未だに読みが不明らしいけど さいたま市です。大宮から電車で川口、鴻巣ぐらいしか行けない。 テレワークだって言ってんのにさいたまにこだわるって
頭の中コボルかよ ごめん なんで相手の顔が見えないとダメなの?
メールと電話だけで充分じゃない? 要件だけ伝わればよくない?
テレワークの必要性がわからない
ところで自宅のパソコンにTSS端末のエミュをインストールしないと
テレワークどうこうは置いといても 自宅で仕事は出来ないよね
自宅で仕事してると いろいろと流出しそうな気もするんだけど 良いのかしら >>791のいうテレワークはビデオ会議のことなのかな
こいつも頭の中コボルだな >>791
いやいや、エミュレーターなんてインストールできない。リモートでしょ 次々頭の中コボルがわいてくるなあ
>>793
端末のエミュ入れずにどうやってリモートでつなぐんだよ
リモート接続できる端末なんて市販されてないぞ? JavaよりもCobolの方が簡単だと思われているらしい
Javaができる能力がないとみなされた場合Cobol要因に
回されるらしい >>JavaよりもCobolの方が簡単だと思われているらしい
今はCOBOLでもオブジェクト指向でCLASS設計も出来る
COBOL→Javaってオブジェクト指向で無くてただのコード移行でしょ 出来ると言ってもやってる所殆ど無いでしょ
レガシーシステムの保守が主だよね >>796
どの辺が?
論理で説明できないあたり、頭がコボルちゃんだね >>802
少しは自分で調べたらどうだ?
あ、COBOLしかしらないから無理かw 説明できない奴の常套手段来たよ
まるでどこかの国の総理大臣みたいだ COBOLに限らず、自宅のPC上で直接開発したりドキュメント類保存したりなんて普通しない。エミュレーターインストールして直接アクセスするなんてセキュリティ的問題ある
基本的に職場にあるPCにリモートアクセス(遠隔操作)して作業する。
と、ここまで説明しないとわからないかい? >>801
ま、オブジェクト指向COBOL自体ほとんど使われて無いからね 最近のcobolはオブジェクト指向だけど
日本の現場でオブジェクト指向cobolが本当に使われているの? そもそもjavaもきちんとしたオブジェクト指向でつくられたシステム少ない COBOL→Javaのマイグレーションはオブジェクト指向で無いJavaのさいたるモノ >>805
やっぱり頭がコボルちゃんだった
リモートデスクトップでどこにつなぐんだよ
リモートデスクトップでつながる端末なんか存在しないぞ >>812
そんなんだから影で老害っていわれちゃんですよ 理解出来ないと人格攻撃をする、頭がコボルちゃんは平常運転だなあ うちはこんな感じ
ホストコンピューター
↑エミュレーター
職場にあるPC
↑リモート接続
自宅のPC
自宅のPCも個人のPCではなく、支給されたPC 汎用機COBOLの開発も今やリモートワークでやっている現実を知らない人がいるのが驚きだよ 311の時出先からRDP経由WSMGRでシステムメッセージを見て東北全滅を確認したわ >>819
今更になってリモート接続とリモートワークの区別がつかないやつが湧いて出てくるとは。。。 君が言ってるリモート接続って、いったい何の事なんだろうね
在宅勤務で職場のPCを遠隔操作する事じゃなさそうだけど 普通はインターネット経由で接続することだろうね
在宅勤務とか関係なく 汎用機は端末エミュレータで操作するから、もともとリモート接続だったりするんだよな。インターネットを経由していることも多い。 今時のCobolの開発環境は何?
OpenCobolIDE とかは日本語化されていないからいや
という人が多そうなんですが 紙に打ち出したソースコードを片手に顔を突き合わせてコードレビュー
入力フォームは画面設計用紙で見やすく
コーディングもコーディングシートにシャーペンで
入力作業は直付けしてある端末から
そんな感じでいい >>825
Visual COBOLとかかな?
マイクロフォーカス製品を使っているところがかなりあるんじゃない。 COBOLはコンパイラはマイクロフォーカスが多いけど、
開発と言うかコーディングはお好みのエディタでどうぞーって感じですよ。
開発環境なんて買ってくれないから。
デバッグはもちろん机上デバッグです! 今時の若者に机上デバッグとかやらせたら次の日から来なくなるな >>829
そんなわけない。
動かすテストより、紙に印刷して確認した方が確実だったりするから、いまでもCOBOLでなくてもやるよ。 リモートワークで自宅のPCに印刷するのが許されてる所あるのかな リモートは職場にあるPC本体から転送されてくる映像を見ながら遠隔操作するような感じなので、印刷は職場のPCに繋がれたプリンタにしか出せないと思うよ Windowsのただのリモートデスクトップ接続だと、ファイルの移動ができるので勝手にやっている。 ある日管理者に気付かれて出来ない設定にされてしまうと >>836
Windowsについてるのはタダじゃないの?
OSの値段に含まれてるから別途料金掛からないよね? 認証が入る仕組みを知らないだけだと思われる。
Windowsのリモートデスクトップ接続はファイルの移動が可能。 windows10の設定で接続を許すセキュリティーがザルな現場があるんだね >>840
リモートする側に制約がないから、個人のPCにファイルを移動できる。 個人のPCでリモートしてるところあるのか
あと、設定でファイル移動禁止にしてるでしょう。まぁ管理者権限があれば外せちゃうけど >>842
逆だよ。貸与PCから個人のPCにリモート接続する。 >>843
842がいう個人ってのは「個人に割り当てられた執務PC」ではなくて
「プライベートで購入したPC」のことを言ってるのだと思うぞ 行番号にgotoとか
行番号の振り直しとか
今でも必要ですか? >>842
貸与PCでも貸与PCにファイルを転送できてしまえば、個人のPCにリモートデスクトップ接続で接続してファイルを転送できるので、結局、抜き取れる。 仮想環境整えれば、自宅からでも普通にやれそうだけどな。 gotoのとび先を動的に変えるalter文というのかあるみたいですが
使われているのですか? 昔からGOTOって禁止されてんじゃねーの?
PERFORMで呼び出しやろ 新卒で入った会社の70年代のプログラムはすべてGO TOだったよ
80年代入るとPERFORM THRUに変わってて感動した思い出 入口 SECTION.
(処理)
出口.
EXIT.
と
入口.
(処理)
出口.
EXIT.
の2つの流儀があって、前者だと「PERFORM 入口.」、後者だと「PERFORM 入口 THRU 出口.」だったな しぶといなttps://asahi.5ch.net/test/read.cgi/newsplus/1635941818/ >>858
ネットでイキってる恥ずかしい人だから暖かく見守ろう 30年以上前から無くなる、無くなると言われてて未だに現役なのな。 石油もCOBOLも、それが無くなることで巨額の利権を手に入れられる輩がいるって意味では同じだね 株式会社週休3日が「週休3日正社員」に特化した求人ポータルサイト「週休3日.com」を正式リリース。
2022年1月から本格始動。企業の利用申込を受付開始。先着200社は1年間限定 月額9,900円(年間契約)。
次世代型ワークライフマッチング「+1日マッチング」を実装し、新しい人材マッチングを創出します。
週休3日.comの主な特徴
1、週休3日正社員の求人を最適化・差別化して募集できます。
20代・30代の若い世代が注目している週休3日正社員など新しい働き方を活かした募集が可能です。
40代以降の優秀な人材の採用にも有効です。(週休3日.comは商標登録を取得しています)
2、月額固定でリーズナブルです。採用時に追加費用がかかりません。
月額22,000円から※採用時に追加費用がかかりません。
今ならオープニングキャンペーンで月額9,900円(年間契約/ ※1年間限定 先着200社)
3、週休3日正社員の働き方を選択することで生まれる+1日のお休み(時間)の価値観もマッチングが可能です。
次世代型ワークライフマッチング「+1日マッチング」
・+1日のお休みは副業したい→会社として許可する?
・+1日のお休みは遠方へ旅行したい→会社として共感する?
・+1日のお休みは子供との時間に使いたい→会社として応援する? >>861
嫌なものほど世の中から中々なくならないのだよ。
中々なくならないから嫌がられているとも言えるが。 COBOLの需要が増えて単価が上がってきてるってガチですか??
だとしたら面白い事になってまいりましたな COBOLが消えないのならJavaなんかもう一生使えそうですな。。。 cobolって変数は全部グローバルだし
ループから抜けるには実質gotoしかないのな
ループの中に飛び込むこともできるし
どうやって保守するの?
「できません」って投げ出すことは可能なの? それってどの規格のCOBOLの話か具体的に言ってほしいなぁ つかえない>>870を成績不良で切るために渡されたソースの話じゃないのそれ gotoを使わずにperformを使ってくれって言う人がいて
それってgotoじゃんという使い方をしている goto使えば良いよ
アセンブリ言語なんてgotoだらけだよ 他セクションの中にGO TO しまくる糞COBOLソースをメンテした事ある。
アセンブラ世代の糞爺が作ったらしい。 ちなみにCOBOLはGO TO な。
gotoならCだろ。 なんか日本人はバカというか教条主義的過ぎるというか
goto禁止というと死んでも使わせない的な話になるけど
上に行くのと飛び越すのさえやらなければ後は使い方だろ >>882はコーディング規約に死ねと書いてあったら死ぬんだろうか GOTOの話ってフローチャート書く上でのお作法の話や
条件分岐文に命令や命令群を直接書けず必ずGOTO文で飛ばすしかない仕様の言語を設計するのやめよう
とかいう話ではなく、GOTOならば無条件に害悪であるからコーディングの美しさのために排除しろ
って話なんだっけ? 馬鹿が飛んでもないところに飛ばすのが頻発したから一律禁止にしたとかそんなんじゃないのかな 一番問題なのはループの中へのgoto
ループの中を書き換えるととんでもないところで
副作用が起きる ループの中へのgotoというと、昔々アセンブラではそんな感じのをよく見たなあ。
1バイトでもコードを減らそうとしてそういうことをする。 >>886
それはGOTO禁止じゃなくて、そいつ切るべき案件だろ
絶対他でもやらかす >>889
cobolの場合、既存のコードがそんなんばっかりというのが
一番大きな問題
スパゲッティになっていて手が付けられない
いわゆるマイナスからのスタートになる よかった……共通化したコードへ飛んで使いまわすような書き方をするな!
行数を稼ぐために同じ処理もしっかりと複数全部書け!
という悪い子はいないんだ…… >>889
切ったところでそんなやつは無限増殖のように頻繁に現れる
予防策として事前に禁止事項にしたんだろ はじめは道徳を説いていただけなのに
馬鹿向けの規則に捻じ曲げられてしまうという
悲しい世の中だね システム開発には決まり事が必要だよ
俺様が作るコードが一番で勝手につくられてはたまらない コーディング規約のGO TO禁止って、
セクション構造の出口(EXIT文の前に適当なラベルを付けておく)へのGO TOはいいけど、
それ以外へのGO TOはダメとかそんなんでしょ? >>896
それだとループからの脱出
continueとbreak
が書けない >>897
COBOLにbreakは無いぞ、continueもCとは意味が違うし。 >>897
いっそのこと脱出しなければいいんじゃない?
次の命令をNOPすればいい 大手のSier企業で金融系で売上の50%を占めているところは半分くらいCOBOLのシステムを扱っている
公共系のところも同様
フリーランスと比べて正社員になるとCOBOLやらされる率が高くなるね COBOLのレガシー資産は塩漬けにして改修は行わない
新機能は他システムで行いコボラーは既存コードに影響ないか調査やテストするだけの存在 COBOLなんてまだあるの?
大分javaに置き換わってるよね 富士通が作ったシステムを作り直しているんだけど、富士通があとから作ったドキュメントしか残っていない。 早くドキュメントが合ってるか確かめる作業に戻るんだ まだまだ社内の基幹システムとしてガンガン新規開発してる。どのパッケージ導入よりもバリューを生み出し続けている。 大きい会社は仕事が営業だから、いまでも体育系なんじゃね? 大きいIT会社は仕事の9割が人員管理、議事録作成、顧客折衝、営業だからSEというよりは営業職だ 大手SI企業とかはプログラミングを1%もやらない
人員管理の仕事は体育会系が好まれる プログラミングできるやつはスグFA宣言しちゃうからねぇ。
企業内にはプログラミング出来ないやつしか残らない。 某自治体で5年前までCOBOLで開発してた。
身体壊して退職したけど。
使っていたのは汎用機。
身体だいぶマシになって来たので仕事復帰したい。
どこか雇ってくれるかなあ? レス数が900を超えています。1000を超えると表示できなくなるよ。