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

[McIDAS #CNL-142507]: Setting up AIX ADDE Server

Hi Martha,

re: ADDE serving
> I know you have been helping Randy with this, and I have your email to
> him from last Friday.  We are having problems getting this to work.


> A couple of points:
> * The MD files are not on a NOAAP ingestor, but sitting in a
>   directory on an AIX box (historical rather than realtime MD files)

OK.  This setup works nicely for MD, GRID and AREA data, but not for
the TEXT data created by McIDAS-XCD.

> * I have installed UNIDATA McIDAS 2005b on the AIX box, and
>   configured it as an ADDE server with mcinet.

Very good.

> * I copied the mcadde_env.ksh to /home/mcidas/.mcenv


> * I have created a mcadde account which has /home/mcidas as its
>   $HOME.  However, I cannot give the mcadde account the same UID as the
>   mcidas account has on AIX; I don't know if this is causing a problem.

The user 'mcadde' does not need/should not have the same UID as 'mcidas'.
The 'mcadde' account should have the same HOME directory as 'mcidas' (as
you have done), and it should _NOT_ allow logins.

> I used a DSSERVE to define the data set, under the mcidas account, i.e.,
> dsserve.k ADD SFCJAN06/DATA MD DIRFILE="/d1/RawSfc/jan2006/MD*"

Two comments:

- do not sorround the DIRFILE= value with quotes.  Since I see that you
  are running this from the Unix command line, I suggest using:

dsserve.k ADD SFCJAN06/DATA MD DIRFILE=/d1/RawSfc/jan2006/MD\*

- it is always a good idea to include the description field in your
  DSSERVE command.  For the realtime surface POINT data, I would use:

dsserve.k ADD SFCJAN06/DATA MD DIRFILE=/d1/RawSfc/jan2006/MD\* \"Real-Time SFC 
Hourly data

> And in fact when I do a PTLIST on that dataset, on the AIX system, I can
> see the data.

Very good.

> On the client machine, I used a DATALOC to reference the AIX ADDE
> server, which is called GSTN, but when I do a DSINFO ALL GSTN,
> It responds but shows no data sets.

ADDE has no discovery capability, meaning that you can not ask a
machine what ADDE datasets it has.  You need to know the machine
name in order to tell DATALOC where to find the dataset.  You then
use DSINFO to ask the ADDE server about the contents of the dataset
with group name XXX.  For instance:


-- or --


> I used tcpdump on the AIX box to watch the network traffic between it
> and its ADDE client when the DSINFO command is issued, and everything
> there seems to be copasetic; the server and client are talking to each
> other and the server is using the mcidas port.
> Can you help us out with this?

I think your problem is you were specifying the machine name instead
of the dataset group name in your DSINFO invocation.  Please try my
suggestions above.

Aside:  we have found that 'telnet' can be used to see if the ADDE
remote interface is setup more-or-less correctly.  Here is an example
of something we use to begin the process of investigating if an
ADDE remote server is configured correctly:

telnet gstn 112

You should get a message back that looks something like:

Trying xxx.xxx.xxx.xxx...
Connected to shemp.unidata.ucar.edu.
Escape character is '^]'.

This will show that access to the server is open on port 112.

If this works, and you still can not serve data through the
server, the next thing to investigate is if the client is asking
for a compression method that is supported on the server side.
This used to be a real gotcha in McIDAS versions prior to 2004/5 since
the only compression method used to be use of 'compress', and 
a 'compress' executable was not always available on the machine
running the ADDE server.  In v2004 GZIP compression was introduced
AND building of gzip/gunzip was bundled in with the McIDAS distribution.

Back to your original question/problem.  I think that you were trying
to understand why your DSINFO command was not working, and the reason
was that you were specifying the ADDE server machine name in the
DSINFO command line when you should have been specifying the ADDE
dataset group name.

Please let me know if this helped...


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: CNL-142507
Department: Support McIDAS
Priority: Normal
Status: Closed

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.