A wireshark trace with a tcpip z/os packet trace will show you end to end...also look at error counts on the routers and switches, make sure packets are being dropped...
Scott ford www.identityforge.com On Aug 23, 2012, at 2:41 PM, Scott Ford <[email protected]> wrote: > Did you run a packet trace, to see where the delay is ? That would be the > first thing ...in my mind..it's not always a case of reviewing definitions... > > Scott ford > www.identityforge.com > > On Aug 23, 2012, at 2:03 PM, "Gibney, Dave" <[email protected]> wrote: > >> I suggest you ask this on IBMTCP-L. You will find more help there. >> Specifically, Chris Mason :) >> >> Dave Gibney >> Information Technology Services >> Washington State University >> >> >>> -----Original Message----- >>> From: IBM Mainframe Discussion List [mailto:[email protected]] >>> On Behalf Of Mauri Kanter >>> Sent: Thursday, August 23, 2012 3:16 AM >>> To: [email protected] >>> Subject: "Delay" Problem with SSL and DVIPA >>> >>> Good morning list, >>> >>> We are facing a strange "delay" problem with TN3270 and SSL which I >>> describe below. >>> >>> The configuration is as follows: >>> PRD1 and PRD2 are production LPARs. >>> DEV1 and DEV2 are development LPARs >>> PRD1 and DEV1 are on a z114 machine with two OSA cards shared among the >>> LPARs >>> PRD2 and DEV2 are on another z114 machine also with two OSA cards shared >>> among the LPARs. >>> Neither the machines nor the OSA cards are exactly equal but they are very >>> similar in many aspects (mips, workload, etc) >>> >>> No network problems from the performance point of view… >>> >>> Ping times from my desktop are very good for all the IP addresses described >>> below. And Normal work is ok. Everybody is happy. >>> >>> Below the several IP addresses involved: >>> Each OSA card has an IP address. >>> Each LPAR has a local VIPA for that LPAR. >>> Each subplex has a dynamic DVIPA. >>> DEV1 has VIPADEF defined on the VIPADynamic statement >>> DEV2 has VIPABackup defined on the VIPADynamic statement >>> PRD1 has VIPABackup defined on the VIPADynamic statement >>> PRD2 has VIPADEF defined on the VIPADynamic statement >>> >>> For example: VIPADEF MOVE IMMED SERVICEMGR 255.255.255.240 >>> xxx.xxx.xxx.xxx >>> >>> We use SSL to connect to TN2370. >>> >>> There is no VIPADIST DEFINE statement neither for the TN3270 SSL port nor >>> the non-SSL port . >>> When connecting via SSL to the TN3270 server of DEV1 using the DVIPA of the >>> development subplex performance is very good. >>> When connecting via SSL to the TN3270 servers of all the lpar VIPAs the >>> performance is very good for all 4 LPARs. >>> >>> In particular, when pointing PCOMM to the lpar VIPA belonging to PRD2 the >>> USSTAB shows up immediately in almost "no time" >>> >>> However … When pointing PCOMM to the DVIPA belonging to the production >>> subplex it may take 5 seconds to get the USSTAB. According to our >>> definitions, >>> the LU name I get, and what I see from NETSTAT HOME, I see that the DVIPA >>> is held by PRD2. >>> >>> To make things more confusing, if I use the non-SSL port of the TN3270 the >>> "delay" disappears. >>> >>> So I do not understand if the problem is SSL, the network, or the >>> distributor. >>> I'm missing something here … >>> >>> Any ideas what to look for? The problem was reported to me lately and also >>> lately we migrated to z/OS 1.13 from 1.11, but I can not confirm for granted >>> that z/OS 1.13 is related to the problem. >>> >>> Thanks in advance for your help. >>> >>> Mauri. >>> >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to [email protected] with the message: INFO IBM-MAIN >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
