５．脱IBM
（１）IBM-日立の和解合意書の後で
（２）工場長が依頼に来所
（３）苦難・苦闘の13ヶ月の始まり
（４）我々のミッション
（５）新聞工程
（６）作業開始
（閑話休題１）
（閑話休題２）
（１）IBM-日立の和解合意書の後で
米国では1981年１月１日からソフトウェアの著作権が守られることになり日本においても同様の法律的整備が進められていた．IBM産業スパイ事件以降は知的財産権保護の動きが通産，文部の両省において活発になった．IBM産業スパイ事件により日立ではビジネスの要となるＯＳを含めたコンパイラ，データベース，通信関連ソフトなど，基本ソフトを全面的に見直す必要があった．特にIBMから指定プログラム(DP：Designated Programs)についてはゼロベースで開発し直す必要に迫られていた．この取り決めは1983年10月6に米国民事訴訟の終結として新聞などに「IBM-日立和解合意書」として翌日の夕刊で報道された．その内容につては日立・IBMの民事訴訟の和解と秘密協定のところで既に述べた通りである．
日立にとって事件後に最も重要だったのは，多くの指定プログラムを早急にゼロベースで開発する，つまり脱IBMを達成しなければならないことであった．上記のようにDPは多岐に渡っていた．特に収益の柱でありコンピュータシステムの中心的存在であるＯＳならびに言語処理系（コンパイラ）の脱IBMは最も重要な案件であった．私が深く関係していたのは，収益の柱となっている大型コンピュータ用ＯＳ：VOS3/SP（実記憶32MBサポート）対応の製品(VOS3/SP21)そして将来を繋ぐIBMのMVS/XAに対応する拡張アドレッシングを実現するVOS3/ES1 (Enterprise System 1)の開発であり，この２製品の脱IBMは急務の課題であった．コンピュータ事業部は1983年11月に脱IBMとなるVOS3/SP21(System Product 21)とVOS3/ES1を1985年３月に配布することを報道する．この報道は1983年10月6日に日立とIBMの和解が成立した報道の約１ヶ月後になされている．脱IBMは秘密協定の中でIBMから要求されていたギリギリの期日であった．
和解合意書・秘密協定締結後の数ヶ月間にコンピュータ事業部の幹部がどのような意思決定をしたのか不明である．想像するに，秘密協定に基づくIBMへのペナルティ的な支払い額を最小限に留め，また指定プログラムの再開発を最短にする検討などが主たる検討事項であり事業部間での激しいやりとりがあったのだろう．この間にソフトウェア工場では秘密協定の条件を踏まえた工程見積もりを各部署で練り，相互に調整をとったと思われる．
＜先頭へ＞
＜ページの最後へ＞
（２）工場長が依頼に来所
1983年11月初旬，ソフトウェア工場・不破工場長がシステム開発研究所の川崎淳所長に面会に来た．その目的は，脱IBMのために力を貸して欲しいという要請であった．脱IBMを実現すると公に発表した直後のことである．工場が最も弱っているのは，一番重要なIBMのMVS/XAに相当する31ビットアドレッシングを可能とするＯＳの開発であり，この責任者として吉澤康文主任研究員に担当してもらいソフトウェア工場にて拡張アドレッシングを実現するVOS3/ES1の開発に従事して欲しいというものだった．
早速，川崎所長は石原孝一郎部長を通して私にこのことを伝えた．その後，早急に工場へ長期派遣の手続きがなされた．長期派遣の開始は1983年12月5日であった．日立は人事関係の期日が月の5日と20日であり（おそらく経理の期日），通常は給与支給などの都合からか20日付けが多かったが，このような緊急の事態では5日付けでも移動などが行われた．ということで，年も迫った12月5日，私と部下合わせて４名がソフトウェア工場・システムプログラム部に長期派遣となった．
＜先頭へ＞
＜ページの最後へ＞
（３）苦難・苦闘の13ヶ月の始まり
当時，ソフトウェア工場はJR戸塚駅の前にあった．駅からは歩いて3分程度の場所である．派遣となったメンバーは；当時，木下俊之君（東京工業大学卒後，東京大学大学院修了；当時30歳），新井利明君（早稲田大学大学院修了；当時29歳），そして櫻庭健年君（東北大学大学院修了；当時25歳-この年の新入社員）であった．派遣された時はIBMとの和解条件により開発チームのシャッフルが行われた直後で，ソフトウェア工場内は混沌としており，作業所はにわか作りであった．雪の舞うどんよりとした寒い日だったことを覚えている．システムプログラム部は設計と呼ばれ工場の５階を居室にしていた．この工場では最も地位の高い部であり一番優秀な人材が揃っていた．窓の下には新しい建家の土台作りが行われており雪で工事中の機材などが白くなっており殺風景な風景を見せていたのを覚えている．この建屋の完成は翌年の秋であったと記憶する．その完成をみて，システムプログラム部はやはり最上階である４階建の最上階に引っ越しをした．
初日は工場長，システムプログラム部長（Mr.T.Y.：IBM産業スパイ事件ではFBIから国外の容疑者として指名手配されていた一人である）への挨拶，そして我々が所属する課長の柴宮実主任技師らとの打ち合わせなどをした．その後，森啓倫主任が部下に命じてIBMのPublic Domainとされている最新のMVSのソースプログラムのリストを我々の机の上に高々と積み上げた．我々の担当する部分はメモリ管理部分であり今回の開発の要となる機能である．
メモリ管理は大きく分けると以下の３つの部分で構成されている．
(A) 実記憶管理（RSM: Real Storage Manager）
(B) 補助記憶管理（ASM: Auxiliary Storage Manager）
(C) 仮想記憶管理（VSM: Virtual Storage Manager）
この中で最大の拡張が必要となるのは実記憶管理（RSM)であり，新井と吉澤が主として担当することにした．補助記憶管理（ASM)は大きなプログラムサイズであったが木下研究員にお願いした．そして変更部分が最も少ないと思われた仮想記憶管理（VSM)は協力会社である日立ソフトウェアエンジニアリング（日立SK）の人達にお願いした．これらの全プログラムは吉澤が責任を持って開発することになっていたので，SKの人達も吉澤の下で働くことになっていたが，派遣法の下での命令指揮権に関する管理体制がやや複雑で悩みがあった．
森啓倫主任（慶應大学卒）はソースコードのリストが搬入完了すると私に，「課長（吉澤）これらのプログラムを31ビット版で動くようにしてください」と言った．私は「これ以外の資料はないの？」と聞いたが，森主任は「ありません．協定によって捨てたと思ってください」との返事であった．和解合意書にある通り，IBMの秘密情報は破棄したことになっているのであった．
＜先頭へ＞
＜ページの最後へ＞
（４）我々のミッション
工場への派遣の際に具体的な作業内容は不明であった．漠然と現在のVOS3/SPをIBMのMVS/XAのように31ビット拡張を実現させるだけで良いと思っていた．大筋はこれで間違いはないのであるが実はビジネスの中心は，まだできてもいないMVS/XA製品の対応にあるのではなく，現在多くのビッグユーザに納入しているVOS3/SPの脱IBM開発が最重要なのであった．そもそもこのIBM産業スパイ事件の発端は31ビット拡張の3081K用の各種情報入手と思われているが，それも事実に違いないが，IBMからすると著作権の米国での成立（1981年１月１日より）を見越して著作権表示をしたMVS/SPを無断使用している日本企業の富士通・日立を絶対に許さないと判断していたはずだ．IBM Sysems Journalによれば，MVSはIBMにとって過去最大のProgramming Effortsであると述べており，莫大な費用を掛けて開発した製品なのである．特に日本市場において日本IBMが1981年初頭に顧客に配布し始めたMVS/SPと同等の機能をほぼ同時に日本のメーカーが配布したことにIBMは強い怒りと危機感を感じたのだと思う．
以上から，我々に課されたミッションは２つであった．
(A) 仮想記憶と実記憶の両方を31ビットアドレッシング可能とするＯＳの開発
＜VOS3/ES1において31ビットと24ビットのアドレッシングモードを同時に実行可能とする両モード機能(Bimodal Operation)を実現することである＞
(B) 仮想記憶領域は16MBまでの空間サポートであっても利用可能となった実記憶を32MB（あるいは64MB）まで拡張できる実記憶拡張を実現するVOS3/SP21の開発
そこでこの２つのＯＳ開発を同時に満たすような方法を考案した．それは，アドレス幅（仮想記憶部分は31/24ビット，実記憶の部分は31/24−26ビット）を意識することのないプログラム記述方法の工夫である．具体的には，アドレス幅の部分は論理的な表現とするマクロ命令化しコンパイル時の指定により具体的なビット幅を指定する方法である．このアイデアの実現は新入社員の櫻庭君にお願いしたところ見事に実現してくれた．これは一つのソースプログラムで２つのＯＳを同時に開発できるためプログラムの生産性を飛躍的に向上させる結果となった．
上記２つのミッションは必要最低限の仕事である．研究所の人間にとっては実際の製品にタッチするような機会は今迄ほとんどなかった．工場からの依頼研究では，研究所で考え提案するアイデアは，仮に研究所で実際のＯＳに試作的に組込み，その効果のあることを示したとしてもそのまま製品化されることはほとんどなかった．理由は明らかで工場は常に「IBMがやっていないことをあえてやる必要はないし利益に繋がらない」ということでほとんどのケースで拒否していた．つまりＯＳの研究とは当時，IBMが新機能をアナウンスした時の解説者としての役割を果たすことであり，そのために日頃はマスターベーション的な自己学習をすれば良いと当時の（ソフト）工場長は青山の技術研修所で（シ研）の上級研究員研修の場で講演していた．しかし，今回は自分達のアイデアがそのままダイレクトに製品化される二度とない千載一遇の機会を得たのである．
＜先頭へ＞
＜ページの最後へ＞
このことからIBMのMVS/XAの最新機能にまでに追いつき，できればそれを追い越したいと思い，予てより依頼研究などで（ソフト）に提案していた機能をなるべく多くこの製品へ関与できる機会に実現することにした．それらは以下の通りである．
(C) セグメント境界緩和方式（CSBR: Common Segment Boundary Release）この提案は小平光彦主任技師からの要求のあった機能であった．
＜従来24ビットのマシンではセグメントサイズの単位が4KB（つまり１ページ単位）であったが3081Kと同等のマシンではメモリ拡張のために１MB単位と大きくなった．このような区切りをバウンダリと呼ぶが，既存の24ビット下で動作する多くのソフトウェアにとってこのハードウェアの制約はジョブ固有領域の縮小となるためプログラムの拡張やそれまでのプログラムが動作できなくなる可能性がある．そこで，この実現にはいささか面倒なテクニックを要すが，なんとかこの問題をメモリ管理で解決する方法を考案しCSBRを実現することにした．VOS3/ES1は我々がこのプロジェクトで開発した31ビット版のＯＳであるが，日経コンピュータに紹介された時，CSBRはIBMにない特徴として紹介された．なおCSBRは私が付けた名前である．後に戦略特許賞を貰うことになる）
(D) オンデマンドスワッピング方式；
実記憶を節約し有効利用するためにジョブ領域全体を外部記憶にオンデマンドで入れ替えする方法である．この有効性については，予てより情報処理学会への論文などで示してあったが実現されていなかった．私の学位論文の一つの重要なテーマと位置づけられている．このアイデアは東京大学大型計算機センターの1000台のTSS端末をサポートするプロポーザルを書く際に得られた知見である．ページングもスワッピングもオンデマンドで行うべきであるというのが私の哲学である．
(E) ワンステージスワップ（One Stage Swapping）方式；
これはスワップ処理を迅速に行う方法であり，ジョブ固有領域とジョブ固有領域のＯＳ管理部分LSQA（Local System Queue Area）と16MB以上のメモリ領域にあるXLSAQを並列して外部記憶に入出力する方法である． 31ビットモードではＯＳ管理部分が拡大されるためスワップに要する時間は無視できずスワップ用のディスクが異なる入出力パスである場合はジョブ固有領域と(LSQA+XLSQA)領域が並行（オーバラップ）して同時に入出力されスワップ時間の短縮となる．
(F) ページテーブル・ページング；
巨大な31ビット空間を実現するためにジョブの管理領域は拡大された．具体的にはページテーブルが最大８MBにもなりこれらの領域は従来，実記憶上に従来は常駐していた．24ビットアドレッシングの時はそれほど大きな領域ではなかったので問題はなかったが仮想記憶のスケール拡大効果により無視できない．そこで，この領域もページングの対象とし実記憶の節約を図ることにした．この複雑なアルゴリズムの実現は新井君が見事に成し遂げてくれた．
(G) 実記憶マイグレーション方式；
従来は16MBあるいは32MBまでの実記憶領域であったがVOS/ES1では2GBの実記憶を利用可能にする必要がある．ところが，当面は拡張チャネルがサポートされないため入出力チャネルは主記憶の16MB以下の領域に対してのみデータ転送を行う．このような状況では16MB以下の実記憶領域が入出力領域により占有されてしまいかねない．この問題を解決するために，実記憶の16MB以下の領域に配置する必要が無くなった領域を積極的に16MB以上の領域に積極的に移動する（migration）アルゴリズムを開発することにした．
これらのアイデアを設計の段階から作り込み実現すると決心した．上記のページテーブル・ページングと実記憶マイグレーション方式の実現は新井利明君にお願いしたがこれらを見事に完成してくれた．それ以外は吉澤が担当した．
余談だが，これらの機能を入れた設計書が完成したところ，現場のプロジェクト・マネージャ（主任クラス）らからとんでもないことを言われた．「吉澤課長，31ビット拡張だけすれば良いので頼まれてもいない機能を作りこむなんて無謀ですよ．自分の首を締めることになりますよ．だから，今のうちにドロップ（設計から外す）したほうが良いと思います．」このようなことを云う設計のエリートが日立に居るのか？と驚いた次第である．日立に入社して以来，日立は野武士精神で技術開発にチャレンジするようにと，と何度も言われていたのだが，工場の現場がこの為体（テイタラク）では将来がないと思った．
＜先頭へ＞
＜ページの最後へ＞
（５）新聞工程
1983年10月6日に日立がVOS3/ES1とVOS3/SP21を1985年3月に出荷すると報道されていたことはほとんど気にしていなかった．自分がその当事者になるとは思ってもみなかったからであろうか．工場の課長，主任クラスも同じでこの期日を気にしていなかったように思える．工場では当初，VOS3/ES1の開発にはほぼゼロベースの出発でありどんなに急いでも1.5年は必要と見ていた．しかし，我々が12月5日に長期派遣となってから数日後の新聞記事にはこともあろうか「日立製作所はIBMに対して脱IBMを1984年12月31日に完了する」と三浦武雄副社長*が日本IBMの副社長との共同記者会見の場で発表した．この時の新聞写真に写っていた三浦さんの元気のない姿は忘れられない．新聞を持ち寄り当日の朝の職場は大騒ぎであった．工程管理のプロマネはあきらめ顔であった．
しかしMr.T.Y.部長からは「できるできないではなく，やるしかないだろう」ということで，1984年12月31日を工程完了として工程作りを命じた．この工程作りでは各部署がギリギリの積上げをして意見をだした．そこでは，
★設計部は担当者がすべて素人であり，設計にはこれからのPublic Domainの調査を含めないとならないため，最低４ヶ月は必要と主張
★設計部はテストプログラムも最初から作る必要がある．この単体テストとプログラムを連結して疎通テストするだけでも５ヶ月は必要となると主張
そうは言っても残り時間は１年と数日しかない．なにしろ後ろが切られているのだ．工場長からは設計部，検査部が共に譲って工程短縮し臨戦態勢を取って欲しいとの命令が出た．三浦副社長が1984年12月31日に脱IBMすると言ったのは製品出荷の90日前にinspectionを受けねばならないという和解合意書とソフトウェア秘密契約におけるVOS3/SPを日立が顧客に提供できる契約期間切れとの兼ね合いからであろう．このinspectionではIBMの秘密情報が含まれていないか，つまりcontamination(汚染)が無いかを判定する期間である．
（注）
三浦武雄*
:
システム開発研究所の初代所長でアナログコンピュータの専門家と聞いていた．私が研究員（俗に云う主任）時代には時折所長室に呼ばれては怒鳴られ，とても怖い人に思えた．しかしいろいろなことを怒鳴り散らすが，多くの場合は自分自身に対する腹立たしさを相手にぶつけているのであって，怒鳴ったことを根に持つ人ではなくとても明るい性格の人であった．1995年9月のある日，日立を退社する際に御茶ノ水本社の副社長室にご挨拶に行った．ビルの最上階で東南の角地の明るい窓だらけの部屋だった．三浦さんは「君ね，この部屋は皆がWindow 95って言うんだよ！明るいだろう」と朗らかに言っていた．私は日立を9月いっぱいで退社することを告げ，その直後に，少し嫌味に「私は（中研）の第７部所属で（シ研）発足と同時に転勤となりました．（中研）では三浦さんの第６部でなかったので，結局はこのように外に出て行かざるを得ません」というと，「君！そう言うなよ！ アッハハ・・・」．つまり，（シ研）というところは（中研）第６部出身者で主要な人事が固められていたので（中研）時代の敵対関係にあった第７部の人間に冷や飯を食わせていたのバレバレだったのだ．この結果，何人もの優秀なコンピュータ技術者が日立から大学教員に転出したと思っている．2012年２月に三浦さんは故人となられた．ご冥福を祈る．
＜先頭へ＞
＜ページの最後へ＞
そこで工程表が直ちに作られて説明されたがこの工程を守れるとは誰も思っていなかった．その工程は以下の通りであった．
（Ａ）調査・方式検討：〜’83/12 残り数日
（Ｂ）設計書作成（概念設計，機能設計，構造設計，詳細設計，検査・テスト仕様書，など）：’84/1-2 ２ヶ月間
（Ｃ）コード化（プログラム作成）：’83/3 ２週間
（Ｄ）コンパイル（フラグ取り）とテスト： 〜’84/4 NIP疎通約６週間
（Ｅ）全モジュールの単体テスト； 〜’84/6 約２ヶ月間
（Ｆ）検査部での総合テスト； 〜’84/12末 ６ヶ月間
我々にとってはすべてが初めての経験であり最初の調査・方式検討の時間があまりにも短すぎたことに不安を抱いた．実際には上記の（Ａ）と（Ｂ）の区別は無かったので調査や方式検討は設計書を作りながら進めることにした．設計書は一部分担したがほぼすべてを吉澤が担当した．概念設計は全体的な設計の方向性を書くだけであるが大方針であるため神経を使う．この方針を基にして実現すべき機能の詳細を詰める必要がある．この機能を実現するための各機能コンポーネントが構造設計である．構造というのはプログラムモジュール（ひとつのまとまった機能を実現する手続きやそのデータ構造など）の処理手順（ロジック）の概略ならびにその手順のための入力情報，処理結果の出力情報などを明確にすることである．つまりモジュール間のインターフェースを定義することになる．詳細設計では各モジュールの詳細な手順を記述しなければならないしまた，制御ブロック（データ構造）内の状態変数との関係を明確化する必要がある．
最後の詳細設計では各モジュールのアルゴリズムの記述とその動作確認用のテストプログラムの仕様を記述していく．通常，一つのモジュールは複数の機能を担うため，その各々が正しく動作しているかをチェックするための単体テストのプログラム仕様を作る．テストプログラムは一般的に複数の処理の確認をすることも可能なので，モジュールの各処理とテストプログラムの各チェック項目とのマトリックスを作成してPCL(Program Check List)を作成し各処理を網羅的に確認できるだけのテストプログラムを作る必要がある．もちろん確認方法も記述しておかねばならない．
上記のスケジュールから見て分かる通り，ソフトウェア開発の要は検査に重点がおかれている．特にＯＳはコンピュータシステムの要となる巨大なソフトウェアであるため，その信頼性はシステムの稼働率に大きな影響を与える．汎用大型コンピュータは一般的に企業の情報中枢的な役割を果たしている(mission critical)ので，信頼性はその企業経営を左右すると言っても過言ではない．アプリケーションプログラムの信頼性も重要であるがＯＳの信頼性はそれ以上に高くなくてはならない．汎用ＯＳの下ではどんなプログラムが動いても障害が起きてはならないのである．とはいえ，ＯＳも一つのプログラムでありバグをゼロにはできない．製品寿命の中でバグが露呈しなければ良いのだが，不幸にしてバグが露呈してもシステムダウンに繋がらない工夫が必要で，Fale Softの設計思想が徹底されねばならないし，また，バグの早期検出を可能にする仕組みも必要である(falt locating)．現在でもソフトウェアの正当性を誰も証明などできないのである．これができればノーベル賞確実であり，かつ億万長者になれること間違いなしである．
＜先頭へ＞
＜ページの最後へ＞
（６）作業開始
当時IBMのソースコードはPLS(Programming Language System)というPL/1ライクな言語で記述されていた．PL/1については私の入社時の少し前にIBMから新言語として提供されていた．当時，技術科学計算はFORTRAN,事務処理はCOBOLが主流であったが，IBMは汎用的な言語としてPL/1を発表していた．日本IBMから（中研）に転職した渡辺坦さん（日立から電通大・教授に異動したコンパイラ研究者）はPL/1の仕様を日立に紹介した人物である．このPL/1を（中研）では中田育男さん（日本のコンパイラ草分けの技術者でHARPというFortranをHITAC 5020に開発した．日立から筑波大学教授，図書館情報大学，法政大学教授などを勤める）がそのサブセットとなるシステム記述言語をPL/1Wとして開発していた．このためPL/1Wの使用経験からPLSのプログラムを読むのに困難はなかった．
しかし問題はプログラムの量が極めて膨大であること，また，IBMのソースコードなど今まで見たこともなかったため，全くの初心者と同じであった．机の上に積上げられたプログラムのリストから一体，どのようなプログラム構成になっているのか，つまり文章によるドキュメントが全く無い状況では機能構造を理解する手掛りが全く無い．情報はこれらのプログラムリストだけと言うのであるから仕方なしに順番にコードを読みそれらの制御の流れをフローチャートとして書くことから始めた．当時はフローチャートに代わるPAD (Problem Analysis Diagram)図が日立では推奨されていた．これは，（中研）の
二村良彦
さん（北海道大学卒．部分計算で有名に．後に早稲田大学・教授，ハーバード大学など．卓球が上手）らが発案した構造化プログラミングの手法である．日立ではIBMのPLSと同様のプログラミング言語としてHPLを使用していたが，PLSと全く同じ機能を持っていると云われていた．HPLはIBMのPLSと同じか否かは極めて重要かつ微妙な問題なので深くは言及しないことにする．
＜先頭へ＞
＜ページの最後へ＞
（閑話休題１）
1984年11月末，富士通—IBMの和解契約に基づく富士通の製品検査(inspection)をIBMは実施した．その結果， IBMは富士通の互換ソフトウェアに大量のIBMコードのコピーが見つかり，悪質であり富士通との和解契約違反であるとして通産省と富士通にこれを申し入れた．その後，12月末に，IBMは富士通のシステム開発言語SPL(System Programming Language)がIBMのPLSに酷似しているとして問題視し富士通に通告した．システム記述言語のような生産治工具に著作権侵害のような事実が判明することはメーカーにとって致命的であるが，まだ日本にはソフトウェアの著作権の法的保護はなく，成立しても言語は対象外であった．富士通はSPLを独自開発し，IBMのSPLには一切接触していないと主張している．しかし，IBMは強硬な態度を取り続ける．交渉の結果，1985年7月11日IBMはアメリカ仲裁協会(AAA)に仲裁に富士通を提訴し仲裁が始まる．その結果1987年9月15日にAAAから「命令」と「意見書」が出され一応の決着を見る（最終裁定は1988年11月29日になる）．AAAはソフトウェアの著作権についてはIBMの意に反して一切言及することなく，富士通，IBMのユーザ保護の立場を守り，かつ自由な市場競争を行うべきであるという立場で仲裁にあたった．後に富士通はSPLから日本語使用を可能とするLDLという言語に発展？させる．IBMは製品検査でSPLの生成するオブジェクトプログラムがIBMのオブジェクトと類似であることから，SPLに疑惑を持ったのであろう．この詳細は９．引用資料の３．「雲の果に」に述べられている．
我々が最初にやるべきことはPublic Domain版のMVSの調査（つまり解読）である．どのような考えでMVSが作られているのかを知り，これを31ビットアドレッシングにどのようにすれば拡張できるのかを探ることである．さらにMVS/SPのように実記憶の拡張をどうすれば可能になるのかも同時に探ることである．時間はほとんど無い状態であることから少し焦りを感じていた．
また工場における設計書の作成規則・基準に対する知識も無かった．これらのルールや作成した後の検査部でのチェック，その対策なども同時に知る必要があった．研究所では知り得ないことを工場の現場に突然組込まれて，しかも最も重要な部分の仕事を果たさねばならなかったのである．
必死に手当たり次第にMVSのプログラムを読み，これらをPAD図として書きプログラムロジックを何度も何度も見つめては理解を深めて行った．毎日，朝から夜の10時ごろまでこのような作業を続けているとおぼろげにではあるがメモリ管理の概念，プログラム構造，機能分割，モジュール間インターフェース，などが理解できるようになってきた．これは英文読解でも難解な文章を何度も繰り返して眺めているうちに理解できるようになるのに似て，眼光紙背に徹すではないが，設計思想を徐々に理解できるようになっていった．PAD図も400枚ぐらいを書いたと思う．私の担当した主たる部分は実メモリ管理のスワッピング部分であるが，実は東京大学大型計算機センターへのプロポーザルを書くために，その性能評価をした折，MVSのスワッピングは大きな性能上のボトルネックであることは知っていた．正確な数字は忘れたが，スワップイン・アウトだけで400万命令以上を費やしていたと思う．しかし，その具体的なプログラムロジックを知ることはなかった．スワッピングは多重プログラミングのコントロールにおける重要な機能であり，ジョブ空間を2次記憶（ディスクなどの補助記憶装置）に退避（swap out），回復（swap in）する機能である．
＜先頭へ＞
＜ページの最後へ＞
（閑話休題２）
ジョブ空間は各ジョブのプログラムやデータ領域のことであり仮想記憶領域である．その一部に実記憶が割り付けられているので，スワップアウトの際の基本的な操作はジョブ空間に割り付けられている実ページを2次記憶（この装置上のファイルをページングファイルあるいはスワッピングファイルと呼ぶ）上に退避する．スワップインはその逆である．スワッピングの難しさはジョブ領域上の仮想記憶の状態がどのようになっていてもスワップアウトし，スワップイン時に矛盾の無い動作を保証することにある．ジョブ固有領域には一般的な入出力領域があり，入出力の起動はされていても入出力が完了していないケースもある．また，一部の仮想記憶領域がページング入出力中であっても同様の保証をすることや，特殊なケースであるが，仮想記憶の一部をページングの対象外とするPGFIX(Page Fix)されている部分，あるいはその処理中である場合の保証も含まれる．さらに面倒なのはV=Rジョブといって仮想記憶のメモリ番地と実記憶の番地が一致していなければならない特殊な入出力を行っている領域のスワップイン/アウトの処理などがロジックをさらに面倒にしている．
スワップ操作について：東京大学大型センターのプロポーザルを作成する仕事の時は，センター長はDennis Richieの開発した「プログラミング言語C」の翻訳で有名な故
石田晴久
先生であった．東京大学からのバッチ処理の性能に関する注文はFortranのSTOP/ENDジョブ（つまり始めと終わりしかない仕事で中身はゼロ）を一時間に何件処理できるかというスループットであった．当時，FortranのSTOP/ENDジョブはせいぜい500万命令であった．これに比べると，SWAP操作は大きなオーバヘッドであることが分かる．石田先生は2009年にお亡くなりになった．お話の上手な先生であった．
＜先頭へ＞
＜戻る＞
＜目次へ＞
＜次＞
脱IBM VOS3/ES1開発
Copyrights all rights reserved, Y.Yoshizawa 2016-2017
（１）IBM-日立の和解合意書の後で
（２）工場長が依頼に来所
（３）苦難・苦闘の13ヶ月の始まり
（４）我々のミッション
（５）新聞工程
（６）作業開始
（閑話休題１）
（閑話休題２）
（１）IBM-日立の和解合意書の後で
米国では1981年１月１日からソフトウェアの著作権が守られることになり日本においても同様の法律的整備が進められていた．IBM産業スパイ事件以降は知的財産権保護の動きが通産，文部の両省において活発になった．IBM産業スパイ事件により日立ではビジネスの要となるＯＳを含めたコンパイラ，データベース，通信関連ソフトなど，基本ソフトを全面的に見直す必要があった．特にIBMから指定プログラム(DP：Designated Programs)についてはゼロベースで開発し直す必要に迫られていた．この取り決めは1983年10月6に米国民事訴訟の終結として新聞などに「IBM-日立和解合意書」として翌日の夕刊で報道された．その内容につては日立・IBMの民事訴訟の和解と秘密協定のところで既に述べた通りである．
日立にとって事件後に最も重要だったのは，多くの指定プログラムを早急にゼロベースで開発する，つまり脱IBMを達成しなければならないことであった．上記のようにDPは多岐に渡っていた．特に収益の柱でありコンピュータシステムの中心的存在であるＯＳならびに言語処理系（コンパイラ）の脱IBMは最も重要な案件であった．私が深く関係していたのは，収益の柱となっている大型コンピュータ用ＯＳ：VOS3/SP（実記憶32MBサポート）対応の製品(VOS3/SP21)そして将来を繋ぐIBMのMVS/XAに対応する拡張アドレッシングを実現するVOS3/ES1 (Enterprise System 1)の開発であり，この２製品の脱IBMは急務の課題であった．コンピュータ事業部は1983年11月に脱IBMとなるVOS3/SP21(System Product 21)とVOS3/ES1を1985年３月に配布することを報道する．この報道は1983年10月6日に日立とIBMの和解が成立した報道の約１ヶ月後になされている．脱IBMは秘密協定の中でIBMから要求されていたギリギリの期日であった．
和解合意書・秘密協定締結後の数ヶ月間にコンピュータ事業部の幹部がどのような意思決定をしたのか不明である．想像するに，秘密協定に基づくIBMへのペナルティ的な支払い額を最小限に留め，また指定プログラムの再開発を最短にする検討などが主たる検討事項であり事業部間での激しいやりとりがあったのだろう．この間にソフトウェア工場では秘密協定の条件を踏まえた工程見積もりを各部署で練り，相互に調整をとったと思われる．
＜先頭へ＞ ＜ページの最後へ＞
（２）工場長が依頼に来所
1983年11月初旬，ソフトウェア工場・不破工場長がシステム開発研究所の川崎淳所長に面会に来た．その目的は，脱IBMのために力を貸して欲しいという要請であった．脱IBMを実現すると公に発表した直後のことである．工場が最も弱っているのは，一番重要なIBMのMVS/XAに相当する31ビットアドレッシングを可能とするＯＳの開発であり，この責任者として吉澤康文主任研究員に担当してもらいソフトウェア工場にて拡張アドレッシングを実現するVOS3/ES1の開発に従事して欲しいというものだった．
早速，川崎所長は石原孝一郎部長を通して私にこのことを伝えた．その後，早急に工場へ長期派遣の手続きがなされた．長期派遣の開始は1983年12月5日であった．日立は人事関係の期日が月の5日と20日であり（おそらく経理の期日），通常は給与支給などの都合からか20日付けが多かったが，このような緊急の事態では5日付けでも移動などが行われた．ということで，年も迫った12月5日，私と部下合わせて４名がソフトウェア工場・システムプログラム部に長期派遣となった．
＜先頭へ＞
＜ページの最後へ＞
（３）苦難・苦闘の13ヶ月の始まり
当時，ソフトウェア工場はJR戸塚駅の前にあった．駅からは歩いて3分程度の場所である．派遣となったメンバーは；当時，木下俊之君（東京工業大学卒後，東京大学大学院修了；当時30歳），新井利明君（早稲田大学大学院修了；当時29歳），そして櫻庭健年君（東北大学大学院修了；当時25歳-この年の新入社員）であった．派遣された時はIBMとの和解条件により開発チームのシャッフルが行われた直後で，ソフトウェア工場内は混沌としており，作業所はにわか作りであった．雪の舞うどんよりとした寒い日だったことを覚えている．システムプログラム部は設計と呼ばれ工場の５階を居室にしていた．この工場では最も地位の高い部であり一番優秀な人材が揃っていた．窓の下には新しい建家の土台作りが行われており雪で工事中の機材などが白くなっており殺風景な風景を見せていたのを覚えている．この建屋の完成は翌年の秋であったと記憶する．その完成をみて，システムプログラム部はやはり最上階である４階建の最上階に引っ越しをした．
初日は工場長，システムプログラム部長（Mr.T.Y.：IBM産業スパイ事件ではFBIから国外の容疑者として指名手配されていた一人である）への挨拶，そして我々が所属する課長の柴宮実主任技師らとの打ち合わせなどをした．その後，森啓倫主任が部下に命じてIBMのPublic Domainとされている最新のMVSのソースプログラムのリストを我々の机の上に高々と積み上げた．我々の担当する部分はメモリ管理部分であり今回の開発の要となる機能である．
メモリ管理は大きく分けると以下の３つの部分で構成されている．
(A) 実記憶管理（RSM: Real Storage Manager）
(B) 補助記憶管理（ASM: Auxiliary Storage Manager）
(C) 仮想記憶管理（VSM: Virtual Storage Manager）
この中で最大の拡張が必要となるのは実記憶管理（RSM)であり，新井と吉澤が主として担当することにした．補助記憶管理（ASM)は大きなプログラムサイズであったが木下研究員にお願いした．そして変更部分が最も少ないと思われた仮想記憶管理（VSM)は協力会社である日立ソフトウェアエンジニアリング（日立SK）の人達にお願いした．これらの全プログラムは吉澤が責任を持って開発することになっていたので，SKの人達も吉澤の下で働くことになっていたが，派遣法の下での命令指揮権に関する管理体制がやや複雑で悩みがあった．
森啓倫主任（慶應大学卒）はソースコードのリストが搬入完了すると私に，「課長（吉澤）これらのプログラムを31ビット版で動くようにしてください」と言った．私は「これ以外の資料はないの？」と聞いたが，森主任は「ありません．協定によって捨てたと思ってください」との返事であった．和解合意書にある通り，IBMの秘密情報は破棄したことになっているのであった．
＜先頭へ＞
＜ページの最後へ＞
（４）我々のミッション
工場への派遣の際に具体的な作業内容は不明であった．漠然と現在のVOS3/SPをIBMのMVS/XAのように31ビット拡張を実現させるだけで良いと思っていた．大筋はこれで間違いはないのであるが実はビジネスの中心は，まだできてもいないMVS/XA製品の対応にあるのではなく，現在多くのビッグユーザに納入しているVOS3/SPの脱IBM開発が最重要なのであった．そもそもこのIBM産業スパイ事件の発端は31ビット拡張の3081K用の各種情報入手と思われているが，それも事実に違いないが，IBMからすると著作権の米国での成立（1981年１月１日より）を見越して著作権表示をしたMVS/SPを無断使用している日本企業の富士通・日立を絶対に許さないと判断していたはずだ．IBM Sysems Journalによれば，MVSはIBMにとって過去最大のProgramming Effortsであると述べており，莫大な費用を掛けて開発した製品なのである．特に日本市場において日本IBMが1981年初頭に顧客に配布し始めたMVS/SPと同等の機能をほぼ同時に日本のメーカーが配布したことにIBMは強い怒りと危機感を感じたのだと思う．
以上から，我々に課されたミッションは２つであった．
(A) 仮想記憶と実記憶の両方を31ビットアドレッシング可能とするＯＳの開発
＜VOS3/ES1において31ビットと24ビットのアドレッシングモードを同時に実行可能とする両モード機能(Bimodal Operation)を実現することである＞
(B) 仮想記憶領域は16MBまでの空間サポートであっても利用可能となった実記憶を32MB（あるいは64MB）まで拡張できる実記憶拡張を実現するVOS3/SP21の開発
そこでこの２つのＯＳ開発を同時に満たすような方法を考案した．それは，アドレス幅（仮想記憶部分は31/24ビット，実記憶の部分は31/24−26ビット）を意識することのないプログラム記述方法の工夫である．具体的には，アドレス幅の部分は論理的な表現とするマクロ命令化しコンパイル時の指定により具体的なビット幅を指定する方法である．このアイデアの実現は新入社員の櫻庭君にお願いしたところ見事に実現してくれた．これは一つのソースプログラムで２つのＯＳを同時に開発できるためプログラムの生産性を飛躍的に向上させる結果となった．
上記２つのミッションは必要最低限の仕事である．研究所の人間にとっては実際の製品にタッチするような機会は今迄ほとんどなかった．工場からの依頼研究では，研究所で考え提案するアイデアは，仮に研究所で実際のＯＳに試作的に組込み，その効果のあることを示したとしてもそのまま製品化されることはほとんどなかった．理由は明らかで工場は常に「IBMがやっていないことをあえてやる必要はないし利益に繋がらない」ということでほとんどのケースで拒否していた．つまりＯＳの研究とは当時，IBMが新機能をアナウンスした時の解説者としての役割を果たすことであり，そのために日頃はマスターベーション的な自己学習をすれば良いと当時の（ソフト）工場長は青山の技術研修所で（シ研）の上級研究員研修の場で講演していた．しかし，今回は自分達のアイデアがそのままダイレクトに製品化される二度とない千載一遇の機会を得たのである．
＜先頭へ＞
＜ページの最後へ＞
このことからIBMのMVS/XAの最新機能にまでに追いつき，できればそれを追い越したいと思い，予てより依頼研究などで（ソフト）に提案していた機能をなるべく多くこの製品へ関与できる機会に実現することにした．それらは以下の通りである．
(C) セグメント境界緩和方式（CSBR: Common Segment Boundary Release）この提案は小平光彦主任技師からの要求のあった機能であった．
＜従来24ビットのマシンではセグメントサイズの単位が4KB（つまり１ページ単位）であったが3081Kと同等のマシンではメモリ拡張のために１MB単位と大きくなった．このような区切りをバウンダリと呼ぶが，既存の24ビット下で動作する多くのソフトウェアにとってこのハードウェアの制約はジョブ固有領域の縮小となるためプログラムの拡張やそれまでのプログラムが動作できなくなる可能性がある．そこで，この実現にはいささか面倒なテクニックを要すが，なんとかこの問題をメモリ管理で解決する方法を考案しCSBRを実現することにした．VOS3/ES1は我々がこのプロジェクトで開発した31ビット版のＯＳであるが，日経コンピュータに紹介された時，CSBRはIBMにない特徴として紹介された．なおCSBRは私が付けた名前である．後に戦略特許賞を貰うことになる）
(D) オンデマンドスワッピング方式；
実記憶を節約し有効利用するためにジョブ領域全体を外部記憶にオンデマンドで入れ替えする方法である．この有効性については，予てより情報処理学会への論文などで示してあったが実現されていなかった．私の学位論文の一つの重要なテーマと位置づけられている．このアイデアは東京大学大型計算機センターの1000台のTSS端末をサポートするプロポーザルを書く際に得られた知見である．ページングもスワッピングもオンデマンドで行うべきであるというのが私の哲学である．
(E) ワンステージスワップ（One Stage Swapping）方式；
これはスワップ処理を迅速に行う方法であり，ジョブ固有領域とジョブ固有領域のＯＳ管理部分LSQA（Local System Queue Area）と16MB以上のメモリ領域にあるXLSAQを並列して外部記憶に入出力する方法である． 31ビットモードではＯＳ管理部分が拡大されるためスワップに要する時間は無視できずスワップ用のディスクが異なる入出力パスである場合はジョブ固有領域と(LSQA+XLSQA)領域が並行（オーバラップ）して同時に入出力されスワップ時間の短縮となる．
(F) ページテーブル・ページング；
巨大な31ビット空間を実現するためにジョブの管理領域は拡大された．具体的にはページテーブルが最大８MBにもなりこれらの領域は従来，実記憶上に従来は常駐していた．24ビットアドレッシングの時はそれほど大きな領域ではなかったので問題はなかったが仮想記憶のスケール拡大効果により無視できない．そこで，この領域もページングの対象とし実記憶の節約を図ることにした．この複雑なアルゴリズムの実現は新井君が見事に成し遂げてくれた．
(G) 実記憶マイグレーション方式；
従来は16MBあるいは32MBまでの実記憶領域であったがVOS/ES1では2GBの実記憶を利用可能にする必要がある．ところが，当面は拡張チャネルがサポートされないため入出力チャネルは主記憶の16MB以下の領域に対してのみデータ転送を行う．このような状況では16MB以下の実記憶領域が入出力領域により占有されてしまいかねない．この問題を解決するために，実記憶の16MB以下の領域に配置する必要が無くなった領域を積極的に16MB以上の領域に積極的に移動する（migration）アルゴリズムを開発することにした．
これらのアイデアを設計の段階から作り込み実現すると決心した．上記のページテーブル・ページングと実記憶マイグレーション方式の実現は新井利明君にお願いしたがこれらを見事に完成してくれた．それ以外は吉澤が担当した．
余談だが，これらの機能を入れた設計書が完成したところ，現場のプロジェクト・マネージャ（主任クラス）らからとんでもないことを言われた．「吉澤課長，31ビット拡張だけすれば良いので頼まれてもいない機能を作りこむなんて無謀ですよ．自分の首を締めることになりますよ．だから，今のうちにドロップ（設計から外す）したほうが良いと思います．」このようなことを云う設計のエリートが日立に居るのか？と驚いた次第である．日立に入社して以来，日立は野武士精神で技術開発にチャレンジするようにと，と何度も言われていたのだが，工場の現場がこの為体（テイタラク）では将来がないと思った．
＜先頭へ＞
＜ページの最後へ＞
（５）新聞工程
1983年10月6日に日立がVOS3/ES1とVOS3/SP21を1985年3月に出荷すると報道されていたことはほとんど気にしていなかった．自分がその当事者になるとは思ってもみなかったからであろうか．工場の課長，主任クラスも同じでこの期日を気にしていなかったように思える．工場では当初，VOS3/ES1の開発にはほぼゼロベースの出発でありどんなに急いでも1.5年は必要と見ていた．しかし，我々が12月5日に長期派遣となってから数日後の新聞記事にはこともあろうか「日立製作所はIBMに対して脱IBMを1984年12月31日に完了する」と三浦武雄副社長*が日本IBMの副社長との共同記者会見の場で発表した．この時の新聞写真に写っていた三浦さんの元気のない姿は忘れられない．新聞を持ち寄り当日の朝の職場は大騒ぎであった．工程管理のプロマネはあきらめ顔であった．
しかしMr.T.Y.部長からは「できるできないではなく，やるしかないだろう」ということで，1984年12月31日を工程完了として工程作りを命じた．この工程作りでは各部署がギリギリの積上げをして意見をだした．そこでは，
★設計部は担当者がすべて素人であり，設計にはこれからのPublic Domainの調査を含めないとならないため，最低４ヶ月は必要と主張
★設計部はテストプログラムも最初から作る必要がある．この単体テストとプログラムを連結して疎通テストするだけでも５ヶ月は必要となると主張
そうは言っても残り時間は１年と数日しかない．なにしろ後ろが切られているのだ．工場長からは設計部，検査部が共に譲って工程短縮し臨戦態勢を取って欲しいとの命令が出た．三浦副社長が1984年12月31日に脱IBMすると言ったのは製品出荷の90日前にinspectionを受けねばならないという和解合意書とソフトウェア秘密契約におけるVOS3/SPを日立が顧客に提供できる契約期間切れとの兼ね合いからであろう．このinspectionではIBMの秘密情報が含まれていないか，つまりcontamination(汚染)が無いかを判定する期間である．
（注）
三浦武雄*
:
システム開発研究所の初代所長でアナログコンピュータの専門家と聞いていた．私が研究員（俗に云う主任）時代には時折所長室に呼ばれては怒鳴られ，とても怖い人に思えた．しかしいろいろなことを怒鳴り散らすが，多くの場合は自分自身に対する腹立たしさを相手にぶつけているのであって，怒鳴ったことを根に持つ人ではなくとても明るい性格の人であった．1995年9月のある日，日立を退社する際に御茶ノ水本社の副社長室にご挨拶に行った．ビルの最上階で東南の角地の明るい窓だらけの部屋だった．三浦さんは「君ね，この部屋は皆がWindow 95って言うんだよ！明るいだろう」と朗らかに言っていた．私は日立を9月いっぱいで退社することを告げ，その直後に，少し嫌味に「私は（中研）の第７部所属で（シ研）発足と同時に転勤となりました．（中研）では三浦さんの第６部でなかったので，結局はこのように外に出て行かざるを得ません」というと，「君！そう言うなよ！ アッハハ・・・」．つまり，（シ研）というところは（中研）第６部出身者で主要な人事が固められていたので（中研）時代の敵対関係にあった第７部の人間に冷や飯を食わせていたのバレバレだったのだ．この結果，何人もの優秀なコンピュータ技術者が日立から大学教員に転出したと思っている．2012年２月に三浦さんは故人となられた．ご冥福を祈る．
＜先頭へ＞
＜ページの最後へ＞
そこで工程表が直ちに作られて説明されたがこの工程を守れるとは誰も思っていなかった．その工程は以下の通りであった．
（Ａ）調査・方式検討：〜’83/12 残り数日
（Ｂ）設計書作成（概念設計，機能設計，構造設計，詳細設計，検査・テスト仕様書，など）：’84/1-2 ２ヶ月間
（Ｃ）コード化（プログラム作成）：’83/3 ２週間
（Ｄ）コンパイル（フラグ取り）とテスト： 〜’84/4 NIP疎通約６週間
（Ｅ）全モジュールの単体テスト； 〜’84/6 約２ヶ月間
（Ｆ）検査部での総合テスト； 〜’84/12末 ６ヶ月間
我々にとってはすべてが初めての経験であり最初の調査・方式検討の時間があまりにも短すぎたことに不安を抱いた．実際には上記の（Ａ）と（Ｂ）の区別は無かったので調査や方式検討は設計書を作りながら進めることにした．設計書は一部分担したがほぼすべてを吉澤が担当した．概念設計は全体的な設計の方向性を書くだけであるが大方針であるため神経を使う．この方針を基にして実現すべき機能の詳細を詰める必要がある．この機能を実現するための各機能コンポーネントが構造設計である．構造というのはプログラムモジュール（ひとつのまとまった機能を実現する手続きやそのデータ構造など）の処理手順（ロジック）の概略ならびにその手順のための入力情報，処理結果の出力情報などを明確にすることである．つまりモジュール間のインターフェースを定義することになる．詳細設計では各モジュールの詳細な手順を記述しなければならないしまた，制御ブロック（データ構造）内の状態変数との関係を明確化する必要がある．
最後の詳細設計では各モジュールのアルゴリズムの記述とその動作確認用のテストプログラムの仕様を記述していく．通常，一つのモジュールは複数の機能を担うため，その各々が正しく動作しているかをチェックするための単体テストのプログラム仕様を作る．テストプログラムは一般的に複数の処理の確認をすることも可能なので，モジュールの各処理とテストプログラムの各チェック項目とのマトリックスを作成してPCL(Program Check List)を作成し各処理を網羅的に確認できるだけのテストプログラムを作る必要がある．もちろん確認方法も記述しておかねばならない．
上記のスケジュールから見て分かる通り，ソフトウェア開発の要は検査に重点がおかれている．特にＯＳはコンピュータシステムの要となる巨大なソフトウェアであるため，その信頼性はシステムの稼働率に大きな影響を与える．汎用大型コンピュータは一般的に企業の情報中枢的な役割を果たしている(mission critical)ので，信頼性はその企業経営を左右すると言っても過言ではない．アプリケーションプログラムの信頼性も重要であるがＯＳの信頼性はそれ以上に高くなくてはならない．汎用ＯＳの下ではどんなプログラムが動いても障害が起きてはならないのである．とはいえ，ＯＳも一つのプログラムでありバグをゼロにはできない．製品寿命の中でバグが露呈しなければ良いのだが，不幸にしてバグが露呈してもシステムダウンに繋がらない工夫が必要で，Fale Softの設計思想が徹底されねばならないし，また，バグの早期検出を可能にする仕組みも必要である(falt locating)．現在でもソフトウェアの正当性を誰も証明などできないのである．これができればノーベル賞確実であり，かつ億万長者になれること間違いなしである．
＜先頭へ＞
＜ページの最後へ＞
（６）作業開始
当時IBMのソースコードはPLS(Programming Language System)というPL/1ライクな言語で記述されていた．PL/1については私の入社時の少し前にIBMから新言語として提供されていた．当時，技術科学計算はFORTRAN,事務処理はCOBOLが主流であったが，IBMは汎用的な言語としてPL/1を発表していた．日本IBMから（中研）に転職した渡辺坦さん（日立から電通大・教授に異動したコンパイラ研究者）はPL/1の仕様を日立に紹介した人物である．このPL/1を（中研）では中田育男さん（日本のコンパイラ草分けの技術者でHARPというFortranをHITAC 5020に開発した．日立から筑波大学教授，図書館情報大学，法政大学教授などを勤める）がそのサブセットとなるシステム記述言語をPL/1Wとして開発していた．このためPL/1Wの使用経験からPLSのプログラムを読むのに困難はなかった．
しかし問題はプログラムの量が極めて膨大であること，また，IBMのソースコードなど今まで見たこともなかったため，全くの初心者と同じであった．机の上に積上げられたプログラムのリストから一体，どのようなプログラム構成になっているのか，つまり文章によるドキュメントが全く無い状況では機能構造を理解する手掛りが全く無い．情報はこれらのプログラムリストだけと言うのであるから仕方なしに順番にコードを読みそれらの制御の流れをフローチャートとして書くことから始めた．当時はフローチャートに代わるPAD (Problem Analysis Diagram)図が日立では推奨されていた．これは，（中研）の
二村良彦
さん（北海道大学卒．部分計算で有名に．後に早稲田大学・教授，ハーバード大学など．卓球が上手）らが発案した構造化プログラミングの手法である．日立ではIBMのPLSと同様のプログラミング言語としてHPLを使用していたが，PLSと全く同じ機能を持っていると云われていた．HPLはIBMのPLSと同じか否かは極めて重要かつ微妙な問題なので深くは言及しないことにする．
＜先頭へ＞
＜ページの最後へ＞
（閑話休題１）
1984年11月末，富士通—IBMの和解契約に基づく富士通の製品検査(inspection)をIBMは実施した．その結果， IBMは富士通の互換ソフトウェアに大量のIBMコードのコピーが見つかり，悪質であり富士通との和解契約違反であるとして通産省と富士通にこれを申し入れた．その後，12月末に，IBMは富士通のシステム開発言語SPL(System Programming Language)がIBMのPLSに酷似しているとして問題視し富士通に通告した．システム記述言語のような生産治工具に著作権侵害のような事実が判明することはメーカーにとって致命的であるが，まだ日本にはソフトウェアの著作権の法的保護はなく，成立しても言語は対象外であった．富士通はSPLを独自開発し，IBMのSPLには一切接触していないと主張している．しかし，IBMは強硬な態度を取り続ける．交渉の結果，1985年7月11日IBMはアメリカ仲裁協会(AAA)に仲裁に富士通を提訴し仲裁が始まる．その結果1987年9月15日にAAAから「命令」と「意見書」が出され一応の決着を見る（最終裁定は1988年11月29日になる）．AAAはソフトウェアの著作権についてはIBMの意に反して一切言及することなく，富士通，IBMのユーザ保護の立場を守り，かつ自由な市場競争を行うべきであるという立場で仲裁にあたった．後に富士通はSPLから日本語使用を可能とするLDLという言語に発展？させる．IBMは製品検査でSPLの生成するオブジェクトプログラムがIBMのオブジェクトと類似であることから，SPLに疑惑を持ったのであろう．この詳細は９．引用資料の３．「雲の果に」に述べられている．
我々が最初にやるべきことはPublic Domain版のMVSの調査（つまり解読）である．どのような考えでMVSが作られているのかを知り，これを31ビットアドレッシングにどのようにすれば拡張できるのかを探ることである．さらにMVS/SPのように実記憶の拡張をどうすれば可能になるのかも同時に探ることである．時間はほとんど無い状態であることから少し焦りを感じていた．
また工場における設計書の作成規則・基準に対する知識も無かった．これらのルールや作成した後の検査部でのチェック，その対策なども同時に知る必要があった．研究所では知り得ないことを工場の現場に突然組込まれて，しかも最も重要な部分の仕事を果たさねばならなかったのである．
必死に手当たり次第にMVSのプログラムを読み，これらをPAD図として書きプログラムロジックを何度も何度も見つめては理解を深めて行った．毎日，朝から夜の10時ごろまでこのような作業を続けているとおぼろげにではあるがメモリ管理の概念，プログラム構造，機能分割，モジュール間インターフェース，などが理解できるようになってきた．これは英文読解でも難解な文章を何度も繰り返して眺めているうちに理解できるようになるのに似て，眼光紙背に徹すではないが，設計思想を徐々に理解できるようになっていった．PAD図も400枚ぐらいを書いたと思う．私の担当した主たる部分は実メモリ管理のスワッピング部分であるが，実は東京大学大型計算機センターへのプロポーザルを書くために，その性能評価をした折，MVSのスワッピングは大きな性能上のボトルネックであることは知っていた．正確な数字は忘れたが，スワップイン・アウトだけで400万命令以上を費やしていたと思う．しかし，その具体的なプログラムロジックを知ることはなかった．スワッピングは多重プログラミングのコントロールにおける重要な機能であり，ジョブ空間を2次記憶（ディスクなどの補助記憶装置）に退避（swap out），回復（swap in）する機能である．
早速，川崎所長は石原孝一郎部長を通して私にこのことを伝えた．その後，早急に工場へ長期派遣の手続きがなされた．長期派遣の開始は1983年12月5日であった．日立は人事関係の期日が月の5日と20日であり（おそらく経理の期日），通常は給与支給などの都合からか20日付けが多かったが，このような緊急の事態では5日付けでも移動などが行われた．ということで，年も迫った12月5日，私と部下合わせて４名がソフトウェア工場・システムプログラム部に長期派遣となった．
（３）苦難・苦闘の13ヶ月の始まり
初日は工場長，システムプログラム部長（Mr.T.Y.：IBM産業スパイ事件ではFBIから国外の容疑者として指名手配されていた一人である）への挨拶，そして我々が所属する課長の柴宮実主任技師らとの打ち合わせなどをした．その後，森啓倫主任が部下に命じてIBMのPublic Domainとされている最新のMVSのソースプログラムのリストを我々の机の上に高々と積み上げた．我々の担当する部分はメモリ管理部分であり今回の開発の要となる機能である．
メモリ管理は大きく分けると以下の３つの部分で構成されている．
(A) 実記憶管理（RSM: Real Storage Manager）
(B) 補助記憶管理（ASM: Auxiliary Storage Manager）
(C) 仮想記憶管理（VSM: Virtual Storage Manager）
この中で最大の拡張が必要となるのは実記憶管理（RSM)であり，新井と吉澤が主として担当することにした．補助記憶管理（ASM)は大きなプログラムサイズであったが木下研究員にお願いした．そして変更部分が最も少ないと思われた仮想記憶管理（VSM)は協力会社である日立ソフトウェアエンジニアリング（日立SK）の人達にお願いした．これらの全プログラムは吉澤が責任を持って開発することになっていたので，SKの人達も吉澤の下で働くことになっていたが，派遣法の下での命令指揮権に関する管理体制がやや複雑で悩みがあった．
森啓倫主任（慶應大学卒）はソースコードのリストが搬入完了すると私に，「課長（吉澤）これらのプログラムを31ビット版で動くようにしてください」と言った．私は「これ以外の資料はないの？」と聞いたが，森主任は「ありません．協定によって捨てたと思ってください」との返事であった．和解合意書にある通り，IBMの秘密情報は破棄したことになっているのであった．
以上から，我々に課されたミッションは２つであった．
(A) 仮想記憶と実記憶の両方を31ビットアドレッシング可能とするＯＳの開発
＜VOS3/ES1において31ビットと24ビットのアドレッシングモードを同時に実行可能とする両モード機能(Bimodal Operation)を実現することである＞
(B) 仮想記憶領域は16MBまでの空間サポートであっても利用可能となった実記憶を32MB（あるいは64MB）まで拡張できる実記憶拡張を実現するVOS3/SP21の開発
そこでこの２つのＯＳ開発を同時に満たすような方法を考案した．それは，アドレス幅（仮想記憶部分は31/24ビット，実記憶の部分は31/24−26ビット）を意識することのないプログラム記述方法の工夫である．具体的には，アドレス幅の部分は論理的な表現とするマクロ命令化しコンパイル時の指定により具体的なビット幅を指定する方法である．このアイデアの実現は新入社員の櫻庭君にお願いしたところ見事に実現してくれた．これは一つのソースプログラムで２つのＯＳを同時に開発できるためプログラムの生産性を飛躍的に向上させる結果となった．
上記２つのミッションは必要最低限の仕事である．研究所の人間にとっては実際の製品にタッチするような機会は今迄ほとんどなかった．工場からの依頼研究では，研究所で考え提案するアイデアは，仮に研究所で実際のＯＳに試作的に組込み，その効果のあることを示したとしてもそのまま製品化されることはほとんどなかった．理由は明らかで工場は常に「IBMがやっていないことをあえてやる必要はないし利益に繋がらない」ということでほとんどのケースで拒否していた．つまりＯＳの研究とは当時，IBMが新機能をアナウンスした時の解説者としての役割を果たすことであり，そのために日頃はマスターベーション的な自己学習をすれば良いと当時の（ソフト）工場長は青山の技術研修所で（シ研）の上級研究員研修の場で講演していた．しかし，今回は自分達のアイデアがそのままダイレクトに製品化される二度とない千載一遇の機会を得たのである．
このことからIBMのMVS/XAの最新機能にまでに追いつき，できればそれを追い越したいと思い，予てより依頼研究などで（ソフト）に提案していた機能をなるべく多くこの製品へ関与できる機会に実現することにした．それらは以下の通りである．
(C) セグメント境界緩和方式（CSBR: Common Segment Boundary Release）この提案は小平光彦主任技師からの要求のあった機能であった．
＜従来24ビットのマシンではセグメントサイズの単位が4KB（つまり１ページ単位）であったが3081Kと同等のマシンではメモリ拡張のために１MB単位と大きくなった．このような区切りをバウンダリと呼ぶが，既存の24ビット下で動作する多くのソフトウェアにとってこのハードウェアの制約はジョブ固有領域の縮小となるためプログラムの拡張やそれまでのプログラムが動作できなくなる可能性がある．そこで，この実現にはいささか面倒なテクニックを要すが，なんとかこの問題をメモリ管理で解決する方法を考案しCSBRを実現することにした．VOS3/ES1は我々がこのプロジェクトで開発した31ビット版のＯＳであるが，日経コンピュータに紹介された時，CSBRはIBMにない特徴として紹介された．なおCSBRは私が付けた名前である．後に戦略特許賞を貰うことになる）
(D) オンデマンドスワッピング方式；
実記憶を節約し有効利用するためにジョブ領域全体を外部記憶にオンデマンドで入れ替えする方法である．この有効性については，予てより情報処理学会への論文などで示してあったが実現されていなかった．私の学位論文の一つの重要なテーマと位置づけられている．このアイデアは東京大学大型計算機センターの1000台のTSS端末をサポートするプロポーザルを書く際に得られた知見である．ページングもスワッピングもオンデマンドで行うべきであるというのが私の哲学である．
(E) ワンステージスワップ（One Stage Swapping）方式；
これはスワップ処理を迅速に行う方法であり，ジョブ固有領域とジョブ固有領域のＯＳ管理部分LSQA（Local System Queue Area）と16MB以上のメモリ領域にあるXLSAQを並列して外部記憶に入出力する方法である． 31ビットモードではＯＳ管理部分が拡大されるためスワップに要する時間は無視できずスワップ用のディスクが異なる入出力パスである場合はジョブ固有領域と(LSQA+XLSQA)領域が並行（オーバラップ）して同時に入出力されスワップ時間の短縮となる．
(F) ページテーブル・ページング；
巨大な31ビット空間を実現するためにジョブの管理領域は拡大された．具体的にはページテーブルが最大８MBにもなりこれらの領域は従来，実記憶上に従来は常駐していた．24ビットアドレッシングの時はそれほど大きな領域ではなかったので問題はなかったが仮想記憶のスケール拡大効果により無視できない．そこで，この領域もページングの対象とし実記憶の節約を図ることにした．この複雑なアルゴリズムの実現は新井君が見事に成し遂げてくれた．
(G) 実記憶マイグレーション方式；
従来は16MBあるいは32MBまでの実記憶領域であったがVOS/ES1では2GBの実記憶を利用可能にする必要がある．ところが，当面は拡張チャネルがサポートされないため入出力チャネルは主記憶の16MB以下の領域に対してのみデータ転送を行う．このような状況では16MB以下の実記憶領域が入出力領域により占有されてしまいかねない．この問題を解決するために，実記憶の16MB以下の領域に配置する必要が無くなった領域を積極的に16MB以上の領域に積極的に移動する（migration）アルゴリズムを開発することにした．
これらのアイデアを設計の段階から作り込み実現すると決心した．上記のページテーブル・ページングと実記憶マイグレーション方式の実現は新井利明君にお願いしたがこれらを見事に完成してくれた．それ以外は吉澤が担当した．
余談だが，これらの機能を入れた設計書が完成したところ，現場のプロジェクト・マネージャ（主任クラス）らからとんでもないことを言われた．「吉澤課長，31ビット拡張だけすれば良いので頼まれてもいない機能を作りこむなんて無謀ですよ．自分の首を締めることになりますよ．だから，今のうちにドロップ（設計から外す）したほうが良いと思います．」このようなことを云う設計のエリートが日立に居るのか？と驚いた次第である．日立に入社して以来，日立は野武士精神で技術開発にチャレンジするようにと，と何度も言われていたのだが，工場の現場がこの為体（テイタラク）では将来がないと思った．
（５）新聞工程
しかしMr.T.Y.部長からは「できるできないではなく，やるしかないだろう」ということで，1984年12月31日を工程完了として工程作りを命じた．この工程作りでは各部署がギリギリの積上げをして意見をだした．そこでは，
★設計部は担当者がすべて素人であり，設計にはこれからのPublic Domainの調査を含めないとならないため，最低４ヶ月は必要と主張
★設計部はテストプログラムも最初から作る必要がある．この単体テストとプログラムを連結して疎通テストするだけでも５ヶ月は必要となると主張
そうは言っても残り時間は１年と数日しかない．なにしろ後ろが切られているのだ．工場長からは設計部，検査部が共に譲って工程短縮し臨戦態勢を取って欲しいとの命令が出た．三浦副社長が1984年12月31日に脱IBMすると言ったのは製品出荷の90日前にinspectionを受けねばならないという和解合意書とソフトウェア秘密契約におけるVOS3/SPを日立が顧客に提供できる契約期間切れとの兼ね合いからであろう．このinspectionではIBMの秘密情報が含まれていないか，つまりcontamination(汚染)が無いかを判定する期間である．
（注） 三浦武雄* :
システム開発研究所の初代所長でアナログコンピュータの専門家と聞いていた．私が研究員（俗に云う主任）時代には時折所長室に呼ばれては怒鳴られ，とても怖い人に思えた．しかしいろいろなことを怒鳴り散らすが，多くの場合は自分自身に対する腹立たしさを相手にぶつけているのであって，怒鳴ったことを根に持つ人ではなくとても明るい性格の人であった．1995年9月のある日，日立を退社する際に御茶ノ水本社の副社長室にご挨拶に行った．ビルの最上階で東南の角地の明るい窓だらけの部屋だった．三浦さんは「君ね，この部屋は皆がWindow 95って言うんだよ！明るいだろう」と朗らかに言っていた．私は日立を9月いっぱいで退社することを告げ，その直後に，少し嫌味に「私は（中研）の第７部所属で（シ研）発足と同時に転勤となりました．（中研）では三浦さんの第６部でなかったので，結局はこのように外に出て行かざるを得ません」というと，「君！そう言うなよ！ アッハハ・・・」．つまり，（シ研）というところは（中研）第６部出身者で主要な人事が固められていたので（中研）時代の敵対関係にあった第７部の人間に冷や飯を食わせていたのバレバレだったのだ．この結果，何人もの優秀なコンピュータ技術者が日立から大学教員に転出したと思っている．2012年２月に三浦さんは故人となられた．ご冥福を祈る．
そこで工程表が直ちに作られて説明されたがこの工程を守れるとは誰も思っていなかった．その工程は以下の通りであった．
（Ａ）調査・方式検討：〜’83/12 残り数日
（Ｂ）設計書作成（概念設計，機能設計，構造設計，詳細設計，検査・テスト仕様書，など）：’84/1-2 ２ヶ月間
（Ｃ）コード化（プログラム作成）：’83/3 ２週間
（Ｄ）コンパイル（フラグ取り）とテスト： 〜’84/4 NIP疎通約６週間
（Ｅ）全モジュールの単体テスト； 〜’84/6 約２ヶ月間
（Ｆ）検査部での総合テスト； 〜’84/12末 ６ヶ月間
我々にとってはすべてが初めての経験であり最初の調査・方式検討の時間があまりにも短すぎたことに不安を抱いた．実際には上記の（Ａ）と（Ｂ）の区別は無かったので調査や方式検討は設計書を作りながら進めることにした．設計書は一部分担したがほぼすべてを吉澤が担当した．概念設計は全体的な設計の方向性を書くだけであるが大方針であるため神経を使う．この方針を基にして実現すべき機能の詳細を詰める必要がある．この機能を実現するための各機能コンポーネントが構造設計である．構造というのはプログラムモジュール（ひとつのまとまった機能を実現する手続きやそのデータ構造など）の処理手順（ロジック）の概略ならびにその手順のための入力情報，処理結果の出力情報などを明確にすることである．つまりモジュール間のインターフェースを定義することになる．詳細設計では各モジュールの詳細な手順を記述しなければならないしまた，制御ブロック（データ構造）内の状態変数との関係を明確化する必要がある．
最後の詳細設計では各モジュールのアルゴリズムの記述とその動作確認用のテストプログラムの仕様を記述していく．通常，一つのモジュールは複数の機能を担うため，その各々が正しく動作しているかをチェックするための単体テストのプログラム仕様を作る．テストプログラムは一般的に複数の処理の確認をすることも可能なので，モジュールの各処理とテストプログラムの各チェック項目とのマトリックスを作成してPCL(Program Check List)を作成し各処理を網羅的に確認できるだけのテストプログラムを作る必要がある．もちろん確認方法も記述しておかねばならない．
上記のスケジュールから見て分かる通り，ソフトウェア開発の要は検査に重点がおかれている．特にＯＳはコンピュータシステムの要となる巨大なソフトウェアであるため，その信頼性はシステムの稼働率に大きな影響を与える．汎用大型コンピュータは一般的に企業の情報中枢的な役割を果たしている(mission critical)ので，信頼性はその企業経営を左右すると言っても過言ではない．アプリケーションプログラムの信頼性も重要であるがＯＳの信頼性はそれ以上に高くなくてはならない．汎用ＯＳの下ではどんなプログラムが動いても障害が起きてはならないのである．とはいえ，ＯＳも一つのプログラムでありバグをゼロにはできない．製品寿命の中でバグが露呈しなければ良いのだが，不幸にしてバグが露呈してもシステムダウンに繋がらない工夫が必要で，Fale Softの設計思想が徹底されねばならないし，また，バグの早期検出を可能にする仕組みも必要である(falt locating)．現在でもソフトウェアの正当性を誰も証明などできないのである．これができればノーベル賞確実であり，かつ億万長者になれること間違いなしである．
しかし問題はプログラムの量が極めて膨大であること，また，IBMのソースコードなど今まで見たこともなかったため，全くの初心者と同じであった．机の上に積上げられたプログラムのリストから一体，どのようなプログラム構成になっているのか，つまり文章によるドキュメントが全く無い状況では機能構造を理解する手掛りが全く無い．情報はこれらのプログラムリストだけと言うのであるから仕方なしに順番にコードを読みそれらの制御の流れをフローチャートとして書くことから始めた．当時はフローチャートに代わるPAD (Problem Analysis Diagram)図が日立では推奨されていた．これは，（中研）の 二村良彦 さん（北海道大学卒．部分計算で有名に．後に早稲田大学・教授，ハーバード大学など．卓球が上手）らが発案した構造化プログラミングの手法である．日立ではIBMのPLSと同様のプログラミング言語としてHPLを使用していたが，PLSと全く同じ機能を持っていると云われていた．HPLはIBMのPLSと同じか否かは極めて重要かつ微妙な問題なので深くは言及しないことにする．
我々が最初にやるべきことはPublic Domain版のMVSの調査（つまり解読）である．どのような考えでMVSが作られているのかを知り，これを31ビットアドレッシングにどのようにすれば拡張できるのかを探ることである．さらにMVS/SPのように実記憶の拡張をどうすれば可能になるのかも同時に探ることである．時間はほとんど無い状態であることから少し焦りを感じていた．
また工場における設計書の作成規則・基準に対する知識も無かった．これらのルールや作成した後の検査部でのチェック，その対策なども同時に知る必要があった．研究所では知り得ないことを工場の現場に突然組込まれて，しかも最も重要な部分の仕事を果たさねばならなかったのである．
必死に手当たり次第にMVSのプログラムを読み，これらをPAD図として書きプログラムロジックを何度も何度も見つめては理解を深めて行った．毎日，朝から夜の10時ごろまでこのような作業を続けているとおぼろげにではあるがメモリ管理の概念，プログラム構造，機能分割，モジュール間インターフェース，などが理解できるようになってきた．これは英文読解でも難解な文章を何度も繰り返して眺めているうちに理解できるようになるのに似て，眼光紙背に徹すではないが，設計思想を徐々に理解できるようになっていった．PAD図も400枚ぐらいを書いたと思う．私の担当した主たる部分は実メモリ管理のスワッピング部分であるが，実は東京大学大型計算機センターへのプロポーザルを書くために，その性能評価をした折，MVSのスワッピングは大きな性能上のボトルネックであることは知っていた．正確な数字は忘れたが，スワップイン・アウトだけで400万命令以上を費やしていたと思う．しかし，その具体的なプログラムロジックを知ることはなかった．スワッピングは多重プログラミングのコントロールにおける重要な機能であり，ジョブ空間を2次記憶（ディスクなどの補助記憶装置）に退避（swap out），回復（swap in）する機能である．
＜先頭へ＞ ＜ページの最後へ＞
（閑話休題２）
ジョブ空間は各ジョブのプログラムやデータ領域のことであり仮想記憶領域である．その一部に実記憶が割り付けられているので，スワップアウトの際の基本的な操作はジョブ空間に割り付けられている実ページを2次記憶（この装置上のファイルをページングファイルあるいはスワッピングファイルと呼ぶ）上に退避する．スワップインはその逆である．スワッピングの難しさはジョブ領域上の仮想記憶の状態がどのようになっていてもスワップアウトし，スワップイン時に矛盾の無い動作を保証することにある．ジョブ固有領域には一般的な入出力領域があり，入出力の起動はされていても入出力が完了していないケースもある．また，一部の仮想記憶領域がページング入出力中であっても同様の保証をすることや，特殊なケースであるが，仮想記憶の一部をページングの対象外とするPGFIX(Page Fix)されている部分，あるいはその処理中である場合の保証も含まれる．さらに面倒なのはV=Rジョブといって仮想記憶のメモリ番地と実記憶の番地が一致していなければならない特殊な入出力を行っている領域のスワップイン/アウトの処理などがロジックをさらに面倒にしている．
スワップ操作について：東京大学大型センターのプロポーザルを作成する仕事の時は，センター長はDennis Richieの開発した「プログラミング言語C」の翻訳で有名な故
石田晴久
先生であった．東京大学からのバッチ処理の性能に関する注文はFortranのSTOP/ENDジョブ（つまり始めと終わりしかない仕事で中身はゼロ）を一時間に何件処理できるかというスループットであった．当時，FortranのSTOP/ENDジョブはせいぜい500万命令であった．これに比べると，SWAP操作は大きなオーバヘッドであることが分かる．石田先生は2009年にお亡くなりになった．お話の上手な先生であった．
＜先頭へ＞
＜戻る＞
＜目次へ＞
＜次＞
脱IBM VOS3/ES1開発Copyrights all rights reserved, Y.Yoshizawa 2016-2017