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

20011120: McIDAS vis-a-via Solaris 7/8 (cont.)

>From: "James R. Frysinger" <address@hidden>
>Organization: College of Charleston
>Keywords: 200111061842.fA6Igt112242 McIDAS platfomrs


re: 7 minute speed record for McIDAS build

>       Shezam! That's not long enough to walk down the hall for another cup 
>of coffee and to get rid of the last one!

Yup, the machine is a smoker all right.

>I told my colleague (Jim 
>Neff), who has been one of my two local unix mentors about Plymouth's 
>time. He cried.

PCs are getting so fast now adays.  I was off at my local CompUSA
last night playing with a new Sony VAIO 1.8 Ghz machine.  It is _real_
nice: 512 MB RAM; 80 GB hdd; Nvidia 64 graphics; DVD R/W (!); CD R/W;
10/100 Ethernet; etc.  All for $1799.  This is a sweat machine to say
the least.  On top of that, Sony has a spectacular 18" LCD flat screen
display that is to die for.

re: VENDOR for Linux and FreeBSD is gcc/f2c

>       I kind of suspected that was the case. For a Buckeye, I show a lot of 
>Missourian traits, though. Must be why I'm a scientist.

SSEC also includes Solaris x86 in the list of machines where VENDOR
means gcc/f2c, but I change that since a number of my Solaris x86 sites
have Sun compilers.

re: What does 'top' show for memory use

>       Doing top results in 0K (as in zero K, not as in alright) for both my 
>linux (at home) and the SunUltra10 (at CofC).

This is not good, although the shared memory is loaded on demand on

>Yep, we did the Solaris 
>shared memory bit some time ago in preparation for installing mcidas, 

Did you reboot your Solaris box after making the shared memory mod?

re: only run as the user 'mcidas' for supervisory tasks

>       Understood. I included that to show that the next line was as expected 
>from starting mcidasx.


>------------old stuff-------------
>       Went back and tested installation on weather.cofc.edu via ssh using 
>mcidasx OK. Went through the "Configuring the mcidas Account" 
>instructions again. Still getting the same error on the last BATCH 
>"LOCDATA.BAT. Lots of stuff happens then, as before,
>   DATALOC: Could not resolve TOPO. Entry not filed
>[But in previous step, lots of TOPO stuff seemed to be getting added.]
>   DATALOC failed, RC=2
>   etc.
>       Where do we go from here, Tom?

Could I get a logon as 'mcidas' on this box so I can snoop around?

>re ports:
>       Our department liason left me a phone message this morning saying that 
>he would bring it up in a meeting, also this morning. Haven't heard 
>anything since.

No hurry.

>re doubling:
>       Any relief yet? One of my messages per day ought to be enough for 

Nope, still getting two of each message.

>------------new stuff------------
>       I started getting ready for LDM. Coupla questions. I downloaded both 
>the LDM and the LDM-MCIDAS tarballs. As I recall from last year, the 
>sequence will be to install LDM and then LDM-MCIDAS. Right?

The order doesn't matter.  The key is to copy the ldm-mcidas decoders
that you will be using (typically proftomd, nldn2md, pnga2area and
batch.k) to a directory in 'ldm's PATH.  I recommend use of
~ldm/decoders or ~ldm/util.  A couple of McIDAS shell scripts will need
to be copied to this directory as well (xcd_run, mcscour.sh,

>       Going through the LDM directions, I changed all the /var/data 
>references to /export/home/mcdata as we discussed before. You said that 
>there was no longer a need for an ldm directory under ---/mcdata so I 
>didn't put one in there.

The typical setup for the LDM is:

o HOME in /usr/local
o /usr/local/ldm/data is a link to a location where you have lots of
  disk.  This could be /export/home/ldm/data in your case (new directory)
o /usr/local/logs is a link to a location where you have lots of
  disk also.  This could be /export/home/ldm/logs

Creating the directories above separate from the McIDAS data (mcdata)
directory is not mandatory, but it is advisable.

>But now I'm reading the words in there about 
>the data having to go into an area that does not get backed. Is this 
>going to be a problem?

The idea is that you agr going to be ingesting, decoding, and filing
lots of data.  If you put that data in a directory/on a file system
that gets routine backup (every night; once a week), your backup
proceedure will be _heavily_ used (read lots of tapes and human
intervention to change those tapes).  Since data can be gotten from
remote machines from archives, why "archive" (backup) the data yourself.
Now, a number of sites what their own archive.  If you fall into this
category, then disregard the comments above.

>Should I proceed to put the ldm data in 

I recommend:


>If I do, should we exclude that directory from the 
>backup list?

It would be a good idea, but remember that you are going to be dealing
with LOTS of data (GBs/day).

>Since we don't have an AIX OS, we don't have to worry 
>about the data getting scrambled every Sunday morning,

???  Our AIX sites don't complain about this...

>I reckon. If I 
>do proceed as we discussed earlier, then of course the symbolic links 
>in ~ldm/data and ~ldm/logs would change accordingly.


>       I smell a turkey coming....

Me too.  Yumm...

>We have no classes Wednesday, so I may 
>work on this a lot more then.

I will be working on Wednesday, so let me know if you run into anything.

>After that I plan to take a couple of 
>days off and slay the fatted Butterball. Might even grade some papers. 

Butterball yes, papers no ;-)

>I hope that you get some time off too. If I go ahead and send you 
>messages in the meantime, just leave 'em in the hopper till you're 
>ready. Otherwise, have a safe and happy holiday.

Got a Tday party planned.  Should be great!



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.