Adabas to DB2 conversion

Iris Foweather

Adabas to DB2 conversion
We have an application running in Adabas and are looking at feasibility of
converting/redesigning it to use DB2. As usual it all hinges on cost, both
for the conversion process and the ongoing running costs.

Does anyone out there have experiences they are willing to share of
converting Adabas to DB2 and the difference in costs involved in running it
in DB2?


Regards,

Iris

Iris Foweather
Technology Services
Experian
Tel: 0115 9344312
Email : [login to unmask email]



This e-mail has come from Experian International: winner of the UK's National Business of the Year Award 2003.

=
Information in this e-mail and any attachments are confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission. There is no intention to
create any legally binding contract or other binding commitment through
the use of this electronic communication unless it is issued in accordance
with the Experian Limited standard terms and conditions of purchase or
other express written agreement between Experian Limited and the recipient
Experian Limited (registration number 653331) Registered office:
Talbot House, Talbot Street, Nottingham NG80 1TH

Although Experian has taken reasonable steps to ensure that this communication
and any attachments are free from computer virus, you are advised to take
your own steps to ensure that they are actually virus free.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Jeff Williams

Re: Adabas to DB2 conversion
(in response to Iris Foweather)
Iris.

I don't have an answer for you but I am curious to know what the motivation is to switch platforms? Is it a usability or development issue?

Jeff

-----Original Message-----
From: Foweather, Iris [mailto:[login to unmask email]
Sent: Thursday, January 22, 2004 5:52 AM
To: [login to unmask email]
Subject: Adabas to DB2 conversion


We have an application running in Adabas and are looking at feasibility of
converting/redesigning it to use DB2. As usual it all hinges on cost, both
for the conversion process and the ongoing running costs.

Does anyone out there have experiences they are willing to share of
converting Adabas to DB2 and the difference in costs involved in running it
in DB2?


Regards,

Iris

Iris Foweather
Technology Services
Experian
Tel: 0115 9344312
Email : [login to unmask email]

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Walter Eachus

Re: Adabas to DB2 conversion
(in response to Jeff Williams)
Iris

Since ADABAS is an inverted list database it is really imperative that you
do the necessary data design to move to DB2.

If you convert as is the ADABAS then you will incur more cost ( never did a
cost analysis ) as such but have converted ADABAS structures to DB2 and it
is all doable in so far as the data is understood.

I am a Data Architect / DB2 DBA and I would strongly suggest a revisit to
the cause of the decision to make this DB2 since there are tools within the
ADABAS world to make things appear relational.

Walt

-----Original Message-----
From: Foweather, Iris [mailto:[login to unmask email]
Sent: Thursday, January 22, 2004 8:52 AM
To: [login to unmask email]
Subject: Adabas to DB2 conversion


We have an application running in Adabas and are looking at feasibility of
converting/redesigning it to use DB2. As usual it all hinges on cost, both
for the conversion process and the ongoing running costs.

Does anyone out there have experiences they are willing to share of
converting Adabas to DB2 and the difference in costs involved in running it
in DB2?


Regards,

Iris

Iris Foweather
Technology Services
Experian
Tel: 0115 9344312
Email : [login to unmask email]



This e-mail has come from Experian International: winner of the UK's
National Business of the Year Award 2003.

=
Information in this e-mail and any attachments are confidential, and may not
be copied or used by anyone other than the addressee, nor disclosed to any
third party without our permission. There is no intention to create any
legally binding contract or other binding commitment through the use of this
electronic communication unless it is issued in accordance with the Experian
Limited standard terms and conditions of purchase or other express written
agreement between Experian Limited and the recipient Experian Limited
(registration number 653331) Registered office: Talbot House, Talbot Street,
Nottingham NG80 1TH

Although Experian has taken reasonable steps to ensure that this
communication and any attachments are free from computer virus, you are
advised to take your own steps to ensure that they are actually virus free.

----------------------------------------------------------------------------
-----
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
"Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org.
The IDUG List Admins can be reached at [login to unmask email] Find
out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

------------------------------------------------------------------------------
This message is intended only for the personal and confidential use of the
designated recipient(s) named above. If you are not the intended recipient of
this message you are hereby notified that any review, dissemination,
distribution or copying of this message is strictly prohibited. This
communication is for information purposes only and should not be regarded as
an offer to sell or as a solicitation of an offer to buy any financial
product, an official confirmation of any transaction, or as an official
statement of Lehman Brothers. Email transmission cannot be guaranteed to be
secure or error-free. Therefore, we do not represent that this information is
complete or accurate and it should not be relied upon as such. All
information is subject to change without notice.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

William Proctor

Re: Adabas to DB2 conversion
(in response to Walter Eachus)
Hello Iris,
Its hard to say without knowing the application and the volume
of data. We are converting from Adabas to DB2. We have gone from 7
volumes of data (3390 disk) to 120 volumes for DB2 and we just had to
upgrade our processor. The update was not totally because of DB2 but
that was a large part of it. So far its been 2 years and 30 million
dollars to convert. The main systems goes in this summer. If you have
any specific question I'll answer them as best that I can.

Bill Proctor
Database Administrator (Adabas/DB2)
Texas Guaranteed Student Loan Corp.
Austin, Texas
Phone: 512-219-4847


Iris.

I don't have an answer for you but I am curious to know what the
motivation is to switch platforms? Is it a usability or development
issue?

Jeff

-----Original Message-----
From: Foweather, Iris [mailto:[login to unmask email]
Sent: Thursday, January 22, 2004 5:52 AM
To: [login to unmask email]
Subject: Adabas to DB2 conversion


We have an application running in Adabas and are looking at feasibility
of
converting/redesigning it to use DB2. As usual it all hinges on cost,
both
for the conversion process and the ongoing running costs.

Does anyone out there have experiences they are willing to share of
converting Adabas to DB2 and the difference in costs involved in running
it
in DB2?


Regards,

Iris

Iris Foweather
Technology Services
Experian
Tel: 0115 9344312
Email : [login to unmask email]

------------------------------------------------------------------------
---------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that
page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences
at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Cuneyt Goksu

Re: Adabas to DB2 conversion
(in response to William Proctor)
Iris,

I have worked for 3 different Adabas/DB2 conv. projects.

Things to remember:

*- If App. env. is Natural, it is easier. If you install Natural/DB2
interface, Current applications work as is with only 'some' minor changes,
After the data converted to DB2 'as is'. Never forget cost of Natural/DB2
interface is a lot!!

*- If you normalize ADABAS data, the number of tables and their size increase
wildly!

*- In the long run, Get rid of Natural/DB2 Interface. Its Cursor processing,
CPU consumption, SQL Usage is not 'controllable'.

*- And the DBAs... ADABAS is much more easier to manage so DBA work for DB2 is
more, as you may know, they have to learn more and more. I have never seen a
happy ADABAS DBA when they switch to DB2. The rehabilitation of them take some
time :))

Regards,
Cuneyt Goksu

Date: Thu, 22 Jan 2004 13:51:33 -0000
From: "Foweather, Iris" <[login to unmask email]>
Subject: Adabas to DB2 conversion

We have an application running in Adabas and are looking at feasibility of
converting/redesigning it to use DB2. As usual it all hinges on cost, both
for the conversion process and the ongoing running costs.

Does anyone out there have experiences they are willing to share of
converting Adabas to DB2 and the difference in costs involved in running it
in DB2?


Regards,

Iris

Iris Foweather
Technology Services
Experian
Tel: 0115 9344312
Email : [login to unmask email]

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Tom Duerbusch

Re: Adabas to DB2 conversion
(in response to Cuneyt Goksu)
We are in the mist of a simular conversion, that is Cincom's Total
database to DB2. OK, perhaps not too simular as Total hasn't been
supported since the mid '80s. (Required 3380s and only runs in 24 bit
area...yikes!)

It is difficult? Technically no... actually yes.

The biggest problem is that everyone has their "day" job. Which is the
job they do 30-40 hours a week. Conversion, much less, the learning
curve is all in addition to their normal work week. Let's see....do I
work on the conversion or do I get the W-2's out?

If you contract outside help, you don't learn as much as doing it
yourself. And it is you that ends up supporting the application. You
can't have the best of both worlds, unless you have the money to do
extensive training and hire a few really good DB2 types.

1. You will end up paying for two database licenses during the
conversion.

2. Disk space requirements, initially are quite a bit more then the
old system. I initially figured a 4X increase going from a nice, packed
database to one with free space and the ability to use many more indexes
then the old database. Initially it grew to 8X more. The database
catalogs are much bigger. And Total didn't have the concept of
"internal dbspaces" used for sorts, joins etc. But that was with DB2
defaults (33% devoted to indexes and 15% for free space in pages). Once
all the data was loaded and things calmed down. I knew how much free
space was needed and reorged the dbspace. So, I can see us being down
in the 5-6X the space necessary.

3. Since the programmers are redoing all the database accesses, they
are also moving all the VSAM files to DB2. A single access method,
single reporting methods, and the data also becomes available in a
distributed environment. More disk space.

4. I tried to scope this as a quick conversion. Just replace the
calls to Total with a SQL call. Well, that worked in as it got
programmers to start the conversion process. But actually, they found
that they could write a single SQL statement (with joins) to replace
pages of code that was necessary when accessing multiple tables. Then I
needed to determine what indexes to add to make the query work
efficiently.

5. Since I also touted the benefits of having a relational database
and the ability to access the data outside of the mainframe (all of
which I thought would start AFTER the conversion), parallel projects
came around to access the data from the PC side, other servers and Web
based. Of course those project drew the resouces away from the
conversion process.

But some of these "new" projects are driving the conversion of our
older applications. So, that's good. In our case, if the data is
available in DB2, then the projects can be done, in house. With Total,
we would have went out shopping for a client server package, on NT with
Oracle done by a set of contracters with weekly refreshes from the
mainframe. Funny, since when the NT, Oracle and contractors leave, that
data ends up being available only to that application. If we modify
things on the NT/Oracle platform then the warrenty on performance and
reliability is violated.

6. DB2 takes quite a bit more virtual storage then Total did. We run
DB2 in a 20 MB partition and it will end up using more and more as
applications are added (buffers). Performance really jumped when I
increased the buffers from the default to a few MBs. We run DB2 in a
dynamic partition, so increasing the virtual size means increasing the
virtual size for all the other partitions of that same class.
Therefore, more paging space needed.

7. One one side, I see more CPU needed. But I can't really tell as
the CPU for Total was more distributed (or hidden). We had to run Total
reorgs weekly. And adding/changing a field in Total could run 6-8
hours.

8. With Total, we would read the daily log tapes to produce audit
reports of what happened. You can't, shouldn't directly read the DB2
log files. But Capture/VSE (part of Data Propagator) can read the log
files and build DB2 "CD" tables of all changes. This is less efficient
than just reading the log spin offs in batch, but these CD tables can be
updated online, in any frequency (I choose every 5 minutes). More CPU,
More memory, More Disk, More things to go wrong<G>.

9. Since DB2 uses internal dbspaces for sorting, etc, we find that
batch reporting is just extract/report instead of extract/sort/report.
This means less scratch disk space. I only defined a single scratch
pack on our DB2 systems. I'm still waiting to see if I would end up
reclaiming the disks that was being used for scratch space on the Total
systems.

10. DB2 Restore feature is a must. I could justify it just on the
ability to restore a single table, while the database is up. Where I'm
planing for weekly archives and keeping the log to roll forward when
necessary, application is doing table backups prior to and after nightly
batch, with table restores when necessary. Just like we always have.
But when the batch window closes even tighter (with data being
accessable via non-traditional methods), we may end up converting to
restore and roll forward as a way of life.

11. DB2 Control Center is kind of iffy in my book. Nice for someone
that doesn't know what they are doing, but...

Control Center for DB2/UDB is neat. It can access DB2 for VM and VSE
but it can't do all the functions that it can do for a UDB database.

12. Watch out for the features lacking in the SQL language for DB2 for
VM and VSE. Big problem. No outer joins for one. All PC based
packages will produce outer joins. DB2 Connect will convert them to
something that DB2 for VM and VSE can understand. In doing the
emulation, DB2 Connect may issue thousands...10s of thousands individual
SELECT statements to get the result the outer join would get. Someone
with an Excel spreadsheet ends up creating an outer join, and DB2 may be
pegged at 90% utilization for hours!

13. With DB2, you can use TCP/IP for remote access. Great, as
everyone has it. But when they do use it, your IP partition starts
using more resources. (IP is not used in the normal CICS or Batch to
DB2, unless DB2 is running in another VSE system. If DB2 is running in
VM, a special IUCV type connection is made.)

14. Our Cobol programs are larger. With Total, we just had the FD for
the table. With DB2, a lot of COPY books are inserted during the SQL
translation. So I assume the compiles take a little more CPU time also.
The compile printouts are much bigger.

15. You will spend a lot more manpower in solving problems as all
problems are new. If you have been running Adabas for a decade or so,
you have already learned or experienced most of the problems. Sometimes
problem solving can take many 10s of hours.

16. Operations has had complaints about when a job cancels. The job
may just sit there and not go to end of job. DB2 is doing a roll back
and due to our usage, the roll backs are quite a bit more intensive then
we every had with Total. But then we don't have to restore either, but
applications still runs the restore jobs.

17. Obviously, each of our tables had to be redesigned. Not only DB2
doesn't have packed decimal (no biggie), but it doesn't have coded
records (if col 1 has an "A", this is an adjustment record and you
should use the record layout for adjustments...) I.E, going from record
oriented processing to field oriented.

18. DB2 only allows clean data in the database. We use to have date
fields of blanks. Not anymore. Either nulls or a valid date. It took
a lot of time to clean up our files. VSAM sure didn't care. Neither
did Total.

Despite all the problems, if I only consider the direct replacement of
Total with DB2 (CICS and Batch only), I really didn't have major
problems. Every big problem was with additional usage/features. Outer
joins coming in from other platforms. Data Progagator to produce audit
tables.

So, depending on if you have been using the relational features of
Adabas or not, will determine how many of the above items may affect
you.

If your determination is only on cost, I can't see that it would be
worth wild. I doupt that the cost of DB2 is that much different than
Adabas. So it is either new functions, availability, accessability that
would be used to determine if the conversion cost is justified. Or
perhaps, you already have DB2 so the elimination of an Adabas license is
the main consideration.

Tom Duerbusch
THD Consulting

>>> [login to unmask email] 01/22/04 07:51AM >>>
We have an application running in Adabas and are looking at feasibility
of
converting/redesigning it to use DB2. As usual it all hinges on cost,
both
for the conversion process and the ongoing running costs.

Does anyone out there have experiences they are willing to share of
converting Adabas to DB2 and the difference in costs involved in
running it
in DB2?


Regards,

Iris

Iris Foweather
Technology Services
Experian
Tel: 0115 9344312
Email : [login to unmask email]



This e-mail has come from Experian International: winner of the UK's
National Business of the Year Award 2003.

=
Information in this e-mail and any attachments are confidential, and
may
not be copied or used by anyone other than the addressee, nor
disclosed
to any third party without our permission. There is no intention to
create any legally binding contract or other binding commitment
through
the use of this electronic communication unless it is issued in
accordance
with the Experian Limited standard terms and conditions of purchase or
other express written agreement between Experian Limited and the
recipient
Experian Limited (registration number 653331) Registered office:
Talbot House, Talbot Street, Nottingham NG80 1TH

Although Experian has taken reasonable steps to ensure that this
communication
and any attachments are free from computer virus, you are advised to
take
your own steps to ensure that they are actually virus free.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that
page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences
at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Isaac Yassin

Re: Adabas to DB2 conversion
(in response to Tom Duerbusch)
Hi,
Lately I was involved (and still involved) in such a project. The customer
decided to go that way due to the inability to do many things (reports) in
ADABAS. It was a really complicated system, built during the last 20 years.
There are many COBOL and NATURAL programs.
The conversion was done by an external company on a "fixed price" project and
the customer decided that in phase 1 they will do only limited re-engineering,
and only later (phase 2) the re-engineering will be done by the customer
personnel as they will learn to use DB2 better.
Phase 1 completed on time (really it was 3 months before time!) and on budget.
CPU consumption is about 63% more and disk space for the data was doubled.
The first 2 months after the conversion were difficult as we worked on CPU
reduction, which worked well for the online (CICS) and now we turn to the batch
processes. Even though many tests were done before the cut-over, we still
encountered many problems in the dynamic SQL part that has to be analyzed and
changed accordingly.
Take into account that during the project we had to install a new Z800 (001)
machine, migrate to OS/390 2.10 (on way to Z/OS 1.4), move to WLM, put in WLM
managed SP, UDF and triggers - it was interesting :-)

We had performance problems on the places that combined NATURAL and COBOL
together (one calling the other) that we solved only by separating them.
The NATURAL/DB2 access works fine (nearly same speed as COBOL - if it's in
static SQL).

Don't look to save money out of it! - You gain more options due to relational
technology but you loose things that were inherent in ADABAS.

There is much more to it - this is only the highlight :-)



Isaac Yassin
IBM Certified solution expert
DB2 V7 for OS/390 & Z/OS

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of
Foweather, Iris
Sent: Thursday, January 22, 2004 3:52 PM
To: [login to unmask email]
Subject: Adabas to DB2 conversion

We have an application running in Adabas and are looking at feasibility of
converting/redesigning it to use DB2. As usual it all hinges on cost, both
for the conversion process and the ongoing running costs.

Does anyone out there have experiences they are willing to share of
converting Adabas to DB2 and the difference in costs involved in running it
in DB2?


Regards,

Iris

Iris Foweather
Technology Services
Experian
Tel: 0115 9344312
Email : [login to unmask email]



This e-mail has come from Experian International: winner of the UK's National
Business of the Year Award 2003.

=
Information in this e-mail and any attachments are confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission. There is no intention to
create any legally binding contract or other binding commitment through
the use of this electronic communication unless it is issued in accordance
with the Experian Limited standard terms and conditions of purchase or
other express written agreement between Experian Limited and the recipient
Experian Limited (registration number 653331) Registered office:
Talbot House, Talbot Street, Nottingham NG80 1TH

Although Experian has taken reasonable steps to ensure that this communication
and any attachments are free from computer virus, you are advised to take
your own steps to ensure that they are actually virus free.

--------------------------------------------------------------------------------
-
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page
at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or
Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG
List Admins can be reached at [login to unmask email] Find out the
latest on IDUG conferences at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Michael Weiss

Re: Adabas to DB2 conversion
(in response to Isaac Yassin)
Iris,

Yes, it is feasible and very doable. Our company has completed many ADABAS
to DB2 conversions projects which are today running in production, at very
well accepted performance levels. This includes operational performance of
the post-migrated applications, and the continued maintenance of the
applications following migration.

While your query asks for feedback concerning Adabas to DB2, you may wish
to consider a number of alternatives, as it relates to the NATURAL
programming language – are you planning to retain NATURAL as the
Programming Language in your move to DB2?, OR, reengineer the NATURAL to
COBOL?

We have developed our own conversions tools (OnTarget) which support the
following types of the following semi-automatic conversions:
o NATURAL/ADABAS to NATURAL/DB2: for the automated transformation of
ADABAS database applications and their programming languages to DB2.
o NATURAL/ADABAS to COBOL/DB2,for the automatic reengineering of
NATURAL/ADABAS applications to COBOL/DB2 - where the generated application
is created in a 3-tier architecture - Presentation, Data and Business
Logic layers. In the next quarter we plan to release the new version which
will support web-based services through a HTML/Java Presentation layer.

These solutions are fully operational and field-proven. Last June
COBOL/DB2 Applications, which were automatically reengineered from their
original NATURAL/ADABAS were put into production at a major international
financial institution in the USA. One of the most impressive results is
degradation in utilization of CPU of batch jobs and the elapsed time was
shortened!! (no - it's not a mistake!!!!). And, the reengineered
applications are now serving as a basis for introducing Web-based
services, thus providing greater flexibility and adaptability to
modifications, with improved receptivity to new technologies.

For more information you may contact us directly or Circle Computer Group,
our partner in the UK.

Best regards
Michael Weiss
Director, Sales & Marketing
MOST - MOdern Software Technologies Ltd.
Tel: +972 3 911 5510
Mobile: +972 6 473 3408
Visit our Web Site: www.mostsoftware.com

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Steve Westfall

Re: Adabas to DB2 conversion
(in response to Michael Weiss)
One approach to conversion that I don't think has been mentioned is the
"transparency layer" approach. At least one consulting firm doing Total and
Supra to DB2 conversions offers this, and I've heard of it being done with other
databases. It's not appropriate for everyone, but it might be worth evaluating.
With this approach, the applications that formerly accessed Total or Supra do not
need to be changed, because they are tricked into thinking that they are still
doing that. The transparency layer makes DB2 look like Total or Supra to the
application.

I'm not claiming that this is efficient or pretty, but it may be a godsend for
some who are stuck and have to get out of a dead-end technology but don't have
the resources for a complete re-engineering project. I think the company was
Tidewater Associates, located in Virginia, but that was ten years ago. They may
have changed their name or may not even be around any more.

Steve Westfall
Equifax, Inc.





Tom Duerbusch
<[login to unmask email] To: [login to unmask email]
ISCITY.COM> cc:
Sent by: DB2 Data Subject: Re: Adabas to DB2 conversion
Base Discussion
List
<[login to unmask email]
ORG>


01/23/2004 12:27
PM
Please respond to
DB2 Database
Discussion list
at IDUG





We are in the mist of a simular conversion, that is Cincom's Total
database to DB2. OK, perhaps not too simular as Total hasn't been
supported since the mid '80s. (Required 3380s and only runs in 24 bit
area...yikes!)

It is difficult? Technically no... actually yes.

The biggest problem is that everyone has their "day" job. Which is the
job they do 30-40 hours a week. Conversion, much less, the learning
curve is all in addition to their normal work week. Let's see....do I
work on the conversion or do I get the W-2's out?

If you contract outside help, you don't learn as much as doing it
yourself. And it is you that ends up supporting the application. You
can't have the best of both worlds, unless you have the money to do
extensive training and hire a few really good DB2 types.

1. You will end up paying for two database licenses during the
conversion.

2. Disk space requirements, initially are quite a bit more then the
old system. I initially figured a 4X increase going from a nice, packed
database to one with free space and the ability to use many more indexes
then the old database. Initially it grew to 8X more. The database
catalogs are much bigger. And Total didn't have the concept of
"internal dbspaces" used for sorts, joins etc. But that was with DB2
defaults (33% devoted to indexes and 15% for free space in pages). Once
all the data was loaded and things calmed down. I knew how much free
space was needed and reorged the dbspace. So, I can see us being down
in the 5-6X the space necessary.

3. Since the programmers are redoing all the database accesses, they
are also moving all the VSAM files to DB2. A single access method,
single reporting methods, and the data also becomes available in a
distributed environment. More disk space.

4. I tried to scope this as a quick conversion. Just replace the
calls to Total with a SQL call. Well, that worked in as it got
programmers to start the conversion process. But actually, they found
that they could write a single SQL statement (with joins) to replace
pages of code that was necessary when accessing multiple tables. Then I
needed to determine what indexes to add to make the query work
efficiently.

5. Since I also touted the benefits of having a relational database
and the ability to access the data outside of the mainframe (all of
which I thought would start AFTER the conversion), parallel projects
came around to access the data from the PC side, other servers and Web
based. Of course those project drew the resouces away from the
conversion process.

But some of these "new" projects are driving the conversion of our
older applications. So, that's good. In our case, if the data is
available in DB2, then the projects can be done, in house. With Total,
we would have went out shopping for a client server package, on NT with
Oracle done by a set of contracters with weekly refreshes from the
mainframe. Funny, since when the NT, Oracle and contractors leave, that
data ends up being available only to that application. If we modify
things on the NT/Oracle platform then the warrenty on performance and
reliability is violated.

6. DB2 takes quite a bit more virtual storage then Total did. We run
DB2 in a 20 MB partition and it will end up using more and more as
applications are added (buffers). Performance really jumped when I
increased the buffers from the default to a few MBs. We run DB2 in a
dynamic partition, so increasing the virtual size means increasing the
virtual size for all the other partitions of that same class.
Therefore, more paging space needed.

7. One one side, I see more CPU needed. But I can't really tell as
the CPU for Total was more distributed (or hidden). We had to run Total
reorgs weekly. And adding/changing a field in Total could run 6-8
hours.

8. With Total, we would read the daily log tapes to produce audit
reports of what happened. You can't, shouldn't directly read the DB2
log files. But Capture/VSE (part of Data Propagator) can read the log
files and build DB2 "CD" tables of all changes. This is less efficient
than just reading the log spin offs in batch, but these CD tables can be
updated online, in any frequency (I choose every 5 minutes). More CPU,
More memory, More Disk, More things to go wrong<G>.

9. Since DB2 uses internal dbspaces for sorting, etc, we find that
batch reporting is just extract/report instead of extract/sort/report.
This means less scratch disk space. I only defined a single scratch
pack on our DB2 systems. I'm still waiting to see if I would end up
reclaiming the disks that was being used for scratch space on the Total
systems.

10. DB2 Restore feature is a must. I could justify it just on the
ability to restore a single table, while the database is up. Where I'm
planing for weekly archives and keeping the log to roll forward when
necessary, application is doing table backups prior to and after nightly
batch, with table restores when necessary. Just like we always have.
But when the batch window closes even tighter (with data being
accessable via non-traditional methods), we may end up converting to
restore and roll forward as a way of life.

11. DB2 Control Center is kind of iffy in my book. Nice for someone
that doesn't know what they are doing, but...

Control Center for DB2/UDB is neat. It can access DB2 for VM and VSE
but it can't do all the functions that it can do for a UDB database.

12. Watch out for the features lacking in the SQL language for DB2 for
VM and VSE. Big problem. No outer joins for one. All PC based
packages will produce outer joins. DB2 Connect will convert them to
something that DB2 for VM and VSE can understand. In doing the
emulation, DB2 Connect may issue thousands...10s of thousands individual
SELECT statements to get the result the outer join would get. Someone
with an Excel spreadsheet ends up creating an outer join, and DB2 may be
pegged at 90% utilization for hours!

13. With DB2, you can use TCP/IP for remote access. Great, as
everyone has it. But when they do use it, your IP partition starts
using more resources. (IP is not used in the normal CICS or Batch to
DB2, unless DB2 is running in another VSE system. If DB2 is running in
VM, a special IUCV type connection is made.)

14. Our Cobol programs are larger. With Total, we just had the FD for
the table. With DB2, a lot of COPY books are inserted during the SQL
translation. So I assume the compiles take a little more CPU time also.
The compile printouts are much bigger.

15. You will spend a lot more manpower in solving problems as all
problems are new. If you have been running Adabas for a decade or so,
you have already learned or experienced most of the problems. Sometimes
problem solving can take many 10s of hours.

16. Operations has had complaints about when a job cancels. The job
may just sit there and not go to end of job. DB2 is doing a roll back
and due to our usage, the roll backs are quite a bit more intensive then
we every had with Total. But then we don't have to restore either, but
applications still runs the restore jobs.

17. Obviously, each of our tables had to be redesigned. Not only DB2
doesn't have packed decimal (no biggie), but it doesn't have coded
records (if col 1 has an "A", this is an adjustment record and you
should use the record layout for adjustments...) I.E, going from record
oriented processing to field oriented.

18. DB2 only allows clean data in the database. We use to have date
fields of blanks. Not anymore. Either nulls or a valid date. It took
a lot of time to clean up our files. VSAM sure didn't care. Neither
did Total.

Despite all the problems, if I only consider the direct replacement of
Total with DB2 (CICS and Batch only), I really didn't have major
problems. Every big problem was with additional usage/features. Outer
joins coming in from other platforms. Data Progagator to produce audit
tables.

So, depending on if you have been using the relational features of
Adabas or not, will determine how many of the above items may affect
you.

If your determination is only on cost, I can't see that it would be
worth wild. I doupt that the cost of DB2 is that much different than
Adabas. So it is either new functions, availability, accessability that
would be used to determine if the conversion cost is justified. Or
perhaps, you already have DB2 so the elimination of an Adabas license is
the main consideration.

Tom Duerbusch
THD Consulting

>>> [login to unmask email] 01/22/04 07:51AM >>>
We have an application running in Adabas and are looking at feasibility
of
converting/redesigning it to use DB2. As usual it all hinges on cost,
both
for the conversion process and the ongoing running costs.

Does anyone out there have experiences they are willing to share of
converting Adabas to DB2 and the difference in costs involved in
running it
in DB2?


Regards,

Iris

Iris Foweather
Technology Services
Experian
Tel: 0115 9344312
Email : [login to unmask email]



This e-mail has come from Experian International: winner of the UK's
National Business of the Year Award 2003.

=
Information in this e-mail and any attachments are confidential, and
may
not be copied or used by anyone other than the addressee, nor
disclosed
to any third party without our permission. There is no intention to
create any legally binding contract or other binding commitment
through
the use of this electronic communication unless it is issued in
accordance
with the Experian Limited standard terms and conditions of purchase or
other express written agreement between Experian Limited and the
recipient
Experian Limited (registration number 653331) Registered office:
Talbot House, Talbot Street, Nottingham NG80 1TH

Although Experian has taken reasonable steps to ensure that this
communication
and any attachments are free from computer virus, you are advised to
take
your own steps to ensure that they are actually virus free.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that
page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences
at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page
at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or
Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List
Admins can be reached at [login to unmask email] Find out the latest on
IDUG conferences at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Roger Miller

Re: Adabas to DB2 conversion
(in response to Steve Westfall)
There are many good responses about experience. I thought perhaps a
couple of additional resources might be useful. If you want it, I think I
can find the 1989 conversion guide from Adabas to DB2. The information
about porting is primarily at these URLs now:
http://www.ibm.com/developerworks/db2/zones/porting/

I went out with Google searching for Adabas DB2 convert and found many
services and vendors with tools: Serena, FBO Sabresoft, Softscout, ...
http://www.wizinc.com/documents/JWolsey.ppt
http://builder.com.com/5100-6315-5034355.html

Roger Miller

On Thu, 22 Jan 2004 13:51:33 -0000, Foweather, Iris
<[login to unmask email]> wrote:

>We have an application running in Adabas and are looking at feasibility of
>converting/redesigning it to use DB2. As usual it all hinges on cost, both
>for the conversion process and the ongoing running costs.
>
>Does anyone out there have experiences they are willing to share of
>converting Adabas to DB2 and the difference in costs involved in running
it
>in DB2?
>
>
>Regards,
>
>Iris
>
>Iris Foweather
>Technology Services
>Experian
>Tel: 0115 9344312
>Email : [login to unmask email]
>
>
>
>This e-mail has come from Experian International: winner of the UK's
National Business of the Year Award 2003.
>
> =
>Information in this e-mail and any attachments are confidential, and may
>not be copied or used by anyone other than the addressee, nor disclosed
>to any third party without our permission. There is no intention to
>create any legally binding contract or other binding commitment through
>the use of this electronic communication unless it is issued in accordance
>with the Experian Limited standard terms and conditions of purchase or
>other express written agreement between Experian Limited and the recipient
>Experian Limited (registration number 653331) Registered office:
>Talbot House, Talbot Street, Nottingham NG80 1TH
>
>Although Experian has taken reasonable steps to ensure that this
communication
>and any attachments are free from computer virus, you are advised to take
>your own steps to ensure that they are actually virus free.
>

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

[login to unmask email]

Re: Adabas to DB2 conversion
(in response to Roger Miller)
If Roger cannot get his hands on the Redbook, I have a hard copy of it. I
can send you a copy.

I did that conversion back then. It required a lot of design effort in
order to accommodate some of the things that were allowable in ADABAS that
would not work in DB2 V1.2.

Contact me off-list if you need the manual.

Carol Sutfin
Corporate DBA
AmSouth Bank
(205)261-5214
[login to unmask email]




"Roger Miller"
<[login to unmask email] To: [login to unmask email]
.COM> cc:
Sent by: "DB2 Subject: Re: Adabas to DB2 conversion
Data Base
Discussion List"
<[login to unmask email]
.ORG>


01/28/2004 01:22
PM
Please respond
to "DB2 Database
Discussion list
at IDUG"





There are many good responses about experience. I thought perhaps a
couple of additional resources might be useful. If you want it, I think I
can find the 1989 conversion guide from Adabas to DB2. The information
about porting is primarily at these URLs now:
http://www.ibm.com/developerworks/db2/zones/porting/

I went out with Google searching for Adabas DB2 convert and found many
services and vendors with tools: Serena, FBO Sabresoft, Softscout, ...
http://www.wizinc.com/documents/JWolsey.ppt
http://builder.com.com/5100-6315-5034355.html

Roger Miller

On Thu, 22 Jan 2004 13:51:33 -0000, Foweather, Iris
<[login to unmask email]> wrote:

>We have an application running in Adabas and are looking at feasibility of
>converting/redesigning it to use DB2. As usual it all hinges on cost, both
>for the conversion process and the ongoing running costs.
>
>Does anyone out there have experiences they are willing to share of
>converting Adabas to DB2 and the difference in costs involved in running
it
>in DB2?
>
>
>Regards,
>
>Iris
>
>Iris Foweather
>Technology Services
>Experian
>Tel: 0115 9344312
>Email : [login to unmask email]
>
>
>
>This e-mail has come from Experian International: winner of the UK's
National Business of the Year Award 2003.
>
> =
>Information in this e-mail and any attachments are confidential, and may
>not be copied or used by anyone other than the addressee, nor disclosed
>to any third party without our permission. There is no intention to
>create any legally binding contract or other binding commitment through
>the use of this electronic communication unless it is issued in accordance
>with the Experian Limited standard terms and conditions of purchase or
>other express written agreement between Experian Limited and the recipient
>Experian Limited (registration number 653331) Registered office:
>Talbot House, Talbot Street, Nottingham NG80 1TH
>
>Although Experian has taken reasonable steps to ensure that this
communication
>and any attachments are free from computer virus, you are advised to take
>your own steps to ensure that they are actually virus free.
>

---------------------------------------------------------------------------------

Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
"Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org
. The IDUG List Admins can be reached at [login to unmask email]
Find out the latest on IDUG conferences at
http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm