Re: 5494

We sometimes have glitches in the continuous connection of remote site
communications, for which we have learned that it is smart to power off the
connections at both ends, then power back on again for re-establishing of a
clean connection.

WRKCFGSTS tells me if the AS/400 thinks there is some kind of problem with
the device in question, but just in case it was varied off for security
reasons, check your QSYSMSG if you have one, or QSYSOPR if not ... you might
also check DSPLOG for hits on that work station address ... will tell you
last time it was used by anyone & if it went down in mid use, which means
there may be a SYSLOG not on the down event, but on the damage to the
software it was running at the time.

Have you recently added new equipment to that line?

Sometimes connections, particularly non-IBM twinax, can lose their
configuration, which means they interfering with some other device on the
same line.  If you know everything that is on the line, try powering off all
but the device in trouble ... does the device in trouble now work Ok?

When printer involved, we sometimes have to delete printer config as part of
the recovery process ... somehow auto config not always seem to recover
properly when switch between display station & printer there, like some
vestige of old config remains.

Have you used up all logical addresses that can be used on the daisy chain?

There are several places where logical addresses are checked ...
the equipment on the line
the remote controller
some chip on AS/400 that has all theoretical addresses
OS/400 config info

any one of those can go bad ... I listed from most likely to least likely

We had a case of user-A work station connection going flaky whenever user-B
work station was powered on that was traced to the wrong kind of connector on
user-C work station all 3 on the same line.

We have a case of a remote site line in which we can get all but 2 of the
addresses to work ... it does not matter which 2 logical addresses ... the
problem is not the specific 2 addresses, but that line & we have also tried
switching ... all kinds of things

how the line goes through the equipment (physically running cable along the
floor to the offices as substitute for the one in the walls to see if problem
is with a section in the walls)

which line attached to which port ... switch lines at the controller port
with another daisy chain to see if the problem is with the hardware or with
the system tracking the logic (latter found to be the case ... it is that
port, not what is connected to it or where ever in the building the
connections are)

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)