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

Hi Mac !

Thanks to all the feedback.

Yep, I agree with how folks on the "other end" can view things, etc. and I have
been REAL lucky to ID a good person at each site to walk through stuff and groom
in the "good info" vein !

A UPS is getting ordered for all of our sites !!

And yes, the diagnostics tools seem to be REALLY lacking at times - this being a
GREAT example  - of course I need to make sure I'M not missing something in that
regard FIRST before saying that I guess !!! Just in the pre-frame relay days it
was pretty obvious that 50+ devices were stuck because the LINE was failing or
something <BG> !!!

And I DEFINITELY agree with a diagram of how things SHOULD look, that is an
EXCELLENT suggestion !

Thanks !

Chuck

MacWheel99@aol.com wrote:

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

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