Learn How to Code in Python With Microsoft’s Free Classes

October 21, 2019 Roger Lacroix

Microsoft has created free instructional videos on Python. Microsoft has uploaded a 44-part series to YouTube dubbed Python for Beginners, which can teach anyone how to program in Python.

Regards,
Roger Lacroix
Capitalware Inc.

Education, Programming Comments Off on Learn How to Code in Python With Microsoft’s Free Classes

Windows and UHD 4K Resolution

October 7, 2019 Roger Lacroix

Another interesting problem/issue that I’ve come across while installing software on my new ASUS ZenBook Pro laptop was that some older 32-bit applications don’t show the images, toolbar icons, etc. correctly. The applications are not “DPI Aware” but for Windows 10, it defaults to applications being “DPI Aware”.

Hence, if you can upgrade to a more modern version of the application(s) then do it but if not, here is a quick way to fix the problem.

(1) Either on the program’s short-cut or the executable, right click and select Properties
(2) Click the Compatibility tab
(3) Click the Change high DPI settings button
(4) Click the checkbox Override high DPI scaling behavior
(5) In the Scaling performed by: dropdown, change it to System
(6) Click Ok and then Ok, to save and close the windows.

Now when you start the application, it should look more normal.

Do you use Java applications on Windows 10 with a high resolution? Oracle has/had some developers that made some really stupid decisions and when I say stupid, I mean so stupid it would make Homer Simpson look like a genius (that kind of stupid).

In Java 6 (from what I can gather), Oracle decided to add the metadata tag to the “java.exe” and “javaw.exe” executables called DPIAware and set it to true. This would be great if they added the code to Java to support it but they only half-ass it. Then when people complained, Oracle added the JVM environment variable “sun.java2d.dpiaware” that you could set to “false” to disable it. For Java 8, Oracle removed the JVM environment variable “sun.java2d.dpiaware” for some unknown reason which meant you were screwed again.

Therefore, if you want your Java applications to be correctly displayed on Windows 10 with high resolution display then you need Java 9 or higher.

Now if you are in a corporate environment where you cannot change the release of Java you are using to Java 9 or higher then follow the instructions above for the “java.exe” and “javaw.exe” executables. More often then not, you can find the “java.exe” and “javaw.exe” executables in the following directory:
C:\Program Files\Java\jre(version#)\bin\

Regards,
Roger Lacroix
Capitalware Inc.

Java, JMS, Windows Comments Off on Windows and UHD 4K Resolution

Unable to load DLL ‘sqlceme35.dll’ and My Invoices & Estimates Deluxe V10

October 7, 2019 Roger Lacroix

Over the weekend, I started installing software on my new ASUS ZenBook Pro laptop. I was installing My Invoices & Estimates Deluxe V10 on my laptop and it said it also needed to install Microsoft SQL Server Compact 3.5 SP1. I clicked Yes and let it do its thing.

My Invoices & Estimates started fine but when I selected my “company” (aka database) to open then I got the Unable to load DLL ‘sqlceme35.dll’ error message.

I even tried uninstalling and installing it again but no luck.

This is just weird. Here’s a little history and you will see why it is weird.

In 2008, I purchased My Invoices & Estimates. In 2009, Avanquest Software released My Invoices & Estimates Deluxe V10. They had an upgrade offer at the time, so I upgraded to it. Back in 2009, my desktop PC was running Windows XP 32-bit (and laptop was running WinXP 32-bit). In 2011/2012, I got a new desktop PC running Windows 7 Pro 64-bit and a new laptop running Windows 7 Home 64-bit. I installed My Invoices & Estimates Deluxe V10 on both and did not have any issues. My Invoices & Estimates Deluxe V10 is a 32-bit program. If it works on Windows 7 64-bit then it should work on Windows 10 64-bit. I checked Avanquest Software’s web site for My Invoices & Estimates Deluxe V10 and it says that it supports Windows 10. Hence, you can see why it is weird that I got the error message: Unable to load DLL ‘sqlceme35.dll’.

I did an internet search and very little came up on the issue with My Invoices & Estimates. I did find one hit about the same issue where Avanquest Software’s support told the user to contact Microsoft. Terrible support response.

So, I just starting searching for the error message only. Tons and tons of hits were coming up. After reading a bunch, I stumbled on one at StackOverflow where “codeulike” said they were having an issue with a 32-bit application running on Windows 7 64-bit and getting the same error message and said:

Following this rather confused discussion on MSDN revealed that I needed to use the 64-bit MSI for SQL Server Compact on 64-bit machines. D’oh! That is, from page Microsoft SQL Server Compact 3.5 Service Pack 1 and Synchronization Services for ADO.NET version 1.0 Service Pack 1 for Windows Desktop I needed SSCERuntime-ENU-x64.msi rather than SSCERuntime-ENU-x86.msi for 64-bit machines.

I scratched my head and thought, why in the world would a 32-bit application need the 64-bit release of Microsoft SQL Server Compact 3.5 SP1. I figured, its Windows, if it doesn’t fix the problem then I’ll just uninstall it.

I downloaded SSCERuntime-ENU-x64.msi from Microsoft and installed it. Reboot (just in case) and then started My Invoices & Estimates and shockingly, when I clicked on my “company”, My Invoices & Estimates worked perfectly. I have no idea why a 32-bit application needed the 64-bit release of Microsoft SQL Server Compact 3.5 SP1 or why Windows needed the 64-bit release to run a 32-bit program but it was required.

I have 100s of utilities installed on my hard-drive. Now normally, if one did not work, I would simply delete it and search the internet for a better/working one. My Invoices & Estimates is such a simply program but what it does, it does it extremely well. It makes generating quotes (estimates) and invoices so easy. It has lots of reports for sales and accounts receivable. Hence, that is why I spent hours and hours on Saturday trying to solve my problem because it would be maddening to have to switch to a different sales program.

Therefore, I figured I would write/post this blog entry to help other small businesses who may be upgrading their desktop PC or laptop from Windows 7 to Windows 10 64-bit and get the Unable to load DLL ‘sqlceme35.dll’ error message. Hopefully, the search engines will pick up my posting and when others have the issue, they will see that they need to install the 64-bit release of Microsoft SQL Server Compact 3.5 SP1 to fix their issue.

Regards,
Roger Lacroix
Capitalware Inc.

.NET, Database, Windows Comments Off on Unable to load DLL ‘sqlceme35.dll’ and My Invoices & Estimates Deluxe V10

SQLite v3.30.0 Released

October 7, 2019 Roger Lacroix

D. Richard Hipp has just released SQLite v3.30.0.
http://www.sqlite.org/news.html

SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. SQLite is the most widely deployed SQL database engine in the world. The source code for SQLite is in the public domain.

Regards,
Roger Lacroix
Capitalware Inc.

C, Database, IBM i (OS/400), Linux, macOS (Mac OS X), Open Source, Programming, Unix, Windows, z/OS Comments Off on SQLite v3.30.0 Released

Time to Move to Windows 10

October 3, 2019 Roger Lacroix

I’m sure lots of people will read the title and say WTF!?! What have you been using? I’ve been using Window 7 Pro since late 2011. Since Microsoft’s support of Windows 7 will end in January 2020, I figured it was time to move on.

My ASUS ZenBook 13.3″ and desktop PC still work reasonable well but I know they are nowhere near as fast as the current hardware that is out in the world.

Picking out a new desktop PC is easy because I simply tell Alan at Mega Computers what I want but for the laptop, it is much harder to get everything I want (and at a reasonable price).

In early September, both Best Buy and Staples (in Canada) had Lenovo ThinkPads on sale at a really good price but CPUs were not very fast and the screen resolution was the standard 1920 x 1080.

Next, I looked at Dell Latitudes and ASUS laptops. I couldn’t quite get the configuration I wanted at a reasonable price. I wanted a laptop with a reasonable fast CPU, SSD only, high resolution display and Win10 Pro (I don’t want Win10 Home). I don’t understand why all the high resolution displays are touch screen. I don’t need/want a touch screen. My fat fingers and touch screens just don’t get along! I hate paying for something that I don’t need and won’t use.

After a bunch of searches and reading reviews, I narrowed my selection down to 2 ASUS laptops:

  • ASUS GU502GU-XB74 ROG Zephyrus S 15.6″
  • ASUS UX550GE-XB71T Zenbook Pro 15.6″ UHD 4K Touch

    • I was leaning towards the ASUS ROG laptop until I read a review comparing the 2 CPUs at TechSpot. They said that “there’s not much difference between the 8750H and 9750H”. Last week, Amazon had the ASUS ZenBook Pro on sale for $1999 CAD ($300 off) – that’s rough $1500 USD. So, I decided to take the plunge and buy the ASUS ZenBook Pro.

    It came just before the weekend. I played around with it on the weekend. It is a really nice laptop. Actually, the first thought I had when I took it out of the box was that it was gorgeous. I’m a geek. I think in terms of gigabytes and megahertz but not gorgeous! But it is one fine looking laptop!! 🙂

    Here are the ASUS Zenbook Pro 15.6″ specs:
    – 15.6″ UHD 4K touch display 3840×2160
    – Intel 8th Gen Core i7-8750HK
    – 16GB RAM
    – 512GB SSD
    – NVIDIA GeForce GTX1050Ti
    – HDMI, USB-C, USB 3.1 ports & SD card reader
    – Wireless 802.11ac

    As I said earlier, ordering a desktop PC is really easy. Last week, I sent an email to Alan at Mega Computers with the following specs:
    – Intel Core i9-9900K
    – 32GB RAM G.SKILL Ripjaws V Series DDR4 3600MHz
    – ASUS PRIME Z390-A
    – Samsung 970 EVO NVMe M.2 2280 250GB PCI-E 3.0 SSD
    – Samsung 970 EVO NVMe M.2 2280 2TB PCI-E 3.0 SSD
    – LG WH14NS40 14x Blu-Ray Writer
    – ThermalTake Versa H25 case
    – Windows 10 Professional

    My 2 Samsung SA450 monitors (each 1920×1200) are still in good working order, so I didn’t need new monitors. If you look closely at the list for the desktop PC, you will notice that I did not purchase a video card either. I’m not a gamer. The ASUS PRIME Z390-A motherboard comes with embedded Intel HD Graphics with 2 ports:
    – Supports HDMI with max. resolution 4096 x 2160 @ 30 Hz
    – Supports DisplayPort 1.2 with max. resolution 4096 x 2304 @ 60 Hz

    The Samsung SA450 monitors only have inputs for DVI and VGA but Alan said he would supply 2 adapters/converts for free: HDMI to DVI and DisplayPort to DVI. They tested it and said it worked fine. I have since tested it and everything looks good. I can extend my desktop across both monitors.

    I picked it up on Saturday and played around with it a little bit. Its a very speedy PC but the laptop is better looking. Ahhh, ha ha ha ha ha ha. 🙂

    Now comes the pain of installing everything on both the desktop PC and the laptop. That’s the part I’m not looking forward to. 🙁 So, many applications/programs to install (on 2 machines). Plus now I have to learn where things were moved to under Windows 10 (vs Windows 7).

    Regards,
    Roger Lacroix
    Capitalware Inc.

    Capitalware, Windows Comments Off on Time to Move to Windows 10

    2 New IBM MQ RFEs related to com.ibm.mq.jmqi.defaultMaxMsgSize

    September 20, 2019 Roger Lacroix

    Please review and vote for these RFEs if you think they are a good idea. The links below will take you directly to the RFE.

    RFE #1:
    Document com.ibm.mq.jmqi.defaultMaxMsgSize JVM environment variable

    URL to review the RFE and Vote for it if you like:
    http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=136680

    RFE #2:
    Add & Document com.ibm.mq.jmqi.defaultMaxMsgSize for .NET Framework

    URL to review the RFE and Vote for it if you like:
    http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=136681

    Regards,
    Roger Lacroix
    Capitalware Inc.

    .NET, IBM i (OS/400), IBM MQ, Java, JMS, Linux, macOS (Mac OS X), Programming, Unix, Windows Comments Off on 2 New IBM MQ RFEs related to com.ibm.mq.jmqi.defaultMaxMsgSize

    WebSphere MQ Fix Pack 5.3.1.16 for HP NonStop Server Released

    September 19, 2019 Roger Lacroix

    IBM has just released Fix Pack 5.3.1.16 for WebSphere MQ for HP NonStop Server:
    https://www.ibm.com/support/pages/websphere-mq-hp-nonstop-server-v531-fix-pack-53116

    Regards,
    Roger Lacroix
    Capitalware Inc.

    Fix Packs for MQ, HPE NonStop, IBM MQ Comments Off on WebSphere MQ Fix Pack 5.3.1.16 for HP NonStop Server Released

    IBM MQ Fix Pack 8.0.0.13 Released

    September 19, 2019 Roger Lacroix

    IBM has just released Fix Pack 8.0.0.13 for IBM MQ
    https://www.ibm.com/support/pages/fix-pack-80013-websphere-mq-v8

    Regards,
    Roger Lacroix
    Capitalware Inc.

    Fix Packs for MQ, IBM i (OS/400), IBM MQ, Linux, Unix, Windows Comments Off on IBM MQ Fix Pack 8.0.0.13 Released

    JMS and Java Client Mode Performance Issues for MQ Get API Calls

    August 15, 2019 Roger Lacroix

    I’ve wasted far, far too much of my time inspecting what is going on with the auto-resizing of the get buffer for the internal JMQI and MQI components for MQ classes for JMS, MQ classes for Java and MQ classes for .NET.

    A strange entry in one of the MQ Auditor audit files got my attention. So, I thought I would test MQ classes for JMS and MQ classes for Java in client mode WITHOUT any JVM environment variables because this is how most of the world would be using their applications.

    For the test set of messages used and the MQ Auditor audit file layout (in particular the BufferLength and DataLength fields), please review the information from one of the previous blog postings.

    I’m going to be using MQTest12L.java and MQTestJMS12L.java which are the same programs I used in my previous tests. All 4 tests will be in client mode: 2 for MQTest12L.java and 2 for MQTestJMS12L.java.

    Test #1: MQTest12L.java client mode – MQGMO No Wait:

  • Load the 100 MQRFH2 messages into a queue
  • Run MQTest12L in client mode against the same queue
    • java MQTest12L -m MQWT2 -q TEST.Q1 -h 127.0.0.1 -p 1416 -c TEST.CHL -u tester -x mypwd

    Here is the MQ Auditor audit file. You can see that there are a total of 114 MQGets:

  • 100 successful MQGets
  • 13 unsuccessful MQGet with RC of 2080 (MQRC_TRUNCATED_MSG_FAILED)
  • 1 unsuccessful MQGet with RC of 2033 (MQRC_NO_MSG_AVAILABLE)

    • There are 3 instances of weird behavior:

  • At line # 22 in the audit file, you will see a successful MQGet with the parameters “BufferLength=19754, DataLength=19754”
  • At line # 23 in the audit file, the MQGet fails with RC of 2080 with the parameters “BufferLength=19754, DataLength=109471”. So, the internal JMQI component is suppose to allocate a new larger buffer of 109471 and issue the MQGet call again.
  • At line # 24 in the audit file, the MQGet fails with RC of 2080 with the parameters “BufferLength=23048, DataLength=109471”. Clearly, something went wrong because the new buffer used was wrong. The new buffer size for the second MQGet was suppose to be 109471 but it was 23048.
  • At line # 25 in the audit file, the MQGet is successful. It took 3 MQGet calls and 2 buffer re-allocations to get it right.
  • This happens again on lines # 31, 32 & 33 of the audit file
  • This happens again on lines # 42, 43 & 44 of the audit file

    • Test #2: MQTest12JMSL.java client mode – MQGMO No Wait:

  • Load the 100 MQRFH2 messages into a queue
  • Run MQTestJMS12L in client mode against the same queue
    • java MQTest12JMSL -m MQWT2 -q TEST.Q1 -h 127.0.0.1 -p 1416 -c TEST.CHL -u tester -x mypwd

    Here is the MQ Auditor audit file. You can see that there are a total of 118 MQGets:

  • 100 successful MQGets
  • 17 unsuccessful MQGet with RC of 2080 (MQRC_TRUNCATED_MSG_FAILED)
  • 1 unsuccessful MQGet with RC of 2033 (MQRC_NO_MSG_AVAILABLE)

    • There are 8 instances of weird behavior:

  • At line # 10 in the audit file, you will see a successful MQGet with the parameters “BufferLength=2568, DataLength=725”. Notice how it did NOT start with a 4KB. Another strange oddity.
  • At line # 11 in the audit file, the MQGet fails with RC of 2080 with the parameters “BufferLength=2568, DataLength=4602”. So, the internal JMQI component is suppose to allocate a new larger buffer of 4602 and issue the MQGet call again.
  • At line # 12 in the audit file, the MQGet fails with RC of 2080 with the parameters “BufferLength=4096, DataLength=4602”. Clearly, something went wrong because the new buffer used was wrong. The new buffer size for the second MQGet was suppose to be 4602 but it was 4096.
  • At line # 13 in the audit file, the MQGet is successful. It took 3 MQGet calls and 2 buffer re-allocations to get it right.
  • This happens again on lines # 14, 15 & 16 of the audit file
  • This happens again on lines # 21, 22 & 23 of the audit file
  • This happens again on lines # 24, 25 & 26 of the audit file
  • This happens again on lines # 27, 28 & 29 of the audit file
  • This happens again on lines # 35, 36 & 37 of the audit file
  • This happens again on lines # 46, 47 & 48 of the audit file

    • Test #3: MQTest12L.java client mode – MQGMO 100ms Wait:

  • Load the 100 MQRFH2 messages into a queue
  • Run MQTest12L in client mode against the same queue
    • java MQTest12L -m MQWT2 -q TEST.Q1 -h 127.0.0.1 -p 1416 -c TEST.CHL -u tester -x mypwd

    Here is the MQ Auditor audit file. You can see that there are a total of 14 MQGets and 100 MQCallBacks:

  • 10 successful MQGets
  • 3 unsuccessful MQGet with RC of 2080 (MQRC_TRUNCATED_MSG_FAILED)
  • 90 successful MQCallBacks
  • 10 unsuccessful MQCallBacks with RC of 2080 (MQRC_TRUNCATED_MSG_FAILED)
  • 1 unsuccessful MQGet with RC of 2033 (MQRC_NO_MSG_AVAILABLE)

    • There are 3 instances of weird behavior:

  • At line # 43 in the audit file, the MQCallBack fails with RC of 2080 (parameters “CBC_BufferLength=110592, CBC_DataLength=109471”) because the previous MQCB call set the buffer size to 19754. So, the internal JMQI component is suppose to allocate a new larger buffer of 109471 and issue the MQGet call again.
  • At line # 45 in the audit file, the MQGet fails with RC of 2080 with the parameters “BufferLength=23048, DataLength=109471”. Clearly, something went wrong because the new buffer used was wrong. The new buffer size for the this MQGet was suppose to be 109471 but it was 23048.
  • At line # 46 in the audit file, the MQGet is successful. It took 1 MQCallBack and 2 MQGet calls and 2 buffer re-allocations to get it right.
  • This happens again on lines # 63, 65 & 66 of the audit file
  • This happens again on lines # 92, 94 & 95 of the audit file

    • Test #4: MQTest12JMSL.java client mode – MQGMO 100ms Wait:

  • Load the 100 MQRFH2 messages into a queue
  • Run MQTestJMS12L in client mode against the same queue
    • java MQTest12JMSL -m MQWT2 -q TEST.Q1 -h 127.0.0.1 -p 1416 -c TEST.CHL -u tester -x mypwd

    Here is the MQ Auditor audit file. You can see that there are a total of 18 MQGets and 100 MQCallBacks:

  • 10 successful MQGets
  • 7 unsuccessful MQGet with RC of 2080 (MQRC_TRUNCATED_MSG_FAILED)
  • 90 successful MQCallBacks
  • 10 unsuccessful MQCallBacks with RC of 2080 (MQRC_TRUNCATED_MSG_FAILED)
  • 1 unsuccessful MQGet with RC of 2033 (MQRC_NO_MSG_AVAILABLE)

    • There are 7 instances of weird behavior:

  • At line # 15 in the audit file, the MQCallBack fails with RC of 2080 (parameters “CBC_BufferLength=8192, CBC_DataLength=4602”) because the previous MQCB call set the buffer size to 4096. So, the internal JMQI component is suppose to allocate a new larger buffer of 4602 and issue the MQGet call again.
  • At line # 45 in the audit file, the MQGet fails with RC of 2080 with the parameters “BufferLength=2568, DataLength=4602”. Clearly, something went wrong because the new buffer used was wrong. The new buffer size for the this MQGet was suppose to be 4602 but it was 2568.
  • At line # 46 in the audit file, the MQGet is successful. It took 1 MQCallBack and 2 MQGet calls and 2 buffer re-allocations to get it right.
  • This happens again on lines # 20, 22 & 23 of the audit file
  • This happens again on lines # 37, 39 & 40 of the audit file
  • This happens again on lines # 42, 44 & 45 of the audit file
  • This happens again on lines # 47, 49 & 50 of the audit file
  • This happens again on lines # 67, 69 & 70 of the audit file
  • This happens again on lines # 96, 98 & 99 of the audit file

    • So, is the internal JMQI component working as designed for auto-resizing of the buffer? Clearly not. But then again, since there is no documentation on it, so who knows.

    I thought it was bad when the internal JMQI component was doing 2 MQGets for each application issued MQGet but 3 is just getting ridiculous.

    Regards,
    Roger Lacroix
    Capitalware Inc.

    IBM i (OS/400), IBM MQ, Java, JMS, Linux, macOS (Mac OS X), Programming, Unix, Windows, z/OS Comments Off on JMS and Java Client Mode Performance Issues for MQ Get API Calls

    .NET Performance Issues for MQ Get API Calls

    August 14, 2019 Roger Lacroix

    If you have read any of the following blog posting then you will know that I have a bee in my bonnet about the performance regarding Java/JMS MQGet API calls:

  • Tuning JMS Programs for Optimum MQ Get API Calls Performance
  • Tuning Java Programs for Optimum MQ Get API Calls Performance
  • How to Improve Your Java/JMS MQ Tuning Cred.
  • Pub/Sub Java/JMS MQ MQGet API Issue

    • Have you ever test-driven a nice looking sports car and every time you stepped on the gas pedal, you thought “wow, I expected more zip”. This kind-of describes the scenario for .NET applications issuing MQGet API calls. You expected more message through-put than you are getting.

    For the test set of messages used and the MQ Auditor audit file layout (in particular the BufferLength and DataLength fields), please review the information from one of the blog posting listed above.

    Test #1:

  • Load the 100 MQRFH2 messages into a queue
  • Run amqsbcg in bindings mode against the same queue

    • Here is the MQ Auditor audit file. You can see that there are exactly 100 successful MQGets and 1 unsuccessful MQGet with RC of 2033 (MQRC_NO_MSG_AVAILABLE). This is exactly what is to be expected. If you scroll to the right of any MQGET line, you will see that in every case the size of the buffer given to MQ (BufferLength field) is 256000 bytes.

    I have a simple C# .NET program that can be run in either .NET Managed-Mode or client mode called MQTest62.cs. You can download the source code from here. The structure of the .NET program is very similar to amqsbcg. It loops getting all messages until the queue is empty (it does not wait for more messages).

    Test #2 .NET bindings mode:

  • Load the 100 MQRFH2 messages into a queue
  • Run MQTest62 in bindings mode against the same queue
    • MQTest62.exe -m MQWT2 -q TEST.Q1

    Here is the MQ Auditor audit file. You can see that there are a total of 171 MQGets:

  • 100 successful MQGets
  • 70 unsuccessful MQGet with RC of 2080 (MQRC_TRUNCATED_MSG_FAILED)
  • 1 unsuccessful MQGet with RC of 2033 (MQRC_NO_MSG_AVAILABLE)

    • This means that MQTest62 performed 70% more MQGets API calls than amqsbcg to accomplish the same thing. So, lets analyze why there were 70 unsuccessful MQGets with RC of 2080.

  • The big difference between the internal JMQI routine (Java/JMS) and the internal MQI routine used by .NET is that the larger resized buffer is NEVER reused.
  • Hence, for every MQGet API that is larger than 4KB, the internal MQI routine will ALWAYS receive a RC of 2080 (MQRC_TRUNCATED_MSG_FAILED). The internal MQI routine will allocate a new larger buffer and the issue a 2nd MQGet API call. This newly allocated buffer is not used for future MQGet API calls.

    • For the client mode test, it will be the queue manager’s listener (MCA) that handles the interact with the queue manager and it uses MQCallBack API call rather than MQGet API call.

    Test #3 .NET managed mode:

  • Load the 100 MQRFH2 messages into a queue
  • Run MQTest62 in client mode against the same queue
    • MQTest62.exe -m MQWT2 -q TEST.Q1 -h 127.0.0.1 -p 1416 -c TEST.CHL

    Here is the MQ Auditor audit file. You can see that there are a total of 170 MQCallBacks and 1 MQGet:

  • 100 successful MQCallBacks
  • 70 unsuccessful MQCallBacks with RC of 2080 (MQRC_TRUNCATED_MSG_FAILED)
  • 1 unsuccessful MQGet with RC of 2033 (MQRC_NO_MSG_AVAILABLE)

    • This means that MQTest62 performed 70% more MQCallBacks API calls than amqsbcg to accomplish the same thing. So, lets analyze why there were 70 unsuccessful MQCallBacks with RC of 2080.

  • This is truly a funny one and is completely different from Test #1 and what the internal JMQI routine (Java/JMS) does.
  • Before every MQCallBack API call, you will see that there is an MQCB API call. The MQCB API call sets the MaxMsgLength field to 4KB in most of the cases. It rarely reuses any re-allocated buffer. Most of the time, for every MQCallBack API that is larger than 4KB, the internal MQI routine will receive a RC of 2080 (MQRC_TRUNCATED_MSG_FAILED). The internal MQI routine will allocate a new larger buffer and the issue a 2nd MQGet API call.
  • And then there are some really weird things, on line # 79 MQCB API call sets the MaxMsgLength field to 4096. On line # 80, the MQCallBack is issued but it fails with RC of 2080. If you look a little to the right, you will see “CBC_BufferLength=110592, CBC_DataLength=6587”. The buffer size if larger than the actual length of the message data but because MQCB API call set the MaxMsgLength field to 4096, this caused the MQCallBack API call to fail. Very, very strange.

    • IBM claims that the internal MQI routine that auto-adjust MQGet/MQCallBack buffer size up and down is working well and performance is not an issue. Clearly, this is not true.

    I would strongly suggest that someone open a PMR with IBM to get the .NET internal MQI routine for auto-adjusting the MQGet/MQCallBack buffer size fixed.

    Also, I cannot find any environment variables that control either the buffer size or threshold value for the auto-adjusting rotuine. I would also get IBM to add the same 2 environment variables that are used by the internal JMQI routine for Java/JMS:

  • com.ibm.mq.jmqi.defaultMaxMsgSize
  • com.ibm.mq.jmqi.smallMsgBufferReductionThreshold

    • Regards,
    Roger Lacroix
    Capitalware Inc.

    .NET, C#, IBM MQ, Programming, Windows Comments Off on .NET Performance Issues for MQ Get API Calls