最近、日本IBM より RPG Open Access RPG Edition(以下 RPG Open Access ) の
紹介があった。RPG Open Access は 米 IBM が 2010年に発表した System i の
RPG の拡張である。特に RPG Open Access は System i の Web化を行うための
拡張ツールであり、弊社が 2008 年に発表した RPG# と非常に良く似ている部分が
あるので興味深くここに紹介する。

■ 関連項目：OfficeQuattro.com TechNet - RPG#とは

■ 関連項目：Open Access for RPGご紹介資料

RPG Open Access は簡単に言うと RPG のファイル仕様書での装置: WORKSTN を
HANDLER キーワードで拡張して実際の入出力を HANDLER (ハンドラー) が
横取りして行うものである。( HANDLER というキーワードは RPG 標準の機能ではない。)

  0001.00 FPGM001D  CF   E             WORKSTN
  0002.00 F                                     HANDLER(QHANDLER)
                      :
  0069.00 C                   WRITE     DSPHEAD
  0070.00 C                   READ      DSPHEAD 

のような記述となる。ここで QHANDLER とは入出力のインターフェースとなる
プログラムであり、ベンダーからも提供されることもあるとのことである。
さらに興味深いのは HTML から GENCLSOA というコマンドによって
次のような ICFF の生成の基となる DDS ソースを生成することである。

   0001.00      A          R DSPHEAD
   0002.00      A            GYONO          4
   0003.00      A            SHCODE        10
   0004.00      A            SHNAME        24
   0005.00      A            SHTANK         7
   0006.00      A            SHSCOD         4

つまり RPG Open Access とは HTML とのインターフェースには DDS を利用して
WORKSTN ファイルの代わりに ハンドラーというゲートウェイを使う手法を採用しており、
これは次に紹介する弊社の RPG# とそっくりである。

RPG# はハンドラーではなく SPECIAL ファイルによって記述して｢HTMLドライバー｣が
HTML とのゲートウェイの役割を果たしている。

  0001.00 FPGM001H  CF   E             SPECIAL PGMNAME('ASNET.COM/HTMLDVR') 
  0002.00 F                                     INFDS(INFDSF) 

  0069.00 C                   WRITE     DSPHEAD
  0070.00 C                   READ      DSPHEAD

の記述となる。RPG Open Access と非常に良く似いてる。
( RPG# が RPG Open Access を真似たわけではない。RPG# の発表は RPG Open Access の
発表の 2 年前に既に発表/出荷されているのである。)

さらに RPG# もコンパイルの時点で HTML から次のような DSPF の生成の基となる
DDS ソースを生成する。

   0001.00      A                                      DSPSIZ(24 80 *DS3)
   0002.00      A                                      MSGLOC(24)
   0003.00      A                                      PRINT
   0004.00      A          R DSPHEAD
   0005.00      A            GYONO          4Y 0O  1  2EDTCDE(3)
   0006.00      A            SHCODE        10A  O  1  2
   0007.00      A            SHNAME        24O  O  1  2
   0008.00      A            SHTANK         7Y 0O  1  2EDTCDE(1)
   0009.00      A            SHSCOD         4A  O  1  2

これも非常に良く似ている。ただし RPG Open Access は GENCLSOA というコマンドを
必要とするが RPG# はコンパイルの時点で DDS ソースは自動的に生成されるので
ユーザーは、どのような DDSソースが生成されているのかは一切、気にする必要はない。
RPG# は IBM が RPG Open Access を発表する2年前に既に完成されていて RPG Open Access と
ほぼ良く似たアーキテクチャーでできているのだから RPG# のポリシーに誤りは無かった言えるだろう。
それでは RPG Open Access と RPG# は大差無いのだろうか ?

ここで両者を比較してみよう。

	RPG Open Access	RPG#
メーカー	IBM	株式会社オフィスクアトロ
発表時期	2010 年	2008 年
サポート OS Ver	OS Ver6.1 〜	V5R2M0-V5R4M0, Ver 6.1-
ゲートウェイ	ハンドラー	HTML ドライバー
RPG コンパイラー	X (サポートなし)	○ (標準サポートあり
入出力ファイル	ICFF (通信ファイル)	DSPF (表示ファイル)
オーバーレイ表示	不可	可能
機能キー	不可	可能
フィールド属性	文字フィールドのみ	数字/文字の両方可
入力妥当性検査	X (できない)	○ (自動検査)
数字の編集	不可 (演算命令で行う)	EDTCDE, EDTWRD 可能
サブ・ファイル	不可	可能
処理方式	メイン・メーチン	イベント駆動型
開発言語	ILE-RPG HTML JavaScript Java または EGL JSF	RPG# (ILE-RPG) HTML JavaScript
開発環境	Ratinal RDi	eStudio
実行環境	IBM 製ハンドラー 5733-OAR Ratiional Open Acess WebShere Application Server IBM Apache HTTP Server	HTMLドライバー Alaska

機能の大きな差異は IBM が ICFF を採用したのに対してオフィス・クアトロでは
DSPF を採用した点である。また IBM の ICFF は文字フィールドのみを採用しているので
数字を直接、入力することはできない。従って入力の妥当性検査はアプリ自身が
行わねばならず、編集も演算命令の中でいちいち、すべての数字フィールドの編集を
行わねばならない。入力される数字が正しいか不安は残るし、出力においても
編集コードや編集語を使用することはできない。
例えば、

                 EVAL    DSP_TANKA = %TRIM(%EDTC(TANKA:'J'))
                 EVAL    DSP_KING  = %TRIM(%EDTC(URKING:'K'))
                   :

のようにして編集するフィールドの数だけ、毎回、繰り返さなければならない。

これに対して RPG# では文字属性を指定して入力妥当性も行えるし編集コードや
編集語も HTML中に EDTCDE や EDTWRD を埋め込むことができる。
IBM RPG Open Access は手間がかる上、入力の信頼性も問題となってしまうのである。

さらに決定的な差となるのは DSPF でおなじみの｢サブ・ファイル｣という概念を
RPG Open Access では使用することができないのである。
IBM は RPG Open Accessの紹介の中では、

というように自信の無さを示しているが、これは元のサブ・ファイル記述は捨てて
SQL バッケージによる再開発が必要であることを示している。

Web では明細行を伴うレポート形式の表示が圧倒的に多いにもかかわらずデータを
サブ・ファイルという非常に便利で効率の良い方法を使用することができないのは
Web開発としては致命的な欠点である。
せっかく System i には RPG/COBOL から利用できるサブ・ファイルがありながら
これが使えないとなると｢画龍点睛を欠く｣といわれても仕方のないことであろう。
RPG# はもちろんサブ・ファイルを十分利用することをサポートしている。
サブ・ファイルが使えないとなると RPG 開発者は RPG Open Access を使おうという
気力が失せてしまうであろう。一体この差はどこから出ているのかというと
ICFF を採用した IBM と DSPF を採用したオフィスロクアトロとの判断の差である。
恐らく IBM は DSPF には 24行 * 80桁 の表示枠の制約があるものとして
採用を諦めてしまったのであるまいか ?
もしそうであったら DSPF への理解が足りなかったと言えるだろう。
もう一度 RPG# が生成する DSPF ソースを見てみよう。

   0001.00      A                                      DSPSIZ(24 80 *DS3)
   0002.00      A                                      MSGLOC(24)
   0003.00      A                                      PRINT
   0004.00      A          R DSPHEAD
   0005.00      A            GYONO          4Y 0O  1  2EDTCDE(3)
   0006.00      A            SHCODE        10A  O  1  2
   0007.00      A            SHNAME        24O  O  1  2
   0008.00      A            SHTANK         7Y 0O  1  2EDTCDE(1)
   0009.00      A            SHSCOD         4A  O  1  2

これを見れば確かに DSPSIZ(24 80 *DS3) となっていて 24行 * 80桁 の表示枠の制約があるように
見える。ところが各フィールドの表示位置の記述を見て欲しい。
すべてのフィールドは( 1 2 ) のように 1行目の2桁目が開始位置として定義されている。
つまりすべてのフィールドの表示位置が重なってしまうのである。
しかし、この DSPF を CRTDSPF でコンパイルすると CPD7866 (重大度10) の警告エラーとは
なるものの コンパイルは正常に成功して DSPF は作成され、各フィールドのバッファー位置は
重なり合うとはなく生成されるのである。
つまり

ということが成り立つ。IBM はこのことに気づかなかったのであろう。
もし気づいていたらサブ・ファイルや編集コードも利用できる DSPF を見逃す手はなかったのである。
恐らく System i 側の担当者チームと オープン系の開発チームの合議によって採用された方法で
あろうが System i 側にもう少し、今一歩、考慮があれば ICFF を採用するという結論は無かった
であろう。

ICFF を採用したことによってさらに問題は続いていく。
ICFF にはもちろん機能キーは使えないので IBM は

ように勧めているが、これも後で説明する｢ソフトウェア資産の移行｣で問題となる。

WORKSTN 装置にはない HANDLER キーワードを考え出したのも苦肉の策であり SPECIALファイルを
選択していれば自由度は高くなったはずである。
EXFMT を実現するのであれば WORKSTN も意味があったが、今回のハンドラーでは EXFMT を
使用することはできない。
もうひとつ IBM が見逃してしたのは相変わらず、メイン・ルーチンを残してしまったことである。

これは開発言語の進化の経路として必定である。
BASIC もイベント駆動の Visual BASIC として進化したし、C++ も Visual C++ として
イベント駆動型への進化を遂げた。
これは Misrosoft の将来を見据えての大変な努力の賜物であったと思わざるを得ない。
さすれば RPG もメイン・ルーチンを持たず、イベント駆動型に進化しなければ
GUI コントロールを適切に処理することができないのである。Ajax にも対応することができない。
一体、メイン・ルーチンの中で｢もしボタンが押されたら...｣などのような鷹揚な処理を書くのだろうか ?

今の若い開発者達は既にメインメ・ルーチンの存在そのものに抵抗を示しているのである。
RPG# は VB や CV++ がメイン・メーチンを隠蔽したのと全く同じ動作原理によって
メイン・ルーチンを排除して完全なイベント駆動型の RPG に仕上げているのである。
RPG Open Access も Web化開発言語とするのであればイベント駆動型に進化しなければならないことに
もっと早くから気づくべきであった。
ICFF の採用とメイン・ルーチンを残してしまったことは IBM は調査と研究が足りなかったと
思えてしまう。

・IBM RPG OpenAccess の開発言語

先の比較表とRPG Open Access の 実行フローでわかるように IBM RPG Open Access の場合は

• ILE-RPG
• HTML
• JavaScript

に基本的な知識に加えて、さらに

• Java
• JSF ( Struts の後継の Webアプリケーション・フレームワーク)
• EGL ( IBM 提供の簡易言語 )

の３つを使用することをIBM は推薦している。
RPG 開発者がこれらをマスターするには HTML, JavaScript を学習した後で
Java を学習して、JSP & Servlet の仕組みを勉強して、Struts を体験して
それから、やっと JSF にたどり着く。
もうひとつ EGL (最近、IBM で開発されたばかりの言語) のマスターも必要だ。
RPGプログラマーがこれらを学習するには1年では、とても無理である。
Java ひとつを学習するにしても

と敷居はかなり高い。しかも RPGソースには相当、手を入れなければならない。
Java プログラマーでも JSF を知っている開発者は小数である。
ILE-RPG, HTML, JavaScript, Java, JSF と EGL すべてに精通している
開発者は日本国内にも米国にも、ほとんどいない。
Web 開発するのに６つの言語をマスターしなければならないプラットフォームは
それ自体、間違ったものである。

IBM はなぜ RPG プログラマーをそんなにも高いところを連れて行こうとするのかと言うと、
理由は

WAS を System i ユーザーに使わせるためである。

WAS ( WeShpere Application Server ) は Java のコンテナであり
WAS を起動するだけで System i は多くの CPUメモリを消費してパフォーマンスも
大幅に低下してしまう。
しかし 利益率の良さそうな WAS を IBM が売ることができる。
先の｢RPG Open Access の 実行フロー｣では WAS を使用しているが RPG Open Access の
ハンドラーが WAS を使用しなければならない理由はどこにもない。
ハンドラーが RPG# の HTMLドライバーのように直接、ブラウザと会話することは
技術的に何の問題もなくできる。

・RPG# の開発言語

IBM RPG Open Access に比べて RPG# の場合は、とてもシンプルである。
ILE-RPG の知識に加えて、

• HTML
• JavaScript

の学習だけで済む。しかもこれらの必要な部分は Wizard によって自動生成されるので
最初は全くわからなくても十分に実用的な HTML+JavaScript/CGI のセットが
自動生成されて直ちに動作させることができる。
しかも段階的に必要な機能が発生した都度、必要なものだけを学習すればよいような
仕組みとなっている。
中にはこれらを、ほとんど学習していないユーザーもいるが�潟Iフィクアトロでは
学習するよう進めており HTML, JavaScript のリファレンスもマニュアルの中に用意されている。

System i の法人ユーザーは既に莫大なソフトウェア資産を抱えている。
しかもミッション・クリティカルで繊細で安全な運用が求められている。
したがってソフトウェアの近代化としても、それらの資産をスクラップ＆ビルドは到底できない。
そこで既存のソフトウェア資産を Web化したいと計画すると、どうしても安全なマイグレーションとしての
移行が必要となってくる。
このとき移行とは言っても、一本々のプログラムを慎重に手作業で書き直すことはできないのだ。
莫大な多くのプログラム・ロジックの人力による書き直しは、また新たなバグの山を呼ぶだけである。

それでは RPG Open Access と RPG#、つまりTONAKAI/2.0 による移行の方法に
どのような差があるのか比較してみよう。

IBM は RPG Open Access では EXFMT 命令は WRITE または READ 命令に置き換えるように
ガイドしている。

• つまり、プログラム・ロジックを解析しながら WRITE または READ の適切なほうに
  変更しなさい、と言っている。
  １万ステップ以上もある他人が書いたプログラムを人手によって解析していくのだろうか ?
• 次に複数の表示レコードの出力、という概念はないので画面ページ毎の READ/WRITE に
  変更しなさい、と勧めている。
  つまりこれまでの表示レコードのオーバーレイ(重ね表示)が使えないので、ひとつのページの
  入出力にまとめないさい、と言っているのだ。
  しかしこれはRPGロジックと画面の大幅な修正を余儀なくされてしまう。
• さらに機能キーはボタンに変更するので *INKC , ... のような機能キーのロジックは
  別の処理に書き換えるか、無くすように指示している。
  ボタンの処理に変更するとは言うもののイベント駆動はサポートされていない。
• サブ・ファイルの再現となるとさらに大幅な修正というより再開発となってしまう。
  IBM は｢修正の方法はいくつか考えられるが SQL で条件式を定義する方法等がある｣と
  表現して、SQLバッケージや SQLストアド・プロシージャーによる代替を示唆している。

これらは何を意味しているかというと

これを見ていると、ほとんどすべてのRPGプログラムが人手による解析/調査/変更の
対象になってしまうことがわかる。つまり移行マイグレーションによる
単純で正確で信頼性の高い移行はできない。人手によるコストの高い移行のみとなってしまう。

さて RPG#、つまりTONAKAI/2.0 による移行はどのようになるのだろうか ?
DSPF をインターフェース・バッファーとして使っている RPG# であれば
とてもシンプルである。

という、大まかに言えば、この２点だけの変更で済む。もちろん実際には Webのために
些細な変更もあるが大きく変わるのは、この２点だけである。
これが何故可能であるのかというのは RPG# が

• DSPF をインターフェース・バッファーとしている。
• オーバーレイ表示を可能にしている。

ことによる。確かに HTML では複数のHTML をオーバーレイして重ね表示する、という機能は
存在していない。しかし DSPF と同じオーバーレイ機能を再現しないことには
EXFMT を単純に WRITE + READ に置き換えることができない。
この技術が TONAKAI/2.0 によるボタンひとつを押すだけの単純変換を可能にしたのである。
RPG OpenAccess ではあれば莫大な人手を投入した人海戦術と莫大な予算投資が
必要となるのは明らかである。
元のアーキテクチャーの不十分さを人手によってカバーすることになってしまう。
RPGソースを解析しながら EXFMT を READ または WRITE に変更したり、機能キーの
処理をはずしたり、サブ・ファイルを書き換えたり、等は事実上、無理であろう。
移行用のマイグレーション・エイドも開発することは不可能である。

これも

IBM が ICFF をレコード・バッファーとして採用し
RPG# では DSPF をレコード・バッファーとして採用したことが明暗を分けた。

ということに起因している。IBM は ICFF でおかしい? と思ったら DSPF でもう一度、と
戻るべきであった。HTML のオーバーレイでも、もう少し考慮し研究すべきであった。
サブ・ファイルが移行できない、というのでのであれば、そこで方針を全否定して振り出しに
戻るべきであったのだ。出発点が間違っていたのだから。

単なるWeb化というだけでなく、ソフトウェア資産の継承までを見据えた考慮が必要なのである。

RPG OpenAccess は eclipse ベースの Rational RDi で開発し、RPG# はブラウザ・ベースの
eStudio で開発する。
つまり RPG OpenAccesss では RDi を各PCに導入する必要があるが、RPG# ではブラウザが
あるPC であればよいので基本的には何も導入する必要がない。

また実行環境では RPG OpenAccess は相変わらず WAS (Whebshere Application Server) を
必要とする。無理やり JSP を使って WAS をユーザーに導入させたいのであろう。
メモリ消費やパフォーマンス低下より WAS の導入が最優先のように見える。
これに対して RPG# の実行は HTTPサーバー: Alaska と HTMLドライバーが提供されているので
特に何も必要ではない。( TCP/IPユーティリティーは当然、必須である。)

IBM は WSG (WorkStation GateWay) に始まって, JSP & Servlet, HATS, CS-Bridge,
XML-Bridge そして RPG OpenAccess とWeb化の決定打に欠ける変遷を行ってきた。
米国サイトでも一体、どれが正しい方向であるのかユーザーはその都度振り回されて
きただけでありIBM は正しい方向を示すべきである、との書き込みがあった。
IBM は RPG OpenAccess を発表してようやく RPG# に近づいてきたが、
またもや出発点を違えてしまった。
RPG の外部記述ファイルによる生産性とこれまでのソフトウェア資産の活用の
重要性に気づいたもののDSPF を扱う技術が無かったために ICFF で妥協しようとしたことで
残念ながら今回もつまづいてしまったのだ。
RPG OpenAccess は開発してみればわかることであるが、これでは開発は相当、
苦労することになるしパフォーマンスも望むことはできない。
紹介の文面から見てとれるのは恐らく RPG OpenAccess による実際の開発実績は
ほとんど無いだろうことが推測される。
RPG OpenAccess は興味深い製品でもあり、IBM としては良く頑張ったと評価したいが
今一歩の感はどうしてもぬぐえない。

RPG# 側としては、これで RPG# の方向性は間違っていなかったと自信を深めるとともに
RPG OpenAccess のアーキテクチャーでハンドラーの入れ替えでマルチプラットフォームに
対応できるとアナウンスしたことは RPG# が積極的に見習って開発を進めていく
良いアイデアであるは思うし、他にも見習うべき点があれば採用して製品の機能性と
信頼性の向上、さらなるユーザービリティの向上を目指したいと願っている。

■ 関連項目：OfficeQuattro.com TechNet - RPG#とは

■ 関連項目：Open Access for RPGご紹介資料

守口市旗

�潟Iフィスクアトロは大阪府守口市に本社を置いている。
守口市は淀川の左岸にあって、大阪市の北東に隣接する人口約14万人の
小さな都市である。大阪市の北東部ではあるが大阪府から見れば大阪府の
ほぼ中央に位置している。
守口の名前の由来は秀吉時代の「守り口」ではないかという説があるが
元々は飯盛山の原生林への入り口の「森口」であったのが石山本願寺や
大阪城の軍事的な意味で「守口」に変型したとの説が有力である。
守口の名前は室町時代の来迎寺縁起(1372年)に既に登場している。
織田信長、池田信輝の統治を経て大坂夏の陣で豊臣家が滅びるまでは
豊臣家の直轄領であった。

守口市 クリックで拡大

全国的には守口は三洋電機の本社の所在地や隣の門真市の
PANASONIC (松下電器) として知られているのかも知れない。
守口市松下町には松下電池工業もある。
この小さな守口には意外と歴史があり、東海道五十三次は江戸から
京都までの道筋であったが江戸時代に入ると大坂までの４つの宿場町を
加えて、東海道五十七次と称せられた。
守口は大坂からの最初の宿場町となり、江戸日本橋から来ると最後の
宿場町である。

守口市役所 クリックで拡大

宿場町としての守口には大名が宿泊する本陣も置かれて栄えたとの
ことである。
本編では守口の歴史と散策の一端を紹介しよう。
守口に本社を置く�潟Iフィスクアトロと守口との関係も深いものであり、
何故ここであえて守口を紹介するのかはいずれ読者の知るところとなる
はずである。
�潟Iフィスクアトロが守口にあるのは意味がある。
次に紹介する「守口」は、いずれも守口に長く在住する者のみが知る裏話や
秘話も含めて紹介している。

交通の要所

守口は近年は大阪市電や大阪市営バスの終点として発達してきたがさらに京阪電車の京橋駅から
最初の急行の停車駅でもあり、京阪百貨店や守口プリンス・ホテルを前身とする
守口ロイヤルパインズホテルや地下鉄谷町線の終点駅でもあった(現在では大日が終点) 。
道路では阪神高速守口線の終着でもあり、中央環状線と国道一号線との交差点でもある。
また伊丹空港へのモノレールの大日駅も擁している。
このように交通の要所のひとつでありながら最近では大日や守口駅周辺にも高層マンションが
建つようになってきた。自動車や地下鉄、京阪電車、そして伊丹空港や新幹線にもアクセスが容易である。

三洋電機

三洋電機本社ビル クリックで拡大

三洋電機の発祥は守口市本町であり自転車用の発電ランプを最初に
作ったのが始まりとされている。
その後、ラジオや洗濯機、テレビを発売した。
創業者は淡路島出身の 井植 敏男 は松下幸之助のもとで電気ソケットを
作り三洋電機本社とともにすぐ近くには井植氏邸宅がある。
( 井植氏邸宅の隣りのタバコ屋も井植家の縁戚のようである。)
井植氏は一度、松下電器を退職して故郷の淡路島に戻ってしまうが
彼の商才を惜しんだ当時の住友銀行の支店長が井植氏を説得して大阪に
連れ戻すのである。
井植氏の故郷・淡路島との関係は深く淡路フェリーは井植一族による
経営であり三洋電機は積極的に淡路島の企業に外注を行うようになった。
三洋電機はまた松下電器とは経営者どうしで親交が深く近所の
松下記念病院も PANASONIC と三洋電機社員との共同利用である。

井植邸宅 クリックで拡大

現在では三洋電機は業務用の冷蔵庫や自動販売機に高いシェアを
誇っているが業務用の部品のサプライに強く、何と IBM S/34 の
モーターには三洋電機製が使われていたのである。

「三洋村」とも揶揄される守口には三洋電機所有の土地不動産が多く、
最近ではマンション建築販売にも積極的に乗り出してきている。
三洋電機の元役員宅にマンションを初めて建設してから今では
京阪守口市駅前にも高層マンションを建設して販売するまでに至っている。

一里塚

一里塚の跡を示す碑 クリックで拡大

東海道五十七次の目印としての守口の一里塚も残っている。
ただし目立たない奥まったところにあるので探すのに苦労する。
一号線から左のわき道へ入ってしばらく行くと一里塚が左手に見えてくる。
一里塚は驚くほど背の低い小さな石であり、このことからも当時は
周りには大きな建物は無かったものと思われる。
この写真の石碑は一里塚ではなく一里塚の跡を示す守口教育委員会による碑である。

大塩平八郎ゆかりの書院

大塩平八郎ゆかりの書院 クリックで拡大

守口の一号線に面して非常に特徴のある旧い邸宅が残されている。
これは大塩平八郎ゆかりの書院跡と呼ばれている。
江戸時代の天保に大坂町奉行所の与力であった大塩平八郎が
米不足やワイロ政治に反発して一揆を企て大阪城の占拠を計画。
親子を中心として武装蜂起したのが世に言うところの
「大塩平八郎の乱」である。
挙兵は簡単に失敗に終わったものの島原の乱以降 200年ぶりの
合戦として江戸幕府の失政に一石を投じるものであったと言われている。
この乱を密談して計画したのではないかと言われているのがこの書院跡である。
現在は白井家の個人宅になっているが大塩平八郎を後援していた
豪農白井孝右衛門の邸宅として今も残されている。
白井家には大塩平八郎が使ったという書院が残されており (非公開)ここで「大塩平八郎の乱」の
相談がなされたのではないかとの歴史がある。
この書院跡は国道一号線に面していて�潟Iフィスクアトロからもすぐ近い場所にある。

守口大根

守口大根 クリックで拡大

愛知県の名産として知られる守口大根は、守口が発祥である。
守口大根は 1 メートル以上はある細長い大根であり、
守口が砂地であったことからこのような大根が育ったのではないかと
推測される。
秀吉が守口に立ち寄ってこの大根を食して美味であると褒めて
守口大根と命名されたと言われている。
残念ながら現在では守口大根はその名を愛知県に譲っている。

守口漬 クリックで拡大

江戸川乱歩

江戸川乱歩居住跡 クリックで拡大

「名探偵明智小五郎」で知られる、江戸川乱歩が最初にミステリー小説を
書いたのが守口の大野産婦人科の２階の下宿であり�潟Iフィスクアトロの
わずか数十メートルのところにある。
これは残念ながらつい最近になって取り壊された。
この乱歩の寓居の跡とされる場所は偶然にも豊臣時代の淀川の流れる
位置でもあった。
つまり�潟Iフィスクアトロは豊臣期の淀川河川敷に位置していると言える。

大阪遷都

難宗寺 クリックで拡大

鳥羽伏見の戦いで徳川幕府軍に勝利した大久保利通は大阪遷都の案を
明治天皇に奏上した。
しかし岩倉具視をはじめとする公家たちの猛烈な反対にあったために、
天皇に大坂を案内するという名目で大阪へ天皇を案内した。
このとき天皇が宿泊したのが守口の難宗寺である。
大阪城へ敗走した幕府軍を追うように守口まで来たのである。
激しい雨中の中、明治天皇は三種の神器を携えて夜９時ごろに難宗寺に
到着して一夜の宿を取り、守口が一夜だけの都となったということである。
( 実は明治天皇はこのあくる日には大阪市旭区太子橋(旧・橋寺町) に
訓練の視察に訪れていたことが石碑によって残されている。)
しかし大坂が都になるという計画は江戸無血開城によって幻となった。
つまり明治天皇の本拠地はそのときはまだ京都にあり、正式には
東京遷都で初めて東京に移るのである。
大久保利通は江戸は炎上するものと予測して大坂を代わりの首都として
考えたのだろう。
しかし江戸城の無血開城は大久保にも予測できなかったようである。
このため大坂遷都は幻のものとして終わった。

明智光秀による守口城

意外と知られていないのが守口城である。
最初に守口城が築かれたのは室町時代の後期とされているが象徴的であるのが明智光秀による
守口城または砦の築城である。
明智光秀は織田信長の命によって蓮如の石山本願寺を攻めたときに築城したのが
守口城であると言われている。
また守口城は難宗寺が本丸の跡であると言われたり、現在の土居あたりにあったのではないかとの説もある。
[註] 「土居」とは軍事用の目的のための土塁を意味している。
光秀は蓮如の留守中に、今すぐ攻めれば本願寺は落ちると確信したが信長の命によって
やむなく自らが攻撃することなく陣を退いた。信長と光秀の微妙な駆け引きが感じられる。

大坂夏の陣

おきく物語

大坂夏の陣で豊臣家は滅びることになるが、淀君の侍女として使えた
「おきく」の「おきく物語」でおきくが大阪城から逃れて落ち延びたのが
守口であるとされている。
「おきく物語」は徳川幕府の政権下になって出版された物語である。
大坂夏の陣では大阪城だけが炎上したと思われているが実は大阪の
ありとあらゆる場所が猛火に包まれて大阪中の一般市民を巻き込む
大パニックであったようである。
逃げ惑う大阪の人々の様子が大阪城の天守閣に展示されている。

大坂夏の陣 クリックで拡大

旭区太子橋にある御野立所と五箇樋跡

五箇樋跡

守口市を歩いていると「時空の旅」という守口市教育委員会による
現代の道標に気づく人も少なくはないだろう。
この中でいくつか「五箇樋跡」を示す道標があるが、いくら探しても
見つからないのではないだろうか ?
守口市マップや歴史散策を紹介しているウェブ・サイトでも
「五箇樋跡」を明確に紹介しているサイトはほとんどない。

この謎を明らかにするために、あえてここで五箇樋跡を紹介する。
これは実は大阪市旭区の淀川沿いに存在しているので守口市を
探したのでは見つからない。

御野立所

「五箇樋跡」とは五ケ庄(守口庄、小瀬庄，橋波庄、寺方庄、稗島庄) への
淀川からの飲料水を引いていた跡のことを意味する。
現代では近くに庭窪浄水場があるのは興味深い。

「五箇樋跡」は大阪市旭区太子橋の淀川の堤防の縁に
「御野立所」とともに残っている。
「御野立所」とは大正天皇が明治43年にこの地で工兵隊の架橋訓練を
視察された記念を残している碑である。

緑道公園

緑道公園 クリックで拡大

元、運河の跡であるが緑と桜並木として整備された緑道公園は
�潟Iフィスクアトロへ至る散策の小道でもある。
この都会にあってもわずかに残された緑に包まれた小道は
オアシスでもあり、あるときは哲学的な雰囲気も与えてくれる。
春には桜並木が美しく迎えてくれる。
緑道公園の西側に広がる松町、竹町、桃町は守口市の高級住宅街と
知られておりゆったりとした一戸建て住宅街が広がっている。

守口宿

特吟純米酒「文禄堤」 クリックで拡大

「守口宿」と「文禄堤」という名前の日本酒がある。

日本酒「文禄堤」のボトルのラベルを飾っているのは文禄堤にかかる
「本町橋」である。
このラベル絵は守口市の名誉市民である画伯によって描かれたとの
解説がボトルの裏面に書かれている。

ふる里守口を訪ねて

ふる里守口を訪ねて クリックで拡大

守口を詳しく解説した書籍として
駒井正三著「ふる里守口を訪ねて」(守口市発行) がある。
著者・駒井正三氏は故人であるが�潟Iフィスクアトロ代表取締役池田一明の池田家とは家族ぐるみの付き合いの長い親しい関係にある人である。
また駒井氏は立命館大学史学科を卒業され、長年、教職にあり守口の
郷土史の編纂にも携わっていたとのことである。
守口の歴史をこれほど詳しく紹介している本は他に例を見ない。
「ふる里守口を訪ねて」は守口市役所で入手することができる。

守口の続きは ...

守口をいろいろと紹介してきたが実は守口を最も象徴するものを敢えて紹介していない。
それは今後の�潟Iフィスクアトロと密接に関係が深くなるので改めたて詳しく紹介したいと考えている。

XMLパーサーが一年以上の考察の末、ようやく完成の目を見るようになった。
XMLパーサーとは XML の解析ツールのことである。XML とはタグによるデータの構造化表現である。
製造業の人であれば御馴染みの部品構成ファイルを タグで表現したようなものである。

   <?xml  Version="1.0" encoding="Shift_JIS"?>
   <自転車 name=BYC-001X>
      <ハンドル name=HDL0010>
         <ハンドル本体>HDL0011</ハンドル本体>
         <グリップ 数量=2>GRP0025</グリップ>
      </ハンドル>
      <フレーム>FRM0850</フレーム>
      <車輪 セット name=WH000>
         <前輪>FRT1011</前輪>
         <後輪>BCK2011</後輪>
      </車輪 セット>
   </自転車>

これは XML の基本的な表現であるが、ここから派生して XSL や XSLT, DTD 等のようなXML の種類もあるが
基本的には 「データの構造化表現」であることには間違いない。
XML をプログラムによって処理するときの手法は一般に DOM (Document Object Model) = 文書化モデルと
呼ばれるツリー構造のメモリーに入れたものに、取り出すための関数やメソッドが用意されているので
それを使って XML の値を取り出すことが一般的である。
XMLパーサーでボピュラーであるのは Misrosoft が IE で提供している XMLパーサーでありJavaScript で
XML を自由に扱うことができる。
Ajax の場合、System i の CGI で XML を生成してクライアントの IE に渡せばIE で JavaScript を使って
XML の値を取り出して HTML に埋め込むというようにして一般的に使用されている。
ところがここにきてサーバー・サイドでも XML を解析する必要が出てきた。それは

Webサービス とは WSDL という XML で書かれた通信記述から送信用の XML であるSOAP という XML を生成し、
受け取るデータも、やはり SOAP という XML によって受け取るのである。
そこで何故、今 Webサービス に注目しているのかというと

1. 企業間のデータ交換は Webサービス による XML となる。

2. Webサービスでは通信の知識やテクニックを必要としない。

3. 社内も含めて世界中のビジネス・ロジックを再利用することができる。

4. 言語の障壁がなくなる。

企業間のデータ交換はWebサービスによる XML が主流になるのは数年を要するとしても今まで通信というと
苦手な人も多かったと思うが Webサービス であれば全く通信を意識する必要はない。
RPG であればただのプロシージャー呼び出しだけであり、Java であればただのクラスをひとつ呼び出すだけの
プログラムとなるだけであり通信の記述はどこにも記述する必要がないのである。

さらに IBM System i ユーザーは既に大量のソフトウェア資産を抱えているがビジネス・ロジックの最小単位である
プロシージャーをWebサービスによって公開するだけでオブジェクト・ベースでの再利用が可能となる。
つまり既にバグがないとわかったいる社内品質に優れたビジネス・ロジックをオブジェクト・ベースで組み合わせる
だけで新たなアプリケーションを生成することができるようになるのである。
これは何を意味しているのかというと、まさしく

である。
SOA のベースとなるのが Webサービスである。
さらに プログラムは Webサービスを通じて繋がっているのであるから、そこには言語の障壁がなくなるのである。
RPG で開発したプロシージャーは Webサービスによって SOA となり、Java のクラスとして扱うことができる。
逆に Java のクラスはWebサービスによって RPG のプロシージャーになるのである。
近年、RPG プログラマーの数は減ってきて Java のプログラマーが増えて

この RPG 0.03 % は容易に減ることはないと思われるが今後は System i を利用していてもJava プログラマーを
無視することはできない。
既にある RPG のソフトウェア資産を Java で利用したりオープン・ソースの Java をRPG のプロシージャーとして
利用できるとすれば世界が広がる素晴らしいことではないだろうか ?
Webサービスは、このようにソフトウェアの世界を一変させるほどの力を秘めているのである。
通信だけではなく SOA も開発言語の障壁もなくしてしまうのである。

となると、System i サーバー内で WSDL からの SOAP の切り出しを始めとして XML の解析技術が非常に重要な
基礎技術となってくるのである。

ところで XMLの話に戻って XML とは「データの構造化表現」であると既に説明した。
弊社が開発した XML を解析する DOM = 文書化モデルは XML をただの複数のキーを持つデータ・ベースに
置き換えただけである。
非常にシンプルはこのデータ・ベースは RPGプログラマーであれば SETLL & READ, CHAIN 等によってごく簡単に
扱うことができるようになっている。
DOM という名前の単なるキーつきのデータ・ベース(物理ファイル) を RPGプログラマーが保守すれば、弊社で用意した「XMLアセンブラー」で元の XML に組み立て直すことができる。
ただのキーつくのデータ・ベースであればRPGプログラマーであれば誰だって自由に読めるし更新することもできる。

オープン・ソースとして有名な gSOAP や soapUI は莫大すぎてソースの解析や System i への
Porting も、ままならない。
System i では IBM が V5R4M0 から PTF として XML_INTO という RPG命令コードを追加したが一本で
約 20MB という巨大なサービス・プログラムである。
OS Ver7.1 では XML への対応が強化されるとの話があるが恐らく XML_INTO が標準装備されるに
留まるのではないかと予想している。
また米国雑誌 System i News マガジンの執筆者で有名な Scott Klement 氏は C/400 で莫大な XMLパーサーを
作成してオープンしているが WSDL を解析する別のツールとして発表したのはこれまた巨大な RPG だけによる
XML 解析である。

( Scott Klement 氏は System i を多角度から解析するのに非常に優れた才能の持ち主であり、
同誌の執筆者の中でも群を抜いている。自分のサイトでも多くの素晴らしいツールを公開している。)

なぜ自分の開発した XMLパーサーを使わなかったのは不思議であるが、いずれも XML を直接メモリ内で
これまでのオープン系で行われていた手法をそのまま 持ち込んだに過ぎない。
IBM System i にはキーつきのデータ・ベースという非常にシンプルで強力な武器があるのである。
これを利用しない手はない。
ただし筆者もこれに気づくのに一年を要した。
気づいてしまえば非常にシンプルで簡単なことであるが考察するだけに準備の時間を十分とったことは
値打ちがあったと考えている。
XMLパーサーは現在、弊社のSystem i 上で非常に快適に動作を始めている。
現在、弊社には多くの大規模システムの再構築の相談が舞い込んできている。
SOA が必要とされる時代が確実にそこまでやってきているのである。
Webサービスをユーザーにお届けできる日は、そう遠くない。

EnterpriseServer は発表以来 ８年目の成熟期を迎えることになり、この春には Ver6.0 をリリースする
予定である。
その間、リエンジニアリングを幾度が繰り返し、Ver5.1 では品質の安定とともに高度な機能追加が数多く行われた。
特に Ver5.1 での技術進歩は目覚しく、次々とユーザーの希望を実現してきた。
( というよりユーザーの要望の実現に追われてきた、と言うほうが正しいのかも知れない)

今年はまた クラウド・コンピューティング や Webサービス が年の後半には話題の中心となるであろう。
System i のユーザーがいきなり基幹業務をクラウドに利用するとは思えないが Webサービスを基盤とする
SOA の普及はこれまでの開発手法を大きく変えることになる。
弊社も Webサービスを技術基盤とする研究開発は進んでおり今年中には何らかの発表を行いたいと考えている。

ところで弊社には 「２社以上のユーザー要求があれば必ず機能追加する」 という不問律があり、
とりわけ重要と思われものにはたとえ一社からの希望であっても製品に機能を追加してきた。
さらには品質の安定と充実により Ver5.1 最終版ではこれ以上のマイナーチェンジすら必要ないのではないかと
見えたのだが、Ver6.0 では、

をテーマとしている。 機能的に充実できた今日、もはや「ここが素晴らしい」と強調を繰り返すのではなくユーザーに「楽しく使って」もらいたいと希望している。
「使って楽しい !」と感じてもらえるには

などの裏返しでもある。
「使って楽しい !」とはイメージ的に思えるがそれを実現する十分な合理的な技術的背景が必要である。
Ver6.0 ではオペーレーションを仮想デスクトップ上のショートカットアイコンから操作が始まる。
またユーザーよるショートカットアイコンの作成や仮想デスクトップの作成を行うことができる。
EnterpriseServer の開発はもちろん、操作も Web上の仮想デスクトップですべて行うのである。
つまり、これはシンクライアント化への発想でもあり、プラットフォームはサーバーではなく
Webがプラットフォームであるというオライリーの提唱する Web2.0 を製品自身に推し進めた結果でもある。
これはWebサービスを基盤とするクラウドにも通じるものでもある。
ユーザーは ビジュアルなショートカットアイコンをクリックして開発や操作を行うことができる。
しかも自分の好みにアイコンを作成したり、配置し直したりすることもできる。
またユーザー自身の工夫によって CGI を作成することなく簡単なユーティリティーを作成して
アイコンを配置することもできる。
まさしく Windows のような世界が Webインターフェース上で展開されるのである。
開発のプラットフォームはブラウザなのであり、つまり Ver6.0 では EnterpriseServer 製品そのものが
Web化されているのである。言ってしまえば、

ということになる。
世の中に Web化ツールと称するものは数多くあるが、ほとんどの製品は製品自体がWeb化されていない。
5250エミュレータ上で操作するようにできている。
これはおかしな話であり Web化ツールこそが真っ先にWeb化されているべきであろう。
原因はひとつで開発メーカーに技術力が足りないだけである。
ともあれ快適に開発できて使っていて楽しくなるように製品を私達は目指している。
Ver6.0 を操作するには大して説明はいらない。
見ればわかる。使ってみたい気になる。
ユーザーが希望を出して作り上げてきた製品に楽しさと将来展望を入れて仕上げたのが Ver6.0 である。

Ver6.0 を「使って楽しい !」と感じてもらえることを真に願っている。

as400-net.com で一般の System i をプラットフォームとするソリューションの登録の公募を行うことにした。
これは IBM ユーザーが業務の効率化や TCO 削減のために積極的にソリューションを活用して頂くための
試みである。

よく ○○サイトでは商用を禁ずる、というものが多いが as400-net.com では意図的に商用を禁じていた
わけではなくオリンピックでもスポンサーなしでは運営できない時代にあって商用を禁じるのはユーザーの知りたい情報に制約を加えてしまうことになる。
そういう意味もあって一切の制限は行わないのが今回のソリューション公募である。
ソリューションだけでなくソフトウェア開発会社や特約店のアピールを行って頂いてもよい。
もちろん弊社の競合相手であっても何ら問題はないし、排除する意図は全くない。
ユーザーの知りえる情報を偏りのあるものにしてはならないのである。
競合他社からの登録はむしろ歓迎である。

さて、ソリューションという語源は問題解決のための製品という意味であるが従前は海外からの輸入品ソフトが
大勢を占めており、IBM ユーザーも「ソリューション = 海外輸入ソフトウェア」というイメージを持たれている
ようである。
しかし、ここにきてようやく国内のソフトウェア・ハウスによる国内製品としてのソリューションが少しずつ目につくようになってきた。 海外製品の場合、漢字が十分に考慮されていない場合もかつてはあった。

地球は日に日に狭くなってきており北欧で開発されたソフトウェアが英国でヒットしてやがては米国に進出したり
オーストラリアやカナダでも新しいソフトウェアが発表された時代もあった。
現在、米国発のソフトウェアが多いのだがわが日本発も頑張っていろいろと数多く発表されるようになってきた。
現在、日本に輸入はされていないが米国で販売されているソフトウェアにも種類が多い。

Web化ツールに限っていえば米国発のソフトウェアも、もう少しアイデアが欲しいと感じている。
JSP や PHP のように HTML の中に RPG をスクリプトとして埋め込んだものもある。
最初は少し面白いと思ったが、これではインターフェースとビジネス・ロジックの分離ができない。
２番煎じではダメなのである。

一方、国産で弊社の競合相手のひとつかも知れない製品に、なるほどと思わせる製品もある。
残念ながらよいアイデアながら製品として実用レベルまでは成熟していないのでシェアは少ないようである。
IBM ユーザーが期待と驚きを持って迎えてくれる製品が数多く生み出されることを期待してやまない。
もちろん優れた製品であれば海外からの輸入品も大歓迎である。

EnterpriseServer Ver5.1 は、そのリリース中でも今、加速度的に急激な成長を為している。
eStudio を中心とする機能の拡張や追加は日々に行われて目覚しい勢いで急激な成長を遂げている。
ユーザーの目に見える範囲ではフロント・エンドの JavaScript による機能追加が猛烈な勢いで行われており、
過去の技術力の蓄積のおかげで不可能に思われてきた機能の実装がわずか一日で為しえることさえある。
ここでは派手な機能追加だけでなく、内部での緻密で地味な作業ではあるが確実に
ユーザーにとって利益となるパフォーマンス改善の様子を紹介しよう。

10/21(火) からの 札幌 iSUC を前に EnterpriseServer のエンジンから細部に至るまでの徹底した
パフォーマンス・チューニングを行った。
Ver4.0 では HTTPサーバー Alaska をIBM が推薦する、メッセージ配布形式のサーバーにリエンジニアリングすることによって、それまでの約２倍の速度向上を図ることができたが今回の Ver5.1 内での 改訂では、発表直後の Ver5.1 に比べて最大、約 ４倍以上に速度を向上させることに成功した。
EnterpriseServer の主要なモジュール部分は ANSI-C言語で開発されているがRPG に比べてかなり速く動作する
C言語であっても、マシンインターフェース( MI ) レベルまでの動作を考慮することによって、

のような対策を EBCDIC/ASCII 変換や Alaska の HTTPプロトコル解析まで、あらゆるロジックを検討して無駄を
徹底的に排除するとともに、マシン・レベルで繰り返されていると思われる命令の実行を廃止するよう心がけた。
C言語は速いものであるという安心感を捨てて徹底的な合理化が図られたのである。
この結果として レポート形式の表示だけでなく AutoWeb や TONAKAI/2.0 はもちろんのこと従来の ILE-RPG や
RPG# による CGI や eStudio の動作までが、驚くほど高速で動作するようになった。
弊社の OS Ver6.1 (CPW = 4300 ) は当然であるが、OS V5R4M0 (CPW = 500 ) でさえも5250エミュレータと思える
速度で、超高速で軽々と動作している。
従来であっても EnterpriseServer は他社製品よりは、圧倒的に速く、その評価は高かったが今回の
パフォーマンス・チューニングによって恐らく他社製品の10倍以上 の高速動作は楽に見込める
のではないかと思う。
ベンチマーク・テストのツールは既に社内で開発されているのでベンチマーク・テストの結果を今後、
Webでも公開していこうと思う。

これは弊社社内の合言葉であり、今後も変わることはない。

eStudio 上での Wizard生成ではデータ・ベースを指定するだけでCGI+HTMLのセットを自動生成することができた。
この Wizard 生成機能に CHAIN 命令によるファイル結合ができないのか?という質問がこれまでに多くあり、
最近になって CHAIN命令によるファイル結合機能を追加した。

別のユーザーにデモをすると「こんなにも簡単に新規Webアプリが生成できるとは?」と驚きの声が聞かれた。
マウス操作だけで ファイル仕様書、キー・リストやCHAIN命令の演算命令まで組み込まれるのであるから、
最初の使用前の不安が一掃されたのであろう。

ところで別のユーザーではサンプルの画面を表示するとあるフィールドを指摘して「チェック・ボックスにして欲しい」
との要望があった。 そこでユーザー自身がフィールドに指定を行うだけで GUIコントロールを自由に設定できるようにした機能が「コントロール・ウィザード」である。
コントロール・ウィザードは、新規生成Wizard の途中でフィールド単位でボタンを押すだけで次のように
コントロール・ウィザードのダイアログが表示されてラジオ・ボタンやコンボボックス, ... 等の GUI コントロールに
変更することができる機能である。

プログラマーは GUI コントロールを HTML でどのように記述すればよいか等の知識は全く必要でなくなる。
GUI コントロールのソースは、その場で表示することもできるが、Web開発が初めての人にとっては開発効率は始めから向上することになる。
また画面を生成した後からでもコントロール・ウィザードを起動することができる。
eStudio でプロジェクトを再オープンして、フィールドの辺りにマウス・ポインターを位置づけてタブル・クリックするだけで、そのフィールドの GUI コントロールをコントロール・ウィザードによって表示して変更することができる。
たとえばラジオ・ボタンとして定義していたフィールドをコンボボックスに変更することもできる。
次のHTMLは全く、人手による HTMLソースの修正を行わずにコントロール・ウィザードによってGUI コントロールを
配置した例である。

従来、HTMLソースの修正はユーザーまかせであり、これはどのような他社製品でも同じである。
ある他社製品では市販の HTMLデザイン・ツールによって HTML に GUI コントロールを配置してから各GUIコントロールに ID を割り振って、それから CGI とのインターフェースを作成するというものである。
市販の HTMLデザイン・ツールは高価であり使うには結構、経験と訓練を必要とする。
実際、このデモを見た多くのユーザーが複雑さを訴えている声を耳にする。
EnterpriseServer であれば Wizard 生成でわずか数分でこれらの作業は終わってしまう。
しかも コントロール・ウィザードの実装によって自由に GUIコントロールを生成することもできるようになったのは
開発効率の著しい進歩となった。

Webの世界では Web2.0 から次の大きな波である「Webサービス」がやってきている。
インターネットでは静的な HTML の公開としてのホーム・ページ作成は終わり、今、現在の国内の
System i のユーザーでは 少しは Web化は普及しつつあるがまだ十分とは言えない。
そんな中で次にやってくるのが Webサービスである。
Web化とは CGI や Servlet 等によってデータを公開することであったが Webサービスとはビジネス・ロジックの
公開である。簡単に言うとインターネット(正確には HTTPプロトコル) 上で SOAP というプロトコルによって
プログラム同士が通信する技術のことである。
プログラム同士が通信するということであれば、これまでも CORBA, DCOMM, ... に代表されるようにサーバーを経由してプログラム同士が通信する技術は既に存在していた。
これらの技術に対して Webサービスとは SOAP という XML 記述によってプラットフォームに依存しないオープンな
通信を行うものである。
SOAP プロトコルとは WSDL という XML による通信仕様をプログラムが解析してHTTP経由で通信を行うというものである。

Webサービスでは相手のプログラムがどのような開発言語で書かれているのか、またはどのような OS を
プラットフォームにしているのかは一切、関知しない。
通信の規格が SOAP という全世界共通の規格であるだけである。
RPG のプログラマーが別の外国にでもあるかも知れない、あるいは Java か COBOL なのか不明な言語のプログラムを Webサービスを使って呼び出すときには、特別な記述は必要ではない。
ただ、RPG と同じように Webサービスのプロシージャーを呼び出すだけである。
ここが素晴らしいところであって Webサービスということで特別な API やコンパイルも必要ないのである。
いつものようにバインドしてコンパイルするだけで全世界のどのようなプログラムでもあなたが直ちに呼び出すことが
できる。注文データを送ることもできるし、社内には存在しない高度なプログラムも無料で利用することができる。
これまでのコンピュータの処理を考えて欲しい。コンピュータで社内処理をして合理化していたとは言え、社外との
処理は、どうしても人手を必要としていたはずである。
EDI で注文データを処理したとしてもアップロード処理や売上の入力も人手に頼っていたはずである。
Webサービスは非常に簡単に社外との取引き先との通信を簡単なものにして、無人化を図ることができる。
しかもインターネット経由であるので通信料は発生しない。
あたなの会社の製品と価格を Webサービスで全世界に公開すれば多くの新規の取引き先からの引き合いが、
しかも相手のソフトウェアによって行われるのである。
Webサービスが進めば社内の人件費は大幅に削減される。

Webサービスは何も社外との関係だけではない。
社内に莫大に眠っているかも知れないソフトウェア資産をプロシージャー化して切り出して SOAP によって公開するようにすればオブジェクト・ベースでの再利用が非常に簡単になり、新規開発のコストと手間は大幅に低減する。
しかもオブジェクト指向であるわけだから信頼性は高い。
社内の別のWindowsサーバー等のプログラムとの通信も簡単である。
すべての社内サーバーのソフトウェアを統合化することができる。
しかもあなたは、利用するプロシージャーがどのサーバーにあるかなどの構造を一切気にする必要はない。利用するプロシージャーがどのサーバーにあるかは漫然としていて気にする必要もない。
つまり漠然としたソフトウェアの利用方法こそが、今話題の

こうしてくると SOA や クラウド・コンピューティング のベースを支えている技術ことがWebサービスであることがおわかりだろうか ?
クラウド・コンピューティングが進んでくると世界中にコンピュータは 5台もあれば十分である、という話さえある。
最近の NHK ニュースでは超軽量のモバイルPC が普及しつつある背景にはソフトウェアはWeb経由で利用すればよく、自分のPCに大容量の HDD を持つ必要がないからである、との報道があった。
Webサービスは、ご自分の会社にはまだ必要ないと思われていても、必ず海外や取引先からはWebサービスがあなたの会社にも要求される時代はすぐそこにまでやってきている。
IBM も今、最も力を入れているのが SOA であり、クラウド・コンピューティングである。

その技術が Webサービスである。

EnterpriseServer Ver5.1 に搭載予定の｢Autoスプール｣とは弊社製品 Spoolライターのいわば Web版である。
操作はシンプルでツリー構造に表示された印刷待ち行列(OUTQ)を選択してスプールの一覧を表示する。

特定の印刷スプールをクリックすると印刷プレビューが最下部のペインに表示されＷクリックすると印刷スプールは、
その場で PDF化されて表示される。Spoolライターが導入されていれば EnterpriseServer Ver5.1 の eStudio や AutoWeb からAutoスプールを呼び出して利用することができる。
印刷のWeb化をどのようにするかということでよく質問を受ける。Autoスプールはあわゆる印刷業務のWeb化に今すぐ使えて、説明の要らないほどやさしい操作で Webに移行することができるのである。
Spoolライターには元々 印刷スプールを System i だけで Web化することができる｢日本語PDFライター｣としての HPT という API が用意されているのでAutoスプールの開発は弊社社内で、わずか３日という短時間で主要な機能がほぼ完成してしまったのである。
さらに製品としてユーザーに快適な操作を提供するには、パフォーマンスをより良いものに仕上げることで、これもほぼ目処がついている。
弊社製品の一貫して目指していることは、使用するユーザーにとってわかりやすくやさしく操作のできることである。
それを考える時間を惜しむことはない。

ユーザーにとってやさしい製品を提供することは、背景となる技術力に相当なものを要する。 しかし幸いなことにこれまで EnterpriseServer の開発によって培ってきた技術は加速度的に製品の機能アップが日増しに行われており、開発している我々自身が結果に驚くことも珍しくはない。 もちろん競合他社もいることではあるが、より良い製品に仕上げていることは弊社にもお客様にもより良い結果を生むはずである。

私達はこの言葉を信じて製品の機能拡張に努力している。

AS/400 の生みの親と言われるDr.フランク・ソルティスが 2008年12月末を持ってIBM ロチェスター研究所を去ることになったようである。Dr.フランク・ソルティスは仮想化技術で S/38 からのアーキテクチャーを創り上げ、最近では Power5 OS をマルチスレッド化したことでも知られている。 意外と少ないと思われるIBM ロチェスター研究所の4000人の職員にも衝撃が走ったようで地元の新聞にも大きく取り上げられているようである。彼の全世界に貢献した功績は称えて余りあるものと思うが、我々が直接、彼と会うことができたのは日本では iSUC の会場であった。

彼の講演は、アジェンダや PowerPoint による説明資料は一切無く、ただ口頭による説明のみである。しかし話の内容は、極めて整然と論理的としたものであり、同時通訳が全く同じ日本語訳であったのは事前に同時通訳と打ち合わせた内容と寸分たがわない正確なものであったのであろうと容易に想像がつく。IBM は事ある毎に基礎技術の高さを誇りとして強調してきたが、ソフトウェア開発においてソリューションの結果を導き出すのは、まさに基礎技術がいかに重要であるかが筆者も強く認識している。 ユーザーが使いやすくわかりやすいソリューションとするためには、Background のソリューション開発者には、最先端の高度な基礎技術の高さが要求されるからである。

その意味においてもIBM のユーザーが直接、彼の功績を具代的に知ったり認識することはないだろうが、新しくまた永年にわたって色あせることのない、アーキテクチャーの基礎を彼が開発されたことには敬意を表せざるを得ない。 彼が IBM在籍中に最後にお会いしたのは iSUC静岡であった。 朝、ホテルのエレベータに向かう途中で、もしかして? と思ったとおりロビーに降りるとDr.フランク・ソルティスがチェックアウト中であり、思わず挨拶すると微笑んで挨拶を返してくれた。 彼は今後とも System i の世界から離れることはないだろうと自ら語っているようにまた、日本でもお会いできることを切に願っている。 今後の彼の活躍を世界中の IBMユーザーが期待していることであろう。

EnterpriseServer Ver5.1 では RPG# という名前の独自のWeb開発言語を搭載した。RPG# もまた、ILE-RPG ではあるがメイン・ルーチンを持たないイベント駆動型の言語である。
開発言語の進化の過程において、C++ や BASIC がメイン・ルーチンを捨ててイベント駆動型の VC++ や VisualBASIC へと進化したのと、ごく当然の成り行きであった。
Webの世界でも Ajax が普及した HTML画面上の各種の GUI コントロールに対応する機能をサーバー側で記述するとなると、 GUI コントロールのイベントが発生する都度、CGI を呼び出すことになる。
すると、ひとつの HTML画面をサポートする CGI が複数個も必要となってしまい、開発だけでなく管理面からも複雑な体系となってしまう。
今後の Web2.0 の普及を考えると従来型のメイン・ルーチンを持つ、いわゆるフォーターフロー型の RPGのビジネス・ロジックでは、もやは限界であるといえるのだ。
イベント駆動型であれば、イベント毎のプロシージャーを記述するだけで済むのでひとつの CGI にまとめることができるのは当然である。
ボタンを押した云々のイベント動作だけをプロシージャーとして記述するのである。
永年、メイン・ルーチンを記述してきたRPGの開発者にとってはメイン・ルーチンがないとは不安に思うかも知れないが若い入門者にとってはメイン・ルーチンが非常にわかりにくいものとして眼に映っているようである。
しかし今の時代で VisualBASIC ではなく、BASICを記述する人がいるだろうか ?VC++ や C# の代わりに C++ を使う開発者もいない。
Microsoft はイベント駆動型の VisualBASIC や VC++、 C# によって間違いなく成功を収めている。すると GUI 化をサポートして　Web2.0 に対応するためには RPG もイベント駆動型への進化が必要であるのは当然の成り行きである。
そこで

となった。

RPG# はメイン・ルーチンを持たないイベント駆動型のRPG言語である。 イベント処理をプロシージャーとして記述するだけの簡単なものであるが、逆にプロシージャー化によって、将来に向けてのオブジェクトの再利用が非常に簡単にもなり、意識せずともオブジェクト指向モデルの適用業務を開発することができる。 また HTML(ビュー) とメイン・ルーチン(コントロール) とプロシージャー(ビジネス・ロジック)の3つは完全に分離された、いわゆる

が実現されている。

もちろん GUI コントロールのサポートとして各 GUIコントロール個別のプロパティやメソッドを
直接、RPG で扱うことができる。

さらに SPECIAL ファイルの機能を利用して、

のである。これは RPG# の記述を大幅にやさしいものとにしている。

つまり HTMLの完全外部ファイル化である。 編集コードや編集語の HTML に記述するだけだ。 フィールドの長さやタイプ、属性も HTMLとして外部ファイルに記述するのである。 しかも Webソリューションにありがちな HTML上の独自タグの記述をほとんど必要としていない。あるのは SFLレコードに相当する <REPORT ... というタグだけである。

このように RPG# は Web開発を非常にシンプルなものにした。 米国雑誌を見ていると今、RPGの近代化が話題の中心であり、様々な手法が毎月のように紹介されているが、RPG のイベント駆動型への進化が必要であることはまだ気づいている人はいないようである。 RPG が 進化するとすれば RPG# の形になることは間違いない。 僭越ながら筆者は初めて米国を抜いた気がしている。 その点において、いち早く RPG# を開発できたことは幸いであった。 2008年 10月の第19回福岡 iSuc で初めて RPG# を紹介したが反響は予想以上であった。今、現在、東京と大阪にて Ver5.1発表セミナーを予定している。 是非、RPG# を実際にご覧いただければ幸いである。 RPG# はあなたの開発手法を必ず変えることになるであろう。

RPG が発表されて久しいし、RPG はレガシーな開発言語であるかのように言われているが、ある統計によれば，全米のプログラマーのうち、Java の使用率が最も高くプログラマー人口の約 20 % が Java を使用しているとのことである。VisualBASIC の使用率が約 12 % で C や VC++, C# の使用人口が 3 % である。

ところがわが、RPG の使用率は何と 0.02 % と、想像以上に極端に少ないのである。System i の開発者は RPG で、できることは他の言語でもできると思い込んでいるが実は、そうではない。COBOL で CHAIN などはできないし、Java や C 言語でも到底できない。データ・ベースをこれほど便利にアクセスできる言語はざらにはない。SQL系の ODBC, JDBC で DB2/400 をアクセスすることを、System i 上で考えるのはRPG のような高速アクセス言語がありながら、わざわざ時代に逆行していると言わざるを得ない。

さらに RPG は System i 上でのコンパイルは他の言語に比べて圧倒的に速く実行速度も他の言語に比べて圧倒的に速く、サイズも小さくて済む。手馴れた人であれば、一日のうち数本のRPGプログラムを開発することも珍しくはないであろう。 他の言語では考えられないことである。

他のJava などに浮気すると実行時のエラーを探すのに苦労するであろうし、C言語でさえ、エラー行を抽出することはできないのである。信じられないだろうが、これは紛れもない真実である。RPG があまりにもやさしい言語であるため、他の言語も同様であろうとタカをくくって JSP & Servlet などをやりだすととんでもない目にあうかも知れない。

それでは何故、RPG がレガシー、つまり古い言語のイメージがあるのであろうか ? COBOL も含めて、制御をすべてプログラムで上から下へと記述する、いわゆる、 ウォーターフロー型の流れのプログラム・ロジックであるからでは、ないだろうか ? これに対して、オープン系と呼ばれるVisualBASIC, VC++, Java, C# 等は イベント駆動型( Event Driven) と呼ばれるものである。

つまり、ウォーターフローのように上から下へと処理の流れを記述するのではなく、 操作員(エンド・ユーザー) が、何らかの操作を行ったときに発生するイベント (事象) に対する関数(振る舞い) を記述していく手法である。

マウスの左ボタンを押したときは、この関数を実行する ... というようなものである。

さて、ウォーターフロー型には F3キーを押したときには、云々、そうでなければ 云々 .... という処理の判断による分岐が多く発生する。これに対してイベント駆動型は，操作に対応する処理をいわば羅列のように記述していけばよいだけなので全体の処理フローを全く、考慮する必要がない。このことがプログラムがまだ始めたばかりの苦手な人にでも容易に受けいけられるのである。 特に GUI 化を考えると GUIコントロール(入力BOX, コンボボックス，スクロール・バー,ラジオ・ボタン，チェックボックス他) に対する操作は数多くあり、さらにAjax が普及を見た今日では Ajax が呼び出すプログラムを別のモジュールにしておくとひとつの画面を維持するプログラムが多数になってしまい、開発や管理の面まで複雑にしてしまう。

イベント駆動であれば、多数のGUIコントロールを持つ HTML であってもAjax を多用するHTMLであってもひとつのプログラムによって処理することができるようになる。

筆者は過去に紹介したように OS400 ユーティリティーのほとんどはバネル・グループと呼ばれる HTML と同様のタグ言語であり、パネル・グループを維持するプログラムはイベント駆動型として設計されている。 (ただし、ひとつのプログラムではない。) イベント駆動型が今後の方向として重要であるのは、

つまり、プログラム主体からユーザー主体への変革である。

ところでオープン系に戻って考えてみると、オープン系の CGI は決してイベント駆動ではなくレガシーなウォーターフロー型である。 考えて欲しい。CGI, Perl, PHP,... すべてウォーターフロー型である。GUIコントロールを擁するオープン系App は、すべてイベント駆動型であるのにだ ?Ajax を含めて Web適用業務は GUI であると考えるとCGI もイベント駆動型への移行が次の進化の段階として予想される。 ここでようやく本題であるが、それでは RPG で CGI を開発するときに RPG を イベント駆動型として記述することが可能かどうかという問題である。

IBM が開発した言語の流れを根本から変えることになるので、そんなことは不可能か、またはできてもイベント処理だけはメイン・ルーチンに残るだろうと考えるのも無理はない。しかし実は VC++ や VB もモジュールのパインドによって C++ や Basic からイベント駆動言語へ進化したのである。 結論を言えば、

というものである。 ユーザーが作成するRPGソースには、最初に画面を出力したら後はイベントに対する記述を書くだけでよい。これは RPG の入門者にも画期的にコーディングがやさしくなるばかりか、社内保守も一層、やさしくわかりやすいものとなる。 しかもオープン系にもイベント駆動型の CGI は存在してないのであるからRPG が最も進化したWeb開発手法となるであろう。 米国IBM もインタビューに答えて、イベント駆動型の Web開発が今後は必要になるであろうと話していたが、それはストアド・プロシージャーであるという少し観点が異なったものであり、RPG の根本的な改革を示唆しているものではなかった。米国雑誌で最も今、賑わっているのは RPG をどう近代化を進めるかということである。 もし RPG が Web開発でイベント駆動型に変身したら、あなたの Web開発は見やすくわかりやすい展望が開けてくることになることは間違いない。
2008 年、RPG は大きな進化の変貌を遂げる。

下記の HTMLインターフェースをご覧頂きたい。

<クリックで拡大表示>

実は、これは AutoWeb による WebFacing の画面である。 AutoWeb は、HTMLテンプレートを基にして 5250エミュレータ画面を動的に HTML に変換して表示するという EnterpriseServer Ver5.0 の機能である。 AutoWeb は、BASE5250.HTM というHTMLテンプレートを基礎にして HTMLを生成してきた。生成されたHTMLはIFSに保管されてユーザーによるカスタマイズも可能なようにできている。HTML を修正するのではなく DSPF の DDSソースを修正することによってコンボボックスやラジオ・ボタンなどの GUIコントロールも作り出すことができる。

さて上記は BlueGlass (プルー・グラス) という名前の HTMLデザイン・テンプレートから自動的に生成された画面である。 あたかもWebデザイナーが手を加えて修正したかのように見えるのだが、実は一切のカスタマイズも行ってはいないのである。 ここで注目して頂きたいのは、サブ・ファイルの見出し行と明細行が美しくデザインされていることである。考えてみれば 5250ストリームはタダの画面であって、どこにもサブ・ファイルであるというような情報は含まれていない。従って従来の WebFacing では人手による介在がないと、このようなデザインは到底、無理な話であったのだ。

ところが AutoWeb はちがう。このブラウザの最上部にあるタイトル・バーには

受注の入力-MN00CL/PGM201FM(SFCTL01) - QPADEV0009

というようにテキストや実行プログラム，画面ファイル名および表示レコード名までもが表示されている。つまり DSPF情報が AutoWeb よって検索されているのだ。 さらには AutoWeb は、今、表示されている DSPF のオブジェクトそのものが、 どのような構造をしているのかを、直接、オブジェクトを参照して、解析しているのである。しかも高速にである。

しかし、これだけで BlueGlass(ブルー・グラス) が動作したかという単純な話ではない。

の3つが統合されて初めて成しえたものである。これには高度な技術を必要とした。 優秀なスタッフのおかげであると感謝しつつ、BlueGlass (ブルー・グラス) が踏み出した一歩は意味のある非常に大きなものであると考えている。 それは WebFacing は簡単なものとして見栄えの良いデザインを望むとは難しかった長い歴史がある。

手間をかけずに様々な多くのデザイン・パターンができるのであれば高度な拡張可能な WebFacing に勝るソリューションはないからである。BlueGlass (ブルー・グラス) の登場によって Web開発は決定的なものが生まれたものと思う。

BlueGlass は、WebFacing の歴史をまちがいなく変えるものである。

EnterpriseServer Ver5.0 では DDSで拡張可能な WebFacing として「AutoWeb」を搭載した。 これまで EnterpriseServer は WebFacing では画面拡張することができないとしてどちらかと言えば反対の立場をとってきた。 おおよそ Web化の目的とは、

などであった。開発者の立場でも、これらのWeb化を実現するにしても

つまりは簡単にWeb化できても拡張性のあるWeb化でありたいという、 望みの高いものであった。 よく Web化された基幹業務パッケージの紹介セミナーで必ず出る質問が、「コンボ・ボックスは使用できないのか? 」というものであり、講師の回答は「これはWebFacing であるのでできません。」と言うものである。 確かに WebFacing では元の業務の画面に手を入れる必要はないし、最も手軽に誰でもができる Web化である。しかしコンボボクッスを初めとする GUIコントロールがないばかりか、フィールドを追加することができないのでは情報量の拡大にはほど遠いものであり早晩あなたのユーザーから不満の声が出ることは明らかである。

もうひとつのWeb化(GUI化?) として一時期にリッチクライアントやクライアント・サーバー・モデルが一世を風靡した時代があった。中には独自の言語を使用して講習会に出席して学習する必要のあるものも現存している。 しかしインターフェースが HTML ではなく、独自のインターフェースを持つものは 拡張性に乏しく時代において行かれることにもなりかねない。 例えば最近の Web2.0 Ajax の技術を適用できないのでは時代遅れになるかも知れないのである。最後には結局、再投資が必要となってしまう。 ただしリッチ・クライアントが人気を博したのは、そのパフォーマンスの良さである。 しかし、これも Ajax の登場によって HTML でリッチクライアントが実現できてしまう現在となっては、リッチクライアントの配布の手間だけが残ってしまうことになった。

ところで WebFacing に戻って、もし WebFacing であっても容易に情報量を拡張したり、容易に GUI コントロールを追加することができのであれば、どうだろうか ? 小職が WebFacing に対して否定的であったのは、拡張性の無さであった。 これでは Web化の根本的な解決にはならない。 そこで EnterpriseServer Ver3.0 では TONAKAI という名前の移行スィートでDSPF を HTML に変換するようにした。 ところがユーザーの多くの作業を眺めていると Web化の 90% 以上は、5250画面をそのままでWeb化しようとする場合が多いのには驚いた。 また残念なことに、ホンのわずかな移行であってもできない開発者が多いのにも驚いた。DSPF の処理は適当に記述しても何とか動作してしまうので開発者は DSPF をほとんど理解しないままに記述している場合がかなり多いのである。

さて Web2.0 Ajax の登場によって HTML の動作は格段に進歩した。 System i の開発者はご存知ない方も多いが、実は DDS記述には HTMLキーワードが既にV3R2M0 から IBM によって提供されているのである。 そこで EnterpriseServer Ver5.0 では DDS 記述によって拡張可能な WebFacing として「AutoWeb」を搭載したのである。 AutoWeb は WebFacing というよりは単に DDS によって HTMLインターフェースの適用業務を開発することができる機能と考えてよいだろう。 簡単に言うがソリューションを提供する業界にとっては、このことは相当、技術力を 要するのである。単にインターフェースが HTML になっただけではなく、Web上であっても従来どおりに端末名等のSystem i の環境までも再現しなければならないからである。もちろん「戻るボタン」や「Ｘボタン」を押しても何の問題もなく動作を保証しなければならない。ステータス・メッセージや突然送られてくるBREAKメッセージへも対応が必要であるのである。当然のこととして入力文字の妥当性検査や FieldExitキー、Tabキーも再現する必要がある。CALL 命令によるPOPUPウィンドウも、そのままで再現される必要がある。 ザッと書いただけでもこのように問題があるのだが多くのソリューションでは、これらは解決されておらず、System i のユーザーに伏せたままで紹介されているのが実情である。それでも売れているとなると羨ましい限りであるが弊社のユーザーでは、そうも行かず厳しい追及を受けることになってしまう。

EnterpriseServer Ver5.0 の AutoWeb は「導入したその日からWeb化」が「売り」である。これは提供側にとってかなり厳しい難題であるが、ユーザーにとっては工数を少なく、誰でもが容易に Web化できるツールとなっている。 これまでの単なる WebFacing とは違い、販売する営業も「非常にインパクトのある製品」と評価してくれた。 しかし本当の最後の評価を下すのは、そのユーザーである。

諸兄は、Web2.0 という名前くらいは聞いたことがあるだろうか ?
ラクダ本でお馴染みのオライリーが彼の会社の会議中に提唱した、これからの Web基本機能のことであり、公的機関による明確な規格があるわけではない。
オライリーが提唱している Web2.0 を満足する Webサイトとは、

が、条件として挙げられているが、この中で具体的な技術として述べられているのが 最後の「7.リッチで軽いこと」があるが、それを具現化する技術として脚光を浴びているのが「Ajax」( = Asynchronous JavaScript + XML : JavaScript と XMLによる非同期通信)である。

Ajax (エージャックス) は Google の地図情報検索で世界中の注目を集めた。 そのあたりは市販の書籍にイヤというほど紹介されているので参考にして頂きたい。 Ajax と Systemi5 ユーザーとの関わりや解説は、情報誌「アイマガジン」で筆者が記事として投稿しているので、そちらをお読み頂きたいが、カンタンに Ajax は何かというと

といえる。 読者は、毎日、Webサイトを見ていて、ボタンを押したり、リンク先に飛ぶとブラウザの画面は一瞬ではあるが消滅して、しばらくしてから次の画面が表示されるのを経験しているだろう。これは GET または POST と呼ばれる投入メソッドによってサーバーへ HTTP要求を投入しているので、画面が消滅するのは仕様であり、仕方のないことである。 しかし、サブファイル画面でロールアップを要求してもデータだけが送られてくるのではなく次の画面全体が送られてくる。データ部分は全体のごくわずかな部分でしかないのに、毎回、大量の画面全体が送られてくることになるのである。 このような非合理な処理に対して Ajax を使えば、データ部分だけを取り出すことができる。さらに Ajax を使えば、データ部分以外の HTMLフレームは、すべてローカルPC にキャッシュさせることができる。それによってブラウザと Webサーバーのあいだを行交うのは単なる XML だけとなり、パフォーマンスは素晴らしいものに改善されるだろう ! 残念ながら市販書籍では、Ajax のこの本質に触れられていることがほんどない。しかし大量のデータ・ベースを扱う i5 のユーザーにとって、このことこそが Ajax の本質である。データ・ベースと HTML フレームとは完全に分離させることができる。 また Ajax はイベント駆動型の Webアプリケーションの開発を容易にする。

このようにして Ajax は筆者が永年、パフォーマンスを挙げ、MVCモデルを模索していた中での解決を見出してくれることと思う。 驚くほどのパフォーマンスと堅牢さ、保守の容易さはスケーラビリティにも繋がる。 まさしく i5ユーザーにとって理想的なアーキテクチャーの出現と言えるだろう。

しかし、筆者が注目しているのは。これだけではない。もうひとつ見ていた夢がある。 それは Systemi5 そのものを根本から Web化(GUI化) することである。 クライアント・サーバー・モデルに始まって PASE 環境や Java, eclipse の利用等も検討はしたが、いずれも決定打には欠いていた。 一方、i5/OS のインターフェースのほとんどはコマンドも含めて、実はパネル・グループ(*PNLGRP) と 呼ばれるタグ言語で書かれている。 これは同じタグ言語である、HTML と非常に良く似ている。 しかもパネル・グループはオプション選択によって該当するオブジェクトPGM が起動されるというイベント駆動型の構造をしている。 HTML をイベント駆動型の操作をサポートするのは、まさしく Ajax である。 OS400 コマンドも実はパネル・グループと同じ表示形式である。

筆者は今、任意の OS400コマンドのソースも取り出して HTML 化することにも成功した。WRKOUTQ. WRKACTJOB などのパネル・グループも現在、HTML化を進めている。これからの Web化は、「Web化」という作業を行うのではなく、「導入」しただけで既に Web化されているようにならなければならないのだ。 もちろん EnterpriseServer も Webとしての操作となり、ユーザー画面も導入と同時に Webからただちに使用することができるように、ならなければならない。 たとえあなたが導入しただけで、何の手を加えていないのであってもだ。 説明が必要であってはならないのだ。

Ajax はまちがいなく私達の世界を変える。 今年の終わりには、Web2.0 すなわち Ajax を搭載していないWeb製品は、淘汰されてしまうくらい Ajax は必須機能となるだろう !

EnterpriseServer もユーザーの要望によって SSL によるセキュアな通信をサポートすることに成功した。System i5では SSLは OS400 V4R3M0 から SSL APIが公開され、V5R1M0 からはGSKIT も公開されて、ユーザー自身による SSL通信の開発が可能となっている。 SSL通信の機能自体は ALASKA にもずいぶん以前から組み込んでいたのだが、認証作業が複雑で難しいために長いあいだ保留としてきたのである。 しかしここにきてユーザーからの強い要望に押されて、また時代背景からもみてセキュアな通信の確立は当然のことと思われるようになってきた。

そこで SSL認証を行う方法であるが、公開インターネット上での有償の証明書ではなく、イントラネットで SSLを使用するだけであればOS400付属の 「ディジタル証明書マネージャー」 を使用するだけで SSL通信を確立することができる。 ところがこの 「ディジタル証明書マネージャー 」(通称 DCM ) の設定が非常に厄介なものであった。SSL通信環境のセットアップは概ね、以下の手順によって行う。

という手順であるが、これがスンナリとは動作しない。

まず最初に V5R4M0 であっても HTTPサーバー *ADMIN の起動ができない。 過去のリリースを見ても弊社の iSeries/i5 では V5R1M0, V5R2M0 ともに *ADMIN は起動することができなかった。 V5R4M0 でも導入直後の System i5 では、まず動作しないであろう。 最新PTF を適用すると余計に動作しない場合さえある。 弊社では V5R1M0 と V5R2M0 での *ADMIN の起動はあきらめている。 製品としてリリースしていて導入直後に動作しないとは・・・。

次にディジタル証明書マネージャー でも結構バグがあり、登録したばかりのパスワードが簡単に使用不可となってしまうので、パスワードの再作成を繰り返し行う作業が発生してしまう。この作業に一週間以上も費やしてしまった。

それではユーザー・プログラムも正しい、証明書も割り付けただけで SSL通信は行えるかというと、そうではない。SSL の実行環境のユーザー・プロフィールに実は *ALLOBJ 権限が必要となるのである。このことはどこにも解説されていなかった。 ところが IBM HTTPサーバーが実行するユーザー QTMHHTTP には *ALLOBJ 権限はないのである。 このことを示すエラーメッセージも出ないので発見するのには大変苦労した。果たして IBM HTTPサーバーが SSL通信で動作するのは遺憾ながら甚だ疑問である。

EnterpriseServer では幸いなことに SSL通信はサポートすることができたが、IBM HTTPサーバー上で SSL通信を行っている例は国内であるのだろうか ? 現存するのであればご容赦願いたいが小職の経験では、かなり難しいのではないかと推測している。

ファイル仕様書の装置名には、WORKSTN, DISK, PRINERR などと記述するが SPECIALという装置名があるのをご存知であろうか?

例えば

FSMP006FM CF  E                   WORKSTN

の代わりに

FSMP006FM CF  E                   SPECIAL PGMNAME(HTMLFILE)
                                            PLIST(HTML)

のように記述するのである。

SPECIAL ファイルの説明の前に、米国のある BSS (掲示板) で興味ある書き込みをある日、見つけた。ある投稿者は

という趣旨であった。別の投稿者が

また別の投稿者は

しかし1年前の投稿であるので既にリンクは切れていて筆者は慌てて投稿したが応答は無かった。しかし SPECIAL ファイルのサンプル・ソースを Web で調べていくと SPECIAL ファイルでも外部記述を使用できることがわかってきた。 これは筆者を大いに勇気づけた。

元の話に戻って SPECIAL ファイルとは簡単に言うとユーザー定義のファイルのことである。つまり、SPECAILとして定義されたファイルに READ/WRITE 命令が実行されると OS400 がPGMNAME として定義されたユーザー作成のプログラムを呼び出して実行するのである。 ユーザーが適切に呼出しプログラムをあらかじめ作成しておくと、どのようなインターフェースもユーザー自身で開発することができるような仕組みが IBMによってされているのである。 上記の例では DSPF: SMP006FM のあるレコード: DSPDTA に対して

WRITE DSPDTA

という命令が実行されたとすると、ユーザー・プログラム HTMLFILE にはレコード：DSPDTAのバッファーが HTMLFILE にパラメータとして渡される。 そこでプログラム HTMLFILE は DSPDTA に含まれるフィールドとなどに関する情報を オブジェクト: SMP006FM を読んで解析しなければならない。 DSPF: SMP006FM を解析する API は IBM によって提供されているが、このファイル解析 API は莫大な構造を持っていて ANSI-C言語の、しかもポインターをアチラからコチラへとぶんまわす精緻な解析処理が必要となった。 しかし複雑怪奇な解析のテクニックさえマスターしてしまえば DSPF のどのような情報でも取得できることができるので、これまでの技術では不可能と思われてきたカーソル位置の取得でさえも行えるようになった。 つまり SPECIAL ファイルを利用することによって RPG-CGI 開発ユーザーが CGI の開発が簡単になるだけでなく、機能そのものも大幅にアップすることが可能になったのである。 さらに SPECIAL ファイルの導入によって CGI の開発は ILE-RPG だけでなく RPG III でも行えるようになったのである。 ( 日本国内の RPG開発者は意外にも RPG III による CGI 開発を希望しているユーザーが多いのである。)

それでは DSPF を SPECIAL ファイルとして使用するのであれば 24 * 80 の制限はついて回るのであろうか? 答えは否である。ILE-RPG であれば追加のプロシージャーさえ記述すれば HTML をどのようにでも拡張することができる。さらに DSPFオブジェクトの解析技術によって将来は DSPF オブジェクトであっても修正できる目処はついている。

このように SPECIAL ファイルを眺めていくと SPECIAL ファイルによる拡張性は無限の可能性を秘めているといっても過言ではない。

HTML を相手にしても SPECIAL ファイルによって HTML もただのファイルとして扱うことができるようになったのである。これこそが筆者が長年、RPG による Web開発の切り札として求め続けていたものである。 SPECIAL ファイル、それはあなたの可能性を広げてくれる素晴らしい技術である。

ある書籍の冒頭には World Wide Web (WWW) とは、ひと言で表現すると 「世界最大のクライアント／サーバー・モデルである」と解説されていた。 これは成る程と思われると同時にこの表現は、まさに的を得た的確なものである。 それでは、クライアント／サーバー・モデルであるからには通信が継続していることが最も理想的で望ましいものである。 HTTP/1.1 規格ではブラウザが「Keep-Alive」というメッセージを HTTPサーバーにリクエストしてなるべく通信が持続されるように望む仕様となっている。

IIS や Apache などを始めとして多くの HTTPサーバーはこれに従って HTMLなどの静的なコンテンツを戻すのであれば通信を継続するように設計されている。 ところが CGI や JSP & Servlet の結果は標準出力をリダイレクトするために結果のコンテンツの長さが不明となって Content-Length を戻すことができない。 そこで Connection: close をブラウザに送って CGI などの結果を出力後には直ちに通信を切断してしまうのである。 iSeries に搭載されている IBM HTTPサーバーでは HTTP/1.1 OK をレスポンス・ヘッダーに戻しているにもかかわらず静的な HTMLのリクエストであっても毎回、Connection: close で回線を切断していまう。 これは HTTP/1.0 の仕様のままである。

よって CGI や JSP & Servlet を呼び出す度に、接続と切断が毎回繰り返されるのである。このことは「WWW とは世界最大のクライアント／サーバー・モデルである」にしてはかなり無駄なことを繰り返していると思われないだろうか？ これは CGI の出力が標準出力(Stdout) をリダイレクトしていることに起因しているのであり、出発点にかなり問題があったことになる。

これらに比べて EnterpriseServer では独自の出力方法を採用しており CGI の出力はひとつの動的なバッファーに収められている。従ってその長さは容易に取得することができて、 Content-Length も戻すことができる。 このことを利用して EnterpriseServer Ver4.0 では、ブラウザとの通信はユーザーがブラウザを閉じるまでは、ブラウザの Keep-Alive リクエストに応えて通信が完全に持続するように改訂された。 Ver3.0 ではブラウザの要求はつねに HTTPサーバーである ALASKA を経由していた。しかし応答だけは CGI が直接、ブラウザに戻していたために通信の負荷が分散されて大幅なパフォーマンスを改善することに成功している。 しかし Ver3.0 であってもブラウザからの次のリクエストは、やはり HTTP サーバーを経由していたのである。 通信も毎回、Connection: close によって切断されていたのである。 これに対して Ver4.0 では最初だけは HTTPサーバーが受け付けて CGI に指示を出すものの、以降の通信は CGI が直接、ブラウザと持続的に会話を継続して行うのである。これは Chicago に見られる完全なクライアント／サーバー・モデルと全く同じ動作である。 応答速度は驚くほど速くなるのはもちろんのこととして、要求するクライアント数が多くなるほど効果を発揮して違いが明確なものとなる。

また Ver4.0 では ALASKA はリエンジニアリングも行われた。Ver3.0で約4000ステップあったソースは Ver4.0 では、この執筆時点ではわずか344ステップと 約1/10 になっている。 必要な下位モジュールも合わせても 約半分以下 のサイズである。 加えて RPGエンジン4 も RPGエンジン3 では 約 5300 ステップあったソースも 約 1700ステップと 約1/3 のサイズとなっている。これだけでもいかに軽々と小さなものにリエンジニアリングされたか、おわかり頂けるであろう。

通信が持続することの利点は速さだけではない。 ユーザーがブラウザを閉じたことも容易にサーバー側では検出することができるのである。今まで「戻るボタン問題」などで問題視されていたことは、容易にしかも確実に検出できるようになる。

つまりブラウザと言えども単なる PCOMM と同じクライアント／サーバー・モデルとなったのである。 Ver3.0 でも EnterpriseServer のユーザーでパフォーマンスが早くなったと驚かれたことと思うが、Ver4.0 ではさらにその 150%以上 のパフォーマンスを軽々と送出している。

EnterpriseSever Ver4.0 は2006年5月のセミナーで発表を予定している。

Chicago は次期 Ver6.0 として Web全盛のこの時代に対応した手法を計画中である。Ver6.0 の目玉は「Chicago のWeb化」である。 Excelのスプレッド・シートのWeb化は BIFFファイルをIFS に作成して、これをブラウザへ公開する方法が既に一部のユーザーなどでも利用されている。 しかし製品化するとなると旧態依然としたBIFFファイルの公開ではユーザーの失笑を買うことになるのでXMLを出力してExcelでこれをバインドする方法を既に社内で開発済みである。 現在はOS400のバージョンによってXML出力の方法が若干変わってくるので調整を行っているところである。これによってChicago STD版の全ユーザーは保守契約の範囲内で Excelをインターネット経由で配布することができるようになる。

さて、それではChicago PRO版のユーザーはどのような恩恵を受けることができるようになるのであろう？ PRO版であるからには Web経由で ExcelをiSeriesのデータ・ベースに更新できるようにならなければならない。 Excel をiSeriesのIFSへアップロードすることぐらいは CGI を作成すれば何とかなるであろう。しかし IFSに保管された Excelからどのようにして解析してセルの文字や数値を取りだせばよいのだろうか？ 答は「Jakarta POI」である。Java のフリー・ソフトウェア・サイトとして「Jakarta」は良く知られている。世界的に有名で最も普及している HTTPサーバー Apache も Jakarta サイトのものである。 あの Tomcat も、もちろん Jakarta による配布である。

その中で POI とは MS-Office製品を解析する手段を提供するツールであり、Excel だけでなく、Word も直接、読み取ったり作成することもできる。 POI とは Poor Obfuscation Implementation(不十分で曖昧な実装）という意味であり、MS-Office製品は Excel, Word などは自動的に圧縮されているのであるがこれらの圧縮技術が古くて中途半端であるとの強烈な皮肉を込めたネーミングだそうである。しかし何もそこまで言わなくてもという気はする。

それはともかくも POI の導入によってIFS のExcelのセル値を取り出すことが可能となるのである。もちろん RPGによっても Excelを直接読むことがてきるようになる。 筆者はこの時点でJava でPOIを利用して Excelのセル値を読み取る小さな Javaによる解析実行に既に成功している。 これまでCSV をアップロードするという解決は良く目にするが Excelを直接、アップロードするという解決はまだ国内にはないはずだ。製品として Chicago が Excelを直接処理するという初めてのものになる予定である。 Chicago PRO版は Excelによるアップロードを可能にするだけでなく RPG からも直接Excelを読めるような機能も追加する予定である。 Chicago が Webの時代にふさわしい製品となることを願っている。

既存のRPGをCGI に移行するスィートが 「TONAKAI」 と呼ばれるEnterpriseServer の機能である。 DSPF を HTMLに移行することは、そんなに大変なことではなかったが、問題は RPGのCGI 移行である。 DSPF を処理しているRPG は EXFMT などで次のユーザーからの入力を待機し続ける。ところが CGI とは本来、HTMLをブラウザへ排出してしまえば直ちに終了するのが、CGI の動作である。 最初はこのCGI の動作に従って GOTO xxxx として処理を画面単位で分割しようとしたが、ユーザーは、RPGをどのような書き方をしているかは千差万別である。 無理やりある一定の処理構造に押し付けることはできない。

そこで次には、EXFMT を記述している位置にスタックを復元させようと考えた。 前回、HTMLを出力した EXFMT の位置を覚えておいて、次回に呼び出されたときはその位置を復元させようというものである。 このことを実現させるために C/400のライブラリーに用意されているスタック復元関数(long/jump) の使用を試みた。一見、うまく動作しているように見えたがやはり CGI が終了してしまうと、元の正しい位置としてのスタックは消滅していて復元することはできなかった。

試行や調査を数ケ月行い、このことばかりを考え続けるようになった。 最終的に元のCGIプロセスで実行待機させることを検討した。 しかし、このとき伝統的な課題である「 ボタン問題」や「 ボタン問題」が障壁となった。 ボタンや ボタンをブラウザ上で押すとサーバー側では、それを認知できずに画面遷移の矛盾を起こして誤動作の原因となるからである。

多くのサイトや書籍でも ボタンや ボタンは認識できないものとして始めから扱い、これらのボタンを押さないように努めるのが一般的な手法であった。 しかし ボタンなどは小生ならずも便利な機能なので「押すな」と言うほうに無理がある。そこで本当にこれらのボタンは認知できないのかとの調査を始めた。 これらの解決がなくては中途半端なものとして製品としてリリースすることは不可能なのである。

かなりの努力の結果、弊社の社内担当や Microsoft社の協力もあって、何とか認知できるのではないかというところまで漕ぎ着けた。しかしネット環境が異なる場合は、やはり動作が不安定であり、まだ完全なものではなかった。 さらに様々なバッファーリングを工夫することによって、ようやく、これらのボタンは 完全にどのような環境下であっても認知できるまでに至ったのである。 幸い、弊社ではHTTPサーバーを独力で作成していたので HTTPサーバーと連携させることによってこれらのボタンをサーバー側と完全に連動させることに成功した。 ある程度の技術力がもう確立されている中でも、これらの調査と開発には約半年間を要した。恐らくはオープン系を含む世界中のWeb開発の中でも、製品にリリースしたのは初めての試みではないだろうか？

これまでセッション管理にこだわりを持ち続けていたユーザーも多くはなかったが、やはり>存在している。どのような場合でもセッション管理が必要であると信じて疑わない人達がいるのは事実である。 5250ストリームの処理がどうしても頭から抜け切れないのである。 しかし今回のTONAKAI の仮想対話式環境は、これらに対する弊社からの明確な 回答になるものと信じている。

今回、ILE-RPGをC/400に書き換えるという作業を請け負った。 弊社ではないがRPGによって書かれている他社のソフトウェア製品の 実行パフォーマンスを高めるという目的であった。 RPGの仕様書はないので単純にRPGの命令をANSI-Cに書き換えるしか 方法がないのであるが、最初は手作業で置き換えていたのだがこれが恐ろしく単調な作業であることに気づき、さらに手作業による変換では人的な単純な変換ミスが発生する可能性があることに気づいた。

そこで別のC/400を開発してILE-RPGからC/400への変換システムを作ることにしたのであるが、これが意外と底が深かった。 例えばRPGでのMOVE命令は数字から文字へ、あるいは文字から数字フィールドへも簡単に内容を移すことができるがC/400ではそうはいかない。タイプによって命令が異なるのである。 またC/400のコピーは受け入れ側の変数長を超えてMOVEすると次に定義されている別の変数の内容を破壊してしまう。C/400は機械語に近い低級言語であるのでRPGのような保護は無い。 またデータ・ベースのアクセスもC/400は変数の多くが NULL-STOP で管理されるので外部記述のフィールドを扱うのにも苦労した。 このような考慮はあらゆる場面で発生したのである。かなりの苦労を重ねた結果、 100%コンバータのみによる変換に成功した。

生成されたC/400は約20〜30% くらいのステップ数は増えたものの オブジェクト・サイズは RPGの約半分 で、実行速度は5倍 と パフォーマンスの向上を図ることができた。

今回あらゆるRPGの命令を網羅したわけではないが、それでもRPGの命令では、 ひとつの命令でいかに多くのことを行っているかを改めて知らされた。 普段何気なく使っているRPGであるがRPGは高級言語の頂上にいるだけあって開発生産性が良いことは実感した次第である。 もうひとつ気づいたことはRPGからC/400へのコンバータを作成することはすなわちRPGのコンパイラーを作成していることに、他ならないのである。 例えばLinux や他のブラットフォームでも ANSI-C のコンパイラーが搭載されているケースは多い。ここにRPGコンパイラーを移植することができる。 つまりWindowsやLinuxでRPGによる開発が可能となるのである。 ただし入出力インターフェースAPIを別途用意する必要があるので事はそうは単純ではない。 現状では理論的に可能であるが実現するにはかなりの困難があるだろうし開発したとしてもユーザー数は多くはないと予想されるので製品化する予定は今のところ無い。 その昔、RPG-II のDOS上でのコンパイラーが存在した。これは別の仕組みであったかも知れないが今回のC/400コンバータも冬の日の想い出として取っておくことにしよう。

ソフトウェアに触れていない人は良く「ソフトウェアは眼には見えない」と表現しがちであるが日頃、ソフトウェアに触れて従事している人はExcel、Word など十分、触れておりビジュアルなものであることを実感しているはずである。

ここに紹介するのは弊社が現在、開発中のまさしく眼には見えないソフトである 「PowerAccess」(仮称)である。 PowerAccess(パワー・アクセス)を導入しても、PowerAccess（以下 P/Aと略）を起動したりすることはない。これまでのWindows-Appのように手動での起動の操作が明示的には無いのである。 その代わりにWinエクスプローラを起動すると最後のほうにiSeries400のアイコン が表示される。 アイコンをクリックしてログインすると、iSeries400の ライブラリーや ファイルが Winエクスプローラ上に展開されるのである。 下記はその様子である。

このP/Aによる展開はMS-Office製品からでも表示することができる。 P/Aは 仮想フォルダー としてあたかもローカルPC上にiSeries400のライブラリーやデータ・ベース群があるかのように表示するが、単なる仮想フォルダーはMS-Office製品のファイル・オープン・ダイアログには表示されない。 MS-Office製品のファイル・オープン・ダイアログは特殊であり、絶えず次世代のWindowsを指向しているからである。

しかしP/Aによれば下記のようにMS-Office製品上でも表示することができる。

ChicagoのユーザーであればあたかもChicagoのファイル・オープン・ダイアログに見えるがこれはあくまで通常使用されるExcelでオープンした画面ダイアログである。 それでは弊社は何故このような「仮想フォルダー」を開発する必要があったのであろうか？

P/AがあればWindows上のあらゆるAppからiSeries400上のファイルを取得できるようになる。 Access、VisualBASIC、VC++、Excel、Java など言語もAppも問わない。Windowsとシームレスな結合を可能にする。 また一歩進んで iSeries400上にWindowsAppを配置することも可能となる。 C/Sの適用業務では再配布の必要もないし、iSeries400のデータ・ベースをアクセスするのに DBC や JDBC も必要でなくなる。 P/Aは眼には見えないソフトのようであるが、導入と同時にiSeries400は、Windowsとシームレスに結合されるようになる。 iSeries400の開発は RPG/COBOL/JAVA などから Access/VB/VC++ と 一挙にオープンな世界へ解放されるのである。

P/Aは neStudio に搭載される予定であるが、まだその一歩を歩みだしたばかりである。

米国では「iSeriesNews」(旧NEWS/400)マガジンが月刊で
発売されているのをご存知であろうか？ 国内ではベル・データ�鰍ｪ自社のHPでiSeriesNewsマガジンの 一部を翻訳して公開しているが、お勧めしたいのは雑誌に掲載されて いる技術情報である。残念なことにiSeriesNewsの技術情報は日本語には翻訳されておらず、実際の購読者は直接、英文の記事を読むしかないのであるが時折、興味深い記事が掲載される。 記憶を辿れば

・CPI-C通信によるクライアント／サーバー適用業務の開発

これはSNAをCPI-C通信によって簡単に開発する技術とサンプルを紹介していた。Chicago の最初の基礎となった思い出深い記事である。

・RPGによるスプールのPDF化

RPGプログラムによる印刷スプールをPDFにするソースである。
これもSpoolライターの日本語PDFライターの基礎となったものである。
ただし日本語PDFライターではRPGではなく同じ論理でC/400で書き直している。
またiSeiesNewsの記事では罫線はサポートされていなかったがSpoolライターでは罫線もサポートするようになりPDFの書式は記事に比べてかなり進化している。

筆者がiSeriesNewsを購読する目的は技術を吸収したいということだけではなく、米国での 流行やユーザーの動向を知りたいこともある。 新しい技術や方向や多くのソフトウェア製品を眺めているだけでも今後の方向を知ることが できる。事実、Spoolライターを発表したときは日本国内ではほとんどニーズは無かった。 販売店でさえ何に使うのかといぶかしがったものである。 しかし今では電子帳票化の波に乗ってSpoolライターは波を迎えようとしている。

英文であるからと言って臆する必要はない。 小説ではなく技術文書であるので比較的、英語そのものは難しい表現は少ない。 また不明な単語があっても米国人は繰り返し多方面から説明を加えるので、 やがては理解できるようになる。 もうひとつ逆に英文であるメリットがある。 和文であればスラスラと読み流してしまうところを英文であれば、じっくりと読まざるを 得ないので (英語に精通している諸兄であればそのようなことは無いかも知れないが、少なくとも筆者にとってはである。）精読する効果があることである。 また出張の折りに持参すれば読むのに時間がかかるので出張の車内や機内に持ち込むには身軽な携行品となる効果がある。 さりとてなかなか真剣に読むのもつらいときにはサウナや家でリラックスしているときに読むのも良いだろう。

読み方はお任せすることにして例えば今月号(2004/11月)の記事を紹介しよう。

さらに

あなたの興味をそそる記事は見つかったであろうか？ 筆者が特に眼を引かれたのは「V5 でのカラー・サポートの適用業務」であった。 これは V5R3M0 からのカラー印刷の技術背景を解説している記事である。 また、IFS を RPG でアクセスするテクニックは読者にとっても興味深いものではないだろうか？ ンバーになれば雑誌だけでなく過去の記事やWebだけでの詳細な解説をWebで 参照/検索することができるし、ソースもダウンロードすることができる。 iSeriesNews の技術情報は時折IBMが執筆することもあって新しくてかなり高度でもある。 また別途、iSeries400の専門書も別売されており、筆者も時々購入している。 毎年、12月号には Tips & Technique の特集も組まれている。

iSeries400 Network.com へは

i5OS が Power5プロセッサー を搭載していることは既にIBM の発表でご存知であろうがこの中で興味深いことをいくつか紹介しよう。 Power5 はMicrosoft社のXBOXやSonny のプレイ・ステーションにも搭載されており、ゲーム機に使用されているプロセッサーをビジネスに使用していて高価になるのは不思議であるが、それは別としてもPower5の最大の特徴は

インテル社やこれまでのPowerPCにしても複数のJOBを同時に実行しているように見えるが、内部ではクロックの分割によってひとつのCPUがJOB001のある部分を実行して、次にJOB002の次の部分だけを実行して... という具合にタイム・スライスによって少しずつ複数のJOBの実行を面倒見ている。

これに対してマルチスレッド・プロセッサーは同様の処理をするのであるが、複数の 同時並行処理を行うというものである。 マルチスレッドは決して新しい技術ではない。 例えばインストールやダウンロード処理において進行を示すインジケータを見たことが おありであろう。あれはインジケータを表示しつつ裏では同時にダウンロード処理を行っているマルチスレッド処理の典型である。 一般にひとつのJOB はスレッドと呼ばれる演算処理とリソースや環境部分などから成り立っているのであるが、大抵の処理では演算部分に大半が費やされる。

ここである人は次のように述べた。

これは興味深い表現である。 なるほど我々がRPGやC言語で一般に演算を記述するとその記述した順序に従って処理は行われ上記の通りに実行される。いきなり全体を同時に処理されることはない。 ところが必ずしも順序よく行う必要がない場合もある。 例えばコード変換を行うために EBCDICのテーブルと ASCIIのテーブルを読み込む必要があるものとする。 両方のテーブルを読み込んで変換処理の準備として完了するのであるが、これはどちらを先に読み込んでも同じことである。 一歩進んで考えればEBCDICテーブルの読み込みが完了してからASCIIテーブルを読み込むという順序も必要ではない。 つまり同時に読み込むことができればそのほうが効率的であろう。 同時処理を行えば両方のテーブルを読む時間はひとずつ読むよりは早くなる。 これが適用業務に応用する場合のマルチスレッドの考え方である。 もちろん両方とも完了したことを検知しないと次には進めない。

現在、マルチスレッドがiSeries400内部で使用されている例はHTTPサーバーやFtpである。EnterpriseServerのALASKAも、もちろんマルチスレッドである。 iSeries400上でのマルチスレッド・サポートはV3R2M0でPOSIXスレッドという古典的な仮想のマルチスレッドがライブラリーQCPA として導入されV4R4M0からは保守本流のカーネル・スレッドが標準でサポートされるようになった。 HTTPサーバーやFtpの例でもわかるようにマルチスレッドはサーバー・デーモンとして応用することが多かったのであるが、「コンピュータ処理はある処理を完了しないと次の処理に進めない」の言葉にあるようにこれは一般の処理速度を向上させることに大いに貢献することができるということになる。 現在、国内でもiSeries400上でマルチスレッドを使用して開発した例はほとんどまだ見られない。しかしこの言葉に気づくと一般の適用業務への応用例は計り知れないものがある。 マルチスレッドの利点はなんと言ってもハードウェアのアップグレードなしにソフトウェアによってCPUの最大性能を引き出す点にある。 ある人は「マルチスレッドこそが21世紀の技術である」と言ったが、それほど大げさではないにしても、マルチスレッドの利用範囲をもう一度考える価値はあるようである。