| Previous[ | Contents] | Index |
ETransfers control from your current process to the specified process.
ATTACH process-name
process-name
FSpecifies the parent process or a spawned subprocess to which control Ais to be passed. The process must already exist, be part of your Fcurrent job, and share the same input stream as your current process. CHowever, the process cannot be the current process or a subprocess #created with the /NOWAIT qualifier.FDo not specify the process-name parameter if you use the /IDENTIFICATION qualifier.
BThe ATTACH command allows you to quickly transfer control between Gprocesses. (For information about creating a subprocess, see the SPAWN Fcommand.) For example, you can transfer control from a parent process Gto a subprocess using the ATTACH command. Then, in the subprocess, you ;can start a build job using VDE and, after you finish, you Hcan enter the ATTACH command to move back to the parent process. If you Blater want to display the status of your build job, you can enter Eanother ATTACH command at DCL level (or from many utilities) to move 'back to the VDE subprocess you created.EDo not attempt to use the DCL ATTACH command to attach to a VDE kept subprocess.
/IDENTIFICATION=pid
CSpecifies the process identification (PID) of the process to which Fterminal control is transferred. Leading zeros can be omitted. Do not Fspecify the process-name parameter when you use this qualifier.
6
| #1 |
|---|
$ EDIT VACATION.TXT . . .[CTRL/Y] $ SPAWN VDE'%DCL-S-SPAWNED, process SMITH_1 spawned9%DCL-S-ATTACHED, terminal now attached to process SMITH_1VDEä BUILD GAME_PROGVDEä ATTACH SMITH2%DCL-S-RETURNED, control returned to process SMITH . . .[CTRL/Y]$ ATTACH SMITH_1VDEä |
AThis example shows how to spawn a subprocess (SMITH_1) to invoke 3VDE and use the ATTACH command to move between VDE G(SMITH_1) and the DCL command level (SMITH). The ATTACH command allows -you to transfer control between subprocesses.
/
Note
HUse the SPAWN command to create a new process and the ATTACH command to 1connect to a process that already exists.
ACreates and optionally starts a build job to build the specified Hmodules. The discrete steps performed during the build are derived from VDE scripts.
(BUILD mod-name [, mod-name...]
mod-name
BSpecifies a module or build group to be produced by the build job.BIf the parameter is a module name, it is typically the name of an Bexecutable image or another type of derived module that is the endFresult of a build operation. Each such module is a target of the build.
@The module name must consist of a module name and a module type Hseparated by a period (as in MODNAM.EXE) and may optionally be preceded =by a facility name enclosed in square brackets (for example, D[FACIL]MODNAM.EXE). If no facility name is specified, the module is *assumed to belong to the default facility.
GYou can build more than one target module by using wildcard characters Hin any of the three components of the module name. The percent sign (%) Gin a name matches any single character in the position it occupies and Dthe asterisk (*) matches zero or more characters in the position it 9occupies. VDE builds those modules whose names match the wildcard pattern.
HIf the mod-name parameter specifies a build group, the HBUILD command builds all modules that are members of the build group. A Gbuild-group name is a simple name that has been declared with a CREATE AGROUP/BUILD command. A build-group name may not contain wildcard characters.
GThe BUILD command performs two distinct operations: it creates a build ;job for the default development stream in the VDE database Band it optionally starts that build job on a set of OpenVMS batch queues.BTo create a build job in the database, the BUILD command does the following three things:
D
- First, the BUILD command determines the target modules to be 1 built. The target modules are specified by the 6 mod-name parameters of the command.A
- Next, the command determines the build steps that must be F performed to build those target modules. The needed build steps are 9 determined by the build dependencies stored in the VDE E database, by the modules that have changed since the last time the I targets were built, and by whether the user requests a full or minimal build.J
- Finally, the BUILD command records information about the new build G job in the database. The information specifies the build steps to be A performed, any constraints on the order in which the steps are I performed, and other attributes. (An example of an order constraint is G the requirement that a compile step must complete before a dependent link step starts.)
GThe build job is always created for the default development stream. It Cuses the build dependencies of the default stream to determine the Cbuild steps to perform and it uses module replacement data for the Ddefault stream to determine the modules that have changed since the Flast build. The build job is then identified by the stream name and a Gbuild-job identification number. For example, the second build job for Bstream V1.0 is labeled "build job 2 for stream V1.0" in VDE messages.
DYou cannot create a new build job for a given stream if a build job Galready exists for that stream and that existing build job has not yet Fcompleted execution. This restriction ensures that two build jobs for Hthe same stream do not execute at the same time. If you do not want the Cexisting build job to run, stop it with the STOP BUILD_JOB command "before creating the new build job.
GTo start a build job, the BUILD command submits one or more batch jobs @to the OpenVMS batch queues that the user specified either with Athe /QUEUE qualifier or by default. Then each batch job runs the 9VDE$BUILD utility that executes the build steps belongingGto the build job. The steps are executed in a loop until all the steps Gare done. The VDE$BUILD utility does the following for each build step:
F
- The program looks in the database for the next available build B step. (A build step, normally a compile, copy, or link step, is F available if it is not waiting for another step to complete.) If no H step is available, the program waits a few seconds before looking for another available build step.C
- When the program finds a build step to run, it looks up the ? VDE script for that step and, from the script, generates the F DCL commands needed to run the step. The program then sends the DCL G commands to a subprocess that executes the build step, and waits for the step to complete.D
- After the step completes, the program records the completion > status of the step in the database. A step completes either G successfully or with errors. If the step completes successfully, the J program updates the step's build dependency information in the database - and then looks for another step to perform.
<The BUILD command always creates a new build job in the VDE Cdatabase. It also starts the build job unless you use the /NOSTART Bqualifier or you answer NO to a query asking whether to start the Hbuild. If the BUILD command does not start the build job, you can start Bit later with the START BUILD_JOB command. After the build job is Fcreated (whether or not you start it), you can use the SHOW BUILD_JOB Fcommand to display the attributes of the build, including the size of Dthe build job and the exact build steps and build-step dependencies that make up the build job.
GYou can distribute the build job across several processors (whether in Ea single machine or in multiple machines in a cluster) by specifying ?the /QUEUE and /PROCESS_COUNT qualifiers. The /QUEUE qualifier Dspecifies the batch queues to run the build job. The /PROCESS_COUNT >qualifier specifies the total number of processes VDE submits Fto the batch queues performing the build job. By specifying the batch >queues and the number of processes VDE submits to each queue, Cyou can decide how to distribute the build job over a cluster with 2processors of different speeds and configurations.
>If you do not specify the /QUEUE or /PROCESS_COUNT qualifier, <VDE uses the default batch queues and process counts of the Gdefault development stream. You can establish these defaults using the G/QUEUE and /PROCESS_COUNT qualifiers with the CREATE STREAM and MODIFY >STREAM commands. If you have not specified such defaults, VDE 'submits one process to queue SYS$BATCH.
/AFTER=date-time
EIndicates the date and time at which the build job begins execution. >Specify the date and time using OpenVMS date-time syntax. Use Cthis qualifier only if the BUILD command starts the build job: the Hqualifier specifies the start time for each batch job that is submitted to execute the build job./CONFIRM
/NOCONFIRM (default)
;Controls whether VDE asks you to confirm that you want the >build job started. The /CONFIRM qualifier causes VDE to print Ga message asking whether you want to start the build job. This message <is displayed after VDE creates the build job and displays a Cmessage stating the size of the job. If you answer YES (or Y), the Dbuild job is started. If you answer NO (or N), the build job is not :started. The /NOCONFIRM qualifier causes VDE to start the Ebuild job without asking for confirmation. Neither qualifier has any Ceffect if you use the /NOSTART qualifier: /NOSTART unconditionally )prevents VDE from starting the build job./FULL
CDirects the BUILD command to perform a full build of your software Csystem. In a full build, all source modules that contribute to the Etarget modules you specified are compiled or otherwise processed. If Eyou do not specify the /FULL qualifier, the BUILD command performs a Dminimal system build, which means that only the source modules that Fhave changed since the last build of the specified target modules are Gcompiled or processed. A minimal build is normally much quicker than a ?full build because it performs only the minimal work needed to 4propagate your source changes to the target modules./LOG (default)
/NOLOG
AControls whether log messages are printed after the build job is Hcreated and submitted to batch queues for execution. The /LOG qualifier Gcauses such messages to be printed and the /NOLOG qualifier suppresses Hthem. These messages indicate that the build job has been created, that Dthe database transaction has successfully committed, and that batch Fjobs have been submitted to various batch queues to execute the build job."/PROCESS_COUNT=proc-count
<Specifies the number of processes to execute the build job. :VDE creates the processes by submitting batch jobs to the Fqueues specified by the /QUEUE qualifier or to the default queues for =the default stream. The number of processes that VDE creates :(that is, the number of OpenVMS batch jobs it submits) is Especified by the proc-count parameter. As a result, Fthis parameter determines the degree of parallelism for the build job.-/QUEUE=(queue-name [,queue-name...])
=Specifies the OpenVMS batch queues to which the build job is Dsubmitted. Each queue-name parameter specifies the Gname of one batch queue. The queue-name parameter may Eoptionally be followed by a process count in parentheses. This count Gspecifies the number of processes that are started on the queue to run @the build job. For example, SYS$BATCH(3) causes three build-job Fprocesses to be submitted to queue SYS$BATCH. If the process count is /omitted, one process is submitted to the queue.CIf you only specify one queue-name parameter, the parentheses may be omitted.
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 Fas scaling factors to distribute build-job processes among the queues =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.
/REMARK="string"
CSpecifies a remark string to be stored in the database for the new Gbuild job. The quoted remark string, which can be up to 132 characters Flong, may contain any explanatory remark about the build job that you want to store in the database./START (default)
/NOSTART
GControls whether the build job is started or not. The /START qualifier >starts the build job, which means that VDE submits batch jobs >to the appropriate OpenVMS batch queues. These batch jobs run Fprograms that execute all the build steps that make up the build job. >The /NOSTART qualifier prevents VDE from submitting the batch Ejobs. If you use the /NOSTART qualifier, you can start the build job 'later with the START BUILD_JOB command."/STEP_DELAY=time-interval
9Specifies the step-delay time interval used by VDE$BUILD.FVDE$BUILD is the program that executes the build steps belonging to a Cbuild job. If VDE$BUILD cannot find an available build step in the @database, the program waits the amount of time specified by the </STEP_DELAY qualifier before it looks in the database again.GWhen multiple processes run a build job, one process may be idle until Fa second process completes its current build step. In that situation, Cthe first process periodically looks in the database to see if the >second process has finished its step. The step-delay interval Ddetermines how often the first process looks in the database for an available step.
EUse the following syntax to denote the number of hours, minutes, and seconds in the interval:
"/STEP_DELAY=hh:mm:ss.ssGFor example, an interval of three and one half seconds is specified as follows:
GUsually the interval is set at a few seconds. If this qualifier is not ;specified, VDE uses the default step-delay interval of the Estream. If no default has been specified, the delay interval is five seconds.
")/STEP_DELAY=00:00:03.50/TIMEOUT=time-interval
DSpecifies the timeout interval for the build job. If no build steps :complete during this interval, the VDE$BUILD utility stopsDthe build job and assigns it TIMEOUT status. Therefore, the timeout Ginterval must be longer than the time required to complete the longest build step.FNormally, a build job only times out if a node that is running one of Bthe build-job processes fails. When a node fails, other build-job Hprocesses may be unable to proceed because they are waiting for a build Hstep that ran on the failed node to complete, which will not happen. In Bthat case, after the timeout interval expires, one of the waiting Fprocesses marks the build job as timed out, after which the remaining Dprocesses terminate themselves. You can later restart the build job "using the START BUILD_JOB command.
EUse the following syntax to denote the number of hours, minutes, and seconds in the interval:
"/TIMEOUT=hh:mm:ss.ssCFor example, an interval of two and one half hours is specified as follows:
HThe length of the timeout interval should be set based on the length of Bthe longest build step in the build job. If this qualifier is not 8specified, VDE uses the default timeout interval of the Fstream. If no default has been specified, the timeout interval is one hour.
"&/TIMEOUT=02:30:00.00
6
| #1 |
|---|
VDEä BUILD FOO.EXE>%VDE-I-BLDJOBCRE, build job 1 for stream BL22 has been createdA%VDE-I-BLDJOBSIZ, build job 1 for stream BL22 consists of 5 steps>%VDE-I-COMMIT, database transaction has successfully committed;%VDE-I-BLDJOBSTARTING, starting build job 1 for stream BL22?%VDE-I-BLDJOBENT, entry number 308 submitted to queue SYS$BATCHJ Job VDEBUILD_0001 (queue CLUSTER_BATCH, entry 308) started on PHI_BATCHJ%VDE-I-BLDJOBSTARTED, build job 1 for stream BL22 started with 1 processesVDEä |
6FThis example performs a minimal system build to build module FOO.EXE. DThe created build job is build job 1 for stream BL22. The build job Fconsists of five build steps, such as compile and link steps. Because Cthe /NOSTART qualifier is omitted, the build job is started on the Hdefault queue for the stream, SYS$BATCH. The build job runs on only one process.
| #2 |
|---|
VDEä BUILD/FULL/NOSTART BLDGRP>%VDE-I-BLDJOBCRE, build job 2 for stream BL22 has been createdC%VDE-I-BLDJOBSIZ, build job 2 for stream BL22 consists of 125 steps>%VDE-I-COMMIT, database transaction has successfully committedVDEä |
6GIn this example, build job 2 for the default stream, BL22, is created. HThis is a full build (not a minimal build) that builds all modules that Hare members of build group BLDGRP. This build requires 125 build steps. ?The build job is not started because the /NOSTART qualifier is Aspecified. (To start it later, use the START BUILD_JOB command.) HAlthough the build job is not started, it exists in the database so you Bcan display information about it using the SHOW BUILD_JOB command.
| #3 |
|---|
VDEä BUILD/PROCESS_COUNT=3 *.EXE@%VDE-I-BLDJOBCRE, build job 2 for stream V2.0-3 has been createdD%VDE-I-BLDJOBSIZ, build job 2 for stream V2.0-3 consists of 25 steps>%VDE-I-COMMIT, database transaction has successfully committed=%VDE-I-BLDJOBSTARTING, starting build job 2 for stream V2.0-3?%VDE-I-BLDJOBENT, entry number 317 submitted to queue SYS$BATCHJ Job VDEBUILD_0001 (queue CLUSTER_BATCH, entry 317) started on PHI_BATCH?%VDE-I-BLDJOBENT, entry number 318 submitted to queue SYS$BATCHJ Job VDEBUILD_0001 (queue CLUSTER_BATCH, entry 318) started on FOO_BATCH?%VDE-I-BLDJOBENT, entry number 319 submitted to queue SYS$BATCHJ Job VDEBUILD_0001 (queue CLUSTER_BATCH, entry 319) started on FUM_BATCHL%VDE-I-BLDJOBSTARTED, build job 2 for stream V2.0-3 started with 3 processesVDEä |
6GThis example creates and starts a build job that builds all executable @images for the default stream. It runs the build job with three Eparallel processes, all submitted to queue SYS$BATCH. The batch jobs Gexecute on three separate batch queues, in this case on separate nodes in a cluster.
| #4 |
|---|
9VDEä BUILD/QUEUE=(PHI_BATCH,FOO_BATCH(2),FUM_BATCH) *.EXE@%VDE-I-BLDJOBCRE, build job 3 for stream V2.0-3 has been createdD%VDE-I-BLDJOBSIZ, build job 3 for stream V2.0-3 consists of 25 steps>%VDE-I-COMMIT, database transaction has successfully committed=%VDE-I-BLDJOBSTARTING, starting build job 3 for stream V2.0-3?%VDE-I-BLDJOBENT, entry number 417 submitted to queue PHI_BATCHF Job VDEBUILD_0001 (queue PHI_BATCH, entry 417) started on PHI_BATCH?%VDE-I-BLDJOBENT, entry number 418 submitted to queue FOO_BATCHF Job VDEBUILD_0001 (queue FOO_BATCH, entry 418) started on FOO_BATCH?%VDE-I-BLDJOBENT, entry number 419 submitted to queue FOO_BATCHF Job VDEBUILD_0001 (queue FOO_BATCH, entry 419) started on FOO_BATCH?%VDE-I-BLDJOBENT, entry number 420 submitted to queue FUM_BATCHF Job VDEBUILD_0001 (queue FUM_BATCH, entry 420) started on FUM_BATCHL%VDE-I-BLDJOBSTARTED, build job 3 for stream V2.0-3 started with 4 processesVDEä |
6GLike the previous example, this example creates and starts a build job Fthat builds all executable images. In this case, the /QUEUE qualifier Aspecifies that four batch jobs are submitted: one to batch queue EPHI_BATCH, two to queue FOO_BATCH, and one to queue FUM_BATCH. These Hqueues belong to specific nodes in the cluster. As a result, the /QUEUE Gqualifier determines precisely how the build job is distributed across the nodes of the cluster.
| #5 |
|---|
VDEä BUILD/CONFIRM FOO.EXE>%VDE-I-BLDJOBCRE, build job 8 for stream BL22 has been createdA%VDE-I-BLDJOBSIZ, build job 8 for stream BL22 consists of 2 steps>%VDE-I-COMMIT, database transaction has successfully committed-Start build job 8 for stream BL22 ? [No]: YES;%VDE-I-BLDJOBSTARTING, starting build job 8 for stream BL22>%VDE-I-BLDJOBENT, entry number 79 submitted to queue SYS$BATCHI Job VDEBUILD_0001 (queue CLUSTER_BATCH, entry 79) started on PHI_BATCHJ%VDE-I-BLDJOBSTARTED, build job 8 for stream BL22 started with 1 processesVDEä |
=The /CONFIRM qualifier causes VDE to ask the user whether to >start the new build job. VDE asks the question after creating Gthe build job and after displaying its size (in this example, only two <steps). The user answers YES and VDE starts one process for !the build job on queue SYS$BATCH.
<Cancels a directory template in the VDE database. Directory ;templates determine what disk directories VDE creates when 0creating new development streams and facilities.
CANCEL DIRECTORY
FThe CANCEL DIRECTORY command deletes a "directory template" <from the VDE database. Directory templates are defined with 9the SET DIRECTORY command and specify the names that VDE Dshould assign to disk directories when creating directories for new 7development streams or facilities or for the library's Bqueued-replacement staging area. The CANCEL DIRECTORY command can Ddelete all templates that the SET DIRECTORY command can create. The FCANCEL DIRECTORY command does not delete or otherwise affect existing disk directories, however.FUnless the cancelled template is for the library's delta files or its Gstaging area, it is only cancelled for the default development stream. EBecause directory templates are inherited by a stream's descendants, Fthe CANCEL DIRECTORY command will affect the disk directories created Efor all future descendants of the default stream. It may also affect Athe directories created for new facilities in the default stream.
;When you have cancelled a directory template, VDE uses its Cdefault rules to create directory trees for subsequent streams and 5facilities. VDE always creates stream, facility, and Bdelta-file root directories, whether there are templates for such 1directories or not. VDE does not create facility Gsubdirectories unless there are templates for them, however, so if you Ccancel a subdirectory template, you prevent that subdirectory from ,being created for new streams or facilities.
CFor additional information on directory creation, and on directory Csymbols (dir-symbol) and directory symbol processing, see ╨SET DIRECTORY, SHOW DIRECTORY, and Script Functions.
/DELTA_FILES
/STAGING
/STREAM (default)
DSpecifies whether a directory template for delta files, the staging Carea, or the default stream is deleted. The /DELTA_FILES qualifier :specifies that a directory template for the VDE library's delta files (CMS libraries)@be deleted. The /STAGING qualifier specifies that the directory Ctemplate for the library's staging-area root directory be deleted. (Staging areasEhold files for queued replacements.) The /STREAM qualifier specifies <that a directory template for the default stream be deleted.AOf /DELTA_FILES, /STAGING and /STREAM, the latter is the default.
/FACILITY=fac-name
FSpecifies that a directory template for the facility specified by the Gfac-name parameter be deleted. If both this qualifier ;and the /SUBDIRECTORY qualifier are specified, VDE deletes Gthe directory template for the specified facility subdirectory. If the D/FACILITY qualifier is specified and the /SUBDIRECTORY qualifier is >omitted, VDE deletes the directory template for the specified facility's root directory.FIf the /FACILITY qualifier is omitted and the /SUBDIRECTORY qualifier 9is specified, VDE deletes the directory template for the Ggiven facility subdirectory for all facilities that are not explicitly Fspecified in other templates. If both the /FACILITY qualifier and the >/SUBDIRECTORY qualifier are omitted, VDE deletes the template ,for the stream or delta-file root directory.
CYou can delete more than one directory template at a time by using Dwildcard characters in the fac-name parameter. 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 Eposition it occupies. Directory templates for those facilities whose -names match the wildcard pattern are deleted.
/LOG (default)
/NOLOG
GControls whether log messages are printed after the directory template Fis deleted. The /LOG qualifier causes such messages to be printed and Gthe /NOLOG qualifier suppresses them. These messages indicate that the Cdirectory template has been deleted from the database and that the 0database transaction has completed successfully.!/SUBDIRECTORY=dir-symbol
CSpecifies that a directory template for a facility subdirectory be Adeleted. The dir-symbol parameter specifies the Edirectory symbol that identifies the subdirectory. Among other uses, the directory symbols is used within VDE scripts; see Script Keywords for further 8 details. If this qualifier is omitted, VDE deletes the ? directory template for a facility, stream, or delta-file root I directory. (The description of the /FACILITY qualifier explains how the 7 qualifiers interact to select the template to delete.)
6
| #1 |
|---|
"VDEä CANCEL DIRECTORY/FACILITY=RMSH%VDE-I-DIRDEL, directory specification [MYDIR.RMS] deleted from database>%VDE-I-COMMIT, database transaction has successfully committedVDEä |
q
PreviousX Next[ Contents] Index