3 :
デフォルトの名無しさん:2014/07/13(日) 14:24:29.39 ID:ctB2P3i5
1>>様のCOBOL経験は何年ですか。
私は20年程やりました。
>>3 20年って凄いね。
20年前ってことはCOBOL85だと思うけど、
最近のCOBOLってどう?
5 :
デフォルトの名無しさん:2014/07/13(日) 15:09:07.88 ID:ctB2P3i5
>>3 Cのポインタと同じようなことができる外部モジュールとか
オブジェクト指向とか結構機能は拡張されてますけど、
使う側が保守的なので組み方は変わってないですねー。
>>5 実際に使ってる処理系は、最新のCOBOLに対応してるんですか?
つまり、ずっと古いものを使っているのか、
最新のものに入れ替えたのに、最新機能使わずに
なんのために最新に入れ替えたのか意味不明状態なのか。
7 :
デフォルトの名無しさん:2014/07/13(日) 15:32:04.97 ID:ctB2P3i5
>>5 対応しています。
保守的という言葉は悪かったかな。
従来のやり方を踏襲しているだけかも。
他所は知りませんけど。
8 :
デフォルトの名無しさん:2014/07/13(日) 15:40:16.67 ID:ctB2P3i5
7です。
間違えました。
>>6でした。
対応しています。
保守的という言葉は悪かったかな。
従来のやり方を踏襲しているだけかも。
他所は知りませんけど。
>>7 そうなんだ。
プログラムなんて、新しいバージョンにしても
書き方を変えないと、生産性上がらないのにね。
俺だったら、これが今のCOBOLのやり方ですが?って言って
使っちゃうけど。
COBOL2002とか実務で使うことあるんだろうか。
12 :
デフォルトの名無しさん:2014/08/27(水) 13:36:17.27 ID:2MXxvQfU
高2のころにVBで初めてプログラミングやって、高3でCOBOL、大学2年でC言語をやってきたが、
未だにこの3つ以外のプログラム言語は苦手だな。
26にもなってやったことのないプログラム言語を一から覚えろといわれてもきついw
何を覚えろと言われたのか知らんけど
変な仕様のいっぱい残ってるCOBOLやCを既にやったんなら
たいしたことはないと思うがな
14 :
12:2014/08/31(日) 21:33:25.45 ID:idfMo+5x
Javaやっとるけどマジわけわかやでw
趣味でホームページ(HTML・CSS)作ってたからJavaScriptはまだ何とかなるが、
あれはJavaの名を冠した別物だからなあ。
上から順にソースを追っていけない時点でもうキツイw
お前さん、作り込んだC言語のソースを追ったことないだろ
16 :
デフォルトの名無しさん:2014/09/14(日) 17:32:07.93 ID:EIEPRMug
ある区分Aについて処理をループさせて、そのなかで別の区分Bをまたループさせて・・・ 処理がある場合
配列つかって、
PERFORM UNTIL 区分Aの配列の数
・・・
PERFORM UNTIL 区分B配列の数
・・・
ってな感じでやるものかな?と思うのですが、うちの会社のソースみてると
こんな感じの定義をしておいて
01 区分
03 区分A
03 区分B
PERFORM UNTIL 区分Aについてエンドフラグが建つまで
if 区分Aが○○なら・・ (区分毎の処理いっぱいでここで区分を書き換えたりしてる)
PERFORM UNTIL 区分Bのエンドフラグが建つまで
if 区分Bが○○なら・・ (区分毎の処理いっぱいで・・略)
・・・
ってな感じの記載なんですが、こういう書き方のメリットってなんかあるんすかね?
>>16 逆に聞きたいが、その制御構成のデメリットは何だと考えてますか?
メリットを書くのは簡単だけど、書いても分かろうとしないでしょ。
だったら、デメリットと思う所を挙げてもらって、
それと対比した形でメリットを書きます。
18 :
デフォルトの名無しさん:2014/09/15(月) 08:12:14.07 ID:7pljNkXx
こちらが思う所のデメリットの対を書くのなら簡単ですね、分からないのなら結構です
分かってる方だとしても、わざわざそのような人を小馬鹿にした文章を書くような人から教わる気はありません
>>18 そうじゃない。
>>16で何を問題にしてるのか不明なんですよ。これの何処がデメリットと見てるのか。
その理由が分からなければまともに噛み合う返事は返せないだろう。
こっちが思いついた事だけ書いても、貴方がデメリットと感じてるのと的外れになったら不毛だろう。
例えばだ。
ループ制御に配列数を使うと、配列サイズの変更でかなりのロジック変更が起きる。
配列サイズの変更を繁茂に必要とする環境なら、考慮が必要だ。
UNTIL カウンタ > 配列数 じゃなく
UNTIL カウンタ > 区分A-TLB-END とか書く。
更には、テーブルエンドまで見ない場合もある。
テーブルサーチで見つければそこでループ脱出などの時も、
UNTIL カウンタ > エンドフラグ で抜ける。
提示したコードが曖昧なので、評価しようがないんだよ。
数字タイプの項目Nにゼロを入れる場合って、
「MOVE ZERO TO N」も「COMPUTE N = ZERO」も同じ?
>>16 その書き方でメリットがありそうなのって配列の数変わってもロジックそのものを修正する
必要がない、くらいじゃね?
仕事の場合、数字変えるだけだろって思うかもだがロジックそのものを変えない方に重きをおく
23 :
デフォルトの名無しさん:2014/09/15(月) 20:19:00.85 ID:Y+BqygTU
質問して返事が来たなら、然るべきリアクションをするのが礼儀。
質問して返答が気に食わんと、捨てレスするのは、どっちが小馬鹿にしてるのか。
小僧の質問レスはこういうのが多くて嫌になる。
>>21 なるほど。数字項目に「数字または数字項目」を入れる場合は、
MOVE文とCOMPUTE文のどちらを使っても問題無いということか。
数字項目以外と書き方を合わせるならMOVE文、
他のプログラム言語と書き方を合わせるならCOMPUTE文だな。
少し上でも「エンドフラグ」って出てたけど、
フラグとかスイッチって初期値ゼロで条件満たしたら1を入れてループ脱出という使い方が多いのに、
何故か数字タイプではなく文字タイプ(PIC X(1))にすることが多いイメージがある。
>>24 文字タイプのスイッチは危ないですよ。
初期化(INITIALIZE命令)しても空白になるので、”ON”、”OFF”、”1”、”0”とか入れとかなきゃならんのを失念すると、
スイッチをすっぽ抜ける事あります。
昔、初心者だった頃、それで数日悩んだ覚えが有ります。
基本、スイッチは数字タイプで取りましょう。
但し、スイッチがオンかオフか、明示的にコード化したい時もあります。(”ARI”、”NASI” みたいに読解生を高めたい時など)
副作用持たないならば、ロジックSECTIONの各先頭に初期化する習慣をつけると良いです。
スイッチならLOW-VALUE HIGH-VALUEの二択をオススメする
それ以外に複数の選択肢がいるなら表現にそったものを
27 :
デフォルトの名無しさん:2014/10/24(金) 00:14:41.82 ID:+wWmb0ng
COBOL2002って規格は作ったけど、実際使ってる企業はあるのかな?
見たことないね。85ばかり。
うちのシステムのソース見ると85より古いな。
END-IFやEND-PERFORMさえまともに使ってない。
それらは省略できるから書いてないのでは
一生懸命、俺は宮大工と自慢して、省略せず書いていたやつがいたが
その会社は一年後に倒産しましたw
>>30 書いた方が気持ちがいい、そういうもんだろコボラーなら
昔のステップ数稼ぎ
COBOLの仕事がドッカンと出てきたな
35 :
デフォルトの名無しさん:2014/12/19(金) 12:52:16.00 ID:JYrlm17r
IBM汎用機でバッチPGMのみの経験
汎用機でのDB経験なし
情報処理旧2種
日商簿記2級
こんなんじゃ雇わんか
>>35 いや、年数がモノ言うところもあるからあながち無理でもない。
案件内容と面接時のアピール次第だな。
面接は合格しようと考えず、不合格にならないよう考えろ。要するに、
・筋道立てて経歴を説明する。
・アホな質問しない。
・マイナスになる事は一切言わない。
面接官は何十人と来るコボラーを、優れた者を採用しようと考えて面接はしてない。
使え無い要素有りな者は全て×、と消去法で面接してるのさ。
37 :
デフォルトの名無しさん:2014/12/25(木) 11:44:26.87 ID:D1gJKcDI
>>35 今後プログラマになる予定なら
Javaとかオブジェクト指向で作れるようになることを勧める。
COBOLだけだと、金融系COBOL案件しか回されなくなる。
結果仕事が全然面白くなくなるし、転職のつぶしもきかない。
現在COBOL案件は金融以外でも多数あるのだけれど、下々の請負が取り合いw
39 :
デフォルトの名無しさん:2015/03/04(水) 22:13:18.64 ID:jopEltpH
既存のCOBOLソース見るとELSEの中に丁寧にネスト構造にして新たにIF文作ってるケースがしばしばあるな。
確かにCOBOLはELSE IF(言語によってはelif)が出来ないから三択や四択の条件ならそうしたくなる気持ちも分からなくはないが、
せっかくEVALUATE TRUEなるものがあるのに使わないのは勿体無いなあと思ってしまう。
昔はEVALUATEが無かったんだと思ってる。
>>40 どんくらい昔を言ってるのかは知らんが、少なくとも20年前にはすでにあったと思うが
3月になってからものすごくCOBOL、コボルの求人が増えた
頑張れ俺
COBOLのCODEを見たくない