|
Very few people these days have genuine IBM for whole network. All over the place there are cheap things that supposedly emulate IBM, but drop something, so you have stuff dropped all over the place, to complicate later troubleshooting.
You need to have one person with tester on one end, another person with another tester on the other end, and telephones on speakers so they can be talking to each other. There is also the scenario of one person at physical device, another person at some 400 screen manipulating settings, and asking other person if they see any change in the indicator lites at their end.
We often find that disconnecting everything and reconnecting everything is a big help. It does no good to power down only part of the network (re-ipl the 400) when the other devices are in some error condition. Bring the entire system down, including all connections, then bring the entire system back up again. If that does not do it, experiment with what sequence bring various parts up. I call this having the tail wag the dog.
Even though you have no service contract, there are places that do this kind of troubleshooting, that could give you a quote ... We will come in for a day to work on trying to fix your problems and our bill for one day will be no more than $1,000.00 or whatever ... then you have some sum of money for management to negotiate.
Many physical terminals are capable of supporting more than one sign on session. Check the actual terminal setup to see how many ... this might account for your 15 addresses. Also, in times past there may have been connections that got pulled from the system, without telling the 400 to delete those old ghosts. You can dump the config data to an *OUTFILE to find out which addresses have not actually been used in eons, and so delete from the big picture.
Terminals can be connected to the daisy chain via a variety of connectors, the kind that are right for that device, and a wrong kind, that can cause troubles on the rest of the line. There's also a right kind of splice, and el cheapo substitute that not always work perfectly.
The pigtail self terminates if there is nothing plugged into the outgoing line.Every terminal came with a manual or two. If you can find one of them, there's lots of illustrations to help with troubleshooting.
Before IBM went with on-line documentation, there were also manuals on the 400 networking, which included a lot of useful info, such as the innards of a twinax connection.
It might be useful to do a WRKCFGSTS print dump, then try to match up pages with terminals, and place a sticky post it note on devices "I think this one is DSP37."
I am assuming you talking LOCALLY connected terminals, as opposed to REMOTE SITE (different city than the AS/400) or VIRTUAL (something non-IBM between the 400 and the terminals that is emulating a LOCAL or REMOTE)
People do things and everything THEY working on seems to be working Ok, but if something goes haywire with some other co-worker, how are they to know. If the warehouse did the disconnect near end of work day, perhaps the co-workers ready to go home..
Sometimes things go haywire and IT not get told right away, so then you troubleshooting something else and not know what all really involved.
You can access the setup screen on the terminal, even when something is messed up in connections with the line.
The terminal cannot tell you what port it is on. It can only tell you what logical address has been assigned to it on the cable thru of its port.
The terminal cannot tell you what physical address it is on, in terms of actual cable from computer to end of the line.
In other words, the first device on the physical cable from the computer down the daisy chain might be # 8 in logical assignments.
It can be a big help if someone can physically trace the cable through walls floors ceilings. If your place anything like ours, be prepared for finding lots of cobwebs and creepy crawly things in poorly lighted above false ceilings, get someone to hold rickety ladder while poking around up there, and for God sake, do not try to walk around off the ladder, you could break your neck.
Purpose of this exercise is to label physical addresses of connections, so you can get stuff working again outwards from the 400.
I assume that the working printer has some id where you can be absolutely certain that is the one on PRTDEVADR for that port.
I believe PRTDEVADR is for locally connected. You need to use something different for remote connections.
WRKSYSVAL automatic configuration works fine for devices being disconnected, reconnected with different logical addresses. Printers can need a reboot of the 400.
Since the printer is working, the connections from 400 to the printer are physically Ok, so you could also try to trace the cables from that, in both directions.
A device on a daisy chain has been known to forget its logical address, or get it messed up because of humans messing with stuff. So now you have workstation-A with address 7, that was that way all along, and workstation-B also with logical address-7, because of human error, two devices on same daisy chain with same address. This is asking for trouble. This can mess up access to more than just those two devices.
When stuff on a port goes down, the problem could be in the connections on the daisy chain, the hardware to run the controller, some chip inside the 400/iSeries that tracks the gone addresses.
Daisy Chained means cable thru from same port. You may need to trace the actual physical cable. With 15 connections, you are above the old 11 ceiling on number of splices supported, meaning you extremely sensitive to interference from bad connections.
You have 4 terminals and 1 printer on the line, that you know about, eating 15 addresses.
You have an unknown number of splices in the line.The device that got disconnected. If that was not the end of the line, the cable at that point needed to become a splice. The plugs are very easy for ordinary people to mess up the connection, twisting so that the connection is broken. There are kits you can use to test lines to find out if messed up or not.
If the disconnected device was the end of the line, then the next one back needed to be changed from cable thru to terminate the line, other wise the cable to the now disconnected turns into an antenna to cause interference all down the line.
When we get new addresses hooked up, we soon go into WRKCFGSTS *DEV F4 and change DSP99 or whatever to something that is meaningful to approx WHERE in the building it is located such as SHIP3 (3rd session in shipping) REC5 (5th session in receiving) BUYB (side B in purchasing) COS4 (computer room main console) AM (Accounting, Mary's work station). That way, when stuff goes haywire, we have a clue as to where it is. We do the same thing with printers.
You can change the WRKSYSVAL and go with a naming convention that includes the port as part of the naming. This only helps for the future, not what already been named.
- Al Macintyre http://en.wikipedia.org/wiki/User:AlMac http://www.ryze.com/go/Al9Mac BPCS/400 Computer Janitor ... see http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
