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: email@example.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: firstname.lastname@example.org +---
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.