| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 318.1 | | OPG::PHILIP | And through the square window... | Mon Jul 25 1994 19:27 | 9 |
|
Bruno,
We used logicals so that we could move things around, so, I dont see
any problem with what you are doing, go ahead and change any of the
logicals, let me know if anything breaks.
Cheers,
Phil
|
| 318.2 | What are you really trying to accomplish. | CSC32::BUTTERWORTH | Gun Control is a steady hand. | Mon Jul 25 1994 19:34 | 38 |
| >Is it possible to have only ONE Database on a Cluster mixed architecture
>( VAX and ALPHA) ??
You could probably do this. The question would be if engineering wants
to support it or not.
>If you change the logical name CONSOLE$ROOT on the VAX to point on
>the directory ALPHA, there is some problems with images !
Yep! Obviously VAX/AXP images are not cross architecture compatible.
>May be, we can change other logicals names... ( CONSOLE$IMAGE,...)?
Definitely. At least you would have to modify the CONSOLE$STARTUP
so that the logical names pointed at the correct images.
>Do you know if there is other problems? May be it's not possible ??
If the end to all this is to have a common database to allow one
system to perform as a hot backup then the question will be if
engineering wants to support user modified startup procedures.
if you are trying to have two independent PCM engines monitor the same
set of node simultaneously then there are inherint problems. First of
all, if your using LAT or TELNET connections to server ports, only one
connection may exist at any time thus only one engine can access the
consoles at any time. If you are using direct conenctions via local
async ports you will need some "black-box" in the line to multiplex the
console port into two lines and this has problems in and of itself.
Users on each engine could enter commands to the same console
simultaneously and then you'd have a really fine mess.
If we back to the hot-backup scheme then there are already hooks in the
software to accomodate a real active failover configuration and it is
planned for the next release as far as I know.
Regs,
Dan
|
| 318.3 | | OPG::PHILIP | And through the square window... | Tue Jul 26 1994 10:05 | 12 |
|
Thinking about the single database problem, well, this might work (if
you are lucky) however, when/if OpenVMS AXP goes to 64 bits, this
definately will not work! So, I would suggest that you dont do it, I
dont want to have to dissapoint you later on by refusing to support
you. I think it says somewhere in the documentation that the binary
database IS NOT transportable accross platforms, thats why we provided
export/import.
Cheers,
Phil
|
| 318.4 | thanks | EVOAI2::CHAVERON | | Thu Jul 28 1994 17:29 | 1 |
| Thanks for your help...
|
| 318.5 | \ | CSC32::BUTTERWORTH | Gun Control is a steady hand. | Thu Jul 28 1994 19:07 | 14 |
| >Thinking about the single database problem, well, this might work (if
> you are lucky) however, when/if OpenVMS AXP goes to 64 bits, this
> definately will not work!
Actually it will have to work since the company is committed to
mixed architecture clusters. If it's a question of file access support
(RMS etc) then it will be okay as RMS must be able to read any file
on any disk regardless of the architecture. If it's at a different
level such as the physical size of a long integer on the two
architectures then some careful coding will be necessary.
Just my .02 worth.
Dan
|
| 318.6 | | OPG::PHILIP | And through the square window... | Thu Jul 28 1994 19:17 | 14 |
| Dan,
Its the size of "long" which on a 32 bit machine is 32
bits and on a 64 bit machine 64bits, but OpenVMS currently
only gives you 32bits! Maybe we should put a bit of blurb
in the next release about exporting and reimporting the
database before upgrading to the 64bit version of OpenVMS
when and if it happens. Alternatively, we could pad our
records on VAX, which would require a lot of testing on
a software platform we just dont have!
Cheers,
Phil
|
| 318.7 | | CSC32::BUTTERWORTH | Gun Control is a steady hand. | Thu Jul 28 1994 19:42 | 14 |
| >Its the size of "long" which on a 32 bit machine is 32
> bits and on a 64 bit machine 64bits, but OpenVMS currently
> only gives you 32bits!
yep! thats why I made the statement about phsycail size of an integer.
There may be a better solution than padding. If there is a compiler
switch that makes all declarations of "int" 32 bits on AXP then you
could compile all the code using the qualifier. I don't have DEC C
installed so I can't verify this. Since it's just the database that
is really an issue then maybe we can use conditional compilation so
that all database routines compile using the correct length?
Regs,
Dan
|
| 318.8 | Just to clarify what 64 bit support means... | STEVMS::PETTENGILL | mulp | Tue Jan 03 1995 23:30 | 11 |
| OpenVMS for AXP systems is already using 64 bit integers, its just that the
default integer size is 32. When VMS adds 64 bit support, it will refer to
64 bit address support and it will be done compatibly with the current 32 bit
support and it will be only for data and only when explicitly requested.
Essentially, what will happen is that an application will create one or more
data regions in 64 bit space and then will be able to access it directly and
with I/O.
This 64 bit support will most likely be used only for in memory databases
and for scientific and engineering computing. No existing non-privileged
application will be adversely impacted.
|