ttp://pc8.2ch.net/test/read.cgi/tech/1068819212/
それともCOBOLを高く評価してるのか
前スレを見る限り、COBOLの信頼性、汎用性、保守性を高く評価しつつ、
2007年問題に代表されるCOBOLER技術者激減を見据え、
COBOLからJavaに移行したらいいではないか、という提案をする
どちらかというとCOBOLマンセー者と、それに対するJava房と、
ときたま乱入するVagenとかCSPとかVisualAgeforJavaとかの房とは
なぜだかたまにWeb2.0とかはてながどうとかこうとかという話題の出る
ある種雑多な話題を扱う激熱スレです。
未来なきJavaなど冒涜する気にもならない。
おまいの未来無き人生に乾杯
Javaばかり信奉していてもろくなことにはならない。
大事なことは、OOPやUMLなど本質を抑えること。
Javaがいいだの悪いだの、言語で騒いでも仕方ない。
結局、もっと優れた言語が現れればJavaも消えるし、
プロジェクトによっては既に言語が既定になっていることもあるだろう。
大事なのは目と本質。
50年後には各自ちゅにCOBOLは死滅します
開発の二大潮流は.NETとJavaだと俺は見ている。
それぞれの特徴は下記のとおり。
.NET：マルチ言語（C#、VB.NET、J#、C++/CLI、COBOL.NETなど）、シングルOS（Windows系のみが一般的）
Java：シングル言語（Javaのみ。当然だが）、マルチOS（JVM搭載すればOSは問わない）
ここで重要なのが.NETの場合、多彩な言語に対応しており、
開発者の得意な言語が使用できる、という特徴がある。
この場合、COBOLやCSPに馴染み深い開発者は、COBOL.NETで開発できるという
メリットが発生する。
しかし、JVMで動作するプログラムを作るには、COBOLでは不可能であり
Javaを覚えるしかない。
つまり、団塊の世代（所謂「COBOLの波を浴びた世代」）にとって、
Javaを初歩から覚えなくとも、COBOL.NETを使用すれば
それほどストレスなく開発できるのだ。
今後の.NETの普及が拡大するにつれ、このメリットは等比級数的に増大すると
我々は睨んでいる。
フリーの実装が出てこないとも限らないわけだが。
つJ#
つうかいまさら団塊の世代を労働者に回すよりも
消費者に回ってもらった方が世の中的にメリットが多いから早いところ引退させろってのが時代の流れ
将来ある若人をCOBOLerにしても何も問題ないのではないか。
COBOLのニーズがあるなら、団塊の世代以外を技術者にしたてあげるのも
ひとつの方法だ。
それに、今の時代は生産者と消費者が同一であり、
ある場面では生産者、ある場面では消費者、というふうに
二面性を持っている（いわばポストモダンの「消費は美徳」）ので、段階の世代を労働者に回すからといって
それすなわちNOT消費者であるとはいえないと思う。
両方使えばいんじゃね。
どっちも業務向き言語である事だし。
アッチョンブリケ
やっとまともで前向きな議論が。
なんとかするイメージが強いんだが
COBOLが帳票に向いているってのは、どの辺の事を言っているのかな。
歴史が長いからツールが充実しているって事なのかな。
俺が去年仕事してた大企業では、実際にフロント処理はJavaで、帳票はCOBOLでやってた。
その前に仕事した金融系でも、全国の顧客への通知書はCOBOLでやってた。
EXCELとかで帳票も作ってたが社内の担当者向け。
逆に聞きたいのだが、全国規模の大企業クラスで顧客向け帳票をJavaとサードパーティ製のツールだけでやってる所ってあるの？
ただ、COBOLの優れているってのは何なのかな〜て思っただけで。
金融だと地銀をやったことあるけど、そこはExcelのテンプレート用意して、
サーバサイドでガリガリやってダウンロードっていう、あんまカッコよくない奴だったよ。
全国規模で言えば某メーカー系をやったことあるけど、
そこはVB.NET＋クリスタルレポートだった。
帳票だす端末は限られているとはいえ、せっかくのリッチクライアントなのにクライアントにインスコかよって思ったのは秘密だ。
Webで一番スマートなやりかたってなんなんだろうね。
やっぱPDFに落とすのかな？
ふぁいぶりっじとか言うﾂｶｴﾈｰ電子化帳票な配布ｼｽﾃﾑ(なんだろうか?)
を使っているのをみた。
データの作成はPL1かCOBOLっぽかったが。
内心ではノーツがあるならそのインフラ使えばいいのに…。
と思う漏れがいた。
＞Webで一番スマートなやりかたってなんなんだろうね。
＞やっぱPDFに落とすのかな？
スマートかどうかは知らんけど漏れは印刷用Web画面をタマに
用意しとくけど。
そこから印刷orPDFにするのはユーザー任せ
最近の奴らは見た事無いのかも知れないが高速プリンタとか言う
激早のラインプリンタを使えるのは汎用機位な物だ
1時間で数千頁位は出力出来るんじゃなかった？
あるなぁ。印刷音もすざまじいモノがあったが。
ｲﾝﾀｰﾌｪｲｽもﾂｲﾝﾅｯｸｽとかいう今は亡き接続方だったような。
現役の部署もあると思うけど。
CanonのレーザープリンタにはIBMの5577(だったかなぁ）の
ｴﾐｭﾚｰｼｮﾝｶｰﾄﾞがあるし、Windowsにそういったプリンターの
ｴﾐｭﾚｰﾀｰってあるし、ｾﾞﾛｯｸｽとかにUNIX内蔵のプリンタとかは
汎用機とWindows印刷と混在出来るよ。
ﾘｺｰも同様の事ができたと思う。
今時だと途中で人身御供なPCが１台ほど必要になる場合もあるだろうけど、
ノーマル1P用紙で汎用的な帳票なら使えない事はない。
たぶん、一昔前のクレジットカードの明細用紙みたいな、特殊フォーマットの
帳票なんかがCOBOLで組んであって直すのがﾏﾝﾄﾞｸｾって理由なんじゃないかな。
やりゃあ解るがWindowsでアレに出すと激しく遅い
直接ドライバ書くと汎用機並みに出力できるけどまあそういう事だ
psにいったん変換して後はホスト任せだと思ったが。
IOCAとか使用してもダメなんでしょうね。
クレジットとかガス、電気、水道、携帯の明細とかだと
毎月毎月、何十万〜何百万（何千万？）枚も刷らなきゃいけなかったりするのか。
こゆ安定したバッチ処理はたしかにCOBOLの得意分野だ。
COBOLじゃなくて汎用機（のプリンタ）の得意分野
つーか、本質的にはCOBOLよりRPGのほうが得意 (環境限定だけどー)
小型車ほどあるでっかいやつ。
漏れもRPGの方が得意だと思うが、他の言語(Java,SQL)を知ると
RPGは触りたくなくなる。
読み方によっては語呂合わせで
「プリンタみなとまるこのページ」
って読めるしね。
偶然にも。
∧＿∧
∧＿∧ （´<_ ｀ ） それはひょっとしてギャグでいっているのか？
（ ´ _ゝ`） / ⌒i
／ ＼ | |
/ /￣￣￣￣/ |
＿_(__ﾆつ/ ＦＭＶ / .| .|＿＿＿＿
＼/＿＿＿＿/ （u ⊃
それはＡＡが違うだろう？
＼＼＼
(⌒＼ ∧＿∧
＼ ヽヽ（ ´_ゝ`）
(mJ ⌒＼
ﾉ ∩兄 / ／
（ | .|∧＿∧ＯＫＯＫ。
／＼丿 | （ ） 兄者マテ！落ち着けって！
(___へ＿ノ ゝ＿＿ノ
Java,SQLを知ると、RPGのよさも感じられると思うぞ。
ｶﾞﾝｶﾞﾙとパック１０進数エリアに文字を叩き込むとか
文字エリアにパック１０進数を無理に叩き込んで、
コンパイルオプションでエラー無視にしとくと、
エラーが発生しても落ちない無敵のPGMが出来る事か？
いるんだよ…。マジでそういうRPGﾌﾟﾛｸﾞﾗﾏｰ
MONMSGをを全ｷｬﾝｾﾙしてたりさー。
文字化けしっぱなしでもテーブルに出力できるよ。
その後DFUと言うツールでデータ見たり、変更しようと思ったら
「フィールドに不正な値が入っています」とOSに怒られます。
そしたら16進数で直接データを編集できるツールで修正するか、
SQLで強制UPDATEとかしないと復活不可能だったり。
まあ、コレもKEYにﾃﾞﾀﾗﾒな値入れられていたら泣くしかないんだが。
EDTFなんかでゴリゴリやるのと変わらんな。
例えばある機能を追加するのに修正するＰＧＭが２個、物理ファイルが１だとしても、
その物理ファイルを使用しているPGMが１００個あったとしたら
リコンパイル１００個に動作検証１００個しなきゃいけないじゃん。
で、そういう時は物理ファイルに仕込んでいたCOBOLerお得意の無意味なFILLERの
文字エリアにパック１０進数を読み書きする様にPGM修正を行い、
魔法のコンパイルオプションを使えば修正PGM2本だけ、動作検証２本だけ
でミッションクリティカル（ｗ）な業務の変更にも対応可能だ。
orz
@ITは漏れも興味のある記事読んでいるけど、さすがに
RPGと言うかiSeriesの特有の世界について記事の
かけるエンジニアなんていないだろ。
漏れ自身が会社で唯一iSeriesでWebSphereAppricationServer
いじれる人間だしなぁ。技術的な交流が出来る人って
IBMの中の人しかいないので寂しいんだが（ｗ
iSeriesのエンジニアがいても90%がRPG+CLしか知らんヤツばっかだと思う。
そもそもそんな言語は使えねぇなｗ
compute b = d - e.
compute a rounded = (b / c) * 100.
divide f into g remainder check digit. みたいな。
ユーザインターフェースの部分はjavaでやってあげて、夜間のバッチ処理などはcobolとか・・・
案件を自分のスタイルにハメようとした人がいたけど、
そのソースみたら別の意味で複雑（ｗ）だっただけだったな。
ユーザーインターフェイスはVBでもなんでもいいんだが、
バッチ処理なんかはSQLでいいよ。
複雑すぎて保守性の悪いSQLはちょっと…。
何事もほどほどに…。
グダグダなストアドもタマにみるけどな・・・。
Javaは全部streamにしたから、これがない。
で、まだ、ドットプリンタで複写用紙を使っている企業は、COBOLの書式付き出力が必要。
レーザープリンタで処理している企業は、別に必要ないのだが。
もっとちゃんと調べる習慣つけなきゃCOBOLの仕事以外じゃあ通用しないと思うよ。。
煽りじゃなくって。
目の前でWindows機(確かVB)でドットプリンタな印刷しているワケだが。
「COBOLが向いている」と言う意見ならともかく、「COBOLが必要」と言う
時点で世間からは相当なDQNと認定されてる可哀相なエンジニアだな。
多いと言いたいだけだよ。COBOLは過去の遺産を生かせるという意味はあるが、
江戸時代の遺産で100年も食っていけると思うSEは時代遅れだろ？
オフコンやらDOSを使っている企業も相当数あると思うがね。ピン折れでドットプリンタ
を買い換えるときにその価格の高さでシステムを乗り換える企業も多い。そんなもんだろ。
米国から輸入するとほとんどレーザプリンタで、処理していることが
わかる。
日本の企業の伝票優先主義が、根底にあると思うよ。
COBOLにラインプリンタとかの仕事が多かった、って意見は
それはそれでいいし、昔のブツを大切に使いつづける姿勢は
それはそれでいいと思うよ。
ただ世間で嫌われているCOBOLerは、そうやって昔のシステムが
リプレースの時期に、妙な意見を言い出すから、ウザいって事だな。
データベースにOracle選択しておいて、開発言語がSQLじゃなくて
COBOLって具合にな。
そして現在の技術を勉強せずにひたすらｸﾀﾞﾗﾈｪ、デスマを
繰り返したりするから始末におえん。
藻前ら索引って知ってるか？って感じだ。
確かCOBOLでSAM形式のファイルを作成してそれをOracleにロードしていた。
処理もSAM形式にしてCOBOLで処理していた。
だから、そのチームのエンジニアはOracleで運用・開発していると言っても、
RDBでもなんでもなくて、カラムが200〜300くらいあるデータを送ってくる。
Oracleは単なる詰め物と化していた。
で、COBOLerはありえない重複データを作成するミスがあっても平気で納品してくる。
受け取った漏れの運用・開発システム(DB2)がお約束で主キーの制約に
ひっかかってアベンドしますた。
SQL書くよりなんぼか早かった。
そういや五年くらい前、VB（旧）、Javaとそれぞれバッチを書いたけど、
どっちもパフォーマンスで爆死したな〜ｗ
今はどうなんだろうね、Javaで大量バッチはあまり聞かないけど、
当時よりはだいぶよくなったのかな。
最近は小物（ASPとかPHPばっかり…）しかやってないからわからないや。
SQL通していちいち最適化考えさせるより、開いて頭から逐次処理するだけだし。
AS/400でCPYFコマンドでなくて、OPNQRYコマンドで
ファイルコピーしていたな…。
で、「これでコピー速度が上がります」と自慢していたが、
あのコマンドは一切のエラーチェックをしないので、
お約束で不正なデータを垂れ流しにし、後続処理で10進ｴﾗｰやら
文字コードエラーがドカドカと大量生産していますた。
だから藻前らはSQL(CPYF)でシステムにちゃんとエラーチェックしてもらえと小一時間(ry
>>68
ちなみにそのデータの作成が早くてもOracleへのロード時間で
マイナスなので、全体から見るとパフォーマンス最悪で爆死です。
普通にSQLで処理汁と思いました。
検討した方がいいよ。そんでもって書き換えちゃえ。
COBOLできる人が必要になるって、
COBOLやってたやつがいってた。。。
どうなんだ？
今までCOBOLで書かれていたプログラムを
COBOL以外の言語にリプレースする為に
COBOLを知ってる奴がいた方がいい。
そのプロジェクトに要件定義書とか仕様書というのが
存在しないならなおさら。
まー、COBOLしかできん奴とCOBOLもできる奴では
意味合いが違ってくるとｵﾓ。
CSPの方が生産性がいいんですか？
Javaに書き換えた方がいいとの意見もありますが
コストを考えるとVisualCSP（当方あまり詳しくなくあっているか微妙。。。）
にした方がいいとの意見もあり、半信半疑です。。。
そもそも、CSPってメジャーな言語なの？
自分が知らないだけで業界の人からみるとデファクトスタンダードなのかな。。。
この話どーよ
勝手に古いCOPY句使ってmakeするPGも駄目だが、余分な領域が別の変数の領域を上書きしちゃうのが実行時まで分からないとはorz
昔某交換機の時は、コンパイルするとアドレスは固定割付で、メモリリークは漏れなくコンパイル時にチェックできたのに。
abnormal endのことだって、去年知った。
♪アベンド、アベンド 嬉しいなぁ〜 (^o^)
「えんぴつ」の方が優れてるぞ！
いや「シャーペン」の方がイイに決まってるだろ！
って言ってるに過ぎないと思われ
なぜ、それを人間がやらなければならない？
こんなスレを素で開くようでは、おしまいである。
つInterstage。俺はやりたくないけど。
オンラインなんかだと、
ユーザーインターフェースとその周辺：Java
中の処理：COBOL、アセンブラ
バッチでも、
ファイルをコード変換してサーバ側へ：JCLで汎用ツール呼び出し→サーバへ送る
どっちもできればいいんだろうけど、実際そんなに起用な人はそうそういない
「こういうことをJavaでやってほしいんだけど、それって大変？」とか、
「コボルってどこまでやってくれるの？」とか、
お互いに協力し合ってやってると思うけど。
大規模システムはCOBOL→UNIX-COBOLへツールで機械的に変換して、
サーバ上で稼動させるし
アナログ人間の俺はコボラーだけど、別にオープン系の人と対立なんか
しないけど
Java使うくらいならVB6でいんじゃね？
つか、普通にJava使えるってレベルの奴ならCOBOLに
メリットは感じないよ。
ただ、思った以上にJava使える(=ライブラリやフレームワークの知識がある)奴は
少ないってのが現状。
俺はむしろ、自称JavaプログラマにCOBOLを使わせたいな。
どうせ業務アプリの殆どが、OOなんて必要ないし。
OO以前に、DBスキーマ見て仰天することも多いが。
JAXBのような知ってる奴が使えば大きく生産性をあげるツール＆APIもあっても、
学ぶのを止めたSEには一生気づかれないままとか寂しい運命の機能も多い。
正直、SEとコーダーを必要以上に分離しようとする日本の風習にJavaはあわない。
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
GCCについて part10 (167)
Objective-C [ObjC part:7]; (133)
J#って何のためにあるの？ (149)
【Lisp】プログラミング言語 Clojure #2【JVM】 (397)
【3DS】プチコンを語るスレ【DSi】 (512)
Lisp Scheme Part34 (336)
--log9.info------------------
★●★ドケチなら千葉に住むよな？★●★ (594)
ドケチのお料理Σ（ﾟ□ﾟlll） 5 (118)
ドケチの虫歯治療・延命・歯磨き・予防★１抜歯目 (371)
【安い】ドケチが100均で買うもの【高い】 3 (548)
電気代をケチろう part 19 (402)
寒いの我慢するなんてバカじゃない？ (357)
逆にこれだけはケチった方がいいもの (217)
コストパフォーマンスの高い食べ物 2 (227)
【トースト】 本日の朝食２ 【ねこまんま】 (602)
ドケチの衣料品【注：ユニクロは高級品】2着目 (446)
ケチな人と付き合いしてて我慢してる人5 (173)
ドケチならドコモ ハーティなら６月から６０%引き (163)
ケチな奴ってさ〜、性格悪いよね (589)
1000万円貯金があると気が楽か？☆6 (891)
500円で出来る最高の贅沢を考えるスレ 2枚目 (713)
ドケチの暖房節約法･冷房節約法 19 (426)
--log55.com------------------
サンワサプライ SANWA SUPPLY 020
【初肉】HP p6745jp/p7-1020jp 5肉目【秋肉】
マイクロスイッチ仕様のマウス 総合スレ
お勧めのスイッチングハブ 29port目【Hub】
メルコ BLR3-TX4のスレ Part4
Bluetooth ヘッドセット #4
ウェブカメラ質問総合スレッドＰＡＲＴ１
NEC無線LANルータ Atermシリーズ Part108