【IT】NTTデータ、COBOLをJavaに変換してシステム基盤を集約するサービスを開始
■ このスレッドは過去ログ倉庫に格納されています
NTTデータは2018年10月11日、COBOLをJavaに変換することによって、システム基盤を1つに集約したりクラウドに移行したりするサービスを提供すると発表した。NTTデータは、COBOLをJavaに移行できるサービス「VENUS（ビーナス）」を提供しているジェイ・クリエイションと、同日付けで協業を開始した。販売目標は、2020年度末までに50億円。
NTTデータは、COBOLをJavaに変換することによって、システム基盤を1つに集約したりクラウドに移行したりするサービスを提供する。要素技術として、NTTデータが提供するJavaアプリケーションフレームワーク「TERASOLUNA（テラソルナ）フレームワーク」と、ジェイ・クリエイションのマイグレーションサービス「VENUS（ビーナス）」を組み合わせた。
TERASOLUNAは、NTTデータが自社のシステム構築サービスで社内利用している、Javaアプリケーションサーバーのフレームワーク（ソフトウェア開発部品）である。オープンソース（OSS）の各種Javaフレームワークのほか、NTTデータが独自に開発したフレームワークも含んでいる。これを使うことで、JavaによるWebアプリケーションを効率よく構築できるとしている。
ジェイ・クリエイションが提供するVENUSは、COBOLからJavaへの変換など、各種の開発言語同士の変換や、異なるデータベース管理システム同士の変換、JCL（ジョブ制御言語）やメインフレームのユーティリティソフトを含めてシステム全体をマイグレーションするサービスである。
今回、NTTデータは、TERASOLUNAとVENUSを組み合わせて、ユーザー企業のCOBOLアプリケーションをJava環境にマイグレーションするサービスをメニュー化した。COBOLとJavaが混在する既存システムの基盤を1つに集約できるようになる。クラウド上でJavaアプリケーションを動作させることで、クラウドへの移行もできる。アプリケーションの再構築（リファクタリング）も手がける。
https://it.impressbm.co.jp/articles/-/16822 COBOLのスパゲッティーをJavaのオブジェクト指向チーズスパゲティーに変換し
もう誰も手を付けられなくするシステムか胸熱だな またすごいものに金かけてるな...
バッドノウハウにバッドノウハウを積み重ねる違法建築感がすごい 何十年後かには、このCOBOLから変換されたJavaを何に変換するんやろなぁ ,;:⌒:;,
8(･ω･)8 これはいいことだね
ソースコードもリーバースエンジニアリングで解析されて
設計仕様書も全部コンピュータが作ってくれるんだろうし
過去のブラックボックスを刷新できる ＮＴＴって昔からこういうの好きだよな
日本語ＰＬＩとかいうのがあって、日本語で入力するとプログラミング
されるとかいうのがあった マシンパワーごり押しすればとりあえず動くんだろうけど
次の再変換の時は新規で作り直した方がいろいろ早いと予想 今のところうちはバッチはCOBOLオンラインはJava オラクルがJavaを有償化した直後だというのに
先見の明が皆無だな >>11
データベースと繋ぐなら一番Javaが楽だから
Pythonなんて過大評価で業務システムには使いづらい ２０００年問題でシステムを構築し直すときに
急遽COBOLでプログラムを組んでいた年配の人たちが
引っ張りだこになったことがあったわな
もちろん用が済んだら即刻解雇になったわけだが、
首を切る手間も省くためにそこまでやるかというツッコミだけはしておく ■
えぇ？
今まで 無かったのぉ？？・・・・・・・・・・・・事務系システムって ずっと コボル？
自動変換の効率が
相当 上がったとかぁ？
まぁ
早くしないと 元号変わるし、・・・・・・・・・・・・・・・・・・・・・
Javaそのものが メジャー変更したけど 大丈夫？ なにそれ魔法みたい
NTTてネタみたいなことするんだな ■
NTT側が Springフレームワークだろ
別の企業が DBやJCLかぁ
なんかぁ
ご愁傷様、
何ですけど。 >>6
こういうのは、変換後のシステムの保守契約で
稼ぐのか王道 ・
システムの画面よりは Javaで NTTのSpringフレームワークで
システムの後ろの方は 単に アダプタを取り付けて コボルと共存？ するんじゃぁ？
自社オリジナルなデータに近い部分は 温存して アダプタ？ってこと？
いやぁ
かなり
大変な
マイグレーションだなぁ。 ほんと、そっち系の人はJavaすきだよなｗ
つまり、Javaを勉強すると、必然的にそっち系の仕事になっちゃう
まあAndroid Javaというのもあるが・・・ ・
まぁ
NTTは儲かるだろ、たぶん。
ニーズ、ありそうだし。
廃れた 技術者、活用できるし。 ・
■
逆に
自動変換されたコードの方が やりやすい 鴨。
返還後のコードのくせ
が
熟知できてれば 請け負った会社は なんとかぁ なる。
それで
動かなければ
さらに アダプタ 噛ませて、ラップを重ねれば いいだけ、だし。
ラップに
ラップ・・・・・・・・・・・・・
さらに
重ねて・・・・・・・・・・・・オリジナルは バックアップ取って しまっておける。 まさか変換後はupper snake caseのJavaかいな？ なかなか難易度が高そうなことやってるね
そんなに技術力あるのか COBOLで作った古いシステムのソース見たことあるけど
言語がどうのこうのではなく、基本はファイル転がし
JAVAに変換しても、システムの非効率なところは全く変わらないと思う COBOLは良く知らんが、コメントとかボロボロになりそうだけど、大丈夫なのかな？ >>38
文系の言語かな
ファイル読んで一項目変更して別のファイルに書き出す
そういうプログラムをつなげて、デイリーとかマンスリーの処理ができていく 変換するメリットってなんだろうな、保守しやすくなるって事よね
理路整然としたクラス体系にして、綺麗なJavadocも生成してくれるのかしら エミュレーターをつくれば充分なような
もとのコードと
Java に変換したコードがあると
もともとの意図は何で
Java ではどう変換されていて
どう動いているのか
とか調べるのが大変そう
問題がおこったときに >>41
変換するメリットはもちろん、COBOLの糞みたいな動作環境を用意する必要が無くなることでしょ まだCOBOLのままにしといた方がダッラダラでも読み易いんじゃね Java 有料化とかあるからほかの言語に移ろうとか思っても
そのジャンルの言語ってあと C# ぐらいしかなさそう。
VM かましていて、いろいろな環境にもっていけるような類のもの
ネイティブならC/C++系で充分だろうし
スクリプト系なら Javascript でも Python でも Ruby でもいいんだろうけど >>46
業務系プログラマーでC言語をできる人が少ない >>36
俺も大昔にちらっとCOBOLソースみたことがあるけどなんか凄かった
コボラーがなぜグローバル変数ばかり使うのか
よくわかった あぁ、これで俺のCOBOLメンテの仕事も終わりか・・・。
定年までどうやって稼いでいこう。
50過ぎのおっさんに、他の言語を覚える気力はありません。 大型冷蔵庫みたいな汎用機が廃れて、コンパクトなラックマウントのオープン系のハードウエアに置き換わっていくのでしょうか？ >>51
本当にCOBOLだけなん？
１つしかないってやばいじゃん 変換で密かに作られるバグは厄介そうだな
発見されないまま運用開始
1年後とかに泣きを見そうｗ >>51
近いうちに70歳まで働ける時代が来るから、まだまだ若い
Web系なら頻繁にフレームワークの仕様も変わるし、複数言語が使えて当たり前
もっと勉強しろ こういう変換系マイグレーションはだれでも考え付くからいろいろある(あった)
しかし成功した事例を知らない
しかししかしもしも成功するなら世界を席巻できる さらにKotlinを介せばJavaとJava Scriptの相互変換が可能に…？ 使えない機能とかあんだろ
コボルなんて幕末の言語だし 変換前からある潜在バグが顕在化した時が、とても面倒そう 去年京都市が基幹系システムのCOBOLを刷新するのに失敗して訴訟になってたな 同じスパゲッティでも読める奴多いJavaの方がマシという事か？
自動変換で可読性も落ちると思うが >>44
COBOLの言語としての動作環境なんて大したことないぞ
昔、普通にあったCOBOLのバッチシステムの動作環境改善なら、
システム全体を、ファイル設計、ＤＢ設計を中心に、
再構築しないとどうにもならない
単に、プログラム・ソースをコンバートしても、
今の人に見慣れてる言語に変わるだけで、
プログラム・ソースのグダグダが解消される訳じゃない
そして、確実なのは実行速度が悪くなる事
COBOLは言語として原始的な分、実行効率は良いからね
あと、COBOLで組まれたシステムは、たいていアセンブラの
サブ・プログラムがついてる
これは、人手を掛けないとどうにもならない
そして、これもやれば遅くなる
>>45
自分もそう思う
COBOLなんて言語自体は大したこと無い
ときに複雑なのは、網の目のようなバッチシステム >>1
COBOLエンジニアが絶滅寸前でCOBOLで書いたシステムの維持が大変だからなあ。 今ちょうどそういう案件にかかわっているわけだが、、、
30年前のCOBOLのコードなんか見たくないのでどうにかしてくれ＞＜ ＞ジェイ・クリエイションが提供するVENUS
これ15年くらい前にはあって特許も持ってるぞ
NTTが窓口になるから利益も分けてねって話 > 販売目標は、2020年度末までに50億円。
１行１００円ぐらい取るのかな？ N-88BASIC、C、COBOLなら現場を離れてか久しいが、組みながら思い出すかもしれない。
がしかし、独り言と共に胃痛がひどくなり食欲がなくなるという流れになる。
務まらんね、残念だけど。 これ、実行環境をJava仮想マシンにできるのがメリットなだけで、メンテナンスはオリジナルのＣＯＢＯＬのコードでやるんじゃないの？
専門家じゃないからよくわからんけど、機械が自動的に吐き出した読みにくいＪａｖａのコードを人間が手作業で改変なんて非効率的じゃない？ テラソルナ懐かしいな、4ヶ月間だけいた案件で少しだけ携わったなぁ ベタCOBOLを整構造COBOL(構造化COBOL)に書き換えただけで
ベテランから「読めん、戻せ！」って指導される世界だからな
多分、gotoだらけのjavaという、おぞましいものを見ることになる >>67
大抵のCOBOLはメインフレームで動いているが、全く同じ環境を用意するのは難しいだろ >>59
マイグレも結局は「人」だよね。
しかも予定工数の倍～３倍は確実にかかる。
同じ工数なら、新設計で綺麗にスタートさせたいよね マジでJAVAが廃れるのがみえてきたのに！
Oracleが買収した後では遅すぎる
導入するには顧客を騙すしかないだろ？ マシンパワーも増強する必要があるな
年間の維持費は同じでコボラーが
不要になるだけだな 動くようにコンバートするだけなら、対応するスタティックメソッドを呼ぶだけだが、なにがすごいんだ？ コボラーは本格的に新規要員のアサインが難しくなってきてる
内製化するか、マイグレか、塩漬けか >>2
バッグのメインフレームでどこでも使われてるやろ ちゃんと動くんならなんでもいい
メンテは簡単にして >>79-80
ソースメンテするのに、要員確保が楽になるだけで、
メンテ作業自体は負荷が大きくなる
自前でメンテ出来てないところに、
要員確保が楽－＞コスト削減と勘違いさせるのが
ＮＴＴの売り込みポイントかと COBOLは昔の商業科で教えてたんだよな
FORTRANが工業系の学校で >>90
COBOLerの改修速度、めっちゃ遅いぞ
とても楽に見えない >>5
彡⌒ ヾ
( ＾ω＾)言語を自動で書き換えるとか言ってんのかねぇ？ COBOLの資産をJAVAに変換する意味あるか？
COBOLのままのほうがわかりやすくていいだろ
クラウド？COBOLで作ったものにそんなのいらんよ COBOL→Javaの自動コンバートツールって、
知ってる限り15年以上前からある
導入して成功した例は聞いたことがない
以前いた会社でもそんなツールを作る案件が来たが、
俺からは「きっぱり断った方がいい」と断言しておいた COBOLコンパイラのオブジェクトコードをJavaにするのなら、
少しは意義が見いだせるんだけどね てか、Ｊａｖａをやらせてよ
クラス設計とかは怪しいけど
コードくらいは書けると思うんだよね
Ｊａｖａ要員が多いのか
なかなか、ＣＯＢＯＬから抜けられない
まぁ、フロントの方は苦手意識があるけどさ まあ、COBOLプログラムの設計思想自体がゴミであることは間違いない
>>99
Java自体の習得はたいしたことない
重要なのはJavaScriptとCSS ジェイクリエイションのVENUSは実績たくさんあるぞ。
直近だと楽天カードの古いシステムをマイグレーションした。 >>93
言語がアセンブラに近く、今の言語感覚だと、
関数がほんど無いに近いので、
ユーザ・システムが用意したサブ・プログラムを使うか、
自分で組むしかない
改修するのでも、それらを読み解く必要があり一手間は掛かる
JAVAにコンバートしても、それらを関数に変えるのは無理と思われ、
ソースの面倒さは、COBOLのままと大差ない
その辺の理解無しに、COBOLじゃなくJAVAだから楽なんて思ったら、
大変な目に遭う
あと、デバッガーもあるけれど、言語に標準でついてない
貧乏ユーザーだと、その辺でも作業効率が落ちる >>104
その業務ロジックまるごと、ポイ捨てで良い というか、いっそJVM上で動くJCOBOLみたいなのを開発して、その上でリファクタリングしていく方が楽だったりしないか？ >> 100
スクリプト系か、最近は、そうらしいね
キャストと入力チェックばかりの力作業で
つまらないイメージしかないけどさ まあ言語を書き換えることに意味が無いわけではないが...
単にJavaで書きましたみたいなくそコード量産するだけなんだろうなあ。
オブジェクト指向の美味しいところ全く使えず単なる機械的に置き換えたコードに過ぎないのだから、
保守のコストは高止まりな気がしてならない。 javaってあの右下に常にアップデート促すアイコンが出て
どうやらそれで組んだと思われるアプリケーションだと
何か押すたびに１テンポ遅れる、歯がゆい言語？ コンバートサービス使うと、コーディングが「COBOLライクなJava」になっちゃうところが難点 >>109
あれはJavaアプレットを動かすために必要なもの
最新のJavaには含まれないし、もうすぐパソコンにインストールする必要は無くなる COBOLとjava
両方使いこなせる人は
世の中に存在しません >>95
COBOLとJAVA、両方出来る人なら、
コンバートしたJAVAより、元のCOBOLの方が良いでしょうね
でも、改修、メンテに必要なCOBOLerを確保できない所がある
というか、自前で改修できないと、
COBOLのままだと、ほぼ外注不可
>>100
COBOLの前は、アセンブラだったので大変な進歩
それでも、前の時代の人には、COBOLは遅いと叩かれてた
COBOLが主役の時代には、
マシンも非力で今の言語じゃ遅くて使えない
ソース修正するのも、端末がなくて、
紙テープやパンチカード使ってた時代にできた言語だよ 中身を解読したうえで一から書き上げるのならいいけど、
まさか機械的に変換するだけで金取るわけじゃないよな？ 実体は Java で書かれて JVM 上で動く COBOL インタープリタだった
あるいは
実体は Java で書かれて JVM 上で動く
COBOL Virtual Machine だった
とか？ 元号対応でコボラー最後の稼ぎ時なのに
余計なことするな！！ こんなのビジネスになるの？
COBOL使っている企業は殆どないけど、あるところは
COBOLのシステム動かしながら、並行してオープン系やクラウドに同じ要件のシステムを再設計して
そのシステムが問題なく動作確認が終われば移行してCOBOLのシステムを廃止だぞ
変換なんてバグでまくりだぞ。ハードも持たないし
xp使っているPCをそのまま7にアップデートして、そこから10にアップデートするようなもんだぞ
ハードもソフトももたないし、汚ねえごみファイルがいっぱい残るぞ Javaってまだメインなの？
日本だけでしょ。（笑） >>117
国税システムもJavaだし。
何故、日本でこんなに使われてるのか理解出来ない。 これ単純翻訳されるだけで
出来上がったコードはCOBOL設計思想全開な、悍ましいコードだぞ
Javaみたいな（こいつも20年ものだが）COBOLよかマシな設計思想にはならない 変換されたソースをまともに読める人がいないというおまけつきやろ？ COBOLは死なず、ただ消え去るのみ．．．ってことか そもそもクラス分けされてないものを
クラス分けするようなことは難しいだろうしな
ひとつのソースコードをひとつのクラスにする
みたいな単純な処理ならともかく ソースを分析して開発しなおすのと変換とどちらが効率よいのか・・・
分析後に開発効率を向上させる為のツールとしてはいけそうだな 金融系の基幹システムでしぶとく生き残ってたコボラーもとうとう解雇されちゃうの？ >>128
業務仕様を網羅把握してるのは強味だから業務系への流れだろうな この手のマイグレーションサービスってもう20年くらいいろんなベンダーが出してるけど、まだニーズあるのかね？
金融系ユー子だけど、誰も今のメインフレーム基盤をマイグレーションできるなんて思ってないし、
損保系最大手のSJNKなんかは要件定義から新規にやり直してJAVAベースの新基盤を作る道を選んだけど >>124
うはｗ
詳しくは知らんけど、全部記号のシステムっしょ？
テーブルがT001で、モジュール名がM001で、変数名がV001みたいな奴 >>121
周回遅れだからでしょ・・・
安価間違えた >>121
海外も大規模基盤系はJavaだけどね
なんだかんだ言ってもサポート基盤がしっかりしているのと、人員調達が楽だから
つか、大規模基盤系に耐える言語ってJavaかC#くらいじゃないのって気がするけど他にあったっけ？
LL系言語とか？() >>133
データ中心アプローチで設計されて、コード上にシノニムを発生させないという目的で使われているのは見たことあるな
アプローチとしては面白いと思った
まあ、実体は採番するのが面倒って理由からか、ワーク領域用に開発者が任意で使っていいコードエリアを使って
エンティティの重要な項目を格納したり、ルール知らない馬鹿が作ってコードが無茶苦茶だったり、
コード辞書にないコードを勝手に使ってたりと、カオスな事になってたがｗ >>138
なんだかんだ言ってもMS基盤は運用面での利便性の面で強いからね
小規模ならともかく、大規模基盤になると基盤チームがMSに頼りたくなる気持ちは分からないでもない >>140
確か、.netはNUMA未対応だったような。
そんな基板で大規模って成り立つんやろか？ >>141
Azureとかやってるし、ちゃんとしたエンジニアが組めば成り立つんじゃないの？
まあ、うちはフロントエンドがメインだけど
それでも結構な規模はあると聞くよ 変換したJavaの実行結果がCOBOLのものと差異が無いかは、別途テストの料金がウン億円掛かります。
とかだろ。 どうせある程度までしか自動で変換できないんだろ
ちょっとは人の手が入ります、からの泥沼が見える 京都市はこれで失敗した
変換しないでシステムを再構築しろ COBOL から変換された Java を保守させられる IT 土方は悲惨ｗｗ なんか頓挫しそう
やっぱCOBOL書ける人を育てようってことで この手のものは平成初期から各社
だしていたが、古いコンピュータ雑誌
があるので、それの広告に載っているｗ 銀行と同じくソースコードまで大きすぎて潰せないCOBOL COBOL→Javaマイグレーションしたあと、一旦はソースに手を加えず運用
徐々にJavaで一から再設計・再実装かな
本当はKotolinにしたほうがいいと思うけど、COBOL使っていた保守的なところからからしたら荷は重いだろう COBOLのデータからデータベースに変化するのが難しいと思う(・ω・｀)
テーブル処理とか再定義とかcomp-3とか漢字とか >>152
そんなカネにもならないプログラマーのオナニーできるところなんてほとんど無いだろ 素人目線だと顧客情報のデータベースさえ新しい環境で使えればいいだけだから
データベース出力しさえすればいいような >>4
ホントそう。
触らぬ神にたたりなし。
分散クラウド？同期？だいじょうぶ？ >>115
>中身を解読したうえで一から書き上げるのならいいけど
それを指示できるのは総理大臣だけ >>155
リファクタに注力しているところならある そういや昔はアセンブラをCにコンバートした変態が日本にいたらしいね >>57
web系は勉強が必要な割に50歳までやるやつは居ないって話も聞くし難儀よな >>112
デスクトップ向けjavaアプリ……
もう実質全滅寸前だからノーカンでいいか >>163
Javaのデスクトップ向けアプリはeclipseがまだまだ現役 >>4
素人が組んだＣＯＢＯＬの前ＧＯＴＯはホント厄介で同じこと思った。
例えとしては元のスパゲッティを握りかためてほぐせなくする変換で
もうこれはメンテ出来なくなるね。
改修案件でなく新規案件を獲得したいのが狙いなんじゃないか。 >>164
jreの話をしてるので…
IDEのレスをされても困っちゃう >>161
コンパイル後のアセンブラソースからさらに
リンケージ後のマシン語のダンプを見て机上でバグを探してましたよ。
ＡＩで直にマシン語を組ませればプログラミング言語いらなくなるね。 >>161
アセンブラからC言語はないけど、C言語からアセンブラならあるな。 アルゴリズムをCで書いて、
コンパイラでアセンブラのソースを出力させてマニュアルで最適化。
最近はやってないけど、コードサイズ優先のオプション付けてコンパイルした、Cの出力したアセンブラを
最適化すると、条件にもよるけど8086だとコードサイズが1/3くらいになる。 コードが小さくなれば、
実行速度も上がる。 新たに巨額の技術的負債を
大金貰って作り上げるビジネスか
上手いこと考えたもんだ。
NTTデータは50年後も安泰だ。 スパゲティを解くAIを開発したら逆にもう底辺マは要らなくなるな >>4
だね
作り直しじゃなくて単純に機械的に変換するだけなら、
二度と改修できない糞ブラックボックスになるな クソコードが更にクソ化するんか
VB6をVB.Netにコンバートしただけのクソコードを思い出すな… >>105
それが出来るところはとっくにそうしてる
今のご時世でCOBOL使ってるのって、金融や役所の中でも相当古い(≒今後も大きな変化を見込まない)部分だぞ 000010 IDENTIFICATION DIVISION.
000020 PROGRAM-ID. SAMPLE001.
000030 AUTHOR. T-YUSUKE.
000040 DATE-WRITTEN. 1998/3/10.
000050 DATE-COMPILED. 1998/3/10.
000060*
000070*
000080* 重要基幹システムをCOBOLから使える人間の多いjavaに変えると、
ハッキングされやすくなるんじゃないの？ >>175
最終的に全部マシン語に転換されるわけだから
これだけ言語増やすとかせずにVBでもアセンブラで組んだように
超最適化してくれりゃいいのに
コンパイラをAI化してほしいわ バグも100%忠実に再現してマイグレーションいたします。
金を出す発注側の立場からしたら、例えばCOBOLのエンジニアよりもJavaのエンジニアの方が安く
雇えて、保守費用が安くなるとか、そんなメリットもなく『開発言語がJavaに変わった以外、今と機能
的に何も変わらないシステムを組み直すだけなら、費用を掛けるメリットないよね』ってことが、SIerの
営業やエンジニアにはわからないのかねぇ？
SIerとかコンサルって看板だけで、実態は丸投げ屋だからなのか？ >>185
汎用機の専用Cobol言語から脱却できて、AWSどころか鼻毛サーバーで運用できますって話なら飛びつくかもよ
問題はバグを生み出さないとは言い切れないし、生成したコードが意味不明かもしれないところだろうな >>183
大丈夫、COBOLが直接通信することはない、というより出来ない
他の通信ソフトのサービス・コールするだけですよ >>51
これで変換しておかしくなった奴の修正のお仕事があると思うから
とりあえずJavaやっとけば？ｗ >>188
COBOLが直接通信しなくてもJavaがやれば出来るだろ >>183,191
セキュリティーホールが多いか否かの問題であって、その言語を使える人間の数とか割合は関係なくね？ とんでもない不具合ばかり起こって、かえって人間の仕事が増えるパターンか？ >>191
元のCOBOLソースがやってないことを、変換後のJavaがやる
それって、コンバーターのバグじゃね？ 30年位前だけど富士通のYAC/IIにはコボルソースから日本語の仕様書を自動作成するシステムが内包されてたような記憶が
モトローラーのMPUが載ったWSで動かしてたけど使い勝手はそれなりに良かった
Javaへのコンバートも自分が辞めた10年前には目処が付いてたけど提供できたのかな・・・ 変換して、その後をどう保守するかが難しい
素直にCOBOLをVMで動かした方が余計な不具合に悩まされることもなくて、
結果的に安上がりだと思うけど ぶれーねり、あなたっのっ おうちはっ どっこー？
あなーたのっ おうーちは すいーすらんどっよー
きれーいなっ みずーみのっ ほとーりなのっよー
やっーーーーーほーーーーーーー
フォートランランラン！やっほフォートーランランラン！
やっほフォートーランランラン、やっほほー！
だれか雇って！！！ >>169
最高齢７０ぐらいじゃない？
ぼくは６０だけど
２５の時に月１００万以下の仕事は請け負わなかったね。
そのくらい出来る奴がいなかった。 【消費増税１０％】 グルグルマン「離陸には時速300マイルが要るのに、200マイルに減速するアホ機長」
http://rosie.5ch.net/test/read.cgi/liveplus/1539569146/l50
２０年前の消費税増税と同じパターン、景気をデフレに戻して、株価だけインフレにする、株式主義政策！ cobolもソースを失くしたのが未だに動き続けてるんだって こういうのって元の仕様は決まってるんでしょ？
その仕様を元にシステム作り直すって
できないの？ 普通に考えて100%自動変換じゃないよね
仮に95%自動変換だとして残りの5%を手動変換するのにどのくらいの手間がかかるの >>18
仕組みを組むと言うだけであればpythonもjavaも変わらない
ただインタプリタなのでjavaのようにループ処理を書くとpythonはとにかく処理が遅い メンテナンスするときは、COBOLソースのほうを修正して、再変換するんですね？ 変換することに実質的な意味があると思っているなら、
その判断や発想自体に問題がある。 HITACHIに勤めてた頃にCOBOL85使ってた
社員の給与計算をするシステム
イントラネットから情報を入力する部分はHTML+C言語だったな
そのデータを流し込んでデータベース処理をするのがCOBOLだった >>1
ボトラーの負の遺産
おっとコボラーだったか 【消費増税１０％】 グルグルマン「離陸には時速300マイルが要るのに、200マイルに減速するアホ機長」
http://rosie.5ch.net/test/read.cgi/liveplus/1539569146/l50
２０年前の消費税増税と同じパターン、景気をデフレに戻して、株価だけインフレにする、株式主義政策！ コボルはいろんなところで使われてるの見てきたけど
フォートランは見たことなかったな
どこで使われてたんだろう？で、今どうなってるんだろう(´･ω･`)？ >>4
まさにこれ
機械的に生成されたコードとか絶対に誰も読みたがらない >>77
ってえか、JCL群を併せて把握しなきゃメインフレームのレガシーシステムなんて置き換えられんやんけ。
業界から逃げてはや20年だが、固定小数点十進演算という帳面世界の慣例を言語仕様で明確にしてるのって、IBMのアセンブラとCOBOL,PL/1以外に何が今有るの? >>216
最近の言語やデータベースだと、たいてい通貨（Currency）型というデータ型が定義されています。 Javaプロフェッショナルでもゲロ吐くくらいのソースができあがるんですねw >>133
うちも消費税が上がったときに解約したわ。
新聞解約したら毎年5万円のキャッシュバックがあると考えるとでかいよ。
知り合いもみんな解約してる。ニュースならスマホで見れるし。
いまじゃ月に1回、爪切り用に分厚いから日経新聞を買うぐらい（笑） >>4
自爆テロですねｗ
新たなサグラダ・ファミリア建設は大変そう >>184
今のCPUって昔の最適化されたマシン語だと逆に処理効率落ちるんでないの？w 運用どうこうで的はずれな事を言ってる人が多いところを見ると、システム計画作成とかの上流工程には携わったことのない
下流工程専門のコボちゃんが多いのかね？
マイグレーションなんてほとんどメンテの入らないサブシステムでやるものでしょ
昔売ってたマイナー商品のサブシステムとか、吸収合併前の旧会社向けのメインフレーム上で動いてるサブシステムとか
スパゲティ化するし当該サブシステムへの改訂はコストがかなり高くなるけど、ほとんどメンテ入らないから問題ない
人材面についてもCOBOLとJavaのどっちもできる人材なんてそんなに珍しくもないし >>213
今は知らないけど、素粒子物理業界では20年前にはFORTRANからC++に移行中だったな
メインフレームからワークステーションに移行するタイミングでついでに変わった感じ 素朴な疑問なんだけどCOBOLのままじゃ駄目なの？ >>226
>>1の目的はクラウドへ移行すること
COBOLのままじゃ、クラウド環境へ移行しにくいでしょ >>202
戦艦大和の設計書渡されても現代戦では何も役に立たないだろ? >>88
COBOLエミュレータで十分
IBMが出してた様な希ガス Javaのことをよくわからんでディスるやつがおおいな。
マイクロサービスとか基盤はJavaだらけやしな。
Netflixとかどんだけ使うてるかと。
あとサポートが有償化しても、NTT様とかくそ高いサポート現時点で払ってるわ。やすいプランでた分ましだわ。 >>228
例えがアホっぽくて的外れ
その戦艦大和のまま今も通用して使われてんだからなぁ >>231
たぶんレベルがベトナム戦争くらいで止まっているのに気づいていないだけだと思う
戦えてないんだよ >>226
バッチはそれでもいいけど、オンライントランザクションはJava化しないと面倒なんじゃね？ 今更javaにするメリットは無いだろ
java無料の時代ならまだしもなぁ このサービスいろんなSIerがやってるよね
NTTデータがまだやってないことにびっくり >>202
元の仕様が分かってるレベルのシステムはもうとっくの昔に作り直してるんじゃないかな
問題は仕様書が無い、仕様書はあるけどかなり古い時点からメンテされていない、
ジョブローテで人が異動するから業務を完全に知ってる人がユーザー部門にいない
っていうカオス状態の大規模基盤だけだと思うよ
SJNKなんかはスゲー大金かけて、その仕様書をもう一度作り直そうぜってやってる
（ついでにユーザー部門にシステムコストを意識して貰って、業務のスリム化と全体最適化を
狙っての取り組みらしいが） >>236
NTTデータなら今までも他の手段でマイグレソリューションを提供してたんじゃないの？
今回の発表の肝はNTTデータの自社ブランドのTERASOLUNAに載せましたよってことかと
フロントのシステム更新にあたりTERASOLUNAを売りたいけど、バックエンドがCOBOLなせいで
トータルソリューションで売れないみたいな案件が思いの外、日本には残っているのかもね >>167
eclipse自体がJavaで書かれてるって意味では NTT関連が総力あげてつくったのではなく、外部のものを使うだけか >>4
まだドカタを殺したりなくて
さらなるドカタの再生産をするんだな >>237
＞問題は仕様書が無い、仕様書はあるけどかなり古い時点からメンテされていない、
＞ジョブローテで人が異動するから業務を完全に知ってる人がユーザー部門にいない
なるほどそういうことね
継ぎ足し継ぎ足し代々受け継いだ秘伝のタレw ＨＩＴ－ＶＭとかFAC-VMとか作った方が早かったり これって でじたるとらんふぉーめーしょん のいっかんなの？ ほんとjava好きだよねー
ほとんどはスクリプト言語で十分過ぎる規模だろうに JAVAとかデータぶっこ抜かれる覚悟のあるイカレポンチが使うんだろ 同じようなサービスは、十年以上前から日本の大手がやってるだろ。
で、失敗する。 REDEFINESとかマルチレイアウト良くあるから、データのコンバート難しいだろうな 頭取が若いころ、社長が若いころに書いたのが問題になるｗ 設計が壮大な世代間の伝言ゲーム指向になており、全体を誰も理解できない。 完全内製でない限り、導入先の社員なんて、実質的な開発には携わっていないし、
ソフトウェアの知識もないだろうから、たとえ導入当時の古株が残っていても、
システム移行には役に立たないだろうな。
大手ベンダーが開発したシステムで、たとえソースが納品されていても、受け入れ
検査なんて形式だけで、納品物の再ビルドなんてやっていないし、そんな能力もない
から、ソース一式を渡されて調べたら、不完全とか、古いソースで、現行システムの
機能が含まれていないものだったりとかよくある。 ツウカ、ソースから設計書起こすだけでいいやん
そこから、改修改善した設計書作れば皆ハッピーなんでは？ >>258
仕様を変更するときは、COBOLで変更してJavaに変換する方が簡単！ >>260-261
一粒(案件)で二度おいしい。
そのココロは、人売り派遣と、丸投げの中抜き屋だけがハッピー♪ハッピー♪ FOTRANのように、いつまでもCOBOLが残る。 >>1
せめて100%の仕様書作ってからコンバートしろよな
無計画に変換して、
動かない部分だけパッチ当てるようにアドオンプログラムで
データ改竄してお茶濁すシステムをあちこちでやられると、
本当にどうしようもない代物になるぞ。 >>264
100%の仕様書が無い。適当な仕様書に管理者の口頭指示でプログラムが変えられることがたびたびあり、それが仕様書に反映されないまま20年が経ち、管理者も担当者も退職した。
そんなシステムを稼働させ続けるにはどうすれば良い？ おれも10年前の組み込みソフトとかハードを
アセンブラから解析して仕様書作成して
別のHDL言語で実装したことあるけど
資料が残ってないからまじで大変だったよ
俺が作った仕様書も結局は
仕様書と実装が違ったりしてるから次にもしも変えようとして
仕様書から別のものを作ろうとしたらバグで一生動かない
プログラムを解析して仕様書つくりなおさないとダメという
会社に対する忠誠心もないし失敗したら他人のせい成功したら自分の手柄にするような
うえのやつのためにわざわざ仕様書や設計資料の変更から大規模な設計修正を行って
コーディングしてと時間割いたりしないんです
おれの頭の中にしか本当の設計資料は残ってないｗ >>199
すげええええ！
プログラマーのイメージが覆るわ 今はなんちゃってプログラミングツールのせいで
糞も味噌もプログラムできちゃうからなぁ
土方報酬に下がって当たり前 最近、COBOL系の人と関わらんから知らんけど、
金融系の基幹システムで、COBOL,PL/I以外で稼動してるところなんかあるの？
ATMがJAVAとかそんなのじゃなくて。 素人考えだと別の言語でゼロから作る銀行が出てきても良さそうな気がする >>271
この二つ以外にPACKED-DECIMALをサポートしている言語ってありましたっけ？ 20年前の高校で情報処理学科だったけど
選択希望言語に既にCOBOLなんてなかったぞ コードは書くより読むほうが難しい、だから
ゼロから書く ← 簡単だが時間がかかる
書き加える ←普通
改変する ←クッソ難題、不具合続出の予感
javaはおばちゃんでも扱える環境なので
人件費削減につながる
システムの質は劇的に下がるが 20年まえに設計したMF COBOLのunixで動く機材の設計マニュアル
IBMではレッドブックというが、俺のやったHewlett-Packardでは紫だった
まだ保管してあるが
それによるとアセンブラなんかをドダイにCOBOLもJavaもその上で動くだけ
だからたいそうに見えてライブラリを都合する作業でしかないんじゃないの、これ >>265
うやむやの仕様で数字が本来の数字と変わっても良いならそのままいけば？
例えば生産計画やら資材購入なら構わんと思うが。
多少誤差があっても、社内にしか迷惑かからないだろ。
ただ、勘定系やらBtoB、BtoCで数量や金額が本来と違う結果になるような
システムならば、そりゃあ100%の仕様を作り直せという敷かないぞ。
特に、複雑な契約やら法的な特例で数字が変わるような
銀行系やら不動産系なんか、こんな自動システムで変換させたら
原因不明の違算を、期限内に解決できずに、
何年も膨大な人力作業で直接数字を修正する対応をする羽目になり、
担当者は海の底に沈められるぞ。 アマゾンAWSに任せればいいだろう
めんどくさい事しないでさ ホスト系やってる会社なんて若者もCOBOLやってるから
自分が死んでも無くならないと思うよ。
数は減るだろうが。 これが失敗して、それ見たことかとコボラー大歓喜
素直にCOBOLの言語処理系作った方が安くないか？ 10年ぐらい前にも、同じようなものを聞いたことがあるような >>277
しっかりとした仕様書があればまだいいけど
仕様書を直さないまま、コードが弄られてると
もはや何が正解かわからないという罠もあるよね COBOLをJavaに変換するくらいだったら、Java VMで動くCOBOLを作ったほうが良くね？
COBOLのはいくつかの方言に対応させる感じで。 COBOLは、俺も書いたけど、一部イージスシステムとかも関与してる
具合は機密だろうな
しかし、アメリカ議会で新型核弾頭の発射システムとかもろもろ否決され
いまだに5インチのフロッピーディスクとか使ってるからな、軍事で信頼背重視かもしれんが
イージスシステムは、陸上型まで拡張されてるし、小型化なんか無理だし
だらだら続くんじゃないか
このJavaコンバートも、軍事の盗んでるかもしれないし 動いてるか知らないが、unixで動くCOBOL
むかし設計したけど、あんな機材でチマチマやってるしかないんじゃね
ソフトバンクグループもそんなのでしのいでるだろ、たしか COBOLをJavaに変換とか狂気しか感じられない 古いシステムって半角カナ文字多用してたと思うんだけど直すの大変そう オラクルが、Javaのセキュリティ保証期間を半年経緯に縮小したり、
Javaの有償保守契約を阿漕な値段に改定したりしている中、よく
Javaに切り替えようと考えるな～。
日本中の公官庁や大手企業が、できればJavaを使わないシステムに
切り替えることを希望し、早期の切り替えを断念している中、
米国追従が過ぎると思う。 >>295
それ言ったら、COBOLの保守体制ってJAVAよりマシなん？
GNU系を使うなら結局JAVAと同じ条件だし >>298
仕事してたとき、電力配電のコアはCOBOLで書かれてて
何十年も変化させれられない、さわれないとか
Javaではそんなのまだ聴いてないな Fortranの場合は使っているサイトでメンテできそうな気がする 学部の頃、シミュレーションに使う言語がFORTRANで、無邪気に「Cで書いてもいいですか？」と言ったら
「要素が複素数の行列の計算しまくるけど自分で書ける？」と聞き返されて諦めた思い出 近いものはJavaにあったと思う
それ以外の言語ならライブラリ探すか自分で実装する >>265
触らないでそのまま使う
当たり前だろw こういうので自動生成されたソースは人間が見ても何をやってるプログラムなのかさっぱりわからん！ 昔やったなあ。
Web系とは別世界で仕事してるんだろうな。 COBOLでそんな評価なのか…。
そんなうちはいまだにRPGちゃん！ この時代錯誤感、常識のなさがNTT たる所以
こういうバカ企業はとっとと潰そうぜ
まず、ドコモを使ってるやつはどこでもいいから他のキャリアに変更しろ
NTTは日本社会のがん細胞 古い言語ではあるけど、COBOLとかFORTRANのソースは
なんの処理してるか読みやすいから捨てがたい魅力はある。 COBOLのソースは半分以上がドキュメントだからな
でもFortranの場合は簡単にスパゲッティ作れるぞ 大学でフォートランが走ってたのって、DEC αチップとか
なんか癖せえ石かCPUか、いまもうそんなのなくね FortranコンパイラはGNUが提供しているから、
普通にPCで動かせる >>319
Fortranって簡単に言うけど、Fortranにも色々あるし、処理系によって計算結果が違ったりするから単純じゃないよ 一応コンパイルオプションで色々設定は出来るようだ
先日30年近く前の古いソースをコンパイルしてみた 大学の研究所でうちはDECは教官がSunばっかだったなあ
隣の研究所ではDECがあって見せて貰ってたけど、フォートラン走らせると
専用になってしまうというか、FX32つかってエクセルでデータをっても落ちるとか
汎用性は無い様子だった ソースの変換より、データのコンバートの方が問題多いだろうに >>258
cobolのネイティブコンパイラを開発するより
javaへのトランスレータの方が有利と考えたのだろう >>295
cobol使われてるのなんて閉じた世界の中のシステムだから
セキュリティ保証なんて自分たちで総合的にやればいいし
他言語で再開発する費用に比べたら
javaの有料化の費用なんてないも同然 >>323
コンバートしないで済むランタイムを書くに決まってる こんなん俺が知ってる限りで数十年前からあるじゃん？ >>327
金融は、まだいっぱい現役で動いてるぞ。 ちなみに、googleやamazonやマイクロソフトのエンジニアでも、銀行の基幹システムの再開発とか無理だからな。属人化してる業務要件が多すぎる。
そもそも銀行の業務フロー自体を完全に変えて、そのシステムを作るなら簡単だけど。 >>330,331
金融業界自体、日本に不要な組織がいっぱいあるだろ << 317
コメントならまだしも、命名規則を無視した、幼稚園児がつけたような英語の音読みのメソッド名やニャロメとかいうわけのわからない変数名も見たことある。 >>335
5chのアンカーすらまともにタイプできないやつが
いくら正しいこと言ってても説得力に欠ける例 Javaも流行して、最初タダでばらまいて、あとで高額有料化
トロント大学で公開された人工知能システムと言われてる画像関係もあとで高額請求するのでは >>328
>>330
またCOBOL関係をやりたいｗ 安倍は70歳までこき使うつもりらしいしな
団塊の爺さんのまだボケてない目ぼしいの拾えば十分な頭数がCOBOL部隊が揃うだろう 団塊よりも15歳以上年下のほうが
COBOLをできる >>339
有料化に関してはORACLEに買われたのが不幸の元。 もともとVMをタダでばら撒いといて、Javaチップでその市場をいただくってのがSunの皮算用だった訳で
Javaチップの開発が遅れに遅れて、WSの市場をLinux/Intelに一気に取られてしまった
その失敗から回復出来ないまま、結局Sunは身売りする羽目になった
本当にSunてバカ過ぎだったわ >>345
ちょっと修正
Linux/Intel→WintelとLinux/Intelだな
うちも待って待って、最後にLinux/Intelにしたけど、Sun WSよりずっと速くなったw
SunはJavaチップにこだわって(まあ当たり前だけど)、Solaris/X86を進めなかったのもOS市場を失う原因になったよなあ ↓お前、月曜日から変換した後のコード改修作業に任命したから >>113
存在することは存在するが伝説ポケモン以上にレアなので
派遣で月額２００万円かかる 誰かいい加減客に言ってやれよ
業務に合わせてシステムを組むよりシステムに合わせて業務を組む方がコストが安いと
最も冗長性があるのが人間なんだから >>349
このblog前に見たことあるがとても分かりにくい
特に注とか見てみろ
なぜか知らんが画像でやってて他人に分からせようっていう気がミジンもないだろ
こういうジャンク情報はネットから消えてほしい
検索の邪魔、初心者の邪魔、界隈の価値を棄損するゴミ情報だ
「なぜ必要なのか」に対して延々とその機能を説明してるだけ、
本当に空気読んでないし他人が何を欲しがってるのかマジで分かってないヤツが書いてる記事だ >>354
Microsoft税とOracle税どっちがお好み？ >>182
懐かしい。こんな感じのが縦長にズラッと。 米IBMが、RedHatを買収したらしいな。 オープンソース詐欺も終わりを迎えつつある。
IBM、レッドハット買収で合意--340億ドル
ttps://japan.cnet.com/article/35127693/
> IBMは米国時間10月28日、オープンソースソフトウェア企業Red Hatを340億ドル（約3兆8000億円）で
> 買収することで合意したと発表した。 >>357
FedoraやCentOSはどうなるんだろう >>358
IBMは殿様商売の危険を瀕死になって学んだから、今後も協調してやってくんじゃないかな >>4
マジこれ
JAVA化とかろくなことない
作り直したほうがマシ COBOLの後で出てきた多くの言語が滅んでるぞ
Oracleの動きとか見るとJavaも長くは無さげだし、Javaが滅んだ後でもCOBOLは生き残ってそう・・だが 言語仕様が時代遅れだろうが何だろうが、COBOLで書かれた
膨大な量のプログラムが稼働しているという現実があるよなあ。 COBOLからJavaを呼ぶプログラム
JavaからCOBOLを呼ぶプログラム
簡単 コボルの設計が、いかつい女の人だっけか、それだけじゃないが
Javaは、とある博士に、インド人の餓鬼が山になって作業してた
それだけ人口をかけても駄目だったつ 将来消えるかも分からん、セキュリティガバガバの下位言語に変換する事に
何の意味があるのか >>371
「実行可能な仕様書」という青い鳥を追いかけて、今でもドメイン固有言語が開発されるけど
いまだにCOBOLを超えたものは無いからね。 >>4
その通りだけど、COBOLのままでも誰も手を付けられない塩漬けだから、同じだろう
塩漬けのままJavaに変換して移行して顧客をロックインし、メインフレーム捨てさせてハードの保守費用が浮いたとこで、作り直しを随意契約させる
したたかだわ >>183
ハカーも解読できない糞コードになるからダイジョブ ■ このスレッドは過去ログ倉庫に格納されています
