From:	CSBVAX::MRGATE!@KL.SRI.Com:info-vax-request@kl.sri.com@SMTP 25-AUG-1987 01:31
To:	EVERHART
Subj:	Comments on volume shadowing...

Received: from ucbvax.Berkeley.EDU by KL.SRI.COM with TCP; Mon 24 Aug 87 19:19:18-PDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
	id AA10856; Mon, 24 Aug 87 19:02:29 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for info-vax@kl.sri.com (info-vax@kl.sri.com)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 24 Aug 87 14:05:47 GMT
From: clyde!watmath!utgpu!bwp@RUTGERS.EDU  (Bruce Pinn)
Organization: University of Toronto Computing Services
Subject: Comments on volume shadowing...
Message-Id: <1987Aug24.100547.3168@gpu.utcs.toronto.edu>
Sender: info-vax-request@kl.sri.com
To: info-vax@kl.sri.com


I'd like to add a couple of comments to the recent volume shadowing
discussion.

Paul Clayton in a recent message said that dismounting a disk from a shadow
set will leave open ISAM (and possibly other types of) files in an inconsistent
state. In general, that is the case. With careful application design this
problem can be avoided. A combination of:
	- not using the RMS "deferred write" option
	- waiting for active writes to complete
	- allowing no further writes to be initiated
	- allowing all non-atomic transactions be completed and allowing
	  no new non-atomic transactions to begin
will leave a prolog 3 ISAM file consistent on disk (with the file still open
for writes) both from an RMS and application viewpoint. 

Synchronizing this disk quiescense can be accomplished fairly easily through
the use of a cluster-wide lock held CR with a blocking AST by all writers. If a
process tries to raise CR to EX then all the writers will get the AST which can
indicate to them that the database is to be quiesced. The writers indicate that
they have quiesced by giving up the CR lock they hold. When the process that
requested the EX lock gets it, the shadow set is ok to be split up. The writers
should requeue for the lock CR so that they can tell when to proceed with more
writes. The holder of the EX lock should give it up when the dismount has
completed. 

People considering using the RMS Common Journalling Facility (CJF) should be
aware that under some circumstances CJF will turn on deferred writes to user
data files even though this option is not explicitly used by the application
code. This "feature" of the CJF, at least in its initial release, will not be
avoidable. 

	Corot Reason, PROMIS Systems Corp., Toronto
	(416) 364-5361x428