[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20010101: McIDAS FRNTDISP probs (cont.)
- Subject: 20010101: McIDAS FRNTDISP probs (cont.)
- Date: Tue, 02 Jan 2001 13:20:50 -0700
>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