[Info-vax] queue errors

[Stephen Hoffman]

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