| PreviousZ | Contents\ | Index |
.VDE supports a number of convenience features.<
<VDE can utilitize a kept subprocess. The kept subprocess is Fcreated when the command interface is first activated, and it greatly Cimproves overall performance. With the kept subprocess, all of the Fprocessing required to initially connect to the database is performed 2only once, not each time the utility is activated.
- To force an update of the security and quota@attributes in the kept subprocess, issue the following commands:
|
" VDEä EXIT/KEPT_PROCESS$ VDE/KEPT_PROCESSVDEä |
9One can use an initialization file to set up VDE command >abbreviations (with DEFINE/COMMAND), keypad definitions (with EDEFINE/KEY), and session environment defaults (with SET FACILITY and @SET STREAM). An initialization file can contain zero or or more VDE commands.
8VDE supports a user-specified initialization file. Each Futility processes an initialization file in a similar fashion, though Aeach uses a unique name for the file. The initialization file is 7automatically invoked at the start of each VDE session.
9To establish an initialization file for the VDE utility, ,define the logical name VDE$INIT38before starting the VDE session. This logical name must ;reference the file name of the VDE initialization file. If Dthe file name and/or the file extension is omitted from the logical 9name translation, the VDE utility uses the default value )VDE$INIT.VDE for the initialization file.
DAn initialization file is usually resident in the user's SYS$LOGIN: directory.
?If desired, the exclamation point (!) can be used as a comment 3character in an VDE or an VDE initialization file. @All text located after a exclamation point is ignored up to and Gincluding the end of the line, if the exclamation point is not located within a quoted string.?The space-hyphen ( --) can be used as a line continuation. The Gspace-hyphen character must be the last character of a line; it causes Fthe subsequent command line to be considered part of the current line.;
1VDE lets one establish a text editor for the VDE 7session. VDE invokes the specified editor when certain >commands are entered. For example, VDE lets one use an editor Hto review code changes on behalf of another user. The editor is invoked Gin a spawned subprocess, and can be invoked in read-write or read-only Fmode, depending on the context. To specify the editor for the current 5VDE session, use the SET EDITOR command. For example:
|
" VDEä SET EDITOR "LSEDIT" |
?The /DEFAULT qualifier on the SET EDITOR command allows one to >establish the default editor strings for future VDE sessions. DThese editor strings are stored in the source control database. The 8SHOW EDITOR command displays the current editor strings.
>VDEalso supports a number of standard utility commands. These Gcommands include @file-spec (which executes a file containing =VDE commands), SPAWN, ATTACH, EXIT, HELP, DEFINE/KEY and SET CKEY, DEFINE/COMMAND, SET LOG and CANCEL LOG, SET VERIFY and CANCEL EVERIFY, SET TERMINAL, and all associated SHOW commands. See the HELP (text for descriptions of these commands.I
/VDE and VDE module reservations can be grouped Htogether using sessions. One can create a session that Econtains a group of modules involved in a particular modification or Gfix---all modules contained in a session can be referenced in a single command.
|
" VDEä REPLACE/SESSION=WIN32_VMS |
AThe above command replaces all modules included in the WIN32_VMS session.
3Information on how to reserve and lreplace modules is included in Chapter 2.F
GA context allows you to easily switch an entire group 8of related VDE default settings among a set of possible :values. You can keep multiple sets of VDE defaults around.
FEach context is comprised of a set of defaults: a default facility, a @default stream, and a default architecture. (For information on rarchitectures, see Chapter 9.) You can specify one context for use Fwhen you are making bugfixes to a particular stream and facility, and Danother context for when you are adding new features to a different Hfacility in a newer stream. And using key definitions (DEFINE/KEY), you @can switch among your various contexts using a single keystroke.
DContexts can be private and user-defined, or they can be publically Eestablished and available for whole groups of users. Project leaders Gcan establish a set of contexts for use by a particular group of users.J
>VDE utilitizes a set of logical names to determine the names, Dcontents and locations of commonly-accessed libraries. To see which Glibraries have been established by default (if any), issue the command:
|
" VDEä SET LIBRARY |
?For information on the VDE$LIBRARY_DEFAULTS logical names, see hVDE Reference Manual, or see Section 10.1.3.
| N < 3 VSC and VTSC use P the logical names VDE$INIT and VTSC$INIT, respectively, and the default L specifications of VSC$INIT.VDE and VTSC$INIT.VDE, respectively. |
>This chapter describes how to use the VSC utility to identify <specific modules in a VDE library. It also shows you how to Ecreate, reserve and replace modules, how to fetch module generations Awithout reserving them, how to create new modules, how to cancel Breservations, and how to display reservation information from the source control database.
AThis section also describes some convenience features present in 4VSC and VDE. Examples of these features include the Hability to reserve groups of modules, called sessions, Hand treat these modules as a unit. Also covered is the ability to queue Ea reservation request when a module is reserved by another user, and Chow to receive notification when the queued reservation request is eventually granted.`
HEach generation of a given module can be referenced using either of two Fnames. One generation name is the generation number. This4number is assigned and maintained by VSC. The other Cgeneration name is the generation expression. The Hgeneration expression is assigned by CMS. One can use either generation 6name to specify a specific generation in VSC commands.
:VSC assigns generation numbers in sequential order to the Hgenerations for each development stream. Generation 1 is thus the first Egeneration for the stream, generation 2 is its successor, and so on. EGeneration 2 of stream A can be the same as generation 2 of stream B D(if the streams have not yet diverged) or they may be two different 1generations (assuming the streams have diverged).
>When one refers to a generation by its generation number on a :VSC command, one specifies a semicolon and the generation Hnumber after the module name. The generation number is relative to some ?stream that one specifies explicitly (usually with the /STREAM Hqualifier) or by default. For example, MOD.TYP;5 refers to generation 5 Bfor the specified stream. One can also specify a zero or negative Fgeneration number; such a generation number is relative to the latest ?generation for the stream. MOD.TYP;0 thus refers to the latest Fgeneration and MOD.TYP;--1 refers to the next most recent generation, %and MOD.TYP;--0 refers to the oldest.
FCMS generation expressions are assigned by different means. The first Ageneration for a module has generation expression 1. It can have Hmultiple successors (for different streams) with generation expressions H2, 1A1, 1B1, 1C1, and so on. Generation 1B1 can in turn have successors @1B2, 1B1A1, 1B1B1, and so on. Each generation thus has a unique Egeneration expression that encodes its genealogy. This expression is Aindependent of stream. To specify a generation by its generation Fexpression, one must use the /GENERATION qualifier for those commands Bthat accept it. For example, MOD.TYP/GENERATION=1B1 refers to the @generation of module MOD.TYP that has generation expression 1B1.
GIf one omits both the generation number and the /GENERATION qualifier, 9most VSC commands reference the latest generation of the Gmodule for the specified stream. This causes the command to operate on Ethe most recent generation by default---this is normally the desired effect.
HBecause generation numbers are always relative to some stream, they are Bused to show lines of descent for a given stream and to reference Fgenerations relative to a specific stream. CMS generation expressions >are independent of stream and thus give absolute names to the Agenerations of a module. These two kinds of generation names are @primarily used with the SHOW GENERATION and FETCH commands. For Hexample, to fetch the next most recent generation of module FOO.BAR for Gstream FRED, one would request generation number --1, as shown in this example:
|
" "VSCä FETCH /STREAM=FRED FOO.BAR;-1 |
|
" #VSCä FETCH FOO.BAR /GENERATION=10A3 |
FWhen modifying a source module, one typically adds code comments that Hexplain the nature of the changes. These comments should be labelled by Gan audit trail identifier. The audit trail identifier Gis simply the expected CMS generation expression of the new generation ;one creates when replacing the changed module into the VDE =library. VDE displays the expected CMS generation expression Bwhen the module is initially reserved. In rare circumstances, the Bactual generation expression used when the module is replaced may Bdiffer from the expected generation expression displayed when the 5module is reserved. If this happens, VSC displays an Ainformational message. One must then update the source module to 8correct the audit trail identifier in the code comments.S
8To reserve a module from a VDE library, use the RESERVE >command. This command reserves a specified module for a given Hdevelopment stream and fetches that module into your default directory. ;This example illustrates the syntax of the RESERVE command:
|
" 9VSC> RESERVE/STREAM=FOO [FACIL]MOD.TYP "Remark string" |
AWith the RESERVE command, you can specify a list of module names Gseparated by commas. This syntax---or the session support---allows you Hto manipulate a number of modules with only a few commands. For example:
|
" VSC> SET FACILITY SYSGVSC> RESERVE/STREAM=FOO A.MAR,B.MAR,C.MAR "Reduce memory-scrambling" |
FYou can use wildcard characters in the module names. The percent sign G(%) in a name matches any single character in the position it occupies Hand the asterisk (*) matches zero or more characters in the position it Coccupies. All modules that match the wildcard pattern are reserved.
:VDE also allows you to associate a number of modules from Bvarious RESERVE and CREATE MODULE commands together, by using the E/SESSION qualifier. The /SESSION qualifier allows you to pick a name Ffor a group of modules, and to avoid having to specify each module on Ethe REPLACE command. The use of /SESSION also provides the reviewers ?and the project leader with a clear indication that a group of replacement modules are related.
EThe reservation remark string can be specified as a parameter at the Aend of the command, as shown in the previous example. The remark Dparameter has the same effect as the /REMARK qualifier described in tTable 2-1 and applies to all reserved modules unless overridden by </REMARK qualifiers on the individual module-name parameters.
HThe RESERVE command displays the expected CMS generation expression for Athe new generation that will be created when the module is later Greplaced. You should use this generation expression as the "audit Gtrail identifier" for the comments in your code that explain your Cnew changes. This example illustrates the RESERVE command's output:
|
" AVSC>RESERVE/STREAM=BIRCH [FACIL]MOD.TYP "Add gasket modulator"C%VDE-I-FETCHED, generation [FACIL]MOD.TYP;3(3) fetched from library3%VDE-I-OUTFILE, output file is DEV$:[MYDIR]MOD.TYP;J%VDE-I-RESERVED, generation [FACIL]MOD.TYP;3(3) reserved from stream BIRCHG%VDE-I-EXPGENEXPR, expected generation expression at replacement is 3A1>%VDE-I-COMMIT, database transaction has successfully committedVSC> |
AThe source control system keeps track of successor relationships Cbetween streams. If source changes replaced into a stream A should Dnormally also be propagated to another stream B, then stream B is a Hsuccessor of stream A. Successor relationships between =streams are defined by the maintainers of the VDE libraries, Fand reside in the source control database. These relationships ensure @that bug fixes and other changes made to one version of OpenVMS 0are propagated to all later versions of OpenVMS.
HSuccessor relationships determine what streams are affected by a module Areservation. Normally, a reservation covers the @development stream specified with the /STREAM qualifier and all Gsuccessors of that stream, including the successors of the successors, >and so on recursively. If you omit the /STREAM qualifier, the Freservation covers your default stream and its successors. This means Hthat you expect your changes to be propagated to those streams when you Flater replace the module. However, the reservation does not cover any Bstream in which the module has already diverged from the original 9stream because VSC cannot automatically propagate source changes to such a stream.
HThe RESERVE command determines what streams your reservation will cover Eand checks if any existing reservation for the module already covers >one of those streams. If so, the RESERVE command rejects your ?reservation attempt unless you explicitly request a concurrent Freservation. You can limit change propagation, and therefore restrict Ethe streams covered by your reservation, by using the /PROPAGATE and G/NOPROPAGATE qualifiers. By covering fewer streams (when appropriate), +you make reservation conflicts less likely.
FThe RESERVE command accepts a number of qualifiers. The help text and Hthe reference manual have the details on all of the qualifiers accepted pby the command. Table 2-1 lists some of the more commonly-used qualifiers.
| /CONFIRM
! /NOCONFIRM | |
| M /CONFIRM asks you to confirm that you want each module reserved. This N qualifier is particularly useful if you use wildcard characters in the G module name. /NOCONFIRM reserves each module without asking for / confirmation. /NOCONFIRM is the default. | |
| 0 /IDENTIFICATION=res-ident | |
| L Specifies that the reservation be identified by the name given by theJ res-ident parameter. This name can be an arbitrary K string that is meaningful to you. (The name must consist of letters, L numbers, dollar signs, and underscores and can be up to 39 characters E long.) If this qualifier is omitted, the source control system J automatically assigns a numeric reservation identifier. Reservation K identifiers distinguish between multiple concurrent reservations for ' the same module by the same user. | |
| /LOG
/NOLOG | |
| I Specify whether informational log messages are printed after each N module is reserved. /LOG causes such messages to be printed and /NOLOG , suppresses them. /LOG is the default. | |
| $ /NOCONCURRENT | |
| L Specifies that concurrent reservations not be allowed for any of the M modules reserved by this command. If this qualifier is omitted, other = users are allowed to concurrently reserve the modules. | |
| ' /OUTPUT=filespec
/NOOUTPUT | |
| L /OUTPUT specifies that the reserved module be written to the file or directory given by theH filespec parameter. /NOOUTPUT specifies that the J reserved module not be written to an output file at all. If neither B qualifier is specified, VSC creates the output file in your K current default directory and gives it the same name and type as the module. | |
| + /OVERRIDE=CONCURRENT | |
| O Specifies that the RESERVE command should reserve each specified module N even if the module is already reserved by another user. This qualifier C is required to create concurrent reservations. However, VSC K creates a concurrent reservation for a module only if all previous, N conflicting reservations of that module allow concurrent reservations. M If this qualifier is omitted, the RESERVE command reserves the module I only if it is not already reserved. When this qualifier creates a E concurrent reservation, the VSC utility automatically sends a N mail message to each developer who already holds a reservation for the N module in order to notify him or her of the new concurrent reservation. | |
| - /PROPAGATE=stream-name
# /NOPROPAGATE | |
| M Determine what streams are covered by the current reservation and how M module changes are propagated to successor streams when the module is F later replaced into the library. /PROPAGATE specifies that the I reservation should be propagated to all successors of the initial I development stream up to and including the stream specified by theN stream-name parameter. /NOPROPAGATE specifies that the H reservation not be propagated past the initial stream. If neither N /PROPAGATE nor /NOPROPAGATE is specified, the reservation is propagated N to all successors (recursively) of the initial stream. These qualifiers M are used when a change is appropriate for only a subset of the streams M in the successor chain. For example, a bug fix might apply only to the H initial stream because it is replaced by a new algorithm in later streams.C For OpenVMS VAX, most reservations should use the default G propagation behavior and you should seldom need these qualifiers. | |
| /QUEUE | |
| K Specifies that a reservation request should be queued if you cannot M reserve the module because it is already reserved by another user. If L the requested module can be reserved now, the module is reserved and E this qualifier has no effect. If the module is not available, @ VSC queues a reservation request for it. When the module O later becomes available, you are notified by a mail message and you can then reserve the module. | |
| O When you queue a reservation request, the source control system records L the queued reservation in its database. The SHOW RESERVATION command M displays queued reservations. When the developer who owns the current M reservation later replaces the module into the library or cancels the B reservation, VSC sends a mail message to each user who has O queued a reservation request for the module. The mail message says that L the module is available and lists all users who have requested it in L the order that they requested it. Those users must then decide among O themselves who should reserve the module first. To actually reserve the 6 module, you must enter another RESERVE command. | |
| ' /REMARK="string" | |
| D Specifies a one-line remark string to be associated with the @ reservation. The string can be up to 132 characters long. | |
| , /SESSION=session-name | |
| N /SESSION allows you to associated various reserved and created modules L together into a session; sessions allow you to later replace a whole L series of reserved and created modules via a single REPLACE command. N When used with the queued-replacement environment, the use of sessions L also provides a clear indication to the reviewers and to the project M leader that the modules being replaced are associated. The particular N session name used is typically a mnemonic name chosen by the user, and A usually reflects the particular set of changes being made. | |
| * /STREAM=stream-name | |
| M Specifies the development stream from which the specified modules are reserved. TheN stream-name parameter gives the name of the stream. If L this qualifier is omitted, the modules are reserved from your default 2 development stream, provided one is defined. | |
| ) /USERNAME=username | |
| J Specifies that the module should be reserved on behalf of the user . whose OpenVMS user name is given by theK username parameter. To use this qualifier, you must B have a VSC privilege (USERNAME); the qualifier is meant for < release project leaders and others who manage the VDE G libraries, and is intended to be used only in special or unusual situations. | |
| PreviousW | NextZ | Contents\ | Index |