5.3 最後のバグ
5.3 最後のバグ
（１）1984年8月の人事
（２）検査工程の最終段階
（３）最後のバグ
（４）背水の陣
（５）工場に戻って
（６）新年の挨拶
（７）VOS3/ES1の開発を通して
（２）検査工程の最終段階
（３）最後のバグ
（４）背水の陣
（５）工場に戻って
（６）新年の挨拶
（７）VOS3/ES1の開発を通して
（１）1984年8月の人事
8月から始まった検査部での検査工程もほぼ4ヶ月が経った．ここまで悪戦苦闘の日々であったがなんとか工程を順調にこなせるように思えていた．だが残された時間は１ヶ月も無い．時々，営業の人間が設計部長席で脱IBMの状況を聴きにくる．営業はVOS3/SPの収入がマイナスであり赤字垂れ流し状態を期日どおり1985年3月で打ち切りたいという切実な思いだったはずだ．確か8月の人事で（日立では2月20日と8月20日に職制の異動が行われることが多い）不破さんから高須昭輔工場長に代わり，システムプログラム設計部長もMr.T.Y.さんから小平光彦さんに代わっていた．小平さんは私の一つ年齢が上で東京大学工学部の出身であった．（ソフト）の超エリートである．日立入社時の配属は（ソフト）所属の研究所(Division Laboratory)の情報システム研究所であったが1973年2月に（シ研）発足と同時にこの研究所が吸収された際に小平さんは（ソフト）に配置転換を希望して工場に移った．これは彼にとっても日立にとっても大正解であった．
（２）検査工程の最終段階
1984年12月に入るとVOS3/ES1の品質も大分良くなってきた．しかし全体としてはまだ検査部から厳しい注文があった．残り時間も少ない．一般的にある程度の品質が向上するとそこから先に発見される一つずつのバグを解決するのは困難を極める．こうしている時に驚くべきバグに遭遇した．
このバグは検査部からの指摘の一つであった．調べると我々のメモリ管理の管轄である制御情報のデータ構造（制御テーブル）の一部が何者かによって書き込まれて誤動作したのである．この種のバグはよくあるのだが，しかし，このバグはその箇所が一定ではない．通常はテーブルの先頭から一定の箇所（オフセット）がメモリ破壊されることが多い．しかし破壊されている箇所が変わるので質が悪い．我々は「Dr.Yoshizawaジョブ」を何度も長時間掛けて実行したが，再現させることができない．検査部に検査時の環境も教えてもらったが再現できないのである．検査部はこのバグを重要視し，解決できない限り合格は出せないとの一点張りである．つまり最後のバグとなったのである．
＜先頭へ＞
＜ページの最後へ＞
（３）最後のバグ
難解な英文を読んでいる時に経験があるが，どうしても理解できない文章でも何度も同じ活字を見ていると徐々にその内容が理解出来てくる．これと同じようにメモリダンプを何度も睨んでいるとバグの原因が徐々に見えてくる気がする．まず，我々のテーブルのあたりを操作すると思われる機能とそのモジュールは何かを考えると，これはRCM（Resource Centralized Manager）に違いないという結論に至った．また破壊されている部分からするとStore系の命令にはいくつかあるが，Store命令（４バイト書込み）であろうと思われた．そこで担当者のMr.M.に「お前が怪しいから，持っているRCMの全ソースコードからStore命令を全部チェックして欲しい」と言った．またこの時点で出るバグは最近修正した箇所の修正誤りであることがあるので，その部分も再度チェックして欲しいと言った．しかし，数日経っても問題はありませんとの返事ばかりであった．したがってこの間，検査部は次の検査に応じることを拒否し完全に工程が止まってしまった．
12月も下旬に入りいよいよ工完期日までの時間がなくなってきた．そこで工場長の出席を得て1984年最後の検査部と設計部の協議を行った．双方が現在の状況説明を工場長に行い，この残された最後のバグ問題をどのように処置すべきかを検討し始めた．検査部は最後のバグと云われているこのバグを解決しないかぎり合格は出せないと主張するばかりである．設計部はこれまで10日以上もこのバグ対策をしてきたが再現させることができない．したがって顧客サイトでもこのバグが出ることはないだろうから，暫定合格にして欲しいとお願いするばかりであった．
膠着状態が続き，工場長も両者の主張を聴くだけで決断はできない．当然である．これで合格させたとすると検査部の役割は何だ！と検査部長が怒鳴ることは必定である．そうしている内に，検査部から「そこまで設計部がいうのなら，バグゼロ宣言をしてみたらどうか？」という挑戦的な発言があった．売り言葉に買い言葉じゃないが，そこで私が「私もフィールドではこのバグは出ないでしょう．したがって，バグゼロ宣言を設計として出しましょう」と提案した．すると小平部長が「吉澤さん．それはマズイよ．バグゼロ宣言すると品質保証を設計部がやらねばならなくなる．検査はこの製品に責任を持たなくなる．そうすると顧客からの問合せのすべてに設計が対応しなくてはならなくなる規則なんだ．これは設計部には耐えられない．」ということで，結局，最後のバグをなんとかして設計部で解決するということで会議が終わった．
＜先頭へ＞
＜ページの最後へ＞
（４）背水の陣
年末年始休暇は12月28日から始まる．そうなると残りが数日しかないようになった．毎日のように一つのバグを追いかけた．マシンでの再現，徹底した罠パッチによるチェック，「Dr.Yoshizawaジョブ」の実行，など様々なテストを繰り返す．それだけではなく自分のところにバグがないのかと徹底的にプログラムソースコードを何度も何度も繰り返し読み直す．そして仮設を立てては可能性の追求を行い検査部から受取ったメモリダンプを繰り返し繰り返し何度も眺める．しかしバグは見つからない．疑わしいのはRCMだけでありそれ以外に考えられなかった．
遂に年末年始休暇に入る前の日；12月27日だったと思うがこの日で時間切れということでこのバグは年越しだと諦め始めていた．しかし最後まで頑張りたいという気持ちはシステムプログラム設計部の人間は皆同じであった．そこで設計部は全員が深夜残業するために残ることになり，（ソフト）のテスト用マシンでは再現しないので神奈川工場に設置してあるソフトウェア工場のサーバマシンに設計部のTSSマシンがつながっていることを利用し，このマシンに開発中のVOS3/ES1をインストールし負荷テストをしてバグを見つけようということになった．マシンに立ち会うために，定時後食事を摂り（ソフト）<->（神）間の連絡バスで神奈川工場に向かった．現地のマシンルームの控室では関係者が既に集合していた．私は「Dr.Yoshizawaジョブ」そして考え抜いた末に作り上げた新たな膨大なパッチカードを持参していた．深夜０時から借り切ったマシンにVOS3/ES1のIPLを行う．しばらくして，（ソフト）に待機していた部隊と連絡が取れ，シプ部のTSS端末を一斉に100名が使用開始する．私は「Dr.Yoshizawaジョブ」を投入する．無限に繰り返す負荷テストプログラムを仕掛けた状態でCPUビジー率，チャネル使用率などをしばらく眺めてはマシンの状態を見ていたが，すぐには罠パッチに掛かってこない．
少し休むつもりで控室に待機していたところ，１時間ぐらい経過した時に「吉澤さん．罠にかかりましたよ！」と大声でオペレータが入ってきた．急いでサービスプロセッサのコンソール画面を眺める．そこにはPSWが16進数で表示されている．31ビットアドレス表示であり，先頭の文字は確かEであった．早速，罠パッチに掛かったことをPSWの表示で確認する．その番地をメモする．犯人のアドレスから自分たちの担当しているプログラム,
つまりRSM(Real Storage Manager)ではないなと少し安心する．長くデバッグしているとPSWやレジスタの内容を見ただけで，おおよそどこのモジュールか，とかバグ内容などが分かるようになっていた．
＜先頭へ＞
＜ページの最後へ＞
こうなると犯人である不当書込みをした「何者か」が分かる．サービスプロセッサを操作して汎用レジスタを見る．これらを素早くメモし，罠パッチで集めた不当書き込みをした命令アドレスのメモリ領域を表示させる．この部分もメモすると，STH(Store Half word)命令であった．コンソールディスプレイには16進数とEBCDIKの文字表示が同時に出ているのでこのプログラム名称を探すことにした．通常，プログラムの先頭は４バイトの分岐命令でありその下にモジュール名がEBCDIKで表示されている．したがって，PSWの示す番地より若い番地をスクロールしていくとプログラム名称が出てくる．急いでその名前を探す．名前の上が分岐命令(ox47)であることを確認する．そこがプログラムのエントリである．早速，このプログラム名称とエントリアドレスをメモする．次にやることは，罠にかかった命令アドレスはこのプログラムの先頭から相対的に何番地であるかを計算することである．この間，メモを取る手が震えていたことを覚えている．
プログラム名称からRCMのプログラムであることが分かった．このバグはRCMであると予想していたが，その通りであった．間違えていたのはバグを起こしている命令がST(Store Word；４バイト操作)ではなくてSTH(Store Half Word:２バイト操作)命令であったことだ．これには気づかなかった．また，担当者のMr.M.には大分前から忠告していたが，STHではなくST命令を全部チェックせよと言った覚えがある．早速，相対番地からバグのステートメントを調べ，設計部の部長らにこれらの調査結果を電話で連絡をした．こうして最後のバグを時間ギリギリで見つけることができた．
最後のバグが見つかり一段落した．大騒ぎをしたあと午前3時半ぐらいになり仮眠することにした．仮眠所は当然薄暗くなっており，作業衣のままベッドに潜り込んだ．しかし，なんだか随分と湿っぽく冷たいことに加えてベッドが人体の形通りに沈み込んでいるので極めて居心地が悪く気持ちが悪い．その上，興奮しているのでなかなか寝付けなかったが，疲れがでたのか目が覚めたら午前８時ぐらいになっていた．とても長い一日に感じた．
＜先頭へ＞
＜ページの最後へ＞
（５）工場に戻って
翌28日は秦野の神奈川工場から（ソフト）<->（（神）連絡バスに乗り（ソフト）に向かった．とても良く晴れた日であった．工場の自分の席に着くとRCM担当の主任であるMr.O.が早速お詫びに来た．Mr.O.は大卒ではないがとても優秀な技術者であり人望もあった．当時の日立には高卒者がいたが優秀な人が多かった．正直言って彼らでもっているような工場に思えた．余談だが，研究所でも高卒者は極めて優秀な人ばかりで，彼らは日本各地の工業高校を成績トップで卒業した人達であった．何らかの事情で大学に進学できなかっただけなのだ．話を元に戻す．Mr.O.主任には「お前でなく，何度も忠告したMr.M.を呼べ！」と怒った．Mr.M.は工場では学卒なので中位ぐらいのエリートなのである．その後，恐る恐る詫びに来た．
その後，私はシステム開発研究所川崎淳所長の自宅に電話を入れ，工期を守りVOS3/ES1を完成したことを報告した．川崎所長は大いに喜んでくれ我々の労をねぎらってくれた．
（６）新年の挨拶
1985年はシステム開発研究所に初出勤することができた．所員は講堂に集まり社長の年頭の辞を聴いてから所長の挨拶がある．所長は冒頭「昨年末に大変めでたいニュースが飛び込みました．吉澤君が脱IBMのＯＳであるVOS3/ES1を期日どおりに昨年末に完成させてくれました．これはシステム開発研究所の名を全社に高め，またコンピュータ事業への大きな貢献となります．本当にご苦労様でした．」という賛辞を頂いた．
（７）VOS3/ES1の開発を通して
この仕事は今まで日立で自由気ままに仕事をさせてもらった恩返しと思いやり遂げた．また，自分の力を試してみようとも思った．この両者を満足させることができたのは幸いであった．最初の目的であった脱IBMを達成する独自ＯＳの開発はできたし，依頼された31ビットアドレス拡張機能，31/24ビット両モードを同時に動かすバイモーダルオペレーション(bi-modal operation)も実現した．そればかりでなく，IBMにない新機能であるセグメント境界緩和方式；CSBR，オンデマンドスワッピング方式，ワンステージスワップ方式，実記憶マイグレーション機能，などの機能をドロップもスリップもすることなく最初のバージョンから作りこむことができた．実は，8月以降の検査部による検査で苦しんでいたときは，プロマネからは（シ研）さんは頼まれてもいない余計な機能を作りこんでいるからバグ収束が悪いのだなどと云われた．そしてこれらの機能をドロップ（落とせ！）せよとかスリップ（延期）して次のバージョンで入れたら，などと言われた．だがこれらの追加機能にはほとんどバグはなかったので，スリップやドロップは論外であった．
ソフトウェア開発の難しさは上記のような新機能の追加にあるのではなく，既存プログラムの改変にある．つまり，新しく機能設計して全く新しいプログラムを作るのは簡単なのである．それよりもPublic Domainという既存プログラムを解読し，そこに改変を加えることの方が比較にならないぐらい難しいのである．理由は簡単だ．他人が作った気心の知れない母体となるプログラムを理解するには桁違いの時間を必要とする．今回のように関連する設計書などのドキュメントがゼロの場合はなおさらのことである．ソフトウェア開発においては，まさに案ずるより生むは易しなのである．だがソフトウェア産業は殆どがメインテナンス産業になっているので，新規のプログラム開発よりは既存プログラムの改変が主となっていることを忘れてはならない．このためにも水面下の財産が重要であり，理解し易いドキュメントを整備することが最も大切である．水面上のプログラムコードだけ残すようでは，そのプログラムを一生抱え込むことになろう．
（シ研）からは我々以外に言語処理系や通信ミドルソフトウェアなどの脱IBMに駆りだされた人達がいた．これは全社を挙げて（ソフト）の危機を脱出するという(S)「これをマルエスプロジェクト」と呼んでいたが，取締役会議で決定した活動であった．その一環として（シ研）でソフトウェア技術があると思われる優秀な研究者を派遣したのである．だが，これらのマルエスプロジェクトに参加した人達で初期の目的を達成した人は居なかったと記憶している．中には指定プログラムを諦めてIBMからライセンスした製品もあった．実は研究所ではその製品に対する最も知見のある研究者であると言われていたのである．またある研究者は身体を壊して入院・手術となり工場から撤退した．皮肉なことに病気になった人間には同情的になり，私達のように元気で（シ研）に戻った人間には同情など無く，出来て当たり前という評価のように思えた．
＜先頭へ＞
＜戻る＞
＜目次へ＞
＜次＞
脱IBM VOS3/ES1開発
Copyrights all rights reserved, Y.Yoshizawa 2016-2017
（２）検査工程の最終段階
1984年12月に入るとVOS3/ES1の品質も大分良くなってきた．しかし全体としてはまだ検査部から厳しい注文があった．残り時間も少ない．一般的にある程度の品質が向上するとそこから先に発見される一つずつのバグを解決するのは困難を極める．こうしている時に驚くべきバグに遭遇した．
このバグは検査部からの指摘の一つであった．調べると我々のメモリ管理の管轄である制御情報のデータ構造（制御テーブル）の一部が何者かによって書き込まれて誤動作したのである．この種のバグはよくあるのだが，しかし，このバグはその箇所が一定ではない．通常はテーブルの先頭から一定の箇所（オフセット）がメモリ破壊されることが多い．しかし破壊されている箇所が変わるので質が悪い．我々は「Dr.Yoshizawaジョブ」を何度も長時間掛けて実行したが，再現させることができない．検査部に検査時の環境も教えてもらったが再現できないのである．検査部はこのバグを重要視し，解決できない限り合格は出せないとの一点張りである．つまり最後のバグとなったのである．
（３）最後のバグ
難解な英文を読んでいる時に経験があるが，どうしても理解できない文章でも何度も同じ活字を見ていると徐々にその内容が理解出来てくる．これと同じようにメモリダンプを何度も睨んでいるとバグの原因が徐々に見えてくる気がする．まず，我々のテーブルのあたりを操作すると思われる機能とそのモジュールは何かを考えると，これはRCM（Resource Centralized Manager）に違いないという結論に至った．また破壊されている部分からするとStore系の命令にはいくつかあるが，Store命令（４バイト書込み）であろうと思われた．そこで担当者のMr.M.に「お前が怪しいから，持っているRCMの全ソースコードからStore命令を全部チェックして欲しい」と言った．またこの時点で出るバグは最近修正した箇所の修正誤りであることがあるので，その部分も再度チェックして欲しいと言った．しかし，数日経っても問題はありませんとの返事ばかりであった．したがってこの間，検査部は次の検査に応じることを拒否し完全に工程が止まってしまった．
12月も下旬に入りいよいよ工完期日までの時間がなくなってきた．そこで工場長の出席を得て1984年最後の検査部と設計部の協議を行った．双方が現在の状況説明を工場長に行い，この残された最後のバグ問題をどのように処置すべきかを検討し始めた．検査部は最後のバグと云われているこのバグを解決しないかぎり合格は出せないと主張するばかりである．設計部はこれまで10日以上もこのバグ対策をしてきたが再現させることができない．したがって顧客サイトでもこのバグが出ることはないだろうから，暫定合格にして欲しいとお願いするばかりであった．
膠着状態が続き，工場長も両者の主張を聴くだけで決断はできない．当然である．これで合格させたとすると検査部の役割は何だ！と検査部長が怒鳴ることは必定である．そうしている内に，検査部から「そこまで設計部がいうのなら，バグゼロ宣言をしてみたらどうか？」という挑戦的な発言があった．売り言葉に買い言葉じゃないが，そこで私が「私もフィールドではこのバグは出ないでしょう．したがって，バグゼロ宣言を設計として出しましょう」と提案した．すると小平部長が「吉澤さん．それはマズイよ．バグゼロ宣言すると品質保証を設計部がやらねばならなくなる．検査はこの製品に責任を持たなくなる．そうすると顧客からの問合せのすべてに設計が対応しなくてはならなくなる規則なんだ．これは設計部には耐えられない．」ということで，結局，最後のバグをなんとかして設計部で解決するということで会議が終わった．
＜先頭へ＞ ＜ページの最後へ＞
（４）背水の陣
年末年始休暇は12月28日から始まる．そうなると残りが数日しかないようになった．毎日のように一つのバグを追いかけた．マシンでの再現，徹底した罠パッチによるチェック，「Dr.Yoshizawaジョブ」の実行，など様々なテストを繰り返す．それだけではなく自分のところにバグがないのかと徹底的にプログラムソースコードを何度も何度も繰り返し読み直す．そして仮設を立てては可能性の追求を行い検査部から受取ったメモリダンプを繰り返し繰り返し何度も眺める．しかしバグは見つからない．疑わしいのはRCMだけでありそれ以外に考えられなかった．
遂に年末年始休暇に入る前の日；12月27日だったと思うがこの日で時間切れということでこのバグは年越しだと諦め始めていた．しかし最後まで頑張りたいという気持ちはシステムプログラム設計部の人間は皆同じであった．そこで設計部は全員が深夜残業するために残ることになり，（ソフト）のテスト用マシンでは再現しないので神奈川工場に設置してあるソフトウェア工場のサーバマシンに設計部のTSSマシンがつながっていることを利用し，このマシンに開発中のVOS3/ES1をインストールし負荷テストをしてバグを見つけようということになった．マシンに立ち会うために，定時後食事を摂り（ソフト）<->（神）間の連絡バスで神奈川工場に向かった．現地のマシンルームの控室では関係者が既に集合していた．私は「Dr.Yoshizawaジョブ」そして考え抜いた末に作り上げた新たな膨大なパッチカードを持参していた．深夜０時から借り切ったマシンにVOS3/ES1のIPLを行う．しばらくして，（ソフト）に待機していた部隊と連絡が取れ，シプ部のTSS端末を一斉に100名が使用開始する．私は「Dr.Yoshizawaジョブ」を投入する．無限に繰り返す負荷テストプログラムを仕掛けた状態でCPUビジー率，チャネル使用率などをしばらく眺めてはマシンの状態を見ていたが，すぐには罠パッチに掛かってこない．
少し休むつもりで控室に待機していたところ，１時間ぐらい経過した時に「吉澤さん．罠にかかりましたよ！」と大声でオペレータが入ってきた．急いでサービスプロセッサのコンソール画面を眺める．そこにはPSWが16進数で表示されている．31ビットアドレス表示であり，先頭の文字は確かEであった．早速，罠パッチに掛かったことをPSWの表示で確認する．その番地をメモする．犯人のアドレスから自分たちの担当しているプログラム,
つまりRSM(Real Storage Manager)ではないなと少し安心する．長くデバッグしているとPSWやレジスタの内容を見ただけで，おおよそどこのモジュールか，とかバグ内容などが分かるようになっていた．
＜先頭へ＞
＜ページの最後へ＞
こうなると犯人である不当書込みをした「何者か」が分かる．サービスプロセッサを操作して汎用レジスタを見る．これらを素早くメモし，罠パッチで集めた不当書き込みをした命令アドレスのメモリ領域を表示させる．この部分もメモすると，STH(Store Half word)命令であった．コンソールディスプレイには16進数とEBCDIKの文字表示が同時に出ているのでこのプログラム名称を探すことにした．通常，プログラムの先頭は４バイトの分岐命令でありその下にモジュール名がEBCDIKで表示されている．したがって，PSWの示す番地より若い番地をスクロールしていくとプログラム名称が出てくる．急いでその名前を探す．名前の上が分岐命令(ox47)であることを確認する．そこがプログラムのエントリである．早速，このプログラム名称とエントリアドレスをメモする．次にやることは，罠にかかった命令アドレスはこのプログラムの先頭から相対的に何番地であるかを計算することである．この間，メモを取る手が震えていたことを覚えている．
プログラム名称からRCMのプログラムであることが分かった．このバグはRCMであると予想していたが，その通りであった．間違えていたのはバグを起こしている命令がST(Store Word；４バイト操作)ではなくてSTH(Store Half Word:２バイト操作)命令であったことだ．これには気づかなかった．また，担当者のMr.M.には大分前から忠告していたが，STHではなくST命令を全部チェックせよと言った覚えがある．早速，相対番地からバグのステートメントを調べ，設計部の部長らにこれらの調査結果を電話で連絡をした．こうして最後のバグを時間ギリギリで見つけることができた．
最後のバグが見つかり一段落した．大騒ぎをしたあと午前3時半ぐらいになり仮眠することにした．仮眠所は当然薄暗くなっており，作業衣のままベッドに潜り込んだ．しかし，なんだか随分と湿っぽく冷たいことに加えてベッドが人体の形通りに沈み込んでいるので極めて居心地が悪く気持ちが悪い．その上，興奮しているのでなかなか寝付けなかったが，疲れがでたのか目が覚めたら午前８時ぐらいになっていた．とても長い一日に感じた．
＜先頭へ＞
＜ページの最後へ＞
（５）工場に戻って
翌28日は秦野の神奈川工場から（ソフト）<->（（神）連絡バスに乗り（ソフト）に向かった．とても良く晴れた日であった．工場の自分の席に着くとRCM担当の主任であるMr.O.が早速お詫びに来た．Mr.O.は大卒ではないがとても優秀な技術者であり人望もあった．当時の日立には高卒者がいたが優秀な人が多かった．正直言って彼らでもっているような工場に思えた．余談だが，研究所でも高卒者は極めて優秀な人ばかりで，彼らは日本各地の工業高校を成績トップで卒業した人達であった．何らかの事情で大学に進学できなかっただけなのだ．話を元に戻す．Mr.O.主任には「お前でなく，何度も忠告したMr.M.を呼べ！」と怒った．Mr.M.は工場では学卒なので中位ぐらいのエリートなのである．その後，恐る恐る詫びに来た．
その後，私はシステム開発研究所川崎淳所長の自宅に電話を入れ，工期を守りVOS3/ES1を完成したことを報告した．川崎所長は大いに喜んでくれ我々の労をねぎらってくれた．
（６）新年の挨拶
1985年はシステム開発研究所に初出勤することができた．所員は講堂に集まり社長の年頭の辞を聴いてから所長の挨拶がある．所長は冒頭「昨年末に大変めでたいニュースが飛び込みました．吉澤君が脱IBMのＯＳであるVOS3/ES1を期日どおりに昨年末に完成させてくれました．これはシステム開発研究所の名を全社に高め，またコンピュータ事業への大きな貢献となります．本当にご苦労様でした．」という賛辞を頂いた．
（７）VOS3/ES1の開発を通して
この仕事は今まで日立で自由気ままに仕事をさせてもらった恩返しと思いやり遂げた．また，自分の力を試してみようとも思った．この両者を満足させることができたのは幸いであった．最初の目的であった脱IBMを達成する独自ＯＳの開発はできたし，依頼された31ビットアドレス拡張機能，31/24ビット両モードを同時に動かすバイモーダルオペレーション(bi-modal operation)も実現した．そればかりでなく，IBMにない新機能であるセグメント境界緩和方式；CSBR，オンデマンドスワッピング方式，ワンステージスワップ方式，実記憶マイグレーション機能，などの機能をドロップもスリップもすることなく最初のバージョンから作りこむことができた．実は，8月以降の検査部による検査で苦しんでいたときは，プロマネからは（シ研）さんは頼まれてもいない余計な機能を作りこんでいるからバグ収束が悪いのだなどと云われた．そしてこれらの機能をドロップ（落とせ！）せよとかスリップ（延期）して次のバージョンで入れたら，などと言われた．だがこれらの追加機能にはほとんどバグはなかったので，スリップやドロップは論外であった．
ソフトウェア開発の難しさは上記のような新機能の追加にあるのではなく，既存プログラムの改変にある．つまり，新しく機能設計して全く新しいプログラムを作るのは簡単なのである．それよりもPublic Domainという既存プログラムを解読し，そこに改変を加えることの方が比較にならないぐらい難しいのである．理由は簡単だ．他人が作った気心の知れない母体となるプログラムを理解するには桁違いの時間を必要とする．今回のように関連する設計書などのドキュメントがゼロの場合はなおさらのことである．ソフトウェア開発においては，まさに案ずるより生むは易しなのである．だがソフトウェア産業は殆どがメインテナンス産業になっているので，新規のプログラム開発よりは既存プログラムの改変が主となっていることを忘れてはならない．このためにも水面下の財産が重要であり，理解し易いドキュメントを整備することが最も大切である．水面上のプログラムコードだけ残すようでは，そのプログラムを一生抱え込むことになろう．
（シ研）からは我々以外に言語処理系や通信ミドルソフトウェアなどの脱IBMに駆りだされた人達がいた．これは全社を挙げて（ソフト）の危機を脱出するという(S)「これをマルエスプロジェクト」と呼んでいたが，取締役会議で決定した活動であった．その一環として（シ研）でソフトウェア技術があると思われる優秀な研究者を派遣したのである．だが，これらのマルエスプロジェクトに参加した人達で初期の目的を達成した人は居なかったと記憶している．中には指定プログラムを諦めてIBMからライセンスした製品もあった．実は研究所ではその製品に対する最も知見のある研究者であると言われていたのである．またある研究者は身体を壊して入院・手術となり工場から撤退した．皮肉なことに病気になった人間には同情的になり，私達のように元気で（シ研）に戻った人間には同情など無く，出来て当たり前という評価のように思えた．
＜先頭へ＞
＜戻る＞
＜目次へ＞
＜次＞
脱IBM VOS3/ES1開発
Copyrights all rights reserved, Y.Yoshizawa 2016-2017
年末年始休暇は12月28日から始まる．そうなると残りが数日しかないようになった．毎日のように一つのバグを追いかけた．マシンでの再現，徹底した罠パッチによるチェック，「Dr.Yoshizawaジョブ」の実行，など様々なテストを繰り返す．それだけではなく自分のところにバグがないのかと徹底的にプログラムソースコードを何度も何度も繰り返し読み直す．そして仮設を立てては可能性の追求を行い検査部から受取ったメモリダンプを繰り返し繰り返し何度も眺める．しかしバグは見つからない．疑わしいのはRCMだけでありそれ以外に考えられなかった．
遂に年末年始休暇に入る前の日；12月27日だったと思うがこの日で時間切れということでこのバグは年越しだと諦め始めていた．しかし最後まで頑張りたいという気持ちはシステムプログラム設計部の人間は皆同じであった．そこで設計部は全員が深夜残業するために残ることになり，（ソフト）のテスト用マシンでは再現しないので神奈川工場に設置してあるソフトウェア工場のサーバマシンに設計部のTSSマシンがつながっていることを利用し，このマシンに開発中のVOS3/ES1をインストールし負荷テストをしてバグを見つけようということになった．マシンに立ち会うために，定時後食事を摂り（ソフト）<->（神）間の連絡バスで神奈川工場に向かった．現地のマシンルームの控室では関係者が既に集合していた．私は「Dr.Yoshizawaジョブ」そして考え抜いた末に作り上げた新たな膨大なパッチカードを持参していた．深夜０時から借り切ったマシンにVOS3/ES1のIPLを行う．しばらくして，（ソフト）に待機していた部隊と連絡が取れ，シプ部のTSS端末を一斉に100名が使用開始する．私は「Dr.Yoshizawaジョブ」を投入する．無限に繰り返す負荷テストプログラムを仕掛けた状態でCPUビジー率，チャネル使用率などをしばらく眺めてはマシンの状態を見ていたが，すぐには罠パッチに掛かってこない．
少し休むつもりで控室に待機していたところ，１時間ぐらい経過した時に「吉澤さん．罠にかかりましたよ！」と大声でオペレータが入ってきた．急いでサービスプロセッサのコンソール画面を眺める．そこにはPSWが16進数で表示されている．31ビットアドレス表示であり，先頭の文字は確かEであった．早速，罠パッチに掛かったことをPSWの表示で確認する．その番地をメモする．犯人のアドレスから自分たちの担当しているプログラム, つまりRSM(Real Storage Manager)ではないなと少し安心する．長くデバッグしているとPSWやレジスタの内容を見ただけで，おおよそどこのモジュールか，とかバグ内容などが分かるようになっていた．
こうなると犯人である不当書込みをした「何者か」が分かる．サービスプロセッサを操作して汎用レジスタを見る．これらを素早くメモし，罠パッチで集めた不当書き込みをした命令アドレスのメモリ領域を表示させる．この部分もメモすると，STH(Store Half word)命令であった．コンソールディスプレイには16進数とEBCDIKの文字表示が同時に出ているのでこのプログラム名称を探すことにした．通常，プログラムの先頭は４バイトの分岐命令でありその下にモジュール名がEBCDIKで表示されている．したがって，PSWの示す番地より若い番地をスクロールしていくとプログラム名称が出てくる．急いでその名前を探す．名前の上が分岐命令(ox47)であることを確認する．そこがプログラムのエントリである．早速，このプログラム名称とエントリアドレスをメモする．次にやることは，罠にかかった命令アドレスはこのプログラムの先頭から相対的に何番地であるかを計算することである．この間，メモを取る手が震えていたことを覚えている．
プログラム名称からRCMのプログラムであることが分かった．このバグはRCMであると予想していたが，その通りであった．間違えていたのはバグを起こしている命令がST(Store Word；４バイト操作)ではなくてSTH(Store Half Word:２バイト操作)命令であったことだ．これには気づかなかった．また，担当者のMr.M.には大分前から忠告していたが，STHではなくST命令を全部チェックせよと言った覚えがある．早速，相対番地からバグのステートメントを調べ，設計部の部長らにこれらの調査結果を電話で連絡をした．こうして最後のバグを時間ギリギリで見つけることができた．
最後のバグが見つかり一段落した．大騒ぎをしたあと午前3時半ぐらいになり仮眠することにした．仮眠所は当然薄暗くなっており，作業衣のままベッドに潜り込んだ．しかし，なんだか随分と湿っぽく冷たいことに加えてベッドが人体の形通りに沈み込んでいるので極めて居心地が悪く気持ちが悪い．その上，興奮しているのでなかなか寝付けなかったが，疲れがでたのか目が覚めたら午前８時ぐらいになっていた．とても長い一日に感じた．
（５）工場に戻って
翌28日は秦野の神奈川工場から（ソフト）<->（（神）連絡バスに乗り（ソフト）に向かった．とても良く晴れた日であった．工場の自分の席に着くとRCM担当の主任であるMr.O.が早速お詫びに来た．Mr.O.は大卒ではないがとても優秀な技術者であり人望もあった．当時の日立には高卒者がいたが優秀な人が多かった．正直言って彼らでもっているような工場に思えた．余談だが，研究所でも高卒者は極めて優秀な人ばかりで，彼らは日本各地の工業高校を成績トップで卒業した人達であった．何らかの事情で大学に進学できなかっただけなのだ．話を元に戻す．Mr.O.主任には「お前でなく，何度も忠告したMr.M.を呼べ！」と怒った．Mr.M.は工場では学卒なので中位ぐらいのエリートなのである．その後，恐る恐る詫びに来た．
その後，私はシステム開発研究所川崎淳所長の自宅に電話を入れ，工期を守りVOS3/ES1を完成したことを報告した．川崎所長は大いに喜んでくれ我々の労をねぎらってくれた．
（６）新年の挨拶
1985年はシステム開発研究所に初出勤することができた．所員は講堂に集まり社長の年頭の辞を聴いてから所長の挨拶がある．所長は冒頭「昨年末に大変めでたいニュースが飛び込みました．吉澤君が脱IBMのＯＳであるVOS3/ES1を期日どおりに昨年末に完成させてくれました．これはシステム開発研究所の名を全社に高め，またコンピュータ事業への大きな貢献となります．本当にご苦労様でした．」という賛辞を頂いた．
（７）VOS3/ES1の開発を通して
この仕事は今まで日立で自由気ままに仕事をさせてもらった恩返しと思いやり遂げた．また，自分の力を試してみようとも思った．この両者を満足させることができたのは幸いであった．最初の目的であった脱IBMを達成する独自ＯＳの開発はできたし，依頼された31ビットアドレス拡張機能，31/24ビット両モードを同時に動かすバイモーダルオペレーション(bi-modal operation)も実現した．そればかりでなく，IBMにない新機能であるセグメント境界緩和方式；CSBR，オンデマンドスワッピング方式，ワンステージスワップ方式，実記憶マイグレーション機能，などの機能をドロップもスリップもすることなく最初のバージョンから作りこむことができた．実は，8月以降の検査部による検査で苦しんでいたときは，プロマネからは（シ研）さんは頼まれてもいない余計な機能を作りこんでいるからバグ収束が悪いのだなどと云われた．そしてこれらの機能をドロップ（落とせ！）せよとかスリップ（延期）して次のバージョンで入れたら，などと言われた．だがこれらの追加機能にはほとんどバグはなかったので，スリップやドロップは論外であった．
ソフトウェア開発の難しさは上記のような新機能の追加にあるのではなく，既存プログラムの改変にある．つまり，新しく機能設計して全く新しいプログラムを作るのは簡単なのである．それよりもPublic Domainという既存プログラムを解読し，そこに改変を加えることの方が比較にならないぐらい難しいのである．理由は簡単だ．他人が作った気心の知れない母体となるプログラムを理解するには桁違いの時間を必要とする．今回のように関連する設計書などのドキュメントがゼロの場合はなおさらのことである．ソフトウェア開発においては，まさに案ずるより生むは易しなのである．だがソフトウェア産業は殆どがメインテナンス産業になっているので，新規のプログラム開発よりは既存プログラムの改変が主となっていることを忘れてはならない．このためにも水面下の財産が重要であり，理解し易いドキュメントを整備することが最も大切である．水面上のプログラムコードだけ残すようでは，そのプログラムを一生抱え込むことになろう．
（シ研）からは我々以外に言語処理系や通信ミドルソフトウェアなどの脱IBMに駆りだされた人達がいた．これは全社を挙げて（ソフト）の危機を脱出するという(S)「これをマルエスプロジェクト」と呼んでいたが，取締役会議で決定した活動であった．その一環として（シ研）でソフトウェア技術があると思われる優秀な研究者を派遣したのである．だが，これらのマルエスプロジェクトに参加した人達で初期の目的を達成した人は居なかったと記憶している．中には指定プログラムを諦めてIBMからライセンスした製品もあった．実は研究所ではその製品に対する最も知見のある研究者であると言われていたのである．またある研究者は身体を壊して入院・手術となり工場から撤退した．皮肉なことに病気になった人間には同情的になり，私達のように元気で（シ研）に戻った人間には同情など無く，出来て当たり前という評価のように思えた．
＜先頭へ＞
＜戻る＞
＜目次へ＞
＜次＞
脱IBM VOS3/ES1開発
Copyrights all rights reserved, Y.Yoshizawa 2016-2017
（６）新年の挨拶
1985年はシステム開発研究所に初出勤することができた．所員は講堂に集まり社長の年頭の辞を聴いてから所長の挨拶がある．所長は冒頭「昨年末に大変めでたいニュースが飛び込みました．吉澤君が脱IBMのＯＳであるVOS3/ES1を期日どおりに昨年末に完成させてくれました．これはシステム開発研究所の名を全社に高め，またコンピュータ事業への大きな貢献となります．本当にご苦労様でした．」という賛辞を頂いた．
（７）VOS3/ES1の開発を通して
この仕事は今まで日立で自由気ままに仕事をさせてもらった恩返しと思いやり遂げた．また，自分の力を試してみようとも思った．この両者を満足させることができたのは幸いであった．最初の目的であった脱IBMを達成する独自ＯＳの開発はできたし，依頼された31ビットアドレス拡張機能，31/24ビット両モードを同時に動かすバイモーダルオペレーション(bi-modal operation)も実現した．そればかりでなく，IBMにない新機能であるセグメント境界緩和方式；CSBR，オンデマンドスワッピング方式，ワンステージスワップ方式，実記憶マイグレーション機能，などの機能をドロップもスリップもすることなく最初のバージョンから作りこむことができた．実は，8月以降の検査部による検査で苦しんでいたときは，プロマネからは（シ研）さんは頼まれてもいない余計な機能を作りこんでいるからバグ収束が悪いのだなどと云われた．そしてこれらの機能をドロップ（落とせ！）せよとかスリップ（延期）して次のバージョンで入れたら，などと言われた．だがこれらの追加機能にはほとんどバグはなかったので，スリップやドロップは論外であった．
ソフトウェア開発の難しさは上記のような新機能の追加にあるのではなく，既存プログラムの改変にある．つまり，新しく機能設計して全く新しいプログラムを作るのは簡単なのである．それよりもPublic Domainという既存プログラムを解読し，そこに改変を加えることの方が比較にならないぐらい難しいのである．理由は簡単だ．他人が作った気心の知れない母体となるプログラムを理解するには桁違いの時間を必要とする．今回のように関連する設計書などのドキュメントがゼロの場合はなおさらのことである．ソフトウェア開発においては，まさに案ずるより生むは易しなのである．だがソフトウェア産業は殆どがメインテナンス産業になっているので，新規のプログラム開発よりは既存プログラムの改変が主となっていることを忘れてはならない．このためにも水面下の財産が重要であり，理解し易いドキュメントを整備することが最も大切である．水面上のプログラムコードだけ残すようでは，そのプログラムを一生抱え込むことになろう．
（シ研）からは我々以外に言語処理系や通信ミドルソフトウェアなどの脱IBMに駆りだされた人達がいた．これは全社を挙げて（ソフト）の危機を脱出するという(S)「これをマルエスプロジェクト」と呼んでいたが，取締役会議で決定した活動であった．その一環として（シ研）でソフトウェア技術があると思われる優秀な研究者を派遣したのである．だが，これらのマルエスプロジェクトに参加した人達で初期の目的を達成した人は居なかったと記憶している．中には指定プログラムを諦めてIBMからライセンスした製品もあった．実は研究所ではその製品に対する最も知見のある研究者であると言われていたのである．またある研究者は身体を壊して入院・手術となり工場から撤退した．皮肉なことに病気になった人間には同情的になり，私達のように元気で（シ研）に戻った人間には同情など無く，出来て当たり前という評価のように思えた．
＜先頭へ＞
＜戻る＞
＜目次へ＞
＜次＞
脱IBM VOS3/ES1開発Copyrights all rights reserved, Y.Yoshizawa 2016-2017