× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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  :-)






As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.