Difference between revisions of "Remote Printer Hung"
From MidrangeWiki
m |
m |
||
| Line 1: | Line 1: | ||
[[Category:Administration]] | [[Category:Administration]] | ||
| + | [[Category:Output to Print]] | ||
| + | [[Category:Trouble Shooting]] | ||
One of the problems that can be a contributor to solving [[Degradation]] - suppose you had a communication line go down, while printer going at remote site, and the 400 manages most of the task of reconnecting devices, but the printer is stuck because it cannot recover the print job that was in the printer communications cache when the communications line went down, or perhaps the 400 not know if the forms aligned right, or any number of other possibilities. | One of the problems that can be a contributor to solving [[Degradation]] - suppose you had a communication line go down, while printer going at remote site, and the 400 manages most of the task of reconnecting devices, but the printer is stuck because it cannot recover the print job that was in the printer communications cache when the communications line went down, or perhaps the 400 not know if the forms aligned right, or any number of other possibilities. | ||
Latest revision as of 19:32, 27 June 2005
One of the problems that can be a contributor to solving Degradation - suppose you had a communication line go down, while printer going at remote site, and the 400 manages most of the task of reconnecting devices, but the printer is stuck because it cannot recover the print job that was in the printer communications cache when the communications line went down, or perhaps the 400 not know if the forms aligned right, or any number of other possibilities.
So it cannot do the next recovery step because it is hanging on an earlier recovery step. The simplest thing to do here is
- Determine the last page printed ... now this OUGHT to be done by someone at the remote site, because the 400 may have sent 25 pages to the print buffer, but only 22 printed before we lost the connection, like perhaps there was a power outage at the remote site, and the printer also lost what was in its buffer.
- Put that report on hold, and change its restart to print page based on what is next needed.
- Bring everything down on the printer, then bring everything back up again.
- Some of this may need to be done with a person whose 400 security is higher than the average user.
- You may need to stop the job that is using the printer writer ... you can locate that with GO CMDLCK and then specify the printer involved. The object type is *DEVD not the *DEV that we use in WRKCFGSTS
- You need to stop the writer to that printer, but before it will let you do that, you may need to stop the job that is using the printer writer.
- You may want to vary off the printer, but you need to stop the writer before this.
- You probably do NOT want to stop sub-system QSPL since that is for ALL printers.
- After we brought everything down on the printer, give the 400 a minute or two for all the error messages to clear, then bring it back up again in the opposite direction.
- Vary the sucker back on.
- Restart the printer writer
- Release the problem report to resume printing
- Ask the folks at the remote end if all Ok now?
Incidentally, a related problem, when we have lots of users with lots of reports for lots of printers, Where is my report? can be a problem.
