Re: QMHSNDPM API and Recursion

On 05-Dec-2014 14:29 -0600, Bradley Stone wrote:

I'm having an issue with something that I believe is an oversight.

I have an application that recursively parses through a structure (a
folder/file type "tree" structure).

It does this recursively in an RPG subprocedure.

For each level, it calls the QMHSNDPM API to send a status message so
we can see what level/folder we're at.

What I'm finding is it will display the message, and then on the
recursive call the status message disappears. Is there a way to avoid
this?

This is how the type of message is being set before the call to the
QMHSNDPM API:
MsgType = 'S'
msg_type = '*STATUS'
msg_id = 'CPF9897'
stack_ent = '*EXT'
stack_ctr = 1

FWiW the Stack Counter is ignored; a value of zero is more sensible, if the value were not ignored.

Here's some psuedocode that gets call with listFiles(rootfolderid):

function listFiles(folderID);

r_level += 1;
nameList[] = getListForFolder(folderID);

for i = 1 to nameList[].count;

if (nameList[i].type = 'folder');
sndpm('Digging down in folder ' + nameList[i].name);
listFiles(nameList[i].id);
sndpm('Back in folder ' + nameList[i].name);
endif;

endfor;

r_leavel -=1;

endfucntion;

the sndpm function flashes each message then goes blank until it
comes back. I'd like the message to stay there until sndpm is called
again to change the message.

Make sense? Thanks

Entirely possible that the work in getListForFolder() causes a blank status message to be sent to the external message queue. Surrounding that invocation [shown here also in pseudo-code] with a prior request to effect a stsMsgs('*NONE') invocation and then with a following request to effect a stsMsgs('*NORMAL') invocation to confirm that is the cause; the stsMsgs() implemented via the Change Job (QWTCHGJB) API to modify the Work Management attribute Key "1902" Data type "CHAR(10)" with Description "Status message handling". Or possibly just inferred to be probably the origin, by review of trace flow that shows the OS program QMHSNSTA sending a status message during that processing; or just debug that program with a break-point defined at instruction '/1' if that program is OPM, to see if that program is invoked [vs inferred from visibility in trace, inferred from the visibility as a Display Breakpoint event].

Reference material for the alluded stsMsgs():
<http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/apis/WMAttrDesc.htm>
<http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/apis/qwtchgjb.htm>