Re: Job message queue for 203562/QUSER/QZRCSRVS has been wrapped.

On 3/23/2015 1:15 PM, Gerald Kern wrote:

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;

I'm not an RDi architect; anything I think I know is by observing
behaviour. The QUSER job starts when RDi starts - it is intimately
linked with the Commands Log View. In the Commands Log View, try DSPJOB
OUTPUT(*PRINT) and check out the spooled file over on IBM i and see if
that isn't what you're looking at.

This job runs all of the IBM i command that RDi needs to execute; not
just debugging, but CRTBNDRPG and so on.

2) is there anyway to control that logging?

The job description in use on my 7.2 system is QSYS/QZBSJOBD, and it's
set to LOG(4 0 *NOLIST) I don't know what else might use that job
description - I don't have auditing turned on for it, but if you really
don't want a log and are hesitant to change a system-provided job
description, try changing the logging level in the Commands Log View to
something less verbose CHGJOB LOG(0 99 *NOLIST), but I don't know how
this will affect how RDi detects what succeeded and what failed.

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?

I close RDi down every night, but it's more a Windows thing than an RDi
thing. My Windows 7 behaves better if I don't leave giant memory
footprints in place overnight, so I close most everything; especially
anything that's Java.

As far as logging goes, it's a shrug for me. I'd prefer to have a log,
especially when trying to work out what binding directory SNAFU I just
committed...