20010101: McIDAS FRNTDISP probs (cont.)

>From: address@hidden
>Organization: SMSU
>Keywords: 200012301857.eBUIvlo29945 McIDAS-X 7.7x FRNTDISP

Bill,

re: Windows use at SMSU
>Yes, we are essentially a Windows shop.  
>
>If you have a version that can exist on a machine with 1GB disk, I'm 
>interested now.  If not, we'll try again in a couple of years or when my 
>AIX boxes break (could actually  be rather soon).

1 GB of _free_ disk space, or a system that only has 1 GB of disk?  This
may be academic since Interix requires a good bit of room and so does
an X windows package like eXceed.

re: XCD setup continued
>I wish to continue the discussion, simply for my own edification (also, 
>nothing is simple...see below).

OK.

>I note that the RTWTEXT has been set to LOCAL-DATA rather than 
>cirrus.smsu.edu....

For the 'mcidas' account this should not make a difference if everything
else is setup OK.

>all this is very foreign and mysterious to me.  I haven't done my 
>assigned reading yet.

OK.

>But just for grins, on a slow, cold New Years, I tried to brainlessly type
>in the items you suggested...here's cut and paste from the text window:
>
>DATALOC ADD INFO ADDE.UCAR.EDU                                                
>   
>Group Name                    Server IP Address                               
>--------------------         ----------------------------------------         
>DATALOC -- done
>DSINFO T INFO                                                                 
>    No Datasets found of Type: TEXT  in Group: INFO                           
>   
>DSINFO -- done

This shows that something is setup incorrectly.

>OK, so try this:
>
>DATALOC                                                                       
>Group Name                    Server IP Address                               
>--------------------         ----------------------------------------         
>RTWXTEXT                     
><LOCAL-DATA>                                       
><LOCAL-DATA> indicates that data will be accessed from the local data director
> y.
>
>
>I infer that I have pretty much buggered the XCD data setup.  OK, sooo, I 
>read a few batch files, and find LOCDATA.BAT...which I KNOW I've executed 
>in following the XCD installation directions...OK, so I BATCH LOCDATA.BAT,
>and it gives all the usual, appropriate responses as it creates datasets, 
>then:
>
>DATALOC                                                                       
>   
>Group Name                    Server IP Address                               
>--------------------        ----------------------------------------          
>RTWXTEXT                     <LOCAL-DATA>                                     
><LOCAL-DATA> indicates that data will be accessed from the local data 
>directory.
>DATALOC -- done                                                                
> 
>I'll let you figure out what I've done wrong.

The environment variable setting in the ~mcidas/.kshrc file was incomplete.
I modified it so that the McIDAS setup section now reads:

# Defines for McIDAS-X
umask 002
export MCHOME=/home/mcidas
export McINST_ROOT=$MCHOME
export MCDATA=$MCHOME/workdata
export MCPATH=${MCDATA}:$MCHOME/data:$MCHOME/help
export MCGUI=$MCHOME/bin
export MCTABLE_READ="$MCDATA/MCTABLE.TXT;$MCHOME/data/ADDESITE.TXT"
export MCTABLE_WRITE="$MCHOME/data/ADDESITE.TXT"
export XCD_disp_file=$MCDATA/DECOSTAT.DAT

Your previous settings resulted in the objects of DATALOC ADDs being
correctly added to ~mcidas/data/ADDESITE.TXT, but there was no
MCTABLE_READ, so your session would not read the file to the the
DATALOCs.

I then logged off and back on to make the changes active in my session.
I then did some tests:

cd workdata
dataloc.k LIST

Group Name                    Server IP Address
--------------------         ----------------------------------------
BLIZZARD                     ADDE.UCAR.EDU
CIMSS                        CIRRUS.SMSU.EDU
INFO                         ADDE.UCAR.EDU
MYDATA                       <LOCAL-DATA>
RTGINI                       ADDE.UCAR.EDU
RTGRIDS                      ADDE.UCAR.EDU
RTIMAGES                     ADDE.UCAR.EDU
RTNIDS                       CIRRUS.SMSU.EDU
RTNOWRAD                     CIRRUS.SMSU.EDU
RTPTSRC                      ADDE.UCAR.EDU
RTWXTEXT                     ADDE.UCAR.EDU
TOPO                         CIRRUS.SMSU.EDU
WSINIDS                      <LOCAL-DATA>

<LOCAL-DATA> indicates that data will be accessed from the local data directory.
DATALOC -- done

This looks good.

Next up was to check on the frontal data in RTWXTEXT.  To investigate this,
I did the following:

cirrus:/home/mcidas/workdata> mcenv
 cannot locate string names - rerun setup.
Beginning Image Data transfer, bytes= 77648
 cannot locate string names - rerun setup.
 cannot locate string names - rerun setup.
 cannot locate string names - rerun setup.
 cannot locate string names - rerun setup.
 cannot locate string names - rerun setup.
 cannot locate string names - rerun setup.
IMGDISP: loaded frame  1
EG;MAP H
imgdisp.k: done
 cannot locate string names - rerun setup.
Erased graphic frame(s) 1-1, panel(s) 1-1
EU: Restoring IMAGE.ET     to frame(s)=   1
EU: Done
cirrus:/home/mcidas/workdata>  cannot locate string names - rerun setup.
 cannot locate string names - rerun setup.
 cannot locate string names - rerun setup.
 cannot locate string names - rerun setup.
 cannot locate string names - rerun setup.
MAP: Completed frame 1
                          
cirrus:/home/mcidas/workdata> frntdisp.k OLAY FRAME
FRNTDISP - Begin
 cannot locate string names - rerun setup.
 cannot locate string names - rerun setup.
 cannot locate string names - rerun setup.
 cannot locate string names - rerun setup.
 cannot locate string names - rerun setup.
 cannot locate string names - rerun setup.
 cannot locate string names - rerun setup.
 cannot locate string names - rerun setup.
frntdisp.k:
frntdisp.k: Invalid High Color.
frntdisp.k: first COLOR= argument is too big --> 6
frntdisp.k: Must be valid 'High Color' integer value within range -1 thru -1.
frntdisp.k:

The last error was a strange one, but I later found out that it was due
to a McIDAS session already running as 'mcidas'; see below.

exit

dmap.k Framecirrus:/home/mcidas/workdata> dmap.k Frame
PERM      SIZE LAST CHANGED FILENAME DIRECTORY
---- --------- ------------ -------- ---------
-rw-      3072 Jan 01 10:50 Frame1.0 /home/mcidas/help
-rw-      3072 Jan 02 13:54 Frame1.1 /home/mcidas/help
-rw-      3072 Jan 01 10:50 Frame1.2 /home/mcidas/help
-rw-      3072 Jan 01 10:50 Frame1.3 /home/mcidas/help
-rw-      3072 Jan 01 10:50 Frame1.4 /home/mcidas/help
15360 bytes in 5 files
cirrus:/home/mcidas/workdata> rm -f /home/mcidas/help/Frame*.*
cirrus:/home/mcidas/workdata> dmap.k Frame
PERM      SIZE LAST CHANGED FILENAME DIRECTORY
---- --------- ------------ -------- ---------
-rw-      3072 Jan 02 13:55 Frame1.0 /home/mcidas/.mctmp/110596
3072 bytes in 1 files

The FrameN.M files should never be found in directories outside of
the ~<user>/.mctmp subdirectories.  In the 'mcidas' account on your
system there were several found in ~mcidas/help.  Since this was not
good/wanted, I deleted those there as you can see from the listing.

Next up was finding and getting rid of other files that should only
exist in the ~<user>/.mctmp subdirectories:

cirrus:/home/mcidas/workdata> dmap.k \*.0\*
PERM      SIZE LAST CHANGED FILENAME       DIRECTORY
---- --------- ------------ -------------- ---------
-rw-     58752 Jan 02 13:59 FRAMENH.001    /home/mcidas/workdata
-rw-      3072 Jan 02 13:59 Frame1.0       /home/mcidas/.mctmp/114692
-r--      7656 Jan 02 11:50 SNDSAVE.001    /home/mcidas/workdata
-rw-     45056 Jan 02 13:59 TERMCHAR.001   /home/mcidas/.mctmp/114692
-r--      7656 Jan 02 11:47 UASAVE.001     /home/mcidas/workdata
-rw-     19122 Jun 07  1999 gbtbpds001.0v1 /home/mcidas/workdata
141314 bytes in 6 files

Time to remove the unwanted FRAMENH.001 and TERMCHAR.001 files:

rm FRAMENH.001 TERMCHAR.001

The other files (SNDSAVE.001, UASAVE.001, and gbtbpds001.0v1 (an XCD file)
are OK so I left them.

Oops!  I just noticed that there was a McIDAS session running as 'mcidas'.
My changes should have screwed this session up; sorry.  This session
should be EXITed so that the new environment variable settings in
~mcidas/.kshrc can become active anyway.

>P.S.  I appear to have 19Z surface data and 22Z MDR  available.  SFCCON 
>and DF (I know) can find it with a minimum of effort.  I can also find
>and map a bit of the HRS data, eta in particular.  I'm just confused
>I guess about what DATALOC should report.

See above.  Again, the DATALOC LIST problems were related to
MCTABLE_READ not being defined at all.

OK, I see another problem:

cirrus:/home/mcidas/workdata> ipcs
IPC status from /dev/mem as of Tue Jan  2 14:05:37 CST 2001
T     ID     KEY        MODE       OWNER    GROUP
Message Queues:
q      0 0x4107001c -Rrw-rw----     root   printq
Shared Memory:
m   4096 0x5806094e --rw-rw-rw-     root   system
m1187841   00000000 --rw-------   mcidas  unidata
m 176130   00000000 --rw-------   mcidas  unidata
m 126979   00000000 --rw-------   mcidas  unidata
m 139271 0x0d0640f1 --rw-rw-rw-     root   system
m4988937   00000000 --rw-------   mcidas  unidata
m1605642   00000000 --rw-------   mcidas  unidata
m 827403   00000000 --rw-------   mcidas  unidata
m 262156   00000000 --rw-------   mcidas  unidata
m 192525   00000000 --rw-------   mcidas  unidata
m  86030   00000000 --rw-------   mcidas  unidata
m  94223   00000000 --rw-------   mcidas  unidata
m  24592   00000000 --rw-------   mcidas  unidata
m  16401   00000000 --rw-------   mcidas  unidata
m  69651   00000000 --rw-------   mcidas  unidata
m  24597   00000000 --rw-------   mcidas  unidata
Semaphores:
s   8192 0x5806094e --ra-ra-ra-     root   system
s      1 0x620641e0 --ra-r--r--     root   system
s   4098 0x4406094e --ra-ra-ra-     root   system
s      3 0x01064158 --ra-------     root   system
cirrus:/home/mcidas/workdata> ls -al ~/.mctmp
total 24
drwx--S---   3 mcidas   unidata      512 Jan 02 14:01 ./
drwxrwsr-x  25 mcidas   unidata     1536 Jan 02 13:21 ../
drwx--S---   2 mcidas   unidata      512 Jan 02 13:49 176130/

The fact that the first listing shows a lot of shared memory segments
owned by 'mcidas' while there is only one entry in ~mcidas/.mctmp
(the subdirectory names in ~mcidas/.mctmp are the shared memory
handles for McIDAS sessions) shows that there have been a number
of aborted McIDAS sessions for which the shared memory segments were
never properly cleaned up.  This will eventually cause your system
to run out of shared memory.

The solution to the shared memory segment glut is:

o EXIT all McIDAS sessions running as 'mcidas'
o verify that all subdirectories of ~mcidas/.mctmp are gone
o remove all of the shared memory segments owned by 'mcidas'; for
  instance:

  ipcrm -m m1187841 -m 126979 -m 4988937 -m etc.

After we clean up these things, we can revisit the XCD decoding.  I
believe, however, that the missing front information through ADDE was
solved when I modified your .kshrc file (I also made gratutious
changes to ~mcidas/.mcenv).

From address@hidden Tue Jan  2 12: 27:47 2001

>You can safely ignore yesterday's e-mail (jan 1 2001) from me.
>ADDE stuff was truely flakey on cirrus.smsu.edu, so I hit the
>mcidas e-mail archives on DATALOC and found a reference to NIS.
>Yes, we run (ran) that.  Turning off NIS brought ADDE to life.

This would not, however, explain the DATALOC listings that you sent.

>I'll get back to you when I have some intelligent questions to ask,
>but for now, consider us functional.

Please let me know if the above comments make sense to you.

Tom