14

このフォーラムには、Cobol プログラミング言語の関連性に関するスレッドがいくつかあります。たとえば、このスレッドはそれらのコレクションにリンクしています。ここで私が興味を持っているのは、1997 年の Gartner による調査に基づいて頻繁に繰り返される主張です。当時、約 2000 億行のコードが実際に使用されていたということです。

関連するいくつかの点を検証または反証するために、いくつか質問をしたいと思います。私の目標は、この声明に真実があるかどうか、またはまったく非現実的であるかどうかを理解することです.

確信が持てないことについて、私の考えや私自身の意見を述べるのが少し冗長であることを前もってお詫びします。 .


「2000 億行」という数字には、実際に使用されている任意の言語の全プログラミング コードの 80% に相当するという追加の主張が付随する場合があります。また、80% は単にいわゆる「ビジネス コード」 (または、読者が主流のソフトウェア、組み込みシステム、または Cobol が実質的に存在しないその他のものをカウントしないことをほのめかす他の漠然としたフレーズ) に言及している場合もあります。以下では、コードには同じソフトウェアの複数のインストールの二重カウントが含まれていないと想定しています (これは不正行為であるためです!)。

特に 2000 年問題以前には、多くの COBOL コードがすでに 20 ~ 30 年前のものであることが指摘されていました。つまり、60 年代後半から 70 年代にかけて書かれたということです。当時、市場のリーダーはIBM/370 メインフレームを搭載した IBMでした。IBM は、彼の Web サイトに、価格、構成、および入手可能性を引用した過去の発表を掲載しました。シートによると、価格は最大 0.5 メガバイトのメモリを搭載したマシンで約 100 万ドルです。

質問 1:実際に販売されたメインフレームの数は?

それらの時間の数字は見つかりませんでした。最新の数値は2000 年のもので、これも Gartner によるものです。:^(

実際の数は数百または数千に上ると思います。2000 年の市場規模が 500 億で、市場が他のテクノロジと同様に指数関数的に成長した場合、1970 年には数十億に過ぎなかったかもしれません。数万台のマシンで(そしてそれはかなり楽観的です)!

質問 2:プログラムのコード行数はどれくらいでしたか?

そのアーキテクチャの 1 行のソース コードから生成されるマシン コードのバイト数はわかりません。しかし、IBM/370 は 32 ビット マシンだったので、アドレス アクセスには 4 バイトと命令 (2、おそらく 3 バイト?) を使用する必要がありました。オペレーティング システムとプログラムのデータを数えると、0.5 メガバイトのメイン メモリには何行のコードが収まるでしょうか?

質問 3:標準ソフトウェアはありませんでしたか?

販売されたすべてのマシンは、標準的なソフトウェアなしで独自のハンドコーディング システムを実行していましたか? 真剣に、すべてのマシンがレガシ コードを再利用せずに最初からプログラムされていたとしても (待って... それは私たちが最初から始めた主張の 1 つに違反しませんでしたか???)、O(50,000 loc/machine) になる可能性があります。 * O(20,000 マシン) = O(1,000,000,000 loc)。

それはまだ2000億にはほど遠いです!ここで明らかな何かが欠けていますか?

質問 4: 2000 億行のコードを書くのに何人のプログラマーが必要でしたか?

これについてはよくわかりませんが、1 日あたり平均 10 loc を取得すると、これを達成するには 5,500 万人年が必要になります。これは、20 年から 30 年の時間枠で、200 万から 300 万人のプログラマーが絶えずコードを書き、テストし、デバッグし、文書化していたことを意味します。それは、今日の中国にいるプログラマーの数とほぼ同じ数になるのではないでしょうか?

編集:何人かの人々が、自動テンプレート システム/コード ジェネレーターなどを作成しました。誰かがこれについて詳しく説明できますか?これには 2 つの問題があります。a) システムが何をすべきかをシステムに伝える必要があります。そのためには、コンピューターと通信する必要があり、コンピューターはコードを出力します。これはまさにプログラミング言語のコンパイラが行うことです。したがって、基本的に、別の高水準プログラミング言語を使用して COBOL コードを生成しています。Cobol の代わりに他の高水準言語を使用するべきではないでしょうか? なぜ中間業者?b) 70 年代と 80 年代、最も貴重な商品は思い出でした。したがって、プログラミング言語で何かを出力する場合は、簡潔にする必要があります。編集の終わり

質問 5:コンテストについて教えてください。

ここまでで、次の 2 つのことを思いつきました。

1) IBM には独自のプログラミング言語PL/I がありました。上記では、コードの大部分が COBOL のみを使用して記述されていると想定しています。しかし、他のすべての条件が同じであるとすると、IBM のマーケティングが自社のマシンでの COBOL を支持して、自社の開発を市場から追い出したのではないかと思います。PL/I に関連するコード ベースは本当になかったのでしょうか。

2) ときどき (上記のスレッドのこの掲示板でも) 「2,000 億行のコード」は「政府、銀行など」以外の誰にも見えないという主張に出くわすことがあります。実際、国防総省は、費用対効果を高め、プログラミング言語の普及を抑えるために、独自の言語に資金を提供していました。これが Ada の使用につながりました。COBOL を主に使用していた場合、非常に多くの異なるプログラミング言語を使用することについて本当に心配するでしょうか? 主流のコンピューティングの認識の外にある「政府および軍事」システムで実行されている言語があるとしたら、その言語は Ada ではないでしょうか?

誰かが私の仮定や結論の欠陥を指摘し、上記の主張に真実があるかどうかを明らかにしてくれることを願っています.

4

6 に答える 6

7

表面的には、Gartner が生成する数字は、「ピンの頭の上で何人の天使が踊ることができるか?」という質問に答えることに似ています。. 彼らのレポートの完全なコピーを入手しない限り (大金がかかります)、彼らがどのようにして 2000 億行の COBOL 主張を思いついたのか、または正当化したのかを知ることはできません。そうは言っても、Gartner は評判の高い情報技術の調査および助言会社であるため、正当な理由や説明がなければ、そのような主張はしなかったと思います。

この研究が何年にもわたって引用されてきたことは驚くべきことです. 「2000 億行の COBOL」を Google で検索すると、約 19,500 件がヒットしました。私はそれらの多くをサンプリングしましたが、そのほとんどは 1997 年の Gartner レポートに直接起因するものです。明らかに、この数字は多くの人々の注目を集めています。

主張を「デバンク」するために取った方法には、いくつかの問題があります。

1) 販売されたメインフレームの数これ自体が大きな問題であり、おそらく 2000 億行のコードの質問に答えるのと同じくらい難しいでしょう。しかし、もっと重要なことは、メインフレームの数を決定することで、メインフレームで実行されるコードの行数を制限する方法がわかりません。

2) プログラムのコード行数はどれくらいでしたか? COBOL プログラムは大きくなる傾向があります。控えめなプログラムは数千行、大きなプログラムは数万行まで実行できます。COBOL プログラマーがよくするジョークの 1 つは、これまでに作成された COBOL プログラムは 1 つだけで、残りはその変更されたコピーに過ぎないというものです。多くのジョークと同様に、そこには一片の真実があります。ほとんどのショップは大量のプログラムの在庫を持っており、それらのプログラムの多くは互いに切り貼りして作成されています。これにより、コードベースのサイズが実際に「膨らみ」ます。

プログラムを実行するには物理メモリに収まらなければならないというあなたの仮定は間違っています。サイズの問題は、いくつかの異なる方法 (プログラム オーバーレイ、仮想メモリなど) で解決されました。60 年代と 70 年代には、物理​​メモリが小さいマシンで大きなプログラムを実行することは珍しくありませんでした。

3) 標準ソフトウェアはありませんでしたか? 多くの COBOL はゼロから、またはテンプレートから作成されます。70 年代から 80 年代にかけて、多くの金融パッケージがソフトウェア会社によって開発されました。これらのほとんどは、ソース コード ライブラリとして配布されました。その後、顧客は特定のビジネス要件に合わせてソースをコピーおよび変更しました。コードベースのより多くの「毛羽立ち」 - 特に、パッケージが「構成」されると、そのコードの大きなセグメントが論理的に実行不可能であったことを考えると。

4) 2000 億行のコードを書くのに何人のプログラマーが必要だったのか 思ったほど多くはありません! COBOL が冗長で高度に複製される傾向があることを考えると、プログラマーは大きな「生産性」を持つことができます。プログラム生成システムは、70 年代から 80 年代初頭にかけて流行しました。私はかつて、「ビジネス ロジック」を記述できる製品 (幸いなことに現在は廃止されています) を使用して、その周りのすべての「ボイラー プレート」コードを生成し、完全に機能する COBOL プログラムを作成しました。生成されたコードは、礼儀正しく、極端に冗長でした。約 200 行の入力から 15K 行の COBOL プログラムを作成できました。ここで深刻な綿毛を取っています!

5) 大会はどうですか?COBOL は、金融および保険の分野でそれほど深刻な競争をしたことはありません。PL/1 は、考えられるすべてのコンピューティング ニーズを満たす 1 つのプログラミング言語を作成するための IBM の主要なイニシアチブでした。そのようなすべてのイニシアチブと同様に、それは野心的すぎて、内部的にほとんど崩壊しました. IBM は現在でもそれを使用し、サポートしていると思います。70 年代には、他のいくつかの言語が COBOL に取って代わると予測されていました。今日、Java と .Net についても同じことが言われています。COBOLがまだ私たちと一緒にいる主な理由は、COBOLが本来の機能を非常にうまく実行していることと、膨大な数十億行のコードの遺産により、ビジネスの観点から「より良い」言語への移行が高価でリスクが高いことだと思います.

2,000 億行のコードの話は信じられますか? COBOLコードが時間の経過とともに自分自身を「毛羽立たせる」傾向がある方法の数を考えると、数字は高いですが、ありえないほど高くはありません。

また、これらの数字の分析に関わりすぎると、すぐに「天使を数える」作業に陥ってしまうと思います。これは、人々が夢中になる可能性がありますが、現実の世界では何の意味もありません。

編集

以下に残されたコメントのいくつかに触れさせてください...

投資銀行が使用する COBOL プログラムは見たことがありません。かなり可能。どのアプリケーション分野で働いていたかによって異なります。投資銀行は、大規模なコンピューティング インフラストラクチャを持ち、幅広いテクノロジを採用する傾向があります。私が過去 20 年間働いてきたショップ (投資銀行ではありませんが) は、国内最大級のショップであり、多額の COBOL 投資を行っています。また、Java、C、および C++ への多大な投資と、人類が知っている他のほぼすべてのテクノロジのポケットもあります。また、COBOL がまだ使用されていることをまったく知らなかったかなり上級のアプリケーション開発者にもここで会いました。ソース管理システムで大まかな行数を数えたところ、約 7,000 万行の実稼働 COBOL が見つかりました。ここで何年も働いているかなりの数の人々は、それを完全に忘れています!

また、選択する言語として COBOL が急速に衰退していることも認識していますが、実際には、今日でも多くの言語が使用されています。この質問が関係する 1997 年の時点では、LOC に関しては COBOL が支配的な言語だったと思います。問題のポイントは、1997 年に 2000 億行あった可能性があるかということです。

メインフレームのカウント。メインフレームの数を取得できたとしても、それらが表す「計算」能力を評価することは困難です。メインフレームは、他のほとんどのコンピューターと同様に、さまざまな構成と処理能力があります。1997 年に正確に「X」個のメインフレームが使用されていたと言える場合でも、それらが表す処理能力を見積もる必要があります。次に、COBOL プログラムやその他のプログラムを実行することによる作業負荷の割合を把握する必要があります。交絡因子。この推論の行が、許容できる誤差範囲でどのように答えをもたらすかはわかりません.

コードのマルチカウント行。COBOL の「毛羽立ち」要因について言及したとき、まさにそれが私の要点でした。COBOL の行数を数えることは、非常に誤解を招く統計となる可能性があります。これは、COBOL の大部分がそもそもプログラマーによって書かれたことがないためです。もしそうなら、かなりの部分がカットアンドペーストいじくり回しの「デザインパターン」を使用して行われました.

メモリが 1997 年以前に貴重な商品であったというあなたの観察は真実です。これにより、利用可能な最も効率的なコーディング技術と言語を使用して、その使用を最大化することにつながると考える人もいるでしょう。ただし、他の要因もあります。アプリケーションのバックログが発生することによる機会費用は、多くの場合、最適化されていないコードを処理するためにより多くのメモリ/CPU を導入する費用を上回ると認識されていました (これはかなり高速にクランクアウトされる可能性があります)。この考え方は、ムーアの法則によってハードウェアのコストが低下し続ける一方で、ソフトウェアの開発コストは一定のままであるという観察によってさらに強化されました。「論理的な」結論は、最適ではないコードを作成し、しばらく苦しみ、その後何年にもわたって利益を享受することでした(IMO、悪い計画と貪欲の教訓であり、今日でも一般的です)。

70 年代から 90 年代にかけてアプリケーションを配信しようとした結果、多数のコード ジェネレーターが台頭しました (今日、さまざまなフレーバーのフレームワークがこの役割を果たしているのを目にします)。これらのコード ジェネレーターの多くは、大量の COBOL コードを出力しました。COBOL コードを発行する理由 アセンブラや p-code など、もっと効率的なものを発行してみませんか? その答えは、リスクの軽減にあると思います。ほとんどのコード ジェネレーターは、10 年後にビジネスを行ったり、製品をサポートしたりしないサード パーティが所有する独自のソフトウェアです。生成されたアプリケーションが遠い将来までサポートされるという鉄壁の保証を提供できない場合、それは非常に難しい販売です。解決策は、「ジェネレーター」になじみのあるもの、たとえば COBOL を生成させることです。「発電機」が死んでも、結果として得られるアプリケーションは、既存の COBOL プログラマーのスタッフが保守できます。問題は解決しました ;) (今日、リスク軽減の議論としてオープンソースが使用されています)。

LOC の質問に戻ります。私の意見では、COBOL コードの行数を数えることは、大きな誤差または少なくとも誤解を招く可能性があります。以下は、私が取り組んでいるアプリケーションの統計です (おおよそ引用されています)。このアプリケーションは Basset Frame Technology (フレームワーク) を使用して構築および維持されているため、実際に COBOL を作成するのではなく、そこから COBOL を生成します。

  • COBOLの行数: 7,000,000
    • 非手続き部門:3,000,000
    • 手続き部門:3,500,000
    • コメント/ブランク : 500,000
    • 展開されていない COPY ディレクティブ: 40,000
  • COBOL動詞: 2,000,000
  • プログラマー手順書部門:900,000
  • 生成されたアプリケーション フレーム: 270,000
  • 生成された企業インフラ フレーム: 2,330,000

このように、当社のCOBOLプログラムの半分近くが無手続き部のコード(データ宣言など)です。LOC と動詞 (ステートメント数) の比率は約 7:2 です。私たちのフレームワークを使用すると、約 7:1 の係数でコード生成が活用されます。それで、あなたはこれらすべてから何を作るべきですか?私にはよくわかりませんが、COBOL の行数を増やす余地がたくさんあることを除けば。

過去に他の COBOL プログラム ジェネレーターを使用したことがあります。これらのいくつかは、まったくばかげたインフレ要因を持っていました (たとえば、前述の 200 行から 15K 行の毛羽立ち)。これらすべてのインフレ要因と Gartner が使用するカウント方法を考慮すると、1997 年には最大 2000 億行の COBOL を「膨らませる」ことができた可能性が非常に高いかもしれませんが、疑問が残ります。それは本当にどういう意味ですか?何も思いつきません。天使の数を数える問題に戻りましょう!

于 2010-06-01T21:25:35.853 に答える
2

数字はありませんが、私の最初の「本当の」仕事は IBM 370 でした。

1つ目:販売数。1974 年には、3 両の 370 で大規模な鉄道が走っていました。ただし、これらは大きな 370 であり、小さなものをはるかに安く手に入れることができました。(現時点では、別のメガバイトを取得するかどうかは VP レベルでの決定でした。)

2 つ目: 典型的な文 (行の COBOL 語) は「顧客のメイン アカウントに 1 を追加します」のようなものであるため、COBOL コードは「ふわふわ」と呼ばれるものです。1 行あたりの機械語命令は比較的少なくなります。(これは特に、COBOL の実行を中心に設計されたマシン命令を使用する IBM 360 以降に当てはまります。) ところで、アドレスは 16 ビットで、4 つはレジスタを指定し (下位 24 ビットをベース アドレスとして使用)、12 はオフセットとして使用されました。 . これは、さまざまな理由で 16 個のレジスタのすべてをベース レジスタとして使用できるわけではないため、一度に 64K 未満のものをアドレス指定できることを意味していました。プログラムを小さなメモリに収める人々の能力を過小評価しないでください。

また、プログラムの数を過小評価しないでください。プログラム ライブラリはディスクとテープにあり、基本的にはコストと量だけが制限されていました。(以前は、データとプログラムのストレージとして深刻な問題を抱えていたパンチ カードを使用していました。)

3 番目: はい、ほとんどのソフトウェアは当時、ビジネス用に手書きで書かれていました。当時、機械ははるかに高価で、人は安かった。プログラムは既存のビジネス プロセスを自動化するために作成されたものであり、ソフトウェアの外に出てビジネス プラクティスを変更できるという考えはほとんど異端でした。もちろん、これは時間の経過とともに変化しました。

第 4 に、プログラマーは今日よりもはるかに速く、1 人年あたりのコード行数で作業を進めることができました。私の経験では、これDATA DIVISIONは各 COBOL プログラムの大部分を占めており、多くの場合、ファイル レイアウトの大量の記述を取り、シリーズの各プログラムでそれらを繰り返していました。

私はプログラム ジェネレーターの経験があまりありませんが、当時はプログラム ジェネレーターを使用してアプリケーションを生成し、出力を変更することは非常に一般的でした。これは、一部は単に悪い習慣であり、一部はプログラム ジェネレーターが必要なすべてを行うことができなかったためです。

5 番目: IBM の努力にもかかわらず、PL/I はあまり使用されませんでした。私の知る限り、修正できなかった唯一の本当の大きな問題は、精度システムを理解することでしたが、初期の悪い報道に遭遇しました. 国防総省は、Ada と COBOL をまったく別の目的で使用していました。競合他社としてアセンブリ言語を省略しており、多くの小規模なショップが COBOL の代わりに BAL (ASM とも呼ばれます) を使用していました。結局、プログラマーは安く、コンパイラーは高価で、COBOL ではできないことがたくさんありました。実際、それは非常に優れたアセンブリ言語で、私はとても気に入りました。

于 2010-06-02T17:37:22.940 に答える
2

[通常の免責事項 - 私は COBOL ベンダーで働いています]

これは興味深い質問であり、証明可能な数値を取得することは常に困難です。COBOL プログラマーの推定数については、200 万から 300 万という数字は桁違いの誤差ではない可能性があります。過去には100万から200万の見積もりがあったと思います。そして、それらのそれぞれは、20 年のキャリアの中で多くのコードを生成できます。インドでは、毎年 (おそらく毎月!) 何万人もの新しい COBOL プログラマーがプールに追加されています。

自動生成されたコードは、おそらく思ったよりも大きいと思います。たとえば、PACBASE は銀行業界で非常に人気のあるアプリケーションです。私が知っている非常に大きなグローバル銀行は、それを広範囲に使用しており、すべてのコードを COBOL に生成し、この生成されたコードがコードベース全体の 95% であり、残りの 5% は手作業でコーディング/維持されていると推定しています。これは珍しいことではないと思います。これらのシステムの保守と開発は、通常、生成されたコードではなく、モデル レベルで行われます。

元の質問には含まれていなかったアプリケーションのグループがあります。COBOL は単なるメインフレーム言語ではありません。Micro Focus の初期の頃は、ほぼすべてが OEM 市場に費やされていました。以前は、200 ほどの異なる OEM がありました (DEC、Stratus、Bull などの多くの古い名前)。すべての OEM は、C およびアセンブラーと共に、ボックスに COBOL コンパイラーを搭載する必要がありました。当時、多くの大きなアプリケーションが構築され、現在も強力に機能しています。最大の人事 ERP システム、最大の携帯電話課金システムなどを考えてみてください。私が言いたいのは、IBM メインフレームにはなかった COBOL コードがたくさんあるということです。と見落とされがちです。

最後に、COBOL ショップのコード ベースのサイズは、「平均」よりも大きい場合があります。それは単に COBOL が冗長だからというだけではありません (または、長い間そうではありませんでした)、システムがより大きく、大規模な組織で多数の異なるタスクを実行しているからです。サイトに数千万の LoC があることは非常に一般的です。

于 2010-06-02T13:57:37.970 に答える
2

私はガートナーでそれらのピエロを擁護することはありませんが、それでも:

IBM/370s についてのあなたの考えは間違っています。370 はアーキテクチャであり、特定のマシンではありませんでした。水冷モンスターから小型のミニコンピュータ サイズのマシン (VAX と同じサイズ) まで、すべてに実装されていました。したがって、販売された数はおそらく、あなたが思っているよりも桁違いにはるかに多かったでしょう.

また、COBOL は DEC の VAX ラインアップで頻繁に使用され、それ以前は DEC-10 および DEC-20 ラインで使用されていました。英国では、すべての ICL メインフレームで使用されていました。他の多くのプラットフォームもサポートしています。

于 2010-06-01T18:53:15.407 に答える
1

さて、あなたはここで間違った場所で尋ねています。このフォーラムは .net プログラマーによって支配されており、かなりの Java 少数派と非常に少数の少数派だけが COBOL の経験を持っているほどの年齢の蓄積があります。

CASE ツール市場は、大部分の COBOL コード ジェネレーターで構成されていました。ほとんどのツールは書き込み専用で、双方向ではありませんでした。これにより、多くのコード行が確保されます。この市場は 70 年代よりもやや新しく、80 年代と 90 年代には COBOL コードの量が急速に増加しました。

多くの COBOL 開発は、重要なインターネット アクセスがないため、可視性を持たない人々によって行われます。その必要はありません。Cobol プログラマーは、社内のプログラミング コースと紙のドキュメント (大量) を持つことに慣れています。

[編集] COBOL ソースを生成することは非常に理にかなっています。Cobol は非常に冗長で低レベルです。さまざまな COBOL 実装はすべてわずかに異なるため、コード ジェネレーターを構成すると、多くの潜在的なエラーが排除されます。

于 2010-06-01T18:36:19.933 に答える
0

#4 に関して: そのうちどれくらいが機械生成コードだった可能性がありますか? テンプレートベースのコードが Cobol でよく使われていたかどうかはわかりませんが、今ではあらゆる種類のものに使われているようです。私のアプリケーションに、機械で生成された何千もの LOC がある場合、それはあまり意味がありません。私が最後に作成したコード生成スクリプトは、作成に 20 分、入力のフォーマットに 10 分、実行に 2 分、その後、一連の自動テストを実行して実際に機能することを確認するのに 1 時間かかりましたが、生成されたコードは手作業で数日間 (または、朝の会議と昼食の間の時間、私のやり方で行います ;))。わかりました、必ずしもそれほど簡単ではなく、手動での微調整が必​​要になることはよくありますが、コードジェネレーターが頻繁に使用されている場合、LOC メトリックはあまり意味がないと思います。

おそらくそれが、彼らが非常に多くのコードを短時間で生成した方法です。

于 2010-06-01T14:06:40.860 に答える