>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.