Ability to resend messages to only a specified to route.

[Max Drown (Infor)]

Subject: Routing

Sorting Lists

Ability to resend messages to only a specified to route or routes instead of to all routes.

Date:

05/15/2008

Operating System:

N/A

Version of OS:

N/A

Cloverleaf Version:

N/A

Revision:

N/A

Tool:

NetMonitor and hcicmd

Enhancement Long Description:

Ability to resend messages to only a specified to route or routes instead of to all routes. Currently the process requires quite a bit of work including altering the NetConfig in a production environment. A tool that provides a way to resend messages to an inbound thread only through a specified route or route would be a huge productivity enhancer.

-- Max Drown (Infor)

Topic

[Jerry Tilsley]

I Agree!  Very cumbersome to do this in a production environment!

[Bob Richardson]

Folks,

I don’t think the resend of messages in Production is that much of a problem.  If you use the route tester tool in Production and save your messages to file, all logic up to and including the TPS Outbound stack is exercised:  you may get multiple output files depending on how many outbound threads are configured but you can remove the ones that you don’t care about and then resend the ONE file outbound from either the command line or the NetMonitor gui.

We have proven to ourselves that the logic does get executed through the TPS Outbound with the file(s) representing State 11 messages.

Hope this helps you out in the interim.

[Tom Rioux]

Bob,

I’ve tested this in the past and I’ve tested it over and over again just now, but I don’t see where, using the routetester GUI, the TPS Outbound stack ever gets exercised.   How did you and your team come to your conclusion?  This has me very curious.  In all the places I’ve worked, I’ve never seen the routester act in such a manner as you described.  Maybe I’m missing something.  Can you elaborate further?

Thanks…

Tom Rioux

[Bob Richardson]

Greetings:  [we are on AIX5.3 TL8 CIS5.6 R2]

  Thomas, you challenged me to prove my assertion and by conducting a few experiments in a test site, you are indeed right and I am wrong here.

See below for my experiment details.  However, all is not lost !! In my experiment, I traced the message in the route tester tool and found that it will create an output file for each recipient thread (outbound) that is a PRE-TPS Outbound image for the receiving thread.   By resending these files either via command hcicmd or the GUI as Outbound PRE-TPS any logic in the outbound thread’s “OUTBOUND TPS” Upoc will get exercised and also any “PreWrite” logic (we use this when we want to massage State 11s or filter them once the thread is connected by the remote end for whatever reason).

I will need to let my group know these results – back when we were on CIS5.3 R3 we had figured that my previous assertion had been correct based on our collective experiences.  So I cannot prove or disprove how the route tester tool works on that version in this case.  In about 3% of our configurations, we tend not to place procedures in the TPS Outbound stack other than numfile style procs.  But then these are used in fileset/local threads in our shop.

Perhaps other Cloverleafers can chime in here with their experiences?

— BobR

Experiment details: (let me know if you want my procs – can post here or email them to you):

1. set up an input fileset thread, output TCP/IP auto reply/resend thread with a dummy port that nothing should connect

2. configured a route detail with pre, xlate, post for the input thread to the output thread

3. plugged in a tps_debug_display Tcl proc at all upocs on both threads

4. plugged in a tps_add_data TCL proc in the Outbound thread “TPS Outbound” Upoc – a simple “msgappend” statement to the message

5. ran my input message in the route tester and observed that NO logic was exercised in the recipient (outbound) thread (the msgappend)

6. Did this several times to rule out any fat finger errors on my part

7. Checked the displays of upoc context, etc from the route tester (output from tps_debug_display)

8. Resent output file from route tester as PRE-TPS Outbound from the GUI NetMonitor

9. Obseved that the TPS Outbound Upoc msgappend now executed.

10. Checked the process log that the PreWrite was also executed.

[Tom Rioux]

I would be nice if the routetester was more comprehensive.   I would like to be able to do a route test and have the ability to run it through all the way past the outbound TPS.  As it stands now, to truly test the entire route, I must do a route test, save it to a file.  Then take that file and perform a tps test on my outbound tps stack.   It would be nice to have the ability to do all of this with one function.   Maybe a check box on the routetester that determines whether or not to use the outbound tps stack.

Thanks Bob for all your input….

Tom Rioux

[Max Drown (Infor)]

Note that my enhancement request is not really for testing, it’s for simplifying the resending of messages in the production environment.

-- Max Drown (Infor)

[Tom Rioux]

Yeah….but the testing tool thing would be nice too!!   😀

[Bob Richardson]

I agree that the testing tool enhancement to run all the way through to the State 11 of the outbound thread(s) would be very handy.  I can see this as a solution in Production for resending messages if you need to resend a large volume of messages and don’t want to interfere with current message traffic.  That is, with a file you could resend the old stuff at a lower engine priority and keep the current stuff at the higher priority level.

Just some thoughts to support the route tester tool enhancement goal as well here.

Enjoy.

[Author]

Replies