r11.0からr12.0へアップグレード後に複数のJCLをバッチのCA JCLCheckを使って一括して検査したところ、r11.0とr12.0で違いがありました

Document created by YOSHINORI_MOMIKI Employee on Jun 8, 2015Last modified by YOSHINORI_MOMIKI Employee on Jun 8, 2015
Version 1Show Document
  • View in full screen mode

文書番号: JTEC000607

 

製品名:CA JCLCHECK WORKLOAD AUTOMATION

バージョン:r12.0

OS: z/OS

 

Question


r11.0からr12.0へアップグレード後に複数のJCLをバッチのCA JCLCheckを使って一括して検査したところ、r11.0とr12.0で違いがありました。


r11.0:
複数のJCLがあった場合に、その中の一番最後のJCLのリターンコードがバッチのCA JCLCheckのコンディションコードとなっています。


例)以下のケースの場合は、CA JCLCHECKのコンディションコードは0で返されました。


JCL1 RC=0
JCL2 RC=8
JCL3 RC=0


r12.0:
複数のJCLがあった場合に、その中の検証結果のリターンコードの一番大きいものがバッチのCA JCLCHECKのコンディションコードとなっています。


例)以下のケースの場合は、CA JCLCHECKのコンディションコードは8で返されました。
JCL1 RC=0
JCL2 RC=8
JCL3 RC=0


特にCA JCLCheckのオプションは変更しておりませんが、何故このような結果になるのでしょうか。


Answer


この事象はCA JCLCheckのJOBSEVオプションがr11.0とr12.0の間でデフォルト値が変更されている理由によるものです。


r11.0の初期バージョンでは、"NOJOBSEV"がデフォルトでした。

r12.0では、JOBSEVがデフォルトとして変更されています。

このデフォルト値の変更はr11.0のPTF:RO21192によって行われています。


オプションの内容について
NOJOBSEV:一番最後に検証されたCA JCLCheckのリターンコードを返します。
JOBSEV :検証されたCA JCLCheckの中で一番高いリターンコードを返します。

Attachments

    Outcomes