7The following is the Rdb V6.0 command used to rename a <particular journalling file. The version number is required.

 

" #$ ! Rdb V6.0 journaling command...5$ RMU/SET AFTER_JOURNAL LIBDEV$:[PROJ]VDE$DATABASE - *_$ /ALTER=(name=aij,FILE=filename.aij;0) 

.Use the Rdb V6.0 "RMU/SHOW AFTER_JOURNAL Fdatabasename" command to display the current journal file(s) and 0the current state of journaling on the database.

GIf the journal is inaccessable, use the following sequence to create a new journal file:

 

" #$ ! Rdb V6.0 journaling command...5$ RMU/SET AFTER_JOURNAL LIBDEV$:[PROJ]VDE$DATABASE - _$ /DISABLE5$ RMU/SET AFTER_JOURNAL LIBDEV$:[PROJ]VDE$DATABASE - _$ /DROP=(name=aij)5$ RMU/SET AFTER_JOURNAL LIBDEV$:[PROJ]VDE$DATABASE - (_$ /ADD=(name=aij,FILE=filename.aij;0)5$ RMU/SET AFTER_JOURNAL LIBDEV$:[PROJ]VDE$DATABASE - _$ /ENABLE 



8The following commands are used to relocate various Rdb ,component files associated with the VDE Rdb database:

 

" '$ RMU/ALTER LIBDEV$:[PROJ]VDE$DATABASE/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 

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.X

7.4.10 Recovering Lost CMS Libraries

;If the delta files (the CMS libraries) in your VDE library Care damaged or lost due to a disk failure or other cause, you must Drecover as much of its lost contents as possible. The procedure for Edoing so involves initially restoring or recreating missing files or Gdirectories (consisting primarily of CMS libraries) from backup tapes, =and then restoring the VDE database from the database backup Gand journal disk(s), and finally bringing the CMS libraries up-to-date Gusing information from the database and the queued replacement staging area directories.

;The first step is to determine how much of the VDE library Gis damaged. If the whole disk is unavailable (due to a head crash, for Gexample), you must restore the whole disk from backup tapes created by Gthe normal nightly backups. If only certain CMS libraries are damaged, Byou may only need to restore those CMS libraries. Either way, you 6should wind up with a VDE directory structure that is Eup-to-date as of the last backup, and thus at most a day out of date.

:If the VDE database was affected by the failure, the next Çstep is to restore and recover it as explained in Section 7.4.7. This Foperation restores the database from its most recent backup files and Ethen applies the after-image journal files to the restored database, Hthus rolling the database forward until it is up-to-date as of the last )transaction completed before the failure.

=Because the VDE database is fully up-to-date, information in Bthe database can be used to determine what module generations are Bmissing from the restored CMS libraries (which may be up to a day Eout-of-date). To determine what generations are missing from the CMS 1libraries, you can use the following VDE command:

 

" -VDEä VERIFY GENERATION/SINCE=YESTERDAY [*]*.* 

AThis command checks all module generations that according to the 7VDE database were created since midnight yesterday and Hdetermines whether each such generation is present in the corresponding :CMS library. If not, VDE prints a message for the missing generation.

@If only a few CMS libraries were restored, you can save time by =verifying generations for only those facilities. For example:

 

" >VDEä VERIFY GENERATION/SINCE=YESTERDAY [FAC1]*,[FAC2]*,[FAC3]* 



BIf the output of the VERIFY GENERATION command indicates that any Hmodule generations are missing from the restored CMS libraries, you can <usually recover those generations from the VDE staging area :directories. The VDE staging area directories contain the Coriginal source file for each generation created by a replacement. DMissing generations can therefore be restored to a CMS library from Ethose source files. To do so, use the VERIFY GENERATION command with $the /RECOVER qualifier. For example:

 

" 5VDEä VERIFY GENERATION/SINCE=YESTERDAY/RECOVER [*]*.* 

GThis command prints a message for each missing generation, but it also Hlocates the replacement staging area directory containing the file that 9created the generation. VDE uses that file to insert the Hmissing generation into the CMS library. As a result, all CMS libraries 7should be fully up-to-date and consistent with the VDE Cdatabase after this command completes. However, if some generation Dcannot be recovered, perhaps because the staging area directory has Abeen deleted or because the generation was created without using <staging area directories, then VDE prints a message to that +effect and the generation is not recovered.

HKeep in mind that not all module generations are stored in staging area Cdirectories. Only queued replacements use staging areas; immediate Breplacements do not. Also, generations created with the /INPUT or D/DIRECTORY qualifier to the CREATE MODULE command are not stored in ;staging area directories. Because these qualifiers require 9VDE privileges and are normally used only during initial ;set-up of the VDE library, recovery of such generations is Busually not an issue. However, it is generally wise to always use Equeued replacements if recovery of lost generations is a concern for your VDE library.

GIn those cases where a missing generation cannot be recovered from its Gstaging area directory but is available from a file elsewhere, you can Grecover that generation with a separate VERIFY GENERATION command that 3gives an explicit file location for the generation:

 

" $VDEä VERIFY GENERATION [FAC1]FOO.C -/_VDEä /GENERATION=5A2/RECOVER=DSK$:[MYDIR]FOO.C 

FThis command recovers generation 5A2 of module FOO.C in facility FAC1 Dfrom file DSK$:[MYDIR]FOO.C. If you use this form of the command to Grecover multiple generations for the same module, you must recover the >generations in the same order as they were originally created.

;If you are unable to recover a missing generation, the VDE Edatabase will be inconsistent with the affected CMS library. This is Ghighly undesirable because it means that the missing generation (which His likely to be the latest generation of at least one stream) cannot be Dfetched or reserved. To correct the problem, you must do one of two Hthings. One possibility is to get the creator of the missing generation Bto recreate it so you can recover it as just described. The other Epossibility is that you recover the missing generation using a dummy 9input file and then delete that generation using the VDE CDELETE GENERATION command; in this case, the missing generation is Bpermanently lost but the database becomes consistent with the CMS libriary.G

7.4.11 Moving to Larger CMS Disks

FThis section describes how to move the CMS library to different---and Dusually larger---disks. The use of a shadow set for the CMS library 4volume, and the use of VDE in a cluster, is assumed.

?
• Send out a warning to the users to indicate that Rdb and ( the CMS libraries will be unavailable.G
• Enable full privileges with the command SET PROCESS/PRIVILEGE=ALL;
• Shut down all versions of Rdb running on the current D system. This may involve procedures such as RMONSTOP, RMONSTOP41, # RMONSTOP60, etc., as appropriate.C
• If it is in use, modify MSCPMOUNT to remove shadow set mount E including the specifications of the source disk(s), and remove any % reference(s) to the target disk(s).J
• Dismount all members of the CMS shadow set, and dismount all of the  target disk volume(s).F
• If MSCPMOUNT is in use, wait for fifteen minutes, or locate and B remove any and all running MSCPMOUNT jobs that might be lurking ) anywhere on any of the cluster members.8
• Set the hardware write-lock on the source disk(s).1
• Mount the source and target disk privately.7
• Perform a disk-to-disk BACKUP, with verification.+
• Dismount the source and target disks.G
• If MSCPMOUNT is in use, modify MSCPMOUNT to include the new disk I volumes using the original shadow set name---do not change the name of F the shadow set. Invoke copies of MSCPMOUNT on one or more nodes, as  appropriate.I
• Perform a cluster-wide MOUNT of the target disk---this disk is the E first or root volume of the shadow set---and then MOUNT additional C members cluster-wide as appropriate. When additional volumes are 3 mounted, a shadow-copy operate will be initiated.6
• Start Rdb on all cluster nodes using RMONSTART, 2 RMONSTART60, RMONSTART41, etc., as approrpriate.9
• Test the access to the CMS library from within VDE.



/This section describes how to relocate VDE Rdb Edatabase files to other disks, how to deal with device name changes, Gand how to reset the filenames of the database root, storage area, and Fsnapshot area should the filename(s) stored in the database root file .not match the filename(s) of the actual files.

 

" '$ RMU/CLOSE/CLUSTER/ABORT=DELPRC/WAIT -4_$ DISK$OLDROOTDISK:[TOOLS.DBROOT]VDE$DATABASE.RDB%$ RMU/MOVE_AREA/NOAREA/NOONLINE/LOG -(_$ /dir=DISK$NEWDATADISK:[VDE.TOOLS] -6_$ DISK$OLDROOTDISK:[TOOLS.DBROOT]VDE$DATABASE.RDB -;_$ /after=DISK$NEWAIJDISK:[VDE.TOOLS]VDE$DATABASE.AIJ;1 -;_$ /root=DISK$NEWROOTDISK:[VDE.TOOLS]VDE$DATABASE.RDB;1 -=_$ /snap=file=DISK$NEWSNPDISK:[VDE.TOOLS]VDE$DATABASE.SNP;1 

CThis sequence performs a controlled relocation of all areas of the Adatabase (specification of /NOAREA indicates all areas are to be Emoved), the after-image journal, the database root, and the snapshot Farea, to the specified new area. The above commands will clean up the old area, as well.

6Once the databases have been moved, be sure to update FVDE$SYSTARTUP.COM, and any system device MOUNT procedures, to reflect @the new location of the databases. Also perform a full database RMU/BACKUP.

HIf is also possible for this situation to arise unintentionally, should >some disks get shuffled around. Should the databases be moved 2unintentionally, VDE can produce RDMS$_FILACCERR, /RDMS$_BADROOTMATCH, and RDB$_DB_CORRUPT errors.FAs part of resolving this, you will want to determine why these files Eare no longer under the expected filenames---device name changes are one potential cause.

 

" $ VDEVDEä SET LIBRARY VMS6%RDB-F-SYS_REQUEST, error from system services request_-RDMS-F-FILACCERR, error opening storage area file $11$DUA1010:[VMS.DATABASE]VDE$DATABASE.SNP;1K-RMS-F-DEV, error in device name or inappropriate device type for operationVDEä [CTRL/Z]$  



 

" $ VDEVDEä SET LIBRARY VMS/%RDB-F-DB_CORRUPT, database filename is corrupt¥-RDMS-F-BADROOTMATCH, root file "$22$DUA1010:[VMS.DATABASE]VDE$DATABASE.RDB;1" no longer has its original name "$11$DUA1010:[VMS.DATABASE]VDE$DATABASE.RDB;1"VDEä [CTRL/Z]$  



 

" $ 6$ RMU/ALTER $22$DUA1010:[VMS.DATABASE]VDE$DATABASE.RDB_RdbALTER> dep file RDB$SYSTEM snapshot speci="$22$DUA1010:[VMS.DATABASE]VDE$DATABASE.SNP;1"VRdbALTER> dep file RDB$SYSTEM speci="$22$DUA1010:[VMS.DATABASE]VDE$DATABASE.RDA;1"LRdbALTER> dep root specif="$22$DUA1010:[VMS.DATABASE]VDE$DATABASE.RDB;1"RdbALTER> commit!RdbALTER> [CTRL/Z]$  



FOnce the database has been brought back online or has been relocated, Cmake certain to perform a full database RMU/BACKUP of the database.i

7.5 Purging the Staging Area Directories

FThe staging area directories will grow over time and must be manually ?cleaned. This operation is performed at site-specific periodic Dintervals---the intervals are determined by the size of the staging Hdevice and the frequency and size of replacements, and by the frequency Hof the database backups. This section describes the steps used to purge Bold replacements. For information on utilitizing the staging area 9directories during VDE database recovery operations, see MSection 7.4.10.

=The staging area directories can be located with the command:

 

" VSC> SHOW LOCATION/STAGING 

HThis command displays the staging (sub)directory containing all staging area directories.

;Underneath the staging subdirectory exists three levels of Gsubdirectories. The files associated with a replacement are located in Fthe lowest two levels of the staging heirarchy---all files associated Fwith a particular replacement are located below a unique subdirectory 2[.VDE$REP_*], in facility-specific subdirectories.GLocated one level above the [.VDE$REP_*] replacement subdirectory is a Estaging area subdirectory in the form [.VDE$STG_*]. The staging area Gsubdirectory exists solely to reduce the number of files in any single Hdirectory. For further details on the stating area directory structure, Gsee Section 6.3.2.

DAn example of the full specification of a staging directory follows:

 

" 8VSC$STAGEDISK:[VMS.STAGE.VDE$STG_130.VDE$REP_13066.ERF]  



HThe names of the [.VDE$REP_*] replacement subdirectories are built from Ca predefined prefix with the five decimal digit replacement number Happended. Replacement numbers are allocated in ascending order, and are ,not reused unless the database is recreated.

HThe names of the [.VDE$STG_*] staging area subdirectories are comrpised Gof a predefined prefix with all but the last two decimal digits of the =replacement number appended. This means each of staging area Asubdirectories holds one hundred replacement subdirectory files. FStaging area subdirectories---once filled -- are not reused until and (unless the entire database is recreated.

)To perform the cleanup, issue the command

 

" VSC> SHOW REPLACEMENT/FULL 

?And look for the replacement number associated with the oldest Creplacement displayed. This is typically the first entry displayed.

AUsing the oldest replacement identifier, delete all [.VDE$STG_*] Gstaging area subdirectories where the first three digits are less than Hthe observed replacement number. For example, if the oldest outstanding Dreplacement number is "13054", all subdirectories and all Cfiles located under staging area subdirectories [.VDE$STG_129...], ?[.VDE$STG_128...], [.VDE$STG_127...], etc., can be deleted. Do Enot delete staging area subdirectories more recent than the ulast VDE database backup operation. See Section 7.4.10.

HFailure to insure adequate space in the staging area can produce errors similar to the following:

 

" E%COPY-E-OPENOUT, error opening VSC$STAGEDISK:[VMS.STAGE.VDE$STG_131. 5VDE$REP_13163.DECW$DEVICE]DECWINDOWS000.E; as output <-RMS-F-FUL, device full (insufficient space for allocation) 9%COPY-W-NOTCOPIED, dev:[dir]DECWINDOWS000.E;1 not copied .%VDE-E-SCRPMODFAIL, STAGING script for module 4[DECW$DEVICE]DECWINDOWS000.E terminated with errors  

1The above error occured on the following command:

 

" VSC> REPLACE DECWINDOWS000.E 

V

7.6 Offloading Large Files

<It is possible for a VDE database to exceed the capacity of Ha volume. The following section describes the steps required to offload /the larger files from one of the VDE libraries.

HThe following command can be used to locate the larger files present in 1the VDE libraries. In the case of OpenVMS, these Gfiles are typically savesets from contributing projects, are typically large.



DMarker files are typically large binary, image, saveset, or library Ffiles, and as such are not (and should not be) stored directly in the BCMS library, as this reduces the overhead involved when there are Etypically rather large changes between one module generation and the &next. Use the SHOW MODULE/FULL commandCto determine if a particular module is a marker file. Use the SHOW DIRECTORY/DELTA command9to determine the current (default) location of the delta Cdirectory---specifically the location referenced by the applicable VDE$MARKER symbol.



GThe following command can be used to locate the larger file(s) present :in the local VDE database in the "VMS$" library:

 

" ?$ DIRECTORY/SIZE/SELECT=SIZE=MINIMUM=500 VMS$:[000000...]*.*.* 

HBased on the files located by above command, a list of the larger files Dwas generated, and the following command procedure was then created:

 

" $ Set NoOn 4$ dir/col=1/siz/out=sys$scratch:masd_listing1.tmp -  vms$:[ddtm.src]ddtmkit.bck 4$ dir/col=1/siz/out=sys$scratch:masd_listing2.tmp - @ vms$:[decw$buildtool.src]decw$buildtool.sav,decw$motif%%%.% 4$ dir/col=1/siz/out=sys$scratch:masd_listing3.tmp - * vms$:[decw$common.src]decwindows%%%.a 4$ dir/col=1/siz/out=sys$scratch:masd_listing4.tmp - 6 vms$:[decw$device.src]decwindows000.b,.c,.d,.e,.f 4$ dir/col=1/siz/out=sys$scratch:masd_listing5.tmp - / vms$:[decw$fonts.src]decwindows000.c,.d,.e 4$ dir/col=1/siz/out=sys$scratch:masd_listing6.tmp - 0 vms$:[decw$server.src]decwindows000.b,.c,.q 4$ dir/col=1/siz/out=sys$scratch:masd_listing7.tmp -  vms$:[ipc.src]ipckit.bck 4$ dir/col=1/siz/out=sys$scratch:masd_listing8.tmp -  vms$:[lm.src]lmkit.bck 4$ dir/col=1/siz/out=sys$scratch:masd_listing9.tmp - & vms$:[starlet.src]vic_starlet.obj 4$ dir/col=1/siz/out=sys$scratch:masd_listinga.tmp -  vms$:[syslib.src]*.* 4$ dir/col=1/siz/out=sys$scratch:masd_listingb.tmp - # vms$:[tpssda.src]tpssdakit.bck $ B$ Copy sys$scratch:masd_listing%.tmp sys$scratch:masd_listing.lis  

FBased on the above command procedure, the following command is issued for each module located:

 

" .VSC> SHOW GENERATION/TREE [DDTM]DDTMKIT.BCK 

EBased on the above generation listing and the directory listing, you Amust now translate each module generation to the associated file Gversion number---this information allows you to remove the appropriate Bmodule generations. Each generation of the module must be checked Eagainst the directory listing and the generation tree. The following Ctwo commands must be issued---the first command is issued once per Amodule, and the second is issued once for each module generation:

 

" *VSC> SHOW MODULE [DDTM]DDTMKIT.BCK/FULL4VSC> FETCH/OUT=TT:/GENERATION=n [DDTM]DDTMKIT.BCK 

CThe above commands are used to determine the generation-to-version Hmapping, and to ensure that the module uses a marker file. Based on the Hdirectory listing, on the generation-to-version translation, and on the Cknowledge of which versions are in streams that are unlikely to be Fimmediately required, a review of the files that can be offloaded can Fbe conducted. Based on the results of the review, a command procedure (similar to the following can be created:

 

" $ SET NOON $ ($! Ignore any higher-version warnings.. $ 8$ READ/PROMPT="^Z TO ABORT, <RET> TO CONTINUE " - 3 /ERROR=DONE/END_OF_FILE=DONE SYS$COMMAND YESNO $ =$ CREATE/DIRECTORY VDE$RESD1$:[941002_VMS_MASD_CLEANUP.DDTM] '$ COPY VMS$:[DDTM.SRC]DDTMKIT.BCK;54 - . VDE$RESD1$:[941002_VMS_MASD_CLEANUP.DDTM] '$ COPY VMS$:[DDTM.SRC]DDTMKIT.BCK;53 - . VDE$RESD1$:[941002_VMS_MASD_CLEANUP.DDTM] A$ CREATE/DIRECT VDE$RESD1$:[941002_VMS_MASD_CLEANUP.DECW$DEVICE] 2$ COPY VMS$:[DECW$DEVICE.SRC]DECWINDOWS000.B;18 - 5 VDE$RESD1$:[941002_VMS_MASD_CLEANUP.DECW$DEVICE] 2$ COPY VMS$:[DECW$DEVICE.SRC]DECWINDOWS000.C;17 - 5 VDE$RESD1$:[941002_VMS_MASD_CLEANUP.DECW$DEVICE] 2$ COPY VMS$:[DECW$DEVICE.SRC]DECWINDOWS000.D;18 - 5 VDE$RESD1$:[941002_VMS_MASD_CLEANUP.DECW$DEVICE] 2$ COPY VMS$:[DECW$DEVICE.SRC]DECWINDOWS000.E;13 - 5 VDE$RESD1$:[941002_VMS_MASD_CLEANUP.DECW$DEVICE] 2$ COPY VMS$:[DECW$DEVICE.SRC]DECWINDOWS000.E;11 - 5 VDE$RESD1$:[941002_VMS_MASD_CLEANUP.DECW$DEVICE] 2$ COPY VMS$:[DECW$DEVICE.SRC]DECWINDOWS000.F;11 - 5 VDE$RESD1$:[941002_VMS_MASD_CLEANUP.DECW$DEVICE] 9$ CREATE/DIRECT VDE$RESD1$:[941002_VMS_MASD_CLEANUP.IPC] %$ COPY VMS$:[IPC.SRC]IPCKIT.BCK;47 - - VDE$RESD1$:[941002_VMS_MASD_CLEANUP.IPC] 8$ CREATE/DIRECT VDE$RESD1$:[941002_VMS_MASD_CLEANUP.LM] #$ COPY VMS$:[LM.SRC]LMKIT.BCK;47 - , VDE$RESD1$:[941002_VMS_MASD_CLEANUP.LM] =$ CREATE/DIRECT VDE$RESD1$:[941002_VMS_MASD_CLEANUP.STARLET] .$ COPY VMS$:[STARLET.SRC]VIC_STARLET.OBJ;32 - 1 VDE$RESD1$:[941002_VMS_MASD_CLEANUP.STARLET] .$ COPY VMS$:[STARLET.SRC]VIC_STARLET.OBJ;29 - 1 VDE$RESD1$:[941002_VMS_MASD_CLEANUP.STARLET] <$ CREATE/DIRECT VDE$RESD1$:[941002_VMS_MASD_CLEANUP.SYSLIB] )$ COPY VMS$:[SYSLIB.SRC]VAXCDEF.TLB;30 - 0 VDE$RESD1$:[941002_VMS_MASD_CLEANUP.SYSLIB] )$ COPY VMS$:[SYSLIB.SRC]VAXCDEF.TLB;28 - 0 VDE$RESD1$:[941002_VMS_MASD_CLEANUP.SYSLIB] $ 8$ READ/PROMPT="^Z TO ABORT, <RET> TO CONTINUE " - 3 /ERROR=DONE/END_OF_FILE=DONE SYS$COMMAND YESNO $ /$ DELETE VMS$:[DDTM.SRC]DDTMKIT.BCK;54 /$ DELETE VMS$:[DDTM.SRC]DDTMKIT.BCK;53 6$ DELETE VMS$:[DECW$DEVICE.SRC]DECWINDOWS000.B;18 6$ DELETE VMS$:[DECW$DEVICE.SRC]DECWINDOWS000.C;17 6$ DELETE VMS$:[DECW$DEVICE.SRC]DECWINDOWS000.D;18 6$ DELETE VMS$:[DECW$DEVICE.SRC]DECWINDOWS000.E;13 6$ DELETE VMS$:[DECW$DEVICE.SRC]DECWINDOWS000.E;11 6$ DELETE VMS$:[DECW$DEVICE.SRC]DECWINDOWS000.F;11 .$ DELETE VMS$:[IPC.SRC]IPCKIT.BCK;47 -$ DELETE VMS$:[LM.SRC]LMKIT.BCK;47 2$ DELETE VMS$:[STARLET.SRC]VIC_STARLET.OBJ;32 2$ DELETE VMS$:[STARLET.SRC]VIC_STARLET.OBJ;29 1$ DELETE VMS$:[SYSLIB.SRC]VAXCDEF.TLB;30 1$ DELETE VMS$:[SYSLIB.SRC]VAXCDEF.TLB;28 $ 8$ READ/PROMPT="^Z TO ABORT, <RET> TO CONTINUE " - 3 /ERROR=DONE/END_OF_FILE=DONE SYS$COMMAND YESNO $ =$ COPY SYS$SCRATCH:Q.Q VMS$:[DDTM.SRC]DDTMKIT.BCK;54 =$ COPY SYS$SCRATCH:Q.Q VMS$:[DDTM.SRC]DDTMKIT.BCK;53 D$ COPY SYS$SCRATCH:Q.Q VMS$:[DECW$DEVICE.SRC]DECWINDOWS000.B;18 D$ COPY SYS$SCRATCH:Q.Q VMS$:[DECW$DEVICE.SRC]DECWINDOWS000.C;17 D$ COPY SYS$SCRATCH:Q.Q VMS$:[DECW$DEVICE.SRC]DECWINDOWS000.D;18 D$ COPY SYS$SCRATCH:Q.Q VMS$:[DECW$DEVICE.SRC]DECWINDOWS000.E;13 D$ COPY SYS$SCRATCH:Q.Q VMS$:[DECW$DEVICE.SRC]DECWINDOWS000.E;11 D$ COPY SYS$SCRATCH:Q.Q VMS$:[DECW$DEVICE.SRC]DECWINDOWS000.F;11 <$ COPY SYS$SCRATCH:Q.Q VMS$:[IPC.SRC]IPCKIT.BCK;47 ;$ COPY SYS$SCRATCH:Q.Q VMS$:[LM.SRC]LMKIT.BCK;47 @$ COPY SYS$SCRATCH:Q.Q VMS$:[STARLET.SRC]VIC_STARLET.OBJ;32 @$ COPY SYS$SCRATCH:Q.Q VMS$:[STARLET.SRC]VIC_STARLET.OBJ;29 ?$ COPY SYS$SCRATCH:Q.Q VMS$:[SYSLIB.SRC]VAXCDEF.TLB;30 ?$ COPY SYS$SCRATCH:Q.Q VMS$:[SYSLIB.SRC]VAXCDEF.TLB;28 $ $ EXIT $ $DONE: $ EXIT  

CThe above command procedure is used to substitute a stub file---an Eexample Q.Q stub file follows---for the original version of the file.

 

" 3 *** this file was archived as of Oct 2, 1994 *** 3 *** Contact [name], at [email-address] ***  



CThe end result of the above commands and command procedures is the Hrelocation of the larger modules---those that are referenced via marker 9files---and out of the VDE library. Should the offloaded Bgeneration of the file be reserved or fetched for any reason, the H"archived" notice will be returned. The archived file must be Fmanually located and retrieved from online or offline storage. (It is Dtypically good practice to indicate the particular location of this storage in the stub file.)

6A future version of VDE may include the capability to E"tie off" streams and offload modules referenced by marker 'files in an easier and cleaner fashion.