Den 2022-09-19 kl. 22:41, skrev Arne Vajhøj:
> On 9/19/2022 2:21 PM, Single Stage to Orbit wrote:
>> On Mon, 2022-09-19 at 11:28 +0200, Jan-Erik Söderholm wrote:
>>> Den 2022-09-19 kl. 01:58, skrev Arne Vajhøj:
>>>
>>> Interesting! Now, what was that link now... :-)
>>
>> I bookmarked it some time ago:
>> https://www.vajhoej.dk/arne/articles/vmsipc.html
>
> Yep. Sorry for not include the link.
>
> Arne
>
>

No problem... :-)

In the part about mailboxes, I miss one language, DCL.

$ create/mailbox/perm abc

$ open/write abc
$ write abc "Hello".
$ close abc

$ open/read abc
$ read abc inline
$ write sys$output 'inline'

Very short example, and it might not work...

On 9/19/2022 6:06 PM, Jan-Erik Söderholm wrote:
> Den 2022-09-19 kl. 22:41, skrev Arne Vajhøj:
>> On 9/19/2022 2:21 PM, Single Stage to Orbit wrote:
>>> On Mon, 2022-09-19 at 11:28 +0200, Jan-Erik Söderholm wrote:
>>>> Den 2022-09-19 kl. 01:58, skrev Arne Vajhøj:
>>>>
>>>> Interesting! Now, what was that link now... :-)
>>>
>>> I bookmarked it some time ago:
>>> https://www.vajhoej.dk/arne/articles/vmsipc.html
>>
>> Yep. Sorry for not include the link.
>
> No problem... :-)
>
> In the part about mailboxes, I miss one language, DCL.
>
> $ create/mailbox/perm abc
>
>
> $ open/write abc
> $ write abc "Hello".
> $ close abc
>
> $ open/read abc
> $ read abc inline
> $ write sys$output 'inline'
>
> Very short example, and it might not work...

It should be possible to make it work.

Thinking about it - index-sequential files are
also accessible from DCL.

More to go on the TODO list.

Arne

On 2022-09-19 22:06:21 +0000, Jan-Erik Sderholm said:

> In the part about mailboxes, I miss one language, DCL.
> ...

Here's DCL DECnet task-to-task:

https://www.digiater.nl/openvms/freeware/v80/hoffman_examples/xqtype.com

Wouldn't suggest using any of this for anything particularly relevent
or sensitive, and it's dicy even on a trusted network.

Unfortunately, DCL lacks TCP, TLS, and ssh connectivity support, and
lacks async / full duplex support.

--
Pure Personal Opinion | HoffmanLabs LLC

On 9/19/2022 6:51 PM, Arne Vajhøj wrote:
> On 9/19/2022 6:06 PM, Jan-Erik Söderholm wrote:
>> Den 2022-09-19 kl. 22:41, skrev Arne Vajhøj:
>>> On 9/19/2022 2:21 PM, Single Stage to Orbit wrote:
>>>> On Mon, 2022-09-19 at 11:28 +0200, Jan-Erik Söderholm wrote:
>>>>> Den 2022-09-19 kl. 01:58, skrev Arne Vajhøj:
>>>>>
>>>>> Interesting! Now, what was that link now... :-)
>>>>
>>>> I bookmarked it some time ago:
>>>> https://www.vajhoej.dk/arne/articles/vmsipc.html
>>>
>>> Yep. Sorry for not include the link.
>>
>> No problem... :-)
>>
>> In the part about mailboxes, I miss one language, DCL.
>>
>> $ create/mailbox/perm abc
>>
>>
>> $ open/write abc
>> $ write abc "Hello".
>> $ close abc
>>
>> $ open/read abc
>> $ read abc inline
>> $ write sys$output 'inline'
>>
>> Very short example, and it might not work...
>
> It should be possible to make it work.
>
> Thinking about it - index-sequential files are
> also accessible from DCL.
>
> More to go on the TODO list.

Added:
* mailboxes / DCL
* socket / PHP
* index-sequential file / DCL
* SQLite / PHP

Arne

On 9/12/2022 10:36 PM, John Forkosh wrote:
> Arne Vajh??j <arne@vajhoej.dk> wrote:
>> I did a little writeup:
>> https://www.vajhoej.dk/arne/articles/vmsipc.html
>> Content:
...
> Thanks so much. That's really terrific. And ditto for your other
> articles https://www.vajhoej.dk/arne/articles.html which I hadn't
> even been aware of.

Thank you.

> Maybe you might arrange/aggregate them into one
> or more books along the lines of Stallman's just released C tutorial
> and reference https://git.savannah.gnu.org/git/c-intro-and-ref.git

I have actually at occasions played with the idea.

But it would require some effort.

Maybe.

Arne

On 9/15/2022 4:32 PM, Arne Vajhøj wrote:
> On 9/15/2022 2:58 AM, Richard Maher wrote:
>> Not necessarily. Show me VMS/Redis Cache, VMS GitHub, something to
>> load my VMS Tier3 ASCII files to GitHub
>
> Redis should be available:
>
> https://vmssoftware.com/products/redis/
>
> BTW, Redis would fit quite nicely into this article, so I will put that
> on the TODO list.

Done.

https://www.vajhoej.dk/arne/articles/vmsipc.html#redis

Redis Cache
Concept
Demo
Hiredis (C)
Official VMS wrapper hiredis (Fortran, Pascal, Cobol, Basic)
Custom VMS wrapper hiredis (Fortran, Pascal, Cobol, Basic)
Jedis (Java, Jython)
Python module (Python)

And just to be clear: this is Redis server running on VMS and client
applications running on VMS.

Arne

On 2022-09-28, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 9/15/2022 4:32 PM, Arne Vajhøj wrote:
>> On 9/15/2022 2:58 AM, Richard Maher wrote:
>>> Not necessarily. Show me VMS/Redis Cache, VMS GitHub, something to
>>> load my VMS Tier3 ASCII files to GitHub
>>
>> Redis should be available:
>>
>> https://vmssoftware.com/products/redis/
>>
>> BTW, Redis would fit quite nicely into this article, so I will put that
>> on the TODO list.
>
> Done.
>
> https://www.vajhoej.dk/arne/articles/vmsipc.html#redis
>

$ set response/mode=good_natured

This is just a guess Arne, but have you by any chance currently got
a lot of spare time on your hands ?

:-)

Simon.

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

On 9/29/2022 8:57 AM, Simon Clubley wrote:
> On 2022-09-28, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 9/15/2022 4:32 PM, Arne Vajhøj wrote:
>>> On 9/15/2022 2:58 AM, Richard Maher wrote:
>>>> Not necessarily. Show me VMS/Redis Cache, VMS GitHub, something to
>>>> load my VMS Tier3 ASCII files to GitHub
>>>
>>> Redis should be available:
>>>
>>> https://vmssoftware.com/products/redis/
>>>
>>> BTW, Redis would fit quite nicely into this article, so I will put that
>>> on the TODO list.
>>
>> Done.
>>
>> https://www.vajhoej.dk/arne/articles/vmsipc.html#redis
>
> $ set response/mode=good_natured
>
> This is just a guess Arne, but have you by any chance currently got
> a lot of spare time on your hands ?
>
> :-)

Not really.

I started writing stuff in 2004.

Recently I have just written a lot about VMS.

And even though is is obviously some work, then I reuse
stuff - for Redis I had most of the API's covered from
when I wrote about cache servers in general back in 2020 - all
the tests back then was done on Windows but the C, Java and
Python API's are the same on on VMS, so I did not have to
start from scratch.

Arne

On 9/13/2022 8:34 PM, Arne Vajhøj wrote:
> I do not have any experience wth sys$icc_* so that will
> need a little research.

Done.

https://www.vajhoej.dk/arne/articles/vmsipc.html#icc

ICC
Concept
Demo
System Service (C, Fortran, Pascal)

Arne

On Wednesday, October 5, 2022 at 12:11:32 AM UTC+1, Arne Vajhøj wrote:
> On 9/13/2022 8:34 PM, Arne Vajhøj wrote:
> > I do not have any experience wth sys$icc_* so that will
> > need a little research.
> Done.
>
> https://www.vajhoej.dk/arne/articles/vmsipc.html#icc
>
> ICC
> Concept
> Demo
> System Service (C, Fortran, Pascal)
>
> Arne
the ICC routines are intriguing. Good to see an example. Did you report the issue with Pascal to VSI?

On Wednesday, October 5, 2022 at 11:28:16 AM UTC+2, Ian Miller wrote:
> On Wednesday, October 5, 2022 at 12:11:32 AM UTC+1, Arne Vajhøj wrote:
> > On 9/13/2022 8:34 PM, Arne Vajhøj wrote:
> > > I do not have any experience wth sys$icc_* so that will
> > > need a little research.
> > Done.
> >
> > https://www.vajhoej.dk/arne/articles/vmsipc.html#icc
> >
> > ICC
> > Concept
> > Demo
> > System Service (C, Fortran, Pascal)
> >
> > Arne
> the ICC routines are intriguing. Good to see an example. Did you report the issue with Pascal to VSI?

I have not heard about any issues with the ICC definitions being Pascal "unfriendly".

If you ever want to override/bypass the type checking between the actual parameter and the formal parameter, you can use an explicit %IMMED, %REF, or %STDESCR as appropriate on the actual parameter. In that case, the compiler will skip the check and just pass what you specified. You can even provide more arguments than in the format definition by just using explicit argument mechanisms on the "extra" arguments.

On 10/5/2022 3:17 PM, John Reagan wrote:
> On Wednesday, October 5, 2022 at 11:28:16 AM UTC+2, Ian Miller wrote:
>> On Wednesday, October 5, 2022 at 12:11:32 AM UTC+1, Arne Vajhøj wrote:
>>> On 9/13/2022 8:34 PM, Arne Vajhøj wrote:
>>>> I do not have any experience wth sys$icc_* so that will
>>>> need a little research.
>>> Done.
>>>
>>> https://www.vajhoej.dk/arne/articles/vmsipc.html#icc
>>>
>>> ICC
>>> Concept
>>> Demo
>>> System Service (C, Fortran, Pascal)

>> the ICC routines are intriguing. Good to see an example. Did you report the issue with Pascal to VSI?
>
> I have not heard about any issues with the ICC definitions being Pascal "unfriendly".

I think only a small fraction of VMS sites use the ICC stuff and only a
small fraction of those use Pascal as language (the ICC stuff is new
enough to C being most common language).

But the fact that I could not get it working does not prove there
is a problem in SYS$LIBRARY:STARLET.PAS - maybe the problem is 40 cm
(16 inches) in front of the screen.

:-)

But some things puzzles me.

The client programs all use:
sys$icc_connectw
sys$icc_transmitw
sys$icc_receivew
sys$icc_disconnectw

All of them have an IOSB argument.

Per the documentation those are:
8 byte IOSB
8 byte IOSB
16 byte IOSB
8 byte IOSB

C has a:
struct _ios_icc

And defines the arguments for the 4 system services as as:
struct _ios_icc *ios_icc
struct _ios_icc *ios_icc
struct _ios_icc *ios_icc
struct _iosb *iosb

Which works fine. It is not obvious to me why the the last one is
different, but no problem.

Pascal has a record IOS_ICC$TYPE and it works fine for me, so that is
all good.

But the argument to the functions are defined as:
VAR IOS_ICC : [VOLATILE] $DEFPTR;
VAR IOS_ICC : [VOLATILE] $UQUAD;
VAR IOS_ICC : [VOLATILE] $DEFPTR;
VAR IOSB : [VOLATILE] $UQUAD;

With:
$DEFPTR = [UNSAFE] ^$DEFTYP;
$DEFTYP = [UNSAFE] INTEGER;
$UQUAD = [QUAD,UNSAFE] RECORD L0,L1:UNSIGNED; END;

Which seems inconsistent and hard/impossible to use for me
($DEFPTR really gave me a hard time).

So I simply used other declarations with arguments:
VAR IOS_ICC : [VOLATILE] IOS_ICC$TYPE;
VAR IOS_ICC : [VOLATILE] IOS_ICC$TYPE;
VAR IOS_ICC : [VOLATILE] IOS_ICC$TYPE;
VAR IOSB : [VOLATILE] IOS_ICC$TYPE;

It works fine and seems a lot more logical to me.

I also had problems with the buffers. $ICC_TRANSMITW
has a SEND_BUF and $ICC_RECEIVEW has a RECV_BUF but they
are declared as $DEFPTR and UNSIGNED. That gave my problems with
transmit so I changed SEND_BUF to also be UNSIGNED.

Arne

On 10/5/2022 7:06 PM, Arne Vajhøj wrote:
> I also had problems with the buffers. $ICC_TRANSMITW
> has a SEND_BUF and $ICC_RECEIVEW has a RECV_BUF but they
> are declared as $DEFPTR and UNSIGNED. That gave my problems with
> transmit so I changed SEND_BUF to also be UNSIGNED.

Let me elaborate on this.

The sys$libary:starlet.pas definition is:
SEND_BUF : $DEFPTR;

And I cannot get that to work.

I am probably missing something very basic, but ...

Demo:

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

void f(unsigned char *s)
{ printf("%02X %02X %02X %02X %02X %02X %02X %02X\n", s[0], s[1],
s[2], s[3], s[4], s[5], s[6], s[7]);
} $ cc zb
$ type za.pas
program za(input,output);

type
$DEFTYP = [UNSAFE] INTEGER;
$DEFPTR = [UNSAFE] ^$DEFTYP;

[external('F')] procedure f1(%IMMED s : unsigned); external;
[external('F')] procedure f2(s : $DEFPTR); external;
[external('F')] procedure f3(%IMMED s : $DEFPTR); external;

var
s : varying [255] of char;

begin
s := 'ABCDEF' + chr(0);
f1(iaddress(s.body));
f2(s.body);
f2(iaddress(s.body));
f3(s.body);
f3(iaddress(s.body));
end.
$ pas za
$ link za + zb
$ run za
41 42 43 44 45 46 00 00
41 42 43 44 00 00 00 00
CA 79 E2 7A 00 00 00 00
00 00 00 00 00 00 00 00
41 42 43 44 45 46 00 00

Especially:
f2(s.body);
output puzzles me.

Arne

On 9/12/2022 6:58 PM, Arne Vajhøj wrote:
> I did a little writeup:
>
> https://www.vajhoej.dk/arne/articles/vmsipc.html

>     TCP/IP Socket
>         Concept
>         Demo
>         Java API (Java)
>         C API (C)
>         Python API (Python, Jython)
>         Wrapper C API (Fortran, Pascal, Cobol, Basic)

Just added:

HTTP
Concept
Demo
Embedded server (Java, Python)
Java API (Java)
urllib3 (Python)
Curl (C, PHP)
Direct socket (C)
Wrapper direct socket (Fortran, Pascal, Cobol, Basic)

Arne

On 2022-10-30, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 9/12/2022 6:58 PM, Arne Vajhøj wrote:
>> I did a little writeup:
>>
>> https://www.vajhoej.dk/arne/articles/vmsipc.html
>

A suggestion: you should add a link back to the main entry point on your
website to the top of each of these pages. There's no immediate obvious
way to get to all of your website when you go in at a specific page such
as this one.

>>     TCP/IP Socket
>>         Concept
>>         Demo
>>         Java API (Java)
>>         C API (C)
>>         Python API (Python, Jython)
>>         Wrapper C API (Fortran, Pascal, Cobol, Basic)
>
> Just added:
>
> HTTP
> Concept
> Demo
> Embedded server (Java, Python)
> Java API (Java)
> urllib3 (Python)
> Curl (C, PHP)
> Direct socket (C)
> Wrapper direct socket (Fortran, Pascal, Cobol, Basic)
>

Have you considered adding articles about 64-bit memory access programming
on VMS and its limits ? Or is everyone already (painfully :-)) aware of
the issues involved here ?

Simon.

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

On 10/31/2022 9:18 AM, Simon Clubley wrote:
> On 2022-10-30, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 9/12/2022 6:58 PM, Arne Vajhøj wrote:
>>> I did a little writeup:
>>>
>>> https://www.vajhoej.dk/arne/articles/vmsipc.html
>
> A suggestion: you should add a link back to the main entry point on your
> website to the top of each of these pages. There's no immediate obvious
> way to get to all of your website when you go in at a specific page such
> as this one.

There is a link at the bottom.

>>>     TCP/IP Socket
>>>         Concept
>>>         Demo
>>>         Java API (Java)
>>>         C API (C)
>>>         Python API (Python, Jython)
>>>         Wrapper C API (Fortran, Pascal, Cobol, Basic)
>>
>> Just added:
>>
>> HTTP
>> Concept
>> Demo
>> Embedded server (Java, Python)
>> Java API (Java)
>> urllib3 (Python)
>> Curl (C, PHP)
>> Direct socket (C)
>> Wrapper direct socket (Fortran, Pascal, Cobol, Basic)
>>
>
> Have you considered adding articles about 64-bit memory access programming
> on VMS and its limits ? Or is everyone already (painfully :-)) aware of
> the issues involved here ?

I have not considered that.

Long opinionated writing about what DEC decided 30 years ago,
why, consequences of that and, discussions about whether DEC
made the right decision and discussions about what VSI should do
now are out of scope for the series.

And from the more practical perspective I don't think there
is enough to write about. One page with background,
one page with all the stuff one can do in C and one
page about the fun of Java calling C via JNI. That
must be about it.

Arne

On 10/31/2022 9:06 PM, Arne Vajhøj wrote:
> On 10/31/2022 9:18 AM, Simon Clubley wrote:
>> Have you considered adding articles about 64-bit memory access
>> programming
>> on VMS and its limits ? Or is everyone already (painfully :-)) aware of
>> the issues involved here ?
>
> I have not considered that.
>
> Long opinionated writing about what DEC decided 30 years ago,
> why, consequences of that and, discussions about whether DEC
> made the right decision and discussions about what VSI should do
> now are out of scope for the series.
>
> And from the more practical perspective I don't think there
> is enough to write about. One page with background,
> one page with all the stuff one can do in C and one
> page about the fun of Java calling C via JNI. That
> must be about it.

I decided to do it anyway.

And it turned out to be more than 3 pages to write.

Pre-release for comments:

https://www.vajhoej.dk/arne/articles/vms64.html

Arne

On 10/31/2022 9:06 PM, Arne Vajhøj wrote:
> On 10/31/2022 9:18 AM, Simon Clubley wrote:
>> Have you considered adding articles about 64-bit memory access
>> programming
>> on VMS and its limits ? Or is everyone already (painfully :-)) aware

> I decided to do it anyway.
>
> And it turned out to be more than 3 pages to write.
>
> Pre-release for comments:
>
> https://www.vajhoej.dk/arne/articles/vms64.html

Looks good. Thanks for doing that. You may be interested in the
following tidbits that showed up in the release notes for the new
clang++ compiler:

1.3 Differences Between C++ on OpenVMS Itanium and OpenVMS x86

The datatypes 'long', 'size_t', 'nullptr_t', 'ptrdiff_t' are 64-bits
wide on OpenVMS x86 but only 32-bits wide on OpenVMS Itanium.

The default size for pointers is 64-bits on OpenVMS x86 but only 32-bits
on OpenVMS Itanium.

On 3/10/2023 6:09 PM, Craig A. Berry wrote:
>
> On 10/31/2022 9:06 PM, Arne Vajhøj wrote:
>> On 10/31/2022 9:18 AM, Simon Clubley wrote:
>>> Have you considered adding articles about 64-bit memory access
>>> programming
>>> on VMS and its limits ? Or is everyone already (painfully :-)) aware
>
>> I decided to do it anyway.
>>
>> And it turned out to be more than 3 pages to write.
>>
>> Pre-release for comments:
>>
>> https://www.vajhoej.dk/arne/articles/vms64.html
>
>
> Looks good.  Thanks for doing that.  You may be interested in the
> following tidbits that showed up in the release notes for the new
> clang++ compiler:
>
> 1.3 Differences Between C++ on OpenVMS Itanium and OpenVMS x86
>
> The datatypes 'long', 'size_t', 'nullptr_t', 'ptrdiff_t' are 64-bits
> wide on OpenVMS x86 but only 32-bits wide on OpenVMS Itanium.
>
> The default size for pointers is 64-bits on OpenVMS x86 but only 32-bits
> on OpenVMS Itanium.

So /POINTER=64 is default. I should make a note about that.

Curious about long being 64 bit.

So:
Alpha & Itanium x86-64
short 16 16
int 32 32
long 32 64
long long 64 ?

?

I guess it is way overdue to always use intxx_t!

:-)

Arne

Arne Vajhøj schrieb am Freitag, 10. März 2023 um 22:01:40 UTC+1:
> On 10/31/2022 9:06 PM, Arne Vajhøj wrote:
> > On 10/31/2022 9:18 AM, Simon Clubley wrote:
> >> Have you considered adding articles about 64-bit memory access
> >> programming
> >> on VMS and its limits ? Or is everyone already (painfully :-)) aware of
> >> the issues involved here ?
> >
> > I have not considered that.
> >
> > Long opinionated writing about what DEC decided 30 years ago,
> > why, consequences of that and, discussions about whether DEC
> > made the right decision and discussions about what VSI should do
> > now are out of scope for the series.
> >
> > And from the more practical perspective I don't think there
> > is enough to write about. One page with background,
> > one page with all the stuff one can do in C and one
> > page about the fun of Java calling C via JNI. That
> > must be about it.
> I decided to do it anyway.
>
> And it turned out to be more than 3 pages to write.
>
> Pre-release for comments:
>
> https://www.vajhoej.dk/arne/articles/vms64.html
>
> Arne

Thanks for your effort.

I like to add, that you can successfully access the lower 2 GB of P2
(%X00000000 80000000..%X00000000 FFFFFFFF) with 32 bit
pointers and descriptors.
You only have to treat the pointers as unsigned instead of signed
avoiding them to be interpreted as S0/S1 addresses.
We successfully use this in Pascal, which is missing 64-Bit descriptors.
The caller of a routine can then simply pass a structure in lower P2
without any special adaptions (except having to use the compiler
qualifier /USAGE=64BIT_TO_DESCR).
The routine itself has to do some additional work. It must extract the
structure's address from the descriptor and copy it to a 64-Bit Pointer
WITHOUT sign extension.
This makes the structure directly accessible although it resides in P2.

I wished treating descriptor pointers as unsigned would be the default
behaviour. The reason is simple: You will find extremely few application
programmers who ever needed to access an S0 or S1 structure via
descriptor - but many who would like to access P2 data.

Treating 32-bit pointers as unsigned is probably possible in any language
available under VMS.

Andreas

Arne Vajhøj wrote:
> On 10/31/2022 9:06 PM, Arne Vajhøj wrote:
>> On 10/31/2022 9:18 AM, Simon Clubley wrote:
>>> Have you considered adding articles about 64-bit memory access
>>> programming
>>> on VMS and its limits ? Or is everyone already (painfully :-)) aware of
>>> the issues involved here ?
>>
>> I have not considered that.
>>
>> Long opinionated writing about what DEC decided 30 years ago,
>> why, consequences of that and, discussions about whether DEC
>> made the right decision and discussions about what VSI should do
>> now are out of scope for the series.
>>
>> And from the more practical perspective I don't think there
>> is enough to write about. One page with background,
>> one page with all the stuff one can do in C and one
>> page about the fun of Java calling C via JNI. That
>> must be about it.
>
> I decided to do it anyway.
>
> And it turned out to be more than 3 pages to write.
>
> Pre-release for comments:
>
> https://www.vajhoej.dk/arne/articles/vms64.html
>
> Arne
>
>
>
I maintain a web-page on 64-bit pointers when using VSI-Fortran. The
site contains many problems you can encounter and what the work-arounds are.

Jouk

JOUKJ wrote:
> I maintain a web-page on 64-bit pointers when using VSI-Fortran. The
> site contains many problems you can encounter and what the work-arounds
> are.

I forgot to copy the link:

http://nchrem.tnw.tudelft.nl/openvms/fortran64.html

Den 2023-03-13 kl. 11:22, skrev JOUKJ:
> Arne Vajhøj wrote:
>>
>> Pre-release for comments:
>>
>> https://www.vajhoej.dk/arne/articles/vms64.html
>>
>> Arne

A bit pre-dated also... :-)

Article history:
Version Date Description
0.9 March 10th 20223 Pre-release

On 2023-03-10, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 10/31/2022 9:06 PM, Arne Vajhøj wrote:
>> On 10/31/2022 9:18 AM, Simon Clubley wrote:
>>> Have you considered adding articles about 64-bit memory access
>>> programming
>>> on VMS and its limits ? Or is everyone already (painfully :-)) aware of
>>> the issues involved here ?
>>
>> I have not considered that.
>>
>> Long opinionated writing about what DEC decided 30 years ago,
>> why, consequences of that and, discussions about whether DEC
>> made the right decision and discussions about what VSI should do
>> now are out of scope for the series.
>>
>> And from the more practical perspective I don't think there
>> is enough to write about. One page with background,
>> one page with all the stuff one can do in C and one
>> page about the fun of Java calling C via JNI. That
>> must be about it.
>
> I decided to do it anyway.
>
> And it turned out to be more than 3 pages to write.
>
> Pre-release for comments:
>
> https://www.vajhoej.dk/arne/articles/vms64.html
>

Typo:

"reduce memoy usage"

Generally, a well-written article.

One comment is to consider what the average person used to other operating
systems may ask and that is "why wasn't the operating system and the RTLs
simply recompiled to use 64-bit pointers instead of 32-bit pointers" ?

You have done some work at explaining this, but it doesn't state clearly
enough the real answer, which is that on VMS, pointers in the languages
and structures used to implement VMS are not hidden behind an abstracted
pointer type (ie: unsigned char *ptr), but are really just directly visible
integers (ie: uint32_t ptr).

Simon.

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

On 2023-03-10, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> So /POINTER=64 is default. I should make a note about that.
>
> Curious about long being 64 bit.
>
> So:
> Alpha & Itanium x86-64
> short 16 16
> int 32 32
> long 32 64
> long long 64 ?
>
> ?
>
> I guess it is way overdue to always use intxx_t!
>
>:-)
>

Even better is to use uintXX_t unless you really want a signed integer. :-)

A big mistake languages made (IMHO) was to make their integers signed
by default, instead of you needing to ask for a signed integer if you
really needed one.

Simon.

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