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

19990603: mcidas-os2 and waldo at stc

>From: alan anderson <address@hidden>
>Organization: St. Cloud State
>Keywords: 199906031537.JAA20463 McIDAS-OS2

Alan,

>After reading in the solaris documentation, plus your message, I have a
>successful mount of our os2 machine to waldo's data directory.  We can
>look at this directory on waldo (/var/data/mcidas) and see all the
>files that have been created.

Very good.

>Back on the os2 machines (running mcidas ver. 7.401) the performance is
>spotty.  One or two terminals seem to be ok, but with very slow
>execution of image loads, much slower that when the same image was
>brought over from hobbes.

This may mean that you need to change the buffering parameters on the
OS/2 side for the NFS mount.

>These machines (pc's, hobbes, waldo) are all
>in the same building and on same branch of our campus net so I don't
>understand this reduction in speed.  It is too slow for practical use.

Tuning the mounts from the OS/2 side _should_ help.  Is it possible
that the mount command you were using for hobbes was tuned for AIX?
I recall that SSEC pointed out to me a long time ago that one had
to setup the input and output buffering for AIX much differently than
for other operating systems.

>The first machine that we mounted to waldo has other problems as well
>as the slow image load; my initial guess was maybe the REDIRECT process
>needs to be changed in light of the more numerour files available from
>waldo.  So, edited EXAMPLE.NAM to uncomment just about everything.

>I assume waldo is creating all the files referenced in EXAMPLE.NAM, with
>the exception of lightning and nids stuff for us.

Right.

>I restored the
>example.nam file, and got the expected change when typing REDIREC.LIST
>but have not noticed much change.

I assume that you can list out the information on images, etc. using
the non-ADDE routines LA, MDU, and MDL.  True?  Is this very slow?

>Some specifice examples of the problems are listed below.
>
>  1. Using the mcidas fkey menu, F6 should get me weather text (from the
>     unidatas file?) the command screen showed 
>     RUN-STOP at statement 90

Did you verify that the REDIRECTion to UNIDATAS was valid?  Did you
verify that the copy of UNIDATAS has data in it?

>  2. Tried to get an 850 mb temp plot, from upper air data.
>     The background map and caption plotted ok, command screen showed:
>     UPC T 850 ....
>     GU  table data
>     GU DONE
>     --MDX --INVALID PARAMETER T
>     MDX: PROGRAM CALLED ABORT
>
>The strange part is that a couple of other os2-pc's have not shown the
>same problems noted in 1. & 2.

Hmm...  Getting the INVALID PARAMETER T message from MDX is strange all right.
Try doing:

TD ALL

on the machine that is producing this error.  It could be that string
table values are inconsistent.  This would explain why other OS/2 machines
don't give the same error.

>Concerning our data, I think unl may still be having problems with
>sending us the MCIDAS stream.  I have not checked with Clint yet, but
>hobbes shows only a few image files from yesterday afternoon through
>this morning, so although he made some changes yesterday, it looks like
>the problem may be back.

OK, you should relay this information to Clint.

>I have assumed that waldo is creating its
>surface and upper air MD files, as well as the text products from
>DDPLUS|IDS and so should not be affected by the MCIDAS stream problem
>for these.

Right EXCEPT for the UNIDATAS file.  This comes from the Unidata-Wisconsin
feed.

>I will email Clint re the MCIDAS data problem.

OK.

>One last note;  when we log in as root on waldo, we get a desktop that
>is really spartan; several of the drop-down menus have things left out,
>and even the colors are very limited.  Logging in as ldm or mcidas
>results in a 'normal' desktop.  Any ideas?

What is included in CDE menus is configurable on a user-by-user basis.
It is not suprising that the environment for 'root' is significantly
different from other users.  As to why the colors are limited, it may
be that some applications that use a lot of colors are being started
in 'root's CDE session (like the file manager).  The allocation of
colors in CDE is configurable through the Color selection available in
the Style Manager.  Click on the mouse/Ttt/palette icon in the CDE
bar and then select the color palette icon.  You should see a button
with "Number Of Colors..." on it; this will allow you to change how
the colors are allocated:

O More Colors for Desktop
O More Colors for Applications
O Most Colors for Applications
O Black and White
O Default

I run my CDE session with "More Colors for Applications" and do not
run the File Manager.  BTW, the settings for CDE should virtually
identical between Solaris and AIX.

>Thanks in advance

In order to troubleshoot your OS/2 problems, it might be useful for
me to get a logon to the offending machine so that I can poke around.

Tom