[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help for DEC implementation

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: Help for DEC implementation
  • Date: Tue, 06 Sep 94 12:02:02 -0600
>From: David van Senden <address@hidden>
>Subject: Help for DEC implementation
>To: address@hidden
>Date: Mon, 5 Sep 1994 15:24:15 +0800 (AWST)

In the above message you wrote:

>I am trying to get the NetCDF package to work properly on a DEC Alpha (running
>OSF/1 version 3.1),

I don't know if I'll be able to help you as we are running OSF/1 version
2.1.

>but I keep getting XDR error messages whenever I create a
>few dimensions and variables, and then call NCENDF() (I'm using it with
>FORTRAN). As soon as NCENDF() is called, it outputs the error message:
>    ncendef:xdr_NC_array:xdr_enum

Would you please send me a simple program that illustrates the problem
by behaving incorrectly.

>I have successfully compiled the NetCDF package (and it's FORTRAN jacket) on
>this DEC machine, with no warning messages whatsoever. I have done the
>following things:
>    1:  Defined only the variable SWAP during preprocessing (not DOS_FS or
>NO_SYSTEM_XDR_INCLUDES).
>    2:  Replaced the conditional directive " #ifdef NO_SYSTEM_XDR_INCLUDES " in
>local_nc.h by the 2 lines:
>            #include "types.h"
>            #include "xdr.h"
>    3:  Modified the return type of the function xdr_posix_getpos() to return
>unsigned long rather than unsigned int, as the xdr_pos struct was initializing
>it's 5th field (of type pointer to function returning unsigned long) to this
>function, resulting in warning messages about incompatible types whenever I
>compiled the library in the libsrc directory.

For what it's worth, none of the above was necessary on our OSF/1 2.1 
platform.

--------
Steve Emmerson   <address@hidden>