RLP Job iD length

[SDZald]

SCO 5.0.7

I am having problems with the order jobs are printing on a remote printer when the total number of jobs(not size of jobs) are large. One thing I have noticed is that the job id length is only 3 digits, example of a job id remprn-001.

Is there a way for me to up the size id length from 3 to say 5 so it would look like remprn-00001?

 

[PHV]

Sorry, but where is the issue ?
More than 1000 jobs per day ?

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886

 

[SDZald]

Yes exactly. Once a week or so we need to print bulk records, they are normaly only a few pages each but they can be up to a couple thousand documents. As long as we keep the total number below a 1,000 the jobs print in order. It only seems to get out of order when the total number of jobs in the queue goes over 1,000.

We run the same job on local printers just fine as of course the local printers request-id is 'printer name-######' where as the remote is 'printer name-###'

What I am trying to do is change that remote default to 6 digits just the same as the local side.

To be honest this is the first time we have been messing with RLP so my learning curve is steep. I also noticed that when you use the disable command on the remote printer it is ignored.

I have read that there seems to be a lot of quarks with RLP and some suggest going to NETCAT. I would prefer to stick with the canned SCO print services if I can, we send a lot of forms type jobs with hole punching and stapling etc and I am afraid that if I use NETCAT we would run into even more problems.

 

[SDZald]

Oh one last note. I removed CUPS when I installed RLP as you can't install RLP with CUPS and I never re-installed it. I don't know if that has anything to do with the problem but I thought I better mention it just in case.

 

[SDZald]

Ok the problem is solved and it had nothing to do with the 3 digit number.

It truns out that the way the local SCO server passes on jobs to a printer setup with LPD the jobs can get out of order if there are delays with the printer LPD service.

How we fixed the issue was to print directly to port 9100 by way of the HPNP. When I first tried setting it up through the scoadmin HP menu it would print nothing. It turns out that there is a process that gets run with every HPNP print job called getone. All getone does is querry the printer as if it were a HP printer, thus all non HP printers will fail. Rename getone (in /etc) and you can get any non HP printer that accepts jobs on port 9100 to work.

One note if you are running any 3rd party apps or have any scripts that expect a return from getone you can't use this method.

 

[motoslide]

Your experience with "getone" is the reason many of us have opted for "netcat" in place of HPNP.

"Proof that there is intelligent life in Oregon. Well, Life anyway.