20020314: McIDAS-X 7.8 install on DEC/ALPHA running OSF/1 5.1

>From: "Dan A. Dansereau" <address@hidden>
>Organization: USU
>Keywords: 200203141936.g2EJa6a06867 McIDAS DEC OSF/1

Dan,

>   On my install I have noted the following:
>  ( hope some of this will help you also! )
>
>1) compile fails on SFCPLT line 602
>   SFCPLT uses a '' for a null string ??
>   my FORTRAN won't take it
>   so I changed it to a CHAR(0) and restarted ..
>   any problems with this ??

Hmm...  it is strange that I didn't pick this up on our build on OSF/1.
In 7.705 I found other instances of things similar to this which I fixed.
Here is an example of the mods made to adirserv.fp:

 ...

      integer ib, ie                    ! <<<<< UPC add 20000630 >>>>>
      integer nch                       ! <<<<< UPC add 20000630 >>>>>
      integer nchars                    ! <<<<< UPC add 20000630 >>>>>
 ...

c     if(mask_string.ne."")  then           ! <<<<< UPC remove 20000620 >>>>>
      nch = nchars( mask_string, ib, ie )   ! <<<<< UPC add 20000630 >>>>>
      if( nch .gt. 0 )  then                ! <<<<< UPC mod 20000630 >>>>>

The difference in the sfcplot.pgm routine is that SSEC was trying to make
a string that had a length of 0.  I suppose that setting 'type' to
a CHAR(0) might be the thing to do, but I will have to test out how this
is handled on other OSes.

I just rebuilt my 7.8 distribution on our DEC OSF/1:

%uname -a
OSF1 dana.unidata.ucar.edu V5.1 732 alpha

%f77 -version
        Compaq Fortran V5.4-1283
        Compaq Fortran Compiler V5.4-1283-46ABA

I got no error when building sfcplot.pgm (or any other routines for
that matter).

Can you send me the output from 'uname -a' and 'f77 -version' on your
machine?

>2) under the installation guide you uses mcidas to start
>   the mcidas program - I had to uses mcidasx or I get a
>   invocation error
>Is this ok ?? or a problem???

I am worried about the invocation error.  The change made was to replace
a Bourne shell script with a Tcl/Tk startup routine.  This routine,
mcstart.gui should get linked to the name 'mcidas' in the installation
step.   You should check this by doing the following:

cd mcidas7.8/src
ls -alt mcidas mcstart.gui

If these are not the same (through a hard link), then you should remove
'mcidas' and make the link by hand:

rm mcidas
ln mcstart.gui mcidas

Next, you should make sure that the 'mcidas' link gets linked to
~/bin/mcidas:

ls -alt mcidas ~/bin/mcidas

If these are not the same (link from ~/bin/mcidas to ~/mcidas7.8/src/mcidas),
then you should make it.

Now, what mcstart.gui will do is see if you have a .mcidasrc file in
your HOME directory.  If not, it will pop open the GUI and allow you to
setup things like number of frames; frame size; number of image colors;
etc.  It will also allow you to specify that you want to start the
MCGUI automatically.  If .mcidasrc doesn't exist, it will create on in
your HOME directory.  It should then bring up McIDAS in the way you
selected when making choices.

What exactly was the invocation error you are getting when you try to
run 'mcidas' (if you still get it after looking at the links described
above)?

>3) the DF example for testing the software in the installation
>   guide don't work - all the other tests do - 
>has DF gone away??

No, but there may be something wrong with your build on OSF/1.

>4) under the Registering MD file SCHEMA section
>   are all the SCHEMA's already registered - the
>   documentation is not clear - but they seem to
>   be registered.

OK, I will take this as an action item to address.  The section is
in the online docs in case a site wants to update a copy of SCHEMA
that they have customized by adding locally developed schema.  This
is an area that the average Unidata user does not get into.

>5) under the XCD-CONFIG section the documentation says
>   the MDRDEC should be active ( by default ) but it is
>   not - so I activated it.
>is the a documentation error - or should it not be activated??

I should change the docs.  MDRDEC can be active, but it is really
not needed/desired given that:

o the MDR grids and images produced from them sucks
o we have alternatives to the MDR products -- more on this at a later date

>6)  several places you use 7.7 in your examples - I assume that
>    it should be 7.8

This depends on where 7.7 was mentioned.  Some documents talk about
upgrading, and then upgrading from 7.7 to 7.8 is appropriate.  There
may be other places where 7.7 is incorrectly used.  I will do a quick
check...

OK, I'm back.  There were a number of instances where 7.7 was used
instead of the correct 7.8.  I have _hopefully_ correctly changed all
of these to use 7.8.

>7)  some of the previous page links in the documentation don't take
>    you back to the previous page - but to another page
>    (like xcd-installation one)

I found one link like this (in the xcd_troubleshoot.html page).  Can
you send me the other links that do this?  Thanks...

>8)  some pages bring up more than on unidata header making the usable
>    part very small

I thought I had fixed this.  Can you let me know which pages are still
acting badly?

>9) the reference to README.PP in the installation guide is broke, and
>   it is missing in the 7.8 distribution

OK, this is restored.

>10) the NMCAMT is broke - gives a floating point exception, and a core dump
>    on my systems.

This must be a DEC problem.  It will have to be investigated.  I just
ran NMCAMT on my OSF/1 5.1 machine, and I got a floating point error
also.  I should be ablet to trace this one down here.

>11) on that same note - I'm attempting to grab the GRIB/BUFR grids - however
>    went thru the steps on the xcd-config, activated the grids etc. but
>    I can't find any grids - the statdisp seems to be counting GRIB data
>    ( the numbers change, and the text changes red and back to white)
>    but I can't find the grids on my system. )

The GRID decoding was working on OSF/1, so this is a new one.  Since we
are not running an LDM on our DEC, I am not able to test a number of the
XCD routines here on live, just ingested data.  Any chance I can get
a logon to your box?

>I think that two very useful additions to your documentations would
>be:
>
>1)a separate section on when (in the build process) and where to put the
>  ROUTE.SYS, SYSKEY.TAB, SCHEMA files; which programs
>  changes them and when they should be re-copied/moved.

OK, good suggestion.

>  can the duplicate files, in mcidas / mcidas-ldm / ldm be eliminated?

If your decoding is spread over several directories, and if you want
the routing and system key table to be updated, then there should
be links in each directory with decoded files to one primary copy.

>  can a links ??? be used, and automated in the distribution/installation?

Links should be used since the object is to update only one copy of
the files.  As for being automated in the distribution, I don't think
so.  The reason for this is that sites don't necessarily follow
guidelines as to where to put decode data.  So, I have no idea where
the links should be made.  My advice is, however, to decode all McIDAS
data into a single directory.  This way, only one copy of ROUTE.SYS,
SYSKEY.TAB, and SCHEMA need to be copied/updated.

>2)a section on what are the current (I know this changes frequently)
>  mcidas useful default datasets, along with a generic, simple pqact.conf
>  file. Keeping all the obsolete/discontinued decoders comments, and optional
>  stuff seems to confuse many of us ( I speak from experience, the email
>  archives seem to indicate that this is problem )

OK.  We are now well past the point where I should have to worry about
keeping users running old code in mind.  I will begin the clean sweep
of the outdated comments.

Tom