Any help or hint would be greatly appreciated it!!
Where is the IBM MQ logs locate on the solaris box MQ SERVER ?
Based on ibm documentation:
Based on ibm documentation online url there should be an errors folder.
https://www.ibm.com/docs/en/ibm-mq/9.1?topic=windows-error-log-directories
As JoshMc said, the queue manager related information is under /var/mqm/ directory.
i.e.
/var/mqm/errors/ directory has log files for general MQ issues and where you will find FDC files.
/var/mqm/qmgrs/{QMgrName}/errors/ directory contains the log files related to a particular queue manager.
Related
I am searching for the default Log format of the IBM Portal Server used for the Systemout.log and SystemError.log files. I have referred many links to find it. From where Portal Server picks the Log format for the these log files?
And also Can we change this log formate?
If you go into the was admin console and go under
Application servers > WebSphere_Portal > WebSphere_Portal > JVM logs there you can pick either basic of advanced for the formatting
Unable to restart the queue manager getting error message as AMQ7017 Log not available
Checked the FDC file and getting the error message as AMQ6118 An internal WebSphere MQ error has occurred 7017
We have remounted the file system and log file is also exists but still not able to restart the queue manager
please let us know your suggestions ASAP
The queue manager generates AMQ7017 for different reasons and following are some of the reasons.
The queue manager was not able to find a specific log file
Your update indicates the log file is there.
Problem in accessing the log file
Check the file permissions of the log files and log control file
If you see any FDCs with BADLSN errors, then there is a possibility of
a MQ defect or a file system issue.
Check for any known defects fixed. But in some cases, an APAR fix only
prevents the problem in future and may not fix the current issue in
queue manager restart.
An immediate workaround would be to backup the queue manager and then rebuild or recreate the queue manager or restore from backup. If this not an option then I suggest opening ticket with IBM.
I don't have access to a WebSphere console, but I need to check if encryption is enabled between the console and appserver connection. The docs I have come across are almost all console related, and I am unable to find what I need. Where would I be able to find this config file setting?
Thanks
I suppose you are looking for WCInboundAdminSecure : it should be located in :
{WAS_HOME}/config/cells/{your cell}/nodes/{your node}/servers/{your server}/server.xml
Following process in our linux server is taking 100% of CPU
java -DMQJMS_LOG_DIR=/opt/hd/ca/mars/tmp/logs/log -DMQJMS_TRACE_DIR=/opt/hd/ca/mars/tmp/logs/trace -DMQJMS_INSTALL_PATH=/opt/isv/mqm/java com.ibm.mq.jms.admin.JMSAdmin -v -cfg /opt/hd/ca/mars/mqm/data/JMSAdmin.config
I forcibly killed the process and bounced MQ then i don't see this. What might be the reason for this to happen?
The java process com.ibm.mq.jms.admin.JMSAdmin is normally executed via the IBM MQ script /opt/mqm/java/bin/JMSAdmin.
The purpose of JMSAdmin is to create JNDI resources for connecting to IBM MQ, these are normally file based and stored in a file called .binding, the location of the .binding file would be found in configuration file that is passed to the command. In your output above the configuration file is /opt/hd/ca/mars/mqm/data/JMSAdmin.config.
JMSAdmin is an interactive process where you run commands such as:
DEFINE QCF(QueueConnectionFactory1) +
QMANAGER(XYZ) +
...
I would be unable to tell you why it was taking 100% CPU, but the process itself does not directly interact with or connect to the queue manager and it would be safe to kill off the process with out needing to restart the queue manager. The .binding file that JMSAdmin generates is used by JMS applications in some configurations to find details of how to connect to MQ and the names of queues and topics to access.
In July 2011 you would have been using IBM MQ v7.0 or lower all of which are out of support, if anyone should come across a similar issue with a recent supported version of MQ I would suggest you take a java thread dump and open a case with IBM to investigate why it is taking up 100% of the CPU.
*PS I know this is a 9 year old question, but I thought an answer may be helpful to someone who finds this when searching for a similar problem.
The file names seesm to point to our WAS data sources. However, we're not sure what is creating them and why there are so many. The servers didn't seem to crash. Why is WAS 6.1.0.23 creating these andy why aren't they being cleaned?
There are many files like these, with some going up to xxx.43.lck
DWSqlLog0.0.lck
DWSqlLog0.0
TritonSqlLog0.0.lck
TritonSqlLog0.0
JTSqlLog0.0
JTSqlLog0.1
JTSqlLog0.3
JTSqlLog0.2
JTSqlLog0.4.lck
JTSqlLog0.4
JTSqlLog0.3.lck
JTSqlLog0.2.lck
JTSqlLog0.1.lck
JTSqlLog0.0.lck
WAS uses JDK Logging and JDK logger creates such files with extension .0,.1 etc along with the .lck file so that the WAS runtime has a lock to these files that it writes to.
Cheers
Manglu