20030821: DSSERVE DIRFILE= for POINT datasets (cont.)

>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
><
>****************************************************************************
><
>