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.
Ah, good to know. > Mike... > > I found a fix to the problem. Here's what I posted on gembud: > > > > FOR THE RECORD: Fixed! > > I have no idea why this worked. I re-generated my LDM pqact.* files from the > gen_pqact.csh script instead of the gen_pqact_GEMDATA.csh script. For > whatever > reason, the dc* decoders like to dump the decoded .gem files into the > $LDMHOME/data symlink. I just created another sym link inside $LDMHOME/data > and pointed it to where I wanted the data to go, and now all is well. > > HUGE THANKS to Michael James for taking the time to look into this for me! > > -Mike- > > > Hopefully others could benefit. > Thanks for the help! > > -Mike- > > -----Original Message----- > From: Unidata GEMPAK Support [mailto:address@hidden] > Sent: Thursday, June 28, 2012 10:37 AM > To: Van Tress,Michael J (BPA) - PGPW-5 > Cc: address@hidden > Subject: [GEMPAK #NTP-422184]: no data written by dc* progs > > Some things to check: > > - Is ~ldm/data/ full or near full? The unix command 'df' will show filesystem > usage. If it's near-full then you may be out of disk space and you'll have to > modify the scouring of old data files. > > - Verify the read/write/execute permissions on ~ldm/data/gempak/ > > - Are there two instances of any one decoder running concurrently? If so > both instances may be trying to write to the same file. If you see multiple > process IDs in the decoder log at approximately the same time this would > indicate multiple instances of a decoder and we'll have to find the duplicate > pattern action in your pqact files. > > > Michael James > Unidata > > > > I've noticed from the past posts that this has been a problem, but I don't > > see a post with a solution. > > Is there a soltuion? I'd be very greateful if someone would share if there > > is. > > > > I've disabled ipv6 on our system. > > > > Here's a previous description that fits mine to the tee: > > > > > > I've run into a problem with 5.11.4 where the decoders will not write files > > into $GEMDATA. If I wipe out the directory structure, the progs will create > > all of the proper subdirectories, but they will not be populated with data. > > In the various log files, all the apps complain about not being able to > > write to files. I've double checked the write permissions on the > > directories and ldm has write permissions (gempak was built under the ldm > > account, no gempak user.) > > My system is: Redhat Enterprise 4 > > Kernel is: 2.6.9-89.ELsmp #1 SMP Mon Apr 20 10:34:33 EDT 2009 i686 i686 > > i386 GNU/Linux > > There were no errors in the make or make_install logs that I could tell. > > > > > > > > > > Ticket Details > =================== > Ticket ID: NTP-422184 > Department: Support GEMPAK > Priority: Normal > Status: Open > > Ticket Details =================== Ticket ID: NTP-422184 Department: Support GEMPAK Priority: Normal Status: Open