×
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.
You can filter out most of these messages by setting the log level for the job a bit higher...
For example ... By default SQL0501 is sent with a severity level of 30 ...
Message ID . . . . . . . . . : SQL0501
Message file . . . . . . . . : QSQLMSG
Library . . . . . . . . . : QSYS
Severity . . . . . . . . . . : 30
Do a CHGJOB LOG(4 31 *SECLVL) and these messages won't be logged.
If required, you can always set it lower again if you need to troubleshoot a problem...
Kenneth
Kenneth E. Graap
http://www.linkedin.com/in/kennethgraap
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dean.Eshleman@xxxxxxxxxxxxxx
Sent: Friday, March 05, 2010 11:41 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Can I monitor for a *DIAG msg?
Hi,
We have a production program that is generating multiple "Cursor MYCURSOR not open" messages in the job log. This message is a Diagnostic message and has a message ID of SQL0501. Can I prevent this message from showing up in the job log by adding a MONITOR group in my RPG code around the code that is trying to close the cursor? I did notice that when I look at the message details, it is being sent to program QSYS/QSQRUN4. I suppose this is another clue that I might not be able to monitor for it. Our programs always try and close the cursor before opening it just in case it was left open for some strange reason. Maybe I need to look at that logic more closely. TIA
Dean Eshleman,
MMA, Inc.
midrange.com
