Ingres 5 -> 6 upgrade

I am currently running  Ingres 5.0/6 :-(     and    6.4/03 :-|
The software base is a combination of ABF, REPORT WRITER, QUEL, COBOL, C, SQL
on VMS 5.5-2.  I have a production vax box   and   a development/test vax box 
with shared clustered DASD.

Management would like to move to the current release

CA indicates I can move to    OpenIngres 1.1/04   or  6.4/06(released June 4th)

I thought CA was going to stop development of the 6.4 line.  Which would cause 
me to move to OpenIngres line.  I have suggested removing the QUEL to go to
the straight SQL code.  The programming staff indicates there are less 
features in SQL then Quel.  So my questions are as follows:

1. Is 6.4 Line dead or is there a future?

2. With ABF as a base - no thoughts to move to W4GL, but maybe someday to 
Powerbuilder where would you go OpenIngres or 6.4?


3. My migration for 6.4/03 to 6.4/06  OR  OpenIngres looks straightforward 
enough.  Palmer Associates have done a nice job reviewing this in DM Review
this year.    But the migration path for 5.0/06   is unclear?

Thanks in advance for your input.

Jer
Ingres/Sybase DBA
jerry_p._clare%chase%chase_na_external@notes.worldcom.com




From: Caroline McKallor 
Subject: Re: migration to ingres current release?
Date: 16 Jul 1996 14:32:31 -0400

Jer (& any other Version 5 people still left out there?),

Some version 5 to 6.4 conversion tips. You must convert your 5 stuff to
6.4 (open ingres is not a direct option from 5 - I am pretty sure).  We 
completed our major conversion about a year and 1/2 ago. 

Our 5 environment was :
	our primary production database (over 5 gigabytes, I think) 
	7 X 12 operation. 
	sql (what a mistake!) for all our abf apps (many procs in sql/c), 
	mostly quel (some sql) embedded in C stand alone programs - (no forms)
	mostly quel reports (some sql)
	vax/vms
	converted 5.0/07 to 6.4/03
		
1. Quel conversion from 5 to 6 is a breeze, sql conversion from 5 to 6 is
	nuclear wind...  lots of fallout and loss of hair.  Expect LIKE a lot 
	of fussing with syntax, queries, wildcards with your SQL.   
2. Get the latest 5 to 6 conversion manual and read it.  Don't believe all that 
	it says, but it is very helpful, of course.
3. Don't expect much help from tech support, in fact it might be dangerous to 
	ask for help.  In my opinion, this is completely foreign territory for 
	them.  
4. There are things that the conversion manual does not tell you that you need 
 	to know.
	a. use the copy /reload method if at all possible (otherwise known as
	  	avoid using the convert-to-6 program). Our incredible pain and 
		suffering came when our convert process died, we called tech 
		support and they compounded the problem (by giving us bad 
		advice - telling us to drop some corrupted indexes out of our 
		partially converted database) and we were then stuck with a 
		worthless, partially converted, corrupt, goin-nowhere database.
		It seems that the convert program can find corruption where 
		your five system did not care.  You supposedly can keep going 
		even if corruption if found, by restarting the convert program,
		but we couldn't get it to run after dropping the indexes.  
		Better to copy out and reload fresh and clean and good data if 
		you can.  (I can't blame tech support - probably one person a 
		year converts.  Helpful advice like "run verifydb on your 5 
		database first" should have warned us since verifydb is not 
		a version 5 command.)
	b. most copy out files (copyform, copyrep, etc.) are portable from 
		version 5 to 6.  This came in very handy for us after we 
		figured it out.  It says nothing about this in the conversion
		manual. Test this out first, of course. 
	c. if your database is large - system table wise - the convert-to-6 
		program takes forever anyway - it took us FOUR DAYS!! to 
		convert a copy of our database for test with hardly any data.  
		We had a ton of system table stuff (hundreds of apps and 
		hundreds of reports and that was what took forever.)   If you 
		have a lot of that stuff and still want to use the convert-to-6
		program, copy it out and get rid of it from your 5 database 
		before you run the convert program. We did that before we tried 
		the for real conversion.  (otherwise it would have run for 
		a week, at least, had it worked).
	d. Your creative permits will no longer work for your sql apps.  Your 
		existing permits become "quel permits" and you will need sql 
		permits.  You are stuck using Knowledge Management "Groups" if 
		you managed group access though your quel permits with your own 
		tables.  If you restricted access to the field level with 
		permits you must now set up views and grant permits to the 
		views.  I really hated to see the permit get so dumbed down.  
		And passing that damn group flag everytime you want group 
		permits applied is also a pain.   
5. We experienced drastic changes in performance - mostly great but some 
	impossibly bad.  The bad performance was from very complex quel 
	queries.  We had to re-write a few programs (to simpler quel not sql, 
	of course).
6. Expect problems - our 5 implementation revealed weaknesses (or should I say
	features) in 6 that we had no idea about beforehand (like the permit 
	and group problem).  Since everyone does things differently, you may 
	find new and stranger problems.
7. Convert your smallest databases first.  Size has everything to do with how 
	hard conversion can be.  Our second database, a much smaller one,
	was converted flawlessly!!! over a weekend, without the convert-to-6
	program.  Practice makes perfect.
8. I could go on but I'll shut up now.


As for your question about OpenIngres vs. 6.4, did I read here a while back 
that CA was not supporting Cobol in OpenIngres or was I dreaming?

Caroline McKallor 	Fred Hutchinson Cancer Research Center
			Seattle, WA
Ingres Q & A
To William's Home Page
Email William