VMS database files compatibility

OpenVMS x86 Field Test questions, reports, and feedback.
Post Reply

Topic author
milehighmikey
Newbie
Posts: 3
Joined: Fri Aug 13, 2021 3:38 pm
Reputation: 0
Status: Offline

VMS database files compatibility

Post by milehighmikey » Fri Aug 13, 2021 3:57 pm

Hi, I am participating in the field test of OpenVMS X-86/64 and we just added some VMs. Trying to make life easier, I copied a DECnet IV netnode_remote.dat into my X-86 VM, but it does not get processed, as if it was not there. I also tried to use a sysuaf.dat from an itanium running OpenVMS 8.4-2L3 into the x-86/64 host, but that was not usable, either.

Are these incompatibilities to be expected? If so, if the incompatibility is due to early implementation, is there any plan to make these files work on the X-86 side?

Thanks,

Mike Taylor

User avatar

arne_v
Master
Posts: 299
Joined: Fri Apr 17, 2020 7:31 pm
Reputation: 0
Location: Rhode Island, USA
Status: Offline
Contact:

Re: VMS database files compatibility

Post by arne_v » Fri Aug 13, 2021 7:10 pm

If not compatible then a mixed-architecture cluster will have some challenges.
Arne
arne@vajhoej.dk
VMS user since 1986


hein
Active Contributor
Posts: 41
Joined: Fri Dec 25, 2020 5:20 pm
Reputation: 0
Status: Offline

Re: VMS database files compatibility

Post by hein » Fri Aug 13, 2021 11:03 pm

milehighmikey wrote:
Fri Aug 13, 2021 3:57 pm
a DECnet IV netnode_remote.dat into my X-86 VM, but it does not get processed, as if it was not there. I also tried to use a sysuaf.dat from an itanium running OpenVMS 8.4-2L3 into the x-86/64 host, but that was not usable, either. "
Hello Mike,

The two files you mention are RMS INDEXED files.
Just do a DIR/FULL on the source and target.
That should look like:

Code: Select all

Directory DKA0:[SYS0.SYSEXE]
NETNODE_REMOTE.DAT;1                      File ID:  (xxx,yyy,z)
:
File organization:  Indexed, Prolog: 3, Using 2 keys
Does it?
Dollars to donuts that the transferred files report to be Sequential, possibly stream_lf
How did you transfer them? FTP ? ... BIN mode?
They are likely corrupted during the tranfer.
Assuming the file attributes are correct, check further using DUMP/RECORD=COUNT=3 on source and target and compare.

It's best to transfer inside a backup saveset - which can be zipped up and transferred (bin mode)
For restore you me need backup/repair.

You can also try ZIP -"V".

Good luck,
Hein

User avatar

martinv
Master
Posts: 101
Joined: Fri Jun 14, 2019 11:05 pm
Reputation: 0
Location: Goslar, Germany
Status: Offline
Contact:

Re: VMS database files compatibility

Post by martinv » Sat Aug 14, 2021 1:55 am

Adding to Hein's post, if you're missing UNZIP.EXE on the x86 system: it's in the V9.1 installation disk file system, under the [VMS$COMMON.SYSHLP.UNSUPPORTED] directory.
Working hard for something we don't care about is called stress;
working hard for something we love is called passion.
(Simon Sinek)


Topic author
milehighmikey
Newbie
Posts: 3
Joined: Fri Aug 13, 2021 3:38 pm
Reputation: 0
Status: Offline

Re: VMS database files compatibility

Post by milehighmikey » Wed Aug 25, 2021 10:44 am

Hi everyone, thanks for the responses.

I was really overthinking this problem and realized that it was pretty simple, and no issue with the files themselves having been somehow corrupt. The real issue was that I had set up openssh on the original sysuaf.dat file and then when merging into the cluster, I used a sysuaf.dat that did not have the openssh user registered. So everything was dead, and the only problem with the sysuaf.dat was the missing UICs for openssh. I realized this and as as soon as I did, I reinstalled openssh which then created the proper accounts on the merged sysuaf.dat. Pretty silly of me.

As of right now, I have not explored the netnode_remote.dat issue since I reported this originally, but I will pay attention to any file format type issues mentioned above.

Mike


hein
Active Contributor
Posts: 41
Joined: Fri Dec 25, 2020 5:20 pm
Reputation: 0
Status: Offline

Re: VMS database files compatibility

Post by hein » Thu Aug 26, 2021 9:05 am

"Pretty silly of me."

Thanks for the update. We appreciate that.
It was pretty silly to even consider there would be an incompatibility at the file ("database") with an OpenVMS port.
OpenVMS's crown jewel is cluster support where multiple servers, of potentially multiple architecture, all mount the same (disk) volumes and see the same file.
Your OpenVMS X-86/64 test node could (should) be member of a cluster sharing the very same SYSUAD, NEtnode, RigthsList and so on. Those are all shared RMS indexed files.
Have fun with the continued tested!
Bye,
Hein.

Post Reply