[Tiffany Bohall]

This probably will not surprise you, but this is exactly what the issue is.  Thank you again for the article and stopping the spinning so we could focus on another solution to try and resolve this once and for all!  I appreciate your time and feedback!

[Tiffany Bohall]

This has been an interesting ride and I am so glad it is coming to an end hopefully in the next few weeks!  Unfortunately, since Cloverleaf AIX is a 32-bit application with smaller memory addressing than Windows and Linux this is the cause of our issues here.  We knew there was a 32-bit  limitation before this issue came up but it was only seen via our inbound SMAT files that consumed so much data we often lose the file in archive and it results in 0kb files.  We did not associate this problem to large inbound messages and had a very difficult time proving so.  Since we will not be upgrading our OS in at least the next year, we have had to take a solution outside of the engine.  We are using a Windows server and wrote a .net solution that will take the messages via SFTP, parse them into a single .csv for SFTP to our downstream app.  It is not idea and there is hesitation going outside of the engine for this, but it is what we have been dealt.

[Tiffany Bohall]

Thank for this information, I will review with our server admins.

[Tiffany Bohall]

Thank you for responding.  We have 38 threads on the site and a majority of them are fileset-local, only processing data once/week/month, etc.  The process is dedicated to these two threads.  The problem is that these backloaded transactions are mixed with non-backloaded transactions and the vendor thus far has been unwilling to split them.

Per my open issue with Infor, Gotham has advised us to write the messages to a file and then split them out based on message size.  The receiving side will have more files to pick up but as long as it stops crashing us, it is an acceptable compromise.  We are currently in testing mode.

[Tiffany Bohall]

We are on AIX v 7.1.0.0.

[Tiffany Bohall]

Hi Mike,

Hope all is well with you! Where is your sense of humor when I need it? 😆  

I felt compelled to respond because we just upgraded our test environment to v5.8.5 and are having significant issues with SMAT cycling.  See CloverTech thread titled “CL 5.8 rev 5 patch issue.”  I finally had to open a CASE with Lawson because I was not getting very far with recommendations here.

Take Care,

Tiffany Bohall

[Tiffany Bohall]

I guess the true question from us would be:  If we change nothing related to SMAT files in the 5.8 application post upgrade.  Will our cron job script work exactly the same as it did for rel 5.7?  It’s looking like the answer is a no but now to figure out why and correct it.

[Tiffany Bohall]

Jim:

I ran this from the command line and it worked fine.  Verified the messages are retrievable in SMAT archive from Friday and as of today messages are also filing to current for this file.  The true test will come at 11pm tonight, when the .old is to cycle to archive.  

Please tell me we won’t have to do this for our 400+ connections??   😥

$ setsite fr_cerner

$ hcicmd -p cer_res

hcicmd> crt_res_in save_cycle in

Response:

inbound message saving cycled

Friday we did turn on automatic SMAT cycling for our master site only and set the threshold very low to observe.  Messages starting collecting in current but we had no luck on cycling of the files.  We manually cycled them this morning and the files just disappeared they did not go to .old.  

As of this morning I turned off autocycle on our master site until we can get this resolved.

Ian:

We do NOT shut down our threads to cycle save them.

[Tiffany Bohall]

Our SMAT files are not cycling.  We just upgraded our TEST environment from 5.7 to 5.8.5 on Tuesday, April 24th and only have a handful of files per each of our 11 sites.  These few files are from the 24th only and nothing has cycled since then.  I have verified that at least a few threads on each site have recent reads so I know messages are crossing fine, we just can’t actually retrieve them.  We have verified that automatic SMAT cycling is turned OFF.  

We have a script that cycles our files once a day in test.  It first takes the .old smat file and moves them to the Archive directory.  Then it issues the following commands to cycle the current smat files to .old.  Been working for years in 5.7.

hcicmd -p $proc -c “$thrd save_cycle in” > /dev/null 2>&1

hcicmd -p $proc -c “$thrd save_cycle out” > /dev/null 2>&1

Any guidance would be greatly appreciated.

[Tiffany Bohall]

The problem you are having with & is the same issue we have with @.  Our Invision encoding characters, post ebcdic to ascii conversion are ” ^~@ “.

[Tiffany Bohall]

Good question!  

All xlates are using variant 2.3 and we are on version 5.7 of CL.

Number 90561, type = ST, length = 256, Name = Case User Data, marked as optional and repeats.

[Tiffany Bohall]

Please see attached word doc.

[Tiffany Bohall]

Thank you for the feedback thus far.  We can receive the @ fine but once we send it through an xlate that has an iteration/if statement looping through a segment to find the variable, if that variable happens to have an @ in the free text user field, the message goes to the EDB.  The seniors I work with have a theory that the message goes to the EDB because we are trying to iterate on a field that could potentially have a user entered @ symbol and Cloverleaf chokes on it, thinking it is an encoding character when in these cases, it is not.

Given our long history of bad luck with @ symbols, I have code in the xlate that searches the 2 custom user fields (email is sent in 2 diff fields as each field is only 20 chars long) and then concatenates them together on the outbound message, so it passes as 1 field.  I tested it in the testing tool and my the code retrieves and concats just find but the testing tool removes the @ symbol, which we do not understand either.

[Author]

Replies