As with anything new you always want to get the latest maintenance
(Vswitch, DB2 and TCP/IP for VSE). That said, I've had no problem with
the VSwitch on z/VM 5.1 with reasonably current maintenance.
I have a customer running a similar configuration (with the assembler
sockets code), but they are using Hipersockets between LPARs. That is
definitely the way to go.
Tom Duerbusch wrote:
I have z/VM 5.1 RSU 0501 running.
On the 390 side, I have a bunch of VSE systems running, the current
ones are connected to a VSWITCH. The VSWITCH is connected to an OSA
adapter.
On the IFL side, I have a bunch of Linux systems running. All of them
are connected to a VSWITCH. The VSWITCH is connected to the same OSA
adapter (different ports obviously).
Note, I'm not using hypersockets for lpar to lpar communication at this
time.
I'm having a communication problem between a DB2 client on VSE and a
DB2 server on zLinux.
When I run the standard DRDA client code, which uses LE functions, the
communications work, just poorly.
The DB2/VSE folks have an assembler version of this code, which
eliminates the LE calls, but it doesn't work. (but we are the only
installation, of the 3 or 4 that are using it), that is having an
problems. Of course, being one of a few, means each installation is
very unique in hardware/software/communications.
So now I'm looking at the VM side. I doubt that the other DB2 shops
are connecting LPARS thru dual VSWITCH setups.
So, what is the consensis on VSWITCH... Was it rock solid stable from
day one? Or was it more of an envolution with a lot of maintenance
(that I need to apply) in order to get it to the fine product that
everyone is happy with?
A piece of the dump we get with the assembler DRDA code:
ARI0801I DBS Utility started: 09/26/06 16:11:37.
AUTOCOMMIT = OFF ERRORMODE = OFF
ISOLATION LEVEL = REPEATABLE READ
##### BEGIN FIRST FAILURE DATA CAPTURE DUMP #####
<<<<< DUMP IDENTIFIER : 20060926161137 >>>>>
APPLICATION REQUESTER DUMP
LUWID = LUWID NOT EXIST IN AR DATE/TIME = 2006-09-26
16:11:37
EXTNAM: .........33
RDBMS: LINUX40 ......... V..... (ALIAS: LINUX40
)
SYMPTOM STRING: MS/ARI2909I PIDS/5697F4201 RIDS/ARICTPB PRCS/01
PROBABLE CAUSE OF FAILURE :
OPEN ACTIVE SOCKET
##### DATA AREA CSIECB #####
00793718 00000000 00008000 1007C351 E9E90000 00000004 *
......C.ZZ...... *
00793728 00000010 00000000 00000000 00000000 00000000 *
................ *
00793738 TO 00793748 SUPPRESSED LINE(S) SAME AS ABOVE ....
00793748 00000030 00000000 00000000 * ........
*
more dump
##### END FIRST FAILURE DATA CAPTURE DUMP #####
ARI0503E An SQL error has occurred.
The communications path to LINUX40
is disabled. No further access to this path
is possible. Request Code = 002.
ARI0505I SQLCODE = -933 SQLSTATE = 40003 ROWCOUNT = 0
ARI0504I SQLERRP: ARIRCNCD SQLERRD1: 4 SQLERRD2: 0
ARI0808I DBS processing completed: 09/26/06 16:11:37.
The PTF (PK00122) that gives us the assembler DRDA code documentation
is:
Error description
DB2/VSE requesters that use TCP/IP currently perform TCP/IP
functions using the LE/C interface. This requires the use of an
LE environment and adds significant overhead and code path
length to the DB2/VSE requester. This enhancement uses an
assembler interface to perform the TCP/IP functions and avoids
the overhead needed by the LE/C interface.
Note: This enhancement only applies to DB2/VSE requesters.
DB2/VSE servers will continue to use the LE/C interface to
perform TCP/IP functions
So, was VSWITCH rock solid, out of the box? or did it need a little
help getting there?
Thanks
Tom Duerbusch
THD Consulting
--
Rich Smrcina
VM Assist, Inc.
Phone: 414-491-6001
Ans Service: 360-715-2467
rich.smrcina at vmassist.com
Catch the WAVV! http://www.wavv.org
WAVV 2007 - Green Bay, WI - May 18-22, 2007
