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

20030110: McIDAS IMGREMAP failure from Perl script



>From: "Paul L. Sirvatka" <address@hidden>
>Organization: COD
>Keywords: 200301101430.h0AEU2t18460 McIDAS-XCD REDIRECT

Paul,

>OK we hve the problem solved for the surface data. Must have been
>something screwed up in LDM...
>thanks for the help...

Glad to hear the problem is solved.

>So here is the old problem that we tried to send you in December:
>
>I am having trouble where none had previously existed. We have a series of
>commands one includes a remap.k
>
>here is the output of the debug
>/home/mcidas/bin/imgremap.k* Write to server has failed. Wanted  5120
>/home/mcidas/bin/imgremap.k*                                Did  -1

This sounds like either an ADDE dataset setup problem, or the
output dataset references AREA files that are not writable, or are
in a directory that the user running the script does not have
write permission for.

>We are also experiencing problems with simple cp commands in the
>scripts. It seems the commands are there but nothing is being copied.
>
>Any clues?

A failure of 'cp' really does make it seem like a permission problem for
output directories/files.

>>From address@hidden Fri Jan 10 17:24:56 2003
>
>A bit more info might help...
>
>I have in a script the following command done by user ldm
>
>system("/home/mcidas/bin/imgremap.k NEXRCOMP/1KN0R-NAT SAT.4467 SSIZE=ALL
>DEV=TTF logfile");
>
>Sat.4467 is a GOES east sector...it exists.

Is it writable by the user 'ldm'?

Is the alias 'SAT' known in the environment you are trying to run the
script in?  If not, this may be your problem.

>Now if I run this by LDM in an environment which is OK as ldm (using a
>kickoff structure that sets mcidas environemt variables.)

???  Was something dropped from this sentence.

>If I run that command by hand as McIDAS it works fine...I cannot run it as
>LDM because it gives an error stating that it cannot open source
>directory...

Can't open source directory?  This is not ringing any bells.

>i figure it would not work because the environements are not set.
>
>Here is the kickoff environment:
>
>MCHOME=/home/mcidas
>MCDATA=$MCHOME/workdata
>MCPATH=${MCDATA}:$MCHOME/data:$MCHOME/help:$MCHOME/workdata/cod

This looks correct.  Does 'ldm' have write permission in the $MCHOME/workdata
directory?

>MCLOG=$MCDATA/radar.log
>MCTABLE_READ="${MCHOME}/data/ADDESITE.TXT"

Looks OK

>PATH=$MCHOME/bin:$PATH
>LD_LIBRARY_PATH=/usr/local/lib:/lib:$MCHOME/lib:/usr/lib
>
># export the environment variables so that they can be used
>
>export MCHOME MCDATA MCPATH MCTABLE_READ PATH LD_LIBRARY_PATH
>
>As I said...it used to work...I do not know what has changed!

When something starts failing after working, I always suspect permission
problems.

>It appears to be some sort of permissions problem but we cannot isolate
>it! Please help.

Can I get a login to the environment(s) where you are trying to run the
script?  This would likely speed up the sleuthing process.  Without
seeing all aspects of the problem, I would be simply guessing possibilities.

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.