Re: QEZSNDMG - Break Message to a User

Michael Ryan wrote:

I'm invoking QEZSNDMG from a program where I get input from
the user running the program. The input is a list of users
that I gather by selection or user profile prefix. That part
runs fast. The time for the actual call to QEZSNDMG to
complete seems to vary widely. I wonder if that's
a function of system load?

CRPence wrote:

Michael Ryan wrote:

I'm using QEZSNDMG to send a break message to a user profile.
Seems pretty slow. <<SNIP>>

Non-UI or when asking for the screen to be presented might matter, and no mention of what assistance level. The changes to the presented display are more often the noticeable change due to ASTLVL(), but the code path differences may also be noticeable if only for the resulting resources required to effect the request.

The *BREAK interface requires that the *DSP message queue is used even though the list is of *USR. The *NORMAL interface is probably faster because there would be no code path requirement to query for the active interactive jobs of each user; i.e. *NORMAL is explicitly just the /user/ because it can use the MSGQ() from each *USRPRF object. See "Delivery mode" at:
http://publib.boulder.ibm.com/infocenter/systems/topic/apis/oa1.htm
Of course when using *NORMAL, the onus is on the user to ensure their user message queue remains set or is set to DLVRY(*BREAK) in whatever job where they wish to receive such notifications. That is somewhat less of an issue for the workstation message queue as I recall, since I think those break in more scenarios; i.e. excepting I believe, only the case for a prior explicit CHGMSGQ DLVRY(*NONE)

Very likely that the more jobs active on the system [irrespective of status], the longer the request will take, and depending on how many of the queried [i.e. listed\filtered] jobs are currently paged into memory [e.g. by & since the last invocation which also had to parse through the list of active interactive jobs].

Because the algorithm is likely a QUSLJOB first, an alternative of using the list locks API to find jobs for each user, and then either infer or retrieve for which are interactive jobs, could be faster. For example if it were known that only DSP* prefixed jobs were interactive, then parsing the list of locks could narrow which job [as holder of lock for that *USRPRF] was one of the user's interactive jobs, much faster than some invocations of /list job/. Although I believe the list job feature may have been much improved with filtering and thus performance for some of those filtering requests [v5r4 or v6r1], it is not only likely but probable that the OA feature to send messages was not then also updated to take advantage of that new capability\enhancement, so even coding one's own /list job/ invocation might be able to complete faster... and then simply SNDBRKMSG for each user matching the supplied list; i.e. just write your own version of QEZSNDMG :-)

Regards, Chuck