@krileydh
Forum Replies Created
-
AuthorReplies
-
This begs the question… Is it preferable to use the “Encoding” setting on TCP/IP or use the TCP/IP PDL and the MLLP.pdl?
Why not save them as HTML, and use that format. It is immediately viewable in the NetMonitor, and most things you would want to do in MS Word should be possible in HLTML.
July 11, 2010 at 8:10 am in reply to: Need utility for listing which threads use a given proc #72028Give this a shot.
Code:
global envif {$argc != 1} {
puts “”
puts “”procbythread
puts “”
exit
}
set procname [lindex $argv 0]set fh [open $env(HCISITEDIR)/NetConfig “RDONLY”]
while 1 {
if {[eof $fh]} {break}
set len [gets $fh line]if {[string first “protocol” $line] == 0} {
set threadname [lindex [split $line ” “] 1]
}
if {[string first [string toupper $procname] [string toupper $line]] >= 0} {
puts “$threadname: $line”
}}
Save is as something like procbythread.tcl, set you site, and run it like:
hcitcl procbythread.tcl tps_log_hl7
[EDIT: it looks like Michael beat me to it… but since I typed all this, I am leaving it…]
If you are using AIX, we have had good experiences with setting the tcp_keepidle parameter.
Yes. You can also enable it from the command line if you have backend access. After doing the setroot, setsite:
hcicmd -p PROCESS -c ‘CONN eo_alias enable_pdl’
Where
PROCESS is the process the connection/thread is in
CONN is the thread/connection name
This assumes you named your EO alias “enable_pdl”, if you named yours something different you will need to adjust the last argument accordingly.
Note:
This will not “stick”. Once you restart the thread it will go back to whatever is set in the thread properties. Whereas, if you put the setting in the thread properties, it will be “on” for you whenever you restart the thread until you remove it via the NetConfig.
(PS to unset the eoalias from the command line use this:
hcicmd -p PROCESS -c ‘CONN eo_alias {}’
or just bounce the thread if it is not setup in the thread properties.
)
On the “Thread” tab of the connection properties lower left below “File:” is “Msg EO Config:”. Put it there. You don’t really need this at the process level since you just care about the protocol information. So this is thread/connection level. One more note, make sure you remember to clear setting out once you have the connection working. As you will see, it generates a lot of stuff in the log file. You wouldn’t want all that stuff in there unless you were specifically diagnosing a problem.
I have found it useful in a case like this to create an Engine Output Alias, I call mine ‘pdl_info0’. It contains this:
ENABLE pdl pdl BDUG 0
This is then setup on the thread properties for the connection you are working with, and will enable you to see every character coming in and its Hex value which enables you to see the unprintable characters like the MLLP encoding characters. Initially, the extra stuff in the engine log might look confusing. Just take you time going through it.
You should also look out for errors (or warnings) with the verbiage “no more phrases to try”. This is a sign that the MLLP encoding you are receiving is not correct. “No more phrases to try” is the PDL driver indicating that it did not find the or the or .
Thanks! I had expected our customer rep. to let me know as soon as he knew something since I have been asking him about it. We have a Cloverleaf upgrade in our list of accountable project for this year. So I am on the hook to get this tested and ready to go live by the end of the year.
So when is 5.8 going GA?
While I an not sure what methods of penetration that the testing software that was used performed, I will make a couple of general statements about this, as I understand things.
Since the typical interface in Cloverleaf is a persistent tcp/ip socket, it will always be vulnerable to ip/macs address spoofing type connection hijacking attacks. As far as I know there is no way to mitigate this inside the firewall (ie. inside the “protected LAN”). Once a connection has been hijacked, I would not expect the Cloverleaf connection to be able to recover on its own. Cloverleaf relies on a proper closing of the tcpip connection to reset the state to “opening”. If for any reason this closing handshake does not happen, Cloverleaf will usually remain in an “up” state even though the actual connection may not still be viable. Without a transition to “opening” Cloverleaf will not try to reestablish the connection, since it would still “think” it is up.
The only remedy I know of for this is to monitor “Last Rd” and “Last Wt” times on the threads/connections and if a gap become apparent, restart the thread/connection. I do this from Cron on our AIX system. There maybe other/better ways, but this works well for us for a few connections we have that “die” in abnormal ways on a regular basis.
I hope this helps.
Here is my recommendation:
set obx [lrange [lregexp $segmentList {^OBX}] 0 end]
Mark,
I see two errors in the code you posted…
1) your ‘set obxlist “”‘ statement needs to be moved out of your foreach loop.
2) You string trim is missing its set, it should be ‘set field [string trim $field]’
Perhaps you should repost your code. I am not sure I am following along. Are you doing the “join”? I don’t think you want any of this in a list at all. I think you want to join it all in to one long string. At that point your “regexp” will work. Try echoing out your variable you are trying to “regexp” against. If there are still curly braces in there, they it hasn’t been joined correctly.
You probably want to use “append” not “lappend”. Try that.
-
AuthorReplies
