bds@mbunix.mitre.org (Barry D Smith) (08/18/89)
If anyone has developed a Lucid to Oracle interface, I wonder if you would be willing to share some of your discoveries with us. We've been working on this for a while now, and although we can make it work, the solution is very kludgy. Neither Lucid nor Oracle are much help in this. When we bought Oracle v5.3x we were running SunOS 3.5, but by the time it arrived, we had updated to SunOS 4.0, including an upgrade to Lucid 3.0 for SunOS 4.0. It turns out that Oracle v.5 has some fundamental incompatiblities with SunOS 4.0, including the fact that SQLNET doesn't work. Unfortunately, we needed to run SunOS 4.0. The plan was to write C code to query Oracle using Pro-C, then to compile the code to object code, and load it and all necessary libraries into Lucid using def-foreign-function and load-foreign-files. Lucid would then do all the linking. We would then run a Lisp function to connect to Oracle, leave the connection open, and run our query and update functions in Lisp as needed. The data could then be loaded into LISP variables using Lucid's def-foreign-callable. This worked using Oracle v.5.3, as long as we didn't have to go over the net. We finally received an Oracle update, v.6.0x, which fixed the networking problem. However, Oracle v.6 requires SunOS v.4.0.3, which we got and installed. Oracle now does everything properly, but Lucid will no longer link the Oracle libraries properly. It appears that the linker under SunOS 4.0 is not compatible with the linker under SunOS 4.0.3. So we no longer could stick by the plan. An alternative plan was developed, in which we would compile and link the c code in unix, producing executable files, and then run them with Lucid's run-program. The c code would print the data, and Lucid would redirect the output to a LISP stream, which we would then read into LISP variables. This works but requires that we open a new connection to Oracle everytime we need to do anything, since the c program exits. It takes about 3 seconds to make each connection, which causes unnecessary slowdowns at runtime. So then we decided to open a 2-way buffer between Lucid and a c program by using :input :stream :output :stream in run-program. We took the code directly from the manual, but it did not work. Apparently we could not open a 2-way stream (it seems we could write to it, but trying to read from it caused it to hang). It is unfortunate, since if it did work, we could make the c program open a connection to Oracle and then just sit in a constant wait state. Then we would be back at the original plan, except that Lucid would not be doing the linking. But it doesn't work. It does appear that we could have the c program write its results to a file, and then have Lucid read that file. We are currently investigating this. The point is that this seems very kludgy. We should be able to load c variables directly into LISP variables (no pointers, just terminal data). If anyone has worked this problem and would like to discuss it, I would welcome it. Thanks. Barry Smith bds@mbunix.mitre.org
barr@pineapple.bbn.com (Hunter Barr) (08/24/89)
In article <64385@linus.UUCP> bds@mbunix (Smith) writes: > >If anyone has developed a Lucid to Oracle interface, I wonder if you >would be willing to share some of your discoveries with us. We've >been working on this for a while now, and although we can make it >work, the solution is very kludgy. Neither Lucid nor Oracle are much >help in this. ... Lisp/C interfaces and Unix kludges, too painful to repeat... >Barry Smith >bds@mbunix.mitre.org ---------------- Have you tried the Symbolics co-processor in your Suns? The Symbolics TCP/IP implementation is, of course, very straightforward to use from Lisp. If you are tied to Lucid, well... you have my sympathy-- I support a Lucid implementation of my stuff too. ______ HUNTER
finin@prc.unisys.com (Tim Finin) (08/25/89)
We've done various Lisp to DBMS packages and finally decided to opt
for maximizing portability by going in the ascii front door. If you
are interested in finding out more you can get the following papers:
The Interpreted-Compiled Range of AI/DB Systems
Anthony D. O'Hare and Amit P. Seth
PRC-LBS-8903
January 1989
The Intelligent Database Interface Language
Anthony B. O'Hare
PRC-LBS-8908
June 1989
The Intelligent Databse Interface: Design And Rationale
Anthony B. O'Hare
PRC-LBS-8909
July 1989
The Architecture Of BrAID: A System For Efficient AI/DB Integration
Amit P. Seth and Anthony B. O'Hare
PRC-LBS-8907
June 1989
These reports may be obtained from
UNISYS M. W. Freeman Memorial Library
Paoli Research Center
P. O. Box 517
Paoli, PA 19301
For additional information, contact:
Judie Norton, Technical Information Specialist
215-648-7254
215-648-7412 (fax)
jen@prc.unisys.com
--
______________________________________________________________________________
Tim Finin finin@prc.unisys.com (internet)
Unisys Paoli Research Center ..!{psuvax1,sdcrdcf,cbmvax}!burdvax!finin (uucp)
PO Box 517 215-648-7446 (office), 215-386-1749 (home),bds@mbunix.mitre.org (Barry D Smith) (08/26/89)
In article <1940@papaya.bbn.com> barr@pineapple.bbn.com (Hunter Barr) writes: >In article <64385@linus.UUCP> bds@mbunix (Smith) writes: >> >>If anyone has developed a Lucid to Oracle interface, I wonder if you >>would be willing to share some of your discoveries with us. We've >>been working on this for a while now, and although we can make it >>work, the solution is very kludgy. Neither Lucid nor Oracle are much >>help in this. > >... Lisp/C interfaces and Unix kludges, too painful to repeat... > >Have you tried the Symbolics co-processor in your Suns? The Symbolics >TCP/IP implementation is, of course, very straightforward to use from >Lisp. If you are tied to Lucid, well... you have my sympathy-- I >support a Lucid implementation of my stuff too. > ______ > HUNTER I received a solution to our problem from John Cowan (cowan@marob.masa.com). He said the problem seemed like a typical problem of making two unix programs talk to each other using pipes. In order to make it happen, you have to force the system to send the data in each direction. This means using (force-output stream) at the Lisp end and fflush(stream) at the C end. The stream at the Lisp end is the stream returned by run-program, while at the C end the stream is standard output. It works. The use of a Symbolics board for this application is intriguing. Oracle only supports interfaces to C, Fortran, and Pascal, and this code must be run through a preprocessor. The output is still C code, though much larger and more complicated, so we could then use the Symbolics C compiler to generate Lisp code which would run on the Symbolics board. However, the Symbolics board doesn't support color right now (or at least didn't a month or so ago), and this system is very color dependent. When there is a cad buffer for the Symbolics board, I think we will be very interested. Until then, it's Lucid 3.0 for its color support, and SPE 1.1 for a development environment. Barry Smith