特集.NET 7 ×IBM i ❶WindowsアプリケーションとIBM iとのミニ連携史　～時代の要請に応じて継続的に進化、20種以上の多様な連携技術

2022年11月に.NET 7のPower対応が発表され、WindowsアプリケーションとIBM iとの新たな連携に「新次元を拓く」期待が高まっている。特集では、IBM iとWindowsの連携技術の歩みを振り返り、.NET 7の導入、セットアップ、連携方法、利用メリットなどを整理し、今回の発表内容の意義とインパクトを探った。

 

text＝佐々木幹雄　日本IBM

 

IBM iはAS/400（S/38）時代から周辺クライアント（DOS、OS/2、Windowsなど）との連携機能を提供してきた。Part1ではAS/400以降の代表的なAS/400-Windowsの連携機能（データ交換やプログラム呼出し）を解説する。

PCサポート

「PCサポート」とは、現在のIBM i Access Family（5770-XW1）の前身のAS/400ライセンスプログラムの名称である（図表1）。PCサポートは対象のクライアントOS（DOS、OS/2、Windowsなど）ごとに各々のモジュールを提供していた。代表的な機能としてはAS/400のストレージ（共用フォルダ）をクライアントにネットワークドライブとして提供する機能、AS/400 5250端末セッションからクライアントのPCコマンドを実行する機能などがあった。

当初PCサポートはエミュレータ機能を含まないものだったが、後継のiSeries Accessファミリーでは5250エミュレータも追加された。PCサポートの系譜につながる最新ソフトウェアであるACS（Access Client Solutions）では、Javaベースの完全に新しいソフトウェアに刷新が図られるなど時代に応じて変遷している。

サポートする通信プロトコルもSNA中心からTCP/IPへと変化し、接続形態もTWINAX接続からLANベース（トークンリング、イーサネット）へと変化していった。共用フォルダは、当初はOS/400のライブラリとは独立した別構造のファイルシステムという扱いだったが、IFS（統合ファイルシステム）が整備された際、/QDLS配下に統合された。IBM iファイルシステムのWindowsクライアントとのネットワーク共有は、現在ではCIFS/SMBサーバー機能（ネットサーバー）を介して提供されている。

ちなみに5250対話型ジョブからPC上のコマンドを実行するSTRPCCMD/STRPCOコマンドは現在でも利用可能である（図表2、5250対話型ジョブからPCコマンドをバッチ実行するRUNRMTCMDは、セキュリティ脆弱性などの理由により現在では利用できない）。機能的に整理すれば、Windowsクライアントとのファイル共有、リモートのWindows上のプログラム実行がサポートされており、その時代に要請された業務で必須となるWindows連携バリエーションは網羅し続けてきたといえる。

データ転送機能

データ転送機能は、歴代の5250エミュレータで提供されてきた機能である（図表3）。IBM i、AS/400のデータベースファイル、ソース物理ファイルとPCクライアント間のCSV、テキストファイルその他とファイル転送するための機能である。このデータ転送機能は、IBM i（主にEBCDIC）とWindows（主にShift-JIS、のちにユニコード）間の文字コード変換やDb2 for iテーブルのカラム定義（DDS定義）を参照したデータ変換、SQLと同様なレコードの選択、カラムの選択、複数ファイルとの転送などを標準で提供しており、非常に使い勝手がよい。バッチ実行にも対応しており（RTOPCB、RFROMPCBコマンドやACSのacslaunch_win-64.exe /PLUGIN=downloadなど）新旧問わずほとんどのユーザーが利用している機能である。時代に応じてXLSやXLSX対応、UTF-8対応、列名の追加などの機能も少しずつ拡張している。

参考までに、ACSでサポートするPCファイルタイプや主要な転送オプションを図表4に記載する。

歴代のデータ転送機能は、Excel（かつてはLotus 1-2-3も）との連携機能をアドインとして提供してきた。アドインをExcelに追加するとExcelのメニューにデータ転送機能が表示され、別ウインドウからデータ転送機能を開始しなくともExcel上でデータ転送を実行して結果をExcelのシート上に取得し、すべての操作をExcel上で完結できた。ACSはJavaベースに切り替わったため従来のExcelアドインが提供できなくなり、代わりにACSデータ転送の転送先としてアクティブ・スプレッドシートが追加された。アクティブ・スプレッドシートをデータ転送先として指定すると、ExcelのワークシートにIBM iからのダウンロード・データを直接書き出すことができる（図表5）。

 

ODBC、JDBC

1990年代半ば以降、Windowsサーバー上にアプリケーションロジックを配置し、ODBCでIBM iをデータベースサーバーとして使用するクライアント/サーバー型のアプリケーションが普及した。さらに2000年代に入るとサーバーサイドJavaアプリケーションも一般に普及し、JDBCでアクセスしIBM iをデータベースサーバーとして利用する形態も一般化した。現在ODBCドライバーは、ACSのWindows用のアプリケーションパッケージで提供されている。Db2 for i用のODBCドライバーはODBC規格の機能拡張に合わせて拡張されており、現在ではADOやOLE DBなどもサポートされている。

JDBCドライバーは、IBM i OSのライセンスプログラムのToolbox for Javaで提供される。IBM i 7.1以降は、Toolbox for Javaは5770-SS1オプション3 拡張基本ディレクトリー・サポートに統合されて提供されている。Toolbox for Javaにはオープンソース版のJTOpenというパッケージも存在する。位置づけはToolbox for Javaよりも新しいコード実装になるもので、新しい機能拡張をToolbox for Javaよりも先に利用可能である（JTOpenサイトの記載によると、Toolbox for Javaより最大4カ月先に新機能が利用可能になる場合がある）。JTOpenで安定化した機能は順次Toolbox for Javaに反映されていく。新しい機能拡張を利用したい場合は、JTOpenサイト（https://jt400.sourceforge.net/）からダウンロードしてほしい。IBMサポートは、Toolbox for Javaと同様に受けることができる。

APPC通信プログラムによる連携

ODBC/JDBCの普及以前にもAS/400の黎明期からSNAのLU6.2によるAPPCプログラムを記述して、複数のAS/400間や、IBMや他社ホスト機とのプログラム呼出しが可能であった（図表6）。OS/2やWindows、DOSなどインテルアーキテクチャ上のOSでもAPPCプログラムの実行は可能で、実際利用しているユーザーも相当数あったと思われる。SNAはその後TCP/IPでカプセル化したAnyNetなどをサポートしIPベースのネットワークインフラ上でも長期にわたって利用されてきたが、IBM i 7.4で正式にAnyNetのサポートも終了し、最新のIBM iではAPPC通信やその他SNA通信機能（SNADS、DDM、表示装置パススルー、APPNサポートなど）はEnterprise Extenderで提供されている。

FTP、SFTP、FTPS

WindowsとIBM iのファイル交換手段として、FTPは最も普及している方法の1つであろう。Windowsのコマンドプロンプトや5250画面からftpコマンドを実行しファイル転送が可能である。FTPをベースとしたWindwos、IBM i、その他プラットフォーム間のファイル転送ツールも数多く存在している。IBM iからWindowsや他のIBM iにFTP通信を開始するには、5250のコマンドラインからFTPコマンドを実行しFTPセッションを開始する。IBM iでは宛先にIPアドレスを指定する場合、下記のように独自の指定方法（RMTSYS（*INTNETADR）パラメーターを指定）が必要である。

FTP RMTSYS（*INTNETADR） INTNETADR（’192.168.1.10’）　

ホスト名を指定する場合は一般的な指定方法と同様で、FTP RMTSYS（WINSVR01） のように指定できる。

昨今はセキュリティ面の懸念から暗号化を行わないFTPは利用を制限される場面も増えてきており、代わりにSFTPやFTPSで暗号化しファイル転送を行うことも一般的になっている（図表7）。

ファイル共有（SMB/CIFS、NSF、SAMBA）

AS/400時代はWindowsほかクライアントとのファイル交換はPCサポート共用フォルダーであったが、iSeries Accessファミリー登場後、Windows 95以降はWindowsの標準的なネットワークファイル共有プロトコルであるSMB/CIFSに準拠したファイル共有方式になっている。IBM iの機能名では、IBM iの任意のIFSフォルダ（ディレクトリ）をWindowsと共有する機能をネットサーバーと呼んでいる。ネットサーバーはLinuxクライアントに対するSambaサーバーとしても動作する。SMB/CIFS以外にもNSFサーバー/クライアントとしてWindows（ほか）とIBM i間でファイル共有することも可能である。ちなみにIBM i同士で互いのIFSフォルダを共有するには/QFileSvr.400という専用のIFSフォルダを介した方法が提供されている。

SOAP、REST API

2000年代半ばにSOA（Service Oriented Archi
tecture）でWebサービスが普及した際に使用されたプロトコルがSOAP（Simple Object Access Protocol）である。SOAPは異なるOSやプラットフォーム間で透過的にサービスを呼び出すための業界標準プロトコルで、ベースとしてXMLを使用した。

SOAは現代のAPI連携、マイクロサービスによる分散アプリケーションの先駆けといえるもので、アプリケーションやサービスの粒度は現代よりもやや大きいものが中心だったように筆者は理解しているが、分散したヘテロなアプリケーション実行環境をネットワーク接続してサービスとしてアプリケーションを構成する、その際共通のインターフェース（SOAP、XML、WSDLなど）を定義し利用するという基本的な考え方は、現代のAPI連携と共通といえよう。

IBM iでは早くからSOA基盤としてのESB（Enterprise Service Bus：たとえばWebSphere ESB）のサポートがなされた。昨今ではレガシーなアプリケーション資産（RPG、COBOL、CLプログラムなど）をSOAPで呼び出し可能とする統合APサーバー機能を提供している。

その後SOAの思想は、よりアプリケーションの粒度を小さくし、XMLベースのSOAPよりも簡易に呼び出し可能なREST API（HTTPプロトコル）+JSONベースに進化して現代に続いている。IBM iもトレンドに呼応してREST API対応、JSON対応を拡張している。前述の統合APサーバー機能をREST API、JSON対応に拡張してレガシーアプリケーションのREST API化が可能となっている。IBM i 7.2以降ではIBM iのシステムリソースやOS機能、REST API接続しDb2 for iへの直接SQLを発行するインターフェースなどさまざまな拡張を実装し続けている（図表8上段）。

以上はIBM iをサービスプロバイダーとして利用する形態であるが、逆のパターンでIBM iをREST APIサービスリクエスターとして動作させる機能（Db2 for i HTTPスカラー関数とILE RPGのTransport APIの2種類）もサポートされている（図表8下段）。

SOAPやREST APIはWindowsとIBM iだけに限定されるものではなく、現在稼働している大半のプラットフォーム（たとえばIBM zSystemsメインフレーム・サーバー）やクラウド上のサービス、アプリケーションでサポートされ、異機種間・異なるプログラミング言語間でのシステム連携を広範囲に実現している。

SQLベースの連携技術の拡張（IBM iサービス、Db2 for iサービス）

IBM i 7.2以降で特に強化が著しい機能にIBM iサービス、Db2 for iサービスがある（図表8上段）。これらは外部からSQLでIBM i上のアプリケーション資産に加えて、さまざまな運用管理機能を利用可能とするものである。別な言い方をすると、5250画面やCLプログラムで実行していたアプリケーションや運用管理機能をSQLでIBM iの外部からの操作で実行するものである。

IBM iサービスが登場した背景にはWindowsに限らず、非IBM i技術者やプログラマーがSQLという最も普及しているインターフェースを使ってIBM iを運用管理できるようにしようという目的がある。このことでIBM i固有のスキル習得を軽減し、IBM i 運用管理のハードルを下げることができる。またIBM iサービスにはCLコマンドや5250端末操作のSQLへの代替にとどまらず、複数の機能を組み合わせた出来合いのサービスとして利用可能なプロシージャも含まれる。

IBM iサービス、Db2 for iサービスはここまでに紹介したようなアプリケーション連携の視点で利用可能な機能と、IBM iの運用面の改善・標準化に利用できるものがある。WindowsはじめIBM iの外部からIBM i運用管理をSQLで標準化することができる。

ハードウェアベースのWindowsサーバー連携技術（FSIOP（IXS）、IXA）

最後に、これまでとは異色なWindows連携技術を紹介する。FSIOP/IXS（File Server IO Processor/In
tegrated xSeries server）は、Windowsサーバーを実行可能なインテルベースのサーバーハードウェアをPower SystemsのPCIスロット形状にパッケージングし筐体内にインストールするハードウェアである（図表9）。FSIOP/IXSはストレージレスのWindowsサーバー（OS/2もサポートしていた）として動作し、ストレージはIBM iが管理するASP内から*NWSSTGとして切り出し、NWSSTG内をWindowsサーバーが管理するものであった。

その後PCIカードにパッケージングする機構から、標準規格品のIBM xSeriesサーバーをHSLケーブルやイーサネット経由のiSCSIでIBM iに接続するIXA（Integrated xSeries Adapter）が登場した。アーキテクチャはIXSと同様で、ディスクレスのxSeriesをIBM iと物理的に接続し、Windowsサーバーのストレージ管理とWindows稼働ハードウェアの電源オフ/オン制御、バックアップなどをIBM iに集中管理させるものである。IXSに対するIXAのメリットは、IBM i接続用の専用ハードウェアはxSeriesを制御するための比較的単純なものに限定できる点である。その結果、さまざまなキャパシティや構成のxSeriesを接続できた（図表10）。

FSIOP/IXSとIXAの基本的なコンセプトはIBM i のオールインワン・コンセプトに基づくもので、Windowsで動作するアプリケーションをIBM i管理下に統合しようというものであった。

時代を経て登場した.NET7サポートではこういった専用のハードウェアを必要とせず、Windowsサーバー上で実行されているアプリケーションを容易にPOWERハードウェア上で統合可能になった。