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

19991001: McIDAS-X at STC (cont.)



>From: alan anderson <address@hidden>
>Organization: St. Cloud State
>Keywords: 199909201508.JAA14368 McIDAS-X setup on client machine

Alan,

>I should have provided a bit more information, so will do so now.
>
>Regarding the 2nd machine, where the MCGUI command failed;
>I have used the mount command on it to mount the /var/data/mcidas files
>on waldo and gave them the same file system name on the client.

OK.

>The redirect list gave the result that everything was to be found in
>/var/data/mcidas so left that alone.

OK.  The next step is to see if you can actually see the files referenced
in the REDIRECTions:

DMAP SYSKEY.TAB

If this fails, then you know you have some sort of a problem.  If it
succeeds, the error you reported before _must_ be coming from somewhere
else.

>This 2nd machine now works fine;  MCGUI starts ok and images and suface
>data plot ok using the GUI, so I think it is set.

Good.

>Regarding this machine (and our others, except waldo) I believed that I 
>would no longer be using an nfs mount, but that with ADDE, the datasets
>were specifically identified as being located on another host machine
>(fully qualified host name to be entered).  If I understand you correctly,
>this would be the case, once everything is converted to ADDE?

Exactly.  Once everything has been converted to use ADDE, you will no
longer have to mount the file system on waldo.  The problem is that
everything is not yet ADDEized.

>Now, back to the first machine;  again, MCGUI ran ok here, right from the
>start (no error msg), although it would not put up data.  A call for an image
>using MCGUI came up blank, with message "no data available".  I suspect
>that if 
>I do the nfs mount command here, it will also work as with machine
>described above.

I suspect so as well.  MCGUI probably started because another copy
of SYSKEY.TAB was found either by virtue of a defined file REDIRECTion
or if, none was defined, by virtue of MCPATH.

>I was able to look at some text data with this machine, using WXTLIST.
>I am guessing that this is an ADDE ized command, and it found waldo in the
>dataloc table.

Exactly correct.

>Am I right that there is not GUI entry for text data, i.e.
>we must use command line entries using WXTLIST to see the various product?

No, the textual output of surface and upper air data is partially ADDEized
in the GUI.  What I mean by this is that the commands that are run to
do data lists are ADDE commands.  The gui widget that is popped up uses
information from SYSKEY.TAB to figure out what currently received data
is on the machine.  Without access to a copy of SYSKEY.TAB that is updated
by XCD decoders, the list of available days/times will be blank and the
command in the GUI will fail.  If you can point to a currently updated
copy of SYSKEY.TAB, it should work fine.

>Dataloc list for this machine gives the following:
>       BLIZZARD        UNIDATA'S IP
>       MYDATA          LOCAL-DATA
>       PLANET          LOCAL-DATA
>       RT..            waldo.stcloudstate.edu
>       remaining entries are same as for RT..

OK.

>Should I change MYDATA and PLANET to also look to waldo, i.e. all requests 
>are directed to waldo?

No.  MYDATA is for local datasets.  PLANET is unknown to me.

>I think my primary issue is how to let our non-ingesting machines access the
>data files stored on waldo.  It seems the current version (7.6) uses nfs when
>using the GUI and a direct call to waldo when using ADDE commands.

My Fkey menu is mostly ADDEized.  My GUI is partially ADDEized.  The SSEC
GUI (GUI instead of MCGUI) is ADDEized, but I don't really like it much.

>I may have my client mapping table entries wrong.  
>
>I must say that the setup, build and other instructions on the web are done 
>quite well.  Congratulations and thank you.

Sorry for the problems, however.

>One other issue,  can (should?) I be maintaining some of the data (say all
>image files) on the disk of a machine other than the ingester, just to
>spread the data file load?

Not unless you are running out of disk on waldo.

>Not sure this would be done, in terms of splitting where the
>data is stored (ldm on waldo just sends it to different places?

It could be done a couple of different ways, but I don't think you need
to do it, at least not just yet.

>As I say, this is a separate issue, can deal with it later.

OK.

>Regards to all

I'm off to Madison, WI on Sunday.  I will return on Thursday.  Talk to you
later...

Tom