Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!ncrlnk!ncr-sd!hp-sdd!apollo!oj
From: oj@apollo.HP.COM (Ellis Oliver Jones)
Newsgroups: comp.sys.apollo
Subject: Re: bug alert - /lib/ftnlib
Message-ID: <462073b7.208ba@apollo.HP.COM>
Date: 9 Oct 89 16:27:00 GMT
References: <8910031938.AA01386@civilgate.ce.uiuc.edu>
Reply-To: oj@apollo.hp.com
Organization: Apollo Computer, Chelmsford, MA
Lines: 30
Cc: lray@civilgate.ce.uiuc.edu

In article <8910031938.AA01386@civilgate.ce.uiuc.edu> lray@CIVILGATE.CE.UIUC.EDU (Ray) writes:
>
>If you have PATRAN on your system, do not use any ftnlib other
>than the 10.1 FCS ftnlib. Otherwise, you will break Patran.
>The problem is a DN10k bug that crept into the 68000 stuff somehow.

The DN10000 ftnlib problem was fixed last July.   The application
(PDA's PATRAN in this case) reads an unknown-format 
file with unformatted IO, hoping to take the ERR=9999 
escape from the READ statement to find out that 
the file is in fact formatted.  Something somebody did to 
/lib/ftnlib for sr10.1.p broke this, and we had to scramble
to fix it.

If (and only if) you have this problem with your DN10000, please call
your friendly customer service person and mutter the incancation
"performing a read of a formatted file with unformatted I/O caused 
a fault."  

The implication in the news article is that the problem has cropped up
on M68K machines.  Please please please call in a bug on this if it has in
fact happened.  I will test it now on a local sr10.2 node to see if
SR10.2's ftnlib has the problem.

>I've also got a call in to PDA about this, and am going to scream
>loudly until it is fixed.
Don't wear out your voice unnecessarily.  We also respond to gentle
requests, you know.  :-)

/Ollie Jones