Remote Printer acting courious

[Michael Starogardzki]

Strange things happends in universe.

I have two printers attached to a e25 and remote printer drivers installed on a d210 both running HPUX 10.20

Some days before, we had a "file system full" message on the d210. I freed up some space and everything worked fine.

Everything? Non everything. One of the printers (lets call it 914) did not work propperly. He prints local requests but no remote ones. The other (letz call it 1070) works well.

Lpstat states 'up and waiting' for both on remote side. SAM shows both active on local side.

I canceled all printjobs - nothing. I rebooted the remote (d210) - nothing. All new print jobs went into queue.

I disabled and enabled back the 914 on local side (e25) with SAM. Nothing changed. I think I disabled/enabled it via SAM on the remote side but I am not quite shure.

I did some enabling/disabling with the 1070 and anything was as expected.

Then I disabled/enabled the 914 on the remote machine withe the commands 'disable' and 'enable' (all this while watching the lpstat outputs) and suddenly everything was ok.

What could be happended? Perhaps did extraterrestrians hack into my system ;-) ?

Thanks

Mike

[Scott D. Allen]

Sounds like you might be having some problems with the remote.

To recap:
you have two printers attached to your server (E45) 910 and 1070.
you have a remote client (D210) printing to these printers.
the local printing is working fine for both printers.
the remote printing is working fine for 1070.
the remote printing is not working fine for 910.

when you restarted the remote client printer from the command line, it started printing again. you said that you were having disk space problems before, but not anymore.

try reinstalling the 910 printer on the client. if you can still print to the 1070 but are having intermittent problems with the 910, it's probably not disk space (assuming your spooler directories are on the same filesystem). make sure that you are using the most recent driver or a nice generic filter.

--Scott

[Michael Starogardzki]

Your repetition is almost right. (it is no e45 but a e25 and the 910 is called 914). I have to state, that 914 is not realy the bull/compuprint 914. It is named after the old printer so I had not to change Application settings. It is a 9058D on the parralel port - the 1070 is what it is called - on the serial.

The driver is one of the generic. I think it could not be the driver because both printers worked fine for weeks an months without rebooting either machine.

Now they work fine for one or two days. The miracle I did not understand is the fact, that SAM and lpstat tells me that both printers were up and waiting on both machines.

Reboting the remote and deactivating/activating the printers from sam on local did not change anything. All printjobs waited in the queue. lpstat tells 914 is up and waiting.

But disable/enable on the command line did the job well. Anything is fine, but I do not understand the reason. Is there some software switch that is not toggeled by the reboot but by the disab/enab? And which is not noticed by SAM and the lpstat?

[Scott D. Allen · Accepted solution]

Sorry about the description mixup.

The reboot won't work because that doesn't actually do anything to the printers or the queue. The machine will just hold onto the queue and shutdown/reboot.

In general, my experience has been that printers are picky/finicky. I would always recommend restarting a printer from the command line with disable/enable over the use of ANY admin tool (no offense to SAM-lovers). I don't know what switches/commands SAM issues to reset the printer, but if I want to unhang a stuck printer, I'll always go with the disable/enable from the command line. Especially when dealing with serial/parallel printers which might experience buffer issues and physical connection issues.

--Scott

"Whatever happened to the paperless office?"

[Michael Starogardzki]

Thanks for the hints and also for your oppinion on sam vs command line. I WILL remember this! ;-)

I think it was some sw switch within the driver which stuck. The kolleges promised that they switched the printer 'off' every evening and 'on' every morning and it stuck for several days.

I am only here two days a week so they save the realy strange things for me. :-)

But with modern printers you could not be realy shure if it is totally resettet with power off :-(