Background:
The typical data warehouse recommendation is to offload your IMAGE data
into another set of databases (Oracle, Sybase, etc.), resulting in redundant
data but typically in a different format for decision support.
The typical data/application migration strategy off the 3000 converts
everything from Image to another platform and RDBMS.
A Hybrid solution/question, of the type "is this a good idea?":
Many vendors have written gateways to Image (Oracle, Image/SQL, ODBC) all
take the viewpoint of the "outside looking in" to Image. How about turning
the tables and create an IMAGE-API to RDBMS at the intrinsic layer?
What I have in mind is the typical "intercept" technique of replacing
DBOPEN, DBCLOSE, DBPUT, DBUPDATE, DBINFO, DBGET...etc, with equivalent calls
to [for example] Oracle SQL over a network.
The approach to "make a less featured DBMS", such as Image, behave as a
full featured RDBMS is logically impossible - but the approach to make a
full featured RDBMS behave like Image would be much simpler.
[IMAGE intrinsic layer] <--> [network API/SQL] <--> [Oracle RDBMS]
So, in this layout, Legacy applications on the 3000 actually think they are
making IMAGE calls, but in reality, are accessing Oracle across the network.
Since Oracle has kerberos V network security modules and DCE integration,
legacy MPE applications could continue to function but we can keep and
maintain a single copy of data and reap the rewards of RDBMS on the network
for global enterprise-wide data access.
Has anyone given thought to this idea or anyone doing it? What this model
turns out to be is the reverse of the Quest IMAGE NETBASE client for Sun
Solaris. It would become an MPE "Image Client" for Oracle RDBMS.
----------------------------------------------------------------
Eric J. Schubert Senior Data Base Analyst
Office of Information Technologies Univ of Notre Dame, IN USA
(219) 631-7306 http://www.nd.edu/~eschuber
Ms. Frizzle says: "Nothing is as constant as change.", how true.
|
