【コボル】COBOL不要論【いらない】

COBOLなんてもう必要ないよね。

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

緊急事態発生！緊急事態発生！

e-Japanは、直ちにメインフレームから脱出せよ。
繰り返す。
e-Japanは、直ちにメインフレームから脱出せよ。

ttp://www.atmarkit.co.jp/fcoding/articles/cobol/03/cobol03a.html
ttp://d.hatena.ne.jp/JavaBlack/20090720/p3

ttp://rikunabi-next.yahoo.co.jp/tech/docs/ct_s03600.jsp?p=000599

ttp://d.hatena.ne.jp/nacky-21/20090608/1244475502

十数年前から「COBOLやる奴は落ちCOBOL」と言われてたのに
未だに現役なんだから、>>1は諦めて習得しろ。
もう必要ないのはN88BASIC。異論は認めない。

こぼらーを隔離するために必要だろ！
何馬鹿なこと言ってんだ

コボルいらねー

いらなきゃ使わなきゃいいだけなのになんでこんなスレ立てるのか？

きっと自己顕示したいんでしょう、思春期の中学生ですから

電子政府は時代遅れのCOBOLを使うな！

コンピュータ業界においても“表沙汰にしたくない裏面”というものが存在し
ttp://www.itmedia.co.jp/enterprise/articles/0801/21/news008.html

別にもうCOBOLでもいいだろ
リプレースと称して死屍累々とゴミを作り出すよりはCOBOL人柱に金を払った方がマシ
それに不要論を唱えるまでもなく今からCOBOL習得に情熱を燃やす若者もいないだろ

(・ω・)ﾉｼ

頼むからCOBOLやめてくれ
COBOLがあると日本のITの進歩が遅れる

COBOLSすら使いこなせない猿にも劣るやつらの集会ですか？

コボルいらねー

不要言語スレって何か実りのある会話が成されたことあるん？

COBOLが無くなる→コボラーがJavaに移行する→Javaの糞コードが増える。

飯の種は増えるが、糞つまらない仕事が増えることでもあるな。悩ましい。

COBOL程度の言語すら理解できないアンポンタンがJAVAとか抜かして笑わせるなｗ

だってCOBOLなんて不要だもん理解する必要がないだけ
理解できないとは一言も言ってないし

>>22
COBOLの命令文を全部書いてみなw

予約語が多い＝糞言語なのに、それを自慢できちゃうのがコボラーのコボラーたる所以

>>23
ACCEPT,ADD,ALLOCATE,ALTER,CALL,CANCEL,CLOSE,COMMIT,COMPUTE,CONTINUE,
DELETE,DISPLAY,DIVIDE,ENTRY,EVALUATE,EXIT,FREE,GOTO,GOBACK,IF,
INITIALIZE,INSPECT,MERGE,MOVE,MULTIPLY,OPEN,PERFORM,READ,RELEASE,
RETURN,REWRITE,ROLLBACK,SEARCH,SET,SORT,START,STOP,STRING,SUBTRACT,
UNLOCK,UNSTRING,USE,WRITE

C言語は予約語が少なく37個しかない
これはC言語に演算子が多く予約語の不足を補うのに
十分なためと言われている

ちなみにC言語の演算子は40個もある
これはAPL、C++の次に多い

C++は予約語が73個と膨れあがってしまったがその殆どが
OOP用拡張用であり、基本はC言語と大差ない
もしくはトライグラフを撤廃するために儲けられた予約語もある

>トライグラフを撤廃
kwsk

>>25
Procedure Divisionだけかよ

ある言語を糞だという奴は、
プログラマーとして糞だ。
本物のプログラマーってのは、
どんな言語にでも長所を見つけて、
その言語に真剣に取り組めるものだ。

糞であることと、長所があることは論理的に矛盾しない。

こんな簡単な論理も分からないと言う奴は、
プログラマーとして糞だ。

最近、なんか宗教戦争スレばっかじゃね？

>>1
けど、知名度では...まだまだ...だったり。
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

>>31
的外れ

ある言語にある欠点があるからといって、
その言語を毛嫌いする奴は、プログラマーとして糞だ。

本物のプログラマーは、どんな言語でも、短所よりも長所の方を見て、
その言語でのプログラミングを楽しめるものだ。

>>32のアンカーは>>30の間違いだった
申し訳ない

COBOLの楽しさって何よ。

データオリエンテドなところ。
適当なカプセル化が行なわれてさえいれば、今でも充分通用するパラダイムだと思うのだけど。

不要言語スレ不要論

【クソスレ】特定言語不要論スレ不要論【立てるな】

そこでPL/Iですよ！

COBOLのおばちゃま

PL/1 って、かつては、機能が多すぎて、こんなの扱えないよって言われてた言語だけど、
今じゃ、 C++ だってあるし、それほどでも無くなってるんじゃないかな。

>>39
アメージング グレイス
グレイス・ホッパー

C++も既に贅肉タプタプの超肥満言語じゃねーか

C++の場合は冗長にも書ける、ソリッドにも書ける。
ボコルの場合は、（ｒｙ

コボルいらねー

COBOLの枯れた技術で十分な業務は腐るほどあるよ、PGレベルの常識で世界を語るとは笑止千万だな
使えもしないJAVA使った現場がどれほど火を吹いて死屍累々になってるか考えることも出来ないような阿呆が
PM,PLやってる現場はひさんだね、言語の新旧でしか判断できないって夏休み中の学生かよ、笑わせるな。

COBOL５０００STEPをJAVAで書き換える例を出してどれほど優れてるか証明してみろ、出来なければ
口から出まかせ決定だよ。

まあまあ
何かの決戦場というわけでもあるまいに
そんなに血圧あげてちゃ飯が不味かろう

そんでもって微妙にスレ間違えてるんでないのｗ

PGレベルの下らない話ばかりしてるからIT関連舐められて単価落とされてるんだろ、
馬鹿立入禁止にしろ。

プロコボラー猿

コボルのソースコードを読みやすくするツールってありませんか？

trで小文字にする。

コボルの変数を整理してくれるようなツールってありますか？

「COBOL 年金問題」でググるとCOBOLを擁護するページがよく出てくる

>>52
ないようだね。自分で作れ

http://www.nec.co.jp/cced/ocf21/cblcli/
COBOL Clinic
COBOLソースを解析して、データ分析・プロセス分析・性能解析・プログラム検索・
疑似実行・ソース整形・保守ドキュメント生成などを実現する開発/保守支援ツール。

ソースコード静的解析ソフト｢FORTIFY SCA｣
ソフトウェアのソースコードを多角的に分析し、そこに潜む脆弱性を正確かつ効率的に発見、修正することができるソフトウェアです。
http://www.hitachijoho.com/solution/shield/fortify-sca/

>>53
年金のシステムがどうのってのは、別に COBOL のせいじゃないからね

田原総一郎が、COBOLなんて古いの使ってるからだめだ、みたいなことを
言って、不評をかってたな。(ネットのごく一部でだけど)

COBOL関連ツールって高いね。１ユーザ50万円もする

COBOLはもうかりまっか？

おまえらCOBOLを馬鹿にしちゃいかんよ。
俺は, wikipediaの「COBOLの言語仕様」のところに書いてある
2次方程式の解の求め方をみて、何が書いてあるか理解するのに
しばらくかかった。
あんなものを理解できる人たちは、きっと頭のいい人たちなんだよ。

>>61
いま見てきた、ありゃキッツいな

初心者が覚えやすいように英語の構文に近づけたと言っているが、
こんなもん、プログラミングに慣れた人にとっては冗長で邪魔なだけ。
こんな化石がいまだに根強く使われてるのが不思議でならない。

>>63
まあ、たいした差ではないよ。

誰も好きで根強く使っているわけではないだろう。

ただ仕事と割り切れば、あんな生産性でこれだけ金が貰える言語は他にない。

いま安いよ。叩き売り状態。

いくらだよ

COBOLでもやってみるか、とCOBOLを始めてみると、
COBOLのデータファイルを編集するソフトがないことに気づいた。

CSVファイルからデータファイルに変換するソフトはあるが。

>>68
意味がわからないんだが…
エディタで編集すればいいじゃん。

ｐａｃｋ形式の領域はどうするんだ？

>>69
「PIC S9(4) comp」のデータ領域は 、エディタでどうやって編集するのか教えてよ。

F痛製でLINDAってのがあったな。
買うと５０万くらいするんだっけｗ

http://software.fujitsu.com/jp/simplia/introduction/tf-linda_pc.html

地元の高校ではプログラミングの授業で
いまだにcobolやってる

Visual Basic の課題で困っております。
誰かお答えください。本当に助けてください。

１．Visual Basicの関数で数値を文字に直すCStr()とStr()の違いについて

２．戻り値の違いが確認できる方法を考え、戻り値の違いについて実際に確認し、
　　その確認方法と違いを具体的に述べよ。
注意：実際にやったことと、確認した違いを簡潔かつ具体的に書くこと。

３．下記の計算結果などから、Visual Basicで計算できる数値の桁数について考察をまとめ、
　　何故そのような制限があるかについて理由を答えよ
　　１）　48 x 100 - 81
　　２）　12 ÷ 9.3 x 247
　　３）　0.2 - 12 ÷ 69
　　４）　-12 ÷ 100 + 100

kkkkkkkkkkkkkkkkkkkkkkkkkkkkk
kkkkkkkkkコボルとっ！kkk@kkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkk

>>61
冗長すぎるｗ

>>74
高校でプログラミング教えてるんだ。
COBOLは意味無いよな。時代のニーズに合ってない。
教育言語として適切な言語ってなんだろうか。
概念的なものを理解できて、実用的な言語であったほうが良いが。。
その前に適切なカリキュラムと教える人員がいないかｗ

現実に存在する計算機の概念ならCで良いんじゃないの？
理論的な計算機械なら、LISPとかMLで。

高校レベルで目標をどのあたりに置くかだね……などと言っていると
やってくれる人がいるならCOBOLでもいいよということにｗ

予約語全部覚えたら英語の勉強にはなるかもね。

教育ならpythonだろ。

それはさておき。
商業高校なら簿記、会計の延長でCOBOLもやるんじゃねえの。
いわゆるコンピュータサイエンスとか、そんなんじゃなくて。

どうせやるんならエクセルとか勘定奉行の方がよくね？

個別製品の使い方を教えるのは教育とは言えないと思う。

しかし、勘定奉行はともかく、文書作成ソフト、表計算ソフト、
電子メールは最低限のスキルとしては良いと思うな。
そうなるとプログラミングじゃなくて、パソコン教室になっちゃうけどｗ

まあ確かにいま学校で教えるならCOBOLなんかより
Excelのマクロ計算式、グラフ、VBAのほうが実用的だわな。

でもCOBOLERが減少してきて、相対的に価値が上がりつつある言語でもある。
主流になることは絶対にないが、なくなりもしない。

>>1が不要なだけ

教育にはPythonは向いてるな。
本気で仕事に応用したい奴限定の教育なら、軽くx86→みっちりC→C++導入編くらい
で、あとは自分で勉強しなさい、かな。

某ハッカーはPython, Java, C/C++, Perl, LISPの５つの言語を学べと説いた。

質問します。

宙に浮いた年金のデータは、COBOLのデータファイルですか？

いえ、だっさいオンライン端末の前でデータが入力できない　or データ入力し難い→ミスで消えたと思われまつ

>>88
esrか。

>>90
根拠は？

COBOLのデータファイルが問題ではないと思うけど、
COBOLのデータファイルなんじゃない？

業務フローとかER図、プログラム一覧とか見てみたいけどな、
すべてを公開しろといは言わないけど、正規化とかされてなさそう。

異常なデータの扱いによるものだと、次のページが示唆している。
http://blogs.wankuma.com/ognac/archive/2007/06/01/79054.aspx

年金データの何が問題なのかが明確に分からないと、こちらも対処のしようがない。

http://alfalfa.livedoor.biz/archives/51055750.html

宙に浮いた年金問題は、社会保険庁の組織的関与によるものだから

http://sankei.jp.msn.com/life/welfare/080918/wlf0809181252001-n1.htm

http://blog.goo.ne.jp/egovblog/e/f9e3eb49e7e08548d554a65a045a588f
http://blog.livedoor.jp/media_heroes/archives/51486102.html
http://bouen.morishima.jp/001116/index.html

http://oshiete1.goo.ne.jp/qa3154548.html

http://kokkai.ndl.go.jp/SENTAKU/sangiin/166/0062/16606140062029c.html

コボルいらねー

同じく
コボルいらねー
コボラーもいらねーｗ

PC用のCOBOLコンパイラを動かすのに仮想マシンが必要とか無いわ
ttp://www.odnir.com/cgi/src/nup40101.jpg

いや、無料でも9x機やUnix系なら要らんぞw

誰かCOBOLのデータを閲覧・編集できるツールを作ってくれ。

お前が作れよモチロンCOBOLでな

>>105
http://www.zob.ne.jp/~c.mos/soft/bz.html

>>106
COBOLだとGUI作れないだろ

PowerCOBOLを知らんのか。

PowerCOBOLとNetCOBOLなら、GUI作れるのか。。。
なるほど。

Fujitsu Data Editor for Windows
http://www.netcobol.com/products/Fujitsu-Data-Editor-for-Windows/overview

Fujitsu's Data Editor is one of the components of the NetCOBOL
(previously called Fujitsu COBOL) Enterprise Edition.
It supports Windows 98/Me/NT/2000/XP.

>>110
COBOL85でもGUI作れるけど、COBOL85自体が古くて使えないよね。

OpenCOBOLでなんとかGUIができないものか。。。

誰かPowerCOBOLのGUI部分をOpenCOBOLに移植してくれないか？

OpenCOBOLならCと連携もできるわけだし
GUIだけ別言語でつくればええがな。

>>109
どういう物なの?

>>115

富士通の、いわゆるWindowsCobol（のGUIライブラリ）だよ。VBみたく、ポトペタで画面を作れるけど
使うには富士通にとってもとっても大きなお金をお布施しなければならない。

マニュアルPDF
ttp://software.fujitsu.com/jp/manual/manualfiles/M080101/B1WD1811/01Z000/B1WD-1811-01Z0%2800%29.pdf

2.2 PowerCOBOL
COBOL の知識を利用して、Windows で動作するアプリケーションをビジュアルに作成するためのシステムです。
Windows で動作するための特有なプログラム構造や、Windows のAPI(Application Programming Interface)の知識がなくても、
PowerCOBOL を利用することにより、GUI(Graphical User Interface)アプリケーションを作成できます。
したがって、新規にアプリケーションを作成する場合はもとより、グローバルサーバやオフコン上のアプリケーションをWindows システ
ムでリメイクする場合に、使い慣れたCOBOL を使用しWindows らしいGUI を持つアプリケーションを作成できます。

モルボル

>>114
何の冗談？　ばかじゃねーの

>>118
openCOBOLはCトランスレータなわけだが、どの辺が馬鹿なのか説明して貰えると助かる。
コボラにC勧めんなって話なら謝る。

118じゃないけど、普通の感覚では「そこまでしてやる意味が解らん」ってトコだろ。
COBOLは汎用機やオフコンで動かしてナンボの言語ではあるし。

GUIからCOBOLの資産使うとか云々ならWebSphereなんちゃらのJavaから
COBOLを呼び出す方が現実的だろうなぁ。

といってもコレは新規にCOBOL開発すると言うツールではなく、
COBOLの資産をかなり無理して再利用ってツールだけど。

だってその上でPowerCOBOLのGUIをopenCOBOLに移植してくれって書いてあるじゃん。
そんなもんCでラップするより大変だぞｗ

ｗ

IDENTIFICATION DIVISION.

【コンピュータ】まだまだ現役：プログラミング言語のCOBOLが誕生50周年 [09/09/19]
ttp://anchorage.2ch.net/test/read.cgi/bizplus/1253376523/

COBOLは不滅だな

JEF漢字コードを叩き潰すスレは、ここですか？

JHT(ホスト連携ツール)SIMPLE版
JEF←→シフトJISコード変換ツール
http://www.vector.co.jp/soft/winnt/util/se088290.html

JHTc(JHTコマンドエディション)
JEF←→シフトJISコード変換ツール(コマンドプロンプト専用)
http://www.vector.co.jp/soft/winnt/util/se094205.html

はっきりいってMeftとNetCOBOLの組み合わせは
感動する

今20代後半でSEとPGを兼務しているもんだが20代初めの頃とある地銀でCOBOLしてますた
ついでにPL/Iとかアセンブラ（若干）とかも
今はwebアプリケーション（PHP,Javascript,Actionscript,JAVA(JSP & SERVLET),VBA(これ例外),Physon等,html,css)
やってるけどやり始めの頃は苦労しますたｗｗ
だって全然違うからｗｗ（基本構文とか、その他もろもろ）

でもCOBOLは不要って言うか捨てきれないところがあるんじゃないのかな？
JAVAにリプレースすると言っても銀行システムのソースともなれば莫大な量
になるし、新たにJAVAを教育する必要がでてくるしコストがかかる。
（銀行にいた頃富士通がCOBOLをJAVAに変換するツールをテストしていたけどどうなったんだろ？ＷＷ）

まあ自分はCOBOLがつまんなくて将来性も無いだろうと思って銀行やめて
web系に移ったんだけどねｗｗ

追記
　忘れてたけど一応JCLも使ってますたｗｗｗ
　（同年代で知っている人は殆どいねーんだろうけど）

大手銀行になると１日のトランザクション量が半端ないから、
言語云々よりコンピュータの性能と信頼性って感じはするけどね。
わりと新しい銀行はJavaで作ったって話はあるよね。

>>134
だけど辞めた後採用された言語がPASCALらしいｗｗｗ
PASCALはどういう言語かもしらないｗｗｗ
ただ情報系（自分が所属していたグループでは勘定系と対外系のシステムの
設計・開発・保守をしていた）はJavaらしいけど

>>134
確かにデータ件数半端ないよね（被仕向けはあまりおおくないけど）
言語云々は確かにどうでもいいんだけど銀行システムの設計・開発従事者
って根っからのCOBOLらー（しかも年配の方が多い）じゃないですか？
今更他の言語にするからって言うのも酷な気がしますね

Pascal人口少なそうだけどなぁ。
その言語の選択は大丈夫なんだろうかｗ

昔からある大手銀行だとCOBOLはまだ捨てきれないのかもね。

金融はシステムの良しあしが如実にサービスに直結するから、
どの言語が将来性があるとかより実現可能なものを選択するが正しいのか。

コンピュータの性能向上で最も御利益があるが一番競争が激しいセクターだよな。

そういう意味では旧来からある技術も大事だが、斬新な仕組みを作れたら競争優
位になりうると。

Pascalはポインタを*抽象的に*理解するには良い言語だと思う。
Cだとどうしてもアドレスと結び付けちゃうからな。

ただ、ものすごく窮屈な言語。

オレのオキニのピンサロ娘は
COBOLで動いてる

Pascalか…言語としてはJavaほどじゃないけど、COBOLよりはマシな感じだな。
JVMが要るJavaを抜きで考えると、まあアリなのかも知れない。
問題は使い手が少ないことか。
一応CやJavaと同じALGOL系統の言語だから
C使いやJava使いを転向させるのかな？

ただし、似てるようで似てなくて、似てないようで似てるせいで
CやJavaと同時に使うと非常に混乱する言語の筆頭でもあるw
文字列リテラルがシングルクォート、代入が := で等号が = （イコール1つ）
ブロックの開始終了が begin 〜 endだったっけ？
同じなのは文末のセミコロンや、関数呼び出しの括弧か。

標準Pascalは
・文字列処理が煩雑
・動的配列が使えない
・ブロック内の局所宣言ができない
・組み込みの数値計算関数が不十分
・モジュール構造と情報隠蔽の能力が弱い
などの理由で大規模・実用的なプログラムには向いていないとされる。

コンパイラぐらいなら書けるが、最初に大域変数がずらずら並んでて楽しいぞ

Pascalの標準ってそんなに弱いのかw

まあ>>135のはTurbo Pascalのように拡張されたものだろうが
CやJavaと比べてどういう利点があると思ったのかなあ

Javaと比べるとネイティブで動くから軽くできる
Cと比べるとメモリ管理が若干安全ってところじゃないか？

>>141
コボラーなら違和感無く移行できるってことか？

標準pascalでも手続き／関数と手続き／関数ローカルな変数は使えるでしょ
それが使えるだけでも標準COBOLより良くないか

まあ現実的な線なのだろう、色々と

OSだってかけるぞ、pascalは
macはpマシーンだし

>>148 おまえは何を言ってるんだ？

一番最初のWizardryはAppleのPascalでかかれてたんだっけ。

そういえばそうだったな。

あの頃のプログラマはマシン語で組むのに慣れていた感があるから、
Pascalにそんなステータスがあるのか疑問だったりするが。

ほとんど線とテキストだからなあ。

DATA DIVISIONでしかデータを宣言できない糞仕様言語より
Pascalのほうがマシだわな。

ちなみに、MacOS の初期バージョンはPascalを使って開発されています。
実用的にも初期のTeXやMacintoshのOSやアプリケーションの記述にも用いられた。

PascalのキラーアプリはPascalコンパイラ

せめてDelphi製アプリを何か挙げてやれよw

富士通・JEFコード変換DLL(CJEF)
http://www.vector.co.jp/soft/winnt/util/se339231.html
シェアウェア3,255円(税込)

http://www1.axfc.net/uploader/Sc/so/40852.zip

COBOLってUNICODEに対応したコンパイラあるの？

COBOLはアホPGの隔離先として絶対に必要だろ

>>160
Enterprise COBOLとMicro Focus Server ExpressではUnicodeをサポートしている。

>>161
メインフレーム用の、と付けるべき

走る、食べる、コボル

転ぶ？

あ、こぼれるだな

>>165
見事に?

私は（コボラ）凄い（つもり）

ああ、心にIDENTIFICATIONがなければスーパーコボラーじゃないのさ

筋肉頭GO TO

Yahoo!プログラミング言語検索ランキング（今回2009/10/12、前回2009/10/9）

. 1（. 1） HTML　　　　 　約5,020,000,000件（約5,030,000,000件）-
. 2（. 2） PHP 　 　　　 　約3,000,000,000件（約2,980,000,000件）++
. 3（. 3） Java....　　　　　約　832,000,000件（約　832,000,000件）0
. 4（. 4） Forth.　　　　 　約　324,000,000件（約　322,000,000件）++
. 5（. 5） Ruby..　　　　 　約　274,000,000件（約　274,000,000件）0
. 6（. 6） perl.....　　　　 　約　245,000,000件（約　244,000,000件）+
. 7（. 7） Python...　 　 　約　209,000,000件（約　205,000,000件）++
. 8（. 8） pascal...　　　 　約　168,000,000件（約　170,000,000件）--
. 9（. 9） Delphi　　　　 　約　128,000,000件（約　127,000,000件）+
10（10） VisualBasic... 　約　120,000,000件（約　121,000,000件）-
11（11） lisp...　　 　 　 　約.　 26,600,000件（約.　 26,700,000件）-
12（12） fortran.......　 　 約.　 21,300,000件（約.　 21,300,000件）0
13（13） COBOL.....　　　約.　 17,100,000件（約.　 17,900,000件）--
14（14） HSP 　 　　　 　約.　 12,400,000件（約.　 12,300,000件）+
15（15） FreeBasic..　 　約　　 6,300,000件（約　　 6,310,000件）-
16（16） Tcl/Tk......　 　　約　　 4,820,000件（約　　 4,940,000件）--
17（17） QBasic.....　 　　約　　 4,160,000件（約　　 4,180,000件）--
18（18） VisualC....　　 　約　　 1,340,000件（約　　 1,340,000件）0
19（19） DarkBASIC . 　約　　 1,330,000件（約　　 1,330,000件）0
20（20） BasicStudio 　 約　　　 302,000件（約　　　 302,000件）0
21（21） N88basic......　　約　　　 218,000件（約　　　 217,000件）+
22（22） f-basic....... 　 　約　　　 109,000件（約　　　 109,000件）0
23（23） ActiveBasic 　 約. 　 　　90,600件（約. 　 　　90,100件）++
24（24） 99BASIC....　 　約. 　 　　11,300件（約. 　 　　11,300件）0

3Dprogramming 約792,000件（約790,000件）++
2Dprogramming 約. 57,100件（約. 57,600件）--
intel 約714,000,000件（約726,000,000件）--
amd 約349,000,000件（約352,000,000件）--

Forthが４位って意外な感じがする。
HTMLは言語ではないだろう。

back and forth

PHPはともかくHTMLを「プログラミング言語」と呼ぶのには違和感が

違和感もなにも、HTMLはそもそもプログラミング言語じゃないわな

バカお一人様〜♪

Yahoo!プログラミング言語検索ランキング（今回2009/10/16、前回2009/10/12）

《一般カテゴリ》
. 1（. 1） HTML.....　　　　約5,030,000,000件（約5,020,000,000件）+
. 2（. 2） PHP...　 　　　　約2,980,000,000件（約3,000,000,000件）--
. 3（--） BASIC.. 　 　 　約1,580,000,000件（....------------- ）0
. 4（. 3） JAVA.. 　 　　　約　822,000,000件（約　832,000,000件）--
. 5（--） CGI. 　 　 　　　約　551,000,000件（....------------- ）0
. 6（--） C言語（*1）. 　 約　399,000,000件（....------------- ）0　（*1）C/C++とC#の検索件数の合計
. 7（. 4） FORTH..　　　　約　323,000,000件（約　324,000,000件）-
. 8（. 6） PERL..　　　　　約　245,000,000件（約　245,000,000件）0
. 9（. 7） PYTHON..　　　約　213,000,000件（約　209,000,000件）++
10（. 8） PASCAL..　　　約　168,000,000件（約　168,000,000件）0
11（. 9） DELPHI.　　　　約　128,000,000件（約　128,000,000件）0
12（11） LISP　　　　　　約.　 26,000,000件（約.　 26,600,000件）--
13（12） FORTRAN. 　　約.　 21,200,000件（約.　 21,300,000件）-
14（13） COBOL.....　　　約.　 16,800,000件（約.　 17,100,000件）--
15（--） PROLOG　　 　約.　 13,800,000件（....------------- ）0
16（14） HSP 　 　　　 　約.　 12,300,000件（約.　 12,400,000件）-

《BASIC言語カテゴリ》
. 1（--） VisualBasic... 　約　120,000,000件（約　121,000,000件）-
. 2（--） Hu-BASIC..　　約.　 15,000,000件（....------------- ）0
. 3（--） QBASIC..　 　　約　　 4,140,000件（約　　 4,160,000件）--
. 4（--） MSX-BASIC.....約　　 1,430,000件（....------------- ）0
. 5（--） DarkBASIC . 　約　　 1,310,000件（約　　 1,330,000件）--
. 6（--） CBM-BASIC.　約　　　 944,000件（....------------- ）0
. 7（--） BasicStudio 　 約　　　 303,000件（約　　　 302,000件）+
. 8（--） N88BASIC..　　約　　　 219,000件（約　　　 218,000件）+
. 9（--） X-BASIC...　 　約. 　 　　40,400件（....------------- ）0
10（--） 99BASIC....　 　約. 　 　　11,400件（約. 　 　　11,300件）+

CGIは言語じゃないだろ

CGIは言語ではないよな。

俺の好きなX-BASICが9位ですかい。

1はこんな所にｽﾚ立てずにCOBOLﾕｰｻﾞｰに
VBだかJAVAだかでﾘﾌﾟﾚｰｽするよう営業すれば
いいんでない

COBOLって、もはや官公庁案件しかないのでは？

官公庁の案件にかかわったことはないが
民間の金融機関（特に保険）の案件で扱ってる言語は、今でも絶賛ＣＯＢＯＬ真っ盛りだよ。
そもそも築き上げられたシステムの規模が巨大すぎてリプレースするにも手がつけられないしな。

国税の「給与所得者の源泉徴収票」も
CMTの取り扱いを今年限りで終えるらしい。

メインフレームで大量に印刷する帳票とかはCOBOLで書いてた
それを三つ折にして封入封緘するマシンにかけるためのバーコード印刷とか
郵送するためのバーコード印刷とかも。
まあ昔ながらのメインフレームの単純なバッチ処理だけど、そんなの最新の技術でなくても
COBOLが一番適してたりするんだろうな

時代的に大量に印刷とか、そろそろやめる方向じゃねーの？
エコに反する。

そんな事したら予算がとれないじゃないか
私腹を肥やせなくなったら困るだろ？
エコなんて口先だけでいいんだよ

>>185
そうはいっても今月もカード会社や携帯電話の会社からは紙の請求書が送られてくるわけで
それは全部メインフレームで大量印刷して封入封緘機で処理してるんだよ
どうやったらやめれるか真面目に考えた事あるか？
BtoCのデータ交換が本当に実用になれば可能かもしれないが
少なくともPC使えないじいさんばあさんが死滅するまでは無理だろうと思う

IDENTICATION DIVISION の私が来ましたよ

FさんとIさんはどこへいったんだろう。

COBOLっておいしいの？

>>188

見出し部か？

COBOL=毒饅頭

おいしいかも知れないが、その先に待ってるのは死、か
良い例えかも知れないな

今日はCOBOL開発者の誕生日

グレース・ホッパー - Wikipediahttp://ja.wikipedia.org/wiki/%E3%82%B0%E3%83%AC%E3%83%BC%E3%82%B9%E3%83%BB%E3%83%9B%E3%83%83%E3%83%91%E3%83%BC

COBOLのデータって扱いにくいよな、PACKとか。
バイナリエディタで見ても醜い。
Excelとかで見れればどれだけ楽か。

まだそんな会社あるんだ。遅れてるね。
そういう会社は一生、この先にメーカーの食い物にされるだけだろうね。

×この先メーカーの食い物
○この先糞メーカーの食い物

いらねー

>>185
凸版印刷の子会社で一部上場のトッパン・フォームズという
会社がそれ専門でやっていてバブル崩壊後もほとんど前年比
プラスで驚異的に成長してる罠。
役人が証券、金融機関を中心に民間企業に余計な報告義務を
以前よりも課してるから、消えるどころか余計に増えてる。

電子化のおかげで、印刷物が大量に増えたのは事実。

確実に増えたね。
顧客データが現在よりも電子化されてなかった頃は
封緘物や圧着はがきのＤＭも少なかったから。
減ったのは机上デバッグ。>199の会社は昔はインパクトプリンタの
連続用紙を独占してるような感じだったから、AS/400だのN5200だのの
COBOLのソースを凸版印刷謹製の連続用紙に打ち出して仕事やってたよ。

いまどきソースをインパクトプリンタ使って印刷してる目検してる所あるの？
何十年前の話だよ。

COBOLもいまどきはIDEとかじゃねーの？ちがうの？

cobolなつかしいな。まだやってるのか

ISPFはIDEに入りますか？

入りません。

1. Cobolコードの約2千億ラインが生きて活動している
2. 世界のビジネス・データの75パーセントがCobolで処理されている
3. 世界中の財務トランザクションの90パーセントがCobolで処理されている
4. Cobolコードで作業している開発者が世界で150万人から200万人居る
5. 約50億ラインの新しいCobolコードが毎年システムに追加されている

ヌルポなんてエラーが頻発する言語は使えん

>>187>>199
自分は昔、そのトッパン・フォームズの子会社で、
まさに大量印刷のプログラム開発してた。
マシンはIBMで言語はCOBOLを使う時もあるけど、
ほとんど、アセンブラだった。
役所や各企業から、大量のデータを磁気テープｗで
受け取って処理するんだけど、当然、各企業によって
漢字コードはバラバラ。大型プリンタから印刷するには
それらの漢字コードをIBMに統一する為の変換処理を
しなければならない必要があったから。
それから、ユーザー定義の漢字コード（外字と呼んでいた）を
含む場合、漢字コードを１文字１文字チェックしなければならない。
言語はアセンブラが適していた。まぁ、自分の居た部署は
ちょっと特殊だったのかもしれない。
スレタイExceptionな話になってしまったけど、CISCマシンでの
アセンブラは楽しかった。

長文失礼。

コボルが無くなったらおじさんの仕事がなくなっちゃうよー

若者がCOBOLを覚えないのでおじさんが引退できないよー

超初心者なんですが

プロコボルとパワーコボルっていまいちわからん・・・
DBはどっちで最初に読み込むんですかね。

プロコボルでDBから値とってきて格納
それをパワーコボルで定義して画面に使う感じでいいんでしょうか。

pro cobolはexec sqlの部分をcobolのソースにするだけだろ。

自分が他の言語を扱えないからって今の世代にCOBOL押し付けんな
氏ねロートル

自分が他の言語を扱えないからって他の奴らにVBA押し付けんな

大量印刷云々言うけど、最近は信販会社も請求書を葉書に換えたりしてるし銀行も明細出さなくなってきてはいるよね。

来年からcobol保守の中小IT。新卒。
奈良の市役所の公務員も目指しているがどちらが良いか・・・

会社自体は残業は全く無い（信頼できる先輩より）優良企業と言っているが・・・

市役所公務員でケースワーカーやることになってもいいんなら、公務員目指せ。
能力や適正を酌んでくれると思ったら大間違い。
人事はもちろん、情シス管理職にも評価能力なし。
責任逃れするために業務は丸投げ、出る杭はへし折られる。

優良企業、裏を返せば顧客こけたら総崩れ。

>>217
>>218
そうなんだよなぁ・・・
顧客はこけることはまず無い企業であってほぼ

でも公務員になりたい。
市役所ってやっぱりしんどいかなぁ。
学校事務も考えてるんだけど・・・教員免許いらないし。

公務員が就職NO１とか終わってるよな。

日本の場合は身分保障あるのに給料がいいなんて優遇されすぎ
むしろ身分保障あるけど薄給にしないと、放置したら何年かで破錠するよ。

日本がギリシャ化するのはわりとすぐ先の話だぞ
今の日本人に暴動起こすほどの甲斐性なんてないし
公務員で安泰なんて甘い考えは捨てた方がいい

同意

公務員の給与減らして、やなやつはやめさせればいいのよ。
どうせ大した仕事してないんだしさ

COBOL誕生50周年
http://iiyu.asablo.jp/blog/2010/05/25/5111701

まだ50年しか経ってないのか

無知で愚かなＰＣプログラマーに教えてつかわす
メインフレームから何故ＣＯＢＯＬがなくならないか？
おおきな理由のひとつが、ＰＣでは
パック十進をサポートしていないからだ。
ＰＣではパック十進をＣＰＵもサポートしていなし
サポートする言語もない。
金融、証券のシステムでは、
高速、厳密な、金の計算のためにパック十進の演算が必要なのだ。
メインフレームでは、ＣＰＵもＣＯＢＯＬ言語もパック十進を
サポートしているのだ。
（インテルのＣＰＵはＢＣＤ演算をサポートしているが
使い物になっていない）

逆に言えば、言語でサポートされていないと充分高速に10進演算を行なえないから未だにしがみついているんだな。

釣れますか？

Adaにもあるし、C#にもある。

>>225
Lisp 系の言語だと扱えるんですけれど, COBOL で無限精度の小数点が扱えますか？
必要となったときに必要な桁まで計算する. ってのは出来ないでしょ
で, 実質的にはそっちの方が速いって知ってますか?

>>229
それは無意味だ。

PackとかZoneって、ＩＢＭ汎用機でも有効桁数は40桁ぐらいでしょ。
個人的には30〜36桁ぐらいで実務的に十分て感じはするけど。。
C#なんかだと28桁ぐらいだったけど・・・

>>229
π(3.14.....)とか 1/3(0.333....) といった無限精度を扱えるの？

１０進化浮動少数点型は見かけるようになったが、
ＢＣＤを新規にサポートしようという言語は見たことがないな。

>>233
意味不明

データ型のことを言いたいのか、それとも内部表現形式のこといいたいのか？
また、内部表現としてBCD(あるいはそれに類する形式)で実装された
C/C++の固定小数点型ライブラリは、かなり以前(1980年代)から存在している
でもそれはライブラリによるサポートであって「言語によるサポート」じゃない

BCDだろうが、固定小数点（10進）だろうが、得られる結果は同じ。後者が効率的。

COBOLスレなのだから組み込みのデータ型のことだろ。
ソフト的にというならたいていの汎用言語で書けるぞ。

変数ごとに個別の精度（桁数）をもつCOBOLのBCDと
単一の精度で浮動小数点のC#のdecimalでは気をつけないと結果は変わってくる。

証券のシステムと言うのなら
東証の新旧システムをググって見ては？

つまり任意精度をもつデータ型が欲しいということですね。

COBOLやAdaにはあるね。

リプレイスしたときの障害（リスク）」がおっかねえから
現行をだましだまし使ってるだけだと思う。

C#だと移植しやすくない？デシマル型が使いやすそう。

>>241
桁数指定できない時点で、お呼びでない。

たしかに任意精度を指定できたほうが都合がよい場合があるよな。
例えば、下記のように10桁で、そのうち5桁が小数部というように。

var num = new Decimal(10,5);

海外の金融系なんかだと以外とdouble型使ってたりするよね。
.NET4ではBigInteger導入されたけど、パフォーマンスの理由でBigDecimal導入が延期されたはずだから
MSもその辺は理解しているんではないかと思うが。。

それならJavaはOKだな。BigDecimal

cobol -> javaのリプレースはやってたりするね

別に流行ってないと思うが。

一昔前はCOBOLで書いた既存システムをJavaへ書き換える(リプレースする)、
JavaがあるからCOBOLは過去の遺物だ！と考えるコンサル/ベンダが多かった。
でも、そんなリプレースプロジェクトの大半が失敗してボロボロに。

今では、基幹業務(ビジネスの核)はCOBOLでコンポーネント化し、
システム全体をJavaで包み込むという、共存共栄のアプローチが主流。

今さらCOBOL不要論を唱える人ってのは、単なる無知なお馬鹿さんか、
あるいは失敗したリプレースプロジェクト関係者であり、
自己正当化(漏れは悪くない、悪いのはCOBOLだったのだ！という責任転嫁)では
ないのかと。

現実的にはそういうのは仕方ないと思うが
そんなのが主流だから日本のITはダメなんだとも思う
現場のPMだって、わざわざ新規でやり直して失敗するリスクは取りたくないから
ずっと残り続けるだろうね

Javaに移行出来たら、AS400とかなんちゃらseriesだとかは要らなくなるわけだし
陰謀説だって考えてしまうよ
その主張をしていたコンサル/ベンダにはIBMは含まれていたの？

Javaは既にIBMの第２のCOBOＬで、
Power Systems(旧ASをなど)やSystem Z(旧System.360系列)でJavaは主力言語のひとつ。
>>247のようなソリューションを使うとIBMのハードやミドルウェアから脱却できなくなって、
今まで以上にＩＢＭの奴隷と化す。

自分はIBMの中のひとじゃないから真実は知らないけど、
IBMはJavaもメインフレーム系コンピュータ(AS400含む)も扱っているから、
それぞれの部門で、自部門が優位になるセールスをしていたのでは？と思う。
それは富士通/日立といったメインフレーム資産を抱えた他メーカも同じだと思う。
こういったメーカ(大企業/企業グループ)では、よくある風景ではないかと。

過激なCOBOL不要論者の中心は、Javaやオブジェクト指向設計を唱える、
新興のコンサル/ベンダだった。彼らはI/F/Hが抱える優良な顧客を
何としても切り崩そうと、必死になっていた(なっている)から。

>>249
前半は良しとして、後半の部分には疑問が残る。

COBOLを扱うベンダはIBMだけではないし、それらCOBOL処理系を扱う
メジャーベンダは、生き残りを賭けて>>247と同様なソリューションを
提案している。SOAやESBといったキーワードで表現されるソリューションね。

結局、IBMの奴隷から解放された(IBMから脱却した)と思っていたら、
気が付くと他のベンダの奴隷になっていた、では意味が無いんじゃないかと。
COBOLから解放されたらJava(Oracle)あるいはC#(Microsoft)の奴隷へ、というふうに。

OracleやMSは別にメインフレームを売りつけてはこないでしょ
ハードとの結びつきが強すぎることが問題
結びつきが弱ければ、ハードウェアは他社を選択することだって出来るだろうに

すでにIBMがメインフレーマではなく、(メインフレーム「も」扱う事のできる)
SIベンダへ変身したという事は、常識だと思っていたんだけどね。
IBMにとってメインフレームはソリューションに含まれる「選択肢」の一つでしかない。
どの企業も自社の得意な(他社と差別化できる)提案するのは当然の事だと思うが。
それを「ハードウェアによる独占」へ強引に結びつけようとする発想は、
もう何と言うか「時代錯誤」としか言いようがない。

SOA/ESBの世界では、メインフレームは構成要素の一つでしかないし、
メインフレームはコストを度外視できる高信頼性システム開発の場でしか生き残れない。
だから、(そこまで信頼性を求められない)多くのメインフレーム上のCOBOLアプリが、
次々とPC/WS上へ移植(COBOLからCOBOLへリプレース)されている。
COBOLは、プラットフォームの壁を乗り越えて、今後も生き残っていくだろう。

>>253
>COBOLは、プラットフォームの壁を乗り越えて、今後も生き残っていくだろう。

COBOLにとっての壁とは、プラットフォームなどではなくて
腐った言語仕様なのだが・・・

>>254
そのとおりだね。

ただ、「JavaはVMでプラットフォーム非依存だからCOBOLよりも優れている」とか
「Javaへの移行によってCOBOLベンダーの束縛から解放されるべきだ」といった
考え方は誤りであって、しかも「COBOL不要論」には無関係であることを言いたかった。

COBOLの腐った言語仕様....というのは、COBOL不要論に結びつく話題だと思う。

確かに、COBOLが腐ってなければ移行する必要はないなｗ

COBOLが設計された時代を考えると、言語仕様の良しあしを論ずるのはナンセンス。
新規に設計するシステムをCOBOLでやるということはまずない。

lispよりも新しい言語なのに、その主張はないです

>>257

COBOLは現実に使われているのだから、COBOLの設計された時代を理由にして
言語仕様のマズさを無視すべきという考え方こそ、ナンセンスではないかと思う。

だたし、COBOLの言語仕様がマズい/腐っているのか否かは、また別の議論。

>新規に設計するシステムをCOBOLでやるということはまずない。

「COBOLは現役バリバリ」，東京海上日動がシステム全面再構築でCOBOLを選んだワケ
　　http://itpro.nikkeibp.co.jp/article/NEWS/20080906/314277/

>>259
右下に [2008/09/06] って書いてあるな。

そして、またそんな事がニュースになっていること自体、
何かを物語っているのでは？

>>259
そのワケって、自社で抱えている大量のCOBOLerの仕事を作るためじゃない。

>>260
ニュース記事にならないほど、COBOL現役が一般的な状況を物語っているね。

>>261
仕事作りの為だけに高額な開発予算を投入するほど、日本企業は甘くはありませんよ。

変な日本語だったので、書き直す。

X: ニュース記事にならないほど、COBOL現役が一般的な状況を物語っているね。
O: この記事は2年前のものだけど、2010年の現在ではいちいちニュース記事に
　ならないほど、COBOL現役が一般的な状況を物語っているね。

え？　いまどき保険会社はiphoneで顧客に提案とか普通じゃないの？
まぁ古い会社はどうしようもないね

>>264

>>247を嫁
>今では、基幹業務(ビジネスの核)はCOBOLでコンポーネント化し、
>システム全体をJavaで包み込むという、共存共栄のアプローチが主流。

iPhoneのような外周のサービスコンポーネントはJava/C#で開発するのがベスト。
でも業務の核となるビジネスロジック部分では、COBOLが使われ続けている。

あと、君には難しすぎるかもしれんが、これも読んで勉強しなされ

・連載：Webと企業システムを結ぶ実践的アーキテクチャ　第1回 - @IT
　　http://www.atmarkit.co.jp/fjava/rensai/webarc/webarc01.html

・連載：COBOLのいま、未来そしてクラウド - ＠IT
　　http://www.atmarkit.co.jp/fcoding/articles/cobol/03/cobol03a.html

>実際，新システムでは旧システムから2000本のプログラムを部品として有効活用できた

こんなの、"新規"とは言わないんじゃないの？

もうずっと前からCOBOLなんてなくなると言われ続けているからな。

画面系はVB5,6のオープンシステム化の時と
JavaのWeb化の時に一気に加速したけど
それでもバッチだけは生き残っている現実。

>>266
学生さん？いや、学生がCOBOLなんかに興味を示す訳ないからw、
社会人なりたての新人プログラマさんかな？それとも趣味グラマ？

今時、Javaですら既存コードを流用しないプロジェクトなんて無いよ。
業務アプリで膨大な過去のJavaクラスライブラリを捨て去って、
１からすべて作り直すなんてことを提案したら、笑われるか馬鹿扱いされる。
普通は既存のクラスライブラリ(部品)を活用して、その他のコンポーネントを新規開発する。
プロジェクト全体からすれば、それは新規開発プロジェクトなんだけど。

この記事では、オブジェクト指向ではないからCOBOLは既存のコード(部品)の活用が
難しいと思われていたけど、予測していたよりも活用できる多かった事を言ってるだけ。
既存部品を活用しても、全体から見れば、それは新規開発プロジェクトを呼ばれるのさ。

>>268
>学生さん？いや、学生がCOBOLなんかに興味を示す訳ないからw、
>社会人なりたての新人プログラマさんかな？それとも趣味グラマ？
出来れば「何故かCOBOLに興味を持った学生さん」だと思っていてくれると嬉しい。

>１からすべて作り直すなんてことを提案したら
まず「作り直す」という言葉を使っている時点で、それは「新規開発」とは呼べないね。
それは実質「既存システム」のリプレース（又は拡張・改修）。
実際、今回の例も「システム全面再構築」であって「新規システムの構築」ではない。
お金の話が絡むし、当事者間で「新規開発」という言葉を使うのを
無下に否定はしないけれど、この場の実例として持ち出すには不適切過ぎる。

>>269
>出来れば「何故かCOBOLに興味を持った学生さん」だと思っていてくれると嬉しい。

そうだねw

>当事者間で「新規開発」という言葉を使うのを

>>268は開発プロジェクト内部からの視点で書いていた。
顧客サイド、あるいは対外的には、新規開発じゃないね。不適切だった。

>>266に対しては「そもそも再構築であって、"新規" ではない」と返すべきだった。

> 「COBOLは現役バリバリ」，東京海上日動がシステム全面再構築でCOBOLを選んだワケ
> 　　http://itpro.nikkeibp.co.jp/article/NEWS/20080906/314277/
この記事って、
「他の言語が使えないじじいを有効活用しようとすると、
COBOL を使わざるを得なかった」
って、読めたんだが…

COBOLで書いたコードはゴミ
他の言語に直したくても、コンバートしたところでゴミであることに変わりないし、手で書き直すと金がかかる
そもそもドキュメントも整備されてないし、客も仕様を説明できない
だから適当な方法でラッピングして塩漬けにするしかない
これが現実

これを現役というのはあまりにひどい

COBOLから他言語への移植の障害はCOBOLの文法そのものよりデータセットなんだよね。
COBOLフォーマットのレコードを他言語で扱うのも大変だし、
他言語で扱えるようにフォーマットを変換するのも大変。
DBにRDBを使ってるならまだ対応の使用もあるけどね。

>>272
まったくその通りだね。
「他の言語を使える若人をこき使おうとしたけど役立たずで、
　しかたなくCOBOLしか使えないじじいを引っぱり出さなきゃならなくなった」
って、読めるよね。情けないよなぁ....

失礼、アンカを間違えてました。>>272は誤りで、>>271が正しいアンカです。

データセットといえば、基本情報で各種編成ファイルのことを習うけどさ
あれってCOBOLと、メインフレームが消えれば、学ぶ意味なくなるように思う
シーケンシャルファイルぐらいは、DATテープとかで見るけど

>>272
その原因は本当にCOBOLにあるのかな？

「ドキュメントも整備されてないし、客も仕様を説明できない」というコードは
いつ頃書かれたものなんだろう。もし最近だとしたら、
・そのコード/ドキュメントを書いたコーダ/デベロッパ、あるいは
・そんなコーダ/デベロッパしか雇えないベンダ、あるいは
・そんなベンダにしか相手にしてもらえない顧客
に原因があるのであって、それをCOBOLに押し付けるのは「責任転嫁」ではないのかな？

あるいは、 もしもそのコードがずっと昔に書かれたもの(いわゆる負の遺産コード、腐ったコード)で
あり、なおかつ自分達のコンバート技術力に自信があるのなら、顧客から高い金を釣り上げればいい。
それは>>272も分かっているのでは。そして、顧客が金を出し渋るから「対処療法」であることを
(顧客を含めて)納得した上で、ラッピングという手法を選んだのではないかな？

要は、コンバートの難しさの本質的な原因は、本当にCOBOLという言語にあるのか？、もしかすると
過激なCOBOL不要論を唱えるベンダ/コンサル(>>250)の詭弁に騙されているのではありませんか？
ということを言いたい。

リレーショナルモデルとか色々と技術が確立されていない時代の遺産だからなぁ

現時点でプログラムがなくなればCOBOLは不要だが、
現実は、COBOLで書かれたプログラムは必要。
リプレイスが進む速度もカメ。

金融系なんか下手すりゃ首吊らないといけないのに若者が手出すかよw

>>273
>他言語で扱えるようにフォーマットを変換するのも大変。

オープン系(UNIX/PC)なら SQLite というサーバレスなRDBがあるから、これをCOBOLから利用できれば、
あとは「COBOL形式レコードをREADしてSQLiteへINSERT」する単純なCOBOLプログラムを作って
実行することで、多言語から扱えるファイルが簡単にできる気がする。性能が心配だけど。

ちなみにOpenCOBOL(NECじゃなくオプソ版のほう)の場合は、標準でSQLite APIが使えるみたい。

・Open COBOLでSQLite3を使おう
　http://www.geocities.jp/sanpontze/xindex.html

他には、XDR(External Data Representation)が使えないかなあと妄想している。

>>276
>あれってCOBOLと、メインフレームが消えれば、学ぶ意味なくなるように思う

COBOLに限らずバッチ処理の入出力で使われているから、バッチ処理そのものが無くならない限り
無理じゃないかな。他の形式(CSVやXML等)もあるけど、大容量で索引アクセスが可能な形式となると....。

いまだにテープに保存してるんでしょ？

オープンリールはさすがに、もう無いんじゃないの？
普通、暗号化された別の媒体に移行してるでしょ

お前らCOBOL以前に基礎ないだろ。RDBとか言って、お前らみたいな口だけナのが
パフォーマンす問題引き起こすんだぞw

>>274

http://itpro.nikkeibp.co.jp/article/NEWS/20080906/314277/
にはこう書いてあるんだけど。

『プログラミングと単体テストを5カ月で終了しなければいけないスケジュールを乗り切るには，
これまでのノウハウや人材を生かしきらなければならないと判断した』

ていうかお前ページきちんと読んでる？
他の言語に移行したかったとか、若人の技術力が不足していたとか、そんな文脈一つもないよね？

厭味で饒舌な癖に言ってることが的外れなのって自分で恥ずかしくならない？

スケジュールありきのプロジェクトはどうかと思うけどね。
収益の柱になるシステムなら随時改修する方法が良いと思うけど、そういう発想自体がないんだろうね。

銀行のシステム止めたらうん兆円規模の損害出るんですけど
どうやって改修するんだよ

諦めるしかない。銀行とかああいう政府に近いところは、金融庁からのおしかりもあるんでしょ？
改修できなければ、負の資産はどんどん膨らんでますます回収出来ないスパイラル

Googleみたいに、一部停止するのはあたり前、という前提の
システムに作り直せると良いのにね

合併とかした時にまとめてやる

数週間前から絶対大丈夫ですってCM流して失敗した例があるけど
あの時はどれだけ損害が出たのだろう

どっちかのシステム捨てるか、超慎重に統廃合するしかないんだろうけどね。

しかしCobolの仕事って墓守みたいなものかもな。
メインフレームを使う必然があるタスクとは何？だよな。何十年も前うん百万もしたメインフレームの性能を今は１０万円のパソコンが上回るんだからな。

今日見知った奴、アセンブラからCOBOLに転向だと。
細かい配慮はできないし、洞察力もなければ発想力もないから似合いだと思うw

>>292
おま、なにゆってるんだ？？？
１０万円のパソコンがマシンチェックして命令の再実行とか
プロセスマイグレーションとかやってくれるのか？？？
# COBOL はどうでもいいけど、それなりの大型機は馬鹿にできないぞ

メインフレームとパソコンは利用する業務領域が違うし、
求められる信頼性や性能が格段に違うからなぁ

10年前のメインフレームといまのパソコン比べたらそういう結論になるかもしれないけど・・・

今のメインフレームは面白いかもしれない
http://globalserver.fujitsu.com/jp/products/gs211600/specifications.html

>>293
COBOL の人は COBOL の業界だけで閉じていてください
組み込みの親分なんか絶対やっちゃダメ！！！

25年前からCOBOLは終わった言語って言われてたんでしょ？
いつになったら終わるんだ？　俺は他の言語を選んでしまったけど
COBOLで書いてる奴が一番収入多いんだが・・・

漏れもモーター制御なんかやめてコボルにでもどろうかな

>>299 あきらめろ
おまいはもうコボルに戻れない体になっている

10万のパソコンが30年ノンストップで動きますかってお話。

その話は COBOL と無関係。

10万のパソコンでも、じゃぶじゃぶ保守費を投入すれば、ノンストップで動くだろうよ

30年間ノンストップって銀行でもないだろ。
今なら、クラスタで実現だな。

原子炉の寿命が何年かしらんが, 最低限30年間ノンストップは期待したいところだな
少なくとも, 50 年保証の A/D コンバータユニットなら見たことある
# つか， すでに COBOL 関係ないしwww

おまえら原子炉のシステムなんて組んでるのかよ。まじこええな。ちゃねらーなんかにやらすなよ。

COBOLは腕のいい技術者が適切な分野で適切に使えば非常にシンプルかつ機能的なシステムが作れる。
もちろん現状はご存じの通り。

腕の良いCOBOL技術者は現場には残ってない。

大きなプロジェクトで、人を集めると
下受けの中に混じっていたりする。
名刺交換したら、部長やらフロアマネージャーでビックリ

最近オフコン/メインフレームの保守業務に就きました。
皆様メインフレームのCOBOL/JCLプログラムはTSO/ISPF上で書いてるのですか？
上司は端末上のほうが早いというのですが信じられない。

emacs使いの言う事みたいなもんかなあ・・・？

コーディング用紙に書いてパンチチャーに穿孔カードを作ってもらうのが基本。

大昔の話だけど、（細かい修正は別として）基本はPCにファイル転送して
PCのテキストエディタで書いてたな。
でもISPFのエディタもいい点はあるよ。カラム指定の検索・置換とか
PCのテキストエディタでできる奴ないもん。

>>312
> カラム指定の検索・置換とか
emacs の cobol-mode って, その程度の機能持ってないの?

>>312
やっぱり大昔でもPCで書くのが普通ですよね。
俺の今の職場に1年後は無いな。

MSP（富士通)だったけど，当時はエミュレータ上のエディタでコーディングしてた。
官庁で作業してたとき変なの〜と思ったのが、一旦Window上でコーディングしてそれをホストにアップロードするようにって言われたの。
直接ホストのエディタで直接編集したら駄目！って言われた。
カナの扱いとかでアップロードするときの指定がめんどくさかったのを覚えている

その他の現場ではWindowsのエディタで編集してUnixホストへアップしてたか。これはその方がやりやすかったけど。

何言ってるんだ全部AP/DF(富士通)でやった方が早い

神のみぞ知るセカイってアニメを見たんだが
作品中で『はじめてのコボル語会話』って本が図書館から処分された
コボルいらないよね

>>312
これどう？

* エディター (Hybrid Editor XE)-->ヘルプHTML v1.25J

メインフレーム(SPFファイルの編集にも便利) と PC と 両方仕事している人に使い易いエディター。
ホストのSPFをベースにPCのEDITORの便利なキー操作をハイブリッド。
バイナリーエディター（ダンプ形式と３行平行表示形式と２種類サポート）,ファイラーとしても使えます。
LogfileなどをExcelで解析できるように編集する機能も強力。
各版がDOS, OS/2, Windows, Linux, AIX で共通の操作を提供。
Windows, Linux, AIX版ではftp/rshによるリモートアクセスサポート。
Windows, LinuxX版ではS3270+IND$FILE+TSOを利用してTSOファイルアクセスをサポート
WIN版/Linux版は拡張子による関連付けを利用した、
excel,explorer/OpenOffice,Nortilus等との連携もサポート

http://www.geocities.jp/sakachin2/#Japanese

>>316
PFDのＥＤＩＴの方が使いやすい。

pfd 2だっけ？
ddとかいじった

PFD懐かしっ w

各部署の端末にfimportやらfexportの設定やらして回った昔が懐かしいよ w

pdfは使いにくいので
windows上でテキスト書いて
importさせてたの

INITIALIZE >>1->>1000

MOVE ZERO TO >>1->>1000

>>321
俺もそうだったな、メモ帳で書いてimport

ＣＯＢＯＬってなんで嫌われたんだろね。

cobolからcに移ったときファイルアクセスで相対編成とか索引編成がないのに戸惑った

相対編成ってどんなやつ？
こないだ勉強したんだけどそれは無かった
直接編成の相対アドレスまたは直接編成のキーレコードの間接指定のこと？

これでいいか？
http://software.fujitsu.com/jp/manual/manualfiles/M050005/B1JN5971/01/ffdmk01/ffdmk007.html

どうも。なんか違うものを参考にしてたようだ

COBOLの仕様と情報処理の知識としてのファイル編成の違いじゃないかな

COBOLって今風に言えばデータオリエンテッドな言語じゃん。
しかも、そのデータ構造定義がグローバルしかないと言う。
ラダーチャートもそうだけど、逐次処理型じゃない言語は
発想の転換が必要だから土方仕事には向かないってことでしょ。

>>330
釣りですか？

COBOLはバリバリ手続き指向言語だろ
COBOLで処理するためなら業務もデータもねじ曲げる

>>330
COBOLを今風に言えばCOBOLです。

>>331
COBOL2002の事もたまには思い出してください・・・

ちなみにこんな感じにキメエ。

CLASS-ID. 預金口座 INHERITS BASE.
…
FACTORY.
…
END FACTORY.
OBJECT.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 残高PIC S9(16)V9（２）.
01 名義人PIC N(40).
PROCEDURE DIVISION.
METHOD- ID. 預け入れ.
…
END METHOD 預け入れ.
METHOD- ID. 引出し.
…
END METHOD 引出し.
METHOD- ID. 残高照会.
…
END METHOD 残高照会.
END OBJECT.
END CLASS 預金口座.

いつになったら終りなんですか？ >みずほ

中華系が逃げたとか？

みずほはどこ？富士通？

一勧のシステム引き継いでるなら同じ古河三水会の富士通
他のだったら知らんがな

みずほは富士通多いけど日立とＩＢＭも混在してる

ビット演算をやりたいんですけど、諦める以外に方法はありますか？

COBOL のことはあま知らないが COBOL から呼べるライブラリつくれば?

COBOLこそ最高の言語じゃん

確かに、JAVA、C#なんて中小企業が渇望してるし、戦国時代のように栄枯盛衰を繰り返してる
けどCOBOLのバックアップ企業を考えてみると、バックは銀行業
COBOLは銀行業からずーっと使おり、この銀行は、いざ破産に近づくと国が融資する

国がパックについてる以上、一生食っていける言語と言うわけだ
一方、JAVA、C＃はバックが中小企業
この中小企業は倒産しても国は援助してくれない

言語的優劣ではなく、一生食っていけるかいけないかで言えば、新言語は価値なし
COBOLはジジイになっても仕事がある

>>340
環境が分からないから、誰も判断できないよ。
COBOL2002以降だったら、ビット演算も
できると思う。
そもそも、なんの為にビット演算やりたいの？

>>340
確か富士通のFACOM／OS IV　MSP上で動いてるCOBOL
（バージョンによると思うけど）だったら、
PIC X(01) VALUE B'00000001'
こんな指定が出来たと思ったけどなー
できなかったらエディタでHEX表示して
PIC X(01) VALUE 'x'←リテラル内のxはHEXコードで01
みたいにすればいいんじゃないのかな
WORKING-STORAGE SECTIONに01からFFまで全部用意して
その値を使った演算をするサブルーチンを自分で作る
（ごめんねアナログな答えで）

COBOLはビル・ゲイツ様の思想に反するからなー
自分は大好きだけどね
20年前から、ずっと、ずっとCOBOL大好きで一筋です
老害でごめんなさい

>>345
bit 演算できないのビル・ゲイツ関係ないし
>>340
なんでCOBOLでビット演算したいの？
そんなことをするための言語じゃないんだが

他の言語やってたのかどうかしらんけど
COBOLの現場に来てCOBOLは糞だってわめく奴が居て困ったことがあったなー
そういう奴がよく口に出して言うのが
「COBOLはビット演算できないから糞」
やりたきゃ自分でサブルーチン作ればいいんだよ
できなくはないよ

うちの会社で使ってるＣＯＢＯＬにはビット演算ついてた
誰も使ってないけど
素直に他の言語で・・・　

>>347
それはある意味そのまんまあんたに返る
有効桁の概念のないCOBOL屋が科学技術計算分野に来て
「桁落ちします!!!」
って言うのと同じだが

アセンブラじゃダメなのか。

>>350
>>341 が言ってるのはそうゆうことちちゃう？

長い人生のちょっとした暇つぶしにコボルを触ってみました。
数学関数はあるのにビット演算は実装されていないのが滑稽に思えたがゆえの質問です。
自前で用意しないとできないのであると、弾幕シューティングを作るのは難しそうですね。

ＢＣＤメインの言語でビット演算は不要だろ。

>>353 運用的がBCDメインなだけであって、言語使用はBCDメインとはなっていない

ＢＣＤ、ＢＣＤていうけど何桁まで使えるんだ？

まあCOBOLには他に不満もかなりあると思うのだが
その一つだけで世も末といわんばかりの>>352は
滑稽としか言いようがないし
そんなに長い人生なら自分で調べろよと

できないできないってうるせえよな
できませんじゃなくてやるんだよ
「成さざるを成す」といったら大袈裟だけどな
どいつもこいつも屁理屈だけは一人前だ

>>352
>弾幕シューティングを作るのは難しそうですね

COBOLで弾幕シューティングを！？
何考えてんの？

スプライト機能が優れたハード用に設計されたCOBOLがあるかもしれないじゃないか！！
なければ作ればいいじゃないか！！！
（まあ、さすがにそれはやる意味がわかんないけどね）

COBOLで弾幕シューティングを作るのは当然としても
弾幕シューティングにビット演算が必要な理由がわからない

COBOLこそ最高の言語じゃん

確かに、JAVA、C#なんて中小企業が渇望してるし、戦国時代のように栄枯盛衰を繰り返してる
けどCOBOLのバックアップ企業を考えてみると、バックは銀行業
COBOLは銀行業からずーっと使おり、この銀行は、いざ破産に近づくと国が融資する

国がパックについてる以上、一生食っていける言語と言うわけだ
一方、JAVA、C＃はバックが中小企業
この中小企業は倒産しても国は援助してくれない

言語的優劣ではなく、一生食っていけるかいけないかで言えば、新言語は価値なし
COBOLはジジイになっても仕事がある

>>361 そのかわり、若いやつが入ってこないけどな
つか、COBOLにそまった若いのは下手すりゃ使い回しが効かない

COBOLに洗脳されるとDBの設計ができなくなる

COBOLの不幸
　もともと伝票処理に特化した言語なのに、
　汎用言語に祭り上げられてしまったこと。

数学計算ならFORTRAN使えばいいし、
弾幕シューティングが作りたいならCやVBでもいいんじゃない。
COBOLは事務処理用の言語だから、
大量のデータを一括処理するのは得意だけど
リアルタイムな計算や表示には不向き。

やりたい処理に合わせて言語を選択すればいい。
頭はいいんだろ(w

DB設計できないのは、本人の資質であって、COBOLが悪い訳じゃない。
たまたま昇進出来なくて窓際なおっさんコボラーが目に付くだけ。
他の言語経験者であっても、Indexが効かないテーブル設計や正規化できない奴はたくさんいる。

禿げ上がるほど同意。

そうそう、結局データベースの正規化できていないと
整合性のない無駄なデータが量産されちゃうのよ。

正規化がすべてではないし、プログラミング言語の問題ではないけど、
悩まなくてもよい問題を作ってしまうんだよ。

> データベースの正規化
って、なに？

コボルって花札以外にどんなゲームを作れるの？

>>369
データベースの正規化というよりは、データの正規化とか言ったほうがいいかもねー。
・・・いや、そもそも正規化という意味について問うてるのか？

>>370
伝票とかの事務処理に特化させた言語に何を期待してるんだ。

>>371
> ・・・いや、そもそも正規化という意味について問うてるのか？
そだよ

補足

正規化のイメージがつかめない

こんなのだとすぐわかるんだが...

俺の高校の時に、持ち点100点で厳格に減点法を適用する教師がいた。
結果として、クラス平均が -30点とかになってた。
けど、こんなもん内申書とかに書けるわけがない。
で、この教師は何をやったかと言うと
「標準偏差を計算して各個人の偏差値を成績」
としていた
# 暇な人やな... と思ったけどな

>>369
>>372
基本情報処理試験から出直した方がいいですよ。

基本情報の参考書読むと、第三正規形がデータベースの管理に適していると書かれている。
だけど、システムで処理させる時に毎回Joinや副問い合わせするのもウザい。
頻繁に使われる項目を残した設計できるかが腕の見せ所だと思う。

非正規化は設計よりプロジェクト管理のセンスが必要
思い付きでやるとバグの温床になる

JOINはRDBMSいいところだからな。
記録として残すべき項目は残しておきつつ、データは最適化した状態にするてなところだよね

>>373
簡単に書くとこうなるか。
細かい項目の有無は指摘しないで（w

［正規化無し］↓
クラス、出席番号、名前、科目、テスト番号（中間、期末、小テスト）、最高点、最低点、平均点、取得点、偏差値

［第三正規化］↓
{学生テーブル（マスタ）}
クラス*、出席番号*、名前

{テスト結果テーブル（トラン）}
科目*、テスト番号*、最高点、最低点、平均点

{個人テスト結果テーブル（トラン）}
クラス*、出席番号*、科目*、テスト番号*、取得点、偏差値

>>378
［正規化無し］は［第一正規形］かもしれない。
{テスト結果テーブル（トラン）}と偏差値は、{個人テスト結果テーブル（トラン）}
をグループ化すれば、計算できるから人によっては不要かも。
状況に応じて作ると考えてください。

まぁ正規化しすぎると、プログラミングが難しくなるのと
パフォーマンス上ネックになる場合もあるのも事実

かといって、正規化の意味も分からずに似たようなテーブルを乱発するやつもいるからな
頭の中を一回整理して、テーブル構成を見直して、良い設計を心がけようというところかな。

>>380
> 正規化の意味も分からずに似たようなテーブルを乱発するやつもいるからな
やっと意味わかった
ありがとう

テーブル設計がミスってると、
バグの温床で問題が何年たっても修復できないシステムができあがるから。
特にプライマリーキーがミスってるとどうしようもない。
プライマリーキーの選択をミスってる香具師にはテーブル設計させないことだな。

あと、せっかく制約機能があるのにゆるゆるでテーブルを作ったがために
ニッチもさっちもいかないケースも多いと思う。

もうこうなると、システム作り直すか地味にデータ正規化していくしかなくなる。

>>374
373をみれば明らかなんだが, 彼は正規化と言う言葉が何を意味しているのかを聞いてる

正規化ってオカーズの全否定だよな。

PIC X(65535) OCCURS 65535.
コンパイラによるだろうけど、
もっと取れるだろうね。
PIC X(100000) OCCURS 100000くらいに設定したらコンパイルエラー出るかな
限界はどのくらいだろ
今現役離れてるから試せないな

というか、SQLってプログラマーを否定してるだろ
全否定とは言わないが

NoSQLという流れもあるがの。

not only sql

流れはあるけど主流にはなりそうもない

NoSQLが主流になるか判断できないけど、SQLの直書きを避けたり、Joinや副問い合わせをせずにプログラムのロジックでデータを取得するのが主流になりつつある。

ハイバネとかはもう一定の地位を築きつつあるよなあ。
そういえば、COBOLにはその手のマッパーとかないの？

通常のデータIOは、ファイル上のレコード＝プログラム上のデータレイアウトだから
マッピングの必要さえ無い。
RDMの場合はORMも考えられなくはないが、COBOLの場合埋め込みＳＱＬが基本だしなぁ。

RDBMSはプログラムから独立していることに意味があるから。
かといって現代のオブジェクト指向と相性が良いかと言ったらそれほど親和性が高くない。（インピーダンスミスマッチ）

>>390
オブジェクト指向前提なら、そのほうがわかりやすいからね。

でもSQLなら一発なJOINまみれの処理を
いちいちORMに適合する形式に直す作業って本末転倒だよな

>>394
システムが動いていて性能に問題がなければ、そのままがいいと思う。
DBをサーバーごとに分散させて、
処理を改善したいなら
JOINを止める方向で改善した方がいい。

>>394
まぁそうなんだけど、オブジェクト指向の場合はユニットテスト、カバレッジ測定ができるからね。
作りこみはその分大変だけど、積み木のようにモデルを作り上げて、
ユニットテストをミッチリ作ればプログラムの完全性を自動で検証できるわけだ。

それとガチガチにテストを作ることで変更に対する影響範囲もすぐわかるというメリットがある。
旧来のテスト方式も必要だけど、より厳格にテストが可能なところが良い点だね。

誰かROSCOEのコマンド教えてー

>>396
今時１から新たなシステム作る案件があれば、な。

>>396
> ユニットテスト、カバレッジ測定
オブジェクト指向でなくてもできるわけだが

複雑なSQLになる場合とかって
ストアドプロシージャなりPL/SQLなり、DB側でコード組んだほうが効率的じゃね?

NetCOBOLから.Netに移行する、とかいう案件が最近耳にはいった。
絶対やりたくないでござる!!

PL/SQLのロジックをAP側に持ってくると、
通信が発生してそれだけで遅くなる事は間違いないし、
ヘタするとネットワーク負荷が上がって、全然関係ない
別の処理が失敗して原因究明まで３日徹夜とか。

>>401
だろうね。せめてレイヤーは合わせるべき。

チャップリンが映画で言ってたじゃないか！

｢血は嫌いだが、流れてる｣

処理部はCOBOLでインターフェース部分が.NETは割りと見る。
それかJavaだったりも
やっぱりレガシーを完全に置き換えるのはコストがな

COBOLのコードは仕様を知ってる団塊世代が抜け切らないうちに置き換えとかないと
触れない・変えられないシステムになる可能性が…

とかいいつつ今期の新人の80%がCOBOLのプロジェクトに投入されるわが社の明日はどっちだ

妙に延命策とって、自爆したいんじゃないの？
臆病もんはCOBOL使うのかね？

>>406
まあ、既存置き換えなんてしたら億じゃすまねーからな…

置き換えできないように作ってあるんだろな（作った人もわかってないと）

誰でも出来るとか思ってるうちは億じゃすまんだろうねえ

みずほと郵貯のATM事故を受けて、他の銀行もどんどんシステムを入れ替えている
現実を知らないのか

当然新しく使う言語はJava一択

COBOLは減る一方だぞ

COBOLマンセーが去年騒いでたけど、現実をやっと見たか
相変わらず、マンパワーで乗り切るつもりなんかね？

>>410
俺の知る範囲だと置き換えなんて少数派
んでもって置き換え要員はCOBOL+置き換え言語+業務経験なんて無茶な要求してるから
まったく人が集まらん状況

まあ柔らかいとこ以前に汎用機をリプレースするのに何年かかることやら
+それを決断できる金と人がそろうか
COBOL使ってる会社は今そんな金動かせないしな状況的に

>>412
脳内お花畑ですか
この前のGW3連休でどれだけ多くのATMが止まってて「システム入れ替え」
をしてたか調べてみな

>>413
ATMとその通信関係でCOBOLが動いてるわけ無いだろw
バックエンドでNetCOBOLとかCORBA経由とかはあるけど少数派

ROM/DOSで動いてたATMなら見たことある。

>>404
見栄えと操作性を上げただけｗｗｗ
外観だけリフォームするのと同じで中身は古いままｗｗｗ

まあ、仕方ないけどね、フェーズの一番目ということでｗｗｗ

>>415
俺もあるｗｗｗ

見た目と操作性は、ユーザーサイドから見ると、重要な要素でしょ。
むしろ、中身の言語が何かなんて重要じゃない。

お客さんの予算が小額なら、外見がWebで内部処理がレガシーのままは、良い選択肢だと思う。

Rubyバカにしてる子ってさ
変数に＄ついてる言語触ってるって事だよね

いちいちSHIFT＋４キーおして ＄ 打ちまくってる感触はどう？


ゴミって知ってる？

アスキーコードが１〜２５６のほうがおかしーし

>>417
コボラーの減少 + 効率いい言語

あとDBがらみとかも地味に
枯れてるのはいいんだけど遅い!!

最近のCOBOL知らないけどUNICODEとかUTF8対応どうなってるの？
そこさえ切り抜けたらまだまだCOBOLは生きていける

.Net COBOL linux版をどぞ、
ttp://software.fujitsu.com/jp/cobol/environment/linux.html#develop

>>421
汎用機にそんなものいるのかよ

>>423
COBOL2002で規格化されとるがな

募集案件みたかんじ外資系が中心…らしい

汎用機でもLinuxを動かすのじゃ〜

COBOLでWindows service 作るにはどうしたらよいですか？

ＮＥＴ　COBOLのフリーダウンロードができるなら広まるし
意味あるけどね。

結局、ＪＡＶＡ環境とか．ＮＥＴ環境に対応していて
なおかつ無料のダウンロードできないと。

Ｒｕｂｙもある程度広まったのは、フリーだから。
Ｃは基本フリーの環境だし。

馬鹿にしてる子ってさ

ｗ

>>428

それは君の頭の中では何かと話がつながっているのだな？

>>421
無理

>>410
ハローワークで社員募集を見てみろ
ほとんどCOBOL言語OKの会社を見なくなったぞ
ほとんどVB,C,JAVAと書いている。
あとは、アンドロイド経験者とか

>>427
COBOLのフリーダウンロードなんて聞いた事ないなぁ

FreeCOBOL.iNFO〜フリーのWindows用COBOLコンパイラまとめ〜
http://labs.netbata.com/cobol/

NET対応でFREEってのはさすがに無いw

フリーのCOBOL なんて、需要ないわな。

>>430
ハローワークはしらんがCOBOLの案件はまだ大量にあるぞ

あと求人なら言語じゃなくて生保とか金融とか業種で募集してんじゃね
生保でプログラマの中途って100%コボラーだし

うーん案件０ではないけど「大量に」っていうのは、、、ないなあ。あったら紹介してほしいくらいだｗ
生保はJavaとVB.Netが多いかな。少なくともうちで聞こえてくる感じでは。

この速さなら言える
















ぬるぽがっ

>>436
セルフサービス？ごくろうさん

でもゆくゆくはコボルはなくなる運命だろうなあ
だいだい新規の開発ではもう使わないし

金融・生保でも最近はコボル以外の開発環境選ぶとこが普通にふえてるし

COBOLで開発すると苦情の山だぞ
本当にした事あるのか

特にバッチ処理での苦情が凄いぞ

�@データ登録ボタンを押す
�A本当に登録されているかを検索ボタンで検索する
�B該当なし
�C10分後に再度、検索をする。照合可能。

これだぞ！！
�Bは、バッチ処理があるからコンピュータがフル稼働していても
処理が間に合わない事が原因。
客からは、本当に登録されているかを確認しないといけないから
登録して10分も待たされる　という文句が来ていた。

>>438
客の所では、10分待たないといけないから
帰宅が遅れるという苦情が来る。

開発では、さらにひどい事になっている。
同じホストコンピュータを使っていたから
テストでプログラムを起動してプログラムが終了するまでに
1〜2時間かかっていた時があったよ（1プログラムで）

COBOLって
ホストコンピュータをテスト用と本番用に分けているんだけど

テスト用でテストをすると本番側に途中でデータが飛ぶ事があるんだよね
COBOLって怖いよね

>>439
テストもかなり時間がかかるから
テスト内容って本番からテスト側にデータを持ってきて
変更前と変更後を実行して結果を比較するだけなんだよね

じゃないと期限までに終わる事が不可能になる

COBOLでの開発の時に
客が新規店舗を増やそうとした。

その時の変更本数100本以上。
午後8時くらいが一番ホストコンピュータが遅くてね
テストに1〜2くらい普通にかかる
（実は、内緒にしていたけど1回テストで動かしていたら
処理が遅くて4時間くらいかかった事があった）

COBOLは、他の言語に比べてステップ数（行数）が
長くなりやすすぎる。
オンライン処理のプログラムを紙に出力したら
A3より1まわり小さい紙で厚さ1cmくらいの量に
なったよ。1つのプログラムだけで

COBOLでいうオンライン処理というのは
画面がある物
画面からボタンをおしたり値を入力したりする画面の事

つーか、処理に時間が掛かるのは、利用する言語にかかわらず
・コンピューターが遅いのか
・プログラマがヘボなのか
・その両方か
の3つしか原因を思いつかないのだが、気のせいだろうか？

・ユーザーが想定外または不適切な運用ないし適用を行っている
もあると思うよ
この場合、COBOLでは特に最適な形への仕様変更の難しさが問題になるだろうね

>>446
それは、大いにあると思う

あと、予算不足も影響しているんですよ
電算室では、テストでもDBへの検索でエラーになると
ピーピーと音が鳴るらしくうるさいらしい。
で、SQL文などはなるべく難しくしないように心がけている

追加でCOBOLの問題点として日付型がない。
boolean型（true/false）は、1：true　2：false　でなんとなく
可能だが日付型はプログラムでちまちまと書くしかないのが現状。
チェックボックスやラジオボタンもboolean型と同じやり方しかないと思う。

COBOLが他の言語と違うのは
関数が無い事なんですよ

だから他の言語をしようと思ったら絶対に
迷う

メーカー独自の関数は以前のところであった。
COBOLで関数？ってかなり違和感はあったけどね w

COBOLって動的処理ができるの？

動的処理の例
　・履歴書などで職歴を書くとき、ハローワークなどの
　　国は書ける企業の個数が決まっているが、リクナビは
　　決まっていない。これは、企業の追加ボタンを押すと
　　入力する箇所が出てきて決定ボタンを押せば良い。
　　つまり、会社の個数に上限は無い。このような作り方。

>>450
なんで、出来ないと思うのか、逆に聞きたい...

>>451
ごめん。ハローワークのは、利用者側の出来ていた。

上限無く追加して画面で一覧表示した後に右側に変更ボタンを追加など
ボタンは、プログラム上で作成して追加するしかない
もちろん、プログラムも

しかし、COBOLはできない。
コンボボックスなどもCOBOLでは、不可能。
（企業に売る物は、作成できない。どうしても逐次、管理者が
変更作業をしないといけない。）

理由
　COBOLの変数が固定の為。

無駄という事を考えると
実は、COBOLは無駄が多い。（メモリの無駄）
逆にVB、C、JAVAの方が無駄が少ない。
参考：サン・マイクロシステムズのJAVAの資格

仮に銀行がCOBOLを今でも使っていたなら
システムが止まりまくっている

COBOLは、変数をプログラムの処理より前に全て宣言しないといけない。
つまり、宣言した変数はプログラムが終了するまで常に保持している。

VB、C、JAVAの場合
　たとえば、for文（ループ）の中で宣言した変数は
　その中のみ使用可能となっている。for文が終了
　した時点でプログラムがその変数を保持していない。

>>452
100万件一覧表示して変更ボタンで処理させるつもりかい？

>>455
何を言っている？
---------------------------------------------
例えば、得意先が追加されるとしよう。

登録ボタンで追加しました。
しかし、その後得意先の会社名が変更されました。

システムも得意先名を変更しないといけません。
検索をして絞り込みましょう。
　検索結果を以下とする
　001　●●●●株式会社　　変更ボタン
　002　△△△△株式会社　　変更ボタン
　003　株式会社□□□□　　変更ボタン

上記のようにしました。該当する会社の社名を
変更したいので変更ボタンを押す。
この時、該当件数分だけ変更ボタンをプログラム上で
作成していますよね。

>>456
表示したいデータを無限に画面に表示する気か？
>>455は、たぶん、表示させる件数なんて、固定数で十分で、それ以上は別ページにすれば良いじゃんって言いたいんだぜ

あと、件数が判らなくて、動的に配列を用意する事も出来ないなら
配列そのものを使う必要が無いんじゃないかな？
つーか、件数が判らない時点で、動的だろうと静的だろうと配列にデータを保管する事自体がメモリの無駄な予感

>>457
表示する件数は、固定数で十分、残りは別ページ
確かにその通り。だけど最後のページは、表示件数が途中で
終わるよね

>件数が判らない時点で、動的だろうと静的だろうと配列にデータを保管する事自体がメモリの無駄な予感

これは、COBOLではなくメーカーが独自に関数を用意するという話が
あったので件数が分かった物として話をしていた。

>>458
途中で終わってなんか不都合はあるのかい？

仮に、画面に表示する件数位の配列を動的に確保するならば、配列を確保するコストの方が高く付くと思うの

>>459
不都合はない

>>453
言語によってメモリの使い方に違いはあるのは分かるけど
今どきメモリの無駄を気にする必要は無いんじゃね。

C++のプログラマがメモリの使い方を気にするのはわかる
でもなんでコボラーが？

最近のCOBOLって動的配列とか出来たりするの？

先週、とある現場に27人受け入れとかあってうけた

ついでに今年の新人は特にやめるのが早いとかいう噂聞いた
あと残業代を要求してきてウザいとか。払えよ、とはいえない俺はチキンです。

昔、COBOLの仕事をしていたが
ずいぶん前に作られたプログラムは
GOTO文ばっかり使っているんだよね

中には、プログラムソースがなくなってしまって
classファイルしか残っていないという声も聞かれた。

さすがにやばいんじゃないの

>>465
そりゃまた、昔の話だなぁ...
20年位前には、既にGOTO禁止になってたからなぁ

>454
それはGCが起動した結果です。VBでもJAVAでもGCが動作していない場合は残りますよ。

>438,439
それはCOBOLが問題なのではなくシステム構築した側の問題でしょう。
オンライン時にバッチなど動かさないし、普通オンラインならRDBでコミットした時点で反映されるでしょう。
そんなものCOBOLが原因ではないでしょうよ。

>>467
GCは、自動的に起動されるでしょう。
今のJAVAやVBでは、自動的に起動されるから残る可能性は0のはず。

そういえばRubyってプログラム言語が最近
出来ているよね
あれは、事務処理用として利用できないのですか

言語にはそれぞれ向き不向きってのがあるとおもうんだが、どうしてRubyを事務処理用に使おうと思ってんだか

>452
基本的にCOBOLはGUIを記述する言語ではないですよ。ロジックですよ。
UIを設計する場合は、今ならWebAppが主であろうからHTMLやJavaScript等で生成するものが多く、
直接COBOLでGUIを生成する訳がないです。Webベースでなくても同じです。
イベントを捕捉する場合でもAppServerが介在しているはずです。
で、仮にボタンを追加するコードがあったとしても、そんなもの屁でもないでしょう。

＞468
スコープから抜けるタイミングでGCは必ず実行されるとは限らないです。Javaではそうです。
GCが実行されないと変数はメモリに残ります。Rubyでも不定ですよね。概ねスクリプト言語はそうです。
C/C++コンパイラは自ら管理する必要があります。管理をミスすればメモリーリークとなります。そうさせない為のGCです。
他の言語でもコンパイラによってはグローバル変数はプロセスが消滅するまで残り実行中に消えません。

>>471 と >>472
この説明は、少し矛盾していない？

COBOLはGUIを記述する言語ではなくロジックなんだよね
つまり、GUI（ボタンやラベル、テキストボックスなど）を追加する
コードがあったとしても屁でもない　とはどういう事？

スコープから抜けるタイミングでガベレージが必ず実行されるとは
限らない。他の言語でもコンパイラによってはグローバル変数は　って
スコープの中にある時点でグローバル変数ではないのでは？

>>470
Prologなどはある見方ではビジネス処理に向いている。
ビジネスで使われている論理や用語を直接プログラミングに利用できるから。
SQLに似ているいが、はるかに柔軟で強力。
しかし、別の見方では向いていない。数千万回の繰り返しを安定して、高速に
実行することは困難。
これは、極端な例だけど、Rubyにしたって、ビジネス処理向きな部分はあるし、
うまく使えば面白いという領域はあると思う。

>473>コードがあったとしても屁でもない　とはどういう事？
別の言語とシステムを使って幾らでも記述出来るだろという事。

>スコープの中にある時点でグローバル変数ではないのでは？
cobolに詳しい訳ではないが、基本的にcobolのリソースはワーキングセットで管理していて、それはメインフレームの概念。
普通のPCの世界と違い、端末やメモリなどのリソースは実行時に割り当てられる。
確かメインフレームではI/O,入出力,リソースは抽象化されていて、実行時にジョブコントローラ(JCL)が割り当てするはず。
だからグローバル変数とか言っている時点でおかしい。リソース管理はJCLで行なうのでは？
コードはバイナリ単体というよりシステムから呼び出されるサブルーチンみたいなもの。

>>466
ラベル break の無い言語で goto 禁止はさすがに頭を疑う。

>>476
何十年も以前からGOTO文を使用しないのが常識となっているのに
GOTO文が無いと組めないと言っている時点でプログラマとしての資質を疑う・・・。

そういや最近中途入社してきた元C++プログラマにCobolの開発を担当させているが
完全にパニクってお手上げ状態になってたっけ・・・。

最近のPGはまともに設計すら出来ないコーダーまがいの人間ばかりだと聞いていたけど
ここまでレベルが落ちていたとは・・・。

>最近のPGはまともに設計すら出来ないコーダーまがいの人間ばかりだと聞いていたけど

昔からそういう香具師は少なからず一定数存在した

それに気がつかなかったなんていい職場だよな

>>476
俺が構造化プログラミングを学んだ主なプログラム言語はCOBOLだよ
つーか、もともとCOBOLの為に出てきたのが構造化プログラミングだと記憶しているんだが

GOTO文って使うまいと思えば、案外使わずに済んじゃう物なんだよね

>>475
なるほど
COBOLのプログラムを一つのメソッドと考えると言う事ですね

昔、書かれていたプログラムは
GOTO文ばかり使われていた。
これをGOTO文を使用しないようにプログラムを変更するのは
意外と難しいよね。
一体、１つのプログラムで何回GOTO文で飛ばしているんだ？
と思っていた。

ふと思ったんだけど
COBOLは、昔からあるでしょ？
同じ言語をずっと使うのはやはり無理があるよね

言い換えれば
竪穴住居（縄文時代）を当時、設計をきちんとして立てていても
現在は、使っていないよね

まあそりゃそうだが
アセンブラれべるじゃ気にならない

>>483
一言でアセンブラって言っても沢山あるよね
だってコンピュータの基礎だもん

COBOLは、FORTRAN（1954年考案：1956年マニュアル：1957年誕生）と
ほとんど同時期となっているけど半世紀経過しているけど大丈夫なの

>>473
Javaでも、web系のシステムを作る時はHTMLを使うじゃん。
COBOLもHTML使えば同じような画面ができるよってことじゃないか。

但し、何十年と使ってるような古いシステムだと
メインフレームやオフコンだし
データの渡し方とかいろいろ面倒くさそう。

>>481
意外とじゃなくて、超難しい。
条件が複雑に絡み合って何が何だか分からないし
コメントも適切に挿入されていない。
30年以上前に作られたgoto文嵐の1万行越えのプログラムをちょこっとだけ修正するだけでも触りたくない。

>>482
お前、アセンブラとかFORTRANとかdisってるの？
基礎から勉強し直してこいや。

>>487
アセンブラはdisって言ってないよ

>>480
pascalじゃねえの、構造化やってたの
cobolはその後、騒いでたような？

>>487
昔は今よりワケワカでやってたからじゃねえの
ほんとにわかってる人は今も昔もほんのひとにぎりだからね

>>485
JCLをServlet代わりとしてCOBOLのプログラムをメソッドと仮定して
関数は、メーカー独自のを採用すると言う事を前提とする

という事でOK？

>>486
昔は、PERFORM文がないのでGOTO文を使うしかなかったらしい

>>487
自分の低スキルが問題でCOBOLすらまともに扱えないのに
それを認めたくないので言語にせいにしているだけじゃないの?

最近のプログラマは「クラスが無ければ組めません(ｷﾘ」とか平気に言い放つからなぁ。

去年java使いの派遣にCOBOLで配列に格納されている文字列のソートを行う処理のコードを書いてもらったら
「クラスやライブラリが無いのにどうやって組めというんですか! だからCOBOLはダメなんですよ。」とかのたまわっていた。

COBOLにはプロシージャもあるしローカル変数も定義可能のような気が。
日付型変数もあるよ。ていうかCOBOLのデータ定義はCのprintf()の書式指定や、
正規表現のように文字と記号で定義するはずなので、変数型定義の自由度は高いはず。
日付型も自由に作れると思う。

>>438、はオンラインをバッチで構築した最悪のシステムなのでは？
基本的にオンラインとバッチは違うはず。オンラインは昔のTelnet/Webサーバ
のようなもの(トランザクションモニタと呼んだかな)が担当して、バッチはバックエンドだ。
昔の新幹線の座席予約システムもそうだし、BASIC言語が開発されたDTSSというシステムも、
フロントエンドに端末処理とインタプリタ、バックエンドに汎用機のバッチ機という二台構成で作られていて、
今に至る基本的な原型となってる。新幹線のシステムはオンライン端末用のサーバは当時一から自作したはず。
そういったミドルウエアは今でも売ってるのではないかな。

最近の開発ではよく判らないエラーやバクは「仕様です。」で済ませられるからある意味楽かもなw

>>495
関数は、自分達で作れと言う事ですね

>>491
JCLをServlet代わりとしてCOBOLのプログラムをメソッドと仮定する

関数みたいな物は、自分達で勝手に作って

という事らしい

と言う事は、

COBOLもうまく利用すればインターネットショッピング

とかも作れそうですね

帳票にグラフを印刷する場合でも関数を自分達で勝手に

作れば出来ますね！

>>438
オンライン画面からの登録ボタン処理をバッチ処理じゃなくて
オンライン画面の内部処理で済ませることもできる。
でも、それだと画面が固まって使えなくなる可能性があるから
バッチ処理へ負荷を分散させたんだろうよ。
それはシステム自体に問題があるだけで、COBOLが原因ではない。
他の言語でシステムが作られていたとしても処理が遅かっただろうよ。

業務が回らないと言うのなら
高い金出して改善して貰えばいいんじゃね？

今までのを聞いて
やはりプログラムは、発想（アイディア）が一番重要だと
感じるな
今までの頭にある概念をなくして別の方法を模索するというやり方は
なかなかできないからね

>>499
開発言語を用途によって使い分けられない頭の弱い方ですか？

特定の言語をディスったりマンセーするような人間はプログラマーとして無能。

>>502
何を言っているんだい？

Javaでは、インターネットショッピングが作れるだろう？
企業用のシステムもSwing機能を使えば作る事ができる。
アプレット機能でゲームも作成できる。

COBOLも企業用のシステムが作れるのなら
やり方しだいでインターネットショッピングやゲームが作れる
と考えて妥当でしょう。

JCLをServlet代わりにするのは、ちょっと無理があるんじゃないかな。
セッション管理とか、いろいろ難しそう。

>>472
なんかGCに対する理解が怪しい
変数はスコープ抜けたタイミングで解放されるよ
同時に、参照していたインスタンスが到達不可能になり次回GCで回収対象になる
が、スコープ内であっても変数に別の参照を代入したり、複数の変数から参照されていたり、また世代別GCなどもあるので、
GCとスコープはあまり関係無いです

>>504はひょっとしてコボラー？
職場のおっさん糞コボラーも同じような事言ってたわｗ

画面とか、ユーザーインターフェイスをHTMLやJava
夜間バッチなどの内部処理をCOBOLとか、適材適所で作ればいい。
どうして、一つの言語で全てこなそうとするんかな。

>>508
夜間バッチなどの内部処理をCOBOLとか、適材適所で作ればいい

あんただよ
分かってないのは　夜間バッチが無いんだよ

>>509の「夜間バッチが無い」って、大量のデータ処理する時とか、どうしてんだろ？
画面入力の都度、１件１件処理できるほど小規模なシステムなら十分だけど
何万件とか大規模のデータ処理させなきゃいけない時はバッチ処理なければ無理じゃないか。

>>510
基本情報処理試験に出てくる
データベースの正規化の勉強はした？
確かSQL文の問題も出題されていたよね？

�@画面入力をして登録ボタンを押す
�Aサーバー側でSQL文（Insert文）を起動させる
これだけでしょ。

帳票印字は、
SQL文（Select文）で2つや3つ以上のテーブルを
複合検索をするからデータを一気に取得できる。
あとは、印字するだけ

想定しているシステムが>>510と>>511で全然違うから、そら話通じんよ。
汎用機屋がバッチといえば、今のBIに相当する部分だ。
それを指して>>509が「(普通インターネットショッピングやゲームで)夜間バッチがない」と言っているが、
まぁトランザクションまとめてバッチしか知らない人には伝わるはずもなく。

>>512

510が言っているバッチというのは、
毎日、同じ時間に起動されるバッチ処理の事ですよね
帳票を出力させるためにテーブルを読み込んで並び替えてマッチング
をする。そして、帳票出力用のテーブルに格納して帳票を印字する。
だから、売上の帳票は、次の日にしか分からない。

>>511 稼働中のシステムでそんなトロイことできるのか。
みずほがキャパオーバーで事故ったろ。
データ件数から処理時間とか予測出来るのか？
作ったけど、翌日営業開始まで間に合いませんとか言い出す気か？

いわゆるオープン系の基幹システムのサーバーで使用するOSっなんだろ。
やっばWindows？((((；ﾟДﾟ)))))))

ここまでの話をまとめると

「COBOL不要論を唱えるプログラマが一番不要」

って事でいいのかな？

>>515
WindowsやLinuxが主だったはず

今の企業システムの基幹OSは、WindowsやLinuxだよ
Javaで携帯サイトを作る時は、Linuxを使う時が多いからVisualStudio
が使えないでしょ　だからeclipseという物がある。

今のスーパーコンピュータは、PS3とかWiiだよ（←ゲーム機）

>>509

夜間バッチが無いって、、、、
月次や半期、年次処理とかないのか？
楽な業務だな

>>516
たかが言語レベルでどうのこうの言っている時点でPGとして終わっている。
つまりただの土方…。

>>520
そっか

「COBOL不要論を唱える奴は人として不要」

って事か！

>>519
月毎の売上や半期毎の売上、年間売上の表って
SQL文のwhere句で期間を指定してやればいいだけの話でしょ

合計ならSQL文でSUMを使えばいいだけの話だしね

ほんと楽な業務なんだなー
裏山

sumだけで済むって随分と単純なバッチじゃないか?

つか>>522はどうも学校か何かでSQLを習ったばかりで嬉しくてしょうがないという感じだな･･･。
既にオワコン状態のJAVAを引き合いに出す辺り、見ていて微笑ましいw

そういや最近すっかりJAVAの案件聞かなくなったね。

確かにJAVAが出始めた頃はCOBOLより先に消えるだろうと言われていたけど
本当にCOBOLより先に消えてしまったとは…。

いまは何の言語の案件に変わったのかな

最近はC#が増え始めたかな・・・

>>525
JavaはJavaでありまくる

金融でも基幹系以外はJava(+Oracle)か.Net(+SQL Server)てのが
仕事としてはありまくるしヒトも足りないけど、金融系はコネがないと仕事がまわってこない

基幹系は基幹系でコボラー定年退職で人材不足が深刻らしい
今日も19人アサイン、だけど月40とかわけわかんねー話をタバコ部屋で聞いた

>>526
COBOLのはずだが

>>522
５千万件のデータがあったとして、４千万件目のデータでこけたらもう一回最初っからやり直しですかね。

>>524
522は、一言もJAVAって言ってないよ

よくコボラーが定年退職してCOBOL開発者の人材不足だという話を耳にするけど
COBOLってそんなに難しい言語か?　
以前COBOLは未経験でCOBOLの開発にまわされたことがあるけどそんなに難しい言語じゃなかったぞ。

確かに仕様書等、まともなドキュメントがないからメンテが困難という話ならわかるけど
それは別にCOBOLに限った話じゃないと思うし…。

COBOLは、確か英文と同じ感覚だったと思う。

まぁプログラマーといってもビンキリだし…。
それこそ既存のクラスやフレームワークを積み木のように組み合わせるようなコーディングしか
出来ない人間にはcobolでも難しいだろうな。

COBOLのプログラムは、実際の処理は、後半の50％しかない。
前半は、データ定義とか誰が作成したかとかプログラム名とかを
書く場所になっている。
つまり、10000行あったとしたら実際の処理の部分は5000行位という
事になる

>>534
そんなプロフェッショナルなあなたに耳寄り情報
金融の直受けなら120(残業代含まず)とかありまっせ

金融系は一見おいしそうだけど関わると地獄を見るぞ…

Javaやドットネットに慣れた人間からすると
COBOLのあの一筆書きみたいな処理ロジックがガッツリ重くて、どうにも解析しにくいと感じる。
どこでどのタイミングで変数変わってんだよ〜とかｗ
慣れもあるとは思うけど。

>>532
COBOLは、完全に英語が得意な人はCOBOLも得意なので
人材不足にはなるはずが無いと思う。
英語が得意=COBOLが得意　と考えていい

>>538
たかだか数千〜1万ステップ程度のコードなら一般的なPGとしての整理能力、論理的思考があればどうって事ないと思う。
それを追えないなんてプログラマーとしての資質に疑問を感じる。

>>532
ビジネス視点の話になるけど、一次受け二次受けで新人投入できる会社はコネクションを持ってる
逆にコネの無い会社は新人を投入できないので中途採用のを適当に放り込む
業務経験を積む場がないので新人が育たない
団塊が定年　<= いまここ

今は新人は月0とかじゃないと受け入れてくれない会社がほとんどだす

>>541
なんでPGに業務経験なんて必要なの?
そんなもんよりAPIのリファレンスとか一つでも頭に叩き込む方が何倍も重要だろ。

業務経験なら
たまに富士通さんなどがしている研修（有料）を
受講させればいいのでは　COBOLではないけどJAVAでのホームページ
作成ならしていたよ

>>542
COBOLに実はAPIが無い

>>544
APIが無いのにどうやってコーディングしろと？
まさか自前でロジックを考えろとでも？

COBOLには、関数自体が無いのでもちろんAPI関数も無い

確かデータベースからデータを取得するプログラム
取得したデータを並べ替えるプログラム
マッチング処理をするプログラム
帳票に印字するプログラムなど個別にプログラムを作っていたよ

>>545
前に誰かが書いていたけど
自前でそれくらいロジックを考えろと言っていた

もちろん日付型もないのでそんなもの自分で作れと
言っていたと思う

>>540
それにかける労力がもったいないって話だよ。
火をおこすのにマッチでするか棒をゴリゴリ磨るかって
同じ火なら楽なほうがいい
「これくらいできて当然」ってわざわざ面倒なことはしたくねえってのｗ

>>545
というか、例えば「新しい金融商品用のプログラム作ってくれ」
とかきたときにAPIもフレームワークもないだろ、全部一から作っていくしかないのよ
そんときに損保なり生保なりの業務経験があるとないのじゃ大違いなわけですのよ

>>547
なんか昔のCやアセンブラみたいだな…
そんな低級言語なんか使いたくないわ。

業務経験なんてプログラムが組めないやつがよく吐くセリフだよな。

バカでもできるが
この業界の合言葉
中身ボロボロって落ちがつく？

>>549
営業さんは、何をやっているの

>>551
業務経験という言葉自体が業界用語的なので
いいかえると領域知識かな (英語だとよくdomain knowledgeて出てくるやつ)

大雑把に例えると、「あるプログラミング言語でフラクタル図形を書く」という案件がある場合
プログラミング言語にどれだけ精通していても、フラクタル図形を描くための数学の知識がないと
一行もプログラム書けないでしょ

上記の場合の「フラクタル図形を描くための数学知識」が領域知識
まあ、おっしゃるとおり、逆に「プログラムの知識」もないと結局のところ目的達成できないんだけどさw

>>553
ゴルフ

>フラクタル図形を描く
cobolで出来るのかいな？

>>554
打ち合わせ　という言葉があるよね
客先に出向いて
お客さん「こういうのを作って欲しいのですが」
資料を作ってきて「こういう感じのものですか」

コレの事だよね

実際DBとかSQLとかメンバとかばかりプログラミングしてると馬鹿になる

COBOL自体の言語習得は簡単なんだよ。
でも、プログラム実行するための設定とか、
COBOL以外で他に覚えなきゃならんことがあるでしょ。
他の言語もDB周りとか覚えたりするから同じなんだが
厄介なのは、そこらへんを独学で覚えようにも、資料が市販されてないし、試すこともできないところかな。

>習得は簡単
それだけで済むとでも

>>559
COBOL自体の習得は、確かに簡単。
他のに比べて関数がない。日付型などもない。
あるのは文字列型と数値型のみ。
COBOLでメソッドと呼ばれている物は変数を渡さないし値を返さない。
nullとかもない。a.lengthとかもない。インスタンスとかも無い。

だから英文みたいな物なんです。

習得が簡単に出来たから、動くものが簡単に作れるとでも
俺はcobolに将来性がないと感じたから、別方面に言った口だけどね

brainf*ckみたいなもんだな

帳票系の言語だから、基本的に簡単なことしかできない
簡単な反面、難しいことをしようとすると悩むことになる

>>554
> 大雑把に例えると、「あるプログラミング言語でフラクタル図形を書く」という案件がある場合
> プログラミング言語にどれだけ精通していても、フラクタル図形を描くための数学の知識がないと
> 一行もプログラム書けないでしょ
>
どうやってフラクタル図形を描くかを仕様にまとめるのはSEの仕事でしょ?
PGはSEが描いた仕様をコード化するだけだからそういった知識は必要ないと思うが。

仮にPGにそこまでの知識を必要というならSEの仕事が無くなるじゃんw
SEなんてプログラムが組めない下衆がやる仕事なんだ〜せめて仕様ぐらいは書いてもらわないと…w

>>564
> PGはSEが描いた仕様をコード化するだけだからそういった知識は必要ないと思うが。

そういう人間はプログラマーとは言わない。いわゆるコーダー。

>>565
昔は知らないけど今のプログラマーは仕様なんて書かないよ。自分も設計書なんて書いたことないし。
今関わっているプロジェクトも実際どういったシステムなのか詳しく知らないし、PGの立場からするとそんなもん知ったことじゃない。

なんでもかんでも一人でこなす時代は終わったんだよ。

>>564
SEって仕様書を作った後に一緒にプログラムを組むよね

つかPGとコーダーの違いって何?

>>564
仕様には、フローチャートまで書いてないよ
それは、PGが自分で考えてプログラムを組む事になる

>>569
自分の環境じゃ未だに仕様書にフローチャートまで書いているよ。
PGはそれにしたがってコード化するのが仕事。
そうやって完全分業化することによってクオリティの向上を図っているんじゃないの?

つかフローチャートが書けないSEなんて存在価値があるのか?

>>570
フローチャートまであるとオブジェクト指向言語の場合、
逆にクオリティが落ちそうなんだが

つかSEは、仕様書を書き終わったらPGにプログラムを
任せて何をしているの

>>566
設計書を書かないで、よく他人と開発できるよな。
いろいろマズイんじゃないですか？

>>566
今関わっているプロジェクトも実際どういったシステムなのか詳しく知らないし

これは、SEが糞だった時点で誰も気づかずに終了する
ミスがあった時点で誰も気づかない

>>573
仕様ミスはSEの責任、PGには一切責任はないだろ、常識的に考えて…。

>>572
出来るだけ他人と関わりたくないからPGの道を選んだのに、
なんでわざわざ他人の事なんて考えなければならないんだよ。

そんなこと言っているからいつまで経っても給料上がらないかさもなきゃ肩叩かれるんだよ。
他人と関わりたくないなら、PGなんかやめてとっとと独立すればいいだろうにそれもできないんだろ。

>>574
それが客に通用する訳がないだろう

客から見ればSEだろうがPGだろうがお前の会社の事だろう
としか見られないよ

既に、COBOLとはなんら関係ない部分で、COBOL不要論が話されております...

つーかさ、特定言語が不要なんじゃなく、特定言語を不要と思う奴らが不要だよね

そもそもなんでCOBOLには、関数が実装されていないの

現在、使用されているのなら関数が実装されていてもおかしくないと
思うのだが

バカでも出来るお手軽言語とやる方もやらせる方も思ってるから
個人的には下等向けのお遊び言語にしか見えんな
環境は今でも馬鹿高なんかね

環境は、相当高いと聞いている。
確か汎用機を買う金が無いからレンタルしていた。
（毎月、レンタル料が発生）

>>579
スタック的な系ではないからだろう。

汎用機は、自分が聞いたのでは数千万円。
前にCOBOLをした時は、汎用機が2台あった。
毎月別々のメーカーにレンタル料が発生。
その内、1台はWindowsに置き換え完了。
但し、Windowsでの環境もオーダーメイド。
回線もNTTさんが来てかなり凄い事になっていた。
（恐らく最高金額の品物だけを買っている状態）

数千万…？えらく安いな。まぁ機械単体だけならそうか。
普通、環境一式揃えるので1億を最安値として5億未満てところだろう。

誰得？状態なんだ

>>585
　＞583の場合、NTTさんが唯一得をしたという事だと思う。

>>583
汎用機からWindowsへリプレースって物凄く勇気があるなｗ

>>587
汎用機の部品を製造しなくなったとかでは
後で困る。8インチフロッピーとかこの会社ではじめて見たよ

基本的に汎用機は物を売るのではなくリースが基本でしょう。歴史的に汎用機は買うのではなくリースで商売してきたはずです。
ハードは所有するものではない。サービス業のようなもので、それはメインフレーム型の大型UNIX機も同じです。
ですからクラウド等はかつての汎用機時代に戻るような印象を持つ人も居ますね。
大型UNIXメインフレーム機や汎用機の実機を買うと考える人はおかしいです。
汎用機を買うのは合理的でない。間違ったビジネスモデルだと思います。

汎用機に縛り付けられてるだけのような

>>589
リース会社に買ってもらっているのではなくて？

業務経験の無い奴らばっかりで笑たw

仕様書の代わりにテストケース。

>>587
某証券システム会社　ユニシスからPCへ移行しようとしていたよ
順調に行ったかどうかまでは知らんけど

自分の会社はオフコン→Windowsと来て現在はLinuxに落ち着いている。

>>594
PCへ移行ですか
自分もユニシスさんや日立さんのを見たことあるけど
あれは、使いづらいですよね。
はっきり言って使っているとムカムカくるんですよね。
任天堂さんのファミコンのような性能があると万歳なのですが。。。
見込めないですよね

COBOLで使用している汎用機は、WindowsのMS-DOSより
かなり使いづらい。
スクロールバーもないしマウスも使えない。
動画は、もちろん　画像処理なんてもってのほか

某金融機関だが、ホストのデータを十数分程度のラグでOracleに落とし込むなんて話があったな。
結果、規模が大幅に縮小された上、主キーもなくFiller部までカラムに落とし込まれた、奇怪なテーブルが出来ただけだった。
あれも2億位したんじゃないかと。

>>598
インデックスの生成がもっともコストが掛るから主キーは外したということか。

>>599
インデックスの生成（OracleMasterBronzeより）

create index 索引名　ON　表名　（列名,[列名]...）
[tablespace 表領域名]
[記憶領域管理パラメータ]

これの事

表の作成方法です
create table 表名 (列名　データ型[default　式],
[列名　データ型]...)
　[tablespace 表領域名]
　[記憶領域管理パラメータ]

　create table 従業員
(従業員No Number(4) constraint PK_従業員　primary key,
従業員名　varchar2(10),
担当　varchar2(9)
);

>>601
Primary Key を指定すると自動的にインデックスを生成するのが普通ではないかな。

小企業だけど、富士通のASPってやつをMS SQL Serverにしたよ。
業者に見積もり取ったら5000万円とか言われたらしい。
そこで俺が手取り15万円で雇われて、2年かけてリプレースした。
今までオフコンをお守りしてた爺さんと二人で作業した。
爺さんは70才でなんとか退職できたけど、俺の昇給は二年で5000円。
かなり凹んだ。

額面以前にそういうこと出来る人がほとんどいないという現実がある

二年かあ。お疲れ様
リアル知人だったら酒奢って色々聞き出したい所だw
しかし昇給可哀想。上の反応気になるな
削れて当然のコストをやっと削れた、くらいにしか思ってないのかねえ

COBOLなどがよく利用するメインフレーム（汎用機）は、
メーカーにもよるけどSQLServerやDB2などではなく、
PS3のように内蔵されているものを使う場合がある。
それは、SQL文が使えなくてread文やwrite文で読み込んだり
書き込んだりする。
確か主キーでのみ検索ができる。それ以外は、上から順に読み込まなくては
ならない。曖昧検索などは、テーブルを上から順に読み込んでいき
マッチングさせるしかない

>>606
内蔵されているデータベースみたいな物は構造も変わっているよね

例えば
社員番号3桁　社員名10桁　住所20桁　とすると
001ああ　ああここから住所
002氏名　名前住所

上のように格納されている　

>>606
汎用機は使ったことが無いので知らないが、富士通のオフコンは随分以前からSQLは使えていたぞ。
実際職場でもCOBOLで直接SQL流し込んだり、ODBC、JDBC経由でPCサーバーからもアクセスしている。

>>608
富士通は、使えていたのですね
日立とユニシスは、使えなかったです

たしかIBMもSQLを使えたような･･･

>>609
日立もユニシスもＲＤＢはあるし、SQL使えるよ。
>>606が関わったシステムがたまたまSQLを使ってなかっただけ。

>>611
自分が関わったシステムでは、確か日立さんのは
READMとかREADGという物を使って読み込んでいました。
READM・・・主キーで検索
READG・・・主キーで検索で検索後、順読み込み　だったと思う。

ユニシスさんの時は普通にREADでした。

>>568
プログラマは、命令の長所や短所を理解して、最適なプログラムを組める人。
コーダーは、設計書の内容を単純にプログラムに置き換えるだけの人。

コーダーが作ったプログラムは、ソースが汚い、無駄が多い、処理が遅い、適切なコメントがない。

リレーショナルなくそぼったいファイルシステムだけ
触れてた輩がうんちゃらいっとんのかこのスレ
引退ご隠居の書き込みじゃなきゃ定年間近やろな、がむばれ

>>613
＞>>568
＞プログラマは、命令の長所や短所を理解して、最適なプログラムを組める人。
ないない
最適化とか(何かが)勝手にやってくれて当然のもんだと思ってるよ、最近のPG
コーダーの基準は曖昧。HTMLとCSSならやれます、ってのはとりあえず間違いなくオペレーター同格でコーダーと呼んでるが他社では通用しなかったりする
割とこういう奴らの方がCOBOLに向けやすいけど

>>615
COBOLは、何も知らない方が向けやすい。
HTMLとCSSならやれます。の人は、別の言語をさせたがいいと思う。

HTMLとCSS
って、プログラム系の言語か？

>>617
プログラム系の言語ではないが
COBOLには、向かないと思う。

自社でコーダーって呼ばれてる人間が他社で通用するもんか。
そんな奴、JavaやC++できるとか言われてもお断りだよ。

コーダーが作ったプログラムは、ソースが汚い、無駄が多い、処理が遅い、適切なコメントがない。

これだよね
確かに他社では、通用しないな

いい加減な教育してるから当然でしょ
それ以上になることそれ以下になること許されない状況の人たちだから

>>603
1000万円のボーナスが欲しいよね。

最近は詳細設計すら出来ないPG気取りのコーダーが多すぎて困る…

>>623
最早、本気で教育していないと云うことですか？
それより、JAVAやC++のプログラマ呼んできたとしても、そう簡単には、
COBOLを前提にした業務ソフトの詳細設計なんてできません。
このスレ的にはこのことが問題なのではないだろうか。

>>623
なんでPGが詳細設計なんてしなくちゃいけないんだ?
詳細設計なんて下等な仕事はプログラムが組めない奴隷SEにやらせればいいんだよ…パカか?お前?

だいたいSEなんてプログラムが組めない、もしくは技術の進歩についていけなくなった人間がやる仕事だし・・・

コミュ能力や設計なんかよりAPIを覚える人間の方が優秀なのは世間の常識

>>625
基本情報を勉強しているか
プログラミングより設計の方が上流工程じゃないか

>>625
適切なコメントがない

COBOLは、プログラムが長くなるからよくコボラーは
コメントは書くなというよね
----------
無駄も多いよね

多少、無駄が多くても変更箇所がすぐに分かるようにしているよね
もちろん処理も遅くなる

そういえばCOBOLは、
a.lengthという事ができないから繰り返し処理の時
変数にわざと配列の要素数を格納していて
その回数分ループさせるよね

例えば、店舗数を並列に固定で入れておいて
その店舗数まで繰り返させる。
店舗が多くなるとその店舗数を入力している
変数の初期値を+1する。

>>629
例えば、店舗数を並列に固定で入れておいて

並列ではなく変数です

詳細設計は、SEの仕事。
プログラミングをしていって理解してから設計をはじめて
任せる事ができる。
家をつくる時も土台がしっかりしていないと家が
傾くでしょ。家の下の土が水分を多く含んでいる状態で
家なんて建てないでしょ

>>629
COBOLの基本は固定長でa.lengthのような、可変長で扱おうとする企みは
一般に排除されるw

COBOL・・・固定長が基本
VB、C、JAVA・・・可変長が基本

ここで全てがおかしくなる

そういえば前の職場でCOBOLをしていたのだが
設計書が半端じゃない量だった。

まず、データベースのテーブル設計が
5cmバインダー4冊にいっぱい。
中から1枚取り出してコピーした後にまた入れなおそうとすると
ものすごく力が要る。

プログラムの詳細設計所
バインダー数十個分。誰だよ　こんなに処理を長くしたやつは

>>629
動的な配列の確保なんてしないだろうから、a.lengthなんて必要ないんじゃない？

ヒープなんていう不効率なことが許されなかった時代に設計された言語。

>>635
そうですね。そうすると
485さんの言っているような事は、無理という事でOK？

でも、どうやってメーカーは、COBOLでは動的な配列を確保しないのに
企業のシステムを組み込めるんでしょう？
日立さんや富士通さん、ユニシスさんは上の資料を見る限りできている
のでしょ
他の言語で画面を作って

>>637
なんでそういう結論になるのだろう。
COBOLでHTMLファイルを書きだすのは簡単。
そのHTMLファイルをどうやって送出してもらえればいいのか、
という事だけだと思う。

送出して貰えばいいか、 だね。

>>638
送り出して貰えばいいか　か
javaではHTMLのファイルを受け取っているよね
tomcatというソフトを使って
IBMでは、tomcatというソフトの代わりに自社ソフトを
使っているよね　それと同じ事？

じゃあ、送り出してもらったファイルの内容（HTML）
に例えば好きなデザートにチェックを入れてね（複数回答可）
としてチェックボックスをつけたらどうかな
□りんご
□みかん
□ぶどう
□すいか
□メロン

>>640
文字列の解析は必要でしょう。ボタン名-1="on"&ボタン名-2="on" のような長い文字列で
戻ってくるのだから。COBOLは固定長ではあるが、REC定義でREDEFINES句とOCCURS句の
組合せで、1バイトずつ拾いながらの構文解析はどうしてもいる。Perlだと解析まで全部やって
くれるだろうけど、COBOLでやるなら自分でやる。

>>640
予め余裕を持って配列を定義する。
どれだけの配列が必要かは初期設計時に慎重に見積もられる。

>>641
ボタン名-1="on"&ボタン名-2="on" のような長い文字列で
戻ってくるのだから。

tomcatでは、チェックボックスにチェックが入っていない物はnull
になる。がこの場合、tomcatに該当するソフトをon/offにすれば
いいのか

なんでCOBOLでHTMLを作るという話になるのか判らん。
画面作るならKQCAMS（富士通ならか）とかで画面作ってオンラインでのやり取りできるし
HTMLでとかならjava連携でとかじゃないのか

>>643
そもそも、サーバーから送られてくる生のデータは配列ではなく文字列だから、動的配列が使えるかどうかは関係ないって事じゃないの？
仮に、配列で送られて来るにしても、画面設計の段階で、何がどれだけ必要かは判ってるはずだから問題ないと思うけどね

>>644
COBOLでだってHTMLファイルくらい書けるし、ブラウザからの情報も
解析しようと思えばできる。でも、何か間を処理する良いサブシステムが
あるならそれに任せればよい。
元の話はCOBOLで得られる情報をGUIで表示したり、そこから情報を得る
にはどうするかということだから、可能な限りCOBOLだけでやるとしたら、
HTMLファイルで表示させるのが簡単なのではないかという話を書いた。

動的な配列を必要な場面がよく分からん。
そんなの使わなくてもシステム作れるだろ。
あれば便利なレベルの問題。

COBOLでHTML連携は、やはり難しいと思う。

コンボボックスで県や市を選択する時、
HTMLの画面上で県を選択したらその県に該当する市のみを
市のコンボボックスで選択可能にしなければならない

この場合、県や市はデータベースのテーブルに登録されている
のを読み込んで表示させている。市町村合併などは
このテーブルを変更するだけ。

この場合、OCCURS句の数値が分からない。

COBOL2002以降の規格を使えば、COBOLでWEB系システムを構築することは可能だよ。

>>649
そんな規格あるのか。
それでは、皆さんがシステムを乗り換えるまで待つということで。

>>648
この話はわかったのだけど、最後の
この場合、OCCURS句の数値が分からない。　とはどういう意味？

NetCOBOLでASPサイトを作るなんて話もあるけど需要あんのかねｗ
そもそもWinサーバでCOBOL動かすメリットがわからんちん。
まあマイグレついでに他システムとの連携を考えてどうのこうの
って話かもしれないけど。

>>651
いらないですね　OCCURSは

>>645
では、データベースから取得したデータを
HTMLでチェックボックスで複数選択可能にしたらどうなの

>>654
checkbox名とデータベースから取得したタプルの対応は、一時的にランダムファイルに
書いておくのが簡単なんじゃないかな。checkbox-nのnがランダムファイルの相対位置に
なるようにすればよい。

>>652
そもそもWinサーバでCOBOL動かすメリットがわからんちん

それは、客の中に自分の子会社にシステムを任せていたら
COBOLでずっとシステムが動いている。VBにシステムを
変えるとお金が大量に必要になる。そんな馬鹿な事をするはずが無い。
で、他の会社の画面を見ると自分の所と画面が違う。何故だ？
他の所では、画面でマウスが使えるぞ！チェックボックスやラジオボタンも
ある。コンボボックスもだ。何故なんだ？

ちなみにチェックボックスとは
□いちご　□りんご　□メロン　□すいか
↑上から複数選択

ラジオボタンとは
○1月　○2月　○3月　○4月
↑上から1つ選択

チェックボックスもラジオボタンも、基本的に設計時にデータ量がわかるから問題ない
check-box1=1&check-box1=2&check-box1=5
って形の文字データとして送信されてくるだけだもの

<textarea>タグみたいな、文字入力系の方が深刻な問題な気がするんだが...
入力される文字の数は設計段階では不明だし...

>>652
COBOLは、データ量が分からないだと
じゃあ、店舗ごとの売上一覧表を作成する為には
店舗を追加/削除したら毎回システムの変更を頼まないといけないのか

なんという事だ！！

それは設計事項

>>659
他の言語はそんな行き当たりばったりな開発が当たり前なの?

>行き当たりばったり
曖昧な要求でどこまで出来るのって話になるのかな？

>>660
いや、
COBOLでは印刷プレビューとか無いし
印刷の帳票レイアウトもプログラムで
　　　○○一覧
　東京本社　12,345円
という感じにファイルを作っている。
それを印字する。改ページなどもVBのやり方とは違う。
よって、何行目で改ページをするというのをプログラム上で
変数として持たせている。（プログラム毎に）

若い人も、アドホックなやり方も少しは知っておいたほうがいい。

>>661
BASICなんかは、行き当たりばったりで開発する方が都合良いけどね

開発が行き当たりばったり、か。
そのようにしか取れないとしたら
他の言語がなぜできたか理解できんだろうな

>行き当たりばったり
出来る人はそんな感じでやってるかも
未熟だと泥沼だろうけどね、慣れるまでは

>>667
確かに出来る人間だといいが世の中ほとんどの現場が泥沼化に陥っているのが現実…。

>泥沼化に陥っている
なんか、ウハウハ状態になれる人もいるみたいだけどね

行き当たりばったりというか……Scrumとかの話じゃないのかよ。

アドホックなやり方 という表現はよく使われるものなのかな。

COBOLでもマウス使えるしチェックボックスもあればオプションボタンもあるだろ。

無知って怖いな。

>>663
COBOLの帳票印刷なんてそんなに難しいか?
つか帳票プログラムなんてCOBOLを始めたばかりの初心者がまず始めに作成するプログラムだそ。
いわゆる"Hello World!!"レベル…。

>>663
随分昔に作成した帳票プログラムなんて罫線まで自前で描いていたぜw
印字データをWirteした後、罫線データをAfter 0でオーバーレイ･･･、ハッキリ言って面倒くさいw

>>672
汎用機でつくっている。
汎用機では、マウスも使えないしスクロールバーもない。
上の画面はF9、下の画面はF10をスクロールバーの代わりに押してる

で、現場で使っている画面を見るとチェックボックスもオプションボタン
も無い。ボタンも無い。確か画面に　「処理：　　」となっている所で
該当する数字を入力してEnter

確かラジオボタンの代わりに
1：男　2：女　という入力方法を採用していたよ

>>676
それ、JIS規格。

iPad上の3270/5250エミュレータなら[1:男　2:女]の部分がボタン化されて(略、、、
と思ったら実際にiPad用の端末エミュレータが存在するのね。
汎用機のダム端末もiPadで進化ですね。

>>678
いや、それ以前に日本のメーカーは
企業用システムのOSを作りきらないでしょう。

まさかWindows95の衝撃を知らないとか。。。
ゲームにおけるドラゴンクエスト、アニメにおける機動戦士ガンダムや
宇宙戦艦ヤマトや新世紀エヴァンゲリオン、システム関係における
Windows95は実はかなり大きい波だったんですよ。

Windows95が出てきたので世界中でスーパーコンピュータのOSの
開発が停止を余儀なくされたんですよ

COBOLてか昔のプログラミング言語は記憶力を要求されるよね。
記憶力に頼るプログラミング言語はＮＧなんだと思う。
階層的に組み立てる方法が現代的でいいんだよ

>>680
>スーパーコンピュータのOSの開発が停止を余儀なくされたんですよ
ソースあるかい？

>>681
ごめん。ちょっと分かりにくい。
昔：COBOL　・・・上から順に処理が流れていく。英文を読む感覚でOK！
今：VB、C、JAVA・・・処理があっちに行ったりこっちに着たりする。
　　感覚としては、
　　1.じゃあ、プログラムをつくろうか
　　2.あっちに使えそうなメソッドがある。
　　3.このメソッドの後にあっちのメソッドに処理を渡せば
　　　終わるんじゃないか？
　　4.おっ　1つプログラムが終わった！良かった。良かった。

>>682
ソースは、無いけど。新聞に出まくっていたよ
撤退の文字が

>>683
構造化をGOTOみたいに言うなw
まあでもJavaとかでイベント駆動が多いコードはおっしゃる通りですが

>>680
近年のスパコンの開発撤退のこと言ってるなら、COBOLもWindowsも関係なくね。
Windows95は確かに革新的ではあったけど。

そもそもWindowsってスパコン目的には使ってないよね。

>>687
シェア１％ある。
デスクトップPCにおけるLinuxのシェアより大きい。

>>683
その程度のカオスなら、人間でも何とかできる...
GOTOのカオスは、神様でもどうにもならない...

>>680と>>688の話を総合すると
Windows系スパコンのシェアが1%ぐらいしかないのに、
Windows95をきっかけに世界中でスーパーコンピュータのOSの開発が停止を余儀なくされたって
ずいぶん無理がある話に聞こえる。

>>686
いやWindows95の台等でプログラムの開発における
価値観が相当変わっている筈

それに今のスパコンOSの開発は、全てゲーム機に移行されている

>>691
> それに今のスパコンOSの開発は、全てゲーム機に移行されている
全てではなく一部で試験的に開発しているだけ、またハードはゲーム機でも使用するOSはLinux。

どうも話を無理やり捏造してWinマンセーしているようだけど、Windowsをそこまで持ち上げて何がしたいんだ?

>>674
何十年も前は帳票イメージをAAみたいに文字を組み合わせて作ってたんだよな。
文字と文字の間にわずかな空白が入ってしまい、見栄えが悪かった。

今ならFDLとかで枠を作れるけど、正直表現の幅が狭い。
データだけ渡してAccessとかで帳票イメージ作った方が良い場合もある。

>>692
いま時Windows以外のOSを使うなんてただの異端だろうに…

>>693
あれ、Accessってプログラムとして利用するのではなく
データベースとして利用する場合がほとんどだと聞いたけど

今まで数多くのプロジェクトに関わってきたがWindows以外のOSなんて一度も動いている物は見たこと無いのだけど。

>>696
携帯電話の着メロサイトは、Windowsでも出来るが
Linuxを使う時がある

>>695
プログラムじゃなか。レポート（帳票）印刷。

>>696は学生さん？
Windows以外のOSを一つも触ったこと無いんかな。

>>698
いや、VisualBasicでプログラムを作って（帳票印刷を含む）
データベースとしてAccessやSQLServer、Oracle、MySQL,DB2、PostgreSQL
を使う場合が多いという事

>>695
Accessの主機能の一つにレポート作成機能がある。

データベースはなんにしろフロントエンドはAccess でっていうのがメンテは楽。

>>700
Access 単体でレポート(帳票)印刷機能があるんですよ。
Access のデータから直で出力できる。
使い方は帳票アプリの Crystal Reports のような感じ。

開発者は Access を DB の代わりに使うことが多いから、レポート出力機能を知らなくても無理はない。

>>703
AccessやExcelで使うマクロというのは、VBAとも呼ばれています。
VBAとは、「VisualBasic　for　Application」の略です。
つまり、AccessとはVisualBasicが内蔵されている状態です。
で、VisualBasicにも帳票作成機能(CrystalReports)が備わっている。

Access はどっかのデータベースサーバから SQL とか使って画面に表示するソ
フトとして使われているイメージがある。

>>703
わかってるな
>>704
わかってないだろ

前もどっかの板にスレ立てて、画面がWindowsだから銀行のシステムはWindows(ｷﾘｯ って言ってる学生さんがいたよ。

>>707
確かにシステムは、WindowsじゃなくてLinuxの可能性もある

>>707
Microsoftのは、ボタンなどのイメージが統一されている。
JavaのボタンとVisualBasicのボタンでは見た目が違う。

で、VisualStudioはWindowsしか動作しない。

ATMは、Windows の可能性大。

>>710
ATMがWindowsだったらサーバーもWindowsじゃないの?
行員が端末として使っているPCもWindowsだったし

今の世の中、業務で使用するOSはWindowsしか存在していないだろ…。
つかWindows以外のOSが稼動している企業システムなんて一度も見たことが無い。

メインフレームが未だに使用されているなんて既に都市伝説だし、Linuxなんて一部のキモオタしか塚ワンだろうし。

お花畑理論炸裂

シンクライアントでならみかけるが、それ意外だとあまり

しつこく釣り続けてるね
まあ今時ならWinでシステム構築も悪くないけんだろうけどさ。レガシーasp系の保守はごめんだが

いまどきの汎用機はOSがLinuxだったりする。

>>716
メインフレームどころか世界の基幹システムはほとんどがWindowsなんだか・・・。
ソース
　↓
東京証券取引所の基幹システムとして稼動するWindows
ttp://itpro.nikkeibp.co.jp/article/NEWS/20090609/331590/?SS=imgview&FD=-654674548

HPCでもダントツのパフォーマンスをたたき出すWindows
ttp://cloud.watch.impress.co.jp/docs/interview/20101224_416025.html

Windows上で稼動するメインフレーム
ttp://wsmgr.jp.brothersoft.com/screenshot-50450.html

BankVision
百五銀行（2007年5月7日稼働）
十八銀行（2009年1月4日稼働）
筑邦銀行（2010年1月4日稼働）
紀陽銀行（2010年5月4日稼働）
佐賀銀行（2010年5月5日稼働）
山梨中央銀行（2011年1月3日稼働）
鹿児島銀行（2011年5月6日稼動）

OpenE'ARK
2008年 福岡銀行
2010年 肥後銀行
2011年1月 山陰合同銀行
2011年5月 みちのく銀行など

釣りのつもりなんでしょうが
それにしても痛いな

Winが頑張ってるのはみんな分かってるよ
「ほとんど」って言っちゃうと語弊あるでしょ
今はまだ、大手銀行からf社やn社のメインフレームがリプレースされる日を待つ段階ですし。そんな日が来るのかどうかは誰にもわからんけど

>>717
Windows上で稼動するメインフレーム

コレだ！！
自分が見たことあるのは、画像の上部分の
クリップボードに　とかオプションボタンは
見たこと無いけどまさしくこのタイプ　
日立さんやユニシスさんのは、このようなもの！！

「ほとんどがwindows」とかもうね...

http://top500.org/stats/list/37/os

>>717
しかしまぁ、揃いもそろってつぶれかけの銀行が並んでるな

大手のWindows勘定系は新生さんくらいじゃない？

パッチ当てただけで（十分な検証もせずにパッチ当てるバカSEはいないと信じたいが）
ブルースクリーン出まくるようなOSなんか基幹系勘定系に使いたくないものだな

しかし通常運用で何時突然落ちるかわからんWindowsを勘定系でよく採用するよなぁ…。
デフォルトで時限爆弾仕掛けられているようなもんだぞ。

しかも2003Server以降中途半端に安定しているために安心しきった時に突然落ちるトラップ付きw

流石に今はそれは無いｗ　全く０ってわけじゃないけど。
たしかにNT時代は落ちまくったがWin2008は安定してるよ。

つってもミッションクリティカルな基幹系に使いたいかってーと、それはないけど。
周りを固める比較的小規模なサブシステムに使う分には何の問題もないレベルだと思う。

>>720
それ 富士通製WSMGRエミュレータの画面キャプチャが容易にできるソフトだってよ。
ttp://www.vector.co.jp/soft/win95/art/se238870.html

Windows上でエミュレータを動かしているだけ。
汎用機にアクセスしていて、汎用機本体を実際に動かしてるのは別OSだよ。

Windows Serverで落ちたこと無いけどなあ。どういう時に落ちたの？

>>727
汎用機自体は、Windowsじゃないんですよね

確か開発画面も客側の画面もあのようになっていた。
今もなっている筈。やはりCOBOLは、どこでもあのような画面なんだね

>>717
必死だなwww

2008Server以降流石に落ちるということは無いけど連続稼動させると時々一時的に応答が無くなったり挙動不審になったりする。
週毎に定期的にサーバーを再起動するようにしてから起こらなくなったけど。

>>717
ユニシス販売員乙

お前ら、Windowsの話をしているのか、それともCOBOLの話をしているのかどちらだ

WindowsServerの場合、定期的に発生するパッチを当てないと色々と危険だし、
パッチを当てるとOSの挙動が変わったり、最悪今まで動作していたアプリが動かなくなったりするからWin鯖は嫌い・・・。

>>729
>やはりCOBOLは、どこでもあのような画面なんだね

COBOLは…というより汎用機やオフコンは通常はあんな画面。
以前メーカーは忘れたが、オフコン上でJAVAを走らせていたところがあったが
ブラウザ経由だと一般的なGUI画面だったが、端末エミュ経由だと>>717と同じような画面だった…。

>>717


>Windows上で稼動するメインフレーム

この表現、めちゃ抵抗があるんだが。単なるエミュレータだろ？

>>735
汎用機やオフコンは通常あんな画面

汎用機からWindowsに置き換えてブラウザ経由
にしても客側の画面は>>717と同じような
画面だった。COBOL

>>737
汎用機だとCOBOLだけじゃなく、CやPL/1やFortranもみな>>717の画面だった

>>736
だからあれはWindowsマシンで汎用機のOSを動作されるためのエミュレーターじゃないの?

>>738
Cobolを汎用機からWindowsに置き換えました。
開発画面は、eclipseのような画面になりました。
しかし、実行画面は元のままでした。客側を含む。

>>739
違う。
OSを汎用機からWindowsServerに置き換えました。
だから前は、Windowsマシンで汎用機のOSを起動させていたけど
その後、WindowsでWindowsのOSを起動させるようにした。
しかし、客側の画面は、変化無し

>>739
前の会社では汎用機を2台(別ﾒｰｶｰ)使用していました。（以下、汎用機A,B）
バッチ処理で汎用機Aから汎用機Bにデータを送っています。
(それぞれ別処理をする。処理を分散させる為)
で、客側から送られてくるデータを処理させる汎用機を
WindowsServerに置き換えました。しかし、客側の画面は変化無し。

実際メインフレームからWinサーバーに移行した企業ってどれだけあるんだろうか…。
2008Serverが安定しているといっても安定性において未だSolarisどころかLinuxにすら及ばないんだし。

それともWinへ置き換え対象になっているシステムはそれ程冗長性を重視しないシステムなのかな。

最近急にスレ伸びてるのはなぜなんだぜ

コボラーの法則
Oracleのテーブル設計をすると予備領域のカラムがついてくる
varchar2を使ってくれない

>>743
少なくても三洋信販さんのシステムは、1から新規作成。

>>743
元がメインフレーム使ってるような止められないシステムなら
多重化+コールドスタンバイするだろうからOS単体の安定性なんてどうでもよくね
仮想化しちゃってもいいし

>>744
流石にOracleでFiller項目つけることはしないだろ。つか無意味だし…。
varcharはCOBOLでは可変長項目の使用に制限がある為使用しないんじゃないかなぁ。

>>746
クラスタリングってハード故障等の致命的な障害に備えた最後の保険のようなものなのに
そんなにホイホイ使うもんでもないだろw

>>748
確かに昔客先で稼動していたメインフレームがH/Wの故障で落ちたことがあって
マシン自体は冗長化してあったので実業務の運用には全く支障は無かったけど
システム部門の現場やベンダーはそれこそまるで天変地異が起こったかのような大騒ぎになったいたわ

それ以前に、誰もする奴がいなくなるんじゃないの？

前に汎用機からWindowsに置き換えた後でも
新人が全員2ヶ月以内に辞めたよ

COBOLの復活は、見込めないと思うなぁ

だって大手企業が来て大失敗をして終わったよ

>>749
メインフレームは飛んだら、損害賠償が発生するからな。
ピンチだよ。

メインフレームが稼動するようなシステムってモノによっては数分停止しただけで最悪死人が出たりするからなぁ

>>751
流石に近年だと無いかもね。
でも2000Server時代にCOBOLというか、当時のある役員の独断でメインフレームからWindowsへ強行移行したことがあったけど
月に数回トラブルは、挙句に決算月に丸一日止まったりでとてもじゃないけど使い物にならない代物で
結局メインフレームに戻したことがあった。

でWindowsの導入を推進した役員は更迭された後自殺した…。

メモリリークないのはいいとこ

>>754
よくわからないけど、新システムへの移行で全くトラブル無しなんて
ありえなくない？だってコボラーがやるんだぜ？

>>756
Windowsがクソだったか、新システムがクソだったんだろ。

>>756
システム移行に携わったのはメインフレームのベンダーとは全く別のベンダーでVBでの開発がメインだった。

半年前のみずほ銀行のトラブルとか
あれほど大規模の障害が発生したとなると
責任者やリーダーとか大量死するレベルなのかな。

>>757
Windowsがクソなら現在ほとんどWindowsでのシステムだから
皆トラブル続出だろう。

そういえば、前にここから飛び降り自殺をした人がいるとかで
塩をおいている場所があった。

とある大手ベンダーのSEが言っていたけど止まることがゆるされないシステムには絶対にWindowsは使ってはいけないんだと･･･。

>>761
つＲＡＩＤ

RAIDがどうしたの

>>760
数年前だとWindowsのIISサーバーが、
ネットワーク上のPCにコンピュータウィルスをばら撒いて悲惨なことになってたな。
今でも毎月セキュリティホール塞ぐためのパッチあてまくってるだろ。
クソっぷりは今でも健在だろ。

Apacheもこの前盛大なセキュリティホール見つかってただろ…

>>765
CodeRedやニムダと比べたら可愛いもの…。
先日見つかったApacheのセキュリティホールはあくまでサーバー単体のみの被害だけど、
CodeRedやニムダの場合はサーバー、クライアント問わず世界中のネットワークに接続されているWindowsマシンに
ウイルスをばら撒き合っていたからなw

そういや最近、価格COMやトレンドマイクロをはじめ、あちこちのWin+IISのwebサーバーも改ざんされてる事件があったっけ?

ダム端のwin置換えとかとゴッチャにしてるんでないか？
鯖にwinなんて現場として勘弁

うちも俺らの反対押し切って2008R2のシステム入れたけど
原因不明の応答停止に悩まされてたよ。
で、解決策が毎週日曜日の深夜に自動リブートさせるという。
これでトラブルは今のところ起きなくなったけど、サーバとしてどうかと思うね。

自分ところでは問題ないから、自分とこで作ったアプリがリークしてるんだろうね。

毎週はいくらなんでも釣りだろ

>>769
いくらなんでもそれはなにか原因あるぞ

っていうか原因不明なんていってよく金もらえてるなぁ、と素直に感心してしまう

マイクロソフトのサポートデスクですら2008Serverでも可能なら定期的に再起動するようと指示された覚えがある。

>>770
Windowsってメインフレームみたいに異常にリソースを消費するジョブのCPUやメモリのプライオリティを
自動で下げたりとか出来ないの?

>>774
下げたら問題解決するか？

独自系メインフレームはハードウェア制御でも資源管理してるんだから、
汎用OSに過ぎないWindowsに求めるのは若干無理ないんじゃない？
オープン系のLinuxでも資源調整は仮想化単位でしょ

>>775
そもそもそこだなw

そもそも、たかがユーザーアプリによるメモリリークでOSが応答停止したり挙動不審な動作をすること自体
商用OSとして信じられないことなんだが･･･!?

Linuxはメモリ不足に陥ると勝手にプロセスをKillするからな･･･。あれはあれでやめて欲しい。

そのユーザーアプリを管理者権限で動かしてるとかだったら笑うけど
WindowsServerは意識的に定期再起動しなくても、一ヶ月に一回再起動するしな

WindowsUpdate

>>780
業務運用中のサーバーになんの検証も無しにWindowsUpdateを実行するということ?

((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

もしこれが汎用機だったら、たかだか一カ月も連続稼働に耐えられないようじゃ、性能を疑われるわな。

Linuxですら4〜5年無停止で稼動なんてザラなのに･･･。

>>772
原因不明なトラブルはWindowsの仕様ですｗ

>>781
検証ってなにするの？パッチのソースも見れないし、中身全くわからんよ。
実験機で試すの？

>>785
えっ…⁉

>>785
さすがにここは未経験者が質問するスレではないと思うのですがw
まあCOBOLだJavaだとか関係なく、正直なところ担当者それぞれでしょう。
予備システムで真面目にやるか仮想環境で検証するに留めるのかも扱ってる問題によるし、本番データのコピーが可能ならしばらく並行して同じ動作させることもあります。
あとは普通に単体テスト走らせたりオンラインのコマンド一式走らせつつ、上への報告書類をこさえます。
win鯖なら、セキュリティ系アップデート項目の内容を熟読した上で放置することも多々。

むしろお前の方が未経験者臭凄いんだが

>>787
あとは普通に単体テスト走らせたりオンラインのコマンド一式走らせ

オンラインのコマンド一式走らせるの？

汎用機COBOLでテスト自動化できないかな。

>>790
それは、メーカーに言う方がいい

>>790
自動的にテストベクターを生成するプログラムを作れば良いだけの話

>>792
つまり、どういうことだってばよ⁉

>>793
恐らく792が言っているのは
テストをするプログラムが通る全てのパターンのデータを自動的に
作るプログラムを作ればいいんじゃないの　って事だと思う

>自動的に
ここでどの程度か悟ってやれよ

(超)大企業でテストデータをPrologで生成しているところはあるよ。
しかもワークステーションではなく汎用機で。

>>796
それは、プログラムはWindowsで作成しておいて
テストパターンだけ汎用機でProlog言語を用いて作成、印字
までしている　という事？

モノは試しでググってみたら「COBOLUnit」なんてものもあるんだな
ぜんぜん使ったことないし、評価のほども知らんがｗ

>>797
汎用機上のPrologのソースがどこで記述されるのかについては全然知らない。
単純に汎用機上での作業と思ってしまっていたが。英文の論文か雑誌に載って
いた話で、多分日本IBMではないと思う。それで本当のところはわからない。

なんだウソか

最近のプログラマって自分でテストコードやテストデータすら作成できないの!?

テストデータの名前が怪しいお米セシウムさん w

ぶっつけ本番の人たちに何をいまさら

元コメの人がいいたいのはUnitTestフレームワークみたいの
COBOLでもないのかいな? ってハナシだと思う…たぶん

COBOLだとメソッド単位というよりは、アプリケーション単位で
IO部分にASSERTバシバシ書いていくような感じになるのかなあ。>>Testコード

COBOL でもテストケースはいくらでもかけるだろ。

テストってテストデータ送って正常な返答があるかチェックするだけだからなぁ
なんとかUnitが無くても誰でもできるよそりゃ
信号色で色分けしなきゃやだとかアサーションコールでスコアまとめて出さなきゃやだとか本末転倒なのが居たら唾棄して然るべきだと思います

>>807
だけど、順列や組合せを使ってデータを生成することは多いだろ。

>>808
してなかったよ。
前の会社でＣＯＢＯＬを使っていたがテストで組み合わせを
使ってテストデータを作成しようとしたら怒られた

本番データを持ってきてそのまま流せばいいだろう
と言われた。皆、本番データを持ってきてテストデータの中身を
チェックしないまま使っていた。

>>809
スゴい職場だな。
全然テストになってないじゃん。
トラブル出まくって、死人が出そうだ。

うちの職場も最後に本番データでテストはするけどテストデータ無しのテストなんて考えられない…。

>>808
順列や組み合わせを使ってデータ生成したものを
ランダムにシャッフルしてから使うべき

境界値テストもないとか。

けど809のとこみたいな会社案外多いと思う

オレの前の会社がそうだったw

入力データってメッセージだけなのか？
ファイル内容とかDB内容に依存する場合は、わざわざ
その状況を作ってやらないとテスト出来ないだろ。
業務プログラムは外部データを参照しまくるから
単体でテストなんて不可能に等しかったけど。

新しい区分やステータスを追加した場合に
本番のデータ使ってテストしたら、追加や変更を加えた処理に何も引っかからないから、
正しいプログラムかどうか検証できない。

ビッグバンテストで一気に確認してたのかな。

>>816
809のテストは、まだしている方です。
忙しくなると上司の一言で変更前と変更後のプログラムを紙に
出力して目視で大丈夫ならテストＯＫとしていた。

>>817
目視でOKのところだと、設計書や仕様署も作ってないんだろうな。

俺のところも、かろうじて仕様書作ってるけど、内容は一行しかないこともあるし。

ソースが仕様書です(キリ)

>>819
こんな書き方をすると勘違いをされる。

確かにソースが仕様書のようになってしまう。
特にＣＯＢＯＬの場合は、昔からあるので仕様書を見ても
変更が多くもはや仕様書が役目を果たしていないという事が多々ある。

その場合は、仕様書よりも現時点で動いているプログラムを
優先に考えないといけなくなる。

バグも含めて再現してください(キリ)

>>821
バグを含めて再現の意味が分からないのだが

移植の時の条件のことじゃね
バグ前提に動いてる他モジュールに影響が出るからとかコボラーの笑い話にありがちだし

>>823
確かにＣＯＢＯＬを移植する時には
バグも一緒に移植される。

しかし、昔から動いているプログラムで修正ばかりで大きくなりすぎた
から全体の流れが全く見えない。
バグが存在するのか、あったとしてどこに存在するのかも全く
掴めない状態。
1からシステムを作成すれば簡単に終わるが客がそれを拒否したら
どうしようもないからバグ前提で動いてもらうしかない状況。

つまり、バグも含めて移植するしかない。

バグ混みで移植は、Microsoft 、Borland が得意。バグ再現用オプションがあったりする。

>>824
言語のせいでバグが一緒に移植されるという言い方は正しくない。
正常処理かバグか現場の担当者すら分からない状態でシステムが運用されているから
>>821 のような話が出てくる。
引き継ぎや変更管理が正しく行われていなければ、
一から作り直しても、何度でも同じ問題が発生する。

ご高説は納得なんだが、言語には寄るよ
Javaで細かく細かくクラスに切り刻まれた方がきっちり問題のスコープが絞られる
SEがかなりなヘボでも有名どころのフレームワークで統一さえしてくれれば読めるプロジェクトになる
実際に人員総入れ替えしても担当者が苦笑いで済む程度の物になる
末端のコーダーがヘボくても管理できる

COBOLじゃバグ対応用コードを非推奨にして切り分けて進めるとかさえ(やれん事はないが)管理できんよ
少なくとも馬鹿が一人でも混ざり得る現場ではね

現代的なプログラミングは記憶力とトッピなロジックに頼るのではなく、
できるだけ小分けにして、テストもプログラムで自動化しましょうってことだからね
まだまだ、それが理解できない頭が固い馬鹿が多すぎるは事実

>>825
バグ再現オプションって
人為的にバグらせるってことだろうけど
オンにすると何が起きるんですか？

毎日ブルースクリーンはヤダな。

>>828
> 現代的なプログラミングは記憶力とトッピなロジックに頼るのではなく、
> できるだけ小分けにして、テストもプログラムで自動化しましょうってことだからね
> まだまだ、それが理解できない頭が固い馬鹿が多すぎるは事実
>
そして「関数が無いから組めません(ｷﾘｯ」とか「テストツールが無いのでテスト出来ません(ｷﾘッ」とか
真顔で言うプログラムが組めないプログラマが大量生産される…。

>>830
CPUってなんですか?、OSってなんですか?　という人間でもプログラマとして通用する時代だから別にいいんじゃね?

>>826
それは、COBOLを理解していない。
VBは、新しいプログラム言語　それに対して、COBOLは
約半世紀前に作られた古いプログラム言語。
VBやJAVAは、827が書いているようにクラスやメソッド単位で
細かく切り刻まれる。対してCOBOLは、プログラム自体が
大きくなりやすい。
COBOLは、昔からあって幾度と無く修正が繰り返されてきた
事を前提としなければならない。

<<引き継ぎや変更管理が正しく行われていなければ、
一から作り直しても、何度でも同じ問題が発生する。 >>

これは、今修正している会社がシステム構築をした会社では
ない場合（途中からいきなりシステムを渡された場合）
どうしようもない。
そして、修正ばかり繰り返す内に1から新規作成する力も
失われてしまう。

現代のプログラミングはフレームワークやライブラリを組み合わせて構築するのが当たり前なのに
自分でロジックまで考えないといけないなんて時代錯誤だしナンセンス。

ブラックボックス化は、いざというときに困る。

>>826
なら、毎回1から新規作成するしかないですね

現実的に起こっているからそれをどうにかする方が大事
理想論だけでは、どうにもならない

>>833
いや、プログラマはロジック考えないでどうする。

この問題は、ずっと思っていたが
企業のシステムは、定期的に1から新規作成する必要が
ある　と思うがどうだろうか？

COBOLの場合は、PERFORM文が出来る前はGOTO文でしか渡せなかった。
そんな物が今でも動いている方がおかしい。

2000年対応の時にめちゃ古いプログラムを掘り起こして修正しまくったからなぁ、その意見は判るよ。 w
現実問題不可能だろうけどな

>>837
それこそ理想論じゃないか？
どんなに良い言語やパッケージができても
企業側が価値を見出せずにお金を出したがらないんだからさ。

>>839
何か勘違いをしていないか？

もしかして全ての大企業にシステムを運用している会社
もしくは部署が存在していると思ってない。

実際は、ほとんどの会社でそんな会社や部署は存在しないよ

この時点で毎回プログラム修正が起きないから時期が来たら
プログラムを1から作成するという選択肢が生まれる

まさか

店舗を追加/削除するたびにプログラム修正が発生しているとか
馬鹿な考えが起きていないよね

もし、そんな考え方なら1から出直せ！！
まずは、アルバイトから

>>838
2000年問題ってCOBOL特有の問題ですよね

他の一般に使われているプログラム言語は、
日付型が存在するからいちいちプログラムを変更しなくても
2000年問題に対応済み

>>836
今時プログラマーがロジックを考えるだなんてどんだけ非効率なんたよｗ
これだから時代錯誤な老害は困る。

ねぇ
思ったんだけどさ
2000年問題の時にVBに全部システムを置き換えられてない？

>>843
そういうのを世間では土方っていうんだぜ

>>840
お前こそ勘違いしてるぞ。
価値や利益がコストを上回れば、時期なんて待たずに買い換えが起こるんだよ。
コストかけるのに値しないから、いつまでもCOBOLシステムが残り続けてるんだ。

>>843
コーダー乙

>>846
他にCOBOLが残り続けているパターンがある。
それは、システムを任せている会社に技術力がなくなって
したいのにできないパターン。

>>843
中国人やインド人にでも作らせてるのっと

>>842
それはどうかな。データの持ち方は、プログラム言語に依ると
いうよりも、ユーザのデータ観によって決まるから。

>>850
意味が分かりません。

COBOLは、文字型(X)と数値型(9)で変数を定義しますよね。
VBは、Date型(100年1月1日〜9999年12月31日)まで可能。
Date型から年のみ取り出したり月のみ取り出せるので
2011年9月16日と表記したり2011年09月16日と表記も可能。
年号も可能。
JavaもVBと同じ。

どう見ても日付は、COBOLよりVBやJavaの方が扱いやすい。

>>840
>もしかして全ての大企業にシステムを運用している会社
>もしくは部署が存在していると思ってない。
中小ならともかく大企業なら普通にあるだろ。
ないとこ教えてくれや。

>>842
違う。そもそも、COBOLにビット操作命令は無い。
それに、PCでも内蔵時計のハードレベルで問題があったはず。

>>853
JR九州は、関連企業の所長がうちには関連企業にIT企業は
存在しないと言っていた

>>851
設計者が日付は6桁の整数が過去との斉合性から好ましいと考えれば、
どんな言語でも整数にする。やはり文字列で有るべきだと考えれば、
文字列にする。そういった前提で書いたプログラムが一つでもあれば、
どんな言語にも2000年問題は存在した。

>>853
COBOLの日付の定義
PIC X(4)
PIC X(2) value '年'
PIC X(Z9)
PIC X(2) value '月'
PIC X(Z9)
PIC X(2) value '日'

上のようにすると2011年 9月16日と入れることができる。

>>851
はあ？2000年問題勉強してこいや。
当時の日付は、1990/09/16なら0x900916といった形式が多かった。
だいたい、2000年頃のマシン性能でJavaやVBなんて実用性がないだろ。

Javaはともかく、VBは稼働しているプラットフォームが脆弱すぎて話にならない。

>>856
予備知識
　『2000年問題』
　　　年を下2桁でプログラムを組んでしまった為に2000年を1900年と
　　　勘違いをしてしまう問題。

それを踏まえて
　VisualBasic6.0（2000年頃　下は、あるVBのホームページより）
　　　Private Sub Command1_Click()

　　'月末を取得したい日付
　　Dim dat As Date

　　dat = Text1.Text

　　'月末を取得する
　　Dim endDate As Date

　　'1.翌月の月初を求める
　　endDate = Format(DateAdd("m", 1, dat), "yyyy/mm/01")
　　'2.月初の1日前は月末
　　endDate = DateAdd("d", -1, endDate)

　　MsgBox Text1.Text & "の月末は" & endDate & "です"
　　　End Sub

　　　

すまん。
COBOLの日付の定義が間違っていた
COBOLの日付の定義
PIC 9(4).
PIC X(2) value '年'.
PIC Z9 .
PIC X(2) value '月'.
PIC Z9.
PIC X(2) value '日'.

これでお願い

三洋信販さんもSeibelという言語で1からシステムを
システム会社に頼んでいたので関連企業にIT企業は、
存在しないと思う。

>>858
びっくりだな。まあ10年前のお話だから無理もないか。

そもそも、下２桁にしていた理由がメモリ節約のためだ。
FDなら512KB、HDでも2GB前後しかない時代だぞ。
だから言語なんて無関係。
ファイルから読み込んだバイト列0x900916がなんでVBだと
問題なくなるんだ？どんな言語でも1900年を加算して処理していた。

>>852
確か防衛省も1からシステム受注を
確か富士通さんが受けたよ
あれは、全国のIT企業数社でのJavaでの開発だった。

アパレル企業関連もあった。これも海外から生地の発注画面
から全て作成だった。（VisualBasic）

>>861
少し混乱しているな

下2桁は、メモリ節約の為。確かにそうです。
HDでも2GB。それは、Windowsの話。汎用機は、2GBもないのでは？
だからメモリ節約の為に下2桁にしているのでは？

下2桁が90や95は、VisualBasicが1900年代と認識するから

>>853,>>860
自社または関連企業にIT企業が無いからといって、
ITシステムが存在しないってのは、苦しい話だな。

>>863
まあ、極端な話だが、摘要の中に @981231　のように手形決済日が記入されていたとする。
これだけで、どんなプログラム言語であっても、2000年問題は発生してしまったのさ。

>>864
アホ！！
IT企業がないからITシステムが存在しないとは言ってない

システムは、存在する。
事務の人などがシステムの入っているパソコンの電源を入れるだけ
で動くでしょ

>>864
コボラーは、全ての大企業はITの関連企業を持っているのは
常識でそこで使用されているプログラム言語は全てCOBOLだと
思っている。だから、COBOLを知っておけば仕事は山のように
入ると思い込んでいる。だからコボラーは今でも一番世界で
使用されているプログラム言語は、COBOLと言っている。
そして、COBOLは未来永劫なくならないだろうとどこかの
ホームページに書かれてあった。

>>865
摘要の欄にそのように書かれても
そのまま処理されるから2000年問題にはならないよ

日付ではなく文字として認識されるから

>>868
そんなことはない。必要な時に6桁の文字列として切り出され、整列キーの対象にも
成りうるから、立派に2000年問題の対象となる。

>>869
摘要って備考の事でしょう
と言う事は、「@981231」と書かれている所に
「手形決済：98年12月31日」と書いてもおかしくない。
ここで2桁目から切り取るとすると「手形決済：98年12月31日」の
部分がおかしくなる。つまり、この部分は日付として認識
させたらプログラムとしておかしくなる。

>>869
それよりも、単純に6桁の頭2桁が"97"より大きいかなんて記述があったら
一発でだめじゃないか。

>>871
19981231 1998年12月31日　98年12月31日
一言で、「@981231」と言っても書き方がいろいろある。
98年12月31日　このパターンの時、単純に6桁の頭2桁
を見ると一発でアウトとなる

>>872
COBOLではあまりやらないけど、一般のプログラム言語では、@の次から始まり、
スペースが来る前までのN文字の文字列を切り出す、などということは当たり前にやる。
切り出した後でシステムの開発者がここは面倒だから、日付型の項目に変換せずに
文字列で比較してしまおうと考えたら、その途端に2000年問題が発生する。

お前ら、何で今頃2000年問題で揉めてんだ w

>>874
確かに。

うちの会社では、西暦二桁表示と、和暦二桁表示のシステムが並存している。

>>876
それは、VBなら簡単にできますね
西暦2桁（和暦2桁）　←みたいな感覚かな

VBはWindowsでしか使えない時点で問題外。
つかWindowsのサーバーなんて多少落ちても問題ないフロントエンド系しか使い物にならないし…。

VBてかWindows Formsて画期的なんだよな
Webはまだまだインタラクティブな需要に耐えられないだよね

うーん、好み分かれると思う
htmlとJSライブラリのほうが、手軽で小回り効いて好きだな
Windows Formsで作り込むよりはAdobe Flexの方が個人的には楽

24bitのバイナリで持てば47127年くらいは耐えられるのを
YY年MM月DD日のBCDで持ってたから問題なんでしょ?
で， さらには日付の計算まで複雑になると...

でも, 山ほどCOBOLの吐き出したデータがあるから移行
できない．

データの変換ソフト作った方が建設的なんじゃないの???

>>881
何を言っているのかさっぱり分からない

もしかして、VB6の話してる？

>>883
COBOLは、事務系に特化している。
そして、現在事務系の言語はVisualBasicが主流になっている。

だから、COBOLとVisualBasicの比較

題がCOBOL不要論なので
事務系に特化しているCOBOLと現在事務系主流のVBを比較した方が
はやいと思う。

>>884
事務処理系でjavaなら判るがなんで今時VBなんだよw

>>886
いや、今の事務系の主流がVBだから。。。

もちろんjavaでも事務処理ができるよ
Swing機能を使う　OR　VisualJを使う　という事でしょ？

※VisualJは、開発元が承認しておりません。マイクロソフトの独断です。
よって、Windows外での動作は保障外。

VB6の時代は終わった

>>881
COBOLで出来たプログラムを少しでも前にすすめるには
バッチ処理の部分をJAVAに置き換え可能なので
COBOL⇒JAVAにまず置き換えるぐらいしかないよね

Windows上でしか動かないVBなんてホビーならともかく業務じゃ使い物にならんだろ・・・

現在メインフレーム+COBOLで稼動している勘定系、鉄道・電気・水道の社会インフラのシステムが
全てWindows+VBに置き換わったとしたら…

(((((((( ；ﾟДﾟ))))))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙｶﾞﾀｶﾞﾀﾌﾞﾙﾌﾞﾙ

間違いなく文明社会の終焉を迎える…。

今の時代、COBOLからVB6にリプレースする馬鹿はいないだろ。

大アホ技術者が駆逐されて、最底辺がアホに格上げされる。

Paasとかクラウドがもっと普及したら、COBOLもJavaもVBも脂肪だから安心しろ。

Gのやつは、J。

>>894
結局業務ごとの大まかなロジックやモデルは共通化できても
実際使うアプリはゴリゴリつくらなきゃいかんのでpaasだろうがsaasだろうが
かわらん

MSのアジュールはPHPとrubyにも対応してんだっけか…あれJavaは

.NetになってVBは結構復活してきてるぞ
まあ相変わらず大規模にはむかないけど、ちょいアプリとかはVBのほうがむいてる

.net自体は魅力的だし期待もしているんだが、実質Windowsでしか稼動しないというのがどうも…。
Windowsというプラットフォーム自体1980年代の汎用機以下の安定性だし、
陳腐化が激しすぎて現在稼動しているシステムが10年どころか5年使用できるかどうかも怪しいもんだから
フロントエンド系ならともかく、基幹システムとしては使い物にならないと思う。

このスレでちょいアプリが俎上に上がるとは
でも.netならぶっちゃけC#でも何でもいいからなあ。ますますVBである必要ないと思うんだけど

VBはMSとしては終息させたい製品でしょう。C#に移ってくれたらと。
と云う訳で、少なくともこれからプログラマを増やす気はしないツールだな。

>>899
> VBはMSとしては終息させたい製品でしょう。C#に移ってくれたらと。
MSの都合で短期間に次々と開発言語を変えられるのもたまったもんじゃないわな。
その都度システムを焼き直ししないといけないかと思うとぞっとする…。
まぁITベンダーにとってはいつまでもユーザーから金を搾り取れるので美味しいかもしれないけどw

VB4でさえ、あと4年サポートする。ご苦労なこった。

8年だった。

>>897
monoがあるじゃん

自分の会社で古いやつだと30年位前のCOBOLのコードがまだ現役で稼動しているけど
そんな古いコードが最新のマシン・OSでリコンパイル無しで未だに動作するってある意味凄いと思う。
WindowsだとOSのバージョンアップどころかSP適用しただけで動かなくなるアプリがあるというのにw

うちの職場は.netへの移行を迫られた際にVBの資源を全てJavaに焼きなおした。
ついでにAPサーバーも2003Serverから全てRHELにリプレースした。

>>896
恐らくVBを嫌がっているのは、2パターンの人がいる。
1つめは、COBOLが大規模になっているので今のロジックを残したい人達。
2つめは、Windowsしか動作しない。要は、Windowsのアップデートでマイクロ
ソフトが仮に客のデータを入手できるような状況になると困る。（トロイの木馬）
だからWindows以外でも動作可能にして欲しい。⇒COBOLかJAVAがBESTだな
という事で.netでVBが復活して欲しくないという事だと思う。

>>906
そんなことより、コンピュータ(ソフトウェア?)サイエンスのメインストリートから完全に
外れた製品で、このまま行ったらJAVAどころか、PythonやScalaにもどんどんシェアを
奪われ続ける製品だからだよ。MSが一番その事を承知している。

Scalaは無いな。なんの冗談だ。

>>903
monoも安泰じゃなくて最近ゴタゴタあったからなあ。
まあでも頑張ってもらいたいけど。

>>906
VBは.netによって弱体どころかむしろ見直されてるだろ。
VB6以前は、オブジェクト指向プログラミングできなかったが、VB.net以降なら可能。
C+で作らなきゃいけないような高度な物じゃない限り、VB.netで出来る。

VBを嫌ってる人は、VBの事を知りもしないで、
COBOLだけ、Javaだけとか、自分の得意な言語が一番だと考えてる人だけ。

>>887 だけを読んで、事務系の主流が VB と書いてるのは、もしかして VBA の
ことを言ってるんじゃないかと思ってしまった。

>>910
VBは別に嫌いではないけどWindowsでしか使用できないのでクライアント用アプリとしては使えるけど
サーバーサイドの基幹システムとしては使えないだけ。

C#のほうが好きだが、VB2010もなかなかたいしたもんだぞ。
細かいところでイライラすることもあるが、でも進化をやめたjavaよりはいい感じになってると思う。
なんたってドットネットの資産をフルフル使えるのは、やっぱでかいよ。

>>913
なんでC#じゃないんだ。世界的にそちらが主流だぞ。

>>908
事務処理の話題としては確かに不適だった。そもそもJAVA系だし。
米国では関数型への流れを全部この言語が受け止めているから一緒に書いてみた。

VBが.netで再評価ってのもなんかの冗談なのかな
VB別物になっちゃったよって嘆息はあっても、VB凄いねって流れは全くないぞ
VBならではのUI周りもとうに専売特許じゃなくなった
コボラーやメインフレーム屋との関連性も皆無に感じるんだが、なんか通じるものがあるのかな

COBOLとVBはかぶる。何故だか。

>>917
ああ、オレもなんとなく同じイメージがあるな〜

なんか被る。単純なオワコン臭とかじゃない何かがあるような。

>>916
でてきてもう8〜9年。旧VBを知らないVB.NETで育った世代もいるってことさ。

どちらも糞と言われながらも、リプレイスするとトラブる。

「COBOLはオワコン」ともう20年近く言われ続けているんだが、いつになったらなくなるんだろ・・・

たしかJavaが出始めた頃、「Cobolの時代はもう終わった。これからはJAVAだ!!」と騒がれていたけど、
気が付けばJavaの方が先に終わってしまった…。

>>921
最近は設計すらまともに出来ないコーダーまがいのPGばかりだからな…。そりゃトラブルさ。

>>924
プログラマーが設計する必要なんてあるのか?
そもそも設計なんて下衆な仕事はプログラムが組めない馬鹿SEの仕事だろ…。

つかPGが一人で設計からコーディングするっていったい何世紀前の話だよw

>>921
Javaもトラブル多いぞ
全然ワロえない

>>926
Javaはトラブル多いので、どうにもならなくなって、
VBで書いたモジュールつなげて、Java+VBという変体構成のシステムを大手電機が作ってきた。
あれは、なんだったんだろう。

>>927
どこだよ

普通は、Javaのみ　若しくは　VBのみで企業システムが出来るはず

>>928
VBのみでシステムを構築する場合、クライアント用アプリはいいとしてサーバーサイドはどうすんだ?
クライアントのみじゃ、かなり小規模なシステムしか構築できないと思うんだけど…?

一般向けのシステムをJavaでWebで公開して
いわゆるバックオフィスな部分（オペレーターさんが使うとこ）をドトネトで作成ってのもある

せめて.NETはSolarisやLinuxで実用的に稼動出来るようにして欲しい…。
基幹システムを稼動させるにはWindowsじゃあまりにも不安定で脆弱過ぎる。

>>929
サーバーサイドってどうして必要になるの？
データベースがインストールされているパソコンが必要なのは
分かるけど

なんか話の内容がクライアント系、フロントエンド系、バックエンド系t全てごちゃ混ぜになっているなw

>>931 IBMがJavaからMonoに乗り換えるとかそういう事件が起きればあるいは。

小生が作ったスレがこんなに伸びてうれしい！
やっぱり、COBOLはいらないんだね。

誰だよおまえw

サーバーサイド（基幹系）が必要な物
　・ホームページ（インターネットショッピング、会員制動画サイト　など）
　・オンラインゲーム

　このような時に大型コンピュータが必要になると思うがどうだろうか

>>937
> サーバーサイド（基幹系）が必要な物
> 　・ホームページ（インターネットショッピング、会員制動画サイト　など）
> 　・オンラインゲーム
>
> 　このような時に大型コンピュータが必要になると思うがどうだろうか

すまんが釣るならもっとマシなネタにしてくれ…。

大型コンピュータって何？
ネットショップレベルのWebサイトなら
そこら辺の中古パソコンで十分だろ。

さすがにそれはただ単に動くだけの代物だ。

>>939
ネットショップだが、Javaの場合
実は、サーバ側がずっと情報を掴んでいる状態となっている。
（セッションが情報を持っている。
　タイムアウトは、時間が来たので持っていた情報を解放した状態）

人気のあるショッピングサイトなら
ある程度の性能があるパソコンじゃないと厳しい。

貧乏スタートアップ個人事業なら中古C2D機で「十分」だろけどね
それで人気出たら最初のネックは回線だな
それでもさすがに中古は故障が怖いな。数万円な安鯖機を勧める

>>942
最低でも開発の時に動く事が前提
開発の時にメモリ不足で動かなかったらまず無理！

今時メモリ心配されてるあたりご同業だと思いますが、テストサーバ条件が乖離してるようなら文句言って損はないかと思うっすよ

この際、安案件は(長い目で見て)LLで対処できるよう働きかけも無駄ではないはず

COBOLは、関数が無い。
他の言語には関数がある。

コボラーは、関数の使い方を知らない人が多い。
（エクセルの関数もあまり使い切れない人が多い）

>>944
Javaでのメモリ不足は、COBOLと違う。
JavaでのPCのメモリ不足は、実行するとパソコンが固まって
何を押しても動作不能状態となって電源ボタンを切るしかない
状態となってしまう。

基幹システム系は、恐らく全てメモリ不足で悩まされている。
946のJavaもそうだし
（tomcat起動しただけで動作不能。プログラムは、動作させてない状況）
、オンラインゲームもメモリ不足で動きが遅い。
COBOLも動作が遅い。

>>946
まあ待ってくれ。もちろんおっしゃる通りだ。PCサーバでは異常プロセス検知も冗長化も甘い。
でも、あなたの挙げた異常状態はテスト不足だ。JavaだCOBOLだって話でさえない。
Amazonも楽天もDBの考え方レベルでさえテコ入れしてんだからさ、ハードウェア保護見越した処理の話やめません？
階層こそ違えど仮想化が生き生きとしてる今、そんなんCOBOLやメインフレームやら故の特権でもなんでもないんですよ

>>948
現実を見るんだ
最近は、パソコンゲームすら最低メモリ1Gとか2Gとか
書かれてあるのが現状だよ

>>949
・・・？
いや悪気は無いんだけど、今のメモリの価格知らん訳ではないでしょ？
勿論いろんな角度の問題や事情はあると思うので、皮肉や嫌味ではなく傾聴させて頂きたい。

>>949
うちは概ね30台ほどに4システム振ってそれぞれ512MB割り当てたLinux上で普通にJava動かしてるけど…

>>950
ボーヤはphpでも弄って寝てろ
>>951
ギガ積んでから出直せ
いつの時代だ

前のCOBOLの会社では、汎用機2台にシステムを振っていた。
その後、汎用機1台をWindowsに置き換えて確か
Windows(メモリは、ギガを積んでいる)と
汎用機は、光回線で結んでいると言っていた。

>>950
恐らくメモリ増設の事を言っているのだと思います。

で、前のCOBOLの会社ですが汎用機は約24時間フル稼働です。
1日に1回再起動（深夜時間帯）をかけているだけでした。

COBOLはメモリリークの事を考えなくていい。

COBOLは、基幹システムなのでメモリの物量作戦をしますので
メモリリークは、考えません。

やはり、COBOL言語について誤解している人が多い

他の言語：
　パソコンから入力⇒入力したパソコンが処理をしてデータベースに登録
COBOL：
　パソコンから入力⇒汎用機に入力したデータが集められる⇒
　汎用機で処理をしてデータベースに登録

　つまり、汎用機は常に動作中でなくてはならない。
　⇒メモリリークを考えたらいけない⇒メモリの物量作戦

正直な話をするとCOBOLを国家試験に入れておくと困る
地元では、COBOLを教えていたり工業大学ではBASICとFORTRANを教えて
いるという話を聞く。
どこでBASICやFORTRAN、COBOLを使っているんだよ

>>958
バリバリに現役。

>>958

お前さ、自分の知ってる世界がこの世の全てと思ってもらうと困るんだよ

流石に中小企業でメインフレーム(オフコン) + COBOLを現役で使用しているところは随分減ったと思うけど
大企業や金融機関、鉄道・電気・水道・ガス等の社会インフラ関連、各省庁のバックエンドでは未だCOBOLが現役で稼動している。

ただそういったところでも一般ユーザーが目にするフロントエンド系は殆どオープン系だったりするから
エンドユーザーが稼動しているCOBOLを実際に目にすることは皆無だろうね。

>>958
国家試験のCOBOL問題の難易度はCやJavaと比べると簡単だよ。
クラスやアドレスのことを考えなくていいし。

>>957
他の言語について誤解していますね。

他の言語もクライアント側からサーバー側に情報が集められて
サーバー側でデータベース処理が行われる。

クライアント側でデータベース処理ができると
DBの破壊や情報の改ざんとか
セキュリティ面から見ても危険ですよ。

>>963
DBの破壊や情報の改ざん

なぜそのような事がおきるの？
プログラムは、コンパイルをして実行可能な状態になりますよね
（インタプリタを除く）
COBOLは、classファイル　VBは、exeファイル　javaは、jarファイル　
このファイルが起動するわけだから（プログラムは、起動しない）
DBの破壊や情報の改ざんができないはずですが。。。

この実行可能状態のファイルは、解読不可能。

javaは、jarファイルと書いていましたが正確には
classファイルですね

何を言いたいのか分かったと思いますが念のために
exeファイルは、解読不可の為変更できない。
つまり、修正はプログラムを修正して再度コンパイル。
もちろんプログラムの中にDBへのアクセスも含まれています。

悪意のある人がDBをいじくろうとおもってもできないわけです。

>>963
あの質問ですが
VBやJavaの参考書を一度でもいいから読んだ事ありますか？

言語ごととか詳しいことは分からないけど……

>>957
> 他の言語：
> 　パソコンから入力⇒入力したパソコンが処理をしてデータベースに登録
入力するパソコンと処理するパソコンが別のパソコンなら、
サーバ・クライアント方式という観点で COBOL もその他も一緒。
同じパソコンなら色々と誤解してる。

>>967
確かにそうですね。
ならば、COBOLにあるバッチ処理もその考え方から必要なしとなりますね

cronも知らんのか？

>>965
解読不可って誰が決めた？VB6なんか接続文字列埋め込みだろ。
パスワードも埋め込んでるかもしれない。そんなのバイナリエディタ
で見たらすぐわかる。

何の為にcronをしているの

>>970
他の言語にすると埋め込まれないなら明日にでも移行したい。