Setting DESTCONN issues

[Richard Hart]

We have some business rules for LAB messages that require a Support Group to check the message and advise us whether to send to their application or discard.

For many years, we’ve sent these messages to the Cloverleaf error database and emailed the support group the details.

I’ve recently made some code changes to send these messages to a ‘dummy’ thread with an attached SMAT file rather then the error database.  The thread is a file protocol to /dev/null.

I’ve coded a routing solution for a similar site that has been in production without issue for a few years.

The TCL code, on an inbound thread, sets the DESTCONN to the ‘dummy’ thread and performs a SEND.

Unit testing was successful and installation in test worked for a few weeks and then failed (PANICed) for the first time last week – by pure fluke (I hope) within 10 minutes of the prod site!

   PANIC: “mid != ((struct MessageId *) 0)”

   PANIC: Calling “pti” for thread ccm_prod_ih_cmd

The prod site PANICed again this morning, but on restart, all messages that were supposed to be in the SMAT file were there and all looked fine.

I have not been able to reproduce this.

has anyone any ideas?

My guess is that a message copy and DESTCONN set will fix this.

Topic

[Richard Hart]

I managed to re-create this issue by adding a further set of threads connected to the ‘in’ threads that perform the translation, so it was more prod like.

ie

out –[tcp socket]–>in–[cloverleaf route]–>snd–[tcp socket]–>application rcv

with the out, in and snd threads in a Cloverleaf site and the out threads in a separate process.  

Sending 100’s of messages (hcicmd ob data) to the out threads PANIC’d the site very quickly.

The msgcopy did not work.

The fixes that worked were to replace the static route with routes for

  ‘required’ messages; or

  ‘investigate’ messages

Or process the messages in a similar way and use the pre output TPS to send to the new destination.

[Author]

Replies