VOSにもUNIX系システムにあるようなプロセス間での同期処理やデータ共有を行うための仕組みがあります。

１．イベント通知
ダミーのファイルを用意して、受信側プロセスへ送信側プロセスからイベントという通知を行うことができます。業務ではあまり使う機会がありませんでしたが、使い方では利用価値があります。

２．キュー
キューという特殊なファイルを使っての通信手段です。一方通行の1 Way Server Queue、データの送受信ができる2 Way Server Queue、相手がいなくても送れるメッセージキューがあります。それぞれのキューによってアクセス方法が異なるので、用途に合わせた作りこみとなります。

３．共有メモリ
物理ファイルと合わせてプロセス間でメモリ共有を可能にします。同じアドレスにデータをマップし、それぞれのプロセスでメモリI/Oを瞬時に別プロセスへ反映できます。別プロセスで同じメモリアクセスを防ぐのにロック機能を使用して排他制御を独自行う必要がありました。

４．シグナル
シグナルもAPIが用意されてます。シグナル処理をしてないプログラムは、シグナルを受信するとデフォルト動作を行います。BREAKシグナルだと、プロセス情報を表示してユーザープロンプト待ちにできます。端末がないプロセスは終了しますが。デフォルト動作が異常事態にわかりやすい情報を残すので、慎重にプログラムしないと情報を失ってしまう場合もあるので実務ではほとんど使いませんでした。

Stratus VOSの強力なユーザーインターフェイスにコマンドFORM機能があります。作成するプログラムやコマンドマクロ（いわゆるシェルスクリプトみたいなもの）に一定のコーディング規則の１つとして、プログラムにはs$parse_command、コマンドマクロには&begin_parametersという記述を加える事で、一貫したFORM機能を持つこととなり、プログラムの引数をユーザーから指定して渡すことができるようになります。
それ故、引数が不明なコマンドでも、コマンド名をタイプしてDISPLAY FORMキーを押すか、引数に-formを指定すると画面にどのような引数を受けられるか表示します。必要なデータを指定して実行するとコマンドを実行できます。コマンド名がわかっていて、引数がわからない場合に有効です。コマンドもコマンドマクロも同じように表示されるので、ユーザーにはコマンドなのかコマンドマクロなのか区別することなく同じように利用できます。コマンドFORMを開いて、実行のキャンセルもできるので、ユーザープログラムも規則に従ってプログラムしておいた方が便利になります。まあ、こんな機能不要！と割り切ってプログラミングするのもアリですが。

サブルーチンリファレンスでもs$parse_commandの説明が一番長いと思われます（記憶が若干あいまいですが）。この機能だけでも1冊のマニュアルが書けてしまうくらい多機能なのでプログラミングする方は熟知すべきサブルーチンの１つです。

Stratus VOSにはForms Management System(FMS：書式管理システム）というtelnetなどの端末上で画面制御を行う非常に強力なパッケージを持ってます。LinuxでnCursesがありますが、それに含まれるformライブラリがそれに近いと思います。Formという言葉から想像できると思いますが、画面を帳票イメージで表示を行い、入力項目の入力を促し、プログラムは1画面単位の情報を受け取って処理することができます。Windowsなどで言う、ダイアログというか１ウインド単位での画面I/Oを行う感じです。
今現在で、画面操作を行おうとすると、Webサーバを立ち上げてCGIなどでサーバへデータを受けて処理するようなシステムが主流かと思いますので、レガシーな方法となってるのかも。
画面のI/Oでも多言語対応ですので、背景項目や入力項目に漢字やいろいろな言語を使うことが可能です。まあ、それなりに使い込んでないと多言語を扱うのは設定とプログラミング技術が必要でしたけどね。漢字とカナで2言語なので、その使い分けは意味を知らないと何でこういった設定で、こういった処理が必要か理解できないと思います。業務で使うノウハウや日本語マニュアルは残してきたので使い込めてるでしょう。

このシステムが、約30年前に普通に使えたので、UNIX系OSで画面操作を行おうとしたときは、FMSを移植しないとダメかな？とか当時思いました。無いものは仕方ないので、それなりなものは提供しました。韓国へパッケージを売った時は、取り扱ってた会社が独自の画面操作プログラムを持ってたので、それが入手できていれば開発環境もだいぶ変わったのかなと当時思いました。それから時代に流されながら生きてしまったので何も残せなかったのがやや心残り。

vosでは、古くからいろいろな言語サポートがあります。日本語はもちろん、韓国語やギリシャ語など世界各国で使えるようになってます。
業務で使ってるケースでは、デフォルトの英語で使用してました。日本語にするとファイル一覧などでタイムスタンプが出るときに日本語で出力しようとするので、端末によって表示できないケースもあるので設定してないのが現状でした。オンラインドキュメントに日本語サポートがなかったので、英語での利用でも問題なく行えました。細かいところまでローカライズできてないので、あえて日本語にする必要性もないという。

英語がメインでも、日本語表示などはできます。シフトモードという表示コードの切り替わりを示すコードを持ってます。JISコードを使うPCなどで、カナコードの開始を示すのにSI,SOというコードを使うものがありますがそれと同様です。コードが変わる最初に指定するロッキングシフトと文字コードそれぞれに指定するシングルシフトコードがありました。ですので、こういったコードを含むファイルなどを表示するデバイス（端末、プリンタ等）に送り込むと、コードに合わせていろいろな言語を表示できました。

日本語は漢字コードを示すものと、カナコードを示すものが2種類サポートされており、区別しないといけなかったのが面倒でした。ちなみに、漢字コードの場合に使われる文字コードはJISコードにMSBをONにしたものが使われてました。PCにバイナリデータを持ってきたときは、シングルシフトコードを取り除き、漢字２バイトに対して0x7F7FとORしてJISからSJISへ変換すると漢字コードを復元できました。カナコードはシングルシフトコードを取り除くだけだったのですけどね。

ちなみに、真のデフォルト文字コードはラテン語だったりする。OSインストール時に英語に設定してるので気づかない場合がほとんどだと思われます。なので、コードを扱うプログラムで、デフォルト値がラテン語というのがわかるかと思います。

VOSはプロセス・プログラムのI/Oにポートという概念を持ってます。プログラムのI/Oはポート番号でアクセスし、結びつけられたファイルや通信デバイスなどのI/O操作を行います。まあ、どんなOSでも似たような概念を持ってると思いますが、それらとほぼ同じです。
ログインしている端末で、list_port_attachment(lpa)というコマンドをたたくと、ログイン端末が今接続してるポート情報の一覧を出してくれます。情報には、ファイル名やデバイス名、オープン状態などが得られます。よく使うのは、mp_debugコマンドで実際に動いてるプロセスへ接続して、コマンドを打ち込んで実際に使用しているファイルやデバイスを調べたりします。
ファイルへアクセスするには、s$attach_portというAPIを呼び出し、物理的なファイル名とポートを結びつけます。戻されるポート番号を使て、ファイルのオープン、I/O、クローズなどの操作を行っていきます。使われたポートの開放はs$detach_portというAPIで行い、後始末を行います。
通信といってもレガシーなX.25、SNA、SDLCなどは通信ボードが古くからサポートしてるのでポートが使われてますが、TCP/IPはユーザーから見えにくくなっていて一般的なソケットでのI/Oとなります。

Stratusの耐障害性は、ハード的に行われていて、アプリケーションプログラムは意識する必要性がありません。CPUボード、メモリーボードなどがすべて二重化されていて、片方が障害となっても動き続けます。当然双方障害だとだめですが。１つのボードも中身が二重化されていて、ボード内でも障害検知が行われます。それ故、故障したボードをオンライン中に抜き差ししても問題ないという。
ハード障害でアプリ的に問題（エラー検知）されるのは、通信障害くらいでしょうか。通信ボードは相手との接続の関係もあり、接続自体を二重化できませんから、バックアップに切り替わるときに回線が切断されたり、停止します。この時アプリには回線切断の事象が通知されます。この辺りは、アプリケーション的にエラーリカバリするのが一般的でした。（データを破棄して、相手側にタイムアウトを検知させるとか、エラーの通知を行う等）

TANDEMでは、CPUボードが停止すると、そのCPU上で動くプログラムはすべて停止します。プログラムをソフト的に二重化して対応しており、メインプログラムとバックアッププログラムを別CPUで動かし、同期をとりつつ動作し、障害時にプログラムが切り替わるという手法でした。こういった手法をプログラミングしなければならなかったので、プログラマーにかかる負担が大きかったです。
パッケージを移植するために初期調査している段階で、ＨＰの技術者にいろいろ聞きながら移植作業をおこなってましたが、この二重化の部分で聞いた情報が間違っていて、後に障害対策で苦労した記憶があります。ファーストユーザーに導入し、動かしてある程度の取引を処理したら、突然エラーが出始めたり、障害テストでCPUダウンさせて切り替わりのテストでバックアップがさらに停止したり散々だった。結局マニュアルを読み直して対応したのですが、社内の周りからの目は痛かったです。自分のスキルの低さもあったのだろうけど、自分的には騙された感の方が強かったと思う。

とまあ、ライバル２機種で比較すればStratusの圧勝って感じが今でも強いです。

標準でサポートされるエディタはEmacsです。本家とは違い、VOS用にカスタマイズされたものです。Emacs LISPは使えませんが、カスタマイズは可能です。unformatted edit（通称edit）というワードプロセッサもプロダクツとして提供されており、購入してると利用可能です。やや重いですが、行選択などで反転表示してくれたり、わかりやすい操作性で愛用してる人も多かった印象です。インターネットが普及してから、公式のFTPサイトからフリーウェアなども利用でき、viも利用できました。

一応、line_editというラインエディタもありますが、これをメインで使うことはなく、シェルスクリプトに相当するコマンドマクロから呼び出して使うときに利用されます。また、PC性能がアップしてからは、PC側でソース編集をしてFTPでアップロードというやり方もできます。FTPサイトからSambaを入手して設定しておけばWindowsからエクスプローラ経由でアップロードも可能でした。

Stratus VOSには、いくつかファイル属性を持ってます。１回の読み書きで扱うデータを１レコードすると、レコード長が固定となる固定長ファイル、固定長にレコード番号を持つ相対ファイル、レコード前後にレコード長を持つシーケンシャルファイルがあります。また、パソコンのDOSやUNIX系ファイルと互換をとるためと思われるストリームファイルというものも存在します。特殊なファイルとして、プロセス間通信で使われるキューファイルもサポートされてます。プログラムのソースファイルには、シーケンシャルファイルかストリームファイルが使えますが、シーケンシャルファイルで作るのが一般的です。

ファイルにはキーをつけることができ、レコードの一部を使う組み込みキーをよく使われます。例えば、レコードを識別する通番や社員番号などの位置をキーにして、昇順に読み取ったり、ユーザー指定のキー内容で当該レコードを読み取ったりするのに使われます。この強力なキー機能により、データベースを使わなくても業務アプリの開発ができるので、使い勝手がいいです。トランザクション保護も使い込むと使えるのですが、自分の携わった業務では使わない方向で作られてました。

Stratus VOSでサポートされるコンパイラ言語は、PL/I、COBOL、Pascal、Fortran、BASIC、Cが使えます。OpenVOSのサポートがあるとGNU C、C++も使えたと思います。自分が辞める時にはこの辺りが曖昧でしたので、実際にGNU関係は使ってませんでした。まあ、メジャーなツールはFTPで落としてコンパイルして使ってましたけどね。PL/Iはデフォルトでサポートされますが、他の言語は有償サポートだったと思います。C言語はソケットを使う上で必須なので、TCP/IPが普通に使われるようになってからインストールされてる可能性が高いと思われます。それ以外の言語はまず使われることがないと思われます。使えればかなりマニアックな環境と思います。最初に使ったマシンは、すべての言語と数多くのパッケージが入ってました。何らかの大人の事情で使えてるっぽかったけど、詳細は聞かずじまいだった。

何でPL/Iなんだ？って思いますけど、カーネルがPL/Iで書かれており、システム提供のAPI（s$・・・エス・ダラーで始まる名前のサブルーチン（関数）群）の引数受け渡しがPL/I言語でサポートされるデータタイプを持つので、プログラムを書くのに一番ストレスなくできます。他の言語でも受け渡しが出来るように言語拡張されてますので、どの言語で書いても問題ないです。生成されるオブジェクトもPL/Iが一番スマートだったと思います。

IT業種から離れて結構経つので思い出話でも。所属していた会社の社外秘には触れないように書きます。

約20年間ストラタスコンピュータ社（現ストラタステクノロジー）のフォルトトレラントマシンで開発を行ってました。引き合いに出されるライバルマシンはTANDEM社のマシンです。停止しては困るミッションクリティカルな業種で使われており、証券取引やクレジットカードのオンライン業務で活躍してました。Stratusの無停止技術は、ハード的に二重化していて、システム稼働中にボードを抜き差ししても動き続ける一風変わったシステムでした（当然二重化されてる双方のボードを抜けば止まりますが）。TANDEMのソフト的に障害復旧処理を記述しておかないとだめだったのに対してソフト的には何も特別な処理を必要としなかった点が面白かった。

最初に使ったマシンはモトローラ68000を搭載していて、当時携わったプロジェクトでのアプリケーションプログラムの5000ステップくらいのソースプログラムをコンパイルするのに20分くらいかかったりしてました。その後、Intel i860を搭載したマシンを使ったときは早くて感動したものです。今のご時世なら、ソースをコンパイルし、エラーを訂正してコンパイル・・・って感じに開発していくと思いますが、当時はソースリストを印刷してエラー修正を書き込んでおき、一気に直してコンパイル、コンパイルの間コーヒータイムって感じだったかな。作るプログラムは１本じゃないからコンパイル中に別のソース編集って感じでしたけどね。i860の後にPA-RISCマシンが出た辺りからはソースの印刷は、目が疲れて机上で確認するときくらいになっていったかな。
StratusのOSはVOSというMulticsから派生したUNIXみたいな独自OSでした。利用はシリアルケーブルを直結した端末か、telnet経由での端末での作業がメインとなります。シリアルケーブル接続時代は、端末はマシンルームにあり、デスクでソースを紙に書いて作成し、マシンルームにもっていって端末から打ち込み、コンパイルって感じだった。この時代にテストフェーズになると端末を複数利用して行うのですけど、端末の奪い合いになるので夕方に出社して夜中に作業、始発で帰るって日も結構ありました。今となっては、一人一台PCが与えられ、telnetで複数端末を立ち上げて作業が出来て快適になりましたけどね。

Stratusで会社のメインパッケージを作る前に、Sequioa SystemのUNIXマシンを使ったことがあります。このマシンもフォルトトレラントマシンでした。それと、辞める前の数年間はTANDEM・・・後のNonStop Serverも使って開発をしてました。当時、ヤフオクにNonStop Serverが出品されて内輪で話題になりまして、結局hpの中の人が落札して使える部品を確保したとかという話を聞いたような聞かないような。