|
[ Intro | Pubs | RunInfo | Workbook | Software | SLACVX | Search ] |
DUCS archive copies are maintained at some, but not all, DUCS hosts. The selected list of hosts is specified at the top of the ducs_arch command file. The specified hosts should be those to which the DUCS and archive disks are physically connected. This avoids unnecessary network traffic within a cluster (a full copy of DUCS measures roughly 0.5 GB). If the disks are moved to different hosts within their cluster, the host list should be updated accordingly.
For each host, one or two models may be specified. This model specification is the model, alpha or vax, of code that is to be maintained by the specified host. This is not necessarily the same as the model of the host. Thus at SLAC, the host SLDA6 maintains code for both alpha and vax systems. At VU, the host VUPACB maintains code only for alpha systems.
The DUCS accounts on each of the hosts must have their .rhosts files set up correctly to allow remote shell logins from the DUCS account on the SLAC central unix VESTA machines. Specifically, the .rhosts files must contain the following lines:
vesta01.slac.stanford.edu ducs
vesta02.slac.stanford.edu ducs
vesta03.slac.stanford.edu ducs
vesta04.slac.stanford.edu ducs
vesta05.slac.stanford.edu ducs
vesta06.slac.stanford.edu ducs
Each of the hosts must have disk space for the archives located under the logical name disk$sld_arc_axp for alpha code or disk$sld_arc_vax for vax code. The archive disk should allow 2.5 GB for the entire alpha code archives and 1.5 GB for the entire vax code archives. This requirement allows the system to maintain the same set of archive copies at all hosts. The system will refuse to perform copies at any hosts if it does not measure sufficient available disk space at all hosts.
Test mode has been designed to thoroughly test all critical components of the archive system. It exercises all remote shell login permissions and all database access. In addition to testing the archive system, it can be useful for comparing the current DUCS at various hosts.
To compare current ducs, use the command: ducs_arch full test
The Oracle connection is obtained through Len Moss's system, Orsess. Connect permission is granted because the unix DUCS account has afs permission to read the password file for the unix Oracle SLD account.
The actual work of measuring, copying, restoring and deleting files is performed by remote shell logins to the DUCS hosts. These logins pass a variety of parameters to the vms command file produtil:ducs_arch.com.
By centralizing many functions into this one command file, the system can achieve consistency in what files are excluded from measuring and copying actions. Examples of excluded files are the log files that DUCS maintains of its update activity. To change this list of what files are excluded from these actions, edit produtil:ducs_arch.com.
The DUCS accounts on each of the hosts must have their .rhosts files set up correctly to allow remote shell logins from the DUCS account on the SLAC central unix VESTA machines as discussed above.
Any version number lower than 13.0 was saved under the old DUCS archive system. Under this old system, all versions, major and minor, were actually full DUCS copies. Thus, for example, versions 11.5 and 12.1 are actually full versions. They do not require any corresponding major versions 11.0 or 12.0. Indeed, the old system has no versions with minor version number zero.
The ducs version command handles these old versions seamlessly for the user. It assumes that any version before 13.0 is from the old system.
Restoring very old versions must be done using the older system outlined in the documents The Practical Guide to Version Management and VERS_MAN: Tracking Code Version Releases. To simplify the transition, the four versions from just before the new system came on line, versions 11.5, 11.6, 12.1 and 12.2 have been stored to tape under both systems. They can therefore be restored using the new system.