|
We are gonna run a test on this tonight. I want this information from the network people. I have inquired to see the exact split up areas on the 2,400 byte records. I will keep you posted. Tim ----- Original Message ----- From: "Vern Hamberg" <vhamberg@centerfieldtechnology.com> To: "Midrange Systems Technical Discussion" <midrange-l@midrange.com> Sent: Friday, February 07, 2003 11:21 PM Subject: Re: [2] AS400's [same] not acting similarly ?? > Tim, has anyone done a comm trace on the BACKUP 400, to verify the size & > contents of the packets it is sending out? > > Vern (don't know what to snip) > > At 04:48 PM 2/7/03 -0500, you wrote: > >Here's a stumper, (i think) > >100 RPG program communication jobs using an antiquated but functional LU6.2 > >connection. > >100 jobs doing the same thing. > >100 information extractions occurring concurrently. > >100 jobs that run in a single sub-system on the AS400's. > >This program referred to above receives a 45 byte REQUEST record, and then > >sends out a 2,400 byte RESPONSE record of information pertinent to the 45 > >byte REQUEST. > > > >On 1 AS400 (the main one) this works great, this AS400 pumps the results of > >the communication job through a LAN, possibly less that a second turnaround. > >It's beautiful, and everyone's happy! > > > >On the BACKUP AS400 (supposedly identical), this AS400 pumps the results of > >the communication job through a WAN that the network people say should act > >just like the LAN. The length of time the actual programmatic process takes > >on the BACKUP AS400 is the same (about a second) but the 2,400 byte RESPONSE > >records are being fragmented ONLY on the BACKUP AS400 and timeouts are > >occurring with GREAT and unacceptable frequency. > > > >Here's the diagnosis: > >When we switch these 100 jobs from the main AS400 to the BACKUP AS400, after > >about 30 of the jobs have been switched onto the BACKUP AS400 the network > >people determine that an unusual "round robin" thing starts to happen, this > >is detected ONLY ON THE BACKUP AS400. They do not see this same thing > >happen under any circumstances on the main AS400. Meaning that the BACKUP > >AS400 system begins to segment the 2,400 byte response and put parts of it > >onto 1 packet, and then it moves to the next of the 100 jobs and takes a > >part of that processes 2,400 byte record and appends it to the next packet. > >What is evidently happening is the 2,400 byte response is being fragmented > >(which should NOT be happening) and appended to a 16,000 byte packet, the > >packets are big enough to accomodate the 2,400 byte RESPONSE that's being > >pushed into the LU6.2 from the RPG program and one would think that it would > >fit within 1 of these 16,000 bytes segments. The network people (and I > >think they're capable) see this 2,400 byte response being broken into > >segments and placed onto individual 16,000 byte packets and then reassembled > >by the receiving system. > >They assure me the AS400's are configured identically, Both AS400's are of > >the same POWER level. > > > >I think possibly there is a setting for the operation of the MAIN AS400's > >sub-system and the BACKUP AS400's subsystem on which these jobs run that may > >be askew or different. > > > >Any thoughts on this ?? > > > >Tim :-) > > _______________________________________________ > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/midrange-l > or email: MIDRANGE-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.