RE: Client Access disconnecting

There's still a lot of "fix it with a hammer" thinking in the telco
world...over the years, I've spent hundreds of hours tracking down problems
rejected by Bell and AT&T as "not theirs"; at some point, you bump up
against a tech not in denial and the problem gets solved in one heartbeat.
In spite of the turmoil caused by deregulation, competition and advancing
technology have been beneficial.

One thing: you didn't identify the test device correctly.  Just prefix "shi"
to the name and you've got it right.

-rf

-----Original Message-----
From: midrange-l-admin@midrange.com [mailto:midrange-l-admin@midrange.com]On
Behalf Of Ray Peterson
Sent: Friday, March 01, 2002 12:30 AM
To: midrange-l@midrange.com
Subject: RE: Client Access disconnecting

Jim...

We've been there with the CA drop problem and have it resolved!  In our case
it turned out to be a telco problem  that the phone company could not see
with their test equipment.  Since the telco's test equipment (something
called a "T-bird" I think) showed a flawless T1 with no bit errors, no
alarms, etc. they insisted the problem had to be in our equipment.  After
many months of trouble shooting, we finally isolated the problem down to an
anomaly on an OC-12 coming in to a state owned ATM switch which is housed in
our building.  Fortunately one of the State of Wisconsin tech's in Madison
could see the errors on the OC-12 even though the telco's tests showed an
error free T1!  With the state on our side we had some leverage, however
after further testing the telcos were sure the problems were due to either
faulty power or rf interference from our own equipment.  We wound up having
to cut all power to the building to eliminate all sources of interference
and rf from our stuff.  The ATM switch went on battery power and the techs
in Madison could still see the problem!  With that proof, the telco had to
admit the problem was indeed theirs and not ours.  I'm not sure what they
actually did to fix the problem, but it only took a day or two.

The bottom line is that a problem that was transparent to the T1 test
equipment would kill CA/400 sessions.  Fortunately, the problem could be
seen on the OC-12.  The state of Wisconsin has invested over a $100 Million
in this network.  The only reason we were able to isolate the problem was
thru the help of a state employee who could see the problem.  I'm not sure
we would have ever gotten the telco to look at an OC-12 to fix a problem
with a T1.  It just doesn't make sense to test at that level.  But that's
where the problem was.

Ray


-----Original Message-----
From: midrange-l-admin@midrange.com
[mailto:midrange-l-admin@midrange.com]On Behalf Of Jim Franz
Sent: Thursday, February 28, 2002 7:38 PM
To: midrange-l@midrange.com
Subject: Re: Client Access disconnecting


Anyone experiencing the CA drop - it would help if you described your
complete environment (like...
W98 w/ 10/100 ethernet connect to local lan thru xx hub 10? or 10/100 , same
lan segment as AS/400 10/100.
Describe the AS400 ethernet (the old 10, or 10/100, or gig eth)
Ethernet line description  Ethernet standard, Enable for TCP/IP, Line Speed?
Duplex? SSAP parms (3rd screen of line desc)
Is this local lan or wan (wide area/remote)
For wan - router used and how config'd - it has timers for resend, maybe
packet prioritization, you could be dropping when someone sends a file
transfer?
Controller description timers on AS400 default to local conditions, and
timers need to be increased for wan.
Private frame or internet? or some other cloud like IBM Global (scary!)

Time-out parms?
system values for QDSCJOBITV, QINACTITV, QINACTMSGQ, QDEVRCYACN
TCP parms in TCP Attributes: TCP keep alive
Telnet Attributes: Session keep alive timeout
(I don't have V5R1 to see if any new parms)

messages in qsysopr like ...
Job 939957/SIEMPRE/HT was ended by user QPGMR.  (CPC1126)
Job 938387/JIMF/QPADEV0003 has not been active.   (from QINACTITV)

joblogs
wrksplf qtcp and see what's there
wrkactjob & dspjoblog for all jobs like QTVDEVICE
maybe change jobd QTGSTELN to log more
 CHGJOBD JOBD(QTCP/QTGSTELN) LOG(4 00 *SECLVL) LOGCLPGM(*YES)
let it fail & look again.

There is a thousand places for this to fail, especially in WAN. There's more
than this, but
this is a start.

jim franz



_______________________________________________
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/cgi-bin/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.