● Dr.フランク・ソルティスが IBM を今年末に退職 !!
AS/400 の生みの親と言われるDr.フランク・ソルティスが 2008年12月末を持って
IBM ロチェスター研究所を去ることになったようである。
Dr.フランク・ソルティスは仮想化技術で S/38 からのアーキテクチャーを創り上げ、
最近では Power5 OS をマルチスレッド化したことでも知られている。
以外と少ないと思われるIBM ロチェスター研究所の4000人の職員にも衝撃が走ったようで
地元の新聞にも大きく取り上げられているようである。
彼の全世界に貢献した功績は称えて余りあるものと思うが、我々が直接、彼と会うことが
できたのは日本では iSUC の会場であった。
彼の講演は、アジェンダや PowerPoint による説明資料は一切無く、ただ口頭による説明のみである。
しかし話の内容は、極めて整然と論理的としたものであり、同時通訳が全く同じ日本語訳であったのは
事前に同時通訳と打ち合わせた内容と寸分たがわない正確なものであったのであろうと容易に想像がつく。
IBM は事ある毎に基礎技術の高さを誇りとして強調してきたが、ソフトウェア開発において
ソリューションの結果を導き出すのは、まさに基礎技術がいかに重要であるかが筆者も
強く認識している。
ユーザーが使いやすくわかりやすいソリューションとするためには、Background の
ソリューション開発者には、最先端の高度な基礎技術の高さが要求されるからである。
その意味においてもIBM のユーザーが直接、彼の功績を具代的に知ったり認識することは
ないだろうが、新しくまた永年にわたって色あせることのない、アーキテクチャーの基礎を
彼が開発されたことには敬意を表せざるを得ない。
彼が IBM在籍中に最後にお会いしたのは iSUC静岡であった。
朝、ホテルのエレベータに向かう途中で、もしかして? と思ったとおりロビーに降りると
Dr.フランク・ソルティスがチェックアウト中であり、思わず挨拶すると微笑んで挨拶を
返してくれた。
彼は今後とも System i の世界から離れることはないだろうと自ら語っているように
また、日本でもお会いできることを切に願っている。
今後の彼の活躍を世界中の IBMユーザーが期待していることであろう。
- 2008年 12月
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# はメイン・ルーチンを持たないイベント駆動型のRPG言語である。
イベント処理をプロシージャーとして記述するだけの簡単なものであるが、
逆にプロシージャー化によって、将来に向けてのオブジェクトの再利用が非常に
簡単にもなり、意識せずともオブジェクト指向モデルの適用業務を開発することができる。
また HTML(ビュー) とメイン・ルーチン(コントロール) とプロシージャー(ビジネス・ロジック)
の3つは完全に分離された、いわゆる
「MVC 3階層モデル」
が実現されている。
もちろん GUI コントロールのサポートとして各 GUIコントロール個別のプロパティやメソッドを
直接、RPG で扱うことができる。
さらに SPECIAL ファイルの機能を利用して、
「RPG の READ/WRITE 命令だけで
HTMLを入出力することができる。」
のである。これは RPG# の記述を大幅にやさしいものとにしている。
つまり HTMLの完全外部ファイル化である。
編集コードや編集語の HTML に記述するだけだ。
フィールドの長さやタイプ、属性も HTMLとして外部ファイルに記述するのである。
しかも Webソリューションにありがちな HTML上の独自タグの記述をほとんど必要と
していない。
あるのは SFLレコードに相当する <REPORT ... というタグだけである。
このように RPG# は Web開発を非常にシンプルなものにした。
米国雑誌を見ていると今、RPGの近代化が話題の中心であり、様々な手法が毎月のように
紹介されているが、RPG のイベント駆動型への進化が必要であることはまだ気づいている
人はいないようである。
RPG が 進化するとすれば RPG# の形になることは間違いない。
僭越ながら筆者は初めて米国を抜いた気がしている。
その点において、いち早く RPG# を開発できたことは幸いであった。
2008年 10月の第19回福岡 iSuc で初めて RPG# を紹介したが反響は予想以上であった。
今、現在、東京と大阪にて Ver5.1発表セミナーを予定している。
是非、RPG# を実際にご覧いただければ幸いである。
RPG# はあなたの開発手法を必ず変えることになるであろう。
- 2008年 11月
● 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ソースには、最初に画面を出力したら後はイベントに対する記述を
書くだけでよい。
これは RPG の入門者にも画期的にコーディングがやさしくなるばかりか、
社内保守も一層、やさしくわかりやすいものとなる。
しかもオープン系にもイベント駆動型の CGI は存在してないのであるから
RPG が最も進化したWeb開発手法となるであろう。
米国IBM もインタビューに答えて、イベント駆動型の Web開発が今後は必要になるであろうと
話していたが、それはストアド・プロシージャーであるという少し観点が異なったものであり、
RPG の根本的な改革を示唆しているものではなかった。
米国雑誌で最も今、賑わっているのは RPG をどう近代化を進めるかということである。
もし RPG が Web開発でイベント駆動型に変身したら、あなたの Web開発は見やすく
わかりやすい展望が開けてくることになることは間違いない。
2008 年、RPG は大きな進化の変貌を遂げる。
- 2008年 7月
● BlueGlass (ブルー・グラス) の示すもの
下記の 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(ブルー・グラス) が動作したかという単純な話ではない。
・DSPF オブジェクトの解析技術
・高度なHTML デザイン
・動作を支えるJavaScript の技術
の3つが統合されて初めて成しえたものである。
これには高度な技術を必要とした。
優秀なスタッフのおかげであると感謝しつつ、BlueGlass (ブルー・グラス) が踏み出した
一歩は意味のある非常に大きなものであると考えている。
それは WebFacing は簡単なものとして見栄えの良いデザインを望むとは難しかった長い歴史がある。
手間をかけずに様々な多くのデザイン・パターンができるのであれば高度な拡張可能な WebFacing に勝るソリューションはないからである。
BlueGlass (ブルー・グラス) の登場によって Web開発は決定的なものが生まれたものと思う。
BlueGlass は、WebFacing の歴史をまちがいなく変えるものである。
- 2008年 4月
● 最も簡単にできるWeb化とは？
EnterpriseServer Ver5.0 では DDSで拡張可能な WebFacing として「AutoWeb」を搭載した。
これまで EnterpriseServer は WebFacing では画面拡張することができないとして
どちらかと言えば反対の立場をとってきた。
おおよそ Web化の目的とは、
・24 * 80 の制限を拡張して情報量を増やしたい。
・ビジュアルで見やすく扱いやすいインターフェースにしたい
・エミュレータの配布の手間とコストを無くしたい。
・通信障害にも問題のない環境にしたい。
などであった。
開発者の立場でも、これらの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 とは違い、販売する営業も「非常にインパクトのある製品」と
評価してくれた。
しかし本当の最後の評価を下すのは、そのユーザーである。
- 2007年11月
● Web2.0 Ajax を語る
諸兄は、Web2.0 という名前くらいは聞いたことがあるだろうか ?
ラクダ本でお馴染みのオライリーが彼の会社の会議中に提唱した、これからの Webの
基本機能のことであり、公的機関による明確な規格があるわけではない。
オライリーが提唱している Web2.0 を満足する Webサイトとは、
|
1. サービスを提供していること
2. データ・ソースを制御できること
3. ユーザーの参加を促すものであること
4. ユーザー情報がデータ・ベース化されていること
5. 利益源がロングテールであること
6. プラットフォームを選ばないこと
7. リッチで軽いこと
|
が、条件として挙げられているが、この中で具体的な技術として述べられているのが
最後の「7.リッチで軽いこと」があるが、それを具現化する技術として脚光を浴びているのが
「Ajax」( = Asynchronous JavaScript + XML : JavaScript と XML
による非同期通信)である。
Ajax (エージャックス) は Google の地図情報検索で世界中の注目を集めた。
そのあたりは市販の書籍にイヤというほど紹介されているので参考にして頂きたい。
Ajax と Systemi5 ユーザーとの関わりや解説は、情報誌「アイマガジン」で筆者が記事と
して
投稿しているので、そちらをお読み頂きたいが、カンタンに Ajax は何かというと
「JavaScript によって サーバーから受け取ったXMLを IDタグに
いつでも埋め込める技術」
といえる。
読者は、毎日、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 は必須機能となるだろう !
- 2007年6月
● SSL通信開発のすべて
EnterpriseServer もユーザーの要望によって SSL によるセキュアな通信をサポートする
ことに
成功した。System i5では SSLは OS400 V4R3M0 から SSL APIが公開され、V5R1M0 からは
GSKIT も公開されて、ユーザー自身による SSL通信の開発が可能となっている。
SSL通信の機能自体は ALASKA にもずいぶん以前から組み込んでいたのだが、
認証作業が複雑で難しいために長いあいだ保留としてきたのである。
しかしここにきてユーザーからの強い要望に押されて、また時代背景からもみて
セキュアな
通信の確立は当然のことと思われるようになってきた。
そこで SSL認証を行う方法であるが、
公開インターネット上での有償の証明書ではなく、イントラネットで SSLを使用するだけで
あれば
OS400付属の 「ディジタル証明書マネージャー」 を使用するだけで SSL通信を
確立することができる。
ところがこの 「ディジタル証明書マネージャー 」(通称 DCM ) の設定が非常に厄介なものであった。
SSL通信環境のセットアップは概ね、以下の手順によって行う。
|
1. IBM HTTPサーバー *ADMIN を起動する。
2. *ADMIN に接続して ディジタル証明書マネージャー を起動する。
3. 証明書ストア *SYSTEM を作成する( *SYSTEM は初期では作成されていない)
4. 証明書ストア *SYSTEM にログインする。
5. 証明書を作成する。
6. アプリケーションID を登録する。( API： QsyRegisterAppForCertUse でも可)
7. アプリケーションに作成した証明書を割り振る。
|
という手順であるが、これがスンナリとは動作しない。
まず最初に 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通信を行っている例は国内であるのだろうか ?
現存するのであればご容赦願いたいが小職の経験では、かなり難しいのではないかと推測
している。
- 2007年3月
● SPECIAL ファイルは RPG の世界を拡張した！ - HTML開発秘話
ファイル仕様書の装置名には、WORKSTN, DISK, PRINERR などと記述するが SPECIAL
という装置名があるのをご存知であろうか?
例えば
の代わりに
FSMP006FM CF E SPECIAL PGMNAME(HTMLFILE)
PLIST(HTML)
のように記述するのである。
SPECIAL ファイルの説明の前に、米国のある BSS (掲示板) で興味ある書き込みをある日、
見つけた。
ある投稿者は
「IBM は HTML という装置を追加して欲しい。 HTML という装置があれば、
通常の RPG で RPG を扱うことができるのではないかと思う。」
という趣旨であった。
別の投稿者が
「それなら SPECIALファイルで代用することができる。」
また別の投稿者は
「私は SPECIALファイルを使って HTMLインターフェースを開発した。
ここにサンプルがある。」
しかし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 ファイル, それはあなたの可能性を広げてくれる素晴らしい技術である。
- 2006年11月
● インターネットはパフォーマンスが命 ! ... ALASKA Ver4.0 の開発
ある書籍の冒頭には 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月のセミナーで発表を予定している。
- 2006年4月
● Excel を RPGで直接、読み取るには？
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の時代にふさわしい製品となることを願っている。
- 2005年11月
● TONAKAI と仮想対話式環境
既存の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 の仮想対話式環境は、これらに対する弊社からの明確な回答に
なるものと
信じている。
- 2005年6月
● RPGからC/400への移行
今回、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コンバータも
冬の日の想い出として取っておくことにしよう。
- 2005年2月
● 見えないソフト : PowerAccess
ソフトウェアに触れていない人は良く「ソフトウェアは眼には見えない」と表現しがちであるが
日頃、ソフトウェアに触れて従事している人は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のデータ・ベースをアクセスするのに
ODBC や JDBC も必要でなくなる。
P/Aは眼には見えないソフトのようであるが、導入と同時にiSeries400は、Windowsと
シームレスに
結合されるようになる。
iSeries400の開発は RPG/COBOL/JAVA などから Access/VB/VC++ と一挙に
オープンな世界へ解放されるのである。
P/AはeStudio に搭載される予定であるが。まだその一歩を歩みだしたばかりである。
- 2004年12月
● iSeriesNews 購読のお勧め
米国では「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月)の記事を紹介しよう。
| Getting into Gear with the IFS | ・・・ | IFSに持ち込む道具 |
|
| IFS Essentials | ・・・ | IFSのエッセンス |
|
Get Started
with IFS Programming | ・・・ | IFSプログラミング入門 |
|
5 Tips for Managing the IFS
with iSeries Navigator | ・・・ | iSeriesナビゲーターの5つのテクニック |
|
| Top IFS Security Pitfalls | ・・・ | IFS機密保護 |
|
Stop Worms Viruses
with StandGuard Anti-Virus | ・・・ | アンチ・ウィルスによるウイルス保護 |
|
--- さらに ---
|
| Is a SAN in Your Future ? | ・・・ | あなたの未来に SAN はあるのか？ |
|
| Secure Service Tools | ・・・ | 機密保護ツール |
|
| Master Modules | ・・・ | モジュールをマスターする。 |
|
Take Advantage of V5
Support for Color Apps | ・・・ | V5 でのカラー・サポートの適用業務 |
|
Execute Stored Procedures
with Net.Data Provider | ・・・ | Net.Dataプロバイダーと
ストアド・プロシージャー |
|
| Extend a WebFasing App | ・・・ | Webフェーシングの拡張 |
|
Sort a Subfile
with a Keyd Data Dueue | ・・・ | キーつきデータ待ち行列の分類 |
あなたの興味をそそる記事は見つかったであろうか？
筆者が特に眼を引かれたのは「V5 でのカラー・サポートの適用業務」であった。
これは V5R3M0 からのカラー印刷の技術背景を解説している記事である。
またIFSをRPGでアクセスするテクニックは読者にとっても興味深いものではないだろうか？
メンバーになれば雑誌だけでなく過去の記事やWebだけでの詳細な解説を
Webで
参照／検索することができるし、ソースもダウンロードすることができる。
iSeriesNews の技術情報は時折IBMが執筆することもあって新しくてかなり高度でもある。
また別途、iSeries400の専門書も別売されており、筆者も時々購入している。
毎年、12月号には Tips & Technique の特集も組まれている。
iSeries400 Network.com へは
- 2004年11月
● i5OS と Power5
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世紀の技術である」と言ったが、それほど
大げさでは
ないにしても、マルチスレッドの利用範囲をもう一度考える価値はあるようである。
- 2004年11月
| 
