[379] in Tooltime
Scopus Response on Macintosh
daemon@ATHENA.MIT.EDU (Steven Wade Neiterman)
Mon Jan 27 18:03:06 1997
Date: Mon, 27 Jan 1997 18:06:33 +0100
To: tooltime@MIT.EDU
From: Steven Wade Neiterman <wade@MIT.EDU>
Here is the mail I promised from Scopus. The major point not mentioned
earlier is that we will only be supporting PowerPC Mac's.
I can say that the BrioQuery and PowerBuilder applications run fine with
CFM and SQL*Net 2.1, so, I would expect that once the Scopus 5.2 release is
available, we should be able to use it.
..Steve
----------------------------------------------------------------------------
From: Dennis Dallin
Sent: Friday, January 24, 1997 6:31 PM
To: Steve Neiterman
Cc: Kira Makagon; Mel Rosenberg; Jill Smolen, Lyle York
Subject: Mac & SQL*Net 2.1
The discussion below clearly defines the technical issues associated with
the strategic solution we have taken as a company in supporting the Mac
Client. We had made this decision several months ago and therefore had
decided not to pursue upgrading the current 3.6.2.1 client but to replace
it at the right time with the Monaco, 5.x client. This would not solve the
680x0 Mac client issue on the Oracle SQL Net 2.1 version but until we
really dug into why the special client we developed and built for MIT
(which we had tested on SQL Net 2.0) didn't work on 2.1, we really didn't
understand that the technology had changed so dramatically. We have
thoroughly investigated what it would take to fix the MIT client to work
properly on SQL Net 2.1 and determined the best short term and more
importantly, long term solution is to build the Mac 5.2 client to run on
the 3.6.2.1 foundation. Not only will this take less time and be more
stable, it also matches our long term strategy. Keep in mind this will
only support Power Mac, but that's all the other solution would support as
well.
It will take us 4 weeks to build the 5.2 Mac client to work on 3.6.2.1 and
thoroughly test it for industrial strength. We don't want anything to go
wrong this time and the real good news is that since this solution fits
with our committed support long term for the Mac Client, it therefore
doesn't fall into the category of a "one-of". One-of's never get supported
well.
If you or any of the management team there want to discuss this further or
need more information, please let me know. We really appreciate your
cooperation and patience and further we are fully committed to meeting this
date. We also apologize for missing the mark so badly in delivering
against our original contractual commitment.
----------
The problem and the solution:
With the introduction of 2.1 SQL*Net Oracle has changed the way
they build their connection libraries on the Macintosh. To build Mac apps
with 2.1 SQL*Net, you must use an Apple technology called the Code Fragment
Manager (CFM). To make things difficult, older Macs don't normally use the
CFM, but Power Macs do.
To build Oracle applications on the Mac that use SQL*Net 2.1, we
need to use Oracle's "new architecture" shared libraries. The current
(3.6.2.1) Scopus application available for 680x0 only does not use CFM. If
we built a 680x0 version, we would have to use an Apple technology called
the "CFM-68K Runtime Manager", which Oracle used to build its "new
architecture" shared libraries. However, Apple has just sent out a warning
to all customers recommending that they not use the CFM-68K technology due
to a bug that can "[result] in application instability and potential loss
of data." (Quote from Apple's own admission of the problem.) It is
unknown when a fix to this problem will be delivered.
Therefore, if we recompiled the 3.6.2.1 source to use the new
Oracle libraries, we would still not have a workable 680x0 version, and we
would still have to go though a port to Power Mac. A much more sound
solution for us at this point is to go with the 5.2 Mac client which is
nearing completion for the Power Mac.
The 5.2 Mac is a cross compiled version of our 5.2 code line which
was initially developed on Windows. We use the Microsoft cross compiler
for MFC (Microsoft Foundation Classes). By using this standard technology
we've been able to avoid lengthy a porting process and we've been able to
leverage development time invested into the Windows code line. Going
forward, the two products will remain in sync and will offer the same
advances in technology and architecture on both platforms.
