ITEM: BN6403L
Not getting printer intervention messages.
ENV:
3.2.5, model 550, printer messages.
DESC:
Customer is printing to Lexmark 4033 attached printers, via lexlink
software. He has users who log onto the RISC, all using the same user
name/ID. When the printers are jammed, out-of-paper, etc. the
user who actaully submitted the job does NOT get the message, but
one of the other users logged in with the same ID. Why?
Response:
The queueing system merely sends a message to the first tty type
device that is logged in using the same userid that submitted the job.
If many people log in using the same userid, it will show up on the
lowest\# tty.. which could be someone else's screen. This is further
complicated by the fact that one can refuse these messages using "mesg
n". So if the lowest\# tty has run "mesg n", then the next lowest
receives it. If that user is no longer signed on or all the tty's
have refused messages, then it should show up in that user's mail.
ACT:
The customer was aware that the lowest tty\# will receive the message.
To better clarify what the problem is; he has added the
user 'sally' to the 'si' attribute, yet 'sally' will NOT receive the
printer intervention messages.
The customer is using the 4033 network printer attachment, thus is
using the Lexlink backend. He now has placed a call with Lexmark, but has
yet to hear from them.
ACT:
I have found this information, from past item BL9853.
The PIO_IPCWRITEFD env variable
somehow specifies a way to pipe messages to a print
administrator. Also there is a setting withing the sysnot
function call that specifies whether these messages are sent
to the screen or the user's mailbox.
Check the virtual printer attributes 'A' and 'si'
EXPAMPLE:
si=nobody
A=1
Reference Info for additional information on PIO_IPCWRITEFD
along with virtual printer attributes.
1. Check the _si attribute.
Users, Separated by Commas, to Get Intervention
Messages; Null String Is Job Submitter
2. PIO_IPCWRITEFD, environmenbt variable.
If it is set, the message is sent to a print supervisor by
way of a pipe.
3. The backend can send messages directly to the user with the
sysnot routine. The sysnot routine can either mail the message
to the user or write the message to the user's terminal.
sysnot(user, host, message, pref)
char *user;
char *host;
char *message;
unsigned int *pref;
The value of the pref parameter should be DOMAIL or DOWRITE.
DOMAIL mails the error message to the user.
DOWRITE writes the message to the user's terminal if the user
is logged on. If the user is not logged on, the message is
mailed to the user. The DOMAIL and DOWRITE constants are
defined in the /usr/include/IN/backend.h file.
NEXT:
Fax this info. to the customer.
ACT: I tried to explain the difference between an intervention message
and an error message. The intervention message is one that actually
comes back from the printer across the system's receive line in text
form. These can be directed using the si attribute. An error message
occurs when the backend generates an error. These are not
controlled by si.
The customer is highly interested in any way to redirect such error
messages so that they do show up, but do not show up to the job
submitter.
Response:
I tried setting up the mo attribute so that 2>/dev/console but can't
seem to get consistent results. A=0 will keep many errors from
showing up at all, but does not help in redirecting them.
Response:
Checked the pioout routine. It uses a subroutine called piomsgout
which can be sent to various places. If it is called with option 1,
then it gets sent to the 'PIOFROM' user.
Be a little careful throwing around env variables like PIO_IPCWRITEFD
and PIOFROM. These are environment variables that are set by piobe
or qdaemon, and are created by the qdaemon based on the user who
submits the job.
When it talks about 'piping' the output to the print supervisor, that
is NOT a person, but the qdaemon. IPC being inter process communication.
I have tried adding filters in various places to change the PIOFROM
env variable, but with no success.
As DS has noted, you can get some minor changes in what messages
appear, but not necessarily in where they are redirected to.
I have tried to 'su nobody' in a custom backend with not sucess.
I've also tried changing the USER, and LOGIN evn variables with
no success.
I also am experimenting with the 4039 using the LexMark driver to
see if I can even get the 'so called' Intervention messages redirected.
I have gotten the message back from the printer, but so far even
it goes to the user submitting the job, and not the final user.
Based on 'man pioout' I should be able to add a -L text parameter
to determine which messages get sent to the intervention user. I
don't seem to get this too work.
I think that we will find it is 'working as designed', with no
ability to redirect the messages. One possibility at the hospitol
which seems to have the problem because everyone logs in as the
same user is to put a '.forward' file in the userid to send all
the mail to the 'administrator' or to build an alias.
Another thought is a 'mail filter', that would check who the mail
was to and from and send certain mail to an 'administrative user'.
VM: customer believes such a .forward solution is acceptable. Just
what were the breakdown between intervention and error messages?
ACT: nilm, I explained again how to setup the .forward. I also
explained that he would need to either 1) submit the jobs with
something like qprt -C or issue "mesg n" for the sessions that should
not receive the messages.
The intervention message is actually a text message that is sent back
from the printer. This is normally only done by devices such as
postscript printers. Errors generated by the backend, such as a cable
breaks or some such, are considered errors and not intervention
messages.
Response:
ACT: customer is willing to implement the .forward workaround, but
would like some way to distinguish the intervention messages from
error messages. What he gets on his screen is "printer is offline" or
"printer needs paper". He believes these would be intervention type
messages, and does not understand why they are not redirected.
NEXT: I concur and will research..
Response:
I have done some testing with both the MarkNet attached 4039 and
a parallel attached 4029. In both cases, I took the paper out
to create an out of paper error. Next I submitted a large
postscript job. I waited for the timeout period and got a message.
The locally attached 4029 gave me the message to the user that
was specified in the 'is' attribute. The network attached printer
only sent the message to the user who submitted the job.
This looks like part of this is related to LexMark.
Part is still related to the vast confusion of virtual printers.
NEXT: Will do more research later.
Response:
Woops, even though it went to the intervention user, a local
message went to the submitter as well:
The message to the submitter was:
Message from qdaemon:
=====> MESSAGE FROM PRINT JOB 749 (sftssn.ps) \<=====
0782-054 Error detected during output to printer.
The device name is lp0 (ibm4029)
The errno (error number) from the write system call is 46
Use local problem reporting procedures.
~The error output to intervention user was:
Message from qdaemon:
=====> MESSAGE FROM PRINT JOB 749 (sftssn.ps) \<=====
0782-057 Printer lp0 (ibm4029) @ tesch needs attention.
Check the printer.
Response:
ACT: I explained to the customer that the intervention messages only
have a path for display when using a local queue. When not using such
a queue.. the messages come back as errors. These errors can not be
redirected using the si attribute. Customer plans to implement the
mail option discussed earlier. cwca
Support Line: Not getting printer intervention messages. ITEM: BN6403L
Dated: October 1996 Category: N/A
This HTML file was generated 99/06/24~13:30:21
Comments or suggestions?
Contact us