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

[Jan-Erik Söderholm]

Den 2019-09-18 kl. 16:48, skrev 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.
> 

As I wrote, you are perfectly right in what you write. I'm not saying
that you are wrong, sorry if it sounded like that. My point is just
that it might be OK to prove ones point once or twice, but not in
every single post one does over and over again. It just adds noice
to something that probably also has some very valuable bits in it.