Conference ulysse::rdb_vms_competition

874.0. "Teradata help needed" by GUIDUK::FLOOD (Cheeseburger in Paradise) Fri Feb 22 1991 23:52

I'm working with an account team that is performing a business analysis on
a customer who is currently an IBM shop and who maintains a high-volume
IMS database as the central repository for the data that drives the
business.  The problem that is confronting the customer is that the data
volume is growing at a rate such that the data storage requirements will
exceed the storage capacity of IMS by September, 1992.  This storage
limitation apparently is due to IMS' usage of 32-bit pointers to chain
records together; thus the number of records possible to be stored is
2**32 or about 4 gig of addressable space. 

The transaction volume on the database is about 400,000 records added 
per day; growth rate has been about 30% per year for the last 4 years.
Business reasons require the customer to retain a certain period's worth 
of data on the database, for customer service and billing functions.  
This retention period is currently 13 days; thus at any time, the 
database will hold 13 days worth of transactions, with one day dropping 
off daily to archive, and a new day being added.

The customer recognizes the need to circumvent the physical limitations 
of the IMS database.  Their long-term strategy is to migrate to DB2; 
short-term strategy is to add a Teradata database engine to their 
configuration.

This strategy of the customer's brings up a number of questions in the 
minds of those of us who would like to see them consider (and hopefully 
choose) another alternative.  For a start, I have technical questions
such as: 

	How feasible is an IMS-to-Teradata conversion?
	How does Teradata perform in a high-volume tps environment?
		comparable to IMS? (required tps is about 50/sec.)
	How comparable is the Teradata logical database model to
		the semi-network model that IMS follows?  What kinds
		of changes/differences would one be faced with when
		reworking an IMS database to be ported to Teradata?
	What changes need to be made to CICS cobol code to interface
		with Teradata?
	What about an ultimate Teradata-to-DB2 conversion?  Same kinds
		of logical database changes to be made (if not the
		exact same changes, then same magnitude of change)?
	does it make sense for the customer to skip the temporary
		Teradata solution and go right to DB2?
	how does DB2 perform in a production tp environment?
	how does Rdb stack up against DB2 in such an environment?

etc, etc, etc.

Can anyone give me some help on these topics?  I'd like to use answers
to these questions to open a discussion with the customer and provide
them information to assist them in re-evaluating their strategy --
hopefully in a manner that will be more favorable to DEC. 

Chuck Flood

	How feasible is an IMS-to-Teradata conversion?

>	As feasible as any heirachical to relational conversion - it is 
>	wholly dependent on the data model and amount of code convert !

	How does Teradata perform in a high-volume tps environment?
		comparable to IMS? (required tps is about 50/sec.)

>	Not too good, it gives lousy numbers for DR/CR, but can manage
>	50/sec as I remember it...

	How comparable is the Teradata logical database model to
		the semi-network model that IMS follows?  What kinds
		of changes/differences would one be faced with when
		reworking an IMS database to be ported to Teradata?

>	Dunno ?????

	What changes need to be made to CICS cobol code to interface
		with Teradata?

>	Rewrite code for SQL style access... Screen handling probably remains
>	the same... Unless Teradata provide tools etc. so they can rewrite
>	the enquiry stuff...

	What about an ultimate Teradata-to-DB2 conversion?  Same kinds
		of logical database changes to be made (if not the
		exact same changes, then same magnitude of change)?

>	Probably the same problems as Teradata conversion...

	does it make sense for the customer to skip the temporary
		Teradata solution and go right to DB2?

>	Probably, but think of the expense of all those 3090's.

	how does DB2 perform in a production tp environment?

>	See the new report from Butler/Bloor - they thing it's excellent
>	for read only, not so good for TP due to concurrency problems...

	how does Rdb stack up against DB2 in such an environment?

>	Rdb is probably a good solution but how about access for the terminal
>	population etc. etc.

	Now some suggestions... If I were them I'd try and keep my days worth
	of transactions in IMS as now, but move the data over to a relational
	system for the enquiries in an overnight batch of sorts, and rejig
	my enquiry applications... But this means that the data lends itself
	to doing this !

	Another approach would be to split the data into a series of daily
	databases (a bit like the airlines do for flights), and roll these
	databases over continuously. Means lots of application changes though !