WTORルーチンがABENDS0C4?

By 神居 - Posted: 2009/11/11 Last updated: 2009/11/11 - Leave a Comment
印刷用ページの表示 印刷用ページの表示

WTOR(Write To Operator with Reply)、S0C4?

WTORだけでなく、S0C4も一緒に指定されているので、WTORマクロ(SVC)を出すと、それがS0C4でABENDする、と言うことを調べようとしていたのかも知れません。z/OS(MSP、VOS3)のAPIの固有名称が検索キーワードに使われるのはそう多くないのですが、WTORとS0C4の組み合わせで検索されていた(それも何度も)のが印象に残っていたので、WTORについて知りたい、ではなく、それがABENDする、と言う視点で考えてみます。もうとっくに解決されてるでしょうから今さらではありますが...

WTORは、コンソールにメッセージを出して、その返答を受け取るためのOSマクロ(API)です。返答を返す際に使用されるのがR[eply]コマンドです。プログラムがコンソール・オペレーターの判断を仰ぎ、その判断によって処理を変えるような場合に利用されます。WTORマクロの使い方は、こちらのページを見て下さい。オペレーター応答とコマンドを受け取る(WTORとQEDIT)


WTORサービスがABENDする理由

パラメーターの指定を間違えても、アセンブルエラーになるか、戻りコードでエラーになるか、あるいはSD23でABENDするかです。ストレージ不足やシステム・リソース不足でWTO/WTORがエラーやABENDすることもあるけど、S0C4は普通ないです。考えられるとすれば、ECBやリプライの返答域のアドレスが誤っている場合。存在しないアドレスや書き込みできない領域(例えば0番地とか)などを指定すると起きそうに思えます。

リプライの返答領域アドレスとして、存在しない仮想アドレスを指定してWTORを出してみます。(x8000番地が存在しないかどうかはプログラムによって異なります)
リプライの返答領域アドレスではなく、ECBアドレスでもかまいません。例えばECBアドレスとして0を指定します。

間違いなくABENDします。ただしABENDコードはE23、メッセージ・マニュアルにも載ってますが、WTORの処理中にECBや返答領域(仮想記憶域)のアドレスが誤っていると、このコードでABENDします。
※ABENDはWTORマクロの発行中ではなく、WTORから戻ってきてWAIT中に起こります。コンソールからリプライコマンドでリプライデータを応答した後、WTOR処理ルーチンの延長でABENDとなります。

ABENDはしますが、S0C4ではありません。どのような場合にS0C4が起きるのでしょうか?コードから考えると、メモリーアドレスを間違えているからに思えますが、単純に間違ったアドレスを指定してみても、ABENDコードはSE23となります。



少し変更を加えてみます。WTORを発行する前に、プログラムを監視プログラムモードに変更します。
※単にMODESETマクロを追加してもS047でABENDするだけなので、バインダー(LKED)のパラメーターにAC=1を追加し、APF許可されているライブラリーにモジュールを登録します。

今度はE23ではなく、S0C4でABENDするはずです。同時にOSのダンプデータセットにSVCダンプが出力されます。

プログラムとしては同じエラーであるのに、完了の仕方が変わります。MVS(z/OS)のAPIにはこのような動きをするものが多くあります。ABENDした際の内部リカバリー処理で、SVCの呼び出し元の走行モード(PROBなのかSUPなのか)を判定し、異なる対応や処理が行われることはよくあります。ここからはOSのソースコードを見られるわけではないので、筆者の考えに基づく記述になりますが、このケースでは、呼び出し元がPROBモードであれば単にユーザープログラムのミスとして、それを示すE23のABENDコードで異常終了し直し、SUPモードであれば、呼び出し元がOSあるいはシステム・プログラムにも関わらず、内部に重大なロジックエラーがある可能性が高いので、原因を追及するための診断資料となるSVCダンプを出力し、元のコードでパーコレート(ABENDの継続)する、と言ったようにリカバリーロジックが作られているのでしょう。
他にもAPIによっては、呼び出し側がPROBモードまたはユーザーキー(8以上のPSWKEY)であれば、指定したパラメーターの形式や、アドレスなどを処理する前に、実際に存在する仮想領域なのか、ユーザープログラムのキーで書き込みできるのか、などの妥当性検査(validation check)を行うが、SUPモードの場合は、それを迂回する、と言うものもあります。例えばEXCP SVCなどがあります。EXCP SVCは呼び出し元が7以下のキーであれば、DEBの妥当性検査を迂回します。これを応用し、データセットをOPENせずにチャネルプログラムで直接アクセスしたり、DASDボリュームの任意のトラック/レコードを読み書きする、と言ったことを行っているシステムプログラムは多く存在します。

入力パラメーターの妥当性検査などは、APIの本質ではなく、むしろ余計なことです。効率面で、監視プログラムモードで動くなら、間違う方が例外である、とデザインされるのはおかしなことではありません。1つ1つは小さくても繰り返し行われる処理では、パフォーマンス面でも無視できません。しかしユーザーが作るプログラムに対しては、そのような高水準を前提にすることはできないので、CPUを余計に使っても、OS内でエラーを起こさぬように入力パラメーターが本当に正しいかを確認するのも、OSとして当然です。MVSではその判断基準に呼び出し元が、監視プログラムモードなのか問題プログラムモードなのか、あるいはPSWキーが8未満か以上か、がよく利用されています。

自分が発行したマクロ(SVC)や呼び出したOSのサービスが、マニュアルに記載されていないコードでABENDするような場合でも、その原因の99.99%は作ったあなたにあります。もしSUPモードやキー0のままサービス呼び出しているなら、その時だけでも、PROBモード、キー8にして同じパラメーターで呼び出してみるのも、デバッグ手法の1つです。ただしその前に、呼び出しの直前で、ABENDさせるなりして、呼び出しパラメーターおよび呼び出し環境(アドレスモード、ASCモード、SUP/PROB、PSWキー、APF許可、ロックの有無などなど)に「絶対間違いがない」ことを確認してみて下さい。99.99%はそこでバグを発見します。
基本的にAPIはエラーになったぐらいで、0CxでABENDしたり、いちいちSVCダンプを吐いたりしません。もしOSの中でABENDした場合、慌てずに自分がOSと同じモードで動いていないかを思い出してみて下さい。特にOSの出口ルーチンなどでは、自分が意識しなくても(自らMODESETなどを使わなくとも)、OSの処理の延長で呼び出されたりすることも多いので、キー0であったり、SUPモードであったりはよくあることです。

Posted in キーワードから(何が知りたいですか) • • Top Of Page