I am looking into the possibility of having to migrate an application
that is running on Universe to a RDBMS. Currently I am my companies
DBA, and have not been involved in this application before now.

I am sorry for this newbie type questions, but what migration paths/
options are available for migrating from Universe? Currently we run
almost all of the major vendor databases (Oracle, SQL Server, Sybase
(asa)) along with PostgreSQL. We are also looking at DB2.

The possible migration path(s) from Universe will be driving a new
initiative to consolidate on one DB platform (all the dba's are saying
YAY!).

So, any help/ideas on where/how to migrate from Universe would be
greatly appreciated.

Also, does anyone out there have any success/horror stories of this
sort of migration?

Thanks,

Chris

Hi
You are about to make the biggest mistake of your computer life.
Universe is a 3 dimensional model, it will not simply migrate to a flat
relational database. The Database is not unpluggable it is part of a
complete development and runtime environment.

Try Reynolds & Reynolds to see how big a mistake it can be.

Anyway you would be better off migrating the rest of your stuff up to
Universe - that is easier and far more productive. Admittedly you would be
able to fire most of your dba's because they would not be needed. I think
that your problem is lack of U2 expertise in the unit. IBM acknowledge that
some 40% of their database revenue comes from U2 (Universe/Unidata) which
they view as an embedded database. That is it is a hidden part of the
solution because it is so efficient and trouble free.
There are of course a significant number of other platforms that support
Universe file structures and Basic language. You could follow up at
www.tincat-group.com where Dawn Wolthuis has a range of discussion papers
and a significant amount of experience in what you are asking.
Peter McMurray

<revoohc (AT) gmail (DOT) com> wrote

Goo'day, Peter,

I must be getting old.

This would have to be the longest reply I've seen from you where I
agree with you from start to finish! <grin>

Well done! Keep up the good work!

On Tue, 13 Feb 2007 22:27:14 GMT, "Excalibur"
<excalibur21 (AT) bigpond (DOT) com> wrote:

Regards,

Bruce Nichol

Talon Computer Services
ALBURY NSW 2640
Australia

If it ain't broke, fix it 'til it is

On Feb 13, 4:27 pm, "Excalibur" <excalibu... (AT) bigpond (DOT) com> wrote:
I'll add my voice to Peter's here. If you wish to consolidate on one
DBMS and you have software that is already written in Universe, you
and your company would be well-served to work with your existing data
model. That means not taking your software to a DBMS that is
encumbered with SQL as its only language / interface.

Taking a logical data model from a rich one that includes multivalued
data to a 1NF model, from one with lists (so there is ordering in the
model) to one without, and one that uses the sweetly simple two-valued
logic of True or False to one that injects a third value into the
logic is a painful and expensive thing to do. Unless you have a tiny
application, plan a decade for such a migration, if your company has
enough money to survive it. If you decide to move forward with it,
however, I am very interested in knowing about such projects and
hearing about how successful they are. You might find that in your
case, in two years time you will have better software than what you
started with, working with one of the currently popular DBMS's. I am
very interested in hearing of both successes and failures in such
attempts.

Many of us on this list have seen such projects up close, close enough
to guess that it is likely you will not trust us on this, thinking
that it cannot be that complex. You will find it is difficult to
provide the same level of functionality for the same costs AND for the
same degree of customer satisfaction with the data model (perhaps not
the UI if yours is old) once you migrate to an SQL DBMS.

If your software is for your company only, it might be less expensive
than if you are migrating a software product that is implemented by
many companies. I have not seen such projects up close myself.
Companies like Oxford Health and, as Peter points out, Reynolds &
Reynolds have, however.

If interested, start with Is Codd Dead? at
http://www.tincat-group.com/mewsings...codd-dead.html and
then follow the links through the pieces I have on this topic. I hope
this is helpful, even if not quite what you wanted to hear. Perhaps
DB2, with their new support for XML would permit you to reuse your
Universe data model, but I have not delved into it. Cache' is another
more popular DBMS (and perhaps the fastest growing one today?) that
would permit you to keep your existing data model. Best wishes and
let us know if you have better success than the bleak picture we are
giving. There have been some success stories of people migrating
software from Pick (Universe) to SQL-DBMS's without breaking the bank,
but these are few and far between. Obviously the smaller the system
is, the easier it will be to move.

If you still decide to migrate away from Universe without retaining
the rich data model, then my best piece of advice is to start from
scratch and develop a logical data model and related applications that
"think like" an SQL-DBMS rather than like a person, I mean, like
Universe/Pick rather than trying to migrate what you have.

Please keep us informed and feel free to ask questions. We really can
be helpful, even if many of us have reached similar conclusions over
the years. Best wishes. --dawn

The problem is not moving the data. While the concept of a multi
value database might sound daunting, in all reality, the mv model
maps very well to a sql model. Any mv data in a record normally
splits out into several tables. In fact, the most telling aspect of this
is that all of the major MV vendors allow the mv model to be
mapped to sql statements and a relational model. So, how this
data is "viewed" is actually up to you.

There is a lot of horror stories. To me, #1 on the list is failing to
distinguish between a data base that hold data, and the programs
and utilities that manage the data. This is where these migrating
fall down -- they fall down because too many people think that
a database system is just some forms that edit data, and some
tables. If migration was just moving data, then we would not
need developers anymore. You would just give every one a
tool like ms-access to build the data entry forms. The problem
is not some tables or data and data entry forms It is the actual
code that gives the whole system value.

The REAL WORK that a system does, and what gives that
system value is the code and applications that manipulates
the data.

The application part is the hard part to convert, and that is
the part that gives value to the system. You are not moving
some data (that is easy part), you are re-writing a bunch of
applications that are the resut of many years of business
rules being built up over the years. If they had 2 developers
working on that system for 7 years, you now have 14 man
years of devleopment to replace (you likey transfer the data
in week or so..but, then what???).

You can read an article of mine on converting an application
from a mv-system to a relational sql system. Make
CAREFUL note about the skill level needed for a successful
IT conversion project.

http://www.members.shaw.ca/AlbertKal...000000003.html

Also, make sure you read the appendix, and the article on how Oxford Health
Plans Inc failed with a migration project from a mv system.


--
Albert D. Kallal
Edmonton, Alberta Canada
pleaseNOOSpamKallal (AT) msn (DOT) com

I'm involved in a "migration" from Universe to Oracle at the moment. This is
a fourteen-million-dollar effort, divided into four phases over four years.
The new Oracle team has Oracle Financials plus custom software, so the
business rules are not being "migrated," but re-written. There are about 15
gigs of live (operational) data which is being flattened into .csv files for
import into tables, and another 20 gigs of data warehouse files to export.

They did a lot of investigation into the potential solutions before jumping
out of mv. the primary reasons were standardization, connectivity, and
turn-key functionality.

There are obvious conversion challenges, mostly having to do with
business-culture changes associated with the differences between the
"Universe way" and the "Oracle way."

If you have a sizable business, be prepared to spend the money necessary to
fund the costs of conversion, including an adequate training budget.

Ed

<revoohc (AT) gmail (DOT) com> wrote

Well, I'd like to suggest that you look into InterSystem's Caché
product. You can download a free copy to evaluate at http://
www.intersystems.com (there is a special 5.2MV
build available that includes the new multivalue features)
The 2007.2 release will have the multivalue features included as a
standard part of the product.
Caché supports MV applications (porting from UniVerse should be a
pretty painless operation), but also has a full SQL implementation, as
well as lots of other stuff (object database,
rapid application development, ...)
We've had many, many customers port from Oracle, Sybase, SQL Server,
etc. to Caché (we call them relational refugees!) who are very, very
happy with us...
We also have our share of horror stories of customers that thought
that moving to a RDBMS was a good idea (usually the idea of a new
CEO), who in the end came back to us
after having spent loads of money trying to get things working on a
pure RDBMS...

Scott Jones

Scott,

"Gandalf" <scott (AT) intersys (DOT) com> wrote

Caché supports MV applications (porting from UniVerse should be a
pretty painless operation)

I'm intrigued how to do that. To my knowledge Cache still hasn't got any
utility for (im)porting MV accounts into its structure. But, please, correct
me if I'm wrong.

Nick

"Gandalf" wrote:
I can't put the same sort of enthusiasm behind that recommendation but
I can say that as an impartial observer I also think it would be good
to evaluate Caché. I'm working on a project now to evaluate the
performance and actual migration effort required to port a large
multi-system site from Universe to Caché. It's not a slam-dunk, and
as we all know that last 5% consumes 95% of the time, but there are
many reasons to assume that on the back-end of this effort the
end-user will be in a much better place than they are now. There are
many questions about porting connectivity via Java, UniObjects, and
XML, but all of these are U2-platform-specific and being resolved with
appropriate interest from InterSystems management. I've heard a
couple sites have already migrated to Caché so I'm inclined to believe
that most issues that we're seeing now are related to site-specific
product usage and coding practices. I'm cautious but optimistic that
this migration will happen smoothly, and while I wouldn't even use the
phrase "pretty painless" I'd say this should be much more painless
technically and financially than a full port to Oracle or other RDBMS.
In particular, Caché not only offers a good technical platform, but
it's also a solid business decision because it's accepted in the
mainstream. For MV users who want to run their MV code and do
everything the MV way, but still want the technical and business
benefits of running a mainstream platform, I think this is a major
factor that most MV people haven't caught onto yet.

jBASE could also be an option where you could store your data in
Oracle or SQL Server and use your MV rules through the jEDI data
interface. Your data is actually in Oracle and you can run your
queries against it, etc, but migration of your code could be "pretty
painless".

I can't speak with any authority about ONWare but they actually do run
MV code against Oracle and SQL Server. So if you want to do a port
without changing your rules, this is an option similar to the others.

These days I'm less inclined than our colleagues to jump to a "you
don't want to do that, stay with MV" type of response. My heart
agrees with the sentiment but in business terms it's a bit too
simplistic and subject to losing the sort of battles we're facing. I
think the solutions you employ are more dependent on your company
objectives. If you need Oracle to satisfy some business agenda then
you simply need Oracle. But there are degrees to which you can
integrate MV and Oracle (DB2, whatever) and I'm much more in favor of
Integration rather than Migration or blatently discouraging a site
from making any changes at all. The mainstream world is all about SOA
and SOS and virtual environments that run together seamlessly, etc.
Take advantage of that, use your Universe system (or the code in
another MV environment) and make the best use of your application
investment that you can. Full out replacement will probably be a
disaster but you can mitigate that with a good understanding of where
each platform has its strengths.

HTH
Tony Gravagno
Nebula Research and Development
TG@ removethisNebula-RnD.com

Well, when I said pretty painless, I did mean compared to other ports
(and not just to RDBMSs).
We are trying to make it so that it will be a lot easier to port say
from UniVerse to Caché than from UniVerse to D3, or from UniVerse to
UniData.
I hope that when we are finished, you would agree with that
assessment.
Another InterSystem's product that could be useful at Revo's company
is Ensemble, which could be used to tie together different
databases/applications.

Scott Jones