Google
オフコン練習帳内を検索
インターネット全体を検索

NECオフコン関連
オフコン一般
情報

トップ  >  カンパニを利用してテスト環境を作る

8.使用例

(1)カンパニを利用してテスト環境を作る

●カンパニを使った例

カンパニを使うと、カンパニ毎にファイルを独立することができる為、これを利用して1台のオフコン上に本番環境とテスト環境を作ることができます。
(ただし、CPUやメモリなどの資源は共有するので、本番環境にテスト環境が全く影響を与えないというわけではありません。あくまでもファイル管理上複数の環境が作れるということです。)

カンパニを簡単に説明すると、1つのA−VXを擬似的に複数のパーティションに分割することができるということになります。
カンパニを構成すると、ローカルファイルとグローバルファイルという2種類のファイルを作ることができるようになります。グローバルファイルはどのカンパニからもアクセスすることができるファイル、ローカルファイルはそのカンパニからしかアクセスすることができないファイルです。ローカルファイルはカンパニ毎に独立して管理されているので、カンパニが異なれば同じ名前のファイルを作ることもできます。これを利用します。



カンパニ:TSTで実行したジョブからは、自分のカンパニのローカルファイルしかアクセスすることはできない。上図のテスト環境で実行したジョブ:DJOBは、テスト環境のローカルファイルA−FILE、B−FILEを常にアクセスすることになり、本番環境のローカルファイルA−FILE、B−FILEにアクセスすることはできない。即ちテスト環境で実行したテストプログラムは常にテスト環境のテストファイルにアクセスすることになり、本番環境側のファイルを壊すことはない。本番環境側は何の問題もなく、従来通り本番環境のファイルをアクセスすることになる。テストプログラムはテスト後そのまま本番環境に持っていくことができ、プログラム内に記述しているファイル名を直したりする必要は全くない。
ただし本番環境のファイルをグローバルファイルとしている場合にはどのカンパニからもアクセス可能なので上記のようなことはできない。

例えば、本番環境カンパニとテスト環境カンパニがあるとします。

本番環境側にあるファイルは全て本番環境カンパニのローカルファイルにします。
本番環境側にあるファイルのうち、テストに使用したいファイルを同名、同属性のローカルファイルとしてテスト環境側にコピーします。
テスト環境側で、テストしたいプログラムを実行します。カンパニを超えてローカルファイルをアクセスすることはできないため、テストプログラムはテスト環境側の同名ファイルを常にアクセスすることになり、本番環境のファイルをアクセス(更新等)することは絶対ありません。
(本番環境のファイルがグローバルファイルになっていると、アクセス可能になってしまうのでダメです。)

SYS@LML、SYS@JSL、SYS@DDF等に格納する情報は、システムで1個(カンパニ毎にならない)ので、ここは気をつける必要があります。例えばDBで同じ名前の表はカンパニ毎に作ることができません。(SYS@PMLはカンパニ毎に作ることもできる。)

●まとめ

最初に書いたように、CPUやメモリ等の資源はカンパニで共有されることにも注意が必要です。例えばテスト環境側でCPU負荷の高いプログラムを動かしたりすると本番環境側にCPU資源が渡らなくなり本番プログラムが遅くなります。

上記のように本番環境とテスト環境を作る使い方をするならば、2つのカンパニでプログラムを実行させるだけの能力を持つCPU、メモリ等を選択する必要があるでしょう。またシステム全体で実行するジョブ数も増える(本番環境ジョブ+テスト環境ジョブ)ので、その分SGで(いろいろな)設定値を増やす必要もあります。
カンパニはあくまでも同一のオフコン上で、A−VXを複数のパーティションに分ける機能でしかありません。完全にシステムとして独立しているわけではないので、限界があることも考慮しましょう。

「カンパニありシステム」は「カンパニなしシステム」とは異なり、業務開始時に「どのカンパニで業務するか」を入力しなければならなくなります。端末起動時の操作性が変わるので注意が必要です。

このようにカンパニを使うと、IBMのSystem iの論理パーティショニング機能に近い使い方ができます。

(これはあくまでもカンパニを使ってどんなことができるかの紹介です。おそらく既にカンパニを構築している場合にはマスタファイルはグローバルファイルになっている可能性が高いし、逆にカンパニ未導入の場合はまず最初にカンパニありシステムにするために多大な労力がかかるため、以上の説明はあまり役に立たないかもしれません。)