Re: Branches down. Any ideas? -- MIDRANGE-L

I have several dumb ideas ... perhaps some will lead to ideas for you to try 
that you overlooked because they are dumb ideas about stuff we normally not 
have to mess with.  

I am also BCC this direct because I am having slow turn around on some 
midrange_L & bpcs_L posts (it could just be AOL) in which some stuff I post 
is not getting back to me for 2 days & I am seeing people answer questions & 
I not see the original until 24 hours later ... normally this is not a 
problem for me, but slow info to your current situation could be particularly 
irritating, but only if my ideas include one that is helpful.

It is always possible that you have more than one problem confusing issues.

If you have not done anything involving a change in configuration, you might 
want to ask about how to do selective restoring from a backup perior to the 
"damaged objects" story ... just restore wherever configuration data is 
stored.

Check your configuration for automatic vary on attempt after IPL power down & 
various interruptions.

I have a menu used in association with re-IPL with stuff to check that is 
easily overlooked.

We have frame relay through an ISP that sometimes goes down without warning & 
gives totally unsatisfactory information about when back in business or why 
down.  Since other branches on the ethernet are working ... if they are not 
local, then frame relay being down would not be an explanation, unless there 
is some sequence of ma bell connections, with everything up to the break 
working & everything from the break onwards failing ... I not know enough of 
how the technology works to know if that is a possibility.

We have had intermittent ma bell problems due to the direction the wind is 
blowing trees brushing against the phone lines in bad weather ... we now know 
this is a seasonal thing, but if you have only had your frame relay for a few 
months, you do not yet know the seasonal disruption patterns.

Is your AS/400 on automatic recognition of the stuff that is out there, so 
that if actual configuration gets rearranged, the configuration automatically 
(within a few minutes) changes to agree with what it found ... this is a 
WRKSYSVAL.  We have found that this does not work for remotes like local 
(because we have not disabled our SSP reality) and in the case of an address 
switching between printer & terminal, we do have to delete the old reality 
before it properly recognizes the switch.

It could be a Y2K thing ... end of first year that is zero ... like the 
caller id on my home phone lost its memory "coincidentally" on the new year 
... it did this at the end of the first year that was zero but not at the 
beginning of year zero.

You might like to change the system date via WRKSYSVAL to a couple weeks ago 
& re-IPL & tell everyone how to change their session date back to today ... 
put it in a CL on a menu to make it easy for them.  If operating with a date 
that is not yet end of year zero improves your overall situation, then you do 
know that Y2K is involved.

You might send a notification to 100% of your relevant suppliers 
Motorolla, ma bell, IBM

Tell them you have a serious problem with stuff down & you having trouble 
diagnosing where the problem is ... ask them for data on latest versions of 
software, PTFs, patches, whatever they call it, especially anything related 
to the new year

We intermittently have stuff down & what I call "gremlins in the 
connectivity" so we have a growing check list of stuff to look into.

DSPLOG & F4 I think it is to get at overall picture of system messages & 
people successfully getting on & off ... you can get this back a few days ... 
you cannot *OUTFILE it but you can *PRINT it then get the 400 spool to 400 
file or search for hits of particular devices & the messages surrounding that 
... this might be easier to navigate than DSPMSG QSYSOPR F4 then see about 
that to *PRINT

Do we really know who all the players are?

We had a scenario where someone did a PC upgrade & put on the back of it the 
wrong kind of cable through splice to the daisy chain & that meant that every 
time the twinax tube in the purchasing office on the same line was actually 
powered on it caused the work station on the receptionist desk to fluctuate 
between talking to the 400 & connection lost ... so basically there was 
interference on the line that caused us to spend an eternity with the 
purchasing office tube which was innocent.

We had a scenario where someone unplugged a tube from the end of a daisy 
chain without telling the new end that it really was the end, which meant we 
had hundreds of feet of unterminated cable in the ceiling acting as an 
antenna for all kinds of interference.

We had a scenario where one tube lost its configuration & reverted to default 
of first address on the port, which was not a problem for that tube so long 
as the tube that was officially at that address was not powered on.

IO sells a twinax tube that you can stick on a line & in addition to being a 
regular twinax tube, there is also a line configuration analysis screen that 
will tell you if there are any problems with the overall system talking to 
any of the other device addresses on that one port line & the whole thing is 
so user friendly it can be operated by an ordinary non-technical user.  I 
think we need tools like that for larger networks of mixed vendors equipment.

Are any of the printers really PC printers in which their 400 identity is 
dictated by a PC ... we have several in which the 400 talks to the printer 
through some other device ... the timing is critical in powering on other 
device & having it talk to the pritner ... under some circumstances the other 
device can lose the printer configuration data ... nothing wrong with the 400 
... nothing wrong with the printer ... the problem is in the PC or terminal 
that is telling the 400 about the printer.

Did the cold weather get at the equipment?

Do we have sufficient tech support to get multi-vendors on the same 
conference call while some testing is conducted?  We have our Motorola 
communications gear on our IBM CE contract & we use the same IBM partner for 
local operating system support as we use for our telco support.

There are issues associated with the sequence of powering stuff up & folks at 
remote ends not experienced with this stuff ... like power off modems at both 
ends ... confirm lights on devices they are in fact powered off both ends, in 
addition to controller being powered off, then bring it back in what sequence 
& confirm hardware is in fact powered on ... someone at host end looking at 
manual & asking remote end person about lights on some panel.

Our controllers come with a diskette that saves configuration last time we 
changed it & that configuration can be lost & needs restoring from the 
diskette.

Apparently for every actual device out there in reality, in addition to the 
controller's map of what all is there, and the AS/400 configuration "files", 
there is a hardware map of theoretical addresses & that hardware unit can go 
flaky such that certain addresses do not work ... nothing wrong with the 
cabling, the controller, or the configuration, the problem is in some chip 
inside the AS/400 ... easy enough to get a service call & have a CE eliminate 
that possibility.

How often do you power off stuff ... as an economy measure last year we 
started asking people to power off their stuff when they went home at nights, 
especially before 3 day weekends & now have a job scheduled message to "all 
active" users 1/2 hour before end of day every Friday with a reminder about 
this ... right after we instituted this economy measure, we had a spate of 
repairs needed for devices that had been powered on for years & the act of 
powering them off broke them (I suspect a flaky power off switch).

We also found some wiring problems ... people had been adding equipment to 
wall plugs & so long as adding one at a time & leaving power on all the time, 
no problem, but no one knew how to power on off bunches of equipment without 
causing surges that damaged some of the equipment.

>  From:    sporter@bestdist.com (Sean Porterfield)
>  
>  It started out 2 days ago with one printer down.  It would never work,
>  so I varied off everybody at the branch (ended the other printer first),
>  varied off the controller, and had them power everything off.
>  
>  After powering back up (printers then terminals then controller) they
>  had only 2 terminals working and no printers.
>  
>  We went through the controller config and it looked OK.  At some point,
>  there was "Internal object is damaged" and one of the suggestions is to
>  IPL.  I first tried deleted all devices related to that branch, but no
>  go.
>  
>  So we powered down/up last night.
>  
>  Now 5 branches are down!
>  
>  They are all connected on frame relay using SNA on the ethernet line. 
>  There are other branches on ethernet that ARE working.  The routers are
>  Motorola and are apparently doing some kind of 5494 emulation. 
>  Controllers are IBM (don't know the model.)
>  
>  APPC controllers, APPC devices, RWS controllers all say ACTIVE.  All
>  devices at these branches are VARY ON PENDING.
>  
>  The router people say everything looks good and there should be signon
>  displays.  Nope.
>  
>  Any thoughts?
>  
>  TIA!


MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
AS/400 Data Manager & Programmer for BPCS 405 CD Rel-02 mixed mode (twinax 
interactive & batch) @ http://www.cen-elec.com Central Industries of 
Indiana--->Quality manufacturer of wire harnesses and electrical 
sub-assemblies - fax # 812-424-6838

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