| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1305.1 | | PSW::WINALSKI | Meetings are our most important product | Fri Aug 18 1989 16:02 | 4 |
| If VAXCRTL appears in ORACLE.OPT somewhere, take it out.
--PSW
|
| 1305.2 | ... and there's more ! | SAC::JEPSON | Eschew Obfuscation | Mon Aug 21 1989 16:08 | 32 |
| Stop Press:
I've tried a few more things: the finger appears to point at
ORACLE shareable stuff. I'll try to summarise to keep this short!!
The ORACLE shareable image sets the base address (using BASE=) in
its option file; it appears to do this to leave some acreage for
some global sections (!). The link of this image also specified
the C run-time library by using a logical name in an option file.
Replacing the logical name in the option file with a specific
reference to SYS$SHARE:VAXCRTL.EXE/SHARE and re-building the
ORACLE shareable image allows the customer application to link OK.
It fails to run with an image activation error caused by:
%SYSTEM-F-VA_IN_USE "Virtual address already in use" (by the way I
cannot find this error in the System Massages manual).
If I then re-link the ORACLE shareable without the BASE= setting,
the customer application again links successfully but this time
ACCVIO's deep in the heart of ORACLE machinations.
NB: I've been ANALYSE/IMAGE'ing the ORACLE shareable images each
time I re-built them. Delivered version had no IMAGE ACTIVATION
FIXUPS and no list of shareable images referenced, this always
happens when the BASE= stuff is included. Remove BASE= (i.e. let
it float or default) and a list of referenced shareables appears
(including VAXCRTL).
Does any of this stuff help spark-off a few ideas ???
Andy
|
| 1305.3 | Bleagh. | UFP::MURPHY | Rick - WA1SPT/4 | Mon Aug 21 1989 22:04 | 29 |
| Oh well.. I just deleted a very nice anti-ORACLE flame.
Let me try again with a bit higher light-to-heat ratio:
I would be *very* careful linking any production code to ORACLE.
They base their shareable image so that code that references their shared
area (the SGA - System Global Area) can use absolute addresses, rather
than deal with pointers to relocatable data. Based images make this
easy, but, like everything, it's a tradeoff - you gain some
simplification of the programming effort (and probably an infinitesimal
improvement in performance) but you pay dearly for it.
This unfortunate design decision leads to your problem: when the based
shareable image is linked, each shared image it links against is then
fixed in memory - unfortunately, this leads to the complications you're
seeing - conflicts in address space.
Moreover, almost every release of VMS changes the size of our shared
images. Thus, you are forced to relink ORACLE frequently.
Since the image isn't built using normal shared image techniques (like
transfer vectors), you are forced to relink every ORACLE user application
each time ORACLE is relinked - I've seen times where an AUTOGEN run
forces an ORACLE relink!
I would strongly suggest finding some way to avoid linking against ORACLE
directly - unless you *like* your application requiring frequent
relinks.
-Rick
|
| 1305.4 | It's a hack ... see personal name :-)
| 42143::PITT | Suspend all hackers ... by the neck! | Tue Aug 22 1989 09:26 | 9 |
| > Oh well.. I just deleted a very nice anti-ORACLE flame.
> Let me try again with a bit higher light-to-heat ratio:
I'm glad you said that in .-1, because I would have had the same problem writing
a reasonable reply ... I have seen so many problems caused by the based ORACLE
shareable image that I've lost count of them years ago ...
T
|
| 1305.5 | Solved it in the end ! | SAC::JEPSON | Eschew Obfuscation | Tue Aug 22 1989 16:11 | 28 |
|
Finally managed to get it going.
For reference (it was a daft one):
In the link command file for the ORACLE shareable image (and for
the command file ORACLE supply for linking user applications) they
had specified the VAXCRTL via an options file that used:
<logical_name>/share
where <logical_name> translated to a reference to
VAXCRTL.
This successfully fooled the linker into including the C run-time
image twice. Making direct reference to it solved the multiple
inclusion problem. The other VA stuff was solved by (correctly)
specifying the correct version of the ORACLE run-time library for
INSTALL (whoops!) and re-building everything in sight to do with
ORACLE.
BTW I concur with your feelings on ORACLE products, I also
consider it all to be rather tacky to say the least.
Many thanks to all for your help.
Cheers!
Andy
|