SYS$SCRATCH:ETCETERA.LOG;1: 9月 2020

2020-09-29

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で応答する番号の初期値を設定できます。

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

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

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

avahiを利用すると何が出来るようになる？

自宅にはアーキテクチャの異なるマシンが何台かあります。それらの多くは必要な時だけ電源を入れています。24×365で電源が入りっぱなしなのは、FreeBSD/amd64です。またWindows10のデスクトップPCはクライアント環境として使っており、就寝時には電源を落としています。

自宅LANには、他にもNetBSD、OpenBSD、OpenVMSや、VirtualBoxとかVMwareにインストールしたCentOSなどが接続されます。基本的にはTCP/IPの固定アドレスを割り当てるようにしていますが、DHCPを使う場合もあります。そのひとつがdynabook SS SX/15AにインストールしたNetBSD/i386です。自宅で使う場合は固定アドレスを割り当てることも可能ですが、外出先に持って行くことがあるので、その場合はDHCPを利用することになります。自宅か外出先かに依って設定を切り替えるのは面倒なので、自宅でもDHCPを使うことにしています。そうしておけば設定を切り替えずに済むからです。

ここで問題になるのが、自宅LANでDHCPを利用した際に割り当てられたアドレスが変動することです。なにしろDHCPなのですから、同じマシンに同じアドレスが割り当てられるとは限りません。それがDHCPというものなので、それはやむを得ないのですが、自宅LANにある他のマシンから接続しようとした際に、アドレスが決まっていないと、不便です。

なんとか解決方法はないものかとWebを検索していたら、avahiというものが見つかりました。技術的にはmDNSという仕組みに基づく実装のようです。僕が必要としているものよりも大掛かりで、必要のない機能も含まれていますが、概念としては求めているものです。

どのようなものなのか、ちょっと試してみようと思います。しかしavahiの想定している環境構築の概念がはっきりしません。問い合わせをおこなうデーモンが動くようですが、LAN上に一つだけ存在すればよいのか、各マシン上に各々配置する必要があるのか、全体像が見えてきません。

Webを探ると事例が見つかるのですが、「そもそもavahiとは」というような情報がみつかりません。とにかく試してみるしかないのかと思っているところです。

2020-09-27

SSHのエージェント転送をTera TermやRLoginで実行

SSHの秘密鍵を多数の接続先に置かないで済むため、エージェント転送をおこなうにはU*IXならば次のような手順となります。

ssh-agentを実行しておく。
ssh-addで秘密鍵を登録しておく。
sshで接続する際にオプション「-A」を指定する。

これは接続元がU*IXの場合の手順ですが、もし接続元がWindowsなら手順はどうなるのでしょうか。

端末エミュレータとしてRLoginを使うなら、接続設定において「サーバー」>「プロトコル」で「エージェント転送を有効にする」を指定するだけです。とても簡単です。

端末エミュレータとしてTera Termを使う場合はどうでしょう。RLoginのように簡単なのかと思って、SSH認証において「エージェント転送する」を指定しましたが、これでは駄目で、以下のようなエラーが出てしまいました。

Permission denied (publickey,keyboard-interactive).

どうやらU*IXの手順で必要だったssh-agentやssh-addに相当するものが無いと駄目のようです。

ssh-agentに相当するのはPageantというソフトのようです。これはWinSCPに不増kしていたものを使いました。元々はPuTTYに付属するようですが、事情はよくわかりません。
ssh-addに相当するのはPageantに秘密鍵を登録することです。
Tera Termで「エージェント転送する」を指定するという行為は、オプション「-A」を指定することに相当するのでしょう。

Tera Termの挙動はU*IXでの手順とおなじですが、RLoginの方が使い勝手が良い気がします。

SSHを鍵認証する場合の鍵作成の方針とは？

SSHで鍵認証を利用する際に必要となる秘密鍵・公開鍵は、どのような方針で作成するものなのでしょうか？ssh-keygenで鍵を作成するわけですが、コマンドを打てば鍵が出来てしまいますが、それがSSH鍵認証で想定している方針に合致しているとも限らないわけです。

ssh-keygenで作成した公開鍵は、以下のような形をしています。右端にあるのはコメントでオプションで変更することができますが、デフォルトでは鍵を作成したユーザ名が入ります。

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABErI+RbZ foo@bar.com

このデフォルトで与えられるコメントを考えると、鍵は「ユーザ（とホスト）」を単位に作成されるものと考えるのが基本なのかと思います。SSH鍵認証の入門レベルの説明としては、それで構わないと思います。しかし現実の環境において、多数のサーバを扱う管理者であれば、どうなってしまうのでしょうか。サーバが何十台もあったとしても、各サーバでssh-keygenを用いて鍵を作成することは可能でしょう（サーバ上に秘密鍵を置くことの是非はあるかもしれませんが）。作成された公開鍵を全サーバに配置していく作業は（できるかもしれませんが）大変です。さらに作業が大変か否かという実務的な問題だけではなく、各サーバに秘密鍵が置かれていることがセキュリティ的に妥当といえるのかという問題もあるでしょう。

このような問題はssh-agentとssh-addを利用することで解決できそうです。「エージェント転送」を使えば、クライアントマシンだけに秘密鍵を置いておけば、その他のサーバに秘密鍵を置く必要がなくなるようです。

管理者が使用しているクライアントマシンで鍵を作成しておけば、全サーバでは鍵を作成しなくて良くなるのですから、これで疑問は解消したと言えるのでしょうか。つまり鍵は「個人」を特定するものなのでしょうか。

それでは管理者が複数のマシンをクライアントとして利用している場合には、どうなるのでしょうか。鍵が「個人」を特定するのであれば、同一管理者が使用する全クライアントマシンでは、秘密鍵を使いまわすことになります。それでも構わないのかもしれませんが、そのような運用を認めると、複数の管理者で秘密鍵を使いまわすことに繋がる恐れもないとは言えません。

運用次第で何とでもなるという話ではなく、SSH鍵管理の発想とは何だったのかという事を知りたいと思います。

2020-09-23

Tera TermでもRLoginでもOpenVMSの利用に問題はないのか

Microsoft Windows上で使う端末エミュレータは、昔からTera Termを利用していました。しかし接続先の日本語環境をUTF-8にすると、（何かの設定が悪いのだと思いますが）ちゃんと日本語が出なくなりました。そこで代わりとなる端末エミュレータを探すとRLoginに辿りつきました。それ以来、Tera Termを使うことは無く、もっぱらRLoginを利用していました。

最近OpenVMS Alpha 8.4-2L1をインストールし始めた際にも、RLoginで接続していました。コマンドライン操作をしている分にはRLoginでも別に差し支えありません。ところがスクリーンエディタを利用しようとすると、ちょっと問題が出てきました。

OpenVMSのスクリーンエディタは、VT端末のキーボード配置を期待して操作するようになっています。今日のパソコンのキーボードと似ていますが、ファンクションキーの配置など多少キー配置が異なっています。RLoginでVT端末と同一の操作をするためには、何か設定すれば良いのか、そもそも不可能なのか、よくわかりません。そこで最近は利用していなかったTera Termを使ってみました。VT端末のキーボードとの対応関係を理解しておく必要はありますが、少なくともVT端末と同等の操作をすることができます。

接続先によってTera TermとRLoginを使いわける事は避けたいと考えています。できればRLoginに統一したいのですが、そううまくいくかどうか調査してみようと思います。

2020-09-22

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

アカウント作成
DECnet-Plusの設定
バッチキューの設定
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』というマニュアルを見つけたので、目を通してみました。些細なことかもしれませんが、やはり違いがあるようです。

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

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

2020-09-20

CentOS7のインストールで作成されるLVM

VMwareを利用して、CentOS7をインストールした際のデフォルトの挙動を調べてみました。

使用したのは「CentOS-7-x86_64-DVD-1708.iso」です。これはCentOS 7.4です。インストール中に選択する項目はありますが、まずはデフォルトのままにしてみます。インストール完了後、ブートしてディスクの割り当て状況を確認してみました。LVMが使われている事は承知していましたが、「/dev/mapper/centos-root」と「/dev/mapper/centos-home」が出来ていました。

もしインストール中にネットワーク設定をおこない、（例えば「myhost」のように）ホスト名を指定すると、論理ボリューム名が変わるようです。「/dev/mapper/centos_myhost-root」のようにホスト名が入るようです。

ここで気になったのは、別のところで使っているCentOS7の論理ボリューム名とは違っていたことです。そこでは「/dev/mapper/cl-root」となっています。この名前は、どのようにして付けたのでしょうか。インストール中に指定する箇所は無かったはずです。

もしやと思い、「CentOS-7-x86_64-DVD-1611.iso」を使ってインストールしてみました。これはCentOS 7.3です。やはりデフォルトのままでインストールを完了したところ、論理ボリューム名が「/dev/mapper/cl-root」のようになっていました。要するにCentOS7.3と7.4とで挙動が変わったということでしょうか。この件はリリースノートには書かれていないようです。どういう理由で変更されたのでしょうか？

2020-09-12

VSI版OpenVMS Alpha 8.4-2L1インストールが完了

Digital PersonalWorkstation 500auにVSI版OpenVMS 8.4-2L1のインストールが完了しました。実質的には「インストール成功」だと思っているのですが、途中でエラーが出ているので、「成功」とは言わずに「完了」としておきます。

%PCSIUI-I-COMPWERR, operation completed after explicit continuation from errors
**************************************************************
* *
* W A R N I N G *
* *
* One or more errors were encountered during installation/ *
* upgrade. The target system may not operate correctly. *
* *
* You should correct the condition that caused the error(s) *
* and repeat the installation/upgrade. *
* *
**************************************************************
The installation is now complete.

先日インストールしようとしましたが、途中でエラーが出たのでインストールを中断しました。同様の問題は他でも出ているようで、VSIのフォーラムで「Error installing 8.4L1 on FreeAXP 4.0」として報告されています。そこでは次のように書かれています。

This is almost certainly a bug in the VSI OpenVMS Alpha V8.4-2L1 kit and indicates, that VSI has never tested a fresh install of this kit on an empty or non-OpenVMS system disk. The 'workaround' seems to be easy: do not abort the installation.

要するにインストール中にエラーが発生し「Terminating is strongly recommended. Do you want to terminate? [YES]」というメッセージが出る（しかも2回も）のですが、それを無視して続行すれば良いということです。

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] no

%PCSI-E-OPENIN, error opening DISK$ALPHASYS:[VMS$COMMON.][SYSLIB]DCLTABLES.EXE;
as input
-RMS-E-FNF, file not found
%PCSI-E-OPFAILED, operation failed
Terminating is strongly recommended. Do you want to terminate? [YES] no
Portion done: 20%...30%...40%...50%...60%...70%...80%...90%
%PCSI-I-PRCOUTPUT, output from subprocess follows ...
% - Execute SYS$MANAGER:TCPIP$CONFIG.COM to proceed with configuration of
% HP TCP/IP Services for OpenVMS.
%
Portion done: 100%

この後は、インストーラを終了し、改めてCCLプロンプトから、インストールしたディスクを指定してブートします。ブート中にシステム・パラメータの調整が行われ、自動的に再起動されますが、無事に完了しました。

Accounting information:
Buffered I/O count: 3942 Peak working set size: 6736
Direct I/O count: 1786 Peak virtual size: 186624
Page faults: 4754 Mounted volumes: 0
Charged CPU time: 0 00:00:03.97 Elapsed time: 0 00:01:10.28

Welcome to OpenVMS (TM) Alpha Operating System, Version V8.4-2L1

Username: system
Password:

インストール中にVSIから提供されたVMS Software Community Licenseを入れたので、これでOSのインストールは終了です。

これまではDEC/COMPAQ/HPEのHobbyist OpenVMS Programを利用していましたが、これからはVSI版を使っていくことになります。

stage

Japan Times Alphaの2020年8月21月号に掲載されたコラム「Odds & Ends」（James Tschudy）の話題は「stage」でした。このコラムは毎月テーマを決めていて、8月のテーマは「Japanese English」です。日本人は英語だと考えているけど、ネイティブが理解している意味から外れており、コミュニケーションの障害にもなるものです。

コラムでは、ミュージカルを観にいった女性から「It was a wonderful stage.」と言われたという逸話が語られています。日本人が使う「stage」というのは、英語ネイティブからすると理解に苦しむので、本来の使い方についてコラムで語られます。

著者は、何故日本人がミュージカルなどの演劇のことを「stage」と呼ぶのかわからないと書いています。

I wonder how the Japanese-English meaning got started. It might have come from "stage play," but I don't have any idea. My dictionary isn't any help either.

これは私見ですが、日本人が英語で「stage」を使ってしまうのは、日本語ではミュージカルなどを（「演劇」と呼ぶこともありますが）「舞台」と呼ぶからなのではないでしょうか。日本人に限らず、外国語を使う場合（日本人が英語を使う場合もそうですが）母語の影響は無視できません。日本人がミュージカルを鑑賞して「素晴らしい舞台だった」と感想を述べるのを、英語で「It was a wonderful stage.」と直訳してしまったからではないかと思うのですが、どうでしょうか。

2020-09-08

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でも報告されています。

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

2020-09-05

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

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

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

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

DIMM5：54-25092-DA x2
DIMM3：54-25092-DA x2
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を試してみることが出来るようなりました。

2020-09-04

WebブラウザとWebアプリケーション

普段利用しているのはFirefoxです。そのOSはWindows10なので、以前ならInternet Explorer、最近なら旧EdgeとかChrome Edgeが入っているのですが、これまではFirefoxを利用してきました。

Webが登場してから、いろいろなブラウザが現れ、進化してきました。しかし当初から言われているのは、ブラウザによってWebアプリケーションの動きが違うという事です。昔のWebアプリケーションは、画面も機能もシンプルでした。それでもWebブラウザによって画面が崩れたりしましたが、Webアプリケーションの機能もシンプルなので、利用する側としては、それほど困りはしませんでした。

ところが最近は、Webアプリケーションの機能が深化してきたためなのか、Webブラウザによって特定の機能が動作しない事例が増えてきました。これは致命的です。

利用しているFirefoxのバージョンは80.0.1です。Firefoxの最近のバージョンでは、このブログの記事を編集する画面が、うまく動作していないのです。一方でGoogle Chrome 85.0.4183.83ならば、全く問題がありません。さらに最近気づいたのが、FirefoxだとStarbucksのリワード管理画面が開かないことです。これもGoogle Chromeなら問題ありません。これ以外にも、Firefoxでは機能しないWebサイトがあります。

このような現象は、Firefox自体の問題なのか、僕の設定や利用しているアドオンの影響なのか、よくわかりません。分かっていることは、Firefoxでは特定のWebサイトの機能が正常に動かないということです。

Webサイトを開発している側からすれば、多彩な利用者のWebブラウザ環境をフォローするのは困難でしょう。だからWebサイトが推奨するWebブラウジング環境を提示し、それで動くことを保証するのが精一杯だろうと思います。しかし利用者側にとってみれば、Webサイトが期待した環境とは異なっている場合も少なからずあります。その時に、利用者側の不具合を解決するためにWebブラウザに申告しても、必ず解決できるとは限りません。もしかすると将来のバージョンで解決するかもしれませんが、何時になるか分かりません。そうであれば、利用者が出来ることは、問題が発生するWebサイトは利用しないか、Windows10に付属する新Edgeを使うことにするか、いずれかでしょう。

2020-09-03

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

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

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

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

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

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

VSI版OpenVMS Alpha 8.4-2L1のZIPEXE

VSI版OpenVMS AlphaのCommunity Licenseを取得したら、キットを提供している場所も教えてくれたので、ダウンロードしておきました。ところが拡張子が「ZIPEXE」になっています。自己解凍形式ZIPファイルだと思うので、Hobbyist OpenVMSとして入手したOpenVMS 7.3で実行してみましたが、エラーが出てしまいました。

問題が発生した時の基本的な態度は、エラーメッセージの意図するところを理解して解決を図ることです。それはそうなのですが、このアプローチでは解決までの道のりは遠そうです。別のアプローチとしては拡張子「ZIPEXE」とは何者なのか調べてみることです。このような拡張子は以前には見かけた記憶がありません。

comp.os.vmsで「ZIPEXE」というキーワード検索をしてみたら2006年8月30日付の投稿「Changes to OpenVMS Patch Kit Formats」が見つかりました。さらに投稿に対する応答の中に次のような記述を見つけました。

ZIPEXE is ZIPSFX. You can unzip it with your own UNZIP program on any platform you like (eg. you unpack the IA64 or VAX ECO on your MARVEL) and you can unpack it on the intended platform without any UNZIP.EXE (because it is part of the archive file).

ZIPEXEというのは、予想していたように自己解凍形式ZIPファイルのようですが、解凍するのは、unzipが使えさえすれば、OpenVMSでなくても良さそうです（自己解凍するなら、実行イメージとして有効なのはOpenVMS Alphaだけだと思いますが）。そこでFreeBSD/amd64 12.1上のunzipを使ってみまたところ、解凍することに成功しました。これならエラーメッセージの調査は不要です。

3つあったZIPEXEの中は、次のようになっていました。

ALPHA0842L1.ZIPEXE
Archive: ALPHA0842L1.ZIPEXE
Length Date Time Name
-------- ---- ---- ----
623616000 02-07-17 15:46 ALPHA0842L1.ISO
ALPHA0842L1DOC.ZIPEXE
Archive: ALPHA0842L1DOC.ZIPEXE
Length Date Time Name
-------- ---- ---- ----
4722688 07-19-17 11:43 AVMS842L1DOC.ISO
540 07-19-17 11:43 AVMS842L1DOC.ISO_VNC
AVMS842L1DOC.ZIPEXE
Archive: AVMS842L1DOC.ZIPEXE
Length Date Time Name
-------- ---- ---- ----
4722688 07-19-17 11:43 AVMS842L1DOC.ISO
540 07-19-17 11:43 AVMS842L1DOC.ISO_VNC

ここで2番目と3番目は、ファイル名が違いますが、中に入っているファイルは同一のようなので、実際には1番目と2番目だけで良いのでしょう。

次の問題は、ZIPを解凍すると出てくるISOファイルの中には何が入っているのかということです。Microsoft Windows10のエクスプローラーではISOファイルをマウント出来るそうなので、確認してみました。AVMS842L1DOC.ISOの方は、次のようになっていました。

ドライブ E のボリュームラベルは AVMS842L1DOC です
ボリュームシリアル番号は 4F70-5FF6 です

E:\ のディレクトリ

2017/01/27 02:38 575,985 VSI_OVMSALPV842L1_SPDQS.PDF
2017/01/24 02:44 1,960,883 VSI_OVMSALPV842L1_UPG.PDF
2017/06/22 03:03 599,634 VSI_OVMS_ALP842L2_NFRN.PDF
2015/05/12 00:36 454,876 VSI_OVMS_LMF_UTILITY.PDF
4 個のファイル 3,591,378 バイト
0 個のディレクトリ 0 バイトの空き領域

しかしALPHA0842L1.ISOをマウントしようとすると、「ファイルが壊れています」というエラーが出てしまいます。ただこれはISOファイルが壊れているという事ではないと思います。FreeBSD上で確認してみたところ、次のような結果を得ました。

ALPHA0842L1.ISO: Files-11 On-Disk Structure (ODS-2); VAX/VMS or OpenVMS file system; volume label is 'ALPHA0842L1 '
AVMS842L1DOC.ISO: ISO 9660 CD-ROM filesystem data 'AVMS842L1DOC'

Windows10がマウント出来るのはISO9660形式だけなのでしょう。ALPHA0842L1.ISOはOpenVMSのファイル形式「Files-11」になっているだけで、別に壊れている訳ではありません。

ALPHA0842L1.ISOをCDに焼いておかないと、インストール作業には利用できません。問題なのはWindows10のエクスプローラーでは、ISO9660形式のISOイメージしかCDに焼けないことです。どうしようかと思いましたが、PCの中に「Nero Express Essentials 12.0.20000」が入っていたので、これを使うことにしました。こちらはISO9660形式以外でもCDに書き込めるので、問題はありませんでした。

VSI版OpenVMS Alpha 8.4-2L1をインストールするためのキットが入手できたので、これをつかってDigital PersonalWorkstation 500auにインストールできるか試してみようと思います。

2020-09-01

%DCL-W-ACTIMAGE, error activating image CMA$TIS_SHR

VSIから入手したライセンスを利用するためには、VSI版OpenVMS Alpha 8.4-2を使用しなければなりません。現在はDEC版OpenVMS Alpha 7.3-1を利用しているので、アップデートするのか、それとも新規インストールするのか、方向性を考えなければなりません。

VSIからライセンスを入手した際に、VSI版OpenVMS Alphaのキットの所在も教えてもらいました。サイトにアクセスしてファイルを入手してみたのですが、拡張子が「.ZIPEXE」となっているファイルがあります。こういう拡張子のファイルはDEC時代のOpenVMSにはなかったと思います。どうやらHPE時代に登場したようです。VAX/VMS以来のセーブセットを使えば良いのではないかと思うのですが、何か問題があったのでしょうか。

この拡張子は自己解凍形式のZIP圧縮ファイルらしいのです。試しに実行しようとしたら、エラーになってしまいました。

$ run [-]avms842l1doc.zipexe
%DCL-W-ACTIMAGE, error activating image CMA$TIS_SHR
-CLI-E-IMGNAME, image file PWS500$DKA100:[SYS0.SYSCOMMON.][SYSLIB]CMA$TIS_SHR.EXE
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image

さっそく躓いてしまいました。OpenVMSのバージョンが旧いのが原因なのでしょうか。なかなか順調には進んでくれません。

登録: 投稿 (Atom)