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

["Jim Franz" <franz400@xxxxxxxxxxxx>]

> They assure me the AS400's are configured identically,
> through a WAN that the network people say should act just like the LAN.

LAN & WAN are never the same! -
To test the "configured identical" idea:
Ethernet card on both as400s 10 or 10/100 (or larger).
The TCP interface MTU Max Transmission Unit same?
The Line Description parms are same - Ethernet standard,  Line speed?
SSAP parms same & have same max frame sizes

Controller Description - Max Frame & SSAP, DSAP same?

Controller Lan Timers - YOU DON'T WANT THE SAME !!!! Timers for WAN need to
be larger!

See book OS/400 LAN, Frame-Relay and ATM Support,  SC41-5404

The WAN router packet size needs to be set to handle the sna traffic (my
guess is the router is

breaking the packets). If Cisco - they have  info on suggested setup for
AS/400 SNA over Wan.

Regular network tech will not know how to get  SNA over a WAN.  Also, don't
let them

turn off or spoof some of the sna traffic in the router.

hth

jim



                   ----- Original Message -----

From: "Tim Truax" <truax@telerama.com>
To: "MIDRANGE-L list" <MIDRANGE-L@midrange.com>
Sent: Friday, February 07, 2003 4: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.
>
>