>From: 10 <address@hidden> >Organization: NMSU/NSBF >Keywords: 200102182128.f1ILSbL25380 McIDAS ADDE named datasets IMGCOPY Robert, >I know that 7.7 allows you not to be restrained to AREA files.. It is not constrained to AREA file naming convention for input. It takes a subserver to know how to read imagery in non-AREA file format. >so I set up a data set as this > >TEST/IMAGE IMAGE AREA > > DIRFILE=/export/home/weather/images/* Hmm... Since a name pattern was not supplied in the DIRFILE= keyword, I was under the assumption that the file names should be named AREAnnnn. I say this because of a comment that Dave Santek made at either the last MUG meeting or the one before. Closer examination and testing shows this to not be true, however. >I would like to do an imgcopy from another machine into this dataset, >but when I try IMGCOPY BLA/BLAH TEST/IMAGE SIZE=ALL, I get an error >IMGCOPY: MCAOUT rc= -1. I gues this has to do with the fact that >since there are no AREA #'s associated with TEST/IMAGES it doesn't >know what to do. Right. It doesn't know how to name the output image. There was just some talk about this sort of thing in the MUG inquiry tracking system (comments from Scott Linstrom). I had thought about this before and came to the conclusion that one would have to come up with a formalism for specifying the naming convention before the output server would have a chance at making up a reasonable name (in the same manner that I created a formalism for the ldm-mcidas decoder, pnga2area). I suppose the output server could name the output file something off the wall and (re)try to get a name that was not already in use, but this has not been implemented. >I knew what I tried would not work..but what >do I need to get it to work since I can't specify anything >other than group/descriptor.position for the dest. dataset? Here are a couple of things that can work: 1) make the destination dataset conform to AREA file naming conventions 2) IF a valid AREA file exists in the directory specified by DIRFILE= and IF your DIRFILE= mask looks like DSSERVE ADD TEST/IMAGES AREA DIRFILE=/home/mcidas/workata/AREA* "AREA form the the IMGCOPY: IMGCOPY RTIMAGES/GE-IR TEST/IMAGES.1 SIZE=ALL will succeed. The write is simply done over the existing AREA file. The ability to describe how an output file is to be named is obviously an area that needs work in McIDAS. Any thoughts you might have on how this can be done would be appreciated. By the way. Does NSBF or Universal Wx have/use any Linux boxes? If so, what OS are they using (version number)? The reason I ask is that I unearthed the inability of serving sounding data (thermodynamic diagrams, UALISTs, and HODOs) through a remote ADDE server hosted on RedHat 6.x,7.x Linux. The process works in RedHat 5.2 and on other platforms where the code is built using gcc/f2c (Solaris x86, FreeBSD, etc.). I have been struggling to pinpoint the source of failure for over a week now and am making very little progress. I am currently looking for sites that might be running something like Debian or Slackware Linux to see if the problem is in the RH distribution on in glibc 2.. I have been looking at this so hard for so long that my head hurts! Tom
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.