19990818: McIDAS 7.6 ...sort of works (cont.)

>From: address@hidden
>Organization: SMSU
>Keywords: 199908122231.QAA22964 McIDAS-X,-XCD 7.60

Bill,

re: remember to:
>  Remembering problems from last install with re-setting variables,
>  I took a look at this release's xcd_run and saw that the only
>  changes were to 'exec' ingetext and ingebin, so I simply added
>  the 'exec' command to the appropriate lines in my old xcd_run,
>  which has always been on /home/ldm/decoders/bin.

Sounds good.  There were no major changes as you noticed.  I changed
the running of ingexxx.k to execing of the same to save process IDs
(never really a big deal, but now you shouldn't see 'xcd_run' in
the process ID list).

>  This morning I looked at xcd....noted that it says it wants to be
>  in the same directory as xcd_run...don't remember that from the
>  installation instructions...not gonna wade though the links to check.
>  Noted that in /home/ldm/decoders/bin I have the old xcd from 7.4.

'xcd' was never really an important routine.  I added it so that one could
stop the running of XCD routines on the fly.  In practice I and most XCD
users never use it.

re: xcd_run environment variables
>    Was working...as above

OK, I should have remembered that you were already running XCD.

re: add the XCD startup line in ~ldm/etc/ldmd.conf:
>    was there already.

I understand that now.

re: was the 7.6 XCD built/installed
>   now here you have me.  I followed along in the web pages on the
>   installation of xcd....vaguely remember I may have had to go back
>   and do some kind of repeat make install.xcd or something, but 
>   frankly I do not remember.  I did all the configuring discussed
>   in the web pages.

You could examine ~mcidas/mcidas7.6/src/makelog to see if the 7.60
XCD modules were built.  These would be at the very end of makelog
IF/WHEN the build of -X went with no hitches.  Your makelog file would
have the several attempts at building mcimage at the end.

>   In /home/mcidas/bin I have :
>
>cirrus:/home/mcidas/bin> ls -l xcd*
>-rwxr-x---   2 mcidas   unidata     3083 Jun 07 13:15 xcd*
>-rwxr-x---   2 mcidas   unidata     6591 Jun 07 13:15 xcd_run*
>-rwxr-x---   2 mcidas   unidata   117859 Aug 14 16:35 xcdrelay*
>-rwxr-x---   2 mcidas   unidata      747 Jun 07 13:00 xcdrelaysh*
>
>  Does their presence indicate an installation of xcd?

No, but the presence of newly built routines like: startxcd.k, ingebin.k,
and ingetext.k (there are more as well) would.

>  If not, how would I know?

Entries in makelog and the existence of newly built XCD routines.  A complete
list of XCD routines is presented in:

Chapter 3 - McIDAS-XCD Administrative Commands 
http://www.unidata.ucar.edu/packages/mcidas/mcx/xcd_admincmd.html

re: STRTABLE: where it should be
>Thank you.   I'll get to the stuff below in a second, but let me tell you
>why this concerns me....Seems to me the first time I ran mcidas 7.6, 
>it initialized fine...now since messing up (something...the stringtable?,
>MCPATH?),
>it (once again, as always in my last 7.4 install) initiates itself with
>'Cannot locate string names - rerun setup'...

>Ack, Thpfft!

Hey, Bloom County!  Bill the cat lives!!

>More below.

re: REDIRECTions
>When I first started mcidas7.6 in order to carry out the configuration
>section of the install instructions (i.e., redirections, xcd, etc),
>I checked the redirections, since I remember last time I did this I 
>blindly followed the instructions and ran EXAMPLE.NAM (or whatever you
>copy it too), which of course walked all over my local, pre-existing
>redirections....so this time I checked first, and my local redirections
>were still extant.

OK.

>So, what to do?

Leave them alone as long as you did not somehow delete/munge the
file LWPATH.NAM in the ~mcidas/workdata diretory.

>I first saved them, then did
>a REDIRECT MAKE, since that was the second part of the exercise.

A REDIRECT MAKE forces a read of the REDIRECTions from LWPATH.NAM
putting the REDIRECTions in memory.

>To answer your question more directly, there is no redirection for
>STRTABLE.

OK.  EXAMPLE.NAM does contain a REDIRECTion for STRTABLE:

"
" Files used by the Unidata Function Key Menu system that should be
" located in each user's mcidas/data directory
"
STRTABLE     .
VIRT9300     .

You will notice that the REDIRECTion is "." (current working directory).
In Unidata McIDAS, the user is forced to their $MCDATA directory at
the initiation of a session.  All scripts that run McIDAS routines
(e.g. xcd_run, batch.k, mcscour.sh, etc.) will have the user define
MCDATA to match their system setup and there will be a 'cd $MCDATA'
near the beginning of the script.

re: what does STRTABLE contain
>TL lists only H and Y as strings....some of my batch files which run
>set all sorts of strings, and they ususally show up, but their not
>showing up.

The next quick test would be to find out what STRTABLE file your
session was using:

DMAP STRTABLE

This will show you whether or not you are using one in the working
directory (~mcidas/workdata for the user 'mcidas'; ~user/mcidas/data
for ALL other users).

>I fear I have done something incredibly simple and stupid, like forgetting
>to open your eyes if you want to see.  Oh well.

I am betting that there is just one little piece of something askew.

re: Did you install the ADDE remote server?
>I did a bunch of stuff on the ADDE...changing inetd.conf, running some
>stuff in mcidas that put in some image data sets...everything seemed
>to run fine, I guess

One installs the ADDE remote server as 'root' by running the
~mcidas/mcinet7.6.sh script:

su -
csh                   (not necessary, but this makes the ~mcidas understood)
cd ~mcidas
sh mcinet7.6.sh uninstall mcadde
<wait>
sh mcinet7.6.sh install mcadde
<wait>

The script does the work of adding things to /etc/services and /etc/inetd.conf
and sending a HUP to inetd.  Sites using NIS+ have a more difficult time
setting up the remote server.

>....couldn't seem to find IR and VIS GOES stuff,

What couldn't seem to find the IR and VIS GOES stuff?  Setting up the
server is one step in getting things to rowk.  The other step, done
as the user 'mcidas' is to define datasets that should be available
on your machine.  This is done by:

<login as mcidas>
cd data
cp DSSERVE.BAT LSSERVE.BAT
<edit LSSERVE.BAT IF needed (standard setups need no change)>
<start a McIDAS-X session>
define XCDDATA in the McIDAS string table:

TE XCDDATA "directory_where_xcd_will_create_its_output_files

BATCH LSSERVE.BAT

This will assocate ADDE dataset names with the data files that compose
them (i.e. RTIMAGES will be composed of images in AREA file format;
there will be descriptors like GE-IR, GW-IR, GE-VIS, etc.)

The next thing that has to be in place for the access to work is the
REDIRECTions that allow the 'mcidas' environment to find data files.
This is the purpose of the REDIRECTions in EXAMPLE.NAM.  To reiterate,
the recommendation for using EXAMPLE.NAM is:

<login as mcidas>
cd data
cp EXAMPLE.NAM LOCAL.NAM
<edit LOCAL.NAM and change the directories to match your setup>
<start a McIDAS-X session>
restore the REDIRECTions from LOCAL.NAM:

REDIRECT REST LOCAL.NAM

LOCAL.NAM will be found by virtue of the definition of your MCPATH
(here I assume that the home directory for 'mcidas' is /home/mcidas):

MCPATH=/home/mcidas/workdata:/home/mcidas/data:/home/mcidas/help

>but not really understanding deeply enough what is going on with ADDE,

ADDE is way cool!

>I just punched the buttons the way (I thought) the instructions said,
>and let it go at that.

OK.  Here is the very cool thing about ADDE in a nutshell.  Suppose
that for some reason you don't have any data before a class, etc.
You are now part of a nationwide network of folks running current
versions of McIDAS-X.  Almost all of these sites is running the McIDAS-X
ADDE remote server, so you have access to their data holdings transparently.

Try the following for grins:

<login as mcidas>
<start a McIDAS-X session>
"point" to the ADDE remote server here at Unidata for realtime imagery
data:

DATALOC ADD RTIMAGES ADDE.UNIDATA.UCAR.EDU

Now, load the most recent GOES-East IR image centered on Columbia, MO
in frame 1 blown up by a factor of 2 and draw a map on it that shows
the counties for Missouri and the state outlines elsewhere:

IMGDISP RTIMAGES/GE-IR 1 STA=KCOU MAG=2 SF=YES REFRESH='EG (GRA);MAP SAT 5 
COUNTY=ALL ST=MO;MAP H 1 WID=2'

If this is not cool, then I don't know what is!

>From address@hidden  Wed Aug 18 12:50:20 1999

>I think I've found a major problem in my install...here's
>output from XCD_START.LOGStarting HRS at 99229.194746
>/home/ldm/decoders/bin/xcd_run[129]: ingebin.k:  not found.
>xcd_run exiting from HRS action at 99229.194746

Oops, bad news.

>Starting HRS at 99229.194844
>/home/ldm/decoders/bin/xcd_run[129]: ingebin.k:  not found.
>Starting DDS at 99229.194844
>/home/ldm/decoders/bin/xcd_run[125]: ingetext.k:  not found.
>xcd_run exiting from HRS action at 99229.194844
>xcd_run exiting from DDS action at 99229.194844
>Starting DDS at 99229.194904
>Starting HRS at 99229.194904
>/home/ldm/decoders/bin/xcd_run[125]: ingetext.k:  not found.
>xcd_run exiting from DDS action at 99229.194904

Ditto.

>ingebin.k and ingetext.k are in the /home/mcidas/bin
>directory....

Are they set to be executable by the user running the LDM?  Are
they non-zero length?

>I can remember working fairly carefully with you to get the
>PATH and MCPATH correct for the ldm user kicking off the
>programs through xcd_run.  The only change here is that
>the programs are exec'd rather than initiated directly.

This should cause no change whatsoever.  Again the reason for the exec
was to get rid of those extra processes for xcd_run.  An exec causes
the overlay of the execed routine over the current one.  This way you
end up with one process in the PID list instead of two.

>Does exec not follow the PATH to find the executables?

Yes, it does.

>It is clearly looking in the /home/ldm/decoders directory.

Hmm...  The PATH statement at the top of xcd_run should have the 'mcidas'
bin directory before any LDM directories.  Something like:

PATH=/home/mcidas/bin:...

or

PATH=${MCGUI}:/home/mcidas/bin

>While I wait, I'll put a copy of the programs in
>with xcd_run and see what happens.

If the programs are not runnable from the ~mcidas/bin directory it must
mean that their file permissions are not set so that the user running
the LDM can execute them (or they were not linked properly). I have
been assuming that you put 'mcidas', 'ldm', and 'mcadde' all into the
same group.  The installation instructions and the installation itself
depend on these users being in the same group AND no others being in
that group.

>From address@hidden  Wed Aug 18 15:05:56 1999

>But then, also some failures.

>1. I reinstalled xcd stuff ...make install.xcd
>2. Went through the web pages on configuration...
>  (Did notice that the SYN decoders came up inactive,
>   managed to set those to active.)

Hmm...  The only data monitor that should come up inactive by default
is the one for GRIB data: DMGRID.

>3. I now have MDXXX files.

Very good.

>That's all I ever wanted out of life.

So, that night with Fifi and Babet, the up and downstairs maids, is
no longer an issue ;-).

>4. (No forecast grids...but I haven't grocked all that stuff.

OK.

>   My brain hurts and I just want to get some data.  I'll think
>   about that tomorrow.)

I'll be here.

>So, at this point I'm reasonably certain my ldm and xcd stuff
>is ok....at least for the present.  Also found I needed to allow
>for more memory in my crontab/batch files using mcenv to set to
>one frame....

Your post process stuff is trying to access frames other than 1?

>BUT my real problem

>5. Strings don't seem to propagate from one mcidas job to another...
>for example, when the MDR.BAT file runs, I have a line I add at the
>end of your supplied file:
>RUN "PTABLE MID$(TIME$,1,2),"?MYRAD"
>Setting a string to hold the time of the latest radar image...this is
>used in a couple of places in my batch files....but now when one
>of my crontab jobs runs:
> --END CONTOURS
>SPC PLOT OLAY  20  MDF=10 DAY=1999230 GRIDF=142 VDEV=YES COLOR=7 IMA=1 
>GRA=1 SF=
>YES
>---PLOTTING DONE
>SF 1
>String not found: ?MYRAD
>(command running is below)
>RUN 720 50 #?MYTIME #SYS(2003) 1 Surface Isobars/#?MYRAD Z Radar  
>FILE=LABEL.MCB

Run the DMAP STRTABLE command to see where the copy of STRTABLE that is
being used is located.  If it is in a subdirectory of ~mcidas/.mctmp, then
it will be deleted as soon as the session ends.  If it is in ~mcidas/workdata,
then I will have to probe further.

>from an interactive session
>TL                                                                     
>H           := 20:59:09                                                
>SLUNIT      := AMERICAN                                                
>SVCA        := 10                                                      
>XCDDATA     := /home/ldm/data/xcd                                      
>Y           := 1999230                                                 
>  --END OF LIST            

This looks like XCDDATA is persisting; true?  What does a the following
list out:

TL OUT

The 'TL' by itself will not list out the global strings (those that begin
with a '?'.

>6. In an interactive session, if I type the command L   (just the 
>simple letter), we get an infinite loop of output, 
>continually scrolling:

>cannot  locate string names - rerun setup.

Weird.  L should just turn on looping.

>  (boy, when I cut and pasted that 
>output up above, it sure screwed 
>up the formatting of this page...).

>OK. That's enough.  Hope to hear from you soon.

I feel bad that you are having to struggle so hard to get things working.
My offer to logon to your machine still stands.  I may be able to spot
something that I am not able to conjure up here just by being on your
machine.

Tom