On 09-Jan-2014 09:29 -0800, Bakutis, Becky wrote:
I contacted IBM with this issue and they pointed me to these
documents along with offering assistance. The joblogs were being
spooled due to the settings in the qgpl/qdftsvr jobd <<SNIP>>

What change was performed to /resolve/ the issue? The OP stated the Job Description was already LOG(4 0 *NOLIST).? If truly corrected by a change to the JOBD, does that imply the *NOLIST was not previously set for the message level value of the LOG parameter as noted in the OP, or that the severity level was being exceeded for the job end? If the job was exceeding the end severity, a change that prevents the job log from being produced is likely just masking that issue; i.e. the reason for the job exceeding the end severity would best be resolved. Similarly if the joblog was being spooled while LOG(4 0 *NOLIST) was in effect, and a change was made to LOGOUTPUT(*PND) to mitigate the effects of the joblog spooling, e.g. by making the joblogs /pend/ instead of *JOBEND or *JOBLOGSVR, that is also just masking the original concern; i.e. if the job is not supposed to produce a joblog due to the combination of *NOLIST and ENDSEV, then it should neither generate a QPJOBLOG nor effect a *PND joblog.

Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2015 by MIDRANGE dot 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 here. If you have questions about this, please contact