This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>From: Michael Voss <<address@hidden> >Organization: SJSU >Keywords: 200001181849.LAA08980 McIDAS-X NLDNPLT Mike, >>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. >I completed those steps you mentioned above, and what would you know, it all >seems to work just fine. I took a quick look and see that you had not changed the items that related to setting up the McIDAS remote ADDE server. Even though you might not be using this facility yet, you will in the future. The changes are small; take little time to do; and only have to be done once. The first two changes are included at the beginning of this email. The next change requires that you edit the ~mcidas/data/LSSERVE.BAT file and change the AREA numbers for various data sets (e.g., RTIMAGES/MOLL-IR, RTIMAGES/MOLL-WV, RTIMAGES/GW-VIS, RTIMAGES/GW-IR, and RTIMAGES/GW-WV). As I read the entries in your routing table, the modifications you need to make in LSSERVE.BAT will look like: DSSERVE ADD RTIMAGES/MOLL-IR AREA 5400 5423 "Mollweide Composite IR DSSERVE ADD RTIMAGES/MOLL-WV AREA 5300 5323 "Mollweide Composite H2O DSSERVE ADD RTIMAGES/GW-VIS AREA 5200 5225 "GOES-West Western US VIS DSSERVE ADD RTIMAGES/GW-IR AREA 5000 5024 "GOES-West Western US IR DSSERVE ADD RTIMAGES/GW-WV AREA 5100 5124 "GOES-West Western US H2O After editing LSSERVE.BAT, you make the mods active by running the following from a McIDAS-X session run as 'mcidas': BATCH LSSERVE.BAT >Thanks for your help, I'm really glad you logged on >and exposed some serious problems which, left unresolved, were sure to bite me >in the %#@A! at a future date. No problem. Glad to help. >The SYSKEY and ROUTE.SYS have always been a bit confusing for me. Yes, they are less than obvious (to say the least). >And, thanks for letting me make the changes, that helps >me learn (slowly) how this thing works. OK. One more thing: I noticed from the routing table that you were at one time running ROUTE PostProcess BATCH files to produce composite imagery (GOES-East/West and topography composites). These are currently not active, but I don't know if that is by design, or by accident. Since they were working, I assume that you know how things work. I did notice, however, that the Bourne shell script, batch.k, had not been copied to the ~ldm/decoders directory (to accompany mcscour.sh and xcd_run which are already there). To setup this processing again, I recommend: <login as 'ldm'> cd decoders cp ~mcidas/bin/batch.k . <edit batch.k and set MCDATA, etc. like you did in mcscour.sh and xcd_run) Since ~ldm/decoders is in ldm's PATH, and since entries in /data3/mcidas/ROUTE.SYS have been setup, then creation of the composites should resume. >Cheers, Talk to you later... Tom