印刷用ページの表示

２番目にご説明するのが、データセットスペース打ち切り制御ルーチン（ＪＤＪＵＳＰＣＬ）です

このルーチンは以下の状態になった時に呼ばれます
１）データセットを作成する時に、課金情報で管理している恒久データセット個数がグループ予算値を超過した時
２）データセットが増分した時に、課金情報で管理している恒久データセットスペース量の上限値がグループ予算値を超過した時
３）ＲＥＮＡＭＥコマンドを実行した時

このルーチンは私が最初に改修を依頼されたオウンコーディングなのです。もう２７年前の話ですが、鮮明に覚えています

私が依頼された内容は、
ＲＥＮＡＭＥコマンドでデータセットの名称を変更する時、属性１恒久データセットと属性２恒久データセット間の属性変更だったら、処理を拒否させる

という内容でした

私が担当したシステムでは以下のような対応をしていたために、属性１恒久データセットと属性２恒久データセットは別物として扱う必要がありました

属性１恒久データセット・・・所属グループ名が先頭修飾子に付く、グループデータセット。
　　グループ予算がある間はどれだけデータセットを作成しても増分を行っても自由である。
　　但し、データセットスペース量、及び割り当てたデータセットの個数を管理して、各グループに与えている予算値を超過させないようにする

属性２恒久データセット・・・ＴＳＳのユーザＩＤが先頭修飾子に付く、ユーザデータセット。
　　予算管理をしないため、リソースがある限りデータセットの作成及び増分は自由に行っても構わないが、データセットの保存期間は７日という制限がある。
　　（データセット作成８日目にはシステムにより自動消去される）

当然ですが、グループデータセットが作成できるリソースとユーザデータセットが作成できるリソースには格差をつけ、グループデータセットのリソースは優遇していました

データセット名を見ると、グループデータセットなのか（属性１恒久データセット）、ユーザデータセット（属性２恒久データセット）を判別する事ができたのです

ＲＥＮＡＭＥコマンドを実行すると、データセット名称を属性１から属性２または属性２から属性１に変更する事が可能であるが、属性１ではデータセット個数、スペース管理をしているため当該情報に食い違いが発生させないようにシステム側で制限措置を講じる必要があったために作業を依頼された

そして、無事にリリースできました

この時、アセンブラの技術、ＶＯＳ３システムのオウンコーディングのしくみ、データセットが作成できるリソース管理方法とユーザデータセットの削除方法、ＴＳＳ上でのＴＥＳＴコマンドとオウンコーディングを単体テストする際の考慮事項などオウンコーディングやＪＤＪＵＳＰＣＬに関わるあらゆる技術の習得を行うことができました


私が２７年経た現在でも、上記の事が頭の中に記憶として残っているのは多くの技術が私の記憶が喪失するのを引き止めていたからに他なりません