HThis section contains a simple set of procedures used to defragment the 2CMS portion of the VDE database using the OpenVMS 6BACKUP utility, using the steps appropriate for a VDE !database located on a shadow set.

5The following example assumes the VDE database is at Eddcu:[vde]VDE$DATABASE.RDB, and the CMS libraries are located on the F$11$DSA1: shadow set device, a shadow set comprised of $11$DUA10: and F$11$DUA11:. $11$DUA100: is assumed to be a scratch disk equivilent to $11$DUA10: and $11$DUA11:.

 

" <$ RMU/CLOSE/CLUSTER/ABORT=DELPRC ddcu:[vde]VDE$DATABASE.RDB $ DISMOUNT/CLUSTER $11$DSA1: /$ MOUNT/OVER=(SHADOW,IDENT)/NOWRITE $11$DUA10: /$ MOUNT/OVER=(SHADOW,IDENT)/NOWRITE $11$DUA11: $ MOUNT/FOREIGN $11$DUA100: 8$ BACKUP/IMAGE $11$DUA10: $11$DUA100:/VERIFY/INITIALIZE $ DISMOUNT/NOUNLOAD $11$DUA10: $ MOUNT/FOREIGN $11$DUA10: )$ BACKUP/PHYSICAL $11$DUA100: $11$DUA10: $ DISMOUNT/NOUNLOAD $11$DUA11: $ MOUNT/FOREIGN $11$DUA11: )$ BACKUP/PHYSICAL $11$DUA100: $11$DUA11: 3$ MOUNT $11$DSA1:/SHADOW=($11$DUA10:,$11$DUA11:) - "_$ VMSCMSMASTER DISK$VMSCMSMASTER  

CThe above steps quickly bring the defragmented database shadow set Hvolumes into synchronization. While the shadow set copy operation could Galso be used to resynchronize the defragmented volume, shadowing merge Hperformance is not tuned for this particular (infrequent) situation; it :is far slower than the double BACKUP/PHYSICAL shown above.W

7.8 Relocating Rdb Components

=It is normally best to use the Rdb RMU/BACKUP and RMU/RESORE Ecommands to relocate a database. As this is not always possible, the Bfollowing commands are used to close and then to relocate various 3individual Rdb component files associated with the VDE Rdb database:

 

" 8$ DEFINE/SYSTEM/EXECUTIVE VDE$OFFLINE "offline for move"'$ RMU/CLOSE/CLUSTER/ABORT=DELPRC/WAIT -_$ VDE$:[ROOTDIR]VDE$DATABASE:$ ! BACKUP or COPY the database files to the new location+$ RMU/ALTER LIBDEV$:[PROJ]VDE$DATABASE.RDB/RdbALTER> deposit file RDB$SYSTEM SNAPSHOT -S_RdbALTER> SPECIFICATION="LIBDEV_SNAP$:[VDE$ROOT.DB_SNAPSHOT]VDE$DATABASE.SNP;1"&RdbALTER> deposit file RDB$SYSTEM -R_RdbALTER> SPECIFICATION="LIBDEV_AREA$:[VDE$ROOT.DB_STORAGE]VDE$DATABASE.RDA;1"SRdbALTER> deposit root specification="LIBDEV_ROOT$:[VDE$ROOT]VDE$DATABASE.RDB;1"RdbALTER> commitRdbALTER> ^Z<$ ! Now adjust any VDE$SYSTARTUP.COM definitions associated<$ ! with the database to reflect the new location, and also<$ ! adjust the live logical name definitions on all cluster$ ! members as appropriate.'$ DEASSIGN/SYSTEM/EXECUTIVE VDE$OFFLINE 

ENote that RMU/ALTER does not currently support continuation Gcharacters such as the hyphen; the hyphen in the above example is used to strictly for readability.Z

7.9 Recreating Rdb Components

mAs part of the process described in Section 7.8, you may sometimes Eneed to recreate the snapshot file and the after-image journal (AIJ) !file, via the following commands:

 

" 4$ RMU/REPAIR/AREA=RDB$SYSTEM/INITIALIZE=SNAPSHOT -"_$ VDE$:[ROOTDIR]VDE$DATABASE.RDB;$ RMU/SET AFTER_JOURNAL VDE$:[ROOTDIR]VDE$DATABASE.RDB;1 -_$ /DISABLE;$ RMU/SET AFTER_JOURNAL VDE$:[ROOTDIR]VDE$DATABASE.RDB;1 -_$ /DROP=(NAME=RDB$JOURNAL) -;$ RMU/SET AFTER_JOURNAL VDE$:[ROOTDIR]VDE$DATABASE.RDB;1 -_$ /ADD=(NAME=RDB$JOURNAL, -=_$ FILE=LIBDEV_SNAP$:[VDE$ROOT.DB_JOURNAL]VDE$DATABASE.AIJ) ;$ RMU/SET AFTER_JOURNAL VDE$:[ROOTDIR]VDE$DATABASE.RDB;1 -_$ /ENABLE 



Also, the following command:

 

" 2$ RMU/REPAIR/ABM VDE$:[ROOTDIR]VDE$DATABASE.RDB;1 

Ecan be of interest if the RMU/VERIFY command detects inconsistencies -among the ABM and SPAM pages in the database.

The AIJTERMINATE error@ can arise when the journal file is inaccessable, or when it is G corrupted. Typically, an AIJTERMINATE error is generated whenever any F operation attempts to access a database after a journal file problem  has been detected by Rdb.

 

" $ VDE$ SET LIBRARY libnameQ%RDMS-F-AIJTERMINATE, inaccessible AIJ file forced image exit to protect database 

GThe following sequence of commands can be used to recreate the journal file:

 

" #$ RMUE/SHOW AFTER VDE$DATABASE.RDBJOURNAL IS ENABLED - RESERVE 1 - ALLOCATION IS 512 - EXTENT IS 512 - OVERWRITE IS DISABLED - SHUTDOWN_TIMEOUT IS 60 - NOTIFY IS DISABLED - BACKUPS ARE MANUAL - CACHE IS DISABLEDADD JOURNAL RDB$JOURNAL -! FILE VDE$JOURNAL:VDE$DATABASE*$ RMUE/SET AFTER VDE$DATABASE.RDB/DISABLE8$ RMUE/SET AFTER VDE$DATABASE.RDB/DROP=NAME=RDB$JOURNAL$$ RMUE/SET AFTER VDE$DATABASE.RDB -1_$ /ADD=(NAME=RDB$JOURNAL,FILE=VDE$DATABASE.AIJ)K%RMU-W-DOENBLAIJ, after-image journaling must be enabled to ensure recovery*$ RMUE/SET AFTER VDE$DATABASE.RDB/ENABLEO%RMU-W-DOFULLBCK, full database backup should be done to ensure future recovery?$ ! backup both the journal file, and the database file, now... 

BThe names and locations of the database and the journal file will 4typically need to be included in the above commands.

4Also of interest may be the output from the command:

 

" 1$ RMU/DUMP/HEADER/OPTIONS=DEBUG VDE$DATABASE.RDB 

DAs the AIJ_STATUS value can indicate what happened with the journal Hfile. (Seeing AIJ_STATUS = 1. indicates that the journal file could not 3be opened.) Also check for any RDSBUGCHK.DMP files.

FThe software building capabilities described in this chapter have "not been completely debugged.

EThis chapter contains preliminary information. Large sections of 5this chapter are currently under construction...

:This chapter describes how to use the VDE builder utility to...



&Section under construction...

&Section under construction...[

8.2 Central Build Algorithm

&Section under construction...Y

8.3 Creating Build Jobs

&Section under construction...`

8.4 Displaying Build Jobs

&Section under construction...X

8.5 Running Build Jobs

&Section under construction...

 

" VDEä START BUILD_JOB V2-BL5" 

&Section under construction...G

8.5.1 Starting Build Jobs

&Section under construction...F

8.5.2 Stopping Build Jobs

&Section under construction...K

8.5.3 Suspending Build Jobs

&Section under construction...I

8.5.4 Waiting for Build Jobs

&Section under construction...f

8.6 Scripts for Build Step Execution

&Section under construction...

 

" 0VDEä CREATE SCRIPT DEVD$:[DIR]FILENAME.VDESCRIPT 

j

8.7 Performing Individual Build Steps

&Section under construction...;

8.7.1 Copy Steps

&Section under construction...DTo cancel a module reservation without replacing the module, use the>

8.7.2 Compile Steps

&Section under construction...DTo cancel a module reservation without replacing the module, use the;

8.7.3 Link Steps

&Section under construction...DTo cancel a module reservation without replacing the module, use thei

8.8 Initializing the Dependency Graph

&Section under construction...

FThis chapter provides an overview and a general description of how to 8use the multiple-architecture support present within VDEn

9.1 Architectures in the Source Code Library Roots

"VDE architecture support adds the <arch-variant, the architecture variant. OneGprocessor-independent root is present---"VMS" -- and zero or Hmore processor-dependent variants can be created. Previous versions <of VDE included implicit support for arch-variants, and all ?such versions use "VMS" as the name of the processor +architecture independent arch-variant.

DAs a specific example of adding arch-variants, one can support both =OpenVMS Alpha and OpenVMS VAX development in parallel if the ;OpenVMS source code libraries are logically reorganized as follows:

J
• The VMS arch-variant directory contains the facility subdirectories B for all architecture independent modules in OpenVMS. There is a  CMS library within the>VMS arch-variant for each facility that contains at least one architecture-independent module.G
• Subdirectories within the VAX arch-variant directory contain CMS I libraries for all facilities that contain at least one module specific E to the VAX architecture. Likewise, subdirectories within the Alpha G arch-variant directory contain CMS libraries for all facilities that A contain at least one module specific to the Alpha architecture.I
• If a module is architecture-independent, it is only represented in C a CMS library within the VMS arch-variant. When a module becomes E architecture-specific, it is turned into two modules so that a CMS > element is created for it within both the VAX and the Alpha E arch-variants. The CMS element within the VMS arch-variant remains B since it contains the module's contents for all old development H streams. In the VMS arch-variant, the stream (CMS class) in which the G module was made architecture-specific is bound to a generation whose I text says that the module is now architecture-specific. In the the VAX ? and Alpha arch-variants, this stream is bound to the initial @ generations of the new architecture-specific modules in those E arch-variants. These new generations have the same contents as the H latest generation in the VMS arch-variants before the module was made J architecture-specific. Thereafter, the three modules (the VMS, VAX, and E Alpha modules, all with the same module name) evolve separately as  separate CMS elements.H
• If a new module is specific to a single architecture, that module C is only represented in a CMS library within the VAX or the Alpha H arch-variant, whichever architecture applies. New modules specific to @ OpenVMS Alpha, for example, will only appear within the Alpha  arch-variant.

BThe structure described here is not a proposed structure, but the 0actual structure as it is presently implemented.m

9.2 Commands to Specify Multiple Architectures

?To support multiple architectures within a source code library <structure, the VDE source control system must represent the @concept of an architecture in its module-name syntax and in its Fdatabase. The module-name syntax we will use in this specification is HARCH:[FAC]MOD.TYP. Here ARCH is the architecture of the module: VMS for 6architecture-independent modules and VAX or Alpha for Harchitecture-specific modules. The remaining fields ([FAC]MOD.TYP) have <the normal meanings explained earlier in this document. The Barchitecture field is optional; if it is omitted, a user-settable !default architecture is supplied.

GTo set up architecture information in the source control database, the +VDE utility supports the following command:

 

" VDEä CREATE ARCHITECTURE VAX 



GThis command creates an architecture entry in the database and assigns Gthe architecture a name and a remark string. This command is only used >when the database is initially set up (and whenever we invent Fadditional architectures in the future). In addition, the VDE utility Hsupports a MODIFY ARCHITECTURE command (to change the remark string), a =DELETE ARCHITECTURE command (to correct mistakes in defining Garchitectures), and a SHOW ARCHITECTURE command. The SHOW ARCHITECTURE Gcommand displays information about all defined architectures. The SHOW DDEFAULTS command shows the current default architecture, along with other defaults.

EA command that is of more interest to most developers is the command <that establishes a default architecture for the current VSC or VDE session:

 

" VSCä SET ARCHITECTURE Alpha 



GThis example specifies that Alpha is the default architecture when the Barchitecture name is omitted from module names. This command also Gresets the default facility to be the facility in the new architecture Gthat has the same name as the current default facility. If there is no Csuch facility, the default facility setting is cleared so that the #default facility becomes undefined.m

9.3 Creating Architecture-Specific Modules

1The VSC and VDE utilities provide a qualifier to Gthe MODIFY MODULE command that makes a module architecture-specific by Bcreating one or more single-architecture modules from an existing <architecture-independent module. This is the command syntax:

 

" ;VDEä MODIFY MODULE/ARCHITECTURE_SPECIFIC VMS:[FACIL]FOO.BAR 



FThis command makes module VMS:[FACIL]FOO.BAR architecture-specific by Fcreating the two modules VAX:[FACIL]FOO.BAR and Alpha:[FACIL]FOO.BAR. DThe command fetches out the latest generation of the module for the Edefault development stream and makes that the initial generation for Gthe two new modules. It also fetches out the latest generations of any Hsuccessor development streams (if different) and inserts those into the Hnew modules. The default stream and its successors are thus all defined Afor the two new architecture-specific modules. In addition, this Hcommand creates a new generation of the architecture-independent module Hin the VMS arch-variant. This generation is bound to the default stream Cand its successors and contains fixed text that indicates that the Bmodule is now architecture-specific. The database record for this Bgeneration contains a flag indicating that the module is obsolete Dbecause it was made architecture-specific; hence the source control Bsystem can determine that the module is obsolete without actually !examining the text of the module.

<The /ARCHITECTURE_SPECIFIC qualifier can optionally take an Farchitecture name as a parameter. If this parameter is specified, the EMODIFY MODULE command creates a new module for that one architecture &only, and not for other architectures.

HTo make an architecture-specific module architecture-independent again, Ha developer must first insert the appropriate generations of the module Ginto the architecture-independent module (such as VMS:[FACIL]FOO.BAR). GThis is done with a combination of FETCH, RESERVE, REPLACE, and INSERT AGENERATION commands, and it must be done for all active streams. @Merging two architecture-specific versions of a module into one Earchitecture-independent version is thus largely a manual operation. GThereafter, the module must be marked as obsolete for each such stream Hin the two single-architecture modules (for example, VAX:[FACIL]FOO.BAR and Alpha:[FACIL]FOO.BAR).

ETo create a new module which is specific to a single architecture, a Cuser enters the CREATE MODULE command, specifying the architecture:

 

" 'VDEä CREATE MODULE Alpha:[FACIL]FOO.BAR 



FThis example creates a module for the Alpha architecture only. If the Dmodule should be architecture-independent, the architecture must be +specified as VMS, explicitly or by default.`

9.4 Operation of Existing Commands

EThe presence of multiple architectures affects the look-up rules for Call commands that accept module names as parameters. Commands that Frefer directly to modules behave a bit differently from commands that refer to module generations.

ECommands that refer directly to modules, such as the CREATE, MODIFY, FDELETE, and SHOW MODULE commands, only create or reference the module Cin the architecture the user specified. If the architecture is not Fspecified explicitly on the module name, the command uses the default Farchitecture established by the most recent SET ARCHITECTURE command. <On any command where the module name may be wildcarded, the Earchitecture part may also be wildcarded. The following command thus Hshows three modules if the module has forms that are both dependent and independent of architecture:

 

" !VDEä SHOW MODULE *:[FACIL]FOO.BARModule Alpha:[FACIL]FOO.BARModule VAX:[FACIL]FOO.BARModule VMS:[FACIL]FOO.BAR 



GCommands that refer to module generations need to look up a generation >of a module in a given development stream. Usually the latest Hgeneration of the module in the given stream is requested. Whether such Ha generation exists depends on the module's architecture as well as the stream.

FGiven an architecture (specified explicitly or by default), a module, Hand a development stream, the FETCH or RESERVE command looks up the the Hmodule with the specified name in the specified architecture. If such a Cmodule is found, the command looks up the latest generation of the Dmodule in the requested development stream. If such a generation is @found and is not marked as obsolete because the module was made Aarchitecture-specific, that is the generation that is fetched or Breserved. Otherwise, the command prints a message saying that the Amodule does not exist, is not defined in the given stream, or is 6obsolete for the given stream. If the module was made ;architecture-specific, the command prints the names of the Harchitectures in which the module is defined. It is then up to the user >to fetch or reserve the corresponding module for each desired architecture.

GA developer who primarily works on OpenVMS Alpha code may thus set his For her default architecture to Alpha. He or she will get the instance Cof the module specific to OpenVMS Alpha, if there is one, else a a Fmessage indicating the module exists for the architecture VMS will be ?displayed. A developer whose work is not focused on a specific Garchitecture could instead set his or her default architecture to VMS. FWhen fetching or reserving a module, such a developer will either get Hthe architecture-independent instance of the module or a message saying Dthat the module is defined for architecture VAX or Alpha, whichever applies, or for both.

GThe REPLACE command does not look up generations in the same sense. It Hlooks up a reservation for a specified module and development stream on Dthe assumption that the module belongs to the architecture that the Euser specifies, either explicitly or by default. If there is no such Hreservation, the command prints an error message. The UNRESERVE command uses the same procedure.

FThe SHOW and MODIFY GENERATION commands only look up generations that Hbelong to the module in the architecture the user specifies (explicitly For by default). Generations that have been made architecture-specific @are marked as such in the SHOW GENERATION output. When the SHOW FGENERATION command displays the list of generations that gave rise to Cthe latest generation of the module in a specified stream, it also =shows at what generation the module was converted from being Darchitecture-independent to being architecture-specific. The INSERT HGENERATION and DELETE GENERATION commands only work on the architecture that the user specifies.j

9.5 Change Propagation and Fold Records

FWhen a module is replaced into the library, the source control system Gmay have to propagate the change from the specified development stream Dto its successors. Change propagation and fold records have already Abeen explained for the one-architecture case. In the presence of =multiple architectures, the following additional rules apply:

<
• If the stream successor chain does not cross from the H architecture-independent to the architecture-specific instance of the G module being replaced, change propagation and fold record generation - work as described earlier in this document.H
• If the development stream successor chain crosses an architecture I boundary for module [FACIL]FOO.BAR (for example, if VMS:[FACIL]FOO.BAR E contains the generation in stream AETNA and VAX:[FACIL]FOO.BAR and H Alpha:[FACIL]FOO.BAR contain the generations in stream PHOENIX), then J the source control system generates fold records saying that the change ? to VMS:[FACIL]FOO.BAR must be manually propagated to modules G VAX:[FACIL]FOO.BAR and Alpha:[FACIL]FOO.BAR. The same is true if the I change must be propagated from an architecture-independent module to a  single-architecture module.D
• Source changes will not be propagated automatically across an J architecture boundary in Version 1 of the new source control system. In G general, a module will not be made architectures-specific unless its J Alpha form is different from its architecture-independent form. The VAX 5 form is more likely to be the same as the original E architecture-independent form, which would make change propagation E across architectures useful, but the implementation of such change F propagation is difficult and will therefore be deferred. This means F that change propagation across architectures must be done manually, J just as folds are. Fold records will remind developers when such change  propagation is required.G
• If a module is architecture-specific, then a change to the Alpha H module can optionally generate a fold record that reminds the user to B make the same change to the VAX module, and vice versa. In this J situation, the REPLACE command will ask the user whether to create such  a fold record.

;In summary, while VDE does include support multiple source Ecode architectures, there is no support automatic change propagation 8across architectures. VDE does support fold records for changes that span architectures.