Multiple threads connection

[Jae Joo]

I am trying to connact 3 threads for single data stream.

Thread –> Thread 2 –> Thread 3.

The data is going from Thread 1 to Thread 2, but not to Thread 3.

Is anyone know why or how ot implement?

Thanks,

Jae joo

Topic

[David Caragay]

Jae,

Are you trying to send data from THREAD to THREAD 2 and THREAD 3?  If so, your diagram should look more like THREAD –> THREAD 2,  THREAD –> THREAD 3.   Your inbound thread should be routing to the two outbound threads.  Maybe you can provide more detail on this issue.

[Anonymous]

To do this you’d want to cause an outbound message to go from state 10 to state 1 using an OB data TPS.  The secret is to OVER the outbound message and then add routes to your outbound thread since you’ve now caused the message to be inbound.

[Jae Joo]

Thanks,

So do I need to change the state of thread 2 (middle one)? if so, how can I do?

Thanks,

Jae

[Viken Ohannessian]

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?

[Anonymous]

I actually tested this and there’s one other thing that you have to do in your TCL procedure to make this work.  First, change the disposition to OVER and then change the source connection to the middle thread.

[David Caragay]

Can someone explain why this interface would need to be set up in this manner?  I can’t think of an example where I would be need three threads set up as indicated.  It may work but is there a “cleaner” way of accomplishing the desired result?

[Jim Kosloskey]

Dave,

Yes it would be interesting to find out why this is considered necessary to begin with.

Jae – do you care to enlighten the rest of us as to why you need this architecture?

Thanks,

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Mark Thompson]

We use this type of arrangement for data normalization.

- Mark Thompson
HealthPartners

[Anonymous]

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

[David Caragay]

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.

[Anonymous]

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.

[Jae Joo]

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

[Mark Thompson]

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

[Jae Joo]

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}”

       }

   }

}

[David Caragay]

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

}

[Anonymous]

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,

[Author]

Replies