[Jim Gibson]

We are in the process of testing for our upgrade from ver 5.3 to 5.6.  We had seen this problem with PATHCOPY.  In 5.6 it has been fixed and you do not get the mystery M segments.  We are just hoping our apps that have been getting these for years won’t mind not getting them.

[Jim Gibson]

I ran a test over the past week.  I created a duplicate connection only this one writes to a file on the engine and then I use a CRON to move the entire file at once to the FTP server once a day.  

Results:  Each day the file that was being written to the FTP server a record at a time lost some data while the file written on the engine and then FTP’d all at once, never lost data.

The FTP server software on the FTP side is just what came with MS 2000 lite (must I say more?).  Moral of the story is to save our data on the engine and then FTP the entire file with a CRON if you want it all to get there.

Thanks for everyone’s help.

Jim

[Jim Gibson]

I am going to have a talk with the person in charge of this server to get all the information about it.  I will post what I find out.  

The file is still a virgin when I look at it  🙂

Jim

[Jim Gibson]

I think you are beginning to see the problem I am describing.  I do not think cloverleaf is loosing messages,  I think they are getting lost on the FTP server.  The message you see in the log is the only thing cloverleaf sees from the FTP server, that it got the message.  It doesn’t let cloverleaf know what it did with it like an ACK coming back from an application would.  I believe there can be a problem on the FTP end and cloverleaf will never know about it unless it gets to the point the FTP server does not accept the message.

[Jim Gibson]

I put this proc in and just as I expected my log showed all the messages were successful.  It matched what was saved in the SMAT file.  The file on the FTP server is the only one missing records.  My original question still stands.  How does the engine know if a record was successfully saved on the ftp machine?  There is no ACK.

[Jim Gibson]

Not yet.  I hope to work on it this week.  I will let you know what happens.  Thanks

[Jim Gibson]

I added the above proc and waited.  No emails came.  I compared the output file to the SMAT file and 9 out of 321 messages were missing.  Just for kicks I ran these 9 messages through the  route tester and they all showed they would have been sent.

I guess my question now is when using protocol fileset-FTP, since no ACK messages comes back from a recieving application, how does the engine know if the message was successfully written on the other end?

[Jim Gibson]

Thanks, I have added this proc and will see if I get any emails today.

[Jim Gibson]

We are running Cloverleaf version 5.3 on AIX 5.2.  There are no prewrite procs on this connection.

[Jim Gibson]

Thanks Greg.  I just finished putting in the tcl to do the formatting manually so I don’t need this now.  It would be nice to know if anyone has done this with vrl.  It would save a lot of work.

[Jim Gibson]

Finally figured out the problem was due to the application we were sending to.  It had a 64k limit and was rejecting the messages.  I split the messages up using DSC segments and had no more errors after that.

Thanks for everyone’s replies.

Jim

[Jim Gibson]

None of the fields in these messages are very large, they just like to send many OBX segments in the messages.  Some have over 300 OBX segments.

What “timeouts” are you referring to?

[Jim Gibson]

Thanks,

I tried this and it works.  Seems like extra code but if it works it works.

Jim

[Author]

Replies