[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20000127: URGENT! Batches won't work!

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


>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

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


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

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.


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


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


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


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.