[Info-vax] queue errors

[Tom Adams]

On Oct 18, 1:44 pm, Stephen Hoffman <seaoh... at hoffmanlabs.invalid>
wrote:
> On 2012-10-18 16:19:58 +0000, Tom Adams said:
>
> > Prompted by your post, I studied and tested the /CHECK qualifier we
> > use.  The only difference between it and /CHECK=ALL is that we turn
> > off runtime underflow checking. How is underflow checking a software
> > quality issue, since one always has to guard against or divide by zero
> > and other places were zero is a problem in calculations? (I am not
> > asking a rhetorical question, I really would like to know if it is a
> > quality issue.)
>
> Stuff that a (current) compiler (or that the run-time can locate) is
> stuff that the application programmer can schedule work and fixes for.
>
> In "recent" releases, the HP C compiler (for instance) has gotten
> substantially better at locating questionable coding constructs with
> the /WARN= ENABLE= (QUESTCODE, VERBOSE) and possibly also related
> diagnostics such as CHECK.
>
> These diagnostics have found various obvious and various subtle errors
> in C code that I've written, and C code I've debugged.
>
> The more the compiler finds (including, yes, finding and tweaking to
> avoid some "noise" messages), the less you have to find later, and
> off-schedule.
>
> Though the syntax differs from C, Fortran also has /CHECK and /WARN
> capabilities.
>
> There are projects that have required promoting all compiler-detected
> warnings to fatal errors, to more widely enforce the checks for "clean"
> code.  With HP Fortran, that would be /SEVERITY=WARNINGS=ERROR.  In C
> (IIRC), it's /WARN=FATAL=ALL
>
> > We stopped paying for VMS support a long time ago and that froze us at
> > 7.3-2 a long time ago.  Don't see any way around that.
>
> Yeah; you're in a corner with that, and then with the application.
>
> Your management get to decide where you're going (next) here, and what
> you'll be spending on.
>
> > Do you think it's a good idea to always patch VMS ASAP (as soon as the
> > patch is available); or only when the patch is recommended for all or
> > might fix a known problem?  What's the best policy for this?
>
> In recent years, and if I don't have a test configuration, and if the
> patch isn't immediately relevent, I defer the patch installation; I
> wait for part of a patch update cycle before loading the patch.  If I
> have a test configuration (and that's preferred), then the patches are
> loaded and tested there.
>
> But if you don't have support, you (also) don't have current patches.
>
> > I am pretty sure I need to improve my policy on patching.
>
> > The application logging is centralized in one application process and
> > (as I said) we log to a shadowed disk and have never lost message.
> > Maybe 3 messages per year don't make it to the paper logger due to
> > these queue errors, and more due to paper jams...
>
> I usually go electronic with logging, and with copies stored across
> multiple boxes and (depending on the value) geographically dispersed.
> Outside of some sort of administrative or legal requirement for it,
> paper doesn't usually factor into the designs.  If I need a more
> permanent transactional archive(s), then maybe DLT / SDLT /Ultrium /
> LTO tape, or a WORM version of the tape, as the (digital) storage.  All
> hardware can be flaky, but printers can average out as more flaky than
> most other widgets.
>
> --
> Pure Personal Opinion | HoffmanLabs LLC

Looks like underflow can cause loss of precision:

http://en.wikipedia.org/wiki/Arithmetic_underflow

But you would have to be working with values near zero (as final or
intermediate values) where precision was important for those values.

So, under the right conditions, underflow could lead to a functional
bug.