COBOLって今需要増えてるの?Part7
1 :仕様書無しさん :2018/05/26(土) 20:22:38.70 .net ■前スレ COBOLって今需要増えてるの?Part5 [無断転載禁止]©2ch.net http://medaka.2ch.net/test/read.cgi/prog/1481468519/ COBOLって今需要増えてるの?Part6©2ch.net https://medaka.5ch.net/test/read.cgi/prog/1497126175/
2 :仕様書無しさん :2018/05/26(土) 20:53:16.36 .net 髪の毛は増えてない!
3 :仕様書無しさん :2018/05/26(土) 22:36:32.86 .net 仕事はあるある
4 :仕様書無しさん :2018/05/26(土) 23:30:37.10 .net > 999 名前: 仕様書無しさん [sage] 投稿日: 2018/05/26(土) 19:52:09.83 > >>996 > COBOLの現場は今でもCOBOL85が主流だから > FUNCTIONの出る幕ないよね 利用者定義関数のことなら確かにCOBOL2002からだけど、 組み込み関数ならCOBOL85の時点でとっくに実装されてた。
5 :仕様書無しさん :2018/05/27(日) 01:13:34.36 .net >>4 私の勉強不足かもしれないけど 組み込み関数の存在自体知らないわ 職場に据え付けのCOBOL85の言語仕様書には そのようなものは記述されていなかったからなんだけどね
6 :仕様書無しさん :2018/05/27(日) 16:59:23.09 .net >>5 たまたま>>5 が知らなかっただけだろうね。 組み込み関数自体は特段マイナーなものではない。 テーブル内の特定の項目の最大値や合計値等を求める場合に テーブルを1から最後までループしていたり、 ある数をある数で割った余りだけが必要(商は不要)な場合に、 わざわざWORKING-STORAGEに使いもしない商格納用の変数を定義して DIVIDE文を使ってたりするソースを見ると、無駄なことしてるなあって思う。
7 :仕様書無しさん :2018/05/27(日) 23:11:31.58 .net 組み込み関数って第3次追補1規格だから、 日本に入ってくるのが遅かったんじゃないの? 古いCOBOL85の仕様書には載ってなくても不思議はない。
8 :仕様書無しさん :2018/05/27(日) 23:26:54.65 .net 第3次追補1規格は米国では1989年、日本でも1992年制定か。それでもなかなか古いね。
9 :仕様書無しさん :2018/06/02(土) 11:05:00.48 .net 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.
10 :仕様書無しさん :2018/06/06(水) 05:18:55.90 .net まだあるのかこれ
11 :仕様書無しさん :2018/06/10(日) 13:59:30.18 .net マイグレーション元のCOBOLと、マイグレーション先のJavaの両方できれば当分需要ありそうだよなあ。片方できるのはいっぱいいるけど両方は全然いない。 まあマイグレーションって基本ブラック案件だから、できないほうがいいのかもしれないが。
12 :仕様書無しさん :2018/06/10(日) 16:06:27.08 .net COBOL捨てるならマイグレーションとかしないで、新規システムにするだけじゃないの。
13 :仕様書無しさん :2018/06/10(日) 18:30:03.35 .net 以前の仕組みを理解している人がいない
14 :仕様書無しさん :2018/06/10(日) 20:09:38.18 .net だったら、 古いのは捨てる 古いのはそのまま使う のどちらかだろう? 後者ならCOBOLの出番があるが、 そのまま使うならjavaの出番はない
15 :仕様書無しさん :2018/06/11(月) 08:17:09.49 .net COBOLシステムの大規模改修自体が出来ないから、そのまま使ってるんですが? だから運用で対応するわけね
16 :仕様書無しさん :2018/06/11(月) 20:45:51.87 .net COBOLはあまりに量が多すぎて、その上継ぎ足し継ぎ足しで使われてて (ただし仕様書は継ぎ足されない)基本何してるのかもさっぱりわかんないから COBOL捨てるって選択をいれると、まず金の面で話にならねえからなあ
17 :仕様書無しさん :2018/06/21(木) 17:32:51.73 .net こりゃCOBOLがなくなるな
18 :仕様書無しさん :2018/06/29(金) 18:00:29.82 .net 世の中には無くなる無くなると言われながら、 何だかんだで残ってるものがいっぱいあるよね。 COBOLもその1つ。
19 :仕様書無しさん :2018/06/30(土) 16:47:00.43 .net >>17 の願望でしかないもんなぁ
20 :仕様書無しさん :2018/07/14(土) 14:03:34.50 .net 絶滅危惧種のウナギの価格が暴騰しているのと一緒 かつて中国産のうなぎは150円も出せば買えたが今は何千円もするだろ しかも引退したオッサン達が仕様書もろくに作らずに、こねクリ回したスパゲッティコード これは罰ゲーム、前世代のケツ吹きだから、若い人はやりたがらないということ コボラーのジョークがウィキペディアにまでのってるw https://ja.m.wikipedia.org/wiki/COBOL IDENTIFICATION DIVISION ENVIRONMENT DIVISION DATA DIVISION PROCEDURE DIVISION だったような 商業高校の情報系ってまだCOBOLやってるのかな?
21 :仕様書無しさん :2018/07/14(土) 21:09:07.33 .net 企業の事務処理全般が手書きが常識の時代から 全てIT化するのが常識の時代へ移り変わったのはバブル景気の時 企業は節税目的もあって一斉にIT化に費用を掛けた 当時技術者の数がまったく足りなくて、いち早く技術者として一人前になれる ある意味簡易な言語がCOBOLであり 高度なことができないからかえって安全な言語だった その時に作られた膨大なシステムがほぼCOBOLだから これを駆逐するのは多分あと100年経っても無理だと思うんだぜーーー 私は還暦後のアルバイトとしてコボラーに戻る予定 今は流行りの言語やってるけど周りの若い子の すぐ諦める姿勢には苦笑いしかでないわ それは言語の仕様の問題じゃなくて、あなたの根気の問題じゃねーの?って 内容の愚痴をさも正当な理由かのように、愚痴愚痴と煩いわ
22 :仕様書無しさん :2018/07/14(土) 23:57:30.49 .net 古いCOBOL資産は改修しない方向なんだよ 運用でカバーする
23 :仕様書無しさん :2018/07/15(日) 00:07:31.23 .net 他の言語も大差ないのでは? COBOLよりは遥かにマシだと思うけど
24 :仕様書無しさん :2018/07/15(日) 01:19:03.17 .net バブルな時ってパソコンと言えばMS-DOS 業務用としては非力すぎるのでバブル期に導入されたのは メインフレームやオフコン それらはほぼ独自OSで使える言語はほんの少しだけ 選択肢は基本的にCOBOLしかなかったんだよね もちろんUNIXとかも日本に上陸してたから素のCで組むこともできたけど 新人を急遽C使いするぐらいならCOBOL使いにした方が安全かつ安上がりなんだよ
25 :仕様書無しさん :2018/07/15(日) 17:56:59.03 .net >>23 COBOLはオープンシステムでも動くけど、PL/1はどうにもならないよ
26 :仕様書無しさん :2018/07/15(日) 17:58:26.47 .net >>24 4GLなんかが流行ったね
27 :仕様書無しさん :2018/07/26(木) 16:50:01.10 .net >>22 Javaライセンスの影響でOpenCOBOLの評価が変わる
28 :仕様書無しさん :2018/07/26(木) 16:52:29.71 .net バッチ処理部分をOpenCOBOL化してUI部分をPHP、Pythonで作れればJavaより安く作れる
29 :仕様書無しさん :2018/08/02(木) 22:16:55.82 .net C#やJavaだと%で余り算出してる人が、いざCOBOLになるとわざわざ使いもしない商格納用の変数定義までしてDIVIDE文を使う不思議。
30 :仕様書無しさん :2018/08/05(日) 13:00:09.97 .net お金の計算をできるのはCOBOLだけだ。 ゆえに、銀行でつかわれるのだ。
31 :仕様書無しさん :2018/08/05(日) 16:45:24.81 .net C#、Javaは計算出来るが金額計算には向かない それを無理やり金融機関でシステム移行に提案したのは大手Sier この人たちの罪は大きい
32 :仕様書無しさん :2018/08/05(日) 19:40:42.31 .net 実際には桁の大きい10進数計算が正確にできればいいだけだよな。 で、そういうのはライブラリで出回ってて既に言語は関係なくなっているように思うのだがなあ。 かといってその一歩を踏み出す勇気はないと。金扱ってるのでリスクは極限まで下げたい。 ということでCOBOLは生き続けているんだろうな。
33 :仕様書無しさん :2018/08/05(日) 21:57:42.08 .net 既に稼働しているCOBOL資源が多過ぎて、それら全部変えるにはコストも時間も掛かり過ぎるし、 別の言語で新たに起こし直す以上どうしたってリスクも避けられないからな。
34 :仕様書無しさん :2018/08/06(月) 16:52:48.89 .net >>32 >>ライブラリ OpenJDKででも存在してれば、ね 実際メガバンクは自前で金額計算部分を銀行個々でライブラリ化してるだろう それをライセンス徴収開始で御破算にするのは今更出来ない みずほはプログラマ確保のし易さからJava採用したが、結果的に納期に間に合わず外国人が実装してた りそなみたいにCOBOLでUI部分も作れるなら、その方が賢かったが三菱UFJへの対抗から安易にJavaへの移行を決定して未だに苦労してる
35 :仕様書無しさん :2018/08/06(月) 21:54:24.97 .net 産みの苦しみだな
36 :仕様書無しさん :2018/08/08(水) 13:39:16.72 .net >>35 産みの苦しみだよね
37 :仕様書無しさん :2018/08/08(水) 14:27:42.38 .net >>34 苦労してるね
38 :仕様書無しさん :2018/08/08(水) 16:53:40.12 .net みずほがグダグダなのは取締役連中がダメだから、が一番大きいけどね 遅かれ早かれ逝くと思う
39 :仕様書無しさん :2018/08/09(木) 20:25:16.49 .net >>30 VBだって通貨型の変数あるじゃん だからといってVBで開発はしないと思うけど
40 :仕様書無しさん :2018/08/09(木) 20:47:50.68 .net >>39 有る しかし、DB上で定義するだけで無く、途中の計算し易さとか編集のし易さがVBはCOBOLに劣る VBプログラマーの一時しのぎ主義も問題として有る (とりあえず動けば良い)
41 :仕様書無しさん :2018/08/10(金) 01:42:52.54 .net やはりCOBOL復活だな
42 :仕様書無しさん :2018/08/10(金) 23:17:38.16 .net 今はC#やってるんだけど、同じようなバッチ処理を作ってもC#だとめちゃ早く作れる 色々な便利機能がついてるから 同じことをCOBOLで作ろうと思うと2〜3倍は時間がかかると思う だからCOBOLがダメだって話じゃないよ 最後にCOBOLの開発案件にかかわったのは3年前だけど COBOLの開発なのに、そのスケはおかしーーーーんじゃないの?ってぐらい 開発期間が異常に短くてスケ通りにまったく進まないどころか スケで予想されてる2〜3倍は時間がかかったので下請け会社は大赤字だったみたい で、このスケを引いて見積もり書いたのも仕事発注した窓口もJavaしかやったことありませんって人だった これだからCOBOLわーーーーーって陰口言いまくりだったみたいだけど COBOLで納得して仕事受けたんちゃうんかい!って思った 今日はC#で作業領域の集団項目とかREDEFINEとかCOPY句機能が使えたらなーーーとボーっと考えてた いちいち、newとかnewとかうぜーーーーーよ! そして集団項目と再定義使わせろ
43 :仕様書無しさん :2018/08/10(金) 23:19:47.08 .net 途中で送信しちゃったわ 集団項目から集団項目への転送も簡単にやらせろーーーー せめてコレポン使わせて・・・
44 :仕様書無しさん :2018/08/11(土) 02:56:20.22 .net コレポンって楽な機能だよね
45 :仕様書無しさん :2018/08/11(土) 06:07:11.00 .net >>42 それはJavaでの開発した事無い会社が悪い COBOLでの開発経験有る会社ならそんなスケジュールしないでしょ そもそもオブジェクト指向言語のJavaでの開発工数とCOBOLの開発工数を同じ感覚でやってたらアホとしか言えんわw
46 :仕様書無しさん :2018/08/11(土) 09:45:00.18 .net 【料金搾取】SEの結婚障害原因【無能残業】 ☆偽装請負多重派遣SEの結婚相手の犠牲原因☆ 両親や親戚に反対されましたが、偽装請負多重派遣会社に高額搾取金を提供したり時間外労働違反で家事をしないSEと結婚してしまい、生活困難で中絶と離婚をしました。現在は犯罪損害のない相手と共働き生活をして、数億円損失を防げました。 ・モラルがない ・キモい ・ファッションセンスがない ・コミュニケーションが苦手 ・コンピューターが趣味 ・プログラムの料金以上の不利益生産 ・プログラムの巨額利益を客先に提供 ・プログラムの巨額報酬を人売に提供 ・プログラムの知的財産を人売に提供 ・ITスキルが高いのに低料金請求 ・高度情報処理技術者なのに請求料金不足 ・高利益なのに請求料金不足 ・高生産なのに請求料金不足 ・高需要なのに請求料金不足 ・学習多いのに請求料金不足 ・人員不足なのに早期退職 ・会社員なのに早期退職 ・PC使用過多で不健康 ・運動不足で不健康 ・高稼働で不健康 ・高稼働で家事困難 ・低収入で生活困難 ・低収入なのに鬱病多発 ・低収入なのに早死多発 ・不利益なのに断らない ・偽装請負の多重派遣損害あるのに稼働 ・裁判官が技術判断不能だから賠償困難 【IT業界】独身が多い職業の象徴として「ITエンジニア」が取り上げられる http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/110200713/?ST=spleaf
47 :仕様書無しさん :2018/08/11(土) 15:56:38.81 ID:ztgqAOgQI >>16 メーカーのSEがCOBOLなくせないって昔から言ってるし、 メーカー側もCOBOL資産を生かす方でユーザーに提案するからね COBOLなくすなくすってそんなのは他の言語で開発させたいときのセールストークでしかないわ
48 :仕様書無しさん :2018/08/11(土) 18:16:23.47 .net >>45 COBOLで開発した事無い企業、だわ 間違い
49 :仕様書無しさん :2018/08/11(土) 22:22:46.53 .net C#ってjavaのようなものなんでしょ
50 :仕様書無しさん :2018/08/11(土) 22:30:20.25 .net ボラクルが関わってないからリスクが大違い
51 :仕様書無しさん :2018/08/12(日) 00:26:51.35 .net >>49 言語仕様はC++ベースは同じ 問題はCOBOLの様に金額計算や小数点計算に向かない事
52 :仕様書無しさん :2018/08/12(日) 01:23:32.86 .net やはりCOBOLが一番。日本人はなぜか古くても良いものを大事にしないからおかしい。
53 :仕様書無しさん :2018/08/12(日) 16:59:00.63 ID:CpJxMJIiq COBOLを使い続けるのが一番安上がりで現実的なんだけど、 新しい物を提案し続けないと商売にならないっていう考え方もあるからまあ仕方ない。 単純にメンテするだけなら毎年単価下げないとユーザーは契約しないよ、それじゃあ技術は進まないし。
54 :仕様書無しさん :2018/08/14(火) 17:12:23.12 .net 金融系でJavaへ移行してライセンスの話で梯子外された中小企業は死亡状態
55 :仕様書無しさん :2018/08/14(火) 20:04:34.15 .net 具体的に何がどうしたんだ?
56 :仕様書無しさん :2018/08/14(火) 20:22:32.95 .net 実業務でこんな大きな数を扱うことはまず無いだろうが、 FUNCTION INTEGER(FUNCTION LOG10(999999999999999999))が18を返してきた。 OpenCOBOLとIBM Enterprise COBOL for z/OSで確認。
57 :仕様書無しさん :2018/08/15(水) 18:12:43.13 .net >>56 それ、どっちもモジュールはCに変換されるヤツだな Cに変換された後のバグじゃね
58 :仕様書無しさん :2018/08/16(木) 02:06:39.58 .net >>54 今必死こいてOpenJDK化してるんじゃね オラクル特許侵害する様なプログラムソース作ったら訴えられるのに
59 :仕様書無しさん :2018/08/16(木) 07:09:49.74 .net あくまでも思い込みです
60 :仕様書無しさん :2018/08/17(金) 11:37:29.02 .net なんでコボルは数値計算が強いの? 今の言語でも結構な精度だと思うけど、何が違ってどんな技術的理由によるの?
61 :仕様書無しさん :2018/08/17(金) 12:24:47.66 .net COBOLの数値精度の精度が高いんじゃなく、やれることが限られてるため誰がプログラム作っても計算精度に差がないこと
62 :仕様書無しさん :2018/08/17(金) 13:35:47.83 .net >>61 その上、計算コードが読み易い 他の言語は人によって読めないから
63 :仕様書無しさん :2018/08/17(金) 16:34:24.59 .net そうだよね COBOLの計算式は本当に算数のようで プログラム未経験者でも見やすいと思う 他の言語は自由がききすぎて お金の計算、特に利息などの少数以下の取り扱いが どの段階でどの様に丸めるかとか あーんまり考えたことない技術者だらけだと思う 丸め方で積み重なれば数億の損害になったりするから ここは非常にシビアなところなんだけどね
64 :仕様書無しさん :2018/08/17(金) 20:32:26.71 .net >>63 実際メガバンクでCOBOL→Javaに移行した所は全く誤差が無い、とは言えない危険性が有る 経営者が気づいて無さそうだが
65 :仕様書無しさん :2018/08/18(土) 04:03:17.32 .net COBOL需要、と言うか金融系では再評価されてる
66 :仕様書無しさん :2018/08/18(土) 12:30:16.05 .net その根拠は?
67 :仕様書無しさん :2018/08/18(土) 14:50:46.79 ID:EMVynphPc https://twitter.com/EnTgO9RDFSj6CDW
68 :仕様書無しさん :2018/08/18(土) 14:17:06.08 .net >>66 うーんたぶんだけど 他の言語だと技術者の粒が揃わず品質にバラつきが出やすいからじゃないかな? 今私はオブジェクト指向言語を使ってるけど、 バージョンアップ対応で元のソースを解読してると 何度も何度も車輪の発明をしてて馬鹿かとしか思えなかった 言語としては優れてるのかもしれないけど 技術者およびマネージャーの意思疎通が図られておらず どいつもこいつもオレ天才やらオレ無双の独りよがりなコーディングしてるわ その点、COBOLだと強制的にある程度の画一性や品質が確保される
69 :仕様書無しさん :2018/08/18(土) 15:11:18.95 .net >>どいつもこいつもオレ天才やらオレ無双の独りよがりなコーディングしてるわ それはVB4,5,6の時でも有った話 実質、プログラマのメンタルは変わってない それがオブジェクト指向でも発揮されてコードが他人に理解しにくくなってる >>その点、COBOLだと強制的にある程度の画一性や品質が確保される この一点につきる
70 :仕様書無しさん :2018/08/19(日) 07:42:51.43 .net >>68 それ金融系がということじゃなく、根拠は自分がそう思ってるだけだよね
71 :仕様書無しさん :2018/08/19(日) 08:52:39.35 .net 数値計算だけ特別にクラス作って処理すれば、他言語でもコボルの代わりになれる?
72 :仕様書無しさん :2018/08/19(日) 11:25:07.72 .net 数値計算といってもCOBOLで使われるのはあくまでも整数計算のみ 固定小数点のね
73 :仕様書無しさん :2018/08/19(日) 15:04:35.54 .net >>71 正解 COBOLで外部モジュール作ってJavaとかPHPから使えば良い >>72 小数点付き計算やわり算の誤差が無い部分がCOBOLのメリット それを外部モジュールで作る
74 :仕様書無しさん :2018/08/19(日) 15:11:28.92 .net >>70 COBOLが金融に強いのは>>63 に書いた通りだよ
75 :仕様書無しさん :2018/08/19(日) 19:53:48.12 .net 要は小学生で習う程度の算数計算に強いだけじゃん 金勘定の基本は算数だけどさ
76 :仕様書無しさん :2018/08/19(日) 23:05:52.21 .net >>75 あなたが技術者でないことはわかった
77 :仕様書無しさん :2018/08/20(月) 01:14:26.90 .net そもそもコボラーは技術者じゃないよ 昔は商業高校でCOBOL教えていた だからCOBOLしかやったことない40過ぎのおばちゃんのスキルシート見ると最終学歴が商業高校だったりする 実務的には簿記をやるレベルってことさ
78 :仕様書無しさん :2018/08/20(月) 01:50:10.27 .net 蛇腹ーは簿記すら理解できないじゃん。。。
79 :仕様書無しさん :2018/08/20(月) 03:09:32.35 .net そういう人達を排除した結果がCOBOL→Javaだった で、オラクルに梯子外された
80 :仕様書無しさん :2018/08/20(月) 07:06:44.97 .net 話がずれてるのは何でだろうね
81 :仕様書無しさん :2018/08/20(月) 08:18:02.88 .net COBOLが再評価されてるって、JavaからCOBOLへのシステム再構築があるってことか マジで?
82 :仕様書無しさん :2018/08/20(月) 17:55:53.82 .net >>81 Java→COBOLは無いよ そういう所はライセンス払ってJava継続するかスクリプト系言語に変えるかしか無い COBOL→Javaへ移行検討してた所が方針見直してCOBOLのままオープン化するって事
83 :仕様書無しさん :2018/08/20(月) 20:41:05.07 .net >>82 なんでそこでスクリプト系言語が出てくるんだ?
84 :仕様書無しさん :2018/08/20(月) 20:41:49.00 .net そんな事例聞いたことないのだけど、ソースは自分がそう思ったとかじゃないよね。
85 :仕様書無しさん :2018/08/20(月) 21:29:02.29 .net だから一旦、Javaに移行したらJavaの蟻地獄にはまって抜けれ無いよ
86 :仕様書無しさん :2018/08/21(火) 01:00:27.81 .net goto文だらけのCOBOLよりマシ
87 :仕様書無しさん :2018/08/21(火) 01:18:32.96 .net 今は構造化プログラミングでGOTO文地獄って少なくなってる
88 :仕様書無しさん :2018/08/21(火) 01:31:54.55 .net GOTOはEXIT行き以外は禁止のとこがほとんどだよね ↑に戻るのは頭がおかしいのか?扱いされる
89 :仕様書無しさん :2018/08/21(火) 01:38:42.73 .net COBOLは一回開発しちゃうと同じソースをメンテしてメンテして使いまわすから むかーしのGOTO地獄とフラグ地獄をたまに見かけるよね むかしのマシンが非力かつ高額な時に、負荷が少なく高速で実行できるからってことで GOTOを多用してたからまあ仕方ない
90 :仕様書無しさん :2018/08/21(火) 04:16:57.33 .net 古いソースはね 今はほとんど構造化プログラミングでしょ GOTO文がほとんど無しでサブルーチン化 むかーしのプログラムを修正する時にGOTO文とフラグの嵐みたいなのに当たると相当の苦痛を強いられる
91 :仕様書無しさん :2018/08/21(火) 07:15:03.55 .net gotoを使わないことが構造化プログラミングだとドヤ顔で言いIF文のネストをひたすら繰り返す老害コボラー。
92 :仕様書無しさん :2018/08/21(火) 08:02:38.28 .net >>91 小学校から国語やりなおしたら?
93 :仕様書無しさん :2018/08/21(火) 08:22:44.35 .net PERFORMの飛び先にPERFORM二つ またその飛び先にPERFORM三つ そして最後にあるのは、MOVE文のみ。 若造よ、これが構造化プログラミングなのだよ! あと内部PERFORMは禁止な。
94 :仕様書無しさん :2018/08/21(火) 12:32:03.82 .net 老人は構造化プログラミングが〜と言い、若手はオブジェクト指向プログラミングが〜と言う そしてお互いに馬鹿にする これが底辺プログラマです
95 :仕様書無しさん :2018/08/21(火) 15:50:20.46 .net COBOLでオブジェクト指向ってNETCOBOLで出来たと思うが .NET環境でCOBOL使わないならCOBOLにオブジェクト指向なんて不要だし、ほとんど構造化プログラミングで済む 適材適所だわな オブジェクト指向プログラミング出来る言語は重要だが、それが足かせになってる言語も有る Javaが最たるモノだが
96 :仕様書無しさん :2018/08/22(水) 21:38:37.23 .net 確かに固定小数点の数の、四則演算及び整数乗の計算精度は高いね。 >>77 その頃はまだ誰もが大学に行くのが当たり前という時代では無かったから、 実はそこそこ頭もいいんだけど親の稼ぎの問題等で高卒って人も時々いる。 でも、今30代以下の人で、大学に行ってなかったり、定員割れしてるような大学出身の人は、極一部を除いて驚くほど頭の悪い人が多い。 例えば1〜12月や日〜土曜日を英語で書けない、ヘボン式のローマ字表記を知らない、小学校で習う程度の漢字の読み書きが出来ないとか。
97 :仕様書無しさん :2018/08/22(水) 23:53:51.05 .net やたら人のあらを探して見下すことを言うのも老コボラーの特徴だね
98 :仕様書無しさん :2018/08/23(木) 02:05:14.26 .net 汎用機COBOL→オープンシステム化は有る
99 :仕様書無しさん :2018/08/23(木) 02:43:22.05 .net >>98 富士通のSEから聞いた話で、その後に 汎用機COBOL←オープンシステムに戻ってくるのが 100件に1件くらいの割合であったってさ。 ウチも最後はエミュレータで締めたけど。 まあ、減っていく一方に変わりはない。
100 :仕様書無しさん :2018/08/24(金) 02:17:12.50 .net >>99 戻るメリットって無い様な、、 オープン化したらオープン化のままCOBOL使えって
166 KB
新着レスの表示
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★
本文 スレッドタイトル 投稿者