アカウント名:
パスワード:
別ACですが性能と安全性を天秤にかけてCOBOLですかね.
その特集記事に名前の上がっているシステムの一つの構築に携わりましたが, クライアントはVB+Java, オンライン系フロントエンドはJava, バッチ系はCOBOLで組んであります. Cによる勘定系開発にもかかわったのですが, かなりのスリルが味わえますよ.
Javaはハードの性能に余裕が有れば, ガーベージコレクションによるメモリ管理のおかげで低レベルのプログラマでも破滅的なコードを書きにくいという点で, 悪い選択では無いと思います. しかし逆にこのガーベージコレクションが原因で性能が極端に低下するとか, jdbcがネックとなって入出力性能が出ないとか(それを回避するために, やたら複雑なSQLを書いてDBサーバ側に処理を任せるとか)の罠があるので, 現時点では(特にエンタープライズ規模でのJavaシステム構築経験が無い場合には)大規模バッチ処理では使わない方が吉だと思います.
# 知っている人だと名前を特定されそうなのでAC
え?違う?
# 普段JavaもCobolも使わないのでAC
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
Linuxもだけど (スコア:2, 参考になる)
大規模Javaは甘くない・UFJ銀行 目指すは1日1000万件のバッチ処理
http://itpro.nikkeibp.co.jp/free/NC/TOKU1/20030703/1/ [nikkeibp.co.jp]
え~、Javaで~?マジで~?と問い詰めたくなるような。
--------------------
/* SHADOWFIRE */
Re:Linuxもだけど (スコア:2, 参考になる)
データの処理としてのバッチ、それはそれで結構。
だがしかし、その前にデータを集める、送るという前段階、後処理について。
全銀協標準通信プロトコル(BASIC手順)の最大9600bpsよりはましになったとはいえ、それを元にした全銀協標準通信プロトコル(TCP/IP手順)では通信に時間がかかってしょうがない。しかも多くの銀行は64Kどころか9600bpsのまま。データ圧縮したとしてもたかが知れてる。そんなんだから大量データはカートリッジテープでやり取りをしつづけねばならない。その結果、必然的にカートリッジテープの運送にかかる時間、料金というコストが下がらない。これでは口座振替を利用する企業、ひては消費者へのサービスには繋がりにくい。全銀協ってダメダメといつも思う。
新たなプロトコルとか、通信環境の整備が必要かと。
とりあえず (スコア:1)
出てくるのは避けてもらいたいですね。
いや・・当然その辺りはBigDecimalのみを使うんだとは
思うけど、実はそれだと処理速度の問題で一部Doubleで・・
なんてのがあったりするかもなぁ・・と。
もちろんちゃんと仕様が明確になっていても意外に・・ってのが・・。
Re:とりあえず (スコア:0)
この手のシステムに関わるプログラマはDoubleを 使ったことがない、に一票。
すくなくとも私はここ5年以上浮動小数点モノは 使ってないが...
Re:Linuxもだけど (スコア:0)
処理能力については3歩戻って2歩進むくらいは譲るとしても
Versionで動作が違うかも知れないのに、、、
Re:Linuxもだけど (スコア:0)
元々バッチ処理系というか汎用系では、VMの上にエミュレータ載せて過去との互換性を持たせたりという形で動いてる場合も少なくないですから、JavaVMという
Re:Linuxもだけど (スコア:0)
そんなの、何だってそうでしょ。まぁ、
> 勇気有るなぁ。
って俺も思うけど。
Re:Linuxもだけど (スコア:0)
Re:Linuxもだけど (スコア:0)
COBOL? C?
Re:Linuxもだけど (スコア:2, 参考になる)
別ACですが性能と安全性を天秤にかけてCOBOLですかね.
その特集記事に名前の上がっているシステムの一つの構築に携わりましたが, クライアントはVB+Java, オンライン系フロントエンドはJava, バッチ系はCOBOLで組んであります. Cによる勘定系開発にもかかわったのですが, かなりのスリルが味わえますよ.
Javaはハードの性能に余裕が有れば, ガーベージコレクションによるメモリ管理のおかげで低レベルのプログラマでも破滅的なコードを書きにくいという点で, 悪い選択では無いと思います. しかし逆にこのガーベージコレクションが原因で性能が極端に低下するとか, jdbcがネックとなって入出力性能が出ないとか(それを回避するために, やたら複雑なSQLを書いてDBサーバ側に処理を任せるとか)の罠があるので, 現時点では(特にエンタープライズ規模でのJavaシステム構築経験が無い場合には)大規模バッチ処理では使わない方が吉だと思います.
# 知っている人だと名前を特定されそうなのでAC
Re:Linuxもだけど (スコア:0)
Javaだと実際に実装させられる(駄目)cobolerが
「なんで直接10進型をcompute出来ねーんだ!! これだからjavaは!!」
と悲鳴上げそうな気がする。
Re:Linuxもだけど (スコア:0)
当たり前の感想ですね。
COBOLを貶めるような発言する人いるけど、COBOLってのはまさにその部分を特化した言語なんだから。
泥臭かろうがなんだろうが、事務計算させるなら最強なのは今でも変わらない。
#それでもJavaってのは、本当の理由はなんだろうね。
Re:Linuxもだけど (スコア:0)
COBOLとは違って、まるではじめから言語仕様にBCD演算があるかのごとく利用できますよ。
失礼な質問ですが、本当にJavaをご存知ですか?
Re:Linuxもだけど (スコア:0)
# C++盲信者なのでAC(嘘)
Re:Linuxもだけど (スコア:1)
#最近は自明な場合以外はわざわざ変な演算記号を使わなくていいじゃんと思ったりしますがID
Re:Linuxもだけど (スコア:0)
失礼な質問ですが、本当にこの業界をご存知ですか?
Re:Linuxもだけど (スコア:0)
予算と人員にそこまで余裕があるのって聞いたこと無い。
Re:Linuxもだけど (スコア:0)
つか、金があるなら実績のあるメインフレームを導入すれば良いだけだし。
#目的と手段を取り違えるタイプだな、元コメントの人は。
Re:Linuxもだけど (スコア:0)
Javaってオペレータオーバーロードできたっけ?
Re:Linuxもだけど (スコア:0)
え?違う?
# 普段JavaもCobolも使わないのでAC
Re:Linuxもだけど (スコア:0)
Re:Linuxもだけど (スコア:0)
Re:Linuxもだけど (スコア:0)
c = a + b;
が出来ないとcobol野郎は悲鳴を上げる、て事だと思われ。
「何でStringは出来るのに!!」とか言いそう。
それよりも (スコア:1)
Re:それよりも (スコア:0)
どうしてこのツリーの方々はJava 2 SDK 1.5 (Tiger)で導入されるであろう
JSR13 Decimal Arithmetic Enhancement [jcp.org]に全く触れませんか?
1999/04/30にはApprovalされてるのですが。
Re:Linuxもだけど (スコア:0)
bea [beasys.co.jp]