V9.2.3

[majorblud]

Greetings:

I was accepted into the Hobbyist program back in the HP Alpha days, and just recently moved into the VSI program a few weeks ago. I downloaded the VMDK, and was able to get V9.2.2 running in ProxMox, complete with networking. I see that V9.2.3 was released, will that be made available to hobbyist?

[sword7]

I re-downloaded community package but it is still old (3/19/2023). We need new community package.

I am not satisfied with the community license because they should provide SP access, not VMDK package. Ambassador license is better because it provides SP access so that we can often update. I have experience with OpenVMS since 1984. I am now applying for that.

Tim

[cct]

Under the new community program, they have said they will ship a new VMDK once a year, so I am afraid you have a few months to wait

[majorblud]

Under the new community program, they have said they will ship a new VMDK once a year, so I am afraid you have a few months to wait

I wasn't aware of this, thanks for providing that info!

[djlstewart]

If a new VMDK is shipped annually, how will we be able to merge the new system with the previous VMDK to preserve the changes we've made?

[cct]

If a new VMDK is shipped annually, how will we be able to merge the new system with the previous VMDK to preserve the changes we've made?

I would suggest creating a data disk, which can be moved over. Also keep a precise note of all changes, so you can reapply them to the new VMDK, where they are necessary.

You can have the old and the new running together, on the console only to check changes

[hb]

You can have the old and the new running together, on the console only to check changes

I'm not sure what this means.

Using a data disk for user data is probably the right thing to have, or at least a backup of the user data.

I haven't seen a community VMDK and instructions how to use it. But as far as I know, you can configure any VM with multiple (VMS system) disks. It should be possible to have a configuration with both, the old VMDK and the new one. Then you can boot the new one and redo the adjustments that you did on the old one - using DIR/DATE to identify modified files since starting to use the old VMDK, and using DIFF and a merge tool to make the same modifications on the new VMDK. This may take some time and may be difficult or not possible for some adjustments made. But you will have all the files and so all the data from the old VMDK.

[cct]

You can have the old and the new running together, on the console only to check changes

I'm not sure what this means.

Clearly when the new VMDK comes out, they will only have a few days before the old licenses expire, but what I was saying that you can still log in on the console on the VM with an expired license, and check any configurations etc on the old VM. Alternately you could offer the old VM system disk up to the new VM, mount it privately and do the same

[sms]

Code: Select all

> Clearly when the new VMDK comes out, they will only have a few days
> before the old licenses expire, [...]

   But the new PAKs (or whole .LDB) could be copied to the old system,
so I see no need to hurry.

> [...] offer the old VM system disk up to the new VM, mount it
> privately [...]

   If the label's different, then why "privately", and not /SYSTEM (or
/CLUSTER)? 


   But yes, VMDK-only access is much less convenient for updates.  In
fact, with all the fiddling with different hosts and VM configurations,
I've been installing VMS at unprecedented rates in recent months.

   One result is that I've been restructuring the way I store the
auxiliary DCL scripts which my SYSTARTUP_VMS.COM uses, segregating them
in a new subdirectory, instead of just putting them into SYS$MANAGER. 
That way, I can copy most of this stuff to a new system in one
operation, leaving only a few files which contain system-specific data
to get special handling.

[cct]

> Clearly when the new VMDK comes out, they will only have a few days
> before the old licenses expire, [...]

But the new PAKs (or whole .LDB) could be copied to the old system,
so I see no need to hurry.

> [...] offer the old VM system disk up to the new VM, mount it
> privately [...]

If the label's different, then why "privately", and not /SYSTEM (or
/CLUSTER)?


But yes, VMDK-only access is much less convenient for updates. In
fact, with all the fiddling with different hosts and VM configurations,
I've been installing VMS at unprecedented rates in recent months.

One result is that I've been restructuring the way I store the
auxiliary DCL scripts which my SYSTARTUP_VMS.COM uses, segregating them
in a new subdirectory, instead of just putting them into SYS$MANAGER.
That way, I can copy most of this stuff to a new system in one
operation, leaving only a few files which contain system-specific data
to get special handling.

Not sure about the legality of copying the .ldb

In the past I usually kept the same label on multiple systems, so I would always mount privately, but as you say if they are different...