同時に、プログラミングの標準による古い本、「魅力的なタイトル「What Mom Never Told You About VM Escort」」の本を思い出しました。 元のタイトルは、メリンダ・W・バリアンによる「母親がVMサービスについて決して言わなかったもの」です。
したがって、しばらくの間、これは1983年です。 MS DOSの最初のバージョンが登場しました。 CVSの出現はまだ約8年待ちます。 Unixは既に存在しますが、まだ配布されていません（モスクワでは、1986年頃にSM-4マシン上でデモ形式で表示されます）。 当時のほとんどのコンピューター本は、今日では絶望的に古くなっています。
この本は、システムプログラマー-VMシステム（CP 67、VM / 370、VM / SP、VM / ESA、および他の多くの名前としても知られている）の保守に関与した人を対象としています。
このような本は、今日の管理者にとって興味深いものと思われます（おそらく、これは当時システムプログラミングと呼ばれていたアクティビティに最適でしょう）。 見てみましょう、自分で判断してください。
そのため、この本は、カーネルの生成、IBMから受け取った更新とバグ修正の適用、バックアップの作成などに専念しています。
結局のところ、それも可能ですか？
プログラミングに関する私の見解を変えた最初のことは、カーネルコードを変更する方法でした。 今日はそれをパッチと呼びます。 原則として、OS / 360以降、IEBUPDTEユーティリティは長い間知られており、CMSのUPDATEユーティリティのパッチ自体の構文は非常に似ていました。 違いは、パッチ自体がXEDITテキストエディタを生成できることでした。 元のファイルを変更する代わりに、彼はパッチを作成し、それをUPDATEを使用して適用しました。
カーネル生成のプロセス自体はこのように単純化されています-S / 370アセンブラーカーネルソース、コンパイル済みオブジェクトファイル（一部のソースは提供されていません）、マクロライブラリ、いわゆるCONTROLファイルのリストを使用してカーネルにパッチを適用し、次にアセンブラー、リンカーで構成される配布キットを取得します、カーネルをディスクに書き込みます。
完成したカーネルには、システムプログラマがマクロから作成した周辺機器のテーブルも含まれていました。
原則として、複雑なことは何もありません。
しかし、2つの異なるパッチセットを適用することで2つの異なるバージョンのプログラムを入手できるという考えは、私と同僚のほとんどにとってまったく新しいものでした。
もちろん、UPDATEは（XEDITを使用しても）Gitではありません。 さらに、これはCVSでもありません。 これは、RCSの機能にほぼ対応していますが、ほぼ同時期に登場しました。 しかし、これは実際に私が出会ったコードバージョン管理の最初のアプリケーションの1つでした。
システムプログラマのサバイバルルール
本の2番目の、より技術的な部分には、システムのさまざまな部分に個別にリリースされたパッチを含むパッチの適用方法に関する情報が含まれていました（CMS生成にはいくつかの機能がありました）。
技術的な詳細は省略し、著者が従うことを推奨しているルールのリストのみを提供します。
- IBMが送信するものを変更しないでください-IBMから送信されたものを変更しないでください
- スタッフをIBMから分離する-ファイルをIBMファイルとは別に保管する
- 動作することを期待しないでください-動作することを期待しないでください
- 常にトラックを残す-変更の痕跡を残す
- VMシステムプログラマーは、常に仮想化を行います-新しいシステムはいつでも確認できます
- BACK IT UP-バックアップを作成します
- もう一度バックアップ-再度バックアップ
- DDRを信頼しない-DDRを信頼しない
- 未解決の参照を確認-未解決のリンクを確認
- バックアップの計画-バックアップとロールバックを計画する
- あなたはホームターミナルに参加します-あなたはあなたの（ホーム）ターミナルを使うべきです
- 一度に1つずつ変更する-一度に1つのものだけを変更する
- Sディスクが多すぎることはありませんSディスクは多すぎません
明らかに、いくつかのポイントには明確化が必要です。 たとえば、ルール5は、仮想マシンで起動することで新しく構築されたカーネルをチェックできることを意味します。つまり、VMは変更を確認するために実際のマシンの時間をかける必要がありません。 、機能制限はほとんどありません。
ルール8では、ディスクダンプ復元ユーティリティについて、特にテープが読み取られない状況では、ダンプ自体とダンプを作成して復元するユーティリティの両方を信頼すべきではないと述べています。
最後に、規則13は、このドライブが指定されたという文字で、CMSシステムSディスクについて述べています。 これは、必要な量のCMSのバックアップコピーを保持できることを意味し、それらの数が多すぎることはありません。
残りの点は説明なしで明らかです。
変更の前にシステムのバックアップを作成し、それらを再度実行し、ディストリビューションとは別に変更を保存し、ディストリビューション自体を変更せず、一度に何かを変更します-多くの人が今日サブスクライブするでしょう。
さらに、システムプログラマのチームにとって、この本は必読の書であり、VMに関する通常のドキュメントとともに、ほとんどデスクトップの本でした。 ちなみに、z / OSシステムプログラマー向けのフォーラムでは、この本はまだ推奨されています。 VM / 390の現実を反映して、新しいものをリリースする計画さえありました。
私はこれ以上語りません。 コンピュータの履歴に興味がある場合は、自分で読んでください。
この本は、メリンダ自身のサイトで、インターネット上でPDFで入手できます。 既存のプリンター用に作成された元のフォーマットを保存しました。
約120ページあり、コンピューターとOSの歴史に興味があるすべての人にとって興味深いものになることを願っています。
そして最後に、私たちが違反しないようにしようとした私たち自身の生き残りのルール：すでに夕方になっている場合、システムを生成しないでください-結果を修正するために一晩滞在する可能性が高いです。
素敵な読書を！