Release Project Leader Menu (PLMENU)

DIGITAL CONFIDENTIAL


Previous Contents


Chapter 10
Comparing Two CMS Classes

It is often useful to compare the contents of two streams (CMS Classes). For instance, you may need to identify which modules have changed between one stable build stream and a subsequent unstable build stream. You can use the compare CMS class option of the menu to compare two CMS classes for one or more facilities (CMS libraries). The utility allows you to submit multiple batch jobs to produce reports of class differences.

The VDE database stream generations are not compared by this option. If you want to compare the VDE generations you can use the VDE SHOW GENERATION command with the /IF_DIFFERENT qualifier. See the "VDE Reference Manual" for a description of the SHOW GENERATION command. The Compare CMS class utility and the VDE command should give you the same result. If the VDE difference is not the same as the output produced by this option, then you have uncovered a difference between VDE and CMS for one or both of the streams.

Required Privileges

You need the process rights identifiers VMS_ENABLE_CMS and (VMS_SOURCE_READ or VMS_SOURCE).

10.1 Invoking the Compare Class Option

To compare two CMS classes, select option nine from the main menu. The compare class command procedure executes.


 What action do you want to perform? (1-6,EXIT,HELP): 9 
 
Difference Stream Version X-1 
 
Enter ? or "HELP" at any prompt to obtain help 
Prompt default values (if any) appear in brackets [] 
Enter <Ctrl>Z, "Quit" or "Exit" to exit immediately 
 
 Product Root [VMS$]: VMS 

Enter the product root. See Chapter 2 for a definition of product root.

You are asked to supply one of the streams to compare. There is no validation performed on the entered stream.


 First Stream [V5.5]: V5.5 

Enter the second stream to for the comparison. No validation is performed.


 Second Stream [V5.5_BUILD]: V5.5_BUILD 

Enter the batch queue in which to run the difference jobs.


 Queue to submit difference job(s) [CLUSTER_LONGBATCH]: 

Enter a directory for the log file produced by this option. This directory specification is also the default directory specification for any report file produced.


 Directory for logs and work files [WORK212:[SWEENEY.SCRATCH]]: 

Optionally enter a file name to contain a report of the differences between the two streams. By default the differences will be reported in the log file. The file type defaults to ".LIS" and the default directory is the work directory entered at the previous prompt.


 Report file name ? [LOG]: bs.lis 

Enter the facility specifications to process. You may enter wildcards in the facility name. In the example below, the streams will be compared in all facilities which begin with the letter "B".


 Facility to process [ALL]: B* 
 
 If you proceed you will submit a job to difference stream V5.5 
 to stream V5.5_BUILD for all facilities matching the specification 
 VMS$:[B*.CMS].  Differences will be reported in 
 file WORK212:[SWEENEY.SCRATCH]BS.LIS;. 
 
 Do you wish to proceed? [Yes]: yes 
Job BS (queue CLUSTER_LONGBATCH, entry 1483) started on GALAXY_LONGBATCH 

You are asked if you wish to process any more facilities. If you answer affirmatively to the prompt, you are asked for a new report file name and a facility specification to process. A batch job is submitted for each facility specification entered. The procedure terminates when you enter "NO" to this prompt.


 Do you want to process any more facilities? [Yes]: 
 Report file name ? [BS.LIS]: cs 
 Facility to process [ALL]: c* 
 
 If you proceed you will submit a job to difference stream V5.5 
 to stream V5.5_BUILD for all facilities matching the specification 
 VMS$:[C*.CMS].  Differences will be reported in 
 file WORK212:[SWEENEY.SCRATCH]CS.LIS;. 
 
 Do you wish to proceed? [Yes]: 
Job CS (queue CLUSTER_LONGBATCH, entry 1484) started on DELPHI_LONGBATCH 
 
 Do you want to process any more facilities? [Yes]: no 

10.2 Compare Class Processing

For each facility specification entered, a batch job is submitted to produce a report of differences between the two streams. The batch job displays a message for each facility processed. A sample session and the log file produced by the session's input follows.


Difference Stream Version X-1 
 
Enter ? or "HELP" at any prompt to obtain help 
Prompt default values (if any) appear in brackets [] 
Enter <Ctrl>Z, "Quit" or "Exit" to exit immediately 
 
 Product Root [VMS$]: 
 First Stream [V5.5]: 
 Second Stream [V5.5_BUILD]: AMBER 
 Queue to submit difference job(s) [CLUSTER_LONGBATCH]: 
 Directory for logs and work files [WORK212:[SWEENEY.SCRATCH]]: 
 Report file name ? [LOG]: 
 Facility to process [ALL]: H* 
 
 If you proceed you will submit a job to difference stream V5.5 
 to stream AMBER for all facilities matching the specification 
 VMS$:[H*.CMS].  Differences will be reported in 
 the log file. 
 
 Do you wish to proceed? [Yes]: 
Job V55_AMBER_DIFF (queue CLUSTER_LONGBATCH, entry 591) started on GALAXY_LONGBATCH 
 
$ type WORK212:[SWEENEY.SCRATCH]V55_AMBER_DIFF.log 
 
   "SYS$NODE" = "GALAXY::" (LNM$SYSTEM_TABLE) 
%FAC-I-PROC, Processing library VMS$:[HELP.CMS] 
                  Library: VMS$:[HELP.CMS] 
          Base class: V5.5    Target class: AMBER 
 
  Element name         V5.5         AMBER          
----------------------------------------------------------- 
  ACCOUNTIN.HLP        2            3             
  LEXICAL.HLP          6            7             
  SET.HLP              12           14            
  SHOW.HLP             9            10            
  START.HLP            6            7             
  STOP.HLP             6            9             
  V55_NEWFEATURES.HLP  2            3             
 
%FAC-I-PROC, Processing library VMS$:[HLD.CMS] 
  TEST  job terminated at 29-APR-1992 09:01:45.67 
  Accounting information: 
  Buffered I/O count:             139         Peak working set size:    4178 
  Direct I/O count:                77         Peak page file size:     11696 
  Page faults:                   5831         Mounted volumes:             0 
  Charged CPU time:           0 00:00:03.34   Elapsed time:     0 00:00:13.16 

10.3 Suggestions for Comparing Classes

This option uses the masterpack CMS libraries in readonly mode so there are no restrictions in the use of the utility.


Chapter 11
Archiving or Obsoleting a Facility

The need to archive or obsolete an entire facility occasionally arises. Most commonly, a facility used for holding the update files for a particular VMS release is archived after the release ships.

Obsoleting a facility refers to deactivating a facility beginning at a particular stream. The deactivation is achieved by removing all of the facility's module generations for a specific stream and all of the generations of the stream's successors. For example, assume facility DECW$LIBS is active in stream AMBER and obsolete in stream BLADE. Suppose both streams are still open for source code changes and BLADE is a successor of AMBER . The BLADE stream does not want the four hundred modules in the facility to be used when creating new build streams and populating existing build streams, but, the AMBER stream needs the four hundred module generations. The BLADE release project leader can obsolete the facility and remove the four hundred module generations from the VDE stream and CMS library. Obsoleting the facility will mean faster, more efficient stream populations for the BLADE project. The AMBER project is unaffected by this action.

Archiving a facility obsoletes the facility beginning at a particular stream, and sets a flag to prevent further stream creations and stream populations for ALL streams in the facility.+ If the facility to archive spans multiple releases, it is important that the facility not be archived until all mainline streams in which the facility is active are closed.

Required Privileges

The archive facility option requires that the user hold the VDE privilege PERFREP and the process rights identifiers VMS_ENABLE_CMS and VMS_SOURCE. If the user does not hold these privileges, the submitted batch job will fail.

Note

+ This restriction is overridden when you use the populate selected facilities menu option. VMS remedial streams need to use archived facilities.

11.1 Invoking the Archive Facility Procedure

To archive or obsolete a facility, select option ten from the main menu. The archive facility command procedure executes.


What action do you want to perform? (1-10,EXIT,HELP): 10 
 
Archive/Obsolete A Facility Version X-1 
 
Enter ? or "HELP" at any prompt to obtain help 
Prompt default values (if any) appear in brackets [] 
Enter <Ctrl>Z, "Quit" or "Exit" to exit immediately 
 
 Product Root [VMS$]: 

Enter the product root. See Chapter 2 for a definition of product root.

You are asked for the facility to archive or obsolete. The procedure validates the existence of the facility. The procedure issues a warning message if the VMSCMS$ARCHIVED_FACILITY.FLAG file is found in the facility masterpack directory. This flag indicates that the facility was archived in the past. You are allowed to continue even if the VMSCMS$ARCHIVED_FACILITY file is found.


  Facility To Obsolete?: DECW$LIBS 

Now indicate if you want the facility to be archived or to be obsolete. Your entry must be substring of "ARCHIVED" or "OBSOLETE".


Archive or Obsolete DECW$LIBS? [OBSOLETE]: Ob 

The next prompt asks you for the stream where the facility is obsolete. The facility should not be active for the stream entered. All module generations for the entered stream and all of it's successor streams are removed from the VDE database stream and the facility CMS class.


Stream at which to OBSOLETE the facility? [AMBER]: BLADE 

Enter the batch queue in which to submit the obsolete facility job.


 Queue to submit obsolete batch job [CLUSTER_LONGBATCH]: 

Enter the directory for the log file produced by the batch job.


 Directory for logs and work files [WORK9:[SYSBLDTEST.JUNK]]: 

At the next prompt, indicate the time to begin execution of the obsolete a facility batch job. The entry defaults to execute the job immediately. If the facility you are archiving or obsoleting contains many modules, it is advisable to defer processing until after "normal" working hours.


 Time to begin obsolete facility job? [NOW]: 

Confirm your input to submit the batch job.


 Do you wish to proceed? [Yes]: 
 Job Obsolete_decw$libs (queue CLUSTER_LONGBATCH, entry 808) started on GALAXY_LONGBATCH 

11.2 Archive/Obsolete Facility Processing

The processing performed by the obsolete a facility batch job is summarized as follows:

  1. If the ARCHIVE option was selected by the user, the file VMSCMS$ARCHIVED_FACILITY.FLAG is created in the facility directory. For the DECW$LIBS facility in the VMS product, the file would be located in directory VMS$:[DECW$LIBS].
  2. The procedure determines all of the streams for which the facility is obsolete. The result is the stream entered by the user and all successor streams in the VDE database.
  3. For each stream determined in the previous step, all module generations in the facility that are members of the stream are removed from the stream via a VDE REMOVE GENERATION command.
  4. For each stream, the associated CMS class is deleted from the facility CMS library.

11.3 Suggestions for Archiving and Obsoleting Facilities


Appendix A
Future Menu Options

Below is a list of options that will be added to the project leader menu in the future.
  1. Prepare a result disk for a system build
  2. Start a system build
  3. Check system build results
  4. Reserve a baselevel number for a future build
  5. Permanently close a stream against changes
  6. Perform a stream's replacements

If you have any comments, gripes, or suggestions regarding the project leader menu or this documentation, please contact Dave Sweeney (STAR::SWEENEY).

Previous Contents Contents