Error state if unix function write() writes into a deleted file

This is working as designed and part of the POSIX specification and will not be changed. Many applications expect this behavior and use these opened and unlinked files as application working storage that they know will get cleaned up when the descriptor closes.

An unlink() or RMVLNK function will only remove the link from the directory so you cannot find the path, it may not actually delete the object. The storage of the object will be freed only if it is the last link AND there are no open descriptors to it. In other words, if there are other hard links to the object OR if there is an open descriptor to the file, the object continues to exist.

The POSIX specification for unlink() states:
"When the file's link count becomes 0 and no process has the file open, the space occupied by the file shall be freed and the file shall no longer be accessible. If one or more processes have the file open when the last link is removed, the link shall be removed before unlink() returns, but the removal of the file contents shall be postponed until all references to the file are closed."

This is exactly the behavior of the root, QOpenSys, and user-defined file systems.
The Knowledge Center documentation for unlink() states:
"The unlink() function removes a directory entry that refers to a file. This unlink() deletes the link named by path and decrements the link count for the file itself.

If the link count becomes zero and no job currently has the file open, the file itself is deleted. The space occupied by the file is freed for new use, and the current contents of the file are lost. If one or more jobs have the file open when the last link is removed, unlink() removes the link, but the file itself is not removed until the last job closes the file."

In order to prevent the unlink to be performed at all or prematurely there are ways to do that. If it is an errant unlink and it normally shouldn't be unlinked, then you can lock it down. If this was just a timing problem that the writes didn't complete as expected, then you need to make sure the different jobs communicate so that functions happen in the correct order.

1. Create some synchronization object. Get the lock, open the file, write all the data, close the file, release the lock. Then in the ftp job, get the lock (will block until released in the other job), then perform the copy and unlink.
2. The CHKOUT command could be used to check out a file so that only the user profile performing the checkout could unlink the file or make any updates to the content of the file. Only the checkout user or a user with special authority could check the object back in.
3. Set the "restricted rename and unlink" attribute for the parent directory. This makes it so that only the owner of the object, the owner of the object's parent directory, or someone with *ALLOBJ special authority can unlink it, regardless of any other authorities to the object.
4. Add a second link to the object so you can relink the file with the original link and call the ftp job again if it gets unlinked prematurely.
For example:
The file being used is: /dir1/myfile
Add another hard link to it through a path that has restricted access.
ADDLNK OBJ('/dir1/myfile') NEWLNK('/securedir/myfile') LNKTYPE(*HARD)
The functions can run as they are. If you find that /dir1/myfile was unlinked prematurely, you can add the link back:
ADDLNK OBJ('/securedir/myfile') NEWLNK('/dir1/myfile') LNKTYPE(*HARD)
Run the ftp job again which will unlink /dir1/myfile
Then unlink /securedir/myfile.

Attachment (Use case): Savefile with sample program