lray@CIVILGATE.CE.UIUC.EDU (Ray) (10/04/89)
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 occurs when trying to read formatted results files. The
traceback is:
Process 1354 (parent 1256, group 1256)
Time 89/10/03.11:14(CDT)
Program //node_194e9/patran/patran23/com/patran2.m68k
Status 03080004: requested too large an area from baf (process manager/basic heap storage manager)
In routine "pfm_$error_trap" line 160
Called from "rws_$alloc_heap_pool" line 498
Called from "pas_$new" line 772
Called from "fio_$getrec" line 613
Called from "fio_$real_ioinit" line 4071
Called from "fio_$real_ioinit" line 29
Called from "BINFIL" line 72
(miscellaneous patran routines deleted)
The problem is a DN10k bug that crept into the 68000 stuff somehow.
The execution error occurs because Patran is trying to determine if
the input file is ascii or binary. It performs a series of tests on the
file, and apparently one of the causes this error.
I have not yet run into another program which has this problem, but if
anyone else does, do open an 800-number call on it -- the more customers
who complain, the better the change of this one getting squished for
good.
I've also got a call in to PDA about this, and am going to scream
loudly until it is fixed.
Leland Ray
UIUC - CE Dept.
(217) 333 - 3821oj@apollo.HP.COM (Ellis Oliver Jones) (10/09/89)
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
oj@apollo.HP.COM (Ellis Oliver Jones) (10/10/89)
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 offending ftnlib is the one shipped with the new compiler version. It seems you don't have to install the ftnlib when you install the new compilers. If you're a PATRAN user, don't install the new ftnlib. I logged an internal bug on this. It's OK for someone else to file an APR. The SR10.2 ftnlib (I know, most of you don't care yet) is OK. Do you mind doublechecking that, Ray? /Ollie Jones (speaking for myself, not necssarily for HP Apollo Systems Div.)