ホワイトニングがいい感じになったのでキーを取り付けたのですが、何故かMキーがなくなってた。バネもなくさないように箱に入れながら保管したのですけど、2個足りないし。バネはもしかすると２つ使ってると思って付けたキーを外して見直してみたけど不明。SHIFTキーはバネ１つにしたけど、これも含めると４つ消えてることになる。謎です。
Mキーはもしかすると漂白時にビニール袋を使って入れ替えを２回してたのですが、最初に袋に残ってた可能性があるか？よくわからんです。流用できるキーがあれば手配したいところ。
起動もさせてみたら、コンポジット接続では問題なく映ります。キーが微妙で、ファンクションキーが効いてる気配なし。BASICをロードしてキー定義されれば使えるか？それとINS/DELキーが効いてなさそう。これも微妙だけど、モニターで画面クリアはできたたはずなのでダメージを受けてるかも。本体をあけて基板をチェックしてみないとわからん。
以前動いていたMZ-700ですが、電源ケーブルが見当たらないので動作確認できず。キーが黄ばんでるので、キートップを取り外して漂白中。酸素系漂白剤で紫外線を当てると化学反応できれいになるらしいのでビニール袋に漂白剤を薄めてキートップを突っ込み、日の当たるところに放置中です。
キーはファンクションキーとINS,DELはバネの位置が微妙で、組み立てるのが厄介そうだったので外してません。色はオリジナルに近いので問題なさそうですので。スペースバーの外し方がわからないので、やめておきました。おそらく3か所くらいとつながっていて、バネの代わりに金属のバーがついてると思われますが、外して戻せないと悲しくなるので諦めです。本体の上面もだいぶ黄ばんでますが、これは後日漂白剤を霧吹き状態で吹き付けて漂泊してみようかと考え中。これらの黄ばみはメラミンスポンジでこすっても落ちませんから化学の力を利用しないとダメっぽい。
漂白が終わる前に電源ケーブルを探しておくか。なければ削って作ればいいし。
https://news.yahoo.co.jp/articles/26f9295e952a0efb974649cb105d07d60d74766a
カレーやみそ汁を一晩放置して危険ってどんな環境だろ？って思った。環境に依存すると思うが、火を通してにおいや状態を確認するのが当たり前だと思うのだが。みそ汁ならねばついたり、味が酸っぱくなったりするので見た目や一口でわかるはず。夜作ったのなら、朝に火を通しておけば昼に食うのには何の問題もない。場合によってはその晩でも問題ない。さすがに二日経過するのは危険ではあるのだが。
カレーだって朝に火を通せば、夜くらいまでは何の問題もない。可能なら昼も火を通しておくといい。それでも菌が残ってダメになるケースもありますが、これも環境依存じゃね？人生で何度か腹痛を起こしたことがありますけど、発生するケースは稀。頻繁に起こるなら生活環境を見直したほうがいい。
そもそも、食いきりの量で作るのがベストであって、作り置きしなければこんな問題は起きないと思うのだが。食事の用意が面倒とか論外だし。みそ汁だって2回づつけて同じものは食いたくない。冷蔵すればって意見もあるが、確実に味が落ちるし、同じ食事が続くのは苦痛じゃ？って思う。つか、みそ汁なんて自分はほとんど飲まないので関係ないけどね。
プロセスは異なるメモリー空間で動作するプログラムです。利用時にログインしている端末もログインプロセスといわれるプロセスの１つです。提供されるコマンドやユーザープログラムをログインプロセス上で動作させて利用していきますが、バックグランドで動かすことも可能です。start_processコマンドを使うと、指定したコマンドをバックグランドで動かすことができます。パラメータを多く指定する必要がありますが、それぞれ意味を持ちます。重要なパラメータの１つにOUTファイルの指定があります。これはバックグランドで動いた場合に出力される標準出力のファイル指定です。実行結果はこのファイルへ書き出され、結果の検証などに使われます。
ログインプロセスも標準出力を持っており、list_port_attachmentコマンドでプロセスが使用しているポートを一覧すると、最初のほうに表示されるTERMINALが相当します。つまり、コマンドを実行した結果は実行した端末に表示されるということになります。
よく利用されるバックグランドプロセスは、起動したらキューや何らかの外部要因で処理を行い、停止するまで実行し続けます。停止はユーザーがプログラムした手法（キューで停止命令などを送って処理させたりいろいろ）で行いますが、停止させるコマンドもstop_processというコマンドで用意されてます。例えば、list_usersコマンドを定期的に実行するコマンドマクロを用意してバックグランドプロセスで実行させておき、データが取れたと思ったらstop_processで停止させ、出力されたOUTファイルを解析してパフォーマンス測定を行ったりできます。
プロダクツとしてプログラミングする場合は、バックグランドで動かすプログラムを起動・停止するプログラムを用意しておき、ユーザーに提供して利用してもらう形になります。この辺りの作りこみが必要ですが、細かく作れば動作状況もわかりやすく設計できると思いますし、満足されるプログラムになるでしょう。
当然ながらstart_processコマンドではなく、APIとしてのルーチンも提供されております。s$start_processがそうで、これもパラメータを多く必要としますがユーザープログラムから任意のプログラムを起動させることが可能です。また、プロセスを扱うプログラムはプロセスが起動時に割り当てられる「プロセスID」を使うことで当該プロセスの情報取得・操作も可能です。当然自分がいま使っているログインプロセスの情報も取れますし、異なるプロセスの情報も取得可能です。ただし、アクセス権がないと拒否されます。
Stratus VOSもLinuxなどでも存在するシグナルをサポートしてます。s$enable_condition、s$signal_conditionなどのAPIが提供されており、シグナルを受け取ると自前のルーチンへ制御を渡すことができます。PL/Iを使用する場合、言語としてシグナルハンドラーを記述することができますので、言語の機能で実装するのもアリかと思います。
シグナルは使いどころが難しく、何でも処理しようとルーチンを書いた場合、エラー調査が難しくなったり、情報を取り損ねるとデバッグが困難になるケースがあります。プロセスは障害などでシグナルを発生させた場合、デフォルト動作にて動作するようになってます。大抵は端末につながるプロセスなら継続するか停止するかなどの問い合わせを行うようになってます。常駐型のプロセスならキープモジュール（コアダンプ）を作成して停止するようになってます。デバッガを起動してデバッグもできますし、エラーメッセージから状況を判断することも可能です。これらのシグナルも自前のルーチンで処理しようとすると二度手間になる場合がほとんどかと思われます。
まあ、常時別のプロセスに状況を送るようなプログラムで、異常状態を検知した場合に当該プロセスへ通知させてから停止なんてプログラムの場合にはいいのかも。
異なるプロセス間でメモリーを共有する手法として共有メモリー（SVM)が提供されます。Linuxなどで言う共有メモリと同じです。ファイルシステムとプログラムもメモリアドレスを合わせておくことで利用可能となります。
プログラムはSVMへ接続すれば通常のメモリアクセス（構造体や配列など）と区別なくアクセスができます。複数プロセスが同時にアクセスしますから、メモリの排他制御の問題が発生します。各プログラム間で特定領域をアクセスする時に排他制御をそれぞれ行う必要があります。OSのバージョンによっていろいろ変わりましたが、自分が知りうるバージョンではスピンロックのサブルーチンが提供されました。この参照場所を合わせてロック・アンロックすることで排他制御を可能にしてました。
キューは先入れ先出しのプロセス間通信です。送る側をリクエスター、受け取り側をサーバと名付けており、通常はリクエスター・サーバ構造となります。キューはメッセージキュー、１Wayサーバキュー、２Wayサーバキュー、ダイレクトキューが存在します。よく使うのは最初の２つ、場合によっては２Wayサーバキューも利用します。APIはs$msg_xxxという名前のルーチンが提供されてます。
メッセージキューはサーバが動作してようかしてまいが送り込めるキューです。プリンターのキューによく使われており、印刷のリクエストを送ってスプーラーが動作してれば印刷されますし、動作してなければリクエストは溜まっていくという感じです。ファイルI/Oに類似しますが、先入れ先出し機能で最初に投入された要求から処理できるのが大きなメリットです。
１/２Wayサーバキューはサーバが動作して受け入れ可能になってる場合に利用できます。サーバはメッセージが到着すると受信処理を行いメッセージを受け取ります。１Wayサーバキューはリクエスタがメッセージを送るとリクエスタ側は処理が完了します。一方的に送り付けるような処理に向いてます。２Wayサーバキューはリクエスタがメッセージを送信しても、サーバが受け取り完了の通知を行わないと処理完了を待たされます。確実に受け渡しを行いたい場合に使われます。
ダイレクトキューはあまり使ったことがないので各自で調べてみてください。
Stratus VOSにおいて、キューは重要な機能の１つで使いこなせると高度なプログラミングが可能です。
あまり時事ネタは反応したくないのだが、ちょっとだけ。
レジ袋有料が義務付けられましたが、これはこれでいいと思います。そもそも袋の対価を支払わないのはおかしいと思うし、ごみの一部になるのは確実なので、軽減する意味での有料化は意味があると思います。そもそも問題となるプラスチックごみのレジ袋に対する比率は大したことないなんて意見もありそうですが。この辺りは専門家ではないので何とも言えません。少なくとも素人考えではごみの軽減につながる要因の１つと思ってます。
新型コロナの影響で、マイバッグが不衛生で使いまわしがよくないという話もみた。それは使ってる人が悪いのでは？と思う。自分もマイバッグにしてから１０数年経つけど、マイバッグの洗濯は結構行ってる。どんなに注意しても、カットフルーツや肉、総菜は汁が出てしまうからです。ドリンクも気温によっては結露して濡れるし、マイバッグは結構な確率で汚れてます。それを知らずに使いまわす方が無知なだけだと思いますがどうでしょうね？
吉野家が不衛生だからレジ袋を無料化と踏み切りましたが、そこで浮上した袋の使いまわしが不衛生という事態に気づかされ、マイバッグは不衛生と思い込む人たちが多く見られたのが笑えたよ。そもそもどんな持ち物も使えば汚れるんだってこと。常識だろ？
１０数年前に東京にいたころは、ごみの軽減をよく考えてたよ。今では問題視されてしまいましたが、スーパーで買い物をしたら、マイバッグに詰め込むときに、不要なパッケージを開けて中身だけしまい、出たごみはスーパーのごみ箱へ捨ててました。カレーのルーとか外箱はいらないし、野菜をくるんでる包装も不要、大きな袋に小分けで入ってるものはみんな中身だけ持ち帰って外の袋は廃棄でした。今は家庭ごみを持ち込むと問題になるのでできませんけどね。これによってごみがかなり軽減できてましたよ。当時のスーパーには迷惑をかけたのだろうけど。そういう仕組みが社会でできてればごみの軽減もできるように思える。つか、過剰包装しすぎなんだよね、日本は特に。トレイだって邪魔なだけだから、袋詰めで十分だし、可能なら自分で必要な分を袋詰め出来た方がごみが減らせるし、野菜なんて袋はいらないしね。衛生上とか理由をつけてるからこそごみが蓄積される。
今回のレジ袋有料化は裏取引がありそうな気がしてますけど、もう日本はすべて有料でいいと思う。海外なんて関係ないだろ？自国や未来の為に決めたのだから突き進むべき。それと、レジ袋で末端の店などを叩くのは論外。制度を決めた政府にクレームを。
Stratus VOSにも異なるプロセスの間でデータを共有ややり取りする手法が提供されてます。共有や受け取りを行うには事前にプログラミングしておく必要があります。任意のプログラム同士でデータをやり取りというのは難しいです。
簡単な通信の１つにイベント通知があります。AプロセスからBプロセスが通信を行うとすると、Aプロセスからイベント通知APIを呼び出すとBプロセスへ通知され、Bプロセスはイベント通知のイベントが発生します。当然Bプロセスはイベント通知を受けるためにイベント通知のイベントを待っている状態でなければなりません。イベントは実ファイルを使って処理されます。最初に実ファイルパス名を決定し、s$attach_eventというAPIを呼び出してイベントの用意をします（ABプロセス双方とも）。Aプロセスは通知にs$notify_eventというAPIを呼び出すことで通知処理を行います。Bプロセスはイベントの用意後に戻されたIDとカウントを使用してs$wait_eventにてイベントを受けるまで待機します。（他のイベント待ちする処理も行っておく）Aプロセスから通知されるとs$wait_eventから抜けてくるので、s$read_eventというAPIでイベント通知を受けます（当然の処理として、待機する何のイベントが発生したのかチェックする必要がありますが）。これで通知されたことによる各種処理を実施することになります。イベント通知には４バイト(fixed bin(31)サイズ）のイベントデータの受け渡しも可能です。これを超えるデータを渡したい場合は、別の手段を使う必要があります。
イベント通知は、何らかのファイル作成をしてその完了を通知するとか、簡単なプロセスへの制御などで使われる可能性があります。まあ、ファイルも巨大でなく、レコード単位の受け渡しだとキュー通信を使った方が処理が簡単になります。また、プロセス間通信ではないですが、タイマーイベントという一定時間経過したらOSから通知してね・・・みたいな使い方もできます。イベントの用意をしたら、s$set_time_eventというAPIで秒数を指定してイベントを待機し、通知されたイベントを判定してタイマーイベントなら当該処理を行うという使い方をします。イベント通知が不要になったらs$detach_eventでリソースを解放します。プログラム終了時にも解放されますが、自分が使ったリソースは自分で解放した方がマナーがいいと思いますし、ルーチンを別のプログラムへ流量したときに解放し忘れがなくなると思われます。
久々にVOSの話でも。
Stratus VOSのI/O動作には同期モードと非同期モードがあります。ファイルを読み書きするときは通常デフォルトの同期モードで行われ、オペレーションが完了すればI/O動作も終わってる状態となります。短時間で処理される動作なら同期モードでも支障ありませんが、通信などでいつ読み込まれるかわからない場合では同期モードでは処理が止まってしまいます。
例えば、内部的なコマンドを受け付け処理と外部からのデータ受信処理を行うプログラムを作る場合、２つの事象（イベント）を同時に処理する必要があります。これが行われてないと、外部データを読み込みしてる間に内部コマンドが届いても処理できなくて困ってしまいます。そこで登場するのが非同期モードです。
非同期モードは通信やキューなどのプロセス間通信で使用されます。ファイルI/Oでも使用できますが逆に処理が煩雑になります。読み取りで威力を発揮し、読み取り動作を行うとデータがあればデータを戻し、無い場合は受信のイベントを待てという指示としてe$caller_must_waitというエラーコード（実コードは1277)を戻します。そしてプログラムは受信などの動作が完了時に通知されるイベント通知をもって処理再開を行います。イベントを待つのにs$wait_eventというAPIを使用し、処理が完了するとイベント通知されたかわかるという仕組みです。上記の例のプログラムだと、内部コマンドを受け取るイベントと外部データを受け取るイベントの２つを待ち、発生したイベントを判断してそれぞれの処理を行えばいいわけです。これで外部データ受信待ち中に内部コマンドでプログラム停止命令などを受けると正常に終了させられたりできるわけです。
VOSではポートを介して一貫したイベント処理とI/O処理を提供してくれるので、あらゆるI/O動作を簡単に処理できます。これが通信に強いとされる根幹です。