Re: [2] AS400's [same] not acting similarly ??

Tim,

I have just a couple of thoughts in addition to what Jim Franz has already
noted:

1) On a WAN the packet sizes will typically be smaller than on a LAN. The
CISCO routers are probably doing this. The same thing usually happens with
TCP traffic. I wouldn't think this would be a problem. The SNA protocol
should put these back together on the receiving end. UNLESS there is an
error in the router in how the packets are getting sequenced. When the
receiving RPG program detects an error is there a major/minor code? Is there
sense data related to the failure?

2) The backup AS/400 may have different routing and class entries in the
subsystem that is processing the evoked (allocated) jobs. The slowness after
30 of these things get going may be due to this. Have you compared the
execution environment on both systems?

3) Lastly, a comms trace of the SNA traffic can sometimes help determine a
problem.

Patrick
----- Original Message -----
From: "Tim Truax" <truax@telerama.com>
To: "MIDRANGE-L list" <MIDRANGE-L@midrange.com>
Sent: Friday, February 07, 2003 1:48 PM
Subject: [2] AS400's [same] not acting similarly ??


> 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.
>
>