[Info-vax] How do I make zip, unzip etc. available to all users?

[johnwallace4 at yahoo.co.uk]

On Saturday, 9 January 2016 04:02:05 UTC, Stephen Hoffman  wrote:
> On 2016-01-08 08:35:27 +0000, Hans Vlems said:
> 
> > I'm just a hobbyist so my requirements are not as strict as a shop that 
> > serves a 24x7 production line.
> > Applying a VMS patch on 11 Alphas was however a RPITA. Would I've 
> > wanted a vendor pushed/forced update like Microsoft, Mozilla etc do? I 
> > don't think so. I prefer to know what gets fixed and if it is something 
> > that bothers me.
> 
> For more than a few folks, the reticence is around the perceived 
> quality of the patches.   Or the lack thereof.   If the patches install 
> and work, they're more easily accepted.   If the patches break things, 
> then it's a circling-the-drain sort of mess, where even working patches 
> get deferred and delayed, where server security weakens, where system 
> integrity suffers, and where bug-related support calls increase 
> including the sorts of callers that expect proof, and... well.... 
> badness ensues.   This mess was also a factor in the genesis of the 
> roll-up patches -- running full regressions for all of the permutations 
> of a dozen disparate point fix patch kits is time-consuming and 
> expensive.
> 
> > Installing patches or layered products for 11 systems ought to be 
> > easier than manually repeating the same procedure.
> > All systems are basically configured the same. I am working on one 
> > system that stores the kit and one batch job that does all the work.
> 
> For another platform, I run a central patch server.
> 
> That server downloads and caches patches from the vendor, and -- if you 
> want or need to manage that flow -- stage which patches are available 
> for deployment, and which are held pending.   This at the patch server. 
>   Individual systems then query that server either on a schedule or 
> manually, and then download and install the patches, and -- prompting 
> for permission -- require at most one reboot to complete the 
> installation.  Internally, this might actually be several reboots in a 
> row, but control -- unlike OpenVMS -- is not returned to the user between 
> any sequenced reboots that might be necessary.
> 
> These individual systems can then either be configured for automatic 
> installation, or manually triggered.
> 
> For the end-user or the system or environment manager or the DevOps 
> team, this amounts to pressing a button or issuing a single command, 
> and all of the staged patches are downloaded from the vendor or from 
> the local patch server, installed, configured and launched.
> 
> For those environments where this approach is insufficient or 
> inappropriate, an environment akin to an installation via host-based 
> InfoServer is available; selecting and installing new disk images, or 
> pushing disk images.
> 
> If site-specific prepared disk images are inappropriate, then there's a 
> web-based system that allows either pushing out specific software 
> packages to specific systems, or allowing the end-users of the systems 
> to select and install centrally-provided, licensed and managed software 
> packages -- self-service installations.
> 
> All of this is available now.   All of this works.  If folks do not 
> currently have this for some particular platform -- I don't know the 
> Windows patch process and distribution mechanisms, for instance -- then 
> they likely will soon have these capabilities.   These are the sort of 
> basic system operations and tools that tend to spread -- not necessarily 
> the same tools, but the same ideas and capabilities -- that spread 
> across all platforms, and that become expected.
> 
> From the patch processing and associated contract and verification 
> data, VSI also gets information on active OpenVMS systems and on 
> down-revision systems, can get opt-in data on server configurations, 
> and other benefits, too.  Probably opt-in crash data, too.   If a patch 
> gets installed and applications and/or servers suddenly start crashing, 
> maybe there's a bug that got past QA and the patch should be put on 
> hold?  Better integration and quicker feedback, rather than the 
> engineering team not knowing (at all), having to wait for support calls 
> to be logged, and then sending out email messages to... somebody.  Or 
> if there are crashes that are fixed by some existing patch, prompting 
> for a particular patch, whether via the patch process and/or email.   
> Given it's opt-in and given crash scanning can be partially automated, 
> accepting crash reports from even off-contract and hobbyist sites is a 
> way to up-sell support, and -- if there are a boatload of crashes -- a 
> way to identify problems that can or will effect supported sites, too.  
>  Post up a sane price and an HTTPS order form -- web browsers can be 
> embedded, and can be text-based -- and you might sell a few, too.
> 
> What the OpenVMS system management folks have to go through to get 
> InfoServer and/or patches and/or patch downloads and the rest is 
> utterly absurd.   Computers are good at automating processes, even with 
> the desire or the need that some sites have for manually pulling an 
> installation "trigger".
> 
> Now some of you will rightfully harrumph over these features and claim 
> "we've always done it this way" or "this works", well, good on you.   
> Glad things are working out.   But ponder this...  New users are not 
> going to want to learn and deal with this.  More than a few just aren't 
> going to patch or to upgrade, too.   Yes, "we walked uphill to school.  
> Both ways.  In the snow."  Etc.   Have fun expanding the installed base 
> with that.   Yeah, "not my problem".   But if new users and new 
> applications don't arrive at least as fast as the existing applications 
> and environments retire or migrate off of OpenVMS, then OpenVMS is 
> dead.  The more barriers are in the way of adoption and operations, the 
> less likely anybody outside of a legacy shop will choose OpenVMS.
> 
> The article on changing the IP address of an OpenVMS server is doing a 
> brisk business.  Which should tell you some things about user 
> interfaces and changes in expectations.
> 
> But then this is rather advanced and probably way past aspirational for 
> the folks at VSI, given their work schedule, staffing, and the utterly 
> stellar state of the existing OpenVMS patch management tools.
> 
> > VMS systems operate in different environments and one solution won't 
> > do. That is where a system manager still earns his keep. The same 
> > applies to Windows servers, many are not blindly upgraded as soon  
> > Microsoft issues a patch.
> 
> Which gets back to the trade-off between the fear of new and previously 
> unknown bugs and the occasional known bugs, and the perceived risks of 
> the existing and known bugs.   More than a few customers clearly don't 
> trust Microsoft to be able to completely manage the complexity of their 
> hardware and software environment.  (That Microsoft does as well as 
> they do with the massive permutations they deal with is no small 
> achievement, too.)
> 
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

Apropos of nothing much in particular: the VMS community generally used
to be proud of VMS's capabilities in terms of extended uptimes, even if
the broader mechanisms for patch management left a bit to be desired.

It seems like one of the other OS vendors has finally caught on too:

https://www.youtube.com/watch?v=SYRlTISvjww (4 minutes, though you'll
get the general idea very quickly. Probably suitable for work, may cause
persistent after effects)

Don't reboot it, just patch.

Over to you, VMS community (not just VSI).

Have a lot of fun.