Re: OpenVMS and CVS-1_11_21 client

[Piet Schuermans]

Mark,

It works fine. Just rebuild and tested.


I had some problem with [.src]client.c
Based on your last e-mail I restored client.c to it's original state,  
meaning I removed my error handling in
both handle_m and handle_e.  Result check-out CVS test failed.
Error: "cvs: cannot write to stderr: socket operation on non-socket"
So I restored the error handling in both routines and CVS Client  
tests returned no errors.

[ [part of e-mail addressing select(..) problem in handle_m and  
handle_e]
The problem is not the client.c code but an VMS issue with file  
descriptors stderr and stdout that are not associated with a socket.
(VMS Release notes => The select() function has been corrected to  
return failure status if either invalid file descriptor or file  
descriptor not associated with a socket is found in one of the  
specified file descriptor sets. In case of invalid file descriptor,  
the select() function sets errno to EBADF. In case of a file  
descriptor not associated with a socket, the function sets errno to  
ENOTSOCK.
Failure with errno set to EBADF is the standard requirement for the  
select() function. Failure with errno set to ENOTSOCK is because  
currently the select() function can operate only on sockets.
So if I check in both routines not only the returning value of select 
(...) but also the errno. And handle the case when errno == ENOTSOCK.  
it would work again with the "original" cvs source files. So instead  
of simple comment out the select() function I replacing it with a vms  
specific wrap function VMS_Select( ) in which I handle the set errno  
values.
] ]


Piet.



On Nov 14, 2005, at 20:49, Mark D. Baushke wrote:

> Hi Piet,
>
> I am given to understand by a MacOS X (10.3.6)
> user that neither the MACOS nor the TARGET_OS_MAC
> macros are being defined during a normal cvs
> configure and build operation which makes the
> VMS_filename_classes symbol become unresolved due
> to the last patch to system.h
>
> It appears that USE_VMS_FILENAMES may be a
> reasonable macro to use as an alternative to
> choose between VMS and MacOS X filesysstems.
>
> Could you verify that this patch would work for
> you?
>
>         Thank you,
>         -- Mark
>
> Index: system.h
> ===================================================================
> RCS file: /cvsroot/cvs/ccvs/lib/system.h,v
> retrieving revision 1.81
> diff -u -p -u -p -r1.81 system.h
> --- system.h    9 Nov 2005 10:59:21 -0000       1.81
> +++ system.h    14 Nov 2005 19:47:22 -0000
> @@ -284,12 +284,12 @@ extern unsigned char WNT_filename_classe
>     * WOE32 needs its own class since \ and C:\ style absolute  
> paths also need
>     * to be accounted for.
>     */
> -#  if defined(MACOS) || defined(TARGET_OS_MAC)
> -#   define FOLD_FN_CHAR(c) (OSX_filename_classes[(unsigned char)  
> (c)])
> -extern unsigned char OSX_filename_classes[];
> -#  else
> +#  if defined(USE_VMS_FILENAMES)
>  #   define FOLD_FN_CHAR(c) (VMS_filename_classes[(unsigned char)  
> (c)])
>  extern unsigned char VMS_filename_classes[];
> +#  else
> +#   define FOLD_FN_CHAR(c) (OSX_filename_classes[(unsigned char)  
> (c)])
> +extern unsigned char OSX_filename_classes[];
>  #  endif
>  # endif /* __CYGWIN32__ || WOE32 */