Are you tired of manually deploying your software? Please check the Simple Software Publication System. It’s still in development, but it already is able to help me.
In WebSphere MQ 7, IBM has changed the default Coded Character Set Identifier (CCSID) and that may cause problems in certain conditions. I’ve encountered this problem while working on a Java application that used JMS to communicate with a legacy C/C++ application running on HP-UX. While the communication with other Java/JMS applications worked flawlessy, the communication with its non-JMS backed caused it to throw the MQRC_NOT_CONVERTED (reason code 2119) to be thrown.
This exception occurs because the queue manager failed to convert between different CCSIDs. Luckily, the problem is documented with great detail by IBM, along with several ways to resolve it. I’ve found that the easiest way to resolve the problem is by setting the following parameters during the JVM startup (you can replace 819 with target CCSID):
This solution, however, requires the application where the exception is thrown, to be running at least version 220.127.116.11.
In the last posts I presented general guidelines to improve your logging practices. Today we’ll discuss further about how and what you log. We will focus in some techniques to help you write clear and descriptive log messages.
A friend of mine, who read the first article, asked me to elaborate further about good logging practices. Hence, I decide to go over some of them, point the problems and discuss the alternatives. I will try to discuss the items in the order they appeared on the article. To start this series of texts, let’s discuss about fancy logs.
Given how easy is to log your application flow these days, it comes as no surprise that many developers abuse and misuse them. There are many anti-patterns that can be applied to logging and this article tries to help you avoid some of them.