PROPCTL configuration

[Donnerbart]

Hey folks,

We're using the ibmcom/mq container as TestContainer for a small integration test.

  @ClassRule
  public static final GenericContainer MQ = new GenericContainer("ibmcom/mq:latest") //
      .withEnv("LICENSE", "accept") //
      .withEnv("MQ_QMGR_NAME", "QM1") //
      .withEnv("MQ_ENABLE_EMBEDDED_WEB_SERVER", "false") //
      .withEnv("MQ_APP_PASSWORD", "<redacted>") //
      .waitingFor(Wait.forLogMessage(".*Automatic MQSC configuration script has completed.*\n?", 1));

So MQ_DEV is true and we're using the default queues like DEV.QUEUE.1 in our tests.

My question is how we can configure PROPCTL in this setup (for the default objects).

[arthurbarr]

The default developer configuration is really only there to help you get started. If you need to change it, you can add your own MQ objects. For reference, the default MQ configuration is here. You can build a new image layer (e.g. FROM ibmcom/mq), and add MQSC and INI files into /etc/mqm/, and they will be applied automatically.

[Donnerbart]

Adding a custom file mapping shouldn't be a big problem, since TestContainers offers a convenient method to map files into an existing container:

// Map a resource (file or directory) on the classpath to a path inside the container.
.withClasspathResourceMapping("/mqsc.ini", "/etc/mqm/mqsc.ini", BindMode.READ_ONLY) //

Also thank you a lot for pointing me to the template file, that's a great start!

I'm already reading through the IBM MQ docs for two hours in total, but I cannot figure out how to configure that PROPCTL attribute for a queue. I searched for configuration files before, but always ended up with the qm.ini or mqs.ini docs.

Looking at that template, I guess I those are MQSC Commands. So I either add an ALTER QLOCAL command or modify the DEFINE QLOCAL to set PROPCTL. Is that the correct documentation I found?

I will need a day or two before I can pick up this task again, but is it as simple as changing the definition to DEFINE QLOCAL('DEV.QUEUE.1') PROPCTL(COMPAT) REPLACE?

[arthurbarr]

Yes, pretty much. I'd recommend adding your own configuration, for your own queues. For example, add the following to a file called 20-foo.mqsc:

DEFINE QLOCAL('DEV.FOO') PROPCTL(ALL) REPLACE

Then mount the file 20-foo.mqsc into the container as /etc/mqm/20-foo.mqsc, and it will get run every time you start the container. MQSC files are applied in alphanumeric order, so if you leave the default developer configuration in, it would apply everything in 10-dev.mqsc and then everything in 20-foo.mqsc. If instead you used the same queue name (e.g. DEV.QUEUE.1), then the first DEFINE (in 10-dev.mqsc) will create the queue, and the second one (in your new file) will re-create the queue, essentially over-writing any options which were set in the first file. So to avoid confusion, I'd probably be tempted to just call your queue something different (like DEV.FOO in my example above). As long as you prefix the queue name with DEV. you will still take advantage of the authority records created at the bottom of 10-dev.mqsc, which authorize the app user appropriately.

As a side note, you could also choose to use ALTER QLOCAL instead, but that can make it harder to track how you've defined things across the different files. Though I think it's an option if you really wanted to re-use DEV.QUEUE.1.

[Donnerbart]

That's some great advice, thank you!

I think I'll create new queues like DEV.DEFAULT, DEV.COMPAT, DEV.FORCE etc. then, so it's very clear from the usage in the tests which PROPCTL configuration is set. The queue name can be easily automated in a matrix test.

In the end we want to test the behavior of different put/get variants (MQMessage, MQMsg2, JMS) with different settings (provider version, message options) when using custom message properties. We want to figure out which combination breaks due to the unexpected payload.