20000127: URGENT! Batches won't work!

>From: Anthony James Wimmers <address@hidden>
>Organization: UVa
>Keywords: 200001271731.KAA26534 McIDAS RoutePP BATCH

Tony,

>I only mean to sound alarmist because it's really important when there's a
>break in the the stream of products we're providing for TOPSE, and this is
>a major one at that. 
>
>I noticed this morning that when starting Mcidas, I got an error at the
>command line:
>
>windfall: /home/ajw7g $ mcidas
>windfall: /home/ajw7g $  cannot locate string names - rerun setup.
> cannot locate string names - rerun setup.
> cannot locate string names - rerun setup.
 ...

This typically happens when one or more things goes wrong in the environment
in which the batch file is trying to run:

o STRTABLE can not be found or can not be READ
o there is one or more files that should only exist in the .mctmp/nnnn
  directory that is now located in one (or more) of the directories in
  the MCPATH that defines the environment
o .mctmp can't be written to
o the shared memory system is munged (I have see this happen on windfall
  before)

>windfall: /home/ajw7g $ 
>
>And I noticed that since between 8:30 and 9:30 EST this morning,
>each automatic batch (IR8.BAT, GRIDC.BAT, etc) generates the same error.

OK, sounds like a STRTABLE location/read problem.

>I don't know what the error message is referring to.

"string names" refers to STRTABLE entries.

>At the same time, I see that Mcidas doesn't recognize the DEFAULT.NAM
>settings. If I type 
>
>REDIRECT LIST                                                                 
>       
>
>Then I get nothing:
>Number of active redirection entries=0                                        
>REDIRECT: Done                                                                

This says that the LWPATH.NAM file has been overwritten or munged.  The
copy of LWPATH.NAM that should be used by a McIDAS-X session for the
user 'mcidas' should be in ~mcidas/workdata.  To scope out the problem,
you should do the following in the McIDAS-X session:

DMAP LWPATH

and send me the results.

>And I get the same result if I try to restore DEFAULT.NAM:
>
>REDIRECT REST DEFAULT                                                         
>        
>Restored DEFAULT.NAM  to active redirection file                              
>        
>Use LIST option to view redirected files                                      
>        
>REDIRECT: Done                                                                
>        
>REDIRECT LIST                                                                 
>        
>Number of active redirection entries=0                                        
>        
>REDIRECT: Done                                                                

OK, this sounds like your session somehow is trying to refer to a copy
of LWPATH.NAM in which it does not have write permission.

>As a result, none of the batches can find their files.

I understand.

>As far as I can tell, no one was at the workstation between 8:30 and
>9:30 today, so I don't know how this could have possibly been started
>either.

Probably by an errant process.

>Thanks for your help,

If your quick troubleshooting doesn't turn up the problem, please give
me that login so that I can jump in and help.

>Tony

By the way, congradulations on winning the award for your poster presentation
at the Long Beach AMS show.

Tom

>From address@hidden  Thu Jan 27 11:16:51 2000

Ne-ver-mind. We discovered that the problem was that the partition was
full. Sorry to bug you.

-------------------------------------------------------------
Tony Wimmers
Department of Environmental Sci., University of Virginia

>From address@hidden  Thu Jan 27 13:17:21 2000

re: never mind
OK, so I should have looked forward in the support inbox, but your
message screamed URGENT! at me and I panicked :-).  The fact that
the partition was full meant that LWPATH.NAM couldn't be written, so
that is why the REDIRECT REST DEFAULT.NAM failed.

Tom

>From address@hidden  Thu Jan 27 13:29:29 2000

re: OK, so I should have looked forward in the support inbox, but your
message screamed URGENT! at me and I panicked :-).

>In fact, I was afraid that that would happen. Next time if I want to nix a
>message, I'll call.

Tony