情報処理にはＣＯＢＯＬが最高の言語である！

情報処理／定型的事務処理に限定すれば
Ｃ＋＋だろうがＪａｖａだろうがＣＯＢＯＬ
には勝てない。
　　　　　　　　　　　　　　反論不可！

確かにCOBOLの問題一番難関。落ちる人が多い。

ごめんなさい
情報処理試験じゃなくて
制御系とかゲーム系とかに対応した摘用分野としての
情報処理であります。

戦略なんかや業務の検討に使えないとアプリって言えない時代に、
コボルって定型業務しか出来ないんだ。
バッチファイルみたいなもんですね。
JCLでソートや抽出するフロー仕様書が何ページ分と同じ処理を、
SQLでやったら１行で書けるもんね。

スレのタイトルはややネタっぽい表現だが、内容的には
あながち間違いでもないと思われ。

大量バッチ処理には確かにCOBOLは向いているね。個人的には
PL/Iのほうが好きだけど。まあ、世間的にはどっちもどっちって
見られるのか・・・

>>4
学生？戦略や業務の検討だけがアプリなの？
膨大な顧客データをもとにDMなんかを発行するのはアプリじゃない
のかな？違うよね。そして例えばその場合、バッチ処理をするのに
わざわざＤＢにアクセスしなきゃいけないかな？もしそういう
処理がいくつもパラレルに動くとしたらＤＢに対する負荷はいったい
どれほどのものになるだろう。

キミはあんまり大規模なシステムってのを見たことないんじゃない？
システムにはフロントエンドからバックエンドまでそれぞれ
いろんな役割や適した形態ってのがあるんだよ。
あんまり頭ごなしに決め付けるのはよくないと思うよ。

反論あればどんどんカキコしてください。煽りたければあおっても
いいっす。

うーん、
これまでほとんどCOBOLで、弱型のCを１年、強型のPascal系を１年、PL/Iは遊び程度。
C++なんてお目にかかったことないし、ooには縁無し。

稀にこの板で、クラスいじって生産性倍増とかって読むけど、今の流行りの言語って
そんなにドラスティックな世界なんですか？

コボラーおやじでっす。
ＳＱＬって記述は短くて済むかもしれないけど、パフォーマンスが事前に読めない
から基幹業務にはちょっとつかえんなぁ。

そういう意味ではＳＱＬまんせーな >>4 はパソコンベースのしょぼいシステム
しか触った事がないと思われ。

哀れな奴（ｗ

>>7
>ＳＱＬって記述は短くて済むかもしれないけど、パフォーマンスが事前に読めない
>から基幹業務にはちょっとつかえんなぁ。
パフォーマンス読めます。それがプロの仕事です。
ＳＱＬが基幹業務に使えんって、あんた、いつの時代の人？

どうでもいいけどコボラーは井の中の蛙ばっかりで大嫌い。

オリ、COBOLかけん
あんなズラズラかかなきゃいけないのはスゴク苦痛
明日提出の読書感想文とか書いてる気分
そういえば作文苦手だったな(藁

俺、経験１０年の金融系システム屋さん
COBOL, C++, SQL, Java, Perl, php, VB
PDAからメインフレームまで。
これだけ仕事でやってきたが、最悪だったのはメインフレームのCOBOLだった。
はっきりいって、悪夢だった。

仕事としておもしろくない。だけど責任がやたらと重い。
デバッグ環境も、もう最悪。
ソースレベルのデバッグできる製品もあるけど、高くて買えない。
SYSOUTやコンソールにデバックのメッセージをシコシコと出して、電卓叩いて確認。
テストデータをいじるのも一苦労。
言語の効率も悪いけど、システムの効率もそら悪いわ。

レガシーなシステムは、COBOLしかないのもよくわかるけど、
新規案件でCOBOLつかってるのは、COBOLしか使えない人を使う場合だけしかないです。
もっと効率的な開発環境で作れば、パフォーマンスが落ちる分は、人件費が減った分をハードにぶち込めば、もっと安くて使いやすいものができます。
いまどき、メインフレームじゃないと処理できないものなんて、ほとんどないんだから。「メインフレームじゃないと」って、呪文のように言ってる奴がよくいるけど、
そういう奴に限って、中型メインフレームくらいしか扱ってないのよね。
大型UNIXを見てみなよ。中型メインフレームなんて、シャレにならないくらいのI/O性能出るうえに、同程度の信頼性あるから。
でも、UNIX系には一緒に心中してくれるようなメーカＳＥがいませんね。ちょっと寂しい。
俺は、メインフレームおさらばして、オープン系に移行したけど、移行して本当に良かったね。
ただ、リベートくれる業者は、メインフレームじゃないとね。
UNIX系だと、俺のような末端までリベートが回ってこない。
メインフレームの時は、末端の俺でもいい小遣いになったが・・・。

11に賛成！！えらい！
「情報処理にはＣＯＢＯＬが最高の言語である！ 」の「情報処理」の部分が足が地に付いてないというか、
浅薄。

でも、最近出た「Cobol++」ってすごいんでしょ？

> デバッグ環境も、もう最悪。
> ソースレベルのデバッグできる製品もあるけど、高くて買えない。
> SYSOUTやコンソールにデバックのメッセージをシコシコと出して、電卓叩いて確認。
> テストデータをいじるのも一苦労。
> 言語の効率も悪いけど、システムの効率もそら悪いわ。

そりゃ単に君の技量が足りないだけでしょう？
ツールに頼ってたらＣ等まともに使えんよ。

なれりゃ10万ステップも１週間！！（笑

Cobol++しってるか？>>出張３２

>>14
スマン！（汗"
全く知らん！！！
今はＣＯＢＯＬ完全無視状態でし

理由は、「ツマラン」「安い」「あほらし」です。 m(_ _;)m

#　配列はＤＢに向いて居りませぬ！！！(いい加減に判れよ！！！)

Cobol++なんてなるわけねーだろ（笑
ｽﾏﾝ

でも、Cobolでオブジェクト指向やってみようってことは聞いたことはある（念のため）。

ヤフーオークションで、幻の人気商品、発見！！！

今は無き「コピーガードキャンセラー」↓
http://page5.auctions.yahoo.co.jp/jp/auction/e5292701

ヤフーオークション内では、現在、このオークション
の話題で、持ちきりです。

>>17
いや、そんなことより聞いてくれよ！
cobolでＤＢインターフェイス可能にして、ＤＢから取得した情報を内部で集団化し転送してるよ。（もうアホかと！
で、取り込んだ情報を固定配列に記憶し「すげー」ってか？ (こ一時間悩むぞ！
でも、COBOLらー多いし、このツール最強！！
だけど保守考えれば最悪、これ諸刃の剣！！！

よって、COBOLでＤＢはお薦めしない。

>>17
ＯｂｊｅｃｔＣＯＢＯＬじゃなかったっけ？

>>出張３２
メタ化傾向の昨今に逆らってるわけ？

>>11
１０年も金融ＳＥやってそういう認識か？（ｗ
言語のせいにしているところが終わっている。

>いまどき、メインフレームじゃないと処理できないものなんて、ほとんどないんだから。「メインフレームじゃないと」って、呪文のように言ってる奴がよくいるけど、
>そういう奴に限って、中型メインフレームくらいしか扱ってないのよね。

やればできるって言うのと、業務として安心して運用できるっていうのを混同してるようじゃ、
本当に経験10年と思えない。よっぼどおめでたい仕事しかしてないんだろうな。


>俺は、メインフレームおさらばして、オープン系に移行したけど、移行して本当に良かったね。

こういう事に拘るところがすでにおかしい。
ＳＥとはどういう仕事なのかをよ〜くかんがえてみろ。
それとも１０年コレでメシ食っていてまだプログラマか？（ｗ

>>22
GSも含め外資金融は基幹まで含めすべてUNIXですが何か？

>>22
>業務として安心して運用できる
安心感のために従来技術に安住するというのはビジネスセンス無さ過ぎ。
なんで９０年代にメインフレームがそっぽをむかれたのか、よく考えよう。

今のコボルのシステムを全て再構築するには、
想像を絶するコボラ−の数を必要とするだろう。
コボル眼中無しって言っている君達
そのときには君らどうすんねん

>>25
ありがたいね。
そうなったら、大企業の人狩りが大量に発生して好景気になるからね♪
まあ私はオープン系やってるわ。

>>25
再構築するんだったらコボラーは必要ねえだろ。
運用コストがリターンを上回るような糞システムは全部捨てろ。
腐ったアセットはBSからとっとと切り放せ。
ついでにコボラーは自分の存在そのものが利回り負の資産だってことに気付け。

>>24
>安心感のために従来技術に安住するというのはビジネスセンス無さ過ぎ。
>なんで９０年代にメインフレームがそっぽをむかれたのか、よく考えよう。

そっくりお返しするわ。
いまでもメインフレームやAS/400が売れているわけを考えてみよう。

コンピュータシステムが安定している事が大命題である業務はいく
らでもあると思うが？
こういう考えはビジネスセンスうんぬんではなく、顧客に対する
責任感が欠如しと思うがどうよ。

もちろん、 >>23 みたいに例えばUNIXのシステムで、業務要件を満
たせるならいいと思うがな。でも、UNIXをそういう風に使うと逆に
高くつくと思うぞ。

適材適所がいいのでは？

>>28
>コンピュータシステムが安定している事が大命題である業務はいく
>らでもあると思うが？
安定のためにはメインフレームしかないという前提なの？
それ、痛すぎるよ。顧客に対する責任感うんぬんではなく、
戦略的発想が欠如しとると思うがどうよ。

戦略的発想というか、リスクコントロールの概念が欠如しているな。
システムで100%を達成するコストと、オフラインでオプションを買うコスト、
どちらを選ぶかは顧客次第だが、システムベンダの責任感は両方のコストを正確に
提示するというところに在って欲しいものだ。

わかっていると思うけど30はいわゆる極論ね。
システムで100%を達成することはできないし、ビジネスリスクを全てヘッジするような
オプションを買ったら利益を出すことはできないからね。

>>28
AS400が売れてるのは経営資産の温存のためだけだと思うのですが。
ASに関しては確かIBMではCの移行を推奨してるし。
金融系のCOBOLシステムについても膨大な資産の移行が出来ず
仕方なくCOBOLベースにしてるってのが実情では？
もちろん安定性云々では汎用ベースが一番だとは思いますが
コストパフォーマンスや今後の人材不足から
オープン系での開発を進めるのが妥当だと思うのですが。
もちろん汎用かオープンかを選ぶのはクライアントです。
その両方を的確に提示するのがSEの役目？
わかりきった話ですいません。

金融系に関しては、何やっても都銀のユーザは文句しか言わん。
オメーラ悪いこといわんから汎用機＋COBOLで乗り切れといいたい。

メインフレーム環境もオープン環境も両方経験したことあります。
なので、双方の言い分はどっちもある程度わかるつもり。

最近は確かにハイエンドサーバなんかの単体性能だけで見ると
メインフレームを代替してもよさそうなものが随分出てきてるけど
やっぱりミッションクリティカルな分野ではメーカーの保守体制
とかがまだまだだよね。
オープン系だと何か障害があったとき、原因がどこにあるか
分からないままってことがある（かもしれない？）けど、
メインフレームの世界では「相性が・・・」とかそういうわけの
わからない言い訳は通用しないからメーカーも原因追及や障害復旧
に必死。

ただ、確かに開発環境という意味ではメインフレームの世界は
あまりにもお粗末。誰か何かいいもの出してくれって感じするよ。
せめてステップ実行と実行中の変数の中身を表示できるように
なるだけでも相当開発効率アップすると思うんだよね。

>>9
禿同。
身の回りにいるコボラー、
いつもウットリ顔でcobolの良さ？を語る。

>>22
俺は、１０年たってもプログラマーだが、ユーザー企業には、SEだのプログラマーだという概念がないところもあるの。
ベンダーだと、一般的にSEの方が単価が高いので、全員SE状態だが、うちは内部の仕事だから全員プログラマーという名前。
一般的に言うところのプロジェクトリーダーまではプログラマーという名前で、プロジェクトマネージャーが上級管理職。
けっこう、変わってるでしょ。１１からすると異文化かな？
創業１５０年の老舗企業だから、横文字の長い名前はあまりない・・・。
いまどき、「上級管理職」っていうのもね・・・。

３６の書き込み、ちょっと書き間違い。
「１１からすると異文化かな？」　→　「２２からすると異文化かな？」

>>35
ﾜﾗﾀ
ウットリ顔っていう表現が、なかなかいい感じ。
ついでにその人たち、古女房の愚痴に見せかけたのろけ話をするように、
cobolの欠点を、「つらいよね」って感じで、いとおしく言っていませんか？

>>38　そんな感じ！！

彼らのウットリ顔を見る限り、ほとんど宗教の世界です。
參考書籍なりデバッグ環境なり、決して仕事しやすいわけじゃない。
それなのに「欠点もあるが、それが何か？」顔。

>>34
> 確かに開発環境という意味ではメインフレームの世界は
> あまりにもお粗末。誰か何かいいもの出してくれって感じするよ。

もう15年以上も前になるけど、各社独自のアーキティクチャで自社開発スタイル
に合わせたツール(ソースジェネレータ)を作ってるんじゃないの？
私も結構その手のツールを作って開発効率を上げたよ。(1/5〜1/10程度)
自社の設計スタイルや設計思想に合わせたツールを作って活用するのが基本です。
大組織になって来ると中々難しいけどね。

>>40
うちに、それあるんだよ。
ユーザー数が少ないもんで、名前出すとばれちゃいそうなの。だから商品名は勘弁してね。
うちのホストには、そのジェネレーターで作られたプログラムが、死蔵も含めて１万本。担当者はかわいそう。
COBOLを吐くジェネレータだが、担当者はCOBOLがわからない。そんな担当者が１００人。さらに、そんな担当者が毎年増殖中。
よって、そのジェネレーターから逃げられない。
そこから得られる結果は、バージョンアップ。
もうメーカーにしゃぶられ放題。
俺、それの担当じゃないから、不幸中の幸い。
それを思うと、まだCOBOLの方がマシね。

>>41
所詮は思考統一の産物だからね。
生産性・保守性・機能統一を追及して行くとどうしても弊害は出るよ。
結局、優秀な技術者を必要としなくなりその結果人材が育たない弊害が顕著になる。
もちろん思考決定側は別だけど人数が少なくて長期的に見ると弊害が多いと言える。
ここらの課題は如何することも出来ず、私は方法のていで逃げ出した口です。(社員さんゴメン！)
今は罪滅ぼしのつもりでその会社の責任者にオープン系による開発環境の構築方法を指導している。
私の踏んだ糧を、その責任者にも踏まそうとしているのか？
今となっては突き進むしかないように思う。

# 多少のロスが発生しても自由な思考でありたいね。

今までCOBOLで作った「資産」はどうなるんだ。
当然生かす為には、COBOLになるだろう。

誰が書いていも同じになる、素晴らしい言語だと思うけどね。

ある所で、DB２で、照会系のオンラインシステム（ＣＯＢＯＬ）を開発
してた事あったけど。
おそらく、同じようなシステムは、データ量が多くなければ、
ACCESSやSQLでできると思うよ。
その方がコストが下げられるけど・・。
ホストでやったくれた方が、お金が稼げるので。
私としては、ＣＯＢＯＬがいい。

>>36 = 11

>俺は、１０年たってもプログラマーだが、ユーザー企業には、SEだのプログラマーだという概念がないところもあるの。
>ベンダーだと、一般的にSEの方が単価が高いので、全員SE状態だが、うちは内部の仕事だから全員プログラマーという名前。
>一般的に言うところのプロジェクトリーダーまではプログラマーという名前で、プロジェクトマネージャーが上級管理職。
>けっこう、変わってるでしょ。１１からすると異文化かな？

うちもユーザー企業だが、社内にＰＧが居るなんてよっぽど本業が儲かって
いるんだな。とても真似できん。
本業の付加価値を高めるわけでもないシステム保守要員は外注すれば十分
だと思うがどうよ。
11はおそらくＰＧという呼称でＳＥ作業しているんだと思うが。

スレの本題からはなれてきたのでsage

金融系の国内勘定系は別として

外為系、情報系などは最近　ＵＮＩＸを使うところが増えてきた
これからこういった方向が加速するのか、またメインフレーム系
に戻るのかはまだなんともいえないといった感じですか

実際、ユーザーからしてみれは最終的な運用およびサポート面
でしか判断できないというのもあり
今時点では、メインフレーム　＋　ＣＯＢＯＬ　での運用が
一日の長があるとおもう

今後の展開がどうなるかは別として

>>43
>今までCOBOLで作った「資産」はどうなるんだ。
>当然生かす為には、COBOLになるだろう。

だからそれが腐ったアセットだと言ってるだろうが。
サンクコストに追加投資することほど馬鹿げたことはない。
その「資産」の運用コストを含めたROIを考えたことはあるかね？

>誰が書いていも同じになる、素晴らしい言語だと思うけどね。

誰が書いても同じになるなら中国人かサルに書かせりゃいいと思うがどうか。

>>45
その通り。ＰＧという名前で、上流から下流まで何でもするYO。
外に出さないのは、本業で使えないやつを放り込む部署だから。
外注すると乳母捨て山が無くなっちゃうよ。俺もその乳母捨て山に捨てられた人だけどね。
でもその乳母捨て山も、いごごちいいもんで、よその会社からの誘いもいくつかあったけど、そのまま住み着いてます。

>>43
>誰が書いていも同じになる、素晴らしい言語だと思うけどね。

今、個人的な課題が「スキルの無い人間には書かせない」ことなんだけどどう思う？
誰が書いても同じなのだと、玉石混交してリスクがコントロールできない。
品質とかスケジュール遅延とか作業者のモチベーションとかさ。
正直言って、最近の短納期・大ボリュームの仕事は人数頼みだと不安定すぎる。

今は、スキルのある人間に重要な部分が集中し、それでいて工数が維持できる
方法を模索中。

>>49を読み直したら意味不明だったので補足。

誰が書いても同じというが、作業には、量が多い・少ない、簡単・難しい、ミスの許容範囲が大きい・小さい、
などの性質があると思う。
難しいことは難しいことができる人にだけやってほしい。ミスできないところはミスしない人にやってほしい。
でも、誰が書いても同じ、ということは難しいところは誰がやっても難しい？わけで。
スキルで量をカバーすることもできないことになる。

とにかく、均質な状態によって得られる利点は、状況的に引き合わなくなってきた、と感じるのです。
誰が書いても同じ、ということに魅力を感じなくなったというか。
伝わらないかもしれませんが・・・。

COBOLﾏﾝｾｰな奴はいないのか？
意気地なし！

COBOLマンセーな人は、こんな休みの日にインターネットにつながる環境がない。
平日でも、インターネットと関係ない人が大多数。
だから議論などできない。

情報処理という一点においてCOBOL以下の言語はないだろ。
あるいみアセンブラが生産性においてCOBOL以下になるかもしれないが。

>>53
そこまで悪くないぞ。
決まり切った定型処理なら、Cよりも生産性はいいぞ。
自由が利かないので、変わったことが出来ないだけ。
かといって、今どきCOBOL使う意味もないが。

>>54
決まり切った脳味噌ならの間違いだろ？

>>55
Cの生産性はCOBOLよりずっと低いよ。(どんなに賢い奴でもね)

>>56
生産性は、なに作るかによるな。
COBOLでパーサ書けとか言われたら自殺したくなるだろ。
パーサってのも決まりきった処理だけどな。
そう考えると、COBOLってなんだ？と思うな。

>>57
以下のようなCOBOLならJavaでできる程度にはできる。
（パーサClassがあれば）
ttp://www.hitachi.co.jp/Prod/comp/soft1/cobol/product/oocobol/pccomow.html

もっとも上のurlは自分的にはジョークき分類している。（ｗ

現在のＩＴ技術は日進月歩。様々な言語、ＯＳ、ミドル、開発ツール
等々を駆使しないと食っていけなくなっている。
小生はとりあえず１５年間汎用機＋ＣＯＢＯＬだけで
十分すぐるほど、食わして頂いた！
たとえ今ＣＯＢＯＬが滅びても悔いはない。
ＣＯＢＯＬよありがとう！

>>57
そりゃ使用言語の特徴に合わないものを書け！って言ってるだけだな。
どちらにせよ、Ｃの生産性はＣＯＢＯＬよりも可也落ちる。
勿論、それだけ用途は広いしネイティブコードもアセンブラには劣るが
可也早い。
所詮言語なんてものは適材適所ってところでろうね。
10も20もの言語が使い別けれて初めて言えることだな。

>>60
http://www.atmarkit.co.jp/fnetwork/column/spec001/csharp.html
>現在作成されている大抵のプログラムは、理論的にはFortranでも記述可能なのである。
>にも関わらず、誰もFortranを使わない理由は簡単である。生産性が著しく低いのである。

WindowsにもCOBOLがあるが誰も使わない。理由は生産性が著しく低い。
汎用機でユーザアプリC言語を使わないのは、ユーザアプリにOSがアボンされると困るから。
実際そういうことはある。コボルコンパイラをかけた瞬間複数の会社が使ってた汎用機が停止。
その後そのコンパイラ使用禁止＆コンパイラかけた本人青ざめてた。

>>61
コンパイルしただけでマシン停止って・・・
んなことあるの？Ｃは経験ないからようわからんけど。

どうせ漏れは汎用機＋ＣＯＢＯＬまたは小規模ＶＢ＋ＯＲＡＣＬＥ
または自宅で遊びＪＡＶＡくらいしか経験のないＤＱＮだよ（泣

ゴメン>>62
イジメルつもりじゃなくて、流れの一部分に言及しただけだよ。
COBOLとJavaが出来れば最先端じゃない。

COBOLは書きやすい＆読みやすい言語だと思うよん。
メンテナンス考えるとこの「読みやすい」は非常に重要なのねん。

>>60　同意

言語は道具なんだから使える場所で使いましょ。
ナット締めるのに六角レンチ持ってきても無理っしょ。？
分類の違う言語で優れてるだのなんだのは非常にナンセンス。

しかし、メンテナンスなどユーザによる責任も大きいが、
PC（Win、Linux）、UNIXともに信頼性は低いなぁ。
無いと言ったほうが良いかもしれん。

保守性の高さと生産性の高さではCOBOLもなかなか。

しかし現在のVBの開発性の高さやOOPできる言語の
ある程度からの生産性の高さと比較すると優れているとは言いにくい。

個人的にはプログラマ向けの言語ではないと思う。
カプセル的に限定されていて範囲が限定されすぎている。
そこが生産性の高さにもつながっているのだが。

よし、生産性の高いコボルコンパイラを作って大儲けだ。
何、売れなかったとしても、
よーしパパ世界中のソフトをコボルで書き換えちゃうぞー。
コンパイラもコボルで書いちゃおかな。

そんな事より１よ、ちょいと聞いてくれよ。スレとあんま関係ないけどさ。
昨日、近所のマシン室行ったんです。マシン室。
そしたらなんか人がめちゃくちゃいっぱいで入れないんです。
で、よく見たらなんか垂れ幕下がってて、Ｓヨ一人月引き、とか書いてあるんです。
もうね、アホかと。馬鹿かと。
お前らな、Ｓヨ一人月引如きで普段来てないマシン室に来てんじゃねーよ、ボケが。
Ｓヨ一人月引だよ、Ｓヨ一人月引。
なんか親子会社連れとかもいるし。系列会社でマシン室か。おめでてーな。
よーしパパOOコボル頼んじゃうぞー、とか言ってるの。もう見てらんない。
お前らな、１５０円やるからC言語使ってろと。
マシン室ってのはな、もっと殺伐としてるべきなんだよ。
オンライン端末の向かいに座った奴といつ喧嘩が始まってもおかしくない、
刺すか刺されるか、そんな雰囲気がいいんじゃねーか。女子供は、すっこんでろ。
で、やっと座れたかと思ったら、隣の奴が、Javaで、とか言ってるんです。
そこでまたぶち切れですよ。
あのな、Javaなんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、Javaで、だ。
お前は本当にJavaを使いたいのかと問いたい。問い詰めたい。小１時間問い詰めたい。
お前、Javaって言いたいだけちゃうんかと。
マシン室通の俺から言わせてもらえば今、マシン室通の間での最新流行はやっぱり、
JCL大盛り、これだね。
ウェブサーバJCL大盛りオンライン端末。これが通の頼み方。
JCL大盛りってのはJCLが多めに入ってる。そん代わりコボル少なめ。これ。
で、それにウェブサーバオンライン端末。これ最強。
しかしこれを頼むと次からユーザのシステム課にマークされるという危険も伴う、諸刃の剣。
素人にはお薦め出来ない。
まあお前らド素人は、VB6でも食ってなさいってこった。

>>65
> しかし現在のVBの開発性の高さやOOPできる言語の
> ある程度からの生産性の高さと比較すると優れているとは言いにくい。

比較すること自体無意味です。
GUI & マルチスレッド & DBインターフェイス周りを考えると用途は全く異なると言えるからね。

> 個人的にはプログラマ向けの言語ではないと思う。
> カプセル的に限定されていて範囲が限定されすぎている。
> そこが生産性の高さにもつながっているのだが。

これは理解レベルが低い。
COBOLでも10万ステップを超えるプログラムも多数存在する。
ＶＢとて各種コントロールのイベント派生により処理不能な制御も多く存在する。
(コマンドボタン上で上矢印ボタン押下時に目的のコントロールに移動する等)

それと多くのＶＢプログラマのソースを覗いているが大方のソースはイベント制御が適切に行えていない
素人が作成したレベルであり、プロと呼べる程の技術者は非常に少ないのも事実である。
やはり経験や基礎学習が大幅に不足していると思われる。
これは、ＶＣプログラマやＣ++プログラマにも共通して言える。
まあ、関連する技術の幅が広く覚える量も半端じゃないから仕方ないのかも。

VBは確かに「とり組みやすい」と思うが、「開発性が高い」とは思えない。
むしろメンテナンス性や生産性はCOBOLの足元におよばないのでは？

JAVAの生産性はCと同等、と聞いてるのできっとその通りであろう。

事務処理はインテラクティブでなくてよいので、別にCやJAVAなんて素晴らしい
言語で書く必要はないんじゃあ？

だったらCOBOLでいいんじゃあないすかね？

> VBは確かに「とり組みやすい」と思うが、「開発性が高い」とは思えない。
> むしろメンテナンス性や生産性はCOBOLの足元におよばないのでは？

ビシネス分野で使えるほどに整理されたコードを記述する場合は「取り組みやすい」とはとても言えない。
ちょっとした入力でも１万ステップを超えるのが当たり前になる。
これは、VBで扱う各コントロールが発生するイベントに細かく対応した場合なんだけどね。
勿論、コンボボックス１つ取ってみてもそのままでは不便な為API関数を使って使い易いような独自な関数群を作ることになる。
このように十分な汎用性を踏まえて統一された開発環境を整備することがＶＢやＶＣでは必要となる。
で、上記の環境下で開発する場合の「生産性」は非常に高く品質も良い。
構築される機能と労力で考えればCOBOLより生産性が高いといえる。

但し、開発者個々に十分なスキルが無いと上記の環境も絵に書いた餅となるので注意がいる。

正直、コボルな文章です。>>68-70
冗長で、ワーキングストレージが大きくプロシージャが小さい。
細部が記述できてないというか、今一歩詰めが甘いです。
生産性が悪い文章ではないでしょうか？

＞但し、開発者個々に十分なスキルが無いと上記の環境も絵に書いた餅となるので注意がいる。
スキルも重要だけど、ドキュメントも欲しいな。

>>71
自分で読み返しても、確かにそうかも...
ま、コボラーだから仕方ないか。

>>70
入力系の制御は確かに大変ですね。
と、いうかVBの柔軟さは真似できないですね。

ただ、webページに良く見られる(主観)ように
　一画面分全部入力＞ＯＫボタンクリック
なんつー入力してサーバで動く処理は
COBOLで充分じゃあないの？と思う今日この頃です。

某Ｎ社(だけでないと思うけど)のエミュレータ使って、
汎用機に接続して、実行／送信キー押してた頃が懐かしい。

>>71
俺的に良しとするCOBOLは、ロジックを短くしその分データ定義に記述させたもの。
だから「ワーキングストレージが大きくプロシージャが小さい」COBOLは良しの部類。

>>72
ドキュメントはＤＢ処理＆GUIが必須となるＶＢのほうが整理し難いですね。
特にＤＢなので項目だけに意味を持つのではなくレコードに意味を持つケースが多く
この辺りを設計者が手抜き無く定義し資料にまとめる必要があります。
しかし、現状の設計者の多くは「顧客様が決めること」と安易に解釈し定義を怠る人が多いのも事実です。

>>73
画面単位のやり取りならばＶＢでもイベント記述は殆ど必要としません。
単に入力桁数や入力可能字種の設定などはAPI関数を使用して作った関数を用意しとけば非常に単純です。

勿論、その後の更新系も大差ありません。

>>74
必要なワークエリアは別けて取るほうが良いでしょうね。
しかし、プロシージャを極端に小さくするのは保守や汎用性を大きく損なうので
お薦めしません。
コードが同じ個所があっても、機能として分離されてるならば別のルーチンに別けたほうが良いでしょう。

COBOLスクリプト？
プププ・・・氏ね！

>>56
同じ仕事でも、COBOLの方が非常にたくさん時間掛かるから
それだけ多くユーザーから金を絞り取れるってこと？
確かにそれはあるな。

かつてCOBOLでＣＡＤｼｽﾃﾑ作っちゃたひと知ってます、わたし。

技術は変わっても昔からやらせたいことはかわんねーんだ。

COBOL上等　ところでなんでこの板はmainframer系がおおいんだ？？
オマエらヒマなんだろ？あん？

オープン系が多いの！
汎用系はインターネット接続環境ないから、いないことになってる

>>78
CADと言っても幅が広いからね。
かく言う私も作ったことあるよ > CAD (各種ダンボール箱設計図面等)
勿論、CAMへの情報伝送＆実績受信含む

「なんでCOBOLなんかで作っちゃたんですか？」
「コボルしかしらなかったんだ・・・（恥」
って、恥ずかしいこと、えらそうに自慢するか・・・
>>81

>>82
その当時は、あるメーカーの子会社やってたから商売上の戦略でCOBOLで開発した。
とは言え、部分的にはアセンブラ使ってたけどね。

本当に出来るやつは言語の優越や好き嫌いなんて語らないよね。

はあ？>>84
本当に出来るやつは言語にこだわりがあるし、言語を作ることが出来る。
C言語はUNIX記述用に作られたし、今月のC魔蛾にJava作ったやつのインタビュー載ってた。
P.JプラウガーなんかのプログラマがC++のSTLなんか作ったし。

「本当に出来るやつは言語の優越や好き嫌いなんて語らないよね。」と
言うのはブビﾁｭｳだけ。

>>85
それ間違い！
単に暇か好き者なだけです。(業界常識)

業界常識でもナンデもよいがさあ、
ブビﾁｭｳや子ボラーが雑誌に載ったり本書いたり出来ないだろうし、安心してくれ。

本当にできるやつは言語を信奉なんてしないし、信奉している言語以外を
使っている人を貶したりしないよね。

言語を信奉するやつとはブビﾁｭｳや子ボラー。
他言語にはうつれないって。

出来るやつは、言語による製品の仕上がりや生産性を計るから
言語やPGにウルサイ。

言語を信奉するやつとはブビﾁｭｳや子ボラー。＜C信者もな（ｗ

日本語COBOLってないの？

ある。でも使うと子ボラーにさえヒンシュク買う。>>91
ま、コボルとはダサイ文化ですね。
コボル＝目立＝汎用機＝ダサイ
というイメージ。

>>89,87,88,90
> 出来るやつは、言語による製品の仕上がりや生産性を計るから
> 言語やPGにウルサイ。

その考え方はまだまだ素人のレベルだな。
我々はプロなので目的にあった言語を推薦こそするがこだわりはしない。
差別化の意味もあり単に生産性だけで言語を選ぶこともないし一見して
不適合な言語でも使えと言われりゃ開発に必要な素材探しや裏技も使うよ。

言語に拘り過ぎるのも幼稚なら生産性だけに拘るのもまた幼稚なり！ってね♪
もう少し前向きな会話をされたし。

>我々はプロなので目的にあった言語を推薦こそするがこだわりはしない。

カワイソウな受託ソフト。コーダーという最下位層。

>>94
そのような短絡的結論を見出すのも幼稚だな。
「差別化」ってキーワードの意味を全く理解していないところがガキっぽい。

>91
項目名は日本語使えますね
　命令自体日本語になると返ってみづらくなですか？

>>95
読み漏らしてるのは93の方。
89が生産性マンセーと読み間違えてるようだ。
89では「言語による製品の仕上がり」や「生産性」となってる。

>>97
同じことだよ。
一見して仕上がりに差が付くように見えても裏技等である程度は補正出来る。
言語の差だけに重きを置くのは愚の骨頂。

>>98
補正しきれない言語があるのを知らないみたいだね。

>>99
お子様じみた反論はされないことだね。（笑
差があったにせよ、戦略や差別化優先で劣る言語を使う場面は結構多いさ。
君は経験が浅いか、それとも井戸の中の蛙君じゃないのか？
世の中はもっと広いぞ。

マッサラな所から理想を追い求めて作り出す。
って時ならリソースや工数や目的で言語選べるし、
そんな時は自分の好き嫌い含めて拘りたいなぁ。

でも、実際に仕事等で、複数人でやるものなら、
過去からしがらみや、クライアントの意見や、会社の方針等で、
既にきめられた枠内でより、良い状態を作り出さなきゃならない事も多いわなぁ。
そんな時は、その枠が最高だぁ〜と自分を信じ込ませるってのも判るよ。
つ〜か、身に染みて（;ｗ;。

そういう意味で１に同意。

ここに来て、COBOLヤヴァイね。
過去からあったものは突然は無くならない、というのは原則だが、
衰退して消えつつあるように見える。

日本IBMがメインフレームの新機種，“COBOLが使えない”安価なOSも用意
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20020220/3/

Javaプログラマも単価が安くなってきてるから
もうCOBOLの活躍する場はなくなりはしないが
減る一方だと思う。

COBOLが安定してるのは文法が最小、外部リソースもファイルだけ、実行時の安定性はポインタ無し。
他のリソースにアクセスするには閉じたものをリンクする形。
Javaの言語も最小であり、JNIで外部リソース、ポインタ無しだから、
何気にJavaってCOBOLの派生かもしれない。
派生言語が出来たおかげでCOBOLが死ぬのかも。

>>19
超遅レスだけど
おれ、ほぼそれと同じもの作ったことある・・・。

ここは１０年前のスレですか？

お金の計算をJavaやCにやらせたくないな。

企業の基幹業務システムには絶対の安定性・信頼性が必要なんだよ。
あー、サーバーダウンしましたねーとか言ってる場合じゃないんだよ。
ミスが許されないのね。
それこそ、ワンミスが命取り。莫大な損失に繋がる可能性がある。
そんな中で新たに導入する「基幹」のシステムには
やはりメインフレームでしょ。
こんな言葉は知ってるよね？
「既知の技術と枯れた手法が一番の成功への近道」

>>104
> COBOLが安定してるのは文法が最小

は嘘だろー。COBOL の予約語の多さにはまいったぜ。習いたくないねー。

　　　　　　 　 　 　 　∩
　　　　　　　 　　　　 | |
　　　　　　 　　　　　 | |
　　　　　 　　　　　　 | |
　　　　 　　　　　　　 | |
　　　 　　 ∧＿∧.　 | |　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　 　（　´Д｀）／/　　＜ 先生！　ここだけ時間の流れが違います
　　　　　 ／ 　　　　/　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　 / /|　　　　/ 　　　　
　 ＿＿| | .| 　　　 |　＿_
　 ＼　 ￣￣￣￣￣　　 ＼
　　||＼　　　　　　　　　　　 ＼
　　||＼||￣￣￣￣￣￣￣||￣
　　||　 ||￣￣￣￣￣￣￣||
　　 　 .||　 　 　 　 　 　 　 ||　

＞企業の基幹業務システムには絶対の安定性・信頼性が必要なんだよ。
　企業の基幹業務システム構築＝ビルや橋梁の建築現場
って感じですね。美しくないが、失敗が許されない現場において
大勢で共同で労働し、皆でブロックを積み重ねてゆくようなイメ
ージ。ＣＯＢＯＬで大規模開発ときくと、そういう印象があります。

自分はオープン系オンリーですが、枯れた環境と使い古された
ライブラリ類が整理されているところなどは、正直羨ましいと
感じることが多いです。こちらは環境が変わると、かなりの部分
共通系も再構築が要りますから。
言語としてのＣＯＢＯＬを見ると、シンプルという点が利点で
もあるのでしょうが、関数という概念がないために、少々大き
めなプロシージャになると、記憶域の管理に問題が出てきます。
構造化しても、変数が常に大域レベルで存在しているので・・
最新のＣＯＢＯＬって、そういう部分は改善されているんで
しょうか？

最近のＣＯＢＯＬはポインタも関数もあるぞ。

>>108
>企業の基幹業務システムには絶対の安定性・信頼性が必要なんだよ。
>あー、サーバーダウンしましたねーとか言ってる場合じゃないんだよ。
>ミスが許されないのね。

思考停止野郎ﾊｹｰﾝ。
保守運用コストが収益を圧迫して会社を潰したとしたら
システムが安定稼働してても何にもならんよ。
クレジットリスクも含めてリスクは計量するもの。

それ以前に絶対の安定性・信頼性が必要なのにコボラー使っているのが
変じゃないか？（藁

>>109
実際につかうのなんて
かたてですむんですよ　予約語なんて

>>111
基盤系のオンライン処理だと
設計でカバーが基本になります
ＩＦとして引き継ぐ形で領域を共通化することにより無駄な領域
を作らないようにとか

>>112
ポインタについては最近でなくてもある
でもそういった処理はだいたいＳＲ（関数？）化して隠す

いずれにしても小細工をするのはオンライン系の処理ですね
バッチ処理については大体１ＪＯＢステップで１ＰＧ

>>116
116さんはいかにも経験者という感じですね。
金融機関なんかの勘定系を経験したことがあるって感じがする。
111さんへのレスを勝手に補足させていただきます。

オンラインでは入力メッセージの展開〜入力チェック〜ＤＢチェック、更新
〜出力メッセージの変換までの一連の流れを１タスクで実施します。
で、そのタスク内で閉じたユーザープロセス空間専用の領域に各ＰＧで
共通に使用する領域を確保して、各ＰＧで使いまわします。ちなみに共通領域は
タスク終了時点で解放されます。

で、その領域の共通化にはポインタが不可欠です。なぜならメモリ上の共通領域
各ＰＧで引き継ぐ際に、その共通領域の先頭アドレスを参照することが
必要だからです。逆にいえば、ポインタなしでは前述の共通領域をタスク内で
引き継ぐという処理方式は実現できません。


・・・なーんて、ずいぶん昔の知識を引っ張り出して偉そうに書いちゃいました。
間違いあったら突っ込みいれてください。

COBOLってさ、事務計算用途に向いているって割には
数値・文字列操作の組み込み関数が弱くない？

例えば次のような操作ってCOBOLではどうやってやるの？

１．ある文字列が代入されている変数から先頭２文字を取り出す
２．ある文字列を16進数として参照する

例えばＶＢでこれらを実施する場合、
１．RETURN = LEFT(VAR,2)
２．RETURN = HEX(VAR)

ってやると思うんだけど、COBOLでは？
あんまりCOBOLって知らないのでもしかして基礎の基礎かもしんないけど
誰か教えてくらさい

基本的にREDEFINESを使うかな。
２はPACKED DECIMALでみればいいのかな。やったことないけど。

PACKED DECIMALじゃないや。ｽﾏｿ

>>118
２．ある文字列を16進数として参照する

基本的に対応する関数は用意されていないから、
ルックアップテーブルを作って対応することになる。

http://www.coboler.com/

>>118
１）は簡単　ＶＡＲ（１：２）で先頭２バイトを取得することができる
２）はＲＥＤＤＥＦＩＮＥＳでしょう

部分列参照か。。。すっかり忘れてた

>>123
ちょっと待ってくれ！！
なんだそのVAR()って関数は？そんなのあったっけ？
しかもコロン(:)を使うなんておよそ、COBOLの文法っぽくないし。
おれもREDEFINESしか方法はないと思ってたが、
それともおれの知らない間にCOBOLも言語拡張されたのか？

誰かおしえてん。COBOLなんてもう何年も触ってないからホントの
ところが知りたいよ。

なんかうわさでは次の規格のCOBOLでは、PG内の関数やらポインタやらも
サポートされるらしいね。何を今さらという感じではあるが・・・
他の言語ではとうの昔に使われているのにねぇ。もう十分すぎるほど
枯れきった言語なんだから無理やり変に拡張しないほうがむしろいい
と個人的には思うのだが。

てゆうか、ｺﾎﾞﾗｰが扱えるJavaという言語が出来たからもうCOBOLは要らないＹＯ！
COBOLとその資産（ｺﾎﾞﾗｰか？）はJavaに継承されました。

ＸＭＬＰｒｅｓｓＶｏｌ５に基幹業務システムにおいてなぜＣＯＢＯＬが君臨してきたか
書いてあったから読んでみてよ。

項目くらい書いたら？>127

>>128
ＣＯＢＯＬの重要性は「データベース、端末、プリンタ、ＭＯＭを包含した伝票処理
フレームワーク」
って書いてありました。

’ＣＯＢＯＬでは、伝票をレコードとして扱います。ＤＡＴＡＶＩＳＩＯＮで定義したレコードを
そのまま画面入出力、データベースへの格納、印刷、データ転送にレコードＩ/Ｏという
形でプログラミングできることに意義があったのです’

Ｊａｖａは帳票出力が弱い、と指摘されていましたが、いかがでしょうか？
（ＣＯＢＯＬは帳票定義を利用するらしいですね）

>>125

部分列参照という言葉を知らないのでしょうか？
１０年以上前からこの仕様はありますよ。
ただオヤジコボラー（４０代以上）は知らないと
思います。

125はコボラじゃないでしょ。
説明するとVARは関数じゃなくてこの場合文字列変数。
で、VAR(1:2)ってやると、VARの１バイト目から2バイト分参照するという意味になる

こういうスレが立つと叩き屋が出現するな。
最近javaを勉強させられてるが、素晴らしいね。
DBもSQL使えば一発だもんね。
こりゃ騒がれるわけだ、と感心したよ。
けどやっぱり基幹定型業務には向かないかな。
極端な話、経理系のシステムを「javaでやりましょう」って
提案したら、アフォかと言われるよ。
別に１つの言語に統一しなきゃダメってルールは無いんだから
仲良くしよーや。

１５年くらいやってないが、
move space to とかおおざっぱな命令はすきだな。

最近、会社のCOBOLを面倒みさせらることになった不幸者です。

構造体の子変数名を参照する時って、Y OF X とかって書かないと
いけないの？
例えば

01 X.
03 Y1 PIC(01).
03 Y2 PIC(02).
05 Z PIC(01).

っていう構造体のY1、Zを参照する時に、Y1やZが他の構造体と
重複してて、一意参照できない時って
Y1 OF X　とか　 Z OF Y2 OF X　とかって書かなきゃいけないのかな？
なんかマニュアル読んだらそれっぽく書いてあったんだけど

SQLであるスキーマに属するテーブルのある項目を参照する時は
スキーマ名．テーブル名．項目名
というようにレベルの高い順に記述するでしょ？それがCOBOLって
どうも逆になってるようなので疑問に思いました。しかもOFとか
使ってていやに冗長な記述だし。

どなたか教えてくださいませ.

>>134
＞それがCOBOLってどうも逆になってるようなので疑問に思いました。
＞しかもOFとか使ってていやに冗長な記述だし。

MOVE TO で気づけよ。

言い訳しておくと、英語の自然言語表現を目指して開発されたらしいから、
まぁしゃーないってことなんじゃないかなぁ？あの時代に良く作ったよって
感じ。

>>132
叩き屋ではないが、

>けどやっぱり基幹定型業務には向かないかな。
>極端な話、経理系のシステムを「javaでやりましょう」って
>提案したら、アフォかと言われるよ。

基幹定型業務に向かない理由は何？

>別に１つの言語に統一しなきゃダメってルールは無いんだから
>仲良くしよーや。

教育コストや保守コストなど、規模の経済があるので
１つの言語に統一した方が競争力が得られるね。
というわけであんまり仲良くしたくないなあ。

>>134
01 X.
03 Y1 PIC(01).
03 Y2 PIC(02).
05 Z PIC(01).
こんな定義はできない。ＣＯＢＯＬを組んでコンパイルした
ことのある人間なら一目瞭然。
おそらく学生かそれよりも年下の人間だろう。
ＣＯＢＯＬコンパイラがついたＬＩＮＵＸだったら１万円前
後で手に入る。それすらも手に入れられないなんて。

何だか偉そうなやつだ

>>136
やっぱり信頼性だよ。
何百万レコードを夜間バッチで処理しておいて、さらに必要書類も発行する。
汎用機だったら当たり前にできることだけど、オープン系はやっぱり一抹の不安があるし、弱い気がする（俺の経験不足だが）
「そのリスクも考えてコストパフォーマンスを考えろ」って意見もあるし、全くそのとおりだと思うけど、万が一が許されない業務もあるしね。
それに今が旬のjavaも流行物かもしれないし。

>教育コストや保守コストなど、規模の経済があるので
>１つの言語に統一した方が競争力が得られるね。
もちろん。
それで理想のシステムが構築できればね。

学校でコボルやってる。　かなり楽。

>>139
おいおい。汎用機vsオープン系の話じゃないだろ。
Javaという言語が「基幹定型業務」に向かない理由とやらを聞いているんだが。
企業分割や事業部スピンオフの流れが今後加速するとしたら、
COBOLで給与計算やってる場合じゃないと思うんだがどうか。

バッチ、定型業務にはCOBOLもいい。
また、プログラマーのスキルによるコードの違いが少ないのは非常にいい。

言い方を変えると、自分で工夫できる範囲が少ない。
よって、ツマランので自分はCOBOLは嫌い。人に作らせる分にはいい。

>>141
汎用系がＣＯＢＯＬ一辺倒である大きな理由は「開発要員」にあると言えますよね。
Javaであれなんであれ環境の進化に追随するだけの言語が世に出て汎用系もその言語
へと開発環境をシフトして行くのが自然であり望まれる状況だよね。

ですが、膨大な需要を抱え技術者確保に翻弄され続けてきた業界のつけ(技術者の慢性技量不足)が
重たく他言語へのシフトを拒む大きな壁となっているのが現状です。

技術者の技量を磨くのではなく、生産性最優先の分業化を推し進めて来た結果が
技術者として不完全な人員を数多く作り出してしまったと言えるでしょう。

ここへ来てオープン系が大きく躍進する中で抱える大量の技術者をオープン系にシフト
出来ない現実はこれらの事実を裏付ける結果となっていますよね。

>>143
いや むしろ 事務所管側が オブジェクト指向的な
業務分析ができず、トランザクション的な業務分析に
とどまっているからでしょう。

COBOLのPGのOOL系言語の移行など半年もあれば
すべて可能と思いますよ

誤 OOL
正 OOA

スマソ

いいよね。ＣＯＢＯＬ、英語の大文字だけで小文字は使わないってところが
アナクロの匂いプンプンでステキ。

>>144
私も最初はそのように考えていました。
はっきり言って言語のシフト等は陳腐なコンバータが一つあればこと足りますからね。
ですが現実は違いました。
オープン系の需要が大きくなってるにも関わらず主要企業の要員シフトが
計画通り進んでいないのです。
結局、新規採用で一から技術者を育てる等と言う非効率な対応になってる訳です。
そして、設計のみ旧技術者の設計技量を期待して配置する構図となり今日に至っています。
それによってコードの読めない設計者が数多く出現し設計のアンマッチによるトラブルを
数多く作り出しているのが実情でしょう。

勿論、汎用機系には非常に優れた技術者が数多くいることも事実です。
ですが、汎用機系に携わる人員総数を考慮すればその割合は非常に小さくオープン系に
シフトするなどの余裕が全く無いのも事実です。

これらのことを踏まえれば、オープン系も熟練した技術者が非常に少なく
育っている要員の技量もこれまたお粗末であると言えるでしょう。
このことも、オープン系が爆発的に成長しない要因となっています。

>>137

COBOLは 文法の縛りは とっても緩いです。
むしろ、あなたの現場に置いてある キャビネットにある
コーディング基準を熟読することを お勧めします。

モジュールに特有な ローカルな変数(ワーク、カウンタ、スイッチ)と
DBインターフェースなどのグローバルな変数、
または、共通コピー句や共通トランザクションエリアなど
とるエリアの目的によって、コーディング基準が異なると思います。

たぶん ローカルな変数であれば ローカルな変数である
接頭語(または接尾語)をつけ、OF修飾なしで用いる旨
規定してないですか？

モジュールを超えて共通的に使う変数であれば
たとえモジュール内でユニークであっても
OF修飾して使うように規定してあるでしょう？

まずは 周りのうんちくじじい と 仲良くしてそこらへんを
身に付けてください

(COBOLってさ、 嫌いじゃないけど ウンチクじじいと
仲良くしなきゃいけないのが すごく うざいよね！！)

>>147

>それによってコードの読めない設計者が
>数多く出現し設計のアンマッチによるトラブルを
>数多く作り出しているのが実情でしょう。

ふ〜む
それって ひょっとして おれのことかも
実に 重いコメントです。

COBOL時代にも コードの読めない技術者は
多かったが(いや 逆にコードを読めないことは誇りですらあったが…)
現在の技術的な過渡期においては それが 業界全体の
足かせになっているのですね

あしたから 仕事の仕方をかんがえてみます。

>> 146

もし あなたが IBMのOS390(またはMVS)をつかっているのであれば
CTRL ＋ F3 をおしてミソ

表示されている 小文字が読めるようになります

入力したいのなら 16進数で入力してミソ
( 英小文字とカナ半角を共有している コード体系がいかん！！
と いうのであれば たしかに おっしゃるとおり）

>>144
ご親切な回答ありがとうございます。
２ちゃんには珍しいくらいのマジレスですね。

で、例題に挙げた変数宣言は確かに間違ってました。
実体のある（桁のある）親変数に従属変数は宣言できない
ですもんね。これは完全に自分の書き間違いでした。

んで、なんで今回のような質問をさせてもらったかというと、
実は、自分は以前に汎用機でＰＬ／Ｉという言語を３年ほど
使ったことあるからです。COBOLを見始めた当初、なんとなく
ＰＬ／Ｉに似てる言語だなぁと思ったりもしたのですが
よくよく見ていくと細部においてＰＬ／Ｉよりもかなり融通が
きかない言語だなぁと感じてきたためです。
（典型的な事務系のオンライントランザクション処理やバッチ処理を
構築する分にはおそらくあまり大きな違いはないと思いますが、
実はＰＬ／Ｉは事務計算のみならず科学技術計算、果てはＯＳ
の記述までやろうと思えばできてしまう言語なので、実は多機能）

以上、長文ｽﾏｿ

あげ

でも、オブジェクト系にはかなわない。
信頼性が無いという人も多いが、同じ機能のものならオブジェクト系で作った方が信頼性高い。
だってソースが小さいんだもん。バグも少ないわな。
ただ、コボラーの人がオブジェクト系をやっても無茶苦茶になるだけだが。

JCLの長所が見出せません。

資格の公平性を考えれば、ＣＡＳＬのみに統一するべき。

スパンの長い仕事（２〜５年）にモジュールの再利用がどこまで効果があるか疑問。
そういった意味でオブジェクト指向の利点を一つ利用できないような気が。

>>153
>同じ機能のものならオブジェクト系で作った方が信頼性高い。
うん APIをたたいたり するなら
COBOLは 絶望的に冗長なコーディングが必要だよね

でも 基幹系のインターフェースを除く部分の
コーディングでは、皮肉なことに
その冗長なコーディングのおかげで
抜群の保守性を発揮するのも事実です。

まあ 超巨大基盤システムでなければ インタフェースと
それ以外の部分を分けて構築することは ないのだけど

>>153
言っていることはよくわかる、だがここでは場違いと思うよ。
ここまで話が噛み合わないとはね・・・・。

>>157
あんたオブジェクト系の意味わかってない。
オブジェクト系になればAPI叩かないっていうところをみると、
あんたはWindowsでMFCなPGでしょ。それとも、VB?

>>157
昔、某汎用機系に関わってましたが、確かに’継承’などの入り込む余地なし、
といいますか…。

コピペ多用して、似たような関数量産しますね、確かに

まじ？

まじでしょ

問題は cobol　ではなくcobolしか使えない人達なのです。
そういう人達は年功序列で給料があがってきた時代をすごしていますので
ものすごい労務費を食ってしまいます。でもリストラしようにも、地位も
ある程度管理職になっていますのでなかなかできません。リストラされるのは
主として現場で作業をするひとです。
もう少し、日本の不況が進行し、cobol専SEの尻に火がつかないかぎりは
まだまだ、のさばりつづけるに決まっています。

>>163
年功序列賃金体系は賃金を最初の内は低く押さえその分高齢者になってから厚く
支給する方式です。
つまりは、賃金遅延払い方式と考えて下さい。(つまりは会社が社員に金利なしで借金してる訳ね)
でだ、問題なのは「ベア」です。
しかしこのベアもここ15年間は非常に低く押さえられていますから、
結局、35-45歳の人達が一番損をしている計算になります。

日本人には、ＹＰＳ ＣＯＢＯＬが一番！！

HITACでしょ？でも、
COBOL専でしたけど、今はそれでは、やっていけないもんで．．．
結構努力してますよぉ

俺コボラーだが、こないだヘルス行ったとき
ヘルス嬢がコボルなら組めると行っていた。
学校で習ったらしい。
泣きたくなった。

>167
超笑った。
確かに誰でもできるわな。

>>167
笑ったよ

>>167
さっさとほかの言語をおぼえなよ。VBでもJAVAでもC++でもなんでもいいから。

うちの高校（工業：情報科）はCOBOL一筋。
みんなコボラー。　わりと簡単で初心者にはオススメだと思うのだけどどうでしょうか？
個人的にはC++が分からん（鬱）

たいていの人はcobolが出来れば
どんなlでも対応できる。（たぶん･･

http://www.moumusu.com/rankem.php?id=mune1111

ＷＡＯ！

俺はＰＬ／Ｉが好きだ。
ＡＤＡもいいぞ、だれもその全貌を知らないが。

>>165
YPS COBOL...
165以外に使ってるとこあるぅ？

２１世紀になってもＣＯＢＯＬ使ってるなんて７０〜８０年代にどのくらいの人
が予想しただろうか・・・
パソコンがこれほど高性能になることを予想できた人間と同じくらい少なそうだ。

>>167
商業高校ではＣＯＢＯＬかＢＡＳＩＣを教えるよ。全国商業高等学校協会というと
ころが主催で、商業高校の生徒を対象にＣＯＢＯＬの検定試験まである。
ちょっと偏見的な言い方になってしまうが、ヘルス嬢などDQNが多いだろう。
商業高校＝DQNとすると、ＣＯＢＯＬできても不思議ではない。
元珍でＣＯＢＯＬできるやつもいるんじゃないか。

ﾊﾞｸﾞﾚｽCOBOLってのもあるらしい。
ﾊﾞｸﾞが無いのか？

>>177
それ、富士通の言語。BUG LESSではなく、BAGLESが正しい。
罫線が書かれている表に日本語でプログラムを書くイメージ。
COBOLの面影は全くなし。
COBOLがわからなくても業務プログラムが書ける。
代表的な大口ユーザーは総務省（郵便貯金）。
ようするに、COBOLすら使えない糞が使う言語だ。
このスレの内容から察するに、ﾊﾞｸﾞﾚｽﾌﾟﾛｸﾞﾗﾏｰの俺はヘルス嬢以下なのか？

>>178
総務省のシステムってなんだか凄そう！
BAFLESって実はすごいんちゃうの。

>>179
総務省（当時は郵政省）がそれを選んだんじゃなく、競争入札で不治痛が落札して、
その不治痛が押しつけたのがBAGLESじゃないのかな？
COBOLにしない理由は、BAGLESにすることによって囲い込みが出来るから。
安値入札は不治痛の得意技だったから、囲い込みを完成してから搾り取る気かな？

>>180
HOST上でcobol変換するんじゃないの？
だったら 囲い込みにならないとおもわれ

>>181
MOVE 10000 TO AGDETFHJLVHJET4RYHLERJTHAL2ERD
こんなソースをスラスラと読むことが出来るヤツはスーパーマンだ。
COBOLに戻ろうとして手持ちの資産が全部上記のようになったらどうする？
戻れるわけないんだな。

>>180
ひょっとして、180は会社でレアチーズケーキをよく食べてるお前か？

バレた？

BAGLESってベーグルパンのベーグル？

ここは富士通の宣伝掲示板か

いまどき不思議なスレですね。
私もコボラーですけど･･･最高といってのける自信がすごい。

ＣＯＢＯＬ７４　と　ＣＯＢＯＬ８５
の違いが、わかる人は、ネスカフェ・ゴールドブレンド？？

>>1
ＰＬ／１なら勝てる？

>>185
いいえＮＥＣの宣伝掲示板です。
ＩＤＬ２マンセー

わかるで〜＞＞187
でわ、ゴールド様と、呼んでいただきましょう。
（って、言うほどの違いはないよ。
　特にＰＧには、意識する必要もないレベルだ。）

COBOLは事務処理言語かもしれないが、
最近のCOBOLの仕事はシステム開発じゃなくて、
事務そのもののような気がする今日この頃。
簡単なんだから、使う人（エンドユーザー）が、
好きに変えてよ。エクセルのマクロより
簡単だからさぁ。

cobolが最高かは知らないけど。
コボラーが叩くのに最高の素材であることが証明されました。

MSX-BASIC
♪ひぃ〜とびとのひっとびっと♪

>193
聖子よりちょっと賢いパソコン♪
なるほどそのとおり。

IDENTIFUCATION DIVISION.
ENVIRONMENT DIVISION.
DATA DIVISION.
PROCEDURE DIVISION.

さああ、懐かしがってくれ

うーん懐かしい。。。
｢IDENTIFUCATION｣
でもｽﾍﾟﾙどこか違っているような気がするが、気のせいか？

>>196
気のせいじゃないよ。　IDENTIFUCATION
　　　　　　　　　　　＝＞　I
久しぶりに昔のソースを見てしまった（ちょっと思い出して鬱）

ずれちゃった（U＝＞I)
（さらに鬱）

２０万円もするコボル講座に通ってます（自費）。

>>199
働きながら通っているとするとかなり偉い。（真似できん）
なぜコボルを・・と思ったけど、逆に今コボルがねらい目かも。
みずほのこともあるし。（コボル→PL/Iはかなり楽）

弟の入社した会社（ソフトハウス）は、配属部署でＣＯＢＯＬを使わないって
わかっていても、全員がＣＯＢＯＬの研修を真っ先にやるらしい。
ＣＯＢＯＬはシステムの基礎だ！！！

>>200
しかも、会社は渋谷のあたりなのに新宿までわざわざ行ってる。
同じ系列のスクールが渋谷にあるのに、コボルができる講師が新宿校なので。
ＣＯＢＯＬ→ＢＡＳＩＣ→Ｃ　という順番で学習しようと思っている。
ＣＯＢＯＬに入る前は、流れ図・アルゴリズム講座に３０時間位通った。
まず流れ図とかを十分に学んでから言語そのものに入ろうと思ったから。

>>201
研修担当者がCOBOLしかできないためと思われ。
そんなやつは、ｸﾋﾞｰ。

>>1
確かに一理あると思われ。
最近の新人は、ＶＢやらＣ＋＋とかのＯＯ言語などに慣れすぎ
肝心の基礎がだめ。（１０年以上のやつでもコントロールブレイクわかっとらん）
その点、無骨なコボラーは情報処理基本のコントロールブレイクなど
基礎ができているやつが多いとおもわれ。

（Ｃなどの言語好きのやつはアルゴリズムはポインタ操作みたいなのりが
あるが、アプリにポインタ操作などいらん。）

情報処理

COBOLしかできないから仕事ありません

新社会人ですが、研修でCOBOLしかやらないため、
不安です。将来大丈夫でしょうか？

>207
不安なら自分で勉強しろよ
何甘えてんだよ

>>207
研修でコボルなんて・・・と同情してみる。
>>199の人のように後は自分しだいさ。
新人研修時代の思い出なんて、寝てたぐらいさね。

ＣＯＢＯＬつまんないよ。
ＵＮＩＸ−Ｃの方がおもしろい、最初は苦労したけど。

>>207
(ﾟДﾟ)ﾊｧ?
そんなモン基本的なロジック教えんのが簡単だから
COBOLなんだっつーの。（でも普通はＣか？）

ＶＢで研修してきた去年の新人の使えんこと。。

教材なんぞ気にするな、がんばれ。

日本の四季を表すのに、日本語より優れた言語はないという
ことでしょうか。

確かに学生気分で甘えていたようです。
すいません。とりあえずはCOBOLを
しっかり理解しようと思います。
それで足りないと思ったらなんとか時間を作って
他の言語を勉強しようと思います。

なんだか　ＣＯＢＯＬ　＝　メインフレーム　＝　時代遅れ　みたいだなぁ
ちょっと待ってくれ。本当にそうなのか？ＣＯＢＯＬでもＳＱＬ使えるし
まだまだ見捨てたものではないぜ。まぁ、ＯＰＥＮ系の連中にはわからん
だろうが、ＲＤＢばっかりが取り扱うデータとは限らんのよ。即時処理しか
組んだことの無い奴らには、大規模なシステム作成は無理だな。
たとえ出来たとしても、引渡し後のシステムサポートにちょ〜経費がかり
会社として赤字だな。

＞＞大規模なシステム作成は無理だな
なんで？

漏れはＲＤＢに対するバッチ処理って経験ないので
ＤＱＮな質問で申し訳ないのですが、誰か教えてください。

ＲＤＢに対するバッチ処理で業務上許容できないエラーが
発生した場合、ＪＯＢを停止するとかエラーリスト（もしくはログ等）
を吐き出して、正常終了するのが普通ですよね。
で、その後のリカバリってどうするのでしょう？

入出力がファイルの場合は、更新前の入力ファイルがあるから
いくらでもリランが可能だけど、ＲＤＢの場合は既に途中まで
更新しちゃってるはずだから、リランというわけにはいかない
ですよね？まさか１ＪＯＢごとにバックアップをとってるとも
思えないし。
それてもバッチが正常終了するまでＣＯＭＭＩＴをかけず、
エラーが発生したらＲＯＬＬＢＡＣＫして、ＪＯＢ停止なんでしょうか？

最近ＯＰＥＮ系に移ってきて、メインフレームでの経験しかないもんで。
誰か教えてください。以上、長文スマソ

>>216
入力側のテーブルに更新フラグを設けて、レコード処理が終わったらフラグを立てる。
ってのは駄目？？

COMMITせずに更新した分を全部ROLLBACKしても良いが、時間がもったいない。

ｽﾏｿ、ﾏﾙﾁﾎﾟｽﾄに気づかずRES入れてもうた。

>>216
処理の件数にもよるが、最後までCOMMITをきらずにPGが動くとは思えんのだが

>>219
どうしてそう思うの？
プログラムの構造がきちんとしてれば極端な話、
１件ずつCOMMITしても最後までCOMMITなしで処理しても
動かせることには変わらないと思うけど。

JOBのリランがうまくできるかどうは別の話だけど

Cobolやってたうちの上司が、
「Cobolだと、仕様聞いただけで、ほぼ間違いなくソースの行数が出せる」とか
言ってたけど、俺は、それ聞いてやりたくなくなった。よいことなんだろうけど、、
確かに。

でも、どんな言語なんだろ・・・

普通はバッチ（トランザクション？）が正常終了したときにコミット。
どこかで異常終了したら全部ロールバック。
オートコミットの設定になってたらＳＱＬ文ごとにコミット。

>>216
バッチのアタマでＵＮＬＯＡＤして一遍バックアップ。
（当然その前でＤＵＭＰも取ってるけど）
その後の処理・更新はＵＮＬＯＡＤしたファイルを使う。
んで処理・更新が終わったらＲＥＬＯＡＤ再創成。
当然そのＤＢを参照するＪＯＢは前提 or 後続で処理だＹＯ！
リランするときはＵＮＬＯＡＤ後からってこと。

答えになってなかったらスマソ。

コンパイルに一時間待ち、
やっと順番回ってきて、ピリオド一個抜けてて、やり直し、またコンパイル一時間待ち
こんなに敷居の高い言語が他にあるか？

>>224
すごい環境だね。
でもそれは 運用の問題。ＤＱＮな運用管理に文句をいってくれ。
>>224さんは今年の新人さんかい？ がんばって！！

ん？
それで稼いでいるのかい？

言語なんだか適所適材でしょ。文脈はなれて比較しても
無意味かも。ＧＵＩ部分でなくて、ＡＰ層の手続き主体の処理とか
バッチ処理とかならＣＯＢＯＬは十分有効な選択肢だとおもいますよ。
それよか、やっぱ手続き型のときは一般的なアルゴリズムをおさえてるか
どうかじゃないのかなー。マッチング、サマリ（ふる〜）とか。
こったＳＱＬをかけるけど、平気で入力バッファいじくってたり、
抽出条件をｓｑｌと手続きに分散させてるたりする若いのみてると
少ない命令セットでアルゴリズムと構造化プログラミングを
ちゃんとやれよといいたい

>>227さん アセンブララーさんですか？
お疲れ様です。

>>同意
VBだろうがCOBOLだろうがASMだろうがかわらん・・・

ＶＢとＣＯＢＯＬはやっぱちがうよ。
ＣＯＢＯＬで画面制御を実現しようとおもうと
結構大変。Ｗａｉｔループと画面遷移の制御に
ほとんど大昔のオントラ制御みたいになるし。
やっぱ、そのへんはイベントドリブンがわかりやすい。
問題なのは組み込みＳＱＬでしょう。
ＳＱＬと手続きの割合をどうとるか。昔はＩＮ、ＯＵＴは
ほとんどＳＥＱ処理で手続き１００％だったじゃないですか。
今はＳＱＬ自身に抽出やサマリの機能があるじゃない。
もち手続きでも同様のことができるし。保守の観点からすると
あまり複雑なＳＱＬだと、解析がしんどいので、ＳＱＬは
ほとんど素のテーブルイメージでＳＥＬＥＣＴしといて
手続きで処理かけさせてる。勿論バッチ等レス性能をあまり
きにしないでいいとき。特に新人には手続きの構造化を意識
させる意味でもＳＱＬに押し込めさせない。でないと結構
その場しのぎで小手先のＳＱＬばかり切るようになるから。
似たような処理なのにｓｑｌへの依存度が違って手続き部分が
全く違う制御構造になってたり、流用できないｐｇｍを量産
してしまう。少人数で保守する場合なんか、思想が一環して
ないとトレースしずらいし。組み込みｓｑｌの場合は、ｓｑｌ
への依存はあまりいただけない、ってのが感想ですね。
性能もつど値踏みしないといかんし。
ｊｏｉｎとＵＮＩＯＮとパーティション限定ぐらいの選択条件を
ｓｑｌにゆだねて、あとの処理対象条件やサマリは手続きにゆだねる
って感じかな。特にｄｅｃｏｄｅはご法度だとおもうな。

>222
あんまり長い間、コミットきらないと
ジャーナル出し過ぎてハーフチェックとかに
ひっかかるよ

>>231
DQN厨房でごめんなさい。
ハーフチェックってなんですか？

>>231
言ってる意味は判るけど．．．
それってちょっと辛すぎますね。
バッチ処理ならば、ストアドプロシージャで処置するのが適材適所だしね。
無理にCOBOLを使っても品質面の低下や速度面の低下を招くだけですね。
それと入出力に置いてもＧＵＩを使うので在れば貴方の言う通りにイベントドリブン系が
良いでしょうし、decoode(case)は、作表処理等の為に多端末から併行して依頼がある場合の
SQL文を組み立てる場合に重宝致します。(decoodeとsumの組み合わせは最強 A * 0 = 0)

>224
机上デバッグを思い出したよ。懐かしー。

騎乗位デバッグ

文法わかんなかったり、システムエラーとか出ると書庫にマニュアルを探しに行く。
たいてい必要なマニュアルは貸し出し中、これでまた1日潰れてしまう。
ＰＣやってる奴には判んないだろうな．．．

>>232
要するにロールバックするためのジャーナルが予め確保されている領域の
1/2を使ってしまうとエラーステータスが返される。
それ以上使用するとロールバックできない、という理由の為
エラーステータスが返される仕様になっている。
(NのACOSにもあったな)

そういえば、oracleでもロールバックセグメントの数が一定数を超えたらエラーになるよね。

>>236
http://www.jbooksrv.yamato.jp.ibm.com/cgi-bin/master!request=menu!parms=!xu=SK888002/Shelves
オンラインマニュアルつかったら？

でも 顧客が外とつなぐの禁止してたら つかえないか。

＞２３３
ストアドプロシージャでも結局、ＰＬ／ＳＱＬでの組み込みＳＱＬ
をつかうでしょ。だったらやっぱりＳＱＬと手続きの割合はよく
考えないとだめだよ。
それと、関係ないけど、ＰＬ／ＳＱｌって動的ＳＱＬ使わない限り、
実表名をソースに埋め込む形になるじゃない？あれっていただけない。
ＣＯＢＯＬだと内部ファイル名、外部ファイル名と実ファイル名から
切り離して（もちＪＣＬで対応付けするんだけど）、純粋に論理的な
世界でコードできるじゃない。ＣＯＰＹ文なんかのＩＮＣＬＵＤＥ機能
もあるし。洗練されてるよ。

>>239
そういわれてみれば そうですね。
PREコンパイル後の中間ソースを見て感動したことがあるんだけど、
そういう視点でもう一回みてみようかな。
新たな感動があるかもしれない。

>>239
ストアドプロシージャで、手続きとＳＱＬ文を別けて考えるのはナンセンスです。
それにＤＢ内処理で実テーブル名を切り離す必要など何処にもありません。

>>239
UNIXには、パイプがあるから全く問題にならない。
パイプっていっても、Windowsのパイプを想像しちゃダメよ。
UNIXのパイプは、もうなんでもあり。
パイプファイルを作っておけば、そのファイルに書き込みするだけで別のプログラムに入力される。
JCLどころの騒ぎじゃないのだ。

>241
えっ、なんでナンセンスなの？
例えばＳＱＬのＤＥＣＯＤＥに押し込むか、手続きで
ＩＦ文で自前判定するか、どっちでもできるじゃん。
保守性からみたら、標準化はいるじゃろ。
「問合せ」か「手続き」はやっぱＤＢをどうハンドルするか
のＰＧＭｅｒの思想がでるよ。ＳＱＬ（問合せ）に「マッチング」
の概念ってないでしょ。でも、手続き的なマッチングでやるほうが
ＳＱＬをかえる必要がなくて、保守性が高い場合だってあるかんね。

＞２４１
それに実テーブル埋め込でたら、回帰テストとか複数の
開発者で開発するとき結構面倒だよ。別の名前でテーブルとか
自分用のデータ環境つくれないじゃん。
ＣＯＢＯＬ＋ＪＣＬならＰＧＭ変えずして、入力ファイルの
アサインを自由にかえれるじゃん。

>>243,244
ストアドプロシージャのお話をしてるんですわ。
SQL文自体がwhere構文を持っていたりするので保守性は元から高いですよ。
標準化と言ったところでそれはＳＱＬ文を区別して考えねばならないことじゃないよ。

それとテストなら別ＤＢ作れば済むことだし本番ＤＢの中にテスト用のテーブルを
作って貰っても困るだけですわ。

>２４５
ストアドプロシージャが何か本とにわかってます？
ＰＬ／ＳＱＬとかしってます？
それがどういう構造をもった言語がわかってます。
どうもかみあわんなとおもったら、ＳＰ＝ＳＱＬと
勘違いしてない？

＞２４５
＞別ＤＢ作れば済む・・
ププ。一人で開発してるの？テスト機ってしってる？
パーソナル環境で一人で開発するならそれもいいかも
しれないけど、システムに必要なテーブル群を
それぞれのパーソナル環境でビルドしないぜ。普通。
共通・制御系のＤＢなんかいるでしょ。
フリーソフト作ってるわけじゃないんだよ。

>>244
うざい。
メインフレームしか知らないのか？
それとも何も知らないのか？

>>246
全てそのままお返し致します。

>>247
全く意味不明の発言をしないで頂きたい。
ストアドプロシージャのロジックテストなんて個別のDBで十分でし！
サーバー環境に幾らＤＢを作ったところでしれてますからね。

やっぱ出張３２は、ベースのとこがわかってないな。
こういうのおおいな。最近のＰＧ。言語ばっかやってて、
ソフトウェア工学の基本概念も通じないやつ。
246に禿同。するどいよ。保守フェーズに入ると
担当者ごとのＳＱＬと手続き部の比重のかけかたの
ばらつきで一貫性がなくてトレースしずらい。
これはストＰでも基本的にお同じ。

やっぱり文系＝ヴァカ

なんだかんだで　結局ボロがでるのね

お客は数年でだめになるシステムなんか望んでない。
最低１０年は使えるシステムにすべきだ。
安定した言語を使うことが、お客のためになるほうが
おおい。新しい技術は勿論嫌いではないが、自分のスキル
アップと顧客の考えるシステムライフサイクルが天秤に
のるときは、やっぱ顧客でしょう。ＣＯＢＯＬはオープン
でもいまだ有効な言語だと客観的におもうな。
だとおもう。

>>250
君ら意味不明の発言ばっかだね。
担当者毎にバラ付くのはそのシステムでの記述方法を取り決めない為です。
手続き部って必死になって騒いだところでストアドは精々カーソル制御と単純な判断文と演算が出来る程度
であって必死になって訴えるほどのもんじゃない。
所詮はバッチ記述であり複雑なのはエラー処理の記述法がいい加減だったり
ロジックそのものの構造が矛盾してる場合です。
つまりはド素人の記述は読み難いだけのこと。（笑

>>243と>>250

「SQLをメンテナンスするのはやだけど、COBOLなら
メンテナンスしてもいい」、と言っているようにしか
聞こえないですね。

>>252

COBOLがいまでも有効な言語ということには賛成します。が、
COBOLだけが安定した言語でしょうか。CやJava、延いては、
PerlやVBも現時点で十分安定してますね。将来のこととなる
と、人知を超えているのでなんともいえませんが。
そう考えると、>>252で仰られていることは、理由が薄弱で
すねえ。

>>254
VBは安定している言語から外してくれ。
動作そのものは安定してるかもしれないが、
５年前のプログラム修正するのに既にコンパイラが売っていないなんて！！
微妙な仕様変更で最新のコンパイラではエラー続出だし。
氏ね＞M$

>>254
どう読んだら、COBOLならメンテナンスしてもいいと言ってるように
きこえるんだ？ばかか？

普通に読んだら、>>243も>>250もCOBOLやその他の言語に
関係しない話だということを理解してるのか？

後、出張32は人の意見をちゃんときかずに、自分の土俵だけで
あばれてばっかしだね。>>243に対する>>245の返事で
「ストアドプロシージャのお話をしてるんですわ。」
といってるのは、馬鹿丸出し。

出張３２は書き込む前に
マニュアル読んでから書き込んでいる模様

自分の経験不足があからさまに文面に出ている

>>257
そりゃ逆だろう？ (笑
ストアド作るのに、ＳＱＬ文制限してどうする？
本末転倒なことを言ってるのは君のほうだろう。

メンテナンス云々を幾ら騒いで見ても適切なＳＱＬ文が制限によって書けないので
あればソースは読み難くなるだけであると言える。

>>258
SQLって知ってるんだ　
どんなマニュアル見たの？おしえて

２以下のCobol否定派諸君

君たち。なに血迷っているんだね。

基幹系はCOBOLで決まりだよ。それ以外に選択肢がない。
悔しかったら仕様書納品してごらん。

金融機関の営業にもわかるような仕様書だよ。SEじゃないよ。
ＳＱＬ分の羅列をされてもわかんないよ。
はぁ？関数仕様書？
漏れはここの部分のこの処理が何やっているかの資料が欲しいんだが？


それにいろんなデータフォーマット見たまえ。
みんな固定長だろう。
あれはCOBOLがいちばん処理しやすいよ。

ＶＢはちょっと難しいよな。
COBOLでCSVに変換してもらったほうが楽だよな。

それとも String * 120 で型定義しているのかい？

あははははは。

悔しかったら全銀協フォーマットをCOBOLで処理できない形にしてみな。

>>260
最初の部分は同意したが

そのあとはしょぼいね
自分のスキル不足まるみえですよ

今はstring*120≠PIC X(120)って知ってる？

＝にもなるのだが

まぁしょぼい頭で調べてくれ

>>261

>今はstring*120≠PIC X(120)って知ってる？
>＝にもなるのだが

だからつかえぇんだよ。

まぁしょぼい頭でかんがえてくれ。

まともなＳＥならこんな反論せんぞ。

string**120=PIC X(120)になるよ

>>260
馬鹿か？
その論理は、COBOL前提の基幹システムを組んだらCOBOLが一番って
いってるだけじゃねーか。
そういうのを同語反復っていうんだよ、覚えときエセＳヨ。

>>260
固定長、全銀協をキーワードとして捉えれば、ＶＢの場合「UNIコード」がネックになる
ことは理解出来る。
だが、UNIコードなんてものは内部コードの問題であってそれ以上でも以下でもない。
結局その言語を自在に操れる人に取ってみれば「固定長、全銀協」など取るに足りない敷居ですわ。
まあ、ド素人に取ってどちらが簡単か？を論じてるのなら多少は理解出来る。

>>264
>その論理は、COBOL前提の基幹システムを組んだらCOBOLが一番って
>いってるだけじゃねーか。

そういっているんだよ。
まぁ、漏れのとこだけがそうなっていたらこの非難も妥当なんだが、
まわりがみんなそうだからな（良くてPL/I）。
くやしかったら金融機関の基幹系をオープソ系の言語で開発して
ごらん。

あっ、証券系はだめだよ。あそこは結構独自色がつよくてもやってられっから。

>>265

>結局その言語を自在に操れる人に取ってみれば
>「固定長、全銀協」など取るに足りない敷居ですわ。

そのとおりなんだけど、そんなやつ少ないよ。
自分がやってない分野は小理屈君にになってさけようとする
奴ばっかり。

これはコボラーにも言えることだが。

べつに「だからオープソ系はむかない」というつもりもないけど。
でも、オープソ系のSEがぶち当たる壁って、まさにこのへんなんだよね。

このあいだもHOSTで作られた他社提供のデータを印刷する処理を作らせ
たんだが、「デリミタがどうの」「レイアウトがどうの」といろいろ
へりくつをこねて仕様がまとまんなかった。（ちなみにマルチレイアウト
だったんだな。このデータ）

結局、相手に頭下げてCSVにしてもらったけど。

こんな調子じゃ基幹系は任せられんな、と心底おもった。

>>266
> そのとおりなんだけど、そんなやつ少ないよ。

まあ、オープン系は経験の少ない技術者が多いのでヨチヨチ歩きな人が多いのは事実ですわ。
そんな人の多くがＣＯＢＯＬ系を蔑んだりメインフレーム系を嘲笑ったりする姿を見るとなんだか
虚しくなるね。
宛がわれたアーキティクチャを覚えることと自身で必要なアーキティクチャを創造する能力を同義と捉えて
憚らない人が居るのも幼稚な思考のなせる業か？

オープン系であれメインフレーム系であれ難しいものは難しくそれをこなす能力を
有する人は少数である事実をもっと知って欲しいものです。

いいかい、出張３２さん。
ＰＧＭの記述はシンプル（短いっていみじゃないよ）
であればあるほどいいんだよ。
「サルでもわかる」記述じゃだめなんだよ。
それが保守性ってもんだ。
だから、手続きについては構造化プログミングって
いわれるんじゃないか。そｒにくらべて、ＳＱＬには
効率からみた約束事はあっても（インデックスを使う記述方法とか）
記述の複雑さへの制限はないよな。
でも、保守するほうからみれば、副問合せやこったｄｅｃｏｄｅだらけ
のＳＱＬは怖くてさわるの勇気がいるのさ。テストもＳＱＬの変更で
実行計画なんかへの影響を考えなきゃならなくなるし。生産性から
すれば手続き内の独立したプロックで影響を限定してるほうがわかりやすい。
ＳＱＬちょっとかえただけで、どこに影響でるか全体的に神経質にならなきゃ
なんないだろ。

>>268
経験のない出張３２にそんなこと言ったらかわいそうやんか
今ごろ必死で弁明の理屈を考えている

私の個人的な見解かもしれないが
ホスト系にはSQLは向いていないと思う

ＵＮＩＸ系は向いているこれはOSでメモリの管理の仕方が異なることに
よるものだと思う

>>265
出張ﾀﾝ、「UNIコード」ってどの教科書にかいてあった？
なんか論点もズレてるんだけど・・・。

>>270
だから自分の知識のないところに入っていくと墓穴ほるから
自分の土俵に持っていこうとする

別に内部コードでUNICODE使わなかったら　どうこう言う話題で
無いと思うが．

ただ単に出張３２はUNIコードって言葉を使いたかったんでしょう

>>271
ﾊｧ?
自分の知識のないところに入っているのに
一生懸命知ったかぶりをするのがおかしいんだろ？
内部コードでUNICODEとかいう話題は出張３２が出しているんだが。
ちゃんと読んでね。

ABAPのプログラマーに・・・・

>>272
あなたも頭悪いですよ　出張３２とどうレベルに思われますよ

ここでの論点はｕｎｉｃｏｄｅでないでしょ！！

あなた小学校時代の通知書にもっとよく人の話を聞きましょうって書かれませんでしたか？
それとも現役小学生ですか？

>269
ＳＱＬはホスト向かないってのは間違ってるよ。
ＲＤＢ自体１０年も前から、ホストでもあったじゃん。
ＮすらＲＩＱＳっていうＲＤＢもどき搭載可能だったじゃん。
当時はＳＱＬはＣＯＢＯＬからの組み込みＳＱＬってことで
すでに使えてたし、気の利いた情報系ならすでにポピュラー
ですらあったよ。だから、汎用機・オープン機に関係なく
処理形態で「問合せ」か「手続き」かだけのはなしだよ。
スレのテーマに即していえば、２０年以上メジャーでありつ
づけている意味だけででも最強といえるかも。
言語の安定性は顧客から見ればものすごく重要。

自分の経験から向き不向きをあげてみる。

（なるべくＨＯＳＴ　VS ＵＮＩＸにならないようにしたつもり）

【向いている処理】
１．帳票を作成する場合（改ページ、改行の概念があるので楽。
　　罫線とかはオーバーレイまかせね）。
２．固定長データを扱うとき。（もともとこのデータを扱うための
　　言語だから）
３．金額計算がともなうとき（小数点以下の桁数も自由に指定可能）

【向いてねー処理】
１．グラフなんかをかかせる。（描画系の命令が昔は全くなかった。
　　いまはあるのかな？）
２．ＣＳＶなんかの可変長データ（テーブルサーチになっちまう。
　　ＰＣ系のＣＯＢＯＬだと専用ＡＰＩがあるらしいが。
　　ＸＭＬなんかになるとさらに鬱）

あと、息が長い言語だけあって、仕様書の書き方なんかは
どのユーザーいってもほとんど同じレベルなのですぐに仕事に
かかれる。

これがＣとかだと、関数仕様書の書き方やらなにやら全く違う
ので、処理の概要をつかむのにちょっと時間が要ることが多い。
（ＪＡＶＡは自社でしかやったことないからわからない。Ｊａｖａ
Ｄｏｃしかおいてってないなぁ。）

>>275
同じ処理をＳＱＬ使わずに昔の方法で試したことある？
前に一度試したんだよね　そしたら処理自体はダサダサのロジックだったけど
NDBの方が早かったんだよね．
１０年前からＲＤＢ動いていたというがそれはＵＮＩＸ系のものを
ただ単に乗せたというだけ．

約１０年ほど前からオープンと言われ，ホストもその流れに沿って行かざるを得ない状況に
なったNDBからRDB　ＮＤＢはOSを意識して作成されたDBだがRDBは違う
UNIXと同じようなSQLは性能がでないのは確か．ＵＮＩＸだとギガ以上のメモリは普通だが
ホストは違う．カーソル処理とか結構メモリを使う．そういった処理を元々ホスト系のＯＳは
意識していないから他のジョブに与える影響が大きい

ホストでの言語はCOBOL以外にはとうめん考えられないと思うがホストで動くDB
がRDBというのは疑問である

あと、ＣＯＢＯＬに限らず、メインフレーム全般の話になって
しまうが、漢字コードが各社ばらばらってのがすげー鬱。
（日立、富士通、ＩＢＭどれもちがう）

いちおーコンバータなんてのもあるが、カラム数指定で漢字エリア
を指定するので可変長データなんかにはまったく歯が立たない。

あと、半角カナの小文字（小さい「ッ」とか）は全く使えない。
じつは使えるんだけど、他社交換でこれらの文字は全く変換でき
ないので、いちおー使えないことになっている。（対応してない
プリンターもあるし）

>>278
確かにメーカー間の互換は無いが外字がつかえることって
凄いと思う

未だにWindowsは外字使えない
使えることは使えるが使用できる数が少なすぎる、全ての水準を対応
する事はできない
いつになったらできるようになるのか？

>>268
君は何をバカこと言ってるんだい？
今、論じてるのはストアドのお話だよ？
カーソル定義して順次読みする必要があれば当然そのような構文になるし、
それだって基本的にＳＱＬ文と呼べるしなものだよ？
凝ったＳＱＬ文って一体どんな文なんだい？
索引条件も考慮しない無茶苦茶な構文のことを指しているのかい？
そんなのはＳＱＬ以前の問題であって論議に持ち込むほうがおかしいさ。
君がＳＱＬ文を制限したいのは、テーブルの性質を全く考慮せずに唯ややこしい無駄な
構文を書くお人を規制する為なんじゃないのかい？
ＳＱＬとして必要なwhere条件すら記述しておらず、ひたすらＩＦ構文で読み飛ばしロジックを
書き出すことが保守性を高めるとはどうしても理解出来ないね。

>>280
だから出張３２はあたま悪いって言われるんだよ
場合によってはIF文使う方が早いんだよ
経験が無いんだから　黙っていて

>277
商用にのったのはＲＤＢは汎用機が先じゃなかった？
Ｏｒａｃｌｅも汎用機からでしょ。
＞２７８
漢字コードは確かに。可変長でも普通、ＫＩＫＯ（漢字イン・漢字アウト）
方式でやるでしょ。項目も属性も意識するひつようもないよ。

>>270-272
私がUNIコードを出したのは、固定長処理を行う上でUNIコードが不味いからですわ。
ご存知のようにUNIコードは半角文字も全て下位バイトにNULLコードを付加した２バイト
文字として扱われる。
この為、全銀協手順だと透過コードも扱うのでstring配列で処理するのは不味い。
基本的にByte配列で処理を行い表示等必要に応じてUniｺコードへの変換を行うのが一般的なんですわ。
だけども、ド素人クラスになるとUniコードへの自動変換がどのタイミングで行われているかすら知らない人も
多く存在し中にはUNiコードって言葉すら知らない御仁すらいるからね。

ド素人に近い突っ込みをしている君達も多分そのクラスのお人なんだろうね♪

>>281
索引条件に見合ったWhere文の方が絶対に早いよ。(笑

>>282
汎用機っていっても色々OSあるんだよね
ＵＮＩＸも動くって知ってる？

>>284
やっはり出張３２は経験が無いんだ
WHEREで使用するメモリとか内部的I/O等の考慮してない

もっと勉強してね

>>283
よく調べたね　調べるのに時間が掛かったからレスに
時間が掛かったの？

>>277
NDBとRDBと比較すること自体が間違いですよ。

NDBは処理速度が命のDBなので、定型処理は圧倒的に
早いし、データの取りだしもらくだが、非定型処理を
組もうとするとおそろしく冗長なプログラムができあがる。

それに比べてRDBはNDBがだめなところを何とかしようとして
開発されたので、キーさえあっていればどんな非定型処理
も可能であるが、いかんせんパフォーマンスが全般的にとろい。

ただ、だからといってNDBも安泰ってなわけではなくて、
時代は「DBはRDB」となりつつあります。
某メインフレームメーカーなんかはNDB作るのやめてますし。
結構NDBからRDBへのリプレースも多いですよ。
もちろん言語はCOBOLだけど。

>ホストでの言語はCOBOL以外にはとうめん考えられないと思うがホストで動くDB
>がRDBというのは疑問である

てゆーのはわかるが、いかんせんメーカーが作らなくなってきている以上
どうしようもない。

>>286
嘘を付いたらダメよ。
1000万件のレコードが存在する内の５万レコードが更新対象データだとして
where文を使わずに処理してご覧よ。
静的カーソルとして考えても1000万件の静的テーブルを作成することとなり
時間が掛かるのは必定ですわ。（笑

>>289
誰もWHEREを使わないと入ってない
複雑な条件よりはIFを使った方が早いって事

今日SQL勉強したからいろんなこと言いたくなるのは
分かるが　あまりにも内容が稚拙すぎる

＞ＳＱＬとして必要なwhere条件すら記述しておらず、ひたすらＩＦ構文で読み飛ばしロジックを
＞書き出すことが保守性を高めるとはどうしても理解出来ないね。

これは大げさすぎだよね。いくらなんでも

UNIXのOracleならば　ばしばし複雑な条件入れるだろうな

>>291
このような使い方は普通でしょう
知らないのは　出張３２だけでない？　どう？

SQLをメモ帳にコピーしたら一画面に収まりませんでした。
どおりで遅いわけだ。
IF文にしたら早くなったよ！

>>282
コンバーターってSI／SO判定してくれましたっけ？
（メーカー提供のはまずだめだったと思うが）
だとしたらべんりだなぁ。
ツールの名前、教えてください。

>>294
俺もあった　やっぱり苦労した人しか分からないでしょう
出張３２は　やはり経験不足

＞出張３２
もう、やれやれってかんじだ・・・。
フェッチしたあとの手続き部分をきちんと
構造化してよっていってるの。単純に。
それと、おんなじ処理をほとんど同じ性能で
問合せと手続きどっちででも実現できるような
場合はバグによるインパクトの小さい手段で
よりわかりやすい記述となるほうで行うのが当然
ということ。きみ、ＰＧＭ書くとき、だれかのためにっ
て意思ないんじゃないの？ＰＧＭｉｎｇで一番必要なのは
言語への知識っていうより、「思いやり」じゃないかな。
一番いらないのが、「自己満足」。つくづくおもうよ、最近。
自分のスキルばかり考えて書いたか、読む人へのおもいやり
から書かれたか、もろ出るよね。おもいやりのあるＰＧＭｅｒ
ならＳＱＬと手続きの配分に悩むはず。こんなんどや！ばかり
考えてるやつには、多分それは見えない問題なんだろ。。。

>>291
うーん、大げさじゃないよ。
必要構文を前提にしない規制ならそうなるんだわ。
つまりＳＱＬ文を規制するのは速度面を考え冗長的な文を規制すれば良いだけであり
それならば「ＳＱＬ文」に拘らず全ての構文に付いてのお話だってことね。

>>294
そのSQL文をこぴぺするように。

あんまし長いWhere文はDBMSによってはインデックス使わなく
なるからやめたほうがいい鴨。

もうねた切れですか？出張３２さん？

ねた切れだったら
１０００万件のレコードから５万件の更新を行うロジック考えてください

>>299
そりゃそうです。

>>299
副問い合わせなんかもてんこ盛りで結局解読できなかった。
仕様から単純なSQL発行してメモリに展開して処理しました。

>>301
どういうときにインデックス使わなくなるの？

>>302
私は逆に、構文が複雑なのをSQL文を見直して簡素化しましたわ。（笑

あんましツマラン展開にして欲しくないね。

>>304
所詮　出張３２が担当する程度のシステムでは
レスポンスとかシビアなシステムでは無いと思われ

自己満足かまたいつもの誇大妄想と思われる

>>303
細かいこと言い出したら導入される製品によって異なりますが、
基本的に索引条件が索引の上位キーに対応していない場合(スター検索除く)やOr構文等によって
索引が実質的に使えないもしくは外部結合などNull条件等が入る場合ですね。

出張32って誰ですか？

>>306

コードが０１又は０２のレコードを検索するときには
CODE=０１　OR　CODE=02　ってすればよいの？

>>307
まあ、読め！（笑

http://mentai.2ch.net/test/read.cgi/infosys/1012999888

>>307
ＳＥらしい
あたまが良いらしい
今までに８０ものプロジェクトを経験したらしい

全てらしいですが

あとは文面をみて　ご自身で判断してください

ｗｈｅｒｅ句はまあいいよ。まだ。
それを「処理対象条件」とすればよし。
でも、where句で制限したうえに、さらにフェッチしてｉｆ文かまして
処理対象外にしてるＰＧＭってあるんだよ、ほんとに。
「処理対象条件」があちこち分散してどうすんじゃ！っていいたい。
それとか、集計対象の違うカラムからなる行をはかなきゃいかん
からって、入力でｄｅｃｏｄｅ乱発。一通りフェッチして、自分で
条件判定してサマリした方がわかりやすい。
なにより、その後そのＰＧの流用度がたかまるよな。ごりごりＳＱＬ
のみのＰＧって、入力テーブルがおんなじでも、まず流用不可だろ。

ゴルァーーーーー！！
ここはCOBOLスレだろーが！！
SQLスレじゃねーよ。

>>302
そーゆーときは男らしく以下のように処理すること。

１．全件アンロードぉ！！
２．トラ＆マスタをソートぉ！！
３．マッチングしてマスタを更新！！
４．マスタをリロードぉ！！

場合によっては４の前にソートを入れる必要あり！！

以上、検討を祈る！！！！

>>308
私なら
CODE >='01' And Code <='02'って書くね♪ (文字だろ？）

>>312
ホストでのリロード遅いんだよね

>>313
やっぱ馬鹿だ

BETWEENを使うならまだしも　＞＝を使う？

あほ以外のなにものでもない　今までにそんなプログラム作ってきたの？
レスポンス悪すぎるよ

俺ならばINを使いますが

>>311
だからさぁ、君の言ってることは理解してるって！（汗"
唯、そんな奴を規制する為にＳＱＬ構文の一律規制をしたところで君の
描いているコードは上がって来ないって．．（笑

そう、そのレベルのお人にバッチを書かすこと自体が異常なんだわさ。

>>312

そうですよねCOBOLですよね

私はホストではCOBOLが最高でなく最強だと思います

ＵＮＩＸでは難しいなぁ　やっぱりＣかなぁ　でもCOBOLも使えると聞いたことあるので
COBOLがあればCOBOLかも

パソコンではＶＢかＪＡＶＡですね

>>314
グホォ！！
何でそれを知っているッ！！

しかし、男ならマッチングだっっっっ！！
これこそ、マスタ−トランザクション処理の基本であるぅーーーー！！

（でも、更新対象のマスタが５個も１０個もあるときはこっちのほうが
並行できるので早いときもあり。これはマジ）

>>318
リロードの場合一度オンライン止めなければならないんだよね

でも俺も男らしく　マッチングで処理しようと思いますっていいたいが
俺クライアントの担当なんだよねＶＢとかではアンロードないしなぁ

では男らしくふんどし締めて仕事します

>>315
>BETWEENを使うならまだしも　＞＝を使う？
他人に文句をいうのもいいが、おまえもかなり痛いぞ

>>320
意味不明

痛いとはどういう事？　自分ならどういう条件にする？
批判だけならば誰でもできるよ

わかった>>320は出張３２でしょう

>>312
よくぞ言ってくれた・・・（泣き）

>>321
索引対象云々を議論してたんじゃ．．．．

出張３２はいつもsageにしてるしね

>>320
やっぱり同一人物だ　内部コードみたら同じIDじゃん
みっともないことはやめましょうね

>>326
べつにいいじゃん。

>>326
??
私はコテハンですよ。（笑
それと、君の低俗なる突っ込みにレス入れるほど私は愚かではありませんからご承知おき下され。

>>319
>リロードの場合一度オンライン止めなければならないんだよね
グホォォォォ！！
何故それを・・（以下略）

まぁ、この手が使えるのって、夜間バッチタイムがあるようなとこ
でないと無理鴨。２４時間オンライン稼動中のとこだとできないのは
確か。

ゴルァーーーーー！！
ここはCOBOLスレだろー（以下略）

・・・つーても誰も聞かないので一人でやるのだ。

昔コボラーいまオープソ系SEの立場からみても、「定型処理」（いわゆる
バッチ処理ね）では、COBOLは最高の言語であると断言が可能である。

理由は　>>276を参考にしてくれ。
（ちなみに、ここの２７６は漏れが書いたものだから。）

クライアント向けの入出力画面しかつくったことのない人
（＜馬鹿にしてるんじゃないよ）には理解できないだろうが、
大量集計処理では、このどれもが欠けてもうまくいかない。

あとOOPでないので、保守のときに楽というメリットもある。
作るときは地獄なんだが、修正の際、修正対象のソースだけ見れば
なにやってるか大体わかってしまう。
OOPでつくられたもんだと、スーパークラスもみなくてはならないし、
サブクラスがないか一通りなめなくてはならない。
サブルーチンだとこの作業は必要だが、非OOP言語であるCOBOLはサブクラス
化されていることはないので、その辺の心配は全くしなくてもいいことになる。
（OO-COBOLになるとこの辺は変わってくるだろうが）

さらにバッチ処理になると、JOBフローだけで修正した影響も特定できる。
気になるんだったら、JCL中に登録されているファイルを検索し、手元に
あるJOBだけで完結しているか調べればなおいい。

なんかCOBOL（およびメインフレーム）マンセーになってしまったが、
保守フェイズにはいるとこれがものすごく効いてくる。

なんせ、客との仕様打ち合わせが数ページのJOBフローだけってことも
珍しくない。だいたい、いまどきのCOBOLプログラムは機能分割が徹底
しているのでJOBフローに機能概略をちょこっと書いてあげるだけで
簡単な資料になってしまうのだ。複雑なやつがあれば、そこだけ
仕様書もっていけばいい。

これがオープン系だと常に全PGの資料とノートパソコン
が必需品になる。（ノートパソコンはとっさのソース検索用。）
こんだけ用意しないと客が急に言ってきた仕様でできるかどうか判断
できないのだ。（あとで検討して云々が利かない客もいるので）

現場での経験からすると、こんなものかな。
まだまだあるけど、とりあえずこんなところ。

＝以下次号＝

ちなみに、会話型処理をCOBOLで組んだ経験はないので
この分野での他言語の比較はできない。
（汎用機では今はなきCSPで作ってました）

ただ、COBOLの言語使用からして、かなり不利なことは否めない
とおもう。

あと、330への補足だが、非COBOL言語とCOBOLとでは
客の要望の度合いがぜんぜん違う。

非COBOL言語の方が要求が高いのだ。

まぁいろんなシステム作ってもらって、CSシステムの方が
見た目がいいからっていうのがあるんだろうけど。

だからこそ、できないことはその場で否定しないと、変な期待を
持たせることになる（場合が多い）

その点、COBOL（およびメインフレーム）はあとで「できませんねぇ」
っていっても許してもらえる場合が多い。
けっこう、融通が利かないことが先入観としてあるみたいだ。

>>318
あんた良いヒトだ
グホォォォォ！！＜このノリがイイ

汎用機での会話型（画面）制御はたいてい画面オブジェクトと
してパネルオブジェクトを専用言語（ＯＳ依存かな）で生成。
そのオブジェクトをＣＯＢＯＬで制御するって感じになります。
ホスト端末の画面故、当然パネルオブジェクトはホスト上のパネル
ライブラリに格納します。
ＣＯＢＯＬソースではイベントは実行キーやＰＦキーになるので
専用のシステムマクロかシステムで用意してる専用サブルーチン
でキー押下のイベントをひろったり、パネルの表示を行います。
パネルの項目に入力した値は専用サブでＷＳのエリアとリンク
しておくことではんどるできるようになります。
当然制御構造はｗａｉｔループ構造で特定キー押下のイベントで
脱出って構造になります。昔のオントラ振り分けっぽいかな？
いずれにせよ画面遷移をすべてソースで制御するので、どうしても
ＧＯＴＯを使いがちになり、結構めんどうなコードになりがちです。
自前の運用管理画面やファイル関連ツールの会話型画面を
これで結構つくってました。

>>334
詳しいことは存ぜぬがＧＯＴＯ制御はおかしい。
構造化したプログラミングを意識すればＧＯＴＯ文は
不要だと思うけど。

>>334
お疲れ様 ヽ(^｡^)ノ
おぺん系の人が「COBOLで画面を作れない」
っていうのは、はい そのとーり。
でも、メインフレーマーが画面ツールを用意してくれてるんですね。
IBMのCICS、IMS等々、のオンライン画面ツールは
容易に扱えて最高ですよ！！
とはいえ、いまはNOTESやWEBブラウザとの連携が必要で、
もちろんベンダーはそれらの準備は怠りないのですが、
おぺんの人から見るとめんどくさく見えるのかもしれませんね。
私は どっちでもいいけど…

>>335
GOTO制御がおかしい、というのは
一理あるが、
構造化を強化するGOTOは推奨されるべき。
たとえば、エラーをトラップした後のセクションexitへの
GOTOはどんどん行うべきです。
JAVAもjdk1.2からループから抜ける仕様が追加になったじゃ
ないですか。

基本的にそうなんだけど、画面ってキー押下等でイベントが
発生するんで、キー押下に応じたルーチン間の遷移で
手っ取り早くｇｏｔｏ使いたくなっちゃうんですよ。恥ずかしいけど。
イベントドリブンな遷移を手続きで実現しようとすると結構めんどう。
遷移にあわせてあっちのルーチンこっちのルーチンって移動パタンを
全部手続きとして実現せにゃならんので。ＶＢなんかだとないよね。
イベント発生で対応したロジックがコールされるだけで、イベント
の順序って基本的にコードする必要ないから。

コボラーにＶＢ教えるのは簡単。
ＶＢしか知らない人にコボル教えるのは、かなり難しい。

>>339
それは コボルを覚えるの嫌がるからでしょうな。
いやと言ってる人は何を言ってもだめだよ。
やれやれ

こまるよな。ＶＢに留まってもらっては 会社にとっても 損害だ。
なんとかして システム全体を面倒みられるエンジニアになって
ほしいんだけどね。(ｃでもいいのだけど）

>>340
基本的に関数の数が違う

VBの
ｔｒｉｍ　とか　ｌｅｎってｃｏｂｏｌでないから

あとデータ型もｘ，９以外にもいっぱいあるから

VBと同じ事できないからイラツク

>>341
関数ぐらい自分で作って欲しいわ。（笑

# 突っ込み歓迎

COBOLって私の知る限りでは関数作れないんだけど、
もしかして最近のは作れるのかな？

関数的なことをCOBOLで実現するなら方法としては２つだね。
（１）外部サブルーチンを作成しそれをコールする
（２）プログラム内部でPERFORM文による手続き呼び出し

でも（１）はいちいち大げさだし、それにスタティックリンクなら
ともかくダイナミックリンクだと呼び出しのオーバヘッドがかかる。
（どれくらいかかる？って聞かれると答えられないけど・・・）
それに（２）は引数渡しができないから、COBOLお得意の大域変数
を使って、そこを呼び出し、呼び出され側双方の共通領域として
値を受渡しする、という手続き間の結合度が高いやり方になっちゃう。

みなさんどんなやり方とられてます？

>>338

画面の中にユーザーからは見えない隠し項目というものを
定義してそこに値を設定して端末にダウンロードして
端末から上がってきた隠し項目の値によって画面がどんな
状態であるか判断できると思うけど。

例）コード＝００３で呼び出される画面で２パターンの
　　表示形式があるとする。

端末　コード＝００３を入力

ホスト　コード＝００３の項目を設定し　
　　　　隠し項目に１をセットして
　　　　画面を転送

端末　コード＝００３の画面が表示されデータを入力

ホスト　コード＝００３の画面であるが隠し項目に１が
　　　　セットされているのでデータが入力された画面
　　　　であることがわかる。

>>295
亀レスｽﾏｿ。F*TRAN+ 調べてみれ（ftranで検索すればでてくる）。
KI/KO含め主要なメーカすべてに対応できるようになってるから。
（ただし、Windowsで動くことには注意）
メーカ提供のツールは、囲い込み戦略と相反する点があるんで、
あんまり熱心には他メーカ対応しないんだよな。
（F*TRANってF系じゃないの？藁）

344

親セクションで実行キーが押下されたのかＰＦキーが押されたのか
それと隠し項目を判断して処理は子セクションに飛ばせばいいと思うけど

68 ：参加するカモさん ：01/12/11 17:29
ひろゆきってたまーに驚く程幼稚なセリフ真顔で吐くんだけど、いったいどういう
青春を送ってきたのだろう？
普通に成長を遂げた人間であれば赤面してしまうような恥ずかしいセリフ

82 ：参加するカモさん ：01/12/13 15:02
なんとなく言ってることわかる。
俺もひろゆきと何回か話したことあるけど、大昔のドラマでも見てるような気になった

95 ：参加するカモさん ：01/12/22 16:35
飲み会になると、必ず「遅刻」の話を得意気に語りだすけど、ひろゆきって遅刻することかっこいいと
思っているのかな？
回りの人間は苦笑するしかないけど、この人やっぱり幼稚だと思う

>>342
また出張３２のしったかぶりかぁ〜

ためしにｔｒｉｍとｌｅｎの関数つくってみて

>>348
STRING とかUNSTRINGとか知ってる？つーてもコボラーも使わないからなあ（藁

>>348
> ためしにｔｒｉｍとｌｅｎの関数つくってみて

うーん、ザコしか釣れん！！！
あのさぁ、固定長処理にそんな関数いるのと思う？ (笑
それとそんな単純なものくらい自分で作れって！(全角判断位は組み込めよ)

ＶＢで大量データのバッチ処理もやるんか？かなり痛い奴らだな
ＶＢなど（ＶＢにこだわらないところがみそ）で、1件のクリーンなデータを
ＲＤＢ（製品名にかだわらないところがみそ）に入れて置いて
日次更新などは、サーバでもくもくとＣＯＢＯＬにやらせるのでは？

>>350
そもそもCOBOLに関数などない

＞３４９
UNSTRINGは俺、よく使ったよ。

パソコン上のCOBOLって固定長処理できるの？

なんかしらんけどＣ＞＞＞＞＞＞∞＞＞＞＞＞＞＞＞ＣＯＢＯＬ

>>355
根拠がわからない？　もしかして素人？

なんかしらんけどＣ＞＞＞＞＞＞∞＞＞＞＞＞＞＞＞＞＞＞＞ＣＯＢＯＬ

>>356
素人でしょう。
そのうち、「java >>>>> perl 」
とか、言い出すんじゃないの？
あはは

俺らはコボラー　やくざなコボラー　俺らがおこれば嵐を呼ぶぜ
喧嘩代りにＪＣＬを叩きゃ　恋のうさもふっとぶぜ

（台詞）この野郎、かゝって来い！　最初はＭＯＶＥだ……　
ホラＰＥＲＦＯＲＭ……　おっとＣＡＬＬ……　
畜生、やりやがったな、倍にして返すぜ　ＣＯＭＰＵＴＥだ、
ＧＯ　ＴＯだ、ＧＯ　ＴＯだ、ＡＤＤだ　
えゝい面倒だい　この辺でＡＢＥＮＤだい

俺らはコボラー　やくざなコボラー　俺らがほれたら嵐を呼ぶぜ
女抱きよせＪＣＬを叩きゃ　ＰＣはいらねぇオンの字さ

（台詞）この野郎、かゝって来い！　最初はＭＯＶＥだ……
ホラＰＥＲＦＯＲＭ……　おっとＣＡＬＬ……
畜生、やりやがったな、倍にして返すぜ　ＣＯＭＰＵＴＥだ、
ＧＯ　ＴＯだ、ＧＯ　ＴＯだ、ＡＤＤだ
えゝい面倒だい　この辺でＡＢＥＮＤだい

俺らはコボラー　やくざなコボラー　俺らが叩けば嵐を呼ぶぜ
年がら年中ＪＣＬを叩きゃ　ビルゲイツも逃げて行く

>>354
ＮＴで動くcobol使ってるけど
問題なく固定長処理できてます

ＶＢとか良く知らないけど固定長処理使えないの？

>359
面白い！！

>>339
それ聞いたことある。
私の場合、最初にcobolをやって、基礎を身につけることができて
本当に良かったと思ってる。

>>352
関数あるでしょ。
JIS COBOL85 （正確には"COBOL 92"っていうのかな）からは。
function length (引数１)
とか。
そういう事をいってるんじゃないの？

>>360
固定長処理は融通が利かない。
固定長という段階で、入出力ファイルの可搬性が著しく損なわれている。
COBOLで可変長扱うのは大変だから、固定長の方が簡単だと思っているCOBOLerは多いが、
可変長を簡単に扱える言語になれると、可変長の方が融通が利くことがわかるはず。

>>364
ものによりまする。
単純に比較してはなりませぬ。
それぞれの長所を短所を考え適材適所で使用するのが宜しい。

頭打ちだな。こぼるは。

>>364はド素人？
何を使うかはそれぞれ作る際の業務（仕組み）に
よって変えたらええやん　

ＣＯＢＯＬが出来ないとかという固定観念
持っているようでは所詮頭の悪いプログラマーレベルやね

大規模なシステムの構築するとＯＬＴＰの考慮が不可欠
そういうときには電文でのやり取りが多い
電文やり取りは固定長処理になる場合が多い
・・・やめたド素人に何言っても無駄だから

>>362
制約の多い環境から少ない環境へ進む方が、逆よりは楽でしょうな。

COBOL自体はいいけど
もう少し簡単な表記にして欲しい

MOVE A TO B.
でなくて
B=A
ではなぜいけない？

あと大文字しか使えないって言うのもめんどくさい
まぁ汎用機が小文字ないからこれは仕方がないか

その他
〜と等しくない
NOT =(COBOL)
<>(VB)
!=(C)

たまにどうしてもコンパイルが通らず悩んでいたら
隣の同僚が見た瞬間に　指摘した「＜＞」ってなに？
そうでした私はＣＯＢＯＬで＜＞を使っていたのでした

>>360
cobolを開発した博士がタイプミスが多い女史で、
あえて冗長な表現としたようです。

その意味で
「MOVE A TO B」 は良くないですね。
("A"と"B"は予約語ではないですが、
"C"はCOBOLの予約語です)

ちゃんと
MOVE WK-HOGE-A TO WK-HOGE-B.
等々冗長な表現で書いてください。(わら

英語の文章に似ていることがCOBOLの売りなので、あしからず。

ＷＫが未定義でもコンパイルが通り実行時にこける
ＰＬ／１より良い言語だ。

今期の新人です。来週からＣＯＢＯＬで仕事することになりました。
先輩がたよろしくお願いします。自分も立派なコボラーになります。

>>373
ご愁傷様です。

>>373
知らないよりは知っている方がいいと思う
ＭＳ−ＤＯＳ知っていて今でもよかったと思うし
ＣＯＢＯＬもやっててよかった

でもＪａｖａもＬｉｎｕｘもするよ

でもＬｉｎｕｘとＵｎｉｘの違い今でも良くわからない

違わないという解釈ではだめですか？

Linux=リナスが作ったPC-UNIXという定義でいるんですが。

>>1
Cは論外ですか？

ああ、めんどくさ。コボルなんて

ＣＯＢＯＬですか。。。そうですか。
いま勉強してますよ。学校で。。。

でもね、熟練したCOBOLプログラマのソースって、みてると、非常に美しくて、
ためになるよ。

実感としてね。

MOVE A TO B.は

YPS/COBOLならA → B と非常にシンプルな表記となりますが。笑

>>３８０

熟練したCプログラマのソースもね

>>382
うーん、如何だろう？
個人の環境が強過ぎるから読み易いとは到底思えない。

# マルチ言語を操る人のＣソースは読み易いけどね。

フランシスコッボラ

COBOLは、業務ニーズのわかる位置にいる人（ユーザ）に
プログラムを組ませることを狙い、成功した言語だ。
(BASICは所詮パソコン上のおもちゃだった。例外もあるが。）

オブジェクト指向なんて現実性（マシン能力とか）がなく、
構造化プログラミングが新鮮だった時代の言語だ。

レジスタだとかアドレスだとかそういった計算機の仕掛けを
理解しなくても、プログラムが組めるというのは
当時はすごいことだっただろうし、
革新的な言語としてとらえられたと想像する。

昨今、アイコンを並べることでプログラムを
作成させるツールをよく見かける。
計算機のアーキテクチャを意識させることなく
自然言語（英語圏）に近い形でプログラムを記述させるＣＯＢＯＬ言語は
ＣＵＩの時代のそれに近かったのではないだろうか？

COBOLとは、....
”野菜の皮をむく”（事務処理）という目的のためには
”皮むき”(COBOL)があればいい、
そういう言語だ。

一流のシェフは、皮むきも使うし、
細かい細工をするときには、それなりの道具をつかう。

皮むきには専用の道具があったほうがいいと考えた発想、
そして”皮むき”としての扱いやすさ、
と言う点で、COBOLはいい言語だと思う。
なんでもできることでよしとはしていない、ということだ。

ただ、”情報処理にはCOBOLは最高の言語である！”ということ
についてはやや疑問に思う。
１のゆう情報処理がホストでのバッチ帳票出力程度であれば、
そうかもしれない。
しかし、いま情報処理（死後かな？）はそれだけにとどまらない。
動的なHTML作成、GUIプログラミング、などといった領域への
対応はやはり新しい言語の方に分がある気がする。
まあ、 ＴＰモニタ上でビジネスロジックを記述する等、
まだまだＣＯＢＯＬを活かせる領域もあることにはあるけど。

それと、いわゆるコボラーへの軽蔑と
COBOLがいい言語であるかどうかは別物として考えて
もらいたい。COBOL言語の開発者に失礼だ。

csvファイルを取り扱うにはawkが最高の言語である。(でもない？)

そんなもののような。1つの言語に拘る方がおかしい。別にCobolでもCでもJavaでも
いいけどさ。

>>386
でも、awk便利だよね！

公共の福祉の為COBOLは必要な物である。

COBOLは鈍器。Cは鋭利な刃物。って印象。
大量のﾊﾞｯﾁ処理やらせたらHOST&COBOLの方が強いだろうし。
細かい処理等、Cのが強いだろうし。
斧(COBOL)で木(情報)を切り倒して彫刻刀(C)で整える、と。
うちではそれぞれそんな位置づけで使われておりますが。

彫刻刀だけで作る場合には、ちゃんとライブラリを充実させて、鈍器に
当たるものを作っとく必要性はありますな。Cのみだとそうなる。

>>385
全くその通りで論理的に反論はできないんだけどさ、でもさ、
なんでまだ若いのに COBOL で帳票出力程度のつまらん経理プログラム
なんか書かないとだめなんだよ。他の部署に配属になった同期は
いろいろ面白そうで、アルゴリズムとか工夫の余地が出てくるプログラム
を書けるというのに。

この世で一番くだらなく創造性の発揮する余地のないリーマン向け
プログラミングのための言語だよ。COBOL は。会社やめたくなった。

>>391
そういう会社を選んだのは誰ですか？

COBOLかぁ・・・なっつかしぃーーー

>>391
　同情する。（藁

　素人を寄せ付けないフィールドに行きたいなら、
　職場（場合によっては会社）の移動をおすすめする。
　今ならAPサーバの基盤関連とかがいいかも？

　今の職場でも、金融とかの特定の分野を担当しているなら、
　とことん業務面に強くなるのも手かも。
　　

>>392
俺だけど。だが、他の部署に行った奴らのやっていることこそ
俺のやりたかったことなんだよ。なんで俺だけ COBOL なんだ。

>>394
とりあえず 2 年は耐えるよ。3 年目までに他社で働ける技術
と知識を身につけて転職する。もちろん今の仕事から学べるもの
があるというなら学ぶし、ないなら仕事片手間にやりたいことを
勝手に勉強してやる。

結構やる気でこの会社選んだのに、ひたすら裏切られたよ。この
会社はあくまで踏み台にしてやる。

>>391
まあ落ち着いて考えようぜ。
俺もあんたと同じ状況に置かれたよ。
でももしかすると会社はもっと先のことを考えてるのかもよ？
いきなりオープン系いってもひたすら技術の波に流されっぱなし
で何も分からないまま時が過ぎそうじゃん。
COBOLでﾏﾀｰﾘとコンピューターについて理解していきましょう。

COBOLって簡単か？

人にもよるが、
「COBOLって簡単だぜ！」っていってるやつほど実力無し。
「結構COBOLって難しいし、何でも出来るんだぜ！」っていうやつは、COBOLバカ一代か、ただのDQNかのどちらか。

共通しているのは、みんな時代に取り残されてるってこと。
一緒に仕事するなら、COBOLバカ一代な人の方が１００倍ほどまし。

>>254
SQLについてもＲＤＢを使う限り
言語にかぎらずＳＱＬはついてまわる（ＣＯＢＯＬでもおんなじ）
情報処理うんぬんというようりＯＰＥＮ　汎用ＨＯＳＴで考えたら多少は
違うかもしれない
業務によってもんだいは四捨五入ＵＮＩＸ系だとこのあたりの制御が
言語でなんともならないし

．ＮＥＴ系言語(VB,C#)はビジネスにもいいらしいよ

>>385 がいいこと言った！
このテのスレ、もうやめろよ。
コボラーではなく、>>1 がバカ。

Ｆ系のＣＯＢＯＬ仕事、どんなサイトで探せばいいでしょうか

言語で議論はいいかげんばからしい・・・
初めてみる言語だって仕事でしょうがなければ
やる。
達成のしやすさの違いはあるけど単なる手段で
あり目的ではない

1月に始まって403か
まだまだ先は長いな
寝て待とう

ＣＯＢＯＬﾃﾅﾆ

>>404

ｃｏｂｏｌ８５よりはましでしょう

>>405 事務用共通言語

＞＞４０５

COBOLのBと

IBMのBは同じ意味

>>406
COBOL85
COBOL74
までは許せる
COBOL/S
は、いかんぞ！！
以上>>404

しまった
寝て待つのだった

>>409 ＣＯＢＯＬ／Ｓは変

>>1
でも反論したいお年頃。
「定型」事務処理って？変化しない？ウソつけ。
バリエーションが現れるたびにソースがコピーされ
てメンテがしにくくなってるよ。
JavaやC++とCOBOLの本質的な違いってなんだと思う？

ＣＯＢＯＬはどんな学校でおしえているのですか

>>413

私立極道高校

明訓学園

めだかの学校

凸凹大学校

のどこかでないでしょうか？

ＹＳＰ　ＣＯＢＯＬって知ってる奴いる？　（ｗ

>>415

ＹＰＳの間違いでしょう

>>1
定型的事務処理でソースを書くこと自体、ナンセンスなのだが。
ＰＧを抱えていて、むりやり仕事を作らないといけない業者の人かな？（ｗ

(((（ ;ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

>>415
YAC表記法に関係あります

>>415
ＹＳＰはオートバイに関係有りそう
ＹＰＳはピアノ

ＣＯＢＯＬは元ＰＧで結婚で引退したおばちゃんに
バイトの場を提供する最高の言語であることに異存なし！
かなり時給もいいし引く手数多だYO!

プログラム組ませて貰えるのですか
うれしい

ＣＡＳＥまではアリかと

OPEN系15年だが、
むかーし、COBOLに、ちょっとだけ、さわったことある。
そもそも、メインの目的が金計算のアプリをくんだことは
ないのだがC,java,VBあたりだと金計算の加減乗除が、
COBOLにくらべて、えれぇー、辛そうという印象をもってるのだが、
金計算の非COBOLアプリをかいてる人たちは、どうしてるんだろう。
(long long で64bitだから、加減だけなら、問題なしってか。）

>>424
普通は目的に応じた精度の関数を作って対処する。

>>425
ええっ！本当に！！
ひょっとしてそうなのかと思ってたのだが、
やっぱり、そうなの？
でも、それって、Ｃ，ＶＢあたりだけだよね。
javaだったら、オペレータオーバロードとかで、
何とかできるんですよね。
正直、javaは、あまりやってないんですよ。

．ＮＥＴはＣＯＢＯＬみたいに好きな桁で宣言できるＹＯ！
よってＣＯＢＯＬ不要

>>427
そうなんだ。
それって、Ｃ＃の話？
それとも、Visual Studio.netの
新しいＶＢの話？
＃目の前にVisual Studio.netころがってるけど
＃まだ、いれてないの

>>427
マジ？いまから試すが。

どうやって宣言すんの？

>>427
ネタですか？
まってるんですが。

勘違いでした。ごめんなさい。
COBOL.NETまで待つしかありません。

>>432
そうなんですか。残念。

>>432
COBOLマンセー！！

PL/1が最高。COBOLみたいにだらだら記述する必要もないし、生産性も絶対COBOLより高い。
だけど、マイナー。それと、PL/�Tやってると他の言語した時にあまり文法で戸惑う心配なし。
関数なんかも似てるのが多いし。他の言語っていってもCOBOLやＲＰＧならだめだけどね。

だから、ソース書く必要性から論じろよ！
未だにＣＯＢＯＬの領域でソース書くなんてどう言うケースだかヨ！

>435
ＰＬ／Ｉて、ＩＢＭ凡汎用機のみ使用出来る言語ですか
むかしは、他のメーカーでもしようできたのですが

>>435
PL/1ってBASEDが使えるCOBOLって感じで、あんまり違いがわからないな。
後、日立の汎用機（VOS3)でもPL/Iが使えたはず。

>>436
> だから、ソース書く必要性から論じろよ！
> 未だにＣＯＢＯＬの領域でソース書くなんてどう言うケースだかヨ！

熟練技術者を多数必要とする案件ならばＣＯＢＯＬ言語を選択するのは自然です。

# まぁ、後５年１０年？って寿命なんだけどね。
# そろそろ必要悪な部分が色濃くなって来てますから「うーん...」って悩みどころではあるけど
# オープン系技術者が未熟過ぎることもあって未だ生存しています。

>>438 それはゾーン１０進の表記が似てるだけでしょ。ＰＩＣ’９９９’とか・・・・
それ以外は全然ちがうよ。例えば代入なんかは MOVE XX TO XXX　じゃ無く　XX = XXX;　だし・・。

>>436 彼はオープン系の人？

Ｃだめっぽ
ＰＬ／１しらんぽ
ＶＢくさってるぽ
ＪＡＶＡおそいっぽ
ＣＯＢＯＬ最高！！
内部どうなってるのかなぁ
意外とＣＯＢＯＬで書いたほうがＣより処理早かったりして

Ｃ言語は、ばぐの宝庫

速度うんぬんで比較するならアセンブラが最高！
保守性、拡張性、最新テクノロジーならJava最高！
＃ただしマトモなプログラムとして
>>442 意外とＣＯＢＯＬで書いたほうがＣより処理早かったりして
コンパイラ次第でしょ。
ＰＣ用のマイクロフォーカスCOBOLってコンパイラなんてクソでしたYO!
発売予定らしいCOBOL.NETなら理論上、C#/VBとほぼ同じだろね。

>>442
JavaもCも、COBOL流コーディングするという罠

>>444
最近のCPUは、へたにアセンブラで描くと遅くなっちゃうよ。
同時実効性を損なわず、パイプラインが乱れないようにアセンブラで組むのは、
地獄のプログラミングとなること必至。

やい、お前ら、みずほのシステム障害の本読んだか？
「システム障害はどうしておきたのか？」
だったっけ？なかなかおもろかったよ。

>>446
って言うか、メインフレーム系とＰＣ系がゴチャゴチャになって論じられてるので
不毛ですわ。(貴方はUNIX系みたいだしね)

マルチスレッド・マルチタスクは意味が違うし処理方法も違う。
メインフレーム系のＣＯＢＯＬならば、単一スレッドではあるが非常に効率の良いコードが
生成されるし、ＰＣ系だと逆に効率が悪いけどマルチスレッド型のコードが生成されたりするからね。

更には、言語の特徴もあってポインタ系の処理になると同列に比較すること自体ナンセンスだしね。
（非同期処理等も同様）

# マイコン・ミニコン・ＰＣ・ＵＮＩＸ・メインフレーム全ての実務を経験している人って少ないからね。

>ＰＣ系だと逆に効率が悪いけどマルチスレッド型のコードが生成されたりするからね。

またわけのわからんことを。

>>449
ありゃりゃ、違うの？
ＰＣ系のＣＯＢＯＬってＧＵＩが拡張されてイベントドリブン処理も入ってると聞いたのだけど．．．
まあ、私はＰＣでＣＯＢＯＬ系やったことないし確証はないけどね♪

# 説明プリーズ

PC 系で COBOL 使うとこなんてあんのか。ほとんどメインフレーム
専用言語だろ > COBOL

>>446
よく知ってるな。汎用機で、アセンブラで組んで一度はまった。
分岐予測するため、アセンブラのブランチ命令を先に予測して
実行していた事があった。そのときは、すーげ悩んだ。
ソース何度も見たがなかなか解らなかった。

>>451
あるよ
金融系の大規模システムなんかで、ＣＯＢＯＬで組んだビジネスロジックを
ＣＯＲＢＡでくるんで分散システム上で動かしている例もある。
まだまだＪＡＶＡとかＣのＰＧを１００〜２００人集めるのは難しいからね。
あと、厳格なコーディング規約やテスト規約をオープン系のＰＧに仕込むのは時間かかるし。

PC系COBOLの代表といえばマイクロフォーカスCOBOLだったYO!
NECがライセンス受けていてN5200、PC-9801があった。
ネットで調べたら今もご健在でした。
http://www.microfocus.co.jp/
当時から余っているコボラーをＰＣの開発にまわせる意味合い強かった。

>439

熟練を必要としない技術してのみ、COBOLには存在価値があるのだよ。
　半年あれば、熟練者になれるのがCOBOL言語。
　それこそが、偉大なCOBOL言語なのだよ。

おれ、なんだか日本語が変だ。もう寝よう。

ＣＯＢＯＬって英語アレルギーだと困るよね。
スペル覚えられないから。

>>457
スペルといっても、ちょっとの単語数だろ。
そんなんのも覚えられないの？
UNIX系でちょっとマイナーな言語やってみてよ。
ドキュメント・参考資料・メーリングリストなどは、ほとんど英語しかないから。

IDENTIFICATION DIVISION.

>>453
ユーザ系の情シスの弱体化で、ＣＯＢＯＬ世代の人しかいなくってＰＣでも
ＣＯＢＯＬが重宝されることもあり
ちょっとかなしい。

>>460
？？単に人材不足だけが原因ならば、ＶＢにした方がいいに決まってるでしょ？
ＰＣだったら、ＡＰＩをたたく部分のヘルプが充実している言語の方が有利だ。

>>460の理解できないレベルの事情があるのではとオモワレ。

グローバル変数って何ですか？











BY　VB厨

ローカル変数じゃない変数。

>>461
世の中には世代構成で３０代１人、あとは４０代後半なんて情シスもある
んです。彼らはＣＯＢＯＬなら超プロで生産性がいいんです。
経費削減で外注もやとえず細々と内作してるんです。
ＶＢを進めてみましたが、結局ＣＯＢＯＬを買ってもらいました。

>>461
　ＣＯＢＯＬのバッチ処理をＶＢで実行するのは無謀です。
　プログラムできなくはないが、実行速度が・・・
　結局、Ｃ／Ｓでも集計は、ＣＯＢＯＬで作成したほうがいいです。

>>464
　最近、ＣＯＢＯＬなんて専門学校でも教えるところは少ないから
　一昔のＰＧの方々が重宝されてるみたいですね〜
　無くなりはしないと思うけど、ＣＯＢＯＬだけってのもＳＥ・ＰＧに
　とっては、仕事の幅を狭める要因になるので他の言語も必要ですね

厨房な質問ですんません。常々疑問に思ってることがあるので
誰か教えてくらはい。

よくＣＯＢＯＬやＰＬ／Ｉって１０進計算が得意で、ＶＢやＣＪＡＶＡ
なんかは１０進の型がないから、巨大な桁数による複雑な計算をすると
情報落ちや桁落ちによる誤差が発生する、っていいますよね？
だから、金融（特に銀行融資や生命保険の運用、ＡＬＭ（資産と負債の将来
予想のようなもの）といった、長期的な期間におよぶ計算なんか
ではどうしても誤差が出やすい為、ＣＯＢＯＬが手放せないってよく語られます。

でも、コンピュータの中身って結局なんであれ、ノイマン型計算機であれば
みんな２進計算をしているわけでしょ？だったらどうしてＣＯＢＯＬなんか
では１０進計算が正確にできるっていえるのでしょうか？
どうもそのへんの理屈がよくわかんなくって・・・

個人的には変数エリアの切り方（Ｃ言語等は型指定のみ、ＣＯＢＯＬは
型とレングスを指定）にヒミツがあると思ってるのですが

>>466
　自分のいっていること、その通りだよ。

　桁数指定ができることが大きいと、おれも思うが、
　桁落ち云々って、COBOLでもしなかったっけ？（正直忘れた）

　それから、ちょっと言い過ぎだろうとは思うけど、
　COBOLのゾーン形式とかパック形式というのは、ある意味オブジェクト。
　印刷時のフォーマット指定等も含めて、
　C++でモドキのデータ型作ってみるのも面白いでしょう。
　（結構いい考えでない？もう存在していたりするかもしれんが）

>>466
10進数の演算ライブラリを使うと、どんな言語でも正しく扱えます。

COBOLの処理系にもよるのですが、COBOLはBCD演算をするものが多いですから、
そいうった幻想が世の中にはびこっているのだと思います。

466は、BCD というキーワードで、ググってみてください。
ご希望の回答が得れるかと思います

>>459
PROGRAM-ID. プログラム名.

前の仕事で、ＣＯＢＯＬ使ってました。
ＰＧの人たちがＣＯＢＯＬのＤＱＮで、予定の期日に間に合わず、
結局、そいつらを切り、徹夜作業でＰＧ作成・単体テストした。（悲
ＣＯＢＯＬ出来ないんなら、仕事請けないで欲しい。

他の言語では、デバックとかはやらなくていいんですか？

前の議論でも出てたけど、ある程度簡単にプログラミングできる言語は、とくにビジネスロジックを記述する上ではほしいはず。COBOLはその点では（メインフレームとかにいい言語がないだけかもしれませんが）いい言語とは思います。

でもJAVAがnativeもしくはそれに近い速度で実行できるのならCOBOLは捨てていいという気がするね。言語仕様的にはJAVAのほうが洗練されているし。
まだメインフレームやミニコンではJAVAってそんなに速くなさそうだから。

（実はメインフレームやミニコンでのJAVAがどんなものかはよくしらないｗ）

>>471
遅ければ、ネイティブコンパイラを通せばよいだけの話である。

ま板　たいへんなことに、どうでもよいですけど

>>472
Javaにネイティブコンパイラってあったっけ？
少なくともPC以外では見たことないけど。

>>459
>>469
次これ
AUTHOR. [作成者名.]

age

age

>>475
ＩＮＳＴＡＬＬＡＴＩＯＮ．ＥＬＥＣＴＲＯＴＥＣＨＮＩＣＡＬ　ＬＡＢＯＲＡＯＲＹ．

オブジェクト指向のコボルってどうよ。

>>479
先に構造化しないと．．．．．．

えっ？とっくに構造化されてるよ

ビジュアル・コボルの事を言っていると思われる。
開発ツールとして使用されている現場を見たことはないが・・・

第4次規格には提案されてるらしいぞ。オブジェクト指向化の機能。

裏社会/ちくり裏情報に

■ここのＳＩｅｒには発注してはイケナイ！■

スレ立てました。ヨロシコ

> ある程度簡単にプログラミングできる言語は、とくにビジネスロジックを
> 記述する上ではほしいはず。COBOLはその点では（メインフレームとかに
> いい言語がないだけかもしれませんが）いい言語とは思います。

COBOLが簡単だという話はたまに聞きますが、家電製品みたいなもので、その
仕様上、言語自体にできること（＝命令）を、事務処理に特化した命令群に
意図的に絞り込んでいたことが理由だと思います。
少々乱暴に言うと、"機能が少ないから、覚えることも知れている"ということ
です。（裏腹な話だと思うんですけどね。）

例えば昨今、PCのCOBOLには、APIコール等を可能とするものや、ActiveXオブ
ジェクトを操作できる製品が、相当数出ています。
こういう処理をコーディングし始めると、COBOLが持っていた「はずの」簡
単さは薄れていきます。

そういう機能を使わなければ、簡単ですし、使う以上は一定の知識を要求され
ます。これは、言語がＶＢ、Ｊａｖａとて同じです。
他にも、ファイルシステム、ＲＤＢＭＳアクセス、ネットワークアクセス等
言語の外に存在する処理は色々あります。

>>485
自己レスで補足ですが、汎用機上でのCOBOLの存在意義は間違いなくあり、
その役割を十分果たしてきたものと思います。
しかし、今後のPC上での新規開発案件ではどうかというと、

・過去のプログラム資産を引き継いでの開発が前提である
・年輩（失礼！）のPG開発要員を、人件費の算段抜きで有効活用する
・動作環境のミドルウェア上、指定された言語製品である

といった余程の特殊な事情でもない限り、採用の意義はないのでは？
むしろ、その後のメンテナンス要員に特殊スキル（＝COBOL言語の習得）
が必要なことを考えると、負の資産となるリスクがあります。

偽装派遣会社の営業をやっていたけど、コボルの引き合いは、まだまだ多いよ。
たぶんＣより多い。

>>486
>・過去のプログラム資産を引き継いでの開発が前提である
>・年輩（失礼！）のPG開発要員を、人件費の算段抜きで有効活用する
>・動作環境のミドルウェア上、指定された言語製品である
>
>といった余程の特殊な事情でもない限り、採用の意義はないのでは？

どこが特殊やねん？（藁）むしろ典型的なんじゃないの？
（２番目は確かに特殊か！）

>その後のメンテナンス要員に特殊スキル（＝COBOL言語の習得）
>が必要なことを考えると、負の資産となるリスクがあります。

最近は学生もJavaから入ると聞くし、確かにそうかもね。
やっぱ、EJB化推進状況なんかをみると
オンライン（死後？）はJavaなんだろね。

でもWebサービスとかいろいろ言い始めても、
バッチ処理はどうする？Javaか？（藁

専門学生の頃、ＣＯＢＯＬでＲＰＧ作ったＹＯ！

>>489
ＣＯＢＯＬでＲＰＧ（Report Program Generator）　どの様な
手法で製作するのですか。教えてください
まさか、ゲームではないでしょうね
Ｒｅｐｏｒｔ　Ｐｒｏｇｒａｍ　Ｇｅｎｅｒａｔｏｒ？

うん。

多分来週出向なんですが今日からCOBOLをやれと言われました、参考書よんだのですがよくわかりません。私はC++等の方がとっつき安さの点では勝ってると思いますが、慣れたらどうでもいいんでしょうかね
意味不明なのでさげ。住人の皆様失礼しました。

>>488
> どこが特殊やねん？（藁）むしろ典型的なんじゃないの？
うむ。特殊ではないですね。訂正します。

>　バッチ処理はどうする？Javaか？（藁
Javaって自分実は経験がないんですが。バイトコードの状態か
ら、事前にCPUネイティブなバイナリにプリコンパイルしておく
ことで、処理速度って改善されたりしないんですか？それなら
javaで十分いけるんではないかと、素人考えでは思うのですが。

age

最近は、昔みたいにバッチ処理で帳票出力ということが少ない。
というか昔のバッチ処理の帳票程度は、
利用者が見たいときにOLAPでサクサクと処理できることが多く、
昔ほどバッチは作りません。
バッチは、java でも perl でも c++ でも、すきなのでやれば良いんじゃないですか？
その気であれば VB でやってもかまいませんよ。推奨はしませんが・・・

>>495
　バッチ処理＝帳票出力とされていますが．．．そうじゃないでしょ！
　まあ、帳票自体は少なくなってはいるけど、キューブ作るまでに何をしている？
　（業務システムのＤＢからバッチ処理なしで勝手にキューブが出来上がる
　　ようなシステムって、ものすごい特殊だと思う。...ないとはいわんが）

>>493
　有名な事例では、某日本を代表する自動車会社Tの大規模システムの刷新は
　　オンライン系：Jａｖａ、バッチ：ＣＯＢＯＬ　だよ．
　　つきぬけ怖くてバッチでＪａｖａなんぞ．．．現時点ではだけどね．．．
　　それにバッチ部分がただ処理速度云々でそれが決まるわけでもない。

　　ＣＯＢＯＬ（というか保守的な言語）が選ばれる理由としては、
（１）「プログラムっていうのは連続、判定、繰返の３つから構成される」
　　　ということだけで思考してプログラムを作るのは非常に楽だ。
（２）バッチプログラムは比較的単純。
　　　オブジェクトとして頭使って（？）つくるより、力技でも十分対応可能。
　　（バッチだから、基本的にファイルね。
　　　ＧＵＩだとかオンラインＡＰ制御等と比較すると
　　　プログラムで制御しなくてはならないオブジェクトは
　　　非常に限られたもの。）
（３）バッチの仕様が決まるのは比較的遅い。
　　　オブジェクト指向できれいに設計して、
　　　再利用のしやすさで開発効率向上！という言い分よりも、大事なことがある。
　　　もちろん、納期。
　　　バッチプログラムがきれいに設計できなく保守性が悪いし、処理効率も
　　　もっと改善できるからカットオーバ３ヶ月先！なんてのはやっぱＮＧだよな。
　　　ＧｏｏｄＥｎｏｕｇｈの発想、大事。　

　　　結局、道具は使いよう。
　　　なんでも一つの道具でやうろするのは、ある意味、技術者の怠慢かもしれない。

他のｽﾚとか本屋の本とか見ると、
なんでCOBOL→VBという風に転向する人がいるみたいなんだけど、
なぜでしょうか？
なんか共通点とかあるんでしょうか？

>なんでCOBOL→VBという風に転向する人がいるみたいなんだけど、
>COBOL→VBという風に転向する人がいるみたいなんだけど、

厨な質問でｽﾏｿ。

　　　　　　　　　　　　　　　　＼　│　／
　　　　　　　　　　　　　　　　　／￣＼　　 ／￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　─（ ﾟ ∀ ﾟ ）＜　ＣＯＢＯＬＣＯＢＯＬ！
　　　　　　　　　　　　　　　　　＼＿／　　 ＼＿＿＿＿＿＿＿＿
　　　　　　　　　　　　　　　　／　│　＼
　　　　　　　　　　　　　　　　　　　 ∩ ∧　∧　　／￣￣￣￣￣￣￣￣￣￣￣￣
￣￣￣￣￣￣￣￣＼∩ ∧　∧　＼（ ﾟ∀ﾟ）＜　ＣＯＢＯＬＣＯＢＯＬＣＯＢＯＬ！
ＣＯＢＯＬ〜〜〜！ 　 ＞（ ﾟ∀ﾟ ）/ ｜　　　　/　＼＿＿＿＿＿＿＿＿＿＿＿＿
＿＿＿＿＿＿＿＿／ ｜　　　 〈　｜　　　｜
　　　　　　　　　　　　　 /　／＼_」　/　／＼」
　　　　　　　　　　　　　 ￣　　　　 / ／

わたす　ＲＰＧＦＯＲＴＲＡＮＰＬ／ＩＢＡＳＩＣ、＞ＣＯＢＯＬ−＞Ｃ、Ｃ＋＋っときますた

>>497
COBOLer＞COBOL案件数
↓
要員育成費用：COBOL→VB＜COBOL→C or C++

>>500
RPG…AS/400ですな。結構凄い遍歴ですね（感服）
次はweb系の原語でしょうか？

ＶＢ→ＣＯＢＯＬ　に転向、させられた。
極めて退屈。。。

でもＣＯＢＯＬが一番いいです。言語よりシステムがうまく稼動すること
が快感になってます。

ばーか！！最高なのは、Ｎ８８−ＢＡＳＩＣなんだよーん。

>>502
COBOLはおもしろいよお！凝ったプログラムにするとホントに英文みたいになる。
構造化COBOLはその点ではつまんないけどね。
まあ、現場でそんなソースコード打ち込んだら問題になるのは必至だが

>>505
すると、こんな英文になるのか？

DO NOT HESITATE TO THROW YOUR SKILL OF COBOL.

>>504
禿同！

N8001-BASIC?

　　　　　　　　　　　　　　　　＼　│　／
　　　　　　　　　　　　　　　　　／￣＼　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　─（ ﾟ ∀ ﾟ ）＜　Ｎ８８−ＢＡＳＩＣＮ８８−ＢＡＳＩＣ！
　　　　　　　　　　　　　　　　　＼＿／　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　　　　　　　　　　　／　│　＼
　　　　　　　　　　　　　　　　　　　 ∩ ∧　∧　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
￣￣￣￣￣￣￣￣＼∩ ∧　∧　＼（ ﾟ∀ﾟ）＜　Ｎ８８−ＢＡＳＩＣＮ８８−ＢＡＳＩＣＮ８８−ＢＡＳＩＣ！
Ｎ８８−ＢＡＳＩＣ〜！！＞（ ﾟ∀ﾟ ）/ ｜　　　　/　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
＿＿＿＿＿＿＿＿／ ｜　　　 〈　｜　　　｜
　　　　　　　　　　　　　 /　／＼_」　/　／＼」
　　　　　　　　　　　　　 ￣　　　　 / ／

ＰＣ−６００１
ＰＣ−８００１

>>506
ｓｙｎｔａｘ　ｅｒｒｏｒ！

>>511
英小文字かよ！！！
せめてANC英大文字で表示してくれよ！

> 498
ＣＯＢＯＬとＶＢは、日本語と英語くらいの違いがあります。
ＣとＶＢは、英語と独語くらいの違いでしょうか。
ＣＯＢＯＬとＣは、日本語とスワヒリ語ぐらいの違いです。

>>513
ＣＯＢＯＬとＣは、日本語と独語ぐらいの違いじゃないのかよ！
何故にスワヒリ語？！


















と言ってみるテスト

>>513
そんなお前は、スワヒリ語を知ってるのか？
活用がめちゃ複雑で、なにがなんだかわからんぞ。あの言語は。
おまけに習得しても活用する機会無し。
通訳の仕事を頼まれても小さい商談の通訳だから、小銭程度の日当しか出ない。

変わった言語を習得したいのなら、アラビア語とイスラムの心を学びなさい。
とりあえず、収入は良いぞな。

>>515
厳密にはイスラーム


















と言ってみるテスト

うーん、言語が単純だとそれで具現化される製品が単純だと思ってるバカが多いですな（笑

# もう少し頭使ってね♪

>>517
うーん、単純な煽りにしか聞こえないですな（笑





















と言ってみるテスト

>>517
仕事を沢山抱えてると言う割りには寝るのが遅いな。
ＣＯＢＯＬスレに付き合っている暇はないだろう。
大名出社して周りの反感買うなよ。
肝に銘じているとは思うが、労働単価が高いと顧客の目も厳しいぞ。

あのー自分cobolで200本位で作ったシステムをVBで4本で
作り直したんだけど。cobolで必死になる時代じゃないんじゃないか。
値段も1/15程度の請求しかしなかった。

>>520
そりゃ勿体無いことしたね。
成果物の付加価値で請求するようにせんとボランティアになっちゃうよ。

>>521
でも逆の立場なら、御自身がボランティアを求めるでしょ？
そんな野暮はしない？正当な対価を払いますか？

520 > ＶＢで４本と言うのは、EXEの数ですよね。
確かに、オンライン系の処理は、ＣＯＢＯＬよりもＶＢの方が生産性が高いと思います。
作りながらデバックできますし・・・
ただ、バッチ系の処理は、ＣＯＢＯＬの方が便利な場合もあります。

>>521
成果物の付加価値はそんなもの。
ハードも安くなるようにソフトも安くなります。
一太郎をご覧なさい。機能はインフレ、価格はデフレ。
１５年前は１０万円してたのが、今じゃ１万円でお釣りが来ますよ。

COBOLも変わらなきゃね。

>>522
逆の立場は関係ないよ。（ビジネスは基本が大事だよね）

>>524
10年前の所得が今の10倍で現在の所得が1/10ならば納得するんだけどね♪
言語の違いによる効率化で10倍なんてことは限定条件を満たす限られた場面だけですわ。（笑

# 10年前の技術者の平均的質と現在の技術者の平均的質を比べても今のほうが悪いように感じますしね。

>>ＣＯＢＯＬとＶＢは、日本語と英語くらいの違いがあります。
>>ＣとＶＢは、英語と独語くらいの違いでしょうか。
>>ＣＯＢＯＬとＣは、日本語とスワヒリ語ぐらいの違いです。
変な比較？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？
ｱﾌｫ

http://mona.2ch.net/546/qwertyuiop.html

http://jumper.jp/yyyu/ 携帯用

　　中高生とHな出会い
　　　 即アポ即H出来る
　　　超最高なH＆Hが・・　

>>525
＞逆の立場は関係ないよ。（ビジネスは基本が大事だよね）
この点で、貴方と同等レベルの経験と技術を持っている者と対峙した時、貴方は負けるね。
その様な者は業界内に数少ないと思っているかも知れませんが。さあどうでしょう？

>>528
「逆の立場は関係ないよ」の意味を貴方はどのように受取られたのでしょうか？
「ビジネスは基本が大事だよね」って助言も書き添えたのだけど通じなかったのかな？

>>529
この程度の話が総括出来なければヤヴァイぞ

いいから本筋に戻ってくれ。次次。

>>531
禿しく同意

出張32は放置しろよ。バナー広告みたいなもんだと思えばいい。
以下、反応はしないようにお願いします。
構ってくれなくてすねる出張32を楽しむのも一興。

>>533
いいこと言うね。

>>533
結構ナルシストだからすねやすいしね。
どうせ他のスレに逝って同じ事を繰り返すだけだろうけどね。

>>533
バナー広告カット機能の様な、出張32の発言が表示されないソフト誰か作らねーかな？ｗ

>>536
かちゅーしゃ + uhyoskin でいいだろ
しかし彼のバイタリティには感心するね
それを仕事に向けてくれればいいんだけど(あ、周りの人とかお客さんに迷惑かw)

本筋戻し希望age

>>538
じゃあ何かつらつら書いてみるよ。

COBOLとPL/I
　　DECIMAL 18桁のCOBOLが良い
　　ABEND DUMPのデータ部はCOBOLの方が見やすい（WORKING STRAGEの定義順で記録されてる）
　　PL/Iはポインター処理で一日の長
　　PL/IはちゃんとDO〜END書かないと暴走する事あり

COBOLの嫌なところ
　　ポインター処理不得手（使えるver.もあるのかな？）
　　ハーフバイト使えない
　　ファイルの動的ALLOCATION不得手（DIVISION分けしてるからなあ）
　　データ群をテーブルの形状でしか捉えられない

COBOLの好きなところ
　　集団項目形式を文字列項目として扱える
　　異なるデータ形式の移送制約がゆるい

その他
　　桁あふれ処理はコンパイル時指定に拠ります（言うまでもなく桁あふれ時フォローなしが最速）


こんな感じかな？
まあ後は反論も意見も、つらつらとやってください。

ＣＯＢＯＬ２００２最高や！

COBOL2002は今年中に国際規格（ISO）が制定、
日本では2003年〜2004年にJIS規格化される予定になっておる。

>>540-541
これか？
http://www.cobol.gr.jp/knowledge/next_standard/standard0002/cobol2002.pdf

>>542
そや。MSとかからVisualCOBOL2002なんての出さないかなぁ。

>>543
変な方言が入りそうでいや

大星紘由企

今時前向きな理由でCOBOLなんぞ採用するとこなんぞ無いつーことで

===========================終了==============================

>>546

ど素人は黙っていた方がいいよ

>547はcobolしかしらねーじじい

>>548

無知の知ってしってる？

ど素人の戯言はやめてね

>>548　頭わるい発言（ｗ

今時前向きな理由でCOBOLなんぞ採用するとこなんぞ無いつーことで

===========================終了==============================

>>551

言語なんぞにこだわる自体が素人　それとも単なる下請け？

ユーザー側の人間ですが何か？
COBOLが最高なんて言ってる馬鹿には仕事渡しません

>>553

最高とは思わないが選択肢の一つ
ユーザが言語の事を云々言わないように

それぞれ業務及びハードに適したものを選択するのは当然
他の言語知ってるの？

おまえらコボコン行った？

ＣＯＢＯＬ（汎用系）のソースコードを読んで仕様を理解し、
ＶＢ（Ｃ／Ｓ系）やＪＡＶＡ（Ｗｅｂ系）のシステムにカスタマイズできれば
現状は、仕事に困ることはないと思います。

　　　　　　 　 　 　 　∩
　　　　　　　 　　　　 | |
　　　　　　 　　　　　 | |
　　　　　 　　　　　　 | |
　　　　 　　　　　　　 | |
　　　 　　 ∧＿∧　 | |　　　 ／￣￣￣￣￣￣￣￣￣￣￣
　　　　 　（　´Д｀）／/　　＜　 先生！ＨＰＬの解析がしんどいです！
　　　　　 ／ 　　　　/　　　　＼＿＿＿＿＿＿＿＿＿＿＿
　　　　 / /|　　　　/
　 ＿＿| | .|　　　　|　＿_
　 ＼　 ￣￣￣￣￣　　 ＼
　　||＼　　　　　　　　　　　 ＼
　　||＼||￣￣￣￣￣￣￣||￣
　　||　 ||￣￣￣￣￣￣￣||
　　 　 .||　 　 　 　 　 　 　 ||

>>557
代わりにアセンブラやるか？ん？

（＾＾）