Re: Programmatically locating, and allowing response to message causing job *MSGW

I would recommend an upgrade. That information was added to the various job
related APIs because there really wasn't a good solution in prior releases.

IF, and that's a big if with your scenario, the job happens to be a print
writer then the Retrieve Writer Information (QSPRWTRI) API provides similar
information on prior releases as message wait was a definite problem
historically for print writers. But for generic job type access, an upgrade
to your OS is the way to go. IBM may have PTFed QUSRJOBI/QUSLJOB prior
releases with this information, but I doubt it.

Bruce

On Sun, Aug 15, 2010 at 9:17 AM, Dennis Lovelady <iseries@xxxxxxxxxxxx>wrote:

Thanks, Bruce.

While that does look promising, we are at V5R3, and lacking that particular
attribute in the JOBI0200 format. :(

Got anything else up your sleeve for the left-behinders? :)

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"Inanimate objects are classified scientifically into three major
categories
- those that don't work, those that break down, and those that get lost."
-- Russell Baker

If you're on V6R1 or later check out the Retrieve Job Information
(QUSRJOBI)
API and format JOBI0200. JOBI0200 provides:

[image: Start of change]191 BF CHAR(4) Message key, when active job
waiting for a message 195 C3 CHAR(10) Message queue name, when active
job
waiting for a message 205 CD CHAR(10) Message queue library name, when
active job waiting for a message 215 D7 CHAR(10) Message queue library
ASP
device name, when active job waiting for a message[image: End of change]


which should get you on your way!

Hope this helps,
Bruce Vining


On Sun, Aug 15, 2010 at 8:30 AM, Luis Rodriguez <luisro58@xxxxxxxxx>
wrote:

Dennis,

Maybe you could use a exit program? Found this on Infocenter:

http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/XDEFAU
LT.htm

The Default Handling exit program provides a default message handling
action
that can be used if the program to which an escape message is sent

does not

monitor for the message. Additional information and an example are

provided

in the CL Programming<

http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rbam6/clpro
.htm

topic.

A default handling program is defined to the system through the Add

Message

Description (ADDMSGD) command and the Change Message Description

(CHGMSGD)

command.

HTH,

Luis Rodriguez
IBM Certified Systems Expert - eServer i5 iSeries
--



On Sun, Aug 15, 2010 at 8:33 AM, Dennis Lovelady

<iseries@xxxxxxxxxxxx

wrote:

Sorry, maybe I wasn't clear.

This is a job that's overlooking other jobs. From this viewpoint,

MONMSG

works for the other jobs, not for this one. Besides, sometimes the

message

is a result of (for example) SNDUSRMSG or SNDMSG ... MSGQ(QSYSOPR)
MSGTYPE(*INQ) followed by RCVMSG.

Think WRKSBMJOB or WRKACTJOB. Each of these is able to respond to

such

messages via option 7. That's what I want to emulate.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
In case of fire, evacuate the building.
Do not use stairways.
Do not use elevators.
-- (sign by elevator in Boston's Federal Reserve Bank

building)

Perhaps I'm over simplifying things, but have you explored MONMSG?


Warmest Regards,

Richard Reeve




________________________________
From: Dennis Lovelady <iseries@xxxxxxxxxxxx>
To: RPG programming on the IBM i / System i <rpg400-

l@xxxxxxxxxxxx>

Sent: Sun, August 15, 2010 7:44:26 AM
Subject: Programmatically locating, and allowing response to

message

causing job
*MSGW

A number of times I have run across a situation where I'd like to
programmatically identify the exact message that's causing a job

to

wait for
reply. For example one of my current tasks emulates WRKSBMJOB,

but

with
some special client-based processing. I have it working quite

well,

and
we're all pleased, but the option to respond to whatever message

is

causing
MSGW status eludes me.



I had the same issue with a WRKSPLF work alike and we finally

abandoned

the
MSGW idea.



As administrator for some systems a few years ago, we also

developed an

application that would sent out pager messages when certain

conditions

occurred (such as same-old, same-old MSGW status), and we'd have

liked

to be
able to send out the exact message that was awaiting response.

For

that, we
pored through the job's SBMMSGQ until (if) we found it. But

that's

horribly
inefficient and often unfruitful. Besides, we did not identify a
method
that allowed response other than good-ole DSPMSG from an

interactive

job.



Since it has come up again, I'd like to see what others may have

come

up
with for this sort of thing, if you can share.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.