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

1 ：デフォルトの名無しさん：2007/11/19(月) 00:36:03

リランってか

2 ：デフォルトの名無しさん：2007/11/19(月) 00:36:24

2

3 ：デフォルトの名無しさん：2007/11/19(月) 01:00:40

おまいらってFORTRANできるん？

4 ：デフォルトの名無しさん：2007/11/19(月) 16:46:18

OpenCOBOLって生Cで書いてるんだな

5 ：デフォルトの名無しさん：2007/11/20(火) 09:28:40

メンバメイコボルスミ11

6 ：デフォルトの名無しさん：2007/11/28(水) 12:45:54

>>3
大学で習った（10年前）がもう忘れてるな

7 ：デフォルトの名無しさん：2007/12/14(金) 11:30:44

保守します

8 ：デフォルトの名無しさん：2007/12/14(金) 21:00:57

スレタイ、PIC X(2) とした方が良かったんじゃないか？

9 ：デフォルトの名無しさん：2007/12/14(金) 21:31:07

今日最終面接受けてきたところに受かると、JavaとCOBOLやんなきゃならない。
速攻で本屋に行って事前調査をしようとしたんだけど、COBOL本が全然並んでない。
JavaとVBはわかるんだけど、COBOLなんて遠い世界の話だった・・・。

・・・どうしたらいいのかわからない俺のためにCOBOLの入門〜中級本を紹介してください。
おながいしまつ。

10 ：デフォルトの名無しさん：2007/12/14(金) 21:59:42

勘でなんとかなるだろ

11 ：デフォルトの名無しさん：2007/12/14(金) 23:47:35

COBOLは極めて単純、と言えなくもない

12 ：デフォルトの名無しさん：2007/12/15(土) 00:41:15

なるほど・・・まあ、適当に基本情報のテキストでも見てみる。ありがとう。

13 ：デフォルトの名無しさん：2007/12/15(土) 00:54:45

ｳﾝｺBOL

14 ：デフォルトの名無しさん：2007/12/15(土) 02:05:35

>>9
COBOL本
大きめの書店なら多分置いてあると思うけど…

15 ：デフォルトの名無しさん：2007/12/15(土) 16:07:29

COBOLでグラフ作ってた時代に戻りたい

16 ：デフォルトの名無しさん：2007/12/17(月) 18:12:01

ＣＯＢＯＬ２００２ってすげえんだな。
オブジェクト指向だよ。

ＣＯＢＯＬでここまでやるなら
ｊａｖａでいいじゃんとコボラのおっさんが嘆いていた。

17 ：デフォルトの名無しさん：2007/12/17(月) 18:40:27

旧来のコボルと互換性は無いのか？

18 ：デフォルトの名無しさん：2007/12/17(月) 19:12:39

COBOL.NETとかぶっちゃけいらないよなCOBOL85とFDでしこしこやらせろよ

19 ：デフォルトの名無しさん：2007/12/17(月) 20:32:00

>>9
アメリカ国防総省に掛け合って仕様書もらってこい。

20 ：デフォルトの名無しさん：2007/12/17(月) 20:37:45

ペンタゴン！...ってキン肉マンに出てきた超人ですか？

21 ：デフォルトの名無しさん：2007/12/28(金) 13:29:39

>>3
大学の後輩が授業でやったと言っておった
現在4年だから、まだやってるとこはやてるみたいだな

22 ：デフォルトの名無しさん：2008/01/16(水) 18:07:24

ソース書くときに1行=92バイトって制限あるようでコンパイルエラーorz
改行を無効化するような制御ってあるんでしょうか？

23 ：デフォルトの名無しさん：2008/01/17(木) 05:14:58

<<22
１行92バイト超えるようなソースなんて書くことある？
右に寄りすぎてるならPERFORMで抜き出せばおｋじゃないかしら

24 ：デフォルトの名無しさん：2008/01/17(木) 05:16:32

追記
改行してもピリオドまでが制御だから問題なし

MOVE A
　TO B.

25 ：デフォルトの名無しさん：2008/01/17(木) 14:03:39

<23
<24

ご返答ありがとうございました。
埋め込み型のSQLを記述しておりまして、関数多様していたため92バイト以上になってました；；

26 ：デフォルトの名無しさん：2008/01/23(水) 11:52:06

コボラーの人に質問なんですが。

COBOL入門
http://www5.plala.or.jp/shirokaze/cobol/htcobol.html

このページの｢CGI化｣以降のプログラムで、配列(テーブル)を誤解していない?

最近の処理系のCOBOLというのはREDEFINES句てないの?
あれば楽なのに出来そうな事を、変な事しているし。

27 ：デフォルトの名無しさん：2008/01/24(木) 01:09:19

全部読んでないけど、配列が云々以前にマとしてのレベルは余り高くなさそうだな。

28 ：デフォルトの名無しさん：2008/01/25(金) 17:53:51

>>26
fatness.cob
IDENTIFICATION DIVISION.
PROGRAM-ID. fatness.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
DATA DIVISION.
WORKING-STORAGE SECTION.
* コマンド全体を格納するTEMP変数
77 i pic 999 value 0.
77 j pic 999 value 0.
01 inum pic 999 value 0.
01 height pic 999 value 0.
01 weight pic 999 value 0.
01 fatness pic 999 value 0.
01 WORKSTR PIC X(20).　　　　　＜＝＝＝＝＝＝＝　ここでpic定義して　　　　
02 C OCCURS 20 PIC X.　　　　　＜＝＝＝＝＝＝　　ここでもpic定義。
　　　　　　　　　　　　　　　　　　　　　　　　　これ、コンパイルエラーじゃね？　　

29 ：デフォルトの名無しさん：2008/01/26(土) 13:00:26

>>28
まあ、それは単純ミスで

01 WORKSTR.
02 C PIC X OCCURS 20.

の間違いだと思うけど、>>26のリンク先の人は、(html,perl,COBOLのソースの絡みから見て)配列にデータがどう格納されているか理解してないように思う。
それとも、例えば、身長162を入力するのに、26100000000000000000と入力させる設計する人なのかな？
この人、職業はＳＥらしい。
Java道場なるものも書いているけど、「はぁ〜だいじょうぶ？」

30 ：デフォルトの名無しさん：2008/01/28(月) 01:54:12

>29
ＣＯＢＯＬでCGIとかはやったこと無いんだけど、
パラメータ入力チェックも兼ねているんだろう。
ｗｅｂ方面言語のアルゴリズム常識かも知れん。

atoiのところは、入力が162なら
Cの配列は、
162（以下ブランク17エントリ）となり
inum結果は数値の162となる。

１エントリ目：inum=0*10+1
２エントリ目：inum=1*10+6
３エントリ目：inum=16*10+2

31 ：デフォルトの名無しさん：2008/01/28(月) 02:07:03

>29
COBOLは数値を基本的には右詰めで扱うから
左詰めの文字列を右詰めの数値にするために
ややこしいことをしてるんじゃないか？

32 ：デフォルトの名無しさん：2008/01/30(水) 21:40:21

cobolの予約語でZEROってあるよね
あれは「数字」の0って意味？

プログラムの中で、フラグを立てるために文字としての'０'を使いたいんだけど、
どうにも使い分けの基準が分からなくて…

33 ：デフォルトの名無しさん：2008/01/30(水) 22:02:48

ZEROは「1桁以上の0」らしいな
複数桁の文字項目に0とZERO入れたら結果違うのか？

34 ：デフォルトの名無しさん：2008/01/31(木) 00:06:47

どうなるんだろう
調べれば調べるほどに分からなくなってきた…

35 ：デフォルトの名無しさん：2008/01/31(木) 00:51:54

>>32
フラグ（"1" or "0"）に文字タイプは危険。
初期化したはずみにスペースが入ってしまい、
フラグチェックをすり抜ける可能性有り。

36 ：デフォルトの名無しさん：2008/01/31(木) 19:08:26

コボラーになることが決まり、今NETCOBOLstudio触って勉強中です。
ファイルつかった処理がしたいんですけど、相対編成のファイルとかってwindows上で再現できますか？
どういう具合にエディットすればいいんでしょう。

37 ：デフォルトの名無しさん：2008/02/01(金) 18:28:19

>>33
ZEROとかSPACEは表意定数というのだっけかな。
複数桁の項目が数字項目ならばどちらでもOKだけど英数字項目の場合
ZEROを代入すると全てゼロになり、"0"を代入すると先頭の1桁だけゼロで
あとはスペースになったような気がする。

38 ：デフォルトの名無しさん：2008/02/01(金) 22:28:25

>>37
正解

39 ：デフォルトの名無しさん：2008/02/04(月) 04:21:47

この３月で会社をやめるので、やっとＣＯＢＯＬからおさらばできる。
こんな効率の悪い言語今まで使っているのが苦痛だったよ。
ま、細かいＰＧ制御とかできるから今だにつかわれているんだろうけど。
コボラーのみなさん、頑張ってください。私は不本意ながら離脱します。

40 ：デフォルトの名無しさん：2008/02/05(火) 19:16:43

>>39
おつかれ。

４月からコボラーの俺が来ましたよ。

41 ：デフォルトの名無しさん：2008/02/05(火) 23:59:57

>>39
弘法筆を選ばず

42 ：デフォルトの名無しさん：2008/02/06(水) 06:51:00

でもプロとかって実際筆とか選んでいるよな。
選ばないプロの方が珍しいし。

43 ：デフォルトの名無しさん：2008/02/06(水) 21:41:19

もちろん弘法に良い筆なら鬼に金棒。
だが、コボラにどんな言語させても効率悪いコードしか書かないんだよ。

44 ：デフォルトの名無しさん：2008/02/06(水) 21:53:12

>>43
効率って何を指してる？
処理速度？
読みやすさ？
改修のしやすさ？

いろいろあるんだぜ。ＰＧなら言葉は正確につかうもんだ。

45 ：sage：2008/02/06(水) 23:44:04

読みやすさでは、ＣＯＢＯＬにかなう言語はそう無いでしょう
改修のしやすさと言う点でも
まぁ、ＣやＢＡＳＩＣでも書く人によるといわれればそれまでですが

46 ：43：2008/02/07(木) 03:12:12

>44
>39 の言葉を借りただけだから、>39 の真意は判らんが
俺としては３つとも全部を意味する。
「書く人による」ことを言いたかっただけなんだが、

COBOLのスレで「コボラ」という単語を、俗称として
用いてしまったのは完全に失言だったと思う。

ごめんなさい。いやまぢでごめんなさい。

47 ：デフォルトの名無しさん：2008/02/07(木) 06:57:41

＞読みやすさでは、ＣＯＢＯＬにかなう言語はそう無いでしょう
＞改修のしやすさと言う点でも

同系統の言語だとRPGの方がぶっちぎりで読みやすいと思うが。

48 ：44：2008/02/08(金) 01:44:00

>>46
そんなに自己卑下するほどのもんでもないさ。
確かにCOBOLはグローバル変数しか無いし、スコープの概念すら無いし、
扱い難いには確かなんだが、１本のサイズをコンパイル通して2.0ｋ位
（プログラム本体として）までなら何とかなる代物。

49 ：デフォルトの名無しさん：2008/02/09(土) 01:47:23

そのCOBOLでさえ読みにくいコードをかくのがコボラ

50 ：デフォルトの名無しさん：2008/02/09(土) 03:35:34

おれ汎用機のＣＯＢＯＬだけど、デバッグがしずらいな。
ＰＣのコボルはそれなりに開発しやすいのかもしれないけれど。
あと、日本語や漢字関係でいつも苦労させられているよ。
おれはマッチングのＰＧがだいの苦手。ＤＢならＫＥＹをりんくするだけなのに。。。
ま、開発言語とＤＢを一緒にしちゃいけないんだろうが。

51 ：デフォルトの名無しさん：2008/02/09(土) 17:32:00

ずっと仕事でCOBOLやってて（といっても数年だけど）
べつの言語の仕事もやりたいと思ってるんだけど、どれを覚えるのがいいですか？

52 ：デフォルトの名無しさん：2008/02/09(土) 19:03:31

VB

53 ：デフォルトの名無しさん：2008/02/09(土) 21:41:43

>>51
Adaを進める。これをマスターすれば他にツブシが効く。

54 ：デフォルトの名無しさん：2008/02/09(土) 22:23:07

>>52-53
サンクス。
Adaとか聞いたことなかったけど調べてみます。

55 ：デフォルトの名無しさん：2008/02/10(日) 02:51:08

>>40
がんがれ

56 ：デフォルトの名無しさん：2008/02/10(日) 02:51:27

>>40
がんばれ

57 ：デフォルトの名無しさん：2008/02/10(日) 02:51:29

>>40
がんばれよ・・・。

58 ：デフォルトの名無しさん：2008/02/10(日) 03:02:30

>>50
ま、COBOLの売りは1レコードが何千アイテムという巨大なデータを扱うことだからね
職業SEやってたら宿命でしょうな。
他の言語で遊んで見ることをお勧めします。

59 ：デフォルトの名無しさん：2008/02/10(日) 05:11:19

>>58
>1レコードが何千アイテムという巨大なデータ
いったい誰がこういうスタイル考え出したんだろうねえ。
昔のＩＯ処理に時間がかかるから何でも詰め込んでしまえってところか。
その影響なのか知らんが、ＤＢですら結構な数、アイテム持たせてるわ。

60 ：デフォルトの名無しさん：2008/02/10(日) 12:36:41

>>59

コボラは横長DBがお好き ２カラム目
http://pc11.2ch.net/test/read.cgi/prog/1179927770/l50


だもんな w

61 ：デフォルトの名無しさん：2008/02/13(水) 19:44:41

C言語とCOBOLってどっちが難しいかな？

62 ：デフォルトの名無しさん：2008/02/14(木) 00:06:35

COBOL

63 ：デフォルトの名無しさん：2008/02/14(木) 05:45:43

>61
何をもって難しいとするか、の基準によりけり。

64 ：デフォルトの名無しさん：2008/02/14(木) 07:36:44

>>63
基本情報君だと思われ。
基情なら圧倒的にCOBOLのほうが簡単。

65 ：デフォルトの名無しさん：2008/02/16(土) 10:27:13

みなさんのお知恵をお借りしたいです。m(__ __)m
cobol + ORACLE10gです

下記のような事が可能と言われたのですが、
検証した結果無理でした。
再度、試みますが物理的に可能なんでしょうか？

手順�@
INSERT
(COBOLE) PIC 9(09) COMP-3 ⇒ (ORACLE) CHAR 5
※この場合 ORACLE上では正しく表現されない事はOKとします。

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

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

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

66 ：デフォルトの名無しさん：2008/02/18(月) 14:46:07

PIC 9(9) COMP-3 は５バイトなんで

01 A.
02 B PIC 9(9) COMP-3.

ってのを作って、DB とのやり取りは、A を使えばいい気がするけど
文字化け起こさないのかな。

67 ：デフォルトの名無しさん：2008/02/18(月) 21:27:49

>>66 ！！！あなたはすごいですね！！
指摘どおりに修正したら、問題解決しました！！！！！！
本当にありがとうございます！！！！！！！！！！！！！

68 ：デフォルトの名無しさん：2008/02/19(火) 00:53:56

IBMの汎用機で開発経験者のコボラさんは
REXXわかりますか

69 ：デフォルトの名無しさん：2008/02/21(木) 14:53:46

COBOLなんて絶滅した方が今後のプログラマにとっていいだろう

70 ：デフォルトの名無しさん：2008/02/21(木) 23:11:18

１月に３０半ばかつこの業界全くの未経験で、コボラーへ転職した漏れ様が
たったいまこのスレに降臨いたしますたよーｗｗ

ところで、フローチャートとか書いてからプログラミングとかしているの？
あとコボラーはどうなの？
まぁの人生よりかは需要はありそうだが…

71 ：デフォルトの名無しさん：2008/02/22(金) 00:24:47

コボルにしろ、C++にしろ、Javaにしろ
慣れるまではフローチャート書いたほうがいいかもね。

72 ：デフォルトの名無しさん：2008/02/22(金) 00:28:45

フローチャートは諸悪の根源。
意味が無い。

73 ：デフォルトの名無しさん：2008/02/22(金) 00:30:21

>>71
そうですよね…
漏れ、ビジネスニュース＋板でも色々と書いたんだけど
ＯＪＴで覚えろ的な会社に入っちゃったから、
フローチャート書く習慣を見につけないまま現場に入りそう…
これじゃダメだと思うんだが、上司が許してくれない…

学費とかなら自分で出すから、しっかりと教わりたい気もする

74 ：デフォルトの名無しさん：2008/02/22(金) 00:32:19

フローチャートはあんま意味ない。
フローチャートを書かせるところはダメな会社と思った方がいい。

75 ：デフォルトの名無しさん：2008/02/22(金) 01:13:34

フローチャートとは、コボルの場合jclとモジュールとＤＢの仕組みを書いた
あの図のことかしら

76 ：デフォルトの名無しさん：2008/02/22(金) 02:46:14

>>75
それはたぶんジョブフロー。

77 ：デフォルトの名無しさん：2008/02/22(金) 09:50:20

正直、現代においてはフローチャートとプログラムの品質やら生産性はまったく関係ないな。
むしろ悪くなる。

ただ、プログラムの開発・テストが終わった後に後のメンテの為に
フローチャートを作るのは意味あると思うけど。

おそらく昔は端末すらも貴重な時代だったので机上かつ紙の上で
設計＆コーティングして第三者に再監してもらってから、コードを
パンチカードに入力ってノリだったので「プログラムするときはフローチャートと先に書け」
と言う格言めいたのが生まれたのだと思うが。

78 ：デフォルトの名無しさん：2008/02/22(金) 22:05:55

>>70
コボラなら時間がある限りフローチャート覚えておくに損はない。
フローチャート言うても、まったり書いてたら意味がない。
ループ処理に着目して、
必ず存在するループ前処理、ループ脱出条件、ループ後処理、
を意識して書け。

間違ってもグルグル巻きのバームクーヘンみたいな図は書くな。
ループ毎に右へネストさせた図を書け。

そうすれば、COBOLの基本であるマッチング処理やサマリ処理の意味が
図解した形でイメージが頭に入り理解できる。

俺もループネストフローチャートは結構書いた。
それで、繰り返し処理のEXIT条件やその前後に付帯する処理なども体に染みついた。

自動車運転と同じ。
慣れるまでは前頭葉で考えながら乗るが慣れれば小脳に移る。
COBOLプログラミングもそれと似ている。

>>73
個人レッスンしてやろうか？

79 ：デフォルトの名無しさん：2008/02/23(土) 00:56:56

>>78
>>73です
マジでお願いしたいですわｗ

それはさておき、
人にばっかり頼っているのはイクナイと思い
今日帰りに紀伊国屋へ行ったら、
参考になるような本があったので、それ買っていまやってました
明日もやる予定です

昔の発行された本ですが、わかりやすいと思いました…

80 ：デフォルトの名無しさん：2008/02/23(土) 01:03:01

あ、１つ言っておくね…
漏れ>>70＝>>73＝>>79です

81 ：デフォルトの名無しさん：2008/02/24(日) 00:06:45

COBOLを学校で学んでいる者です。
課題について聞きたいことがあるのですが…
いいですか？

82 ：デフォルトの名無しさん：2008/02/24(日) 01:21:00

書いてみ。活気のあるスレじゃないから返事遅いかも知れんが、他のスレよりここが適任だろ。

83 ：デフォルトの名無しさん：2008/02/24(日) 21:33:34

>>82

書いてみますね。
「キーボードから8桁の2進数を入力して、10進数と16進数に変換し表示して9を入力したらブログラム終了」
このようなプログラムを作りたいんです。
教えてくれませんかねー

84 ：デフォルトの名無しさん：2008/02/25(月) 02:44:00

今のところ、どこまで解るの？
2進→10/16進の変換で詰まってるのかな。

85 ：デフォルトの名無しさん：2008/02/25(月) 03:05:10

2進数を10進数に直す方法はググりゃすぐ出ると思う。
COBOLコードにするなら、1桁ずつの配列にして、ループ回すのが楽か？

86 ：デフォルトの名無しさん：2008/02/25(月) 23:25:09

01 BIN-DATA.
03 BIN-BIT PIC 9 OCCURS 8.
01 HEX-DATA.
03 HEX-HI PIC X.
03 HEX-LO PIC X.
01 DEC-DATA PIC 9(3).
01 HEX-STR.
03 HEX-STR-DATA PIC X(15) VALUE "0123456789ABCDEF"
03 HEX-WK REDEFINES HEX-STR-DATA.
05 HEXS PIC X OCCURS 15.

こんなんどうでしょう？

87 ：デフォルトの名無しさん：2008/02/26(火) 00:36:22

２進数から１０進数・１６進数への変換の仕方は分かってます。
ただどうプログラムにしたらよいか分からないんです。

88 ：デフォルトの名無しさん：2008/02/26(火) 04:53:25

どういう器を用意して、どんな命令を使って
どういう手順でやれば実現出来るか考える。

基本的なプログラムは見たことあるよな？

89 ：デフォルトの名無しさん：2008/02/26(火) 05:03:59

どんなプログラミング言語でも基本的なことだが
あいまいな文章から、細かい仕様を煮詰めていくのは大事なこと。
例えば「キーボードから8桁の2進数を入力」という文章から

　　→　8桁の2進数が入る項目を用意する
　　→　キーボードから入力する

ということを読み取る。

90 ：デフォルトの名無しさん：2008/03/04(火) 21:28:53

岡山から保守age

91 ：デフォルトの名無しさん：2008/03/09(日) 03:32:43

>>79
その参考書を教えて欲しい

92 ：デフォルトの名無しさん：2008/03/12(水) 01:49:26

質問してもいいですか？
.net系エンジニアなのですがCOBOL技術者の人と話していて違和感を感じたので。
１．COBOLの長大なレコードを処理するのって、最初にファイル読み込んで、
　　ループ開始：ファイル末尾まで着たら終了
　　　　#処理を記述〜
　　　　次の行へ読み進める処理
　　ループ終了：
　のような感じになってる、って認識でいいの？
２．変数は、定義したときに「コレは固定長出力ファイルに書き出すもの」「コレは書き出さないもの」
　　の2択で最初から決めてある、でOK？
３．FILLER項目をよく切るけど、FILLERで切って置かないといけない理由は？
　　固定長の項目のバイト位置が変わるから？

あと、COBOLのひとがJavaやそのへんのオブジェクト指向言語を扱わせるのに注意すべき点ってあります？
以前SQLを教えたときは、意外とすんなり理解してくれたのだけど.netやJavaになると
急に理解が悪く･･･。何か誤解しやすいのかなぁ

93 ：デフォルトの名無しさん：2008/03/12(水) 07:03:40

１だがCOBOLerういう人が多いな。C風(?)のループを組む人は少ない
２は言語仕様から前もって全ての変数を定義する必要があるので
自然とそんな感じになるのだろう。
３はCOBOLerだから。いやマジで

＞急に理解が悪く･･･。何か誤解しやすいのかなぁ
経験則的にCOBOLerは「新しい技術に否定的であり、なおかつ根拠のないプライドがたかい」から
まあ、参照型（ポインタ）の概念が理解出来ん人が多いし、それ以前に構造化も知らん人いるし
根本的に「オブジェクトに対して操作する」と言う概念が理解できんだろ。
ひたすら手続きを並べる事に一生を捧げてきた人種だから。

94 ：デフォルトの名無しさん：2008/03/12(水) 08:20:45

>92
３．について

(1) バッチ処理では、ファイルをワークファイルに書き出し、
「転がす」処理を行うんだけど、そのときに、後処理で必要な
計算結果などをFILLERの部分に格納しておく。

(2) 単純にスペース効率のいいレコード長にあわせるため。
これは(1)のワークファイルのスペース効率に関係している。

(3) レイアウト変更があった場合、プログラムの修正を
なるべく少なくするため。

DBという概念がなく、メモリやディスクが潤沢に
つかえなかった時代に編み出された手法で
前世紀の遺物といってもいい感じ

95 ：元コボラ：2008/03/12(水) 11:42:38

３．について

コンパイラに依存するかもしれないが、"FILLER"をコーディングしないと、
INITIALIZE命令をそのフィールドに割り当てた場合、low-valueになる
環境の場合がある。

96 ：元コボラ：2008/03/12(水) 11:51:37

low-valueでは困る場合があるので、空白文字（EBCDICでX'40')に
する為にINITIALIZE命令を実行してもlow-valueにならないように
'FILLER'をコーディングする。

97 ：デフォルトの名無しさん：2008/03/12(水) 13:32:34

>95-96
何いってるのかサッパリわからん。
FILLER 項目は INITIALIZE 命令の影響をうけないんじゃないか？

98 ：デフォルトの名無しさん：2008/03/12(水) 13:42:02

COBOLは基本的にBCD演算だから何十桁でもなんなくこなせるのがいいよな
金銭業務以外ではあんまりメリットないけどｗ

>>53
Adaなつかしいな。大々的に宣伝して、人知れず死に絶えた体系。今は誰も知らないだろうけど

99 ：元コボラ：2008/03/12(水) 13:42:45

>>97
コンパイラ環境によって影響あり。

100 ：デフォルトの名無しさん：2008/03/12(水) 20:54:01

ＦＩＬＬＥＲはやっぱりレイアウト変更の時に融通聞かすためじゃないかな。
後から項目を追加する場合、似たような項目の隣におきたいよな。
しかし、それをやっちまうと、そのレイアウトのＰＧをすべてコンパイルし直さないと
ならないんだよ。
ま、今の時代、きりのいいレコード調にしたいってのもわかるしな。
あと、ＦＩＬＬＥＲの項目に後で使う数字を格納するのはお勧めしないぞ。

後日、その処理を引き継いだものが仕様書読み返さないと何をやっているか
わからなくなる可能性があるからな。

101 ：デフォルトの名無しさん：2008/03/12(水) 23:28:50

>>93
確かに長年ＣＯＢＯＬｅｒをやってると
オブジェクト指向なんて全く理解できないわ

鉄は何とかの内に打てっていうじゃん
プログラムを触る初めの内に
ｊａｖａとかやってないと絶対にダメだと思ったわ
ＣＯＢＯＬなんて後からでも十分に理解できる言語だからね

これからでも汎用機は残るだろうけど、
それがメインで残るなんてことは絶対にないわけだから
やっぱｊａｖａとかの概念だけは学ばなければと思ったわ


>>91
昭和５０年代後半〜平成５年くらいまでの情報処理試験用の
アルゴリズムの参考書が結構ＣＯＢＯＬｅｒさんには有効だと思う

中々入手しにくいかもしれないけど
紀伊国屋や三省堂など本当に大きなところからだと手に入ると思うので
探してみるといいかも？

102 ：デフォルトの名無しさん：2008/03/13(木) 06:50:06

別にJavaでもオブジェクト指向じゃなくて手続きベタ打ちな事が可能と言えば
可能なので、COBOLerが嫌がるほどの事でもないと思うが。

Javaも結構バカでも出来る言語だし。

Javaが人気なのは言語仕様よりもテストツールや開発IDEによる利便性と
生産性の向上とかだと思うが。

後は普通にライブラリが充実（しすぎ？）なのでCOBOLで地道な小技を組み合わせて
日付計算とかしなくて済むのが楽だな。

103 ：デフォルトの名無しさん：2008/03/14(金) 01:55:39

ＣＯＢＯＬｅｒには、たい焼き機の概念は理解しにくいな。

104 ：デフォルトの名無しさん：2008/03/15(土) 02:26:34

>>98
Ada、いいよ〜。これでアルゴル系の言語概念吸収できたし、型と変数の分離も分かった。
すんなり、Ｃに入れたよ。ポインタの扱いには苦労したが。。。

>>101
オブジェクト指向なんて判らなくても構わないんじゃない。
実装を見れば「ああ〜そうかなるほどな」ってな感じだと思うけどな。良きサンプル次第だが。
それより、COBOLの最適な有り方を追求したほうがいいんじゃない。
５Ｋ、１０ＫのＣＯＢＯＬプログラム、こういう物の存在が許されてる事に怒りを感じなきゃ。

それもオンラインだぜ。
今回入った職場は、画面遷移（状態遷移）の概念無きコボラーが組んだ代物だけあって最悪に
近いわ。

コボラーに問わず物言い放つ！
状態遷移の概念知らない奴はオンラインプログラムに手を出すな。近づくな。
「イベントドリブン」の言葉だけ知ってて、状態遷移の概念知らない奴もプログラム書くな。
「〜〜モード」で誤魔化す奴も、状態遷移の概念知らなければ、首吊って市ね。

ソフトウエア工学ってのは、最先端の知識・技法じゃないんだよ。
レガシーでも通じる、当たり前の技法・スキルなんだよ。

105 ：デフォルトの名無しさん：2008/03/15(土) 09:20:13

＞画面遷移（状態遷移）の概念

正直、言っている意味が解らん。
実行キーでデータ投入でPF3で終了とかPF12で前に戻るとか言うアレか？
それと5Kのコード量とかイベントドリブンとかオンラインとか喚いているのも解らん。

オンラインプログラムは神に選ばれた勇者のみがコード書いていたり
設計したと思っているのだろうか？


とりあえず喪前がソフトウェア工学って単語使う事自体が恥ずかしいモノを感じるが。

106 ：デフォルトの名無しさん：2008/03/15(土) 21:13:32

銀行系のシステムを作ったヤツは
他のヤツよりプライド高かったり

107 ：デフォルトの名無しさん：2008/03/15(土) 21:24:57

正直オンライン系プログラマってIBMのテンプレート真似てるだけで、
その世界から外にでると途端に使えない連中が多いよな。

つか、そこから更に自慰フレームワーク作り出してる連中は
さらにウザさ倍増だが・・・。

108 ：デフォルトの名無しさん：2008/03/17(月) 21:57:16

細島一司標準ＣＯＢＯＬプログラミングと結城 圭介実践COBOLプログラミング入門
のどちらが入門に良いでしょうか？
もしくはもっと良い入門書ありますか？

109 ：デフォルトの名無しさん：2008/03/19(水) 02:29:17

オーム社の図解シリーズCOBOL入門が分かりやすい。
入手困難。

110 ：デフォルトの名無しさん：2008/03/20(木) 01:18:12

藻前等に聞きたいんだが・・・
ＣＯＢＯＬの仕事って入ってる？
気持ちの持ちようなのかもしれんが
案件が減ってきているように思えるが・・

111 ：デフォルトの名無しさん：2008/03/20(木) 01:31:00

>>110
減ってないよ。但し、作業工程によって募集度合いが違う。
コーダー、プログラマーレベルは減ってるかもしれない。
製造・単体テスト案件２カ月で入ったが、実際は業務案件も
分かってなければ単体テストできない。
（DBに入れるテストデータの組み合わせがモロ業務）
上流工程のコボラが求められてんじゃないか。

112 ：デフォルトの名無しさん：2008/03/20(木) 04:21:06

自治体向けなんかだと結構あります。
昨日も10人くらい自分の周りでCOBOL組んでました。デスマです。

113 ：デフォルトの名無しさん：2008/03/20(木) 10:34:54

社保庁の５０００万件の突合って多分汎用機ＣＯＢＯＬでやってんだよな。
請け負っている会社は新しい仕事ができて喜んでいるのだろうか。
それとも、無理とわかってやっていてモチベーション低下しまくっているんだろうか。

114 ：デフォルトの名無しさん：2008/03/25(火) 12:00:55

>>113
えーこすでやってそうｗ

115 ：デフォルトの名無しさん：2008/04/03(木) 20:25:14

aspenとか言う糞エディタにもうんざり
COBOLの行番号といい、冗長性のウザさといい、日本語項目といい
もうやんなっちゃうよ

116 ：デフォルトの名無しさん：2008/04/03(木) 23:26:38

質問です。

以前、あるところで研修を受けたときの話です。

ACCEPT　項目名
と書いてある部分があり、
このPGMを実行すると画面で値が入力出来るようになり
この入力値はACCEPTで取得しているようでした。
(PGMはACCEPTの部分で一旦STOPしている？)

実際に自分の会社の環境で
上記と同じACCEPT文を実行するとSYSINから取得しようとし
落ちます。(SYSINをJCLで指定していないため。)

ACCEPT　　項目名　　FROM　　CONSOLE
と記述すると画面で入力を同じことが可能なのでしょうか？

会社の環境なので、むやみやたらに色々と試すのが
難しいため、教えて頂きたいです。　

117 ：デフォルトの名無しさん：2008/04/05(土) 00:40:59

>>115
そこがまたＣＯＢＯＬのいいところじゃんかよｗｗ
ＴＨＥ　ＣＯＢＯＬって感じで、漏れ的にはものすごく病みつきになっちゃう部分なんだよなＷＷ

118 ：デフォルトの名無しさん：2008/04/07(月) 11:36:11

>>116
うちの場合、
CONFIGURATION SECTION.
SPECIAL-NAMES.
CONSOLE IS CONS.
としておいて
ACCEPT　　項目名　　FROM　　CONS.
表示は
DISPLAY　　項目名　　UPON　　CONS.

119 ：デフォルトの名無しさん：2008/04/07(月) 16:47:13

俺は元コボラーだけど、今ＲＤＢの設計している。
オープン系の案件やったらマジ汎用系はつまんないよ！！

120 ：デフォルトの名無しさん：2008/04/07(月) 23:18:43

コボラのテクニカルタームの
電文
とはなんですか

121 ：デフォルトの名無しさん：2008/04/08(火) 22:35:13

>>116

ホスト系なら　その入力要求が行くのはセンターコンソールでしょう
通常は端末からは簡単には入力できません。

122 ：デフォルトの名無しさん：2008/04/10(木) 04:01:11

>>121
オフコンなんじゃないかい？
いまどき、メインフレームでACCEPT使える環境って無いよ。

123 ：デフォルトの名無しさん：2008/04/10(木) 23:11:00

ＡＣＣＥＰＴって・・・研修ＣＯＢＯＬでしか聞いたことないな

124 ：デフォルトの名無しさん：2008/04/12(土) 04:22:56

少し切実な話題。
今、システム改修のプロジェクトにいるのですが、コボルソースが無茶苦茶ですねん。
プロ仕１枚にソース１０Ｋってアンタなめてんのかよ、って言いたい位。
で、やむなくソース解析→仕様起こし、してるんですが、コボルの悪弊PERFORM飛ばし。
結構大事な処理もコメント無しでPERFORM文一行。
最悪なのは、制御文とデータ編集文がごちゃ混ぜになってるところ。

コボルメンテされてる皆さんはどうやってソース解析してるんでしょうか？
俺はこうしてる、ってな何か秘訣が有ればご教授願います。

自分は昔はコンパイルリスト印刷して、クロスリファレンスから追っかけて、
最悪はREADY TORACE文実行させてプログラムの動きつかんでましたが、
ｚ／OSになって以来、READY TORACE　廃止されたようで難儀してます。

125 ：デフォルトの名無しさん：2008/04/12(土) 08:52:51

>>124
解らないなら触らない。調べない。仕様はﾃｷﾄｰな事を書く。
COBOLに限らないが時間的制約がある中での作業なら割り切って客を騙せ。

おそらく>>124が求める秘策は存在しない。

つか、おそらく中間のグダグダなモジュール解析よりもインプットのファイルと
アウトプットのファイルのみに集中して、ゴミプログラムは解析しない方針で
新プログラムを組む方が早いがそれは作業者のスキル左右されるので
お勧めな方法かどうかは微妙。
レベルの低いプログラマーと言うかコーダーには不可能だろうな。

要件定義＆設計＆仕様作成＆実装＆テストが全てできる人でないと
そういうスッ飛ばし対応は難しいし。

126 ：デフォルトの名無しさん：2008/04/12(土) 14:26:30

>>124
100万円くらい予算追加してもらって
開発会社に当たってCOBOL開発のエースを
派遣してもらえ。
凡人が一週間悩むより、エースが半日集中して
解析した方が早い。

127 ：デフォルトの名無しさん：2008/04/12(土) 23:51:37

新人研修の言語がCOBOLです。
みなさんよろしく

128 ：デフォルトの名無しさん：2008/04/13(日) 00:12:17

今のウチに逃げる用意をしておいたほうがいいのでは・・・

129 ：デフォルトの名無しさん：2008/04/13(日) 21:24:51

>>124

>>制御文とデータ編集文がごちゃ混ぜになってるところ。

↑ってどういう感じになっているってこと？


>>コボルの悪弊PERFORM飛ばし

GO TO 飛ばしの方がキツイ。
PERFORM飛ばしって何？？

130 ：デフォルトの名無しさん：2008/04/13(日) 21:53:52

私などはPERFORMが入ったときは随喜の涙を流したものだったが。

131 ：デフォルトの名無しさん：2008/04/13(日) 22:14:32

随喜の涙を流したのはPERFORMに繰り返しの機能が付加された時でござる。
記憶違いでござる。

132 ：デフォルトの名無しさん：2008/04/13(日) 22:43:13

PERFORMは多用するとプログラムの流れが
見えにくくなるデメリットがある。
うちの部署では、初期処理・メイン処理・後処理の
三つに飛ぶ以外のPERFORMは禁止されている。

133 ：デフォルトの名無しさん：2008/04/13(日) 22:53:11

>>127
hello world!!

134 ：デフォルトの名無しさん：2008/04/13(日) 22:57:43

>>132
READに飛ぶのも禁止なん？

135 ：デフォルトの名無しさん：2008/04/13(日) 22:59:08

しんどいなそれ

136 ：デフォルトの名無しさん：2008/04/13(日) 23:19:50

>>134
禁止。
READは初期処理・メイン処理・後処理の中に
必要に応じて設ける。

137 ：デフォルトの名無しさん：2008/04/13(日) 23:24:21

>>132
手続き名を読みつないで流れを理解するのではなくて?

138 ：デフォルトの名無しさん：2008/04/14(月) 00:25:01

>>136
キツイなー。
同じ処理が何度か出てくるようなとき、
PERFORM使えないと逆にPGMの流れが見えにくくなる気がする。

139 ：デフォルトの名無しさん：2008/04/14(月) 02:51:23

PERFORMの悪弊
内PERFORM文で済む物も外PERFORMにする。
外PERFORMで出されたSECTIONの並び順が統一されてない。
１回しか呼ばれない、ほかからは呼ばれないSECTIONは１回呼ぶ場所に記述すべし。
（ロジックを分散する理由が無い）

ど新人にメンテさせると、既存ロジックいじるのが怖くて全てPERFORM文で
外出ししてしまう。要するに既存ロジック読めない奴がやる。
あるロジックのかたまりの中に機能追加、チェック処理追加なら外に出さず
その中に書き込め。ロジック分散させるな。

140 ：デフォルトの名無しさん：2008/04/14(月) 03:25:45

COBOLなんかやってると頭悪くなりそうですが、
みなさま自衛策は取ってらっしゃいますか？

141 ：デフォルトの名無しさん：2008/04/14(月) 17:10:16

COBOLerやってると、頭良くなる。
自衛策って例えば何？

142 ：デフォルトの名無しさん：2008/04/14(月) 22:10:12

> 自衛策って例えば何？
それが知りたいんですが、頭が良くなるのでしたら問題ないですね。

143 ：デフォルトの名無しさん：2008/04/14(月) 22:27:16

ある意味COBOLをやっていると他の言語に比べてライブラリがしてくれる
事を自前でしなければいけない事が多いからしょーもない小技に関してはアタマが
よくなるかも知れないな。
うるう年やら日付から曜日の算出とか。

とは言え現実に芸術的なアルゴリズムとかデータ構造を実装している
例を漏れは見たことないしRDBと関連する仕事させると設計がメタメタなので
あんましアタマいい印象ない。

144 ：デフォルトの名無しさん：2008/04/14(月) 22:31:44

変数が全部グローバルって時点で洗練しようがない。

145 ：デフォルトの名無しさん：2008/04/14(月) 22:35:57

>>144
そんなこと、関係あるかね。全部ユニークな名前を
割り当てるというのは洗練されたことかもしれない。

146 ：デフォルトの名無しさん：2008/04/14(月) 23:23:08

変数にスコープがある言語はキツいね。
自分はCやJavaに挫折したCOBOLerだけど、
その原因は主に変数スコープだった。

ローカル変数とカッコの位置関係、それに加えて
種類の多い繰り返し構文。これらのせいで
凶悪なほどにプログラムの流れが追いにくくなる。
Javaはさらにクラスとか言って処理そのものにも
スコープがあるので、輪をかけて大変。
何でプログラム言語はこう複雑になっちまったんだろうね。

147 ：デフォルトの名無しさん：2008/04/14(月) 23:32:44

スコープがあるからこそ、
流れが追いやすくなるんだけどな。
どこで変更されるか分からん方が辛い。

148 ：デフォルトの名無しさん：2008/04/14(月) 23:34:49

変数のスコープがあるから難しい、ってマジで言ってるとしたら
プログラマーなんて無理じゃないのか。

149 ：デフォルトの名無しさん：2008/04/14(月) 23:44:23

>>139
超テラヤバスｗｗｗｗｗｗｗｗｗｗｗｗｗ
漏れが新人の頃やってた手法じゃんかよｗｗｗｗｗｗｗｗｗｗｗｗ
で、先輩に怒鳴られて、Ｐｅｒｆｕｍｅ飛ばしはある程度やめたんだけど
それでも癖は治ってないなｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

150 ：デフォルトの名無しさん：2008/04/14(月) 23:54:34

>>146
わかりやすいと都合が悪いからだよｗ

151 ：デフォルトの名無しさん：2008/04/15(火) 00:38:02

>>147
そうかい？
ローカル変数が出てくるたびに脳内スタックを
一段消費するわけだが、その辺は君は無限？
自分は脳内スタックが一段しかないみたいで
無理だった。

152 ：デフォルトの名無しさん：2008/04/15(火) 06:47:19

＞ローカル変数が出てくるたびに脳内スタックを
＞一段消費するわけだが、その辺は君は無限？

その脳内スタックを無限にする為にスコープがあるんだが。


悪いが貴方はプログラマーの適正に欠いているフシがあるので
CとかJavaの世界には触らない方がいい。

そもそもJavaにはグローバル変数の概念がないからCOBOLerには
最高に相性が悪いと言う点を差し引いてもそう思う。

153 ：デフォルトの名無しさん：2008/04/15(火) 07:21:42

>>151
ローカル変数だけで書かれたルーチンＡは、
その部分だけで処理が完結している。
ルーチンＡだけ理解すればいい。

そこで別ルーチンＢを呼んでる場合は、
そのルーチンＢの仕様さえ分かっていれば、
やっぱりそのルーチンＡの部分だけ読めば理解できる。

簡単理解するためにローカルスコープが存在するのじゃ。

154 ：デフォルトの名無しさん：2008/04/15(火) 07:23:46

>>152
COBOLerの視点から。これはデータと手続きを分離した方がいいか、
手続きの近くにデータがあった方がよいか、と設計上の選択に
起因する。分離する設計をとっているため、現在のCOBOLの
言語仕様に止まっているわけだが、COBOLが社会の基幹部分の
コンピュータシステムを担っていることも事実で、そういう
設計の方が安定的だという主張があるのだとすれば、軽々しく
否定することはできないと思う。

155 ：デフォルトの名無しさん：2008/04/15(火) 14:57:49

COBOLやると頭悪くなるということがよくわかった。

156 ：デフォルトの名無しさん：2008/04/15(火) 18:45:09

保守以外の案件が山ほどあればそうなるんだろうが・・・

157 ：デフォルトの名無しさん：2008/04/15(火) 20:39:18

>>152
プログラマーの適性はあるよ。
COBOLとアセンブラはバリバリやっている。
CやJavaが苦手なだけだ。
挫折はしたものの、JavaをCOBOL的に使うことで
活路を開こうと思っていて、現在思いついたのは
mainクラスの中に初期処理メソッド、メイン処理メソッド、終了処理メソッドを
作り、それらを呼び出すことで処理をコントロールする。
変数はクラス変数というやつをmain内で定義すれば
main内の各メソッドでグローバル的に使えるらしい。
いけると思う。作るぞ、バリバリと。

158 ：デフォルトの名無しさん：2008/04/16(水) 00:48:38

＞COBOLとアセンブラはバリバリやっている。

ネタだと思うが制御やドライバ系のアセンブラならともかく
金融系のアセンブラバリバリはまったく自慢にならないというか
誰でも出来る。

アレはテンプレートを埋めてくかコピーしてツギハギにするだけだし。

159 ：デフォルトの名無しさん：2008/04/16(水) 03:27:09

すげービッグマウスだな。
それで適正があるとか・・・。

160 ：デフォルトの名無しさん：2008/04/16(水) 03:42:00

自分で言うこっちゃないわな。

161 ：デフォルトの名無しさん：2008/04/16(水) 07:17:53

JAVAでCOBOLインタプリタを書けば一番いいのでは?

162 ：デフォルトの名無しさん：2008/04/16(水) 10:53:38

>>161
ファイル編成で躓くよ。

163 ：デフォルトの名無しさん：2008/04/16(水) 21:01:03

うひゃー
マイクロフォーカスってたけぇのな

164 ：デフォルトの名無しさん：2008/04/17(木) 16:17:30

>>154
>COBOLが社会の基幹部分の
コンピュータシステムを担っていることも事実で、<
歴史観捏造。

社会の基幹部分（銀行、鉄道、社保、電話、etc）のシステム開発は
昭和５０年代から始まっている。当時の言語はCOBOLかFORTLANかPL/I
くらいしか無かった。この内、データ処理に向いたのがCOBOL、PL/Iだが、
PL/IはIBMが独占してたので残されたCOBOLしか選択支が無かったのが現実。

>これはデータと手続きを分離した方がいいか、
手続きの近くにデータがあった方がよいか、と設計上の選択に
起因する。<

これも嘘。
そのような選択支が設計時点で交わされた証拠はどこにもない。
単純にローカル変数の概念が無かっただけ。
その証拠に、コール文で受け渡す変数名称が位置パラメータにのみ
依存してる（＝FORTLAN）。位置パラメータとローカル変数は全く別の発想。

NECのCOBOL/Sはローカル変数を導入したプリプロセサだが、既に1969年に開発
されている。CODASYLがサボっただけ。

COBOLの世界でもローカル変数の必要性、有用性は認識されてたって事。

165 ：デフォルトの名無しさん：2008/04/17(木) 16:46:54

とにかくローカル変数は百害あって一利なしだな。
同じ変数が場所によって別物になるなんて、
考えただけでも恐ろしい。
変数Aはどこにあってもただ一つの変数Aであるべきだ。

166 ：デフォルトの名無しさん：2008/04/17(木) 23:06:12

>>165
脳内硬直コボラーの実態

167 ：デフォルトの名無しさん：2008/04/17(木) 23:20:43

世界の一流エンジニアがCOBOLを推薦することが無いのは何故なのだろう。
私は見たことがない。

168 ：デフォルトの名無しさん：2008/04/17(木) 23:26:46

>>165
FORTRAN is not FORTLAN.

169 ：デフォルトの名無しさん：2008/04/18(金) 04:21:06

>>167
マイケル・ジャクソン

170 ：デフォルトの名無しさん：2008/04/18(金) 07:16:35

>>169
M.Jは言語の差異や開発ツールの
能力よりも、プログラマの丁寧で
細心な注意の方が重要と主張した
のであって、COBOLが優れている
といったことはない。

171 ：デフォルトの名無しさん：2008/04/18(金) 08:39:55

別にCOBOLが優れているわけではないんだけど、
後発のくせに、いまだにシンプルさ・堅牢さで
COBOLを超える言語がないってのは寂しいモノがあるね。
もっとこう、COBOLerをワクワクドキドキさせる言語が
出てこないものかな。俺の生きているうちに。

172 ：デフォルトの名無しさん：2008/04/18(金) 11:57:42

>>171
シンプルと堅牢さならRPGの方が超えてるだろ。

狭い世界に閉じこもっていて他を認めない排他主義者が
世の全てを知ったように語るのは滑稽だな。

たぶんお前はエンジニアとして死んでるよ。

173 ：デフォルトの名無しさん：2008/04/18(金) 12:57:42

なんという煽り

174 ：デフォルトの名無しさん：2008/04/18(金) 15:59:39

>>171
COBOLとの対比にRPGを持って来るのはどうかと思うぞ。
AS400メインのローカルな言語ではないか。（VAX、何鱈は認めん）

COBOLに対しては、個人的にはSECTION単位のローカル変数を
導入して欲しいもんだ。
スコープ概念の無いローカル変数ってのも何だがな。

175 ：デフォルトの名無しさん：2008/04/18(金) 16:40:36

十分COBOLもローカル言語だと思うが。

「それは認めない」なんて事言い出すヤツは>>172の言うところの排他主義者そのものじゃん。

176 ：デフォルトの名無しさん：2008/04/18(金) 18:36:52

しかし堅牢さ云々を言うほどものすごいコアな制御系の処理をCOBOLで書いてるヤツがいるのか？

OSのカーネルだってC/C++で書かれているのが多いけど、そういうのに関しては
COBOLerはどう考えているのだろうか？

177 ：デフォルトの名無しさん：2008/04/18(金) 19:48:16

なんでコボラーじゃない奴が集まってるの？

178 ：デフォルトの名無しさん：2008/04/19(土) 01:56:45

>>177
コボラーは嘲笑の対象でしかないからなのかな・・・
はぁ・・・漏れもコボラーとして飯を食っていくことができるのだろうか・・・
はぁ・・・はぁ・・・ため息しか出てこない

179 ：デフォルトの名無しさん：2008/04/19(土) 08:10:28

>>177
そりゃしょーもない妄想ネタをageで書き込めば、COBOLer以外の目にもつくだろ。

180 ：デフォルトの名無しさん：2008/04/19(土) 09:01:08

とにかくCOBOL最強で間違いないのだから、他の言語のことは
気にせず前向きにガンガン開発していけばいいんだよ。
なにせ銀行や保険という日本を支える大規模基幹システムが
COBOLで構築・維持されている事実は動かせない。
悔しければメガバンクの勘定系をJavaで構築してみろ。
たぶんシステム障害多発で日本は終わる。

181 ：デフォルトの名無しさん：2008/04/19(土) 09:49:31

システム移行が遅いわ移行でトラブル多発するわしてる
現在の銀行のシステムの話ですか？

182 ：デフォルトの名無しさん：2008/04/19(土) 10:38:53

>悔しければメガバンクの勘定系をJavaで構築してみろ。
>たぶんシステム障害多発で日本は終わる。

COBOLerの設計が糞すぎ＆ドキュメントは頭の中とかのプロジェクトを
普通に移行できるワケないじゃん。

正確にはシステム障害ではなくて「ソフトウェア設計の潜在不良障害」だな。


＞COBOLで構築・維持されている事実は動かせない。

ちなみに株式とかそっちの世界はCOBOLから離れつつあるし、
金融系も徐々にオープン系にシフトしつつあるけどな。

あと漏れは保険の仕事もやったけど、COBOLは一切使ってない。

183 ：デフォルトの名無しさん：2008/04/19(土) 11:08:26

少なくともメガバンクの1つは、勘定系をCOBOLで構築してないよ。
どれかは機密保持上言えないけど。

184 ：デフォルトの名無しさん：2008/04/19(土) 11:09:50

COBOL は言語界の老害か。

185 ：デフォルトの名無しさん：2008/04/19(土) 11:11:21

勘定系は全てCOBOLって思ってる時点で知ったかだろ。

186 ：デフォルトの名無しさん：2008/04/19(土) 11:16:27

> なにせ銀行や保険という日本を支える大規模基幹システムが
> COBOLで構築・維持されている事実は動かせない。
たまにはPL/Iのことも思い出してやってください

187 ：デフォルトの名無しさん：2008/04/19(土) 11:18:40

なぜそんなにCOBOLerを叩くんだ？
大規模基幹システムにはCOBOLが最適という
事実を述べているだけだろ。

188 ：デフォルトの名無しさん：2008/04/19(土) 11:20:14

COBOL 以外の言語も知らないくせに
そこまで大口叩けるところが怖い

189 ：デフォルトの名無しさん：2008/04/19(土) 11:28:01

>>187
COBOLが叩かれているのではなく
COBOLerが叩かれているんです

190 ：デフォルトの名無しさん：2008/04/19(土) 12:32:39

昔、帳票処理等に向いている言語の一つとしてCOBOL(PL/I)が向いている時代があった。
と言うかメインフレームやオフコンでは僅かな選択肢しかなかっただけだな。
現代において品質や生産性を考慮した場合、COBOLが向いているとは正直いい難い。

ウチの職場ではホスト系業務のCOBOLerの品質＆生産性の悪さに
ずいぶん泣かされている。

つか開発的には赤字なんだよな。
運用で無理やり黒字にしているくらいなモンで。

COBOLはそんなに悪い言語じゃないと思うがCOBOLerの脳がとてつもなく悪いだけだな。
10年以上の前のシステムを保守する仕事もあるから全否定はしないけど、
「大規模基幹システムにはCOBOLが最適」なんて寝言は言うべきではない。

191 ：デフォルトの名無しさん：2008/04/19(土) 12:49:02

ていうかCOBOLer以外はここ来るなよ。
スレタイ読め。
CやJavaなんてこの世の糞だ。
COBOLこそ言語界における唯一絶対の存在。
これは永遠に変わらん。

192 ：デフォルトの名無しさん：2008/04/19(土) 13:02:10

なんという煽りｗ

193 ：デフォルトの名無しさん：2008/04/19(土) 13:59:00

Javaからオブジェクト指向機能全てとローカル変数を外し、
COBOLの文法が通るようにし、APIに相当するサブルーチン集を付けて
アドバンスドCOBOLとして出直すなら、使ってやってもいい。
クラスなんぞ作っても、一人の人間が一貫して保守し続けるので
ない限り、隠蔽効果や再利用効果なぞは価値を持たない。
人が変われば「このクラスは一体何だ？」というところから始まるのだから。
それではCOBOLのサブルーチンと何ら変わりがないではないか。

またローカル変数は、その場限りという雑で近視眼的な意識を生み出し、
それは変数設計のみならず、コーディングの質全体に影響を及ぼす。
結局、オブジェクト指向やローカル変数は、高尚なことをしているつもりで
余計なことをしているに過ぎないのだ。

Javaなどに目移りしているCOBOLerもいるだろうが、私は言いたい。
目を開けてよく現実を見るんだ。
クラス仕様を考えている暇があるなら、その時間で一行でも多くロジックを
書き、とっととテストに移るべきだ。
メインルーチンに一直線に処理を並べ、サブルーチン分岐も極力少なくする。
これが結局一番シンプルで保守しやすいプログラムになる。
自分たちには、COBOLのパワーを使いこなし、日本社会の基幹部分を
担うシステムを維持していく大事な使命がある。他言語に惑わされるな。

194 ：デフォルトの名無しさん：2008/04/19(土) 14:03:37

こんなアフォがシステムを語るから「COBOLerは老害」と言われるんだろうなぁ

195 ：デフォルトの名無しさん：2008/04/19(土) 14:55:06

半分読んだが、言ってることは正しい。
ただ、ローカルルールで、プログラマー板が有る。
そこで一つ質問だが、有料最安Windows NTのCOBOL言語は？
>>194 COBOLerじゃなくていいのか。

196 ：デフォルトの名無しさん：2008/04/19(土) 15:09:40

自作自演が始まりました。

197 ：124：2008/04/19(土) 17:00:13

俺もCOBOLで飯食ってる部類なんだが、COBOL イズ　ナンバーワン的
書き込みには萎えるな。　
言語仕様以前の話なんだよな。COBOLソースを書いてる人達って、
コーディング思想を持ってないんじゃないか、と突っ込みたくなる。
で、コーディング思想なんて大げさに書いたけど、要はイメージなんだよね。
まっさらなところから或る仕様を出して新規にコーディングさせて、
他人が仕様からソースをスラスラ読めるコード書けるコボラーってホントはどれだけ
居るの？

198 ：124：2008/04/19(土) 17:14:45

まあ、偉そうな事書いたけど、結局ぶつかる所は、プログラムは工業製品か、って言う事。
確かに美しく、読みやすく、何をしたいのかイメージ出来るコードなら誰も文句は言わないが、
製造である以上、生産性・品質・コストって問題がつきまとう。
『何をしたいのかイメージ出来るコード』
って言うのを作るのは簡単なようで難しい。一回、仕様から自分の頭の中で描いたプロセスに
変換しなければならない。それやってると生産性が落ちる。やむを得ず仕様をそのままコードに
落とす。イメージしない。
イメージ＝モデル化と言ってもいい。
工業製品と、仕様をモデル化した人為的生産物との差を書きたかったんだが、上手く言葉が見つからないや。

199 ：デフォルトの名無しさん：2008/04/19(土) 17:16:55

脊髄反射でいいコードが書けるのがプロってもんだろ？

200 ：デフォルトの名無しさん：2008/04/19(土) 17:51:04

>>198
何一人で的外れなことを語ってるんだ。
ここはプログラム板であり、
スレタイがコボラー集まれ！なのであるから
コボル使用者が集まってコボルを褒め称えるスレなんだよ。
さあ、コボルのいいところをあげて賞賛しろ！

201 ：デフォルトの名無しさん：2008/04/19(土) 18:25:17

正直「○○ イズ　ナンバーワン」とか言うのってCOBOLerだけじゃねーのか？

しかもかなり本気でｗ

202 ：デフォルトの名無しさん：2008/04/19(土) 20:28:58

>>200
褒め称えるスレって、このスレタイから良く読み取れましたね。

203 ：デフォルトの名無しさん：2008/04/19(土) 21:06:22

＞さあ、コボルのいいところをあげて賞賛しろ！

ローカル変数やスコープの概念がないから、生産性が低く、ソースが読みにくいので
他の言語よりも工数を多くふんだくれる上に、品質が低くても言い訳ができる。

「大規模基幹システムにはCOBOLが最適」と大法螺を吹いて、
基幹システムにいつまでも寄生虫のように生きる事が可能。

若い人がまったく魅力に感じない言語なので定年までプログラマで食っていける可能性がやや高い。

204 ：デフォルトの名無しさん：2008/04/19(土) 22:18:34

君らが荒らしたい気持ちもわかる。
COBOLは登場時から絶対の存在だった。
COBOLを超えるものはCOBOL自身しかない。
後発の言語がいくら頑張っても敵わない、その悔しさは
わかるつもりだ。
しかし、プログラム開発に携わる者同士、互いの精神の
根っこは同じ所にあるはずだ。尊重し合おうではないか。

205 ：デフォルトの名無しさん：2008/04/19(土) 22:42:57

そろそろそのパターンの煽りもつまらなくなってきたなぁ。

COBOLerは本気で他の言語使いが羨ましがっていると思い込まないと
やっていけないほど精神的に追い詰められているのは哀れだな。

206 ：デフォルトの名無しさん：2008/04/19(土) 23:17:54

だってCやJava使いの人はいくら偉そうなこと言ってても
結局COBOLを使って基幹系を動かせないでしょ？
日本の社会は、俺たちCOBOLerの力で保っている。
ヤフーやアマゾンや新生銀行が数日止まったって
世の中に大した影響はないけど、メガバンクのATMや口座引き落としが
止まったら、大変なことになるからね。
他の言語の開発者とは、背負っているものが違うのだよ。
もっと言葉遣いに気をつけてくれないものか？

207 ：124：2008/04/20(日) 05:34:23

自称コボラーの発言、情けねえと自分自身感じないか？
>>164でも書いた通り、背負いたくて背負った訳じゃないんだぜ。
それしか選択肢が無かっただけ、なんだぜ。
今現在、新規開発案件（大小問わず）で、COBOLを選択してるプロジェクトが
有るなら、それを示せ。

208 ：デフォルトの名無しさん：2008/04/20(日) 06:56:46

>世の中に大した影響はないけど、メガバンクのATMや口座引き落としが
>止まったら、大変なことになるからね。

某メガバンクは合併の時に思いっきりATM&口座引き落とし止めてたじゃねーか？
今も日曜日止めまくりだし。

むしろCOBOLerがデカ口叩いて障害起こしてる現実に気がつけよ。

喪前が知らないだけで金融系基幹業務の内部は障害まみれだよ。

209 ：デフォルトの名無しさん：2008/04/22(火) 20:08:58

すみません、お聞きしたいのですが、
来月からプログラマーの職につくことになりました。
会社でCOBOLを使うことになりそうなのですが、
どこか基礎を学べるサイトはないでしょうか？
『COBOL　基礎』で検索したのですが、書籍の販売しか見当たりません。
本も買おうとは思っているのですが、後日の入社説明でテキストが渡されるらしく、
それを見てから買う本を決めたいと思っています。
とりあえずさわりだけでも勉強できるサイトを紹介していただけないでしょうか？
よろしくお願いします。

210 ：デフォルトの名無しさん：2008/04/22(火) 20:49:05

>>209
そんなに焦らなくても大丈夫。
プログラミングは実践あるのみだよ。
未経験者がWEBや本を読んで何か身に付くというものじゃない。
それに会社特有の開発環境やルールというものもあるから
むしろ最初は余計な知識を持ってない方がいい。
まずはその渡されるテキストに全力投球すべし。

211 ：デフォルトの名無しさん：2008/04/22(火) 21:02:46

>>210
優しいなあ。

>>209
まあ焦るな、がんばれ。210の言う通り。
困った事が起きたら、ここに書き込めば良し。

212 ：デフォルトの名無しさん：2008/04/23(水) 06:26:24

なんていいコボラー

213 ：デフォルトの名無しさん：2008/04/23(水) 09:15:55

>>208
Mほの統合ことかな？

F銀の勘定系システムがDK銀より優れていたのに「F銀のシステムはPL/Iなので
人員の動員が困難。うちのシステムはCOBOLなので技術者が調達しやすい」
とDK銀（F通）がごり押ししたらしいね。

214 ：209：2008/04/23(水) 10:44:41

>>210、211
返答ありがとうございます。
やる気を見せようかと思ったのですが、
そんな付け焼刃では鼻で笑われてしまいますよね、、、
最終的にはJAVAも覚えなければならないらしいので、
まずはテキスト、その後COBOLやJAVAの本を買って勉強してみようと思います。
ありがとうございました。

ＰＳ・ひょっとしたらわからないことが出てきたら聞き来るかもしれません。
そのときはよろしくお願いいたします。

215 ：デフォルトの名無しさん：2008/04/23(水) 20:20:28

エッ世の中こんなんでお金動いてんの？
みたいな金融システムって結構ある。

よく飲食店でバイトすると外食する気なくすと言うけど
まあなんつーか、アレと同じだ。

クレカなんて利用する気おきない。

216 ：デフォルトの名無しさん：2008/04/23(水) 21:02:24

>>215
クレカは自分の知る限りメガバンと同じく
メインフレーム＋COBOLで重武装しているところが大半の
はずなんだけど、そうじゃないの？

217 ：デフォルトの名無しさん：2008/04/23(水) 23:50:44

クレカのホスト＆COBOLerのコラボは凄いよな。
リリースの頻度がかなり凄いのでロクにテストもせずに本番動かしているから、
おおよそ週に１・２回障害が起きてる。

いまだにSNAが現役だしなぁ。色々な面で負の遺産だとｵﾓ。

218 ：デフォルトの名無しさん：2008/04/24(木) 00:42:04

>>209
ひとつアドバイス、勉強する為の情報源は複数持った方が良いですぜ。
本にしろWEBサイトにしろ、間違っていることもあるから。

219 ：デフォルトの名無しさん：2008/04/25(金) 06:39:56

バカな質問かもしれません。
COBOLでは今でも索引順編成ファイルなんて使うのですか。

220 ：デフォルトの名無しさん：2008/04/25(金) 10:00:46

スコープの概念はあって欲しいなぁ。
うちの汎用機のいわゆるオンラインプログラムの
メインロジックはMLIBを使い共通フレームワークに
しているのだけど、隠蔽したつもりのロジックに
飛び込まれたり使われたくない変数を弄られたりして
ボロボロになりそうになったことあるよ。

221 ：デフォルトの名無しさん：2008/04/26(土) 14:30:44

>219
あまり使っているプログラムを見たこと無いな。
試験には出るが。

ちなみに、
ＣＯＢＯＬで使うかはしらないが、
索引順次編成ファイル自体は普通に存在している。

222 ：デフォルトの名無しさん：2008/04/29(火) 05:23:59

PCで気軽に使えるスクリプトCOBOLが欲しいなあ。
COBOLはいい言語だけど、現代の開発文化からすると
DIVISIONの宣言とかちょっと冗長で堅苦しい部分もあるんで
そこいらを簡略化したバージョンで。
コンパイル不要なスクリプト言語であれば、運用現場で
ちょっとしたツールを書くのにも使える。

RubyやPythonもやってみたけど、やっぱデータの流れがMOVEやADDで
左から右へと自然に美しく書けるCOBOLは最強の言語だと確信した。
言語がやたら複雑になってしまった今こそ、COBOLが見直されるべき時。

というわけで、誰か作ってくれ。実用的なコンピュータ言語を作るには、
大学院クラスの専門理論とC言語の知識が必要みたいだからさ。

223 ：デフォルトの名無しさん：2008/04/29(火) 06:25:37

>>222
昔はオフコン用に少なくともメーカーの数はCOBOL簡易言語があったけれど、
全部死に絶えた。見直すというか、あってもいいと私も思う。・

224 ：デフォルトの名無しさん：2008/04/29(火) 08:44:12

COBOLから宣言部を削除してスクリプト化しても、
PythonやRubyに比べると「COBOLは汚くて複雑」としてコメントできんが。

225 ：デフォルトの名無しさん：2008/04/29(火) 08:46:25

>>222
おそらくちょっとしたツールの書く速度だとCOBOLとRuby/Pythonだと
後者の方が圧倒的に早いと思うが。

226 ：デフォルトの名無しさん：2008/04/29(火) 12:50:48

>>225
またそうやってコボラーをいじめるう。
COBOLほどシンプルで美しい言語はないって。
小文字キーワードの言語は目眩がするんだよ。

>>225
いや、そもそも俺はRubyやPythonでプログラムを
書けないから、書く速度で言えばスクリプトコボルが
圧倒的に早い。

227 ：デフォルトの名無しさん：2008/04/29(火) 20:42:48

＞いや、そもそも俺はRubyやPythonでプログラムを

この辺りの言語はそういう事じゃないよな。

基本的理念は別として、誰でも使えて気軽に書ける様に
なっているから、ある意味、非プログラマでも
簡単に書ける様になっているしなぁ。

生産性を言い出すとRubyやPythonはメチャ強い。
強いて言う弱点は速度とマイナーさ(?)だけだろうし。

228 ：デフォルトの名無しさん：2008/04/30(水) 04:15:06

>>227
生産性に関して言えばそうですね。以前は、生産性はPrologが独走していたと
思うけれど、現在はRubyの方が上でしょう。

229 ：デフォルトの名無しさん：2008/04/30(水) 12:08:34

言われてみれば、
unko.setFoo(shikko.getFoo());
より
MOVE SHIKKO-FOO TO UNKO-FOO.
の方が潔い感じですっきりかもね。

だがどうも文法が狭いというか貧弱なんだよなぁ＞COBOL

230 ：デフォルトの名無しさん：2008/04/30(水) 12:41:51

なんつーか普通に

foo = bar

でいいじゃん。
なんか無理に潔いとか言うのは苦しすぎだろ。

231 ：デフォルトの名無しさん：2008/04/30(水) 14:34:02

>>222
出たよ、作ってくれ。

232 ：デフォルトの名無しさん：2008/04/30(水) 22:09:05

>>229
いや、どう考えてもCOBOLのMOVE以上に簡潔で
わかりやすい代入の記述方法はないだろ。
幼稚園児が見たってわかるもの。
foo=barなんて、一般人からすれば「はぁ？」てなもんでさ。
この左から右への転写命令があるのは、他にはアセンブラの一部
くらいなのかな？
全く、世の流行は理不尽な方向に進むものだよなあ。

233 ：デフォルトの名無しさん：2008/04/30(水) 22:55:52

＞幼稚園児が見たってわかるもの。

無理だろ。

234 ：デフォルトの名無しさん：2008/04/30(水) 23:05:06

>>232
COBOL以上の簡潔かつ解りやすい言語で左から右言語にRPGがある

ただ、世の中の義務教育を終えた人間からすると、数式の記述は
foo = barの方が圧倒的に理解しやすい。


つかCOBOLerは他の言語をロクに知らないクセに相手を全否定すんなよ。
ｶｺﾜﾙｲ

235 ：デフォルトの名無しさん：2008/05/01(木) 06:01:09

>>234
「最も美しいプログラム言語は?」っていうスレがある。
ここに、
・　被代入項が左側に固定した言語は失格! を加えることにしよう。
破壊代入がいけないとは思わないが。

236 ：デフォルトの名無しさん：2008/05/01(木) 07:00:10

「最も美しいプログラミング言語は?」 だね。
http://pc11.2ch.net/test/read.cgi/tech/1153320716/

237 ：デフォルトの名無しさん：2008/05/01(木) 23:16:54

＞・　被代入項が左側に固定した言語は失格! を加えることにしよう。

とりあえず人間失格な発言と言うのは理解できる。

238 ：デフォルトの名無しさん：2008/05/02(金) 06:16:47

Rubyは結構使ってるな俺は。う〜ん…
Ruby用に、Pictureクラスでも作ってみようかな？

239 ：デフォルトの名無しさん：2008/05/02(金) 14:39:04

>>238
いいねえ、その調子で、RubyをCOBOLライクに
使うクラス群を作れないもんかな。MOVEクラスとか
PERFORMクラスとか。
そうすりゃ俺だってRubyを使えるようになるかも知れん。
今のRubyはコボラーには難し過ぎる。

240 ：デフォルトの名無しさん：2008/05/03(土) 02:33:23

コボルの質問です。

2バイトの領域に格納されている１文字（日本語などの2バイト文字）を
16進表記でDISPLAY文で出力したいのですが、どうやったら出来るんでしょうか？

241 ：デフォルトの名無しさん：2008/05/03(土) 04:22:41

>>240

そういう低級なことはできません

242 ：デフォルトの名無しさん：2008/05/03(土) 05:33:11

>>241
簡単だろ？
バイナリ→16進文字列変換は組む必要ありそうだが。

243 ：240：2008/05/05(月) 01:34:28

>>242
結局のところどうやるんですかね？

01　MOJI　PIC　X(02).

MOVE　X'4040'　TO　MOJI.
DISPLAY　MOJI.

単純に文字コードを16進でみたいだけなんですけど
上手く行かなくて。

DISPLAY文に何か設定しないと見れないんですかねぇ。
スレ違いなら他のところで聞きますが。

244 ：デフォルトの名無しさん：2008/05/05(月) 03:54:54

>>243
01 ATOM-1 PIC X(2).
01 ATOM-2 REDEFINES ATOM-1.
02 ATOM-3 PIC 9(4) USAGE COMUTATIONAL.
01 TABLE-1 PIC X(16) VALUE "0123456789ABCDEF".
01 TABLE-2 REDEFINES TABLE-1.
02 X-0 PIC X OCCURS 16 TIMES.

のようなWORKING-SECTIONの定義はいりますよね。
あとは、ATOM-3を256で割り、
その答えと剰余をまた16で割ってとやっていけばいいんでしょう。
そこで出てきた4つの解からX-0[KAI]でHex文字を引けばよい。

245 ：デフォルトの名無しさん：2008/05/05(月) 03:56:45

ごめん!
X-0(KAI +　1) 　から引けばよい。でした。

246 ：デフォルトの名無しさん：2008/05/05(月) 04:12:27

ますますごめん!
WORKING-SECTION ではなくて WORKING-STRAGE SECTION.　ですね。
2年くらい前にopen-cobolをインストールしてみてそのあと使ってみたのが
18年ぶりで、1週間使っただけでまた空いてしまった。
ほかにも、へんなこと言ってるかも知れない。

247 ：デフォルトの名無しさん：2008/05/05(月) 04:13:38

あった。　COMUTATIONAL -> COMPUTATIONAL

248 ：仕様書無しさん：2008/05/05(月) 15:50:15

すみません初心者なんですが質問です。


DISPLAY "COUNT =" CNT

なんですが・・・
日本語で説明するとどういうことになるんでしょうか？
"COUNT ="

どうして　＝　まで　"　でくくるのでしょうか？

初心者過ぎて申し訳ないですが、もし分かる方いたらお願いします。

変な質問をしてしまってすみません。

249 ：デフォルトの名無しさん：2008/05/05(月) 16:29:05

うわっ、懐かしいなぁ、ＣＯＢＯＬ！

250 ：デフォルトの名無しさん：2008/05/05(月) 22:48:04

>>248
ダブルコーテーション”〜〜”で挟んだ部分は文字列として表示されるだけ。
DISPLAY命令で、変数CNTだけ記述すると、その値が表示されます。
表示結果を見ても、この値が何の変数の値なのか分かりませんよね。
その為に文字列COUNTをあらかじめ先に表示しておく。＝を付けるのはその人のセンスです。
＝の代わりに：にする人もいます。

251 ：240：2008/05/05(月) 23:34:58

>>244
どうもです。
しかしこんな手間をかけないと出来ないものなんですね。
不便ですねぇ。

252 ：デフォルトの名無しさん：2008/05/05(月) 23:51:55

>>251
不便とか言う人は、COBOLの本質をわかっていない。
バイナリーデータを扱う機能があるのは
ハードに近い原始的な言語と相場が決まっている。
COBOLは業務処理を書くために高度に進化した言語だから、
そういう余計な機能はないのだよ。

253 ：デフォルトの名無しさん：2008/05/06(火) 03:35:55

リテラルもわからない人に本質云々の話をするなよ

254 ：253：2008/05/06(火) 03:42:01

申し訳ありません、間違えました。吊ってきます。

255 ：デフォルトの名無しさん：2008/05/06(火) 07:08:34

>>251
COBOLの REDEFINES句 にはアセンブラ的なデータ構造と
いうか、アセンブラ的データ認識が見え隠れします。
しかし、どの言語でも、たとえばC,C++,C#,Java,PHPなどですが、
やることはほとんど同じです。それが「公式」のライブラリに
登録されているか、いないかの違い。COBOLでも企業に入れば
同様のものが必ず用意されています。誰が書いたかの違いで、
企業の場合は先達が書きました。公式ライブラリの場合は、
言語仕様に則って処理系の作成者が書きました。

256 ：240：2008/05/06(火) 14:49:07

>>255
てっきりＣ言語のprintf関数のようにフォーマット指定子%xのような感覚で
DISPLAY文にちょこっと何か加えるだけで16進数表記になるのかなと思って
いたので不便だなぁと思いました。
不便と言うかめんどくさいなぁと。

会社にこういうユーザライブラリあるのか判りませんが、とりあえずＤＥＢＵＧ時
にコード確認したいだけなんで自分で組もうと思います。
テスト用スタブにちょろっと組むだけなんで。

257 ：仕様書無しさん：2008/05/06(火) 18:18:50

２５０さん

ありがとうございます！かなり理解できました！

258 ：デフォルトの名無しさん：2008/05/07(水) 11:55:07

>>256
COBOLを覚えてからFORTRANを習ったので、format付きprintがうらやましかった。
20年以上前だけれど、私の職場ではこれを真似て、
CALL "PRINT" USING FORMAT-1,DATA-1.
とかを使っていた。

259 ：デフォルトの名無しさん：2008/05/07(水) 15:52:08

COBOLのコンパイラを探してるんだけど、フリーでないかな？
再配布が可能で、エディター付なら最高なんだけど。

260 ：デフォルトの名無しさん：2008/05/07(水) 23:29:19

>>259
http://labs.netbata.com/cobol/

261 ：デフォルトの名無しさん：2008/05/08(木) 14:53:10

>>259
OpenCOBOLをLinuxで使ってるけれど
何の不満もない。

262 ：259：2008/05/09(金) 08:25:04

ごめんなさい。エディターは付かない方が良かったです。
これって再配布は可能なんですか？

263 ：デフォルトの名無しさん：2008/05/09(金) 08:53:51

>>262
知らない。>>260にホームページが載ってるからライセンスのところを
読んでみたら。私は職場での「一発完動」手品のトリックとして使って
いるだけだから。

264 ：デフォルトの名無しさん：2008/05/10(土) 16:41:11

Microsoft .NET Framework 用 COBOLってのがあるんだね？
http://www.microsoft.com/japan/msdn/net/general/pdc_cobol.aspx

実績がある言語だけに、これからもコボラーとしてやっていけるんだね。
安心したよ。

ＣＯＢＯＬはなくならない気がする。っていうか進化していく気がする。

コボラーばんざい！！

265 ：デフォルトの名無しさん：2008/05/10(土) 19:26:01

自虐ネタだと思うが、本気で言っているなら.NETの仕事には関わらない方がいいぞ。ｗ

266 ：デフォルトの名無しさん：2008/05/10(土) 19:38:17

>>264
だからメガバンのシステム子会社に入れって逝ってるだろ。
あと百年はメインフレーム＋COBOLでメシが食える。
オープン系に比べ、親会社から高い単価で仕事もらえるしな。
最近はCOBOL技術者が減っているから職場でも大事にされるよ。

267 ：デフォルトの名無しさん：2008/05/11(日) 02:22:29

おれいやいや.NET系のアプリ開発に関わってるけど、この間先輩に
「このコボルくせぇコーディングやめてくれ」っていわれちゃった。

268 ：デフォルトの名無しさん：2008/05/11(日) 06:54:44

>>266
だからメガバンのシステム子会社のCOBOLer見てるけど、
アレが大事にされているとは思えない。
あと数年でクビを切る気マンマンに見える。

単価が理不尽に高いのは解るが。

269 ：デフォルトの名無しさん：2008/05/11(日) 11:18:24

COBOLer と揶揄されるのは、COBOL 以外の言語を使えもしないし、使えるようになる気すらないからで、
他の言語もバリバリにできるようになればそんな馬鹿にもされないし、潰しも効く。

270 ：デフォルトの名無しさん：2008/05/11(日) 15:36:28

ウチの部署はＡＳＭじゃないと保守できないとか言われたな。
次のプログラムはＣＯＢＯＬで作るけど。

よその部署では、
自会社のＣＯＢＯＬｅｒを集めずに
中国企業のＣＯＢＯＬｅｒを仕入れている所を見ると
コスト要因と指揮系統の問題か。

271 ：デフォルトの名無しさん：2008/05/11(日) 20:05:46

＞他の言語もバリバリ
なんて出来る人はとっくにCOBOL捨てている人が多い点について。

272 ：デフォルトの名無しさん：2008/05/11(日) 20:08:54

COBOLer が希少価値になってきてるから
スキマ産業的に COBOL やってる人もいるかもしれないじゃないか！

273 ：デフォルトの名無しさん：2008/05/11(日) 20:09:57

>>271
給与の高い方を取るケースも多いだろう。

274 ：デフォルトの名無しさん：2008/05/11(日) 20:12:19

ウチの会社はCOBOLの案件は中国に回すとか言ってるけど。

もう、COBOLは希少価値どころか値下がり中です。

275 ：デフォルトの名無しさん：2008/05/11(日) 20:16:45

中国に金融機関の中枢任せちゃって大丈夫なの？

276 ：デフォルトの名無しさん：2008/05/11(日) 20:55:25

悲しいがそれが現実なんだ。
とくにＦあたりなんか積極的に中国だすぞー！って意気込んでますよ。

日本受入後検査（IT、STフェーズ）で泣いた日本人SEがどんだけいるか。

277 ：デフォルトの名無しさん：2008/05/11(日) 20:58:59

近視眼的だなあ。
国防意識ないのかな。

278 ：デフォルトの名無しさん：2008/05/11(日) 21:26:06

マッチ擦るつかのま海に霧ふかし

279 ：デフォルトの名無しさん：2008/05/11(日) 21:43:21

>中国に金融機関の中枢任せちゃって大丈夫なの？

すでに一部の金融系は任せているな。

正直未来がないと思うんだけど、最近流行だしな。


ただ、金融系業務で国防どうこう言うほどの高レベルを要求される仕事でないのも事実だな。
テンプレート埋めるだけの単純作業なんざアフォでも出来る作業と言われればそれまでだし。

280 ：デフォルトの名無しさん：2008/05/11(日) 21:47:29

いや、変なコード仕込まれたらとかさ。

281 ：デフォルトの名無しさん：2008/05/11(日) 22:13:34

某証券会社は上海にどっぷり w

282 ：デフォルトの名無しさん：2008/05/11(日) 22:45:29

＞いや、変なコード仕込まれたらとかさ。

逆にCOBOLだから仕込み様がないと思うが。

C++やらJavaとかで変にカプセル化&継承とか使いまくって
たら気がつきにくいかもしれんが。

そういうセキュリティの穴を仕組まれそうなトコにCOBOLerの出番はないだろ。

283 ：デフォルトの名無しさん：2008/05/12(月) 21:41:29

やっぱ、コボラーはダメなんかな…
漏れコボルしか知らへんし…
困ったのぉ…

284 ：デフォルトの名無しさん：2008/05/13(火) 08:49:29

>>283
だから言ってるじゃん。
メガバンのシステム開発を受託してるシステム会社に入れって。
日本を支えるメガバンの巨大システムは、オープン系なんかじゃ
置き換え不可能だから、COBOLで一生食っていける。

285 ：デフォルトの名無しさん：2008/05/13(火) 20:16:38

某メガバンが早速障害を起こしてマスゴミに叩かれたワケだが。

まあ個人的にはアレはどっちも悪いとは思うけど。

286 ：デフォルトの名無しさん：2008/05/13(火) 21:55:53

>>285
COBOL自体に問題があるわけではないさ。
みずほも糖蜜も、障害の原因はインターフェースがらみ。
システム開発で一番障害が起きやすいところだ。
なにせ本番と全く同じ環境であらゆるケースのテストなんか
できるわけがないのだから、ある程度の障害は仕方ないんだよ。
しかるべき人が頭下げて終わりだ。

287 ：デフォルトの名無しさん：2008/05/13(火) 22:08:14

こういう考えだからCOBOLerは嫌われてるんだろうなぁ。
ロクにユニットテストせずに「○○に問題がある！」と主張する。

一番問題なのはCOBOLerの脳だと思うが。


ただあのネタに関しては今ある情報だとメガバンではなくてセブンの方が悪いと感じるけどな。

で一番悪いのはマスゴミだろうけど。

288 ：デフォルトの名無しさん：2008/05/13(火) 23:29:06

YPSの糞エディタ死ね

289 ：仕様書無しさん：2008/05/14(水) 00:10:54

PROCEDURE DIVISION.
OPEN OUTPUT F1.
PERFORM UNTIL CNT = 100
INITIALIZE W1R.
ACCEPT WTIME FROM TIME
PERFORM VARYING S FROM 1 BY 1 UNTIL S > 5
ADD 1 TO CNT
ACCEPT WTIME FROM TIME.
MOVE CNT TO W-CNT(S)
MOVE HH TO W-HH(S)
MOVE MM TO W-MM(S)
MOVE SS TO W-SS(S)
　　　　　　　　　END-PERFORM
　　　　　WRITE F1R FROM W1R
　　　　　DISPLAY W1R


すみません・・・質問です。
このコーディング文なんですが・・・
フローチャートにするとどうなるんでしょうか？

290 ：デフォルトの名無しさん：2008/05/14(水) 03:31:15

>>289
CNT=100が気になる。

291 ：デフォルトの名無しさん：2008/05/14(水) 06:41:47

>>289
まずフローという意味がわかっているのかな？

「そのまんま」としかいいようがないんだけど。

292 ：デフォルトの名無しさん：2008/05/14(水) 07:03:55

>>289
ゼロクリアしろよ
うえのACCEPTいるか？
END PERFORMが足りん
学生さんかな。

293 ：デフォルトの名無しさん：2008/05/14(水) 21:30:12

>>288
ＹＳＰコボルか…
懐かしいのう…あれは中々癖が強うもんやさかい…
漏れはもういいや…

294 ：デフォルトの名無しさん：2008/05/14(水) 21:45:43

>>289
何がしたいのかようわからへんが、
２つ目のACCEPT文のピリオドがいらへん
その前ににACCEPTは１つでよさそうやなw
あと外側のEND-PERFORMが足りない
初期化が最初のPERFORMの前に行うのがコボラーらしくてええわw

漏れもダメコボラーや、一緒に頑張ろうやwww

295 ：デフォルトの名無しさん：2008/05/15(木) 12:14:58

PROCEDURE DIVISION.
*
*Ｆ１ファイルを出力モードで開く
OPEN OUTPUT F1.
*
*ＣＮＴが１００になるまで以下の処理を行う
PERFORM UNTIL CNT = 100
*Ｗ１Ｒ（Ｆ１ファイルのレコードエリア）を初期化
INITIALIZE W1R
*システム時刻を獲得（この処理いらない）
ACCEPT WTIME FROM TIME
*添え字Ｓが５以上になるまで以下の処理を行う
PERFORM VARYING S FROM 1 BY 1
UNTIL S > 5
*ＣＮＴに１を加算
ADD 1 TO CNT
*システム時刻を獲得
ACCEPT WTIME FROM TIME
*Ｗ１Ｒ（Ｆ１ファイルのレコードエリア）の各項目編集
MOVE CNT TO W-CNT(S) *>CNT(件数？)
MOVE HH TO W-HH(S) *>システム時
MOVE MM TO W-MM(S) *>システム分
MOVE SS TO W-SS(S) *>システム秒
END-PERFORM
*Ｆ１ファイルへレコードを書き出す
WRITE F1R FROM W1R
*Ｗ１Ｒ（Ｆ１ファイルのレコードエリア）を
*（画面又は帳票に）表示する
DISPLAY W1R
END-PERFORM.

296 ：295：2008/05/15(木) 12:15:49

>>289

COBOL一筋15年の自分が通りますよ。
フローでここにアップするのは、ちと難しそうなので
>>295でネスト、ピリオドをきれいにして、各処理にコメントつけてみました。

297 ：デフォルトの名無しさん：2008/05/16(金) 10:05:39

>>289 PAD知ってるか？
ちゃんとしたコーディングなら、DATA DIVISIONもENVIRONMENT DIVISIONも必要。
フローチャートにしても、どうにもならん。
これから、左のインデントは全角のスペースで統一にしてくれ。

298 ：デフォルトの名無しさん：2008/05/16(金) 10:09:04

>>296
つか、いいヤツだなw

299 ：デフォルトの名無しさん：2008/05/16(金) 17:06:24

くだらないコードを解説するんじゃないよ（あはははははぁ〜）

300 ：仕様書無しさん：2008/05/18(日) 03:24:55

返事がおそくなってごめんなさい。
ありがとうございます。

分かりました。
フローっていう意味はわかってたんですがコーディング書いてると２ｃｈにのせれなくて

一回目のアクセプト文がいるのかいらないのかわけがわからずでしたがありがとうです。

２９５さん親切ですね。
何かあったらまた質問します。

301 ：デフォルトの名無しさん：2008/05/19(月) 14:29:02

４１歳の地方コボラーだが、とにかく地方はＣＯＢＯＬの仕事ないから、ＪＡＶＡの勉強始めた。
ストラッツを本見ながらやっているが、ＷＥＢ系は難しい〜。
ＪＡＶＡ系のエンジニアがコボラーをバカにする理由がわかった気がする。

302 ：デフォルトの名無しさん：2008/05/19(月) 17:05:46

>>301
OOの概念を掴んでからやらんと壁にぶつかるから気をつけろ。
で、新規に勉強するのに何故に今更Struts？
てかStruts2？

303 ：デフォルトの名無しさん：2008/05/19(月) 18:08:33

>>302
301です。ＪＡＶＡ詳しそうですね。
えぇ〜Strutsってもう古いんですか？
書店にStrutsのＷＥＢアプリケーション開発関連の本があったから買ったんですよ。
イクリスプ上でのＪＡＶＡ開発環境の最新は、ＷＴＰって本に書いてあったんですが、現場で最低限必要な知識って？

304 ：デフォルトの名無しさん：2008/05/19(月) 19:20:46

当たり前だがWebアプリなんだからhtmlは最低限読めないとお話にならんと思うが。

JavaはWebアプリからじゃなくて、普通にコンソールアプリで
COBOL程度の事は出来るようにならんとWeb系は辛いと思う。
マルチスレッドでサーバープログラミングしろとは言わんが。

JSFみたいに解らなくても出来るのはあるにはあるけど、基本はhtmlで、
そのうちにJSPやservletと来て次にStrutsかJSFっていけばいいと思う。

305 ：デフォルトの名無しさん：2008/05/20(火) 00:52:08

コボラにお聞きするが、コボルとＶＢで新入社員研修で使えるのはどっち
さらに、今後しばらく案件がありそうなのはどっち？

306 ：デフォルトの名無しさん：2008/05/20(火) 11:28:50

>>303
StrutsはいわばJavaのWebフレームワークにおける
レガシーデファクトスタンダードという位置づけだ。

既にStrutsで作られたシステムの改築というなら
ともかく、新規案件を想定しているならStruts採用には
疑問符がつく。(Struts1.xの話しね）

>>304氏の言うように、COBOLと同程度のことが
出来なくてはならんというのはWebやる前の前提条件。
Javaのバージョンに気をつけろ。1.5以上を理解しろ。

あと、OOは理解しとかないと辛い。クラス図をちゃんと
読めないと、必ず壁にブチ当たる。

COBOL的に言うと、01レベルの記憶領域に操作コマンドが
付着したものが、メモリ空間にポンポン打ち出されていくような
イメージなんだけど、最初は理解に悩むかもね。

Webフレームワークは、個人的にはJSFの方が良いと思う。
理由は「Java標準」だから。ちなみにStrutsの原作者が
二度目に作ったWebフレームワークだ。

Webフレームワークの次は、ORMを学べ。データベースと
オブジェクトの同期を楽にするフレームワークのことだ。

んで締めくくりにDIxAOPかな。SpringとかSeasar2ってやつね。

ここまでやったら、Javaで飯が喰えると思う。

307 ：デフォルトの名無しさん：2008/05/20(火) 12:39:19

>>304 306
最低限のhtmlは読めます。昔ホームページをhtmlで作ったことがあるから。
JSFですねやってみます。
けど、後２〜３年後にはまた新しいフレームワーク出てくるんだろうなぁ〜。
まずは、新しいフレームワークが出てきても対応できる基礎的なものを勉強したい。

308 ：デフォルトの名無しさん：2008/05/20(火) 16:21:13

>>305
COBOLの案件ってのは、大規模システムの基幹に関わるような要件じゃないと無い気がする。
案件については、各企業の事業経歴によるだろうけど、一般的にはVBの方が使えると思うよ。
VBと言えば、.NETが主流になりつつあるけど、クラスはともかく、構造体の概念さえ分かれば
COBOLの仕事をさせるのも、それほど難しくはないだろうし。

309 ：デフォルトの名無しさん：2008/05/20(火) 23:59:28

いろいろ問題あるもののMU銀行さんがシステム統合（いちおう）おわったってんで
大量のコボラさんがいま解散、散り散り＆職探し状態。
なんかないっすか、って連絡がよくくるんだけどさ、
まあ、びっくりするくらいないんだわ（苦笑）

310 ：デフォルトの名無しさん：2008/05/22(木) 03:47:26

タレントの巨泉が言ってた、選挙に出ない方がいい人が居るって。

311 ：デフォルトの名無しさん：2008/05/22(木) 22:01:37

いやー、Javaを勉強してるんだけど、あれはないわ。
記述が冗長すぎる。冗長さではCOBOLも大概のモンだと
思ってたけど、Javaはその上を行く。
バッファードリーダービーアールイコールニュウ
バッファードリーダー・・・てな調子で、どこで息を吐けば
いいんじゃ、てなくらい一行が長い。
こんなもんを日々やらされている人はお気の毒。
しみじみコボラーでよかった。

312 ：デフォルトの名無しさん：2008/05/23(金) 03:44:29

元金融系のCOBOLerですが、
適材適所で使い分けてたな。
ALL COBOLじゃ無理だし。

ASMやCも使ってました。

某社の勘定系は、30年以上前のソースを未だに手直ししてるし。

誤差無し演算が18桁というのは金融系ではあるいみ強みだったと思う。
今は31桁だっけ?

313 ：デフォルトの名無しさん：2008/05/23(金) 12:24:04

>>311
そんな超絶初級レベルの段階で全てを悟るのは、Javaがある程度わかっている人間から
すると「だからコボラーは頭おかしいのか」といわれる原因だと思う。

そして現状仕事でやる人間はそんなコードは日々書いていない。

漏れはある程度、仕事で言語を選択できる部署の人になっちまったのだけども、
もう、好き好んでCOBOLは書かなくなっちゃったなぁ。つかむしろ避ける。

Python、Java、C++、SQLで過去の遺産(COBOL)は塗り替えたしなぁ。

314 ：デフォルトの名無しさん：2008/05/23(金) 13:38:18

>>311

だからOOを理解していないと、今自分が何やってるのか
判らなくなるんだってばさ。

BufferedReaderが何故二回出現するのか理解してないでしょ？

Reader reader = MyReaderFactory.getTextReader("myText.txt");

ま、がんばれや。そのうちスラスラ出来るようになる、ｶﾓｼﾚﾝ。

315 ：デフォルトの名無しさん：2008/05/23(金) 20:39:36

基礎中の基礎は独学してみたが、この後ＪＳＰサーブレット、フレームワーク………
週末勉強で独学じゃまともに使えるようになるのは何年かかるか検討もつかん

316 ：デフォルトの名無しさん：2008/05/23(金) 22:49:17

単にWebアプリを作りたいとか言うだけならPHPやらRubyの方が敷居は低いと思うが。

今後はCOBOLの案件が増えることはないだろうから今後の飯のタネに
Javaを覚えようとするのは悪くはないと思うが、学習する時間がないなら、
RubyやPythonみたいな比較的学習コストが安い言語にした方がいいのでは？

317 ：デフォルトの名無しさん：2008/05/23(金) 23:11:48

Javaに比べて、RubyやPythonの案件なんてあるの〜？
あっても、プラットフォームはUNIX or Linuxだよね？

318 ：デフォルトの名無しさん：2008/05/23(金) 23:36:48

COBOLか・・・

何もかも皆懐かしい・・・

319 ：デフォルトの名無しさん：2008/05/24(土) 08:34:34

>>317
Rubyは日本でも普通にある。
Pythonは海外では普通にあるし。

あとJavaと比較するのはあんま意味ないとは言わんがどーかと思う。
それこそ「Javaと比べてVB(C#/C++)の案件なんてあるの〜？」と同じ意味で、
プログラマー人口(?)が最も高い言語との比較したら、この世の案件は全てJavaになるんだが。

むしろRubyを提案する方がJavaについていけないCOBOLer向けだろう。
「Ruby/Pythonなら漏れでもOOっぽい事ができますた！」ってノリで。

320 ：デフォルトの名無しさん：2008/05/24(土) 16:02:48

COBOL＆JCLでの開発、運用経験のある人に質問です
「汎用機オペレータは無能」スレの方にCOND氏という人がいまして、
JCLで組んだジョブはアベンドしてもこけない（止まらない）
CONDでコントロールするから、等、不思議発言を繰り返してまして
何かうそ臭いかなぁ、と

興味のあるメインフレーマーの方はROMってみてください
結構荒れてますが

そういう特殊なJOBってあるんですか？

321 ：320：2008/05/24(土) 18:06:54

解決しました
すごくくだらないオチでした
興味がある方はどうぞ

322 ：デフォルトの名無しさん：2008/05/24(土) 20:00:45

笑えるというかなんというか、まあオペレータはあんなモンだろうけど、
COBOLerもたいして変わらんから、仲良く汁。

323 ：デフォルトの名無しさん：2008/05/25(日) 17:21:31

質問!
何でアホみたいに予約語有るんですか!
しかも、名前管理面倒なんで外部ルーチン多用したら往年のCOBOLerさんは煙たがりやがりますか!

324 ：デフォルトの名無しさん：2008/05/27(火) 19:40:37

上のほうにある「PERFORM飛ばし」ってのはいわゆるCのGOTO文みたいなものかい？

325 ：デフォルトの名無しさん：2008/05/27(火) 21:35:47

>>324
いんにゃ。行って帰ってこいですわ。
サブルーチンです。

326 ：デフォルトの名無しさん：2008/05/27(火) 23:13:39

BASICで言う
GO SUB 〜RETURNか・・・

327 ：デフォルトの名無しさん：2008/05/27(火) 23:17:16

内PERFORMもたまには思い出してやってください。

328 ：デフォルトの名無しさん：2008/05/29(木) 03:53:38

おいらが入っていた金融機関では、殆ど外PERFORMでした。
処理毎に標準化されていたし(変数名からセクション名)。

仕様書は、YACCIIでした。

329 ：デフォルトの名無しさん：2008/05/29(木) 16:07:08

書き込みで「Ruby/Pythonなら漏れでもOOっぽい事ができますた！」ってかいてあるけど、ここに出てくる"OO"って何なの？
コボラーなオイラに教えてくれ。

330 ：デフォルトの名無しさん：2008/05/29(木) 17:22:15

オブジェクト指向

331 ：デフォルトの名無しさん：2008/05/29(木) 18:29:37

つうか、現場のコボラはCobol2002で
オブジェクト指向機能が組み込まれたことも
知らんのかな？
（使える機能かどうかは別問題だが）

332 ：デフォルトの名無しさん：2008/05/29(木) 19:18:17

外PERFORMでものすごい細分化したあるソースでEXITの次は/(改ページ）コメント。
知らずに印刷したコンパイルリストが200ページ以上。

作った奴を呪ってやりたかった。

333 ：デフォルトの名無しさん：2008/05/29(木) 20:41:16

>>309
そうなんか・・・
確かに最近じゃ案件が少なくなっているって
営業さんが嘆いているのを帰社するたびに聞いているから・・・

334 ：デフォルトの名無しさん：2008/05/29(木) 23:00:44

>つうか、現場のコボラはCobol2002で
>オブジェクト指向機能が組み込まれたことも
>知らんのかな？

正直ウチのホスト/オフコン屋は全員知らん。

オブジェクト指向=Java/C++ってなんとなく思ってるくらいで
自分には関係ない世界、と認識している。

335 ：デフォルトの名無しさん：2008/05/29(木) 23:29:17

ぶちゃっけ、COBOLでOOPができても仕方ないんじゃないかと思う。
過去の資産にできるだけ手を入れないで使いたいわけだから…
別のコンパイラを使わなきゃいけない、内PERFORMすらほとんど使わんよ。

336 ：デフォルトの名無しさん：2008/05/30(金) 02:23:29

COBOL2002でオブジェクト指向機能が組み込まれた事は知っている。
知っていても、コーディング規則＆ソースレビューで弾かれる。
それを語ってるのが>>335
COBOLに新しい機能がついても、それを採用するかどうかは親方次第。
部分参照すら、未だにマトモに使えないコボラーが居る始末じゃ
どうしようも無いな。

部分参照は基本項目にのみ用いるべし。
集団項目に用いる椰子は死んでよし。

337 ：デフォルトの名無しさん：2008/05/30(金) 02:33:51

COBOL覚えたいんだけど
本屋に行ってもないんだよ
どんな本買えばいいの？

338 ：デフォルトの名無しさん：2008/05/30(金) 05:49:48

>>337
ジュンク堂みたいなとこ逝けば、かなりの数ある。
でも、地方だとしたらAmazonかな。

ただ、COBOLってメーカー固有の環境・方言込みで憶えないと
使えんので、マニュアルを読むのが大基本だぞ。

339 ：デフォルトの名無しさん：2008/05/30(金) 09:51:53

30代40代コボラー！！
今の５０代がいなくなったら天下が取れる。
何だって若い奴らはやりたがらないから。
底辺でまったりドブさらいみたいな仕事でもいいやつはＣＯＢＯＬを続けろ。
今から、４０代のやつがＪＡＶＡとか始めても意味なし！！
５０代でＪａｖａ使えても仕事は殆ど無いよ。
俺は、４０代ＣＯＢＯＬで定年までしがみつく！！

340 ：デフォルトの名無しさん：2008/05/30(金) 10:23:01

オブジェクト指向の特徴であるカプセル化などは
「作る側の思想」で盛り込まれたものであり、
「読む側の思想」は無視されている。
全てのクラス定義内容・クラス間の依存関係を
完全に理解してからでなければ、一行たりとも
読み進むことができない。それがオブジェクト指向言語。
事実上、作った本人でなければ保守はできない。

何も考えず上からズラズラと読んでいけば
誰でも理解できるCOBOLとは相容れないものだ。

341 ：デフォルトの名無しさん：2008/05/30(金) 15:07:39

>>333

三○UFJはシステム統合のために５千人だか６千人だかの技術者を集めていたからね。
（cobolerだけじゃないけど）
それを一気に解散させたら、そらバブルも崩壊する罠。

皮肉なのは能力がなくて早々に切り捨てられた技術者たちが
開いている隙間をうまくついて新しいプロジェクトを見つけたのに対し、
老体鞭打ってギリギリまでがんばったcobolerさんたちに限って
案件なくて無職で苦しんでいるということ。

派遣はつれーなー笑

342 ：デフォルトの名無しさん：2008/05/30(金) 20:55:32

24歳のコボラーがとおりますよ
基本しかまだ知らないけど

343 ：デフォルトの名無しさん：2008/05/30(金) 23:57:46

＞何も考えず上からズラズラと読んでいけば
＞誰でも理解できるCOBOLとは相容れないものだ。

現実問題だけど、漏れの知り合いが15年以上前のシステム(COBOL)を
メンテしてるんだけど、明らかに理解に費やす時間が近年の仕組みに比べて
時間がかかるんだが。

つか、COBOLerの釣りには飽きた。

344 ：デフォルトの名無しさん：2008/05/31(土) 04:55:49

「上からズラズラと読むだけで理解出来る」程度の内容で仕事になるCOBOLの偉大さでもある
冗談じゃなくそんな案件がまだまだそこそこあるからね
一件無能なCOBOLerも、歴次第で信用得れますし。

50代で骨董的な過去の有名システム保守したコボラーの給料は
20代のガッコでOOP知識を学んだ程度で現場に回された実績皆無なコボラーと一桁違うのです

たかが一桁でも子供養えるんですね

石油資源のごとく、いつ尽きるかという不安はありながら当面尽きない事もみんな判ってるのである

345 ：デフォルトの名無しさん：2008/05/31(土) 08:04:12

COBOLerが無能の割りには高級取りってのは認めるけど

＞20代のガッコでOOP知識を学んだ程度で現場に回された実績皆無なコボラーと一桁違うのです
こんなヤツは見た事ない。

商業高卒の女性で学生時代COBOLやってたそのまま銀行子会社へ、ってケースは
見た事あるけど、会社規模＆学歴に準じた給料だったなぁ。

ただちょうど漏れがCOBOLシステムからJavaシステムに移行してしまったので、
また勉強やりなおし、っつーか、頭固いんだよな。

行員だけだは「便利になった」と喜んでいるんだが、銀行子会社のエンジニアは難色してしていたし。

MUFJは漏れもちょっと関わったけど、管理者からすると老人COBOLerは
普通に嫌われていたよ。あいつら自分から動かないしバグがでても「昔の人がやった
部分だから俺ｼﾗﾈ」だし、なんであんなヤツに高い単価払っているか理解できん。と
よく漏れに愚痴をこぼしていた。

346 ：デフォルトの名無しさん：2008/05/31(土) 11:55:43

つまりコボラーは頭が固いと、頑固だと

347 ：デフォルトの名無しさん：2008/05/31(土) 12:00:14

うむ、俺はコボラーだから
これからＡＳＭを覚えてメンテしていかなきゃと思うと頭痛だ。

348 ：デフォルトの名無しさん：2008/05/31(土) 12:18:10

COBOLと言う言語に関してどうこう言う気はないが、４０や５０にもなって
プログラマーってかなり使えない人間の証明に思えるんだが。

349 ：デフォルトの名無しさん：2008/05/31(土) 12:59:41

Java厨の遠吠えが情けないな。
単価が高いということは、それだけCOBOLシステムの
価値が高いと認識されているからだ。
それを素直に認められない人はこの世界で通用しない。
悔しければ自らが精進し、COBOLシステムを駆逐するほどの
価値の高いシステムを作り、評価を得ればよい。
人を貶めるんじゃなくてな。

350 ：デフォルトの名無しさん：2008/05/31(土) 13:14:32

世界で通用していない人の言う事には説得力がありますな。（ﾌﾟ

つか、今現在でCOBOLが駆逐されつつある現実を認められない人はこの世界で通用しない。

351 ：デフォルトの名無しさん：2008/06/01(日) 07:59:22

COBOLはJavaとはかなり違ってどっちかというとBASICに近いんだな
まさか小学時代趣味で遊んでたBASICがこんなところで役に立つとは･･･
人生何があるかわからんね

352 ：デフォルトの名無しさん：2008/06/01(日) 08:41:28

BASICに近いとか言い出すならCOBOLよりもPythonの方がよっぽと近い点について



つか、COBOLと比較するならまだアセンブラの方が近いわ。
どういう脳の構造しているんだが。

353 ：デフォルトの名無しさん：2008/06/01(日) 11:16:35

いやぱっと見だから別にそこまで深い理由無いって
来春業務で使うんじゃね？って思ってる新卒です

354 ：デフォルトの名無しさん：2008/06/01(日) 11:54:02

前途多難ｗ

355 ：デフォルトの名無しさん：2008/06/01(日) 12:40:01

>>351　COBOL 対 なにか
>>352　BASIC 対 なにか
この場合、比較の基準はCOBOLに合わせろよ。どういう頭の構造してんだか...

356 ：デフォルトの名無しさん：2008/06/02(月) 00:05:53

頭の構造がおかしいからこのスレに来るのだろう

357 ：デフォルトの名無しさん：2008/06/02(月) 00:26:49

「頭の構造」が形状とかの意味だったらおもしろいな.

358 ：デフォルトの名無しさん：2008/06/02(月) 00:47:27

COBOLの現状

・生保基幹系では現役、損保でも現役（アセンブラも多々あり）
・銀行はリニューアルの方向（まだ使ってる）
・証券はブラックボックス扱いのアセンブラと混じりあってる
（多分リニューアルしたいんだろうけど、かなりの困難がある）
・メーカーもまだ使ってるところがある
（MF-COBOLを採用するところと完全リニューアルするところはマチマチ）
・物流、流通・小売もまだ使ってるところはあるが主流ではもちろんない

MF-COBOL採用の会社が結構あるのでCOBOL自体は無くなりはしない
汎用機→UNIXサーバになる

359 ：デフォルトの名無しさん：2008/06/02(月) 00:53:44

>>358は一応リアルな現状です

IT音痴はなはだしい俺でもCOBOL現場ではそれなりに仕事できてたので、
文系で息長く業界でやっていきたい人向き
定年までやって、現在嘱託でまだ現場でやってる人もいるくらい
ただ本当に保守開発はつまらない
オープン系でいける人はそっちの方がいいに決まっている

何も対立することはないよ
VBで買い叩かれてた人とかSIで疲れきった人なんかが汎用系に転向することもある
ただ、金融系はCOBOLといえども残業が多いのでその辺は注意してね
まぁ、やらないだろうけどさw

360 ：デフォルトの名無しさん：2008/06/02(月) 01:14:38

コボラーの99.9％は生活の為に仕事をしています
やりがいなんてカケラも感じていません
やらなければいけないからやってるだけです
そういう意味では工場のライン工や新聞配達とたいして変わりません
SEやPGではなく、業務担当者です
業務システムに対しては妙なこだわりとどうでもいいプライド的なものがあったりします

仕事を楽しんでる若者とは基本的に合いませんw

361 ：デフォルトの名無しさん：2008/06/02(月) 01:28:21

おれは若いがCOBOLやってる、正直つまらん
いま別の言語勉強してるから30歳までには転職予定

362 ：デフォルトの名無しさん：2008/06/02(月) 01:29:20

コボラーに必要な素養

×：才能
○：忍耐力

もし保守メインのコボル現場にJavaラー（新規開発メイン）がつっこまれたら多分その日のうちに
ブチ切れてバックレると思うw
いや本当

363 ：デフォルトの名無しさん：2008/06/02(月) 04:10:30

例えば、三菱東京UFJのシステム統合。
11万人月のプロジェクトといわれているけど、COBOL、PL/I以外、
つまり、CやC++での作業量はどの程度あったんだろう。

メインフレームは、IBMと日立。東京三菱側のIBMに片寄せするということだったけど、
勘定系基幹システムが、Cとかjavaとは思えない。

全てのデータがDBとも思えないし、一つのプログラムで、いくつもIOをする場合
COBOLは楽。複数ファイルのマッチングとかは特に。

勘定系システムで、完全にCOBOLを排除したシステムを知っている人がいましたら、
どこの何というパッケージか教えて欲しいです。

COBOLやPL/Iを擁護するつもりはないが、過去の資産をリプレイスするだけの体力は
メガバンクと言えども無理じゃないか。

Cやjavaのアプリケーションプロジェクトで、1万人月を超えるようなのを
しらないだけかもしれないけど。

364 ：デフォルトの名無しさん：2008/06/02(月) 07:37:10

＞11万人月

微妙に関わった人間からすると、プログラムの作業量はそこまで多くないな。
マスゴミ（MUFGの広報を含む）の情報に踊らされてる。

漏れも全体を把握してないから予想だけど、ヘボい三菱のシステムと
先に進みすぎていたUFJな構図だけど、立場と権力は三菱の方が上と言う
ある意味最悪パターンで、そこらの折り合いと言うか宣伝や会議の時間と
ダラダラしたテストが多い。

＞全てのデータがDBとも思えないし、一つのプログラムで、いくつもIOをする場合

そもそもひとつのプログラムのIOは２・３程度がほとんどだけど。
ただ無駄にそういうジョブが山ほどあって高価な視覚自動化ツールをつかっても
画面が真っ黒と言うどうしようもないノリだったらしいな。

COBOLのコード量と密度と質は他の言語と比べにくいから、なんとも言えないが
人が触る機能面も含めた全体システムでみるとCOBOLは激減したな。
作業量云々はCOBOL以外の方が多い。

漏れのトコは移行関係のツールもCOBOLではなかったし。

365 ：デフォルトの名無しさん：2008/06/02(月) 15:00:00

＞＞勘定系システムで、完全にCOBOLを排除したシステムを知っている人がいましたら、
＞＞どこの何というパッケージか教えて欲しいです。

地銀でウィンドウズにしたとこがあって一昔前話題になった
ただ、カーネルを改良したものなので一般的なWinではない

スルガ銀行はやろうとしてつまづいてIBMを提訴中

銀行、特に地銀は汎用機自体をどうにか無くせないものか、といろいろ思案中なのは確か
生保はこのまま汎用機でGOという雰囲気

リニューアルに失敗、成功したが苦戦（当初予定の2倍の予算と工数）の例が結構あるので、
慎重なメーカーの中にもMF-COBOLにツール変換するとこもある
JCL→シェルになるアレね

366 ：デフォルトの名無しさん：2008/06/02(月) 17:20:44

結局、コボラーは生き残れるの？

367 ：デフォルトの名無しさん：2008/06/02(月) 17:38:45

むしろＣＯＢＯらーの方が安定して高収入や
取引先がいい。金もおしまない。

368 ：デフォルトの名無しさん：2008/06/02(月) 18:04:33

COBOLが無くなるって
何年前から言われてるの？

369 ：デフォルトの名無しさん：2008/06/02(月) 19:53:47

COBOLそれ自体の需要は無くなりはしないが、保守・新規共に開発は減少傾向。
まあ、いいとこUNIXへの移植くらいしか残されてないなあ。

370 ：デフォルトの名無しさん：2008/06/02(月) 20:05:28

まあ、COBOLはそれこそ汎用機オペと同じな感はあるなぁ。
IT自体が底辺なのだと思うが、その中で最下層ってイメージがある。

371 ：デフォルトの名無しさん：2008/06/02(月) 20:41:21

>>366
生き残るも何も、COBOLerがいなけりゃ
日本社会は一秒も成り立たないと前から言っておろうが。
ヤフーやアマゾンが障害で数日休んでも何てことはないが、
メガバンや証券のシステムが一週間でも止まったら、
日本社会総崩れ、下手すると世界を巻き込んだ大恐慌になる。
この世の中はCOBOLerのおかげで回ってると言っても過言ではないよ。

372 ：デフォルトの名無しさん：2008/06/02(月) 20:56:45

現実問題、富士通のCOBOLerが証券のシステム止めてたよな。

ダウンタイム云々を言い出すとヤフーやアマゾンよりも
証券や銀行の方が長いし。ｗ

373 ：デフォルトの名無しさん：2008/06/02(月) 21:02:51

>>370
どっちの経験もあるけどオペとは全然違う
オペについては素人と同じレベルだと思ってもいいくらいスキルはゼロに近いよ
別にコボラーを擁護するわけじゃないが、ITカースト最底辺のオペと一緒にするのはさすがに無礼きわまるよw

汎用機オペ：COBOL読み書きできない、JCLも理解してない奴多数、仕事はルーチンワーク兼人間アラート
　　　　　　人間の質も開発とは比べ物にならないくらい劣悪

汎用系コボラー：COBOL＆JCLは普通にできる、人によってはその他言語も可、
　　　　　　　　元請or2次請け案件メイン、オープン系からの転向組も少数ながらいる

374 ：デフォルトの名無しさん：2008/06/02(月) 21:09:40

しかし大多数のCOBOLerはまったく応用力がなく、専用人間の割りには使えないヤツが
大杉だからなぁ。

他人からみたらオペと大差ない状態あるだろ。
特に>>371みたいなアフォがいる時点でいい証明だ。ｗ

375 ：デフォルトの名無しさん：2008/06/02(月) 21:14:47

汎用機オペレータのスキルはそれこそニート・フリーターと同レベル
仕事を通して身につくものが特に無いので、普通は2年程度で開発or運用へ異動になる
稀に40過ぎてもオペやってる人がいるが、本当に稀
開発、運用で問題を起こした人かさっぱり使えなかった人か・・・

まぁ、>>370はオペレータ本人なのかもしれんが

オペ経験者が中途で、COBOL開発者の求人に応募してもスキルが無いので採用はかなり厳しい
汎用機にさわってコマンド打ってた程度では相手にされない
それが現実
でもやれば誰でもすぐ覚えるよ
やりたくないだろうけどw

376 ：デフォルトの名無しさん：2008/06/02(月) 21:20:07

>>374
だからぁ
オペとは雲泥の差があるの
オペはただの雑用係
運用とですらかなり差があるのに
粘着しすぎだよオペｸﾝ

証券のシステムの方はもうプロパですらブラックボックス扱いしてる
ソース郡があるんだと
下手に手が出せんとさ

377 ：デフォルトの名無しさん：2008/06/02(月) 21:22:18

>>374
コボラーに粘着し杉w
何かやなことでもあったのか？

378 ：デフォルトの名無しさん：2008/06/02(月) 21:25:09

オープン系でも設計・開発、運用、オペじゃ全然違うだろ
それと同じ

無能、優秀ではなく職種が全然違う
スキルも全然違う
オペは脱ITする奴の方が多いくらいの職種だし
そっちの方が正解だしね、多分w

379 ：デフォルトの名無しさん：2008/06/02(月) 21:57:23

20人弱の大規模コンパで部門跨いで呑んだんだが、
携帯やってる若い衆の話は聞くだけで青ざめた
web中心のとこの女プログラマーさんでさえ終電帰りが珍しくないというし

そりゃ俺ら、比較的加齢臭漂うツマラン世界かもしらんが
コボラーってのはITん中でも比較的幸せな職場なんじゃねえか

380 ：デフォルトの名無しさん：2008/06/02(月) 22:03:57

ＣＧＩ、ＨＴＭＬ、ＭｙＳＱＬやら１５年前の汎用機と基本同じやて。
しかもやっすいのな。

ＣＯＢＯＬで電力会社の資材管理扱ったことあるけど桁が違う。
ＷＥＢでも似たようなの作ったけど安いのな。
発注元の資金力が１０００倍くらい違うからやろけど。
ＩＴとかいうても実際、小口ばかりやん。あふぉくさ。

381 ：デフォルトの名無しさん：2008/06/02(月) 23:03:00

webや大規模Java等→需要が多くて単価安くなる
　なぜか志望者も多くて単価安くなる
携帯やゲーム機→キャリアやライセンシーが連日過酷な価格競争
　志望者には事欠かないので専門卒をいびり倒しつつ凌ぐ
COBOL→新人自体が数少ない
　時流の面白みも刺激もないため、保守が必要なお抱え元が過大評価
　リプレースなんかできれば考えたくない

こんな流れかしら

382 ：デフォルトの名無しさん：2008/06/03(火) 01:23:32

あんなあ、サーバーでも汎用機並の信頼性持たせようとすれば、相当の金掛かるんよ。
汎用機のメモリ幾らするか知ってる？
プログラム障害でのシステムダウンならどうしょうもないけど、ハードウエアの信頼性に
関しては汎用機もオープンサーバーも肩を並べれば同じくらい金が掛かるんよ。

383 ：デフォルトの名無しさん：2008/06/03(火) 02:40:19

いや、オープンサーバと、メインフレームを比較しちゃいけない。
設計思想が全く違うのだから。

信頼性ではメインフレームの方が、格段に上。

384 ：デフォルトの名無しさん：2008/06/03(火) 02:44:19

ユニシスがWindowsで勘定系を構築したのは知っている。
でもリリースには開発言語まで書かれていない。

マッパーだったりして。

385 ：デフォルトの名無しさん：2008/06/03(火) 05:01:32

今は汎用機もサーバ上にエミュレータ動かしてるけどな。
よって、HDDやメモリなんかも安いのよ。
しかも早いし。

386 ：デフォルトの名無しさん：2008/06/03(火) 13:52:22

まぁ〜開発が好きな奴は、ＷＥＢ、オープン系。
まったり、仕事以外のことに時間を使いたい奴はコボラーていいんじゃない？
俺はコボラーを選ぶ。

387 ：デフォルトの名無しさん：2008/06/03(火) 15:51:47

>>385

それ間違い。メインフレーム使ったこと無いでしょ。

メインフレームでは、VM化して複数のOSを動かしているわけで
サーバー上にエミュレータを動かしているのではなく
1つのマシン上で複数のサーバー(というか機械)が動いているイメージ。

388 ：デフォルトの名無しさん：2008/06/03(火) 20:33:47

>まったり、仕事以外のことに時間を使いたい奴はコボラーていいんじゃない？
>俺はコボラーを選ぶ。

漏れの先輩のCOBOLerは数年近く終電かタクシーでしか帰ったことがなく、
ブチ切れてヤめていった。
個人的には１０年に一人現れるかどうかの人材だったと思う。

職場にもよるがIT系でゆったりと時間が使えるのはある意味で無能の証明だと思う。

389 ：デフォルトの名無しさん：2008/06/03(火) 21:02:59

暇で役立たずな自分を「漏れはゆったりと生活するんだ」と
思い込むのは自由だよな。

COBOLだともう、保守か運用くらいしかネタがないから
そんなに忙しい>>388のケースってのは稀だとは思うけど。

真に有能な人間は他の仕事やってるだろうし。

390 ：デフォルトの名無しさん：2008/06/03(火) 23:45:45

毎日定時帰りですいません
ていうかもっと仕事くれ、まじで

391 ：デフォルトの名無しさん：2008/06/04(水) 01:55:22

>>388,389
まあ、君らの物言いには多分に「逆」もあるけどな。
「暇で忙しい自分は役立たずでない」って視点もまた幻想だしね。
まったりなCOBOLerが支えてる「維持」系も、比類無き価値だしね。
時間搾取を正当化せず仕事以外に意義見出せば、笑いどころは180度変わるしなァ。

XeonでFreeBSD4系のFB-DIMMの三台冗長に置き換える案を出してもハネられるか「社運をかけた実験」扱いされる時代だしね。
汎用機のメモリがいくら高価くても・・・

汎用機を殺せない理由って多分に電源系が問題な気もしないではない。
大手町某データセンタさえ定期的に落としやがるしな

392 ：デフォルトの名無しさん：2008/06/04(水) 04:34:39

ぶっちゃけ文系SE、PGの飯の種
オープン系からの転向組はやっぱりJCLがうざすぎるとのこと
JP1なんか使ってた人は尚更だと思う

コボラーといえど、証券、銀行（勘定系）の保守につっこまれると残業地獄になるはず
生保、損保も作業量が多いのでやっぱり残業が多い
金融系で汎用系はどっち道残業まみれな会社、現場が多い

「コボラー＝定時帰り」は中々難しい

393 ：デフォルトの名無しさん：2008/06/04(水) 06:41:30

しかし、「証券、銀行（勘定系）の保守につっこまれると残業地獄になるはず」
とか「日本の証券、銀行はCOBOLerが支えている」とか
「まったり、仕事以外のことに時間を」とか
COBOLerは胡散臭い印象が強いなぁ。

残業の多い少ないは波があるんだろうけど、「まったりと」なんて現場は
単に無能か汎用機オペと似た連中なんだろう。

394 ：デフォルトの名無しさん：2008/06/04(水) 09:33:13

JCLがうざいのはわかるんだが、
クリティカルパスで組んだバッチ処理の運行を考えると
良くできているとおもうのだが。

395 ：デフォルトの名無しさん：2008/06/04(水) 13:30:16

JCLの発想はよく出来ていると思うよ。
オープン系のDIとか見ても、
「それに似たこと、ずっと昔からJCLでやってますぜ」って思うし。

バッチ処理をOSレベルで管理できるのって
何だかんだ言っても便利だと思う。

未だにIDEが無いのが死ぬ程タリィけどね。

396 ：デフォルトの名無しさん：2008/06/04(水) 18:26:35

こういう会社があるぐらいだからコボラーはだいじょ〜うぶ。
http://www.cobol.co.jp/

397 ：デフォルトの名無しさん：2008/06/05(木) 13:19:24

mixi、ブログ、ようつべすぐ真似するの現れるね。

そこで必要なのは客集める力、営業力であり
技術屋は使い捨て。

398 ：デフォルトの名無しさん：2008/06/05(木) 17:42:19

マジで聞きたい。
cobolとphpどっちが将来性ある？

399 ：デフォルトの名無しさん：2008/06/05(木) 19:29:19

COBOLには将来性は無いが
phpには何も無い

400 ：デフォルトの名無しさん：2008/06/05(木) 21:38:51

将来性といってもなぁ・・・。

以下、個人的な思いだけど。

<< COBOL >>
COBOLバッチ処理＠汎用機は非常に優れモノで
これを凌駕するモノが出現するまでは、しぶとく
生き残るんじゃないの？
あとはブラックボックス化しちゃった部分の周囲では
しつこく残るかもね　（ex.生保の課金計算とか)

<< php >>
ま、短期決戦型Webシステムの需要には応えられるよね。

・・・てな感じ。


オレの場合、仕事でも使っていて面白いなと思うのはJavaかな。
言語がどうと言うより、進歩の早さが何かワクワクして楽しい。

仕事以外で少し勉強しているのがRuby。まだ半人前にも
達してないので語れません(涙)
あとは頭の体操替わりに時々Haskell本を覗くくらいかな。

401 ：デフォルトの名無しさん：2008/06/05(木) 23:24:33

phpの方が今においては現役感があるなぁ。
将来においてはCOBOLよりはマシな程度だとは思うけど、
将来云々言うなら素直にJavaとかRubyとかSQLを覚えておけって希ガス。

402 ：デフォルトの名無しさん：2008/06/07(土) 00:40:12

>>393

オペレータの方はスレ違いなのでコボラーに粘着しないで下さい

さすがにあなた方とは違いマスw

403 ：デフォルトの名無しさん：2008/06/07(土) 00:42:45

コボラースレに何故Javaラーやオペが粘着するのか不思議でしょうがない
君達は一体何を求めてるんだ？
コボルスレでwww

404 ：デフォルトの名無しさん：2008/06/07(土) 00:50:14

JCLについて語ろうぜ

405 ：デフォルトの名無しさん：2008/06/07(土) 01:04:33

COBOLもJAVAも生き残るよ。　.NETでVBも生き残るし。
PHPは小規模で結構使われている。

まあ、サーバーサイドJAVAは汎用機アプリの焼き直し
みたいなもんだが、覚える事が多くて大変。
その点、古臭いと言われてもCOBOLは魅力だね。

406 ：デフォルトの名無しさん：2008/06/07(土) 01:30:07

本当、オペの粘着がうざい
バレバレだからいいかげんやめろ
コボラーは汎用系とはいえ開発者
一所懸命コボラーとオペを同一視しようとしてるけど汎用系スキル自体が全然違う
そもそもオペは情報システムの人間ではない
オペは就業時間中にネット、ゲーム、携帯、マンガで遊んでる連中

オープン系、ファームウェア、コアテクの連中とコボラーが戯れるスレに
オペはいらない

オペごときのためにスレが消化されるのは無駄
マジで来ててくれ

407 ：デフォルトの名無しさん：2008/06/07(土) 01:34:33

コボラーは自分のことを技術者とは思っていない
安定志向のサラリーマンだと思っている
そしてそれでいいと思っている
思考パターンは公務員に近いかも

なので腕一本でやっていこうとしてる技術屋とは基本的に合わない
ただそれだけの話
コボラーはオープン系の技術屋と対立する気はゼロ
むしろいろいろと依頼する側

408 ：デフォルトの名無しさん：2008/06/07(土) 03:51:30

コボラーになりたいので
オススメ本おしえて

409 ：デフォルトの名無しさん：2008/06/07(土) 03:55:10

COBOL文法活用法

410 ：デフォルトの名無しさん：2008/06/07(土) 07:47:13

コボラーが公務員に近いのは同意だな。
やる気なし、技術なし、責任転嫁ばかりってトコは特に。

411 ：デフォルトの名無しさん：2008/06/07(土) 11:42:33

>>410
技術なしとは何事だ。
お前が代わりにコボラーやれるのか？ああ？

412 ：デフォルトの名無しさん：2008/06/07(土) 11:48:57

やる気はあるが仕事がない、保守とかつまんね

413 ：デフォルトの名無しさん：2008/06/07(土) 12:11:20

代わりのコボラーって言うか仮にCOBOLで金融系のプログラム組めと言われたら
正直、誰でも出来るだろ。

「オマエが変わりにPS3のCELLでプログラムしてみろ」とか言うならともかく。

414 ：デフォルトの名無しさん：2008/06/07(土) 13:30:00

>413
妄想乙

415 ：デフォルトの名無しさん：2008/06/07(土) 14:10:39

もしかして煽っているつもりなのか・・・。

本気で言っているなら相当に哀れなんだが。

416 ：デフォルトの名無しさん：2008/06/07(土) 14:29:33

最近のオープン系はひどいね。
動くものを作るためには、データベースや
WEB系の複数のプロダクトを連携させるテクが必要。
特定の言語一つで全て作るという思想がない。
よくそんなに脳みその容量があるなと感心する。
JavaのAPIを見ているだけで日が暮れる俺には
とてもできんわあんなこと。

417 ：デフォルトの名無しさん：2008/06/07(土) 16:04:47

最近の言語なんてどれも似たようなもんだろ？

418 ：デフォルトの名無しさん：2008/06/07(土) 16:33:29

Ｊａｖａのフレームワーク次々と変わっているから、新しい物好きはＪａｖａ。
まったり派はＣＯＢＯＬ。
ぜったいＣＯＢＯＬがいいって！！

419 ：デフォルトの名無しさん：2008/06/07(土) 17:41:59

>>416
オマエが単にWeb以前に進化と言うのを理解していないだけだと思うが。

つかCOBOLもOO対応版あったけど、こっちも同じように否定するんだよな？ｗ
#正直こっちの方がオープン系より酷いんだが

420 ：デフォルトの名無しさん：2008/06/07(土) 18:01:21

まー、ローカル変数ですら害悪扱いする人種だからなー。

＞特定の言語一つで全て作るという思想がない。
仮にWebの事を言っているならIBMのWebSphereは全てJavaでシステム構築
できるんだが。つか逆にソレしかできん。

421 ：デフォルトの名無しさん：2008/06/07(土) 21:44:30

純粋関数型言語的に考えて引数以外の変数は害悪じゃね。

422 ：デフォルトの名無しさん：2008/06/07(土) 23:49:23

何かなあ、COBOLだjabaだと言い張りつつの、お互いの優位性ばかり晒してる。
言語が何であれ、結果は品質の良いプロダクトになればいいのさ。
そこで、質問。
テスト、まあ単体テストでもいいわね。
テスト効率（少ないテスト件数で多くのバグを検出する）に関してはどうなんだ？
検出したバグ修正に関わるモジュール修正数、
こういう観点から見た場合にて、COBOLはCOPY句の誤りが無ければ
１プログラムにバグ収束してるように思えるんだが、
jaba坊の意見聞きたし。

423 ：デフォルトの名無しさん：2008/06/08(日) 00:26:53

１プログラムって範囲広すぎじゃね？
そしてjabaって何？

424 ：デフォルトの名無しさん：2008/06/08(日) 00:33:37

テスト効率という点では
オブジェクト指向言語は分が悪い。
クラスごとにテストしなくてはならないからだ。

425 ：デフォルトの名無しさん：2008/06/08(日) 00:41:26

COBOL は単体テストもしないのか？

426 ：デフォルトの名無しさん：2008/06/08(日) 00:50:36

OOしなけりゃ分が良いというもんでもない
OOできなきゃ一般的なリフレクションとも縁がないからだ
一長一短　COBOLどうこうって話じゃねえ

427 ：デフォルトの名無しさん：2008/06/08(日) 08:52:04

どうやらCOBOLerは単体テストもしないらしい。

jaba坊ってのはどこの世界に存在するかしらんが、
仮にJavaの事を言っているなら、ナニをどう考えてもJavaの方が
テストしやすい環境＆テスト仕様になっている。

テスト効率に関しても圧倒的にCOBOLは分が悪い。


つか、OOとテストが無関係とは言わんが畑違いな事比べるなよ。
だからCOBOLerは老害と言われるんだよ。

428 ：デフォルトの名無しさん：2008/06/08(日) 10:33:43

なんかCOBOLerのOO否定派ってJavaの入門書の最初の１０ページくらい読んで
OOが解ったつもりになっている痛いヤツだと思えて仕方ないんだが。

ある程度OOを習得し実務で使った経験者が優越やら個人的所感を語るならともかく
明らかに開発経験なしな素人が知ったかで語っているのは滑稽だったりする。

429 ：デフォルトの名無しさん：2008/06/08(日) 10:47:18

>>425
COBOLは実行ファイルが一つだから
単体テストを一つやればおk。
Javaはクラスの数だけ単体テストが必要。
mainのみのプログラムでやっとCOBOLと同等の
テスト効率になるが、それではOOできないだろ。

430 ：デフォルトの名無しさん：2008/06/08(日) 11:52:07

COBOLでも（最低でも）サブプログラム単位に単体テストが必要だろ普通

>COBOLは実行ファイルが一つだから
>単体テストを一つやればおk。
こんなことやってるからバグるんだよ馬鹿

431 ：デフォルトの名無しさん：2008/06/08(日) 12:09:00

単体テストを一つやればってのがどういうレベルなのかわからん

432 ：デフォルトの名無しさん：2008/06/08(日) 18:02:21

＞Javaはクラスの数だけ単体テストが必要。

COBOLerの名誉の為にコイツは氏ねばいいと思う。

何も知らないクセに他の言語をバカにするから
COBOLerは役立たず扱いされている事に気がつけよ。

433 ：デフォルトの名無しさん：2008/06/08(日) 18:10:33

>>429の人気に嫉妬だなｗ

しかし、こんなアフォが少なからず現存しているから漏れの部署は
障害連発しているんだろうなぁ。

434 ：デフォルトの名無しさん：2008/06/08(日) 18:57:10

>>432
馬鹿にしてはいないだろう？
テスト効率の話になったから
JavaとCOBOLを比べてみただけだ。
お前のような、劣等感と卑屈さに満ちた
COBOLerこそがCOBOLerの地位を悪くしてるんだよ。
一つの言語を極めた人間としてもっと堂々としろや。

435 ：デフォルトの名無しさん：2008/06/08(日) 19:40:02

>>432
> ＞Javaはクラスの数だけ単体テストが必要。
これをもってテスト効率云々は、言語以前に効率の意味が判ってないと思われ。
部品の概念が違う言語の比較を、クラス(モジュール、ファイルなんでもいいが)数で
比べるとは・・・

436 ：422：2008/06/08(日) 19:58:03

なんか話がシワクチャだな。jaba誤り、javaね。
どこからCOBOLのテストは１回でokなんて話になったんだ。

>>429はCOBOLの１ロードモジュールに対して単体テスト一式＝一つ、つう意味で書いてるんじゃね。
俺の書きたかった事は、あるジョブを実行する上で、COBOLとjavaでテストケースはどれくらいあるのかって事。

COBOLだって共通サブとか使ってるし（共通サブの正当性は既に保証済みとする）SQLも呼んだり書いたりするし、
オンライン画面からのテーブル更新なら単体で３００〜５００位のテスト項目がある。
それを何回のテストケースで網羅させるか、大体1/10くらいが俺の経験則だ。つまり３０〜５０位回走らせる。
そこでjavaはどうなのよってことを聞きたかった訳。
１プログラムってのは誤読されやすいな。ダイナミックリンクも含めた１ロードモジュールって感じで読んで来れ。

本来の意図は、開発方式とテスト方式は同じ枠組みの中で考えるべきじゃないかと思ったんよ。
巷の参考書。開発関連書籍は何十冊もあるがテスト方式は７冊だけだってのを知ったからさ。
ま、この話は別な時に興味ある奴が取り上げて来れ。

437 ：デフォルトの名無しさん：2008/06/08(日) 20:23:34

テストケースなんて要件を満たす数だけやるんだから
COBOLもJavaも関係ない。

ひとつの１プログラムに１０の機能を実装する仕様であるならば
COBOLは8のテストでJavaが12のテストとかありえない。

テスト効率と言う意味で言うならばJavaはウォーターフォール形式の
開発ではなくTDDを用いるケースが多いので、Javaの方が生産性が
高く品質が高い場合がある。と言うかIDEとユニットテストのノウハウが
COBOLとは段違いに蓄積されているので、設計にもよるが
ほとんどぼ場合はJavaの方が効率がいい。

つか、開発スタイルから違うから比較は無意味。
COBOLでTDDができないワケでもないが、現実問題出来ないし
言語仕様からしてやると苦痛なだけだろう。

438 ：デフォルトの名無しさん：2008/06/08(日) 20:33:15

JAVAはテストやら例外やら、長年悩まされてきたプログラマの苦悩を
低減する様に工夫・進化している言語だから、COBOLの様に
長年とまった言語を効率云々を言っても仕方ないと思うが。

つかコボラーはどうしてそんなにJAVEを目の敵にするんだ？

後から出た言語なんだから現代戦に有利に作られてるに決まってるだろ。
C#やRubyなんかかなり効率的にヤれるしな。

439 ：デフォルトの名無しさん：2008/06/08(日) 21:02:45

>>438
Javaは理念先行で使いづらく実用性に欠ける言語だ。
なのに業界全体がブームに乗せられ、強引に推進しようとしている。
その欠点をはっきりさせ、関係者の目を覚まさせるのが俺らCOBOLerの仕事だ。
Cとの勢力争いにほぼ勝利した今、コンピュータ言語界は
COBOLを中心にまとまっていくべき時代に入っているんだ。

440 ：デフォルトの名無しさん：2008/06/08(日) 21:14:27

Javaは言語としてよりJavaVM含めた環境全体が湧いてるからな

この所、何もかもがJava上に乗っかっちまいそうな勢いで動いてるしな

441 ：デフォルトの名無しさん：2008/06/08(日) 22:06:41

>>439
もうCOBOLラー、マンセーな書き込みはやめてくれ。
俺は純粋に、JAVAの生産性（テストを含めた）を知りたいだけなんだから。

442 ：デフォルトの名無しさん：2008/06/08(日) 23:24:06

javaが流行っている理由は
・機種依存しない。
・httpd通信である為、遠隔地（海外）であっても設備コストがかからない。
・VBのようにDLLの配布が不要。
であって、ブームに乗せられている訳ではない。

システムを利用する拠点数が多ければ多いほど、メリットはある。
ちなみにコボラーはjavaへの移行を目の当たりにして、批判的なんだ
ろうけど、既存のシステムを他の言語で移行する場合、どんな言語でも
大変だって。それに階層型が多い汎用機からの移行はデータ構造も
変えないといけないから余計だね。

別にCOBOLを馬鹿にしてるわけではない。　バッチ処理言語として
COBOLは確実に生き残るよ。

443 ：デフォルトの名無しさん：2008/06/08(日) 23:38:56

そういやJava上のCOBOL実装ってねえの？

444 ：デフォルトの名無しさん：2008/06/08(日) 23:59:54

JABAなんぞ、中間コードを走らせるのだからBASICとたいして変わらん。
やっぱロードモジュールを動かさないとな。

445 ：デフォルトの名無しさん：2008/06/09(月) 00:00:25

オメーラのせいで間違った。
JAVAだ。

446 ：デフォルトの名無しさん：2008/06/09(月) 00:49:10

は？中間コード？

447 ：デフォルトの名無しさん：2008/06/09(月) 01:05:34

たわけが、敵の長所を知らずして、戦に勝てるかあ！
　
〜〜信長公記〜〜

448 ：デフォルトの名無しさん：2008/06/09(月) 01:18:57

>>444
BASICと違って中間コード（？）……バイトコードの方を
仕様で固めた仮想マシン実装だから、雲泥の差なんだけど

449 ：デフォルトの名無しさん：2008/06/09(月) 02:03:38

>>442
機種依存しないが、バージョン依存する(場合がある)
DLLつーか、汎用機にゃそんなもんはねえ

別にjavaを批判するわけじゃなく、適材適所だと思うわけだ。
金融系のシステムつっても、全部COBOLというわけじゃないわけだし

速度を必要とするところは、FORTRANなりASMを使うし
DBアクセスなんか、外部モジュール化して
より簡単に利用できるようにしてある
SQLなんか知らなくてもいいようにするでしょふつー

450 ：デフォルトの名無しさん：2008/06/09(月) 08:40:41

このスレに集まっているコボラー以外の奴らって、
プログラム言語以前にスレタイが読めないの？

451 ：デフォルトの名無しさん：2008/06/09(月) 10:36:01

コボラーも読めてないゾ

452 ：デフォルトの名無しさん：2008/06/09(月) 12:55:18

>>451
コボラーがこのスレに集まるのは問題ないでしょうに。

453 ：デフォルトの名無しさん：2008/06/09(月) 20:10:02

あ、コボラでさえあれば、語る内容は何でもok？

454 ：デフォルトの名無しさん：2008/06/09(月) 20:19:38

ここはプログラム板ですよ

455 ：デフォルトの名無しさん：2008/06/10(火) 15:09:45

>>450
コボルしか出来ない人集まれ　ではないんだからね。
他の言語との比較とか、適材適所論は問題ないでしょ？

456 ：デフォルトの名無しさん：2008/06/10(火) 19:37:50

>>455
それは問題ないんじゃない？

コボラーなら。

457 ：こんないめーじがある…：2008/06/11(水) 12:39:46

事務手続き処理用生データそのまんま処理可能言語。
異星人が見た時、一番早く理解するプログラム言語。

優れた仕事＝機械にやらせる前に既に問題解決済み。
プログラムが出来ると言うより、仕事ができる人向け。

超整理法の人は、その時に終わる仕事を残さないひと。
整理能力が優れているわけではなく、仕事が出来る。

コボルが出来る人は、見れば使えるデータを仕上げるひと。

458 ：デフォルトの名無しさん：2008/06/11(水) 13:25:32

>>457
プログラマならもう少し日本語整理しなさいな。
まったく意味不明だよ。
>コボルが出来る人は、見れば使えるデータを仕上げるひと。
RDB全盛時に何書いてんだか。
今のデータはコマギレでテーブルレコード読んだ位じゃわけわかめ。

459 ：デフォルトの名無しさん：2008/06/12(木) 04:47:53

COBOL＆JCLしかできない俺はJAVAで開発してる人とか普通に尊敬するけど
隣のシマがオープン系の開発部署でプリンタに紙を取りに行くときにPGの端末を
ちらっと見るけど、ソースがまたすごい感じ・・・
理系のPGは頭の出来が違うというか
オープン系の人に悪いイメージは全く無いけど
何故そんなに対立するのかさっぱりわからない
お互い協力して開発するときもあるし

460 ：459：2008/06/12(木) 04:51:20

生保の子ITでオンライン新規で作ったときは単体テストはせずに、
すべてのモジュールを対象とした結合テストをいきなりやってた
その前に疎通テストがOKなのが前提だけど
保守開発も結合テストからはじめる

他系システムとのサイクルテストはスケジュールを合わせて、という感じ

あんまり単体モジュールのみにこだわったテストはしなかった
生保の基幹系は特殊だからあまり参考にならないかもだけど

461 ：459：2008/06/12(木) 04:55:36

メーカーの生産系とか事務系のバッチはモジュールベースのテストが多かった
これは生保の基幹系と違ってモジュールを階層構造にしないからだと思う

複数の小さいプログラムをJCLで数珠つなぎにしてジョブとして成立させてた
なのでJCLがもう長くて長くて結構うんざりしました

COBOL＆JCLといっても業種や会社によってソースは完全に別物だし、
やり方も結構違いますね

462 ：459：2008/06/12(木) 04:58:08

ちなみにADABASとナチュラルバッチは超苦手です（汗）
DB2が簡単でいいですね
定義する人は大変らしいですが、ビューを引っ張る側の業務PGの私は
とっても楽です

DBエンジニアの方
お疲れ様です
いつも助かってます

463 ：デフォルトの名無しさん：2008/06/12(木) 05:02:43

日記はチラシの裏へ
感謝状は玄関の彼の靴の中に、香水を添えて

464 ：デフォルトの名無しさん：2008/06/12(木) 05:09:18

>>459
意味わかんねえ。何で尊敬なんて言葉が出てくるんだよ。
あっちはCOBOL+JCLなんて出来ねえんだから
プラマイゼロ、対等の立場だぞ。
自分にない技術を嘆くより、ある技術を誇れよ。

465 ：デフォルトの名無しさん：2008/06/12(木) 09:14:27

コボリング技術は誇れないなぁ
自分のことを技術者だなんて思ったこと一度もない
システム事務って感じかな

あっちはエンジニアだから

466 ：デフォルトの名無しさん：2008/06/12(木) 10:53:31

>>459
単に自分が知らない言語だからそう見えるだけだと思うぞ。
Javaは言語としてはそう難しくない。一度学べば普通に読める。
むしろCOBOLのPRUCEDURE DIVISIONより上の部分の方が
素直じゃないと思うけどね。

こんなこと書くと荒れるかもしれんが、怖がってないで突撃しろよ。

>>465
Javaも純粋なエンジニア的な部分は殆どライブラリ、あるいは
フレームワークが肩代わりしていて、一般人は単にそれを利用するだけ。
ま、COBOLより少し「考慮しなくてはならないこと」は多いけどね。
（マルチスレッドetc)

難しいのはむしろ、どんどん世代交代するライブラリやフレームワークに
追いついていくこと。この為に勉強時間をしっかり確保せねばならないね。

467 ：デフォルトの名無しさん：2008/06/12(木) 16:15:46

>>466
コボルのエリア定義はわかりやすいよ
慣れてるからかもだけど

もともと文系でシステム音痴の俺でも使えるのはCOBOLだけ
そもそもオープン系は残業マンセー徹夜マンセーなイメージで怖い
コボラーは休日出勤はしても徹夜はしないから
テスト機はどの会社もたいてい2時でメンテナンスに入るからw

468 ：デフォルトの名無しさん：2008/06/12(木) 16:36:23

理系や文系でも高学歴なコボラーは明らかにオープン系やDBまわりの仕事してる人に
嫉妬心を持ってるよね

469 ：デフォルトの名無しさん：2008/06/12(木) 16:44:07

>>467
そうと限らないけどね。

470 ：デフォルトの名無しさん：2008/06/12(木) 19:36:05

>>468
嫉妬はない。うらやましいとは思うが
だから俺はオープン系も勉強中

471 ：デフォルトの名無しさん：2008/06/12(木) 22:40:05

>>470
えらいなぁ
俺もアクセス＋VBAくらいできるようにしとこうと今決意した
ありがと

でも俺の頭じゃC系は無理（泣）

472 ：デフォルトの名無しさん：2008/06/12(木) 23:52:47

VBAは消えるって噂だよ…

473 ：デフォルトの名無しさん：2008/06/13(金) 00:03:03

COBOLのCOPY句はべんりだけど。
Cだと、構造体の管理が大変で。

といっても大分昔の話しなので今は違うかも。

項目数で300以上あるSEQファイルを扱うときなどは…

474 ：デフォルトの名無しさん：2008/06/13(金) 01:07:45

つ #include

475 ：デフォルトの名無しさん：2008/06/13(金) 12:57:38

私は現場未経験の新米プログラマです。
今まではJavaを勉強していました。

今日、会社からCOBOLの案件をすすめられたのですが、
皆さんどう思いますか？

476 ：デフォルトの名無しさん：2008/06/13(金) 15:22:17

シッカリとやりたまえ。

477 ：デフォルトの名無しさん：2008/06/13(金) 19:16:44

>>475
コッボラー突撃部隊へ　よ　う　こ　そ
君には特別に、パンツァーコピークを２つ用意した

478 ：デフォルトの名無しさん：2008/06/13(金) 21:23:37

笑った方がいい？

479 ：デフォルトの名無しさん：2008/06/14(土) 00:13:50

苦笑いでおk

480 ：デフォルトの名無しさん：2008/06/14(土) 01:24:12

>>472
それほんと？

481 ：デフォルトの名無しさん：2008/06/14(土) 02:14:45

C言語の勉強を20年以上してるけど、いまだにポインタがわからんな。
ていうかポインタの存在意義がわからん。
グローバル変数があれば一発じゃん、てなところで
まどろっこしくアドレス渡しなんかしてるソースを見ると
作者を殴りたくなってくる。
お前はそんなにアドレスを渡したいのか？
大事なのはアドレスじゃない、その先にあるデータなんだ。

やっぱCOBOLは最高。
必要にして十分な機能で構成された美しさ。
個人依存のあいまいな記述を許さない崇高さ。
大文字キーワードを旨とする質実剛健さ。
変数を一カ所にまとめて宣言する潔癖さ。
全てが俺ら男のためにある言語だ。
男と生まれたならCOBOLをやらなくては。
みんなでCOBOL賛歌を高らかに歌い上げよう。

482 ：デフォルトの名無しさん：2008/06/14(土) 08:28:21

>>481
とりあえず、COBOLが腐った女向けの言語に思えて仕方なくなってきた。

483 ：デフォルトの名無しさん：2008/06/14(土) 09:40:11

馬鹿は何を教えても無駄

484 ：482：2008/06/14(土) 09:43:13

そういや、スクリプト言語でスコープが理解できず、ぜんぶ
大域スコープの変数で処理しぐちゃぐちゃになるまで
だまってる奴がいた

女だったよ。本当のような、本当のはなし。

485 ：デフォルトの名無しさん：2008/06/14(土) 11:09:42

オンライントランザクションモニタって簡単にいうと何？

わけわからん

486 ：デフォルトの名無しさん：2008/06/14(土) 13:56:01

まあ釣りだろうな。
釣りじゃなけりゃ脳みそ湧いてる。

487 ：デフォルトの名無しさん：2008/06/14(土) 14:32:50

>>486
釣りじゃないよ。
ほんとにCOBOLが大好きさ。
COBOL使いであることを誇りに思っている。
COBOLのプログラムは生きている。
ソースリストの一文字一文字が、自分に優しく語りかけてくる。
このプログラムは俺のもの。俺だけがメンテできる。
彼女がいなくても、童貞でも、職場での扱いが低くても、
COBOLと対話できればそれで幸せなんだ。

Cから入っていたら、たぶんこの喜びはなかった。
一応努力してるよ。Cの入門書は30冊以上持ってるし。
でもCとはフィーリングが合わない。縁がなかったんだな。

488 ：デフォルトの名無しさん：2008/06/14(土) 14:35:15

あなたちょっと病んでますよ

489 ：デフォルトの名無しさん：2008/06/14(土) 14:40:28

Cは立ち読みで習得できた
COBOLは何冊重ねてもわけがわからん
すでに存在するソースが汚物すぎる

490 ：デフォルトの名無しさん：2008/06/14(土) 16:37:26

>>480
嘘の決まってるでしょ（笑）。ＶＢＡはなくならない。
マイクロソフトに電話して聞いてみたから大丈夫！！

ヤッホーーーーーーーーーー俺もコボラーだけど、ヤッパサイコ〜。
Ｊａｖａのわけのわからない言葉が大嫌い！！
コボラーーーーーーーーーーーーーーーーーーーーーーーーー
ーーーーーーーーーーーーーーーーーーーーーーーーーーーー
ーーーーーーーーーーーーーーーーーーーーーーーーーーーー
ーーーーーーーーーーーーーーーーーーーーーーーーーーーー
ーーーーーーーーーーーーーーーーーーーーーーーーーーーー
ーー最高！！

491 ：デフォルトの名無しさん：2008/06/14(土) 16:39:00

これはひどい

492 ：デフォルトの名無しさん：2008/06/14(土) 16:57:21

保守案件ばかりで、表現力の低い言語であるから
現行の仕事が個人が悠々と見渡せる「ジオラマ」の
ようになる。最高なのは当たり前

うちは生保系だけど、ＭＦそんなんばっかやってる。
ＪとかＣとかなどのオープン系との折衝には、みんな
だまーって話振らんでくれってうなだれてるよ。

493 ：デフォルトの名無しさん：2008/06/14(土) 18:41:25

しかし、古いCOBOLソースに当たったら本当に悲惨だ。
新しくても良い。
元ソースに何らかのモデル化意識が有れば何とか読めるが、
モデル化思想ゼロ、そいつに修正コードてんこ盛り、なもんは
ぼろ雑巾に何度も何度もミシン目かけて使ってるのと変わりない。

494 ：デフォルトの名無しさん：2008/06/14(土) 20:54:25

それはCOBOLに限った話ではないでしょ。
時代とともにコードの書き方も変わる。
ところでモデル化って何？

495 ：デフォルトの名無しさん：2008/06/14(土) 21:15:52

どんな言語でもそうだが、
障害対応等で辻褄合わせで高速開発したプログラムは
後々の保守でも癌となりやすい。
しかし、本当にアルゴリズムを知らない人間が作った
プログラムはｇｄｇｄである。

496 ：デフォルトの名無しさん：2008/06/15(日) 00:45:09

よく他人が書いたプログラムは・・っていうけど
見てわからないプログラムってあんまり知らない。

動いてるわけだし・・。

ソースプログラム古いんじゃねぇ？って事が無けりゃなんとかなる。

見てわからねぇ奴は、聞いてもわからねぇ。

497 ：デフォルトの名無しさん：2008/06/15(日) 01:19:50

>>494
モデル化ってのは、そのプログラムが何をやりたいか、
「俺はこういうスタイルで実装化させる」
っていう筋の通った考え方さ。
カラムを揃えるとか、and条件を前に置くとか、コーディング規則じゃないんだ。
プログラムの背骨みたいなもんさ。

498 ：デフォルトの名無しさん：2008/06/15(日) 02:13:58

>>497
よくわからんなあ。
そういうのはルーチンの先頭に
機能説明と引数・戻り値の説明を
コメントで書けば十分伝わるんじゃないのか。

499 ：デフォルトの名無しさん：2008/06/15(日) 02:52:52

部品化とか言った方が分かりやすいんじゃなかろうか。
モデル化は必ずしも部品化ではないとは思うが。

500 ：デフォルトの名無しさん：2008/06/15(日) 05:48:57

メーカーのシステムで使ってるCOBOLソースでひどいのは本当にひどい
（生保のソースは頭わるいけど綺麗だと思う）

・30年以上前のソースで構造化前のもの
・GO TOでループ、ALTERでGO TO文の飛び先が変わる（昔のソースでは普通らしい）
・主処理部分にCOPY句使ってる（使う必要なし、意味不明w）
・入出力ファイルにCOPY句をあてずに、処理で使わない変数部分はFILLERでとばしまくり
（後に保守、解析、システム移行するときの最大のガン）
・レコードレイアウトをジョブ中盤のプログラムが無視してエリアをメンテする
・汎用モジュールのカードが間違ったままほったらかし状態
・パック項目なのに偶数w
・やたら符号付の数字項目を使いたがる（パックでいいですやん）
・完全に意味不明なソースがある（プロパ側でもブラックボックス扱いでそのことには触れてはダメ）

解析案件にアサインされた俺涙目
UNIX-COBOLへの単純移行したがる会社が多い理由がよくわかる
膨大でぐっちゃぐちゃのソース郡をまともに相手にしてるとおかしくなる

501 ：デフォルトの名無しさん：2008/06/15(日) 05:57:00

それぞれの必要な資質

WEB系：センスと貧乏に耐える精神力
ネットワーク系：常に最新技術にキャッチアップできる能力
オープン系：たゆまぬ勉強と努力、スタミナ
コボラー：ただひたすらに忍耐力

502 ：デフォルトの名無しさん：2008/06/15(日) 07:36:09

IBMの「READY　TRACE」機能は良かったなあ。
あれのおかげで随分と助けられた。
１レコードだけ読ませて通過パス（SECTION、PARAGURAFH）を表示してくれる機能。
OS変わってから廃止になったんだよなあ。
ついでにJCKも便利だった。

503 ：デフォルトの名無しさん：2008/06/15(日) 16:24:09

ちょっとここで質問するのは失礼かもしれませんが、
COBOLerの人って他の言語を勉強しない印象があるんですが、
気のせいですか？

それと、他の言語を（かなり）勉強したがCOBOLの方が断然いいって
いう人いますか？

504 ：デフォルトの名無しさん：2008/06/15(日) 16:34:34

>>503
気のせい。COBOLerをひとくくりにするな。
ていうか、一つの言語を習得したプログラマーは
他の言語も勉強しなきゃならんなんてルールがあるのか？
君の言っていることは根本からおかしい。

505 ：デフォルトの名無しさん：2008/06/15(日) 16:37:12

>>481 = >>487なんかな？

>一応努力してるよ。Cの入門書は30冊以上持ってるし。
入門書しか買わなかったから、そこから進歩しなかったんじゃ？

例えば自己参照構造体（だっけかな？）を勉強すれば、
ポインタの意義がわかる。

506 ：デフォルトの名無しさん：2008/06/15(日) 16:38:52

むしろ一言語習得すると、たいてい他の言語も自然に理解できる（場合が多い）。
最初がBASICであっても。それがCOBOLerには通用しないみたいだ、と解釈してみた。

すなわち、COBOLerだけ異星人からの訪問者がまじっている。they live.

507 ：デフォルトの名無しさん：2008/06/15(日) 17:43:52

１つの言語しかやらないとか潰しきかなすぎだろう。

508 ：デフォルトの名無しさん：2008/06/15(日) 18:42:32

純粋コボラーっていうのは、新人の時に第３次オンにぶち込まれ、
そのままずっとCOBOLオンリーなんだよ。
スポットでPL/IやＣなどもいじらされるが、所詮スポット。経験にカウントされないのさ。
「私、独学で〜〜勉強しました」
じゃ、仕事は回してくれないのよ。実践一番。どんなクズな実践であってもな。

509 ：デフォルトの名無しさん：2008/06/15(日) 19:08:38

おれは仕事でCOBOLオンリー&趣味グラマーだから、ほかの言語も好きでやってる
でも特にプログラムに興味なくて仕事でCOBOLしかしない人は
COBOLだけしか知らないってことは多いと思う

510 ：wolf ◆8VH3XAqjlU ：2008/06/15(日) 19:59:55

>>507
大分誤解されていますね

COBOL'erの皆さんは勝組みなのです
野良犬のように餌を漁り回る必要がない優雅な方たちを指します

511 ：デフォルトの名無しさん：2008/06/15(日) 20:07:05

かもしれないな

512 ：デフォルトの名無しさん：2008/06/16(月) 01:30:09

>>500

金融系では、30年前のソースはざらにある
だいたい、3次オンが1980年代
このときだって全面的にソースを書き直したわけではない

そういうおれも10数年前まで、COBOL69準拠コンパイラで保守してたw

513 ：デフォルトの名無しさん：2008/06/16(月) 01:41:47

>>503

処理による
言語には向き不向きがあるわけ
使用する機械にもよるし。

zシリーズとかGSシリーズで開発している人とPCのみの人では
思考の方向がちがうかもしれん

514 ：デフォルトの名無しさん：2008/06/16(月) 03:31:28

未だに1976年作成のプログラムを毎年メンテしているうちの部署って・・・

515 ：デフォルトの名無しさん：2008/06/16(月) 04:00:21

>>514
ポジティブに考えようぜ！
きっと仕事を作り出すのが上手いんだ。

516 ：デフォルトの名無しさん：2008/06/16(月) 04:04:06

>>514
それで生活に不満あるなら問題も感じなくもない

でも小洞の水準だとむしろ勝ち組な人生送ってそうな気配

517 ：デフォルトの名無しさん：2008/06/16(月) 12:05:57

コボラーは勝ち組。
若い奴らもコボラーがいいって！！
ＩＴでこんな気楽な言語ないよ！！

518 ：デフォルトの名無しさん：2008/06/16(月) 13:27:15

>>517
証券や銀行の勘定系につっこまれるとそんなことは言ってられなくなる
年中募集してるよ
東陽町あたりでw

言語の問題じゃなくほとんど会社の体質でそ
メーカーあたりでまったりやるには最高だけどね

519 ：デフォルトの名無しさん：2008/06/16(月) 15:50:04

>>514
よくワカランけど、プログラムソースに書くべきではないことを
ソースに書いているのだとオレの勘が言っていますが？

520 ：デフォルトの名無しさん：2008/06/16(月) 17:14:00

このおばちゃんは元気でやってるの？
この画像がニュースで流れて以来、情報が無いのですが
ちゃんと避難できたでしょうか？
http://2chart.fc2web.com/2chart/obachannnigeteeeeeeeee.html

521 ：デフォルトの名無しさん：2008/06/16(月) 18:27:56

>>481
ポインタが分からずに仕事できているんだから良いじゃない。
データ構造とか、関数のポインタとか、気にしなくて良い仕事なんだから、
幸せってことで。

522 ：デフォルトの名無しさん：2008/06/16(月) 19:12:36

ランフロー、仕様書作成マシーンになるとCOBOLすらうっすら忘れるからw
読めば思い出すんだけどね

523 ：デフォルトの名無しさん：2008/06/16(月) 22:39:21

>>481
COBOLでもアドレス渡しはできるんだが。

524 ：デフォルトの名無しさん：2008/06/17(火) 01:21:37

COBOLのアドレス渡しは今はほとんど使わない、てか使わせない。
昔のオンラインのようにメモリ空間小さかった時の名残です。
今は、必要ないし、むしろ危なくて使わせられない。
アベンドの嵐でデバッグすらできねえだろう。
おそらく。

525 ：デフォルトの名無しさん：2008/06/17(火) 03:59:50

関東だったら、COBOLだけでも食っていけるんだろうけど、
関西じゃ、COBOLオンリーの年寄りは、かなり厳しいのが現状。

526 ：デフォルトの名無しさん：2008/06/17(火) 09:52:57

おそらくアドレス渡し使ってる。

527 ：デフォルトの名無しさん：2008/06/17(火) 23:36:40

>>524
アドレス渡しでのABENDの原因はプログラマーの質によるものだろ。

528 ：デフォルトの名無しさん：2008/06/17(火) 23:41:17

つーか、某信託銀行なんて、PL/Iでアドレス渡しを強制してるからな。
アドレス概念がわからないPGは超低級だろう。

529 ：デフォルトの名無しさん：2008/06/17(火) 23:46:57

まあ、どっちにしても、おまいらが意識するかしないかの違いで、内部的にはアドレス渡しが行われている。
例えば：
CALL HOGEHOGE USING PARM-1 PARM-2.
だったとする。
PARM-1のアドレスとPARM-2のアドレスがパラメータリストに入れられて、そのパラメータリストの先頭アドレスがレジスタ1に入れられてCALLされる。
パラメタリストの最後のPARM-2のアドレスの先頭BITが立つ。
64ビットモードではどうなるか知らんが。

530 ：デフォルトの名無しさん：2008/06/18(水) 10:11:20

>>529
おまえアホか。
言語仕様で隠蔽されたアドレス渡しなど、ユーザーにとってはどうでも良い事だ。
>>528
アドレス概念が判らないＰＧ、モサモサ居るんだよ。
>>527
プログラマの質かもしれない。
しかしCOBOLコーディングでアドレス渡しがどうしても必用だという局面に会ったのは
俺は１回きりだ。それも３０年前の話だ。
COBOLにアドレス操作は必要ない。

531 ：デフォルトの名無しさん：2008/06/18(水) 14:38:12

おれのなまえは、子簿・らー太郎。
アドレス渡しとか細かいこと言ってるんじゃないよ！！
ＣＯＢＯＬにはビッグシステムが似合う。
ビッグになりたければ子簿らーになれ！！
ヤッホーーーーーーーーーーーーーーーーーーー
ーーーーーーーーーーーーーーーーーーーーーーーーーー
子簿らーは無敵！！

532 ：デフォルトの名無しさん：2008/06/18(水) 16:43:27

良い病院を紹介しますよ

533 ：デフォルトの名無しさん：2008/06/18(水) 17:43:38

>>530
＞COBOLにアドレス操作は必要ない。

予約語に「POINTER」が含まれていることは知ってるか？

534 ：デフォルトの名無しさん：2008/06/18(水) 17:52:24

POINTER使ったアドレス渡しなんて生保のオンラインじゃ普通だよな
バッチでもだけど
でかいエリアの受け渡しをモジュール間でしなくて済むからこっちの方が安全

535 ：デフォルトの名無しさん：2008/06/18(水) 19:41:38

アクセスくらい使えるようにするか
コボラーだけど

536 ：デフォルトの名無しさん：2008/06/18(水) 20:06:09

>>530
>527-529は全部俺なんだけど。

537 ：デフォルトの名無しさん：2008/06/18(水) 20:06:24

>>535
ホストのRDBをアクセスに引っ張ってデータの検証するとか、逆に持っていくとかいろんな使い道がある（というか、やらされてるがw

538 ：デフォルトの名無しさん：2008/06/18(水) 20:57:43

>>533
> 予約語に「POINTER」が含まれていることは知ってるか？

全く知らんかったよ。
COBOLはポインタのような危険で難解な概念を
極力排除したガチムチの現場重視の言語だと
思っていたのに・・・ちとショックだ。
そのキーワードの使い方知らんからどうでもいいけど。

539 ：デフォルトの名無しさん：2008/06/19(木) 11:44:02

おれのなまえは、子簿・らー三郎。
またアドレス渡しとか細かいこと言ってる！！
あぽか？
ビッグになりたければ子簿らーになれ！！
ヤッホーーーーーーーーーーーーーーーーーーー
ーーーーーーーーーーーーーーーーーーーーーーーーーー

子簿らーはさいこうーーーーーーーーーーーーー！！

540 ：デフォルトの名無しさん：2008/06/19(木) 15:56:54

>>538
業務側のモジュールではすご〜く安全な使い方してますよ
とってもコボルちっくな感じで

危ない橋を渡るのはIO関係の共通モジュールだけです

541 ：デフォルトの名無しさん：2008/06/20(金) 20:40:01

ADABASとかNATURALって今後どうなるの？
ADABASなんかはもうDB2に移行する動きらしいけど

542 ：デフォルトの名無しさん：2008/06/20(金) 21:36:55

アダバス、ナチュラル・・・
もう見たくない
＞＝でフェッチすんなっつーのw
VSAMより感じわりーっつーの
素直にDB2使えっつーの
ナチュラルのソース汚ねぇっつーの

543 ：デフォルトの名無しさん：2008/06/20(金) 23:51:14

いや、見たくなくても・・・

いや、なんでもないが。
いやほんと。

黙れ。

544 ：デフォルトの名無しさん：2008/06/21(土) 08:19:55

COBOLの10倍以上の生産性がどーたらとか言うアレか

545 ：デフォルトの名無しさん：2008/06/21(土) 09:37:14

>>544
俺がソース読んだ感想だけど、
ADABASもCOBOLでコントロールした方がはるかにわかりやすい
そして保守しやすい
NATURALは意味ない
変数定義の汚さにはあきれるばかりです

546 ：デフォルトの名無しさん：2008/06/21(土) 09:55:34

COBOL歴3年以上の人にちょっと質問

保守メインのところ（ほとんどそうだと思うけど）は、
分析（ソース読むなど）→コーディング→テストでやってると思うけど、

テストってどの程度細かくやってます？
まさか複数条件網羅ですべてのパターンを・・・なんてことはしてないと思いますが

最近、COBOLなんて書いたとおりにしか動かないから木を見て森を見ないような細かい
テストパターンは無意味な気がしてます
修正、スペック追加時は特に

コボラーになって何か無駄なテストばっかりしてる気がしてならない今日このごろです

547 ：デフォルトの名無しさん：2008/06/21(土) 10:16:00

>>546
画面系は微妙だけどバッチ系の処理だと、基本的にテストは
全てのケースに対してやる。複数条件含めて網羅する。

ただ、多くの場合現実的に不可能なケースが多いので、
>>546みたいな意見はわかる。

だた漏れは開発環境がiSeriesなので、SQLやPythonでテストデータの自動生成や
検証用のSQLがサクサク作れるので、「複数条件網羅ですべてのパターン」は
別に辛くない。

職場によるが「無駄なテスト」と思うなら上司に意見汁。
正直、COBOLしか知らん上司に言っても無駄だと思うが。

548 ：デフォルトの名無しさん：2008/06/21(土) 13:11:25

>>546
木を見て森を見ないのはダメダメ。少なくとも木は見ろミタイナ。

549 ：デフォルトの名無しさん：2008/06/21(土) 13:54:57

>>547
そんな便利ツール無いっす
COBOLしかできない人ばかりです

他部署ですが、テストを全くしないで稼動させたことで処理が全コケ、
なんてことがたまに起きる典型的なアホユー子です
仕事の半分以上がテストです・・・

550 ：デフォルトの名無しさん：2008/06/21(土) 15:00:39

>>546
テスト楽しいじゃん。
頭抱えてコーディングするよりも、悩まなくていい。
日々淡々と作業するだけでいいのだから。

自分は保守の場合、修正要件が少ない分、テストは深くやるよ。
こんなのあり得ねえだろ、というくらいマニアックな境界条件を
洗い出してテストする。
例え修正が一行のみであっても、データとロジックの絡みが
変わり、意外なバグが露見することがあるからね。

551 ：デフォルトの名無しさん：2008/06/21(土) 16:52:33

こぼーーーーーーーーーーーーーーーーーーーーーーーーーー
ーーーーーーーーーーーーーーーーーーーーーーーーーーーー
ーーーーーーーーーーーーーーーーーーーーーーーーーーーー
ーーーーーーーーーーーーーーーーーーーーーーーら最高！！
といいつつ．ＮＥＴ系にはまっている俺さいこう！！
ADABASなんてくだらない言語の会話してるんじゃないよ！！

552 ：デフォルトの名無しさん：2008/06/21(土) 16:54:47

日々淡々と作業するだけなんて全然楽しくないじゃん。
デスマに追われて過労臨死体験のギリギリの日々を生きる。
これが人生ってやつの醍醐味だ。山中鹿之介も言ってるじゃん。

553 ：デフォルトの名無しさん：2008/06/21(土) 18:33:21

>>551
アダバスはDBですw
その操作言語がナチュラル
COBOLでも操作可でやんす

>>550
テスト楽じゃないYO
テストしたいモジュールまで届かなかったり、その部分まで届かなかったり

ランフローと仕様書書いて、その後の工程を外注の人にやってもらう方がよっぽど楽

554 ：デフォルトの名無しさん：2008/06/21(土) 21:46:35

複数の業務で使ってるライブラリにバグが....
修正自体は簡単だけど、影響範囲が広くて大変です。
単体だけで済ませたいよーーーー;;

555 ：デフォルトの名無しさん：2008/06/22(日) 07:20:58

>他部署ですが、テストを全くしないで稼動させたことで処理が全コケ、
>なんてことがたまに起きる典型的なアホユー子です
>仕事の半分以上がテストです・・・

ウチの職場だと
・期間が短い
・ドキュメントが整備されてない。
・COBOL以外の言語知らない
・２０年前近くの開発ルールを神の啓示と思っている

って基本姿勢があるから

・現状分析（60%)
・仕様書作成:書類仕事(30%)
・コーティング(1%)
・テスト(9%)

ってノリだな。
お約束でテストケース不足で本番でアベンドしまくりだ。

ドキュメントが電子化されている前提かつ現在の手法で開発すれば
開発期間は1/5になって品質はメチャ上がるんだが、
そういう事をしないのがCOBOLerたる所以なんだろうなぁ。

556 ：デフォルトの名無しさん：2008/06/23(月) 16:58:24

>>555
ちなみにアホユー子の場合は、
・現状分析（30%)
・仕様書作成:書類仕事(10%)
・コーティング(20%)
・テスト(40%)
（外注の方の作業を含む）

やっぱり資料はほとんど無かったです
仕様書もランフローもどちらも・・・
そもそも仕様書ではなく、プログラムリストに直接手直しする箇所を手書きするだけとか普通ですw
アベンドで処理が止まることは少なかったです
ランダムなデータを大量につっこんでの疎通テストは行ってましたから
ただ、そもそも仕様がおかしかった、レアケースに対応できてない、普通のケースにも対応できてない
などの理由でつい数ヶ月前に稼動したシステムの不備対応をすることが妙に多かったです

557 ：デフォルトの名無しさん：2008/06/23(月) 17:03:47

よくオープン系の人が、
「資料がそろってればCOBOLのシステムなんか余裕で保守してやんよ」
と言いますが、そんなものはありませんw
ひどい会社だとレコードレイアウトすらありません
入出力ファイルにCOPY句すらあててないところもあり、レコードのレイアウトを調べるだけでも、
JCLを遡ったり、後続JOBまでみたり、とアホなことで一苦労です

ちなみにバグは少なくないです
多くもないですが
汎用モジュールのパラメータを切り間違えてるとか普通にあります
絶対にテストしないで稼動させたでしょ、これ、というものが結構あります
金融系は結構テストしますが、そもそも子会社の人間の仕事に対するモチベーションが低いので
必然的にテスト不足によるバグが発生します
短納期、複数案件を一人の担当者が抱えていることも原因のひとつですが

558 ：デフォルトの名無しさん：2008/06/23(月) 18:22:49

てか、COPY句って何？

559 ：デフォルトの名無しさん：2008/06/23(月) 19:01:21

>>558
#include みたいなもん

560 ：デフォルトの名無しさん：2008/06/23(月) 19:05:04

>>557
それってオープン系でもある。
会社の体質的なことなんだろうナ。

561 ：デフォルトの名無しさん：2008/06/23(月) 20:34:39

ま、短納期案件はえてしてある事。
そういうこまい仕事は取らない様、営業にきつく言ってやんな。

ある程度のスパン・金の掛かる仕事を一つ、通しで経験すると
・現状分析
・仕様書作成:書類仕事
・コーティング
・テスト
の詳細度が変わって来るので、ＳＥらしい仕事になるよ。

終わるとぐっと自信が付いて来る。

562 ：デフォルトの名無しさん：2008/06/23(月) 21:22:54

保守なお仕事

プログラムを読む→なおす→テストするの無限ループ

まさに下流スパイラル

563 ：デフォルトの名無しさん：2008/06/23(月) 22:22:41

>>562
しかもなおす内容がバグ修正ばかり。

564 ：デフォルトの名無しさん：2008/06/23(月) 23:53:28

ユー子に営業なんていません（泣）
天下り出向者にまともな開発経験なんてありません（泣）

565 ：デフォルトの名無しさん：2008/06/24(火) 12:13:51

ＣＯＢＯＬだと、自治体系が居残る可能性高いって聞いたけど、どうなの？
予算削減状態だから、地方でコボラーでやっている為には自治体系に強い会社が強いよね。

566 ：デフォルトの名無しさん：2008/06/24(火) 13:09:16

>>565
基本的には生保、損保あたりは残るのかと
公共系はちょっと・・・
水道局のシステムは数年前のリニューアルで汎用系は廃止されたと記憶しております

567 ：デフォルトの名無しさん：2008/06/24(火) 18:38:07

>>565
地方自治体は合併を期にオープン系に移行してるところ多いよ。
メーカーもオープン系しか売り込みづらいとのこと。
規模にもよるけど、VB・VC・JAVA・独自言語のシステム見たことある。
データ移行なんかではCOBOLが使われることも多いけどね。←参加したｗ
全国規模の住○ネットなんかもWindowsだし
もうひとサイクル汎用機でというユーザもいるけどね。

568 ：デフォルトの名無しさん：2008/06/25(水) 07:05:50

すんません。
昔ながらのおっちゃんに 9項目とCOMP-3項目をIFの中で比較すると
実行時エラーになるか永遠にマッチしないと言われやした。

実際に試してみると自動的に型変換して問題ないんですけど、
今時そんなコンパイラー使っているところあるんですか？

569 ：デフォルトの名無しさん：2008/06/25(水) 11:06:26

汎用機を近い将来に廃止する予定のメーカーなんかは
超古いコンパイラ使ってたYO

>>568
そういう比較ができることを今知った
金融系はパックはパック同士、ゾーン数字はそれ同士が基本だった

570 ：デフォルトの名無しさん：2008/06/26(木) 07:09:06

>>569
ま、それが普通てか本来のスタイルだわな。
>>568のようなことやってると、コンパイラに助けられてるから良い様な物の、
バグッたときに検出が困難になるよ。

571 ：デフォルトの名無しさん：2008/06/26(木) 12:17:47

俺は40代コボラー。
40代以降の人は、あと、20年ぐらい持ってくれればいい！！と思っている。

572 ：デフォルトの名無しさん：2008/06/26(木) 15:22:56

やばい。７月からCOBOLの現場に配属されることになっちまった。
未経験からでも、仕事しながら覚えればいいらしい。
今からCOBOL覚えても、未来なんてあるのか？
お先真っ暗な気分だぜ。

573 ：デフォルトの名無しさん：2008/06/26(木) 19:49:34

>>572
意味わからん。
技術は未来のために覚えるのではなく
今を生きるために覚えるものだろ。
こういう些細なことでいちいちネガってる
ような香具師に未来はない。

574 ：デフォルトの名無しさん：2008/06/26(木) 20:59:21

>>571
俺もそう思っている。40台半ば

575 ：デフォルトの名無しさん：2008/06/26(木) 22:56:12

20台の俺はあと10年もってくれればいい

576 ：デフォルトの名無しさん：2008/06/27(金) 00:06:17

COBOLの現場に配置される事がお先真っ暗だと思う。
まあ携帯電話系に置き換えても似たような印象はあるのだが。

577 ：デフォルトの名無しさん：2008/06/27(金) 02:27:55

コボラーの場合。言語の知識より
業務知識の方が銭になることが多いと思う

少なくとも俺はそうだった。

578 ：デフォルトの名無しさん：2008/06/27(金) 06:40:43

真に知識が役に立つと自負してるならコンサルになればいいのに。

579 ：デフォルトの名無しさん：2008/06/27(金) 16:41:16

業務知識云々を持ち出すと負け犬の遠吠えになるからヤメれ。

業務知識があって技術も広いヤツなんて、なんぼでもいるぜよ。


＜COBOL のように死んだ言語＞
http://www.ibm.com/vrm/newsletter_10844_3545_78682_email_DYN_1IN/hzfk90549513

↑中身的には「Javaは死なない。COBOLのように」という趣旨。

580 ：デフォルトの名無しさん：2008/06/27(金) 20:57:20

いずれ死ぬだろうが、まだおもいっきり現役で生きてるじゃん

581 ：デフォルトの名無しさん：2008/06/27(金) 23:44:43

>>579
どこが「負け犬の遠吠え」なんだい？
業務知識の広さを言ってるんじゃない。彼は深さを言ってるんだ。
浅く広い業務知識。浅く広い言語レベル。
浅さはすぐにメッキがはげる。

COBOL一筋、一業務知識充分。これさえ有ればこの業界で生きて行ける。

582 ：デフォルトの名無しさん：2008/06/28(土) 01:33:29

>>570
暗黙的型変換も言語仕様書に定義されていないんだからしょうがないか。

583 ：デフォルトの名無しさん：2008/06/28(土) 06:10:02

>>581

それを負け犬の遠吠えと世間では言う。

584 ：デフォルトの名無しさん：2008/06/28(土) 06:39:06

>>583
負けてないじゃない。
毎日定時退社で昼休みも丸々一時間。
それで十分給料をもらってる。
携帯開発のスレなんか見てると
COBOLerの自分が勝ち組にしか見えないのだが。

585 ：デフォルトの名無しさん：2008/06/28(土) 07:20:07

勝ち組とか言うヤツはイタイ

586 ：デフォルトの名無しさん：2008/06/28(土) 11:23:37

>585
それって負け犬の遠吠えじゃ・・・

587 ：wolf ◆8VH3XAqjlU ：2008/06/28(土) 12:22:26

>>585
使い捨て労働力の場合はCOBOL'erに限らず負け組みですね
COBOL'erと呼ばれるには何らかの参入障壁の存在とその内側でﾇｸﾇｸしていないと

>>572
悲観するのはまだ早い
現場でプログラミングの仕事が貰えれば未来はバラ色貰えなければｵﾜﾀwです
未経験からなら言語は(C,Java,COBOL,etc)何でもok!
学部や院でかなり勉強している場合は手続き型以外で開発出来るのでCOBOLは寄り道かな？

588 ：デフォルトの名無しさん：2008/06/28(土) 12:23:09

F通のCOBOL-85のマニュアルには書いてある。

COMPといえば、EBCDIC系とASCII系だと、当然ながらあわない。
コード変換がやっかいだったりする。

589 ：デフォルトの名無しさん：2008/06/28(土) 13:53:51

Nの言語仕様書にも書いてるよ。

今時COBOL使うのもナンセンスだけど、
トラぶる筈もないことに昔の経験というだけで
いつまでも恐れていることに身震いする。

590 ：デフォルトの名無しさん：2008/06/28(土) 18:11:27

だから言ってるだろ！！
年取ったら言語なんて意味なし！！
Java VB C C++・・・で下流やっているより、業務知識強いほうが生き残る可能性大！！
たぶん小僧が吼えているだけ！！

591 ：デフォルトの名無しさん：2008/06/28(土) 18:51:13

負け犬の遠吠えｷﾀｰ

592 ：デフォルトの名無しさん：2008/06/29(日) 01:05:24

というか、役割がかわっただけだろ。。。

593 ：デフォルトの名無しさん：2008/06/29(日) 20:58:08

ユークリッド互除法の宿題ができません…

594 ：デフォルトの名無しさん：2008/06/30(月) 01:23:53

>>590
設計さえよければ言語なんて関係ない。
そう思っていた時期もありました。

でも言語にはやっぱパワーレベルがあるってか、
COBOLだと（業務分析）設計と実装技術にギャップがありすぎるんだぜ……。

595 ：デフォルトの名無しさん：2008/07/01(火) 00:16:24

>>594
実装設計の粒度が荒かったんじゃないかな。
あるいはDBのレコード設計が大雑把だったとか。
COBOLはCOBOL。
それ以上でもそれ以下でもない。
俺の経験した限りでは、１本のCOBOLにRDBアクセスが多過ぎる事による複雑化・煩雑化、
を感じた。

596 ：デフォルトの名無しさん：2008/07/01(火) 01:22:08

コントロールブレークとマッチングがCOBOLでのバッチ処理の大半だとおもうわけです

なんでもかんでもDBにすればいいというわけでもなく
システムの規模にもよるだろうし

業務知識に関しては無いよりあった方がいいしょ

597 ：デフォルトの名無しさん：2008/07/01(火) 06:30:29

業務知識があろうとなかろうと横長ＤＢな設計してたらｱﾌｫとしか言いようがないが。

598 ：デフォルトの名無しさん：2008/07/01(火) 11:09:01

正直RDBべったりな設計ならPL-SQLでいいじゃんって思う。

599 ：デフォルトの名無しさん：2008/07/01(火) 12:46:48

ソースにSQL埋め込むのはもう時代遅れだべ。

※COBOLに向かって時代遅れってのも野暮だが。

600 ：デフォルトの名無しさん：2008/07/01(火) 16:03:10

確かにPL/SQLってロジック部分にSQLが入り込んでいて
非常に気持ちが悪い。最近のオープン系のように
直接的なデータアクセス部分と業務的なロジックは
階層分けした方が奇麗に仕上がると思うな。


業務知識があればCOBOL一本で充分だというのは
どうかと思うね。ちょっと世界が狭すぎないか？

これを書くと荒れるかもしれんが、COBOL一本というヤツに
対しては、「知的好奇心の少ないヤツ、業務上の好奇心に
欠けるヤツ、ひいては恐らく仕事の厚みの無いヤツ」と
思ってしまうオレは心が狭いかな。

601 ：デフォルトの名無しさん：2008/07/01(火) 17:17:10

目立たぬように　はしゃがぬように

似合わぬ事は　無理をせず

他人の心を　見つめ続ける

時代遅れの　男になりたい

602 ：デフォルトの名無しさん：2008/07/01(火) 21:02:59

男でなく「漢」と書いたほうがかっこいい

603 ：デフォルトの名無しさん：2008/07/01(火) 21:19:26

それは世間一般でチキン野郎と言うのでは・・・

604 ：デフォルトの名無しさん：2008/07/02(水) 00:17:48

>>602
暴漢、痴漢、、カッコいいな

605 ：デフォルトの名無しさん：2008/07/02(水) 00:21:36

あかん

606 ：デフォルトの名無しさん：2008/07/02(水) 12:21:59

飲んで〜♪

607 ：デフォルトの名無しさん：2008/07/03(木) 20:04:18

高校でCOBOL習ってるんだけど効率悪い気がするんだがどうなん？
1年で全商1級とって、もう2年で日商1級とるらしいんだけど、、なんだかなぁて

608 ：デフォルトの名無しさん：2008/07/03(木) 20:44:51

>>607
何をもって効率が悪いと言ってるのか、判らん。
説明してみ。

前にもこんなレス有ったな。

609 ：デフォルトの名無しさん：2008/07/03(木) 20:58:54

公立が悪いと思うんなら、別の方法で勉強するなり
別の言語を勉強すればいい。子供じゃないんだから

610 ：デフォルトの名無しさん：2008/07/03(木) 21:05:11

効率うだうだ言う奴は、実際のところノーアクション
「効率の良い勉強方」を求めて、いつまでも勉強を始めない

611 ：デフォルトの名無しさん：2008/07/03(木) 21:11:00

高校生は子供と言えば子供だと思うが。

しかし、効率悪いってなんだろう？
僅かな学習コストで「使えるアプリ」を組むのが目的なら
PythonでもRubyでも使っとけと思うが。

612 ：デフォルトの名無しさん：2008/07/03(木) 21:18:57

商業高校に行ってる時点でDQNだろ？

613 ：デフォルトの名無しさん：2008/07/03(木) 21:29:12

まあ、商業高校が全部DQNとは思わんけど、
知っているCOBOLerで商業高校時代にプログラムやっていたと
自慢なのかよくわからん職場の後輩がいた。

しかし現代においてはCOBOLよりもAccessやSQL出来るほうが
重宝されるので、ﾋﾞﾐｮｰな立場の人間になっていた。

614 ：デフォルトの名無しさん：2008/07/03(木) 21:39:12

作業効率じゃまいか。と意訳。

たとえばおんなじプログラムでもCobolで100行かかるところを
PythonとかRubyなら10行くらいでできたり、
標準ライブラリで1,2行で出来たりすること、ちょっと悲しくなったりする。
（特に文字列がらみの処理とかね）

615 ：デフォルトの名無しさん：2008/07/04(金) 00:13:52

COBOLだとやたらに文字をタイプしないといけないとかじゃアルマイカ？

616 ：デフォルトの名無しさん：2008/07/04(金) 00:15:47

COBOLの場合、PROCEDURE DIVIDION にたどり着くまでが長いかもな
それなりの開発規模があるところなら、似たようなソース持ってきて
出来ちゃうことも多いけど。

高2で簿記日商1級は可能でしょ。原価計算のところで躓きやすいが。

perlでもrubyでも覚えればいいじゃん。

617 ：デフォルトの名無しさん：2008/07/05(土) 16:34:37

俺も商業高校だったが、学校のCOBOLじゃつまらなかったから
家でHSPとかDelphiとかRubyとかやってたよ

618 ：デフォルトの名無しさん：2008/07/06(日) 17:13:37

素朴な疑問: COBOL って事務処理系以外のどこに使えますか?

619 ：デフォルトの名無しさん：2008/07/06(日) 18:43:45

他の用途に使おうとする発想すらねーよ w

620 ：デフォルトの名無しさん：2008/07/06(日) 20:26:56

○×ゲーム作った
はい、素直にBASICで作った方が開発効率よかったです。

621 ：デフォルトの名無しさん：2008/07/06(日) 21:06:54

正直、事務処理ですら・・・。

622 ：デフォルトの名無しさん：2008/07/06(日) 21:12:52

POS端末の制御プログラムをCOBOLで実装してるのを見た事有る。
GOTO文の固まりで、BASICみたいだった。
事務所理系も画面定義やら帳票定義やら、なんやらかんやら、メンドイ。

623 ：デフォルトの名無しさん：2008/07/08(火) 23:49:53

2次元テーブルの集計処理ってどうやってやるのですか？ｗ

624 ：デフォルトの名無しさん：2008/07/09(水) 00:33:10

>>623
PERFORMで回せばすむだろ

625 ：デフォルトの名無しさん：2008/07/09(水) 00:41:10

>623
PERFORM２つ重ねるｗ

626 ：デフォルトの名無しさん：2008/07/09(水) 02:20:16

なにもおもしろくない

627 ：デフォルトの名無しさん：2008/07/10(木) 23:40:34

PMだが、コボラーがいなきて困ってる。
システムのリプレース要員として、読めて、一部修正して、テスト仕様が書けて、テストができるだけでいいのに。
人月100でみつからねぇ！

628 ：デフォルトの名無しさん：2008/07/11(金) 02:02:14

まだ若いけど俺が行こうか？

629 ：デフォルトの名無しさん：2008/07/11(金) 07:14:57

会社的にフリーと契約できないから、瑕疵担保責任が取れるようなとこに所属してくださいな。

630 ：デフォルトの名無しさん：2008/07/11(金) 09:41:11

>>629
こういうのって、100%ジョークなの?

631 ：デフォルトの名無しさん：2008/07/11(金) 21:46:28

要員が足りないのと、フリーの人と契約できないのはほんと。
プログラムの能力だけではなく、一般的なコミュニケーション能力は標準レベルを期待します。
わからないことやできないことをはっきり言ってくれる人。
自分のスケジュールに見通しがつく人。
問題があった時にすぐに報告できる人。
勝手に自分の判断で事を進めない人。

難しい話ではない。

632 ：デフォルトの名無しさん：2008/07/11(金) 22:46:17

条件がよければ転職しますよ

633 ：デフォルトの名無しさん：2008/07/11(金) 23:44:38

うちはSIerだからプログラマーはいりません。
条件は30才750万ぐらい。
上場なら並かな？

634 ：デフォルトの名無しさん：2008/07/12(土) 09:21:13

>>631
悪いが今時COBOLerしている人でそのレベルはかなり難しい。ｗ

ってウチの会社もホントはフリー禁止なんだけど、真の偽装派遣と言うか
偽装フリーが何人かいるな。
毎日タクシーで通勤しているゴージャスな人もいる。

635 ：デフォルトの名無しさん：2008/07/12(土) 18:13:33

一般的なビジネススキルを求められないのはきついね。
最新技術指向なのもいいけど、需要を考えると、コボルはまだまだニーズはある。
金融の勘定系はまだまだコボルが多いし。
リプレースでオープン化のリスクは取れない。

636 ：デフォルトの名無しさん：2008/07/12(土) 19:25:58

コボラーは技術よりも業務知識のがはるかに大事だと思う

637 ：デフォルトの名無しさん：2008/07/12(土) 19:27:05

コボラーじゃなくても担当する部分に必要な業務知識要るでそ

分業前提だから全部じゃないにしても

638 ：デフォルトの名無しさん：2008/07/12(土) 20:56:03

コボラーなら業務知識が必要、の意味がわかりません。
プログラマには必要ないかもしれないけど、設計するにはまぁ必要。
コボルが組めることが最低条件で、技術的にプラットフォームやコイパイラの組み込み方をより多く知っている方がより好ましい。

639 ：デフォルトの名無しさん：2008/07/13(日) 08:02:32

思うんのだが、コボラー以前にニートじゃないんだから、
会社で働くならビジネススキルは要求されるにきまってる。

そして、コボルは「まだまだ」じゃなくて「かろうじて」ニーズがある。

設計するなら業務知識は「あって当たり前」だな。

「技術よりも業務知識」なんて言うのはエンジニアでありながら
技術のない人間が言う台詞だな。

つか業務知識を言い出すと負け犬の遠吠えになるからヤめれ。

640 ：デフォルトの名無しさん：2008/07/13(日) 11:02:39

どうしてお前らはそう極端なんだ
「他の言語に比べて」って言ってるだけだろう
COBOLは文法が読みやすいから

641 ：デフォルトの名無しさん：2008/07/13(日) 17:45:13

もっと広い視野で考えられないのかね？
言語なんてただの作り方の違いだけじゃん。
コボルが悪くて、JAVAがいい、とかないんだよ。
適性も考えずにシステム構築するのはおかしいよ。

642 ：デフォルトの名無しさん：2008/07/13(日) 20:08:02

>>627
本当？その程度なら掃いて捨てるくらい人材はいるはずなのだが･･･。

643 ：デフォルトの名無しさん：2008/07/13(日) 20:16:42

>COBOLは文法が読みやすいから

ぶっちゃけ、その主張をしているのはCOBOLerだけに思えて仕方ないが。
読みやすさ最強はアセンブラだと思う。（ｗ）

COBOLの読みやすいと勘違いしているのは、「COBOLが出来る事が少ない」と言う
意味で解読しやすいとか言うなら解らないでもないけど、
ロジックの流れを追うとか言う意味ならOOな言語の方がメソッド名に
なんとなくのルール(getXxxx,isXxx)があるから現実的に読みやすい。

644 ：デフォルトの名無しさん：2008/07/13(日) 22:26:21

パフォーマンス面だとCを余裕で上回る。
１日1000万トランだとコボルでないと処理しきれん。
アンチコボルが多いのはなぜ？
金融のシェアは圧倒的なのが事実。

645 ：デフォルトの名無しさん：2008/07/14(月) 00:15:33

>パフォーマンス面だとCを余裕で上回る。

どう考えてもＣの方が上回っています。
ヴァカじゃねーの？

>１日1000万トランだとコボルでないと処理しきれん。
>アンチコボルが多いのはなぜ？
>金融のシェアは圧倒的なのが事実。

某メガバンクはアセンブラで実装していました。
シェアは圧倒的でもなんでもありません。
しかも今、COBOLから移行中。


金融って小さい農協か組合かカード会社（まあコレはピンキリだが）か？

646 ：デフォルトの名無しさん：2008/07/14(月) 00:20:45

1000万トランザクションは、小さい金融機関では発生しないと言ってみる。

647 ：デフォルトの名無しさん：2008/07/14(月) 01:41:08

表面上COBOLでも、ファイル更新やDB周りは
外部モジュールをCALLしていると思うが

648 ：デフォルトの名無しさん：2008/07/14(月) 02:44:17

千万虎くらい、必要になったら割って増設できる状態キープするがな
Java屋がスケール性のある設計云々とか無い智慧絞ってる間に
普通に置換で対応して手作業テスト済ませてはい終わり

普段偉そうなJava屋や、フットワークの軽さ自称してるPHP屋が
ユニットテストとか組みまくってるのに変更時に
いきなり障害起こしてるの見ると、おれら苦笑するしかないね

「設計舐めるな」と人を笑う暇で、手前が運用舐めんなと。

649 ：デフォルトの名無しさん：2008/07/14(月) 06:45:02

障害起こすのは言語じゃなくて人間なワケだが。

そして運用が設計を語るほど滑稽な事はない。

しかし、
＞普通に置換で対応して手作業テスト済ませてはい終わり

こんなヴァカがいるから後任の技術者が泣く羽目になるわけだが、
自分さえよければ良いと言うゆとりかよ。

650 ：デフォルトの名無しさん：2008/07/14(月) 11:39:26

頭が痛くなるような文章が続くなぁ。

651 ：デフォルトの名無しさん：2008/07/18(金) 07:13:05

良く分らんが、コボラーはひねくれ者のオヤジが多いってことじゃね？
うちでもコボラー不足だけど、本当に人いない。

コボルって業務知識以前のシステム実装知識が大いに必要。
フラグの意味とか、変数のCRUD（Dは無いけどな）とか。
他の言語だともう少し構造化プログラミングしてあるからなー。

なんかそれを知っているだけで業務知識があるって偉そうにしている
オヤジさんたちを見ると、この先どうするんだろ？って不思議に思うよ。

652 ：デフォルトの名無しさん：2008/07/18(金) 15:33:45

>>627

コボラーです。
できますできます。
仕事ください。

653 ：デフォルトの名無しさん：2008/07/18(金) 23:14:23

ＣＯＢＯＬはじじぃばかりで、人余ってるよな
やはり５０代のコボラーは使えん

654 ：デフォルトの名無しさん：2008/07/19(土) 00:45:04

20代のコボラーだけどやりがいのある仕事ください
PCL、内部設計、要件定義も少し経験済み

655 ：デフォルトの名無しさん：2008/07/19(土) 01:21:10

>>654
>20代のコボラー
20代は「COBOLも（やれと言われれば）できます」くらいが望ましい

COBOL案件はシステム単位のまっさらな新規受注なんざマジで
皆無（※私感。もしかして、ある所にはあるのか・・・？）。
保守と引き継ぎ、改良依頼だけで家族養うには無難。
やりがい求めたところで乗り切れないぜ。どこに投げ込まれてもやる事は変わらないからね。

会議に出された際に、阿呆web系SEに言いくるめられない程度の
知識、話術があるべきだろうな。実務はどうあれ出来るかぎり把握しておくべき。

やりがいだけで生きたいなら院でうまいこと研究職見つけて
関数型言語中心の屋を目指した方がいい

656 ：デフォルトの名無しさん：2008/07/19(土) 01:39:56

>>655
大卒だけどオープン系やるつもりだった、それがCOBOLの部に回された
たしかにいまだ完全な新規はないですね
今後の糧に、有りがたく言葉を受け取っておきます

657 ：デフォルトの名無しさん：2008/07/19(土) 08:03:42

別にCOBOLの部だろうと運用だろうとどこでもいいとは思うけど、
そこに３年以上同じ事の繰り返しだとモチベーションが維持できないだろうなぁ。

そしてウチの会社の例だけどCOBOLの部に５年以上いたら
壊れるまでCOBOLに付き合わされる。俗に言う墓場。

しかし、若い人材だと可能性やら適正やら見る意味で色々な部にまわされると思う。

658 ：デフォルトの名無しさん：2008/07/19(土) 09:27:47

やんぐはこぼるがだいきらいじゃのう。
さみしいのう。

659 ：デフォルトの名無しさん：2008/07/19(土) 13:24:11

あー納得。
あの閉塞感は新規開発がないせいか〜。

わかることだけ、できるとこだけやっていればいいという雰囲気だーね。

660 ：デフォルトの名無しさん：2008/07/19(土) 20:29:45

ＣＯＢＯＬはセンスを問われる
動けばいいプログラムつくるな

661 ：デフォルトの名無しさん：2008/07/19(土) 21:06:06

他人の保守作業が99%の現状でセンスもクソもないと思うが。

そして、「動くプログラムは全て美しい」だ。

662 ：デフォルトの名無しさん：2008/07/19(土) 21:20:38

大昔にコボラーしてた者なんですがCOBOLのプログラム公開してるところないですか？
なんか久しぶりに見てみたくなりました
ジャンルは問いませんが出来ればサンプルとかじゃなく実用のものを・・・

663 ：デフォルトの名無しさん：2008/07/19(土) 23:50:30

別に去年のソースも10年前のソースも20年前のソースも大差ないと
感じるが。

664 ：デフォルトの名無しさん：2008/07/20(日) 00:16:33

確実にコメントアウトが増えてソースが汚くなっているけどな。
3案件以上前のソースは残しておいて何か意味あるのかねー…。

COBOLでもリファクタリングしたいよ。

665 ：デフォルトの名無しさん：2008/07/20(日) 01:51:51

えーっとですね
コボラーの人たちは外に出てきてほしくありません
つか、組み込みの親分になられるとすごく困ります

666 ：デフォルトの名無しさん：2008/07/20(日) 02:02:18

・・・COBOLで組み込み？親分？？

667 ：デフォルトの名無しさん：2008/07/20(日) 02:48:14

純コボラーの人は組み込みなんか到底てきない人がほとんどだよ
でもコボラーを長くなってる人の業務知識はなかなのもんだよ

668 ：デフォルトの名無しさん：2008/07/20(日) 08:04:47

負け犬の遠吠えｷﾀｰ

669 ：デフォルトの名無しさん：2008/07/20(日) 08:08:49

>>662
コボルつったら大型の汎用機で、しかも特定の業務に特化したシステムが当たり前だから
オープンソースってのは難しいだろう。

いまでも、商業系の学校以外じゃ学生が勉強するのは難しいって言われているんだから
（opencobolなんてのもあって、敷居は下がっているけど）

670 ：デフォルトの名無しさん：2008/07/20(日) 09:29:49

>>665
COBOL専門にやってたオッサンが、組み込み系事業部の
親分になってしまったんですorz

671 ：デフォルトの名無しさん：2008/07/20(日) 10:16:32

コボラーは基本的に他所ではやっていけない人がほとんどだからなぁ。
諦めろ。
それかもっと上の上司に相談汁。

672 ：デフォルトの名無しさん：2008/07/20(日) 18:59:23

ACOS-2、ACOS-4の仕事は現在、有りますか？

673 ：デフォルトの名無しさん：2008/07/20(日) 22:10:35

OSIV/MSPならあるんじゃね

674 ：デフォルトの名無しさん：2008/07/20(日) 22:27:40

ＮＥＣのＣＯＢＯＬは
ＩＢＭや富士通とはちょっと違うらしいね。

675 ：デフォルトの名無しさん：2008/07/21(月) 10:40:38

COBOL/S ?

676 ：デフォルトの名無しさん：2008/07/21(月) 19:34:50

そうです。
Cobol/sです。
まだあるのですかね。

677 ：デフォルトの名無しさん：2008/07/21(月) 21:39:56

COBOLの異端児 YPS は一刻も早くこの世から消えて無くなれ

678 ：デフォルトの名無しさん：2008/07/21(月) 23:09:32

YPSとはまた懐かしいものを・・・。
ソースコードがそのままドキュメント（詳細設計書）になりますって
うたい文句は良かったんだけどね。
記号だらけの日本語コボルなんて、かえって読みにくくなるだけだったというオチ。

679 ：デフォルトの名無しさん：2008/07/22(火) 07:47:00

汎用機で生き残っているのは銀行・保険業界が多い。
Nはそちらの方面弱いので、流通と運輸と官公庁に残っているのみ。
官公庁も汎用機は随意契約につながるから辞めろという命令がTOPから
出ていてお先真っ暗。

680 ：デフォルトの名無しさん：2008/07/22(火) 10:15:25

随意契約の意味を教えてください。
汎用機、なんでダメなんでしょうねえ・・・。
仕掛けが単純で間違いが起こりにくくていいと思うんですけどねえ。
バリバリ並列処理もできるし。

681 ：デフォルトの名無しさん：2008/07/22(火) 13:04:15

COBOLを基礎の基礎から学ぶのに適した参考書でオススメの参考書はどんなのがあるでしょうか？

682 ：デフォルトの名無しさん：2008/07/22(火) 19:30:38

本はお金が勿体無いですよ〜。
Ｗｅｂでいいんじゃないでしょうかねえ。
http://www16.plala.or.jp/hiyokogumi/3/300.html
ココとかどうですか？

はあ、仕事が見つからない・・・。
俺の人生をＲＥＤＥＦＩＮＥＳしたい。
ＯＣＣＵＲＳ　１００くらいで。
人生のループ、終わっちゃったかな・・・。
もう、ＳＴＯＰ　ＲＵＮの時間かも。
あ、そんなの使わないよね。
ＧＯＢＡＣＫします。

683 ：デフォルトの名無しさん：2008/07/22(火) 21:11:58

YACIIってまだ使ってるとこあるの？

684 ：デフォルトの名無しさん：2008/07/22(火) 22:01:34

>>680
並列処理？

マルチプロセル・マルチスレッドならハードと言うよりプログラミングの問題
⇒汎用機でもバッチジョブはシングルスレッド

デュアルシステムなら汎用機の強みだが、最近はオープンでも実現している
⇒NEC ftサーバ

685 ：デフォルトの名無しさん：2008/07/22(火) 23:38:42

OpenCOBOLてREAD 〜 NEXTはあるくせにREAD 〜 PRIORは無いのな
使えなさすぎる

686 ：デフォルトの名無しさん：2008/07/22(火) 23:40:09

>>683
20年位前に名前変わったぞ。
何だったかは忘れたけど。

687 ：デフォルトの名無しさん：2008/07/23(水) 00:03:10

>>676
うちんところは毎月動いているPGにCOBOL/Sの奴があるよ。
それとかGOTOしまくりとかいろいろある。

688 ：デフォルトの名無しさん：2008/07/23(水) 00:29:55

COBOL/SはコンパイルオプションでCOBOLに展開したソースが
出力できるけどELSE NEXT SENTENCE と　GO TOの嵐。
普通にコーディングした5〜6倍くらいはあったと思う。

689 ：デフォルトの名無しさん：2008/07/23(水) 18:08:30

某銀行だけど
仕様書はYACII
さすがにYPSは使ってない

690 ：デフォルトの名無しさん：2008/07/24(木) 21:40:46

mapperだよマッパー！

691 ：lovelace：2008/07/24(木) 22:02:58

現在COBOLで以下のようなプログラムを作成しています。

受付日と今日の日付を比較して1ヶ月経過したデータと振り分ける。
　1ヶ月経過したものは、削除分のデータとしてディスクに保存
　1ヶ月経過していないものは、保存分のデータとしてディスクに保存

ただし、入力データは、受付日（6桁）に書かれているのは6桁（例：080524）
本日の日付は、システム時間で8桁（例:20080824）

このままでは、桁数が違うので、比較することができないため、受付日を8桁にしたいと考えています。
つまり、「'20'+受付日」としたいのです。

この場合、どのようにすればよろしいのでしょうか？
よろしくお願いします。

692 ：デフォルトの名無しさん：2008/07/24(木) 22:10:46

>>691

01 WK受付日８.
03 FILLER PIC X(02) VALUE "20".
03 WK受付日６　PIC X(06).


・・・・・・


MOVE 受付日 TO WK受付日６.

この後、WK受付日８と、システム時間とを比較して何とかする。
　　

693 ：デフォルトの名無しさん：2008/07/24(木) 22:18:37

01 ウケツケビ.
02 ウケツケビA　　　PIC 9(02).
02 ウケツケビB PIC 9(06).
として、
　MOVE 20 TO ウケツケビA
　MOVE データウケツケビ TO ウケツケビB

　IF　（ウケツケビ（の1ヶ月後）　＜　本日日付）
　　　　　　ホゲホゲ
　ELSE
　　　　　　ホゲホゲ
　END-IF

とやれば出来るけど、このプログラムの難しいのは
「○月○日の1ヶ月後は×月×日」
の判定だと思う。（「○月○日の×日後」は簡単だけど）

まあ、そういう関数なり、サブルーチンが有れば良いけど、この判定は
各業務によって違うから注意が必要。

694 ：lovelace：2008/07/24(木) 22:21:29

お二人とも回答ありがとうございます。
書き忘れたことがあるのですが、判定するのは、年月のみで日は関係ありません。

695 ：デフォルトの名無しさん：2008/07/24(木) 23:05:33

>>694 こんな感じか（西暦2100年問題あり）

01 WK受付日６.
　　03 WK受付年月.
　　　　05 WK受付年　　 PIC 9(02).
　　 　 05 WK受付月　　 PIC 9(02).
　　03 FILLER　　　　 　　PIC 9(02).
01 WKシステム時間８
　 03 FILLER 　　　　　PIC 9(02).
　 03 WKシステム年月.
　　　05 WK受付年　　 PIC 9(02).
　　 05 WK受付月　　 PIC 9(02).
　 05 FILLER　　　　 　 PIC 9(02).

・・・・

MOVE 受付日 TO WK受付日６.
MOVE システム時間 TO WKシステム時間８.

IF WK受付月 = 12 THEN
　　ADD 　1 TO WK受付年
　　MOVE 1 TO WK受付月
ELSE
　　ADD　 1 TO WK受付月
END-IF.

IF WK受付年月 <　 WKシステム年月　THEN
　　削除分
ELSE
　　保存分
END-IF.

696 ：デフォルトの名無しさん：2008/07/24(木) 23:22:40

のちの3000年問題である。

697 ：lovelace：2008/07/24(木) 23:37:36

回答ありがとうございます。

今考えているのは、
　「現在年月の1ヶ月前の年月を別のエリアで計算する」
という方法です。

また、受付年月は、

01 WORK-AREA.
05 WK-UKETUKEBI
10 WK-UKETUKE-YM PIC X(04).
10 FILLER PIC X(02).
01 DATE-AREA.
05 SISUTEMU-DATE.
10 SISUTEMU-NENGETU PIC X(06).
10 FILLER PIC X(02).


と記述します。

698 ：デフォルトの名無しさん：2008/07/25(金) 10:11:02

>>695氏の考え方でいいんじゃないの？
ＣＯＢＯＬやってる人だったら普通にできると思うけど、
そういうの自分で考えないと覚えないよ。

699 ：デフォルトの名無しさん：2008/07/26(土) 00:10:23

>>691
人に聞くことの問題だとは思わんが

未だにファイルに日付を6桁で保持するって

700 ：デフォルトの名無しさん：2008/07/26(土) 06:16:02

うちもやってる。
2000年問題のとき「IF YY >76 THEN 1900年代 ELSE 2000年代」
で逃げているソースがあちらこちらに。

システム作り直しが早いか、2076年が早いか。

701 ：デフォルトの名無しさん：2008/07/26(土) 21:04:08

うちは昭和83年のプログラムがあるよ。

702 ：デフォルトの名無しさん：2008/07/26(土) 21:12:14

それいつよ

703 ：デフォルトの名無しさん：2008/07/26(土) 22:11:14

>>702 今年じゃねぇの？

704 ：wolf ◆8VH3XAqjlU ：2008/07/27(日) 21:15:57

>>685
ISAMだけかな

http://opencobol.no-ip.org/download.html
open-cobol-1.0.tar.gz

000000031524 typeck.c 04384 CB_FILE (file)->access_mode == COB_ACCESS_SEQUENTIAL) {
000000031525 typeck.c 04385 /* READ NEXT/PREVIOUS */
000000031526 typeck.c 04386 if (next == cb_int2) {
000000031527 typeck.c 04387 if (CB_FILE (file)->organization != COB_ORG_INDEXED) {
000000031528 typeck.c 04388 cb_error_x (CB_TREE (current_statement),
000000031529 typeck.c 04389 _("READ PREVIOUS only allowed for INDEXED SEQUENTIAL files"));

705 ：デフォルトの名無しさん：2008/07/29(火) 10:19:02

3000年問題（笑）。
コボルがあるわけないだろ（笑）。

706 ：デフォルトの名無しさん：2008/07/29(火) 12:43:27

逆読みですか。
そんな事もできるんだ・・・。

707 ：デフォルトの名無しさん：2008/07/29(火) 23:21:45

2000年問題当時、「我が社は、昭和通年方式だから問題なし。がはは。」
って笑ってた会社が結構あったが、それはそれで
「昭和100年問題＝2025年問題」を抱えてるんだよな。
今から17年後だが、はたしてCOBOLは消えてくれるでしょうか…

708 ：デフォルトの名無しさん：2008/07/29(火) 23:28:04

1000年後は人類も終わってそうだ

709 ：デフォルトの名無しさん：2008/07/30(水) 01:57:26

2000年問題の時、OSが対応して無くて(一応汎用機)、
メーカーも対応する予定がなかったため
システムの日付を和暦にして対応した。

710 ：デフォルトの名無しさん：2008/07/30(水) 07:12:43

>>709
その調子で、今後はイスラム暦とか中華民国暦とか、
使えるやつを探して乗り切るんだ。

711 ：デフォルトの名無しさん：2008/07/30(水) 11:26:06

安田生命のシステムは、2000年問題を見越して皇紀で作成されていたらしい。
2040年問題は発生するが、さすがにそこまでは持たないかな。

712 ：デフォルトの名無しさん：2008/07/30(水) 18:26:51

主体暦にもぜひ対応きぼん

713 ：デフォルトの名無しさん：2008/07/31(木) 23:59:08

>712
北朝鮮にでも輸出するのかｗ

714 ：デフォルトの名無しさん：2008/08/01(金) 18:11:46

>>704

PREVIOUSについては書いた後で気づいたよ
しかし他にも無いものが多すぎる

715 ：デフォルトの名無しさん：2008/08/01(金) 18:26:52

関数などに頼らず自分でなんとかするのがこぼらーなのさ☆
個人的にＣＯＢＯＬのイヤなところは、可変長を非常に扱いづらいところ。

716 ：デフォルトの名無しさん：2008/08/02(土) 11:31:52

CICSって今から勉強する価値ある？
まだまだ使われている？？

日本語資料がIBMの正規マニュアルしかない…。
その上、意味が分からない。

717 ：デフォルトの名無しさん：2008/08/02(土) 16:30:04

まだまだ使われてるんじゃないでしょうかねえ。
オンラインですよねえ。
そういう仕事は、現場のやり方に従えば、いいですよ。
特別に勉強しなきゃということもないと思いますけど、
ＴＳＯを使えるようになっときゃ大丈夫なんじゃないでしょうかねえ。
(ＴＳＯの操作も、現場で充分覚えられると思いますよ)

718 ：デフォルトの名無しさん：2008/08/02(土) 16:51:21

そんなことよりADABASをなんとかしてくれ

719 ：デフォルトの名無しさん：2008/08/02(土) 23:46:29

>>715

そんなに可変長って扱いにくいかなぁ
あまり意識したことないけど

720 ：デフォルトの名無しさん：2008/08/03(日) 06:33:04

そりゃ、根本の設計から「可変長」と言う単語が抜けているだけかと。

721 ：デフォルトの名無しさん：2008/08/03(日) 08:52:47

俺が前やっていたとこでは、
File/DB IOサブルーチンで全てのCOMP-3をUNPACKに、可変長を最大Lengthを取る固定長に変換してた。

722 ：デフォルトの名無しさん：2008/08/04(月) 13:33:31

そうだよね。そうしないとできないよね。

723 ：デフォルトの名無しさん：2008/08/05(火) 00:24:53

金融の仕事ってつまんねぇなぁ

724 ：デフォルトの名無しさん：2008/08/05(火) 00:51:03

デリバティブとか面白そうじゃん

725 ：デフォルトの名無しさん：2008/08/05(火) 06:02:53

>>724 もはやCOBOLでは対応不可能な領域なのでは？

726 ：デフォルトの名無しさん：2008/08/05(火) 07:07:37

>>724
贅沢いえるほど仕事の選択肢がない

727 ：デフォルトの名無しさん：2008/08/05(火) 22:48:31

ＣＯＢＯＬでバリバリ新規開発がしたい

728 ：デフォルトの名無しさん：2008/08/06(水) 00:45:34

ねぇよ、そんな需要w

729 ：デフォルトの名無しさん：2008/08/06(水) 13:41:00

リプレースの仕事だったけど、
昔のソース（ＰＬ／Ｉ）がやばすぎて、
ＣＯＢＯＬで作り直す仕事あったよ。

730 ：デフォルトの名無しさん：2008/08/06(水) 14:05:55

>>724 非線型微分方程式ってCOBOLで計算可能ですか？

731 ：デフォルトの名無しさん：2008/08/06(水) 14:16:08

式そのものは、どんな言語でも計算できるんじゃない？
ＣＯＢＯＬは、数値の扱いが、
他の言語で言うところの通貨型のみだから、
誤差が出なくていいかもね。

732 ：デフォルトの名無しさん：2008/08/06(水) 14:34:15

>>731
似たようなことやったことあるけど、有意な桁数を計算しようとすると
計算が終わらない
つか、1日まわして答えが出なかったんで途中でやめた
# 計算途中の結果はあってたんだけどね

733 ：デフォルトの名無しさん：2008/08/06(水) 15:06:54

＞1日まわして答えが出なかったんで途中でやめた
それはウソでしょ。
純粋に計算するだけでしょ？
ファイルアクセスとかしないんでしょ？
だったらそんなに時間はかからないはずだよ。
コンピューターだよ？
８ビットのパソコンでもできるでしょそのくらい。

734 ：デフォルトの名無しさん：2008/08/06(水) 18:48:42

ややこしい計算の部分をフォートランで行って、COBOLの方はそれを受けるのみ
なら以前やった（フォートランの部分は別の人間が担当してた

735 ：デフォルトの名無しさん：2008/08/06(水) 19:12:30

>>733 コンパイラの最適化性能の問題だと思う
問題の計算はFORTRANで書いても数時間かかったが

736 ：デフォルトの名無しさん：2008/08/06(水) 19:45:02

そっかあ、フォートランはわからないです・・・。
難しい技術計算向けの言語ですからねえ。
それでも時間がかかるのですか。

そんな式、扱ったことがないです・・・。

737 ：lovelace：2008/08/06(水) 22:14:43

>691をもう一度質問させてください。
入力データに記載されている受付日は2000年以降のものしかないため、受付日の先頭に20を追加します。
なお、判定日の1ヶ月前年月はサブモジュールで実装しています。
振り分けの条件では、年月のみで比較します。
（例）
　受付日　080629 　　→200806　（'20'）を追加
　判定日　20080806　　→200808
　
また、Copy句ファイル(BSCP10A)には、
　10 'XXX-KEY-KOMOKU'
　 15 'XXX'-RIYOU-YMD PIC X(06).
　 15 'XXX'-RIYOU-ZIKOKU PIC X(06).
　
と定義されています。
以下のように実装してみました。（抜粋）
WORKING-STORAGE SECTION.
01　DATA-IN. COPY BS10A SUPPRESS PREPLACING =='XXX'==BY==BS10A==.
01　DATA-OUT1. COPY BS10A SUPPRESS PREPLACING =='XXX'==BY==BS10A==.
01　DATA-OUT2. COPY BS10A SUPPRESS PREPLACING =='XXX'==BY==BS10A==.
01 WORK-AREA. //ここに受付日を8桁にする方法を記述？
05 WK-DATA-RIYOBI.
PROCEDURE DIVISION.
*--<主処理>--
MOVE BS10A-RIYOU-YMD TO WK-DATA-RIYOBI.
//以下に振り分け条件記述
6桁にした受付日と判定日の1ヶ月前年月を比較

入力データの受付日に20を追加して6桁にする方法を教えてください。どうか皆様のお力を貸してください。
お願いします。

738 ：デフォルトの名無しさん：2008/08/06(水) 22:42:18

>>692,693,695あたりでいんじゃないの？

739 ：デフォルトの名無しさん：2008/08/06(水) 23:00:38

>>737

740 ：デフォルトの名無しさん：2008/08/07(木) 01:49:19

>>735
FORTRANで数時間かかる問題をCOBOLにやらせる意味がわからんし
そんな計算をjavaでやっても1日かかっておわるのか?

計算に関してはFORTRAN以上に早い言語は今のところないんじゃないの
円周率の計算も未だにFORTRANだったとおもう

741 ：デフォルトの名無しさん：2008/08/07(木) 02:53:19

>>733が世間知らずって事で

742 ：デフォルトの名無しさん：2008/08/07(木) 11:46:28

プラットフォームじゃなくて
言語の問題なの？？
お前ら言ってる事おかしくない？？？

743 ：733_736_742だけど：2008/08/07(木) 11:55:28

じゃあ８ビットのパソコンに円周率を計算させたら、
そんなに遅いか？？？
一応言い分は聞いてやろうと思って折れると、
調子に乗る奴らだな。

744 ：lovelace：2008/08/07(木) 22:57:08

＞738
ありがとうございます。
TSOにて開発しているのですが、コンパイル（COBOL�U）すると、

MOVE BS10A-RIYOU-YMD TO WK-DATA-RIYOBI.

の部分で、「BS10A WAS NOT A UNIQUELY DEFINED NAME.」

というメッセージが出てしまいます。
これを解決するにはどうすればよいでしょうか？

745 ：デフォルトの名無しさん：2008/08/07(木) 23:59:16

>>744
COBOL�Uってマジかよ？
今あるのか？

BS10Aが一意でない定義名って意味だよ。
ハイフン抜けてるんじゃない？

746 ：デフォルトの名無しさん：2008/08/08(金) 05:26:47

今でもいつでもありますよ…。
変数定義が重複していないか確認だーね。


>>718
ASABASってなんであんなにFIND遅いの？
READもDB�Uより激遅。

747 ：デフォルトの名無しさん：2008/08/08(金) 14:11:25

>>744

ソースで取り込んでいるＣＯＰＹ句の中に、同じ変数名があるんだと思う。
ＷＯＲＫＩＮＧ−ＳＴＯＲＡＧＥ　ＳＥＣＴＩＯＮの、
ＣＯＰＹ　なんちゃら　の部分のコトです。
基本的にＣＯＰＹ句の変数名は変えられないけど、
どうしてもそっちを変えたければ、
ＣＯＰＹ　ＢＳ１０Ａ　ＲＥＰＬＡＣＩＮＧ　なんちゃら　で変えられるはず。

748 ：デフォルトの名無しさん：2008/08/08(金) 16:12:43

あ、ＲＥＰＬＡＣＩＮＧ指定については、
ちょっと書式が違うかもです・・・。
すみません。
そのへんは、資料やマニュアルなどを、
見て頂けませんでしょうか。すみません。

749 ：デフォルトの名無しさん：2008/08/08(金) 17:53:54

ＣＯＢＯＬって簡易言語ってやつだよね？
これって総務とか経理で使えない奴がやらされる奴だよね？

750 ：デフォルトの名無しさん：2008/08/08(金) 19:05:25

>>749
事実上、COBOLとFORTRANしかなかった時代もあるんだけどね。

751 ：デフォルトの名無しさん：2008/08/08(金) 22:10:13

>>746
あったとしてもサポート切れてるだろ？

752 ：デフォルトの名無しさん：2008/08/08(金) 23:07:54

ＰＬ／Ｉもあるでよ？

753 ：デフォルトの名無しさん：2008/08/08(金) 23:12:34

>>749
マジか、今年就職したんだけど、今COBOLやってる！
いきなり使えないと判断されたんだろうか。

754 ：デフォルトの名無しさん：2008/08/08(金) 23:49:49

>>753
涙が止まりません・・・

まあ、なんというか・・・
所詮、仕事なんか怒られない程度にやっとけ
仕事以外で充実した人生を送れ

755 ：デフォルトの名無しさん：2008/08/09(土) 00:07:34

>>753
何事も経験だと思うけど、ただ単に前任者がおじいちゃんで定年退職した
穴埋めってだけじゃねーの？

当人が有能だったらすぐにそこから這い上がれるだろうし。

756 ：デフォルトの名無しさん：2008/08/09(土) 00:24:28

>>753
あなたがどんな会社に入ったのかは知らないけど、まだまだ銀行や生保の業界ではCOBOLがメイン
うちの会社なんて有望な新人をCOBOLの部に配属してるくらいだぞ

757 ：デフォルトの名無しさん：2008/08/09(土) 00:31:57

>>753
悲惨だな。

IT技術者の唯一の利点が、技術に汎用性があるから転職が容易な事。
でもCOBOLやらされるって事は、技術を身につけることは不可能だし、
業務知識だって、その会社でしか通じないことばかり。

758 ：デフォルトの名無しさん：2008/08/09(土) 00:46:51

>>756
その手の業務にしかつけない人間しか育たない悲惨な会社だな
外部との連携なんてCOBOLだじゃ書けなくないか？

759 ：デフォルトの名無しさん：2008/08/09(土) 00:46:59

それはあんたが無能なだけだろ

760 ：デフォルトの名無しさん：2008/08/09(土) 00:53:19

どうでもいいが全角くんのCOBOLのソースってやっぱり
ＷＯＲＫＩＮＧ−ＳＴＯＲＡＧＥ　ＳＥＣＴＩＯＮとかになってるの？

それでコンパイル通るのかどうか他人事ながら心配になるわ・・・

761 ：デフォルトの名無しさん：2008/08/09(土) 00:57:17

通らないだろたぶん
たしか全角スペースがあってもそこがエラーになったはず

762 ：デフォルトの名無しさん：2008/08/09(土) 01:10:29

全角スペースね。

ソースやコンパイルエラーのリストを
画面で見ても
一見あってる構文に見えるから困る。

ま、HEX表示で壊滅するが。

763 ：デフォルトの名無しさん：2008/08/09(土) 04:26:23

>760
全角くんの職場には、全角専用コンパイラがあるんだよ、きっと。

764 ：デフォルトの名無しさん：2008/08/09(土) 08:41:30

全角なんてわかるからいいじゃん。
全角スペースなんて検索で一発よ。
それよりあのピリオドが嫌い。。。


>>753
COBOLになれちゃったら他の言語を習得できない。
少しは仕事あるし、言語仕様が簡単だし、何といっても運用保守だから仕事が楽

可哀そうだがおしまいコースだな。
汎用機が生産中止になるまでおじいちゃん達と昔話でもたのしんでおけ。

765 ：デフォルトの名無しさん：2008/08/09(土) 08:47:05

>COBOLになれちゃったら他の言語を習得できない。

それはあなた次第ですよ
そういう事を言うならＣでなんでもやるべきだという意見は認めるが

766 ：デフォルトの名無しさん：2008/08/09(土) 08:54:26

ＣＯＢＯＬが嫌いなのはわかったから
イヤならこのスレに来るなよ

767 ：デフォルトの名無しさん：2008/08/09(土) 11:00:41

>>764
C系言語選んであと何年持つかな。あまり差がないんじゃないの。

768 ：デフォルトの名無しさん：2008/08/09(土) 11:54:41

C系ならいくらでも潰しがきくがＣＯＢＯＬじゃ・・・

まあどっちにしてもＣＯＢＯＬしか出来ない様じゃ社内でも社外でもどこ行っても使えない奴ということ
プログラム以外でうまく世渡り汁

769 ：デフォルトの名無しさん：2008/08/09(土) 12:11:47

プログラム以外で世渡りできるなら他の業界いくわ

770 ：デフォルトの名無しさん：2008/08/09(土) 12:14:47

だから他の業界へ行けという事では？　　　　　　ｗｗｗ

771 ：デフォルトの名無しさん：2008/08/09(土) 15:18:56

なるほど！

772 ：デフォルトの名無しさん：2008/08/09(土) 18:57:13

だからここはＣＯＢＯＬの話をするスレなんだよ。
ＣＯＢＯＬやってる人間が他の言語できないかっていったら
そうでもないと思うがな。
１から書けと言われりゃそりゃ時間かかってしまうが
現場にソースはいくらでも落ちてるだろ。

言語は使い分けるものだろう。
Ｗｅｂとか画面制御にＣＯＢＯＬ使えって言われたら
コボラーの俺でもアホかと思うしな。

773 ：デフォルトの名無しさん：2008/08/09(土) 23:06:08

だからそのコボラーの馬鹿さ加減を話しているのでは？

VB程度の研修すらついていけず脱走したコボラーを知っている。
コボラーとしては優秀なんだがなー。

774 ：デフォルトの名無しさん：2008/08/09(土) 23:39:46

ＣＯＢＯＬ自体は優秀な簡易言語だと思うよ
大昔と比べてマシンスペックも段違いに上がっているんだから
逆にこれからはＣＯＢＯＬに回帰してもいいんじゃないかとも思う

ただ、コボラーって・・・ｗ
コボラーにスキル必要ないでしょ？
つか、スキルは逆に邪魔ｗｗｗ
だからＣＯＢＯＬは簡易言語

775 ：デフォルトの名無しさん：2008/08/10(日) 09:38:08

ところで、
COBOLでhtmlファイルを生成する案件は結構あるものかな?

776 ：デフォルトの名無しさん：2008/08/10(日) 13:50:23

おまえは一体なにを言っているんだ

777 ：デフォルトの名無しさん：2008/08/10(日) 13:58:23

VALUE '<HTML>'　みたいな？

778 ：デフォルトの名無しさん：2008/08/10(日) 15:37:53

[COBOLでhtmlファイルを生成する]事って出来たっけ？

779 ：デフォルトの名無しさん：2008/08/10(日) 16:01:38

>>772
確かに道具は選ぶもんだしな

>>774
コボル以外の言語をやって身につくスキルって何なんだ？

780 ：デフォルトの名無しさん：2008/08/10(日) 18:11:41

自演ｳｻﾞｲww

781 ：デフォルトの名無しさん：2008/08/10(日) 19:06:34

>>776
上の方(>>772)で
>Ｗｅｂとか画面制御にＣＯＢＯL使えって言われたら
というのがあったので訊いてみた。
ないということはないだろ。

782 ：デフォルトの名無しさん：2008/08/10(日) 19:27:22

昔のオフコンみたいに
ＳＣＲＥＥＮ　ＳＥＣＴＩＯＮというのがあるのではないかな。
やったことないけど。

783 ：デフォルトの名無しさん：2008/08/10(日) 19:45:23

>>781

こういうものがあるらしい
案件としては、どうなんでしょうねえ。

ttp://itpro.nikkeibp.co.jp/free/SI/NEWS/20030514/1/
ttp://www.geocities.jp/sokudo999/webif.html

784 ：デフォルトの名無しさん：2008/08/10(日) 20:25:27

１００％ピュアCobolなWebは知らんけど
フロントにJSP／Servletを採用したCoboのWeblフレームワークなら
大手がそれなりに力を入れていると思う。

富士通Interstageは何回か触ったことがある。
NRIもなんか作ってた気がする。

785 ：デフォルトの名無しさん：2008/08/10(日) 21:10:07

>>783
これは良いんじゃないの？

一気にCOBOLを無くすのは大変だろうから、まずはクライアントから置き換える。
インタフェースの互換性を保ちながら、サーバ側も一つずつ置き換えていける。

786 ：デフォルトの名無しさん：2008/08/10(日) 23:54:07

>>783
悪くないとは思うが掲載が
2003/05/14
の件

787 ：デフォルトの名無しさん：2008/08/11(月) 10:36:15

俺はＰＬ／Ｉで新規開発がしたいんだよ！！！

788 ：デフォルトの名無しさん：2008/08/11(月) 13:13:50

参考書は古本屋で売ってる、20年前のでもＯＫですか？

789 ：デフォルトの名無しさん：2008/08/11(月) 16:22:40

だいじょうぶじゃない？

790 ：デフォルトの名無しさん：2008/08/11(月) 16:34:05

>>789
ANSI'74 レベルのCOBOLでも大丈夫?

791 ：デフォルトの名無しさん：2008/08/12(火) 20:42:02

コボルとかダメだろ

792 ：デフォルトの名無しさん：2008/08/12(火) 23:03:43

日本中の半分のプログラムはコボルで出来ています
http://pc11.2ch.net/test/read.cgi/prog/1215794933/l50

昔のコボラーはアセンブラとかも経験してる人も多いからね

793 ：デフォルトの名無しさん：2008/08/13(水) 21:14:04

>>782
まず互換性がない。
向き不向きてもんさ。

794 ：デフォルトの名無しさん：2008/08/17(日) 22:50:48

http://www.nicovideo.jp/watch/sm4232502

OpenCOBOLとPHPてアレな組み合わせだな

795 ：デフォルトの名無しさん：2008/08/22(金) 20:49:24

運用の都合上COBOL・VB・Javaと使いこなせないとまずいが、
結局言語云々てのは重要じゃないんだよね

796 ：デフォルトの名無しさん：2008/08/23(土) 09:43:11

そそ

797 ：デフォルトの名無しさん：2008/08/23(土) 17:51:04

言語の問題じゃなくて歳の問題。
プログラマー３５歳定年は義務付けるべき。
頭の固いプログラマーなんていらねー。

798 ：デフォルトの名無しさん：2008/08/23(土) 20:05:51

ちなみにコボラーとプログラマーは分けて考えてね
もし３５歳までCOBOLやってる様な人間がいたとしたら
そいつに今更何をやれっちゅーの？ただの無能なオヤジだよ？酷いよ・・・

799 ：デフォルトの名無しさん：2008/08/23(土) 20:52:29

この前コボラーと話しててコボルは１バイトに数値が０〜９まで
しかもてないと言っていました。本当でしょうか。なんかパックとか
アンパックとか言ってましたけどよくわかりません

800 ：デフォルトの名無しさん：2008/08/24(日) 00:09:38

>>799
整数型の変数が必要だとする。想定される最大値によって、
int だとか long だとかを選ぶ、というのがまぁ大方の考えだろう。
COBOLは違う。例えば、想定される最大値が10進数10桁だとすると、
「最大9999999999まで格納できる整数」
という定義をする。それは記憶領域に10バイト要する。
一桁 ＝ 1バイトである。

2の補数表現とかで、int風の変数の持ち方もできるが余り使われない。

801 ：デフォルトの名無しさん：2008/08/24(日) 02:08:53

小数ならともかく、整数を二進化十進で計算して何が嬉しいんだろう？
今よりもメモリもCPUパワーも貴重だったのに。

802 ：デフォルトの名無しさん：2008/08/24(日) 08:33:10

>>801
つ[ダンプリスト]

803 ：デフォルトの名無しさん：2008/08/24(日) 08:37:48

>>801
簡易言語だから当然です

804 ：デフォルトの名無しさん：2008/08/24(日) 08:55:12

COBOLerを再教育する施設が必要だと思うんだが。
COBOLの技法を他の言語に持ち込まれると大変なことに。
これ以上COBOLerによる被害を増やさないためにも、
COBOLer再教育プログラムを！

805 ：デフォルトの名無しさん：2008/08/24(日) 10:43:19

教育出来なかったからコボラーやらされていると思うんだが・・・

806 ：デフォルトの名無しさん：2008/08/24(日) 21:41:44

>>801
うちはそれでISAMの桁数が足りなくなったとか大騒ぎしたり、
上位桁が落ちてしまって計算が狂ったり、目からうろこが
落ちるようなバグばかりだしやがる・・・。もうやだ。。。

807 ：デフォルトの名無しさん：2008/08/24(日) 21:51:49

なんか涙が止まりません・・・

808 ：デフォルトの名無しさん：2008/08/24(日) 22:03:11

＞ISAMの桁数

ＩＳＡＭって、ファイルの索引編成のことだろ？？
お前意味わかって言ってる？？

809 ：デフォルトの名無しさん：2008/08/24(日) 23:13:56

でも言いたいことは解るぞｗ

810 ：デフォルトの名無しさん：2008/08/24(日) 23:20:19

大ＣＯＢＯＬ帝国憲法

第３条
ＣＯＢＯＬハ神聖ニシテ侵スヘカラス

811 ：デフォルトの名無しさん：2008/08/24(日) 23:40:54

目から鱗というか、まあそういうモンと思うしかない言語だからなぁ・・・

812 ：デフォルトの名無しさん：2008/08/25(月) 16:09:46

そんな事で困るの？？
なんというかまあ・・・。君たちは・・・。

813 ：デフォルトの名無しさん：2008/08/25(月) 17:28:19

涙で明日が見えない

814 ：デフォルトの名無しさん：2008/08/25(月) 21:08:51

>>812はコボラーより馬鹿とみたｗ
もしくは生粋のコボラー

815 ：側近中の側近 ◆0351148456 ：2008/08/25(月) 21:21:26

>>808
(っ´▽｀)っ
ISAMって吉川ひなのと結婚した人でしょ。

816 ：デフォルトの名無しさん：2008/08/25(月) 21:27:51

>>808
(っ´▽｀)っ
ISAMって吉岡美穂と結婚した人でしょ。

817 ：デフォルトの名無しさん：2008/08/25(月) 21:27:59

どっかで見たうざい顔文字だと思ったらVBAだったか

818 ：デフォルトの名無しさん：2008/08/25(月) 22:06:08

>>812
請求書の計算を間違えても困らないコボラーなんていたら見てみたいわ

819 ：デフォルトの名無しさん：2008/08/25(月) 23:44:20

　まちがったって
　　　いいじゃない　　

　　コボルだもの

820 ：デフォルトの名無しさん：2008/08/26(火) 00:03:26

>>819
>　　　いいじゃない　

みつをｗｗｗｗ　やめｗｗｗｗｗ
業務がｗｗｗｗｗｗｗ

821 ：デフォルトの名無しさん：2008/08/26(火) 00:55:50

正解は0〜255まで。
符号つきなら-127〜+12

822 ：デフォルトの名無しさん：2008/08/26(火) 00:57:10

途中送信しちまった。
-127〜+128

823 ：デフォルトの名無しさん：2008/08/26(火) 03:22:27

世の中には word=36bit, 1byte=9bit のマシンもあるわけだが………

824 ：デフォルトの名無しさん：2008/08/26(火) 20:35:32

↑あんまり人の事をバカだアホだと言いたくはないが・・・。
アホか。

コンピュータにとってキリのいい数字は、
１，２，４，８，１６、３２・・・。
だろ？？？基礎中の基礎じゃね？？？

825 ：側近中の側近 ◆0351148456 ：2008/08/26(火) 20:45:51

>>824
(っ´▽｀)っ
パリティビットはどうする？

826 ：デフォルトの名無しさん：2008/08/26(火) 20:47:33

計算機科学の常識に従うようじゃCOBOLとは言えない。

827 ：デフォルトの名無しさん：2008/08/26(火) 21:06:56

>>825
>>826

・・・・・。

話にならない・・・。
パリティビット？？検出符号だろ？？
そんなの、ソフト的な問題だろ・・・。
８ビットのうち、どれをパリティビットにするのかは、
プログラムを設計、作る側が決めることだろうに。

828 ：デフォルトの名無しさん：2008/08/26(火) 21:43:40

>>824 アホはおまえだ! DEC-10とかACOS-6とか調べてみれ

829 ：デフォルトの名無しさん：2008/08/26(火) 21:43:58

>>823
UNISYSですね。

830 ：デフォルトの名無しさん：2008/08/26(火) 21:53:33

>>824と>>827の今の顔

http://image.space.rakuten.co.jp/lg01/89/0000313089/77/imge82d3a21zik7zj.jpeg

831 ：デフォルトの名無しさん：2008/08/26(火) 22:00:56

うそこけ
何がＵＮＩＳＹＳは１バイトが９ビットだよ

そんなハードあるかよ
テキトーな事言うなよ・・・。

832 ：デフォルトの名無しさん：2008/08/26(火) 22:04:38

コンピュータにとってキリのいい数字は、
１，２，４，８，１６、３２・・・。
だろ？？？基礎中の基礎じゃね？？？

よし、なら聞こう。
１１１１　１１１１　はＦＦｈだよな。
なら、
１１１１　１１１１１？？（あるわけねえけど）
はいくつだよ？？？

833 ：デフォルトの名無しさん：2008/08/26(火) 22:10:06

ど田舎富山DQN男の家族消えろ　ど田舎富山DQN男の親消えろ　ど田舎富山DQN男の子供消えろ　ど田舎富山DQN男の親戚消えろ
ど田舎富山DQN男の家族消えろ　ど田舎富山DQN男の親消えろ　ど田舎富山DQN男の子供消えろ　ど田舎富山DQN男の親戚消えろ
ど田舎富山DQN男の家族消えろ　ど田舎富山DQN男の親消えろ　ど田舎富山DQN男の子供消えろ　ど田舎富山DQN男の親戚消えろ
ど田舎富山DQN男の家族消えろ　ど田舎富山DQN男の親消えろ　ど田舎富山DQN男の子供消えろ　ど田舎富山DQN男の親戚消えろ
ニヤニヤ(・∀・)　ニヤニヤ(・∀・)　ニヤニヤ(・∀・)　ニヤニヤ(・∀・)
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね死ね
苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね
苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね
苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね
苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね 苦しんで死ね
死ぬとき　このレスの事思い出してから地獄へ行けよ
ニヤ(・∀・)ニヤ(・∀・)

834 ：デフォルトの名無しさん：2008/08/26(火) 22:11:03

>>831

http://ja.wikipedia.org/wiki/UNIVAC

UNIVAC 1100/2200シリーズ: 36ビットのトランジスタ化されたコンピュータのシリーズ。今日もユニシスで ClearPath IXとしてサポートされている。

835 ：デフォルトの名無しさん：2008/08/26(火) 22:25:46

>>832
オクタルなんだよw

836 ：デフォルトの名無しさん：2008/08/26(火) 22:31:23

1107は初の36ビット、ワード指向マシンで、

なるほど、確かにこう記述されているな・・・。
３６ビットを９ビットｘ４で扱うメリットって何だ？？？
わけわからん・・・。

そういう機種があるのはわかった。

837 ：デフォルトの名無しさん：2008/08/26(火) 22:32:28

>>835

８進数？？
それにしたって、９ビットじゃ半端だろうに。

838 ：デフォルトの名無しさん：2008/08/26(火) 22:33:32

>>832 ワードマシンってオクタル使ってヘキサ表現使わないみたいだが...

839 ：837：2008/08/26(火) 22:35:03

>>835

ああ、そうか。
半端じゃない。失礼しました。
納得した。なるほどね。

変な機種だな・・・。

840 ：デフォルトの名無しさん：2008/08/26(火) 22:37:52

>>836
昔は 36bit を 6分割して 6キャラ詰め込んでたらしい
当然, ASCIIコードは入りきらない. そのため, 昔の言語は全部大文字表記
FORTRAN も COBOL も LISP も...

同じワード長の中に, 8bit キャラを詰め込むための苦肉の策

841 ：デフォルトの名無しさん：2008/08/26(火) 22:43:56

> パリティビット
ダビスタを思い出した

842 ：デフォルトの名無しさん：2008/08/26(火) 22:53:20

なるほど・・・。
そうすると、８ビットで１文字を表現するよりも、
少ないメモリにより多くのキャラを詰められますねえ。

メモリが少なくて貴重だった昔の、苦肉の策なのですね。

843 ：デフォルトの名無しさん：2008/08/26(火) 22:55:14

>>840
なるどほ。なんとなくコボルの数値が１バイト１桁な理由が納得できた

844 ：デフォルトの名無しさん：2008/08/26(火) 22:56:23

そういうマシンで、ＣＯＢＯＬを動かしていたとして、
ＣＯＭＰ−３はどうなるんだろう？？

845 ：デフォルトの名無しさん：2008/08/26(火) 23:06:23

ああそうか、そんなの無いのか・・・。

わかったけど・・・。
「今の時代は」１バイトは８ビットではないのか？？？

846 ：デフォルトの名無しさん：2008/08/26(火) 23:23:19

>>844
ワード内で任意の bit 位置から N bit 取り出すとか,
ワード内で任意の bit 位置から N bit 分の長さの値を書き込む命令とかがある

847 ：デフォルトの名無しさん：2008/08/26(火) 23:25:20

>>845
> 「今の時代は」１バイトは８ビットではないのか？？？
ではないから, 通信を扱うときはバイトと呼ばずにオクテットと呼んでる

848 ：デフォルトの名無しさん：2008/08/26(火) 23:45:52

一見、このスレらしからぬ専門的な話だが
いかんせん突っ込みを入れてからんできた奴のレベル低すぎ
さすがコボラースレだｗ
仕事でもこんなんだろうな。調べもせずに自分の浅い知識がすべてだと思っている

849 ：デフォルトの名無しさん：2008/08/26(火) 23:54:52

くやしいです！！

http://image.space.rakuten.co.jp/lg01/89/0000313089/77/imge82d3a21zik7zj.jpeg

850 ：デフォルトの名無しさん：2008/08/27(水) 00:07:44

職場にグーグル先生がいてくれればもう少しましにはなるんだけどね

851 ：デフォルトの名無しさん：2008/08/27(水) 09:36:20

36ビット(ACOS-6)使ったことあるけど、COBOLでは何の恩恵もなかった。
ちなみにINTEGERが36ビットになるFORTRANは恩恵があった。

852 ：デフォルトの名無しさん：2008/08/27(水) 09:57:01

ＣＯＢＯＬが古くてジジイだから気に入らないくせに、
嬉々として６０年代のワードマシンやＦＯＲＴＲＡＮの話するのはなんでなの？？
屁理屈だろそんなもん。１バイトは８ビット。常識だろ。常識。

853 ：デフォルトの名無しさん：2008/08/27(水) 10:30:34

>>848

おい、お前。
１１１１１１１１１はいくつだ。
答えてみろ。

854 ：デフォルトの名無しさん：2008/08/27(水) 10:34:48

そうだよな。レベルの低い質問だ。
別に俺も難しくないと思う。ならお前、答えて見せてみろ。

855 ：デフォルトの名無しさん：2008/08/27(水) 10:57:40

>>852
> 嬉々として６０年代のワードマシン
ACOS-6とかUNISYSのマシンが現存してるから話題にしてるんじゃないのか？
> １バイトは８ビット。常識だろ。常識。
おまえはおまえで、かってに常識だと思ってればええんちゃう？

856 ：デフォルトの名無しさん：2008/08/27(水) 12:38:58

>>853
だからアホはもう黙ってろって・・・

こっちまで恥ずかしいんで、せめてsageろ

857 ：デフォルトの名無しさん：2008/08/27(水) 13:51:44

そうかよ。お前らが使ってるパソコンは
１バイトが８ビットじゃないのかよ。
じゃあ、ＡＳＣＩＩとか普通の文字コード使えるＰＣ使うな。
一生昔のワードマシン使ってろよ。

>>856
sageたぞ、
そうだよな。アホでも答えられるよな。
お前答えてみろ。

858 ：デフォルトの名無しさん：2008/08/27(水) 13:57:40

昔のマシンの話は、話としては面白かった。
ありがとう。

いいからさっさと答えろよ
>>856

ヒントやるよ。
話の流れ見ればわかるだろ？？

859 ：デフォルトの名無しさん：2008/08/27(水) 15:04:20

＞昔のマシンの話は、話としては面白かった。
＞ありがとう。

プププッ

860 ：デフォルトの名無しさん：2008/08/27(水) 15:16:44

プププッ
こぼらーにぱりてぃびっとは不要さ