[Info-vax] VSI OpenVMS Hobbyist Program Announced.

[Jan-Erik Söderholm]

Den 2019-09-28 kl. 01:40, skrev Phillip Helbig (undress to reply):
> In article <gv7kehFtc50U1 at mid.individual.net>, Hans Bachner
> <hans at bachner.priv.at> writes:
> 
>> why not just provide new PAKs? I guess folks who have used *and
>> customized* the disk image would like to preserve their changes.
>>
>> Of course they can by binding the new image as a separate disk to their
>> virtual Alpha, extract and re-apply the PAKs - but why do you want them
>> to take this extra effort?
> 
> Right.
> 
> In the longer term, there should be a supported way to do an upgrade
> without overwriting ANY customization.  Perhaps this would be as simple
> as (re)defining SYS$SYSROOT to have an additional translation before the
> other two, which could be a non-system disk, possibly shared by more
> than one node (or all nodes).  I've heard of people doing this, but I
> don't know to what extent it is supported.  Some things are relatively
> easy: have a line in SYLOGICALS.COM to mount this disk, then another one
> to execute a procedure there.  So moving SYSUAF etc off the system disk
> is relatively easy.  A bit more work for OPERATOR.LOG and the audit
> server, but still not that much work.  TCPIP is an additional burden,
> then things like procedures which, in contrast to SYSUAF, say, have no
> built-in logical names.  So I have stuff like a line at the top to look
> on the non-system disk for a procedure of the same name and execute it
> then exit, but these get overwritten by a system upgrade.  I've thought
> about customizing things to the max then copying only executables from a
> newer version to a system disk, but this is probably neither sufficient
> nor supported.
> 

Remember that this primarily is an demonstration/educational offer.
What you describe above is probably not what someone looking to see
what OpenVMS is all about is expecting. And I guess that you are
expected to use this setup in an evaluation period, not forever...