First of all my recommendation is check and follow IBM's site process and second check or attend all the great presentations about this subject. 

But now, said so, I will write down what I would recommend to a colleague still running in Db2 V12. 

Never is too soon to execute the premigation reports. 

1.   Job DSNTIJPM if you have the Db2 V13 software available
2.   Job DSNTIJPE if you only have the Db2 V12 modules

Then you can start cleaning or fixing everything that be need and controlling it by some table and/or GREEN status, e.g:

NOTE - This above table was the based on the one that I used, but there's one more report, the number 22. It was introduced with APAR PH62379: "Expression-based indexes which could require implicit regeneration on first INSERT/UPDATE/DELETE execution in V13"  (Nov. 2024)

Check the compatibility of all the tools related to Db2 at your shop

Go to the vendor sites and check or ask their support team about the Db2 V13 compability. If not it can be the case that you have to rollback just because any of your versions is not compatible:

                Admin Tool, Query Monitor, Mainview, Sysview, BMC or CA Db2 tools, QMF, your Replication Tool ... everything!

Check the aliases

If it is the first time you are jumping from one Db2 Version to other, check all the possible aliases, don't miss any. 

I am spotting this because a module from another Function Level could work, but a module from version 12 will not work at version 13. 

When I am not sure I allways execute this LISTCAT command for all my current or old LOAD libraries:

listcat all entries ('DB2.V12.RSU2401.SDSNLOAD')

Among other things, it reports the aliases that are related to my SDSNLOAD

ASSOCIATIONS                        
  ALIAS----DB2.TEST.SDSNLOAD        
  ALIAS----DB2.PROD.SDSNLOAD              
  ALIAS----DB2.ALIASNOT.CONTROLD.SDSNLOAD     

If there is no alias related, it just report:

ASSOCIATIONS--------(NULL) 

Give a try to the new batch way for generating the tailored jobs for migrating

I really liked this new option, with job DSNTIJBC you can generate them instead of going thru the usual Db2 Installation CLIST. 

Once you have it set you execute it in batch, and you can save the source and the output for next time, instead of picking screenshot by screenshot all the CLIST screens. Who does not have some folder with tens of PNG archives) DSNTIPA, DSNTIP0, DSNTIPK ... ? 😁

If you have a Sandbox, make use of it

Ok, for some reason you cannot go with the change yet, but ... if you have the software and you have a Sandbox for making tests, start with it as soon as possible.

That way you will realise that is a pretty simple move, there is no Catalog change, so no Catalog Reorg during the CATMAINT.

Do not forget to prepare and test the Fallback

You can verify by yourself that in case of trouble, going back to Db2 V12 is really simple.

Basically you stop the Db2, run the aliases to point back to V12, start Db2 and probably you will have to fix some packages that during the process or the testing where bind or autobind. For example, something like this

DSNT500I  :D2E2 DSNTBAB2 RESOURCE UNAVAILABLE  785

           REASON 00E30305                        

           TYPE 00000804                          

           NAME "ADBL"."ADBCMRQ".("V13.1.0.0000000"

No more, with this you would be back to Db2 V12.

And remember that you can make it and that you are not alone. You have this community to solve your doubts, just ask!

#Db2forz/OS #Db2forz/OS