COBOLについて勉強したい！

1 ：ぐぅ：2005/07/10(日) 00:13:30

COBOLをはじめて約一年のプログラマです。
仕事ではコピペで出来てしまう仕事が中心で、全然自分の力になっていないのを感じます。
そこで、自分で勉強をしようと思っているのですが、COBOLの書籍は古いものがほとんどで何を勉強するのが良いのかわから無いので教えてください。

2 ：nobody ◆other5OudI ：2005/07/10(日) 00:27:31

　_, ,_
(;´д｀) 2ゲット >1 はげどう

3 ：仕様書無しさん：2005/07/10(日) 01:36:59

他の言語への逃げ方について。

4 ：仕様書無しさん：2005/07/10(日) 11:18:59

COBOL～～～？
ﾓﾚはさぁ、工房で商業学校通っててCOBOLやっているけど。。。

あ　ん　な　も　ん　の　ど　こ　が　い　い　の　さ？

【COBOLのｸｿな点】
・定義の面倒くささ。IdentificationからProcedure（つづりは間違ってるかもね）まで計４つのディビジョンを作成せなならん。
しかも、いちいちPic句で指定するの面倒くせぇし～～～。
・画像等が表示できねぇ（まぁ事務処理用言語だからねぇ）。
・その割には教科書系統には意味不な問題を作ろうとする（簡単だけどな）。【例】オセロゲームのCOBOLver
・移植しづらいプログラム

まぁ大人のあんたにﾓﾚが教えられることは、とにかく様々なプログラムを作るってことだね～～。
基本情報にはＣＯＢＯＬの問題があるからやってみれば？結構チカラになると思うよ。

ってかＣＯＢＯＬの仕事ってナニヨ？金融関係？

5 ：仕様書無しさん：2005/07/10(日) 11:32:18

>>4

＞＞あ　ん　な　も　ん　の　ど　こ　が　い　い　の　さ？

とりあいず、計算とかじゃないかな

とりあいず頭が腐らない様にＣとかやっとけば？

6 ：仕様書無しさん：2005/07/10(日) 13:20:29

Cを10年やってて頭が腐ってる人を知っています。
お口も腐い。

7 ：仕様書無しさん：2005/07/11(月) 11:05:17

C,Java,VB,VCでもこぴぺだけでやらされている奴多し

8 ：仕様書無しさん：2005/07/11(月) 11:17:55

COBOLだけはその言語仕様ゆえにコピペが避けられない場合があるねぇ

9 ：仕様書無しさん：2005/07/11(月) 11:26:38

(`・ω・´)ｼｬｷｰﾝ

10 ：仕様書無しさん：2005/07/11(月) 13:43:00

なぁ、とりあえず>>1よ、学習目的で使うんじゃないなら悪い事は言わん多言語へ移れ。

11 ：仕様書無しさん：2005/07/11(月) 15:32:13

そんなことより>>1さん、どんな言語でもこなせる勉強を！
他の言語を習得してもダメになることもある。

12 ：仕様書無しさん：2005/07/12(火) 00:33:41

現役COBOLerにして年収200万円の俺が、このスレにやってきました。
聞きたいことがあったら、何でも質問してくれ。

13 ：仕様書無しさん：2005/07/12(火) 00:36:08

>>12
その年収で生活できる、あなたのサバイバル生活術を教えて下さい。

14 ：仕様書無しさん：2005/07/12(火) 15:33:33

>>1
４０代のおっちゃんだが、おっちゃんは２０代から３０代前半までＣＯＢＯＬだけの（実はASM,BASIC,PLI,FORTRANも勉強はした）
実務生活をしてきたが、Ｃは全く勉強していなかったが、組み込み関連などハード寄りの開発をさせてもらい知らなかったＣも
問題なく世に送りだせたぞ。要するに言語に左右されないものを最初のＣＯＢＯＬで身につけたのだ。それだけ、あとはがんばって！
>>1君へ
文章適当でｽﾏﾇ

15 ：14：2005/07/12(火) 15:34:21

こりゃまた酷い文面になっちまったｗあれれ

16 ：仕様書無しさん：2005/07/12(火) 21:52:14

ぼくは、Object COBOLばりばりでつ。

17 ：仕様書無しさん：2005/07/16(土) 01:19:14

COBOLはコピペでできてこそCOBOL。
構造化された元ネタがあればそこから工数少なくプログラムできる。
学生時代COBOLで、まっさらなエディタから、
IDENTIFICATION DIVISION.から手で書いてたけど、
実務じゃそんなヒマないよ。似たプログラム探す方がラク。
あとあんまし使わない予約語使ってコーディングすると、
あとでメンテする人が苦労するから、やめれ。

18 ：仕様書無しさん：2005/07/16(土) 02:06:07

…じゃかわいそうな気がしてきたので…
とりあえずバッチかオンラインかでちょっと違いが出てくるので、
守秘義務に反しない程度にどんなんかわからんと…。

本当に(先があるかは漏れも含めてしらんが)COBOL勉強するなら、
COBOL85準拠の参考書ならいいんじゃないかな？古くても。
開発環境がある程度自由に使えるなら、
そこらのテストデータを整形して帳票に出す、レベルを
フローチャート書いてから考えなさい…と漏れは就職して言われた。
＃そん時紙のコーディングシートまで使わされたよ…

オンラインは…環境によってちがうんだよねー。
オンラインに限ってはごくまれにGO TO使わざるを得ない場合もあるし。

個人的な感想は、「桁数決まってる事務処理には便利」ってとこかな。
PICTURE句も、使いようによっては便利だし。

もし今後、COBOL続けるなら、言語仕様にこだわるよりも(んなこと本に乗ってる)
「今扱っている業務」に興味を持たせた方がいいのかも。

…てゆか。「～がわからないのですが、xxという理解でいいのですか？」
という姿勢の方がいいのかも（老婆心ゴメン
あと現場のコーディングルールな。守れよ。あとがめんどいの…

19 ：ペコ：2005/07/16(土) 03:19:13

ＣＯＢＯＬってまだ使われていたんだ～。もうなくなったのかと思った。
もうかれこれ○○年前にプログラマーしていた時に使っていたけど、
今じゃ～、使っていないって友人が言ってました。

20 ：仕様書無しさん：2005/07/16(土) 03:45:58

>>19
今日組んできましたが何か？ｗ

なんだかんだ言って、昔に大規模システム作っちゃって、
あまりの規模に他言語への移植が大変だったり、
止められないシステムだと生き残ってるところ多い気がする。
さすがに完全新規でシステム入れるとなったら他言語だろうけど。

…おいら本当はVB,Oracleが専門だったんだよー
気付いたら端末エミュレータでCOBOL書いてる…

21 ：業務システム上流工程経験10年以上：2005/07/16(土) 10:46:49

COBOL は、なんだかんだと言われつつも40年以上にも亘って
使われ続けている。ソフトウェア資産としての物量で言えば
ナンバーワンだ。仕事がなくなることは無いだろう。

22 ：仕様書無しさん：2005/07/16(土) 12:59:21

何この時代の流れについて行けない人達

23 ：仕様書無しさん：2005/07/16(土) 15:34:27

>>22
自分が知らないからって、そんな風に言うなや。
厨房丸出しだぞ。
そもそもプログラミング言語に好き嫌い言っている
時点でアウトだろ。
別にCOBOL一番だとか、そんなことを言っている
わけじゃねー。単に事実を言っているだけだろ。

24 ：仕様書無しさん：2005/07/16(土) 16:20:09

COBOLは知っておいて損はないよ。マジで。
COBOL and C言語
この２つは、基本として知っていないと、話が通じない
場合が多い。けっこう、片方しか知らないやつが多いが
それではいけない。
それから、プログラミング言語で好き嫌い言っていては
成長できないというのも確か。
大切なのは言語なんかではなく、考え方。

25 ：仕様書無しさん：2005/07/16(土) 16:39:02

ま、「新しい思考法を学ぶことのできない言語は覚える価値がない」って言葉もあるし。
JavaやC#との異質さ故に、実務では使わなくとも教養として知っておく価値はある。＞ＣＯＢＯＬ

仕事ではJavaとC++, Perl、趣味ではRuby, Scheme使ってるけど。今、教養と思って
COBOLとHaskell勉強してるよ。そのうちFortranもやってみたいね。

26 ：仕様書無しさん：2005/07/17(日) 11:14:43

>>25
たいへんよいこころがけだと思いますよ。まぢで。
ちなみにCOBOLはかなりの確率で使用することになる。
直接コーディングするかどうかは別として、設計ドキュメント
のデータ項目定義の表現なんかには、平気で「Xで５桁」
などという表現が出てくる。それくらい普及しているのは事実。

27 ：仕様書無しさん：2005/07/17(日) 11:38:22

リファクタリングは受け付けない身体になってコピペばかりするようになるけどな。

28 ：仕様書無しさん：2005/07/17(日) 14:00:46

COBOL > C > PowerBuilder と覚えていった俺は負け組みですか？

29 ：仕様書無しさん：2005/07/17(日) 14:02:27

>>28
そんなことはないでしょう。
VBから入る人に比べれば１００万倍まし。

30 ：仕様書無しさん：2005/07/17(日) 15:51:31

COBOLの良いところは、他の言語に比べて、個人個人によって品質がバラツカないところ。
不勉強な人間ばかりでもモノが出来上がる。

31 ：仕様書無しさん：2005/07/17(日) 20:27:42

まあ要するにそれなりの物は作れるがそれなりの物しか作れないということ。

32 ：仕様書無しさん：2005/07/17(日) 22:32:23

>>31
ちょっと違うね。
素質のある人材でも、COBOLの仕事を続けると勉強をやめてしまうから、個人個人の能力が均衡してくるだけ。

33 ：仕様書無しさん：2005/07/17(日) 23:10:16

勉強を・・・
上司、企業の問題

34 ：仕様書無しさん：2005/07/18(月) 20:52:07

システムのメンテナンスを考えると>>30の点は
めちゃくちゃ重要。
こちとら仕事なんだし、趣味じゃないんだし。
どんなに美しかろうが人の個性が出てしまうようなもんは
悪でしかない。
COBOL がこれほどまでに普及し長く現役でいられるのは
設計からの定石が築かれてきたから。

35 ：仕様書無しさん：2005/07/18(月) 21:03:39

>>34
いや、言語自体の設計思想が安全性、事務処理への特化に集約
（金額計算させるプログラムを作らせるのに何でもできてしまう
言語でコーディングさせるのは逆に不自由だったんだろう）して
いるおかげだと思う（だから、定石もそんなにパターンないだろ
うし）。
まあ、難点も多いけど、悪いところばかりじゃないよな。
COBOLしかやらないのは良くないと思うけど、COBOLも勉強する
というスタンスは良いと思う。

36 ：仕様書無しさん：2005/07/18(月) 21:07:50

ボコルなんてやっていたら、頭が腐る
蛆虫がわく

ま、頭が腐ってもこれでおまんまが食えるなら、これでもいいっか！
ちんぽが腐るわけじゃないし

技術よりもおまんこ！がいい！！

37 ：仕様書無しさん：2005/07/18(月) 21:10:06

ま、聞いた話だが
COBOLは携帯電話会社関連の仕事があるらしい。

これなら当分はCOBOLも大丈夫か？

38 ：仕様書無しさん：2005/07/18(月) 22:07:07

>>36 いいこというじゃねぇか

39 ：仕様書無しさん：2005/07/19(火) 21:28:00

>>1
COBOL85 仕様が最も普及している。
今後も考えるとCOBOL97 もしくはOO-COBOL をみておくとイイ。
HITACHI FUJITSU MicroForcuse

40 ：仕様書無しさん：2005/07/23(土) 12:54:01

４０年以上にわたって使用され続けている言語なので
それを前向きに勉強したいという姿勢はとってもよい。
いい意味で枯れた部分も多いので、古い書籍でも読む価値は
ある。特にVBやJavaから入った人にはいろいろ発見もあるはず。

>>35
激しく同意です。

41 ：仕様書無しさん：2005/07/23(土) 14:44:30

A領域とかB領域とか書かれたコーディングシートを使うのだ。

42 ：仕様書無しさん：2005/07/25(月) 18:16:12

>>24
良い事言うね、あなた

43 ：仕様書無しさん：2005/07/25(月) 19:16:19

知り合いにCOBOLで食ってる人がいるんだけど・・・・・・・

COBOLはまずいのか？

44 ：仕様書無しさん：2005/07/25(月) 19:24:04

まずはこれ

COBOL利用技術
http://www.cobol.gr.jp/knowledge/technical.html

45 ：仕様書無しさん：2005/07/25(月) 19:29:36

日本や世界の大手企業で、COBOLが動いてない企業はほとんど無い。
ただ、知られてないだけ。

COBOLの良さは、業務（事務計算）をきちんと記述するのに向いてる事。
だから「低脳言語」と馬鹿にされながら、Cのように機械(CPU)の種類で型や精度が変わる事も無い。
多くの仕事で必要なのは芸術家ではなく、確実で反復・保守可能な言語だから。

46 ：仕様書無しさん：2005/07/25(月) 19:35:43

勘定系は何で書かれているか？

・東京三菱銀行、りそな、日銀：主にPL/I
・三井住友、みずほ銀、みずほコーポ、UFJ：主にCOBOL

47 ：仕様書無しさん：2005/07/25(月) 19:41:40

COBOL事例

富士通
http://www.netcobol-forum.com/user_cobol.html

MicroFocus
http://www.microfocus.co.jp/userref/index_jpn_03.asp

Microsoft
http://www.microsoft.com/japan/showcase/meitetsucom.mspx

UNISYS
http://www.unisys.co.jp/club/code/15002-8/

ソニー生命
http://www-6.ibm.com/jp/solutions/casestudies/20041129sonyseimei.html

48 ：仕様書無しさん：2005/07/25(月) 20:58:08

>>24
ＣＯＢＯＬは知らなくても問題ない。

49 ：仕様書無しさん：2005/07/30(土) 13:57:24

>>48
別にいやなら無理強いはしないけど、COBOL知っておいて損なし
は確かだと思いますよ。うえの方で何度も語られているように、
業務システム（特に基幹系）では、圧倒的な使用量だし、ドキュメント
もCOBOLが前提となっているものが多い。
大丈夫だよ。C言語系が理解できるならCOBOLなんて簡単だから。
少なくとも言語仕様としては。＞それが強みなんだけどねぇ。
価値観が違うんだろうな。＞COBOLを忌避する人
>>45
そうですね。

50 ：仕様書無しさん：2005/07/30(土) 15:07:09

>>49
>価値観が違うんだろうな。＞COBOLを忌避する人

つうより、単に自分の知ってる世界以外を蔑視してる単純君がいるだけ

51 ：仕様書無しさん：2005/07/30(土) 16:07:36

ＣＯＢＯＬの質問なんですけど、
外部プログラム(ＣＯＢＯＬでなくてもいい。例えばミドルウェア)からＣＯＢＯＬの変数使いたい
もしくは、
ＣＯＢＯＬから外部プログラムの変数を呼び出したい場合、
ＣＡＬＬインターフェースを使うために、
PROCEDURE　DIVISIONでUSING句で渡したり、参照したりする変数を定義して、
ここからなんですけど、
あらかじめ、LINKAGE　SECTIONでCALL文で使う変数の領域を確保する時に
０１　CALLHENSUU1　PIC　～
０１　CALLHENSUU2　PIC　～
と確保して、このとき０１じゃなければならないと読んだことがありますが、
正しいですか、読み違いですか、メーカごとのCOBOLの仕様で変わるのですか？
もし、正しいとしたら、何か理由があるのでしょうか？

52 ：５１：2005/07/30(土) 16:41:17

書いた内容がおかしいので再び..
・外部プログラム(ＣＯＢＯＬでなくてもいい。例えばミドルウェア)からＣＯＢＯＬの変数使いたい場合
PROCEDURE　DIVISIONでUSING句で渡したり、参照したりする変数を定義して、
あらかじめ、LINKAGE　SECTIONで使う変数の領域を確保する時に
０１　CALLHENSUU1　PIC　～
０１　CALLHENSUU2　PIC　～
・ＣＯＢＯＬから外部プログラムの変数を呼び出したい場合、
LINKAGE　SECTIONでCALL文USING句で使う変数の領域を確保する時に
０１　CALLHENSUU1　PIC　～
０１　CALLHENSUU2　PIC　～

で、いずれの場合でも、LINKAGE　SECTIONでは０１に変数の領域を確保しないといけないというのは
正しいのか？、間違っているのか？、はたまたメーカごとのCOBOLの仕様で変わるのか？
という質問と
もし正しかった場合、この０１である理由はなんなのか
という質問です

53 ：仕様書無しさん：2005/07/30(土) 19:05:14

>>51-52
そもそもなぜそんなことを知りたがっているのかわからん。
結構答えにくい質問かもよ？　それは。

わかる範囲で言います。
・まず、貴方が例に挙げているのは「変数」というよりも「引数」（アーギュメント）だと
　思います。
・製品によって違うかどうかはわからないが、変数領域の定義で、いきなり０３レベル
　などから記述することはないし、必要もないと思いますが・・・
　というか、おそらく言語仕様的にできないと思います。
　これは別に他プログラムとのやり取りをする領域かどうかは関係ない話では？

54 ：仕様書無しさん：2005/07/30(土) 20:24:07

COBOL COBOL85 COBOLS
何もかもが懐かしい

55 ：仕様書無しさん：2005/07/30(土) 21:23:30

>>50
そういう単純君が多いのよね。悲しいことに。

56 ：仕様書無しさん：2005/07/30(土) 21:36:56

ボコルなんか覚えたらちんぽが腐って抜け落ちちゃうよ

57 ：仕様書無しさん：2005/07/31(日) 06:08:07

おれは富士通、IBMのJCL、そしてCOBOLしか知らん！！！

※それでもフリーで年商１０００万円弱！！！参ったか！！！がははは！！！

58 ：仕様書無しさん：2005/07/31(日) 06:28:06

俺、下っ端に指示するだけで年収1500万。　頑張れ下っ端。

59 ：仕様書無しさん：2005/07/31(日) 06:38:20

>>58
時給1500円の間違いだろw

60 ：仕様書無しさん：2005/07/31(日) 07:03:11

社内ベンチャーで、自社システム用の集中管理システム作ったんだわ。
元々、人間が全てモニタするっていうアホなシステムで、外注で管理してたんだが、これが年間で億超えてたんだが、これを半額で請け負ってるんでな。
実働は下っ端7人で回ってるから、残った金が全部俺の給料。　事務とか、親会社にある程度任せて、うちでやらなきゃいけない分はパートのおばさんで安くすましてる。
客を捜さないでも親会社が客になってくれるから楽だった。　値切られるがな・・・（台数が当初より1割増えてるのに、入ってくる金は数％しか増えてねぇ）

61 ：バブル期就職：2005/07/31(日) 08:52:55

コボルって勉強するような要素ほとんど無かったと思う
ＩＭＳとかを勉強したような記憶が

62 ：仕様書無しさん：2005/07/31(日) 11:31:53

>>61
別に言語仕様に限った話ではないでしょ。
古典的だけど、レコード処理をするときに、基本的には
必ずファーストリード（１次入力）してから、EOF判定を前判定
として主処理に入って、主処理の最後に２次入力を行うとか、
パターンマッチング処理だとか、コントロールブレイク処理だ
とか、そういった定石とともに学ぶ価値があるんだよ。
最近じゃ、新人研修でも学校でも、そういうロジック的な定石
なんかは教えないじゃん。

63 ：仕様書無しさん：2005/07/31(日) 11:45:07

のーたりんのボコラに１０００万も払う馬鹿な会社があるのね

ちなみに俺は理学博士で、最低単価２００万／月だ

どうだ、おまいには逆立ちしたって無理だべ、馬鹿ボコラー！

64 ：仕様書無しさん：2005/07/31(日) 11:57:22

>>62
そんなRDB出現以前のバッチ処理が「基本」だと言う時点でｵﾜｯﾄﾙ
SQLから入るどころかいまやO/Rマッピングからなのに。

65 ：仕様書無しさん：2005/07/31(日) 12:28:03

>>63
だから・・・時給200円の間違いだろ・・・
気がふれて当然か・・・

波阿弥陀仏・・・

66 ：仕様書無しさん：2005/07/31(日) 12:32:49

>>64
古典的だと断っているでしょ。
RDBを使う場合でも、オンラインでも、この古典的な「基本」は
重要ですよ。そこに気がつかないことこそ、表面的な技術しか
見ていないということになるよ。んで、保守性の低いシステムを
大量に生み出してしまう。
言語が変わっても、考え方まで刷新されているわけじゃない。
OOPにしたって、結局一番細かい部分では従来の手続きの
記述があるわけだから。

67 ：仕様書無しさん：2005/07/31(日) 18:16:43

日本語を話すためには、古典である漢文を習得しなければならないみたいな論拠だな。
英語を学んだ方が役立つと思うぞ。
COBOLerにとっての英語とは、UNIX, Windows, C, Java,...
ようるすに、メインフレームCOBOLオフコン以外の全てと言うことだよ。

68 ：仕様書無しさん：2005/07/31(日) 18:21:53

>>61
言語は勉強するためにあるんじゃない。実務で使うためにある。

学問的とか芸術的とかのソースが好きなら、確かにCOBOLは全く向かない。

69 ：仕様書無しさん：2005/07/31(日) 18:24:15

>>64
良し悪しは別として、階層型DB(IMS等)は、
今でも応答速度重視の大規模システムでは基本ですが...

世界中の大半の自動車会社、航空会社、銀行とか。
(ただし中小では基幹もRDBも確かに多い)

70 ：仕様書無しさん：2005/07/31(日) 19:15:07

>>69
現在の新規大型案件は、RDBになっています。
NTT Docomoの料金計算システムは、10年以上前にRDBに移行済み。
月間数十億レコードのデータが発生するシステムでも、10年前にRDBだよ。
階層型でないと構築できないシステムとは、いったいどれほどの超巨大なシステムなんだ？

現在、階層型を使用しているのは、
(1)リスクを恐れる役人のような腰抜けシステム部門
(2)メインフレームベンダーに騙されているバカなシステム部門
(3)単純に、再構築する金がない貧乏会社
(4)RDBすら覚えられないバカ情シスが抵抗している会社

71 ：y@su ◆8oZYsxYASU ：2005/07/31(日) 19:18:09

COBOLの勉強に限っては情報処理技術者試験の問題は結構いいと思うけど。
Cのソースはやけに汚い気がする。。

72 ：仕様書無しさん：2005/07/31(日) 20:26:34

普通に商用UNIX上で動くOracle等のRDBとCOBOLで書かれた業務AP
の組み合わせで構築されているシステムは数多く存在します。
COBOLを使っているシステムがRDB知らないとかUNIX知らないとか
いっている時点で、相当の世間知らず。
>>71
学究部門の人が書くC言語は本当に汚いよ。
業務システムの保守を知らんから。そういうやつに限って、上記のような
世間知らずだったりする。

73 ：仕様書無しさん：2005/07/31(日) 20:31:49

>>70
まさに>>50 が言っているような人だね。あんた。
現にそういうシステムもあるという事実すら、認めようとしない。
夏厨といわれても仕方が無いですよ。

74 ：仕様書無しさん：2005/07/31(日) 21:00:48

いや、今時マッチングだのコントロールブレイクが基本と言ってる奴がいるから
「保守性が低く」なるんじゃないか？
そんな奴に限って自分じゃJCLも切れなかったりするしな。
基本が大事だと言うならそれこそ360アセンブラから入らんと。保守性のためになｗ

75 ：仕様書無しさん：2005/07/31(日) 21:47:23

UNIX+RDB+COBOLは銀行のシステムぐらいしか見た事無いや

Cのソースが汚く見えるのは言語仕様依存でしょう
人によってはエレガントと呼ぶ
まあCで業務系なんかやらんでしょ今時

JCL切るならパンチカードでどうぞ

76 ：仕様書無しさん：2005/07/31(日) 22:16:56

>>74
> 今時マッチングだのコントロールブレイクが基本と言ってる奴がいるから
　おまえ学生か？　マジでいってんのか？
　とても仕事でシステムを見ている人間のせりふとは思えないな。
　言語どうのの問題じゃねぇぞ。
　考え方的には、まったく陳腐化していない基本中の基本だぞ。
　Javaでだって使う。

77 ：仕様書無しさん：2005/07/31(日) 22:28:13

>>76
マジで言ってる。そんなこと言ってていつまでもRDBなのに複数カーソル作ってマッチングもどき
設計したりする奴が絶えないからな。果ては効率重視だからVARCHARは使えないよ、とかな。
SQL工夫すればいいのをロジックで実装したがる奴大杉。

78 ：仕様書無しさん：2005/07/31(日) 22:28:51

>>76
>Javaでだって使う。

「Javaでだって使う奴がいる。」の間違いだろ？

79 ：仕様書無しさん：2005/07/31(日) 22:48:54

だいたいファーストリードだEOFだなんだってなCOBOLの都合だ。
抽象化のレベルが昔と今で違うだけ。
んならチャネルマクロ出してブロックファクタ計算してが「基本」だって言われても
文句はなかろ？
昔は昔、今はその上に乗った「基本」があんじゃないの？

80 ：仕様書無しさん：2005/08/01(月) 22:11:49

コボル出来る俺様が来ましたよ。
コボルは素晴らしい言語で、素人でも2週間でマスター出来ると言われてるよ。
プログラム言語経験者なら3日、かなりセンスの悪い人でも3カ月でマスター出来ると言われているよ。

つまりコボル1年やってて分からないってのは非常にまずい。
コボルなんてさっさと2週間で覚えて、別の事を勉強しなさい。

81 ：仕様書無しさん：2005/08/02(火) 00:30:48

>>57
コボルで稼いでんの？それとも、SE/PMとして稼いでんの？

前者ならマイッタ。

82 ：仕様書無しさん：2005/08/02(火) 01:05:45

もっと突っ込むと、SQLを投げておくのは、安全性の面で有効とは思うけど、
アクセスが激しい環境では、SQLの乱発はロックの粒度が荒くて、きつい、せめて、主幹のコア環境は避けたい
例えば、select と COBOLのreadでは粒度が全然違う(簡単にこれだけでは比べられないけど)
それは、オープン言語で開発する時にも、SQL投げるかそうでないかで、ロックのキツサは違ってくるけど、
ただし、充分に練り上げられた、そう例えばミドルウェア製品として出ているような、ものでなければ危なくて使えない
案件ごとでのカスタマイズは危ない
だからワレズが豊富な「サーバサイドJAVA」ということになってくる

83 ：仕様書無しさん：2005/08/02(火) 01:12:58

↑日本語、せめてC言語

84 ：仕様書無しさん：2005/08/02(火) 01:54:22

COBOLやって、コボラーは最低の人間だということを勉強した。
もちろん、まともな香具師も居るだろうけど・・・

85 ：仕様書無しさん：2005/08/02(火) 18:59:13

クールな
おまえに
ボイン
おっぱい
ラッシュ

86 ：仕様書無しさん：2005/08/03(水) 21:44:42

コボル出来る人がコボラーではない。
プログラマで長年やってても、コボルしか出来ないのがコボラーである。
つまりコボラーにまともな奴はいない。

87 ：仕様書無しさん：2005/08/04(木) 16:40:03

いつもながら、笑えるな↑
おまえが、好きな言語をやれば？ｗ

88 ：仕様書無しさん：2005/08/05(金) 22:44:29

最強のCOBOLが発表されました。
その名も、COBRA COBOL 「コブラコボル」
名前からして強そうです。

CORBA（コルバ）じゃないからね。
でも、CORBA環境で使うみたいだけどよ。
CORBAでCOBRA COBOL って、しゃれててｶｯｺｲｲ！

89 ：仕様書無しさん：2005/08/05(金) 23:04:15

>87
悪いが何を言いたいのか分からん。
「好きな言語をやる？」
好きな言語を勉強しろと言うことか？好きな言語で仕事しろと言うことか？

90 ：仕様書無しさん：2005/08/06(土) 23:11:04

>>88
そのCOBOLはどこで開発されたの？
調べたけど、わからんかった。
すまんが詳しく教えてくれ。

91 ：89：2005/08/07(日) 02:44:16

>>90
全部ネタだ。すまんかったな。

92 ：仕様書無しさん：2005/08/07(日) 07:35:40

>>77
確かに、RDBの仕様を十分に使いこなしていない業務システムが多い。
RDBを単なるISAM的にしか使ってなかったり…。
それはわかるよ。でもな、その理屈だって、見方を変えれば、RDBベンダ
の都合であって、保守を重視する業務システムの都合じゃない。
別に、RDBの本来の機能を知らないからそういうシステム設計にしている
わけじゃない。いろいろ開発効率とか、保守フェーズに移行したときのこと
とか、いろいろ考えた上で決めているのだよ。

新しいものを知ろうとしないやつは馬鹿だが、新しいものを妄信するやつも
馬鹿だ。今の技術は過去のものの積み上げ名のだから、その意味では、
枯れた考え方を知っておくことはとても重要だ。
そういう意味では、あんたが嫌いな設計手法だって、基本には違いない。

93 ：仕様書無しさん：2005/08/07(日) 09:04:19

>>92
そういう話は、学生や下流PGが多数派のこの板で言っても、理解できる人は少ないぞ。

上で何度も出ているが、保守性の高い業務システムの構築という面では、COBOLには
一日の長があるということだ。つまり、知っておいて損は無い。

コボラーとか言って文句言っているやつらは、一度、C言語の汚いソースの保守してみろ
って。エレガントとか言ってられねぇって絶対。

94 ：仕様書無しさん：2005/08/07(日) 16:27:47

>>92
同意

>>93
保守不能なソースはその記述言語に無関係に存在する

95 ：仕様書無しさん：2005/08/08(月) 21:29:06

このたびCOBOLを覚えることを余儀なくされた新人デス
結構国の根幹に関わる仕事みたいですが、新人デス

コボラーではなく玄人っぽくCOBOL人（コボルト）と呼ばれるように精進するッス

96 ：仕様書無しさん：2005/08/08(月) 21:57:29

新人なら、「コボちゃん」と呼ぶのが一般的だ

97 ：仕様書無しさん：2005/08/08(月) 23:12:12

CreateGame～陸海空オンライン～
有志によるＭＭＯ製作です。
力ある奴だけこぃ！

自民党解散キターーーーーーーーー

98 ：仕様書無しさん：2005/08/13(土) 14:07:06

>>95
官公庁の仕事か何かでしょうか？
確かに、金融とか官公庁とか公共企業などの基幹系では
COBOL必須だからな。

99 ：仕様書無しさん：2005/08/13(土) 16:03:59

お役所系だと、最近の新規案件ではCOBOLは
ちょっと嫌われぎみっすよ。

100 ：仕様書無しさん：2005/08/13(土) 21:49:23

>>99
それは局所的にはね。新規のサブシステムを組むときには、最新のWeb系の
画面を組み入れたJava系フレームワークを使うんでしょ。
でも、それは現有の膨大なシステム（ほとんどがCOBOL）からしてみたらごくわずか。
下手に新旧混合させるから、いろいろな問題がでる。どっちがいいとか、そういう問題
ではなくてね。やっぱり人の問題が出てくる。両方知っていなければいかんのだが、
片方しか知らんやつが多すぎ。

101 ：仕様書無しさん：2005/08/13(土) 22:00:55

特に基幹系業務システムは、いくら新規システムでも、既存システムとの連携は
絶対にあるからな。相手がCOBOLで組まれている以上、知らないじゃすまされん。

102 ：仕様書無しさん：2005/08/14(日) 00:38:42

俺はCOBOLしか知らないんで、最近、銀行を中心に金融関係の仕事ばかり回って来る。
CとJAVAの勉強を始めますた。。。。。

103 ：仕様書無しさん：2005/08/14(日) 00:51:08

金融系だってＣＯＢＯＬは減ってるよ。

104 ：仕様書無しさん：2005/08/14(日) 08:37:23

>>102 COBOLプログラマが他の言語を学習する時には
全部課題の一部をCOBOLのアプリケーションを呼びだす
仕様に変えてしまうといいようです。
つまらないグラフィックの例題が、日頃の実務プログラムの
強化に使えたりして楽しいです。

105 ：仕様書無しさん：2005/08/14(日) 10:28:01

>>103
その言葉は１０年以上前からずっと言われてきた。
正確に言うなら、COBOLの割合が減っている、ということ。
COBOLプログラム資産自体は、それほど急激には減って
いない。企業によっては、いまだに増え続けている。
昨今では、COBOL知らないやつが多くて、かえって人手不足。
重要な基幹系システムの保守業務なんかでは重宝される。

106 ：仕様書無しさん：2005/08/14(日) 10:53:45

>>101
俺の先輩もみな「COBOLを知らないと相手システムも作れない」とか
「リニューアルできない」と言うのだが、それって結局既存システムの
仕様書がないことをすり替えてるだけだよね
「COBOLで基幹システムを支えてきた俺達ってスゲー」といわんばかりの中高年の人もいるけど、
外注に丸投げしといて威張る前に仕様書の一枚でも書いて残せよって
ユーザ要件と設計資料さえしっかりしてれば、基幹系だってCOBOLを一行も
書けなくても再構築できるわさ

107 ：仕様書無しさん：2005/08/14(日) 11:16:18

>>106
禿同。でも仕様書のないユーザがいかに多いことか。。。。。
ある銀行に逝ったときだが、ほどんどの重要なプログラムのソースが
失われていて、だれも怖くてメンテさえ出来ない
というトホホな状態だったよ。

108 ：仕様書無しさん：2005/08/14(日) 11:29:10

仕様書がない云々は、言語の問題じゃないけどな。

仮に仕様書がなくても、コードを追えるかどうかは、言語とアルゴリズムの問題。

109 ：仕様書無しさん：2005/08/14(日) 11:43:01

>>107
いま作っている新しいシステムだって、いずれは似たようなこと言われるんだよ。
確かに、昔はドキュメント化に対する意識が低かったのだろうが。
いまだって、開発期間と投入人員などの兼ね合いで、十分な仕様書が作れている
とは思えない。
そう考えると、仮に仕様書がなくても、保守できるように、っていう観点も必要。
その意味では、COBOLはよい言語だと思うよ。

110 ：仕様書無しさん：2005/08/14(日) 12:28:37

COBOLには、良いとこ　と　悪いとこ　がある。
悪い部分はだらだらとコーディングして行けば書ける点。

IFのネストが、変数の長さと相まって見づらい。

シーケンス番号とコメント含めて80桁/1行という狭いスペース。

良いとこは、元々データ処理を重点に考えられているから
一般ファイル、VSAM、RDB等に対応している事。

RDBは15年前には既に使えた。

RDBより前には木構造やネットワークDBが使えた。

バッチ処理では、データベースだけで処理する事は少ない。

オンラインの一部でGOTOを使うと書いている人が居るが (スレ探すのも面倒)
GOTOは使わんだろ。

GOTOを記述するのは、例外処理です。

SQLをだらだらと　1カラム/1行縦に書くのは嫌いです。
※COBOLerに多い。

111 ：仕様書無しさん：2005/08/14(日) 20:18:14

>>110
由緒ある真のCOBOLerは、１行８０カラム以内と決まっています。

112 ：仕様書無しさん：2005/08/14(日) 23:22:51

COBOL歴20年ですが、C++を始めてみました。
C++の中にJCLを埋め込んだら、なんとコンパイルに通るので驚きました。

113 ：仕様書無しさん：2005/08/14(日) 23:57:57

>>112
そりゃ通るだろｗ。

//SYSUT1 DD DSN=&&SYSUT1,UNIT=SYSDA,

とかだもんなｗ。

114 ：仕様書無しさん：2005/08/15(月) 21:16:30

システムを保守してるんじゃなくて、
きちんと文書化しないことで自分の仕事を保守しているひとのスレですね。

115 ：仕様書無しさん：2005/08/15(月) 22:07:00

俺のまわりにいるCOBOL専門のプログラマって、
ドキュメント化が下手な人多いような気がするんだが、
みんなも同じっすか？^_^;
ソースにコメント残す人も皆無だし。
ドキュメント作らないなら、ちょっとくらいコメント
残せよっ！と思って先輩のソースを修正している
今日この頃・・・。

116 ：仕様書無しさん：2005/08/15(月) 22:14:11

>>115
俺の先輩にソースに一切のコメントを入れない奴がいたけどね w
プログラムの先頭に何をするプログラムかコメントいれてたりしてたんだけど、それも一切せずで。
保守が鬱陶しかったよ。

117 ：112：2005/08/15(月) 23:43:27

>>113
今日、オチを書こうと思ってたんだが、先にお前に書かれちまったよ。
うれしいような、悲しいような・・・

118 ：仕様書無しさん：2005/08/16(火) 14:09:35

COBOLにコメントなんか特別わかりにくいとこ以外つけんよ。
そもそもコメントつけないと分からないソースなんて悪魔的だろ。
メインの容量が厳しいのに。それにＣＯＢＯＬは可読性が良いだろ。

だいたいＣＯＢＯＬはドキュメントをしっかり作るし、
ＣＯＢＯＬはドキュメントとフローチャ－トが出来れば99.9％完成だ。

紙と鉛筆の世界だよ。

119 ：278：2005/08/16(火) 14:26:01

突然ですが、現在27才でこれから勉強してプログラマーとして
仕事をしていきたいと思っているのですが、29才ぐらいになっても
プログラマーとして雇ってくれる会社はあるのでしょうか？いままで工場勤務しか
経験がないのですが。

120 ：仕様書無しさん：2005/08/16(火) 20:05:10

希少価値があれば。

121 ：仕様書無しさん：2005/08/16(火) 20:10:53

＞＞１１９
童貞なら大丈夫だけど非童貞なら無理

122 ：仕様書無しさん：2005/08/16(火) 20:31:25

>>118
いまどき、フローチャートという用語が飛び出してくるとは、正直驚いた。

>>119
COBOLerなら大丈夫です。経験ありといってウソついて入社しなさい。
なあに、バレないって。経験無しと同じレベルのヤツがごまんといるんだから。

123 ：仕様書無しさん：2005/08/16(火) 20:55:55

それでもマッチングやらコントロールブレイクは基本なんだろうか。
新人には各種joinの使い方を実践しろ、ってもう１０年近くたつんだけど。

固定長レコードで、キー順ソートが前提で順アクセス、
その上ラインプリンタ出力を考えに。っつ今の物理モデルからかけ離れたものを
「基本」と称する神経がおかしい。誰がいまさらMT意識でプログラムすんの？

124 ：仕様書無しさん：2005/08/16(火) 22:36:27

>>118
>そもそもコメントつけないと分からないソースなんて悪魔的だろ。
俺の会社にあるソースは、悪魔だらけっす（ｗ

>メインの容量が厳しいのに。
最近の汎用機は容量いっぱいっす。そんな心配するより
コメント残して保守性あげるほうが良いっす。

>それにＣＯＢＯＬは可読性が良いだろ。
それは作者によりけりですな。教科書的なCOBOLは
すっと読めるけど、現場のソースは読みにくいのが
結構多い。

>ＣＯＢＯＬはドキュメントとフローチャ－トが出来れば99.9％完成だ。
そんなものデカい会社にしかない代物です。

125 ：仕様書無しさん：2005/08/17(水) 10:02:53

>>122
いまどき？あのな、ＣＯＢＯＬでフローチャートが無いなんて考えられない。
どうやって設計すんだ。お前の仕事は犬小屋か。

お前メインフレームやったことねえだろ。

126 ：仕様書無しさん：2005/08/17(水) 12:13:32

図式化技法とプラットフォームとは関係ないと思うけど。
方法論固定を何十年も選択し続けている組織の体質が原因でそ

127 ：仕様書無しさん：2005/08/17(水) 22:18:32

だからさ、「上流工程」って称して文書化しないことで自分の身を守ってるのが情けないんだよね。
本来業務を知ってるなら、ここはオープン化してとか自分で提案できそうなものを。
ドコを変えてドコを残す、くらいのものができなくて何のための上流なのよ。

128 ：仕様書無しさん：2005/08/18(木) 00:21:31

>>125
最近は、COBOLですらUMLだ。

フローチャートを使って、どうやってRDBを扱うのだ？
まさか、Excelで管理してるんじゃ無いだろうな？

129 ：仕様書無しさん：2005/08/18(木) 00:24:18

バカ登場

130 ：仕様書無しさん：2005/08/18(木) 00:37:34

COBOLに群がる人間は、PG、SEの中でも最下層の人間。
なんかそれをああ本当だなぁってここは感じさせてくれて
実にいい感じだよいいよいいよぉ

131 ：仕様書無しさん：2005/08/18(木) 01:20:53

>>125
フローチャートのレベルによるな。
学校でやるような、１ステップ１つの箱なんてフローは仕事ではほとんど書かない。（新入社員の練習のために書かせたりするが）
「XXXのDBから、YYYの条件のレコードを読み込む。」程度で、ひとつの箱のフローなら書くけど、
その程度なら、文章でも十分。複雑な判定の部分だけ、ほんとのフローを書くけど、それは仕様書のほんの１部です。

132 ：仕様書無しさん：2005/08/18(木) 02:52:04

プログラムのフローの話じゃないだろ、ＪＯＢだろＪＯＢ

133 ：仕様書無しさん：2005/08/18(木) 02:55:37

>>125
経験上、
メインフレームを扱っていることを自慢しているヤツに、
まともなヤツがいたためしはない。
きっと、お前もその部類だろうね。

しかもそのメインフレームとやらも、現在ならオフコンで処理できる規模を
古い小型メインフレームでオナニー的に稼働させているだけ。

134 ：仕様書無しさん：2005/08/18(木) 02:56:18

COBOLでＵＭＬ？　ＰＣ-ＣＯＢＯＬの話か？

135 ：仕様書無しさん：2005/08/18(木) 03:01:15

もしかしてプログラム単位の話してるのか？

136 ：仕様書無しさん：2005/08/18(木) 03:05:23

COBOLのシステムでフロー図がないなんて考えられない。

137 ：仕様書無しさん：2005/08/18(木) 03:07:43

メインフレームを扱ったことがないのにＣＯＢＯＬを語るなんておかしいね。

138 ：仕様書無しさん：2005/08/18(木) 22:08:29

ジョブフローなら普通の話だが、プログラムの詳細なフローを書くような会社があるだなんて信じられない。
専門学生の戯言かと思ってしまう。

139 ：仕様書無しさん：2005/08/18(木) 22:46:48

>>138
勝手に「詳細な」なんて付け加えるなよ

140 ：仕様書無しさん：2005/08/19(金) 00:36:03

一般的に、詳細なものを「フローチャート」といい、
荒っぽいものを「フロー」というのが業界の慣例だ。

荒っぽいものを「フローチャート」というのは、経験のない学生である証拠。

141 ：仕様書無しさん：2005/08/19(金) 02:04:53

>>140
負け惜しみで詭弁をたれるのは2chだから仕方ないとして、
せめて>>138の内容との整合性くらいは取ってくれないか。

142 ：仕様書無しさん：2005/08/19(金) 09:34:28

ﾜﾛｽ

143 ：仕様書無しさん：2005/08/20(土) 02:31:19

何十年前の話だよ。

144 ：仕様書無しさん：2005/08/20(土) 11:57:34

オフコンなんて、もう稼動していないだろ。
生産していないし。

メインフレームのCOBOLが基本だが

Pro*COBOLならば、UNIX環境になるし
Windowsで稼動する日立のCOBOL85や、富士通のNetCOBOLなんてものもある。
日立のCOBOL85ならば、VOS3準拠でコーディングできる統合環境だよ。
最新バージョンはCOBOL2002

WebSphereの一番高いやつならば、Javaのほかにも CICS, PL/I, COBOLなんて文字がずらずらでてくる。
IBMのCOBOL開発も、PCで出来るという事。

145 ：仕様書無しさん：2005/08/21(日) 01:25:30

なんのなんの。
Intel系のCPUでエミュレートしながら、細々とオフコンは生きています。

146 ：仕様書無しさん：2005/08/21(日) 12:22:10

なんだか、言語云々の話ではないな。レスを見ていると。
上でフローチャートという言葉が出てきて、それの賛否があったが、
フローチャートをどの記述レベルで認識して使っているかによるな。
確かに、昔ながらのフローチャートは、アセンブラなどでもない限り、
COBOLだろうがなんだろうが、業務システムでは使ってないだろう。
だが、その代わりになるプログラム設計図（企業などによって色々）
を考案して使っている。それもフローチャートといっているのであれ
ば、今でも使っている。
COBOL云々というより、業務システムでは云々ということだろ。
俺はVBのプログラムで単一モジュールの中にこれでもかってくらい
多重ネスト構造で組んで、保守不可能になっているバカなやつを
知っている。
業務システムで利用されてきた歴史が長い＝COBOL
ということであって、ほかの言語でも、業務システム保守を意識した
つくりをすれば、差は無くなる。

147 ：仕様書無しさん：2005/08/21(日) 12:24:28

学生や下流PGには、業務システムの保守云々なんて話をしても、わからねぇよｗ

148 ：140：2005/08/21(日) 13:46:46

俺は学生じゃねえよ、この池沼ども。

149 ：仕様書無しさん：2005/08/21(日) 14:01:21

>>144
> オフコンなんて、もう稼動していないだろ。
> 生産していない

国産オフコンは新製品は出ないが山と稼動してる。
「コンピュータユーザー年鑑」最新版を参照。

唯一IBMのAS/400(iSeries)が現役。
POWER系CPU、H/W RDBMS、EBCDIC、シングルレベル記憶など異色の存在。

・夜中に停電工事があっても電源OFFと電源ON時刻をセットして帰宅するだけ。
・FIXはメニューで選んでメディアを入れるだけ。
・DISK管理は原則なし（DISK増設すればファイルシステム的管理は不要)。
...などなど、専任エンジニアを置けない職場では今でも便利。

150 ：仕様書無しさん：2005/08/21(日) 17:55:46

コボル一筋５年だけど、高度（ＮＷ，ＤＢ）合格できたよ！
どうだすごいだろう。

151 ：仕様書無しさん：2005/08/21(日) 18:28:53

>>150
そんなの学部生でも合格するよｗ

152 ：150：2005/08/21(日) 18:39:24

>>151
そんな稀有な例を出してもナンセンスさ！
オープン系、ウェブ系で何年もやってるのに、
オノレが学部生でも合格できると抜かす
高度（ＮＷ，ＤＢ）に合格できない奴らの何と多いこと！

153 ：仕様書無しさん：2005/08/27(土) 21:16:53

もう宿題片付けたか？

154 ：仕様書無しさん：2005/09/03(土) 00:05:51

いろいろな言語を経験したが、COBOLは素晴らしいと思った。
ソースが機能ごとにセクション分けされており、構成が統一されている。
その他の言語のように、プログラマごとに好き勝手な位置に
変数宣言が散在するような猥雑さは、COBOLには存在しない。
まさに真面目な、洗練された高等言語と言って差し支えない。

155 ：仕様書無しさん：2005/09/03(土) 08:39:54

>152
今時NetWareですかそうですか。

156 ：仕様書無しさん：2005/09/03(土) 09:24:54

>>144
＞オフコンなんて、もう稼動していないだろ。
自分の周囲に無い物は世の中に存在しないと思ってるのか

157 ：仕様書無しさん：2005/09/04(日) 19:05:07

>>156
じゃあ、お前は神が実在すると思っているのか？

158 ：仕様書無しさん：2005/09/04(日) 19:13:28

周囲にいればそう思っているんじゃない？

159 ：仕様書無しさん：2005/09/04(日) 20:05:46

COBOLの神である俺様が、このスレに降臨しますた！

160 ：仕様書無しさん：2005/09/05(月) 10:25:08

出ていけ

161 ：仕様書無しさん：2005/09/08(木) 14:59:10

塩をまくにはどういうコードを

162 ：名無しさん＠そうだ選挙に行こう：2005/09/11(日) 14:16:10

COBOLは古い！！
これからはフォートランの時代だ。

163 ：名無しさん＠そうだ選挙に行こう：2005/09/11(日) 19:07:31

101 名前：名無しさん＠そうだ選挙に行こう[] 投稿日：2005/09/11(日) 18:50:19
コボルって命令を記述するためにかかるキータッチの数が多すぎ・・
これもっとシンプルにしたコボルって無いの？
例えば
COMPUTE　A=B+Cは
A=B,C
MOVE　A　TO　Bは
MB　A､B
なんかに省略出来るやつ

164 ：仕様書無しさん：2005/09/12(月) 00:09:24

>>163
お前、頭悪杉

165 ：仕様書無しさん：2005/09/12(月) 01:47:40

>>163
マイナーでよければあるよ。
NEしーのCOBOL-Sとか>>163みたいな感じ
漏れはやらなかったけどね
しっかしNいーCはローカル言語をつくっちゃーつぶしているな
恐ろしいことにオープン系も独自の言語だよ。
一応OOPLだけど

166 ：仕様書無しさん：2005/09/12(月) 12:36:54

はやくCOBOL2005出せよ

167 ：仕様書無しさん：2005/09/12(月) 12:49:06

EclpseでもCOBOLが使えるそうだ

168 ：仕様書無しさん：2005/09/12(月) 12:50:48

Eclpse→Eclipse

169 ：仕様書無しさん：2005/09/17(土) 02:52:18

>>168
こまけーよ、お前
そーゆーのは、女に嫌われるよ

170 ：仕様書無しさん：2005/09/17(土) 14:30:22

>>163 タイプ数より見やすさ・保守性が大事

171 ：仕様書無しさん：2005/09/17(土) 14:48:04

>>163
コーディングシートに △△△-o-×××-suru.
といった冗長な手続き名がならぶプログラムを
書き殴り、それを専業のタイピストに渡す。
一休みしている間には機関銃を撃つような勢いで
彼女はカードにパンチし終わっている。
そんな時代のプログラマが未だ現役なのがCOBOL。

君の指摘は今更。間が抜けているのだよ。

172 ：仕様書無しさん：2005/09/17(土) 14:49:43

ごめんなさい。 △△△-O-×××-SURU.
だなー。

173 ：仕様書無しさん：2005/09/17(土) 15:04:34

オブジェクト指向に対応したCOBOLも登場し
新たな開発スタイルへをパラダイムシフトしていたことに
期待したんだけど
なんで今時になって>>163みたいな読みにくい書き方をするかな

174 ：仕様書無しさん：2005/09/17(土) 15:07:22

>>163は別に読みにくくもないし
当を得てると思うが。

175 ：仕様書無しさん：2005/09/17(土) 17:17:05

MVより、MOVEの方が
人間の感性として自然でしょう。
そこがCOBOLの良いところ。
速いタッチタイプのできる人なら、
意味のある単語を打つ方が楽。

Cとか流行のスクリプト言語とかの毒々しい
破綻したキーワード・文法では頭が疲れてしまう。
MOVEやADDの構文を初めて見た時は
その美しさに鳥肌モンの感動を覚えたものだ。

176 ：仕様書無しさん：2005/09/17(土) 21:37:43

>>174
失礼ですが、あなたの歳はいくつくらいでしょうか？
それから、COBOL以外のプログラミング言語経験は
お持ちでしょうか？　もしお持ちでしたら
その経験のあるプログラミング言語を列挙していただけないでしょうか？

177 ：仕様書無しさん：2005/09/18(日) 01:20:23

＞MB　A､B
アセンブラかいな。

178 ：仕様書無しさん：2005/09/18(日) 08:40:09

>>174がアセンブラ出来るとしたら>>176に勝ち目は無いな

179 ：仕様書無しさん：2005/09/18(日) 12:26:26

汗のニモニックライクにするならMVのほうがいいんじゃ？MBじゃメガバイトやマルチバイトっぽくない？

180 ：仕様書無しさん：2005/09/18(日) 14:10:30

>>178
アセンブラもCOBOLもできますが何か。
折角高級言語を使っているというのに
未だに読みにくいコードを書く癖が理解できないのですが。
昔の方ですか？

181 ：仕様書無しさん：2005/09/18(日) 14:13:49

>>180
ｳｷｰｰｰ
お前ムカつくﾅﾘｰｰｰｰ!"!!!

182 ：仕様書無しさん：2005/09/18(日) 14:32:10

ﾜﾛｽ

183 ：仕様書無しさん：2005/09/18(日) 21:19:28

COBOLって高給取り言語になりつつね？

184 ：仕様書無しさん：2005/09/19(月) 11:38:44

ない。

シンタックスからすでにJavaに敗北している。
日立の社員がJavaよりもCOBOLが
良い点を解説しているサイトがあったが
あまりにも説得力がない。
下らない点でJavaより使いやすいとかいっている。
本当にミクロな視点でしか者が見えない香具師が解説してるって漢字だったなあ。
JavaのBigDecimalが演算子が使えないからCOBOLのほうがいいとか
その程度のレベル。

んなもんJakarta Velocityとか使えば簡単に解決できるだろw

185 ：仕様書無しさん：2005/09/19(月) 17:19:47

まだ一長一短という概念を理解できない奴がいるのか

186 ：仕様書無しさん：2005/09/19(月) 17:54:28

いるなあ。
Jakartaのような外部ツールを入れれば
それだけシステムの保守や安定性で不利となる。
COBOLがなぜこれだけ長い間使われているのか、
謙虚に評価できない人は技術者としてダメだね。

187 ：仕様書無しさん：2005/09/19(月) 18:14:30

COBOLが長い間使われているのを評価することは吝かではないし、
他者にやらせることも状況によってはありうるだろうが。
自分がやるのは「技術者として」イヤ

188 ：仕様書無しさん：2005/09/19(月) 21:18:33

COBOLのシステム保守が問題になっているのを直視できない人は技術者じゃないね。

189 ：仕様書無しさん：2005/09/20(火) 20:03:13

>>186
> いるなあ。
> Jakartaのような外部ツールを入れれば
> それだけシステムの保守や安定性で不利となる。

そんなことを言うお前は愚かだ。

何度も世界中の多くの人によってテストを繰り返され、
信頼と実績を誇るオープンソースプロダクトTomcatを
JavaApplicationServerとして使っておきながら
Jakarta Commonsを使うことを拒否するヴァカがいるんだな。
Commons製品はTomcatにもすでに使われているにもかかわらず、
安定性が不利だと勘違いするとはなんとも愚かなもんだ。

安定性はかなり高く実績もある。
Jakarta 製品は、さらに言語としての信頼性の高いオブジェクト指向言語Javaを使っており
でありオブジェクト指向を首尾良く使いこなしたAPIだ。
そこらへんのDQN個人やDQNエンジニアが作ったAPIよりも信頼性がある。

190 ：仕様書無しさん：2005/09/20(火) 20:04:29

> COBOLがなぜこれだけ長い間使われているのか、

他にまともな言語が使われなかったこと、当時メモリが高価だったから
たまたまCOBOLがしばらく優勢だったわけだが。

しかも35年前はオブジェクト指向も普及していなかった。
テストの自動化という発想も普及していなかった。
それでたまたまCOBOLが長い間使われていただけだということに気づかないとは
愚かだ。

オスマントルコ帝国は長く続いたからその国はアメリカ合衆国よりも優勢か？
アフォだ。長ければ偉いってもんじゃない。

> 謙虚に評価できない人は技術者としてダメだね。

おまえさんのように
論理的に評価できない奴は技術者として駄目だね。

191 ：仕様書無しさん：2005/09/20(火) 20:53:00

>>189-190は釣りか？

192 ：仕様書無しさん：2005/09/20(火) 21:17:16

ストアドプロシジャだとコケたらロールバックできるけど、
ファイル処理がメインのCOBOLだとこけたら途中までJCLを削ってリランしてるよ
COBOLでトランザクション制御ってできるの？
どこが保守性や安定性で有利なのかよく分からん

193 ：仕様書無しさん：2005/09/20(火) 21:27:20

なんでstored procとCOBOLを同列に語れるのか
俺には全く理解できない

194 ：仕様書無しさん：2005/09/20(火) 21:35:41

え？じゃー>>193はバッチ処理は何で開発してるの？

195 ：仕様書無しさん：2005/09/20(火) 21:47:55

VC++

196 ：仕様書無しさん：2005/09/20(火) 21:48:51

>>192
PRO*COBOLなら普通に出来るんちゃう？

197 ：仕様書無しさん：2005/09/20(火) 21:59:01

既存のシステムを完全に移植するのがどれだけ大変なことか
解らない人がいるのはこのスレですか？

198 ：仕様書無しさん：2005/09/20(火) 22:35:01

COBOLの老朽化したシステムを移植するならすべて捨てて
最初から作り直したほうが効率がいい。

九龍城のような古い家(COBOLシステム)なんか
リフォームすらできない(オブジェクト指向が無い)のですべて破壊して
新たに作り直したほうが効率が良い。

199 ：仕様書無しさん：2005/09/20(火) 23:22:36

COBOLのシステムをJAVAで完全移植しましたが何か？

200 ：仕様書無しさん：2005/09/20(火) 23:28:42

完全に移植するだけ無駄だよ。
汚いウンコを新しい便所に運ぶ必要なんて無い。

201 ：仕様書無しさん：2005/09/20(火) 23:56:34

>>199
すげえな。
でもパフォーマンス的にはどうだい？
やっぱCOBOLよりJavaはかなり遅いのではないか？

202 ：仕様書無しさん：2005/09/20(火) 23:59:45

>>201
そっすね。
手続き型言語のまんま移植だからやはり遅い。というか別にJAVAじゃなくても良かった気も。

203 ：仕様書無しさん：2005/10/02(日) 16:04:00

COBOLにはCOBOLなりの活用分野がある。
JavaにはJavaなりの活用分野がある。
それだけだろ。
言語に限らず、設計手法としても、
手続き主導のほうが楽なときもあるし、ＯＯじゃないと
複雑怪奇になる場合もある。
なんで、ひとつに統一しようとする？
なんで、自分が知らん分野を否定ばかりする？

スレ的にCOBOLについて言えば、シェアはともかくとして、
COBOLによるシステムはずっと引き継がれるだろう。
つまり知っておいて損は無いとは思う。

204 ：仕様書無しさん：2005/10/03(月) 00:04:30

>>203
COBOL知ってますって言うとCOBOLの現場に飛ばされるので、知っていると損をするよ！

205 ：仕様書無しさん：2005/10/03(月) 01:14:31

>>204
COBOLの現場に飛ばされたら
そこで頑張るだけだろう。
君は何をそんなに恐れているのだ？
COBOLは単価高いし仕事も楽だぞ。

206 ：仕様書無しさん：2005/10/03(月) 04:18:36

つ[浦島太郎]

207 ：仕様書無しさん：2005/10/05(水) 02:24:33

毎日汎用機でCOBOLのバッチプログラム書いてる。
・・・・・面白くない。

208 ：仕様書無しさん：2005/10/06(木) 02:15:03

毎日Javaやってても別に面白くも何ともないが・・・

209 ：仕様書無しさん：2005/10/06(木) 10:59:01

毎日Rythonやっててハッピーだが。

210 ：仕様書無しさん：2005/10/07(金) 20:13:49

COBOLのプログラム書いてて面白さを感じるようなら変態も極まれりってとこだな。

211 ：仕様書無しさん：2005/10/14(金) 07:35:24

COBOLやってる人てSQLとかできる？

212 ：仕様書無しさん：2005/10/14(金) 22:45:07

>>211
COBOLでSQL使えないと思ってる香具師発見。
正確に言えばSQLはプレコンパイラでCOBOLに変換されるのだがな。

213 ：仕様書無しさん：2005/10/15(土) 00:20:57

Pro*COBOLって何だっけ？

214 ：仕様書無しさん：2005/10/15(土) 11:46:33

>>211
できるだろ。普通に。…っつーか、なんでそういう発想になるかな？
いまどき、ＲＤＢの知識は必須だし、多くのシステムで使われている。
無論、業務ロジックの記述はＣＯＢＯＬで、ということも多い。
ＣＯＢＯＬはコンパイラであり、開発言語。一方でＳＱＬはＲＤＢ関係。
直接関係はまったく無いと思うが…。
（システムによっては言語にＳＱＬを組み込む手法だったり、ＤＢアク
セスを外だししたりしているが、テストの際にはＲＤＢ使うからな）

確かに、Ｃの熟練者に比べると、アセンブラ的な知識は身につきにくい
のは事実だ。だから、そういう比較なら的を射ているが、ＳＱＬを話題
に出すのはまったく厨房の理屈だな。

215 ：仕様書無しさん：2005/10/15(土) 11:49:05

＞Ｃの熟練者に比べると、アセンブラ的な知識は身につきにくい

　そーいう視点なら、ＣＯＢＯＬとJavaは同レベルなんだがな。
　厨房にはそれがワカラナイ

216 ：仕様書無しさん：2005/10/17(月) 19:11:30

>>1
が居ない件について

217 ：仕様書無しさん：2005/10/17(月) 21:48:16

気にするな

218 ：仕様書無しさん：2005/10/23(日) 01:24:32

>>1
自宅のパソコンでメインフレームできるよ。
これでCOBOLもJCLも勉強しろ
http://www.genny.or.jp/kaz/hercules/mvs38j_top.html

219 ：仕様書無しさん：2005/10/23(日) 19:44:01

まだＪＣＬってあったのか。

220 ：仕様書無しさん：2005/10/23(日) 23:15:37

COBOLやJCLなんか勉強したって、頭が腐るだけ

脳味噌が腐って蛆虫がわくヨ

221 ：仕様書無しさん：2005/11/11(金) 18:56:59

UNIXで動いてるやつもCOBOL８５なの？
ぜんぜんちがう？

222 ：ハーピィ：2005/11/11(金) 22:02:06

E・∇・ﾖﾉｼ　＜222ｹﾞｯﾄ♪♪

223 ：仕様書無しさん：2005/11/12(土) 22:41:13

>>221
COBOL85規格もあればCOBOL2002規格もある。
基本的にCOBOL85規格が一番多いが。

224 ：仕様書無しさん：2005/11/18(金) 15:36:44

ＣＯＢＯＬ/Ｓ

225 ：仕様書無しさん：2005/11/19(土) 15:20:33

この参考書おすすめってないですか？

226 ：仕様書無しさん：2005/11/27(日) 03:36:34

>>225
COBOL色に染まったあなたには、この本がお勧め！

http://www.amazon.co.jp/exec/obidos/ASIN/4872331265

227 ：仕様書無しさん：2005/11/28(月) 00:43:21

すべてのCOBOLl職人に読ませたい
http://www.amazon.co.jp/exec/obidos/ASIN/477940021X/qid=1133105879/sr=1-15/ref=sr_1_2_15/503-3701741-9789538

228 ：仕様書無しさん：2005/11/28(月) 13:00:38

馬鹿にされないようなURL貼ろうな

229 ：仕様書無しさん：2005/12/13(火) 11:30:27

ＣＯＢＯＬ最強！！！

230 ：仕様書無しさん：2005/12/13(火) 16:31:44

http://deekoo.net/psili/teens/japanese-cobol-chick.jpg
イメージ検索でCOBOLを検索したら、こんな画像が出てくるなんて

231 ：仕様書無しさん：2005/12/14(水) 23:56:45

GREATERの役割を教えてください。

232 ：仕様書無しさん：2005/12/22(木) 00:38:33

>>231
どうぞ
http://goraku.jp/cobol/cobol29.html

233 ：仕様書無しさん：2006/01/28(土) 22:07:30

みなさんは帳票設計時等にどんな定規をつかっていますか？
テンプレート定規に、1/10、1/8インチ等のメモリついてますが、
それだけで充分ですか？
それとも、インチ単位の直定規等を併用されているのでしょうか？

234 ：よん：2006/02/13(月) 15:02:23

はじめまして。今年の４月から入社し、cobolをはじめてやろうとしている
新人プログラマーです。（Ｃ、Ｃ＋＋、Ｊａｖａは少々できます）
なにぶん初心者なので入社前に基礎くらいは勉強しておきたいのですが、
cobolについてはまったく何も知りません。
cobolの開発環境で一番ポピュラーなものを教えていただけませんか？
あと初心者にはこれがお勧めという参考書もできれば教えてください。
お願いします。

235 ：仕様書無しさん：2006/02/14(火) 13:11:40

>>234
言語をカリカリ勉強するのは入社後でもよい。

COBOLは文法的には簡単なものだから、
覚えるのに苦労はしなので心配無用。

あと、「少しだけ出来るC,Java」なんて、
実のところ屁にもならんので、君を採用した
企業もそんな所に期待してない。

それよりこんなモノ読んでみてはどうだ？
入社して忙しくなるとなかなか読めない書の類。

http://www.amazon.co.jp/exec/obidos/ASIN/4795296758/
http://www.amazon.co.jp/exec/obidos/ASIN/4320023684/

答えになってないけど一応マジレス

236 ：仕様書無しさん：2006/02/14(火) 13:32:23

>>230
http://deekoo.net/psili/teens/
なにも入れずにﾎﾞﾀﾝを押下しても、
どうやってか、年齢をカード会社に問い合わせて
「未成年者は帰れｺﾞﾙｧ」などと言われる。

せめて入力ﾁｪｯｸは通した方が良いと思うがどうだろう。ｗ

237 ：仕様書無しさん：2006/02/14(火) 17:29:34

>>234
大変だね、入社直後にCOBOLなんて。
という俺も同じ目にあったさ。
マジレスしておくけど、COBOLなんて勉強せんでもある程度はできるって。
他の言語と同じようにわからんときに調べる程度で十分。
COBOLを少しかじって他の言語に行くしかないと思う。
俺もちょっと前までCOBOLやらされてて、
一年間上司に文句言い続けてやっと解放されたクチだし。
問題はアレだよ、意味不明なJCLとか。

238 ：仕様書無しさん：2006/02/14(火) 21:41:59

COBOLやっても未来ないもんなぁ。
昔話になるだけだよ。

239 ：仕様書無しさん：2006/02/14(火) 23:03:27

汎用でCOBOLをやってて感じるのがそれ。
NetCOBOLはどうなの？所詮はCOBOL？それとも少しは将来性（藁）ありそう？

240 ：隊員：2006/02/15(水) 19:08:07

オレは、１５年ぐらい前に汎用機全盛の頃COBOLは、何百本ソース書いたか覚えてないぐらい書いた。

その後のオレの言語の旅は．．．

COBOL（85）　→　COBOL-S　→　C　（C、PRO*C、MFC、GNU　C、）→　VisualBasic（Version2、4、6）→　C++（Boｒland,VC）　→　pearl→　cgi　→　php　→　Sun Java

現在、感じることは．．．．

COBOLは楽しくないぜ。

COBOLやるなら、ORACLEのPL/SQLのほうが現実的だ。

241 ：仕様書無しさん：2006/02/16(木) 03:23:08

PL/SQL歴10年の俺から言わせると最近はじめたCOBOLはかなり新鮮で興味深かった
なるほど、手続き型言語ってのは組み方のパターンが少なくて楽だな

242 ：隊員：2006/02/16(木) 12:19:32

>>241
スレ違いだが．．．

PL/SQL　はFUNCTION、PACKAGE,PROCEDUREを工夫して作れば、いろいろデータ（DB）操作するには適した言語だと思う。

COBOLで言うところの、メインルーチンがPACKAGE　,PROCEDURE、サブルーチンがFUNCTIONあたりかな？

PACKAGE　HEADER　と　BODYで作る書き方もあれば、PROCEDUREだけで書く手もある。

COBOL新鮮でヨカッタネ。

PERFORM　のとりこになりそうかい？

243 ：仕様書無しさん：2006/02/16(木) 14:36:40

>>234
>>218と>>232見とけば。
後、コントロールブレークとマッチングがわかれば十分でしょ。

話はそれるが、
COBOLって便利だったなと思うこと。
　集団項目で一発で比較できる。

COBOLって変だったなと思うこと。
　PERFORMがloopとcallを兼ねてる事。

244 ：隊員：2006/02/16(木) 16:58:24

>>243
集団項目かぁ。確かに楽だよな。

あとは、REDEFINES　の使っても、さらに楽だしな。

そういえば．．．．
カウンタが以下のように定義されていたとしよう。

01 CNT-A PIC 9(03).
77 CNT-B PIC 9(03).

01　A.
03 WK-CNT1 PIC 9(03).
03 WK-CNT2 PIC 9(03) PIC COMP-3.

この中で一番早いカウンタはどれでしょう？

なんて、最近は関係ないのかな？

PERFORM　は、条件PERFORMなんてのもあったっけなぁ。

245 ：仕様書無しさん：2006/02/16(木) 19:03:45

REDEFINESは確かに楽。他の言語でもやって欲しい。

けど、動的配列はお願いしたい。

246 ：仕様書無しさん：2006/02/16(木) 20:37:42

COBOLは素晴らしい言語だし、COBOLを修得している事に何のデメリットもない。
何が素晴らしいかというと、素人でも8割以上の人間が2カ月でマスター出来る所だ。
問題は1年以上プログラマやっていてもCOBOLしか出来ない奴だ。

247 ：仕様書無しさん：2006/02/16(木) 22:04:58

昔、コーディング規則でワークを全部、集団項目に書くプロジェクトがあった。

01 WORK.
03 FILLER PIC X(8) VALUE "**WORK**".
03 CNT PIC 9(3) VALUE ZERO.
03 OLD-KEY PIC X(4) .

みたいな感じ

プログラムが異常終了した時に、メモリダンプの**WORK**を目印にしてＷＯＲＫの内容を確認するため
だそうだけど。
ちなみに、このプロジェクトにはMOVE SPACE TO WORKというコードを書いて 3日で消えた外注がいた。

248 ：よん：2006/02/16(木) 23:07:08

ありがとうございます。
とりあえずcobolは入社後に勉強するとして、入社するまでは自分の興味の
ある分野を勉強しようと思います。

249 ：隊員：2006/02/17(金) 13:26:44

>>247

MOVE SPACE TO WORK

文字通り、WORK（仕事）　に　SPACE（ぽっかり空いた穴）　を　MOVE（入れた）　訳だな。

250 ：仕様書無しさん：2006/02/18(土) 00:51:13

汎用機のCOBOLやってるけどぜんぜん面白いと感じた事はない。
同じ事の繰り返しやってるだけな感じでいつも眠くなる。

251 ：仕様書無しさん：2006/02/18(土) 07:39:40

>>250
それが正常

252 ：仕様書無しさん：2006/02/18(土) 15:39:21

>>250
汎用機のCOBOLじゃなくても仕事はつまらない

253 ：仕様書無しさん：2006/02/26(日) 11:59:51

>>250
確かに同じことの繰り返しだと退屈なのは確か。

もしも、あなたが若い方だったら、COBOLの経験は相当貴重になりますよ。団塊の世代と呼ばれる方々がいなくなると、
汎用機COBOLをやる人はかなり減るし、今の若い世代は.NETやJava等で入ってくるから、昔の言語を理解できる人は相当貴重になる。

ただ、そのためには自分で仕事以外に.NETとJava等の言語も平行して勉強しておくと良いと思うけどね。

今、COBOLは.NETやJava等と連動するのも増えてきているし、汎用機からオープン系への移行も国是として進められているから、
そのための要員として移動することも併せて考えると損はしないと思うよ。

254 ：仕様書無し：2006/03/15(水) 22:33:13

これからプログラマーになろうとしている者です。

>>246の
＞素人でも8割以上の人間が2ヶ月でマスター出来る所だ

というのはどういう理解をすればよいのでしょうか。
＞問題は1年以上プログラマやっていてもCOBOLしか出来ない奴だ
という点は、スレを読んで、技術職である以上研鑽の意味を込めての件だと
理解してみたのですが。

現状の自分のスペックはしょんぼりなものです。
　・MOUSE Excell　初級
　・初級シスアド
　・年齢24
　・前職営業
　・PC歴は中3から。 Mac→Win
募集されているプログラマとは
　・プログラマー候補
　・1年程度はプログラミングの学習（教育してもらえるとの事）
　・プログラマー転身後はCOBOL言語を使用したシステム開発
です。

COBOL漬けになる事が良しとされてないスレの中、
COBOLによるシステム開発を行うとなると、スレの流れに逆行する点等あるかとは思いますが
何かご教授頂ければ幸いです。(・・`）

255 ：仕様書無しさん：2006/03/15(水) 23:07:17

>254
言語的には2ヶ月かからずに
ある程度処理を構築できるほど簡単
その代わり、安易にCOBOLのみに特化すると
他の言語でのつぶしが利かなくなる
どの言語でも仕事がしたいのであれば
COBOL(言語)の仕事の進め方を覚えるのではなく
プログラミングという仕事の進め方を覚えるがいい
ってことじゃないかね？

256 ：仕様書無しさん：2006/03/15(水) 23:20:39

自分も来週からプログラマという職につくことになりました
面接でうちはCOBOLがメインだから。。。といわれ、
少々不安になりましたが、このスレを読んで、安心しました。
そして、他の言語の勉強もがんばるどー。。。
酔いながらのレス失礼。。。orz

257 ：仕様書無しさん：2006/03/16(木) 00:06:09

>>255

>その代わり、安易にCOBOLのみに特化すると
>他の言語でのつぶしが利かなくなる

COBOLのところを他の言語（C,Java,VB･･･）に置き換えても意味が通じてしまうところがすごいな。

>>256

COBOLは事務処理に特化した言語だから、プログラミングを通して業務の勉強もした方がいい。
財務会計、給与計算などのノウハウは陳腐化しないから、上流工程の仕事ができるようになれば
単に言語を沢山覚えているだけのやつよりつぶしがきく。

258 ：仕様書無しさん：2006/03/16(木) 00:13:32

>>257
面接では早く上流工程を覚えるようにと言われたので、がんばりますね。
ありがとうございます。

259 ：仕様書無し：2006/03/16(木) 01:47:02

>>255
早速のレスありがとうございました。
「プログラミングという仕事の進め方」
がどういう物なのかが想像付かない程の物なのですが、
>>257さんの言われる様な
>COBOLは事務処理に特化した言語だから、プログラミングを通して業務の勉強もした方がいい。
>財務会計、給与計算などのノウハウは陳腐化しないから、上流工程の仕事ができるようになれば
>単に言語を沢山覚えているだけのやつよりつぶしがきく。
の様にプログラミングもCOBOLを用いた業務でも、汎用的な知識を身につけろ
みたいな理解でいます。

取り急ぎ>256さんに続けるよう、面接ｶﾞﾝﾊﾞｯﾃきます！
あ・・・・・・書類選考Orz

260 ：仕様書無しさん：2006/03/18(土) 10:26:28

UNIX-COBOLでよく使うCASEツールってどういうのがあるの？

261 ：仕様書無しさん：2006/03/18(土) 15:46:35

＞COBOLは素晴らしい言語だし、COBOLを修得している事に何のデメリットもない。
＞何が素晴らしいかというと、素人でも8割以上の人間が2カ月でマスター出来る所だ。
＞問題は1年以上プログラマやっていてもCOBOLしか出来ない奴だ。

COBOLと書いている箇所をVBに置き換えても意味が通じる件について

262 ：仕様書無しさん：2006/03/18(土) 16:10:39

>>259
プログラマは家畜同然に扱われる。
同じ家畜なら能力が高く、日々学習していく物のほうを取る。
だから能力が低い奴は捨てられる。
代わりは腐るほどいるからな。

263 ：仕様書無しさん：2006/03/18(土) 16:38:46

>>259
257氏の言うように、業務知識を身に着けると言うのはものすごく大事、
ただし、汎用的な知識よりある特定の業務に特化したほうがいい。
特にCOBOL言語は銀行、生損保などの金融系の仕事がメインになると思われるが、
金融系の業務知識がしっかり身についていれば、COBOLの仕事がなくなっても
何とかなる。

ちなみに、俺は独立してフリーになって5年、
金融業界の開発を15年続けてきたおかげで、仕事に困ったことは無い、
COBOLとPL/Ⅰしか知らないが、この数年はOpen系の上流工程や
IT工程以降の検証作業など、COBOLと全く関係ない仕事しかしていない、
昨年、法人化して現場を離れたが、いまだに指名での依頼が後を絶たない。

実際営業をしていると、特にOpen系で業務知識の無い技術者が多いと嘆かれる、
プログラミング能力も大事だが、何よりも業務知識とコミュニケーション能力を磨け、
それが今後の身のためだ。

264 ：仕様書無しさん：2006/03/18(土) 20:54:56

COBOLで食っている会社で一番難しい仕事は、
業務系COBOLerを押し込める営業です。

金融系COBOLerを人月100万円で押し込める会社は、
技術者のレベルは低くても、営業のレベルは総じて高い。

265 ：仕様書無しさん：2006/03/18(土) 21:07:50

>>263
俺は銀行員でシステム担当だが、
お前みたいなヤツがいるベンダーには絶対に発注したくないな。

金融業務の業務知識なんて、そんな威張るほどのもんじゃないだろ。
俺は、銀行業務検定試験２級なんて１科目１週間の勉強で合格したぜ。
証券外務員だって、それぞれ３日の学習で３種類とも合格した。
生保や損保の外務員試験なんて前日に勉強しただけだぜ。

お前の言う業務知識なんて、そんな試験以下だろ。

現場固有の知識なんてものは現場に聞けばいい。そいつらが一番よく知ってるんだから。
ベンダーで上流行程をする人に対して俺が求める金融知識というのは、
修士レベル以上の金融工学や保険数理だ。
現場の人間が知らないことをおまえらが知っていればいいんだ。

現場を知らないと仕事ができないなんて言っているヤツは、
経験でしか物事を考えられない凡人だ。
理論と歴史で物事を考えてから行動しろ。

266 ：仕様書無しさん：2006/03/18(土) 21:26:49

オレも>>263には、あんまり同意できないな。
本来技術屋に求められている部分を軽視しているのが腹立たしい。

267 ：仕様書無しさん：2006/03/18(土) 21:31:58

>>265さん
>俺は銀行員でシステム担当だが、
何処の銀行ですか？
と、釣られてみた。

近寄りたく無い。

268 ：仕様書無しさん：2006/03/18(土) 21:34:44

ユーザさんがSEの「金融工学」の話に耳を傾けるか？
SEってのはユーザさんの話を理解できるだけの業務知識があればいいんじゃない？

269 ：仕様書無しさん：2006/03/18(土) 21:38:51

ユーザより詳しくなってしまうことは割とある。
相手は出世や異動で、いなくなったりするしね。
そうすると、便利だから相手が離してくれないわ
けだが、自分が望んでいない場合には最悪。

270 ：仕様書無しさん：2006/03/18(土) 22:01:34

最近80×25な世界が美しいと思えてきた。

271 ：仕様書無しさん：2006/03/18(土) 22:20:15

>>263
そういう○○能力と△△能力はどちらが大事か？という議論は不毛だから
やめたがいいと思う
あなただって、業務知識も技術知識も持つ人がいる隣りでは、
そんなに熱くは語れないでしょ。いないから嬉々として書き込めてるだけ。

272 ：263：2006/03/19(日) 03:38:16

>>265
現場を知らないお坊ちゃまですね、ホントに銀行のｼｽﾃﾑ担当？
実際に現場では、ＳＥに対して業務知識、業務知識ってうるさいよー、
現実にＭとＵのｼｽﾃﾑ統合が遅れたのはなぜだか知ってる？
業務知識のあるＳＥが集め切れなかったせいだよ。

試験受かったそうでおめでとう、でもね、資格じゃ仕事はできないぞー
ちなみに、誰もユーザー以上の業務知識を見につけろなって言ってませんよ。

>ベンダーで上流行程をする人に対して俺が求める金融知識というのは、
>修士レベル以上の金融工学や保険数理だ。
どこの部門か知りませんが、保険数理をいくら知ってても外為のシステムは
組めませんし、銀行の主業務たる預金・融資システムも組めませんねえ、
まああなたの井戸の中で頑張ってください。

273 ：263：2006/03/19(日) 03:41:05

>>266,271
これは俺の書き方が悪かった、謝る。

俺は別にどちらが大事なんて論議するつもりじゃない、
263での書き込みをよく読んでくれ、
プログラミング能力も大事だが・・・と書いてあるつもりだが。
20年近くこの業界にいると、技術はあっても、特化した業務知識や
コミュニケーション能力が無いために、40近くになっても下流工程しか
任されず惨めな思いをしている連中を嫌というほど見てきた、
実際、40代になると求められるのは技術力ではなく、業務知識なんだよ。

274 ：仕様書無しさん：2006/03/19(日) 13:02:48

業務ＳＥなら、の一言が抜けてる気がするが。

>ちなみに、誰もユーザー以上の業務知識を見につけろなって言ってませんよ。

求められているのは、ユーザー未満の業務知識だろ。
>>265は「その程度の知識なら」一週間も勉強すれば十分だ、と言ってるだけジャマイカ。
この程度の長文ｗの文意を正しく読み取れない香具師にコミュニケーション能力とか
言われてもなあ。

275 ：仕様書無しさん：2006/03/19(日) 23:31:14

>>274
つまりだ、>>263が詰め込まれているユーザー先は、
銀行業務検定試験の２級も通らない連中ばかりだと言うところです。
たしかに、金融工学の話をしても無駄ですね。

>>263
外為なんてのは、保険に比べればずっとパイが小さい分野ですよ。念のため。
銀行が保険に参入したのが最近だから新規案件が多いのですよ。
外為は昔からシステムがあるから大きな案件は少ないのです。

まあ、>>263のような信金や農協に派遣で行くようなレベルの人に業務を知らないと言われても、困っちゃうよね。
たしかに、信金や農協のオヤジなら、「業務知識」と呪文のように唱えそうな感じがしますね。
都銀・信託・外銀などは、「業務知識」などとは連呼しませんよ。

276 ：仕様書無しさん：2006/03/19(日) 23:32:48

>>263の技術はCOBOL技術。
たしかにCOBOLしか知らないのなら、１年もすればそれ以上覚えることは何もない。
だから、技術の奥深さを知らないんだ。

277 ：仕様書無しさん：2006/03/19(日) 23:43:23

ここ見てて某N○Rでの茶番劇のような仕事場を思い出しました。

278 ：仕様書無しさん：2006/03/22(水) 00:04:34

ＴＡＣ基本情報技術者試験　カセット講座一式（ＣＯＢＯＬ）
出品しました。よろしければ参考になさってくださいませ。

ttp://page9.auctions.yahoo.co.jp/jp/auction/k31459907

279 ：仕様書無しさん：2006/03/22(水) 20:20:42

がんばれ、コボル

280 ：仕様書無しさん：2006/03/22(水) 20:46:51

コボルおばちゃま

べーしっ君

281 ：263：2006/03/25(土) 01:27:29

>>275
まーしばらく見ないうちに、ずいぶんな言われ方だが、
すまんが、信金や農協の仕事はしたことが無いね、
都銀の三菱と東京の外為統合や、
みずほの勘定系統合は要件定義から参画してるがね、
多分君は、俺が固めた要件や基本設計の下流工程で頑張ったんだろう。

ちなみに、残念ながら複数の外資系生保で保全系の仕事経験を通して、
算法書はかなり読み込んでますから、
ＰやＳの計算式の概要を作れるぐらいの数理知識はありますよ。

>都銀・信託・外銀などは、「業務知識」などとは連呼しませんよ。
残念、そういうところのほうがうるさい、もっとも君のようなペーペー
には解らないのかも知れない。

ま、都銀や生保から、ＰＭやリーダーの依頼も含めて、
仕事の依頼は山ほど来てるし、もう現場は疲れるから断ってるけど、
会社も儲かってるし。

282 ：仕様書無しさん：2006/03/25(土) 01:42:29

現場で、胡散臭い徒弟制によって培われた「業務知識」とやらが何の役にたつのか。
そういうものを標榜する阿呆に限ってその知識とやらを体系化せん。

ユーザより詳しいから(ryとのたまってみたところで、そいつが優秀である保障は何処にもない。

283 ：仕様書無しさん：2006/03/25(土) 10:10:51

ＣＯＢＯＬはこれからも生き残るでしょ。

これだけ理路整然と書ける言語は他に無い。
まあＣＯＢＯＬベースの簡易言語なんかはあるか。

284 ：仕様書無しさん：2006/03/25(土) 12:24:18

>>281
>都銀の三菱と東京の外為統合や、
>みずほの勘定系統合は要件定義から参画してるがね、

またすぐそういうばれるうそをつく…

285 ：仕様書無しさん：2006/03/25(土) 15:25:43

>>283
>これだけ理路整然と書ける言語は他に無い。
何を持って「理路整然」などというのか...。
古き良きPascalでも使ってろ(pgr

286 ：仕様書無しさん：2006/03/25(土) 17:23:40

いやＣＯＢＯＬを使う

287 ：仕様書無しさん：2006/03/25(土) 17:27:00

10進演算でDB/Fileとやり取りするようなものを書くなら今でもCOBOL最強と思われ。
COBOLの忌み嫌われる原因は、COBOL自体より日本業務系伝統の妙ちくりんな規約にある。

288 ：263：2006/03/26(日) 01:14:02

>>284
本当だよ、三菱と東京の合併では旧東京の青葉台事務センターに２年缶詰状態、
もともと外為専門銀行だった東銀の外為システムを、
三菱が見栄で自分のシステムに乗せようとしたから大変だったよ、
三菱のはマルチカレンシーの対応はカスカスだし、
ペイメントアドバイスは無いも同然だし、
制約だらけで、東銀で当たり前のことができないんだから。

みずほはＤＫＢ側で、内幸町と渋谷と中目黒を行ったり来たりしてた、
ここは主導権争いが大変だったね、
もともとＤＫＢのシステムに一本化する「片寄せ」から、
ころころ変わるんだから。
合併対応の上流工程から入ると、こういうことにも気を使うんだよ。

289 ：仕様書無しさん：2006/03/26(日) 03:04:23

>>288
全て日経コンピュータに書かれてました。
あなたは、日経コンピュータの愛読者ですね。

そんなあなたにお勧めの書籍がありますので、是非ご愛読下さい。
http://www.amazon.co.jp/exec/obidos/ASIN/4062722607/qid=1143309793/

290 ：仕様書無しさん：2006/03/26(日) 11:24:55

俺はPL/IとCOBOLしか実務では使ったことがない。
３０年も前のプログラムを直したりすると宮大工の気分。

291 ：仕様書無しさん：2006/03/26(日) 20:42:56

俺も似たようなもんだが、相手は汎用機のアセンブラ。
宮大工というより、考古学者になった気分だ。

292 ：仕様書無しさん：2006/03/26(日) 22:01:02

３０年も前のCOBOLの命令って、MOVE，COMPUTE，GOTO，PERFORM位しか思い出さないんだけど。
そんなおっさんでも、まだいけるかな。

293 ：仕様書無しさん：2006/03/26(日) 22:29:26

DBはさすがにリレーショナルDBになってるんじゃない？

294 ：仕様書無しさん：2006/03/26(日) 22:31:22

宮崎大学工学部

295 ：仕様書無しさん：2006/03/26(日) 22:37:51

>>292
alterなんてのも・・・

296 ：仕様書無しさん：2006/03/26(日) 22:54:21

>>292
OPEN,CLOSE,READ,WRITEは忘れたの？

297 ：仕様書無しさん：2006/03/27(月) 20:50:25

>>292
本質は何も変わっていない。まだまだ現役だ。

>>293
リレーショナルを使っているところもあるけど、
基幹系はいまだに階層型かネットワーク型が主流。
基幹系を再構築するまでは無くなりません。

298 ：仕様書無しさん：2006/03/27(月) 22:36:42

>>293
COBOLでDB扱うのなら、階層型のほうが扱いやすい。
RDBはコーディングがめんどくせー
擬似更新できないし
ま、検索の自由度はRDBにはかなわないんだけど・・・

299 ：仕様書無しさん：2006/04/08(土) 12:03:28

↑
バカ？

300 ：仕様書無しさん：2006/04/09(日) 19:49:19

>>291
汎用機でアセンブラ使う理由ってわかる？
タイムクリティカルな部分はCで書けば済む話だと思うんだけど
メーカーがコンパイラ作ってくれないとかあるのかな

301 ：仕様書無しさん：2006/04/10(月) 00:17:53

>>300
汎用機用のＣあるでしょ

302 ：仕様書無しさん：2006/04/10(月) 15:40:23

>>302
標準入力がSYSIN（カードイメージ）です。
getchar()すると次の文字を読み込む前に79バイトのスペースを読み飛ばす必要があります。

303 ：仕様書無しさん：2006/04/10(月) 15:41:38

↑
>>301でした。 orz

304 ：仕様書無しさん：2006/04/10(月) 20:53:30

system call とかはどうやるの？

305 ：仕様書無しさん：2006/04/26(水) 00:15:48

>>300
システムマクロを発行する時はアセンブラでないとな。

306 ：fucksianasan：2006/05/15(月) 10:49:58

こんな貴重なスレはあげておくに限る

307 ：仕様書無しさん：2006/05/17(水) 00:40:36

コボラーと軽蔑されても今もコボルのみ。
まだまだがんばるぞー

308 ：仕様書無しさん：2006/05/19(金) 23:52:32

さて、６月の仕事からいままで一切触ったことのないコボルを扱うおれがきましたよ

309 ：仕様書無しさん：2006/06/02(金) 00:22:42

編成ファイルについて教えて(ひきよう編成てなんだ！)

310 ：仕様書無しさん：2006/06/02(金) 10:02:17

>>309
マジレスしてみるテスト。
「ひきよう編成」聞いたことがない。
概念的には、順編成、索引付順編成(←正しくないかも)、区分編成くらい知ってれば
よさそうな気がする。

311 ：仕様書無しさん：2006/06/03(土) 13:17:15

NET COBOLを勉強しようぜ。

312 ：仕様書無しさん：2006/06/03(土) 13:25:12

今になってCOBOLが見直され始めている
複雑化したOOP言語が取っつきにくく理解した者しかメンテ出来ない状況
「最新の思想と技術を満載に詰め込んだ言語」が
「旧世代のシンプルかつ素直な言語」に再び取って代わられる時代も近い

313 ：仕様書無しさん：2006/06/03(土) 13:49:15

卑怯編成

314 ：仕様書無しさん：2006/06/03(土) 15:08:09

こらからCOBOL勉強しようと思うのですが、
http://www.cobol.gr.jp/この中でどれが
一番業務で役立つと思いますか？

315 ：仕様書無しさん：2006/06/03(土) 20:34:44

http://rikunabi-next.yahoo.co.jp/tech/docs/ct_s03600.jsp?p=000599&__m=1149334284053-3977182556549450818

また、COBOL、オブジェクト指向など聞き慣れない用語は、「知的」
という印象を受けるらしく、「かっこいいと思う用語は？」という
質問に対する回答は、すべて難易度の高いものばかりであった。
しかし、彼女たちにとって、「知的」と「ウザイ」は紙一重らしく、
あまり専門用語を多用するのは好ましく思われないようだ。

　ｧ　　∧＿∧　ｧ,､
　,､'` ｡ﾟ( ﾟ^∀^ﾟ)ﾟ｡,､'`
　 '` 　 ( ⊃ ⊂)　　'`

316 ：仕様書無しさん：2006/06/03(土) 21:08:10

COBOLってCﾌﾟﾗﾌﾟﾗとかｼﾞｬﾊﾞｰよりずっとカッコイイね

317 ：仕様書無しさん：2006/06/03(土) 21:19:31

俺の高校の授業COBOL取り入れてたりするが
本当に無駄な気がする
役立つ現場や応用出来る仕事なんて少ないのにほんと無駄
低偏差値高校なのに更に低レベルなことしてる

318 ：仕様書無しさん：2006/06/03(土) 21:27:28

CというのはCOBOLのこと？
それともCOBOL85のこと？

319 ：仕様書無しさん：2006/06/03(土) 21:50:58

>>317
いまだにCOBOLの業務系での利用度はNo1だと思うが・・

320 ：かど：2006/06/03(土) 22:08:33

こぼらーｗ

321 ：仕様書無しさん：2006/06/03(土) 22:10:25

>>319
そうなの？
でも古いイメージしか湧かないしなんか響きもダサい

322 ：仕様書無しさん：2006/06/04(日) 00:21:26

>>317
低偏差値高なら、COBOLがお似合いです。
COBOLを避ければ、いきなりExcelやワードでMOUSコースになってしまいます。

323 ：仕様書無しさん：2006/06/04(日) 07:15:37

>>319
利用されていても、開発は少ないのでは？

324 ：仕様書無しさん：2006/06/04(日) 08:21:05

>>323
案件も多いよ。
大手が数握って専属チームに開発させてるから中小企業やオープン系チームにはあんまり
話が来ないだけで。

325 ：仕様書無しさん：2006/06/04(日) 09:21:04

コボるコボラーこぼれスト

326 ：COBOL初心者：2006/06/06(火) 11:43:57

お願いです！
COBOLの言語＆構造についてまとめてあるサイト教えてください！
特に編成ファイルがよくわからないですOTZ

327 ：仕様書無しさん：2006/06/06(火) 15:20:23

　　　_　_
　　(　ﾟ∀ﾟ)
　　(　 ∩ミ　　ﾃｨﾑﾎﾟ！ﾃｨﾑﾎﾟ！
　　|　ωつ,ﾞ
　　し ⌒Ｊ

328 ：仕様書無しさん：2006/06/06(火) 16:57:26

INDEXファイルのこと？

329 ：COBOL初心者：2006/06/06(火) 19:15:26

索引編成についてです！
COBOLの言語＆構造についてまとめてあるサイト教えてください！

330 ：仕様書無しさん：2006/06/06(火) 19:49:07

おじちゃんも勉強しなおしたいな＾＾
索引順次編成だな

331 ：仕様書無しさん：2006/06/06(火) 19:57:31

あのよー。サイト探す前に本を探せよ。

332 ：COBOL初心者：2006/06/06(火) 20:18:34

確かに本ならたくさん有るけどお金かけたくないので

333 ：仕様書無しさん：2006/06/06(火) 20:25:37

>>329
どんな環境で何を目的(学習?)にしてるのか？
環境によって言語文法は微妙に違うから最終的にはマニュアルしか頼りにならないよ
試しにググってみた結果。中身はチラ見したぐらいなので役にたつかどうかは知らん
331の言う通り、入門向きなら書籍のほうが役に立つと思われ
ttp://www.geocities.jp/shirokaz99/htcobol.html
ttp://hp.vector.co.jp/authors/VA003991/kouza/beginner/kouza_cobol.html
ttp://homepage2.nifty.com/pu-relaxroom/pro/prog.htm
ttp://www.microfocus.co.jp/manuals/NE40/books/bklr.pdf

334 ：仕様書無しさん：2006/06/06(火) 20:31:07

いんでっくすしーけんしゃるふぁいる

335 ：仕様書無しさん：2006/06/06(火) 20:33:00

一番いいのは現に動いているソースを見るこった。

336 ：仕様書無しさん：2006/06/06(火) 20:43:01

現に動かないソースしかありません！

337 ：COBOL初心者：2006/06/06(火) 21:19:09

まだよく見てないがとりあえず>>333㌧クス
目的は学習です！それと入門は逝きすぎです。

338 ：仕様書無しさん：2006/06/06(火) 21:33:19

＞確かに本ならたくさん有るけどお金かけたくないので

おまえはVisual Basicでもやってな。

339 ：仕様書無しさん：2006/06/07(水) 01:24:25

ひよこグミなんかどうですか？
学校の先生に紹介されました

340 ：仕様書無しさん：2006/06/07(水) 20:40:10

ＣＯＢＯＬ言語からのデータ変換作業

バイトの求人に書いてあったんですが、これってどんな事をやるか知ってる人います？

341 ：仕様書無しさん：2006/06/08(木) 00:22:14

新人のころ、隣のシマの人たちが
真っ黒で文字しかない画面にJCL書いたり、
分厚いダンプリストを眺めてる姿を見て
「なんや知らんけど難しそやなぁ」
と思ってた。

ヘルプで半年ほど汎用系に回された時は
それなりに楽しかったけどなぁ。
トランザクション処理で階層型DBをはじめて触ったときは
「おお、これが２種の勉強で出てきたやつか！本物や！すげー！」
と感動した。

どこかのレスにあったけど、マッチング処理とか
いかにネストを避けるか、とかロジックの
組み立て方はその後の他の言語でも役立ったと思う。

今は全然違う分野で外注に仕事依頼するだけで、たまにエクセルのVBAを使うぐらい。
プログラム組まなくなってから楽しくない。転職しよかな。
また一兵卒からスタートするのはキツイかなぁ。

342 ：仕様書無しさん：2006/06/08(木) 00:50:12

マッチング処理というものが、諸悪の根元。
RDBの恩恵に浴していない汎用機連中は、「マッチング」という概念に特別な感情があるようだ。

343 ：仕様書無しさん：2006/06/08(木) 00:52:04

俺はマッチングとかキーブレイクとかに秋田んだがなー、まだこれからも付き合わないといけない orz

344 ：仕様書無しさん：2006/06/08(木) 01:18:42

>>342
汎用機のシステムは扱うデータの規模が違うからね。
副参照ならべたSQLで数十万件のレコード抽出するだけでも
それなりに時間がかかるけど、それじゃあ汎用機の世界じゃ
仕事にならんでしょ。

345 ：仕様書無しさん：2006/06/08(木) 14:09:08

>>340
PIC なんたら VALUE かんたらで
テーブル書いてあるヤツを
他の言語の似たようなモンとか、
バイナリファイルに移植するんじゃねーの？

キーパンチャー

346 ：仕様書無しさん：2006/06/08(木) 20:07:28

RDBはやっぱ遅いのか。

347 ：仕様書無しさん：2006/06/08(木) 23:02:26

>>344
RDBは、普通に１０億件を扱います。
数十万件で悦に入っているようでは、子供のオナニーと一緒だね。

数十万件なんて、MS-Accessでも扱えるよ。

348 ：仕様書無しさん：2006/06/08(木) 23:11:41

今時コボルかｗ
ＪＯＢコントロールカードとか今でも使ってるの？

349 ：仕様書無しさん：2006/06/08(木) 23:38:50

>>344
汎用機のような貧弱な環境では、それ自体が仕事になりません。

350 ：仕様書無しさん：2006/06/08(木) 23:54:58

処理速度はどう考えても汎用機の方が上だろ
Oracle9i（高性能サーバー）と某メーカーの汎用機使ってるけど処理速度は
圧倒的に汎用機が上だよ
Oracle9iなんて子供のオモチャだから新人教育に使われてるｗ

351 ：仕様書無しさん：2006/06/09(金) 10:07:54

汎用機は何で、ORACLE動かしているサーバは何？機種教えて。

352 ：仕様書無しさん：2006/06/09(金) 13:31:44

300万の機種と30万の機種比べたら100倍位早くないと割に合わない

353 ：仕様書無しさん：2006/06/09(金) 13:32:21

煽りコメントで計算間違え

354 ：仕様書無しさん：2006/06/09(金) 17:59:24

大分昔の話

ライブラリの整理をしていたら見慣れないＪＣＬとプログラムを発見。
えらく沢山のファイルを使っている。
社長と喧嘩してやめた奴の作ったものらしい。

ソースを見たら
（1）システム日付をACCEPT
（2）(１)の日付が13日で曜日が金曜日か調べる。
（3) (2)の条件を満足したならば、すべてのマスタファイル（得意先や商品）をOPEN OUTPUTで開きすぐ閉じる
ということをやっていた。

COBOLで作ったウイルスもどき。
どうやって実行させる気でいたんだろうか？

355 ：仕様書無しさん：2006/06/09(金) 22:13:06

>>347
素人

356 ：仕様書無しさん：2006/06/10(土) 10:53:30

COBOLか・・・誰かＥＡＧＬＥ／４ＧＬ使ってる人いない？

357 ：仕様書無しさん：2006/06/12(月) 00:02:24

>>355
時代の進化に取り残された化石

358 ：仕様書無しさん：2006/06/15(木) 21:47:08

>>357

> RDBは、普通に１０億件を扱います。
> 数十万件で悦に入っているようでは、子供のオナニーと一緒だね。

「数十万件程度」という言葉から「悦に入っているよう」という発想をしている。
大規模プロジェクトの経験がないか、学生か、素人。もしくは無能。

359 ：仕様書無しさん：2006/06/16(金) 00:28:13

数十万件っていうとExcelで扱えなくなるあたりだね

360 ：仕様書無しさん：2006/06/16(金) 06:28:58

最近のMTは何ギガぐらい入るの？

361 ：仕様書無しさん：2006/06/16(金) 21:04:22

MTってなあに？

362 ：仕様書無しさん：2006/06/16(金) 21:13:41

もうCLSだろ

363 ：仕様書無しさん：2006/06/16(金) 21:34:26

>358
ちょっぴりﾜﾛﾀ。

確かに返ってくるレコード件数が多くて悦に入る人間を見たことがない。
件数が少なくてホッとする奴や件数が多くてチッと思う奴は居てると思うが。

>357 はむしろ一日数万件のデータ入力ができる優秀なキーパンチャーかも。

>359 エクセルだとたぶん

63000とちょい行 * 255列 * 255シート　と思われ。

364 ：仕様書無しさん：2006/06/17(土) 02:27:35

>>360
MTはサポート切れです

365 ：仕様書無しさん：2006/06/17(土) 12:48:36

いやいや、契約件数とレコード件数は直接的に結びついてるなら、
件数が増える事は喜ばしい事だよ。

件数増加対応に漏れがあってSB37を出してしまったこともあったが…

366 ：仕様書無しさん：2006/06/17(土) 20:37:03

汎用機のCOBOL一筋の上司に
「PCで使えるCOBOLがあるんです」と話したら、
「JCL無いのなら、使い物にならないじゃん」
って言われた。

思いっきり脱力した。

367 ：仕様書無しさん：2006/06/17(土) 21:07:41

>>342
マッチングが諸悪の根元ってどういうこと？

368 ：仕様書無しさん：2006/06/17(土) 21:24:29

>>367
マッチングが全てだと思っているコボラーがRDBを使うと
WHEREを書かずにSELECT * from XXXの結果を全件舐めながら
ループ内の分岐で必要なものだけ取り出したり、
結合すれば済むものを、↑のやり方をネストさせてやったりする。

結果、パフォーマンスは語るに及ばず。
上司コボラー曰く、「やっぱりPCはダメだ。結局は汎用機じゃなきゃ使い物にならん」

馬鹿は氏ね、としか言いようがない。

369 ：仕様書無しさん：2006/06/17(土) 21:59:17

SELECTで読むときって、いったんぜんぶメモリに入れるの？

370 ：仕様書無しさん：2006/06/17(土) 22:05:32

>>368
JOINすれば良い場合にわざわざそんな事やってれば
まあ腹もたつと思う。
要するにその人がSQLを使ったコーディング慣れしてないって事だと
思うけど、マッチング自体は大量バッチ更新などでは必要な場面もある。

371 ：仕様書無しさん：2006/06/17(土) 22:09:07

>>368
そんな奴おらんやろ

372 ：仕様書無しさん：2006/06/17(土) 22:09:20

SQLしか知らん奴に汎用機やらせる方が面白い

373 ：仕様書無しさん：2006/06/17(土) 22:47:46

COBOLをやって、その後にWebの時代になりASP、PHPと使ってきたが、
先日JSP サーブレットを書いてみたら、型がどうだの　ぬるぽだの苦労した。
COBOLのときに、型のデータ例外でJOBが落ちたりしたことを思い出したよ。
PICTURE句だけど、型の指定や領域をきちんととるプログラムは、JAVAなんか
やるときにも感覚的につかみやすい。

374 ：仕様書無しさん：2006/06/18(日) 00:21:07

>>373
そうやってCOBOLで育つと、
ベクトルやリスト、連想配列などのデータ型を全く使わず、
数字と文字列の２種類だけで物事を解決しようと考えるようになってしまいます。

375 ：仕様書無しさん：2006/06/18(日) 04:41:05

で、COBOLについて勉強したいんだが無料で手に入るCOBOL環境ってどのくらいあるよ？

376 ：仕様書無しさん：2006/06/18(日) 08:24:12

>>374
そうそれ。
彼らは可変長の配列やリストや連想配列が使えない。
打算的に最大長を決めて、それでよしとしてしまう悪習がある。

ある日突然客から「エラーが出るようになった」と言われ調べると
SQLのINの中身をループ内でSTRINGで繋いでるプロシージャがあって
扱うデータが増えたせいでSQL文字列変数をオーバーフローしていた、とかざらにある。

>>375
OpenCobolが一番完成度としては高いがそれでもまだ微妙だな。
大体OpenCobolってCOBOL→Cのコードコンバータだから何ちゅーか本中華

377 ：仕様書無しさん：2006/06/18(日) 09:19:29

>>376

> 打算的に最大長を決めて、それでよしとしてしまう悪習がある。

俺のことを言っているのか？

378 ：仕様書無しさん：2006/06/18(日) 09:20:57

>打算的に最大長を決めて、それでよしとしてしまう悪習がある。

ﾃﾍッ

379 ：仕様書無しさん：2006/06/18(日) 09:51:28

>>376
彼らはって・・・
使いたくても環境的に無理なんだから、
やむを得ずに良しとしてるだけじゃん。
データ定義の部分だけでもGenericsが使えると夢が広がりんぐ

380 ：仕様書無しさん：2006/06/18(日) 10:20:37

可変長文字列が扱えないんだから
もう今となっては「汎用言語」とは言えないよな。
10進数演算と定型帳票出力に対するドメイン特化言語に過ぎないよ。

381 ：仕様書無しさん：2006/06/18(日) 10:53:23

文字列の前に4バイト付けて可変長を扱えるようにしたらいいのにね。

382 ：373：2006/06/18(日) 11:19:18

>>374
自分で言うのも何だが、それだけじゃないよ。
DBのテーブルも、恐ろしくフィールド数が多いのを、同じCOBOL出身の作ったので
見かけることが多い。フィールド名も無理やり日本語をローマ字にしたやつ。

正規化なんてロクに教わらないで、順編成ファイルを扱っていた感覚でそのままテーブル作るから。
自分と同じニオイのするソースやDBは、見るとすぐわかるｗ

383 ：仕様書無しさん：2006/06/18(日) 17:08:50

だからCOBOLの文法を覚えてどうするつもりなんだ？
COBOLはその周りのJCLとかDBとかミドルウェアが重要なんだぞ

384 ：仕様書無しさん：2006/06/18(日) 17:56:41

誰のレスに対する発言なのか判らんが、文法を覚えようとしているレベルの人間に
ＪＣＬとか言ったとこで始まらんだろうに。

385 ：仕様書無しさん：2006/06/18(日) 18:38:13

JCLについてなんて勉強しようにも
現場に出なけりゃ何もやりようがないだろうが。

JCLを座学、って、恐らくこの世で最も価値の無い行動の一つだと思う

386 ：仕様書無しさん：2006/06/23(金) 12:31:01

>>342おまえ何も知らないなｗ
そんなものバッチｗ

387 ：仕様書無しさん：2006/07/05(水) 22:07:20

MicroFocusのCOBOLでINSPECTとかSTRINGとかごちょごちょするプログラムを書いていたら

　メ　モ　リ　リ　ー　ク　し　て　O　S　が　死　に　ま　す　た　。

388 ：仕様書無しさん：2006/07/06(木) 20:47:21

>>387
COBOL様の方が正しい

389 ：仕様書無しさん：2006/07/06(木) 21:37:19

>>385
エミュレータ環境作って勉強するという手もある
現場じゃあんまり好き勝手できない面もあるからね

390 ：仕様書無しさん：2006/07/07(金) 18:15:24

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

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

391 ：仕様書無しさん：2006/07/07(金) 18:19:30

環境とか、その部分のコードぐらい書けや、ボケ

392 ：仕様書無しさん：2006/07/07(金) 18:45:28

>>382
そおいや、他所の会社でCOBOLもできる優秀な若手とかいう人がいて、
そこのシステムの手伝いにいったら、DB2のテーブルで金額のカラムを40個も
作っていたｱﾌｫがいたな。そのウチ値が入っているのは５・６個しかないワケだが・・・。

ゆとり教育の弊害かと思ったよ。ｗ

393 ：仕様書無しさん：2006/07/07(金) 19:16:26

>>391
スミマセン、HITACHIのCOBOL85です。
あと、別にコード書かなくてもわかる質問なんですが、、、。

394 ：仕様書無しさん：2006/07/07(金) 19:31:14

わかるんだったら質問すんなよ

395 ：仕様書無しさん：2006/07/07(金) 19:43:48

>>394
はぁ？
質問の意味・回答がわかるってことじゃん？
ニホンゴツウジマスカ？

396 ：仕様書無しさん：2006/07/07(金) 19:48:15

そうですね。

では、次の質問をどうぞ。

397 ：仕様書無しさん：2006/07/07(金) 22:31:09

うちのところのコボラーはテーブル設計させると
どいつもこいつも必ず最後に
char(10)でOPT1～10、char(1)でSIN1～10、char(50)のFILLER
という余計な項目をつけるんだが一体なんのおまじないなんだ？

398 ：仕様書無しさん：2006/07/07(金) 22:39:51

あー、ソレに近いの見るよなぁ。アレなんなんだろう？

ｺﾎﾞﾗｰ以外だとFILLERは１レコードを任意のバイト(128,256,512,1024)に調整するっぽい
イメージで使うけど・・・。

399 ：仕様書無しさん：2006/07/07(金) 22:52:37

以前に順編成のファイルを拡張しまくりで、それがウンザリで最初から予備項目を作っておけば良い！みたいな？ w

400 ：仕様書無しさん：2006/07/07(金) 23:56:47

おじちゃんはアセンブラを勉強しなおすぞｗ
まずは、ＣＡＳＬから
懐かしい

401 ：仕様書無しさん：2006/07/08(土) 00:40:55

>>400
ふつーにx86系アセンブラやZ-OS用アセンブラをやったほうがいいのでは？
実働したほうが楽しいでしょ。

402 ：仕様書無しさん：2006/07/08(土) 00:48:41

>>397
ＤＢＭＳ経由でＳＱＬをつかってデータを取り出すだけなら、レングスあわせの項目は必要ない。
しかし、夜間バッチでＤＢから固定長のファイルをアンロードして処理をするのであれば、あったほうが高速になる。

ＤＢＭＳ経由だけであれば、ただの無駄。

いずれにしても、設計した人に意図を聞いておいたほうがいいとおもう。
必要がないのに、なんとなく追加する奴がいるから、しっかりと詰問しよう。

403 ：390：2006/07/08(土) 02:13:20

結局誰もわからないのですか？

404 ：ネタじゃないことを祈りつつ：2006/07/08(土) 08:17:45

>>390
コード提示しないとわからない可能性大ですね
例えば、WRITE FROM で記述した場合、レコード定義によっては
KI/KO等コントロールコード挿入される場合もあるし。
他にもレコード長云々とか・・・

405 ：仕様書無しさん：2006/07/08(土) 11:50:35

>>401
そうですね＾＾

406 ：仕様書無しさん：2006/07/08(土) 21:57:00

LD STを復習した
懐かしい

407 ：仕様書無しさん：2006/07/11(火) 00:00:41

FILLER項目か・・・ナツカスィ。

>399 >402　を読んでともに「そうそう」って
感じ入ってしまった。

408 ：仕様書無しさん：2006/07/13(木) 14:29:06

オフコンのコボルは古いですかね

まじめな質問です

409 ：仕様書無しさん：2006/07/13(木) 15:20:59

>408
意味が分からん。

COBOLのバージョンを指してるのか？

410 ：仕様書無しさん：2006/07/13(木) 18:42:10

IT関連のﾒﾙﾏｶﾞを見ていたらオフコンの修正の仕事があるな
あれはＣＯＢＯＬだな

411 ：仕様書無しさん：2006/07/13(木) 23:39:35

つい先月までGP6000だったけか、それでCOBOLの仕事をしてたけど、それがどうした？
っつーか、まじCASETなんて糞な言語作りやがった不治痛、死ね。

412 ：仕様書無しさん：2006/07/14(金) 00:30:59

>>411
どんな言語なのか興味がある。
ちょっと短いコードでもいいから、サンプル書いてみてよ。

413 ：仕様書無しさん：2006/07/14(金) 07:05:06

>>412
COBOLの命令を日本語にしたやつ

俺も２，３回触っただけなんでもう忘れてるw うろ覚えでこんな感じ　

例えばmove を　転記　～　とかだったけかな。
if を　
条件～
　成立　～

　不成立　～

条件終了

みたいな。

これのエディタがまた操作が独特っつーか、慣れないとイライラすること間違いなしってやつで。 w

414 ：仕様書無しさん：2006/07/14(金) 07:14:35

COBOLはクソ
COBOLしかやったこと無い上司はクソ

JAVA等を学んできた新人には受け入れられないと思う

415 ：仕様書無しさん：2006/07/14(金) 11:11:20

>>413
YPSじゃないのか？

416 ：仕様書無しさん：2006/07/14(金) 22:52:28

>>414
お前は俺か？
上司に報告するときはメソッドをサブルーチンと置き換えセッションを
CTSエリアとか意訳しないと通じない。

417 ：ぴん：2006/07/15(土) 05:35:40

ＣｏＢＯＬ　の仕事有ります　飛びバス　稼げ・・・す。

418 ：ぴん：2006/07/15(土) 05:38:32

ＣｏＢＯＬ　の仕事有ります　飛びバス　稼げ・・・す。

419 ：仕様書無しさん：2006/07/15(土) 10:21:34

今Windowsサーバ上のWebアプリをCOBOLで新規開発してるのは
日本でウチの会社くらいじゃなかろうか…orz

しかも自由記法禁止。ホストとのソース互換性を持たせるためらしい。
Windowsサーバからホストにマイグレーションなんてシチュエーション
今後未来永劫発生しえねえよ…

420 ：仕様書無しさん：2006/07/15(土) 10:37:11

>>419
PC世界の仮想化技術が発達するとそうとも居えない

421 ：仕様書無しさん：2006/07/15(土) 23:16:30

>>419
どうやってCOBOLでWebアプリ動かすの？

422 ：仕様書無しさん：2006/07/15(土) 23:34:24

AS/400なら出来なくも無いだろうけどWindowsでやる辺りに漢を
感じるなぁ。

つか、今後「このプログラムはあそこの業者しかメンテできない」って
規制事実を作りたいだけな気もするが…。

423 ：仕様書無しさん：2006/07/16(日) 01:19:47

>>421
某F社のWindows用COBOLはASP.NETのコードビハインドのコードに使える

424 ：仕様書無しさん：2006/07/16(日) 18:51:34

>>420
PC上で汎用機エミュ動かしてそこにわざわざWindowsで動いていたモノを持って行くってこと？
ありえねーよそれは。

だいたいおまい、仮想化技術ってなんだか分かってないだろｗ

425 ：仕様書無しさん：2006/07/16(日) 20:24:51

>>424
なんで汎用機エミュなんだよ
チャネルと言うかHTブリッジでチャネル増やしてx86ベースの汎用機を作るんだよ
で、仮想マシンの一つでクライアントのWindowsも動かす
IBMとかSun辺りが目指してる仕組みだ

426 ：仕様書無しさん：2006/07/17(月) 01:03:34

>>425
x86ベースの汎用機と仮想化技術の関係が見えませんが。

427 ：仕様書無しさん：2006/07/17(月) 06:31:59

ちょっと話横道にそれるけど、質問。
近年の汎用機ってエミュみたいな構成なの?
複数のRICS CPUを使用してる構成ってどんなものなのか素朴な疑問。

428 ：仕様書無しさん：2006/07/17(月) 07:16:03

IBMのでOS/400とlinuxとかAIXとかを仮想というか
１台のマシン上に共存してHTなんちゃらで通信したり、
CPUを適宜割り振ったり(OSにCPUx１、DBMSにCPUx2、LINUXにCPUx1)
と出来なくもないらしぃが、漏れはそんな広告よろしくな構成している
お客にはあった事がない（ｗ

漏れもそんな鯖管理したくねぇ。

429 ：仕様書無しさん：2006/07/17(月) 14:10:56

>>427
超大きい方はまだエミュじゃないけど小さめの方はエミュですね。
CPUに汎用機用の命令を追加しちゃってる感じ。
OSの一部（割り込み処理とか）は書き換えているようです。

430 ：仕様書無しさん：2006/08/19(土) 02:53:51

COBOLage

431 ：仕様書無しさん：2006/08/27(日) 23:29:08

よく2chでCOBOLERを馬鹿にする発言を見かけますが
○○という言語を使っているから技術力が低いと決め付ける事は無い。
古い言語であるCOBOLは枯れた言語であり、何よりも「安定」して動くシステムが多い。
安定して動くシステムってのは　コンピュータ業界にとってかなり重要。
だから多くのCOBOLERがいろんな業界にいる。
でも、
「それってCOBOLERが自分の身を守るために」
「ふるい技術から離れない自分を正当化するために」
「COBOLしか使わないのはCOBOLERが出世して選択肢にCOBOL以外選ばないから」
「COBOLはそもそもプログラミング言語ではない」
「COBOL＝帳票出力専用言語と言っても間違いない」
そんな意見を若い技術者から良く聞きます。

技術者たるもの言語がどうだからと偏見を持つのはよくない。

そして先月から初めてCOBOLERとお仕事。

若い技術者の言う通りでした。
ってか　COBOLERの脳内はひど過ぎる…(全員じゃないけどね)

432 ：仕様書無しさん：2006/08/27(日) 23:35:17

まぁCOBOLで扱えるアルゴリズムなんてたかが知れてるもんね。

433 ：仕様書無しさん：2006/08/31(木) 18:17:23

COBOLを使いこなす技術者は凄いと思うがいわゆるコボラーは凄くない
COBOL全盛期に凄い奴はすでにCOBOLからは離れている

434 ：仕様書無しさん：2006/08/31(木) 19:00:13

COBOLERだからどうというより、自分の地位が脅かされるから
新しい技術を排除しようとする人たちがいるのが問題。

435 ：仕様書無しさん：2006/08/31(木) 19:26:12

>>434
超絶同意！

436 ：仕様書無しさん：2006/08/31(木) 22:29:55

>>431
COBOLERの脳内についてくあしく

437 ：仕様書無しさん：2006/09/01(金) 07:29:36

むやみやたらに新技術を啓蒙するワケでもないが、
COBOL以外の言語が選択できる状況(Java,SQLとか）
で未だにコボルで組まれても、正直迷惑だよなー。

いい加減、藻前がこっちに合わせろよ。と小一時間…

438 ：仕様書無しさん：2006/09/02(土) 02:57:13

437とか本気で思ってる？

汎用機しか知らない奴が率いるオープン系のプロジェクトは悲惨だぞ。

毎回毎回スタンダードエラーの説明が必要なんだ。

分からないなら黙ってろよと毎回思うぞ。
でも本人は優秀なつもりだから手に負えん。

439 ：仕様書無しさん：2006/09/02(土) 03:39:34

>>438
Javaの例外は多すぎると思う訳ですよ

その点汎用機の例外はシンプルでいい

440 ：仕様書無しさん：2006/09/02(土) 08:15:46

>汎用機しか知らない奴が率いるオープン系

それはこの時点でデスマ決定なノリが…。

処理系にもよるがSQLだと２・３文で仕様書作成～単体テスト終了まで１日で
終わるような簡単なロジックでも、COBOLとかで２・３日（下手すりゃ一週間）も
かけてタラタラと仕事されて、優秀なつもりなのは困ったちゃんだと思う。

で、まあそういう人は残業してるから「仕事頑張ってる」と勘違いされて
定時でサクサクあがる漏れは「ナニしてんのアイツ？」と勘ぐれる
謎スパイラル（ｗ

441 ：仕様書無しさん：2006/09/02(土) 11:09:29

>>440
>で、まあそういう人は残業してるから「仕事頑張ってる」と勘違いされて
>定時でサクサクあがる漏れは「ナニしてんのアイツ？」と勘ぐれる
>謎スパイラル（ｗ

超ありがちパターンだなあ

442 ：441：2006/09/02(土) 11:11:46

途中で送っちまった

んで，人増やすっつって新人とか入ると
残業多いところに割り当てられてそこで悪い知識ばかり詰め込まれて
腐れ人材増殖。

これもスパイラル。

443 ：仕様書無しさん：2006/09/02(土) 12:36:37

今って学校でもまだCOBOL教えてるらしいけど。

そおいや、学生時代にCOBOLで大会でどーたらと聞かされたが、
実際は人のいう事聞かないDQNだったなぁ。

学生時代に覚えた事が社会で役にたたんのはCOBOLにかぎらず
一緒だけど、妙な自信を実力も実績も無いうちに身につけんなよ、
と思ったな。

まあ、社会に出てからデスマーチの戦歴を自慢されても困るけどな。

444 ：仕様書無しさん：2006/09/02(土) 15:07:00

客先のビルに、今や使われなくなったオフコンが転がってるんだよ。

それが欲しくたまらないんだが、俺って変態だろうか？

445 ：仕様書無しさん：2006/09/02(土) 17:11:29

>>444
１００人に聞いたら、９９人がこう答えます。
「変態です」

残りの１人はお前のことな。

446 ：仕様書無しさん：2006/09/02(土) 19:52:59

アンティークなインテリアとしてはいいかも

447 ：仕様書無しさん：2006/09/02(土) 19:56:17

>>444
ウンコ喰いたがる奴と一緒

448 ：仕様書無しさん：2006/09/02(土) 23:34:23

>>447
じゃあ、おれも一緒だ。

449 ：仕様書無しさん：2006/09/03(日) 11:08:52

>>441-442
COBOL開発とは関係ないが、9割がた今の俺の環境と同じ。
俺は７年目でこんな職場環境は初めてだが、個人の７年程度の経験じゃ
無数にある職場環境の実態はつかめんか。

これが、この業界の平均的な姿なのか？

450 ：仕様書無しさん：2006/09/03(日) 16:12:14

>>449
多分「OJT」って言ってるところは全てそうだろ

451 ：仕様書無しさん：2006/09/03(日) 19:25:45

>>449
なんつーか、経歴の長さは関係ない場合もあるよ。
まあ、２・３年ではあまりデカイ口は叩かない方がいいと思うけど、
バカはいつまでたってもバカなので、この道１０年なSEやPMが
いようが学習能力のない奴は毎回デスマしてる。

でまあ、そういう「デスマが普通」と諦めている連中は
なんでデスマになるか原因を分析する事をしないんだよな。
で>>442の人が言うように悪い知識や常識を身につけて
思考停止してる奴が「前からこうだから」「昔からこうだから」と
いってCOBOLﾏﾝｾｰとか…。

452 ：仕様書無しさん：2006/09/03(日) 21:26:44

PL/Iしか使えない俺が来ました

453 ：仕様書無しさん：2006/09/04(月) 00:14:37

貴重な人材です。

454 ：仕様書無しさん：2006/09/04(月) 00:36:46

>>453
マジで貴重。

大手金融機関では引く手あまただよ。

455 ：仕様書無しさん：2006/09/04(月) 06:31:11

引く手あまたかもしれないが、結末は奴隷なんだよな。（ｗ

456 ：仕様書無しさん：2006/09/13(水) 23:37:11

ボコルなんて技術じゃねー
こんなのやっていたら、脳味噌が腐ってウジ虫がわくってもんよ　

457 ：仕様書無しさん：2006/09/13(水) 23:38:41

DATA DIVISION
さえ書けりゃ、いっちょあがりーーーーー！

458 ：仕様書無しさん：2006/09/13(水) 23:55:02

余り頭使わなくていいし、まったりですよ

459 ：仕様書無しさん：2006/09/14(木) 14:38:14

COBOLなんて、金融と保険業界しか、主に使わないよ。
これまた、保険業界が　変な思想があってきついけどね。・・・・

460 ：仕様書無しさん：2006/09/14(木) 16:12:51

COBOLやって身に付く事ってキーパンチの強さくらいじゃね？
COBOL世代のｵｻｰﾝのエンターキーを叩く強さは異常

461 ：仕様書無しさん：2006/09/14(木) 18:16:44

そんなに強いか？
せいぜいタイプライター打つのと同じ程度だろ。

462 ：仕様書無しさん：2006/09/14(木) 20:30:33

前の仕事で見かけたオッサンは小指で押さないで中指で叩くに押すのが印象的だったなぁ。
すげー音してた。しかもブランインドタッチしてないし。
COBOLってバッチでは処理速度でいまだに優位にあると聞くがどうなの？
バッチで負けたら確実に引退だろうけど。

463 ：仕様書無しさん：2006/09/14(木) 23:30:00

>>462
そりゃＳＱＬに比べたらな

ただ工数は五倍位？
正直、メリットないよ

464 ：仕様書無しさん：2006/09/14(木) 23:52:09

>>462
COBOLのバッチが速いというのは、都市伝説だ。

COBOLだから速いのではなく、
それが稼働している環境（メインフレーム）のI/O速度が速いだけだ。

465 ：仕様書無しさん：2006/09/15(金) 00:05:54

古い言語だからコンパイラの最適化処理は結構出来る部類だろうけど
結局メインフレームっていうバッチ専用の環境が一番効いてるわな。

466 ：仕様書無しさん：2006/09/15(金) 00:33:31

ついでに言うと、メインフレームが速いのはI/O速度のみ。
しかし、EMCなどのストレージがオープン系でも一般的になったため、
メインフレームの唯一の優位な点は、チャネルが高負荷に強いだけ。

ちなみにメインフレームのCPUは、とても遅い。

467 ：仕様書無しさん：2006/09/15(金) 00:59:15

ウチの上司、言語と言えばN88とMASMしか知らない・・・・
Java使いをメモリ無駄喰いの無能扱いだもんな_|￣|○

468 ：仕様書無しさん：2006/09/15(金) 03:20:13

実際そのとおりじゃないか。

469 ：仕様書無しさん：2006/09/15(金) 14:36:28

>>466
だけ、ってそれがいちばん重要なんだが

470 ：仕様書無しさん：2006/09/15(金) 19:46:43

>>463 >>464
俺が今関ってる新規開発プロジェクト（かなり大規模の国家プロジェクト）でもバッチはCOBOLなんだよね。
メインフレームは使ってなくてサーバはAIX。それでもバッチは全部COBOL。
俺はJavaでWebの方の開発しかしてないんだけど、バッチはなんでCOBOLなんだかずっと不思議に思ってる。
人件費の高そうなオッサン集めてやってるなーって遠目に見てるだけ。

個人的にはCOBOLはコーディングが面倒で好きじゃないなぁ。
eclipseに慣れすぎたせいか右クリックで宣言を開くができないからだるい。
やれといわれればやるけど。
.NETに興味があるんだが案件がないから勉強する気ならないや。

471 ：仕様書無しさん：2006/09/15(金) 19:55:24

無駄遣いの宝庫たる国家プロジェクトなんだからそのくらい当然だろ

472 ：仕様書無しさん：2006/09/15(金) 19:58:13

失業対策だろ？

473 ：仕様書無しさん：2006/09/15(金) 21:20:10

30年以上も前からつぎはぎで使われているCOBOLのソースを
まるっきり新しい言語でリプレース出来る？

474 ：仕様書無しさん：2006/09/15(金) 22:42:08

>>473
出来る

475 ：仕様書無しさん：2006/09/18(月) 20:21:07

要件から定義しなおせば余裕だろ
そもそもその機能を人間が必要なのかそれが一番大事

476 ：仕様書無しさん：2006/09/24(日) 01:05:48

要件を定義出来る人間はもはや居ない。

477 ：仕様書無しさん：2006/09/24(日) 15:58:55

はい、ソースから仕様を起こしといてね。
つCobolスパゲッティ

478 ：仕様書無しさん：2006/09/24(日) 16:14:56

COBOL.NETさえあれば、無敵だ。

479 ：仕様書無しさん：2006/09/24(日) 20:44:54

おまいらに聞くけど、COBOLの案件でいくらぐらい？

480 ：仕様書無しさん：2006/09/25(月) 22:29:34

富士通のやつ.NET対応してるじゃん

481 ：仕様書無しさん：2006/09/25(月) 23:58:45

>>479
1人月50万

482 ：仕様書無しさん：2006/09/26(火) 00:24:40

>>481
やっぱりそんなもんだよな
元請は5000万だの8000万だの挙句の果てには20億だの。。。。
所詮部分請負じゃたいした額にはならないよなぁ。。。

483 ：仕様書無しさん：2006/09/26(火) 22:20:22

COBOL.NETは植物人間に延命措置してるようなもんだよなー
アコギな商売だ。

484 ：仕様書無しさん：2006/09/27(水) 00:10:07

そもそも商売になるんかね
ホストで動いてるのってコアな部分は全部アセンブラじゃん

しょぼいバッチオンリな案件なら使えるのかもしれんけど、
それだったら最初から作り直した方が絶対に良いし

485 ：仕様書無しさん：2006/09/27(水) 21:59:31

>>それだったら最初から作り直した方が絶対に良いし
この提案が通じないからこそコボラー。

486 ：仕様書無しさん：2006/10/01(日) 18:45:04

これあおりとかネタとかじゃなくてマジなんだけど
コボルのプログラマーって高校の偏差値が４８ぐらいのやつでもできる？
知り合いに一次方程式もとけないやつがいて
そいつプログラマーらしいんだけど
あんなに頭悪いのにできるもんなのかな？って不思議なんだよね。

487 ：仕様書無しさん：2006/10/01(日) 20:17:26

偏差値測ったこと無いからわからんが
プログラマという職種なら誰でもできる
コボルにかぎらずな

488 ：仕様書無しさん：2006/10/01(日) 21:15:46

SEが超初心者向けの仕様書作ってくれる会社のプログラマーだったら
小学生や中学生でも出来るだろ。

489 ：仕様書無しさん：2006/10/01(日) 21:32:10

そゆことｗ
なんたってここは何回ループさせてくださいまで書いてある仕様書なんだぜ？ｗ
できないほうがおかしいんだｗ

490 ：仕様書無しさん：2006/10/01(日) 22:49:08

COBOLerとかホスト関係の古代言語のプログラマーってそこら辺まで書かないと
怒るんだよな。
でプログラムがバグっているとSEの仕様書が悪いとか言い出すし。
そりゃまあ、そうかも知れないけど…。

漏れの前いた職場では変数名や長さ、ラベルまで指定されていて、
ロジックもフローチャート付きで懇切丁寧に書かされたな。

ある意味COBOLを扱う様な大企業(?)はこういった
習慣が残っているだろうから、誰でもプログラマは出来る。

491 ：仕様書無しさん：2006/10/01(日) 23:25:19

>>490
そうなのか？
うちは逆だな
そんなことまで書かなくていいからとか言われちゃうな

492 ：仕様書無しさん：2006/10/01(日) 23:50:34

漏れ、VBとoracleの技術者だけど、あさってからCOBOLの仕事です。ちょっと、不安です。

493 ：仕様書無しさん：2006/10/02(月) 00:06:47

安心しろ。ただ書き回しが面倒なだけで大して変わらんよ

494 ：490：2006/10/02(月) 00:27:07

>>491
ｳﾗﾔﾏｼｽ

漏れは漏れが作るPGMの仕様書（ファイル出力設計書とか）だと
「KEY:処理年月で○○ファイルをEOFまで読み、フィールド○○の平算をA.○○にセット」
とか書くのだけど、コレだと「他人が理解できん」とか言われるので、
プログラムの構造化部分まで設計して納品してるよ。(T_T;

自分の書くロジックが常に最高とも思っていないから、ここら辺は
プログラマの技量に任せたいんだが。

495 ：仕様書無しさん：2006/10/02(月) 00:30:55

そこまで極端なのか。。。

496 ：490：2006/10/02(月) 00:49:46

そういう意味もあって最近やっているJava+SQLはSE的に天国に思える。（ｗ

Eclipes関連だとdocも作りやすいし、SQL文だとくだらねぇ構造化な
解説も必要ないし…。
最近のだと人間が色気だしてコーティングに凝っても
SQLのオプティマイザの方が勝つし。

なんにせよ、プログラマはあんまし頭の出来云々は関係ないと思う。

497 ：仕様書無しさん：2006/10/02(月) 00:55:55

そうだよなｗ
所詮事務所内の土方だ
いや。。。土方のほうがましかもな。。。
土方は多人数でひとつずつ仕事をこなしていくが
PGは一人で割り振られた仕事をこなさないといけないから
誰も助けちゃくれないんだよな。。。
たとえ人より多くこなせる能力があっても
結局その分仕事が回ってきて残業だ。。。
がんばれ日本のプログラマｗ

498 ：仕様書無しさん：2006/10/02(月) 20:04:15

何だかリアルCOBOLerが紛れ込んでるなｗ

499 ：仕様書無しさん：2006/10/02(月) 23:38:42

いよいよ、明日から、COBOLです。
不安ですが、このスレ読んでちょっと勇気がでました。
また、報告、いいですか？

500 ：仕様書無しさん：2006/10/02(月) 23:44:49

>>498
リアルだが何か？ｗ
>>499
女性なら大歓迎です

501 ：仕様書無しさん：2006/10/02(月) 23:46:15

５０前のオッサンでは？

502 ：仕様書無しさん：2006/10/03(火) 00:17:02

スレ、もう一度、読みすた。
VB、Oracleの漏れでもできる様に重いますた。
今日からCOBOLの仕事です。
最初はメンテナンスですが、がんばります。

503 ：仕様書無しさん：2006/10/03(火) 00:41:51

常識のある人なら大丈夫です

504 ：仕様書無しさん：2006/10/03(火) 00:43:58

ありがとう。
勇気でます。

505 ：仕様書無しさん：2006/10/03(火) 20:03:36

だが良心と責任感は捨てろ。
効率化への欲求もな。

506 ：仕様書無しさん：2006/10/03(火) 22:34:51

>>494
とある生保のシステムの仕様書がそんな感じだった。
実際はもっと細かかった。
何も考えずに、仕様書どおりにつくり納品。
不具合があれば、設計側のミスとなる。
結合フェーズの後で何度も改変された仕様書が送られてくる。
まさに考えることを放棄させられたコーディングマンと化する。

507 ：490：2006/10/03(火) 23:32:08

そおいえば、そういう仕様書を作って外注さんに出したら
コンパイルも通らないソースを納品された事があったなぁ。
半分くらい（ｗ

あっちの人間は思考停止してるだろうなぁ、とは思ったがまさか
コンパイルも通らないのを納品してくるとは、そのクセ偽造テスト結果を
出す脳はあるんだ。と妙に感心しました。

結局、ＰＧＭは自分で作り直して、二度とそこに仕事を出さなくなりましたが。

508 ：仕様書無しさん：2006/10/03(火) 23:50:26

1からMAXの値の(MAXはACCEPT文で入力)全ての素数を求める
プログラムをCOBOLで作ってるんですが、PERFORMの使い方が
ヘボイのか、結果が2が表示されるだけで終わってしまいます。

　諸先輩方はどのようにコーディングされますか？
参考にさせていただきたいです。

509 ：仕様書無しさん：2006/10/04(水) 00:25:39

PERFORMの使い方云々以前の様な希ガス。

510 ：仕様書無しさん：2006/10/04(水) 00:26:51

>>508
ソース見せて。
久しぶりにCOBOLのソースが見たくなった。

511 ：仕様書無しさん：2006/10/04(水) 00:27:22

>>508
PERFORM VARYING A FROM 2 BY 1
UNTIL A > MAX
MOVE 1 TO WK
PERFORM VARYING B FROM 2 BY 1
UNTIL B > A OR
WK = ZERO
MOVE FUNCTION REM(A B) TO WK
IF WK = ZERO
DISPLAY A UPON CONS
END-IF
END-PERFORM
END-PERFORM.
適当に書いてみた
間違ってたらすまん

512 ：仕様書無しさん：2006/10/04(水) 00:28:13

ぬお。。。。スペースが全部消えとる。。。

513 ：508：2006/10/04(水) 00:31:35

>>510
ごめんなさい、ソースは今なくてですね、明日の夜に
載せます。

>>511
ありがとうございます、参考にさせていただきます。

514 ：仕様書無しさん：2006/10/04(水) 00:34:39

>>512
一文字目の半角スペース
二つ連続した半角スペース
これらは削除されるよ

515 ：仕様書無しさん：2006/10/04(水) 00:36:17

>>514
きっちり8カラム数えてやったのに。。。
さてエロゲ作業に戻る

516 ：仕様書無しさん：2006/10/04(水) 01:36:41

>>507
もうなんだ、あれだ、COBOLで仕様書書けばいいんじゃネーの？

517 ：508：2006/10/04(水) 19:50:04

すみませんー。メールでソース添付して送るの忘れて
しまいました。ですが、ヒントを教えていただいたので
ちゃんと実行できました。ありがとうございます。

明日の夜に再度載せますので。

518 ：仕様書無しさん：2006/10/04(水) 22:52:21

喫煙者の呼気（息）は環境汚染基準を超えているので、毎日吸い込んでいると非常に危険です。
会社で喫煙者の向かい側や両隣に座ってる人は、喫煙者の呼気（息）を毎日吸い込むことになるので非常に危険です。
学校の先生が喫煙者の場合は、前の方に座ってる子供も非常に危険です。

519 ：仕様書無しさん：2006/10/04(水) 23:07:32

>>516
ＣＯＢＯＬのソースやCOPY句から仕様書を作るツールなら作ったことが、、、

520 ：508：2006/10/06(金) 01:20:18

遅くなりました、こんな感じで完成しました。
ただ縦に表示されるので、レコードに格納させて
1行に20件ずつ表示させる形に変更しています。
なぜか素数が表示された残りの項目にNULLが出ますが・・・

PROCEDURE DIVISION.
001100 MAIN SECTION.
001200 DISPLAY 'MAXヲ9(5)デKEYINシテクダサイ' UPON CONSOLE.
001300 ACCEPT MAX FROM CONSOLE.
001400 PERFORM VARYING SOSU FROM 2 BY 1 UNTIL SOSU > MAX - 1
001401 MOVE 1 TO AMARI
001403 PERFORM VARYING KEISAN FROM 2 BY 1 UNTIL
001405 KEISAN > SOSU OR AMARI = ZERO
001406 DIVIDE KEISAN INTO SOSU GIVING SYO REMAINDER AMARI
001410 IF KEISAN >= SOSU
001420 THEN
001510 DISPLAY SOSU UPON SYSOUT
001520 ELSE
001521 CONTINUE
001530 END-IF
001540 END-PERFORM
001630 END-PERFORM.
001800 STOP RUN.

521 ：仕様書無しさん：2006/10/06(金) 05:25:10

俺ならこんな感じかなぁ。環境はOpenCOBOL。
PROCEDURE DIVISION.
MAIN SECTION.
DISPLAY "MAX ｦ 9(5) ﾃﾞ KEY-IN ｼﾃｸﾀﾞｻｲ"
ACCEPT MAX
DISPLAY "00002"
PERFORM VARYING SOSU FROM 3 BY 2 UNTIL SOSU > MAX

MOVE 1 TO AMARI
PERFORM VARYING HOU FROM 3 BY 2
UNTIL HOU * HOU > SOSU OR AMARI = 0

DIVIDE SOSU BY HOU GIVING SYO REMAINDER AMARI

END-PERFORM
IF AMARI > 0 THEN

DISPLAY SOSU

END-IF

END-PERFORM
STOP RUN.

522 ：仕様書無しさん：2006/10/06(金) 08:25:08

MOVE SPACEしたら

523 ：508：2006/10/07(土) 12:43:21

>>522
　はい！レコードにあらかじめMOVE SPACEしたら出来ました。
ありがとうございます。

524 ：508：2006/10/09(月) 16:50:17

みなさんどうもありがとうございました。更に改良を加えてみて、
素数プログラムを印刷してみようと思うのですが、行カウンタをまわす
IF文を何処に配置するかで悩んでいます。ソースはこんな感じです。

525 ：508：2006/10/09(月) 16:51:50

005201 　IF LINE-CTR = 30
005202 THEN
005203 MOVE SPACE TO REC-OUT
005204 WRITE REC-OUT AFTER ADVANCING PAGE
005205 COMPUTE PAGE-CTR = PAGE-CTR + 1
005206 MOVE PAGE-CTR TO PAGE-SUU-OG
005207 MOVE MIDASHI-GYO TO REC-OUT
005208 WRITE REC-OUT AFTER ADVANCING 3 LINES
005209 MOVE 0 TO LINE-CTR
005210 ELSE
005211 CONTINUE
005212 END-IF

526 ：仕様書無しさん：2006/10/11(水) 16:15:51

>>524
何を悩んでいるのかよくわからんが、出力編集処理は別ルーチンに分けるのが
マとしては当たり前ではあるまいか。

527 ：仕様書無しさん：2006/10/11(水) 19:34:49

>>525
・LINE-CTR の初期値を 30 にする
・素数の印字処理の直前にその IF 全体を入れる
・素数の印字処理と同じブロックに ADD 1 TO LINE-CTR

528 ：デフォルトの名無しさん：2006/10/11(水) 23:50:57

>>526
>>527
おっしゃる通りサブルーチン化して完成しました！
今までPCインストラクターで最近COBOLを勉強しています。

529 ：仕様書無しさん：2006/10/11(水) 23:58:16

…ギャグ？

530 ：仕様書無しさん：2006/10/12(木) 09:37:59

うん。

531 ：仕様書無しさん：2006/10/12(木) 20:00:01

それ聞いて安心。

532 ：仕様書無しさん：2006/10/13(金) 01:47:50

ごめん、話ぶった切っちまうけどふと思ったんだ
大学の文系学部を卒業して、プログラマとして採用された人ってどのくらいいるのかな？
俺の周囲では結構多くて、そいつらホントに完全無欠な素人なんだ

まぁズブの素人にとってはCOBOLは覚えやすいからいい言語なのかもしれないけど……
しかもそいつら、若手のCOBOLerは少ないからこれから重宝されるだろう的な考えを持ってるんだよね

んなわけねえよ、と笑ってやりたいが、もしかしたらホントにそうなるかもと思ってちょっと嫉妬

533 ：仕様書無しさん：2006/10/13(金) 03:13:40

>>532
心配するな。将来は本当にジリ貧だからよ。

本人の実力とはあまり関係なく、
会社の営業力によってのみ生き残れるかどうかが決するのが、
近未来のCOBOLerの特徴。

534 ：仕様書無しさん：2006/10/13(金) 06:43:31

>>532
人の将来はそれぞれだと思うが、大学卒業してなぜにプログラマとかを
目指すのかよーわからんが。

そして重宝されたければCOBOLなんてメジャーで使う人の多い言語では
なくRPGとか覚えろよ。

ただ>>533が言うように本人の実力関係ない世界だし、
技術者間では「あいつあんな簡単な修正に何日かけてんだよ、ﾂｶｴﾈｰ」
と将来的に暗いのは覚悟しておけ。

535 ：仕様書無しさん：2006/10/13(金) 21:19:27

そういう奴らはせいぜいエンジニアの離職率や精神疾患者数とかを引き上げるのが関の山よｗ

536 ：仕様書無しさん：2006/10/13(金) 22:06:00

>>532
経済学部卒で営業の仕事していて、システム管理部希望したらそれが通り、そこでCOBOL+汎用機という
仕事をしていた人間がいたとさ。俺のことだが。

537 ：デフォルトの名無しさん：2006/10/14(土) 00:00:40

会社は東証一部で安定しているのですが、そこの情報システム
部門に配属になりCOBOLをやらされてます。
この会社にずっと居るなら現状でよいのでしょうか？

538 ：仕様書無しさん：2006/10/14(土) 00:17:41

富○通ならやばいなｗ

539 ：仕様書無しさん：2006/10/14(土) 00:29:40

>>537
安定してるなら、何でもいいよ。
この業界は階層型なので、中小IT企業に所属していたら、
短期スパンで常に多重派遣されるので、なんでもかんでもやらにゃあ
ならん。いくら頑張っても、その企業で定年を迎えることなくこの業界を去ることになる。

階層の頂点にある企業にいるのなら、それだけでよい。自分が多重派遣されることなど
ない。

能力・技術のありなし、できる言語など二の次の話題だ。

540 ：デフォルトの名無しさん：2006/10/15(日) 15:00:31

OCCURS句で作成した項目にDIVIDEで割ること出きるんでしょうか？

01 S-DATA
02 REC OCCURS 1200 TIMES
03 KAKIKOMI PIC 9(5)

DIVIDE KAKIKOMI(S) INTO ATAI GIVING SYO REMAINDER AMARI

541 ：仕様書無しさん：2006/10/17(火) 01:31:09

>>539
ただし、その企業内での派閥争いに敗れたり、企業そのものが身売りすると、
そらもう、どうしようもない将来しか残っていない。

俺様の半生を振り返ってみると、

２３歳、某地方国立大学を卒業し、東証一部上場企業へ就職し、情シスへ配属。
３５歳、情シスの課長として脂がのっている時期、同業他社と合併（事実上吸収された）
３６歳、システム移行終了後、営業部門へ転勤　→　いびられる　→　ノイローゼ　→　鬱病　→　長期休養
３７歳、退職　→　鬱病が直る。
３８歳、流通業のシステム担当として再就職。年収は半分程度になるが、それなりに充実。
４０歳、勤務先の医薬品スーパーが大手流通に身売り。またもやシステム統合作業後に退職
４２歳、現在、日用品問屋で事務員のかたわらシステムも担当。システム担当といっても勘定奉行のメンテ。

現在４４歳、私生活はそれなりに充実・・・・・。

俺の人生で失敗したとすれば、一部上場企業のCOBOLerとして満足し、自己研鑽を怠ったことだ。

542 ：仕様書無しさん：2006/10/17(火) 02:27:12

吸収される側のシステム要員は、全員クビという典型的な話ですね。

営業部門なら、ある程度は生き残ることも出来ますし、
吸収された側の人でも、ある程度の出世は望めます。

システム部門の場合、システム移行さえ終われば全員ゴミです。
新システムでも力を発揮してくれなんて激励されますが、あれはウソです。

543 ：仕様書無しさん：2006/10/18(水) 20:04:17

質問。
みなさんＶＢはどれくらいわかりますか？

544 ：仕様書無しさん：2006/10/18(水) 21:06:24

>>541
文型理系？専攻学部学科を教えて

545 ：541：2006/10/22(日) 23:35:34

>>544
文系です。

我考える故に我有り。　文学部哲学科卒業です。

546 ：仕様書無しさん：2006/10/24(火) 01:05:41

哲学科なら弁証法を学ぶべきだったな。生きる知恵にあふれてる

547 ：仕様書無しさん：2006/10/31(火) 01:32:08

相当上の方にも似たような意見があるけども、
代入、演算のたびにMOVE,COMPUTEでは邪魔くさくてしょうがない。

MOVE A TO B　は
B = A

COMPUTE A = B + C　は
A = B + C

と記述できるようにならんものか。
何をするにも命令語ありきがCOBOLの統一化された美意識といえばそれまでだけども。
ただ、MOVE,COMPUTEで代入方向が左→右、左←右と異なるのは気持悪い。

548 ：仕様書無しさん：2006/10/31(火) 02:28:10

>547
元々代入形式の書き方は FORTRAN 由来っしょ。
FORTRAN のそもそもの目的は数式を扱うこと。
当時はアセンブリで数式処理してたわけだから画期的だぁね。

COBOL は「英文的に読める言語」として作られたから
その目的からすると相容れないだろうなぁ。
逆に COBOL では COMPUTE こそが例外かと。

実際、COMPUTE 無しでも計算が出来るようになってる。
ただ代入式に慣れた人の為に一応
数式を処理命令のCOMPUTE を入れたんだろ。

549 ：仕様書無しさん：2006/10/31(火) 22:24:31

COMPUTE 禁止の環境で仕事したことあるよ。
その後、他のソース読んだときに邪道！と感じた。

550 ：仕様書無しさん：2006/10/31(火) 23:22:17

COBOLを使って曜日計算をフローで作らないといけないのですが
なにがなんだかorz

今月のカレンダーを使って○日と入れたら○曜日と返ってくるものを作りたいのですが
初心者の私には難しいです…。

先輩方教えていただけないでしょうか？

551 ：仕様書無しさん：2006/10/31(火) 23:51:10

ググれ

552 ：仕様書無しさん：2006/10/31(火) 23:56:16

会社のサブルーチンじゃ年月日いれれば
それの曜日と祝日判定してくれるから
今月のカレンダーという感覚が分からんな
今月のカレンダーはどうやって準備するんだい？
単純に7で割って余りに差分を足せば（0を日曜日として）
曜日判定できないか？

553 ：仕様書無しさん：2006/11/01(水) 23:25:57

YMD系の関数なり、下位モジュールなりは、ありとあらゆる言語、環境で用意されつくされている。
不定期に変動のある休日、祝日だけ、別途テーブルを用意する必要はあるだろうが、
わざわざフローから作るなど、物好きも甚だしい。無駄なことはやめなさい。

554 ：仕様書無しさん：2006/11/02(木) 00:35:34

学生なんだろうからしかたないでしょ

555 ：_____：2006/11/03(金) 10:37:37

COBOLって15年前のコードが現役で使われているって本当？
知人が「コードの署名が今の部長の名前だったのびっくりした」って言ってた

556 ：仕様書無しさん：2006/11/03(金) 10:47:02

>>555
ひっそりと、かつ堂々とバッチで動いている w

557 ：仕様書無しさん：2006/11/03(金) 11:36:40

>>COMPUTE A = B + C　は
ADDをつかえ

558 ：仕様書無しさん：2006/11/03(金) 13:54:17

>555
本当だろうな。
ウチでもパッと見だけで 94年なんてザラだから
探せば 91年も見付かると思う

559 ：558：2006/11/03(金) 13:59:11

因みに94って一覧の上での最終更新日な。
中身の作成日付は見てない。

560 ：デフォルトの名無しさん：2006/11/03(金) 14:41:06

うちなんて86年とかあるよ。いつまで稼動するんだかw

561 ：仕様書無しさん：2006/11/03(金) 15:16:22

24歳なんだけど、作成日付が俺が生まれる前だったっていうソースがゴロゴロある…

562 ：仕様書無しさん：2006/11/03(金) 16:20:56

COBOLの無料コンパイラ＆エディタはありますか？

563 ：仕様書無しさん：2006/11/03(金) 19:41:00

>>562
COBOLを動かす
ttp://www.geocities.co.jp/SiliconValley-Cupertino/9416/obenkyo_01/howtoruncobol.html

564 ：仕様書無しさん：2006/11/04(土) 00:03:08

ム板かマ板のCOBOLスレにcygwinのOpenCOBOL入れた経過を嬉々とカキコしてた奴が居たな

565 ：仕様書無しさん：2006/11/04(土) 00:29:21

コーディング規約の標準化のドキュメントの日付が昭和47年だった。
紙ベースでボロボロだった。
動物のイラストがところどころに描かれていた。

566 ：仕様書無しさん：2006/11/04(土) 00:36:00

>564
俺俺。
http://pc8.2ch.net/test/read.cgi/tech/1146475958/60-62

567 ：仕様書無しさん：2006/11/04(土) 08:01:57

おっとそうだった
俺は転職してもうCOBOLとは縁が切れたんだった
逃走するぜ

568 ：仕様書無しさん：2006/11/04(土) 08:35:42

>>563
ありがとう

>>566
OK.とりあえずコピペしといた。乙thx

569 ：仕様書無しさん：2006/11/07(火) 03:25:44

>>561
俺が前居たとこにもそんなのが結構あったな。しかも大半がスパゲッティ化した状態で。
一度修正の必要があってドキュメント探したら、キングファイルで3冊とかになっててびびったｗ

570 ：仕様書無しさん：2006/11/07(火) 10:03:25

おまいらJCLはどうしてる？
IBM系なら少しはわかるが、NEC系は糞。
だいたい、どこでJCLを学習するんだ？

571 ：仕様書無しさん：2006/11/07(火) 11:07:45

先輩からの口伝か現地のソースじゃね？

572 ：仕様書無しさん：2006/11/07(火) 23:45:39

お仕事でCOBOLいじる事になったー
「ANSI74でお願いします」って

INITIALIZE使わせてください…

573 ：仕様書無しさん：2006/11/09(木) 00:52:52

>>570
NEC系のＪＣＬも覚えられないお前が糞

574 ：仕様書無しさん：2006/11/09(木) 22:20:53

おれの経験から言わせてもらうとJCLは慣れ。考え込んで指が止まるようなものではない。
DOSコマンド並べでbatファイル作るのと大差ない。
慣れ、慣れ。

575 ：デフォルトの名無しさん：2006/11/11(土) 16:52:40

現在、汎用機がある会社に転職して、社内システムサポートのかたわら
COBOLプログラミングをやってますが、いまいち考え込んでウツに
なります。何か気持ちの切り替えで良い方法はありますか？

576 ：仕様書無しさん：2006/11/11(土) 23:10:55

>>575
2ちゃんでグチる

577 ：仕様書無しさん：2006/11/11(土) 23:13:05

>>575
別の言語を勉強しながら2ちゃんでグチる。

578 ：仕様書無しさん：2006/11/12(日) 01:10:38

>>575
とっとと回線切って屋上から飛び降りろ

579 ：仕様書無しさん：2006/11/12(日) 22:27:01

>>575
文部科学省、ではなくて厚生労働省に自殺する手紙を出して無視される。

580 ：仕様書無しさん：2006/11/15(水) 12:18:04

Pythonのメーリングリストにコボラが投稿してきた。
案の定叩かれてた。

---抜粋
PythonのMLでCOBOLの用語を羅列されても判りません。
> ＥＢＣＤＩＣのＣＯＭＰ－６からＡＳＣＩＩへという変換ではなく
・・・なんのための「ではなく」なのかが不明です。

> ＵＮＩＸ上のＣＯＢＯＬで作られたレコードをＦＴＰのＡＳＣＩＩ
> モードでＵＮＩＸ側からWindowsのＰＣへ転送したあと、
そもそもレコードというやつのバイナリフォーマットがわからないので、
FTPのASCIIモード転送でデータが破壊されないのかわかりません。

> パック項目をゾーン型へ変換したいのです。
パック項目もゾーン型もわかりません。プログラミング一般用語では
ないですよね？

> レコードは以下の通りです。ＣＯＢＯＬ風ですが。
> field01 pic 9(1).　　　　区分
> field02 pic 9(6) comp-6.　キー
> field03 pic X(20).　　　　名称
> field04 filler x(6)　　　　空白
PythonのMLでCOBOL風にフォーマットを説明されてもわかりません。

581 ：仕様書無しさん：2006/11/15(水) 17:06:42

COMP-6 ってトコロ見て思ったんだが
そいつ、ねらーなんじゃね？

582 ：仕様書無しさん：2006/11/16(木) 00:25:10

少なくともパックとゾーンはプログラミング一般用語だと思うのだが。。。

583 ：仕様書無しさん：2006/11/16(木) 01:34:53

>>582
コボラにしか通じんよ

584 ：仕様書無しさん：2006/11/16(木) 05:50:16

コボルはしらんが、パックとゾーンは常識だろ。

つか、その辺の用語が通じないのにプログラマ名乗られてもなぁ。

585 ：仕様書無しさん：2006/11/16(木) 06:44:27

パックとゾーンは常識かどうかは微妙だけど、基礎みたいなモンだろ。

586 ：仕様書無しさん：2006/11/16(木) 22:06:16

ゾーンは損やで

587 ：仕様書無しさん：2006/11/17(金) 12:21:01

パックでもゾーンでもいいけど、バイナリで送るならそのままだろうし、ASCIIに変えたら文字表現になってるな

この場合ってフォーマット指定がCOBOL形式で提示したことが問題でなく、
・COMP-6をそのまま文字表現と見てEBCDICからASCIIへやって壊れた
・COMP-6を文字表現に変えて、ASCIIへ変えて壊れた
・バイナリのまま送ってCOMP-6の変換を間違えた
が解らないって事でPythonの問題かどうかが怪しいね

パックもゾーンも解りませんって以外のPython厨の回答も痛いけどなｗ

588 ：仕様書無しさん：2006/11/20(月) 02:29:06

ゾーン、パックは、COBOL,PL/I,メインフレームASSEMBLERの利用者にとっては
基礎中の基礎だが、それ以外の人にとって本当に常識？　でも情報処理試験
第２種と呼ばれていた時代には試験にも出ていたので、上記の言語の利用者
でなくても、30～40代の人には机上の常識かもなあ。
あとCOBOLer同士諸君、他言語の人や若い人と話すときは用語には気をつけよう。
・ゾーン -> ゾーン10進
・パック -> パック10進
☆若い人にはゾーン10進やパック10進を知らない人が多い。このため、
　慣用表現のゾーンやパックという言葉を使われたら、データ型である
　ことさえわからない。10進をつけても知らない人は知らないが、
　データ型の１種としては理解してもらえるようだ。
・文を指すCOPY句 -> COPY文
・ファイルを指すCOPY句 -> （厳密には登録集原文ファイルだが絶対わからないので）COPYファイル or COPYライブラリファイル

589 ：仕様書無しさん：2006/11/20(月) 06:23:08

レコード長が理解できない若者ＰＧは勘弁！
上記の言葉を理解しても使えないとなぁ～。
ＣＯＢＯＬ＋ＶＢ、ＶＣで生きていけるぞ。（使えるなら）

590 ：仕様書無しさん：2006/11/20(月) 06:45:18

別にDB2でも生きてるが。

591 ：仕様書無しさん：2006/11/20(月) 17:33:02

DB2（笑）

592 ：仕様書無しさん：2006/11/20(月) 20:35:22

>>588
さすがに今の大学生でも情報基礎でゾーンとパックは習う。
2進数と10進数とか、そういうホントのごく初歩の段階で。
たまに用語がパック・アンパックだったりするけど。

593 ：仕様書無しさん：2006/11/20(月) 20:37:48

データベースを扱う人間だと基礎だと思うが。
ホストを連携して処理をするとここら辺は気を使わないといけないし。

のワリにはOracleではゾーンは死んでるんだよな。

594 ：仕様書無しさん：2006/11/20(月) 22:34:55

パックやゾーンだなんて、そんな１バイトを節約するようなプログラミングは過去の遺物だよ。

ファイルに書き出すのは人が読めるテキスト、
DBに書き出すならそれぞれにネイティブな形式もあるし、
エクスポートするならテキストでエクスポートもできる。

メモリ上ではパックもゾーンもﾑﾀﾞﾑﾀﾞ。
素直に全ビットフルに使うか浮動小数点つかうか。

丸め誤差だ？　そんなものライブラリに任せておけ。

595 ：仕様書無しさん：2006/11/20(月) 22:45:28

>>594
藻前は金融機関でメインフレームとOracleを連携させる仕事してみれ。
いろんな意味で泣けてくる。（ｗ

悪いが漏れはそんな理想郷は見たことがない。

596 ：仕様書無しさん：2006/11/21(火) 00:34:47

流星人間

597 ：仕様書無しさん：2006/11/21(火) 00:35:35

>>595
どんなレベルでの連携を言っているのかわからんが、
Oracleとメインフレームの連携はやってます。

Oracleのインポートは、標準でCOMP-3 EBCDICを扱うことができるから、
数字だけのレコードなら、何も考えることは無いと言えば言い過ぎだが、
改行さえちゃんと考慮してやれば結構簡単にできてしまう。

漢字の場合は確かに泣けてくるが、JIS78、JIS83、JISX 2028がどうとか、
あまり気にしなくても社内用と割り切れば、あまり問題は無いよ。

でも、うちの会社は予算が潤沢なので、去年から PowerCenter 使っています。

598 ：仕様書無しさん：2006/11/21(火) 01:20:20

>>596
特ヲタＰＧﾊｹｰﾝ！

っておいらも特ヲタｗ。

599 ：仕様書無しさん：2006/11/21(火) 14:00:48

>>596
そんなゴジラが出てくる番組なんか知らん。

600 ：598：2006/11/21(火) 21:00:14

>>599
知ってるやんｗ

601 ：595：2006/11/21(火) 22:54:25

>>597
漏れのところはホストから改行なしのS-JIS+ﾊﾟｯｸ十進数のストリームデータを
叩き送られたよ…。
ウチのDB2はEBCDICですが、ナニをどうしろと…。

そしてお約束でオリジナル外字交じりの日本語ありなワケで、
それで例によってテーブルのカラムが100～300近くあるワケだが…。

まあ、英数字だけのデータなら改行されなくてもなんとかならなくもないが
それに日本語攻撃＋鬼カラムのテーブルで数GBのやりとりだと
死ねるモノがある。

602 ：デフォルトの名無しさん：2006/11/29(水) 06:46:41

レコードをGET ANYしている間に、同じコードを使って
別のレコードをGETするのに何か良い方法がありますか？

2つめのレコード読むときに思いっきりABENDしました・・・

603 ：デフォルトの名無しさん：2006/11/29(水) 23:52:16

キーをセットしたらうまくいきました、ありがとうございます。
ただ、DB EXPECTIONって13が空ですよね？

604 ：仕様書無しさん：2006/11/30(木) 07:24:01

VSAMでいうとこのKey Invalidにあたるやつじゃなかったっけか？

昔の事なんで記憶のかなたなんだが w

605 ：仕様書無しさん：2006/12/05(火) 20:27:50

うちの会社じゃUNTILは使ってはダメで、GO TOのみでループを実現させねばならない
非構造化のアルゴリズムやコーディングに慣れてしまうと
変な癖ついてしまいそうなんだが、このまま続けてても大丈夫かな？

606 ：仕様書無しさん：2006/12/05(火) 20:39:59

>>605
>うちの会社じゃUNTILは使ってはダメで、GO TOのみでループを実現させねばならない
ソース読みにくくて死にそうですね。失礼ですが、どういう分野でしょう。

607 ：仕様書無しさん：2006/12/05(火) 21:11:10

宮大工が、仕事が早くなるからと言ってチェンソーつかっちゃならん、っつことか・・・

608 ：仕様書無しさん：2006/12/05(火) 23:37:07

うちの会社はPERFORMが禁止なのだが
（全てGO TOで対応）

609 ：仕様書無しさん：2006/12/06(水) 01:45:45

うちはセクション抜けるときかアベンドするときに使うな

610 ：仕様書無しさん：2006/12/06(水) 10:37:59

ラストコボラーががんばっているが
TPCareでSEが殺され続けているうちを助けてくれ
マジで人材募集中

611 ：仕様書無しさん：2006/12/06(水) 13:11:51

☆社会の寄生虫、派遣会社をぶっ壊せ！やつらは背広を着た８９３だ！

私は今ここに要求する！派遣法を改善・改正せよ！
サラ金真っ青の３０％、４０％超の暴利を搾取し労働者から毟り取る。

　派遣会社の搾取率を１０％未満に規制しろ！
　派遣会社の搾取率を１０％未満に規制しろ！
　派遣会社の搾取率を１０％未満に規制しろ！
　派遣会社の搾取率を１０％未満に規制しろ！
　派遣会社の搾取率を１０％未満に規制しろ！
　派遣会社の搾取率を１０％未満に規制しろ！
　派遣会社の搾取率を１０％未満に規制しろ！
　派遣会社の搾取率を１０％未満に規制しろ！
　派遣会社の搾取率を１０％未満に規制しろ！

ついでに薄利で中小の乱立する派遣会社に消えてもらって
　派遣は大規模派遣会社のみが薄利多売でやる商売にしろ。
そうすれば労働者の手取りも増えてニートやフリーターも減るだろう。

【漫画DB】第0弾フリーザ様に学ぶ派遣会社搾取問題
http://www2.ranobe.com/test/src/up16740.jpg
【漫画DB】第1弾フリーザ様に学ぶフリーター問題
http://www.ranobe.com/up/src/up154312.jpg 　
【漫画DB】第2弾　セルゲームに学ぶ「再チャレンジ支援税制」
http://up2.viploader.net/pic/src/viploader364144.jpg
【漫画DB】第3弾　孫一家に学ぶ「就職氷河期」問題
http://up2.viploader.net/pic/src/viploader364686.jpg
【漫画DB】おまけ　これが30過ぎた男の月収なのか
http://2sen.dip.jp:81/cgi-bin/up/source/up2976.jpg

612 ：仕様書無しさん：2006/12/06(水) 15:05:57

>608
PERFORMが二重の意味を持つコボルで
それはあんまりだ…

613 ：仕様書無しさん：2006/12/07(木) 00:22:12

>うちの会社はPERFORMが禁止なのだが

釣りか？ PERFORM THRU は駄目ってとこはあるけど

614 ：デフォルトの名無しさん：2006/12/07(木) 20:52:02

COBOLは簡単ですと良く耳にするのですが、実際にそうなんですか？

615 ：仕様書無しさん：2006/12/07(木) 20:58:20

ソースを書くのは簡単だよ。。
ただ、人が書いたソースはやっぱり読みづらい

616 ：仕様書無しさん：2006/12/07(木) 21:00:57

>>614
簡単なのはいいのだけど、敷居が低すぎて糞プログラムを量産しやすい傾向があると思う。

617 ：仕様書無しさん：2006/12/07(木) 21:51:42

あと、糞プログラマが淘汰されない。
そんでもって、その糞が後輩を育成するわけで、糞の再生産スパイラル。

負のスパイラルを断ち切るには、全員クビにする以外に方法はない。

618 ：仕様書無しさん：2006/12/08(金) 05:52:43

>>616-617
ごめんなさい…orz

619 ：仕様書無しさん：2006/12/08(金) 09:42:14

>>616
仕様が残っていない、バグだらけ、作りかけ、退職済み
大手から転職した地元企業、ではこれら全部をおしつけられる
ＤＱＮプログラマまがいは死んでいいよ

620 ：仕様書無しさん：2006/12/08(金) 11:33:45

良スレage

621 ：仕様書無しさん：2006/12/08(金) 21:10:47

ageられて釣られるが良スレか？

622 ：仕様書無しさん：2006/12/09(土) 01:28:48

COBOLはともかく、汎用系のJCLが覚えにくいです。
テストコードガンガン書いていけばそのうち慣れるでしょうか？

623 ：仕様書無しさん：2006/12/09(土) 02:01:45

慣れるはず。。。。

624 ：仕様書無しさん：2006/12/09(土) 02:48:06

マニュアルが読めるなら、いろいろ遊んでおけ。
DOSのバッチファイルやUNIXのシェルスクリプトが書けるなら何とかなるだろ。
あと、転がっているJCLを読みこなしてみるのも吉。

625 ：仕様書無しさん：2006/12/09(土) 23:33:18

>>624
UNIXのシェルスクリプトは奥が深いが、
DOSのバッチファイルと同列に考えている時点で、お前の将来はない。

626 ：仕様書無しさん：2006/12/10(日) 06:30:26

>>622
JCLはガンガン書いて覚えるものではなく、似たJCLを探して自分用に変更かけていけば自然と覚えると思う。
JCLで間違えていると、人のファイルをぶっ壊したり、最悪、本番ＤＢを壊したりするので、わからないまま走らせない事。
当たり前だが。
シェルスクリプトとJCLは似てるようで全く別物だが、シェルを理解できるようならJCLもわかるだろ、という意味なら同意。
JCLはガチガチのコマンドラインの固まりで、シェルのような自由度は無い。

627 ：仕様書無しさん：2006/12/10(日) 09:36:42

・DOSのバッチファイル
・UNIXのシェルスクリプト
・メインフレームのJCL

一見すると似てるようでも
それぞれの役割や機能は全然違うぞ。

628 ：仕様書無しさん：2006/12/10(日) 10:26:47

>>627
> 一見すると似てるようでも
> それぞれの役割や機能は全然違うぞ。

そんなことは分かってるよ。
違いを認識しながらどう応用していくかだろ。

629 ：仕様書無しさん：2006/12/10(日) 14:24:33

>>628
別に違いを認識する必要すらないんじゃない？
だって、役割や機能は全然違うことはド頭から分かってるし
>>627　の記述内容が空気みたいなものなだけでしょう。

作ったモジュールをキックするという共通した雰囲気があるから
どれかが普通に組めるなら、他も組めるやろ、という精神的な後押しと
捕らえていればいいでしょう。

>>625　のようにUNIXのシェルは奥が深い、と鼻息を荒げるのもいかがなものか。

630 ：仕様書無しさん：2006/12/10(日) 16:44:39

この場合カタプロもJCLに入れていいんだよね？
じゃそんなに遜色ないような気がしないでもない。

631 ：仕様書無しさん：2006/12/10(日) 17:06:49

>>625
DOSのバッチファイルも奥が深いし、
JCLの奥も深いぞ。メーカーもよく分かってない仕様とかあるしｗ

632 ：仕様書無しさん：2006/12/10(日) 18:41:50

UNIXの基本的なコマンドとシェルだけで

httpサーバを書いたヤツもいるし、
ファイルシステムを書いたヤツもいるし、
メールサーバを書いたヤツもいるし、
スパムフィルタを書いたヤツもいる。

もちろん実用的ではないが、教材・実験的な試み・あるいはジョークとして作られたものだ。

DOSのバッチファイルで forコマンド使って奥が深いとか言わないでよ。
WindowsならWSHがあるから、さっさと移行したほうがいいと思うぞ。

633 ：仕様書無しさん：2006/12/10(日) 19:24:22

>>632
もう、いいからあんたは
>ttp://pc8.2ch.net/test/read.cgi/prog/1165152602/
こっち行ったほうがいいんじゃない？

634 ：仕様書無しさん：2006/12/10(日) 20:18:30

さすがにDOSのソレはUNIXに比べれば奥が浅いのは事実だと思う。

WinでもVBスクリプトとかいうのも奥が深いと言われればそうかも知れんが。

635 ：仕様書無しさん：2006/12/10(日) 20:33:10

このスレでDOSといったらVSEとかあのへんじゃ･･･ないのか。

636 ：仕様書無しさん：2006/12/10(日) 23:56:26

バッチファイルが貧弱なものだから、マイクロソフトはWSHを推奨している。
たしかに、VBSでスクリプトが書けるし、COMオブジェクトも使い放題。

UNIXのshでは、シェルがネイティブにオブジェクトを扱えないので、WSHの方が先進的だというのは事実だ。
しかし、Windowsでしか使えないうえに、オブジェクトも豊富ではない。
さらに、基本コマンドがこれまた使えねぇ。

基本コマンドからして、標準出力と標準エラー出力の使い分けを間違ってるんだから、もうどうしようもない。
これじゃ、バカの再生産で、資産の蓄積など望みようもない。

637 ：仕様書無しさん：2006/12/10(日) 23:57:40

よく考えてみると、ここはCOBOLスレだった。
すまんすまん。
おまえらには理解不能だから、俺様はどこか別のスレに逝ってくるよ。

638 ：仕様書無しさん：2006/12/11(月) 00:20:22

最近のMSはPowerShellなんてのも出したけどな
標準装備にする予定は無さそうだが

…俺もスレ違いだな
要素5000の配列が入ったレコードにMOVEされて分割してもらってくるわ

639 ：仕様書無しさん：2006/12/11(月) 02:02:29

VistaからはWSHも非推奨になりますた。

640 ：仕様書無しさん：2006/12/11(月) 22:24:24

>>637
子供やなぁ。もう。

641 ：仕様書無しさん：2006/12/12(火) 02:27:17

COBOLﾗﾌﾞ(*´Д｀)ﾊｧﾊｧ

最近perlだけ使ってるから、たまにCOBOL使いたくなる25歳

642 ：仕様書無しさん：2006/12/12(火) 03:57:17

>>641　変態ぃｗｗ

643 ：仕様書無しさん：2006/12/14(木) 01:15:51

COBOLって正規表現使える？

644 ：仕様書無しさん：2006/12/14(木) 23:07:34

そんなもんあらへん。一行ずつなめて、レコードのカラム位置の
値で判断するねん。

645 ：仕様書無しさん：2006/12/16(土) 23:11:51

>>643
やろうと思えば可能だけど、COBOLしか扱えないような人がそんな環境を整えることは不可能。
そんな努力をするなら、素直にCOBOLを捨てろ。

646 ：仕様書無しさん：2006/12/16(土) 23:54:29

Del好きVB房だけど今度転職先でCOBOLすることになりました。
30からCOBOL初体験！ﾎﾟｯ

647 ：仕様書無しさん：2006/12/17(日) 01:06:35

>>646
安心しろ。誰にでも出来る簡単な仕事だ。

648 ：仕様書無しさん：2006/12/17(日) 01:10:45

渋谷女子高生に直撃☆COBOLの意味わかりますか？／Ｔｅｃｈ総研
http://rikunabi-next.yahoo.co.jp/tech/docs/ct_s03600.jsp?p=000599

これ絶対知ってるやつが書いたネタだろｗ
ボケがちゃんとCOBOLと関係あるじゃないか・・・ｗ

649 ：仕様書無しさん：2006/12/17(日) 18:23:24

>>647
と思ってたら、646が、２０年以上前に開発されたGO TO文だらけのメンテ不可能なプログラム満杯のシステムの改造をまかされて、沈没する予感。

650 ：仕様書無しさん：2006/12/17(日) 19:01:45

全くのプログラミング初心者なんですけど、
「らくらく突破COBOL」で勉強すれば一通りの知識は身につきますか？

651 ：仕様書無しさん：2006/12/17(日) 21:33:24

十分

652 ：仕様書無しさん：2006/12/17(日) 22:49:09

>>649
マジで？
全力でオープン系へ移行させるつもりなんだけど。

653 ：仕様書無しさん：2006/12/17(日) 22:51:51

>>650
情報処理試験対策以外で、真面目にCOBOLを語る書籍はないのか？

COBOL中級者向きの本とか、COBOL上級者向きの本とか、はたまたCOBOLウィザード向きの本とか。

654 ：仕様書無しさん：2006/12/17(日) 23:10:21

>649

オレ、今、３１歳で、担当しているシステムを数年見ています。
GO TO だらけのオンラインです。もう生まれて２０年位たつと思います。

改造するときはいくら調べても自信が持てないですね。どこから飛んでくるのか、
確信がいくら調べても持てません。

でも、GO TO を否定はしません。サブルーチンを一気に抜ける　VBの
Exit Sub のような予約語が有れば使うことは少なくなると思いますが、
ないから、場合によっては可読性を高めるために敢えて使いますしね。

655 ：仕様書無しさん：2006/12/17(日) 23:25:31

最近、若いCOBOL技術者少なくて困ってる所が多いね。

656 ：仕様書無しさん：2006/12/17(日) 23:28:49

ぱーって読んだんだけど、俺新人でコボルの案件にいかされてるんだけど、
PGMの修正で
変数の代入先を２行変更しただけで、資料やら、ハードコピーやら、PGMのソースやらを
２０枚くらい（印刷すると）書かされたんだけど、これって普通なの？なんか読んでたら不安になってきたｗ

657 ：仕様書無しさん：2006/12/18(月) 00:32:07

>>654
オンラインは特にGO TOが多くなるよね。
COBOLはオンラインプログラムに向いていないと思う。
帳票を１００万単位で出力するようなバッチ処理の場合は、帳票の文字制御の易しさと、ホストの高速レーザープリンタを使える点でCOBOL向きだが。
それでも、COBOLでもクラスがあれば、オブジェクト指向化されてりゃもう少し楽なのになあ、と思う。
変数や処理が全く隠蔽化されていない為、全て読まないと安全性を確認できない。

658 ：仕様書無しさん：2006/12/18(月) 19:57:41

>>653
細島一司さんが書いたCOBOL本がええんじゃないかな？
沖電気でCOBOLコンパイラ作ってたみたいで技術力は高いみたい。

659 ：仕様書無しさん：2006/12/18(月) 21:13:38

>>658
情報ありがトン。
買ってみるよ。

660 ：仕様書無しさん：2006/12/19(火) 02:39:28

>>656
普通です。
私が昨日提出したＩＦ文の条件を１行追加しただけのプログラムの報告資料は約２００ページ
になりました。
複雑な気持ちです。

661 ：仕様書無しさん：2006/12/20(水) 00:00:03

俺はヤミ改修します。

ソースの日付を変更して、
オブジェクトコードの日付をバイナリで書き換えて、
ログを抹消するのは、
オペレータにポテトチップを差し入れることにより可能になります。

662 ：仕様書無しさん：2006/12/20(水) 00:41:41

僕の場合は、過去に書いた報告資料の日付を変えて提出します。
新たに書くのは最初の１枚だけで、あとの５０枚ほどは日付以外は手を加えません。
どうせ、誰も内容なんて読んでません。

663 ：仕様書無しさん：2006/12/20(水) 01:06:25

>>661は、金がかかるが楽でまぁまぁ安全な処理

>>662が、手間は多少かかり、安全性に若干の問題がある処理

どちらも熟練のプロの技だ

664 ：仕様書無しさん：2006/12/20(水) 01:26:49

報告書類にそんな枚数かかるってなに書いてるの？

修正前後ソース
テスト結果ログ
テストデータダンプ
とか全部紙に出してやってるとか？

665 ：仕様書無しさん：2006/12/20(水) 05:40:00

一刻も早く違う言語も覚えなさい

666 ：仕様書無しさん：2006/12/20(水) 08:14:24

オブジェクトは忘れろ。
あんなものは害悪にしかならん。

667 ：仕様書無しさん：2006/12/20(水) 22:45:23

>>664
そう。アホ臭いけどマジ面倒くさい。

668 ：仕様書無しさん：2006/12/21(木) 15:16:48

遠い昔、cobolのプログラマーしてた。
最初のコンパイラーはend-ifも使えなかったため、苦労した。
私の作ったプログラムはもう使われてないだろな。オフコンだったし。
メインフレームの仕事ができなかったのが、心残り。

669 ：仕様書無しさん：2006/12/23(土) 17:42:39

いくら互換性があるとはいえ

ＦＡＣＯＭ→ＡＣＯＳ4　への移植は大変だった

670 ：仕様書無しさん：2006/12/23(土) 19:33:59

>>俺はヤミ改修します。
>>ソースの日付を変更して、
>>オブジェクトコードの日付をバイナリで書き換えて、
>>ログを抹消するのは、
>>オペレータにポテトチップを差し入れることにより可能になります。
ホストなら全部、お前の届かないところにログとられてるよ

671 ：仕様書無しさん：2006/12/23(土) 22:54:35

>>670
ログをとったところで、どうということはない。リアルタイムでチェックなど誰もしない。
何か問題が表面化されたときにはじめてログをあさる。

ログをとること自体が何かしらの不正の防止にはならない。

672 ：仕様書無しさん：2006/12/24(日) 05:01:48

本番移行してから、ありゃバグを見つけたけど顧客に知られたくないって時、皆どうしてるのかな。
661みたいなヤミ改修できる環境、オペレータと取引できるとかってのは特殊でしょ。
普通は顧客に正直に報告して、予想通り罵倒されまくったあげく、徹夜か休日出勤して影響調査の後、改修、本番移行するはめになるのだが。
オープン系でも同じなのかな。

673 ：仕様書無しさん：2006/12/24(日) 06:43:14

顧客にそのバグがいつ見つかるかにかけて、黙って放置。

ばれなきゃイカサマじゃない、って教えてくれたなぁ、先輩が。

674 ：仕様書無しさん：2006/12/27(水) 20:39:41

>>672
別の軽いバグの修正と一緒にやってしまう。
仕様変更を称して一緒にやってしまう場合もある。
たぶん、MSでも同じ事をやっているに違いない。

675 ：仕様書無しさん：2006/12/27(水) 22:28:23

で、より一層悪化すると

676 ：仕様書無しさん：2006/12/27(水) 23:43:47

>>672
オープン系はそのへんがいいかげんだと思う。

677 ：仕様書無しさん：2006/12/29(金) 23:45:18

オープン系だと構ってられなくて放置ってのもある
その後は>>674とか

678 ：仕様書無しさん：2007/01/05(金) 22:01:16

「客の教育」をすればいいだけだ

679 ：仕様書無しさん：2007/01/06(土) 00:55:42

>>672
他の案件で一緒に直した
工数も貰えた

680 ：仕様書無しさん：2007/01/06(土) 01:36:38

オープン系のCOBOLといえば
日●医師会がやってる診療会計システムのプロジェクトがあるけど
いろんな意味で非難囂々だった。
痛いコボラーの見本市みたいだったって。

681 ：仕様書無しさん：2007/02/25(日) 17:37:27

とある製造業のシステム部門で汎用機の保守も仕事の一環で
やってるのですが、PD書もSD書もありません。
どうすればええんですかね？

682 ：595：2007/02/25(日) 18:52:14

その方言はよく解らんが、必要な資料がないと言うならば
そもそも「保守も仕事の一環でやってる」とは言わん気がするんだが。

683 ：仕様書無しさん：2007/02/25(日) 23:38:48

PD書もSD書
って何ですか？
仕様書みたいなもん？

684 ：仕様書無しさん：2007/03/02(金) 19:48:34

富士通COBOLの特殊レジスタ？である

RETURN-CODE

PROGRAM-STATUS

上記の意味と相違についてどなたかご存知ないですか？

685 ：仕様書無しさん：2007/03/20(火) 20:55:05

>>684
方言というのがわかりましたので、ありがとうございました・・・

686 ：仕様書無しさん：2007/03/21(水) 13:14:48

NECのCOBOLにもあるな

687 ：仕様書無しさん：2007/04/01(日) 11:20:10

>>658
俺は、その本でＣＯＢＯＬ覚えたけど、現場のボコラーの人たちに、
なんでＶＢみたいに、いっぱい改行いれるの？見難いじゃんって
言われて、唖然としますタｗ

688 ：仕様書無しさん：2007/04/07(土) 16:10:52

http://rikunabi-next.yahoo.co.jp/tech/docs/ct_s03600.jsp?p=000599

689 ：仕様書無しさん：2007/04/07(土) 18:40:31

ボルコ

690 ：仕様書無しさん：2007/04/30(月) 06:33:54

FACOM→ACOS4の移植は苦労した

691 ：仕様書無しさん：2007/04/30(月) 07:31:08

この一ヶ月で、３０万行のＣＯＢＯＬソースすべてプログラム設計書に落としました。
おかげで、９連休です。

５月７日から怒涛の勢いで、中国人達がＪａｖａプログラムにしまつ。

ちなみに、ＣＯＢＯＬソースはすべて勘で読みました。
REPLACEという命令だけはﾁｮｯﾄ解らんけど、問題ないよね。
賢い漏れは５月７日からﾁｮｯﾄ旅にでますけど。

692 ：仕様書無しさん：2007/04/30(月) 09:38:49

お前、後でしっかり責任取らされるぞ。

693 ：仕様書無しさん：2007/04/30(月) 14:35:34

つか、DBなんかの見直し無しでソース焼き直し？
1レコード全部詰め込みの悲惨なのが残るぜよ。

694 ：仕様書無しさん：2007/04/30(月) 15:16:01

大変だ！FILLER領域が無い

695 ：仕様書無しさん：2007/05/08(火) 07:45:28

COBOLってのはさ、ようはSQLの発展系なわけ。
構造化ﾌﾟﾛｸﾞﾗﾐﾝｸﾞが出来るSQL。
それがCOBOLだ。
もしくはAccessVBAだ。
C#は次のﾍﾞｰｼﾞｮﾝでそれを言語仕様に組み込む予定。
それがLINQ。
覚えておいて。

696 ：仕様書無しさん：2007/05/08(火) 16:14:43

COBOLは…強いて言えば
変数自体が書式を持ってるって辺りが特徴的だが
それ以外に興味も魅力も感じないな…ｗ

697 ：仕様書無しさん：2007/05/08(火) 20:10:54

そんなこと言いに来たんですか？(苦笑)

698 ：696：2007/05/08(火) 20:31:01

>697
うん☆（＾ー＾

699 ：仕様書無しさん：2007/05/09(水) 23:57:45

>>695
C#のバージョン更新の早さに萎える

まだ2.0すら理解しきれてない

その点枯れきったCOBOLは安心

700 ：仕様書無しさん：2007/05/12(土) 10:34:56

あるIT企業から内定を頂いたのですが、
そこの会社はCOBOL言語を使うらしいのですが、
CやJavaと比べて何が違うのでしょうか？

701 ：仕様書無しさん：2007/05/12(土) 11:01:37

何が違うのかって聞かれてもなぁ。全然系統が違う別の言語だとしか言い様がねーよ。

702 ：仕様書無しさん：2007/05/12(土) 13:19:38

英語ベースだから大差ないよ。
記号スキーか単語シコーかの差。

703 ：仕様書無しさん：2007/05/12(土) 18:20:26

>>701,702
レスありがとうございます。
ソースを見たのですが計算するのに
CやJavaだと計算する時は「i = i + 1」でいいのに
COBOLは「COMPUTE I = I + 1」って記述しないと
いけないんですね。めんどくさい・・・

704 ：仕様書無しさん：2007/05/12(土) 19:07:57

インクリメントするだけなら「ADD 1 TO I」でできる。
どこも面倒じゃない。

705 ：仕様書無しさん：2007/05/12(土) 22:47:53

Javaと比べたら面倒
コーディング自体は変わらんけど単体テストでの手間が違う
Cはシラネ

706 ：仕様書無しさん：2007/05/12(土) 23:43:07

バグ0で作ればテストなんて楽なもんじゃないか。

707 ：仕様書無しさん：2007/05/13(日) 00:16:12

じゃあもう単体テスト要らないな

708 ：仕様書無しさん：2007/05/13(日) 00:54:02

>>707
実際要らない。

709 ：仕様書無しさん：2007/05/13(日) 08:22:55

テストの為の環境作りなんかが本当に大変だからね。
DBの中身確認するのも面倒だし、データ表示の為のアプリも必要だし。
HDDの容量も少ないしCPUもあまり使えない。
最下層グレードの汎用機を数年リースで数千万なんてありえねーよ。

710 ：仕様書無しさん：2007/05/13(日) 14:47:45

>>709
本当に汎用機（オフコン）が必要なのかを考えた方が良いんじゃね？

大型、中型のプリンタなど周辺機器を使いたいが為泣く泣く汎用機を使っているとか？

711 ：仕様書無しさん：2007/05/13(日) 17:24:46

自社の基幹システム開発を汎用機でずっとしてきてるから…
オープン系へ移行なんてとんでもない orz

712 ：仕様書無しさん：2007/05/13(日) 19:55:56

汎用機の方が総合的に見たときにはコスト低いから
わざわざ不安定でコスト高になるオープン系に移行する意味がない。

713 ：仕様書無しさん：2007/05/13(日) 20:40:30

わざわざ将来性がなく行き止まりになる汎用系を維持する意味がない。
オープン機の方が総合的に見たときにはコスト低いから

714 ：仕様書無しさん：2007/05/13(日) 20:59:02

>>713
オープン系の将来性も微妙だけどな。
パソコンオタクには理解できないのかもしれんが。

715 ：仕様書無しさん：2007/05/13(日) 21:16:52

>>712
汎用機でハード周りのトラブルが起きた場合はきっちり原因究明してくれる（高いリース料払ってる
甲斐はある）から安心なんですかねぇ。
漏れが汎用機メーカー側で周辺機器のトラブルシュートしてた時にはそうだったんだけど、
今もきっちり原因を説明してもらえるんだろうか？

716 ：仕様書無しさん：2007/05/13(日) 22:03:44

ログ持って帰って調査して終わりかな。
報告なんてくれないよ。

717 ：仕様書無しさん：2007/05/15(火) 21:20:18

IT業界を脱出するか、社内SEになってそのうち
総務や人事や経理に鞍替えしたほうがずっと長生き出来る。

718 ：仕様書無しさん：2007/05/16(水) 17:33:56

それが簡単にいけばいいんだけどね

719 ：仕様書無しさん：2007/05/16(水) 20:43:06

俺は汎用機（ＡＣＯＳ4）の運用からＪＣＬ作成の
運用管理になりＣＯＢＯＬで開発し

辞めた…

今は水質の機械の保守の仕事している（コンピューターはまったく関係ない）

給料は1.5倍になった

早くＩＴ業界は辞めるべき

720 ：仕様書無しさん：2007/05/16(水) 23:21:46

やめた途端ワーキングプアになっちゃう

721 ：仕様書無しさん：2007/05/18(金) 12:53:29

いやそれただのプアだろ

722 ：仕様書無しさん：2007/05/18(金) 13:27:07

わろた

723 ：仕様書無しさん：2007/05/18(金) 23:54:31

大林久人は発砲事件の犯人なのか？

724 ：仕様書無しさん：2007/05/19(土) 14:33:03

ＣＯＢＯＬ経験者の派遣がウチ（Ｊａｖａ系）のＰＪに入ってきたんだけど
全然つかえねーよ！
つかえねーってレヴェルじゃなくて、もう完全なるお荷物でどうしようもない

立場上面倒みなきゃいけないんだけどもうそろそろ限界です、たすけて

725 ：仕様書無しさん：2007/05/19(土) 19:45:16

キーボード掃除でもさせておけばよろし

726 ：仕様書無しさん：2007/05/19(土) 20:53:18

コボラーの使い道はないな。
引導渡してやれ

727 ：仕様書無しさん：2007/05/20(日) 00:30:10

そうだね、今動いているＣＯＢＯＬのシステムにも引導渡しちゃえ。
できればの話ですけどぉ。

728 ：仕様書無しさん：2007/05/20(日) 04:28:53

>>724
使えないのはお前らJava厨の方だろ。
ろくに現状の説明もできない、コードレビューもできない、
端末に向かってキーボード叩いてりゃ仕事した気になってる。
トラブルかかえてても「大丈夫です」なんて嘘付くし。

729 ：仕様書無しさん：2007/05/20(日) 09:32:24

今年初めから実務に入った金融系COBOLerですよ……
COBOLいらつく。マジうざい。

パラメータうざい。引数と戻り値でシンプルに処理してええええよおお。
なんで繰り返し処理するためだけに何百ステップも離れた場所にSECTION切ってんだ。
グループ項目もソース追うときDATA DIVISIONとにらめっこにならなきゃいけないから疲れる。
なんで変数のクリアであそこまで気を遣わなきゃいけないんだ。スコープ使わせろ。

あああああ、ストレスたまるー。

730 ：仕様書無しさん：2007/05/21(月) 10:36:34

>>729
どんだけ無計画にコーディングしてんだよ
思いつき思いつきで書くようヤツなら、まだCOBOLだけでもメンテしやすく書いてくれるヤツの方が使い物になるな

731 ：仕様書無しさん：2007/05/21(月) 22:01:02

>>730
COBOLなら普通だけど？
COPY句に書かれた変数が普通に登場して
どこから現れたのか焦ることなんか多々あるぜ。

732 ：仕様書無しさん：2007/05/22(火) 16:28:39

>>731
どこが>730へのレスなのかが判らない。

変数の宣言ぐらい計画的にコーディングしてたら苦は無いだろうに、どんだけ>729はゆとりなんだよ。
って話でしょ？

つーか、人の書いたCOBOLを見るときはINCLUDE拾っておくのは常識だろ。

733 ：①：2007/05/22(火) 21:28:03

俺はCOBOラーとしておよそ15年。
得意なマシンはIBMと富士通で、MVS・MSP・XSPを普通に使えます。DBはIMSが一番好きですが、SQLが分かるのでDB2もOK。
バッチメインだがCICSも大丈夫。得意な業務は金融系「銀行業の法人向け貸出業務。」
ただコマプロだけは余り得意とは言えません。
というスキルを持って、とある派遣会社に転職。
ほどなくして現場は見つかりましたたが、JavaやJSPが分かるSEよりも単金で若干少ないとの事。年齢も35歳だし仕方がありません。
という理由でこの会社の社長、俺に言って来ました。

「お前もよ～。さっさとJava覚えろよ～。今この時代、
この業界ででJavaが分からないと食って行けないぜ？
単金も安いんだからよ～。」

つい先月、たった1年で辞めました♪
辞めた翌月に給料の振込みが遅れてたので電話をかけて確認してみると、

「お前ね～。何でも世の中自分の思い通りになると思ったら大間違いだぜ？」

ですって。勘違いもはなはだしいとはまさにこの事です。
ちなみにこの会社の社長は、起業前は食品会社でTOPの営業マンだったとか。

「資本主義社会で、一番楽して儲かるのは社長だ。」

これが座右の銘だそうです。
この会社は多重派遣・偽装請負に頼って中間マージンを搾取して稼いでいる会社です。
いわゆる、単なる「人材の横流し組織」。
武器となる技術などな～んにも持っていません。出向率100%は伊達じゃありません。ｗｗｗ
そもそも社長自身がIT技術など皆無ですし、業界の事もまるっきり分かっていません。
かつ、人間のクズです。

734 ：②：2007/05/22(火) 21:30:35

今はユーザはコンプラの問題もあって、2次請・3次請にはナーバスになってます。
それは大手のベンダーも同じで、直接契約した会社内で体制を組めるかどうか？で客を選ぶ傾向があります。
そうなったらまず真っ先に潰れるのは、この社長のような会社です。
ちなみに自分は今SIベンダーに入ることが出来て、そこで協力会社との要員調整の仕事をしています。
COBOラーとしての経験を生かして、金融系のユーザへ提案するRFP作成もやらせてもらっています。
とてもやりがいのある仕事です。

そんなある日の事です。この会社が、うちの会社から仕事をもらう立場としてリストに載ってるじゃありませんか。ｗ
さっそく案件情報を送るメールグループからこの会社を削除したのは言うまでもありません。
この会社は取引先を1つ失ったわけです。近いうちに、この会社から社員を根こそぎ引き抜いて路頭に迷わせてあげます。潰します。
今の自分にはそれだけの事を上層部に提案出来る権限があります。
人を使い捨てるものだと思っていると、思わぬ所から報復を食らいますよ？
ま、せいぜい頑張って下さい。
「まさかあいつが・・・。」なんて後悔しても遅いです。
ビクビクしながら毎日眠れぬ夜を過ごすあなたを想像するのがとてつもなく痛快です。

「株式会社ブルー・アース　青木敏春」様へ。
ttp://www.ble.co.jp/

735 ：仕様書無しさん：2007/05/22(火) 22:06:00

>>732

COBOLの常識なんてしらねーよｗ

736 ：仕様書無しさん：2007/05/23(水) 10:55:47

>>735
常識知らないのに弄るのが無計画ゆとり

737 ：仕様書無しさん：2007/05/24(木) 23:32:53

>>729
頭の悪い人間？
もっとやりやすいように工夫するとかしないの？

738 ：仕様書無しさん：2007/05/25(金) 01:21:27

古いコピー句やら改修にがんじがらめにされるのがCOBOLなんじゃねーの。
ローカル変数なんて概念がないのも、
グループ項目の関連がソース追うだけじゃ直感的にわからないのも。
仕様の問題だから、工夫のしようなんてないだろ。

739 ：仕様書無しさん：2007/05/25(金) 11:06:20

コピー句ってプログラム毎に同じ変数宣言しないで済むようにした工夫なんだけどな
ハードの値段が下がったおかげで、ディスクやメモリーを使い放題なゆとりには解らないだろうな。クライアントから処理が遅いとクレームがきても「仕様です」で片付けちゃってるだろ？
COBOLしか書けないのは論外だけど、COBOLの仕様にもきちんと対応できる人は他の言語でも読みやすい書き方をしている場合が多い。

740 ：仕様書無しさん：2007/05/26(土) 01:20:15

うんうん、ソースの頭にグローバル変数全部書き並べたりね

741 ：仕様書無しさん：2007/05/26(土) 03:33:49

COBOLはメンテしやすくて好き。
もちろｎ作る人にもよるけど。ｗ

742 ：仕様書無しさん：2007/05/26(土) 05:28:53

コピー句ペタペタ、サブルーチンペタペタ、プロ仕パクリ

743 ：仕様書無しさん：2007/05/26(土) 15:13:14

仕様書の作り方にもセンスが出るよね。
もちろん現場で使ってるフォーマットがあるけど、それに沿って
「如何にわかりやすく作るか？」というのもあるし。

744 ：仕様書無しさん：2007/05/26(土) 22:22:11

この前、友だちから西部警察のビデオを借りて、久々に見た。
子供の時以来だ。
その中で、「超高精度・高性能時限爆弾」を作った元SEの爆破魔が
脅迫事件を起し、大門軍団出動、という話を見た。

子供の頃に見たときには何とも思わなかったが、
犯人を突き止めるべく捜査している軍団員が、犯人と思われる男が
作った爆弾プログラムのソースを見るシーンがあって、
それがCOBOLだったような。ｗ
DATAD EVISION1の辺りを見てた奴が、
「だ、だめだ！複雑すぎて分からない！」とか言ってたよ。。。

745 ：仕様書無しさん：2007/05/26(土) 22:53:10

ゲッターロボの操作画面がBASICだったりもしたな
いちいちインタプリタで解釈してんのかよ！

746 ：仕様書無しさん：2007/05/27(日) 11:57:16

>>737
たぶん729の作り方が悪いんじゃなくて、作りの悪いプログラムを
729がメンテしなきゃいけないんじゃないの？

747 ：仕様書無しさん：2007/05/27(日) 23:48:14

拡張しすぎて
FILLERが足りないよ
顧客Ｍ　1500Byteカツカツに埋まってる
だれだ無計画な拡張をしたのは

ブツブツ

748 ：仕様書無しさん：2007/05/28(月) 00:27:57

とあるロボット漫画では有害なプログラムが無いか判断するのに
16進ダンプを見て「ふーむ、まあいいじゃろう」とか言ってたな
そんな小さいプログラムじゃなかろーに、バイナリ目視でいいのかｗ

749 ：仕様書無しさん：2007/05/28(月) 00:47:37

実際に紙テープを読める奴がいるし問題ない。

750 ：仕様書無しさん：2007/05/28(月) 01:08:43

アンヌ隊員は普通に読んでいたな

751 ：仕様書無しさん：2007/05/28(月) 11:35:05

昔俺もパチンコ屋の計数穿孔テープくらいなら読めたよw

752 ：仕様書無しさん：2007/05/28(月) 21:21:52

>>749
パンチカードなら、カード単体がどういう値かは誰でも見れば解るとおもう。
＃マークシートみたいに印刷してあったりするし。

問題はそのバイナリがどういう意味かってことで、結局 >> 748の問題に突き当たる。

753 ：仕様書無しさん：2007/05/29(火) 04:18:29

>>748
検証用のコードが入っていて、例えば特定領域にCRCを書き込むとか、
そういうんじゃないの？

754 ：仕様書無しさん：2007/05/29(火) 19:56:16

【調査/PC】「死んだ(または死につつある)コンピュータスキル」トップ10：1位はCOBOL [07/05/28]
http://news21.2ch.net/test/read.cgi/bizplus/1180368241/

755 ：仕様書無しさん：2007/05/30(水) 11:40:47

>>754
http://pc11.2ch.net/test/read.cgi/tech/1146475958/235-237

756 ：仕様書無しさん：2007/05/30(水) 15:57:36

そんなことしないでｽﾚﾀｲくらい明示しとけよｗ

757 ：仕様書無しさん：2007/05/30(水) 16:05:37

コボラだからそこまで気はまわらない

758 ：仕様書無しさん：2007/05/30(水) 16:11:14

ひでぇｗ

759 ：仕様書無しさん：2007/05/30(水) 17:24:15

自演乙

760 ：仕様書無しさん：2007/05/30(水) 20:14:02

遙かまえから「無くなる、無くなる」言われてるのに
全然無くなる気配が無いな

761 ：仕様書無しさん：2007/05/30(水) 22:38:45

言語を変えて移行しても大失敗したら嫌だからね。

762 ：仕様書無しさん：2007/05/30(水) 23:29:33

まともなRDBでの設計とアプリ設計ができない状態のコボラ主導で変にマイグレーションするんなら、
無理にJavaじゃなくてもPro*COBOLでやったほうが傷は浅いんだろ。たぶん。

763 ：仕様書無しさん：2007/05/31(木) 09:57:01

>>761
日本ユニシスに任せるんだ

764 ：仕様書無しさん：2007/05/31(木) 20:44:53

動いていものを動かなくする会社、多いな

765 ：仕様書無しさん：2007/06/06(水) 22:12:15

コボルの仕事が多いとか聞いたがこんな奴らがたむろしてるのかｗｗｗ

766 ：仕様書無しさん：2007/06/07(木) 02:04:44

>>762
RDB設計とアプリ設計の知らない奴はどの言語を使っても同じ

767 ：仕様書無しさん：2007/06/08(金) 18:25:14

年金照合はCOBOLで！ｗ
マッチング

768 ：仕様書無しさん：2007/06/09(土) 13:21:39

>>767
笑い事じゃなくて、本当です。

769 ：仕様書無しさん：2007/06/09(土) 16:11:50

金の計算はCOBOLの方が良い

770 ：仕様書無しさん：2007/06/10(日) 16:45:30

風俗嬢にCOBOLなら私も出来ると言われた・・・OTL

771 ：仕様書無しさん：2007/06/10(日) 17:33:58

ｗｗｗｗｗｗｗｗ

772 ：仕様書無しさん：2007/06/10(日) 21:32:26

>>768
言っていい冗談と悪い冗談があるとおもうんだ。

mjdsk?

773 ：仕様書無しさん：2007/06/11(月) 11:13:00

金計算でCOBOL使ってる環境は珍しくない
古い会社や公の組織ならなおさらだな

774 ：仕様書無しさん：2007/06/11(月) 13:12:41

ＣＯＢＯＬってＲＤＢ使えないよな？
階層型ＤＢで処理するのはキツい案件だと思うんだ……

775 ：仕様書無しさん：2007/06/11(月) 15:35:11

>>774
なにいってんだ？

776 ：仕様書無しさん：2007/06/11(月) 20:20:17

SQL使えるが、コボラーは使えないのか使わないのか
とにかくREAD・WRITE大好き人種だから間違えるのもわからんでもない

777 ：仕様書無しさん：2007/06/11(月) 21:17:47

ＤＢにＲＥＡＤ・WRITEはないでしょ。
最近はREAD・ＷＲＩＴＥも使わなくなった。
インターフェースはサブルーチン。

778 ：仕様書無しさん：2007/06/11(月) 21:21:56

GET ANY , GET FIRST , GET NEXT 、、、、あぁ、もう見るのも嫌だ w

779 ：仕様書無しさん：2007/06/11(月) 22:40:17

随分と懐かしい記述だ

780 ：仕様書無しさん：2007/06/12(火) 09:56:52

>>776
いやコボラー云々じゃなくてシステム構成の問題なんでない？
最近READを書くことは減ったけど、WRITEは減らないな
CSVに吐き出させてみたり、帳票系では普通に使わざるをえない

781 ：仕様書無しさん：2007/06/12(火) 11:05:01

>>777

>インターフェースはサブルーチン。

SELECTするサブルーチンに「DB_READ_RTN」と名前がついているとか？

782 ：仕様書無しさん：2007/06/12(火) 17:00:07

銭の計算に使いたい言語、一位はCOBOLです
ここ数十年、流行の制御に使用するのはC(そのまえはｱｾﾝﾌﾞﾗ)です

COBOLが嫌なら他の言語を勉強しなさい

ただ、どの言語でも基本は変わりません

貴殿の脳に基本的な事をどう植え付けたかですねｗ

783 ：仕様書無しさん：2007/06/12(火) 20:41:00

COBOLと他言語の基本が同じって…ｗ

貴殿は刺激的な脳をしておられますねｗｗｗ

784 ：仕様書無しさん：2007/06/12(火) 20:49:57

>>781
EXEC-SQL.～END-SQLの間に普通にSQL書いて、プレコンパイラがサブルーチンコールに変換するから意識しなくて良い。

785 ：仕様書無しさん：2007/06/12(火) 22:57:07

ちょっと誰か教えて・・・

英数字項目として宣言した変数の中に入っている
英数字‘2006’を
‘2005’にしたい場合
‘2006’-1
又は
‘2006’-‘1’
でできる？

それとも、判定でMOVE文かまさないとだめ？
どっかで見た気がするんだけど忘れちゃった。

786 ：仕様書無しさん：2007/06/12(火) 23:12:30

>>785
できない。

787 ：784：2007/06/12(火) 23:16:09

間違った。END-EXEC.だな。

>>785
内部形式が同じなのでPIC 9(4)で再定義すればできる。
9(4)にMOVEするのは邪道。

788 ：仕様書無しさん：2007/06/12(火) 23:55:42

サンクス。

やっぱり再定義か。
なんかどっかでこんなこと他の言語じゃ絶対できないのにー
っていうようなことができた気がしたんだけどな。。。

本当に助かりました。

789 ：仕様書無しさん：2007/06/13(水) 18:36:42

いや、再定義しなくてもグループ項目でいいんじゃねーの？

10 YYYY PIC X(4)
15 YYYY-9 PIC 9(4)

YYYY-9 からなら1を引ける。

790 ：784：2007/06/13(水) 20:10:03

>>789
ヲイヲイ、それじゃあコンパイルエラーだ。
PL/Sならできるがな。PL/S知ってる奴はそういない。
今はPL/Xだっけか。IBM内部だけで使われている言語。

正しくは
10 YYYY.
15 YYYY-9 PIC 9(04).

791 ：仕様書無しさん：2007/06/13(水) 20:24:22

COBOL書くときって、みんなテキストエディタで書いてる？
なんか、フリーのWin用ソフトないっすかね？

Eclipse Plugin試してみたけど動かなかた・・

792 ：仕様書無しさん：2007/06/13(水) 21:18:25

>>791
ISPF

793 ：仕様書無しさん：2007/06/13(水) 23:01:37

PF12はretrieveなのかcancelなのか

794 ：仕様書無しさん：2007/06/13(水) 23:04:37

>>792
それってエディタ？
フリーの使えるIDEってない？

795 ：仕様書無しさん：2007/06/14(木) 00:45:41

>>794
ISPF

796 ：仕様書無しさん：2007/06/14(木) 00:47:45

>>774
こういう、なにも分かってないバカが、
コボル使えネー
とか言ってるんだよな。

COBOL（´・ω・）ｶﾜｲｿｽ

797 ：仕様書無しさん：2007/06/14(木) 00:51:51

>>783
同じだろ。バカじゃねーの？

798 ：仕様書無しさん：2007/06/14(木) 21:26:08

>>793
昔はRETRIEVEだったけど、今はCANCEL。
俺はRETRIEVEにして使ってる。CANCELなどDB2PMを使う時しか必要ない不要キーさ。

799 ：仕様書無しさん：2007/06/17(日) 17:53:38

>>783
基本はどう考えても一緒

違うのは標準ライブラリがゴミつーか無いのと言語仕様がアレなだけ

800 ：仕様書無しさん：2007/06/19(火) 22:33:47

>>799
お前は日本語も英語もドイツ語も「言語だから基本は一緒」って考えているのか？

と、FORTRANで給与計算をやらされた俺が言ってみた。

801 ：仕様書無しさん：2007/06/21(木) 00:24:15

>>800
ピンで海外転勤でもすれば現地語喋れるようになるだろ

つかお前も必死でFORTRAN覚えたんだろ？ｗｗｗ

802 ：仕様書無しさん：2007/06/21(木) 20:28:11

つまり覚えるという基本は同じということなのか？

803 ：仕様書無しさん：2007/06/22(金) 11:49:39

>802
んー、アセンブリなんかだと、覚えることは少ないけど
頭ひねる比重はかなり高いんじゃね？

覚えるにしても、何を覚えるか、も結構違うよな。
日本語は名詞を覚える言語だが
英語は動詞とイディオムを覚える言語だし。

プログラミングでも関数を覚える言語もあれば
クラスを覚える言語もあるし。
COBOLは予約語を覚える言語だなｗ

あと、根本的な思想の違いもある。
RPG と Haskell と Java を同列に扱えるかっていうとそうじゃない。
どう訳そうとしても直訳しづらいんだよ。

COBOLだって、他の言語と違う珍しい考え方がある。
データの入れ物が桁情報や書式情報を持ち
書式付きの項目にぶち込むことでフォーマット。

大抵の言語は、変数に入るのはあくまでデータであって
フォーマットは出力したり文字列化する際に
文字列か何かで指定するもんじゃないか？
書式項目って割と珍しくない？

804 ：仕様書無しさん：2007/06/23(土) 04:16:14

入れ物に色が付いてるという意味では、
型も似たようなものではなかろうか。

805 ：仕様書無しさん：2007/06/23(土) 12:14:13

>804
でも型は入れ物に入るデータを制限するものって感じがする。
PICTURE の珍しいところは
入れたデータを項目が持つ情報に従って変換するところだと思う。

806 ：仕様書無しさん：2007/06/24(日) 09:09:55

C1C3を「１３」と見るか「AC」（だっけ）と見るか、ってことだな。
型とは違って、データ自体が色を持ってるんじゃなくて、データを見るときにどんな色をつけるか。

あとグループ項目も独特の概念だな。
たとえばある変数の4桁目から7桁目を取り出すってときに、
関数で変数をぶった切るんじゃなくて、データ領域自体を最初から定義する。

807 ：仕様書無しさん：2007/06/24(日) 09:56:40

COBOL やったことないけど、みんなの話おもしろいね。
読んでると、COBOL のコンパイラってどういう作りになってるか不思議になってくる。
書式情報など、そのままマシン語に変換できると思えないんだけど、コンパイラ内部で
かなり面倒くさいことやってるんじゃない？

808 ：仕様書無しさん：2007/06/24(日) 14:10:35

IBM系のメインフレーム、FやHの命令セットを見ると
COBOLコンパイラが作りやすいのがわかるよ。
IAなんかだとランタイムで吸収してるんだろうけどね。

809 ：仕様書無しさん：2007/06/24(日) 14:49:01

>>807
>かなり面倒くさいことやってるんじゃない？

Cのprintf()もかなりめんどくさいことをやってると思いますが。

>>808
悪名高きEdit命令とかですかねｗ

810 ：仕様書無しさん：2007/06/24(日) 20:04:42

>>806
REDEFINES って（あれだけはw）便利だと思うんだけどなぁ

811 ：仕様書無しさん：2007/06/24(日) 23:23:31

>>810
Cには共用体があるではないか

812 ：仕様書無しさん：2007/06/25(月) 20:46:04

COBOLのDATA DIVISION が好き

813 ：仕様書無しさん：2007/06/27(水) 21:02:46 BE:67846234-2BP(15)

こう言う会社がある。
http://www.cobol.co.jp/

814 ：仕様書無しさん：2007/06/27(水) 23:36:32

いくらＣＯＢＯＬとはいえ単金の範囲は少し安くはないですか。
案件の情報が実際はないしいまいちな感じ。

ただ「新着情報」の日付が未来なのは、ある意味時代の先を行ってる訳ですね。

815 ：仕様書無しさん：2007/06/29(金) 21:26:07

03 work-area
05 cnt-area
07 in-cnt
07 out-cnt
05 flg-area
07 flg-a
07 flg-b

initialize work-area.

このイニシャライズする瞬間が好き

816 ：仕様書無しさん：2007/06/29(金) 22:38:23

なぜに０１がないの
後、字下げしてよ！

817 ：仕様書無しさん：2007/06/30(土) 14:34:09

でもinitialize命令とかinspect命令って規約とかで禁止されてるところもあるんだよな
なんでかは知らないが

818 ：仕様書無しさん：2007/06/30(土) 15:27:42

>>817
数字項目にゼロ、英数字項目にスペースが入る訳では無いから、とかじゃ無かったっけ？
あと、微妙に処理速度が遅かった様な気がしなくもない。

819 ：仕様書無しさん：2007/07/01(日) 19:05:54

集団項目に対してinitializeするとlow-valueがセットされるんで、それを嫌うとか　だったかな？（もうあやふや w

820 ：仕様書無しさん：2007/07/01(日) 20:08:03

いや、そんなのは年寄りが「俺が知らないからだめだ」っつてるだけだ。
技術的に何の理由もない。ひとの(俺の)解らない文を書いてくれるな、っつそんだけ。
だいたい、COBOLを省略抜きの正書法でコーディング出来る奴なんているのか。

821 ：仕様書無しさん：2007/07/01(日) 22:38:21

INITIALINEは集団項目を初期化するというだけであって実際に英数字項目に何
（スペースかLOW-VALUE)をセットするかは実装（メーカー）依存なんじゃないのかな？
（数字項目のゼロは保障されそうだけど・・・）

昔のF社のCOBOLは「OPEN OUTPUT」という命令が実行されたとき

・物理ファイル名の先頭４文字が”WORK"ならばファイルの先頭から
・先頭４文字が"WORK"でなければ、最終データの次から「つまりOPEN EXTEND」

という言語仕様だった。

メーカーが勝手に言語仕様を改竄している状態で
INITIALIZE命令で英数字項目に何がセットされるかなど（そのメーカー言語仕様のマニュアルを読まない限り)分からない。

822 ：仕様書無しさん：2007/07/01(日) 22:56:29

そうなんだ、、、勝手に「0」や「スペース」で初期化されると思いこんでたよ

823 ：仕様書無しさん：2007/07/02(月) 01:06:41

>>822
818だけど、その思い込みで苦労したことあるよ

824 ：仕様書無しさん：2007/07/02(月) 23:23:10

うちは処理が遅くなるから禁止　INITIALIZE

825 ：仕様書無しさん：2007/07/03(火) 20:34:17

どれだけの差がつくっつーんだか

826 ：仕様書無しさん：2007/07/06(金) 19:09:56

誇り高きコボラーの諸君よ！
田原総一朗にこんなこと言われてるぞ
↓
消えた年金問題はコンピュータが原因 by 田原総一朗
http://money6.2ch.net/test/read.cgi/seiji/1183645152/

1 名前：名無しさん＠３周年[sage] 投稿日：2007/07/05(木) 23:19:12 ID:JQgXBHOk
日経BPのWebで田原総一朗が「5000万件の消えた年金の問題は40年も前の
COBOLというプログラム言語を使っているのが原因」とのたまってます

日本の国会議員の中で、最もコンピュータシステムに詳しい人に聞いたんだそうです

http://www.nikkeibp.co.jp/style/biz/column/tahara/070705_18th/

金融関係のSEやってる人なら常識だけど、今でもほとんどの日本の金融機関の
勘定系システム(金の勘定する一番大事なとこ)はCOBOLで出来てます。

こりゃあ、あなたの預金も消えちゃうかもしれませんよwwww

この記事ちゃんと訂正が入るんだろうな？
入らないならもう日経BPはコンピュータ関係の雑誌やる資格が無いな

827 ：仕様書無しさん：2007/07/06(金) 19:20:11

なんか、よく分かってないで書いてる事が丸わかりな文章だなぁ・・・。

828 ：仕様書無しさん：2007/07/06(金) 20:01:28

むしろ田原総一郎が悪いんじゃね？

あ、それと、INITIALIZEは登場当時(＝COBOL85)は比較的「重い」とされていて、
初期設定は別個にVALUEでやれと大昔の教本に書いてあったよ。
まあ30年前とかのオフコンには㌧でもなく重いマシンもあるからなー

829 ：仕様書無しさん：2007/07/06(金) 20:01:40

なんでCOBOLが叩かれなくちゃいけないんだろう、、、
＞日本の国会議員の中で、最もコンピュータシステムに詳しい人に聞いたんだそうです
誰？

830 ：仕様書無しさん：2007/07/06(金) 20:18:38

>>829
> 公明党の斉藤鉄夫政調会長
学会員はコボラーまで敵に回したようです

831 ：仕様書無しさん：2007/07/07(土) 00:00:46

銀行はＰＬ／Ｉ多いけどね

832 ：仕様書無しさん：2007/07/07(土) 02:32:53

>>831
信託銀行な。

833 ：仕様書無しさん：2007/07/07(土) 21:53:35

>>830
やっぱり学会か

834 ：仕様書無しさん：2007/07/19(木) 13:27:43

田原総一郎は無知無学にして厚顔無恥。

835 ：仕様書無しさん：2007/07/19(木) 14:59:34

>>834
自分の方がよく知ってる分野が一つあるからって、そんなにいきがんなや。
田原はコンピュータの専門家ではないし、全体の議論についてはいつもそこそこ勉強してるので、その中で欠陥があるのはしかたないと思ってる。
この分野のブレーンが少ないんだろうな。そうやって定年まで窓際の第三者面ですね続けないで、田原に呼ばれてコメントできるくらいの専門家になろうや。

836 ：仕様書無しさん：2007/07/19(木) 15:42:22

プログラムはともかくハードウェアを４０年も変えていないわけがないじゃん。
これはコンピュータの分野でも何でもないし、専門家が必要なほどの内容でもない。

それに専門分野でないならば、入稿する際に専門家に精査させるべきじゃない？
そんなこともしないで欠陥を残したまま公開された文書を、同じく専門外の人が読めば誤認してしまう問題が生まれてしまう。

837 ：仕様書無しさん：2007/07/21(土) 18:53:31

ＤＢとレコードの違いって何なんでしょうか？
ＤＢにイニシャライズやスペースを送ることって出来ます？

838 ：仕様書無しさん：2007/07/21(土) 22:46:51

DBとは何ぞやを勉強した方がいい

839 ：仕様書無しさん：2007/07/22(日) 05:30:32

最近（てここ何年か）音楽CD買ってないな
なんか青春が終わったって感じがする（マになった時点で暗黙的に強制終了してるわけだが）
あとは寿命が尽きるまで生きるだけ

840 ：仕様書無しさん：2007/07/22(日) 22:11:31

DBなんて止まったら終わりなわけで。
COBOLで書かれて安定動作してるシステムを
何が悲しくて安定動作しないJavaの糞システムに変更せにゃならんのだ。

841 ：仕様書無しさん：2007/07/22(日) 23:30:40

滅ぶべきものが滅ぶべきときに滅ばなかったせいで苦労するのは勝手だが
子々孫々にまでその苦労を強要することに人の心が痛まないのか

842 ：仕様書無しさん：2007/07/22(日) 23:35:49

>>841
具体的に何がいつ滅ぶべきだったのか、理由と一緒に言ってもらえないか？

843 ：田原は本当に頭が悪い：2007/07/23(月) 06:22:09

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

844 ：仕様書無し：2007/08/14(火) 21:15:27

開発の現場ではCOBOLでどういうプログラムを書くんですか？
ファイル処理が多いんでしょうか？

初めてCOBOLの案件に入るので、わからないことばかりです。。すみません。。

845 ：仕様書無しさん：2007/08/14(火) 22:03:19

そりゃそれぞれ現場にもよるな。以上。

846 ：仕様書無しさん：2007/08/14(火) 23:36:12

営業の現場では外回りでどういう商品を売るんですか？
さおだけが多いんでしょうか？

初めて外回りの営業に出るので、わからないことばかりです。。すみません。。

847 ：仕様書無しさん：2007/08/16(木) 23:38:50

COmmon Business Oriented Language だったっけ？
上から下に受け流す言語だよね？

848 ：仕様書無しさん：2007/08/17(金) 00:07:04

社会保険庁のシステムが糞なのは、
国民総背番号制を野党が強固に反対するから

NTTデータの体質も悪いが、根本の原因は国民番号に基づかずに1億人以上の数百億もあるレコードを管理するから。
レコードキーピングの専門家からいわせると、悪夢のようなアーキテクチャだ。

849 ：仕様書無しさん：2007/08/18(土) 14:14:41

古い言語使ってるからだってテレビで言ってるだろ馬鹿

850 ：仕様書無しさん：2007/08/18(土) 19:33:59

テレビで言ってたら何でもかんでも信じるヴァカ発見 pu

851 ：仕様書無しさん：2007/08/20(月) 16:01:38

COBOLでも他の言語でもなんでもいいんだよ
プログラミングテクニックの素養を手に入れたらそれで良し
能力開発すればそれでよし
言語関係なく何でもできるよ

852 ：仕様書無しさん：2007/08/20(月) 22:04:36

COBOLにテクニックや要素なんてありませんし
使う機会もありません

　残　念　！

853 ：仕様書無しさん：2007/08/21(火) 00:55:57

COBOLしかできない奴に限って、言語なんて関係無いとかいうんだよな
LispとC極めた奴がいうならわからなくもないけど、コボラがいうなよって感じ
低レベルなJavaのオプソですら、どうやって拡張していいか皆目見当もつかないくせに

854 ：仕様書無しさん：2007/08/21(火) 02:24:46

公明党の斉藤鉄夫政調会長

『Fortran の機械語が COBOL』の名言をテレビで言った人

議員の中で最もコンピューターに詳しい人

この国オワタ

855 ：仕様書無しさん：2007/08/21(火) 07:12:08

>Fortran の機械語が COBOL

意味判らん。誰か解説してくれ

856 ：仕様書無しさん：2007/08/21(火) 20:31:09

>>855
俺も意味判らんけど、田原総一郎の番組で斉藤鉄夫が言った言葉
耳を疑ったけどテレビ板（実況板だったかも）で同様の書き込みが有って盛り上がってた

知ったかぶりするにも知識が無さ過ぎると滑稽という例

857 ：仕様書無しさん：2007/08/21(火) 21:15:58

COBOLしか出来ないし、言語なんか関係ないと思ってるよ
既にPG使う立場だから

858 ：仕様書無しさん：2007/08/21(火) 21:19:49

COBOLしか出来ない奴がPG使いこなせると思ってることがまた滑稽

859 ：仕様書無しさん：2007/08/21(火) 21:48:59

>>857
害にしかならなそうなので、業界からいなくなってください。
おながいします。

……冗談はおいておいて、とり合えず別に言語はできなくてもいいので、
上流工程はCOBOL以降のものもちゃんと学んで身につけておいてくれればいいです。

それができないなら、マジで業界からいなくなって（ry

860 ：仕様書無しさん：2007/08/21(火) 21:56:23

>>859
ああ、もちろん言語なんかどーでもいい、っていう意味で言ってる訳じゃないよ
PGとして第一線で開発やってたのはCOBOLだけってことね

861 ：仕様書無しさん：2007/08/22(水) 10:22:30

COBOL時代のシステム開発は、プロジェクト開始時点に前提条件(言語・プラットホーム)が出揃ってる状況で
経験ベースでも確度の高い見積もりや妥当な設計をすることが可能だった。

コボラは上記が現状では全く通用せず、知識がなきゃ設計はもとよりスケジュールも立てられないことを知らない。
システム開発の本読んだり新しいフレームワーク試してみたり、そういうことやってるコボラを一人も知らない。
コボラPMが読むのはビジネス書のリーダシップの本とか。とにかくズレまくってる。

862 ：仕様書無しさん：2007/08/25(土) 11:52:23

>861
>ビジネス書のリーダシップの本とか

プレジデントだな！ w

863 ：仕様書無しさん：2007/08/25(土) 12:08:21

>>861
プロマネが新規で言語覚えるのも無理だろうし、やり方としては間違ってないんじゃない？
コーダーとはやる事違うし、そういう本読むのも必要だと思うが。
そもそも新規で言語覚えるやる気と能力があるなら、コボラとは呼ばれてないわけで。
そんな奴の下で文句言いながら働いている奴も能力的にどうなのと思うわけで。

864 ：仕様書無しさん：2007/08/26(日) 09:57:25

>そんな奴の下で文句言いながら働いている奴も能力的にどうなのと思うわけで。
くっだらねえ、ガキの発想だな
本人の能力で何でもかんでも解決できるわけねえだろ

恵まれた環境で働くことができるのは、一体何%くらいの人間だ？
能力がありさえすれば、恵まれた環境で働くことができるのか？
可能だとして、上位何%位の人間である必要がある？

865 ：仕様書無しさん：2007/08/26(日) 11:04:53

>>864
そんなの職場で活躍してるヤツや上司にプロパー社員がどれ位いるかを見ればわかるだろ
恵まれた環境ってのは与えられる物じゃなく、自ら探し求めるモノだ

866 ：仕様書無しさん：2007/08/26(日) 15:59:52

>>863=>>865
もっとよく考える習慣つけたほうがいいと思う。
お前が思うより、他の人はずっと深く物事を考えてるよ。

867 ：仕様書無しさん：2007/08/26(日) 16:32:20

何やら必死な人が多いスレですね

868 ：仕様書無しさん：2007/08/26(日) 18:20:32

傍観者気取ってるよりマシじゃね？

869 ：仕様書無しさん：2007/08/26(日) 21:22:53

あ、ひょっとしてこのスレ、現役COBOL使い専用だったの？

870 ：仕様書無しさん：2007/08/27(月) 15:04:12

>>869
このスレはCOBOLについての勉強方を指南するスレ

871 ：仕様書無しさん：2007/09/02(日) 10:04:52

まぁ、20年前にCOBOL使いで、業界を辞めた俺からすれば、

SE,PGなんてのはCOBOL好きだろうが嫌いだろうが、

負け組みの使い捨てだよｗ

872 ：仕様書無しさん：2007/09/02(日) 10:07:22

とついて行けなかった奴が言ってもなー。

873 ：仕様書無しさん：2007/09/02(日) 10:15:45

>>872
あらら、ｵﾏｲﾗが保守してる基幹業務は俺達が無から作ったんだよなぁ
仕様書ないのが多いっちゃ多いけどな（＾－＾；）

874 ：仕様書無しさん：2007/09/02(日) 10:33:13

COBOL使は引く手あまた

って　ねーちゃんが言ってた

875 ：仕様書無しさん：2007/09/02(日) 11:21:19

>仕様書ないのが多いっちゃ多いけどな

あっても全然メンテされてないからもう諦めてる orz

876 ：仕様書無しさん：2007/09/02(日) 12:39:00

たった20年前で無から基幹業務って、若い会社ですねw
いや、自分はその頃からバックログ負ってたもんで、いいなぁ。

877 ：仕様書無しさん：2007/09/02(日) 13:03:34

まあわざわざこんなスレに来るぐらいだから、転職先で上手く行ってないんだろうさｗ

878 ：仕様書無しさん：2007/09/02(日) 20:39:44

>>861
確かにＣＯＢＯＬはちゃんと仕様が固まってからコーディングすると
大体誰が組んでも同じくらいの規模になるね。

ＪＡＶＡとかだとそうはいかない。

見積もりの容易さもＣＯＢＯＬがしぶとく生き残ってる
一因だと思う。

879 ：仕様書無しさん：2007/09/02(日) 21:17:11

いや、構造化プログラミングもできない、あるいは、
ソース水増しのためにあえてやらない連中の手にかかれば、

880 ：仕様書無しさん：2007/09/02(日) 22:50:38

まあ、他人のソースを見ても一発である程度理解できるってのは利点といえば利点かｗ

881 ：仕様書無しさん：2007/09/02(日) 22:55:11

小回り効かないし
地味で面白みないし
帳票命の富士通だし

正直触りたくないんだよな

882 ：仕様書無しさん：2007/09/03(月) 07:12:41

>>881
なら、触んなきゃいいし、何でこのスレ来るのか意味不明

883 ：仕様書無しさん：2007/09/03(月) 20:06:00

この人は何で切れ気味なの？意味不明

884 ：仕様書無しさん：2007/09/03(月) 20:07:57

>>883
妄想が激しいな

885 ：仕様書無しさん：2007/09/03(月) 20:17:11

この人は何で切れ痔なの？意味不明

886 ：仕様書無しさん：2007/09/03(月) 22:45:18

>>885
pic X(06)

887 ：仕様書無しさん：2007/09/03(月) 22:57:08

>>847

いや右から来たものを左へ受け流す言語だよ

888 ：仕様書無しさん：2007/09/03(月) 23:52:12

ID表示が欲しいな

889 ：仕様書無しさん：2007/09/04(火) 05:41:20

>>880
それは甘い

俺が見た恐怖のCOBOLコード...
・PERFORMによる抽象ブロック無し
・下から上へのGOTO乱発
・変数名に意味無し（AND仕様書無し）
・結構長い（PROCEDUREが3000ステップくらい）

仕様が不明なのでフロー書いて追っかけてみたけど何やってるのか理解できず（まぁ俺も新人だったけど）
そのコードを担当したのは俺が３人目だったらしいが皆全滅...俺の後何人死んだことか...

890 ：仕様書無しさん：2007/09/04(火) 06:23:29

>889
IF文のインデント無しも付け加えておくれ
ソースそのものは、そんなには長くなかったけど、頭痛を起こして
会社休んだのはアレを見た後だったよ。orz

891 ：仕様書無しさん：2007/09/04(火) 08:32:13

>>888
しねよ

892 ：仕様書無しさん：2007/09/04(火) 22:42:49

一つの変数にイニシャライズを掛け忘れたためにごくまれに起こるバグ
そのバグの再現と原因把握のためにおいらが３日費やしたのは有名な話

893 ：仕様書無しさん：2007/09/04(火) 22:44:51

私の人生にイニシャライズをかけて下さい

894 ：仕様書無しさん：2007/09/04(火) 23:07:49

>>893
numericでいい？

895 ：仕様書無しさん：2007/09/05(水) 00:14:27

>>891
一人釣れたねｗｗｗ

896 ：仕様書無しさん：2007/09/05(水) 01:49:14

>>895
ｗｗｗってつけなきゃよかったのに

負け惜しみに聞こえるよ

897 ：893：2007/09/05(水) 21:48:11

あ、俺ヤクザじゃん！

898 ：仕様書無しさん：2007/09/06(木) 16:57:18

おっちゃんだが、昔ＮＥＣのＡＣＯＳでCOBOL/Sという変なのをやらされたな
あれで、VIALANとかいうのが信用金庫ででてきた

なんだあれは？
昨今はM/BのVIAだが
LANは未だにローカルエリアネットワークじゃなｗ

899 ：仕様書無しさん：2007/09/06(木) 17:52:06

>>898
おお、なつかすい
COBOL／S。
農水省に派遣で行ってたころ全部COBOL/Sだったな。

900 ：仕様書無しさん：2007/09/06(木) 18:03:02

官公庁なんかは今でもCOBOLとかCOBOL/S現役でしょ。

901 ：仕様書無しさん：2007/09/06(木) 18:47:02

>>900
プチ公務員体験できるよ。
COBOLやってればｗ

902 ：仕様書無しさん：2007/09/06(木) 21:20:19

>>1さん。一生懸命勉強しなさい。
そして、COBOLerに教えてあげてね。。

903 ：仕様書無しさん：2007/09/08(土) 19:19:34

>>899
COBOL/Sがコンパイル時に生成するCOBOLソースを見たことがあるけど
「ELSE NEXT SENTENCE」と「GOTO」が嵐のごとく使われていた。
ソース行数は普通にコーディングしたソースの５倍くらい。
冗談で新人に「このソース解析してくれ」と頼んだら、しばらくソースを眺めた後
「こんな糞なコーディングしたのは誰ですか！」と文句言ってきた。

ACOSと言えばIDLIIというのもあったが、こっちはCOBOLソースを生成すると
印刷して10ページ程度のソースがCOBOLソースで200ページ以上になったな。

904 ：仕様書無しさん：2007/09/08(土) 19:59:43

>>903
懐かしいね、IF: ～ END IF:をコンパイルするとそんな感じのソース吐くんだよね。
アレに慣れたあとF系やったらえらく苦労した覚えがあるよｗ

905 ：仕様書無しさん：2007/09/09(日) 16:43:28

>>903
Ｓだけはばかだと思う
金融担当者用につくったらしいが、バグレスとかわらんわなｗ

906 ：仕様書無しさん：2007/09/09(日) 20:05:54

ＣＯＢＯＬより生産性があがるとうたい文句だったけど生産性が上がったのは
ＭＯＶＥとＣＯＭＰＵＴＥをキーボードから入力しなくて良くなった程度だなw

907 ：仕様書無しさん：2007/09/09(日) 21:28:41

何か不具合があると当然だがCOBOLのソースに変換後のSTEP数で返してくるから
デバッグも面倒なんだよなｗ

908 ：仕様書無しさん：2007/09/09(日) 22:12:34

聞きたいのだがオブジェクト指向コボルてどうなのよ？
多分「オブジェクト指向」という面からするとJAVA等他の言語には引けを取りそうだが。

909 ：仕様書無しさん：2007/09/10(月) 00:01:14

>>908
オブジェクト指向に拡張したＣＯＢＯＬを例える言葉がありましたので紹介します。

「砂上の楼閣」
意味：　基礎がしっかりしていないために崩れやすい物事のたとえ

910 ：仕様書無しさん：2007/09/10(月) 19:56:08

>>908
コボラでさえ使わない気がする。

911 ：仕様書無しさん：2007/09/10(月) 20:36:02

>>908
つかえねー
やっぱ、コボルはコボルが一番

912 ：仕様書無しさん：2007/09/13(木) 23:53:37

コボルやることになったよ
すぐ覚えられるとか言ってたけどそんな簡単なの？

913 ：仕様書無しさん：2007/09/14(金) 00:35:46

>>912
おれは決して覚えられなかった。
特に、IDENTIFICATION DIVISIONとENVIRONMENT DIVISION

914 ：仕様書無しさん：2007/09/14(金) 09:22:27

COBOL って決め打ち多いんですか？
C/C++ 育ちで、決め打ちやマジックナンバーはできるだけ排除するか、変更しやすいようにしろって
教えられたもんで。

915 ：仕様書無しさん：2007/09/14(金) 09:52:33

決めうちコピペの嵐ですよ
COBOL/ADD 1 TO COBOL GIVING COBOL方式に慣れてください

916 ：仕様書無しさん：2007/09/16(日) 18:49:22

コボルで使えるアルゴリズム教えていただきたい。なかなか思うように組めん。。。

917 ：仕様書無しさん：2007/09/16(日) 18:57:58

アルゴリズムなんてほとんどつかえないんじゃないのか？

918 ：仕様書無しさん：2007/09/16(日) 23:47:51

せめて構造化くらいで組めｗ

919 ：仕様書無しさん：2007/09/18(火) 01:00:48

COBOL世界においては、
構造化プログラミングが時代の最先端であり、
今、最もホットな話題の一つです。

920 ：仕様書無しさん：2007/09/18(火) 01:01:48

確かに保守ができん話題でホットだな

921 ：仕様書無しさん：2007/09/18(火) 12:05:28

構造化gotoﾚｽﾌﾟﾛｸﾞﾗﾐﾝｸﾞで組まれたcobolｿｰｽはﾒﾝﾃしやすい

922 ：仕様書無しさん：2007/09/19(水) 11:54:06

goto満載のソースを構造化コンバージョンするの好き

923 ：仕様書無しさん：2007/09/19(水) 23:27:10

今日マッチング習いました。記念下記子。

>>922
パズル解くみたいで楽しいですよね！けど、やりすぎると逆に
トリッキーで読めん！ってブーイング来ません？

924 ：仕様書無しさん：2007/09/19(水) 23:30:14

>>923
それがスタンダードだって事を理解させないと。
トリッキーでもなんでもない。
perform

925 ：仕様書無しさん：2007/09/22(土) 07:21:43

俺はgoto満載の非構造化クソソースは大嫌い
タグの名前が適当だと尚更最悪

gotoでループするんじゃねぇ、ヴォケがっ
alterとか使うんじゃねぇ、カスがっ
>=で適当にVSAMひっかけるんじゃねぇ、クズがっ
キー設計からやり直せ、クソジジィ

と思いませんか？

926 ：仕様書無しさん：2007/09/22(土) 08:42:29

>>925
だからそれをリソースするのが好きな
どMですｗ

927 ：仕様書無しさん：2007/09/22(土) 10:29:05

>>926
あんたすげぇよ
本物のコボルプログラマだよ
俺はあんなもの読みたくもない
つーか読めないものがある

この前、サマリーやマッチングに専用の機能モジュールを使うソースを読んだ

コーディングしたヴァカに殺意をおぼえた
30年以上前のソースだからもう本当に死んでるかもしれないけどw

928 ：仕様書無しさん：2007/09/22(土) 19:03:59

コーディングが面倒だからと、イージーコーディングツールを作ったＳＥがいた。
しかし派遣替えで去った後コンピュータのリプレースでツールが使えなくなり、
そのツール使用を前提のプログラムがえらい迷惑を受けた。

ＩＤＩＶ　→　IDENTIFICATION DIVISION.
ＥＤＩＶ　→　ENVIRONMENT DIVISION.
ＣＳＥＣ　→　CONFIGURATION SECTION.
ＣＯＭ３　→　COMPUTATIONAL-3.

などと略称でコーディングするものなんだが、データネームにうっかりその略称を含む
文字列を使うと大変なことに・・・

PREDIVIDEWORK →　PRENVIRONMENT DIVISIONIDEWORK

929 ：仕様書無しさん：2007/09/22(土) 22:41:30

>>922
昔やったことあるな
暇な時代だった＾＾

930 ：仕様書無しさん：2007/09/23(日) 00:21:57

COBOLについて勉強するのは難しいが（ホストがないとプログラムをコンパイル、ＤＳ移動できない）
、勉強は参考書、資格試験の本などでできるが、
ＪＣＬを学ばないとCOBOLはモジュールとして使えないと思う。
ＪＣＬの市販の参考書などがないためどうやって効率よく後輩に教えるかが・・・。
COBOLが衰退した原因のひとつはこの辺にもあるような気がしたとかしないとか
予約語が無駄に多いとか、コンパイラがしょぼいとかいろいろあるとおもうが
どう思う？

931 ：仕様書無しさん：2007/09/23(日) 09:26:26

>>1
COBOLの環境にいると、コピペがあたりまえになる。
だからこそ、そこでコピペではなく、ライブラリ化することを考える。
もちろん、職場ではそれをやらない（周りから批判をあびるから）
COBOLでも、ローカル変数とか使えるから、研究をする。

その後、オブジェクト指向を勉強してみな。
きっと君が工夫して編み出したプログラミング手法と同じ方向性になってるから。

932 ：仕様書無しさん：2007/09/23(日) 14:56:04

>>930
秘伝のCOBOLという本が売っているぞ

933 ：仕様書無しさん：2007/09/23(日) 15:03:32

頭の悪い社長がコピペだらけで行数だけ多いクソプログラムの行数自慢してたな。
きったない、頭悪いコードの長いだけのソースを。
低学歴丸出しのソースをｗ

934 ：仕様書無しさん：2007/09/23(日) 16:16:23

>>932
秘伝って何をどう秘伝にするのやら
・・・コンプライアンス的によくないことを書いてあるのか？
それとも、腐れジジイの自慢話がかいてあるのかい

935 ：仕様書無しさん：2007/09/23(日) 16:20:32

hiddenのCOBOL？

936 ：仕様書無しさん：2007/09/23(日) 17:19:38

富士通ではシンフォウェアの取り扱いが一子相伝の秘伝となっております。

937 ：仕様書無しさん：2007/09/23(日) 18:30:55

一子相伝だけではなく、門外不出にもしてほしい。

938 ：仕様書無しさん：2007/09/23(日) 18:33:24

すくなくとも他流試合禁止で…。

939 ：仕様書無しさん：2007/09/23(日) 19:49:21

>>934
http://www.google.co.jp/search?hl=ja&q=%E7%A7%98%E4%BC%9D%E3%81%AECOBOL&lr=

940 ：仕様書無しさん：2007/09/23(日) 19:50:26

秘伝昇る

941 ：仕様書無しさん：2007/09/23(日) 20:49:27

COBOLが秘伝というより、
JCLが秘伝といわざるを得ない現実

942 ：仕様書無しさん：2007/09/23(日) 22:11:03

秘伝のCOBOLという本はCOBOLを覚えながらＦＥにでる簡単なアルゴリズムを
理解できるという本
試験には受かるかもね

943 ：仕様書無しさん：2007/09/24(月) 19:13:48

ホストが無いとコンパイルできないって言ってる人いるけど
出来るでしょ？
汎用機だけがコボルの勉強環境じゃないし。

944 ：仕様書無しさん：2007/09/25(火) 17:53:42

翻訳だけならﾌﾘｰのCOBOLｺﾝﾊﾟｲﾗｰで済むな
不実のｱﾒﾘｶのｻｲﾄに学術用があったな
でも、ボヨヨン機で実際にテープデッキをかけて触りましょうｗ

945 ：仕様書無しさん：2007/09/26(水) 17:56:10

>>699
2.0で基盤は固まってると思う。
3.0以降は+αであって、根底が揺らぐことはあんまり無いんじゃないかな。

946 ：仕様書無しさん：2007/09/30(日) 11:10:38

JCLってパソコンで勉強できんの？
本も市販じゃ存在しないだろ

947 ：仕様書無しさん：2007/09/30(日) 17:53:51

>>946
あらら
揚げ足とらんでもいいｗ

948 ：仕様書無しさん：2007/10/03(水) 15:05:47

>>１はどうした？

949 ：仕様書無しさん：2007/10/03(水) 15:20:23

システムの保守の生産性がいかに大事か．．．ＣＯＢＯＬの生存はそれを証明している。

簿記関連のロジックはもはや進化は無い．．．ＣＯＢＯＬの生存はそれを証明している。

950 ：仕様書無しさん：2007/10/12(金) 11:53:05

>>949
そうだな。いちいち別言語でコンバージョンする必要性はないな。
もう一度バブルでも来て、設備投資に金かけられるなら物好きがやるかもしれんがｗ

いずれにしろ、COBOLerは希少で価値が上がると見た。
よかった。よかった。

951 ：仕様書無しさん：2007/10/13(土) 05:41:14

>>950
希少で価値が上がるが、給料は上がらないだろう

952 ：仕様書無しさん：2007/10/13(土) 11:10:39

>>951
基幹システムのコンバージョンには金がかかるからしない。
　　　　　　　　↓
　　保守するCOBOLERの絶対数は減る
　　　　　　　　↓
　　　　価値が上がる。

市場経済の論理で言えば給料が上がるのは当然の流れでしょう。

953 ：仕様書無しさん：2007/10/13(土) 11:32:17

今後COBOLも出来る人の価値が上がる可能性は十分あると思うよ
COBOLしか出来ない人はどーにもならんだろうけど

954 ：仕様書無しさん：2007/10/13(土) 11:42:06

COBOLしか出来ない人でも基幹系のをやってた人なら価値はある。
小規模のとこしかやってない人は価値0になるけど。

955 ：仕様書無しさん：2007/10/13(土) 13:32:43

http://www.microfocus.co.jp/support/techtips/cobol_002.asp

COBOLってやっぱりすばらしい言語だね！　Cなんて足下にも及ばないよ！

956 ：仕様書無しさん：2007/10/13(土) 21:56:09

>>955
プログラム板にも書き込みがあったな・・・
メーカーの営業の場合→はい、ごくろうさん
コボラ→宣伝広告を真に受けたちゃった人　そうそう、Ｃの負けでいいよ（Ｃだけの現場は多いのかな）
Ｃ＋＋やＪＡＶＡには勝てるんかねぇ
でも、現実的なＣの使われ方を知らないだけだろ
業界の人以外→あっそうですか

957 ：仕様書無しさん：2007/10/13(土) 21:59:30

価値は上がっても会社が儲かるだけで給料は上がらないと思います

958 ：仕様書無しさん：2007/10/14(日) 11:56:27

>>956
Cやほかの言語との戦いじゃないわけよ（＾-＾;）。
どうしてそう、対立構図にしたいんだろうねｗ
現実、汎用機の基幹システムはCOBOLで書かれてる事が多いわけだし・・・
他言語へ、新たにコンバージョン率１００％に近づける為の労力を知らないんだなｗ

金もかかるし、人もいる。
実際、コンバージョンするにしたって、コボルの知識が必要になってくる。
二兎を追うもの・・・

コボルは奥深いよｗ

959 ：仕様書無しさん：2007/10/14(日) 12:30:35

なんでこいつら若いのに今更、COBOLを勉強したいとか言うてんの？

960 ：仕様書無しさん：2007/10/14(日) 14:49:27

今思えば、このスレ自体が釣りだったとしか思えないな
>>1らしき書き込みも無いし

961 ：仕様書無しさん：2007/10/14(日) 18:31:38

需要と供給

962 ：仕様書無しさん：2007/10/14(日) 18:54:18

別にCOBOLを勉強したいと思ったわけじゃない。放り込まれた環境がCOBOLだっただけ。

963 ：仕様書無しさん：2007/10/14(日) 19:03:55

今の会社に転職した時の採用理由の一つがCOBOLの経験があること、だったんで
このスレの書き込み見てると色々と複雑な気持ちになるんだよね・・・

自分でCOBOLのソース書くことはしてないけど、たまに見たりはするし
だから、今後需要も需要はあり続けるだろうって意見にも頷けるし、
それでもCOBOLだけじゃ・・・って意見にも同意だったりする

まあ4字で要約すると「職場次第」ってことなんだがなｗ

964 ：仕様書無しさん：2007/10/14(日) 19:51:24

COBOLで月６７万円

965 ：仕様書無しさん：2007/10/17(水) 00:13:09

Ｏ
　　　　　　o　　　　　　　　　　　　　　　　　　　　　　と
　　　　　　　。 ,. -ｰ冖'⌒'ｰ-､　　　　　　　　　　　思
　　　　　　　,ノ　　　　　　　　＼　　　　　　　　　　う
　　　　　　/　,r‐へへく⌒'￢､　ヽ　　　　　　　　キ
　　　　　　 {ノへ.._、 ,,／~`　　〉　｝　　　　,r=-､　モ
　　　　　／プ￣`y'¨Y´￣ヽ―}j=く　　　　/,ミ=/ 　オ
　　　　ノ　/レ'>-〈＿ｭ`ー‐'　　ﾘ,ｲ} 　　　〃　/　　タ
　　　/　_勺ｲ;；∵r;==､､∴'∵;　シ　　〃　/ 　　で
　　,/　└' ノ＼　こ¨｀　　　ノ{ー--､〃__/ 　　　あ
　人＿_/ー┬ 个-､＿_,,..　‐'´ 〃`ァーｧー＼　　　っ
. /　　　|／　|::::::|､　　　　　　　〃　/:::::/　　　ヽ　　た
/　　　｜　 |::::::|＼､_________／' 　 /:::::/〃

966 ：仕様書無しさん：2007/10/17(水) 09:51:09

cobolで、６７万円ならいくでしょ。
どんなとこで働いてんだよお前らｗ

967 ：仕様書無しさん：2007/10/18(木) 19:44:03

C,Javaの連中は最近、月2,30

968 ：仕様書無しさん：2007/10/18(木) 20:20:07

開発言語だけで月額云々なんてアフォすぎるだろ常考

969 ：仕様書無しさん：2007/10/19(金) 00:24:37

ﾁｮﾁｮﾁｮｰっとバッチを書くのにはいいと思うんだが・・

970 ：仕様書無しさん：2007/10/19(金) 00:58:54

全然良くない件

971 ：仕様書無しさん：2007/10/19(金) 18:14:52

COBOLで67って、単体ﾃｽﾄまでの金額だぞ

972 ：仕様書無しさん：2007/10/20(土) 14:48:35

>>971
結合ならもっとあがるってか？

973 ：仕様書無しさん：2007/10/20(土) 21:08:57

>>967
どこのダメ外車だかしらんけど、そんな条件で取ってるからおまいのところには
クビ寸前のゴミみたいなC,Java使いしか集まってこねぇんだよｗ

974 ：仕様書無しさん：2007/10/20(土) 22:10:36

釣られちゃってまぁｗ

975 ：仕様書無しさん：2007/10/20(土) 23:27:05

データ部でデータを定義して、手続き部で反映して
プリントアウトできたのはいいものの、
何故か一番最初に印刷されるデータだけおかしいのは何故なんだ？？？
他はちゃんと出てるのに…orz..

976 ：仕様書無しさん：2007/10/20(土) 23:49:36

初期化漏れだろ

977 ：仕様書無しさん：2007/10/21(日) 11:58:49

>>973
これがCjava使いのクオリティーｗ

978 ：仕様書無しさん：2007/10/21(日) 20:43:27

のダメ外車
のだめは等々免許取って、外車に乗ったのか？
そういえばヨーロッパロケがあるそうな
のだめカンタービレ

979 ：仕様書無しさん：2007/10/22(月) 07:37:02

980 ：仕様書無しさん：2007/10/22(月) 16:43:26

アニオタはしねよ
仕事中にアニメの話すんな気持ち悪い
近くにいたら同じような目で見られるからたまらない
というかいまも近くにいて臭い

981 ：仕様書無しさん：2007/10/22(月) 16:55:14

>>980
ほれほれ，コミュニケーション，コミュニケーション。

今期はどれに期待してる？
とでも聞いてみそ。

982 ：仕様書無しさん：2007/10/22(月) 21:46:03

983 ：仕様書無しさん：2007/10/22(月) 21:53:57

また、そのAAか
ｱﾌｫちゃう？

984 ：仕様書無しさん：2007/10/22(月) 22:12:45

精神的にガキなんでしょ
でも実年齢は40代だったりするんだよこれがw

985 ：仕様書無しさん：2007/10/22(月) 22:38:29

30代未満でしょ
４０代はこんな板には居ない

986 ：仕様書無しさん：2007/10/22(月) 22:41:43

987 ：仕様書無しさん：2007/10/23(火) 23:23:39

>>985
ﾉｼ w

とかなんとか言ってるうちにこのスレもようやく終わろうとしてますな。ﾒﾃﾞﾀｼﾒﾃﾞﾀｼ
早く埋めませう

988 ：仕様書無しさん：2007/10/24(水) 07:15:38

【COBOL】コボラー集まれ！！！【事務処理】
http://pc11.2ch.net/test/read.cgi/tech/1146475958/l50