20000811: Problems with MCENV under a shell script... (cont.)

>From: McIDAS <address@hidden>
>Organization: University of Puerto Rico
>Keywords: 200008111642.e7BGgYN02913 McIDAS-X scripting

Karli,

re: figured you were gone
>Hehe, nope! I'm still around... I've been away for a while, and it's
>hard for me to manage the machine regularly.

OK.

>Also I managed to fix most
>of our ADDE problems with our mcidas accounts and the other accounts
>too, we still have a few problems though, and I've been working on this
>project recently and ran into this problem.  That's why I wrote when I
>did since it's of the highest priority (using my limited McIDAS and perl
>skills I'm building a page for our site).

OK.

>   I have not tried out the changes but I think they should work. 
>Originally I thought all of the processes ran linearly, I guess they
>don't.  

Right.

>(Is there any way to force them to be as such?)

Instead of kicking off the MAP and BAR commands from the REFRESH= keyword
of IMGDISP, you could run them individually AFTER the IMGDISP invocation.

>I will let you know what happens when I do. I'll discuss the other
>problems below...

OK.

>Which command sets up the loop then?

LB (lb.k) sets up loops of contiguous frames.  LS (ls.k) sets up loops
of contiguous or random frames.

>All I did basically was cut & paste
>the commands, and evaluate the strings.  This brings me to another
>question: Is there a way to make McIDAS wrap the text (particularly the
>one printed after a Menu option is selected or a user-defined image is
>displayed) in its screen so that you can copy/paste them easily?  

No, but you can make your Text window wider so that you don't have
to scroll to see all of the command.  You scroll right by use of the
<ALT>-]  (alt close square bracket); you scroll left by use of the
<ALT>-[.  You can also open a file into which all commands are saved
automatically.  Please review the online help for the command TFILE
(and watch to make sure that you don't open a file and never close
it; it could be come large depending on what you are doing).

>I have also had a problem getting my scripts to recognize the String
>Table. It doesn't want to evaluate strings, but I think this problem
>might be due to more to the fact that I didn't include the environment
>variables within the script. Am I right?

Yes, exactly.  You _must_ define MCPATH at the very least.  I strongly
recommend that you define MCDATA; make it the first directory in
MCPATH; and cd to it in your script.  The reason for this is that
you will then correctly pickup the file REDIRECTions that are defined
in LWPATH.NAM.

re: getting compressed ADDE transfers to work
>Compressed data transfers? I think I vaguely remember those, they
>probably have not been fixed.

The client (the application requesting data from a server) determines
the transfer mode of the data from the server.  If the user has the
environment variable MCCOMPRESS defined in his/her environment, then
the server will compress data before sending it, and the client side
uncompresses it upon receipt.  This makes it much quicker to look
at data on remote systems/networks.

>If you could send me commands to try them
>out I'd appreciate it.

This is the problem.  The last time we had email exchanges, your
ADDE server setup was not able to send data back in compressed form.
I sent you an email about this, but it was apparently at the beginning
of when you weren't going to be there.

To test things, do the following:

o start a McIDAS-X session and run any ADDE command that requests data
  from your own server

  From what I can tell, this should work fine.

o exit the McIDAS-X session

o define MCCOMPRESS (can be defined to anything at all; it just has to
  be defined

o start a McIDAS-X session and try the exact same command that you did
  before.  If this doesn't fail, then things are working.  If it fails,
  it is likely that the environment in which the server is running
  (i.e. the PATH that is in effect when server commands run) does not
  include the directory that contains the 'compress' executable.

>I've also tried the code below and I get stuck
>in the IMGDISP because McIDAS complains that the can't locate the
>station KSJU:
>IMGDISP: Cannot locate
>KSJU                                                          
>IMGDISP:
>done                                                                        
>which makes no sense, but what do I know?

OK, so try any station that does work, or try specifying the load point
using the Latitude and longitude.   The command using LATLON to specify
the load center would look like:

SF 1
IMGDISP RTGINI/GPR1KVIS LATLON=18:26 66:00 EU=IMAGE MAG=-3 REFRESH='EG;MAP H 9'
SF 2
IMGDISP RTGINI/GPR1KVIS LATLON=18:26 66:00 EU=IMAGE MAG=-2 REFRESH='EG;MAP H 9'
SF 3
IMGDISP RTGINI/GPR1KVIS LATLON=18:26 66:00 EU=IMAGE MAG=1 REFRESH='EG;MAP H 9'
LB 1 3
DR 2*5 20
TERM L ON

>Since we've been having
>bandwidth problems (aside from the DNS problems) we reduced out dataset
>down to:
>request MCIDAS "LWTOA3 (1[0145].|2[01])" pluto.met.fsu.edu
>request WMO ".*" pluto.met.fsu.edu
>which I beleive is just US-East satellite images, Radar, and some other
>stuff.

So, you and/or Amos are not on any of the Unidata email lists?  We are
changing the compression for the images in the broadcast from the inefficient
delta encoding scheme that LWTOA3 decodes to a PNG scheme.  You must
download the latest version of the ldm-mcidas to get the new decoder,
pnga2area.  You then will need to:

o change your ldmd.conf request line

o change your pqact.conf entry(ies) for image decoding

o stop and restart your ldm.

>Maybe my ADDE is still misconfigured?

I am sure that it is not 100% done, yes.

>Finally, (sorry to bog you down with so much stuff but I guess i'm
>trying to make up for lost time :) I seem to be receiving Radar images,
>for they are being updated in the Routing Information,

OK, this tells me that you are decoding them into AREA files.

>but after
>selecting them in the menu a Message Box pops up saying "No NIDS images
>found in dataset RTNIDS/BREF1".

The dataset is probably not setup correctly on the server side.

>These are the WSI Radar images entered
>in the ldmd.conf file and I've seen them come down when I do a watch.

Right, but the ADDE side is probably not setup correctly yet.

>Also I'd like to let you know that I'll be shutting down our server
>since there will be a power outage this weekend, Saturday and Sunday. 

OK, I saw that.

>Please wait to reply until Monday for the email will bounce back.  I
>will send another email to support@unidata stating this again in hopes
>that it will be distributed to the other McIDAS users.
>
>Thanks alot for your help!

No problem.  Last time I wrote (the time several months ago) I offered to
troubleshoot your ADDE setup, but I got no reply.  That offer still stands
AND I can help get you going with the new ldm-mcidas decoders.  Please
let me know if you want this help.  If you do, I need logins as both
'mcidas' and 'ldm' on breeze.

Tom