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.
>From: "Fingerhut, William A" <address@hidden> >Organization: Lyndon State >Keywords: 200207191535.g6JFZa920941 McIDAS-X XCD REDIRECT Bill, Sorry to not be answering questions very fast, but I just returned from a trip to Brasil and Argentina durning which I picked up a bad case of the "grunge" (maybe dysentery, but I am not sure). I am at home where I work a little and then go nap for awhile. >From your email, it is apparent that the REDIRECT MAKE >was never done. I just did >REDIRECT REST LOCAL.NAM >REDIRECT MAKE >BATCH "XCD.BAT >BATCH "XCDDEC.BAT >etc...... The key elements in the sequence are doing the REDIRECT REST LOCAL.NAM before doing the BATCH XCD.BAT. The REDIRECT MAKE is not absolutely necessary, but it doesn't hurt. >I exited mcidas (as mcidas) and restarted mcidas. >No error message, and redirections look okay. Yea! > >I restarted the ldm, just in case. Restarting the LDM was a good move. The reson for this is that the XCD processes are started by the LDM via the 'xcd_run MONITOR' action in ~ldm/etc/ldmd.conf. This has the effect of starting the XCD routine startxcd.k whose job it is to keep all of the data monitors (e.g., DMSFC, DMRAOB, etc.) running. These processes are then children of xcdstart.k. startxcd.k picks up things like McIDAS REDIRECTions upon startup only. Changing REDIRECTions after startxcd.k is running will not result in startxcd.k _or any of its children_ picking up the new/changed REDIRECTions. >Now for the main problem -- our surface and upper data haven't >been found by mcidas (all users) since last Friday. OK. As the user 'mcidas' can you find the MD files into which that data is decoded? You do this by using DMAP from a McIDAS-X session as the user 'mcidas': DMAP MDXX If 'mcidas' can see the files, then the REDIRECTions are OK. If 'mcidas' can not see the files, it either means that the files don't exist or the REDIRECTions are wrong. >I think that adde and redirection are okay. OK. >I am puzzled by not finding any *.RAT files??? This is not good because it indicates a problem. >From linux, I just did a stat.k -- on the SAODEC line, >the GridF/MD is shown as 10, the time and pointer values, >Begptr and Lasptr, increase every time I run stat.k >The Row column is empty. > >Any ideas??? An idea: if a bad/munged MD file existed before your modifying your REDIRECTions the decoder will not be able to write correctly to it. In this case I would: o stop the LDM o delete the MD file(s) o delete the *.RAP and *.RAT files that should exist in the XCD output directory Also, just in case you didn't do this before, or if something got deleted, make sure that you defined the McIDAS string XCDDATA. Defining XCDDATA was one of the steps that had to be done in the XCD setup process. The BATCH file XCD.BAT uses the value of XCDATA to setup REDIRECTions for all of the *.RAP and *.RAT files. Looking at the list of things you did above coupled with your comment about not having the *.RAT files, I would ask you to check to make sure that you did the following: REDIRECT REST LOCAL.NAM TE XCDDATA "whatever_directory_you_are_using_for_XCD_decoding BATCH XCD.BAT BATCH XCDDEC.BAT The BATCH XCD.BAT line will setup the REDIRECTions for the *.RAP and *.RAT files, and it is the last line that will create the *.RAP files in the directory named in XCDDATA. Before restarting the LDM make sure that the *.RAP files exist in the XCD output directory. I would do this using DMAP: DMAP *.RA The *.RAT files will get created by the XCD decoders if everything else in the XCD setup is correct. Got to run (literally)... Tom