日本-日本語
日本HPホーム 製品 & サービス サポート & ドライバー ソリューション ご購入方法
≫  お問い合わせ

製品とサービス >  ソフトウェアとOS >  OpenVMS >  History of OpenVMS

VAX & VMSものがたり


第4章 VMSソフトウェアの開発

VAXハードウェアの開発に遅れること数ヶ月、1975年6月にコード名が 「Starlet」というソフトウェアの開発が開始されました。Roger Gourdがプロジェクトを主導し、 ソフトウェア技術者のDave Cutler、Dick Hustvedt、Peter Lipmanが技術面のプロジェクトリーダでした。 そして、この3人はオペレーティングシステムの別々の部分を担当しました。


VMSのプロジェクト計画

Starletプロジェクト計画は、Starファミリープロセッサ用に 全く新しいオペレーティングシステムを開発することでした。 この計画は、多数の異なる環境をサポートできる拡張可能な 高性能のマルチプロセシングシステムを要求していました。 ちょうどPDP-11とカルチャー的に互換性のあるハードウェアが設計されたように、 Starletは既存のオペレーティングシステムであるRSX-11Mとの互換性を保つことによって、 ハードウェアの互換性を増強するように設計されました。

短期的な目標は、VAXシステムの最初の顧客への出荷用に、オペレーティングシステムの核部分を 開発することでした。これは競争力のある十分な機能を持っていましたが、 長期にわたる多様なDEC市場に合わせて、拡張版やサブセットを作成するための基礎となる必要もありました。

プロジェクトの長期の目標は、品質、性能、信頼性、適用性、サービス性、 サポート費用の減少、および少ない開発費と保守費用でした。 主な目標は、リアルタイム処理やトランザクション処理などの高性能アプリケーションを サポートすることでした。

  VMS V1 software development team
VMS V1 software development team

資料化

当初から、ソフトウェアチームは、プロジェクトの重要な部分を資料化することを考えていました。 最初のテクニカルライター、Sue Gaultはソフトウェアチームとの設計会議に参加して、 Starletの設計書の資料化を支援しました。この設計書には、 オペレーティングシステムの詳細な技術面の説明が書かれていました。 このプロジェクトは「ハードウェアとソフトウェアを一体にしたひとつのシステムを開発する」 として定義されていたので、現在までのDECのどんなプロジェクトよりもスコープが複雑でした。

資料作成作業を通じて、エンジニア達はドキュメントのライターからフィードバックを得て、 潜在的な問題をトラブルシュートすることができました。アイデアは明確に表現され、 仕様書に正確に記述される必要がありました。この方法は、仮定や意見の相違を解決するのに有効でした。 資料化は、社内の他の人々にVMSプロジェクトの情報を知らせるためにも有効でした。 そして、新しいプロジェクトに対する社内の圧倒的な支援と熱意の確保に大きく貢献しました。.

Bill Heffner(VP、ソフトウェア エンジニアリング)の話

  「ソフトウェア開発は、非常に創造的で個人的です。 我々は、エンジニアに独立して働く自由、共同して働く自由、 やりたいことをする自由を与えることを望みました。」  

連携作業

ソフトウェアとハードウェアの間の緊密な統合を確かなものにするため、 複数のソフトウェアのプログラマがVAXデザイン委員会に出席して、 ソフトウェアの観点からデザインに貢献しました。

ソフトウェアとハードウェアのエンジニア間の緊密な協力により、 潜在的な問題の解決にも役立ち、最終的に緊密に統合されたソフトウェアと ハードウェアのシステムが開発されました。これは、「デザインイン」と 「アドオン」ほどの相違を意味しました。 ソフトウェア開発作業の結果として、多くのハードウェアの要素が変更されました。

VAXとVMSの開発チームは、実際のマシンと同時にソフトウェア開発を行うために、 早期のハードウェアのインプリメンテーションが、必須であることを認識していました。

このため、ハードウェアエンジニアのチームは「ハードウェアシミュレータ」 と呼ばれたシステムを作りました。これは、PDP-11/70の部品、カスタムロジックのボード、 多くのファームウェアから構成され、VAXプラットフォームの早期のインプリメンテーションとなりました。 VMSのチームは、そのシミュレータ上でオペレーティングシステムのソフトウェアすべてを 設計しテストしました。シミュレータは、実際のシステムよりも10倍から20倍時間がかかりましたが、 開発チームがソフトウェアを設計しながら、そのシステム上で作業することが可能になりました。

規律ある創造性

  当初から、DECは創造性の重要性を理解して、 個人の創造性が規律ある環境でも成長する事ができるような環境を求めていました。 その戦略は、有能な人を採用し、彼等に計画作製の権限を与え、 かれらの計画をレビューし承認する事により、プロジェクトのオーナーとすることでした。 会社は、社員がマイルストーンと予算を守らなければならないときが、 最も生産的であると信じていました。ここに規律が必要になります。 製品ラインのグループはそれぞれ、時間と予算の制約の中でその計画を達成する責任がありました。  

カート上のブレッドボード

VAX-11/780のエンジニアリングチームは、最初にブレッドボードというマシンを作成して、 大きな金属製のカートに載せました。すべての回路ボードがワイヤラップにより作成されました。 一方、電源はカートの下部の棚に乱雑に置かれていました。

ソフトウェア開発チームは、そのブレッドボード上で短期間タイムシェアのVMSシステムを走らせていました。 というのは、VMSがマルチユーザをサポートするように進化した頃に、それが使用可能になったからです。 しかし、ブレッドボードは完全には信頼性がありませんでした。 この理由は、動作速度がワイヤラップで可能な限界に達していたからでした。

そのブレッドボードは、最初のVAX-11/780のエッチングされたプロトタイプで置き換えられました。 このプロトタイプは実際の部品、すなわち、実際のフレーム、電源、 エッチ回路ボードなどで作成さされた最初のマシンでした。 欠けていた唯一のものは、外部キャビネットでした。 このプロトタイプは、VMSとVAX-11/780が出荷されたずっと後まで、 量産機と交換される事はありませんでした。このプロトタイプは、 スタンドアロンのテストに何年間も使用され続けました。 VAX-11/780後に開発されたシステムは、ブレッドボードのステージを経由しませんでした。 というより、徹底的なシミュレーションの後、実際のエッチングされた回路ボードに直接移行しました。

ソフトウェア開発者は自分達の作業にプロトタイプを使用しました。 これは、自分達が作成したものを使用するという閉じたループ環境を提供しました。 設計作業にそのソフトウェアシステムを使用するというこの戦略により、 先に進むに従って潜在的な問題を見つけるのが容易になりました。

仕事ばかり?

 

何年間も、VMSのエンジニアは共に笑い、共に働きました。 このため、多くの実践的なジョークがありました。 それらのジョークには次のようなガイドラインがありました。 「人が作業を行うのを邪魔してはいけない。システムに害を与えたり、 または一日の作業成果を失うようなことをするのは許されない。しかし、それ以外は許される。」

Dave Culterが、最初のVMSのエイプリルフールのジョークを始めました。 1年後、Andy Goldsteinがすべて逆に印刷するように、 ラインプリンタのドライバを交換しました。別の年の4月1日に、 システムメッセージのファイル全体が、「ファイルが見つかりません。どこに置きましたか?」 などのジョークのメッセージと交換されました。

VMSエンジニアのTrevor Porterが休暇で故郷のオーストラリアに帰りました。 そして、彼が戻る前に、仲間のエンジニアのAndy Goldsteinが彼のオフィスのドアーがあったところを パネルで留めてしまっていました。Trevorは自分のオフィスに行って、その状態を見ました。 そしてAndyの方に向いて「OK!スパナはどこ?」と言いました。

 

Kathy Morse(VMSエンジニア)の話

  「VMSグループの哲学の1つは、我々は自分達が作るソフトウェアを使って暮らすというものでした。 なぜなら、ソフトウェアが自分達に良いものでなければ、自分達の顧客にも良いものではないからです。」  

誰がレッドフラグを持っている?

ソフトウェアのビルド環境プロセスは、ソフトウェアのソースコードを 実行可能なシステムに変換するものですが、一度に1人しかビルドできませんでした。 2人が同時にビルドしようとすると、お互いに上書きしてしまい使用可能なものは何も生成できませんでした。 エンジニアは熱心に働きますが、別のエンジニアが今ビルドの最中かどうかを知る手段がありませんでした。 早い時期から、隣り合ったオフィスの2人のエンジニアが同時にビルドしようとして、 互いの作業内容を破壊してしまうのを避けることができませんでした。

創造的なチームは、創造的なソリューションを思いつきました。 誰がビルドを行っているかを知る方法として、磁石付きの赤旗がシミュレータを 使用している人の部屋に置かれました。

それは通常、「mutex」と呼ばれ、一般的に使用されるソフトウェアの同期化のメカニズムを意味しました。 エンジニアがビルドしたいときは赤旗を探して、その所有者に「使える?」と尋ねます。 そして、旗の所有者がビルド中でない限り、それを使用できました。


必要になると作られたツール

必要性から、チームはプロジェクトの進捗につれ、自分達のツールを数多く作りました。 性能評価のために、VMSエンジニア達は性能モニターを作り、 システム性能の測定にそのツールを使用しました。モニターの一部は、 タイムシェアリングの負荷として働く、別のPDP-11コンピュータシステムで動作しました。 これを用いて、エンジニアはタイムシェアリングでの性能を見るために、 種々の複数ユーザの作業負荷によりVMSを測定しました。


作成したものを使用

ハードウェアとソフトウェアのエンジニアの間には、多くのやり取りがありました。 ライター達も申し分のない閉じたループプロセスを提供する、ソフトウェアを使用しました。 この背景にあったのが、プロジェクトが進むにつれて、ソフトウェアを用いてテストし、 デバッグするというソフトウェアの哲学でした。


互換性の確保

VMSの開発システムは、ある大きな部屋に設置されましたが、 そのほとんどは大規模な一台のデュアルプロセッサのDECsystem-10によって占められ、 一台のPDP-11/70はその部屋の片隅に置かれました。 最初のバージョンのVMSでは、大部分がMacroで書かれ、残りはBlissで書かれました。 Macroの開発は、クロスコンパイラを用いてPDP-11で徹底的に行われました。 アセンブラのオブジェクトモジュールは、その後PDP-11で実行形式にリンクされディスクに出力されました。 そして、VMSエンジニアがそのディスクを隣部屋のVAXシステムに運びました。

Andy Goldstein(最初の開発チームのVMSエンジニア)の話

 
Andy Goldstein
Roger Gourdが Mythical Man-Month(Fred Brooks著)という本を回覧し、 チームのメンバーのほとんどがその本を読みました。我々のほとんどが、 すでに何らかのオペレーティングシステムを経験していました。 このため、Brooksの「第二システム効果」に関する議論には同感しました。

「第二システム効果」は、最初のシステムにおけるすべてのミスや欠点を、 各エンジニアが修正しようとすることに起因するものです。 放って置くと、「第二システム効果」はソフトウェアの品質とスケジュールに 影響を及ぼす手に負えない複雑さの原因となることがあります。 「忍び寄るエレガンス」という新しい用語がプログラマの辞書に入れられました。 すなわち設計が連続的に改良され、どんどん完全になって行き、 最後にはそのサイズと複雑さのために破壊という結果をもたらすプロセスを表す用語です。

これによりソフトウェアチーム全体が、機能する高品質な製品を作成する事と、 スケジュールを守ることのバランスを配慮するようになりました。

 

Blissで書かれたVMSモジュールのコンパイルにはDEC-10が使用されました。 この理由は、当時BlissコンパイラはDEC-10上でしか動作しなかったからです。 Blissコードをリンクするためには、テープを使用してPDP-11に持って行かなければなりませんでした。

プログラム作成のプロセスは、当初非常な時間と努力を必要としました。 しかし、新しい仮想メモリのオペレーティングシステムは、 最新の基準に比しても比較的短期間に開発されました。

VMSシステムのカーネルと関連する重要な機能は、新規のVAXインストラクションセットを用いて、 ネーティブモードで書かれました。しかし、多くのユーティリティの機能は 単にRSX-11オペレーティングシステムから移植されて、PDP-11エミュレーションモードである 互換モードで動作しました。これにより、これら機能のVMSへの移植が早まっただけではなく、 VAXプラットフォームとVMSオペレーティングシステムの互換機能のライブテストが効率的になりました。

仮想メモリシステムのソフトウェアは、ミニコンピュータにこれまで無かった多くの機能を提供しました。 VAXとVMSもネットワークとPDP-11との互換性をサポートしたため、顧客はPDP-11のプログラムを実行して、 自分達のアプリケーションをVAXとVMSに迅速かつ容易に移行することができました。

放棄された自動車(Kathy Morse、VMSエンジニア)

  「VMSの開発中、関係者は非常に多くの残業をしました。 ある時期に、カリフォルニアからのエンジニア、Ralph Weberを採用しました。 最初の1週間、彼はレンタカーを借りホテル暮らしをしていました。 会社に朝早く到着したので、毎朝正確に同じ場所に駐車し遅くまで残業していました。 一週間後、ガードマンはその自動車が放棄されたものと思い、 レンタカー会社に電話をして引き取らせてしまいました。その夜、Ralphが退社して駐車場に行くと、 自分の自動車がありません。そこで、彼はガードマンの所に行き、「レンタカーが盗まれた」と叫びました。 ガードマンは警察に電話をしようとしましたが、そのとき幸運にも、 別のガードマンが来て、『その車は、そこに一週間置かれていたので放棄されたものと思い引き取らせた。』 と言いました。」  

VMSの戦略

VMSソフトウェアの戦略は、小型から大型までの製品範囲をカバーする 単一オペレーティングシステムの開発でした。VMSは、並行バッチ処理、トランザクション処理、 タイムシェアリング、限定的なリアルタイム処理を可能とする完全なメインフレーム機能を提供しました。

VMSの背後にあったこの単一オペレーティングシステム戦略は、 以下のようなPDP-11の複数オペレーティングシステムの反動でもありました。

  • リアルタイムとラボ用のRT-11
  • 教育と小規模商用タイムシェアリング用のRSTS-11
  • 工業と製造制御用のRSX-11
  • 医療システム用のMUMPS-11
  • DOS-11、ほとんど上記のOSにより取って代わられた元のPDP-11オペレーティング システム

PDP-11オペレーティングシステムの各々は、特定の市場分野向けでしたが、 市場を越えて多数販売されました。同時に、非互換インターフェイスの複数オペレーティングシステムにより、 アプリケーションのシステムベースが薄まってしまいました。 どんなアプリケーションも、多数のシステムで動作するには、 複数のバージョンに移植される必要がありました。

このため、VMSの戦略は、PDP-11のターゲット市場のほとんどを対象とできるように、 柔軟性に富み、強力で効率的な単一オペレーティングシステムを開発することでした。

  ケープコッドでのVMSバージョン3のリリースパーティ
ケープコッドでの
VMSバージョン3のリリースパーティ

VAXとVMSのビジネスに賭ける

VAXシステムとVMSオペレーティング システムの開発以前は、 DECは複数のプロダクトライン環境で経営されていましたが、 1978年に、DECを今後10年間に渡って導くための「VAX戦略」というビジョンを採用しました。 会社はPDP-11とDECsystem-10の開発を継続しましたが、主な方向はVAXの開発でした。

VAXとVMS戦略は、以下の一貫したDECからのメッセージを導き出しました:

  「1つのプラットフォーム、1つのオペレーティング システム、1つのネットワーク」。
 

1978年のブリザードの中でのデバッグ(Andy Goldstein VMSエンジニア)

 

暴風雪の最初の夜、Andy Goldsteinは新しいVMSのファイル構造に関して夜遅くまで働いていました。 彼は帰宅できなくとも平気でした。Hank Levyがミルから道路をはさんだ所に住んでいましたので、 帰宅できないVMSグループの人々は彼の家に行き、ソファーで寝ました。

「私はディレクトリのエラーを見つけて、『何てことだ、ファイルシステムにバグがあった』 と叫びました。このデータを収集しようとしましたが、雪が深く積もってきて停電となりました。 州全体が次の2週間クローズされましたが、私はミルに車で行き、何とか中に入りました。 マシンの電源を入れ、問題のディレクトリのダンプを取り、家に持ち帰りました。 それから、近くに住んでいたRichie Laryに電話をして、 『Richie、マイクロコードにバグがあると思う』と言いました。 すると彼は『マイクロコードのリストが家にあるから、家に来ないか』と言いましたので、 雪道を歩いて彼の家に行きました。Richieはベッドの下から6インチのバインダを取り出し、 二人で調べました。そして、バグを見つけて修正しました。」

 

Patti Anklamテクニカル ドキュメンテーション ライター

 

「テクニカル ライターとして、テクニカルライターは顧客の代言者であるというのが私の信念でした。 このため、システムの使用法を学ぼうとする人の立場に、自分を常に置きました。 そして、少しずつマニュアルを書きました。VMSドキュメンテーショングループは、 1977年の5人から、1987年には45人に成長し、マニュアルセットは9,000ページから 20,000ページになっていました。それは大きな成果でした。」

 
トップへ 戻る   次のページへ
印刷用画面へ印刷用画面へ
プライバシー ご利用条件・免責事項 ウェブマスターに連絡