[Info-vax] CRTL and RMS vs SSIO
Arne Vajhøj
arne at vajhoej.dk
Wed Oct 13 19:17:14 EDT 2021
On 10/13/2021 1:43 PM, Simon Clubley wrote:
> On 2021-10-12, Arne Vajhøj <arne at vajhoej.dk> wrote:
>> On 10/12/2021 1:57 PM, Simon Clubley wrote:
>>> BTW, I wonder, with the required changes for the new filesystems
>>> for disks >2TB, if VSI will still support Macro-32 with the new
>>> filesystems or if we are moving to data structures with abstracted
>>> pointer sizes (and subroutine interfaces) just as in Unix and elsewhere.
>>
>> I think your view of *nix is a bit too rosy.
>>
>> Try read about lseek vs llseek vs lseek64, off_t vs off64_t vs loff_t
>> and how they behave depending on whether #define _FILE_OFFSET_BITS 64
>> is used or not.
>
> Not really. Those are all about maximum supported file sizes.
That seems pretty relevant to the question about file systems for large
disks.
> VMS has a major additional problem that no other operating systems do
> in that the size of an address is directly visible in program-visible
> system call structures instead of being abstracted away by the compiler.
It was a decision made 30 years ago to not extend those fields.
Problem? Maybe.
Major problem? I doubt it. Try count the number of questions about it.
Very few seems to have a problem with it in real life.
> This is because the lowest supported application language on VMS is
> Macro-32 but the lowest supported application language on those
> other operating systems is C which has a pointer data type that
> programs don't generally care about the size of.
I believe that z/OS also has applications with some assembler.
But newer OS'es like Windows and Linux does not.
C was not that big a language when VMS was designed. I don't even
think VAX C was available with first VMS versions. So obviously
VMS API's was not defined in C.
Arne
More information about the Info-vax
mailing list