The situation you describe with Sun is fairly typical of my experience with
mult-user licenses.  I have filed formal bug reports on both HPUX and Irix
compilers while associated with a previous employer, but, in those cases
where the bug was fixed, it appeared to have nothing directly to do with my
efforts.  Where there is a multi-user or site licence, it is common to have
a single point of contact, and, unfortunately, a slow process on both your
employer's side and the vendor's side. The situation is quite different with
the vendors of individual desktop compiler licenses, yet the situation may
still vary with the vendor and with your employer, if you are using the
compiler on their business.  So I come to the obligatory disclaimer stage of
not speaking for my present or past employers.

In recent weeks, I have filed formal bug reports, including one in which the
people on this list assisted me in establishing that there is a reasonable
interpretation of one aspect of the standard on which several
implementations agree.  On another, I triggered one of those internal
failure requests to file a report, so I took that as a clear indication of
action.  I have left several intermediate cases untouched, where the
behavior of the compiler was clearly sub-standard but perhaps excusable, but
difficult to deal with in view of disclaimer and business relationship
requirements.
----- Original Message -----
From: "Hjalmarson, Harold P." <[log in to unmask]>
To: <[log in to unmask]>
Cc: "Hjalmarson, Harold P." <[log in to unmask]>
Sent: Friday, November 24, 2000 10:08 AM
Subject: Re: Suspected bugs...


> At 07:23 AM 11/24/2000, [log in to unmask] wrote:
>
> >There has been a few comments, recently, from vendor compiler engineers,
> >complaining that bug reports should be sent to the proper support
> >provided by the vendor, and not to comp-fortran-90.
> >
> >I understand the frustration of the compiler engineers, when hearing of a
> >bug for the first time on a mailing list.
> >
> >However, there is often another side of the story.
> >Most of the time, a dysfunction is not clearly identified as a bug.
> >Users do not always have a copy of the Standard, and even if they do,
> >it is not so easy to understand.
>
> Yet another side to this story occurs when one is using the Sun
> compiler.  Under our support agreement, the report must be made by
> designated system administrators.  Thus I've had to make phone calls and
> write email to start the process. Then a Sun administrative person
> communicates with me about the details.  Then generally there is a long
> delay until this person asks me for even more details.  At no point do I
> actually get any advice in the first few days of an encounter with Sun
> support.  At some point I solve the problem myself or get advice from
> another source such comp-fortran-90.
>
> In the cases when the Sun engineers have noticed my postings to
> comp-fortran-90, the process led to some useful responses from Sun.
(Also,
> I've received communications from Sun managers stating that the process
> will be improved.)  In the other cases, I got regular requests to supply
> more information or allow the "case" (I forget what Sun calls it) to be
> closed.  For each of these I allowed the case to be closed after
developing
> a work-around to the problem.
>
> Having had this experience,  I'm not surprised that some members would be
> inclined to submit questions to comp-fortran-90 instead of the vendor.
>
>
> >I had several cases in the last 2 or 3 years, where it took me some
> >time, and help from the contributors of this list, to decide whether
> >a problem was a compiler bug or not.
> >I even saw one case where different compilers where acting differently,
> >and the old-timer (the vendor that was present on my site for years)
would
> >dismiss my bug report, while the new-kid-on-the-block (the company that
had
> >just installed a new system on the site) was ready to "correct" its
compiler
> >from standard-compliant to old-timer compliant!
> >
> >This list permits developpers to ask the fortran community about
> >unclear issues, get a strong, if not authoritative, opinion, and
> >avoids us the embarassment of submitting a bug report when there is
> >no bug at all.
> >
> >Bertrand MELTZ
> >
> >****************************************
> >*                                      *
> >*  Bertrand Meltz                      *
> >*  CEA / Bruyeres-le Chatel            *
> >*  BP 12                               *
> >*  91680 Bruyeres-le-Chatel            *
> >*  FRANCE                              *
> >*                                      *
> >*  Tel : (33) [0] 1 69 26 57 83        *
> >*  Fax : (33) [0] 1 69 26 70 93        *
> >*                                      *
> >*  e_mail : [log in to unmask]      *
> >*           [log in to unmask]      *
> >*                                      *
> >****************************************
>
> ---
> Harold P. Hjalmarson
> (Computational Biology and Materials Technology Department, Dept. 9235)
> Sandia National Labs, MS-1111, PO Box 5800, Albuquerque, NM 87185-1111
> [log in to unmask] (Internet) 505-844-8888 (office) 505-845-7442 (fax)
>
>



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%