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

[Stephen Hoffman]

On 2016-01-07 02:46:43 +0000, abrsvc said:

> I have to agree with Phil here.  I too try to keep the system disk 
> "clean" from any non-DEC stuff.  I also use concealed devices so that I 
> am not tied to a particular device.  Since the "disk" is created during 
> startup so is available quite early.

The problem that some of the replies appear to be alluding to is the 
lack of a reproducible environment.

IMO, creating a local top-level directory on the system disk is fine, 
as is the locally-preferred practice of creating reproducible 
installation kits for the customizations and add-on tools.  Kits that 
can be archived, and maintained, and mass-deployed across multiple 
servers.

Ad-hoc and manual deployments tend to lack documentation and 
particularly tend to lack reproducibility.

Now as the temporary files and the log files and the volatile files and 
the other dreck that random stuff creates, those all belong elsewhere, 
because the general goal of any sort of disk segmentation is to avoid 
the need to back up the system disk on a daily or even weekly schedule, 
and the avoid the need to have to clean the system disk.   No system 
disk backups?   There's no point in backing up something that doesn't 
change.   On a typical system disk, there are maybe two or three dozen 
files that might or do change, and that's all that generally needs to 
be backed up, which means that locating those files elsewhere can be 
preferable.

Now if you're really working on mass deployment and reproducible 
deployments — what some folks call DevOps or Cloud services or some 
other term for mass management — you really don't want system disk 
modifications except via PCSI or VMSINSTAL or deployment procedures.

As for a hobbyist cluster or the sort of servers that are still running 
ancient OpenVMS releases — "ancient" is anything prior to V8.4, BTW — 
more than a few of those are already a software junkyard, so copying a 
few more files around is No Big Deal.   At least until the primary 
occupants of the junkyard decide to drain the swamp.   Why do I think 
this is No Big Deal?  Because nobody ever does any of this deployment 
stuff consistently — that includes DEC, Compaq, HP, HPE and VSI with 
OpenVMS and the associated layered products, third-party providers, 
open source, add-ons, and the usual raft of local procedures and local 
tools — it's all a pile of chaos.

The current OpenVMS system environment is filled with more than a 
little short-term thinking and scheduling compromises and quick hacks.  
 It's so ingrained that I honestly don't believe that more than a few 
of the participants here have actually thought about or realized the 
scope and the extent of the problems.  But I'm feeling polite, today.

This is why I rant about the DCL limits and the PATH mess and the 
directory mess and the lack of real temporary directories and the 
general lack of consistency and about the need for improved tools for 
cloud deployments and vastly easier software updates, and for updating 
the deployment tools and installation kits, about preferences files and 
consistent configuration and management tools, and about removing 
choices from installation kits, and related.  If you want to play in 
server computing in 2020, you need to be working on your own management 
UIs and vastly simplified UIs and continuous updates and mass 
deployments now and with fewer staff, or you're going to outsource all 
of this to the vendors.

But for this case and other similar cases, do what's locally 
appropriate for locating zip and unzip tools.    Use GNV.   Stick it in 
SYS$COMMON:[SYSEXE].   Whatever.  If it works, do it.



-- 
Pure Personal Opinion | HoffmanLabs LLC