IPA locks text file if process errors out

I found a workaround for this.

If you configure a Data Iterator to read a file directly using input method "File", and the iterator is interrupted by an error before it reads all the records in the file, the input file may be locked; held open by the java runtime. In testing, this happened when an error was trapped by an error hander and control went to a node in the process that is outside the iterator loop. I did not test what happens if you stop the process when an error occurs.

When the file is locked, subsequent runs of the process won't be able to access it, e.g., FTP a new version of the file into place or delete it; nor can it be deleted manually via Windows Explorer using a file share. This happens when running on the IPA server or on the PC in IPD.

A workaround is to configure the iterator input method to "Data", read the file using a File Access node, then feed that node's output data into the iterator. Presumably this works because the File Access node reads the entire file without interruption.

Another option would be to set an error flag when the error occurs, handle the error, then linking the last node of the error handler to the iterator's end node. Then, first thing in the iterator loop, test the error code and branch directly to the end node if it was set. This would allow the iterator to complete, and presumably release its input file. That might result in many needless iterations if the error occurred early in a large file.

With IPA (and particularly when IPA is on separate server from LSF), using the fileaccess node to read the file first into memory and then using the DataIterator against the data instead of the file will become a necessity. One pattern that I've noticed with the move to v10 IPA is that customers who used to have LSF / PF on the same server now have IPA on a separate server and when they use the FileAccess nodes to write from within an iterator loop that means a network round-trip for every read or write...