私が関わった数々のオウンコーディング(2)
By 岡田 - Posted: 2013/09/14 Last updated: 2013/09/17
- 2 Comments
2番目にご説明するのが、データセットスペース打ち切り制御ルーチン(JDJUSPCL)です
このルーチンは以下の状態になった時に呼ばれます
1)データセットを作成する時に、課金情報で管理している恒久データセット個数がグループ予算値を超過した時
2)データセットが増分した時に、課金情報で管理している恒久データセットスペース量の上限値がグループ予算値を超過した時
3)RENAMEコマンドを実行した時
このルーチンは私が最初に改修を依頼されたオウンコーディングなのです。もう27年前の話ですが、鮮明に覚えています
私が依頼された内容は、
RENAMEコマンドでデータセットの名称を変更する時、属性1恒久データセットと属性2恒久データセット間の属性変更だったら、処理を拒否させる
という内容でした
私が担当したシステムでは以下のような対応をしていたために、属性1恒久データセットと属性2恒久データセットは別物として扱う必要がありました
属性1恒久データセット・・・所属グループ名が先頭修飾子に付く、グループデータセット。
グループ予算がある間はどれだけデータセットを作成しても増分を行っても自由である。
但し、データセットスペース量、及び割り当てたデータセットの個数を管理して、各グループに与えている予算値を超過させないようにする
属性2恒久データセット・・・TSSのユーザIDが先頭修飾子に付く、ユーザデータセット。
予算管理をしないため、リソースがある限りデータセットの作成及び増分は自由に行っても構わないが、データセットの保存期間は7日という制限がある。
(データセット作成8日目にはシステムにより自動消去される)
当然ですが、グループデータセットが作成できるリソースとユーザデータセットが作成できるリソースには格差をつけ、グループデータセットのリソースは優遇していました
データセット名を見ると、グループデータセットなのか(属性1恒久データセット)、ユーザデータセット(属性2恒久データセット)を判別する事ができたのです
RENAMEコマンドを実行すると、データセット名称を属性1から属性2または属性2から属性1に変更する事が可能であるが、属性1ではデータセット個数、スペース管理をしているため当該情報に食い違いが発生させないようにシステム側で制限措置を講じる必要があったために作業を依頼された
そして、無事にリリースできました
この時、アセンブラの技術、VOS3システムのオウンコーディングのしくみ、データセットが作成できるリソース管理方法とユーザデータセットの削除方法、TSS上でのTESTコマンドとオウンコーディングを単体テストする際の考慮事項などオウンコーディングやJDJUSPCLに関わるあらゆる技術の習得を行うことができました
私が27年経た現在でも、上記の事が頭の中に記憶として残っているのは多くの技術が私の記憶が喪失するのを引き止めていたからに他なりません
このルーチンは以下の状態になった時に呼ばれます
1)データセットを作成する時に、課金情報で管理している恒久データセット個数がグループ予算値を超過した時
2)データセットが増分した時に、課金情報で管理している恒久データセットスペース量の上限値がグループ予算値を超過した時
3)RENAMEコマンドを実行した時
このルーチンは私が最初に改修を依頼されたオウンコーディングなのです。もう27年前の話ですが、鮮明に覚えています
私が依頼された内容は、
RENAMEコマンドでデータセットの名称を変更する時、属性1恒久データセットと属性2恒久データセット間の属性変更だったら、処理を拒否させる
という内容でした
私が担当したシステムでは以下のような対応をしていたために、属性1恒久データセットと属性2恒久データセットは別物として扱う必要がありました
属性1恒久データセット・・・所属グループ名が先頭修飾子に付く、グループデータセット。
グループ予算がある間はどれだけデータセットを作成しても増分を行っても自由である。
但し、データセットスペース量、及び割り当てたデータセットの個数を管理して、各グループに与えている予算値を超過させないようにする
属性2恒久データセット・・・TSSのユーザIDが先頭修飾子に付く、ユーザデータセット。
予算管理をしないため、リソースがある限りデータセットの作成及び増分は自由に行っても構わないが、データセットの保存期間は7日という制限がある。
(データセット作成8日目にはシステムにより自動消去される)
当然ですが、グループデータセットが作成できるリソースとユーザデータセットが作成できるリソースには格差をつけ、グループデータセットのリソースは優遇していました
データセット名を見ると、グループデータセットなのか(属性1恒久データセット)、ユーザデータセット(属性2恒久データセット)を判別する事ができたのです
RENAMEコマンドを実行すると、データセット名称を属性1から属性2または属性2から属性1に変更する事が可能であるが、属性1ではデータセット個数、スペース管理をしているため当該情報に食い違いが発生させないようにシステム側で制限措置を講じる必要があったために作業を依頼された
そして、無事にリリースできました
この時、アセンブラの技術、VOS3システムのオウンコーディングのしくみ、データセットが作成できるリソース管理方法とユーザデータセットの削除方法、TSS上でのTESTコマンドとオウンコーディングを単体テストする際の考慮事項などオウンコーディングやJDJUSPCLに関わるあらゆる技術の習得を行うことができました
私が27年経た現在でも、上記の事が頭の中に記憶として残っているのは多くの技術が私の記憶が喪失するのを引き止めていたからに他なりません
Posted in 日立VOS3:オウンコーディングによるシステムのカスタマイズ • • Top Of Page
2 Responses to “私が関わった数々のオウンコーディング(2)”
Comment from okada
Time 2013年9月15日 at 19:34
野良猫さん
コメントありがとうございます
27年に渡ってオウンコーディングの作成、改修の作業を請け負ってきましたが、最後に関わったのは実に10年以上も前の事です
オウンコーディングを作ると管理、改修できる要員が居ないため継続した管理ができない事やサイト側がOSの一部にメスを入れるという事もあり、自分たちに必要な内容であっても改修をしないでサイトで吸収しようと無理をしている所がほとんどです。
結局、その無理もユーザの末端まで届いておらず、システムに関わるベンダーに歪が生じています
データベースコンピュータがメインフレームシステムの殆どの領域を占めてしまったがために挑戦する意欲を失っている事に、とても悲しい思いをしています
また、色々な記事を投稿致しますので、またコメントお願いします
コメントありがとうございます
27年に渡ってオウンコーディングの作成、改修の作業を請け負ってきましたが、最後に関わったのは実に10年以上も前の事です
オウンコーディングを作ると管理、改修できる要員が居ないため継続した管理ができない事やサイト側がOSの一部にメスを入れるという事もあり、自分たちに必要な内容であっても改修をしないでサイトで吸収しようと無理をしている所がほとんどです。
結局、その無理もユーザの末端まで届いておらず、システムに関わるベンダーに歪が生じています
データベースコンピュータがメインフレームシステムの殆どの領域を占めてしまったがために挑戦する意欲を失っている事に、とても悲しい思いをしています
また、色々な記事を投稿致しますので、またコメントお願いします
Comment from 野良猫
Time 2013年9月15日 at 18:11
OS本体で、できている事を再度出口でチェック、回避をしたりするのは、OSの仕様をあまり理解していない証拠だと自分は思っています。(パラメータ等で制御ができるのですから)