I recently implemented some minor changes in my qm.ini configuration. My question is, if there is one or more error in the configuration file, can MQ sort out only the wrong config, or is the whole qm.ini get omitted?
Example:
Channels:
MaxChannels=3000
MaxActiveChannels=300
TCP:
KeepAlive=Yes
ListenerBacklog=7O0
The wrong config is in ListenerBacklog.
Is all config omitted, or only the ListenerBacklog not implemented ?
No, whole qm.ini file will not be ignored because of one erroneous value. MQ will read all the attributes in the ini file. In your case ListenerBacklog value might get truncated to 7 as there is a non-numeric character after 7.
Related
I am using Springboot version 2.7 and trying to configure the log pattern to be daily rolling.
I am currently using just the application properties file to configure the logging as that's the preference.
I added the following line in the properties file but does not seem to work
logging.logback.rollingpolicy.file-name-pattern=myservice-%d{yyyy-MM-dd}.log
Any clues what I may be missing?
Also, is there a way to check daily log rolling without having to wait for EOD :)
First, you have to specify the file name:
logging.file.name=myservice.log
then you can use the rolling file name pattern
logging.logback.rollingpolicy.file-name-pattern=myservice-%d{yyyy-MM-dd}.log
To force the file change you could set the size to something small
logging.logback.rollingpolicy.max-file-size=100K
To specify the directory you must set this property
logging.file.path=/var/logs
The documentation can be found here:
https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.logging
I am trying to read the data from following cap files.
everyhing from alerts folder
http://dd2.weather.gc.ca/alerts/cap/20180205/CWHX/14/
I am using AMQP from http://metpx.sourceforge.net. And when I am trying to connect to subscriber from nifi, I am getting the following error.
Failed to establish the connection with AMQP broker
this is my cap.conf file.
broker amqp://anonymous:anonymous#dd.weather.gc.ca
directory /data
subtopic alerts.cap.#
accept .*
mirror True
Over the summer, the broker migrated to SSL, so the current URL would be: amqps://anonymous:anonymous#dd.weather.gc.ca
The web page has also moved to: https://github.com/MetPX/sarracenia
best practice to put authentication info in ~/.config/sarra/credentials.conf
a line like: amqps://anonymous:anonymous#dd.weather.gc.ca
Installing a version from the past year is likely to be a much
better experience. It now comes with sample configurations,
one of them being ddc_cap-xml.conf which is the same data you
are trying to download.
So the work is:
blacklab% sr_subscribe add ddc_cap-xml.conf
blacklab% sr_subscribe edit ddc_cap-xml.conf
# Change the directory option to suit your case.
blacklab% sr_subscribe foreground ddc_cap-xml.conf
And it should work. It could take many hours to prove it because this particular set (severe weather warnings in Common Alerting Protocol format) is produced only when needed, rather than continuously. (Use start instead of foreground to run as a background daemon.)
To test things, it might be easier to start with dd_swob, which will be a continuous feed.
blacklab% sr_subscribe list dd_swob
broker amqp://anonymous#dd.weather.gc.ca
exchange xpublic
#msg_skip_threshold 60
#on_msg ../msg_skip_old.py
subtopic observations.swob-ml.#
accept .*
In this configuration you need to add a directory option just before the accept line. and should start downloading data immediately. Once you know it works, switch back to the data set you actually want.
i'm working on qmgr migration from 6.0 to 7.0, but i got problem when restoring V6.0 queue manager from 7.0 on windows. After re-installing MQ 6.0, i copied back the previous backup QMGR data and log, and then tried to start up that QMGR, for instance TEST01. However, that command strmqm TEST01 returns with no such QMGR existed.
The restore procedure i refer to is from infor center below
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp
and i backup and restore MQGR data and log through as below:
Backup
copy C:\Program Files (x86)\IBM\WebSphere MQ\Qmgrs\TEST01 under another path
copy C:\Program Files (x86)\IBM\WebSphere MQ\log\TEST01 under another path
Restore
copy above backup folder back to target path
So according to above operation, did i miss anything or do something wrong?
UPDATE:
This issue has been fixed. I forgot backing up the configuration information from the registry and restored it then. That's why MQ cannot recognize my QMGR at the very beginning.
Additionally, I've got another question here:
how to transfer configuration information from the registry to the mqs.ini file?
You are far better off not to migrate QMgrs but rather to create new ones at the new version. Although IBM has always provided an upgrade path, the implementation of certain functionality differs from version to version. For example, on Windows the registry settings in V6 are no longer used in V7.1 and higher. The requirement to upgrade usually comes from the belief that replacing the QMgr somehow loses something.
In fact, this is rarely the case. There is also nothing special about a QMgr that well-designed client applications would need to know its name. The host, port and channel uniquely identify a QMgr for a client application. If the app specifies the QMgr's name and it does not match, the connection fails. But the app can specify a blank QMgr name and the connection will succeed. The QMgr's name is automatically filled into the Reply-To QMgr field so requests are properly handled. The only thing that needs to know the name is a QRemote (which can be repointed) or a local app using bindings mode connection.
That said, to answer your question just performing the upgrade to V7.1 or V7.5 will move the QMgr's settings to the ini file.
this issue has been fixed. i forgot backing up the configuration information from the registry and restored it then. that's why MQ cannot recognize my QMGR at the very beginning.
I am not able to retrieve records from flat file using fileadapter ver 5.6 with JMS. It always show this error at console,
Startup error. SDK Error: Could not open JMS shared library jms, DllError.
The error occurred on starting the adapter after initialization. The Repository URL is D:\bala\input\Work\AT_adfiles_53689.dat and the Configuration URL is Fileadapter/FileAdapterConfiguration..
Its working fine with RV but not with JMS. Kindly help me out..
I found the solution to the problem above. First look into the AT_adfiles_xxxxx.tra under your working adapter directory. Look for the line where it said "tibco.env.PATH=xxxxx"
First of all, look into all those bins directory, you will find some of the bin folder actually contain libeay32.dll" and "ssleay32.dll". The problem is where the sdk\5.5\bin contain different version of libeay32.dll" and "ssleay32.dll" to other folder. In order for you to run this correctly, all of libeay32.dll" and "ssleay32.dll" should be in the same version.
So which ever version you decided to use, make a copy of that to other folders that contain the same file. What i did to preserve the original version of those is by renaming the original with .bak at the end.
This should allow you to test the file adapter!
we are sending data trough MQ from a z/OS/CICS system to an AS400.
Original encoding of the message is CCSID 500 with a MQSTR Format. The client application is getting the message with the CONVERT option and CCSID 819.
Data is almost converted correctly except for the end of line caracter. Any idea?
The z/OS is sending 0D (CR) as end of line caracter. If they had 0D+0A (CR+LF), CCSID automatically change from 500 to 437, and the end of line still ain't right on the client side.
Have already you tried only "0A" (LF)? Have you tried without an expliciet CONVERT? We've never had any issues with this part of the conversion and our machine talks with windows, AIX, Linux and so. Almost all the time we do rely on automatic conversions.
Also, you may want to check the USER of your job that picks the MQ message from the Queue. Most of the time the USER uses the system attributes (as defined in the appropriate SYSVAL). Maybe this userprofile has been configured very specific and different from the SYSVAL which stops the iSeries in doing the correct automatic conversion.
As a simple test, FTP your data to the iSeries. That will also force an automatic conversion that uses the system tables (WRKTBL). That may show an error in that configuration.
We had a problem with the CCSID of the queue manager not being set correctly and the wrong conversion table used.