Previous[ | Contents] | Index |
AIf you also use the /PROCESS_COUNT qualifier, the /PROCESS_COUNT Gqualifier states the total number of build-job processes to create. In .that case, the process-counts attached to the Hqueue-name parameters on the /QUEUE qualifier are used Cas scaling factors to distribute the build-job processes among the Dqueues proportionally. For example, if you specify queues HI_BATCH, GHO_BATCH(3) and a total process count of eight, then two processes are Hsubmitted to queue HI_BATCH and six processes to queue HO_BATCH. If the Gtotal process count does not divide evenly into the sum of the scaling Dfactors, the remaining processes are allocated to the queues in the Eorder the queues are listed. If the total process count is nine, for Fexample, the one extra process is allocated to queue HI_BATCH because HI_BATCH is listed first.
6
#1 |
---|
VDEä START BUILD_JOBE%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$BATCHJ Job VDEBUILD_0001 (queue CLUSTER_BATCH, entry 549) started on FOO_BATCH?%VDE-I-BLDJOBENT, entry number 550 submitted to queue SYS$BATCHJ Job VDEBUILD_0001 (queue CLUSTER_BATCH, entry 550) started on PHI_BATCHM%VDE-I-BLDJOBSTARTED, build job 15 for stream V2.0-3 started with 2 processesVDEä |
6>This command starts the most recent build job for the default Fdevelopment stream, in this case, build job 15 for stream V2.0-3. Two Gbatch processes are submitted, one to batch queue FOO_BATCH and one to queue PHI_BATCH.
#2 |
---|
EVDEä START BUILD_JOB V5.3/AFTER=15:00/PROCESS_COUNT=1/QUEUE=SYS$BATCHB%VDE-I-BLDJOBSIZ, build job 12 for stream V5.3 consists of 2 steps<%VDE-I-BLDJOBSTARTING, starting build job 12 for stream V5.3I%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$BATCHQ Job VDEBUILD_0001 (queue FOO_BATCH, entry 583) holding until 12-JUL-1989 15:00K%VDE-I-BLDJOBSTARTED, build job 12 for stream V5.3 started with 1 processesVDEä |
HThis example starts the most recent build job (build job 12) for stream EV5.3. The /AFTER qualifier specifies that the batch job starts after H15:00 hours (3:00 pm) of the current day. The /PROCESS_COUNT and /QUEUE Aqualifiers 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.
BStops the execution of an existing build job. A stopped build job cannot be restarted.
9STOP BUILD_JOB [stream-name [, stream-name...]]
stream-name
EThe name of a development stream. The most recent build job for this stream is stopped.CYou can stop build jobs for more than one stream by using wildcard Fcharacters in the stream name. The percent sign (%) in a name matches Fany single character in the position it occupies and the asterisk (*) Hmatches zero or more characters in the position it occupies. Build jobs Eare stopped for those streams whose names match the wildcard pattern.
<If you omit the stream-name parameter, VDE 7stops the most recent build job for the default stream.
EThe STOP BUILD_JOB command stops the most recently created build job Gfor each stream that matches a specified stream name. When a build job Cis stopped, it is marked as stopped in the database. Any processes Hexecuting the build job stop executing as soon as they read the new job Fstatus from the database. This command stops a build job permanently: Dit can never be restarted. Use the STOP BUILD_JOB command to stop a Grunning build job or to mark an existing build job as stopped (even if Bit has never been started). After the most recent build job for a Cstream is stopped, you are free to create a new build job for that Estream because the stopped job cannot execute and interfere with the new job.FYou cannot stop a build job that has already been stopped or that has Ealready 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 8build job stopped. The /CONFIRM qualifier causes VDE to Fprint a message for each build job asking whether you want that build Hjob 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 6qualifier causes VDE to stop the specified build jobs without asking for confirmation./LOG (default)
/NOLOG
BControls whether log messages are printed after each build job is Gstopped. The /LOG qualifier causes such messages to be printed and the C/NOLOG qualifier suppresses them. These messages indicate that the Abuild job has been stopped and that the database transaction has successfully committed.
6
#1 |
---|
VDEä STOP BUILD_JOB9%VDE-I-BLDJOBSTOP, build job 15 for stream V2.0-3 stoppedVDEä |
6=This command stops the most recent build job for the default Gdevelopment 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.37%VDE-I-BLDJOBSTOP, build job 12 for stream V5.3 stoppedVDEä |
GThis command stops the most recent build job for specified stream V5.3.
6Stops the subprocess that VDE uses to execute the DCL 1command files it generates from VDE scripts. VDE <automatically terminates this subprocess when you exit from 0VDE (or from the VDE kept subprocess), but this Dcommand allows you to explicitly terminate the script subprocess in 9order to reduce the number of open subprocesses you have.
STOP SUBPROCESS
None.
None.
6
#1 |
---|
VDEä STOP SUBPROCESS |
:This command stops the subprocess VDE uses to execute DCL 'command files generated by VDE scripts.
GSuspends the execution of an existing build job. A suspended build job can be restarted.
<SUSPEND BUILD_JOB [stream-name [, stream-name...]]
stream-name
EThe name of a development stream. The most recent build job for this stream is suspended.FYou can suspend build jobs for more than one stream by using wildcard Fcharacters in the stream name. The percent sign (%) in a name matches Fany single character in the position it occupies and the asterisk (*) Hmatches zero or more characters in the position it occupies. Build jobs Gare 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.
GThe SUSPEND BUILD_JOB command suspends the most recently created build Gjob for each stream that matches a specified stream name. When a build Ajob is suspended, it is marked as suspended in the database. Any Fprocesses executing the build job stop executing as soon as they read Cthe new job status from the database. A suspended build job is not ?permanently stopped, however: it can be restarted with a START DBUILD_JOB command. Use the SUSPEND BUILD_JOB command to temporarily Estop a running build job; you can restart the suspended job later or Frestart it on different batch queues. You should also suspend a build Gjob if one of the nodes it is running on fails; suspending a build job Gand then restarting it allows the build steps that were running on the failed node to reexecute.HYou can only suspend a build job that is currently queued for execution Eor 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 Fprint a message for each build job asking whether you want that build Hjob suspended. If you answer YES (or Y), the build job is suspended. If Eyou answer NO (or N), the build job is not suspended. The /NOCONFIRM 9qualifier causes VDE to suspend the specified build jobs without asking for confirmation./LOG (default)
/NOLOG
BControls whether log messages are printed after each build job is Esuspended. The /LOG qualifier causes such messages to be printed and Gthe /NOLOG qualifier suppresses them. These messages indicate that the =build job is suspended and that the database transaction has successfully committed.
6
#1 |
---|
VDEä SUSPEND BUILD_JOB;%VDE-I-BLDJOBSUSP, build job 15 for stream V2.0-3 suspendedVDEä |
6@This command suspends the most recent build job for the default Adevelopment stream, in this case, build job 15 for stream V2.0-3.
#2 |
---|
VDEä SUSPEND BUILD_JOB V5.39%VDE-I-BLDJOBSUSP, build job 12 for stream V5.3 suspendedVDEä |
EThis command suspends the most recent build job for stream V5.3. The )stream name is specified in this example.
CCancels one or more module reservations in the default development stream.
,UNRESERVE mod-name [, mod-name...]
mod-name
BSpecifies one or more source modules whose reservations are to be @canceled. The module name consists of an optional facility name Fenclosed in square brackets, a module name, and an optional type name Hpreceded by a period (such as [FACIL]MOD1.MAR). If the facility name is Eomitted, the module is assumed to belong to the default facility. If Gthe type name is omitted, all source modules with the specified module *name in the given facility are unreserved.DYou can cancel reservations for more than one module using wildcard Bcharacters in any of the three components of the module name. The Hpercent sign (%) in a name matches any single character in the position Hit occupies and the asterisk (*) matches zero or more characters in the Hposition it occupies. The source modules whose names match the wildcard pattern are unreserved.
DYou can also unreserve multiple modules by specifying the name of a Fsource group instead of a module name. Source groups are created with Hthe 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 Freserved with the RESERVE command. The module reservation is canceled (only for the default development stream.HIf 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 1determine the identification of each reservation.
ATo cancel another user's reservation, you must use the /USERNAME >qualifier to specify the OpenVMS username of that other user. DYou must have the USERNAME privilege to use the /USERNAME qualifier.
EReservations created by the CREATE MODULE command cannot be Fcanceled with the UNRESERVE command. To cancel the reservation(s) and 6delete these module(s), use the DELETE MODULE command.
/CONFIRM
/NOCONFIRM (default)
<Controls whether VDE asks you to confirm that you want each 8module unreserved. The /CONFIRM qualifier causes VDE to Dprint a message for each module that you specify asking whether you =want to unreserve that module. If you answer YES (or Y), the Ereservation is canceled. If you answer NO (or N), the reservation is 5not canceled. The /NOCONFIRM qualifier causes VDE to @unreserve each specified module without asking for confirmation."/IDENTIFICATION=res-ident
GSpecifies the reservation that is canceled. This qualifier is required Fwhen you have multiple reservations of the same module in the default Dstream. The res-ident parameter is the reservation >identifier of the reservation to be replaced. The reservation Didentifier is a small integer value or the identifier you specified ?when reserving the module. Use the SHOW RESERVATION command to 9determine the reservation identifier of each reservation./LOG (default)
/NOLOG
?Controls whether log messages are printed after each module is Eunreserved. The /LOG qualifier causes the messages to be printed and Fthe /NOLOG qualifier suppresses them. The messages indicate that each Amodule has been unreserved and that the database transaction has successfully committed./SESSION=session-name
BSessions are used to logically group a set of module reservations Htogether, typically to group all modules related to a particular source Acode alteration or enhancement together. It allows all component Amodules reserved to be treated as a single entity for subsequent Greplacement operations. A session also allows additional modules to be Creserved and incorporated into an existing session at a later time.EThe /SESSION qualifier causes all module reservations comprising the Dsession-name reservation session are canceled, and :that the session be deleted from the VDE database. If you Especify this qualifier, you cannot specify mod-name $parameters on the UNRESERVE command.
HSessions can be manipulated via the REPLACE, RESERVE, UNRESERVE, MODIFY ?SESSION, MODIFY RESERVATION, CREATE MODULE, and CANCEL SESSION Hcommands. And modules created by CREATE MODULE (on a queued-replacement Gstream) and reserved via RESERVE can be combined into the same session.
/STREAM=stream-name
ESpecifies that the modules be unreserved from the development stream Ggiven by the stream-name parameter. If this qualifier Dis omitted, the modules are unreserved from the default development Gstream. If this qualifier is omitted and no default stream is defined, $VDE prompts you for the stream name./USERNAME=username
ASpecifies that another user's reservation is to be canceled. The ?username parameter is the OpenVMS username of Athe other user. You must have the USERNAME privilege to use this qualifier.
6
#1 |
---|
VDEä UNRESERVE [FACIL]FOO.MARA%VDE-I-UNRESERVED, reservation for module [FACIL]FOO.MAR canceled>%VDE-I-COMMIT, database transaction has successfully committedVDEä |
6CThis 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 MOD1A%VDE-I-UNRESERVED, reservation for module [COPY]MOD1.PAS canceled>%VDE-I-COMMIT, database transaction has successfully committedVDEä |
6DThis command cancels the reservations for all source modules called FMOD1 in the current default facility, COPY. Because there is only one Csuch module, MOD1.PAS, the reservation for that module is canceled.
#3 |
---|
/VDEä UNRESERVE/IDENTIFICATION=2/CONFIRM FOO.MAR+Unreserve module [FACIL]FOO.MAR ? [No]: YESA%VDE-I-UNRESERVED, reservation for module [FACIL]FOO.MAR canceled>%VDE-I-COMMIT, database transaction has successfully committed |
HIn this example, reservation 2 of module FOO.MAR in the current default Gfacility is canceled. The /IDENTIFICATION qualifier is required if you Hhave more than one reservation of the same module at the same time. The =/CONFIRM qualifier causes VDE to ask for confirmation before Hunreserving the module. In this case, the user answers "YES", and the reservation is canceled.
AVerifies that a specified set of module generations exist in the ?corresponding CMS libraries and optionally recovers any missingEgenerations. This command thus ensures that CMS libraries within the 4VDE library are consistent with the contents of the VDE database.
4VERIFY GENERATION mod-name [, mod-name...]
mod-name
FThe name of a module whose generations are to be verified. The module Hname consists of an optional facility name enclosed in square brackets, Ba module name, and an optional type name preceded by a period. An Bexample is [FACIL]MOD1.PAS. If no facility name is specified, the Gdefault facility is assumed. If no type name is specified, all modules Bwith the specified module name in the given facility are verified.FYou can verify generations for more than one module by using wildcard Bcharacters in any of the three components of the module name. The Hpercent sign (%) in a name matches any single character in the position Hit occupies and the asterisk (*) matches zero or more characters in the Fposition it occupies. Generations for those modules whose names match "the wildcard pattern are verified.
9If you omit the mod-name parameter, VDE =verifies generations for all modules in the default facility.
HThe VERIFY GENERATION command verifies that the generations you specify :actually exist in the CMS libraries belonging to your VDE library. ThisHcommand 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-up6tapes. Provided you have enabled journalling, the VDE Hdatabase can be fully recovered after a failure up to and including the Elast completed database transaction before the failure. However, the Fcontents of the associated CMS libraries cannot be recovered past the Alast available back-up. If you back up your disks daily, the CMS Elibraries may thus be as much as a day out of date. As a result, the GCMS libraries may be missing generations created by REPLACE or PERFORM FREPLACEMENT 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 Gdatabase contains correct information about what generations should be =found in the CMS libraries for your VDE library. If it finds Hany differences between the generations that the database says ought to Dexist 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.
EIf you specify the /RECOVER qualifier, the VERIFY GENERATION command @will attempt to recover any missing generations. If the missing Egenerations were created by REPLACE commands and if the replacements 4were queued, VDE retrieves the text of each missing Ageneration from the staging area for the queued replacement that created the generation.HThe retrieved text is then inserted into the CMS library. For immediate :replacements, VDE does not maintain staging areas, but if Hyou have a file that contains the text of a missing generation, you can Gspecify that the missing generation be recovered from that file. Using 5either the VDE staging areas or files you explicitly >specify, the /RECOVER qualifier thus allows you to repair any 5inconsistencies between the VDE database and its CMS libraries.
GThe VERIFY GENERATION command is usually used with wildcard characters Fin the module name parameters because you normally want to verify all @generations in a specific facility (if the CMS library for that Ffacility was restored from a back-up tape) or all generations for all >facilities (if your whole disk was restored). To speed up the Everification, you can use the /SINCE qualifier to verify and recover Bonly those generations created since the back-up date for the CMS libraries.
/GENERATION=gen-expr
GSpecifies that the generation with the CMS generation expression given Eby the gen-expr parameter be verified. When you use Fthis 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)
DControls whether log messages are printed for successfully verified Ggenerations. The /LOG qualifier causes such messages to be printed and F/NOLOG suppresses them. The log messages for generations that are not Gsuccessfully verified are always printed and are not affected by these qualifiers./OUTPUT=file-spec
DDirects the printed output of this command to a specified file. The Efile-spec parameter specifies the name of the file. =VDE creates a new file with that name, directs the command's Hprint output to that file, and prints nothing on your terminal. If this 9qualifier is omitted, all output appears on the terminal./RECOVER[=file-spec]
8Specifies that each generation that is found in the VDE Cdatabase but is missing in the corresponding CMS library should be recovered intoGthe 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 Egeneration, provided such a staging area exists. You should omit the Bfile-spec parameter when you want to recover all Hmissing generations for a given set of facilities and those generations !are available from staging areas.=If you specify the file-spec parameter, VDE Brecovers each missing generation by taking its text from the file Dspecified 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 Ffile-spec parameter, you would normally also use the E/GENERATION qualifier to identify the specific generation to recover Eand you would omit wildcard characters in the module name parameter. FYou should use the file-spec parameter when you want Cto recover an individual module generation that cannot be found in VDE's staging areas.
?This qualifier requires the PERFREP privilege.
/SINCE=date-time
HVerifies (and if requested, recovers) only those generations created on For 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 Ffollowing keywords: YESTERDAY, TODAY, or TOMORROW. If you use a space Cto separate the date from the time, remember to enclose the entire Adate-time string in double quotes. For further information about Bspecifying OpenVMS date-time format, see the OpenVMS DCL Concepts.
6
#1 |
---|
#VDEä VERIFY GENERATION [FACIL]*/LOGE%VDE-I-GENFOUNDCMS, generation [FACIL]A.REQ;1(1) found in CMS libraryG%VDE-I-GENFOUNDCMS, generation [FACIL]A.REQ;2(1A1) found in CMS libraryE%VDE-I-GENFOUNDCMS, generation [FACIL]A.REQ;2(2) found in CMS libraryE%VDE-I-GENFOUNDCMS, generation [FACIL]B.REQ;1(1) found in CMS libraryL%VDE-I-GENNOTFOUNDCMS, generation [FACIL]B.REQ;2(2) not found in CMS libraryI%VDE-I-ELENOTFOUNDCMS, element [FACIL]C.B32;1(1) not found in CMS libraryE%VDE-I-GENFOUNDCMS, generation [FACIL]D.B32;1(1) found in CMS libraryE%VDE-I-GENFOUNDCMS, generation [FACIL]E.B32;1(1) found in CMS libraryE%VDE-I-GENFOUNDCMS, generation [FACIL]F.B32;1(1) found in CMS library Summary statistics:7 Number of generations successfully verified: 77 Number of CMS elements not found: 17 Number of CMS generations not found: 17 Total number of generations scanned: 9 VDEä |
6EThis example verifies all generations in facility FACIL to make sure ?that each such generation is found in the CMS library for that facility. The8/LOG qualifier causes VDE to print log messages for the Egenerations that are successfully verified as well as those that are Emissing. In this case, generation 2 of B.REQ is not found in the CMS Clibrary and the whole CMS element for module C.B32 is missing. The Esummary statistics indicate that seven generations were successfully verified and two were not.
#2 |
---|
/VDEä VERIFY GENERATION/SINCE=TODAY/RECOVER [*]*L%VDE-I-GENNOTFOUNDCMS, generation [FACIL]B.REQ;2(2) not found in CMS libraryH%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;I%VDE-I-ELENOTFOUNDCMS, element [FACIL]C.B32;1(1) not found in CMS libraryB%VDE-I-GENNOTRECOVERED, generation [FACIL]C.B32;1(1) not recoveredH-VDE-I-GENNOTQUEREPL, replacement was not queued; no staging area exists Summary statistics:7 Number of generations successfully verified: 77 Number of CMS elements not found: 17 Number of CMS generations not found: 17 Total number of generations scanned: 97 Number of generations recovered: 17 Number of generations not recovered: 1 VDEä |
q
PreviousX Next[ Contents] Index