DB2 z/OS - enabling NFM

Mike Martin

DB2 z/OS - enabling NFM
Hi all,

We have been running V11 CM for several months now. (Our migration from V10 went smoothly)

We are now preparing for NFM. I have a few questions...


* Is there any danger of existing application code having problems when we go to NFM? We will not be taking advantage of new V11 features, just continuing to run what had been running in V10 and is now successfully running in V11 CM.


* Is there any reason to run in ENFM for a while before going to NFM?


* If we have to fallback to CM* is this the same as CM (as far as the applications are concerned) ? I understand we cannot fallback to V10 from CM*.


* Any need to restart our DB2 subsystems for any of this? (say like after running job DSNTIJNG which reassembles/links a module?)

Any other tips/gotchas are greatly appreciated. We are z/OS V11 CM without data sharing.

Mike Martin

This email may contain confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please contact the sender and delete all copies. Any review or distribution by others is strictly prohibited. Personal emails are restricted by policy of the State Employees' Credit Union (SECU). Therefore SECU specifically disclaims any responsibility or liability for any personal information or opinions of the author expressed in this email.

Philip Sevetson

DB2 z/OS - enabling NFM
(in response to Mike Martin)
Mike,

I'm in a non-data-sharing shop which went to V11CM about four months ago. We had a couple of problems, but nothing specifically attributable to NFM. If you use Websphere or any similar external-connect products, you should already have run into most of this.

1) Particularly, check the Java JDBC module class and level to make sure that you're running Type 4 calls to DB2. Type 3 are deprecated and most are obsolete-incompatible. Also,

2) If you have date-partitioned tables for which you SELECT LIMITKEY FROM SYSIBM.SYSTABLEPART, be aware that after any ALTER to the LIMITKEY, or any creation of new date-partitioned tables or new partitions for existing tables... the new LIMITKEY values for these dates will have delimiting apostrophes (single quotes), but unaltered partitions will still have un-delimited date values. The STRIP() function helps re-standardize the data.

We didn't spend more than the minimum time in ENFM and encountered no problems; and we did a -STOP DB2 and a -START DB2 when going to NFM. Again, no problems. Hope this helps.

--Phil Sevetson

From: MARTIN, MIKE [mailto:[login to unmask email]
Sent: Tuesday, January 16, 2018 3:46 PM
To: [login to unmask email]
Subject: [DB2-L] - DB2 z/OS - enabling NFM

Hi all,

We have been running V11 CM for several months now. (Our migration from V10 went smoothly)

We are now preparing for NFM. I have a few questions...


* Is there any danger of existing application code having problems when we go to NFM? We will not be taking advantage of new V11 features, just continuing to run what had been running in V10 and is now successfully running in V11 CM.


* Is there any reason to run in ENFM for a while before going to NFM?


* If we have to fallback to CM* is this the same as CM (as far as the applications are concerned) ? I understand we cannot fallback to V10 from CM*.


* Any need to restart our DB2 subsystems for any of this? (say like after running job DSNTIJNG which reassembles/links a module?)

Any other tips/gotchas are greatly appreciated. We are z/OS V11 CM without data sharing.

Mike Martin
This email may contain confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please contact the sender and delete all copies. Any review or distribution by others is strictly prohibited. Personal emails are restricted by policy of the State Employees' Credit Union (SECU). Therefore SECU specifically disclaims any responsibility or liability for any personal information or opinions of the author expressed in this email.

-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**

Javier Estrada Benavides

RE: DB2 z/OS - enabling NFM
(in response to Philip Sevetson)

Hello:

  You'll do fine, just follow the standard recommendations:

- Save critical accesspaths

- Save a list of critical packages and after activating NFM see if they will be auto rebound or you can just do it yourself

- A restart will be required if you convert to the new 10 byte RBA, which is recommended because we know you'll do eventually do it anyway

- If in the future you want to use archive tables be sure to use applcompat with v11 and also rebind the jdbc nullid packages with the same parameter

Hope that helps

 

Regards,

Javier Estrada Benavides, Mexico

IBM Certified System Administrator - DB2 11 for z/OS

IBM Certified Database Administrator - DB2 11 DBA for z/OS

IBM Champion 2018

Mike Martin

DB2 z/OS - enabling NFM
(in response to Mike Martin)
Thanks Phil and Javier. The items you mentioned are very helpful.

I have a couple more questions for everyone…

Is it possible to migrate from CM to NFM without stopping/starting DB2? (for instance, it seems like job DSNTIJNG might require a restart to pickup the NEWFUN=V11 change)

Also, we rebound all our application packages when we went from V10 to V11 CM. Is it advisable to rebind again – going from CM to NFM?

Mike Martin





This email may contain confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please contact the sender and delete all copies. Any review or distribution by others is strictly prohibited. Personal emails are restricted by policy of the State Employees' Credit Union (SECU). Therefore SECU specifically disclaims any responsibility or liability for any personal information or opinions of the author expressed in this email.

Michael Hannan

RE: DB2 z/OS - enabling NFM
(in response to Mike Martin)

Mike,

REBIND depends on your reasons to REBIND. One reason is very old packages not at optimum performance. Some sites may REBIND with APREUSE to get new runtime structures without change to access paths as far as possible, if not ready to take on new access paths (which are largely available in CM). If REBIND everything in CM to take new access paths, then a REBIND again in NFM is not normal at average sites. Any package that wants to use a new functionality will obviously have to get a REBIND after the change to use the new function if it is related to SQL features or capabilities. Some PTFs may require a REBIND but that should be localised.  

Some sites may REBIND everything after change of subsystem parameter APPLCOMPAT. However I don't understand the logic and benefit behind that, despite reading the IBM manuals on the topic. No observable benefits I would expect, if Packages are already rebound since CM. If someone can point out a major concrete benefit, well great. Possibly just extra tidiness. 

System Packages not related to your applications may benefit from REBINDs for any static SQL access paths.

If Rebinding to benefit from better access paths during CM, it maybe firstly worthwhile to only REBIND those packages above some threshold cost level (from SMF data), to limit access path changes needing to be checked.

Years ago used to be dangerous to REBIND everything too often (in case of access path degrade), however with APREUSE to prevent access path change, it becomes somewhat safer (but not completely). In Db2  z 10, after REBIND there were some rare packages degrading badly despite same access path, due to changes in MX/MI functioning (which should be fixed by Db2 12 adaptive MX/MI). If degradation ever happens noticeably happens, roll it back using REBIND SWITCH, providing Plan Mgt retained duplicates.  
 
In Reply to Mike Martin:

Also, we rebound all our application packages when we went from V10 to V11 CM. Is it advisable to rebind again – going from CM to NFM?

Mike Martin

 

Michael Hannan,
DB2 Application Performance Specialist
CPT Global Ltd

Edited By:
Michael Hannan[Organization Members] @ Jan 25, 2018 - 07:48 AM (Europe/Berlin)