I've read and re-read the whole thread and I think I see what Edmundo is trying to accomplish and why. The way I see it? He's trying to take the databases down for the shortest amount of time, that five minute goal he mentioned, just to stall the D/Bs (which appear to be MUMPS-based) and bring them back online as soon as possible for transactions to continue processing while catching up the journaled activities. Splitting off a shadowset member allows him to "only" access a fixed and static copy of the database because, otherwise, he'd have to bring it up as a separate instance to use the MUMPS tools for saving either in it's entirety or incrementally. My guess is that this process is necessary because trying to save the databases while active may cause more contention and delay than they can afford.
So what to do with the limitations that are in place? Sorry, Edmundo, but the core question here is going to simply be one of "how much money do you have to spend to fix the problem?" One solution I can envision would be to max out memory on your ES47 and use the OpenVMS RAM disk product and setup a disk large enough to hold your nightly backups, then save them to tape either using Save Set Manager or BACKUP. The main goal being to keep the I/O off your SAN as much as possible. After all, we ARE talking about V7.3-2 and it's limitations... Which begs the question: Why are you stuck at V7.3-2 and are you cutting-edge current on patches?
I'm also curious about your SAN environment. Are your VMS systems the only consumers of your storage on the SAN? Are the disks configured with an optimal cluster factor? Is zoning correctly setup if you're sharing?
For a real hardware solution, which is going to be as elusive as the "OpenVMS FAST switch" some think exists in SYSMAN/SYSGEN, you may have to consider a larger, much more complex system or clustering with more I/O capability, multiple fabrics, dedicated I/O channels for your tape... The unfortunate part is that the solution isn't as simple as buying a set of racing slicks or a bigger engine to shoehorn into your car. Any solution has to consider all your environment, all your requirements and your expected goals. More data would be crucial to providing a solution and the solution has to meet your needs for data recovery. If that isn't the important result then we're doing little more than working our brains for no reason.
Personally, since any solution is going to require purchasing, I'd enlist someone in sales that knows OpenVMS and this sort of complicated problem solving. Where are you located and, in general, in what area of business does your employer address (healthcare, financial, etc)? Then we might have some suggestions about who to ask to do the hard work...
bob
