Re: BIG Communications Problem - I'm CLUELESS...

Often with non-tech folks at remote sites there is the general user problem 
of not communicating relevant facts that might help diagnose what went wrong 
& there are people who see part of the picture & assume all relevant 
co-workers also see those facts.

Ask the remote site if they recently had a building power outage ... 
or any other public utility disruption
Is the Perle on a UPS or just a surge protector? 

If there are facts that you need to get from the remote site ... ask for them 
right away while fresh in their memory ... I have had conversations with 
remote sites in which I ask them if their electrical power is Ok, and they 
say "Yes" not volunteering the fact that they had a power outage 5 minutes 
ago & assuming I know that, when I am going down a check list of suspects, so 
I continue tackling problem as if a power outage is not part of the picture.  
If I had asked the question when the phones worked but the power did not, I 
would have gotten a better answer.  Perhaps the failure is in my ability to 
communicate a proper question.

We sometimes have power outages that are like blip gone & back, such that 
some devices go down & some continue to run fine, but the end users do not 
"witness" the outage, or realize that it happened.

We also have phone line downage - blip it is back, but some devices handshake 
not properly recovered.

When we first installed our Perle units several years ago, we used to have a 
devil of a time with brown outs - the AS/400 would be constantly trying to 
reconnect, drowning in error messages - I reccommend a small UPS in the room 
that has your modems & Perle & Cisco & etc. at each site, so an outage at one 
facility does not mess up the whole network.

I have long been aware that the quality of remote diagnostic information does 
not measure up to the quality of local diagnostic info.  It is like Cisco & 
Perle are emulating most everything we need to be operational but something 
non-obvious is missing.  We cannot trust all the diagnostic information in 
the same sense that we can believe it when done locally.

There are non-IBM twinax devices all over our network ... I generally insist 
that the main console per facility be a device that is on IBM maintenance, 
because we have had visitations by IBM CE unable to help us out because we 
unable to provide IBM equipment for them to use.

We recently switched our Perle to Frame Relay instead of leased lines. 

We used to be able to vary off communications line, which has 4 controllers 
(1 Perle box with 4 twinax cards) then vary on communications line, and get 
all the attachments, but now with Frame Relay more than one remote site is on 
the same line.

It might be helpful to create an illustration of what the front panel of 
modems & Perle & UPS look like when all is well, and have copy at remote site 
& at HQ.  The purpose of this is so when talking to someone at remote site 
who probably has never looked at these devices before, they know which is 
what when you ask & also whether the lights & indicators on the panels are 
normal.

We find the simplest way to recover after a public utility outage at a remote 
site is to flip off the modem there, wait a couple minutes, then flip it back 
on again ... this resets all the handshakes.

I not handle the communications side so not know what you mean by PING but do 
know that when we on leased lines & ma bell tested them, that would bring 
AS/400 connection down ... you cannot be pinging & handshaking at the same 
time.  What looks fine to ma bell is not in 400 language.

Also check out your terminating devices ... some twinax need a T connector 
with tail into the device ... some twinax need cable through the actual 
device ... you can physically hook them up wrong & they appear to work, but 
you get an intermittent problem elsewhere on the line.

We had one case of this where a PC emulating 5250 was flickering on & off 
connection to our midrange only when a Lynk on the same line was powered on 
but there was nothing wrong with the Lynk or its connection, the cause was 
another PC on the same port that had the wrong style of connector ... we 
never found where IBM documented this nuance.

We also have gremlins such that some addresses are not recognized ... 
apparently there can be a bad chip on the host for some logical addresses.

>  From:    clewis@iquest.net (Chuck Lewis)
>  
>  Hi Folks,
>  
>  Not sure WHAT is going on here. We are on a 620 running V4R1. Ethernet
>  NIC card in the AS/400. Frame Relay network to attach remote branches.
>  Cisco routers and Perle 494e control units with an Ethernet NIC.
>  
>  Three times now in the last 3 or so weeks (including about 15 minutes
>  ago) our largest branch (2 virtual controllers in the Perle because it
>  has 2 twin ax cards in it) with 53 devices has called and said their
>  screens were blank. I look at things on the AS/400 and all looks FINE. I
>  ping the router AND the 2 virtual Perle control units and all looks
>  FINE. I pick a device that shows a signon screen and vary it off and
>  back on and it shows Vary On Pending and will never go active. So I end
>  up killing the jobs and writers, varying off the control units and the
>  virtual devices (one for each controller) and varying everything back on
>  and everything comes back up FINE.
>  
>  Anybody have ANY idea WHAT is going on or what I should be checking, how
>  I should be checking, where I should be checking, etc. ?
>  
>  Thanks in Advance :-)
>  
>  Chuck


Al Macintyre  ©¿©
http://www.cen-elec.com MIS Manager Programmer & Computer Janitor
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---