This is the third time I have written this post. It keeps changing, so I keep sharing.
I work from home, so downloading software to my laptop and then uploading it to a server is not very efficient. Download speeds aren’t bad, but uploading can take 8 hours or more, depending on the client. This forces me, whenever possible, to move code directly to the server. The first time I wrote about this, it was little more than a wrapper around a tech note. The second time, I went into greater detail about a slightly different method. IBM has actually made it quite easy now.
You first have to know the Operating System and Fix Pack number you need. A full Db2 install is now possible from any fix pack code, so this goes for brand new installs, too. Though you will still have to get your license file from Passport Advantage, as the fix packs only come with a try-and-buy license. The easiest way to get to the code you need is by starting at the Fixes by Version page. This page presents a nice list of all available Db2 fix packs:
Once you’ve selected the fix pack number you want there, you’ll need to select the plus sign next to the operating system. Under the operating system, you have several options.
If you don’t know what to pick, select “DB2 Universal Fix Pack”.
Once you have made that selection a separate tab or window will open up for the right fix pack in Fix Central. You will be required to log in with your IBM ID. If you don’t already have one, IBM IDs are free, and you don’t have to have any association whatsoever in order to download a fix pack for free.
The Fix Central screen should have only one package available. Check the box next to it, and click Continue at the bottom: 
There is then a screen where you may have to wait for a bit:
Once it is done loading, you have a screen that gives you the details of how to login via FTPS to get your fix pack:
The three pieces of information you need there are in the red boxes. Once you have this, you just use those to get the fix pack from a UNIX/Linux command line:
$ ftp -s delivery04.dhe.ibm.com
Connected to server.boulder.ibm.com.
220 ProFTPD 1.3.5b Server (proftpd) []
234 AUTH TLS successful
TLS Auth Entered.
TLS handshake succeeded, though Server signed it's own cert!
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
30:ee:0e:4d:47:3f:76:4d:dc:bc:6a:07:4d:8e:a1:72
Issuer: C=US, O=GeoTrust Inc., CN=GeoTrust SSL CA - G3
Validity
Not Before: Jan 5 00:00:00 2017 GMT
Not After : Mar 6 23:59:59 2018 GMT
Subject: C=US, ST=New York, L=Armonk, O=INTERNATIONAL BUSINESS MACHINES CORPORATION, CN=*.dhe.ibm.com
TLSv1/SSLv3 ( AES256-SHA ), 256 bits
Name (delivery04.dhe.ibm.com:vdba): asdfghkLer
331 Password required for asdfghkLer
Password:
230 User asdfghkLer logged in
200 PBSZ 0 successful
200 Protection set to Private
ftp> passive
Passive mode on.
ftp> binary
200 Type set to I
ftp> prompt
Interactive mode off.
ftp> mget *
TLSv1/SSLv3 ( AES256-SHA ), 256 bits
227 Entering Passive Mode (170,225,15,105,254,132).
150 Opening BINARY mode data connection for v10.5fp2_aix64_universal_fixpack.tar.gz (1913464208 bytes)
TLSv1/SSLv3 ( AES256-SHA ), 256 bits
226 Transfer complete
1913464208 bytes received in 869.7 seconds (2149 Kbytes/s)
local: v10.5fp2_aix64_universal_fixpack.tar.gz remote: v10.5fp2_aix64_universal_fixpack.tar.gz
ftp> bye
221 Goodbye.
Note that the above is slightly sanitized output from downloading a different fix pack than the one I showed in the screen shots from fix central. I did not share the real userid and pw from my code download, as that doesn’t seem quite right to me.
Hi Ember, I just noticed the FTPS option yesterday while downloading a CDC fixpack, but I never tried it before. I think I will next time – thanks!
Is there a real use case for this ? Not likely any Db2 server can download directly from the internet , definitely not ftp/ftps ?
Moreover, even then: Download binaries only ONCE, from any supplier, to internal distribution vault. Then quality control and testing (distribute that one image to test / development / acceptance / production)
I have seen IBM publishing the exact same fixpack (name on website and zip/tar filename after downloading) that was NOT the same build … One reason I never download a fixpack the first week(s) after it is published …
Many Db2 servers do actually allow downloads directly from the internet. Even if it’s not to the Db2 server, though, this method can be useful for getting the fix pack to a jump server or other server that is on the same network as the Db2 server. Agreed that an internal location for code is a better solution. And a good point on not downloading a fix pack the first week. I, too, always wait a week after a fix pack before starting to use it.
Ember,
Thanks for the info. For years I’ve always downloaded fixpacks using wget (as per your older post) and this has always worked flawlessly for me. I find that HTTP(S) tends to be more often available in corporate sites than FTP(S). You just have to use the URL you capture within a reasonable timeframe (it expires fairly quickly).
Just one more comment. I’d always take the Server, rather than Universal, Fixpack. This is because the Server Fixpack is a full install image (apart from the license key) and can be used to lay down a fresh installation of Db2. I always lay down the new fixpack beside the original install and then use db2iupdt to switch the instance over to the new code level. You can also use db2iupdt with the “-f ” option (or the deprecated “-D” option) to move back down again if you find any issues. Only when I know I’m not wanting to fall back do I then remove the old code install. I find separating out the code install from the instance migration in this way takes a lot of pressure off during fixpack applications. You just have to remember to reapply the license key after the upgrade.
Good point. I’m a fan of side-by-side installs as well.
I agree with Phil: I also always take the “Server”, not the “Universal” Fixpack (and usually also ‘lay down the new fixpack beside the original install’, as fallback if there are issues)