[Info-vax] OpenVMS Development Annoyances

[Stephen Hoffman]

On 2019-04-28 14:28:35 +0000, IanD said:

> ACMS was good for lots of things but having to chase down a process or 
> task death in the ACMS logs could get tedious. It also got hairy at 
> times, especially if it crashed at a lower level and you then had to 
> wade through swlup logs when ACMS didn't start for example

Not being able to easily determine why a process crashed is a fairly 
sizable hole in a scheduling product.

What little of the ACMS documentation I've looked at also needs 
substantial work, if this is to be deployed as a generic scheduling 
project.

I'd expect the ACMS UI to need upgrades to be a generic scheduler too, 
but that's solely based on experience with the age of the doc and of 
the UI designs that I'm finding here.

As was mentioned else-thread, ACMS integration with SYSUAF and logical 
names?  Yeah, okay, but that's not selling this for me.  SYSUAF and 
logical names and ilk are among the more problematic OpenVMS features.

I really don't see ACMS as a generic scheduler.  Not with what I'm 
finding.  It may well be capable of doing that. But if it is, it's 
buried under a UI and documentation that makes that ability rather less 
than clear.

Though that's a common problem with OpenVMS APIs and layered products 
and related documentation.

"Why?" is not a question that the traditional OpenVMS documentation was 
seemingly ever good at answering.

Why would I use ACMS as a generic app scheduler on OpenVMS?  If that's 
not clear to enough folks, that's just not going to happen.

Now if I wanted a transaction monitor, sure.  I'd look at ACMS.

> I used to plead with programmers to add dectrace calls in their code 
> but it often feel on deaf ears. Dectrace can be very helpful.

OpenVMS app tracing has been a problem for years.  There are many 
ad-hoc solutions and many home-grown solutions.

OpenVMS itself is inconsistent.  Some crashes get written to accounting 
(RMS), some to the system dump files (errors and system crashes), some 
to app dump files (various apps, and scattered around), and some to 
various log files.

Crashes should have been collected years ago, and not dumped to the 
display of the end user.

The crash collection frameworks I'm working with elsewhere are well 
beyond what OpenVMS offers.

Telemetry is a key part of running any complex environment.  Yeah, opt-in, etc.

syslog and syslog-ng are available from VSI.   Though that availability 
may not necessarily be widely known.  Though that's also not 
integrated, like much of the rest of networking.

And given that DECtrace is now Oracle Trace, DECtrace seems unllikely 
fodder for any future incorporation into OpenVMS.

> It seemed to stem from a like minded design philosophy, unlike the 
> modular crap on sees in systems and products today where it's blatantly 
> obvious different teams design and write different parts. They often 
> cannot even get a definition sentence consistent

Any complex environment gets that way, sooner or later.  Or it develops 
or maintains its own terminology—e.g. shadowing, whatever it is that 
Process calls "firewall"—and diverges from what most folks expect and 
recognize.  Or both.  Doc work and UI work is an ongoing effort.  
OpenVMS doc is mostly stuck in the 1990s.

One of the infinite list of projects scrawled on Bolton whiteboards 
includes overhauling and updating the "Building Dependable Systems: The 
OpenVMS Approach " manual.   That manual is ~25 years old, and it 
really shows.  And the gulf between what's in that manual and what's in 
the Programming Concepts and Security Manuals and what's increasingly 
necessary.  Not that any of these manuals are even remotely reflective 
of expected practices.  I'd have probably started with a complete 
overhaul of the DEC Software Engineering Handbook (1988) (hard to 
find), but dragging even parts of the OpenVMS documentation forward is 
no small effort.  That documentation work will inherently also show 
where the APIs and the UIs and the integration is weak, too.





-- 
Pure Personal Opinion | HoffmanLabs LLC