errno and other global variables -- RPG400-L

But aside from right or wrong, I think Scott's way is just plain nicer.It doesn't interrupt the normal flow with the assignment to errno, and
the checking for an error is directly related to the call that is being
checked.

   parm = something;
   errno = 0;                    // this line gets in the way
   retval = somefunction(parm);
   if errno <> 0;                // check seems unrelated to the call
     --- handle the error
   endif;

vs

   parm = something;
   retval = somefunction(parm);
if retval indicates failure;--- handle the error, possibly referring to errno
   endif;

Scott's remark 'Therefore, you shouldn't use errno to detect if there'san error or not.' is exactly on the money. That's what the return valueis for (usually). But this remark 'You risk screwing up other routineswhen you set it to zero.' seems to be a defence of long-persistenceglobal variables. If multiple routines depend on errno to remainunchanged, that's a red flag for a bug.

This is a very close approximation to the old SETLL/READ situation, whenREAD would set the EOF indicator, but not reset it. So we were veryused to seeing:


setof 80
read master 80
80 ...

We were NOT used to seeing:

move *blanks name
read master 80
name comp *blanks (=30)
30 ...

If someone used indicator 80 for ALL I/O, and wrote code that used 80all over the place to test whether I/O to MASTER was successful, thatcode is going to go casters up when someone adds a chain to PRODUCT.This is the case with errno. We are _forced_ to use the same variableall over the place because we can't assign a different 'indicator.'

It seems to me that a more robust philosophy is to localise thatreference as much as possible: test it within a line or two of whereit's set. If you can't do that, the next reasonable mechanism seems tome to store the value in a private variable and use _that_. In ourtheoretical example, that might be:


 parm = something;
 retval = recv(parm);
 if retval <> NORMAL;
   recv_errno = errno;
 else;
   recv_errno = NORMAL_ERRNO;
 endif;

One might argue that one does not want a special NORMAL_ERRNO value:

 parm = something;
 retval = recv(parm);
 if retval <> NORMAL;
   recv_errno = errno;
   recv_error = TRUE;
 else;
   recv_error=FALSE;
 endif;

Now one can refer to recv_error to one's heart's content. Of course,the nomenclature is still less than stellar for a global variable.Rather than refer to the I/O operation, better (IMO) is:


 // see if the automated clearing house acknowledged our login
 parm = something;
 retval = recv(parm);
 if retval <> NORMAL;
   ACH_login_errno = errno;
   ACH_login_error = TRUE;
 else;
   ACH_login_error=FALSE;
 endif;

In any event, it seems to me that the greater of the two evils isallowing a long-persistence global variable to hold a consistent statethroughout one's code.

  --buck