Passport Address Verification/Eligibility

[Robert Milfajt]

Is anyone out their running an Address Verification interface with Passport?  We connect to them via VPN, and send out Address Verification query (QBP) messages and receive via another thread, response (RSP) messages.  What we’re seeing are sporadic delays of up to 7 minutes between QBP and RSP message.  Closer inspection shows the QBP message goes out, does not get ACK back for the time of the delay, and after we get the ACK, it’s about 3 seconds to get RSP message.

So it looks as though the network (VPN) is causing our problems.

I am looking for:

1. Any experience people have had with this vendor and if they have experienced a similar problem.

2. Any experience with VPN and a similar problem.

3. Any advice on how to set up the TCP connection.

Running 5.8.5 in clustered AIX 6.1 environment.

Thanks in advance,

Robert Milfajt
Northwestern Medicine
Chicago, IL

Topic

[Robert Milfajt]

OK, now that I’ve stumped everyone.  We’ve been debugging this, traces, sniffers, etc., and it looks like the lower levels of the OSI model are pulled right out from underneath the application layer.

They don’t see us sending the message to them.  We keep sending as though the connection is up.

Anyone have a handy dandy TCL script to plug into Timeout Handling to check to see if we haven’t received an acknowledgement to do something.  Ideally, I’d like to reset the connection, but if that’s not possible, send a page.

Thanks,

Bob

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Henry Bauer]

Haven’t done anything to look for ACK’s but you could query the recovery database for any messages to that thread and check if there is a message in state 14, I believe that is a message awaiting an ack, if you have one then bounce the thread.

[Russ Ross]

Take a look at my posts at the following URLs that talk about how I use tps_check_resend_count.tcl

<a href="https://usspvlclovertch2.infor.com/viewtopic.php?t=4212&highlight=tpscheckresendcount&#8221; class=”bbcode_url”>https://usspvlclovertch2.infor.com/viewtopic.php?t=4212&highlight=tpscheckresendcount

<a href="https://usspvlclovertch2.infor.com/viewtopic.php?t=1862&highlight=tpscheckresendcount&#8221; class=”bbcode_url”>https://usspvlclovertch2.infor.com/viewtopic.php?t=1862&highlight=tpscheckresendcount

It has been a very handy way to quickly catch problems very quickly even if queue depth is only one message deep.

When you have repeated resends of the same message due to no ACK received there is no need to wait too long to be alerted because you are headed for problems.

My motivation for creating this method was similar to yours, we had outbound interfaces that thought they were connect/up when they really had their legs kicked out from under them but didn’t know it.

Queue depth alerts can also catch the problem but take to long to be triggered during slow message flow periods, with this alert there are no false alarms and can be configured to get tirggered in a much shorter amount of time.

Russ Ross
RussRoss318@gmail.com

[Robert Milfajt]

Russ,

Thanks for the idea.  I have a question regarding implementation in 5.8.5.

Currently running 5.8.5, and they’ve added standard resend OB message functionality.  So Reply Generation button says Timeout Hanlding, but inside it looks similar to the old one, with another option, called Resend OB message.

If I pick procs, and stack my proc to send email (copied from Russ’ example), on top of cl_resend_ob_msg (found in $HCIROOT/tclprocs/recover.tcl), will that get me what I’m looking for, an email if we don’t get an ACK to a message and resending the message itself?

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Russ Ross]

I certainly would like to think that cosmetic differences in the 5.8 GUI will not cause the procs underneath it to quit working.

I’m currently on Cloverleaf 5.6 and have installed Cloverleaf 6.0, but not far enough along to do a hcirootcopy, so time will tell.

Since the recover 33 procs have held up with each cloverelaf upgrade, I expect the same of our resend procs.

Russ Ross
RussRoss318@gmail.com

[Russ Ross]

Be sure to understand my method of checking the resend count is intended to complement the recover 33 procs, so it is designed with the assumption you have the interface built to use the recover 33 procs or whatever they are called these days.

Russ Ross
RussRoss318@gmail.com

[Robert Milfajt]

Charlie can back me on this, but there are new recover procs for 5.6, that use a new argument OBMSGID that is now provided standard in Cloverleaf and replaces the need for the Send_OK procs.  I would like to verify that the cl_resend_ob_msg (which uses this OBMSGID argument) is what I would need to simulate what the radio button Resend OB message does in the GUI.

Thanks,

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Russ Ross]

That is correct, I just keep calling them recover 33 procs but they have been modified to include OBMSGID.

I don’t recall having any of them go way though like the send okay proc.

Remember this is the old style of ACK handling before it was built into the engine as an option.

If you select the built in method of ACK handling I don’t know how to count resends so that is why we stayed in the past because we like this resend alert.

Russ Ross
RussRoss318@gmail.com

[Bob Richardson]

Greetings,

Folks, if you look at the old recover procs that are supplied with the 5.8 engine they are the equivalent of NOOPs (old style term for ‘do nothings’ in the land of IBM).

We have been using “Auto resend OB” and doing the interpretations/counts/emails whatever in an IB TPS Reply proc.

With the 5.8 engine the “auto” will echo in the process log when it is resending a message unlike its predecessor 5.7 version.

Easier configuration.

Hope this helps.  Good luck on your implementations.

[Robert Milfajt]

Bob,

I beg to differ.

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Bob Richardson]

Robert and company,

Thanks for the additional information.  As always it is good to be able to participate in this forum and in a disinterested manner do point/counter point discussions and sharing.

Have a great weekend!

[Author]

Replies