Updating Db2 or z/OS

Edit online

Db2 and z/OS can be updated by applying software maintenance, or upgrading to a newer release of the software. The topic provides information on how to upgrade Db2 and z/OS without system interrupts.

SMP/E is the system tool that is used to apply, upgrade, track, and manage software for all z/OS products, including Db2 and z/OS.

At a high level, SMP/E builds target executable libraries (loadlibs) while the software is running from different executable libraries. To activate the latest changes, the software (z/OS or Db2) must be stopped and restarted by using the updated loadlibs. For more details about how to apply software maintenance that uses SMP/E, refer to the SMP/E User's Guide for the release of z/OS you are running.

Both Db2 and z/OS support downward compatibility. This means you can run multiple software releases in a Parallel Sysplex® data sharing environment. z/OS normally supports N-2 releases. This means that up to three consecutive releases can run in the same Parallel Sysplex.

Db2 allows you to non-disruptively upgrade to a higher release. For example, Db2 12 for z/OS with function level (FL) V12R1M510 could run in parallel with Db2 13 with FL V13R1M100 in the same data sharing group as long as the new function (V13R1M500) of Db2 13 is not activated. By iteratively moving all Db2 members of the data sharing group to Db2 13, and staying at function level V13R1M100, the SAP application can remain online all the time. When all of the Db2 members of the data sharing group have been moved, you can execute the -ACTIVATE FUNCTION LEVEL command for V13R1M500. All of these activities can be run without stopping SAP.

If both z/OS and Db2 need to be upgraded, the preferred sequence is to upgrade z/OS first, followed by Db2.

When z/OS Parallel Sysplex and Db2 data sharing are both being used, individual z/OS LPARs and Db2 data sharing members can be started and stopped without stopping the SAP system. This is accomplished by taking advantage of Db2 connection failover, see Db2 connection failover. Complete the following steps for each LPAR in the sysplex to be updated:

  1. Build new Db2 loadlibs with the Db2 maintenance that is applied for each Db2 data sharing member. A suggested name would be: 
    <db2_member_name>.SDSNLOAD.NEW
  2. Stop SAP batch processing. Make sure that all SAP batch processing on application servers that are connected to Db2 in this LPAR has stopped and no new batch workload gets scheduled. You can use SAP transaction RZ03 to switch these application servers to a previously defined operation mode that does not comprise any SAP batch work processes. Such an operation mode prevents new batch work from getting scheduled on these application servers.
  3. Ensure that the SAP Collector (SAPCL) alert router is stopped for the Db2 member. You can check SAPCL alert router in the SAP application with transaction DBACOCKPIT -> Configuration -> SAP Collector Settings -> Check Status. The SAPCL alert router can be stopped on the same panel.
  4. In case of Db2 maintenance and the sapdbctrl-component of the SAP Host Agent in z/OS Unix is active, then ensure that the Host Agent is not using the Db2 load library of the Db2 member, which will be maintained. If the maintained Db2 load library is used by the SAP Host Agent, then stop the Agent in NetView and stop the resources of SA group SAPHOST_AGT.

    For details on SAP Host Agent and the sapdbctrl-component, see The Solution Manager Diagnostics Agent (SMDA).

  5. Initiate Db2 connection failover

    For ABAP and Java connections, use the graceful stop of the DDF address space STOP DDF MODE(QUIESCE) or if DDF location alias is used then stop the alias with MODIFY DDF ALIAS(<alias-name>) STOP in order to move any database connections away from the Db2 data sharing member that is going to be updated.

  6. Ensure that there are no active connections to this member and stop the Db2 member in SA z/OS. The Db2 administrator may require to start and stop the Db2 member in maintenance mode without the intervention of System Automation. In such situations, suspend the Db2 member from automation. Then, automation does not react on any Db2 messages, and does not trigger predefined commands from the policy for this message, neither a Db2 stop or start nor a Db2 light restart on another LPAR.
  7. Switch from current Db2 loadlibs to new Db2 loadlibs. This can, for example, be accomplished by renaming the Db2 load libraries.
  8. Stop and re-IPL z/OS to activate z/OS updates. At this point, z/OS can be stopped and re-IPLed to activate z/OS updates. Other services that were running on this LPAR, such as the NFS server, SAP Web Dispatcher, SAP Router, SAP Central Services, should be restarted automatically on one of the other active LPARs by System Automation. This assumes that your automation policy works correctly and has been verified (see Verifying your implementation on z/OS).
  9. Start the Db2 data sharing members in the LPAR in SA z/OS. If the Db2 member is suspended, cancel its suspend vote.
  10. Switch back ABAP application servers to the previous configuration by using SAP transaction DBACOCKPIT.
    • Method 1: Database connections of both ABAP or Java™ instances automatically switch back to the restarted Db2 member, if affinityFailbackInterval parameter was set in the connection profile.
    • Method 2: Switch back ABAP application servers using SAP transaction DBACOCKPIT, SAP report RSDB2SWITCH or the RFC utility rfcmove.
  11. Verify the switched back threads to the restarted Db2 member.
  12. If SAPCL alert router was stopped before Db2 member maintenance, ensure that it is active again.
  13. Restart all SAP batch processing on application servers that are connected to Db2 in this LPAR. Use Opt Mode Switch to add batch work processes.