| Previous | Contents | Index |
If you also use the /PROCESS_COUNT qualifier, the /PROCESS_COUNT qualifier states the total number of build-job processes to create. In that case, the process-counts attached to the queue-name parameters on the /QUEUE qualifier are used as scaling factors to distribute the build-job processes among the queues proportionally. For example, if you specify queues HI_BATCH, HO_BATCH(3) and a total process count of eight, then two processes are submitted to queue HI_BATCH and six processes to queue HO_BATCH. If the total process count does not divide evenly into the sum of the scaling factors, the remaining processes are allocated to the queues in the order the queues are listed. If the total process count is nine, for example, the one extra process is allocated to queue HI_BATCH because HI_BATCH is listed first.
| #1 |
|---|
VDE„ START BUILD_JOB
%VDE-I-BLDJOBSIZ, build job 15 for stream V2.0-3 consists of 25 steps
%VDE-I-BLDJOBSTARTING, starting build job 15 for stream V2.0-3
%VDE-I-BLDJOBENT, entry number 549 submitted to queue SYS$BATCH
Job VDEBUILD_0001 (queue CLUSTER_BATCH, entry 549) started on FOO_BATCH
%VDE-I-BLDJOBENT, entry number 550 submitted to queue SYS$BATCH
Job VDEBUILD_0001 (queue CLUSTER_BATCH, entry 550) started on PHI_BATCH
%VDE-I-BLDJOBSTARTED, build job 15 for stream V2.0-3 started with 2 processes
VDE„
|
This command starts the most recent build job for the default development stream, in this case, build job 15 for stream V2.0-3. Two batch processes are submitted, one to batch queue FOO_BATCH and one to queue PHI_BATCH.
| #2 |
|---|
VDE„ START BUILD_JOB V5.3/AFTER=15:00/PROCESS_COUNT=1/QUEUE=SYS$BATCH
%VDE-I-BLDJOBSIZ, build job 12 for stream V5.3 consists of 2 steps
%VDE-I-BLDJOBSTARTING, starting build job 12 for stream V5.3
%VDE-I-BLDJOBAFTER, build job to be started after 12-JUL-1989 15:00:00.00
%VDE-I-BLDJOBENT, entry number 583 submitted to queue SYS$BATCH
Job VDEBUILD_0001 (queue FOO_BATCH, entry 583) holding until 12-JUL-1989 15:00
%VDE-I-BLDJOBSTARTED, build job 12 for stream V5.3 started with 1 processes
VDE„
|
This example starts the most recent build job (build job 12) for stream V5.3. The /AFTER qualifier specifies that the batch job starts after 15:00 hours (3:00 pm) of the current day. The /PROCESS_COUNT and /QUEUE qualifiers specify that a single batch job is submitted to queue SYS$BATCH to run the build job. The log messages show that this happened as requested.
Stops the execution of an existing build job. A stopped build job cannot be restarted.
STOP BUILD_JOB [stream-name [, stream-name...]]
stream-name
The name of a development stream. The most recent build job for this stream is stopped.You can stop build jobs for more than one stream by using wildcard characters in the stream name. The percent sign (%) in a name matches any single character in the position it occupies and the asterisk (*) matches zero or more characters in the position it occupies. Build jobs are stopped for those streams whose names match the wildcard pattern.
If you omit the stream-name parameter, VDE stops the most recent build job for the default stream.
The STOP BUILD_JOB command stops the most recently created build job for each stream that matches a specified stream name. When a build job is stopped, it is marked as stopped in the database. Any processes executing the build job stop executing as soon as they read the new job status from the database. This command stops a build job permanently: it can never be restarted. Use the STOP BUILD_JOB command to stop a running build job or to mark an existing build job as stopped (even if it has never been started). After the most recent build job for a stream is stopped, you are free to create a new build job for that stream because the stopped job cannot execute and interfere with the new job.You cannot stop a build job that has already been stopped or that has already completed execution. Because such jobs cannot execute again, there is no need to stop them.
/CONFIRM
/NOCONFIRM (default)
Controls whether VDE asks you to confirm that you want each build job stopped. The /CONFIRM qualifier causes VDE to print a message for each build job asking whether you want that build job stopped. If you answer YES (or Y), the build job is stopped. If you answer NO (or N), the build job is not stopped. The /NOCONFIRM qualifier causes VDE to stop the specified build jobs without asking for confirmation./LOG (default)
/NOLOG
Controls whether log messages are printed after each build job is stopped. The /LOG qualifier causes such messages to be printed and the /NOLOG qualifier suppresses them. These messages indicate that the build job has been stopped and that the database transaction has successfully committed.
| #1 |
|---|
VDE„ STOP BUILD_JOB
%VDE-I-BLDJOBSTOP, build job 15 for stream V2.0-3 stopped
VDE„
|
This command stops the most recent build job for the default development stream. In this case, the default stream is V2.0-3 and its most recent build job is build job 15.
| #2 |
|---|
VDE„ STOP BUILD_JOB V5.3
%VDE-I-BLDJOBSTOP, build job 12 for stream V5.3 stopped
VDE„
|
This command stops the most recent build job for specified stream V5.3.
Stops the subprocess that VDE uses to execute the DCL command files it generates from VDE scripts. VDE automatically terminates this subprocess when you exit from VDE (or from the VDE kept subprocess), but this command allows you to explicitly terminate the script subprocess in order to reduce the number of open subprocesses you have.
STOP SUBPROCESS
None.
None.
| #1 |
|---|
VDE„ STOP SUBPROCESS
|
This command stops the subprocess VDE uses to execute DCL command files generated by VDE scripts.
Suspends the execution of an existing build job. A suspended build job can be restarted.
SUSPEND BUILD_JOB [stream-name [, stream-name...]]
stream-name
The name of a development stream. The most recent build job for this stream is suspended.You can suspend build jobs for more than one stream by using wildcard characters in the stream name. The percent sign (%) in a name matches any single character in the position it occupies and the asterisk (*) matches zero or more characters in the position it occupies. Build jobs are suspended for those streams whose names match the wildcard pattern.
If you omit the stream-name parameter, VDE suspends the most recent build job for the default stream.
The SUSPEND BUILD_JOB command suspends the most recently created build job for each stream that matches a specified stream name. When a build job is suspended, it is marked as suspended in the database. Any processes executing the build job stop executing as soon as they read the new job status from the database. A suspended build job is not permanently stopped, however: it can be restarted with a START BUILD_JOB command. Use the SUSPEND BUILD_JOB command to temporarily stop a running build job; you can restart the suspended job later or restart it on different batch queues. You should also suspend a build job if one of the nodes it is running on fails; suspending a build job and then restarting it allows the build steps that were running on the failed node to reexecute.You can only suspend a build job that is currently queued for execution or running. There is no need to suspend a build job that has not yet been started or that has completed execution.
/CONFIRM
/NOCONFIRM (default)
Controls whether VDE asks you to confirm that you want each build job suspended. The /CONFIRM qualifier causes VDE to print a message for each build job asking whether you want that build job suspended. If you answer YES (or Y), the build job is suspended. If you answer NO (or N), the build job is not suspended. The /NOCONFIRM qualifier causes VDE to suspend the specified build jobs without asking for confirmation./LOG (default)
/NOLOG
Controls whether log messages are printed after each build job is suspended. The /LOG qualifier causes such messages to be printed and the /NOLOG qualifier suppresses them. These messages indicate that the build job is suspended and that the database transaction has successfully committed.
| #1 |
|---|
VDE„ SUSPEND BUILD_JOB
%VDE-I-BLDJOBSUSP, build job 15 for stream V2.0-3 suspended
VDE„
|
This command suspends the most recent build job for the default development stream, in this case, build job 15 for stream V2.0-3.
| #2 |
|---|
VDE„ SUSPEND BUILD_JOB V5.3
%VDE-I-BLDJOBSUSP, build job 12 for stream V5.3 suspended
VDE„
|
This command suspends the most recent build job for stream V5.3. The stream name is specified in this example.
Cancels one or more module reservations in the default development stream.
UNRESERVE mod-name [, mod-name...]
mod-name
Specifies one or more source modules whose reservations are to be canceled. The module name consists of an optional facility name enclosed in square brackets, a module name, and an optional type name preceded by a period (such as [FACIL]MOD1.MAR). If the facility name is omitted, the module is assumed to belong to the default facility. If the type name is omitted, all source modules with the specified module name in the given facility are unreserved.You can cancel reservations for more than one module using wildcard characters in any of the three components of the module name. The percent sign (%) in a name matches any single character in the position it occupies and the asterisk (*) matches zero or more characters in the position it occupies. The source modules whose names match the wildcard pattern are unreserved.
You can also unreserve multiple modules by specifying the name of a source group instead of a module name. Source groups are created with the CREATE GROUP command. If you specify a group name, each module that is a member of the group is unreserved.
The UNRESERVE command cancels an existing reservation for each specified module. Each module must be a source module currently reserved with the RESERVE command. The module reservation is canceled only for the default development stream.If you have more than one reservation of a module, you must specify the exact reservation to be replaced. You do this by using the /IDENTIFICATION qualifier. Use the SHOW RESERVATION command to determine the identification of each reservation.
To cancel another user's reservation, you must use the /USERNAME qualifier to specify the OpenVMS username of that other user. You must have the USERNAME privilege to use the /USERNAME qualifier.
Reservations created by the CREATE MODULE command cannot be canceled with the UNRESERVE command. To cancel the reservation(s) and delete these module(s), use the DELETE MODULE command.
/CONFIRM
/NOCONFIRM (default)
Controls whether VDE asks you to confirm that you want each module unreserved. The /CONFIRM qualifier causes VDE to print a message for each module that you specify asking whether you want to unreserve that module. If you answer YES (or Y), the reservation is canceled. If you answer NO (or N), the reservation is not canceled. The /NOCONFIRM qualifier causes VDE to unreserve each specified module without asking for confirmation./IDENTIFICATION=res-ident
Specifies the reservation that is canceled. This qualifier is required when you have multiple reservations of the same module in the default stream. The res-ident parameter is the reservation identifier of the reservation to be replaced. The reservation identifier is a small integer value or the identifier you specified when reserving the module. Use the SHOW RESERVATION command to determine the reservation identifier of each reservation./LOG (default)
/NOLOG
Controls whether log messages are printed after each module is unreserved. The /LOG qualifier causes the messages to be printed and the /NOLOG qualifier suppresses them. The messages indicate that each module has been unreserved and that the database transaction has successfully committed./SESSION=session-name
Sessions are used to logically group a set of module reservations together, typically to group all modules related to a particular source code alteration or enhancement together. It allows all component modules reserved to be treated as a single entity for subsequent replacement operations. A session also allows additional modules to be reserved and incorporated into an existing session at a later time.The /SESSION qualifier causes all module reservations comprising the session-name reservation session are canceled, and that the session be deleted from the VDE database. If you specify this qualifier, you cannot specify mod-name parameters on the UNRESERVE command.
Sessions can be manipulated via the REPLACE, RESERVE, UNRESERVE, MODIFY SESSION, MODIFY RESERVATION, CREATE MODULE, and CANCEL SESSION commands. And modules created by CREATE MODULE (on a queued-replacement stream) and reserved via RESERVE can be combined into the same session.
/STREAM=stream-name
Specifies that the modules be unreserved from the development stream given by the stream-name parameter. If this qualifier is omitted, the modules are unreserved from the default development stream. If this qualifier is omitted and no default stream is defined, VDE prompts you for the stream name./USERNAME=username
Specifies that another user's reservation is to be canceled. The username parameter is the OpenVMS username of the other user. You must have the USERNAME privilege to use this qualifier.
| #1 |
|---|
VDE„ UNRESERVE [FACIL]FOO.MAR
%VDE-I-UNRESERVED, reservation for module [FACIL]FOO.MAR canceled
%VDE-I-COMMIT, database transaction has successfully committed
VDE„
|
This example cancels an existing reservation for module FOO.MAR in facility FACIL. The log messages show that the reservation was successfully canceled.
| #2 |
|---|
VDE„ UNRESERVE MOD1
%VDE-I-UNRESERVED, reservation for module [COPY]MOD1.PAS canceled
%VDE-I-COMMIT, database transaction has successfully committed
VDE„
|
This command cancels the reservations for all source modules called MOD1 in the current default facility, COPY. Because there is only one such module, MOD1.PAS, the reservation for that module is canceled.
| #3 |
|---|
VDE„ UNRESERVE/IDENTIFICATION=2/CONFIRM FOO.MAR
Unreserve module [FACIL]FOO.MAR ? [No]: YES
%VDE-I-UNRESERVED, reservation for module [FACIL]FOO.MAR canceled
%VDE-I-COMMIT, database transaction has successfully committed
|
In this example, reservation 2 of module FOO.MAR in the current default facility is canceled. The /IDENTIFICATION qualifier is required if you have more than one reservation of the same module at the same time. The /CONFIRM qualifier causes VDE to ask for confirmation before unreserving the module. In this case, the user answers "YES", and the reservation is canceled.
Verifies that a specified set of module generations exist in the corresponding CMS libraries and optionally recovers any missing generations. This command thus ensures that CMS libraries within the VDE library are consistent with the contents of the VDE database.
VERIFY GENERATION mod-name [, mod-name...]
mod-name
The name of a module whose generations are to be verified. The module name consists of an optional facility name enclosed in square brackets, a module name, and an optional type name preceded by a period. An example is [FACIL]MOD1.PAS. If no facility name is specified, the default facility is assumed. If no type name is specified, all modules with the specified module name in the given facility are verified.You can verify generations for more than one module by using wildcard characters in any of the three components of the module name. The percent sign (%) in a name matches any single character in the position it occupies and the asterisk (*) matches zero or more characters in the position it occupies. Generations for those modules whose names match the wildcard pattern are verified.
If you omit the mod-name parameter, VDE verifies generations for all modules in the default facility.
The VERIFY GENERATION command verifies that the generations you specify actually exist in the CMS libraries belonging to your VDE library. This command should be used if there is reason to think that one or more CMS libraries in the VDE library may not be consistent with the VDE database. Such a situation can arise any time you have had to restore the VDE library's database from back-up files or its CMS libraries from back-up tapes. Provided you have enabled journalling, the VDE database can be fully recovered after a failure up to and including the last completed database transaction before the failure. However, the contents of the associated CMS libraries cannot be recovered past the last available back-up. If you back up your disks daily, the CMS libraries may thus be as much as a day out of date. As a result, the CMS libraries may be missing generations created by REPLACE or PERFORM REPLACEMENT commands that were entered after that last back-up, while the VDE database contains up-to-date information about those generations.The VERIFY GENERATION command therefore assumes that the VDE database contains correct information about what generations should be found in the CMS libraries for your VDE library. If it finds any differences between the generations that the database says ought to exist and the generations that actually exist in the CMS libraries, VDE prints a message for each such generation. Optionally, VDE can also print a message for each generation that was correctly found.
If you specify the /RECOVER qualifier, the VERIFY GENERATION command will attempt to recover any missing generations. If the missing generations were created by REPLACE commands and if the replacements were queued, VDE retrieves the text of each missing generation from the staging area for the queued replacement that created the generation. The retrieved text is then inserted into the CMS library. For immediate replacements, VDE does not maintain staging areas, but if you have a file that contains the text of a missing generation, you can specify that the missing generation be recovered from that file. Using either the VDE staging areas or files you explicitly specify, the /RECOVER qualifier thus allows you to repair any inconsistencies between the VDE database and its CMS libraries.
The VERIFY GENERATION command is usually used with wildcard characters in the module name parameters because you normally want to verify all generations in a specific facility (if the CMS library for that facility was restored from a back-up tape) or all generations for all facilities (if your whole disk was restored). To speed up the verification, you can use the /SINCE qualifier to verify and recover only those generations created since the back-up date for the CMS libraries.
/GENERATION=gen-expr
Specifies that the generation with the CMS generation expression given by the gen-expr parameter be verified. When you use this qualifier, you would normally not use wildcard characters in the module name parameter. If you specify an asterisk (*) for the gen-expr parameter or if you omit the entire qualifier, VDE verifies all generations for each specified module./LOG
/NOLOG (default)
Controls whether log messages are printed for successfully verified generations. The /LOG qualifier causes such messages to be printed and /NOLOG suppresses them. The log messages for generations that are not successfully verified are always printed and are not affected by these qualifiers./OUTPUT=file-spec
Directs the printed output of this command to a specified file. The file-spec parameter specifies the name of the file. VDE creates a new file with that name, directs the command's print output to that file, and prints nothing on your terminal. If this qualifier is omitted, all output appears on the terminal./RECOVER[=file-spec]
Specifies that each generation that is found in the VDE database but is missing in the corresponding CMS library should be recovered into the CMS library. If you omit the file-spec parameter, VDE recovers each missing generation by taking its text from the staging area for the queued replacement that created the generation, provided such a staging area exists. You should omit the file-spec parameter when you want to recover all missing generations for a given set of facilities and those generations are available from staging areas.If you specify the file-spec parameter, VDE recovers each missing generation by taking its text from the file specified by that parameter. If the parameter specifies a directory name without a file name, VDE assumes that the file has the same name as the module being recovered. When you use the file-spec parameter, you would normally also use the /GENERATION qualifier to identify the specific generation to recover and you would omit wildcard characters in the module name parameter. You should use the file-spec parameter when you want to recover an individual module generation that cannot be found in VDE's staging areas.
This qualifier requires the PERFREP privilege.
/SINCE=date-time
Verifies (and if requested, recovers) only those generations created on or after the specified date and time. The date and time can be stated in the standard OpenVMS date-time format or can be one of the following keywords: YESTERDAY, TODAY, or TOMORROW. If you use a space to separate the date from the time, remember to enclose the entire date-time string in double quotes. For further information about specifying OpenVMS date-time format, see the OpenVMS DCL Concepts.
| #1 |
|---|
VDE„ VERIFY GENERATION [FACIL]*/LOG
%VDE-I-GENFOUNDCMS, generation [FACIL]A.REQ;1(1) found in CMS library
%VDE-I-GENFOUNDCMS, generation [FACIL]A.REQ;2(1A1) found in CMS library
%VDE-I-GENFOUNDCMS, generation [FACIL]A.REQ;2(2) found in CMS library
%VDE-I-GENFOUNDCMS, generation [FACIL]B.REQ;1(1) found in CMS library
%VDE-I-GENNOTFOUNDCMS, generation [FACIL]B.REQ;2(2) not found in CMS library
%VDE-I-ELENOTFOUNDCMS, element [FACIL]C.B32;1(1) not found in CMS library
%VDE-I-GENFOUNDCMS, generation [FACIL]D.B32;1(1) found in CMS library
%VDE-I-GENFOUNDCMS, generation [FACIL]E.B32;1(1) found in CMS library
%VDE-I-GENFOUNDCMS, generation [FACIL]F.B32;1(1) found in CMS library
Summary statistics:
Number of generations successfully verified: 7
Number of CMS elements not found: 1
Number of CMS generations not found: 1
Total number of generations scanned: 9
VDE„
|
This example verifies all generations in facility FACIL to make sure that each such generation is found in the CMS library for that facility. The /LOG qualifier causes VDE to print log messages for the generations that are successfully verified as well as those that are missing. In this case, generation 2 of B.REQ is not found in the CMS library and the whole CMS element for module C.B32 is missing. The summary statistics indicate that seven generations were successfully verified and two were not.
| #2 |
|---|
VDE„ VERIFY GENERATION/SINCE=TODAY/RECOVER [*]*
%VDE-I-GENNOTFOUNDCMS, generation [FACIL]B.REQ;2(2) not found in CMS library
%VDE-I-GENRECOVERED, generation [FACIL]B.REQ;2(2) successfully recovered
from DISK$:[LIBDIR.VDE$STAGE.VDE$STG_0.VDE$REP_3.FACIL]B.REQ;
%VDE-I-ELENOTFOUNDCMS, element [FACIL]C.B32;1(1) not found in CMS library
%VDE-I-GENNOTRECOVERED, generation [FACIL]C.B32;1(1) not recovered
-VDE-I-GENNOTQUEREPL, replacement was not queued; no staging area exists
Summary statistics:
Number of generations successfully verified: 7
Number of CMS elements not found: 1
Number of CMS generations not found: 1
Total number of generations scanned: 9
Number of generations recovered: 1
Number of generations not recovered: 1
VDE„
|
Previous Next Contents Index