マイグレーション教授のワンポイント・アドバイス

マイグレーション教授のワンポイント・アドバイス～z/OS、ミドルウェアマイグレーションの勘所～

マイグレーション教授のワンポイント・アドバイス

～z/O

S、ミド

ルウェアマイグレーションの勘所～

第3章　CICSマイグレーションのここが知りたい 93

　3-① MQアタッチメントの変更（CICS TS V3.1以前からの移行）・・・・・・・・・・・ 94

　3-② LE化（CICS TS V2.2以前からの移行）・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 106

　3-③ ロガー環境のセットアップ（CICS/ESA V4.1以前からの移行）・・・・・ 116

第4章　押さえておきたいDB2マイグレーションのポイント 125

　4-① 移行計画での考慮点（1） ……………………………………………… 126

　4-② 移行計画での考慮点（2） ……………………………………………… 134

　4-③ 非互換項目のキーポイント …………………………………………… 142

　4-④ REBINDとアクセスパス管理の鍵 ………………………………… 148

　4-⑤ V10への移行での注意点 ……………………………………………… 155

第5章　MQマイグレーションの第一歩 167

　5-① MQ移行計画立案のために …………………………………………… 168

　5-② バージョンアップによる変更の影響と対応策について　（V5.3.1からV7.0.1へのケース） ………………………………… 178

参考資料 ……………………………………………………………………………………………… 186

第１章

第２章

第３章

第４章

第５章

第1章　z/OSマイグレーションの簡素化と役立つ新機能 7

　1-① USERMOD廃止のチャンス到来　　　　① LE実行時オプションのカスタマイズ …………………………………………………… 8　　　　② SDSF導入オプションのカスタマイズ ………………………………………………… 14　　　　③ DFSORT導入オプションのカスタマイズ …………………………………………… 19

　1-② z/OS V1R10移行を支援するスマート機能　　　　① DISP=UNCATLG処理変更への対応 ……………………………………………… 25　　　　② WTO/WTOR処理変更への対応 ……………………………………………………… 33　　　　③ MGCR（SVC34）処理変更への対応 ………………………………………………… 39

　1-③ 使い勝手を向上するz/OS新機能（Ease-Of-Use）　　　　① 非SMS管理順次データセットのアロケーションに関する新機能 ……………… 45　　　　② ALLOCxx PARMLIBメンバー設定値の更新に関する新機能 ……………… 50　　　　③ ICKDSF WTORメッセージICK003Dの出力抑止に関する新機能 ………… 54　　　　④ IEAOPTxx PARMLIBメンバーのパラメータ表示に関する新機能 ……… 56　　　　⑤ SMFタイプ30レコード（パフォーマンス・セクション）に関する新機能 ……… 60　　　　⑥ SMFタイプ30レコード（EXCPセクション）に関する新機能 …………………… 64　　　　⑦ SYS1.DUMPデータセットの動的アロケーションに関する新機能 New … 68

第2章　IMSマイグレーションの効率化のために 71

　2-① SMU移行の勘所 SMUからRACFへの移行って？ ………………… 72

　2-② 移行してみよう！端末に対するコマンド・セキュリティー移行の勘所 … 77

　2-③ 移行してみよう！ TYPE 1 AOIセキュリティー移行の勘所 ………… 85

目次

はじめに ……………………………………………………………………………………………………… 6


1

2

3

1

2

3

1

2

3

4

5

6

7

�

・第1章・

z/OSマイグレーションの簡素化と役立つ新機能

�

第１章

USERMOD廃止のチャンス到来

z/OS V1R10移行を支援するスマート機能

使い勝手を向上するz/OS新機能（Ease-Of-Use）

1

2

3

はじめにマイグレーションとは…『優れた基盤サービスを維持・発展しながら新し

い機能を実現するための重要なプロジェクトの取り組み』…と言えるのでは

ないでしょうか。

たとえば企業の再編、新サービスの競争など、ビジネス環境の変化が

実際に生じた場合、急場のシステム変更計画・実施に取り掛かること

は、システムの安定稼働に悪影響を与えかねません。このような要件

がいつ発生しても円滑に対応できるよう、日頃からシステム基盤の整

備を行うことで、優れた基盤サービスが提供され、企業経営にも貢献

することができます。

また、基幹システムのマイグレーション・プロジェクトに取り組むことで、

システム・スキルの向上や若手技術者へのスキル伝承、組織の活性

化が期待できます。さらに、日頃使用しているシステム設定の意味や

重要性をあらためて理解したり、より効率的な運用の仕組みを検討す

る良い機会にもなります。

本書では、z/OSが大好きな教授、ミドルウェアが得意な教授が、マイグ

レーションの効率化、マイグレーションを成功に導くための勘所、そして

使い勝手の向上を狙った新機能まで、幅広い話題を取り上げます。

基幹システムのマイグレーション・プロジェクトを成功させるためにも、

ぜひマイグレーション教授の様々な情報をご活用いただければと思い

ます。

2013年2月

日本アイ・ビー・エム株式会社

z/OSマイグレーションの簡素化と役立つ新機能①…USERMOD廃止のチャンス到来

�


�

第１章-

❶

USERMOD適用JCL

CEEDOPTのカスタマイズ（z/OS V1R4の場合）

++ USERMOD(CEEWDO1) REWORK(2005139) .

++ VER (Z038) FMID(HLE7707) .

++ SRC ( CEEDOPT ) DISTLIB (ACEESRC1).

CEEDOPT CSECT 00100000

CEEDOPT AMODE ANY 00110000

CEEDOPT RMODE ANY 00120000

CEEXOPT ABPERC=((NONE),OVR), X00130000

(途中省略)

XUFLOW=((AUTO),OVR) 00420000

END 00430000

//CEEWDOPT JOB MSGLEVEL=(1,1)

//CEEWDOPT EXEC PGM=GIMSMP,REGION=4096K

//SMPCSI DD DSN=#GLOBALCSI,DISP=SHR

//SMPPTFIN DD *

/*

//SMPCNTL DD *

SET BDY(GLOBAL).

RECEIVE S(CEEWDO1) LIST SYSMODS.

SET BDY(#TZONE).

APPLY S(CEEWDO1) ASSEM.

/*

USERMODソース

教授：なるほど。図①-1にあるように、LEの実行時オプション変更は、CEEDOPT（Non-CICS）、CEECOPT（CICS）などのモジュール形式で行うのがまだ主流かも知れませんね。ただ、その方法だと、バージョン・アップやリリース・アップの都度、SMP/EUSERMODの再適用が必要になります。これは、とても煩わしいと思いませんか？

生徒：はい、もちろん、私もそう感じています。何か簡単にカスタマイズできる方法があればうれしいのですが。

PARMLIB（CEEPRMxx）メンバーによるカスタマイズ新機能

教授：数年前から提供されている、とても簡単な方法がありますよ！z/OSV1R7からは、PARMLIBの新規メンバーCEEPRMxxを利用して、LE実行時オプションの省略時値をカスタマイズできるようになったのです。とても便利な機能だと思いませんか？

生徒：それは助かります。ぜひ、私のプロジェクトでも、利用する方向で検討してみたいと思います。

教授：この新機能を利用すれば、SMP/EUSERMOD方式を廃止して、より簡素化されたカスタマイズ手順に移行することができるわけです。おまけに、z/OSV1R10では、活動化前に、CEEPRMxxメンバー指定値の構文検査を行う機能（ツール）も、下記のように新しく提供されました。

　　　　・PGM=CEEPRMCC（構文検査をバッチ・プログラムにて行う場合）　　　　・CEEPRMCK（構文検査をCLISTにて行う場合）

図①-1.SMP/EUSERMOD方式（例）

1　……LE実行時オプションのカスタマイズ

これまでのカスタマイズ方法

教授：今回は、LE（LanguageEnvironment）実行時オプションのカスタマイズについて考えてみましょう。

生徒：どんなお話が聞けるか楽しみです。よろしくお願いします。

教授：こちらこそ。最近は、アプリケーションの稼働環境として、LE化対応を余儀なくされるケースが増えてきたと思います。LE実行時オプションのカスタマイズを、どんな方法で行っていますか？

生徒：はい、教授。ちょうど今、z/OSV1R6からV1R10への移行プロジェクトが始まり、その中で、LE化も対応することになりました。実行時オプションのカスタマイズは、以前のVSCOBOLIIと同じような方法で、提供されるアセンブラー・マクロを使ってオプション指定し、それをSMP/EUSERMODとして適用する予定です。

第１章-

❶

USERMOD廃止のチャンス到来 1

z/OS環境にて稼働する製品では、導入オプションや実行時オプションなどのカスタマイズ（省略時値の変更）をモジュール形式で行う場合が少なくありません。一般的に、このような場合、カスタマイズ内容はSMP/E…USERMODとして管理することを推奨しますので、バージョン・アップやリリース・アップの都度、USERMODの再適用が繰り返し必要となります。このような背景から、z/OSマイグレーション作業をより円滑に進めるためにも、従来のモジュール形式（SMP/E…USERMOD）に加え、パラメータ形式によるカスタマイズ機能が望まれています。

第1章-❶では、3回に渡り、上記のようなUSERMODを廃止可能とする新機能の概要をご紹介します。バージョン・アップやリリース・アップ作業の簡素化のみならず、日頃の運用負荷軽減にもつながります。


10


11

第１章-

❶

教授：その通りです。図①-2には、PARMLIB（CEEPRMxx）メンバーの活用例を載せましたので、参考にしてください。また、z/OSV1R10にて提供されるヘルス・チェック機能（IBMHealthCheckerforz/OS）では、CEE_USING_LE_PARMLIBという新しいチェック項目が追加されており、PARMLIB（CEEPRMxx）メンバーが使用されていない場合に、メッセージを出力して、USERMOD方式からの移行を促してくれます。

CEEPRMxxメンバー方式の制約と方向性

生徒：ところで、PARMLIBメンバーCEEPRMxxを利用すれば、カスタマイズ作業や管理がとても楽になると思うのですが、何かデメリットのようなものはあるのでしょうか？

教授：そうですね。強いて言えば、実行時オーバーライドを不可にできない点だと思います。つまり、新規メンバーCEEPRMxxで指定された省略時オプションは、全て、実行時にオーバーライド可能（OVR扱い）として定義されるのです。従来のSMP/EUSERMOD方式では、アセンブラー・マクロ形式でオプションを定義する際、実行時オーバーライド不可（NONOVR扱い）という属性を与えることができますが、この新機能では、それがサポートされていません。よって、実行時オーバーライドを禁止したいオプションがある場合は、従来のSMP/EUSERMOD方式を併用する必要があるというわけです。

図①-2.z/OSV1R10におけるPARMLIB（CEEPRMxx）メンバー方式（例）

①設定SYS1.PARMLIB（CEEPRM01）

②活動化SET CEE=01コマンド

③反映確認D CEE,CEEDOPTコマンド

MSGFILE DD名の省略時値を、SYSOUTからLEOUTに変更

CEEDOPT(MSGFILE(LEOUT,FBA,121,0,NOENQ))

SET CEE=01 IEE252I MEMBER CEEPRM01 FOUND IN SYS1.PARMLIB CEE3742I THE SET CEE COMMAND HAS COMPLETED.

D CEE,CEEDOPT CEE3745I 15.31.28 DISPLAY CEEDOPT CEE=(01) 157 LAST WHERE SET OPTION --------------------------------------------------------------- PARMLIB(CEEPRM01) MSGFILE(LEOUT,FBA,121,0,NOENQ)

生徒：オプションの指定方法は、これまでのアセンブラー・マクロ形式（USERMOD方式）と同じでしょうか？

教授：いえ、そこが少し違う点です。利用するCEEPRMxxメンバーのサフィックスは、PARMLIB（IEASYSxx）メンバーのCEE=（xx,…,xx）パラメータにて指定しますが、このCEEPRMxxメンバーでは、EXECPARM形式でオプションを指定します。例えば、"ALL31=ON"というアセンブラー・マクロ形式とは異なり、"ALL31（ON）"というパラメータ形式にて指定するわけです。

生徒：そこは注意が必要ですね。

教授：はい、z/OSV1R11までは、その制約が残ります。ただ、新機能への移行容易性を考慮して、z/OSV1R12では、従来のアセンブラー・マクロ形式（USERMOD方式）も新たにサポートされました。ちょっと、うれしい話だと思いませんか？

生徒：素晴らしいです！それは移行しやすくなりますね。ところで、これまでのSMP/EUSERMOD方式も、まだ使えるのですか？

教授：はい、SMP/EUSERMOD方式も、これまで同様に利用することができます。また、新規CEEPRMxxメンバーによるオプション指定値は、対応するUSERMOD指定値をオーバーライドします。

生徒：その機能を利用する上で、何か新しいコマンドはあるのでしょうか？

教授：はい、例えば、下記のようなものがあります。もちろん、z/OSV1R10でも利用できます。

　　　　・SETCEE=xxコマンド・・CEEPRMxxメンバーの置換（動的活動化）　　　　・SETCEEコマンド・・・・・オプションの選択的置換　　　　・DCEE,ALLコマンド・・・CEEPRMxxメンバーで現在有効なオプションの表示　　　　　　　　　　　　　　　　（USERMOD指定値はマージされません）

生徒：3番目のコマンドは、とても役立つ新機能だと思います。これまでのUSERMOD方式だと、設定状況の確認を行うために、バッチ・ジョブやCICSトランザクションを実行する必要があります。CEEPRMxxメンバー方式に移行すると、それがコマンド一発で確認できるのは、とても簡単ですね。

第１章-

❶

12


13

SMP/E USERMOD方式 PARMLIB（CEEPRMxx）メンバー方式

利用可能な稼働環境限定せず z/OSV1R7以降に限定

カスタマイズの方法 ++USERMODの適用 PARMLIBメンバーの編集

z/OS移行時の対応 USERMODの再適用必要に応じて更新

構文検査の機能機能なし

z/OSV1R10で機能追加

・PGM=CEEPRMCC（バッチ実行）

・CEEPRMCK（CLIST実行）

オプション指定の形式アセンブラー・マクロ形式（例：ALL31=ON）

EXECPARMパラメータ形式（例：ALL31（ON））

※z/OSV1R12からは、アセンブラー・マクロ形式もサポート

設定内容の確認方法・RPTOPTSオプション（非CICS環境）・CLERトランザクション（CICS環境） DCEE,ALLコマンド

実行時オーバーライドの禁止機能

・OVR属性（オーバーライド可）・・・省略時解釈

・NONOVR属性（オーバーライド不可）

常にOVR属性（オーバーライド可）の扱いとなる

※z/OSV1R12からは、NONOVR属性の設定をサポート

方向性将来的な機能廃止の意向あり

※当機能のサポートは、z/OSV1R13が最終となる計画

今後主流となるカスタマイズ方式

図①-3.主な機能比較

第１章-

❶

■ z/OS Language Environment カスタマイズ（SA88-8552-08）　http://publibfp.dhe.ibm.com/epubs/pdf/a8885528.pdf第2部 Language Environment のカスタマイズ: ランタイム・オプション、出口、およびプロシージャー第6章 CEEPRMxx （z/OS Language Environment パラメーター）

■ z/OS Language Environment Customization （SA22-7564-10）　http://publibz.boulder.ibm.com/epubs/pdf/ceea5190.pdfPart 2. Language Environment Customization: run-time options, exits, and proceduresChapter 6. CEEPRMxx （z/OS Language Environment Parameters）

【関連マニュアル】

生徒：なるほど。幸い、私のプロジェクトでは、実行時オーバーライド禁止という要件はありませんが、確かに影響を受ける場合も出てきそうですね。でも、教授。そんな制約があるとすると、SMP/EUSERMOD方式を廃止して、CEEPRMxxメンバーに完全移行することは無理ではないでしょうか？

教授：はい、確かにその通りです。その制約を排除するため、z/OSV1R12では、CEEPRMxxメンバーの各オプションに対して、NONOVR属性が指定可能となり、実行時オーバーライドを禁止できるようになりました。この結果、SMP/EUSERMOD方式を継続利用する必然性がなくなりますから、今まで以上に、CEEPRMxxメンバーへの移行が強く推奨されます。

生徒：それは役立つ新機能だと思います。

教授：そんな背景もあって、z/OSV1R12では、SMP/EUSERMOD方式のサポートを廃止する将来計画（方向性）が盛り込まれています。具体的には、z/OSV1R13が、SMP/EUSERMOD方式をサポートする最後のリリースになる計画です。

生徒：なるほど。その将来計画も、z/OSV1R12で制約排除が実現できた結果なのですね。とてもよく理解できます。

教授：国内でも、CEEPRMxxメンバーの利用実績が出てきているようです。せっかくの機会ですから、USERMOD廃止に向けて計画しましょう。あと、図①-3には、機能比較を簡単にまとめましたので、こちらも忘れずにチェックしてみてくださいね！

生徒：はい、教授。今日は、大変参考になるお話、ありがとうございました。これからも、よろしくお願いします！

教授：こちらこそ。お役に立てて、よかったです。次回は、SDSF導入オプションのカスタマイズについて、一緒に考えてみましょう。

第１章-

❶


14 15


います。このような背景もあって、SMP/EUSERMODのMCSステートメント見直しが必要です。特に、図①-4で示したように、FMID（JJE775S）やDISTLIB（AISFSRC1）指定が、これまでとは全く異なりますから、注意してください。

生徒：やはり、USERMOD管理の場合は、いろいろと手間が掛かるのですね。

教授：はい、その通りです。パラメータ方式への移行を支援するREXXツール（ISFACP）も利用できますから、z/OSマイグレーションを簡素化し、維持・管理作業の負荷を軽減する意味でも、PARMLIB（ISFPRMxx）メンバーへの移行をおすすめします。また、z/OSV1R10にて提供されるヘルス・チェック機能（IBMHealthCheckerforz/OS）では、SDSF_ISFPARMS_IN_USEという新しいチェック項目が追加されており、ISFPARMSモジュールを利用したカスタマイズが今でも行われている場合に、メッセージを出力して、パラメータ方式への移行を促してくれます。

ISFUSER Exitによるカスタマイズは荷が重い？

教授：話は変わりますが、SDSFでは、何らかの理由で標準機能（省略時解釈の処理）を変更する際、ユーザーExitISFUSERのコーディング・導入を必要とする場合があります。みなさんは、使用していますか？

生徒：はい、教授。今のプロジェクトでは、ISFUSERExitを使用しています。以前、z/OSV1R7へ移行した際、SDSFAPARPK06616（zAAPサポート）による機能変更で、DAパネルのタイトル行に、スタートI/O情報（SIO）が表示されなくなったので、その表示を復活させる目的で、ISFUSERExitを初めて導入しました。

教授：なるほど。やはり、その対応ですね。他にも、同様な報告を何件か聞いたことがあります。

生徒：ISFUSERExitの中身は、あるフラグのビットをオンするという単純なロジックですが、以前と同じパネル内容を表示するために、Exitを導入するしかないというのは、ちょっと荷が重いと感じています。

図①-4.z/OSV1R10におけるUSERMOD方式（例）

第１章-

❶


第１章-

❶

2………………SDSF導入オプションのカスタマイズ

ISFPARMS USERMOD方式は手間が掛かる？

教授：今回は、SDSF導入オプションのカスタマイズについて考えてみましょう。


教授：こちらこそ。いきなりですが、PARMLIB（ISFPRMxx）メンバーを利用して導入オプションのカスタマイズを行っているのでしょうか？

生徒：はい、教授。以前担当したプロジェクトでは、確かにそうでした。でも、今のプロジェクトでは、ISFPARMSモジュールによるSMP/EUSERMOD方式を依然として使用しています。

教授：そうですか。では、SDSFサーバーは起動していないのですね？

生徒：はい、DISPLAYコマンドで確認しても、SDSFアドレス空間が稼働していないので、最初は少し戸惑いました。ところで、z/OSV1R10では、ISFPARMSカスタマイズに関するSMP/EUSERMODのサンプルJCL（ISFPARME）が、いつものSISFJCLデータセットに見当たりません。これは、いよいよ、PARMLIB（ISFPRMxx）メンバーによるパラメータ方式への移行が必須になったということなのでしょうか？

教授：確かに、z/OSV1R10からは、サンプルJCLの提供が廃止されています。ただし、これは、PARMLIB（ISFPRMxx）メンバーへの移行が必須になったという意味ではなく、従来のUSERMOD方式も利用可能です。

生徒：ありがとうございます。ひとまずは安心ですが、パラメータ方式への移行も合わせて検討したいと思います。

教授：z/OSV1R10で、ISFPARMSモジュールを利用したUSERMOD方式を継続する場合は、注意すべき点がありますので、忘れないでくださいね。

生徒：いつものように、FMIDが変わる以外に何かあるのでしょうか？

教授：まず、提供されるISFPARMSのソースが、SISFSRC（または、AISFSRC）データセットからSISFSRC1（または、AISFSRC1）データセットに移動しました。また、モジュールISFPARMSの格納先も、SISFLOADからSISFMOD1データセットに変わって


1�


1�

ます。PROPERTYステートメントのNAMEパラメータは、大文字・小文字どちらでも指定可能です。なお、参考までに、カスタマイズ実施前後のパネル表示を掲載しましたので、図①-6、図①-7を参照してください。

生徒：なるほど、これは簡単です！　他には、この新機能を活用できるものはありますか？

教授：他には、SDSFPREFIXコマンドで指定された値（ABC）に対し、総称文字（*）を自動的に付加する（ABC*）ことができます。つまり、利用者の方は、*を明示的に入力せずともすむわけです。この機能は、当初、z/OSV1R8SDSFに対するAPAR

図①-6.カスタマイズ実施前のDAパネル表示（例）

図①-7.カスタマイズ実施後のDAパネル表示（例）

第１章-

❶

第１章-

❶

教授：確かに、マイグレーションの負荷という観点でも避けたいですね。

生徒：以前と同じように、DAパネル・タイトルのSIO情報を表示したまま、ISFUSERExitが廃止できれば最高なのですが。

PARMLIB（ISFPRMxx）メンバーの機能がパワー・アップ！

教授：はい、それなら、おすすめの新機能がありますよ！z/OSV1R9では、SDSFサーバーで利用されるPARMLIB（ISFPRMxx）メンバーが機能拡張され、ISFUSERExitを代替するための新規ステートメントPROPLIST、PROPERTYが提供されました。これを活用すれば、ISFUSERExitなしでも、簡単にSIO情報の表示ができますから、もはや、それだけを目的としたISFUSERExitの導入は必要ありません。

生徒：その新機能は、ISFPARMSUSERMOD方式では使えないのでしょうか？

教授：そうです。USERMOD方式では、同等機能が提供されていません。つまり、これはSDSFサーバー稼働時のメリットと言えます。もちろん、ISFUSERExitの継続利用もできますが、対応する新規ステートメント（ISFPRMxxメンバー）に移行することでExitの廃止が可能となり、より簡素化されたカスタマイズ手順を実現することができます。

生徒：ちなみに、どのような設定になるのでしょうか？

教授：例えば、DAパネルのタイトル行でSIO情報表示を行うには、図①-5のように指定し

図①-5.PARMLIB（ISFPRMxx）メンバー設定（例）


1�


1�

3………………DFSORT導入オプションのカスタマイズ

ICEMAC USERMOD方式での苦労話

教授：今回は、DFSORT導入オプションのカスタマイズをテーマに考えてみましょう。


教授：こちらこそ。DFSORTといえば、ICEMAC導入オプションのカスタマイズを行うケースが多いかと思います。いかがでしょうか？

生徒：はい、教授。私のプロジェクトでは、リリース・アップなどで新規オプションが追加された際、従来との互換性を維持できるよう、その省略時値をカスタマイズしています。同じような目的で利用される場合は、意外と多いのではないでしょうか。

教授：そうですね、私もそう思います。ところで、ICEMAC導入オプションのカスタマイズは、SMP/EでUSERMOD管理していると思いますが、これまでの苦労話は何かありますか？

生徒：苦労話といえば、以前、DFSORT製品の提供ライブラリー名が変わったことで、++SRCUPDステートメントのDISTMOD指定値を修正する必要がありました。また、マクロのPTFレベルが更新された関係で、++VERステートメントのPRE指定値を修正する必要が生じたこともありました。あの時は、"GIM38201EMODIDERROR"メッセージでなかなかUSERMODが適用できず、苦労した覚えがありますね。

教授：なるほど、それは大変お疲れ様でした。とても具体的な話で、苦労が目に見えるようです。

生徒：SMP/EUSERMODの再適用は、マイグレーションの都度行うので、ある意味、定型作業なのですが、もっと簡単にカスタマイズできれば、とても助かると思います。

PARMLIB（ICEPRMxx）メンバーによるカスタマイズ新機能

教授：うれしいことに、ようやくその機能が提供されましたよ！z/OSV1R10からは、PARMLIBの新規メンバー ICEPRMxxを利用して、DFSORT導入オプションの省略時値をカスタマイズできるようになりました。これは、おすすめの新機能です。

第１章-

❶

第１章-

❶

PK36698で提供され、ISFUSERExitによるカスタマイズでのみ実現可能でしたが、z/OSV1R9以降では、下記のような簡単な指定で対応できます。

　　　　　GROUP NAME(ISFSPROG),CUSTOM(SPRGPROP)

　　　　　PROPLIST NAME（SPRGPROP),

　　　　　PROPERTY NAME(Command.PREFIX.AddGenChar) VALUE（TRUE）

生徒：これは知りませんでした。この新機能を使えば、いろいろなメリットがありそうですね。私のプロジェクトでは、ISFUSERExitを廃止するために、PARMLIB（ISFPRMxx）メンバーへの移行を検討してみたいと思います。おかげさまで、ISFPARMSUSERMOD方式の廃止が見えてきました。

教授：とても前向きな、素晴らしいアクションだと思います。


教授：こちらこそ。お役に立てて、よかったです。次回は、DFSORT導入オプションのカスタマイズについて、一緒に考えてみましょう。

■ z/OS SDSF オペレーションおよびカスタマイズ（SA88-8610-08）第2章カスタマイズとセキュリティーのためのISFPARMSの使用カスタマイズされたプロパティー（PROPLIST）

■ z/OS SDSF Operation and Customization （SA22-7670-11）Chapter 2. Using ISFPARMS for customization and securityCustomized properties （PROPLIST）



20


21

教授：メンバーのサフィックスは、最大10個まで指定できます。例えば、全システム共通のメンバーと、各システム固有のメンバーを組み合わせて運用することができます。また、複数のICEPRMxxメンバー間でオプション指定が重複した場合は、最後に指定された値が有効になります。

生徒：オプションの指定方法はどうでしょうか？

教授：これは、かなり柔軟性があり、keyword=（value）形式、keyword=value形式、keyword（value）形式のいずれかを使用することができます。つまり、従来のアセンブラー・マクロ形式（SMP/EUSERMOD方式）から、容易に移行できるような設計になっているわけです。

生徒：従来のSMP/EUSERMOD方式も、まだ利用することができますか？

教授：はい。もちろん、これまでのUSERMOD方式を継続利用することも可能です。また、オプション・マージの優先順位は、下記のようになっています。

　　　　PARMLIB（ICEPRMxx）メンバー指定値> カスタマイズ後のICEAMx/ICETDxモジュール指定値（ICEMAC導入オプション）>IBM省略時値

生徒：なるほど。z/OSV1R10では、ICEPRMxxメンバーへの移行が必須というわけではないのですね。理解しました。

PGM=ICETOOLのDEFAULTS LISTコマンドがパワー・アップ！

教授：PGM=ICETOOLのDEFAULTSLISTコマンドを使って、設定オプションや省略時値の一覧を確認することはありますか？

生徒：教授、もちろんです。PTF適用時やマイグレーションを計画する際、いつも活用しています。とても頼りになるツールだと思います。

教授：はい、確かにその通りです。z/OSV1R10では、これがまた進化し、（a）ICEPRMxx/ICEMACマージ後のオプション指定値、（b）ICEPRMxxメンバーによるオプション指定値、（c）ICEMACマクロによるオプション指定値、を各々出力するようになっています。従来の出力は、（c）だけでしたね。参考までに、図①-9では、（b）ICEPRMxxメンバーによるオプション指定値、の出力結果だけを抜き出してみました。

第１章-

❶

第１章-

❶

生徒：それは便利ですね！そうすると、SMP/EUSERMODも廃止可能ということですか？

教授：はい、その通りです。この新機能は、8つの導入環境（JCL/INV/TSO/TSOINV/TD1～TD4）すべてを対象にしていますから、SMP/EUSERMODを廃止して、より簡素化されたカスタマイズ手順に移行することができます。

生徒：それは、とても助かります。教授、具体的に教えてください。先ほど、PARMLIBの新規メンバー ICEPRMxxを利用するとのことでしたが、そのサフィックスは、やはり、PARMLIB（IEASYSxx）メンバーで指定するのでしょうか？

教授：いえ、そうではありません。ちょっと珍しい方法かも知れませんが、活動化するメンバー ICEPRMxxはPARMLIB連結内に作成しておき、そのサフィックスを、STARTICEOPT,ICEPRM=（xx,…,xx）コマンドで指定するのです。具体例が図①-8にありますから、参照してください。また、このSTARTコマンドは、PARMLIB（COMMNDxx）メンバーに登録しておき、IPL時に有効化するのが一般的だと思います。

生徒：そうなのですね。確かに、ちょっと独特な感じがします。

教授：ICEOPTというプロシジャーは、ServerPacで導入すると、SYS1.IBM.PROCLIBデータセットに提供されます。中身は、PGM=ICEPRMLを実行するステップになっています。

生徒：ICEPRMxxメンバーのサフィックスは、いくつまで指定可能でしょうか？

図①-8.ICEPRMxxメンバーの設定と活動化（例）


22


23

教授：はい、その通りです。z/OSV1R10のDFSORTAPARPK70523では、　　　TIME=30パラメータが新しく追加されています。

生徒：ありがとうございます。確認してみます。

教授：その他、DB2V8およびDB29では、APARPK59399のPTFを適用することで、DB2ユーティリティー実行時に、ICEPRMxxメンバーの設定オプション（ICEAM2環境）が有効となります。PTF適用状況を確認してください。さらに、DB2V8のユーティリティーでは、APARPK87450のPTFを含めた予防保守をおすすめします。

生徒：DB2のユーティリティーとDFSORTは、お互い密接に関係していると思いますので、アドバイスいただいた点を確認してみます。

教授：はい、よろしくお願いします。国内でも、ICEPRMxxメンバーの利用実績が出てきているようです。せっかくの機会ですから、USERMOD廃止に向けて計画しましょう！

生徒：これから移行するz/OSV1R10での利用を検討してみます。

教授：それから、参考までに、SORTジョブ実行結果の一部を、図①-10に載せました。目新しいメッセージICE252Iも出力されており、ICEPRMxxメンバーを利用していることがわかります。こちらも忘れずにチェックしてみてくださいね！

第１章-

❶

図①-10.SORTジョブ実行時のオプション確認（例）

第１章-

❶

生徒：なるほど、これは本当にパワー・アップです。意図した設定値が（b）に正しく反映されているかどうか、自分の目で確認できるのはうれしいです。

教授：はい。実際にリストしてみると、情報量が多くて、結構なページ数になるのですが、大変役立つ機能です。

生徒：ぜひ、私も試してみたいと思います。ところで、この新機能を利用する上で、注意すべき点があれば、教えてくださいませんか？

ICEPRMxxメンバー方式の考慮点は？

教授：STARTICEOPTコマンド実行時には、指定されたICEPRMxxメンバーを見つけるために、PARMLIB連結データセットが探索されます。従って、PARMLIBデータセットのRACF保護を行っているような場合は、READアクセス許可があるかどうか、開始タスク・テーブル、または、ICHRIN03の確認をおすすめします。

生徒：なるほど、RACF保護の影響を受けるわけですね。確認してみます。

教授：それから、STARTICEOPTコマンドを、SUB=MSTR指定で実行する場合は、注意してください。この場合、TIMEパラメータ指定がないと、ABEND322が起きてしまいます。念のため、ICEOPTのカタプロをチェックして、TIME=30パラメータが明示指定されていることを確認してください。

生徒：提供されるカタプロを使用すればよろしいですね？

図①-9.ICEPRMxxメンバー設定の反映確認（例）


24 25

1…　…DISP=UNCATLG処理変更への対応

"DISP=UNCATLG"指定にはご注意

教授：VOLSER指定でアロケーションされたデータセットに対して"DISP=UNCATLG"要求を行った場合、もし、カタログ済みの同名データセットがあれば、そちらがアンカタログされてしまいます。つまり、VOLSER指定によらず、カタログ済みのデータセットがアンカタログされるわけです。ご存知でしたか？

生徒：これまで経験したことがなく、あまり意識していませんでした。

教授：もちろん、SMS管理データセットの場合は、カタログ前提ですから、"DISP=UNCATLG"要求は無視され、KEEP扱いとなります。一方、非SMS管理データセットの場合、VOLSER指定でアロケーションされたデータセットを"DISP=UNCATLG"処理すると、このような事象が起きてしまいます。

生徒：教授、具体的な例を教えてくださいますか？

z/OSマイグレーションの簡素化と役立つ新機能②…z/OS…V1R10移行を支援するスマート機能

第１章-

❷

z/OS V1R10移行を支援するスマート機能

2

第1章-❷では、マイグレーション・アクションの計画・実施を効率化するヒントをお届けします。


教授：こちらこそ。お役に立てて、よかったです。既に掲載済みの　　　■1 LE実行時オプションのカスタマイズ　　　■■■2 SDSF導入オプションのカスタマイズ　　　では、それぞれ、LEやSDSFのカスタマイズ簡素化をテーマにまとめています。　　　ぜひ、こちらもお見逃しなく！

■ z/OS DFSORT インストールおよびカスタマイズ（SD88-6332-02）第2部 DFSORTのカスタマイズ第4章インストール・デフォルトの変更

■ z/OS DFSORT Installation and Customization （SC26-7524-02） Part 2. Customizing DFSORTChapter 4. Changing the Installation Defaults


第１章-

❶

2� 2�

同名データセット（データセット（1）:非カタログ、データセット（2）:カタログ済み）が別ボリューム上に存在する場合、データセット（1）の存在VOLSERを指定してアロケーションし、"DISP=（OLD,UNCATLG）"処理を行っても、カタログ済みのデータセット（2）がアンカタログされることはありません。

（1）DSN=TSO1.TEST.D0815A,VOL=SER=OSXWK1,非カタログ（2）DSN=TSO1.TEST.D0815A,VOL=SER=OSXCA1,カタログ済み

生徒：ということは、z/OSV1R10で"DISP=UNCATLG"要求を行う際は、VOLSER指定を実施せず、カタログ経由でのアロケーションを行うことが必須となるわけですね。

教授：はい、その通りです。"DISP=UNCATLG"処理に対しては、正常終了時・異常終了時いずれの場合も、この変更が適用されます。対応としては、"DISP=UNCATLG"指定を"DISP=DELETE"指定に変更したり、また、IDCAMSプログラムを代替策として利用する方法も考えられます。

生徒：教授、ダイナミック・アロケーションの場合はどうでしょうか？

教授：JCLアロケーションの他、ダイナミック・アロケーションも同じく変更対象となります。さらに、カタログ・エントリーが示すVOLSERを明示指定してアロケーションした場合でさえ、"DISP=UNCATLG"要求が無視されます（KEEP扱いとなる）ので、注意してください。

生徒：具体例で教えてくださいますか？

図②-2.z/OSV1R10での実行例

第１章-

❷


教授：では、z/OSV1R8での実行例に基づき説明しましょう。（図②-1参照）同名データセット（データセット（1）:非カタログ、データセット（2）:カタログ済み）が別ボリューム上に存在する場合、データセット（1）の存在VOLSERを指定してアロケーションし、"DISP=（OLD,UNCATLG）"処理を行うと、データセット（2）がアンカタログされてしまいます。また、JOBLOGを参照しても、このようなことが起きていることは、全く知ることができません。

（1）DSN=TSO5.TEST.D0815A,VOL=SER=WORK01,非カタログ（2）DSN=TSO5.TEST.D0815A,VOL=SER=ATSWK2,カタログ済み※実際にアンカタログされたのは、データセット（2）

生徒：なるほど。VOLSER指定のアロケーションと"DISP=UNCATLG"処理は、とても相性が悪いのですね。

z/OS V1R10で行われた機能変更

教授：このような紛らわしさを解消するため、z/OSV1R10では機能変更が行われました。

生徒：もしかして、今後は、JCLエラーになるのですか？

教授：いいえ、ジョブ・ステップは実行されますが、VOLSER指定でアロケーションされたデータセットの"DISP=UNCATLG"要求は無視され、KEEP扱いとなります。その場合、JOBLOGのJESYSMSGには、メッセージIEF287IdsnNOTUNCTLGD13が出力され、"CC=00"で処理完了します。（図②-2参照）


第１章-

❷


2� 2�


第１章-

❷

z/OS V1R10で提供された移行支援機能

教授：その作業負荷を少しでも軽減するために、移行支援の機能が提供されています。具体的には、PARMLIB（ALLOCxx）メンバーに新規パラメータが追加され、カタログ経由でアロケーションされていないデータセットの"DISP=UNCATLG"要求にどう対応するか、そのポリシーを明示指定できるようになったのです。

生徒：それは、とても役立つ便利機能だと思います。z/OSV1R10では、標準で利用できるのでしょうか？

教授：もちろん、z/OSV1R10でも利用可能ですが、この移行支援機能は、次のようなAPARに対するPTFを適用することで提供されます。

APAROA27917（PTF:2009/08CLOSE）APAROA32843（PTF:2010/07CLOSE）

生徒：教授、具体的なパラメータ設定を教えてくださいますか？

教授：サマリーすると、下表のようになります。省略時解釈は、従来のz/OSV1R10と同じく、機能変更後の処理内容となっています。

"SYSTEMVERIFY_UNCAT"機能のサマリーメンバー：PARMLIB（ALLOCxx）ステートメント：SYSTEMVERIFY_UNCAT（FAIL|TRACK|MSGTRACK|LOGTRACK）

（1）（2）（3）（4）

機能提供されたAPAR番号

VOLSER指定でアロケーションされたデータセットの "DISP＝UNCATLG"処理

TrackingFacilityの活用

新規メッセージIEF384I

FAIL APAROA27917無視される（IEF287IdsnNOTUNCTLGD13）

トラッキングなし未出力

TRACK APAROA27917 処理されるトラッキングあり未出力

MSGTRACK APAROA27917 処理されるトラッキングあり出力（JOBLOG）

LOGTRACK APAROA32843 処理されるトラッキングあり出力（JOBLOG+HardcopyLog）

教授：はい、わかりました。では、z/OSV1R8とV1R10で実行した場合の違いを説明しましょう。（図②-3、図②-4参照）カタログ・エントリーが示すVOLSER（WORK01）を明示指定してアロケーションを行い、"DISP=UNCATLG"処理を実施した場合、該当データセット（TSO1.TEST.D0814A）はアンカタログされます。

カタログ・エントリーが示すVOLSER（OSXWK1）を明示指定してアロケーションを行い、"DISP=UNCATLG"処理を実施した場合、メッセージIEF287IdsnNOTUNCTLGD13が出力され、該当データセット（TSO1.TEST.D0814A）はアンカタログされません。

生徒：なるほど、ご説明ありがとうございます。挙動の変化は理解できましたが、z/OSV1R10へ移行する際の影響調査・対応として、修正すべきJCLを洗い出す作業が大変になりますね。


第１章-

❷



30 31

第１章-

❷


VERIFY_UNCAT（MSGTRACK）"オプションを明示指定した場合の実行結果です。この場合、「TrackingFacility」の他、（4）列にある通り、JOBLOGのJESYSMSG部分に、メッセージIEF384Iも合わせて出力されます。

生徒：これは、かなり詳しい情報が得られますね。プログラムによるダイナミック・アロケーションの場合、特に有用ではないでしょうか。ところで、（4）列にありますが、LOGTRACKオプションを明示指定すれば、JOBLOGの他、SYSLOGやOPERLOGにもメッセージIEF384Iが出力されるのですね？

教授：はい、その通りです。MSGTRACKオプションとの違いは、該当メッセージがWTOとして発行されるかどうかです。LOGTRACKオプションの場合のみ、WTOメッセージ（ハードコピーのみ）としても出力されるわけです。

生徒：なるほど。「TrackingFacility」を無理に稼働しなくても、SYSLOGやOPERLOGへ記録されたIEF384Iメッセージを調査することで、修正箇所（ジョブ名、ステップ名、DD名）の洗い出しに十分役立ちそうです。また、出力されたWTOメッセージを自動化処理することも可能だと思います。あと、『TrackingFacility』実行結果で、

図②-5.JOBLOG/JESYSMSGへのメッセージIEF384I出力

図②-6.「TrackingFacility」実行結果

第１章-

❷

生徒：（1）列の意味は、「全てのオプションを利用可能とするには、最近のAPAROA32843まで必要」ということですね？

教授：はい、ご理解の通りです。なお、APAROA32843のPTF出荷対象は、z/OSV1R12までとなっています。つまり、z/OSV1R13では標準機能になっています。

生徒：（2）列の意味ですが、省略時値（FAIL）以外を明示指定すると、z/OSV1R10移行後にメッセージIEF287IdsnNOTUNCTLGD13の状況が発生するような場合でも、z/OSV1R9以前と同様に、"DISP=UNCATLG"要求が処理されるのですね？

教授：その通りです。再び、"DISP=UNCATLG"要求が有効になります。ただし、これらのオプションは、あくまで、移行容易性を高めるための支援機能という位置付けで、JCLやプログラムの修正対象・箇所を洗い出すことが目的となります。従って、最終的には、それらの修正を行った上で、省略時値（FAIL）の環境で稼働させることを推奨します。

生徒：なるほど。修正箇所の洗い出しを助け、かつ、対応までの猶予期間を設けているわけですね。この機能を利用すれば、z/OSV1R10移行とは非同期に、別タスクでの修正対応も可能になると思います。

「Tracking Facility」が大活躍

生徒：教授、（3）列の意味を教えてくださいますか？

教授：わかりました。その前に、「TrackingFacility」はご存知でしょうか？

生徒：はい。SETCONTRACKING=ON/OFFコマンドで活動化・非活動化する機能ですね。以前、1バイト・コンソールIDの洗い出しで利用したことがあります。でも、当時は、「ConsoleIDTrackingFacility」という名称だったように記憶しています。

教授：その通りです。z/OSV1R10では名称が変わり、「TrackingFacility」となりました。この機能が、またまた大活躍なのです。

生徒：より汎用性が高い支援機能（インフラ）に生まれ変わったのですね。素晴らしいです。

教授：「TrackingFacility」を活動化させておくと、TRACK/MSGTRACK/LOGTRACKオプション明示指定にて稼働した場合、影響を受けるJCLやプログラムをリスト・アップすることができます。（図②-5、図②-6参照）下の例は、z/OSV1R10に対してAPAROA27917のPTF適用後、"SYSTEM


32 33


第１章-

❷

2…　…WTO/WTOR処理変更への対応

WTO/WTORメッセージの宛先？

教授：WTOマクロやWTORマクロで出力するメッセージの宛先を、どのように管理していますか？

生徒：宛先コード（Routingcode）を利用するのが一般的ではないでしょうか。

教授：はい、確かにそうですね。その以外の方法として、メッセージ出力先のコンソールを直接指定することもできます。

生徒：それは、CONSOLxxPARMLIBメンバーで指定するコンソール名のことですか？

教授：はい、コンソール名の他、コンソールIDも利用できます。コンソールIDは、システムが割り振る番号で、DCコマンドの応答メッセージIEE889Iで示されます。（図②-8参照）ただし、z/OSV1R10では、応答メッセージがCNZ4100Iに変わり、さらに、コンソールIDも非表示となりました。（図②-9参照）

図②-8.z/OSV1R8での実行結果

"VALUE"の値が"00"となっていますが、これは何でしょうか？1バイト・コンソールIDの洗い出しでは、この値は、確かコンソールIDを示していたと思います。

教授：そうですね。ただし、この機能では意味を持たない（常にゼロ）ので、無視していただいて構いません。そして、大事なことを言い忘れましたが、RACFOPERCMDSクラスを活動化して、コマンド実行を保護している場合、SETCONコマンドを実行するためには、該当プロファイルに対して"CONTROL"以上のアクセス権限が必要となりますから、注意してください。

生徒：詳しい解説、どうもありがとうございました。影響を受けるJCLやプログラムが一体どれくらいあるかわかりませんが、洗い出しの目的で支援機能を利用しながら、z/OSV1R10への移行作業をスマートに進めたいと思います。

教授：はい、お役に立てたようで、よかったです。最後になりますが、z/OSV1R10で行われた機能変更は、図②-7のようなシナリオにも影響を与えますので、注意してください。つまり、省略時値（FAIL）が有効な実行環境では、"DISP=UNCATLG"要求が無視され、"DISP=DELETE"要求のみが処理されますから、この場合、「カタログ・エントリーが存在し、VTOCエントリーが存在しない」という中途半端な状態が発生してしまうのです。

生徒：なるほど。このようなハウス・キーピング的な仕掛けがある場合は、特に要注意なのですね。漏れがないようチェックしたいと思います。

教授：とにかく、大きな影響を受けず、省略時値（FAIL）がそのまま利用できる環境ならば一番ですね。移行プロジェクトの成功を祈ります。

生徒：ありがとうございます。また、いろいろと教えてください！


第１章-

❷

図②-7.影響を受けるシナリオ（例）

■ APAR OA27917: NEW FUNCTION - MIGRATION SUPPORT FOR UNCATLG （US）■ APAR OA32843: NEW FUNCTION - DISP=UNCATLG ENHANCEMENT （US）

【関連情報】

34 35

第１章-

❷


生徒：なるほど、パラメータで指定する以外にも、レジスターを使った指定方法があるのですね。

教授：その通りです。ただし、この【方法（3）】を利用する場合だけは、z/OSV1R7以降、注意してください。同じくコンソールIDを利用する場合でも、【方法（1）】は影響を受けません。

z/OS V1R7での変更点

生徒：教授、注意すべき点を具体的に教えてくださいますか？

教授：【方法（3）】を利用して、z/OSV1R6以前に作成された既存プログラムは、z/OSV1R7環境でも、従来と同じく稼働し、指定されたコンソールへのメッセージ出力が可能です。一方、z/OSV1R7環境では、MCSFLAG=（REG0）パラメータやMCSFLAG=（QREG0）パラメータにて「1バイト・コンソールID」を明示指定したアセンブラー・プログラムは、もはや新規作成や再作成することができません。その場合には、下記のようなアセンブル・エラーが発生してしまいます。（図②-11参照）

つまり、新規作成や再作成を行う場合は、【方法（1）】や【方法（2）】のコーディングに変更する必要があるわけです。

z/OS V1R8での変更点

生徒：この点は、z/OSV1R8以降でも同じでしょうか？

教授：よい質問ですね。アセンブル・エラーの件は変わりませんが、z/OSV1R8以降になると、今度は、【方法（3）】を利用した既存プログラムの稼働時さえ、指定されたコンソールへのメッセージ出力が行われるとは限らなくなります。

生徒：どういうことでしょうか？

教授：つまり、MCSFLAG=（REG0）パラメータやMCSFLAG=（QREG0）パラメータを明示指定したアセンブラー・プログラムからの出力メッセージでは、指定されたコンソールIDが無視されてしまうのです。

図②-11.WTOマクロでMCSFLAG=（REG0）パラメータ指定時のアセンブル・エラー（例）

第１章-

❷

図②-9.z/OSV1R10での実行結果

生徒：なるほど。z/OSV1R10では、実行結果の表示が大きく変わったのですね。ちょっと慣れるまで、大変だと思います。ところで、教授、話を戻しますが、メッセージ出力に関して、z/OSV1R10移行時の注意点はありますか？

宛先コンソールを直接指定する方法

教授：はい。では、そのあたりを、ちょっと整理してみましょう。WTO/WTORマクロでメッセージ出力先を制御するには、宛先コード（Routingcode）の他、宛先コンソールを直接指定する方法として、下記の3種類があります。（図②-10参照）

この中で最も新しいのは【方法（2）】で、MVS/ESAV4.1から利用可能になったものです。

【方法（1）】・・・4バイト・コンソールIDCONSIDパラメータで、コンソールIDを含む4バイト・フィールドを指定する。

【方法（2）】CONSNAMEパラメータで、コンソール名を含む8バイト・フィールドを指定する。【方法（3）】・・・1バイト・コンソールIDレジスター0の下位1バイトにコンソールIDを設定し、かつ、MCSFLAG=（REG0）パラメータ、または、MCSFLAG=（QREG0）パラメータを明示指定する。


図②-10.WTO/WTORマクロで宛先コンソールを直接指定する方法

3� 3�

第１章-

❷


変更対象の洗い出し

生徒：アドバイスありがとうございます。ところで、【方法（3）】を利用したプログラム、つまり、変更対象を洗い出すには、どのような方法が考えられますか？

教授：【方法（3）】（1バイト・コンソールID）でメッセージ出力したプログラムを洗い出すには、「TrackingFacility」を利用することができます。

生徒：その機能は、簡単に使えるのでしょうか？

教授：はい、これは、z/OSV1R4.2から標準提供されており、SETCONTR=ONコマンドで活動化します。非活動化は、SETCONTR=OFFコマンドで行います。RACFOPERCMDSクラスを活動化して、コマンド実行を保護している場合、SETCONコマンドを実行するためには、該当プロファイルに対して"CONTROL"以上のアクセス権限が必要となりますから、注意してください。

生徒：教授、具体的な実行例があれば、教えてくださいますか？

教授：【方法（3）】（1バイト・コンソールID）を利用したWTOメッセージが、「TrackingFacility」で検知される様子を、z/OSV1R10環境で確認しました。（図②-12、図②-13参照）もちろん、該当WTOマクロを含むアセンブラー・プログラムは、z/OSV1R7以降、新規作成できませんので、z/OSV1R6で作成したもの（WTOTEST1）を利用しています。

図②-12.発行したWTOメッセージ

第１章-

❷


生徒：すると、そのメッセージはコンソール出力されなくなるのでしょうか？

教授：いえ、厳密に言えば、CONSOLxxPARMLIBメンバーで、"UNKNIDS（Y）"属性が明示指定されたコンソール宛てに出力されることになります。ただし、そのコンソールが、本来の意図した宛先とは異なる可能性が十分あるわけです。

生徒："UNKNIDS（Y）"は、新しい属性ですね？

教授：はい、その通りです。"UNKNIDS"属性は、z/OSV1R8から新規追加されたもので、省略時値は"UNKNIDS（N）"となります。従って、"UNKNIDS（Y）"属性は、明示指定が必要です。

生徒：z/OSV1R7以降では、【方法（3）】を利用したプログラムへの考慮が必要ということが、よくわかりました。

教授：お話したように、z/OSV1R8では、【方法（3）】で利用する「1バイト・コンソールID」のサポートが完全に廃止されたわけです。

対応策

生徒：では、教授、【方法（3）】を利用したプログラムは、どのように対応すればよろしいのでしょうか？

教授：これまでのように、特定コンソールをメッセージ出力の宛先にしたい場合は、【方法（3）】（1バイト・コンソールID）をあきらめ、【方法（1）】（4バイト・コンソールID）、または、【方法（2）】（コンソール名）へ変更してください。

生徒：【方法（1）】と【方法（2）】の選択基準は、何かありますでしょうか？

教授：そうですね。（図②-9）のように、z/OSV1R10では、DCコマンドの応答メッセージがCNZ4100Iに変わり、さらに、コンソールIDも非表示となりました。また、コンソールIDは、CONSOLxxPARMLIBメンバーで指定するCONSOLEステートメントの指定順序にも依存しますから、使い勝手の観点では、コンソール名が推奨です。z/OSV1R4.2以降では、MONOPLEX環境でも、コンソール名の指定は必須ですからね。

生徒：わかりました。

教授：あと、この機会に、宛先コード（Routingcode）の利用も合わせて検討してくださいね。

3� 3�

第１章-

❷


3…　…MGCR （SVC34）処理変更への対応

プログラムからのコマンド実行

教授：システム・コマンドは、どのように実行していますか？

生徒：オペレーターさんなら、MCSコンソールを利用しますね。それ以外のケースでは、やはり、SDSFのLOGパネルやULOGパネルを利用して実行するのが一般的ではないでしょうか。あと、NetView（NCCF）コンソールも利用します。

教授：その他、バッチ・プログラムからもコマンド実行できますが、ご存知でしょうか？

生徒：はい、教授。プログラムを利用すれば、さまざまな条件などに応じて適切なコマンドが実行できるので、便利ですね。私は、あまり利用しませんが、以前開発されたプログラムが、今でも現役で稼働している可能性は高いと思います。

教授：確かに、運用の一部になっているかも知れませんね。バッチ・プログラムからコマンドを実行する場合、一般的に、次のような3つの方法が考えられます。（図②-14参照）

　　　　　　　【方法（1）】MGCRマクロの利用　　　　　　　【方法（2）】SVC34（X'0A22'）の直接利用　　　　　　　【方法（3）】MGCREマクロの利用

図②-14.プログラムからコマンドを実行する方法

この【方法（1）】MGCRマクロでは、START/REPLYコマンドの実行がサポートされ、それ以外のコマンドは、【方法（3）】MGCREマクロを利用して実行するのがお作法です。また、SYS1.MACLIBデータセットを見ればわかりますが、【方法（1）】MGCRマクロ、【方法（3）】MGCREマクロとも、最終的には、SVC34が発行されています。

生徒：前回（■2 ）のお話で、【z/OSV1R8では、「1バイト・コンソールID」のサポートが完全に廃止された】という件をうかがいましたが、この変更は、バッチ・プログラムからコマンドを実行する際にも、影響を受けるのでしょうか？

教授：鋭い質問ですね。はい、影響を受けます。今日は、その点について一緒に考えてみましょう。

第１章-

❷


生徒：これは便利です。修正対象のプログラムとメッセージ、さらに、【方法（3）】で指定された「1バイト・コンソールID」の値までわかるのですね！

教授：はい、その通りです。z/OSV1R8以降では、【方法（3）】（1バイト・コンソールID）を利用したアセンブラー・プログラムの稼働時に影響が出ますので、z/OSV1R6やV1R7でも提供されている「TrackingFacility」は、その洗い出しに大変役立つはずです。

生徒：教授、大変有益なアドバイス、どうもありがとうございました。z/OSV1R10移行に向けて、ぜひ活用してみたいと思います。また、いろいろと教えてください！

図②-13.z/OSV1R10環境での「TrackingFacility」実行結果

■ z/OS V1R10.0 MVS Planning: Operations （SA22-7601-10）「A.0 Appendix A. Tracking facility」（US）■マニュアル（日本語版）　http://publibfp.dhe.ibm.com/epubs/pdf/a8885738.pdf

【「Tracking Facility」に関する情報】

40 41

第１章-

❷


【対応策（1）】z/OSV1R7までと同様、該当「1バイト・コンソールID」と関連付けを行うには、【方法（3）】MGCREマクロによるプログラム修正を行い、コンソールID（CONSIDオペランド）、または、コンソール名（CONSNAMEオペランド）を指定する。

【対応策（2）】プログラム修正を行い、レジスター0に設定された「1バイト・コンソールID」をゼロ・クリア（SRREG0,REG0）することで、【コンソールID=0】（INTERNAL）から発行されたコマンドの扱いに変更する。

図②-15.z/OSV1R8以降での対応策

生徒：なるほど。いずれも、プログラム修正になるのですね。ところで、一般的には、どちらの対応策が推奨でしょうか？

教授：それは、もちろん【対応策（1）】をおすすめします。というのは、【対応策（2）】は一見簡単ですが、次のような懸念事項があるからです。（図②-16参照）

●コマンドの応答メッセージは、PARMLIB（CONSOLxx）メンバーでINTIDS（Y）オプションが明示指定されたコンソールにしか出力されない。

　"INTIDS"属性は、z/OSV1R8から新規追加されたもので、省略時値は"INTIDS（N）"となる。従って、"INTIDS（Y）"属性を有効とするには、明示指定が必要。

●【コンソールID=0】（INTERNAL）が利用されるため、AUTH（MASTER）属性が適用される。従って、従来利用していた「1バイト・コンソールID」のAUTHレベルと整合性が保てない可能性あり。

図②-16.【対応策（2）】の懸念事項

変更対象の洗い出し

生徒：アドバイスありがとうございます。ところで、【方法（1）】や【方法（2）】を利用したプログラムで影響を受けるもの、つまり、変更対象を洗い出すには、どのような方法が考えられますか？

教授：はい。それには、これまでも何度も登場した、「TrackingFacility」を活用することができます。z/OSV1R9までの呼称は、「Console IDTrackingfacility」でしたが、z/OSV1R10では呼称が変更されました。この機能は、z/OSV1R4.2か

第１章-

❷


z/OS V1R8機能変更に伴う影響

生徒：教授、z/OSV1R8以降では、【方法（1）】～【方法（3）】のいずれも、影響を受けるのでしょうか？

教授：いいえ、z/OSV1R8で行われた「1バイト・コンソールID」のサポート廃止に影響を受けるのは、【方法（1）】MGCRマクロを利用する場合と【方法（2）】SVC34を直接利用する場合になります。【方法（3）】MGCREマクロを利用する場合は、影響を受けません。

生徒：そもそも、バッチ・プログラムからコマンド実行する際に、「1バイト・コンソールID」がどのように関係するのか、理解できません。

教授：「1バイト・コンソールID」は、レジスター0に対して設定しますが、z/OSV1R8以降では、それがサポートされなくなったのです。

生徒：「1バイト・コンソールID」を設定する理由は、何でしょうか？

教授：それには、大きく2つの目的があります。まず、コマンドを実行する際、該当コンソールIDに関連したAUTHレベルを利用することができます。さらに、コマンドの実行結果を、該当コンソールIDをもつコンソールへ返すことができます。

生徒：なるほど、そのような背景があるのですね。すると、「1バイト・コンソールID」を継続利用した場合、どのような結果になるのでしょうか？

教授：z/OSV1R8以降では、「1バイト・コンソールID」が無視され、代わりに、UNKNOWNコンソールIDが設定されてしまいます。つまり、z/OSV1R7までのような、意図した処理結果が得られないわけです。

対応策

生徒：では、このようなプログラムは、どのように対応すべきでしょうか？

教授：対応策としては、次のような2種類が考えられます。（図②-15参照）

42 43

第１章-

❷


教授：はい、その通りです。"TRACKINGINFORMATION"では、【方法（1）】MGCRマクロを利用する場合、【方法（2）】SVC34を直接利用する場合、いずれも、"MGCR"という同一タイプが表示されますので、そこは注意してくださいね。

影響を受けるコマンドの実行結果

生徒：ところで、このコマンド実行結果は、どうなるのでしょうか？

教授：先ほど説明しましたが、z/OSV1R8以降では、「1バイト・コンソールID」が無視され、代わりに、UNKNOWNコンソールIDが設定されてしまいます。従って、SYSLOGには、次のように実行結果が記録されます。（図②-19参照）

図②-19.コマンドの実行結果-SYSLOG抜粋

生徒：この意味は、DIPLINFOコマンドが、UNKNOWNコンソールIDから実行され、結果が、UNKNOWNコンソールID向けに返されたということですね？

教授：その通りです。UNKNOWNコンソールIDからのコマンド実行時は、SYSLOGの先頭から2桁目に"U"が表示され、レスポンス出力先コンソール名としても"UNKNOWN"が表示されます。

生徒：SYSLOGの"U"表示は、見慣れませんね。

教授：これは、UNKNOWNコンソールIDが追加されたz/OSV1R8から登場したもので、SYSLOGのマッピング・マクロ（SYS1.MODGEN（IHAHCLOG））を参照すると、"COMMANDFROMUNKNOWNCONSOLEID"として定義されているのがわかります。

第１章-

❷


ら標準提供されており、SETCONTR=ONコマンドで活動化します。非活動化は、SETCONTR=OFFコマンドで行います。

生徒：確か、SETCONコマンドは、権限エラーに要注意でしたね。

教授：その通りです。ちゃんと復習していますね。RACFOPERCMDSクラスを活動化して、コマンド実行を保護している場合、SETCONコマンドを実行するためには、該当プロファイルに対して"CONTROL"以上のアクセス権限が必要となりますから、注意してください。（図②-17参照）

図②-17.SETCONコマンド実行時の権限エラー発生例

生徒：「TrackingFacility」の具体的な実行例があれば、教えてくださいますか？

教授：【方法（2）】SVC34の直接利用を行った場合、「TrackingFacility」で検知される様子を、z/OSV1R10環境で検証しました。（図②-18参照）この例では、バッチ・プログラムを利用して、レジスター0に「1バイト・コンソールID」として"5"を設定し、SVC34経由でコマンド（DIPLINFO）を実行しています。

図②-18.z/OSV1R10環境での「TrackingFacility」実行結果

生徒：なるほど。修正対象のプログラムと該当コマンド、さらに、【方法（2）】で指定されている「1バイト・コンソールID」の値までわかるのですね！

44 45

第１章-

❸

z/OSマイグレーションの簡素化と役立つ新機能③…使い勝手を向上するz/OS新機能（Ease-Of-Use）

1…　… 非SMS管理順次データセットのアロケーションに関する新機能

新規アロケーション時のEOFレコード

教授：今回は、DASD順次データセットを新規アロケーションする際のEOF（End-Of-File）レコード書き込みに関して取り上げてみましょう。JCLで新規アロケーション（例：PGM=IEFBR14）されただけの非SMS管理順次データセットは、VTOCにそのデータセットのエントリー（DSCB）が作成されるだけで、実際にデータの書き込まれる領域が掃除されるわけでもなく、また、先頭トラックにEOFレコードが書き込まれるわけでもありません。

生徒：それは、SMS管理の順次データセットも同じですか？

教授：いいえ。非SMS管理の場合と異なり、SMS管理の順次データセットでは、アロケーションしただけでも、先頭トラックにEOFが書き込まれます。EOFレコードは、データセットの先頭トラックに書き込まれたデータ長がゼロのレコードです。

生徒：ということは、非SMS管理データセットの場合は、アロケーションしたデータセットの先頭トラックに偶然ゴミのEOFがあった場合を除き、読み込もうと思えば無効なデータ（削除される前にその場所に書き込まれていた古いデータ）を読み込めてしまうわけですね。

教授：そうです。もちろん、実際にそのようにしてデータを読み込んでみると、当然ゴミのデータですから、読み込む際に指定されたデータセット属性（DCB）と異なる可能性があり、エラーとして検知される場合もあります。

使い勝手を向上するz/OS新機能（Ease-Of-Use）

3

第1章-①…,②に続きz/OS分野の話題を取り上げ、7回シリーズでお届けします。z/OS…V1R10から後続リリースへの移行後に利用可能となる新機能や待ち望まれた機能改善などを中心に、日々のシステム運用にも有効な情報・ヒントが満載です。

第１章-

❷


生徒：すると、この実行結果は、どのコンソールにも出力されないのでしょうか？

教授：いいえ。前回（■2 ）も触れましたが、これは、CONSOLxxPARMLIBメンバーで、"UNKNIDS（Y）"属性が明示指定されたコンソール宛てに出力されます。"UNKNIDS"属性は、z/OSV1R8から新規追加されたもので、省略時値は"UNKNIDS（N）"となります。従って、"UNKNIDS（Y）"属性は、明示指定が必要です。

生徒：ところで、教授。今思い出したのですが、JCLのコマンド・ステートメントを利用してコマンド実行する場合があると思います。この場合は、影響を受けますか？

教授：よい質問です。実は、z/OSV1R8以降でも、UNKNOWNコンソールIDが設定されない「1バイト・コンソールID」があり、それには、X'00'（INTERNAL）とX'80'（INSTREAM）が該当します。JCLからのコマンド実行は、COMMANDステートメントの明示指定有無によらず、INSTREAM扱いとなります。つまり、この例外にあたりますから、z/OSV1R7以前と同様、正常に実行されます。

生徒：なるほど、それは安心しました。また、【対応策（2）】で【コンソールID=0】（INTERNAL）が利用可能な理由もわかりました。

教授：z/OSV1R8以降では、【方法（1）】MGCRマクロを利用する場合と【方法（2）】SVC34を直接利用する場合のアセンブラー・プログラムが影響を受ける可能性がありますので、「TrackingFacility」は、その洗い出しに大変役立つはずです。「TrackingFacility」は、z/OSV1R4.2で登場し、z/OSV1R6やV1R7でも提供されています。もちろん、z/OSV1R10でも利用できます。

生徒：教授、大変有益なアドバイス、どうもありがとうございました。z/OSV1R10移行に向けて、ぜひ活用してみたいと思います。また、いろいろと教えてください！

教授：お役に立てたようで、よかったです。

■ z/OS V1R10.0 MVS Planning: Operations （SA22-7601-10）「A.0 Appendix A. Tracking facility」（US）■マニュアル（日本語版）　http://publibfp.dhe.ibm.com/epubs/pdf/a8885738.pdf

【「Tracking Facility」に関する情報】

4� 4�

第１章-

❸


教授：はい、先ほども触れましたが、SMS管理データセットの場合は、新規アロケーション処理の一環として、EOFレコードが自動的に書き込まれます。一方、非SMS管理データセットの場合は、EOFレコードの書き込みが行われません。

生徒：非SMS管理の順次データセットに対して、何か特別な方法でEOFレコードを書き込むことはできますか？

教授：EOFレコードを強制的に書き込む方法としては、新規アロケーション後にOUTPUTモードのOPEN/CLOSE処理を行うプログラムを実行する、または、新規アロケーション時にプライマリー・スペース量をゼロ設定する（例：SPACE=（TRK,（0,5）））などが一般的ではないでしょうか。もちろん、SMS管理データセットに移行すれば解決します。

生徒：前者の考え方は、まさに、ISPFOPT3.2の新規アロケーションで行われている方法ですね。

教授：はい、その通りです。バッチ・ジョブの場合、例えば、IEBGENERユーティリティー（PGM=IEBGENER）を利用して、SYSUT1DDステートメントでDUMMY指定を行い、SYSUT2DDステートメントで対象の順次データセットを指定すれば、OUTPUTモードのOPEN/CLOSE処理が可能です。

生徒：なるほど、自作のプログラムを作成しなくても、そのような方法が利用できるのですね。

教授：この場合、SYSUT1DDステートメントでは、対象データセットのDCB情報を明示指定する必要がありますから、注意してください。

z/OS V1R11の新機能

教授：前置きが長くなりましたが、今回お伝えしたいことはここからです。z/OSV1R11の新機能として、非SMS管理の順次データセットに対しても、新規アロケーション処理の一環として、先頭トラックへのEOFレコード書き込みが行われるようになりました。

生徒：ということは、従来のSMS管理順次データセットと同じ扱いができるようになったわけですね！

教授：はい、その通りです。独自の方法でEOFレコードを強制的に書き込まなくても、無効なデータを読み込んでしまう危険がなくなりました。ちなみに、z/OSV1R11環境で、非SMS管理の順次データセットを新規アロケーションし、その直後にDFSMSdssPRINTコマンドを実行した結果がありますので、図③-2を参照ください。先頭トラックへのEOFレコード書き込みが確認できます。

第１章-

❸


ISPF OPT3.2による新規アロケーション処理

生徒：ISPFのOPT3.2で行う順次データセットの新規アロケーションでは、このような問題を回避する目的で、特別な処理が行われていると聞いたことがあります。

教授：その通りです。非SMS管理データセットの場合に限り、アロケーション直後にOUTPUTモードでのOPEN/CLOSE処理を明示的に行うことで、先頭トラックにEOFレコードが強制的に書き込まれています。

生徒：非SMS管理の順次データセットでは、アロケーション処理によるEOFレコードが書き込まれないので、ISPFが機能を代替しているわけですね。

教授：はい。例えば、図③-1は、非SMS管理の順次データセット（BEANS.TEST.D0319A）をISPFOPT3.2で新規アロケーションした後、DFSMSdssPRINTコマンドを実行した結果です。下線部分（COUNT0227000601000000）が示すように、先頭トラックへのEOFレコード書き込みが確認できます。

PAGE 0001 5695-DF175 DFSMSDSS V1R10.0 DATA SET SERVICES 2010.078 23:32

PRINT DATASET（BEANS.TEST.D0319A） INDYNAM（WORK01）

ADR101I （R/I）-RI01 （01）, TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'PRINT '

ADR109I （R/I）-RI01 （01）, 2010.078 23:32:33 INITIAL SCAN OF USER CONTROL STATEMENTS COMPLETED

ADR016I （001）-PRIME（01）, RACF LOGGING OPTION IN EFFECT FOR THIS TASK

ADR006I （001）-STEND（01）, 2010.078 23:32:33 EXECUTION BEGINS

*** TRACK（CCHH） 02270006 R0 DATA 0000000000000000

COUNT 0227000601000000

ADR006I （001）-STEND（02）, 2010.078 23:32:33 EXECUTION ENDS

ADR013I （001）-CLTSK（01）, 2010.078 23:32:33 TASK COMPLETED WITH RETURN CODE 0000

ADR012I （SCH）-DSSU （01）, 2010.078 23:32:33 DFSMSDSS PROCESSING COMPLETE. HIGHEST RETURN CODE IS 0000

図③-1：DFSMSdssPRINTコマンドの実行結果（z/OSV1R10）

生徒：SMS管理データセットの場合は、同じような処理は行われないのですね？

教授：はい。その場合は、順次データセットをアロケーションする処理の一環としてEOFレコードが自動的に書き込まれますから、ISPFとしては特別な処理を行う必要がないわけです。

バッチ・ジョブによる新規アロケーション処理

生徒：ところで、バッチ・ジョブによる順次データセットの新規アロケーション処理は、どうなるのでしょうか？

4� 4�


第１章-

❸

教授：はい、その通りです。

教授：今回の内容はいかがでしたか？z/OSV1R10から後続リリースへ移行する際には、この新機能を活用いただければと思います。


第１章-

❸

//S1 EXEC PGM=IEFBR14

//DD1 DD DSN=TSO5.TEST.D0319,DISP=（NEW,CATLG）,

// UNIT=3390,VOL=SER=WRKI02,SPACE=（TRK,（1,0））,

// RECFM=FB,LRECL=80,BLKSIZE=0,DSORG=PS

//S2 EXEC PGM=ADRDSSU,REGION=4M

//SYSPRINT DD SYSOUT=*

//SYSIN DD *

PAGE 0001 5695-DF175 DFSMSDSS V1R11.0 DATA SET SERVICES 2010.078 23:05

PRINT DATASET（TSO5.TEST.D0319） INDYNAM（WRKI02） 00061012

ADR101I （R/I）-RI01 （01）, TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'PRINT '

ADR109I （R/I）-RI01 （01）, 2010.078 23:05:20 INITIAL SCAN OF USER CONTROL STATEMENTS COMPLETED

ADR016I （001）-PRIME（01）, RACF LOGGING OPTION IN EFFECT FOR THIS TASK

ADR006I （001）-STEND（01）, 2010.078 23:05:20 EXECUTION BEGINS

*** TRACK（CCHH） 00070006 R0 DATA 0000000000000000

COUNT 0007000601000000

ADR006I （001）-STEND（02）, 2010.078 23:05:20 EXECUTION ENDS

ADR013I （001）-CLTSK（01）, 2010.078 23:05:20 TASK COMPLETED WITH RETURN CODE 0000

ADR012I （SCH）-DSSU （01）, 2010.078 23:05:20 DFSMSDSS PROCESSING COMPLETE. HIGHEST RETURN CODE IS 0000

図③-2.新規アロケーション直後のDFSMSdssPRINTコマンド実行結果（z/OSV1R11）

生徒：この新機能は大変役立つものと思いますが、これに伴う影響は何かありますか？

教授：一般的にはありませんが、強いて言えば、非SMS管理の順次データセットを削除した後、リカバリーの目的などで、"ABSTR"指定（SPACE=（ABSTR,（primary-qty,address）））を利用したアロケーションを再度行ったとしても、先頭トラックにはEOFレコードが書き込まれていますから、もはや、削除前のデータを読むことはできません。

生徒：なるほど、ありがとうございます。

教授：それから、この新機能を受けて、z/OSV1R13ISPFでは、OPT3.2の新規アロケーション、及び、OPT3.4ALコマンド（z/OSV1R13ISPFの新機能で、OPT3.4から新規アロケーションが可能）の両方において、非SMS管理の順次データセットに対する独自のOPEN/CLOSE処理が廃止されました。

生徒：確かに、今となっては不要な処理ですね。

教授：この結果として、新規アロケーション直後に最終参照日が更新されなくなりましたので、OPT3.4で確認すると、最終参照日のカラムが***None***と表示されます。従来は、作成日と同じ情報が表示されていましたので、大きな変化になります。

生徒：なるほど、SMS管理の順次データセットと同じ扱いになったのですね。

50 51

第１章-

❸


教授：それは大変でした。でも、よい知らせがありますよ。z/OSV1R11から、ALLOCxxメンバーで設定されたオプションの動的変更がようやくサポートされるようになったのです。

生徒：やはり、SETALLOC=xxコマンドで行うのでしょうか？

教授：いいえ、そのコマンドは提供されません。動的変更を行うには、z/OSV1R11から利用可能になったSETALLOCコマンドを使って、変更対象のオプションを指定することになります。例えば、SETALLOCSYSTEM,VERIFY_UNCAT=LOGTRACKコマンドを実行するわけです。

生徒：なるほど、SETALLOCコマンドが新しくサポートされるのですね。その動的変更は、IPLを跨って有効でしょうか？

教授：よい質問ですね、答えは『いいえ』です。動的変更は、IPL期間中のみ有効で、再IPL後にも変更を引き継ぎたい場合は、ALLOCxxメンバーの修正・反映が必要です。

生徒：わかりました。ありがとうございます。では、現状のALLOCxxメンバーのオプション設定状況は確認できますか？

教授：はい、簡単にできますよ。これも同じく、z/OSV1R11からの新機能ですが、DALLOC,OPTIONSコマンドが利用できるのです。図③-3を参照してください。このコマンドでは、IPL時に有効となったALLOCxxメンバーのオプション設定値に加え、その後に実行されたSETALLOCコマンドによる動的変更が反映された形で表示されます。

図③-3.DALLOC,OPTIONSコマンドの実行結果（z/OSV1R12）

生徒：ところで、動的変更されたオプションは、すぐに有効になりますか？

第１章-

❸


2…　… ALLOCxx PARMLIBメンバー設定値の更新に関する新機能

PARMLIB（ALLOCxx）メンバーを活用していますか？

教授：PARMLIBのALLOCxxメンバーは、文字通り、デバイス・アロケーションの挙動に関する省略時値を定義するものですが、みなさんはどのように活用していますか？

生徒：はい、ALLOCxxメンバーといえば、TIOTサイズを調整したり、また、リカバリー・アロケーション（メッセージIEF238D）が発生した場合のポリシーなどを定義できると理解していますが、あまり積極的には利用していません。

教授：そうですか。私の経験では、かなり前の話ですが、"CATLG_ERRFAILJOB（YES）ERRORMSG（YES）"オプションを活用したことがあります。通常、ステップ終了時にDISP=CATLG処理を行う場合は、たとえ該当データセットが既にカタログ済みでも、処理は完了してしまいます。もちろん、カタログ処理はできないので、例えば、非SMS管理データセットの場合は、メッセージ"IEF287I（NOTCATLGD2）が出力されます。このようなイレギュラーな状況を避けるために、"CATLG_ERRFAILJOB（YES）ERRORMSG（YES）"オプションを明示指定することで、ジョブの実行を中止させるわけです。この組み合わせでオプションを指定すると、メッセージ"IEF378I（JOBFAILED-CATALOGDISPOSITIONERROR）が出力されます。

生徒：なるほど、確かに大事なポイントですね。その機能は、SMS管理データセットの場合も有効でしょうか？

教授：はい、このオプションは元々MVS/ESAV4.1の新機能だったのですが、しばらくして、SMS管理データセットも対象になりました。

ALLOCxxメンバー指定オプションの動的変更

教授：さて、前置きはこれくらいにして、本題に入りましょう。みなさん、PARMLIB（ALLOCxx）メンバーのサフィックスは、IEASYSxxメンバーの"ALLOC=xx"オプションで指定しますが、IPLを介さない動的変更は可能だと思いますか？

生徒：いえ、少なくとも、z/OSV1R10ではサポートされていないはずです。以前、z/OSV1R10移行時の非互換対応のため、"SYSTEMVERIFY_UNCAT（FAIL/TRACK/MSGTRACK/LOGTRACK）"オプションをテストする機会があったのですが、オプション変更のたびに再IPLが必要となり、結構苦労した覚えがあります。

52 53

第１章-

❸


生徒：いろいろと調べたのですが、それを非表示とするには、MPFExitやIEAVMXITの導入が必要ということで、あきらめました。

教授：そうですか。では、この新機能は朗報だと思います。実は、z/OSV1R11から、ALLOCxxメンバーにて、"SYSTEMREMIND_INTV（xxx）"オプションが新しく登場したのです。これを利用すれば、z/OSV1R10から出力されるようになったリマインダー・メッセージの発行インターバル（秒数）を調整することができます。もちろん、SETALLOCSYSTEM,REMIND_INTV=xxxコマンドによる設定・変更も可能です。

生徒：指定できるインターバルは、どれくらいでしょうか？

教授：指定可能なインターバルの範囲は『10～999』（秒）で、省略時値は変わらず90秒になります。さらに、『0』秒というユニークな指定も可能で、"SYSTEMREMIND_INTV（0）"オプションにより、リマインド・メッセージの出力自体を抑止する効果があるのです。

生徒：Exitなどの特別なカスタマイズなしでも、JOBLOGやSYSLOGに非表示となるわけですね。

教授：はい。おまけに、MPFLSTxxメンバーで現在指定しているリマインダー・メッセージの表示抑止も不要になります。

生徒：それは助かります。次回のz/OSマイグレーションでは、ぜひ対応したいと思います。

教授：言い忘れましたが、リマインダー・メッセージIEF882Eは、別のWTORメッセージIEF433DやIEF434Dへの応答が遅延した時も出力されます。

生徒：z/OSV1R11のALLOCxxメンバーは、運用に役立つ新機能が満載ですね。楽しみです！

教授：ぜひ、新機能の活用を検討してみてください。これまでの悩みが一気に解決するかも知れませんよ！

第１章-

❸


教授：いいえ、SETALLOCコマンド完了後に開始されるアロケーションから有効になります。つまり、既存のアロケーションには影響を与えません。また、TIOTサイズの変更は、次のジョブ・ステップ開始時から初めて有効になります。

生徒：ALLOCxxメンバーの全てのオプションが動的変更可能と考えてよろしいですか？

教授：いいえ、例外があります。新規データセット作成時に指定された"yyddd"形式（2桁年号）の満了日をどう扱うかは、2DGT_EXPDTオプションで規定されていますが、それだけはSETALLOCコマンドによる動的変更の対象外ですから、注意してください。

ALLOCxxメンバーの新規オプション

教授：ALLOCxxメンバーの話をしてきたので、最後に、z/OSV1R11の新機能にも少し触れてみましょう。

生徒：楽しみです。教えてください。

教授：既に経験されたかもしれませんが、z/OSV1R10からは、リカバリー・アロケーション発生時のWTORメッセージIEF238Dへ応答が遅延した場合、90秒毎にリマインダー・メッセージIEF882Eを新しく出力するようになりました。図③-4を参照してください。この目的は、システムの内部的なENQコンテンション発生を警告・回避することです。

図③-4.リマインダー・メッセージIEF882Eの出力

生徒：はい、z/OSV1R10移行時に私も経験しました。このメッセージは、記述子コード（Descriptorcode）が11で高輝度（赤色）ということもあり、オペレータさんから問い合わせを受けたのです。オンライン時間帯は、オペレータさんがユーザーから依頼を受けてWTORメッセージに応答する運用ということで、結局、MPFLSTxxメンバー指定を利用してコンソール表示を抑止することにしました。つまり、移行前と同じような挙動にカスタマイズしたのです。

教授：なるほど、同じような話は他でもありそうですね。では、JOBLOGやSYSLOGへのメッセージIEF882E出力は、どう対応されましたか？

54 55

第１章-

❸


図③-6.“NOREPLYU”指定によるICKDSFプログラム実行

生徒：もちろん、その機能は知っています。でも、その機能を利用するには、SYSINDDステートメントで、VERIFYパラメータを指定する必要があると思います。

教授：その通りです。VERIFY（volser）パラメータ、または、VERIFY（*NONE*）パラメータを指定することが前提になります。つまり、オフライン・モードでINITコマンドやREFORMATコマンドを実行する際、NOVERIFYパラメータを指定した場合には、PARM='NOREPLYU'パラメータが無効になりますから、ICK003DWTORメッセージ出力は避けられません。

生徒：はい、私もそのように理解しています。ただ、不便に感じているのは、例えば、テスト環境の構築時など、既存のVOLID（VOLSER）を無視して多量のDASDボリュームを素早くオフラインINIT処理したい場合でも、そのWTORメッセージ出力を回避するには、DASDボリューム毎にVERIFY（volser）パラメータの指定が必要になる点です。

教授：なるほど、それなら朗報がありますよ。ICKDSFR17に対して、APARPM17764のPTFを適用することで、新機能が提供されました。

生徒：どんな新機能でしょうか？

教授：オフライン・モードによるINIT処理を行なう際、図③-7のように新しく提供されたPARM='NOREPLYU,FORCE'パラメータを指定すると、NOVERIFYパラメータを指定した時でも、ICK003DWTORメッセージ出力が回避できるのです。

図③-7.“NOREPLYU,FORCE”指定によるICKDSFプログラム実行

生徒：それは便利です。特に、先ほど私が挙げた例では、PARM='NOREPLYU,FORCE'パラメータとNOVERIFYパラメータの組み合わせで、ICK003DWTORメッセージ出力を避けることができるわけですね！

教授：はい、その通りです。機会があったら、ぜひ活用してみてください。

第１章-

❸


3…　… ICKDSF WTORメッセージICK003Dの出力抑止に関する新機能

ICKDSFプログラムの機能

教授：ICKDSFプログラムは利用していますか？

生徒：はい、DASDボリュームの初期設定を行う時にはINITコマンドを使用しています。

教授：その他にも、DASDボリュームのVOLID（VOLSER）を変更（CLIP）する時には、REFORMATコマンドを使用していると思います。いかがでしょうか？

生徒：確かにそうです。あまり使用頻度は高くありませんが、ICKDSFプログラムにしかできないことはたくさんあると思います。

教授：おっしゃる通りです。例えば、REFORMATコマンドにはIPLテキストを作成する機能もありますから、スタンド・アローン・ダンプ・プログラムの生成などでも活躍しています。もちろん、導入作業の一環で、z/OSのIPLテキストも作成された経験があるかと思います。

WTORメッセージICK003Dの出力を回避する方法

教授：ところで、オフライン・モードでINITコマンドやREFORMATコマンドを実行した場合、図③-5のようなWTORメッセージが出力され、UまたはTの応答が必要なことはご存知ですか？

図③-5.WTORICK003Dのメッセージ・テキスト

生徒：はい、知っています。以前担当していたお客様では、メッセージ自動化処理を利用して応答されていました。多数のDASDボリュームを一括処理するような場合、このICK003DWTORメッセージに人手で応答するのは、骨の折れる作業だと思います。

教授：図③-6のように、実行JCLのEXECステートメントでNOREPLYUパラメータを指定すれば、このWTORメッセージを出力させないことができます。この機能は利用していませんか？

5� 5�

教授：その通りです。でも、そのような従来処理には、大きく2つの課題があったのです。わかりますか？

生徒：NOSWAP属性（Non-SWAPPABLE）のアドレス空間が考慮されていないことでしょうか？

教授：そうです。さらに、論理スワップ対象のアドレス空間を決める際、AUXストレージ（スロット）の消費状況のみに着目していた点も課題でした。

生徒：それらの課題は、既に解決されたのでしょうか？

教授：はい、これらに関しては、z/OSV1R10で機能変更が行なわれました。つまり、（1）AUXストレージ（スロット）に加えてCSフレームの消費速度も合わせて監視を行うことで、論理スワップ対象のアドレス空間を決める、（2）システムの省略時解釈として、NOSWAP属性（Non-SWAPPABLE）のアドレス空間も考慮する（ディスパッチ不可の対象にする）、ように変わったのです。

生徒：『省略時解釈』ということは、システムの挙動がカスタマイズできるということでしょうか？

教授：その通りです。PARMLIBのIEAOPTxxメンバーに、"STORAGENSWDP=YES"または"STORAGENSWDP=NO"いずれかのパラメータが新しく指定できるようになりました。この省略時解釈は前者（STORAGENSWDP=YES）で、その場合、NOSWAP属性（Non-SWAPPABLE）のアドレス空間もディスパッチ不可の対象にすることができます。

生徒：私の知る限り、メッセージ自動化やジョブ・スケジュラーの中には、NOSWAP属性で稼働しているものがあるかと思います。省略時解釈（STORAGENSWDP=YES）の場合、z/OSV1R10以降では、それらのアドレス空間もディスパッチ不可になる可能性があるわけですね。

教授：はい、サービス・クラスとして"SYSTEM"（SCL=SYSTEM）が割振られたアドレス空間は対象外なのですが、そうでない場合には、ご指摘のような懸念もあります。サーバー的な振る舞いをするアドレス空間がディスパッチ不可になることを避けるためには、"STORAGENSWDP=NO"パラメータを明示指定することで対応できます。つまり、そうすることで、z/OSV1R9までの挙動が踏襲できるわけです。

第１章-

❸


第１章-

❸


4…　… IEAOPTxx PARMLIBメンバーのパラメータ表示に関する新機能

IEAOPTxx PARMLIBメンバーとは

教授：PARMLIBのIEAOPTxxメンバーはご存知でしょうか？

生徒：IEAOPTxxメンバーは、SRMの省略時挙動をシステムの稼働環境に合わせてカスタマイズ（チューニング）するために利用すると思いますが、WLMゴール・モードへの変更や、64ビット・モード（z/Architectureモード）になって拡張記憶域（ES）が廃止されたことで、指定可能なパラメータも随分と変わってきたはずです。

教授：そうですね。約20年前のOS（MVS/ESAV4.2：1992年）とz/OSV1R12をクイックに比較してみたのですが、当時との共通パラメータは、ERV/RMPTTOM/MCCAFCTH/CPENABLEなど、10種類程度しかありません。一方、z/OSV1R12にしかないパラメータが、なんと、20種類ほどもありました。

生徒：そこまでは知りませんでした。IEAOPTxxは移り変わりの激しいメンバーというか、まさに、SRMに関する機能発展の歴史を物語っているのですね。

教授：はい、確かにその通りです。では、最近の新規パラメータをひとつだけご紹介しましょう。

z/OS V1R10の新規パラメータSTORAGENSWDP

教授：AUXストレージ不足（IRA200EAUXILIARYSTORAGESHORTAGE）の経験はありますか？

生徒：はい、AUXストレージ不足が起きると、ログオン処理や新規ジョブの稼働ができなくなりました。

教授：そうですね。使用率が70%を超えて、AUXストレージ不足（IRA200E）が発生した場合、z/OSV1R9までは、SWAP属性（SWAPPABLE）のアドレス空間のみを対象にして、AUXストレージ（スロット）の消費速度が最も大きいものを論理スワップしていました。

生徒：論理スワップさせることで、AUXストレージの消費に歯止めをかけるわけですね。

5� 5�

第１章-

❸


生徒：これは便利ですね。ぜひ活用させていただきます。

教授：該当のパネル（RMF-OPTSettings）では、現在有効なIEAOPTxxメンバーのサフィックス（OPT）をはじめ、活動化されたタイム・スタンプ（Time）、パラメータ名（Parameter）、省略時値（Default）、有効になっている値（Value）、値の単位（Unit）、簡単なパラメータ解説（Description）などが表示されます。

生徒：活動化されたタイム・スタンプ（Time）は、IPL時のタイム・スタンプを示すのでしょうか？

教授：いいえ、そうではありません。IPL以降にSETコマンドで動的変更していない場合は、N/Aと表示されますので注意してください。

生徒：同じような機能は、RMFのISPFパネルからでも利用可能でしょうか？

教授：はい、利用できます。【RMFMonitor IIPrimarySelectionMenu】で"L.4"を実行するか、または、【RMFMonitor IILibraryListandOPTSettingsSelectionMenu】で"4OPT"を選択してください。z/OSV1R11からは、これまでの【RMFMonitorIILibraryListSelectionMenu】（メニュー・タイトル）が、【RMFMonitorIILibraryListandOPTSettingsSelectionMenu】に改名されています。

生徒：なるほど。LibraryListのメニューでは、従来、Link/LPA/APFリストを表示しましたが、z/OSV1R11からは、そのメニューに新機能（OPT）が組み込まれたのですね。

教授：その通りです。この新機能が提供されたことで、z/OSV1R11以降では、前述のWLMOPTツールが機能拡張されませんので、その点も注意が必要です。

生徒：わかりました。今日は、役に立つ新機能をご紹介いただき、ありがとうございました。大変参考になりました。

第１章-

❸


新機能: IEAOPTxx PARMLIBメンバーのパラメータ表示

教授：ところで、PARMLIBのIEAOPTxxメンバーで、どのようなパラメータ（設定値）が有効になっているか、知りたいとは思いませんか？

生徒：もちろん賛成です。でも、私の知る限りでは、例えば、DISPLAYコマンドのような方法は提供されていないと思います。省略時値なども含めて情報が得られれば、マイグレーション（バージョンやリリース更新）時の参考にもなると思います。

教授：そうですね。以前は、WLMOPTという名前のツール（WLMOPTParameterViewer）がダウンロードできるようになっていたので、利用されたことがあるかも知れません。

生徒：そのツールは、聞いたことがあります。確か、中身はREXXでコーディングされていたかと。

教授：その通りです。でも、いよいよ、z/OSV1R11からは、製品の標準機能として同じようなことができるようになったのです。

生徒：それは助かります。具体的に教えてください。

教授：z/OSV1R11の新機能は、RMFモニター II（RMFMON）に対して組み込まれ、コマンド・ラインでOPTコマンドを実行することで、簡単に、IEAOPTxxメンバーのパラメータ状況を表示することができます。（図③-8参照）

図③-8.z/OSV1R12RMFMON出力パネル例（OPTコマンド実行結果）

�0 �1

第１章-

❸


図③-10.ジョブログの出力結果（一部）・・・z/OSV1R10の場合

教授：もちろん、出力形式やメッセージが変わったことで、ジョブログを吸い上げて加工しているようなケースでは、処理の見直しが発生してしまいます。でも、一般的には、機能改善として受け入れられるのではないでしょうか。

生徒：ところで、教授。この変更には、どのような背景があるのでしょうか？

教授：よい質問ですね。これまで、メッセージIEF374I/IEF376Iで示されるCPU時間、SRB時間は、最大値が"9999"分（MIN）となっており、それを超えた場合には、下4桁のみが表示されていました。つまり、長時間に渡り連続して稼働するジョブへの配慮が不足していたというわけです。変更後の出力形式では、最大"99999"時間（HR）までサポートされます。

生徒：なるほど、果たしてそこまでCPU時間を消費するかどうかはわかりませんが、連続稼働をサポートするためには必要な変更だと思います。ありがとうございます。

連続稼働をサポートするための新機能

生徒：先ほど教えていただいたジョブログと同じように、連続稼働をサポートするために最近行なわれた機能変更はありますでしょうか？

教授：はい、他にもあるかも知れませんが、今日は、SMFタイプ30レコードの件をお話しましょう。

生徒：よろしくお願いします。

教授：従来、SMFタイプ30レコードのパフォーマンス・セクションでは、消費されたサービス・ユニット量が、図③-11で示すような6種類のフィールドに記録されています。

第１章-

❸


5…　… SMFタイプ30レコード（パフォーマンス・セクション）に関する新機能

ジョブログの出方が変わった！？

生徒：z/OSV1R12へ最近移行したのですが、ジョブログの出方が図③-9のように大きく変わったようです。教授は、既にご存知ですよね？

図③-9.ジョブログの出力結果（一部）・・・z/OSV1R12の場合

教授：ええ、もちろんです。ちなみに、従来のジョブログを図③-10に掲載しましたが、見てお分かりのように、変更点としては大きく3つあります。

（1）CPU時間、SRB時間の出力が、MIN/SEC表示（メッセージIEF374I/IEF376I）から、z/OSV1R12ではHR/MIN/SEC表示（メッセージIEF032I/IEF033I）に変更

（2）従来1行で出力されていたメッセージIEF374Iが、z/OSV1R12ではメッセージIEF032Iに変更され、かつ、3行に分割

（3）従来1行で出力されていたメッセージIEF376Iが、z/OSV1R12ではメッセージIEF033Iに変更され、かつ、2行に分割

生徒：確かにそうですね。特に変更点（2）はありがたいです。これまでは、VIRT/SYS/EXT/SYS部分の内容を確認するのに、ジョブログをスクロール（PF11）していましたが、z/OSV1R12では不要になりました。

�2 �3

第１章-

❸


教授：例えば、SMF30SRVフィールド（4バイト）に対しては、SMF30SRV_L（8バイト）が提供されます。他のフィールドに対しても、同様に、"_L"を付加した新しいフィールド名になります。

生徒：新しく定義されたフラグ・バイト（SMF30INV）は、どのように利用されるのでしょうか？

教授：はい、例えば、SMF30SRV（4バイト）フィールドが一回りすると、SMF30INVフラグ・バイト内の、SMF30SRV_INVビット（X'80'）をONにすることで、その事実を示します。他のフィールドに関しても全く同じような考え方で、それぞれ、別のビット（全部で6種類が用意されている）がONされるわけです。

生徒：なるほど。長時間に渡り連続稼働するジョブをサポートするためには、新しく提供された8バイト・フィールドを利用することで、より正確なサービス量が把握できますね。

教授：その通りです。従来の4バイト・フィールドを継続利用する場合でも、新しく定義されたフラグ・バイト（SMF30INV）の内容を吟味することで、より正確性を期すことが可能になるわけです。

生徒：この機能改善もまた、連続稼働をサポートする力強い見方になりますね！

教授：忘れないうちにお伝えしておきますが、この新機能は、z/OSV1R10に対しても、SRMAPAROA25540とSMFAPAROA26832の両方を組み合わせることで、同様に提供されます。


第１章-

❸


図③-11.消費されたサービス量を記録するフィールド

でも、これらのフィールドは、長時間に渡り連続稼働するジョブを考慮すると、必ずしも十分な設計とは言えなかったのです。

生徒：それは、どのような理由からでしょうか？

教授：はい、これまで大きく2つの課題が指摘されていました。

（課題1）各フィールドの最大値がX'FFFFFFFF'のため、最大"4GB"までのサービス量しか正しく記録できない

（課題2）最大値を超えるとゼロに戻ってしまい、その後も継続して値は記録されるが、オーバーフローが発生したという事実は判別できない

生徒：なるほど、そういうことですね。お客様によっては、これらの消費サービス量を課金などの目的で利用されるケースもあろうかと思いますので、正確な値をいつでも記録できるのはとても重要なことだと思います。

教授：その通りです。これらの課題を解決するために、z/OSV1R11では、SRMコンポーネントとSMFコンポーネントが協力して、次のような機能改善が行なわれました。

（改善（1））SMFタイプ30レコードとして、従来のフィールド（4バイト）に相当する新しいフィールド（8バイト）を定義し、4バイト・フィールドが一回り（オーバーフロー）した後も、新規8バイト・フィールドには正しい値を継続して記録する

（改善（2））従来の4バイト・フィールドに記録された値が最大値を超えてゼロに戻った（一回りした）場合、新しく定義したフラグ・バイト（SMF30INV）に対して、そのことを記録する

生徒：新規フィールド名は、どうなりますか？

�4 �5

第１章-

❸


生徒：ということは、DDCONS（NO）パラメータを明示指定するほうがベターですね？

教授：はい、その場合は、EXCPセクションのマージ作業を行なわないので、先ほど説明したような挙動は回避できますが、記録されるSMFタイプ30のレコード量が増大してしまう懸念はあります。特に、EXCPセクションの重複が多いほど、その傾向が顕著に現れるはずです。

SMS候補ボリュームに対する『Empty EXCPセクション』生成の抑止

生徒：ありがとうございます。ところで教授、今日のお話は、このあたりの機能に関係しているのでしょうか？

教授：そうですね、そろそろ本題に入りましょう。みなさん、SMFタイプ30レコードに対して、必ずしも有用ではないEXCPセクションが生成されているとしたら、どう思いますか？

生徒：それは、SMFタイプ30レコードの出力量も意味なく増加しますし、もしマージ対象の条件を満たしていれば、省略時解釈のDDCONS（YES）パラメータが有効な場合には、CPU浪費の悪影響などもあると思います。

教授：確かに、その通りです。実は、SMFタイプ30レコードのサブ・タイプ2/3/4/5におけるEXCPセクションは、以前から、SMS候補ボリューム全てに対して生成されているのです。

生徒：SMS候補ボリュームとは、データクラスで指定するボリューム・カウントに相当するものですね？

教授：そうです。例えば、ボリューム・カウントが59で、先頭ボリュームだけがアロケーションされた場合、該当ボリュームに関するEXCPセクションはもちろん生成されますが、残り58個の候補ボリューム全てに対しても、EXCPセクションが生成されてしまうのです。

生徒：でも、アロケーションされていない58個のSMS候補ボリュームは、実際には未使用のわけですから、いったいどのような内容が記録されるのでしょうか？

教授：はい、DD名（SMF30DDN）に関する情報のみが記録され、その他のフィールドは全てゼロとなります。従って、このようなEXCPセクションのことを『EmptyEXCPセクション』と呼んでいます。具体的には、図③-12と図③-13を参照してください。

第１章-

❸


6…　… SMFタイプ30レコード（EXCPセクション）に関する新機能

SMFタイプ30レコードのEXCPセクション

教授：今回も、前回から引き続き、SMFタイプ30レコードについて考えましょう。

生徒：前回は、パフォーマンス・セクションの新機能とメリットについて教えていただきましたが、今回はどのようなお話でしょうか？

教授：今回は、EXCPセクションに関する話題です。みなさん、SMFタイプ30レコードのEXCPセクションはご存知ですか？

生徒：はい、DDステートメント毎のI/O統計情報（EXCPカウント）を求める際に利用したことがあります。

教授：そうですね。EXCPカウント以外にも、データセットのブロック・サイズや装置番号、装置タイプなどの情報が記録されています。

生徒：そういえば、以前、長時間稼働のジョブを停止する際、なかなか処理が完了せず、CPUも多量に消費するといったことがありました。当時、その原因は、EXCPセクションをマージする作業が行なわれるためと聞きました。

教授：なるほど。確かに、DB2やDFSMShsmなど、多数のデータセットを動的アロケーションするようなケースでは、同じような報告が以前ありましたね。

生徒：このような挙動は、システム設定パラメータに依存して発生するのでしょうか？

教授：はい、おそらく、PARMLIB（SMFPRMxx）メンバーのDDCONS（YES）パラメータ指定、つまり、省略時値を利用していたのだと思います。その場合、SMFのインターバル・レコーディング処理や該当ジョブの停止処理では、SMFタイプ30レコードの重複したEXCPセクションをマージする作業が内部的に行なわれます。そのため、JCLアロケーション、動的アロケーションを問わず、データセットを多数アロケーションする長時間稼働ジョブなどにおいては、ご指摘のような挙動が発生してしまいます。

生徒：重複したEXCPセクションとは、どのように判断されるのですか？

教授：EXCPセクションに記録される情報は、それほど多くはありませんが、DD名、装置クラス、装置タイプ、装置番号などが同一の場合に重複と見なされ、それらがマージされて一つのエントリーが生成されるわけです。

��

第１章-

❸


生徒：これは、とても価値ある新機能ですね！

教授：はい、SMS候補ボリュームを多数定義しているような環境では、ぜひ、おすすめしたい新機能です。

生徒：SMS候補ボリュームに対する『EmptyEXCPセクション』が生成されなくなるおかげで、SMFタイプ30レコード量の削減や、DDCONS処理の効率化が大いに期待できると思います。

教授：ひとつ、忘れないうちにお知らせしておきますが、動的アロケーションに関してEMPTYEXCPSEC（SUPPRESS）パラメータを活用するためには、SMFAPAROA32914（対象：z/OSV1R10,V1R11,V1R12）が必要です。このAPAR/PTFが未適用だと、JCLアロケーションでのSMS候補ボリュームしか対象になりません。


第１章-

❸


図③-12.先頭ボリュームに対して生成されたEXCPセクション（一部抜粋）

図③-13.残りのSMS候補ボリュームに対して生成されたEXCPセクション（58個分繰り返し）

生徒：これまで『EmptyEXCPセクション』のことは知りませんでしたが、とても無駄のように思えてしまいます。また、図③-13を見ると、SMS候補ボリュームに対して生成された複数の『EmptyEXCPセクション』は、マージ対象にもなりますね。

教授：はい、まさにご指摘のようなコメントは、お客様からの機能改善要望として寄せられ、IBM開発部門による努力の結果、z/OSV1R10では、ついに、この『EmptyEXCPセクション』生成を抑止することができるようになったのです！

生徒：その新機能を利用するには、どのように指定すればよいのでしょうか？

教授：z/OSV1R10からは、PARMLIB（SMFPRMxx）メンバーに、EMPTYEXCPSEC（NOSUPPRESS/SUPPRESS）パラメータが新しく提供されました。省略時値は、EMPTYEXCPSEC（NOSUPPRESS）となり、従来同様、SMS候補ボリューム全てに対して『EmptyEXCPセクション』が生成されます。

生徒：では、EMPTYEXCPSEC（SUPPRESS）パラメータを明示指定することで、『EmptyEXCPセクション』の生成を中止できるわけですね。

教授：その通りです。ただし、その場合は、DDDUMMY指定やスプール・データセット（SYSOUTなど）に対しても同様に、『EmptyEXCPセクション』が未生成となりますから、問題ないことを事前に確認しておいてください。

��

第１章-

❸


教授：SYS1.DUMPxxデータセットの場合は、"IEA911ECOMPLETE/PARTIALDUMPONSYS1.DUMPxx..."となるのに対し、動的アロケーションの場合は、"IEA611ICOMPLETE/PARTIALDUMPONdsname..."というメッセージが出力されるのです。また、記述子コード（Descriptorcode）の違いから、メッセージIEA611IはIEA911Eと異なり、高輝度表示されないという特徴があります。

データセット名の省略時パターンに関する新機能

教授：前置きが長くなりましたが、そろそろ本題に入りましょう。今日は、SVCダンプ・データセットの動的アロケーションで使用されるデータセット名について考えてみます。

生徒：それは、DUMPDSコマンド（DDNAME=name-pattern）で定義するデータセット名のことですね。

教授：はい、その通りです。指定されるデータセット名のパターンは、テキストとシステム・シンボルを含みますが、その省略時解釈（SYS1.DUMP.D&YYMMDD..T&HHMMSS..&SYSNAME..S&SEQ.）が問題なのです。

生徒：教授、それが何故、問題になるのでしょうか？

教授：データセット名の第5修飾子（&SYSNAME.）に注目してください。

生徒：SYSNAMEは、PARMLIB（IEASYSxx）メンバーで指定されるシステム名（SYSNAME=sysname）だと思います。

教授：そうです。SYSNAMEは、1～8桁の英数字（$,@,#を含む）ですが、数字が先頭の名前も許されているのです。

生徒：なるほど、もしSYSNAMEの先頭が数字の場合は、第5修飾子が数字で始まるので、無効なデータセット名になってしまうということですか。

教授：その通りです。その状態でDDALLOC=ACTIVEコマンドが実行されると、"SYSNAMEBEGINSWITHNUMERIC.RESPECIFYNAMEPATTERN.RETRYDUMPDS"という結果になり、SVCダンプ・データセットの動的アロケーション機能が活動化できません。

生徒：つまり、数字で始まるSYSNAMEが割り当てられた環境では、省略時解釈のデータセット名・パターンが利用できないという制約があるのですね。

第１章-

❸


7…　… SYS1.DUMPデータセットの動的アロケーションに関する新機能

SVCダンプ・データセットの動的アロケーション機能

教授：取得されたSVCダンプをDASDデータセットに書き込むための方法が2種類あるのは、ご存知ですか？

生徒：はい、事前にデータセットを作成しておく方法と、必要な時に自動的（動的）に作成する方法があると思います。

教授：その通りです。前者の方法では、SYS1.DUMPxx（xx：00-99）という固定のデータセット名が利用され、また、後者の方法とは異なり、SVCダンプを格納するために十分な大きさのセカンダリー・アロケーション量を事前に定義しておく必要があります。

生徒：後者の方法は、いつごろから利用可能になったのでしょうか？

教授：SVCダンプ・データセットの動的アロケーション機能は、1990年台中頃のMVS/ESAV5.1で提供された新機能ですから、もう15年以上前になりますね。最近では、かなり普及してきたのではないかと思います。

生徒：システムの省略時解釈としては、どちらの方法が利用されるのでしょうか？

教授：よい質問ですね。省略時解釈の場合は、前者の方法、つまり、事前作成されたSYS1.DUMPxxデータセットが利用されます。後者の動的アロケーション機能を利用するためには、DUMPDSコマンド（DDALLOC=ACTIVE）を明示的に実行する必要があります。

生徒：そういえば、私が担当したプロジェクトでも、SYS1.PARMLIB（COMMNDxx）メンバーで、DDNAME=name-pattern、DDADD,VOL=volser、DDALLOC=ACTIVEという一連のコマンドを実行している場合がありました。

教授：SVCダンプ・データセットの動的アロケーション機能を利用する場合は、出力されるメッセージが変わりますので、自動化処理では注意してください。

生徒：といいますと？

�0 �1

第２章

IMSはお客様アプリケーションを含む多くのシステム資源の互換性を保持するマイグレーション・パスを提供しています。ただし、V10以降IMS独自のセキュリティー保護機能であったSMU（Security…Maintenance…Utility）が廃止され、RACF等のz/OS環境が提供するセキュリティー保護機能を利用するよう統合されました。従って、V10以降にマイグレーションする場合、既存IMS環境のSMUセキュリティーをRACFセキュリティーに移行するという作業が必須になります。そこで第2章では、「SMU移行の勘所」と題し、SMUセキュリティーからRACFセキュリティーへの移行時のポイントや、マイグレーションに役立つユーティリティーなどをご紹介します。また、多くの環境で実際に使用されているSMUセキュリティーの移行手順をご紹介します。

●

・第2章・

IMSマイグレーションの効率化のために

SMU移行の勘所 SMUからRACFへの移行って?

移行してみよう ! 端末に対するコマンド・セキュリティー移行の勘所

移行してみよう !TYPE 1 AOIセキュリティー移行の勘所

1

2

3

教授：はい。そこで、その制約を排除するような機能拡張が行なわれたのです。

生徒：具体的に教えてください。

教授：z/OSV1R13からは、SYSNAMEが数字で始まる場合、省略時解釈のデータセット名・パターンが次のように変わりました。第5修飾子に注目してください。

　　　1.SYSNAMEが1～7桁の場合・・・　　　SYS1.DUMP.D&YYMMDD..T&HHMMSS..S&SYSNAME..S&SEQ.

　　　2.SYSNAMEが8桁の場合・・・　　　SYS1.DUMP.D&YYMMDD..T&HHMMSS..S&SYSNAME（2:8）..S&SEQ.

生徒：なるほど、1の場合は、第5修飾子の先頭に"S"が付加されるので、SYSNAMEが数字で始まる場合でも問題なくなります。安心して、動的アロケーション機能の省略時解釈が利用できそうです。

教授：はい、その通りです。これまでの制約が排除されたわけです。ただし、2の場合のように、SYSNAMEが数字で始まる8桁の場合は、第5修飾子として、先頭の数字が"S"に置換されたSYSNAMEが使われますから、その点は注意が必要ですね。


教授：忘れないうちにお伝えしておきますが、この新機能は、APAROA31627のPTFを適用することで、z/OSV1R9からV1R12に対しても提供されます。

生徒：今日は、役に立つ新機能をご紹介いただき、ありがとうございました。大変参考になりました。

教授：お役に立てたようで、よかったです。

みなさん、1章-③「使い勝手を向上するz/OS新機能（Ease-Of-Use）」は、いかがでしたか。1章-①「USERMOD廃止のチャンス到来」や1章-②「z/OSV1R10移行を支援するスマート機能」とは一味違う特集になりましたが、移行することで得られる新機能のメリットについて、少しでもご理解いただければ幸いです。

第１章-

❸


�2

IMSマイグレーションの効率化のために①…SMU移行の勘所　SMUからRACFへの移行って？

�3


第２章-

❶

教授：まず、本番系システムでもテスト系システムでもオペレーター端末からIMSコマンドを発行するような運用は一般的ですよね。しかし、省略時許可されているごく少数のIMSコマンド以外のIMSコマンドについては、明示的にSMUで許可を与えないと、IMSマスター端末やWTOR以外から投入できません。そのため、必然的に1はよく使用されることになります。また、IMSコマンドを発行するためのDL/Iコールを実装したタイプ1AOと呼ばれる自動化プログラムもよく利用されていますが、明示的にSMUでIMSコマンド発行許可を与えることが必須です。だから、3も良く見かけるというわけです。これは4のTCO機能からのコマンド発行に関しても同様です。

生徒：なるほど！つまり良く利用される運用形態において、「省略時設定ではできないことをSMU設定で許可する」という理由があるわけですね。

教授：その通りです。一方、他のSMUセキュリティーはどちらかというと「省略時設定では制約がないことをSMU設定で制限する」という意味を持っていますので、そのようなセキュリティー基準を持つIMS環境でなければ実装されません。ただし、もちろん使用している場合は、他のSMUセキュリティーと同様にRACFセキュリティーへの移行対象となります。

生徒：実際どんなSMUセキュリティーを実際に使用しているかについては、IMS定義のどこを見れば分かるのでしょうか。

教授：もっとも基本になるのはSMUコントロール・ステートメントです。例えば、端末追加やアプリケーション追加後のお作法として、以下のようなSMUコントロール・ステートメント指定のあるIMSユーティリティー（プログラム名：DFSISPM0）を実行している運用手順があるはずです。実はこのステートメント指定がSMUセキュリティー設定そのものであり、どう頑張ってもここに指定してある以上のSMUセキュリティー保護を行うことはできません。

図①-2.SMUコントロール・ステートメントの例

第２章-

❶

SMU移行の勘所SMUからRACFへの移行って？1

生徒：今度のIMSのバージョン・アップ・プロジェクトで、IMS独自のセキュリティー機能からz/OSRACFセキュリティー機能への移行部分を担当することになりました。でもそもそも移行元のIMS独自のセキュリティーが実は良く分かっていなくて・・・

教授：V9が最終サポートとなるSMU（SecurityMaintenanceUtility）のことですね。SMUはそれほど難しいセキュリティー機能ではありませんよ。

生徒：そうです、それです！えーと、まずSMUも「セキュリティー」と呼ばれるからには、IMSを不正な利用や誤用から保護する機能、と考えてよいのでしょうか？例えば、権限のないユーザーがIMSを勝手にシャットダウンできないようにするとか？

教授：その通りです。簡単にまとめれば、SMUでは以下のセキュリティー保護を行うことができます。実はこれでほぼすべてといっても良いでしょう。

1.論理端末に対し、あるIMSコマンドの入力を許可する2.論理端末に対し、あるIMSトランザクションの入力を許可する3.自動化プログラム（タイプ1AO）に対し、あるIMSコマンドの投入を許可する4.TCO（TimeControlledOperation）機能に対し、あるIMSコマンド／ IMSトランザクションの入力を許可する

5.論理端末に対し、IMS使用前のサインオン検査を実施する6.従属領域が使用できる資源（PSB、トランザクション、論理端末）を制限する7.IMSコマンドやIMSトランザクション使用時に、合わせてパスワードを入力させ

てその組み合わせを検査する

図①-1.SMUが提供するセキュリティー保護機能

生徒：なるほど、いろいろなIMS操作の保護を行うのですね・・・この中で、特によく使用されている機能はありますか？

教授：そうですね、私の経験では1と3の利用を良く見かけます。また、TCO（Time-ControlledOperations）機能を利用している場合は4も必ず存在します。

生徒：何かよく使われている理由や背景があるのでしょうか？

�4


�5


第２章-

❶

教授：その通りです。ここで活動化を指定されていないセキュリティーは、例えSMU定義があったとしても移行対象にする必要がないわけです。少し細かい話になりますが、このIMS生成マクロ指定は図①-4に示すようにIMSリスタート時のオプション指定で上書きすることもできます。もしマクロ指定と異なるセキュリティー動作が見られるようであれば、念のためリスタート時のオプション指定も確認してみてください。逆に言えばSMUの有効化／無効化をIMS生成なしでリスタート時に切り替えられるので、特にSMU移行テスト時などに覚えておくと便利ですよ。

図①-4.IMSリスタート・コマンドによるSMU活動化の制御

生徒：うむむ、SMUについてはだんだん分かってきた気がします。でもこれをRACFセキュリティーに移行するとなると、どうやっていいのか・・・

教授：具体的な移行については次回以降ご紹介するとして、今回はSMUセキュリティーからRACFセキュリティーへの移行に関する一般的な考え方について理解しておきましょう。さて、まずRACFセキュリティーといえば、どういう仕組みを思い浮かべますか？

生徒：そうですね、えーと、例えばデータセット保護やMVSコマンド保護がありますよね。

教授：どうやって実現されている？

生徒：例えばデータセット保護であればデータセット・プロファイルを登録して対象ユーザーに必要な権限を与えますし、MVSコマンド保護であってもOPERCMDSクラスに保護したいMVSコマンドのプロファイルを登録して特定のユーザーに権限を与えますね・・・あ！ということはIMSも一緒なのかな？

教授：その通り、同じRACFセキュリティーなのですから、IMSも全く同じ方法でIMS資源を保護します。つまり、特定のRACFクラスにIMS資源を表すプロファイルを登録して、対象ユーザーにそのプロファイルに対する権限を与えるという操作によって、セキュリティー保護を実現します。

生徒：うーん、でもSMU定義にはユーザーもクラスもありませんでしたよね・・・単純にIMS資源の組み合わせで許可テーブルが作られていただけで・・・

第２章-

❶

生徒：あ！確かにこのユーティリティーは、運用手順としてIMS生成の後に必ず実行しています。これがSMUによるセキュリティー指定だったのか・・・

教授：ステートメントの意味も単純です。簡単に言うと、『）（に定義された資源（指定）が、それ以降の行に定義された資源について使用を許可される（適用される）』というものになります。例えば、論理端末LTERM451には、IMSトランザクションIVTNOおよびIMSコマンド/START、/STOP、/DISPLAYが許可されています。

生徒：なるほど、この例から見ると、論理端末にIMSコマンドを許可するために『）（端末／コマンド』または『）（コマンド／端末』という書き方ができるのですね。確か、このSMUユーティリティーの実行結果はIMSオンラインのMATRIXデータセットに格納されるのでしたよね？

教授：その通りです。SMU定義は最終的には「端末／コマンド」「トランザクション／コマンド」といった資源組み合わせ毎の許可状況を示す内部テーブル（行列）に変換され、IMS.MATRIX内に格納されます。だからIMS関連のセキュリティー許可モジュール用データセットはMATRIX（行列）データセットと呼ばれています。また、「）（端末／コマンド」「）（コマンド／端末」といった定義順は最終的に資源組み合わせに基づく内部テーブルに統合されますので、あまり重要ではありませんでした。

生徒：他にSMUセキュリティーの使用状況を決める定義はありますか？

教授：もう一つ重要な項目として、IMS生成マクロ指定があります。

図①-3.IMS生成マクロによるセキュリティー設定例

このマクロ指定から、SMUによって生成されたセキュリティー定義の中で、実際にオンラインで活動化するセキュリティーが決まります。

生徒：ということは、SMUコントロール・ステートメント指定が存在していても、実際は使用されていないセキュリティー機能もありえるわけですね。

��


��

第２章-

❷

移行してみよう！端末に対するコマンド・セキュリティー移行の勘所2

RACF移行対象となる論理端末資源

教授：それでは、SMUセキュリティーからRACFセキュリティーへの移行例として、論理端末に対するIMSコマンド・セキュリティーの移行について解説します。

生徒：SMUを使用したIMSコマンド保護は今回のプロジェクトでもRACFへの移行対象になりますので、よろしくお願いします！

教授：まず、SMUを用いた論理端末に対するIMSコマンド保護定義の例を見てみましょう。

図②-1.SMUを使用した論理端末に対するIMSコマンド保護定義の例

生徒：論理端末にIMSコマンドを許可するために「）（端末／コマンド」または「）（コマンド／端末」というSMUコントロール・ステートメント記述が行われていること、また、IMS生成マクロ指定でターミナル・セキュリティーが活動化されていることが分かりますね。・・・教授、実はこのような定義以前の非常に基本的な質問があるのですが・・・

IMSマイグレーションの効率化のために②…移行してみよう！……端末に対するコマンド・セキュリティー移行の勘所

第２章-

❶

教授：そう、まさにそこがSMUセキュリティーからRACFセキュリティーへの移行の勘所になります。つまり、SMUセキュリティーでは「IMS資源（例えば論理端末）―IMS資源（例えばIMSコマンド）」という関係で定義されていたセキュリティー保護を「IMS内のRACFユーザー ID（例えば論理端末にサインオンしたユーザー ID）―IMS資源をあらわすプロファイル（例えばCIMSクラスに登録されたコマンド・プロファイル）」というRACFセキュリティーのスキームに変換して登録し、活動化するという作業になるわけです。つまり、SMUセキュリティーからRACFセキュリティーの移行のキモはIMS資源の何がRACFユーザー IDになってIMS資源の何がIMS資源保護用クラスに紐づくプロファイルになるのかという点をしっかり抑えることです。

図①-5.SMUセキュリティーとRACFセキュリティーの対応関係

生徒：なるほど・・・でも何か難しそうですね、本当にうまく移行できるのかな。

教授：ご心配なく。実は今から30年ほど前のV1の時代からIMSはRACFセキュリティーを実装し続けていますし、2004年に発表されたV9ではほぼ全てのSMUセキュリティーに対しRACFセキュリティーにて同一の保護を提供するような機能拡張が追加されています。また、その後のPTF提供にて、さらに移行性を高める新機能やユーティリティーも盛り込まれました。

生徒：具体的な移行例を見ると、もっと理解できそうな気がします。

教授：では、次回はまず、もっとも多い移行パターンとして、論理端末に対するIMSコマンド・セキュリティー移行の手順と勘所を見ていきましょう。

生徒：それは楽しみですね。よろしくお願いします！

IMS資源（ex.論理端末）

RACFプロファイル（ex.CIMSのプロファイル）

STASTODIS

SMULTERMセキュリティー RACFセキュリティー

使用許可

IMS資源（ex.コマンド）STARTSTOPDISPLAY

使用許可MATRIX RACF DB

RACFユーザーID（ex.論理端末名のユーザーID）

��

第２章-

❷


IMSコマンド・セキュリティーにおけるSMUとRACFの対応関係

教授：それでは、前回解説したSMUセキュリティー移行の勘所、「SMUとRACFの対応関係」について見ていきましょう。

生徒：いよいよ本題ですね。確かに、前回教えていただいたSMUからRACFへの移行は、

　　　 IMS資源の何がRACFユーザーになって　　　 IMS資源の何がIMS資源保護用クラスに紐づくプロファイルになるのか

を明確にするということが勘所になるのでしたね。IMSコマンド・セキュリティーの場合、SMUでは論理端末名とコマンドの組み合わせでコマンド許可が定義されましたが、RACFの場合はどうなるのでしょうか。

教授：IMSコマンド・セキュリティーにRACFを適用するのであれば、

　　　該当論理端末にRACFサインオンしたユーザー IDが　　　 CIMSクラスに登録されたIMSコマンド・プロファイルのREAD権限を有する

場合に該当コマンドの使用が許可されることになります。

生徒：サインオン？聞いたことはあるのですが、どのような機能なのでしょうか・・・？

教授：そうですね、適用必須のセキュリティー機能ではありませんので、使用していない環境では意識することがないと思います。サインオン・セキュリティーとはIMSへのログオン後、ユーザー IDとパスワードの組み合わせを検証する機能です。サインオン・セキュリティーが有効な端末では、ログオン直後にまずサインオンのための画面（DFS3649A）が表示され、これを用いたユーザー IDとパスワードのRACF検証に成功した後、初めて通常のログオン画面（DFS3650I）が表示されます。この際に使用されるRACFユーザー IDを、サインオン・ユーザー IDと呼びます。なお、サインオン・セキュリティーが有効な端末では、このサインオンに成功しない限りログオフ以外の一切のIMS操作ができません。

第２章-

❷


教授：はい、ぜひ質問してください。

生徒：IMSでは静的端末以外にもいろいろな場所からIMSコマンドを投入できますよね。例えば、IMS1次マスター端末（MTO）やz/OSコンソール上の「xxDFS996I*IMSREADY*」に対するリプライ応答（WTOR）、それにz/OSコンソールかCRC（CommandReorganizationCharacter）を経由したコマンド投入もあるぞ・・・うむむ、混乱してきました。SMUからRACFへの移行対象となるのは、そもそもどの端末からのコマンド入力なのでしょうか？

教授：まずは落ち着きましょう。とても良い質問ですね。実は①「SMU移行の勘所　SMUからRACFへの移行って？」で説明した勘所に答えが含まれています。つまり、「SMUステートメント指定がSMUセキュリティー設定そのものであり、ステートメントに指定してある以上のSMUセキュリティー保護を行うことはできない」ということです。

生徒：というと？

教授：SMUでコマンド・セキュリティーを指定できるIMS端末の種類は、TERMINALマクロで定義された静的端末のみです。つまり、SMUからRACFにコマンド・セキュリティーを移行する対象となるのは、静的端末のみです。

生徒：なるほど！もともと他のコマンド入力元はSMUで指定できないのですから、そもそも移行対象にもならないのですね。

教授：はい、そうです。もう少し細かく見ていくと、以下のようになります。

MTO（1次マスター端末）はSMU環境では自動的に全てのIMSコマンドが許可されるよう設定されていました。従って、IMSはRACFセキュリティー環境下でもMTOからの入力をRACF検査対象とせず、全てのコマンド入力が許可されます。

WTOR（z/OSコンソールからのリプライ入力）もSMU環境では自動的に全てのIMSコマンドが許可されるよう設定されていました。従って、IMSはRACFセキュリティー環境下でもWTORからの入力をRACF検査対象とせず、全てのコマンド入力が許可されます。

CRC、OTMA、APPC、ETO経由のコマンド入力は、もともとSMUセキュリティーの対象外であり、RACFセキュリティーもしくはユーザー出口のみ使用可能でした。従って、そもそもSMUからの移行対象にはなりません。

生徒：ありがとうございます。これで移行対象となる端末をはっきりと絞ることができました。

�0 �1

第２章-

❷


教授：予想通りの反応ですね、ご心配なく。そのようなユーザーの要望に答えるために、V9APAR（PK88391）、V10APAR（PK85571）、V11APAR（PK92195）にて自動サインオン機能が提供されています。

生徒：おお！期待の持てそうな機能ですね、どのようなことができるのでしょうか。

教授：このAPAR/PTFを適用することで、TERMINALマクロもしくはTYPEマクロのOPTIONS=パラメーターに新規キーワードAUTOSIGN/NOAUTSGNが指定できるようになります。AUTOSIGNが定義されている端末からログオンする場合、TERMINALマクロに定義されている最初の論理端末名をRACFのユーザー IDとして自動的にサインオンが実施されます。しかも、この自動サインオンの際にパスワード検査は行われないため、論理端末名をRACFユーザー名として登録する際にはNOPASSWORD指定でも問題ありません。

図②-3.AUTOSIGN定義の例

生徒：なるほど！この機能を利用すれば、エンドユーザーにサインオンを意識させずに論理端末名をRACFユーザー IDとすることができますね。これで、SMUで実現されていた「論理端末に対するコマンド許可」と同等のセキュリティーをRACFでも提供できるようになるわけですね。

SMUからの移行におけるIMS定義およびRACF定義の例

教授：さて、それではコマンド・セキュリティー移行時のIMS関連定義例および新規RACF定義例について見ていきましょう。

第２章-

❷


図②-2.IMSサインオン処理の例

生徒：確かにこのサインオンを適用すれば、論理端末とRACFユーザー IDが紐付くことになりますね。そして、RACFサインオンを済ませた論理端末からのコマンド投入時に、CIMSクラスのコマンド・プロファイルに対して該当のRACFユーザー IDがREAD権限をもっていれば、コマンドの使用が許可されるということですね。

教授：その通りです。従って、論理端末に対するコマンド・セキュリティーをSMUからRACFに移行する際には、サインオン・セキュリティーの活動化が前提になります。実はこのサインオン・セキュリティー自体も非常に古くから存在するIMSセキュリティー保護です。また、静的端末の場合はSMUにて実現されていたため、既にサインオン・セキュリティーをお使いのお客様ではSMUからの移行対象になります。しかし、今回の主題ではありませんので、この移行に関する説明は割愛します。

生徒：教授、RACF環境下におけるコマンド・セキュリティーの前提としてサインオンが必要ということは良く分かりました。でも、これは困りました・・・

教授：何が困るのですか？

生徒：ちゃんとRACFでユーザー検証した上でコマンド使用許可を与える、という考え方は筋論では正しいと思いますし、セキュリティー上望ましいと思います。でも、これではエンドユーザーがIMSを使用する前の画面遷移が変わってしまいますよね。この変更に対する業務やアプリケーションの影響見極めや、ユーザー教育に非常に工数がかかってしまいそうです。それに、SLUPやSLU1通信などを実装した上で、IMS論理端末として稼働するVTAMアプリケーションを使用している場合は、そちらの対応にも膨大な手間がかかりそうです・・・

�2 �3

第２章-

❷


図②-5.SMU定義からRACF定義への変更例

生徒：最終的に、これまで伺った内容が反映されたRACF定義内容になるわけですね・・・よく分かりました。教授、この定義を見る限り、一旦勘所を押さえてしまえば、SMU定義からRACF定義への移行パターンはある程度共通化されそうですね。

教授：その通りです。論理端末に対するコマンド・セキュリティーの場合、移行方針が決まればSMU定義それぞれのRACF定義への移行方法はパターン化されます。そして、SMU定義を入力としてパターン化されたRACF定義を生成するためのユーティリティー（DFSKCIMS）が、V9APAR（PK38522+関連APAR）、V10APAR（PK49538+関連APAR））、V11（BASE+関連APAR）にて追加されています。DFSKCIMSを使用することで、SMU定義体からRACF定義体を直接生成することもできます。

図②-6.DFSKCIMSユーティリティー

生徒：これは便利そうですね！このユーティリティーをうまく使用すれば、あまり手を掛けずに移行できそうだなあ。

第２章-

❷



教授：まず、IMS生成マクロおよび実行時パラメーターの指定例を図②-4に示します。実行時パラメーター指定でSECURITYマクロ指定を一部オーバーライドすることもできますが、移行のタイミングで両者とも矛盾のないように設定しておくほうが今後の参照性の観点からも良いでしょう。

生徒：なるほど、確かにあっちでオンなのにこっちでオフだったりすると、後々設定の意味が分からなくなりがちですね、了解です。

SECURITYマクロ指定例●サインオン実施（SECLVL=（,SIGNON））●サインオンに対するRACFセキュリティー保護（TYPE=（RACFTERM））●LTERMセキュリティーの無効化（TERMNL=NO）

TERMINALマクロ指定例（SMU上定義のある論理端末）●自動サインオン実施（OPTIONS=（AUTOSIGN））

IMS実行時パラメーター設定例●サインオン実施（SGN=Y|Wもしくはそれ以上）●静的端末からのコマンド入力に対するRACFセキュリティー保護適用（RCF=S|Rもしくはそれ以上）

図②-4.IMS生成マクロおよびIMS実行時パラメーター指定例

教授：次に移行元となるSMU定義からRACF定義への変換例を図②-5に示します。このRACF定義ではAUTOSIGN機能の利用を前提として、論理端末名と同一名称のRACFユーザーを作成し、CIMSに登録したIMSコマンド用プロファイルに対する権限を与えています。

�4 �5

第２章-

❸

IMSマイグレーションの効率化のために③…移行してみよう！……TYPE…1…AOIセキュリティー移行の勘所

移行してみよう！ TYPE 1 AOIセキュリティー移行の勘所3

TYPE1 AOIアプリケーションにおけるSMU定義

教授：今回は、SMUセキュリティーからRACFセキュリティーへの移行例として、TYPE1AOIアプリケーションに対するIMSコマンド・セキュリティーの移行について解説します。

生徒：SMUを使用したTYPE1AOIコマンド保護も今回のプロジェクトでRACFへの移行対象になりますので、よろしくお願いします！ところで、念のためTYPE1AOIに関する私の理解を確認させてください。要は、IMSコマンドを発行する運用管理用のユーザー・アプリケーションですよね？

教授：はい、TYPE1AOIアプリケーションは、CMDおよびGCMDというDL/Iコールを用いてIMSコマンドを処理するよう実装されたユーザー・アプリケーションです。なお、AOIは自動化操作インターフェイス（AutomatedOperatorInterface）の略であり、IMS操作のためのアプリケーション・インターフェイスという意味です。非常に古くから存在する機能であり、多くの環境で運用管理のために利用されていますね。

生徒：どうして「TYPE1」というのでしょうか？

教授：IMSV5から新たな機能拡張としてICMDおよびRCMDという新しいIMS操作用DL/Iコールが提供され、TYPE2AOIと呼ばれています。よってTYPE2AOI登場以前から存在するCMDおよびGCMDコールを用いた自動化アプリケーションをTYPE1AOIと呼ぶようになりました。では、SMUを用いたTYPE1AOIに対するIMSコマンド保護定義の例を見てみましょう。

第２章-

❷


教授：そうですね。でも、所詮は機械的に変換されたRACF定義体に過ぎません。従って、ユーティリティーの変換結果を慎重にレビューして、できるだけ効率が良く見やすい定義に整形した上で使用したほうがよいでしょう。特に、SMU定義では同じ端末名に対する登録を別々に記述したり、コマンド／端末や端末／コマンドといった自由な形で記述することが可能でしたので、機械的な変換結果ではやや冗長になってしまう可能性があります。また、TERMINAL/SMU定義だけは存在するがもう使用されていない業務端末をIMS上から削除したり、業務的に必要のない余分なコマンド許可を削除したりするなどして、今後IMSを使用する上でメインテナンスしていく定義体の量をなるべく削減することも考慮しておいてください。SMU定義量がそれほど多くなければストレート・コンバージョンでも問題ありませんが、膨大な定義が存在する場合は、移行対象を「本当に移行が必要なもの」に絞り込むことが、今後のシステム運用負荷軽減のための大切なポイントになります。

生徒：なるほど・・・今後めったにないであろうセキュリティー移行のタイミングを利用して、きちんと棚卸をすることも大切な作業になるのですね。教授、とても参考になりました。ありがとうございます。

教授：こちらこそ。次回はTYPE1AOIセキュリティーの移行方法の勘所について見ていきましょう。

生徒：はい、よろしくお願いします。

��

第２章-

❸


TYPE1 AOIセキュリティーにおけるSMUとRACFの対応関係

生徒：SMUからRACFへの移行は、

IMS資源の何がRACFユーザーになってIMS資源の何がIMS資源保護用クラスに紐づくプロファイルになるのか

を明確にするということが重要になるのでしたね。SMUによるTYPE1　AOIセキュリティーはトランザクション・コードとコマンドの組み合わせで定義されましたが、RACFの場合はどうなるのでしょうか。

教授：TYPE1AOIセキュリティーでは、SMUからRACFへの移行パターンとして3つのオプションが用意されています。そして、TRANSACTマクロに新規追加されたAOI=キーワードで、この3つのオプションのうちどのRACF移行パターンを使用するかを指定できます。

図③-2.TRANSACTマクロ新規パラメーターAOI=

TRAN/CMD/YES指定それぞれにおいて、TYPE1AOIに対するRACF権限検査は以下のように実施されます。

（その1：AOI=TRANの場合）トランザクション・コードと同一名称のRACFユーザー IDに対するCIMSクラスに登録されたIMSコマンド・プロファイルのREAD権限

図③-3.AOI=TRANによるRACF権限認証パターン

【RACFユーザーID】トランザクション・コード

AOI=TRAIN

権限認証AOITRN01

【RACFプロファイル】CIMSクラスのプロファイル

（IMSコマンド）STASTODIS

第２章-

❸


図③-1.SMUを使用したTYPE1AOIに対するIMSコマンド保護定義の例

生徒：TYPE1AOIに対するIMSコマンド許可については、「）（トランザクション・コード／コマンド」または「）（コマンド／トランザクション・コード」というSMUコントロール・ステートメント記述が行われていること、また、IMS生成マクロ指定でトランザクション・コマンド・セキュリティーが活動化されていることが分かりますね。教授、TYPE1AOIアプリに対するIMSコマンド許可は、PSB名やプログラム名ではなく、トランザクション・コードに対して定義されるのですね。

教授：はい、CMDコールおよびGCMDコールを使用できるIMS従属領域タイプはMPPもしくはメッセージ主導型BMP（IN=パラメーターでトランザクション・コードを指定したBMP）という制約があります。従って、SMUにおけるコマンド許可は必ずトランザクション・コード／ IMSコマンドという組み合わせになります。

生徒：なるほど、第一回で教えていただいた勘所、「SMUステートメント指定がSMUセキュリティー設定そのものであり、ステートメントに指定してある以上のSMUセキュリティー保護を行うことはできない」という点からは、今回はこのトランザクション・コード／IMSコマンドというSMU上の関係をどうRACFに持っていくかが考慮点になるわけですね。

教授：その通りです、大分つかめてきましたね。それではTYPE1AOIにおけるSMUとRACFの対応関係について見ていきましょう。

��

第２章-

❸


教授：そうですね、私の経験では「AOI=TRAN」を選択する場合が殆どですね。トランザクション名をユーザー IDとしてCIMSクラスを検査させることで、前回学習した論理端末からのIMSコマンド入力に対するセキュリティーと同様の仕組みに乗せることができます。

生徒：なるほど、確かにその通りですね。このパターンが、直感的にも分かりやすくすっきりとしたRACF定義が可能そうです。他のAOI=指定はどのような場合に検討されるのでしょうか。

教授：「AOI=CMD」はSMU定義が殆ど「）（TCOMMAND/CTRANS」というコマンド―トランザクション型で実施されている場合に、見た目上SMUと類似したRACF定義が可能になるというメリットがあります。ただし、セキュリティー許可対象となるIMSコマンドを全てRACFユーザーとして登録する必要があること、TIMSクラスに登録したトランザクションがIMSの別セキュリティーであるトランザクション保護対象になる場合がある点（TRN=Y指定）がやや煩雑です。「AOI=YES」は冒頭で少し説明したTYPE2AOIのセキュリティー検査と同様の仕組みですが、CMDコール発行のタイミングに依存して認証対象となるRACFユーザーIDが変わってしまう点が、元ト々ランザクション・コードにのみ対してコマンド許可を与えればよかったTYPE1AOIの観点から見ると使いにくい面があるでしょう。ただし、新規要件としてAOIトランザクションを発生させたサインオン・ユーザーのIMSコマンド使用権限を反映させたAOIコマンド許可を実施する場合などに、有効に活用できる指定であるともいえます。

生徒：ありがとうございます、よく分かりました。多分私が担当する今回のプロジェクトではAOI=TRANを採用することになりそうです。

SMUからの移行におけるIMS定義およびRACF定義の例

教授：さて、それではTYPE1AOIセキュリティー移行時のIMS関連定義例および新規RACF定義例について見ていきましょう。ここでは、AOI=TRAN型を取り上げます。


教授：まず、IMS生成マクロおよび実行時パラメーターの指定例を図6に示します。実行時パラメーター指定でSECURITYマクロ指定を一部オーバーライドすることもできますが、移行のタイミングで両者とも矛盾のないように設定しておくほうが今後の参照性の観点からも良いでしょう。

第２章-

❸


（その2：AOI=CMDの場合）IMSコマンド先頭3文字と同一名称のRACFユーザー IDに対するTIMSクラスに登録されたIMSトランザクション・プロファイルのREAD権

図③-4.AOI=CMDによるRACF権限認証パターン

（その3：AOI=YESの場合）CMDコール発行時点の状況に依存して選択された、PSB名／論理端末名／サインオン・ユーザー ID ／従属領域のRACFユーザー IDのいずれかに対するCIMSクラスに登録されたIMSコマンド・プロファイルのREAD権限

図③-5.AOI=YESによるRACF権限認証パターン

生徒：うーん、複数の選択肢があるとかえって迷ってしまいますね。一般的に多く使用されているのはどのパターンになりますでしょうか。

【RACFユーザーID】IMSコマンド（先頭3文字）【RACFプロファイル】

TIMSクラスのプロファイル（トランザクション・コード）

AOITRN01

AOI=CMD

権限認証STA

従属領域タイプ CMDコールのタイミング端末サインオン有無 RACFユーザーIDMPP GUI/OPCB前 N/A PSB名

GUI/OPCB成功後無トランザクション投入元LTERM名

有トランザクション投入元サインオン・ユーザーID

MD・BMP GUI/OPCB前 N/A MD・BMPのユーザーID（JCL USER=等）

GUI/OPCB成功後無トランザクション投入元LTERM名

有トランザクション投入元サインオン・ユーザーID

【RACFユーザーID】CMDコール発行時点の状況に依存して変動

【RACFプロファイル】CIMSクラスのプロファイル

（IMSコマンド）STASTODIS

AOI=YES

権限認証

�0 �1


第２章-

❸

生徒：最終的に、またもや伺った内容が反映されたRACF定義内容になるわけですね・・・よく分かりました。教授、前回お聞きしたSMU定義を入力としてRACF定義およびを生成するためのユーティリティー（DFSKCIMS）のように、TYPE1AOI移行を簡略化するためのユーティリティーはありますか？

教授：はい、まず前回紹介したDFSKCIMSを用いることで、論理端末に対するコマンド・セキュリティーと同様にTYPE1AOIセキュリティー用RACF定義を生成することができます。また、SMU定義およびTRANSACTマクロ定義を入力として、TRANSACTマクロ定義にTYPE=パラメーター指定を追加するためのユーティリティー（DFSKSMU1/DFSKSAOI1）を利用することもできます。

図③-8.DFSKSMU1/DFSKAOI1ユーティリティー

生徒：おお、まさにこのようなユーティリティーが欲しかったんですよ。でも、前回教わったとおり、自動生成されたRACF定義やマクロ定義を100%鵜呑みにするのではなくて、ちゃんと生成内容をレビューした上で将来にわたってメンテナンスしやすいよう考慮した定義体を作成するよう心がけますね。今回のセキュリティー移行のタイミングを利用して、きちんと棚卸をすることも大切な作業ですからね。教授、今回も参考になりました。ありがとうございます。

教授：それでは、移行プロジェクト頑張ってください！


第２章-

❸

生徒：そして、AOI1=がTYPE1AOIに対しRACFセキュリティーを適用するための新しい実行時パラメーターになるわけですね。了解です。

SECURITYマクロ指定例●トランザクション・コマンド・セキュリティーの無効化（TRANCMD=NO）

TRANSACTマクロ指定例（SMU上定義のあるAOIトランザクション）●AOI=TRANを追記

IMS実行時パラメーター設定例●V9新規実行時パラメーターAOI1=による、TYPE1AOIセキュリティーへのRACF適用

図③-6.IMS生成マクロおよびIMS実行時パラメーター指定例

教授：次に移行元となるSMU定義からRACF定義への変換例を図7に示します。このRACF定義ではAOI=TRAN指定を前提として、トランザクション・コードと同一名称のRACFユーザーを作成し、CIMSに登録したIMSコマンド用プロファイルに対する権限を与えています。

図③-7.SMU定義からRACF定義への変更例

�2 �3

第３章

・第3章・

CICSマイグレーションのここが知りたい

2011年1月現在、正式サポートされているCICSのバージョンは…CICS…Transaction…Server…V3.1以降です。しかし、実際にはTS…V3.1より前のバージョン（CICS…TS以前のCICS/ESA…V4.1も含む）をお使いのお客様もいらっしゃるため、現時点では非常に幅広いバージョンが利用されています。バージョンアップを行う場合、どのバージョンから移行するのかによって考慮点が異なるため、ひとくちに考慮点と言うと移行元と移行先のバージョンの組み合わせによりさまざまなパターンが発生します。当コラムでは、その中でも特に重要な考慮点や、最近の新機能による拡張について取り上げてご紹介します。

●

MQアタッチメントの変更（CICS TS V3.1以前からの移行）

LE化（CICS TS V2.2以前からの移行）

ロガー環境のセットアップ（CICS/ESA V4.1以前からの移行）

1

2

3

�4

CICSマイグレーションのここが知りたい①…MQアタッチメントの変更…（CICS…TS…V3.1以前からの移行）

�5


第３章-

❶

図①-1.MQおよびSQLアクセスにおけるTCBスイッチ

教授：他にもいいことはありますが、それは後にして、まずは接続の設定をしてみましょうか。

生徒：お願いします。

教授：始める前に、WMQに必要なPTFが適用されているか確認しておいてくださいね。では、CICS-WMQアダプターの設定を始めましょう。

図①-2.CICS-WMQアダプターの設定手順

生徒：まずは資源定義の導入ですね。えーと、確か、WMQが定義体のソースを提供しているから、DFHCSDUPユーティリティーを実行して・・・。

CICS TS V3.2 ～

QR TCB サブタスクTCB QR TCB OPEN

TCB

～ CICS TS V3.1

BL BL

MQOPENBL

BLMQGETSQLSQLBLSQLMQPUTMQCLOSEBL

BL

BL

BL

BL

MQCLOSE

MQPUT

SQL

SQL

SQL

MQGET

MQOPEN

～CICSTSV3.1 CICSTSV3.2 CICSTSV4.1～

1.CICS資源定義 WMQ提供 CICS提供

2.CICS起動時の自動接続設定（Option）

SITMQCONNパラメーター

PLTPI PLTPI

3.接続先情報の設定 SITINITPARM SITINITPARM MQCONN資源定義

4.CICSスタートアップJCL STEPLIB/DFHRPL STEPLIB/DFHRPL

5.WMQCSQINP2を修正イニシエーション・キュー名を指定（デフォルトCICS01.INITQ）※色付きセルは変更がある項目

第３章-

❶

MQアタッチメントの変更（CICS TS V3.1以前からの移行）1

生徒：うーん、困ったな・・・。

教授：どうしましたか？

生徒：実は最近、CICSTSV2.3からCICSTSV4.1にバージョンアップしたんです。そうしたら、WebSphereMQ（WMQ）と接続できなくなってしまったんです。

教授：マニュアルの手順に従って設定しましたか？

生徒：いいえ。以前作成した手順書があったので、それを見ながら同じ作業をしましたよ。

教授：なるほど。実は、CICSTSV3.2以降では、WMQ接続の仕組みが変更になったので、これまでと同じ手順で設定しても接続できなくなったのですよ。

生徒：えー。具体的にはどのような変更でしょうか？

教授：これまで、CICSとWMQの接続機能はWMQ側が提供していました。それが、CICSTSV3.2からはCICS側が提供するようになりました。

生徒：CICSが提供するようになって、何かいいことがあるんですか？

教授：いろいろありますよ。まずは、OpenTCBに対応したことです。OpenTCBといえばSQLを処理するTCBとして有名ですよね。WMQを使用する場合、これまでは、アプリケーションがMQI（MQのAPI）を発行するときは、MQI毎にQRTCBからサブタスクTCBへスイッチして処理していました。しかし、MQIをOpenTCBで処理するようになったことで、アプリケーションがスイッチ先のTCBでそのまま稼働できるようになりました。つまり、TCBスイッチの回数が減り、CPU削減が見込めるというわけですね。

��


��


第３章-

❶

生徒：ところで教授、実はまだ移行作業中なので、古いリージョンとCICSTSV4.1のリージョンが混在していて、このCSDを共用しているのですが・・・。

教授：それを早く言ってください。CICSTSV3.1までのCICSでは、WMQが提供しているCICSアダプターを使用しなければいけませんから、CSQCAT1グループを使いますよ。DFHMQグループは、CICSTSV3.2以降でしか使えません。

生徒：えー、どうすればいいんだ・・・。

教授：まず、CICSTSV4.1のリージョンには、CSQCAT1グループの資源をインストールしないこと。CICSTSV2.3の方ですが、DFHMQグループ定義より後からCSQCAT1グループを上書きインストールしましょう。

生徒：ということは、この環境ではCSQCAT1グループをMQLISTというLISTに追加しているので、SITGRPLIST=(DFHLIST,MQLIST)という順番で指定すればいいわけですね。

教授：その通り。あとは、CSQCAT1グループから、TDQUEUE(CKQQ)定義を削除してください。

生徒：いいんですか？

教授：大丈夫です。CKQQの定義はDFHMQグループでも提供していますから、定義が重複するとエラーになってしまいますからね。

生徒：完了しました。

教授：では次に、CICS起動時の自動接続の設定を確認しましょう。CICSを起動した時、どうやってWMQとの接続を開始していますか？

生徒：PLTPIでCSQCCODFを実行して、起動時に自動接続しています。

教授：PLTPIですか。では、そこも変更が必要です。アダプターのモジュールはCICSが提供するようになったので、モジュール名もCICSらしく、DFHMQCODになりましたからね。

第３章-

❶

教授：いきなり間違っていますよ。CICS-WMQアダプターはCICSが提供するようになったと言いましたよね。当然、資源定義もCICSが提供しているのです。

図①-3.CICS-WMQアダプターの設定（1）.資源定義

生徒：あ、DFHMQというグループがCSDに最初から入っています。これを使えばいいんですね。

教授：そうです。ちなみに、DFHMQはLIST(DFHLIST)にも含まれていますから、SITGRPLISTでDFHLISTを指定している場合には、CICS起動時に自動的にWMQ関連の資源定義が導入されます。DFHLISTを使用しない場合は、別のLISTに追加してそのLISTをGRPLISTに追加すればいいですよ。

生徒：教授、CSDも移行したので、今まで使っていたWMQの資源定義グループCSQCAT1とCSQ4SAMPが残っていますが・・・。

教授：CSQCAT1は削除してください。CSQ4SAMPは残しておきましょう。これはWMQが提供しているサンプル・アプリケーションの定義ですから、CICSでは提供していないので。

資源定義提供元設定手順 RDOグループ

アダプター WMQWMQ提供の定義体　hlq.SCSQPROC(CSQ4B100)をDFHCSDUPユーティリティーで導入

CSQCAT1 必須

サンプル・アプリケーション WMQ

WMQ提供の定義体　hlq.SCSQPROC(CSQ4S100)をDFHCSDUPユーティリティーで導入

CSQ4SAMP 任意

～ CICS TS V3.1

資源定義提供元設定手順 RDOグループ

アダプター CICS なし（CSDに定義済み） DFHMQ 必須

サンプル・アプリケーション WMQ

WMQ提供の定義体　hlq.SCSQPROC(CSQ4S100)をDFHCSDUPユーティリティーで導入

CSQ4SAMP 任意

CICS TS V3.2 ～

��


��


第３章-

❶

～ CICS TS V3.1

INITPARM=(CSQCPARM='SN=QMG1,TN=001,IQ=CICS01.INITQ')

CICS TS V3.2 ～

INITPARM=(DFHMQPRM='SN=QMG1,IQ=CICS01.INITQ')

図①-5.CICS-WMQアダプターの設定（3）.INITPARMの設定

生徒：CSQCPARM=がDFHMQPRM=になっていますね。それに、TN=パラメーターの指定がなくなっています。TNはトレース番号を指定するパラメーターでしたね。

教授：そう。まずはオペランドがCSQCPARMから、CICSらしくDFHMQPRMに変わりました。そして、もう一つがTNパラメーターの廃止です。実は、これも最初にお話ししていた「いいこと」の一つですが、その話は後にして、先に設定を済ませましょう。

生徒：そうですね。CICSTSV4.1以降ではどう変更されたのですか？

教授：INITPARMでの指定が廃止されたので、無視されます。

生徒：ええっ、そんな・・・。

教授：そんなにがっかりしないで。その代わり、MQCONNという資源定義が追加されたので、これを使って接続情報を定義すればいいのです。

OBJECT CHARACTERISTICS

CEDA View MQconn( QSG1 )

MQconn : QSG1

Group : MQGROUP

DEScription : CONNECTION TO WEBSPHERE MQ

Mqname : QSG1

Resyncmember : Yes Yes | No

Initqname : CICS01.INITQ

図①-6.CICS-WMQアダプターの設定（4）.MQCONN資源定義

生徒：なるほど。MQNAMEにQMGR名を、INITQNAMEにイニシエーション・キュー名を指定して・・・このRESYNCMEMBERって何ですか？

第３章-

❶

●…PLTPIで設定する場合

～ CICS TS V3.1

DFHPLTMQ DFHPLT TYPE=INITIAL,SUFFIX=MQ

DFHPLT TYPE=ENTRY,PROGRAM=DFHDELIM

DFHPLT TYPE=ENTRY,PROGRAM=CSQCCODF

DFHPLT TYPE=FINAL

END

CICS TS V3.2 ～

DFHPLTMQ DFHPLT TYPE=INITIAL,SUFFIX=MQ

DFHPLT TYPE=ENTRY,PROGRAM=DFHDELIM

DFHPLT TYPE=ENTRY,PROGRAM=DFHMQCOD

DFHPLT TYPE=FINAL

END

●…SITパラメーターで設定する場合

MQCONN=YES

図①-4.CICS-WMQアダプターの設定（2）.CICS起動時の自動接続設定

生徒：PLTPIのアセンブルは面倒だな・・・

教授：では、いい機会ですからPLTPIをやめて、SITMQCONNパラメーターを使いましょうか。MQCONN=YESと指定すれば、PLTPIと同じように、CICS起動時に自動的にWMQと接続できますよ。

生徒：これは簡単！いい機能が追加されましたね。

教授：これはCICSTSV1から使えますよ。移行時はパラメーターを見直すチャンスですから是非使ってみてください。では次に進みましょう。

生徒：SITINITPARMパラメーターで接続先の情報を指定するんですよね。

教授：そこも変更になりました。ただし、その変更内容はCICSTSV3.2と、CICSTSV4.1以降で異なりますから注意してください。先に、CICSTSV3.2の場合の変更について説明しておきましょう。

100


101


第３章-

❶

教授：まず、DFHRPLは連結の順序に気をつけてください。必ずCICSのライブラリーを上位に連結してください。そうしないとWMQ提供のアダプター・プログラムが使用されてしまいますからね。

・・・ SCSQANLx、SCSQCICSライブラリーは必要なケースもあります。接続先のWMQのバージョンがV5.3.1で、MQ-CICSブリッジ機能を使用するか、WMQ提供のサンプルを実行する場合です。それ以外であれば、指定は不要になりました。

生徒：あとはWMQCSQINP2でイニシエーション・キューを指定する、と。ここは移行前と同じですね。

教授：はい。これでMQ-CICSアダプターの設定は完了です。・・・そうそう、SITMAXOPENTCBSの見直しもしておかないといけませんね。最初にお

話ししたとおり、MQIはL8TCBというOpenTCBで稼働します。OpenTCBは複数持てますが、無制限というわけではなく、その上限を決めるのがMAXOPENTCBSパラメーターです。

生徒：つまり、CICS-WMQの1Threadが1TCBだから・・・確か、CICS-WMQのThread数は9本でしたよね。

教授：そこも変更されました。CICSTSV3.2以降では固定数ではなく、L8TCBをアロケートできる上限数で制御するようになったのです。それがMAXOPENTCBSです。

生徒：じゃあ、今までと同じでいいからMAXOPENTCBS=9と指定します。

教授：ちょっと待ってください。OpenTCBはWMQ以外にも、DB2アクセスやJavaアプリケーション実行時などにも使用されますよ。それらすべてのTCBを合計した数を指定してくださいね。それに、OpenTCBはタスクに紐付いて占有されますから、WMQタスクの並行度から算出しなければいけませんよ。

生徒：そうか。そういえばDB2接続の設定をするときにもこのパラメーターを変更しました。ええと、今はDB2CONN定義のTCBLIMIT=20で、MAXOPENTCBSも20が指定されています。WMQアクセスするタスクは常駐で10タスク稼働するので、その分を合計して30を指定します。

教授：同じアプリケーション内でSQLとMQIを発行している場合は同じTCBが使われるので、実際にはそれより少なくてもよい場合もありますが、MXTとは違ってMAXOPENTCBSで大きい値を指定しても、それだけでリソースが消費されることはありませんから、不足することだけはないよう十分な値を指定することが大事です。

第３章-

❶

教授：それは、WMQがキュー共用環境の場合に有効となるパラメーターです。CICSTSV4.1では、MQグループ・アタッチ機能が追加され、キュー共用グループ名を指定してWMQに接続することができます。

図①-7.MQグループ・アタッチ

生徒：ふむふむ。ということは、今はCICS1は同じLPAR上のQMG1に接続しているけど、CICS1をZOS2で起動すれば、同じMQCONN定義でQMG2へ接続できるというわけですね。

教授：そう。ただ、ZOS2で再起動する前に、ZOS1で稼働していたCICS1とQMG1の間でIndoubtUOWが残ってしまったとしたらどうしますか？

生徒：それは普通、QMG1と再接続してIndoubtを解消させなければいけませんよ。

教授：そうですね。このようにIndoubtUOWがある時の接続を制御するのがRESYNCMEMBERオプションです。YESを指定すれば、前回接続していたキュー・マネージャーに接続します。NOを指定した場合も、前回接続していたキュー・マネージャーに接続しようとしますが、接続できなければグループ内の別メンバーと接続します。ちなみに、WMQV7.0.1ではキュー共用グループ内のIndoubtをリカバリーできる機能も追加されていますよ。

生徒：MQCONN資源定義ができました。このMQCONN資源定義も起動時に導入できるようにSITGRPLIST内のリストに追加すればいいんですね。

教授：よく気がつきましたね。さあ、あとは、CICSスタートアップJCLを見直して完了ですよ。

生徒：STEPLIBは今までと同じですね。DFHRPLは、連結するライブラリーが減りましたね。

共用キュー

MQCONN

DFHCSD

キュー共用グループQSG1

QMG1 QMG2

CICS2

ZOS2

InstallInstall

ZOS1

CICS1

102


103


第３章-

❶

図①-8.CICSトレース（～CICSTSV3.1）

図①-9.CICSトレース（CICSTSV3.2～）

生徒：MQOPENやMQGETなど、何をしているのかがわかりやすくなりましたね。

教授：そうです。今まではTNパラメーターで指定したユーザー・トレース・ポイント1つだけでしたし、トレース・エントリーCSQCxxxxをWMQのマニュアルで調査しないとその内容がわからないので十分見やすいとは言えませんでした。

生徒：で、これがモニタリングですね。

00066 QR AP 2520 ERM ENTRY COBOL-APPLICATION-CALL-TO-TRUE(MQM )

00066 QR AP 00E1 EIP ENTRY ENTER-TRACENUM 0004,1DF0F288 .02h,08004802 ....

00066 QR AP 0001 USER EVENT APPLICATION-PROGRAM-ENTRY CSQCOPNO KOMA.TEST.IN

00066 QR AP 00E1 EIP EXIT ENTER-TRACENUM OK 00F4,00000000 ....,00004802 ....

00066 QR DS 0004 DSSR ENTRY WAIT_MVS MQSeries,1DDCC238,NO,TASKSWCH

00066 QR DS 0005 DSSR EXIT WAIT_MVS/OK


00066 QR AP 0001 USER EVENT APPLICATION-PROGRAM-ENTRY CSQCOPNH ....


00066 QR AP 2521 ERM EXIT COBOL-APPLICATION-CALL-TO-TRUE(MQM )



00066 QR AP 0001 USER EVENT APPLICATION-PROGRAM-ENTRY CSQCGMGH ....





00066 QR AP 0001 USER EVENT APPLICATION-PROGRAM-ENTRY CSQCGMGI CSQ M60R G..?............................



00066 QR AP 0001 USER EVENT APPLICATION-PROGRAM-ENTRY CSQCGMGD UPDATE00010000





00066 QR AP 0001 USER EVENT APPLICATION-PROGRAM-ENTRY CSQCLOSH ....





MQOPEN

MQGET

MQCLOSE

00204 L800C AP 2520 ERM ENTRY COBOL-APPLICATION-CALL-TO-TRUE(MQM )

00204 L800C AP A090 MQTRU ENTRY APPLICATION-REQUEST MQOPEN

00204 L800C AP A091 MQTRU EXIT APPLICATION-REQUEST MQOPEN 00000000,00000000

00204 L800C AP 2521 ERM EXIT COBOL-APPLICATION-CALL-TO-TRUE(MQM )


00204 L800C AP A090 MQTRU ENTRY APPLICATION-REQUEST MQGET

00204 L800C AP A091 MQTRU EXIT APPLICATION-REQUEST MQGET 00000000,00000000



00204 L800C AP A090 MQTRU ENTRY APPLICATION-REQUEST MQCLOSE

00204 L800C AP A091 MQTRU EXIT APPLICATION-REQUEST MQCLOSE 00000000,00000000


MQGET

MQOPEN

MQCLOSE

第３章-

❶

生徒：わかりました。ところで教授、MQ-CICSブリッジも使用しているのですが、その設定は？

教授：MQ-CICSブリッジの設定は、CICSの資源定義とWMQ側でキューの定義をするという2つの手順があります。WMQ側の定義はこれまでと同じですが、CICSの資源定義はCICS-WMQアダプターと同じく変更になりましたよ。

生徒：つまりCICSが提供してくれる、というわけですね。

教授：そうです。MQ-CICSブリッジ関連の定義もDFHMQグループに含まれているので、これまで使用していたCSQCKBグループを導入しないでください。ただし、CICSTSV3.1以前のCICSではCICS-WMQアダプターの設定と同様にWMQ提供の資源定義を使用すること。

生徒：じゃあ、CICSを起動してみますね・・・。やりました、教授。接続できましたよ。

教授：おめでとう。

生徒：ところで、気になることがあるんですが・・・。MQIを発行するアプリケーションを連係編集する時にはWMQのStubCSQCSTUBをINCLUDEしていました。でも、CICSが提供するWMQ関連のモジュールは、DFHMQxxxという名前になっています。ということは、CICS提供のStubをINCLUDEして連係編集し直さないといけないですよね？

教授：大丈夫、問題ありません。確かに、CICSが提供するStubはDFHMQSTBという名前ですが、AliasとしてこれまでのCSQCxxxxが定義されていますから、今までとネーミングには変更なしと考えてもらっていいですよ。再コンパイルする場合も、CICS、WMQのどちらが提供するStubもサポートしていますから、コンパイルJCLの修正も不要です。ただし、WMQV7で追加されたAPIを使う場合は、CICS提供のStubを使わなければいけませんから注意してください。

生徒：よかったー。じゃあ、「いいこと」の続きを教えてください。

教授：そうですね、先ほどのINITPARMの設定の時にもちょっと言いましたが、CICSが提供する問題判別や監視機能でMQ接続の情報を取得できるようになったので、解析がしやすくなりました。具体的には、CICSのトレース、モニタリング、統計情報です。

生徒：どういうことでしょう？今までもトレースは取れていましたよ？

教授：では見比べてみましょう。

104 105


第３章-

❶図①-11.CICS統計情報

教授：最後にもう一つ。メッセージIDが変更されたので注意してください。

生徒：本当だ。CICS-MQメッセージはこれまでCSQCxxxxというメッセージIDだったのに、DFHMQxxxxになっていますよ。NetViewの自動化監視メッセージを変更しなければ・・・。

教授：これでMQ接続は大丈夫ですね。では今日はここまでにしましょう。

生徒：ありがとうございました。

WebSphere MQ Connection statistics

__________________________________

MQCONN name. . . . . . . . . . . . . . . : M60R Websphere MQ Connect Date / Time . . . : 12/20/2010 / 18:37:18

WebSphere MQ Connection Status . . . . . : CONNECTED Websphere MQ Disconnect Date / Time. . :

Mqname . . . . . . . . . . . . . . . . . : M60R

WebSphere MQ Queue Manager Name. . . . . : M60R

Resync Group member. . . . . . . . . . . : YES

Websphere MQ Release . . . . . . . . . . : 6.00

Initiation Queue Name. . . . . . . . . . : CICS01.INITQ

Number of current tasks. . . . . . . . . : 1

Number of futile attempts. . . . . . . . : 0

Total number of API calls. . . . . . . . : 206

Number of API calls completed OK . . . . : 205

Number of OPEN requests. . . . . . . . . : 69

Number of CLOSE requests . . . . . . . . : 68

Number of GET requests . . . . . . . . . : 69

Number of GETWAIT requests . . . . . . : 69

Number of GETWAITs that waited . . . . : 1

Number of PUT requests . . . . . . . . . : 0

Number of PUT1 requests. . . . . . . . . : 0

Number of INQ requests . . . . . . . . . : 0

Number of SET requests . . . . . . . . . : 0

Number of internal MQ calls. . . . . . . : 229

Number that completed synchronously. . . : 228

Number that needed I/O . . . . . . . . . : 0

Number of calls with TCB switch. . . . . : 0

Number of indoubt units of work. . . . . : 0

Number of unresolved units of work . . . : 0

Number of resolved committed UOWs. . . . : 0

Number of resolved backout UOWs. . . . . : 0

Number of Backout UOWs . . . . . . . . . : 1

Number of Committed UOWs . . . . . . . . : 22

Number of tasks. . . . . . . . . . . . . : 23

Number of Single Phase Commits . . . . . : 22

Number of Two Phase Commits. . . . . . . : 0

( 後略 )


第３章-

❶図①-10.CICSモニタリング

教授：WMQREQCTはユーザー・タスクで発行したMQリクエスト数、WMQGETWTはGETWAITでMQ待ちになった時間が出ます。それ以外にも見てほしいのが、L8TCBの使用状況です。MQIはL8TCBで処理されますから、その処理時間はL8TCBに計上されるのです。

生徒：統計情報では、接続状況や発行されたMQIの数などがわかるんですね。これは便利です。

----------FIELD-NAME-------------------------UNINTERPRETED-------------------------------INTERPRETED--------------

DFHTASK C001 TRAN E6E2D4F2 WSM2

DFHTERM C002 TERM F0F0F2F7 0027

DFHCICS C089 USERID C3C9C3E2 E4E2C5D9 CICSUSER

( 中略 )

DFHDATA A395 WMQREQCT 00000009 9

...

DFHTASK A252 DSTCBHWM 00000001 1

...

DFHCICS A402 EICTOTCT 00000004 4

...

DFHTASK S007 USRDISPT 000000000048C98000000008 000 00:00:00.001164 8

DFHTASK S008 USRCPUT 00000000003565DC00000008 000 00:00:00.000854 8

DFHTASK S014 SUSPTIME 0000000ECD81AB8000000008 000 00:00:15.521818 8

DFHTASK S102 DISPWTT 000000000003158000000007 000 00:00:00.000049 7

DFHTASK S255 QRDISPT 0000000000257E8000000004 000 00:00:00.000599 4

DFHTASK S256 QRCPUT 0000000000195D9000000004 000 00:00:00.000405 4

...

DFHTASK S262 KY8DISPT 0000000000234B0000000004 000 00:00:00.000564 4

DFHTASK S263 KY8CPUT 00000000001C084C00000004 000 00:00:00.000448 4

...

DFHTASK S259 L8CPUT 00000000001C084C00000004 000 00:00:00.000448 4

...

DFHTASK S249 QRMODDLY 0000000000010A8000000003 000 00:00:00.000016 3

...

DFHTASK S247 DSCHMDLY 000000000001F68000000006 000 00:00:00.000031 6

...

DFHTASK S125 DSPDELAY 0000000000011A0000000001 000 00:00:00.000017 1

...

DFHTASK S170 RMITIME 0000000ECD9F9F800000000B 000 00:00:15.522297 11

DFHTASK S171 RMISUSP 0000000ECD7E9B0000000001 000 00:00:15.521769 1

DFHSYNC S173 SYNCTIME 00000000001D4A0000000001 000 00:00:00.000468 1

...

DFHDATA S396 WMQGETWT 0000000ECD7E9B0000000001 000 00:00:15.521769 1

...

MQリクエストの発行数

MQ GETWAITによる待ち時間

MQ APIの処理時間はL8 TCBに計上される

10� 10�

第３章-

❷

CICSマイグレーションのここが知りたい②…LE化（CICS…TS…V2.2以前からの移行）

図②-1.CICS移行に伴うLE化

一方、アプリケーションのLE対応は、アプリケーションがLEランタイム上で稼働するように、アプリケーションに適切な修正を行うことです。

生徒：アプリケーションはLEコンパイラーで再コンパイルしないといけないのでは？教授：それは使用している言語と移行先CICSバージョンによりますね。例えば、VS

COBOLⅡはCICSTSV3.1以降でも稼働サポートがありますので、ランタイムをLE化しても、ユーザー・アプリケーションは基本的にそのまま稼働できます。一部のアプリケーションについては再コンパイルや再リンクが必要になる場合がありますが。CICSバージョンごとの言語サポートについては、稼働させるバージョンのマニュアルで確認してくださいね。

生徒：つまり、CICSTSV2.3以降にバージョンアップするからといって、全アプリケーションを再コンパイルしなくてもいいかもしれないということですね？

教授：そういうことです。

生徒：全部作り直しだと思っていましたが、思ったより移行の工数は大きくならないかも。 CICSのLE化はランタイムのLE化とアプリケーションのLE対応が必要なのはわかりま

したが、LE化する利点は何ですか？

または

LE化済みのためそのまま移行CICSの

LE化が必要

非LEモジュール LEモジュール非LEモジュール

言語提供ランタイム

非LEモジュール LEモジュール

LEランタイム

～CICS TS V2.2～CICS TS V2.2

LEランタイム

CICS TS V2.3～

基本的にそのまま稼働できるが、一部モジュールはLEモジュールとして作り直し

第３章-

❷


LE化（CICS TS V2.2以前からの移行）2

生徒：うーん・・・。

教授：またしても困った顔をしていますね。どうしましたか？

生徒：お客様がCICSのバージョンアップを予定しているのですが、CICSTSV2.3以降ではLE化が必要だっていうじゃありませんか。どうやってLE化を進めればいいのか考えていたのです。

教授：なるほど。ではどの作業で悩んでいるのですか？

生徒：実は・・・何から始めればいいのかさっぱりわからずに悩んでいるのです・・・。

教授：・・・それは重症ですね。では今日はLE化について勉強することにしましょう。

生徒：ありがとうございます！助かります！！

教授：CICSのLE化には大きく2つの作業があるのは知っていますよね？

生徒：ランタイムのLE化とアプリケーションのLE対応でしょうか。

教授：そうです。ランタイムのLE化はCICSの稼働環境をLE化することです。CICSTSV2.3以降で

は、ランタイムはLE化することが必須となっています。もちろん、CICSTSV2.2以前のバージョンでもランタイムのLE化は可能ですが必須ではなく、言語提供のランタイムを使用することもできました。

10� 10�


第３章-

❷

教授：そうです。STEPLIBの代わりにLNKLSTxxでもいいですよ。あと、言語提供のランタイム・ライブラリーは指定を外してくださいね。

生徒：他には何をすればいいのですか？

教授：あとは、LE関連のモジュールを読み込めるように、CSDにLE関連の資源定義が必要です。LE関連の資源定義はCEEグループとして作成します。CEEグループを作成したらリストに追加してCICS始動時に読み込まれるようにしておきましょう。CICSTSV2.3以降に移行する場合はデフォルトでDFHLISTにCEEグループが追加されているのですが、CICSTSV2.2以前の場合は手動で追加しなくてはいけません。

生徒：CEEグループの資源定義のためのサンプルは無いのですか？

教授：CEE.SCEESAMP(CEECCSD)にCEEグループの定義サンプルがありますので、DFHCSDUPの入力に使用すればOKです。もしお客様がCICSでC/C++を使用していてXPLINK機能を使う場合にはCEE.SCEESAMP(CEECCSDX)による定義も追加してくださいね。

あと、これは忘れがちなのですが、LEのランタイムはOSが提供しています。そのため、OSのバージョンが変わったときにはCEEグループはそのOSで提供しているサンプルを使用して再定義してあげる必要がある点に注意してください。

生徒：なるほど。ランタイムのLE化についてはわかりました。では、アプリケーションのLE対応では何をすればいいのでしょうか？

教授：アプリケーションのLE対応は、大きく3つの種類に分かれます。何もしない、再連係編集、再コンパイルです。

生徒：“何もしない”ですか？

教授：そうです。非LEコンパイラーでコンパイルされていても基本的にはLEランタイム上でそのまま稼働可能です。そういうアプリケーションは何もしなくても大丈夫ということです。

生徒：では、再連携編集と再コンパイルはどう違うのですか？教授：再連携編集はリンクしているモジュールを変更するケースです。例えば、言語固有の

ルーチンを静的CALLしている場合、LE化後はLE提供のルーチンを使用するように再連係編集が必要となります。

一方、再コンパイルは、移行後はサポートされない言語を使用している場合に必要に


第３章-

❷

教授：これはCICSだけではなくて一般に言えることですが、LEが出てくる前は、ユーザー・アプリケーションを稼働させるランタイムは、COBOLならCOBOL用のランタイム、PL/IならPL/I用のランタイムというように、コンパイラーが独自に提供していました。またCOBOLでも、OS/VSCOBOLとVSCOBOLⅡではそれぞれがランタイムを提供しており、実行JCLではアプリケーション・モジュールに合ったランタイムを指定する必要がありました。しかしながら、LEが出てきたことで、ランタイムは全言語で共通のものを1つ指定すればよくなりました。

生徒：つまり、ユーザー・アプリケーションがCOBOLで作れられていても、PL/Iで作られていても、実行JCLで指定するランタイムはLEのランタイムのみでよいということですね。

教授：さらに、コンパイラーからランタイムが切り離されたため、コンパイラーのバージョンアップをしたりコンパイラーを変更したりしても、実行JCLで指定するランタイムは変更せずにすみますので、JCLやプロシージャー等の運用管理も楽になります。

それに加えて、LEランタイムを使うことで、異なる言語間でのCallが可能になりました。アセンブラーのCallは前からできていたのですが、例えばCOBOLからPL/IのモジュールをCallするということはできませんでしたので、これも大きな違いです。

図②-2.ランタイムのLE化

生徒：なるほど。一度LE化してしまえば、いろいろな恩恵を受けられそうですね。

教授：さて、話をCICSに戻しましょう。 CICSのランタイムをLE化する方法は知っていますか？

生徒：ランタイムのLE化は以前聞いた覚えがあります。確か、STEPLIBにCEE.SCEERUN、CEE.SCEERUN2を指定して、DFHRPLにCEE.SCEECICS、CEE.SCEERUN、CEE.SCEERUN2を指定すればいいんでしたよね。

● 1つのランタイムで全言語をカバー● 言語間のCallが可能

COBOLモジュール PL/Iモジュール C言語モジュール

COBOLモジュール PL/Iモジュール C言語モジュール

COBOL提供ランタイム C言語提供ランタイムPL/I提供ランタイム

LEランタイム

110 111

第３章-

❷


教授：そういう人のために、OSVSCOBOLやVSCOBOLⅡのプログラム・ソースを入力にして言語レベルを判断し、必要な部分を自動的に修正してくれるツールがあります。COBOLandCICSCommandLevelConversionAid（CCCA）というツールです。例えば図のように変換してくれます。

図②-4.CCCAによる変換イメージ

生徒：どれどれ・・・おっ、これは便利ですね。ソースコードの修正があっという間だ。他にこういう便利なツールは無いのですか？

教授：他にも、LIBMAP、EPA、ロード・モジュール・アナライザーなどといったツールや機能があります。目的に応じて必要なツールを使うと移行工数の削減になるでしょう。

BLLの代替ポインター定義の追加OS/VS COBOLソース CCCA変換後

WORKING-STORAGE SECTION. WORKING-STORAGE SECTION. 77 LCP-WS-ADDR-COMP PIC S9(8) COMP. 77 LCP-WS-ADDR-PNTR REDEFINES LCP-WS-ADDR-COMP USAGE POINTER.

BLLセルの削除

LINKAGE SECTION. 01 BLL-CELLS. 03 BLL-PTR PIC S9(8) COMP. 03 AREA1-PTR01 PIC S9(8) COMP. 03 AREA2-PTR02 PIC S9(8) COMP.

LINKAGE SECTION.*01 BLL-CELLS.* 03 BLL-PTR PIC S9(8) COMP.* 03 AREA1-PTR01 PIC S9(8) COMP.* 03 AREA2-PTR02 PIC S9(8) COMP.

SERVICE RELOADステートメントの削除

SERVICE RELOAD ... CONTINUE.

4KB以上のアドレッシング処理の削除

ADD +4096 AREA1-PTR01 GIVING AREA1-PTR02. CONTINUE.

EXEC CICSコマンド SETオプションの変更

EXEC CICS GETMAIN SET(AREA1-PTR01) ... EXEC CICS GETMAIN SET(ADDRESS OF AREA1) ...

EXEC CICS ADDRESSコマンドの変更

EXEC CICS ADDRESS TWA(BLL-PTR2) EXEC CICS ADDRESS TWA(ADDRESS OF TWA-AREA)

予約語とユーザー定義名との衝突回避

WORKING-STORAGE SECTION. 01 CLASS PIC X(5). 01 AREA1 PIC X(5). PROCEDURE DIVISION. MOVE CLASS TO AREA1.

WORKING-STORAGE SECTION. 01 CLASS-74 PIC X(5). 01 AREA1 PIC X(5). PROCEDURE DIVISION. MOVE CLASS-74 TO AREA1.

ポインターのセット処理の変更

MOVE AREA1-PTR01 TO PTR1. SET LCP-WS-ADDR-PNTR TO ADDRESS OF AREA1. MOVE LCP-WS-ADDR-COMP TO PTR1.

第３章-

❷


なります。例えば、OS/VSCOBOLはCICSTSV3.1以降ではABENDしてしまいますので、再コンパイルが必要です。もちろん、ソースにCICSバージョン間の非互換対応を施した場合には再コンパイルが必須なのは言うまでもありませんね。

図②-3.再連係編集・再コンパイルが必要になる主な例

生徒：なるほど。私のお客様はCICSTSV4.1に移行するのですが、アプリケーションはOS/VSCOBOLとVSCOBOLⅡが混在しているのです。少なくともOS/VSCOBOLでコンパイルされたアプリケーションについては再コンパイルが必要ということですね。

ではCICSのバージョンアップによるAPI非互換部分を修正して再コンパイルしてみますね。

・・・教授！再コンパイルしたらエラーがたくさん出てしまいました！！

教授：それは言語の非互換ではないですか？LE対応のコンパイラーと、LE対応ではないコンパイラーでは文法が異なる場合があります。例えば、OS/VSCOBOLとEnterpriseCOBOLでは、言語レベル（ANSIレベル）が前者は68か74ですが後者は85となっており、一部の構文が異なるためソースを修正しないとコンパイルは通りません。

生徒：いちいちソースを調べるのは非常に面倒なんですけど・・・。

言語再連係編集するケース再コンパイルするケース

COBOL

・VSCOBOLⅡを使用していて、DBCSコンバージョン・ルーチン（IGZCA2D,IGZCD2A）を静的Callしている場合

・VSCOBOLⅡを使用していて、DFHECIをリンクしている場合は、DFHELIIに変更して再連係編集推奨

・移行先がCICSTSV3.1以降の場合、OS/VSCOBOLは再コンパイル

・ソースの修正が発生した場合

PL/I・OSPL/IV1.3、V1.4を使用している場合・OSPL/IV1.5.1で共用ライブラリーを使用している場合

・OSPL/IV1.2以前を使用している場合・ソースの修正が発生した場合

C言語・C/370V1、V2でAPARPN74931の適用なしにCOBOLをILCしている場合

・ctest（）コールを含む場合・ソースの修正が発生した場合

112 113

図②-6.LEランタイム・オプションの例

生徒：よし。ちゃんと動きました。次は障害時のテストをやりますね。・・・・あれ？

教授：今度は何が起きましたか？

生徒：エラーハンドリングがおかしいです、教授。 HANDLEABENDに制御が渡りません。


第３章-

❷

オプション推奨値（*）はCICS環境のdefault値説明

ABTERMENC ABEND（*）アベンド時のエンクレーブの終了方法

ALL31 ON（*）

プログラムがすべてAMODE31ならONを指定することが推奨。ONのほうがUDSAに獲られるストレージが少ない。一部AMODE24のプログラムがあるならCEEUOPTで対応。

ANYHEAP 4K,4080,ANY,FREE（*） 16MB以上のランタイム用ヒープ・ストレージのアロケーション

BELOWHEAP 4K,4080,FREE（*） 16MB以下のランタイム用ヒープ・ストレージのアロケーション

CBLPSHPOP OFF

サブプログラム・コール時にPUSHHANDLE/POPHANDLEの発行を制御。OFFのほうがパフォーマンスが良い。但し、サブルーチンでエラー・ハンドリングを個別に行う（VSCOBOLⅡ互換性）場合はONが必要。

HEAP 4K,4080,ANY,KEEP,4K,4080（*）ユーザー用ヒープ・ストレージのアロケーション

LIBSTACK 32,4080,FREE（*）ランタイム用スタック・ストレージのアロケーション

RPTOPTS OFF（*）ランタイム・オプションのレポート出力

RPTSTG OFF（*）ストレージ使用状況のレポート出力

STACK 4K,4080,ANY,KEEP,4K,4080（*）ユーザー用スタック・ストレージ。ALL31（OFF）指定の場合、第三パラメーターにBELOWの指定が必要。

STORAGE NONE,NONE,NONE,0K（*）

ストレージの初期化。ランタイムによるNull 初期化が必要な場合は第一あるいは第三パラメーターに00を指定。但し、パフォーマンスへの影響有り。

TERMTHDACT UATRACE,CICSDDS,96 ダンプ出力の制御。CICSDDS 指定でCICSダンプ・データセットにダンプを出力。

TRAP ON（*） LEのコンディション・ハンドリングを有効化

図②-5.言語関連ツール

生徒：よし。コンパイルと連携編集が終わったので実行してみますね。・・・あれ、動きがおかしいぞ？

教授：ラインタイム・オプションはちゃんと確認しましたか？

生徒：LEにもランタイム・オプションがあるのですか？

教授：もちろんです。ランタイム・オプションはCICSリージョン全体に対して指定したり、アプリケーション・モジュール毎に指定したりできます。ランタイム・オプションを適切に指定しないと、予期しない動きをすることもありますよ。例えば、OS/VSCOBOLではWORKING-STORAGEの初期化が自動的に行われていましたが、LEランタイムではデフォルト値の場合は初期化を行いません。ストレージの初期化を自動的に行いたい場合には、STORAGEオプションの変更が必要です。


第３章-

❷

ツール名称用途入手方法

CCCA（COBOLandCICSCommandLevelConversionAid）

-OS/VSCOBOL、VSCOBOLⅡのソースをLEコンパイラーに対応したソースに書き換え

-IBMDebugToolに同梱

EPA（EdgePortfolioAnalyzer）

-コンパイル・オプションの調査-ロード・モジュールのコンパイラーの調査-再リンク・再コンパイルが必要なロード・モジュールの洗い出し

-サードベンダー・ツール

LIBMAP -ロード・モジュールのコンパイラーの調査-RES/NORESオプションの調査 -IBM社内開発ツール

ロード・モジュール・アナライザー -ロード・モジュールのコンパイラーの調査

-CICSサポートパックCH1A（無料）または-IBMDebugToolに同梱

114 115


第３章-

❷

教授：そうですね。LE化することでパフォーマンスに変化が生じる可能性がります。例えばストレージの使用状況やCPUの使用状況ですね。これらはアプリケーションを単体で稼働させただけでは見えにくいものなので、負荷テストを行ってLE化前後でのパフォーマンスを比較できるといいですね。本番環境での負荷テストは難しいでしょうから、開発環境をLE化する際に、移行前後で同じシナリオの負荷テストを実施してCPUやストレージの使用量を比較するとよいでしょう。

生徒：なるほど。移行計画に負荷テストを入れるようにします。

教授：24bitアプリケーションにも注意が必要です。24bitアプリケーションに対してはランタイム・オプションとしてALL31(OFF)を指定する必要があります。CICSリージョンのランタイム・オプションでALL31(OFF)とすると、本来は31bitで動かせるアプリケーションも16MB以下の領域を使用して稼働してしまうため、16MB以下の領域が不足してしまう恐れがあります。

生徒：それは困りますね。対処方法は無いのですか？

教授：CICSリージョンに対してはALL31(ON)を指定（デフォルト）して、24bitアプリケーションだけ個別にALL31(OFF)を指定することでストレージを効率的に利用できます。また、24bitアプリケーションが稼働時に使用するストレージについてもLE化すると増加する可能性がありますので、アプリケーションの31bit化が可能であれば31bit化を行ってALL31(ON)として稼働できるようにするのがよいですね。

生徒：他には何か、例えばLE化の進め方などについて何かありませんか？

教授：そうですね、LE化の進め方として、複数CICSリージョンある場合、リージョンごとに稼働するアプリケーションが明確にわけられるなら、LE未対応アプリが稼働するリージョンと、LE対応済みアプリが稼働するリージョンを分けて段階的にLE化していくという考え方もあります。

生徒：なるほど。全部いっぺんにやって一回で済ませるか、回数は多くなるけど順次LE化していくことで何か発生したときの影響範囲を狭めてリスクを減らすか、ということですね。

教授、どうもありがとうございました。おかげでお客様CICSのLE化が進められそうです。

教授：それはよかった。では今日はここまでにしましょう。


第３章-

❷

教授：LEのハンドル処理の変更の影響が疑われますね。LEではランタイム・エラーを検知した場合、ユーザーのコンディション・ハンドラーに制御が渡りますが、そこでコンディションがハンドルされなかった場合はエンクレーブを終了させてから4038アベンドを発行します。エンクレーブが終了してしまっているのでHANDLEABENDで拾うことができないのです。

生徒：元のプログラムはHANDLEABENDで拾うように作っているのでそれでは困ります。何とかならないのですか？

教授：LEではユーザー・ハンドラーのひとつとしてCEEWUCHAが提供されています。CEEWUCHAを使うことでHANDLEABENDに制御を渡すことができるようになります。CEE.SCEESAMP(CEEWUCHA)にサンプルがあります。このままアセンブルしても使えますし必要に応じてカスタマイズしてもいいです。アセンブル後はLEのランタイム・オプションでUSRHDLR(CEEWUCHA)を指定することで有効になります。

生徒：ありがとうございます。やっとアプリケーションの稼働確認ができました。ところで、CICSをLE化した場合には、実際にはどれくらいテストをするべきなのでしょ

うか？

教授：非常に難しい質問ですね。最低でも再コンパイル、再連係編集したアプリケーションについてはテストしておきた

いところです。できれば、ランタイムがLEランタイムになったということで稼働環境が変わっていますので、手を加えていないアプリケーションを含めて全アプリケーションをテストできるのが望ましいです。

生徒：さすがにそれは・・・工数と時間の制限に引っかかりそうなのですが・・・。

教授：全アプリケーションのテストというのは余裕がないと難しいですよね。CICSのバージョンアップ時のテスト方針があるなら、それに従うのもよいでしょう。アプリケーションのテストは、全ロジック全パターンをテストしようとすると非常に困難ですし負荷が高くなってしまいますから、どれくらいの範囲でテスト・確認できればよしとするか、お客様と相談して決めるようにしてください。

生徒：これで一通りアプリケーションの稼働まで確認できたのですが、他に何か注意すべきことはありますか？

11� 11�

第３章-

❸

CICSマイグレーションのここが知りたい③…ロガー環境のセットアップ（CICS/ESA…V4.1以前からの移行）

教授：まぁ、単純移行とはいきませんが、ロギングの仕組みをしっかり理解すれば大丈夫です。ロギングの仕組みの違いを表すとこんなイメージになります。

図③-1.ロギングの仕組みの違い

教授：IXGLOGRというのがロガーで、CICSとは別のアドレス・スペースで動作することになります。

生徒：新しく”ログ・ストリーム”というのが出てきましたね。

教授：これはログ書き出しの単位で、ログの種類毎に識別子が付けられます。ロガーは基本的にこのログ・ストリームの単位でログを管理します。

生徒：ログ・ストリームというのは実体としてはデータセットにマッピングされるのですか？

教授：それは構成の仕方によって違ってきます。まずロガーによるログの取得方法について基本的な考え方から整理しましょう。ロガーは内部的に3つのタイプのストレージに分割してログを管理します。

図③-2.ロギングに使用されるコンポーネント

CICS/ESA V4.1 以前 CICS TS 以降

CICS CICS動的ログ域

TRX

TRX IXGLOGR

After ImageUser Data

Before Image

<System Log>

<General Log>

<General Log>

<System Log>

ログ・ストリーム（DFHLOG）

ログ・ストリーム（DFHSHUNT）

ログ・ストリーム（General）

・・・

・・・

DFHJ01A

DFHJ01B

DFHJ99A

DFHJ99B

DFHJ02A

DFHJ02BAfter ImageUser DataAfter ImageUser Data

Before ImageBefore Image

CICS ロガー（IXGLOGR）

Log Manager

プライマリー・ストレージ

セカンダリー・ストレージ

ターシャリー・ストレージ（オプション）

プライマリー・ストレージのサイズがある閾値を越えたら、古いものがセカンダリーに移される=> "オフロード" と呼ぶ

必要に応じてテープなどにアーカイブ（オプション）

ログの書き出し先（冗長化して管理）

ログ管理を行う

第３章-

❸


ロガー環境のセットアップ（CICS/ESA V4.1以前からの移行）3

生徒：教授、今度CICS/ESAV4.1からCICSTSV4.1へ移行するプロジェクトに参画することになりました。

教授：旧4.1から新4.1への移行ですか。一気にジャンプ・アップですね。

生徒：はい、間のバージョンでの差分が積み重なるので細かい考慮点が沢山あるようなのですが、特にログの仕組みが大きく変わるという話を聞きました。

教授：そうですね、CICS/ESAV4.1の後継からは、CICSTransactionServerと製品の名前も変わり、ログを取得する際に使われるメカニズムがガラリと変わっています。

生徒：実はその辺がよく分かっておらず不安なのですが…

教授：トランザクション・サーバーにとって"ログは命"ですから、まずはログのメカニズムをしっかり押さえておきましょう！

CICS/ESAV4.1ではログのセットアップはどのように行っていましたか？

生徒：JCTにログ用のエントリーを定義しています。ログの実体としては、DFHJxxA/DFHJxxBというような2つのデータセットが使われます。そのうちDFHJ01A/DFHJ01Bはシステム・ログ用に使われるものですね。

教授：そう、それはCICSが提供するジャーナル管理の機能が使われているということなんです。CICSTS以降ではログ・マネージャー・ドメインという新しいドメインが提供され、OS提供のロガーを使ってロギングを行うようになりました。CICSとしてはログの管理をロガーにお願いするだけで、実際の管理はロガーが担うということです。ロガーを使うことで、複数CICSからのジャーナルのマージが可能になったり、ログのラップ・ラウンド防止、アーカイブ管理などの機能改善も図られています。

CICS上の資源定義についても、これまでジャーナルの定義をしていたJCTは廃止され、JOURNALMODELというオンライン資源定義を使用することになります。

生徒：ふーむ、機能変更が入ったというより、CICSとは全く別のコンポーネントを使うようになったということなんですね。うーん、それは移行がやっかいそうだな…

11� 11�


第３章-

❸

教授：そうですね。それからログが失われてしまうと整合性を保つことが出来なくなってしまいますので冗長化をしておくことが重要です。ロガーは自分のアドレス・スペースのローカル・バッファーにも同じ情報を保持しますので、CFと合わせて二重化されることになります。

生徒：これまではディスクの仕組みでログの二重化を考慮しなければいけませんでしたが、ロガーがその辺の仕組みを提供してくれている訳ですね。

ところで教授、CFは必須ですか？CFを構成していないお客様もいらっしゃると思うのですが…

教授：CFが無い環境の場合は、もう一つのDASDロギングと呼ばれる構成を利用することができます。

図③-4.DASDロギング

生徒：ふーむ、DASDロギングでは、CFの代わりにロガーのローカル・バッファーとステージング・データセットで二重化されることになるのですね。

教授：はい、DASDロギングの場合ステージング・データセットは必須ということになります。CFロギングの場合はステージング・データセットはオプションです。

基本的なロガーの仕組みが分かったところで、CICSがどのようにこのロガーの機能を使うことになるのか見ていきましょう。さて、CICSのログにはどういった種類のものがあったでしょうか？

生徒：えーと、トランザクション・ログを管理するシステム・ログ、フォワードリカバリーのためのログ、それからユーザー・ジャーナルなどがありますね。整理するとこんな感じでしょうか。

※LSN: Log Stream Name



ターシャリー・ストレージ

ログ・ストリーム・データセット

（オフロード・データセット）

DFHSMストレージ（オプション）

ステージング・データセット

オフロード

ロガー（IXGLOGR）CICSData Space

（Local Buffer）

ログ書き出しLog Manager LSN1LSN2LSNn


第３章-

❸

教授：図のように、まずロガーはプライマリー・ストレージ上にログを書き出します。

生徒：プライマリー・ストレージというのは具体的に何ですか？

教授：それはこの後お話しますが、まずはログの一次書き出し先と思ってください。このプライマリー・ストレージにログが溜まっていって、ある指定された閾値を超えたら古いログからセカンダリー・ストレージに移されていきます。これを”オフロード”と呼びます。

ユーザー・ジャーナルなど溜まっていく一方のログもありますのでセカンダリー・ストレージからさらにアーカイブを行う仕組みも提供されています。

生徒：基本的なログ管理の仕組みは分かりました。

教授：では次に具体的にどのようにログが管理されるかという話ですが、ログの管理方法としては大きく2種類に分けられます。一つ目はCF（CouplingFacility）ロギングです。名前の通りCF上でログを管理する仕組みです。

図③-3.CFロギング

生徒：ログはDASDに書かれるものと思っていましたが、CF上に取られるのですか…。なるほど！プライマリー・ストレージ=>セカンダリー・ストレージのような仕組みになっていますが、

プライマリー・ストレージがいわゆるバッファーのような役割になっているとも言えますね！これはパフォーマンスの改善も期待できそうですね。

CF

※LSN: Log Stream Name



ターシャリー・ストレージ

Log StructureLSN1LSN2LSNn

ログ・ストリーム・データセット

（オフロード・データセット）

DFHSMストレージ（オプション）

ステージング・データセット（オプション）

オフロードロガー（IXGLOGR）CICS

Data Space（Local Buffer）ログ書き出しLog Manager

120 121


第３章-

❸

教授：一般的には以下のような観点で配置を考えます。

● 用途別にストラクチャーを分割・ストラクチャー内のスペースを効率的に使用するため、ログの種類、書き込み量が類似したログ

ストリームを同一ストラクチャーに配置・一般的に、DFHLOG,DFHSHUNT,その他のログの種類毎にストラクチャーを分け、さらに

CICSリージョンの種類（TOR,AORなど）によってさらにストラクチャーを分割・一つのストラクチャー内のログ・ストリーム数は最大20程度が推奨

● 複数CFにストラクチャーを分散・CFが複数ある場合、ストラクチャーへのアクセス・バランスを考慮してストラクチャー配置を分

散するのが推奨。・ただし1CICSのDFHLOG,DFHSHUNTは同一CF上に配置。（システム・ログDFHLOG,

DFHSHUNTは、いずれかが失われればそのCICSは使用できなくなるため分散して配置することのメリットは無いため）

● 複数OSからストラクチャーを共用・OS障害またはIXGLOGR障害発生時にストラクチャーを共用している別OSから障害検知、オ

フロードが可能。（共用していない場合、障害IXGLOGRがリスタートするまでリカバリー不可）

図③-6.ストラクチャーの使い分け（CFロギングの場合のみ）

教授：例えばシステム・ログに注目して配置例を考えてみると以下のようなイメージになります。

図③-7.ログ・ストリーム配置例

DFHLOG（CICS1）

DFHLOG（CICS3）

DFHSHUNT（CICS1）

DFHSHUNT（CICS3）

CF1

DFHLOG（CICS2）

DFHLOG（CICS4）

DFHSHUNT（CICS2）

DFHSHUNT（CICS4）

CF2

CICS1

MVS1 MVS2PR/SM

CICS3 CICS4

MVS3 MVS4PR/SM

CICS2

複数MVSからのストラクチャー共用

ストラクチャーを複数CFに分散

DFHLOG/DFHSHUNTを同じCFに配置

一つのストラクチャーには同じ用途のログストリームを配置


第３章-

❸

図③-5.ログの種類

教授：はい、そうですね。その中でもシステム・ログは特殊な管理がされます。先にお話した通り、CICSのログはログ・ストリームという単位で管理されますが、システム・ログはCICSリージョン毎にDFHLOG,DFHSHUNTと呼ばれる2つのログ・ストリームが使われます（図③-1参照）。

生徒：その他のログは、ログ毎にそれぞれログ・ストリームが使われることになりますか？

教授：はい、そうです。ただ、システム・ログ以外のジェネラル・ログ（フォワード・リカバリー・ログ、ユーザー・ジャーナル等）は、複数のCICSリージョン間でログ・ストリームを共用することもできます。CFロギングの場合であれば、OSを跨って共用することも可能です。

システム・ログは共用できないので各リージョンでそれぞれログ・ストリーム（DFHLOG,DFHSHUNT）を定義する必要がありますが。

生徒：なるほど。とりあえず現行を踏襲する形で移行する場合は、現行使用されているログを整理し、それに対応するJOURNALMODEL定義、ログ・ストリームを作成するようなイメージでしょうか。

教授：はい、そのイメージで正しいです。ログ・ストリームの作成に関してですが、CFロギングの場合ログ・ストリームはストラクチャー内に保持されますので、ストラクチャーとログ・ストリームの配置を意識する必要があります。例えば、CF内には複数のストラクチャーを保持することができますし、一つのストラクチャー内に複数のログ・ストリームを保持することもできます（図③-3参照）。

生徒：その場合、ストラクチャーをどのように分割して使い分ければいいのでしょうか？何か指針はありますか？

用途 CICS/ESA上の構成

システム・ログトランザクション・ログ管理 JCT（DFHJ01A/DFHJ01B）

ジェネラル・ログ

ユーザー・ジャーナルアプリケーションでのジャーナル書き出し JCT

フォワード・リカバリー・ログLOG-OF-LOGS

VSAMのフォワード・リカバリー用の情報取得CICSVR（VSAMRecovery）などのツールによって利用される

JCT,FILE定義（FCT）

自動ジャーナルファイル制御、端末制御のアクティビティーを自動的に記録

JCT,FILE定義（FCT）,PROFILE定義

122 123


第３章-

❸

教授：ログのアーカイブやモニター /統計情報管理など、運用手順の見直しも忘れずに検討して下さいね。

生徒：まぁ、その辺りはログに限らずバージョンアップにつきものの話ですので、その他の非互換とも合わせて対応していくようにします。

教授：そうですね。ではログ環境設定に必要な作業についておさらいしておきましょう。

● 現行CICSログ環境の調査・CICSリージョン数・使用しているジェネラル・ログ（フォワード・リカバリー用、ユーザー・ジャーナルなど）● 新規ログ環境の計画・CFロギングorDASDロギングの選択・ストラクチャー、ログ・ストリームの配置（CFロギングの場合のみ）・サイズ見積（ユーティリティー利用可）● RACFの定義（オプション）・ロガーでセキュリティー・チェックを行う場合のみ（お客様要件に依存）● SMSの定義● ロガーの設定・ログ・ストラクチャーの定義（CFロギングの場合のみ）・ログストリームの定義● CICS関連リソースの移行・JCT,SIT,スタートアップJCL,● 運用手順見直し・ログのアーカイブ・統計/モニター情報管理、ログ処理用バッチ

図③-9.ログ環境移行に関する主な作業項目

生徒：ふむふむ、ようやくやるべきことのイメージが出来てきました！

教授：それはよかった。では最後に一つ注意点を。ロガーを使う場合、CF上（CFロギングの場合）、もしくはDASD（DASDロギングの場合）にログが書かれることになりますが、同等の内容をローカル・バッファーにも保管し、オフロードされるまで保持します。そのため、リアル・ストレージが従来の環境より消費されやすくなるのでストレージの使用量は要チェックです。

生徒：なるほど。ストレージが不足する場合ページングが多発してしまうので、場合によってはリアル・ストレージの増強、ページ・データセットのチューニングも必要かもしれませんね。

教授：それでは、移行プロジェクト頑張って下さい。

生徒：ありがとうございました。


第３章-

❸

生徒：なるほど、この辺りは新規に設計しなければいけないということですね。

教授：ちなみにDASDロギングの場合であれば、CF上のストラクチャーの考慮などは不要ですのでもっとシンプルになりますよ。

生徒：なるほど。他に定義周りでロガーを使うことによる変更点などはありますか？

教授：OS関連では、ロガーを使う場合、SMS（StorageManagementSubsystem）は必須です。それからロガーでセキュリティー・チェックを行いたい場合はRACFの定義も必要になります。

CICS関連の設定周りでも旧環境から引き継ぐものについては非互換部分を修正する必要があります。

生徒：CICS関連の設定というと？

教授：JCT、SITパラメーター、スタートアップJCL、ログ処理用のバッチなどです。

● JCT: 廃止・JOURNALMODEL定義に移行● 新規API・EXECCICSWAIT/WRITEJOURNALNAME（WAIT/WRITEJOURNALNUMの置き換え）● 新規SPI・EXECCICSDISCARDJOURNALMODEL/JOURNALNAME・EXECCICSINQUIREJOURNALMODEL/JOURNALNAME/STREAMNAME・EXECCICSSETJOURNALNAME● 削除SPI・EXECCICSINQUIREJOURNALNUM/VOLUME・EXECCICSSETJOURNALNUM/VOLUME● GLOBAL USER EXITS・XLGSTRM-新しいログ･ストリームへの接続時に呼び出され、ログ･ストリーム名の変更が可能　　 ※サンプル･プログラムを提供：CICSTS41.CICS.SDFHSAMP(DFH$LGLS)・廃止:　XJCWR/XJCWB● URM・DFHXJCO、DFHXJCCは廃止● ユーティリティー・DFHJACDU、DFHJCJFP、DFHFTAP、DFHTEOPは廃止● SITパラメーター・変更:　SPCTRxx/STNTRxx（LGの追加）、AKPREQ（要チューニング）・削除:　DBUFSIZE、JCT、JSTATUS、SERIES=PURGE・追加: LGDFINT（LogDeferインターバルの指定）

図③-8.ログ関連の非互換項目

124 125

第４章

・第4章・

押さえておきたいDB2マイグレーションのポイント2010年10月にDB2…for…z/OS…V10が発表されました。V10への移行パスは、DB2…for…z/OS…V9だけでなくV8からのスキップ･マイグレーションもサポートされます。このため、V10は今後のDB2移行における主要な移行先となることが予想されます。一方で、DB2…for…z/OSの移行は複数のステップを経る必要があることから、移行に要するワークロードが大きくなりやすいとみなされて、現在もV8以前に留まっているお客様が多くおられます。ポイントをしっかりと押さえておけば、DB2…for…z/OSの移行は決して難しくはありません。DB2…for…z/OSの移行を、スムーズに進めるために押さえておきたいポイントとして、バージョンによらず大切な考慮事項や移行に使える便利な機能、さらにV10への移行の特徴をご紹介します。

●

移行計画での考慮点（1）

移行計画での考慮点（2）

非互換項目のキーポイント

REBINDとアクセスパス管理の鍵

V10への移行での注意点

1

2

3

4

5

12�

押さえておきたいDB2マイグレーションのポイント①…移行計画での考慮点（1）

12�


第４章-

❶

教授：CMへ移行するとDB2ライブラリーがVnとなり、Vnのコード上でDB2が稼働します。このCM上で一定期間業務を稼働させ、問題なく動くことを確認します。

そして、ENFMでDB2カタログ/ディレクトリーをVnのフォーマットへ変換すると、NFMになります。ENFMは実際には過渡的なモードなので、CM～ENFM～NFMへの流れは実質1ステップと考えてよいでしょう。

ですから、DB2の移行は1.CMへ移行するステップと2.NFMへ移行するステップの2つからなると覚えてください。

移行に要する期間が長くなるのは、CMで一定期間業務を稼働させることが主な理由でしょう。

移行ステップごとの詳細はまた後でみるとして、まずは大まかな移行のイメージをつかんでください。

生徒：はい。実際は2ステップということですね。

教授：ただし、このように他の製品とは少し異なるスタイルで移行を行いますから、事前にしっかりとした計画を立てることが重要になる点は注意してくださいね。ポイントを押さえた準備がスムースな移行につながります。

生徒：分かりました。

教授：さて、では移行の概要を押さえたら、移行の準備に入りましょう。何から始めたらいいでしょうか？

生徒：ええと・・・

教授：まずは、移行に大きく影響する環境情報を調査することから始めましょう。必要な情報は、以下の3つに分けて説明できます。

1.移行先DB2の前提条件

2.システム環境情報

3.資源使用状況

移行計画での考慮点（1）1

生徒：教授、ご相談したいことがあるのですが・・・

教授：はい、私の力になれることなら。何か困ったことでもあるのですか？

生徒：今度DB2forz/OSのバージョン・アップ・プロジェクトを担当することになったのですが、DB2の移行は大変だと聞きますし、実際何から始めていいのか・・・

教授：なるほど。では、まずDB2の移行の概要を押さえましょう。 DB2の移行というと、何が思い浮かびますか？

生徒：複数のステップがあるとか・・・移行が長期間にわたるとか・・・

教授：確かにDB2の移行は複数のステップがあります。 DB2を移行しようとすると、まずDB2をCM（変換モード）と呼ばれるモードに移行す

る必要があります。その次にENFM（新機能使用可能化モード）、さらにNFM（新機能モード）へと移行します。

生徒：3段階ということでしょうか。やはり大変そうですね・・・

教授：仮に、バージョンn-1からバージョンnに移行する場合の、移行ステップの図を見てみましょう（①-図1）。

図①-1.DB2の移行ステップ

第４章-

❶Vn-1 NFM

列追加等再編成等

カタログ移行過渡期入れ替え

Vn-1 DB2カタログ/ディレクトリー

Vn-1ライブラリー

ユーザー・データ

Vn CM

Vn CM DB2カタログ/ディレクトリー

Vnライブラリー


Vn NFMVn ENFM

Vn DB2カタログ/ディレクトリー

Vnライブラリー


NFM：New Function Mode　　CM：Conversion Mode　　ENFM：Enabling New Function Mode

フォールバック不可フォールバック不可フォールバック不可フォールバック不可

新機能利用可能CMで稼働保障移行準備

12�


12�


第４章-

❶

教授：そして、次に把握すべき情報は、現在のシステム構成や定義情報です。データ共用かどうか、分散環境からの接続があるかといったシステム構成、ログ

やDB2カタログ/ディレクトリーの配置やサイズ等の物理設計が必要です。また、DSNZPARMやDDL,DCLのような定義情報やアクセスパス管理に関する情報も抑えておくことが重要です。

生徒：このような情報は、なぜ必要なのですか？

教授：例えば、DB2データ共用環境だったら共用グループ内のDB2メンバーを全て同時に移行するか、それとも順にローリング移行させていくかで移行手順が変わります。

また、この後非互換項目の検討をしますが、データ共用環境特有の非互換項目があれば対応が必要と判断できますよね。DRDA接続の有無や災対サイトがあるかどうか等も、同様に移行作業に影響を及ぼします。

さらに、移行に伴ってBIND/REBINDを検討する必要がありますが、その際に現在のアクセスパス管理がどのように行われているかという情報が必要です。

生徒：これからの移行作業計画を立てるためのベースとなる情報ということですね。

教授：ええ、その通りです。次に3点目として資源使用状況の把握があります。移行をすると、DB2が使用するCPUやメモリといった資源の使用量が変わる可能性

があります。ですから、事前に移行後の使用量を見積もり十分な資源があることを確認する必要があります。

生徒：そういえば、先輩が、CPUが増加するかもしれないと心配していました。

教授：CPUだけでなく、メモリやディスクの容量も気をつける必要があります。 CPU、実メモリ、仮想メモリ、ディスクともバージョンが上がるにつれて増加する傾

向があります。ただし、V10に関しては、CPU使用率は前バージョンと同じ程度、新機能を利用すれば減少する可能性もあります。また、仮想メモリはこれまで、特にV8まではDSNDBM1アドレス・スペースの2GB以下の使用量が逼迫しやすい問題がありましたが、V10ではDB2が使用するほとんどの領域が2GBより上にアロケーションされるようになり、2GB以下の考慮はほぼ不要になったと言えます。

一方、実メモリは、バージョンを重ねるごとに2GBより上の仮想メモリを積極的に使用していくこともあり、増加する傾向はV10でも変わりません。ディスクに関しても、DB2カタログ／ディレクトリーの容量増加に注意が必要です。バージョンアップするごとに、プラン／パッケージのサイズが大きくなりますし、カタログ／ディレクトリーに格納される情報量も増えるためです。

第４章-

❶

1. 前提条件: DB2と関連する製品がDB2がサポートするバージョン/レベルかどうか　●ハードウェア、OSのversion、CFのレベル　●DB2に関連するプログラミング言語の種類、version、LE化実施の有無　●接続のある他サブシステムの種類、version　　・ホスト上のローカル接続（IMS、CICSなど）　　・ネットワーク経由のリモート接続（DB2Connect,DB2forLUWなど）　●関連製品　　・OMEGAMON製品、DMtool製品（QMF、HPUなど）、SORT製品（DFSORTなど）、

セキュリティ関連製品（RACFなど）

2. システム環境情報：移行作業に影響する、現行環境のシステム構成や定義情報　●データ共用かどうか　●DRDA接続の有無　●災害対策サイトの有無　●システム・データセットのサイズ、物理配置　●アクセスパス情報　●DSNZPARM等の定義情報やDDL,DCL,アプリ・ソースの保管状況

3. 資源使用状況：資源使用量の見積もりのための情報　●モニタリング運用　●CPU使用率、実記憶域使用量、仮想記憶域使用量、ディスク使用量

図①-2.移行計画時に把握すべき情報

生徒：最初の前提条件は、確かに基本的な情報ですよね。 DB2の前提条件を確認するには、どんな資料を確認すればいいですか？

教授：DB2の前提条件はそれぞれのバージョンでProgramDirectoryと呼ばれる公式な資料にまとまっています。製品発表後、随時改定されていきますので、必ず最新情報を確認してくださいね。

ProgramDirectoryには、HWやOS、ミドルウェア等DB2の主だった関連製品についてサポート状況が記述されています。ただし、他社製ツール等には記述されていないものもありますので、そのような場合はツール側の情報でサポートがあるかどうかを確認してください。

現行環境で使用している製品がDB2の前提条件を満たしていないと、DB2の移行と同時にそれらの移行も計画しなければいけませんから、前提条件はとても重要です。

生徒：なるほど、早速調査したいと思います。

130


131


第４章-

❶

図①-3.DB2のマイグレーション・パス

生徒：このV8からV10への矢印があるということは、V9を経由しなくてもV10へ移行できるのですか？

教授：はい。V8からV10はスキップ・マグレーションがサポートされます。

生徒：これは嬉しい情報です！最新まで一気に移行できれば、しばらく移行の心配をしなくてすみます。

教授：ええ。現在V8のお客様にとっては、V10へのスキップ・マイグレーションは大きな選択肢となるでしょう。ただし・・・

生徒：何か考慮点がありますか？

教授：特別な考慮点があるわけではありませんが、2バージョンを一度に移行するわけですから、必要な調査や対応項目は当然多くなります。

生徒：しっかりした準備が肝ということですね！

教授：その通りです。

生徒：ところで少し話は変わるのですが・・・、実は今回担当するプロジェクト以外にもDB2を使っているシステムがあって、そこはまだV7なのです。今後移行を検討しなければいけなくなると思うのですが、この場合、スキップ・マイグレーションは使えませんよね。

教授：ええ、そうですね。では、移行方法の選択肢について整理しましょう。大まかに言って、DB2の移行方法は、DB2が提供する移行パスを利用する方法と、

移行パスを通らない方法の2つがあります。

＊2. V10CMおよびV10ENFMは、正確には移行前の　バージョンによって呼び方が異なる。- V8から移行した場合は、V10CM8, V10ENFM8- V9から移行した場合は、V10CM9, V10ENFM9

V10NFM

V9NFMV9ENFM

V9CM

V8NFMV8ENFM

V8CM

V7

V10CM＊2V10ENFM＊2

第４章-

❶

生徒：なるほど。V10への移行では、CPUや仮想メモリはあまり心配しなくてよさそうですが、実メモリやディスクは注意が必要そうですね。

教授：はい。CPUが増加しないと言っても、それはDB2サブシステム全体での話であって、個々のSQLを比較すると増加するものも減少するものもあることは理解しておいてくださいね。


教授：まずは、現在のモニタリング運用がどのように行われているかを確認し、必要な情報が得られるかを調査しましょう。情報が足りない場合は、追加でモニタリングの手段を考える必要があります。

生徒：はい。OMPE＊1を使用していると聞いているので、どのように運用しているか確認します。

必要なモニタリング情報が得られたら、現在の使用量にどの程度余裕があるかを見ればよいですよね。

＊1.正式名称：TivoliOMEGAMONXEforDB2PerformanceExpertonz/OS

教授：ええ。ただし、使用量というのは、平均ではなくピーク時を確認する必要がある点に注意してください。月末／月初、年次などのピークの使用量を把握し、見積もりのベースにします。

生徒：そうか。平均値に余裕があっても、ピーク時に100%を超えて、パフォーマンスが劣化してしまったら意味がありませんものね。

教授：そういうことです。さて、必要な情報を確認したところで、次は移行パスの話をしましょうか。今度の移行プロジェクトはDB2のどのバージョンからどのバージョンへ上げるので

すか？

生徒：現行環境はDB2V8なのですが、実はまだ移行先が決まっていません。最新のバージョンは確かV10でしたよね。

教授：そうです。今サポートがあるバージョンはV8,V9,V10ですが、どのバージョンからどのバージョンへ移行することが可能か、つまり移行パスを図にすると、以下の図3のようになります。

132


133


第４章-

❶

生徒：方法2は、移行パスを通らない方法ですね。これは、CMを経ない分移行ステップは1回で済むと考えてよいでしょうか。

教授：そうですね。ですが、いくつか考慮点が出てきます。図①-4では、6つの考慮点を紹介しています。まず、データ量の大きいお客様ではデータ移行（UNLOAD／LOAD）にかかる時間が問題になる可能性がありますので、データ移行時間の見積もりをしっかり行う必要があります（考慮点（1））。

また、新しいDB2上で表を再作成したりパッケージをBINDしたりしなければいけないので、DDLやプログラム・ソースが適切に管理されていることが前提になります（2）。加えて、BINDによりアクセスパスが変わる可能性があるため、その検証をどうするか考慮が必要になります（3）。フォールバックに関しては、旧環境を保管しておく必要があります（4）。つまりシステム全体でフォールバックすることになるため、DB2のみフォールバックが必要でも、OSや他のミドルウェアも同時に旧環境に切り替える必要が生じます（5）。さらに、移行後更新されたデータをどう反映するのか方法を考える必要もあります（6）。

生徒：なるほど、確かに難しそうです。ですが、1回のステップで移行できる点はやはり魅力的です。

教授：本来は、DB2提供の移行パスを通ることが推奨ではありますが、DB2を再作成する方法も、現行のバージョンが古く一気に数バージョン先に移行したい場合や、H/WやOS,ミドルウェアを一斉更改するような要件がある場合は、有効な方法と言えるでしょう。

生徒：はい。分かりました。今回のプロジェクトではDB2提供の移行パスを使いたいと思いますが、他のDB2で

は別の方法もあることを念頭に検討していきます。

教授：そうですね。それが良いでしょう。

生徒：少しずつDB2の移行が分かってきた気がします。

教授：それは良かった。では、次回は移行ステップの詳細やスケジュールを立てる際のポイントを見ていきましょう。

生徒：分かりました！楽しみにしています！

第４章-

❶

移行パスを経由するなら、まずV7からV8に移行し、次にV8からV9もしくはV10に移行する必要があります。

生徒：うーん、それは時間がかかりそうです。移行パスを通らない方法とはどんな方法でしょうか。

教授：DB2を新しいバージョンで新規作成しデータを移行する、いわば引越し型の移行方法です。データは、UNLOAD/LOADユーティリティーなどを使って旧環境から新環境に移行します。

DB2の移行パスを利用する場合と、新しいDB2を再作成する方法を比較してみましょう。

図①-4.2種類のDB2移行方法と考慮点

生徒：方法1は、これまで話をしてきた方法ですね。CMで一定期間稼働させた後、ENFM,NFMに上げるという・・・

教授：ええ。この場合、CMでは新機能が使用できなかったり、NFMに移行するまでの期間が長くなったりはしますが、フォールバックが保証される環境（CM）で十分に稼働確認ができます。

V8NFM

カタログ移行過渡期

V8 DB2カタログ/ディレクトリー

V8ライブラリー


V8NFM

旧環境




V10 NFM

新環境



ユーザー・データユーザー・データを

コピー

V10CM8

V10CM DB2カタログ/ディレクトリー



V10NFMV10ENFM8




方法1

方法2

（1） V10新機能は利用不可

（2） CMで一定期間稼働させる

ユーザー・データをコピー

移行作業時間の長時間化

フォールバック対象範囲の拡大

フォールバック環境として旧環境を保管しておく

アクセスバス検証の実施が必要

フォールバック実施時、データ差分の反映が必要

新環境でオブジェクト作成、PLAN/PACKAGEのBINDが必要

（4）

（6）

（5）

（1）

（2）

（3）

134 135

第４章-

❷

押さえておきたいDB2マイグレーションのポイント②…移行計画での考慮点（2）

生徒：今度担当するシステムは、DB2V8からV10へ移行パスを通って移行したいと思っていますので、この前提でお話をお願いできますか？

教授：いいでしょう。といっても、この段階で考慮するポイントは、バージョンごとでそれほど大きくは違いません。

さて、それでは、移行ステップの詳細を見てみましょう。図②-1を見てください。

生徒：前回は、V8からCM,ENFMを経てV10NFMに移行するという流れを、習いました。

教授：そうでしたね。今回はさらに、各ステップの役割と大まかなスケジュールを確認しましょう。まず、V8からCM（正式にはV10CM8）への移行では、DB2のライブラリーがV10

のものと入れ替わると同時に、DB2カタログ/ディレクトリーへ列の追加や列定義変更、索引追加といった変更が加えられます。この変更はDSNTIJTCというDB2提供ジョブに含まれるCATMAINTユーティリティーが行います。

生徒：CMは、V10のコードで業務を稼働させ、問題なく動くことを確認するということでしたよね。図②-1からすると、1～2カ月程度がおすすめなのでしょうか。

教授：ええ。正確には、月末・月初めのような業務量のピーク日を含むように一度ビジネスサイクルをまわすことが推奨です。

CMでもう1つ重要なのは、V8へのフォールバックが可能であることです。つまり、フォールバック可能なモードで一連の業務の稼働確認を行うことがCMの主な目的です。

生徒：何か問題があったらV8に戻ることができるわけですね。

教授：CMでの稼働確認が済んだらNFMへ移行しますが、ここではDB2カタログ／ディレクトリーの再編成や再構築が行われます。これは2つの移行ジョブDSNTIJENとDSNTIJNFに含まれるCATENFMユーティリティーにより実行されます。この2つのジョブにはさまれた期間がENFMということになります。

生徒：なるほど。だからENFMは過渡的なモードであり、普通ENFM上で業務を稼働させることはないのですね。

教授：はい、そういうことです。ここでのDB2カタログ／ディレクトリーの変更は、比較的大きな変更を行うため、環境によって数分から数十分かかる可能性があります。

そして、NFMに移行すると、新機能が使用できるようになるとともに、DB2の機能ではフォールバックできなくなります。

第４章-

❷


移行計画での考慮点（2）2

生徒：教授、今日は移行ステップの詳細とスケジュールの立て方についてのお話ですよね。

教授：ええ。今回のテーマは、移行計画段階でスケジュールをたてる際に重要になるポイントです。以下の3つの観点からお話しましょう。

1.移行ステップの詳細 2.スケジュール計画のポイント 3.フォールバック計画

まず、スケジュールをたてるには移行ステップをよく理解することが必要ですね。その上でスケジュールをたてますが、その際のポイントとしてフォールバック計画を紹介します。

図②-1.DB2V8からV10への移行の流れ

NFM：New Function Mode　　CM：Conversion Mode　　ENFM：Enabling New Function Mode

V10 CM8 V10 NFM

V10DB2カタログ/ディレクトリー






V8 NFMV10ENFM8

新機能利用可能CMで稼働保障移行準備







CATENFMCOMPLETE（DSNTIJNF）

CATMAINTUP DATE

（DSNTIJTC）

CATENFMSTART

（DSNTIJEN）

データ共用環境で共存可能

共存期間

フォールバック不可

1～2ヵ月数分

フォールバック可

13� 13�

第４章-

❷


図②-2.DB2V8からV10への移行スケジュール例

生徒：全体としては6カ月間のスケジュールを引いていますね。

教授：もちろん、環境によってもっと長くなることもありますし、短くできる可能性もあります。

生徒：スケジュールを立てる際は、どんなことに気をつけたらいいでしょうか。

教授：まず、図②-2の本番およびテスト環境のスケジュールとマイルストーン等のイベントを確認してください。気づくことはありますか？

生徒：移行の計画書、手順書の作成は当然必要ですよね。移行を始める前に、新規アプリ開発・テストの凍結とありますが、これはなぜ必要なの

でしょうか。

教授：図②-2にもありますが、通常、開発・テスト環境の方が先にバージョンアップし、本番環境はその後になります。もし、バージョンアップした環境の他に開発環境がないなら、本番と開発のバージョンが異なってしまいますので、バージョンが異なる間は新規アプリのリリースはできません。ですから、新規開発の凍結をします。

別途環境が用意できるなら、継続して開発してリリースすることができます。

▲ 移行計画書作成▲ 移行/フォールバック手順書作成 ▲ NFMテスト結果報告

▲ フォールバックSPE適用、PTE適用凍結

時間（月単位）

マイルストーン

その他イベント

本番環境移行

テスト環境移行

既存アプリ

基本機能

新機能

非互換項目

アクセスバス

▲ ピーク日

1 2 3 4 5 6

▲ 新規アプリ開発・テスト凍結　 ※別途V8環境を用意すればテスト継続可能

▲ CMテスト結果報告/判定

フォールバックフォールバック

移行リハーサル再移行移行リハーサル再移行

テスト

V8性能テスト CM稼働性能テスト

V8基本機能確認 CM基本機能確認 NFM基本機能確認

新機能調査 CM新機能テスト NFM新機能テスト

非互換調査/V8修正テスト CM修正テスト NFM修正テスト

アクセスバス検証

NFM稼働性能テスト

V8 CM

V8 CM NFM

NFM

第４章-

❷


生徒：ところでちょっと思いついたのですが、V10の新機能を使わないなら、CMのまま稼働させNFMには移行しないという選択肢はありませんか？フォールバックが保障される状態でいられると安心です。

教授：気持ちは分かりますが、やはりCMに留まらずNFMに移行することを推奨します。本来移行の目的は、新しいバージョンの新機能を利用してパフォーマンスの改善や運

用の効率化を図ることです。CMではほとんどの新機能は使用できませんから、NFMまで移行し新機能の活用を考えるべきです。それにCMの主な目的は稼働確認であり、そもそも長期間留まることを意図したものでもありません。

また、V10へ移行する前提がV8NFMであるように、次のバージョンへの移行ではNFMであることが必須です。

生徒：そうですか。分かりました。

教授：図②-1でもう1つお話したいことがあります。それは、データ共用環境についてです。担当するプロジェクトにDB2データ共用環境はありますか？

生徒：今回は単体と聞いています。でも今後担当する可能性もありますから、教えてください。

教授：データ共用の場合、まず1つのDB2メンバーをCMへ移行します。このとき他のメンバーはまだV8ですが、CMの間はV8と共存可能です。この期間中に全てのメンバーをCMに上げる必要があります。全てのメンバーがCMになったら、CATENFMユーティリティーをいずれか1つのメンバーで実行すればグループ全体がNFMとなります。

ただしCMとV8が共存可能といっても、実際に共存期間を設けると、それに伴う考慮点が発生します。一定時間業務を止めることが可能なら、データ共用メンバー全てを一度の業務停止期間中にCMまで移行することがお勧めです。どうしても止められない場合、1メンバーずつバージョンアップする方法（ローリング移行）を検討してください。その場合も共存期間はできるだけ短くすることが推奨になります。

生徒：分かりました。移行のために業務が停止できる時間があるかどうかがポイントですね。

教授：さてそれでは、次にスケジュール計画のポイントに移りましょう。図②-2に大まかな移行スケジュールの例を示します。

13� 13�

第４章-

❷


教授：そうですね。非互換の影響調査、修正が必要な項目の洗い出し、修正テストには、一般的に多くのワークロードが必要になります。一口に修正といっても、V8時点で対応できるものもあれば、V10への切り替えと同時に対応する必要があるものなどさまざまです。

計画初期では、正確に必要となるワークロードを把握することは難しいですが、余裕を持って計画を立てましょう。非互換項目については、次回（③非互換項目のキーポイント）でまとめる予定です。

生徒：はい、楽しみにしています。

教授：移行後のREBINDを行うタイミングと、アクセスパス検証も注意してスケジュールする必要があります。パフォーマンスの観点からは、移行後にPLAN/PACKAGEのREBINDを実施することが推奨されますが、REBINDを行うことでアクセスパスが変化する可能性があります。一概に変化することが問題ということはありませんが、一部パフォーマンス劣化につながるアクセスパスが選択されてしまうケースがあります。REBINDを行うかどうか、行う場合の対象範囲、そしてアクセスパスの検証方法などを計画に組み込む必要があります。アクセスパス管理方法については、第4回のコラムで詳しくお話します。

生徒：アクセスパス管理はいつも問題になります。ぜひ教えてください。そのほかに注意点があるでしょうか。

教授：スケジュールに大きく影響するところでは、OS、言語環境や他のミドルウェアなど、併せて移行を計画する製品がある場合、それらの移行スケジュールと調整が必要になりますね。

生徒：考えることがたくさんありますが、少し全体像が見えてきました。

教授：最後に、先ほど後回しにしたNFM～CMへのフォールバックについてお話しましょう。具体的な方法は環境にも依存してさまざまな選択肢がありますが、NFMで問題が発生した場合の対応方法は大きく分けて2つあります。

1つ目は、CM*（スター）に戻る方法です。CM*は、CMに似ていますがいったんNFMに移行したことを示すモードです。CM*へはDB2の機能で戻ることができます。なお、同様にENFM*に戻ることも可能です。

生徒：なるほど、では2つ目はどのようなものでしょうか。

第４章-

❷


生徒：テスト環境では、V8からCMへの移行もCMからNFMへの移行でもフォールバックが計画されていますね。

教授：はい。テスト環境での移行では、必ずフォールバック手順も含めるようにしてください。 CM～V8とNFM～CMの2段階がありますが、前者はDB2の機能で提供されます

から、その手順に従います。後者は本来戻るべきではありませんが、移行方針としてフォールバックの可能性を含めると判断した場合は、フォールバック計画を作成し検証しておく必要があります。NFM～CMへのフォールバックについては、後でまとめます。

生徒：ピーク日とあるのは、先ほども出た業務的なピークの話ですね。

教授：ええ、そうです。本番環境のCM稼働期間としてピーク日を含めた一定期間を確保しましょう。ビジネスサイクル中の主な業務が問題なく稼働することに加えて、ピーク日のパフォーマンスや資源使用量が許容できる範囲内かどうかを確認します。

生徒：図②-2には、テストの種類がいくつか載っていますが、テストの計画も大事ですよね。

教授：テスト項目として、まず挙げられるのは、既存アプリケーションの稼働確認テストや性能テストです。また基本機能テストでは、ユーティリティーやコマンドなどの運用も含めて問題ないことを確認します。

これらはお客様環境にテストセットがある場合も多く、あればそれらを利用できます。特にない場合は、少なくとも業務やパフォーマンスの観点から重要なアプリケーション、運用をカバーするようにテストを計画しましょう。

生徒：なるほど。

教授：同時に、CPUやメモリー等システムリソースの使用量を確認することも重要です。その結果によってリソースの増強を計画する必要が出てくることもあります。

生徒：新機能テストというのは、積極的に新機能を使用しなければ必要ないテストでしょうか。

教授：新機能には、ユーザーが意図して積極的に使用する新機能の他、意図しなくても使用される新機能も含めて考える必要があります。例えばV10で言えばDBM1アドレス・スペースのメモリー・マップの変更のように、ユーザーが意図しなくても自動的に使用される機能もあります。

自動的に使用される新機能は、非互換項目の1つと考えてもいいかもしれませんが、いずれにしても、このような機能の影響を洗い出し、必要であればテストを計画します。

生徒：非互換項目は、特にワークロードがかかりそうなイメージがあります。

140 141


第４章-

❷

生徒：確かに、そうですね。

教授：今日は、移行計画におけるスケジュール関連のトピックを紹介しましたが、いかがでしたか。

次回は、非互換項目のポイントをお話したいと思います。

生徒：とても勉強になりました。非互換項目は今日のトピックの中でも重要なポイントとして紹介されていましたね。

楽しみです！


第４章-

❷

教授：DB2サブシステム全体をCMだった過去の時点に戻す方法です。つまり、CMの一時点で整合性のあるシステム全体のバックアップを取得しておき、その時点に戻ります。

これは、DB2の機能ではありませんから、データの整合性はユーザーが保障する必要があります。

生徒：DB2を過去の時点に戻すということはユーザーデータも過去に戻ってしまいますよね。そうすると、NFMに移行してからフォールバックするまでの更新データが失われてしまうのではないでしょうか。

教授：その通りです。ですから、対応方法を用意しておかなければいけません。例えば、フォールバック前にいったん更新されたデータをUNLOADしておき、フォー

ルバック後にLOADを行う方法があります。このようにすれば、最新の業務データを反映できます。

そのほか、業務的な追いつき処理を行うという方法もあります。

生徒：追いつき処理の仕組みを作るのは大変そうですが、UNLOAD/LOADもデータ量によっては作業量が多くなりそうです。

教授：どちらも確かに難しいですね。できれば、フォールバックするかどうかの最終的な判断を行うとともに、以後は問題が

起きてもフォールバックは検討しないというチェックポイントを予め決めておくことが望ましいです。そうすれば、チェックポイントまでの限定された更新データを反映する手順を作成しておけばよいことになります。

フォールバックはNFM移行後時間が経つほど難しくなります。データの更新のみでなくDDLやアプリ変更（REBIND等含む）、ユーティリティーが実行されるとさらに考慮点が増えます。

生徒：時間がたつほど考慮点が増えるのですね。チェックポイントを入れるようにしたいと思います。

ちなみに、NFMで問題が発生した場合の戻し方は、方法1と方法2はどちらが推奨なのでしょうか。

教授：それは、発生した問題によります。 NFMの新機能に依存した問題なら、CM*に戻ることで対応可能と考えられます。逆にカタログ／ディレクトリーの構造のように、CM*とNFMで変わらない点が原因で

あると、CM*に戻っても解決が期待できませんから、他のフォールバック方法を検討する必要があります。

142 143

押さえておきたいDB2マイグレーションのポイント③…非互換項目のキーポイント

第４章-

❸

教授：一旦表スペースをDROPしてしまうと同じ単純表スペースでは作成できなくなります。V8で単純表を作成するために使用していたDDLをそのまま使用すると、セグメント化表スペースになります。

生徒：セグメント化表スペースになると、何か考慮事項は発生しますか。

教授：セグメント化表スペース自体は、単純表よりもスペース管理に優れており、使用することに問題はありません。また、アプリケーションから見た場合に、セグメント化表スペースになったからといって変更は必要ありません。

生徒：ということは、この非互換項目は該当するけれども、特に対応は必要ないということに・・・

教授：いえいえ、ちょっと待ってください。1つ考慮点があります。セグメント化表スペースは、ページをセグメントという単位で管理しますが、セグメン

トに何ページ含むかを作成時にSEGSIZEパラメーターで指定します。セグメント表スペースではSEGSIZEのデフォルトは4ページなのですが、SEGSIZEがFREEPAGEより小さい場合、SEGSIZE-1がFREEPAGEの値として使用されます。そのため、SEGSIZE=4の場合、FREEPAGEに大きい値を設定しても4-1=3がFREEPAGEの値として使用されます。この結果4ページごとに1ページの空きページができることになり、LOAD時等に表スペースの容量が意図したよりも大きくなる可能性があります。

これを防ぐため、DDLには明示的に大きめのSEGSIZEを指定することが推奨になります。非常に小規模な表スペースでない限り、SEGSIZEは明示的に32もしくは64を指定しましょう。

生徒：DDLの修正が必要になるということですね。

教授：単純表スペースが新規作成できなくなるという例で見てきましたが、まとめると、非互換項目に対してはまず該当するかどうかの調査が必要です。そして、該当するのであればどのような影響があるか、影響する場合はSQL修正のような対応が必要になります。

生徒：分かりました。他にはどのような非互換があるでしょうか。V8からV10への移行で重要になるものを

教えてください。


第４章-

❸

非互換項目のキーポイント3

教授：今日は、DB2の非互換項目について話をしましょう。非互換項目とは、DB2のバージョンアップをすることで、以前のバージョンと同じよう

にそのまま動かしても違う動きになるものです。

生徒：作業量やスケジュールの観点からも、重要なところですよね。マニュアルを見るとかなりの数がありますね・・・特にV8からV10への移行では、2バー

ジョン分ということもあり、数が多いようです。

教授：確かにそうですね。ただし、マニュアル上はDB2の持つ全ての機能について非互換項目を列挙していま

すから、もし今使用していない機能であれば、除外できます。

生徒：なるほど。では、まずは全項目について、使用しているかどうかを確認する必要がありますね。

教授：その通りです。

具体例（１）単純表スペースの新規作成不可への対応

教授：たとえば、V8からV10へ移行する場合の非互換の1つに、単純表スペースを新規作成することができなくなる、という項目があります。この場合は、まず単純表スペースを使用しているかどうかを確認する必要があります。

なおこの変更はV9からのため、V8からV9へ移行するときも非互換になります。

生徒：単純表スペースはおそらく使用しています。確認ですが、現在使用している単純表スペースが、使えなくなるわけではありません

よね。

教授：ええ、既存の単純表スペースは使い続けることができます。

生徒：そうですか。では、この非互換によってどんな影響があるのでしょうか。

144 145

第４章-

❸


生徒：ZPARMでも対応できるのですね。

教授：ただし、従来の区分表スペースを使い続けるか、PBRを新しく使うかは考えどころです。先ほども言ったとおり、PBRはセグメント化表スペースのメリットを併せ持っています。加えて、今後ユニバーサル表スペースが主流になる可能性が高く、新機能もまずユニバーサル表スペースを対象に追加される傾向があります。

生徒：これを機に、PBRに切り替えても良さそうですね。検討してみます。

教授：既存の区分表スペースを、ALTERでPBRに変換できる機能も追加されていますから、参考にしてください。


具体例（3） SQL予約語

教授：さて、次はV10への移行に限らずどのバージョンでも考慮が必要な非互換を紹介しましょう。

SQL予約語は知っていますか。

生徒：はい。SQL構文中に使用される単語で、ユーザーが指定する表名や列名には使ってはいけないものですよね。

教授：使う場合は、「“」（ダブル・クオーテーション）などの区切り文字で括ることが必要になります。

SQL予約語は、基本的にバージョンアップするごとに増えていきます。

生徒：新規に増えたSQL予約語を使っているアプリケーションがあるかどうか確認すればよいですか。

教授：いいえ。 SQL予約語は、新規に追加されたものだけでなく既存の予約語についても対応する

必要があります。既存の予約語でこれまで問題なく稼動していたとしても、バージョンアップ後DB2によるSQL構文の変更などでチェックが厳しくなり動きが変わる可能性があるためです。

生徒：なるほど。しかし、数が多いので大変そうです。簡単な調査方法はありますか。

第４章-

❸


具体例（2）区分表スペース作成時の注意点

教授：先ほどの表スペースの話に関連して、区分表スペースにも変更があります。区分表スペースの新規作成はV10でも可能ですが、V8と同じDDLを使用すると、

デフォルトの動きではユニバーサル表スペースのPBR（PartitionByRange）が作成されるようになります。

生徒：ユニバーサル表スペースは、V9からの新機能で、セグメント化表スペースの特徴と区分表スペースの特徴を併せ持った表スペースでしたね。

教授：はい。区分表スペースに、セグメント化表スペースのスペース管理というメリットが持ち込まれたもの、と考えてください。PBRは、アプリケーションや運用の観点からは、従来の区分表と変わりません。

なお、ユニバーサル表スペースには、2種類あり、PBRのほかにPBG（PartitionByGrowth）があります。

生徒：従来の区分表スペースを使い続けることも可能なのですよね。

教授：ええ。PBRが作成されるようになるのは、区分表スペースとユニバーサル表スペース（セグメント化表スペース以外）のSEGSIZEの省略時値が32になるためなので、SEGSIZE=0を明示指定すれば従来の区分表スペースが作成できます。

生徒：対応策はDDLの修正のみでしょうか。

教授：セグメント化表スペース以外のSEGSIZEの省略時値はZPARMパラメーターDPSEGSZで指定できるので、このパラメーターの値を変えて対応することもできます。

図③-1に、表スペースタイプとSEGSIZEの関係をまとめています。

図③-1DB2V10SEGSIZEの省略時値

●区分表スペースおよびユニバーサル表スペース作成時のSEGSIZEの省略時値は、ZPARMパラメーターDPSEGSZによる

●DPSEGSZの省略時は32

DPSEGSZ NUMPARTS 作成される表スペース

>0（省略時値32）

指定なし SEGSIZE=4のセグメント化表スペース

指定あり SEGSIZE=DPSEGSZのPBR

0指定なし SEGSIZE=4のセグメント化表スペース

指定あり従来の区分表スペース※PBG表スペースについては、記述を省略

14� 14�

第４章-

❸


教授：移行前に対応しなくても、V10での最初の実行時に自動的にパッケージが作成されます。

ただし、コレクション名が自動的に決まってしまいますし、REBINDによりアクセスパスが変わる可能性もあります。

できればV8の段階で、環境に即したネーミング・ルールを決め、アクセスパス検証も含め事前に対応しておくことがお勧めです。

生徒：まずは、DBRMが直接バインドされたプランがどのくらいあるかを確認してみます。

教授：プランの数が多いと対応にかかる作業量も多くなりますから、V10化の事前準備作業として十分な時間を持って取り組むようにしましょう。


その他、注意しておく変更点

教授：この他に注意が必要になるものとしては、メッセージやコマンド出力があります。非互換項目として取り上げられているものもありますが、細かいフォーマットの変更に

ついては明記されていないケースもあります。目視するだけならあまり影響はありませんが、出力を独自のアプリケーションで加工し

ているような場合は、少しの変更でも影響を受けますので、注意が必要です。

生徒：現行のシステムでメッセージをどう確認しているか方法を調べておきます。

教授：また、カタログをアクセスするアプリケーションにも注意しましょう。バージョンが上がるごとに、カタログ表に保持する情報量やデータ量が増えるため、移行時にカタログ表への列追加や列定義の変更が行われます。

この影響で、カタログをアクセスするアプリケーションに修正が必要になるケースがあります。

生徒：V10ではカタログやディレクトリーのデータセットがSMS管理になると聞いていますが、これもアプリケーションに影響しますか。

教授：いいえ。アプリケーションには影響はありません。ただし、SMS化することでデータセットの運用には変更が必要になってきます。

この点については、第4章-⑤でご紹介する予定です。

生徒：楽しみにしています。

第４章-

❸


教授：予約語は原則としてプリコンパイル時にチェックされるため、プリコンパイラーによりソース・プログラムをプリコンパイルし、エラーにならないことを検証することが推奨です。予約語を含むソース・プログラムを洗いだすには、SYSIBM.SYSPACKSTMT表のSTMT列かSYSIBM.SYSSTMT表のTEXT列に格納されているSQLステートメントを検索する方法が一般的です。なお、V8以降ではカタログはUnicode化されているため、適宜CAST関数を利用して検索してください。

具体例（4） BIND関連の変更

生徒：ほかに注意が必要な非互換項目はあるでしょうか。

教授：BINDPACKAGE/BINDPLANのオプションの動きが変わるものがあります。具体的には、以下の3つです。

● CURRENTDATAオプション：省略時値が、YESからNOへ変更されます。 ● ISOLATIONオプション：省略時値が、RR（RepeatableRead）からCS（Cursor

Stability）へ変更されます。 ● DBPROTOCOLオプション： PRIVATEがサポートされなくなります。PRIVATE

を指定しているものはDBPROTOCOL（DRDA）で再BINDが必要です。

そして、V10ではDBRMを直接プランにバインドする方式はサポートされなくなり、パッケージが必須になります。

生徒：DBRMが直接バインドされているプランは、一部使っている気がします。どうしたらいいでしょうか。

教授：パッケージに変換する必要がありますが、変換を容易に行うためにREBINDPLANの新しいオプションCOLLIDが提供されています。

REBIND PLAN（X） COLLID（collection-name）

このようにREBINDを行うと、指定したコレクション名の下にパッケージがバインドされます。COLLIDオプションは、V8やV9でも使用できます。

生徒：これはV10に移行する前に対応が必要でしょうか。

14� 14�

第４章-

❹

押さえておきたいDB2マイグレーションのポイント④…REBINDとアクセスパス管理の鍵

しいバージョンの進化したオプティマイザーによりアクセスパス選択が行われますから、よりよいアクセスパスが選ばれる可能性が高くなります。

さらに、V10ではDBM1ストレージの2GBラインより下にアロケーションされていたEDMプールやスレッド作業域が2GBより上にアロケーションされるようになるため、2GB以下のストレージが逼迫する問題が解決されるとともに、より多くのスレッドを処理できるようになります。この拡張はV10でREBINDすることにより利用可能になります。

生徒：なるほど、メリットがある点は理解しました。ということは、全パッケージを移行時にREBINDすべきでしょうか。全てREBINDす

ることは難しいかもしれないのですが・・・

教授：まず、移行に伴って一部無効化されるパッケージがありますので、これはREBINDしなければいけません。

無効化されるのは、非常に古いDB2バージョン（V10への移行であれば、V5以前にBINDされたもの）や移行に伴って変更されるカタログ表を参照しているようなパッケージです。

生徒：これらはREBINDを計画する必要があるということですね。

教授：明示的にREBINDしなくても自動REBIND機能がONになっていれば、新しいバージョンでの初回実行時にREBINDされますが、自動REBINDではアクセスパスが確認できません。ですから、移行作業の1つとして明示的なREBINDを計画することをお勧めします。

生徒：分かりました。 REBINDが必須ではないパッケージはどうでしょうか。

教授：全パッケージのREBINDが難しい場合は、業務上、またパフォーマンスの観点から重要なアプリケーションは優先的にREBINDすることをお勧めします。

生徒：移行ステップの中では、CMの段階でREBINDしてしまってよいでしょうか。それともNFMまで移行が終わるのを待ってREBINDするほうがよいのでしょうか。

教授：CMも新しいバージョンであり、NFMでREBINDする場合と比べて得られるメリットに大差はありませんから、CMでREBINDすることをお勧めします。

その際、可能であればREBIND前にRUNSTATSを実行し、最新の統計情報を取得しておきましょう。バージョンが上がると収集される統計情報も拡張されますから、より適切なアクセスパスが選択されやすくなります。

第４章-

❹


REBINDとアクセスパス管理の鍵4

生徒：今日は、REBINDとアクセスパス管理ですね。移行時以外でもREBINDをしてアクセスパスが変わってしまい問題になったという話

を聞いたことがあります。そんな話を聞くとREBINDすることにはやや抵抗があるのですが・・・

教授：アクセスパスが変わること自体が問題ということではないのですが、アクセスパスが変わった結果パフォーマンスが劣化するケースがあるため、抵抗感を持つお客様が少なくないのは確かですね。

REBINDをすることによるメリットも多くありますから、アクセスパスの変更にうまく対応しながらREBINDを行うことが鍵となります。

今回は、以下の2つの観点からお話しましょう。

（1）移行におけるREBINDの必要性（2）アクセスパス検証のポイント

なお、基本的に前提はパッケージを利用する静的SQLとして話を進めます。

（1）移行におけるREBINDの必要性

生徒：早速ですが、移行では全てのパッケージのREBINDが必要なのでしょうか。

教授：いいえ。正確には、一部REBINDが必要なパッケージはありますが、全パッケージのREBINDが必須というわけではありません。ただし、パフォーマンスの観点からはREBINDすることが推奨です。

生徒：REBINDによるメリットがあるということでしたね。

教授：はい、そうです。 REBINDを推奨する理由の1つ目は、移行に伴うオーバーヘッドの解消です。移行後

REBINDせずにそのままパッケージを実行すると、新しいバージョンに合わせるためのオーバーヘッドがかかりますが、これがREBINDによって解消できます。

2つ目の理由として、新機能の利用があります。まず、移行後REBINDすると、新

150 151

1.現在のアクセスパスの把握 2.アクセスパス検証環境の整備 3.選択されたアクセスパスを変更するための対応

ポイント1. 現在のアクセスパスの把握

教授：移行後のREBINDによってアクセスパスが変化したかどうかを確認するには、まず現在のアクセスパスを把握していなければいけません。

現状でどのようにアクセスパス管理をしているかを調査する必要があります。

生徒：おそらくプラン表で管理はしていると思うのですが・・・確認してみます。ちなみに、現在アクセスパスが把握できていないパッケージがあった場合、選択され

ているアクセスパスを調べる方法はあるでしょうか。

教授：残念ながら、V8以前に作成したパッケージでは、BIND/REBIND時にアクセスパスを取得していないと、その後アクセスパスを確認することは困難です。DB2トレース等を取得して、どのようなアクセスパスなのかを推測するしかありません。

なお、V10の新機能にEXPLAINPACKAGEステートメントがありますが、これを使用するとV9以降にBINDされたパッケージのアクセスパスを後から確認することができます。

EXPLAINPACKAGECOLLECTION'collection-name'PACKAGE'package-name'

例えばこのようにSQLを発行すると、既存のパッケージのアクセスパス情報がプラン表に格納されます。

生徒：V9のパッケージからということで今回の移行では使用できませんが、今後の運用の参考にしたいと思います。誤ってプラン表の内容を削除してしまったような場合には便利な機能ですね。

教授：そうですね。ですが、基本的な運用として、BIND時にアクセスパスを記録しておくことの重要性は変わりません。

ポイント2. アクセスパス検証環境の整備

教授：移行後どのようなアクセスパスがとられるかを検証するには、テスト環境でREBINDを行ってアクセスパスを確認する必要があります。このとき、アクセスパス選択に影響を及ぼす要素を、できるだけ本番環境と揃えることが重要になります。

特に動的SQLの場合、本番環境では事前にアクセスパスを確認することができません

第４章-

❹


生徒：推奨の通りREBINDを計画したいと思いますが、やはりアクセスパスは変わってしまうでしょうか。

教授：新しいバージョンではオプティマイザー自体が変わるため、REBINDするとアクセスパスが変わる可能性は確かにあります。しかし、先ほども述べたように、よりよいアクセスパスを選択するようにオプティマイザーは改良されていますから、変更それ自体が悪いわけではないのです。

ただ、一部パフォーマンスが悪化してしまう可能性もあるため、そのような場合に備えてアクセスパス検証の仕組みを整えておくことが重要になります。


教授：REBINDの影響として、アクセスパスが変わることの他に、もう1つ押さえておくべき点があります。資源使用量の増加です。新しいバージョンでREBINDすると、通常パッケージのサイズは大きくなります。この結果、パッケージが格納されるDB2カタログ/ディレクトリーのデータセット・サイズが増加し、実行時にパッケージがアロケーションされるEDMプールの容量も増大します。EDMプールに関しては、V10では2GBより上にアロケーションされますからあまり気にする必要はありませんが。

生徒：カタログ/ディレクトリーのデータセット・サイズに注意が必要ということですね。

教授：V9までは、データセットの容量監視を行い、必要に応じてデータセットの追加を行うといった対応が必要になります。

これに対して、V10のカタログ/ディレクトリーは、SMS管理かつDB2管理となり、さらに大部分の表スペースがPartitionByGrowth表スペース（ユニバーサル表スペースの一種）となります。その結果、手動でのデータセット追加のような対応は必要なくなります。このV10での変更に関しては、詳細は次回お話しましょう。

生徒：楽しみにしています。

（2）アクセスパス検証のポイント

教授：では、アクセスパス検証をどのように行うかに話を移しましょう。 REBIND対象になるパッケージ数にもよりますが、アクセスパス検証は通常多くのワー

クロードが必要となる作業です。必要な環境/手順/期間を事前に明確にしておくことが重要になります。

3つのポイントからお話します。

第４章-

❹


152 153


第４章-

❹

他にはヒント機能といって、プラン表に選択させたいアクセスパスを用意し、そのアクセスパスを選択させるようにする機能もありますが、SQLのコーディングや運用の仕組みが必要になるため、これまで使用していない場合はすぐに採用することは難しいでしょう。

生徒：どんな方法を使うかは、現在どのような方針、方法でアクセスパスの運用をしているかを確認してから、検討したいと思います。

教授：それがいいでしょう。もう1つ、V9およびV10新機能であるPlanStability（Accessplanstability）

も移行でアクセスパスが変更された際に利用できます。

生徒：どのような機能でしょうか。

教授：パッケージのREBIND時に、古いパッケージ・コピーを消してしまわずに保管しておき、必要に応じて新しいパッケージとスイッチして戻すことができるという機能です。

図④-1:PlanStability機能

REBINDをする際に、PLANMGMTオプションを指定すると、現在のパッケージがコピーとして残されます。その後、アクセスパスを元に戻したいという要件が発生した場合は、SWITCHオプション付でREBINDを実施すると、パッケージが切り替えられます。

REBIND前のパッケージ

もとのパッケージはコピーとして保管

切り替え可

REBIND PACKAGE…PLANMGMT（BASIC）

REBIND PACKAGE…SWITCH（PREVIOUS）

REBIND後のパッケージ


第４章-

❹

から、テスト環境を整えることが非常に重要です。アクセスパス選択に関与する要素には、以下のようなものがあります。

●DB2バージョン、PTFレベル ●システムパラメーター（ZPARM） ●統計情報 ●CPU（モデル、個数） ●Pool類の設定（バッファープール、RIDプール） ●データベース設計（区分表、索引の数、他） ●SQLステートメント

生徒：CPUやバッファープール定義も合わせる必要があるのですか。全てを本番環境と揃えるのは難しいかもしれません・・・

教授：確かに環境によっては難しい要素もありますが、できるだけ合わせることをお勧めします。

なお参考情報ですが、先ごろproductionmodelingfunctionと呼ばれる機能がPTFで提供されました（V9用：PM26475、V10用：PM26973）。本番環境の設定の一部をテスト環境でシミュレートすることを目的とした機能になります。

生徒：なるほど。確認してみます。

ポイント3. 選択されたアクセスパスを変更するための対応

教授：検証の結果アクセスパスの変化が確認されたら、実際に稼動するとパフォーマンスが劣化するかどうかを判断します。大規模な表に対する表スペース・スキャンのように明らかに避けるべきアクセスパスであれば判断は簡単ですが、複雑なSQLではアクセスパスを見るだけでは難しいため実際にアプリケーションを実行して比較することも検討します。

その結果、パフォーマンスが劣化すると予想されるものや実際に稼動させた結果劣化したものに対しては、異なるアクセスパス（必ずしも元のアクセスパスが最適とは限らない）を選択させるように対応する必要があります。

生徒：どのような対応方法があるでしょうか。

教授：SQLにできるだけ手を加えたくないのであれば、RUNSTATSの実行や索引設計の見直しを行うことになります。ただし、これらの対応は、問題となったSQLだけでなく他のSQLにも影響を及ぼすため、再度アクセスパス検証が必要になるという考慮点があります。

154 155

第４章-

❺

押さえておきたいDB2マイグレーションのポイント⑤…V10への移行での注意点

V10への移行での注意点5

生徒：教授、DB2マイグレーションのご相談ができるのも、今日が最終回と聞きました。どうしてもお聞きしておきたいことがあります。私の担当するDB2バージョンアップ・プロジェクトでは、最新のDB2V10にすることを考えているのですが、V10への移行って特別なことがあるのでしょうか。たしか前回、SMS管理化の話が少し出ていた気がするのですが・・・。

教授：ええ、DB2V10への移行にはいくつか特徴的な点があります。それらの多くは既にお話しているものなので、今回はSMS管理の話を中心にお話したいと思います。

その前に、これまでの4回を振りかえり、DB2V10への移行にあたって、どのような注意点があったかをみてみましょう。ちゃんと覚えていますか？

生徒：バッチリ！だと思うんですけど・・・。

V10への移行で特徴的な点

教授：DB2V10への移行で特徴的なのは、次の5点といえます。

1.リソース使用量（CPU,メモリ,ディスク）の変化 2.スキップマイグレーションのサポート 3.デフォルトで作成される表スペースの変更 4.パッケージのREBIND時の動きの変更 5.DB2カタログ/ディレクトリーの再構築とSMS管理化

上から4つは説明済みのはずですが、覚えていますよね。

生徒：はい。1つ目の「リソース使用量」については、第2回の時にお話がありました。V10ではCPU使用量増加の懸念は小さく、仮想メモリーの制約もほとんど緩和されたとのことでした。一方で、実メモリーやディスク容量は旧バージョンと比べて増加する傾向があるというものでした。ディスク容量は特にDB2カタログ/ディレクトリー部分のことでしたよね。

第４章-

❹


なお、PLANMGMTオプションの省略時値はシステムパラメーターPLANMGMTでも指定できます。

生徒：これは便利ですね。念のため古いパッケージを残しておけば、いざというと元に戻せるわけですから、移

行でも利用できそうです。

教授：考慮事項としては、まず、パッケージのコピーを残していくため、パッケージ本体が格納されるディレクトリー（SPT01）のデータセット・サイズ増大に注意が必要になります。全てのパッケージをPLANMGMT（BASIC）付でREBINDすると単純に2倍になりますから。

また、REBIND時に使用する機能であるため、プリコンパイルやバインドから再作成する場合には使用できません。

それから移行に伴ってパッケージが無効化しREBINDが必須になるパッケージは、REBIND前のパッケージは使用できないため、当然ですが古いパッケージを取っておいても戻ることはできません。

生徒：分かりました。REBINDとアクセスパス検証、しっかり移行計画に反映していきたいと思います。

15� 15�


第４章-

❺

教授：V10ではこのPlanStability機能が、デフォルトでONとなっているのです。もちろん、使用するかどうかは、BINDオプションやシステムパラメーター（ZPARM）で選択できます。

生徒：でもデフォルトでONなら、意識せずに使っていると、REBIND時にパッケージのコピーが作成されて、それらが格納されるDB2ディレクトリーの容量が知らない間に増加していくことになるのでは？

教授：よく気がつきましたね。もちろん、心配ならZPARMで当機能を使用しない設定にしておけばよいのですが、正しく運用すれば便利な機能ですから、V10移行前に採用の是非をしっかり検討しておくことです。ただ、デフォルトでONとしているからには、DB2ディレクトリーの方も容量面で問題が生じにくいように、V10からいろいろ改良されているのです。

さあ、DB2ディレクトリーのサイズの話が出たところで、いよいよ今回の本題である「DB2カタログ/ディレクトリーの再構築」についてみていくことにしましょう。

生徒：ようやく本題に辿り着きましたね。よろしくお願いします。

DB2カタログ/ディレクトリーの再構築とは

教授：DB2V10は、DB2カタログ/ディレクトリーの構造が大きく変更されています。

生徒：V8の時にも同じような話がありましたね。以前、先輩から聞いたのですが、そのときはDB2カタログ/ディレクトリーのUnicode化が行われたそうです。今回の再構築の目的は何でしょうか？

教授：DB2が、より多くの情報を格納し、より多くの処理に対応できるようにするためです。さきほどお話した”PlanStability”機能からもわかるように、DB2カタログやDB2ディレクトリーに格納される情報は増え続けています。また、DDLやBIND、ユーティリティーの並列実行などのオペレーションでは、DB2カタログやディレクトリー上での競合が問題となっていました。これらの問題を解決し、DB2がさらに進化するために、このタイミングでカタログ/ディレクトリーの構造を見直したのです。

生徒：なるほど。25年以上の歴史があると、DB2に求められる要件も大きく変わってきていますからね。DB2も時代の変化に合わせて、改善を続けている証なんですね。

教授：今回の再構築のポイントは以下の3つです。


第４章-

❺

教授：そうです。DB2カタログ/ディレクトリーに関しては、このあとでもお話します。増加の心配が少ないものでも、移行前後での比較ができるように、監視を行っておくことが大事ですよ。

さて、2つ目はどうでしょう？

生徒：はい。V9からだけでなく、V8から直接V10にマイグレーションするパスもサポートされるとのことでした。これも第1回でお話いただいたことです。V8ユーザーからすると、V9orV10のいずれかを選択できるのでうれしいです。V8→V10スキップ・マイグレーションの選択にあたっては、非互換/変更点の調査とその対応がキーでしたね。

教授：よく覚えていますね、いい感じですよ。

生徒：3つ目は、確か第3回の非互換項目のところで教えていただいたような・・・。V9から単純表スペースの新規作成ができなくなったことや、代わりに新しく登場した「ユニバーサル表スペース」と関係していることは覚えています。でも、具体的にどの点が変わるんでしたっけ。

教授：V9とV10では、表スペース作成時のセグメントサイズ（SEGSIZEパラメーター）の省略時値が異なるのです。そのため、同じDDLを使っても、作成される表スペースのタイプが異なることがあるという話です。大事な点ですから、あとでもう一度確認しておいてください。ユニバーサル表スペースの1形態である”PBG（PartitionbyGrowth）”は、このあとのカタログの再構築のところでも出てきますよ。

生徒：あ、思い出しました。SEGSIZEに関する設定によって、従来の区分表スペースを作成するつもりがPBR（PartitionByRange）として作成されるというお話がありました。SEGSIZEオプションはDDLに明示的に指定することが推奨ということでしたよね。

そして4つ目は・・・これは前回の最後のほうで教授がおっしゃっていた「パッケージのコピーを保存しておく機能」のことですか？

教授：はい。“PlanStability”機能という名称でしたよね。

生徒：でも、これはV9でも使える機能と教わりましたよ。REBIND時に、それまでのパッケージのコピーを保存しておき、新しく作られたパッケージのアクセスパスが不適切だったような場合に、元のパッケージに戻すことができる機能でしたよね。ちょっと興味があるので、検討してみるつもりなのです。

15� 15�


第４章-

❺

生徒：これでは、表スペースの個数が大幅に増えることになりますね。あれ？ LOB表というものもあるようですが、これはあの”LargeObject”のことですか？

教授：そうです。DB2カタログに格納するデータの中には、とてもサイズの大きいものもあります。それらを格納するために、LOB型の列をカタログ表の中に採用したのです。このSYSDBASEの分割の例には含まれませんが、BINDした時にDBRMから抜き出したSQLステートメントも、その対象です。

LOB列を使用する以上、別途LOB表スペースも必要になります。そのため、図⑤-１では2つのLOB表スペースを加えると、実際には15個の表スペースに分割されることになるのです。

生徒：しかし、どうしてここまで細分化するのでしょうか。

教授：先ほど少しお話しましたが、カタログやディレクトリーでの競合を回避するためです。V9まではカタログやディレクトリーの一部に「リンク」と呼ばれる仕組みを利用していました。しかし、この仕組みを持っているが故に、行レベル・ロックが使用できず、しばしばカタログやディレクトリーでの競合が問題となっていたのです。V10では、このリンクを削除し、代わりに参照制約を利用することにしたのです。これにより、行レベル・ロックが使用可能になりました。その結果、DDL,DML,DCL,DB2コマンド、ユーティリティーなどでの競合が減り、これらのオペレーションを、より高い並列度での実行が期待できるのです。

生徒：なるほど、参照制約をDB2カタログで採用したのですね。ところで、このようにして生成される表スペースのタイプは何でしょうか。

教授：ユニバーサル表スペースの1形態、PBG（PartitionbyGrowth）です。PBGの特徴は知っていますか？

生徒：だいたいは理解しているつもりです。「区分」の特性をもっているものの、区分化のためのキーはなく、データセットのサイズがあらかじめ決められたサイズ以上になると、次の「区分」として新しいデータセットがアロケーションされ、データが格納されていくんですよね。また、ユニバーサル表スペースだから、各区分の中はセグメントの構造を持っています。

教授：はい、その通りです。一部のカタログ/ディレクトリーは、PartitionByGrowth表スペースに変更されます。全ての表スペースがPBGに変換されるわけではありませんが、V8やV9の時のSYSDBASE,SYSPKAGE,DBD01,SPT01など、サイズが大きくなりやすいものは対象となっています。では、PBGとして作成されるときの主な属性を挙げてみましょう。


第４章-

❺

・SMS管理化&DB2管理化・PBGの利用&LOBの利用・リンクを削除し行ロックを活用可能に

生徒：うーん、いろいろ変わるようですが、正直なところ、DB2カタログやディレクトリーの構造については、今までそれほど意識していませんでしたので、具体的なイメージがわきません。

教授：では1つ例を見てみましょう。ユーザーが作成した表、列、索引などの定義情報は、DB2カタログの中の表に格

納されていますよね。表の定義情報ならSYSIBM.SYSTABLES、列はSYSIBM.SYSCOLUMNS、索引はSYSIBM.SYSINDEXESといった具合です。V8やV9の段階では、これらは全て”SYSDBASE”という1つの表スペースの中に含まれていました。V10では、これらの表はそれぞれ対応する表スペースが作成され、そこに含まれるようになります。図⑤-１を見てください。そのため、この例だけでも全部で13個の表スペースがDB2カタログの中に作成されることになるのです。

図⑤-1．カタログ表スペースの分割：SYSDBASE表スペースの場合

SYSCOLAUTH

SYSDBASE

SYSCOLUMNS

SYSFIELDS

SYSFOREIGNKEYS

SYSINDEXES

SYSINDEXPART

SYSKEYS

SYSRELS

SYSSYNONYMS

SYSTABAUTH

SYSTABLEPART

SYSTABLES

SYSTABLESPACE

SYSCOLAUTH

SYSTSFAU

SYSCOLUMNS

SYSTSCOL

SYSFIELDS

SYSTSFLD

SYSFOREIGNKEYS

SYSTSFOR

SYSINDEXES

SYSTSIXS

SYSINDEXES_RTSECT

SYSTSIXR

SYSINDEXES_TREE

SYSTSIXT

SYSINDEXPART

SYSTSIPT

SYSKEYS

SYSTSKEY

SYSTABLES

SYSTSTAB

SYSTABLESPACE

SYSTSTSP

SYSRELS

SYSTSREL

SYSSYNONYMS

SYSTSSYN

SYSTABAUTH

SYSTSTAU

SYSTABLEPART

SYSTSTPT

V10V9まで

表スペース

ベース表

LOB表

V8/V9では1個の表スペースだったものが、V10では13個のPBG表スペースと2個のLOB表スペースに分割される

1�0 1�1


第４章-

❺

・DB2管理のデータセットになったことで、データセットを手動でアロケーションする必要がない

　⇒オンラインREORG時のシャドー・データセット等、データセットの割り振りが自動化される

・データセット・サイズの見積もりが不要　⇒ 一次割振り量は、ZPARMの値が省略時値として使用される上、二次割振り量

はスライド制（Slidingscale）アルゴリズムによる計算値が使用される

・SMSの機能によりエクステント数の増加を抑え、エクステントでのエラーを回避する（ExtentConsolidation機能）

・SMSによるVOLUMEの自動選択

生徒：ずいぶんと様々なメリットを享受できるようになるんですね。「DB2カタログ/ディレクトリーの再構築」によって、DB2V10がどれだけ進化したか、使うのが楽しみです。

SMS管理化と移行手順

生徒：しかし教授、カタログ/ディレクトリーのSMS管理化が必要なのはわかったのですが、いつどうやってそれを行えばよいのでしょう？ V8のカタログUnicode化の際は、移行ジョブ1つで自動的に変換されたと聞いています。

教授：V7からV8に移行する時のUnicode化とは少し事情が異なります。SMS管理化にあたっては、事前に自分で設定を行っておく部分があります。また、実際にSMS管理化するタイミングや方法も1つではありません。V10CMとV10NFMで、カタログ/ディレクトリーに対してどのような変更が行われるかを見ながら、SMS管理化の方法を説明しましょう。

1）V10CMへの移行時

教授：まず、CMへの移行前に、DFSMSでDB2カタログ/ディレクトリーをSMS管理にするための定義が必要です。ここで、EF/EAの指定をもったデータクラスの定義や、ACSルーチンを定義しておくわけです。

CMへの移行過程では、移行ジョブ：DSNTIJTCにてCATMAINTユーティリティーが実行されます。既存のカタログ表に対して新しい列などが追加されるのと同時に、新しい表スペースや索引も追加されます。この新しい表スペース/索引のデータセットは、移行前に準備しておいたDFSMSの定義が使用され、SMS管理のボリュームにアロ


第４章-

❺

・DSSIZE64G ・MAXPARTITIONS1 ・SEGSIZE32 ・LOCKSIZEROW

この情報から、この表スペースの特徴を想像できますか？

生徒：えーと、1つのデータセットは最大64GBまで拡張できるんですね。あれ、でもMAXPARTITIONS=1だから、複数データセット（区分）になることはなく、結局データセットとしては1つ（1区分）だけってことですね。その中は32ページで1つのセグメントを構成していて・・・あとはさっきお話のあった行レベル・ロックですか。

教授：そのとおりです。PBGとなるカタログ/ディレクトリーの表スペースは、それぞれ最大64GBまで拡張可能な1つのデータセットとして定義されます。そして、そのためには、SMS（StorageManagementSubsystem）管理のデータセットとして、データクラスの定義でEF/EA（拡張フォーマット/拡張アドレッシング）の指定が必須となるのです。

生徒：それでSMS管理となるわけですか。

教授：SMS管理化によるメリットは、64GBというデータセットを定義できることだけではありません。でもその前に、V10では他にもカタログ/ディレクトリーのデータセットに対する変更があるのを知っていますか？

生徒：え、SMS管理化の他にあるのですか？すぐには思い浮かびません・・・。

教授：DB2カタログ/ディレクトリーのデータセットが「DB2管理」となったことです。逆に言うと、V9までは「ユーザー管理のデータセット」だったわけで、REORGなどを実行する際は、自分でAMSのDELETECLUSTERやDEFINECLUSTERを使ってVSAMを削除して再作成しておく必要があったのです。

このように、「DB2管理のデータセット」とし、さらに「SMS管理化」とすることで、DB2カタログ/ディレクトリーのデータセット管理の効率化を実現できるのです。1つ1つは詳しく述べませんが、DB2カタログ/ディレクトリー再構築後の、表スペースや索引の特性をリストアップしておきましょう。

1�2 1�3


第４章-

❺

教授：実はそれも1つの方法なのです。V10CM移行前に、再構築の対象かどうかに関わらず、既存のカタログ/ディレクトリーのデータセットを全てSMS管理化しておくこともできるのです。この場合、DFSMSにデータクラスやACSルーチンなどを定義するところは同じですが、V8やV9の段階で、DFSMSの「CONVERTVコマンド」を利用すると、既存ボリュームをデータの移動なしでSMS管理に変換できるのです。もちろん、利用するにあたっては前提や注意点があるので、十分な調査と計画は必要です。しかし、V8やV9のうちに、カタログ/ディレクトリーのデータセットを自分で再編成しながら、SMS管理のボリュームに移していくよりは、手間が少ない方法と言えるでしょう。

生徒：これは便利ですね。V10への移行を見据え、どこかのタイミングでV8orV9のカタログ/ディレクトリーをSMS管理化しておくわけですね。

教授：ではここで、もう一度おさらいしておきましょう。SMS管理化の方法・タイミングは、大きく2つありました。1つは、移行ジョブや自分でREORGを実行することで、徐々に変換していく方法。もう1つは、V10CM移行前にCONVERTVコマンドであらかじめ全部変換しておく方法です。これらを図でまとめたものが、以下の図⑤-2と図⑤-3です。よく理解しておいてください。

図⑤-2．V10CM移行前に既存データセットをSMS化しない場合

非SMS管理 SMS管理

DFSMS定義

V8/V9VOLA

VOLA

VOLA

VOLB

VOLB

VOLB

V10 CM

V10 NFM

TS

TS

TS TS

TS

TS

IXIX

IX

IX

TS TS

TSTSTSTS

TS

IXIX

IX

IXIX

IX IXIX

TS IX

IX

IX

ACS Routine

SMS Class

DFSMS定義

ACS Routine

SMS Class

DFSMS定義

ACS Routine

SMS Class

既存表への列追加新規TS, IX追加

新規TS, IX追加

再編成すると、SMSボリュームに移動する

再構築されない表スペースは残る


第４章-

❺

ケーションされることになります。一方で、既存のデータセットについては、自動的にSMS管理のボリュームに移ることはありません。また、CATMAINTユーティリティーでは、表スペースが分割されて複数のPBGとして生成されるわけではありません。カタログ/ディレクトリーの基本的な構造としては、V8もしくはV9のときと同じままです。

生徒：ということは、CMになった段階では、DB2カタログ/ディレクトリーの大部分はまだSMS管理化されておらず、新しく追加されたものだけがSMS管理化されているというわけですね。

教授：そうです。まだ本格的な「再構築」は行われていないのです。ただ、CMで稼動している期間中に、自分でDB2カタログ/ディレクトリーに対する再編成を行うと、その対象となった表スペースや付随する索引は、DFSMSでの定義にしたがって、SMS管理のボリュームにアロケーションされることになります。

生徒：自分で再編成を行うことで、DB2カタログ/ディレクトリーのデータセットを少しずつSMS管理のボリュームへと移していくことができるわけですか。

教授：もちろん、再編成をしなくても構いません。その場合、次のENFMの段階で、DB2によってSMS管理化が行われます。

2）NFMへの移行時

教授：移行ジョブ：DSNTIJENにより、CATENFMユーティリティーが起動されます。ここから、ENFMと呼ばれるモードに入ります。DSNTIJENでは、REORGによってカタログ/ディレクトリーの再構築が行われます。表スペースの分割や名称変更、PBG化、LOB列の導入などもこの段階で実施されます。表スペースや索引のデータセットは、DFSMSの定義に従って、SMS管理のボリュームにアロケーションされます。

生徒：ここで一気にカタログ/ディレクトリーの再構築とSMS管理化を行うわけですね。

教授：ただし、カタログ/ディレクトリーのデータセットの全てが再構築の対象ではありません。再構築の対象でないデータセットは、NFMに切り替えた後でも、SMS管理ではない状態で残っています。これらも含め、全てのカタログ/ディレクトリーのデータセットをSMS管理とするのであれば、別途それらを再編成するなどの手順が必要となります。

生徒：SMS管理とそうでないものが混在してしまうのですか。自分で再編成すればSMS管理化できるとはいえ、運用的な観点からも手順が煩雑になりそうですね。いっそのこと、V10CMに移行する前に、カタログ/ディレクトリーの全てをSMS管理化しておくことはできないものでしょうか。

1�4 1�5


第４章-

❺

（2）リンクが廃止されたことで、DSN1CHKRユーティリティーを使う運用は不要となります。代わりに参照制約やLOBをもつことになるので、整合性を確認するという意味では、DB2カタログ/ディレクトリーに対するCHECKDATA、CHECKINDEX、CHECKLOBユーティリティーを使うことになります。

（3）データセットの容量監視の方法も見直してください。データセットの名称変更も当然ですが、PBGとなるものは、1つのデータセットで64GBまで拡張されます。その上、1次/2次割振りの方法やその量について、ユーザーが指定できる余地はなくなっています。また、SMS管理のボリュームですと、エクステントについては、ExtentConsolidation機能も利用されます。したがって、個々のデータセットのエクステントの監視を行うというよりも、DB2カタログ/ディレクトリーで使用するDFSMSストレージグループについて、全体的なボリューム使用量の観点で監視を行うとよいでしょう。

（4）従来のユーザー管理データセットから、DB2管理データセットに変更されるため、再編成時にデータセットを手動でDELETE/DEFINEする必要がありません。現在のカタログ/ディレクトリーの再編成の手順を見直すことになります。

（5）あと、DB2カタログ/ディレクトリー全体の容量も増大する可能性があります。ただ、こちらは個々の環境に依存するため、テスト環境で検証することをお奨めします。

ざっと5点ほど述べましたが、いかがですか？1つ1つしっかり理解して準備していけば、「DB2カタログ/ディレクトリーの再構築」といっても、決して難しいものではありません。

生徒：はい。移行の計画にしっかりと反映し、十分に準備しておきます。

DB2 V10へのマイグレーションにむけて

教授：さて、今回は少し話が長くなってしまいましたが、もう一度、今回のテーマを振り返ってみましょう。「DB2V10への移行での注意点」でしたね。そして以下の5つの特徴を挙げました。

・リソース使用量（CPU,メモリ,ディスク）の変化・スキップマイグレーションのサポート・デフォルトで作成される表スペースの変更・パッケージのREBIND時の動きの変更・DB2カタログ/ディレクトリーの再構築とSMS管理化


第４章-

❺

図⑤-3．V10CM移行前に既存データセットをSMS化する場合

生徒：わかりました。V10への移行計画を立案する上で、大事なポイントですね。

運用への影響

生徒：SMS管理化の方法も含め、V10移行における「DB2カタログの再構築」の内容はだいたい理解できました。いろんなメリットを享受できる反面、この変更により既存のDB2カタログ/ディレクトリーの運用を見直さないといけないところも出てきますね。

教授：いいところに気がつきました。まさにそのとおりです。では、これまでお話した内容をもとに、運用上どのような注意点があるかを考えてみましょう。

（1）SYSDBASE表スペースの分割に代表されるように、表スペースの数が大幅に増え、その名称も変わります。そのため、DB2カタログ/ディレクトリーのイメージコピーを取得するJCLの修正が必要です。取得する順番も含め、導入ジョブ：DSNTIJICを参考にするとよいでしょう。LOB列があることで、LOB表スペースもバックアップの対象となることを忘れてはいけません。

非SMS管理 SMS管理

DFSMS定義

V8/V9VOLA VOLA

VOLA

VOLA

V10 CM

V10 NFM

TS

TSTS

IXIX

IX

TS

TSTS

IXIX

IX

TS

TS

TS

TS

IXIX

IX

TS

TSTSTSTS

TS

IXIX

IXIX

IX IXIX

ACS Routine

SMS Class

DFSMS定義

ACS Routine

SMS Class

DFSMS定義

ACS Routine

SMS Class

既存表への列追加

CONVERTV

新規TS, IX追加

新規TS, IX追加

再構築されない表スペースもある

既存表スペースの再構築（REORG）

IX

CONVERTVコマンドを利用すると、既存ボリュームをデータ移動なしでSMS管理に変換できる

1�� 1��

第５章

・第5章・

MQマイグレーションの第一歩

2012年12月現在、正式サポートされているMQのバージョンは,V7.0.1、V7.1です。しかし、実際にはV5やV6など、サポート切れのバージョンをお使いのお客様もいらっしゃいます。この様に、世の中で幅広いMQのバージョンが利用されることになります。MQのマイグレーションを考えると、移行元と移行先の組合せはさらに数多く存在しまが、MQではどのVRM（バージョン・リリース・モディフィケーション）間のマイグレーションを計画する場合も考え方は同じです。もちろん、それぞれのVRMに応じて考慮点や非互換項目が存在しますので、調査は必要です。MQ…V5.3.1からV7.0.1への移行を例に、マイグレーションに関する考え方の基本と考慮点をピックアップし、ご紹介したいと思います。

●

MQ移行計画立案のために

バージョンアップによる変更の影響と対応策について（V5.3.1からV7.0.1へのケース）

1

2

第４章-

❺


前回までに話のあった4つの復習に加え、5つ目のDB2カタログ/ディレクトリーの再構築とSMS管理化を詳しくお話しました。

これらに加え、第1章から第4章までにお話した内容をもう一度復習し、DB2の移行の全体像を掴んで、移行の計画に反映してください。DB2V10への移行がスムーズに完了し、V10の新機能を存分に活用できることを願っています。

生徒：はい！最初にご相談したときは、DB2の移行は大変そうだというぼんやりした印象しかなかったのですが、今では重要なポイントを具体的にイメージできるようになりました。1つ1つしっかり検討して対応していけば、V10への移行もうまくいけそうです。それでは、教わったことを忘れないように、早速移行計画に着手します。ありがとうございました。

1��

MQマイグレーションの第一歩①…MQ移行計画立案のために

1��


第５章-

❶

クのためには、移行前のバージョンにフォールバックPTFを適用する必要があります。この場合、現行バージョンのシステム・データ・セットはそのまま新バージョンでも使用できます。例えばMQv6.0からMQv7.0.1COMPATモードへの移行の場合はこの方法を選択可能です。

ちなみに、2011年7月現在のMQの移行パスについては以下の図①-2を確認してください。

サポートされる移行パス・V7.0.1への移行が正式サポートされているのはV6,V7.0.0のみ・V7.0.1からのフォールバックは、COMPATモードで稼働時のみ可能・NEWFUNCモードで稼働したQMGRのフォールバックは不可・V1.2,V2.1,V5.2,V5.3.xからの移行は、一旦V6に移行してからV7.0.1に移行する・APARPK73643（PEFIXPK92281）により、V5.3.1⇒V7.0への移行が可能（フォールバックは不可）

方法1：リソース引継あり

システム・データ・セット

ZPARM（CSQ6SYSP）にてOPMODE=COMPAT

ページセット

B SD S

アーカイブ・ログ

アクティブ・ログWMQ/z OSV7.0.1

WMQ/z OSV7.0.1

V7.0.1ライブラリー



WMQ/z OSV6.0

WMQ/z OSV5.3.1

V5.0ライブラリー

（+フォールバックPTF）

V5.0ライブラリー

（+フォールバックPTF）

例）V6.0　　 V7.0.1（COMPATモード）の移行　　

方法2：リソース引継なし例）V5.3.1　　 V7.0.1の移行　　

新規に作成


ページセット

B SD S

アクティブ・ログ


ページセット

B SD S

アクティブ・ログ定義のみ移行



フォールバックに備えフル・バックアップ

図①-1.MQの移行方法

第５章-

❶

MQ移行計画立案のために1

生徒：教授、ご相談したいことがありますが、よろしいでしょうか？

教授：はい。なんでしょうか？

生徒：実は、MQforz/OS担当者としてサポートしてきたお客様で、今度MQのバージョン・アップ・プロジェクトを担当することになりました。ですが、何からはじめればいいのか・・・。

教授：なるほど。でもMQforz/OSの経験者なので、しっかりとMQ移行の基本的な考え方と考慮点を押さえれば、心配ないでしょう。MQはデータベース製品と違って、長時間にわたってデータを保持していないし、アプリケーションもMQ資源として定義する必要がないので、その分、他のミドルウェアと比較して移行作業は容易ですよ。

生徒：ですけど、やはり、MQのバージョンアップについては経験がないので不安です。

教授：それでは、MQ移行の概要から話しましょう。MQの移行は基本的に、製品ライブラリーを入れ替えて、稼働するキュー・マネージャーのバージョンを切り替えることです。その際に、MQリソースの移行はどうするかがマイグレーションのポイントになります。

生徒：MQリソースとはMQシステムで使用されるデータ・セットのことですか？

教授：そのとおりです。MQリソースというと一般的にはページ・セット,BSDSとログのことを指します。この３種類のデータ・セットの中に、ユーザーとシステムのメッセージ、稼働に必要なオブジェクト定義情報や構成情報、リカバリー情報等が含まれています。

生徒：なるほど。そのMQリソースの移行をどの様に考えればいいですか？

教授：それは移行方法に大きく影響されるので、まず、移行方法から説明しましょう。

MQでの移行方法は大きく分けて2つあります。MQリソース引継ありの方法と引継なしの方法です。

リソース引継ありの方法は移行パスがある場合のみに採用可能です。製品ライブラリーの切り替え（STEPLIBの連結ライブラリーの入れ替え）で新バージョンへの移行と現行バージョンへの戻し、つまりフォールバックも可能になります。ただし、フォールバッ

1�0 1�1


第５章-

❶

生徒：具体的に、リソースの再構築とはどのような作業を行うのですか？システム・データ・セットのVSAMを再生成するだけではないですよね。

教授：それはそうですね。データ・セットの生成も必要なのですが、それだけでは不十分です。具体的に、再構築にどの様な作業が必要なのかは表1で確認してみましょう。

表1. MQ移行時のリソースの再構築方法

リソース切替え前の準備切替え後の作業備考

ユーザー・メッセージ

・メッセージ数を確認・メッセージをSAMファイル等に保管（バックアップツールの開発要）　

・メッセージ数を確認・メッセージをファイルからキューに戻す（メッセージ書き出しツールの開発要）

・予めキューを空にすることが可能である場合は不要

・バックアップ/戻しツールの開発・テストを実施

・メッセージの移行が不要な場合は作業はなし

オブジェクト定義情報

現行のMQSCコマンド文を保管（CSQUTILMAKEDEFによりMQSCコマンド文を生成可能）

・現行のMQSCコマンド文を再発行

・ISPLAYコマンドを発行し属性値を確認

チャネル同期情報

・チャネルを正常終了させる・INDOUBT（NO）を確認

送信側チャネルにRESETCHANNELコマンドを発行チャネルの接続確認メッセージの疎通確認

チャネルのシーケンス番号同期処理は接続時ではなく、メッセージ疎通時に検知されることに注意

クラスタークラスターから離脱クラスターに再参加

移行するキュー・マネージャーがFullRepository である場合、周辺キュー・マネージャーからのRefreshClusterが必要になる

キュー共用構成情報キュー共用グループから離脱キュー共用グループに再参加

グループ内で複数バージョンが共存する場合はPTF適用など、別の考慮点がある

UOWステータス情報

・各タスクを正常終了させる・INDOUBTスレッドがないことを確認

起動時のリカバリー処理が正常に完了していることを確認

対象：チャネル、IMS（サブシステム接続、OTMA 接続）、CICS、RRS

ログ新規に作成特になしログ・レコードの移行は不可

例えば、オブジェクトの再構築には、切り替え前にMQユーティリティーのMAKEDEF機能を使って、既存オブジェクトのMQSC定義コマンド文を生成し、保管します。そして、切り替え後は保管したコマンド文を再実行する必要があります。その他にRESETCHANNELやクラスター構成をとっている場合はREFRESHCLUSTERコマンドを実行し、チャネルの同期情報やクラスターの構成情報を同期・更新させるという作業もあります。環境により、再構築が必要な項目が変わりますので、自分の環境に該当するものを確認してください。

第５章-

❶


図①-2.WebSphereMQ（z/OS版）の移行パス（2011年7月現在）

V7.0.1からは、新機能の使用やフォールバックを制御するためのOPMODE属性がZPARMに追加され、その設定値としてCOMPATとNEWFUNCがあります。

COMPATを設定するとキュー・マネージャーが互換モードで稼働します。一部の新機能であるログの圧縮とキュー共用のグループUR機能は使用不可能ですが、その代わりフォールバックができます。

一方NEWFUNCを設定すると、すべての新機能が使用できるようになりますが、旧バージョンへのフォールバックは不可になります。

COMPATとNEWFUNC間のモード変更はZPARMの変更のみで可能です。ただし、一度NEWFUNCモードで稼働したキュー・マネージャーは、新機能使用有無にかかわらず、COMPATモードに変更しても、下位バージョンにフォールバックすることはできません。

生徒：ええと・・・、お客様の現行システムはv5.3.1なのですが、今回のプロジェクトでv7.0.1への移行を考えていらっしゃいます。この図を確認している限り、両バージョン間は移行パスがないみたいですね。そうすると、移行パスをたどって、v5.3.1->v6.0->v7.0.1という2段階移行を実施するしかないですか。

教授：いいえ、その場合はもう一つの移行方法をとることが多いですね。

生徒：あっそうでした。この図①-1の「方法2：リソース引継なし」というのもありましたね。

教授：そのとおりです。この方法は移行パスがないバージョン間や移行パスはあるけれども、リソース引継ぎが不要な場合の移行に採用されます。最初に説明しましたように、MQのリソースは他のミドルウェアと比較して、少ない方です。そのため、MQの移行ではリソースを引継がずに新バージョンで再構築することも可能です。ただし、この方法を採用する場合、現行バージョンへのフォールバックに備え、予め取得したフル・バックアップからリストアする必要があります。

サポートが終了している移行パスサポートされる移行パス

WMQV7.00

WMQV6.0

WMQV5.3

WMQV5.3.1

MQ V1.2

MQ V2.1

MQ V5.2WMQV7.01

（COMPAT）

1�2


1�3


第５章-

❶

新バージョンに移行したときに、新バージョンキュー・マネージャーの1つに問題が発生したとします。それはバージョン移行によるものか、それともそのキュー・マネージャー独自の問題なのか判別するのは難しいです。仮にそのキュー・マネージャーをフォールバックすると判断した場合、残りのキュー・マネージャーもフォールバックする必要があるかどうかも、また判断する必要があります。一方、それと対象的に、一時的にサービスを全面停止し、3つ同時にバージョンアップする場合、何か問題があったときに、全てのキュー・マネージャーを同時にフォールバックするという判断ができます。

生徒：なるほど。ちなみに、先ほどから気になったのですが、キュー・マネージャーの停止が必須ということは、移行時、キューにあるメッセージはどうなるのですか。

教授：いい質問ですね。MQでは基本的に、リソースの引継ぎ有無によらず、アプリケーションを完全に停止し、ユーザー・キューを空にして移行する方法が望ましいです。

生徒：でも、どうしてもキューのメッセージを残しておきたい場合はどうなるのですか。

教授：ノン・パーシステントのメッセージについては、キュー・マネージャーの停止が入るため、ご存知のとおり、保持されずに削除されます。パーシステントのメッセージについては、リソースを引継ぐ場合、移行の際にメッセージを保持することは可能です。ただし、万が一に備えてメッセージのバックアップを取得する必要があります。

リソースを引継がない場合、元々ログとページ・セットがありませんので、メッセージの保持ができません。その場合、なおさら、ユーザー・キューを空にすべきだと思います。しかし、どうしてもできない場合は、まず、アプリケーション・レベルでメッセージの再処理を検討する必要があります。それも不可能な場合、MQユーティリティーを使用して、メッセージのバックアップを取得して、移行後のシステムに戻す方法があります。

いずれにしても、移行テストでは、“移行前のメッセージを移行後のシステムで処理できるか”という観点のテストも実施する必要があります。

生徒：なるほど、資源を引継がない場合でも、キューにメッセージを回復することはできるようですが、移行時の考慮点が増えるので、出きる限りキューを空にした方が良いといことですね。

教授：そういうことになりますね。次に計画の立案に必要なのは②現行システムの調査です。この段階では、より具体

的なシステム構成、アプリケーション、運用、とリソース使用状況を調査します。MQが今どの様な環境・設定で稼働しているのかを今一度確認します。これにより、移行で現行システムはどの様な影響を受けるのか、そして、対応するためにどうすればよいのかを確認できます。何を確認すればいいのかは表2を見てみましょう。

第５章-

❶

生徒：はい、わかりました。今回の移行プロジェクトは、リソースの再構築が必要なMQリソース引継ぎなしの方法になりそうですね。これで、MQ移行の概要がわかったような気がします。次はどのように移行の計画を立てればよいのかを教えてください。

教授：そうですね。今度は移行プロジェクト計画の立案に必要なものを説明しましょう。

1.移行方針の検討 2.現行システムの調査 3.製品情報の調査

これらの作業を実施し、プロジェクト計画を立案します。


教授：まず、1.移行方針を確認しましょう。この段階では移行の目的、範囲や移行時のサービス・レベルを検討・確認します。

MQ移行の目的には、「製品サポート終了への対応」と「新機能の利用」の2つに大きく分類できます。その違いとしては、新バージョンに移行後、新機能を利用するかどうかです。ここで重要な考慮点としては、単純移行（ストレート・マイグレーション）と新バージョンの機能採用はフェーズを分けて考えることです。これにより、障害発生時の問題判別や回復手順が容易になり、フォールバック要否の判断も出来るようになります。

生徒：なるほど。どんな目的で移行しても、「最初の段階はストレート・マイグレーションを行え！」ということですね。

教授：そういうことですね。他に、この段階で確認が重要なのは要求されるサービス・レベルです。そもそも、MQの移行時（ライブラリーの切替）にはキュー・マネージャーの停止が必須です。つまり、キュー・マネージャー単体でみるとサービスを止めざるを得ないということです。もちろん、システムがクローン構成となっているような高可用性の構成であれば、システムの縮退や代替システムで移行時にもサービスの提供が可能です。しかし、その場合は移行期間中にサービスを提供するキュー・マネージャーのバージョンが混在する可能性があり、フォールバックの判断や問題判別が複雑になりますので、考慮が必要です。

生徒：どの様に複雑になるのですか。

教授：例えば、3つのキュー・マネージャーでクローン構成のシステムがある場合に、1キュー・マネージャーずつ移行することを考えてみましょう。3キュー・マネージャーの内2つが

1�4


1�5


第５章-

❶

教授：すばらしい、そのとおりです。接続先キュー・マネージャーは移行プロジェクト範囲に含まれていなかったりするので、プロジェクトでは考慮されていない場合があります。しかし、MQは相手とのメッセージのやり取りがあって、はじめてその機能を発揮します。したがって、MQではリモート接続の組合せ、バージョン、OS、設置場所、数についても、調査することが大変重要です。その他に、接続の形態がキュー・マネージャー接続なのか、それとも、クライアント接続なのかも把握しておきましょう。

生徒：接続相手のバージョンとOSは接続の互換性を調べるために重要なのはわかりますが、設置場所と数の情報はなぜ必要ですか。

教授：設置場所と数の情報は移行作業に大変重要なものです。例えば、チャネル同期情報を同期させるために、周辺のキュー・マネージャーからRESET　CHANNELコマンドを実行する必要がある場合、対象のキュー・マネージャーの数が5個あるか、1000個あるかでは大きな違いになるでしょう。まして、それらのキュー・マネージャーがローカル・サイトではなく、他社のデータ・センターや海外等にあったりしたら、コマンドを実行するのに、作業を依頼したりする必要があったり、時差や運用管理体制の違いで作業できる時間が異なったりするので、考慮点が全然違いますよね。

生徒：確かにそうですね。そういえば、PMの方からは、今回の移行ではホストキュー・マネージャーのみバージョンアップするため、周りのサーバーキュー・マネージャーとは、しばらくの間、異なるバージョンでのMQ接続になるかもしれないと聞きました。そもそも、その構成は可能でしょうか。

教授：MQはチャネル接続に関して互換性を維持しながら、バージョンアップされています。よって、MQの下位バージョンとの接続は基本的に可能です。ただし、バージョンの差が大きい場合は、予期せぬ事象が発生する可能性もあります。従って、サポート終了しているバージョンとの接続の際は、十分なテストが必要です。これはキュー・マネージャー接続も、クライアント接続も同じです。

生徒：接続のサポート、つまり接続に問題が発生したときの問題解析や修正プログラムの提供についてはどうなっているのでしょうか。

教授：MQのプログラム・サービスが提供されているバージョン間の接続であればサポートされます。

ただし、サポートの終了した製品に対しては、新規のトラブルに対する修正プログラムは提供されません。ですので、周辺のキュー・マネージャーに対しても早めにバージョンアップすることも検討してください。

第５章-

❶

表2. 現行システムの調査

生徒：・・・多いですね。

教授：確かに、少なくはありません。でもこれらの情報はMQ担当者として把握しておきたいものです。内容を覚えていなくても、少なくとも、どこで、どの様に情報を入手できるのかは最低限把握してください。

生徒：了解しました。確認しておきたいと思います。

教授：では、ここで、質問！！ MQのシステム構成を調査する際に、忘れてはならない重要な項目はなんでしょうか。これは“MQならでは”といっていいでしょう。

生徒：いきなりですか・・・ええと・・・接続先のことでしょうか。

環境、LPAR毎 ●パラメータ・ライブラリーの確認 ●PARMLIB,PROCLIBのデータ・セット名 ●製品ライブラリー　・SMPE環境、ZONE確認 ●TCP/IPスタック

移行対象キュー・マネージャー毎 ●起動プロシージャー名　・MSTR/CHIN ●初期入力ファイル名　・CSQINP1,CSQINP2,CSQINPX ●MQシステム・データ・セット　・ページ・セット、BSDS、ログ ●システム・パラメータ・モジュール　・ZPARM名　・XPARMはQMGR属性として実装（V6.0以降）

リモート接続の組み合わせ ●バージョン、OS、数、設置場所 ●キュー・マネージャー接続/クライアント接続

取り扱うメッセージ ●永続性 ●メッセージ長 ●トランザクション・レート

アプリケーションの種類と数 ●常駐/トリガー ●バッチ、CICS,IMS、その他 ●TSO,ISPFパネル ●サポート・パック

1��


1��


第５章-

❶

教授：これでひととおり、現行システムの調査は終わりです。今まで説明した作業に加え、移行先バージョンの製品情報の調査を実施すれば、MQの移行計画の立案は行えるはずです。

これからの道のりはまだ長いと思いますが、頑張ってください。

生徒：頑張ります！！

第５章-

❶

生徒：わかりました。これで、システム構成の確認について理解しました。次はアプリケーションの確認について教えてください。

教授：そうですね。アプリケーションの確認で必要なのはアプリの種類と数です。例えば：バッチ、CICS、IMSのアプリであるか、自作監視アプリがあるか等です。でも、最初に伝えたように、MQでは比較的アプリケーションに関する考慮点が少ないです。アプリケーションの移行作業としては、アプリケーションが実行時に使用するMQライブラリーを新バージョンのライブラリーに切り替える必要があります。再コンパイル・再リンクは基本的に必要ありません。もちろん、アプリケーションの稼働確認を含むリグレッション・テストを実施することは必須ですよ。

生徒：リグレッション・テストですね。必ず実施します。

教授：次に運用への影響を確認しましょう。特に運用・監視製品を利用する場合、確認が重要です。

生徒：なぜでしょうか。

教授：移行に伴って、システム・メッセージ、コマンド、コマンド応答、MQオブジェクト等が変更される場合があります。それらの変更の有無を調査し、自動化にどのような影響を及ぼすのか、実環境で影響があるかどうかを確認する必要があります。

生徒：なるほど。例えば、SYSLOGに出力されるメッセージを監視し、自動化の仕組みを組んでいる場合、移行によって出力メッセージの内容が変更になったりすると、自動化が正しく動作してくれないということですか。

教授：まさに、そのとおりです。そして、現行システム調査の最後のヤマはリソースの使用状況の調査です。移行をすると、ストレート・マイグレーションの場合でも、MQが使用するCPUやメモ

リといった資源の使用量が変わる可能性があります。ですから、事前に移行後の使用量を見積もって、十分な資源があることを確認する必要があります。そこでマニュアルやパフォーマンス・レポートを確認し、CPU、ストレージ、DASDの見積り、確認方法をきちんと抑えてください。

ちなみに、資源の使用量の変化はアプリケーションに依存する部分が大きいので、お客様の個別環境でパフォーマンス検証を行い、資源の使用量への影響を確認してください。

生徒：つまりパフォーマンス検証を含む、資源の使用状況の調査は必ず実施するのですね。わかりました。

1�� 1��

第５章-

❷

MQマイグレーションの第一歩②…バージョンアップによる変更の影響と対応策について（V5.3.1からV7.0.1へのケース）

生徒：コマンドで変更できると、反映にはキューマネージャーの再始動が不要になったのですね。

教授：そのとおりです。そして、変更への柔軟な対応の一つとして、チャネル・イニシエーターのXPARMモジュールが廃止され、その代わり、キューマネージャー属性として設定できるようになりました。これにより、各パラメーターの値を変更するときに、ALTERQMGRコマンドで対応可能になりました。また一部のパラメーターでは変更を反映させるのにチャネル・イニシエーターの再始動が必要なくなりました。詳細なパラメーターやそれぞれの反映されるタイミングは図②-１を確認してください。

＜チャネル・イニシエーター・パラメーター＞●太字はXPARMパラメーターから名称が追加/変更されているパラメーター●反映されるタイミングは属性により異なる　　CHIN：チャネル・イニシエーターの再起動必要　　LSN：リスナーの再起動必要　　CHL：チャネル・インスタンスの再始動必要（開始済みのチャネルに対しては反映されない）

図②-１.チャネル・イニシエーターのパラメーターと変更反映のタイミング

生徒：なるほど。確かに、パラメーター変更が柔軟になったのはよくわかりました。しかし、今回のような移行プロジェクトでは変更に対応するために、XPARMの属性をALTERQMGRコマンドとして指定しなくてはならないですよね。それは移行作業として手間が増えますし、パラメーターもかなり細かいため、手動で実施する場合は設定ミスの可能性もあると思いますが…

CSQXPARMパラメーター名 QMGR属性名変更反映

タイミング

ACTCHL ACTCHL CHINADAPS CHIADAPS CHIN

ADOPTCHK ADOPTCHK 変更後ADOPT時

ADOPTMCA ADOPTMCA 変更後ADOPT時

CURRCHL MAXCHL CHINDISPS CHIDISPS CHIN

DNSGROUP DNSGROUP LSNDNSWLM DNSWLM LSNLSTRTMR LSTRTMR LSNLUNAME LUNAME CHINLUGROUP LUGROUP LSNLU62ARM LU62ARM CHIN

CSQXPARMパラメーター名 QMGR属性名変更反映

タイミング

LU62CHL LU62CHL CHINOPORTMAX OPORTMAX CHLOPORTMIN OPORTMIN CHLSERVICE CHISERVP -TCPCHL TCPCHL CHINTCPKEEP TCPKEEP CHLTCPNAME TCPNAME CHINTCPTYPE 廃止 -TCPSTACK TCPSTACK CHINTRAXSTR TRAXSTR CHINTRAXTBL TRAXTBL 即時RCVTIME RCVTIME CHL

RCVTYPE CHLRCVTMIN RCVTMIN CHL

第５章-

❷

MQマイグレーションの第一歩……②…バージョンアップによる変更の影響と対応策について（V5.3.1からV7.0.1へのケース）

バージョンアップによる変更の影響と対応策について（V5.3.1からV7.0.1へのケース）2

生徒：教授、実は今担当しているMQ　V5.3.1からV7.0.1への移行プロジェクト計画の実施に当たり、何か固有の考慮点がないかと情報を収集しています。何かあれば教えていただけませんか。MQ　V6.0前後のバージョンで様々な変更があったとも聞きましたので・・・

教授：そうですね。確かにV6.0以降、MQではいくつか変更点があります。では、本日は移行の際の注意点について、話しましょう。

生徒：ありがとうございます。

教授：V5.3.1からV7.0.1に移行する際の考慮点は簡単に分類すると以下の項目に分けることができます。

❶ システム管理関連の変更 ❷ MQリソースへの影響 ❸ 新規追加オブジェクトやパラメーターへの対応

生徒：アプリケーションの考慮点についてはどうでしょうか。

教授：前回話したように、元々MQでは比較的アプリケーションに関する考慮点が少ないです。アプリケーションの再コンパイル・再リンクは基本的に必要がありません。また、移行作業としてMQライブラリーを切り替えて、アプリケーションの稼働確認を実施すれば、基本的に問題はないかと思います。

ただ、強いて言えば、アプリケーションの開発環境ではSTUBの入れ替えついて少し考慮点があります。ではそれを❹ アプリケーションSTUBの互換性として最後に話をしましょう。

生徒：それは是非、お願いします。

教授：それでは、先ほどの分類の❶からはじめましょう。 MQではV6.0から環境変更に柔軟に対応するため、いくつかMQ管理に関連する機

能を拡張しました。例えば、バッファープール・サイズの変更やアクティブ・ログの追加はコマンドで動的にできるようになりました。

1�0 1�1

第５章-

❷


スクがあります。そのタスクは必要がなくなったデータをバッファープールのページから消去することで、そのページを他のデータの収納に利用できるようにします。そこで、1ページに1件のメッセージを置くと決めることで、SCAVENGERの処理が効率的に動作し、その分CPUの使用量が緩和されます。

生徒：わかりました。これについてお客様に相談し、是非ご理解をいただきたいと思っていますが、万が一、ストレージの増加に大変懸念される場合はどうすればよろしいでしょうか。

教授：その場合は回避策がありますよ。実は「RECQMGR（TUNEMAXSHORTMSGS0）」という設定パラメーターをキューマネージャーのスタートプロシージャーCSQINP2のメンバーに追加することで、V7.0.0までとほぼ同じ動作に戻すことが可能です。ただし、厳密には1ページあたりに収納できるデータ長はV6.0とは異なります。詳細は以下の図②-2をご覧ください。

●ページセット01~99の見積もり　-メッセージ長毎の必要ページ数一覧（パフォーマンス・レポートMP1Gより）http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg24024589&loc=en_US&cs=utf-8&lang=en&wv=1

図②-2.ページセット01～99：メッセージサイズ毎の必要ページ数

生徒：教授、この図を見ると、「ページセット01～99」とあるのですが、ページセット00についてはどうなるのでしょうか。

第５章-

❷


教授：実はそのために、既存XPARMからの移行ユーティリティーが提供されていますよ。CSQUTILのXPARM機能を利用すれば、XPARMモジュールを入力にしてALTERQMGRコマンドを生成することが可能です。後は生成されたALTERQMGRコマンドをスタートプロシージャーのCSQIPN2に追加するだけです。なお、XPARMに由来しないQMGRのパラメーターをどのように設定するかはまた別途考慮する必要がありますよ。

生徒：それは大変便利なユーティリティーですね。是非利用したいと思います。

教授：では次に2つ目の大きな考慮点として、移行によるMQリソースへの影響について話しましょう。前回説明したように、MQでは移行の際に、ストレート・コンバージョンを行う場合でも、MQの内部仕様変更や機能の追加等により、リソースの使用量に変化がある場合があります。具体的な例としては、V7.0.1でのデータ・ページの使用方法が変更されています。

生徒：どのように変更になったのですか？

教授：一言でいうと、短いメッセージ（メッセージ長が1655バイト以下）については、使用するデータ・ページ数がデフォルトで増加するということです。

生徒：データ・ページ数の増加というのはバッファープールとページセットの両方の使用量が増加するということですか。

教授：はい、そのとおりです。

生徒：それは影響がありそうです。今回のシステムは平均500バイト前後のユーザー・メッセージを取り扱っていますので、影響は受けるはずですよね。

教授：そうですね。V7.0.1より前のバージョンでは短いメッセージを取り扱う場合、1つのデータ・ページに複数件のメッセージが入っていたのが、V7.0.1からは1つデータ・ページに1件のメッセージしか入らないことになります。現行の500バイトのメッセージですとV6までは1つのデータ・ページに4件入っていましたが、V7.0.1では1件です。単純計算ですと4倍の容量が必要になります。もちろん、正確に増加分を把握するために、見積り・検証は必要ですよ。

生徒：4倍ですか・・・大きいですね。ちなみに、なぜこの様に変更されるのですか？メリットがあるのでしょうか。

教授：もちろんありますよ。それはCPUの使用量の減少が見込めることです。実はバッファープールで、以前のバージョンから、SCAVENGERと呼ばれる“お掃除”のMQ内部タ

1�2 1�3

第５章-

❷



教授：基本的にシステム用の新規オブジェクトについては、関連する機能の使用の有無に関わらず、サンプル提供のオブジェクトは定義しておくことが推奨されています。定義した後に、もし機能を使わないのであれば、機能を無効にしたりするなど、個別に対応することができます。その理由はシステム関連のオブジェクトの多くはシステムの内部タスクに使用されたりしているからです。万が一、システム内部から要求されているオブジェクトが存在しない場合、システムに不要なエラー・メッセージが出力されたりする場合がありますので、例えMQ稼働に影響がないとしても、運用・管理の面からは好ましくない状況になりますよね。

生徒：確かに、そうですね。

教授：一方、新規パラメーターについては、前バージョンで定義されていたオブジェクトのパラメーターであっても、個別に対応しない場合は新バージョンで自動的にデフォルト値として設定されます。また、新規パラメーターにデフォルト値を設定することで、基本的に「前バージョンと同等の動作」になることが多いです。

このように、新規オブジェクトや新規パラメーターには一般的な対応方法はありますが、たまに個別に考慮が必要な場合もあります。V5.3.1からV7.0.1へ移行の際は、その具体的な例として、キューマネージャー属性のPSMODEパラメーターの設定というのがあります。

生徒：PSMODE…ええと、これはV7.0より提供されたパブリッシュ/サブスクライブ、いわゆるPub/Subブローカー機能を利用するかどうかを制御するためのものですよね。

教授：そのとおりです。デフォルトの設定値はENABLEDとなっており、Pub/Subブローカーを稼動させることになります。これは、以前のバージョンとは異なる動作になるだけでなく、使用していないにも関わらず、資源を消費することになります。よって、Pub/Sub機能を使わない場合は設定値をDISABLEDにする必要があります。


教授：ちなみに、Pub/Sub機能に関連するシステム用のオブジェクトとして新規のシステムキューやトピックというオブジェクトが複数追加されました。もちろん、前に説明しましたように、これらの新規システム用のオブジェクトを定義する必要があります。

生徒：定義しないと何かエラー・メッセージが出るのですね。

教授：そうです。実際には前のバージョンから移行する際に、SYSTEM. INTER.*という新規システム用のオブジェクトを定義せずに、稼働時にPub/Subブローカーが当該オブ

第５章-

❷


教授：よく気付きましたね。実はページセット00は少し特別なケースです。ご存知のとおり、ページセット00はオブジェクト定義など、システム情報が保持されるページセットで、ユーザー・メッセージが書き込まれるキューを配置しないことが推奨されてきました。一方今回のページ使用方法の変更はメッセージの形式で収納されるものにしか影響しません。そのため、通常の構成ではメッセージが入らないであろうページセット00は図2の記述から除外されたわけです。もちろん、ページセット00にもユーザー・メッセージを収納する場合は他のページセットと同様の影響を受けることになります。


教授：このリソースへの影響に他にはまだ考慮点があります。例えば、ストレージの使用量がデータスペースとしてShuntLog用に100MBデフォルトで増加することになります。このサイズは固定であり、キューマネージャーの終了までリリースされません。

生徒：シャ・・シャントログとは何ですか。

教授：ShuntLogはV6.0からの新機能であり、障害リカバリーのバックアウト処理時、長時間トランザクションのログ遡及範囲を短縮させるために登場しました。これによって、OS障害やMQのアドレス・スペースの障害後の再起動時のバックアウト処理に必要な時間を短縮化することができます。

生徒：ストレージ量が増加する代わりに、再起動時の処理が効率的になるということですね。

教授：そういうことになりますね。このように、どのバージョン間のマイグレーションでも、リソースへの影響は、必ずといっ

ていいほど、あります。そのため、今回のように調査することも必要ですが、調査結果を踏まえて自ら担当している個別の環境では具体的にどのような影響があるのか、現行の統計情報を元に新環境への影響を見積り、実機で検証することは不可欠だと思います。

生徒：了解しました、必ず見積りと検証を実施したいと思います。

教授：それでは、次に新規追加オブジェクトやパラメーターへの対応（③）についての考慮点です。

MQは他の製品と同様、新バージョンで新機能を実現するために、新規オプションやパラメーターを追加しています。例えば、V6.0ではクラスター構成やチャネル接続周り、v7.0以降ではパブリッシュ/サブスクライブ機能周りの新規オブジェクトやパラメーターが追加されています。ここで、V5.3.1からV7.0.1へ移行時の固有の考慮点に入る前に、まず、MQの新規オブジェクトやパラメーターに対する基本的な考え方を確認しましょう。

1�4 1�5

第５章-

❷


教授：図にあるとおり、MQではアプリケーションSTUBについて上方互換はあります。そのため、バージョンアップの際に、現行バージョンの既存実行モジュールは再コンパイルや再リンクの必要がなく、新バージョンで使用できます。　

しかし、その一方STUBの下方互換はありません。つまり、新バージョンのSTUBでコンパイル・リンクした実行モジュールは旧バージョンで使用できません。

よって、複数の環境があり、段階的に移行する場合はアプリケーションの開発環境が最後にバージョンアップすることが理想的ですね。

生徒：しかし、お客様の環境では、開発環境をテスト環境としても利用されているので、どうしても開発環境を先にバージョンアップする必要があります。どうすればよろしいでしょうか。やはり、新バージョンの開発環境で開発したものを現行バージョンの環境で実行する前に、その都度、再コンパイル・再リンクするしかないですかね。

教授：その場合、開発環境では新・旧両バージョンのライブラリーを用意し、アプリケーションのコンパイルやリンクの際は引き続き旧バージョンのSTUBを使用するようにしましょう。全ての環境がバージョンアップして、フォールバックをしないと判断した後、開発環境で使用するSTUBを新バージョンに入れ替える必要があります。

つまり、開発環境では、しばらくの間2種類のライブラリーを保持するということですね。

そのとおりです。これで一通り、V5.3.1からV7.0.1への移行の際の大きな考慮点を説明しました。

生徒：ありがとうございました。これらの情報を活用して、今回のプロジェクトを是非成功させたいと思います。

教授：オオッ、頼もしいですね。頑張ってください。

生徒：ありがとうございます。頑張ります。

第５章-

❷


ジェクトを検索しようとしますが、見つけられず、CSQSNAPにスナップ・ダンプが出力されるという事象が報告されています。

生徒：要するに、V7.0.1ではシステム用の新規オブジェクトを全部定義し、その上でPub/Sub機能が未使用の場合はPSMODEをDISABLEDにすればよろしいですね。

教授：そのとおりです。ただし、PSMODE（DISABLED）でデフォルトのシステムオブジェクトの”DEFINE

SUB（‘SYSTEM.DEFAULT.SUB’）”コマンドを繰り返し実行すると、その都度システム用キューSYSTEM.DURABLE.SUBSCRIBER.QUEUEにパーシステントの制御メッセージが1件ずつPUTされ滞留し続けるという事象が報告されています。起動プロシージャのCSQINP2から”DEFINESUB”コマンドが実行されないように、コマンドをコメントアウトするような対応が必要です。

ついでにもう１つ、V701でのCSQINP2メンバーの指定順序についての考慮点です。V7.0.0からはストレージクラス定義（CSQ4INYS）をCSQINP2の最初に追加する必要があります。CSQ4INYSをCSQ4INSGより後ろに指定する場合、起動途中でCSQV086EABNORMALTERMINATIONREASON=00D40090が出力され、キューマネージャーが異常終了することがあるからです。

生徒：なるほど。お客様のスタートプロシージャーを確認し、教えていただいた事象の対応や回避策を移行作業に盛り込みたいと思います。

教授：それが良いでしょう。では最後に、アプリケーションSTUBの互換性（❹）について説明しましょう。まず、図②-3を確認してください。

図②-3.アプリケーションSTUBの互換性

ソース･コード

コンパイル・リンク

STUB V701実行

モジュールV701

キュー･マネージャー

ソース･コード

コンパイル・リンク

STUB V6実行

モジュールV6

キュー･マネージャー

×

● 上方互換あり　旧バージョンのSTUBは、新バージョンのキュー・マネージャーで利用可能● 下方互換なし　新バージョンのSTUBは、旧バージョンのキュー・マネージャーで利用不可　対応策は以下のいずれかを選択　　1. フォールバックを想定し、移行前バージョンのスタブを継続して使用　　2. フォールバック後バージョンのSTUBで再コンパイル/再リンクが必要

1��

◆ 過去のセミナー資料

事例に学ぶ、先手を打つ！システムｚの移行情報セミナー　2012 年 5 月http://www.ibm.com/software/jp/zseries/events/migration-synthesis-seminar_2012/download/materials.html

メインフレーム最新化に役立つ移行情報セミナー　2011 年 6 月http://www.ibm.com/software/jp/zseries/events/migration-synthesis-seminar_2/download/materials_june8.html

メインフレーム最新化に役立つ移行情報セミナー　2011 年 2 月http://www.ibm.com/software/jp/zseries/events/migration-synthesis-seminar/download/materials.html

◆基盤更改をご支援するシステム変更負荷軽減サービス（zCT）のご紹介　（YouTube）http://www.youtube.com/watch?v=TBUbxE1zrCU

◆システム変更負荷軽減サービス（zCT）http://www.ibm.com/systems/jp/z/solutions/zct/

※本書は、Systemzソフトウェア・クラブニュース（メールマガジン）で2010年8月～2011年11月に連載したコラムを、加筆・修正したものです。

参考資料

IBM、 IBMロゴ、 ibm.com、 CICS、 DB2、 IMS、 OMEGAMON、 RACF、 Tivoli、 WebSphere、 z/OSは、世界の多くの国で登録されたInternational Business Machines Corporationの商標です。他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。現時点での IBM の商標リストについては、www.ibm.com/legal/copytrade.shtmlをご覧ください。●掲載された情報は2013年2月現在のものです。事前の予告なく変更する場合があります。 ●製品、サービスなどの詳細については、弊社もしくはIBMビジネスパートナーの営業担当員にご相談ください。 ●本事例中に記載の肩書や数値、固有名詞は掲載当時のものであり、変更されている可能性があることをご了承ください。