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.
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>