-- snip -- My storage admin guy is having a problem that he thinks started when we went to z/OS 1.4.
We use FDR Upstream to back up certain workstations and servers to mainframe DASD. We use the same SMS data class for all of them. It allows for up to 59 volumes to be used for each backup data set. Apparently, Upstream determines internally what size to use for primary allocations, and uses 64010 tracks for this data class. Since going to z/OS 1.4, any backup requiring more that 5 volumes fails with an S837-08. Looking at the catalog entries for backups built using this data class, any of the backup data sets that actually require only a single primary have unused catalog slots for 59 volumes, just like I would expect. Any that required a second volume to be allocated, revert to only 5 such slots. Hence, we can't back up anything that requires more than 5 X 64010 tracks. I'm sure there's something at work here that we're not aware of. Can anyone point me in the right direction? -- snip -- If the allocation is using the same method (eg. Dataclas, no volume count override), then I would be suprised if it was SMS. It really looks like the larger allocation specifies a volume count of 5 and overrides the Dataclas definition. Try allocating the dataset using a batch job and a utility like IEBGENER. Confirm that small and large allocations work as you expect. Having said all that, there were some changes in the z/OS 1.4 time frame. Dynamic volume count was introduced. It is an elegant way of allowing multivolume datasets to dynamically obtain more volumes when extending, without having to predefine the entries in the catalog. The relevant Dataclas fields are Dynvol count and Space constraint relief. John ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
