This Db2 for z/OS News from the Lab blog entry was originally published on 2019-06-05.

By Ann Hernandez.

ITERGO is an affiliate of its holding company ERGO AG, which is a major insurance group that operates in Germany, throughout Europe, and worldwide. Headquartered in Düsseldorf Germany, ITERGO is the company’s IT service provider and employs about 1700 people at four locations in Germany.

This blog post is based on a recent conversation with two key ITERGO employees, who shared their perspective on the company’s migration to Db2 12 for z/OS.

• Walter Janissen, a DBA for the application development area, has worked with Db2 since V1.1. His role in migrations has mainly been during the ESPs for new versions. Walter is also an IBM Champion and speaks at conferences about Db2 and other IBM products.
• Jürgen Ritterbach, a system programmer who secondarily supports the application development area, has worked on Db2 since V2.3. Jürgen has been actively involved in migrations since V8.

First, a bit of history. ERGO has merged with three other companies over the past 20 years, so the IT system has evolved accordingly. The IT systems for four companies are now all consolidated into one Db2 data sharing system with one data model and one physical database design. The ERGO mainframe environment (z14) runs on two nearby sites, which support 16-17 million transactions each day. All valuable ERGO company data is in the Db2 systems, which are configured as 6-way data sharing groups. (In addition, the ERGO Direct subsidiary has five non-data sharing Db2 systems in test/development and one in production; ERGO Direct systems have not yet migrated to Db2 12.)

ITERGO participated in the Db2 12 ESP, which began early in 2016. After GA in the fall of 2016, they began migrating their environment, one system at a time, in early 2017. Between August and October 2017, they completed migration and activated new function mode. All Db2 systems for the ERGO holding company (seven test/development systems and three production systems) have successfully migrated to Db2 12 FL501. ITERGO plans to move to FL503 this spring.

When asked about the motivation for migrating to Db2 12, Walter and Jürgen mentioned several new functions that answered past requirements that ITERGO had submitted, including several optimizer enhancements and the capability to insert partitions. In addition, ITERGO sees the move to continuous delivery as good news. Version-to-version migrations take a lot of time and resource, so Walter and Jürgen believe that continuous delivery will be far less disruptive for them and will allow them to reap the benefits of enhancements that are shipped on an ongoing basis, rather than waiting for a new version of Db2.

ITERGO now has a third-party service provider that handles basic operations; the migration to Db2 12 meant a lot of coordination with the outside provider, who was not yet familiar with Db2 or with continuous delivery concepts. Although Walter and Jürgen acknowledge that they need to do more work to establish an efficient and effective process for them to work with their service provider, Walter says, “Every migration in the future will be easier because you need only to move to a new function level instead of doing a complete version-to-version migration.”

As an early adopter, ITERGO faced some technical challenges with the migration to Db2 12. They had a problem with insert algorithm 2, or IAG2, during the ESP, which was resolved after GA; this new function is now working well. They also experienced some ODBC connection problems, some INCORROUT problems with fast index traversal (sometimes called fast traverse blocks or FTB), and some problems with vendor tools, which occurred because the vendors were not ready to move to FL501. ITERGO did a fallback in early 2018 on one production system (their primary one) because of problems with FTB. They moved forward to FL501 in late spring 2018 but will wait to begin using FTB until after they install new software prerequisites associated with an available PTF that resolves an FTB problem that they experienced.

Recommendations for other clients who are preparing to migrate

Walter and Jürgen offered some useful advice for clients who have not yet migrated to Db2 12:

• Establish your test strategy for migration and for continuous delivery. Take care to test your systems and your data when you enable new functions. Do not assume things will work fine in production (with much larger workloads) if they work okay in test.
• If you use vendor software, work carefully with vendors so that they are ready to move to new function levels when you want to use the new functions. If you really need to use a new function that is being delivered in a function level and the vendor is not ready, you will need to wait for them before you can use the new function.
• Before migration, decide how much time you will spend at each stage, as you move between the initial migration (V12R1M100) and the first post-migration function level (V12R1M500). Leave enough time so that you have time to adequately test and address problems that might occur along the way.
• If you want to use new functions from the distributed side, make sure the data server packages are at the right APPLCOMPAT level. Jürgen explained how ITERGO approached this: “We kept one collection of packages available for the production system. When we wanted to move forward, we used a separate collection with the latest set of packages for function level testing. Not every remote system is ready for a new function level, because software updates on the distributed side might need to happen first.”
• Migrate during periods with reduced workload activity to avoid disruption or slow performance on the production system.
• Activate new functionality (such as FTB) carefully, making sure to verify that data you expect to see is there and that it looks as you expect. Do thorough testing on the test and development systems first, before moving to production. When you move to production, double-check to make sure everything works correctly because problems sometimes occur for the first time in production when you have a larger workload.
• Coordinate with outside service providers if you have them, like ITERGO does, before the migration and then on an ongoing basis as you activate new function levels.
• Consider whether your rebind strategy will work well with migration to Db2 12 and continuous delivery, and adjust your strategy as needed. For example, ITERGO chose not to rebind their packages because they wanted to ensure consistency in performance across Db2 11 and Db2 12. Walter pointed out that some customer installations might choose instead to rebind with APREUSE so that the prior (Db2 11) access paths are rebuilt into the new Db2 12 runtime structures.

Summary of the ITERGO migration experience

As mentioned earlier, Walter and Jürgen have both been involved in many Db2 migrations over the years. Even though they experienced a number of problems along the way, they are both very satisfied with the actual migration process for Db2 12. In fact, Jürgen says, “This was the best, smoothest migration we have experienced, compared to previous migrations, in terms of the amount of time required and the impact to the surrounding environment.”

#Db2Znews
​​