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

What about the QMHLJOBL API, that retrieves job log messages.

Vadim Rozen wrote an RPG IV procedure that provides a much better interface
to the QMHLJOBL API. His procedure, Receive Job Log Messages (RCVJLMSG),
takes care of all the gory details.

It was published in Midrange Computing. Here a link to an artivcle on it:
http://www.mcpressonline.com/programming/apis/api-power-without-api-complexi
ty.html

I do not knw if it works correctly on V5R3, because my programme wrapper I
have occassionally ends up in MSGW status itself. At V5R1 it worked without
errors. Had no time to check it though.

With regards,
Carel Teijgeler

*********** REPLY SEPARATOR ***********

On 15-8-2010 at 10:22 Bruce Vining wrote:

Oops. Rather than QUSLJOB I should have reference QGYOLJOB in my prior
note.
QGYOLJOB also has the message wait information but evidently QUSLJOB was
not
enhanced in this area for V6R1. I should know better than to go by memory
at
my age...

Bruce

On Sun, Aug 15, 2010 at 10:12 AM, Bruce Vining
<bvining@xxxxxxxxxxxxxxx>wrote:

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

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

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.

--
Regards,
Bruce
www.brucevining.com
www.powercl.com

--
Regards,
Bruce
www.brucevining.com
www.powercl.com
--
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.

Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 9.0.851 / Virusdatabase: 271.1.1/3064 - datum van uitgifte:
08/11/10 08:34:00