>From: alan anderson <address@hidden> >Organization: St. Cloud State >Keywords: 199906211923.NAA20658 McIDAS ADDE Alan, >Regarding the items you listed above; > >The MDX command ran ok this morning, after I used the syntax you listed; OK. >So do the F key menu commands that access upper air data files. OK. >UL List continues to give the 'no sounding available message'. I logged onto your PC and, using c:\mcidas\tools\mcrex.cmd, discovered why UL is not returning any data. It is the same reason that the MDX command was failing: the format of the DAY key in the upper air MDXX files was changed from YYDDD to CCYYDDD. The following UL command will work: UL LIST 72469 DAY=1999173 We updated UL in our 7.5 release to use the correct DAY format based on what the MD file DAY key looks like. The other thing that was updated in 7.5 was the format of the date string avaliable in the string table. For version previous to 7.5, Y (the date) would look like: 99173 This is how your system presents Y. For versions 7.5 and above, the date will look like: 1999173 UL and other routines read the clock to determine the current time. The then format a McIDAS command specifying things like DAY, and the MDX search routines look for exact matches. The match will fail when DAY in the file is in the form CCYYDDD and the form of DAY specified on the command line or internally are in YYDDD. The fix for these kinds of problems is to upgrade to 7.50. >The Mcidas version is 7.401, with a date of 980820. This is the reason that UL doesn't work "out of the box". >The file IDGROUP.EXE >does not exist on the disk of this os2 machine. I will check on our other >machines as well as I think we changed to 7.4 at about the same time on all >of them. From your earlier comments, I assume that even if IDGROUP.EXE did >exist, and XCDCLI.BAT ran successfully, this would not solve our problem. After thinking about this, and after asking Don, I see that the lack of IDGROUP.EXE on your system was caused by not loading the XCD component of the OS/2 distribution. Since this really shouldn't be necessary for machines not running XCD for OS/2 (like your OS/2 boxes), it appears that the batch file XCDCLI.BAT is in error in its inclusion of the 'IDGROUP LIST' command. The good news is that this is the very last line of XCDCLI.BAT, so all things before it have been executed correctly. >The machine we are dealing with on these items has the name 56F and >IP of 199.17.31.12; ... Thanks this helped cut though a couple of problems quickly. >Will using DATALOC to point to waldo for the datasets change the transfer >speed for F key menu commands the way that it does for command line entries? Only for those menu functions that have been upgraded to use of ADDE routines. I looked through the UNIDATA.MNU menu template on your OS/2 box and see that some things have been upgraded to use of ADDE routines, and some have not: Display type ADDE (Y/N) ---------------------+------------- image load N grid display Y front display N cross sections N (no ADDE routines yet available) surface data plotting N fous14 plotting N etc The upshot is that to use this menu, you will have to access files locally (e.g. via NFS). >I assume >that it does not as the image files already point there. The image loading from the Fkey menu is through ALOOP which calls DF which is not an ADDE routine. >Even if the issues of transfer speed This one is a puzzler. We have lots of experience with folks doing just what you are doing, and they do not see the excessive times to do things like image loads. >(apart from ADDE) and the failure of some >commands The reason for this is now known. >are not resolved, I think we will begin the process of changing to >mcidasx. I think that this might solve a couple/several of your problems: access to data on NFS mounted file systems should certainly be much faster and you will be upgrading to a release of McIDAS that is matched to the release of McIDAS-XCD on waldo. >I assume we go through the process similar to waldo, execept we will >not be setting up an ldm; install solarisx first, then mcidasx. Right. >Thanks Sorry for your problems. At least we undstand most of them now. 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.