20000302: Unidata-Wisconsin products removed in July of 1999 (cont.)

>From: "Karli Lopez (McIDAS)" <address@hidden>
>Organization: University of Puerto Rico
>Keywords: 200002010754.AAA03412 datastreams ROUTE PP BATCH LDM

Karli,

First, I want to thank you for including the informational header from
pervious email exchanges, especially the Keywords: line.  This sames me
from having to lookup the information in our tracking database.  The
idea here is that the first value after Keywords: is a unique key that
can be used in our online tracking system search.  We try to propogate
this key to all email exchanges in a "conversation" so that when one
goes back, all messages can be easily found.  To demonstrate this, try
using '200002010754.AAA03412' as a key in the glimpse search at:

McIDAS-X HomePage
http://www.unidata.ucar.edu/packages/mcidas/mcx
  Support archives                 (link in left hand side frame)
  
You will see that three messages are listed as of this morning.  After
the indexing run tonight, this email will also show up in the list.

re: $MC_HOME is ~mcidas.
>right.

I thought so, but I wanted to make sure.

re: zero had dataset definitions removed
>right, and this was supposed to be after I made the corrections

re: What is your umask?  It should be 002.
>right, and that was one of the things I checked, both the DMAP and ls -la
>showed that it had the correct permissions (our umask is corectly set):

Very good.

re: ability to edit ADDESITE.TXT directly
>Ok I hadn't thought of that.  I think I have found the problem.  When I type
>the contents of ADDESITE.TXT i noticed that they were correct, which was
>rather weird.

This shows that the DATALOC command worked.

>So I checked MCTABLE.TXT and all  of the old information was there.

Aha!

>Now
>MCTABLE.TXT is supposed to be listed ahead of ADDESITE in the MCTABLE_READ
>variable.

Yes.

>What would you suggest I do with the file? Update it, or remove it?

You could do either.  The concept behind there being both of these for
the user 'mcidas', but only ADDESITE.TXT being the one updatable by
DATALOC commands (MCTABLE_WRITE only points to ~mcidas/data/ADDESITE.TXT)
is the following:

o 'mcidas' is the super user for McIDAS-X users; things that 'mcidas' does
  can affect ALL users of McIDAS-X.  This is evident by each user having
  their MCTABLE_READ setup to first read their own local data location
  tables (~user/mcidas/data/MCTABLE.TXT) and then the site defined one
  (~mcidas/data/ADDESITE.TXT)

o when running as 'mcidas' (should only be done for supervisory duties,
  but I treat McIDAS users as big boys and girls :-), one may want to
  point at other machines for one thing or another without disturbing
  what other users are looking at.  In this case, 'mcidas' would be
  required to edit their own ~mcidas/workdata/MCTABLE.TXT file "by hand".
  I figured that this was appropriate since one should only be running
  as the user 'mcidas' if one knows what is going on

>Apparently there are other definitions not on ADDESITE, however i don't know
if they're necessary at all or even up to date:

The combination of MCTABLE.TXT and ADDESITE.TXT can give one's session a
very full range of data locations.  Entries in MCTABLE.TXT supercede those
in ADDESITE.TXT since MCTABLE.TXT is searched first.

>-----------------------------------
>mcidas@breeze 10% cat MCTABLE.TXT
>ADDE_ROUTE_BLIZZARD=144.92.109.163
>NICKNAME_GV4=BLIZZARD/G7-VIS-4K
>NICKNAME_GI4=BLIZZARD/G7-IR-4K
>ADDE_ROUTE_MYDATA=LOCAL-DATA
>NICKNAME_TI=MYDATA/TEST-IMAGES
>ADDE_ROUTE_PLANET=LOCAL-DATA
>NICKNAME_MV=BLIZZARD/M3-VIS
>NICKNAME_MI=MYDATA/IMAGES
>HOST_CIRRUS.AFIT.AF.MIL=129.92.2.88
>HOST_REDWOOD.ATMOS.ALBANY.EDU=169.226.4.37
>HOST_=207.51.48.20
>HOST_RATMAN.WHOI.EDU=128.128.28.228
>HOST_HAZE.ALDEN.COM=198.114.236.23
>HOST_DRY.ATMOS.WASHINGTON.EDU=128.95.175.1
>HOST_HOMER.GEOL.IASTATE.EDU=129.186.26.172
>ADDE_ROUTE_RTWXTEXT=LOCAL-DATA
>NICKNAME_C-IR=MYDATA/CI
>NICKNAME_VI=IMGDISP
>ADDE_ROUTE_RTNIDS=LOCAL-DATA
>ADDE_ROUTE_RTNOWRAD=LOCAL-DATA
>ADDE_ROUTE_RTGRIDS=LOCAL-DATA
>ADDE_ROUTE_RTPTSRC=LOCAL-DATA
>ADDE_ROUTE_TOPO=LOCAL-DATA
>HOST_ZERO.UNIDATA.UCAR.EDU=128.117.140.56
>ADDE_ROUTE_RTIMAGES=ZERO.UNIDATA.UCAR.EDU
>-----------------------------------

The NICKNAMES are entries for aliases managed by the AKA routine of McIDAS.
They are shortcuts.

PLANET is interesting.  I wonder what it is?  I just pointed at your
machine (still working from home) and did a DSINFO ALL PLANET.  Since
this returned nothing, I guess that it is a dead/empty dataset.

>ADDESITE only has:
>-----------------------------------
>mcidas@breeze 13% cat ~/data/ADDESITE.TXT
>ADDE_ROUTE_RTGRIDS=LOCAL-DATA
>ADDE_ROUTE_RTNIDS=LOCAL-DATA
>ADDE_ROUTE_RTNOWRAD=LOCAL-DATA
>ADDE_ROUTE_RTPTSRC=LOCAL-DATA
>ADDE_ROUTE_RTWXTEXT=LOCAL-DATA
>ADDE_ROUTE_TOPO=LOCAL-DATA
>ADDE_ROUTE_BLIZZARD=128.117.140.56
>ADDE_ROUTE_MYDATA=LOCAL-DATA
>ADDE_ROUTE_RTIMAGES=LOCAL-DATA
>-----------------------------------

This looks reasonable.

>which is the correct information.  I don't know if we use PLANET, and I
>wonder if the HOST references and the nicknames are necessary.

They are not necessary if the machines are not being accessed for any
reason.

re: how ROUTE.SYS entries map to ADDE dataset definitions
>ok I thought it would be something like that.  I just didn't know the proper
>naming.

Given that you have never attended a workshop, you have picked up an
awful lot!

>Wow, I did not know McIDAS was that old!

McIDAS dates back to 1972!  Now, that _is_ old.

>It would very interesting to see how much I'm sure it has evolved.

Some things have not changed much; some things have changed a bunch.
If we and some other sites can get our way, it will change even more
in the future.

re: meaning of cylinders
>Oh ok. I see how the naming goes.  And I didn't know you could save more than 
>ten images.  This may prove to be useful in the future.

Yup.  One can save as many OR few (including none) as one wants.  The only
thing that has to be watched out for is name clashes.

re: datasets that need to be protected
>Yes, that is what I was referring to, as well as NLDN.

You are exactly correct.  If you are accessing your NIDS data through my
NIDS ADDE server, then you can control that.  If you are converting NIDS
products into AREA files, then access to them is through the Wisconsin
ADDE server.  This server does not have the easy capability to limit
access to one dataset (or portion of dataset) and not another.  I have
been lobbing hard for this over the past two years, but...

>Where would I look at/change those IPMASK entries?

If you are accessing your NIDS data throught an ADDE server, then you
will have a configuration file named NIDS.CFG in your ~mcidas/workdata
directory (actually, the file will be there anyway, but it will not
be used if you are converting NIDS data into AREA files).  This simple
ASCII text file is designed to be edited by the local site administrator
(i.e. the local 'mcidas' user).  The entries that are modifiable/meaningful
are:

DIRMASK=    <- where to find the NIDS files
FILEMASK=   <- how the files are named
IPMASK=     <- who can look at the data

I suspect that you are converting NIDS images into AREA files.  You will
probably want to change this as transitioning to use of my ADDE server
access will allow you to:

o cut down on processing on your ingestor
o be able to control access to the data

Right now, there is no specific way to limit access to the NIDS data.  One
can, however, install TCP wrappers around the 500 and 503 ports used by
ADDE and limit access that way.  I wouldn't worry too much about this
right now; see below.

re: ADDE has no discovery
>That's a very good point.

Right.  Someone would have to know what they are looking for AND be running
McIDAS at the same time.  This is a small list of people.

>Thank you for everything!

You are welcome.

>P.S. You guys sure stay up late.

I guess you might call this "flextime" :-).

I answered the last question from home.  If I happen to be awake at odd
hours, I jump on and do some support email.  If I have to logon to a
remote machine, it is usually better to do it in the middle of the
night since the net is much more quiet.

>From address@hidden  Thu Mar  2 08:31:10 2000

>For now I have renames MCTABLE.TXT and copied ADDESITE.TXT onto it, and
>here's what I got:

>------------------------------------------------------------
>
>mcidas@breeze 19% dataloc.k LIST
>
>Group Name                    Server IP Address
>--------------------         ----------------------------------------
>BLIZZARD                     128.117.140.56
>MYDATA                       <LOCAL-DATA>
>RTGRIDS                      <LOCAL-DATA>
>RTIMAGES                     <LOCAL-DATA>
>RTNIDS                       <LOCAL-DATA>
>RTNOWRAD                     <LOCAL-DATA>
>RTPTSRC                      <LOCAL-DATA>
>RTWXTEXT                     <LOCAL-DATA>
>TOPO                         <LOCAL-DATA>
>
><LOCAL-DATA> indicates that data will be accessed from the local data
>directory.
>DATALOC -- done
>mcidas@breeze 20% dsinfo.k IMAGE RTIMAGES
>
>        Dataset Names of Type: IMAGE in Group: RTIMAGES
>
>Name         NumPos   Content
>------------ ------   --------------------------------------
>ANTARCTIC       10    Antarctic IR Composite
>EDFLOATER-I     10    Educational Floater
>EDFLOATER-II    10    Educational Floater II
>GE-IR           10    GOES-East North America IR
>GE-IRTOPO       10    GOES-East IR/TOPO Composite
>GE-VIS          10    GOES-East North America VIS
>GE-VISTOPO      10    GOES-East VIS/TOPO Composite
>GE-WV           10    GOES-East North America H2O
>GEW-IR          10    GOES-East/West IR Composite
>GEW-IRTOPO      10    GOES-East/West IR/TOPO Composite
>GEW-VIS         10    GOES-East/West VIS Composite
>GEW-VISTOPO     10    GOES-East/West VIS/TOPO Composite
>GEW-WV          10    GOES-East/West H2O Composite
>GW-IR           10    GOES-West Western US IR
>GW-IRTOPO       10    GOES-West IR/TOPO Composite
>GW-VIS          10    GOES-West Western US VIS
>GW-VISTOPO      10    GOES-West VIS/TOPO Composite
>GW-WV           10    GOES-West Western US H2O
>MDR             10    Manually Digitized Radar
>MDRTOPO         10    MDR/TOPO Composite
>MOLL-IR         10    Mollweide Composite IR
>MOLL-IRTOPO     10    Mollweide IR/TOPO Composite
>MOLL-WV         10    Mollweide Composite H2O
>RESFLOATER      10    Research Floater
>
>DSINFO -- done
>mcidas@breeze 21% IMGLIST RTIMAGES/GE-VIS.ALL
>mcidas@breeze 22% imglist.k RTIMAGES/GE-VIS.ALL
>Image file directory listing for:RTIMAGES/GE-VIS
> Pos Satellite/         Date       Time      Center   Band(s)
>     sensor                                 Lat  Lon
> --- -------------  ------------  --------  ---- ---- ------------
>   1  G-8 IMG        1 MAR 00061  12:15:00    23   71 1
>   2  G-8 IMG        1 MAR 00061  13:15:00    23   71 1
>   3  G-8 IMG        1 MAR 00061  21:15:00    23   71 1
>   4  G-8 IMG        1 MAR 00061  22:15:00    23   71 1
>   5  G-8 IMG        1 MAR 00061  23:15:00    23   71 1
>   6  G-8 IMG        2 MAR 00062  00:15:00    23   71 1
>   7  G-8 IMG        2 MAR 00062  10:15:00    23   71 1
>   8  G-8 IMG        2 MAR 00062  11:15:00    23   71 1
>   9  G-8 IMG        2 MAR 00062  12:15:00    23   71 1
>  10  G-8 IMG        2 MAR 00062  13:15:00    23   71 1
>imglist.k: done
>mcidas@breeze 23% dmap.k ADDESITE.TXT
>PERM      SIZE LAST CHANGED FILENAME     DIRECTORY
>---- --------- ------------ ------------ ---------
>-rw-       273 Mar 02 03:45 ADDESITE.TXT /unidata/mcidas/data
>273 bytes in 1 files
>mcidas@breeze 24%
>-------------------------------------------------

Looks good.

>should I keep these settings or do I need anything from the old
>MCTABLE.TXT (or how would I find out)?

As you point out in your next message, you don't even need MCTABLE.TXT.

>From address@hidden  Thu Mar  2 09:08:53 2000

>I just figured out that MCTABLE.TXT doesn't need to be there! I've
>removed the new copy and left the old one renamed.  Everything still
>seems to be working fine.

Right, you don't need it at all.  See above for more commentary.

Tom