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.
Glenn, I guess I should have added after replacing the Makefile: cd $NAWIPS/unidata/ldmbridge/dcredbook make clean make all make install make clean After you have the dcredbook_vg installed, then all you need to do is edit your script and change dcredbook to dcredbook_vg and remove the gpend line. Steve Chiswell Unidata User Support >From: "Glenn Rutledge" <address@hidden> >Organization: NCDC >Keywords: 200103271909.f2RJ9nL23483 >Thanks you Steve, >I've substituted the Makefile for the existing one. It that all I have to do? >I'll see if it works since I've killed all the processes (vg and gplt) and tur > ned >on the pqact.conf file for the graphics. > >Thanks much- your amazing! Glenn > >General Support wrote: > >> Glenn, >> >> Looking at your "ps" output, it appears that many of the VG processes are >> started concurrently (eg many products coming in at the same time). >> This probably indicates a race condition with the system handing out >> message queue ids. As a result, the time between getting an ID and >> starting up the gplt and vg process is probably overlapping with >> other processes. >> >> To eliminate the message queues, we can directly link the vg driver >> to the dcredbook process. I have attatched a Makefile for the >> $NAWIPS/unidata/ldmbridge/dcredbook directory to replace the >> existing one. >> >> This new Makefile will create a "dcredbook_vg" executable in the >> same manner as the dcredbook_ps and dcredbook_gf programs. >> >> You can use this dcredbook_vg executable in your pqact script >> and eliminate the "gpend" line in the script (since you will no longer >> be creating a message queue, no gpend will be needed). >> >> Let me know if you continue to see the problem. >> You will need to kill off your existing "vg" and "gplt" processes that >> are eating up your system resources. >> >> Steve Chiswell >> Unidata User Support >> >> >From address@hidden Tue Mar 27 08:28:58 2001 >> Received: from mercury.ncdc.noaa.gov (mercury.ncdc.noaa.gov [192.67.134.126] > ) >> by unidata.ucar.edu (UCAR/Unidata) with ESMTP id f2RFSuL08638 >> for <address@hidden>; Tue, 27 Mar 2001 08:28:57 -0700 (MST > ) >> Keywords: 200103271528.f2RFSuL08638 >> Received: from noaa.gov ([192.153.129.193]) by >> mercury.ncdc.noaa.gov (Netscape Messaging Server 4.15) with >> ESMTP id GAV4C700.UUO for <address@hidden>; Tue, 27 >> Mar 2001 10:28:55 -0500 >> Message-ID: <address@hidden> >> Date: Tue, 27 Mar 2001 10:29:19 -0500 >> From: "Glenn Rutledge" <address@hidden> >> Organization: NCDC >> X-Mailer: Mozilla 4.75 [en] (Win98; U) >> X-Accept-Language: en >> MIME-Version: 1.0 >> To: Unidata Support <address@hidden> >> Subject: [Fwd: redbook Graphics Pblm] >> Content-Type: multipart/alternative; >> boundary="------------C056EA6BA75FC9BC4522C69F" >> >> --------------C056EA6BA75FC9BC4522C69F >> Content-Type: text/plain; charset=us-ascii >> Content-Transfer-Encoding: 7bit >> >> -------- Original Message -------- >> Subject: redbook Graphics Pblm >> Date: Tue, 27 Mar 2001 08:42:02 -0500 >> From: Glenn Rutledge <address@hidden> >> Organization: NCDC >> To: Unidata Support <address@hidden> >> >> Steve, >> Yesterday I turned my redbook processing back on and by today I've got >> all those vg and gplt processes running. A grep on the vg's reveal the >> below number of processes. Any thoughts as to why this is running >> amuck? We have the following script that we pipe the data to : > npfos:/npraid/noaaport/nawips/bin/scripts->more dcredbook.csh >> #!/usr/bin/csh -f >> # the source line below will set the locations of your GEMMAPS and >> GEMTBL >> # directories from your Gemviron file >> source /npfos/noaaport/nawips/Gemenviron >> >> # To generate gifs using the gf device, you need permission to draw to >> # an X server. Otherwise, you could use the gif2 device or ps driver >> # as shown below. >> setenv DISPLAY unix:0 >> >> cd /npfos/noaaport/nawipsdata/redbook >> >> set DATE=`date -u '+%Y%m%d'` >> set LOGFILE=/npraid/noaaport/nawips/logs/${DATE}_dcredbook.log >> >> cat | /npfos/noaaport/nawips/bin/sol/dcredbook -v 1 -d $LOGFILE >> 'vg|%P_YYYYMMDDH >> HNN.vgf' >> #cat | /npfos/noaaport/nawips/bin/sol/dcredbook_gf -v 1 -d $LOGFILE >> 'gf|%P_YYYYM >> MDDHHNN.gif|1280;1024' >> gpend >> exit 0 >> >> # The above uses dcredbook_gf. Alternatively, to produce postscript >> files >> # without an X server, you could use: >> #cat | dcredbook_ps -v 1 -d $LOGFILE 'ps|%P_YYYYMMDDHHNN.ps|8.5;11|C' >> >> #or, to use the gif2 driver, just use the generic dcredbook program >> #and run gpend when finished: >> #cat | dcredbook -v 1 -d $LOGFILE 'gif2|%P_YYYYMMDDHHNN.gif|1280;1024' >> #gpend >> >> [Image] >> >> Thanks, Glenn >> >> **************************************************************************** >> Unidata User Support UCAR Unidata Program >> (303)497-8644 P.O. Box 3000 >> address@hidden Boulder, CO 80307 >> ---------------------------------------------------------------------------- >> Unidata WWW Service http://www.unidata.ucar.edu/ >> **************************************************************************** >> >> ------------------------------------------------------------------------ >> Name: Makefile >> Makefile Type: Plain Text (TEXT/PLAIN) >> Encoding: BASE64 >> Description: Makefile >