Re: Remoteoutq quit working

On 06-Jun-2011 21:11 , Kirk Goins wrote:

I have a client with a pair of 170s running probably 4.3 or so ( I'll
check the rel tomorrow ). they have a remoteoutq from one system to
the other. Today the whole sending system hung and before they called
me they had unplugged the source 170 and rebooted it. ( Bad Customer,
Bad ). After that the remoteoutq just goes to a SND state. The LPD
job on the receiving system updates/resets the Idle-time but nothing
ever hits the outq.

I tried creating a whole new pair ( sending and the destination outq
) but I am getting a TCP3701 with no previous messages and the writer
ends. Both system were politely restarted tonight with no change. I
am going to try and create a reverse pair of outq's tomorrow just to
see what happens. According to the client 'nothing else has changed'
We can telnet between both systems just fine. I have even did my old
standby and moved a joblog into the outq but it acts the same way so
I don't think it's job/splf related.

Any Ideas?

Try SNDTCPSPLF against a SPLF residing in a local OUTQ [not one already in a RmtOutQ irrespective of status] to see if the LPD can accept and that LPR functions outside the TCP\IP remote *OUTQ feature. This is step-23 [fourth doc link below; heading inline is "Symptom: Spooled File in SND Status and Spooled File does not Print on the Printer (or Arrive on the Target System)"]. On really old releases LPD may need to be running on the source system; that would mean verifying the QTMPLPD user profile.

After a hard crash I usually would look to QHST for any damage messages, and the VLic log for any damage VLogs since just before the system failed; and esp. near the time of attempts to use the failing function. If the spool file stays in SND even after the writer ends, there is a KB doc step-25 [fourth doc link below; same heading as step-23 noted above, under another heading "Symptoms Associated with Remote Output Queue Printing"] which includes a recommendation to call QSPFIXUP. Less likely after a crash is an authority issue as side effect of the crash [though possible an object was created but no aut set and so a later reference which locates object is unable to access per the missing auth], for which after ending everything and then restarting only after auditing is in effect for *AUTFAIL, a review for T-AF entries might assist to track down an issue.

Some links FWiW; first three are just redirects to limited-access documents [e.g. BP access versus standard free IBM-ID], and the third is included ignoring "no previous messages" comment. The fourth document has "Symptom: All Remote Writers Have Stopped Printing" and "Symptom: Remote Writer Starts and Immediately Ends" which may apply also? The "undocumented diagnostic tool" found with no special access via a web search which is described as being for "LPR debug mode" at the fifth link may be of use.?

https://www-304.ibm.com/support/docview.wss?uid=nas17b74f84e8ca1a23886256ab800426b9d&crawler=1
"Remote Output Queue (RMTOUTQ) Ends Immediately with Message TCP3701"

https://www-304.ibm.com/support/docview.wss?uid=nas10d342226892b755b86256bc200434e9f&crawler=1
"Remote Output Queue (RMTOUTQ) Fails with Message TCP3701 and No Other Messages"

https://www-304.ibm.com/support/docview.wss?uid=nas16763a32ffb4fa12486256968006eaee0&crawler=1
"Remote Writer Receives Messages TCP370A and TCP3701"

https://www-304.ibm.com/support/docview.wss?uid=nas12a414d2d7d7ab7e9862568be00722993
"Configuration Settings and Error Messages for Remote Output Queues (RMTOUTQs)"

https://www-304.ibm.com/support/docview.wss?uid=nas1a62c6590ae5ee530862565c2007d43a4
"10905059, Activating Debug Mode for Remote Output Queues (RMTOUTQs)"
... "LPR Debug Mode

When diagnosing problem with Remote Output Queues (RMTOUTQs), it can help to activate the LPR Debug Mode before reproducing a particular problem. This will cause extra information to be logged to the writer job log for every spooled file that is printed or sent through every RMTOUTQ. This information can be very useful when diagnosing problems, but can also slow down all of your RMTOUTQs and will cause the writer job logs to be considerably larger, so debug mode should be turned off once you have reproduced the problem and collected the writer job log.

This is an undocumented diagnostic tool for use by the Rochester Support Center to aid in solving internal LPR problems, particularly those that occur sporadically or cannot be reproduced here.

While activated, additional debug messages will appear in the writer job logs and on screen when the SNDTCPSPLF command is used manually. Be advised that there may be additional messages in the job log."

http://www-912.ibm.com/s_dir/slkbase.NSF/0/32afe7c42c90146186256f970069b0fb?OpenDocument&ExpandSection=6
"Running a TRCCNN Trace for LAN Printing Problems"

https://www-304.ibm.com/support/docview.wss?uid=nas1c7b1e076e7740a9c86256ab90057b4fd
"Configuring a RMTOUTQ to Send SPLFs from one IBM System i to Another using LPR/LPD"

Regards, Chuck