>From: "Steve Ochani" <address@hidden> >Organization: SUNY Nassau >Keywords: 200004122050.OAA15539 McIDAS-X IMGDISP ADDE DSSERVE REDIRECT Steve, >I have (for a while) McIDAS 7.6 / XCD running on a Linux (RH 6.1) >machine running with ldm on and off for a while. OK, thanks for bringing me up to speed on your installation. >The build etc went without a single problem Excellent! >I have setup mcx and xcd and adde etc by following the directions >on the website to the best of my knowledge but when trying to >display data through the fkey menu i get the following error(s). > >IMGDISP: Image data server unable to resolve this dataset: >RTIMAGES/GE-VIS >IMGDISP: done >IMGDISP failed, rc=2 OK, this is telling us that the ADDE subsystem does not know how to interpret the RTIMAGES/GE-VIS dataset. This is caused by the access for the user and/or site not being setup by use of appropriate DSSERVE commands or by an inappropriate DATALOC. >I tried what was suggested in the message > >http://unidata.ucar.edu/glimpse/mcidas/4738 OK, this just about covered everything. >my XCDDATA string is setup in the mcidas accounts .cshrc >and running the commands such as > >DMAP AREA and DMAP MDXX do show the data in the dir >correctly such as.. > >-rw- 607856 Apr 11 07:31 AREA0219 /usr/local/ldm/data/mcidas Good. >and i again ran the default DSSERVE.BAT >but the commands thru the menu produce the same error. Alright, then the dataset definitions should be made. In which account were you doing this? Also, what is the result of: DATALOC LIST run from that same account? >Running the old commands such as df and aloop work fine though. OK, I am glad you mentioned this. This means that the REDIRECTions for the imagery are setup correctly. >Any help/suggestions would be greatly appreciated. The question is how you were setting up the ADDE access to the data files. This can be done in two ways: o for an individual user. In this case, each user's account would have to have REDIRECTions defined so that their McIDAS session can find the needed data files (MDXX, GRID, and AREA). o for all McIDAS users on a system. In this case, all users would "point" to the server machine from their session. Their sessions would not have to know how to find the data files, but the remote server part of McIDAS would have to be setup Here is a mini blow-by-blow of what goes on when setting up ADDE access for a user: o first, hopefully you setup the user account to have MCDATA, MCPATH, MCGUI, MCTABLE_READ, and MCTABLE_WRITE defined as in: Configuring User Accounts http://www.unidata.ucar.edu/packages/mcidas/mcx/config_users.html o next, you would have had to setup REDIRECTions so that McIDAS data (MDXX, GRID, and AREA) files can be found (you have apparently done this) o next, you would have had to define the McIDAS string XCDDATA as the fully qualified directory name where McIDAS data produced by XCD files are being stored (you have apparently done this) o next, as the user 'mcidas', you would have made a copy of DSSERVE.BAT in LSSERVE.BAT and a copy of DATALOC.BAT in LOCDATA.BAT: <login as 'mcidas'> cd data cp DSSERVE.BAT LSSERVE.BAT cp DATALOC.BAT LOCDATA.BAT then, you would edit LOCDATA.BAT and replace 'fully_qualified_host_identifier' with either 'LOCAL-DATA' if the account will be accessing the data individually, or the fully address of the machine running the McIDAS remote ADDE server. It sounds like your setup efforts were aiming towards the former option. o back as the user your are trying to setup ADDE access for (this might be 'mcidas', it might not), you would start a McIDAS session and define the datasets: mcidas BATCH LSSERVE.BAT BATCH LOCDATA.BAT The 'BATCH LSSERVE.BAT' will create a file named RESOLV.SRV in the user's McIDAS-X working directory. This will be the ~user/mcidas/data directory for non-'mcidas' users and ~mcidas/workdata for the user 'mcidas'. This is what the ADDE commands need to be able to read in order to translate an ADDE dataset reference into the actual files needed to be read. By the way, the error you got in trying the IMGDISP RTIMAGES/GE-VIS command seems to be saying that RESOLV.SRV was not created or is not readable. The 'BATCH LOCDATA.BAT' invocation setups where to go look for data when an ADDE reference is made. The cool thing about ADDE is that the data may be local, or it may be on any machine running a remote ADDE server that is accessible over TCP/IP ethernet AND for which you know the server and dataset names. So, you should check to see if the RESOLV.SRV file was created after you ran the DSSERVE comands in LSSERVE.BAT. You should next make sure that the DATALOCation in effect is valid. This means that if you setup datasets for local access (not through a remote ADDE server), then a 'DATALOC LIST' should come back looking like: Group Name Server IP Address -------------------- ---------------------------------------- RTIMAGES <LOCAL-DATA> <LOCAL-DATA> indicates that data will be accessed from the local data directory. DATALOC -- done If you setup the ADDE remote server in the 'mcadde' account, and if it is configured properly, then this dataloc may look like: Group Name Server IP Address -------------------- ---------------------------------------- RTIMAGES WR.PSI.SUNYNASSAU.EDU <LOCAL-DATA> indicates that data will be accessed from the local data directory. DATALOC -- done (or whatever the name of the machine that McIDAS and the McIDAS remote ADDE server are setup on). >Thanks If the above does not help you solve your ADDE setup problem, please send me: o the name of the account you are trying this in o the contents of the RESOLV.SRV file that should exist in the user's McIDAS working directory o the output from a 'DATALOC LIST' command in a McIDAS-X session in the user's account Tom >From address@hidden Tue Apr 18 13:58:22 2000 >Subject: Re: 20000413: ADDE setup questions at SUNY Nassau Thanks! the fkey is working now it seems i had not edited the LOCDATA.BAT my mistake
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.