>From: Michael Voss <<address@hidden>
>Organization: SJSU
>Keywords: 200001181849.LAA08980 McIDAS-X NLDNPLT
Mike,
>My MD files go to /data3/xcd and I believe they are being scoured correctly
Oops, my bad. I saw a bunch of MDXX files in /data3/mcidas and figured that
that is where you were storing them. I see now that you are dealing with
them in /data3/xcd. I also looked at the setup in ldm's crontab for
the scouring and don't see any problems. My apology for jumping the gun.
I would suggest that you free up some disk space by deleting all of the
MDXX files in /data3/mcidas. While you are doing this, I suggest other
mopping up operations:
<login as mcidas>
o there are lots of XCD data files in ~mcidas/workdata. Since you are
doing your XCD decoding in /data3/xcd, I would delete these:
cd workdata
rm *.IDX
At the same time, there are some files in workdata that should never
be there:
rm *.001 SYSIMAGE.SAV
o there are files in /data3/mcidas that should not (no longer) be there:
cd /data3/mcidas
rm SCHEMA SCHEMA.bak (SCHEMA needs to be in /data3/xcd, not here)
rm STRTABLE GRID000[12] GRID010[12] MDXX*
There are also lots of AREA files that are very old. It looks like
you changed how many images you wanted to keep by altering the
routing table, ROUTE.SYS, and did not remove the old images
o the definitions for MCTABLE_READ and MCTABLE_WRITE in ~mcidas/.mcenv
are incorrect.
You have:
MCTABLE_READ="${MCDATA}/MCTABLE.TXT;/export/home/mcidas/data/ADDESITE.TXT"
MCTABLE_WRITE="/export/home/mcidas/data/ADDESITE.TXT"
They should be:
MCTABLE_READ="/export/home/mcidas/mcidas/data/MCTABLE.TXT"
MCTABLE_WRITE="/export/home/mcidas/mcidas/data/MCTABLE.TXT"
This may seem incorrect, but the idea is that these should point to
files that do NOT exist. The reason for this is to circumvent a
circular definition that could occur when using the McIDAS ADDE
remote server.
The definitions for users other than 'mcidas' would have MCTABLE_READ
and MCTABLE_WRITE set like what you have currently.
o while on the subject of the McIDAS ADDE remote server, the entry for
the user 'mcadde' in your /etc/passwd file should have the default
shell set to be '/bin/false'. This means that the 'mcadde' account
is not a login account. This is important for security reasons.
o there are some entries in the REDIRECTion table for 'mcidas' that
don't exist. This can be seen when one uses the DMAP command:
cd ~/workdata
dmap.k MDXX
WARNING: cannot examine directory /var/data/mcidasd: No such file or directory
WARNING: cannot examine directory /var/data/mcidasd: No such file or directory
WARNING: cannot examine directory /var/data/mcidasd: No such file or directory
WARNING: cannot examine directory /var/data/mcidasd: No such file or directory
WARNING: cannot examine directory /var/data/mcidasd: No such file or directory
WARNING: cannot examine directory /var/data/mcidasd: No such file or directory
WARNING: cannot examine directory /var/data/mcidasd: No such file or directory
WARNING: cannot examine directory /var/data/mcidasd: No such file or directory
WARNING: cannot examine directory /home/mcidas/data/tutorial: No such file or
directory
WARNING: cannot examine directory /home/mcidas/data: No such file or directory
WARNING: cannot examine directory /var/data/ldm/surface/front: No such file or
directory
WARNING: cannot examine directory /home/mcidas/data/tutorial: No such file or
directory
WARNING: cannot examine directory /home/mcidas/data/tutorial: No such file or
directory
PERM SIZE LAST CHANGED FILENAME DIRECTORY
---- --------- ------------ -------- ---------
-rw- 17814336 Jan 18 04:29 MDXX0008 /data3/xcd
-rw- 3954892 Jan 18 14:10 MDXX0018 /data3/xcd
-rw- 1456992 Jan 18 14:10 MDXX0028 /data3/xcd
-rw- 4776016 Jan 18 14:21 MDXX0038 /data3/xcd
-rw- 7879048 Jan 18 14:21 MDXX0058 /data3/xcd
-rw- 5950844 Jan 18 14:21 MDXX0068 /data3/xcd
-rw- 30744 Jan 18 14:18 MDXX0078 /data3/xcd
41862872 bytes in 7 files
o while I was checking things out, and after seeing that you now have some
lightning data, I tried running an NLDNPLT test to see if it would
terminate:
cd ~/workdata
nldnplt.k LIG USA
---PLOTTING DONE
This is undoubtedly due to reasonable values existing in SYSKEY.TAB:
cd ~/workdata
sysval.k LIST 2051 2053
SYSKEY Word Value
----------- -----------
2051 = 78
2052 = 200000
2053 = 2000018
sysval.k: Done
The SYSKEY.TAB values are, however, still not being updated as they
should (the original reason for this email :-). Neither is ROUTE.SYS.
I see the problem! There is no copy of ROUTE.SYS in /data3/xcd.
Since there is not routing table to read, nldn2md does not know that
it is supposed to update SYSKEY.TAB values. Additionally, the
read/write permission on /data3/xcd/SYSKEY.TAB is set incorrectly:
-rw-r--r-- 1 mcidas data 24000 Jan 18 12:16 SYSKEY.TAB
This says that only 'mcidas' can update the file.
One thing that is a little tricky (not really) when one tries to keep
McIDAS data files in separate directories (images in one; XCD files
in another) is the need for ROUTE.SYS and SYSKEY.TAB to be in both
directories at the same time. The solution for this is to put
both of them in one directory and then make links for each to the
other directory. Here is what I mean:
<as user 'mcidas'>
cd /data3/xcd
chmod 664 SYSKEY.TAB
ln ../mcidas/ROUTE.SYS .
rm ../mcidas/SYSKEY.TAB
ln SYSKEY.TAB ../mcidas
Now, SYSKEY.TAB will be updated when new images and point source data
is decoded. The end user only has to have a REDIRECTion that points
to one SYSKEY.TAB (and ROUTE.SYS for the user 'mcidas').
>(I
>scoured the MD77's by hand today because of a disk space problem...long
>story).
I can see that you could save some disk space on /data3 by removing
the old MDXX files in /data3/mcidas.
>The ones in /data3/mcidas are left over from my pre-XCD days. I will
>delete those from /data3/mcidas because they serve no purpose other than to
>confuse the unsuspecting (:
Very good.
>Before I give you the go ahead to make changes, maybe log in one more time
>and see if there are any other more sublte inconsistencies in my configuration.
Let me know about the things I listed above. You can get through those pretty
quickly and then see where you stand.
>Thanks,
You are welcome.
Tom
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.