- This topic has 16 replies, 6 voices, and was last updated 19 years, 4 months ago by
.
-
Topic
-
-
Replies
-
-
-
-
-
You can do this by simply creating a Tcl proc using the tcl editor and just change the CONTINUE statement to OVER. Then place this proc in thread2’s Outbound data TPS. Then you’ll have to create a route from thread2 to thread3 which i assume you already have. The OVER disposition will take the messages from the outbound data queue and place them in the opposite queue which in this case is the inbound data queue.
But why would you be using 3 threads in the first place?
-
-
-
-
-
We have some interfaces with the “OVER” tclproc, but now we are trying to use other way to do the same. We found that troubleshooting, doing “resends” or recovering from a crash is a little bit more complicated. To acomplish the same, now we use something like this: thread1_in –route–> thread2_out –tcp–> thread3_in –route–> thread4_out
Yes, we have one more thread, but it is easier to maintain.
We didn’t noticed a significant drop on performance by using the TCP connection.
Best regards,
Carlos
-
I would tend to agree with Carlos. Because of the maintenance and support issues of the suggested configuration we have avoided using this setup. Instead, we will create a separate (fourth) thread to support the scenario indicated. We have many interfaces that use this configuration (within a site and between sites, on different servers) and performance has not been a problem. As a side note, I would think it would be more difficult for our operators to support the suggested configuration. Netmonitor GUIs may not be as intuitive as they are accustomed to. -
I have had two different circumstances for using the over thread method. One was a normalization scheme. The other was to do many to one processing where the over thread held onto a set of messages until I recieved the last message of the set. In my testing it is faster to redirect messages than it is to TCP/IP them. I think this is because you don’t need to wait for replies when you just redirect.
-
All, Thank you for great information 😀 😀
Why I need is ;
Invision sends EBCIDIC data and I need to reuse it. But, I have no idea to edit EBCIDC data in the system. So I try to create dummy thread to create the outbound SMAT file which can be updated and resent.
If you have any idea how to edit ebcdic smat file, it will be great.
Jae
-
Jae, One thing to note when you are using ThreadA -> ThreadB -> ThreadC, there is no way to save data in the SMAT files on TheadB. If your goal is to save an ASCII version of the message you don’t need this thread arrangement.
For your situation, do the EBCDIC to ASCII conversion on the inbound side of ThreadA. Raw route the ASCII version of the message to ThreadB configured as File:/dev/null. Translate the ASCII version of the message to ThreadC and others if needed. When you want to edit and resend, use the messages from the SMAT file on ThreadB. When you resend messages, be sure to put them “Post TPS” on the inbound side of ThreadA — otherwise they will get double-converted from EBCDIC to ASCII (not pretty).
- Mark Thompson
HealthPartners -
Still problem! Thread1–> Thread2 –> Thread3
Thread1 : Inbound and route to Thread2
Thread2 : Input and outfile /dev/null
OUtbound TPS over_thread
Route to Thread 3
Here is my tcl proc for OVER disposition.
proc over_thread { args } {
global HciConnName HciSiteDir
set mode [keylget args MODE]
set context [keylget args CONTEXT]
if { ! [info exists HciConnName] } { set HciConnName “UNKNOWN_TD” }
switch -exact — $mode {
start {
return “” ;# Nothing specific
}
run {
set mh [keylget args MSGID] ;# Message header
return “{OVER $mh}”
}
}
}
-
Try this code. You can add any bells and whistles later if you wish. This proc should be placed on your thread2 OB TPS. You will also have to set up a route on thread2 to send data to thread3. I put a few msgdumps in the code so you can see the metadata change in the log. You can remove them before using this in production. As I said before, this seems to be adding unneeded complexity to the interface. Unless you have real performance issues, you may want to reconsider this configuration. Adding another thread to simpify the interface would be my recommendation. I usually save these unusual configurations for interfaces that really need it.
proc over_msg { args } {
keylget args MODE mode ;# Fetch mode
set dispList {} ;# Nothing to return
switch -exact — $mode {
start {
# Perform special init functions
# N.B.: there may or may not be a MSGID key in args
}
run {
# ‘run’ mode always has a MSGID; fetch and process it
keylget args MSGID mh
msgdump $mh
msgmetaset $mh SOURCECONN thread2
msgdump $mh
lappend dispList “OVER $mh”
}
time {
# Timer-based processing
# N.B.: there may or may not be a MSGID key in args
}
shutdown {
# Doing some clean-up work
}
}
return $dispList
}
-
I’m not sure I understand what you’re trying to do. Here’s two ideas. There’s a set of standard map tables that you can use to transliterate ebcdic to ascii and back again. So, when the message enters the engine you change it to ascii, work with it, then convert it back to send back. The procedure is hcitpstableconvert.
The secret to usin this proc is knowing what map tables you can use. You’ll find the tables in $HCIROOT/tcl/lib/cloverleaf/hciStart.tlib. The list names are the table names. The first one is hcie2a, and so on. The standard tables are hcie2a and hcia2e.
There is also a TCL command to transliterate using the map tables (that’s what hcitpstableconvert uses). The command is msgmapdata. Using this command you can write your own tcl to transliterate messages at will.
BTW, you could create your own map tables as well if you don’t like ours for some reason.
It’s not possible to change the data that goes into a SMAT file (that’s the whole idea behind SMAT, guaranteed not to have been changed). But you could resend from a smat file to a thread that transliterates. Or you could put the data into a file and write a TCL to transliterate it outside the engine.
Cheers,
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
