X
【IT】COBOLに罪はない　トップ自ら情報戦略を
■ このスレッドは過去ログ倉庫に格納されています
0001田杉山脈 ★
垢版 |
2019/08/12(月) 17:28:11.27ID:CAP_USER
日本の活力低下の一因はデジタル化の出遅れにある。まず手を着けるべきは、古びた情報システムの刷新だろう。改修できる人材の枯渇も迫っている。デジタル化による爆発的な変化に企業が適応するには、トップ自らが情報戦略を主導する必要がある。

「COBOL」というプログラミング言語がある。1959年に業務用に開発され、金融機関などの基幹システムでは依然として現役だ。統計不正で問題となった厚生労働省の毎月勤労統…
https://www.nikkei.com/article/DGXMZO48430390Z00C19A8TCR000/
0083名刺は切らしておりまして
垢版 |
2019/08/13(火) 03:10:19.50ID:DZ9DXpqA
コボちゃん
0084名刺は切らしておりまして
垢版 |
2019/08/13(火) 03:29:46.90ID:k+l7S400
適材適所、COBOL や Java とかそれぞれの言語に向いてる処理がある。
COBOL で問題なく動いてる事務処理をわざわざ別の言語に書き換えるメリットなんかないだろうよ。
メンテなんて必要な時にはその言語を勉強してやればいいだけ。
特定の言語しか使えないやつがいるという前提がおかしい。
0085名刺は切らしておりまして
垢版 |
2019/08/13(火) 05:20:34.67ID:cPBvRCQR
>>6>>7
おまえみたいに同じ内容でステップ数稼ごうとするヤツには無理
0087名刺は切らしておりまして
垢版 |
2019/08/13(火) 06:17:20.67ID:IVUHMQjf
>>86
COBOLだと、リファクタリングがやりづらそう

昔からの言語仕様で作られているソースが大半だろうし、コボラーが新しい言語仕様で作り直すととても思えない
0089名刺は切らしておりまして
垢版 |
2019/08/13(火) 06:50:56.52ID:IVUHMQjf
>>88
別にCOBOLのままでもいいけど、オブジェクト指向を取り入れた新しい言語仕様で作れ

PHPだって、オブジェクト指向を取り入れて延命してるだろ
0090名刺は切らしておりまして
垢版 |
2019/08/13(火) 06:57:54.68ID:9eWAW4Cd
>>87
JAVAのほうがやりづらいわい

やりやすい前提が崩れたJAVAだよ？ぐちゃぐちゃになっててあっちこっちソースが分断されてて、、、最悪だ！COBOLのがマシ！
0093名刺は切らしておりまして
垢版 |
2019/08/13(火) 07:08:59.17ID:++0mpnZi
>>53
新たに作るのは良いのだが既存システムを載せかえるのは困難を伴う。
文字コード体系の違いは大きい。
0094名刺は切らしておりまして
垢版 |
2019/08/13(火) 07:17:18.34ID:Y1ITNsI+
COBOLに関わる人はみんな後ろ向き
そんなCOBOL界隈が大嫌いです
0096名刺は切らしておりまして
垢版 |
2019/08/13(火) 07:31:54.93ID:6ic7qen+
コボルは業務システムをパターン化したモデルに基づいて良く考えられている。
新しい言語はプログラミングし易くなっているが、この手の記述に向いている訳でもない。
問題があるとすれば、プログラミングが面白く無いんだよ。
0097名刺は切らしておりまして
垢版 |
2019/08/13(火) 07:39:16.50ID:9eWAW4Cd
>>92
そんなわけあるかい
めちゃくちゃなコードはどの言語だってめちゃくちゃだ
定期的にまずいコードを破棄してく保守がなけりゃどれだって最終地点はゴミクズさ
0098名刺は切らしておりまして
垢版 |
2019/08/13(火) 07:52:44.10ID:IVUHMQjf
>>97
めちゃくちゃなコードでも、オブジェクト指向にして、開発環境のミドルウェアを使いこなせば、保守効率は雲泥の差
0100名刺は切らしておりまして
垢版 |
2019/08/13(火) 07:58:52.81ID:GgkNzH8Q
最近の言語は5年くらいで刷新されるから、COBOLよりも危険だろ。
アプリ開発やパッケージシフテムならそれでなもいいけど、勘定システムでそれだと無理。
0101名刺は切らしておりまして
垢版 |
2019/08/13(火) 08:05:18.14ID:9eWAW4Cd
>>98
オブジェクト指向じゃねぇコードがめちゃくちゃにパッチ当て的に書いてあるんだよ！
20年も同じコード修正し続けたらそうなるの
0103名刺は切らしておりまして
垢版 |
2019/08/13(火) 08:17:11.43ID:9eWAW4Cd
どんな言語でもぐちゃぐちゃなら同じ、そしてコードは必ずぐちゃぐちゃになるもの。
だから定期的に業務要件がなくてもリファクタリングしないとだめ

しかし日本は委託請負でプログラム修正してるからそのコストを出さない。
だからどの言語を使っても同じ。

JAVAだってそろそろ問題になりつつあるだろ？
0104名刺は切らしておりまして
垢版 |
2019/08/13(火) 08:21:20.64ID:aXmfPjfC
言語の良しあしは別として
年寄りのＣＯＢＯＬ好きは異常w
ていうよりＣＯＢＯＬしか知らないと思う
オブジェクト指向言語とか言われたら
受け付けないんじゃないか？
0105名刺は切らしておりまして
垢版 |
2019/08/13(火) 08:32:42.07ID:mBJq8LCP
汎用機の方がセキュリティは高い気がする
0107名刺は切らしておりまして
垢版 |
2019/08/13(火) 09:05:30.93ID:EtjaRXra
コボルのソースコードをPythonやJavaScriptに翻訳するソフトを作れば良い
0108名刺は切らしておりまして
垢版 |
2019/08/13(火) 09:10:28.18ID:XljiZakd
>107

COBOLなら一行で済む命令文が、PythonやJavaScriptでは10行〜になるのでは、可読性が落ちて、かえって保守に手間がかかるよ。
0109名刺は切らしておりまして
垢版 |
2019/08/13(火) 09:12:05.26ID:IdwKWIDC
>>108
COBOLには関数って無いんだっけ？
0110名刺は切らしておりまして
垢版 |
2019/08/13(火) 09:14:42.38ID:XljiZakd
>>95

メインフレームは漢字コードの管理が大変。
データベースにはSI/SOが入って無くて、APP側で追加する（漢字コード領域の前後にあらかじめ初期値として入れておくので、処理としても書かれてないとか）とか普通にあるので、単にデータコンバートするだけでは、全然だめ。
0111名刺は切らしておりまして
垢版 |
2019/08/13(火) 09:18:17.46ID:XljiZakd
>>108

組み込み関数は　COBOL85から
ユーザー定義関数は　COBOL2002から

それ以前は戻り値領域を定義して、PERFORMで処理を呼ぶとかする
0112名刺は切らしておりまして
垢版 |
2019/08/13(火) 09:19:47.86ID:XljiZakd
>>81

金融系は、プログラムにかぎらず、ガチガチの手順です。
0114名刺は切らしておりまして
垢版 |
2019/08/13(火) 09:35:25.90ID:tknqEYya
>>81
って、>>1の問いかけを象徴してるな。
手間をかけて責任の所在を残してるだけで一切の合理性が無い
0115名刺は切らしておりまして
垢版 |
2019/08/13(火) 09:42:38.68ID:XljiZakd
>>114

　金融系は扱っている金額が金額だけに、責任の所在を明確にしないとねえ
0116名刺は切らしておりまして
垢版 |
2019/08/13(火) 09:43:48.02ID:XljiZakd
>>113

事務処理計算を大量にこなすバッチ処理では、COBOL悪くないよ。
最も適している。
そのために設計された言語だし。
0118名刺は切らしておりまして
垢版 |
2019/08/13(火) 09:51:23.33ID:XljiZakd
>>117

　ソースコードが読めても、金融系の業務フローを知ってないとなあ。
　
0119名刺は切らしておりまして
垢版 |
2019/08/13(火) 09:57:16.74ID:IdwKWIDC
>>116
60年前に設計されたものを「最も適している」と評価するあたりがCOBOL業界の問題なんでしょうねぇ
0120名刺は切らしておりまして
垢版 |
2019/08/13(火) 10:08:51.55ID:8VaoAJWG
うちはUNIX-COBOLで継続や
0121名刺は切らしておりまして
垢版 |
2019/08/13(火) 10:25:19.85ID:pgZrim7S
>>81
他の言語に変えたところで同じだなｗ
0122名刺は切らしておりまして
垢版 |
2019/08/13(火) 10:28:51.38ID:WLlOnYPx
>>12
> 必要なのは言語のコンバートじゃなく、業務の整理・単純化なんだけどね

これだよね
0123名刺は切らしておりまして
垢版 |
2019/08/13(火) 10:29:37.37ID:wqh3p+gr
>>69
ソフト系のその甘えた思想嫌い
機械なら死人出るわ
0124名刺は切らしておりまして
垢版 |
2019/08/13(火) 10:31:16.23ID:IdwKWIDC
>>81
すげー雑な管理だな
0125名刺は切らしておりまして
垢版 |
2019/08/13(火) 10:47:46.45ID:+pQ1Uj0F
>>11
他になにがあるの？教えてw
0126名刺は切らしておりまして
垢版 |
2019/08/13(火) 10:48:10.81ID:Y6RrpnMN
この際、ＦＯＲＴＲＡＮはどうでっか？
0127名刺は切らしておりまして
垢版 |
2019/08/13(火) 10:51:48.86ID:XyCQzFkh
COBOL++ とか COBOL# とか作ればよくね？
0128名刺は切らしておりまして
垢版 |
2019/08/13(火) 11:27:13.78ID:WLlOnYPx
>>123
じゃあ、ちゃんとテストの時間と人と金を出せよ
0129名刺は切らしておりまして
垢版 |
2019/08/13(火) 12:09:28.31ID:uCPRrDs+
ソフトはテストがすべて

外観がないからわかりにくい
だからテストだけが唯一の手がかり
0130名刺は切らしておりまして
垢版 |
2019/08/13(火) 12:12:16.75ID:XljiZakd
>>127

　COBOL85で構造化とか、自由書式を取り入れている

　COBOL2002 でオブジェクト指向も取り入れたので、今のCOBOL仕様は
かなり進化している。
0132名刺は切らしておりまして
垢版 |
2019/08/13(火) 12:22:05.21ID:XljiZakd
>>119

　帳票処理って、帳票１の項目Aを、帳票2の項目Bに転記する　とかの繰り返しだから、
COBOLでそいういうコーディング書くのとても楽。
　COBOLは帳票ベースの会計処理とかに最適化されてて、戸籍台帳の台帳処理とか、銀行の台帳処理とか
はやり方がほとんど変わらない。
　税法とかの法律が変更されるにつれ細かい条件判断は増えていくけど、帳票処理自体は変わらんし。

　京都市みたいに住民数が120万人で、住民基本台帳のマスタ更新と、税計算と、各種公的保険の請求・控除処理を
一晩でやり遂げて翌日は新マスタで窓口処理を開始するような大規模バッチはCOBOLが一番いいよ。
0133名刺は切らしておりまして
垢版 |
2019/08/13(火) 12:24:44.61ID:XljiZakd
>>125

ファンクションポイント法とかあるけど、最終的に予算化するときには、人月にしないと予算化できない。
0134名刺は切らしておりまして
垢版 |
2019/08/13(火) 12:26:36.74ID:IdwKWIDC
>>132
>　帳票処理って、帳票１の項目Aを、帳票2の項目Bに転記する　とかの繰り返しだから、
>COBOLでそいういうコーディング書くのとても楽。
大体どの言語で書いても
copy B, A
とか
B(A)
みたいな感じになるのでそう変わらんと思うけど。
0135名刺は切らしておりまして
垢版 |
2019/08/13(火) 12:29:29.46ID:XljiZakd
>>131

パンチカードがまづ先にあって、機械式の会計機械で処理していたのを、電子的に処理するためにメインフレームが開発されたからね。
　
0136名刺は切らしておりまして
垢版 |
2019/08/13(火) 12:29:39.08ID:pWSVfgR7
>>138
その程度なら、フレームワークによってはコーディングレスかもよ
0137名刺は切らしておりまして
垢版 |
2019/08/13(火) 12:31:21.66ID:vbbeZCPK
>>132
その様な業務なら、今だとデータベース使う事になりそう
バッチにもむいているし、オンラインでの更新もあっという間
0138名刺は切らしておりまして
垢版 |
2019/08/13(火) 12:38:14.05ID:XljiZakd
>>137

　誤解しているようだけど、COBOLのバッチってデータベース使うんだよ。
　IBMならDB2とか、IMDBとか。

　昔はSAMとかを入出力ファイルとして使っていたけど、いまはデータベース。
　他のシステムとSAM経由でやり取りしなきゃいけないときは別。

　オンライン業務とバッチ業務は別だよ。
　
0139名刺は切らしておりまして
垢版 |
2019/08/13(火) 12:42:29.11ID:XljiZakd
>>134

　COBOLって、構造体のメンバーごとのCOPYとかしなくて済むし、
小数点の位置をいちいち考えなくていいし、構造体の構成が
異なっていてもちゃんと割り振ってくれたりする。
　親->子->孫と多段の修飾を指定するも必要ないし。
0140名刺は切らしておりまして
垢版 |
2019/08/13(火) 12:44:27.39ID:vbbeZCPK
>>138
そうなのか
今でも有編成ファイル扱うものだと思ってた
バッチって言う場合、処理量をある程度まとめた上で
リアルタイムではなく処理を行うものと理解してたけど
0141名刺は切らしておりまして
垢版 |
2019/08/13(火) 12:45:28.07ID:IdwKWIDC
プログラマーがそういうの意識する言語のほうが稀では
0142名刺は切らしておりまして
垢版 |
2019/08/13(火) 12:45:58.47ID:XljiZakd
>>136

　そのフレームワークが今から50年前にあったら、そうだろうけど。
　今フレームワークを使おうとするのなら、現在のシステムを０から作り直すということになるから、
それは現実的ではないな。
　西暦＜＞和暦　の変換をJavaならライブラリ使って簡単にできるけど、そのためにシステムを０から構築しなおすかという問題。
0143名刺は切らしておりまして
垢版 |
2019/08/13(火) 12:47:31.01ID:XyCQzFkh
>>130 そうなんだ。
じゃあ、.NET で使えそうだな。
0144名刺は切らしておりまして
垢版 |
2019/08/13(火) 12:52:23.27ID:SoD1ranR
マイクロソフトはVisualCOBOL.NETを出してくれや！(*ﾉω・*)ﾃﾍ
0146名刺は切らしておりまして
垢版 |
2019/08/13(火) 12:55:57.00ID:7e17kuqa
PythonやGoなどの新しい言語はバグやセキュリティに不安がある。だから基幹システムは枯れたCOBOLでやる、とかそういう理由なのかね。
保守的というか、システムを一度作ったらおしまいとか思ってるからそういう発想になるんじゃないか？
時代錯誤だよなあ。これだから日本のソフトウェア産業は未だに低レベルなんだな。
0147名刺は切らしておりまして
垢版 |
2019/08/13(火) 13:00:29.63ID:XljiZakd
>>146

　世界規模でみると、COBOLのソースは増えているよ。
　PythonやGoは基幹システムの要件からすると、オーバースペックだし。
　
0148名刺は切らしておりまして
垢版 |
2019/08/13(火) 13:03:37.57ID:XljiZakd
>>140

バッチ処理って、処理の区切りは日次、週次、月次、年次だから。
0149名刺は切らしておりまして
垢版 |
2019/08/13(火) 13:12:21.16ID:vbbeZCPK
>>148
オンラインショップの中だと、分単位で動くバッチがあるように見える
それがCobolかどうかは分からないけど
0151名刺は切らしておりまして
垢版 |
2019/08/13(火) 13:25:10.47ID:XljiZakd
>>149

　それはたぶん、普通のトランザクション処理だと思う。

　IBMのメインフレームだと、小さいバッチジョブを頻繁に動かすCICSというトランザクションシステムがあって、
バッチだけど一見オンラン処理をしているように見せかけていた。

　AJAX見たときに、「あ、CICSに先祖返りした」と思ってしまった。
0153名刺は切らしておりまして
垢版 |
2019/08/13(火) 13:38:15.95ID:A+7djq6o
>>21
オブジェクト志向が壮大な失敗と言われているの知らないの
ポインターも分からないプログラマにCでアプリを書かせてメモリエラーの山になったりクラスが作れない設計者にC++で設計させてどこを修正して良いか分からない状態にして日本だけでもIT産業衰退要因になっている
0155名刺は切らしておりまして
垢版 |
2019/08/13(火) 14:05:14.11ID:xHmPvLs+
>>124
そんな雑な管理じゃ、億単位の誤魔化しやっても責任不明で、
最悪は金融庁から行政処分食らうな
0156名刺は切らしておりまして
垢版 |
2019/08/13(火) 14:11:30.25ID:xHmPvLs+
>>148
今は、集計処理とかで、何時間かの間隔で自動起動させるのがあるよ
0157名刺は切らしておりまして
垢版 |
2019/08/13(火) 15:05:05.63ID:wnz1f4Fp
俺もCOBOLerだけど俺のポリシーはIF文は極力使わない
IF使うところはEVALUATE使ってた
0158名刺は切らしておりまして
垢版 |
2019/08/13(火) 15:08:32.62ID:wnz1f4Fp
>>138
何デタラメでどや顔してんねんw
別にデータベースとは限らんわアホが
0159名刺は切らしておりまして
垢版 |
2019/08/13(火) 15:16:14.88ID:OyxuABph
【IT】Flashに罪はない　トップ自ら情報戦略を
0160名刺は切らしておりまして
垢版 |
2019/08/13(火) 15:22:44.74ID:xHmPvLs+
EVALUATE　って、多くの言語では、CASE文ね
0163名刺は切らしておりまして
垢版 |
2019/08/13(火) 18:24:06.23ID:trV88SKN
今のCOBOLは、言語仕様上はオブジェクト指向言語であり、
各コンパイラにも大昔に実装されている
（でも、使われていない）
　↑
これを知らないカキコ多し
0164名刺は切らしておりまして
垢版 |
2019/08/13(火) 18:52:41.32ID:DE9n6UKA
>>132
ようは使い道なんだよな

銀行のように大元の勘定系のような基幹部分周辺だけCOBOLで書いて
エンドユーザに送るデータはサーバへ送ってJAVAで書くとかした方が良い
0166名刺は切らしておりまして
垢版 |
2019/08/13(火) 20:45:54.95ID:XljiZakd
>>164

　そうそう。
　COBOLは大規模計算バッチとかとかの基幹系が得意なんだから、
フロントが得意なJavaとか.netとかと棲み分けしたら良いんだよ。

　世界的にCOBOLのソースコード量がいまだに増えているのは、企業の基幹系はCOBOLが
必要だからだろうね。

　アメリカのCOBOLプログラマの平均所得は年6万ドルらしい。
0167名刺は切らしておりまして
垢版 |
2019/08/13(火) 20:52:08.78ID:gCirOaFy
でも国家試験から外されたよなCOBOL
つまりそういうことだ
0168名刺は切らしておりまして
垢版 |
2019/08/13(火) 21:13:39.13ID:+atLxHXg
COBOLって帳票を転写するための言語でしょ？
ぶっちゃけawkとかで代用できるよね
そしたらあとは速度だろうけどその辺はどうなの？
0169名刺は切らしておりまして
垢版 |
2019/08/13(火) 21:43:59.39ID:V0Jf0Nc8
こういう文系の記事をよむ度に思うのだけど、COBOLを潰せば日経が言う
「でじたるとらんすふぉーめーしょん」が進むの？


現状でもCOBOLが生きてるのは基幹系の奥底だけで、フロント周りはWEBだし、
メインフレームが持ってるDBデータはDB2だのSQL Serverだのにエクスポートされて
BIツールやら系絵分析システムやらが利用しているわけで

経理・人事なんかの経営管理系システムはそもそもメインフレームから切り離されて
パッケージ使ってるしな

むしろ刷新が進まずに現場が困ってるのはすっげー昔に組まれたUNIXシステムだったりする事の方が
多いんじゃないかと思うんだけど
0170名刺は切らしておりまして
垢版 |
2019/08/13(火) 21:56:39.62ID:V0Jf0Nc8
>>163
基本的に現場で使えるのはCOBOL85レベルだからな
コンパイラの設定からして旧バージョン指定だから拡張された機能は使えない事が多いし
そもそも、そういうニーズがあんまりない

というか、昔からビジネスロジックに抽象化とかOOPって要るのってのは、Java界隈でも言われていたような
気がするんだよなぁ（「美しいコードってめっちゃエロい！」みたいな人は置いておくとして）

一時期デザパタとか凝りまくったXMLが流行ったけど、最近流行りのPythonとかだとデザパタって何？みたいな
人も居るし、XMLもJSONにシェアをがっつり取られつつあるわけで

>>165
社内文書電子化システムが用意されても、今だに紙の文書を押印して社内便リレーするのをやめないジジイと、
それらのジジイに育てられた低脳社員の方が「でじたるとらんすふぉーめーしょん（笑）」とやらの敵だと思うわ
0171名刺は切らしておりまして
垢版 |
2019/08/13(火) 22:42:52.89ID:XljiZakd
>>168

awkはインタプリタだから遅いし、そもそもトランザクション処理できない。
0172名刺は切らしておりまして
垢版 |
2019/08/13(火) 22:50:02.65ID:XljiZakd
>>169

いまや、Salesforceでオンラインシステム組んでいる官民も多いし、日経の言うデジタル化って意味が分からん。
0173名刺は切らしておりまして
垢版 |
2019/08/13(火) 23:06:41.82ID:V8D+WT1W
AWS LambdaでCOBOLいけるっぽいから、Lambdaじゃきついバッチだけ置き換えて、COBOLで組まれたシステム続行じゃないのか？
そもそも官公庁すらパッケージ入れたり、クラウド使ったり、SaaSサービス入れたりしてる時代で、COBOL使ったレガシーシステム排除したからって大きく変わるのか？

某人事パッケージが市場寡占一歩手前になるようなユーザーの状態を先にどうにかしないといけないと思うが
0175名刺は切らしておりまして
垢版 |
2019/08/13(火) 23:15:23.70ID:vbbeZCPK
>>171
トランザクションにしたければ裏でDB動かせばいいし
ファイル操作の速度で言えば、インタプリタだろうと関係無いと思う
0176名刺は切らしておりまして
垢版 |
2019/08/13(火) 23:26:01.20ID:Y1ITNsI+
>>170
デザパタはフレームワークが隠蔽して、アプリケーションプログラマはあまり意識しなくて良くなったかな。
いずれにせよ、既存フレームワークの上に案件独自の業務フレームワーク組む時などには有用。

抽象化とかOOPとか要らないと言ってる現場って、業務要件がソースコードにベタって書き下されてるだけで、
そこに開発コストの削減などの観点は入ってないんだろうと推測する。さすが金持ちだと思うけれども。
0177○
垢版 |
2019/08/14(水) 01:17:07.39ID:SGGV5r1+
>>59

　PCサーバは原則5年で保守打ち切り。
　長くて7年。
　しかも延長保守料が高くつく。
0179名刺は切らしておりまして
垢版 |
2019/08/14(水) 02:56:08.86ID:cz2FEGqj
>>65
そうですね。
言語開発者の意図をプログラマーが理解していないからねー。
算術演算だけの文系プログラマーは、論理が分かっていなよ。
0181名刺は切らしておりまして
垢版 |
2019/08/14(水) 03:15:22.94ID:jro/G6Xs
実際経理やＤＢには向いてるんだよね。
書いたやつが居なくなっても他人が容易に保守できる。
0183名刺は切らしておりまして
垢版 |
2019/08/14(水) 08:18:53.48ID:STSPDk9O
>>175

　awkで120万人分の住民登録台帳を1晩で更新できる？
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況