仮想化でバーチャルマシンを作ってクラウドでサービスを受ければいいからな
いい時代になったものだ
トヨタの世界勘定システムや、大手銀行なんかはだいたいCOBOL。
全部作り直すよりハード更新したほうが安いからね。
携帯会社の基幹はだいたいCOBOLなのでよかったね。
この言語はやったことないけど何に近いの？
Pascal? Fortran?
>>11
COBOLはBASICに近いっちゃ近い
VBじゃない方のBASICね
てか今も動いてるCOBOLシステムってマシン語サブルーチンとか使ってるの多いと思うんだけど大丈夫か？ コボルは読み書き出来ないけど
他の言語は出来ますなんてアホいねーよ
他の言語出来るならコボルは1時間勉強すれば出来る
そう設計されてる
>>2-3
お前等のように新しいものは古いものより優れていると思い込んでいる文系は社会のクズだということを気づけ。
なんで貴様等のような無能者に世界が合わせなければならない。
優れているからこそ今も使われている、それだけだ。 >>6
つい最近COBOLの腐ったシステムを
わんミズホさんがJavaにリプレースしたやん
Javaも酷いらしいがw >>11
古代言語だから、現存する言語で似ている物なんて無いだろ
無理にその２つで言うと、データ形式を書く点ではPascalで、行単位の文法でFortran？ 解散。
＞
一方、稼働時間が限られるAWS Lambdaは、「長いトランザクション処理などは苦手」（マソン氏）という。このような処理は、COBOLプログラムの分割やリライトといった変更が必要になることが少なくなさそうだ。
また、リコンパイル後のプログラムの実行には、Javaの実行環境を立ち上げなければならない。初回起動時は処理に時間がかかることにも注意が必要だ。
コボちゃんはお役御免って事で、
これからはPHPでやれ！
>>13
それが欠点何だよ
人間の言語は冗長だから プログラミングって自動化されないの？
わざわざコード書くのは、かったらるくないか？
>システムの保守・運用に悩むユーザー
長年プログラムメンテでソースがぐちゃぐちゃになってたり、仕様書と乖離している場合
下手したら、実行形式だけでソースが紛失している場合があるからかと思う
言語自体は、普通に作っていれば、理解しやすい
まあ、こういうのまだ使ってる企業自体
そのうちリプレースされるだろう
>>21
人工知能って、何のために作ってるんだろうね 懐かしいなPL/1とかCOBOL。ダンプリストに赤線引っぱってたっけか。
COBOLはいいと思うけどな
必要な計算処理だけCOBOLでやって表示とか他のでやればいいじゃない
コボル懐かしいなぁ
昔会社でプログラム組んでたけど日々のデータトランザクションを
深夜にバッチ更新するからオンライン向きじゃなかったね
COBOLを捨てるって事ではなくて、自前のハードと計算機室を捨てるってことだよね
移行にはそれなりに手間がかかるだろうけど
二度と移行作業も、ハードソフトのバージョンアップしなくても良いのは素敵過ぎる
やっぱり紙テープと磁気テープがないとCOBOL触ってる気分が出ない
磁気テープマウント等はawsでどう実現するんだろう？
jclはどうなるの？
COBOLだけ移植されても使い物にならなくない？
ＡＷＳでシステム３６０のエミュレーションをやれってかｗ
電子博物館だなｗ
move toとかperform toとか直接的でわかり易かった。
コボルに最適化されたハードウェアとOS捨てて、ランニングコストだけ削減して
大規模基幹システムを移管するメリットあるのか？
大昔COBOLのプログラム開発で、カードリーダーからプログラム読見込ませて、磁気テープ装置のテープがくるくる回って、ラインプリンターにバババッと印字される感動は今でも忘れられない思い出。
>>34
Ｆ４じゃなくて X8となｗ
その世代だと370互換が必須だな 数十年後にも残ってる言語だよな。COBOL
JavaはOracleのせいで死んだ
第二地銀黎明期に友人が会社で使うってんで学習手伝いがてら俺も覚えたわ
当時は開発環境なんてゲスト垢が俺でも使えるくらいセキュリティポリシーガバガバだったな
IBMもいよいよ終わり
zもエミュレーター上で動くからなw
新しいシステム、新しい言語で、既存システムと全く同じのをつくって！
っていうのがデスマーチになりやすいケースだって何かに書いてあった
>>21
２０年以上前から結構自動生成されているよ 47名刺は切らしておりまして2019/07/30(火) 16:01:33.99
業務アプリってぶっちゃけなんでもいいんだよな
癖を覚えるのが面倒なだけ
動くのはいいけど、使いこなせる人材がどんどんいなくなっていくのに古い資産を使い続けるのはリスクじゃね？
どっかのタイミングでシステム更新するなら早ければ早いほどいい
AWS使うぐらいならシステムを再構築したほうが長持ちする
思い切ってシステム更新すれば無くても困らない機能が8割あることに気が付く
コーディングの標準化規約しっかり作って、固定的に雇えるプログラマーを雇用して
その通りに作るんなら、C++でも構わないと思う。というか、今時のC++はSTLも含めて
良くできている。
どちらかというと問題は、プログラマを外注変動費にして、毎回スキルが異なる人を
集める関係上、標準化規約が有名無実になっている点。そして、どこからそうなるのか
わからんけど、COBOLプログラマは安くて、JavaやC++だと高いみたいな、不可思議な
事がまかり通って、みんな中途半端に新しい言語に飛びついていることだと思う。
>>53
COBOLのコード自動生成よりもはるか以前から、自動生成されていますが？ システムをわかってない奴ほどアセンブラでと言い張るよね
ほんとキモい(´・ω・｀)
プログラマ要らずのコード自動生成の夢を見て沢山の簡易言語が出たが
COBOLを超えるもの未だなし
57名刺は切らしておりまして2019/07/30(火) 16:43:36.59
AS/400のRPGは傑作だったな
多少の認知が入っても自分の書いたソースが読めます、たぶん
>>55
軽さを求める奴がアセンブラって言うんだろうな
コボルはそれと対極、スピードは求めないが、信頼性で選ばれてたからなぁ
でも流石に駆逐されて欲しいｗ 60名刺は切らしておりまして2019/07/30(火) 16:49:15.67
ソニーのneural network consoleみたいに
モジュールの積み木を積んでいけばプログラム書かなくていいみたいなのが
出来ればいいのに
さすがAWSやわｗ
「レガシーシステム保守は不安よな。
COBOL 動きます。」
>>57
まだあるぞw
しかも年々バージョンアップしてる 64名刺は切らしておりまして2019/07/30(火) 16:58:56.81
前の会社、PC-9801でなんかやってたが、メーカーが潰れてシステムを組めなくて中古で探してたの思い出した
>>37
F4は重いので、同一ハードにX8載せた方が
キビキビ動くって言ってたアプリ開発者がいたなあｗ。 保守運用のコボおじ達は現状平和で長生きできてる幸せな人種
本番対応以外はマジで定時付近に帰れてワークライフバランスも良い
若者は塩漬けにされるのが嫌で逃げるから余計にパラダイス化してる
効率化のためにプログラム言語はあるがCOBOLのために莫大な無駄が生じている
COBOL使うようなところがAWSを使う発想があるのか？
メインフレームから離れられないユーザだろ
>>73みたいなこと言う人をネット上でよくみかけるけど、
そういう人ってCOBOLできちんと仕事したことあって
COBOLの長所短所を踏まえてるのかなぁ？ faasとCOBOLって対極にあるような気がするんだが、そうでもないのか？
>>6>>70
全部本体の方が終了しそうな会社や業種じゃないか
というわけでコボル君も一緒にロストテクノロジー化するので大丈夫w
まあ今は金融の勘定系すら標準システムをカスタマイズして、しかも今後はクラウドで、というふうになっていくようだろ
2018
>銀行の勘定系システムの機能をインターネット経由で提供する「クラウド勘定系」がにわかに盛り上がっている。富士通は2020年の提供開始を目指しており、ソニー銀行が第1号ユーザーとして採用することを検討中だ。
がただでさえ火がついているメガバン様
>三井住友 「勘定系システムはメインフレームを中核に長年作り上げてきたものなので、そう簡単にクラウドへ移行することはできない。移行するとしても遠い未来で、5年後のような近い未来の話ではないと考えている」
相変わらずの調子 COBOLが出来た頃のコンピュータと今のコンピュータは何倍くらい性能が違うの？
すげぇな
でもうちは１０年前に全部リプレース済みだからもうCOBOLは残ってないな
>>16
古代言語ってその通りなんだけど、なんだかファンタジー系のRPGみたいだな。 >>28
それやりたくで出入りの業者に相談したけど、時期尚早だと実質蹴られたわ 91名刺は切らしておりまして2019/07/30(火) 18:52:30.42
アジャイルだとJupiter notebookみたいなの使って
仕様決めのメモからプログラムまで一緒にしちゃった方が
保守がしやすくて合理的なような気がする
昔コボルとかフォートランとか習った気がするがまた使えるようになるのか？
コボルの問題は、コボルをリプレースできる言語が無いことだな。
10進数言語の開発が待たれるが、COBOLの拡張とハード側を仮想化の方が安いんだろうな。
うちもコボラー派遣でお願いしたら
６０前の方だらけになってたｗ
>>93
Fortranは特定分野ではまだまだ現役だし、言語自体も
進化してるだろ。いわゆるIT屋が使うのではなく、科学
技術計算をする必要があるサイエンティストやエンジニアに
とって、プログラミング言語の修得という余計な労力を
最低限にできるという意味で、使い勝手がいいのでは？ >>94
まさにそこだよね．10進数で計算してくれ言語じゃないと．
他にそんな言語知らないけど，なんかあるのかなぁ． >>36
昔は一時ワークにもテープ使っていたからな
ディスクが信じられないほど高価だったこともあるけど
今じゃテープを一時ワークにするなんて考えられないわ 昔は、COBOLのハードウェア直接実行マシンなんてのがあったんだぞ
ピンと来ないだろうな
>>98
javaでstrictfpという宣言をすればIEEE754で演算できるようになる Javaももう25年も経つのか。COBOLになれなかった半端者め。
>>101
BigDecimal 使えってことだろうが，，
それが言語のデフォルトじゃないしなぁ． AWSにしたらバッチジョブは完結する保証がないし、
自前プリンタは必須
コスト半減まで行けば、大成功かな
>>11
もともと事務員が書けるようなものを目指してるからな。 >>109
COBOLとかFortranは、プログラミングの専門家ではなく、
計算を必要とする領域の専門家がコーディングすることを
前提としているからね。 なんだかんだ言ってCOBOLを使ってた
人間は勝ち組で引退できるとはね
>>11
完全手続き型特化のSQLと聞くとイメージできるだろうか 今の今までCOBOLを排除できなかった企業は
現状に固執することを選ぶような
>>117
ユーザーは業務に必要なソフトウェアを組むための
プログラミング言語がなにかなんて興味ないだろ。 >>113
そろそろ残存者利益が出てきた頃かな。
20代で新たにCOBOLをやる奴もいないだろうし、60代は引退の時期だし。 >>28
どんな言語、ハードだって
結局は移行作業必要になる時がくるやろ… >>118
維持してるのはユーザーじゃないの？
興味ないかもしれないけど、ユーザー以外はそんな骨董品のシステム使いたいニーズ持ってないんだから 維持し続ける理由ってなんだろな
新しく書き起こしたら莫大な試験でとてもこなせないとか、そう言う理由なんだろか？
また、使ってるところはどこなんだろ
銀行みたいなところなんだろうか？
そんなところがアマゾン簡単に使うような選択するとは思えないけど
>>14
で？
金融系のレガシー関連以外に具体的な仕事あるの？
あるなら出してみな。 >>44
これユニコード時代になるとどうでも良いことなんだよね。
16ビットコードの時代には取り扱いが面倒だったのは事実だけど。 >>6
大手銀行は別にして現実にコボルの適用分野はほぼレガシー関連しかない。
要するに不要なシステムなんだよね。 >>11
既存の言語はプログラムタイプの簡略化、簡便化を考える。
コボルは20年後の人がそのプログラムから組織、人員、デバイスなどのメタ的な状況を含む全ての情報で理解でき、かつ誤解する可能性がないことを要求する。
要するに効率良く仕事をしようとする最近の言語に対して、プログラム作成のための労力は無限に投入可能という思想で作られたのがコボル。
作成の中心がアメリカ軍の後方部門というのは伊達ではない。 >>12
マシン語とか言っても、マシンごと仮想化すれば良いだけだからね。 >>128
20代の優良で健全な労働力が大量に投入可能というのがコボルシステムが要求する最も重要なリソースだが？ 漫画のコボちゃんは子供だけど
IT業界のコボちゃんはおっさんだらけ
COBOLでたくさんプログラムを作ったな、オンライン処理、バッチ処理、サブルーチン、
８０年代だけど充実してたわ、当時日立のＭ２２０でＤＢはＰＤＭⅡで端末は５６０/２０
エミュレータ、ＤＢ操作はＸＤＡＴＢＡＳ ＲＥＡＤＭ ＲＤＮＸＴとか使ってプログラミングしてた
ＧＯＴＯレス、うちパフォームそとパフォーム文を駆使してた。テープソートなんかしないし
索引順編成ファイルを作成すればソートしたことになるし工夫しだいで簡単にバッチ処理はできた
>>130
視野の狭いIT屋のための言語ではないということだね。 >>134
レガシーの意味がわからないのね？
馬鹿はもう寝ろ。 >>136
お前のような間抜けにはお似合いかもね？
ただ、お前には動けるコボルのシステムは作れないがな。 >>137
カタカナではなく、普通の日本語で説明してみ？ COBOLは、誰でもすぐにソースが読んだりかけたりするのが良いね。
フロント側でもエクセルとかが不要になるし。
>>30
そういう話しはまずここでは上がらない。ただの一種類資産なのにね。 触ってる人居ないの？
現役で
スレでマウントとり会うのは構わないけど、今使ってる人がいるならどんな用途でなんで使い続ける判断してるのか、可能な範囲で聞いてみたい
これは需要あるだろ。
いままで完璧に近く動いてた完成させたコードがそのまま使える。
コボル自体を稼働させるためのハードやソフト絡みのことは丸投げできる。
縮小、衰退ぎみのコボルを逆手にとり一括管理してくれる。
お前らが何言ってるのかさっぱりわからんのが、逆に楽しい
COBOLアプリがAWSで動く、「コスト8割減」をうたう新サービスが登場 日経 ｘＴＥＣＨ
2019/07/01
COBOLプログラムを稼働させるハードウエアの保守・運用には多大なコストが発生するのが一般的だった。
ところが、最新技術の活用でこの状況を改善できる可能性が出てきた。
それが、フランスのブルーエイジ（Blu Age）が手掛けるサービス「Serverless COBOL for AWS」である。
Serverless COBOL for AWSは、「AWS Lambda」を使って既存のCOBOLシステムをサーバーレス環境で動かせるようにするサービスである。
AWS Lambdaは、米アマゾン・ドット・コムのAWSで提供されているサービスの1つ。
処理時間にしか課金されないためコスト効率に優れている。
COBOLシステムをサーバーレスに移行できれば、メインフレームの維持に費やしていたコストの削減が見込める。
ブルーエイジのシニアソフトウエアアーキテクト、ティエリ・マソン氏は、
「メインフレームでCOBOLシステムを動かすのに比べて、8割ほどの保守・運用コスト削減を見込める」と自信を見せる。
>>135
そういう時代もあったね
しかしワークステーションやＰＣが台頭し、
COBOLプログラマも３日でＣを習得して、
現場投入されたよね たとえば、web検索やGメールを自前で製造するか、ネットでやるかの違い。
検索エンジンを自前でやるとサーバーとかプログラムがいるが。
すでにあるやつ使う分にはブラウザだけでいい。
コボルが動くシステムを、アマゾンに丸投げ。
たとえば、メモ帳でコボルのプログラムを書いてネット送信すれば応答くるようなもの。それを業務で使えるほど規模でやる。
お前ら最新技術のスレだと的外れレスばっかりなのに、COBOLスレになると妙に具体的な話になるなw
ＲＰＧはどうなん？？
そもそもIBMに対応してるかという問題があるがｗ
言語の問題ではなく、システムを構成するハードウェアとその規模もの問題じゃね？
まぁ、どうでもいいけど。
COBOL>JAVAのリコンパイラで支障ないならコボラー滅びそう
もうCOBOLは20年、お目にかかってないｗ
でもいまでも錆びていない
COBOL書けると以外にメシウマなんだよね。
ただ、創造性のある仕事にはつけない。
>>144
メーカー毎COBOL毎に微妙に仕様が違うから、
ソースレビュー・確認・修正は必須
特に深刻なのは、日本語処理周り
事前のデータコンバージョンが必要
丸投げ的なことはできないのよ COBLEの最大の欠点は
それを動かすメインフレーム機の費用がとんでもなく高いこと。
これをAWSで動かすことができるなら確かに需要はあるだろう。
あとは>>157の言うようにメーカーごとにまるで異なる方言をどこまで吸収対応できるか。
日本語対応はまったく期待できない気もするが。 >>14
新しいシステムがCOBOLで作られてるわけじゃなく昔作ったものをひたすら保守して結果COBOL使える人材もいなくなってるってことじゃない？
そして今でも使ってるところはしすてむがでかすぎて入れ換えるにも金がかかるってことかと すでに動くものがあるなら
エミュレーターを作るのが早いわな
動作速度とかタイミングとかの関係で
エミュレーションだけでは完全な動作を保証できないところもあるかもしれないけど
ピリオドが有るかどうかをソースを永遠と探してた思い出
ＣＯＢＯＬは金利計算に適している１番の言語、基準残，積数、切捨て等、計算式が楽に作れる
メンテもしやすいが変更履歴が増えると実行ステップよりメモが増えて目検（めけん）でのチェック
がいやになることもある。
あとはデバッグが面倒、デバッガーを使用してテスト結果を記録するのに時間がかかる、まあ
どの言語も似たようなものだが、コストの面は昔はハードが高かったが汎用機からＰＣサーバに
代わり随分安価になったが信頼性がダウンしたＯＳのせいだな仮想環境が維持費用を拡大した
大事な基幹システムを一企業のサーバ上に置くとか狂気の沙汰ｗｗｗｗｗ
> 一方、稼働時間が限られるAWS Lambdaは、「長いトランザクション処理などは苦手」（マソン氏）という。
バッチ処理とか大丈夫なん？
>>130
プログラムを作るのに必死で、重要な設計資料を作っていませんでした。
という初学者にありがちなミスを犯してるんだな。 >>119
今なら訓練されたベトナム人が投入される。 >>60
テキストでソースコード書かなくても大量の「設定」が必要になると思われる。
セールスフォースみたいになるならソース書いたほうが100倍マシ。
sfdcも結局コード書く羽目になるし、、、 >>21
人が書いたコードでも読み解くのに時間がかかるのに
ＡＩが書いたコードなんか理解不能で保守不能になる >>168
そのかわり、その辺の手書き伝票とかまんま入出力できる >>167
AWS lambda は普通は秒単位で終わるようなプロセスを実行するための環境なんだが
最長は15分まで >>172 AIとは違うけど…
20年以上前までNECの汎用機ACOSでCOBOL/Sのプログラムつくってたけど、
コンパイルエラーだか実行時エラーのときにプリントされたコボルソースが
COBOL/Sじゃなくて機械的に展開したCOBOLだったので、とんでもなくわかりにくい
ものだったのを思い出した。 よーし、金利の四捨五入の端数を自分の口座に集めちゃうぞ
今金利がメチャクチャに低いから
そういうのをやると目立つと思う
>>175
ITOS、NTOS、PTOSのCOBOLずっとやってて、ACOS2、ACOS4の画面系初めてやったときはビビった
違いすぎだろ、何だよ画面を送信するってw AIがコード書くとして、というか、
機械学習はヒューリスティクス関数を得ることなので、
「コード」っぽいものが得ることはできると思う。
だから、コードを読んで、検証やテストの為の
プログラミングが必要になるんじゃないか
プログラミング（コード）を検証するプログラミング（）
AWSってなに？アマゾン雲通信サービスてこと？
雲、クラウド空中？え？
単にデータ通信網が速いから
他所の会社で自社のシステムを
全部移行して、つかうだけでしょ
Amazonのクラウドなんて時給制で中国人やインド人が管理w
セブン同様に盗まれるだけ～
C++にもデシマル型とかパックドデシマル型とか作ればよいのに。
>>189
今どきハードウェア十進計算なんてアドバンテージにはならないだろ プログラム言語が使えるだけでは、何も解決しないんだよ。
ど素人は気楽でいいなwww
自分のいってたＦＳという保険屋は
Ｆのメインフレームからパッケージに去年移行したけど
当初４年の計画が９年ぐらいかかっている
現行とパッケージを合わせる作業に５年ぐらいかかってた
正直よく移行したと思うわ、予算が当初の５，６倍かかってたな
保険屋はまだパッケージがあるからいいけど
公共（年金）はずっとコボルでいかないと無理だと思う
というかリプレス不可能だと思う
COBOLerになれば年金貰いながら
月60万稼げるぜ？
>>194
作れるのは知ってる。
作った奴がいるのかという話。 >>11
COBOLは仕組み的には機械語に近い。
簡略化された命令が少なく、自分でメモリの構造を考慮しながら組む言語。
今ある言語からは程遠い。PASCALもFortranもCOBOLに比べれば高級言語。
もう、いまじゃ高級言語なんて若い人はわからないんだろうな。 C/C++のBCD演算とか多倍長演算、任意精度?
フリーでもGMPとかあるやろ?
decimal型とか用意してるのはIBMだっけ?
>>200
釣りですか、ＣＯＢＯＬを知らないのですか、機械語に近いのはアセンブラです。
ＣＯＢＯＬは高級言語です、事務処理に一番適してる。
PASCALやＦＯＲＴＲＡＮでオンライン処理ができますか？ 逆にCOBOL使える人は高く使ってもらえたりしないの？
業務知識あれば高値安定そうでなければ低い
それがCOBOL
Windows10で動くVisualCOBOL.NET頼むわ＾＾
もうコボルやめろよｗｗｗｗｗｗ
いつまで遺産を使い続けるんだ？？？
新しい機能が必要なければ、バグが取れて枯れてるシステムのほうがいいのがわからんの？
>>207
MicroFocusが出してるぞ
冗談ではなく COBOLというか汎用機を未だに使ってる企業はかなりあるよ
システムをリプレースする予算がないとか
リプレースに失敗したときに責任を取りたくない人が邪魔してるなど
>>209
役所みたいに金がじゃぶじゃぶ使えるならな かなり昔、COBOLにオブジェクト指向機能が追加されたのも、あまり知られていない
>>105
IEEE754じゃ誤差が出るだろ
BCDでないと >>219
必要があれば自分で書くけど、みんな困ってるんじゃないかと思ってね。 Cobol を使わなかったセブンの末路知ってるか？
バカって直ぐに安いシステムに食いつくんだよねw
>>189
メインフレームの性能なんてクソだろ。
ただ、低い故障率やメーカー保証があるから使うだけ。
あと、I/Oをコプロに投げるからCPUの
性能は必要ない。 >>202
PASCALオンラインはあるよ。
それと、COBOLのパック演算や文字操作は
マイクロコードになってるから
アセンブラでも書ける。 >>10
LambdaがLambdaを呼ぶコード書いて事故るとクラウド破産しかけるけどな～ >>224
ごめんよ、私の今までの経験（金融、自治体、警察、図書館等）で汎用機でPASCALを
見た事がなくオンライン処理ができるなんて知らなかった、もしよろしかったらどんな業種で
どういうシステムで使ってたか教えてください。 >>221
困るっつっても、必要だったら小一時間で書けるようなものだし 30桁のパック演算で誤差が絶対出ないとか保証できるもの作るの？
>>15
みずほさんの惨状見たら、やっぱコボルのままでいいやってなりそう 俺が就職した70年代半ば、158 2台で昼間はオンラインとプログラムテスト。
夜間はバッチジョブとプログラムテストだった。
既に仕様書のないアセンブラとかあったな。
>>231
エンジニアが保証したぞ
しかも書面でww >>220
BCDでも1÷3みたいな演算すれば誤差は出るわけだが？ 根本的に勘違いしていないか？ オブジェクト指向言語で固定小数点オブジェクト作ったら?
>>237
2進⇔10進高速変換ができないと、長時間バッチなんてできないのよ
これには普通、10で割るループを組んで下の桁から順に取り出すというのが定石
これだけでも大量に除算が入る
さらに、最新COBOLでは10進32桁のデータを扱えることとなっているから、
2進では128ビット整数で表すことになる
普通のサーバじゃこのビット数の整数は１０では割れず何らかの除算例外が発生する
ひと工夫すれば回避できるが、すると大きなオーバヘッドの発生は避けがたいわけ
カプセル化だけでは済まない理由がこの辺にある 今からプログラマー国策で育ててるからあと15年もすれば供給されるだろ
>>238
オープン系だとバッチ処理はHadoopで荒粒度並列化という手段があるのでは? >>238
それハードの問題だよね？
COBOLはどう問題回避してるの？ >>241
だから、オープン系には事実上10進演算ハードウェア命令がないでしょ
一方、汎用機やオフコンはそれを備えてるわけ
COBOLの大部分の10進演算は1～数命令の機械語に展開され、
高速で実行されるのよ 15年後にCOBOL要員がたくさん送り込まれるな・・・
>>242
専用ハードが必要ならFPGAでよくない？
本当に必要なのかわからんが >>242
オフコンの10進演算ハードって掛け算や割り算もサポートしてたんですか？ 今時の汎用機やオフコンってどの程度の性能があるの？
ハードウェアでサポートしてても、
パソコン搭載程度のCPUでエミュレートしたのと
どちらが性能良いかな？
コモンビジネスオリエンテッドランゲージでいいんだっけ。
>>248
ホストって汎用機を指す言葉ではないのでネタではないんじゃないの
ホストコンピュータはあらゆる形があるからね、汎用機の場合もあるしＰＣサーバもあるし
ただのＰＣの場合もある。 >>63
IBMの方言みたいな言語なのに、まだ存在してるのかよ。
コンパイルしたら、COBOLより速いとかなんとかが当時の売りなんだっけ >>238
最初から最後までBCDで計算すればいいだけ。
ニシンが出てくる必要はない。 >>250
この文脈でのホストならPCサーバとPCは含まなくないか?
> 基幹システムでは、メインフレーム(以下：ホスト)で大量のトランザクションを処理しているが、 月１００万超って聞いた。
JCLしか知らんワシは１０万も無理だが。
>>238,242
なるほど cobol 長生きするわけだ 外国の銀行はどうやっているんだ？
アメリカとかユダヤのところとか
>>257
COBOLシステムに携わってる人がこの程度の認識だと、
そりゃCOBOL最強って思ってるだろうなぁ >>242
何？昭和？
ムーアの法則って知ってる？
今やその辺のPCでも例えば単純な加減乗除なら1秒に10億回 金融の基本的な入金処理に1000倍のステップないし時間がかかるとしても1秒に100万件処理
日本のATMの総数は十数万台 大量の日本人が全部で一気に入出金処理しても、計算速度的にはノートパソコン一つで間に合いそうだなw
一般の振込や、少なくとも自動振替処理は別に1秒以内の一瞬で受け付ける要はない、時間分散してもよいからさらに楽
そしてもちろん、日本の全金融機関が1台のPCを共有して使っているわけでは全くない
そういう中で、何かの特殊処理の有無によって仮に10倍速い遅いに意味あんの >>262
入出金だけで処理が終わると思ってるの？www
1つの取引で関連するDBの参照とか更新があるから、負荷は大きいよ。 >>263
その程度の負荷がクリティカルになるようなオンボロコンピュータ売ってるんだとしたら、詐欺だね。
それかプログラマーが無能すぎて無駄な処理や待ちが発生しているか。
もしくはその両方だね。 >>46
富士通の「ＣＡＳＥＴ」だったかな、部品を組み合わせていく
様にしていったらＣＯＢＯＬのソース生成からコンパイルまで
しちゃってオブジェクトができるけど、ソースは見れないという
せこい第４世代言語とかいうやつ。 ハードウェアを丸々仮想化できるならその方が安いんだろうよ
>>263
それが処理のボトルネックなら、もうCOBOL関係ないだろ 携帯の5Gですら変復調はソフトウェアで実装してる、仮想化には逆らえず金融だけ特別扱いは無理だろ。
>>268
ベースバンド処理は、楽天の汎用サーバに乗ってるFPGAカードや三大キャリアの
ベンダ基地局に乗ってるFPGAでハード処理してる。
FPGAは、プログラマブルなハードなので規格が変わったり機能追加されたときに追従しやすい。
https://japan.zdnet.com/amp/article/35134297/
楽天モバイルネットワークでは、BBUをソフトウェアで仮想化し、x86サーバをエッジサーバとして配置する。
エッジサーバは、NTTの電話局にコロケーションで設置する。基地局とエッジサーバ間は、専用の光ファイバ（100Gビット）で接続される。
ただ、単なるx86サーバだけでは、基地局からのパケットを処理するのに負荷がかかる。
このためエッジサーバに、携帯電話ネットワークのパケット処理にチューニングしたIntelのFPGAカードが使われている。
1つの基地局に対して1つのFPGAカードが接続されることで、負荷のかかるパケット処理を高速なFPGAでハードウェア処理してしまうというコンセプトだ。 
