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
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.