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

19991119: Running McIDAS and McIDAS-XCD on OSF/1

>From: Erick Lorenz (address@hidden) <address@hidden>
>Organization: UC Davis
>Keywords: 199910272007.OAA03748 McIDAS XCD


>I am now running the ldm and mcidas-xcd on ATM25, a DEC-Alpha running
>OSF/1 4.0F.

OK, sounds good.

>The ldm seems to be collecting data correctly and the scour programs
>are keeping the disk space reasonable.
>This system is much more stable than the ATM12, the SGI Origin 200 running
>Irix 6.5.  There we kept running into shared memory problems.
>On the Alpha I am having trouble in the following areas:
>1. I can't backspace in the McIDAS command window.  Neither the BS key nor
>   control-H works.  If I make a mistake I have to hit return and hope that
>   the mistake is so bad that it won't parse.

Is the keyboard mapping non-standard for the backspace?  Have you tried
to use xmodmap to set the backspace key?

>2. On the main console I have to start a mcidas login session fresh with-
>   out any other graphics windows (eg netscape) or I run into a "too many
>   colors" problem.

McIDAS and Netscape don't play well together.  Netscape uses as many
colors as it can get, and McIDAS needs a fixed number which can be high.
Running in an 8-bit display can cause problems of the type you are
reporting, but that is something to be lived with due to the slower
performance on 24-bit displays and the non-functioning of the Fkey menu
on most 24-bit displays.

>The above problems are nusances but not crucial because users will not
>normally run mcidas on this machine.


>The following is more serious
>as it is preventing classes from using mcidas to its fullest potential.
>3. Some data that I can plot with the menu I cannot get with MCGUI.
>   For example, if I try to plot surface temperatures I get a dialog box
>   with the message:
>               Error: can't read
>               "ptPltDays (SVCA)": no
>               such variable
>   If I try to plot upper air data I get the same box except that SCVA is
>   replaced with RAOB.  And in either case the "Data plot day" menu
>   is blank.  I can plot these variables with the menu even when the
>   plot window is the MCGUI interface.

This seems to be telling us that the session you are trying to do this from
is not pointing to a copy of SYSKEY.TAB that is being updated by the data
decoders.  The reason that the Fkey menu is working is that I have mostly
ADDEized it, meaning that it no longer depends on reading values from

What you should do is:

o start a McIDAS session with no MCGUI or Fkey menu
o type:


If a copy of SYSKEY.TAB is not found, then that is the problem.  If one
is found, you still need to make sure that it is the one that is being
updated by the XCD and ldm-mcidas decoders.  The MCGUI uses SYSKEY.TAB
values for things like the current DAY and TIME of surface, upper air,
profiler, etc. data.  This information is then used to generate a list
of DAYs for which there are data files available.

>   We have been seeing this error on our Linux workstations as well but there 
>   the menu is not an option because of the color depth problem on those
>   machines.

The menu (i.e. Fkey menu) or the MCGUI?  I routinely run both on my RedHat
5.2 Linux system along with Netscape.  Furthermore, I have had very good
luck running both the Fkey menu and MCGUI on a RedHat 6.0 system that is
running in 24-bit mode.  I know that we talked about this some time ago
and that I recommended you drop back to 8-bit mode since that is what
users on the majority of OSes have to do.  I am wondering, however, if
you have retried 24-bit graphics mode on at least one of the Linux boxes?


Please let me know if the MCGUI problem is something other than not
reading the appropriate version of SYSKEY.TAB.


>From address@hidden  Mon Nov 22 13:52:57 1999


>I did as you suggested.  The result DMAP SYSKEY.TAB was:

>-rw-   240000 Nov 21 16:42 SYSKEY.TAB /home/data/mcidas

>/home/data/mcidas is the directory where all the McIDAS and XCD files
>are being written.

>I assume that the date of the file should be more current if it is
>supposed to be updated with fresh data.  It may be as recent as it
>is because I was reinitializing everything Sunday night in an attempt
>to cover something I may have missed.

>If it is in the right place but it is not being updated what am I missing?

>From address@hidden  Mon Nov 22 15:50:43 1999

re: DEC OSF/1
>Since I sent this message I found a way to cope.  I can use the left
>arrow to move back over the text.  Then BS/DEL key acts as a DEL key
>deleting from the right.  I don't have a way to insert so I just delete 
>the right end of the line and retype.

>I checked out the xmodmap command.  According to xmodmap -pke, key 188
>is a DELETE key and no key is a BACKSPACE key.  I assume by elimination
>that 188 is the key at the upper right of the main keyboard but I 
>haven't found a way to confirm this.


>From address@hidden  Mon Nov 22 17:20:08 1999

re: MCGUI functionality
>After staring hard at the screen I changed the permissions on 

>       /home/data/mcidas/SYSKEY.TAB

>to group write.  Also, I think I remember that XCD uses the redirection
>to locate files in which case it should be able to find SYSKEY.TAB but
>I still get confused when I read the instructions in various config
>files and scripts regarding the function of MCDATA so just in case
>I put a link to /home/data/mcidas/SYSKEY.TAB in ~mcidas/workdata.

>Anyway shortly thereafter the modification date on SYSKEY.TAB started
>changing. I have been able to plot one very sparse surface temperature
>map from MCGUI. Upper air is still giving me errors so I will wait over
>night to see it gets in line.

>By the way if and when the program is able to plot cross sections,
>should I indicate longitude with negative numbers in the US or does McIDAS
>convert?  The reason I ask is that the default values were positive.


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.