@shane-farney
Forum Replies Created
-
AuthorReplies
-
Yeah, I see what you mean, now. I tried to use it as is and it failed too. Worked with slashes or my other thought was use a “binary encode hex $string” and then “string map {“0d0a” “0d”} $string” and then a “binary decode hex” on the string map. Tried on the inbound tps and did the trick.
Anyone have any idea when version 21 will come out?
Can anyone upload tclmail? I haven’t been able to find it anywhere on the board since things were switched to the new format.
Thanks for your input. The splurge of messages are from batch processes, closing out encounters. Some systems need this data, though we’re starting to think maybe not real-time and could go to the back of the line.
Your idea about delaying them somehow is also on the table in our discussions. We’re considering changing priority of messages identified by the nightly batch process… to give the real-time messages more of a fast-lane. Do you guys play with priority on messages at all?
We just had the same thing happen today after installing 6.2 this past week. This was helpful so that we didn’t have to open a ticket to figure out what was wrong.
October 20, 2016 at 4:03 pm in reply to: Cloverleaf Process Unresponsive – read returned error 0 #84661John Mercogliano wrote:We had the same issue on 5.7, the Epic bridges analysis would run a report every day and get 1000’s that failed and had to resend.
October 20, 2016 at 1:36 pm in reply to: Cloverleaf Process Unresponsive – read returned error 0 #84659That’s good to know this is normal. I did dig up this from the 6.1.2 release notes which seems to imply that there was a bug with Cloverleaf handling this kind of a connection:
Issue
Memory leak with MLP PDL (12592)
Description
A memory leak with MLP PDL could happen with sites that have a large number of messages, for example, a query site that has multiple applications connecting/disconnecting to it.
Instead of connecting, sending the query, waiting for the reply, and then disconnecting, the application with the memory leak connects, sends the query, immediately disconnects, and waits for a reply on a separate interface.
When Cloverleaf does not initiate the close connection or send a reply first, it does not clean up the memory until the process is stopped.
This issue no longer happens.
October 18, 2016 at 5:46 pm in reply to: Cloverleaf Process Unresponsive – read returned error 0 #846556.1.1 on AIX
The connection is opening/closing for what I assume to be every message.
I would look even harder at the IDE when using this “fix” to really notice what else may be affected. For instance, you’ll notice that the status indicators next to the Lock Mgr and Monitor Daemon will be gone within the Network Monitor. Buttons on the SMAT file routine are also a bit harder to read and use.
…just be wary that some things could change outside of the “white” look and feel from Hook and Loop.
Thank you for your reply, Steve, I’m going to pose this to Infor to get a response. To me, the text “You can force the engine not to truncate any field content, even if the content is beyond field length definition, by selecting Force engine not to truncate any content on the Site Preferences dialog box
Instead of using “lappend”, maybe just create a string delimited by your separator carets?
Double check your translate, and make sure you aren’t copying just a single subfield. It definitely works (tried it myself).
-
AuthorReplies
