× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 15-Oct-2015 18:24 -0500, Englander, Douglas wrote:

Has anyone run into this or have a fix:

When I run an ILE RPG program in DEBUG, either in green screen
STRDBG or Rational Debugger, my job get tons of joblogs, and the
entries look like they are telling me that each SQL instruction was
successful. Because of this, the DEBUG sessions run extremely
slowly.

Presumably "tons of joblogs" implies many spooled joblogs.? Thus changing the job attribute Job Message Queue Full Action (JOBMSGQFL) from Print And Wrap (*PRTWRAP) to just Wrap (*WRAP) should help; i.e. use the Change Job (CHGJOB) command [or Change Job Description (CHGJOBD) to the *JOBD of the user if applicable and desirable:
CHGJOB MSGQFL(*WRAP)

Having done so, there would be no wait to produce the joblog in the job [if the joblog server is not performing the work]. I am not sure of the effect for also changing the Spooled File Action (SPLFACN) attribute for the job to *DETACH, because AFaIK that only applies to the End Of Job (EOJ) processing [for which the wrapping probably does not qualify].

While a similar change made to increase the Job Message Queue Maximum Size (JOBMSGQMX) should also help, if *PRTWRAP is maintained, then the larger queue will take longer to be spooled if\when that does occur, but the total number of times the job waits to spool would be reduced; greatly, if the default size is small [likely the value is obtained from QJOBMSGQMX system value, perhaps indirectly via the user's JOBD].


I found a tip where you set up the QAQQINI table with the
MESSAGE_DEBUG parameter set to *NO, and run CHGQRYA referencing my
developer library where that table resides as where the table is. I
thought this would reduce the job log creation, but it does not. Does
anyone have any ideas on how to stop/reduce the job log creation?


Unfortunately the value of that MESSAGES_DEBUG QQPARM specification for Debug Messages [AFaIK still only supports the values *YES and *NO] and the value of *NO means only _do not forcibly log_ debug messages irrespective the use of the debug. They really need to add support for a new special-value such as *OVRDBG or *NODBG that suggests to override the effect to _no "Query" Dbg Msg logging_ even when Debug is active; or here where I suggested *SUPPRESS instead, and link several prior discussions where I think a similar suggestion was made alluding that those who want a change in function probably should be asking for just that:
[http://archive.midrange.com/midrange-l/201309/msg00383.html]
Subject: SQLRPGLE in STRDBG creates *a lot* of QEZJOBLOG entries


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.