| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 7054.1 | | REGENT::POWERS | | Fri Jan 24 1997 10:04 | 7 |
| It's probably (almost certainly) not the printer or its resident code,
but some change in how it is being driven.
Is there a change in queue configs, a new job header page, setups?
Can anybody print to it successfully from anywhere?
- tom]
|
| 7054.2 | Looks like NO one can print from anywhere | ICS::ELDRIDGE | P_Name lost..pleeeze help find? | Fri Jan 24 1997 11:34 | 16 |
| No No & No. No changes have been made to this queue, the VAX4000-90
that loads the printer or anything. User were able to print
successfully from WIN95 thru PC shares set up on the VAX4000-90,
from VMS & ALLIN1 via DQS to the VAX4000-90, and from NT3.5 thru the
Alpha NT Office-server.
I just rechecked the LPSLOG since yesterday and it is now showing
hardware related errors but back to normal.
Just monitored the LPS$CONSOLE and saw two jobs printing thru WIN95 PC
shares and it shows: 11:08:52 Session 3 ends (13415 bytes total)
11:09:14 Session 4 ends (13415 bytes total) Left voicmail for the user
to call me and let me know if it actually printed.
Hardware support reports that the POP is a postscript software
error looking for a particular parameter (??)
Paul E.
|
| 7054.3 | | REGENT::POWERS | | Mon Jan 27 1997 10:15 | 11 |
| 'pop' is a PostScript command to remove an element from the operand stack.
If there isn't anything on the stack, the stackunderflow error will occur.
Since this error will only occur in reaction to PostSCript code received,
it's unlikely that theree is an error in the machine that would generate
such a specific error. Hence the questions about what's driving the printer.
Of course, it could be that the stuff driving the printer NEEDS to be changed
because of the upgrade, but I can't address that in isolation of your upgrade
process.
- tom]
|
| 7054.4 | Thanks.... | ICS::ELDRIDGE | P_Name lost..pleeeze help find? | Mon Jan 27 1997 11:47 | 12 |
| Re: -1 Before reading your reply, I recreated the queue and
submitted a CUBES.PS test and monitored the remote LPS$CONSOLE and
the system shows:
%DCPS-I-JOBSTART, Job CUBES (queue OG11G15P20, entry 18) started on
OG11G15P20 & then
Job CUBES (queue OG11G15P20, entry 18) completed.
I alos monitored the remote console as several jobs processed thru the
Alpha NT Office server, all showing different total bytes
Looks like all is back to normal...needed a relaxing weekend off? :>)
Thanks for all the info/assistance.
Paul E
|