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

The following example assumes the VDE database is at ddcu:[vde]VDE$DATABASE.RDB, and the CMS libraries are located on the $11$DSA1: shadow set device, a shadow set comprised of $11$DUA10: and $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: $ 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: $ MOUNT $11$DSA1:/SHADOW=($11$DUA10:,$11$DUA11:) - _$ VMSCMSMASTER DISK$VMSCMSMASTER

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

7.8 Relocating Rdb Components

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

$ 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 - _RdbALTER> SPECIFICATION="LIBDEV_SNAP$:[VDE$ROOT.DB_SNAPSHOT]VDE$DATABASE.SNP;1" RdbALTER> deposit file RDB$SYSTEM - _RdbALTER> SPECIFICATION="LIBDEV_AREA$:[VDE$ROOT.DB_STORAGE]VDE$DATABASE.RDA;1" RdbALTER> deposit root specification="LIBDEV_ROOT$:[VDE$ROOT]VDE$DATABASE.RDB;1" RdbALTER> commit RdbALTER> ^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

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

7.9 Recreating Rdb Components

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

$ 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:

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

can 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 corrupted. Typically, an AIJTERMINATE error is generated whenever any operation attempts to access a database after a journal file problem has been detected by Rdb.

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

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

$ RMUE/SHOW AFTER VDE$DATABASE.RDB JOURNAL 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 DISABLED ADD JOURNAL RDB$JOURNAL - FILE VDE$JOURNAL:VDE$DATABASE $ RMUE/SET AFTER VDE$DATABASE.RDB/DISABLE $ RMUE/SET AFTER VDE$DATABASE.RDB/DROP=NAME=RDB$JOURNAL $ RMUE/SET AFTER VDE$DATABASE.RDB - _$ /ADD=(NAME=RDB$JOURNAL,FILE=VDE$DATABASE.AIJ) %RMU-W-DOENBLAIJ, after-image journaling must be enabled to ensure recovery $ RMUE/SET AFTER VDE$DATABASE.RDB/ENABLE %RMU-W-DOFULLBCK, full database backup should be done to ensure future recovery $ ! backup both the journal file, and the database file, now...

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

Also of interest may be the output from the command:

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

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

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

This chapter contains preliminary information. Large sections of this 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...

8.3 Creating Build Jobs

Section under construction...

8.4 Displaying Build Jobs

Section under construction...

8.5 Running Build Jobs

Section under construction...

VDE„ START BUILD_JOB V2-BL5"

Section under construction...

8.5.1 Starting Build Jobs

Section under construction...

8.5.2 Stopping Build Jobs

Section under construction...

8.5.3 Suspending Build Jobs

Section under construction...

8.5.4 Waiting for Build Jobs

Section under construction...

8.6 Scripts for Build Step Execution

Section under construction...

VDE„ CREATE SCRIPT DEVD$:[DIR]FILENAME.VDESCRIPT

8.7 Performing Individual Build Steps

Section under construction...

8.7.1 Copy Steps

Section under construction... To cancel a module reservation without replacing the module, use the

8.7.2 Compile Steps

Section under construction... To cancel a module reservation without replacing the module, use the

8.7.3 Link Steps

Section under construction... To cancel a module reservation without replacing the module, use the

8.8 Initializing the Dependency Graph

Section under construction...

This chapter provides an overview and a general description of how to use the multiple-architecture support present within VDE

9.1 Architectures in the Source Code Library Roots

VDE architecture support adds the arch-variant, the architecture variant. One processor-independent root is present---"VMS" -- and zero or more 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.

As 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:

• The VMS arch-variant directory contains the facility subdirectories 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.
• Subdirectories within the VAX arch-variant directory contain CMS libraries for all facilities that contain at least one module specific to the VAX architecture. Likewise, subdirectories within the Alpha arch-variant directory contain CMS libraries for all facilities that contain at least one module specific to the Alpha architecture.
• If a module is architecture-independent, it is only represented in a CMS library within the VMS arch-variant. When a module becomes architecture-specific, it is turned into two modules so that a CMS element is created for it within both the VAX and the Alpha arch-variants. The CMS element within the VMS arch-variant remains since it contains the module's contents for all old development streams. In the VMS arch-variant, the stream (CMS class) in which the module was made architecture-specific is bound to a generation whose 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 arch-variants. These new generations have the same contents as the latest generation in the VMS arch-variants before the module was made architecture-specific. Thereafter, the three modules (the VMS, VAX, and Alpha modules, all with the same module name) evolve separately as separate CMS elements.
• If a new module is specific to a single architecture, that module is only represented in a CMS library within the VAX or the Alpha arch-variant, whichever architecture applies. New modules specific to OpenVMS Alpha, for example, will only appear within the Alpha arch-variant.

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

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 database. The module-name syntax we will use in this specification is ARCH:[FAC]MOD.TYP. Here ARCH is the architecture of the module: VMS for architecture-independent modules and VAX or Alpha for architecture-specific modules. The remaining fields ([FAC]MOD.TYP) have the normal meanings explained earlier in this document. The architecture field is optional; if it is omitted, a user-settable default architecture is supplied.

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

VDE„ CREATE ARCHITECTURE VAX

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

A 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

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

9.3 Creating Architecture-Specific Modules

The VSC and VDE utilities provide a qualifier to the MODIFY MODULE command that makes a module architecture-specific by creating 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

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

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

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

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

VDE„ CREATE MODULE Alpha:[FACIL]FOO.BAR

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

9.4 Operation of Existing Commands

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

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

VDE„ SHOW MODULE *:[FACIL]FOO.BAR Module Alpha:[FACIL]FOO.BAR Module VAX:[FACIL]FOO.BAR Module VMS:[FACIL]FOO.BAR

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

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

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

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

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

9.5 Change Propagation and Fold Records

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

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