We've recently switched our Db2/z to Db2/z DDF comms from using SNA to TCP/IP.
Our Mainframe Security product of choice is CA Top Secret and we are using PassTickets for the authentication (SECURITY_OUT='R' in SYSIBM.IPNAMES).
We have seen two expected outcomes, but also one unexpected outcome, for which I kindly ask for any ideas/suggestions from this forum, to try and identify the root cause…..
We expected to see up to 60% of the CPU burnt on the “remote” (server) side offloaded to zIIP. We are seeing this.
We expected to see SNA (the NET STC) reduce its CPU utilization and the TCPIP STC increase its CPU utilization. We are seeing this.
We expected to see a CPU reduction for the “local” (client) Db2 distributed address space, because I understand that as of DB2 9 for z/OS, SNA (31-bit) processing incurs an overhead due to the Db2 DIST address space going to 64-bit addressing.
However, we have actually observed a CPU increase in the local/client Db2 DIST address space. The increase is not directly proportional to any increase in workload - e.g. if we have seen workload/throughput increase by a factor of 1.8 (due to more CPU resource available now that the zIIP has come into play) the CPU increase of the local/client DIST address space has been much higher than this, e.g x4
I’d really like to try and understand why this has happened and whether or not there are any opportunities for us to tune this out. I've asked my CA Top Secret security colleague and Mainframe Network colleague to see if they can think of any monitoring or tracing that they can do at their ends, but I'm out of ideas on what else I can look for in Db2 land.