V'0);FACPOP

FACPOP



&

July 1991





CThe Facility Populate utility (FACPOP) is used to populate one CMS Gclass from another CMS class. The advantage of this utility is that if Ethe class to be populated already contains some elements, then these Felements will be skipped since no real work needs to be performed for them.

%Software Version: FACPOP Version X0.1



B

FACPOP



D Activates the FACPOP utility. The FACPOP utility is run from DCL. $ Selectively populates CMS classes.



Format

5

FACPOP library-spec base-class target-class

                  
Command QualifiersDefaults
 /[NO]CREATE  /NOCREATE
 /[NO]LOG  /LOG=library
 /PROCESS  /PROCESS=flagfree
 /[NO]REMOVE  /NOREMOVE


prompts

            
 LIB_SPEC:  library-spec
 BASE_CLASS:  base-class
 TARGET_CLASS:  target-class



Description

GThe FACPOP utility is used to create (if necessary) and populate a CMS Hclass from an existing CMS class. This utility has some built in checks Ethat must be met in order to minimize the possibility for error. The Dactual task of populating the CMS class is performed in three steps.

HThe first step is to verify that both class names specified are present Fin the CMS library. If the 'TARGET' class is not present, the utility Dwill optionally create this class for the user. If the user did not Hspecify that the class should be created, then the utility will display Ean error message and discontinue processing on the library that does not contain the 'TARGET' class.

DThe second step is to build a list of all elements contained in the C'BASE' class, and a list of all elements contained in the 'TARGET' @class. Using these lists, the utility then puts the new/updated 8generations found in the BASE list into the TARGET list.

HThe third and final step is to remove all element generations that were Efound in the TARGET list, but were not present in the BASE list. The @step is optional, and by default is turned off (see the /REMOVE qualifier).




Parameters



library-spec

G Specifies the CMS library that is to be acted on. This specification F can contain wildcards, but it must be a valid CMS library directory J specification (i.e. VMS$:[YELLOW_TEST.CMS]). An example of a wildcarded J specification would be: VMS$:[Y*.CMS]. This specification would process / all libraries that start with the letter "Y".

base-class

H Specifies the CMS class name that will be used to populate the target  class.

target-class

6 Specifies the CMS class name that will be populated.



Command Qualifiers



/[NO]CREATE

I Indicates that the utility should create the target class if it is not H already present in the library. The target class will only be created I if the library contains the base class, and the library is one that is J supposed to be processed. The default is not to create the target class G and to display an error message indicating that the target class was  not found in the library.'

/LOG=(log-type[,log-type,...])

I Specifies what type of logging the user wants. The default is that the A user will only see messages from the utility pertaining to the I libraries being processed or skipped. The list of acceptable log types  is:-

/PROCESS=(attribute[,attribute,...])

E The PROCESS qualifier is used to identify what libraries are to be J processed. Some libraries have special attributes associated with them, I VMSCMS$NO_PROPAGATE.FLAG is an example of an attribute. This attribute B indicates that this library is not to have any code propagation D performed within it. The process qualifier is used to selectively H process or skip libraries marked with certain attributes. The list of  acceptable attributes is:

/[NO]REMOVE

D Indicates that the utility should remove generations found in the I target class that are not in the base class. The default is that these 8 generations will not be removed from the target class.


 .
^ Contents