PDP-11のTRAP命令のバイナリ表現が104400から104777の256個もあるのは何故だろう

PDP-11/40上で動作するUNIX V6のlow.sを解析するため、PDP-11の命令について調べています。low.sの中ではTRAP命令は使われていません。ただし、紛らわしい事に、m40.sの中で定義されている「trap」という番地を参照しているので、うっかりするとTRAP命令が使われていると誤解してしまうかもしれません。

PDP-11 processor handbookでTRAP命令を確認すると、対応するバイナリ表現が104400から104777までの256個もあります。普通なら、BPT命令なら000003とか、IOT命令なら000004などのように、1対1に対応しているはずです。TRAP命令だけではなく、EMT命令も104000から104377までの256個用意されているので、何か意図がありそうな気がします。

 

EMT命令、TRAP命令、BPT命令、IOT命令は、PDP-11においては、それぞれの命令に専用のTRAP VECTORを介して、それぞれのルーチンに飛ぶようになっています。BPT命令なら014番地、IOT命令なら020番地、EMT命令なら030番地、TRAP命令なら034番地です。各命令に1つずつしか用意されていません。と言うことは、EMT命令やTRAP命令のバイナリ表現が256種類あったとしても、全て同じTRAP VECTORが使われる訳ですから、区別できません。しかも、256種類のバイナリ表現があり得るとしても、その値がレジスタに格納される訳でもないので、普通にプログラミングしているだけでは、256種類のバイナリ表現の違いを認識できません。どうして、こんなことになっているのでしょうか。

 

同じような疑問を感じた人は他にもいるようで「Using the TRAP instruction」という記事がありました。ロジックを工夫すれば、256種類あるバイナリ表現の中で何が使われたのかを実行時に識別することは出来るようです。

 

PDP-11の命令体系において何か意図してTRAP命令用のバイナリ表現として256種類を用意したのであれば、その区別がレジスタ参照で取り出せるようになっているべきではないかと思います。そうなっていないということは、命令体系上の方針としては、256種類を使い分ける必要はないと思っていたということでしょうか。

 

PDP-11の命令体系はよくできているという評価を得ているようです。私自身としては、まだPDP-11を学び始めたばかりなので、それほど深く理解している訳ではありませんが、多彩なアドレッシングモードが多くの命令で同じように使えるようなので、よく出来ているCPUだと思わなくもありません。そうであったとしても、TRAP命令とEMT命令については、謎めいているという印象です。

MS42-BA

ずいぶん前にジャンク扱いでVAXstation 3100を何台か手に入れました。中を確認すると「MS42-BA」というメモリが使われているのを確認しましたが、詳細は不明でした。ネットを検索すれば、それがDEC製のメモリであることはわかるのですが、公式情報ではないので、要するに何なのか分からずにいました。

つい最近bitsavers.orgで「Digital Systems and Options Catalog July 1992」を入手しました。すると「MicroVAX 3100 Model 10e VAXstation 3100 Model 30, 38, 40, and 48 Memory」として「MS42-AB」、「MS42-BA」、「MS42-CA」、「MS42-KA」が掲載されているのに気付きました。その記述によると、「MS42-BA」というのは、「12-Mbyte parity (1-Mbit chip) memory module. Factory or field installed. Not configurable with MS42-AB or MS42-BA.」という事のようです。

これでひとつ理解が進んだことになります。これ以外にも、何者なのか分からない型番のパーツがありますので、いずれ何かの情報を得られることを願っています。

MOPDの実装：select()かpoll()か

DEC製ワークステーションをネットワークから起動するために必要となるMOPDの実装を調べています。調査をすすめているうちに、横道にそれるという言うか、派生する技術についても把握しておく必要に迫られます。しかも空き時間を見つけながら調査しているので、なかなか先に進みません。

ともかく、MOPDをデーモンとして動作させるための中心部分とおもわれる「Loop()」（mopd-2.5.3/common/loo-bsd.c）を調べてみました。そこではシステムコール「select()」 が使われているのですが、NetBSD版ではシステムコール「poll()」に置き換わっています。他の実装、OpenBSD版、Linux版、FreeBSD版では、select()のままです。

システムコール「select()」と「poll()」は歴史的に見れば成り立ちが異なるようですが、それは2000年以前のUNIX乱立時代の頃の話であって、21世紀に入って20年以上も過ぎた今日では、両システムコールが実装されていないOSの存在を気にする必要はない気がします。

そうであるならば、システムコール「select()」と「poll()」の何れを用いるのが望ましいのでしょうか。select()の方が制限が厳しいようで、よりましなpoll()を使っておく方が良いとも考えられます。しかしMOPDにおいて、その制限が問題になるようなネットワーク的な同時接続数があるのかと言うと、そんな事はないと思います。程度問題なのかもしれませんが、机上の空論のような究極の状況を考慮してロジックを組むのも、やりすぎではないかとも思います。

 

NetBSD版MOPDのようにシステムコール「poll()」に置き換えるのが悪いとは思いませんが、圧倒的なメリットがある訳でもなさそうです。ならば他の実装のようにシステムコール「select()」のままにしておくのも、ひとつの判断でしょう。どちらのシステムコールを採用するのか、判断の決め手のようなものが何かあれば良いのですが。

mopdの実装を調査するためにmopd/mopd.cを読んでみました。オリジナルのmopd-2.5.3が各OSの実装で変更されており、似たような変更を加えていますが、統一化が図られている訳ではないようです。 

• mopd.cを見ると、MOPD(8)では説明されていないオプションが実装されています。ただしOpenBSD版のMOPD(8)では、そのオプションの説明が加えられています。またNetBSD版では、-sという新しいオプションが追加されています。
• オリジナル版では、大域変数Programを用いて、argv[0]からプログラム名を得ています。ところが他の実装では、関数getprogname()や変数__prognameを利用するように変更が加えられています。
• デーモンとして動作させるため、オリジナル版ではfork()を呼び出したりしていますが、他の実装ではdaemon()を利用するように変更が加えられています。

 

オリジナル版も他の実装にも、以下のような処理があります。このロジックならば、ForegroundFlagが指定されておらず、DebugFlagが指定されている場合に、このメッセージが出力されるという事です。しかしメッセージの「not running as daemon」と、ForegroudFlagが指定されていないという状態とが、整合していない気がします。

if ((!ForegroundFlag) && DebugFlag) {
    fprintf(stdout, "%s: not running as daemon, -d given.\n", Program);
}

MOPD(8)では、SEE ALSOにbpf(4)が記載されています。BPFというのはBerkeley Packet Filterの事だという事しか知らないので、勉強しておこうと思います。

mopd/process.hのバリエーション

mopdの実装を学ぶため、mopdに置いてあるファイルを一つずつ見ていくことにしました。おそらく、ソースを読むために必要となる派生的な技術に手を出す必要が出てくると思いますが、それもこれも勉強だと思います。短期間に全力疾走して解析を終えることにはならないでしょうから、長期に亘ることを意識して、TW5で情報を整理しながら進めていこうと思います。

まず最初にmopd/process.hから見ていきます。このファイルは、コメントを除けば、10数行しかありません。

#ifndef _PROCESS_H_
#define _PROCESS_H_

#ifdef NO__P
void    mopProcessDL (/* FILE *, struct if_info *, u_char *, int *,
                         u_char *, u_char *, int, u_short */);
void    mopProcessRC (/* FILE *, struct if_info *, u_char *, int *,
                         u_char *, u_char *, int, u_short */);
#else
__BEGIN_DECLS
void    mopProcessDL __P((FILE *, struct if_info *, u_char *, int *,
                          u_char *, u_char *, int, u_short));
void    mopProcessRC __P((FILE *, struct if_info *, u_char *, int *,
                          u_char *, u_char *, int, u_short));
__END_DECLS
#endif

#endif _PROCESS_H_

ここで「__BEGIN_DECLS」と「__END_DECLS」のペア、「__P()」というマクロらしきもの、「NO__P」という定義が利用されています。これらが何かを調べるところから始めていきたいと思います。

まず「__BEGIN_DECLS」と「__END_DECLS」は、Web上にある記事「C言語系 / NetBSD1.6における setjmp(), longjmp() の実装(2) (v1)」で説明されていました。同様の説明は他にも見つかったので、それ自体は難しいことは何もありません。ただし調べても不明だったのは、なぜ「extern "C"」を直に記述しないで、これらを使うのかという事です。しかも「8.1 Writing C header files」では、「BEGIN_C_DECLS」と「END_C_DECLS」を使うことにしています。何か歴史的な事情があったのではないかと思うのですが、その経緯がわかりませんでした。

次に「__P()」というマクロは、初期のC言語とANSI Cとのプロトタイプ宣言の違いを吸収するために使うようです。mopd-2.5.3が何時から開発されていたのか、ChangeLogなどがないので、不明ですが、その当時はK&R CとANSI Cの違いを気にする必要があったのでしょう。しかし2023年の今となっては、あまり気にしなくても良さそうです。

 

最後に「NO__P」という定義は、otherOS/Makefileの中で定義されているのを見つけました。rs6000-aix3、sun3-sunos4、sun4-sunos5などの環境下では定義されるようです。多分それらでは「__P()」が存在しないのでしょう。

このファイルがどのように変更されているかを確認してみました。

• NetBSDでは、「NO__P」の定義を確認している箇所が無くなっていますし、「__P()」も使っていません。
• OpenBSDでは、NetBSDと同様の対応に加えて、「__BEGIN_DECLS」と「__END_DECLS」も消えています。
• FreeBSDでは、portsのパッチが増え過ぎないようにしたかったのか、何の変更も加えられていません。
• Linux版は、NetBSDの変更を取り込んでいるようですが、「NO__P」の定義を確認している箇所が無くなっているものの、「__P()」は残っています。

mopd-2.5.3の派生

VAXstationなどDEC製品はネットワーク上に存在するマシンから情報を貰ってブートさせることが出来て、これをMOP（Maintenance Operation Protocol）と呼びます。OpenVMSなどDEC製OSであれば当然MOPサーバになれるのですが、NetBSDやLinuxであってもmopdを動かしておけば、MOPサーバとして機能させることが可能です。

 

調べてみると、以下のOSでmopdが動くようです。

• NetBSD
• OpenBSD
• FreeBSD
• Linux

 

これらは全て「mopd-2.5.3.tar.gz」という実装から派生していますが、現時点での実装は各々異なっているようです。

1. NetBSDとOpenBSDは、OSのusr.sbinとして取り込まれており、OSのポリシーに合わせた変更が行われているように見えます。
2. FreeBSDは、portsとして提供されているので、必要最小限の変更だけで済まされている印象です。
3. Linuxは、READMEにも書かれていますが、NetBSD版を取り込み、OpenBSD版などの変更を参考にしているようです。
4. 各OS版とも、オリジナルの「mopd-2.5.3」と構成がほぼ同じになっています。しかしNetBSD版は、mopa.outというコマンドが消えており、mopcopyというコマンドが追加されています。

手持ちのDEC製ワークステーションを生かすために、mopdを準備しようと思っています。どれを使っても構わないとは思いますが、MOPの理解を深めるために、それぞれの変更箇所を詳しく調べてみようと思います。

Assabet Woolen Mill

フェイスブックにある「DEC Computer Users」を見ていたら、Ryan Foley氏の投稿「I went to the Mill yesterday.」を見つけました。ボストン郊外にあるAssabet Woolen Millは、DECの本社があったところです。フェイスブックに投稿された写真を見ると、跡地にはDEC時代を振り返る掲示板が出来ているようです。

Assabet Woolen Millはボストン郊外のメイナードにあります。Boston中心部から50km弱ほどの距離です。アメリカは車社会なので、車を使えば小一時間で行けるでしょう。しかし日本から旅行で行くとして、レンタカーを借りずに公共交通機関を利用する方法を調べてみました。

ボストン周辺の公共交通機関はMBTAが担っており、FITCHBURG線のSOUTH ACTON駅が最寄り駅かと思います。最寄り駅とは言っても「比較的」一番近いというだけなので、この駅からAssabet Woolen Millまでは4kmほどあります。アメリカの公共交通事情は分かりませんが、日本のようにバスが運行されている訳ではないんじゃないかと思います。歩けない距離ではないと思いますが、こういう場合にどうするのが無難なのでしょうか。歩くことは厭わないのですが、フラフラ歩くのは避けたほうが良いのか、注意しさえすれば日本同様に歩いても問題ないのか、現地の感覚が知りたいところです。

COVID-19の影響が何時まで続くのか見えませんが、永遠に続くわけでもないでしょう。いつになるか分かりませんが、Assabet Woolen Millを訪問し、DEC時代を振り返る掲示板をこの目で見たいと思います。

RLoginでOpenVMSに接続した際の端末タイプの設定方法

先日インストールしたOpenVMS Alpha 8.4-2L1にRLoginで接続すると、端末タイプが「VT500相当」になります。VT500相当ではいけないという事ではありませんが、VT100などにはならないのか、そもそも任意に変更できるのか、不明でした。

$ show term

Terminal: _OPA0:      Device_Type: VT500_Series  Owner: SYSTEM

RLoginのWebサイトにある「エスケープシーケンス一覧」によると、「DA1」の応答はTermID設定によって変化すると書かれています。その「TermID設定」とは「3.6.1 ESC/CSI/DCSの設定」によれば次のように書かれています。

各種IDでは、DA1,DA2,DA3で応答する番号の初期値を設定できます。

試してみたところ、次のように変化しました。

1. TermIDを「10」とした場合「VT500_Series」になる。
2. TermIDを「9」とした場合「VT400_Series」になる。
3. TermIDを「7」か「8」とした場合「VT300_Series」になる。
4. TermIDを「5」か「6」とした場合「VT200_Series」になる。
5. TermIDを「2」か「3」か「4」とした場合「VT102」になる。
6. TermIDを「0」か「1」とした場合「VT100」になる。

OpenVMSに接続する場合、どのVT互換として利用すれば良いのかは、迷うところです。VT220などのキーボードは、IBM-PCのキーボードとは（似ていますが）重要なキー（DOキーなど）に差異があります。このハンドリングをRLoginで対応できるのかを、見極めなければならないと思います。

OpenVMS Alpha 8.4-2L1に対してSSHでログインする方法は何か？

Digital PersonalWorkstation 500auにVSI版OpenVMS Alpha 8.4-2L1をインストールしました。この時点で次のようなプロダクトがインストールされています。

------------------------------------ ----------- ---------

PRODUCT                              KIT TYPE    STATE

------------------------------------ ----------- ---------

VSI AXPVMS AVAIL_MAN_BASE V8.4-2L1   Full LP     Installed

VSI AXPVMS CDSA V2.4-320A            Full LP     Installed

VSI AXPVMS DECNET_OSI V8.4-D         Full LP     Installed

VSI AXPVMS DWMOTIF V1.7-F            Full LP     Installed

VSI AXPVMS DWMOTIF_SUPPORT V8.4-2L1  Full LP     Installed

VSI AXPVMS HPBINARYCHECKER V1.1-A    Full LP     Installed

VSI AXPVMS KERBEROS V3.1-152A        Full LP     Installed

VSI AXPVMS OPENVMS V8.4-2L1          Platform    Installed

VSI AXPVMS SSL V1.4-502A             Full LP     Installed

VSI AXPVMS SSL1 V1.0-2JA             Full LP     Installed

VSI AXPVMS TCPIP V5.7-13ECO5F        Full LP     Installed

VSI AXPVMS TDC_RT V2.3-1220          Full LP     Installed

VSI AXPVMS VMS V8.4-2L1              Oper System Installed

------------------------------------ ----------- ---------

13 items found

PAKは既に入れてありますが、それ以外の設定は何もしていません。ひとまず次のような設定を済ませておきました。

1. アカウント作成
2. DECnet-Plusの設定
3. バッチキューの設定
4. TCP/IP Services for OpenVMSの設定

DECnet IVとしての設定を済ませましたので（DECnetとして）リモートログインは出来るのですが、DECnetで繋がるのは自分自身だけです。TCP/IPならMicrosoft Windows10やFreeBSD/amd64などから接続できるはずなので、その設定を済ませたいと思います。TELNETなら以前に設定したことがあるので、今回はSSHで接続する環境を設定してみようと思います。しかしながら、TCP/IP Services for OpenVMSの場合、どうすれば良いのでしょう？

FreeBSDやNetBSD、またはLinuxであれば、接続したいアカウントの「~/.ssh」において、公開鍵を「authorized_keys」に追加すれば良い訳ですが、OpenVMSの場合は、どうなるのでしょう？

『TCP/IP Services for OpenVMS Guide to SSH』というマニュアルを見つけたので、目を通してみました。些細なことかもしれませんが、やはり違いがあるようです。

1. SYS$LOGINの下にある「[.SSH2]」が使われるようです。
2. RSAかDSAしか選べないようです。普段はED25519を使っているので、同じ鍵は使えないですね。

試しにSSHで接続してみましたが、うまく行きませんでした。問題の所在をつきとめて、接続できるようにしたいと思います。

VSI版OpenVMS Alpha 8.4-2L1のインストールに失敗

Digital PersonalWorkstation 500auのシリアルコンソールが使えるようになりました。またVSIから入手したOpenVMS AlphaのZIPEXEファイルを展開してISOファイルを取り出し、CDに焼いてあります。これで準備が整ったので、DEC版OpenVMS Alpha 7.2がインストールされていたマシンを、VSI版OpenVMS Alpha 8.4-2L1にアップグレードしてみました。

しかし残念ながら、アップグレードに失敗しました。まず最初は、システムディスクのファイルを残してアップグレードを試みましたが、エラーが出てしまいました。

The following product has been selected:

    VSI AXPVMS OPENVMS V8.4-2L1            Platform (product suite)

 

Configuration phase starting ...

 

You will be asked to choose options, if any, for each selected product and for

any products that may be installed to satisfy software dependency requirements.

 

%PCSI-E-UPGRADERR, existing version of product that VSI AXPVMS OPENVMS V8.4-2L1 

upgrades is incorrect

Terminating is strongly recommended.  Do you want to terminate? [YES] 

%PCSI-E-S_OPCAN, operation cancelled by request

%PCSIUI-E-ABORT, operation terminated due to an unrecoverable error condition

    Installation has been aborted.

システムディスクに残っているファイルが悪影響を及ぼしているかもしれないと思ったので、次にシステムディスクを初期化するようにしてインストールを試みましたが、やはり失敗しました。

Execution phase starting ...

The following products will be installed to destinations:

    VSI AXPVMS AVAIL_MAN_BASE V8.4-2L1     DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS CDSA V2.4-320A              DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS DECNET_OSI V8.4-D           DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS DWMOTIF V1.7-F              DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS DWMOTIF_SUPPORT V8.4-2L1    DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS HPBINARYCHECKER V1.1-A      DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS KERBEROS V3.1-152A          DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS OPENVMS V8.4-2L1            DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS SSL V1.4-502A               DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS SSL1 V1.0-2JA               DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS TCPIP V5.7-13ECO5F          DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS TDC_RT V2.3-1220            DISK$ALPHASYS:[VMS$COMMON.]

    VSI AXPVMS VMS V8.4-2L1                DISK$ALPHASYS:[VMS$COMMON.]

 

Portion done: 0%...10%

 

%PCSI-E-OPENOUT, error opening DISK$ALPHASYS:[VMS$COMMON.][SYSHLP]HELPLIB.HLB; a

s output

-RMS-E-FNF, file not found

%PCSI-E-OPFAILED, operation failed

Terminating is strongly recommended.  Do you want to terminate? [YES] 

%PCSI-E-CANCEL_WIP, termination resulted in an incomplete modification to the sy

stem

%PCSI-E-S_OPCAN, operation cancelled by request

%PCSIUI-E-ABORT, operation terminated due to an unrecoverable error condition

    Installation has been aborted.

このエラーについては、同様の現象がVSI OpenVMS Forumやcomp.os.vmsでも報告されています。

1. Error installing 8.4L1 on FreeAXP 4.0
   
2. Problem connecting OpenVMS to linux via ssh
   

このマシンはインストール出来ることを、VSIが正式に保証しているわけではないので、うまくいかないことがあってもやむを得ないと思いますが、なんとかインストールを成功させたいと思います。

Digital PersonalWorkstation 500auのシリアルコンソールが復活した

Digital PersonalWorkstation 500auの基盤に取り付けられているCR2032を交換しましたが、何故かシリアルコンソールが出なくなってしまいました。何か表示が出るとか、ビープが鳴るなどの、何らかのアクションを起こしてくれれば、それを手掛かりに原因究明をおこなうのですが、何も出ません。このマシンにはグラフィックスボードもついており、もしかするとグラフィックス画面に何か表示が現れているのではないかとも考えられますが、（Web上でみかけた情報によると） ディスプレイやキーボードが接続されていなければ自動的にシリアルコンソールが有効になるそうです。

数年前にもシリアルコンソール出力に異常があり、その時に試行錯誤した記録を確認してみました。その時には、メモリスロットにあるメモリを、手持ちのメモリと入れ換えて様子をみたようです。そのうちになんとなく直ってしまったので、最終的に何が問題だったのかは不明なままです。今回も原因が不明（少なくともCR2032の交換が原因ではないと思う）ですが、前回同様メモリあたりから確認してみようと思います。

現状を確認すると、このマシンはメモリスロットが6本あり、2枚ずつ3組挿せるようになっています。基盤にはDIMM5、DIMM3、DIMM1と印刷されているのが見えます。メモリは次のようになっていました。

1. DIMM5：54-25092-DA x2
2. DIMM3：54-25092-DA x2
3. DIMM1：IO-DATA PC133 E133-256M

ひとまずメモリを全て取り外して電源を入れてみます。するとビープ音が鳴り異常を通知します。シリアルコンソールには何も表示がありません。

次にDIMM5に54-25092-DA x2だけを取り付けて電源を入れてみました。すると（もちろんビープは鳴りません）シリアルコンソールに表示が現れました。CR2032を交換したことで初期状態に戻ってしまったようでAlphaBIOSが起動しましたが、これはSRMに変更すれば良いだけの事です。ともかくシリアルコンソールが復活したのは大きな前進です。

今度はDIMM5にIO-DATA PC133 E133-256 x2だけを取り付けて電源を入れてみました。するとビープ音がなり、シリアルコンソールには何も表示がありません。これが問題の原因なのかもしれません。基盤を見ると、メモリスロットの側にLEDが8個あり、マシンの状態を示しているようです。上下に4個づつ配置されており、上段は「ON-ON-ON-OFF」、下段は「OFF-OFF-ON-ON」でした。

どうやらメモリに問題がありそうなので、DIMM5に54-25092-DA x2を、DIMM3に54-25092-DA x2を取り付け、DIMM1は空きのままとしました。この状態で電源を入れると、ビープも鳴らず、シリアルコンソールにも出力が現れました。CR2032を交換しているので、AlphaBIOSには戻らずSRMのままです。ちなみに、この状態でLEDを確認したら、上段は「ON-ON-ON-OFF」で、下段が「OFF-ON-OFF-OFF」でした。

これまではIO-DATAのメモリを挿したままでも問題が無かったのですが、偶々運が良かっただけだったのかもしれません。現状でもメモリは512Mあるので、問題はないでしょう。

>>>show config

Firmware

SRM Console:    V6.9-7

ARC Console:    5.67

PALcode:        VMS PALcode V1.20-14, OSF PALcode V1.22-17

SROM Version:   v5.90

Processor

DECchip (tm) 21164A-2   Pass   500 MHz  96 KBytes SCache 

2 MB BCache

PYXIS ASIC Pass 257

MEMORY

Memory Size = 512Mb

Bank      Size/Sets   Base Addr

------    ----------  ---------

   1        256Mb      00000000

   2        256Mb      10000000

BCache Size = 2Mb

Tested Memory =  512Mbytes

ともかくシリアルコンソールが復活したことで、VSI版OpenVMS Alpha 8.4-2L1を試してみることが出来るようなりました。

PWS500auのCR2032を交換したらシリアルコンソールの出力が出なくなった

 Digital PersonalWorkstation 500auは、シリアルコンソールで利用しています。OpenVMSを利用するにはSRMにしておく必要がありますが、電源を入れるとAlphaBIOSが起動してしまいます。内部バッテリCR2032が切れてしまったのかもしれません。交換作業は難しくありません。過去（2009年頃および2014年頃）にも交換作業をしました。

新しいCR2032と交換して、電源を入れたところ、なぜかシリアルコンソールに出力が出なくなりました。このような問題が生じるとは考えていませんでした。おそらくAlphaBIOSが起動するだろうから、SRMに変更しようと思っていたのです。CR2032を交換したので、今後は電源を入れても、AlphaBIOSに戻ることは無く、SRMで起動するハズだと考えていました。事実、過去に交換した時には、そうだったのです。

シリアルコンソールに何も表示がでないと、手も足も出ません。何か故障でもしているなら、電源投入時の自己診断で、何かビープ音でも出そうなものですが、異常を知らせるような音は発していません。

このマシンは過去にもシリアルコンソールが突然出なくなる現象を起こしたことがあります。調べても問題の原因が不明で、いつの間にか現象が現れなくなっていたのですが、再発したようです。何が問題なのか不明なので、対処のしようもありません。かと言って、このままでは鉄屑になってしまうので、冷静に状況を確認しながら、解決を図ろうと思います。

VSI版OpenVMS AlphaのCDが焼けたことだし、早速インストールしてみようと思っていましたが、ひとまずお預けです。ZIPEXEの問題は解決しましたが、シリアルコンソールの問題が再発して、一難去ってまた一難という感じです。

Digital Persolal Workstation 500auのAlphaBIOSをSRMに変更

 先日VSIの「Community License Program」を申請してAlpha用のライセンスを入手しました。これを適用しようと思っているのは、自宅にあるDigital Personal Workstation 500auです。このマシンには従来「Hobbyist OpenVMS Program」として入手したライセンスを用いてOpenVMS Alpha V7.2を入れていましたが、VSI版OpenVMSに移行する必要があります。

準備作業のために久しぶりに電源を入れたら、ボタン電池が切れていたようで、AlphaBIOSが立ち上がってしまいました。このマシンはWindowsNTでも利用できるようになっておりAlphaBIOSが初期状態となるようですが、OpenVMSを利用する場合にはSRMに切り替える必要があります。もちろんSRMに切り替えておいたはずですが、バッテリ切れのために初期状態に戻ってしまったようです。

このマシンをWindowsNTで利用するならディスプレイやキーボードを取り付けておくところですが、OpenVMSとして使うならシリアルコンソールで十分です。ところがAlphaBIOSをSRMに変更しようとすると、ちょっと厄介なことになります。

数年前にも同じ作業をしたのでメモが残っていました。参考となる情報は「The OpenVMS Frequently Asked Questions (FAQ)」にある「14.3.7.3 How do I switch between AlphaBIOS/ARC and SRM consoles?」です。作業自体は、一度経験してみれば分かると思いますが、難しくありません。ただし注意すべきポイントが幾つかあります。

1. シリアルコンソールであっても作業は可能ですが、画面表示でVT100エスケープシーケンスが多用されているので、それを解釈できる端末で作業する必要があります。僕はRloginを利用しました。
2. 設定メニューを出すには「F2」などのファンクションキーを押す必要があるのですが、キーボードの「F2」を押しても遷移できません。前述したFAQにあるように、ファンクションキーの代替キーを入力する必要があります。例えば「F2」ならば「Ctrl-B」です。

これでAlphaBIOSからSRMに切り替わったのですが、電源を落とすと初期状態（ALphaBIOS）に戻ってしまうようです。ボタン電池の交換が必要なのでしょう。近いうちに交換しておこうと思います。

OpenVMS AlphaのVSI版ライセンス

VSIが発表した「VMS Software Community License Available」を入手してみたら、過去に「Hobbyist OpenVMS License」として入手してきたものと全然違いました。何か理由があるのだろうとは想像していましたが、念のためにメールで問い合わせてみました。

2020年8月18日15時前（日本時間）にメールを送信しましたが、正直言って、いつになったら返事が来るか不安でしたし、もしかすると返事が来ないかもしれないと思っていました。

ところがなんと、数時間後（日本時間の同日17時過ぎ）にはVSIの担当者から返事が届きました。VSIの公式サイトによればオフィスは米国マサチューセッツ州とスウェーデンにあるようです。いずれにしても日本時間とは昼夜逆転していると思いますが、それにもかかわらず素早く返信している事は好感がもてます。

ライセンスの構成が変わっているのは、VSI担当者からの返事によれば、HPEからOpenVMSの権利を引き継いだ時にライセンス体系の単純化が決められたからとの事です。僕も薄々そういう理由なのではないかと想像していました。

ライセンス体系が変化しているという事は、もはやHPEが提供していたような（もっと以前にはDECやCOMPAQが提供していたような）OpenVMS Alphaのライセンスは入手する術がないという事です。Hobbyist OpenVMSによるAlphaやVAXの旧バージョンのメディアを所有していますし、それをインストール出来るマシンも（AlphaもVAXも）持っていますが、ライセンスが無いので利用できないという事になります。

VSIがリリースしたOpenVMS Alphaに更新すれば、VSIのCommunity Licenseが利用できるのでしょう。VSI版OpenVMS Alphaが僕の所有している「Digital Personal WorkStation 500au」にインストールできるのか試してみようと思います。

VSI版OpenVMS Alpha用のライセンスなのか？

VSIから送られてきた「OpenVMS Community License」には「ALPHA-SYSTEM」と「ALPHA-LP」という2つのPAKしか入っていませんでした。当初これは何だろうと思いましたが、Webを検索してみると2017年頃にVSIが発表した情報を見つけました。そこには次のような記述があります。

• All OpenVMS & LP licenses included in Tiers
• License PAKs
• Alpha-System
• Alpha-LP

OpenVMSが必要とするライセンスの仕組みは、DECが開発したものだと思いますが、それをCOMPAQもHPも踏襲してきていました。内部構造がどうなっているのかは知りませんが、プロダクトなどのライセンス管理単位で決められている名称が内部に組み込まれているのだと思います。その名称ごとに有効無効の管理や、有効期限の管理が行われていたのではないかと思います。

これまでHPEから入手してきた「OpenVMS Hobbyist License」では、システム関係とレイヤードプロダクト関係を合わせて112個のPAKが含まれていました。それが、たった2個のPAKにまとめられてしまっているので、おそらくVSI側の意向としては、ライセンス管理単位が細かすぎて不必要に手間がかかっていると感じていたのではないでしょうか。それをまとめてしまう気持ちは分からなくもありませんが、DECやCOMPAQがリリースしていたOpenVMS Alphaとの互換性が失われてしまっているのは否めないのではないでしょうか。

DEC/COMPAQ/HP時代のOpenVMSの内部にはライセンス管理名称として「ALPHA-SYSTEM」や「ALPHA-LP」は入っていないだろうと思います。昔は「OPENVMS-ALPHA-USER」とか「DW-MOTIF-UI-JAPANESE」などのように、細かく細かくライセンス名称が分かれていたので、このようなライセンス名称しか認識しないのではないかと思います。そうなると、VSIから入手した「OpenVMS Community License」を入れても認識されず、有効期限を過ぎたら「ライセンスが無効です」というようなエラーが出てしまう気がします。

VSIがリリースしたOpenVMS Alphaを使えば問題ないのだろうと思いますが、それは避けたいと考えています。なんとかならないだろうかと、とりあえずVSIに問い合わせのメールを送ってみました。返事がくるかどうかわかりませんし、たとえ返事が来たとしても、昔流儀のPAKを発行してくれることになるかもわかりません。

どういう結末を迎えるのか不明ですが、できることを探っていこうと思います。

VSIからPAKが届いた、しかし・・・

VSIから2020年7月28日付で「VMS Software Community License Available」が発表されたので、2020年7月31日に「Community License Program」でPAKを申し込みました。ところが2週間ほど経っても音沙汰がなかったので、催促しようかと思っていました。

comp.os.vmsの「VSI Community License Program Update」を見ると、PAKが届いている人が現れ始めているようなので、僕のところにもそろそろ届くかもしれないと待っていたら、メール（送信日時：Sat, 15 Aug 2020 11:15:01 +0000）が届きました。

Hello Kazumi,

Thank you for your OpenVMS Community License application.

*snip*

Please click the following link to download the license PAK: 

ようやく連絡がきて安心しました。しかしダウンロードしたPAKがなんだか変です。

ダウンロードしたファイルはZIPで圧縮されています。その中にはコマンドプロシージャが入っているのは、OpenVMSなら、そういうものだろうと納得できます。しかしライセンスが「ALPHA-SYSTEM」と「ALPHA-LP」の2つだけしかありませんが、これで良いのでしょうか?これまでHPEから「OPENVMS HOBBYIST LICENSE REGISTRATION」として届いていたPAKには、以下に示すように、112種類のライセンスがありました。

$! PAKs(112) listed below include:

$!   ACMS, ACMS-REM, ACMS-RT, ACMSXP-DEV, ACMSXP-RT, ADA, ADA-PDO, ADAO-PDO, 

（以下略）

OpenVMSのライセンス管理の仕組みが不明ですが、VSIが送ってきた2つのライセンスで、HPEが発行した112のライセンスを代替できるものなのでしょうか。

もうひとつ不審なのが、有効期限が「/TERMINATION_DATE=14-JUL-2021」となっている点です。「/AUTHORIZATION=1-VSI-20200716-00021」のような情報もありますし、僕が申請した日付である2020年7月31日よりも前に準備していたファイルを間違って送ってきたのだろうかという疑いを持ちます。

問い合わせてみるのがよいかもしれません。

the “OpenVMS Community License Program” by VMS Software, Inc.

元々はDEC（Digital Equipment Corporation）が開発したOpenVMSには「OpenVMS Hobbyist license program」という個人ユーザ向けライセンスがありますが、現在はHPE（Hewlett Packard Enterprise）によって提供されています。ところが先日、ライセンス提供を終えることが予定されているというメールが届きました。このメールは世界中のユーザにも一斉に送られたようで、ユーザが集まるコミュニティにおいて、今後どうなるのかという心配する声が溢れていました。

OpenVMSは、DECを買収したCOMPAQが、さらにHPと合併したことにより、HPEが権利を保有していました。しかしHPEにとって今後も開発をしていく気はないらしく、数年前にVSI（VMS Software, Inc.）に権利を渡してしまいました。そのVSIが2020年4月22日に「OpenVMS Community License Program」を提供するつもりがあることを発表しました。

It will be called the “OpenVMS Community License Program”, and we are currently in the process of working out all the details, which will be available well before the end of the HPE Hobbyist license program.

このようなアナウンスが出たことはcomp.os.vmsの「OpenVMS Community License Program」で知りました。

詳細は検討中とのことなので、正式に発表されてみないと安心はできませんが、ちょっとホッとしました。提供アーキテクチャにはVAXが含まれているのか（僕はVAXstation3100を何台か所有しているので、気になります）とか、 ライセンス料金はどうなるのだろう（現在HPEから提供されているOpenVMS Hobbyist license programは無料です）とか、いろいろと気になるところがあります。今後の動向を注視していこうと思います。

今年もHobbyist OpenVMSのPAKを入手した

自宅にあるPERSONAL WORKSTATION 500au（DECchip 21164A-2 500MHz）には、OpenVMS Hobbyist Programを利用してOpenVMS/alphaをインストールしています。個人利用ではありますが本物のOpenVMSなので、使用するにはライセンスを必要とします。

OpenVMS Hobbyistのためのライセンス（Product Authorization Key）を入手するにはWebサイトからリクエストします。その後HPEからメールでPAKが送られてきます。このPAKには有効期間が設定されており、1年間相当なので、毎年更新手続きをおこなう必要があります。

そういう訳で、今年もPAKの申請を行いました。申請は「OpenVMS Hobbyist Registration」からおこないます。申請には「Participating Chapter」というものが必要になり、僕の場合は昔々に得た資格「DECUS Japan」を使っています（Membership Numberも必要になります ）。


Webからリクエストを投げると自動返信メールが届きます。このメールはグリニッジ標準時（GMT）で10時となっていますが、日本時間なら19時（午後7時）です。

Date:    27 Nov 2019 10:00:13 GMT
From:    no-reply@hp.com
Subject: Thank you for contacting HP

Your message is important to us. It has been forwarded to the HP OpenVMS Systems
 response team. An auto-acknowledgement will be sent to you to confirm your e-ma
il address and to confirm that we have received your inquiry. If you do not rece
ive an auto-acknowledgement after 1 hour, please re-submit your inquiry and veri
fy that you've entered the correct e-mail address.

If you have submitted an inquiry that is not related to HP OpenVMS Systems, we w
ill forward your message to the appropriate organization within HP.

If you have additional feedback or inquiries, please visit our <a href"http://we
lcome.hp.com/country/us/en/wwcontact.html">Contact HP</a> page.

Thank you,
OpenVMS webmaster

驚いたことに、30分後にはPAKが届きました。近年は処理が早いのですが、以前には数日待ってもPAKが届かないので、待った方が良いのか、催促した方が良いのか、気を揉んだこともあります。

Date:    Wed, 27 Nov 2019 10:28:10 GMT
From:    OpenVMS Customer Lab <openvmscustomerlab@hpe.com>
Subject: RE: OpenVMS Hobbyist Registration

Hello Furusawa-san,

Please see attached for PAKs to use on your VAX or Alpha.
The attached file is a DCL command file; to load your PAKs simply execute it

（以下略）

これでPAKが手に入ったので、早々にDCL（日本語では「コマプロ」）を流そうと思います。

Hobbyist OpenVMS AlphaのPAKを更新しました

Personal Workstation 500auに入れてあるOpenVMS Alpha 7.2のHobbyistライセンスの有効期限が明日に迫っているので更新しました。

ライセンスはHewlett Packardの「OpenVMS Hobbyist Registration」から申請します。去年とはURLが微妙に異なっていました。ここから申請を送ると直後に自動返信メールが届きます。1営業日でPAKが届くはずなのですが、数日待っても送られてきませんでした。

待っていれば届くのか、催促した方が良いのか迷うところです。もっとも催促すると言っても何処にコンタクトすれば良いのでしょうか。そこで参考情報が集まっていると思われる「OpenVMS Hobbyist Program」にあるフォーラム「Hobbyist Licensing」にある「Alpha License PAK's」の中の「Getting Hobbyist licenses and Media」の情報を参考にしました。ここにある「How do I get Hobbyist License Keys?」 という質問の回答に「the backup link for getting license keys」というURLがあります。ここから再度申請してみたら、翌日PAKがメールで送られてきました。

結局どちらの申請が有効だったのかわかりませんが、送られてきたメールの申請内容の記録を見ると、どうも最初の申請に対する応答のような気がします。

ともかくPAKが手に入ったので、これをOpenVMS Alphaに転送して登録しておきます。去年はまだTCP/IPが使えなかったので相当苦労しました。しかし今はftpで一発です。

$ tcpip show version

  DIGITAL TCP/IP Services for OpenVMS Alpha Version V5.0
  on a Digital Personal WorkStation  running OpenVMS V7.2   

送られてきたPAKをSYS$SCRATCHにコピーしました。このファイルはコマンド・プロシージャ形式なので、拡張子まで指定すれば、先頭に@をつけて直接実行できます。

$ dir sys$scratch:hobbyist-use-only-va.txt

Directory SYS$SYSROOT:[SYSMGR]

HOBBYIST-USE-ONLY-VA.TXT;1            

Total of 1 file.
$ @sys$scratch:hobbyist-use-only-va.txt
%SHOW-I-NOLICMATCH, no licenses match search criteria
%LICENSE-I-DISABLED, ACMS HOBBYIST-VA-KEY12497-151009 has been disabled
%LICENSE-I-DISABLED, ACMS HOBBYIST-VA-KEY12497-161007 has been disabled
%LICENSE-I-UNLOADED, ACMS   has been unloaded
%LICENSE-I-ENABLED, ACMS HOBBYIST-VA-KEY12497-161007 has been enabled
%LICENSE-I-LOADED, DEC ACMS was successfully loaded with 0 units
%SHOW-I-NOLICMATCH, no licenses match search criteria
（略）
%SHOW-I-NOLICMATCH, no licenses match search criteria
%LICENSE-I-DISABLED, X500-DIRECTORY-SERVER HOBBYIST-VA-KEY12497-151009 has been disabled
%LICENSE-I-DISABLED, X500-DIRECTORY-SERVER HOBBYIST-VA-KEY12497-161007 has been disabled
%LICENSE-I-UNLOADED, X500-DIRECTORY-SERVER   has been unloaded
%LICENSE-I-ENABLED, X500-DIRECTORY-SERVER HOBBYIST-VA-KEY12497-161007 has been enabled
%LICENSE-I-LOADED, DEC X500-DIRECTORY-SERVER was successfully loaded with 0 units
Completion of PAK Load Command File....
$

これでライセンスの更新は終わりました。

configureが生成するCプログラムの抽出

gzip-1.4をOpenVMS alphaでコンパイルしてみるためにはlib/config.hが必要です。このファイルはconfigureによって作成されますが、OpenVMSではconfigureが動かないので手作業で作らなければなりません。configureは自動化されているとはいえ、内部ではCプログラムを生成し、コンパイルをおこない、実行させた結果をみて設定値を決めています。configureがどのようなCプログラムを生成しようとしているのかが分かれば、OpenVMS alphaの設定値を決める参考になるでしょう。

configureを変更して、生成しようとしているCプログラムと、そのコンパイル方法を表示させるようにしてみました。

--- configure.org       2016-03-16 16:07:02.148767000 +0900
+++ configure   2016-03-16 16:13:11.852319000 +0900
@@ -1992,6 +1992,9 @@
 {
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
   rm -f conftest.$ac_objext
+  echo "#+++#ac_fn_c_try_compile#$as_lineno#$(eval $(echo $ac_compile | sed -e 's/>&5//' -e 's/.*/echo &/'))"
+  cat conftest.c
+  echo "#---#"
   if { { ac_try="$ac_compile"
 case "(($ac_try" in
   *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
@@ -2029,6 +2032,9 @@
 ac_fn_c_try_cpp ()
 {
   as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
+  echo "#+++#ac_fn_c_try_cpp#$as_lineno#$(eval $(echo $ac_compile | sed -e 's/>&5//' -e 's/.*/echo &/'))"
+  cat conftest.c
+  echo "#---#"
   if { { ac_try="$ac_cpp conftest.$ac_ext"
 case "(($ac_try" in
   *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;

この変更を加えたconfigureを実行すると、次のように#+++#から#---#の間に生成しようとしているソースが表示されます。

checking for suffix of object files... o
checking whether we are using the GNU C compiler... #+++#ac_fn_c_try_compile#4267#gcc -c conftest.c
/* confdefs.h */
#define PACKAGE_NAME "gzip"
#define PACKAGE_TARNAME "gzip"
#define PACKAGE_VERSION "1.4"
#define PACKAGE_STRING "gzip 1.4"
#define PACKAGE_BUGREPORT "bug-gzip@gnu.org"
#define PACKAGE_URL ""
#define PACKAGE "gzip"
#define VERSION "1.4"
/* end confdefs.h.  */

int
main ()
{
#ifndef __GNUC__
       choke me
#endif

  ;
  return 0;
}
#---#
yes
checking whether gcc accepts -g... #+++#ac_fn_c_try_compile#4305#gcc -c -g conftest.c

ここからCプログラムを抜き出してOpenVMS alpha上でコンパイルしてみれば良いのですが、手作業で切り出すのは大変なので簡単なツールを作りました。今まではsh、sed、awkなどを組み合わせて作っていましたが、今回はpythonを使う事にしました。pythonは気にいっている言語で、今後も多用したいと思っています。提供されているライブラリが便利なことに驚き、とても気持ちよく作成できました。

1. OptionParseライブラリを使えば、コマンドラインのオプションを解析するだけでなく、ヘルプ・メッセージや、バージョン表示オプションなども出せるようになるので、便利でした。
2. fileinputライブラリを使うと、処理対象となる入力ファイルがコマンドラインで指定されても、標準入力から与えられても、気にせずに処理できるので、楽でした。

     1  #! /usr/local/bin/python
     2  # -*- coding: utf-8 -*-
     3  # genconftest.py -- configureの実行ログファイルからconftest.cを抽出
     4  def main():
     5      import fileinput
     6      import os.path
     7      import sys
     8      from optparse import OptionParser
     9
    10      parser = OptionParser(
    11          usage="usage: %prog [options] [logfile]",
    12          version="$Id: genconftest.py,v 1.5 2016-03-18 11:54:12 furusawa Exp $")
    13      parser.set_defaults(verbose=0)
    14      parser.add_option('-v', '--verbose',
    15                        action='count', dest='verbose',
    16                        help='make lots of noise')
    17      parser.add_option('-q', '--quiet',
    18                        action='store_const', dest='verbose', const=0,
    19                        help="be vewwy quiet (I'm hunting wabbits)")
    20      parser.add_option('-d', '--directory',
    21                        dest='dirname',
    22                        default="conftest",
    23                        help="Output files into the directory")
    24      (opts, args) = parser.parse_args()
    25
    26      if len(args) >= 2:
    27          sys.exit("Too many logfiles")
    28
    29      if os.path.isdir(opts.dirname) == False:
    30          sys.exit("%s:Directory not found" % opts.dirname)
    31
    32      if opts.verbose >= 2:
    33          sys.stderr.write("opts.verbose:%d\n" % opts.verbose)
    34          sys.stderr.write("opts.dirname:%s\n" % opts.dirname)
    35
    36      writing = False
    37      for line in fileinput.input(args):
    38          if fileinput.isfirstline() and opts.verbose >= 2:
    39              sys.stderr.write("read from:%s\n" % fileinput.filename())
    40
    41          if '#+++#' in line:
    42              writing = True
    43              l = ['/*\n', line, '*/\n']
    44              x = line.split("#")
    45              filename = "%s/conftest_%s_%d.c" % (opts.dirname,
    46                                                  x[3],
    47                                                  fileinput.lineno())
    48              continue
    49          if '#---#' in line:
    50              if opts.verbose >= 1:
    51                  sys.stderr.write("write to:%s\n" % filename)
    52              f = open(filename, 'w')
    53              f.writelines(l)
    54              f.close()
    55              writing = False
    56          if writing:
    57              l += line
    58
    59  if __name__ == '__main__':
    60      main()
    61  # $Id: genconftest.py,v 1.5 2016-03-18 11:54:12 furusawa Exp $

configureの結果を処理してみたところ、108個のCプログラムが生成されました。そのうちac_fn_c_try_compileによるものは105個、ac_fn_c_try_cppによるものは5個でした。