Help! No printer output since IPL

[Guest.Visitor]

We have several different printer models directly attached to our 400 (i.e., cat 5 cable daisy-chained to the WS controller), and we IPL'd this weekend. We had a problem during IPL and had to manually IPL again to get the console back. Now, all of our printer output is going to "H" status...when I look at the message queues, I see messages to "...please load forms type..." and they are automatically answered "H". Any ideas???

[Guest.Visitor]

Regina, Sounds like a reply list entry now exists for message CPA3394. Type "GO CMDRPYL" select option 4 and see if the CPA message is there. If so, remove it. One question is the subsystem QSPL active? Also what are the printers status when you do a WRKWTR *ALL? HTH Doug

[Guest.Visitor]

Yep, QSPL was started. I'm a former sysadmin turned pgmr, and boy, I'm getting a headache trying to remember all the stuff I've forgotten! Turns out that operations did a manual IPL over the weekend, and no one noticed that the amber light is still on. Looks like we lost our console, so I think that's the problem.

[Guest.Visitor]

OK, I was able to retrieve the console through a normal IPL, and I have started TCP/IP functions. The writers, however, are still not printing. The status on them is "STR", and QSPL is active. Current print jobs are going on hold. If I release a splf, when I check the message queue, the "load forms" message is there with an "H" reply, and the file is back on hold. I'm really stumped on this one. I did check the reply list entries, and I don't see anything there.

[Guest.Visitor]

Check the delivery method for the message que for the printers. Seems like I rememeber something that would cause you problem when this is set wrong. Sorry to be so vauge but thats all I remember. Roger

[Guest.Visitor]

I looked at message CPA3394, and I see that the default reply value is "H"....this seems to be correct. But, for some reason, the message is not "popping up" for user response, so the default reply is kicking in. The message option on all of these writers is "*INQMSG". I know this must have something to do with the message queue, but I'm not sure where to look next.

[Guest.Visitor]

Turns out that the QSYSOPR message queue had somehow been changed so that the DLVRY parameter was "*DFT", which means that all messages sent to that msgq were answered with their default reply. I changed it to "*HOLD" and all was well. I doubt that this had anything to do with our IPL/lost console problem. I think someone most likely changed it without realizing what he/she was doing. Thanks again. <whew>

[Guest.Visitor]

Regina, Are you using the Operations Console? I know there is a timing issue that cropped up with one of the recent CUMs. I have heard there is a PTF to fix that problem. If you would like I could forward you some instructions to cycle the port off and back on which should correct this problem without a full IPL. David Morris

[Guest.Visitor]

David: No, actually our operations staff had set up an async console, and they were trying using ReachOut to dial into that PC from home. During the IPL, they lost contact and the PC apparently went down. I think the 400 was looking for that device and therefore we had the error. We're still trying to come up with the best solution for a remote console.