[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20001228: McIDAS 7.7 ADDE setup at UGa

>From: Thomas Mote <address@hidden>
>Organization: U. Georgia
>Keywords: 200012282251.eBSMpko24860 McIDAS-X 7.70 ADDE

Tom,

>I got the new (post 12/1/00) version of McIDAS 7.7 and installed it from
>scratch on the RedHat 7 server. Now I'm back to the same ADDE server
>problems.

OK.

>I have this "new" cacimbo.ggy.uga.edu system running as the server. All
>the decoders are working and I can display data on it. All of the GINI
>products are also available, as you had helped me set up. (The only
>exception is the CONUS visible product, which we are having a problem with
>sending from the NOAAPort system. That's another story but soon to be
>fixed.)

OK, sounds good.

>I do a "dsserve.k LIST" on cacimbo and all looks as it should. I followed
>your instructions for the xinetd, and I can telnet to ports 500 and 503 on
>cacimbo. So far, so good...

I logged on and took a quick look at the mcserv and mccompress files in
/etc/xinetd.d.  There needs to be two small changes per file made (the
changes are the same in both files):

change:

        server          = /home/mcidas/linux/bin/mcservsh
        server_args     = -H /home/mcidas/linux

to:

        server          = /home/mcidas/bin/mcservsh
        server_args     = -H /home/mcidas


The changes need to be made by 'root'.  After making the changes, you will
need to send a USR1 signal to xinetd:

kill -USR1 pid_of_xinetd

>I have been setting up a new client system, which will be copied
>onto all of the systems in my lab. A DATALOC on that system shows that I
>have set most of the datasets to point to cacimbo.ggy.uga.edu. (I don't
>get any NIDS data.) However, when I try to access any data on the server,
>say through the F keys, I get an "unable to resolve" error. 

This is probably due to /etc/xinetd.d/mcserv|mccompress needing to
be modified.

>If you would like to take a look, I have temporarily changed the
>cacimbo.ggy.uga.edu (128.192.40.157) account

Thanks this was useful for three reasons:

1) the GINI configuration file in ~mcidas/workdata, GINI.CFG, gets
   overwritten by new installations, so all changes made to your old
   file (if one existed) were gone.  I tried to prevent this from
   happening again by doing the following:

   <login as 'mcidas'>
   cd workdata
   <edit RESOLV.SRV and change the Q=GINI.CFG sequence (tells the server
   to look in the configuration file GINI.CFG) to Q=UGAGINI.CFG.  Now
   that the GINI configuration file is named differently than what is
   in the distribution, it will no longer get overwritten by new installs.

   After making the UGAGINI.CFG copy of GINI.CFG, I edited it and setup
   dataset access information as it should be (setting the directory
   locations for the various GINI images).

2) the format of your GINI files has changed since the last time I was
   on a system named cacimbo.  Now, the products are being wrapped with
   beginning and ending byte sequences that make them look like old
   FOS products:

GINI image without opening preamble:

0000000   T   I   G   E   0   2       K   N   E   S       2   9   2   1
0000020   1   5  \r  \r  \n 001 013 001 004 005  \0 005  \0   d  \f 035
0000040 025 017  \0  \0 003 005  \0 005  \0 002 177   k 221   C   E  \0
0000060 216   ~ 360  \0 236 273  \0 236 273  \0  \0 003 320 220 004  \0
0000100  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0001020  \0  \0  \0  \0  \0 241 241 252 257 254 256 265 272 270 274 275
0001040 277 301 300 274 274 273 271 266 264 264 262 260 253 256 261 263
0001060 262 256 245 234 231 226 225 227 230 230 230 230 227 230 227 227
0001100 226 226 225 225 226 226 225 225 224 224 224 223 224 224 223 223

Your GINI product with the opening preamble:

0000000 001  \r  \r  \n   9   9   9  \r  \r  \n   T   I   G   E   0   2
0000020       K   N   E   S       2   9   2   1   1   5  \r  \r  \n 001
0000040  \v 001 004 005  \0 005  \0   d  \f 035 025 017  \0  \0 003 005
0000060  \0 005  \0 002 177   k 221   C   E  \0 216   ~   ð  \0 236   »
0000100  \0 236   »  \0  \0 003   Ð 220 004  \0  \0  \0  \0  \0  \0  \0
0000120  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0001020  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0   ¡
0001040   ¡   ª   ¯   ¬   ®   µ   º   ¸   ¼   ½   ¿   Á   À   ¼   ¼   »
0001060   ¹   ¶   ´   ´   ²   °   «   ®   ±   ³   ²   ®   ¥ 234 231 226

   I modified my McIDAS GINI server code to be able to handle either form,
   but conversations with Chiz indicate that GEMPAK might not be able to
   read the file format that you now have.  He suggested that you need to
   strip the first two "lines" off of the product in order to make GEMPAK
   work with them.  I don't know if you have run into this problem or not,
   but I decided that I should send along this info anyway.

3) saw that the /etc/xinetd.d/mcserv and mccompress files needed the
   modifications I outlined above.

>You can also look at my sample client system as well. It is currently
>named cacimbo2.ggy.uga.edu (128.192.178.77). (My network administrator's
>idea for the name; she didn't know which system was which.)

OK, I will take a look either tonight, or tomorrow morning.

>I thought I had actually covered everything this time through. I guess
>not.

New installations/upgrades to this machine should go smoothly now.

>Thanks again for your help.

No problem.  Have a great New Year!

Tom