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

20030311: mcidas at stc (cont.)

>From: "Anderson, Alan C. " <address@hidden>
>Organization: St. Cloud State
>Keywords: 200303111741.h2BHfFB2012143 McIDAS-X v2002 setup

Hi Alan,

Sorry I couldn't answer before now, but I was out yesterday and in a
meeting earlier today.

>The week here is starting out fine as I followed up on your last
>message.

OK.

>I have done testing and then install of  MCIDAS 2002 on waldo.  You had
>already done the build.  everything seemed to go ok.  Also did the
>uninstall.mcxall for the version we had been using,  7.7.  and removed
>the other 7.7 files.

Sounds good.

>A few questions; 
>
>From your earlier messages,  I had the feeling that you had already
>upgraded the ADDE server on waldo, so I did not do the uninstall of 7.7
>or the install of 2002 using sh /mcinet2002.sh install mcadde.
>Do you recall if you did this on waldo or not ?

I did run the remote ADDE server installation script, yes.  You do
not have to redo that step.

>The line mcserv 500/tcp  #McIDAS ADDE port line is listed in my
>/etc/services file.

Additionally, a mcserv 503/tcp line should be there.

>Some othe questions/comments
>
>mcidas 2002 starts ok on waldo.
>I note that the text/command window no longer starts automatically,

In which mode:

o regular McIDAS image window and text and command window
o regular McIDAS image window and text and command window and Fkey menu
o MCGUI GUI interface

>but can be created using the keyboard icon
>or the misc. icon.

Which windows are automatically started depends on how you configure
McIDAS to start.  To set the way you want it to start, exit your
running McIDAS session and then restart using:

mcidas config

The GUI interface that will popup allows you to select from the three
different start mods I listed above;  I recommend using the MCGUI.
Make sure that you select save the settings option at the bottom
(a radiobutton selection) so that the next time you start McIDAS
by simply typing 'mcidas', the same kind of session will be started.

>Is there a best way to close or exit MCIDAS ?

If you are running in either of the first two options above, then
simply type EXIT in the McIDAS Text and Command window.  If you
are running in the MCGUI, go to the File dropdown and select
the 'Exit McIDAS' action.

>Click the upper left corner of the product screen  or  type EXIT in a
>command window ?

The best way is to EXIT, not kill the window (i.e., don't simply kill
the window by double clicking the left corner of the McIDAS window).

>Also,  in looking at the listings from choosing Configure ADDE Dataset
>Locations, using the pull down menus,  I  got listings that are
>different from those that show in my  present  LSSERVE.BAT file.

These are two different things.  Settings in LSSERVE.BAT define datasets
on your local machine (defining a dataset is the process of telling
McIDAS which files compose a dataset).  The 'Configure' 'ADDE Dataset
Locations' action lets you point at your machine or others for particular
datasets.  This may seem like they should/have to be the same, but
it isn't.  For instance, McIDAS allows you to change your session to
go get data from remote servers that are not under your control.
You would do this if you don't have the particular datasets, or if
your data feed went down and you don't have any decoded data to look
at.

>I did not re copy  EXAMPLE.NAM  to  LOCAL.NAM,    and   DSSERVE.BAT to
>LSSERVE.BAT   as  when I checked,  LOCAL.NAM  and DSSERVE.BAT  were
>already there  in ~mcidas/data.   I assume they are left from the
>previous version.

Yes, they are there from the previous version.  At some time, you
should compare the v2002 version of EXAMPLE.NAM and DSSERVE.BAT
against your LOCAL.NAM and LSSERVE.BAT files to see if there are
new entries that you should be aware of.  In the case of upgrading
from v7.7x to v2002, there _are_ new entries that you should be
aware of.

>Are the new ADDE sites that show  when I look at the CONFIGURE ADDE
>listings while running MCIDAS the preferred ones ?

There are a set of cooperating community servers that provide a list
of datasets that all Unidata users are permitted to access.  Some
of these datasets you already have locally:  RTPTSRC, RTIMAGES,
CIMSS, RTWXTEXT.  Some are datasets that you don't have locally: 
AMRC, GINICOMP, GINIEAST, GINIWEST, ME7, RTNEXRAD, RTGRIDS.
I am uncertain at this point if you have the NEXRCOMP dataset
products on waldo.

>I suspect that
>these are just examples of sites that have agreed to serve these
>products to the community.

Yes.

>Will waldo  find the products listed
>there, or do I have to re-run DSSERVE.BAT ?

You configure your McIDAS session to tell it where to go when accessing
data from a particular dataset.  If you have some datasets locally
that are the same as ones offered through any of the community
servers, I recommend that you use your own as the access should
be faster.  For those datasets that you don't have, I would choose
one of the cooperating servers that serves you well.  The AMRC
and ME7 datasets are only served by one server each, so you don't have
any option there.

To change to point at your own server for a dataset that you do have,
do the following:

Open up the 'ADDE Dataset Locations' GUI either by selecting it from
the 'Configure' dropdown, or by clicking on the MCGUI button that has
the icon that represents two computers that are intereconnected (this
is the button just to the right of the one with the big red Z).  From
the GUI that pops up, either select a different server from the drop
down list that is provided, or click in the entry to the right of the
button(s) with the down arrow; erase the entry by backspacing hit the
ESC key; and type in the fully qualified name of the server that you
want to access.  For datasets on waldo, this would be
waldo.stcloudstate.edu.

>I am also building  ver.2002 on another terminal, the machine that will
>likely replace waldo.  So far it is going ok.   I  also plan to build
>another LDM on that machine, will do that after McIDAS is running on
>it.

OK, I got the second note, and I will answer it in a separate response.

Tom