when I want to see the logs of a datastage job it gave me only the logs with the info level logs
I want to define a new level to see the logs please
Any help
Thanks in advance
Datastage knows three level of log entries - as you mentioned already:
Info
Warning
Error
They will be shown if they appear - so you do not have to do anything for it (as your question asumes)
You can "demote" a warning to an informational message or promote one i.e. from an information to a warning.
EDIT:
To do this you can define so called Messgae Handlers
his can be done on Job level or Project level (or Runtime handler)
In DataStage Director you eed to follow these steps: Menu - Tools - Message Handler Management
There are lots of descriptions out there - just search for DataStage Message Handler
Related
I have few debugs with info in the java class configured in Idempiere plugin. But after execution of that class on that server, I am getting warning log, but not info log, inside idempiere logs.
I tried google but couldn't find anything related to it. Could some one help in "How to change logger level (warning, info, debug) for Idempiere logs"
You could use the iDempiere Monitor
http://127.0.0.0:8080/idempiereMonitor
You can access with your System User credentials. Then go to the line:
Trace Log Level
And select one of these:
OFF
SEVERE
WARNING
INFO
CONFIG
FINE
FINER
FINEST
ALL
This will regenerate the last log file and build the new ones with this parameter.
I have a clarion application running in Win Server 2016 talking to a sybase DB, over the past few weeks we find the application gets frozen for different users at a given time. However the user can leave the session as such and start a new one and that works good. The users are known to use multiple instances of the same application in one remote server or on multiple servers. Having said that, I wanted to get more information on the freezeup and looked through the application event logs in the system where I see explorer.exe crashes but these correlate to the time of occurrence of the issue at certain times but not always, checked the DB transaction logs from Sybase and I do not find any crashes, errors or stuck connections. Having said that, since I have exhausted all possible options I am reaching out to you guys to know if there are any other places that i can look for to gather more information.
I would love to know of any application / tools that we could use to gather logs of a frozen clarion application on windows. Also good to know if anyone has faced such a situation and where and how have you guys looked into the issue.
Thanks in advance for your help in this.
Clarion's runtime library and database drivers expect a persistent connection. Disconnects that are normal with remote ODBC can cause a problem (including app hangs) unless you test for them at the ABC file mgr level and reconnect, or use similar steps to test and recover.
If you're looking for specifics about what's going on between the driver and the SQL backend, I suggest using Clarion's database driver trace facilities. From the help topic: "Logging Driver I/O for debugging":
To view the trace details in debugview, name the target trace file "DEBUG:"
Logging opens the named logfile for exclusive access. If the file exists, the new log data is appended to the file.
On Demand Logging
For on-demand logging you can use property syntax within your program to conditionally turn various levels of logging on and off. The logging is effective for the target table and any view for which the target table is the primary table.
file{PROP:Profile}=Pathname !Turns Clarion I/O logging on
file{PROP:Profile}="DEBUG:" !Turns Clarion I/O logging on and
!sends output via OutputDebugString()
!(viewable via debugview, etc)
file{PROP:Profile}='' !Turns Clarion I/O logging off
PathName = file{PROP:Profile} !Queries the name of the log file
file{PROP:Log}=string !Writes the string to the log file
file{PROP:Log}="DEBUG:" !Writes the string to the log file
file{PROP:Details}=1 !Turns Record Buffer logging on
fFile{PROP:Details}=0 !Turns Record Buffer logging off
where Pathname is the full pathname or the filename of the log file to create. If you do not specify a path, the driver writes the log file to the current directory.
You can also accomplish on demand logging with a SEND() command and the LOGFILE driver string. See LOGFILE for more information.
Example I use frequently, which was based on the help above:
SYSTEM{PROP:DriverTracing} = '1'
CRMNotes{PROP:TraceFile} = 'DEBUG:'
CRMNotes{PROP:Details}=1
CRMNotes{PROP:Profile}= 'DEBUG:'
CRMNotes{PROP:LogSQL} = 1
I have come across an odd error I have never encountered before in the audit logs:
As you can see there are no details displayed but rather just an image
When I click on a specific line I only get this:
I haven't the faintest idea of where to start looking
I am a system administrator in the system so I don't think it's a permissions issue.
I can also confirm that there are real values in the system where the audit logs display that image instead of a value.
It seems to be a widespread issue across almost every entity in the system too.
EDIT:
I have looked in the audit management logs and found this:
I guess this indicates that no logs have been deleted?
This occurs when auditing was switched off and on again. From that moment the system cannot guarantee that the audit trail shown is complete and therefore it displays a torn page symbol.
I'm troubleshooting a build step in TeamCity 9.0.4. The problem seems to lie within the service message output. Is it possible to view these after the build has completed? They are not included in the build log.
The documentation on service messages simply says In order to be processed by TeamCity, they should be printed into a standard output stream of the build.
https://confluence.jetbrains.com/display/TCD9/Build+Script+Interaction+with+TeamCity
(To some extent the service messages can be viewed by manually rerunning the build step and monitoring standard output, but this is not always feasible.)
The documentation for service message implies that you need to write service messages to standard out/error rather than to a log file. If you write it to standard out, teamcity will automatically pick it up and show it in the **build logs ** tab
What this means is that if you have a
shell script, use echo for your service messages
java class, use System.out.println
and so on
Different languages also have different plugins for this , for ex perl has TapHarness.pl to write teamcity messages to the console.
EDIT:
If you want to just view service messages , you can find them in the build logs on the teamcity agent that the build ran on. If you do not find them in the build logs , either the build log has rolled over or you need to increase the verbosity or debug level of your logs(depends on the language).
There was a problem which is solved nowdays:
TeamCity now parses service messages inside other service messages, but only if original message was tagged with tc:parseServiceMessagesInside. Example:
##teamcity[testStdOut name='test1' out='##teamcity|[buildStatisticValue key=|'my_stat_value|' value=|'125|'|]' tc:tags='tc:parseServiceMessagesInside']
A link to JetBrains bug tracker:
https://youtrack.jetbrains.com/issue/TW-45311
I am getting an WebSphere MQ Reason code 2195 MQRC_UNEXPECTED_ERROR when I try to connect to the message flows deployed on the execution group. Can somebody please tell me what exactly does this reason code mean? Queue manager, broker , execution group.. everything is up and running and the ports are also open. I am not getting anything worthwhile on the net.
Please advise.
The 2195 return code is a high-level exception that is hit when errors are not caught at lower levels in the code. Very often these are generated when some external dependency such as file access or OS resources do not behave as expected and the failure cascades into WMQ.
Usually when these errors are thrown, WMQ will produce an FDC file in {WMQ install dir}/errors to record the event. The FDC file tells which executable failed, the function that was executing during the failure, the environment, user ID and many other details. These can be used by IBM to diagnose the problem but are often useful for WMQ admins as well.
As a general rule, for any WMQ error that you cannot easily diagnose, take a look in:
{WMQ install dir}/qmgrs/{qmgr name}/errors/AMQERR01.LOG
{WMQ install dir}/errors/AMQERR01.LOG
{WMQ install dir}/errors/*.FDC
When reporting an error, please post whether you found any error log entries or new FDC files in these locations and if so what the content of these was. This will make it easier for respondents to to provide answers that are specific and relevant. If you care to update your question with diagnostic info from the errors directories, I'll be happy to update this response in kind.
You might encounter this code after changing your NT password, as the service tries to log on with your saved credentials.
Change the UID/pwd through the command console -
AMQMSRVN -user \ -password
And, to be safe, in ther services menu, update the stored passwords for Services MQSeriesBrokerROL_ACB_BROKER and MQSeriesServices in properties -> LogON