From Newsgroup: comp.os.vms

I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.

I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 8/29/2025 10:14 AM, Waldek Hebisch wrote:

I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.

I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.

I suspect very few try to build VMS executables on Linux.

GNV got both ar and ld, but that does not help you.

But are you sure you want to do it this way?

My understanding is that you want to do:

source-(compiler on Linux)->.obj->(ld on Linux)->VMS .exe

I would go for:

source-(compiler on Linux)->.obj->(LINK on VMS)->VMS .exe

Or if possible even better:

source-(compiler on Linux)->.s-(GCC AS on VMS)->.obj-(LINK on VMS)->VMS .exe

GCC AS (version 2.8) is working on VMS Alpha.

Arne




--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <108sckg$19hcn$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.

I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.

There is a BFD backend for VMS on Alpha in the main binutils
branch in git, but it is not clear to me how well-tested or
generally maintained it is, nor how compatibile with the
standard VMS utilities it ever was; I suspect it existed
primarily to port GNU software to VMS.

What, exactly, are you trying to do?

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 10:14 AM, Waldek Hebisch wrote:

I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.

I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.

I suspect very few try to build VMS executables on Linux.

GNV got both ar and ld, but that does not help you.

Where are the sources? Working sources certainly would help.

But are you sure you want to do it this way?

My understanding is that you want to do:

source-(compiler on Linux)->.obj->(ld on Linux)->VMS .exe

I would go for:

source-(compiler on Linux)->.obj->(LINK on VMS)->VMS .exe

That is plan B. Working binutils would be simpler because
I could use existing automated process.

Actually, ATM I getting errors during gcc build. I can use
crude workaround to go further, but I am affraid that to get
working compiler I need either working binutils or to examine
all build steps involving binutils and do equvalent work in
different way.

Or if possible even better:

source-(compiler on Linux)->.s-(GCC AS on VMS)->.obj-(LINK on VMS)->VMS .exe

GCC AS (version 2.8) is working on VMS Alpha.

Actually, it is possible that I will have to use

source-(compiler on Linux)->.s-(VMS assembler)>.obj...

because one of next goals is to get running compiler wich generate(d)
assembly for VMS assembler and may be incompatible with GNU as. But
this means more changes to build process (= work work => not better).
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-08-29, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <108sckg$19hcn$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.

I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.

There is a BFD backend for VMS on Alpha in the main binutils
branch in git, but it is not clear to me how well-tested or
generally maintained it is, nor how compatibile with the
standard VMS utilities it ever was; I suspect it existed
primarily to port GNU software to VMS.

AdaCore was primarily responsible for working on this as part of
GNAT. After they dropped VMS as a supported target, this code may
have gone stale.

What, exactly, are you trying to do?

I strongly suspect the OP is trying to either run more modern variants
of languages that already exist on VMS or languages that simply do
not yet exist on VMS.

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 8/29/2025 1:32 PM, Waldek Hebisch wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 10:14 AM, Waldek Hebisch wrote:

I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.

I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.

I suspect very few try to build VMS executables on Linux.

GNV got both ar and ld, but that does not help you.

Where are the sources? Working sources certainly would help.

There are the SourceForge version of GNV and there is the
VSI version of GNV.

The SF version is here:

https://sourceforge.net/p/gnv/ld_tools/ci/default/tree/reference/ld_tools/

Looks like SF GNV ld was last maintained 10 years ago.

But heck that is way later than VMS Alpha!!

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <108sckg$19hcn$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.

I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.

There is a BFD backend for VMS on Alpha in the main binutils
branch in git, but it is not clear to me how well-tested or
generally maintained it is, nor how compatibile with the
standard VMS utilities it ever was; I suspect it existed
primarily to port GNU software to VMS.

What, exactly, are you trying to do?

Well, this is part of bigger rather poorly defined project. ATM
I trying to compile gcc-15.1. I first build binutils, then I do

../gcc-15.1.0/configure --enable-languages=c,c++ --target=alpha-dec-vms --prefix=/sklad/usr
make -j 7 > mlogg 2>&1

There were earlier problems that I resolved. I have now trouble
during linking of libgcc. Some problems went away after switch
from binutils 2.43 to binutils 2.21. But now I get the following
error:

/sklad/usr/alpha-dec-vms/bin/ld: -shared not supported

That is 'ld' from binutils 2.21 says that it does not support
'-shared'. Note that Makefile wants to create 'libgcc_s.exe',
so it knows about VMS file extentions. In other words somebody
at least tried to make it work.

If you want more details I can provide them, but the message
about '-shared' appears also when I attempt to build a
different shared image:

/sklad/usr/alpha-dec-vms/bin/ld -shared -o pop_poll.exe pop_poll.obj

so the problem can be reproduced outside of gcc build.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 8/29/2025 1:32 PM, Waldek Hebisch wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 10:14 AM, Waldek Hebisch wrote:

I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.

I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.

But are you sure you want to do it this way?

My understanding is that you want to do:

source-(compiler on Linux)->.obj->(ld on Linux)->VMS .exe

I would go for:

source-(compiler on Linux)->.obj->(LINK on VMS)->VMS .exe

That is plan B. Working binutils would be simpler because
I could use existing automated process.

But couldn't you have your existing automated process do the
link on VMS via some fancy scripting?

I have little faith in ld producing good VMS .exe.

All the GCC ports to VMS I have seen (GCC 1.4x on VAX,
GCC 2.8.x on Alpha and GNAT 2.8.x on Alpha) have used
VMS linker. I suspect they have their reasons.

Actually, ATM I getting errors during gcc build. I can use
crude workaround to go further, but I am affraid that to get
working compiler I need either working binutils or to examine
all build steps involving binutils and do equvalent work in
different way.

Are you trying to get a recent GCC working on VMS?

In that case there may be some ideas from the GNAT
Itanium port done by the french:

https://github.com/AdaLabs/gnat-vms

Or if possible even better:

source-(compiler on Linux)->.s-(GCC AS on VMS)->.obj-(LINK on VMS)->VMS .exe >>
GCC AS (version 2.8) is working on VMS Alpha.

Actually, it is possible that I will have to use

source-(compiler on Linux)->.s-(VMS assembler)>.obj...

because one of next goals is to get running compiler wich generate(d) assembly for VMS assembler and may be incompatible with GNU as. But
this means more changes to build process (= work work => not better).

If you can generate VMS assembler, then you are all good.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 8/29/2025 1:39 PM, Simon Clubley wrote:

On 2025-08-29, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <108sckg$19hcn$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.

I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.

There is a BFD backend for VMS on Alpha in the main binutils
branch in git, but it is not clear to me how well-tested or
generally maintained it is, nor how compatibile with the
standard VMS utilities it ever was; I suspect it existed
primarily to port GNU software to VMS.

AdaCore was primarily responsible for working on this as part of
GNAT. After they dropped VMS as a supported target, this code may
have gone stale.

Not just AdaCore GNAT (Ada).

ProGIS also tried to make a business of GCC (C and C++) in the
same time frame (25 years ago).

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-08-29, Arne Vajhoj <arne@vajhoej.dk> wrote:

On 8/29/2025 10:14 AM, Waldek Hebisch wrote:

I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.

I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.

I suspect very few try to build VMS executables on Linux.

A decade ago, I got as far as getting a simple C program for VMS Alpha
to compile and link on Linux. Anything else more complicated than that
(ie: other languages) failed and I suspect that either bits were missing
from the public kits or the additional steps required were not obvious.

I discussed this at length in comp.os.vms at the time. Anyone interested
will have to rely on the notes I posted at the time as I have completely forgotten the details of any of this (and have no motivation to get back
up to speed on them because my hobbies these days are very different and because there's no longer a proper hobbyist licence for VMS Alpha).

GNV got both ar and ld, but that does not help you.

But are you sure you want to do it this way?

My understanding is that you want to do:

source-(compiler on Linux)->.obj->(ld on Linux)->VMS .exe

I would go for:

source-(compiler on Linux)->.obj->(LINK on VMS)->VMS .exe

I strongly suspect that will not work as the VMS linker may not
have the features needed to link those .o files.

Or if possible even better:

source-(compiler on Linux)->.s-(GCC AS on VMS)->.obj-(LINK on VMS)->VMS .exe

Er, why ? If you can get the BFD library working for VMS Alpha
once again, that's the major problem sorted.

GCC AS (version 2.8) is working on VMS Alpha.

Also, what makes you think that the GNU gas of that era will still
be suitable for today's compilers ?

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-08-29, Waldek Hebisch <antispam@fricas.org> wrote:

Arne Vajhoj <arne@vajhoej.dk> wrote:

On 8/29/2025 10:14 AM, Waldek Hebisch wrote:

I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.

I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.

I suspect very few try to build VMS executables on Linux.

GNV got both ar and ld, but that does not help you.

Where are the sources? Working sources certainly would help.

Aren't they simply wrappers around the native VMS utilities ?

But are you sure you want to do it this way?

My understanding is that you want to do:

source-(compiler on Linux)->.obj->(ld on Linux)->VMS .exe

I would go for:

source-(compiler on Linux)->.obj->(LINK on VMS)->VMS .exe

That is plan B. Working binutils would be simpler because
I could use existing automated process.

Binutils worked at one time because I was able to do the whole
sequence, including generating the final C VMS executable, on Linux.

Actually, ATM I getting errors during gcc build. I can use
crude workaround to go further, but I am affraid that to get
working compiler I need either working binutils or to examine
all build steps involving binutils and do equvalent work in
different way.

That's where I gave up. I either didn't understand the required
VMS-specific build steps or there were bits missing from the public
source kits.

Note that I have a lot of experience building cross compilers on Linux
for various embedded targets (including fixing various problems
I encountered along the way), and I have never had a fraction of the
problems I had when trying to get VMS support working.

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-08-29, Arne Vajhoj <arne@vajhoej.dk> wrote:

I have little faith in ld producing good VMS .exe.

That bit worked just fine, but I don't remember if I had to fix up
anything in the BFD librayr first. The problem seems to be that the
current version of the BFD library has stagnated for VMS Alpha and
appears to need bringing up to date.

All the GCC ports to VMS I have seen (GCC 1.4x on VAX,
GCC 2.8.x on Alpha and GNAT 2.8.x on Alpha) have used
VMS linker. I suspect they have their reasons.

AdaCore started with a cross compiler on Linux.

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 8/29/2025 1:57 PM, Simon Clubley wrote:

On 2025-08-29, Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 10:14 AM, Waldek Hebisch wrote:

I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.

I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.

But are you sure you want to do it this way?

My understanding is that you want to do:

source-(compiler on Linux)->.obj->(ld on Linux)->VMS .exe

I would go for:

source-(compiler on Linux)->.obj->(LINK on VMS)->VMS .exe

I strongly suspect that will not work as the VMS linker may not
have the features needed to link those .o files.

If the .o files are not valid VMS .obj files, then it will
not work.

But the VMS Alpha target of gcc-as did generate valid
VMS .obj files back in time.

I don't see why anyone should have changed that since.

Or if possible even better:

source-(compiler on Linux)->.s-(GCC AS on VMS)->.obj-(LINK on VMS)->VMS .exe

Er, why ? If you can get the BFD library working for VMS Alpha
once again, that's the major problem sorted.

Getting it working 100% may be a huge effort.

Generating a text file and using the native tools on VMS
seems much less risk and effort to me.

GCC AS (version 2.8) is working on VMS Alpha.

Also, what makes you think that the GNU gas of that era will still
be suitable for today's compilers ?

I would expect Alpha assembler to still be Alpha assembler.

The instructions are obviously the same.

And I find it unlikely that anyone has spend time the last 25
years adding advanced macros and pseudo instructions to the
Alpha assembler and the compiler.

Given the status of Alpha.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 8/29/2025 2:11 PM, Simon Clubley wrote:

On 2025-08-29, Arne Vajh|+j <arne@vajhoej.dk> wrote:

All the GCC ports to VMS I have seen (GCC 1.4x on VAX,
GCC 2.8.x on Alpha and GNAT 2.8.x on Alpha) have used
VMS linker. I suspect they have their reasons.

AdaCore started with a cross compiler on Linux.

But did they use ld on Linux or LINK on VMS?

Arne




--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-08-29, Arne Vajhoj <arne@vajhoej.dk> wrote:

On 8/29/2025 1:57 PM, Simon Clubley wrote:

Also, what makes you think that the GNU gas of that era will still
be suitable for today's compilers ?

I would expect Alpha assembler to still be Alpha assembler.

And are you sure that VMS gas 2.8 will support all of the following:

https://sourceware.org/binutils/docs/as/Pseudo-Ops.html

(Those are just the current target-neutral directives).

The instructions are obviously the same.

And I find it unlikely that anyone has spend time the last 25
years adding advanced macros and pseudo instructions to the
Alpha assembler and the compiler.

That's not where the problem is. You need to think at a higher level
than that. Notice that I said today's compilers which may rely on
underlying features not present in that old VMS Alpha version of gas.

Alpha is but one BFD target. Compilers do not talk to the VMS Alpha
gas directly. The following may help you understand the overall flow:

https://en.wikipedia.org/wiki/Binary_File_Descriptor_library

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 8/29/2025 2:28 PM, Simon Clubley wrote:

On 2025-08-29, Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 1:57 PM, Simon Clubley wrote:

Also, what makes you think that the GNU gas of that era will still
be suitable for today's compilers ?

I would expect Alpha assembler to still be Alpha assembler.

And are you sure that VMS gas 2.8 will support all of the following:

https://sourceware.org/binutils/docs/as/Pseudo-Ops.html

(Those are just the current target-neutral directives).

The instructions are obviously the same.

And I find it unlikely that anyone has spend time the last 25
years adding advanced macros and pseudo instructions to the
Alpha assembler and the compiler.

That's not where the problem is. You need to think at a higher level
than that. Notice that I said today's compilers which may rely on
underlying features not present in that old VMS Alpha version of gas.

If some of those directives was not supported in GCC 2.8 as
and those directives are actually generated by the compiler
for the VMS Alpha target (because they are generated on all
target or was added to Alpha target later for the benefit
of other OS), then GCC 2.8 as will obviously not work.

It may still be easier to hack the compiler to not use
those than to reverse engineer LINK though.
Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-08-29, Arne Vajhoj <arne@vajhoej.dk> wrote:

On 8/29/2025 2:11 PM, Simon Clubley wrote:

On 2025-08-29, Arne Vajhoj <arne@vajhoej.dk> wrote:

All the GCC ports to VMS I have seen (GCC 1.4x on VAX,
GCC 2.8.x on Alpha and GNAT 2.8.x on Alpha) have used
VMS linker. I suspect they have their reasons.

AdaCore started with a cross compiler on Linux.

But did they use ld on Linux or LINK on VMS?

From what I remember, everything was pure GNU, including the use
of binutils, or at least it was by the time I started becoming
interested in this.

It's possible however that earlier efforts did involve native VMS
tools, but by the time I became interested in building binutils/gcc
from source the standard approach appears to have been via binutils.

Just had a quick look and there are patch emails online
showing AdaCore working on binutils to add and extend VMS support.

What I can't remember is if prior to this, AdaCore had their own
private gcc/binutils branch and if they only started pushing into
the public branches later on. I have some vague memories in this
area, but it's been so long ago, I could simply be wrong.

If anyone still has it installed, does the really old GNAT 3.11/3.12p
use ld or the VMS linker ? I know they used gas, but what about the
final link ?

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <108splv$24jsc$2@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-08-29, Arne Vajhoj <arne@vajhoej.dk> wrote:

On 8/29/2025 10:14 AM, Waldek Hebisch wrote:

I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.

I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.

I suspect very few try to build VMS executables on Linux.

A decade ago, I got as far as getting a simple C program for VMS Alpha
to compile and link on Linux. Anything else more complicated than that
(ie: other languages) failed and I suspect that either bits were missing
from the public kits or the additional steps required were not obvious.

I discussed this at length in comp.os.vms at the time. Anyone interested
will have to rely on the notes I posted at the time as I have completely >forgotten the details of any of this (and have no motivation to get back
up to speed on them because my hobbies these days are very different and >because there's no longer a proper hobbyist licence for VMS Alpha).

GNV got both ar and ld, but that does not help you.

But are you sure you want to do it this way?

My understanding is that you want to do:

source-(compiler on Linux)->.obj->(ld on Linux)->VMS .exe

I would go for:

source-(compiler on Linux)->.obj->(LINK on VMS)->VMS .exe

I strongly suspect that will not work as the VMS linker may not
have the features needed to link those .o files.

What features? Presumably the `.o` files generated are actually
VMS `.OBJ` files. I suppose the compiler could generate generic
ELF or COFF or a.out objects for Alpha, and then rely on GNU LD
to do the right thing and convert them to a properly linked VMS
executable, but that seems a rather roundabout way to go.

Or if possible even better:

source-(compiler on Linux)->.s-(GCC AS on VMS)->.obj-(LINK on VMS)->VMS .exe

Er, why ? If you can get the BFD library working for VMS Alpha
once again, that's the major problem sorted.

GCC AS (version 2.8) is working on VMS Alpha.

Also, what makes you think that the GNU gas of that era will still
be suitable for today's compilers ?

I'd be rather surprised if much had changed in that department.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 8/29/2025 2:44 PM, Simon Clubley wrote:

If anyone still has it installed, does the really old GNAT 3.11/3.12p
use ld or the VMS linker ? I know they used gas, but what about the
final link ?

I have Gnat 3.12p / GCC 2.8.1 installed.

I think it uses LINK.

<quote>
$ gnat make
List of available qualifiers and options

GNAT MAKE file /qualifiers (includes COMPILE /qualifiers)
gnatmake
...
/LINKER_QUALIFIERS (switches for LINK) -largs switches
...
</quote>

It mentions LINK.

<quote>
$ gnat make hello /verbose

GNATMAKE 3.12p (19990629) Copyright 1995-1999 Free Software Foundation,
Inc.
"hello.ali" being checked ...
-> "hello.ali" missing.
gcc -c hello.adb
gnatbind -x hello.ali
gnatlink hello.ali
GNU:[LIB]CRT0.OBJ
DISK2:[ARNE]B$HELLO.OBJ
DISK2:[]HELLO.OBJ
GNU:[LIB.OPENVMS7_1.2_8_1.DECLIB]LIBDECGNAT.OLB/library GNU:[LIB.OPENVMS7_1.2_8_1.ADALIB]LIBGNAT.EXE/shareable GNU:[LIB]LIBGCC.OLB/library
sys$library:vaxcrtltx.olb/library
GNU:[LIB]LIBGCC.OLB/library
</quote>

That looks very much like VMS LINK option format.

Arne


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-08-29, Arne Vajhoj <arne@vajhoej.dk> wrote:

On 8/29/2025 2:44 PM, Simon Clubley wrote:

If anyone still has it installed, does the really old GNAT 3.11/3.12p
use ld or the VMS linker ? I know they used gas, but what about the
final link ?

I have Gnat 3.12p / GCC 2.8.1 installed.

I think it uses LINK.

<quote>
$ gnat make
List of available qualifiers and options

GNAT MAKE file /qualifiers (includes COMPILE /qualifiers)
gnatmake
...
/LINKER_QUALIFIERS (switches for LINK) -largs switches
...
</quote>

It mentions LINK.

Interesting thanks. Does the "ld" binary exist in whatever the binutils executables directory is ?

If it does, and you run it as a foreign command with "--help", what
output do you get ?

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 8/29/2025 3:10 PM, Simon Clubley wrote:

On 2025-08-29, Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 2:44 PM, Simon Clubley wrote:

If anyone still has it installed, does the really old GNAT 3.11/3.12p
use ld or the VMS linker ? I know they used gas, but what about the
final link ?

I have Gnat 3.12p / GCC 2.8.1 installed.

I think it uses LINK.

<quote>
$ gnat make
List of available qualifiers and options

GNAT MAKE file /qualifiers (includes COMPILE /qualifiers)
gnatmake
...
/LINKER_QUALIFIERS (switches for LINK) -largs switches
...
</quote>

It mentions LINK.

Interesting thanks. Does the "ld" binary exist in whatever the binutils executables directory is ?

If it does, and you run it as a foreign command with "--help", what
output do you get ?

Nothing with ld.

$ dir gnu:[bin]

Directory GNU:[BIN]

AS.EXE;10 ASISTANT.EXE;1 GCC.EXE;1 GNAT.EXE;1 GNATBIND.EXE;1 GNATBL.EXE;1 GNATCHOP.EXE;2 GNATELIM.EXE;1 GNATFIND.EXE;1 GNATKR.EXE;1 GNATLBR.EXE;1 GNATLINK.EXE;1 GNATLS.EXE;1 GNATMAKE.EXE;1 GNATMEM.EXE;1 GNATPREP.EXE;1 GNATPSTA.EXE;1 GNATPSYS.EXE;1 GNATSTUB.EXE;1 GNATXREF.EXE;1 MAKE.EXE;260 OPENVMS7_1-GCC.EXE;1 SET_EXE.COM;11

$ dir gnu:[bin]*ld*.*
%DIRECT-W-NOFILES, no files found

Arne


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 8/29/2025 3:14 PM, Arne Vajh|+j wrote:

On 8/29/2025 3:10 PM, Simon Clubley wrote:

On 2025-08-29, Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 2:44 PM, Simon Clubley wrote:

If anyone still has it installed, does the really old GNAT 3.11/3.12p
use ld or the VMS linker ? I know they used gas, but what about the
final link ?

I have Gnat 3.12p / GCC 2.8.1 installed.

I think it uses LINK.

<quote>
$ gnat make
List of available qualifiers and options

GNAT MAKE file /qualifiers (includes COMPILE /qualifiers)
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a gnatmake
-a-a-a-a ...
-a-a-a-a /LINKER_QUALIFIERS (switches for LINK)-a-a-a-a-a-a-a-a-a-a -largs switches
-a-a-a-a ...
</quote>

It mentions LINK.

Interesting thanks. Does the "ld" binary exist in whatever the binutils
executables directory is ?

If it does, and you run it as a foreign command with "--help", what
output do you get ?

Nothing with ld.

$ dir gnu:[bin]

Directory GNU:[BIN]

AS.EXE;10-a-a-a-a-a-a-a-a-a-a ASISTANT.EXE;1-a-a-a-a-a GCC.EXE;1-a-a-a-a-a-a-a-a-a-a GNAT.EXE;1
GNATBIND.EXE;1-a-a-a-a-a GNATBL.EXE;1-a-a-a-a-a-a-a GNATCHOP.EXE;2-a-a-a-a-a GNATELIM.EXE;1
GNATFIND.EXE;1-a-a-a-a-a GNATKR.EXE;1-a-a-a-a-a-a-a GNATLBR.EXE;1-a-a-a-a-a-a GNATLINK.EXE;1
GNATLS.EXE;1-a-a-a-a-a-a-a GNATMAKE.EXE;1-a-a-a-a-a GNATMEM.EXE;1-a-a-a-a-a-a GNATPREP.EXE;1
GNATPSTA.EXE;1-a-a-a-a-a GNATPSYS.EXE;1-a-a-a-a-a GNATSTUB.EXE;1-a-a-a-a-a GNATXREF.EXE;1
MAKE.EXE;260-a-a-a-a-a-a-a OPENVMS7_1-GCC.EXE;1-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a SET_EXE.COM;11

$ dir gnu:[bin]*ld*.*
%DIRECT-W-NOFILES, no files found

$ link=="XXXX"
$ link
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\XXXX\
$ gnat make hello
gcc -c hello.adb
gnatbind -x hello.ali
gnatlink hello.ali
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\XXXX\
gnatmake: *** link failed.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <108sp9v$1a4ae$2@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <108sckg$19hcn$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.

I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.

There is a BFD backend for VMS on Alpha in the main binutils
branch in git, but it is not clear to me how well-tested or
generally maintained it is, nor how compatibile with the
standard VMS utilities it ever was; I suspect it existed
primarily to port GNU software to VMS.

What, exactly, are you trying to do?

Well, this is part of bigger rather poorly defined project. ATM
I trying to compile gcc-15.1.

That's a pretty big project in itself. I expect, as others have
noted and I mentioned earlier, that the port to VMS has fallen
into disrepair. Getting it back up to snuff will likely be
hard.

I first build binutils, then I do

../gcc-15.1.0/configure --enable-languages=c,c++ --target=alpha-dec-vms --prefix=/sklad/usr
make -j 7 > mlogg 2>&1

There were earlier problems that I resolved. I have now trouble
during linking of libgcc. Some problems went away after switch
from binutils 2.43 to binutils 2.21. But now I get the following
error:

/sklad/usr/alpha-dec-vms/bin/ld: -shared not supported

That is 'ld' from binutils 2.21 says that it does not support
'-shared'. Note that Makefile wants to create 'libgcc_s.exe',
so it knows about VMS file extentions. In other words somebody
at least tried to make it work.

It definitely ran on VMS in the past. I don't think anyone has
actively tried to remove VMS support. So it's very likely you
are getting the vestigal remnants on that prior porting effort,
along with a lot of what one might refer to as "soft" bugs; that
is, things that are not outright _wrong_ in the code, but which
exhibit incorrect behavior on VMS because no one has been
actively maintaining the GCC VMS port.

If you want more details I can provide them, but the message
about '-shared' appears also when I attempt to build a
different shared image:

/sklad/usr/alpha-dec-vms/bin/ld -shared -o pop_poll.exe pop_poll.obj

so the problem can be reproduced outside of gcc build.

I mean, in a way the meaning of the message is obvious: that
flag is not supported on the version of binutils you built for
VMS. Merely getting confirmation of that is unlikely to yield
much in the way of insightful new information, as it says it
right on the tin.

The more pressing question is *why* is the flag unsupported?
Figure that out and you'll likely unlock the entire thing.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 8/29/2025 1:50 PM, Waldek Hebisch wrote:

There were earlier problems that I resolved. I have now trouble
during linking of libgcc. Some problems went away after switch
from binutils 2.43 to binutils 2.21. But now I get the following
error:

/sklad/usr/alpha-dec-vms/bin/ld: -shared not supported

That is 'ld' from binutils 2.21 says that it does not support
'-shared'. Note that Makefile wants to create 'libgcc_s.exe',
so it knows about VMS file extentions. In other words somebody
at least tried to make it work.

If you want more details I can provide them, but the message
about '-shared' appears also when I attempt to build a
different shared image:

/sklad/usr/alpha-dec-vms/bin/ld -shared -o pop_poll.exe pop_poll.obj

so the problem can be reproduced outside of gcc build.

https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/vms-alpha.c;h=c4b248494ee624f7b1d6acbf45065469cda7c682;hb=HEAD

says:

<quote>
/* vms.c -- BFD back-end for EVAX (openVMS/Alpha) files.
Copyright (C) 1996-2025 Free Software Foundation, Inc.

Initial version written by Klaus Kaempf (kkaempf@rmi.de)
Major rewrite by Adacore.

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston,
MA 02110-1301, USA. */

/* TODO:
o overlayed sections
o PIC
o Generation of shared image
o Relocation optimizations
o EISD for the stack
o Vectors isect
o 64 bits sections
o Entry point
o LIB$INITIALIZE
o protected sections (for messages)
...
*/
</quote>

It is on the TODO list.

Which of course does not help you much.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 8/29/2025 1:57 PM, Simon Clubley wrote:

On 2025-08-29, Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 10:14 AM, Waldek Hebisch wrote:

I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.

I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.

I suspect very few try to build VMS executables on Linux.

A decade ago, I got as far as getting a simple C program for VMS Alpha
to compile and link on Linux. Anything else more complicated than that
(ie: other languages) failed and I suspect that either bits were missing
from the public kits or the additional steps required were not obvious.

I discussed this at length in comp.os.vms at the time. Anyone interested
will have to rely on the notes I posted at the time as I have completely forgotten the details of any of this (and have no motivation to get back
up to speed on them because my hobbies these days are very different and because there's no longer a proper hobbyist licence for VMS Alpha).

I did the search:

https://groups.google.com/g/comp.os.vms/c/KN9yqM7_8PU/m/T4xwyTz5A3oJ

https://groups.google.com/g/comp.os.vms/c/S7-VwQmmOZU/m/LXQ2TrbCBAAJ

https://groups.google.com/g/comp.os.vms/c/oSNzXLKeu4o/m/8Tq5dIFaDAAJ

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 1:32 PM, Waldek Hebisch wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 10:14 AM, Waldek Hebisch wrote:

I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.

I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.

I suspect very few try to build VMS executables on Linux.

GNV got both ar and ld, but that does not help you.

Where are the sources? Working sources certainly would help.

There are the SourceForge version of GNV and there is the
VSI version of GNV.

The SF version is here:

https://sourceforge.net/p/gnv/ld_tools/ci/default/tree/reference/ld_tools/

Thanks. AFAICS main work is done by VMS binaries, so it does not
help in my immediate problem, but it contains interesting information.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:

On 2025-08-29, Waldek Hebisch <antispam@fricas.org> wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 10:14 AM, Waldek Hebisch wrote:

I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.

I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.

I suspect very few try to build VMS executables on Linux.

GNV got both ar and ld, but that does not help you.

Where are the sources? Working sources certainly would help.

Aren't they simply wrappers around the native VMS utilities ?

Unfortunately yes.

But are you sure you want to do it this way?

My understanding is that you want to do:

source-(compiler on Linux)->.obj->(ld on Linux)->VMS .exe

I would go for:

source-(compiler on Linux)->.obj->(LINK on VMS)->VMS .exe

That is plan B. Working binutils would be simpler because
I could use existing automated process.

Binutils worked at one time because I was able to do the whole
sequence, including generating the final C VMS executable, on Linux.

Thanks, good to know this.

Actually, ATM I getting errors during gcc build. I can use
crude workaround to go further, but I am affraid that to get
working compiler I need either working binutils or to examine
all build steps involving binutils and do equvalent work in
different way.

That's where I gave up. I either didn't understand the required
VMS-specific build steps or there were bits missing from the public
source kits.

There are missing pieces, build needs VMS header files and libraries.
If those pieces are incomplete, then configuration may go wrong
and lead to trobles later.

Currently I have fairly incomplete set of header files, so I expect
trouble due to this. OTOH libgcc seem to compile fine, so C
compiler probably will work. I worked around trouble with
shared images by configuring gcc with '--disable-shared',
suboptimal but must do for now.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-08-30, Arne Vajhoj <arne@vajhoej.dk> wrote:

On 8/29/2025 1:57 PM, Simon Clubley wrote:

A decade ago, I got as far as getting a simple C program for VMS Alpha
to compile and link on Linux. Anything else more complicated than that
(ie: other languages) failed and I suspect that either bits were missing
from the public kits or the additional steps required were not obvious.

I discussed this at length in comp.os.vms at the time. Anyone interested
will have to rely on the notes I posted at the time as I have completely
forgotten the details of any of this (and have no motivation to get back
up to speed on them because my hobbies these days are very different and
because there's no longer a proper hobbyist licence for VMS Alpha).

I did the search:

https://groups.google.com/g/comp.os.vms/c/KN9yqM7_8PU/m/T4xwyTz5A3oJ

https://groups.google.com/g/comp.os.vms/c/S7-VwQmmOZU/m/LXQ2TrbCBAAJ

https://groups.google.com/g/comp.os.vms/c/oSNzXLKeu4o/m/8Tq5dIFaDAAJ

Yeah, there's useful stuff in the above that I had completely forgotten
about. It looks like 2017 was a _really_ busy year for me, both at the
start and the end of the year. :-)

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-08-30, Waldek Hebisch <antispam@fricas.org> wrote:

Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:

That's where I gave up. I either didn't understand the required
VMS-specific build steps or there were bits missing from the public
source kits.

There are missing pieces, build needs VMS header files and libraries.
If those pieces are incomplete, then configuration may go wrong
and lead to trobles later.

Currently I have fairly incomplete set of header files, so I expect
trouble due to this. OTOH libgcc seem to compile fine, so C
compiler probably will work. I worked around trouble with
shared images by configuring gcc with '--disable-shared',
suboptimal but must do for now.

If you look at the links Arne posted, you will see I took across to
Linux the VMS-supplied header files inc addition to the libraries.
According to those notes, it appears I also had to write patches
for those headers.

When I talked about bits missing, I wasn't thinking about the headers
and libraries. Given that Adacore didn't start using Newlib or something similar to support VMS, that was pretty much expected.

I was thinking more about bits missing within the compiler or binutils
itself, especially given the crashes I had with Fortran. I was wondering
if, for example, there are bits missing in the image initialisation
sequence, along with other similar types of missing bits.

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 1:57 PM, Simon Clubley wrote:

On 2025-08-29, Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 10:14 AM, Waldek Hebisch wrote:

I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.

I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.

I suspect very few try to build VMS executables on Linux.

A decade ago, I got as far as getting a simple C program for VMS Alpha
to compile and link on Linux. Anything else more complicated than that
(ie: other languages) failed and I suspect that either bits were missing
from the public kits or the additional steps required were not obvious.

I discussed this at length in comp.os.vms at the time. Anyone interested
will have to rely on the notes I posted at the time as I have completely
forgotten the details of any of this (and have no motivation to get back
up to speed on them because my hobbies these days are very different and
because there's no longer a proper hobbyist licence for VMS Alpha).

I did the search:

https://groups.google.com/g/comp.os.vms/c/KN9yqM7_8PU/m/T4xwyTz5A3oJ

https://groups.google.com/g/comp.os.vms/c/S7-VwQmmOZU/m/LXQ2TrbCBAAJ

https://groups.google.com/g/comp.os.vms/c/oSNzXLKeu4o/m/8Tq5dIFaDAAJ

Thanks, I have read the posts. ATM I am at earlier stage than Simon.
IIUC problems with binutils-27 should not affect me as I am currently
using binutils 2.21.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:

On 2025-08-30, Waldek Hebisch <antispam@fricas.org> wrote:

Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:

That's where I gave up. I either didn't understand the required
VMS-specific build steps or there were bits missing from the public
source kits.

There are missing pieces, build needs VMS header files and libraries.
If those pieces are incomplete, then configuration may go wrong
and lead to trobles later.

Currently I have fairly incomplete set of header files, so I expect
trouble due to this. OTOH libgcc seem to compile fine, so C
compiler probably will work. I worked around trouble with
shared images by configuring gcc with '--disable-shared',
suboptimal but must do for now.

If you look at the links Arne posted, you will see I took across to
Linux the VMS-supplied header files inc addition to the libraries.
According to those notes, it appears I also had to write patches
for those headers.

I saw Arne message only after writing message above. My approach
differs, namely I use headers that I created. They have minimal
content, basically what is needed to compile libgcc and a few other
things. ATM I am working at creating needed libraries. My
understanding is that for linking purposes I do not need any real
code in the libraries, just function names (in correct order).

I hoped that linking could be done without any libraries (this is
possible on most platforms), but VMS ld in binutils insists on having
libraries and up to now I have no work around for this.

When I talked about bits missing, I wasn't thinking about the headers
and libraries. Given that Adacore didn't start using Newlib or something similar to support VMS, that was pretty much expected.

I was thinking more about bits missing within the compiler or binutils itself, especially given the crashes I had with Fortran. I was wondering
if, for example, there are bits missing in the image initialisation
sequence, along with other similar types of missing bits.

Do you have any indications that gcc Fortran or C++ worked on VMS say 25
years ago? Presumably Ada Core cared mostly about Ada. To build Ada
compiler they needed to build C compiler first. I do not know if they
ever supported on VMS gcc version recent enough to require C++ to build.
If C++ and/or Fortran was never supported, then missing pieces in runtime support are expected. Also, there may be new pieces of platform support
needed by newer compiler versions, that nobody bothered to add for VMS.

BTW: I compared VMS specific headers in binutils-2.21 and binutils-2.43.
They are the same, except for some comment changes. OTOH headers seem
to match reasonably well with file structure.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/1/2025 2:33 PM, Waldek Hebisch wrote:

Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:

When I talked about bits missing, I wasn't thinking about the headers
and libraries. Given that Adacore didn't start using Newlib or something
similar to support VMS, that was pretty much expected.

I was thinking more about bits missing within the compiler or binutils
itself, especially given the crashes I had with Fortran. I was wondering
if, for example, there are bits missing in the image initialisation
sequence, along with other similar types of missing bits.

Do you have any indications that gcc Fortran or C++ worked on VMS say 25 years ago? Presumably Ada Core cared mostly about Ada. To build Ada compiler they needed to build C compiler first. I do not know if they
ever supported on VMS gcc version recent enough to require C++ to build.
If C++ and/or Fortran was never supported, then missing pieces in runtime support are expected. Also, there may be new pieces of platform support needed by newer compiler versions, that nobody bothered to add for VMS.

C and C++ worked in 1.4x on VAX and 2.8.x on Alpha.

The first I remember. I used it pretty extensively.

The second I can demo:

$ type hello.c
#include <stdio.h>

int main()
{
printf("Hello world from C!\n");
return 0;
}
$ gcc hello.c
$ gcclink hello
$ r hello
Hello world from C!

and:

$ type hello.cc
#include <iostream.h>

int main()
{
cout << "Hello world from C++!" << endl;
return 0;
}
$ gxx hello.cc
$ gxxlink hello
$ r hello
Hello world from C++!

ProGIS tried to make a business out of GCC and GXX on VMS. I don't
think that ever turned profitable.

I don't think I ever say G77 on VMS (back then it was G77 not GFortran).

Also note that C++ back then was before C++98 and the language and
runtime was not quite as well defined.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/1/2025 3:02 PM, Arne Vajh|+j wrote:

C and C++ worked in 1.4x on VAX and 2.8.x on Alpha.

The first I remember. I used it pretty extensively.

The second I can demo:

I believe that both the 1.4x and 2.8.x stuff made it
to DECUS LT tapes.

There is a copy of the 2.8.x Alpha stuff here:
https://www.vajhoej.dk/arne/vmsstuff/gccbeta/

It is the original with a few changes to COM files
(and maybe OPT files) back then to make it work better
and a few changes to COM files later to accomodate
newer VMS versions.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-09-01, Waldek Hebisch <antispam@fricas.org> wrote:

Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:

When I talked about bits missing, I wasn't thinking about the headers
and libraries. Given that Adacore didn't start using Newlib or something
similar to support VMS, that was pretty much expected.

I was thinking more about bits missing within the compiler or binutils
itself, especially given the crashes I had with Fortran. I was wondering
if, for example, there are bits missing in the image initialisation
sequence, along with other similar types of missing bits.

Do you have any indications that gcc Fortran or C++ worked on VMS say 25 years ago? Presumably Ada Core cared mostly about Ada. To build Ada compiler they needed to build C compiler first. I do not know if they
ever supported on VMS gcc version recent enough to require C++ to build.
If C++ and/or Fortran was never supported, then missing pieces in runtime support are expected. Also, there may be new pieces of platform support needed by newer compiler versions, that nobody bothered to add for VMS.

I do not know about Fortran, but C++ used to work IIRC, and Arne
appears to be confirming that as well. I cannot remember if I tried
C++ but I have a vague memory I did and had similar problems to Fortran,
but it's long enough ago that I may be wrong about that.

The other reason I suspect things might be missing or may have an
unusual build sequence I am not aware of is because I could not get
the Ada compiler itself to build.

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/1/2025 5:00 PM, Simon Clubley wrote:

On 2025-09-01, Waldek Hebisch <antispam@fricas.org> wrote:

Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:

When I talked about bits missing, I wasn't thinking about the headers
and libraries. Given that Adacore didn't start using Newlib or something >>> similar to support VMS, that was pretty much expected.

I was thinking more about bits missing within the compiler or binutils
itself, especially given the crashes I had with Fortran. I was wondering >>> if, for example, there are bits missing in the image initialisation
sequence, along with other similar types of missing bits.

Do you have any indications that gcc Fortran or C++ worked on VMS say 25
years ago? Presumably Ada Core cared mostly about Ada. To build Ada
compiler they needed to build C compiler first. I do not know if they
ever supported on VMS gcc version recent enough to require C++ to build.
If C++ and/or Fortran was never supported, then missing pieces in runtime
support are expected. Also, there may be new pieces of platform support
needed by newer compiler versions, that nobody bothered to add for VMS.

I do not know about Fortran, but C++ used to work IIRC, and Arne
appears to be confirming that as well. I cannot remember if I tried
C++ but I have a vague memory I did and had similar problems to Fortran,
but it's long enough ago that I may be wrong about that.

Note that the 2.8.x stuff used VMS LINK.

$ gccl*ink :== @gccbetadir:[000000]gcclink.com
$ gxxl*ink :== @gccbetadir:[000000]gxxlink.com

gcclink.com:

$ link 'p1', -
gnu_cc_library:libgcc.olb/library, -
gnu_cc_library:crt0.obj
$ exit

gxxlink.com:

$ if p2 .eqs. ""
$ then
$ link/exe='f$parse(p1,,,"NAME")' gnu_cc_library:crtbegin.obj, -
'f$parse(p1,"sys$disk:[].obj")', -
gnu_cc_library:libstdcxx.olb/lib, -
gnu_cc_library:libgccplus.olb/lib, -
gnu_cc_library:libgxx.olb/lib, -
gnu_cc_library:libgcc.olb/lib, -
gnu_cc_library:crtend.obj, -
sys$library:vaxcrtl.olb/lib, -
gnu_cc_library:gxx_main.obj
$ else
$ link/exe='f$parse(p1,,,"NAME")' gnu_cc_library:crtbegin.obj, -
'f$parse(p1,"sys$disk:[].obj")', -
'p2'/lib,-
gnu_cc_library:libstdcxx.olb/lib, -
gnu_cc_library:libgccplus.olb/lib, -
gnu_cc_library:libgxx.olb/lib, -
gnu_cc_library:libgcc.olb/lib, -
gnu_cc_library:crtend.obj, -
sys$library:vaxcrtl.olb/lib, -
gnu_cc_library:gxx_main.obj
$ endif
$ exit

The C++ link needed many more pieces than the C link.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/2/2025 8:59 AM, Waldek Hebisch wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 1:57 PM, Simon Clubley wrote:

A decade ago, I got as far as getting a simple C program for VMS Alpha
to compile and link on Linux. Anything else more complicated than that
(ie: other languages) failed and I suspect that either bits were missing >>> from the public kits or the additional steps required were not obvious.

I discussed this at length in comp.os.vms at the time. Anyone interested >>> will have to rely on the notes I posted at the time as I have completely >>> forgotten the details of any of this (and have no motivation to get back >>> up to speed on them because my hobbies these days are very different and >>> because there's no longer a proper hobbyist licence for VMS Alpha).

I did the search:

https://groups.google.com/g/comp.os.vms/c/KN9yqM7_8PU/m/T4xwyTz5A3oJ

https://groups.google.com/g/comp.os.vms/c/S7-VwQmmOZU/m/LXQ2TrbCBAAJ

https://groups.google.com/g/comp.os.vms/c/oSNzXLKeu4o/m/8Tq5dIFaDAAJ

I looked deeper at the last message (one with 8Tq5dIFaDAAJ at the end).
The fix for PR 17512 is clearly wrong: 'struct vms_eihd' is deliberatly bigger than typical headers. Reverting this and similar fix for
PR 21813 allows objdump from binutils-2.39 to disassemble VMS shared
images with small header. However, cross binutils-2.39 can not read
VMS object files, and any attempts at linking give result like:

foo.obj: file not recognized: file format not recognized

VMS EXE is FIX 512, which is FTP binary friendly.

VMS OBJ is VAR, which is not FTP binary friendly and FTP
text will likely fuck up the file.

I would:
* $ SET FILE/ATTR=(RFM:FIX,MRS:512) on the OBJ file on VMS
* FTP binary to Linux
* see if objdump on Linux can recognize it

Arne



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/2/25 22:37, Arne Vajh|+j wrote:

On 9/2/2025 8:59 AM, Waldek Hebisch wrote:

...
I looked deeper at the last message (one with 8Tq5dIFaDAAJ at the end).
The fix for PR 17512 is clearly wrong: 'struct vms_eihd' is deliberatly
bigger than typical headers.-a Reverting this and similar fix for
PR 21813 allows objdump from binutils-2.39 to disassemble VMS shared
images with small header.-a However, cross binutils-2.39 can not read
VMS object files, and any attempts at linking give result like:

foo.obj: file not recognized: file format not recognized

VMS EXE is FIX 512, which is FTP binary friendly.

VMS OBJ is VAR, which is not FTP binary friendly and FTP
text will likely fuck up the file.

I would:
* $ SET FILE/ATTR=(RFM:FIX,MRS:512) on the OBJ file on VMS
* FTP binary to Linux
* see if objdump on Linux can recognize it

Check out with "objdump -i" if your objdump supports the VMS object
format for Alpha.

The one I installed from the distributions repository does not. You very likely have to rebuild objdump.

Changing the file attributes or zipping the object file with "-V" will preserve the internal record structure. Works for me:

$ ./gsdeobj -v m.obj
GSD for OpenVMS/Alpha object files, V0.94
EMH:
name: M
version: V1.0
date: 15-AUG-2025 09:41
LNM:
VSI C V7.4-002
Type Flags caPSIndx PSIndx Name
PSECT P--r-SE------ 0 $CODE$
PSECT P--r-S-R--N-- 1 $LITERAL$
PSECT ---r---R----- 2 $LINK$
PROCEDURE -D-R--N- 0 2 M
UDFSYM -------- F
UDFSYM -------- G
EOM:
total linkage pairs: 2
completion code: 0x0
SUCCESS
transfer address flag: 0x1
WEAK
transfer address PSECT index: 2
transfer address: 0x0
Record summary:
emh: 2, eom: 1, gsd: 2, tir: 2, dbg: 0, tbt: 4
psc: 3, sym: 3
Keys to PSECT flags:
P - PIC, position independent L - LIB, from shareable image
O - OVR, overlaid allocation r - REL, relocatable
G - GBL, global S - SHR, shareable
E - EXE, executable R - RD, readable
W - WRT, writeable V - VEC, vector
N - NOMOD, not stored into C - COM, allocation for common symbol
A - ALLOC_64BIT, allocate in 64-bit space
Keys to symbol flags:
W - WEAK, weak D - DEF, definition
U - UNI, universal R - REL, relocatable
C - COMM, common V - VECEP, vectored entry point
N - NORM, procedure Q - QUAD_VAL, value is 64 bits
$
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 02/09/2025 21:37, Arne Vajh|+j wrote:

VMS OBJ is VAR, which is not FTP binary friendly and FTP
text will likely fuck up the file.

Arne

I trust that is a technical term ;)
--
Chris
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 9/2/2025 8:59 AM, Waldek Hebisch wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 1:57 PM, Simon Clubley wrote:

A decade ago, I got as far as getting a simple C program for VMS Alpha >>>> to compile and link on Linux. Anything else more complicated than that >>>> (ie: other languages) failed and I suspect that either bits were missing >>>> from the public kits or the additional steps required were not obvious. >>>>
I discussed this at length in comp.os.vms at the time. Anyone interested >>>> will have to rely on the notes I posted at the time as I have completely >>>> forgotten the details of any of this (and have no motivation to get back >>>> up to speed on them because my hobbies these days are very different and >>>> because there's no longer a proper hobbyist licence for VMS Alpha).

I did the search:

https://groups.google.com/g/comp.os.vms/c/KN9yqM7_8PU/m/T4xwyTz5A3oJ

https://groups.google.com/g/comp.os.vms/c/S7-VwQmmOZU/m/LXQ2TrbCBAAJ

https://groups.google.com/g/comp.os.vms/c/oSNzXLKeu4o/m/8Tq5dIFaDAAJ

I looked deeper at the last message (one with 8Tq5dIFaDAAJ at the end).
The fix for PR 17512 is clearly wrong: 'struct vms_eihd' is deliberatly
bigger than typical headers. Reverting this and similar fix for
PR 21813 allows objdump from binutils-2.39 to disassemble VMS shared
images with small header. However, cross binutils-2.39 can not read
VMS object files, and any attempts at linking give result like:

foo.obj: file not recognized: file format not recognized

VMS EXE is FIX 512, which is FTP binary friendly.

VMS OBJ is VAR, which is not FTP binary friendly and FTP
text will likely fuck up the file.

I would:
* $ SET FILE/ATTR=(RFM:FIX,MRS:512) on the OBJ file on VMS
* FTP binary to Linux
* see if objdump on Linux can recognize it

I di this before writing my previous message. objdump from
binutils-2.21 recognizes both files produced by gas from binutils-2.21
and file transferred from VMS (after doing what you wrote). After
transfering .obj file produced by binutils-2.21 from Linux to
VMS (which was tricky) ANALYZE said that it constins no
errors. Transferring was tricky, becuse transfer via scp gave
fixed 512 bytes blocks. Doing SET FILE/ATTR=RFM:VAR resulted in
null padding at the end and ANALYZE were complaining about
empty records (but no other errors). zipping .obj file, transfering
that to VMS gave streamlf file. Doing SET FILE/ATTR=RFM:VAR on
this file apparently worked. But zip treating it as text file
can potentially mangle it, so I am looking for better method.

Anyway, objdump from binutils-2.39 can not recognize .obj files
produced by gas from binutils-2.21 (which due to tests above I
believe have correct format). Also, using gas from binutils-2.39
or binutils-2.43 I get similar results. In other words,
objdump from binutils-2.21 recoginzes .obj files regardless of
source (tranferred from VMS or made by gas from any binutils).
objdump from later binutils does not recognize .obj files
from above mentioned sources.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/2/2025 6:30 PM, Waldek Hebisch wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 9/2/2025 8:59 AM, Waldek Hebisch wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 1:57 PM, Simon Clubley wrote:

A decade ago, I got as far as getting a simple C program for VMS Alpha >>>>> to compile and link on Linux. Anything else more complicated than that >>>>> (ie: other languages) failed and I suspect that either bits were missing >>>>> from the public kits or the additional steps required were not obvious. >>>>>
I discussed this at length in comp.os.vms at the time. Anyone interested >>>>> will have to rely on the notes I posted at the time as I have completely >>>>> forgotten the details of any of this (and have no motivation to get back >>>>> up to speed on them because my hobbies these days are very different and >>>>> because there's no longer a proper hobbyist licence for VMS Alpha).

I did the search:

https://groups.google.com/g/comp.os.vms/c/KN9yqM7_8PU/m/T4xwyTz5A3oJ

https://groups.google.com/g/comp.os.vms/c/S7-VwQmmOZU/m/LXQ2TrbCBAAJ

https://groups.google.com/g/comp.os.vms/c/oSNzXLKeu4o/m/8Tq5dIFaDAAJ

I looked deeper at the last message (one with 8Tq5dIFaDAAJ at the end).
The fix for PR 17512 is clearly wrong: 'struct vms_eihd' is deliberatly
bigger than typical headers. Reverting this and similar fix for
PR 21813 allows objdump from binutils-2.39 to disassemble VMS shared
images with small header. However, cross binutils-2.39 can not read
VMS object files, and any attempts at linking give result like:

foo.obj: file not recognized: file format not recognized

VMS EXE is FIX 512, which is FTP binary friendly.

VMS OBJ is VAR, which is not FTP binary friendly and FTP
text will likely fuck up the file.

I would:
* $ SET FILE/ATTR=(RFM:FIX,MRS:512) on the OBJ file on VMS
* FTP binary to Linux
* see if objdump on Linux can recognize it

I di this before writing my previous message. objdump from
binutils-2.21 recognizes both files produced by gas from binutils-2.21
and file transferred from VMS (after doing what you wrote). After transfering .obj file produced by binutils-2.21 from Linux to
VMS (which was tricky) ANALYZE said that it constins no
errors. Transferring was tricky, becuse transfer via scp gave
fixed 512 bytes blocks. Doing SET FILE/ATTR=RFM:VAR resulted in
null padding at the end and ANALYZE were complaining about
empty records (but no other errors). zipping .obj file, transfering
that to VMS gave streamlf file. Doing SET FILE/ATTR=RFM:VAR on
this file apparently worked. But zip treating it as text file
can potentially mangle it, so I am looking for better method.

I think I would go for:
* FTP binary from Linux to VMS
* SET FILE/ATTR=RFM:VAR on it

And if padding gives problems, then:
* SET FILE/ATTR=(EFBLK:n,FFB:m) on it

Anyway, objdump from binutils-2.39 can not recognize .obj files
produced by gas from binutils-2.21 (which due to tests above I
believe have correct format). Also, using gas from binutils-2.39
or binutils-2.43 I get similar results. In other words,
objdump from binutils-2.21 recoginzes .obj files regardless of
source (tranferred from VMS or made by gas from any binutils).
objdump from later binutils does not recognize .obj files
from above mentioned sources.

VMS Alpha support missing in newer versions??

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

hb0815 <mw40171@mucweb.de> wrote:

On 9/2/25 22:37, Arne Vajh|+j wrote:

On 9/2/2025 8:59 AM, Waldek Hebisch wrote:

...
I looked deeper at the last message (one with 8Tq5dIFaDAAJ at the end).
The fix for PR 17512 is clearly wrong: 'struct vms_eihd' is deliberatly
bigger than typical headers.-a Reverting this and similar fix for
PR 21813 allows objdump from binutils-2.39 to disassemble VMS shared
images with small header.-a However, cross binutils-2.39 can not read
VMS object files, and any attempts at linking give result like:

foo.obj: file not recognized: file format not recognized

VMS EXE is FIX 512, which is FTP binary friendly.

VMS OBJ is VAR, which is not FTP binary friendly and FTP
text will likely fuck up the file.

I would:
* $ SET FILE/ATTR=(RFM:FIX,MRS:512) on the OBJ file on VMS
* FTP binary to Linux
* see if objdump on Linux can recognize it

Check out with "objdump -i" if your objdump supports the VMS object
format for Alpha.

The one I installed from the distributions repository does not. You very likely have to rebuild objdump.

Yes, I am using binutils compile for Alpha VMS. I configured it using
the followng line:

(CC=/sklad/kompi/gcc/pp/mygcc; ../binutils-2.21/configure --target=alpha-dec-vms --prefix=/sklad/usr)

mygcc is a wrapper around gcc to replace '-Werror' by '-Wno-error'
(otherwise compilation using modern gcc would fail due to new
warnings being treated as errors).

Changing the file attributes or zipping the object file with "-V" will preserve the internal record structure. Works for me:

Thanks, works for me too.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Tue, 2 Sep 2025 16:37:12 -0400, Arne Vajh|+j wrote:

VMS OBJ is VAR, which is not FTP binary friendly and FTP text will
likely fuck up the file.

No it wonrCOt. The content is still intact, if you do a binary transfer. The problem is that VMS-based tools like the linker and librarian insist on
going through RMS to deal with files, and RMS insists on using file
attributes to govern the way it blocks and deblocks records. If those attributes are lost, then it just gives up.

ThererCOs no reason for Linux-based tools, say, to be so nitpicky and
stupid. The VMS .OBJ file format is perfectly readable without the
necessary record attributes. They are not conveying anything important.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/2/2025 8:13 PM, Lawrence DrCOOliveiro wrote:

On Tue, 2 Sep 2025 16:37:12 -0400, Arne Vajh|+j wrote:

VMS OBJ is VAR, which is not FTP binary friendly and FTP text will
likely fuck up the file.

No it wonrCOt. The content is still intact, if you do a binary transfer.

No.

The differences between VMS and *nix files can create
weird situations.

If you create a RFM VAR file on VMS with:

A
BB
CCC

then it is stored as:

01 00 41 00
02 00 42 42
03 00 43 43 43 00

When you do a binary FTP to Linux you end up with just 6 bytes:

41 42 42 43 43 43

With a binary FTP from VMS of a VAR file you get just the
data bytes with no structure defining bytes at all.

It works fine with FIX 512 files.

(at least with standard FTP server)

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Tue, 2 Sep 2025 20:35:54 -0400, Arne Vajh|+j wrote:

If you create a RFM VAR file on VMS with:

A
BB
CCC

then it is stored as:

01 00 41 00
02 00 42 42
03 00 43 43 43 00

When you do a binary FTP to Linux you end up with just 6 bytes:

41 42 42 43 43 43

ThatrCOs stupid. I would describe that as a bug in the VMS FTP program.

With a binary FTP from VMS of a VAR file you get just the data bytes
with no structure defining bytes at all.

And here I thought rCLbinaryrCY meant rCLtransfer all the bytes in the file as isrCY ...
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 1:57 PM, Simon Clubley wrote:

On 2025-08-29, Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 10:14 AM, Waldek Hebisch wrote:

I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.

I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.

I suspect very few try to build VMS executables on Linux.

A decade ago, I got as far as getting a simple C program for VMS Alpha
to compile and link on Linux. Anything else more complicated than that
(ie: other languages) failed and I suspect that either bits were missing
from the public kits or the additional steps required were not obvious.

I discussed this at length in comp.os.vms at the time. Anyone interested
will have to rely on the notes I posted at the time as I have completely
forgotten the details of any of this (and have no motivation to get back
up to speed on them because my hobbies these days are very different and
because there's no longer a proper hobbyist licence for VMS Alpha).

I did the search:

https://groups.google.com/g/comp.os.vms/c/KN9yqM7_8PU/m/T4xwyTz5A3oJ

https://groups.google.com/g/comp.os.vms/c/S7-VwQmmOZU/m/LXQ2TrbCBAAJ

https://groups.google.com/g/comp.os.vms/c/oSNzXLKeu4o/m/8Tq5dIFaDAAJ

I looked deeper at the last message (one with 8Tq5dIFaDAAJ at the end).
The fix for PR 17512 is clearly wrong: 'struct vms_eihd' is deliberatly
bigger than typical headers. Reverting this and similar fix for
PR 21813 allows objdump from binutils-2.39 to disassemble VMS shared
images with small header. However, cross binutils-2.39 can not read
VMS object files, and any attempts at linking give result like:

foo.obj: file not recognized: file format not recognized

To summarize, cross binutils-2.21 have one bug known to me: 'ar' can
not correctly extract '.obj' from a library. Apparently extracting
file looses information about record length (that probably only affects
cross ar, in native case probably RMS manages lengths).
binutils-2.39 is affected by the second issue mentioned by Simon. '--disable-plugins' option to configure is not needed to get working
objdump, but 'ar' from binutils-2.39 can not create libraries from VMS
object files even after giving '--disable-plugins' to configure. binutils-2.43.1 seem behave in similar way to binutils-2.39.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/3/2025 12:20 AM, Lawrence DrCOOliveiro wrote:

On Tue, 2 Sep 2025 20:35:54 -0400, Arne Vajh|+j wrote:

If you create a RFM VAR file on VMS with:

A
BB
CCC

then it is stored as:

01 00 41 00
02 00 42 42
03 00 43 43 43 00

When you do a binary FTP to Linux you end up with just 6 bytes:

41 42 42 43 43 43

ThatrCOs stupid.

Maybe not.

I would describe that as a bug in the VMS FTP program.

I think it happens deep down in the C RTL.

$ type dump.c
#include <stdio.h>

int main(int argc, char *argv[])
{
FILE *fp = fopen(argv[1], argv[2]);
int c;
while((c = fgetc(fp)) >= 0)
{
printf("%02X\n", c);
}
fclose(fp);
return 0;
}
$ cc dump
$ link dump
$ mcr []dump z.txt r
41
0A
42
42
0A
43
43
43
0A
$ mcr []dump z.txt rb
41
42
42
43
43
43

With a binary FTP from VMS of a VAR file you get just the data bytes
with no structure defining bytes at all.

And here I thought rCLbinaryrCY meant rCLtransfer all the bytes in the file as
isrCY ...

That is the Win/*nix way of thinking.

VMS could do it. Basically just use something that end
up calling SYS$READ instead of something that end up calling
SYS$GET.

But it would not make much sense to do so.

ORG IDX and ORG REL would end up as a huge pile of useless
bytes.

ORG SEQ & RFM FIX could be problematic too.

Let us say that you on VMS have a program create a FIX 1
file with 3 records of 01, 02 and 03.

If you did a binary FTP to Linux of that would you
expect 3 bytes (01, 02, 03) or 6 bytes (01, 00, 02, 00, 03, 00)?

ORG SEQ & RFM VAR would be pretty useless in most cases (except
when moving OBJ files between VMS and Linux!!).

But since VAR usually is a text file, then the FIX 1 example
may be more relevant.

Arne





--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-09-03 06:20, Lawrence DrCOOliveiro wrote:

On Tue, 2 Sep 2025 20:35:54 -0400, Arne Vajh|+j wrote:

If you create a RFM VAR file on VMS with:

A
BB
CCC

then it is stored as:

01 00 41 00
02 00 42 42
03 00 43 43 43 00

When you do a binary FTP to Linux you end up with just 6 bytes:

41 42 42 43 43 43

ThatrCOs stupid. I would describe that as a bug in the VMS FTP program.

Really? The length bytes are not actually any data in the file. Same
with padding. I would say it would be a very bad bug to actually include
them.

With a binary FTP from VMS of a VAR file you get just the data bytes
with no structure defining bytes at all.

And here I thought rCLbinaryrCY meant rCLtransfer all the bytes in the file as
isrCY ...

And it does. All the bytes of the file. Not all the metadata that exists outside of the data content.

Johnny

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 9/2/2025 6:30 PM, Waldek Hebisch wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 9/2/2025 8:59 AM, Waldek Hebisch wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 1:57 PM, Simon Clubley wrote:

A decade ago, I got as far as getting a simple C program for VMS Alpha >>>>>> to compile and link on Linux. Anything else more complicated than that >>>>>> (ie: other languages) failed and I suspect that either bits were missing >>>>>> from the public kits or the additional steps required were not obvious. >>>>>>
I discussed this at length in comp.os.vms at the time. Anyone interested >>>>>> will have to rely on the notes I posted at the time as I have completely >>>>>> forgotten the details of any of this (and have no motivation to get back >>>>>> up to speed on them because my hobbies these days are very different and >>>>>> because there's no longer a proper hobbyist licence for VMS Alpha). >>>>>

I did the search:

https://groups.google.com/g/comp.os.vms/c/KN9yqM7_8PU/m/T4xwyTz5A3oJ >>>>>
https://groups.google.com/g/comp.os.vms/c/S7-VwQmmOZU/m/LXQ2TrbCBAAJ >>>>>
https://groups.google.com/g/comp.os.vms/c/oSNzXLKeu4o/m/8Tq5dIFaDAAJ

I looked deeper at the last message (one with 8Tq5dIFaDAAJ at the end). >>>> The fix for PR 17512 is clearly wrong: 'struct vms_eihd' is deliberatly >>>> bigger than typical headers. Reverting this and similar fix for
PR 21813 allows objdump from binutils-2.39 to disassemble VMS shared
images with small header. However, cross binutils-2.39 can not read
VMS object files, and any attempts at linking give result like:

foo.obj: file not recognized: file format not recognized

VMS EXE is FIX 512, which is FTP binary friendly.

VMS OBJ is VAR, which is not FTP binary friendly and FTP
text will likely fuck up the file.

I would:
* $ SET FILE/ATTR=(RFM:FIX,MRS:512) on the OBJ file on VMS
* FTP binary to Linux
* see if objdump on Linux can recognize it

I di this before writing my previous message. objdump from
binutils-2.21 recognizes both files produced by gas from binutils-2.21
and file transferred from VMS (after doing what you wrote). After
transfering .obj file produced by binutils-2.21 from Linux to
VMS (which was tricky) ANALYZE said that it constins no
errors. Transferring was tricky, becuse transfer via scp gave
fixed 512 bytes blocks. Doing SET FILE/ATTR=RFM:VAR resulted in
null padding at the end and ANALYZE were complaining about
empty records (but no other errors). zipping .obj file, transfering
that to VMS gave streamlf file. Doing SET FILE/ATTR=RFM:VAR on
this file apparently worked. But zip treating it as text file
can potentially mangle it, so I am looking for better method.

I think I would go for:
* FTP binary from Linux to VMS
* SET FILE/ATTR=RFM:VAR on it

And if padding gives problems, then:
* SET FILE/ATTR=(EFBLK:n,FFB:m) on it

Thank, after replacing EFBLK by EBK this works for me.

Anyway, objdump from binutils-2.39 can not recognize .obj files
produced by gas from binutils-2.21 (which due to tests above I
believe have correct format). Also, using gas from binutils-2.39
or binutils-2.43 I get similar results. In other words,
objdump from binutils-2.21 recoginzes .obj files regardless of
source (tranferred from VMS or made by gas from any binutils).
objdump from later binutils does not recognize .obj files
from above mentioned sources.

VMS Alpha support missing in newer versions??

Everthing from old versions is present. There are also some fixes.
AFAICS this is just normal bitrot due to inadeqate testing.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Wed, 3 Sep 2025 15:52:27 -0400, Arne Vajh|+j wrote:

On 9/3/2025 12:20 AM, Lawrence DrCOOliveiro wrote:

And here I thought rCLbinaryrCY meant rCLtransfer all the bytes in the file >> as isrCY ...

That is the Win/*nix way of thinking.

That is the only way to preserve round-trip integrity. Or the closest we
can get to it.

ORG IDX and ORG REL would end up as a huge pile of useless bytes.

We are not dealing with those here, though.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Thu, 4 Sep 2025 00:38:34 +0200, Johnny Billquist wrote:

On 2025-09-03 06:20, Lawrence DrCOOliveiro wrote:

ThatrCOs stupid. I would describe that as a bug in the VMS FTP program.

Really? The length bytes are not actually any data in the file.

Yes they are.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/4/25 00:38, Johnny Billquist wrote:

Really? The length bytes are not actually any data in the file. Same
with padding. I would say it would be a very bad bug to actually include them.

And here I thought rCLbinaryrCY meant rCLtransfer all the bytes in the file as
isrCY ...

And it does. All the bytes of the file. Not all the metadata that exists outside of the data content.

Although the length and padding bytes are not data, they are still bytes
of the file. What was shown indicates that only the data, not all the
bytes, were transferred. I don't think that this makes sense or is
useful. But, VMS users very likely use the (unsupported) zip and unzip
utility to ensure that they get transferred what they really want/need.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/3/2025 6:38 PM, Johnny Billquist wrote:

On 2025-09-03 06:20, Lawrence DrCOOliveiro wrote:

On Tue, 2 Sep 2025 20:35:54 -0400, Arne Vajh|+j wrote:

If you create a RFM VAR file on VMS with:

A
BB
CCC

then it is stored as:

01 00 41 00
02 00 42 42
03 00 43 43 43 00

When you do a binary FTP to Linux you end up with just 6 bytes:

41 42 42 43 43 43

ThatrCOs stupid. I would describe that as a bug in the VMS FTP program.

Really? The length bytes are not actually any data in the file. Same
with padding. I would say it would be a very bad bug to actually include them.

With a binary FTP from VMS of a VAR file you get just the data bytes
with no structure defining bytes at all.

And here I thought rCLbinaryrCY meant rCLtransfer all the bytes in the file as
isrCY ...

And it does. All the bytes of the file. Not all the metadata that exists outside of the data content.

-a Johnny

Don't consider the length/padding to be part of the file. It is simply
part of the container that is holding the bytes. VARCR, STMLF, etc.
each are different containers but would hold the same bytes. You
wouldn't want the RMS header would you? Of course not.

Consider an OBJ file that contains code and data. The container in
which it lives (EOBJ, ELF32, ELF64, etc.) is not relevant to the code or
data.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/4/2025 12:52 PM, hb0815 wrote:

On 9/4/25 00:38, Johnny Billquist wrote:

Really? The length bytes are not actually any data in the file. Same
with padding. I would say it would be a very bad bug to actually
include them.

And here I thought rCLbinaryrCY meant rCLtransfer all the bytes in the file as
isrCY ...

And it does. All the bytes of the file. Not all the metadata that
exists outside of the data content.

Although the length and padding bytes are not data, they are still bytes
of the file. What was shown indicates that only the data, not all the
bytes, were transferred. I don't think that this makes sense or is
useful. But, VMS users very likely use the (unsupported) zip and unzip utility to ensure that they get transferred what they really want/need.

Discussing binary ftp of text files is a bit odd, because it
is not expected to work.

Binary FTP from VMS to Linux loose line structure. But even
if it did transfer all bytes Linux would just see a bunch
of bytes not making any sense as lines.

But that not working is not unique for VMS-*nix. Between
Windows and *nix you can end up with text files with a
trailing CR on all lines on *nix or lines not recognized
due to missing CR in older Windows apps.

I still think the FIX odd record length is a much better
example.

It is something that could happen in real world.

The expectation would be that it could be FTP'ed
binary.

And I would say that the least surprising handling
is what FTP actually does: loose the padding zero.

It would be quite confusing to write a FIX 1 file
on VMS, binary FTP it to Linux and see those
null bytes.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/4/2025 6:57 PM, Arne Vajh|+j wrote:

On 9/4/2025 12:52 PM, hb0815 wrote:

On 9/4/25 00:38, Johnny Billquist wrote:

Really? The length bytes are not actually any data in the file. Same
with padding. I would say it would be a very bad bug to actually
include them.

And here I thought rCLbinaryrCY meant rCLtransfer all the bytes in the >>>> file as
isrCY ...

And it does. All the bytes of the file. Not all the metadata that
exists outside of the data content.

Although the length and padding bytes are not data, they are still
bytes of the file. What was shown indicates that only the data, not
all the bytes, were transferred. I don't think that this makes sense
or is useful. But, VMS users very likely use the (unsupported) zip and
unzip utility to ensure that they get transferred what they really
want/need.

Discussing binary ftp of text files is a bit odd, because it
is not expected to work.

Binary FTP from VMS to Linux loose line structure. But even
if it did transfer all bytes Linux would just see a bunch
of bytes not making any sense as lines.

But that not working is not unique for VMS-*nix. Between
Windows and *nix you can end up with text files with a
trailing CR on all lines on *nix or lines not recognized
due to missing CR in older Windows apps.

I still think the FIX odd record length is a much better
example.

It is something that could happen in real world.

The expectation would be that it could be FTP'ed
binary.

And I would say that the least surprising handling
is what FTP actually does: loose the padding zero.

It would be quite confusing to write a FIX 1 file
on VMS, binary FTP it to Linux and see those
null bytes.

To illustrate.

On VMS:

...
type
myrec = packed record
code : char;
val : integer;
end;

var
f : file of myrec;
r : myrec;

begin
open(f, 'fix.dat', new);
rewrite(f);
...

On Windows:

...
{$mode ISO}

type
myrec = packed record
code : char;
val : integer;
end;

var
f : file of myrec;
r : myrec;

begin
assign(f, 'fix.dat');
reset(f);
...

Arne


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Thu, 4 Sep 2025 18:57:17 -0400, Arne Vajh|+j wrote:

But that not working is not unique for VMS-*nix. Between
Windows and *nix you can end up with text files with a
trailing CR on all lines on *nix or lines not recognized
due to missing CR in older Windows apps.

At least you do not lose any data. Text files are the least troublesome, because it is easy to open the file in rCLuniversal newlinerCY mode and transparently handle all the common line-ending conventions.

We are talking here about a VMS-specific problem, that all the common utilities insist on viewing file data through RMS, with all the trouble
that causes.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Thu, 4 Sep 2025 17:22:35 -0400, John Reagan wrote:

Don't consider the length/padding to be part of the file. It is simply
part of the container that is holding the bytes.

Every byte in the file contents is part of the contents of the file.

VARCR, STMLF, etc. each are different containers but would hold the same bytes. You wouldn't want the RMS header would you? Of course not.

There is no rCLRMS headerrCY in variable-length record formats.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/4/2025 7:47 PM, Lawrence DrCOOliveiro wrote:

On Thu, 4 Sep 2025 18:57:17 -0400, Arne Vajh|+j wrote:

But that not working is not unique for VMS-*nix. Between
Windows and *nix you can end up with text files with a
trailing CR on all lines on *nix or lines not recognized
due to missing CR in older Windows apps.

At least you do not lose any data. Text files are the least troublesome, because it is easy to open the file in rCLuniversal newlinerCY mode and transparently handle all the common line-ending conventions.

I suspect that "universal newline" means handling LF CRLF and CR
terminated lines 3 out of many line formats.

And not handling VMS RMS VAR, VMS RMS VFC, NOS variable length files,
NOS/VE variable length files, whatever fun stuff IBM mainframes may
have etc..

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Thu, 4 Sep 2025 19:55:12 -0400, Arne Vajh|+j wrote:

And not handling VMS RMS VAR, VMS RMS VFC, NOS variable length files,
NOS/VE variable length files, whatever fun stuff IBM mainframes may have etc..

We donrCOt care about those here. We care about VMS OBJ format, which is (or should be) easy to transfer to *nix platforms and work on there and even generate on there, not so easy to transfer back to VMS.

All the trouble happens on the VMS side.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/4/2025 8:24 PM, Lawrence DrCOOliveiro wrote:

On Thu, 4 Sep 2025 19:55:12 -0400, Arne Vajh|+j wrote:

And not handling VMS RMS VAR, VMS RMS VFC, NOS variable length files,
NOS/VE variable length files, whatever fun stuff IBM mainframes may have
etc..

We donrCOt care about those here. We care about VMS OBJ format, which is (or should be) easy to transfer to *nix platforms and work on there and even generate on there, not so easy to transfer back to VMS.

I think he got the transfer working both ways with a little
ingenuity.

But it is not the use case VMS FTP was designed for.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

But note that it is actually more messy than just described
for VAR and FIX.

Same file:

A
BB
CCC

VMS -> Linux

FTP text:

-rw-rw-r-- 1 arne arne 9 Sep 4 20:54 stmlf.txt
-rw-rw-r-- 1 arne arne 9 Sep 4 20:54 stm.txt
-rw-rw-r-- 1 arne arne 9 Sep 4 20:54 var.txt
-rw-rw-r-- 1 arne arne 9 Sep 4 20:54 vfc.txt

all as expected.

FTP binary:

-rw-rw-r-- 1 arne arne 9 Sep 4 20:57 stmlf.txt
-rw-rw-r-- 1 arne arne 12 Sep 4 20:57 stm.txt
-rw-rw-r-- 1 arne arne 6 Sep 4 20:57 var.txt
-rw-rw-r-- 1 arne arne 20 Sep 4 20:57 vfc.txt

is more mixed:
* VAR and VFC strip length and pad (but VFC does transfer
header bytes)
* STREAM and STREAM_LF does not strip line terminator

I knew that STREAM_LF was special, but I had actually
expected that STREAM had stripped line terminator as well.

Due to:

$ mcr []dump var.txt rb
41
42
42
43
43
43
$ mcr []dump vfc.txt rb
01
8D
41
01
8D
42
42
01
8D
43
43
43
$ mcr []dump stm.txt rb
41
42
42
43
43
43
$ mcr []dump stmlf.txt rb
41
0A
42
42
0A
43
43
43
0A

(dump.c is in an earlier post)

Ofcourse:

$ mcr []dump vfc.txt r
41
0A
42
42
0A
43
43
43
0A
$ mcr []dump vfc.txt r
41
0A
42
42
0A
43
43
43
0A
$ mcr []dump stm.txt r
41
0A
42
42
0A
43
43
43
0A
$ mcr []dump stmlf.txt r
41
0A
42
42
0A
43
43
43
0A

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/4/2025 9:16 PM, Arne Vajh|+j wrote:

$ mcr []dump var.txt rb
41
42
42
43
43
43
$ mcr []dump vfc.txt rb
01
8D
41
01
8D
42
42
01
8D
43
43
43
$ mcr []dump stm.txt rb
41
42
42
43
43
43
$ mcr []dump stmlf.txt rb
41
0A
42
42
0A
43
43
43
0A

(dump.c is in an earlier post)

If one really want all the bytes then:

$ mcr []dump2 var.txt rb ctx=stm
01
00
41
00
02
00
42
42
03
00
43
43
43
00
$ mcr []dump2 vfc.txt rb ctx=stm
03
00
01
8D
41
00
04
00
01
8D
42
42
05
00
01
8D
43
43
43
00
$ mcr []dump2 stm.txt rb ctx=stm
41
0D
0A
42
42
0D
0A
43
43
43
0D
0A
$ mcr []dump2 stmlf.txt rb ctx=stm
41
0A
42
42
0A
43
43
43
0A

dump2.c:

#include <stdio.h>

int main(int argc, char *argv[])
{
FILE *fp = fopen(argv[1], argv[2], argv[3]);
int c;
while((c = fgetc(fp)) >= 0)
{
printf("%02X\n", c);
}
fclose(fp);
return 0;
}

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Thu, 4 Sep 2025 20:28:24 -0400, Arne Vajh|+j wrote:

But it is not the use case VMS FTP was designed for.

If you canrCOt even properly transfer a file to another VMS system, then
what *was* it designed for?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 9/4/2025 8:24 PM, Lawrence DrCOOliveiro wrote:

On Thu, 4 Sep 2025 19:55:12 -0400, Arne Vajh|+j wrote:

And not handling VMS RMS VAR, VMS RMS VFC, NOS variable length files,
NOS/VE variable length files, whatever fun stuff IBM mainframes may have >>> etc..

We donrCOt care about those here. We care about VMS OBJ format, which is (or >> should be) easy to transfer to *nix platforms and work on there and even
generate on there, not so easy to transfer back to VMS.

I think he got the transfer working both ways with a little
ingenuity.

Yes, thanks to your tip I can correct attributes on files
transmitted from Linux. To transfer from VMS I can either
change attributes to fixed blocks and deal with padding
in Linux or use zip -V. I have tried

SET FILE/ATTR=(RFM:FIX,MRS:1)

but that does not give me expected result.

I was also thinking about using BACKUP (I assume that BACKUP can
correctly restore files), but I do not know if its format can be
easily decoded.

BTW: I have found that

DUMP /HEADER/PAGE /BLOCK=COUNT=0

gives me more information about file than DIR/FULL/PAGE
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:

On 2025-08-30, Waldek Hebisch <antispam@fricas.org> wrote:

Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:

That's where I gave up. I either didn't understand the required
VMS-specific build steps or there were bits missing from the public
source kits.

There are missing pieces, build needs VMS header files and libraries.
If those pieces are incomplete, then configuration may go wrong
and lead to trobles later.

Currently I have fairly incomplete set of header files, so I expect
trouble due to this. OTOH libgcc seem to compile fine, so C
compiler probably will work. I worked around trouble with
shared images by configuring gcc with '--disable-shared',
suboptimal but must do for now.

If you look at the links Arne posted, you will see I took across to
Linux the VMS-supplied header files inc addition to the libraries.
According to those notes, it appears I also had to write patches
for those headers.

When I talked about bits missing, I wasn't thinking about the headers
and libraries. Given that Adacore didn't start using Newlib or something similar to support VMS, that was pretty much expected.

I was thinking more about bits missing within the compiler or binutils itself, especially given the crashes I had with Fortran. I was wondering
if, for example, there are bits missing in the image initialisation
sequence, along with other similar types of missing bits.

I now got to C++ problem. In fact, this may be binutils problem:
gcc generates an assember file and as from binutils-2.21 aborts on
this file. as from current binutils developement tree produces
error message instead:

pom/kompi/gcc/binu-build3/gas/as-new -o array_type_info.obj array_type_info.s array_type_info.s: Assembler messages:
array_type_info.s: Error: no entry symbol for global function '_ZN10__cxxabiv117__array_type_infoD1Ev'

The offending function is defined in the following way:

.globl _ZN10__cxxabiv117__array_type_infoD1Ev
_ZN10__cxxabiv117__array_type_infoD1Ev = _ZN10__cxxabiv117__array_type_infoD2Ev

If I delete this definition and the ony use of it the file assembles OK.
AFAICS this means that _ZN10__cxxabiv117__array_type_infoD2Ev is correctly defined.

DEC assembler apparently uses different syntax, so I can not check
if the file is correct using DEC assembler. But I guess that similar
equates work with DEC assembler, so probably handling of equates in
GNU as is faulty (possibly corresponding piece is missing).
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-09-04 06:16, Lawrence DrCOOliveiro wrote:

On Thu, 4 Sep 2025 00:38:34 +0200, Johnny Billquist wrote:

On 2025-09-03 06:20, Lawrence DrCOOliveiro wrote:

ThatrCOs stupid. I would describe that as a bug in the VMS FTP program.

Really? The length bytes are not actually any data in the file.

Yes they are.

No, they are not.

If I write, in my program (pseudocode):

write("a")
write("bc")
write("def")

I would not want, when I read it back, to get:

^A ^@ A ^@
^B ^@ B C
^C ^@ D E F ^@

I didn't write those three control characters, which basically is just
the length of each record (and occasionally padding). If I got those,
then I'm reading back things I never wrote into the file in the first
place. They are not data in the file. They are meta-information about
the data.

That would be a horribly broken idea to get that meta-data when I read
the file back.

Johnny

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-09-05 02:24, Lawrence DrCOOliveiro wrote:

On Thu, 4 Sep 2025 19:55:12 -0400, Arne Vajh|+j wrote:

And not handling VMS RMS VAR, VMS RMS VFC, NOS variable length files,
NOS/VE variable length files, whatever fun stuff IBM mainframes may have
etc..

We donrCOt care about those here. We care about VMS OBJ format, which is (or should be) easy to transfer to *nix platforms and work on there and even generate on there, not so easy to transfer back to VMS.

All the trouble happens on the VMS side.

Because you assume that ftp binary mode somehow should make sense
between different types of systems, which it explicitly is not.
binary mode in ftp is, at the most optimistic, a way to hopefully get
all the actual content across. It has no way to deal with meta-data information. ftp basically never was a universal tool to transfer
arbitrary files between arbitrary systems and somehow make that just
work. Implementers of ftp actually then have to choose what to do, and
how to make it work "best" (for some arbitrary definition of "best") on
the system where they implemented it.
If the underlying systems are not compatible, then there will be cases
and situations where things will not work. There is no way around that.

Your assumptions and wishes are more just showing the lack of
understanding of the problem.

Johnny

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/4/2025 10:00 PM, Lawrence DrCOOliveiro wrote:

On Thu, 4 Sep 2025 20:28:24 -0400, Arne Vajh|+j wrote:

But it is not the use case VMS FTP was designed for.

If you canrCOt even properly transfer a file to another VMS system, then
what *was* it designed for?

That is a scenario we have not discussed yet.

Everyone use either COPY (if on same network) or ZIP -V and
binary FTP for that.

But plain FTP should work due to STRU VMS.

Which I believe does approx. the same as ZIP -V: copy
the blocks and copy the file meta information and force
it on the target file.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-09-05 04:00, Lawrence DrCOOliveiro wrote:

On Thu, 4 Sep 2025 20:28:24 -0400, Arne Vajh|+j wrote:

But it is not the use case VMS FTP was designed for.

If you canrCOt even properly transfer a file to another VMS system, then
what *was* it designed for?

ftp between two VMS systems can transfer arbitrary files correctly, if I remember right. But it uses extra tricks for that to work, which are not compatible with transferring to non-VMS systems.

The basic ftp spec have ASCII, which is supposed to always work, but is
only suitable for test-like files. And ftp can then transform then
to/from whatever format is suitable on each system, while over the
network they have a common, canonical form.

For binary files, ftp basically leaves everything undefined. Any system
can do whatever they want, and the end results is whatever. And then ftp
have some special modes that I think pretty much noone ever have
implemented. And beyond that, ftp implementations can extend the
protocol in any way they want to do extra things not defined by the specs.

Johnny

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/4/2025 11:02 PM, Waldek Hebisch wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 9/4/2025 8:24 PM, Lawrence DrCOOliveiro wrote:

On Thu, 4 Sep 2025 19:55:12 -0400, Arne Vajh|+j wrote:

And not handling VMS RMS VAR, VMS RMS VFC, NOS variable length files,
NOS/VE variable length files, whatever fun stuff IBM mainframes may have >>>> etc..

We donrCOt care about those here. We care about VMS OBJ format, which is (or
should be) easy to transfer to *nix platforms and work on there and even >>> generate on there, not so easy to transfer back to VMS.

I think he got the transfer working both ways with a little
ingenuity.

Yes, thanks to your tip I can correct attributes on files
transmitted from Linux. To transfer from VMS I can either
change attributes to fixed blocks and deal with padding
in Linux or use zip -V. I have tried

SET FILE/ATTR=(RFM:FIX,MRS:1)

but that does not give me expected result.

I would try with an even number for MRS. An odd number will
cause some bytes to be considered pad bytes.

I was also thinking about using BACKUP (I assume that BACKUP can
correctly restore files), but I do not know if its format can be
easily decoded.

BACKUP can restore files. There are some C code on the internet
to process backup savesets.

But I would go for ZIP.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-09-05 01:49, Lawrence DrCOOliveiro wrote:

On Thu, 4 Sep 2025 17:22:35 -0400, John Reagan wrote:

Don't consider the length/padding to be part of the file. It is simply
part of the container that is holding the bytes.

Every byte in the file contents is part of the contents of the file.

No.

VARCR, STMLF, etc. each are different containers but would hold the same
bytes. You wouldn't want the RMS header would you? Of course not.

There is no rCLRMS headerrCY in variable-length record formats.

Yes there is. The length information is the "RMS header". And I don't
know what I'd call the padding, but it's also clearly not part of the
data of the file.

And the same data, written either to a VARCR or a STMLF file, should
read back out the same data. What you are suggesting would mean that the
same data written, would result in different data being read back out,
which would be absolutely madness.

Johnny

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 9/4/2025 11:02 PM, Waldek Hebisch wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

I think he got the transfer working both ways with a little
ingenuity.

Yes, thanks to your tip I can correct attributes on files
transmitted from Linux. To transfer from VMS I can either
change attributes to fixed blocks and deal with padding
in Linux or use zip -V. I have tried

SET FILE/ATTR=(RFM:FIX,MRS:1)

but that does not give me expected result.

I would try with an even number for MRS. An odd number will
cause some bytes to be considered pad bytes.

Let me explain what I expected: RFM:FIX alone keeps maximal
record size unchanged, effectivly adding padding in last
record (unless length of the file happens to be be an integral
multiple of maximal record size). My expectation was that
MRS:1 will eliminate need for padding, keping file end in
the same place as it was before changing attributes.

Unfortunately, it seems that attempts to set record size are
ignored. It seems that record size is separate from mazimal
record size and despite claim in "VSI OpenVMS Record Management
Services Reference Manual":

: The maximum record size (MRS) field defines the size of all records
: in a file with fixed-length records, the maximum size of variable-length
: records, the maximum size of the data area for variable with fixed-
: length control records, and the cell size (minus overhead) for relative
: files.

setting maximal record size does not change record size: DUMP/HEADER
shows me:

Record type: Fixed
File organization: Sequential
Record attributes: <none specified>
Record size: 4056
Highest block: 54
End of file block: 52
End of file block: 52
End of file byte: 220
Bucket size: 0
Fixed control area size: 0
Maximum record size: 26332

in contradiction to the claim from reference manual.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/5/2025 11:43 AM, Waldek Hebisch wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 9/4/2025 11:02 PM, Waldek Hebisch wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

I think he got the transfer working both ways with a little
ingenuity.

Yes, thanks to your tip I can correct attributes on files
transmitted from Linux. To transfer from VMS I can either
change attributes to fixed blocks and deal with padding
in Linux or use zip -V. I have tried

SET FILE/ATTR=(RFM:FIX,MRS:1)

but that does not give me expected result.

I would try with an even number for MRS. An odd number will
cause some bytes to be considered pad bytes.

Let me explain what I expected: RFM:FIX alone keeps maximal
record size unchanged, effectivly adding padding in last
record (unless length of the file happens to be be an integral
multiple of maximal record size). My expectation was that
MRS:1 will eliminate need for padding, keping file end in
the same place as it was before changing attributes.

Unfortunately, it seems that attempts to set record size are
ignored. It seems that record size is separate from mazimal
record size and despite claim in "VSI OpenVMS Record Management
Services Reference Manual":

: The maximum record size (MRS) field defines the size of all records
: in a file with fixed-length records, the maximum size of variable-length
: records, the maximum size of the data area for variable with fixed-
: length control records, and the cell size (minus overhead) for relative
: files.

setting maximal record size does not change record size: DUMP/HEADER
shows me:

Record type: Fixed
File organization: Sequential
Record attributes: <none specified>
Record size: 4056
Highest block: 54
End of file block: 52
End of file block: 52
End of file byte: 220
Bucket size: 0
Fixed control area size: 0
Maximum record size: 26332

in contradiction to the claim from reference manual.

I was not talking about file padding but about record
padding.

I think this illustrate the issue:

$ write sys$output f$file("z.txt","rfm"),f$file("z.txt","mrs")
FIX2
$ typ z.txt
AB
CD
EF
$ set file/attr=(mrs:1) z.txt
$ write sys$output f$file("z.txt","rfm"),f$file("z.txt","mrs")
FIX2
$ set file/attr=(lrl:1) z.txt
$ write sys$output f$file("z.txt","rfm"),f$file("z.txt","mrs")
FIX1
$ typ z.txt
A
C
E

B, D and F are "lost".

And it looks like one need to set LRL instead of MRS to change the file.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Waldek Hebisch <antispam@fricas.org> wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 1:57 PM, Simon Clubley wrote:

On 2025-08-29, Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 8/29/2025 10:14 AM, Waldek Hebisch wrote:

I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.

I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.

I suspect very few try to build VMS executables on Linux.

A decade ago, I got as far as getting a simple C program for VMS Alpha
to compile and link on Linux. Anything else more complicated than that
(ie: other languages) failed and I suspect that either bits were missing >>> from the public kits or the additional steps required were not obvious.

I discussed this at length in comp.os.vms at the time. Anyone interested >>> will have to rely on the notes I posted at the time as I have completely >>> forgotten the details of any of this (and have no motivation to get back >>> up to speed on them because my hobbies these days are very different and >>> because there's no longer a proper hobbyist licence for VMS Alpha).

I did the search:

https://groups.google.com/g/comp.os.vms/c/KN9yqM7_8PU/m/T4xwyTz5A3oJ

https://groups.google.com/g/comp.os.vms/c/S7-VwQmmOZU/m/LXQ2TrbCBAAJ

https://groups.google.com/g/comp.os.vms/c/oSNzXLKeu4o/m/8Tq5dIFaDAAJ

I looked deeper at the last message (one with 8Tq5dIFaDAAJ at the end).
The fix for PR 17512 is clearly wrong: 'struct vms_eihd' is deliberatly bigger than typical headers. Reverting this and similar fix for
PR 21813 allows objdump from binutils-2.39 to disassemble VMS shared
images with small header. However, cross binutils-2.39 can not read
VMS object files, and any attempts at linking give result like:

foo.obj: file not recognized: file format not recognized

To summarize, cross binutils-2.21 have one bug known to me: 'ar' can
not correctly extract '.obj' from a library. Apparently extracting
file looses information about record length (that probably only affects
cross ar, in native case probably RMS manages lengths).
binutils-2.39 is affected by the second issue mentioned by Simon. '--disable-plugins' option to configure is not needed to get working
objdump, but 'ar' from binutils-2.39 can not create libraries from VMS
object files even after giving '--disable-plugins' to configure. binutils-2.43.1 seem behave in similar way to binutils-2.39.

I have filed a bug report about this to binutils bug tracker:

https://sourceware.org/bugzilla/show_bug.cgi?id=33385
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms


On 9/5/25 6:55 AM, Waldek Hebisch wrote:

I now got to C++ problem. In fact, this may be binutils problem:
gcc generates an assember file and as from binutils-2.21 aborts on
this file. as from current binutils developement tree produces
error message instead:

pom/kompi/gcc/binu-build3/gas/as-new -o array_type_info.obj array_type_info.s array_type_info.s: Assembler messages:
array_type_info.s: Error: no entry symbol for global function '_ZN10__cxxabiv117__array_type_infoD1Ev'

The offending function is defined in the following way:

.globl _ZN10__cxxabiv117__array_type_infoD1Ev
_ZN10__cxxabiv117__array_type_infoD1Ev = _ZN10__cxxabiv117__array_type_infoD2Ev

If I delete this definition and the ony use of it the file assembles OK. AFAICS this means that _ZN10__cxxabiv117__array_type_infoD2Ev is correctly defined.

Note that this symbol is 38 characters long. The native VMS toolchain traditionally limits itself to 31-character symbols and uses a checksum
to shorten symbols that are longer. The linker, the librarian, and the
inertia of existing code are all things I've heard blamed for this state
of affairs.

I have no idea whether the tools you are using require or are capable of observing the 31-character limit. If some parts do and other parts
don't, that could obviously cause trouble, and of course you've got the
C++ name mangler in the mix as well.

If you need an open source name shortener that mimics what the DEC
compilers do, I've got one here:

<https://sourceforge.net/p/vms-ports/vmsshortsym/ci/default/tree/vms_shorten_symbol.c>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 9/5/2025 11:43 AM, Waldek Hebisch wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 9/4/2025 11:02 PM, Waldek Hebisch wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

I think he got the transfer working both ways with a little
ingenuity.

Yes, thanks to your tip I can correct attributes on files
transmitted from Linux. To transfer from VMS I can either
change attributes to fixed blocks and deal with padding
in Linux or use zip -V. I have tried

SET FILE/ATTR=(RFM:FIX,MRS:1)

but that does not give me expected result.

I would try with an even number for MRS. An odd number will
cause some bytes to be considered pad bytes.

Let me explain what I expected: RFM:FIX alone keeps maximal
record size unchanged, effectivly adding padding in last
record (unless length of the file happens to be be an integral
multiple of maximal record size). My expectation was that
MRS:1 will eliminate need for padding, keping file end in
the same place as it was before changing attributes.

Unfortunately, it seems that attempts to set record size are
ignored. It seems that record size is separate from mazimal
record size and despite claim in "VSI OpenVMS Record Management
Services Reference Manual":

: The maximum record size (MRS) field defines the size of all records
: in a file with fixed-length records, the maximum size of variable-length >> : records, the maximum size of the data area for variable with fixed-
: length control records, and the cell size (minus overhead) for relative
: files.

setting maximal record size does not change record size: DUMP/HEADER
shows me:

Record type: Fixed
File organization: Sequential
Record attributes: <none specified>
Record size: 4056
Highest block: 54
End of file block: 52
End of file block: 52
End of file byte: 220
Bucket size: 0
Fixed control area size: 0
Maximum record size: 26332

in contradiction to the claim from reference manual.

I was not talking about file padding but about record
padding.

I think this illustrate the issue:

$ write sys$output f$file("z.txt","rfm"),f$file("z.txt","mrs")
FIX2
$ typ z.txt
AB
CD
EF
$ set file/attr=(mrs:1) z.txt
$ write sys$output f$file("z.txt","rfm"),f$file("z.txt","mrs")
FIX2
$ set file/attr=(lrl:1) z.txt
$ write sys$output f$file("z.txt","rfm"),f$file("z.txt","mrs")
FIX1
$ typ z.txt
A
C
E

B, D and F are "lost".

And it looks like one need to set LRL instead of MRS to change the file.

I am not sure what this is supposed to ilustrate. I mean, I would
expect that changing record length below previous record length
and doing no other changes to attributes will lead to trouble
and while I do not undertand all details of your example, it seem
to confirm my expectation. I would expect that having records
of length 3 and then setting length to 2 would also truncate
data in the records.

I did:

copy FFS.OBJ;1 FFS.OBP;1
SET FILE/ATTR=LRL:1 FFS.OBP;1
SET FILE/ATTR=RFM:FIX FFS.OBP

and after that scp to Linux worked fine. Since in variable length
file records always take even number of bytes (odd length recors are
padded), I think that ET FILE/ATTR=LRL:2 would work equally well.
But for me LRL:1 looks more correct, as this does not depend on
detail above.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/5/2025 1:40 PM, Waldek Hebisch wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

I was not talking about file padding but about record
padding.

I think this illustrate the issue:

$ write sys$output f$file("z.txt","rfm"),f$file("z.txt","mrs")
FIX2
$ typ z.txt
AB
CD
EF
$ set file/attr=(mrs:1) z.txt
$ write sys$output f$file("z.txt","rfm"),f$file("z.txt","mrs")
FIX2
$ set file/attr=(lrl:1) z.txt
$ write sys$output f$file("z.txt","rfm"),f$file("z.txt","mrs")
FIX1
$ typ z.txt
A
C
E

B, D and F are "lost".

And it looks like one need to set LRL instead of MRS to change the file.

I am not sure what this is supposed to ilustrate. I mean, I would
expect that changing record length below previous record length
and doing no other changes to attributes will lead to trouble
and while I do not undertand all details of your example, it seem
to confirm my expectation.

It illustrates that:

$ set file/attr=(rfm:fix,lrl:oddnumber) ...

is very dangerous, because some data bytes may end up being lost due
to being considered padding.

I would expect that having records
of length 3 and then setting length to 2 would also truncate
data in the records.

$ set file/attr does not change the content of the file only the
file header meta data.

AAA
BBB
CCC

41 41 41 00
42 42 42 00
43 43 43 00

does not become:

AA
BB
CC

41 41
42 42
43 43

but:

AA
A*
BB
B*
CC
C*

41 41
41 00
42 42
42 00
43 43
43 00

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-09-05 17:43, Waldek Hebisch wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 9/4/2025 11:02 PM, Waldek Hebisch wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

I think he got the transfer working both ways with a little
ingenuity.

Yes, thanks to your tip I can correct attributes on files
transmitted from Linux. To transfer from VMS I can either
change attributes to fixed blocks and deal with padding
in Linux or use zip -V. I have tried

SET FILE/ATTR=(RFM:FIX,MRS:1)

but that does not give me expected result.

I would try with an even number for MRS. An odd number will
cause some bytes to be considered pad bytes.

Let me explain what I expected: RFM:FIX alone keeps maximal
record size unchanged, effectivly adding padding in last
record (unless length of the file happens to be be an integral
multiple of maximal record size). My expectation was that
MRS:1 will eliminate need for padding, keping file end in
the same place as it was before changing attributes.

Unfortunately, it seems that attempts to set record size are
ignored. It seems that record size is separate from mazimal
record size and despite claim in "VSI OpenVMS Record Management
Services Reference Manual":

: The maximum record size (MRS) field defines the size of all records
: in a file with fixed-length records, the maximum size of variable-length
: records, the maximum size of the data area for variable with fixed-
: length control records, and the cell size (minus overhead) for relative
: files.

setting maximal record size does not change record size: DUMP/HEADER
shows me:

Record type: Fixed
File organization: Sequential
Record attributes: <none specified>
Record size: 4056
Highest block: 54
End of file block: 52
End of file block: 52
End of file byte: 220
Bucket size: 0
Fixed control area size: 0
Maximum record size: 26332

in contradiction to the claim from reference manual.

I think you're expecting magic (if I understood you right). Changing the attributes of an existing file does not change the content of the file,
merely how some things are interpreted at read, as well as possibly
affecting further writes.

If you set a file to fixed, with a maximum record size of whatever does
not change any existing records in the file. It can cause truncation
when you write additional records, but if you by some trickery caused
larger records to exist in the file, they will not be changed.

Furthermore, you cannot dodge padding if you have records in the file.
If you specify a maximum records size of 1, you'll get padding on every
record if I remember right. The one way to not have padding is to have a stream record format.

But really, just modifying file attributes does not in any way go in and actually change the content in the file.

Johnny
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Craig A. Berry <craigberry@nospam.mac.com> wrote:

On 9/5/25 6:55 AM, Waldek Hebisch wrote:

I now got to C++ problem. In fact, this may be binutils problem:
gcc generates an assember file and as from binutils-2.21 aborts on
this file. as from current binutils developement tree produces
error message instead:

pom/kompi/gcc/binu-build3/gas/as-new -o array_type_info.obj array_type_info.s
array_type_info.s: Assembler messages:
array_type_info.s: Error: no entry symbol for global function '_ZN10__cxxabiv117__array_type_infoD1Ev'

The offending function is defined in the following way:

.globl _ZN10__cxxabiv117__array_type_infoD1Ev
_ZN10__cxxabiv117__array_type_infoD1Ev = _ZN10__cxxabiv117__array_type_infoD2Ev

If I delete this definition and the ony use of it the file assembles OK.
AFAICS this means that _ZN10__cxxabiv117__array_type_infoD2Ev is correctly >> defined.

Note that this symbol is 38 characters long. The native VMS toolchain traditionally limits itself to 31-character symbols and uses a checksum
to shorten symbols that are longer. The linker, the librarian, and the inertia of existing code are all things I've heard blamed for this state
of affairs.

I have no idea whether the tools you are using require or are capable of observing the 31-character limit. If some parts do and other parts
don't, that could obviously cause trouble, and of course you've got the
C++ name mangler in the mix as well.

IIUC GNU assembler internaly uses arbitrarily long names (in dynamically allocated buffers) and shortens names only on output. Anyway, I
tried shorthening names in the input file and it makes no difference.

All indicates that GNU assembler can not handle simple symbol
equality as intended. Namely relevant part of original code
including definitions of _ZN10__cxxabiv117__array_type_infoD2Ev
and _ZN10__cxxabiv117__array_type_infoD1Ev is:

.link
.align 3
_ZN10__cxxabiv117__array_type_infoD2Ev:
.pdesc _ZN10__cxxabiv117__array_type_infoD2Ev..en,stack $80.._ZNSt9type_infoD2Ev..lk:
.linkage _ZNSt9type_infoD2Ev
.end _ZN10__cxxabiv117__array_type_infoD2Ev
.globl _ZN10__cxxabiv117__array_type_infoD1Ev
_ZN10__cxxabiv117__array_type_infoD1Ev = _ZN10__cxxabiv117__array_type_infoD2Ev

The intent is clearly that _ZN10__cxxabiv117__array_type_infoD1Ev
should be alternative name for _ZN10__cxxabiv117__array_type_infoD2Ev,
but for some reasons assembler can not handle this. AFAICS GNU
assembler for VMS believes that that given function should have
only one name. For example I tried to transform fragment above
to:

.link
.align 3
_ZN10__cxxabiv117__array_type_infoD2Ev:
.pdesc _ZN10__cxxabiv117__array_type_infoD2Ev..en,stack $80.._ZNSt9type_infoD2Ev..lk:
.linkage _ZNSt9type_infoD2Ev
.end _ZN10__cxxabiv117__array_type_infoD2Ev
.globl _ZN10__cxxabiv117__array_type_infoD1Ev
.ent _ZN10__cxxabiv117__array_type_infoD1Ev _ZN10__cxxabiv117__array_type_infoD1Ev:
.pdesc _ZN10__cxxabiv117__array_type_infoD2Ev..en,stack
.linkage _ZNSt9type_infoD2Ev
.end _ZN10__cxxabiv117__array_type_infoD2Ev

that is I actually build second descriptor duplicating content of
descriptor for _ZN10__cxxabiv117__array_type_infoD2Ev and GNU
assembler still does not want to accept this. More precisely,
version 2.21 gives the same error message as original code,
current trunk says:

at3.s: Assembler messages:
at3.s:55: Fatal error: .pdesc doesn't match with last .ent

I do not know if VMS object format allows alternative names,
that is two symbols resolving to the same name (but I also
am not aware of any reason for such restriction), but even
if there were such restriction version with duplicate descriptor
should work around this.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Johnny Billquist <bqt@softjar.se> wrote:

On 2025-09-05 17:43, Waldek Hebisch wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 9/4/2025 11:02 PM, Waldek Hebisch wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

I think he got the transfer working both ways with a little
ingenuity.

Yes, thanks to your tip I can correct attributes on files
transmitted from Linux. To transfer from VMS I can either
change attributes to fixed blocks and deal with padding
in Linux or use zip -V. I have tried

SET FILE/ATTR=(RFM:FIX,MRS:1)

but that does not give me expected result.

I would try with an even number for MRS. An odd number will
cause some bytes to be considered pad bytes.

Let me explain what I expected: RFM:FIX alone keeps maximal
record size unchanged, effectivly adding padding in last
record (unless length of the file happens to be be an integral
multiple of maximal record size). My expectation was that
MRS:1 will eliminate need for padding, keping file end in
the same place as it was before changing attributes.

Unfortunately, it seems that attempts to set record size are
ignored. It seems that record size is separate from mazimal
record size and despite claim in "VSI OpenVMS Record Management
Services Reference Manual":

: The maximum record size (MRS) field defines the size of all records
: in a file with fixed-length records, the maximum size of variable-length >> : records, the maximum size of the data area for variable with fixed-
: length control records, and the cell size (minus overhead) for relative
: files.

setting maximal record size does not change record size: DUMP/HEADER
shows me:

Record type: Fixed
File organization: Sequential
Record attributes: <none specified>
Record size: 4056
Highest block: 54
End of file block: 52
End of file block: 52
End of file byte: 220
Bucket size: 0
Fixed control area size: 0
Maximum record size: 26332

in contradiction to the claim from reference manual.

I think you're expecting magic (if I understood you right).

I simply expected documantaion to say the truth.

Changing the
attributes of an existing file does not change the content of the file, merely how some things are interpreted at read, as well as possibly affecting further writes.

If you set a file to fixed, with a maximum record size of whatever does
not change any existing records in the file. It can cause truncation
when you write additional records, but if you by some trickery caused
larger records to exist in the file, they will not be changed.

Well, I would prefer to avoid discussions about what is content,
what is data and what is metadata. People here have strong views
about this and nobody is going to change his/her view.

I would say that VMS file have header and rest. I think that
documentation actually says about disc blocks, but main point is
that changing attributes only changes header keeping rest of
file unchanged. "VSI OpenVMS Record Management Services Reference
Manual" mentions several fields in the header and I wanted to
do specific change to header fields. More precisely, I wanted
to set file "File organization" to Sequential and record size to 1
preserving information about end of file.

Given that basic parameters are controled by FAB, I looked at
parameters to SET FILE/ATTR setting various fields of FAB and
I found MRS with from description looked like right way to
set record length field in the header. But it did not work.
As I wrote in replay to Arne using LRL parameter that he
found did the job.

Furthermore, you cannot dodge padding if you have records in the file.
If you specify a maximum records size of 1, you'll get padding on every record if I remember right. The one way to not have padding is to have a stream record format.

As I wrote in replay to Arne I did:

SET FILE/ATTR=LRL:1 FFS.OBP
SET FILE/ATTR=RFM:FIX FFS.OBP

which set file to fixed length records. In such file there is no
padding: either there is byte and we have full record or there is
no byte and we have no record. Of course, without the second step
file above would have variable length records and reading it would
produce nonsense.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 9/5/2025 1:40 PM, Waldek Hebisch wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

I was not talking about file padding but about record
padding.

I think this illustrate the issue:

$ write sys$output f$file("z.txt","rfm"),f$file("z.txt","mrs")
FIX2
$ typ z.txt
AB
CD
EF
$ set file/attr=(mrs:1) z.txt
$ write sys$output f$file("z.txt","rfm"),f$file("z.txt","mrs")
FIX2
$ set file/attr=(lrl:1) z.txt
$ write sys$output f$file("z.txt","rfm"),f$file("z.txt","mrs")
FIX1
$ typ z.txt
A
C
E

B, D and F are "lost".

And it looks like one need to set LRL instead of MRS to change the file.

I am not sure what this is supposed to ilustrate. I mean, I would
expect that changing record length below previous record length
and doing no other changes to attributes will lead to trouble
and while I do not undertand all details of your example, it seem
to confirm my expectation.

It illustrates that:

$ set file/attr=(rfm:fix,lrl:oddnumber) ...

is very dangerous, because some data bytes may end up being lost due
to being considered padding.

I did

set file/attr=lrl:1
set file/attr=rfm:fix

which in sane system should be equivalent to

set file/attr=(rfm:fix,lrl:1)

As I wrote my change gave result that I expected, that is I got
both count and record content (including padding byte when record
had odd length). From my point of view I got all data with no
loss and no extra bytes at the end.

You use DCL features which make it somewhat unclear what your command
did (and you did not specify what parameters were used to create
initial file). Also, your command looks like using the same
file as input and output (or do versions insure that they are
different?).

I would expect that having records
of length 3 and then setting length to 2 would also truncate
data in the records.

$ set file/attr does not change the content of the file only the
file header meta data.

AAA
BBB
CCC

41 41 41 00
42 42 42 00
43 43 43 00

does not become:

AA
BB
CC

41 41
42 42
43 43

but:

AA
A*
BB
B*
CC
C*

41 41
41 00
42 42
42 00
43 43
43 00

I am not sure how you are getting result above. I created a
simple variable length file and I get:

$ set FILE/ATTR=LRL:2 VTST.TXT
$ type VTST.TXT
a
bcd
$ set FILE/ATTR=LRL:1 VTST.TXT
$ type VTST.TXT
a
bcd

That is 'type' is getting right records regardless of my LRL setting.
Naive program could truncate records. Slightly better one
could get records in pieces of size corresponding to
LRL (possibly creating more record on output than is present in
the input). But truncating with odd LRL setting and reading
record padding bytes with even LRL setting look like a bug
(which may remain unfixed forever due to requirement for
bug compatibility).
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/5/2025 7:12 PM, Waldek Hebisch wrote:

Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 9/5/2025 1:40 PM, Waldek Hebisch wrote:

I would expect that having records
of length 3 and then setting length to 2 would also truncate
data in the records.

$ set file/attr does not change the content of the file only the
file header meta data.

AAA
BBB
CCC

41 41 41 00
42 42 42 00
43 43 43 00

does not become:

AA
BB
CC

41 41
42 42
43 43

but:

AA
A*
BB
B*
CC
C*

41 41
41 00
42 42
42 00
43 43
43 00

I am not sure how you are getting result above. I created a
simple variable length file and I get:

$ set FILE/ATTR=LRL:2 VTST.TXT
$ type VTST.TXT
a
bcd
$ set FILE/ATTR=LRL:1 VTST.TXT
$ type VTST.TXT
a
bcd

That is 'type' is getting right records regardless of my LRL setting.
Naive program could truncate records. Slightly better one
could get records in pieces of size corresponding to
LRL (possibly creating more record on output than is present in
the input). But truncating with odd LRL setting and reading
record padding bytes with even LRL setting look like a bug
(which may remain unfixed forever due to requirement for
bug compatibility).

Sorry. I am still messing around in RFM FIX.

It can be deduced from the hex, but I should have been explicit.

I create the FIX file simply by creating a VAR in EVE and do a:

$ convert/fdl="record;format fixed;size 3" var-file fix-file

I think VAR is way less sensitive to MRS/LRL than FIX.

VAR use the length in the record prefix. FIX has to take the length
from the header.

Arne



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Fri, 5 Sep 2025 21:32:01 -0000 (UTC), Waldek Hebisch wrote:

All indicates that GNU assembler can not handle simple symbol
equality as intended.

I tried creating a source file test.s containing just your two problem
lines:

.globl _ZN10__cxxabiv117__array_type_infoD1Ev
_ZN10__cxxabiv117__array_type_infoD1Ev = _ZN10__cxxabiv117__array_type_infoD2E

and when I try to assemble it,

gcc -c test.s

there is no error, and test.o is created OK. Trying objdump on it

objdump -t test.o

shows it has the correct symbol reference in it, albeit undefined:

test.o: file format elf64-x86-64

SYMBOL TABLE:
0000000000000000 *UND* 0000000000000000 _ZN10__cxxabiv117__array_type_infoD2E

So no, the issue is not with those two particular lines on their own.
Something else is involved.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

On Fri, 5 Sep 2025 21:32:01 -0000 (UTC), Waldek Hebisch wrote:

All indicates that GNU assembler can not handle simple symbol
equality as intended.

I tried creating a source file test.s containing just your two problem
lines:

.globl _ZN10__cxxabiv117__array_type_infoD1Ev
_ZN10__cxxabiv117__array_type_infoD1Ev = _ZN10__cxxabiv117__array_type_infoD2E

and when I try to assemble it,

gcc -c test.s

there is no error, and test.o is created OK. Trying objdump on it

objdump -t test.o

shows it has the correct symbol reference in it, albeit undefined:

test.o: file format elf64-x86-64

SYMBOL TABLE:
0000000000000000 *UND* 0000000000000000 _ZN10__cxxabiv117__array_type_infoD2E

So no, the issue is not with those two particular lines on their own. Something else is involved.

Yes. AFAICS main issue is creating alias name for an exported
function. Internal aliases work fine. Probably data aliases too.

_ZN10__cxxabiv117__array_type_infoD1Ev must be defined as an exported
function. Actual code is rather long. Below is much shorter code
that exhibits the same problem.

Also note the context: this is code for alpha-dec-vms, equivalent
construct is used on other architecures and works fine.

----------------<cut here>----------------------------
.set noreorder
.set volatile
.arch ev6
.text
.align 2
.globl ts_fun
.ent ts_fun
ts_fun..en:
.base $27
.frame $29,0,$26,8
.prologue
ret $31,($26),1

.link
.align 3
ts_fun:
.pdesc ts_fun..en,null
.end ts_fun
.globl ts_fun2
ts_fun2 = ts_fun
.text
$Lvetext0:
----------------------<cut here>-----------------------------
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Sat, 6 Sep 2025 01:13:39 -0000 (UTC), Waldek Hebisch wrote:

Also note the context: this is code for alpha-dec-vms, equivalent
construct is used on other architecures and works fine.

But you said the problem was with the GNU assembler. Seems unlikely that
would have a language limitation, that has to do with naming and not to do with any architecture specifics, that doesnrCOt apply on other
architectures.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Fri, 5 Sep 2025 22:28:27 -0000 (UTC), Waldek Hebisch wrote:

Well, I would prefer to avoid discussions about what is content, what is
data and what is metadata.

If you bypass RMS and read/write the file contents directly, what you have
is rCLdatarCY.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Fri, 5 Sep 2025 03:02:10 -0000 (UTC), Waldek Hebisch wrote:

SET FILE/ATTR=(RFM:FIX,MRS:1)

but that does not give me expected result.

I recall, long ago, trying to set up a file with fixed-length 1-byte
records, to approximate something that could be reliably transferred to/
from *nix-style systems, but what defeated me was that RMS requires that records start on even byte boundaries.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Waldek Hebisch <antispam@fricas.org> wrote:

Craig A. Berry <craigberry@nospam.mac.com> wrote:

On 9/5/25 6:55 AM, Waldek Hebisch wrote:

I now got to C++ problem. In fact, this may be binutils problem:
gcc generates an assember file and as from binutils-2.21 aborts on
this file. as from current binutils developement tree produces
error message instead:

pom/kompi/gcc/binu-build3/gas/as-new -o array_type_info.obj array_type_info.s
array_type_info.s: Assembler messages:
array_type_info.s: Error: no entry symbol for global function '_ZN10__cxxabiv117__array_type_infoD1Ev'

The offending function is defined in the following way:

.globl _ZN10__cxxabiv117__array_type_infoD1Ev
_ZN10__cxxabiv117__array_type_infoD1Ev = _ZN10__cxxabiv117__array_type_infoD2Ev

If I delete this definition and the ony use of it the file assembles OK. >>> AFAICS this means that _ZN10__cxxabiv117__array_type_infoD2Ev is correctly >>> defined.

Note that this symbol is 38 characters long. The native VMS toolchain
traditionally limits itself to 31-character symbols and uses a checksum
to shorten symbols that are longer. The linker, the librarian, and the
inertia of existing code are all things I've heard blamed for this state
of affairs.

I have no idea whether the tools you are using require or are capable of
observing the 31-character limit. If some parts do and other parts
don't, that could obviously cause trouble, and of course you've got the
C++ name mangler in the mix as well.

IIUC GNU assembler internaly uses arbitrarily long names (in dynamically allocated buffers) and shortens names only on output. Anyway, I
tried shorthening names in the input file and it makes no difference.

All indicates that GNU assembler can not handle simple symbol
equality as intended. Namely relevant part of original code
including definitions of _ZN10__cxxabiv117__array_type_infoD2Ev
and _ZN10__cxxabiv117__array_type_infoD1Ev is:

.link
.align 3
_ZN10__cxxabiv117__array_type_infoD2Ev:
.pdesc _ZN10__cxxabiv117__array_type_infoD2Ev..en,stack $80.._ZNSt9type_infoD2Ev..lk:
.linkage _ZNSt9type_infoD2Ev
.end _ZN10__cxxabiv117__array_type_infoD2Ev
.globl _ZN10__cxxabiv117__array_type_infoD1Ev
_ZN10__cxxabiv117__array_type_infoD1Ev = _ZN10__cxxabiv117__array_type_infoD2Ev

The intent is clearly that _ZN10__cxxabiv117__array_type_infoD1Ev
should be alternative name for _ZN10__cxxabiv117__array_type_infoD2Ev,
but for some reasons assembler can not handle this. AFAICS GNU
assembler for VMS believes that that given function should have
only one name. For example I tried to transform fragment above
to:

.link
.align 3
_ZN10__cxxabiv117__array_type_infoD2Ev:
.pdesc _ZN10__cxxabiv117__array_type_infoD2Ev..en,stack $80.._ZNSt9type_infoD2Ev..lk:
.linkage _ZNSt9type_infoD2Ev
.end _ZN10__cxxabiv117__array_type_infoD2Ev
.globl _ZN10__cxxabiv117__array_type_infoD1Ev
.ent _ZN10__cxxabiv117__array_type_infoD1Ev _ZN10__cxxabiv117__array_type_infoD1Ev:
.pdesc _ZN10__cxxabiv117__array_type_infoD2Ev..en,stack
.linkage _ZNSt9type_infoD2Ev
.end _ZN10__cxxabiv117__array_type_infoD2Ev

that is I actually build second descriptor duplicating content of
descriptor for _ZN10__cxxabiv117__array_type_infoD2Ev and GNU
assembler still does not want to accept this. More precisely,
version 2.21 gives the same error message as original code,
current trunk says:

at3.s: Assembler messages:
at3.s:55: Fatal error: .pdesc doesn't match with last .ent

I do not know if VMS object format allows alternative names,
that is two symbols resolving to the same name (but I also
am not aware of any reason for such restriction), but even
if there were such restriction version with duplicate descriptor
should work around this.

I have tried to do similar thing using DEC assembler and arrived
at the following routine:

.title t2.s
.psect $code,shr,exe,nowrt,quad,pic
.align quad
$ROUTINE ts_fun1, KIND = stack, -
SAVED_REGS = <r2,r3,r4,r5,r6,r7,r8,r9,r10,r11,r12,r13,r14,r15,fp>
.base r27, $LS
$RETURN
$END_ROUTINE
ts_fun2 == ts_fun1

That apparently assembles OK. But ts_fun2 is defined as data
symbol and trying to call it leads to link failure.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/5/2025 10:07 PM, Lawrence DrCOOliveiro wrote:

On Fri, 5 Sep 2025 22:28:27 -0000 (UTC), Waldek Hebisch wrote:

Well, I would prefer to avoid discussions about what is content, what is
data and what is metadata.

If you bypass RMS and read/write the file contents directly, what you have
is rCLdatarCY.

Read like this:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include <descrip.h>
#include <starlet.h>
#include <rms.h>
#include <iodef.h>
#include <fibdef.h>
#include <ssdef.h>

int main(int argc, char *argv[])
{
long stat;
char *fnm = "var.txt";
char expfnm[NAM$C_MAXRSS];
struct FAB fab = cc$rms_fab;
struct NAM nam = cc$rms_nam;
fab.fab$l_fna = (char *)fnm;
fab.fab$b_fns = strlen(fnm);
fab.fab$b_fac = FAB$M_GET;
fab.fab$l_nam = &nam;
nam.nam$b_rss = sizeof(expfnm) - 1;
nam.nam$l_rsa = expfnm;
stat = sys$open(&fab, 0, 0);
//printf("stat = %d\n", stat);
stat = sys$close(&fab, 0, 0);
//printf("stat = %d\n", stat);
struct dsc$descriptor_s devdesc;
devdesc.dsc$b_dtype = DSC$K_DTYPE_T;
devdesc.dsc$b_class = DSC$K_CLASS_S;
devdesc.dsc$w_length = strlen(expfnm);
devdesc.dsc$a_pointer = expfnm;
short chan;
stat = sys$assign(&devdesc, &chan, 0, 0, 0);
//printf("stat = %d\n", stat);
struct fibdef fib;
long fibdesc[] = { FIB$K_LENGTH, (long)&fib };
memset(&fib, 0, sizeof(fib));
fib.fib$w_fid[0] = nam.nam$w_fid[0];
fib.fib$w_fid[1] = nam.nam$w_fid[1];
fib.fib$w_fid[2] = nam.nam$w_fid[2];
unsigned short iosb[4];
stat = sys$qiow(0, chan, IO$_ACCESS | IO$M_ACCESS, iosb, 0, 0,
&fibdesc, 0, 0, 0, 0, 0);
//printf("stat = %d\n", stat);
char buf[512];
int ix = 0;
for(;;)
{
ix++;
stat = sys$qiow(0, chan, IO$_READVBLK, iosb, 0, 0, buf, 512,
ix, 0, 0, 0);
if(iosb[0] == SS$_ENDOFFILE) break;
//printf("stat = %d iosb[0] = %d\n", stat, iosb[0]);
for(int i = 0; i < iosb[1]; i++)
{
printf(" %02X", buf[i]);
if(((i + 1) % 16) == 0) printf("\n");
}
}
stat = sys$qiow(0, chan, IO$_DEACCESS, iosb, 0, 0, &fibdesc, 0, 0,
0, 0, 0);
//printf("stat = %d\n", stat);
stat = sys$dassgn(chan);
//printf("stat = %d\n", stat);
return 0;
}

?

I don't think the output from this will be considered the
file content by many.

:-)

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Sat, 6 Sep 2025 19:55:43 -0400, Arne Vajh|+j wrote:

On 9/5/2025 10:07 PM, Lawrence DrCOOliveiro wrote:

If you bypass RMS and read/write the file contents directly, what you have >> is rCLdatarCY.

Read like this:

[long-winded equivalent to fopen(-2file-+, "rb")/fread/etc omitted]

I don't think the output from this will be considered the
file content by many.

Why not?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/6/2025 9:59 PM, Lawrence DrCOOliveiro wrote:

On Sat, 6 Sep 2025 19:55:43 -0400, Arne Vajh|+j wrote:

On 9/5/2025 10:07 PM, Lawrence DrCOOliveiro wrote:

If you bypass RMS and read/write the file contents directly, what you have >>> is rCLdatarCY.

Read like this:

[long-winded equivalent to fopen(-2file-+, "rb")/fread/etc omitted]

I don't think the output from this will be considered the
file content by many.

Why not?

What do you say?

$ typ var.txt
A
BB
CCC
$ r nonrms
01 00 41 00 02 00 42 42 03 00 43 43 43 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Sat, 6 Sep 2025 22:02:52 -0400, Arne Vajh|+j wrote:

On 9/6/2025 9:59 PM, Lawrence DrCOOliveiro wrote:

On Sat, 6 Sep 2025 19:55:43 -0400, Arne Vajh|+j wrote:

I don't think the output from this will be considered the
file content by many.

Why not?

What do you say?

$ typ var.txt
A
BB
CCC
$ r nonrms

[lots of content omitted]

If thatrCOs what was in the file, then thatrCOs the content.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/7/25 04:02, Arne Vajh|+j wrote:

...
$ typ var.txt
A
BB
CCC
$ r nonrms
-a01 00 41 00 02 00 42 42 03 00 43 43 43 00 00 00
-a00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-a...

There are disk blocks, files and application data.

nonrms prints a disk block.

The file contents ends at FFB in EBK.

The TYPE application interprets the file contents and prints it.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/7/2025 7:31 AM, hb0815 wrote:

On 9/7/25 04:02, Arne Vajh|+j wrote:

...
$ typ var.txt
A
BB
CCC
$ r nonrms
-a-a01 00 41 00 02 00 42 42 03 00 43 43 43 00 00 00
-a-a00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-a-a...

There are disk blocks, files and application data.

nonrms prints a disk block.

The file contents ends at FFB in EBK.

The TYPE application interprets the file contents and prints it.

Yes.

But FFB and EBK are in the record attributes together
with record format etc..

From a QIO perspective a file consist of N allocated
blocks where N is a multipla of allocation size that
can be read and write.

It is also able to read when access and write when
deaccess record attributes, but QIO does not use those
itself.

RMS use record attributes. RFM to know how to interpret
records. And FFB and EBK to know where the logical EOF is.

Point being that dropping RMS and data used by
RMS does not provide a useful result.

It is all a little bit of polemic of course, because
obviously I know that Lawrence wanted to have QIO
use the record attributed, ignore some parts (RFM)
and use other parts (FFB and EBK) to emulate RMS.

Arne





--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/7/2025 9:42 AM, Arne Vajh|+j wrote:

But FFB and EBK are in the record attributes together
with record format etc..

From a QIO perspective a file consist of N allocated
blocks where N is a multipla of allocation size that
can be read and write.

It is also able to read when access and write when
deaccess record attributes, but QIO does not use those
itself.

RMS use record attributes. RFM to know how to interpret
records. And FFB and EBK to know where the logical EOF is.

Point being that dropping RMS and data used by
RMS does not provide a useful result.

It is all a little bit of polemic of course, because
obviously I know that Lawrence wanted to have QIO
use the record attributed, ignore some parts (RFM)
and use other parts (FFB and EBK) to emulate RMS.

Most probably already know this, but for the rest:

$ typ secret.txt
This is top secret.
$ write sys$output f$file("secret.txt","eof")," ",f$file("secret.txt","ffb")
1 22
$ set file/attr=(ebk:0,ffb:0) secret.txt
$ typ secret.txt
$ set file/attr=(ebk:1,ffb:22) secret.txt
$ typ secret.txt
This is top secret.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Sun, 7 Sep 2025 13:31:13 +0200, hb0815 wrote:

The TYPE application interprets the file contents and prints it.

rCLInterpretationrCY of file contents is precisely what you donrCOt want in
a binary file-transfer mode.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-09-07 23:23, Lawrence DrCOOliveiro wrote:

On Sun, 7 Sep 2025 13:31:13 +0200, hb0815 wrote:

The TYPE application interprets the file contents and prints it.

rCLInterpretationrCY of file contents is precisely what you donrCOt want in
a binary file-transfer mode.

So when are you going to start complaining about Unix not giving you the
full content of the allocated blocks for a file, but only up to the
point where the logical eof points to?
At the bottom side, disks are still dealt with in blocks, even under
Unix. The whole idea of a file being of a certain number of bytes
basically just hides from you that there are actually more bytes
allocated to that file.

Johnny

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <109g1s1$3jb20$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

On Fri, 5 Sep 2025 21:32:01 -0000 (UTC), Waldek Hebisch wrote:

All indicates that GNU assembler can not handle simple symbol
equality as intended.

I tried creating a source file test.s containing just your two problem
lines:

.globl _ZN10__cxxabiv117__array_type_infoD1Ev
_ZN10__cxxabiv117__array_type_infoD1Ev = _ZN10__cxxabiv117__array_type_infoD2E

and when I try to assemble it,

gcc -c test.s

there is no error, and test.o is created OK. Trying objdump on it

objdump -t test.o

shows it has the correct symbol reference in it, albeit undefined:

test.o: file format elf64-x86-64

SYMBOL TABLE:
0000000000000000 *UND* 0000000000000000 _ZN10__cxxabiv117__array_type_infoD2E

So no, the issue is not with those two particular lines on their own.
Something else is involved.

Yes. AFAICS main issue is creating alias name for an exported
function. Internal aliases work fine. Probably data aliases too.

I caution against putting it in those terms. What you are doing
in GNU `as` when you use the `a = e` syntax is creating a symbol
called "a" from that is set to the evalue of some expression.
In this contrived example, that expression is just "e", which I
used as a stand-in for any arbitrary expression, but if taken
literally, would just be valuated to the value of some other
symbol, called "e". If "e" was not defined already, it is
assumed to be an external.

When you assemble troll's file, an object file is generated; the
results from `objdump` above show that there is a single symbol
in that object file's symbol table, one you referred to when
creating '_ZN10__cxxabiv117__array_type_infoD2E'. But note that '_ZN10__cxxabiv117__array_type_infoD2E' itself (the symbol that
you created when you assigned to it) is not in the symbol table.

However, the symbol that you created is not in the symbol table,
which is the fundamental problem.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <109g1s1$3jb20$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

Lawrence D|o??Oliveiro <ldo@nz.invalid> wrote:

On Fri, 5 Sep 2025 21:32:01 -0000 (UTC), Waldek Hebisch wrote:

All indicates that GNU assembler can not handle simple symbol
equality as intended.

I tried creating a source file test.s containing just your two problem
lines:

.globl _ZN10__cxxabiv117__array_type_infoD1Ev
_ZN10__cxxabiv117__array_type_infoD1Ev = _ZN10__cxxabiv117__array_type_infoD2E

and when I try to assemble it,

gcc -c test.s

there is no error, and test.o is created OK. Trying objdump on it

objdump -t test.o

shows it has the correct symbol reference in it, albeit undefined:

test.o: file format elf64-x86-64

SYMBOL TABLE:
0000000000000000 *UND* 0000000000000000 _ZN10__cxxabiv117__array_type_infoD2E

So no, the issue is not with those two particular lines on their own.
Something else is involved.

Yes. AFAICS main issue is creating alias name for an exported
function. Internal aliases work fine. Probably data aliases too.

I caution against putting it in those terms. What you are doing
in GNU `as` when you use the `a = e` syntax is creating a symbol
called "a" from that is set to the evalue of some expression.
In this contrived example, that expression is just "e", which I
used as a stand-in for any arbitrary expression, but if taken
literally, would just be valuated to the value of some other
symbol, called "e". If "e" was not defined already, it is
assumed to be an external.

When you assemble troll's file, an object file is generated; the
results from `objdump` above show that there is a single symbol
in that object file's symbol table, one you referred to when
creating '_ZN10__cxxabiv117__array_type_infoD2E'. But note that '_ZN10__cxxabiv117__array_type_infoD2E' itself (the symbol that
you created when you assigned to it) is not in the symbol table.

However, the symbol that you created is not in the symbol table,
which is the fundamental problem.

Well, one issue is if needed construct is supported at all.

Other platforms have code like:

.text
.globl exp_fun
.type exp_fun, @function
exp_fun:
ret
.LFE0:
.size exp_fun, .-exp_fun
.globl alias_fun
.set alias_fun,exp_fun

Assembling this on x86 Linux gives object file exporting two symbols:
exp_fun and alias_fun. IIUC this behaviour is wanted by C++
compiler.

Alpha VMS needs more complicated function definition. And more
important: '.set alias_fun,exp_fun' causes assembler message
about wrong syntax.

In DEC assembler '=' apparently gives effect that you describe:
new name is not exported. In DEC assembler '==' apparently creates
an alias, but as a data symbol. I am not aware of DEC construct
to get effect of '.set' as in x86 Linux example above (but up
to now I did not look into macro manual). So '=' probably is
wrong syntatx, I do not know why gcc uses it.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <109mep8$84ft$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <109g1s1$3jb20$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

Lawrence D|o??Oliveiro <ldo@nz.invalid> wrote:

On Fri, 5 Sep 2025 21:32:01 -0000 (UTC), Waldek Hebisch wrote:

All indicates that GNU assembler can not handle simple symbol
equality as intended.

I tried creating a source file test.s containing just your two problem >>>> lines:

.globl _ZN10__cxxabiv117__array_type_infoD1Ev
_ZN10__cxxabiv117__array_type_infoD1Ev = >_ZN10__cxxabiv117__array_type_infoD2E

and when I try to assemble it,

gcc -c test.s

there is no error, and test.o is created OK. Trying objdump on it

objdump -t test.o

shows it has the correct symbol reference in it, albeit undefined:

test.o: file format elf64-x86-64

SYMBOL TABLE:
0000000000000000 *UND* 0000000000000000 >_ZN10__cxxabiv117__array_type_infoD2E

So no, the issue is not with those two particular lines on their own.
Something else is involved.

Yes. AFAICS main issue is creating alias name for an exported
function. Internal aliases work fine. Probably data aliases too.

I caution against putting it in those terms. What you are doing
in GNU `as` when you use the `a = e` syntax is creating a symbol
called "a" from that is set to the evalue of some expression.
In this contrived example, that expression is just "e", which I
used as a stand-in for any arbitrary expression, but if taken
literally, would just be valuated to the value of some other
symbol, called "e". If "e" was not defined already, it is
assumed to be an external.

When you assemble troll's file, an object file is generated; the
results from `objdump` above show that there is a single symbol
in that object file's symbol table, one you referred to when
creating '_ZN10__cxxabiv117__array_type_infoD2E'. But note that
'_ZN10__cxxabiv117__array_type_infoD2E' itself (the symbol that
you created when you assigned to it) is not in the symbol table.

However, the symbol that you created is not in the symbol table,
which is the fundamental problem.

Well, one issue is if needed construct is supported at all.

Other platforms have code like:

.text
.globl exp_fun
.type exp_fun, @function
exp_fun:
ret
.LFE0:
.size exp_fun, .-exp_fun
.globl alias_fun
.set alias_fun,exp_fun

Assembling this on x86 Linux gives object file exporting two symbols:
exp_fun and alias_fun. IIUC this behaviour is wanted by C++
compiler.

Alpha VMS needs more complicated function definition. And more
important: '.set alias_fun,exp_fun' causes assembler message
about wrong syntax.

In DEC assembler '=' apparently gives effect that you describe:
new name is not exported. In DEC assembler '==' apparently creates
an alias, but as a data symbol. I am not aware of DEC construct
to get effect of '.set' as in x86 Linux example above (but up
to now I did not look into macro manual). So '=' probably is
wrong syntatx, I do not know why gcc uses it.

So the GNU `as` documentation says that `a = e` has the same
semamtics as `.set a, e`. Why isn't the Alpha version exporting
that symbol? I don't know off the top of my head. But it's not
specific to Alpha: my experiments were on x86. My suspcion
is that its because it is not used in the file itself.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <109mep8$84ft$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <109g1s1$3jb20$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

Lawrence D|a-o??Oliveiro <ldo@nz.invalid> wrote:

On Fri, 5 Sep 2025 21:32:01 -0000 (UTC), Waldek Hebisch wrote:

All indicates that GNU assembler can not handle simple symbol
equality as intended.

I tried creating a source file test.s containing just your two problem >>>>> lines:

.globl _ZN10__cxxabiv117__array_type_infoD1Ev
_ZN10__cxxabiv117__array_type_infoD1Ev = >>_ZN10__cxxabiv117__array_type_infoD2E

and when I try to assemble it,

gcc -c test.s

there is no error, and test.o is created OK. Trying objdump on it

objdump -t test.o

shows it has the correct symbol reference in it, albeit undefined:

test.o: file format elf64-x86-64

SYMBOL TABLE:
0000000000000000 *UND* 0000000000000000 >>_ZN10__cxxabiv117__array_type_infoD2E

So no, the issue is not with those two particular lines on their own. >>>>> Something else is involved.

Yes. AFAICS main issue is creating alias name for an exported >>>>function. Internal aliases work fine. Probably data aliases too.

I caution against putting it in those terms. What you are doing
in GNU `as` when you use the `a = e` syntax is creating a symbol
called "a" from that is set to the evalue of some expression.
In this contrived example, that expression is just "e", which I
used as a stand-in for any arbitrary expression, but if taken
literally, would just be valuated to the value of some other
symbol, called "e". If "e" was not defined already, it is
assumed to be an external.

When you assemble troll's file, an object file is generated; the
results from `objdump` above show that there is a single symbol
in that object file's symbol table, one you referred to when
creating '_ZN10__cxxabiv117__array_type_infoD2E'. But note that
'_ZN10__cxxabiv117__array_type_infoD2E' itself (the symbol that
you created when you assigned to it) is not in the symbol table.

However, the symbol that you created is not in the symbol table,
which is the fundamental problem.

Well, one issue is if needed construct is supported at all.

Other platforms have code like:

.text
.globl exp_fun
.type exp_fun, @function
exp_fun:
ret
.LFE0:
.size exp_fun, .-exp_fun
.globl alias_fun
.set alias_fun,exp_fun

Assembling this on x86 Linux gives object file exporting two symbols: >>exp_fun and alias_fun. IIUC this behaviour is wanted by C++
compiler.

Alpha VMS needs more complicated function definition. And more
important: '.set alias_fun,exp_fun' causes assembler message
about wrong syntax.

In DEC assembler '=' apparently gives effect that you describe:
new name is not exported. In DEC assembler '==' apparently creates
an alias, but as a data symbol. I am not aware of DEC construct
to get effect of '.set' as in x86 Linux example above (but up
to now I did not look into macro manual). So '=' probably is
wrong syntatx, I do not know why gcc uses it.

So the GNU `as` documentation says that `a = e` has the same
semamtics as `.set a, e`. Why isn't the Alpha version exporting
that symbol? I don't know off the top of my head. But it's not
specific to Alpha: my experiments were on x86. My suspcion
is that its because it is not used in the file itself.

GNU assembler has four similar constructs: .set, .eqv, = and ==.
Generically .set is claimed to be the same as =, .eqv is claimed
to be the same as ==. But on some platforms .set and = differ
and Alpha VMS seem to one of such platforms.

I tried now '==' and it is possible that this is needed: using
it I get two text symbols which resolve to the same address.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 9/8/2025 7:30 AM, Waldek Hebisch wrote:

In DEC assembler '=' apparently gives effect that you describe:
new name is not exported. In DEC assembler '==' apparently creates
an alias, but as a data symbol. I am not aware of DEC construct
to get effect of '.set' as in x86 Linux example above (but up
to now I did not look into macro manual). So '=' probably is
wrong syntatx, I do not know why gcc uses it.

In the DEC Macro-64 assembler there is an argument to $routine
for aliases.

$ type tst.for
program tst
integer*4 func_1,func_2,func_3
write(*,*) func_1()
write(*,*) func_2()
write(*,*) func_3()
end
$ type f.m64
$code_section
$routine name=FUNC_1,aliases=<FUNC_2,FUNC_3>,kind=stack
mov #42, r0
$return
$end_routine FUNC_1
.end
$ for tst
$ macro/alpha f
$ link tst + f
$ run tst
42
42
42

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2