Strange behavior from unlink() Unix-type API

[James Lampert <jamesl@xxxxxxxxxxxxxxxxx>]

We've recently noticed some strange goings-on with the unlink() API call.

We call it (from RPG, FWIW) to delete an IFS file, and it fails.

We modified the call, so we're catching the return value, and checking 
errno, and sure enough the call is failing, and errno is coming back 
with 3401, "EACCESS."

And the owner/creator can't delete it from the command line, either.

Looking at the authority on the IFS file, we find that, for some reason, 
the creator/owner has no object authority, but *PUBLIC has *ALL object 
authority.

Now, I've done some things (an ownership change, as I recall, and I 
think it's to the group profile) to protect the files we're talking 
about from being deleted inadvertently as a result of user profile 
deletion, but I can't imagine how that ownership change would result in 
the owner of an IFS file being locked out.

On closer examination, I see that the ownership change is *not* 
happening in the affected directory, yet it apparently *is* happening in 
another environment's IFS directory. And in the directory where it's 
working properly, the group profile owner is retaining full rights to 
it. This just keeps getting weirder.

Anybody have any insights here?

--
JHHL