5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

【COBOLから】バッチ処理【Javaまで】

1 :デフォルトの名無しさん:2008/01/12(土) 16:38:37
最近は、Javaでもバッチ処理を書くんですなぁ

2 :デフォルトの名無しさん:2008/01/12(土) 16:42:52
http://hp.vector.co.jp/authors/VA015862/javabtch.html

3 :デフォルトの名無しさん:2008/01/12(土) 16:45:44
http://hp.vector.co.jp/authors/VA015862/javabtch.html

4 :デフォルトの名無しさん: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:01
>>7
時代遅れのおっさんw
用なしwww

9 :デフォルトの名無しさん:2008/01/14(月) 15:26:04
ちょっと観戦させてもらうよw

10 :デフォルトの名無しさん:2008/01/14(月) 19:46:00
Javaでもバッチ処理をしてみようというだけであって、
Javaでのバッチ処理なんて現実性がない。
実績もほとんどないだろ。
やっぱCOBOLだな。
実績ばっちり。

11 :デフォルトの名無しさん:2008/01/14(月) 19:53:30
http://www.atmarkit.co.jp/fjava/column/andoh/andoh37.html
これからの技術だと思うので、期待age

12 :デフォルトの名無しさん:2008/01/15(火) 01:10:13
結局バッチ処理は安定性・処理速度重視だろ?
JAVAじゃ無理だろ?

13 :デフォルトの名無しさん:2008/01/15(火) 01:47:49
Javaは移植性高いし、JCLに取って変わらせてもいいんじゃないかな?
どうせ、ホストはUNIXにすれば、いいわけだし。
その程度のマイグレーションは出来るよねwww
落ちコボラーには無理かw






14 :デフォルトの名無しさん:2008/01/15(火) 01:50:42
移植性はあるだろうが、安定性はどうなんだよ?
JAVAはメインフレームで走るCOBOLほど安定してんのか?

JAVAでバッチやるんなら大量データを処理するための処理とか
あるのかよ?

15 :デフォルトの名無しさん:2008/01/15(火) 01:51:58
なんだ、年齢がばれそうな汎用系のSEくずれかよw

16 :デフォルトの名無しさん:2008/01/15(火) 01:58:09
レガシーにしがみ付いてる業務系SEにはスキルアップの途が既に閉ざされてる
ように聞こえてならない書き込みだなw

17 :デフォルトの名無しさん:2008/01/15(火) 02:03:05
JAVAで速くて安定しているバッチ処理は書けるのか?
そのための技術基盤があるのか?
それがなけりゃJAVAでバッチ処理なんてありえないだろ。

18 :デフォルトの名無しさん:2008/01/15(火) 02:11:12
分散処理の話してもしょうがなさそうだな、こりゃw
君が20年以上経験してるとは思えんのでこれ以上話すまい。
では、お休みw

19 :デフォルトの名無しさん:2008/01/15(火) 02:15:42
なんだ、まともな反論も出来ない正月休みの中房かw


20 :デフォルトの名無しさん:2008/01/15(火) 02:35:58
まともな反論はできないだろう。
馬鹿につける薬はないとw

21 :デフォルトの名無しさん:2008/01/15(火) 22:42:21
Javaは遅いと思うけどOracle使ってんならSQL次第、というかデータベースのチューニング次第のような気ガス。

純粋にシーケンシャルファイルの読み込みならCOBOLのほうが早そうだけど
シーケンシャルに落としてソートしてキーマッチさせてローダーなんて
そろそろ絶滅してもいいんじゃねーかと思うな。

22 :デフォルトの名無しさん:2008/01/15(火) 23:19:44
すげぇ関係ないけど、Javaで可能だとしたら.NETでもやれるんだろうか?

23 :デフォルトの名無しさん:2008/01/16(水) 00:03:20
これだから、プログラマー連中はお荷物だといわれる。

24 :デフォルトの名無しさん:2008/01/16(水) 00:07:12
30年以上使い込んでるメインフレームごと落ちコボラーをインドにでも払い下げた
ほうが経営効率は1000倍はあがるな。

25 :デフォルトの名無しさん:2008/01/16(水) 00:15:11
>22
可能だろう。
Win系でバッチとか客に殺されるかもしれんがなw

26 :デフォルトの名無しさん:2008/01/16(水) 10:04:23
電気代と、古参のSEPGを経営面から見て継続使用が可能なら、
レガシーのまんまで良いのかもな。

中小規模で新規の基幹業務システムを構築する場合は、
予算と、要求仕様にもよるが、最近じゃあサーバーで実現できそうな
話だな。



27 :デフォルトの名無しさん:2008/01/16(水) 23:28:12
バッチはCでやるものだ

28 :デフォルトの名無しさん:2008/01/17(木) 01:31:19
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20020628/2/

29 :デフォルトの名無しさん:2008/01/17(木) 01:45:10
COBOLで過去に作られた業務プログラムが企業にとって資産ねぇ?
地球温暖化の要因のひとつだろw


30 :デフォルトの名無しさん:2008/01/20(日) 20:10:24
SOAとbatchは似ている

31 :デフォルトの名無しさん:2008/01/21(月) 19:31:45
バッチのフレームワーク・・・
バッチ処理でstrutsのように使いまわせる処理ってあるか?

32 :デフォルトの名無しさん:2008/01/25(金) 17:07:19
>>31
まあ、各会社が必要に応じて作ってんな
バッチなんて、個人で率先してフレームワークを作ろうって対象じゃないしw

データ量が中規模までだったら、COBOLなんて絶滅して構わん
大規模で遅いのが問題なんだよ

俺はCOBOL嫌いだから、Cで作るべきだと思うけど、Cはこぼらーにも
JAVAや.Net派にも不人気なんだよな〜
Cが一番速度と柔軟性を兼ね備えていると思うのに・・・

33 :デフォルトの名無しさん:2008/01/29(火) 21:50:51
コボルはそのまんま東

34 :デフォルトの名無しさん:2008/02/02(土) 01:25:15
http://itpro.nikkeibp.co.jp/article/NEWS/20080129/292387/

35 :デフォルトの名無しさん:2008/02/02(土) 22:19:45
>>32
各会社で作りこむ必要が無いバッチの処理って何だろう?
フレームワークということはバッチ処理の定型的な処理が
あるってことなんだろうけど。

36 :デフォルトの名無しさん:2008/02/03(日) 09:44:08
>>32
Cでバッチ処理書いてパフォーマンスあがる?
ファイルIOとデシマル計算がメインの金融系バッチだと
COBOLのほうが安定したパフォーマンスたたき出せると思うなあ。
あいだにSQL挟んだらそれこそC関係ないし。

ソートはCのほうが早そうだけど

37 :デフォルトの名無しさん:2008/02/03(日) 12:17:06
>>36
何件レコードのソート考えて書いてる?
ソートロジックかいたCだから早いってか?

さらし上げ

38 :デフォルトの名無しさん:2008/02/03(日) 17:34:48
???
なにが言いたいのかよくわからん???

39 :デフォルトの名無しさん:2008/02/03(日) 18:11:45
クリティカルなバッチ処理ならCOBOLだと思うけど、
ちょっとした処理ならJavaでもCでもなんでもいいと思う。

ただフレームワークという発想は面白い。
springbatchに期待。

40 :デフォルトの名無しさん:2008/02/12(火) 01:23:14
Antとかでも簡単なバッチ処理出来そうなんだが
実績はないのか

41 :デフォルトの名無しさん: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とします。

手順A次に(上記の手順後)
(ORACLE) CHAR 5 ⇒ (COBOLE) PIC 9(09) COMP-3
この場合、INSERT時のCOBOLで入力した値が
正しく表現されると言われたのですが・・・
本当でしょうか?

検証した時には、
手順@
111111111 ⇒ 11111
手順A
11111 ⇒ 000012345

このように 再取得した値が000012345となり
当初の111111111ではなくなります。

43 :デフォルトの名無しさん:2008/02/16(土) 20:17:40
バッチ処理はSASが一番だ。費用対効果は無視ナ。

44 :デフォルトの名無しさん: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がJavaを熱心にやっているので、Javaにアレンジして
IBMユーザー研究会の論文に出したわけです。
 IBMのユーザー研なので、本文ではDelphiと書けずObjectPascal。
「I社」と書いたのは、当時のINPRISE社(ボーランド)のことだけど、
読んだ人はIBMと勘違いしてくれるだろうと期待してのこと。

 ただし、ここで最高の副産物。Javaのプラットフォームにこだわらない
という特性は、PCで作ったものがMacで走る、ということよりも、PCで
やっていた業務がスケールアップしても、UNIXなりメインフレームで
プログラムを走らせればよい、というアイデア。でも一般的にならなかった。
 同じようなことは、同時期にテンアートニの社長もどっかで書いていた。
(はっきり意識していたかはよく分からないけど。)

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:28
http://www.atmarkit.co.jp/fjava/rensai4/javabatch01/javabatch01_1.html

50 :デフォルトの名無しさん:2008/04/17(木) 23:09:53
http://www.atmarkit.co.jp/fjava/rensai4/javabatch02/javabatch02_1.html

51 :デフォルトの名無しさん:2008/06/06(金) 23:17:37
トランザクションの量によりますよね。
業務アプリはサーバーサイドjavaが大半だからバッチも含めて
ALLjavaも可能だけど、チューニング労力を考えると現実的
では無いような気がします。
大規模案件やった時はどうしても処理量が多いものはPL/SQL
で構築していました。

52 :デフォルトの名無しさん:2008/06/09(月) 14:07:45
http://www.atmarkit.co.jp/fjava/rensai4/javabatch03/javabatch03_1.html

53 :デフォルトの名無しさん:2008/06/18(水) 19:40:41
>>48
ファイル読んで帳票出力するんだべ?
違うの?

54 :デフォルトの名無しさん:2008/07/15(火) 20:53:11
http://www.infoq.com/jp/news/2008/07/spring-batch

55 :デフォルトの名無しさん:2008/07/22(火) 21:18:24
TextSS


56 :デフォルトの名無しさん:2008/08/19(火) 22:35:02
>バッチのフレームワーク
千手とか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/


58 :デフォルトの名無しさん:2008/09/12(金) 21:37:00
バリバリ伝説

59 :デフォルトの名無しさん:2008/09/15(月) 21:12:18
これは恋のおまもりカキコです。このカキコを3ヵ所以上の
所に貼り付けると。。。
いままでずっと
片思いだった人と
両思いになれちゃったり☆彼氏・彼女が
できちゃったり☆
と、他にもいい事がたぁ〜っくさんおこります!!
私の姉がこれを
冗談でやってみたところ・・・
その3日後好きな人に告られました!!
これを信じるか
信じないかは
あなたしだいですよっっ☆
みなさんも
良い恋愛を・・・!!




60 :デフォルトの名無しさん:2008/09/28(日) 02:38:28
>>57
「COBOLは現役バリバリ」 この言葉から加齢臭がする。

全面再構築でシステム構成のシンプル化を目指してるはずなのに、なんでJava+COBOLなんだよ。

でCOBOLがシンプルで習得スピードの速さに繋がり人材育成にも有効と言いながら。
なんで若手はJavaでベテランはCOBOLで開発してるんだよ。

どうせ取締役の私情でCOBOL使うことになったんだろ。無駄に作業をふやしてんじゃねえよ。

61 :デフォルトの名無しさん:2008/10/13(月) 19:02:08
>トランザクションの量によりますよね。
>業務アプリはサーバーサイドjavaが大半だからバッチも含めて
>ALLjavaも可能だけど、チューニング労力を考えると現実的
>では無いような気がします。

と、>>51氏が申しております。

62 :デフォルトの名無しさん:2008/12/24(水) 02:11:26
【.cmd】 バッチファイルスクリプト %4 【.bat】
http://pc11.2ch.net/test/read.cgi/tech/1229955189/

63 :デフォルトの名無しさん:2009/01/22(木) 12:32:07
こぼるの良さを知らない若造が!!
こぼるはオヤジ達が似合う!!
こぼる最高!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

64 :デフォルトの名無しさん:2009/02/21(土) 02:29:53
map 系の処理が簡単に書けない COBOL も Java も糞じゃねぇの?
今時、クロージャがなくても許される言語って Fortran だけだよね
# Fortran は並列化構文があるので許さざるを得ない


65 :デフォルトの名無しさん:2009/02/26(木) 00:40:14
なんかみんな憐れ
痛々しい

66 :デフォルトの名無しさん:2009/02/27(金) 16:26:42
>>64 COBOLはしょうがないだろFortranと同じ世代だが元々の役割ちがうしFortranの並列化構文だってコンパイラーにその後付加されたのだろ


67 :デフォルトの名無しさん:2009/04/13(月) 20:32:36
計算はCOBOL、計算結果のメール送信にはjavaとか・・・

68 :デフォルトの名無しさん:2009/04/15(水) 23:18:02
そうか

69 :にゃあ:2009/05/04(月) 03:25:02
いまだ!69ゲットォォォォ!!! オマンコベロベロナメダーチンチンナメテー
 ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄    (´´
                  ∧∧       (´⌒(´
           ↑⊂(゚ー゚*)≡≡≡(´⌒;;;≡≡≡
        ⊆⊂´ ̄ ⊂ソ  (´⌒(´⌒;;
           ̄ ̄ ̄   ズザーーーーーッ

70 :デフォルトの名無しさん:2009/05/22(金) 21:45:07
EASY PULSについて聞きたいことがあるんだが、スレがない・・・
ここで質問してもいいのかな?

71 :デフォルトの名無しさん:2009/05/23(土) 09:01:06
富士通汎用機のツールか?とりあえず書いてみることよ。

72 :デフォルトの名無しさん:2009/05/23(土) 09:10:18
>>42 すごい亀だけど解決したんじゃろか?
Cobol質問スレねーの?


73 :デフォルトの名無しさん:2009/05/23(土) 09:38:59
以下の出力の違いを知りたいんだ。。。

例えば、SAMで頭4桁がX'123F'のデータがあるとして、
それをレポートに出力。


FILEA
A-DATA 1 2 P

W-DATA W 3 N


JOB
W-DATA = A-DATA
PRINT


と書いたとき、W-DATAの中身が012になっちゃうんだけど、
そーゆー仕様なの?
W-DATAを4桁にすると中身は0123。

ちなみに、データの頭が、'123C'や'123D'の時はちゃんと123になる。

EASY TRIVは平気なんだけど、PLUSは絶対値は勝手に埋められるのかな?


74 :デフォルトの名無しさん:2009/05/23(土) 11:18:26
今、実機で確認出来ませんが仕様と思われます。
以下のように推測します。
【原因】
B-DATAに出力を期待するデータは3桁であるのに、途中経路であるA-DATAを2桁で定義している。
状況により結果がことなるのはEASYのデータ切り捨て仕様に起因する(切り捨てが行われるタイミング)

【対処法】
A-DATAを3桁で定義する。




75 :デフォルトの名無しさん:2009/05/23(土) 11:30:34
>>74
だってパックだよ?
普通に出力したら化けるから、わざわざNタイプに移してから出力してるんだけど。。


76 :デフォルトの名無しさん:2009/05/23(土) 12:20:54
桁数あってないのが原因だと思うんだが。

77 :デフォルトの名無しさん:2009/05/23(土) 12:27:26
もしかしてパックだから3桁の半分の2桁にしたってオチ?文字数指定だから3のままでいいんだが、まさかそういうことじゃないだろうな

78 :デフォルトの名無しさん:2009/05/23(土) 12:43:05
そうじゃないだろ?

データとしては、

..
13
2F

って入ってるだろ?
これを例えばA、2桁で定義したら、「..」、P、2桁で定義したら「123F」
P、3桁なら隣の関係ないエリアまでかかるじゃねーか


79 :デフォルトの名無しさん:2009/05/23(土) 13:42:18
パックはそんなデータの持ち方しないはず。
ともかく3桁で定義して一度実行をすすめるわ。

80 :デフォルトの名無しさん:2009/05/23(土) 13:45:39
普通に開いたら..でしか見れないだろ?
HEXモードにしたら>>78みたいに表示されるよな?
実際の値は開かないと分からない。
符号がなく絶対値だと勝手に桁埋めされるのかね・・・

81 :デフォルトの名無しさん:2009/05/29(金) 21:36:03
ワークベンチ(Eqlipse?)の日本語COBOL?使ってるんだが、
これってカラム位置とか揃えないといけないのか?
PG作ったら、イコールや符号、→の位置全部揃えろとか言われたから、
面倒だが、上から下まで全部揃えた。

次作った時は、最初から揃えた訳だが、今度はイコールや符号の位置がおかしいとか言い出して
俺の見てる前で半角スペースとDELキーで上から下までチマチマと位置をズラし始めた。
挙句の果てにここは1行空けるべきだとか言出だす。
他の人のソース見たら、普通に揃ってないわけだが…

さらには、EASYで作った検証ツールもIFなどを考慮して
イコールと符号の位置を揃えろとか言ってくるんだが
これはマジなわけ?

82 :デフォルトの名無しさん:2009/05/30(土) 00:56:03
easyって小数点とか、割り算の余りとか制御できないの?

83 :デフォルトの名無しさん:2009/05/30(土) 03:12:11
>>81の言っていることは釣りだよな?
あんまりCOBOLの事は知らないんだが、なんか言ってることを想像したらフイタ

84 :デフォルトの名無しさん:2009/06/06(土) 19:06:06
COBOLには文法上、カラムの縛りは確かにあるんだが
コードの大半を費やすことになるB領域と呼ばれるものは
行番号を除いて6カラム目「以降」に書くもので、インデントとかはちゃんとするのが普通

ただ、最近の言語と違って行同士の縦を揃える習慣は確かに存在するよ
宣言部分は特にそうだし、処理を書く部分もカラム揃える規約があったりとか

85 :デフォルトの名無しさん:2009/06/21(日) 23:55:24
教えて厨で申し訳ないんだが、
汎用機そのもののスレは、何板にあるかな?
2ちゃんのPC等のカテゴリーは初心者かつ
システム部門に異動したてなんで、探しても見つからない…

86 :デフォルトの名無しさん:2009/06/22(月) 02:32:57
>>85
http://find.2ch.net/?STR=%A5%E1%A5%A4%A5%F3%A5%D5%A5%EC%A1%BC%A5%E0&COUNT=10&TYPE=TITLE&BBS=2ch

87 :デフォルトの名無しさん:2009/06/29(月) 23:41:10
Javaでバッチ処理を組むことになったんだけどよいフレームワークってありますかね?
バッチ処理の内容は、CSVまたは固定長のファイルからデータ読み込んでDBへ格納するという感じです。
ファイル内のデータは1件の場合もあれば、1000件の場合もあります。

88 :デフォルトの名無しさん:2009/06/30(火) 22:58:17
バッチスケジューラも作るの?

作らないなら、特にフレームワークはいらないと思うけど。
DBアクセスのところだけ、iBatisかDbUtilsでも使えば?
後は、起動部分は自分でミニフレームワークでも作って、
引数の扱いや例外処理、ログなんかを共通化して。

Webアプリに付随したバッチ処理なら、Webサービスで窓口作ると良いかもね。
デプロイが一括で出来るし、HTMLで叩けるから、ロードバランサで負荷分散とか出来るし。
でも、せいぜい1,000件なら負荷分散の必要は無いかな。

89 :デフォルトの名無しさん:2009/07/01(水) 22:11:10
easyの事なんですが質問。

easyで、2バイト文字を、コードで見た値でプラスしたりマイナスしたりしたいんですが。。

例えばヘキサで見た値が、X’1234’だったら、X’1235’とか、X’1233’とかに足し算引き算をしたいんだけど、、、

90 :デフォルトの名無しさん:2009/07/02(木) 20:50:29
Quartz
使っている人いる?

91 :デフォルトの名無しさん:2009/07/04(土) 19:41:46
>>90
http://imepita.jp/20090628/565860
  サテト
  ∧∧
 (・ω・ )
 _| ⊃/(__
/ ヽ-(___/
 ̄ ̄ ̄ ̄ ̄ ̄


92 :87:2009/07/04(土) 23:06:45
>>88
亀レスすません。
バッチスケジューラは作りません。Windowsのタスク使いますんで。

なるほど。DBアクセスだけっすか。
フレームワーク使って標準的なバッチ処理を組むように指令が
出てたんで全てをフレームワークでやろうと思ってました。
確かに例外処理やログは自作フレームワークの方が自由度がありますね。

ありがとした。

93 :デフォルトの名無しさん:2009/07/05(日) 11:39:03
>>91
http://imepita.jp/20090704/028160
   ネヨ
  ∧∧
  (´・ω)
 _|⊃/(___
/ ヽ_(____/
 ̄ ̄ ̄ ̄ ̄ ̄ ̄


94 :デフォルトの名無しさん:2009/09/20(日) 01:12:02
【コンピュータ】まだまだ現役:プログラミング言語のCOBOLが誕生50周年 [09/09/19]
ttp://anchorage.2ch.net/test/read.cgi/bizplus/1253376523/


95 :デフォルトの名無しさん:2010/01/04(月) 11:05:35
あげて聞いてみる。

俺も >>40 と同じこと思ったんだが、
Ant でジョブネットを定義してバッチ業務やってる実例が知りたいなあ。

Ant でジョブネットを組んで Quartz でジョブスケジューリングできれば、
OSSプロダクトだけで、業務システムで必要なジョブ制御が一通りできそうな
気もするんだけど、どうなんだろ?

96 :デフォルトの名無しさん:2010/01/05(火) 16:08:22
技術的にできたとして、
誰が嬉しいの?

97 :95:2010/01/05(火) 20:41:49
うーん……

コマンドプロンプト+ atコマンド とか シェルスクリプト+cron とかで組むと
先行ジョブ、後続ジョブとかの依存関係の制御が地味にめんどいけど、
でも JP1 とか千手とか Tivoli とか買うのもなぁ、タダで幸せになりたいなぁ……

みたいな人って、もしかして俺だけなんだろうか。

とりあえず、まずは自分でいろいろ試してみます……

98 :デフォルトの名無しさん:2010/01/10(日) 00:46:35
まぁ確かにビルド自体 バッチ処理だからantやMSBuildはそういう風に活用するのがいいいかもしれない。

エンドユーザがGUIで簡単に運用状況確認するとか、そういうがそれほど問題にならないならいいと思うけど。

99 :デフォルトの名無しさん:2010/01/13(水) 00:07:00
すいません、COBOLで教えてください。

NetCobolで既存ファイルの削除をしたいんですが、
どうやれば可能でしょうか?

サーバーはWindowsなのでAPIなんかででも、出来たら
御願いします。

100 :デフォルトの名無しさん:2010/01/13(水) 09:48:02
>>99
使用手引書にちゃんとあるじゃないか。読めよタダなんだし。
http://software.fujitsu.com/jp/manual/fm/b298c2606/b1jw6201/01/cobuw.pdf

--------------------------------------------------------------
CALL "COB_FILE_DELETE" USING BY REFERENCE COBF-INF.
--------------------------------------------------------------
呼出し時のデータ設定 COBF-INPUT-FILENAME:
削除するファイルのパス名を指定します。
復帰コード
本関数からの復帰コードは、特殊レジスタPROGRAM-STATUSを使用して受け取ります。


― ファイル名にワイルドカード(?,*)を指定することはできません。
C:¥INFILEを削除する
--------------------------------------------------------------------
MOVE LOW-VALUE TO COBF-INF.
MOVE "C:¥INFILE" TO COBF-INPUT-FILENAME.
CALL "COB_FILE_DELETE" USING BY REFERENCE COBF-INF. --------------------------------------------------------------------

101 :デフォルトの名無しさん:2010/01/17(日) 22:06:30
思うがバッチ処理ってのは、いつかはリアルタイムになるのかな
いまはまだコンピュータの性能や制約があって、バッチ処理でしか方法ないけど。
いずれ処理時間という問題が解放されたらすべて即時計算の世界になるもんかね

そういう世界になったらもっとすごいバッチ処理ができるかもしれんけどw

102 :デフォルトの名無しさん:2010/01/17(日) 22:15:09
黙れバカ

103 :デフォルトの名無しさん:2010/01/17(日) 22:21:55
どの辺が馬鹿か説明してくれよ おばかさん

104 :デフォルトの名無しさん:2010/01/17(日) 22:35:08
>>101
自分で何を言ってんのか、わかってのかよwww

105 :デフォルトの名無しさん:2010/01/25(月) 23:07:20
バッチ処理をJavaで作成する場合、
DBサーバかAPサーバのどっちにプログラムを配置するのが普通?


106 :デフォルトの名無しさん:2010/01/26(火) 02:50:03
>>105
COBOLで作成する場合と一緒だよ

107 :デフォルトの名無しさん:2010/01/26(火) 22:30:11
COBOLはどっち?

108 :デフォルトの名無しさん:2010/02/03(水) 01:31:30
>>100
>>99
>使用手引書にちゃんとあるじゃないか。読めよタダなんだし。
>http://software.fujitsu.com/jp/manual/fm/b298c2606/b1jw6201/01/cobuw.pdf
コボラーはマニュアルも読めないのかw

109 :デフォルトの名無しさん:2010/02/08(月) 22:35:38
WebからJavaで作成したバッチを起動するとき、
そのたびに別のプロセスとして動かしてたらやばい?

110 :デフォルトの名無しさん:2010/02/09(火) 00:04:22
>>109
エロイ人がServletで別プロセス立てちゃ駄目だって言ってた気がする

111 :デフォルトの名無しさん:2010/02/10(水) 01:19:10
理由が知りたいなぁ。やっちゃってるから。

112 :デフォルトの名無しさん:2010/02/11(木) 00:04:24
Servletではなく、バッチが別々のプロセスとなる設計は問題ありますか?

113 :デフォルトの名無しさん:2010/02/11(木) 05:35:58
Java辞めればすべて解決

114 :デフォルトの名無しさん:2010/02/11(木) 12:01:25
>>112
悩んでるならSpringBatchとか見てみな、ヒントにはなると思うよ

115 :デフォルトの名無しさん:2010/02/11(木) 15:34:34
SpringBatch見たところ、別プロセスにせず別スレッドとしているようですね。。

オンラインバッチ作るときは、直接Shellコールではなく。
JOBテーブル実行依頼テーブルのようなものを、監視するデーモンを用意して
各JOBは別スレッドとして動かした方がいいのかな

116 :デフォルトの名無しさん:2010/02/11(木) 16:35:26
Javaだけで完結してるならスレッドでやればいいと思うが、
バッチ処理はJNIとかも使う要件も出るものだから、
VMを保護するためにもプロセスで分けた方が安全だと思う。

117 :デフォルトの名無しさん:2010/02/11(木) 19:05:58
VMを別にするとなると直接シェルキックですかね・

118 :デフォルトの名無しさん:2010/02/13(土) 11:26:46
リカバリの一般的な方針は?

119 :デフォルトの名無しさん:2010/02/13(土) 13:20:32
リアルタイムバッチか定期バッチかによって変わってくるとは思うけど、外部I/Oのポイントでのバックアップは必須じゃないかな

120 :デフォルトの名無しさん:2010/02/13(土) 15:29:23
基本的に1バッチ処理で、1トランザクションとすれば
リカバリは簡単?

121 :デフォルトの名無しさん:2010/05/25(火) 15:01:03

COBOL誕生50周年
http://iiyu.asablo.jp/blog/2010/05/25/5111701


122 :デフォルトの名無しさん:2010/10/17(日) 02:16:34
RDB使うならバッチは基本的にストアドだろ

123 :デフォルトの名無しさん:2010/11/17(水) 20:46:51
>>122
いや、分野や規模によるぞ。裏で定期バッチは意外に多い。
歴史が長いから、細かいテクニックも知られてるし。

124 :デフォルトの名無しさん:2011/03/09(水) 23:01:17.86
ObjectWorks+ ってどうなんだ?

125 :デフォルトの名無しさん:2011/05/07(土) 14:43:17.53
COBOLで書けばすべて数十年前に解決済みの問題を、
わざわざJavaで引き起こしては解決、の作業に何の意味があるのか

126 :デフォルトの名無しさん:2011/05/08(日) 02:25:58.88
COBOLでやってきたバッチ処理なんて、
・データ編集
・マッチング
・帳票出力
なんてなもんだと思うがデータ編集とマッチングは
mdbや市販のETLツールで置き換えられるし
帳票ツールもGUIで帳票作れるものに置き換えられるから
それらをバッチファイルで順番に実行されるように組めば
Jaba(っていうか、プログラム言語自体)なんか使う
必要ないんじゃないの?


127 :デフォルトの名無しさん:2011/05/08(日) 04:48:59.04
その変なツール類が、エンハンス停止とかになるので
またCOBOLに戻ってくる訳ですよ。

128 :デフォルトの名無しさん:2011/05/08(日) 12:12:30.44
バッチで帳票出力とか未だに需要あるの?
COBOL→javaが騒がれてる理由はメンテ要員の高齢化でしょ
若いのはCOBOL近づかないしどんどん人がいなくなっていく

129 :デフォルトの名無しさん:2011/05/08(日) 12:50:14.34
官と商社と銀行がすべて無くなれば需要は減るかもな

130 :デフォルトの名無しさん:2011/05/08(日) 13:40:31.13
官庁と銀行は未だに帳票がとっても大好き。
某証券会社など、取り引き明細をわざわざ横型の紙に表裏上下反対に印刷して見易いなぞと悦に入ってる始末。

131 :デフォルトの名無しさん:2011/05/08(日) 21:01:48.22
帳票出力の需要聞いてるわけじゃないんだがな・・・
帳票はあるのは当たり前として「バッチで」必要とされてんのか?

132 :デフォルトの名無しさん:2011/05/08(日) 21:44:38.40
伝統を軽視する奴は許さないよ

133 :デフォルトの名無しさん:2011/05/09(月) 01:08:14.25
>>131
バッチ以外で帳票なんて必要?

134 :デフォルトの名無しさん:2011/05/09(月) 19:19:35.74
帳票てPDFでセキュリティロックして、サーバに保存が普通じゃないのか。

135 :デフォルトの名無しさん:2011/05/16(月) 01:42:01.59
>>131
それはバッチ処理が不要と聞いているのか?
それとも、バッチ処理内で帳票作る必要はないと言ってるのか?
どちらにしても、一処理で何十万件ものデータを処理して帳票イメージを作り、印刷出来るなら、そんな不要になるだろう。
だけど、現状は一瞬で処理して印刷まで完了させるなんて出来ない。

136 :デフォルトの名無しさん:2011/05/16(月) 01:58:36.15
>>133
バッチって、夜間バッチという意味?
画面で印刷指示かけたら、すぐに帳票が出て欲しくないの?

>>134
2、3枚の帳票なら、ユーザーサイドで印刷すればいいけど、何十枚、何百枚単位になってもユーザーに印刷させる気かい?

137 :デフォルトの名無しさん:2011/05/19(木) 00:29:08.67
>>136
そのすぐできる帳票ってどこに出るの?
すぐほしいならユーザーサイドで印刷するよね。
どこかで印刷されるならすぐ印刷する必要はないよね。

138 :デフォルトの名無しさん:2011/05/19(木) 00:38:39.80
バッチで帳票ってのは朝出社したら大量に帳票が印刷されてる感じ?

139 :デフォルトの名無しさん:2011/05/19(木) 01:17:58.17
そんな感じ
印刷された場所と受け取る人が遠く離れてる場合は配布に時間かかるから
出社した時点ではまだ届いてなかったりするけど

140 :デフォルトの名無しさん:2011/05/19(木) 02:09:44.22
配送系とかかな?やっと理解できたわ
帳票はデスクからプリンタの即時印刷ってイメージだったわ

141 :デフォルトの名無しさん:2011/05/19(木) 15:22:28.91
>>137
もう理解できてるかもしれないけど、
ユーザーサイドで印刷するものは、見積書とか依頼書とか印刷枚数の少ない帳票。オフィスに据え置いたブリンタで印刷する。
印刷は、印刷枚数の多い帳票は、大量印刷用のプリンタ。

142 :デフォルトの名無しさん:2011/05/19(木) 15:27:38.18
>>141
誤送した。
最後の行は、郵送用のDMなど、大量印刷が必要な帳票は大量印刷用の専用ブリンタで一括で印刷する。

143 :デフォルトの名無しさん:2011/06/03(金) 09:00:19.49
>>126
まあ、個人のクソ店舗程度ならそれで充分かもなwww
その理念で行くと、みずほレベルの損害では済まないだろwww


144 :デフォルトの名無しさん:2011/06/03(金) 09:04:31.96
>>131
大量の帳票出力とかになると、大型の高速プリンターでないと無理だろwww
何百万件以上もある客先の案内を朝までに打ち出さないといけない時にどうするよwww

大型の魅力はマダマダあるんだよ、アンタのクライアントみたいにショボイ企業レベルの考え方では
処理しきれないのwww

145 :デフォルトの名無しさん:2011/06/03(金) 09:10:20.14
>>140
ショボイな、何の会社だよwww
システム規模の違いで、いや、顧客規模の違いで必要とされているからこそ
コンパクトにできないんだよ、データ件数っていう処理に大きく関わる部分を意外と
ないがしろにしてマシンの処理能力を過剰評価してるから、みずほみたいなシステム要員に
馬鹿が多いんだよ、まあ、ゆとりも障害の要因だよなwww

146 :デフォルトの名無しさん:2011/06/03(金) 09:24:28.90
なんか元気なのが沸いてきたな

147 :デフォルトの名無しさん:2011/06/03(金) 12:21:16.10
躁期にだけ動くバッチ処理って役に立たないよな

148 :デフォルトの名無しさん:2011/11/20(日) 11:30:15.51
立たないよね

149 :デフォルトの名無しさん:2012/08/29(水) 00:27:57.80
     ,,,,.,.,,,,
    ミ・д・ミ
.    """"

150 :デフォルトの名無しさん:2012/08/29(水) 15:28:48.75
ruby2.0がかなりすごいらしい

151 :デフォルトの名無しさん:2012/11/12(月) 23:40:06.57
バッチって具体的にはどういう処理よ
夜間に大量のCSVファイル加工してデータベースに書き込んだりする?

それだったらメインのシステムと同じ言語使ったりしてもよくね?

152 :デフォルトの名無しさん:2012/11/16(金) 23:42:25.85
メインのシステム自体がCOBOLだろw

153 :デフォルトの名無しさん:2013/10/12(土) 19:25:07.64
保守age

154 :デフォルトの名無しさん:2014/04/08(火) 21:34:52.99 ID:iiVXvs8Z
そろそろ時代が追い付くか
jBatchと、あとは分散を上手くやればなんとかなる・・・のか?

155 :デフォルトの名無しさん:2014/11/09(日) 14:30:23.83 ID:iOEsToOb
>>144
何百万件も明朝までに印刷しろとか無計画にもほどあがある。
どこのボンクラ企業だよ。
1週間以上前から言えよハゲ。

156 :デフォルトの名無しさん:2014/11/09(日) 16:50:56.27 ID:EbU/SVlS
>>155
企業によっては月に一度くらいはそのページ数出力して打つとこもあるからな

157 :デフォルトの名無しさん:2014/11/10(月) 00:49:26.98 ID:ns5VzSEf
ここに書いてる人らの置かれた状況(システム化領域)の差をごちゃ混ぜにしてるのをよく分かった。
帳票リアルタイム出力かバッチ出力か、で環境の差を知る。
出す紙の量に従ってシステム組むしかないだろ。

158 :デフォルトの名無しさん:2014/11/10(月) 01:51:31.29 ID:uWFUaRza
うちにはカード会社や電話会社からの利用明細が毎月届くけど
ああゆうのはバッチ出力して封入封函機で処理しないと
どうしようもないよね。
まあ電子化も進めてるんだろうけどNET使えないジジババがいる限り
なくせないだろうし。

159 :デフォルトの名無しさん:2014/11/10(月) 02:39:28.07 ID:tVi0pfE8
>>158
NTTから引き落としにしないと請求書の発行には金を取るという脅迫文が来た。

160 :デフォルトの名無しさん:2014/11/10(月) 22:36:27.66 ID:k2HEG8L5
>>155
ゴシック体ならいいの?

161 :デフォルトの名無しさん:2014/11/16(日) 12:51:57.33 ID:xez2fkiv
>>159
ドコモなんて口座振替でも請求書発行には金を取るって言ってんだぜ?w

162 :デフォルトの名無しさん:2014/11/16(日) 21:51:37.74 ID:jkITM5Sp
ずいぶん昔、リモート印刷システムの開発に関わったことがある
一般にはメインフレームには高速ページプリンタをチャネル接続するけど、
このプリンタをUNIXワークステーションに接続して
メインフレームからオンライン印刷するシステム

こうした大量の帳票を印刷するシステムでは、印刷の高速化や部品の耐久性が
重要になるけど、最も難しいのは帳票の重複や欠落を限りなくゼロにする設計だった
印刷処理はプリンタというメカが相手だから用紙切れや紙づまり(ジャム)が起こりうるけど、
エラーを適切に検出/回復し、たとえ何百万件であっても重複や欠落の無い出力が求められる

こうした要求を満たすために、高速プリンタは数10ページ分のバッファを持ち、
用紙トレイ/印刷ドラム/排紙トレイの様々な箇所にはジャム検出センサが配置されている
またコンピュータとのインターフェイスにも印刷が完了したページ番号を伝える機能が必要
同様にプリンタドライバや印刷ミドルウェアにも対応した変更が必要になる(汎用品では対応できない)
更にここまでしてなお印刷エラーは完全に排除できないから、
エラーの回復手順にどこまで目視確認(=人の介入)が必要か運用基準を設計しなければならない

こうして考えると、PCの印刷システムは少量多種なオフィス向け帳票印刷に適していても、
安全な大量印刷を求められる帳票印刷のニーズには不完全であることが理解できる
結果として、印刷システムを既に技術が確立しているメインフレームから
UNIX/PCへ移行するのは、大きな壁が存在していると言わざるをえない

163 :デフォルトの名無しさん:2014/11/18(火) 00:40:33.58 ID:ZA1BEKo6
>>162
何だってそうだよねえ。
少量多種を即時に出すのと大量同種を一度に出すのとは、根本思想が違ってる。
印刷だけの話じゃない。
寮生10人の賄い飯を毎日作るおばちゃんと毎度異なる団体客千人への夕食を毎日作る板前さんとでは
ノウハウも技術も根本的に違う。
どっちが優劣でもない。

もう当たり前過ぎるレベルのスレだよな。
それを一緒くたにに話してる輩が不憫。

164 :デフォルトの名無しさん:2016/11/19(土) 21:23:56.01 ID:NB2bKCn7
ハローワーク求人128,214件の平均月給197,300円〜268,000円
その中からCOBOLの求人486件の平均月給251,800円〜432,000円
https://goo.gl/E3yXUJ

165 :デフォルトの名無しさん:2016/11/27(日) 15:53:57.17 ID:X5F00nfL
JCLを開発言語だと思ってるのかねw

166 :デフォルトの名無しさん:2016/11/27(日) 15:55:34.99 ID:X5F00nfL
やべ 一行目抜けてた
>>165>>13宛て

167 :デフォルトの名無しさん:2016/11/28(月) 03:59:27.18 ID:ONxkjxus
ほぼ9年前のレスに返信するのもどうなの?ってちょっと思ったけど
それもコボラーらしくていいのかもしれない
新しいものを追いかけるだけが全てではないものね

39 KB
新着レスの表示

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50
名前: E-mail (省略可) :


read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)