Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!STAR.STANFORD.EDU!XRJJM%SCINT.SPAN From: XRJJM%SCINT.SPAN@STAR.STANFORD.EDU (John McMahon, STX/COBE (x4333)) Newsgroups: comp.os.vms Subject: CMS 3.0 Conversion Message-ID: <8807080811.AA10882@ucbvax.Berkeley.EDU> Date: 6 Jul 88 17:04:37 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 30 ***> The Release Notes for CMS 3.0 state that is important to verify all CMS ***> 2.x libraries before converting to CMS 3.0. This is because although CMS ***> 3.0 can convert CMS 2.x libraries to the new format, it can only do so ***> to CMS 2.x libraries that have no "structural problems". Thus, any such ***> problem must be both recognized and fixed using CMS 2.x. ***> We were lucky that all of our CMS libraries are ganged in one area, and used only by our configuration management people. We ended up writing a batch procedure that located every CMS library in the directory tree and performing the verify. Since our libraries are all defined similarly (e.g. [ROOTDIR.SOURCE_FILES.FACILITY_NAME.CMS_LIBRARY]) this turned out to be a trivial task. I suspect in your case, all you can do is warn your users. Although you could try to write a procedure that searches devices for CMS libraries. That could get a little wierd though. There is a second "gotcha" in the installation. After you upgrade to 3.0, you are supposed to issue a CONVERT command on the 2.0 libraries. CONVERT doesn't convert the existing library, it creates a new directory (User specified) and writes the 3.0 CMS library there. This also required a smart command procedure and a new directory tree structure. It also requires more than a little extra disk space to perform the conversion. ***> Jon Forrest ***> FORREST@LBL.GOV ***> ucbvax!lbl-csam!ux1!forrest John McMahon xrjjm%scint.span@star.stanford.edu