>From: "James R. Frysinger" <address@hidden> >Organization: College of Charleston >>Keywords: 200111061842.fA6Igt112242 LDM binary install Jim, >McIDAS has been working fine here at home for two days but today I'm >having problems. These occur only when trying to download GINIEAST >products. As near as I can tell, the problem is that this site >(cacimbo.ggy.uga.edu) has been offline for awhile. Seems like I should >be able to just change my LOCDATA.BAT to go to a different site if >there are any alternatives available to us. I seem to recall from last >year that there are alternative sites. There are, indeed, other sites for the most of the datasets handled by the MCGUI, and they are easy to get at. Either click the left mouse button on the 'ADDE Client Routing Config' button on the top buttonbar of the MCGUI (this is the button with the "picture" of two comutes, one on top of another (the button just to the right of the button with the Z on it (the Zoom button)), or click on the 'Configure' dropdown (top of MCGUI) and select 'ADDE Dataset Locations'. Either of these actions will bring up a tabbed window in the middle of the image window. After the widget is fully realized (it goes out and verifies server sites), click on the 'Image' tab to bring that page to the top. Now, go down to the GINIEAST dataset entry and click on the down arrow at the right. This will presnet you with a drop down list of server sites from which you can request GINIEAST data. Choose a site other than cacimbo.ggy.uga.edu, and then click on the 'Update and Exit' button at the bottom of the widget. This widget then simply runs a 'DATALOC ADD GINIEAST hostname' for the 'hostname' you chose. >Assuming there are some alternative sites (I don't know how to find >them, though), See above. >I'm not certain what to do after editing LOCDATA.BAT. You don't have to change LOCDATA.BAT. >It would seem to me that all I have to do is to do > BATCH "LOCDATA.BAT >Is that correct? Yes, typing 'BATCH "LOCDATA.BAT' (or 'BATCH LOCDATA.BAT') will update your ADDE Client routing information with the settings in LOCDATA.BAT. >And I probably need to do it as mcidas (opening with >mcidasx to avoid the configuration problems). No, you do not need to do this from a McIDAS session started with 'mcidasx'. You can change the pointing to ADDE servers on the fly in any McIDAS session. >The bigger problem seems to be that there is no timeout action on data >requests. There is an ADDE timeout (currently set for 120 s), but that >doesn't apply for data requests, I would think. There is an ADDE timeout, and that applies to every ADDE transaction. It may seem to be the case that the timeout does not pertain to the entire ADDE transaction since 2 minutes has gone by. The reason for this is that the timeout is applied to each piece of the transaction, not the whole. A display of an image includes lots of little block trnasfers each of which have a 2 minute timeout. >I can go in and kill >the process (doing ? to get the pids then kill ####) but that kills the >windows, too, apparently. >Is there a work-around I'm missing? Yes, you can kill the process, and yes you can do it without killing your McIDAS session. Here is what do do (and I know that this should be easier and it will be in the futre): While waiting for the display, left click on the keyboard icon on the MCGUI. In the GUI console window, type CTRL-? (this is: hold down the Ctrl key then press 'Shift /'). This brings up a list of processes running as the user your are running your McIDAS session as. What will be listed in the GUI Console window will look something like: !ps fuw USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND mcidas 878 0.0 0.2 2772 1392 pts/0 S Dec10 0:00 -sh mcidas 19577 0.0 0.0 2084 352 pts/0 S 08:30 0:00 uncompress -cf mcidas 19578 0.0 0.0 1516 424 pts/0 S 08:30 0:00 mcserv -R mcidas 10472 0.0 2.5 17676 16696 pts/0 S Dec15 0:00 mcenv -k 10471 -f address@hidden -e 5m -g 16 -i 128 mcgui.k 0x02A00002 16 mcidas 10480 0.0 0.9 27692 5828 pts/0 S Dec15 3:09 mcwish /home/mcidas/bin/mcgui.k 0x02A00002 16 128 +340+0 71x26+630+51 mcidas 10485 0.0 2.4 22596 15844 pts/0 S Dec15 2:50 \_ mcimage -progressID 44040194 -igeometry +346+148 -graphicsColors mcidas 19573 0.0 0.0 17672 584 pts/0 S 08:30 0:00 \_ mcrun IMGDISP GINIWEST/GW4KIR STATION=KDEN PLACE=C MAG=2 2 EU=IMA mcidas 19574 2.2 0.1 22108 1064 pts/0 S 08:30 0:00 | \_ IMGDISP GINIWEST/GW4KIR STATION=KDEN PLACE=C MAG=2 2 EU=IMA mcidas 19575 0.2 0.0 1516 512 pts/0 S 08:30 0:00 \_ cat mcidas 19579 0.0 0.1 2600 732 pts/0 R 08:30 0:00 \_ ps fuw The listing is from the Unix command 'ps'. Since 'ps' output looks different on different OSes, your listing might look a little different. The important things to locate are processes related to the IMGDISP command that is hanging. From my listing, these are the processes 'mcrun', IMGDISP', 'cat', 'uncompress', and 'mcserv -R'. All you need to do is kill the process associated with the IMGDISP. The rest will eventually die by themselves, but you can be complete and kill the 'mcserv -R' and 'uncompress' processes also. In my example, the process ID for IMGDISP is 19547, so I can simply type: kill 19547 <- kills the IMGDISP invocation or kill 19547 19578 19577 <- kills IMGDISP, mcserv and uncompress in my GUI Console window. Notice that you don't have run kill from a Unix window. >Some >things allow me to issue a new command and do something else, but this >GINIEAST one ties up menus and all. By the way, doing a kill sometimes >results in teminal reports of window errors. For example, here's a >terminal window printout after a kill: > address@hidden:~ > kill 10113 > address@hidden:~ > mcimage: X Error: BadWindow (invalid Window >parameter) > mcimage: Request Major code 4 (X_DestroyWindow) > mcimage: ResourceID 0x2e00001 > mcimage: Error Serial #1887 > mcimage: Current Serial #1905 > mcimage: X Error: BadWindow (invalid Window parameter) > mcimage: Request Major code 4 (X_DestroyWindow) > mcimage: ResourceID 0x2e00001 > mcimage: Error Serial #1906 > mcimage: Current Serial #1909 You were probably killing the wrong process. Doing so can/will result in McIDAS exiting as you have seen. 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.