Storage Set exit?

[geoffwilde]

In version 2, you could monitor the "storage sets" to change the collection name when an OAM group was either full, or going very close to full. V7 doesn't offer an equivalent. Anyone figure out how to do this?

[Justin Derrick]

In the multiplatforms world, you add more cache filesystems, or assign additional storage inside TSM.  In TSM, this can mean adding volumes to a storagepool, or adding a new one and configuring it in TSM's hierarchy.

[leodejong]

I don't think there is an exit in V7 to handle this. I have considered this exit in past for this purpose.
But we have converted the OAM 32K tables to LARGE partitioned tablespaces with a DSSIZE of 64G and up to 128 partitions.
In this set up we don't expect to hit any full condition in any foreseeable future.
But we do monitor size of the different groups from time to time (monthly) and change collection-names if size makes the image-copy time excessive. If you want details sent me an email. (see profile)
Leo

[geoffwilde]

We can add more nodes, but it's the automated switching between them that I'm after.

[Bill Dennis]

I have used the ARSUUPDZ exit to assign Storage Set Node based on the input. This spreads the work among nodes rather than monitor for a near full condition.

[geoffwilde]

Can you be more specific?

[Bill Dennis]

On our z/OS server, we had an external table with Storage Node names (and other info) to be used for various reports.  The Names processing call in ARSUUPDZ could update the name that would be used.  We also assigned the AG and APP from the table.

[LWagner]

IBM is setting up a table, ODSCRT, that is an application/applicationgroup/storage node cross reference.  We have a rotation across 4 OAM databases in one instance, and 3 OAM databases in the other.  We have multiple versions of each report, and in V2, change the active version depending where we want to write.  When a database's contents has all gone out to tape, we re-org it in place down to one volume, then set the version that writes to it as current. With one set, that is yearly.  With another it is about every 13 weeks.  This keeps our space under control.

In version 8, we'll need to update the ODSCRT table to identify which is the active version.  Ask IBM about the implementation of this table with CMOD 7.1/8.4. They have a patch to ARSLOAD so that it checks this table to determine which node to write to for a given application group and application combination.

 I hope to have some jobs that monitor the row count in the pertinent OAM tables, and auto-update ODSCRT as appropriate, but we'll be creating them ourselves.  Since we are already doing this, IBM has to take it into account as part of our migration scenario.