4 ms·

I have just been dealing with problems of VMS this week, and I have Dave Cutler to thank. We have a temporary emulated VAX running VMS 7 and Rdb [a SQL databas

by chasil 3y ago

I have just been dealing with problems of VMS this week, and I have Dave Cutler to thank. We have a temporary emulated VAX running VMS 7 and Rdb [a SQL database now owned by Oracle]. After several tries to move the Rdb backup files through our QA firewall with FTP, we finally had to use Multinet SFTP2 to push the backup instead (upping the transfer time from 3 to 40 minutes), which autodetected "VMS mode." There are some secret record blocking/delimiter capabilities in the ODS-2 filesystem used by VMS that an FTP binary transfer will not preserve, and which the Rdb backup/restore process absolutely needs. Thank heavens that UNIX thinks a file is a single stream of bytes. Windows continues the feature experimentation with NTFS "alternate data streams." My, how clever that is [not]. EDIT: from the article, the claim "The open-source BSDs and Linux had just seen the light of day." is not quite correct. Bill Joy was involved in the earliest BSD repacking of v6 Research UNIX, shipped in 1978. "In 1975, Ken Thompson took a sabbatical from Bell Labs and came to Berkeley as a visiting professor. He helped to install Version 6 Unix and started working on a Pascal implementation for the system. Graduate students Chuck Haley and Bill Joy improved Thompson's Pascal and implemented an improved text editor, ex. Other universities became interested in the software at Berkeley, and so in 1977 Joy started compiling the first Berkeley Software Distribution (1BSD), which was released on March 9, 1978." https://en.wikipedia.org/wiki/Berkeley_Software_Distribution https://en.wikipedia.org/wiki/Berkeley_Software_Distribution ...I have also read elsewhere that a conscious decision was made in Windows to never, ever support big-endian architectures (but I am not certain that this is correct). NetBSD and Linux can run big-endian. "Now, I know you will complain that NTFS is slow… but you know what? It almost-certainly is not... NTFS on its own is fine..." XFS appears to trounce NTFS, and it consistently leads the performance scores on tpc.org; until very recently, SQL Server on XFS/Linux was well ahead of Windows.

Gravityloss 3y ago
Oh my, that prompted me to read Wikipedia - and we have MUMPS also from VMS. A quite different programming paradigm. The last common ancestor with current mainstream programming is really far back and it looks very odd. New large scale multi billion dollar healthcare systems are still being written in it.
- chasil 3y ago
  VMS was just recently ported to AMD64, so you might be able to keep using it if your vendor ports their code. https://vmssoftware.com/about/v921/ https://vmssoftware.com/about/v921/
canucker2016 3y ago
You're blaming tools that don't support the full featureset of one of your platforms. VMS's ODS2 filesystem evidently has concept of files that are grouped in records. The ftp program that you use on VMS wasn't designed to support sending that info to a destination filesystem. Probably because the original Unix filesystem only supported the idea of one stream of bytes for a file. You'd need an FTP server on the destination side to support records seamlessly if you wanted full fidelity. That's why NTFS supports alternate data streams - the MacOS HFS filesystem supported data and resource forks for a file. An NTFS alternate datastream was where the resource fork was placed so the NTFS user would only see one file from the CLI and the GUI and the builtin copy tools would copy all streams. deleting such a file would remove both streams on NTFS.
- chasil 3y ago
  Actually, Multinet FTP does have a couple of switches for "VMS mode," but SFTP2 got a working solution in front of us with less reading of the manuals. POSIX was wise in having absolutely none of this. Would you rather Apple had won over this standard and we had resource forks everywhere? I understand that the largest use of alternate data streams at times in the past was malware, to evade virus scanners, which seems to be an anti-feature to me. A file should be a stream of bytes that can at least survive transfer over a socket (that is 8-bit clean), unlike this ODS-2 detritus.
  - tedunangst 3y ago
    You know that e.g. linux supports extended attributes and they don't copy so easily over ftp either?
    - chasil 3y ago
      Yes, I know that ACLs, security contexts, and zfs/btrfs parameters aren't going to move. This would be know as "filesystem metadata," and the send/receive operations on zfs/btrfs would be the best bet to preserve them. However, my ODS-2 problem was not metadata, it was data that lacked esoteric formatting. I certainly don't need that for Oracle RMAN - an FTP binary transfer will always works.
anthk 3y ago
XFS was for media and big files. If you were on A/V production with huge recordings, XFS was the right choice over a network.
- chasil 3y ago
  Oracle is putting a LOT of development effort into XFS, and I am assuming that they are doing so because it makes their database faster. https://blogs.oracle.com/linux/post/xfs-2019-development-retrospective https://blogs.oracle.com/linux/post/xfs-2019-development-ret... https://blogs.oracle.com/authors/darrick-wong https://blogs.oracle.com/authors/darrick-wong
- HeckFeck 3y ago
  I have a habit of selecting XFS for all my Linux installations. It is a truly excellent filesystem. Though I must confess the reason I initially chose it was because of the name.
wannacboatmovie 3y ago
> Thank heavens that UNIX thinks a file is a single stream of bytes. Windows continues the feature experimentation with NTFS "alternate data streams." My, how clever that is [not]. Macs use Resource Forks, a type of alternate data stream, yet I am frequently reminded (here) that macOS is Certified (r) UNIX (r)(c)(tm).

by chasil 3y ago

Gravityloss 3y ago

Oh my, that prompted me to read Wikipedia - and we have MUMPS also from VMS. A quite different programming paradigm. The last common ancestor with current mainstream programming is really far back and it looks very odd. New large scale multi billion dollar healthcare systems are still being written in it.

chasil 3y ago
VMS was just recently ported to AMD64, so you might be able to keep using it if your vendor ports their code. https://vmssoftware.com/about/v921/ https://vmssoftware.com/about/v921/

canucker2016 3y ago

You're blaming tools that don't support the full featureset of one of your platforms. VMS's ODS2 filesystem evidently has concept of files that are grouped in records. The ftp program that you use on VMS wasn't designed to support sending that info to a destination filesystem. Probably because the original Unix filesystem only supported the idea of one stream of bytes for a file. You'd need an FTP server on the destination side to support records seamlessly if you wanted full fidelity. That's why NTFS supports alternate data streams - the MacOS HFS filesystem supported data and resource forks for a file. An NTFS alternate datastream was where the resource fork was placed so the NTFS user would only see one file from the CLI and the GUI and the builtin copy tools would copy all streams. deleting such a file would remove both streams on NTFS.

chasil 3y ago
Actually, Multinet FTP does have a couple of switches for "VMS mode," but SFTP2 got a working solution in front of us with less reading of the manuals. POSIX was wise in having absolutely none of this. Would you rather Apple had won over this standard and we had resource forks everywhere? I understand that the largest use of alternate data streams at times in the past was malware, to evade virus scanners, which seems to be an anti-feature to me. A file should be a stream of bytes that can at least survive transfer over a socket (that is 8-bit clean), unlike this ODS-2 detritus.
- tedunangst 3y ago
  You know that e.g. linux supports extended attributes and they don't copy so easily over ftp either?
  - chasil 3y ago
    Yes, I know that ACLs, security contexts, and zfs/btrfs parameters aren't going to move. This would be know as "filesystem metadata," and the send/receive operations on zfs/btrfs would be the best bet to preserve them. However, my ODS-2 problem was not metadata, it was data that lacked esoteric formatting. I certainly don't need that for Oracle RMAN - an FTP binary transfer will always works.

anthk 3y ago

XFS was for media and big files. If you were on A/V production with huge recordings, XFS was the right choice over a network.

chasil 3y ago
Oracle is putting a LOT of development effort into XFS, and I am assuming that they are doing so because it makes their database faster. https://blogs.oracle.com/linux/post/xfs-2019-development-retrospective https://blogs.oracle.com/linux/post/xfs-2019-development-ret... https://blogs.oracle.com/authors/darrick-wong https://blogs.oracle.com/authors/darrick-wong
HeckFeck 3y ago
I have a habit of selecting XFS for all my Linux installations. It is a truly excellent filesystem. Though I must confess the reason I initially chose it was because of the name.

wannacboatmovie 3y ago

> Thank heavens that UNIX thinks a file is a single stream of bytes. Windows continues the feature experimentation with NTFS "alternate data streams." My, how clever that is [not]. Macs use Resource Forks, a type of alternate data stream, yet I am frequently reminded (here) that macOS is Certified (r) UNIX (r)(c)(tm).