First of all I would like to "quench" answers to my query of this morning
concerning "sudden system misbehaviour". I've finally been able to trace it
and it resulted a spurious problem (my fault !).
Namely it was the combination of :
- an environment variable which was set before reboot (actually it was
set since several days, I'm lazy and log out only seldom) and not set
after the boot
- My laziness in relying in my normal software to report an error if
such variable is not set, and the fact that my latest "quick and dirty"
programs did not do such check, and continued.
- A totally independent (compiler problem ?) in another program.
Please do not answer to my previous query, it's solved.
I'd like however to mention a few things about DEC Fortran under DU (no answer
is required, but any useful info will be gratefully appreciated).
(1) in answer to my query about a "normal system map" of /usr/shlib
<lucia_at_calliope.cccfc.uam.es> notes that on her system too f77 libs are
> owned by root.89,
> and I'm puzzled too about this group 89 which does not exist on my system
> either.
I confirm that also my other two alphas have some libraries owned by
root.89, it looks like it's part of the installation.
(2) I know that the version DFARTL361 of the Runtime Support for Fortran
3.8 (the one which came with my DU 3.2) had a bug (control-C interrupts
not honoured), which can be cured by a patch available at DEC.
I have DFARTL365 installed which has no such bug.
(3) however DFARTL365 has apparently another problem. Some of my programs
call a small C jacket routine around the "free()" C library call.
I recently fixed a bug in such routine, and now it generates a
"misalignment fixup" on its return statement.
This happens on my system with DFARTL365, but does not happen at
another site wit two systems (one with DFARTL361, another one with
DU 4.0 and a newer compiler version)
(4) I've encountered today another funny problem in the following code
call z_get_global('MECSMACCUM_SECRET',buffer) ! (a)
disable=buffer.eq.' ' ! (b)
C write(*,*)' disable is ',disable ! (c)
...
... some statements using BUFFER for other purposes
if(disable)then ! (d)
... conditional code A
else
... conditional code B
endif
i.e. I test a variable, and if it is undefined (blank) I set in (b) the
LOGICAL variable DISABLE to TRUE. Later on I execute conditional code
A or B according to this being true or false.
What happens is that if I decomment the debug write in (c), all works.
And (c) shows DISBALE is .TRUE.
But if I leave (c) commented, it's like disable is false in statement
(d), and conditional code B is ALWAYS executed.
I solved this moving lines (a) and (b) immediately before (d)..
It looks like the execution of statement (b) is deferred (by the
optimizer ?) until variable DISABLE is actually used (by the write
statement in (c), or by the IF in (d)).
But since BUFFER has been modified in the meanwhile, it fails.
Could this explanation be correct ?
----------------------------------------------------------------------------
Lucio Chiappetti - IFCTR/CNR - via Bassini 15 - I-20133 Milano (Italy)
----------------------------------------------------------------------------
Fuscim donca de Miragn E tornem a sta scio' in Bregn
Che i fachign e i cortesagn Magl' insema no stagn begn
Drizza la', compa' Tapogn (Rabisch, II 41, 96-99)
----------------------------------------------------------------------------
For more info :
http://www.ifctr.mi.cnr.it/~lucio/personal.html
----------------------------------------------------------------------------
Received on Tue Sep 30 1997 - 16:23:57 NZST