NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Mike, > From: address@hidden > Organization: NOAA/FSL > Subject: problems installing new netCDF on VMS > Keywords: 199603142352.AA00600 netCDF VMS In the above message you wrote: > Even though I've followed the instructions, I'm having problems > getting the new netCDF installed on my VMS system. I've been using a > very old (1989) version, and would like to upgrade. > > Here's what I've done so far, along with a description of the problems I've > encountered. > > 1. Downloaded the distribution to a Unix machine. Uncompressed and untarred. > > 2. FTP'ed (ASCII) everything to my VMS machine (MicroVAX III series, VMS > version up-to-date -- I don't know the version number, but can get it if > needed). There are some binary files in the distribution. These files might be corrupted by an ASCII mode FTP transfer. The binary files are fortran/fills.nc libsrc/test_cdf.sav xdr/test_xdr.sav > 3. Followed the VMS instructions in INSTALL. To wit, ran makevms.com for the > following source directories, in order: > > [.xdr],[.libsrc],[.nctest],[.fortran.vms],[.ncdump],[.ncgen] > > The only errors encountered were in [.fortran.vms]ftest.exe, which worked > fine except for errors in testing fill data (initial error FILLS.NC not a > netCDF file, then more after that). The file fills.nc contains fill-values that we generated here. If the file was corrupted as mentioned above, then this could explain the fill-value testing errors. > NCTEST worked as expected. This is good. > 4. Tried to run ncgen -- it blew up. Then looked in the ncgen directory and > found test.com, ran it, and it blew up on the first test: > > ncgen -o test0.nc test0.cdl here's the resulting output: > > %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000004, > PC=00018113, PSL=03C00021 As I recall, reason mask=00 means that the process tried to access memory outside of its virtual address space (e.g. dereferencing a NULL pointer). I'll have to investigate this one and will get back to you as soon as I can. > Improperly handled condition, image exit forced. > > Signal arguments Stack contents > > Number = 00000005 00000000 > Name = 0000000C 08000020 > 00000000 0000A060 > 00000004 7FE4D540 > 00018113 00018145 > 03C00021 0000A0B0 > 00000000 > 08000020 > 7FE4D580 > 7FE4D558 > > Register dump > > R0 = 00000001 R1 = 0000005D R2 = 00000001 R3 = 0000A30C > R4 = 00000001 R5 = 0007DC77 R6 = 0000A1EC R7 = 0000A1FC > R8 = 0000A208 R9 = 0000A1CC R10= 0000A158 R11= 0000A098 > AP = 7FE4D4EC FP = 7FE4D4AC SP = 7FE4D528 PC = 00018113 > PSL= 03C00021 > > I also noted that README in ncgen refers to compiling [.util]getopt. > However, there's no indication that this is used in ncgen's makevms, > and there's no locating the string getopt in any of the makevms files. > Perhaps this means something? The DECC runtime library now supplies a getopt() function, so the utilities use that instead of the one in the [.util] directory. The README needs to be updated to reflect this. > 5. Tried to run ncdump on a valid netCDF file (the netCDF file's not part > of your distribution. Got the following output: > > %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000002, > PC=0000C437, PSL=03C00021 > > Improperly handled condition, image exit forced. > > Signal arguments Stack contents > > Number = 00000005 00000000 > Name = 0000000C 08000020 > 00000000 00001D80 > 00000002 7FE4D53C > 0000C437 0000C469 > 03C00021 00001DD0 > 00000000 > 08000020 > 7FE4D57C > 7FE4D554 > > Register dump > > R0 = 00000001 R1 = 000001F8 R2 = 00000001 R3 = 00001F80 > R4 = 00000001 R5 = 00000460 R6 = 00001E78 R7 = 00000001 > R8 = 00000050 R9 = 7FFECC54 R10= 0006F434 R11= 00001DB8 > AP = 7FE4D4E8 FP = 7FE4D4A8 SP = 7FE4D524 PC = 0000C437 > PSL= 03C00021 > > > Please let me know where I went wrong. I'd like to get the utilities working > before I start messing with my applications. > > Thanks, > > - - - Mike Barth > address@hidden > 497-6589 I'll investigate and let you know what I find. -------- Steve Emmerson <address@hidden>