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

19990622: more os2/mcidas & solarisx server (cont.)

>From: alan anderson <address@hidden>
>Organization: St. Cloud State
>Keywords: 199906211923.NAA20658 McIDAS ADDE

Alan,

>Regarding the items you listed above;
>
>The MDX command ran ok this morning, after I used the syntax you listed; 

OK.

>So do the F key menu commands that access upper air data files.

OK.

>UL List continues to give the 'no sounding available message'.

I logged onto your PC and, using c:\mcidas\tools\mcrex.cmd, discovered
why UL is not returning any data.  It is the same reason that the MDX
command was failing: the format of the DAY key in the upper air MDXX
files was changed from YYDDD to CCYYDDD.  The following UL command
will work:

UL LIST 72469 DAY=1999173

We updated UL in our 7.5 release to use the correct DAY format based
on what the MD file DAY key looks like.  The other thing that was updated
in 7.5 was the format of the date string avaliable in the string table.
For version previous to 7.5, Y (the date) would look like:

99173

This is how your system presents Y.  For versions 7.5 and above, the
date will look like:

1999173

UL and other routines read the clock to determine the current time.
The then format a McIDAS command specifying things like DAY, and
the MDX search routines look for exact matches.  The match will fail
when DAY in the file is in the form CCYYDDD and the form of DAY specified
on the command line or internally are in YYDDD.

The fix for these kinds of problems is to upgrade to 7.50.

>The Mcidas version is 7.401, with a date of 980820.

This is the reason that UL doesn't work "out of the box".

>The file IDGROUP.EXE 
>does not exist on the disk of this os2 machine.  I  will check on our other
>machines as well as I think we changed to 7.4 at about the same time on all
>of them.  From your earlier comments, I assume that even if IDGROUP.EXE did 
>exist, and XCDCLI.BAT ran successfully, this would not solve our problem.

After thinking about this, and after asking Don, I see that the lack of
IDGROUP.EXE on your system was caused by not loading the XCD component
of the OS/2 distribution.  Since this really shouldn't be necessary for
machines not running XCD for OS/2 (like your OS/2 boxes), it appears
that the batch file XCDCLI.BAT is in error in its inclusion of the
'IDGROUP LIST' command.  The good news is that this is the very last
line of XCDCLI.BAT, so all things before it have been executed
correctly.

>The machine we are dealing with on these items has the name  56F and 
>IP of 199.17.31.12; ...

Thanks this helped cut though a couple of problems quickly.

>Will using DATALOC to point to waldo for the datasets change the transfer
>speed for F key menu commands the way that it does for command line entries?

Only for those menu functions that have been upgraded to use of ADDE routines.
I looked through the UNIDATA.MNU menu template on your OS/2 box and see
that some things have been upgraded to use of ADDE routines, and some
have not:

Display type          ADDE (Y/N)
---------------------+-------------
image load            N
grid display          Y
front display         N
cross sections        N (no ADDE routines yet available)
surface data plotting N
fous14 plotting       N
etc

The upshot is that to use this menu, you will have to access files
locally (e.g. via NFS).

>I assume 
>that it does not as the image files already point there.

The image loading from the Fkey menu is through ALOOP which calls DF
which is not an ADDE routine.

>Even if the issues of transfer speed

This one is a puzzler.  We have lots of experience with folks doing just
what you are doing, and they do not see the excessive times to do things
like image loads.

>(apart from ADDE) and the failure of some
>commands

The reason for this is now known.

>are not resolved, I think we will begin the process of changing to 
>mcidasx.

I think that this might solve a couple/several of your problems:
access to data on NFS mounted file systems should certainly be much faster
and you will be upgrading to a release of McIDAS that is matched to
the release of McIDAS-XCD on waldo.

>I assume we go through the process similar to waldo, execept we will
>not be setting up an ldm; install solarisx first, then mcidasx.

Right.

>Thanks

Sorry for your problems.  At least we undstand most of them now.

Tom