Here's what I need in a "final" procedure.

Of course normal termination isn't a problem, but I have various I/O
boards that I need to ensure are properly terminated/safed (put in a
known state (e.g. not transmitting, outputs reconfigured to inputs) in
the event of a program crash. This is in part to ensure that
transmitters aren't overheated from prolonged operation (e.g. stuck in
the xmit state) or shorted because someone starts dismantling the test
setup thinking that the devices are automatically safed upon program
crash.

How is that handled normally? Will any of the new f2k3, f2k8 features
help me in this area (fault detection/recovery)?
--

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Gary Scott sbcglobal.net> wrote:

The standard doesn't and can't guarantee anything about that. That's
true of all versions, and for that matter to a certain extent of all
languages.

"Crashes" can happen for many reasons, but most of them boil down to one
of:

1. Hardware broke. Sorry, but if the machine catches on fire, the
Fortran standard isn't going to guarantee that Fortran programs still
behave in any kind of desirable way. Same for any other language. Now
just possibly, you might have something like an interupt to let you know
"machine on fire; you don't have long; clean up what you can", but the
standard doesn't guarantee that.

2. Compiler broke. Which is to say that the compiler isn't conforming to
the standard in some sense. Again, I'm afraid the standard doesn't cover
how compilers have to act when they fail to conform to the standard.
There are some circularity problems with that.

On Sep 19, 12:46 pm, Gary Scott sbcglobal.net> wrote:

What about adding a second job step that just turns everything off?

- e

e p chandler wrote:

As an ex-Oil company employee (some 30 years), I note we always
arranged that any equipment had a fail-to-safe mode default. If a
signal is not received within a defined minimum time, the external
processes must protect themselves and everything they in turn,
control.

The problems suggested by Gary, if truely existing, need engineers to
revise their designs.

Terence wrote:

Possibly, but that might complicate the device for some users that don't
need such protection (e.g. the system is built in and not subject to
being dismantled as in a test and some data acquisition environments).
Plus, the typical system is a hodgepodge of vendor cards, so it would be
really nice if there were a standard mechanism so it doesn't have to be
handled uniquely for each card.

--

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Gary Scott wrote:

There are two possibilities
a) The cpu/OS survives the software application crash and is in a
position to do something.
b) Otherwise.

Cases:
b) needs the external (or internal removable plugged-in device)
hardware to save itself.
This needs a higher engineering standard than usual. I will treat this
as unlikely.

Terence wrote: