Outbound thread not sending message to receiving system

[Ariba Jones]

I have an interface that I just put into production that is not working properly.  I have compared the setup of the production interface to the test interface and everything looks identical.  This interface worked in test, but is not working in production.

I have an inbound thread that sends a file to two separate outbound threads.  

Inbound thread is type fileset-Local. One of the outbound threads is type pdl-tcpip.  The second outbound thread is type fileset-Local.  

There is a kornshell script that runs to retrieve the inbound file from a server. That same kornshell script takes the file and places it in a different directory on the same server (which is where the outbound thread that is type fileset-Local comes into play).  

The file retrieved by the kornshell script is also sent to the receiving system via the other outbound thread that is type pdl-tcpip.  

Part of this interface is working.  The file gets picked up from the sending system (via that kornshell script).  The file gets placed in the new directory on the same server.  The part that is not working is the file being sent via tcp-ip connection to the receiving system.  Cloverleaf doesn’t appear to show that a file was sent out to the receiving system.  

If I take the backup copy of the file and place it in the directory where Cloverleaf is looking for the file (as setup in the inbound thread’s Inbound Directory on the Protocol Properties tab), the interface picks up the file and sends it to the receiving system (via tcp-ip) with no problem.  I did not have this issue when testing this interface.

Can anybody offer any input as to what may be the issue here?

Here is what I see when I turned up logging on the outbound (tcp-ip) thread.  I am not sure what this means.

[pti :sche:INFO/1:la_timeacc_out_4] Thread has 1 ready events.

[pti :sche:INFO/1:la_timeacc_out_4] Thread has 0 ready events left.

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/1:la_timeacc_out_4] Thread has 1 ready events.

[pti :sche:INFO/1:la_timeacc_out_4] Thread has 0 ready events left.

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/1:la_timeacc_out_4] Thread has 1 ready events.

[pti :sche:INFO/1:la_timeacc_out_4] Thread has 0 ready events left.

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/1:la_timeacc_out_4] Thread has 1 ready events.

[pti :sche:INFO/1:la_timeacc_out_4] Thread has 0 ready events left.

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/1:la_timeacc_out_4] Thread has 1 ready events.

[pti :sche:INFO/1:la_timeacc_out_4] Thread has 0 ready events left.

data == AA

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/1:la_timeacc_out_4] Thread has 1 ready events.

[pti :sche:INFO/1:la_timeacc_out_4] Thread has 0 ready events left.

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

[pti :sche:INFO/1:la_timeacc_out_4] Thread has 1 ready events.

[pti :sche:INFO/1:la_timeacc_out_4] Thread has 0 ready events left.

[pti :sche:INFO/2:la_timeacc_out_4] Performing apply callback for thread 5

Thanks for any input in advance.

Ariba Jones

Topic

[Jim Kosloskey]

Ariba,

My first guess is the first part of this process is not placing the file in the directory where the Fileset-Local thread is looking. I say that because when you manually place the file there it functions.

It is also possible I guess, that the file has permissions which Cloverleaf(R) does not have privilege when placed by the script. When you place a file there, it will have proper permissions (if you logon as hci or another appropriate logon).

Have you tried to trap when the script is finished to assure the file is in the correct directory?

If one file is being placed in a directory where a foreign system will pick it up AND Cloverleaf(R) is expected to retrieve it then it is possible the foreign system gets to the file first and deltes it. Then when CLoverleaf(R) looks the file is not there.

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

[Ariba Jones]

Jim,

I have not tried to trap when the script is finished.  I am not sure how I would do that other than to monitor the directory where I expect the file to be to see if I ever see it there while the interface is being run.   Do you have any recommendations on what I should do other than that?

I find it odd that this is happening.  I actually have a similar setup for another interface that is also giving me the same problem…the file is not being sent to the receiving system via tcp-ip.  That particular interface worked fine for several years now and it has recently started to do this. I have made no changes to it, so, I am puzzled.

Ariba

[Jim Kosloskey]

Ariba,

If you are using a Korn shell script to do the first step, one way would be to modify the script so that it pipes the output from an ls-al command of the directory where the file is to exist to a file in a nuetral directory so that you can see if the file got to the directory.

Do you have two systems (foreign and Cloverleaf(R)) trying to use the same file that is placed by the first step?

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

[Ariba Jones]

Jim,

Yes, I have two systems trying to use the same file that is placed by the first step.

This is how it goes.  

The kornshell script ftp’s to a directory on the sending system and picks up a file. The kornshell script then makes a copy of this file to a backup directory and also to a shared directory. It then ftp’s to a directory on our shared drive and places the file.  After this, the file is then removed from the shared directory on Cloverleaf and also removed from the directory on Cloverleaf where the outbound thread is looking for the file. The script then ftp’s back to the sending system and deletes the file from the directory it was picked up from.

So, I guess this does mean that two different systems (foreign and Cloverleaf) are using the same file from the first step.

Ariba

[Jim Kosloskey]

Ariba,

OK – is it possible that the first system to get the file deletes it and the second system has no file to retrieve?

If so and Cloverleaf(R) happens to get there second, that could explain why Cloverleaf(R) does not process the file.

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

[Ariba Jones]

Jim,

I guess that is possible.  I will have the file created again so that it can go through the interface.  I will watch the directory on Cloverleaf to see if the file ever gets in the directory that Cloverleaf is looking for it in.  

I’ll let you know how that goes.

Thanks for the input.

Ariba

[Ariba Jones]

Jim,

I was not able to test this on Friday.  The person who generates the file was out.

We did some testing today.  You were right, the file was not hitting the directory that Cloverleaf was looking for it in.  I edited the kornshell script to make sure the directory was spelled out with full path name (instead of a variable like I was using).  After doing this, the file went to the appropriate directory and stayed in that directory.  

The file was resent via the outbound thread two times (when I noticed I manually removed it before it did it again).  So, I thought that maybe I needed to put a delete statement in the kornshell script to delete the file from that directory once it had been picked up by the outbound thread.  I added a remove (rm) statement to remove the file at the very end of the kornshell script.  We tested again and this time the file made it to the directory, but was removed so quickly the outbound thread did not pick it up.  

I have compared the setup of my test threads (again) to the production threads and I don’t see a difference.  This worked in test.  My test script also has the remove (rm) statement in it that is actually in a earlier place in the script than my production remove statement (which is the very last statement in the kornshell script).

What I can’t figure out is either why does the outbound (tcp-ip) thread take so long to pick up the file from the directory or why the script is deleting the file so quickly that the outbound thread can’t pick it up?  Unless I am overlooking some type of interval or timing setting that I am not thinking about.

Any ideas what may be my issue now?  The file is being deleted too quickly by the kornshell script for the outbound thread to send it over to the receiving system.  If I take the remove statement out of the kornshell script, the file stays in the directory that Cloverleaf is looking for it in and gets resent multiple times.

Thanks.

Ariba

[Jim Kosloskey]

Ariba,

The Cloverleaf(R) thread that is picking up the file should delete it after it has read the complete file unless there is a proc in the tps delete UPoC which keeps that from happening.

Perhaps I do not fully understand what you are doing, but the script that puts the file in the directory Cloverleaf(R) is searching should not be deleting it.

Moreover, if you have two systems (Cloverleaf(R) and some other system) which are intending to pick up the file, it is not a good idea to have the file in one directory for both systems. But if you want to keep it this way then only one of the systems picking the file up should be responsible for deleting it. Since by default Cloverleaf(R) deletes files it picks up, I would think that should be the system to delete the file.

The issue you will always have however when trying to have a file in one directory picked up by multiple systems and then removed when everyone is done, is the timing and scheduling.

In my opinion it would be better to put the file in a separate directory for each system.

As a matter of fact, I would have Cloverleaf(R) pick up the file initially and then put it wherever it needs to go (TCP/IP, FTP, Fileset-Local, whatever) and let the receiving systems deal with the file and the processing responsibility as they need to.

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

[David Harrison]

Ariba,

This may not be your problem but I

[Author]

Replies