International Business Machines Corporation (IBM) Earnings Call Transcript & Summary

Hello. Good morning or good evening wherever you are in the world. This is John Campbell, a Distinguished Engineer in IBM Db2 for z/OS development. Welcome to today's webcast, which is part 1 of a 2-part webcast on the subject of Db2 12 for z/OS migration planning and experiences. At the end of the part 1 today, there will be a live question-and-answer session. Now let us turn to the next slide. Here on Slide 2, I would like to go over the objectives for today's webcast. I would like to share lessons learned, surprises and pitfalls, provide some hints and tips, address some myths that have grown up around Db2 12 for z/OS, provide additional planning information, provide usage guidelines and positioning on the new enhancements and lastly, and most importantly, help customers migrate as fast as possible, but to do so safely. Now let's turn to the next slide. Going on Slide 3 is the agenda for today's webcast in terms of those sub topics to be discussed. I will, first of all, introduce and discuss the prerequisite for migrating to Db2 12. I will then provide some quick hits in terms of the most important factors around the migration itself. This will be followed by a set of important recommendations regarding preventative service planning for Db2 12 and continuous delivery. I will then introduce and discuss the activities you can perform to mitigate the risk of migrating to Db2 12. Next, I will switch to discussing continuous delivery under Db2 12, how to adopt new function levels and also how to use APPLCOMPAT. Finally, I will share with you John Campbell recipe for a safe, successful migration. Now let's turn to the next slide. Here on Slide 4 is the agenda in terms of the list of topics to be discussed in part 2 of this webcast tomorrow. In part 2 of this webcast, I will mainly concentrate on introducing and discussing the most important and popular features of Db2 12. In each case, I will try to explain the design point for each new enhancements, the considerations which apply around customer adoption and any issues that apply. Now let's turn to the next slide. Here on Slide 5, I would like to start discussing the Db2 11 prerequisites for migration to Db2 12. The first item is to ensure that the existing production Db2 11 catalog and directory data objects are consistent and ready for the migration to Db2 12. This activity should be performed early and often to ensure that any data inconsistencies which exist are identified as soon as possible and addressed in a timely manner, so as to not delay the migration to Db2 12. Do not wait until just before or at the time of the migration to Db2 12. The question is how to do it in a nondisruptive way? One option is to exploit the DR Test environment. Once the DR Test is complete, and before tearing the environment down, use this environment to perform data consistently backing and also practice the migration process from Db2 11 to Db2 12. Another alternative is to clone the existing production Db2 11 catalog and directory data objects over into a test subsystem or data sharing group and then cold start this environment with new active logs. Again, use this test environment to perform the consistency checking and practice the migration. Next, run the pre migration check queries supplied with the job DSNTIJPC for Db2 11 and the job DSNTIJPM for Db2 12. Most importantly, review the output and act on the findings which need remedial action. For example, rebind any old 31-bit plans and packages under Db2 11 before migrating to Db2 12 so as to avoid disruptive auto bind activity. Make sure you apply the PTF for the fallback SPE to all members of each Db2 data sharing group and also to each stand-alone Db2 subsystem. Failure to do so will prevent the respective Db2 data sharing group or the respective stand-alone Db2 subsystem from being migrated to Db2 12. As well as continuously applying preventative service to Db2 12, you should also be maintaining a reasonably current level of Db2 11, so as to confidently exploit mixed release coexistence during the migration to Db2 12 and also to be confident about release fallback to Db2 11 and the subsequent remigration to Db2 12. I also recommend that you augment any new RSU or PUT level by adding an additional PTF guest recommended by the SMP/E fixed categories for migration fallback and mixed release coexistence with data sharing. Now let's turn to the next slide. Here on Slide 6, I would like to continue discussing the Db2 11 prerequisites for migration to Db2 12. You must convert the BSDS dataset pair for each Db2 subsystem to the 10 byte extended log RBA format before leaving Db2 11 new function mode. For data sharing groups, you can convert single member at a time. There are some important things to consider before converting the BSDS pair using the supply job DSNJCNVT. Firstly, you must stop the Db2 subsystem that owns the subject bootstrap data set pair. Secondly, any utilities, such as RECOVER or REORG, running on an alternate Db2 member of the data sharing group that reads from the peer BSDS must be terminated. There are special considerations for data replication. You must stop any data replication process to ensure the BSDS dataset pair can be successfully renamed and replaced, and the recommended best practice is to stop the data replication process first and then stop the respective Db2 subsystem. Thirdly, the RACF user ID, running the DSNJCNVT job must have read/write access to the new bootstrap dataset pair and read access to the old BSDS dataset pair. After converting the BSDS dataset pair, you will see an increase in logging volume for that Db2 subsystem, and that's because of an increase in log record size because of the extended format. And that could be somewhere between 3% and 40%. And in the case of 1 specific customer installation, that increase was 23%. Also, there will be a further increase in log record size after entry to Db2 12 because of the 7 byte RID values introduced as a result of relative page numbering. And this increase in size will be experienced regardless whether you're using UTS PBR relative page numbering or not. So there are some important considerations. Each customer will need to consider increasing the size and number of active log dataset pairs so as to maintain the recommended 6 hours of recovery log data at all times across the active log configuration. Customer installations will also need to reevaluate the size of the archive log DASD pool so as to ensure 48 hours' worth of recovery log data can be kept in the pool. Now let's turn to the next slide. Here on Slide 7, I would like to continue discussing the Db2 11 prerequisites for migration to Db2 12. I strongly recommend that you avoid disruptive autobind processing on pre-Db2 10 plans and packages running under Db2 12. These old migrated plans and packages have a 31 bit run time and the 31 bit run time is no longer supported under Db2 12. So when these old migrated plans and packages are first touched on the Db2 12, the respective plan or package will be marked invalid and trigger autobind processing to create either a brand-new Db2 12 plan or brand-new Db2 12 package. Many customers have suffered some painful lessons related to plans. The thread breaking capability delivered in Db2 11 may help for packages when customers are performing a rolling migration to Db2 12. But no such capability exists for plans. I recommend that you explicitly rebind these old migrated plans and packages under Db2 11 new function mode before leaving for Db2 12. This will give you the ability to resolve any potential authorization issues that may exist and you can also use plan management for packages to keep a backup copy of the package. For data sharing customers who plan to execute an online migration, I strongly recommend that you set the ZPARM ABIND to COEXIST. This is because, for a period of time, you'll be running in mixed release coexistence, where some members will be running on Db2 11 and the other members will be running on Db2 12. Why should you care? This is because there's potential for a tariff sell [ effect ] of repetitive autobind ping pong activity across the Db2 11 and Db2 12 members. This is because those plans or packages that were previously autobound under Db2 12 will not execute under Db2 11, and they will be marked invalid again and go through autobind to create a brand-new Db2 11 plan or brand new Db2 11 package. Because of the disruption cost to customers, we made a design change to Db2, and this was introduced APAR PI87675. With this APAR, remigration autobinds under Db2 12 are now disabled. This solution applies to both plans and packages. And it applies equally well to when an ABIND is set to COEXIST and when ABIND is set to yes, you will get exactly the same behavior, which is that remigration autobinds or reentry to Db2 12 will now be disabled. With this APAR, we deliver a complete solution for both Db2 11 and Db2 12. Now let's turn to the next slide. Here on Slide 8, I would like to continue discussing the Db2 11 prerequisites for the migration to Db2 12. If you were using plan management, then you should free off the inactive copies of all packages before performing the first rebind from the Db2 12. This is because the original copy of each package may now be very old and no longer viable is a fallback option. By freeing off the inactive package copies, then the first REBIND under Db2 12 will create a new original and a new previous package copy, which will be the migrated Db2 11 package that was previously used prior to the rebind under Db2 12. And the current package copy has now been replaced by the new package created under Db2 12. When migration to Db2 12, the EXPLAIN table should be at least in Db2 11 format. I would recommend that you upgrade the EXPLAIN tables to Db2 12 format ahead of the migration to Db2 12. This upgrade can take place on the Db2 11 new function mode after the fallback SPE has been applied. You can use the sample batch job DSNTIJXA with the REXX program DSNTXTA to help with the migration. For data sharing customers who plan to perform a rolling online migration to Db2 12, please ensure that the PTF for APAR PI69589 is applied to Db2 11 and the PTF for APAR PI69584 is applied to Db2 12. Both of these enhancements are aimed at reducing contention on the Db2 catalog and directory during an online migration. When running Db2 12, the Db2 EARLY code must be either at the Db2 11 level or the Db2 12 level. Ideally, it should be the Db2 12 level. You can still run Db2 11 using the Db2 12 EARLY code. Some customers are still leveraging an IPL to introduce a new version of the early code. This is no longer required. Since Db2 9, new EARLY code can be introduced using the Db2 REFRESH command. The refresh command will reload and replace the early code modules that were last loaded at the last IPL, and it will rebuild the EARLY controlled block. There are some restrictions and considerations, which apply when using the Db2 REFRESH command. The library that contains the new EARLY code must have been in the links contamination as at the time of the last IPL. If the DSN link library is LLA managed, you must perform an LLA REFRESH after you apply the EARLY code maintenance and before you issue the Db2 REFRESH command. The LLA REFRESH can be performed by using the Db2 modify LLA REFRESH command. Now let's turn to the next slide. Here now on Slide 9, I would like to switch topics I would now like to provide and discuss some quick hits about the Db2 12 migration. The minimum operating system-level has been lifted from z/OS version 1 release 13 to version 2 release 1. And the minimum hardware level has been lifted from z10 to z196 and z114. I get a lot of questions about what are the actual prerequisites for data replication. You must apply the PTF for APAR PI70998 to Db2 12 engine, and Db2 11 requires the Q Capture and Capture programs from IBM InfoSphere Data Replication to be version 10.2.1. The Q Apply and the Apply programs must be at architecture Level 1,001, and this will work with both Db2 11 and Db2 12. And then on this slide, are listed the specific APARs for the Db2 engine, which is APAR PI70998, and the APAR for IIDR 10.2.1 Q and SQL replication, which is PI66768. And finally, the APAR for change data capture, which is PI61562. Now let's turn to the next slide. Here on slide 10, I would like to continue providing and discussing quick hits about the Db2 12 migration. And specifically, I'm going to talk about Db2 Connect. And the situation described on this slide, is the situation that occurred until very recently and before you apply the PTF for APAR PH08482. Basically, any level of the Db2 Connect drivers should work with the Db2 12 engine, both before and after new function is activated, and there should be no behavioral change. In order to exploit continuous delivery function, the data server clients and drivers must be at the following levels to explore Db2 for z/OS application compatibility level or V12R1501 or greater. You need to have the IBM data server driver for JDBC and SQLJ and version 3.72 or 4.22 or later. And the other IBM data server clients and drivers, in other words, Db2 for Linux, UNIX and Windows should be at 11.1 Modification level 2 fix Pack 1. Why are these new levels required? This is because of the new property called client application capability, and it's available for both ODBC and JDBC. This property setting allows you to control the capability of the clients when updating the drivers where the drivers ship changes to enable new Db2 server capability. For example, you might want to control specific driver capability when the Db2 client driver introduces new behavior currently not controlled by the Db2 APPLCOMPAT or the change needs to be controlled at the application level to ensure compatibility with the new behavior. The client APPLCOMPAT setting or V12R1M500 is required to access Db2 server capability shipped after GA at function levels beyond 500. And please note carefully the Db2 Connect Server gateways do not support this new ClientApplCompat setting. Now let's turn to the next slide. Then on Slide 11, I will continue providing and discussing quick hits about the Db2 12 migration, and I will continue on the subject of Db2 Connect. Here on this slide, I want to talk about the new behavior after applying the PTF for APAR PH08482. With this APAR, it will make the setting of the ClientApplCompat property optional, and customers are no longer forced to have this setting. No changes are required in the Db2 Connect level and the Db2 Connect configuration. As before, all customers who want to exploit continuous delivery function must upgrade to at least Db2 Connect, V11.1 fix pack 1 or higher in order to run DRDA applications where the APPLCOMPAT on the package is greater than function level 500. It is a similar story with Db2 Connect server gateways who want to exploit continuous delivery function. These must be upgraded to at least Db2 Connect, V11.1 fixed pack 1 to access packages, which have an APPLCOMPAT than function Level 500. Note that when the client APPLCOMPAT property is set, Db2 will perform validation checking where there are changes in the DRDA message flows. In other words, check the underlying infrastructure and avoid application incompatibilities. Now let's turn to the next slide. Here on Slide 12, I would like to continue providing and discussing quick hits about the Db2 12 migration. On this slide, I will continue discussing the new Db2 Connect behavior after applying the PTF for APAR PH08482. Going out into the future, there is potential risk of breaking existing applications when there are changes in DRDA command flows and the ClientApplCompat property is not set. So far in Db2 12, there are no changes in DRDA command flows and no changes are currently in plan, but at some point in the future, it is likely to happen. So applications may break in the future when DRDA transactions are running with a package, which has an APPLCOMPAT greater than function level 500. So if an application breaks then Db2 developments will not provide server side support to allow these broken applications to run. In other words, there will be no more new DDF compatibility ZPARM settings. So as a customer, what are your options? Firstly, you can rebind the driver packages in the NULLID collection and back level the APPLCOMPAT setting. This is a one size fits all solution to fallback to an earlier APPLCOMPAT level. Secondly, you could penalty box the problem applications, and there's 2 flavors of this. Firstly, you can switch the problem applications out to use the driver packages in a different collection, which has a back leveled APPLCOMPAT setting or you could switch all the good applications out into a new collection using driver packages with the new APPLCOMPAT setting and then leave the problem applications still using the old driver packages in the NULLID or a different collection but with the driver packages running a back leveled APPLCOMPAT setting. Now let's turn to the next slide. Here on Slide 13, I will continue providing and discussing quick hits about the Db2 12 migration. On this slide, I will conclude the discussion about the new Db2 Connect behavior after applying the PTF for APAR, PH08482. I now want to provide some general best practice recommendations in this area. When migrating to Db2 12, all DRDA applications should continue to use the driver packages in the NULLID collection. These packages can have an APPLCOMPAT setting of V10R1, V11R1, V12R1M100 or V12R1M500, depending on where you are in the migration process to Db2 12. The APPLCOMPAT setting for the driver packages in the NULLID collection should not be advanced beyond V12R1M500. When specific applications and their application servers want to use new functions, requiring a higher APPLCOMPAT setting these application servers should switch away from using the driver packages in the NULLID lection to a new collection where the driver packages are bound with a higher APPLCOMPAT setting. So for example, if an application or an application server wants to use new function at, say, function level 503, they should point to a collection of V12R1503, in which the driver package has been bound with an APPLCOMPAT V12R1503. Now let's turn to the next slide. Here on Slide 14, I would like to continue providing and discussing quick hits about the Db2 12 migration. There are changes in Db2 12 related to the utilities suite installation. And the utilities suite has to be reregistered in the IFAPRD PARMLIB member. This is because IBM has decided to sunset the custom built product delivery options, CBPDO for short, and SystemPac is the strategic direction. Any separately orderable product using F or J FMIDs like utilities suite has to be changed to use the E or H base FMID. How to reregister the utilities suite is clearly documented in the program directory. Failure to do so correctly, or not at all, will result in the following messages which are amazingly accurate. Now let's turn to the next slide. Here on Slide 15, I would like to continue providing and discussing quick hits about the Db2 12 migration. I would here like to discuss the REORG mapping table format, which has been changed to allow for 7 byte RID values. This is because, in Db2 12, we've introduced the option of relative page numbering for UTS PBR tablespaces. There are some SQL DDL changes. The column SOURCE_RID has been expanded from CHAR(5) to CHAR(7). The column TARGET_XRID has been expanded from CHAR(5) to CHAR(7). There's no toleration logic in Db2 11 new function mode for the version 12 format of the mapping table, which means that when you run REORG under Db2 11 new function mode with the Db2 12 format for the mapping table, the REORG will fail. Db2 12, running with function level V12R1M100 will still tolerate the Db2 11 format of the mapping table. But when you run the REORG under Db2 12 at function Level V12R1500 or later, this will only support the Db2 12 format of the mapping table. In terms of the incompatible changes, the BIF_COMPATIBILITY system parameter is still fully supported. IFCID 366, which was used for tracing application incompatibilities, has been removed. This is because it was unattractive to use because of the sheer volume of records. It has now been replaced by IFCID 376. A typical customer complaint to me is that when you collect IFCID 376, you cannot match the contents with the dump contents of the dynamic statement of cache. So as a recommendation to provide a pragmatic solution, I recommend that you can turn on IFCID 376 for only 10 minutes and then dump the contents of the dynamic statement cache. Now let's turn to the next slide. Here on Slide 16, I would like to continue to provide and discuss quick hits about the Db2 12 migration. The Db2 system parameter REORG_IGNORE_FREESPACE has been removed. This is because of an enhancement in Db2 12 that when you're running a part level REORG against the UTS PBG table space, if the data will not fit back into the partition then rather let the REORG fail, Db2 will add a new partition to the tablespace at the end. There are RACF changes related to IDAA. Db2 12 now uses the TCPIP.DROP API and RACF profiles must be defined to allow Db2 to use this API. The z/OS system parameter HVSHARE should be set to 510 terabytes, which is the default. Db2 12, like Db2 11, requires 1 terabyte of 64-bit shared private storage for a subsystem. This memory is virtual. It's not real. It's basically reserving and addressing range, and you can monitor the use of HVSHARE using IFCIDs 217 and 225. When planning for Db2 12, you should plan for a REAL memory increase. The trend continues for Db2 12 of using larger size REAL memory to deliver performance improvements, and most customers should expect about a 15% increase. So you should expect up to a 30% increase if you're taking advantage of new in-memory performance functions. The largest percentage will come from the use of Fast Traverse Block area, which defaults to AUTO, which is 20% of the total allocated VPSIZE across all buffer pools. The trend also continues to extend zIIP offload. So you should consider your existing zIIP utilization and upgrade zIIP capacity if needed. There are additional functions in Db2 12, which will use zIIP capacity available, Fast Traverse Block monitoring, pipe management for insert algorithm 2, the RELOAD phase of the REORG load utilities and the child task eligibility for SQL query parallelism has been extended from 80% to 100%. Now let's turn to the next slide. Here on Slide 17, I would like to continue presenting and discussing quick hits about the Db2 12 migration. There will be an increased space requirement for the RID pool as a result of the RID value size increasing from 5 to 8 bytes. Even though relative page numbering option of UTS PBR tablespaces only requires 7 bytes, internally, Db2 uses a normalized 8 byte RID value to allow for future expansion. Such as having page sizes greater than 32k and/or having more than 255 rows per page. So more RID loss will be used for the same query because each RIDLIST holds fewer RIDs. RID pool memory usage will be roughly 60% higher. And for a very small list, it may be up to 2x higher. So you may have to increase the RID pool size by the system parameter MAXRBLK by up to 60%. The data manager logical limit has been reduced from 26 million, down to 16 million RIDs, and therefore, you're likely to see more RID pool overflow to the workfile. There's also going to be an increased space requirement for the RID pool as a result of potentially more use of list prefetch in Db2 12. There has been an enhancement to the Optimizer cost model to more closely reflect the true cost and benefit of list prefetch. So I expect to see an increase in list prefetch and potentially hybrid join, but not necessarily changes in the access path where Db2 would previously have chosen a sort avoidance plan. Db2 has been very careful here not to select list prefetch with a sort as an access path when there's an alternative access path that could use an index to avoid a sort such as pagination type SQL. Now let's turn to the next slide. Here on Slide 18, I would like to continue providing and discussing quick hits about the Db2 12 migration. On this slide, I will be discussing the increased EDM pool memory requirement for DBDs. Starting with Db2 12 function level V12R1M100, there will be an increased demand for EDM pool memory for DBDs. How much depends on the size and number of tables and the number of tablespaces in the respective DBD. The extra memory comes from the puffing of the pre Db2 12 migrated DBDs to the new DBD format in Db2 12. The puffed size of the migrated DBD under Db2 12 will be greater than the size of the Db2 12 format DBD that has been persisted and externalized after an alter or repair operation under Db2 12. The size of the Db2 12 format DBD will obviously be bigger than the Db2 11 format DBD. Starting with Db2 12 function level V12R1M100. The puffed DBD will not be written out to DBDL1, which means that the puffing of the migrated DBD to Db2 12 format will occur every time the DBD is read from the DBDL1 object into the EDMDBDC pool. As from Db2 12 function level V12R1M500 and before the PTF for APAR PH05624 is applied, the puffing code is invoked even when the DBD is already in Db2 12 format. The only blessing is that there's no further additional memory increase since the DBD is already in Db2 12 format. Some customers have experienced significant performance impact after the migration to Db2 12 because of the extra EDM pool space required. I recommended to you a package of solutions to address the issue. Firstly, double the size of the EDMDBDC pool. Secondly, apply the PTF for APAR PH05624 and any DDL or repair DBD rebuild operation will result in the update of the DBD to Db2 12 format and the new format will be persisted in DBDL1 object. Now let's turn to the next slide. Here on Slide 19, I want to continue presenting and discussing quick hits about the Db2 12 migration. One of the goals of Db2 12 is to reduce CPU resource consumption by avoiding scheduling our dynamic prefetch engine when sequential detection triggers dynamic prefetch and where all of the pages are in the buffer pool, almost all of the time. The goals here are to reduce the risk of running out of prefetch engines, reduced DBM1 SRB CPU time and to reduce latch class 24 contention. The solution is for dynamic prefetch to use new buffer pool statistics to drive intelligent decisions about when to disable dynamic prefetch and when to re-enable dynamic prefetch. The 2 new statistics are the number of dynamic prefetch iOs and the number of sequential sync iOs. When about to schedule a dynamic prefetch request, Db2 maintains a counter about the number of times dynamic prefetch iO occurred. It checks whether the dynamic prefetch iO count has not changed. If this happens 3 times, dynamic prefetch scheduling is disabled, and Db2 starts recording the number of sequential sync iOs for the buffer pool. Once dynamic prefetch scheduling is disabled, but the number of sequential sync iOs has changed, then the scheduling of dynamic prefetch is reenabled. Now let's turn to the next slide. Here on Slide 20, I will continue presenting and discussing quick hits about the Db2 12 migration. The subject on this slide is the deprecation of basic row format. The Db2 system parameter SPRMRRF, which controls the conversion of objects from basic row format to reordered row format is now hidden in Db2 12. The row format keyword option of the REORG unload utility to convert a page set between basic row format and reordered row format has been removed from all the documentation. The row format keyword option is still fully supported from a utility syntax and function perspective. All new objects created will always be created in reordered row format. Existing page sets in basic row format will continue to be supportive for the time being. There is no issue about recovering a tablespace to a previous point in time before the conversion to reordered row format. Db2 will recover the object to that previous point in time using an image copy in basic row format. At the end of the recovery, the catalog and directory will be updated to reflect basic row format. Now let's turn to the next slide. Here on Slide 21, I would like to continue presenting and discussing quick hits about the Db2 12 migration. The subject on this slide is an incompatible change related to the invalidation of prepared SQL statements in the dynamic statement cache. Prior to Db2 12, RUNSTATS would always invalidate prepared statements, dependent on the object that the utility was run against. In Db2 12, RUNSTATS, by default, will not invalidate the prepared statements. So this is an incompatible change, but in most cases, this is a welcomed change. If you really want to invalidate the prepared statements, there's a new option on RUNSTATS called INVALIDATECACHE YES. And that will force the invalidation of prepared statements. The invalidation of prepared statements will still occur when the following conditions occur: RUNSTATS is executed with the INVALIDATECACHE YES option; RUNSTATS is executed after SQL DDL, such as create and drop index and the statistics profile has been updated; RUNSTATS has been executed with the UPDATE NONE REPORT NO option; and for other utilities that the object was in an invalid state before the utility began execution, such as rebuild pending or REORG pending. Now let's turn to the next slide. Here on Slide 22, I would like to continue presenting and discussing quick hits about the Db2 12 migration. The topic on this slide is an incompatible change related to buffer pools, which are using both the PGSTEAL(NONE) attribute and 2 gigabyte size large page frames. The key to the story is that when you're using PGSTEAL(NONE) buffer pools, they automatically start using the new contiguous buffer pool feature on entry to Db2 12. And when you're using the new contiguous buffer pool feature, one memory object is allocated per paid set petition, and therefore, there's a risk of wasting large-sized real memory. So the incompatible change occurs immediately when migrating from Db2 11 to Db2 12. On the Db2 11, Db2 can still use 2 gigabyte size frames for PGSTEAL(NONE) buffer pools. But under Db2 12, PGSTEAL(NONE) buffer pools are allocated as contiguous buffer pools, and they cannot use 2 gig size frames. The request to use 2 gigabyte size frames is not honored, but the buffer pools will still be allocated, but in 4K size frames. There's a new Db2 message DSNB 548I, which will be issued under 2 situations: firstly, allocating a buffer pool, which has PGSTEAL(NONE) and frame size 2 gig specified; and secondly, when there's an auto buffer pool command, that changes either attribute, but it results in the combination of PGSTEAL(NONE) and frame size 2 gig. So why should you be concerned if the size of the contiguous buffer pools are very large, this can lead to a shortage of 4K size frames on the LPAR, and this will have consequences. Firstly, the penalty of page movement or paging I/O overhead with the corresponding CPU burn in the RASP address base and in the worst case, the LPAR may crash out. So have a strong recommendation. If you are using 2 gig size large frames for PGSTEAL(NONE) buffer pools under Db2 11, you should switch to using 1 meg size frames before leaving Db2 11 New Function Mode for the Db2 12. Now let's turn to the next slide. Here on Slide 23, I would like to discuss preventative maintenance, policy and recommendations for Db2 12 and continuous delivery. Applying regular drops of preventative service is very important for closing the gap on missing service and vital to maintain the stability of your Db2 systems. I strongly recommend that you stay reasonably current on preventative service. Applying maintenance only once or twice a year is definitely not enough. And there's also a definite need to regularly review HIPERs and PE fixes, at least, on a weekly basis. You should apply preventative maintenance every 3 months based on a rolling calendar. You should use RSU instead of PUT levels so as to be less aggressive on applying non-HIPER maintenance. Here, I recommend a sample strategy based on 2 major and 2 minor releases of preventative service. Every 6 months, there should be a refresh of the base, which I call a major release, and each base upgrade should be based on the latest quarterly RSU. You should ensure that RSU-only services installed by adding the source ID, RSU* option in the supplied APPLY and ACCEPT jobs. In addition, apply too many packages covering HIPER and PE fixes only in between. And this is called a minor release. You should also implement a continuous program to review Enhanced HOLDDATA on a weekly basis. You should do this with rolling out a maintenance package to production and also after postproduction cutover. For vicious HIPER problems where there's no operational bypass or workaround, you should expedite the fix into production after maybe 1 to 2 weeks in test. Other fixes can be deferred until the rollout of the next major or minor maintenance drop. You can do this by applying an operational bypass or workaround in production if it exists or it may only be a low-grade problem in production, in which case, you can carry on or the problem may not be applicable. Now let's turn to the next slide. Here on Slide 24, I would like to discuss the problem introduced by having different APAR numbers across Db2 11 and Db2 12 for the exact same problem. This came about because of our own internal DevOps project in which we switched the software for our library management subsystem. The short-term solution was to make the connection visible bidirectional either in the sysrouted FROM or the sysrouted TO section of the outline overview of the respective APAR. Here on this slide is an example where we have the APAR PI76204, which in the sysrouted TO section points to PI76206. Now let's turn to the next slide. Here on Slide 25, I would like to continue discussing the problem of having different APAR numbers for the exact same problem across Db2 11 and Db2 12. The solution has been to go back to providing a single APAR for a single problem for all new APARs that are now being delivered, and this started in June 2017. The default behavior now is to have a single APAR for the same problem across both Db2 11 and Db2 12. This does assume the same basing chain. So occasionally, there will be a few exceptions. This solution will not be applied retrospectively. Now let's turn to the next slide. Here on Slide 26, I would like to introduce and discuss risk mitigation around the Db2 12 migration. Regression testing is a critical piece to keep fires away from production. You should test all critical and custom processes and scale them up. You should run performance measurements on the Db2 11 New Function Mode and establish a performance baseline for comparison against Db2 12. There should be a formal go and no-go decision for Db2 12 migration of production system, and this should be based on positive results from proper testing. And you should be prepared to postpone the migration as opposed to forcing in Db2 12. You should practice migration fallback from Db2 12 to Db2 11 New Function Mode and then back again to Db2 12. You should design your fallback strategy and practice it in preproduction environments. You should minimize change and the use of new function in and around when Db2 12 is first introduced into production. For production systems, you should stay on function level version 12R1M100 for at least a month to prove running smoothly, and that way, it leaves the back door open if there is any instability, you can go back to Db2 11 New Function Mode in an emergency. You should make sure you're very current on preventative service for these specific new Db2 12 functions: fast index traversal for the in-memory index performance optimization; Insert Algorithm 2 for the fast unclustered insert; UTS PBR Relative Page Numbering; the improved EDM pool management; and the increased active log dataset size. Now let's turn to the next slide. Starting here on Slide 27, I want to discuss continuous delivery under Db2 12, and I want to begin by discussing the old Db2 strategy for delivering new function. In the old world, we used to deliver most of our new function in a new release, and that occurred approximately every 3 years. And Db2 was typically on a 3-year cycle, but some of our customers were, in fact, on a 4-year cycle, and hence, the continued customer interest in skip-release migrations. We develop or retrofit a very limited number of new features in the service stream but only if they are urgent and generally low risk, such as in the utilities area. The deployment of new releases is often seen as disruption by our customers. On the other hand, many of our customers launching new features delivered much faster. And the industry and customer trend is to move away from monolithic codelivery towards a continuous delivery model. So IBM is moving towards this continuous delivery model and it's time for us in Db2 to change. Now let's turn to the next slide. Here on Slide 28, I would like to discuss the new Db2 strategy for delivering new function. This is continuous delivery on the Db2 12. We are dedicating ourselves going forward to this continuous delivery model and radical internal changes are required within Db2 development to be able to do this. Db2 12 is the starting point after general availability. And there will be a significantly higher number of continuously delivered items. Customers will see a single maintenance stream for Db2 12, with the new function delivered into that and the function will be designed to be easily consumable. Point releases or new versions will be a very rare exception, and there will be some reasons that might result in a new point release or a new version, such as, for example, a new compiler, extending control block structures or enabling a new architectural level set. Db2 development will have relentless focus on maintaining continuous production level reliability for you in the service stream, and we are dedicating ourselves to doing this. We will control the input to the pipe in terms of the size and risk of the items. There will be an increased internal focus on function and performance regression testing, and we will deliver new function when the quality is right and not based on a promise date for delivery. Now let's turn to the next slide. Starting here on Slide 29, I would like to provide a tutorial on continuous delivery with Db2 12. With continuous delivery, there's a single delivery mechanism for all defect fixes and all new enhancements. PTFs and collections of PTFs provided through a PUT level and an RSU are applied in the same way as today. As you progressively upgrade the maintenance, then the maintenance level or ML for short, of the data sharing group or stand-alone subsystem will increase. With continuous delivery, there are 4 Db2 levels to consider. There's the maintenance level or ML for short, which is lifted by applying maintenance. It's also known as the code level, and it contains defects and new enhancement fixes. Most of the new functions are ship disabled until the appropriate new function level is activated. There is a catalog level or CL for short, and this is the vehicle to enable new function levels. It's accumulative and skip level is possible. Db2 catalog changes are needed for some function levels, but not all function levels. And our micro CATMAINT is used to upgrade the schema of the catalog and directory. Then is the function level or FL for short. It's needed to be activated for new function. It's accumulative and skip level is possible. It introduces new Db2 features and functionality, and there's no impact or change on existing application behavior because the existing applications are protected by the APPLCOMPAT setting on the package. The APPLCOMPAT level on the package or AC for short is set by the application at bind and rebind time. It provides an island of stability for a given application. It determines the SQL function levels of the applications and it increases the function level of the application and fallback. APPLCOMPAT in Db2 12 applies to DDL and DCL, in addition to the existing DML and XML. APPLCOMPAT must be advanced to exploit any new SQL function. And the APPLCOMPAT level, on the bind and rebind of the package, must be less than or equal to the function level of the data sharing group or stand-alone subsystem. APPLCOMPAT freezes new SQL syntax, even if the function level is later moved back to an earlier level. The minimum starting point for continuous delivery is Db2 12 at function level version 12R1M500. Now let's turn to the next slide. Here on Slide 30, I would like to continue my tutorial on continuous delivery with Db2 12. On this slide, I would like to provide you with an understanding of new function levels. Version 12 is now a single-mode migration. The old modes of conversion mode enable New Function Mode and New Function Mode no longer apply. Function level V12R1M100 is similar to conversion mode or before new function activation and the Db2 engine and the catalog and directory are updated. The supply job DSNTIJTC uses CATMAINT to do all the customization of the Db2 catalog and directory. At this stage, fallback to Db2 11 New Function Mode is possible at any time. Function level V12R1M500 is similar to new function activation or after new function activation. All the new functionality becomes available that was previously blocked because it would have prevented a fallback to Db2 11 New Function Mode. The activate function level command is used to get to function level V12R1M500. At this stage, fallback to Db2 11 New Function Mode is no longer possible. And if you do need to get back to the Db2 11 New Function Mode, that a point-in-time recovery is required. Now let's turn to the next slide. Here on Slide 31, I would like to continue the discussion to help you understand the new function levels. On this slide, I want to go through the various stages of the migration to Db2 12. At step 1, you would set the system parameter, APPLCOMPAT, to V12R1M100. And at this stage, the activated function level of the data sharing group or stand-alone subsystem is V12R1M100. And this would keep all the existing applications running at the current level and with the same behavior as at Db2 11 New Function Mode. At stage 2, you would have been progressively applying new maintenance to Db2 libraries, and the maintenance or code level would rise to V12R1M500 or later. At this stage, the code level would support all the new function, but it exists but it's not activated because you haven't increased the function level of the data sharing group or stand-alone subsystem. At stage 3, a CATMAINT would have been executed to update the catalog level, and the catalog level would now be V12R1M500. And the catalog and directory would have been updated to reflect the Db2 12 schema changes. And at this stage, fallback to Db2 11 New Function Mode is possible at any time. At stage 4, you would use the activate function level command to increase the function level to V12R1M500. At this stage, all the new functions in the base Db2 12 release are available. But at this stage, fallback is no longer possible to Db2 11 New Function Mode. At stage 5, you would find the Db2 Connect driver packages to set the APPLCOMPAT. At this stage, the activated function level of the data sharing group or stand-alone subsystem will be V12R1M500. You would set the system parameter APPLCOMPAT now to V12R1M500. And the applications can now use all the new SQL syntax in Db2 12. Now let's turn to the next slide. Here on Slide 32, I would like to pull all the pieces together by showing you an example of how to get to a new function level. In this scenario, there's a particular application, either a new one or existing one that want to use a new piece of SQL function that's only available with function level 503. To start with, this customer has completed the migration of their data sharing group or stand-alone subsystem to Db2 12 and the maintenance level, the catalog level, the function level and the APPLCOMPAT level are all at 500. Over time, the customer has progressively applied maintenance to their data sharing group or stand-alone subsystem, they may have done this through RSU or PUT levels and now the maintenance level of the data sharing group or the stand-alone subsystem is now at 504. So at this stage, theoretically, they're capable of activating function level 501 or 502, 503 or even 504. Anyway, function level 503 is required for this new or existing application to use that new SQL function. Now before activating function level 503, a new catalog level is required. So the CATMAINT must be run to do a micro update to the Db2 catalog level. And after this, the catalog level will be at 503. The next stage is to use the activate function level command to reach the function level of the data sharing group or the stand-alone subsystem to V12R1M503. Now the new functions are now available, but the existing applications have exactly the same behavior because they're protected by the APPLCOMPAT of 500. The last stage here is for the new or existing applications that want to use that new SQL function, they must be rebound with an APPLCOMPAT of 503 in order to use that new function. Now let's turn to the next slide. Here on Slide 33, I would like to discuss the change in strategy for APPLCOMPAT with the introduction of Db2 12. There is no need to force the rebind of all packages to a new higher APPLCOMPAT level every time you advance the function level of the data sharing group or stand-alone subsystem. APPLCOMPAT will now have many more versions to support many function levels. You will still rebind a package with a higher APPLCOMPAT level in order to exploit any new SQL DML, SQL DDL, SQL DCL and XML functions. Applications can only use this new SQL function if the packages are bound to the necessary and required APPLCOMPAT. And packages can only be bound with an APPLCOMPAT level that is less or equal to the current function level of the daily sharing group or stand-alone subsystem. It is still recommended best practice to regularly rebind all packages with APREUSE(WARN) and plans. Why? To benefit from the latest runtime performance improvement. Without APREUSE, you can gain exposure to new access path selection improvements, you benefit from defect fixes and you reduce your exposure to latent issues that were seeded previously. Now let's turn to the next slide. Here on Slide 34, I would like to discuss developing a strategy for required. And this is an essential requirement for every customer installation. You should use IFCID 376 tracing to identify specific packages, which are potentially exposed to incompatible changes and then investigate and upgrade application programs where necessary. You should not increase the level of the system parameter APPLCOMPAT until such time that all incompatibilities have been identified and addressed. Why is this? You want to avoid breaking existing applications, which have latent compatibility issues that when we do a bind replace, they're picking up the APPLCOMPAT from the default system parameter. You should set the APPLCOMPAT value explicitly on a BIND ADD or BIND REPLACE and manage its value throughout the application development cycle. Any application wanting to use new SQL function will need to be explicitly rebound with that specific application compat after cleaning up any residual incompatibilities. And this includes system packages, such as SPUFI, DSNTEP2 and the Db2 Connect driver packages. Going forward, you will need direction from application providers and package vendors about their application compatibility requirements. Now let's turn to the next slide. Here on Slide 35, I would like to discuss whether APPLCOMPAT is a sticky option or not on bind and rebind operations. Bind replace does not reuse any bind option from an existing package if the option is not explicitly specified on the bind replace operation. This is because the SQL statements can be totally different. So a bind replace is considered a new bind. Rebind and bind copy are the only subcommands that can reuse the existing source packages option, but only if at least one bind or rebind of the package has occurred since the introduction of Db2 11 and the APPLCOMPAT value for the respective package is set in this package in the catalog. This is true for all Db2 releases and not just Db2 12. Now let's turn to the next slide. Here on Slide 36, I would like to discuss setting the current application compatibility special register. Under Db2 11, the value of the register can be greater than or equal to the APPLCOMPAT level of the executing package, but it cannot be greater than the Db2 system parameter APPLCOMPAT. Under Db2 12, the value of the register has to be less than or equal to the APPLCOMPAT level of the executing package, and this is independent of the current function level of the data sharing group or stand-alone subsystem. Why is this? To be able to control application use of new functionality and to avoid breaking applications when activating a lower function level. In other words, you're falling back the function level of the data sharing group or the stand-alone subsystem. Now let's turn to the next slide. Starting here on Slide 37, I would like to provide some recommended best practices for function level adoption. And these recommendations are based on prioritizing maintaining production stability over new function adoption. If you're currently only applying preventative maintenance once or twice per year then this is most definitely not enough for Db2 12 and continuous delivery, and you need to apply drops of preventative maintenance more frequently. And I'm recommending every 3 months using a rolling calendar. As you progressively upgrade the maintenance level of your Db2 systems, either through an RSU level or a PUT level then you're increasing the maintenance level of your Db2 data sharing group or stand-alone subsystem. You should not activate a new function level until the system is proving to be running stable on the current maintenance level. Some of the new function levels require some catalog changes and a CATMAINT is required before activating the new function level. After the execution of the CATMAINT, the subsystem can only be started with a library that has a maintenance level that supports the catalog. Also after activating a new function level, the subsystem can only be started with a library, where the maintenance level supports the function level. New function not related to SQL function is available immediately. The rebinded packages without any APPLCOMPAT would pick up any optimizer enhancements and nonstabilized dynamic SQL will pick up optimizer and other enhancements not related to APPLCOMPAT. Now let's turn to the next slide. Here on Slide 38, I would like to conclude providing recommended best practices for function level adoption. Also the new function level is considered to be running stable, you can allow the applications to start exploiting new feature function. You can rebind the DBA packages to allow new SQL DDL to be utilized. You can rebind the application static SQL packages with a higher APPLCOMPAT level, so they can exploit new SQL functions and behaviors. You can rebind the dynamic SQL packages with a higher APPLCOMPAT to allow the applications to use new SQL function. You can rebind the distributed packages into a separate collection with a higher APPLCOMPAT setting to allow new SQL functions to be used. And you must switch the applications or application servers to use the new distributed package collection. This can be done by setting the collection ID in the data source property for JDBC and in the database configuration file for dotnet and ODBC. You can leverage planned management extended. You can use rebind switch previous to restore the static SQL packages to the prior runtime structures, and you can use rebind switch previous for the dynamic SQL packages to restore the prior APPLCOMPAT. And by switching to a prior collection ID for the distributed applications, you would restore the previous level of APPLCOMPAT. Now let's turn to the next slide. Starting here on Slide 39, I would like to share with you my JC recipe for successful migration. This recipe is predicated on protecting production stability for a conservative customer. You should have a well-defined technical program plan, management and contain the scope. Function level V12R1M100 is similar to conversion mode, except that in version 12, it is a single-mode migration and is a single step to customize the Db2 catalog and directory. You should remember to start all inactive Db2 members of the data sharing group before activating function level V12R1M500. Otherwise, these inactive Db2 members will be orphaned, and they will ultimately have to be deactivated and deleted. Function level V12R1M500 is similar to New Function Mode except in version 12, it's just simply a group-wide command, a system-wide event. You should perform thorough testing. You should run the pre-modulation query jobs early and often, look at the output reports, act on the incompatibilities and also the removed functions. You should perform premigration catalog migration testing, either on a clone or in a DR environment, performing consistency checking of the Db2 11 catalog and directory. Practice the conversion of the bootstrap dataset to the EXTENDED 10-byte extended format using the job DSNJCNVT. Practice DSNTIJTC, which is the CATMAINT. And under Db2 12, rebind the static SQL packages, explain the SQL views and perform some impact analysis on access path changes. You should design for release fallback, mixed release coexistence and test and practice it. You should perform as much application testing as possible to keep fires away from production and migrate to production only when Db2 12 has proven to be running stable in preproduction environments and do not be date driven. Now let's turn to the next slide. Here on Slide 40, I would like to continue discussing the JC recipe for successful migration. You should be aggressive on taking preventative service. You should take as much preventative maintenance as possible on Db2 12 and keep the level of Db2 11 reasonably close. This is important for mixed released coexistence with data sharing and release fallback toleration. And the recommendation is to apply drops of preventative service every 3 months per year with continuous delivery and Db2 12. On a continual basis, you should perform a weekly review of the Enhanced HOLDDATA, looking at new HIPERs and new PEs. You should add the PTF into an existing maintenance package or expedite the PTFs into production after 1 or 2 weeks in test if the new HIPER problem is vicious or where the apply of the PE resolution fix unblocks important missing HIPERs that could not be applied previously. And all of this is especially important when exploiting new functionality. You should try to minimize the number of moving parts and changes in functionality on the initial migration. For example, perform the conversion of the bootstrap dataset to the EXTENDED 10-byte format well ahead of the migration window. You should proactively plan to increase REAL memory and zIIP capacity requirements. You should increase the size of the EDM and RID pools under Db2 11 New Function Mode before leaving Db2 11 New Function Mode for Db2 12. You should rebind deprecated plans and packages with APREUSE(ERROR or WARN) before leading Db2 11 New Function Mode. And you should turn off all new features in Db2 12, which are on by default. Now let's turn to the next slide. Here on Slide 41, I would like to complete my discussion about the JC recipe for successful migration. You should build a performance profile based on key performance indicators under Db2 11 New Function Mode to create a baseline for performance comparison against Db2 12. You should create this profile at a subsystem level using the statistics trace and at the application level by process using the accounting trace. And in terms of application processes, you should concentrate on high-volume transactions, complex transactions at reasonable volume and critical batch processes. You should rebind high-use plans and packages with APREUSE(ERROR or WARN) after migrating to Db2 12 and after proving the stability of Db2 12 in production. You should initially target high-volume transactions and complex transactions at reasonable volume. In terms of benefits, you'll be reenabling fast column processing for migrated packages. You'll avoid the performance overhead of any runtime puffing code under Db2 12 for migrated packages and also plans. You will also accrue the Db2 12 runtime performance improvements, and finally, reduce exposure to any latent issues that were seeded previously in earlier Db2 releases. And then much later, you can gain exposure to the new access path selection improvements in Db2 12. Now let's turn to the next slide. Here on Slide 42, I would like to summarize the objectives of this webcast. I wanted to share lessons learned, surprises and pitfalls, provide some hints and tips based on experience, address some myths that have grown up around Db2 12 migration; provide some additional planning information that can't be found elsewhere, most importantly, provide some usage guidelines and positioning on the new enhancements, but ultimately, what I want to do is to help customers migrate as fast as possible, but to do it safely. Now let's turn to the next slide. Here on Slide 43, I would like to advertise the top social media channels for Db2 for z/OS. You can join the world of Db2; you can follow IBM Db2 on Twitter; you can join the Db2 Z Group on LinkedIn; on YouTube, you can find many videos and webcasts; and you can also follow Db2 Z on Facebook. Now let's turn to the next slide. We have now finished the formal part of this webcast. And temporarily, I'm going to hand control over to the moderator. And then very shortly, we're going to begin the live Q&A. Thank you. Hello, everybody. This is John Campbell here, from Db2 for z/OS Development. Thank you for dialing in for today's webcast. I've got 2 special guests with me today. I've got Ute Kleyensteuber from Commerzbank and Howard Paxton from HSBC. And they've kindly volunteered to come along today for the live Q&A. They will also be with me tomorrow as well. And before I start asking them questions, my questions, and also questions that you've entered, I'd like Ute and Howard, respectively, to introduce themselves. So over to you first, Ute, to introduce yourself.

Yes. Thank you, John. So my name is Ute Kleyensteuber. I'm looking for Commerzbank since many, many, many years. I'm a Senior Product Owner for Db2 and as well for IMS, WebSphere and MQ. I know Db2 since 1.2, so very experienced in Db2 itself, part of lots of early support programs, the last was Db2 12. So we are -- on the use of new functionalities and at last working with Db2. And we are involved in the product since the end of 2017. We are now in function level 504 in production. And yes, I'm happy to answer your questions.

Okay. Over to you, Howard.

Thanks, John. I'm Howard Paxton, work for HSBC. I'd like to think I'm an experienced Db2 Systems Programmer, I've certainly been around for quite a long time. Started out in programming, moved on to work as a DBA initially with IMS and on to Db2. I've been working on the systems programming role for most of this millennium. I've worked in quite a number of sectors over the years, many, many years. From a Db2 V12 perspective, we've been live in our busiest production share in group, our most critical environment since September last year. And I think that will do for now. We look forward to your questions.

Thanks, John. Okay. So we're going to start going through the questions now. The first question I'm going to give to Ute, which is, what are the most important things to do in preparation for migration to Db2 12?

There are several important things. I want to mention, so first at all, it's very important to be at the current available maintenance. The next thing is that there are lots of premigration drops that you should have run, and I can recommend you to do the -- to do and all of the needed follow-ups. The next thing is that in the ZPARM setting, there a lots of new ZPARMs and when you want to be successful, we recommend to switch the new functionality off to run a very quick regression. Then you should have to keep in mind if you have special ZPARM setting, for example, the version 9 behavior for the package authorization, this compatibility, this allows select into union parameters, things like this. And as I mentioned, the new functionalities, you should switch off at the beginning as to disable the Fast Traversal Block, the Index type 2. And you should not increase your APPLCOMPAT. And then, of course, the next thing is to look at the utility suite because for Version 12, you have to have a member in the SYS1 PARMLIB that is IFATRD00, where you should have your utility suite mentioned. And then, of course, it's very helpful to be familiar with the new continuous delivery concept, the function levels and the application compatibilities. One of our very important recommendation we do have is to verify that your internal and external toolings vary. But I think that you might be at the current maintenance with external tooling. So this should also be for Version 12 with the minimum function level 500. The last thing that you should keep in mind is that your EXPLAIN tables and the optimization tables are at the newest format -- at the latest format you have. And that your mapping table with columns increased from about 2 bytes and that you should change the format that you can avoid unnecessary DBL during the REORG. These are the main important things.

Okay. Thank you, Ute. Now a question for you, Howard. What have you been particularly happy with regarding the migrations to Db2 12?

Thank you, John. Yes, from a high level perspective, the quality of the code, based on our approach, we went for, as we have done with previous migrations on Db2 for an evolving entry level through the migration periods, it takes us up to 12 months -- 12 to 18 months in some instances to complete all of the migrations. And we think and it's good practice to -- throughout that migration period that you can't afford to not stay current. So we like to think that we've benefited from that and that we did stay current. We completed a number of maintenance catch-ups building up to the left and most critical production migration. During the migration period, we were keeping a very close eye on the latest 2-year Enhanced HOLDDATA file from IBM to track our HIPER and PTF exposure at the maintenance levels that we had in-flight. Because we'd have some environments that were already live on Db2 12 at a lower level that we subsequently upgraded or uplifted our development environments. So that was quite challenging in managing the maintenance catch-ups in situ with an in-flight migration period. But certainly, even though, there's lots of work to be done, we had a very good experience in terms of, I mentioned in my introduction, that we completed our most critical data sharing group in production migration in September, and even though that weekend is always a stressful weekend for the guys involved, the following week was not stressful. And that was a good indicator of the success of the migration. I always recall speaking to a manager, who no longer works with the bank, and he said something, which I think is quite apt actually with what we do and what I do is that, almost, the asset test for when you guys do a migration and bear in mind, we do an online migration with services active in members concurrent to the member where we drive the migration from, that the best testament we can give to you is, on a Monday morning, people say, did you do it? Did you complete the migration on Sunday? We quite smoothly say, yes, we did. And there are no problems. Isn't that good? Hasn't been totally planned sailing throughout, John, but I've certainly been impressed with the quality of the codes. Lots of efforts in preparing for the migration throughout the migration period. Some stressful times, but a successful result was achieved. John?

Yes. Thanks, Howard. And by the way, I'll send a check in the post for those kind words. Okay? Next question, a subject dear to my heart, and I'd like you both to comment in this and I'll let Ute go first. Ute, is there anything you'd like to emphasize regarding the preparation for the migration? And I know you're bound to talk about the -- both. And this one is actually to Howard. Is there anything you'd like to emphasize regarding the preparation for the migration? Howard, you go first please. Yes, you go first, Howard.

Yes, I think so. Okay. Thank you. Yes, I think, the first point I would make is -- and it should be obvious, but from my experience is, teamwork is key right at the outset in preparing for the migration. Great to have at least 2 people working on the project that is completing the migration, ideally, 3 working collaboratively on the migration. But in terms of expectations, I would suggest that people shouldn't underestimate the amount of work to be completed prior to the migration. For example, the TIJPM queries that are supplied by IBM, in our environment, does identify a fair bit of work to be done. And we structured ourselves such that throughout the periods of the migration we tracked the status for each environment and for each report that was produced by the IBM-supplied queries. As we progressed towards and completed each migration, we did plan to complete ahead of each migration if at all possible and don't leave premigration tests to the night of the migration. If, like in our scenario, we've got a very tight window to complete each migration. You don't want any of that time to be lost on anything that could be done upfront. In terms of challenges, rebinds are always a challenge in that we do not want to have a bad experience due to access path regression or even a less optimal access path. Now what we choose to do, and I don't think it's John's necessarily recommended approach, but we elect to use APREUSE(ERROR) and that's the safest way to rebind the package in that if all of the statements within a package Db2 says, I cannot reuse the same access path for every single statement, I'll fail the rebind. So we got -- get through a large-ish percentage with APREUSE(ERROR) and then were left with the rump of things that need some investigation. And the approach that we take typically is that we bind-copy those into a dummy collection so that we can then analyze and compare with the current live access paths and make decisions based on that. We had 1 or 2 hiccups in some of the environments because it's never a perfect way forward when you are making decisions on access paths. But that's the approach we take. And generally, that stood us in good stead. But it did take quite a lot of resource. So I think that's an important message that if you are able to resolve the premigration steps credibly, involving at least 2 people, then that's definitely the way to go from my experience. Back to you, John.

All right then, Howard. Before I hand over to Ute, I just want to say a few things, piggybacking on the answer that Howard just gave. I mean, Howard mentioned about the DSNTIJPM jobs. And I don't mean to be a comedian here, but it's okay to run the job, but it's really important that people act on the output. And I heard a story, and I don't know if it was true or not, but I was told it was true, that one customer said it was complete, yet they ran the job with TYPRUN=SCAN on the job card. We just meant they validated the JCL. So why do I mention this? Because I'm seeing a lot of customers ignore that the output from the TIJPM query, especially related to plans and packages. And so when you have any pre-Version 10 plans and packages and you -- and their first touch on the Version 12, they will go through auto-binds. And the problem with that is, is that with auto-bind, the way it works, you've got no protection from APREUSE. So if you have a large volume of auto-binds, then some of them may lead to performance problems due to bad access path chains, or let me just say, changes in access path. And then you have to immediately fight those problems. Secondly, lots of auto-bind activity can be quite a lot of disruption in the Version 12 migration window. And some people have even run into authorization problems. So I strongly encourage you to act on these old plans and packages and to explicitly rebind them in your own time, but well ahead of the Version 12 migration. And that way, if you explicitly bind the plans and packages to avoid auto-bind, you'll be able to put the controls in place. So for example, when you bind these old packages, buying them on to Version 11, you can say APREUSE(WARN) plan management extended. And that way, it tries to give you the access paths that you've got. So you've got the protection of APREUSE. And if something ends up behaving badly with worse performance, you can also do a rebind switch to take you back. That's one thing I'd like to draw out about that. The other thing is a bit of an advertisement is that, I may not have the APAR number correct here, but one of the things I'm pleased that we're about to do is deliver an enhancement under Version 12. So the APREUSE(WARN) will always happen on auto-bind. So when auto-binds happened, for whatever reason, then the auto-binds will execute with APREUSE(WARN) and try to give you the access paths you had before. So with that said, I'd like to hand over to, Ute, now, to talk about something that she'd like to emphasize, and of note, Ute would like to emphasize about maintenance strategy for Db2 12 and continuous delivery. Over to you, Ute.

Thank you. So first of all, I can absolutely agree with what John said, that you should not ignore the output. So many, many releases ago, we were not so detailed in running that DSNTIJPM job and doing all the things. But since 2 or 3 versions, I think, we did it because once a year, we had a problem during that migration, that's years ago. But now we definitely run that job, and we definitely make sure that all of the to-dos are long time before we are really migrating. And as I said, John, the planned stability is standard. That's what -- the feature that we are using in production by default. So we have switched it on. And there is another thing besides the maintenance is if you have the chance then you should copy your catalog, run the CATMAINT in another system to make sure that the CATMAINT runs fine, and we don't have any problem. We had no problem with the CATMAINT there. And so, yes, for the maintenance, what we are doing is that we are very current on the maintenance, that we definitely have a look on the PTFs. So there are some PTFs. They have a special code word in it that you find some -- or those PTFs, they are dealing with migration. So there are APARs that have Db2 12 mix/K. There you can find PTFs, you should have run the system. And then, of course, make sure that you have step-by-step activation of the maintenance to make sure that your applications are running fine with the latest maintenance that you want to use for the CATMAINT and then run with the migration.

Okay, Ute. I just want to make -- check that you're finished. So I forgot to mention what the APAR number was for getting APREUSE(WARN) an auto-bind and that APAR number is PI15896, I repeat that PI15896, and that's still open. But just to emphasize, you should try and avoid those auto-binds for the reasons that I said, and I'll just go through it quickly. One, again, is that without the protection of APREUSE and auto-bind, you could get some performance regression that you have to fight in a hurry, disruption to the window, I also think you might -- you could -- you would avoid some authorization problems. And I'll tell you in one customer's case, they actually had a very serious application service outage based on the volume of auto-bind activity, especially around plans. I have a question from Qadir, who said some very kind things about me. So I'll accept those, but then he said, when was I going to retire. But the heart of the question was, would I be around when Version 13 comes out in 2023? Or would it be 2024, '25? All I can Qadir is, right now, we have no plans for a Version 13. And it doesn't mean there won't be a Version 13. It doesn't mean that Version 12 will be the last ever release of Db2. At some point, I can definitely see that there will be a follow-on release. And reasons for that will be usually things like some major architectural change. May be something to do with the terms and conditions, or more likely, we will run out of space in one of the common control blocks, and we'll have to recompile the whole product. And in which case, we don't want to put that out as a -- all those parts in a single PTF. So that may lead to the introduction of Version 13. So based on your initial time scale of 2023, you shouldn't be out there waiting for a Version 13 in 2023. We're no longer on this 3-year cycle. Something may happen in the next 12 months to bring it out. On the other hand, it may be 5 years away from here. So I hope that answers the question. There's a question from Fernando here about suggested best practice for the percentage increase in the size of the EDM and the RID pools under Db2 11 before leaving -- Db2 12 before leaving 11? What I'd like to say there is that a lot of that is already covered in the presentation. So I'm just going to give you a recap on it. In terms of the RID pool because of the fact we're going to use the 10-byte RID values now, just because you might decide to use relative page numbering that could lead to a 60% increase in the RID pool. And I also said that because of changes in the optimizer calculation, then the costing of list prefetch will be cheaper and list prefetch or even multiple index access. Anything that involves this prefetch may become a more attractive access path. So you're talking about at least a 60% increase in the RID pool, and you might decide to do that before you leave 11 for 12. And in the area of the EDM pool, virtually all of the EDM pools are going to increase their consumption in Version 12, but the one that I drew out in the presentation today was about the DBD pool where my recommendation was to increase it by 2x. Another question I have here was about Fast Traverse Block, that in-memory index optimization. And the question that's come in is about am I safe now to turn this on? So I mean, for some people, they may not know to turn it off in the first place. But let me summarize the situation. I mean Fast Traverse Block, from a performance viewpoint, has been very impressive, both during the early support program and in customer migrations, in terms of generating some very generous reduction in GETPAGES and the associated reduction in CPU. However, as more customers migrated to Version 12, especially those that were in data sharing and they migrated to function level 500, we started to uncover some service issues, some of them related to concurrency, some of them related to memory leak and some of them to latch contention. So earlier this year, when we did this already last year, I gave a recommendation about turning off FTPs. So what's happened in the meantime is that we've made a very big quality effort inside Db2 to try and stabilize this item. So what I would say, if anybody wants to turn on FTPs, then what I would say is you need to be super-aggressive about taking the latest preventative service. And I'm certainly going to call out 3 APARs here now, and you can listen to this on the recording afterwards: PH14370; PH16429; and PH13024. So now I'm going to go back to Ute, again, and ask her this question. What are your most favorite new Db2 function level 500 functions?

Okay. So our most favorite function is -- are the greater Db2 logs, because we have a problem that, as you know, you can only have 93 active log paths in your BSDS. And what we want to have is one-day active logging on DASD and in the active log data sets. And therefore, in our production environment, we had to increase this. We could not stay for one day. And so this was the most favorite function. We had a lot of problems at the beginning with this, but it's now safe. All of the problems are solved, and we have increased our active logs to 20 gig each log. So you might ask why we have 20 gig. That's very easy. If we have an issue and opened a case and Db2 Development asked us to upload some Db2 logs, then 20 gig, you can handle. That's the reason why we have limited it to 20 gig. And so now we have increased our active log volume on the SD to 1.8 terabyte. And so the recoveries can benefit, the backout processing can benefit. And of course, if you, yes, if you have some log-based replication, and this might be on delay, then it's very, very helpful to have the active logs on the SD in the active log dataset. So that's the first. Number 2 for us is for the developers. They ask could you enhance much [indiscernible]. As you might know, with [indiscernible], you can mitigate the logging effects and you can allow that the application can commit in between. So in case of problems, the time period you need for the rollout or backout will decrease. And number three, of course, that's the fast analysis log because we know that lots of our applications will benefit from this. And as John said, now we can think when the quality is back that we can switch on this very safely in the production systems. But we have still deactivated it in production, but is activated in the test and development systems and in the pre-lab systems. So that in case of issues, we can provide lots of diagnostics, as we have done in the past. Thanks, John.

There's a question here from Fernando, which I'm going to paraphrase this. It's about falling back from Db2 12 function Level 100 to Db2 11 NFM. Will the packages rebound in Db2 12 function level 100 be frozen, while in falling back to Db2 11 NFM? And he says, how to handle these and remigrate back to Db2 12 function Level 100? So what'll happen here Fernando, if you don't do anything, is that those packages that you rebound or plans that you rebound, both plans and packages that you rebound under Db2 12, if you fallback to Db2 11, they will be invalidated the first time Db2 tries to use that package and old plan. It will be invalidated, and it will go to auto-bind. And the end result will be a Version 11 plan or a Version 11 package. When you remigrate to Db2 12, then those the 11 packages will be able to run under Version 12. It just means that when you remigrate, they will be first 11 versions of the plan and package, and in the case of the packages, you will lose the benefit of fast column processing, for example, and you'll lose the runtime benefits that came with Version 12 and to get the fast column processing routines and the improved run time in Version 12, you need to rebind. You don't have to rebind, but in order to get those performance benefits, you'll need to rebind under 12. But what I would say you should do is that we should be using plan management, which means plan management extended. And therefore, when you rebound those packages under Db2 12, the existing V11 package will become the previous copy. And therefore, if you ever have to fall back to Version 11 New Function Mode, you simply do a rebind switch previous before leaving Db2 12. And that way, when you go back to Db2 11, it will, straight away, be able to use the Version 11 version of the package and avoid the auto-bind activity. So hopefully, that answers that. And someone else has commented here. That was Terry, wasn't it? There's a question here from Fernando about -- I think, it's Fernando, about, is there any suggested or best practice for the period of time to be on each stage during Db2 12. So I think the main recommendation here, there's another one that's going to come after it. But the first one is...