【COBOLから】バッチ処理【Javaまで】
■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
2008/01/12(土) 16:38:37 最近は、Javaでもバッチ処理を書くんですなぁ
2デフォルトの名無しさん
2008/01/12(土) 16:42:523デフォルトの名無しさん
2008/01/12(土) 16:45:444デフォルトの名無しさん
2008/01/12(土) 22:09:05 batchがCでやるものだ
5デフォルトの名無しさん
2008/01/14(月) 12:10:39 あげ
6デフォルトの名無しさん
2008/01/14(月) 13:51:46 まん
支援
支援
7デフォルトの名無しさん
2008/01/14(月) 14:54:50 Javaでバッチ処理なんてシステムを解ってないとしか言い様がない
8デフォルトの名無しさん
2008/01/14(月) 15:21:012008/01/14(月) 15:26:04
ちょっと観戦させてもらうよｗ
10デフォルトの名無しさん
2008/01/14(月) 19:46:00 Javaでもバッチ処理をしてみようというだけであって、
Javaでのバッチ処理なんて現実性がない。
実績もほとんどないだろ。
やっぱCOBOLだな。
実績ばっちり。
Javaでのバッチ処理なんて現実性がない。
実績もほとんどないだろ。
やっぱCOBOLだな。
実績ばっちり。
11デフォルトの名無しさん
2008/01/14(月) 19:53:30 http://www.atmarkit.co.jp/fjava/column/andoh/andoh37.html
これからの技術だと思うので、期待age
これからの技術だと思うので、期待age
2008/01/15(火) 01:10:13
結局バッチ処理は安定性・処理速度重視だろ？
JAVAじゃ無理だろ？
JAVAじゃ無理だろ？
2008/01/15(火) 01:47:49
Ｊａｖａは移植性高いし、ＪＣＬに取って変わらせてもいいんじゃないかな？
どうせ、ホストはＵＮＩＸにすれば、いいわけだし。
その程度のマイグレーションは出来るよねｗｗｗ
落ちコボラーには無理かｗ
どうせ、ホストはＵＮＩＸにすれば、いいわけだし。
その程度のマイグレーションは出来るよねｗｗｗ
落ちコボラーには無理かｗ
2008/01/15(火) 01:50:42
移植性はあるだろうが、安定性はどうなんだよ？
JAVAはメインフレームで走るCOBOLほど安定してんのか？
JAVAでバッチやるんなら大量データを処理するための処理とか
あるのかよ？
JAVAはメインフレームで走るCOBOLほど安定してんのか？
JAVAでバッチやるんなら大量データを処理するための処理とか
あるのかよ？
2008/01/15(火) 01:51:58
なんだ、年齢がばれそうな汎用系のＳＥくずれかよｗ
2008/01/15(火) 01:58:09
レガシーにしがみ付いてる業務系ＳＥにはスキルアップの途が既に閉ざされてる
ように聞こえてならない書き込みだなｗ
ように聞こえてならない書き込みだなｗ
2008/01/15(火) 02:03:05
JAVAで速くて安定しているバッチ処理は書けるのか？
そのための技術基盤があるのか？
それがなけりゃJAVAでバッチ処理なんてありえないだろ。
そのための技術基盤があるのか？
それがなけりゃJAVAでバッチ処理なんてありえないだろ。
2008/01/15(火) 02:11:12
分散処理の話してもしょうがなさそうだな、こりゃｗ
君が２０年以上経験してるとは思えんのでこれ以上話すまい。
では、お休みｗ
君が２０年以上経験してるとは思えんのでこれ以上話すまい。
では、お休みｗ
2008/01/15(火) 02:15:42
なんだ、まともな反論も出来ない正月休みの中房かｗ
2008/01/15(火) 02:35:58
まともな反論はできないだろう。
馬鹿につける薬はないとｗ
馬鹿につける薬はないとｗ
2008/01/15(火) 22:42:21
Javaは遅いと思うけどOracle使ってんならSQL次第、というかデータベースのチューニング次第のような気ガス。
純粋にシーケンシャルファイルの読み込みならCOBOLのほうが早そうだけど
シーケンシャルに落としてソートしてキーマッチさせてローダーなんて
そろそろ絶滅してもいいんじゃねーかと思うな。
純粋にシーケンシャルファイルの読み込みならCOBOLのほうが早そうだけど
シーケンシャルに落としてソートしてキーマッチさせてローダーなんて
そろそろ絶滅してもいいんじゃねーかと思うな。
2008/01/15(火) 23:19:44
すげぇ関係ないけど、Javaで可能だとしたら.NETでもやれるんだろうか？
2008/01/16(水) 00:03:20
これだから、プログラマー連中はお荷物だといわれる。
2008/01/16(水) 00:07:12
30年以上使い込んでるメインフレームごと落ちコボラーをインドにでも払い下げた
ほうが経営効率は1000倍はあがるな。
ほうが経営効率は1000倍はあがるな。
2008/01/16(水) 00:15:11
>22
可能だろう。
Win系でバッチとか客に殺されるかもしれんがなｗ
可能だろう。
Win系でバッチとか客に殺されるかもしれんがなｗ
2008/01/16(水) 10:04:23
電気代と、古参のSEPGを経営面から見て継続使用が可能なら、
レガシーのまんまで良いのかもな。
中小規模で新規の基幹業務システムを構築する場合は、
予算と、要求仕様にもよるが、最近じゃあサーバーで実現できそうな
話だな。
レガシーのまんまで良いのかもな。
中小規模で新規の基幹業務システムを構築する場合は、
予算と、要求仕様にもよるが、最近じゃあサーバーで実現できそうな
話だな。
27デフォルトの名無しさん
2008/01/16(水) 23:28:12 バッチはCでやるものだ
2008/01/17(木) 01:31:19
2008/01/17(木) 01:45:10
COBOLで過去に作られた業務プログラムが企業にとって資産ねぇ？
地球温暖化の要因のひとつだろｗ
地球温暖化の要因のひとつだろｗ
30デフォルトの名無しさん
2008/01/20(日) 20:10:24 SOAとbatchは似ている
31デフォルトの名無しさん
2008/01/21(月) 19:31:45 バッチのフレームワーク・・・
バッチ処理でstrutsのように使いまわせる処理ってあるか？
バッチ処理でstrutsのように使いまわせる処理ってあるか？
2008/01/25(金) 17:07:19
>>31
まあ、各会社が必要に応じて作ってんな
バッチなんて、個人で率先してフレームワークを作ろうって対象じゃないしw
データ量が中規模までだったら、COBOLなんて絶滅して構わん
大規模で遅いのが問題なんだよ
俺はCOBOL嫌いだから、Cで作るべきだと思うけど、Cはこぼらーにも
JAVAや.Net派にも不人気なんだよな～
Cが一番速度と柔軟性を兼ね備えていると思うのに・・・
まあ、各会社が必要に応じて作ってんな
バッチなんて、個人で率先してフレームワークを作ろうって対象じゃないしw
データ量が中規模までだったら、COBOLなんて絶滅して構わん
大規模で遅いのが問題なんだよ
俺はCOBOL嫌いだから、Cで作るべきだと思うけど、Cはこぼらーにも
JAVAや.Net派にも不人気なんだよな～
Cが一番速度と柔軟性を兼ね備えていると思うのに・・・
2008/01/29(火) 21:50:51
コボルはそのまんま東
34デフォルトの名無しさん
2008/02/02(土) 01:25:152008/02/02(土) 22:19:45
2008/02/03(日) 09:44:08
>>32
Cでバッチ処理書いてパフォーマンスあがる？
ファイルIOとデシマル計算がメインの金融系バッチだと
COBOLのほうが安定したパフォーマンスたたき出せると思うなあ。
あいだにSQL挟んだらそれこそC関係ないし。
ソートはCのほうが早そうだけど
Cでバッチ処理書いてパフォーマンスあがる？
ファイルIOとデシマル計算がメインの金融系バッチだと
COBOLのほうが安定したパフォーマンスたたき出せると思うなあ。
あいだにSQL挟んだらそれこそC関係ないし。
ソートはCのほうが早そうだけど
37デフォルトの名無しさん
2008/02/03(日) 12:17:062008/02/03(日) 17:34:48
???
なにが言いたいのかよくわからん???
なにが言いたいのかよくわからん???
39デフォルトの名無しさん
2008/02/03(日) 18:11:45 クリティカルなバッチ処理ならCOBOLだと思うけど、
ちょっとした処理ならJavaでもCでもなんでもいいと思う。
ただフレームワークという発想は面白い。
springbatchに期待。
ちょっとした処理ならJavaでもCでもなんでもいいと思う。
ただフレームワークという発想は面白い。
springbatchに期待。
2008/02/12(火) 01:23:14
Antとかでも簡単なバッチ処理出来そうなんだが
実績はないのか
実績はないのか
2008/02/12(火) 05:58:42
CSVからソース取ってきて、コンパイルして、Jarに固めて、デプロイ
という流れはバッチ処理と言えなくは無い。
という流れはバッチ処理と言えなくは無い。
42デフォルトの名無しさん
2008/02/16(土) 10:28:38 みなさんのお知恵をお借りしたいです。m(__ __)m
cobol + ORACLE10gです
下記のような事が可能と言われたのですが、
検証した結果無理でした。
再度、試みますが物理的に可能なんでしょうか？
手順①
INSERT
(COBOLE) PIC 9(09) COMP-3 ⇒ (ORACLE) CHAR 5
※この場合 ORACLE上では正しく表現されない事はOKとします。
手順②次に(上記の手順後)
(ORACLE) CHAR 5 ⇒ (COBOLE) PIC 9(09) COMP-3
この場合、INSERT時のCOBOLで入力した値が
正しく表現されると言われたのですが・・・
本当でしょうか？
検証した時には、
手順①
111111111 ⇒ 11111
手順②
11111 ⇒ 000012345
このように 再取得した値が000012345となり
当初の111111111ではなくなります。
cobol + ORACLE10gです
下記のような事が可能と言われたのですが、
検証した結果無理でした。
再度、試みますが物理的に可能なんでしょうか？
手順①
INSERT
(COBOLE) PIC 9(09) COMP-3 ⇒ (ORACLE) CHAR 5
※この場合 ORACLE上では正しく表現されない事はOKとします。
手順②次に(上記の手順後)
(ORACLE) CHAR 5 ⇒ (COBOLE) PIC 9(09) COMP-3
この場合、INSERT時のCOBOLで入力した値が
正しく表現されると言われたのですが・・・
本当でしょうか？
検証した時には、
手順①
111111111 ⇒ 11111
手順②
11111 ⇒ 000012345
このように 再取得した値が000012345となり
当初の111111111ではなくなります。
43デフォルトの名無しさん
2008/02/16(土) 20:17:40 バッチ処理はＳＡＳが一番だ。費用対効果は無視ナ。
2008/02/18(月) 02:21:23
ttp://pc11.2ch.net/test/read.cgi/tech/1195400163/65
45はりせん
2008/03/08(土) 08:35:43 多態性オブジェクトを何とか理解して、
「リストにぶら下げたオブジェクトにイベントを渡す」
がイメージできたときに（塚越さんの本は分かりやすい）、
オブジェクト指向でバッチやるとロジックがシンプルに
なるな、と気がつき、Delphiでやってみるとなかなかよさげ。
（というか、これをやるためにコンパイラを買ったようなもの。）
で、ＩＢＭがＪａｖａを熱心にやっているので、Ｊａｖａにアレンジして
ＩＢＭユーザー研究会の論文に出したわけです。
IBMのユーザー研なので、本文ではDelphiと書けずObjectPascal。
「Ｉ社」と書いたのは、当時のINPRISE社（ボーランド）のことだけど、
読んだ人はIBMと勘違いしてくれるだろうと期待してのこと。
ただし、ここで最高の副産物。Ｊａｖａのプラットフォームにこだわらない
という特性は、ＰＣで作ったものがＭａｃで走る、ということよりも、ＰＣで
やっていた業務がスケールアップしても、ＵＮＩＸなりメインフレームで
プログラムを走らせればよい、というアイデア。でも一般的にならなかった。
同じようなことは、同時期にテンアートニの社長もどっかで書いていた。
（はっきり意識していたかはよく分からないけど。）
「リストにぶら下げたオブジェクトにイベントを渡す」
がイメージできたときに（塚越さんの本は分かりやすい）、
オブジェクト指向でバッチやるとロジックがシンプルに
なるな、と気がつき、Delphiでやってみるとなかなかよさげ。
（というか、これをやるためにコンパイラを買ったようなもの。）
で、ＩＢＭがＪａｖａを熱心にやっているので、Ｊａｖａにアレンジして
ＩＢＭユーザー研究会の論文に出したわけです。
IBMのユーザー研なので、本文ではDelphiと書けずObjectPascal。
「Ｉ社」と書いたのは、当時のINPRISE社（ボーランド）のことだけど、
読んだ人はIBMと勘違いしてくれるだろうと期待してのこと。
ただし、ここで最高の副産物。Ｊａｖａのプラットフォームにこだわらない
という特性は、ＰＣで作ったものがＭａｃで走る、ということよりも、ＰＣで
やっていた業務がスケールアップしても、ＵＮＩＸなりメインフレームで
プログラムを走らせればよい、というアイデア。でも一般的にならなかった。
同じようなことは、同時期にテンアートニの社長もどっかで書いていた。
（はっきり意識していたかはよく分からないけど。）
46デフォルトの名無しさん
2008/03/08(土) 16:00:04 Javaで帳票のバッジ処理するのは変なんですか？
47デフォルトの名無しさん
2008/03/08(土) 18:19:38 >>46
狂気の沙汰
狂気の沙汰
48デフォルトの名無しさん
2008/03/08(土) 18:29:54 帳票のバッジ処理って具体的にどんな処理？
49デフォルトの名無しさん
2008/03/10(月) 20:57:2850デフォルトの名無しさん
2008/04/17(木) 23:09:5351デフォルトの名無しさん
2008/06/06(金) 23:17:37 トランザクションの量によりますよね。
業務アプリはサーバーサイドjavaが大半だからバッチも含めて
ALLjavaも可能だけど、チューニング労力を考えると現実的
では無いような気がします。
大規模案件やった時はどうしても処理量が多いものはPL/SQL
で構築していました。
業務アプリはサーバーサイドjavaが大半だからバッチも含めて
ALLjavaも可能だけど、チューニング労力を考えると現実的
では無いような気がします。
大規模案件やった時はどうしても処理量が多いものはPL/SQL
で構築していました。
52デフォルトの名無しさん
2008/06/09(月) 14:07:452008/06/18(水) 19:40:41
54デフォルトの名無しさん
2008/07/15(火) 20:53:1155デフォルトの名無しさん
2008/07/22(火) 21:18:24 TextSS
2008/08/19(火) 22:35:02
＞バッチのフレームワーク
千手とかJP1とか。
運用管理システムのアーキテクチャに合わせて設計するだろ。
運用から見ればCOBOLだろうがJAVAだろうが変わりないけど、
シェルスクリプト内でループ回すのだけはやめて欲しい。遅すぎる(TT)
大規模バッチで重要なのは朝までに処理が終わるかどうか。
COBOLでも遅いものは遅い。
先行後続関係がくもの巣になってるほど終わらなくなるし、性能改善も難しい。
千手とかJP1とか。
運用管理システムのアーキテクチャに合わせて設計するだろ。
運用から見ればCOBOLだろうがJAVAだろうが変わりないけど、
シェルスクリプト内でループ回すのだけはやめて欲しい。遅すぎる(TT)
大規模バッチで重要なのは朝までに処理が終わるかどうか。
COBOLでも遅いものは遅い。
先行後続関係がくもの巣になってるほど終わらなくなるし、性能改善も難しい。
57デフォルトの名無しさん
2008/09/12(金) 11:03:42 【IT】「COBOLは現役バリバリ」、東京海上日動がシステム全面再構築でCOBOLを選んだワケ 開発者向けセミナー「XDev2008」 [08/09/08]
http://gimpo.2ch.net/test/read.cgi/bizplus/1220822531/
http://gimpo.2ch.net/test/read.cgi/bizplus/1220822531/
58デフォルトの名無しさん
2008/09/12(金) 21:37:00 バリバリ伝説
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 日中関係改善は「下手をすると10年かかる」 トランプを全面信頼できない高市官邸の苦悩★3 [ぐれ★]
- 牛丼チェーン店で5杯食べ終えて「支払えない」…詐欺容疑で逮捕の男「どうしても腹がすいて」 甲府 [蚤の市★]
- 【東京】赤坂サウナ火事2人死亡 サウナ室のドアノブ外れ閉じ込められた可能性 ★10 [nita★]
- 【赤坂サウナ火災】非常ベル電源「2年前から入れていない」、押した形跡も [ぐれ★]
- WBCでパブリックビューイング ネットフリックス、自治体と連携 [ひかり★]
- 特攻機と同じ名称「桜花中」、福岡・大牟田市の新設中学校名に異論 市民団体が再考申し入れ ★3 [少考さん★]
- 【高市新幹線】 秋田商工会「秋田新幹線に新線を建設､秋田空港に新駅を造ってくれ！」 JR東日本「(知らんがな) 想いは受け止めました」 [485983549]
- 石破茂＜ーこの人、健常者だったのになんですぐに総理大臣を辞めさせられちゃったの？🥺 [153736977]
- 糞スレを無理やり神スレに変えるスレ
- 【高市悲報】辻元、追加資料公開。官僚が「頼むからこれ踏襲して」と台湾問題に関する歴代総理答弁を渡していた😰 [359965264]
- 高市応援団「中国なんていらねえ！」高市「日本にとって中国は重要な隣国」 [931948549]
- 「電気ショックで男性管理職への生理痛体験推進」条例、成立 反対したのが127人中参政党とさとうさおりと他2名のみｗｗｗｗｗｗｗｗｗ [384232311]