PSF/AIX: What is needed to set up queue to convert PCL
ITEM: RTA000136017
Q:
ABSTRACT: What steps are needed to set up a queue to convert PCL
files and print them on a 3900?
SEARCH ARG: psf/aix pcl queue
TOPIC THREAD: PRINT
PSF/AIX
..
We are trying to set up a PCL queue on PSF/AIX to print to a 3900-DWx.
We are able to convert a PCL file using the sample script, but we want
to set up a queue so that eventually people on the LAN can print to the
queue. I think the manual (Print Administrator's Guide for PSF/AIX)
doesn't match the version of AIX we are running. We tried both the
mklque and mkpq commands, and we don't get the screen described in
the book. We get a window that says "Set up a Print Queue" instead of
"Set up a Local Queue" as the manual says. We select the Other/Backend
option from the list of local, remote.... We fill in the queue name
(netpcl), the device (we tried dev1 and dev11 since we really don't
know what that's for), filled in the backend process per doc with
printername as 3900S1 (3900 simplex printer) and set activate to yes.
When we display the queue, it says ready. We tried enq -P netpcl pclfn
and the job goes to that queue. The queue status says DOWN (sometimes
it says INITING). We found the conversion messages and it says the
transform was successful and 22 pages were generated, but they just
sit in the queue and don't go to the 3900S1 printer queue (which says
READY). Are we missing something? When we display all the queues, some
of them say: 3900S1 dev1 3900S1 dev2 3900S2 dev3...Our queue does
not have a dev# after it. Should that be there? We tried to manually
move the file from the netpcl queue to the 3900S1 queue, but that queue
went to DOWN or INITING status and the file still didn't print.
A:
You didn't tell me what level of AIX you do have, so I can only tell
you what I'm seeing on an AIX 4.1.4 system. (You can type oslevel
at an AIX command prompt to see what level AIX is installed.)
Note that you should not make changes or add printers while any printing
is going on in the system; we don't want things to get out of sync for
the AIX qdaemon (although there is now an AIX print PTF that will help
alleviate this problem; contact AIX Support for details).
It sounds like you got the right window by issuing the mklque (make
local queue) or mkpq (make print queue) command, even if the panel
titles appear different. You were right to pick "Other". On my
system, that brings me to a panel entitled "Add a Print Queue". There
are three required fields as indicated by an asterisk in the leftmost
column. You didn't give me all the information on what you filled in
so let me state what it should be (using the names you provided):
* Name of QUEUE to add netpcl
* Name of QUEUE DEVICE to add dev1 (name really doesn't matter)
* BACKEND PROGRAM pathname (let me put this below since I need
more room)
The full BACKEND PROGRAM pathname should be:
/usr/lpp/psf/bin/ainbe 3900S1 datatype=pcl formdef=F100S
It's very important that you remember to include "3900S1", which is the
PSF/AIX printer name you defined when you configured the initial
PSF/AIX 3900 queue.
The formdef is optional, but since we recommend that you print PCL
using a formdef with a 0,0 offset, it's easiest to put the appropriate
default formdef in the backend.
When you complete the entries and hit enter, you should get a message
back that it:
"Added queue 'netpcl'."
"Added queue device 'dev1'."
Then when you display your queues, this printer should look like:
Queue Dev Status Job ....
------- ----- --------- --------
netpcl dev1 READY
If you "tail /etc/qconfig", you should see the entry for this printer
as:
netpcl:
device = dev1
up = TRUE
dev1:
backend = /usr/lpp/psf/bin/ainbe 3900S1 datatype=pcl formdef=F100S
As a test, try printing the sample file (awful as it is) to this queue:
enq -Pnetpcl /usr/lpp/psf/pcl2afp/sample.pcl
When you display the queue status, you should first see the queue
INITING, then RUNNING. The job will stay on the netpcl queue until
it is finished and stacked on the 3900 printer; it will not move to
the 3900S1 queue in the display. Of course, this occurs because on
the backend program pathname you're really pointing to the 3900S1
PSF print queue.
One very important item to check is the availability of spool space.
AIX uses /var as spool space, and PSF/AIX by default uses it for much
of its workarea (like for the PCL transform). If there is not sufficient
space in /var, jobs will not print. The default for new AIX systems
is only 4MB and that is not enough. To check the current size, at
an AIX command prompt, type:
df -k /var
This will show you the number of 1024-byte blocks that are currently
allocated and that are free. For example, if it says the number of
1024-blocks is 20480, that means /var has been allocated about 20MB.
Likewise, if Free=16820, there's about 16MB free. The best size for
/var depends on the customer's data and requirements, but I'd
recommend 50-100MB. PSF/AIX really uses a subdirectory of /var
(/var/psf), and if the customer doesn't want to make /var that large,
an alternative is to create a new filesystem for /var/psf. The AIX
Support Center has a fax on how to do this on a system that already
has PSF/AIX installed (1-800-CALL-AIX).
If your customer will be doing a lot of PCL printing to the 3900, you
will want to add additional queue devices to the netpcl queue. This
will allow greater throughput; one queue device can be printing while
another is transforming the PCL to AFP. In other words, PSF/AIX can
be working on or preparing more than one job at a time. The fastpath
to add additional queue devices (at least on 4.1.4) is "mkpqprt".
For your second queue device, you would specify dev2 as the "Name of
DEVICE to add" and netpcl as the "QUEUE to which to attach device".
You would enter the same "BACKEND PROGRAM pathname" as you did above.
I hope this helps. If you need additional assistance, please provide
the level of AIX you're running, the level of PSF maintenance installed
(from the root directory type "lslpp -h psf.\*"), the relevant entry
from /etc/qconfig, and any pertinent error numbers and messages.
Q:
Ok, we got this working, although I don't think anything was different
than the first time. Maybe we had something active before and that
caused us problems. The next step for the customer that I need some
direction on is that they want their LAN Windows users to be able to
route PCL and PostScript (we also set up a postscript queue) files to
the RS/6000 and the 3900. Where is the best place to find documentation
on what needs to be done at the user workstation and the current lan
print server? Are there some ASKQ items to review? Thanks for
your help. Oh, they are on AIX V4.1.5.
A:
You mention a LAN print server, but not what kind. Is it Novell,
Windows NT, LAN Server, LAN Manager, or something else? Does that
LAN print server have TCP/IP (specifically remote print support, i.e.,
LPR)? Does the customer want all user print requests going through
the print server, or does s/he want the users to route output directly
from their workstations to the PSF/AIX queues? If the latter, do the
individual user workstations have TCP/IP installed, and if so, whose
package? (If this latter is the case, setup instructions will be
vendor-dependent, and you would need to refer to that product
documentation for setting up remote queues.)
If you can get this additional information, I can try to help. There
really isn't a lot of documentation in this area, but we'll do the best
we can.
Q:
Ok, I got some more information from the customer. The users do have
TCP/IP on their workstations. Also, they go thru a Windows NT LPR.
They said that NT will only talk to an LPD daemon. They tried to
direct the files to the RS/6000, but they don't arrive. What needs
to be done on the RS/6000 side other than define the 2 queues? Is
there an LPD that has to be started and how do we start it.
A:
On AIX, you will need to start the LPD daemon if it's not already
started and then grant the remote NT client(s) access to LPD. In
smit, you can get to the "Manage Print Server" panel by the fastpath
"smit server".
From this panel you can Show the Status of the Printer Server Subsystem
to query if LPD is running and you can Start the Print Server Subsystem
(lpd daemon) if it is not. You must perform this operation as root.
Also from this panel you List all Remote Clients with Print Access and
Add Print Access for a Remote Client. This information will be stored
in /etc/hosts.lpd. It is possible to grant global LPD access for all
remote print clients by specifying a plus (+) sign; you must perform
this operation as root.
If you get this all set up so that the LPD daemon is running and the
remote users have LPD access and it still doesn't appear to work,
bring down the queues on the AIX side and resend the job to see if
it appears on the queue in QUEUED status but disappears when the queue
is enabled.
If the job is not coming across at all, then you will need to run an
iptrace to see what's happening across the connection. The best
description of how to do this is on an internal web site,
http://tesch.aix.dfw.ibm.com/printips/iptrace.html, or you can call
1-800-CALL-AIX, or reopen this item.
If the job is coming across but disappearing, then we'll have to snoop
around further. There are some known changes in the LPD AIX V4.3 that
affect how jobs from Windows 95 or NT are handled (see RTA000152199),
but I don't know of anything at 4.1.5.
Hope that helps.
(Reviewed 01 Oct 1998)
S e a r c h - k e y w o r d s:
psf/6000 psf/aix psf aix windows NT LAN lpr lpd pcl pcl2afp PostScript
ps2afp remote client hosts.lpd hosts.equiv 4.3 4.3.1
WWQA: ITEM: RTA000136017 ITEM: RTA000136017
Dated: 10/1998 Category: XPSF6000
This HTML file was generated 99/06/24~12:43:35
Comments or suggestions?
Contact us