Re: Intermittent Message Subfile, works always in debug.

The DSPLY idea worked. I put a DSPLY after the call to QMHSNDPM, and found that for some reason the message file name wasn't getting set with a library qualifier on some messages. (Who knows why, and I had created this service program from some older source from another developer.) I made a change to hard-set the message file/library field and everything went to work just like it should.

Thanks for the help, I was gonna be bald by Tuesday morning!

--Jamey

On 2/6/2012 3:57 PM, Rory Hewitt wrote:

By itself that looks fine (although you should be defining your numeric
fields in DSERR as integers rather than as binary fields, but it's no
biggie. Do you check the value of @BAVL immediately after the call to
QMHSNDPM?

Unfortunately, the problem may not be in this specific section of code - it
may actually be elsewhere, but only show up here (in fact, it;'s not even
clear that it's showing up here - there appears to be a problem with a
message not being sent (or possibly not being received), but that's about
all we know.

Short of posting the code for the entire program, I'd suggest you include
code (if you haven't already) to check @BAVL immediately after the call to
QMHSNDPM and if it's not 0, somehow send an error (using DSPLY or DUMP or
another call to QMHSNDPM to write it to the job log). Speaking of which, is
there anythign in your job log that might have some bearing on this?

On Mon, Feb 6, 2012 at 12:47 PM, Jamey Saunders<
jsaund@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

Rory,

Yes, its RPG.

Here's the data structure definition I'm using for the Error DS:

D*----Data structure for API error.
D DSERR DS
D @BRET 1 4B 0 INZ(0272)
D @BAVL 5 8B 0 INZ(0000)
D @ERRID 9 15
D @DSERR 16 16
D @ERR 17 272

And here's the prototype for QMHSNDPM:

D QMHSNDPM PR ExtPgm('QMHSNDPM')
D PR_MsgID 7A const
D PR_QualMsgF 20A const
D PR_MsgTxt 32767A const options(*varsize)
D PR_MsgTxtLen 10I 0 const
D PR_MsgType 10A const
D PR_MsgQueues 276A const dim(50) options(*varsize)
D PR_NumQueues 10I 0 const
D PR_MsgKey 4A
D PR_ErrorCode 8000A options(*varsize)
D PR_CCSID 10I 0 const options(*nopass)

And the call to QMHSNDPM in my service program:

CallP QMHSNDPM(INMGID:MMSGF:MDATA:MLEN:MTYPE:
MMSGQ:MSTACK:MKEY:DSERR);

Values when I'm in debug are:
INMGID: IRB0014 (That's the message number I'm sending from my message
file)
MMSGF: 'IRBMSG IRBPGM ' (That's the correct qualified name of my
message file)
MDATA: *BLANK
MLEN: 80
MTYPE: *INFO
MMSGQ: IRB201 (That's the name of the program whose message queue I want
to write to)
MSTACK: *ZEROS
MKEY: *BLANKS
DSERR: @BRET is 272, but that's being set in the DS definition.
Everything else in the DSERR structure is zeros or blank.

Does that help?

Best Regards,
Jamey Saunders

On 2/6/2012 3:29 PM, Rory Hewitt wrote:

Jamey,

In my experience, there are 2 reasons why something works in debug and
doesn't work otherwise:

1. Timing. Running a program in debug takes longer - mainly because

you're

stopping it every so often to check field values. In programs that make

use

of things like semaphores, mutexes, shared memory and where there are

other

programs accessing the same data or sending receiving signals, data queue
entries etc from your program, this can change things drastically.

2. Memory initialization. When a program is loaded , it allocates

whatever

memory it needs from the OS to do its thing. If you run it in debug, the
memory may be allocated differently than when not in debug. I think the
debugger may pre-initialize the memory heap in some way, but I'm not

sure.

You're almost certainly a victim of #2. Check your numeric variables,
specifically those that are subfields in a data-structure? Do you
explicitly initialize them? If not, then in debug, the memory over which
they are overlaid may be set to hex zeroes anyway, so they implicitly
initialize to 0, but when not in debug, it may be some other value.

Do you check/set QUSEC prior to calling QMHSNDPM? If so, do you check it
afterwards?

If necessary, add a DUMP statement to your program (and or multiple
DSPLY's) - I'm assuming this is RPG - although that may cause a different
memory layout anyway.

HTH,

Rory

On Mon, Feb 6, 2012 at 11:46 AM, Jamey Saunders<
jsaund@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

Hi Everyone,

Here's something that has had me stumped for two days. I have a display
file with a message subfile. I am sending the messages using QMHSNDPM
wrapped in a service program. I have a block of code that does some
sanity checks on the subfile control data and sends messages to the
program queue for display as appropriate. I am also clearing the
message queue whenever the subfile is acted on and control is returned
to the program (i.e.: someone does something and presses Enter).

My issue is this: Some of my messages display properly. Some of my
messages do not display at all. It is always the same messages that
display, and always the same messages that do not. Here's the kicker,
though: If I put my program into debug, and step past the call to the
ShowMsg procedure in my service program, then hit F12, every single
message displays properly.

None of my colleagues can figure this one out, though one of them says
that he's seen this happen before where something worked in debug that
didn't work otherwise, and he thinks it was subfile-related. He doesn't
remember what the fix was, though.

Anybody ever run into something like this? I'll post any code that
anyone deems relevant, even though the messaging is working properly
some of the time.

Best Regards,
Jamey Saunders
--
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.

--
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.