On 23-Mar-2015 12:15 -0500, Gerald Kern wrote:
<<SNIP>>
Job message queue for 203562/QUSER/QZRCSRVS has been wrapped.
That is presumably the USEnglish msg CPI2417 "Job message queue for
&3/&2/&1 has been wrapped." issued from the named job and sent to
QSYSOPR and thus logged also to QHST.
Looking at the job log I determined these were related to the debug
job I was running earlier that morning.
So since it was around 4:00 pm I didn't want this activity to
continue throughout the weekend I simply ended the QUSER job and the
logging stopped.
If the logging was [all or mostly] just from the activity in the
morning, then ending the job despite little or no new messages being
logged would seem pointless.? Maybe something about when were the
/wrapped/ messages sent, when was the logged activity taking place, and
what\when /this activity/ was are not clear for lack of the events on a
time-line.
The *N/QUSER/QZRCSRVS jobs are prestart jobs to which essentially the
user is /connected/ to utilize that already-established job; some
activity will be logged as messages to the [*EXT, inactive, and active]
program message queues of the various program that ran or are running
when the client is connected. Those program message queues, all
together, effectively are quantified as the Job Message Queue (JMQ).
However I also went to debug another job and saw a similar
message on QSYSOPR for the new debug job, and out of curiosity
I shut down my RDi client and the QUSER job ended.
So I guess my questions are:
1) why did the QUSER job continue to write to the job message queue
after I stopped debugging the initial program? and;
There was no disconnection from the server by the client. Does that
question imply that the /wrapping/ condition was noted to continue
occurring for the same job after the debug work? Note that could be
normal, if that same job was since attached by a client that started
doing some more work for which a wrapping might be a legitimate effect;
if the original connection had not disconnected, the job would not be
eligible to be reused by another job.
2) is there anyway to control that logging?
By controlling what requests and the messaging effected by each
request that is performed. Otherwise control of the limits on the size
before wrapping; forced terminate upon a full condition, i.e. *NOWRAP
action for which the job would be ended when the JMQ became full.
I often leave RDi open but minimized when I go home for the eventing
but now I'm wondering if I need to shut it down when I'm not actively
using it, just as insurance against all this logging to a message
queue?
Without any work being passed to the server from the client, there
really should be no messages as requests and no messages as responses
that would be logged.
I suppose if a SEP debug was left active to that connection via that
command-server job, then for new instances that occurred for the entry
point, some messaging might occur despite no feedback from the client?
Thought, comments anyone?
The Job Message Queue Maximum Size (JOBMSGQMX) for the JOBD
[presumably the standard JOBD(QSYS/QZBSJOBD) as defined by the PJE in
QUSRWRK for program QZRCSRVS] can be changed [from the
default\as-shipped value of 8 MB] to a larger value; e.g. up to 64 MB.
The Job Message Queue Full Action (JOBMSGQFL) for that *JOBD could
also be changed to *PRTWRAP to ensure the QPJOBLOG is spooled before
wrapping, so the logged [unfiltered] messages will be written and left
available for review; using *WRAP, the ability to learn what might have
been the messaging that led to the condition surely would be impacted.
Not all messages that take space will be visible however, even with
LOG(4 0 *SECLVL) LOGCLPGM(*YES) to minimize the filtering of messages;
i.e. those LOGging settings ensure maximizing what messages will be
visible in the spooled joblog. Note that even with logging level of
LOG(0 0 *NOLIST) LOGCLPGM(*NO) to ensure minimal logging, the JMQ can
still wrap, because messaging still take the space irrespective the
aggressiveness of the filtering.
FWiW an old message thread with the /identical/ topic:
<
http://archive.midrange.com/web400/200606/threads.html#00069>
Subject: Should I be concerned ....
FWiW: The definition\attributes of the prestart job determines if the
job is reused or ended; according to what usage the job being used had
already performed servicing other connections. Change Prestart Job
Entry (CHGPJE) is used to modify the settings established with the Add
Prestart Job Entry (ADDPJE). These should not matter with regard to the
wrapping even for a reused job, because the disconnect for job reuse
should effectively perform a method that might be described as Reset or
Clear Job Message Queue.
midrange.com
