[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
960102: Problems running under OSF1 version 4.0 on an Alpha station
- Subject: 960102: Problems running under OSF1 version 4.0 on an Alpha station
- Date: Thu, 02 Jan 97 11:03:38 -0700
Alison,
> To: address@hidden
> cc: Alison Macdonald <address@hidden>
> From: Alison Macdonald <address@hidden>
> Subject: Problems running under OSF1 version 4.0 on an Alpha station
> Organization: Oregon State University
> Keywords: 199701010014.RAA03943
In the above message you wrote:
> I have been running the GMT (Generic Mapping Tools) software package
> out of the University of Hawaii which uses NetCdf. I have an Alpha
> workstation previously running version 3.2b of the operating system, now
> running 4.0. Since the upgrade I have not been able to create netcdf files
> through the GMT calls to netcdf routines. I have re-installed both
> NetCdf and GMT.
>
> The test case I am using is a call to the gmt program xyz2grd.
> It opens the file using ncopen, calls ncvarid, ncattget, ncvarget
> and ncendef. The file exists after the open, but after the call to
> ncendef, the variable ncerr has been set = 32.
Hmm... A error code of `32' indicates a failure to XDR something.
> It then proceeds to
> call ncvarput and ncclose. The file disappears at ncclose and the
> program produces an error when it checks the ncerr value.
>
> GMT and NetCdf did not have this problem under the previous version
> of the operating system and the test routines supplied with netcdf,
> do not produce any errors (other than a warning in the test programs
> themselves about strings being continued over lines). I wondered if
> you had any experience with the software being run under this new
> operating system that might give me clue as to the source of the
> problem.
My workstation is OSF1 V4.0B (it used to be V3.2 and V4.0). As far as
I can tell, the netCDF 2.4.3 package works correctly on this system.
Therefore, I suspect that the problem lies with the GMT package (which
we don't have here). The only realistic hope in fixing a hypothetical
problem in the netCDF package would seem to lie with either you or the
GMT people getting me a small piece of C code that illustrates the
problem.
>
> I am also writing to the GMT people because although the error occurs in
> the NetCdf routines, I don't know how to reproduce the problem outside of
> GMT.
If you converse with the GMT people, please tell them that I'll be happy
to assist in any way that I can.
> I would be grateful for any assistance you can offer
>
> Alison Macdonald
>
>
> ps. Some of the things I have checked include:
> removing the optimization (same error occurs)
> the write access on the file (I appear to have write access)
> going back to the previous version of the operating system (still
> works)
This last one is odd because, if the low-level error is in the XDR
layer, then I would think that the problem would manifest itself under
both versions of the OS.
--------
Steve Emmerson <address@hidden>