Need Help!

[Ivan Ng]

I am looking for the tcl script to forward the all outbound msgs of a thread to itself as inbound msgs.

As a result, I would be able to chain transformations.  ThreadA->ThreadB->ThreadC.

Thank you.

Topic

[Rentian Huang]

This is a good concept. You can than place xlate on ThreadB and reduce the burden of ThreadA.

This is the tps.

Sam  8)

Code:

######################################################################
# Name: over_to_ibTPS
# Purpose:
# UPoC type: tps
# Args: tps keyedlist containing the following keys:
#       MODE    run mode (”start”, “run” or “time”)
#       MSGID   message handle
#       ARGS    user-supplied arguments:
#              
#
# Returns: tps disposition list:
#          
#

proc over_to_ibTPS { 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
           lappend dispList “CONTINUE $mh”
           set msg [msgget $mh]
           set new_mh [msgcreate -recover $msg]
           lappend dispList “OVER $new_mh”
       }

       time {
           # Timer-based processing
   # N.B.: there may or may not be a MSGID key in args
       }

       default {
   error “Unknown mode ‘$mode’ in proto_to_ibTPS”
       }
   }

   return $dispList
}

[David Caragay]

There was a good thread discussion about how and why (or why not) an interface should be designed this way.  Sample code was included. Check out http://clovertech.infor.com/viewtopic.php?t=359

[Charlie Bursell]

Perhaps the concept is valid.   IMHO, there are much better and more maintainable methods to accomplish the same thing.  For any of you that have had the pleasure of my company  🙂  you know I always preach about maintainabilty.  Again IMHO, this method adds a lot to the overhead and maintenance because it is not obvious to those that follow you what you are trying to accomplish.  The same reason I preach against Generate Routes.  If you  do use this method add some heavy commenting.

Also, *NEVER* use msgcreate unless you are building an ACK or inside a UPoC read driver.  It will cause you many problems since the message created has little or no meta data.  Use the msgcopy and msgset instead to maintain meta data.

I just spent several hours running down a problem where the recover_33 procs seemed to not work properly.  The customer swore it was Cloverleaf or the recover_33 procs screwing up.  We finally discovered that when they received a certain ADT type, they had to create another message.  They were using msgcreate to build the second message.  Since that message did not have the Await Replies flag set, it would not wait for a reply and the next message was sent immediately.

A word to the wise should be sufficient.

[Rentian Huang]

Charlie,

My tcl was actually provided by Quovadx, and we have been using it for a long while without any problem. But as from a performance prospective, would it be more efficient to change the code to:

Code:

run {
      # ‘run’ mode always has a MSGID; fetch and process it
           keylget args MSGID mh
           lappend dispList “OVER $mh”
       }

Will this change have an impact?

Thanks,

Sam 🙂

[Charlie Bursell]

Quite frankly, I wouldn’t use the OVER in this context at all.  As I said in my previous post, I think there are better, more maintainable methods of doing this.   But, this is my opinion, others may differ.

However, this is better than the previous code.

FWIW, we at Quovadx are learning all the time just like you guys.  Just because it was done by one of us does not mean we haven’t learned new ways and methods.  I look at some stuff I wrote a while back and it makes me sick  🙂

[Rentian Huang]

Thanks Charlie, I agree 100 percent!

[Anonymous]

Charlie,

If we use your recommended method and create interfaces A, B, C & D:

where A messages are routed to B (A->B),

[Charlie Bursell]

Boy, you have me confused here  ❓

II guess the first question I would ask is why you are doing this.  The only time we do this is when we feel the xlate thread is starving the IB thread and want to move the xlate thread to a different process.

I don’t understand the arrow between B and C.  You can certainly put a dummy route there for documentation purposes.  Is this what you mean?  If so and you have OB Msgs Only checked on C, the only thing B will see are the replies from C.

The interface between B and C should be exactly like an interface to an external vendor.  The only difference is I normally return just a simple  ACK from C and I set the timeout on B to a long time, usually 300 seconds.

The dummy route will not affect anything.  Of course, throughput will not be the same over the internal TCP/IP connection but that is why we use this paradigm only when absolutely necessary.

I hope this helps

[Elizabeth Wilson]

Charlie,

 We have a new programmer that had seen the tpsOverMsg used before at other hospitals to replace the TCP/IP in and out threads.  We installed it in the test system and it is routing the messages to the appropriate threads.  I informed him of our problem with the loss of the metadata with the msgcreate command.  He changed the msgcreate command to msgcopy.  Now when the data is sent from thread A it is routed to thread B, thread B contains the proc in the Outbound tps that does the OVER.  We expected it to go to the inbound of thread B and then route to thread C like before when the proc contained the msgcreate command.  But now it appears that the message is routed back to thread A which routes it back to thread B.  This loop continued creating messages and putting them into the recovery database.  This almost caused production to go down.  Do you have any insite?

Thanks,

Elizabeth Wilson

[Anonymous]

Yes Charlie,

That answered my question, and yes, the only reason to add the route between C and D would be for the looks. We try to avoid this type of overhead, of course   🙂

[Charlie Bursell]

Elizabeth:

Yours is a Greg Day question. He is a proponent of this method.  I am strongly against it for reasons previously stated.

However, like Republicans and Democrats, we are allowed to have philosophical differences.  8)

[Rentian Huang]

Elizabeth,

Try get rid of the msgcopy, just do a simple OVER:

Code:

run {
      # ‘run’ mode always has a MSGID; fetch and process it
           keylget args MSGID mh
           lappend dispList “OVER $mh”
       }

Sam

[Ryan Boone]

Elizabeth,

In order to make this kind of routing work without looping, set the source connection in the message metadata to the new (or “middle”) thread before setting the “over” disposition, like this:

#######################

global HciConnName

if { ! [info exists HciConnName] } { set HciConnName “UNKNOWN_THREAD” }

set thread $HciConnName

msgmetaset $mh SOURCECONN $thread

lappend dispList “OVER $mh”

#######################

This makes thread “B” the new source thread instead of thread A and prevents the message from looping.

There are other issues to be aware of with this kind of routing — the same routes must appear in thread A as in thread B, and the trxid in both threads needs to be able to handle them appropriately. Unless I’ve missed something, which is entirely possible.

[Elizabeth Wilson]

Charlie – thank you for your answer.

Rentian – eliminating msgcopy and using just OVER had the same looping effects.

Ryan;

If I understand you correctly, our configuration would not be applicable for using OVER.

Our current TCP/IP config is working fine:

Thread A sends to 5 out_B threads (out1, out2, out3, etc.);

each out_B sends raw data to each in_B (in1, in2, in3, etc.);

each in_B thread xlates to multiple C threads.

It is a ‘performance improvement’ behind the idea of changing it, although we do not have performance problems so far.

The new concept is to make Thread A send raw data to a file on Threads B: in1, in2, in3, in4, in5.

Each of the threads B (with OVER in Outbound) in turn, would have different routes defined, each Thread B has several routes to multiple C Threads.

That’s not ‘the same routes’ is it?

[Ryan Boone]

Elizabeth,

It sounds like you have a different configuration than what I was thinking. My understanding was this:

A->B->C

Or

    C1

     |

A->B->C2

     |

    C3

But the only tcp/ip protocols would be inbound A and C outbound.

1. Message goes from A xlate to B outbound. Source connection is A.

2. B outbound “OVERs” mesage to B inbound, but still has Source connection of A. To remedy looping, change SOURCECONN to B before the OVER.

3. Now B will xlate/route to appropriate Cs.

4. However, for B routes to work, A must have the same routes. (This may be due to not finding the correct way of routing from B).

This configuration can be used for more complicated routing, where you can create a “traffic circle,” but there needs to be a good reason for doing so, obviously.

[Author]

Replies