| I need help to compete against Oracle:
We got a new Customer who will buy a Dual-host configuration (they
have already bought some Stations to begin development).
Now they have to choose the Database engine on which develop their
application; they need to interoperate with a Bull machine with Oracle
that they use in another site. The interaction between the two
computer should be at transaction level: they want to update the two
databases (Oracle on Bull and the one on Vax) at the same time.
>> As far as I know, Oracle is the only relational model that runs on Bull
DPS6/6+, 7000, and 9000. I have a customer who has 2 DPS6+ and 3
DPS7000 and several vaxes. Through benchmarks, we have consistently
beat the 7000 and the 9000 machines from Bull. The last I heard
(which is about 4 months old), SQL*net had not yet been ported to
GCOS7 AND, more importantly, Oracle V6 had not yet been ported to
ANY version of GCOS. Since the customer has Bull, he has NO choice
except to use Oracle. Bull has missed the relational database
"window of opportunity".
Essentially, we have the same problem with my customer and I
have studied this several times. I believe your best bet is
to write task-to-task programs on the VAX and the Bull which use
X.25 to communicate. The VAXen my customer has is not able to
communicate to the DPS6 and 7000 AT ALL because Bull has very
weak multi-vendor communications. As a result, my customer makes
tapes on the VAX and walks them to the Bull.
So, the bottom line is this, if the VAX can't communicate with the
Bull, Oracle on VAX can't communicate with Oracle on Bull. I
recommend you use Rdb on the VAX since this is the best solution
for your customer.
I don't know the features of SQL*NET and SQL*STAR ( 2PC is provided? ),
could they solve the problem and push my Customer to choose Oracle
on Vax too?
>> Absolutely ! Oracle DOES NOT have 2PC support. As I understand it,
Bull supports the port of Oracle to its many versions of GCOS.
I don't believe there is a version of SQL*net available for any
version of GCOS. SQL*star is a marketing concept, not a product.
Also, SQL*net does not have a programming interface like Rdb's
remote access. In order to get a local Oracle program to access
a remote Oracle database, you have to do all sorts of strange
things to table definitions within the Oracle database.
My customer uses SQL*net in sort of a DCL copy mode where one
table from node x is copied IN WHOLE to node y. Not exactly
transaction processing huh ?
On the other hand, what can I suggest to solve that problem using Rdb?
(at the moment Vaxlink to Oracle will only read data froma an
Oracle database on Vax)
>> VAXlink only runs on IBM mainframes. The rumour that our unannounced
mythical, gateway to Oracle is probably read-only. That is what
our gateway to DB2 is. Basically, you have the same problem no
matter what database you use on VAX. The way to solve this problem
is to get rid of the Bull machine and go all VAX.
>> You're going to have to write 3gl code on the VAX and 3gl code on the Bull.
You will have to manage your own transactions and 2PC dialogue.
Because you will have to write this from scratch, it doesn't matter
what is on each end and, as such, there would be no advantage of
using Oracle on the VAX (except that your customer would get to
spend a lot of money).
However, in my opinion, you've got more serious problems due to the
difficulty of communicating with Bull.
Hope this helps .... send me email if you need more info or want to discuss.
-- gerry
|