Re: Remoteoutq quit working

Chuck,

Used ALL your references and still just a TCP3701. They have ANYNET configed
so I changed the remote outq to use SNA vs IP and it's working.

I even did a STRCMNTRC and could see Telnet stuff back and forth but never
anything for port 515 going either way A to B or B to A... anyway it
working.

Thanks for the info

On Mon, Jun 6, 2011 at 10:51 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

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
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.