はじめに

お疲れさまです、みやもとです。

前回記事については思いのほかたくさん見ていただけたようで嬉しい限りです。
ありがとうございます。
読んでくださった方から「懐かしい」とご反応いただいたのが嬉しかったので、もうちょっとだけ汎用機開発の頃の思い出話、汎用機開発経験者の多くがよく目にしたであろうアベンドコードに関する話を記事にしたいと思います。

今後はなるべく現在勉強中のことに関連する話題で書くつもりです。

今回の記事も前回と同様、
・z/OS（IBMメインフレーム）
・IBM　DB2
の開発に携わっていた頃の経験談となります。

今回も私が汎用機システム開発に携わっていた頃の記憶に基づく話です。
時代の流れや開発環境の違い、私の記憶違い等で記載の内容が現在と異なる場合があります。

アベンドコードとは？

まずは「アベンド」、および「アベンドコード」についてさらっと。

プログラム上に設定された本来の終端箇所とは異なる位置で突然終了することを指す。プログラムの誤り（バグ）や想定外のデータの入力、ハードウェアの障害などによって続行不能に陥ったり、何らかの異常な振る舞いによりOSなどにより強制的に終了させられたりすることにより発生する。異常の種類や内容を知らせる識別番号が出力される場合もあり、これを「アベンドコード」（ABEND code）という。
IT用語辞典 e-words 「アベンド」より引用

汎用機でなくとも、バッチ処理開発の経験がある方であれば馴染みがあるのではないでしょうか。
あんまり馴染みがない方がいいと言われればその通りですが、プログラミングを続けていれば望まずともバグが出るように、毎日毎月実行されるJOBがひとつとしてアベンドしないなんてまずないのです。
かつて居たとある現場ではバッチ処理のほとんどが夜間に実行されており、アベンドが発生すると即刻運用センターから電話がかかってきて寝ぼけ眼で対応したものでした。
遭遇率の高い低いはあれど、一度も電話がかかってこなかった人はいなかったと思います。

夜中に突然鳴り響くカルメンの前奏曲¹でたたき起こされた思い出はさておき。

本番処理に限らずとも、開発環境でテスト実行時に異常終了するのはよくあること。
今回はそんなアベンドコードを眺めて、見覚えのあるものについていくつか書いていきたいと思います。

S0C7：データ例外

COBOLで定義した項目のデータ型と実際の項目値のデータ型が異なる場合に発生する例外です。
まだ初々しい新人時代に遭遇してわりとインパクトがあったので、これだけははっきり覚えていました。

■原因
大抵は数値型で定義した項目に数値じゃない値が入ってきたことで起こります。
インプットにたまたま手入力で追加したデータが間違ってたとか、システム間連携で定義内容が食い違ってて想定外の値が入ってきたとか。
また、私は実際に遭遇したことはありませんが、数値型でもパック10進数とゾーン10進数だったり、数値の桁数が定義と実際のデータで違っていたりしても発生するかと。

■対応
大部分はデータパッチ（原因となるインプットデータを一旦除外するか、該当項目を正しいデータ型になるよう修正）して再実行します。
どの項目が原因なのか突き止めるまでがちょっと大変。
数値項目が少ない場合は項目名とアベンドしたプログラムのソースを見比べてある程度見当をつけられるのですが、多い場合はプログラムのコンパイルリストを引っぱり出し、エラーログのオフセットを手がかりに16進数のアドレス計算にいそしむことになります。
このへん詳しく書ければいいのですが、ここ何年か画面見てなくて記憶があんまりにもおぼろげなのと、さすがにエラーログ出力イメージとかCOBOLコンパイルリストイメージとかは作れないので割愛させていただきます。

S813：ファイルOPENエラー

新規に作成するJCLのテストとか、データパッチその他本番で単発実行するJCLでたまに見かけました。
前者はともかく後者は大変心臓に悪く、うっかりやらかすとめちゃくちゃ頭を抱えたものです。

■原因
JCLの記述誤りです。単純なデータセット名の記述誤りだったり、あとは磁気テープのボリューム指定誤りもこれだったと思います。
本番だと使いたい磁気テープをずっとマウントしているわけではないので大抵の現場では処理前に「このテープ出して」と依頼する必要があり、伝達ミスや依頼の受領タイミングによりテープがマウントされるより先にJOBが実行されてしまって……というのもたまにありました。²

■対応
JCLを修正して再実行します。
データセット名の間違いなら書き直しだけですが、ボリューム指定誤りの場合だと先述のテープの準備があるので正しいボリュームで依頼し直す必要があってちょっと面倒でした。
間違えたのが悪いので偉そうに言えたことではないですが。

S222：オペレータキャンセル

開発環境・本番環境問わず、個人的にはだいぶ心臓に悪いアベンドコードです。

■原因
実行したJOBが何らかの理由によりオペレータにキャンセルされた場合のエラーコードです。
この「何らかの理由」がわからないというのが結構怖い。
「ちょっと今混んでるから重そうなJOBいくつかキャンセルしてます、後でやり直して」みたいな場合はいいのですが、JCLの記述でやばい間違いがあって……という可能性も無くはないので連絡がくるまでひたすら祈りました。

■対応
オペレータさんの連絡に応じてJCLを修正したり、時間を見計らって再実行します。

S806：実行モジュールなし

本番ではまず見かけなかったアベンドコード、というより本番で見かけたらやばいと思うアベンドコードです。³

■原因
JCLで指定したプログラムが使用しているライブラリに存在しないというエラーです。
新規プログラムのテスト用に作ったJCLとかでよく発生しました。
また、社内共通のユーティリティをチームごとにカスタマイズしてプログラムIDを変えたりしている現場だと、チームを移った途端に今まで使えたプログラムIDでエラーが発生……とかもありました。

■対応
プログラムIDを修正するかライブラリ指定を追加してJCLを再実行します。

SB37：ファイル拡張エラー

本番・開発環境問わずちょくちょく見たコードです。
不可抗力みたいなこともあるので、個人的には諦めがつくコードでもありました。

■原因
JCLで指定したファイルの増分量を使い果たしてまだ出力データがある場合に発生します。
本番で見かけるのは急激に処理データ量が増えたことによるアベンドがほとんど。
前回記事で書いた容量計算に絡んだ部分でもあるので、ちょっと詳しく書きたいと思います。

SPACE指定の赤枠部分を「一次増分量」、青枠部分を「二次増分量」と言います。
詳しい説明はここをご参照いただきたい。
かなりざっくり説明すると処理開始時、アウトプットファイルの書き込み領域としてまず確保されるのが一次増分量。
処理を行い、一次増分量を使い切ってなお処理が終わらない場合に追加で確保されるのが二次増分量です。
この二次増分量は決まった回数まで繰り返されるのですが、これを最大回数実行してもまだ出力がある場合にこのアベンドコードが発生するわけです。

記憶が曖昧なのですが、一次増分量に指定した容量を連続して確保できない場合のアベンドもこのコードだったかも？
ボリューム全体の空き容量はあるのに何故……？と思っていたら連続空き容量がほとんど無くて、というちょっと珍しいパターンでした。

■対応
だいたいはJCLのスペース指定を増やして再実行します。
ただし先述の一次増分量を連続で確保できない場合のみ、一次増分量の部分を連続で確保できる最大空き容量より小さく、その分二次増分量を大きくして再実行しました。
二次増分量は大きくしても実行できたというのが今でもわりと不思議なのですが、一次とは違って連続していなくても大丈夫ということでしょうかね？

参考

この記事を書くにあたって、以下サイトを参照しました。

まず、一覧を眺めて「こんなん見た気がする」と記憶の掘り起こしに使ったサイト。

そして詳細を思い出すのにあれこれつついたサイト

所属Organizationのお知らせ

所属OrganizationであるTECH WOMAN KANSAIは関西女性エンジニア限定コミュニティです。
オンラインもくもく会やオフラインイベント等で違う分野のエンジニアともお話できたりするので、ご興味ある関西在住の女性エンジニアは是非！

絶対に起きなければいけない電話なのでなるべくインパクトのある着信音を選んだ結果。 ↩
この場合は指定ボリュームがマウントされてないよ、ってことで別のアベンドコードだったかも。 ↩
本番アベンドはどれもやばい、と言われればそれはまあそう。 ↩