On 23/06/2010, at 11:46 PM, Dennis Lovelady wrote:
Still, I haven't seen an answer about negative return code while
errno is
zero. OTOH, I have not looked at documentation for the RENAME API
that
you're using.
I thought I explained (a possible reason for) that? Perhaps I wasn't
clear enough:
In C the rename function maps to three different possibilities:
1. rename()
2. Qp0lRenameKeep()
3. Qp0lRenameUnlink()
1. is used when compiling with SYSIFCOPT(*NOIFS) and is the default
behaviour. It expects the old and new names in lib/file(mbr) format.
2. and 3. are used when SYSIFCOPT(*IFSIO | *IFSIO64) is used. It
expects the old and new names in IFS format (i.e., dir/dir/file.extn).
rename() is defined in stdio.h but is overridden to one of the Qp0l
variants in qp0lstdi.h if SYSIFCOPT(*IFSIO | *IFSIO64) is specified.
The specific Qp0l variant used depends on your Posix preference:
Choosing Posix compliance maps to Qp0lRenameUnlink() otherwise it maps
to Qp0lRenameKeep().
Documentation for rename in the C Run-time Library reference shows it
returns 0 if successful, otherwise non-zero. Prior to VRM530 it did
not list any ERRNO values in the error case. This indicates to me that
it does not set errno. Compare with the 530 documentation where it now
lists ECONVERT as the only errno value set.
Documentation for Qp0lRenameKeep and Qp0lRenameUnlink list many more
errno values that can be set.
To verify my original supposition I wrote the following test program:
#include <stdio.h>
#include <errno.h>
#include <string.h>
int main ( void )
{
int rc = 0;
rc = rename( "/home/shc/test_rename_from_C.txt",
"/home/shc/successfully_renamed_from_C" );
if ( rc < 0 )
perror( "rename() error" );
return 0;
}
The source file does exist. I compiled using CRTBNDC with all default
values. Running it gave:
rename() error: There is no error.
Press ENTER to end terminal session.
which shows that the rename() function failed but errno was not set.
What is the cause of the failure? In typical C fashion we don't get
told the cause but the most likely reason is using an IFS path name
instead of a lib/file(mbr) style name.
Simply recompiling with SYSIFCOPT(*IFSIO) made the program function
correctly because rename() is now mapped to one of the IFS-aware
variants. Changing the code to rename a lib/file(mbr) object works too
thus supporting my supposition as to the cause of failure.
What have we learned? When calling C functions from RPG you have to
know what's going on in the C pre-compiler to ensure you invoke the
correct function, and you have to read the C documentation to be sure
the function does what you think it does--or simply avoid the C file
functions and use the Unix-style IFS APIs directly.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
