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.
On Wed, 20 Dec 2000 address@hidden wrote: Thanks very much for this. I still have problems compiling dcshef under comet and dcwatch under ldmConnect, but I do not need either of them, so I bypass them. The sfchck still gives the same segmentation violation - maybe once I have upgraded to HPUX-11.00 everything will work out. I'll be doing that first thing in January and will let you know how it works out. The rest works just great and is appreciated! Thanks again for everything and Season's Greetings. Stephen Sinnis | Tell:905.566.9511x379 Pelmorex Inc. ***************************************************************** Stephen, In sfchck.f, there is a large array defined: LOGICAL datflg ( LLSTFL, LLMXTM ) with my defaults of LLSTFL = 29700 and LLMXTM = 300, this probably causes the segmentation fault on startup, before anything in executed. You can try replacing instances of LLSTFL in this program with a smaller number of say 5000 if you don't have more than that number of stations in your surface files. This will let you use this program. Otherwise, you can compile the entire source of GEMPAK using a smaller LLSTFL in the GEMPRM file. In $NAWIPS/unidata/ldmbridge/dcwatch, the Makefile needs $(SYSLIBS) when linking (this will resolve the math functions from -lm). eg: $(PROG) : $(PROG_OBJS) $(LINK.f) $(NOFORMAIN) $(PROG_OBJS) $(LIBS) $(SYSLIBS) -o $@ (I found that when make failed in dcwatch, it also skipped building in $NAWIPS/unidata/programs). I haven't found anything in compiling dcshef as of yet. Steve Chiswell Unidata User SUpport