Db2 for z/OS 11 - SNA to TCP/IP for DDF

Andy Smith

Db2 for z/OS 11 - SNA to TCP/IP for DDF

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…..

 

1)

We expected to see up to 60% of the CPU burnt on the “remote” (server) side offloaded to zIIP.  We are seeing this.

 

2)

We expected to see SNA (the NET STC) reduce its CPU utilization and the TCPIP STC increase its CPU utilization.  We are seeing this.

 

3)

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.

Thanks
Andy

Peter Conlin

Db2 for z/OS 11 - SNA to TCP/IP for DDF
(in response to Andy Smith)
Is it possible that cpu now charged to ssnDIST was previously charged back to the user (possibly via SECACPT=ALREADYV in the VTAM appl?)

I suspect the VTAM/DDF chargeback (now in ssnDIST?) could only have been charged to the Db2 client when on the same LPAR as the Db2 server (so the SMF type 30s, etc would add up properly.)

From: Andy Smith [mailto:[login to unmask email]
Sent: Thursday, October 19, 2017 1:20 PM
To: [login to unmask email]
Subject: [DB2-L] - Db2 for z/OS 11 - SNA to TCP/IP for DDF


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…..

<cut…/cut>

3)

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.

Thanks
Andy

-----End Original Message-----

Peter Conlin

RE: Db2 for z/OS 11 - SNA to TCP/IP for DDF
(in response to Andy Smith)

Is it possible that cpu now charged to ssnDIST was previously charged back to the user (possibly via SECACPT=ALREADYV in the VTAM appl?)  

I suspect any old VTAM/DDF chargeback (now in ssnDIST?) could only have been charged to the Db2 client when on the same LPAR as the Db2 server (so the SMF type 30s, etc would add up properly.) 

pete conlin

Andy Smith

RE: Db2 for z/OS 11 - SNA to TCP/IP for DDF
(in response to Peter Conlin)

Peter, thanks for this suggestion, I'll look into it and report back next week....

Andy Smith

RE: Db2 for z/OS 11 - SNA to TCP/IP for DDF
(in response to Andy Smith)

Peter, the CPU increase in the local/client Db2 DIST address space was simply down to PassTicket generation in CA Top Secret for every outbound call.  This increase is significantly less than the benefit we are seeing from zIIP offload on the remote/server side though, so we are just tolerating this as a small price to pay for the security aspect of using this configuration.  Overall, the benefits are huge.