Hmm,
I'm still trying to find a Solaris Box to play with, LPRng uses an extended lpd
protocol, to provide things like accounting, and 2 things pop to mind:
1) the Solaris box has a sloppy parser for its control files, causing the LPRng
extensions to screw it up,
or
2) the Solaris box has its OWN lpd extensions, which LPRng interacts badly with.

I will keep looking, but if this is critical to you (and it probably is, sigh)
you uninstall LPRng, and can install the old lpd daemon from 6.2 (I would
strongly suggest the latest errata (lpr-0.50-7.rpm), and all it's friends (the
6.2 tree's printtool, and rhs-printfilters).

If THAT doesn't let you print, then something is bad wrong.

I'm not sure if this is the same problem?

Remote printing via the lpd deamon running under SunOS Release 4.1.3_U1 has been
working fine for us for years under previous releases (5.2 and 6.1).  Now, with
7.0 installed, printing is fine to the Xerox device (as queue lpxf) but nothing
happens on the HP Laserjet device (4050N as queue lp2)    

And yes, I have read the release notes under 7.0 and rebuilt /etc/printcap using
the new printtool.  I have tried every variation of printcap options to the HP
device I can imagine, to no effect.  For the purposes of this report, I have
used the same basic postscript setting for both printers.

##PRINTTOOL3## REMOTE POSTSCRIPT 1200x1200 a4 {} PostScript Default {}
lpxf:\
        :sd=/var/spool/lpd/lpxf:\
        :mx#0:\
        :sh:\
        :rm=manta.vic.cmis.csiro.au:\
        :rp=lpxf:\
        :lpd_bounce=true:\
        :if=/var/spool/lpd/lpxf/filter:
##PRINTTOOL3## REMOTE POSTSCRIPT 1200x1200 a4 {} PostScript Default {}
lp2:\
        :sd=/var/spool/lpd/lp2:\
        :mx#0:\
        :sh:\
        :rm=manta.vic.cmis.csiro.au:\
        :rp=lp2:\
        :lpd_bounce=true:\
        :if=/var/spool/lpd/lp2/filter:

Under 7.0, after printing, lpq returns:

  [root@redfin-vt rh6.2]# lpq -Plp2
  Printer: lp2@redfin-vt (dest lp2.cmis.csiro.au)
   Queue: no printable jobs in queue
   Status: job 'root@redfin-vt+523' removed at 09:18:02.739 

So, there appears to be communication between the local and remote lpd daemons
(this is the same message as returned oin the lpxf queue where printing works). 
However, nothing prints when I use the printtool postscript test option or lpr
directly.

Unfortunately, I do not administer the Sun machine, so have limited access to
what is going on on that side.  Certainly no errors are reported.  It does seem
that the print job is not showing up on the remote print logs though.

Further on the HP Laserjet issue.  Following crutcher's suggestion, I
just reverted to the rh6.2 lpr rpms and printing works fine now.

I note the following entries on the Sun lpr log:

I'm not sure, (timestamp doesn't match) but I think this may have been produced
by an attempt to print using the 7.0 LPRng setup:

Debug /usr/local/etc/printers/print_hplj:  User root at Wed Oct 25 14:43:03 DST
2000
Debug /usr/local/etc/printers/ditautoscan:  $_:  ;      24.194.138.in-addr.arpa
Debug /usr/lib/hpnp/hplj.if.sh.dit:  $FORMAT:  TEXT 

I believe a format of "TEXT" will not print on the HP Laserjet 4050N, so that
could be part of the story.  The other part is what the hell is
"24.194.138.in-addr.arpa" doing there?  Our subnet here is 138.194.24 by the
way.

With the 6.2 LPR setup, a working remote entry is:

Debug /usr/local/etc/printers/print_hplj:  User root at Thu Oct 26 10:36:35 DST
2000
Debug /usr/local/etc/printers/ditautoscan:  $_:  %!PS-Adobe-2.0
Debug /usr/lib/hpnp/hplj.if.sh.dit:  $FORMAT:  PS

Which looks rather better.

Hope this helps.

I reverted to lpr from 6.2 too, and it works fine.

My guess (but I haven't find anything to support that claim) is that
Sun's lpd extensions and LPRng extensions do not mix well; is there
any way to make LPRng work in "plain" lpd mode ?

Additional comment, posted at the suggestion of RH support.
I have similar problems with RH7.0 printing via LPRng. I am upgrading an RH6.1 server 
that prints to a variety of networked printers. LPRng works fine printing to laserjets and 
deskjets on HP JetDirects (either way, lpd or direct port 9100). But it fails to print to 
an Oce printer which uses a closed DAC (digital access controller) box for lpd (the 
Ikon service guy says its just an OS2 box with Oce's software). Also failing to print is 
a postscript printer served by lpd on an old Sparcstation running SunOS4.1.3. 
Just to note: Up until now, all the lpr/lpd boxes can print among themselves 
(RH6, SunOS, NT4, Solaris, Macs with lpr-enabled Laserwriter drivers, Win2k, ...). 
OnlyRH7.0 with LPRng won't work.

When RH7 tries to print to SunOS4, there is an lpd log entry that the RH7 box 
"requests recvjob"; an email is sent to root@RH7 from daemon@SunOS with this 
message: "Your printer job (/usr/lib/rhs/rhs-printfilters/testpage.ps) could not be printed."
No other indications are given. 

LPRng HOW-TO section 4.33 has the answer to my problem. Add the "bk" flag to printcap for the old 
bsd-style lpd printers. This flag makes LPRng send a backward compatible control file to the lpd.
Above printers now printing.

Let me just recall (see my first posting) that I tried "bk" and it did
not work. So this is not a "universal" workaround (but of course,
it is worth trying).

the ability to set this flag is in the new printconf system.