ITEM: G3752L

Unable to remote print, but can local print on both hosts.




Question:

I have two machines.  Machine 1, a 220,  is running 3.2.3 and is
physically connected to an HPLJ3P and machine 2 is connected through
ethernet to Machine 1.  I have set up my remote queues through smit.
When I do an lpstat command, I get the remote queues going from ready
to host is down.  I think I have set something up incorrectly, what
should I do?

Response:

You called back in.  We checked to see if the lpd daemon was running
on your print server.  It was not.  We started it (via smit, spooler,
remote printer subsystems, server services, lpd services, start lpd)
and now the client's lpstat looks "ready".

Response:

You called back in.  While the lpstat ouput looks good, nothing gets
printed when sent through the remote queue.

We did the classic:

        1) stopsrc -s qdaemon         2) rm /var/spool/lpd/stat/*
        3) rm /var/spool/qdaemon/*         4) rm /var/spool/lpd/qdir/*
        5) startsrc -s qdaemon

Followed by a delete then readd of the remote queue.  We checked
/etc/hosts.lpd - remote host was listed on server.  /etc/hosts.equiv
on server did not have the remote host.  Both machines have been
rebooted within the last 24 hours.  TCP/IP seems to be working fine
between the machines.  The server is printing local jobs to the
printer in question.

We get NO error messages.  We do need to determine if you are sitting
at the console or not.  If not  you need to get to the console to
watch for error messages.

Response:

We removed both remote queues you had defined and readded them.  You
defined an asc queue and a postscript queue.  We tried sending a job
to the asc queue.  We did see the job queued on the client but not on
the server.  Someone else was running a local print job on the server
but ours did not get queued on the server.

We checked for messages in the /var/spool/lpd/pio directory.  The only
msgX files there were from July....

We checked the server's /etc/host.lpd file.  The client's hostname was
listed (not using domain nameserving at all).  It was.  We added a
line with the client's internet address.

qdaemon is running on the client.  /etc/qconfig and /etc/qconfig.bin
have the same time stamp.

We followed the procedure in
/public/support/aix/printers/howto_trace_remote_printing.  Data is
being sent to the server.  There was nothing at the BEGINNING of
the trace of interest.  We should have looked at the end after the
data, but didn't do this.

Response:

We closed down the local queue, and then sent remote jobs.  They
get queued with no problem.  When we enable the queue the jobs go
away without getting printed.  We found that we were able to send
local jobs with no problem.

We also were able to send a remote postscript job with no problems to
the postscript queue.  What is different here is that the printer is
by default in a 'ps ready letter' status.  The print process is a
little more complicated than at first glance.  To print an ascii file,
three files actually get printed.  These are 1 file to put the printer
into pcl (ascii) mode, 2:  the actual file, and 3: a file to put the
printer back into ps mode.  

We took the queue down, and printed all 3 jobs from the remote system.
We captured the jobs in /var/spool/lpd where they were waiting and put
them in /tmp/newname1...  We then enabled the queue and the jobs went
away.  We then printed /tmp/newname1 and the printer was no longer in
ps mode.  We then printed /tmp/newname2 and the file printed just fine.
We then printed /tmp/newname3 and the printer went back into ps mode.
This appears to be a timing problem or something is getting stripped
during the piobe processing.

We created a new virtual printer type with the commands that appeared in
these conversion files and tried printing to this and trapped the commands
and compared them to the original file.

Catting both files to the screen they appeared identical, but diff showed
they were different.  ls -l on the file showed the one sent by the script
they use has 9002 or more bytes, while our file created by the virtual
printer had all the printing characters, but was only 64 bytes long.  It
appears that they send a bunch of nulls.  This can be added to a 
virtual printer definition as defined in the last section of this item.
Plan of attack:

1.  Will 'lpr -h -Prque file' or enq -Bnn -Prque file   print
        If they do this is a known problem needs IX29407.
2.  We can build a queue that simply cat's the file the file on
        the printer host (local system) and then enq's as a local file.
    - create directorys for path /tmp/var/spool/lpd with 777 permissions
    - create queue with following stanzas
      catq:
        device = lxx
        up = TRUE
      lxx:
        file = FALSE
        backend = /bin/sh /bin/catq.sh
    - create /bin/catq.sh
        enq -Ppclque ps2pcl        ! send file to send printer to pcl
        cp $1 > /tmp$1             ! Make temporary copy of file
        enq -c -Ppclque /tmp$1     ! print temp file with copy option
        rm /tmp$1                  ! Remove temp file.
        enq -Ppclque pcl2ps        ! Shift printer back to postscript
        !  The -c option on enq creates a copy of the file so we
                can erase our temp copy.
3.  Do an lptrace to see if anything is getting sent back to the remote
        system when printing fails.  See /public/support/aix/printer dir
        for howto_trace_remote_printing for directions.
4.  Change filters to aixv2short/aixv2long.
5.  Defect Support records show similar problems at levels of the OS
        including pmr 230x4, U409579, IX29407, IX19305, IX20609
                (IX28687 for 3.2 systems), IX20879
        $\#@!-Hhighfive that shows up in the control file.

I am faxing him some ideas to try.

Response:

This morning we tried the enq -Bnn file, but it still did not print.
We discussed the custom backend workaround.
Next we ran the iptrace based on my fax.
Inside the trace after the users file data we found the following:

msg from qdaemon:  Job 675 /etc/group cannot create file .0782-029
cannot create file /tmp/shared.pcl:lp0.  errno from operating system
call is 13.  use local problem shooting techniques.

We checked the permission on /tmp and it was drwxr-xr-x on both systems.
We changed this to drwxrwxrwx and then the remote printing started to
work.

Customer requested copy of this record.  I am also going to FAX a copy
of a how_to_change_ps_to_pcl for a HPLJ-III. (HPLJ3).

R: The following is additional information I found on how to obtain the
mode switching function on the HP LaserJet III and the HP LaserJet III-Si.

1. Enter 'smit virprt'  or 'lsvirprt' from the command line.
    Select 'Change/Show Characteristics of a Virtual Printer'
     Choose the appropriate Queue for hplj-3 (PCL)
      Enter '~v'   (This allows you to enter the colon file in the
                    /var/spool/lpd/custom directory for editing.)
   Now, you will need to insert the 'ez' attribute.
   ***NOTE*** The ez attribute is usually not included in
   the colon file of PCL.  So, the label number and attribute data
   needs to be inserted.  You should scroll down and try to insert
   the attribute in an appropriate group and numbering system of the
   colon file to easily locate this for future reference:

   The following data for the ez attribute

      %{9216}%Px%{100}%Py\\33%%-12345X%wx\\0%;\\33%%-12345X@PJL
      ENTER LANGUAGE=PCL\\12%wy\\0%;

   is included in the colon file as

    :263::ez:%{9216}%Px%{100}%Py\\33%%-12345X%wx\\0%;\\33%%-12345X@PJL ENTER
    LANGUAGE=PCL\\12%wy\\0%;

2. Now, look for the ci attribute.  It should be labeled 144.  The
   ez needs to be included.  The ci attribute will need to be changed
   from something like:

   :144:ci::%?%G_j%{1}%=%t\\33E %I[eP,c1,eT,eS,eO,ct,eF,es]\\33&l%{48
   0000}%Gwn%/%Pq%gq%{100}%/%d.%gq%{100}%m%2dC%;

   to

   :144:ci::%?%G_j%{1}%=%t\\33E %I[ez,eP,c1,eT,eS,eO,ct,eF,es]\\33&l%{4
   80000}%Gwn%/%Pq%gq%{100}%/%d.%gq%{100}%m%2dC%;

3. Now, exit the colon file.  You should repeat "step 1." for hplj-3
   (Postscript).  The ez attribute needs to be inserted as the
   following:

   :263::ez:%{9216}%Px%{100}%Py\\33%%-12345X%wx\\0%;\\33%%-12345X@PJL ENTER
   LANGUAGE=POSTSCRIPT\\12%wy\\0%;

4. The ci attribute needs to be modified to look like:

   :144:ci::\\33E%Iez

5. Now, look for the j attribute.  The j attribute needs to be set to
   yes.  Therefore the j attribute should look like:

   :076:_j::1

Additionally, if the printer is a HP LaserJet IIIsi, then the above
steps can be used with the following exceptions:

    For HP-LJ3si PCL, the ez attribute needs to look like the
    following:

               :263::ez:\\33%%-12345X@PJL ENTER LANGUAGE=PCL\\12

    For HP-LJ3si POSTSCRIPT, the ez attribute need to look like the
    following:
               :263:ez::\\33%%-12345X@PJL ENTER LANGUAGE=POSTSCRIPT\\12

The sequence code for the the HP LaserJet III was obtain from the
HP Technical Support Center.  If further assistance is needed, you
may wish to contact the HP Technical Support Center at
1-208-323-2551.


Support Line: Unable to remote print, but can local print on both hosts. ITEM: G3752L
Dated: February 1994 Category: N/A
This HTML file was generated 99/06/24~13:30:50
Comments or suggestions? Contact us