Re: Oracle and the VMS delta time restriction

From: Wayne Sewell <wayne_at_tachyon.com-kill-spam-it-sux>
Date: 1997/04/24
Message-ID: <1997Apr24.122008.808@tachyon.com>#1/1

In article <335F6C0C.7F12_at_cri.dk>, Arne Vajhoej <ava_at_cri.dk> writes:
> Douglas Miller wrote:

>> 
>> Oracle Co. have told me that Oracle is affected by the VMS delta time restriction (of 9999 days on unpatched versions of VMS up to 7.0), and
>> recommended that any Oracle customer not running VMS 7.1 either upgrade or apply the Digital supplied patch to lift the restriction.
>> 
>> But they also claim that I will need to relink all Oracle and Oracle-related EXE's after applying the patch (for versions 6.0 thu 7.0). I can
>> find no evidence that anything in the Oracle linking procedures pulls in any of the affected libray routines directly out of STARLET.OLB, which
>> is surely the only thing that would mandate a rebuild.  Does anybody have any facts or opintions on this subject?  I really don't want to
>> relink unless I have to --- our Oracle environment is too complex for this to be an easy job.

>
> The patch pulls in a new SYS$SHARE:LIBRTL.EXE.
>
> It should no be specified in a link procedure.
>
> A relink should not be necesarry.
>
> FOR A NORMAL APPLICATION.
>
> A normal application does not need to be relinked after a VMS upgrade.
> Oracle does - even
> often needs an upgrade.
>
> I do not know what they do. I once spoke with a Digital VMS guru. He was
> also puzzeled about what Oracle were actualy doing.
>
> So even if it sounds strange, then you are probably better off doing
> exactly as Oracle tell you.
>
>

Probably true. I can confirm that they have done weird things in the past.

I was more than puzzled by the old Oracle link procedures. I had a hell of a time linking user applications, because Oracle had a based shareable image. This means it contained code that was not position independent, so it *had* to be linked at a fixed virtual address. (This was under an very early version of VMS, probably 2.x or 3.x, circa 1983, when the sizes and address ranges of referenced shareable images were actually stored within the executable image file, though the actual code was not. Nowadays, only the *name* of the shareable is stored in the image file and address mapping is done at runtime by the image activator.)

This in itself was kludgey, but not insurmountable, since the normal position independent shareable images would float around the fixed virtual address range. However, we had *another* vendor who didn't understand VMS and who *also* had a based shareable image. It was impossible to link the two shareable images into the same program, because they would try to map to overlapping address ranges and the linker would get hysterical. If I recall correctly, we couldn't do anything to change the conflicting base addresses, since that has to be done when the *shareable* is linked, not the main image referencing it. I don't think we had the capability of relinking the shareables, due to lack of objects. I'm sure we would have done that if we could have.

I have not used oracle for a long time (since the early eighties), so I have no idea what they are doing now, but the above does not surprise me.

Wayne

-- 
===============================================================================
Wayne Sewell, Tachyon Software Consulting  (214)553-9760  wayne_at_tachyon.xxx
http://www.tachyon.xxx/www/tachyon.html and wayne.html  
change .xxx to .com in addresses above, assuming you are not a spambot  :-)
===============================================================================
From Monty Python:"NOBODY expects the Spanish Inquisition!"

Received on Thu Apr 24 1997 - 00:00:00 CDT