[Info-vax] OpenVMS - DCL - Data entry filtering

[johnwallace4 at yahoo.co.uk]

On Saturday, 28 March 2015 10:24:05 UTC, Paul Sture  wrote:
> On 2015-03-28, David Froble <davef at tsoft-inc.com> wrote:
> > Bob Gezelter wrote:
> >> David,
> >> 
> >> The point is that on modern systems, it is not impossible to get
> >> identical filenames with the output of F$CVTIME. 
> >> 
> >> At the very least, one needs to trap the possibility when creating a
> >> file, and take appropriate action (e.g., appending index numbers).
> >> 
> >> - Bob Gezelter, http://www.rlgsc.com
> >
> > Yeah, I do that.  But it's rather rare, and if there are additional 
> > components to the filespec, it's even more rare.
> >
> > It also will depend upon the application.  I don't do anything that 
> > spins out many files, quickly.  I'm not sure what type of application 
> > would do that.
> 
> But in the case of splitting the job across members of a cluster, you
> might run into the problem Hoff raised.  Yes, we could add the node name
> into the mix and that can be handy on its own for problem diagnosis, but
> do we really want that?
> 
> > Sometimes what's theoretically possible and what's practically possible 
> > are far apart.
> 
> It's wise to remember that bit of Murphy's Law which says if something
> can't possibly happen, it will.
> 
> > I personally find the ascending sequence of time stamps very useful.
> 
> It's very useful indeed and can give you a head start when diagnosing
> problems.
> 
> -- 
> If you think it's simple, then you have misunderstood the problem 
>                                             -- Bjarne Stroustrup

And if something is theoretically possible but can be shown to be
very unlikely in any given period of time ("once in fifty years"),
it's entirely possible it might happen next week, next month, etc.

Sometimes it won't matter much if it does happen. Sometimes the
consequences can be devastating.

Further reading: e.g. Leveson on Therac and other subjects e.g.
steam [1], the "swiss cheese" model [Wikipedia], etc.

[1] http://sunnyday.mit.edu and in particular papers on "High
Pressure Steam Engines and Computer Software" (1994) and "The Role
of Software in Spacecraft Accidents":
Following is the last para of the Spacecraft Accidents paper, though
there's nothing spacecraft-specific about the principles and processes
being examined in the paper:
"Complacency and misunderstanding software and its risks were at the
root of all these [accidents considered]. Software presents
tremendous potential for increasing our engineering capabilities. At
the same time, it introduces new causal factors for accidents and
requires changes in the techniques used to prevent the old ones.

We need to apply the same good engineering practices to software
development that we apply to other engineering technologies while at
the same time understanding the differences and making the appropriate
changes to handle them.

There is no magic in software--it requires hard work and is difficult
to do well, but the result is worth the effort."