ｚマイスターとの新たな価値探求System z ソフトウエアの最新機能と、最新化がもたらす価値

ｚマイスターとの新たな価値探求System z ソフトウエアの最新機能と、最新化がもたらす価値

Systemｚ は IBM メインフレームの 45 年以上の歴史において、多くのお客様の基幹システムを支えるインフラとして採用され、現在も最新のビジネス・ニーズに対応すべく、ハードウェア、ソフトウェア共に進化し続けているプラットフォームです。技術の進化、移り変わりの激しいＩＴ業界の歴史においても、これだけ長く、継続してお客様に価値を認めていただいているプラットフォームは、他に例が無いでしょう。

そのことを裏付ける事実として、全世界の市場を見てみると2010 年から2012 年にかけて、System ｚ のビジネスは飛躍的な伸びを示しています。一方で、日本の市場においては、日本国産ベンダーのメインフレームのイメージを元に、メインフレームに対するネガティブなイメージが散見されています。そのイメージを払拭するために、進化・発展してきた IBM System ｚ が提供する機能とそれによって得られるメリットをより分かり易い形に整理し、お伝えできるように取り組みを進めています。

本コラムでは、最新のバージョンに移行して頂いた暁に、活用頂ける最新のソフトウェアの機能と、最新化がもたらす価値について、主要なミドルウェアの切り口から、お届けいたします。

先輩： IT部門のシニアな社員。豊富なメインフレーム経験を持つ。自称“zマイスター”

後輩：IT部門若手社員。

メインフレームが主担当だがオープン系も一部担当する。

登場人物

� �

【第1章】 System z ① System z のビジネス価値とは？

第1章

System z

1 System z のビジネス価値とは？

　メインフレームの価値

後輩 ： メインフレームの運用に関わって数年になりますが、最近は仕事にも慣れてきて、自分の仕事がどのようにビジネスに貢献しているのか気になるようになってきました。さらに、これからもっと役立つためにはどうすればよいのかということも考えたいと思っています。そこで、先輩に色々と伺いたいのですが、よろしいでしょうか？

先輩 ： なるほど。前向きな考えですね。では、まず目の前にあるメインフレームにどんな価値があるのか考えてみるのはどうでしょう。加えて、IBM の一番新しい Systemｚ というメインフレームがもたらすビジネス的な価値についても考えてみましょうか。例えば、どんなポイントに興味がありますか？　どんなことでもよいでので、疑問に思っていることを聞いて下さい。

後輩 ： はい、よろしくお願いします。では、まずメインフレームというと、真っ先に思い浮かぶのがシステムの信頼性だと思うのですが、具体的な価値として見えにくいですよね。この部分について、どのように考えればよいでしょうか？

先輩 ： システムの信頼性については、ハードウェアで故障しにくい部品を使うことや、不具合が出たところを自動で予備に切り替えるような止まらないための仕組みを備えていることが大事です。System z のハードウェアは、そのような仕組みを備えているのに加え、ミドルウェアの品質も他のプラットフォームと比較して、良好であるということが挙げられます。ソフトウェアの品質が悪い場合には、システム構築時のテストや、本番稼働後のトラブルの対応などで、より多くの工数が必要となり、見えないコストが大幅に増加することになり、投資対効果を低下させる原因となります。

後輩 ： あと、オフィスにある UNIX サーバーでは、トラブルの対応で、ダンプやトレース等を用いても問題が特定できなかったり、とりあえず最新の Fixpack を適用して様子をみたりし

なければならない事があり、トライアンドエラーによる対応をせざるをえない事が多々あります。また、月末のデータを大量に処理するような場合でも、Systemｚ は CPU 使用率が100%を振り切っても、大事な処理を優先的に判断したりして、システム全体がスローダウンすることなく稼働し続けますよね。これがビジネスになると、業務を止めることなく、ビジネスへのインパクトを抑止できることも大きなメリットになると思います。

先輩 ： WorkLoad Manager のことですね。確かにこれは、IBM Systemz のアーキテクチャーの特長で、信頼性を実現している大きなポイントです。また、アーキテクチャーの観点で言えば、Systemｚ はハードウェアとソフトウェアがシナジーをもって一体となり、昨今流行のアプライアンス的な価値も提供しています。例えば、Sysplex というクラスタリング構成で DB2 のデータを共用している場合は、ハードウェアとソフトウェアが一体となってデータベースの整合性をとりつつ、拡張性、可用性を実現しています。さらに昨年発表されている DWH アプライアンスである「IBM DB2 Analytics Accelerator」を使用すれば、DB2 上の基幹データを用いた DWH 系の処理がより高速になり、そのまま情報系のデータとして使用できるわけです。

後輩 ： そう考えると、その IT システムをコスト・センターではなくプロフィット・センターとして捉えることができそうです。データは増える一方ですから、その活用方法は大事ですね。

先輩 ： 新規に取り組む価値が見えてきましたか。その他には、ビジネス要件に応じて柔軟に拡張できるかといった観点があります。例えば IMSというデータベース製品の最新のベンチマーク・テストでは、一秒間に６万件のオンライン・トランザクションを処理できることが確認されています。ACID 属性※ 1 を保ちながら、シングル・システム・イメージでこれだけ拡張性のある仕組みを提供できるのは IBM System z だけでしょう。このような拡張性は、ビジネス・ニーズ拡大に対応する際の、既存投資の保護という意味で大きな価値を提供するものです。

後輩 ： さすが、先輩。わからない言葉もちらほら…。 投資の観点だと、メインフレームは高いというイメージがありますが、一方で、先に話した

障害時の手間暇なども入れて考えるとシステム全体では最新の Systemｚ は決して高くはないという記事も読んだことがあります。また、システムの数が 20 から 30 を超えると、メインフレームに統合したほうが、コストが安いという話も。実際のところはどうなのでしょうか。具体的なデータの積み上げで語れるものはないでしょうか？

先輩 ： IT の経済性について研究している Howard Rubin 博士という人のレポートでは、様々な業界のITコストについての調査を実施した結果、会社の規模が大きくなれば、その製品・サービス単位の IT コストは、メインフレームをベースにしたシステムのほうが、安いという報告があります。Web サイトに掲載されている各種レポートには具体的なデータが記載されているので、納得できるかどうかは一読して判断してみてください。※ 2

�

【第1章】 System z ① System z のビジネス価値とは？

�

【第1章】 System z ① System z のビジネス価値とは？

後輩 ： はい、後で詳しく見てみます。

　System z 上で稼働するミドルウェアの拡充

先輩 ： これまで話してきたように、伝統的に語られてきたｚインフラストラクチャーの信頼性であるとか、ＴＣＯメリットにもまして重要なことは、System z 上で稼働するミドルウェアが機能を拡充して進化し続けており、今や、その能力はデータ・マネジメント、アプリケーション基盤、サービス・マネージメントで必要とされる機能をほぼカバーしているという事実です。

後輩 ： そうですか。たとえばデータベースのエリアでいうと、どのような事が可能となっているのでしょうか？

先輩 ： 企業の IT 化の歴史において、過去は、既存業務プロセスの効率化のためにシステムが作られ、その多くの基幹業務システムがメインフレーム上でつくられてきました。しかし、これからは、その基幹業務で扱っているデータを、如何に企業のビジネスを伸ばすために活用できるかが、企業成長の鍵となっていくのは間違いないでしょう。

後輩 ： 基幹データは、いくつもの加工を経て練り込まれた情報資産ですからね。 その活用のためには、どのようなものが提供されているのでしょうか？

先輩 ： このエリアでは、DB2 や IMS のデータを情報系システムに連携するための InfoSphere製品群、ビジネス・インテリジェンス（BI）ソフトである Cognos や、 分析用ソフトのSPSS など、既存データからビジネス・インサイトを得るためのミドルウェアが揃っています。これらのソフトウェアを用いることにより、Systemｚ 上でミッション・クリティカルなDWH、オペレーショナルＢＩといった、リアルタイムに基幹データを活用するシステムを構築することが可能になります。これらの付加価値の高い情報を経営判断に生かせば、そこから得られるビジネス的な価値は非常に大きなものとなるでしょう。

後輩 ： ありがとうございます。色々な製品名も出てきましたね。 確かにデータ・マネジメントのエリアについては、具体的な価値のイメージが掴みやすい

のですが、アプリケーションの基盤として考えた場合に重要なポイントはどのあたりでしょうか？

先輩 ： このエリアで最も重要なことは、企業として、新しいサービスを如何に迅速に投入できるかという点です。この点においては、Operational Decision Manager（ODM）という製品に代表されるルール・ベースのアプリケーション開発や、CICS、IMS といった伝統的ミドルウェアのＳＯＡ対応など、インフラとして必要な機能が、ミドルウェアによって一通り提供されています。

後輩 ： なるほど。従来からあるものから、新しいものまで、先輩の知識はメインフレームの職人といったところですね。

先輩 ： 職人ね。もうちょっと、モダンな呼び方はない？　横文字でマスターとか、マイスターとか、マエストロとか。

後輩 ： マエストロは芸術家っぽいですね。それはちょっと…。 ではマイスターで。 いままで伺ったお話を私なりにまとめてみると、最新の Systemｚ プラットフォームを使用

することにより得られる価値というのは、Systemｚ の基盤力によるメリットを享受しながら、そのインフラの上で、最新のビジネス・ニーズに対応するソフトウェアを稼働させられる、ということですね。

先輩 ： そのとおりです。さらに付け加えれば、ＩＢＭの言っている Smarter Computing などの取り組みにも対応できるインフラとして、Systemｚ は類まれなる機能を備えたプラットフォームといえますね。次回以降のセッションでは、主要なミドルウェアごとに、最新の機能から得られる価値についてディスカッションをしていきましょう。

後輩 ： そうですね、マイスター！！　今回のお話を通じて、System z の全般的な価値のイメージは掴めました。これで、ますます、次回以降のセッションが楽しみになってきました。これからもよろしくお願いします。

※ 1. ACID 属性とは、Atomicity, Consistency, Isolation, Durability から合成された頭字語である。これ以上分解してはならないという意味の原子性（Atomicity: 不可分性）、一貫性（Consistency）、独立性（Isolation）、および永続性（Durability）は、トランザクション処理の信頼性を保証するために求められる性質である。もし ACID がなければデータベースの完全な状態は保証されない。

　　（出典：Wikipedia）

※ 2. コンピューティングの経済性 エンジンとしてのメインフレーム（執筆：Howard Rubin 博士） （2.84MB） 　　 http://www.ibm.com/systems/jp/z/library/pdf/rubin_mainframe_economics_201106.pdf

① z/OSの概要【第5章】 z/OS

�2�1

第5章

z/OSz/OS は、System z で稼働する代表的な OS （Operating System）です。OSとは、ハードウェアとアプリケーション・ソフトウェアの仲介役となるソフトウェアで、主な役割は、ハードウェア資源の効率的管理と、アプリケーションからハードウェア資源へのアクセス制御です。z/OS は、System z プラットフォームの最も重要なオペレーティング・システムであり、System z ハードウェアの機能を余すことなく引き出すことができます。今日の z/OS は、1960 年代の S/360 アーキテクチャーを起点とし、数十年間の技術的進歩の結果たどりついたもので、一度に一つのプログラムしか処理できないオペレーティング・システムから、数多くのプログラムやユーザーとの対話を並行処理できるオペレーティング・システムに進化しました。

z/OS は、企業のアプリケーションおよびデータの中心で基幹システムを支えるIBM のメインフレーム上で稼働し、大量のトランザクションやデータの処理に必要な高い信頼性・可用性・拡張性・パフォーマンスを提供します。また、オープン・テクノロジーに対応した機能を提供し、インターネットや Java のアプリケーションなど広範囲で多様な実行環境に対応することができます。すなわち、従来のメインフレーム上で稼働する資産を継承しつつ、既存資産と新しいアプリケーションを統合した基幹システムを実現することが可能になります。

① z/OS の概要は、歴史や機能のほか、オペレーティング・システムがユーザー、プログラム、バッチ・ジョブなどに対して割り当てる仮想アドレス範囲を示す「アドレス空間」のメリットを、システム信頼性向上の観点からわかりやすくお伝えします。また、②役に立つ z/OS 新機能は、z/OS V1R10 以降のリリースで利用可能になった幾つかの新機能を簡単にご紹介します。

1 z/OS の概要

後輩 ： メインフレーム運用の仕事は地味というか、目立たないですよね。エンドユーザーから見たら、OS が z/OS であろうと UNIX であろうと関係ないし。最近流行りの Big Data はDB2がメインだし、SOAはWASが前面にでてくるし、一体 OSって何やってるんですかね。

先輩 ： まあ、確かにね。言っていることは一理あるよ。OS とはハードウェアとアプリケーション・ソフトウェアとの仲介役なので、エンドユーザーには z/OS の凄さというか特長が見えにくいかもしれない。でも、OS に問題が発生するとすべてのアプリケーションに影響を与えるので、非常に重要な中核のソフトウェアであることは間違いないね。逆に、その存在が目立たず、障害を起こすことなく黙々と仕事をしているのが “z/OS の凄さ ” とも言えるんじゃないかな。

後輩 ： それでは、z/OS の概要とか、先輩が言う“z/OS の凄さ ” を教えてもらえますか。歴史とか機能も聞きたいです。

先輩 ： まず、z/OS の概要だけど、z/OS は企業の基幹システムを支える IBM の System z 上で稼働し、大量のトランザクションやデータ処理に必要な高い信頼性・可用性・拡張性・パフォーマンスを提供している OS なんだ。また、我々ユーザーを z/OS 独自の世界に囲い込むようなことはなく、オープン・テクノロジーに対応していて、インターネットや Java のアプリケーションなど広範囲で多様な実行環境に対応している。つまり、従来のメインフレーム上で稼働する資産を継承しながら、新しい技術を取り入れて成長を続けているわけで、まあ “Trendy & Traditional” の同時実現といったところだね。

後輩 ： z/OS は、いつごろ出てきたのですか。先輩が新入社員の頃からありましたか？

先輩 ： 私が新入社員のころは、z/OS という製品名ではなく、MVS と呼んでいたね。MVS はMultiple Virtual Storage の略で、日本語に訳すと『多重仮想記憶』と言えるかな。この MVS によって仮想記憶化がサポートされ、ユーザー、プログラム、バッチ・ジョブなどのタスク毎に固有のアドレス空間を提供することで、処理の多重化ができるようになったんだ。

後輩 ： すみません、ちょっとわからないです。それと、MVS と z/OS の関係がわかりません。

【第5章】 z/OS ① z/OSの概要

�3

① z/OSの概要【第5章】 z/OS

�4

先輩 ： ごめん。そうね、ホテルを例にして言うと、タスクが宿泊客で、部屋がアドレス空間かな。MVS 以前や他の OS では、物理的な記憶装置をうまく分割して使えないため、すべての処理をひとつのアドレス空間で実行します。ホテルというか旅館の大部屋に多くの宿泊客が泊まるようなイメージだね。まるで、私の中学、高校時代の修学旅行みたい。

後輩 ： えっ、そうなんですか。私の中学、高校時代の修学旅行は、ちゃんと一人一部屋でした。

先輩 ： 豊かな時代になったということだけど、まさに、その一人一部屋が MVS の設計思想なのです。各タスクが個別のアドレス空間で稼働するので、仮想記憶の参照など、お互いを干渉することがなく、さらに、ある特定タスクの異常終了が他のタスクに影響を与えないことが MVS の特長です。例えば、私の時代の修学旅行であれば、誰かがいびきをかいたら、同じ部屋の仲間が眠れないということになってしまいます。

後輩 ： 私の時代であれば、一人一部屋なので、隣の部屋の仲間がいびきをかいても、私は熟睡できるということですね。いわゆる “ 部分障害が全体障害につながらない ” ということだと思います。

先輩 ： その通り。1974 年に発表された MVS は、その後、1996 年に OS/390 としてリリースされ、2001 年には 64 ビット・アドレッシングをサポートする z/OS としてリリースされたんだ。z/OS は、MVS の歴史を継承する製品だけど、その関係を簡単に言うと、MVSからOS/390では処理の同時実行可能数が増えました。これは、ホテルの部屋数が増えて、同時に宿泊できる人数が増えたことを意味します。また、OS/390 からz/OS では、一部屋の大きさが体育館並みになったということでしょうか。

後輩 ： ありがとうございます。ホテルの例で、z/OS の概要は理解できました。それでは、z/OSの主要機能としてはどのようなものがありますか？

先輩 ： z/OS の機能は、いくつかのフィーチャーとして提供されているよ。まずは、BCP （Base Control Program）。これは、メモリー記憶域やシステム資源の管理、プログラムのタスク管理など、z/OS の重要で基本的な機能を提供しています。

後輩 ： これはオープン系と変わらないですね。

先輩 ： 確かに、どのプラットフォームでも必ず必要な部分ですね。次は、JES2 （Job Entry Subsystem 2）。私のようにメインフレームを長年担当してきた技術者にとっては当たり前の機能だけど、意外にも、この機能がオープン系の OS には標準でついていないことがわかりました。この JES2 は、バッチ・ジョブの制御を行いますが、同時に多数のジョブを実行したり、ジョブを順番に流したり、あるいは処理しないで貯めておくこともできます。さらには、印刷帳票の入出力制御を行います。他の OS には、こんな機能ありましたか？

後輩 ： はい、オープン系の OS には標準機能としてなかったと思います。確か、別製品で対応しているはずです。でも、機能的には JES2 の方が上ですね。

先輩 ： その他に、 ネットワーク通信機能を提供する Communications Server や z/OS 上で UNIX 標準の Shell コマンドを実行したり、CC++ で作成したプログラムを実行するUNIX System Services （USS）があります。

後輩 ： えっ。z/OS で Shell コマンドですか。

先輩 ： そうだよ。だから最近のメインフレームは “ オープン・メインフレーム ” とも言われています。Java、XML、UNICODE、Web サービスもごく普通に動きますよ。また、データ暗号化機能を提供する Cryptographic Services、システムのリソース保護やアクセス管理を強固に行なうSecurity Server、外部記憶装置のアクセスを行うDFSMS など、OS として企業のシステムを運用するための機能は全て揃っています。

後輩 ： まさに、“ALL in ONE” ですね。このフレーズと、”Trendy & Traditional” がとても印象に残りました。先輩のおかげで、z/OS の概要は理解できたと思います。ありがとうございます！

【第5章】 z/OS

��

【第5章】 z/OS

��

② 役に立つz/OS新機能

2 役に立つ z/OS 新機能

　プロシージャーにおける『入力データセット』のサポート

先輩 ： プロシージャー（JCL PROC）には、大きく2 種類あるのは知っているよね？

後輩 ： はい、カタログ式プロシージャー（PROC）、いわゆるカタプロと、入力（IN-STREAM）プロシージャー（PROC/PEND）があると思います。

先輩 ： その通り。では、君のこれまでの経験で、プロシージャーを使った際に困ったことは何かあったのかな？

後輩 ： 確かにありました。SYSIN DD * ステートメントを含むユーティリティーをカタプロに登録して実行したところ、JCL エラーになってしまいました。エラー・メッセージやマニュアルを調べたのですが、そのような使い方ができない旨、明記されており、製品の制約事項のようでした。

先輩 ： それで、対応はどうしたの？

後輩 ： 代替策としては、 1. 実行時にカタプロをオーバーライドして、SYSIN DD * ステートメントを指定（追加）する、または、2. ユーティリティー制御ステートメントを DASD 上に格納し、SYSIN DD ステートメントで該当データセット名を指定する方法があると思います。私は前者 1. で対応しました。

先輩 ： なるほど、それはよい経験をしたね。以前から、カタログ式プロシージャー（PROC）や入力（IN-STREAM）プロシージャー（PROC/PEND）では、入力ストリーム・データセット（//ddname DD * ステートメント、//ddname DD DATA ステートメント）の指定がサポートされておらず、無理に指定すると、エラー・メッセージ（IEFC601I INVALID JCL STATEMENT）の出力を伴い、JCL ERROR が発生します。

後輩 ： 今ちょうど、z/OS のリリース・アップを計画中ですが、最新レベルでも、この制約は相変わらず同じでしょうか？

先輩 ： いい質問だね。朗報があるよ。実は、先日出席した z/OS の研修で得た情報だが、z/OS V1R13（2011 年 9 月出荷の最新リリース）からは、この制約が大きく緩和されたんだ。

② 役に立つz/OS新機能

後輩 ： どういうことですか？

先輩 ： z/OS V1R13 からは、カタログ式プロシージャー（PROC）や入力（IN-STREAM）プロシージャー（PROC/PEND）において、入力ストリーム・データセット（//ddname DD * ステートメント、//ddname DD DATA ステートメント）の直接指定がようやくサポートされるようになったんだ。この新機能の対象は JES2 サブシステムに限定されるけど、STC、バッチ・ジョブいずれでも利用できるよ。

後輩 ： JES3 サブシシテムでは、z/OS V1R13 でも、まだ従来の制約が残っているのですね。

先輩 ： そう。私も最新のマニュアルを確認したが、JES2/JES3 の記述が明確に区別されているね。あと、この新機能を利用するには、JCL の変換（CONVERTER）処理を z/OS V1R13 のメンバーで行うことが前提というのも大事だね。逆に、ジョブの稼働メンバーは、z/OS V1R12 以下のレベルでも可能になっている。

後輩 ： これは助かります。カタログ式プロシージャー（PROC）や入力（IN-STREAM）プロシージャー（PROC/PEND）と、入力ストリーム・データセット（//ddname DD * ステートメント、//ddname DD DATA ステートメント）が同居できて、分離せずに済むので、煩雑な JCLコーディングから解放されると思います。z/OS のリリース・アップが完了したら、ぜひ利用してみたいと思います。

先輩 ： 新機能の利用例を載せておきますので、参考にしてください。

z/OS V1R10 環境での稼働結果 :

1. 実行 JCL:

//BEANSZZ JOB MSGCLASS=X,NOTIFY=&SYSUID//HELLO PROC //STEPA EXEC PGM=IEBGENER //SYSIN DD DUMMY //SYSPRINT DD SYSOUT=* //SYSUT2 DD SYSOUT=* //SYSUT1 DD DATA HELLO WORLD /* // PEND//GO EXEC HELLO

【第5章】 z/OS

��

【第5章】 z/OS

��

2.JOBLOG(JESMSGLG/JESJCL):

IEFC452I BEANSZZ - JOB NOT RUN - JCL ERROR 3851 //BEANSZZ JOB MSGCLASS=X,NOTIFY=&SYSUID IEFC653I SUBSTITUTION JCL - MSGCLASS=X,NOTIFY=BEANS2 //HELLO PROC //STEPA EXEC PGM=IEBGENER //SYSIN DD DUMMY //SYSPRINT DD SYSOUT=* //SYSUT2 DD SYSOUT=* //SYSUT1 DD DATA // PEND 3 //GO EXEC HELLO 4 ++HELLO PROC 5 ++STEPA EXEC PGM=IEBGENER 6 ++SYSIN DD DUMMY 7 ++SYSPRINT DD SYSOUT=* 8 ++SYSUT2 DD SYSOUT=* 9 ++SYSUT1 DD DATA

3.JOBLOG(JESYSMSG):

STMT NO. MESSAGE 3 IEFC001I PROCEDURE HELLO WAS EXPANDED USING INSTREAM PROCEDURE DEFINITION9 IEFC601I INVALID JCL STATEMENT

z/OS V1R13 環境での稼働結果 :

1. 実行 JCL:

//BEANSZZ JOB CLASS=A,MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID//HELLO PROC //STEPA EXEC PGM=IEBGENER //SYSIN DD DUMMY //SYSPRINT DD SYSOUT=* //SYSUT2 DD SYSOUT=* //SYSUT1 DD DATA HELLO WORLD /* // PEND //GO EXEC HELLO

② 役に立つz/OS新機能

2.JOBLOG(JESJCL):

1 //BEANSZZ JOB CLASS=A,MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID IEFC653I SUBSTITUTION JCL - CLASS=A,MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=BEANS2 //HELLO PROC //STEPA EXEC PGM=IEBGENER //SYSIN DD DUMMY //SYSPRINT DD SYSOUT=* //SYSUT2 DD SYSOUT=* //SYSUT1 DD DATA // PEND 3 //GO EXEC HELLO 4 ++HELLO PROC 5 ++STEPA EXEC PGM=IEBGENER 6 ++SYSIN DD DUMMY 7 ++SYSPRINT DD SYSOUT=* 8 ++SYSUT2 DD SYSOUT=* 9 ++SYSUT1 DD DATA

3.JOBLOG(JESYSMSG/SYSPRINT/SYSUT2):

STMT NO. MESSAGE 3 IEFC001I PROCEDURE HELLO WAS EXPANDED USING INSTREAM PROCEDURE DEFINITIONICH70001I BEANS LAST ACCESS AT 17:29:21 ON FRIDAY, OCTOBER 28, 2011 IEF236I ALLOC. FOR BEANSZZ STEPA GO IEF237I DMY ALLOCATED TO SYSIN IEF237I JES2 ALLOCATED TO SYSPRINT IEF237I JES2 ALLOCATED TO SYSUT2 IEF237I JES2 ALLOCATED TO SYSUT1 IEF142I BEANSZZ STEPA GO - STEP WAS EXECUTED - COND CODE 0000 IEF285I BEANS.BEANSZZ.JOB02625.D0000103.? SYSOUT IEF285I BEANS.BEANSZZ.JOB02625.D0000104.? SYSOUT IEF285I BEANS.BEANSZZ.JOB02625.D0000101.? SYSIN IEF373I STEP/STEPA /START 2011301.1730 IEF032I STEP/STEPA /STOP 2011301.1730 CPU: 0 HR 00 MIN 00.00 SEC SRB: 0 HR 00 MIN 00.00 SEC VIRT: 60K SYS: 252K EXT: 0K SYS: 12168K IEF375I JOB/BEANSZZ /START 2011301.1730 IEF033I JOB/BEANSZZ /STOP 2011301.1730 CPU: 0 HR 00 MIN 00.00 SEC SRB: 0 HR 00 MIN 00.00 SEC 1DATA SET UTILITY - GENERATE -IEB352I WARNING: ONE OR MORE OF THE OUTPUT DCB PARMS COPIED FROM INPUT

PROCESSING ENDED AT EODHELLO WORLD 00090001

② 役に立つz/OS新機能

【第5章】 z/OS

��

【第5章】 z/OS

�0

　バッチ・ジョブにおける『ジョブ完了コード』のサポート

先輩 ： ところで、話は変わるけど、バッチ・ジョブにおける『ジョブ完了コード』には興味あるかい？

後輩 ： えーと、確か、『ジョブ完了コード』とは、実行されたステップの中で最大の戻りコード、または、最後の ABEND コードが代表値として報告されるはずです。

先輩 ： はい、その通り。では、この機能が不便と感じたことはないかい？

後輩 ： あります。実行ジョブにおける特定ステップの戻りコードに着目したい場合、ジョブ・ログの確認がちょっと面倒ですね。もちろん、EXEC ステートメントの COND パラメータと組み合わせることで、特定ステップの戻りコードに応じて処理を進めることはできますが、特定ステップの戻りコードが代表値として『ジョブ完了コード』にセットされると便利だと思います。

先輩 ： それはよかった、朗報があります。z/OS V1R13 からは、バッチ・ジョブ実行時の機能拡張として、『ジョブ完了コード』の制御ができるようになったのです。この新機能を利用することで、ジョブ・ログの吟味から解放され、業務視点でのジョブ成功・失敗が容易に判断できます。

後輩 ： 具体的に教えてください。

先輩 ： z/OS V1R13 では、『ジョブ完了コード』を制御する目的で、JCL JOB ステートメントにて下記のような新規パラメータ（JOBRC）が追加されました。

1. JOBRC=MAXRC： 実行ステップの中で最大の戻りコード、または、最後の ABENDコード

2. JOBRC=LASTRC： 最後に実行した STEP の戻りコード、または、ABEND コード 3. JOBRC=(STEP,stepname[.procstepname])： 該当ステップの戻りコード、または、

ABEND コード

後輩 ： 以前との互換性はどうなっていますか？

先輩 ： さすが、よい質問だね。でも、 その点はご心配なく。z/OS V1R12 までの挙動は、1.JOBRC=MAXRC に該当し、z/OS V1R13 での省略時値も 1.JOBRC=MAXRC なので、ストレート・マイグレーションの観点では問題ありません。

後輩 ： なるほど、この新機能 3. が、私の求めていた機能になりますね。

② 役に立つz/OS新機能

先輩 ： その通り。また、3. の場合、該当ステップが実行されなかった場合は、1.JOBRC=MAXRCの扱いになります。

後輩 ： 変な話ですが、3. で指定されたステップが存在しない場合は、どうなりますか？

先輩 ： おぉ、 鋭い質問だね。その場合は、 エラー・メッセージ（IEFI010I STEPNAME IN JOBRC DOES NOT MATCH ANY STEP IN THE JOB）が出力されて、即座にジョブは終了します。（$HASP396 jobname TERMINATED）

後輩 ： この新機能を利用するには、JCL JOB ステートメントに JOBRC パラメータの明示指定が必須ですか？

先輩 ： いや、JES2PARM JOBCLASS ステートメントにも、下記のような新規パラメータが追加されたので、例えば、（b）JOBRC=LASTRC を明示指定しておけば、JCL JOB ステートメントの JOBRC パラメータ省略時値として利用できます。つまり、JCL JOB ステートメントの JOBRC パラメータは、JES2PARM で設定された省略時値をオーバーライドするわけです。

（a）JOBRC=MAXRC （省略時解釈） （b）JOBRC=LASTRC

後輩 ： この機能を利用する上で、何か注意点はありますか？

先輩 ： z/OS V1R13 では、この新機能を利用する・しないにかかわらず、ジョブ完了時のNOTIFY メッセージ（$HASP165）にて示される『コード（cccc）』が、 常に 4 桁表示されるように変わりました。 例えば、"MAXCC=0" が "MAXCC=0000" となり、"MAXCC=12" が "MAXCC=0012" となりますので、メッセージ自動化処理では影響有無の確認が必要です。

後輩 ： いろいろ聞いてしまいましたが、ありがとうございます。勉強になりました。これは、ぜひ利用してみたい新機能ですね。

先輩 ： 新機能 3.JOBRC=(STEP,stepname[.procstepname]) の利用例を載せておきますので、参考にしてください。

② 役に立つz/OS新機能

【第5章】 z/OS

�1

【第5章】 z/OS

�2

z/OS V1R13 環境での稼働結果 :

1. 実行 JCL:

//XXXXXXX JOB CLASS=A,MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID, // JOBRC=(STEP,TEST.STEP1) or JOBRC=(STEP,TEST.STEP2) //PROC1 PROC //STEP1 EXEC PGM=IEFBR14 //*=====* //*RC=00 //*=====* //SYSPRINT DD SYSOUT=* //STEP2 EXEC PGM=IDCAMS //*=====* //*RC=08 //*=====* //SYSPRINT DD SYSOUT=* //SYSIN DD * DELETE XXXXXXX.TEST1028 /* // PEND //TEST EXEC PROC1 /*

2. 各ステップの実行結果 :

-STEPNAME PROCSTEP RC-TEST STEP1 00-TEST STEP2 08

3.JOBRC=(STEP,TEST.STEP1) パラメータを指定した場合 :

SE '14.01.09 JOB01764 $HASP165 XXXXXXX ENDED AT N1 - JOBRC=0000',LOGON,USER=(XXXXXXX)

4.JOBRC=(STEP,TEST.STEP2) パラメータを指定した場合 :

SE '14.07.18 JOB01766 $HASP165 XXXXXXX ENDED AT N1 - JOBRC=0008',LOGON,USER=(XXXXXXX)

② 役に立つz/OS新機能

＊ z/OS 新機能に関するコラムは、『マイグレーション教授のワンポイント・アドバイス』でも掲載していますので、あわせて参照ください。

② 役に立つz/OS新機能