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

[McIDAS #GYT-719991]: Interesting batch file errors

Hi Paul,

Sorry for the silence... it has been quite busy here lately!

re: environment created by 'mcenv'

> I understand this. The problem is that it does not happen *every* time.
> 
> This is the important part of the kickoff script that establishes mcenv:
> 
> mcenv -f 2@600x800  -g 16 << EOF
> /home/scripts/mcidas2/radarcomps/remaprad.pl
> /home/scripts/mcidas2/radarcomps/createradarcomps.pl
> exit
> 
> So you see, the graphics switch is set to 16.

Yup, this looks good.

Is there any part of your Perl scripts (assuming that the .pl suffix is 
indicating
a Perl script) that creates a new shell?

re:

> I am wondering if the environments are getting confused?

Perhaps, but each environment should have its own private copy
of User Common.  If User Common were shared, then things being
done in one script could well affect things done in the other
script.  But, given that the scripts are run sequentially, it
is hard for me to understand how this interference could happen.

re: some McIDAS commands fork off additional commands that can run
after the parent command has exited.  The command that does this
the most obviously is IMGDISP where the actions run from the
REFRESH= keyword are spun off asynchronously.

> Ah ha....I will try this to see if things change. Nope...still have
> problems.The same ones. I have (apparently random) the errors concerning
> the lack of image and the WWDISP errors.
> 
> BTW I had this in the batch file::
> :CONTINUE
> MAP H 14 GRA=1 IMA=1
> FRMLABEL IMA=1 "NEXRAD 1KM MOSAIC (DAY)  (HHMM)
> BAR COLOR=16 SU=MYBREF GRA=1
> ZA 6 7 C GRA=1 POS=8 700 "NEXLAB-College of DuPage
> ZA 6 12 L GRA=1 POS=5 789 "$T
> 
> OS "sleep .2s
> FRMSAVE 1 /home/apache/climate/sirvatka/rad/%4.rad.gif

OK.  I don't think that any of the above commands do things
asynchronously.  And, I think that using 'sleep' run from
an OS command should work the same way as WAIT.  But, just
to be sure, you could try using WAIT directly and waiting
more than a fraction of a second.

re:
> WWDISP NAV=C WID=1 COL=5 6 5 6 12 12 1 7 7 9 16 PLO=NBOX WLI=YES
> OS "sleep .2s
> FRMSAVE 1 /home/apache/climate/sirvatka/rad/%4-ww.gif
> 
> EG 1
> BAR COLOR=16 SU=MYBREF GRA=1
> OS "sleep .2s
> FRMSAVE 1 /home/apache/climate/sirvatka/rad/overlays/%4-ww.gif
> K
> OS "sleep .2s
> EG 1 LEV=16
> WWDISP NAV=C WID=1 COL=5 6 5 6 12 12 1 7 7 9 16 PLO=NBOX WLI=YES
> OS "sleep .2s
> FRMSAVE 1 /home/apache/climate/sirvatka/rad/overlays/%4-ww2.gif
> K
> OS "sleep .2s

re:
> Notice I used OS "sleep instead.

Yup, I noticed. What happens if you increase the sleep from 0.2 to
1 or 2 seconds?

re:
> Quite baffled

Me too.  The typical problem encountered is when a command that spawns
off other commands exits before the spawned commands are finished. This
can result in unexpected results that sound a lot like yours.  One that
I ran into early on was a FRMSAVE being executed before the actions
in an IMGDISP REFRESH= keyword sequence were finished.  That is why I
moved all of my MAP, BAR, etc. executions to after the IMGDISP in
my scripts.  I also added a WAIT before each FRMSAVE just to make
sure that the previous action(s) had completed before capturing the
results.

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: GYT-719991
Department: Support McIDAS
Priority: Normal
Status: Closed