Wondering if anyone has attempted removing 'candidate' volumes (* ones only) from a VSAM component that is allocated and open to a CICS region? Can't find anything definitive using googlies or IDCAMS/Managing catalogs manuals to say it can't be done, or any warnings.
I think it should be harmless as they're only markers in its catalog entry. The only issue I can think of is if all candidates were removed and the dataset needed to extend. But the Dataclas DYNVOL should kick in and add further candidates if necessary. I think that should happen both before or after the dataset has been closed and reopened to CICS and the candidates were removed.
Pete, I was reading one of the blog and here is what I have got and may this be of your help. Please ignore it if you knew this already.
Lets say the file is in a pool with x number of candidate volumes, and the system has already allocated extents in all the volumes and it needs a new extent. Even if space has become available in one of those volumes (another dataset was deleted, moved, whatever), SMS will not go back and search again for space in the volumes where in previous extents it failed to allocate space. We run into this problem with a large VSAM file and had to call IBM for assistance because I could not understand why I could not allocate 500 cylinders when I had over 2,000 available. We are running OS/390 2.8. I don't know if this "design feature" has been improved upon on later releases.
The problem is exactly what the message said. Your VSAM file is out of space on the current volume. If the data set is SMS managed, you can simply execute IDCAMS to put in another candidate volume.
ALTER ESD.DPM.DPDDFIL.VS.DATA ADDVOL(*)
If the data set is not SMS managed, you must replace the * in the above
command with an actual volser which has sufficient space (primary
allocation).
There is one other thing. If this data set does not have "extended
addressing" and the attempt to expand onto another volume would result in the data set exceeding the 4gig barrier, the data set will not expand. In
this case, you would likely need to make the data set "extended" and do an unload/delete/define/reload to fix this problem.
Thanks Rohit, but my concern is primarily about removing candidate volumes from an active, open dataset allocated to CICS, in case there may be some in-storage control block that retains knowledge of the candidates that were there, and might cause and issue if the file needs to extend. These are files used by many CICS regions and batch processes 24x7, hence the extra caution being applied.
Are you sure you're on OS390 still?! Is it a computer museum you work at?
Re your VSAM space issue, that could be due to fragmentation of your DASD which a compaktor or defrag could help, or make your allocation a bit smaller to fit within the available space, or add more capacity. Also your SMS Dinterval time might need changing to force it check space info in the pools more frequently.
