Open Establishment Controller（OEC）インターフェースを製作し、これを用いて、3270ターミナルを、エミュレートされたIBM端末上のVM/370へ接続します。
前回の投稿では、IBM 3270 クライアント端末 について触れました。ここでは、メインフレームコンピューターが規模を拡大し、何千人ものユーザーにサービスを提供可能になったことで、高度に統合されたシステムの一部として機能していたこの端末ファミリーが、非常に興味深いものであると紹介しています。今回の投稿では、「Open Establishment Controllerインターフェース」のオープンソース実装を調べてみます。これは、3270シリーズのターミナルをメインフレームにインターフェース経由で接続するために使用するものです。このOECハードウェアはArduinoベースで、私たちは今回、これをRaspberry Pi 4上で実行される、エミュレーションされたメインフレームと、インターフェース経由で接続するために使用します。
インターフェースを作る
前回の投稿でお話しした通り、3270データストリーム（プロトコル）は TCP/IP 接続（別名TN3270）が可能であり、これが一般的に、昨今のメインフレームコンピューターで使われています。当然ながら、 LinuxやWindows、Mac用の、より好都合の端末エミュレーションが提供されているのにも関わらず、実際の端末を使用する人はほとんどいないでしょう。ですが、私たちの場合、実際にクラシックな端末を使用したいと考えているので、同軸ケーブルでの接続によってインターフェースを連結するということになりますが、一方で、このOECでは、TN3270をエミュレーションされた端末に接続するために使用します。
現在、入手困難な3270送受信機のASICを使用するv1のArduinoシールドと、iCE40 FPGAと一緒にSTM32マイクロコントローラーを使用するv2の、2つの同軸ケーブル（coax）インターフェースがあります。3270 ICはv2の設計が完了する少し前に入手したものなので、ここではv1を製作します。
通例的に、抵抗器をはじめとする、小型の構成部品のはんだ付けから始めました。
コンデンサやパルス変圧器といった大きな構成部品へと、作業を進めていきます。3270 ICは、今ではかなり希少であることを踏まえ、 再利用できるように、差し込み式にしました。
組み立てが完了したら、シールドをArduino Mega 2560 (715-4084) に取り付けました。
この時点で、Arduinoをプログラムできるようになり、また、ファームウェアソースが、PlatformIOプロジェクトとして提供されました。これは、VS Codeですでにインストールし終えているので、あとは、Extension ManagerからPlatformIO IDEを検索し、インストールするだけです。その後、coax interface1ファームウェアプロジェクトを開き、ビルドを選択することで、アップロードも選択できるようになります。
coaxターミナルインターフェースはこれで完成しましたが、OECアプリケーション自体はPythonで書かれているので、Raspberry Pi 4 4GB (182-2096) で、インターフェースをUSB経由で接続して、アプリを実行してみようと思います。
ソフトウェアの依存関係
OECにはPython 3.8以上が必要ですが、一方、RaspbianにはPython 3.7が提供されているため、より新しいバージョンをインストールする必要がありました。まず、ビルドに関する依存関係を、Gitと一緒にインストールすることから始めました。
$ sudo apt install git build-essential tk-dev libncurses5-dev libncursesw5-dev libreadline6-dev libdb5.3-dev libgdbm-dev libsqlite3-dev libssl-dev libbz2-dev libexpat1-dev liblzma-dev zlib1g-dev libffi-devこのあと、最新のPython 3.xソースを入手し、ビルドしてインストールできました。
$ wget https://www.python.org/ftp/python/3.9.5/Python-3.9.5.tar.xz
$ tar xvf Python-3.9.5.tar.xz
$ cd Python-3.9.5
$ ./configure --prefix=/usr/local/opt/python-3.9.5
$ make -j4
$ sudo make altinstall確実にパスを通せるように、~/.bashrcに以下を加えました。
PATH=$PATH:/usr/local/opt/python-3.9.5/binOEC
次に、OECのインストールに移ります。Gitリポジトリをクローンし、Python仮想環境を作成することから始め、その後、pipで必要なモジュールをインストールしました。
$ git clone https://github.com/lowobservable/oec.git
$ cd oec
$ python3.9 -m venv VIRTUALENV
$ source VIRTUALENV/bin/activate
$ pip install -r requirements.txtこれで、3270 coaxインターフェースと、open establishment controllerの設定が終わりました。では次に、Herculesメインフレームエミュレーターのインストールについて考え、その後でVM/370オペレーティングシステムについて見ていきましょう。
Hercules
Hercules エミュレーターには2種類のメインバージョンが存在します。オリジナル開発ブランチ、別名Spinhawkは、ロジャー・バウラー氏をはじめとした人々が管理しており、また、Hyperion forkは SoftDevLabs （SDL）により、製作されています。後者には多数の新機能が組み込まれているようですが、一方、オリジナルは最近、メンテナンスモード寄りのようにみられます。
今回は、パッケージマネージャを介して簡単にインストールできることから、オリジナルバージョンを使用することにしました。
$ sudo apt install herculesVM/370
VM/370（Virtual Machine Facility/370）が最初に発売されたのは1972年のことで、 それよりも前のCP/CMSオペレーティングシステムを再実装したものでした。「370」の部分で、IBM System/370が、メインフレームコンピューター製品であることを示していますが、IBM System/370は、1964年に発表された、画期的なSystem/360の後継機でした。S/360は、その多数の機能が有名で、特に、大小、性能の高低などあらゆるモデルが用意されていたのですが、どれも同じ説明書セットを使用しており、さらに、エミュレーションを介して前のシステムとの下位互換性をサポートしていました。
最近では当たり前のことかもしれませんが、S/360の柔軟性と下位互換性は当時、信じられないほど斬新なものでした。同様に、VMにも多くの最新機能が組み込まれていて、ログオンユーザー全員に対し、アドレス空間と仮想デバイスまで用意され、完全な仮想マシンを提供してくれました。各VM内では、別のオペレーティングシステムのインスタンスを、その当時のIPL（これはIBM用語のイニシャルプログラムローダー、いわゆる「ブート」のこと）にすることが可能でした。
VMは今も現役で、 IBM zアーキテクチャのメインフレームに対し、強力な仮想化プラットフォームを提供しています。ただ、このバージョンの懸念事項として、かなり古いものであり、機能的には現在のO/Sのサブセットとなってしまうといえるでしょう。
初期のリリースはオープンソース／パブリックドメインであると考えられており、また、最近では愛好家のコミュニティー、ベテランによるメインフレームプログラマーの集まりが多いことから、そういったコミュニティーがメンテナンスを引き受け、古くなったパブリックリリースをもとにした、Community Editionの提供に踏み切りました。これは、実用的な応用はできないかもしれませんが、本物のメインフレームオペレーティングシステムを使って、直接的な体験をしたいと思っている人にとっては、存分に楽しめるものであることは確かです。
はじめに、VM/370 Community Editionをダウンロードし、解凍しました。
$ wget http://www.vm370.org/sites/default/files/2021-05/VM370CE.V1.R1.1.zip
$ unzip VM370CE.V1.R1.1.zip
$ cd VM370CE.V1.R1.1VM/370の配布は、多くの仮想ディスクイメージとして提供され、メインフレームというよりはむしろ、エミュレーター内での特定の方法で設定することが想定されています。Herculesはconfigファイル経由で設定され、また、既製のvm370ce.confが提供されます。ですが、現行のリリースでは、SDLバージョンのHerculesを使用する想定となっており、いくつかconfigファイルの違いがあるため、 configファイルの「ARCHLVL」というキーワードを「ARCHMODE」と置き替える必要がありました。他にも、「CNLSPORT」の値を、OECが接続のためにエクスポートするTCPポート番号である23に変更する必要もありました。
これで、次のコマンドによって、エミュレーターを起動可能になりました。
$ sudo hercules -f vm370ce.conf実際のところ、これは理想的な手順ではありません。おそらく、netcapを使って、Herculesの実行ファイル がルート権限なしで、特権ポートを使えるようにするべきだったと思います。
Herculesが起動し、VMをIPL（ブート）するスクリプトを読み込みます。
コマンドプロンプトにてESCを押すことで、上の写真のような仮想オペレーターコンソールをトグルでき、ここでは特に、エミュレーションされたデバイスのリストを確認することが可能です。
エミュレーションされたメインフレームが、同じRaspberry Piで実行されているため、別のウィンドウでOECを起動して、TN3270モードとlocalhostのホストアドレスを指定できます。ここでは、最初にエラーが出た後で端末がアタッチされ、その性能が表示されたことがわかります。
3270ターミナル上で、最初の出力を確認できました！
Enterキーを押すと、VM/370ログオン画面が出迎えてくれます。
最初、ログオンに失敗しましたが、その後無事にCMSUSERとしてログオンに成功しました。続いて、「ipl cms」と入力し、会話型モニタシステム（シングルユーザーO/S）をVM内で読み込みます。後に続く文字は、利用できるディスクのリストと、さらにはヘルプへの歓迎メッセージが表示されています。ここからは、利用できるコマンドを探り、ファイルのリスト作成や、コピー、編集、削除などを行い、VM/370 CEの一部として提供されている、各種コンパイラーを活用していきます。
ただ楽しむためだけに
より近代的な、1990年代後半の端末（ 3270ファミリーの最終モデルである IBM 3483）でも見ることができます。今回は、OECを次のコマンドで起動させました。
$ python -m oec /dev/ttyACM0 vt100 /bin/sh -lこれによって、OECをVT100モードで操作し、LinuxシェルをRaspberry Pi上でspawnし、これを端末セッションにアタッチします。上の写真では、シェルから「top」を実行していることがわかります。
ただ楽しむためだけに、テキストベースのウェブブラウザ「Lynx」をインストールしてみました。ここでは、より旧式のIBM 3179ターミナルが、RSウェブサイトのナビゲーションに使用されている様子がわかります。当然画像はありませんが、その点を考慮しても素晴らしいものです！
まとめ
今回、ビンテージの3270ターミナルを、エミュレーションされたメインフレームに（または手元にあるなら実際に本物の端末に）接続することを可能にしてくれた、OECの筆者であり、coaxインターフェースの設計者でもある、アンドルー・ケイ（Andrew Kay）氏には、ソフトウェアの製作とハードウェアの設計に関して、心から感謝申し上げます。インターフェースを構築し、最終的に実際の端末をHerculesとVM/370で使えたことは、本当に楽しいものでした。次は、Phosphorの前にしばらく座り込み、VMやCMS、クラッシックメインフレームアーキテクチャを、何にも邪魔されることなく探ることを、楽しみにしています。
コメント