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.
>From: "Alliss, Randall J." <address@hidden> >Organization: TASC >Keywords: 200308201138.h7KBccLd008934 McIDAS-X MKRAOBID DSSERVE REDIRECT HI Randy, >i have tried renaming the file, putting it in tmp directories...nothing >works. Hold on, it just dawned on me what your problem is! You are using a DIRFILE= keyword clause to setup a POINT dataset in McIDAS v2002x. The ability to use non-standard McIDAS names for POINT files was not introduced until v2003. The DIRFILE= keyword only worked for IMAGE files in versions previous to v2003. Here is the snippit from the v2002 DSSERVE online help: ************************ DIRFILE Keyword Remarks *********************** Use the DIRFILE='mask' keyword to access image files with names other than AREAnnnn (where nnnn is a 4-digit number) and/or image files outside the MCPATH and REDIRECT directories. The 'mask' value contains the location and names of the files (i.e., the directory and file masks), and is specified using standard Unix substitution rules and wildcards. The file mask consists of all characters after the last slash; everything before and including the last slash is the directory mask. For example, if you specify DIRFILE='/home/user/goes/images/199?/Conus*' then /home/user/goes/images/199?/ is the directory mask, Conus* is the file mask, and the entry matches all files beginning with "Conus" that reside in any /home/user/goes/images/ subdirectory whose name is four characters long and begins with "199". If you don't specify any slashes in 'mask', there is no directory mask so the entry is treated as a file mask only and its file(s) must be located in a MCPATH directory. Absolute position numbers in datasets created using the DIRFILE keyword are determined in the order that the files are found by the server, beginning with position 1. Thus, the absolute position number of a file can change if another file is added to or removed from the dataset. Relative position numbers work as expected, so position 0 is the most recent image, -1 is the next most recent, etc. This section clearly talks about images only. This is in contradiction to the section on DIRFILE= in the same online help: Keywords: DIRfile='mask' | directory and/or file mask to locate files with names other than AREA*, GRID* and MDXX*, and/or files outside the MCPATH and REDIRECT directories; do not specify bfile and efile when using this keyword; see the Remarks So, the real cause of your problem is that v2002x does not support what you want to do. The good news is that v2003 does. For now, you will need to rename your data files to follow the MDXXnnnn naming convention and setup your dataset to point at that(those) file(s). >When i changed the name to MDXX0001 and placed in /home/randy/mcidas/data/ >and used the DIRFILE=/home/randy/mcidas/data it actually worked Yup. >BUT when i >change the name to anything else or move it out of ./mcidas/data into a tmp >directory it does not work. It should work in v2003. you entered. This is why it is so important to get the _exact_ text >Are you running this on a linux box? i am running mcidasx2002b. Yes. My mistake yesterday was to setup an IMAGE dataset as an example. That works fine in v2002, but POINT and GRID do not. Support for POINT was added in v2003, but not GRID. In my mind, this it is a high priority item to add GRID to the list of datatypes where one can use the DIRFILE= syntax of DSSERVE as this gets away from the archaic McIDAS naming conventions and does away with the need for REDIRECTions. >Since i am running SSEC mcidas on the IBM where the DIRFILE command works Is the IBM running v2003? If _no_, I am at a loss to explain why it works. >is >there anyway to compile MKRAOBID in that version of MCIDAS? I would be set >then. Yes. You already have a development environment setup on one or more of your machines (from previous interactions about your version of remap2), so building mkdraobid.k should be straightforward. You should be able to simply grab the source code from your Unidata McIDAS v2002b distribution (in ~mcidas/mcidas2002/src/mkraobid.pgm), bring it over to your IBM (which is presumably running v2003) and build it in the same way that you build your own version of remap2. > >Randy > > > >-----Original Message----- >From: Unidata Support [mailto:address@hidden] >Sent: Wednesday, August 20, 2003 7:43 PM >To: Alliss, Randall J. >Cc: address@hidden >Subject: 20030820: ualist (cont.) and DSSERVE DIRFILE= (cont.) > > >>From: "Alliss, Randall J." <address@hidden> >>Organization: TASC >>Keywords: 200308201138.h7KBccLd008934 McIDAS-X MKRAOBID DSSERVE REDIRECT > >Randy, > >>ok on the redirect i will try that to make sure it works (ie., *.ISF*) > >OK. > >>but, regarding DIRFILE='/scratch/tmp/200*ISFC' >> >>i can list the correct files using the ~ls /scratch/temp/200*ISFC on ALL >>systems (IBM, ALPHA, LINUX) > >Since ISFC is a suffix, try: > >DIRFILE=/scratch/tmp/200*.ISFC > >>PTLIST SFC/DATA.1 FORM=FILE however only works on IBM...i expect problems >on >>the ALPHA but not LINUX box. >> >>am i missing anything else? > >Since the DIRFILE= stuff follows the rules for the platform it is used >on, I suspect that the file name mask is being intperpreted as >200*ISFC, like 2001172ISFC, not, 2001172.ISFC, etc. Try the DIRFILE >I listed above. > >>Tom, there is no ~/workdata/AREA1236 to copy. > >My listing was meant as an example. The steps it was meant to illustrate >were: > >- create a new directory not in MCPATH > >- copy an AREA file to that directory, but give it a name that has a > suffix that is longer than 3 characters > >- setup an ADDE dataset that uses a DIRFILE= with a suffix that is > longer than 3 characters > >- test access to the image in the newly created dataset > >>From address@hidden Wed Aug 20 14:43:30 2003 > >>I am running McIDAS-X 2002b on linux box > >>does it matter that the files are named 20011001.ISFC (ie., >YYYYMMDD.XXXX)? > >Only in so far as the suffix is longer than 3 characters. It sholdn't >matter in the DIRFILE= keword claus for DSSERVE, but it will for >REDIRECTions. > >Tom >**************************************************************************** >< >Unidata User Support UCAR Unidata Program >< >(303)497-8643 P.O. Box 3000 >< >address@hidden Boulder, CO 80307 >< >---------------------------------------------------------------------------- >< >Unidata WWW Service http://my.unidata.ucar.edu/content/support >< >**************************************************************************** >< >