Hi all,

I have a problem where I don't know how to track this further down.

We have an AIX box (5.something) and a printer connected over the
network with a JetDirect print server. The printer is configured in AIX
and there is a queue for that printer.

I can use SMIT without any problems to print an ASCII file to that
queue and it gets printed fine. So I would assume the queue and
everything behing it is doing fine.

Now I try to print to that very same queue using an application which
produces ASCII output as well. Just *nothing* happens. No error
message, no printout.

This sounds like the app fails to place the print job into the queue in
the first place. But: If I take the printer offline and then print from
the application, the job cannot get processed obviously. So it stays in
the queue and I can see it sitting there in the Print Manager or with
lpstat. So obviously the application knows how to put the job into the
queue properly.

Just alltogether it does not work out.

Any ideas? Strange, isn't it? Feel free to ask me for any information
that I might have left out.

Regards,
Torsten

You may want to try this:

1) Bring the queue down and print to it using the application.

2) Go into /var/spool/qdaemon directory and locate the generated ASCII
output which should be stored in a randomly generated filename. You may
have to do this based on date, time, or simply cat the file to see if
it is the right one (if you have many printers sending jobs, that
directory may contain several filenames).

3) Use "od" command to examine the contents of that file for any
special ASCII characters. There may be some escape codes that are
preventing the job from printing properly.

I am also assuming the printer is set up on an HP JetDirect device but
is defined as Other - Generic for the make/model. If you chose a
specific make/model when the queue was defined (eg. HP 4000) then it
may be expecting PostScript or PCL codes that are messing things up.

Perhaps doing this test will identify something in the setup or the
application. HTH.

Steve

Steve,

> 2) Go into /var/spool/qdaemon directory and locate the generated ASCII
> output which should be stored in a randomly generated filename.

Ok. I have done that and I have some findings:

- There are a couple of jobs lying around. Some are some days old, some
are from last year(!). I tried doing a fresh print from the app and
found my job to appear there in a new file that keeps staying there
though I did *not* bring down the queue I printed to.

- The file is in PostScript. The application was probably fooling me
because it has a "print to file" option. I thought if I use that it
will print to the file exactly what it would send to the printer queue,
but it obviously doesn't. Good to know. In the app there is no way to
say what kind of printer you have and I guess there is no way the app
will ask the queue, is there? So I would assume that the application is
always sending PostScript to the printer queue.

> I am also assuming the printer is set up on an HP JetDirect device but
> is defined as Other - Generic for the make/model.

By "defined as "Other - Generic" do you mean in AIX? Then it is not set
up like that as far as I can tell:

$ /usr/lib/lpd/pio/etc/piolsvp -p
# PRINT QUEUE PRINTER DESCRIPTION
tta_printer tta_printer
...
ntc58028 hp@ntc58028 hplj-4 (PCL)
ntc58028PS hp@ntc58028 hplj-4 (PostScript)

The queue ntc58028 and ntc58028PS represent the same printer, it's just
once PostScript and once ASCII.

I tried to print the PostScript file found in /var/spool/qdaemon using
SMIT, but this did not work, while printing an ASCII file the very same
way worked.

Something's wrong here ...

Sorry for the wrong information about ASCII in the first place. Now at
least I got a consistent behaviour: PostScript does not print neither
way.

Any more ideas maybe ???

Based on the DESCRIPTION column I see you have the queue set up using
the HP Laserjet 4,4M driver. That is why the queues are created as
either PCL or PostScript, not as "generic (ASCII)".

If the application is generating PostScript data, then it could be that
the PS code is not being generated properly by the application. (For
example, we use Zebra tag printers that need to send the data to the
printer in ZPL II otherwise the printer just ignores what was sent to
it)

My thought would be to see if you can send a PostScript file from any
other source to that ntc58028PS printer queue and see if the queue will
print it. If so, then sneak a peak in /var/spool/qdaemon at the job
file and see how it compares to the one being produced by the problem
application.

Sorry - wish I could be more help but it sure looks like the
application is causing your problem. It may not be producing valid
PostScript data and the port is refusing to print it out. You might
want to check the emails sent to root user on that RS/6000. Maybe it
will contain an error message sent about the jobs going to that printer
queue.

Steve