When I tried to start an FTE agent in the command prompt , it displays the error message as "An internal error has occurred. Unable to complete the command because the agent directory does not exist".
What would be the reason for this? It was working fine until yesterday. And is there any way to start an agent in MQ FTE itself? I use fteStartAgent in command prompt each time to start an agent.
Kindly advise me on this....
There are a few possible reasons for this. It is possible that the default properties were changed and now point to an invalid location. This usually happens when the different components are installed and you select to provide the connection details again rather than to reuse the existing configuration.
Another possibility is that the default properties have been changed to point to a different Coordination QMgr. Sometimes people want to run Prod and Dev agents on the same host and set up connectivity to more than one Coordination QMgr. The result is that the default properties can point to only one at a time and so some agent directories are found while others are not. The trick to making this work is to use the -P option to select the proper Coordination QMgr.
Related
I have installed OEM 13c and deployed a couple of agents and want to test out the Log File Monitoring utility. I have enabled it and added a log file to monitor.
When I go and test it out, it does not show any alerts when they are put into the Log File. On the agent server, I have tailed the file and see the messages coming into the log file.
Does anyone have experience adding log files to OEM? I could have configured it wrong. Or is there any troubleshooting steps that I can follow to see if the server is even contacting the agent for reading the log file. Status of the agent is good with no incidents.
Without access to the system, it would be difficult to tell you the exact cause of this issue. However, I can list a few potential causes of this issue that I have experienced personally:
Permissions. The Oracle Enterprise Manager Agent is very convoluted when it comes to system permissions within a remote server. The agent can be owned and run as any number of users but during metric evaluation, may also need sudo or pam-authentication permissions to access certain entities on the server. Depending on the authentication profiles on that server, this could be the cause of your issue. There are ways to grant the agent access through the PAM stack if that is necessary.
Syntax. The wildcard syntax in the OEM GUI can be a little confusing as well. I would play with the wildcard elements a bit on the "String" component to ensure that it isn't as simple as adding wildcards to the beginning and end of the string. Without diving into the binaries of the agent plugins, it is difficult to assess exactly how the agent is evaluating this particular metric
One suggestion I would have is to go through the agent commands. There are specific commands you can run to manually force an agent to evaluate a particular metric for a particular target. This can allow you to manually trigger the metric collection locally on the server and evaluate what exactly is being performed at the agent level.
On the system I was running (12c) the command was as follows:
emctl control agent runCollection <hostname>:host host_storage
I am looking for a command to change the message broker message flow instance in the run time. I know it is quite easy with MB explorer. But I am more interested towards the server side mqsi command. Ours is a AIX env with message broker 8 installed.
The number of instances a message flow has on the execution group is configured in the BAR file, before deployment.
If you want to change the number of additional instances you will need to redeploy your flow.
You can use the mqsiapplybaroverride command to change the configuration of the flow in the BAR file, and the mqsideploy command to redeploy the BAR.
As of IIB v9 you can control the number of instances dynamically at runtime by assigning a workload management policy.
See the description here:
http://www-01.ibm.com/support/knowledgecenter/SSMKHH_9.0.0/com.ibm.etools.mft.doc/bn34262_.htm
Once you have assigned a policy you can change it using the mqsichangepolicy command specifying an xml policy document that has a different number of instances.
Alternatively you can use the web ui to change it directly on the running broker.
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
I've compiled and trolled around the quickfix ( http://www.quickfixengine.org ) source and the examples. I figured a good starting point would be to compile (C++) and run the 'executor' example, then use the 'tradeclient' example to connect to 'executor', and send it order requests.
I created two seperate session files one for the 'executor' as an acceptor, and one for the 'tradeclient' as the initiator. They're both running on the same Win7 pc.
'executor' runs, but tradeclient can't connect to it, and I can't figure out why. I downloaded Mini-fix and was able to send messages to executor, so I know that executor is working. I figure that the problem is with the tradeclient session settings. I've included both of them below, I was hoping someone could point out what's causing them to not communicate. They're both running on the same computer using port 56156.
--accceptor session.txt----
[DEFAULT]
ConnectionType=acceptor
ReconnectInterval=5
SenderCompID=EXEC
DefaultApplVerID=FIX.5.0
[SESSION]
BeginString=FIXT.1.1
TargetCompID=SENDER
HeartBtInt=5
#SocketConnectPort=
SocketAcceptPort=56156
SocketConnectHost=127.0.0.1
TransportDataDictionary=pathToXml/spec/FIX50.xml
StartTime=07:00:00
EndTime=23:00:00
FileStorePath=store
---- initiator session.txt ---
[DEFAULT]
ConnectionType=initiator
ReconnectInterval=5
SenderCompID=SENDER
DefaultApplVerID=FIX.5.0
[SESSION]
BeginString=FIXT.1.1
TargetCompID=EXEC
HeartBtInt=5
SocketConnectPort=56156
#SocketAcceptPort=56156
SocketConnectHost=127.0.0.1
TransportDataDictionary=pathToXml/spec/FIX50.xml
StartTime=07:00:00
EndTime=23:00:00
FileLogPath=log
FileStorePath=store
--------end------
Update: Thanks for the resonses... Turns out that my logfile directories didn't exist. Once I created them, they both started communicating. Must have been some logging error that didn't throw an exception, but disabled proper behavior.
Is there an error condition that I should be checking? I was relying on exceptions, but that's obviously not enough.
It doesn't seem to be config, check that your message sequence numbers are in synch, especially since you've been connecting to a different server using the same settings.
Try setting the TargetCompID and SenderCompID on the acceptor to *
I realise there are some similar questions on here already but I couldn't see one that matched my problem so I'm afraid I had to ask a new question.
I have a webservice running on a server, which is throwing a ORA-12154: TNS:could not resolve the connect identifier specified" error. However when I log onto the said server i am able to tnsping the entry successfully, and connect to it via sqlplus, but not through the webservice.
If anyone has any suggestions as to things to look for then I would greatly appreciate it.
Cheers
Some other things to look at include:
If you're using a service name instead of SID, are you specifying the entire service name?
If you're using the ORACLE_SID environmental variable, check the case (mydb vs MYDB)
Check for a sqlnet.log file
If you're using a username/password#SID connect string, you may need to quote your password if it contains special characters (like an # symbol).
The webservice can't find tnsnames.ora which usually means that you didn't set up Oracle's environment properly when starting the process. This usually means you didn't source oraenv.sh in the shell script which starts it.
So your interactive login works - what is different between your interactive login and the user that runs your web service?
Are they the same user? If not then you will need to update some of your configs in order to make the Oracle client files available to the webservice.
Details like Operating System, Oracle Version, etc are always a help.