Conference orarep::nomahs::repository

1077.0. "ACCVIO in CDO doing an extract" by M5::GHODSON () Tue Apr 01 1997 19:16

Hi:

I have a customer using CDD 6.1 with Rdb 6.1-04 on an Alpha VMS 6.2
system.  This is a new installation.  

He copied his cdd.dic and a subdictionary sparks_record.dic from his
vax running cdd 4.2 to this alpha.  He is using the cdd$compatibility
that was created by the CDD installation.  He can go into datatrieve
and see all his records,...  He can use DMU to extract the records.  
He is getting an accvio when compiling DECforms when it attempts to 
copy a form from CDD.

We have determined that the very same ACCVIO occurs in CDO when his
cdd$default is defined to the cdd$top.record.location, and he goes into
CDO and does an extract record.  If cdd$default is defined to be cdd$top or 
cdd$compatibility and the default is set to cdd$top.record.location while 
in CDO, then the extract record works fine.

Here is the accvio:
CDO> extract record cho_rec
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=01E33FC0, 
=00A6CC4C, PS=0000001B

  Improperly handled condition, image exit forced.
    Signal arguments:   Number = 00000005
                        Name   = 0000000C
                                 00000004
                                 01E33FC0
                                 00A6CC4C
                                 0000001B

    Register dump:
    R0  = 0000000000D673B8  R1  = 0000000000000000  R2  = 0000000000B6BF48
    R3  = 0000000000000002  R4  = 0000000001E2C7CC  R5  = 0000000001E23900
    R6  = 0000000000000000  R7  = 0000000000D673B8  R8  = 0000000001E42398
    R9  = 0000000000D673B8  R10 = 0000000000000000  R11 = 0000000001E2ADF8
    R12 = 0000000000000000  R13 = 0000000000000000  R14 = 0000000000000000
    R15 = 0000000001CF20E0  R16 = 0000000000D673DC  R17 = 0000000000000000
    R18 = 0000000001E42398  R19 = 0000000000000195  R20 = 0000000000000000
    R21 = 0000000000D63826  R22 = 0000000001000000  R23 = 0000000001000106
    R24 = 0000000000D67DDC  R25 = 0000000000000003  R26 = 0000000000A6CD10
    R27 = 0000000000B6BF48  R28 = 0000000000000000  R29 = FFFFFFFF80E47E00
    SP  = 000000007EE08000  PC  = 0000000000A6CC4C  PS  = 000000000000001B


After dialing into his system and looking around, I have gathered this
information:

$ mcr cdo
CDO> set def cdd$compatibility
CDO> dir

 Directory SYS$COMMON:[CDDPLUS] 

    ...
SPARKS_DEV                                       DIRECTORY

$ mcr dmu
DMU> list/type=subdictionary cdd$top>

   CDD$TOP
   |  SPARKS_DEV <SUBDICTIONARY> : SPARKS_DEV:[SRC]SPARKS_RECORDS
        
    ...

$ show log sparks_dev

   "SPARKS_DEV" [exec] = "EQS005$DRB0:[SPARKS.DEV_PROGRAMS.]"
        [concealed.terminal (LNM$SYSTEM_TABLE) 

On my system I tried setting up the same situation and can not even get
cdd 6.1 to allow this:


$ create/directory DISK$USR3:[GHODSON.sparks]
$ create/directory DISK$USR3:[GHODSON.sparks.dev_programs]
$ create/directory DISK$USR3:[GHODSON.sparks.dev_programs.src]
$ define/system/exec/tran=(conc,term) -
  sparks_dev DISK$USR3:[GHODSON.sparks.dev_programs.]
$ mcr dmu
DMU> create/subdictionary=sparks_dev:[src]sparks_record sparks_dev
%DMU-E-BADDEFLT, command aborted because CDD$DEFAULT cannot be used
-CDD-E-NODNOTFND, directory or object not found
-DMU-W-CDDTOPDEF, your default directory is now CDD$TOP
DMU> exit

I then just tried:

$ define/sys/exec subdic disk$usr3:[ghodson]
%DCL-I-SUPERSEDE, previous value of SUBDIC has been superseded
$ mcr dmu
DMU> create/subdictionary=subdic:my.dic subdic1
DMU>  Exit
$ mcr dmu
DMU> create/subdictionary=subdic:my1.dic subdic
%DMU-E-CDDERROR, CDD error at "SUBDIC"
-CDD-E-CDDONLY, you cannot perform this call on a CDO dictionary node
DMU> create/subdictionary=disk$usr3:[ghodson]my2.dic subdic
%DMU-E-CDDERROR, CDD error at "SUBDIC"
-CDD-E-CDDONLY, you cannot perform this call on a CDO dictionary node
DMU>

Is there a problem with having a system logical that is the same as the 
dmu subdictionary name?  Was this a problem back on CDD 4.x? 

Thanks for any input.

--Gary Hodson

    more info:
    
    I found that by doing
    
    DMU> create/subdictionary=sparks_dev:[src]sparks_record _sparks_dev
    
    I could get the subdictionary defined in DMU.  Is this still asking
    for trouble in having the subdictionary and logical the same name?
    
    

~    I could get the subdictionary defined in DMU.  Is this still asking
~    for trouble in having the subdictionary and logical the same name?

Well you seem to have answered your own question...  Did you have trouble?

I think the answer was "yes".

Ian

Hi Gary,

>We have determined that the very same ACCVIO occurs in CDO when his
>cdd$default is defined to the cdd$top.record.location, and he goes into
>CDO and does an extract record.  If cdd$default is defined to be cdd$top or 
>cdd$compatibility and the default is set to cdd$top.record.location while 
>in CDO, then the extract record works fine.

	Is he running the standard 6.1 version of CDD/Repository ? An ECO will 
	be better and the last one ( ECO 3 ), the even best. 
	In CDD$TOP.RECORD.LOCATION, is RECORD and LOCATION CDO directories or
	DMU directories? Or is it a replacement for CDD$TOP.SPARKS_DEV ?

>Is there a problem with having a system logical that is the same as the 
>dmu subdictionary name?  Was this a problem back on CDD 4.x? 

	CDD is not able to know when you want to use the name versus when you 
	want to use the logical name. Therefore, as soon as you use a logical 
	name, it prevents the use of this word for other purpose. The VMS 
	mechanism to contrary this is the use of the underscore as you found
	it out. 

Patrick

    Thanks Patrick.  I suspected that having a system logical and 
    subdictionary with the same name could cause problems with CDO.
    I am going to have the customer try creating a new logical,
    deassign the sparks_dev logical, and then go into DMU and do a
    "RENAME/AUDIT/SUBDICTIONARY=..."  He also is using CDD 6.1
    unpatched.  I will try to get him to upgrade to eco 3 or version 7.
    
    --Gary