tundra@ux1.cso.uiuc.edu (John Kemp) (10/02/90)
We are trying to print from an AIX system to an HPUX
system. The file names that end up in the HP spool
directory are mysteriously truncated. For example,
the spool control file should have a name like
"XXXxxxozone.atmos.uiuc.edu". Instead it has a name like
"XXXxxxozon".
Since this behavior does not occur when remote printing is
done from a Sun, I tend to think the IBM is at fault.
Does anyone know how or where to change the parameters
that the IBM passes to a remote printer which end up
in the remote spool file? (say that three times fast)
Thanks in advance,
-------- john kemp ( ( )_ internet - kemp@uiatma.atmos.uiuc.edu
----- ( ( __) decnet - uiatmb::kemp
--- univ of illinois (_ ( __) bitnet - {uunet,convex}
-- dept of atmos sci .(____). !uiucuxc!uiatma!kemp
- 105 s gregory ave ... phone - (217) 333-6881
- urbana, il 61801 ... fax - (217) 444-4393
***** IBM SIDE *****
/usr/lpd/qconfig:
lp:
s_statfilter = /usr/lpd/bsdshort
l_statfilter = /usr/lpd/bsdlong
device = rp0
up = TRUE
host = uiatma.atmos.uiuc.edu
rq = lp
rp0:
backend = /usr/lpd/rembak
command used:
$ lpr -Plp testfile
***** HP SIDE *****
NOTE: the truncated spool file name "ozon" appears in the spool cf file
and as part of the spool file name
/usr/spool/lp/request/lp/cfA044ozon:
Hozone.atmos.uiuc.edu
Pkemp
J/usr/spool/qdaemon/tO5EDaw
Cozone.atmos.uiuc.edu
Lkemp
B
K1
O -oBSDJ/usr/spool/qdaemon/tO5EDaw -oBSDCozone.atmos.uiuc.edu
FdfA044ozon
fdfA044ozon
UdfA044ozon
N/usr/spool/qdaemon/tO5EDaw
/usr/spool/lp/request/lp/dfA044ozon:
this is a test of IBM to HP lpr remote printing...
/usr/spool/lpd.log:
rlpdaemon: ozone.atmos.uiuc.edu requests recvjob lp
NOTE: the fully qualified name in the lp request causes the error
/usr/spool/log:
lp-44 smith lp Oct 1 17:10
lpsched: Unable to open and lock
"request/lp/cfA044ozone.atmos.uiuc.edu"Kimmo.Suominen@lut.fi (Kimmo Suominen) (10/02/90)
First of all: ask your local HP support for the "FTP Software PC/TCP
lp patch". I *think* it should solve your problem. I've been using
the patch (totally new lp spooler system) for about a month now
without problems. Note: It is UNSUPPORTED currently. It is for
HP-UX version 7.0.
I am currently trying to find out whether I can release the patch
under anonymous ftp on lut.fi and nic.funet.fi. My case is now
pending at the local support. I already got an answer after 10
minutes of waiting, and it seems like it would be ok to release the
patch. I will remove it without notification, if it appears to be in
conflict with licenses etc.
The patch is now available under anonymous ftp on lut.fi as
/unix/hp-patches/lp-patches.shar.Z
If you would like to know more, then read on.
>>>>> On 1 Oct 90 22:35:57 GMT, tundra@ux1.cso.uiuc.edu (John Kemp) said:
John> /usr/spool/lp/request/lp/cfA044ozon:
John> Hozone.atmos.uiuc.edu
John> Pkemp
John> J/usr/spool/qdaemon/tO5EDaw
John> Cozone.atmos.uiuc.edu
John> Lkemp
John> B
John> K1
John> O -oBSDJ/usr/spool/qdaemon/tO5EDaw -oBSDCozone.atmos.uiuc.edu
John> FdfA044ozon
John> fdfA044ozon
John> UdfA044ozon
John> N/usr/spool/qdaemon/tO5EDaw
Now this control file is just perfect! 'f' is the file to print etc.
John> NOTE: the fully qualified name in the lp request causes the error
The remote (AIX) machine requests to store a file cfA044ozon. The
HP-UX rlpdaemon does this. So far so good.
BUT THEN: rlpdaemon requests lpsched to print out a request from the
control file cfA044ozone.atmos.uiuc.edu! Somewhere the rlpdaemon
logic is broken. This results in the following error log entry:
John> /usr/spool/log:
John> lp-44 smith lp Oct 1 17:10
John> lpsched: Unable to open and lock
John> "request/lp/cfA044ozone.atmos.uiuc.edu"
PC/TCP requests everything without the domain appended in the files.
But it tells its whole domain name as its identification. HP-UX's
rlpdaemon has an error in it, which assumes that the files have the
fully qualified domain name in them EVEN THOUGH THE REQUEST IS MADE
AND FILES STORED WITH THE SHORT NAME.
The above mentioned patch corrects this problem among other things.
Please REMEMBER: IT IS TOTALLY UNSUPPORTED BY HP! Oh, and I don't
support it either, I just offer to distribute it under anonymous ftp.
--
Kim / Internet: Kimmo.Suominen@lut.fi
"That's what I think." / Bitnet: KIM@FINFILESlienhart@hpfcdc.HP.COM (Bob Lienhart) (10/02/90)
>We are trying to print from an AIX system to an HPUX >system. The file names that end up in the HP spool >directory are mysteriously truncated. For example, >the spool control file should have a name like >"XXXxxxozone.atmos.uiuc.edu". Instead it has a name like >"XXXxxxozon". There are two problems that are probably showing up here. First, the HPUX system must be converted to long filenames, otherwise the control filename will be truncated to 14 chars. (I do not understand why yours seems to be truncated at 10 chars). At a minimum, the disk containing /usr/spool/lp must be converted to long filenames. Second, there are several problems showing up with the 7.0 HPUX spooler when used in conjuction with either named or ypserv. These are being looked into at the present time. After re-reading the basenote, I have a question about the request control file. Would you please add a long listing (ls -l) of /usr/spool/lp/request/lp on the HPUX system? There is a problem with user "lp" submitting requests which result in the error "lpsched: Unable to open and lock request . . . ". But I have not seen it happen remotely. If your control file appears owned by root instead of lp, then there is a third problem--this one on the HP system. Bob Lienhart
tundra@ux1.cso.uiuc.edu (10/05/90)
Yup. It was a BUG in the HP software.
If you are having problems with "lpr" to an HP
I highly recommend getting the patch or waiting
for system 8.0.
Thanks to Kimmo in Finland for pointing this out.
(I wish HP would let their customers and engineers
know about these patches. HP is great, but sometimes
this kind of thing can be irritating.)
Thanks to all who replied...
-------- john kemp ( ( )_ internet - kemp@uiatma.atmos.uiuc.edu
----- ( ( __) decnet - uiatmb::kemp
--- univ of illinois (_ ( __) bitnet - {uunet,convex}
-- dept of atmos sci .(____). !uiucuxc!uiatma!kemp
- 105 s gregory ave ... phone - (217) 333-6881
- urbana, il 61801 ... fax - (217) 444-4393kemp@uiatma.atmos.uiuc.edu (John Kemp) (10/05/90)
One other thing about using LPR on the HP.
Another well know bug is that "inetd" does NOT
start "rlpdaemon". So you have to start it
from your "rc" file or manually.
So 1)
/usr/lib/rlpdaemon in /etc/rc
2)
get the lp/rlpdaemon patches from HP
(or ftp from 128.214.25.8 lut.fi if you can
trust putting ftp'd binaries on your system)
Of course, there is always the "remsh", and "rcp"
method, but that would be cheating.
-------- john kemp ( ( )_ internet - kemp@uiatma.atmos.uiuc.edu
----- ( ( __) decnet - uiatmb::kemp
--- univ of illinois (_ ( __) bitnet - {uunet,convex}
-- dept of atmos sci .(____). !uiucuxc!uiatma!kemp
- 105 s gregory ave ... phone - (217) 333-6881
- urbana, il 61801 ... fax - (217) 444-4393lienhart@hpfcdc.HP.COM (Bob Lienhart) (10/06/90)
>One other thing about using LPR on the HP. >Another well know bug is that "inetd" does NOT >start "rlpdaemon". So you have to start it >from your "rc" file or manually. inetd WILL start rlpdaemon if you add the following line to your /etc/inetd.conf file: printer stream tcp nowait root /usr/lib/rlpdaemon rlpdaemon -i -l Note: The -l (little-L) option turns on logging to the default /usr/spool/lp/lpd.log file. Then execute inetd -c to force inetd to re-read the /etc/inetd.conf file. Bob Lienhart
Kimmo.Suominen@lut.fi (Kimmo Suominen) (10/06/90)
>>>>> On 4 Oct 90 20:08:53 GMT, kemp@uiatma.atmos.uiuc.edu (John Kemp) said:
John> Another well know bug is that "inetd" does NOT
John> start "rlpdaemon". So you have to start it
John> from your "rc" file or manually.
I have to disagree here. Inetd has always started rlpdaemon on lut.fi
- even before I installed any patched software. All you need is the
following line in /etc/inetd.conf
# Added by Kimmo Suominen
printer stream tcp nowait root /usr/lib/rlpdaemon rlpdaemon -i -l
It seems to have my note on it, so it wasn't there when shipped.
However, it is documented in the manual page for rlpdaemon.
The -i is essential so that rlpdaemon will exit after having finished
with the request, that caused inetd to start it.
The -l stands for logging (/usr/spool/lp/lpd.log). You don't need it
if you don't want to see who's using your printers. Actually it is
quite useless, but then again, it is of much help in problem cases.
John> So 1)
John> /usr/lib/rlpdaemon in /etc/rc
Of course you can start rlpdaemon as a stand-alone daemon as John
suggested. I didn't choose to do so, because lut.fi's print services
are not very often used by other machines.
John> 2)
John> get the lp/rlpdaemon patches from HP
Doesn't really have anything to with inetd starting the rlpdaemon.
And if you haven't experienced any other trouble, then I'd suggest you
stick to the supported stuff shipped by HP.
John> (or ftp from 128.214.25.8 lut.fi if you can
John> trust putting ftp'd binaries on your system)
I'd trust me ;-) Anyhow, the binaries haven't been modified in any
way by me. It is the very same package I received from HP.
Because lut.fi has the time restriction I mentioned, I copied the
patch over to nic.funet.fi, so you can reach it in either place. On
nic.funet.fi it is called /pub/unix/hpux/hp-patches/lp-patches.shar.Z
--
Kim / Internet: Kimmo.Suominen@lut.fi
"That's what I think." / Bitnet: KIM@FINFILES