Conference orarep::nomahs::dbintegrator_public_public

Hi Patrick,

We had Rdb 6.1-1 Standard and Rdb v7.0 MV running on our system with
DBI 3.1A and everything was working ok.  We never tried to install 3.1A
as it was already installed.  We just installed DBI v7 about a month ago
and that seems to be ok too.

Rdmshrp.exe, rdmprv.exe should be the 6.1 images and rdmshrp70.exe,
rdmprv70.exe the 7.0 images.  Looks like it is trying to activate v6.1
images but something is set to v7.  Were you set to the standard version
of Rdb when you installed 3.1A?  

I'm not sure what is going on with your system and will defer that to
engineering, but could I ask why don't you install dbi v7?  This was 
officially released in January.

Diane

Hi Patrick,

I was looking in the Rdb notes file and some notes said that images
have to be registered.  See notes 1710 and 4903.  These were mostly
related to vms 7.0 and I see you are on 6.2 but I did see one
reference to vms 6.0 and up.  Assuming both Rdb installations were
working ok before the dbi installation, I cannot explain why the
images would no longer be registered.  Is it possible someone did
a vms upgrade before the dbi installation?  Hopefully the information
in the above notes might get you out of your current state.

Diane

Hi Diane,

This is a mistery but I finally succeeded in installing Distributed option
3.1A but I still don't understand why it failed and why it succeeded.

But first, let me answer to your questions:

>                                    Were you set to the standard version
>of Rdb when you installed 3.1A?  

	I have a symbol which do "@SYS$SHARE:decRDB$setVER 6.1". I used it 
	just before the @sys$update:vmsinstal

>I'm not sure what is going on with your system and will defer that to
>engineering, but could I ask why don't you install dbi v7?  

	I ordered DBI V7.0 but I didn't received it yet. Thus I installed 
	what I have that is 3.1A.


Here is what has been done to make it work.
I checked that all images were correctly registerd through :
	$ @ sys$update:REGISTER_PRIVILEGED_IMAGE show epc$shr
	$ @ sys$update:REGISTER_PRIVILEGED_IMAGE show RDMSHRP
	$ @ sys$update:REGISTER_PRIVILEGED_IMAGE show RDMPRV
We finally killed the RDMS_MONITOR process by STOP/IDENTIFICATION command and 
restarted it by RMONSTART.COM. At this point, RMU/SHOW SYSTEM shows Rdb V6.1-1. 
A @SYS$UPDATE:VMSINSTAL then runs exactly the same as previously ( except that 
[SYSHLP.EXAMPLES.DBI] creation has been skipped ) but this time it succeeded !
What is strange is that I show before the speach "This procedure creates 3 Rdb
databases," I see :
    Current PROCESS SQL environment is version V7.0-0 (MULTIVERSION)
    Current PROCESS Rdb/Dispatch environment is version V7.0-0 (MULTIVERSION)
Why does it set Rdb to 7.0 when I was initially set to 6.1-1, and when, I 
checked it, after the installation I am still in Rdb 6.1-1 ?  

Strange isn't it ? I hate to see things unexplained so thank you for any ideas?

Patrick.

>Why does it set Rdb to 7.0 when I was initially set to 6.1-1, and when, I 
>checked it, after the installation I am still in Rdb 6.1-1 ?  
>
>Strange isn't it ? I hate to see things unexplained so thank you for any ideas?

DBI usually issues a setver to the highest version of Rdb available on your
system.  If version 7.0 is installed, the highest version on your system in
7.0, not 6.1-1.  The installation perhaps set that in the context of the 
"job" or installation, but when it was complete, the setver for the process
was gone and the one you initially set up returned.  I don't know the 
internals of the installation, but this is my guess.  Engineering would have
to confirm this.

Renee

Hi Patrick,

Here's a bit more clarification although what actually happened
during your first install still remains!

DBI needs a minimum of SQL 6.0 to operate.  Additionally DBI needs
the highest version of Rdb/Dispatch to be enabled whenever it is run.

The IVP procedure does two things:

1.  Executes sys$library:dbi_user_setup.com to set the logical 
rdb$enable_highest_version "ON".  This is needed because dbi assumes the 
highest version of Rdb/Dispatch on a system is used and makes calls based 
on that assumption.  In this case v7.

2.  Sets the environment to the highest version of common components
on your system executing the procedure @sys$library:sql$setver.
In your case this would be v7.  The common components are Rdb/Dispatch
and SQL.  That is why you see the following in your installation log:

>    Current PROCESS SQL environment is version V7.0-0 (MULTIVERSION)
>    Current PROCESS Rdb/Dispatch environment is version V7.0-0 (MULTIVERSION)

This is done in order to ensure that a minimum of SQL 6.0 is used
(required for DBI).  Since DBI catalogs can exist in pre-6.0 databases,
there is the possibility that users will not set up the installation
environment to use the higher version of SQL.

The version of Rdb remains what you set your process to using the procedure
decrdb$setver, in your case 6.1.  Or to the standard version of Rdb
if decrdb$setver is not run and a standard version exists.  This determines 
what version of Rdb to use for your dbi catalog (metadata storage).

Diane

Thanks for the clarification Diane!!  :)

Renee