【COBOL】コボラー集まれ！！！【事務処理】

1 ：デフォルトの名無しさん：2006/05/01(月) 18:32:38

いるだろ？語ろうぜ

2 ：デフォルトの名無しさん：2006/05/01(月) 18:39:45

ひょっとしたらマ板の方がいいんじゃない？

3 ：デフォルトの名無しさん：2006/05/01(月) 18:56:10

てｓｔ

4 ：デフォルトの名無しさん：2006/05/01(月) 19:56:12

コボラーの占有面積は異常に狭い

俺が某保険会社で実際に目撃したものだが、奴らは超旧式なまっ四角で超窮屈な事務机しか与えられていない

その占有面積は俺のデスクの半分以下！

それはきっとコボラーの社会的なステータス自体がドン詰まりである事を表しているに違いない

5 ：デフォルトの名無しさん：2006/05/01(月) 20:16:43

こぼるのおっさん

6 ：デフォルトの名無しさん：2006/05/01(月) 20:28:54

身も蓋もNothing

7 ：デフォルトの名無しさん：2006/05/01(月) 21:49:35

集めたら一網打尽！

8 ：デフォルトの名無しさん：2006/05/01(月) 21:58:53

CobolもOOPの時代らしいけど、
そこまでして使いたいものなんかと、小一時間。
それならJavaでええがな。

9 ：デフォルトの名無しさん：2006/05/02(火) 11:49:54

COBOLはバカでもできるしオッサンでもできる
もうそこら辺は重々承知してるんでこれ以上イジメんといて下さい

10 ：デフォルトの名無しさん：2006/05/04(木) 00:00:53

コボラー集めてどうするの？
やっぱあれ？

11 ：デフォルトの名無しさん：2006/05/05(金) 12:04:47

集団自殺

12 ：デフォルトの名無しさん：2006/05/05(金) 13:59:16

コボル一筋12年の俺が来ましたよ
しかし、もう辞めたが

13 ：デフォルトの名無しさん：2006/05/05(金) 14:40:26

漏れ COBOL は高校でかじっただけだが
COBOL の OOP のコードって見たことないけど
どんなんなってんの？

*想像上のコード*
　
　WORKING-STORAGE SECTION.
　01　KURASU 　　　 PIC CLASS.
　　　　02 MESODDO PIC METHOD　～

*/想像上のコード*

とかそんな感じ？実例見てみてぇー。

14 ：デフォルトの名無しさん：2006/05/06(土) 18:43:30

IDENTIFICATION DIVISION.
PROGRAM-ID. ******.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. ****.
OBJECT-COMPUTER. ****.
SPECIAL-NAMES. CONSOLE IS *.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
DATA DIVISION.
FILE SECTION.
WORKING-STORAGE SECTION.
こんな感じ？

15 ：デフォルトの名無しさん：2006/05/07(日) 17:57:13

大文字ってマジで見辛い。

OO機能追加する前に小文字使用をデフォルトにしてくれ

16 ：デフォルトの名無しさん：2006/05/08(月) 23:22:10

>>14
項目が何も無いじゃない！
…べ、別に定義して欲しい訳じゃないからねっ！？

個人的にはデータが桁情報持ってたりとか
READ 構文がEOF判定までするところが変わってるなぁと思う

最近は古い言語も小文字デフォだったりするし
小文字の環境もあるんじゃないの？
実際の環境触ってないから分からんが。

17 ：デフォルトの名無しさん：2006/05/10(水) 20:14:06

>>16

＞READ 構文がEOF判定までするところが変わってる

いや、オレにはこれが「事務処理特化型」の特徴の一つだと思うよ。

try{
　　read(xxFile);
}
catch(EofException e){
　　eof = true;
}
catch(IOException e){
　　・・・
}
catch(Exception e){
　　・・・
}

こんなのよりも；

READ XXFILE
　AT END MOVE "ON" TO FLAG-EOF.

この方がよっぽど単純だし、信頼性の高い汎用機で動かすなら
これで充分だと思う。

おまけにbuffer/streamなんかの類もコンパイラとOSのタッグで
意識せずに済む。なかなか素敵な話だと思うがね。

18 ：デフォルトの名無しさん：2006/05/11(木) 01:41:53

COBOL知らない俺にフリーのCOBOL環境教えて君

19 ：デフォルトの名無しさん：2006/05/11(木) 02:24:46

http://www.opencobol.org/

20 ：18：2006/05/11(木) 04:21:39

>>19
インスコ出来ねーぜちくしょう！
でも教えてくれただけでもまーいーや㌧クス

21 ：デフォルトの名無しさん：2006/05/11(木) 15:51:35

>>17
streamの使い方が十分分かっていないのではないか？
上の記述が冗長に見えて、柔軟なのを分からないのが、とってもobsolete.

22 ：デフォルトの名無しさん：2006/05/23(火) 11:27:00

ンモーすぐそんな事言う～～

23 ：仕様書無しさん：2006/06/02(金) 00:24:15

編成ファイルって何？(ひきよう編成ってあるのか？)

24 ：デフォルトの名無しさん：2006/06/02(金) 01:25:00

ttp://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E7%B7%A8%E6%88%90%E6%B3%95

25 ：デフォルトの名無しさん：2006/06/07(水) 21:43:27

高校でCOBOLを習っているのですがテーブルって難しいですね。

26 ：デフォルトの名無しさん：2006/06/11(日) 01:23:02

cobolの勉強をはじめました。
どこかにフリーソフトのエディターってあります？勉強で使う程度ですが。

27 ：デフォルトの名無しさん：2006/06/12(月) 00:07:00

要点を抑えていないその質問だと、「メモ帳」と言う答えが関の山だと思われ

28 ：デフォルトの名無しさん：2006/07/07(金) 18:14:52

いきなり質問で申し訳ないのですが、どなたかご教授願います。
当方COBOL85を使用しているのですが、Write命令で書き込みを
した際、書き込みレコードの後ろの半角文字が削除されてしまいます。
WriteするレコードをDisplayしたところ、きちんと半角文字が入っているの
は確認できます。

どなたか、原因はわかる方いますでしょうか？
宜しくお願いいたします。

29 ：デフォルトの名無しさん：2006/07/08(土) 13:32:55

実行ジョブにレコード長という定義はありませんか？

30 ：デフォルトの名無しさん：2006/07/08(土) 14:43:59

>>28

＞書き込みレコードの後ろの半角文字

意味ﾌﾒ。日本語ﾖﾛ。
人に説明する能力の不足を自覚してるなら、せめてソース晒してくれ。

>>29

その質問方法では答えようがない。いったい何を訊きたいのだろ。ハァ

31 ：デフォルトの名無しさん：2006/07/20(木) 11:42:01

最近、コボルトをコボルといい間違える。
DDOやってて、コボル・アソールトとか言ってる。

32 ：デフォルトの名無しさん：2006/07/20(木) 12:03:30

あんだｺﾗｧ!
くだらねぇこと言ってんとコボるぞﾃﾒｰ!!

33 ：デフォルトの名無しさん：2006/07/20(木) 12:36:15

うわぁ、コボラーの猛攻撃だぁ

34 ：デフォルトの名無しさん：2006/07/23(日) 02:08:40

質問です。
入力ファイルをチェックして、正常分と異常分に振り分ける
プログラムを作ろうとしています。
１レコード毎に振り分けるのなら簡単なのですが、自分が作ろうとしているのは、
連続した複数レコード単位にチェックして、その中で１レコードでも異常なら、
そのまとまったレコードを全て異常分に出力するという仕様になっていて、
どのように実装するか悩んでいます。

最初は、配列を使おうと思ったのですが、レコードの件数は不定で、
何万件もある場合もあるので、汎用性がないということでボツにしました。
そこで次に考えたのは、チェック結果が確定するまで、一時的に作業用の
出力ファイルに溜め込んでいって、判定が確定したら、作業用のファイルを
一旦クローズして、再度入力モードでオープン＆リードし、ＥＯＦまでそのまま
正常分か異常分に出力し、その後作業用ファイルをクローズ＆再度出力モードで
オープンし、次の連続レコードを溜め込む・・・というのを繰り返すという方法です。

このように、１つのファイルのオープン＆クローズを何度も行うやり方っていうのは
どうなんでしょうか？
一つのプログラムでやるとなると、これぐらいしか思いつかないのですが、
もっと賢いやり方はありますか？

35 ：デフォルトの名無しさん：2006/07/24(月) 10:16:09

>>34
何で二つのプログラムに分けないの？

36 ：デフォルトの名無しさん：2006/07/25(火) 01:49:37

　　　　　　　　　　　　 |
　　　　　　　　　　　 |　　なんでだろ～♪
　　　　　　　　　　　　　＼＿＿＿＿＿　＿＿＿＿＿
　　　　　　　　　　　　　　　　　　　　　　V
　　　　　　　_,ヾゝｰ'"'"'"ｰ､,;　　　　,.:-‐―‐-.､_
　　　　　　,ﾗ　　　､_　　　　ヽ,､　／　　　　　　　＼
　　　　　ｲ　 r-'ｰﾞ　"ー‐､,　ﾐ/　　　　　　　　　　ヽ
　　　　　 i!　 ,!　　　　　　　i! ミi　　　,ﾊ　　　　　　　 i
　　　　　 ,j　i /ニ=､　 ,r==､i ,,ﾊ ,ﾉヽi! ﾞ'ﾚ＞ヾ-､　,!r'
　　　　　 i V　<(･)>i　i!(･)>ﾞ!,i　 !!ｲ(･)） <.(･)>ﾞ　i /!i
　　　　　ﾞ!ji!　　　., j .i_　　 /j 　 i　　｡｡,　　　ﾄ-'
　　　　　　,ｨi:.　 ;" ｰ-‐' 　ﾄ'　　 .! 　 ,.=､　　 /￣￣ﾞｰ-､＿
　　　　__ノ !ﾊ　　 : 0 ;　 ,/　_,.-‐''＼ﾞ＝''　 ,／
　　／　　　＼＼　￣ ,／／　　　　　ﾞｰ-‐‐"
／　　　　　　＼.ﾞー-ｲ ,/

37 ：デフォルトの名無しさん：2006/07/31(月) 21:37:18

>>34

マッチングしながら、ワークにデータをタンクしておいて
エラーがあったら出力でいいと思うよ。
適当にテーブルをワークをとっておき、自分の想定以上の
データ数が来たときには、ディスプレイで表示し後で
テーブルを修正。
効率は悪いけど、わかりやすいと思うよ。

>>28
書き込みしたファイルをコードで見れば
わかる。

38 ：デフォルトの名無しさん：2006/08/23(水) 22:10:21

今日､会社で手足を縛られた上、ｺﾎﾞﾙを無理やり教えられました。
明日も明後日もです・・・。
うう・・・ただの事務屋なのに・・・。
明日は朝からコーディングシートに鉛筆でなにやらかかされるそうです

39 ：デフォルトの名無しさん：2006/09/01(金) 15:44:01

コボルをおぼえるなら今のうちだぞ。
現役コボラーのおじさん達が引退するのは
もう間もなくだ。
その後、コボルで作ったシステムの面倒を
誰が見るよ？
メンテするにもリプレースするにも
コボラーが必要になるんだよ。

40 ：デフォルトの名無しさん：2006/09/02(土) 08:22:58

そのおじさん達にまともな仕様書を作らせておけば、
COBOLを熟知していない漏れが面倒みるのもやぶさかではないが。

まあ、長い人生において一度くらいは紙に鉛筆使って設計するのも
悪くない経験だろ。

役には立たんが。（ｗ

41 ：デフォルトの名無しさん：2006/09/02(土) 08:59:33

一度ならな

42 ：デフォルトの名無しさん：2006/09/08(金) 23:48:22

質問です。
PROCEDURE DIVISION.
MEIN.
PREFORM READ_RTN.
STOP RUN.
READ_RTN.
READ INFILE AT END FLG = 1
END-READ.
と
PROCEDURE DIVISION.
MEIN.
PERFORM UNTIL FLG = 1
PERFORM READ_RTN
END-PERFORM.
STOP RUN.
READ_RTN.
READ INFILE AT END FLG = 1
END-READ.
・・・は同じですか？

43 ：デフォルトの名無しさん：2006/09/09(土) 00:23:02

>42

釣り？

これ、コンパイル、通ります？

> READ INFILE AT END FLG = 1

これ
READ INFILE AT END
MOVE 1 TO FLG
END-READ.

だったら分かるんだけど、今の COBOL（ってオレが使ってるのは COBOL88だけど）
そんな代入できるの

44 ：デフォルトの名無しさん：2006/09/09(土) 00:25:03

昔の二種Lvの俺の話で良いなら。

本当にコードがそれだけなら一緒だな。
INFILE読むだけで何もしてないからｗ

それ以前にOPENやCLOSEしてなくて大丈夫なのか？とか
ピリオドの位置ってそれで良いのか？とか
疑問は尽きないわけだが…

で、マジレスするなら
INFILEが空でない限り違うと思うぞ。

下のコードはループしてないから
ファイルが終端であろうとなかろうと
１レコード読んで終わるんでね？

45 ：デフォルトの名無しさん：2006/09/09(土) 00:28:01

MEIN.

46 ：デフォルトの名無しさん：2006/09/09(土) 00:29:28

>>45
そこは多分合ってるかと。
コボラー的には。

47 ：デフォルトの名無しさん：2006/09/09(土) 15:55:11

COBOLerのローマ字文化はそこそこ理に適ってる

・予約語の数がハンパじゃない
・フルスペル
・環境によって存在する予約語とない予約語がまちまち

COBOLがこんなだからローマ字文化にもなる訳だが
他言語にまで持ち込むのは止めて欲しい罠

48 ：42：2006/09/10(日) 19:24:02

あ、すみません、初心者なので。。。
知りたいのは

PERFORM UNTIL ～～
PERFROM READ_RTN
END-PERFORM.
と
PERFORM READ_RTN.
だとREAD_RTNを通る回数が同じになるのかを知りたかったんです

49 ：デフォルトの名無しさん：2006/09/10(日) 20:10:20

>>48
>>44

50 ：デフォルトの名無しさん：2006/09/10(日) 20:11:44

あ、>>44は一部誤りがあるな。
ループしてないのは上のコード。

51 ：デフォルトの名無しさん：2006/09/10(日) 20:15:40

つーか藻舞 UNTIL の意味解ってんの？
解ってたらこんな質問出ないハズ。

52 ：デフォルトの名無しさん：2006/09/16(土) 10:12:06

openCOBOLは、変数名に漢字を使える？

53 ：デフォルトの名無しさん：2006/09/16(土) 13:31:43

使えない

54 ：デフォルトの名無しさん：2006/09/25(月) 00:27:31

COBOLerは、何故態度がでかいのでしょうか

55 ：デフォルトの名無しさん：2006/09/25(月) 01:30:54

>>54
逆だよ。

歳ボケ＋歳のせいにする→他の言語を覚えない

実力主義の人→COBOLだけでは立場がないと考える
年功序列主義→年上が偉いと考える

つまりCOBOLerだから態度がでかいのではなく
そういう性格だからCOBOLerなんだよ

56 ：デフォルトの名無しさん：2006/09/25(月) 23:25:07

お勧めの入門サイトある？

57 ：デフォルトの名無しさん：2006/09/26(火) 04:52:15

>56
言語そのものの入門ならググればすぐ出てきたよ。

ひよこグミ
ttp://www16.plala.or.jp/hiyokogumi/
入門者にゃ良いかもな。
但し、コイツのギャグセンスに耐えられる人向けであることを補足しておく。

COBOL入門
ttp://ueno.cool.ne.jp/shirokaze185/htcobol.html
これで十分な人はこれで十分かも。

でも、一番の問題はセットアップかなぁ。

58 ：デフォルトの名無しさん：2006/09/27(水) 22:16:56

>>57
ありがとうございます
そうなんです、NetCOBOL体験版をみつけたんですが
プログラムを始めるとこまでなかなかいけなくて……

59 ：デフォルトの名無しさん：2006/09/29(金) 18:15:34

>>58
COBOL85はとっつきやすくてよいかも知れません。
もう使い方忘れたけど。

60 ：大分前にOpenCOBOLのインスコに挫折してた人：2006/09/30(土) 04:33:33

やっと、OpenCOBOL (Cygwin版) のインスコ出来たので報告。

1. Cygwin公式サイト(英語) から setup.exe を落とす。（Ｅみたいな形のアイコン）
2. 落とした setup.exe を起動して全部デフォルトで。インスコ始まったら待て。
3. インスコが終わったら、ショートカット作成するか訊いて来るがこの時点では関係なし。
4. もう一度 setup.exe を起動して、今度は途中のURLがズラーっと並んでる画面。
　　下の User URL: のボックスに（頭の h は補完してね）
　　ttp://members8.tsukaeru.net/pegstyle/cygwin/
　　と入れて次の画面へ。
5. Select Packages 画面。これはツリーになってるので + をクリックすれば展開できる。
　　Devel -> opencobol: COBOL compiler （かなり下の方にある）を見つける。
7. その行にリサイクルみたいなマークと Skip と書かれてる。
　　このマークは Skip -> バージョン番号 -> 別のバージョン番号 -> とクリックする度に変わる。
9. バージョン 0.32（正式版）か 0.33（テスト版）にして、次の画面へ。
10. 後はそのまま。最後にまたショートカット作成するか訊いて来るからチェック入れる。
11. 0.32 を入れた場合、cygltdl-3.dll のバージョンが新し過ぎて動かないので古いバージョンを入れる。
　　入手先は ttp://members8.tsukaeru.net/pegstyle/cygwin/cygltdl-3.zip 。

参考URL:
ttp://jp.opencobol.org/modules/mydownloads/
あとはCygwin関連のサイト諸々。

61 ：大分前にOpenCOBOLのインスコに挫折してた人：2006/09/30(土) 04:47:06

ショートカットから Cygwin 起動 → cat > test01.cob

000010 IDENTIFICATION DIVISION.
000020 PROGRAM-ID. TEST01.
000030*
000040 ENVIRONMENT DIVISION.
000050*
000060 DATA DIVISION.
000070*
000080 PROCEDURE DIVISION.
000090 MAIN.
000100 　　DISPLAY "TEST"
000110 　　STOP RUN.

Ctrl+D で入力終了。

（2chで空白の入れ方判らんから行番号付きにして、
　Ｂ領域の頭に入れる４つの半角スペースは全角２個で書いた）

cobc test01.cob でコンパイルして ./test01.exe で実行。

TEST

と出た時には感動と同時に４ヶ月半の疲れがどっと出たぜ……
もうなんか COBOL とかどうでも良くなったｗｗｗ

ちなみに上では cat > ファイル名でやっちゃったけど
エディタは EUC+LF改行に対応してるヤツを使えばＯＫぽい。

62 ：大分前にOpenCOBOLのインスコに挫折してた人：2006/09/30(土) 04:51:42

間違えた。SJIS+LF 臭い。何だ初めて聞いたぞこんな組み合わせ。

63 ：デフォルトの名無しさん：2006/10/07(土) 23:37:00

ソースコード検索エンジンでCOBOLに対応しているところはないでしょうか？
http://koders.com/や http://www.krugle.com/では対応していませんでした。

64 ：デフォルトの名無しさん：2006/10/08(日) 04:53:58

新人に汎用機のデカさやＴＳＳを嬉々として説明してる自分に老いを感じた

65 ：デフォルトの名無しさん：2006/10/08(日) 11:06:40

COBOLScriptなんてブッ㌧だ代物が存在するんだな…ｗ
思えば書けるプログラムの規模はスクリプト並だが
書く時の面倒臭さは汎用言語を上回るCOBOLって救えねぇ…ｗ

66 ：デフォルトの名無しさん：2006/10/10(火) 21:33:35

学校でCOBOL習ってるがさっぱりだ

67 ：デフォルトの名無しさん：2006/10/10(火) 22:29:27

君にはプログラミングのセンスがありません

68 ：デフォルトの名無しさん：2006/10/10(火) 23:06:57

辛辣な意見をありがとうございます

69 ：デフォルトの名無しさん：2006/10/13(金) 01:52:05

高校普通科→大学文系→就職：プログラマー
これ最強コンボ

70 ：RAG：2006/10/17(火) 19:57:35

始めまして。早速ですがわからないことがあるので教えて下さい。

例）
*ソート命令サンプルプログラム

－－－－－中略－－－－－

ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. UP4800.
OBJECT-COMPUTER. UP4800.
*
INPUT-OUTPUT SECTION.
FILE-CONTROL.

SELECT OTFILE1 ASSIGN TO OTFILE1-MSD
ORGANIZATION SEQUENTIAL
ACCESS MODE IS SEQUENTIAL
FILE STATUS IS FO1-STATUS.

－－－－－中略－－－－－

OPEN OUTPUT OTFILE1.

続きます。。。

71 ：RAG：2006/10/17(火) 19:58:53

上のようなプログラムの場合なんですが、このOUTPUT【OTFILE1】は
どこに出力されるのですか？
他のCOBOL関係のサイトを見てみたんですが、

例２）
INPUT-OUTPUT SECTION. *>入出力節の宣言文
FILE-CONTROL. *>ファイル管理段落の宣言文
SELECT F1 ASSIGN TO "C:\dat\c005.dat". *>利用ファイルの詳細

みたいに他ではパスとファイル名まで書かれているのにこのOUTPUT【OTFILE1】は
『OTFILE1-MSD』に出力する（？）みたいな事になっています。
イメージとして『OTFILE1-MSD』はなんかの定数で
別で『OTFILE1-MSD ＝ "C:\dat\c005.dat"』
のようなモジュール（？）があるのでしょうか？

わかりにくくてすみません。
わかる方がいらっしゃいましたら教えて下さい。

72 ：デフォルトの名無しさん：2006/10/17(火) 23:05:06

>>71
製品によるけど環境変数等で設定されてるはず

73 ：デフォルトの名無しさん：2006/10/17(火) 23:23:33

Windowsの統合開発環境か何かでやってるかい？
であれば実行時に環境変数を指定するウインドウとか出てこない？

74 ：デフォルトの名無しさん：2006/10/18(水) 00:11:14

久しぶりに無性にJCLを書きたくなってしまって書いた。
現場を離れてみて思い起こすと、未だにあの使いにくいCUIでコーディング・テストとか
やってるなんて浮世離れしている感があるなあ…

//TEST　　JOB CLASS=U,MSGCLASS=X
//JOBLIB　　DISP=SHR,DSN=HOGE.LIB
//JOBCAT　DISP=SHR,DSN=HOGE.CAT
//TEST01 EXEC PGM=HOGE01
//OTFILE-1MSD　DD　DISP=(NEW,CATLG),DSN=TEST.HOGE,
//　　　　　　UNIT=DASD,VOL=SER=HOGEVL,
//　　　　　　DCB=(RECFM=FB,LRECL=115,BLKSIZE=23000),
//　　　　　　SPACE=(TRK,(1,1),RLSE)
//SYSOUT　 SYSOUT=*

75 ：デフォルトの名無しさん：2006/10/18(水) 09:20:24

>>72
>>73 さん

回答、ありがとうございます。
詳しくは言えないのですが、現状、手元には上記にのソースがある(.cobファイル)のみで
Ａ-ＣＯＳをＡＳＰ．ＮＥＴにオープン化する際の解析段階の事をしています。

環境変数等で設定されているという事はソース上では分からないという事でいいんですよね？
>>72
>>73 さん
その他の方々、よろしければ返事をお願いします。

76 ：デフォルトの名無しさん：2006/10/18(水) 23:30:36

どこかでOTFILE1-MSDをACCEPTしてない？

77 ：デフォルトの名無しさん：2006/10/19(木) 00:14:51

>>75
NetCOBOLならIDEから設定できる

78 ：デフォルトの名無しさん：2006/10/20(金) 00:02:12

COBOLってどんな仕事やってる？
大至急覚えないといけなくなったんだけど
文法覚えた後なにしようか迷う

79 ：デフォルトの名無しさん：2006/10/20(金) 01:46:49

ファイルの読み込み→編集→ファイル出力または帳票出力
が王道パターン。Oracleと組み合わせてPro*COBOLなんかも。

80 ：デフォルトの名無しさん：2006/10/20(金) 04:07:31

>>78
メンテ

81 ：デフォルトの名無しさん：2006/10/20(金) 23:11:00

そしておいらにもメンテの仕事がまわってきたよ
ソース解析するのに便利なツールなんかある？

82 ：デフォルトの名無しさん：2006/10/29(日) 03:14:06

俺はコボラーでいまだに、コボルで開発やっている。
先がないのは、わかっているので、今後を見据えて
Ｊａｖａ、ＶＢ．ＮＥＴ、ＶＢ６、ＡＣＣＥＳＳを
かじった。今後専門的に伸ばしていくには
どれがよいか教えて。

83 ：デフォルトの名無しさん：2006/10/29(日) 16:43:02

DB2,OracleなどのRDBの基礎とSQLだろ。

別にExcel+VBAでもエキスパートになれば食う分には困らんと思うが。

84 ：デフォルトの名無しさん：2006/11/04(土) 20:42:44

>>82
コボラ（上がり）は何故全角文字を使いたがるのだろう？
教えてけれ。

85 ：デフォルトの名無しさん：2006/11/10(金) 00:03:05

COBOLって全角半角混在できないでしょ？

86 ：デフォルトの名無しさん：2006/11/10(金) 21:59:13

漏れはそれよりもソースリストの注釈をｶﾞﾝｶﾞｯﾃ半角カナで入れられる
方がなんとなくムカつくんだけど。

87 ：デフォルトの名無しさん：2006/11/11(土) 13:14:44

S9(3) COMP-3 から　X(2)　に項目移送するってできんの？？

88 ：デフォルトの名無しさん：2006/11/11(土) 15:34:10

>>87

なにがしたいんだ？

3桁の数値しかもパック項目をX（２）って・・・

俺だったら一旦、
S9(3)COMP-3 → S9(3) →　X(3)

にするが、＋-がわからなくなってしまうので考慮が必要。

89 ：87：2006/11/11(土) 21:38:56

X(3)の間違いでした。。すみません。
やっぱS9(3)を挟まないとダメなんですかね？

90 ：デフォルトの名無しさん：2006/11/12(日) 00:01:31

01 NULLPO COMP-3.
　03 A PIC S9(03)　VALUE -111.
01 GATT.
　03 B PIC X(02).
******

MOVE NULLPO TO GATT.

↑のコーディングで
Bの中身は「111D」（パックで-111）になるはずだけど、
こういう何をやりたいのかわかりにくいコーディングは糞なのでおすすめしない。

91 ：デフォルトの名無しさん：2006/11/12(日) 00:30:04

ああ、>>89見てなかった。

基本的には　S9　→　X　はダメ。
ただし、S9をREDEFINESや集団項目でXタイプにみたてて送り出すなら転記可能。

しかし、X(3)の中にどういうデータを入れたいのか明確にしないとバグになるぞ。

-111だとしたら
「F1F1F1」ならS9(3)COMP-3 → 9(3) →　X(3)
「F1F1D1」ならS9(3)COMP-3 → S9(3) →　X(3)
「60F1F1F1」ならS9(3)COMP-3 → -(4) →　X(4)

92 ：デフォルトの名無しさん：2006/11/12(日) 00:56:34

くそう、コードを書かれだすと叩きにくくなるな。
何書いてあるのかさっぱりわからん。

93 ：87：2006/11/12(日) 01:13:29

>91
理解しました。有難う御座います。

94 ：デフォルトの名無しさん：2006/11/13(月) 20:03:54

>>92
ぷ

95 ：RAG ◆nOA3ItxPxI ：2006/11/14(火) 16:06:31

すみません，またまた質問させて下さい。

----------------------------------------------
01 WK-NUM.
02 WK-NUM01 PIC ------.999.
----------------------------------------------

上記の『 WK-NUM01 』に「-123456.123」をｾｯﾄすると
ｱﾎﾞｰﾄしちゃいますか？

96 ：デフォルトの名無しさん：2006/11/15(水) 03:50:39

桁あふれは一般的には切り捨て。
ていうか、そういうのは文法書みるとか、マニュアルみるとかしな。

97 ：デフォルトの名無しさん：2006/11/15(水) 17:22:07

マニュアル、でふと思った
無料でオンラインの文法書ってあります？

98 ：デフォルトの名無しさん：2006/11/15(水) 18:51:39

>>97
たくさんあるよ、ただ版がね

99 ：デフォルトの名無しさん：2006/11/17(金) 01:10:24

他の高級言語と違って、COBOLの文法は初見だとよく分からん。

100 ：デフォルトの名無しさん：2006/11/17(金) 10:55:31

>>99
他の高級言語の範囲が広くなるとそうもいってられない。
というか、COBOLぐらいなんてことはない。
むしろ、よさが分かる。[EOR]

101 ：デフォルトの名無しさん：2006/11/18(土) 09:26:19

>99
俺の場合、文法よりもデータ構造に戸惑った

各itemの定義（数値n桁や文字x桁）の仕方だけでなく
レコードと各要素の関係まで全て桁がベースになってるのには驚いたよ

例えばレコードＲの各要素にデータ突っ込んで
Ｒを取り出したら繋がった内容が出て来たりとか

逆にＲに１行突っ込むと勝手に桁で区切って
各要素に分解されたりとかそのへん

102 ：デフォルトの名無しさん：2006/11/18(土) 20:43:21

>>101
Cobolいいよね＾＾

103 ：デフォルトの名無しさん：2006/11/18(土) 20:58:29

>102
良いか悪いかはまた別の話

104 ：RAG ◆nOA3ItxPxI ：2006/11/29(水) 15:44:18

すみません。またまた質問させてください。

----------------------------
02 WK-A PIC X(02) VALUE ""3F75"".
02 WK-B PIC X(02) VALUE ""3F76"".
----------------------------

これって何で2バイト領域に6(?)・4(?)バイトのものがデフォルト設定
出来るのですか？
教えて下さい。

105 ：デフォルトの名無しさん：2006/11/29(水) 21:12:02

stop run

106 ：デフォルトの名無しさん：2006/11/30(木) 22:32:03

>>104
釣りか？

3F75と3F76って何かしってる？

107 ：デフォルトの名無しさん：2006/11/30(木) 22:42:32

go to >>105

108 ：RAG ◆nOA3ItxPxI ：2006/12/01(金) 08:51:31

>>106
レスありがとうございました。
書き込みが遅くなりましたが、あの後自己解決（？）しました。
ネットで調べてみると”漢字”の前後に付加するコードなんですね。

でも仕事で見ている他のプログラムは付けていないのもあってどういう
時にコードを付加するのかは未だに理解できてません。

とりあえず，ありがとうございました。

109 ：RAG ◆nOA3ItxPxI ：2006/12/06(水) 18:24:06

ここのみなさま方，お疲れ様です。

すみません！！最後にしますので，教えていただけないでしょうか？

>>95 が解決しませんでした＿|￣|○

01　A　PIC　------9.999;
01　B　PIC　 -----9.999;　

が宣言されていて

『-123456.123』

をAとBにｾｯﾄすると

A＝-123456.123
B＝123456.123

という解釈でよろしいのでしょうか？

どなたかご回答をお願いします。

110 ：デフォルトの名無しさん：2006/12/07(木) 07:43:26

符号部は桁落ちしないだろ。
B=-23456.123

111 ：RAG ◆nOA3ItxPxI ：2006/12/07(木) 16:49:46

>>110　さん
ありがとうございました。

112 ：デフォルトの名無しさん：2006/12/17(日) 15:54:12

補足しちゃいます。
---.99の場合、---と－が３つありますが、このような数字編集を浮動挿入編集と
いいます。－の挿入位置が次のように浮動するからです。
|－|？|？|．|？|？|
|△|－|？|．|？|？|
|△|△|－|．|？|？|
浮動挿入の場合、先頭の－は、符号確保用で数字が入ることはありません。
続く２つの－は符号・数字を格納する桁です。すなわち、---.99と同等の
キャパシティを持ったゾーン10進は、
　PIC S999.99 USAGE IS DISPLAY.
ではなく、
PIC S99.99 USAGE IS DISPLAY.
です。私の知っているCOBOLコンパイラは、一旦このような相当するゾーン
10進に変換した後で、編集を行うようなオブジェクトを出しているようです。
PIC -----9.999ですと、PIC S99999.999 USAGE IS DISPLAYですので、
-123456.123は、-23456.123に変換された後で編集されることになります。

113 ：デフォルトの名無しさん：2006/12/17(日) 20:00:51

ピリオドが必要だったり不要だったりしてややこしい。

114 ：デフォルトの名無しさん：2006/12/17(日) 23:53:10

COBOLって関数(値を返すサブルーチン)はないのでしょうか？

115 ：デフォルトの名無しさん：2006/12/18(月) 00:48:06

組み込み関数くらいならあるでしょう。
FUNCTION LENGTHとかFUNCTION ～って奴。
あと、特殊名称とかで戻り値を拾って来れたはず。

116 ：デフォルトの名無しさん：2006/12/18(月) 08:04:33

program-status

117 ：デフォルトの名無しさん：2006/12/18(月) 08:15:31

ユーザ定義関数は、2002にはある。
＞http://www.cobol.gr.jp/knowledge/next_standard/standard0002/chap08.pdf
が、使ってるところはありそうもないな。

118 ：デフォルトの名無しさん：2006/12/20(水) 16:51:57

すいません、質問なんですけど
SELECT ○○○ ASSIGN ○○○-DS
ORGANIZATION RELATIVE
ACCESS DYNAMIC
KEY ○○○-KEY.
というファイルを　I-O　で　OPEN　して
ACCEPT　○○○-KEY.
READ ○○○ RECORD INVALID
MOVE "1" TO W-INVFLG
END-READ.
という風に書くとコンパイルできないんですけど何故なんでしょう？
○○○-KEYはWORKING　STRAGE　に定義してるんですけど…
どなたか教えていただけませんでしょうか

119 ：デフォルトの名無しさん：2007/01/21(日) 23:01:06

ＣＯＢＯＬは永遠に不滅なり～！

120 ：Taku：2007/01/21(日) 23:03:42

Performを使えば構造化出来て、GO TO使えば生産性の良いプログラムが作れるＣＯＢＯＬは
情報処理を行う技術者の永遠の救世主なり！

121 ：デフォルトの名無しさん：2007/01/21(日) 23:42:51

PERFORM SUB-SEX-RTN THRU SUB-SEX-END UNTIL SYASEI-SW = 1.
...
SUB-SEX-RTN.
COMPUTE ROUNDED MANKO = TINPO * SEIEKI.
IF MANKO > 100
MOVE 1 TO SYASEI-SW.
SUB-SEX-END.
EXIT.

失敬！！！

122 ：デフォルトの名無しさん：2007/01/21(日) 23:52:50

ローカルでしか使わない変数どうやって管理すればいいんだよぅ

123 ：デフォルトの名無しさん：2007/01/22(月) 00:10:46

真のコボラーは、ローカル／グローバルなんて意識しません。
すべてグローバルでいいんです。
そんなの意識するから生産性が落ちるんですよ！！！！！

124 ：デフォルトの名無しさん：2007/01/24(水) 01:57:23

コボルって随分と時間が止まってるんですね

125 ：デフォルトの名無しさん：2007/01/25(木) 00:02:27

COBOLに関して質問なんですが、どなたか教えていただけないでしょうか？
主キー(RECORD KEY)のみを指定して、
索引ファイル(REIDAI)を、順呼び出しで読む場合、
下記の様なプログラムで主キーの昇順に最初から最後までレコードを
読めるのでしょうか？
それとも主キーの昇順に最初から最後までレコードを読むためには
READ文の前に何か位置を決めるような処理が必要だったり、
READに何か付け足したりする必要があったりするのでしょうか？

OPEN INPUT REIDAI.
KURIKAESHI.
READ REIDAI
AT END
GO TO OWARI
NOT AT END
GO TO KURIKAESHI
END-READ.
OWARI.
CLOSE REIDAI..
STOP RUN.

126 ：デフォルトの名無しさん：2007/01/25(木) 00:06:30

OPEN INPUT REIDAI.
スペースが…
　　　　OPEN　INPUT　REIDAI.
KURIKAESHI.
　　　　READ　REIDAI
　　　　　　AT END
　　　　　　　　　GO TO OWARI
　　　　NOT AT END
　　　　　　　　　GO TO KURIKAESHI
　　　　　　END-READ.
OWARI.
　　　　CLOSE REIDAI..
　　　　STOP RUN.

127 ：デフォルトの名無しさん：2007/01/25(木) 23:56:02

INITIALIZEってCで言うmemsetみたいなものって認識でいいの？

128 ：デフォルトの名無しさん：2007/01/26(金) 01:35:12

>127
C言語のソレは知らんけど…この辺が参考になるか？

ttp://www.ginga.co.jp/kenshu/cobol/initialize.html
ttp://www16.plala.or.jp/hiyokogumi/dic/a_init.html

VALUE句で初期化出来るし、後から初期化するにしても
単体の項目なら MOVE で大抵は事足りるだろうから
必ずしも使うかと言うとそうでも無いんじゃね？

複合項目なら使うかもね、文字数字複合レコードとか。

129 ：デフォルトの名無しさん：2007/01/26(金) 01:45:32

何でコボルってあんな仕様なんだよ変数宣言だけで1500ステップってｗｗｗｗｗｗｗｗｗ

130 ：デフォルトの名無しさん：2007/01/26(金) 03:44:54

>>129
それだけ業務が大きいってことさ。
行数が減ってもテスト量は減らんぞ。

131 ：デフォルトの名無しさん：2007/01/27(土) 03:00:01

>127
主に集団項目(Cでいう構造体)の初期化に使うという意味では、
あたらずも遠からずというところでしょうか。Cの構造体の場合
memsetで、一色、たとえば0x00で初期化してしまえば事足りることが
多いです。しかし、COBOLの場合、メンバのデータ型に応じた初期化が必要と
なることが多いです。INITIALIZE文は、ゾーン１０進メンバは0xf0f0...f0、
パック１０進メンバは0x000...0c、２進メンバは0x0、英数字メンバは
半角スペース、日本語メンバは全角スペース、ポインタメンバはNULLと
いったように、メンバ毎にメンバのデータ型で一番自然な初期値で
初期化を行います。もちろん、「英数字メンバはデータ項目A、日本語
メンバはデータ項目Bの値で初期化する」といった指定も可能です。

132 ：デフォルトの名無しさん：2007/03/01(木) 08:25:27

こぼるを馬鹿にする奴は天に唾吐いてるのと同じ

133 ：デフォルトの名無しさん：2007/03/01(木) 19:22:47

新規での開発でコボルを使うなんてとんでももない

134 ：デフォルトの名無しさん：2007/03/01(木) 21:51:03

それがあるんだよ。新規で。COBOLでWebアプリケーション。しかもWindowsserver。ドットネットは使用禁止。

135 ：デフォルトの名無しさん：2007/03/01(木) 21:59:38

それはそれでチャレンジ精神をくすぐられるというかなんというか・・・。

客からすれば動けばいいんだろうけど、それって
JavaとかPHPとか.NETよりも開発コスト低いのか？

どー考えても、JavaやPHPの方が3～10倍ほど効率よく開発できると思うが。

136 ：デフォルトの名無しさん：2007/03/01(木) 23:11:38

COBOLって大文字だけで書くの？
ひょっとして、タイピングは昔の機械式タイプライターみたいのでやるの？

137 ：デフォルトの名無しさん：2007/03/02(金) 01:09:29

>136
汎用機にだってスクリーンエディタはちゃんとある。
それより昔だとパンチカードになるんじゃないか？

Windows用のCOBOLなんかだと、好みのエディタを使っても良いかと。

138 ：デフォルトの名無しさん：2007/03/03(土) 16:49:59

COBOL.Netじゃないのか

139 ：デフォルトの名無しさん：2007/03/05(月) 12:01:37

Dをでーと読む
Tをてーと読む

140 ：デフォルトの名無しさん：2007/03/05(月) 12:16:45

>>136 ダ・ダ・ダ・ダ・ダーっと右手に紙テープが出てくる。

141 ：デフォルトの名無しさん：2007/03/05(月) 20:51:00

隊長！東京湾に怪獣が出現しました！！

142 ：デフォルトの名無しさん：2007/03/05(月) 21:05:56

メモリーはCore(CPUではない!)だから、不揮発性だ。

143 ：デフォルトの名無しさん：2007/03/13(火) 07:01:40

PRO*COBOLで↓みたいなSQLをフェッチしたいんだけどどうやればいい?
ひょっとしてCOBOLではできないんだろうか…?

SELECT DISTINCT 会社,CURSOR(
　SELECT DISTINCT 支店,CURSOR(
　　SELECT 明細NO,ROWNUM
　　FROM 支店別明細
　),ROWNUM
　FROM 支店別明細
),ROWNUM
FROM 支店別明細

144 ：デフォルトの名無しさん：2007/03/13(火) 16:33:39

できるに決まってる
もうちょっと調べれ

145 ：デフォルトの名無しさん：2007/03/17(土) 01:00:20

>>144
CURSOR式のところで別のCURSORオープンして、3重ループで回すのかな?
コンパイル通るんだろうか…

146 ：デフォルトの名無しさん：2007/03/22(木) 17:31:48

ループカウンタに関して

A-RTN　　　　　　　　　SECTION.
　　PERFORM VARYING IX1 FROM 1 BY 1 UNTIL IX1 > 10
　　　　PERFORM B-RTN.
　　　　PERFORM C-RTN.
　　END-PERFORM.
　　　：
A-EXIT.
　　EXIT.

B-RTN　　　　　　　　　SECTION.
　　MOVE　WK-XXX (IX1)　　TO　SPA-XXX(IX1).
　　　：　　　：　　　　　　　　　　：
B-EXIT.
　　EXIT.

C-RTN　　　　　　　　　SECTION.
　　MOVE　WK-YYY (IX1)　　TO　SPA-YYY(IX1).
略

既存のソースでこういうのを見ると吐き気が・・・

147 ：デフォルトの名無しさん：2007/03/22(木) 17:38:06

A-RTN　　　　　　　　　SECTION.
　　PERFORM B-RTN.
　　PERFORM C-RTN.
A-EXIT.
　　EXIT.

B-RTN　　　　　　　　　SECTION.
　　PERFORM VARYING IX1 FROM 1 BY 1 UNTIL IX1 > 10
　　　　MOVE　WK-XXX (IX1)　　TO　SPA-XXX(IX1).
　　　　　：　　　：　　　　　　　　　　：
　　END-PERFORM.
B-EXIT.
　　EXIT.

C-RTN　　　　　　　　　SECTION.
　　PERFORM VARYING IX1 FROM 1 BY 1 UNTIL IX1 > 10
略

こう書いてくれると助かる。
就職してから初めてCOBOLに触れて（社内保守）そんなに経ってないんだけど
ローカル変数が無いと確認する範囲が広すぎて落ち着かない・・・

148 ：デフォルトの名無しさん：2007/03/22(木) 21:17:44

そんな書き方したらテスト量が増えるだろ！
Sectionは関数じゃネーンだよ。
真のコボラーなら、余裕で問題無し。と感じるはず。

149 ：デフォルトの名無しさん：2007/03/25(日) 00:57:57

>>148
テスト量も増えるし計算量も増えるよね…　＞147
同じループ2回も回さなくても…

150 ：デフォルトの名無しさん：2007/03/29(木) 20:05:42

普通は148-149の感覚で問題ないが、IX1をいじるバカがいる特殊な職場だと
146の気持ちもわからんでもない。
そんな糞ソースは普通レビュー段階でボコられるはずだが。

151 ：デフォルトの名無しさん：2007/03/30(金) 00:07:24

COBOLにもFOR EACHが欲しい…

152 ：デフォルトの名無しさん：2007/03/30(金) 01:54:45

ある意味コボルはアセンブラに近いなw

153 ：デフォルトの名無しさん：2007/03/30(金) 13:22:47

ACOS-6

154 ：デフォルトの名無しさん：2007/04/08(日) 10:09:03

今年の4月から新入社員研修でCOBOLの勉強をしてるのですが、
家のパソコンで予習・復習したいのでCOBOLの環境（？）を
入れたいのですが、入れ方を教えてください！

155 ：デフォルトの名無しさん：2007/04/08(日) 21:02:38

>>154
FreeCOBOL.iNFO～フリーのWindows用COBOLコンパイラまとめ～
http://labs.netbata.com/cobol/
ここら辺りを見たら？

156 ：デフォルトの名無しさん：2007/04/08(日) 23:01:40

おすすめの参考書教えろ

157 ：デフォルトの名無しさん：2007/04/09(月) 22:38:18

>>155
どうもありがとうございます！

158 ：デフォルトの名無しさん：2007/04/10(火) 13:12:44

>>152
生成されるコードはアセンブリとは程遠いんじゃまいか？
それとも最近は改善された？

159 ：デフォルトの名無しさん：2007/04/10(火) 21:49:27

こぼるはいい
命令10個おぼえれば仕事できる
もう10年も前に足あらったが今はこぼるがいとおしい

160 ：デフォルトの名無しさん：2007/04/10(火) 22:22:12

>>156
現場で動いてるグッチャグッチャなソース

161 ：デフォルトの名無しさん：2007/04/11(水) 14:17:32

COBOLはもう滅ぶしかないのだろうか・・・

162 ：デフォルトの名無しさん：2007/04/11(水) 23:39:07

COBOLの参考書なんて見たことないな…。
教科書だったら明日から使うけど。

163 ：デフォルトの名無しさん：2007/04/12(木) 22:20:35

すんません教えてください。
2chtable から　ita_bangou というデータを埋め込みsqlでとってくる。
fitchでITA-BANGOUにいれる。
ita_bangouがnullの場合、ITA-BANGOUには何がはいるんでしょうか？

後に　IF ITA-BANGOU = NULL と同じ意味になる文を作りたいです。

164 ：デフォルトの名無しさん：2007/04/13(金) 06:33:46

初心者質問です。
データベースのtableにある小数点以下まである数値を
SQLで読み込んで演算し結果を表示したいのですが、
小数点が表示されなくなったりしてうまくいきません。
どうすればよいか教えていただけないでしょうか？

165 ：デフォルトの名無しさん：2007/04/13(金) 08:47:38

PIC S999.99 で。

166 ：デフォルトの名無しさん：2007/04/14(土) 14:47:51

研修でコボルやってるんですけど難しくて
周りについていけないです（＞＜）

167 ：デフォルトの名無しさん：2007/04/15(日) 23:44:00

>>166
あ、それはもう転職したほうがいい。。
別にプログラムできなくても人生なんにも困らん。

168 ：デフォルトの名無しさん：2007/04/19(木) 15:39:31

引数で与えられた秒数ＷＡＩＴさせる方法を教えてください。

169 ：デフォルトの名無しさん：2007/04/19(木) 21:24:52

NET COBOLのコンパイルエラーについてどなたか教えてください。

「COPY コピー句名.」だとエラーは出ず、
「COPY コピー句名 DISJOINING AA JOINING BB AS PREFIX.」だと
展開されてるっぽいんだけど文字が置き換わってません。

これだけの情報でもし原因がわかる方がいたらお願いします。

170 ：デフォルトの名無しさん：2007/04/19(木) 22:24:46

研修中です。
仕様書に、レコード長５０、ブロック長５０って書いてあります。
BLOCK CONTAINS 50 RECORDS　でいいんですか？

171 ：デフォルトの名無しさん：2007/04/20(金) 01:07:06

英語分からんの？

172 ：デフォルトの名無しさん：2007/04/20(金) 01:38:02

>>143
CURSOR変数にINTOしてやればFETCHできるんじゃない？

173 ：デフォルトの名無しさん：2007/04/20(金) 01:46:54

>>170
ブロック長って指定できたっけ？

>>168
COBOLにwait命令なんて無いから、ミドルウェアの機能を呼び出す。
なければ、Cライブラリのsleepでも呼び出す機能を自前で作る。

174 ：デフォルトの名無しさん：2007/04/21(土) 00:58:16

>>143
CURSOR式のCURSORは親レコードがFETCHされた時暗黙でOPENされるから(次の行をFETCHする時CLOSEされる)、
OPENとかCLOSEとか考えずにFETCHすれば良い。

175 ：デフォルトの名無しさん：2007/04/23(月) 21:18:46

質問です。
COBOLでJAVAを読む方法を教えてください。

176 ：デフォルトの名無しさん：2007/04/23(月) 23:02:54

READ A-REC.
こんな感じか？

177 ：デフォルトの名無しさん：2007/04/24(火) 22:51:02

先週研修はじめましたが、詰まっています。
入力ファイルの
SHOHIN-CODE　PIC X(１) の中身が１かつ２なら正常でそのまま出力ファイルの同項目に書き込み、それ以外なら、
ERR-KBN PIC X(1) （注：OCCURS　5　TIMES になっている）のエラー区分(1)に１を入力するという
処理なのですが、IF SHOHIN-CODE = 1 OR 2 THEN CONTINUE ELSE MOVE 1 TO
ERR-KBN(1) END-IF.　でいいのでしょうか？

178 ：デフォルトの名無しさん：2007/04/24(火) 23:11:51

>>BLOCK CONTAINS 50 RECORDS　でいいんですか？
こりゃこれは1レコードを1ブロックとする指定
つーつブロックはJCLで指定しなさい

179 ：デフォルトの名無しさん：2007/04/24(火) 23:12:43

あ、50レコードを1ブロックとする指定ね

180 ：デフォルトの名無しさん：2007/04/25(水) 01:10:32

>>177
>１かつ２なら
１または２なら～だろ。

>IF SHOHIN-CODE = 1 OR 2 THEN
文字だから'1'にしないと一致しないかも。あと
SHOHIN-CODE = '1' OR SHOHIN-CODE = '2'
解釈確認するの面倒だから愚直に書くほうがいい。

181 ：177：2007/04/25(水) 23:47:41

>>180
ありがとうございます。
調べまくったのですが、ERR-KBN OF 集団項目というふうにすればＯｋですか？

182 ：デフォルトの名無しさん：2007/04/25(水) 23:58:16

>>181
集団項目なくてもコンパイルは通る。いれるのは気分次第かね。

183 ：177：2007/04/26(木) 22:35:24

エディターでプログラム入力するとき、スペースキーを使ってはいけないって
本当ですか？
MOVE A TO B　などのように、語と語の間は空白をあけますが、
十字キーでカーソル移動しないと、スペースキーだと空白と認識してしまい、
ビルドしたときにエラーの嵐で大変だと聞いたことがあります。

184 ：デフォルトの名無しさん：2007/04/27(金) 07:28:36

クラスごとに小計を出して最後に合計を出すんですけど
どのような命令を出せばいいんですか?
初心者なんでよくわからないんです
誰か教えてください

185 ：デフォルトの名無しさん：2007/04/27(金) 08:09:14

>>183
スペースキーでいいよ。ただ漢字の全角空白だとエラーになる。

>>184

COMPUTE SYOKEI-A = 1 + 2 + 3

186 ：デフォルトの名無しさん：2007/04/27(金) 20:25:54

COBOLって何ですか？

187 ：デフォルトの名無しさん：2007/04/28(土) 00:06:16

僕らには関係ない言語さ

188 ：183：2007/04/28(土) 00:38:03

>>185
エディターで最初に全部右シフトとかしないといけなかったようです。
どうもありがとう。

189 ：デフォルトの名無しさん：2007/04/28(土) 09:10:34

>>184
そのファイルがクラスの昇順になっているものとして

1 クラスをキーとしてワークエリアに定義しておく
eg 03 WK-KEY01
05 WK-CLASS01 PIC 9(XX)
03 WK-KEY02
05 WK-CLASS02 PIC 9(XX)

2 ファイルを読み出す
3 クラスをキーに入れる
4 最初のみ WK-KEY01をWK-KEY02にセットする
5 ファイルを読んでいく
6 集計するものはこの間にクラス計と全合計に加算
7 キーが違えば集計分を出力クラス計の変数を初期化
8 最後までこの繰り返し
9 最後になればクラス計と全合計を出力して終了

190 ：デフォルトの名無しさん：2007/04/28(土) 13:28:03

WORKING STORAGE SECTION　にも　FILE SECTION　にもPICTURE　がありますが、
２つのセクションんってどうちがうんですか？

191 ：デフォルトの名無しさん：2007/04/28(土) 13:53:05

>190
その単語が意味する通り。

FILE SECTION はファイル入出力用の領域。
WORKING-STORAGE SECTION は作業用の一時領域。

192 ：デフォルトの名無しさん：2007/04/28(土) 23:09:13

Ansiコードで3行改行って指定できないですよね？
出力で3行以上空けてから文字を打ち出したいときはどうしたらいいのでしょうか。

193 ：デフォルトの名無しさん：2007/04/28(土) 23:28:58

>>192
１行改行を３回書けばいいだろ。

194 ：デフォルトの名無しさん：2007/04/28(土) 23:39:20

でもAnsiコードって1バイト分しか取れないですよね？
すみません、よく理解していなくて。

195 ：デフォルトの名無しさん：2007/04/29(日) 00:31:01

>>194
だから、改行文字を３文字書けよ。

196 ：デフォルトの名無しさん：2007/04/29(日) 01:51:24

warata

197 ：デフォルトの名無しさん：2007/04/29(日) 01:54:04

いいぞ
その調子だ

198 ：デフォルトの名無しさん：2007/04/29(日) 12:37:34

そういや、1行戻るってのもあるんだよな
これいっぱい出力したらどうなるかぁ

199 ：デフォルトの名無しさん：2007/04/30(月) 12:49:24

初めて来たけど、ACOSの人、多いな。

200 ：デフォルトの名無しさん：2007/05/01(火) 19:26:50

研修中です。
二つのファイルのマッチングをやるんですが、なぜ事前にソートするのか？って
聞かれました。効率がいいからではないんですか？ソートしていないバラバラの
状態では、マッチングできないんですか？

201 ：デフォルトの名無しさん：2007/05/01(火) 22:47:45

>>200
そんなの自分で両方ともトレースしてどっちが効率いいか比べろ。
それも研修のうちだ。

いっとくけど、ソートしないほうは「ソート」という下ごしらえが不要で
ソートしておく方は余計な作業が必要だな。
その辺のアルゴリズムも考えて総合的に比較しろよ。

現実、ソートなんてユーティリティまかせだけど、それも所詮人間の作った仕組みなんだから
絶対考慮しろよ！

ま、開発効率は言うまでもなくry(

202 ：デフォルトの名無しさん：2007/05/02(水) 00:00:47

コボラー・・・　知り合いに「COBOL分かるんだ、コボルドだね」って言われた。

203 ：デフォルトの名無しさん：2007/05/02(水) 00:36:09

コボリン。

204 ：デフォルトの名無しさん：2007/05/02(水) 01:20:40

＞200
順ファイルは、いわばカセットテープ。
頭出しができないから、あらかじめ昇順しておくと、先頭から何度も読み込みする必要はなくなる。

205 ：デフォルトの名無しさん：2007/05/02(水) 02:49:49

すげー
ちなみにCOBOLの新規開発なんてあるの？
既存システムへの機能追加じゃなくて、純新規の開発。

206 ：デフォルトの名無しさん：2007/05/04(金) 11:02:48

金融系では普通にあるよ　しかもUNIXやWinのプラットフォームで
OracleがPro*COBOLを提供しているからね　Pro*Cよりも開発が楽で生産性が高い

207 ：デフォルトの名無しさん：2007/05/04(金) 12:14:45

私も銀行とか証券とか金融系の仕事してたけど、COBOLの現場を見たことないなー
もっともそういう現場には逝かないような会社を選んで就職したわけだが

208 ：デフォルトの名無しさん：2007/05/04(金) 19:58:30

Webフロントくらいしかやってなかったんだろ

209 ：デフォルトの名無しさん：2007/05/04(金) 21:25:12

自治体関係なら普通にある。
来年度に始まる新しい保健制度もCOBOLでやるし。

210 ：デフォルトの名無しさん：2007/05/04(金) 22:24:07

自治体や金融ならバック側に汎用機使うケース多いね。
みずほ統合の際にも話題になったけど、○○銀行は日立、○○銀行はIBMみたいに、
これらの業界では汎用機メーカーが勢力争いでがっちり縄張り持ってるからな。

OSからソフトから運用保守まで全てをクローズドな技術として自分たちの手のうちに
できるメインフレームシステムは、他へのリプレースが非常に困難な上に利益率が
90％以上という恐ろしく儲かる世界。
無料のオープンソースが採用できたり利益率が低かったりするフロント側とは
比べ物にならないくらいおいしいビジネスなんだよ。
同じシステム開発でも、情報系と基幹系は別世界だと考えた方がいい。

211 ：デフォルトの名無しさん：2007/05/05(土) 00:21:16

NECって銀行系あるんですか？

212 ：デフォルトの名無しさん：2007/05/12(土) 10:38:03

質問なのですが改ページ処理をする時に何故、
SPACEを出力領域に送らなければならないのですか？

213 ：デフォルトの名無しさん：2007/05/12(土) 10:47:07

送らないでやってみるとわかるよ。

214 ：デフォルトの名無しさん：2007/05/12(土) 10:48:37

>>213
月曜日にやってみます！

215 ：デフォルトの名無しさん：2007/05/12(土) 13:10:30

改ページしたいだけなのになぜスペースを書き出さなくてはならないのですか？

216 ：デフォルトの名無しさん：2007/05/12(土) 22:10:02

　 ―――――――‐‐―――――――――　,　.　
　　　　　　　　　　　　|||n　　　　　　　　　　　; '"__　ﾞ、
　　　　　　　＿＿__/二ﾆヽ､=_　　　　　　　 ;　⊂/　　;
　　　　　／_／|　,.l　 ,ｨ'''"　ii')´）　　　　　　/ / ,　
　　　　　/__/ ,.ｨ'"　　　i　　,,,.ｨ'｀　　　　　　 /　/　　
　　　　 /〆｀´　　　　　｀""　ー――――‐　/
　　　　ﾛ0~l　　　　　"〃〃"　　　　　__,,.ｨ-‐'"　　　＜　コブラと聞いてやってまいりました
　　%====,≧j＿,,...()８８三--―''""~
　　　　　　　/　　　/ヽ､　　　ヽ､
　　　　　｀￣￣￣｀￣￣￣￣￣￣´

217 ：デフォルトの名無しさん：2007/05/14(月) 21:27:26

社員番号１２３４５６　と　社員番号１２３４５６７８　のマッチングだったら、
６が最終キーですよね？

218 ：デフォルトの名無しさん：2007/05/15(火) 21:43:55

>>209

> 来年度に始まる新しい保健制度もCOBOLでやるし。
それマジ？後期医療保険制度のことでしょ？

219 ：209：2007/05/16(水) 00:42:42

>>218
保健って書いていたね。ごめん。後期医療の事ですもちろん。
自分の取引先だと既存システムが汎用機でシステム組んでいるため、
それらと連携を取るためにも汎用機のシステムの方が都合の良いケース
も考えられるし。
そんな場合だと当然COBOLになってしまう。

220 ：デフォルトの名無しさん：2007/05/16(水) 00:47:07

ボッてるな・・・・

221 ：デフォルトの名無しさん：2007/05/18(金) 13:17:18

医療系か
そういえばORCAもCOBOLだったな

222 ：デフォルトの名無しさん：2007/05/24(木) 15:09:04

COBOLソース内でバッチを起動させる方法を
教えてください。

223 ：デフォルトの名無しさん：2007/05/24(木) 16:25:50

>>222
JCLでやるべきなんじゃないの？

224 ：デフォルトの名無しさん：2007/05/24(木) 19:26:26

ヤバイ…落ちコボラーになりそうだ…orz

225 ：デフォルトの名無しさん：2007/05/25(金) 11:43:42

COBOLでEXEファイルを実行したいのですが、
どうすればいいでしょうか？

226 ：デフォルトの名無しさん：2007/05/25(金) 11:45:56

>>223

まじれすしちゃだめぽ

227 ：デフォルトの名無しさん：2007/05/25(金) 11:57:41

若い人はいやがるんだよな・・・ＣＯＢＯＬ。

228 ：デフォルトの名無しさん：2007/05/26(土) 00:12:57

ttp://www.cobol.co.jp/

こんな会社があるとは…

昔　汎用機オペ　～オフコンプログラマー　やってたが　
オープン系にシフトして　Object指向に馴染めず　欝で　失職した
元PGだが　またコボラーに　戻れるかな＞＞？

229 ：デフォルトの名無しさん：2007/05/26(土) 01:09:21

COBOL魂よんで、お前が泣いた。

230 ：デフォルトの名無しさん：2007/05/26(土) 05:42:55

7年ブランクがあるけど久しぶりにｺﾎﾞﾙやります。

231 ：デフォルトの名無しさん：2007/05/27(日) 22:19:27

コボラーのコラボ

232 ：デフォルトの名無しさん：2007/05/28(月) 12:09:43

ビジネス環境が激変する中、企業を支えるシステムにも変化対応が求められています。
特に基幹システムでは、既存システムへの投資を無駄にすることなく、変化に強い新システムへ
進化できることが何よりも重要です。既存のCOBOLビジネスロジックを再利用可能なサービスに分解し、
ビジネスプロセスに合わせてそれらのサービスを組み合わせる。さらに、ビジネスプロセスの変化に対し、
サービスを再利用してシステムを再構築する、というアプローチを多くの先進企業が始めています。
今回の「COBOLフォーラム2007」では、SOAと .NETで実現する変化に強い新基幹システム構築のための
技法を解説し、最新のCOBOL活用事例をご紹介します。
この機会に是非ご参加いただきたく、ご案内申し上げます。
　
■COBOLフォーラム2007 開催概要
主催：マイクロフォーカス株式会社
協賛：日本アイ･ビー･エム株式会社／マイクロソフト株式会社／日本ユニシス株式会社
開催日時： 2007年6月7日（木） 13：30～17:10（開場13:00）
開催場所：ヴィラフォンテーヌ汐留コンファレンスセンター（東京都港区東新橋1-9-2）
[地図] 汐留シオサイト地上MAP
[地図] 汐留シオサイト地下歩道MAP
受講料：無料（事前登録制）

ttps://ssl2.oneoffice.jp/ssl.ai-privacy.jp/cobolforum/index.html

>日本ユニシス株式会社 w

これって、リプレイスしない方法ってことなの？
詳しい人よろしく

233 ：デフォルトの名無しさん：2007/05/28(月) 13:44:44

フォールバックのやり方を教えてくれるんだよ

234 ：デフォルトの名無しさん：2007/05/29(火) 00:07:49

とりあえずアセンブラな部分をCOBOLにリプレースしたい
話はそれからだ

235 ：デフォルトの名無しさん：2007/05/29(火) 12:33:29

本当に"死んで"いる? さびれゆくコンピュータスキル"トップ10" - 米誌調査

米『Computerworld』誌は24日(現地時間)、「死んだ(または死につつある)コンピュータスキル」を10種挙げるという
記事を公開した。サブタイトルには「あなたのスキルをアップデートすべきでは?」とあり、どちらかというと前向きな
提言というニュアンスを込めたいのかもしれないが、必ずしもそう感じられる文章ではない点は少々残念なところだ。

以下、そのリストと説明文を紹介しておこう。

1. COBOL

Y2Kは、腕をふるう機会が減りつつあったCOBOLプログラマにとって「2度目のゴールドラッシュ」となった。しかし、
それから7年近く経過した現在、この忘れられつつある言語の救世主の影もまったく見えない。同時に、コンピュータ
サイエンス関連の大学のカリキュラムでCOBOLが教えられることもほとんどなくなっているが、「メンテナンスを続け
なくてはいけないCOBOLアプリケーションを運用している組織はまだ何千も存在している」という声もある。

http://journal.mycom.co.jp/articles/2007/05/28/deadskills/index.html

236 ：デフォルトの名無しさん：2007/05/29(火) 12:35:14

第5回　失敗を恐れたら前に進めない

リスクを考え転職するか悩む
　
　Mさんは大学卒業後、小規模なソフトハウスに入社しました。大学の専攻は文系学部でしたが、ITスキルが
将来重要になると考え、IT業界を中心に就職活動をし、3社から内定をもらうことができました。その中から、
規模は小さいものの、いろいろ先輩から教わることもできそうな、幅広い年齢層の先輩がいる企業に入社を決めました。

　Mさんは入社後に汎用機の保守を中心に行う部署に配属されました。学生時代はITに関してほとんど接する
ことがなかったMさんにとっては、汎用機だろうと保守だろうと新しいことばかりでした。

　しかしIT業界のことを少しずつ学んでいく中で、汎用機の保守作業のキャリアは評価があまり高くないということを
知るようになったのです。

　会社の中では、上流工程に携わっているITエンジニアもいます。しかし、上流工程にかかわることのできる社員は、
ほとんど自分よりもかなり年齢が高い人ばかりでした。汎用機以外の仕事ができる可能性を求めてプロジェクトの
転換を希望してみましたが、思いどおりになりませんでした。

（全文）
http://jibun.atmarkit.co.jp/lcareer01/rensai/debug05/debug01.html

237 ：デフォルトの名無しさん：2007/05/29(火) 13:53:38

ま、IT系の技術なんて水物だからね。
上２つの文から受けた印象は
メンテナンスを続けなければならないCOBOLを運用している組織が
まだ何千も存在しているならば、まもなく定年を迎える人たちが
携わっている上流工程を保守できるスキルは評価される機会はある。
って感じ。

238 ：デフォルトの名無しさん：2007/05/30(水) 01:37:18

>>233

誰がうまいことを書けとｗ、、、。

239 ：デフォルトの名無しさん：2007/06/07(木) 17:55:56

COBOLのおばちゃまってイージス艦の名前に取られてるのな。

240 ：デフォルトの名無しさん：2007/06/14(木) 03:13:13

LispはCOBOLより古いし、COBOLと比べれば弱小勢力に過ぎない。
しかし、Lispは古くさい言語だとは思われてない。

COBOLはLispより新しいし、今もなおLispとは比べるまでもない大勢力だ。
それなのに古くさいカビの生えた前世紀の遺物と思われてる。

この差はいったいなぜ？

COBOLにだって今もなお学ぶべき優れた点があるというのに。
可読性を重視し、読みづらい省略表記を使わないという長所なんて、
未だにCOBOLに遠く及ばない言語も多数あるというのに。
(たとえばPerlとかPerlとかPerlとか)

なぜCOBOLにはこんなに古くさい、
いまさら取り上げるべき長所なんか皆無の
惰性だけで使われてる言語という
イメージができてしまったのだろうか？

241 ：デフォルトの名無しさん：2007/06/14(木) 08:45:55

>>240
一番効いてるのは、使ってるプログラマ層の差だろうね。

242 ：デフォルトの名無しさん：2007/06/16(土) 04:26:47

俺が思うにCOBOLの最大のネックは
安価で導入が楽な、個人PC用の決定的な環境が
無いことなんじゃないかなぁと。

Lispはフリーのエディタに付いてくるし
そもそも主なターゲットである言語研究者なら
自分で実装できてしまうようなシンプル設計。

PerlはWinならActivePerlをインスコすればOK、Linux系なら準標準。
書き捨て言語と割り切ってる設計だから慣れれば速記性がある。
文字列処理に強いのもポイント高い。
今でこそテキスト処理に重点を置いたスクリプトが台頭して
PHPみたいなWeb専門の言語もあるが、一昔前は
CGIをやりたいが為に導入した奴もかなり多いと思う。

PascalはDelphiで覚えた奴が多そう。普及に一役かっただろうな。
入力補助してくれるIDEがあれば冗長性も大して気にならないし
あれだけのライブラリがあれば言語関係なく使えると思う。

COBOLのフリー環境はあるが、ライブラリが不足だったり
中途半端だったりインストールが面倒だったり。
あの冗長なコードをテキストエディタで書くのもちょっと…。
かと言って、商用は異様に高いし…。
やはり汎用機の時代を引きずってる印象は否めないんだよなぁ。

243 ：デフォルトの名無しさん：2007/06/17(日) 17:50:57

>Pascal
大学で仕方なく覚えたやつも多そう

244 ：デフォルトの名無しさん：2007/06/17(日) 22:06:43

>>242
COBOLが帳票出力言語な事につきるんじゃねー？
使いやすいフリーのIDEがあったとしても、
帳票出すプログラムなんて個人ユースには必要ない

245 ：デフォルトの名無しさん：2007/06/19(火) 21:25:02

COBOLは確かに今でも大勢力ではあるが、
PCユーザとは全く無縁の所でしか使われてないから
PCユーザにとっては「COBOL？　なにそれ？」になってしまう。
そして現代のコンピュータユーザの95%はPCユーザだ。

同じ古い言語でもLISP、C、PASCALなどは
PCの世界で使われてるからPCユーザが目にする機会は多い。

違いといえばそれだけだろう。

246 ：デフォルトの名無しさん：2007/06/20(水) 09:25:33

>>245
COBOLスレでコンシュマーな話されても。。。

247 ：デフォルトの名無しさん：2007/07/06(金) 10:37:54

田原いわく、社保庁の不祥事は「COBOLが悪い」のだとさ。（爆笑）
http://www.nikkeibp.co.jp/style/biz/column/tahara/070705_18th/

田原のぞっとするほどの無知無学さに喫驚。っていうか、呆れた。

248 ：デフォルトの名無しさん：2007/07/06(金) 15:14:19

> 彼がいうには、いまだに社保庁のシステムはCOBOLというプログラム言語を使っているという。
> これは彼が学生時代に使っていたもので、40年も前のものだ。
> つまりこの年金の問題は、あまりにも古いシステムとハードを使っていることから起きたのだ。
> なぜこのようなことが起きたのかというと、まさに社保庁は倒産しないからだ。
> 一般企業ではそんな古いものを使っていれば、数字が無茶苦茶になって倒産するから、
> 何年かに1回は切り替えている。それを社保庁は、40年も切り替えないできた。

ﾋﾃﾞｰ。言語やハードがいくら古かろうが
コンピュータは寸分の狂いもなく "命令どおり" に動いているというのに・・・
手持ちの電卓たたいて変な数字が出てきたら誰のミスか？ということを考えなおして欲しい。

249 ：デフォルトの名無しさん：2007/07/06(金) 20:38:40

> なぜこのようなことが起きたのかというと、まさに社保庁は倒産しないからだ。
うちの病院はもう40年もシステムを継ぎ接ぎ継ぎ接ぎしながら
使い続け、一円のミスも起こしてませんが・・・・・・・・・・・・・
COBOLなんですけど・・・

250 ：デフォルトの名無しさん：2007/07/06(金) 23:14:17

こんなニュースがあった

「時効年金」受給申請初日、連絡不手際で一部受理されず
http://www.yomiuri.co.jp/national/news/20070706it07.htm

今日から年金の時効を撤廃する法律が施行されたのに、社会保険庁からの
指示のメールを社会保険事務所の馬鹿が見てなくて「社会保険庁から何も
聞いておらず、手続きの方法も指示されていません」と言って申請に来た人を
追い返したそうだ

こんな馬鹿にはどんなシステム作ってやっても無駄じゃねえのか？

システム入れ替える前に人を入れ替えろやっ！

251 ：デフォルトの名無しさん：2007/07/07(土) 00:00:47

倒産しないから何でもアリだな。うらやましすぎる。
俺に立派な大学を出られる頭脳と財力があったら社保庁入りたい。

252 ：デフォルトの名無しさん：2007/07/07(土) 01:00:07

未だ多くの(少なくとも国内の)金融機関での勘定系処理はCOBOL。
なのに、社保庁のCOBOLだけが悪いのかが不明。

しかし国会議員の無知は怖い。
システムの移行に2年や4年でできると思っているのか。

第3次オンライン後、ハード、ソフトを新規で完全にリプレイスした銀行ってどこよ。

253 ：デフォルトの名無しさん：2007/07/07(土) 14:39:39

年金の例の問題がCOBOLのせいだとでも言うのか？

254 ：デフォルトの名無しさん：2007/07/07(土) 17:22:40

>>253
そう言ってる馬鹿がいる
で、この世には日経信者のおっさんがいて
その記事を鵜呑みにしちゃうかも・・・

255 ：デフォルトの名無しさん：2007/07/07(土) 21:50:23

>>252
新生銀行（長銀）があるじゃん
都銀に同じことが出来るかどうかは知らんが

256 ：デフォルトの名無しさん：2007/07/08(日) 11:23:08

年金問題はCOBOLなんて古い言語を使ってたせい
by サンプロ

257 ：デフォルトの名無しさん：2007/07/08(日) 20:53:33

なんという馬鹿な議論
ＣＯＢＯＬいまだに重要な言語だろ。
銀行、行政機関、事務系　いまだに普通に使っている。
いい言語だと思う。

258 ：デフォルトの名無しさん：2007/07/08(日) 21:02:24

大工もげんのうやのこぎりといった古い道具を使って
家を建ててるので、家は欠陥品

259 ：デフォルトの名無しさん：2007/07/08(日) 21:21:49

>>258
うまい。
そのようなことを言っているとしか思えない。

260 ：デフォルトの名無しさん：2007/07/09(月) 04:26:42

>>257
PG初心者なのですが・・・・これ新聞読んでて首ひねってたのです。
「・・・・ＩＴコンサルタントによると使用しているプログラミング言語もCOBOLという
古い世代の言語であり、今の言語なら１行ですむものを３行で云々・・・・」

とどのつまり、最終的には機械語にコンパイルするのですから、
言語仕様をどうこう言うのはおかしいと感じたのですが、プロのPGのかたからみたら
どうなのですか？何か問題があるのでしょうか？よく分かりません＞＜
要するに、如何なる言語を使用しようが、codeが最適か否かの問題ではないの
ですか？

261 ：デフォルトの名無しさん：2007/07/09(月) 06:38:05

マスゴミの発表をまにうけるな、って思うが。

ただまぁ、「いい言語」と言われたら「２０－３０年前は」と
漏れも答えるが。

まあこの場合は使う人間がおかしいって事でFA

262 ：デフォルトの名無しさん：2007/07/09(月) 06:39:58

>>260
全然、古くないよ。
世界中で金融系・事務系に幅広く使われている。

263 ：デフォルトの名無しさん：2007/07/09(月) 06:46:18

>>261
安定しているといえばいい言語。

264 ：デフォルトの名無しさん：2007/07/09(月) 07:26:18

＞金融系・事務系に幅広く使われている。

漏れの知っている某都銀では
Javaとかにシフトしつつあるけどな。

今は幅狭く使われているよ。＞COBOL

ただまあ、新規案件でCOBOL持ち出すアフォが実在するのも事実だしなぁ。

265 ：デフォルトの名無しさん：2007/07/09(月) 10:42:30

田原総一郎の無知無学ぶりを顕彰する！
どはははは。

266 ：デフォルトの名無しさん：2007/07/09(月) 17:23:41

>>262
逆に金融・事務系で切替が進まなかったことが不思議。COBOL自体にできることは少ないから、結局、
多言語とのインターフェースだらけになって、後になって、scratchから書いた方が早いなどと言う自体に
なる。

267 ：デフォルトの名無しさん：2007/07/09(月) 18:26:07

入出力をはっきり定義して、その間の手続きを記述する言語。
知識ベースを作るのに向かないというか言語外のDB頼りとなる。
従ってCOBOLだけで実世界のモデルを記述することが困難。
これが、メーンフレームで未だに気の利いたことができない理由。

268 ：デフォルトの名無しさん：2007/07/09(月) 18:30:58

メインフレーム?

269 ：デフォルトの名無しさん：2007/07/10(火) 22:52:10

いくつかの銀行系のシステム開発に携わっているけれど、
プログラム単体の中ででDBを直接アクセスするコードって書いたこと無い。
DBアクセスするようなのは、全て外部モジュールをCALLだったけど。

何千とあるプログラムでcoderの勝手に書かれちゃメンテナンス出来ません。

270 ：デフォルトの名無しさん：2007/07/10(火) 23:01:03

FILLERとか言う文字エリアにパック１０進数を叩き込んであって
それを読み出す為に、プログラム内でﾏﾝﾄﾞｸｻｲ内部定義切って
アレコレしてたりするんだが、あれはある意味DBを直接アクセスしてるのと
大差ないと思うんだが。

SQLであんなワザはできんしな。

271 ：デフォルトの名無しさん：2007/07/11(水) 15:11:38

>>269
その外部モジュールというのは何をやっているのですか?
一般にどんな言語で記述されているのですか?

272 ：デフォルトの名無しさん：2007/07/11(水) 22:42:24

>>267
そういう用途にわざわざ汎用機使うのは無駄じゃねー？
それなりの性能のサーバにUNIXぶち込めば万事OKな気が。安いし

273 ：デフォルトの名無しさん：2007/07/12(木) 20:44:31

でもCOBOLってソレしか出来ない言語だしな

274 ：デフォルトの名無しさん：2007/07/14(土) 20:08:19

>>271

COBOLのものもあれば、アセンブラのものもありました。
用途や使用頻度、要求される速度によって違います。

275 ：デフォルトの名無しさん：2007/07/15(日) 01:43:31

コボラーになりたての者です
COBOLを学ぶに良い本を教えてください

276 ：デフォルトの名無しさん：2007/07/15(日) 10:43:43

>>275
>>160

277 ：デフォルトの名無しさん：2007/07/19(木) 22:15:07

>>275

>>160 がいうようにソースを読め。もしあるならJob Flow

278 ：デフォルトの名無しさん：2007/07/19(木) 23:34:46

>>275
マニュアル
マニュアルをまともに読まない（読む時間がない）人も多いので

279 ：デフォルトの名無しさん：2007/07/22(日) 11:37:21

COBOLじゃないんですけど
EasytrievePlusの日本語マニュアルってPDFで
ありませんか？
英語版しか見当たらなくて。。。

280 ：田原はアルツハイマーか：2007/07/23(月) 06:23:36

年金、田原総一朗、COBOLが悪い発言
http://iiyu.asablo.jp/blog/2007/07/23/1674169

281 ：デフォルトの名無しさん：2007/07/23(月) 15:11:53

>>269
何か、再利用しにくい資産だね。ソフトウェアも高額なら資産に計上して良いはずだと
思うけれど、時価では価値低そうだね。

282 ：デフォルトの名無しさん：2007/07/23(月) 15:15:08

>>280
もう、技術者がいなくなってきているし、当たらずとも遠からず、じゃないの。
後で入力のチェッカーなんて作ろうとする奴が何十年も現れなかったのだし...

283 ：デフォルトの名無しさん：2007/07/24(火) 18:46:23

COBOLってプログラミングした奴のエラー以外は素直に動くよな

284 ：デフォルトの名無しさん：2007/07/26(木) 10:18:35

>>283
うん。汎用機を持ち続けることが出来るなら無理に言語変更はしなくても大丈夫だと思う。
あまり新しいことは出来ないけど、裏で動かすバッチだったら安定してるしね。

285 ：デフォルトの名無しさん：2007/07/27(金) 12:56:21

>>284
うちの会社のデータベースはＪａｖａと連動してオンライン化してるけど
１回もＣＯＢＯＬが原因でエラーになったことないから
御国の言ってることが何だか分かりませんよ、やれやれ

286 ：デフォルトの名無しさん：2007/07/27(金) 16:53:13

プログラマ側の都合は別にして、大規模ハードメーカがCOBOLのサポートを順次
停止してきます、と将来言い始めたら、さてどうするのかな？　COBOLはオプション
で別契約別料金とします、これが一番いい。

287 ：デフォルトの名無しさん：2007/07/27(金) 20:14:33

>>286
銀行などの大口客を敵に回す気？

288 ：デフォルトの名無しさん：2007/07/27(金) 21:34:37

>プログラマ側の都合は別にして、大規模ハードメーカがCOBOLのサポートを順次
>停止してきます
ばかー？

289 ：デフォルトの名無しさん：2007/07/27(金) 21:52:53

つまりRPGの時代が(ry

290 ：デフォルトの名無しさん：2007/07/28(土) 00:58:42

これからはオープン系＝ＡＳ４００の時代に(ry

291 ：デフォルトの名無しさん：2007/07/28(土) 01:47:51

>>289-290
それは大ボラ。ｗ

292 ：sage：2007/07/29(日) 00:07:26

>>289-290
おいおいそりゃあWKENだろう

293 ：棒線レーサー：2007/07/31(火) 14:07:44

待て、この流れでいくと初心に帰ってBASIC！！

294 ：デフォルトの名無しさん：2007/08/01(水) 22:20:30

現場に配属になったＹＯ

研修ではゼロからコーディングしていったけど、
現場では、生産性高める為にヒナ形があって、パラメータとかちょこっと
変えてやるだけでいいのね。。。
プログラムよりも、現場独自のツールとかテスト結果の読み方とか勉強
するのが大変。

295 ：デフォルトの名無しさん：2007/08/02(木) 21:50:14

>>294
そう。それ以上に大変なのが業界ごとのお約束。部外者には、なんで、ここでこういう処理をする？って事ばっか。

296 ：デフォルトの名無しさん：2007/08/04(土) 09:51:56

シェル環境でCOBOLのプログラム実行すると「sysout」ってファイルができるんだけど何かコーディングがまずいのかな？

297 ：デフォルトの名無しさん：2007/08/04(土) 22:31:42

なんという釣り餌

298 ：デフォルトの名無しさん：2007/08/08(水) 06:20:29

釣りとかじゃなくて本当に困ってるんです！

299 ：デフォルトの名無しさん：2007/08/10(金) 10:14:52

AGEND

300 ：デフォルトの名無しさん：2007/08/11(土) 09:34:10

COBOLってデータベースからデータ取ってきて加工して返すような案件があるけど、
それってクエリの代わりを作ってるっていうことなのか。

301 ：デフォルトの名無しさん：2007/08/11(土) 18:56:25

やっぱ大量データのバッチ処理の分野じゃ
メインフレーム＋COBOLが最強だわ。断言できる。
金融機関の社内SEだけど、これからもずっとCOBOLでやっていくことで
社会コンセンサスは取れてる。
今は一部のアセンブラ資産をCOBOLに順次切り替え中。
メインフレームのアセンブラ使いこそは、まさに絶滅危惧種だからな。
これでうちのシステムはあと何十年でも戦える。

302 ：デフォルトの名無しさん：2007/08/13(月) 06:34:50

＞金融機関の社内SE
別にどーこー言うつもりもないが、
自分の居場所を守る行為はそれはそれで普通だけど
COBOLerをアセンブラ使いを絶滅危惧種扱いはどーなのかと。

漏れの知っている某金融機関はアセンブラ:COBOL=8:2って
感じで、そもそもそのCOBOLは派遣(?)が作った部分だったりするが。

いや、その開発部署は８割が派遣で出来ているんだけどな。w

303 ：デフォルトの名無しさん：2007/08/13(月) 06:35:28

ｽﾏｿ

＞COBOLerをアセンブラ使い
COBOLerがアセンブラ使い

304 ：デフォルトの名無しさん：2007/08/13(月) 10:36:30

メインフレーム扱ってる奴ならCOBOLもASSEMBLERも使えて当然な気もする
JAVAも含めた三刀流は珍しいかな

305 ：デフォルトの名無しさん：2007/08/13(月) 13:05:03

トキの絶滅を危惧するヤンバルクイナがいると聞いて飛んできますた！(`・ω・´)

306 ：デフォルトの名無しさん：2007/08/13(月) 23:43:27

コボルの開発環境は進化を続けているが
コボラーが進歩していない、どころか退化しているのが現状。

307 ：デフォルトの名無しさん：2007/08/14(火) 00:01:28

>>304
そりゃまあ、バッチ処理みたいな単純な読み書きに計算、分岐処理しかやらないんだったら
アセンブラもコボルも出来て当然だと思うが。

分野が違うけどＣやアセンブラでリアルタイムなアクションゲーム作るのとは次元が違うしな。

308 ：コボちゃん：2007/08/15(水) 13:16:41

コボちゃん

309 ：デフォルトの名無しさん：2007/08/15(水) 22:19:51

COBOLの進化についていけるようなコボラーはとっくにCやJAVAに乗り換えてる罠

310 ：デフォルトの名無しさん：2007/08/15(水) 22:48:22

COBOLはキーワードがかっちょいいんだよな。
DIVISIONとかＳＥＣＴＩＯＮとかさ。
WITH TEST AFTERなんて、もううっとりしてしまう。
COBOLに一生付いていくよ。

311 ：デフォルトの名無しさん：2007/08/15(水) 22:58:19

COBOLerが絶滅危惧種？
１年前まで、COBOLerだらけの楽園にいましたが...？

312 ：コボちゃん：2007/08/16(木) 07:34:36

コボちゃん

313 ：デフォルトの名無しさん：2007/08/16(木) 17:33:36

こぼらあｗ

314 ：デフォルトの名無しさん：2007/08/17(金) 17:48:52

俺、ＣＯＢＯＬの経験ありってことで、システム維持管理の仕事をするように会社から言われた。
具体的にはどういった仕事をするの？
経験者の方のコメントを求む。

315 ：デフォルトの名無しさん：2007/08/17(金) 19:04:49

>>314
アホかｗ
お前の会社のシステム維持管理が
どういう仕事かなんて俺らが知るかよｗ
上司や先輩に聞けｗ

316 ：デフォルトの名無しさん：2007/08/17(金) 19:57:48

どこかで見たような・・
http://pc11.2ch.net/test/read.cgi/prog/1120922010/844-846

317 ：デフォルトの名無しさん：2007/08/18(土) 00:36:03

>>310
釣られてみる

WHTH TEST [AFTER | BEFORE]が好きな奴は変態

318 ：デフォルトの名無しさん：2007/08/18(土) 15:44:23

314です。
俺の会社ではなく、今度新しくこの会社（ソフトハウス）に入社し、この会社が開発したＣＯＢＯＬのシステムの維持管理です。
具体的にはどういった仕事をするんですか？
経験者の方のコメントをお願いします。

319 ：デフォルトの名無しさん：2007/08/18(土) 15:50:44

予備知識?

320 ：デフォルトの名無しさん：2007/08/18(土) 17:03:44

COBOLの保守？
臭いモノにふたをして（見なかったことにして）上辺だけを見繕い、
世の中（と自分）を誤魔化しながら生きていくって感じ。
まあトラブルさえなけりゃ一日中マンガ読んでいても大丈夫な現場じゃね？
技術的な向上心を望んでいる人には地獄だと思うけどな。

321 ：デフォルトの名無しさん：2007/08/20(月) 12:43:21

10　PRINT　ﾞこぼらー乙ﾞ
20　GOTO 10

RUN

322 ：デフォルトの名無しさん：2007/08/20(月) 20:25:20

>>321
それはBASIC

323 ：デフォルトの名無しさん：2007/08/20(月) 23:39:10

warota

324 ：デフォルトの名無しさん：2007/08/21(火) 00:37:14

DISPLAY 'こぼらー乙'.
STOP RUN.

325 ：コボちゃん：2007/08/21(火) 14:42:27

コボちゃん

326 ：デフォルトの名無しさん：2007/08/22(水) 17:18:26

MAIN
PERFORM DISP-RTN THRU DISP-RTN-EXT UNTIL 10000 TIMES.
STOP RUN.

DISP-RTN.
DISPLAY NC"こぼらー乙".
DISP-RTN-EXT.
EXIT.

久々に書いたよ。ボコル。
久々にNumLockをonにしていたよ。ボコル。

327 ：デフォルトの名無しさん：2007/08/22(水) 17:39:11

コンパイル通らないね

328 ：デフォルトの名無しさん：2007/08/22(水) 19:30:19

>>326
なんて美しいコード…やっぱコボルが一番だな。
CとかJavaの軟弱な小文字ソースを見ると吐き気がする。

329 ：デフォルトの名無しさん：2007/08/28(火) 23:33:53

ケース１：
A PIC S9(03)　VALUE -123.
B PIC X(2).
MOVE A(3:2) TO B
上記だとBには「23」が設定されますよね？

ケース２：
A PIC S9(03)　VALUE 123.
B PIC X(2).
MOVE A(3:2) TO B
上記だとBには「23」が設定されますか？

ケース２の実行結果がわかりません。
ご教示願います。　( ･∀･)ﾉ

330 ：デフォルトの名無しさん：2007/08/29(水) 00:00:25

A領域、B領域...

331 ：デフォルトの名無しさん：2007/08/29(水) 00:16:46

ケース1も怪しい気がする。
ZONE形式で符号付きの場合、一番ケツに符号を持ってたと思う。
（持ち方は環境依存かもしれない。）
-123　だからと言ってS9(3)は4文字にはなっていないんじゃないか？

332 ：デフォルトの名無しさん：2007/08/29(水) 00:50:04

>>331
その辺は言語仕様として固まって無いんじゃ
俺はCOMPオプションで出力されるデータ型が決まるみたいに考えてた

333 ：デフォルトの名無しさん：2007/08/29(水) 00:55:12

>>331
おいおい、MOVEするときに型変換されるに決まってるじゃないか。
つまりケース２は「23」で正しいかと。

334 ：329：2007/08/29(水) 08:11:37

みなさん、ご教示ありがとうございます。

ということは・・・
「A PIC S9(03)で変数Aを宣言すると４文字分の領域（符号領域＋３桁の数値領域）が
確保され正の数のとき、右詰で数値が設定される」
という認識であってますか？

335 ：デフォルトの名無しさん：2007/08/29(水) 09:38:02

>>334
REDEFINES して調べてみたら?

336 ：デフォルトの名無しさん：2007/08/29(水) 10:03:06

>>335
>>333 はREDEFINESとMOVEで動作が違うといってるな。
どういう動作になるのかは言語仕様にあるかわかんね。コンパイラ依存だろうか。

337 ：デフォルトの名無しさん：2007/08/29(水) 12:50:06

>>329
>>334
俺の環境だとコンパイルすら無理、どっちのケースでも
MOVE A(3:2) TO B
が異常あつかい

俺の環境だとAは3バイトあつかいなので、
3桁目から2バイトだと領域オーバーだから

いぜう

338 ：デフォルトの名無しさん：2007/08/29(水) 14:45:43

>>318
COBOLだけのシステムって、何が作れるの？
middle wareだらけじゃないの？

339 ：デフォルトの名無しさん：2007/08/29(水) 15:38:03

>>338
ミドルウェアに依存しているのはどの言語も同じ
って言うか、オープン系の言語の方がその傾向が強いんじゃねーか？

340 ：デフォルトの名無しさん：2007/08/29(水) 17:11:43

>>339
開発の規模とプラットフォームによるだろうけれど、例えばCで統一する方が、ミドルウェアから、GUIまで
一貫性があるんじゃないの？　それか小規模のシステムなどは、スクリプト型言語でランタイムライブラリに
全部依存する方が開発が早いのでは？

341 ：デフォルトの名無しさん：2007/08/29(水) 17:57:27

小規模のシステムでCOBOLによる開発が早くないことは
最初からわかってることでは? つまり、そんな観点で
COBOLが選ばれている訳ではない。

342 ：デフォルトの名無しさん：2007/08/29(水) 22:27:31

いざとなったらUNIX-COBOLERになればいいのさ

UNIX自体についてはできる人か講師の先生に教わればいいんだし
経験者曰く、毎日やってりゃ嫌でも覚える、とのこと

343 ：デフォルトの名無しさん：2007/08/29(水) 22:37:12

アナログ人間の俺にはコボルが精一杯
もう30になるので、これからどうやって食っていくか考えなきゃ

344 ：デフォルトの名無しさん：2007/08/30(木) 10:00:52

中小企業といっても千差万別だが、
ほとんどの企業でPC2台(一台はバックアップ)で済むよ。

345 ：デフォルトの名無しさん：2007/08/30(木) 13:15:25

>>314
異常終了とかしたら、ダンプだのトレースだの
他の人が手を加えて継ぎ接ぎだらけのＡＰをデバックする
次に異常終了したら、担当じゃないとこまで責められる。

俺は銀行系の運用携わってたけど、死ぬかと思った。
夜中に呼び出され知らないことで問い詰められ、
朝までにデバック～テストして本番に移行する。

この仕事やる前に、運用保守って聞いて受けないでおこうと思ったけど。
金に釣られてやった俺がバカだった。

最後は強引に辞めちゃった。
二度と子守りなんてごめんだ。

346 ：デフォルトの名無しさん：2007/08/30(木) 13:37:16

>>344
どんだけしょぼい会社しか知らないんだよ。

347 ：デフォルトの名無しさん：2007/08/30(木) 15:31:55

９月の３日からクレジットカード系のコボルの開発に行くんですが
まったくやったことないんです。　初級、新卒レベルOKの案件なんで大丈夫だと思うんですが
これだけは入場する前にやっておけというのはありますか？

C,C++,JAVA,VBはやってます

348 ：デフォルトの名無しさん：2007/08/30(木) 21:40:26

>>347
>C,C++,JAVA,VBはやってます
まったく役に立たないからな。むしろ苦痛になるぞ。

349 ：デフォルトの名無しさん：2007/08/30(木) 22:16:39

頭の切り替えが大変そう w

350 ：デフォルトの名無しさん：2007/08/30(木) 22:44:34

>>347
他の言語を知ってれば知ってるほど、コボルは辛いかもね,,,

351 ：デフォルトの名無しさん：2007/08/30(木) 23:59:39

>>348
それはいい過ぎ

Ｃが出来れば後は文法覚えるだけ
VBが出来れば文法も半分覚えてる

C++ JAVAはいらね。窓から投げ捨てろ

352 ：デフォルトの名無しさん：2007/08/31(金) 00:10:16

コボルしか知らない俺でも金融系のコボルは苦痛・・・
特にオンライン・・・
プログラムが果てしなく深く、そして汚く、下へ下へと繋がって、他系システムに
連動している・・・
メインフレームのシステムはドキュメントが無い
プログラムとJCLのみ

組んだ奴しか知らないことばかり

運用兼開発は朝から晩まで大変らしいね
開発か運用のどちらかに専念できる会社じゃないと体がもたないよね

353 ：デフォルトの名無しさん：2007/08/31(金) 23:10:19

つか、金融系がCOBOLの最後の砦なんだから
そんなに嫌ならC++かJavaに譲ってやれよ。ｗ

354 ：デフォルトの名無しさん：2007/09/01(土) 09:07:39

CやVBのコーディングスタイルに慣れていると、
COBOLはつらいかもね。

うちの会社だけかもしれないけど。

355 ：デフォルトの名無しさん：2007/09/01(土) 09:28:21

つ ttp://anond.hatelabo.jp/20070831005830

356 ：デフォルトの名無しさん：2007/09/01(土) 09:46:12

漏れも金融系の仕事してるけど、>>355はまあ、そういうものだよな。
COBOLが悪いと言うか、あの辺りはそういう体質なんだから、
慣れるしかないな。

つーか今は亡き(w)UFJなんかCOBOLじゃなくてアセンブラ全盛だったぞ。
COBOLで贅沢いうんじゃねーよ。って感覚だったな。

漏れも久しぶりに64Kの壁やらセグメントって概念思い出したし。

357 ：デフォルトの名無しさん：2007/09/05(水) 14:34:09

Fの汎用機のデータ(VSAM)をＣＳＶ形式に落としたいのですが、F*TRAN以外に
何か変換できるソフトはないでしょうか？

データは、EBCDIKとJEFコードで、ファイル転送は、ＰＦＤのFIMPORTを使用しています

教えてエロい人・・・スレチの場合は、誘導願います。

358 ：デフォルトの名無しさん：2007/09/05(水) 16:23:18

>>357
F*TRANだとどういう風に具合が悪かったの？

359 ：デフォルトの名無しさん：2007/09/06(木) 09:31:08

>>357
その流れでF*TRANいるのか？
FIMPORT終了でPC上のﾌｧｲﾙ(CSV)になっているのでは？
PFDのFIMPORTってPC上でやってるんじゃないの？

360 ：357：2007/09/06(木) 10:53:53

358 さん返信ありがとう

F*TRAN が不具合と言う訳ではなく、該当ソフトを模索している最中なので、F*TRANは既に
候補にあがっているので、～以外としました。

それと、ＪＥＦ変換の精度が、50％ぐらいだとＨＰに書いてあったような・・・

359 さん返信ありがとう

＞PC上のﾌｧｲﾙ(CSV)になっているのでは？
確かにＣＳＶ形式になっているのですが、1レコード単位なので、基本項目別に、カンマをいれるには
ファイル毎にカンマ編集のプログラムを組んでＰＣに送らなければならないので、ＰＣ側でF*TRAN等
が必要だと思いました。（10～20程度のファイルならプログラムも組みますが、100を超えるもので）
　　　　
理想的には、ＶＳＡＭファイルをホストのワークファイルにする
　　　　　　　　　　　　　　↓
　　　　　　　　　　ファイル転送(FIMPORT)でＰＣに転送
　　　　　　　　　　　　　　↓
　　　　　　　　　　変換ソフトを使いＰＣ内で項目別カンマのファイルに変換　→　ＰＣ利用

カビの生えたレガシープログラマに愛の手を・・・

361 ：358：2007/09/06(木) 12:34:51

>>360
その流れで処理するのがベストです。

よく使われているレガシーデータ変換ツールは、
　F*TRAN+
　AnyTran
　Hulftデータ変換Pro
　Pervasive Data Integrator(旧Data Junction)
のあたりですね。この中からコストと漢字変換機能を重視して選ぶと、
F*TRAN+の一択になってしまうと思います。漢字変換テーブルが標準で
付いてくるのが大きなポイントです。試用版をDLしてまず使ってみては？

もっと大きくEAI/ETLツールという枠組みで考えると、他にもレガシーデータに
対応した製品/システムはいろいろとあります。でも、価格が2桁ほど
跳ね上がってしまうので、現実的ではないでしょう。

362 ：デフォルトの名無しさん：2007/09/06(木) 12:56:47

358 さん　早速のレスありがとうございます

試用版が、有ったんですか、文字通り試してみます。

363 ：デフォルトの名無しさん：2007/09/08(土) 01:36:18

そんなあなたに
ACUCOBOL
これ最強！

364 ：デフォルトの名無しさん：2007/09/08(土) 02:05:31

COBOLといえば、二つのファイルから一レコードずつ
読み出してのマッチング処理というのが
入門書の例題における定番ですが、
Cなどの参考書ではとんとお目に掛からない。
もしかして、他の言語ではマッチング処理ということ
自体、存在しない概念なのかな？

365 ：デフォルトの名無しさん：2007/09/08(土) 04:25:24

>>364
うん。必要ない。

366 ：デフォルトの名無しさん：2007/09/08(土) 10:13:03

>>365
なんで必要ないんだ？

367 ：デフォルトの名無しさん：2007/09/08(土) 12:50:25

>>366
COBOLみたいなファイルを扱う世代から
RDBを扱う世代に移ってSQL使うようになったんじゃね？

368 ：デフォルトの名無しさん：2007/09/08(土) 13:16:01

しかしOracleに限っていえば、Pro*CよりもPro*COBOLのほうが
相性がいいというか、可読性が高い気がしている

369 ：デフォルトの名無しさん：2007/09/08(土) 18:14:35

>>367
ちょい質問なんだけど、中間ファイルを作ったり、シーケンシャルなファイル（テキストファイルとか）
を使ってどうのこうの　なんて作業はないの？

370 ：デフォルトの名無しさん：2007/09/08(土) 18:59:12

>>369
RDBの勉強しような。

371 ：デフォルトの名無しさん：2007/09/08(土) 20:20:38

>>369
マッチングは完全にＤＢ任せで、
中間ファイルはJavaなんかだとシリアライズして保存するのが多そう

372 ：369：2007/09/08(土) 23:06:21

>>370
へ～い w

>>371
ふむふむ　です w

373 ：デフォルトの名無しさん：2007/09/10(月) 21:49:00

>>368　同意
だが埋め込み SQL は可搬性が無くなる罠。
ロジックの切り分けって観点からしても、速度からしても PL/SQL だろ。
（SQL はどのみち別々に書く覚悟でな）

>>369
>>370 と重なるけど、少し詳しく言うと
通常は一発 SQL でだいたいの処理はできる。
きちんと設計された DB で一発 SQL だと遅いような場合、
中間データを作る事はまれにだがある。

それでもデータは一時テーブル（データを蓄える DB 上のストア）に置く。
Oracle はダメだったはずだけど一時テーブルを最後に捨ててくれたりもするし、
（エラー系の処理の実装が安全になるわけだな）
全てのデータ操作が SQL で書ける。

>>371 みたいな実装はすまんがちょっとイメージできない。
別システムへデータを移すのであれば、確かにあるけど、
処理中に中間データを DB の外に出すのはあまりないと思う。

そうするとソートもマージも全部 SQL で完結するようになるから単純だし、
基本的な操作はこなれたミドルウェア（DB）にまかせるって切り分けも完全だ。
DB のソート／マージ機能をライブラリみたいに使う感じか？

374 ：デフォルトの名無しさん：2007/09/10(月) 23:53:22

Javaでマッチングとかコントロールブレイクとか要らない理由って、
ユーザ定義クラスとかコレクションクラス使ってCOBOLのレコードより
もっと柔軟なデータ構造が表現できるからじゃないの?

375 ：デフォルトの名無しさん：2007/09/11(火) 20:26:10

ダメだ…CやJavaを10年くらい独学で
勉強してるけど、ハローワールドから全く進まねえや。
COBOLは三ヶ月で使えるようになったのに。
COBOLもCもJavaもバリバリっつー人いる？
どうやって勉強した？

376 ：デフォルトの名無しさん：2007/09/11(火) 20:30:28

Cは独学、COBOLは会社の研修、JAVAは独学中だったが飽きた。
別にバリバリっってほどでもないけど、、、
勉強法、1.読む、2.書く、3.試す。

377 ：373：2007/09/11(火) 20:40:48

>>374
メモリ上で処理できるなら COBOL だって索引表にデータを蓄えるだろ。
JAVA しかやってない世代には理解できないかもしれないが、
100 万を超えるデータを読み込んで突き合わせ、なんて処理が
COBOL の時代にはたくさんあったらしいんだ。
まさかそんなデータはメモリに読み込まないよな？
で、メモリに持てないから一度ファイルに書き出して処理するんだと。

今はその規模のデータを処理する事になっても、
中間テーブルにデータ持つよってのが >>373 の回答。
まあ、最近は正規化が進んだデータしか扱ってないから
滅多にそんな必要に迫られる事もないけどな。

>>375
C も COBOL も JAVA も使うが特別な事をやったつもりはない。
強いて言えば C のポインタが強敵だった。
あれだけは 5，6 冊本を読んで、
10 本近くプログラムをこなしてようやく何とかなった感じだ。

378 ：デフォルトの名無しさん：2007/09/11(火) 23:06:58

人の作ったのコピペで修正

379 ：デフォルトの名無しさん：2007/09/12(水) 15:40:49

Ｃのポインタってそんなに難しいのかな、アレはアセンブラの動きそのものなんだが
そこら辺をすっ飛ばして勉強しているからかな

380 ：デフォルトの名無しさん：2007/09/12(水) 18:53:47

Cのポインタはメモリのイメージが出来ていれば、難しくないはずだが。

が、まあ他人のソースで***pなのを見ると市ねとか思うのはある。

381 ：デフォルトの名無しさん：2007/09/12(水) 22:26:51

>>379
俺はBASIC、COBOLと来たもんだから、ポインタはさっぱり。
変数のアドレスか…ふーん…で終わってしまう。
星２つなんてとんでもない話で、変数のアドレスを持つ変数の
アドレスを持つ変数って、それイジメじゃんってレベル。
ああ、ポインタのないCOBOL大好きっ！

382 ：デフォルトの名無しさん：2007/09/13(木) 00:00:43

そっか、自分は初めて触ったのがCだったから
何の違和感も無く使えたけど
確かに、COBOLやBASICで入った人には分かりにくいかも寝

383 ：デフォルトの名無しさん：2007/09/13(木) 18:16:03

＞彼がいうには、いまだに社保庁のシステムはCOBOLというプログラム言語を使っているという。
＞これは彼が学生時代に使っていたもので、40年も前のものだ。
＞つまりこの年金の問題は、あまりにも古いシステムとハードを使っていることから起きたのだ。

http://www.nikkeibp.co.jp/style/biz/column/tahara/070705_18th/index.html

384 ：デフォルトの名無しさん：2007/09/13(木) 19:11:34

COBOLのリンケージって参照渡してるよね？

385 ：デフォルトの名無しさん：2007/09/13(木) 20:51:21

COBOLを使わせてるということは会社の上層部を騙してるってことでしょ
汎用機のほうが信頼性がありますよとかいって
クソ高いマシンを使わせてクソ言語でシステムを組む
コボラーは全員罪人だよ

386 ：デフォルトの名無しさん：2007/09/13(木) 23:53:13

>>385
あ？

同意

387 ：デフォルトの名無しさん：2007/09/14(金) 02:00:10

>>385
でも、コボラーはあそこから出てきて欲しくないってのもあるよ

388 ：デフォルトの名無しさん：2007/09/14(金) 04:33:56

言語の問題？ハードウェアの問題？どっちもか！？
マシン語で組んだらいいのか？

389 ：デフォルトの名無しさん：2007/09/14(金) 06:48:07

どんな言語使ってもRDBを順ファイルフォルダとして使っちゃう人たちだからなあ。
オツムのアーキテクチャの問題でしょ。

390 ：デフォルトの名無しさん：2007/09/14(金) 11:31:45

A4縦のリストでメートル級の関数書くのは止めて欲しい、保守するとき全面書き直ししたな

391 ：デフォルトの名無しさん：2007/09/14(金) 11:56:40

汎用機の信頼性が捨てがたいのと
安いマシンを冗長性持たせてパラで複数台動かすと
ランニングにコストがかかることから
汎用機の大企業での需要はここ最近伸びてるよ

コボル云々は別として汎用機卑下は筋違いでしょ
汎用機下にＬＰＡＲ切って複数台のＵＮＩＸ系のサーバ
動かせるしね

どこかの企業が数百台のサーバを数台の汎用機上の
バーチャル環境に集約させたことによって、電気代と
インフラに従事する人員をかなり削減できたため
高額な汎用機のメンテナンス費用を差し引いても
コストメリットが有ったらしい

392 ：デフォルトの名無しさん：2007/09/14(金) 18:13:51

安くて丈夫なPCサーバの方がパフォーマンスはずっと上だろ
ユーザーを囲い込んで独占商売する汎用機が
ものすごく割高なのは明らかじゃない

393 ：デフォルトの名無しさん：2007/09/14(金) 19:25:32

＞安くて丈夫なPCサーバの方がパフォーマンスはずっと上だろ

オマイは一度でも汎用機を使ってみてから語ってくれ。

そのPCサーバーは１分間に４０万トランザクションくらい軽く走るって事だよな。

394 ：デフォルトの名無しさん：2007/09/14(金) 20:08:52

自社開発の汎用機のCPUなんて
Intel製と比べたら遅いなんてもんじゃないぞ
その他あらゆる箇所が自社開発だからパフォーマンスで劣る

GoogleはやっすいPCサーバを大量に並列化してとてつもない
パフォーマンスを叩き出している
その汎用機はGoogleのトランザクションがさばけるのかね

395 ：デフォルトの名無しさん：2007/09/14(金) 21:14:25

と言われてもGoogleのデータセンターって火事があったりしたし、
そもそもGoogleのメールも極稀に止まったりして、
トランザクション結構とめてるんだけど、そういうのが許される世界と
許されない世界を無理に比較するのはアマチュアの思想だよな。

あと、googleの鯖は今は特別仕様のはずだが。
昔の広告宣伝のニュースに踊らされるなよ。

396 ：デフォルトの名無しさん：2007/09/14(金) 21:20:35

つか、Googleほどの天才集団ならPC使ってもパフォーマンスは出せるだろうが
392みたいな素人が安PCを数揃えても使いこなせんだろう。

397 ：デフォルトの名無しさん：2007/09/14(金) 22:22:09

>> そのPCサーバーは１分間に４０万トランザクションくらい軽く走るって事だよな。
そもそも普通の会社のバックオフィスの鯖に
分間40万トランザクションを捌く性能は要らない。

それにもかかわらずそんなものを売りつけるんだよ、汎用機屋は。

398 ：デフォルトの名無しさん：2007/09/14(金) 22:39:47

汎用機の性能はいつだってPCよりいいに決まってる
専用の高価なマシンがPC同等スペックだったら売れない

いっぽうでPCサーバーの安定性は昔よりはるかに向上してる
その点を攻めるのは汎用機側の驕りにすぎないね

汎用機が売れてるのは嘘つき営業が上層部騙して売ってるから
今どき汎用機じゃなきゃつとまらない処理なんてほとんどない
（特殊な用途ではあるよもちろん、完全に無用の長物じゃあない）

平時の負荷が全能力の10%とか切っててピークでも40%越えないとか
明らかにオーバースペックな汎用機を入れて喜んでる
ただのアフォだね

ダウンタイムだってそれでロスする損失、賠償とか営業機会なんかが
トータルで保守費用の差分を上回るなんて滅多ない
つまりわずかな利益のために目茶苦茶コストをかけてるってこと
はっきり言って騙されている以外の何ものでもないな

399 ：デフォルトの名無しさん：2007/09/14(金) 22:43:17

SunやHPやIBMのUNIX販売屋連中が、汎用機に少しでも近づくのが目標とのたまわっているのに・・・

400 ：デフォルトの名無しさん：2007/09/14(金) 22:53:38

汎用機アンチの発言に突っ込みどころ満載なんだけど
面倒なのであまりにもな１つにだけ

>>398
> ダウンタイムだってそれでロスする損失、賠償とか営業機会なんかが
> トータルで保守費用の差分を上回るなんて滅多ない
随分と無責任な世界に生息してるんだね

401 ：デフォルトの名無しさん：2007/09/14(金) 23:06:10

汎用機に近づくのが目標って
海外じゃ汎用機は既に置き換えが進んでほとんど消えている
日本は汎用機所有数世界一
保守的で技術に疎い上層部が食い物にされ続けてるのだ

402 ：デフォルトの名無しさん：2007/09/14(金) 23:10:58

いやいや、コボル＋汎用機は
人類が手にしうる最高の安定稼働環境。
PC鯖なんぞで安く済まそうと考えるような
上層部は無能と断言できる。
システムが企業の屋台骨だとわかっているなら
コボル＋汎用機にするはずだ。

403 ：デフォルトの名無しさん：2007/09/14(金) 23:15:58

つられないぞ・・・・

404 ：デフォルトの名無しさん：2007/09/14(金) 23:46:23

COBOLと汎用機が優秀だとしても、使い手のCOBOLerが無能じゃ仕様がない。

405 ：デフォルトの名無しさん：2007/09/15(土) 00:14:04

このスレの住人、実際に実物の汎用機を見たことない香具師が多数なんだろうな

406 ：デフォルトの名無しさん：2007/09/15(土) 00:50:04

>>405
それより有能なCOBOLer見たこと無いんだが

407 ：デフォルトの名無しさん：2007/09/15(土) 01:39:20

見たこと無いね
どこかにいるのかしら

408 ：デフォルトの名無しさん：2007/09/15(土) 01:59:36

>>400 >>398
汎用機が必要な業務もあるって書いてるんだし、
そういう重責任な業務は汎用機に責任転嫁してんじゃね？
仕様の変更に柔軟に対応できる低コストかつ無責任なオープン系と
ガチガチに仕様固めなきゃ開発進まない高コストだが安心な汎用機。
漏れもよくそう説明するぜ。

見積もりって意味じゃPCサーバーのダウンタイムって
リスクとしてカタログの数字通り見積もる。
でも確かにでかい数字にはならねー。
汎用機の保守費用と比べて圧倒的に低リスク＆低コストなのは間違いないな。
そういう勝負だとよっぽど神経質なとこじゃないと汎用機は売れない。

銀行の会計系のサーバーをPCサーバーにするとかいうのはバカだが、
企業のバックオフィスのサーバーならPCサーバーで十分。
（本当はweb系にこそ汎用機の性能を生かして欲しいんだけどな。
　数千万トランザクションとか安定して捌くよ？）

>>402
最高の安定環境ってのは認めるが、投資対効果が悪過ぎるだろ。
COBOLerだし、バックオフィスにはPCサーバー＋COBOLがいいけど。
今だったらよっぽどの事が無い限り汎用機を持ち出さない。
PCサーバーでトランザクションも十分さばけるしな。

ところで最近のPCサーバー、実際のとこどれくらい落ちるよ？
いままで2回落としたけど、スムーズに退避系に切り替わってたし、
漏れ、サービスを実際に完全に落とした経験ないんだけど、
そんなもんなのかな？

409 ：デフォルトの名無しさん：2007/09/15(土) 02:18:16

汎用機も落ちるときゃ落ちるよ

410 ：デフォルトの名無しさん：2007/09/15(土) 02:19:36

COBOLのコンパイラは貧弱だとききますが、ホストでコンパイルするのに
人弱なのでしょうか。
パソコン上でただで使える、ＶＣ＋＋やｂｃｃなどと比べられるなら
どのくらい差がでますかね

411 ：デフォルトの名無しさん：2007/09/15(土) 02:20:24

オレも汎用機触ったことあるけど、安定性が高いとか言われる要因がよく分からん。
ハード面／ソフト麺でいったらどっちなの？両方？
F通かどっかが汎用機にLinuxのせたとか言うの雑誌で見たけどそういうのはどうなんだろう？
PCサーバに汎用機用のOSが載せられたとしたら？

で、実際に落ちたのを見た経験があるのは汎用機の方。人的ミスでショートさせたとか。
業務を止めるのは、その上で動いてるアプリケーションのバグだったりする方が多いと思うけど、
これらだと汎用機もPCも関係ないよな。

OSごと落ちるのはWin以外見たこと無いな。

412 ：デフォルトの名無しさん：2007/09/15(土) 07:20:15

汎用機とはちょっと違うがAS/400なんかはPCベースなHP-UXに比べると
タフではあるな。

これは使い方が悪い例でもあるがDisk使用率が99%使っても気合で動いていたりする。（w

それとは複数のJOBをガンガン並列に走らせても性能の劣化はPCサーバとは
比にならんと言うか、CPUスペックの数字だけ立派なPCと違い、
I/O周りがしっかりしているので、月末とか期日とか重めのバッチが
走っても他のオンライン系の処理も影響なく走るしな。

あとノーツとか動かすとやっぱPC鯖の方が落ちてる回数多い。
あれもトランザクション結構走る業務(?)だと思うが。

まあ、現代はオープン系が人気なので安ＰＣ並べる方がパフォーマンス云々
いいたい気持ちは解るが、やっぱ使い手による面が多いぞ。
COBOLerの99%くらいはアフォなので文句言いたい気持ちは解るけど。

客からすると中途半端なしったかオープン系の方が性質悪いケースが多いし。

413 ：デフォルトの名無しさん：2007/09/15(土) 07:28:49

そういや汎用機といえばPL/Ⅰって完全に消えたの？

414 ：デフォルトの名無しさん：2007/09/15(土) 07:31:45

まだメーカーの研修ってやってた希ガス

415 ：デフォルトの名無しさん：2007/09/15(土) 22:16:35

>>412
すさまじく同意

416 ：デフォルトの名無しさん：2007/09/15(土) 23:16:33

日本じゃまだ商売できてるからっていつまでも汎用機だのCOBOLだのの
幻想にしがみついてると社会保険庁みたいになるぞ

417 ：デフォルトの名無しさん：2007/09/16(日) 01:38:03

>>412
対応は真摯だけれども、詐欺同然にお金だけはキッチリ取る汎用系もどうなのかなぁとｗ
お客からすればどっちがマシなんだろうか

418 ：デフォルトの名無しさん：2007/09/16(日) 01:56:24

>>417
ヤフオクや楽天みたいな
システムダウンしてもお客が舌打ちすりゃ
済むようなシステムならともかく、社の威信のかかった
大事なサービスを提供するシステムなら、
信頼性と迅速なサポートの付いた汎用機だろうね。

419 ：デフォルトの名無しさん：2007/09/16(日) 02:05:41

信頼性って指標値が今ひとつ納得できないんだよなあ
可用性ってことなら、単に待機系のマシン増やせばいいだけなんじゃないの？って思っちゃう

420 ：デフォルトの名無しさん：2007/09/16(日) 08:23:26

>>419
信頼性ってのが胡散臭いなら、以下の記事を読むといい。
ttp://www.nikkeibp.co.jp/style/biz/management/yajima/050606_manzokudo/

AS/400(iSeries)は知っているエンジニアからすると突き抜けて評判がいいのは事実だ。

待機系のマシンを増やせば？って意見もわかるが、PC鯖にOracleやらあれこれアプリケーション
突っ込んでRACやらWEB鯖の分散やらやっていくと管理や構成がウザくなっていくので、
ある程度以上の金が出せて自社の抱えるエンジニアに難のある企業（ココ重要ｗ）
はAS/400の様なマシン買う方が安いのは事実ではある。

こういうのをやらずに「安ＰＣ鯖、オープン系ソフト、技術者は偽装派遣(w)」なんて
組み合わせは「安物買いの銭失い」の典型的パターンだしな。

まあ、「無能なのに金をボるCOBOLer」ってのも事実だけど、機械の方は
あんまり罪はないぞ。そういうのは主に営業が悪いんだし。

421 ：デフォルトの名無しさん：2007/09/16(日) 14:00:03

このスレにオープン系と汎用系の両方をやっている人間何人いるの？

422 ：デフォルトの名無しさん：2007/09/16(日) 18:16:03

>>421
ﾉｼ
と言っても画面周りだけjavaかDominoで、基幹はCOBOL。
基幹に係る仕組みは一台の汎用機の論理領域を切った、zOS(S/390)×1とLinux×5の上で動いてる。

423 ：デフォルトの名無しさん：2007/09/16(日) 18:56:45

AS/400にRPGで開発しろってか
自殺するようなもんだな

424 ：デフォルトの名無しさん：2007/09/16(日) 20:43:43

>>421
一応経験はある。でも、安定性に関してはどちらとも実感がない。
機械やOSよりむしろ、扱う人間が不安定。開発はオープン系のが楽だった。
※あくまでも個人の乾燥です。効果には個人差があります。

425 ：デフォルトの名無しさん：2007/09/16(日) 20:58:34

オープン系はOSも弱いが、特にハードがヤワい。
うちの鯖の外付けDLTドライブなんて、この一年に４回故障している。
そのたびに保守業者を呼んで見積もり取って、
システム臨時停止の稟議を上に上げてハード交換。
数日バックアップが取れないので、気が気じゃない。
一方、汎用機のCMTデッキは１０年以上故障知らず。
モノが違う。

426 ：デフォルトの名無しさん：2007/09/16(日) 21:03:03

>>425
それは、その製品がダメなだけじゃないか？
一方CMTの中身はちゃんと使えるんだろうな？

427 ：デフォルトの名無しさん：2007/09/16(日) 21:45:53

>>423
IBM的にはAS/400は「Java(WebSphere)+SQL(DB2)」が推奨なワケだが。
昔のRPG,COBOLも問題なく動くけど、今からRPGやCOBOLで
新規システム作るアフォはいないだろ。

と漏れは常々思っているが無能軍団なCOBOLerは(ry

428 ：デフォルトの名無しさん：2007/09/16(日) 21:49:37

>>427
コボラー馬鹿にすんなよ
知らないJavaより知ってるCOBOLで
作った方が現実的じゃないか
システム納期は限られてるんだ

429 ：デフォルトの名無しさん：2007/09/16(日) 21:51:32

>>428
JavaっていうかCOBOL以外何にも知らないじゃんｗ
そりゃ馬鹿にされてもしょーがないｗ

430 ：デフォルトの名無しさん：2007/09/16(日) 21:57:52

CMTの頑丈さは半端じゃないよ。
ワークテープとしてリードライトをほぼ毎日数回繰り返す作業を、同じメディアで５年くらい使い続けたことがある。
次のリプレイスでディスクがかなりやすくなってたから、ディスク上のSAMファイルで代用するようになったから
そのMTは使わなくなったけど、SWAPするとか不安な動きすることもなかったから、まだまだ使えたんじゃないかな。
それに比べると、DATとかLTOなんて１年使い続ける勇気はないね。

あと、ディスクの丈夫さも桁違いだね。質量も桁違いに違うのが欠点だけど。

431 ：デフォルトの名無しさん：2007/09/16(日) 22:12:28

>>428
納期を気にするならそれこそ人の集めやすいJavaやSQL使うだろ。

ナニ矛盾した事言っているんだが。

432 ：デフォルトの名無しさん：2007/09/16(日) 22:28:35

RPGつかわないんじゃAS/400使う意味ねーんじゃねーの

433 ：デフォルトの名無しさん：2007/09/17(月) 00:15:01

とは言っても、例えば現行動いているシステムがCOBOLで組んであったら
COBOLで組むしかないじゃん。
それとも、このスレに集まっているプログラマーは20年以上動いている
COBOLで出来たシステムをJavaでバグなしでリプレース出来る
腕利きの方ばかりなんでしょうかね？

434 ：デフォルトの名無しさん：2007/09/17(月) 00:27:30

ローカル変数と小文字キーワードと
ポインタとオブジェクト指向を持つ言語は
全て俺らの敵だ。
俺らの居場所を守るためには、コボルで品質の
良いシステムを作り続け、顧客に変な気を
起こさせないこと。これが大事。
顧客説得のため、Javaの弱点・オブジェクト指向の
弱点をそれらしく言えるだけの知識をつける必要はあるが、
使えるようになる必要はない。そんな時間があったら
コボルのスキルを磨くべきだ。

435 ：デフォルトの名無しさん：2007/09/17(月) 00:29:05

マイグレーションの意味ねーじゃん
なにいってんの？

436 ：デフォルトの名無しさん：2007/09/17(月) 00:44:03

コボルのスキルだけでいつまで食ってけると思ってるのかしら

437 ：デフォルトの名無しさん：2007/09/17(月) 01:41:55

>>431
Java使いのくせに人海戦術をご所望とwww

438 ：デフォルトの名無しさん：2007/09/17(月) 04:10:31

UNIX-COBOLをシェルで動かすのって難しい？
汎用機を廃止して、COBOL→UNIX-COBOL、JCL→シェル
になるんだけど、UNIX覚えるの大変かなぁ・・・

汎用系コボラーの俺やばい？

439 ：デフォルトの名無しさん：2007/09/17(月) 06:39:24

＞COBOLで出来たシステムをJavaでバグなしでリプレース出来る
＞腕利きの方ばかりなんでしょうかね？

正直、そんな程度なら作業的に難しくもなんとも無い。

難しいのは、紙ベースのドキュメントかつメンテされてなく
バグが無いと思い込んでいる糞COBOLerのシステムだろう。
そんなのは、どんなOSやら言語で組まれていても困難だよ。

COBOLやら汎用機が悪いのではなくて、主に使う人間の問題が
大きいのが現状だろう。

440 ：デフォルトの名無しさん：2007/09/17(月) 09:00:31

>>438
なんでもCOBOLとJCLに見立てちゃうからな
COBOLより汎用的なものつかうときは、いったんCOBOL知識捨て去るべきなのに

441 ：デフォルトの名無しさん：2007/09/17(月) 13:12:49

>>439
>正直、そんな程度なら作業的に難しくもなんとも無い。

おいおい、ホントかよ。あんた神様だよww
Javaでどうやって構造体組むんだよ。
Cobolで一行で済む処理がJavaだと延々アホみたいな
型変換が発生するのに。

>>438
シェル=JCL的なことはできる。

442 ：デフォルトの名無しさん：2007/09/17(月) 13:26:37

>>438
UNIXのシェルはユーザインターフェイスとJCLを併せ持った物と言って良いかと思う。
汎用機で使われるJCLと文法が違うだけかと。
おれもUNIXでCOBOLつかってたけど、JCLのDDのかわりに、環境変数使ってたよ。
ちゃんと対応付ける仕組みはあるはずだから安心しな。

>>439
>難しいのは～　のくだり。
そういうのがあるから>>433の後半みたいなセリフが出てくるんだと思うぞ。

443 ：デフォルトの名無しさん：2007/09/17(月) 16:50:56

>Cobolで一行で済む処理がJavaだと延々アホみたいな
>型変換が発生するのに。

これはアホすぎる。一般的にCOBOLの8行=Javaの1行と言われている。

444 ：デフォルトの名無しさん：2007/09/17(月) 17:26:14

クラスも知らなきゃORマッピングも出来ないのだろ

445 ：デフォルトの名無しさん：2007/09/17(月) 17:34:21

>Javaでどうやって構造体組むんだよ。
>Cobolで一行で済む処理がJavaだと延々アホみたいな
>型変換が発生するのに。

とりあえず、COBOLerの程度が知れる発言だな。
Javaが解らないなら解らないと言えよ。

とりあえず世間一般のJavaプログラマは全員神って事になる。ｗ

446 ：デフォルトの名無しさん：2007/09/17(月) 17:39:52

>シェル=JCL的なことはできる。

こんなの付けなきゃ、釣りだって言い張れたのにな

447 ：デフォルトの名無しさん：2007/09/17(月) 17:58:45

>>444
クラスって要はサブルーチンだろ
サブルーチン呼び出しなら、COBOLの
PERFORM～UNTILに敵う構文は
この世に存在しねえ

448 ：デフォルトの名無しさん：2007/09/17(月) 18:02:42

>>447
釣りと見せかけて、マジレスでも大差ないこというからな
コボラってのは

449 ：デフォルトの名無しさん：2007/09/17(月) 18:04:50

>>447
さぶるー珍よびだしはCALLですよ。

450 ：デフォルトの名無しさん：2007/09/17(月) 18:17:13

ローカル変数がわからないコボラーに
クラスを理解しろというのも無理があるのかな

451 ：デフォルトの名無しさん：2007/09/17(月) 18:41:59

＞クラスって要はサブルーチンだろ

いいからもう黙っとけ。
頼むから。ｗ

452 ：デフォルトの名無しさん：2007/09/17(月) 18:49:31

このスレはこボラーが主役だ。
コボラーのコボラーっぷりを曝せ。

453 ：デフォルトの名無しさん：2007/09/17(月) 19:52:40

そうだよ。
何でコボラーが叩かれるスレになってるんだよ。
Javaだって使えないことはない。
main以外にクラスを作らず、ロジックをズラズラ
書き並べればとりあえず動くものはできる。
ただしJavaは構造化機能が弱いので、ソースが汚くなる。
慣れたコボルでやったほうがよいのは言うまでもない。

454 ：デフォルトの名無しさん：2007/09/17(月) 20:08:47

構造化機能など聞いたことが無い言葉だが、JavaにCOBOLより弱い構文など無い

455 ：デフォルトの名無しさん：2007/09/17(月) 21:36:07

構造化は関数でやるもので
サブルーチンでやるものじゃないんだよ
ダイクストラの教えを未だに聞かなきゃいけないのはコボラーぐらいなんだ
目を覚ましてくれ

456 ：デフォルトの名無しさん：2007/09/17(月) 22:10:58

COBOLで関数定義どうやるの？

457 ：デフォルトの名無しさん：2007/09/17(月) 22:16:18

>>453
アンフェアな比較をするのはやめようよ。
JAVA にクラスを作るなって言うのは
COBOL で PERFORM 使うなって言われる並にフェアじゃない。

なんだかんだ言われたって JAVA はとにかく遅いって。
結局 VM の上で動く以上、同じ事をやらせたら COBOL に勝てない。

>>456
SECTION を区切ってそのセクションを PERFORM する
COBOL をやってない人間には理解できないかもしれないが、
function hoge() みたいな構文はちゃんとあるから。

458 ：デフォルトの名無しさん：2007/09/17(月) 22:19:41

>>457
釣りと見せかけて、マジレスさせても大差ないってんだから始末に終えない

459 ：デフォルトの名無しさん：2007/09/17(月) 22:25:13

>>457
その PERFORMを式として使えますか？

460 ：デフォルトの名無しさん：2007/09/17(月) 22:50:14

>>457
JavaがネイティブコンパイルされるCOBOLに比べて遅いとか
言うのが論点ではなくて、COBOLerがあまりに無知なのに
Javaについて語るから叩かれるんだろ。

なんだかんだ言われたってCOBOLerはとにかく「仕事」が遅いって
同じ事をやらせたら生産性＆保守性ではJava に勝てない。

461 ：デフォルトの名無しさん：2007/09/17(月) 22:55:59

　　　　　INITIALIZE　フラグ.
　　　　　PERFORM　初恋.
　　　　　IF　失恋N_FLG　=　'1'
　　　　　　　PRFORM　失恋
　　　　　ELSE
　　　　　　　IF　純情_FLG　=　' '
　　　　　　　　　PERFORM　エッチ
　　　　　　　ELSE
　　　　　　　　　PERFROM　オナニー
　　　　　　　END-IF
　　　　　END-IF.
===================================================
　　　++++++++++++++++++++++++++++++++++
　　　　初恋　　　　　　　 SECTION.
　　　　　 MOVE　'愛してます'　 TO 　彼女
　
　　　　　 IF 　男前度　<　10
　　　　　　　 MOVE　'1'　　　　TO　失恋_FLG
　　　　　 ELSE
　　　　　　　 IF　彼女　NOT =　恥女
　　　　　　　　　 MOVE　'1'　　TO　純情_FLG
　　　　　　　 END-IF
　　　　　 END-IF.
　　　　EXIT.
　　　++++++++++++++++++++++++++++++++++
　　　　失恋　　　　　　　 SECTION.
　　　　　　　　∧||∧
　　　　　　　（　 ⌒ ヽ
　　　　　　　　∪　　ﾉ
　　　　　　　　　∪∪
　　　　EXIT.

462 ：デフォルトの名無しさん：2007/09/17(月) 23:00:03

>461
イマイチ

463 ：デフォルトの名無しさん：2007/09/17(月) 23:03:05

>>462
きっと>>470さんが面白いプログラム書いてくれるよ！

464 ：デフォルトの名無しさん：2007/09/17(月) 23:06:17

>>457がJAVA派なのかCOBOL派なのか見えない。というか両方を擁護して見える。
1段落目はJAVA派
2段落目はCOBOL派

で>>453がJAVAを否定している様に受け取って>>457を書いたんだと思うけど、
>>453は
　COBOLerがJAVAを使った場合、mainに詰め込んでしまう。
　だからCOBOLerにとっては慣れたCOBOLの方が良い。
といってるんだと俺は受け取った。
だとしたら>>457の1段落目は勘違い。揉める必要もない。

そうすると2段落目だけが生きるが、1段落目のJAVA派視点を生かすと、
JAVAを知り、その欠点を認めたものと取れるので、「COBOLerのJAVA論」と対決する姿勢の
>>460の1段落目は必要ない。

よって>>460の2段落目
これが正解！

465 ：デフォルトの名無しさん：2007/09/17(月) 23:12:21

関数というのはローカル変数を持ち値を戻すものを言うのだ
それがないとまともな構造化は出来んのだ
コボラーはソフトウェア工学の進化から何十年取り残されてきたのか
自分らが使ってる言語がなんなのかよく考えるべき

466 ：デフォルトの名無しさん：2007/09/17(月) 23:18:46

　　　　　　　　　　　　　　　　　　　　　　　 ,､ｧ
　　　　　　　　　　　　　　　　　　　 ,､ '";ｨ'
_＿_＿＿___　　　　　　　　　　　　　／::::::/l:l
─- ､::::;;;;;;;;;｀ﾞﾞ''‐ ､　　 __,,,,......,,,,_／:::::::::/: !|
　　. : : : : : : ｀ﾞ'ヽ､:::ﾞヾ´::::::::::::::::::::::｀ﾞﾞﾞ'''‐'､. l|
､､ . : : : : : : : : r'":::::::::::::::::::::::::::ﾉ::::ぃ::ヽ::::::ヽ!
.ヽ:ﾞヽ; : : : : : :ノ:::::::::::::::::::::::::／" :: 　　 '＼-:'､
.　＼::ﾞ､: : : :./:::::::::::::::::::::::::::::（・）::　　,...,（・）:::':､　　　　　>>464 で　？
　r､r.r ヽ､ /:::::::::::::::::::::::::　　　_　　｀ﾞ''‐''"　 __,,',,,,___
r |_,|_,|_,|｀ヽ､:::::::::;;;､､--‐‐'''''',,iﾆ-　　　 _|　　､-l､,},,　￣""'''￢-
|_,|_,|_,|_,|､-‐l'''"´:::::::'　　,､-'" ,.X,_,,､-v'"''ﾞ''yr-ヽ / ﾞﾞ'ヽ､,
|_,|_,|_人そ(^il:::::::::::;､-''"　 ,.-'　　ﾞ､""ヾ'r-;;:l　　冫、　　ヽ､
|　)　　ヽﾉ　|l;､-'ﾞ:　　 ,／　　　　ゞ=‐'"~ﾞﾞ')　./.　＼
|　　`".｀´ 　ﾉヽ:::::..,.r'ﾞ　　　　　　　　 ,,. ,r／ ./　　　ヽ
　　　入＿ノ　ﾝ;"::::::.　　　　　　　"´ 'ﾞ ´　/　　　　　ﾞ､
　＼＿／　　／/:::::::::　　　　　　　　　　　　{.　　　　　　 V
　　／　／ ./:::::::::::::　　　　　　　　　　　　',
　 /　　／　 /:::::::::::::::::.　　　　　　　　　　　　',.

467 ：デフォルトの名無しさん：2007/09/17(月) 23:25:43

AAのコピペをするほどCOBOLerがテンパっているのが
なんというか哀れで・・・。

なんか職場でイジめられているのだろうか・・・。

468 ：デフォルトの名無しさん：2007/09/18(火) 00:16:45

というかコボルってネイティブだっけ？
数値を十進数で計算する言語が
ネイティブっつってもなんのこっちゃわからんけど

469 ：デフォルトの名無しさん：2007/09/18(火) 00:23:22

>>468
ネイティブの意味を理解して発言してるとは
とても思えないんだけど

470 ：デフォルトの名無しさん：2007/09/18(火) 00:31:02

BCD関連の命令はx86系CPUにもあるようだ。使い方はシラン。

471 ：デフォルトの名無しさん：2007/09/18(火) 00:31:11

あなたのCOBOLは
機械語を生成していますか中間コードを生成していますか
という話だが
もし機械語だったとしても十進数で計算するものをネイティブとは呼びたくないな

472 ：デフォルトの名無しさん：2007/09/18(火) 00:34:59

>>471
またそういう釣りとも素ともつかない発言をするんだから

473 ：デフォルトの名無しさん：2007/09/18(火) 01:07:05

いずれにしても今のシステムは絶対にとまってはいけないという
風潮はなんとかしないと日本のIT産業は衰退していくばっかだ。

そもそもCOBOLやJAVAでの開発に限らず
もともと基幹系でガチガチに試験工数をつんでるプロジェクトと
中小で試験工数を軽くしか見積もってないプロジェクトを
金額だけで比較するのはあまりにもナンセンスだろ

オープンだと安くなると張り切って開発を始めて
ふたを開けてみると、これまでの資産を回収しきれずプロジェクト崩壊、
もしくは障害だしまくって実際は赤字ってのはよくある話で、
オープン最高って軽くいってるやつが
自分で自分達の首を絞めていることに早く気づいてほしい。

こう書いたけどおれも実際にはオープン推進派で
金融機関系でCOBOLもJAVAも両方みてる。
ただ、安易にCOBOLいらねぇっていってるやつは
下っ端JAVAプログラマが表面的なところだけを見て
ものを言っているようにしか見えない。
システムがちょっとでも止まれば大騒ぎ、障害出ればマスゴミに
袋叩きてな世の中で、システム作らせる側も作る側も
リスクかけて大金かけてほぼ１からオープンで作り直すなんて
よっぽど先鋭的な企業か大金持ってないと簡単に提案できるわけないだろ。
実際にはCOBOLerも使い古したきたねえソースは１から作り直したいと思ってるんだよ。
金と期間さえもらえればね。

どうでもいいけどこのスレッドは釣りの判断が難しいな。

474 ：デフォルトの名無しさん：2007/09/18(火) 01:10:43

んなこと言ったってDB自体が止められない物なんだから仕方ねえべさ。

475 ：デフォルトの名無しさん：2007/09/18(火) 05:03:16

COBOLerの主張って、Cで書いたら全て解決するように見えるんだが
コボルで書ける程度のことならメモリーリーク起せず書けそうだし

476 ：デフォルトの名無しさん：2007/09/18(火) 06:56:37

マジで釣りの判断が難しいスレッドだな。

＞実際にはCOBOLerも使い古したきたねえソースは１から作り直したいと思ってるんだよ。
＞金と期間さえもらえればね。

実際サ、その機会が稀にあってもオープン系の人間のアイデアがなぜか全否定されて
COBOLerはCOBOLでつくりなおす。

そして「ちょっとでも止まれば」って実際システム初回稼動時なんかCOBOLで
組んであっても「激しく止まる」か「激しく数値が違う」事はお約束じゃん。

オープンだろうが汎用COBOLだろうがリスクはどっちにでもあるが、
オープン系の安く上がる妄想もアレだが、COBOLerの安定神話な妄想も
ウザいんだが。

477 ：デフォルトの名無しさん：2007/09/18(火) 10:51:54

>>476
>オープン系の人間のアイデアがなぜか全否定されて
だって、無責任集団のオープン系なんて信用できないよww

478 ：デフォルトの名無しさん：2007/09/18(火) 16:36:37

貿易保険のシステムはコボルからJavaに作り変えられました

PMは2回交代し、当初計画2年のところ、4年近くかかりましたが

479 ：デフォルトの名無しさん：2007/09/18(火) 18:32:30

＞だって、無責任集団のオープン系なんて信用できないよww

無能集団が無責任集団を笑う図か。ｗｗｗ

480 ：デフォルトの名無しさん：2007/09/18(火) 18:37:05

某金融系のCOBOL開発は月120時間残業で10ヶ月くらいの年中デスマだったな。

でJava+SQLだと某COBOL開発の1/5の人員でほぼ定時帰りだったな。

正直、残業代が稼げて仕事が出来ると勘違いしているCOBOLerが羨ましくもあった。ｗ

481 ：デフォルトの名無しさん：2007/09/18(火) 20:22:56

>>480
そりゃあ反則だよ。
上の方にも出てるけど、
RDBってCOBOLの得意分野のマッチングや
ソート・抽出を元から持っててSQL一発で操れるじゃん。
ＪａｖａでもRDBを使わずSAMファイルにデータを持って
マッチング処理を組むなら、それなりに苦労すると思う。
三本マッチング処理なんてやったら大変だよ。
一度体験してみなよ。COBOLerを馬鹿にできなくなる。

482 ：デフォルトの名無しさん：2007/09/18(火) 20:34:26

何が反則だ
コボルが馬鹿なだけでコボラーは無能じゃないという主張か？
言っててむなしくならないか？

483 ：デフォルトの名無しさん：2007/09/18(火) 21:16:02

>>481
反則って言われてもサ、「クラスって要はサブルーチンだろ」
とか言う無能COBOLerに無理やりJavaやらせたら、そりゃ>>478みたいにデスマになるわさ。

現代だとRDB操作するのにSQLは当たり前なのにCOBOLerとかは
SELECT * FROM HOGEしかしらずに、妙なストアドでカーソルいじくって
無理やりステップ数稼ぐみたいな実行性能＆保守性＆テスト効率最悪な設計しておきながら
「やっぱCOBOLは安定して速い」とかをマジで言っているからな。w
そりゃ、当初計画２年が４年にのびるだろう。

COBOLerの全員がバカとは思わんが、残念ながらほとんどのCOBOLerは
こんな事を本気で言っているのが現状だ。

484 ：デフォルトの名無しさん：2007/09/18(火) 22:43:15

本当に無能なのはCOBOLで安定して動いてるものを
機材まで何まで全部Java用に総入れ替えにしておきながら
初日で止まるシステムを作る奴ら。

485 ：デフォルトの名無しさん：2007/09/18(火) 23:03:08

なんかすっかりつまらなくなったな。
汎用機vsオープン系なんて話題はどこかよそのスレでやってくれ。
ここはCOBOLについてのみ語るスレだ。

486 ：デフォルトの名無しさん：2007/09/18(火) 23:10:12

>>484
そうやって脳内にしか存在しない、物語を作り上げるのに必死なんだろうなぁ。

487 ：デフォルトの名無しさん：2007/09/18(火) 23:16:10

本当にフェアじゃない話だね
COBOLが保守性、テスト効率でJavaに劣るのは仕方の無い事だろうに

COBOLでテストツール使って全自動でテスト、
んで気に入らない部分は即リファクタ出来たらどれだけ幸せか

ところで>>483は階層型ＤＢというものを知っているかな？ｗ

488 ：デフォルトの名無しさん：2007/09/18(火) 23:32:24

Javaが保守性とかテスト効率でCOBOLより優れているのは
後発の言語だからってのもあると思うが、
そのコミュニティ(JCPか)の思想の問題だと思う。

まー、JCPも初期はかなりアレでIBMやらOracleが力入れ始めて
Javaが使えるようになってきた、って希ガス。

COBOLerが保守やらテストとかを軽視したツケが
Javaを調子つかせているんだろうけど、それを
フェアじゃない。って言うのは負け犬の遠吠えだろう。

Javaなんか1.0や1.1の頃は他の言語使いからは笑い者だったけど
今はプログラム言語シェアNo.1になっちまったし。

489 ：デフォルトの名無しさん：2007/09/19(水) 12:46:41

>>483
ところで、なんでステップ数が減ると実行性能＆保守性＆テスト効率
良くなるんだ。あり得んだろ。
工期が延びるのはPMがバカだからだろう。COBOL関係ないじゃん。

490 ：デフォルトの名無しさん：2007/09/19(水) 12:58:49

>>489
>ところで、なんでステップ数が減ると実行性能＆保守性＆テスト効率
>良くなるんだ。あり得んだろ。

あり得んのはお前の読解力の方だろ

>工期が延びるのはPMがバカだからだろう。COBOL関係ないじゃん。

関係あるよ

491 ：デフォルトの名無しさん：2007/09/19(水) 14:16:36

具体例も出さずに反論とな？

492 ：デフォルトの名無しさん：2007/09/19(水) 15:00:26

>>490
同じ処理なら１行でまとめて書こうが
数行にバラそうがダイナミック・ステップは大差ないはず。
A = B + C + D + ... を数行にしても数ナノ秒も変わらんだろ。

第一、Javaは中間コードやVMで動作するから実行性能は
他言語より遅いじゃないか。

テスト量のほとんどは、入出力のバリエーションやIF文等の
分岐数で決まるのにJavaだとなんで効率よくテスト
できるんだよ？

ある変数を使っているソースファイルを抽出せよ。って時に
COBOLだと変数名で内容検索すれば十分だが、
Javaだとそんな単純じゃないだろ。保守性高いか？

493 ：デフォルトの名無しさん：2007/09/19(水) 16:15:33

>>491
反論じゃねーよ自惚れんな

まず>>483を1000回嫁
話はそれからだ

罰として、バカレス再掲しとくぞ

>ところで、なんでステップ数が減ると実行性能＆保守性＆テスト効率
>良くなるんだ。あり得んだろ。

494 ：デフォルトの名無しさん：2007/09/19(水) 16:44:36

>>492
COBOLでいうところの「ある変数」ってのは、OOPLでいうところのフィールド(メンバ変数)ってことだろ？
なら、その変数にアクセスできるのは同じクラスのメソッド(メンバ関数)だけだよ
つまり検索する間でもないってこと

ポリモルフィズムで入出力のバリエーションや条件分岐を(コードから)ある程度消すことができる

それにOCPに則ってコーディングすれば、あるクラスを修正したときに他のクラスには一切影響が無い
つまりデグレが絶対に発生しない

おそらく言ってることが全くわからないと思うけど、なにしろ保守性に関してはJavaの方がCOBOLより
圧倒的に上ってこと

495 ：デフォルトの名無しさん：2007/09/19(水) 20:57:54

>テスト量のほとんどは、入出力のバリエーションやIF文等の
>分岐数で決まるのにJavaだとなんで効率よくテスト
>できるんだよ？

喪前は一度Javaで開発してみろ。
よくあるデスマの原因の「突然の仕様変更攻撃」を受けたときに
激しく差がでるから。

496 ：デフォルトの名無しさん：2007/09/19(水) 21:05:03

なんでJava vs COBOL になってるんだ？

497 ：デフォルトの名無しさん：2007/09/19(水) 21:06:04

>テスト量のほとんどは、入出力のバリエーションやIF文等の
>分岐数で決まるのにJavaだとなんで効率よくテスト
>できるんだよ？

実際効率良いよ
COBOLとの比較じゃ話にならないくらい

498 ：デフォルトの名無しさん：2007/09/19(水) 21:25:02

Java房うぜえ

499 ：デフォルトの名無しさん：2007/09/19(水) 21:30:15

>>498
勘違いするなよ
「Java(及びJava厨)が優れてる」のではなく、とりわけ「COBOL(及びコボラ)がゴミ」なだけ

500 ：デフォルトの名無しさん：2007/09/19(水) 22:47:32

COBOLの言語自体はそれほど悪いとはおもわんけどサ。人間的にダメなのがな・・・。

なんというかJavaでも程度の低いヤツは多いけど、COBOLerは他の言語にくらべて
ぬきんでてアフォが多いのが問題なんだろ。>>492に代表されるように。

あと今はJavaが一番人気(?)だから比較大量になりやすいだけだろ。

501 ：デフォルトの名無しさん：2007/09/19(水) 22:48:24

ｽﾏｿ「比較大量」じゃなくて「比較対象」な

502 ：デフォルトの名無しさん：2007/09/19(水) 22:57:40

例えばCOBOLではDBそのものは作れない
COBOLしか知らない人間は、DBの内部動作がどうなっているか
ほんとのところはわからないんだな

コボラーがアホなのはCOBOLがアホだから
COBOLで思考したんじゃプログラミングの本当のところは
何も分からない

503 ：デフォルトの名無しさん：2007/09/19(水) 23:10:39

例えばJavaではOSそのものは作れない
Javaしか知らない人間は、OSの内部動作がどうなっているか
ほんとのところはわからないんだな

Java廚がアホなのはJavaがアホだから
Javaで思考したんじゃプログラミングの本当のところは
何も分からない

504 ：デフォルトの名無しさん：2007/09/19(水) 23:13:13

釣りかマジレスかしらんけど、本気でCOBOLerってヴァカなんだな、って思うよ。

505 ：デフォルトの名無しさん：2007/09/19(水) 23:17:00

>>503
昔SUNがJDSというOSを作ってたワケだが。

506 ：デフォルトの名無しさん：2007/09/19(水) 23:17:23

>>503
残念ながら作れます

507 ：デフォルトの名無しさん：2007/09/19(水) 23:21:23

JavaStationとかいうのもあったな。

508 ：デフォルトの名無しさん：2007/09/20(木) 00:10:43

何のたとえなのかすらわからんが、なぜにCOBOLでDBを作らねばならない？
DBの内部構造を知る必要なんか全く無いだろ
チューニングなんかで、外部パラメータなんかを知っておく必要があるというのなら
わかるというか当然だが

ふと思い出したが、JavaでOS作るって笑い話であったな
SUNの環境（バイトコードで動くCPUだっけ？）除いて、誰がそのOSが動くランタイム作るんだという話だろ？

509 ：デフォルトの名無しさん：2007/09/20(木) 00:17:51

>>492
これの実行性能に指摘が無いので
Java<COBOLでFA?

510 ：デフォルトの名無しさん：2007/09/20(木) 00:35:47

>DBの内部構造を知る必要なんか全く無いだろ
大有りだよ
データベースパフォーマンスアップの教科書基本原理編
1000回嫁

511 ：デフォルトの名無しさん：2007/09/20(木) 01:07:46

内部構造ってその程度だったのか。
同期処理とかデッドロック検出とか
それらの実現方法かとてっきりww

512 ：デフォルトの名無しさん：2007/09/20(木) 01:33:56

>>511
バカにしてるおまえが哀れすぎて、もう何もいえねぇよ

513 ：デフォルトの名無しさん：2007/09/20(木) 01:36:35

多分コボラーじゃ二分木をどう書くかすらわかんねえんじゃねえかな

514 ：デフォルトの名無しさん：2007/09/20(木) 01:41:53

多くのJava使いもWeb-DBとフレームワークの基本的な金太郎飴コーディング
しかできないような気がするんだけどなあ・・・。
もともとCOBOLもFramework Javaも、業務システム構築向けに均一な品質の
金太郎飴コードを生み出すのが優先目的な訳で、結局提供されたフレームワークを
「使う側」（「作る側」じゃなくて）のJava使いって、COBOL使いと立場は同じな
気がするよ。単なる兵隊。

515 ：デフォルトの名無しさん：2007/09/20(木) 01:45:53

目糞（Java）鼻糞（COBOL）を笑う

516 ：デフォルトの名無しさん：2007/09/20(木) 01:46:34

ああ、ルンペン同士の飯の取り合いみたいなものか

517 ：デフォルトの名無しさん：2007/09/20(木) 01:47:38

Java使いにはアホも多いけどJava自体は糞じゃないな
COBOLはどっからどう見ても糞だが

518 ：デフォルトの名無しさん：2007/09/20(木) 01:55:34

>>514
んなこといってるやつって、ホントにJavaでフレームワーク使った開発やったことあるんかなあ
多分Struts位しか使ったこと無いんだとおもうけど、それすら意味わかって使ってるかどうか
怪しいもんだ

519 ：デフォルトの名無しさん：2007/09/20(木) 06:52:34

＞もともとCOBOLもFramework Javaも、業務システム構築向けに均一な品質の

こういう認識持っている限りCOBOLerは常に糞呼ばわりされるんだと思う。

520 ：デフォルトの名無しさん：2007/09/20(木) 10:00:31

>>502
25年以上前だが、COBOLでRDBを作ったよ。
1989年まではSQLではなくてPrologで動作してた。

521 ：デフォルトの名無しさん：2007/09/20(木) 19:15:34

＞25年以上前だが、COBOLでRDBを作ったよ。

どんな商用DB?

522 ：wolf ◆8VH3XAqjlU ：2007/09/20(木) 21:38:39

>>520
25年以上前だが、JavaでRDBを作ったよ。
2014年まではSQLで動作してた。

--- 2037年**月**日、あるJava'erの生涯より ---

523 ：デフォルトの名無しさん：2007/09/20(木) 22:46:09

だからおまえらここはコボラーを叩くスレじゃねえ。
コボラーが集まって話をするスレだ。スレタイ嫁よ。
どうしても発言したいなら、コボラーがJavaを
できるだけCOBOL風に使えるような主砲をアドバイスしろ。

とりあえず上に出てきた、main()に全ての処理をぶち込んで
クラスやスコープの縛りを受けずに済む方法を考えている。
メソッド定義を各プロシージャ定義になぞらえて
メソッドを順に呼び出すやり方だ。
しかしCOBOLのPERFORM～UNTILに相当する
条件付きメソッド呼び出し方法がないっぽい。
やっぱりJavaはここいらが弱い。

524 ：デフォルトの名無しさん：2007/09/20(木) 22:52:12

PERFORM xxx UNTILは条件付きっていうより繰り返し構文って感じだろ。
while や for で置き換えれば良い。

525 ：デフォルトの名無しさん：2007/09/20(木) 22:55:51

while(condition() == false){
method();
}

526 ：デフォルトの名無しさん：2007/09/20(木) 22:56:55

>main()に全ての処理をぶち込んで
>クラスやスコープの縛りを受けずに済む方法を考えている。

自殺したいならそうするといい
生き延びたければJavaが体現しているソフトウェア工学の教えを真面目に学び取れ
どうせCOBOLだけじゃ生き延びられんのだ

527 ：デフォルトの名無しさん：2007/09/20(木) 23:11:18

ソフトウェア工学ｗｗｗ

528 ：デフォルトの名無しさん：2007/09/21(金) 00:56:51

>PERFORM～UNTILに相当する
>条件付きメソッド呼び出し方法がない
breakも無いくせに、何いっちゃってんの？

529 ：デフォルトの名無しさん：2007/09/21(金) 01:05:56

GOTOがあるだろ。

530 ：デフォルトの名無しさん：2007/09/21(金) 01:12:31

>コボラーがJavaをできるだけCOBOL風に使えるような主砲をアドバイス
どんだけ恥知らずなんだよ
他の言語使いがこんなこというの聞いたことないよ

531 ：デフォルトの名無しさん：2007/09/21(金) 01:42:25

フリーフォーマットの言語ではそんなに細かい構文まで
言語が用意してやる必要はないのだよ
単に基本的な要素を組み合わせればいいだけだ

532 ：デフォルトの名無しさん：2007/09/21(金) 07:34:14

＞しかしCOBOLのPERFORM～UNTILに相当する
＞条件付きメソッド呼び出し方法がないっぽい。
＞やっぱりJavaはここいらが弱い。

いや、COBOLerの頭が弱いとしか思えんが・・・。

533 ：デフォルトの名無しさん：2007/09/21(金) 12:28:28

金に糸目を付けないで、処理速度、ユーザビリティー共に優れた
システム作れって案件があったら、オールCOBOLもオールJava
も選択されないで、各々の特例を生かした、混在型のシステムが
できあがる。

お互いの弱いところをつつき合ったって、どっちも納得する訳なかろ？
ま、どっちもどっち、ここでバカみたいに言い合っている奴らの程度が
低いってこった。

534 ：デフォルトの名無しさん：2007/09/21(金) 12:47:40

なんだよ特例って特性だろ
まだわかってないバカがいるみたいだからもう一度いうぞ
COBOLに生かすべき特性なんてないし、JavaがCOBOLに劣る点なんて一つもない
むしろ混在型のシステムなんか、オールCOBOLにすら劣るだろうな

535 ：デフォルトの名無しさん：2007/09/21(金) 15:38:39

やれやれ。Javaを万能だと思いこんで長期間安定して稼働してる堅牢なシステムを
わざわざJavaで書き直して、バグや負荷に耐えられなかったりでまともに動かない
マヌケなものにしてどうすんの。
COBOLの悪口並べ立てて、Javaでなら安く済むかのように吹聴し、Javaで置き換える
ように説得したあげくに、まともに動かないものを客に押しつけて、しかもその修正に
まで金をとるんだから、はっきり言えば詐欺みたいなもんだ。
そこに流用すべき資産があるかぎりCOBOLは最強。動くか動かないかなんていう
低次元な心配は全く必要ない。UI部分にVBを組み合わせれば無敵。

536 ：デフォルトの名無しさん：2007/09/21(金) 15:52:28

全く同じ仕様でいいなら、COBOL→Javaのマイグレーションは簡単なんだよ
気付いてないかもしれないけど、Javaに移行っていった時点で潜在的に非機能要件がいっぱい増えてんの
スケーラビリティやらセキュリティやらなんやら、な
COBOLが最強も何も、COBOLじゃJavaと同じモノ自体が作れないんですよ

それから、Javaが万能なんてだれも思ってないぜ
COBOLが無能過ぎるだけ

537 ：デフォルトの名無しさん：2007/09/21(金) 16:36:23

>>536
へー
（・∀・）ﾆﾔﾆﾔ

538 ：デフォルトの名無しさん：2007/09/21(金) 16:45:21

>>537
古臭い煽りに敢えてレス

そろそろコボラは観念して勉強始めろ
何一つ勉強しない分際で、現役気取ってんじゃねぇ
若しくはとっとと引退しろ

539 ：デフォルトの名無しさん：2007/09/21(金) 18:04:16

そういう文句はバグ数0でプログラミングできるようになってから言え。
期限も守れない、大風呂敷広げた仕様の半分も満たせない、それで一人前のつもりか？
COBOLerならきちんと完成させてからソース水増しする余裕すらあるというのに。

540 ：デフォルトの名無しさん：2007/09/21(金) 18:14:25

バグ数0でコード書けるのが良いことだと、
いまだに信じ込んじゃってるからなあ

541 ：デフォルトの名無しさん：2007/09/21(金) 18:19:28

>>538
ありゃ。カチンときちゃいましたか。カチンと。
そんなにいちいち他人の一言に反応してると、自分の啓発がおろそかになって
数年後には、ゆとり世代に同じこと言われてると思うぞ。

言語がどうのってこだわっているようじゃ、とても勉強しているとは思えない。
一生PGとして生きていくならいいけど、いい年したPGなんてここで馬鹿にされる
コボラとなんら変わりないね。

一番使えないのは、PGMの勉強だけして安心している仕様書待ちのプログラマ。
言語なんてのは、使うときになれば直ぐに覚えられるだろ。
そんなに覚えが悪いのか？

542 ：デフォルトの名無しさん：2007/09/21(金) 18:24:31

>>541
カチンとなんて、素で来ませんよ
最近2ch始めた方でしたか？

よかったら最近勉強されてること教えてください
そのとき読んだ本なども、できれば

543 ：デフォルトの名無しさん：2007/09/21(金) 18:54:46

＞言語がどうのってこだわっているようじゃ、とても勉強しているとは思えない。

全員が別に言語がどうのと拘っているのではなくCOBOLerが一方的に
COBOLという言語にしがみ付いている感があるが。

Javaをやる連中は他の言語も齧っている感があるが、
COBOLerはオンリーワン的なイメージあるよな。

教育係とかもちょっとやった事あるけどCOBOLの上がりの人間が
一番物覚えが悪いよ。
説明しても「私は今までコレでやってきた」と机上コーティング始めるし。
それで他の人間よりも品質が上とか仕事が早いとかなら許せるけど、
そんなワケがないし。

で、テメエの能力の低さを「今までは・・・、」とか「COBOLでやれば・・・」とか愚痴りだす。

あからさまに向いていない案件でもCOBOLを持ち出したりするし。

漏れもCOBOLで向いているところはCOBOLでやればいいと思うし、
COBOLもそんな悪い言語ではないと思うが、COBOLerという人種が癌ではある。

544 ：デフォルトの名無しさん：2007/09/21(金) 21:21:55

全員が別に言語がどうのと拘っているのではなくJava厨が一方的に
Javaという言語にしがみ付いている感があるが。

C++をやる連中は他の言語も齧っている感があるが、
Java厨はオンリーワン的なイメージあるよな。

教育係とかもちょっとやった事あるけどJavaの上がりの人間が
一番物覚えが悪いよ。
説明しても「私は今までコレでやってきた」とEclipse使い始めるし。
それで他の人間よりも品質が上とか仕事が早いとかなら許せるけど、
そんなワケがないし。

で、テメエの能力の低さを「今までは・・・、」とか「Javaでやれば・・・」とか愚痴りだす。

あからさまに向いていない案件でもJavaを持ち出したりするし。

漏れもJavaで向いているところはJavaでやればいいと思うし、
Javaもそんな悪い言語ではないと思うが、Java厨という人種が癌ではある。

545 ：デフォルトの名無しさん：2007/09/21(金) 21:53:56

まじ意味わかんねえよな机上コーディング

546 ：デフォルトの名無しさん：2007/09/21(金) 21:59:47

>>542
> 最近2ch始めた方でしたか？
（・∀・）ﾆﾔﾆﾔ
本で勉強って考え自体がねえ。
システムってのは構築することが目的ではなくて、ユーザが使ってユーザが欲しい
容を用意するのが目的。どれだけ画期的なロジックを組み込もうが、メンテナンス性
がよかろうが、ユーザの求めるものでなければ何も意味はないよ。
何のシステムを開発しているのかは知らないけど、言語の勉強よりもその業務を知って
エンドユーザの声を聞くことが重要なんじゃないかな？
ユーザの求めるものを現状のプラットフォームで構築するのがエンジニアの役割。
どうしても、現在のプラットフォームで構築が不可能であったり、困難である場合は
リプレースの提案となる訳だけど、業務を理解していないPGの言うことなんかに、聞く耳
もってもらえないよ。

>>543
その通り。
COBOLも出来て困ることはないわけだし、職能によっては勉強が必要なわけ。
なのにJavaの方がCOBOLよりすぐれているんだから、置き換えてCOBOLなんて
捨ててしまえ。なんてレスばかりで、程度の低さが鼻につくわけさ。

547 ：デフォルトの名無しさん：2007/09/21(金) 22:06:12

>>545
机上コーディングするのは器財や環境が高価だった頃の名残じゃない？
未だにやっているのは、そろそろ引退の輩なので無視の方向で
Javaしか書けないヤツは十中八九字が汚いから字の練習にやってみるのはいいかもな

548 ：デフォルトの名無しさん：2007/09/21(金) 22:09:24

いったんCOBOLに慣れ親しんだらもう
他の言語を学ぶ気が起きないんだよ。
キーワードが大文字で記号が少なく、見やすい。簡潔。
Javaの醜いソースは見るに堪えない。

549 ：デフォルトの名無しさん：2007/09/21(金) 22:15:40

>>541はいきなりC++やASMでコーディングが出来ちゃう神様。

550 ：デフォルトの名無しさん：2007/09/21(金) 22:22:19

ユーザが求めているものは汎用機とCOBOLで作ったシステムではないのだ
もうすぐこの世からなくなるコンピュータと
もうすぐこの世からなくなる古代語で書かれたシステムが
欲しいと思ってる奴などほんとはいない
それを口八丁で騙してなんとか延命を図っているのがコボラーなわけだ

551 ：デフォルトの名無しさん：2007/09/21(金) 22:37:28

ユーザがCOBOLかJavaかを気にしていると思っている馬鹿発見

552 ：デフォルトの名無しさん：2007/09/21(金) 23:12:23

>>551
言語を気にする香具師も居る。主に情シに。
十中八九デスマ確定案件になるがな。

Java でフレームワーク使ったら早くて安いんだろ？　ってヴァカと
COBOL こそが安定していて枯れているから安全だ　ってアフォ、な。

それでもって
前者は仕様変更を幾ら行っても全然 OK！　って勘違いをしていて、
後者はまず現行システムのドキュメント化を丸投げしてくるドキュソ
というパターンが多いな。

頼むからどっちも死滅してくれ。

553 ：デフォルトの名無しさん：2007/09/21(金) 23:57:54

>>552
情sysは件のユーザからは外れるだろ
つーか、情sysは言語気にしろよww

554 ：デフォルトの名無しさん：2007/09/22(土) 00:02:00

なんか、7年くらい前のJ2EE vs .NETを思い出すなあ。。。

555 ：デフォルトの名無しさん：2007/09/22(土) 02:44:54

>>554
そんなのあったか？

556 ：デフォルトの名無しさん：2007/09/22(土) 07:10:09

>>536
＞＞全く同じ仕様でいいなら、COBOL→Javaのマイグレーションは簡単なんだよ

この作業がどれだけしんどいものかは、貿易保険のシステム（COBOL:500万ステップ）
のマイグレーションで証明されましたが・・・

当初2年弱の予定→4年
IBMのPMが2回交代
予算は2.5倍に膨れ上がる

ちなみに、COBOL:500万ステップ　→　Java：400万ステップ　になりました
COBOL：8行＝Java：1行じゃないんかいな

COBOL→UNIX-COBOL（マイクロフォーカス社のアレね）のマイグレーションの方が時間とお金を節約できるので、
そちらを選ぶ会社も多い

中堅生保のシステムはCOBOL:2500万ステップ
大手だと1億を超えるところもある（手広くやるとシステムも巨大化するので）

557 ：デフォルトの名無しさん：2007/09/22(土) 07:13:57

たったの500万ステップであのザマだったのに1億ステップやる？

それ以前にどうやって解析要員と開発要員を集めるんだ？
ただでさえ脱ITが多いのに

COBOL→UNIX-COBOLへツール変換＋調整を選ぶでしょ
JCL→シェルにツール変換できるし

558 ：デフォルトの名無しさん：2007/09/22(土) 07:56:46

＞ちなみに、COBOL:500万ステップ　→　Java：400万ステップ　になりました
＞COBOL：8行＝Java：1行じゃないんかいな

だから>>543みたいなCOBOLerがJavaやるとそんな感じになる
COBOLerが無能と言ういい証明なんだろ？

漏れだったらCOBOL比較で1/5の人員でクリアできる自信あるけど。
#ま、営業的にボるので1/3くらいにしとくが。ｗ

559 ：デフォルトの名無しさん：2007/09/22(土) 08:11:14

漏れも保険関係のシステムやったことあるけど500万ステップってすげーな。
相当に無駄テーブルやらが無駄PGMがテンコ盛りな希ガス。

たぶん、死にモジュールや期限切れ機能とか整理されていない状態で
なおかつ担当者もよく解ってない保険の掛け金管理とかやっていて、
移行中に年金問題よろしくな「おい、この客の掛け金の計算合わないぜ！」
って感じで公表できない問題のすり合わせで時間かかる事があった。

つか、この手のシステムで移行で問題なのは既存の設計が穴満載で、
その場をしのげればオッケイ的なCOBOLerの体質にあるな。
で、資料もお約束でメンテされてないので、COBOLerの作ったゴミソースを
解読しなきゃいけないが、それを頼んだCOBOLerがさらに間違えて解釈して
デスマスパイラルが深まるってオチ。

相当に割り切りのいいPMがいてCOBOLのシステムを全否定する勢いでリプレースしないと
逆に地獄を見ると思うよ。
中途半端なマイグレーションはCOBOLerが組んだシステムだと鬼門。

言語が悪いんじゃなくて、主にシステム作る人間が悪いと思う。

極稀に設計を見ると美しいなー、って人もいるから。

560 ：デフォルトの名無しさん：2007/09/22(土) 08:20:39

500万ステップが400万になったからって
何がどうというものでもないな。多いことには変わりない。
そんなにまでしてJavaにして何かメリットあんの？
流行の言語で作り直してハイカラ気分を味わいたいとか？
今COBOLでちゃんと動いてりゃそれでいいじゃん。
システム開発は保守的であるべきだ。

561 ：デフォルトの名無しさん：2007/09/22(土) 08:23:56

>今COBOLでちゃんと動いてりゃそれでいいじゃん。

現場の底辺はそれ考えでいいと思う。W

ただ会社を運営する層はシステム部門が金食い虫の無能集団と思っているから
今後の開発・運用費を安くする為にシステムをリプレースするんだろ。

そして現状はCOBOLerの質があまりに悪いので気持ちマシなJavaなり
.NETなり流れていくんだろ。

562 ：デフォルトの名無しさん：2007/09/22(土) 08:41:30

安くなるはずがなんで開発期間延びて予算が数倍に膨れあがるんだ？

563 ：556,557：2007/09/22(土) 08:56:37

>>558
？？？？？
ざっくりとした役割分担は、
コボラー：解析、仕様書作成、ランフロー作成、データ移管
Javaプログラマ：開発、テスト
です
コボラーがJavaで開発したわけではありません
基本的にコボラーは開発には参加していません

ちなみに結合テストの段階で単体レベルのバグが出て、このプロジェクトは何度も
仕切り直しています。

>>559
保険で500万ステップは小さい方です
中堅生保のシステムはCOBOL:2500万ステップ程度です
大手は1億ステップを超えます
設計の失敗を実装で取り戻すことはよくあります
しかし、残念ながらCOBOLシステムを全否定すると仕様がさっぱりわからなくなります
ドキュメントはもちろんありませんし、ユーザー、ユーザー側SEの業務理解度も低く、
解析する以外に手がなかったのです

>>560,561
マイグレーションの目的はもちろん保守開発、運用コストの削減です
UNIX-COBOL、もしくは、Javaにすることには多いに意味があります

貿易保険のシステムの場合は、現行汎用機では完全にキャパオーバーしていて、
上位機種にするか、マイグレーションするかの選択をせまられ、後者を選んだ結果です

564 ：デフォルトの名無しさん：2007/09/22(土) 08:57:55

>>558
> 漏れだったらCOBOL比較で1/5の人員でクリアできる自信あるけど。
まぁ、俺も幼稚園の頃は世界征服とかできる自信あったしな。

565 ：デフォルトの名無しさん：2007/09/22(土) 09:08:07

保険業がいつまで存在する物なのか知らないが、
一億ステップは魅力的だなぁ。宝の山だ。

566 ：デフォルトの名無しさん：2007/09/22(土) 09:14:30

＞コボラー：解析、仕様書作成、ランフロー作成、データ移管
＞Javaプログラマ：開発、テスト
＞です
＞コボラーがJavaで開発したわけではありません
＞基本的にコボラーは開発には参加していません

えと、それは９割くらいの割合でデスマの原因はコボラーにあると思うけど。
それで「コボラーは開発には参加していません」って・・・。

頭大丈夫？

567 ：556,557：2007/09/22(土) 09:17:05

>>558
何か勘違いをしているようなのではっきりと言います
・まず、あなたやあなたの所属する会社が請け負える案件ではありません
・このプロジェクトはユーザ側とベンダーが対立し、破綻しかけました
　その原因はベンダーのPMの期待を裏切るユーザ側の業務理解度の低さと
　当初見積もりの甘さ、Java開発チームのレベル、生産性の低さにあります
・結局、Javaプログラマに関しては、当初予定の2倍以上の人員を投入しています
・業を煮やしたユーザ側はNRIにコンサルティングを数度依頼しています
・日本IBMは3人目のPMに本国のテスリック氏を投入し、現場レベルからたて直し、
　このプロジェクトはやっと収束しました

この案件はマイグレーション案件としては超メジャーなもので、
ツール変換するかJavaにするかの判断材料として使われます

568 ：デフォルトの名無しさん：2007/09/22(土) 09:18:04

>>566
おかしいのは君の頭だ。
開発に参加したのはジャバラーで、
ジャバラーがCOBOLソースを解析しながら
やったらデスマになっちまいましたってことだろ。

569 ：デフォルトの名無しさん：2007/09/22(土) 09:18:18

>>563
>しかし、残念ながらCOBOLシステムを全否定すると仕様がさっぱりわからなくなります
>ドキュメントはもちろんありませんし、ユーザー、ユーザー側SEの業務理解度も低く、
>解析する以外に手がなかったのです

えと、それはコボラーが悪いって事でFA
それJavaじゃんくてC/C++/C#でも同じデスマが待っているし。
つか最初から予定調和じゃん。

それでCOBOL以外はダメポみたいな事言われても「キチガイですか？」って
返答しかできんが。

570 ：デフォルトの名無しさん：2007/09/22(土) 09:21:02

>>567
つまり、567の会社の人材は開発＆運用＆経営そろって無能って事でFA

571 ：デフォルトの名無しさん：2007/09/22(土) 09:22:57

なんか釣りまマジレスかしらんけどコボラーがこんな程度の考えだから
あの現場ではデスマがなくならないんだと思う

572 ：デフォルトの名無しさん：2007/09/22(土) 09:37:53

だからコボラーがひっちゃかめっちゃかにしたシステムを
どうリプレースするかという時に、コボルのソース解析することになったら
おしまいだという話でしょ
Javaうんぬんじゃなく

573 ：デフォルトの名無しさん：2007/09/22(土) 09:45:59

>>566
完全リニューアルのマイグレーション案件について少しは調べてからにしたら？
現行ソースの解析は、「要件」を定義する為のもの
要件は「事務基準」＋「解析結果」から作成
これは決めてからは変えてない

この案件は別に要件が間違っていて止まったわけではないよ

574 ：デフォルトの名無しさん：2007/09/22(土) 09:52:56

>>570
そうなっちゃうよねw
天下のIBMだけど
ユーザーは賠償云々を含めてマジギレだったし
（NRIは火消し役）

まさか、勘違いしてないと思うけど、
COBOL&JCLからの単純トレスがそっくりそのままJavaになると思ってないよね
だいたい機能追加しまくってるのにステップ数減ってるでしょw

575 ：デフォルトの名無しさん：2007/09/22(土) 09:54:22

つかさ、Java使いの人たちはUNIX-COBOLの存在をあまり知らないんじゃない？
金融業界が汎用機のリプレースで選ぶのは最近はUNIX-COBOLが多いよ。
金融業界で影響力を持つ野村総研がこのパターンを推進しているから。

LinuxやHP-UXというとJavaしかない！みたいな風潮が一時あったせいで誤解されているけど、
最近の金融屋はJavaのマイグレーションが失敗事例続きで懲りているからね。
最近の流行は、Linux＋Oracle＋Pro*COBOLというパターンだね。
OracleがPro*COBOLに力を入れているおかげで、OracleとCOBOLの相性は
抜群だからね。（個人的にはPro*Cなんか比較にならないくらい優れていると思う）

COBOLにはMicroFocusやHitachiのコンパイラを採用。
Javaも使っているけど、画面系に特化したところが中心。バックエンドなロジックは
Javaには任せない。JDBCは一括大量バッチ処理が苦手だから。

576 ：デフォルトの名無しさん：2007/09/22(土) 10:00:36

結論を言うと、

コボラー、ジャバラー、どっちも悪い、でFAだ

でもこの超有名案件で超がんばったのはジャバラーの方
単純トレスから、要件、外設、内設、～、実装したのは間違いなくジャバラー
相当やりにくかったと思うよ

コボラーは裏でひそかにCOBOL現行ソースに保守開発対応を入れてたんだわ
Javaでの完全リニューアルがこけたときの為に
もちろんジャバラーには内緒で
ごめんね、信用してなかったわけじゃないんだよ

保険のシステムだし、こっちも保険ってことで許してね

577 ：575：2007/09/22(土) 10:00:54

おっと、ちょっと上のほうに同業者がいたようだ。
ここでいう同業者って、金融や保険のバックエンド開発に携わっている
ミッションクリティカルなシステム屋のことね。
このスレでJava最高っていってる人って、フロントエンドばかりやっている
人っぽさそうだからな。

ところで、最近のJDBCは明るくないんだけど、少しは機能改善されているのかな？
昔のJDBCでは1行ずつしかFETCHできなかったよね。
Pro*COBOLだったた1回のFETCHで500件くらいを一気にホスト変数に格納できて
メモリ上で高速に処理できた。この機能は最近のJDBCにはあるのかな？

578 ：575：2007/09/22(土) 10:05:16

×Pro*COBOLだったた
　　　↓
○Pro*COBOLだったら

バックエンドってやっぱりバッチの世界だから、大量データを一気に
処理するバッチ機構がJavaに備われば、けっこう嬉しいんだけどね。
JCP見る限り、そっちの世界に走る気はないようだね。

579 ：デフォルトの名無しさん：2007/09/22(土) 10:11:35

つか、この貿易保険の一件で、MF-COBOLを選択するユーザーが増えた気がする
何せ、変換ツールさえ正しければ、現行システムをそっくりそのまま
UNIXに持ってけちゃうから
もちろんDBが変わったり、オンラインのプログラムは調整が必要だったりはする
けど、リスクが少ない

そして何より、コボラーがそのまま使える
喜べコボラー
UNIXをおぼえればC系言語がわからなくても仕事はあるぞ
COBOLとMF-COBOLはほとんど一緒
（若干命令語が違うが、それは慣れる）

お前ら、これからも保守でウマーだw

580 ：575：2007/09/22(土) 10:16:28

＞何せ、変換ツールさえ正しければ、現行システムをそっくりそのまま

＞もちろんDBが変わったり、オンラインのプログラムは調整が必要だったりはする

ここらへんの単純マイグレーションって最近は中国に丸投げだね。
だからマイグレーションそのものではCOBOLerは食えない。
需要があるとしたら、マイグレーション後の保守工程からだろうね。

581 ：デフォルトの名無しさん：2007/09/22(土) 10:18:14

コボラーだって薄汚いソースを読むのはつらいのに
そんなに攻めるなよ

ちょっとくらい読み間違えるさ

コボラーだもの・・・

582 ：デフォルトの名無しさん：2007/09/22(土) 10:24:15

>>580
中国人が変換して、ソースを調整してるってことですか？
オープン系の人から中国人のソースでひどい目に遭った話をよく聞くから
なんかやだなぁ
コンパイルすら通らないソースを納品してくるとか
テスト全然してないとか・・・

保守でウマーだとしても

583 ：デフォルトの名無しさん：2007/09/22(土) 10:41:25

それは少し前までの話。
日本のソフトハウスに優秀な企業からブラックな企業まであるように、
中国のソフトハウスもピンキリということですよ。
最近は中国の優秀なソフトハウスの選別も済んできていて、
高品質な仕事をするところだけに発注しているよ。
日本のプログラマはこの先、コボラ、ジャバラ問わず
ますます数が減るだろうね。

584 ：デフォルトの名無しさん：2007/09/22(土) 10:47:48

中国人はタグは中国語で書くのですか？
それとも日本語？

585 ：デフォルトの名無しさん：2007/09/22(土) 10:53:26

ありがとうCOBOL、そしてさようならCOBOL

586 ：デフォルトの名無しさん：2007/09/22(土) 10:53:34

コボちゃんスレなんか上げるなよ。臭い。

587 ：デフォルトの名無しさん：2007/09/22(土) 11:34:24

設計実装を分業したり、コーディングなんてだれでもできると言ったり
COBOL世界でしか通用しない戯言を一般化してしまう厚顔無恥さに腹が立つ

588 ：デフォルトの名無しさん：2007/09/22(土) 11:40:38

実装できない奴が設計したりするからな

589 ：デフォルトの名無しさん：2007/09/22(土) 12:00:36

日常的にCOBOLやってる人って、タイピング早いの？
自分は遅いから、COBOL初体験の時辛かった・・・

590 ：デフォルトの名無しさん：2007/09/22(土) 12:32:10

Java厨、黙っちゃったね

591 ：デフォルトの名無しさん：2007/09/22(土) 14:05:35

>>577
遅レスになった。すまんの。

JDBC にあるもの
・一度に FETCH する件数の指定
（一気に配列に格納はできない）
・複数の SQL の同時実行
（異なる SQL でも同時実行。INSERT & UPDATE 混在おｋ）
COBOL と比べて一長一短だ。

COBOL のグループ項目への一気に格納は便利だが、
COBOL が固定長配列しか扱えない泣き所があるため、
量が可変なデーターに対して最適な閾値を決めるのは難しいと思ってる。

JDBC は FETCH にループを回さなきゃいけないけど、
ライブラリまでは一度に読み込んでくれるのでレスポンスは稼げる。
調査のために COBOL & C と比較したが大差はない。
いや、細かく言うと C < COBOL < JAVA となるが僅差だ。
ボトルネックになる程度の差はないって事。

複数の SQL の同時実行は新規データと更新データが混ざってる時なんか便利だが、
それを意識してプログラムすると値のバインドに名前解決を選択することになる。
添え字解決より若干速度が遅く、これを数百のカラム数×数万件の単位でやると、
それなりにレスポンスに響いてくる。
（既存システムのテーブルを捨てられるならここまで酷くはならないが、
　そうも行かない事も多いよな？）

COBOL と JAVA の処理速度ってーのは実は大差ない。
もちろん、どちらも適切にプログラムを書き、
DB もそれぞれに最適化した場合だがな。

592 ：デフォルトの名無しさん：2007/09/22(土) 14:14:16

一気に配列に格納はできないことが短所とは思えないけどなあ
配列やArrayListにぶちこもうと思えば造作も無い

593 ：デフォルトの名無しさん：2007/09/22(土) 15:31:43

COBOLerの欠点は、RDBを生かした設計が出来ない事だろう。

594 ：デフォルトの名無しさん：2007/09/22(土) 15:37:31

終わってんだろ、それｗ

595 ：デフォルトの名無しさん：2007/09/22(土) 16:42:21

汎用モジュールのパラメータのグループ変数領域を初期化する。
階層型DB1親セグのデータの受け皿のグループ変数領域を初期化する。
階層型DB1子セグのデータの受け皿のグループ変数領域を初期化する。
階層型DB2親セグのデータの受け皿のグループ変数領域を初期化する。
階層型DB2子セグのデータの受け皿のグループ変数領域を初期化する。
階層型DB3親セグのデータの受け皿のグループ変数領域を初期化する。
階層型DB3子セグのデータの受け皿のグループ変数領域を初期化する。
汎用モジュールのパラメータを初期化する。

入力ファイルを読み込む。
入力ファイルがEOFだったとき、読み取れなかったときの例外処理を書く。

汎用モジュールのパラメータに、階層型DB1を表すリテラルをセットする。
汎用モジュールのパラメータに、キーとして入力ファイルのレコードにあるコード1をセットする。
汎用モジュールのパラメータに「ダイレクトリード」を表すマジックナンバーをセットする。
汎用モジュールのパラメータに、親セグを表すリテラルをセットする。
汎用モジュールをCALLする。
汎用モジュールのパラメータから戻り値にあたるグループ変数を階層型DB1親セグのデータの受け皿のグループ変数領域に格納する。

階層型DB1親セグのデータの受け皿のグループ変数領域にあるコード2を取得し、汎用モジュールのパラメータにキーとしてセットする。
汎用モジュールのパラメータに「ダイレクトリード」を表すマジックナンバーをセットする。
汎用モジュールのパラメータに、子セグを表すリテラルをセットする。
汎用モジュールをCALLする。

汎用モジュールのパラメータに、階層型DB2を表すリテラルをセットする。
汎用モジュールのパラメータに、キーとしてコード1をセットする。
汎用モジュールのパラメータに「ダイレクトリード」を表すマジックナンバーをセットする。
汎用モジュールのパラメータに、親セグを表すリテラルをセットする。
汎用モジュールをCALLする。
汎用モジュールのパラメータから戻り値にあたるグループ変数を階層型DB2親セグのデータの受け皿のグループ変数領域に格納する。

596 ：デフォルトの名無しさん：2007/09/22(土) 16:43:45

階層型DB2親セグのデータの受け皿のグループ変数領域にあるコード3を取得し、汎用モジュールのパラメータにセットする。
汎用モジュールのパラメータに「ダイレクトリード」を表すマジックナンバーをセットする。
汎用モジュールのパラメータに、子セグを表すリテラルをセットする。
汎用モジュールをCALLする。
汎用モジュールのパラメータから戻り値にあたるグループ変数を階層型DB2子セグのデータの受け皿のグループ変数領域に格納する。

汎用モジュールのパラメータに、階層型DB3を表すリテラルをセットする。
汎用モジュールのパラメータに、キーとしてコード1をセットする。
汎用モジュールのパラメータに「ダイレクトリード」を表すマジックナンバーをセットする。
汎用モジュールのパラメータに、親セグを表すリテラルをセットする。
汎用モジュールをCALLする。
汎用モジュールのパラメータから戻り値にあたるグループ変数を階層型DB3親セグのデータの受け皿のグループ変数領域に格納する。

以下をＸ回繰り返す。
　汎用モジュールのパラメータに、階層型DB3を表すリテラルをセットする。
　階層型DB3親セグのデータの受け皿のグループ変数領域にあるコード4を取得し、汎用モジュールのパラメータにセットする。
　汎用モジュールのパラメータに「シーケンシャルリード」を表すマジックナンバーをセットする。
　汎用モジュールのパラメータに、子セグを表すリテラルをセットする。
　汎用モジュールをCALLする。
　汎用モジュールのパラメータから戻り値にあたるグループ変数を階層型DB3子セグのデータの受け皿のグループ変数領域に格納する。

　階層型DB3子セグのデータの受け皿のグループ変数領域にあるコード5と階層型DB1子セグのデータの受け皿のグループ変数領域にあるコード5、
　および階層型DB3子セグのデータの受け皿のグループ変数領域にあるコード6と階層型DB2子セグのデータの受け皿のグループ変数領域にあるコード6が同じなら、
　階層型DB3子セグのデータの受け皿のグループ変数領域にあるコード7を出力ファイルに書き込む。

597 ：デフォルトの名無しさん：2007/09/22(土) 16:47:20

↓

select コード7
from　 DB1-1, DB1-2, DB2-1, DB2-2, DB3-1, DB3-2
where　DB1-1.コード1 = 引数
　 and DB2-1.コード1 = 引数
　 and DB1-2.コード2 = DB1-1.コード2
　 and DB2-2.コード3 = DB2-1.コード3
　 and DB3-2.コード4 = DB3-1.コード4
　 and DB3-2.コード5 = DB1-4.コード5
　 and DB3-2.コード6 = DB1-4.コード6

598 ：デフォルトの名無しさん：2007/09/22(土) 17:30:06

ProCOBOLしかやったことないコボラ－な俺
上のやつが階層型DBってやつかい？

599 ：デフォルトの名無しさん：2007/09/22(土) 18:46:59

階層型DBってわかりやすいんだよなあ。
テーブルの親子関係が、文字通り家系図みたいに
上から下へと定義されてるからね。設計がサクサク進む。
DBアクセスおよび取り出したデータの処理をいちいち
プログラムでしてやらなきゃならんけど、わかりやすく
保守しやすい。
RDBは階層という概念がないため、テーブル数が増えると
設計者の脳内スタックに負担をかけ、開発・保守が非常に
困難となってくる。

600 ：デフォルトの名無しさん：2007/09/22(土) 19:39:25

はあ、保守が困難っすか……
どう見てもRDBの方が扱いやすそうなんですが。
"One fact One place"の原則って知ってる？

データに更新かけたいとき、方々のDBに好き勝手なフォーマットで記録されてるそいつらの整合性を保つのにどれだけの手間がいるだろうね。
固定長のレコードで記録されてるから、桁数や項目の拡張もやりにくくて、
「個人情報データは20桁目～305桁目と1050桁目～1054桁目と1080桁目～1100桁目、
　所属組織データは306桁目～500桁目と1055桁目～1068桁目」みたいな構成がしょっちゅうでてきたり、
ひどいのになると、5桁のデータを記録するとき、上3桁と下2桁が別の領域に記録されてたり。
構造体がちゃんと作られてない場合、レコードのレイアウトを見ながら直接桁数を切ってデータやりとりしたり。

601 ：デフォルトの名無しさん：2007/09/22(土) 19:48:43

道具の使い方が簡単だからといって、複雑な作業が簡単になるはずはないわな
コボラはよくフラグを使うが、開発回次を重ねるごとにフラグの管理が異常に困難になっていく

602 ：デフォルトの名無しさん：2007/09/22(土) 20:26:52

Java使いの無意味なクラス分割とかモナー

そういえばJ2EEのデザパタとか酷いよな
昔からある構造化の考え方をSession Facadeだの何だの
さも新しい概念であるかのように喧伝して
ただの構造体をValue Objectとか言ってるのは笑えたよ
EJBも結局Stateless Session Beanしか使い物にならずに廃れたし

結局DOAなんてイキがってたのが、実装には到底使えない
机上の空論だと分かって、やがて構造化設計に戻っていったのに、
それを認めたくないからってデザパタなんて言葉でごまかしてな

603 ：デフォルトの名無しさん：2007/09/22(土) 21:06:29

>>602
デザインパターンの意味を知って発言してるとは
到底思えないんだけど。

これも釣りなの？

604 ：デフォルトの名無しさん：2007/09/22(土) 21:09:15

都合が悪いとすぐ釣りとしか書かない人物

ずっとこのスレに常駐ｗｗ

605 ：デフォルトの名無しさん：2007/09/22(土) 21:10:49

デザインパターンって、所謂GoFのでしょ？
オブジェクト指向に特化した考え方の中に、むりやり構造化の概念を
詰め込んでいるのが滑稽だという意味じゃないの？

606 ：デフォルトの名無しさん：2007/09/22(土) 21:40:28

COBOLer（失笑）…… Java 叩きはまだしも、
OO 叩きはじめると底の浅さが露見するから迂闊な事はやめとこうぜ。
データ主体に考える事ができない時点で、
OO のオの字も理解してないってバレバレになるからさ。

607 ：デフォルトの名無しさん：2007/09/22(土) 21:43:33

オブジェクト指向は構造化なんかとっくの昔に包含してますから

608 ：デフォルトの名無しさん：2007/09/22(土) 21:44:44

無理やり構造化のって意味不明もいいとこ
Javaのメソッドは手続きじゃん
構造化設計のノウハウは全てそのまま使えるだろ

609 ：デフォルトの名無しさん：2007/09/22(土) 21:58:23

>>603=>>606wwww
具体的に反論できないバカ
データ主体に考えて成功した大規模プロジェクトを挙げてみな

>>607=>>608
その割りには構造化をバカにするのが典型的なJava厨の特徴ﾌﾟｷﾞｬｰ

あと時間はもっとずらしてレスしようぜ
どうせ1人の自演なんだろうがな

610 ：デフォルトの名無しさん：2007/09/22(土) 21:59:30

>>602
そもそもデザインパターンてのは
使い古された設計の手法を
パターン化して共通言語にしましょうていうのが
狙いだから「こんなの今までも使ってたよ」て
馬鹿にすること事態が間違ってる。

大体Javaに特化した話でもなんでもないし。
OO指向のパターンでなければ
Cで組んでもそれこそCOBOLで組んでも
間違いではない。

611 ：デフォルトの名無しさん：2007/09/22(土) 22:01:35

OOのことは全然分からないコボラ－ですが、
データ指向（DOA）の失敗の果てにサービス指向（SOA）が
生み出されたと聞いたことあるのですが。（Javaな人に）

612 ：デフォルトの名無しさん：2007/09/22(土) 22:02:44

> OO指向のパターンでなければ

うわ！全然分かってないじゃん！！

613 ：デフォルトの名無しさん：2007/09/22(土) 22:04:24

構造化をバカにする？
どのレスのことよ

614 ：デフォルトの名無しさん：2007/09/22(土) 22:04:39

はっきりと言えることは、

現在コボラーの人は10年後もコボラーの可能性が高い
現在Java房の人は10年後異業種に転職しているか、死んでいる可能性が高い

615 ：デフォルトの名無しさん：2007/09/22(土) 22:05:32

えー？普通デザパタってOOに対して使う言葉でしょ？
めちゃめちゃ広義に捉えた場合は知らんが、普通デザパタといえばOO。

wikiにもGoFの考え方が書いてあるじゃん。
[Design patterns] solve specific design problems and make object-oriented designs more flexiblem elegant,
and ultimately reusable. They help designers reuse successful designs by basing new designs on prior experience.
A designer who is familiar with such patterns can apply them immediately to design problems without having to
rediscover them.

616 ：デフォルトの名無しさん：2007/09/22(土) 22:07:39

デザパタ論議はオブスレでどうぞ
いくらなんでもここでやるのはどうかと思うぞｗ

617 ：デフォルトの名無しさん：2007/09/22(土) 22:07:53

プログラマのレベルって、どの言語を使っているか、じゃなくて
どんなシステム開発を行ってきたかだと思うんだけど。

金融歴20年のコボラ－と、Webアプリ5年のジャバラだったら
どっちを採用すると思う？

618 ：デフォルトの名無しさん：2007/09/22(土) 22:10:04

>>617
どう考えてもJavaのほうだろ。アホか
5年のコボラと20年のジャバラだと、まだちょっと悩むがな

619 ：デフォルトの名無しさん：2007/09/22(土) 22:10:51

そもそもバッチ処理中心のCOBOLと
Webアプリ中心のJava自体、生息地帯が違いすぎるだろ
不毛な議論

620 ：デフォルトの名無しさん：2007/09/22(土) 22:11:46

>>618
ひぇぇぇぇ

621 ：デフォルトの名無しさん：2007/09/22(土) 22:21:18

金融歴20年のコボラ－はもう派遣か請負しかないよ
まともな会社に社員採用はまずない

622 ：デフォルトの名無しさん：2007/09/22(土) 22:28:48

普通に銀行のシステム子会社を渡り歩けばいい。
銀行のシステム開発は人手がいくらあっても足りない。
あまりにデータ量が多い＆ミッションクリティカルなため、
メインフレーム＋コボルでしか運用できないのだ。

623 ：デフォルトの名無しさん：2007/09/22(土) 22:35:29

>>622
ああ、その手があった
生保、損保の子会社もあるね
データ量＝契約件数＊1.4倍くらいあるから、マジで半端ないw
正直外資系、年俸制とかはヤバそうだけど、やってる人いる？
求人内容には18:30には帰宅しています、なんて載ってるけど、どう考えても
嘘だよな

派遣：2次受けの会社（客先常駐）も含む

624 ：デフォルトの名無しさん：2007/09/22(土) 22:38:26

保険や金融はねえ、最低でも100人月以上の仕事だから
人手はとにかく足りないんだよねえ

625 ：デフォルトの名無しさん：2007/09/22(土) 22:38:59

いまだにATMが24時間動いてないのは
コボラーが夜間にシステムとめて変な処理してるからだろ
いい加減目を覚ませよ
お前らのやってることは間違いだらけだ

626 ：デフォルトの名無しさん：2007/09/22(土) 22:39:18

俺派遣コボラー（直近は一般派遣）だけど、
元請のユー子とかに入れたりするのかな
現在30歳だけど・・・

もうムリかな・・・

627 ：デフォルトの名無しさん：2007/09/22(土) 22:44:52

>>625
通信系のバックも汎用機なんですが。。。

628 ：デフォルトの名無しさん：2007/09/22(土) 22:59:55

>>625
金融系のシステムでやってるのが
オンライン処理だけだとでもおもってるの？
そもそもバッチ処理を動かすことと
オンラインシステムを止めることは関係ないし

最初の設計段階で24時間稼動まで考えて
なかったんだからそう動いてないシステムが
まだ存在するのは当たり前で
言語の問題ではない。

基幹系のシステムをちゃんと勉強してね
JAVAでやるにしたって必要な知識でしょ

629 ：デフォルトの名無しさん：2007/09/22(土) 23:01:26

Javaが基幹系をやるケース自体レアだと思うけどなあ
一時期はそういう風潮もあったけど
今ではIBMも含めてどのSIもそんな提案してないでしょ
失敗して責任とらされるの怖いもんね

630 ：デフォルトの名無しさん：2007/09/22(土) 23:10:09

>>626
力量にもよるだろうけど
団塊が一気に抜けることを考えると
今一番必要な世代ってな気もする

逆に言えば移るなら今かもね

色々いってるけど
俺らが現役の間は絶対にCOBOLは
無くならないよ、つか無くせない

631 ：デフォルトの名無しさん：2007/09/22(土) 23:20:45

いや、そりゃ無くならないとは思うよ(無くなって欲しいけどｗ)
でもそれって、コボラは概して不勉強であり、周りに害を与える存在であるって事実と
なんら関わりないことだよね？

632 ：デフォルトの名無しさん：2007/09/22(土) 23:26:01

まあ絶滅はしないにせよ現代言語に置き換えられていく流れは変わりようがない

633 ：デフォルトの名無しさん：2007/09/22(土) 23:27:46

そういえば以前いた現場では、バッチ処理が昼間動いてたよ。
何時間か置きにデータをDBに格納するの。COBOL関係ないけどね。
そういう状況下では別に夜間止める必要ないな。

俺のやった仕事で言えば、メインフレームからOracleへのリプレースで
COBOLで書いていた夜間の集計処理をPL/SQLに置き換えるってのはあった。

一方でWebシステムのサーバーサイドにCOBOL使ったりしてるところもある。
F社の何とかステージとやらで...製品知識無いんであまり説明できないけど。

結局音頭取ってる人間次第で使う言語や構成が変わるんだろうね。

634 ：デフォルトの名無しさん：2007/09/22(土) 23:36:27

> でもそれって、コボラは概して不勉強であり、周りに害を与える存在であるって事実と
> なんら関わりないことだよね？

ソースは？

635 ：デフォルトの名無しさん：2007/09/22(土) 23:46:29

ソースねぇ・・・

Java使いが叩かれるのも、コボラが叩かれるのも
そこには幾許かの真実があるからだと思うけど

まず、あんたはどう思ってんのよ

636 ：デフォルトの名無しさん：2007/09/23(日) 00:00:49

IBMがシステムマイグレーションで完全Javaリニューアルを提案するとは思えないw

もう懲りたべ

637 ：デフォルトの名無しさん：2007/09/23(日) 00:06:23

話をすりかえるなよ。
ソース出せよソース。

638 ：デフォルトの名無しさん：2007/09/23(日) 00:08:14

脳内ソースだろｗｗ
真実だってよ　笑っちまうｗｗ
「思う」なんていわずにソースだして断言してみろよ

639 ：デフォルトの名無しさん：2007/09/23(日) 00:35:38

ソース出せとか、いつの時代の煽りだよｗ
何にでも乗り遅れるのがコボラか？ｗｗ

640 ：デフォルトの名無しさん：2007/09/23(日) 00:50:43

ソースが出せない電波厨房の負け惜しみ劇場が始まりましたｗｗｗｗｗ

641 ：デフォルトの名無しさん：2007/09/23(日) 01:03:43

悲惨だな

642 ：デフォルトの名無しさん：2007/09/23(日) 01:17:08

今頃必死でネット上でソースをかき集めようとしている
涙目の>>639の姿が目に浮かぶ

643 ：デフォルトの名無しさん：2007/09/23(日) 01:19:52

アホなコボラーの例をいくつあげればいいんだ？

644 ：デフォルトの名無しさん：2007/09/23(日) 01:40:19

いいから早くソースを出せ。話はそれからだ。

645 ：デフォルトの名無しさん：2007/09/23(日) 01:42:21

ソースと思ってあげても君らがソースと思わなかったら意味がないからな
何をあげればソースと認めるのか、そこをまず聞こうか

646 ：デフォルトの名無しさん：2007/09/23(日) 01:49:53

ﾌﾟｯ

647 ：デフォルトの名無しさん：2007/09/23(日) 01:50:46

コボラー相手に論理的な話し合いなど不可能ということかな

648 ：デフォルトの名無しさん：2007/09/23(日) 02:01:46

もうどう考えたって敗北してんだから　大人しくいなくなればいいのに
これ以上負け惜しみを重ねることもあるまい　惨めな気持ちになる

649 ：デフォルトの名無しさん：2007/09/23(日) 02:04:42

だーかーらー
「コボラは概して不勉強であり、周りに害を与える存在である」
と類似する文書を書いてあるソースを出せっつーの

それができねーならとっとと尻尾を巻いて消えろよ、この四つ足が

650 ：デフォルトの名無しさん：2007/09/23(日) 02:05:53

試しに「コボラ不勉強」でぐぐったら、出てきたのほとんど2chだったぞ藁

651 ：デフォルトの名無しさん：2007/09/23(日) 02:06:01

コボラ進退窮まって自演かよ
ひでぇなこりゃｗ

652 ：デフォルトの名無しさん：2007/09/23(日) 02:21:47

村上龍は13歳のハローワークで
コボラは無能であり日本から消えていく存在だと言っていたな

653 ：デフォルトの名無しさん：2007/09/23(日) 02:38:36

●●は○○だからダメっていうレッテル貼りに終始してる奴って
自分の無能さから目を背けてるだけだったりするんだよね。

654 ：デフォルトの名無しさん：2007/09/23(日) 02:59:11

ｺﾎﾞﾗは馬鹿だけど
ｺﾎﾞﾗ叩きはそれに輪を掛けて馬鹿だったって事か

655 ：デフォルトの名無しさん：2007/09/23(日) 10:33:50

亀レスだけど

＞最近の流行は、Linux＋Oracle＋Pro*COBOLというパターンだね。

某金融系の某○立が似た事やってんだけど、
こっちとしてはデータが出来れば文句ないが、
Oracleのテーブルに主キーなし、インデックスなし、全カラムnull可で
ユーザー側でそのデータで分析やろうとしても３０分～３時間くらい
結果が返ってこないワケだが・・・。

もう少し某日○はRDBの事を勉強してください。おながいします。

ぶっちゃけ漏れがSQL+JDBCアプリ組んだ方が１００倍速いです。

656 ：デフォルトの名無しさん：2007/09/23(日) 10:38:03

>>655
つうかＥｘｃｅｌＶＢＡでフロント組んでも勝てるじゃね

657 ：デフォルトの名無しさん：2007/09/23(日) 10:45:18

それは日立が無能なのであって言語とは関係ない
DB設計をプログラマがやるような超小規模な案件なら話は別だがな

658 ：デフォルトの名無しさん：2007/09/23(日) 10:45:45

>>656
いや、それはAccess+VBAがフロントエンドのシステムでつ。
そのOracleと連携してアレコレしているそうですけど、
根本的に実効速度を無視している感ありで、
ユーザーが「遅いよー」とゴネでも「データ量が多いのでそれくらい時間かかります」
とかヌカしやがった。ｗ

さすが年金問題な某日○だな、と思いました。

漏れがIBMの鯖で試しにテーブル移植しサンプルをJava+SQLで作ったら
たら100倍近く早くなったけどサ。

659 ：デフォルトの名無しさん：2007/09/23(日) 10:51:43

>>657
主に日立が無能なのは同意だけど、ユーザーの要望に合わせて
言語を選択するのは、規模関係ないと思うけど。
COBOLでもデータ分析に適したリレーショナルなＤＢシステム作れると思うけど、
やっぱCOBOLerが設計すると横長DBになりがちではあるよ。

純(?)なSQL上がりな人間からするとSQL発行できれば、CでもJavaでもVBAでも
言語はどれでもよかったりするけど、COBOLerとExcel信者は
横長志向だとｵﾓ。

660 ：デフォルトの名無しさん：2007/09/23(日) 10:54:03

主キーがないってすげえな

661 ：デフォルトの名無しさん：2007/09/23(日) 11:26:51

＞普通に銀行のシステム子会社を渡り歩けばいい。
＞銀行のシステム開発は人手がいくらあっても足りない。

この間、システム共同化とかいって地銀のシステム子会社の
エンジニアは軒並み仕事がなくなったワケだが。
地銀系はこの流れになっていくとｵﾓ。
なんか都銀のパッケージを不思議に啓蒙している不思議な経営陣だから。

漏れの知るところの都銀のシステム子会社(某○菱系)だと仕事はあるにはあるけど、
孫会社や下請けに丸投げの中間マージン搾取会社となっているフシがあるから、
あんまし銀行系の開発ってお勧めしない。特に某○菱は死ぬほど金払いが悪い。

他の都銀は金払いいいのか知らんけど。似たようなモノだとｵﾓ。

662 ：デフォルトの名無しさん：2007/09/23(日) 11:32:25

なんで中間搾取会社なんてのが存在できるんだろうな
合理化という言葉はどこに消えてしまったんだろう

663 ：デフォルトの名無しさん：2007/09/24(月) 00:09:09

コボラにDB設計やらせると主キーなしのテーブルができるって、、、
それってどこかに元ネタがあってそれが広まった都市伝説じゃないの？

ファイルにソートキーつけまくってブレイク処理しまくる処理に慣れている
コボラが、キーの概念を知らないというのは考え難いんだけど。

664 ：デフォルトの名無しさん：2007/09/24(月) 00:15:27

俺の今いる職場、COBOLつかってないし、元々の設計者がCOBOLerかどうかも分からんけど、
トランザクションに主キーが無い。

665 ：デフォルトの名無しさん：2007/09/24(月) 00:42:49

別に主キーなんてなくてもいいじゃん。
COBOLの世界じゃ、レコードの格納順番が
そのままキーということが非常に多い。

666 ：デフォルトの名無しさん：2007/09/24(月) 01:00:59

＞トランザクションに主キーが無い。

ごめん意味不明

667 ：デフォルトの名無しさん：2007/09/24(月) 05:44:14

>>663
都市伝説もなにも実在する以上の証明はないワケですが。

変に汎用機慣れしているとユーザーサイドの使い勝手と言うか、
COBOLの「全件読んでからブレイク集計」と一般的SQLの「情報を
集合で扱う」概念が身にしみてないだけだろう。

668 ：デフォルトの名無しさん：2007/09/24(月) 08:54:16

> 実在する以上の証明はない

お前の周りだけだろ
つかお前>>631だろ？？根拠のない断言大杉
貴様のことを「思い込み厨」と命名するｗｗ

669 ：デフォルトの名無しさん：2007/09/24(月) 09:05:16

ここでCOBOL叩いている人って、実際のCOBOLの知識なさそう。
ネットの記事や２ｃｈだけ読んで思い込んでいるというか。。。
家にこもってないで外に出ろ！現実を見ろ！

670 ：デフォルトの名無しさん：2007/09/24(月) 12:40:25

>>666
後ろに「データ／ファイル／テーブル」などと付けなきゃ分からんか？
要するに取引データみたいな物のことだが、、

一つの取引を特定できないって状況なんだよ。

671 ：デフォルトの名無しさん：2007/09/24(月) 12:54:26

ここでCOBOLer叩きしてるヤツが馬鹿だという事がよく分かった
コボラを叩きたいんなら、他スレでやってくれ

672 ：デフォルトの名無しさん：2007/09/24(月) 13:17:34

>>670
やっぱり、意味不明。

673 ：デフォルトの名無しさん：2007/09/24(月) 14:29:42

コボラ叩きの言ってることの方が説得力があるぞ
コボラ叩きを叩いてる連中の発言には中身が何も無い

674 ：デフォルトの名無しさん：2007/09/24(月) 16:33:18

>>673
それ、冗談で言ってるんだよな？(笑)
コボラ叩きはレッテル貼りしかしてないじゃないか。

675 ：デフォルトの名無しさん：2007/09/24(月) 16:55:09

仕様の枯れてない言語は嫌なんだよなあ。
Javaはすぐに次のバージョンが出てしまう。
俺なんか1.2の参考書の勉強がまだ終わってないぜ。

676 ：デフォルトの名無しさん：2007/09/24(月) 20:40:56

今までオープン系を10年近く経験してきたが、

「トランザクションに主キーが無い」はおろか

という表現はいまだかつて聞いたことないな。

677 ：デフォルトの名無しさん：2007/09/24(月) 22:25:24

＞コボラ叩きはレッテル貼りしかしてないじゃないか。

主キーがないやら、インデックス知らないとか具体例満載で
説明されているのに「レッテル貼り」とは日本語読めない人か？

つかコボラーは釣りかマジレスか解らん池沼が多いな。

678 ：デフォルトの名無しさん：2007/09/24(月) 22:51:50

＞主キーがないやら、インデックス知らないとか具体例満載で

いやだから、そんな人いないから・・・てこのスレで書いてるのに。
なんでCOBOL＝DB知識がないって思い込んでるんだろう、この人。
COBOLだって普通にOracleバリバリ使うのに。

それで、「トランザクションに主キーが無い」って何？

679 ：デフォルトの名無しさん：2007/09/25(火) 00:09:27

>>664＝>>670≠>>677ですが、
「トランザクションに主キーが無い」はおろか
という表現は、おれも>>676ではじめてみましたよっw

トランザクションテーブルに主キーが設定されてない実例はあるよって言ってるだけなんだが。。。。
おまけにCOBOLerとの関連は不明としているでしょ。ちなみに俺自身経験の半分はCOBOLだし。

俺は10年も経験ないけど、主キーの無いテーブルを見たのは初めてだったのは確か。
逆に主キーが無いテーブルってのは結構多いの？

680 ：デフォルトの名無しさん：2007/09/25(火) 00:21:36

各レコードに5明細ずつとかわけわからん設計してるくせに
「主キーくらい知ってるわ！」と言って熱くなるコボラｗ

681 ：デフォルトの名無しさん：2007/09/25(火) 00:38:46

それはコボルとかコボラは関係なく
設計が馬鹿なだけで・・・

682 ：デフォルトの名無しさん：2007/09/25(火) 00:59:34

いい加減敗北を認めて去ればいいのにねぇ・・・

683 ：デフォルトの名無しさん：2007/09/25(火) 01:08:05

>>681
横長テーブルはCOBOLの言語仕様と関係ないとは言えないのでは？

684 ：デフォルトの名無しさん：2007/09/25(火) 01:11:20

なんでやねん

685 ：デフォルトの名無しさん：2007/09/25(火) 01:41:19

敗北も何も・・・
コボラやコボルと関係ないことで叩かれてもねぇ

686 ：デフォルトの名無しさん：2007/09/25(火) 01:49:08

金融商品のマスタテーブルや、株式・債券の約定取引テーブルなんていったら
カラム数100個なんて簡単に突破する横長テーブルになると思うのだが・・・。

あと、パフォーマンスを重視した正規化崩しとして、テーブルのカラムに
項目1、項目2・・・と繰り返しを定義するのは、必ずしも間違いではない。
数テラバイトのデータを扱うDWHでは一般的な手法。スタースキーマあるいは
スノーフレークスキーマの形を美しく整えるほうが大切。

687 ：デフォルトの名無しさん：2007/09/25(火) 02:06:30

DWHか、懐かしい。
購買テーブルのレイアウトに、商品コード、商品名漢字、商品名略称、商品名カナ、
商品単価、商品製造日付・・・なんて項目がずらっと並んでいるんだよね。
商品属性をマスタに出して従属させちゃいけないんだよね。

688 ：デフォルトの名無しさん：2007/09/25(火) 02:28:46

>>679
トランザクションでなくて、
取引明細テーブルに主キーがないと
言ってくれれば誰でもわかる。

689 ：デフォルトの名無しさん：2007/09/25(火) 02:37:26

たぶん彼はもう話の流れについていけなくなって
逃走間際だと思うよ

690 ：デフォルトの名無しさん：2007/09/25(火) 03:46:29

もう一つ考えられるのは、従来の
トランザクションファイル(マスターファイルに対する更新要求列)を
テンポラリなテーブルとして、DBに持つケース。データ管理の一元化
などで起こりうる。上の方で日立を馬鹿にした書き込みが続いていたが
これなのではないか。
せっかくテーブルに仕立てたのだから、主キーくらいは設定して、
更新に行く前にチェックもしようよの意味で使ったのだろう。

691 ：デフォルトの名無しさん：2007/09/25(火) 06:41:08

＞＞主キーがないやら、インデックス知らないとか具体例満載で
＞いやだから、そんな人いないから・・・てこのスレで書いてるのに。

ナニ半島の人みたいなレスするんだか。ｗ

オマエみたいな池沼は現実に存在する。

つかOracle社の中の人が見たら笑う様なレスすんなよ。

692 ：デフォルトの名無しさん：2007/09/25(火) 09:47:13

うわあ・・・具体的な反論ができなくなっちゃってるう（笑）

693 ：デフォルトの名無しさん：2007/09/25(火) 10:20:59

負け惜しみって惨めだねぇ

694 ：デフォルトの名無しさん：2007/09/25(火) 12:26:30

・特定条件下で横長テーブルが妥当であることと、あらゆる条件下で横長テーブルが妥当であることとは違う
・DB詳しいコボラが存在することと、全てのコボラがDBに詳しいこととは違う

よってコボラの反論はすべて詭弁以下

695 ：デフォルトの名無しさん：2007/09/25(火) 12:39:40

会社が昼休みになったのかｗｗ

＞DB詳しいコボラが存在することと、全てのコボラがDBに詳しいこととは違う

これってそっくりそのまま

＞DB詳しい蛇腹が存在することと、全ての蛇腹がDBに詳しいこととは違う

にあてはまるね
ほとんどの蛇腹は、create table文さえ知らないアフォな兵隊だからねｗｗ

696 ：デフォルトの名無しさん：2007/09/25(火) 12:44:06

>>695
＞DB詳しい蛇腹が存在することと、全ての蛇腹がDBに詳しいこととは違う
あたりまえでしょ。何を得意になってるのやら

だけど、横長テーブルやフェッチを好む蛇腹は居ないんだよ
何のメリットもないから

697 ：デフォルトの名無しさん：2007/09/25(火) 13:06:23

ｱｲﾀﾀﾀﾀﾀ

＞横長テーブル
君の職場がしょぼいテーブルしか使わない程度の案件しかやってないんでしょう

＞フェッチを好む
フェッチの意味よく分かってないんじゃないの？

698 ：デフォルトの名無しさん：2007/09/25(火) 13:08:00

このアンチ君、2年目くらいのスキルしかないんじゃないの？
開発経験本当にあるの？単なるプログラムオタクレベルっぽい。
もしかして愛読書はWebDB Pressかい？（爆笑）

699 ：デフォルトの名無しさん：2007/09/25(火) 13:12:13

頭痛くなってきた・・

・特定条件下で横長テーブルが妥当であることと、あらゆる条件下で横長テーブルが妥当であることとは違う

「「「不適当な条件下で」横長テーブルを好む」蛇腹はいない」

な？

バカなの？

何が「君の職場が・・」ｗなの？

バカ？

よーく考えてよ。

無理？

700 ：デフォルトの名無しさん：2007/09/25(火) 13:14:51

ひっこみがつかなくなってきたな

701 ：デフォルトの名無しさん：2007/09/25(火) 13:15:39

あ、あとさ
＞だけど、横長テーブルやフェッチを好む蛇腹は居ないんだよ
これのソースは？

702 ：デフォルトの名無しさん：2007/09/25(火) 13:16:11

うちの部下のJava使い、キーのないテーブル設計して俺に持ってきたよ。

703 ：デフォルトの名無しさん：2007/09/25(火) 13:17:07

おまいら、新人をあまりイジめるなよ

704 ：デフォルトの名無しさん：2007/09/25(火) 13:18:04

だっていじくり甲斐があるんだもんｗ
今の職場じゃ、無能な部下をいじめるなんてしたら問題になっちゃうからねｗｗ

705 ：デフォルトの名無しさん：2007/09/25(火) 13:19:39

あれ、順番まちがえちゃった？

俺の職場がしょぼいテーブルしか使わない程度の案件しかやってないソースと

フェッチの意味よく分かってないソース

はやくだせやボケ

706 ：デフォルトの名無しさん：2007/09/25(火) 13:23:25

客観的に見てコボラは逃げに終始
説得力ゼロだな

707 ：デフォルトの名無しさん：2007/09/25(火) 13:26:31

>>702-704
なんですぐ涙目なんだよ

泣くほど悔しいんだったら、はじめから勉強しろバカ

708 ：デフォルトの名無しさん：2007/09/25(火) 13:29:18

フェッチが有効なときもあるが、複雑なUpdate文を組み立てられなくてフェッチを使っているケースがよくあるね
そしてフラグとIF文満載なストアードプロシージャ、どうやってメンテすればいいんだよ

709 ：デフォルトの名無しさん：2007/09/25(火) 13:34:55

ソースソースってうぜえょ

>ほとんどの蛇腹は、create table文さえ知らないアフォな兵隊だからねｗｗ

ほれ、ソース出してみろ
それか二度とソースでごまかそうとスルナヨ糞低脳が

710 ：デフォルトの名無しさん：2007/09/25(火) 18:00:12

では、まず君のソースを見せてもらおうか？
君が最初にケンカ売ったんだかんね。
自分のソースが出せないからって転嫁するなよ。

711 ：デフォルトの名無しさん：2007/09/25(火) 18:05:52

たった1人で孤立無援の戦いを続けるMr.トランザクションに武運のあらんことを・・・

>>664
>>667
>>670
>>674
>>677
>>679
>>680
>>683

712 ：デフォルトの名無しさん：2007/09/25(火) 18:06:23

>>685
>>691
>>694
>>696
>>699
>>705
>>706
>>707
>>709

713 ：デフォルトの名無しさん：2007/09/25(火) 19:11:43

>>711-712

流石はコボラ

センスは古いし、仕事はいい加減

714 ：デフォルトの名無しさん：2007/09/25(火) 19:44:37

Java使うヤツは出来るのとか出来ないのとか当たり外れが激しいとは
思うけど、COBOLerは正直、現代においては外ればっかだと思うが。

特にこのスレのコボラのマジレス（ｗ）をみてるとな・・・。
#釣りにしても酷いが・・・

715 ：デフォルトの名無しさん：2007/09/25(火) 20:17:48

>>711-712　それは間違い。

>>664 は、
マスタ系／トランザクション系に分類したときにトランザクション系って意味でトランザクションと書いた。
マスタ系には主キーが付いているので。

>>670 は、
はじめは>>666がトランザクション↓ここらへんの意味でとらえていると思って書いた。
http://www.sophia-it.com/category/transaction.jsp

>>679 は、
若干カチンときてるが、俺はCOBOLer叩きでも、蛇腹でもない。(COBOLerのつもりでもないけど)
すでにアンタらほど経験もありませんよって認めている。

あとのレスは俺じゃない。

それから横長に付いては、「パフォーマンスのために...」てあたりは一応知識としては知っている。
だから必ずしも否定的ではない。

>>697
これはアドバイスとして受け取っておく。
ありがとう。

俺が書きながら思い出していたテーブルは、明細は横に持っていて、横が足りないと縦を追加している。
店番号(i)　日時(i)　明細1　明細2　明細3　その他の項目．．．こんな感じ(iはインデックス)
で実際に担当者がこのレコードを探し出すときに、明細の金額まで見てやっと判断してる。
だからもう少し確実なキーが要るんじゃないかと思う。

716 ：715：2007/09/25(火) 20:22:44

間違えた。
>>697 -> >>688

717 ：デフォルトの名無しさん：2007/09/25(火) 20:29:29

客観的に見て、論理性・人間性ともにアンチの方が上だな

718 ：デフォルトの名無しさん：2007/09/25(火) 21:49:26

IDが出ないから自作自演し放題だな

そろそろCOBOLの質問したいんだけど、、、

719 ：デフォルトの名無しさん：2007/09/25(火) 22:09:47

＞IDが出ないから自作自演し放題だな

確かにCOBOLerの自作自演がかなり酷いな・・・

720 ：デフォルトの名無しさん：2007/09/25(火) 22:33:21

いや、君のほうが必ｒｙ

721 ：デフォルトの名無しさん：2007/09/25(火) 22:40:04

なにがなんでもアンチの自作自演にしないと気が済まないのか・・・。

どーでもいいじゃん。現実のコボラーが改心するワケでもなし。

722 ：デフォルトの名無しさん：2007/09/25(火) 22:58:14

そうだな。無能な君がJavaから卒業できるわけでもないし。
Java使いなんてCOBOLer以下の最下層デジドカだという現実に目を向けなよ。

723 ：デフォルトの名無しさん：2007/09/25(火) 23:01:41

とにかく大文字だ大文字。
大文字で書けるJavaならば勉強する気になれる。
誰か作ってくれ。改造は意外と簡単なような気がする。

724 ：デフォルトの名無しさん：2007/09/25(火) 23:39:43

COBOL勉強中。
思ったより流れが速いだけでなんだか嬉しいです。

725 ：724：2007/09/25(火) 23:42:37

あ、流れって、このスレの流れね。

726 ：デフォルトの名無しさん：2007/09/25(火) 23:58:00

COBOL勉強するなら、端末COBOLや余分なファイルI/Oは飛ばしても構わんぞ。
基礎文法さえ押さえたら、すぐにでもOracleのPro*COBOLを勉強すべし。
オープン系COBOLは今かなり需要がある。

727 ：デフォルトの名無しさん：2007/09/26(水) 00:58:42

>>658
年金はデータだろw

>>659
SQLを何度も発行するのがいやで一本化してるんでないの？
ひとつの処理でテーブル１０～２０使うのはざらにあるし。

728 ：デフォルトの名無しさん：2007/09/26(水) 01:00:26

Pro*COBOLはSQLが埋め込み式だから、SQLの可読性が高くていいね。
これに慣れてしまうと、VBやJavaでひたすらSQLを文字列結合している
汚らしい構文にはもう戻れない。

729 ：デフォルトの名無しさん：2007/09/26(水) 01:03:52

すぐ上に書き込みが来たので、ついでに

> SQLを何度も発行するのがいやで一本化してるんでないの？
DWHに限ってはそれは主目的ではないよ。
このスレにはDWHに詳しい方がいる（いた）ようなので私のような
半端モノは詳細説明を避けるけど、DWHのスレがあれば
そちらで聞いてみるのもいいでしょう。

730 ：デフォルトの名無しさん：2007/09/26(水) 01:04:40

>>723
COBOLで書くなら当然大文字だけどさ、
他の言語使うならその言語の一般的なルールに従おうよ

たまーに見かける小文字COBOLソース見ると、書いた奴殴りたくなるだろ？ｗ
そのまた逆も然り

731 ：デフォルトの名無しさん：2007/09/26(水) 01:20:08

それはいえる。変数の命名規約も然り。
だから、口座残高は、JavaではAccountBalance、
COBOLではKZ-ZNDKと書かねばならない。

732 ：デフォルトの名無しさん：2007/09/26(水) 02:37:47

！？
KZ-ZNDK読みやすい！！
講座ズンドコ

733 ：デフォルトの名無しさん：2007/09/26(水) 03:09:47

まあコボルがクソ言語で
コボラが死滅していく人種であることには
変わりはないんだけどな

734 ：デフォルトの名無しさん：2007/09/26(水) 06:00:19

大文字で書けるJavaって・・・
書けるだろ普通に

735 ：デフォルトの名無しさん：2007/09/26(水) 06:42:50

Javaは大文字でも出来るけど、特に意図がない限りは
そりゃAccountBalanceって記述すると思うが。

736 ：デフォルトの名無しさん：2007/09/26(水) 06:59:52

>>735
>>723

737 ：デフォルトの名無しさん：2007/09/26(水) 07:07:40

変数とかメソッド名とか漢字を使うと偉く見通しがよくなるけどね
但し、漢字未対応のツールを使うと地獄が待っているが

738 ：デフォルトの名無しさん：2007/09/26(水) 07:37:58

気分転換に質問です。
COBOLで書かれたシステムでは例えば、
摘要を構文解析して、意味を理解分類すると
いうようなコードはどのように書いているの
ですか。
それとも、汎く知られたソースのライブラリの
ようなものがあるのですか。

739 ：デフォルトの名無しさん：2007/09/26(水) 13:43:52

>>738
COBOLには可変長の文字列といった概念は
基本的に無いんだよ。わかったな。それだけだ。

740 ：デフォルトの名無しさん：2007/09/26(水) 21:49:25

基本的にない、だけだがな

741 ：デフォルトの名無しさん：2007/09/26(水) 22:27:15

マルチレコードレイアウトにやられ気味。
なんじゃこりゃあぁぁぁぁ！

けど、改ページを好きな所に入れられるのは超便利。

742 ：デフォルトの名無しさん：2007/09/28(金) 00:36:44

>>741
REDEFINES と / のことかな？

743 ：デフォルトの名無しさん：2007/09/28(金) 00:55:29

ある特定のカラムに特定の値があったらそのレコードはうんちゃらで、
なんちゃらの時はこんちゃらってのが、相当混乱しました。
キーなのに同じ値が複数あるし。もう慣れましたけど。

ワークスペースに複数の切り分けをした領域取ってやってましたけど、
REDEFINES使えば楽なんですかね？
やってみます。

改ページはAFTER PAGEの事でっす。

744 ：デフォルトの名無しさん：2007/09/28(金) 00:56:55

REDEFINESって概念は他の言語にあるのかね？

745 ：デフォルトの名無しさん：2007/09/28(金) 03:35:01

C言語に共用体ってデータ構造があるらしいけど
挫折したからよくわからないんだ…

746 ：デフォルトの名無しさん：2007/09/28(金) 11:02:11

C言語ならポインターと構造体でアクセスするだけだよ。何の不都合も無い

747 ：デフォルトの名無しさん：2007/09/28(金) 11:36:14

都合・不都合じゃなくって、REDEFINESって概念が他の言語にあるのか知りたいんだろ。

言語じゃなくて規約なら、COMがVARIANTという概念で、1つの変数にあらゆる属性の
値を入れることが出来た（主要言語はC++）。しかしこれはREDEFINESとは違うかな。

748 ：デフォルトの名無しさん：2007/09/28(金) 12:39:52

>>746
ポインタ設定するの面倒だろ。そのポインタ設定が漏れまくるから
高級言語じゃ使われないのに不都合無いって・・

REDEFINESはメモリ節約の産物だからもう必要ないだろ。

749 ：デフォルトの名無しさん：2007/09/28(金) 14:46:33

REDEFINESはCOBOLの中でも最もアセンブラ的な所だね。
REDEFINESと同様の概念がないとすると、アセンブラ的な
ものから遠ざかろうとしている言語がほとんどだから
ではないか。

750 ：デフォルトの名無しさん：2007/09/28(金) 15:51:22

>>733
まあＪＡＶＡがクソ言語で
ビジネスロジック専門自称ＪＡＶＡＰＧが死滅していく人種であることには
変わりはないんだけどな

751 ：デフォルトの名無しさん：2007/09/28(金) 16:23:57

>>748
I/Oポートを直接触る組み込みでは未だ必要な機能だよ、コボルと違ってビット単位でアクセスできるし
まあシーケンシャルファイルなんてデータコンバートプログラムでしか用は無いけどね

752 ：デフォルトの名無しさん：2007/09/28(金) 18:57:57

あー、昔X68000とかでスプライトレジスタに書き込みする時に
Cで構造体使っていたなぁ。

I/Oを叩く時は必要だと思うけど、COBOL的なデータ操作とかで
構造体やらREDEFINESを使ってどうこうとは今は思わんね。

753 ：デフォルトの名無しさん：2007/09/28(金) 19:34:32

STS分割する時に、なんでI/O定義書と違う定義を必要とするんだ？と思った。

754 ：デフォルトの名無しさん：2007/09/28(金) 20:08:09

>>748
つうかあんた構造体とかポインタって全く解って無いだろ。ポインタ設定が漏れるって何のことだよ
勉強してから一丁前のこと言ってね

755 ：デフォルトの名無しさん：2007/09/28(金) 20:17:28

ポインタ解決

756 ：デフォルトの名無しさん：2007/09/28(金) 22:25:28

>>754はポインタ使ったこと無いのねw

757 ：デフォルトの名無しさん：2007/09/28(金) 23:24:38

なぜCOBOLだとポインタは不要なのに
どうしてCではポインタが必須なのだろう。
俺の永遠の課題だ。

758 ：デフォルトの名無しさん：2007/09/28(金) 23:36:03

>>745
おれは C -> COBOLの順に勉強したんだけど、
REDEFINESを見たときに　「union(共用体) と一緒じゃん」って感想を持ったよ。

実際の使い方も似たようなものでしょ。
なんか「データ区分」みたいな項目があって使用する構造を決定する。
>>743
ちなみに、改ページはCでは'\f'フォームフィードでやったことがある。

C:構造体を関数にポインタで渡す
COBOL:構造体をサブルーチンに参照渡し
存外、共通点らしき部分が見受けられますな。

COBOLは「編集項目」が便利だと思ったな。

759 ：デフォルトの名無しさん：2007/09/29(土) 00:36:02

誰かOOCOBOLやったことある人いないの？

760 ：デフォルトの名無しさん：2007/09/29(土) 01:45:23

最近はフレームワークをベースにビジネスロジックしか記述できない

自称ＪＡＶＡＰＧだらけだな

「えっネットパッケージってなんですか？リフレックスＡＰＩ？？？」

おまえは無理しないでＣＯＢＯＬでもやってろＨＡＧＥといらだつよ

761 ：デフォルトの名無しさん：2007/09/29(土) 01:46:26

>>757
コボルの命令はＣの関数ライブラリにあたると考えれば
みなまで言わなくてもわかるだろ

762 ：デフォルトの名無しさん：2007/09/29(土) 07:39:28

COBOL歴10年最近5年間ブランクありの40歳のおっさんだけど、もう需要ないかな？
さすがにこの業界への再就職は厳しいかね？
他に資格とか無いし、警備員になるしかないのか。

763 ：デフォルトの名無しさん：2007/09/29(土) 08:46:49

>>762

金融関係ならあるはずだべ　by 45のｵｻｰﾝ

764 ：デフォルトの名無しさん：2007/09/29(土) 11:04:18

金融・保険関係はCOBOL需要いっぱいあるよ。
汎用機だけでなく最近はUNIX-COBOLも引く手数多。
後者は、UNIXの知識＆Oracleの知識必須ね。

ただ、金融・保険関係は、プログラマ歴よりも金融開発歴が
重視されるので、金融業務歴がないと厳しいかな。

765 ：デフォルトの名無しさん：2007/09/29(土) 11:20:34

>>763 >>764
ありがとう！
金融＆UNIX＆Oracleの知識はないけど頑張ってみます。

766 ：762＝765：2007/09/29(土) 11:22:35

>>762＝>>765です。

767 ：デフォルトの名無しさん：2007/09/29(土) 11:22:57

いっそのこと運用オペレータという選択肢もあるぞｗ

768 ：762＝765：2007/09/29(土) 11:32:10

>>767
あっても20万ぐらいだろうな。スキルも付かないし。
まあ、どっちにしても10年間頑張ってスキルを磨いても50歳。
そうなると転職は99.99・・・％無理、リストラされておしまいか。
お先真っ暗な人生しか見えない今日この頃・・・

769 ：デフォルトの名無しさん：2007/09/29(土) 21:01:48

>>762
その年で底辺のプログラマーを目指す理由が正直わからんが。
COBOL歴は正直なんの役にも立たん。

漏れの知っている部署だと「知らなくてもすぐに覚えられるから」とか言う理由で
素人でも即プログラマーには慣れる。が、壊れるまでコキつかわれる率80%って感じだ。

まあ、壊れる壊れないは本人の資質が大きいのでデスマの経験を
とくとくと語れば採用されるかも。

770 ：デフォルトの名無しさん：2007/09/30(日) 05:48:17

「Javaによる知能プログラミング入門」という本があり、
探索とパターン照合それからルールベースなどという章が
切られている。
Javaで書かれたPrologは多い。Prologに関して言うと最初のPrologは
1972年にマルセイユ大に於いてFORTRANで記述された。
それで、COBOLによって書かれたPrologはないかとググッてみても、
それらしきものは出てこない。1980年代には汎用機上のProlog処理系は
結構あったはずだけれどアセンブラで書かれていたのだろうか。

771 ：デフォルトの名無しさん：2007/09/30(日) 08:14:11

普通にアセンブラかＣなんじゃねーのか？
ＣがＣで書かれたってのはある意味神業な気がするが。

とりあえずCOBOLはCOBOLで出来てないだろ。

772 ：デフォルトの名無しさん：2007/09/30(日) 10:50:23

FORTRAN->Cへの書き換えは早いが、COBOL->Cの書き換えは遅い。
構文とか、商用に使いやすいとか、あまり関係ないんじゃないの？

773 ：デフォルトの名無しさん：2007/09/30(日) 12:40:11

>>771
最初のC言語はB言語で書かれたんだよ。直ぐにC言語で書き直されたんだが

774 ：デフォルトの名無しさん：2007/09/30(日) 13:44:16

むうー
CをCで書くことに何の意味があるのだろうか。
この辺は理系の知識がいるな。

775 ：デフォルトの名無しさん：2007/09/30(日) 16:01:22

>>762
あるとおもうよ
こんなのもあるから

株式外会社ＣＯＢＯＬ
http://www.cobol.co.jp/

776 ：wolf ◆8VH3XAqjlU ：2007/09/30(日) 18:06:04

>>774
たとえば皆さんのプログラムで正常処理とエラー処理の比率はどれくらいですか？
どんな言語のコンパイラーでもただ動くだけ部分以外エラー処理とか最適化とか結構バカになりません
それでAssemblerではやっていられないという事です

777 ：デフォルトの名無しさん：2007/09/30(日) 22:58:29

＞最初のC言語はB言語で書かれたんだよ。直ぐにC言語で書き直されたんだが

確かにＢ言語を改良した言語がＣ言語ではあるが、最初のＣはＢでは出来てないらしい。
ＣはＣで書かれたとの事。

778 ：デフォルトの名無しさん：2007/09/30(日) 23:26:06

でも一番最初のCはアセンブラで書かれたんだよな？
頼むそう言ってくれ！
言ってくれないと俺の頭が爆発する。

779 ：デフォルトの名無しさん：2007/09/30(日) 23:50:26

Cが何でかかれたか、なんてスレ違いだよな！
頼むそう言ってくれ！
言ってくれないとCOBOLerがCスレに乱入する。

780 ：デフォルトの名無しさん：2007/10/01(月) 01:05:03

実は全てのプログラミングの言語ってＣ言語の派生なんだよ。

781 ：デフォルトの名無しさん：2007/10/01(月) 13:43:24

マクロアセンブラの代わりにCを使って
書かれた言語が多いことは確かだが。

782 ：デフォルトの名無しさん：2007/10/01(月) 15:08:46

>>781
Cが台頭するまではPL/MみたいなPL/Iのサブセットを使ったものが殆どだったが。

783 ：デフォルトの名無しさん：2007/10/02(火) 17:57:50

COBOLはいいけど
TSSがウンコ

TSOの勝ち

784 ：デフォルトの名無しさん：2007/10/04(木) 04:26:56

>>783 >TSOの勝ち
それで何をするの?

785 ：デフォルトの名無しさん：2007/10/04(木) 16:17:38

現在、小売業の社内コボちゃんしていますが、
近々、転職を余儀なくされそうです。

金融関係は、キツイと言われていますが、実際のところ、どうなんでしょうか？
（金融システムの経験は全くありません）

786 ：デフォルトの名無しさん：2007/10/04(木) 18:20:24

経験無いなら来ないでくれ、頼む。

787 ：785：2007/10/04(木) 19:16:21

>786

詳しく説明してくれたら、いきません。

788 ：デフォルトの名無しさん：2007/10/04(木) 22:44:57

金融システムの経験がないなら、まず門前払いだと思うが。

789 ：デフォルトの名無しさん：2007/10/04(木) 23:29:09

キツいっつーか、金融系だと強烈に前時代的な開発スタイルだから
それに耐えられるか？ってのもあると思うが。

ドキュメントは神（紙）って感じで・・・。

790 ：デフォルトの名無しさん：2007/10/05(金) 00:08:18

紙であるならまだいい。
古いシステムだと○○さんの頭の中だけってのも結構あるんだぜ。

791 ：デフォルトの名無しさん：2007/10/05(金) 00:24:10

COBOLの場合トップダインで開発が進むから紙のドキュメントでも大筋で概要は分かる。
仕様変更の網羅がしっかりできていれば（コードレニューがきちんと行われていれば）
紙のドキュメントでも十分役に立つよ。

RADとかプロトタイピングとかいって最初の仕様と全く違うこと行っているのにソースのコメント
がプロトタイプ版のままのモジュール（クラス）よりは絶対に役に立つ。

792 ：デフォルトの名無しさん：2007/10/05(金) 06:48:46

＞仕様変更の網羅がしっかりできていれば（コードレニューがきちんと行われていれば）
＞紙のドキュメントでも十分役に立つよ。

それが理想論なのは誰もが知っているワケで・・・。

＞RADとかプロトタイピングとかいって最初の仕様と全く違うこと行っているのにソースのコメント
＞がプロトタイプ版のままのモジュール（クラス）よりは絶対に役に立つ

コメントが難しいが、そう思うヤツの90%くらいはドキュメント信仰が強いだけの
能無しが言う台詞ではある。

オブジェクトにあるメソッドがブラックボックスでも大して困らない。
仮に言語がJavaだとしてJavadoc作ってあって、例外に関する仕様とdocが
あれば許せる。
catch(HogeException){}
なんて空の例外コーティングしてあると最悪と感じるが・・・。

まあ、漏れが現物志向ってのはあるな。
ドキュメントなんて大抵アレなケースが多いし。

793 ：785：2007/10/05(金) 09:11:05

>786 - 792

皆さん、貴重な御意見ありがとうございました。

取り敢えず、金融関係は、候補から外した方がよいみたいですね。

794 ：デフォルトの名無しさん：2007/10/10(水) 17:20:33

急に静かになったな・・・・

795 ：デフォルトの名無しさん：2007/10/11(木) 21:14:59

http://www.microfocus.co.jp/support/techtips/cobol_002.asp

COBOLってやっぱりすばらしい言語だね！　Cなんて足下にも及ばないよ！

796 ：デフォルトの名無しさん：2007/10/12(金) 00:00:56

>>795
そうCを責めるなよ。
そもそもCをOS記述以外に使うこと自体、
間違った使い方なんだから。
リッチーとカーニハンも、今のCの使われ方を
草葉の陰で嘆いていることだろう。

797 ：デフォルトの名無しさん：2007/10/12(金) 00:57:05

>795
あんたは、そんな宣伝文句を真に受けてどうする
コボラってほんまにアホや
デスマ土方で頭おかしいんちゃう

798 ：デフォルトの名無しさん：2007/10/12(金) 06:51:57

>>795
喪前がすばらしい脳ミソってのは解るな。

799 ：デフォルトの名無しさん：2007/10/12(金) 10:10:25

ま、コボルを端から毛嫌いするヤツに限って、決裁権も選定権もなにもない三下だから、世の中なにも変わらないよ。

800 ：デフォルトの名無しさん：2007/10/12(金) 18:16:59

日本信号のプログラマはCOBOLer?（笑）

801 ：デフォルトの名無しさん：2007/10/12(金) 21:49:05

他メーカーのやつやったことあるけどC言語だったな

802 ：デフォルトの名無しさん：2007/10/13(土) 00:28:03

>>801
他のメーカーのうまく動いたのはC言語、日本信号はCOBOLだったりして（笑）。

803 ：デフォルトの名無しさん：2007/10/13(土) 11:50:54

自動改札機のカード読み取り部分にプログラムミスだろう？
組み込みでCOBOLってのは聞いたことがないが。

804 ：デフォルトの名無しさん：2007/10/13(土) 16:21:44

組み込み機械にCOBOL、という発想が思い浮かぶ>>802ってすごいにゃあ。
業界人には及びもつかない柔軟かつ斬新な発想。。。

805 ：デフォルトの名無しさん：2007/10/13(土) 16:35:04

でもこれほど安定して動く言語もないから
実際に組み込んでみたら凄いと思う
なぜ組み込みに使われないのかは知らないけど

806 ：デフォルトの名無しさん：2007/10/13(土) 16:42:14

>>805
セマフォとインターラプトとマルチスレッドを勉強してみようね

807 ：デフォルトの名無しさん：2007/10/13(土) 18:38:35

安定して動くと言うか、あれだけ出来る事が少なくて
動く環境が限定されているんだから、そりゃ当たり前だと思うけど。

808 ：デフォルトの名無しさん：2007/10/13(土) 21:07:46

いや、そもそも事務処理を目的とした言語なのであって

809 ：デフォルトの名無しさん：2007/10/13(土) 21:42:45

>>808
もう何も言うな
恥かくだけだぞ

810 ：デフォルトの名無しさん：2007/10/13(土) 22:45:40

>>807
当たり前とか簡単に言うなよ。
実際に安定して動くという事実こそは
COBOL業界が長年努力して作り上げてきた
かけがえのないメリットなのだぞ。
銀行や保険のシステムが年中ぶっ飛んでいたら
世の中は回っていかんでしょーが。
COBOLとCOBOLerが社会に成してきた貢献は
計り知れない。

811 ：デフォルトの名無しさん：2007/10/14(日) 00:04:50

>>810
そもそも汎用機のOSやCOBOLはCOBOLで書かれていないんだが
つまり安定したCOBOL環境を作ってきたのはアセンブラやC言語のエンジニアなんだよ

812 ：デフォルトの名無しさん：2007/10/14(日) 00:23:47

なんでも最後はＣとアセンブラの２つに行き着くのかな。まあＣＯＢＯＬに限らず、と言ってもこぼらあは怒るのかなあ？

813 ：デフォルトの名無しさん：2007/10/14(日) 01:21:39

初期のCOBOLはアセンブラで、
今のCOBOLはCOBOLで書かれていると聞いた

814 ：デフォルトの名無しさん：2007/10/14(日) 02:56:03

おめえちょっとコボルでパーサ書いてみろや

815 ：デフォルトの名無しさん：2007/10/14(日) 07:42:19

＞実際に安定して動くという事実こそは
＞COBOL業界が長年努力して作り上げてきた
＞かけがえのないメリットなのだぞ。

COBOLの連中が努力しているのではなく、
汎用機を扱うメーカー(つか実質IBM)が金にモノを言わせて
独占市場となり、それの推奨言語がCOBOLだったって話なだけ
な希ガス。
#RPGもあったか。

つか、今の汎用機のカーネルってアセンブラ＋C++だし。

816 ：デフォルトの名無しさん：2007/10/14(日) 12:50:24

自動改札機、サーバーと切り離したら、起動したんだろ？　問題はサーバーにあり、
と思ったのだが。

817 ：デフォルトの名無しさん：2007/10/14(日) 14:29:46

COBOLってもう減価償却期間をとうに過ぎた言語だと思う今日このごろ

818 ：デフォルトの名無しさん：2007/10/14(日) 15:35:55

COBOLは事務計算用のフレームワークだと思えばいい。
何で書かれてるかはあまり重要ではない。

819 ：wolf ◆8VH3XAqjlU ：2007/10/14(日) 21:34:36

>>816
当然山勘ですが
サーバーと切り離すと自主運転モードになって前日分のネガ・データで稼動したんじゃないかな？

820 ：wolf ◆8VH3XAqjlU ：2007/10/14(日) 21:37:44

>>819
あっゴメン
改札機開放したってニュースだから前日分を持っていなかったかな

821 ：デフォルトの名無しさん：2007/10/14(日) 22:15:40

>>816
それだけの情報じゃどちらが悪いか判断つかないよ。サーバーからのコマンドの順序や
タイミングによるものかもしれない。その場合は端末が悪いことも考えられる

822 ：デフォルトの名無しさん：2007/10/15(月) 10:03:52

>>817
>799

823 ：デフォルトの名無しさん：2007/10/15(月) 16:21:56

>>821
どうも、メーカー毎にサーバーが違っていたようだが。だから日本信号の改札機だけが
止まったらしい。COBOLer作じゃないの？（笑）

824 ：デフォルトの名無しさん：2007/10/15(月) 16:30:56

>>823
おもしろくないのが、なんで一度で理解できない？
まさか、おま・・
現実逃避してないで首でもくくったらどうだ？

825 ：デフォルトの名無しさん：2007/10/16(火) 00:35:32

↑自分ワールドで何舞い上がってるんだろ

826 ：デフォルトの名無しさん：2007/10/19(金) 16:05:31

COBOLって、汎用？（笑）

827 ：デフォルトの名無しさん：2007/10/19(金) 17:18:58

うん。

828 ：デフォルトの名無しさん：2007/10/19(金) 22:22:25

事務系　○
技術計算×
制御系　×
web系 ×
Winowsアプリ　×

汎用？

829 ：デフォルトの名無しさん：2007/10/20(土) 00:21:10

うん。

830 ：デフォルトの名無しさん：2007/10/20(土) 18:33:17

凡庸？

831 ：デフォルトの名無しさん：2007/10/20(土) 19:33:11

朋友？

832 ：デフォルトの名無しさん：2007/10/22(月) 15:58:53

三菱東京UFJのシステム、東京三菱のシステムを残して、UFJのシステムはゆうちょ銀行に
売却するそうだ。こういうのって談合なんだろうなぁ。

833 ：デフォルトの名無しさん：2007/10/22(月) 16:01:03

>>828
COBOLほど汎用を唱って、特殊な用途に使われている言語も少ないよ。
LISPとかPrologみたいな感じ。

834 ：デフォルトの名無しさん：2007/10/24(水) 00:19:19

金融系で開発＆保守のSEやってますが、大手なせいで、
メインフレームのCOBOLもあれば、ダウンサイジングの中で作った
C、Java、VB、Perlなんかのシステムもたっぷりあります。
（TSSでCOBOLプログラム書いてメインフレームからデータ
　引っ張りだして、細かいところはPerlとかJavaで加工して
　客に提出、なんて業務もしょっちゅう。）

でもこんな特殊な環境で開発してきたせいで、ソフトウェア工学が
進歩してきた道のりを体感してます。

あんま、特定の言語に固執するのは意味がないんじゃないですかね。

ただ、COBOL＆メインフレーム知ってると出世が速いのは
あるかもしれません。COBOL世代のお偉方にJAVAをCOBOLに
翻訳して説明できるんで。

835 ：デフォルトの名無しさん：2007/10/24(水) 06:31:52

＞ただ、COBOL＆メインフレーム知ってると出世が速いのは
漏れの知っている金融系はまったくの逆だな。
１０年以上マをやらされているヤツがほとんどだ。

836 ：デフォルトの名無しさん：2007/10/24(水) 11:24:50

>>832
東京三菱とUFJのシステムってIBMと日立の違いだと思うのだけれど、開発言語は同じなの？

837 ：デフォルトの名無しさん：2007/10/24(水) 16:10:00

>>836
日立A-cosだよなIBMとちょとちがう

838 ：デフォルトの名無しさん：2007/10/24(水) 16:21:27

>>837
ACOS...国策的OSだなぁ。

839 ：デフォルトの名無しさん：2007/10/24(水) 18:18:41

ACOSはNECだ

840 ：デフォルトの名無しさん：2007/10/24(水) 20:57:46

COBOLなんて今後ニーズあるんですかね？

841 ：デフォルトの名無しさん：2007/10/24(水) 21:52:08

金融系だけど、ほとんどEASYとJCLばかり触ってる。

842 ：デフォルトの名無しさん：2007/10/24(水) 21:56:57

>>834
金融系でもフロントはそんな感じだよね
色々経験できるのはいいけどバックの事とか全然わからないんじゃ？
というか、俺がそうなんだけどｗ

843 ：デフォルトの名無しさん：2007/10/24(水) 22:09:44

COBOLの記述について、教えてください。

ORACLEテストテーブル

OLACLE-KOUMOKU VARCHAR2 300バイト
※中身は動的SQLが入っております。

これを、COBOLの画面表示するために

01 WK-KOUMOKU.
03 WK-KOUMOKU-A PIC X(60)
03 WK-KOUMOKU-B PIC X(60)
03 WK-KOUMOKU-C PIC X(60)
03 FILLER PIC X(120) 切捨て用
--------------------------------------
MOVE OLACLE-KOUMOKU TO WK-KOUMOKU
--------------------------------------
DISPLAY WK-KOUMOKU-A
DISPLAY WK-KOUMOKU-B
DISPLAY WK-KOUMOKU-C
--------------------------------------

この場合、どうしてもWK-KOUMOKU-Aの
一番最初に変な文字が表示されます。

どうすればよいのでしょうか？
可変長だとなんかヘッダついてくるみたいですが
どのように除外できますか？

844 ：デフォルトの名無しさん：2007/10/25(木) 02:07:08

>>843
Pro*COBOL? たしか、
WK-KOUMOKU-Aを可変長文字列にする宣言が必要なんじゃないか?
それをすると、
WK-KOUMOKU-A-LEN と　WK-KOUMOKU-A-VAR （だったかな？）という二つの変数名が出来るんだったような...

845 ：デフォルトの名無しさん：2007/10/25(木) 07:54:36

>>844
ありがとうございます。
さっそく、試してみます。
本当にありがとうございます。

846 ：デフォルトの名無しさん：2007/10/27(土) 18:46:16

コボルで汎用的なCSV変換のPGMを作成したいのですが
どういうPGMを作成すれば実現できるか思いつきません。
INPUT①をCSV化したい固定長ファイル
INPUT②にCOBOLのCOPY句(OCCURS項目がある場合は少し加工が必要？)を指定して
OUTPUTにCOPY句に合わせた
CSVファイルが出力されるようなPGMが理想です。

STRINGとかUNSTRINGを駆使すれば出来そうかなくらいの
想像しか出来ません。
低脳ですいませんがアドバイスあれば宜しくお願いします。

847 ：デフォルトの名無しさん：2007/10/27(土) 21:59:32

>>846
ttp://homepage2.nifty.com/pu-relaxroom/pro/pro-cob3.htm
を参考にしたら。

848 ：wolf ◆8VH3XAqjlU ：2007/10/28(日) 15:31:35

>>846
コンパイラーで　REFERENCE MODIFICATION　が使えれば「4.部分参照の表記方法」を参考に

サルでもわかるＣＯＢＯＬ入門【ひよこグミ】
http://www16.plala.or.jp/hiyokogumi/3/310.html#a4

849 ：デフォルトの名無しさん：2007/10/29(月) 12:06:12

>>846
そういう用途にCOBOLは使わないほうがいい

850 ：デフォルトの名無しさん：2007/10/31(水) 14:07:48

ＣＯＢＯＬ経験者急募

851 ：デフォルトの名無しさん：2007/11/01(木) 09:33:36

>850

業種とかは？

852 ：デフォルトの名無しさん：2007/11/01(木) 21:50:29

>850

どの板＆スレで？

853 ：デフォルトの名無しさん：2007/11/01(木) 23:59:10

基本的な事で申し訳ないですが・・・。

COBOLのASSIGN TO hogehoge
となっていた場合、JCLからならhogehogeに対応するファイルを
指定して読み込ませますよね？

MFCOBOL＠AIXで動かしたいのですが、
hogehogeにファイルを関連付けるのってどうやるのでしょうか？
dd_hogehoge = path.to.file
export dd_hogehoge
で合ってます？

やってみればよいのですが、しばらく実機にさわれないので、
よろしければどなたか経験者の方ご教授ください。

854 ：デフォルトの名無しさん：2007/11/02(金) 12:53:53

正直、ＣＯＢＯＬってもうだめなの？
現役コボラーの方どうですかね？

855 ：デフォルトの名無しさん：2007/11/02(金) 20:33:54

これから新しい分野でどんどん使われるとはさすがに思わない。
けど、廃れることだけは絶対にない。　と思う。 w

856 ：デフォルトの名無しさん：2007/11/02(金) 21:35:39

絶滅はしないだろうけど、COBOLやってるヤツはある意味
鬱病患者のように「新しい仕事がやりたい」と漏らしている。
しかし実際に新しい仕事をやることはほとんどない。
１０年以上前のシステムを延々と保守し続けるだけ。

857 ：デフォルトの名無しさん：2007/11/02(金) 22:43:03

>>853
そういえば、ASSIGN TO　なんてあったねｗ
部品使ってるので、研修以来ASSIGN TO　なんか見たことない。。。

858 ：デフォルトの名無しさん：2007/11/02(金) 23:55:13

>>856
なかなか見所のある奴だねぇ
デスマ確定なシステム更改案件とかやってる会社に転職すればいい
常時人材を欲しているはずｗ

859 ：856：2007/11/03(土) 08:57:33

>>858
えーと、40～50代のCOBOLしか使えないし同じ部署で10年以上いる為、
世間一般の開発常識は一切ない、ある意味素人同然なんだが・・・。

正直、今リアルタイムでCOBOLの仕事している人って世間知らずのボンボンって
印象がぬぐえないのだが・・・。

Eclipse等のIDEは見たことも触った事もないし。

860 ：デフォルトの名無しさん：2007/11/03(土) 10:36:39

>>859
> 正直、今リアルタイムでCOBOLの仕事している人って世間知らずのボンボンって

それと開発と何の関係があるんだよ。
仕様通り納期を守ってシステムを作る、
それが開発者に科せられた唯一にして
最大の使命じゃないか。
他に何か資質を要求されるのかい？

861 ：デフォルトの名無しさん：2007/11/03(土) 11:14:02

その唯一にして最大の使命に、結構世間を知っているかどうかが
どーゆーわけか結構関わってくるんだな、これが。
開発って、残念ながらそこまでピュアに専門知識と専門技術だけで進むものではないからね。

862 ：856：2007/11/03(土) 14:40:23

>>860
世間を知らないと結構大変と言うか仕事できないに近いけど。

システム開発でコーダー＆テスターみたいな最底辺ならともかくとして、
「新しいシステムを作る」となると実運用やユーザー側から見た使い勝手
とか意識しながら、要件をまとめ、設計＆実装するワケだが、
COBOLって未だにTSO端末のグリーン画面で80x23なテキスト画面設計して、
SNAでネットワーク&プリンタを構成して、システムバックアップはテープ命って
ノリだからなぁ。

システムなんにも知らないお客さんに対して「電文」とかの普通に喋るしサ。
もうちょっと普通の一般人に解る言葉で喋ってくれないと、辛いと思う。
SNAって単語自体普通のエンジニアだって知ってるか疑わしいし。

863 ：デフォルトの名無しさん：2007/11/03(土) 14:40:46

>861
あなたは結構世間を知っているんですね。
凄いね。

864 ：デフォルトの名無しさん：2007/11/03(土) 15:56:19

>>853
UNIX系の環境では、環境変数で結びつけるってやり方は多分一緒だと思うけど、
環境変数名は ASSIGN TO hogehoge なら環境変数名もhogehoge で良いと思うよ。
dd_hogehoge の dd_ をつける必要があるのかな・・？
（コンパイラの違いとかあるかもしれんけど）

865 ：デフォルトの名無しさん：2007/11/05(月) 10:31:04

>>862
MTはCOBOLだからとかそういう問題じゃないし、汎用機じゃなくてもMTは普通に使うだろ
Disk to Diskのみなんてのはバックアップと言えない
CMTは敷居が高いから少ないけどDAT、LTO程度は入れるべき

SNAはさすがにもう使っているところ少ないだろうね。でもすごく安定したプロトコルだった
Win2000まではSNAドライバを見かけたことあるけど、最近のOS用のはあるのかな？
もっとも、スイッチとかルータが対応してる機器が少なくなって来ちゃってるけど

866 ：856：2007/11/05(月) 19:03:02

>>865
汎用機じゃないとMTは使わんとｵﾓ。最近はかなり減ったと感じる。
何年か前は口座引き落としな全銀どーたらで使ってたりもしたけど、
電送(?)に変えてから業務なやりとりでMTは使わなくなった。
データのバックアップでDATやLTOは入れてる。
ただ未だにシステムのバックアップで1/4ｶｰﾄﾘｯｼﾞ(30GB)が普通と
COBOLerなエンジニアは主張してくる。ｴｪｰ

で、ウチの案件は未だにSNA全盛で色々とめんどくさい。
ちょっとプリンタの電源投入タイミングが悪いと手動でON/OFF
しないといけない。構成が悪いって言えば悪いんだろうけど。

とにかく運用コストが高い方法を好むのよ。汎用機&COBOLerなエンジニアは。

867 ：デフォルトの名無しさん：2007/11/05(月) 21:14:52

よ～く知ってるね
凄いねw

868 ：853：2007/11/05(月) 23:13:56

>>864
ありがとうごぜいやす。
今度試してみます！

869 ：デフォルトの名無しさん：2007/11/06(火) 09:10:10

バックアップはやはりCMTに限る。
ドライブ装置とメディアの信頼性が他とは圧倒的に違う。
DAT・DLT・LTOも使ってるけど、装置・メディアとも
しょっちゅう故障してて使い物にならん。

870 ：デフォルトの名無しさん：2007/11/06(火) 09:19:31

CMT無くなるって噂が・・・（製造終了）

871 ：デフォルトの名無しさん：2007/11/06(火) 11:11:20

>>866
だから、DATもLTOもMTだってば

CMTはドライブどころかメディアも丈夫だから
値段は高いけど、信頼性も高い
ウチ１０年位ワークテープとして使われている
CMTメディアあったよw

で、全銀どーたらって全銀手順のことでしょ？
それがEDI（電送）
EDIで送れるデータ量ならいいけど、到底無理な
場合も多々あって、そういう場合はやっぱりCMT

通函じゃないけどある程度丈夫じゃないと、コスト
云々よりも確実なデータ流通が滞る

LTOはいくらか丈夫だけど、DATは使い捨てする
位の気持ちで使わないと泣きをみる

872 ：デフォルトの名無しさん：2007/11/06(火) 22:13:23

2chのしょっちゅう故障するってのはどーも微妙だったり。
ウチはCMTが一番トラブル多い、理由は「エンジニアが丈夫だからと過信してミスをする」ケース。（w
LTOは問題なし、DATは最初から１年交換ってノリで運用している。

まあテープ関連の業務は正・副作成して作業しているから
多少壊れてもいーや、感はある。

今の電送は県民単位で処理可能なデータ量なんで、漏れの地方では使わんな。
仮に電送が止まったらテープで運送って対策しているから、最初から
「やっぱりテープが安心」ってやり方はしてない。最終手段として捕らえている。
ただ東京都とかが回線が胡散臭くて安定して送れない状況と言うならそうなのかもしれん。
田舎モノでｽﾏｿ。

あとテープ装置を漏れがあんまし推奨しない理由は運用のおばちゃん(とは限らんが)に
高価なデッキを触らすに抵抗がある。

人間は間違えるﾅﾏﾓﾉって印象があるからな。

873 ：デフォルトの名無しさん：2007/11/07(水) 09:02:37

今でもオープンリールＭＴで「シュコー…キュルキュルキュル」と普通にＩＮ-ＯＵＴ
テープ折れ曲がったら其処をハサミでチョッキン!! ほらまだ使えんじゃね～か
しかしハード保守契約は切れてて綱渡り　
なのにＣＯＢＯＬは今日も安定
バッチジョブをチョチョイっといじってコンパイル
あれ落ちちゃった??　コンソールの赤い文字が小憎らしいじぇ
かな入力モードはデフォ
俺の通り過ぎたＰＣから若造たちの「げっカナモード」の悲鳴が心地いい

それから
マッチングの前には必ずレコードクリアをするんだ、うんこしたらお尻拭くのと一緒だ
MOVE　SPACEだ

けどマシン室ドアの暗証番号を入れ間違い「あ、あれっ」とすんなり一回で入れない

コボラーとはそんな漢の世界

874 ：デフォルトの名無しさん：2007/11/07(水) 21:58:58

>>873
>マッチングの前に～うんこしたらお尻拭く
どちらかというと、「トイレで座る前に便座を拭く」とかの方が良くない？
ときどき水滴が...

875 ：デフォルトの名無しさん：2007/11/07(水) 22:03:14

確かにウンコする前に尻拭いてるって事になるね
した後は当然拭いてないんだろうなぁ

んで保守契約ぐらいしとけｗ
壊れたらどーすんだ

876 ：デフォルトの名無しさん：2007/11/08(木) 16:59:16

>>875
>壊れたらどーすんだ
メインの媒体はCMTだからｗ

MTはおぢちゃんたちが「過去のデータ資産を～」って言って残したの（実際はCMTに全部COPYしてるけどね）
ほら"007"(ショーンコネリーのね)とか、仮面ライダーのショッカー基地とか…
悪の秘密結社でMTがくるくる回っているが心にのこってるのよｗ
「あれがコンピューターだ」ってね

結局…CMTとかDATには『萌え』がないんだよw　これっって賛同者多いと思うけどなｗｗ

あ～ちなみに８インチフロッピーもご健在　髪の毛挟まっていようが、綿埃ついていようが
「ガッチン、ガッチン」読込むあのタフさが『萌え』ｗｗ

877 ：デフォルトの名無しさん：2007/11/08(木) 22:35:38

つーか今でもMTのメディアや機器作ってる会社あるのか？

878 ：デフォルトの名無しさん：2007/11/09(金) 08:23:23

>>856
その古いシステムを延々と保守し続ける事が
仕事になるって、ある意味幸せな事だけど…。
１０年後もおそらくそれで飯食えるわけだろ？

他の環境なんて、ライブラリやら刷新されて
一から覚え直してプログラミング　なんてザラでっせ。
（昨今のWeb系もC++だけじゃどうにもならんからね）

879 ：デフォルトの名無しさん：2007/11/10(土) 04:53:54

＞仕事になるって、ある意味幸せな事だけど…。
＞１０年後もおそらくそれで飯食えるわけだろ？

死なない程度の給料でな。

＞他の環境なんて、ライブラリやら刷新されて
＞一から覚え直してプログラミング　なんてザラでっせ。

どこのザラか知らんが、技術職なんかは常に勉強するのが
ある意味、普通なんだが。

オブジェクト指向な言語(JavaやC#)の初歩すら理解できん
低脳は存在するから、それはそれで仕方ないが、
自分が理解できないからって上記な理由で身の保身に
走って他者の脚を引っ張るマネするからCOBOLerは
他のエンジニアからバカにされる率が圧倒的に高いんだとｵﾓ。

880 ：デフォルトの名無しさん：2007/11/10(土) 08:25:08

コボルの仕事で金を稼げるかどうかは会社次第なんじゃねぇの
金融子会社でもコボル使わない現場に送られたら・・・

それ以上に、システム会社自体がどれくらい寿命があることやら

881 ：デフォルトの名無しさん：2007/11/10(土) 08:58:42

>>879
おい言葉に気をつけろ。低脳とは何だ。
人をそんな風に言うもんじゃない。
オブジェクト指向は本来非常に特殊で難解な
概念で、ソフトウェア技術に適用することに疑問すら
提唱されているものなんだから、わからなくても
おかしくないんだよ。

882 ：デフォルトの名無しさん：2007/11/10(土) 09:44:04

＞コボルの仕事で金を稼げるかどうかは会社次第なんじゃねぇの

会社が儲かるのと個人の報酬は別物だけどなー。
ああ、でも単純なﾌﾟﾛｸﾞﾗﾏｰ単価だと不思議とCOBOLはちょい高いよな。

883 ：デフォルトの名無しさん：2007/11/10(土) 09:56:18

>>879
JavaやCができたって所詮デジタル土方じゃないか。

884 ：デフォルトの名無しさん：2007/11/10(土) 10:02:13

オブジェクト指向なんて、別にできたからどうっていうほどの
特殊な思考でもないけどなあ。
そういえばOOCOBOLってやっぱり誰も使ってないの？
俺もOOCOBOLでCOM作って遊んだ程度の経験しかないけどさ。

885 ：デフォルトの名無しさん：2007/11/10(土) 10:21:15

オブジェクト指向はたいしたことなくもないが、
現実問題ユニットテストつーか、単体テストで
ファイルの結果をなんでもかんでも16進数のダンプ形式で
プリンタに印刷して、鉛筆と定規で縦線引いて、
マーカーで色つけて、って手間ばかりかかるテスト手法を
強制するのがCOBOLerだなー、って感はある。

オブジェクト指向と言うよりかは、現代の開発スタイルから
あからさまに取り残されている感がウチの周りではある。

もうちょっと本質的かつ効率的なテストしてほしい。

JavaのxxUnitみたいなユニットテスト→リファクタって概念ないんで、
システムが年々グダグダになっていく。

まあ、Javaでもグダグダになっていくけどサ。

886 ：デフォルトの名無しさん：2007/11/10(土) 14:02:11

>>885
COBOLが駄目な一番の理由はリファクタ出来ない事だよねぇ

現行の仕様を誰も理解してないから、
デグレードが怖くて影響の少なそうな部分を強引に直す
んで更にシステムがグダグダになっていく

まさに負のスパイラル

887 ：デフォルトの名無しさん：2007/11/10(土) 17:44:25

月9ドラマ「ガリレオ」最終回、COBOLる（おわる）

888 ：デフォルトの名無しさん：2007/11/10(土) 17:49:10

>>886
考古学的プログラム分析ツール
　仕様書のないCOBOLプログラムを分析ツールにかけて、GUIで、シーマンプログラマが一杯飲みながら
愚痴りながら仕様を解説してくれる

889 ：デフォルトの名無しさん：2007/11/11(日) 04:34:58

デー子で働いてる人いたら業務内容ｋｗｓｋ

890 ：デフォルトの名無しさん：2007/11/11(日) 04:51:22

COBOLのコーダーになりたい
http://pc11.2ch.net/test/read.cgi/prog/1194723581/

891 ：デフォルトの名無しさん：2007/11/11(日) 09:43:13

>>890
COBOLだけ学んでもJCL学ばないと意味ないぞ

892 ：デフォルトの名無しさん：2007/11/11(日) 19:30:12

言語の難易度として COBOLってどれぐらい？

自分は全く触ったことないけど、印象的には
SQLぐらいかとか、何の根拠もなく思ってるん
だけどどんなもんだろ。　もっと難しい？

難易度の尺度としては、同じ人物が、
簡単なアプリ組めるようになる日数で。
（SQLはアプリ内で要求通りの表作り）

893 ：デフォルトの名無しさん：2007/11/11(日) 19:51:47

バッチ系のファイル更新のみで、同じ人物だとしたら
生産性はSQLが10分とすればCOBOLは３・４時間くらいだろうな。

ただ、現実的にCOBOLerはSQLを覚えない、もしくは
超絶初心者レベル(SELECT * FROM HOGE程度)が
99%くらいなので、こういう比較は意味ないとｵﾓ。

あと、SQLでは画面遷移やらプリンター印刷やらの処理は出来ない（に近い）ので
SQL使いは他の言語(JavaやらCやらRubyやら)を覚えなければならないが、
COBOLはそれだけで一通りのアプリが出来なくもないのでSQLとは比較にならないとｵﾓ。

言語の難易度としては気軽に学習とは言いがたいのでそういう意味では高いが
言語仕様的には中レベルじゃね。

894 ：デフォルトの名無しさん：2007/11/12(月) 00:02:38

SQLでどうやってファイル更新するんだろ

895 ：デフォルトの名無しさん：2007/11/12(月) 06:39:36

COBOLerのカキコは相変わらず釣りかマジレスか解らんな・・・

896 ：デフォルトの名無しさん：2007/11/12(月) 21:50:02

>>893
今Accessを勉強しているけど、やはり難しいと思う。
複数のクエリが同時に連動して動く。
これではどこかでクエリを止めて出力を検証するなどの
デバッグ手法が使えないし、項目の追加変更が出た時に
どこを直すべきかわからなくなる。
やはりコボルで地道にバッチシステムを構築するのが
一番だと思った。

897 ：デフォルトの名無しさん：2007/11/13(火) 00:00:55

今いる部署で言語コンバートをしているのだが、
「ＣＯＢＯＬは保守要員がいないのでＡＳＭにして下さい」
泣いてＣＯＢＯＬにしてもらいました。ASMｸﾒﾈ.orz
かと思えば、
よそのシステム管理部からＣＯＢＯＬプログラムの修正が飛んでくるし。

>896
後々を考えると、ＶＢＡ＋ＳＱＬで組むのが応用が出来ると思います。

898 ：デフォルトの名無しさん：2007/11/13(火) 01:03:22

そういえばWinでバッチなシステムを見たことが無い
小規模なシステムならUNIX使うより運用が楽そうで良さそうなんだが

899 ：デフォルトの名無しさん：2007/11/13(火) 06:47:44

>>896
Accessにナニを求めているか知らんが、
ｶｷｺを読む限りはCOBOLの延長でモノを考えているから
泥沼にハマるだけなのでは・・・。

そして、地道なバッチシステムほどメンテしにくいモノはない。

RDB設計の基本の「one fact in one place（1つの事実は1カ所で管理する）」
が出来ていない人間ほど、そういう複雑怪奇な物事の考え方をする。

900 ：デフォルトの名無しさん：2007/11/13(火) 09:00:14

>>896
複数のクエリが同時に連動して動く　って？

できないことはないでしょ、みんなやってんだから。
アクセスは組んだことないけど、Winアプリは、
DOSプログラムの様な１本道の処理ではなく、
いわば全て割り込みを引き金にして動くからね。

これはオブジェクト指向とも相性がいい。

901 ：デフォルトの名無しさん：2007/11/13(火) 10:50:03

>>893
COBOLの仕様も随分と拡張されたものだが、
それでも"やさしい部類"に入るのではないか。
役に立っていない予約語が無闇と多いが。

902 ：デフォルトの名無しさん：2007/11/13(火) 12:43:19

Cみたいなバイナリベースの型しか頭に無かった俺は
高校でCOBOLやらされてPICを理解するのに数日苦しんだw
桁ベースなんだよな、あれって…

903 ：デフォルトの名無しさん：2007/11/13(火) 16:54:52

C畑にとっちゃCOMPも理解に苦しむな
なんなんだよ、あれ・・・

904 ：デフォルトの名無しさん：2007/11/13(火) 21:28:35

>>900
> 複数のクエリが同時に連動して動く　って？

例えばクエリＡの出力をクエリＢの入力に指定して…
という風にどんどんつなげていくと、
クエリＺを実行しただけでクエリＡからＺまで
ぷよぷよの大連鎖みたいにダダーって動く。
これは恐ろしい。下手に動かすとシステムを壊してしまう。
全クエリの相関図を書かないと手を出せない。
その点コボルは一つ一つがロードモジュールとして
明確に独立しているから、非常に扱いやすい。

905 ：デフォルトの名無しさん：2007/11/13(火) 22:23:22

>>904
もしかしてSQLの実行に非同期コマンドの DoCmd.RunSQL 使ってないか？

だったらAccessで（というかVBAで）初心者が必ず犯す失敗のひとつ。
同期コマンドの CurrentDb.Execute 使ってみれ。

906 ：デフォルトの名無しさん：2007/11/13(火) 22:33:04

>例えばクエリＡの出力をクエリＢの入力に指定して…
>という風にどんどんつなげていくと、

COBOLerが好みそうな糞設計の典型だな。

907 ：デフォルトの名無しさん：2007/11/14(水) 00:06:27

ばよえ～～ん

908 ：デフォルトの名無しさん：2007/11/14(水) 11:43:02

>>906
動かした順番を間違ったときオペレーターが悪いって言い張るアレのことかな

909 ：デフォルトの名無しさん：2007/11/14(水) 13:43:28

>>906
おまえ知らなかっただろw

910 ：デフォルトの名無しさん：2007/11/14(水) 22:22:37

基本的にCOBOLerってシステム設計で基本の「結合度は低く、凝縮度は高く」を
真逆に実装するクセがあるよな。

そのクセ「その点コボルは一つ一つがロードモジュールとして
明確に独立しているから、非常に扱いやすい。」とか勘違いして、
途中のモジュールがコケると後続やら関連JOBが停止して、
あれこれとオペレータが泣かされる。w

普通の設計でクエリの出力をつなげるなんてヴァカ設計しねーっての。

911 ：デフォルトの名無しさん：2007/11/14(水) 23:16:40

>>910
>途中のモジュールがコケると後続やら関連JOBが停止して、
当たり前じゃないのか？
重要なのは対処して、再実行だけで業務続行が出来るように
設計されていること。

PCなんかじゃ、編集中のファイルがぶっ壊れて
修復不能ってのが当然なんだろ。

912 ：デフォルトの名無しさん：2007/11/14(水) 23:26:46

>PCなんかじゃ、編集中のファイルがぶっ壊れて
>修復不能ってのが当然なんだろ。

釣りがマジレスか知らんがこの認識が正にCOBOLerの真骨頂だと思う。

913 ：デフォルトの名無しさん：2007/11/14(水) 23:30:58

＞重要なのは対処して、再実行だけで業務続行が出来るように
＞設計されていること。

現実的に、１０年以上前のシステムをリファクタ無しでCOBOLerが
メンテし続けた、複雑怪奇な状態で「再実行だけで動く」なんてのは
かなり稀なケースであり、実際は「あそこのフラグを初期化してから実行」
とか「あのメニューの最初から順にやり直してください」ってケースが
ほとんどな点についてｗ

914 ：デフォルトの名無しさん：2007/11/14(水) 23:34:33

コボラはまずコボル以外の開発をやってから何か言った方がいい

915 ：デフォルトの名無しさん：2007/11/15(木) 00:16:12

COBOLしかやったことのない奴なんていねーよ
だいたいが複数言語のマルチリンガル

916 ：デフォルトの名無しさん：2007/11/15(木) 01:12:05

そうだなCOBOLer崩れがVBの糞設計を量産しているのはよく知っているよ
５００行を超える関数をコーディングしたりしてな

917 ：デフォルトの名無しさん：2007/11/15(木) 02:07:24

>>916
別に問題無いだろ。意味なくアホみたいに小さな関数大量に作られる
方が苦痛だ。呼び先見たら１行なんてざらだし。
開発量の水増しかよww

>>913
だってマジにやったらお金掛かって仕方ないしw

>>912
釣りはオマイだろ。MS-Wordのファイルなんか普通に保存して、
二度と開かなくなることが度々あったしな。
こんなレベルの製品で金が取れるのが不思議だ。

918 ：デフォルトの名無しさん：2007/11/15(木) 04:36:23

>>917
COBOLerってプログラムの構造化が何で必要かわかっていないんだ
５００所か１０００，２０００行の関数作って「俺は凄いんだ｣って自己満足してるしな
スコープって概念は一生理解できないだろうな
俺が知ってる1行の関数作っていた奴もCOBLer崩れだったんだけどね
１０００行ぐらいの関数から４，５回呼び出していたよ

919 ：デフォルトの名無しさん：2007/11/15(木) 06:03:37

>>910
> 普通の設計でクエリの出力をつなげるなんてヴァカ設計しねーっての。

んー俺が勉強不足なのかなあ。
クエリ一つでやれることは一つの処理だけだから、
複数工程のデータ加工を実現するには
JCLのステップみたいにクエリをつなげるしかないと思うんだけど。
で、一番最後のクエリを動かすマクロをAccessに登録して
運用者にはそのマクロを起動してもらう。
この手法でいろんなシステム組んじゃってるんだけど
マズイのかな。

920 ：デフォルトの名無しさん：2007/11/15(木) 06:50:01

＞釣りはオマイだろ。MS-Wordのファイルなんか普通に保存して、
＞二度と開かなくなることが度々あったしな。

Win3.1の時代のネタか故障しているPC＆鯖なんじゃねーのか。

今はまず壊れないし、自動保存＆作業中にハングしても元ファイルは壊れない
仕組みになっている。

障害率で言うならCOBOLerのシステムの方がよっぽどアベンド率が高い。

自らの保身の為に都市伝説を声高らかに語るなよ。アフォか。

921 ：デフォルトの名無しさん：2007/11/15(木) 07:27:52

>>919
コミットやロールバックは知ってる？

922 ：デフォルトの名無しさん：2007/11/15(木) 07:31:13

>>919
じゃ世の中のSQLを内包して動いてるシステムは壊れまくりっすね

923 ：デフォルトの名無しさん：2007/11/15(木) 09:22:59

>>921
コミット・ロールバックはAccessのマクロからでは使えないって知ってる？

>>920
この手法はまずいと思う。
VBAを使えばAccessでもコミット・ロールバックが使えるからそちらの
実装を考えてみては？

924 ：デフォルトの名無しさん：2007/11/15(木) 10:50:49

今北わけだが
このスレでコボラーと定義されているコボルしか扱えない人達
(恐らく2007年問題とか言われてる中で居なくなる人たちが主)
は確かに使い物にならないというか、未だにダム端しかなくても
困らない仕事しかできないのは事実だけど、コボル自体は悪い
言語じゃない。ここでコボルを卑下してるヤツってコボルを実戦
経験してないだろ。解釈がおかしすぎ。

コボルでも普通にSQL扱えるんだから、うまく利用できていない
ことがあれば、それはコボルの問題じゃなくて人の問題。

もっともくだらない小競り合いからVBAやら終にはワードの話に
なるんじゃ、ここでは肯定派にもいわゆる駄目な人が居るみたい
だけどさ。でも、>911の解釈は正しい。
>910は何してる人か知らないけど、エラーは情報を残しておいて
後で処理すれば済む場合と、その場で対処しないとユーザにも
迷惑かけることになる場合があるのはわかるよな？

925 ：デフォルトの名無しさん：2007/11/15(木) 13:37:06

コボルが悪い言語じゃないって良く聞くフレーズだけど、
どう考えたって言語として最悪だろ
それを認めない限り、一歩も前進しないぞ

926 ：デフォルトの名無しさん：2007/11/15(木) 13:46:57

>>925
だから最悪だってことを説明してみろよ
なーんも考えてないくせに「どう考えたって」とか放いてるなよ

927 ：デフォルトの名無しさん：2007/11/15(木) 14:03:07

最悪な点なんざ枚挙に暇がねえよ
俺的に一番気に入らないのは、抽象化が出来ないこと

928 ：デフォルトの名無しさん：2007/11/15(木) 14:52:42

>>920
Word使ったこと無いでしょ。Word2003でも余裕で
死ねるつーの。都市伝説？どこの田舎だよ。
これが現実だっつーの。

Word 文書が破損している場合のトラブルシューティング方法
http://support.microsoft.com/kb/826864/JA/

>概要
>文書ファイルが壊れていると、プログラムの動作に問題が発生する場合が
>あります。この現象は、ファイル内の情報に誤りがあることが原因で発生します。

>文書の破損による損害を防止する最も効果的な方法は、
>文書のバックアップコピーを作成しておくことです。

929 ：デフォルトの名無しさん：2007/11/15(木) 17:03:47

>>928
数千万のコンピュータで動くソフトと、お前の1台のコンピュータでしか動かさないソフトを比較して嬉しいの？

930 ：デフォルトの名無しさん：2007/11/15(木) 17:05:29

>>927
それを言うなら「枚挙に遑がねーよ」な

ゆとりな抽象的回答過ぎて何の抽象化だか判んねー
アセンブリじゃねーんだから、抽象化ぐらいできてるぞ
思考の抽象化もたいがいにしろよ

ま、クラスって考え方はコボルにはないけどな
仮にそれが一番の理由として、それで最悪？

少なくとも「俺的」根拠で最悪とは短絡思考もいいところ

931 ：デフォルトの名無しさん：2007/11/15(木) 17:08:16

コボちゃんご立腹の巻

932 ：デフォルトの名無しさん：2007/11/15(木) 18:23:03

COBOL で関数が作れたら良いなぁ。と思ったことはある。
(FORTRANを思い出しながら)

933 ：デフォルトの名無しさん：2007/11/15(木) 21:50:55

＞コボルでも普通にSQL扱えるんだから、うまく利用できていない

アレは普通とは言わないと思うし、そういう場合は普通にストアドにする。
そこまでして生産性の低いコボルをムリに使おうとは思わない。

934 ：デフォルトの名無しさん：2007/11/15(木) 22:07:29

>>930
COBOLってよく知らないんだが、クラスを伴わない抽象化って斬新だな
abstractやinterfaceを使わずどうやって抽象化するの？

935 ：デフォルトの名無しさん：2007/11/15(木) 22:36:49

930の世界ではアセンブラ以外の言語は全て抽象化が可能なんだろう。

936 ：デフォルトの名無しさん：2007/11/15(木) 23:23:01

このスレで抽象化とか意味不明なことしゃべるなよ。
COBOLは質実剛健・実用第一を旨とする漢の言語。
軽薄な機能なんて要らないのさ。
変数スコープや関数や小文字キーワードなんて
百害あって一利なし。バグの元になるだけ。

937 ：デフォルトの名無しさん：2007/11/15(木) 23:25:26

いや漢とか…

938 ：デフォルトの名無しさん：2007/11/15(木) 23:43:27

>>936
ただ、不器用で使いづらい言語なだけだろ

939 ：デフォルトの名無しさん：2007/11/15(木) 23:45:47

COBOLなんてSQLサーバへクエリー投げた結果を形整えて出力するだけでいいんだよ。
PL-SQLの上位みたいなポジション。

940 ：デフォルトの名無しさん：2007/11/15(木) 23:47:07

>変数スコープや関数

いや、これはイルダロ・・・

941 ：デフォルトの名無しさん：2007/11/15(木) 23:51:58

オブジェクト指向を覚えたての人間が混じっているな
interfaceだのabstructだのって。。。

942 ：デフォルトの名無しさん：2007/11/15(木) 23:53:45

COBOLってRDBすら使わないイメージがあるのだが。

943 ：デフォルトの名無しさん：2007/11/15(木) 23:56:02

RDB使わずにVSAMやらなにやらだけでやってるところは当然ある。

944 ：デフォルトの名無しさん：2007/11/15(木) 23:56:13

さすがにRDBは使うよ
ファイルの変わりに

945 ：デフォルトの名無しさん：2007/11/16(金) 00:01:16

>>936
N88-BASICかよ

946 ：デフォルトの名無しさん：2007/11/16(金) 00:28:43

しかしさCOBOLやっててファイル名がIN01やらIO01とか
TENBANはまだいいにしてもCA001→CA999,CB001→CB999とかな
カラム名でDB設計されてたらたまらん罠。

947 ：デフォルトの名無しさん：2007/11/16(金) 00:51:57

必要なら一覧表を参照すればいい。

948 ：デフォルトの名無しさん：2007/11/16(金) 01:30:03

>>944
レコードイメージをvarchar型とかに平気で突っ込んだりしてるのかな

949 ：デフォルトの名無しさん：2007/11/16(金) 01:46:14

俺、汎用機使ってCOBOLで処理しているんだけど、
COBOLってそんなに悪い言語かなあ？
この考えが時代遅れか？

例えば100万人分のバッチ処理をやったりする分には
まったく不自由して居ないんんだけど。

950 ：デフォルトの名無しさん：2007/11/16(金) 02:07:49

>>949
俺は、COBOLの表面くらいしか知らないし、言語にはそれぞれ
適した分野があると思う。用途さえ間違えなければ。
過不足ないということは大事。

そこをあえて質問してみたいのだけどさ、COBOL以外の言語の
この機能があれば、もっと便利なのに！って思うことは、
あります？

951 ：デフォルトの名無しさん：2007/11/16(金) 07:08:55

＞COBOLってそんなに悪い言語かなあ？
＞この考えが時代遅れか？

とりあえず現代においてはそんなにいい言語ではないな。

たとえばCOBOLで実現可能なバッチ処理なんかは
SQLで組めば1/10の期間で作成可能だし。

そして強烈な排他制御やらスレッドなプログラミングは
辛すぎる。つかそんなのCOBOLでやらんけどな。

100万人がどーとかはマシンパワーの問題なので言語は関係ない。

952 ：デフォルトの名無しさん：2007/11/16(金) 07:47:03

>>950
やはり、文字列の解析がし易くなるような、文法上の
基礎が欲しいですね。

953 ：デフォルトの名無しさん：2007/11/16(金) 11:32:39

>>949
地球シミュレータが廃止される、というニュースが報道されてたよね。
汎用機より、クラスタの時代じゃない？

954 ：デフォルトの名無しさん：2007/11/16(金) 11:38:12

>>934
>930はアセンブリを対照としてあげてるんだから命令というか制御の抽象化を書いているんだと思うよ。
>927がオブジェクト指向言語上の話をしているって前提がどこにもないから抽象化の語意が多岐にわたっちゃっていて、前提条件が無い状態では一概に抽象化といってもデータの抽象化のこととは限らないんだから思考まで抽象化するなってことでしょ。
>930の頑な過ぎのところはどうかと思うが、仕事を頼むなら手戻りがなさそうだから期間は短くなりそうだな。要件定義のワークショップはやたら長そうだけどw

それから、俺もCOBOLはすごくいいとは言わないけど悪い言語ではないと思うな。よく枯れていて安定してるし、最近の言語よりも英語ライクだからファイル読んで加工してファイル吐き出すとかの簡単なものならプログラムを知らない人でも読めるしね。
そこにある環境で求められているもの実現することがプログラム言語を扱う者の役割なんだから、過剰に言語をえり好みするのは自分のスキルに自信がないか向上心がないかだね。つまりはCOBOLerと同族ってこと。

955 ：デフォルトの名無しさん：2007/11/16(金) 16:44:41

やんわり口調でズバリ言ったwww

956 ：デフォルトの名無しさん：2007/11/16(金) 20:22:58

普通にCOBOLを評価するなら、極自然に悪い言語だとおもうけどな。
コレ悪くないと評価するならば、他の多くの言語は神レベルだし。w

英語ライクつっても、そのお陰でステップ数は他の言語に比べれば膨らむし
変数スコープの概念がアレなので、プログラムの見通しは悪い。
そしてCOPY句とかでソースがやたら分散してたりすると、ソースの解読が
かなりマンドクサイ。

別に昔から動いているシステムでそれの保守の仕事ならそれでいいけど、
新規案件でメインの開発COBOLとかヌカすアフォがいるからなぁ。

957 ：デフォルトの名無しさん：2007/11/16(金) 21:33:30

おれは、COBOLは「悪い言語」というと、少し表現がキツいと思うが、まぁ嫌いだな。
あまりにも、COBOLばかりやらされ過ぎて「嫌いにさせられた」のかも知れん。

>>956
普通に新規で使ってたぜ。
UNIX上で動いているOracleDBからWebブラウザに表示するデータを抜くのにCOBOL。
途中にJAVAが挟まってるんだけど、直接Oracleに触るのはCOBOL(Pro*COBOL)。

その方が速いからという理由だった。実測値を示された訳じゃないんだが、ほんとに変わるのかなぁ？
ほとんどデータを右から左に受け流すだけなんだけど。（一応、規定の電文形式とやらに整形してはいたけど）

958 ：デフォルトの名無しさん：2007/11/16(金) 21:43:04

それは、たぶん嘘w

一日に１回しか起動しないようなバッチ処理だとCOBOLと言うか
OSネイティブコードなアプリの方が速いだろうけど、
トランザクションがドカドカ走る状況になると、servletの方が速い。
と言うか商用のJavaのAP鯖だと、コネクションプーリングやら
キャッシュとかがRDBとの関連技術がｳﾏｰな感じで働くから。

後はEclipseの様なIDEとJavaやWeb関連の開発＆テストツールが
豊富なので、トータルコストで考えるとCOBOLをWeb関連で使うのは
ほとんどお勧めしない。

959 ：デフォルトの名無しさん：2007/11/16(金) 22:09:20

>>954
>よく枯れていて安定してる
この「安定」は、言語仕様が大幅に変わることはない。という事を言ってるのかな？
(作ったプログラムの安定はプログラマの問題だからな）
でもそれって、悪く言えば進歩がない。現状にアグラをかいている。COBOLerの体を表しているとも言える。
あるいはその言語には誰も期待していないことの現れカモ知れん。

せめて関数が自作できて（FORTRANの文関数みたいなのだけでも...）
　MOVE MYFUNC(ARG1, ARG2) TO A.
みたいな書き方が出来れば、使いやすくなるんだけドナ。

ここまで書いた所でググったらCOBOL2002では「利用者定義の関数機能」あるみたいねw

960 ：デフォルトの名無しさん：2007/11/16(金) 22:41:44

だからProCOBOL＋TPモニタ＋UNIXが最強だって
埋め込みSQL使ってProC以上の生産性と可読性
TPモニタに乗せればプーリングもキャッシュも自由自在
コンパイルすればシェアードライブラリになるから高速動作
J2EEで実現している機能でこの組み合わせで実現できていないものはないよ
だってそもそもAPサーバ自体TPモニタのJava版クローンなんだからサ

961 ：デフォルトの名無しさん：2007/11/16(金) 22:52:36

＞だってそもそもAPサーバ自体TPモニタのJava版クローンなんだからサ

釣りかマジレスか知らんが勘違いもここまでくると感動モノだな。

じゃあ、DB2だったらどうすんだヨ？って言ってみるテスト。

962 ：デフォルトの名無しさん：2007/11/16(金) 22:53:30

関数は嫌だなあ。
文と一体化してしまうから、ある意味言語仕様の
拡張をしてるみたいなもんだろ？
サブルーチンはサブルーチンらしく、PERFORMか
GOTOの配下に置くべきだと思うなあ。

963 ：デフォルトの名無しさん：2007/11/16(金) 23:21:55

APサーバがTPモニタの機能をそのまま実装しているのは
常識だと思うのだが。。。
コネクションプーリングやライブラリキャッシュなどの
機能は全部TPモニタの思想を受け継いでいるだけであって
APサーバ固有の機能ではないし。

だいたいAPサーバもTPモニタもミドルウエアの総称なのに、
なぜDB2という製品名が持ち出されるのかすげー謎。
まさかTPモニタはOracleしか使えないとでも思ってるのか（藁

964 ：デフォルトの名無しさん：2007/11/16(金) 23:26:45

963がどんどん哀れになってきました。

965 ：デフォルトの名無しさん：2007/11/16(金) 23:27:22

完全にスレチだが、アプリケーションサーバが強いベンダーは
もともとTPMonitorで稼いでいたところが多いよね。
その頃の思想をアプリケーションサーバに受け継がせている。
IBMはCICS→WebSphere、BEAはTuxedo→WebLogic、
ついでに日立はTP1→TPBroker→Cosminexusなど、

966 ：デフォルトの名無しさん：2007/11/16(金) 23:27:58

じゃあ、DB2だったらどうすんだヨ？って言ってみるテスト。
じゃあ、DB2だったらどうすんだヨ？って言ってみるテスト。
じゃあ、DB2だったらどうすんだヨ？って言ってみるテスト。

>>961よ・・・

967 ：デフォルトの名無しさん：2007/11/16(金) 23:28:25

自分が世界の中心を思い込みたいだけだろ。放置汁

968 ：デフォルトの名無しさん：2007/11/16(金) 23:29:03

クローンかどうかは知らんが、960の上5行がCOBOLで実現できるなら
Java厨が得意になって語っているメリットってあまりないなあ

969 ：デフォルトの名無しさん：2007/11/16(金) 23:37:02

つか、COBOLの場合だと宣言部だけで５行以上消費すると思うが。

まあ、○○を使えば、って事いいだすとそんなのなんでもアリになる罠。
VB.NET最強論と大差ない。

970 ：デフォルトの名無しさん：2007/11/16(金) 23:52:58

言語の話と製品の話とプラットフォームの話がごっちゃになるから
訳分からなくなるんだよ。言語スレで汎用機批判されてもなあって感じ。
だいたいここは対決スレじゃないんだから、次スレでは純粋に
言語についてのみ語りたいなあ。

971 ：デフォルトの名無しさん：2007/11/17(土) 08:36:56

えっ、次スレあるの？ w

972 ：デフォルトの名無しさん：2007/11/17(土) 08:52:47

個人的にはCOBOLが安定性云々って汎用機(IMS)が前提にしても怪しいよな。

ウチの職場な感覚だとCOBOLが言語的に枯れているのは事実だろうけど、
10年以上前のシステムを使い続けていて、誰も全仕様を把握してない
状況だから障害のない日が珍しい。って状態だったり。w

ぶっちゃけiSeriesにWebSphereの組み合わせで運用が適度に保守している
システムの方がCOBOLよりも生産性＆保守性＆安定性において
全て勝っている。

最大の問題はマイナーOSを使えるエンジニアがエスパー並に少ない事だが。w

様は使いどころと使う人間って結論なんだろうが、ウチは上がアレな性か今の現状は

安定命→汎用機＋COBOL→けどシステムグダグダ→よく落ちる
どーでもいい情報・分析系→適当なAP+DB鯖＋Java→使いやすい→超安定

とかなり皮肉な結果となっている。

973 ：デフォルトの名無しさん：2007/11/17(土) 11:16:12

メインフレームでTSSからJCL視認・手実行で
COBOLアプリを動かす。
これほど簡単で安定した運用環境はこの世に存在しない。

974 ：デフォルトの名無しさん：2007/11/17(土) 12:19:20

君だけを見ていた
コボルそうな笑顔
初めて見つけた時から

君だけを見ていた
ずっと側にいるよ
飾らない心で

975 ：デフォルトの名無しさん：2007/11/17(土) 12:21:39

COBOLだけを見ていた
寂しげな横顔
初めて見つけた時から

COBOLだけを見ていた
まっすぐな瞳と
飾らない心で

976 ：デフォルトの名無しさん：2007/11/17(土) 13:13:41

それにしても相変わらず「普通に・・極自然に」って訳の分からない日本語を
使うヤツが自分の価値観を振りかざすのはなんでなんだ？
自分の嫌いなものは悪というシンプルなルーチンしか持ち合わせてないのか？

COBOL擁護派は"一般的"に多くのシステムで稼働を続けているとか
"多くの"金融機関の基幹系はCOBOLだとか定型句を言い続けてるだけで、
完全否定派は"個人的に"とか根拠のない"普通に"の後に自分の感想文を
付けているだけなんだよな

どうせ両派共に当てはまるようなヤツはプラットフォームの選定や決定にかかわる
ような仕事には携わらせて貰えないんだから、自分の好きな言語だけを使えれば
困らない職場にシッポ降ってついて行けばいいじゃん

見苦しい

977 ：デフォルトの名無しさん：2007/11/17(土) 13:52:32

>>976
はいはい、おまえも価値観丸出しなんだけどｗ
恩をあだで返すタイプだな
お世話になってる人の悪口をいう奴。

978 ：デフォルトの名無しさん：2007/11/17(土) 14:04:17

価値のない見本が釣れましたww

979 ：デフォルトの名無しさん：2007/11/17(土) 14:16:46

難しいことを言っても始まらん。あまりに稼働中のシステムが多いから、

「学名に死語であるラテン語を使っていることを変えられない。」

のと同じことじゃないのか？　Argol由来の言語はほぼ共通の形式で大差がない。
最後は特殊・実験プログラミング用の言語とCOBOLが残るぐらいだな。

980 ：デフォルトの名無しさん：2007/11/17(土) 14:24:27

>>977
>976が卑下してるようなタイプの人間に恩を感じてる人がいるなら、君も将来、いやたぶん既に恩を着せてるつもりの奴に見下されてるよ。
ガンバレ　せ・ん・ぱ・い♪

981 ：デフォルトの名無しさん：2007/11/17(土) 16:12:54

うひゃ
釣れまくりだなｗ

982 ：デフォルトの名無しさん：2007/11/17(土) 16:50:15

コボルスレのくせに下手な言語スレよりレス伸びてんなｗ

983 ：デフォルトの名無しさん：2007/11/17(土) 18:55:12

言語は終わってるけど俺たちのスレは始まったばかり！

984 ：デフォルトの名無しさん：2007/11/17(土) 21:59:19

最初からクライマックスな言語なだけあるなｗ

985 ：デフォルトの名無しさん：2007/11/17(土) 22:12:35

次のスレタイはなにかな

986 ：デフォルトの名無しさん：2007/11/17(土) 22:57:28

オブジェクト指向が行き詰まり
C++やJavaが改変の果てにグダグダ言語になって
世界はやがてシンプルなCOBOLへ還る…
そんな日がきっと来ると思うんだ。
だからCOBOLの技術を磨き、資料を作って
次代へ継承しようよ。

987 ：デフォルトの名無しさん：2007/11/17(土) 23:04:30

たまっしぃーのルフーラン

988 ：デフォルトの名無しさん：2007/11/17(土) 23:06:47

極論COBOLerがうざいなら存在価値を薄めてやりゃいい。
進化はほぼ止まったような言語なんだから、現状のCOBOLを覚えちまえば
COBOLのシステムを抱えている企業でも事足りる。
COBOLerは年寄りが多い分無駄に高給だから需要あるぞ。
もちろん適用業務の知識を持っていることが条件だけどな。

最近の若い奴らって仕様書通りにはどうにか作るけど稼働させる現場のことを
全く勉強しないんだよ。一生プログラマで食ってくつもりなのかね？
それがCOBOLerの入口だと気づいてるんかいな？

989 ：デフォルトの名無しさん：2007/11/17(土) 23:31:45

使ってる言語の優劣なんて問題じゃないのよ。
経験そのものに価値があるんだから。

990 ：デフォルトの名無しさん：2007/11/17(土) 23:35:11

プログラマーの経験なんて何の役に立つんだか。
SEやらPMの経験ならともかく。

991 ：デフォルトの名無しさん：2007/11/18(日) 00:11:54

>>990
意味ワカンネ。
プログラマーの経験は次のプログラミングに
役立つに決まってるじゃねえか。
一つ仕事をするたびにそのソースを体に取り込んで
成長する、それがプログラマのあるべき姿だ。

992 ：デフォルトの名無しさん：2007/11/18(日) 00:42:40

とりあえず次スレではCOBOLerの要件定義からはじめようか

993 ：デフォルトの名無しさん：2007/11/18(日) 00:49:51

>>986
黄ばんだドキュメントなら腐るほどあるけど・・・
次代云々前に今すぐ窓から投げ捨てたい。

994 ：デフォルトの名無しさん：2007/11/18(日) 00:50:58

COBOLのシステムについてはいろいろな意見はあるようだが
COBOLerイラネってのは異論が無さそうだな