20050627: [Fwd: Re: FL_WRIT and perror]

Kevin,

I added the perror while trying to track down the limitations
of the pgf77 compilers. Some people wanted to use something
other than g77, and the pgf77 compiler had a limitation that
you could not open the same file more than once (which GEMPAK does).
The perror was necessary to get the 901 translation by the pg compiler.
That was an internal fortran runtime STATUS error, and not the type of thing
ththat the ER_ library would know about.

There was no error message there previously, and you can remove it,
or comment it out as you need for your work.

Steve Chiswell
Unidata User SUpport



>From: "Kevin R. Tyle" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200506271957.j5RJvCNi026217

>This is a multi-part message in MIME format.
>--------------010608080003090905010603
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>Content-Transfer-Encoding: 7bit
>
>Hi Steve,
>
>I'm forwarding this little thread with Scott Jacobs regarding a question 
>I had about FL_WRIT.  It looks like the "perror" line was added in 
>September 2004 by you guys?  Anyway, it seems to be incompatible with 
>the Intel Fortran compiler for Linux, which I am playing with.  Do you 
>think it can safely be removed for future builds?
>
>Regards,
>
>Kevin
>
>--------------010608080003090905010603
>Content-Type: message/rfc822;
> name="Re: FL_WRIT and perror"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline;
> filename="Re: FL_WRIT and perror"
>
>X-Account-Key: account2
>Return-Path: <address@hidden>
>Received: from mocbox2.nems.noaa.gov (mocbox2.nems.noaa.gov [140.90.121.142])
>       by atmos.albany.edu (8.11.7p1+Sun/8.11.7) with ESMTP id j5RJXoe13310
>       for <address@hidden>; Mon, 27 Jun 2005 19:33:50 GMT
>Received: from [140.90.193.205] ([140.90.193.205]) by
>          mocbox2.nems.noaa.gov (Netscape Messaging Server 4.15) with
>          ESMTP id IIRD0E00.CV1 for <address@hidden>; Mon, 27 Jun
>          2005 15:33:50 -0400 
>Message-ID: <address@hidden>
>Date: Mon, 27 Jun 2005 15:33:50 -0400
>From: Scott Jacobs <address@hidden>
>User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
>X-Accept-Language: en-us, en
>MIME-Version: 1.0
>To: "Kevin R. Tyle" <address@hidden>
>Subject: Re: FL_WRIT and perror
>References: <address@hidden>
>In-Reply-To: <address@hidden>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>Content-Transfer-Encoding: 7bit
>X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 
>       cypress.atmos.albany.edu
>X-Spam-Status: No, hits=-2.5 required=8.0 tests=AWL,BAYES_00 autolearn=ham 
>       version=2.63
>X-Spam-Level: 
>
>Kevin,
>
>Things are ok. Not so hot today, but rather humid -- 81 over 72 -- right 
>now.
>
>I don't know where the call to PERROR came from. My copy of FL_WRIT has 
>the following:
>
>IF  ( iostat .ne. 0 )  THEN
>      iret = -5
>ELSE
>      iret = 0
>END IF
>
>PERROR may have been added by Unidata. I would suggest removing it.
>
>Scott
>
>
>Kevin R. Tyle wrote:
>
>> Hi Scott,
>>
>> Hope you're doing well and that you're not roasting away in the torrid 
>> DC summer.  Anyway, I'm trying to build GEMPAK on linux using the 
>> Intel fortran compiler (ifort).  It doesn't  seem to have a "perror" 
>> command, which is causing problems when linking against FL_WRIT.  
>> FL_WRIT has these lines:
>>
>> C
>> C*      Get the GEMPAK file error number.
>> C
>>        IF  ( iostat .ne. 0 ) THEN
>>            write ( *,*) 'iostat ',iostat,irec, lenw
>>            call perror('flwrit')
>>
>> Any idea why perror is used instead of a call to ER_WMSG?  This seems 
>> to be the only place in the FORTRAN subroutines/programs where perror 
>> is used insteasd of ER_WMSG when an error messsage needs to be generated.
>>
>> From what I can tell, the Intel Fortran compiler looks like it has its 
>> roots in the DEC/OSF fortran compilers from days of yore . . .
>>
>> Thanks!
>>
>> Kevin
>
>
>
>--------------010608080003090905010603--
>
--
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.