[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20011217: setup of ldm-mcidas, LDM, XCD, and McIDAS at COFC (cont.)

>From: "James R. Frysinger" <address@hidden>
>Organization: College of Charleston
>>Keywords: 200111061842.fA6Igt112242 LDM binary install


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

>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
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 
mcidas   19574  2.2  0.1 22108 1064 pts/0    S    08:30   0:00  |   \_   
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


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

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


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.