Mark Taylor's Blog

Do we still need application developers?

I read an article at the weekend about the ChatGPT system, which included a link about how it might be useful for programmers. A lot of the recent material on this service has concentrated on its use for generating plausible text – essays and the like. But I thought it might be interesting to take a quick look for myself at the coding capability. How much can be delegated; do we still need application developers?

Spoiler: Yes we do. But it can be useful to look a bit deeper at the good and bad.

Update – Spring Boot and Jakarta Messaging

I wrote recently about the support for Jakarta Messaging that is part of IBM MQ 9.3 and work to integrate it with Spring. At that point, I gave the mq-jms-spring-boot-starter a pre-release version number as there was not a formal version of the Spring Framework and Spring Boot packages. But that changes this week, with the release of Spring Boot 3.0.0. And so there is now a corresponding MQ release of the starter package, also version 3.0.0 to match.

> Task :bootRun

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::                (v3.0.0)

2022-11-25T12:06:23.591Z  INFO 1091972 --- [           main] sample3.Requester                        : Starting Requester using Java 17.0.5 with PID 1091972 (mq-jms-spring/samples/s3.jms3/build/classes/java/main started by metaylor in mq-jms-spring/samples/s3.jms3)
2022-11-25T12:06:23.596Z  INFO 1091972 --- [           main] sample3.Requester                        : No active profile set, falling back to 1 default profile: "default"
...

Aside to the aside: this latest version of the MQ Boot Starter has new optional configuration parameters providing the equivalent of the -D command-line options that you might use for defining location and credentials for TLS keystores. Look at the ibmmq.jks parameters.

Snippet 3 – Converting between MQRFH2 and properties

There are preferred MQI functions for dealing with message properties. But sometimes you may have requirements for converting between MQRFH2 and properties. This post came out of a question posed by a developer on another IBM product. Oddly, it was the same product (though a different person) that prompted a previous Snippet. And I was able to use the same basic framework from that test to demonstrate how simple it can be.

Snippet 2 – Basic MQ Queue Rate monitoring

My previous post was about one small project I got involved with over the last week. This is another one prompted by working with an MQ user, this time to do with metrics. Essentially they had an urgent need to do some basic MQ queue rate monitoring: how many messages were put/got in an interval. More sophisticated observability, whether using a product like Instana, or tools such as these, would be a later exercise. I described what MQ can generate, and what some of the provided sample programs do, but decided it was more interesting to demonstrate it with real running code.

I also think of this as the coding version of the “Yes, And …” rule for Improv. Start with one piece and see where it leads. I ended up with 3 pieces – collect data, format data, display data. Each piece had some utility on its own, but I then thought “Yes, and then what can I do to demonstrate the next phase most effectively.”

Snippet 1 – Building an MQRFH2

Over the last week I’ve been working on some questions sent to me, and several have resulted in writing some test programs and scripts. This post shows the results of one of those exercises, building an MQRFH2 structure from scratch.

Recording queue manager object access

In this post I’ll talk about a new exit (Installable Service) that can be used with an MQ 9.3 installation for recording queue manager object access requests. It can provide a level of reporting who is using what and when. I’ll show what it does, how it does it, and what the limitations are.

Durable subscriptions to minimise object handle use

Collection of the metrics that the queue manager publishes requires that each monitored queue has at least one associated subscription. This post describes an interesting option where collection programs use durable subscriptions to minimise object handle use when running MQ monitoring. It reduces the requirements for configuring the MAXHANDS attribute on the queue manager. It’s also a nice demonstration of how subscriptions could be used in any application.

Supporting MQ Jakarta JMS in Spring Boot

One of the features of the newly-released MQ 9.3 is support for JMS 3, also known as Jakarta Messaging. There will be more information elsewhere about what that means for standalone JMS programs. There continues to be a JMS 2 package, of course, for ongoing compatibility. But JMS 3 introduces incompatibilities that mean that we need updated versions of other components to match if you want to move up to newer standards. This post will talk about supporting MQ Jakarta JMS in Spring Boot.

I’ll also discuss the issues I had when developing the new version – the annoying incompatible tooling upgrades I had to work through.

MQ application compatibility across a quarter century

I was working on something recently where I had to upgrade various components in the tooling. And I was getting more and more annoyed that the upgrades broke my existing programs and scripts. None of that was MQ’s fault and I’ll write more about the project once it’s available alongside the newly-announced MQ 9.3. [That article is now published here.] But it got me thinking about the efforts we’ve made to keep MQ application compatibility across its lifetime. I wanted to show how we’ve achieved that across a quarter century (and more). And how that has preserved the work that developers have put into their MQ programs. In particular, I want to see if old compiled programs can still work with a current queue manager.