[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[McIDAS #XLJ-825608]: Trouble setting up ADDE service for IDV use
- Subject: [McIDAS #XLJ-825608]: Trouble setting up ADDE service for IDV use
- Date: Fri, 24 Aug 2007 09:30:46 -0600
Hi Art,
re: you might consider upgrading to the latest addendum release
> I think I'm using that, unless you made a 2nd new one... I pulled another
> copy of McIDAS2007 and built it on 8/16/07...
That was up to date on the 16th; it isn't anymore. The last change I made
to the distribution was last night.
re: IDV use of PUBLIC.SRV
> Okay... I actually came across an email related to PUBLIC.SRV in my
> searching and thought of trying something with it but it was from 2001 and
> since I didn't see any documentation regarding it, I assumed it was
> abandoned.
>
> I've now copied the RESOLV.SRV file to PUBLIC.SRV. However, it's still
> not working. The problem may be more fundamental. In my SERVER.LOG file,
> an "od -c" shows it trying to use the PUBLIC.SRV file and the message
> "Unable to open requested file" appears after it. It looks like it's
> having trouble getting the file at all. I tried doing a
> "DSSERVE ADD PUBLIC/SRV TEXT DIRFILE=/home/meteo/mcidas/workdata/PUBLIC.SRV"
> in case that was required, but it doesn't seem to have helped either.
To get a listing out of SERVER.LOG, run the routine ADDEINFO:
<as 'mcidas'>
cd $MCDATA
addeinfo.k <- summary listing
> I should note that I have a slightly non-standard install in that I'm
> using the LDM approach of "runtime" links with McINST_ROOT one level below
> ~mcidas and then making a "runtime" link to the install root in ~mcidas.
This is how I setup McIDAS at home and in my development environment at
work. Everything should work nicely _if_ your environment variables are
adjusted to recognize your setup.
> Then I link all the working directories to "runtime" in ~mcidas. Here's a
> listing:
>
> drwxrwxr-x 6 mcidas mcidas 4096 Aug 22 18:06 .
> drwxr-xr-x 773 root root 16384 Aug 24 04:22 ..
> lrwxrwxrwx 1 mcidas mcidas 13 Aug 22 10:52 admin -> runtime/admin
> lrwxrwxrwx 1 mcidas mcidas 11 Aug 22 09:51 bin -> runtime/bin
> -rw-rw-r-- 1 mcidas mcidas 359 Aug 8 10:42 .cshrc
> lrwxrwxrwx 1 mcidas mcidas 12 Aug 22 09:49 data -> runtime/data
> drwxrwxr-x 3 mcidas mcidas 4096 Aug 22 10:51 dist
> lrwxrwxrwx 1 mcidas mcidas 11 Aug 22 09:51 etc -> runtime/etc
> lrwxrwxrwx 1 mcidas mcidas 12 Aug 22 09:51 help -> runtime/help
> lrwxrwxrwx 1 mcidas mcidas 11 Aug 22 09:51 inc -> runtime/inc
> lrwxrwxrwx 1 mcidas mcidas 15 Aug 22 09:51 include ->
> runtime/include
> lrwxrwxrwx 1 mcidas mcidas 11 Aug 22 09:51 lib -> runtime/lib
> lrwxrwxrwx 1 mcidas mcidas 11 Aug 22 09:51 man -> runtime/man
> -rw-rw-r-- 1 mcidas mcidas 92 Aug 22 12:54 .mcenv
> lrwxrwxrwx 1 mcidas mcidas 14 Aug 22 09:49 mcidas ->
> runtime/mcidas
> drwxrwxr-x 15 mcidas mcidas 4096 Aug 21 12:56 mcidas2007
> -rw-rw-r-- 1 mcidas mcidas 16566 Aug 8 15:42 .mcidasrc
> -rw-rw-r-- 1 mcidas mcidas 16508 Aug 22 14:14 .mcidasrc.tmp
> -rw-rw-r-- 1 mcidas mcidas 16508 Aug 22 12:13 .mcidasrc.tmp.old
> drwx------ 3 mcidas mcidas 4096 Aug 22 14:14 .mctmp
> drwxrwxr-x 3 mcidas mcidas 4096 Aug 22 10:48 psu_mods
> lrwxrwxrwx 1 mcidas mcidas 10 Aug 22 09:48 runtime -> mcidas2007
> lrwxrwxrwx 1 mcidas mcidas 16 Aug 22 09:51 savedata ->
> runtime/savedata
> lrwxrwxrwx 1 mcidas mcidas 11 Aug 22 09:51 tcl -> runtime/tcl
> -rw------- 1 mcidas mcidas 8798 Aug 22 18:06 .viminfo
> lrwxrwxrwx 1 mcidas mcidas 16 Aug 22 09:48 workdata ->
> runtime/workdata
> -rw------- 1 mcidas mcidas 126 Aug 9 13:51 .Xauthority
I see a big problem here: you have made your runtime link point to
mcidas2007. This will definitely lead to problems during upgrades as the
~mcidas/data directory is now the same as the distribution's data directory.
Also, the directory structure ~mcidas/mcidas should not
change from distribution to distribution.
What I do is the following:
** before building/installing McIDAS **
cd ~mcidas
export McINST_ROOT=mcidas07
mkdir mcidas07
./mcunpack
cd mcidas2007/src
make all
make install.all
cd ~mcidas
ln -s mcidas07 runtime
ln -s runtime/* .
> In ~mcidas/mcidas2007 (my McINST_ROOT directory):
>
> drwxrwxr-x 15 mcidas mcidas 4096 Aug 21 12:56 .
> drwxrwxr-x 6 mcidas mcidas 4096 Aug 22 18:06 ..
> drwxrwxr-x 2 mcidas mcidas 4096 Aug 22 10:38 admin
> drwxrwxr-x 2 mcidas mcidas 8192 Aug 21 12:56 bin
> drwxrwxr-x 3 mcidas mcidas 12288 Aug 22 12:21 data
> drwxrwxr-x 2 mcidas mcidas 4096 Aug 21 12:55 etc
> drwxrwxr-x 2 mcidas mcidas 8192 Aug 21 12:55 help
> drwxrwxr-x 2 mcidas mcidas 4096 Aug 20 18:38 inc
> drwxrwxr-x 2 mcidas mcidas 4096 Aug 20 18:38 include
> drwxrwxr-x 3 mcidas mcidas 4096 Aug 21 12:55 lib
> drwxrwxr-x 4 mcidas mcidas 4096 Aug 21 12:56 man
> drwxrwxr-x 3 mcidas mcidas 4096 Aug 20 18:38 mcidas
> drwxrwxr-x 2 mcidas mcidas 4096 Aug 20 18:38 savedata
> drwxrwxr-x 6 mcidas mcidas 4096 Aug 21 12:55 tcl
> drwxrwxr-x 2 mcidas mcidas 4096 Aug 24 09:57 workdata
>
> I put the sources under ~mcidas/dist. I do all this because I find it
> unsettling to have to delete my working build of mcidas when doing
> upgrades.
One doesn't have to delete a working build of McIDAS when doing an
upgrade. SSEC's approach to builds/upgrades is different that the
LDM's, but it works nicely. The source of a new distribution is always
put under its own directory tree: ~mcidas/mcidas2006 for v2006, etc.
When one does an upgrade to a new release, the procedure is:
<as 'mcidas'>
cd ~mcidas2007/src
make
-- test the distribution as per the directions I put in the Users Guide
-- when satisfied that the new release works, do the following:
cd ~mcidas/mcidas2006/src
make uninstall.all <- this removes installed files from
directories like ~mcidas/bin, etc.
but it does not delete the files from
where they were built
cd ~mcidas/mcidas2007/src
make install.all
> Hopefully this structure isn't creating a problem for mcservsh.
I would have to think long and hard before being able to say what your
setup may or may not do good or bad. I think maintenance of your
McIDAS installation would be much easier if you switched to a known setup.
I can help with this if you like.
re: what happens when you point the IDV at your server using the
machine name and ADDE dataset group name
> It says "Dataset not found on server: ls2.meteo.psu.edu"
I would say that your remote ADDE server interface is not setup correctly,
or that how you are doing your runtime link is causing a problem,
or the setup for your 'mcadde' user is not pointing at the right
place. The last possibility is the most likely.
re: have you made your ADDE installation publically available
>
> It's not publicly accessible at this point... I'm just trying to get
> something going. I can get it opened up if we need to in order to
> diagnose the problem.
I think the problem is being caused by your runtime link setup.
Here is something that you can try quickly:
<as 'root'>
cd /etc/xinetd.d
vi mcidas
-- change the 'server' definition to point at the specific location
in your setup, /home/mcidas/mcidas2007/bin/mcservsh
-- change the 'server_args' definition to the specific directory in
your setup, -H /home/mcidas/mcidas2007
I think these changes might work for you, but I strongly recommend that
you regularize your setup. It will make maintenance and support _so_
much easier in the future.
> Thanks for you help...
No worries. Again, I am happy to help you get your installation setup in
a standard way. In order to do this, I would need SSH access to your
machine as 'mcidas'.
One last comment: the example DSSERVE invocation you sent in your first
message was a bit different from the standard I send out with McIDAS. I
think you will be better off using the standard definitions so that your
IDV users can transparently go from one ADDE server for data to another
elsewhere in the community. In v2007 I have included a configuration
script, mcxconfig, that will create a McIDAS BATCH file of DSSERVE commands
that are used to define server mapping table entries. Since all of the
publicly accessible ADDE server sites in the Unidata community will be
using the standard dataset names, it would be a good idea if you did as
well. Again, this is so that the end user can simply point at a different
server and access the same data using the same standardized names.
Cheers,
Tom
****************************************************************************
Unidata User Support UCAR Unidata Program
(303) 497-8642 P.O. Box 3000
address@hidden Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage http://www.unidata.ucar.edu
****************************************************************************
Ticket Details
===================
Ticket ID: XLJ-825608
Department: Support McIDAS
Priority: Normal
Status: Closed