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

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

Jim,

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

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

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.

OK.

>------------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 ADD TOPO
>   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 
>anybody!

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,
uwgrid.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 
>/export/home/mcdata?

I recommend:

/export/home/ldm
/export/home/ldm/data
/export/home/ldm/logs
/export/home/mcdata
/export/home/gempak
 ...

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

Yes.

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

Later...

Tom