藤原 俊成氏
JBCC株式会社
プラットフォーム・ソリューション事業部
ソリューション技術部 Powerグループ
テクニカルアドバイザー
（Power Systems）
外部からのIBM i DBの利用を
約30％が検討
i Magazine（以下、i Mag） IBM iのデータベース化について話をうかがう前に、最近のユーザーの動きを教えてください。
藤原 一連のEOS（保守サービス終了）が始まる2018年9月以前は、移行の際にHAの採用を検討するケースがかなりありましたが、EOS以降はその需要が減少傾向となり、バックアップ環境を強化する動きが増えています。バックアップ先をテープからストレージへ切り替え、効率のよくないテープでのバックアップを減らす動きです。さらには、この更新のタイミングでIBM iを災害対策目的で、データセンターに移設することを検討するケースも多く見受けられます。
外部ストレージへのバックアップでは最近、DataDomainを採用する動きが増えています。IBM i以外のサーバーのバックアップもそこへ集中させて、運用の効率化とデータの保全性を高める考え方です。さらに遠隔地にもう1台DataDomainを配置して、レプリケーション環境でのデータの冗長保全を高める動きも多くなっています。
また、外部ストレージへのバックアップの流れの延長線として、クラウドへの保険的な3次バックアップも増えています。
i Mag それは、図表1の「Backup／DR対策コース」への動きですね。
藤原 そうです。移行と同時にバックアップやDR対策を強化するお客様の動きです。IBM iを置き換えるだけの単純な移行を除いた総数の70％を占めます。
i Mag すると、残り30％は「DB連携活用／SoE推進コース」と「セキュリティ／次世代AI推進コース」ですか。
藤原 セキュリティやAIに関しては大多数のお客様が重要性を認識していますが、移行と同時ではなく、移行後の検討テーマとするケースが大半です。残り30％の大部分は「DB連携活用／SoE推進コース」への動きですね。
i Mag 「DB連携活用」と「SoE推進」はセットの動きですか。
藤原 「DB連携活用」は、IBM iのデータベースを一歩踏み込んで、外部のオープン系システムから最大限活用しようという考え方ですから、「SoE推進」につながります。また、IBM iでSoEを推進しようとすると、さまざまなオープン系とのコネクションが必須となり、データベース（DB2 for i）との連携がキーになります。この両者は表裏一体でセットの動きです。
i Mag その動きは、どのようなビジネスニーズから出てくるのですか。
藤原 多いのは、最新の在庫状況をモバイルからリアルタイムに確認したい（見せたい）とか、得意先や協力会社に在庫状況や販売情報をリアルタイムで開示したい、というニーズです。
もう1つあるのは、“隠れSoE”をやっているお客様がものすごく多いということです。つまり、IBM iから外部サーバーやクライアントなどへバッチモードでデータを転送して、その先でいろいろな処理を行うというパターンです。FTPでオープン系システムへデータを渡して取引先・協力会社へ開示するというケースはよく見受けられますが、このバッチ転送をリアルタイム転送に変えれば、業務のスピードだけなく品質の向上にも寄与します。
IBM iをDBサーバー化するときの
問題と解決のステップ
i Mag IBM iのデータベース・サーバー化は、どのように進めていくのですか。
藤原 IBM iのデータベースをリアルタイムにどこからでも容易に使えるようにするには、Webでつなぐのが一番ですが、Web系の5250エミュレータは制約が多いので、他のWebツールを試してみると、文字化けするとかデータがうまく通らないといった課題が生じます。とくに半角カナ文字やDBCSの問題は必ず浮上します。
とは言え、そのためにIBM iのアプリケーションやデータベースを全面的に作り直すことはできません。そこで半角カナ文字体系5026（CCSID 5026）の古い文字コードを使っている部分は温存して、問題が発生する部分や新規に必要になる部分のためだけに5035（英小文字対応）や1399（日本語拡張）、1208（UTF-8）などの別の文字コードを用いたファイルやその集合体であるライブラリを設計・構築し、関連するフィールドをデータベース要素として持たせる形が考えられます。
つまり、複数の文字コードが混在するファイルやライブラリを別に用意することによって、最小限の労力でIBM iのデータベースをオープンな外部環境から利用できるようになるわけです。
i Mag その次はどうなりますか。
藤原 上記の話をお客様にすると、最初は「すべてのデータベースに適用したい」となることが多いのですが、それでは時間も労力もかかり過ぎます。最初に目標をはっきりさせることが必要なので、お客様とデータベース・サーバー化の話をするときは「5W1H」のルールを適用するようにしています。
つまり、どのデータ／データベースを（What）、誰のために（Who）、どのような目的で（Why）、どのくらいの期間で（When）、どこの区画、ライブラリで（Where）、どのような手順で実現するか（How）という5W1Hです。
そして目的や対象が明確になったら、既存のデータベースの、どのフィールドの文字コード変換が必要かを確認します。対象となるものの多くは、製品名や企業名、その他の固有名などですが、そこからUnicode化や5035化の話へと進んでいくわけです（図表2）。
i Mag ほかに検討の対象となるものはありますか。
藤原 文字コード変換の対象を絞り込むプロセスで明らかになることが多いのは、データベースの構成特性です。たとえば、ある部門では品名が固定長の10文字なのに、別の部門では可変長の20文字というようなことです。ふだんはデータをFTPで送っているので、レコードの属性までは意識していない。フィールド単位で文字コードを検討する段階で初めて気づくことが多くあります。
そこで、IBM i上にデータベースを置くときは、これまでの固定長を可変長にするかとか、スタティックなDDSかそれともダイナミックなSQLにするのか、という話になるわけですが、ほとんどのIBM iユーザーはDDSを選択されます。
しかしDDSはスタティックな固定長ですから、可変長データはどう扱うかとか、シフトコードはどうするかといった検討事項がたくさん出てきます。
「脱DDS」がDBサーバー化の
ポイントの1つ
i Mag どうするのですか。
藤原 私はこのタイミングでSQLを提案します。RPGでもSQL化されたファイルが読めるのですから、必要なデータベースからSQL化しましょう、と勧めます。
確かに、何もないフィールドを一定のルールで意味づけしてサーチできる機能を与えるDDSは優れていますが、外部からオープンにIBM iを活用しようというステージになると、あまり自由度がなく、縛りが多くて融通がききません。
それに対してSQLは、ALTER系コマンドでテーブルを簡単に追加・変更操作できたり、フィールドをコピーできるなど、柔軟にデータベースのコントロールが可能です。私は、IBM iをデータベース・サーバー化するポイントの1つは「脱DDS」だと思っています。
i Mag SQL化が受け入れられると、ターゲットのフィールドの加工へ進むのですか。
藤原 そうなります。この段階でパイロットへと進むお客様が多数おられます。基幹アプリケーション（データベース）の一部を新しい文字コード対応に改修し、SQLで操作してもらって実際に動くことを確認します。もしくは、ACCESSやExcelからクエリを投げ、文字列がきちんと汎用的に表示できることを確認してもらいます。
i Mag ユーザーの反応はどうですか。
藤原 RPG ⅣなどのILE系のアプリケーションや既にSQLをご利用中のお客様はすぐに理解され、納得もされます。それに対して従来のスタティックなRPG Ⅲなどの世界でずっとやってこられたお客様からは、相対的なシステムパフォーマンスが上がっていることもあり、「だから何なの？」という反応をよくお聞きします。その結果、パイロットで終わってしまうケースも少なくありません。
i Mag それは、SQL化のメリットがピンときていないからですか。
藤原 DDSにしておかないと、昔からあるCHAIN命令やREADE命令、READP命令が使えないと思い込んでいるお客様が驚くほどたくさんいるのです。SQLに変えてしまうと、難しいSQL文法に則ってSELECT文を必ず使わなければならない、と思っておられる。
確かに、SQLでCHAIN命令のような高速なダイレクトアタッチの構文を書こうと思ったら非常に大変です。しかし、SQLでデータベースを作っても、昔からのデータベース命令も使えますから、得られるメリットは非常に大きいのです。
またSQLに切り替えると、パフォーマンスは格段に上がります。「結合論理ファイルを対象に検索する」という当社の検証では、外部から接続する同じ条件で、SQLがDDSよりも32倍高速だったという結果もあります。
SQLに変えるとさまざまなメリットが得られるという発想の転換こそ、IBM iをデータベースサーバー化する際のキーになると感じています。
i Mag データベースをリアルタイムに切り替えたときの問題や考慮事項は何ですか。
藤原 データベースをリアルタイム化して、エンドユーザーに直接触られることに対する懸念は昔から存在しています。たとえば、レコードを書き込み処理しているときにアベンドさせられたら、データベースはたまったものではありません。
そうしたことを考えると、直接のアクセスではなくワンクッション置いて利用してもらうほうがよい、との考え方も出てきます。あるいは参照ユーザーにはREAD権だけを与えるという考え方もあります。
この問題に対しては、内部的にオブジェクトの複写／転送を行う手段としてジャーナルやログ、CLコマンドをうまく使って、ユーザーがあたかもリアルタイムにデータベースを利用しているかように見せる対処法もあります。ただし、それもシステム部員の余力やエンドユーザーのITリテラシーに負う部分が少なくないでしょう。
とは言え、今後の方向性としては、IBM iのデータベース（DB2 for i）をオープンに開放し、外部から見える状態にすることが必須条件になることは間違いありません。IBM iのDXへの対応も、この方向での前向きな取り組みにかかっていると思います。
［i Magazine 2020 Summer掲載］
特集｜あらためて知るDb2 for i
