「FH2$W_RECATTR」の構造がわからない

simh V3.8-1のvax.exeを使ってOpenVMS  VAX V7.2を動かしています。OpenVMS側にあるファイルをWindows側に持ってくるため、simhの仮想磁気テープのファイルを使用する方法を考えています。他にも方法はあると思いますが、技術的興味から、しばらくはこの方法を追求してみようと思っています。

 

OpenVMS側で作成した磁気テープはANSI X3.27 Level 3に準拠した構造になるようです。マニュアル『Guide to OpenVMS File Applications』の「1.3.1. ANSI-Labeled Magnetic Tape」に情報があります。その「1.3.1.6.3. HDR3 Label」では「These attributes are converted from 32 bytes of binary values to 64 bytes of ASCII ...」のような記述があります。さて、この32バイトの情報は、具体的にはどのようなものなのか調べているのですが、核心の情報にたどり着けていません。

 

ODS2を操作する何かのプログラムの一部らしき箇所に「struct RECATTR」という構造体がありました。この中の要素を数えると、32バイト分ありましたので、多分これがそうなのかもしれません。しかしプログラムのソースファイルに書かれているということは、何か出典となる情報に基づいていると思われますが、それが何なのか見つからないのです。

手元に『VMS File System Internals』（ISBN 0-13-931783-X）があるので調べてみると、「Figure 2-2: Format of the Header Area」の中に「FH2$W_RECATTR (32 bytes)」という箇所を見つけました。多分これのことだろうと思うのですが、32バイトの詳細構造がわかりません。

 

同書の「2.4.1 Directory Structure」では、「The last word of the directory file's record attributes area (FAT$W_VERSIONS) is ...」のような記述があるところを見ると、何か構造があって然るべきなのですが、その構造を記した情報にたどり着けません。

 

この構造がわからなくても、OpenVMS→Windowsの情報転送には困らない感触があるので、わからないならわからないで構わないとは思います。しかし何かに書かれているのであれば、それを知りたいところです。

『平家物語』を「鱸」まで覚えた

 2023年の夏頃から『平家物語』を暗記しようとしています。覚えたから何かあるわけではありません。ただし、ただ読み流すだけよりも、言葉の一つ一つに注意が向くようになりました。

 

『平家物語』と言えば、「祇園精舎の鐘の声、諸行無常の響きあり」で始まる冒頭が有名です。『平家物語』には、話のまとまりごとに副題がついており、冒頭の箇所は「祇園精舎」です。次が「殿上闇討」で、「鱸」、「禿髪」と続きます。

 

覚え始めてから2年弱ほどですが、ようやく「鱸」まで覚えました。重要人物である平清盛がようやく登場してきました。これから覚える「禿髪」では、「驕る平家は久しからず」のエピソードが語られていくことになります。

 

『平家物語』は、まだまだ長いので、一生かかっても覚えきれないでしょう。そもそも巻一すら終わらないかもしれません。

OpenVMSのRMS attributesにおける「32 bytes of binary values」って何？

simh V3.8-1のvax.exeを使ってOpenVMS VAX V7.2の環境を整えようとしています。ひとまずOSを入れることはできています。今後の作業を考えると、OpenVMS側からWindows側にファイルを持っていく方式を考えておこうと思っています。TU-81で磁気テープを使おうと思いますが、実際には仮想環境なので、現実にはsimhの仮想磁気テープのファイルを扱うことになります。磁気テープはANSI X3.27形式が使われているようなので、その構造を理解しようと思います。

 

OpenVMSにおける磁気テープの構造は『Guide to OpenVMS File Applications』に詳しい情報があります。ここで「1.3.1.6.3. HDR3 Label」には、次のような記述があります。

The RMS attributes describe the record format of a file. These attributes are converted from 32 bytes of binary values to 64 bytes of ASCII representations of their hexadecimal equivalents for storage in the HDR3 label.

 

HDR3にはRMS attributesが格納されており、その32バイトのバイナリ値が64文字のASCII文字列として表現されているというのです。つまり1バイトが2文字ですから、いわゆる「16進ダンプ」のような見た目なのでしょう。それは良いのですが、「RMS attributes」というの何でしょうか。

 

「RMS attributesのことなら、もう既にご存知かと思いますが」と言うかのような感じです。しかし私は何のことかわからないので、調べてみなければなりません。おそらく何かのマニュアルに詳しく記述されていると思います。それを探し出そうと思います。

simhのvax.exe上で動作させるOpenVMS VAXにおける仮想磁気テープのファイル構造

simh V3.8-1のvax.exeを利用してOpenVMS VAXを動かしています。OpenVMSからWindowsにファイルを送るために、simhの仮想磁気テープのファイルを使おうと思います。OpenVMS側は、磁気テープをANSI X3.27 Level 3に準拠した構造にしているそうです。ANSI X3.27の構造には詳しくありませんが、仕様書をネットで見つけましたので、調べてみようと思います。

 

ファイル構造を調べるため、OpenVMS側でファイルをテープに格納してみて、そのファイルがWindows側でどのように見えるかを確かめてみようと思います。そのファイルの16進ダンプは、次のようになりました。

00000000  50 00 00 00 56 4F 4C 31 53 49 4D 48 20 20 20 20  P...VOL1SIMH    
00000010  20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                  
00000020  20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                  
00000030  20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                  
00000040  20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                  
00000050  20 20 20 33 50 00 00 00 50 00 00 00 48 44 52 31     3P...P...HDR1
00000060  54 45 53 54 31 2E 54 58 54 20 20 20 20 20 20 20  TEST1.TXT       
（以下略）

 

ANSI X3.27の仕様書によれば、「VOL1」とか「HDR1」というのが、規定されている構造を示す文字列のようです。それでは、その前にある「50 00 00 00」というのは何でしょうか。当初、これもANSI X3.27の規格で定められている情報かと思ったのですが、そうではなさそうです。

 

ネットで情報を探ってみると「SIMHで古代UNIXを再現(2)」を見つけました。この中に「SIMHのテープフォーマットは、SIMH Magtape Representation and Handlingに解説があります。」という記述があります。この「SIMH Magtape Representation and Handling」を確認してみると、SIMHの都合により、実データの前後に「Leading Length」と「Trailing Length」が入るようです。これが「50 00 00 00」なのでしょう。

 

ひとまず、SIMH側が挿入する情報の構造は判明しました。この段階で、仮想磁気テープのファイルをアクセスしてみるプログラムを組んでみました。これを拡張すれば、ANSI X3.27の構造を表示するプログラムになると思います。

 

 #!/usr/bin/python3

def readrecord(f):
    global TapeMark
    len0 = int.from_bytes(f.read(4),'little')
    if len0 == 0:
        TapeMark += 1
        if TapeMark >= 2: raise EOFError
        return 0
    TapeMark = 0
    data = f.read(len0)
    len1 = int.from_bytes(f.read(4),'little')

    print(TapeMark, len0, data[:4], data[4:16])

    return 0 if len0 != len1 else len0

def readblock(f):
    while True:
        if readrecord(f) == 0: break

TapeMark = 0
with open("test-tu81.tap","rb") as f:
    while True:
        try:
            readblock(f)
        except EOFError:
            break
#[EOF]

simh上のOpenVMSとWindowsとの間でのファイル交換

simh V3.8-1のvax.exeを使用してOpenVMS VAX V7.2を楽しんでいます。まだOSをインストールだけです。今後のことを考えて、いまのうちにOpenVMSとWindowsとの間でファイルを交換するための方法を考えておこうと思います。

 

普通に考えれば、最も適切なのはネットワークを利用することでしょう。TCP/IPが使えるようになれば、FTPを利用するだけのことです。もしネットワークを利用しないのであれば、往年の環境がそうであったように、何かオフラインで利用できるメディアを使うことになります。以下のようなメディアが考えられます。

• CD-ROM
• 磁気テープ
• フロッピーディスク

 

simhをWindows上で動作させており、WSLが使えるため、WSLでmkisofsを使えば、Windows上のファイルを含んだISOファイルを生成できます。そのISOファイルをsimhでattachしておけば、OpenVMSではRRD40からマウントできるので、WindowsからOpenVMSにファイルを渡せるようになるはずです。しかしCD-ROM経由では、逆方向（OpenVMSからWindows）は難しそうです。

 

磁気テープを使うというのは、いかにもクラシックなコンピュータという趣がします。simhではTU81として指定されたデバイスにファイルをattachしておけば、OpenVMS側ではINITIALIZEやMOUNTなどの操作が可能です。何か適当なファイルをCOPYすれば、simh側でattachされているファイルに書き込まれるのを確認しました。

 

問題は、Windows側でファイルを取り出す方法です。ファイルを確認してみると、ANSI X3.27形式のヘッダが付いているようです。これを解釈して、特定のファイルを取り出すには、どうしたら良いのでしょうか。もし本当にテープデバイスを持っているなら、mtコマンドが使えるかもしれません。しかしsimhが作成した単なるファイルに対してmtコマンドは使えません。

 

ANSI X3.27形式のヘッダが入っているファイルを解釈して操作できるツールというものが、存在しても不思議はないのではないかと思うのですが、ネットを探しても見つかりませんでした。何か方法がないか、探ってみようと思います。

 

最後のフロッピーディスクというのは、何ができるのか全くわかりません。そもそもOpenVMSで扱うフロッピーディスクは、FATを解釈できるのでしょうか。もしかするとODS-2だけのような気もします。仮にFATを取り扱えるとしても、それをWindows側で「仮想的なフロッピーディスク」として操作するには、どうするのか見当もつきません。

OpenVMS VAXに接続する端末エミュレータのためのキーマップ設定におけるTera TermとRLogin

simh V3.8-1のvax.exeを使ってOpenVMS VAX V7.2をインストールしました。まだOSを入れただけですが、simhではDZデバイスをTCP/IPで接続できるので、端末エミュレータからログインできるようになりました。端末エミュレータとして、昔はTera Termを利用していたのですが、ずいぶん前からRLoginに移行しています。端末エミュレータを使い分けるのは面倒なので、できればRLoginを使いたいとは思いますが、ひとまずTera TermとRLoginで使い勝手を検討します。

 

まずログインするだけであれば、Tera TermでもRLoginでも、いずれも可能でした。ただし注意が必要なのは、ログイン先がOpenVMSだということです。Tera TermもRLoginもVT端末の動作を再現しようとしており、VT端末のエスケープシーケンスにも対応しているようなのですが、キーボードの扱いがどうなっているのか、気になります。

 

そもそも、DECのVT端末でつかわれているLK201キーボードと、PCの109キーボードとでは、違う点があります。

1. ファンクションキーは、LK201では20個ありますが、109キーボードでは12個しかありません。
2. 109キーボードのテンキーにおける「+」キーは、LK201では「-」と「,」として別のキーになっています。
3. カーソルキーの上部にある6個のキーの役割が、LK201と109キーボードでは、配置が異なります。

 

Windows上で動作する端末エミュレータは、109キーボードを使いますが、VT端末として操作するためにはLK201と同等の操作ができる必要があります。このためには、上述した違いを吸収するために、キーマップ設定をおこなわなければなりません。

 

端末エミュレータで実現できるか否かを確認するまえに、どのようなキーマップ設定とするか方針を決めておきます。

1. LK201のファンクションキーは20個あり、109キーボードの12個では数が足りません。そこで、F1～F10を使うことにして、F11～F20は、Shift+(F1～F10)で実現することとします。
2. 109キーボードのF11とF12が余りますが、これはLK201のF15とF16に割り当てます。OpenVMSではF15を「Help」として、F16を「Do」として使っています。これらは使用頻度が高いので、押しやすいようにF11とF12を使います。
3. カーソルキーの上部にある6個のキーは、LK201と109キーボードで配置が異なります。例えば、「Ins」と「Del」が109キーボードでは左端にありますが、LK201では「Insert」と「Remove」は右上にあります。ここで考えるのは、109キーボードの刻印を無視してLK201の配置に合わせるのか、LK201の配置を無視して109キーボードの刻印に合わせるのかという選択です。もし日常的にLK201を利用しているのであれば、身体が配置を覚えているでしょうから、LK201の配置に合わせたほうが良いでしょう。しかしキーの刻印を参照しながら操作するのであれば109キーの刻印に合わせた方が良いことになります。私自身は、LK201を使用する機会はありませんので、109キーボードの刻印を見ながら操作することになると思うので、キーボードの刻印に合わせてエスケープシーケンスが送出されるように設定します。
4. 109キーボードのテンキーには「+」しかありませんが、LK201では「-」と「,」の2つのキーがあります。これを実現するため、テンキーの「+」は「,」に割り当てることとして、Ctrl+「+」を「-」にしました。

 

このような方針を実現できるように、端末エミュレータのキーマップ設定をおこないます。設定ができているか否かは、OpenVMSの「EVE（EDIT/EVE）」や「EDT（EDIT/EDT）」で確かめます。

 

Tera Termの場合は「KEYBOARD.CNF」というファイルに対応関係を記述するようです。EVEやEDTで確かめましたが、問題なさそうです。

 

RLoginは、設定画面を使います。Tera Termとはキーマップの考え方が違うようで、Microsoft Windowsの仮想キーコードを使って割り当てをおこなうようです。ところが、この方式だとVT端末と同等の挙動を実現できませんでした。LK201はテンキーの上部にPF1～PF4が割り当てられており、特にPF1は「GOLD」として使われます。ところが109キーボードでは「NUMLOCK」なので、例えばテンキーの「7」は、NUMLOCKの状態によって「7」だったり「Home」だったり変化します。このため仮想キーコードも「PAD7」と「HOME」となり、特に「HOME」の場合は、カーソルキー上部にある「Home」と区別することができません。

 

普段は、Tera Termではなく、RLoginを使用しているので、OpenVMSもRLoginにしたかったのですが、そうもいかないようです。OpenVMSを操作するときだけはTera Termにするしかないのかなと思います。

『時刻表大解剖』は面白い

近所の書店に『時刻表大解剖』という本があったので買ってみました。時刻表そのものや、鉄道の歴史などについて、詳しく書かれていて、とても楽しく読めました。本の帯には「JTB時刻表マスター認定試験」を実施するとあります。今年がJTB時刻表100周年なので、その記念イベントのようです。

 

近年JTBからは復刻版時刻表が幾つか発売されています。古い時刻表を出版しようとするには、それなりに手間もかかると思います。『時刻表大解剖』の11ページには、「電算写植完了」が昭和62年12月とあります。それ以降のものであっても、すぐに復刻版が出版できるわけではないと思いますが、それ以前のものであれば、なお大変でしょう。かけた手間に見合うだけの販売数が見込めるかという営業判断も必要かとは思います。そうであっても、昭和43年10月大改正（いわゆる「よんさんとう」）のような画期となるものが、戦前とか終戦直後にはないものでしょうか。そのような時刻表も復刻版を出版してくれれば、とても嬉しいです。