I had a similar situation with my interface with Moen Faucet. The had a 'lock' record scheme set up so that they would write a record indicating that the were getting ready to upload the data from the 'orders to ship' file. If my ftp program saw that record, it was not supposed to append to the orders file. If I was going to append to the orders file, I would write the lock record so that they would not start uploading until I was finished. This worked about 98% of the time, but 2% of the time records were getting lost, or partial orders were being uploaded on their side.
Before I ever wrote the first line of code for the order interface, I told them that their locking scheme was faulty, but I was told to do it anyway. Eventually this because a big enough problem that they finally listened to me. My solution was to create a "master and slave" locking process with a 15 second delay. (They liked this since I did all the programming, and they were the Master".) What I did was when I would write my locking record, I would wait 15 seconds and check the lock record to see if I had written it, or if they had overwritten my lock record with theirs. If they had overwritten my record, I knew that there was a collision similar to yours, and I would wait 5 minutes and try again. If not, I would go ahead and append. This solved their problem that they had experienced for over 7 years with other subsidiary companies as well as with mine. My reward? They closed our division. You just gotta love the logic of big corporations. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dana Baron Sent: Monday, December 20, 2004 06:39 To: U2-Users (E-mail) Subject: [U2] Writeseq quirkiness - the answer Greetings, And the prize goes to Kevin King! He came up with the "write" answer to solve my writeseq problem. Of course, he had an advantage since he helped write the application in the first place. Still, I was stumped and his answer worked. Thank you (once again!), Kevin. For those who care: To understand the solution, you need a little more background. The code segment I sent is part of an application that manages the interface between my Unidata application and a third-party device, which in turn manages the interface with a bunch of other devices. When I want to send data out of my application, I create a file with a .out extension and write the appropriately formatted data to the file. A program written by Kevin King sits out there looking for files with .out extensions. When it finds one, it reads the file and sends the data to the third-party device. It then deletes the file. And this is wherein lay the problem, and the solution. What was happening was, my program would open the file (OPENSEQ) and Kevin's program would come along and try to read it, then delete it, then I'd try to write to it (WRITESEQ), but by then it was gone. I changed the code a little bit to open the file with a .tmp extension, write to that, then rename it to .out. Works great! There are still a few mysteries: why does the original code work for just about every situation, then suddenly fail for one new situation that is seemly the same as all the others? But heck, it works so I'll go with it. Thanks to everyone who responded with a solution. And the u2 list comes through again! Dana Baron System Manager Smugglers' Notch Resort ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
