Pertaining to DB2 v11+ fixpacks....

Chris Bielinski

Pertaining to DB2 v11+ fixpacks....

it seems that the version number and the fixpack_num values aren't incrementing like they have in the past.  Any reason why?

Unix:

Mod1 FP1: 11.1.1.1, fixpack_num: 1

Mod1 FP1 iFix001: 11.1.1.1, fixpack_num: 1

Mod2 FP2: 11.1.2.2, fixpack_num: 2

Mod2 FP2 iFix001: 11.1.2.2, fixpack_num: 2

Mod2 FP2 iFix002: 11.1.2.2, fixpack_num: 2

 

Although, I do see that DB2 installed on Windows does give a slightly different version number, and the fixpack_num seem to increment, but I don't have access to extensively upgrade and observe on the Windows side.

 

Does anyone know why this is?

Ian Bjorhovde

Pertaining to DB2 v11+ fixpacks....
(in response to Chris Bielinski)
The new versioning scheme is explained in this doc:  http://www-01.ibm.com/support/docview.wss?uid=swg27008656

iFixes (Interim Fixes) have always existed, but in the past they were assigned letters.  (For example:  DB2 9.7 Fixpack 9a).

If you translate the new version numbers into what we’ve seen before, you’d get:

11.1 Fixpack 1
11.1 Fixpack 1a
11.1 Fixpack 2
11.1 Fixpack 2a
11.1 Fixpack 2b



Ian Bjorhovde




On Jan 29, 2018, 1:26 PM -0700, Chris Bielinski <[login to unmask email]>, wrote:
> it seems that the version number and the fixpack_num values aren't incrementing like they have in the past.  Any reason why?
> Unix:
> Mod1 FP1: 11.1.1.1, fixpack_num: 1
> Mod1 FP1 iFix001: 11.1.1.1, fixpack_num: 1
> Mod2 FP2: 11.1.2.2, fixpack_num: 2
> Mod2 FP2 iFix001: 11.1.2.2, fixpack_num: 2
> Mod2 FP2 iFix002: 11.1.2.2, fixpack_num: 2
>
> Although, I do see that DB2 installed on Windows does give a slightly different version number, and the fixpack_num seem to increment, but I don't have access to extensively upgrade and observe on the Windows side.
>
> Does anyone know why this is?
>
> Site Links: View post online   View mailing list online   Start new thread via email   Unsubscribe from this mailing list   Manage your subscription
>
> This email has been sent to: [login to unmask email]
> Setup a data refresh task in less time than it takes to make a cup of coffee + save up to 90% in CPU
> ESAi's BCV5 & XDM fast data refresh & Test Data Mgmt products will make you a hero to users. See
> http://www.ESAIGroup.com/idug
>
> Use of this email content is governed by the terms of service at:
> http://www.idug.org/p/cm/ld/fid=2

Chris Bielinski

RE: Pertaining to DB2 v11+ fixpacks....
(in response to Ian Bjorhovde)



In Reply to Ian Bjorhovde:

The new versioning scheme is explained in this doc:  http://www-01.ibm.com/support/docview.wss?uid=swg27008656

iFixes (Interim Fixes) have always existed, but in the past they were assigned letters.  (For example:  DB2 9.7 Fixpack 9a).

If you translate the new version numbers into what we’ve seen before, you’d get:

11.1 Fixpack 1
11.1 Fixpack 1a
11.1 Fixpack 2
11.1 Fixpack 2a
11.1 Fixpack 2b



Ian Bjorhovde




On Jan 29, 2018, 1:26 PM -0700, Chris Bielinski <[login to unmask email]>, wrote:
> it seems that the version number and the fixpack_num values aren't incrementing like they have in the past.  Any reason why?
> Unix:
> Mod1 FP1: 11.1.1.1, fixpack_num: 1
> Mod1 FP1 iFix001: 11.1.1.1, fixpack_num: 1
> Mod2 FP2: 11.1.2.2, fixpack_num: 2
> Mod2 FP2 iFix001: 11.1.2.2, fixpack_num: 2
> Mod2 FP2 iFix002: 11.1.2.2, fixpack_num: 2
>
> Although, I do see that DB2 installed on Windows does give a slightly different version number, and the fixpack_num seem to increment, but I don't have access to extensively upgrade and observe on the Windows side.
>
> Does anyone know why this is?
>
> Site Links: View post online   View mailing list online   Start new thread via email   Unsubscribe from this mailing list   Manage your subscription
>
> This email has been sent to: [login to unmask email]
> Setup a data refresh task in less time than it takes to make a cup of coffee + save up to 90% in CPU
> ESAi's BCV5 & XDM fast data refresh & Test Data Mgmt products will make you a hero to users. See
> http://www.ESAIGroup.com/idug
>
> Use of this email content is governed by the terms of service at:
> http://www.idug.org/p/cm/ld/fid=2

Thanks for the reply and for the document. So knowing this, and taking into consideration the information in the table(sysproc.env_get_inst_info()), the only way you can compare fixpacks via logic and SQL would be the buildlevel?  I guess I don't know why the fixpack_num wouldn't be incrementing.

Ian Bjorhovde

Pertaining to DB2 v11+ fixpacks....
(in response to Chris Bielinski)
Chris,

I don’t speak for IBM (maybe Roger Sanders or Jessica Rockwood want to chime in), but I wouldn’t consider the Interim Fixes to be Fixpacks.  The number of fixes in each iFix is very small in comparison to what you see in a normal Fixpack;  if you look at the release notes for the iFixes, you’ll see that they generally only include security and high priority (HIPER) APARs.

In the past, I only recall ever seeing Interim Fixpacks if there was something seriously broken in a Fixpack;  these usually came out relatively quickly after a fixpack was released.

With V11 it appears that the release planning has changed, and so it seems like iFixes are being released to get HIPER / Security APARs fixed sooner (as opposed to forcing customers to wait for the next Fixpack).


Ian Bjorhovde


On Jan 29, 2018, 2:16 PM -0700, Chris Bielinski <[login to unmask email]>, wrote:
> Thanks for the reply and for the document. So knowing this, and taking into consideration the information in the table(sysproc.env_get_inst_info()), the only way you can compare fixpacks via logic and SQL would be the buildlevel?  I guess I don't know why the fixpack_num wouldn't be incrementing.

Chris Bielinski

RE: Pertaining to DB2 v11+ fixpacks....
(in response to Ian Bjorhovde)

Thanks for the replies Ian. 

 

Its funny you mention how the iFixes contain security fixes, because that is what I am working on at the moment. Auditing security fixes, contained within the fix packs, and comparing the version levels of our existing database servers to what IBM has released. Up until v11, we have gotten by with comparing the combination of version level and fixpack_num, but now that the fixpack_num isn’t incrementing we need to come up with another way.