Re: Comparative between DB2, Informix and Oracle ~ Answered: amber (solid confidence) — Once refocused by Serge Rielau, the question 'what's the migration target for a 4GL app moving off Informix' gets substantive answers (Oracle-side toolkits, and IBM's EGL path for 4GL) before the thread drifts into an unrelated migration-economics/vendor debate.

Advisory only.

DA Morgan said: > Obnoxio The Chav wrote: > >> FireHawkBr' said: >> >>>Which are the alternatives to >>>the 4GL for Oracle? >> >> SQL*Forms. >> >> Hahahahahahahahahahahahahahahahahaha!!!!! > > You shouldn't bring up technology that is older than you are. So what *is* your suggested competitor to 4GL for Oracle, then? -- Bye now, Obnoxio "C'est pas parce qu'on n'a rien ' dire qu'il faut fermer sa gueule" - Coluche "I'm trying to see things your way, but I can't get my head up my ass" - JCH "Ogni uomo mi guarda come se fossi una testa di cazzo" - Marco Travel broadens a person. You look as if you have been all over the world. I went to the airport to check in and they asked what I did because I looked like a terrorist. I said I was a comedian. They said, "Say something funny then." I told them I had just graduated from flying school. -- Ahmed Ahmed http://i2.photobucket.com/albums/y41/Obnoxio/thinkIfoundtheproblem.jpg sending to informix-list

Obnoxio The Chav wrote: > DA Morgan said: > >>Obnoxio The Chav wrote: >> >> >>>FireHawkBr' said: >>> >>> >>>>Which are the alternatives to >>>>the 4GL for Oracle? >>> >>>SQL*Forms. >>> >>>Hahahahahahahahahahahahahahahahahaha!!!!! >> >>You shouldn't bring up technology that is older than you are. > > > So what *is* your suggested competitor to 4GL for Oracle, then? You. I thought you did. I think SQL*Forms as valuable as 4GL. Neither one has much of an impact in the global marketplace. Oracle, though, hasn't sold SQL*Forms in far more than a decade. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace 'x' with 'u' to respond)

DA Morgan wrote: > Obnoxio The Chav wrote: > >> DA Morgan said: >> >>> Obnoxio The Chav wrote: >>> >>> >>>> FireHawkBr' said: >>>> >>>> >>>>> Which are the alternatives to >>>>> the 4GL for Oracle? >>>> >>>> >>>> SQL*Forms. >>>> >>>> Hahahahahahahahahahahahahahahahahaha!!!!! >>> >>> >>> You shouldn't bring up technology that is older than you are. >> >> >> >> So what *is* your suggested competitor to 4GL for Oracle, then? > > > You. I thought you did. I think SQL*Forms as valuable as 4GL. > Neither one has much of an impact in the global marketplace. > Oracle, though, hasn't sold SQL*Forms in far more than a decade. Somehow I don't think that answers OTCs or the original posters question. What would be the target for migrating a 4GL app to Oracle? Cheers Serge -- Serge Rielau DB2 SQL Compiler Development IBM Toronto Lab

Serge Rielau wrote: > > Somehow I don't think that answers OTCs or the original posters > question. What would be the target for migrating a 4GL app to Oracle? > > Cheers > Serge There are some 4GL to Java migration toolkits available, for instance http://www.artinsoft.com/iproducts/i4gltojava/index.asp If you where looking at a straight redevelopment then you could use Java/JDeveloper http://www.oracle.com/technology/tech/java/index.html, .Net/Visual Studio with the Oracle VSI add ins http://www.oracle.com/technology/tech/dotnet/index.html, PHP http://www.oracle.com/technology/tech/opensource/index.html, Oracle HTML DB http://www.oracle.com/technology/products/database/htmldb/index.html, or Oracle Forms http://www.oracle.com/technology/products/forms/index.html. Or pretty much any third party development tool on the planet. All provide different types of development solutions with specific Oracle support. My preference now-a-days for rapid development is HTML DB. An Oracle only solution, but it rocks if you want a web based development environment that is largely declarative, with the app totally hosted and executing within the dayanase. Some of the busiest applications within Oracle are built using this technology, including our online employee directory, the Server Technology division's project management/tracking environment, and my own humble interal website with supporting applications for field activities etc.

Serge Rielau wrote: > DA Morgan wrote: > >> Obnoxio The Chav wrote: >> >>> DA Morgan said: >>> >>>> Obnoxio The Chav wrote: >>>> >>>> >>>>> FireHawkBr' said: >>>>> >>>>> >>>>>> Which are the alternatives to >>>>>> the 4GL for Oracle? >>>>> >>>>> >>>>> >>>>> SQL*Forms. >>>>> >>>>> Hahahahahahahahahahahahahahahahahaha!!!!! >>>> >>>> >>>> >>>> You shouldn't bring up technology that is older than you are. >>> >>> >>> >>> >>> So what *is* your suggested competitor to 4GL for Oracle, then? >> >> >> >> You. I thought you did. I think SQL*Forms as valuable as 4GL. >> Neither one has much of an impact in the global marketplace. >> Oracle, though, hasn't sold SQL*Forms in far more than a decade. > > Somehow I don't think that answers OTCs or the original posters > question. What would be the target for migrating a 4GL app to Oracle? > > Cheers > Serge Depends. If an internal applications I'd give a different answer from it being an externally accessible app. It depends on security, scalability, application server, etc. What you are asking is the equivalent to which database is the best. Without including information about "for what". -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace 'x' with 'u' to respond)

DA Morgan wrote: > Serge Rielau wrote: > >> DA Morgan wrote: >> >>> Obnoxio The Chav wrote: >>> >>>> DA Morgan said: >>>> >>>>> Obnoxio The Chav wrote: >>>>> >>>>> >>>>>> FireHawkBr' said: >>>>>> >>>>>> >>>>>>> Which are the alternatives to >>>>>>> the 4GL for Oracle? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> SQL*Forms. >>>>>> >>>>>> Hahahahahahahahahahahahahahahahahaha!!!!! >>>>> >>>>> >>>>> >>>>> >>>>> You shouldn't bring up technology that is older than you are. >>>> >>>> >>>> >>>> >>>> >>>> So what *is* your suggested competitor to 4GL for Oracle, then? >>> >>> >>> >>> >>> You. I thought you did. I think SQL*Forms as valuable as 4GL. >>> Neither one has much of an impact in the global marketplace. >>> Oracle, though, hasn't sold SQL*Forms in far more than a decade. >> >> >> Somehow I don't think that answers OTCs or the original posters >> question. What would be the target for migrating a 4GL app to Oracle? >> >> Cheers >> Serge > > > Depends. If an internal applications I'd give a different answer from > it being an externally accessible app. It depends on security, > scalability, application server, etc. > > What you are asking is the equivalent to which database is the best. > Without including information about "for what". I wish that were true. In my experience the question about migrating from one product to another is governed by one overriding factor: Price of migration. To be exact: How much does it cost me to replace x with y? The way to keep the price down is to find the best match. So the question is really quite simple: Does the target language exist, and if not is there one that is sufficiently equivalent that a tool can automate the transfer? Because if that cannot be automated PYs of manual labor may loom over my head. No matter how green the grass on the other side after a redesign, migrations are in the vast majority of the cases about one-to-one emulations first. Often teh QA system at a customer site is not equipt to do proper regression testing as required for a redesign to begin with. So here is my answer w.r.t. 4GL for an IDS to DB2 scenario: The successor for 4GL is EGL and there is tooling to bring you from one to the other smoothly. Here is a link: http://www-306.ibm.com/software/data/informix/pubs/library/4gl_7_egl.html Once you are on EGL (still with IDS (!)), you are in a position to move to DB2 without having to worry about that part any more. Going to DB2 will you also won't have to worry about incompatible isolation levels which may require rewriting your app logic. Cheers Serge -- Serge Rielau DB2 SQL Compiler Development IBM Toronto Lab

Serge Rielau wrote: > DA Morgan wrote: > >> Depends. If an internal applications I'd give a different answer from >> it being an externally accessible app. It depends on security, >> scalability, application server, etc. >> >> What you are asking is the equivalent to which database is the best. >> Without including information about "for what". > > I wish that were true. In my experience the question about migrating > from one product to another is governed by one overriding factor: Price > of migration. > > Cheers > Serge Perhaps I missed something somewhere. I thought you were an internal coder for IBM? How many migrations have you been involved in where you were part of the decision making process (as opposed to part of the implementation team)? Price of migration is one of many factors. But only one and generally the tool chosen is an insignificant part of that cost. The biggest cost is is the time spent as payroll dollars. And that is hardly ever about the tool itself. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace 'x' with 'u' to respond)

DA Morgan wrote: > Serge Rielau wrote: > >> DA Morgan wrote: >> >>> Depends. If an internal applications I'd give a different answer from >>> it being an externally accessible app. It depends on security, >>> scalability, application server, etc. >>> >>> What you are asking is the equivalent to which database is the best. >>> Without including information about "for what". >> >> >> I wish that were true. In my experience the question about migrating >> from one product to another is governed by one overriding factor: >> Price of migration. >> >> Cheers >> Serge > > > Perhaps I missed something somewhere. I thought you were an internal > coder for IBM? How many migrations have you been involved in where you > were part of the decision making process (as opposed to part of the > implementation team)? Let's just say my day to day work is not limited to compiling DB2, swearing at clearcase and posting in newsgroups. ;-) > Price of migration is one of many factors. But only one and generally > the tool chosen is an insignificant part of that cost. The biggest cost > is is the time spent as payroll dollars. And that is hardly ever about > the tool itself. Possibly for the first time ever we agree: The cost is in the payroll dollars. Therefore the degree of automation is a crucial factor. Migration is an investment with an associated risk. Both increase with the amount of redesign and manual labour. It needs either a big pay-off or a seriously pissed of customer to make the investment and risk worthwhile. Cheers Serge -- Serge Rielau DB2 SQL Compiler Development IBM Toronto Lab

Serge Rielau wrote: > Once you are on EGL (still with IDS (!)), you are in a position to move > to DB2 without having to worry about that part any more. > > Going to DB2 will you also won't have to worry about incompatible > isolation levels which may require rewriting your app logic. > OK - now you have confused me. Why would anyone currently on Informix move to DB2 ? Whats the value proposition, Serge ?

Mark T wrote: > Serge Rielau wrote: > > >>Once you are on EGL (still with IDS (!)), you are in a position to > > move > >>to DB2 without having to worry about that part any more. >> >>Going to DB2 will you also won't have to worry about incompatible >>isolation levels which may require rewriting your app logic. > > OK - now you have confused me. Why would anyone currently on Informix > move to DB2 ? Whats the value proposition, Serge ? > Hmm, wasn't there a recent Oracle financial report where some CEO complained that support should be more expensive for Oracle? Seems a good reason to stick with IBM if you ask me ;-) Stick with IBM is not equal to migrating to DB2. Cheers Serge -- Serge Rielau DB2 SQL Compiler Development IBM Toronto Lab

Serge Rielau wrote: > Mark T wrote: > Hmm, wasn't there a recent Oracle financial report where some CEO > complained that support should be more expensive for Oracle? I don't get this question, but then I don't read out financial reports, so perhaps I'm missing context. I'm sure its rhetorical anyway. > Seems a good reason to stick with IBM if you ask me ;-) > Stick with IBM is not equal to migrating to DB2. Well, obviously not now. But just a few hours ago weren't you suggesting .... > Cheers > Serge > Let's just say my day to day work is not limited to compiling DB2, swearing at clearcase and posting in newsgroups. Not so much posting as tap dancing (badly). (OT) BTW - do you want to talk about a possible alternative to clearcase ? Some of Us (TM) have one already, and only a very few of Us (TM) are of a size that will ever need it. Perhaps we should get our heads together ?

Serge Rielau wrote: >> Price of migration is one of many factors. But only one and generally >> the tool chosen is an insignificant part of that cost. The biggest cost >> is is the time spent as payroll dollars. And that is hardly ever about >> the tool itself. > > Possibly for the first time ever we agree: > The cost is in the payroll dollars. Just a second ... back up ... one of us needs to change our mind. ;-) > Therefore the degree of automation is a crucial factor. > Migration is an investment with an associated risk. > Both increase with the amount of redesign and manual labour. > It needs either a big pay-off or a seriously pissed of customer to make > the investment and risk worthwhile. > > Cheers > Serge True if migration automation produced good code. But that is something I've never seen. I've seen code that compiles. I've seen code that runs. But I've never seen good, clean, efficient, secure, scalable, maintainable code. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace 'x' with 'u' to respond)