19991119: Client Routing Table (cont.)

>From: "Jennie L. Moody" <address@hidden>
>Organization: University of Virginia
>Keywords: 199911182049.NAA16853

Jennie,

>Well, I am glad you are satisfied that things seem okay on windfall.

Let me reiterate that I have not had the chance to read through the
exchanges that you had with Don, so I don't know that I fixed the real
problem that you were having.  Done came in this afternoon and noted
that the remote server on windfall was not reporting that it could find
data in the various data sets that were expected.  He mentioned your
problems with RTGRIDS, so I leapt to the conclusion that the only thing
that was wrong was the ADDE remote server setup.  I figured that this
was probably due to something in .mcenv, so I started there.  When I
saw MCDATA defined to be /home/mcidas/workdata and given that I
remembered that you were going to setup a /home/mcidas/uvaworkdata, I
figured that this must be the problem.  I logged in as 'mccode' and was
able to look at the contents of ~mcidas/.mcenv and see that MCDATA was
wrong, I figured that this was the only problem (i.e. I looked no
further).

>My brain must be made of bricks, because I don't understand why I could
>work with RTGRIDS (and the other use accounts could too, eg., Tony,
>Owen, McUser, etc.) but the server setup wasn't correct.

Was the DATALOC for RTGRIDS in your and other's accounts pointing to
the ADDE remote server, or were they LOCAL-DATA?  I am betting that all
of your accounts are setup to know how to access the data so that using
RTGRIDS as LOCAL-DATA worked.

>I was just on the McIDAS web-docs trying to understand the role of
>mcadde (but again, its unclear).

The real problem here is that you have not had the opportunity to sit
through a McIDAS-X workshop, so you probably don't have a complete
picture of how McIDAS works.

>As for whether you were dreaming we had this all set before you
>left....well, we had the runtime links etc. all set correctly, but I
>needed to get the new ldm-mcidas, and before we switched over we tried
>to make-over all the BATCH files to get rid of any dependence on old
>(non-adde and non-y2k) references.

Yea, but I thought that we actually modified .mcenv.

>I was reluctant to make the switch
>at the same time you and Don left the country thinking it unwise to
>change versions (and implement this new version-control structure) with
>out any support.

Good move.

>Actually, I thought the switch had gone quite
>smoothly, and with the acception of having failed (but only
>momentarily) to have moved the ADDESITE.TXT definitions from the old
>(eg., /home/mcidas/mcidas74/data directory).

OK.  I have to admit, that I had not thought of this, so that is why I
did not mention it to you in previous conversations.  It is now clear
to me that some more thought needs to go into documentating how a site
can cut over from one distribution to the next.  By the way, you are
the only site that is doing this, so you are a pioneer :-(

>However, since Tony has
>been having trouble copying grids, and Don was suggesting that several
>steps might have been missed in re-configuring the ADDE, I have been
>worrying that something is messed up.

I understand, I would have too.  I guess Tony's problems are documented
in the email exchanges you had with Don.  I'll read those tomorrow.

>I have a bunch of questions, but they will have to wait until
>tomorrow.

But you just couldn't wait ---+
                              V

>>From address@hidden  Thu Nov 18 23:50:59 1999

>One last comment, since I just went and looked at the the .mcenv and I
>realized I don't know when this gets used???

.mcenv gets read by the script ~mcidas/bin/mcservsh.  mcservsh is the
routine that is run by inetd when an ADDE connection is made.  Its
purpose is to setup the environment (through MCDATA, MCPATH, etc.) for
the ADDE remote server.  The user 'mcidas' _could_ use this file, but
doesn't have to.  I believe that I mentioned this in passing in one of
our email exchanges or phone conversations.  You could change the
.variables.ksh file that is used by 'mcidas' (or whatever file is read
on login by 'mcidas') to read .mcenv (i.e. '. .mcenv').  That way,
there would be one setup for MCDATA, MCPATH, etc. in the 'mcidas'
account.  Remember, the 'mcadde' account is nothing more than an alias
for the 'mcidas' account WITH THE EXCEPTION that it is _NOT_ a login
account.  This is important for security!

>If I log in as user
>mcidas, my environment gets set in .variables.ksh (which is where it
>has always been getting set),  and it was correctly pointing to
>uvaworkdata as the "working data" directory for user mcidas.

OK, but the environment for 'mcadde' only gets set when
~mcidas/bin/mcservsh reads .mcenv.  Since 'mcadde' is _NOT_ a login
account, and since mcservsh run by inetd does not even attempt to
create a login shell, the .variables.ksh,
.profile, and .kshrc file used by 'mcidas' when it logs in do not come
into play at all.

>If the virtual user mcidas runs things through an exection of the shell
>script batch.k, then I am explicitly setting the mcidas environment in
>the shell, and, again, the MCDATA directory has been set at
>uvaworkdata.

You are right, but the operation of the ADDE remote server is subtly
different that the running of a ROUTE PostProcess BATCH file from the
LDM.

>So I again went to look at what to me is the mystery link, mcadde, its
>defined as a user, but its only presence is as a link under
>/home/mcadde pointing to /users/mcidas....so is mcadde the one who is
>(or was) trying to use the .mcenv??

Exactly correct.

>If so, then isn't it still
>erroneous (did you see that it has definitions for McTABLE_READ and
>McTABLE_WRITE which don't make any sense?
>(/home/mcidas/mcidas/data??).

I didn't even look at McTABLE_READ or McTABLE_WRITE.  If they are
pointing to /home/mcidas/mcidas/data, and if there is a copy of
ADDESITE.TXT in that directory (the directory ~mcidas/mcidas/data does
exist), then that is why the remote server is working without copying
~mcidas/mcidas74/data/ADDESITE.TXT to ~mcidas/mcidas76/data.  By the
way, this may be a very _GOOD_ thing.  By leaving ADDESITE.TXT in
~mcidas/mcidas/data, you no longer have to worry about it when you do
cut over upgrades!

>I am supposed to demonstrate my competence to provide met support for
>the TOPSE campaign in a "dry-run" on December 1st, and lets just say I
>am feeling far less than competent at the moment.

It sounds to me like you have 99.99% of things setup correctly.  What
was missing was the "big picture" overview of how McIDAS works.

>Sorry, what a nightmare for you to come back and imagine its somehow
>just more of the same....

The 360 emails were a bigger headache (I have 95 left to act on tomorrow)!

Tom