COBOL vs Java 2戦目
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2006/09/13(水) 22:37:48ttp://pc8.2ch.net/test/read.cgi/tech/1068819212/
0655デフォルトの名無しさん
2009/07/22(水) 16:43:010656デフォルトの名無しさん
2009/07/22(水) 23:17:23>OOP以降になると、コーディングは「設計」工程の延長。
>だけど今でも製造工程なんだよね
なんかわかるな、システム設計の成果物である設計書が、
OOPLを知らない人向けになってるのもそうだし
ぶっちゃけUMLを活用しているところなんて皆無じゃない？
構造を説明するというのにプログラミング言語というのが嫌な人が多いんだろうね。
0657デフォルトの名無しさん
2009/07/23(木) 02:24:01クラス図、シーケンス図は書かんなあ。
いわゆるJaaでWebだとフレームワーク使うことが前提で、
フレームワークのお作法に則ればある程度形（これアクション、これDAOみたく）になるから、
いわゆるモジュールの一覧みたいなのは作っても、図には起こさんな。
コメントうって、あとjavadocみたいな。
0658デフォルトの名無しさん
2009/07/23(木) 23:47:02http://www.infoq.com/jp/news/2009/07/cobol-to-java
記事貼りで悪いが、こういう記事を見ると、恐怖を感じるというか、
自動コンバートなんてのが流行った暁には、
レガシーコードがCOBOLからJavaに映っただけじゃんとおもったりする。
0659デフォルトの名無しさん
2009/07/24(金) 00:55:19そんなにＣＯＢＯＬがキライなのか
0660デフォルトの名無しさん
2009/07/24(金) 01:36:42人が居ないってことでしょ。
実質的には似たようなことをやっていたとしても、Javaならその先がある気がする。
それに対して、COBOLじゃ一生同じことをやっていくのかと思わせる。
0661デフォルトの名無しさん
2009/07/24(金) 03:39:09javaの方が若くて丈夫で単価の安い土方多いんだし…
0662デフォルトの名無しさん
2009/07/24(金) 20:59:0520年前のコボラーですが、このスレについて行けますか？ｗ
0663デフォルトの名無しさん
2009/07/24(金) 22:50:010664デフォルトの名無しさん
2009/07/26(日) 10:40:02http://q.hatena.ne.jp/1248422316
0665デフォルトの名無しさん
2009/07/29(水) 16:37:46ＪＣＬはjavaのデブロイデスクリプタに似ている
0666デフォルトの名無しさん
2009/07/29(水) 21:02:46触ってたりしてるけど、COBOLの方がまだいいな。スレッド無いし…
中間ファイルあるだけ不具合の発見し易かったりする。
Swing使うとイベントディスパッチスレッドルール違反で落ちまくって大変な目に遭う。
java Applet <=> java Servlet <=> C Service <=> JCL <=> COBOL <=> DB
という華麗なシステムのおかげで、言語としては、どちらも糞としか見えない。 orz
Java=マルチスレッド系とCOBOL=基幹系かな？
データベースを上手く作れば良いのだろうけど、
昔のオフコンスペックで安定稼動させる事ができるならCOBOLが上かと…
>>642
Java(CORBA)で作成された制御システムを保守したけど、10日で1回、
原因不明の動作不全で落ちているのがあったよ。怖いよね。
こいつもマルチスレッドでオブジェクト崩壊起こしてた。
スレッドダンプが拾えなくてしんどかった…
0667デフォルトの名無しさん
2009/07/29(水) 22:15:100669デフォルトの名無しさん
2009/07/30(木) 07:28:07エンジニアとして落ち目街道まっしぐらってトコが可哀想なノリがあるな・・・。
全てが喪前が原因で不安定と言うワケではないが、
基幹系でも毎日STEP当てて不安定をごまかしている運用もあるから、
JCL+COBOLが安定ってのは幻想だ。
安定に関しては言語云々よりも人の質が大きく左右する。
0670デフォルトの名無しさん
2009/07/30(木) 12:02:32糞技術者どもの10数年前の不快な技術、不快なコード、
ずっとバグ隠蔽していた前任が逃げて仕事が、こっちに来たんだよ。
第一、CVS、SVN、VSS、全て存在しないとかいってほざいて辞めたし…
でもいいや、今は生きている。
とりあえず予算通れば…奴らも大人しくなる。
>>669
仕事無い時は別のC#案件とか入るし、顧客対応とかもう疲れた。
>>668
とりあえずスレッドパターンだけ話せるレベルまで、
ちゃんと新人に教えてくれているなら許す。
0671デフォルトの名無しさん
2009/07/30(木) 19:58:590672デフォルトの名無しさん
2009/07/30(木) 20:26:28COBOL2002とかいう規格だと再帰はサポートされているんだな
あと、戻り値と引数が使える関数！もサポートされてるな
後気になるのは、COBOLにはグローバル変数しかないという話を聞くが
ローカル変数/スタックは使えるのか
また、今広く使われているCOBOLの規格はどれなのか
引き続き解答を募集
0673デフォルトの名無しさん
2009/07/30(木) 20:32:360674デフォルトの名無しさん
2009/07/30(木) 21:25:540675デフォルトの名無しさん
2009/07/30(木) 23:52:18WinMergeのプラグインの功績大きいよな…
COBOLコードのDIFFが取れるようになった御陰で、
改修し易くなったぉ。
0676デフォルトの名無しさん
2009/07/31(金) 00:28:00SCC使ってるのに、あの慣習を持ち込む奴は、さっさと死ぬべきだよね。
0677デフォルトの名無しさん
2009/07/31(金) 01:02:23SVN、CVS、VSS(総称SCM)の利点が使えるから>>676の言い分は共感できる。
でもさ、本番機（SCMが無い環境）にしか開発環境を用意していない所もある。
セキュリティ強化によってソース改修をSCMに頼れない場所だってあるんだ。
あの慣習も場合によっては必要かと…最低悪だよう。
0678デフォルトの名無しさん
2009/07/31(金) 01:18:38こちらこそ、ごめんなさい。SCMのtypoです。
でも、この意味が良くわからない。
>でもさ、本番機（SCMが無い環境）にしか開発環境を用意していない所もある。
>セキュリティ強化によってソース改修をSCMに頼れない場所だってあるんだ。
本番機にしかソースがないってこと？
それじゃぁ、本番機が飛んだりしたら元に戻せないのでは？
それに、開発環境とSCMのサーバは別に同じである必要は無いし。
0679デフォルトの名無しさん
2009/07/31(金) 01:19:13再帰なんて言語仕様の問題じゃなくて処理系やOSの問題だろ
何十年も前のACOSのアセンブラだって再帰は使えてた
0680デフォルトの名無しさん
2009/07/31(金) 01:30:14おぉ、サンクス。そんなツールあるんだ、初めて知ったよ。
検索で一撃で出なかったので、詳細教えてくれない？
>本番機にしかソースがないってこと？
色々事情があってね。セキュリティとか気にする上からのお達しなんだ。
開発環境も本番機に接続…笑えるでしょ？
0681デフォルトの名無しさん
2009/07/31(金) 06:06:350682デフォルトの名無しさん
2009/07/31(金) 06:55:490683デフォルトの名無しさん
2009/07/31(金) 11:53:26SCMは、ソースコード管理ツール一般ですね。特定のツールではなく。
SCMと打とうとして、まちがってSCCと打ってしまったのです。
しかし、恐ろしい環境ですね。本番機からダム端がぶら下がっている感じ？
ところで、もともとの私のレスは「SCM使ってるのに…」という文脈なんで、
あなたの環境では、コメント入れるのもしょうがない気はします。
なんか解決策ないのかなとは思うけど、そちらの方面には詳しくないので。
酷いところだと、JSPにHTMLコメントで履歴残してたりして、クライアントに駄々漏れ…
それこそセキュリティ上問題があるだろと思うんだけど。
0684デフォルトの名無しさん
2009/07/31(金) 14:46:28>>JSPにHTMLコメントで履歴残してたりして
そうか！JSP内にJavaコメントとして残せば良いんだ！(ピコーン)
0685デフォルトの名無しさん
2009/07/31(金) 16:44:450686デフォルトの名無しさん
2009/07/31(金) 18:28:48Java も COBOLもSCMが無ければただの（略）で、OKですか？
リファクタリングも糞もないよね。
0687デフォルトの名無しさん
2009/07/31(金) 18:52:51>SCM使ってるのに…
そうだね。レス違いだったよ。
SCM使えるのに管理コードのコメント加えるのは氏んで良いと思う。
どんな言語だろうとも。
0688デフォルトの名無しさん
2009/08/01(土) 19:16:08リポジトリを誰が管理するのかという観点で考えられていないことが
多いと思う。
開発～単体テストくらいの期間だけSCM使ったり、逆にリリース管理用に
テスト完了したものしか登録させてもらえなかったり…
0689デフォルトの名無しさん
2009/08/01(土) 23:25:02ＡＰとデータのバージョン管理なのだが難しいのはデータのほう。
ＡＰのほうは目視でスタンプ見てでも何とかなるだろう。
あんぽんたらふうが。
0690デフォルトの名無しさん
2009/08/02(日) 21:09:51CVS（Concurrent Versions System)
SVN(Subversion)
VSS(Microsoft Visual SourceSafe)
Git
その他（MSのなんとかサーバとか）
0691デフォルトの名無しさん
2009/08/02(日) 22:04:03COBOL言語の場合は知らないけど、どうしてるんだろうね
0692デフォルトの名無しさん
2009/08/02(日) 22:16:240693デフォルトの名無しさん
2009/08/02(日) 22:37:030694デフォルトの名無しさん
2009/08/03(月) 00:15:22分散型なら沢山あるけど、日本語ファイル名やGUIに難があったりして、環境を選ぶよ。
0695デフォルトの名無しさん
2009/08/03(月) 06:38:29とりあえずオフコンじゃ無理だけど、COBOLはSVNだな...
WINDOSで使えるCOBOLの場合は亀に依存してる。
あのツールはDIFFツールを自前や別ツール指定できるし、Winmergeプラグイン大活躍。
最新バージョンは知らないケド、VSS6.0dじゃ無理。
0696デフォルトの名無しさん
2009/08/03(月) 07:53:43ソースをオープン系OS(Win or Unix)のSVNに入れといて、
コード編集はテキストエディタでゴリゴリ書いて、
コンパイルはSVNからEXPORTしたものをFTPかなんかで転送して、
汎用機に反映してコンパイルって感じなの？
0697デフォルトの名無しさん
2009/08/03(月) 08:46:020698デフォルトの名無しさん
2009/08/03(月) 09:56:59もうやめたい。
0699デフォルトの名無しさん
2009/08/03(月) 11:53:01バージョン管理は悩ましいな。台帳管理が一番いいと思うがなあ。
完全自動化は無理だし、第一、人間の思考回路とか、そういうものは
変わってないからな。完全に落ち着いた状態ならシステムで
やり易いだろうが、管理の境界点では不特定要素がかなり出てくる。
そんなとき、システムがこうだからと言っても、運用側からしたら
そんなこと知ったことじゃない。運用管理の難しさの一つのキモですな。
0700デフォルトの名無しさん
2009/08/03(月) 13:14:22バージョン番号を決めるのも、どのバージョンをリリースするかを決めるのも人間がやるしかない。
SCMは、構成管理に必要な機能の一部を提供してくれているに過ぎない。
SCMに変な幻想を抱いていたり、逆に使えないと思っているのは、
単純に構成管理そのものを理解していないからじゃないか？
0701デフォルトの名無しさん
2009/08/03(月) 13:42:26考えておいた方が色々気が楽だと思うけどなぁ。
ウチの場合は、開発中は自由にSubversion/CVSにコミットしていって、
(もちろんコンパイル／デプロイできるのが当然条件だけど)、
本番リリース前のwar+ソース一式だけtarやzipで固めて、
共有ディレクトリに置いて管理してる。
698は要約するとめんどくさいから要らない、って言ってるだけに見えるけど、
Javaとかのオープン系で上記の管理してるんかね？
0702デフォルトの名無しさん
2009/08/03(月) 14:47:25まーでも開発、試験はツール使って管理しててもだ、
本番リリースだけは台帳つくって人間が管理なんてのはよくある話
、なんだかんだでつぶしが利くし
ごくたまにデグレがあってあたふたするけどｗ
最近は台帳というより、リリースノートをウィキで書いたり、
あとボーランドとかベンダーの出してる商用の要件管理ツール（と連動する構成管理、リリース管理）を使ったりなんかもするけど
何が正しい運用なのかは、いまだに答えが出てこないなあ。
0703デフォルトの名無しさん
2009/08/03(月) 16:30:07> Javaとかのオープン系で上記の管理してるんかね？
Java はあまりやらないけど, BTS と SCM はないと生きてけないな
それ以外にも, プロジェクトに合わせた, サポート用のスクリプトは結構作る
0704701
2009/08/03(月) 17:09:42>>699だよ、言いたいのは。
とりあえずソース管理なんてそんなご大層なもんじゃなくって、
テキストファイルのバックアップ程度のもんなんだから、
難しく考えずに導入して試して見ろ、とゆいたかっただけです。
後、仕事しような＞俺
0705デフォルトの名無しさん
2009/08/03(月) 21:21:30バージョン管理のいいところは、差分が取れる、編集者・編集日時が誰かわかる、タグが付けられるだな。
設計書、スクリプト類、テストデータなんかも入れて使ってる。
使い勝手の良いBTSって無いですよね。Excel管理とかになってしまう。
0706デフォルトの名無しさん
2009/08/03(月) 21:36:25見事にツールだけで壷に嵌るケースもあると思う
しかしだね、俺が今まで経験した多くのプロジェクトでもでね、
例えば、30本に新規作成や改変やったとしてだね、本番移行は、そのうちの
25本だけなんてよくある話だよ。それとね、システムの性質によっては、
ある特定日に合わせて順を追って移行することもある。
従って、バージョンの管理も本番系、テスト系、それぞれ別個にある。
石橋を叩いても渡らないくらいの用心してやらんとチョンボが出る。
日本のだね、ソフト開発はね、テスト工程以降がマジで手薄だ。
作ったら終わりのような腐ったよなエセＳＥが多い。
運用はね、実は難しいのだよ、わかってる？
0707デフォルトの名無しさん
2009/08/03(月) 22:40:34>25本だけなんてよくある話だよ。それとね、システムの性質によっては
よくある話でもなくて、そのエセSEの計画がムチャクチャだっただけでは。
運用が実は難しいと言うか、バカなSEがいるようにバカな運用も普通に多いと感じる。
0708デフォルトの名無しさん
2009/08/04(火) 00:34:25ソースの版を管理するのと、どれをリリースするか、って別次元の話じゃん。
依存性のある単位でパッケージングなり、台帳管理なりしておいて、
ソース管理から取り出してリリースすればいいじゃん。
ソース管理を複数持つとか、無駄以外の何者でもないよ。
後、30本の改変やって25本だけリリースしたとして、
残りの5本に依存した機能が必要だったらどうするつもりなんだろうね？
後、石橋を叩いて渡らないって、仕事はするけど成果物出さないの？
それって顧客が怒らない？
0709デフォルトの名無しさん
2009/08/04(火) 00:40:03馬鹿なSEとか、複雑な運用とか、難しいとか
だいたい抽象的すぎるだろ表現が、具体的な書いてもらわんと批評できんわ。
そんなんは居酒屋でやってくれ。
0710デフォルトの名無しさん
2009/08/04(火) 00:55:590711デフォルトの名無しさん
2009/08/04(火) 00:56:25まあ経験を積めば見えてくるさ
機会があればだけどね。
0712デフォルトの名無しさん
2009/08/04(火) 00:59:35バージョン管理以前の問題だ。
発注側が馬鹿だから、SIerの評価が出来ない。
SIerも馬鹿だから、エンジニアの評価が出来ない。
結果、金ばかり掛けて使えないシステムが出来上がると。
0713デフォルトの名無しさん
2009/08/04(火) 03:58:48例えばA,B,C,D,E,Fの６業務のAPに改修が必要となったとする。
それぞれ５本のソースから出来ており、互いに依存はしない。
（業務Aを構成するA1～A5は、他のB～Fの業務で使われることは無い。
B1～B5・・・・・F1～F5 も同様）
これらを同時にリリースできればいいのだが、業務フローの都合上、
Fのみ、来月の月次処理の後でなければいけないとすると、
A～Eの25本だけをまずリリースすることになる。
F1～F5の５本については、リリースする日まで、
甲：現在、稼動しているバージョン
乙：改修を加えたバージョン
の２系統を管理する必要がある。
Fのリリースだけ伸びることが初めから分かっているなら、
改修スケジュールをFだけ遅らせればいいだろう、
という声が聞こえてきそうだが、30本まとめてやらざるを得ないこともあるね。
例えばちょうど年度末の時期で、来年度は改修予算ガタ落ちだとすると、
今年度中に30本片付けておきたい、とか。
ここで25本リリース後、業務Fに未知の不具合が発覚し、
調査の結果、F4に潜在バグが見つかったとすると、
（１）それが致命的バグで、緊急を要するのであれば、
F4甲に対して修正を加え、緊急リリース
（２）それが致命的でなく、だましだまし使えるのであれば、
業務方には来月月次まで待ってもらう約束を取り付け、
F4乙に対して修正を加え、リリースはあとで
できれば（２）にもっていきたいね。
ここで、「じつはF3の改修は業務Bにも影響するんです」
となると・・・・・もう嫌っ！
0714デフォルトの名無しさん
2009/08/04(火) 06:16:48A-E の改修が完了した時点で, リリースブランチ切ればいいって話でもないのかな?
F をリリースする前の突発的な変更は、リリースブランチでやっておいて F を
リリースするときに必要であれば F にマージ。
F の改修はリリースブランチの変更を意識することなくヘッドブランチで作業
F の回収中に必要性が判明した A-E への変更もリリースブランチを意識する必要なし
程度のことはできるけど………
0715デフォルトの名無しさん
2009/08/04(火) 06:38:54まさにシステムは生き物だというのを、明確に実感できるセクションだね。
プログラムのこと、データのこと、顧客運用のこと、総合的な視野を
持っていないといけないね。運用管理に関してはJavaもCOBOLもない訳でね、
安全サイドに立脚して考えていかないといけないね。
その中で、ツールを使えるところは使うし、手作業のとこは手作業で、
可能であれば技術者の思考の余地が少なくなる方向で出来上がれば
いいのではないかな。
0716デフォルトの名無しさん
2009/08/04(火) 10:59:25完全に独立しているなら、最初から別々に管理しておけば良いとも思うが、
そうはできない理由があるとする。
改修開始前のソースをベースラインとし、トランクではA～Eの改修を行う。
また、ベースラインからブランチを作成し、そちらでFの改修を行う。
A～Eの改修後、リリースバージョンにタグを打つ。その後、ブランチでのFの改修をマージ。
この状態でF4に致命的バグ、緊急リリースが必要なら、先ほど打ったタグからブランチを作成し、
これに対し改修を実施する。これなら、Fに対する来期向けの改修がリリースに含まれない。
もちろん、ブランチに対しても、リリースバージョンにはタグを打っておく。
緊急改修の内容は、緊急リリース終了後にトランクにマージ。
Fの正式リリースはトランクからビルドする。当然、そのバージョンにもタグを打っておく。
これは、次の改修が発生した場合のベースラインとなる。
最終的に、次のタグが残ることとなる。
1. ベースライン（改修前）
2. A～Eリリース
3. F緊急改修リリース（A～Eの改修も含まれる）
4. F正式リリース（A～Eの改修、F緊急改修も含まれる）
SIだけやってると、構成管理が適当でもなんとかなったりするけど、現状で困っているなら、
一度じっくりと勉強してみるといいと思う。
Subversionのドキュメントで、「こんな場合はこうする」ってのがあったと思うんだが、
今見てみたらつながらなかった。
0717デフォルトの名無しさん
2009/08/04(火) 16:56:430718デフォルトの名無しさん
2009/08/04(火) 18:21:370719デフォルトの名無しさん
2009/08/04(火) 18:37:400720デフォルトの名無しさん
2009/08/04(火) 23:39:350721デフォルトの名無しさん
2009/08/05(水) 00:48:380722デフォルトの名無しさん
2009/08/05(水) 01:02:59意味不明な言語があったな
0723デフォルトの名無しさん
2009/08/05(水) 01:10:19現代のインテルセンスというより、エラー＋タッチ＆GOみたいな感じ？（ニュアンス伝わらなかったらすまない）
オブジェクト指向ではないけど、同名フィールド名で、同じ型なら多重定義できるから
使い方によってはすさまじく効率が良いプログラミングが可能。
0724デフォルトの名無しさん
2009/08/05(水) 01:18:00用語辞書に名前が載るような鉄道系巨大システム開発やったことあるが
もはや触れないと言っていた。当時はディスクが高価でね1バイトで
8個のフラグ操作とかやってるからな。汎用機は高額だからメーカーも
受注生産でも対応するだろうし、基幹システムのJAVA化には
踏み切らない、もしくは、それは緩やかなものになると思う。
IBM、HITAC、FACOM、ACOS、MELCOMこんなもんだろう。
20XX年までに汎用機から完全撤退とか、そういう話になれば
そりゃあ面白いだろうけどなあ。これからのネックは人材だろうよ。
COBOL技術者は高齢だからなw、40代、50代、60代だろう。
慌てて若者のCOBOL教育もやってるみたいだけどね。間に合わないよな。
やりたがらないだろうし。これからのパラダイムが動いてさ、
大きなシステム改修とかが発生したら、どうするんだろうな。
若き技術者が苦労しながらやっていくんだろうと思う。
0725デフォルトの名無しさん
2009/08/05(水) 01:24:54COBOLがそうだから自分が偉いとでもいいたい勘違い野郎か？
0726デフォルトの名無しさん
2009/08/05(水) 06:34:07正確には昔からある大企業だろうけど。
GoogleやらYahooがCOBOL使っているとはとても思えんが。
0727デフォルトの名無しさん
2009/08/05(水) 06:57:340728デフォルトの名無しさん
2009/08/05(水) 07:01:11WebSphereユーザ？欲しいなと思っていたけど、使い勝手悪くない？
やっぱSCMも使えないし、インテリセンスはJavaに劣るよ。最新バージョンはもっと良いの？
未だにエミュレータでTelenetアクセスでCUIで打ち込んでいるよ…
>>722
最新はRPG/ILE、Sysstem i（iSeries）って名を変えてさ、現役どころか進化してるよ。
Shiftコードは汎用機の問題点かと、これさえなければなー。
標識フラグは嫌だ。配列も変数のサイズ制限あるし…
あの変なクラスやメンバ、オブジェクトと言うファイルシステムは、Javaエンジニアには理解できん。IFSの方がまだいい。
普通にフォルダ、ファイル、属性と表現してくれ欲しい。
開発、保守、運用、ホトンド顧客説明とバグ修正テスト、要件管理ばっか…
要件管理を仕様書に取り入れて仕変したりする。
Java→C/C++、RPGⅢ→PHP4→ASP、C#.Net、COBOL85
色々やっているが、一番Javaが開発しやすい。Log4J、JUnitも使い易いから。
マルチスレッドはしんどいけど…
>>669
>エンジニアとして落ち目街道まっしぐらってトコが可哀想なノリがあるな・・・。
折れの中での一番の技術と思っているのはソーシャルハッキング。
嘘や勘違いの中から真実を抽出する技術は重要と思う…orz
おすすめ２ちゃんねるのスレで「会社で使えない奴、それはワタシ／アイツ」で
「被害妄想と言えばいいよ」というレス見て、このカードは使えるなと思った。
ちなみにそんな折れは20代後半…orz
もう寝る。
0729デフォルトの名無しさん
2009/08/05(水) 07:08:14ゆとりは関係ない。出来る奴はできるし、出来ない奴はできない。
顧客対応が一番むずいよ。言語そのものが話してる途中で変わるから。
0730デフォルトの名無しさん
2009/08/05(水) 20:28:170731デフォルトの名無しさん
2009/08/05(水) 20:51:49COBOLよりは速いから心配すんな
0732デフォルトの名無しさん
2009/08/05(水) 21:11:02このやり取り何回目よ
0733デフォルトの名無しさん
2009/08/05(水) 22:20:220734デフォルトの名無しさん
2009/08/05(水) 23:51:16あとCOBOLでcgi作ったことないから解らんが、htmlを返す様な処理なら
色々な意味でJavaの方が速いもしくは楽だと思うけど。
0735デフォルトの名無しさん
2009/08/05(水) 23:57:28COBOLとRPGを速度を比較するなら
AS400で、おんなじ内容の処理で計測必要があるとおもうが。
それとFORTRANとの比較自体意味なくないか？
0736デフォルトの名無しさん
2009/08/06(木) 00:11:45最も銀行とかでかい企業で基幹部分いじってるって言うなら別だけど
0737デフォルトの名無しさん
2009/08/06(木) 01:04:50いまだ現役とは恐れ入る。確かに名機だったがね。
0738デフォルトの名無しさん
2009/08/06(木) 12:29:22コンパイル出来ないって言うJVMの仕様があるらしいね。
COBOLのプログラムを機械的に移行するツールとか使った場合なんかに、
この制限を突破しちゃって、これだからJavaは～とか叩かれないかしら。
0739デフォルトの名無しさん
2009/08/06(木) 12:59:3064kも書くようなメソッドを作る香具師はバカ。
オブジェクト指向分かってないし、
そんな複雑なものを作ったら、そもそもテストができん。
COBOLのプログラム間共有領域は2kとかの制限の方が、よほどおかしな話
0740デフォルトの名無しさん
2009/08/06(木) 13:19:02単純に割り算すると8191行ぐらいのステップになるのかな？
実際には80桁使い切るステートメントはありえないので、もうちょっと行は増えるのか。
0741デフォルトの名無しさん
2009/08/06(木) 13:37:22> 1つのメソッドが64k以上になると、コンパイル出来ないって言うJVMの仕様
バイトコードのサイズじゃなかったっけ?
0742デフォルトの名無しさん
2009/08/06(木) 23:19:07ある意味、どんなコードなのか見てみたいｗ
0743デフォルトの名無しさん
2009/08/06(木) 23:39:04それでもいくつかのブロックに分かれていたからなあ。
俺も元がどんなプログラムなのか見てみたいわな。
0744デフォルトの名無しさん
2009/08/07(金) 00:59:15DBはADABASで。64ｋというのロードサイズだったら結構あるんでは？
0745デフォルトの名無しさん
2009/08/07(金) 01:38:04吐くことも多いからその辺じゃない？
プログラムは小さくてもコピー句がでかくて、
それを読み書きするJavaのコードが際限なく生成されてたり。
0746デフォルトの名無しさん
2009/08/07(金) 02:22:54誰も困らない仕様を不具合と呼ぶ前に、巨大メソッドを吊し上げろよｗ
0747デフォルトの名無しさん
2009/08/07(金) 07:11:1564kのバグはCOBOL→Java変換で起こったと…
0748デフォルトの名無しさん
2009/08/07(金) 14:31:59使われていることがあって、このソースは見れたものじゃない。
そこからさらにJavaのソースを自動生成したとすると、
混沌ぶりが二倍二倍！
0749デフォルトの名無しさん
2009/08/07(金) 14:52:50元のJSPのサイズだけで40KB近くあって、中にスクリプトレットが大量に埋め込まれているんだぜ。
ところで誰かJRubyとかJythonみたいな感じでJCOBOLとか作らないかな？
出たらスレタイの不毛な議論も無くなり、
COBOLer≒JCOBOL技術者≒Java技術者とか言って売り込めるんだけど。
0750デフォルトの名無しさん
2009/08/07(金) 21:04:15よってCOBOLのレガシーコードが、COBOLなんちゃってフレームワークなJavaレガシーコードになるのがオチ
COBOLなんちゃってフレームワークなJavaレガシーコードのソースなんかメンテしたくないわな。
ただ、パフォーマンスとか信頼性の点でまともに動作するなら、最新のIDE、SCM等を活用できるので評価したい。
まともな頭を持ってる人なら、変換後に全プログラムの動作確認が必要と判断するので、
テストする工数と新しく作り直した場合の工数のどっちが多いかという検討をするだろう。
自動変換が難しい部分は、Javaで作り直しという選択でも良いのかもしれんが。。
>>749
COBOLの場合は、コピー句があるからそんな代物は作れないと思う。
>>748
それ最悪だね。そういうCASEツールで作られたもので、なおかつ変換したいというのは悪夢だな。
0751デフォルトの名無しさん
2009/08/07(金) 22:44:15不毛ではないよ。COBOLを窓から投げ捨てれば万事解決。
0752デフォルトの名無しさん
2009/08/07(金) 23:36:14バージョン勝手に変えてくれるからJavaは言う事聞かなくて困るよ。
あとJavaコントロールパネル、反映されないのは何故だろう。
Windowsの場合レジストリに書き込んでるのだろうか…
JREの仕組みを教えてエロい人。
0753デフォルトの名無しさん
2009/08/08(土) 01:53:28お前は馬鹿まで読んだ。
0754デフォルトの名無しさん
2009/08/08(土) 20:04:58■ このスレッドは過去ログ倉庫に格納されています