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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
