Re: Repeitive device messages -- MIDRANGE-L

This is either a dumb idea, or the perfect solution:

Send *INFO messages to a nearby workstation's message queue. Shouldn't matter if there is an active session, and workstation message queues are cleaned by the system. I was told, if the user account is accurate, that the printer is usually out of paper for a short time, so even if new messages are sent frequently, this shouldn't be an issue.

What I have learned from this is the cause and possible response to another devd that apparently runs out of paper far more often. Standard response by the operators was to cancel the writer. Maybe, if that message had on first line the cause of the error, operator might have attended to it. End user adds paper, complains to computer operator, and operator starts the writer. With messages sent as *INFO to a workstation, some user frustration might go away.

John McKee

-----Original message-----
From: jmmckee jmmckee@xxxxxxxxxxxxxx
Date: Thu, 05 Aug 2010 21:02:51 -0500
To: "Midrange Systems Technical Discussion" midrange-l@xxxxxxxxxxxx
Subject: Re: Repeitive device messages

I hadn't considered trying *INFO for messages. Wasn't sure if there would be other consequences. Since the printer is looked at frequently, there doesn't seem to be a down side to this. But, wouldn't the message still be sent as long as the condition existed?

Here is the devd:

CRTDEVPRT DEVD(CVLP001) DEVCLS(*LAN) TYPE(3812) MODEL(1) +

LANATTACH(*IP) PORT(9100) ATTACH(*DIRECT) ONLINE(*YES) +

FONT(11 *NONE) FORMFEED(*AUTOCUT) SEPDRAWER(*FILE) +

PRTERRMSG(*INQ) MSGQ(*CTLD) ACTTMR(170) INACTTMR(*SEC15) +

LINESPEED(19200) WORDLEN(8) PARITY(*NONE) STOPBITS(1) +

TRANSFORM(*YES) MFRTYPMDL(*LEXOPTRAS) PPRSRC1(*LETTER) +

PPRSRC2(*LETTER) ENVELOPE(*NUMBER10) ASCII899(*NO) +

IMGCFG(*NONE) CHRID(*SYSVAL) RMTLOCNAME('10.50.52.220') +

WSCST(BSYOBJ1/LEXOPTRAS) SYSDRVPGM(*HPPJLDRV) +

TEXT('Cardiovascular Lab - Lexmark Network Printer') +

PUBLISHINF(*UNKNOWN *UNKNOWN *UNKNOWN *UNKNOWN *BLANK +

(*UNKNOWN))

Related question I could research Monday when I am back at work is how *INFO would effect the forms change message. I use the reply list now to send a G to the message. I am assuming that a forms change message (CPA3394) would still be sent as *INQ since it isn't device error related, but from the writer job itself (a guess on my part).

John McKee
-----Original message-----
From: Kirk Goins kirkgoins@xxxxxxxxx
Date: Thu, 05 Aug 2010 17:52:25 -0500
To: Midrange Systems Technical Discussion midrange-l@xxxxxxxxxxxx
Subject: Re: Repeitive device messages

Some of these messages 'might' be handled better if the 'Printer error
message' parm is set to *INFO vs *INQ or is it already set that way? Anther
thing is what is the 'Activation timer' value set to? The default is 170sec,
you might want to increase it to say 300sec. Also for grins can you post the
printer's devd?

On Thu, Aug 5, 2010 at 1:39 PM, jmmckee <jmmckee@xxxxxxxxxxxxxx> wrote:

A printer was set up some time ago as a remote output queue. User
complained that output was not being printed. Best guess is because this
printer is a Lexmark and receives data from other sources. My thought was
that the printer was just ignoring data if it was busy printing from another
system. So seemed like a printer device would be the answer.

First issue was adding a reply list entry to handle the forms change
message. I thought that was it.

Yesterday, user called again with the same complaint. I checked QSYSOPR
for unanswered messages. And, there was a "Device requires attention (C R)"
message. After entering R, the queue emptied almost immediately. Best
guess is that the Lexmark ran out of paper. More paper was added, but that
unanswered message let things get backed up. The user does not keep a
session active all the time, so that is why Isent the messages to QSYSOPR.
But, the operator does want to deal with beginner mode. Must better to
just ignore all errors. Really ticks me off. User requested returning to a
remote output queue.

I had one other idea - a reply list entry for that printer to answer with
R. Kind of works. Problem is that message is sent perhaps every fifteen
seconds until the issue is resolved.

Best approach would be to get the operators to care. But, that seems
unlikely. So, now this question: Is there a way to suppress a duplicate
error message from being sent to QSYSOPR?

John McKee
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
Kirk
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.