Print queue management: How to locate file associated with print request-id

[Toad Hall]

I'm an HP-UX newbie, so please forgive my lack of knowledge. I need some help with understanding print management with HP-UX.

I can know how to send a print job to a queue, and how to check on the status of the print job, what I need to know is where are those jobs really kept, and how to associate a print request-id with the filename of the item that is queued.

On our system, I'm using the following command to check on a queue.

$ lpstat -padmdp01 -oadmdp01
printer admdp01 disabled since Sep 14 04:52 -
reason unknown
fence priority : 0
admdp01-192 d_p002 priority 0 Sep 20 14:28
(standard input) 46075 bytes
admdp01-203 d_p002 priority 0 Sep 21 09:27
(standard input) 55882 bytes
admdp01-204 d_p002 priority 0 Sep 21 09:27
(standard input) 46073 bytes
admdp01-224 d_p002 priority 0 Sep 21 12:42
(standard input) 2 copies 57910 bytes
admdp01-225 d_p002 priority 0 Sep 21 12:42

Most print jobs are handled by an application that submits the print job, and I don't know how to locate the actual file name associated with the print request-id.

Can someone explain it to me? I've been searching and reading doc from HP, but can't seem to locate any help on the topic.

Thanks for helping.

[Tim Nelson]

/var/spool/lp/requests/PRINTER

a cAxxxx file and a dAxxx file
"c" file is job info
"d" file is the actual data
xxx relates to job number.

[A. Clay Stephenson]

The answer varies a bit with the type of printer but for local and Network printers (as opposed to Remote printers):

Consider this two lp requests:

ls -l /etc | lp -dmyprinter
and
lp -dmyprinter myfile

both of these would wind up in /var/spool/lp/request/myprinter and each request would have 2 files associated with it. One is the actually data and will be named dArequestidhost (or something very close) and the other contains lp metadata for the printjob and will be named cArequestidhost. When the request is actually printed these files are removed.

[OldSchool]

and to add to the above comments, let us say someone issues the following:

lp -dmyprinter myfile.txt

and get the message:

request id is mprinter-123

in this case, there is no way to relate the specific print request back to file "myfile", much less the complete path to "myfile" (if that's what you're looking for)

[Toad Hall]

Good info folks. I guess I'm just spoiled by OpenVMS which gives me the info in a really simple command $ show entr/full

The system responds with the full path and filename.

Our remote host doesn't give us permissions to take a look at the files in the /var/spool/lp/request/ folder, so I can't see what's in those c9999nodename files.

The problem being, we have 2 nodes, about 400 print queues. If a printer goes down, we need to be able to move the file over to another queue. Yes, we can move it, if we know the request-id, but the application doesn't give folks that info when the job is submitted, and doubt they would write it down anyway. So, we really would need to know the full path of the print job to move the right ones.

It's hard to believe that this is not a function available to HP-UX folks. Seems pretty standard print queue management stuff.

I appreciate all of the responses so far. Maybe there's a shell script or perl script to get access to those files and info.

Thanks, again for helping.

[OldSchool]

well...if you can't see the remote file system you can't move them anyway.

reading "man lpmove" may also offer some insight.

[Patrick Wallek]

If a queue goes down for some reason, you don't really need to know the exact file name to move.

You can find the request with the lpstat command, as you have in your original post.

If you need to move those, you can then use the lpalt command to move the request to a different printer.

For example, to move the request admdp01-192 from printer admdp01 to admdp02 you would do:

# lpalt admdp01-192 -dadmdp02

See the lpalt man page for more information.

[OldSchool]

and you may want to look at HP Distributed Print Service, SpoolQ or PlusTechnologies various offerings if basic lp stuff isn't up to your needs

[Toad Hall]

OldSchool: I do have privs to most files, just not root privs to do much with these particular files, I'm not the owner, and the permissions don't allow me to read them.

I have no trouble moving the files using lpalt.

Patrick: The issue isn't so much not being able to use the request-id, but what file is actually being moved. In our hospital, a user may submit a job from an application, along with 50 other jobs. Then, something happens to the printer. They call and want their 'report' to print on another printer, but don't care about the other less important jobs. Now, I don't know how to located 'their priority report' because I don't have a filename to identify it.

I suspect the lack of the filename /job name is due to some setup of the print queue, that's using (standard inpu) for all job names. So, maybe that's what would be in that file information anyway, still, I need a way to find the full path and filename to be able to service the users, otherwise I have to move each job until they get the right one. That's not a very good solution for clinical folks that need their jobs to treat patients.

So, again, thanks for all of the responses. I'm really appreciative of the quickness of the responses here on this forum. Great to see.

[OldSchool · Accepted solution]

"I suspect the lack of the filename /job name is due to some setup of the print queue, that's using (standard inpu) for all job names"

Nope...thats the way the application uses the printer system. kind of like:

date | lp -dmyprinter.

As I previously noted, there is *nothing* in the lp sub-system that will tell you the name of the originating file.

*if* you had read access to the dA* files noted above AND the user could tell you a specific-enough piece of data to search for, then you *could* search for the correct file in the requests directory.

Given your environment, I think I'd look into document / print management software

[Toad Hall]

Ah, ok, thanks OldSchool. Probably, going to let the issue go as we are locked into the vendor's method and choices, so not much I can do as a 'system administrator' but work with what they give me.

I'll just push the request off to them to figure out, when they get tired of not being able to meet the service targets of our clinical folks, they'll be forced to do this another way.

Thanks for the responses, again.