| PreviousZ | Contents\ | Index |
FThis section includes a code example that shows the steps involved in Hthe conversion from a major CMS-based project into a project based on a 6VDE database. The project involves the importation of =multiple CMS libraries for the various software units---what VDE calls facilities---into9VDE. Each facility is organized in a CMS library located =under the project-specific root directory DISK$EVMSCMS:[VMS].
GDuring the execution of the attached example code, no changes 4to the format of the CMS libraries are made. |
DBefore performing the CREATE FACILITY/FROM_CMS_LIBRARY command, one :must create all VDE streams---those streams with the same Ename as the CMS classes to be uploaded from the CMS library into the >VDE database, and one must also specify the /MAIN or /NOMAIN, E/PARENT and /SUCCESSOR values correctly. If these operations are not Dcorrectly created and configured before issuing the CREATE EFACILITY/FROM_CMS_LIBRARY command, CMS generation selection, and the Fvariant and mainline streams will not be correctly configured. |
|
" $ set noon $ 5$! These logicals will need to be (re)defined in the 3$! site-specific system startup command procedure. $ G$ Define/System/Executive/Nolog VMS$ DISK$EVMSCMS:[VMS.]/Trans=Conceal 9$ Define/System/Executive/Nolog VSC$DATADISK $10$DKB400: 9$ Define/System/Executive/Nolog VSC$ROOTDISK $10$DKB400: 9$ Define/System/Executive/Nolog VSC$SNAPDISK $10$DKB400: 8$ Define/System/Executive/Nolog VSC$JNLDISK $10$DKB400: $ F$ Define/System/Executive/Nolog VSC$DBDATA VSC$DATADISK:[evms.dbdata] F$ Define/System/Executive/Nolog VSC$DBROOT VSC$ROOTDISK:[evms.dbroot] F$ Define/System/Executive/Nolog VSC$DBSNAP VSC$SNAPDISK:[evms.dbsnap] D$ Define/System/Executive/Nolog VSC$DBJNL VSC$JNLDISK:[evms.dbjnl] $ $ Create/Directory VSC$DBDATA $ Create/Directory VSC$DBROOT $ Create/Directory VSC$DBSNAP $ Create/Directory VSC$DBJNL $ $ VDE "create librar VSC$DBROOT /DEFER - , /NAME=EVMS /REMARK="EVMS Source Library" - ? /NOAUTO_CONVERT /AUTO_ADD_USER=VMS_SOURCE /AUTO_MAIL - 8 /ASK_INFO_FILE /ASK_REPL_CAUSE /SHOW_GEN_EXPR - ; /NOHISTORY_NOTES /NOALLOW_DELETE /NOWILD_INS_GEN - 6 /NOCMS_ELEM_HIST /CREATOR="Stephen Hoffman" - * /DEF_PRIVILEGES=(CREMOD,RESREP) - + /AUTH_PRIVILEGES=(CREMOD,RESREP) - 4 /data=VSC$DBDATA/journ=VSC$DBJNL/snap=VSC$DBSNAP - ! SHOW DEFAULTS SHOW LIBRARY/FULL 2MODIFY CONTEXT/PUBLIC DEFAULT/NOSTREAM/NOFACILITY ! (SET DIRECTORY/DELTA_FILES VMS$:[000000] 6SET DIRECTORY/DELTA_FILES/SUBDIRECTORY=VDE$CMS [.CMS] 9SET DIRECTORY/DELTA_FILES/SUBDIRECTORY=VDE$MARKER [.SRC] QMODIFY FACILITY CODE/NAME=AAA_VDE_TEST/REMARK="Test facility for VDE developers" "CREATE DIRECTORY_TREE/DELTA_FILES ! SHOW DIRECTORY/DELTA_FILES ! D! Set to the AAA_VDE_TEST facility for use by database administion, -! and populate it with a test module or two. ! SET FACILITY AAA_VDE_TEST LCREATE MODULE/NODELETE/REMARK="VDE test module" LOGIN.COM /INPUT=SYS$LOGIN: VCREATE MODULE/NODELETE/REMARK="VDE test module" SYSTARTUP_VMS.COM /INPUT=SYS$STARTUP: ! .SET DIRECTORY/STAGING disk$common:[vms.stage] CREATE DIRECTORY_TREE/STAGING ! H! Rename stream MAIN to be MAINLINE. We will use this stream for a few J! selected modules that should always stay on the main development thread *! outside the normal development streams. ! OMODIFY STREAM MAIN/NAME=MAINLINE/REMARK="Mainline thread for selected modules" SHOW STREAM/FULL MAINLINE /SET DIRECTORY/STREAM disk$common:[VMSMAINLINE] CREATE DIRECTORY_TREE/STREAM ! F! Create the V6.1 parent stream to all others streams. Specification E! of /MAIN or /NOMAIN, and /PARENT and /SUCCESSOR are key factors in D! the CMS generation selection and the propogation processing. All D! streams must be created prior to specification of CREATE FACILITY <! /FROM_CMS_LIBRARY. See the reference manual for details. ! SET STREAM MAINLINE MCREATE STREAM/CLOSED/MAIN V6.1/PARENT=MAINLINE/REMARK="create release class" ICREATE STREAM/CLOSED/MAIN V6.2/PARENT=V6.1/REMARK="create release class" ICREATE STREAM/CLOSED/MAIN V6.3/PARENT=V6.2/REMARK="create release class" ! SHOW DIRECTORY/DELTA_FILES ! Exit $ SHOW TIME $ VDE ,create facility ACAS/FROM_CMS/REMARK="ACAS" 1create facility ACC/FROM_CMS/REMARK="Accounting" 4create facility ACLEDT/FROM_CMS/REMARK="ACL Editor" .... 2create facility ZSYSGEN/FROM_CMS/REMARK="ZSYSGEN" 2create facility ZSYSVER/FROM_CMS/REMARK="ZSYSVER" Exit $ SHOW TIME |
=VDE includes example command procedures and associated files Cin VDE$EXAMPLES:, the core example procedure used for uploading an 7existing CMS library into VDE is VDE$CREATE.COM. Files Aassociated with VDE$CREATE.COM will need to be tailored to local >requirements and to the local CMS library directory structure.
;To avoid losing any changes made during any subsequent VDE 9upgrades, relocate the example command procedures into a ;non-VDE directory before making any edits. |
|Also see Section 6.1.1 for information on VDE$UPLOAD, a tool that can Hdirectly perform the task of library creation based on a description of 2the desired VDE database contained in a data file.O
8Adding modules into a VDE library is a simple operation.
|
" 8VDEä CREATE MODULE/NODELETE/REMARK="user login module" -&_VDEä LOGIN.COM /INPUT=SYS$LOGIN: |
=This chapter explains how how to perform various maintenance Hoperations. These operations include clearing deadlocks, performing the Fsource code database backups, creating and maintaining the associated ?backup procedures, restoring the database after a failure, and :recovering lost information in the CMS libraries on a VDE Hlibrary. Also included are the procedures involved in periodic cleanups Aof the staging area directories, and one approach toward storage :recovery within VDE libraries. Some of these commands and Aoperations will require you to have the OpenVMS SETPRV or SYSPRV privileges.
HOperations described in this chapter are normally performed only by the 6maintainers of the OpenVMS VDE libraries, or by those *users maintaining their own VDE libraries.
@The command procedures described in this chapter are located in :directory MASD$JNL:[VMS.TOOL] on the journal disk for the 4OpenVMS VDE libraries. Because these procedures may Hbe needed in case of journal disk failures, they are also stored in the directory VMS$:[TOOLS].c
FFor the automatic submission of the SCT note to operate properly, the FSCT notes conference must have the correct protections. The following Fshows the commands necessary to enable the security necessary for the typical SCT notes conference:
|
" $ set security/acl=- 0_$ ((IDENTIFIER=VMS_SOURCE_READ,ACCESS=R+W+E),- ,_$ (IDENTIFIER=VMS_SOURCE,ACCESS=R+W+E)) - _$ NOTES$LIBRARY:SCT-*.NOTE $ set security/acl=- 4_$ ((IDENTIFIER=[DECNET,NOTES$SERVER],ACCESS=R+W),- (_$ (IDENTIFIER=NETWORK,ACCESS=NONE)) - (_$ /PROTECTION=(S:RWED,O:RWED,G:RE,W) - _$ NOTES$LIBRARY:SCT-*.NOTE |
DFailure to correctly set up the security attributes can prevent the creation of SCT entries by VDE.U
GDepending on requirements, one can use the MODIFY LIBRARY/LOCK command 9to mark a particular VDE library as read-only to all but :privileged VDE users, and one can define the logical name ;VDE$OFFLINE to take the VDE environment completely offline.
|
" ($ Define/System/Executive VDE$OFFLINE - &_$ "Down for maintenance until 23:00" |
:Users with privileges within VDE can override the library Flockout; a message indicating that a library lock is being overridden @is displayed in this situation. For further information on this Aparticular command, see the VDE Reference Manual manual.
FShort of deassigning the VDE$OFFLINE logical name, there is no way to Coverride the VDE$OFFLINE lockout---the VDE$_OFFLINE message and theF translation of the logical name will be displayed to all users. Once H this privileged logical name has been defined, users cannot invoke the 2 VDE images, and users already executing VDE will * be unable to invoke any new VDE commands.
<Note that it can be difficult to debug certain VDE problems :when the VDE$OFFLINE lockout is in place, as even the VDE :maintainers cannot invoke the VDE images. This lockout is :best suited for the protection of Rdb and CMS maintenance operations.a
9Various things have been seen to go wrong within VDE, or 4within Rdb. Failures include deadlocks, and various ;Rdb problems that result in process-level and system-level bugcheck dumps.
3VDE has occasionally been known to deadlock at the <Rdb level. This deadlock condition is usually heralded by a <series of "VDE is wedged" complaints from various vociferous VDE users.
=Before attempting to clear a "stuck" VDE database, Afirst determine if there is a valid reason for sluggish database 0access. VDE or Rdb commands executed by another Bdatabase user. Project leaders use some commands and perform some ?operations that can potentially be quite time-consuming, while 2Rdb database backups are notorious for clobbering :performance. Any of these can lead to intervals where the 9VDE database processing is extremely sluggish or various commands are locked out. |
CProcess-level deadlocks occur infrequently, and they often involve Ehigh-traffic applications such as database backups or they involve a ;VDE command that was paused via [XOFF] command, Fand they can usually be easily and safely cleared using the following command:
|
" &$ RMU/CLOSE/CLUSTER/ABORT=DELPRC/WAIT- _$ VDE$:[ROOTDIR]VDE$DATABASE |
;To use the RMU/CLOSE command, you must possess the OpenVMS <SYSPRV or BYPASS privilege, or you must have access via the ;Rdb database access control list. If the RMU/CLOSE command Changs for an extended interval (it should hang for a while pending Hcluster-wide closure), see if the "freeze" deadlock mentioned Kin Section 7.3.2 has occured.7
=It is possible for Rdb processes to deadlock waiting for the Rdb "freeze" resource.
BWhen a "freeze" deadlock occurs, one normally finds any <attempt to SET LIBRARY to the VDE library or to run various <RMU commands---including the RMU/CLOSE command mentioned in oSection 7.3.1 -- against the library will hang indefinitely. This 6deadlock can survive the shutdown of all Rdb database Hmonitors, though a shutdown of the node holding the deadlocked recovery !process can relieve the deadlock.
?The following example shows the particular process holding the "freeze" lock:
|
" $ RMU/SHOW LOCK/MODE=BLOCKING K========================================================================== SHOW LOCKS/BLOCKING Information K========================================================================== K-------------------------------------------------------------------------- Resource: freeze K ProcessID Process Name Lock ID System ID Requested Granted K --------- --------------- --------- --------- --------- ------- FWaiting: 224018E0 SHOFFMAN_00E0.. 3F00433E 00010002 CW NL FBlocker: 20402DC8 RDM_RB60_1..... 5D00A098 00010002 PR PR |
;Rdb generates a dump file when it encounters an unexpected ;condition. Under typical circumstances, Rdb will display a -message indicating a dump is being generated.
|
" VDE> set lib evms 9Generating bugcheck dump file WORK10:[user]RDSBUGCHK.DMP |
FOne potential cause is the inability to write to the run-unit journal _area, see Section 7.3.4 for information for details.B
8The run-unit journal area is a key component of the Rdb 5processing, and allows Rdb to rollback incomplete or Gerroneous database operations. And when an unexpected condition occurs =with the run-unit journal, Rdb tends to generate a dump file.
DErrors involving the run-unit journal have a variety of footprints, <including symptoms such as process-level Rdb bugcheck dumps and user process deletions.M
FIf the run-unit journal area is entirely messing, one can potentially =see an Rdb bugcheck dump generated. By default, the run-unit Bjournal is written to SYS$LOGIN_DEVICE:[RDM$RUJ], but this can be *altered via the Rdb RDMS$RUJ logical name.
|
" VDE> set lib evms 9Generating bugcheck dump file WORK10:[user]RDSBUGCHK.DMP |
4For any user seeing these errors, make certain that GSYS$LOGIN_DEVICE:[RDM$RUJ] exists and is owned by [SYSTEM]. If it does Hnot exist, create it. (Note that the directory is actually based on the Fdevice from SYS$LOGIN:, not from the SYS$LOGIN_DEVICE: specification.)
|
" 2$ create/directory work10:[rdm$ruj]/owner=[system] $ set security/owner=[system] -,_$ work10:[000000]rdm$ruj.dir,[rdm$ruj]*.*.*$ run sys$system:sysman"SYSMAN> DISKQUTA ADD [SYSTEM] -0_SYSMAN> /DEVICE=WORK10/PERM=100000/OVER=1000 SYSMAN> [CTRL/Z] |
6Based on Rdb documentation, one can also redirect the =location of the SYS$LOGIN_DEVICE:[RDM$RUJ] directory via the /Rdb RDMS$RUJ logical name. (Note that Rdb does Dnot actually use SYS$LOGIN_DEVICE:, it appears to parse SYS$LOGIN:.)
>This particular error is more common on volumes that were not $initialized with [SYSTEM] ownership:
|
" "$ INITIALIZE work10: work10/SYSTEM |
cAlso see Section 7.3.4.2 for a related problem.W
9Rdb requires the creation of a run-unit journal file. By >default, this is in the user's login device, in the directory C[RDM$RUJ], and this location can be altered using the logical name BRDMS$RUJ. If this creation operation fails or due to insufficient (quota, one can see the following errors:
|
" $ vde/library=evms 7%RDB-F-SYS_REQUEST, error from system services request 8-RDMS-F-FILACCERR, error creating run-unit journal file 3WORK1:[RDM$RUJ]VDE$DATABASE$0099C91EC6BCC945.RUJ;1 #-RMS-E-CRE, ACP file create failed +-SYSTEM-F-EXDISKQUOTA, disk quota exceeded |
|
" $ set security/owner=[system] -+_$ work1:[000000]rdm$ruj.dir,[rdm$ruj]*.*.*$ run sys$system:sysman"SYSMAN> DISKQUTA ADD [SYSTEM] -/_SYSMAN> /DEVICE=WORK1/PERM=100000/OVER=1000 SYSMAN> [CTRL/Z] |
\Also see Section 7.3.3 for a related situation.M
4Rdb generates a dump file when the recovery process xencounters an unexpected condition. (See Section 7.3.4.4 for one example Dof an unexpected condition.) There may or may not be any indication Fthis dump is being written---in one particular case, the process that Ewas triggering the failing recovery process was being logged off the system.
GUnder typical circumstances, the recovery process dump file is written Gto SYS$SYSTEM:RDMDBRBUG.DMP. The following is an example of a recovery process dump file:
|
" Q================================================================================ = Bugcheck dump SYS$SYSROOT:[SYSEXE]RDMDBRBUG.DMP;17 Q================================================================================ >This file was generated by DEC Rdb V6.0-1 upon detection of a Afatal, unexpected, error. Please return this file, the query or ?program that produced the bugcheck, the database, monitor log, 1and any other pertinent information with an SPR. (Current time is 21-JAN-1997 15:20:21.10 H 3-FEB-1997 16:23:35.84: Linked DBR (RDBVMS) RDMS$ALPHA_V0601:[KODABLD] H25-JAN-1997 08:06:24.32: Compiled KOD$DBR (KODA) KOD$ALPHA_V0601R:[DBR] M25-JAN-1997 08:06:15.13: Compiled KOD$LIBRARY (KODA) KOD$ALPHA_V0601R:[CODE] Q================================================================================ Stack Dump Q================================================================================ 6Saved PC = 001383C0 : STD$DUMP_ALPHA_STACK + 00000090 3Saved PC = 001212E4 : KOD$BUGCHECK_DUMP + 00000D74 =Saved PC = 000A1214 : KOD$BUGCHECK_AND_EXIT_HNDLR + 00000094 !Saved PC = 80895D44 : S0 address !Saved PC = 962A62BC : S0 address 5***** Exception at 0006B930 : DBR$RECOVER + 000009F0 7%RDMS-F-FILACCERR, error opening run-unit journal file 3WORK1:[RDM$RUJ]VDE$DATABASE$0099C91EC6BCC945.RUJ;1 +-SYSTEM-W-ACCONFLICT, file access conflict %Saved PC = 0006AB50 : DBR + 00000B90 +Saved PC = 00057F0C : BLI$CALLG + 000000BC *Saved PC = 0005011C : DBR$MAIN + 0000011C !Saved PC = 962D3C44 : S0 address +[...rest of dump file has been omitted...] |
|
" $ run sys$system:sysman"SYSMAN> set environment/cluster$SYSMAN> set profile/privilege=all.SYSMAN> do show device/file/nosystem work1: SYSMAN> [CTRL/Z] |
~A recovery-process dump similar to Section 7.3.4.3 can also be seen when Hthe RUJ file is missing. This can be a result in user process deletions 9and failed RMU backups, as well as other nasty behaviour.
&One sees the following in an RMU/DUMP:
|
" %Active user with process ID 38810DD3 Stream ID is 1 Monitor ID is 2 Transaction ID is 16 V Recovery journal filename is "WORK300:[RDM$RUJ]VDE$DATABASE$009A486CCA4B098E.RUJ; ' Read/write transaction in progress * Transaction sequence number is 183093 |
|
" 5***** Exception at 000253ED : DBR$RECOVER + 000005CB l%RDMS-F-FILACCERR, error opening run-unit journal file WORK300:[RDM$RUJ]VDE$DATABASE$009A486CCA4B098E.RUJ;1 -RMS-E-FNF, file not found |
HThere's no good solution to this problem if the file cannot be located, Gshort of locating the missing RUJ, or recovering the database from Rdb BACKUP.
CThe following steps will clear the missing RUJ and will leave the\ Fdatabase accessable, but the database is now likely corrupt. 'Recovery from RMU/BACKUP is preferable.
|
" E$ RMU/ALTER databasename(1)KRdbAlter> DISPLAY ROOT USER(2)TRdbAlter> DEPOSIT ROOT USER # RUJ=""(3)@RdbAlter> COMMIT(4)RdbAlter> EXIT<$ RMU/UNLOAD...(5)=$ RMU/VERIFY/ALL(6) |
| PreviousW | NextZ | Contents\ | Index |