Cloverleaf 6 SMAT files forced .old rename

We are experience the exact same issue.  We haven’t found the cause or fix yet either.

Mike C.

Peter,

Have you opened up a ticket with Infor support on this yet?  We’re planning to upgrade to 6.0 soon and are VERY interested to avoid this issue ourselves.  

Also, for both of you, what platform/OS version are you running on?

Thanks for the information,

Peter, I was wondering if you heard anything back from Infor support on the SMAT file issue?  We would like to proceed with upgrading our Prod sites but would like to get this resolved first.

Thanks.  Mike C.

Peter, do you have SmatHistory turned on in the Site Settings?

I’ve seen this issue “cycle save”  occurring on Cloverleaf 5.8.5 on Linux.

This issue first came about in 5.8.5 when there was an attempt to lock the smat file to a single user where before it was opened as read only to multiple uses.  You could toggle and edit the message and resend it with the only evidence of the edit was in the /hci/cis5.8/integrator/temp directory in a file named with a random name beginning with tmp.  It did not save the message you edited in smat as it does with this change.  You never know when the cycle happens. You can be in it perform various tasks get out back in then out again and back in an hour later and all of a sudden it cycles with out notification/error or any mention of it you only notice that it has 0 records or that it has 1 record.  Between the last time you got out and getting back in you do not know what happened to any and all messages between that time.  If they are lost that is critical, there is no way of knowing.

Peter, R&D has been unable to reproduce this issue in-house. Would you be willing to do a webex issue with them so you can demonstrate the problem?

From Cloverleaf R&D, This is a bug where the engine inconsistently uses upper- and lower-case in the encoding in the .ecd file while using a case-sensitive comparator.

They are working on a fix for a future patch.

Just started seeing this happen on a Windows server 2003 SP2 CL5.8.5.  Will there be a fix for 5.8?

Donna

Does Cloverleaf 6.0.1 include a patch for this SMAT cycle save issue?

No, not in 6.0.1. Maybe in 6.1.

What is the workaround for this bug?  We will not be able to upgrade to 6.1 so will need to manage this in 6.0 (on Windows OS).

Thanks in advance.

Also is there a work around for AIX 6.1?

We are also contemplating an upgrade to v6 and are hoping a patch will be made available soon.

According to R&D, this fix is scheduled for CIS 6.2 (AR 10093).

R&D is trying to get this into CIS 6.1.1.

Greetings,

Max, the post history does not include exactly WHAT the bug is here.

Please post what SMAT cycle bug is being discussed in this forum.

Thank you.

Is there a patch for this SMAT cycle save issue now? we are using version 6.0.

Max:

I have seen some anomalies with SMAT when multiple people are viewing saved messages for a thread.  Messages that should be there do not appear immediately in the SMAT.  I don’t *think* we’re losing any messages, but it’s making me nervous.

Please confirm if this patch has been included in 6.1.1.  We are about 4 weeks from a big go-live and don’t want to be having problems with SMAT data disappearing.

Checking with R&D …

If you use the SMAT database instead of SMAT files, then you don’t have this issue.

From R&D,

This is expected and done to not degrade engine writes to smat. We use SQLite

Max,

That reply from R&D seems to be referencing SMATdb not traditional SMAT.

So is that in response to the originally reported issue involving traditional SMAT?

Yes, this response was for SMAT DB only.

I understand the WAL function of SQLite – and that all makes sense.

The issue I’m having is with SMAT files.

Let’s say I’m doing some testing.  I send a message from system X bound for System Y and I’m saving outbound messages on the thread to “Y”.  

I’m not always seeing a message in the SMAT file after I know it’s been sent to “Y”.  It may show up a minute later, maybe right away – it’s not entirely predictable.  There seems to be more frequent (apparent) write delays if more than one user is viewing data in a given SMAT.

This behavior is different than my experience with our current CL5.6 engines.

Our new engines are 6.1.1

Is CL 6.x not flushing the file handle(s) it’s has open to write to SMAT?  That might give a nominal improvement in speed, but would reduce usability dramatically – and could also expose the SMAT files to data loss if there’s a power failure or if an engine process is killed forcibly.

Thanks!

This started out as a discussion about SMAT files (traditional) getting cycled when other actions are being selected in the SMAT GUI.

It appears this has been identified as a bug and the correction to exist in 6.1 or 6.2.

But then the discussion morphed to SMATdb.

So the question still remains (at least in my mind) wass the original bug fixed and in what release?

We experience some of that same strange SMAT behavior in our production system that is running 6.0.2 with the classic SMAT files.

We are seeing the random cycling in our new 6.1.2.0 (AIX7.1) test environment. It has happened to 7 smatdb files in the last 3 days.  Seeing other weird behavior that seems to be related to this too.  One of the smatdb files randomly cycled on Tuesday.  The new file had messages in it for Wednesday and no messages for today(Thursday) even though the thread statistics showed it should have 22 messages.  The file timestamp showed last activity from Wednesday.  I turned up the engine logging and bounced the process and voila, all of today’s messages wrote to the smatdb with the correct time saved timestamp from when the messages actually passed through the thread.

So is there still a bug in CL6.1.2..I thought is we were using smatdb it was fixed???