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.
Hi Bernie, re: > Thanks for the response and glad to hear that you were not affected by the > various fires. > The IP for ULY has changed. It is now 129.82.109.142 OK, thanks for the information. I just tested access to the ULY/AMSU dataset from my machine here at the UPC, and I encountered _no_ problems. This might imply one of two things: - the firewall on 129.82.109.142 is configured to allow requests from machines in the U.S. - there is something amiss in the McIDAS setup on the CIMH machine re: > I thought it was Spring of 2010 that Barbados was able to connect to the > PUB server: which is SATEPSANONE.NESDIS.NOAA.GOV It could be that it is > not a public server anymore? I thought SATEPSANONE.NESDIS.NOAA.GOV was supposed to be open to all. I can attest to the fact that it, at least, used to be open. I have accessed it on several occasions when I was in Brazil. re: > When I checked emails, it was Sept 2009 that they successfully connected. > > I'm not sure I fully understand how McIDAS transfers data, what ports are > normally open and blocked by the firewall for incoming and outgoing data, > and how the user modifies this. A typical firewall setup will allow all outgoing connections and limit incoming connections to certain IP addresses for specific services. It is unusual for a university site to limit outgoing connection attempts. The way McIDAS works is: - the user specifies which host to contact by its ADDE dataset name (e.g., ULY for your AMSU data) - when the user running McIDAS tries to access that dataset, a process is started which tries to connect to port 112 on the server machine. The port that will be opened on the client machine is semi-random, and will almost always be >= 1024. - if the firewall on the serving machine has been setup to allow connection attempts through port 112, and if McIDAS has been properly configured to respond to those connection attempts, then the process ~mcidas/bin/mcservsh will be run. This Shell script sources the ~mcidas/.mcenv file to setup environment variables needed to run McIDAS routines, and then it execs the McIDAS top level server 'mcserv'. 'mcserv' will read the request being made and then start the appropriate data-specific top level server (e.g., adirserv for listing image in AREA file format information, etc.). The top level server started by 'mcserv' will either process the data request directly (if it knows about the data type) or start a sub-server (e.g., giniadir for listing of imagery in GINI format,etc.). re: > (That's why we have experts like you!) We're in big trouble now ;-) re: > I will forward your suggestion to have them check connection to RTIMAGES. Very good. Please let me know if there is anything further I can do to help. For instance, if I was given login information to the CIMH machine, I could poke around to see if there is anything obvious amiss. 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: JGU-378119 Department: Support McIDAS Priority: Normal Status: Closed