× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.