[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20000203: NIU ADDE access to MSFC imagery
This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
- Subject: 20000203: NIU ADDE access to MSFC imagery
- Date: Thu, 03 Feb 2000 12:04:22 -0700
>From: Gilbert Sebenste <address@hidden>
>Organization: NIU
>Keywords: 200001311730.KAA02738 McIDAS ADDE accounting
Anthony and Gilbert and MUG support,
Sorry I couldn't jump in on this discussion before now. I was off yesterday
(skiing; superb!) and have been trying to unbury myself from the email
that piled up (in one short day ;-().
I am including the entire set of email exchanges at the bottom of this
message for our tracking system. I will put my comments at the beginning
so you don't have to wade through the stuff you have already seen.
My specific comments are:
o I did not muck with the McIDAS code to eliminate comments like was
asked by Jay
"Maybe it's possible that the Unidata McIDAS does not have or print
that message or something like that."
I agreed with Jay's specualtion, however:
"If Gilbert's client machine is requesting compressed data transfers,
then your server must also have port 503 open for the compressed data
transfer."
o Jay's finding of 'stdin: not in compressed format' (I saw this this morning)
led me to the same conclusion that Jay cam to: there was something amiss in
the ADDE server setup at MSFC related to the finding of compress.
This matches what I found _and fixed_ for the Unidata release. Here
is the relevant comment from the change file, mcidas7.6/src/CHANGES.760
I include in the Unidata McIDAS-X distribution:
mcserv.cp SSEC 7.60 version with mods
added execl for compress and uncompress for Linux where
they are found in /usr/bin
added execl for compress and uncompress for IRIX where
they are found in /usr/bsd
The second line is the operative one for the MSFC problem! One must
either make a link on one's IRIX system so that compress can be found
in the location expected by mcserv, or one has to modify mcserv.cp and
have the /usr/bsd directory searched for compress (this is the route I
took).
Gilbert,
The use of the MCCOMPRESS environment variable in McIDAS to choose whether
or not to use compressed data transfers is presented in the Unidata
McIDAS-X Learning Guide:
http://www.unidata.ucar.edu/packages/mcidas/mclearn760/adde-6.html
I see that it should be discussed in detail in my online Installation
and Configuration information.
MUG support,
As a side comment, the use of an environment variable to determine
whether one uses compressed or uncompressed transfers has been
discussed at MUG meetings in the past. A number of us feel that a
users should be able to specify _at the command level_ which form to
use (i.e., compressed or uncompressed). Setting of MCCOMPRESS to
_anything_ forces ALL transfers to be done in compressed mode;
unsetting of MCCOMPRESS forces ALL transfers to be done in uncompressed
mode. This is less than optimum (to say the least).
As you have noted, when compressed transfers are turned off, loading of
imagery from remote sites is noticably slower.
If I were to redesign the compress/uncompress stuff (comment for the MUG),
I would add support for a keyword that sets the transfer mode
(like COMPRESS=YES|NO) that would override the setting of the MCCOMPRESS
environment variable. If keeping the MCCOMPRESS concept is near and
dear to someone's heart, then I would add support for the things that
Gilbert was trying to do:
MCCOMPRESS=TRUE | YES | ON | 1 -> use compressed transfers
MCCOMPRESS=FALSE | NO | OFF | 0 -> use uncompressed transfers
If MCCOMPRESS is not defined, then I would default it to FALSE/NO/OFF/0.
Anthony,
I figured that you _should_ be able to get compressed transfer support
working immediately by having your system administrator make a link
from /usr/bsd/compress to any of the directories already supported by
mcserv. Why this did not work for you is a mystery to me. For my
distribution, however, I chose to add the /usr/bsd directory into
mcserv.cp for both compress and uncompress since that would eliminate
the burden of explaining to users that their 'root' would need to make
the link.
The text that follows is the full transcript of the interactions that
Gilbert has had with Anthony and Anthony has had with the MUG, so you
can stop reading here.
Tom
Date: Thu, 03 Feb 2000 08:44:21 CST
To: "Gilbert Sebenste (E-mail)" <address@hidden>
cc: "'Unidata Support'" <address@hidden>
From: "Guillory, Anthony" <address@hidden>
Subject: FW: ADDE
>Here's UW response from after I left on yesterday. They think it may be a
>compression issue as I mentioned earlier to you. Although you turned it
>off, I wonder if for some reason Unidata might still need access to 503? In
>the meantime, I'm going to try to get 503 turned on. I'll follow up with
>you after that.
>
>Tom, any thoughts?
>
>Anthony
>Anthony R. Guillory
>NASA/Marshall Space Flight Center
>Global Hydrology and Climate Center
>977 Explorer Blvd.
>Huntsville, AL 35806-2807
>(256) 922-5894
>(256) 922-5723 FAX
>address@hidden <mailto:address@hidden>
>Geostationary Satellite Data: http://www.ghcc.msfc.nasa.gov/GOES
><http://www.ghcc.msfc.nasa.gov/GOES>
>
>-----Original Message-----
>From: MUG [mailto:address@hidden]
><mailto:[mailto:address@hidden]>
>Sent: Wednesday, February 02, 2000 5:10 PM
>To: address@hidden
><mailto:address@hidden>
>Cc: MUG; DaveSantek
>Subject: FW: ADDE
>
>Hi Anthony-
>We may have stumbled upon part of the problem. I DATALOC'd to your machine
>and was able to access your data just fine. Then I tried to access your
>data while running compression (setting the environmental variable
>MCCOMPRESS=YES) on my client. I received the following errors (which are
>almost identical to Gilbert's):
>DSINFO I G8-GHCC DEVÌC
>DSINFO* ***** REQ. CFILE-->ALA.G8-GHCC <--
>stdin: not in compressed format
>DSINFO* Read of server has failed. Wanted 4
>DSINFO* Did
> No Datasets found of Type: IMAGE in Group: G8-GHCC
>DSINFO-done
>IMGLIST G8-GHCC/VIS.ALL DEVÌC
>Image file directory listing for:G8-GHCC/VIS
>IMGLIST* mcadir:G8-GHCC VIS 1095519264 AUX=YES TRACE=0 BAND=ALL X
>IMGLIST* mcadir:
>IMGLIST* mcadir:
>stdin: not in compressed format
>IMGLIST* Read of server has failed. Wanted 4
>IMGLIST* Did
>IMGLIST: done
>
>IMGDISP G8-GHCC/VIS 1 STA=HSV DEVÌC
>IMGDISP* G8-GHCC VIS 0 EC 34.6500 86.7667 X 480 640 CAL=X TRACE=0 TIME=X X I
>
>IMGDISP* SPAC=1 UNIT=BRIT AUX=YES DAY= DOC=NO VERSION=1
>stdin: not in compressed format
>IMGDISP* Read of server has failed. Wanted 4
>IMGDISP* Did
>IMGDISP: done
>
>Notice the extra line "stdin: not in compressed format." Maybe it's
>possible that the Unidata McIDAS does not have or print that message or
>something like that. If Gilbert's client machine is requesting compressed
>data transfers, then your server must also have port 503 open for the
>compressed data transfer. (Appendix I talks a bit about this in the McIDAS
>User's Guide.) Maybe it's possible that Unidata McIDAS has compression
>"turned on" for it's default or Gilbert has something set on the client to
>request compressed data.
>Hopefully, this will get us closer to the solution. First, try to see if
>Gilbert can determine if he is running compression, hopefully he can turn it
>off. Then maybe he'll be able to get data from the server. Second, you
>could try opening Port 503 on your server for compressed data transfers, and
>then have him rerun his commands.
>Let us know how this goes. If problems still are occurring, let us know,
>and also possibly send along any insights that Tom Yoksas had.
>Thanks, Jay
>----------------------------------------------------------------------------
>--
>REPLY FROM: MUG Return-Path: <address@hidden
><mailto:address@hidden> > Message-Id:
><address@hidden
><mailto:address@hidden> >
>From:
>"Guillory, Anthony" <address@hidden
><mailto:address@hidden> > To: "MUG Help Desk
>(E-mail)" <address@hidden <mailto:address@hidden> > Cc: "'Gilbert
>Sebenste '"
>
><address@hidden
><mailto:address@hidden
>> >, "David Cross (E-mail)" <address@hidden
><mailto:address@hidden> >, "Edwards, Rita"
><address@hidden <mailto:address@hidden> >, "Paul
>Meyer (@rimeice) (E-mail)"
> <address@hidden <mailto:address@hidden>
>>, "'Tom Yokas'" <address@hidden <mailto:address@hidden>
>>
>Subject: FW: ADDE
>Date: Mon, 31 Jan 2000 12:44:02 -0600
> MIME-Version: 1.0
> X-Mailer: Internet Mail Service (5.5.2650.21)
> Content-Type: text/plain; charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
>MUG,
>We are trying to grant access to our McIDAS-X ADDE server (UW McIDAS-X
>7.501, SGI Origin 200, dual 180 MHz R10000) to Gilbert Sebenste at NIU who
>is running (Linux Redhat 6.0 dual PII 450 MHZ Intel-based PC from SW
>Technologies with Unidata McIDAS-X 7.605). We can confirm that he can
>ping, traceroute, telnet to port 500, and even see that he "connects" to the
>ADDE server in the system log files using the commands shown below, but he
>is unable to access any data. I've attached below the output (with
>DEV=CCC) of series of commands that I had him try. All end with the same
>result. Access to the ADDE server is controlled through the etc.hosts
>allow/deny files and not through the McIDAS accounting s/w due to security
>concerns. We have also verified that reverse DNS works for his machine. Tom
>Yokas at Unidata has provided some insight into things but since this is
>getting over my head I thought I'd turn to you as well. Any ideas as to the
>culprit to this problem?
>P.S. As a side note, I can connect to his server (same machine) from our
>server (acting as the client of course) without a problem.
>Thanks, Anthony
>Anthony R. Guillory
>NASA/Marshall Space Flight Center
>Global Hydrology and Climate Center
>977 Explorer Blvd.
>Huntsville, AL 35806-2807
>(256) 922-5894
>(256) 922-5723 FAX
>address@hidden <mailto:address@hidden>
><mailto:address@hidden
><mailto:address@hidden> >
>
>Geostationary Satellite Data: http://www.ghcc.msfc.nasa.gov/GOES
><http://www.ghcc.msfc.nasa.gov/GOES>
><http://www.ghcc.msfc.nasa.gov/GOES <http://www.ghcc.msfc.nasa.gov/GOES> >
>
>
>
>-----Original Message-----
>From: Gilbert Sebenste [mailto:address@hidden]
><mailto:[mailto:address@hidden]>
> <mailto:[mailto:address@hidden]
><mailto:[mailto:address@hidden]> >
>Sent: Thursday, January 27, 2000 9:55 AM
>To: Guillory, Anthony
>Cc: David Cross (E-mail); Edwards, Rita; Paul Meyer (@rimeice) (E-mail)
>Subject: RE: ADDE
>
>On Thu, 27 Jan 2000, Guillory, Anthony wrote:
> > Gilbert,
> >
> > If you show 198.116.59.198 in your
> >
> > DATALOC LIST
> >
> > For the G8-GHCC dataset. Do the following in McIDAS:
>
>OK, here you go. I separated a few lines to make it easier to read.
>TFILE did OPEN on window 0
>DATALOC LIST
>
>Group Name Server IP Address
>-------------------- ----------------------------------------
>G8-GHCC 198.116.59.198
>MYDATA <LOCAL-DATA>
>RTGRIDS <LOCAL-DATA>
>RTIMAGES <LOCAL-DATA>
>RTNIDS <LOCAL-DATA>
>RTNOWRAD <LOCAL-DATA>
>RTPTSRC <LOCAL-DATA>
>RTWXTEXT <LOCAL-DATA>
>TOPO <LOCAL-DATA>
>
><LOCAL-DATA> indicates that data will be accessed from the local data
>directory.
>DATALOC-done
>DSINFO IMAGE G8-GHCC DEVÌC
>DSINFO* ***** REQ. CFILE-->ALA.G8-GHCC <--
>DSINFO* Read of server has failed. Wanted 4
>DSINFO* Did
> No Datasets found of Type: IMAGE in Group: G8-GHCC
>DSINFO-done
>IMGLIST G8-GHCC/VIS.ALL DEVÌC
>
>Image file directory listing for:G8-GHCC/VIS
>IMGLIST* mcadir:G8-GHCC VIS 1095519264 AUX=YES TRACE=0 BAND=ALL X
>IMGLIST* mcadir:
>IMGLIST* mcadir:
>IMGLIST* Read of server has failed. Wanted 4
>IMGLIST* Did
>IMGLIST: done
>
>SF 1
>IMGDISP G8-GHCC/VIS 1 STA=HSV DEVÌC
>IMGDISP* G8-GHCC VIS 0 EC 34.6500 86.7667 X 480 640 CAL=X TRACE=0
>TIME=X X I
>SPAC
>IMGDISP* C=1 UNIT=BRIT AUX=YES DAY= DOC=NO VERSION=1
>IMGDISP* Read of server has failed. Wanted 4
>IMGDISP* Did
>IMGDISP: done
>
>TFILE CLOSE 0
>McIDAS version 7.605
>
>************************************************************************
>****
>***
>Gilbert Sebenste
>********
>Internet: address@hidden <mailto:address@hidden> <mailto:address@hidden
><mailto:address@hidden> > (My opinions only!)
>******
>Staff Meteorologist, Northern Illinois University
>****
>E-mail: address@hidden
><mailto:address@hidden>
><mailto:address@hidden
><mailto:address@hidden> >
> ***
>web: http://weather.admin.niu.edu <http://weather.admin.niu.edu>
><http://weather.admin.niu.edu <http://weather.admin.niu.edu> >
>**
>Work phone: 815-753-5492
>*
>************************************************************************
>****
>***
>
>From address@hidden Thu Feb 3 10:09:32 2000
On Thu, 3 Feb 2000, Guillory, Anthony wrote:
>
> Here's UW response from after I left on yesterday. They think it may be a
> compression issue as I mentioned earlier to you. Although you turned it
> off, I wonder if for some reason Unidata might still need access to 503? In
> the meantime, I'm going to try to get 503 turned on. I'll follow up with
> you after that.
>
> Tom, any thoughts?
>
> Anthony
> Anthony R. Guillory
> NASA/Marshall Space Flight Center
> Global Hydrology and Climate Center
> 977 Explorer Blvd.
> Huntsville, AL 35806-2807
> (256) 922-5894
> (256) 922-5723 FAX
> address@hidden <mailto:address@hidden>
> Geostationary Satellite Data: http://www.ghcc.msfc.nasa.gov/GOES
> <http://www.ghcc.msfc.nasa.gov/GOES>
>
>
>
> -----Original Message-----
> From: MUG [mailto:address@hidden]
> <mailto:[mailto:address@hidden]>
> Sent: Wednesday, February 02, 2000 5:10 PM
> To: address@hidden
> <mailto:address@hidden>
> Cc: MUG; DaveSantek
> Subject: FW: ADDE
>
> Hi Anthony-
> We may have stumbled upon part of the problem. I DATALOC'd to your machine
> and was able to access your data just fine. Then I tried to access your
> data while running compression (setting the environmental variable
> MCCOMPRESS=YES) on my client. I received the following errors (which are
> almost identical to Gilbert's):
> DSINFO I G8-GHCC DEVÌC
> DSINFO* ***** REQ. CFILE-->ALA.G8-GHCC <--
> stdin: not in compressed format
> DSINFO* Read of server has failed. Wanted 4
> DSINFO* Did
> No Datasets found of Type: IMAGE in Group: G8-GHCC
> DSINFO-done
> IMGLIST G8-GHCC/VIS.ALL DEVÌC
> Image file directory listing for:G8-GHCC/VIS
> IMGLIST* mcadir:G8-GHCC VIS 1095519264 AUX=YES TRACE=0 BAND=ALL X
> IMGLIST* mcadir:
> IMGLIST* mcadir:
> stdin: not in compressed format
> IMGLIST* Read of server has failed. Wanted 4
> IMGLIST* Did
> IMGLIST: done
>
> IMGDISP G8-GHCC/VIS 1 STA=HSV DEVÌC
> IMGDISP* G8-GHCC VIS 0 EC 34.6500 86.7667 X 480 640 CAL=X TRACE=0 TIME=X X I
>
> IMGDISP* SPAC=1 UNIT=BRIT AUX=YES DAY= DOC=NO VERSION=1
> stdin: not in compressed format
> IMGDISP* Read of server has failed. Wanted 4
> IMGDISP* Did
> IMGDISP: done
>
> Notice the extra line "stdin: not in compressed format." Maybe it's
> possible that the Unidata McIDAS does not have or print that message or
> something like that. If Gilbert's client machine is requesting compressed
> data transfers, then your server must also have port 503 open for the
> compressed data transfer. (Appendix I talks a bit about this in the McIDAS
> User's Guide.) Maybe it's possible that Unidata McIDAS has compression
> "turned on" for it's default or Gilbert has something set on the client to
> request compressed data.
> Hopefully, this will get us closer to the solution. First, try to see if
> Gilbert can determine if he is running compression, hopefully he can turn it
> off. Then maybe he'll be able to get data from the server. Second, you
> could try opening Port 503 on your server for compressed data transfers, and
> then have him rerun his commands.
> Let us know how this goes. If problems still are occurring, let us know,
> and also possibly send along any insights that Tom Yoksas had.
> Thanks, Jay
I just tried it with the environment variable MCCOMPRESS set to FALSE, and
then to NONE, to see if it would work. Each time, I got the same result:
no imagery (and yep, I did shut down mcidas after every time I did a
source .cshrc). So, still no-go. That is the correct variable, correct? Or
am I still missing something?
*******************************************************************************
Gilbert Sebenste ********
Internet: address@hidden (My opinions only!) ******
Staff Meteorologist, Northern Illinois University ****
E-mail: address@hidden ***
web: http://weather.admin.niu.edu **
Work phone: 815-753-5492 *
*******************************************************************************
>From address@hidden Thu Feb 3 10:38:09 2000
Gilbert,
>I just tried it with the environment variable MCCOMPRESS set to FALSE, and
>then to NONE, to see if it would work. Each time, I got the same result:
>no imagery (and yep, I did shut down mcidas after every time I did a
>source .cshrc). So, still no-go. That is the correct variable, correct? Or
>am I still missing something?
Not sure how you are setting the variable.
Are you using "set" and "export" or "setenv" ??? I guess the question is
which shell are you using Bourne/ksh or csh? I assume csh since you are
sourcing your .cshrc.
I tried setting MCCOMPRESS to NONE and the result was no data. So you might
want to verify that MCCOMPRESS is not in your environment at all. Just exit
McIDAS, do unset MCCOMPRESS and/or unsetenv MCCOMPRESS and then restart and
give it a shot.
==
Here's what I've found using a system here related to compression:
To undo compression I:
unsetenv MCCOMPRESS
(I'm using tcsh - improve csh). This gives me data as usual. But doing a:
setenv MCCOMPRESS YES
results in no data. I was told "YES" was the correct answer, but I'm not
sure it matters. The result is identical output to yours. We are still
puzzled why using compression fails now that port 503 is alive. In fact, it
appears that it is still using port 500 (looking at the SYSLOG at the same
time as the command is entered) because mcservsh answers the request rather
than mccompress.
Anthony
Anthony R. Guillory
NASA/Marshall Space Flight Center
Global Hydrology and Climate Center
977 Explorer Blvd.
Huntsville, AL 35806-2807
(256) 922-5894
(256) 922-5723 FAX
address@hidden <mailto:address@hidden>
Geostationary Satellite Data: http://www.ghcc.msfc.nasa.gov/GOES
<http://www.ghcc.msfc.nasa.gov/GOES>
-----Original Message-----
From: Gilbert Sebenste
[mailto:address@hidden]
Sent: Thursday, February 03, 2000 11:10 AM
To: Guillory, Anthony
Cc: 'Unidata Support'
Subject: Re: FW: ADDE
This message uses a character set that is not supported by
the Internet Service. To view the original message content, open the
attached message. If the text doesn't display correctly, save the attachment
to disk, and then open it using a viewer that can display the original
character set. << File: message.txt >>
>From address@hidden Thu Feb 3 10:53:14 2000
GOT IT! IT WORKS! The solution: dump the MCCOMPRESS line from my
mcidas account .cshrc (I am using tcsh, by the way) altogether!
But Tom, won't that affect me getting images from the UNIDATA server?
Guess I'll find out now. Weird projection (conformal), but very nice,
NASA. Now, let's see if UNIDATA's stuff displays. YES! But it displays
more slowly.
Hmmmm. I have a hunch the compression does speed up things and reduces
bandwidth problems. That's a *guess* (right Tom?). If so, can they still
be sent compressed via NASA by doing something on my end? If so, what?
Thanks for all your help, everyone. As of 11:50 AM, the images are coming
in!!!!
*******************************************************************************
Gilbert Sebenste ********
Internet: address@hidden (My opinions only!) ******
Staff Meteorologist, Northern Illinois University ****
E-mail: address@hidden ***
web: http://weather.admin.niu.edu **
Work phone: 815-753-5492 *
*******************************************************************************
>From address@hidden Thu Feb 3 11:12:44 2000
Glad to hear it works Gilbert! !
As for the project, Gilbert, everything is in the GVAR raw projection. So
keep in mind GOES oversamples (almost 2:1) in the E-W than in the N-S
direction. So nothing is remapped. We wanted the data to be "pure", so we
can do whatever to it after collection. You might use IMGDISP G8-GHCC/VIS
STA=ORD MAG=1 -2 to get close to a normal perspective, but in doing so you
throw away a little bit of information in the oversampling. Your call.
Update on compression here, Rita & David our sys admins found at least one
problem with the UW code. A hardcoded directory for IRIX for the compress
routine - which is wrong! I'll forward Rita's writeup to UW and cc: Unidata
on it when I get it. But at the moment even that hasn't fixed the port 503
problem or at least our first test didn't solve the problem. Hopefully,
that will get fixed and you won't have to worry about Unidata versus us.
Anthony
Anthony R. Guillory
NASA/Marshall Space Flight Center
Global Hydrology and Climate Center
977 Explorer Blvd.
Huntsville, AL 35806-2807
(256) 922-5894
(256) 922-5723 FAX
address@hidden <mailto:address@hidden>
Geostationary Satellite Data: http://www.ghcc.msfc.nasa.gov/GOES
<http://www.ghcc.msfc.nasa.gov/GOES>
-----Original Message-----
From: Gilbert Sebenste
[mailto:address@hidden]
Sent: Thursday, February 03, 2000 11:53 AM
To: Guillory, Anthony
Cc: Unidata Support (E-mail); David Cross (E-mail);
Edwards, Rita
Subject: YEEAAAAAHHHHHHHHHHHHH!!!!!
GOT IT! IT WORKS! The solution: dump the MCCOMPRESS line
from my
mcidas account .cshrc (I am using tcsh, by the way)
altogether!
But Tom, won't that affect me getting images from the
UNIDATA server?
Guess I'll find out now. Weird projection (conformal), but
very nice,
NASA. Now, let's see if UNIDATA's stuff displays. YES! But
it displays
more slowly.
Hmmmm. I have a hunch the compression does speed up things
and reduces
bandwidth problems. That's a *guess* (right Tom?). If so,
can they still
be sent compressed via NASA by doing something on my end? If
so, what?
Thanks for all your help, everyone. As of 11:50 AM, the
images are coming
in!!!!
****************************************************************************
***
Gilbert Sebenste
********
Internet: address@hidden (My opinions only!)
******
Staff Meteorologist, Northern Illinois University
****
E-mail: address@hidden
***
web: http://weather.admin.niu.edu
**
Work phone: 815-753-5492
*
****************************************************************************
***
>From address@hidden Thu Feb 3 11:58:51 2000
Jay,
In the process of resolving our situation with Gilbert at NIU, we have
looked at several things: 1) port 503 access - was denied, but now enabled
for mccompress, 2) the source code for detecting which port to use, and 3)
source code for compress calls. Below is a message from our sys admin about
a McIDAS-X hardcoding problem with the directory for the uncompress and
compress routines under IRIX. (Note: IRIX 6.5.x and the same McIDAS-X code
was compared between ver. 7.5xx and 7.600 - no changes). Unfortunately, an
attempt to do a symbolic link to fake the hardcoded directory did not solve
the problem, nor did copying the executables to the hardcoded directory.
There appears to more to this problem, but have been unable to find it. I
would like to get compression working (tried long time ago and gave up) not
just for NIU purposes. BTW, all of this testing was in house - not with
NIU. Ideas? Also, brutus still has access.
**As an additional note, Gilbert's problem was resolved when the set for
MCCOMPRESS was taken out of his .cshrc file. Of course, that slows his
connections to Unidata, but for now he has access to our server.
Thanks for your help.
Anthony
---------- Forwarded message ----------
Date: Thu, 03 Feb 2000 12:11:39 -0600
From: Rita Edwards <address@hidden
<mailto:address@hidden> >
To: Anthony R. Guillory <address@hidden
<mailto:address@hidden> >
Cc: David Cross <address@hidden
<mailto:address@hidden> >
Subject: Hardcoding executable paths
In the file mcserv.cp
First the comments:
* future porting note:
* the 'compress' and 'uncompress' commands are found in /bin
* on AIX, HPUX, and Solaris. They are found in /usr/ucb on IRIX.
Then the actual calls:
execl("/bin/compress", "compress", "-cf",0); execl("/usr/ucb/compress",
"compress", "-cf",0);
execl("/bin/uncompress", "uncompress","-cf",0); execl("/usr/ucb/uncompress",
"uncompress","-cf",0);
The problem is that /usr/ucb does not exist on IRIX. So we tried to do a
symbolic link from where the executables for compress and uncompress really
reside:
geo 6# whereis uncompress
uncompress: /usr/bsd/uncompress
/usr/share/catman/u_man/cat1/uncompress.z
geo 7# whereis ucb
ucb:
geo 8# ls /usr
Cadmin Motif-2.1 WorkShop bin diags
impressario lib64 pcp sgitcl tmp
CaseVision NetVis WorkShopMPF bsd etc
include local people share tmp_rex
CosmoPlayer SpeedShop adm cms freeware
java mail preserve sitemgr update
Imgtcl ToolTalk adobe cpu gfx
lib mbase relnotes spool var
Motif-1.2 WebFace array demos gnu
lib32 nds sbin sysadm webdocs
geo 10# cd /usr
geo 11# mkdir ucb
geo 12# ln -s /usr/bsd/uncompress /usr/ucb/uncompress
geo 13# ls -al ucb
total 4
drwxr-xr-x 2 root sys 28 Feb 3 17:36 .
drwxr-xr-x 47 root sys 2048 Feb 3 17:36 ..
lrwxr-xr-x 1 root sys 19 Feb 3 17:36 uncompress ->
/usr/bsd/uncompress
geo 14# ln -s /usr/bsd/compress /usr/ucb/compress
geo 15# ls -al ucb
total 4
drwxr-xr-x 2 root sys 45 Feb 3 17:36 .
drwxr-xr-x 47 root sys 2048 Feb 3 17:36 ..
lrwxr-xr-x 1 root sys 17 Feb 3 17:36 compress ->
/usr/bsd/compress
lrwxr-xr-x 1 root sys 19 Feb 3 17:36 uncompress ->
/usr/bsd/uncompress
However, that did not work. The question is do we need to copy the
executables over to /usr/ucb or put another execl call into the code?
Rita
--
Rita R. Edwards
Research Scientist
Nichols Research Corporation (NRC)
(256)922-5873
* I've had prayers answered.
* Now I'm careful what I ask for.
Anthony R. Guillory
NASA/Marshall Space Flight Center
Global Hydrology and Climate Center
977 Explorer Blvd.
Huntsville, AL 35806-2807
(256) 922-5894
(256) 922-5723 FAX
address@hidden <mailto:address@hidden>
Geostationary Satellite Data: http://www.ghcc.msfc.nasa.gov/GOES
<http://www.ghcc.msfc.nasa.gov/GOES>
>From address@hidden Thu Feb 3 15:35:28 2000
Jay,
You hit me over the head. We changed the link on the server but didn't do
it on the client!! Did it. It works - for me at least. Thanks a bunch!
Anthony
Anthony R. Guillory
NASA/Marshall Space Flight Center
Global Hydrology and Climate Center
977 Explorer Blvd.
Huntsville, AL 35806-2807
(256) 922-5894
(256) 922-5723 FAX
address@hidden <mailto:address@hidden>
Geostationary Satellite Data: http://www.ghcc.msfc.nasa.gov/GOES
<http://www.ghcc.msfc.nasa.gov/GOES>
-----Original Message-----
From: MUG [mailto:address@hidden]
Sent: Thursday, February 03, 2000 2:48 PM
To: address@hidden
Cc: Tom Yoksas (UNIDATA coor); MUG
Subject: ADDE Compression under IRIX and Hardcodi
Hi Anthony-
At least we are getting toward some answers. I have to apologize for not
asking what operating system your server is running. We encountered the same
IRIX compression problems that you found with /usr/bin/ vs. /usr/bsd/ at
NASA-Langley and Boeing. This has been addressed in inq. 10489 and the fix
is currently in testing here at SSEC (this should be in the May upgrade or
possibly in a Fastrack before then).
I'm glad that Gilbert was able to access the data. Like TomY said though, it
is a mystery why he or your local clients cannot access the compressed data
after your sysadmin made the link for the proper compress/uncompress
directories. Adding a link worked for NASA-Langley and Boeing (inq. 10489)
for their 7.6 servers. Also, I just turned compression on for Brutus here.
I was able to DSINFO/IMGLIST/IMGDISP/IMGCOPY your data on 198.116.59.198 with
success. So that puzzles me even more why compression would work for me and
not everyone else. As long as the clients and servers are McIDAS-X 7.3 or
later compression should work. Also, this is from page 2-29 of the User's
Guide: "This feature utilizes the Unix compress command on the remote server
and uncompress command on the client." Is it possible your clients are not
finding the uncompress command? If problems still exist with this, what do
the errors, DEV=CCC output, and trace files look like? Similar to before or
are they different now?
Hope this info helps. Thanks again for going through all these iterations
with me and allowing access to your machine. It sure helps with the problem
solving.
Thanks, Jay
---------------------------------------------------------------------------- --
REPLY FROM: MUG From: "Guillory, Anthony" <address@hidden>
To: "MUG Help Desk (E-mail)" <address@hidden>
Cc: "Unidata Support
(E-mail)" <address@hidden>, "David Cross (E-mail)"
<address@hidden>, "Edwards, Rita"
<address@hidden> Subject: ADDE Compression under IRIX and
Hardcoding executable paths Date: Thu, 3 Feb 2000 12:57:33 -0600
Jay,
In the process of resolving our situation with Gilbert at NIU, we have
looked at several things: 1) port 503 access - was denied, but now enabled
for mccompress, 2) the source code for detecting which port to use, and 3)
source code for compress calls. Below is a message from our sys admin about
a McIDAS-X hardcoding problem with the directory for the uncompress and
compress routines under IRIX. (Note: IRIX 6.5.x and the same McIDAS-X code
was compared between ver. 7.5xx and 7.600 - no changes). Unfortunately, an
attempt to do a symbolic link to fake the hardcoded directory did not solve
the problem, nor did copying the executables to the hardcoded directory.
There appears to more to this problem, but have been unable to find it. I
would like to get compression working (tried long time ago and gave up) not
just for NIU purposes. BTW, all of this testing was in house - not with
NIU. Ideas? Also, brutus still has access.
**As an additional note, Gilbert's problem was resolved when the set for
MCCOMPRESS was taken out of his .cshrc file. Of course, that slows his
connections to Unidata, but for now he has access to our server.
Thanks for your help.
Anthony
---------- Forwarded message ----------
Date: Thu, 03 Feb 2000 12:11:39 -0600
From: Rita Edwards <address@hidden
<mailto:address@hidden> >
To: Anthony R. Guillory <address@hidden
<mailto:address@hidden> >
Cc: David Cross <address@hidden
<mailto:address@hidden> >
Subject: Hardcoding executable paths
In the file mcserv.cp
First the comments:
* future porting note:
* the 'compress' and 'uncompress' commands are found
in /bin
* on AIX, HPUX, and Solaris. They are found in
/usr/ucb on IRIX.
Then the actual calls:
execl("/bin/compress", "compress", "-cf",0); execl("/usr/ucb/compress",
"compress", "-cf",0);
execl("/bin/uncompress", "uncompress","-cf",0); execl("/usr/ucb/uncompress",
"uncompress","-cf",0);
The problem is that /usr/ucb does not exist on IRIX. So we tried to do a
symbolic link from where the executables for compress and uncompress really
reside:
geo 6# whereis uncompress
uncompress: /usr/bsd/uncompress
/usr/share/catman/u_man/cat1/uncompress.z
geo 7# whereis ucb
ucb:
geo 8# ls /usr
Cadmin Motif-2.1 WorkShop bin diags
impressario lib64 pcp sgitcl tmp
CaseVision NetVis WorkShopMPF bsd etc
include local people share tmp_rex
CosmoPlayer SpeedShop adm cms freeware
java mail preserve sitemgr update
Imgtcl ToolTalk adobe cpu gfx
lib mbase relnotes spool var
Motif-1.2 WebFace array demos gnu
lib32 nds sbin sysadm webdocs
geo 10# cd /usr
geo 11# mkdir ucb
geo 12# ln -s /usr/bsd/uncompress /usr/ucb/uncompress
geo 13# ls -al ucb
total 4
drwxr-xr-x 2 root sys 28 Feb 3 17:36 .
drwxr-xr-x 47 root sys 2048 Feb 3 17:36 ..
lrwxr-xr-x 1 root sys 19 Feb 3 17:36 uncompress ->
/usr/bsd/uncompress
geo 14# ln -s /usr/bsd/compress /usr/ucb/compress
geo 15# ls -al ucb
total 4
drwxr-xr-x 2 root sys 45 Feb 3 17:36 .
drwxr-xr-x 47 root sys 2048 Feb 3 17:36 ..
lrwxr-xr-x 1 root sys 17 Feb 3 17:36 compress ->
/usr/bsd/compress
lrwxr-xr-x 1 root sys 19 Feb 3 17:36 uncompress ->
/usr/bsd/uncompress
However, that did not work. The question is do we need to copy the
executables over to /usr/ucb or put another execl call into the code?
Rita
--
Rita R. Edwards
Research Scientist
Nichols Research Corporation (NRC)
(256)922-5873
* I've had prayers answered.
* Now I'm careful what I ask for.
Anthony R. Guillory
NASA/Marshall Space Flight Center
Global Hydrology and Climate Center
977 Explorer Blvd.
Huntsville, AL 35806-2807
(256) 922-5894
(256) 922-5723 FAX
address@hidden <mailto:address@hidden>
Geostationary Satellite Data:
http://www.ghcc.msfc.nasa.gov/GOES
<http://www.ghcc.msfc.nasa.gov/GOES>
>From address@hidden Thu Feb 3 16:00:23 2000
On Thu, 3 Feb 2000, Guillory, Anthony wrote:
> Jay,
>
> You hit me over the head. We changed the link on the server but didn't do
> it on the client!! Did it. It works - for me at least. Thanks a bunch!
Anthony,
It works for me too...and it comes over LIGHTNING fast! Compression is the
way to go. OK, I'll keep the compression on! Thanks EVERYONE for all your
help...looks like there are some bugs to fix, issues to tackle, but gang,
I love this ADDE stuff, despite the glitches. Thanks to everyone for
pitching in on this!!!! Tom, muchas gracias!
*******************************************************************************
Gilbert Sebenste ********
Internet: address@hidden (My opinions only!) ******
Staff Meteorologist, Northern Illinois University ****
E-mail: address@hidden ***
web: http://weather.admin.niu.edu **
Work phone: 815-753-5492 *
*******************************************************************************
- Prev by Date: 20000202: problem with mcidasx & custom sat. loop
- Next by Date: 20000203: New McIDAS-X users
- Previous by thread: 20000202: problem with mcidasx & custom sat. loop
- Next by thread: 20000203: New McIDAS-X users
- Index(es):