20010731: setting up McIDAS user accounts (cont.)

>From: "Wayne Bresky" <address@hidden>
>Organization: Cornell
>Keywords: 200107312125.f6VLPs113024 McIDAS DATALOC DSSERVE

Wayne,

>Here is what the output from DATALOC shows for the user mcidas:
>
>[mcidas@cloudcover ~/data]$ dataloc.k
>
>Group Name                    Server IP Address
>--------------------         ----------------------------------------
>BLIZZARD                     ADDE.UCAR.EDU
>CIMSS                        CLOUDCOVER.CIT.CORNELL.EDU
>GINICOMP                     CLOUDCOVER.CIT.CORNELL.EDU
>GINIEAST                     CLOUDCOVER.CIT.CORNELL.EDU
>GINIWEST                     CLOUDCOVER.CIT.CORNELL.EDU
>MYDATA                       <LOCAL-DATA>
>RTGINI                       CLOUDCOVER.CIT.CORNELL.EDU
>RTGRIDS                      CLOUDCOVER.CIT.CORNELL.EDU
>RTIMAGES                     CLOUDCOVER.CIT.CORNELL.EDU
>RTNEXRAD                     CLOUDCOVER.CIT.CORNELL.EDU
>RTNIDS                       CLOUDCOVER.CIT.CORNELL.EDU
>RTNOWRAD                     CLOUDCOVER.CIT.CORNELL.EDU
>RTPTSRC                      CLOUDCOVER.CIT.CORNELL.EDU
>RTWXTEXT                     CLOUDCOVER.CIT.CORNELL.EDU
>TOPO                         CLOUDCOVER.CIT.CORNELL.EDU
>WNEXRAD                      <LOCAL-DATA>
>WNOWRAD                      <LOCAL-DATA>

OK.  Since you most likely do not have the datasets GINICOMP, GINIEAST,
GINIWEST, RTGINI, WNEXRAD, and WNOWRAD, I suggest that you run:

DATALOC DEL GINICOMP
DATALOC DEL GINIEAST
DATALOC DEL GINIWEST
DATALOC DEL RTGINI
DATALOC DEL WNEXRAD
DATALOC DEL WNOWRAD

The real thing to do is to edit LOCDATA.BAT and remove/comment out
the DATALOC commands for the datasets that you do not have.  Saying this,
however, does not give the full picture.  The datasets GINICOMP, GINIEAST,
and GINIWEST can be accessed off a set of servers around the net:

snow.plymouth.edu
cacimbo.ggy.uga.edu
papagayo.unl.edu
startus.al.noaa.gov
adde.ucar.edu

You would do best to choose one or more of these machines as the
DATALOCation for the data and edit LOCDATA to match your selection.
For instance:

DATALOC ADD GINICOMP snow.plymouth.edu
DATALOC ADD GINIEAST cacimbo.ggy.uga.edu
DATALOC ADD GINIWEST papagayo.unl.edu

I would, however, comment out the entries for WNOWRAD and WNEXRAD If you
have not contracted with WSI to receive their products through point-to-point
LDM transfers (this costs significant $).

>When I type in SFCLIST the command works.

OK.  This means that you should be going through the remote ADDE
interface on cloudcover.cit.cornell.edu.  This should indicate that the
'mcadde' user is setup correctly (has the same HOME directory as
'mcidas'; is in the same group as 'mcidas'; and ~mcidas/mcidas/data
exists and is writable by 'mcadde'.  Will you check this just to make
sure?  Thanks.

>Now, while logged in as a user (and after running BATCH LOCDATA.BAT)
>for that user the same ADDE datasets exist:
>
>[wysocki@cloudcover wysocki]$ dataloc.k
>
>Group Name                    Server IP Address
>--------------------         ----------------------------------------
>BLIZZARD                     ADDE.UCAR.EDU
>CIMSS                        CLOUDCOVER.CIT.CORNELL.EDU
>GINICOMP                     CLOUDCOVER.CIT.CORNELL.EDU
>GINIEAST                     CLOUDCOVER.CIT.CORNELL.EDU
>GINIWEST                     CLOUDCOVER.CIT.CORNELL.EDU
>MYDATA                       <LOCAL-DATA>
>RTGINI                       CLOUDCOVER.CIT.CORNELL.EDU
>RTGRIDS                      CLOUDCOVER.CIT.CORNELL.EDU
>RTIMAGES                     CLOUDCOVER.CIT.CORNELL.EDU
>RTNEXRAD                     CLOUDCOVER.CIT.CORNELL.EDU
>RTNIDS                       CLOUDCOVER.CIT.CORNELL.EDU
>RTNOWRAD                     CLOUDCOVER.CIT.CORNELL.EDU
>RTPTSRC                      CLOUDCOVER.CIT.CORNELL.EDU
>RTWXTEXT                     CLOUDCOVER.CIT.CORNELL.EDU
>TOPO                         CLOUDCOVER.CIT.CORNELL.EDU
>WNEXRAD                      <LOCAL-DATA>
>WNOWRAD                      <LOCAL-DATA>
>
>Now, however, when I type in SFCLIST I get
>
>sfclist.k: Point data server unable to resolve this dataset:
>RTPTSRC/SFCHOURLY
>
>Does this mean the ADDE remote server is not set up properly?

I would have said yes except that you have already noted that invoking the
SFCLIST command as the user 'mcidas' works.

>The redirections for this user look like:
>
>[wysocki@cloudcover wysocki]$ redirect.k LIST
>Number of active redirection entries=81
>AREA007* /usr/local/ldm/data/mcidas
>AREA008* /usr/local/ldm/data/mcidas
>AREA009* /usr/local/ldm/data/mcidas
>AREA006* /usr/local/ldm/data/mcidas
>AREA010* /usr/local/ldm/data/mcidas
>AREA011* /usr/local/ldm/data/mcidas
>AREA012* /usr/local/ldm/data/mcidas
>AREA013* /usr/local/ldm/data/mcidas
>AREA014* /usr/local/ldm/data/mcidas
>AREA015* /usr/local/ldm/data/mcidas
>AREA016* /usr/local/ldm/data/mcidas
>AREA017* /usr/local/ldm/data/mcidas
>AREA018* /usr/local/ldm/data/mcidas
>AREA019* /usr/local/ldm/data/mcidas
>AREA020* /usr/local/ldm/data/mcidas
>AREA021* /usr/local/ldm/data/mcidas
>AREA022* /usr/local/ldm/data/mcidas
>AREA023* /usr/local/ldm/data/mcidas
>AREA024* /usr/local/ldm/data/mcidas
>AREA025* /usr/local/ldm/data/mcidas
>AREA026* /usr/local/ldm/data/mcidas
>AREA027* /usr/local/ldm/data/mcidas
>AREA028* /usr/local/ldm/data/mcidas
>AREA029* /usr/local/ldm/data/mcidas
>AREA901* /usr/local/mcidas/data
>MDXX000* /usr/local/ldm/data/xcd
>MDXX001* /usr/local/ldm/data/xcd
>MDXX002* /usr/local/ldm/data/xcd
>MDXX0030 /usr/local/ldm/data/xcd
>MDXX008* /usr/local/ldm/data/mcidas
>MDXX009* /usr/local/ldm/data/mcidas
>MDXX0100 /usr/local/ldm/data/mcidas
>GRID000* /usr/local/ldm/data/mcidas
>GRID010* /usr/local/ldm/data/mcidas
>UNIDATAS /usr/local/ldm/data/mcidas
>ADMIN.MSG /usr/local/ldm/data/mcidas
>PROFILER.CDF /usr/local/ldm/data/mcidas
>LWPATH.NAM .
>SKEDFILE .
>STRTABLE .
>VIRT9300 .
>ROUTE.SYS /usr/local/ldm/data/mcidas
>SYSKEY.TAB /usr/local/ldm/data/mcidas
>AREA8* /usr/local/mcidas/data/tutorial
>GRID8* /usr/local/mcidas/data/tutorial
>MDXX8* /usr/local/mcidas/data/tutorial
>ASUS1* /usr/local/ldm/data/ldm/surface/front
>FSUS2* /usr/local/ldm/data/ldm/surface/front
>MDXX003* /usr/local/ldm/data/xcd
>MDXX004* /usr/local/ldm/data/xcd
>MDXX005* /usr/local/ldm/data/xcd
>MDXX006* /usr/local/ldm/data/xcd
>MDXX0070 /usr/local/ldm/data/xcd
>GRID5* /usr/local/ldm/data/xcd
>GRID6000 /usr/local/ldm/data/xcd
>MDXX007* /usr/local/ldm/data/mcidas
>MDXX0080 /usr/local/ldm/data/mcidas
>AREA03* /usr/local/ldm/data/mcidas
>AREA04* /usr/local/ldm/data/mcidas
>AREA05* /usr/local/ldm/data/mcidas
>AREA06* /usr/local/ldm/data/mcidas
>AREA07* /usr/local/ldm/data/mcidas
>AREA08* /usr/local/ldm/data/mcidas
>AREA09* /usr/local/ldm/data/mcidas
>AREA10* /usr/local/ldm/data/mcidas
>AREA11* /usr/local/ldm/data/mcidas
>*.IDX /usr/local/ldm/data/xcd
>*.IDT /usr/local/ldm/data/xcd
>*.XCD /usr/local/ldm/data/xcd
>IDXALIAS.DAT /usr/local/ldm/data/xcd
>FOUS14.RAP /usr/local/ldm/data/xcd
>FOUS14.RAT /usr/local/ldm/data/xcd
>HRS.SPL /usr/local/ldm/data/xcd
>RAOB.RAP /usr/local/ldm/data/xcd
>RAOB.RAT /usr/local/ldm/data/xcd
>SAOMETAR.RAP /usr/local/ldm/data/xcd
>SAOMETAR.RAT /usr/local/ldm/data/xcd
>SYNOPTIC.RAP /usr/local/ldm/data/xcd
>SYNOPTIC.RAT /usr/local/ldm/data/xcd
>TERMFCST.RAP /usr/local/ldm/data/xcd
>TERMFCST.RAT /usr/local/ldm/data/xcd
>redirect.k: Done

These look OK.

>The redirections seem to be fine.  I can do an MDU LIST for the user
>
>[wysocki@cloudcover wysocki]$ mdu.k LIST 1 10
>  MD#  CREATED SCHM PROJ  NR   NC     ID   DESCRIPTION
> ----- ------- ---- ---- ---- ---- ------- -----------
>     1 2001210 ISFC    0   72 6000 2001211 SAO/METAR data for   30 JUL 2001
>     2 2001211 ISFC    0   72 6000 2001212 SAO/METAR data for   31 JUL 2001
> -- END OF LISTING

OK, the user can see the data files.  This will not have anything to do
with him/her being able to list the contents of those files since the
DATALOC setup says that requests need to go to the remote ADDE server.
It doesn't matter if this server is on the same machine, the DATALOC
is telling the commands to go through the remote interface.

What was the result of doing a:

DSINFO POINT RTPTSRC

as the non-'mcidas' user?  Do you get an error with DSINFO?  If so,
then there still is something wrong with the ADDE remote server setup.

By the way, I guess that cloudcover is behind some kind of security
(firewall, TCP wrappers, etc.) since I can not access the remote server
on it from my home machine.  Does this match with what you are expecting
for cloudcover?  If not, it points to the same problem.

A couple of quick questions that may or may not be relevant to the current
problem:

o what is the value of the Unix environment variable MCCOMPRESS in the
  'mcidas' and user accounts; this controls how the data will be transferred
  to the client

o how long does it take for the SFCLIST command to fail in the user account

o can you send me the contents of the ~mcidas/.mcenv file

If the SFCLIST command takes a long time (like two minutes), then the
command is timing out.  A connection is being attempted with
cloudcover, but is not succeeding.  If it is immediate, I think that
the remote server setup is not quite right.  A quick look at the
contents of .mcenv might shed some light on whether or not the remote
sever is setup correctly or not.  A login is always the last, but
perhaps the quickest, resort.

Tom