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

[David Froble]

Stephen Hoffman wrote:
> 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.

Funny, how my idea of leaving the VMS directories untouched has turned into the 
entire disk ....

I have no problem using the system disk for rarely to never used stuff. 
Application source files, build procedures, and such.  The goal should be to 
have most to all of the I/O on this disk be relevant to VMS, not other things.

While today's disks are inexpensive, they are rather large.  Doesn't matter much 
if the "not used by VMS" is "blank" or rarely used.

> 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.

Guess I'm deprived.  I don't have hundreds of VMS systems to administer. 
Doesn't mean some others are not privileged to have such.


> 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.

Yeah, at some places that would be desirable.  Now if the maintainers of VMS and 
layered products would also have some disciplen.  Compilers and such could be in 
different directory trees.

> 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.

Pretty much ....