Post by David FrobleNow, I'm not typical, as all I do is R&D, but, I tend to store files on
the system(s) on which I'll be using them. So, if I do need a file
from another platform, copying it is the usual choice. No, I don't
serve files from dissimilar systems.
That certainly works at a small scale and clearly works for your
preferred style of project work and suchlike, but sharing files SMB
or MSCP/SCS in a cluster is handy when you want to have common files
across multiple systems. Either a single master (read only) copy, or
your (shared, read-write) working copy. Really handy for porting from
VAX to Alpha to Itanium to..., and handy for work across multiple
OpenVMS versions, or for various other permutations.
I've used shares for distributed software builds
https://github.com/distcc/distcc or otherwise where the local files
are exported as a share and all the build engines mount and churn away
on the code, too. Particularly outside of the OpenVMS environment, I
use a DVCS such as git or mercurial for distributed source code control
and access, and other than for builds probably not a share.
Shares are also handy for having big pools of storage available across
multiple computers; for NAS. MSCP/SCS services aren't available
outside of OpenVMS servers and OpenVMS itself has no access to
MSCP/SCS outside a host-local or cluster configuration with NAS
devices and other servers running SMB and NFS being far more prevalent
in the market.
There are also products which implement remote backups using file
shares; distributed archiving to a de-dup capable NAS device, etc.
But shares certainly don't solve all problems, any more than FTP or
sftp or a DVCS or anything else in this business would.
Post by David FrobleIn the event that a production task needs such files, as appropriate, I
set up services and clients, such that a client can ask for some
service to be performed. This can include the client sending and
receiving data, including files.
That's where having a kitting and distribution procedure would be
handy. Whether based on RSS, or manual push or pull/poll, or
otherwise. See https://sparkle-project.org or https://brew.sh among
many examples, and with slightly different purposes. Linux has
multiple choices here of course, and as is usual. OpenVMS completely
and entirely lacks that whole concept, however. Which means we all
tend to end up reimplementing this stuff, usually bespoke. Sometimes
PCSI based, sometimes VMSINSTAL, sometimes using other mechanisms.
Sometimes by manual processing and FTP transfers. With gaps in
various of the app-specific OpenVMS implementations I've encountered;
omissions such as kit and binary digital signing. But that's also not
where I'd typically look to use a share, either. Or FTP.
--
Pure Personal Opinion | HoffmanLabs LLC
------------------------------------
Original headers:
Xref: b4gate.uuhec.net comp.os.vms:22195
From: Stephen Hoffman <***@hoffmanlabs.invalid>
Content-Transfer-Encoding: 8bit
Lines: 58
User-Agent: Unison/2.2
References: <48a248db-c1cd-4d28-b630-***@googlegroups.com> <o8lm9j$ivs$***@dont-email.me> <o8n126$jtm$***@dont-email.me> <o8nbqk$uhj$***@dont-email.me> <o8ne4n$80c$***@dont-email.me> <o8nn5b$9o4$***@dont-email.me>
Mime-Version: 1.0
Organization: HoffmanLabs LLC
Newsgroups: comp.os.vms
Date: Thu, 23 Feb 2017 19:06:16 -0500
Path: b4gate.uuhec.net!newsfeed.xs3.de!io.xs3.de!nntp-feed.chiark.greenend.org.uk!ewrotcd!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
Message-ID: <o8nta6$vf5$***@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Cancel-Lock: sha1:9KYc3xjddY9lpb4IqjDByhyKZvk=
Injection-Info: mx02.eternal-september.org; posting-host="daa9c538d5ae399c7b3bce3fe42aa1a8";
Subject: Re:SAMBA / CIFS for OpenVMS
-- Pyffle HQ -=- London, England -=- http://pyffle.com