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

19990208: McIDAS-X build error on AIX

>From: address@hidden
>Organization: SMSU
>Keywords: 199902082342.QAA27095 McIDAS-X

Bill.

>I've made mcidas7.4 on my AIX 4.2 box using the vendor's 
>compilers.  All, finally, seems to be running...XCD, new
>ldm-mcidas.  But there are a few problems:

Nuts.

>Oh, BTW, before I start with 'problems', since a lot of the ADDE
>stuff was greek to me, I basically added the lines to .mcenv, set
>up a user account (ADDE), and that's all...just for reference.

Did you go through our web pages on how to build, install, and configure
the new distribution?

>1) Not a problem, but:
>
>Fortran died on profsect.f, line 873 (in the integer function)...
>looks like it didn't like the line:
>c      labinc = max0((pixlen+10)/dx,2)          ! set time labeling 
>increment
>
>because of the dx...was converting it to real.  From makelog:
>
>f77 -c -O -qextname -qextern=abort -qcharlen=4096 -I. profsect.f
>** main0   === End of Compilation 1 ===
>"profsect.f", line 873.21: 1513-041 (S) Arguments of the wrong type were 
>specified for 
>the INTRINSIC procedure "max0".
>
>I wrote in a little kludge with a new integer variable to replace dx
>and it compiles ok.  

This is a bug since the arguments to MAX0 should all be integer. I just
changed the code to be:

      labinc = max0(int((pixlen+10)/dx),2)         ! set time labeling increment

The fix will go into the next bugfix update.

>2) ldm-mcidas didn't make on my machine.  If anyone wishes to try it, 
>I'll hand out passwords.

I will want to look at this carefully since it does build on our AIX machine
here at Unidata.  When I will be able to get to it is another question,
however.

>I ended up installing the binaries you supply
>(they're AIX 4.3 and I am 4.2...so tried to be exquisitely precise about
>versions...oh well, the 4.3 binaries seem to work fine...)

I'm glad to hear that these work.

>3) Two problems:
>       a. when mcidas logs a new AREA file, it kicks off an appropriate
>           postprocess BATCH file (e.g., VIS8.BAT) into which I insert a
>           line to run some of my own map-making BATCH stuff...
>           but the environment mcidas utilizes is its default, not mine
>           so frames end up 640x480 rather than 1000x750. BTW...this is a new
>           problem "it never did this before".   Other batch
>           jobs initiated by cron (modeled on your mcscour.sh) explicitly
>           set the mcenvironment and work fine.

This should be the same in 7.4 as in 7.1.  What happens in the ROUTE PP
BATCH stuff is:

o the LDM runs an ldm-mcidas decoder, lwtoa3 in this case
o the environment in which the LDM runs should be setup so that the
  Bourne shell script, batch.k, (included in the ldm-mcidas
  distribution) is locatable through PATH
o the environment in which the LDM runs should have NO McIDAS environment
  information (e.g. MCDATA, MCPATH, PATH should not contain ~mcidas/bin,
  etc.)
o the script batch.k gets run by the ldm-mcidas decoder (when McIDAS
  runs BATCH, it really runs an executable named batch.k)
o the Bourne shell script batch.k needs to define McIDAS environment
  information (e.g. MCDATA, MCPATH, PATH which _does_ contain ~mcidas/bin,
  etc)
o at the very end, either the "real" McIDAS BATCH command (~mcidas/bin/batch.k)
  is run directly or the McIDAS environment setter 'mcenv' is run

In order to set the number of frames AND/OR the frame size(s) to be used in
the PP BATCH invocation, you have to setup the Bourne shell script as
follows:

MCPATH=$MCPATH PATH=$PATH LD_LIBRARY_PATH=$LD_LIBRARY_PATH mcenv -f 16@480x640 
$command

The -f flag to mcenv sets the number and size of the frames to be created
for the PP BATCH invocation.  In your case (assuming that you are only
wanting to deal with one 1000x750 frame, you would put:

MCPATH=$MCPATH PATH=$PATH LD_LIBRARY_PATH=$LD_LIBRARY_PATH mcenv -f 1@1000x750 
$command

After you make this change, you should get the correctly sized frame.

>(I've got to get out of that constraining tight margin setup)
>
>b. a Mcbasi script does a 
>KEYIN "FONT SET COUMR
>KEYIN "PC T " R,C
>KEYIN "ZA 2 15 X GRA="G"  {"  " " A$" " Y " " T "Z " B$" "C$" "D$" "E$" 
>"F$
>to label frames with user-initiated strings....
>font set COUMR used to produce a nice Times-Roman (???) typeface, now
>in BATCH files we get a stick font (could in fact be real courier)....

Hmm...  "stick font" sounds like the McIDAS default.  It sounds like
your FONT SET COUMR command is not taking effect globally like I _think_
it should.  FONT= is no a global keyword, so a quick workaround would
be:

REM KEYIN "FONT SET COUMR
KEYIN "PC T " R,C
KEYIN "ZA 2 15 X GRA="G" FONT=COUMR {"  " " A$" " Y " " T "Z " B$" "C$" "D$" 
"E$" "F$

Now that I think about it, since the ZA keyin is not a descendant of the
FONT SET sequence, you should get the McIDAS default.  If you want the
FONT setting to be active across all of the KEYINs in the McBASI script,
you should add a FONT= keyword sequence to the McBASI script invocation
(e.g. RUN FONT=COUMR FILE=...)

>if I initiate mcidas from the console and clip out a line from one of
>my batch files that calls this script, the first time through I get the
>stick font (or courier), the second time through I get my nice 
>Times-Roman font.

This confirms my conjecture.  After FONT SET is run, it becomes the
global setting from that point on.

>I realize you folks have added new, higher-horsepower
>ways of labelling frames, but I've gone on the assumption, that "if it
>ain't fixed, don't break it" or something like that. 

Right.  The fix here, however, should be quick and easy.

>And once again, thank you for your support.

No problem.  Talk to you later...

Tom