８．使用例

（１）カンパニを利用してテスト環境を作る

●カンパニを使った例

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

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

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

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

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

ＳＹＳ＠ＬＭＬ、ＳＹＳ＠ＪＳＬ、ＳＹＳ＠ＤＤＦ等に格納する情報は、システムで１個（カンパニ毎にならない）ので、ここは気をつける必要があります。例えばＤＢで同じ名前の表はカンパニ毎に作ることができません。（ＳＹＳ＠ＰＭＬはカンパニ毎に作ることもできる。）

●まとめ

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

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

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

このようにカンパニを使うと、ＩＢＭのＳｙｓｔｅｍ　ｉの論理パーティショニング機能に近い使い方ができます。

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