On Feb 19, 8:56 am, sh <sham... (AT) prupipe (DOT) com> wrote:
jBASE isn't out of the question from my perspective, but the ownership
structure of the DBMS concerns me (the folks with the copyright are
not the ones marketing it) and it seems to have lost some momentum. I
have it on the same shelf where I have Revelation, a product. They
are within arms reach, but so far I have not heard enough reason to
take them off the shelf.

I recall telling somewhere there that I would like to be more excited
by their product, but my angle was somewhat opposite. I want to use
current software development tools and languages against a better data
model than that in SQL-DBMS tools. Given that they do the opposite of
my interest on both ends, it isn't on my radar at this point. I do
understand that they have filled a role of helping VARs who would
otherwise not get business due to the non-standard DBMS, migrate their
product so that it runs on Oracle, for example. I know that is no
small thing, so I can say "bravo" for any successes at least.

No. My understanding is that Cache' has a data model that at least
addresses three of my issues with standard SQL-DBMS's: 3VL, 1NF and
lack of lists. Cache has an implementation of SQL like they have an
implementation of Pick. While they built it into their toolset in a
very integral way, SQL is not altogether standard as it addresses
non-1NF structures. Their data model is neither Pick nor relational,
but MUMPs, based originally on a toolset developed about the same time
as Pick, used extensively in the medical profession, for example.

Not much. I did talk to them to get accurate information for the MV
Family tree poster, but nothing to add at this point.

Just my two cents. --dawn

dawn wrote:

I can appreciate your interest, but that wasn't what the poster wanted.
The poster has SQL machines, and wants to move his MV application to
one. He wasn't asking for a better data model than relational. We have a
responsibility to provide information that is best for him/her, not what
interests/is best, for us.

Again, I can appreciate your position. It's a good reason why you don't
have an interest in OnGroup. But I still find the deafening silence from
everyone disturbing. Whether we like the relational model or not, it is
the DB of the vast majority of the universe, and it is a valid solution
for someone who has some reason for wanting to go to it.

On Feb 19, 4:53 pm, sh <sham... (AT) prupipe (DOT) com> wrote:
You are right -- I got this thread confused with the one where I gave
a list of possible products for a new app. Sorry 'bout that.

Yes, agreed. Again, for some reason I confused this with the other
thread. If there is a target DBMS that a site wishes to migrate to
for every app and they do not care about how the app is written, just
that it uses that particular DBMS, then if either jBASE or OnGroup
permits that DBMS as a backend, it might be worth considering such a
migration. Thanks. --dawn

On Feb 19, 11:02 pm, "dawn" <dawnwolth... (AT) gmail (DOT) com> wrote:
I don't have the docs to hand atm, but I'm pretty sure I read that you
could persist your data on DB2 using the same old UniVerse application
software. Wasn't that on the CD they were handing out when Susie was
on her world tour?

Mike.

On Feb 20, 6:29 am, "Mike Preece" <mich... (AT) preece (DOT) net> wrote:
I know they were working on it, but am unaware of anyone actually
doing that. u2-users would likely have an answer to that ( http://www.u2ug.org
). --dawn

dawn wrote:

Strange, I had a feeling you were mixing the two up. Your response was
so not like you.

In that other thread (Starting from Scratch) I had mentioned Cache, but
you didn't respond. I thought, perhaps, I had overestimated your
interest in more progressive data bases. I see that isn't true.

On Feb 20, 2:08 pm, "dawn" <dawnwolth... (AT) gmail (DOT) com> wrote:
It is called EDA - you can write your own EDA interfaces for any
database IBM initially released it with a DB2 EDA it is live and
released for some time now and they have people using it - i know of
none myself tho so i can not give a resume on how well it goes.


Symeon,

sh wrote:
hardware ...

My favourite war story (I think you'll find the original post on the
u2ug mailing lists somewhere). In a conversion just like this, some
Oracle consultants proudly announced that, after SIX MONTHS hard work,
they'd finally got the replacement system 10% faster than the old UV
system for some complex query. They shut up very fast when the guy
maintaining the UV system said "You've got a twin Xeon 800, and you're
*proud* of being only ten percent faster than an old Pentium 90?".

MultiValue (which includes UniVerse) tends to be very efficient in its
use of computer resources.

Cheers,
Wol

(Somehow this posting wasn't published, retrying)

Thanks Sholom.

sh wrote:
From what I've seen, ONware is good software that has a very specific
niche. I'd like to work with it but I've never been asked. I think
the part of their problem with industry perceptions is that the
message from ONgroup doesn't speak to the typical MV developer.
They're in a weird position because MV guys generally don't want
Oracle or SQL Server. I think, could be wrong, the only companies
they're going to sell to are VARs or end-users who are highly
motivated to run over one of these relational databases. There are
two types of companies who fit this category:
You have the MV VAR who has decided to get the best of both
worlds by selling a relational solution to people who want such a
thing, but using familiar MV development tools. This requires some
major conscious decisions which most MV people are reluctant to make.
The net result for their company could be a big benefit, but for those
who say "we sell applications and not databases" the initiative may
achieve nothing at all. The results depend on the approach.
You have the MV end-user site who is compelled to make
changes, either because they feel their net worth will be higher
because they use a mainstream database, or because they have someone
at high levels insisting that relational is the only way to go. This
site can get tremendous bang for buck by using ONware rather than
doing a full port to relational, spending millions of dollars, etc.
The database can be ported in the near term, the rules in the longer
term in a controlled process. In fact, there's no real business or
technical need to migrate the rules in this case. The only problem
with this is that traditional MV code doesn't allow for referential
integrity checks by the DBMS, so either that relational feature needs
to be forfeited, or the MV code needs to be modified to accommodate
it. I know nothing about how they handle such things.


Not really.
Caché doesn't require the MV developer to understand a new
database, though more familiarity will lead to better use of the
environment.
Caché has more tools that are built-into the environment.
ONware emulates MV functionality over a relational environment. I'm
not sure what other unique value-add ONware offers. Since other
database products don't have "out of the box" what's in Caché you're
getting more of a package than with a relational environment.
(Big one for me) ONgroup doesn't provide anywhere near the
business benefits that InterSystems does. For a company doing a basic
migration this may not be important except that Caché and Oracle and
SQL Server are all recognized "mainstream" databases. For a VAR
looking to sell new solutions this is very important. I suspect
InterSystems marketing will do much more at a personal level for a
transitioning VAR than Oracle Inc or even Microsoft. InterSystems is
a big company but I think they have a personal side that's good for
this sort of business.
Similarly, when you use ONware, you're using a third-party
product over mainstream databases. Someone may ask "who is this
ONware company?" When you're using Caché, it's all the same company
and product. The MV extensions in Caché are a native part of the
database. That eliminates one middleman. It also opens doors for MV
developers who want to sell product and services in the Caché world.

I don't want to downplay ONware. I do appreciate their offering. But
from the options available to us now it seems Caché is rapidly
becoming a contender and responds to some of these issues that other
existing products in our industry have had all along. Note that
Nebula R&D is a jBASE reseller but if someone just wants to use the
jBASE jEDI with Oracle the exact same issues are present. I need to
weigh all of these things when making recommendations to my clients
and prospects.

TG@ please.remove.this.antispam.textNebula-RnD.com

On Feb 23, 12:06 am, Tony Gravagno
<g6q3x9lu53... (AT) sneakemail (DOT) com.invalid> wrote:


Just a quick note on my own experience of onWare - At Datelex in the
UK (where i used to be a consultant) a big part of their solution (the
air fares system) is based on U2. this system is typically sold with
the internet booking engine (java and oracle) into large tier 1 and 2
airlines and travel companies (united, virgin, sas, southafrican,
emirates, singapore, best western etc all big names) Many of these
corporates have a policy for database systems and, although very often
U2 is allowed in as it is for a specific application, many dictate
that they will only have oracle as they already have investment in the
term of millions in oracle clusters. Onware where used for such end
users. At the end of the day only one actiually pushed the point so
much that onware was deployed (JTB in Japan).

The main onware guy in the UK is an old McDonnalDouglas gut who is
well known and repsected in the uk "Pick world" so the pedigree and
"MV'ness" was never much doubted.

To begin with onware was a bit lacking in some areas (no debugger
forinstance), and was quite different to U2 in others (c interface for
instance) however the guys at onware where very receptive to our needs
and updated their core software fairly quickly (the only other people
to do this it seems in openQM!)

In the end it has to be realised such a task is fairly easy if you do
not want to do any optimisation and just store your MV data as blobs
in oracle - however this then makes the solution slower in that oracle
can not do what it is good at and store and index tables of data
correctly, and harder for any oracle/sql people to analyse, and work
with.

Back to the OP's question - this is actually a good case example - as
has been said before There are two aspects

A) The programs - if you want those to be redone - well pick your
language, TSQL, VB, .NET, C++ etc ...
If you want to keep the programs then you have a number of options
Run in Universe still and use the EDA to store the data in DB2/Oracle/
SQLSRV etc
Run in Onware and ditto
Run in jbase and ditto
However with Universe and Jbase you still get a MV database on the
system, with Onware there is no native database purely a run engine so
this may be considered the neatesty solution.
B) The data - there is a lot of work here converting the MV data to
good performant SQL tables, it can be done quickly and stored as
blobs, but htis gives imediate problems and problems later on (as
shown in the example above), so i would recomend you get it done up
front.

rgds
Symeon.