TO:	Brian Beiers					Thu Mar 02 1995

From:	Neal Rhodes

Subject: Multiple SMGR systems

Thanks for the call today.  I understand you want to keep track of both changes
done in Miami and in California.   And you want to avoid both coasts working on
the same bug report.  There are a couple of developers involved, and the only
interconnnection now is via async dialup on demand.    I think you could 
coerce SMGR into helping as follows:

Choices we discussed:

1. CALLING CALIFORNIA FROM MIAMI WHENEVER YOU WANT TO CHECK OUT A FILE.  Yuck. 
This really means calling whenever you even want to review the history on a 
file,  or compare two versions, or whatever.   I don't think that will be too
pleasant for long. 

2. MAINTAIN TWO ROUGHLY SYNCHRONIZED SMGR SYSTEMS.  Two different SMGR systems
could maintain a semblance of coordination as follows:

	a. After Checkout (trafchko.i)
		- Send Email to developers on other system notifying them of
		category, file and issue number.

		- Initiate uux job to create psuedo lock file on other system.
		Receiving end of uux job could cross-check that the file hasn't
		also been checked out there in the interim.

	b. Before Checkout (trb4chko.i)
		- Check for existence of psuedo-lock file, and inform developer
		that file is inuse at other site. 

	c. After Checkin (trafchki.i)
		- Send Sccs master file to other site via uux job.  Receiving
		end of uux job will place new file in specified queue 
		directory.
	
	d. Perodically - Run a Progress job to display revision files from 
	the other system, allow them to be copied to the local SMGR data 
	directory, then run "resetrev.p" to update the local system. 

This would provide a fairly well coordinated duplication of SMGR data between 
the two systems, with collisions detected for manual coordination.