| PreviousZ | Contents\ | Index |
<Before a user can use the new VDE library you are creating, <that user must be added to the library's VDE database. This 8means that VDE must create an entry for the user in the ;database User Table. This entry records the user's OpenVMS Cusername, full name (first and last names), default and authorized Hprivileges, and other information. A user who has not been added to the 6database cannot use VDE to access information in that 1database or to perform VDE operations on the VDE library.
CThe CREATE LIBRARY command automatically adds the creator of a new =VDE library to the library's database. Additional users must Ebe added in one or two ways. First, they can be added manually using @the CREATE USER command. This command allows you to specify the Dattributes of each new user explicitly. This way of adding users is 8most practical for VDE libraries with a small number of Dusers, especially if you want careful control over who accesses the library.
DSecond, you can set a library attribute that allows new users to be 7added automatically the first time they access the VDE <library. This way of adding users is more practical for VDE Flibraries with a large number of potential users. To enable automatic Haddition of new users, you must use the /AUTO_ADD_USER qualifier to the DCREATE LIBRARY or MODIFY LIBRARY command. If this qualifier is used =without a parameter, any user who attempts to access the VDE 2library through VDE is automatically added to the 6VDE database with the standard default and authorized VDE privileges for that library.
HThe qualifier can also be specified with a rights identifier parameter, ;as in /AUTO_ADD_USER=rights-id. In this case, VDE ?will only add those users to the database who hold the OpenVMS Frights identifier given by the parameter. This way of adding users is ;useful when you already use a OpenVMS rights identifier to :protect the files and directories of your VDE library. In ?this case, the OpenVMS security mechanism for the library also 9serves as the mechanism that restricts access to the VDE library through the VDE utility.
uSection 6.4 gives a more complete description of how you can add users to your VDE library.
GIf you do not specify the /AUTO_ADD_USER qualifier, you must add users Hwith explicit CREATE USER commands. However, you can change the library Cattribute that controls automatic addition of users at any time by Gusing the /AUTO_ADD_USER or /NOAUTO_ADD_USER qualifier with the MODIFY LIBRARY command.
5The owner information specified in the OpenVMS SYSUAF< database will be used as the owner of any new VDE username 8 created. VDE will ignore any leading numerics, leading I hyphens, leading space characters, and leading tilde characters, listed in the SYSUAF owner field.N
/VDE maintains data about your VDE library in a ;relational database. As new capabilities are added to VDE, ;the format of this database may change from one version of =VDE to the next. A new feature may, for example, require the Haddition of new database tables or of new columns to existing tables in Horder to store the data required to implement the feature. New features <may also require other changes to your VDE library, such as Bthe addition of a subdirectory or a new file. To accommodate such <changes to the library format, each new version of VDE that Crequires a format change contains code that converts your existing 4VDE library to the new format. VDE also maintains a Hdatabase format version number in your database so that it always knows 4the current format of your library and its database.
<When a new version of VDE is installed on your system, that 6version may require that your existing VDE library be Cconvered to a new format. If so, there are two ways to effect this =conversion. One is to allow VDE to automatically convert the Dlibrary format the first time any user accesses the library through 9VDE. The second way is to explicitly convert the library "using the CONVERT LIBRARY command.
3By default, VDE will not convert your VDE ;library automatically the first time any user starts a new )VDE session that attaches to that libraryE1 Automatic conversion is useful for small libraries, for Clibraries that are accessed only by the local copy of VDE, and for Blibraries that are easily restored from backup. In order to avoid Funexpected conversions and the resulting potential for library access Houtages, automatic conversion is, by default, disabled when the library is created.
FIf you specify the /AUTO_CONVERT qualifier with the CREATE LIBRARY or <MODIFY LIBRARY command, VDE will automatically convert your >library when new versions of VDE are installed on your system.CIf automatic conversion is disabled, a user must enter an explicit ECONVERT LIBRARY command to convert the library. To use this command, <you must have the VDE privilege MODLIB. This approach gives >you more control over when conversions occur so that your VDE Alibrary cannot be accidentally converted to the format for a new /version of VDE that you do not yet want to use.
DFurthermore, when the library format changes, you should in general 9delete all processes connected to the VDE library before Fconverting the library so that all user processes use the new version =of VDE after the conversion. This is especially important if <most users use kept VDE subprocesses to access the library. !To delete such processes, use the@RMU/CLOSE command with the /ABORT=DELPRC qualifier. For example:
|
" ;$ RMU/CLOSE/CLUSTER/ABORT=DELPRC DEV$:[ROOTDIR]VDE$DATABASE |
BTo use the RMU/CLOSE command, you must have the OpenVMS privilege SYSPRV.
EYou can modify the library attribute that controls automatic library Econversion using the /AUTO_CONVERT or /NOAUTO_CONVERT qualifier with the MODIFY LIBRARY command.N
:The /AUTO_MAIL qualifier specifies that VDE should send a Hmail notification message to the user who has queued a replacement when pthat replacement is later performed (see Queued Replacements). The D/NOAUTO_MAIL qualifier suppresses such notification messages. These 8qualifiers thus control the volume of mail messages VDE Bsends. If you specify neither qualifier, /AUTO_MAIL is assumed by default.
3The /NOSEND_MAIL qualifier suppresses all VDE mail Gnotification messages for the library. This qualifier is useful if you <are setting up a VDE library for testing purposes or simply =to play with. For a production VDE library you should always >enable mail notifications, which can you do by specifying the F/SEND_MAIL qualifier or by simply omitting the /NOSEND_MAIL qualifier.W
;VDE allows you to delete library entities such as modules, Bfacilities, and streams with various DELETE commands. To use such Hcommands, you must in general have the corresponding delete privileges. HThese delete privileges protect against deletion of library entities by Dunauthorized users. They also require authorized users to set those Dprivileges before deleting entities, thus providing some protection against accidental deletion.
CAs an additional protection against accidental deletion of library ;entities, VDE allows you to specify that certain entities, Fsuch as specific modules, facilities, and streams, are not allowed to Hbe deleted even when the user has the corresponding delete privilege. A @given stream, for example, can have its delete attribute set to Fno-delete using the /NODELETE qualifier to the MODIFY STREAM command. <VDE will then not allow the DELETE STREAM command to delete Hthat stream. The stream can still be deleted, but only if the attribute His first changed with another MODIFY STREAM command to allow the stream @to be deleted. The no-delete attribute thus prevents accidental Cdeletion of the stream by requiring an extra command to explicitly Aallow deletion before the DELETE STREAM command can be used. The ,delete-stream privilege is required as well.
>When you create your VDE library, you can specify the default Asetting of the deletion attribute for new database entities. The F/ALLOW_DELETE qualifier to CREATE LIBRARY specifies that new database 9entities should be allowed to be deleted by default. The F/NOALLOW_DELETE qualifier specifies that database entities should not Gbe allowed to be deleted by default. If you specify neither qualifier, <VDE by default marks new database entities as being allowed Ato be deleted. You can of course always override this default by Fexplicity specifying the delete attribute when creating new entities. AIn general, allowing deletion is more convenient for the library Dmaintainer. Not allowing deletion is more appropriate when numerous ?individuals have access to the library and some of them may be &accident-prone when entering commands.M
>Two sets of qualifiers to the CREATE LIBRARY command controls <VDE's treatment of CMS history and notes information in the 3VDE library. The /NOCMS_ELEM_HIST qualifier causes :VDE to create CMS elements (that is, delta files) with no Ddefault history and notes strings. This prevents CMS from producing Ffiles with history or notes information when modules are fetched with Gthe CMS FETCH command. This library attribute has no effect on modules >fetched with the VDE FETCH command, so it is only relevant if :DCL command procedures access the CMS elements in the VDE library using CMS directly.
>The /NOHISTORY_NOTES qualifier causes the VDE RESERVE command Fto never produce CMS history or notes information in its output files Band to not accept the /HISTORY, /NOTES, and /POSITION qualifiers. HDisabling history and notes information in reserved files makes certain Cmistakes less likely where such information gets replaced into the 'VDE library as part of the module text.
CBoth of these qualifiers prevent certain problems where history or Gnotes information gets included in output files where this information Gmust not be present. Such problems only occur in special circumstances 9and do not affect most VDE libraries. As a result, these Bqualifiers are optional and the default settings are given by the Fpositive forms of those qualifiers, /CMS_ELEM_HIST and /HISTORY_NOTES.E
.This section is under construction...
BAfter the creation of the various architectures using one or more !CREATE ARCHITECTURE commands, oneGnormally enables the display of differnt architectures with the MODIFY "LIBRARY/SHOW_ARCHITECTURE command.
USee Chapter 9 for further information.H
HOther qualifiers to the CREATE LIBRARY command allow you to set various ?miscellaneous library attributes. The /ASK_INFO_FILE qualifier Ddetermines whether the REPLACE command will by default ask the user qwhether to edit a replacement information file (see Section 2.7). The @/SHOW_GEN_EXPR qualifier determines whether the RESERVE command >displays the expected generation expression of the new module Fgeneration to be created when the module is later replaced. These and Hother qualifiers are described in more detail in the description of the FCREATE LIBRARY command. Whether they are applicable to you depends on Bthe development process you think is appropriate for your project.
FIf you have no strong feelings on these options, use the defaults. If Eyou later change your mind, you can always change these setting with the MODIFY LIBRARY command.
9In addition to its root directory and database, your VDE =library contains a number of additional disk directories and Hsubdirectories. These additional directories contain the source modules Bfor your software system, all associated derived modules (such as Eobject modules and executable images), and various command files and 7log files that VDE uses to perform its functions. This Hsection describes the structure and functions of these disk directories.G
;VDE always stores all source modules that are part of your <software system in "delta files." A delta Gfile stores all generations of a source module in a condensed Fform. The delta file stores every line that has ever been part of the Gsource module, along with information specifying which lines belong to Fwhich generations of the module. Because a line that is the same from Fone generation to the next is only stored once in the delta file, the Afile saves space by essentially only storing differences between Hgenerations. (Such files are called "delta files" because the ?Greek letter delta is often used to denote differences between %quantities in mathematical notation.)
:VDE uses callable CMS (VAX/VMS Code Management System) to =manage its delta files. VDE sets up one CMS library for each ;facility in your software system. VDE also creates one CMS Helement (which is a delta file) for each source module in your software system.
2By default, VDE creates a delta-file root Hdirectory called VDE$CMS.DIR within the library root directory Bwhen you create the library. Each time you create a new facility, 8VDE creates a subdirectory for that facility within the Gdelta-file root directory. The CMS library for the facility is created Cin the facility's subdirectory. CMS uses additional subdirectories Gwithin the CMS library to store the actual delta files (CMS elements), <but VDE does not keep track of the internal organization of sthe CMS library. Table 6-1 illustrates the disk directories that $VDE establishes for delta files.
j
| Library root directory: | DEV$:[ROOTDIR] |
| Delta-file root directory: | DEV$:[ROOTDIR.VDE$CMS] |
| ! Directory for facility FOO: | DEV$:[ROOTDIR.VDE$CMS.FOO] |
| ! Directory for facility BAR: | DEV$:[ROOTDIR.VDE$CMS.BAR] |
;VDE records the directory specification for the delta-file ?root directory and each facility's delta-file directory in its >database. The SHOW LOCATION /DELTA_FILE command displays this information on your terminal.
<Although VDE uses the default locations just described, you Ccan specify different locations for the delta-file directories. To Hspecify a different delta-file root directory (VDE$CMS by default), you must take the following actions:
|
" 0VDEä SET DIRECTORY /DELTA_FILES DEV$:[DELTAROOT] |
|
" <VDEä SET DIRECTORY /DELTA_FILES /FACILITY=FOO DSK2:[PQR.STU] |
|
" 'VDEä CREATE DIRECTORY_TREE /DELTA_FILES |
|
" 5VDEä CREATE DIRECTORY_TREE /DELTA_FILES /FACILITY=FOO |
GNote that the SET DIRECTORY command specifies where a directory should Fbe located, but does not actually create the directory. In effect, it <creates a template for some part of the VDE directory tree. FTo actually create directories from that template, you must enter the FCREATE DIRECTORY_TREE command. This arrangement allows you to specify Gtemplates for many parts of the directory tree before you actually use $the templates to create directories.I
=When you use VDE for source control, you can replace modules Fin two ways. One is to replace modules immediately, in which case the 9modules being replaced are inserted into the VDE library Hright away. The other way is to queue modules for replacement, in which Gcase the modules are not inserted into the library until an authorized Fuser "performs" the queued replacement. Queued replacements Dare useful because they give project managers more control over the Atiming of replacements and they allow the replaced modules to be 0reviewed before being inserted into the library.
;When a user queues modules for replacement, VDE copies the :files being replaced into the library's staging area. The Hstaging area is a disk directory tree that temporarily Dholds files being replaced until the corresponding replacements are Bperformed by an authorized user. The staging area starts with the @staging area root directory. By default, this root directory is 9subdirectory VDE$STAGE within the library root directory.
=Within the staging area root directory, VDE creates two more Clevels of subdirectories. The staging area root directory contains Dsubdirectories with names of the form VDE$STG_n. Each such Gdirectory holds a group of 100 replacements. Directory VDE$STG_12, for Gexample, contains replacements with Replacement Id values in the range 61200 to 1299. Within each such directory, VDE creates ?second-level directories that each hold the files for a single Freplacement. Within VDE$STG_12, for example, there are subdirectories @with names such as VDE$REP_1261, representing replacement 1261. WTable 6-2 illustrates this structure.
5Within the replacement subdirectory, VDE creates one <subdirectory for each facility involved in the replacement. 8VDE stores the individual files being replaced in those ?facility subdirectories. Comment and information files for the Ereplacement are stored in the replacement subdirectory. This is also Ishown in Table 6-2.
l
| Library root directory: | |
| DEV$:[ROOTDIR] | |
| " Staging area root directory: | |
| DEV$:[ROOTDIR.VDE$STAGE] | |
| % Directory for 100 replacements: | |
| ) DEV$:[ROOTDIR.VDE$STAGE.VDE$STG_12] | |
| $ Directory for one replacement: | |
| 6 DEV$:[ROOTDIR.VDE$STAGE.VDE$STG_12.VDE$REP_1261] | |
| + Comment file for replacement ID 1261: | |
| E DEV$:[ROOTDIR.VDE$STAGE.VDE$STG_12.VDE$REP_1261]DOE.VDE$COMMENT | |
| $ Directory for facility FACNAM: | |
| = DEV$:[ROOTDIR.VDE$STAGE.VDE$STG_12.VDE$REP_1261.FACNAM] | |
| % File for module being replaced: | |
| D DEV$:[ROOTDIR.VDE$STAGE.VDE$STG_12.VDE$REP_1261.FACNAM]MOD.TYP | |
;As mentioned above, VDE's default location for the staging Farea root directory is subdirectory VDE$STAGE within the library root Gdirectory. To change this default, you must take the following actions:
|
" .VDEä SET DIRECTORY /STAGING DEV2$:[PROJ.STAGE] |
|
" #VDEä CREATE DIRECTORY_TREE /STAGING |
HThe SET DIRECTORY and CREATE DIRECTORY_TREE commands can be used at any Htime after library creation to redirect the staging area to a different disk location.
<After a given replacement has been performed, VDE no longer :needs the corresponding staging area. VDE does not itself Edelete those files, but you should do so periodically to reclaim the Edisk space. Staging area files can be useful for some time, however, ;because they contain copies of the files inserted into the 3VDE library. They can thus be used to recover lost Hinformation if your delta files (CMS libraries) are lost or damaged. In Gcase of such loss, you have to restore the CMS libraries from backups. HThat should make them close to being consistent with the information in 2the VDE database. After that, you can use the VDE EVERIFY GENERATION command with the /RECOVER qualifier to restore the ;CMS libraries to the state given by the VDE database. This ;recovery operation requires access to the old staging area Ddirectories---to retrieve copies of any lost module generations for Einsertion into the CMS libraries. For this reason, you should always Ghave the staging areas on a different disk than the delta files or the ;VDE database and you should keep the staging areas for old Greplacements around for some time after the replacements are performed.
DFor information on typical staging area maintenance operations, see =Section 7.5.
| PreviousW | NextZ | Contents\ | Index |