Writing to Msg (SMAT) File?

Marcus, not sure if you can do it outside the thread.  I search through the SMAT data using the .msg files.

I haven’t seen the option to write message to a SMAT file by a tcl. What you could do though is write a tcl-proc that writes/echos the current message to a file. All messages will then be written to this file and you can browse/search through it. We used to do that a lot, but now mostly use the normal SMAT files.

Another option is to make a new thread, send the messages you want to this thread and turn on SMAT.

I’ve never tried it, but the format of the .msg and .idx files is pretty simple.

Messages are simply written to the .msg file and the .idx entries are indexes to those messages with offsets to the beginning of each message.

Why don’t you just route your messages to a file:/dev/null thread and turn on saved messages for that thread? Seems a lot simpler than trying to write your own smat files.

Why don’t you just route your messages to a file:/dev/null thread and turn on saved messages for that thread? Seems a lot simpler than trying to write your own smat files.

Agreed, but the original question asked about writing SMAT “from TCL without going through the thread process”.

And I’m saying that’s a bad idea.

Because it’s more complicated, there’s the potential for introducing problems that could cause the log file to be incorrect or for the existing process to have problems.

But more importantly, the format of .idx and .msg files has changed (and may continue to change) between Cloverleaf releases. You’ll have to revisit this code every time you do an upgrade.

Greetings,

Just want to chime in here on caveats about writing to files under the direct management of the Engine processes and also about revisions as Cloverleaf continues its march down the road of “change” here.

Caveats:

(1) The SMAT files are open for update by the cmd module in a running engine, that is, the process itself in Cloverleaf.  I am of the opinion you are introducting the dangers of update collisions between your external process and the Cloverleaf process.  We don’t know here if more than one update string is allowed at any one time to these SMAT files.

(2) After 5.7 the integrator now includes message metadata in the .msg files for each message starting with 5.8.  As we have custom logic that reads and extracts messages for resend or for display directly from SMAT .msg files these require rewrite/modification.  I do believe the inclusion of metadata in the .msg files was an enhancement request at one time.  It also appears to support the latest Global Monitor 5.0 feature of displaying and allowing edit of the message metadata in its new SMAT feature.

So… I would say if you need to save messages which reflect SMAT images of sent or received messages, consider writing them to a separate file or to a database.

My .025 cents worth.

Enjoy.

All good observations.

My understanding/interpretation of Marcus’ original question was something like “…can I write a SMAT-compatible file independent of the SMAT written by CL?”

My answer to that was “likely”. I’m not necessarily advocating for that.

There are certainly maintainability concerns as new versions of the SMAT are rolled out. And it’s definitely a bad idea to directly write a SMAT file that’s currently being managed by the engine – almost sure to cause mayhem.

Jeff and company,

For what it is worth, I did have an opportunity to Beta Test both the 5.7 and 5.8 engine feature known as “Message archiving”.  It is available in the thread properties in the NetConfig.  However, you need to purchase an ODBC license to turn it on and install ODBC software from Lawson Cloverleaf as well and do some other configuration work to get it operational such as setting up an alert to “make it work” (klunky in my opinion).   My feedback to Cloverleaf R & D was to say the least not very complimentary.

In my Beta testing, I had directed the output to an MS-SQL database that was established by our Data Warehouse group.  The default table keys are all SMAT metadata values.  I was unsuccessful in getting any other values to be lookup keys in the database though R & D maintained that is doable but only in the 5.8 integrator.

For me the best option to save messages of interest is write them to your own file.  You can always design some sort of key companion file to do lookups.  TCL does have seek and read options to manipulate  a file like an .idx using offsets and record lengths.  That does work – my experiments have demonstrated that to my satisfaction.  Not implemented here but retained as an option just in case.  We mostly just save them off to flat files and archive them elsewhere.

Hope this helps someone out there in this Forum.

Have a great day!

Writing messages to a MySQL or SQLite table is both easy and fun!!  😉