4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

IBM i の「システム値」について知ろう! ~日々の業務に役立つチェックリスト~

Posted at

はじめに

この度、IBM社主催のIBM i RiSING2025プロジェクトの一環として、この記事を作成しています。
今回は、IBM i における「システム値」を理解するうえで、私が必要だと思う内容を完全な独断と偏見でピックアップしましたので、興味のある方はご確認いただけると幸いです:relieved:

1. システム値とは

1-1. システム値とは
IBM i で使用される設定情報の一部でシステムの動作やユーザー環境に大きな影響を与えます。これらの値は、システム全体に対して設定され、システムの初期化時や起動時に読み込まれます。 システム値は、下記にある通りそれぞれの項目において非常に重要です。

①セキュリティ
セキュリティ設定が適切でない場合、システムが危険にさらされる可能性があります。
②言語と地域設定
システムの表示言語やメッセージが設定され、ユーザビリティに影響します。
③データの処理
データの文字コードが決まり、データの保存や表示に影響を与えます。

1-2.システム値の役割、メリット
システム値は、それぞれの設定値ごとに役割を持っています。
例えば、サインオン、パフォーマンス、セキュリティなど様々な役割があります。

中でもシステム値の大きなメリットは、セキュリティ管理が容易である点です。
システム値の各項目の設定はコマンド:WRKSYSVALにまとめられているため、
どこを見ればどの設定が確認できるかあるいは変更できるかが明確になっています。 コマンド1つで完結できるなんて、魅力的だとは思いませんか?
また、システム値はOSの大部分においてデフォルト値にもなっているため、
例えば、ジョブの実行時の設定値に関して、システム値を省略値としつつ、変更したい点があれば該当箇所のみ変更すればいいという非常に容易な運用にも繋がっています。

WRKSYSVAL画面
image.png

2.カテゴリ別のシステム値

2-1. すべてのカテゴリについて
システム値は大きく17のカテゴリに分けることができます。
黒画面上では、一覧で表示されますが、IBM i にOS標準で備わっているサービス「Navigator for i 」では、カテゴリ別に確認することができます。
IBM i は黒画面がほとんどだと思われている方が多いかと思いますが、ブラウザベースでのサービスもあるのです:clap:

image.png

image.png

Navigator for i に接続しなくとも内容が確認できるよう、こちらで実際にカテゴリについて詳しく見ていきましょう!対象となるシステム値はかなり多いので、ここでは一部の例を挙げてご説明しています。

①監査
監査値を変更します。 システム値の例:QAUDCTL、QAUDLVL

②日時
日付、時刻、および時間帯情報を変更します システム値の例: QDATETIME、QCENTURY

③装置
装置自動構成および回復値を変更します システム値の例: QAUTOCFG, QDEVNAMING

④インターナショナル
ロケールの設定と数字、日付、および時刻の形式を変更します システム値の例: QDATFMT、QCCSID、QLOCALE

⑤ジョブ
システム・レベルのジョブ限界およびデフォルトのジョブのプロパティーを変更します システム値の例: QMAXJOB、QACTJOB

⑥ライブラリーリスト
デフォルトのライブラリー・リストを変更します システム値の例: QSYSLIBL、QUSRLIBL

⑦メッセージおよびサービス
メッセージ、ロギング、およびサービス情報を変更します システム値の例: QHSTLOGSIZ、QCFGMSGQ

⑧パスワード
パスワードの有効期限および妥当性検査を変更します システム値の例: QPWDLVL、QPWDCHGBLK

⑨パフォーマンス
処理、メモリー・プール、通信、およびデータベースのパフォーマンス値を変更します システム値の例: QMCHPOOL、QTHDRSCADJ

⑩電源制御
電源機構値を変更します システム値の例: QUPSDLYTIM、QUPSMSGQ

⑪印刷中
基本印刷値およびプリンター出力の形式を変更します システム値の例: QPRTDEV、QPRTKEYFMT、QPRTTXT

⑫再始動
初期セットアップ値および再始動に影響する設定を変更します システム値の例: QIPLTYPE、QPWRDWNLMT、QIPLSTS

⑬保管および復元
保管および復元値を変更します システム値の例: QVFYOBJRST、QALWOBJRST

⑭セキュリティ
オブジェクト、ユーザー、およびシステム・セキュリティー値を変更します システム値の例: QSECURITY、QSSLCSL

⑮サインオン
サインオン値を変更します システム値の例: QMAXSIGN、QMAXSGNACN、QLMTSECOFR

⑯記憶域
システム記憶域の値を変更します システム値の例: QSTGLOWLMT、QSTLOWACN、QRCLSPLSTG

⑰システムおよびユーザーのデフォルト
システム識別情報の表示およびユーザーのデフォルト値を変更します システム値の例: QCONSOLE、QPRCMLTTSK

2-2. セキュリティ
システム値の重要な役割ともいえる「セキュリティ」について、ポイントを押さえていきます。
2-1での記述通り、セキュリティにカテゴライズされるシステム値は下記です。

対象のシステム値:
QSECURITY、QUSEADPAUT、QRETSVRSEC、QCRTAUT、QALWUSRDMN、QSCANFS、QSCANFSCTL、QSHRMEMCTL、QSSLPCL、QSSLCSLCTL、QSSLCSL

セキュリティ関連のシステム値は複数ありますが、中でも非常に重要なシステム値がQSECURITYです。
QSECURITYは、システム全体のセキュリティレベルです。システム値の特徴として、

変更時にシステムの再起動(以降、IPL)を必須とする場合があります。

QSECURITYも例外ではなく、設定値の変更はIPLが行われたあと初めて有効となります。
次に、QCRTAUTです。これは、簡単に表現すると、ユーザーが扱うオブジェクトに付与される共通権限の設定についてです。
例えば、QCRTAUT=*ALLに設定すると、システムの全ユーザー(*ALLより上位権限を持つユーザーが対象)が新規作成されるオブジェクトを完全に制御することができます。
「完全に制御する」とは、つまり、オブジェクトの読みとり、変更、削除、管理全般の操作が可能ということです。


2-3. 監査
IBM i には、企業の基幹システムならではともいえる監査を目的とした機能・サービスが備わっています。わかりやすい機能だと、「監査ジャーナル」がありますが、同様にシステム値にも監査を目的とした設定値があります。
監査カテゴリーに含まれるシステム値は下記のとおりです。

対象のシステム値:
QAUDCTL、QAUDLVL、QAUDLVL2、QAUDENDACN、QAUDFRCLVL、QCRTOBJAUD

監査ジャーナルにかかわるシステム値としては、QAUDLVLQAUDLVL2です。
この2つのシステム値により、すべてのシステム・ユーザーを対象として、セキュリティー監査ジャーナル (QAUDJRN) にどのセキュリティー関連の事象をログに記録するかを決定できます。
例えば、QAUDLVLが *NONE だった場合、たとえ、QAUDLVLまたはQAUDLVL2に設定値が入っていたとしても、これらのシステム値で制御される事象はログに記録されません。
端的にいえば、ログとして残すならば、QAUDLVLの設定は必須ということです。
社内のセキュリティを考慮するうえで重要なシステム値ですね!

2-4. メッセージおよびサービス

対象のシステム値:
QHSTLOGSIZ、QCFGMSGQ、QACGLVL、QSTSMSG、QPRBFTR、QPRBHLDITV、QSFWERRLOG、QSRVDMP、QRMTSRVATR

メッセージおよびサービスカテゴリーにあてはまるシステム値は、主にIBM i 全体で発報されるメッセージを制御している内容が多いです。
IBM iのログには主に、「ジョブ・ログ」「ヒストリー・ログ」「問題ログ」がありますが、この「ヒストリー・ログ」を管理しているのが
QHSTLOGS(最大ヒストリー・レコード数)です。ヒストリー・ログのレコード数の最大値を決めることができ、この最大値を超えるとシステムは自動で新しくログのバージョンを作成していきます。
バージョンは、ログが保管されている箱のようなイメージです。

ヒストリー・ログ(DSPLOGで確認可能)
image.png

2-5.ジョブ

対象のシステム値:
QMAXJOB、QACTJOB、QTOTJOB、QADLACT、QADLTOT、QADLACTJ、QADLTOTJ、QLOGOUTPUT、QJOBMSGQFL、QJOBMSGQMX、QINACTMSGQ、QDSCJOBITV、QMLTTHDACN、QSPFACN、JOBSPAL

ジョブ関連のシステム値では、文字通りIBM i 環境で稼働するすべてのジョブを制御しています。
例えば、QMAXJOB(ジョブの最大数)では、システムで許可されるジョブの最大数を指定します。
設定した最大数値を超えると、バッチを含むそれ以上のジョブは投入・開始不可となります。なお、最大数値として設定できるのは970000です。

また、ユーザーが意識するシステム値としては、QJOBMSGQFL(ジョブ・メッセージ待ち行列満杯処置)があります。
これは、ジョブ・メッセージ待ち行列が満杯になったとき、どのような処置を行うかを決める値です。
ジョブに関するメッセージが「ジョブ・メッセージ待ち行列」という箱たくさん保管されてしまって、入りきらなくなった!という状況を想像していただくとわかりやすいかと思います。
このようにシステム値には数字の設定だけではなく、いくつかの選択肢をもとに設定可能な文字ベースの設定値が存在します。それぞれの選択肢に意味があるので、注意が必要ですね。
設定値に関して、 *WRAP であればジョブ・メッセージを折り返してくれます。
*NOWRAP であれば折り返しが行われないので、ユーザーのインターフェースでは途中でメッセージが切れてしまっているように表示されます。
*PRTWRAP であれば折り返しつつ、折り返したことで重なった部分を印刷します。
個人的には、*PRTWRAPの設定でストレスなくお使い頂くのがいいと思います。

3. 設定値の変更に伴うシステムの挙動

3-1. ユースケース①「セキュリティ設定の強化」

今回、想定する目的は、システムに対する不正アクセスのリスクを低減するために、セキュリティレベルを向上させることです。
変更の対象となるシステム値はQSECURITYです。
このシステム値は、前述した通りにシステム全体のセキュリティ部分を管理する設定値です。
QSECURITYを変更するというのは、システム全体にとって大きなイベントとなります。

IBM社のWEBサイトによると、QSECURITYにおける下記のセキュリティーレベルの機能比較表があります。

機能 レベル20 レベル30 レベル40 レベル50
サインオン時にユーザー名が必要  はい  はい  はい  はい
サインオン時にパスワードが必要  はい  はい  はい  はい
パスワード・セキュリティーが活動状態   はい  はい  はい  はい
メニューおよび初期プログラム・セキュリティーが活動状態   はい  はい  はい  はい
制限機能サポートが活動状態   はい  はい  はい  はい
資源保護が活動状態  いいえ  はい  はい  はい
オブジェクト・アドレスを使用したすべてのオブジェクトへの直接アクセス。   はい いいえ いいえ いいえ
ユーザー・プロファイル自動生成  いいえ いいえ いいえ いいえ
セキュリティー監査機能が使用できる   はい  はい  はい  はい
制限された命令を含むプログラムを作成/再コンパイルできない   はい  はい  はい  はい
サポートされていないインターフェースを使用するプログラムが実行時に失敗する  いいえ いいえ  はい  はい
全記憶域で拡張ハードウェア記憶保護を実行する  いいえ いいえ  はい  はい
ライブラリー QTEMP が一時オブジェクトである  いいえ いいえ いいえ いいえ
*USRSPC、*USRIDX、*USRQ オブジェクトは、QALWUSRDMN システム値で 指定されているライブラリーでのみ作成できる   はい  はい  はい  はい
パラメーターで使用されるポインターは、システム状態で実行している ユーザー・ドメイン・プログラムに対して、妥当性が検査される  いいえ いいえ  はい  はい
メッセージの処理規則が、システムおよび ユーザー状態プログラム間で実施されている  いいえ いいえ いいえ  はい
プログラムの関連スペースが直接変更できない  いいえ いいえ  はい  はい
内部制御ブロックが保護されている いいえ いいえ  はい  はい

引用:システム・セキュリティー (QSecurity) システム値の使用方法

IBM i のバージョンV7R5より、QSECURITY20の廃止が行われています。これまで、設定値:20で運用されていたお客様にとっては、大きな変更点だったかもしれません。
ただ、マシン上で選択肢が存在しない状況になるほど、世の中全体でセキュリティへの意識が高まった証拠ともいえると思います。

そろそろ、皆さんもQSECURITYの変更方法を知りたい頃かと思うので、本題です。
実は、先に種明かしをすると、ユースケースに取り上げるほどの大変な作業ではありません。
ただ、前述した通り、キーポイントになるのは変更にマシンの再起動を伴うということです。
ここで、少し余談ですが、再起動は自動と手動の2パターンがあります。
自動は、マシン上で設定される時刻に自動で行われます。問題は、手動パターンですが、こちらはお作法が必要です。
あまり、ユーザーの方々が自ら再起動されるということはないかと思いますが、今回は敢えてPowerサーバーの再起動方法も含めてQSECURITY変更の手順を記載します。

<QSECURITYの変更>
①コマンドWRKSYSVAL QSECURITYにて「OPT5:表示」で現在のセキュリティ値を確認する。
画像からもわかる通り、V7R5以降の環境では20以下はサポートされていない。

image.png

②変更するべきシステム値を設定する。変更画面では、設定可能な値のみが表示される。
今回は50に設定することを想定します。

image.png

③変更内容は即時には反映されないため、IPLの準備を行う。

④IPL準備のため、下記コマンドを実行する。

・コマンドWRKACTJOB SBS(QINTER)を実行し、サブシステムQINTER配下で動いているジョブがないかどうかを確認。
画像では、配下のジョブが動いている様子が確認できる。
image.png

・ジョブがない状況になったら、制限状態へ移行する。
※制限状態とは...すべてのサブシステムが停止し、制御サブシステムのみが稼働している状態のこと。ユーザーがサーバーにアクセスできない状態ともいえます。

各サーバーを停止後に、サブシステムをすべて落とします。
念のため、コマンドWRKSBSでサブシステムの確認を行います。最後に制御サブシステムのみが残っていればOKです。サブシステムの停止は少々時間がかかりますが、そのまま待ちます。

ENDTCPSVR *ALL
ENDHOSTSVR *ALL
ENDTCP
ENDSBS *ALL *IMMED

WRKSBS

⑤IPLを実行します。再起動の際は、下記コマンドを実行します。
※RESTART(*YES)を忘れてしまうと、電源停止になり、マシンは自動で起動されないため注意が必要です。
PWRDWNSYS OPTION(*IMMED) RESTART(*YES)

image.png

⑥再起動されたら、QSECURITYを再度確認し、変更後の値が設定されているか確認しましょう。

ここまでが、QSECURITYの変更方法です。設定値を上げることで、ユーザーのアクセス権限を厳格に管理できるようになり、結果的に不正アクセスのリスク低減にも繋がるかと思います。

3-2. ユースケース②「負担軽減につながる仮想装置の運用」

今回の目的は、システム管理者が仮想装置の管理を簡素化し、運用負担を軽減することです。
そこで、変更の対象なるのがシステム値QAUTOVRTです。
QAUTOVRTでは、Telnetサーバーが自動的に構成される仮想装置の数を制限します。

現在は、QAUTOVRT が 0(無効) に設定されている想定です。
この場合、仮想装置を新たに追加する際は毎回手動での構成作業が求められます。
これにより、特に繁忙時には多くの時間を費やす必要があり、業務に支障が出ることもあります。

今回は、ユーザー人数を考慮し、「20」を設定します。(数字は1から32500 まで設定が可能です。)
早速、変更していきましょう!

①まずは、現在値を確認します。
WRKSYSVAL QAUTOVRT

image.png

②WRKSYSVAL QAUTOVRT にて「OPT2:変更」で20に変更します。
image.png

③20に変更しました。QAUTOVRTは変更した設定値が即座に反映されるので、赤枠のメッセージを確認して終わりです。
image.png

期待される効果としては、自動構成により、仮想装置の追加を手間なく行えるため、管理者の負担が軽減されます。
ただし、注意点としては、新しい仮想装置が知らぬ間に追加されるため、リソースの使用状況や運用面での影響を定期的に確認することが重要です。

4.システム値を変更するうえでのチェックリスト

ここまでシステム値の変更に焦点を当ててきましたが、実際にはシステム値を変更するうえで何を意識すべきかということは大切な要素になるかと思います。
そこで、今この記事を読んでくださっている方々が実際にシステム値を変更するという状況になった際、役立つチェックリストを作成しましたのでぜひご活用ください!

✅ チェックリスト

  • 目的の明確化
    システム値変更の目的は何か?(例えば、パフォーマンス向上やセキュリティの強化)
    →目的が不明確だと、どの値をどのように変更すべきか判断が難しくなります。

  • 影響範囲の確認
    変更がシステムやアプリケーションに与える影響を評価する。
    →例えば、その設定がどのシステムやプロセスに関連しているのか、影響を受けるユーザーは誰かを確認します。

  • 現在の設定のバックアップ
    変更前に、現在の設定値をバックアップする。
    →万が一問題が発生した際に、迅速に元に戻すことができるようにします。バックアップは、コマンドやスクリプトを用いて自動化することも可能です。

  • 参考資料の確認
    公式サイトやベストプラクティスを確認する。
    →変更の影響度やベストプラクティスを理解します。これにより、設定変更が正しく行われ、意図した結果をもたらす可能性が高まります。

  • 変更手順の作成
    変更の具体的な手順を洗い出し、記録する。
    →この手順には、必要なコマンドや操作を含め、誰が実行するのか、実行日時はいつかなどを明確にします。

  • テストの計画
    本番環境に変更を適用する前に、テスト環境で変更を試験する。
    →テストでは、想定した動作がなされるか、問題が発生しないかをチェックします。特に再起動手順をユーザー側で確認する場合には要注意です。

  • ロールバックプランの準備
    開発ほど難易度は高くありませんが、もし変更が問題を引き起こした場合に備え、元の設定に戻す手順を用意する。
    →これには、どのコマンドや手順を使用するかを事前に明記しておくことが重要です。

  • 影響のモニタリング
    変更後はシステムの動作をモニタリングし、異常がないか確認する。
    →パフォーマンスの変化やエラーメッセージをチェックし、異常があれば迅速に対応します。

  • ドキュメントの更新
    設定変更を行った場合、関連するドキュメントやマニュアルを更新する。
    →特に、今後のメンテナンスや他の管理者が参照できるよう属人化を防ぐためにも文書化は重要です。

  • 従業員への通知
    「影響範囲の確認」にも関連するが、システムの利用者に対して、変更の時期や内容・影響を周知する。
    →変更作業自体のアナウンスは非常に重要です。また、変更内容を伝えることで利用者が新しい設定に対応できるようになります。

5.おわりに

今回、記事の投稿にあたり、システム値を選んだ理由は、原点に返って基幹システムの管理・運用の見直しに少しでも寄与できればと思ったためです。
私自身、業務上、システム値を確認したり変更したりする機会が多かったのですが、システム値を知っていく中で、ユーザー・ベンダー関係なく、Powerサーバーの根幹部分ともいえる部分を知ることはPowerそのものを扱ううえで非常に重要だと感じました。
開発業務がメインで、なかなかインフラ部分を触ることがないという方でも知識さえ持っていれば、エラー分析にも役立つ機会があるかもしれません。
一度、基礎に立ち戻って自社のPowerサーバーにおけるシステム値を見直してみてはいかがでしょうか。
本記事が何かのお役に立てれば幸甚です。
それでは、またいずれどこかの記事でお会いしましょう。


当記事の著作権はIBMに帰属します。
詳細はこちらを参照ください。

4
0
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?