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.
> > Just so you have all of the pieces. > And, just to mention a utility available in GEMPAK in case you wanted to save some of the date subtraction voodoo: There is a program call datetime (which will give you its usage details if you type that command by itself). To subtract 4 hours from the current GEMPAK format UTC time: datetime -s `date -u +"%y%m%d/%H%M"` 04:00 You can optionally specify an output format as necessary. Steve Chiswell Unidata User Support > > > > 301-874-1911 DIJM > 240-687-0036 cell > > (\__/) > (='.'=) > (")_(") > > > -----Original Message----- > From: Unidata GEMPAK Support [mailto:address@hidden] > Sent: Friday, October 05, 2007 3:47 PM > To: Kerich, Steve (DIJM) > Cc: address@hidden > Subject: [GEMPAK #AJO-748565]: GEMPAK - Possible problem with 5.10 > decoder > > Steve, > > I see that your script uses "EOD" twice as SFLIST<<EOD EOD > > That label should be unique, such as: > SFLIST<<EOD_YESTERDAY > EOD_YESTERDAY > > SFLIST<<EOD_TODAY > EOD_TODAY > > I can't guarantee that is your problem, but is seems like when your > script enters into the block of IF ( TIME3 != "" ), that defines EOD, so > you only run yesterdays sflist until you hit 4Z when I assume $TIME3 > becomes nill and you don't overlap your use of EOD. > > That may be an esoteric difference...which you should try correcting. > > I can tell that your 0Z file looks to have times from what appear to be: > 0709271945 to 0709272344 > > The 1Z file: > 0709272045 to 0709272344 > > The 2Z file: > 0709272145 to 0709272344 > > The 3Z file: > 0709272245 to 0709272344 > > The 4Z file: > 0709272345 to 0709280437 > > That probably indicates whatever processing you are doing is looking at > yesterdays file only until 4Z when it switches over to the current day's > file (and not looking at yesterdays). You also source something called > backhour which I can only assume is computing the time for yesterday > (possibly minus 4 hours?) I would guess your script is failing execute > the 2 unique invocations of SFLIST (FILETODAY and FILEYEST) and you are > only getting one in any case. > > Some little things that might help are to redirect the SFLIST output, or > log the script output to a file to verify what SFLIST is doing in both > instances. Also, set $RESPOND=yes and add a blank line after the "r" for > run so that your log output will show the proplt verification of what > your running settings are for SFLIST each time. > > Steve Chiswell > Unidata User Support > > > > > > ************************************************ > The information contained in, or attached to, this e-mail, may contain > confidential information and is intended solely for the use of the individual > or entity to whom they are addressed and may be subject to legal privilege. > If you have received this e-mail in error you should notify the sender > immediately by reply e-mail, delete the message from your system and notify > your system manager. Please do not copy it for any purpose, or disclose its > contents to any other person. The views or opinions presented in this e-mail > are solely those of the author and do not necessarily represent those of the > company. The recipient should check this e-mail and any attachments for the > presence of viruses. The company accepts no liability for any damage caused, > directly or indirectly, by any virus transmitted in this email. > ************************************************ > Ticket Details =================== Ticket ID: AJO-748565 Department: Support GEMPAK Priority: Normal Status: Closed