ENV: AIX 4.2
Model R24
DESC: Customer is sending remote jobs to a 3rd party print
server and is having trouble with the jobs going to
the wrong queues.
ACT: Customer check the qconfig file and notes that the rq is
correct. When customer sends the jobs with a delay
between the jobs they all print correctly but in rapid
succession they print wrong. Told customer to run an iptrace
to check that the rq is being sent correctly, if so the
print server is the problem. Sending iptrace fax.
Response:
ACT: From iptrace we see that the the files are being sent to
different print queues but the temp file names being specified
for the remote system are all the same. So when the jdf files
are created they seem to be overwritting one another and causing
the irratic condition. Customers sees this as when he truns
on lpd debugging on the server he sees errors that it
cannot open the tmp file. Customer will send iptrace
as testcase.
NEXT: Research.
Response:
Response:
ACT: received the email and found:
====( 86 bytes transmitted on interface en0 )==== 16:00:00.500304128
ETHERNET packet : [ 02:60:8c:2e:60:2c -> 00:00:77:02:70:1b ] type 800 (IP)
IP header breakdown:
\< SRC = 191.207.128.253 > (gemini.corp.qfc.com)
\< DST = 191.207.128.201 > (qfccorp.corp.qfc.com)
ip_v=4, ip_hl=20, ip_tos=0, ip_len=72, ip_id=32269, ip_off=0
ip_ttl=60, ip_sum=7f3d, ip_p = 6 (TCP)
TCP header breakdown:
\
th_seq=4a485408, th_ack=7b5a2002
th_off=5, flags\
th_win=16060, th_sum=7447, th_urp=0
00000000 03313833 34206466 41303030 67656d69 |.1834 dfA000gemi|
00000010 6e692e63 6f72702e 7166632e 636f6d0a |ni.corp.qfc.com.|
ACT: Customer does not have anywhere near 1000 jobs queues. He says
maybe at most 50 jobs. Due to this I will escalate to L3PRNT.
L3 discovered that the code for rembak determines the \#\#\# following
the dfA in two ways. If it is called from qdaemon, it uses the
next job\# for that system. Since he is using the local filtering
the piorlfb script calls rembak, and not qdaemon. When it is called
from somewhere other than qdaemon it uses the present time.
Specifically it uses the three digit number is set to the last
three digits of the current time since 1/1/1970. Since rapid
submission can lead to rembak being called multiple times in a
single second this leads to the same filename.
L3 is working on correcting this in future releases, but for now
suggests a workaround of submitting the jobs >1 second apart.
Support Line: remote printing loses job files ITEM: CF2884L
Dated: October 1996 Category: N/A
This HTML file was generated 99/06/24~13:30:18
Comments or suggestions?
Contact us