[Info-vax] Reopen OPERATOR.LOG from batch?

[Stephen Hoffman]

On 2019-09-18 10:02:53 +0000, Jan-Erik Søderholm said:

> Den 2019-09-18 kl. 11:32, skrev IanD:
>> Disquiet about silly old things brings it to attention rather than 
>> being ignored for the next smuck to hit their head on it

It's rude. It's hostile. It's not helpful.

I see these user interface design and implementation messes in 
application design, too.

Sitting with the end-users and learning from them, or answering support 
calls, and having the budget and the management support to fix things 
is a necessary and valuable investment.

Testing the UI ahead of deployments, too.  Better development tools 
that make changing the UI easier, and without requiring extensive 
source code re-development efforts, too. All of which exists.

Fixing bugs, fixing bad user interfaces, automating common sequences, 
all reduces costs and efforts.  And can help increase adoptions.

And that all comes from feedback.  Solicited or not.

>> Sort of akin to the squeaky wheel getting the grease
>> 
>> VMS had got a lot of catching up to do and I think it's great to hear 
>> about how other OS's have surged ahead while VMS has been sleeping 
>> because it helps set the bar for how high VMS needs to jump
>> 
>> Hearing some of the loud snoring that goes on within the belly of the 
>> OS also serves as a reminder that the only way forward is to embrace 
>> beneficial change
>> 
>> I don't think it's beneficial that so many things in VMS remain either 
>> undocumented or are just plain new user unfriendly

Oh, don't get me started on LMF.  Or some of the other areas.

>> Go ahead, keep thinking VMS in its current state is good enough and see 
>> how quickly that strategy will bring about an even quicker death
>> 
>> I for one value Master Hoffman's critiques. He's obviously got a ton of 
>> comparative OS, programming, networking and business knowledge that 
>> should be being tapped for input into where VMS could go
>> 
>> Can't say I can recall any rant of his about the shortcomings of VMS 
>> that weren't true and called for either
>> 
> 
> Yes, sure. He is not *wrong* as such. But the 10'th time the same rant 
> comes, that everyone has heard and read before, and that is mostly 
> unreleated to the question at hand, I at least have had enough.

You didn't run a newsgroup search, didn't check the FAQ, and/or you 
didn't know or have the search keywords to use, apparently didn't 
recall the details of my previous nine "rants" on this topic, and the 
documentation here is clearly lacking.

Any documentation of this case effectively being a published workaround 
for a design error or a design omission, too.  But I digress.

That's all fine.  This ask-somebody approach an increasingly common 
approach, too. Stack Overflow, etc.   But this question should also be 
an indication of an issue.

You're also here objecting to a suggestion that removes the need to 
even research this question.

Our software design and user interface approaches have to improve, as 
the expectations always change.  And the competitive products always 
improve.

And this having just gotten done with yet another log-rotation 
procedure for yet another OpenVMS installation, too.  Same as what 
you're going through here. You're writing a log-rotation tool. We're 
all writing log-rotation tools. Because we have to.

> And I prefer to say so, instead of blocking the/his posts.

Block my posts Jan-Erik, then.  Block them.  Or maybe ponder your 
approach around receiving constructive feedback, and around the need 
for software user interface improvements and design improvements.  Have 
you looked through your own designs for these issues and improvements?  
Or as we all get inured to our own designs and assumptions, had 
somebody else look through them?  Some of the end-users—if you can 
build up their trust and their engagement—can be phenomenal at this 
feedback.  This can be humbling, and can be quite surprising, from some 
of what I've experienced with feedback for my documentation and my app 
designs.

I've seen more than a little business and enterprise software that uses 
the "we don't want to hear it" approach to feedback.  That's an 
unfortunately all-to-common response in IT within various businesses.  
When your app audience is captive, and when your audience is paid to 
use it, a vendor can get away with it.  To a degree. For a while. Try 
this "We're IT and your not" approach too much when your audience has a 
choice, and it usually ends badly.  Corporate IT is getting (slowly) 
dragged along behind improvements in consumer IT, entertainingly.  But 
I digress.

As developers, if we're not looking back at the last couple of programs 
we wrote, or the last couple of configuration or management or 
installation sequences we've used, or if we don't realize that what 
you've just gone through here with OPCOM is utter and unmitigated 
manure—OPCOM is one such area within OpenVMS, among many—then maybe 
we've spent too much time working in the same manure heap, and not 
noticing the smell.  You're not stupid. Far from it. You're not 
inexperienced at OpenVMS.  Again, far from it.  And you could not find 
out how to get the logs to roll.  Contemplate how the OpenVMS design 
here has failed you.  That should be a warning of a latent issue. Not 
something to be overcome and then ignored. That log-rolling is entirely 
automatic on other platforms. On OpenVMS, it's entirely aromatic.

Working with other platforms has made some of the limitations of 
OpenVMS very apparent.  Very freshly apparent, in recent months.  OPCOM 
and system and network configuration, and app set-up and log management 
are all among the problematic areas.

Yes, the x86-64 port has priority.  But 1980s-vintage OpenVMS system 
management interfaces and assumptions just aren't all that interesting 
to folks outside the installed base.  UI improvements, and added and 
replaced frameworks, are the future of the platform.

This having just watched some network configuration menus pre-populate 
itself from the local DHCP and mDNS data, for networking and printing.  
And not having had to do anything to have automatic log roll-overs on 
that box.

Times change. Expectations change. OpenVMS changes. Or it dies.









-- 
Pure Personal Opinion | HoffmanLabs LLC