Conference orarep::nomahs::repository

>         <<< Note 1082.0 by UKVMS3::PJACKSON "Oracle UK Rdb Support" >>>
>                 -< CDD-E-LCCNOTAVL from DATATRIEVE SHOW ALL >-
>
>    A customer is getting a CDD-E-LCCNOTAVL error when doing a SHOW ALL from
>    DATATRIEVE before doing a SET DICTIONARY. He has CDD 6.1-0.  CDD$DEFAULT
>    points to a new repository that was verified after creation, and then had
>    the directory created within it. DIR/FULL from CDO just reports that the
>    directory is empty.
>    
>    Any ideas?
>    
>    Peter

Peter,

I was about to post a problem (a bug in my opinion) but after seen your note
I thought it can be the same problem or related ... I hope it helps.

Anyway here is what I have experienced recently, CDD V 5.3 and DTR (this one
was on ALPHA - but VAXes might be the same).

$ define CDD$DEFAULT CDD$TOP.RECORDS	!This being SYS$COMMON:[CDDPLUS]RECORDS
$!                                      !as my CDD is in SYS$COMMON:[CDDPLUS]
$ DICTIONARY OPERATOR
CDD> SHOW DEFAULT
	SYS$COMMON:[CDDPLUS]RECORDS		<--- This is OK
CDD> SHOW RECORD <a-reord>
	| ...
	| it shows the reord			<--- This is OK
	| ...
CDD> SHOW DEFAULT
	SYS$COMMON:[CDDPLUS]DTR$TOP.RECORDS	<--- This is NOT OK --***--
                            ^^^^^^^

After showing the record my default directory has changed.
I found out that this is caused when DTR is installed with no CDD support
(A question during DTR installation)
We re-installed DTR with CDD support and everything is fine after that.

The problem (bug) that I complain about is why CDD gets affected by the way
another product is installed. CDD should be and act as independent of the
way DTR is installed. If DTR is installed with no CDD support then it should
be DTR's problem, not CDD's. I think that there is something wrong with the
hooks CDD has for DTR.

George

Hi George,

>$ define CDD$DEFAULT CDD$TOP.RECORDS	!This being SYS$COMMON:[CDDPLUS]RECORDS
>$!                                      !as my CDD is in SYS$COMMON:[CDDPLUS]
>$ DICTIONARY OPERATOR
>CDD> SHOW DEFAULT
>	SYS$COMMON:[CDDPLUS]RECORDS		<--- This is OK

	Did you redefine CDD$TOP ? Did you redefine CDD$DICTIONARY ? 
	Your DMU dictionary must not be in SYS$COMMON:[CDDPLUS]. A
        VERIFY/REBUILD or an upgrade can destroy it .  

Patrick

>    <<< Note 1082.2 by 8292::PJACOB "Patrick [email protected]" >>>
>                    -< CDD.DIC in SYS$COMMON:[CDDPLUS] ?  >-
>
>Hi George,
>
>>$ define CDD$DEFAULT CDD$TOP.RECORDS	!This being SYS$COMMON:[CDDPLUS]RECORDS
>>$!                                      !as my CDD is in SYS$COMMON:[CDDPLUS]
>>$ DICTIONARY OPERATOR
>>CDD> SHOW DEFAULT
>>	SYS$COMMON:[CDDPLUS]RECORDS		<--- This is OK
>
>	Did you redefine CDD$TOP ? Did you redefine CDD$DICTIONARY ? 
>	Your DMU dictionary must not be in SYS$COMMON:[CDDPLUS]. A
>        VERIFY/REBUILD or an upgrade can destroy it .  
>
>Patrick

Patrick

	-	CDD$TOP is not defined so I get my default dir to be:
		SYS$COMMON:[CDDPLUS]RECORDS

	-	CDD$DICTIONARY points to another device where CDD.DIC is
		located. The logicals always area in as:

		(LNM$SYSTEM_TABLE)
		  "CDD$COMPATIBILITY" = "SYS$COMMON:[CDDPLUS]"
		  "CDD$DICTIONARY" = "PRODDISK19:[SYSEXE]"
		  "CDD$EXTENSIONS" = "SYS$COMMON:[CDD_EXTENSIONS]"
		  "CDD$TEMPLATE" = "SYS$COMMON:[CDD$TEMPLATE]"
		  "CDD$TEMPLATEDB" = "SYS$COMMON:[CDD$TEMPLATEDB]"

	As I said in .1 no changes or other deviations from normal
	It WAS ONLY DTR that we re-installed and everything functioned OK
	after that.

	The three line script can demo it if you are willing to play (and
	have the time) with DTR installations. In our case DTR was installed
	before CDD if this sequense of events has anything to do with it.

George

Hi George,

>	-	CDD$TOP is not defined so I get my default dir to be:
>		SYS$COMMON:[CDDPLUS]RECORDS

	Sorry I was wrong in my interpretation of your SHOW DEFAULT.


>	The three line script can demo it if you are willing to play (and
>	have the time) with DTR installations. In our case DTR was installed
>	before CDD if this sequense of events has anything to do with it.

	I would be glad to test it but I had no 7.1 DTR kit nor DTR PAK. This 
	greatly reduces my possibilities to investigate this problem. Did you
	try to deassign DTR$DICTIONARY logical name when DTR was installed
	without CDD ?
       
Patrick

    Our customer getting the problem here definitely installed Datatrieve
    with the CDD option.
    
    In fact he only has problems with new dictionaries accessed by a
    non-privileged account.
    
    Louise.

.4

Patrick,

Peter and Louise might have a different problem. I should have create a new
note but I thought we are dealing with a single but doubled faced problem
since Peter (.0) mentioned DTR and DTR was the one which gave us the pain.

Here is the sequense of events.

1.	Digital delivered a brand new alpha (in fact 8 turbolasers) and a
	4100 preinstalled with DTR but no RDB and CDD on the system and DTR
	was installed with CDD options.

>        							    Did you
>        try to deassign DTR$DICTIONARY logical name when DTR was installed
>        without CDD ?

	I don't know since the machine was delivered with DTR installed, but
	I don't think any body did that. I guess this DTR$DICTIONARY logical
	wasn't even defined on that machine by the time they installed DTR
	since the machine was delivered with no RDB and CDD on it.

2.	We installed Rdb V6.0A-16 standard.

3.	We installed CDD V5.3. We took the default choices for CDD placement
	SYS$COMMON:[CDDPLUS].

	I changed the CDD$DICTIONARY sys/exec logical to point to another disk
	for the CDD.DIC (in PRODDISK19:[SYSEXE] ).

4.	We backed up the CDD from the production VAX/OpenVMS and we restored
	it on the ALPHA/OpenVMS (since we migrate VAX--> Alpha).

	The CDD.DIC file was already in PRODDISK19:[SYSEXE] since an image
	VAXbackup/ALPHArestore was done on it - otherwise I would have copy
	it there.

5.	I verified the CDD and the only message was about the node location
	and then I run verify/fix so to alter the CDD node location so it
	should be its new hosting node.

Note:	The problem I described in .1 was occuring in both cases before
	and after step #5.

6.	We re-installed DTR with CDD support.

7.	We are happy everything looks fine.


FINAL "tip" if this helps:

	In this customer all the RMS records are defined using DTR as the
	means to create new or alter old record definitions. They don't use
	the CDO define field and define record commands and I never tested
	this final case (with CDO define command) because by records were
	already been defined with DTR on the VAX side and I was trying
	to access (compile DECforms and 3GL programs) them on the ALPHA side.

George

    My customer's problem seems to have been solved by granting the user
    CHANGE access to to repository.
    
    Peter