Q:
ABSTRACT: PSF/AIX-attached 3900 duplex printer printing extraneous
characters. Need help in narrowing down the problem.
SEARCH ARG: extraneous psf/aix
TOPIC THREAD: PRINT
PSF/AIX
..
I am trying to understand a problem we are having when outputting
to a 3900 duplex wide driven by a PSF/AIX system.
Customer sends output created at the AS/400 over the network to an
RS/6000 printer queue. The file which is temporarily stored in
the queue is requeued with a new FORMDEF name (rather than the
default contributed by PSF/400). When printed on the 3900 duplex
printer some extraneous characters are printed too. They
apparently see no print-time errors, nor any of the "back-hitching"
we have seen in the past and seemingly caused by incompatibilities
between PSF/400 and PSF/AIX. The extraneous characters APPEAR to
be some that are found legitimately elsewhere on the output.
The output is created at the AS/400 using an RPG program.The
FORMDEF assigned at the PSF/AIX console is duplexed with N_up = 2.
When the output is printed, the extraneous characters appear
in the upper-left-hand corner of the right-hand logical page on the
first sheet and the upper-left-hand corner of the left-hand logical
page on the second sheet. Then the pattern repeats.
+--------+--------+
| |x | x represents the extraneous characters
| | |
| | |
| | |
| | |
+--------+--------+
|x | | x represents the extraneous characters
| | |
| | |
| | |
| | |
+--------+--------+
I am hoping you can suggest some other information to gather
or things to consider. Perhaps even this sketchy description
sounds familiar in some way. I appreciate any ideas you can
offer on this. Thanks.
A:
How are they routing output from the AS/400 to the RS/6000? Are they
using PSF Direct, or more likely from your description, using TCP/IP?
If the latter, what level of OS/400 are they using, how are they routing
the data (LPR? remote queues?), and any details on how they are
configured (HPT?). What is the type of data? What if any defaults are
set up on the PSF queues on the RS/6000 (easiest place to look is
the backend statement in /etc/qconfig)? Also, what PTFs does the
customer have installed on PSF/AIX (lslpp -L psf.* or lslpp -h psf.*)?
There are also a couple of other helpful diagnostics. It's often
helpful to see what exactly is coming across the network. There are
a couple of options, one of which assumes a TCP/IP connection:
1) Bring down the PSF/AIX queue and resubmit the job from the AS/400
side. When the job is transmitted, you can find a job descriptor file
(JDF) for that job in /var/spool/lpd/qdir, and in that JDF, you can
see the name of the temporary file (which is the job) that is now in
/var/spool/lpd. By viewing the file, you can see what the AS/400 has
actually sent over, It's possible to use the "od" command (with the
-cx flags) to look at the text and hex representations of this data, or
there's an IBM IUO tool on the AIXTOOLB disk called editbin which is
very handy for looking at files like this; it allows you to see the hex
characters and also toggle between the ASCII and EBCDIC representations
of the data. You can copy both the JDF and the temporary file to
files for further analysis.
2) If the communication method is TCP/IP, then you can also run an
iptrace to capture the IP traffic related to print between the AS/400
and the RS/6000; commands are issued from the RS/6000. A write-up
follows.
This should provide some clues as to the source of these extraneous
characters. I'll be glad to go through them with you.
**********************************************************************
HOW TO TRACE REMOTE PRINTING
The 'iptrace' facility can easily show what is being sent to or from a
remote system using the following commands:
# iptrace -p printer -a -b -s source_host -d dest_host /tmp/trace.out
-p printer (use the word printer) says look at port 515 only.
-a means suppress ARP packets
-b means change the -d and -s to bidirectional mode (optional)
-s where the print command is issued
-d system where the printer is
Print the job to the remote queue
# enq -Pqueue_name filename
Now find the process id (PID) for the trace
# ps -ef | grep ipt
Kill the trace command's PID
# kill pid_no
Now format the output so we can read it. The report contains three or
four parts for each packet of data. These are the 'MAC' header, the
'IP' header, the 'TCP' header, and the data. The MAC header doesn't
supply much information useful to debugging printing. The IP header
gives us the direction of the data flow, but this is also given in the
TCP packet. The TCP packet gives us direction, handshaking, and packet
identification.
The data packet shows the actual data that is sent back and forth.
# ipreport /tmp/trace.out > /tmp/report.out
The data packets contain queue names, command information, actual data
to be printed, print flags, and also error messages back from the
remote system lpd. It often simplifies the reading of the data to
extract the data from the other packets. This is usually quite easy
to do because all data lines of importance begin with at least 4 zero's.
# grep 0000 /tmp/report.out > /tmp/datasent.out
The size of this file will greatly depend on the size of the data file
being printed. For this reason, I like to start with a small file
when I am testing. A useful command is:
$ echo "AAAAA" | qprt -Pqueue_name
A PostScript output might look something like this:
¢data hex equivalent of the characters ASCII equiv. of
¢byte in sent to the remote host the characters.
¢packet
00000000 020405ac |.... |
00000000 020405ac |.... |
00000000 0268705f 706f7374 0a |.hp_post. |
00000000 00 |. |
00000000 03363433 36382064 66413132 30746573 |.64368 dfA120tes|
00000010 63680a |ch. |
00000000 00 |. |
00000000 04252150 532d4164 6f62652d 332e300d |.%¢PS-Adobe-3.0.|
00000010 0a252543 72656174 6f723a20 57696e64 |.%%Creator: Wind|
00000020 6f777320 50534352 4950540d 0a252554 |ows PSCRIPT..%%T|
00000030 69746c65 3a20524f 444e4559 322e574b |itle: RODNEY2.WK|
00000040 330d0a25 25426f75 6e64696e 67426f78 |3..%%BoundingBox|
00000050 3a203138 20392035 39332037 38340d0a |: 18 9 593 784..|
00000060 2525446f 63756d65 6e744e65 65646564 |%%DocumentNeeded|
00000070 5265736f 75726365 733a2028 6174656e |Resources: (aten|
'hp_post' was my remote queue name.
'tesch' was my local host name.
Obviously this is a postscript file %¢PS-Adobe-3.0.
Some of the things to look for in the output are:
There is always an initial handshake protocol that seems to look like:
00000000 020405ac |....
00000000 020405ac |....
The middle column always starts 02; still working on the rest.
In general, lines like the following indicate a positive
acknowledgment:
00000000 00 |. |
One of the first lines in the file will be the queue name:
00000000 02617363 0a |.asc. |
..
Notice in the middle column that this begins with 02; this is a flag
to indicate that this is the start of a command sequence with the
queue name.
A status request for a queue would start with an 03:
00000000 03617363 20200a |.asc . |
A short distance down the file a line will contain the temporary file
name:
00000000 03353120 64664132 31396169 786e7473 |.51 dfA219aixnts|
In this case it begins with '03' in the middle column for 'data file'.
The 51 in the 3rd column indicates the number of bytes in the file.
The file name starts with 'df' for data file.
The job number is the next part of the data file '219'.
The last part of the file name is the sending host name 'aixnts'.
The next packet of data from the client to the server will be the data
file itself. Check this file for extraneous characters, line feeds,
spaces, tabs and other things that might affect the format. The data
in the right hand column should be exactly what was on the client:
00000010 31323334 35363738 393a3b3c 3d3e3f40 |123456789:;<=>?@|
00000020 41424344 45464748 494a4b4c 4d4e4f50 |ABCDEFGHIJKLMNOP|
00000030 51520a |QR. |
The next packet from the client is usually the control file name:
00000000 02313130 20636641 32313961 69786e74 |.110 cfA219aixnt|
00000010 730a |s. |
Again the subcommand for control file begins with '02' in the middle
column. The number of bytes is shown in the right column as '110'. The
name starts with 'cfA', and is job number '219' from host 'aixnts'.
The following packet will be the actual control file:
00000000 48616978 6e74730a 506a7774 65736368 |Haixnts.Pjwtesch|
00000010 0a666466 41323139 6169786e 74730a55 |.fdfA219aixnts.U|
00000020 64664132 31396169 786e7473 0a4e5354 |dfA219aixnts.NST|
00000030 44494e2e 36333834 350a2d4e 310a2d5a |DIN.63845.-N1.-Z|
00000040 6a777465 73636840 6169786e 74730a2d |jwtesch@aixnts.-|
00000050 746a7774 65736368 40616978 6e74730a |tjwtesch@aixnts.|
00000060 2d545354 44494e2e 36333834 350a |-TSTDIN.63845. |
Haixnts shows the Hostname of the client.
Pjwtesch shows the user identification
fdfA219aixnts shows the file to print.
UdfA219aixnts
NSTDIN.63845 shows the origin of the file
-N1 says make one copy
-Zjwtesch@aixnts
-tjwtesch@aixnts
-TSTDIN.63845
Error messages from the remote system usually show as text in the right
hand column.
For example using a bad backend I got the following message:
00000000 30373831 2d323031 20696c6c 2d666f72 |0781-201 ill-for|
00000010 6d656420 46524f4d 20616464 72657373 |med FROM address|
00000020 2e |. |
Sending data to a nonexistent queue on a remote machine gave:
00000000 756e6b6e 6f776e20 7072696e 74657220 |unknown printer |
00000010 62616471 2e |badq. |
where 'badq' was the name of the queue I tried to send to.
Mail message for this was:
Message from qdaemon:
Device stimpy:dstimp died running request test.file which is still
queued.
and
Message from qdaemon:
/usr/lpd/rembak -S stimpy.aix.dfw.ibm.com -P badq -N /usr/lpd/aixshort
/tmp/test.file
Another common error for remote printing is shown here:
00000000 30373831 2d323032 20796f75 7220686f |0781-202 your ho|
00000010 73742064 6f657320 6e6f7420 68617665 |st does not have|
00000020 206c696e 65207072 696e7465 72206163 | line printer ac|
00000030 63657373 2e |cess. |
mail messages:
Message from qdaemon:
rembak: (FATAL ERROR): Could not send datafile /tmp/test.file.
Message from qdaemon:
/usr/lpd/rembak -S vulcan.aix.dfw.ibm.com -P badq -N /usr/lpd/aixshort
/tmp/test.file
Message from qdaemon:
Device stimpy:dstimp died running request test.file which is still
queued.
Message from qdaemon:
rembak: (FATAL ERROR): Could not send datafile /tmp/test.file.
Harder ones to find include 'unable to create file'.
S e a r c h - k e y w o r d s:
CROSS PSF AIX PSF/6000 PSF/AIX OS/400 AS/400 INCORROUT EXTRANEOUS
iptrace direct tcp/ip
WWQA: ITEM: RTA000099378 ITEM: RTA000099378
Dated: 11/1998 Category: XPSF6000
This HTML file was generated 99/06/24~12:43:33
Comments or suggestions?
Contact us