On 1/9/2024 7:42 PM, Arne Vajhøj wrote:
> On 1/9/2024 7:14 PM, Lawrence D'Oliveiro wrote:
>> On Tue, 9 Jan 2024 18:33:13 -0500, Dave Froble wrote:
>>> I seriously doubt that any [noddy] users would take advantage of a
>>> conversion to 64 bit addresses.  So why bother?
>>
>> In the x86-32/x86-64 situation in particular, the 32-bit architecture is
>> known for being register-poor. This is alleviated somewhat in the 64-bit
>> extensions. This means a compiler can generate more efficient code using
>> the 64-bit instructions.
>
> And?
>
> The VMS 32 vs 64 bit discussion has nothing to do with traditional
> 32 bit vs 64 bit.
>
> There has never been and never will be a VMS Basic for x86 (IA-32).
>
> VMS Basic is expected to become available for VMS x86-64 any day.
>
> And we expect it to store 32 bit pointers because that is
> what it does on Alpha and Itanium.
>
> It will use x86-64 instructions and x86-64 registers and x86-64
> address space and so on.
>
> And we are discussing whether it some day in the future should
> switch to use 64 bit pointers.

It's BASIC. Why wold it eve need more than 64K of memory?

Sorry Dave, I couldn't resist. ;-)

bill

On 2024-01-09, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 1/9/2024 4:35 PM, John Dallman wrote:
>> In article <unkd47$25cg2$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
>> wrote:
>>> I suspect that all direct calls to LIB$ and SYS$ no matter if it is
>>> Macro-32 or Fortran or C would have to be manually edited to use
>>> new 64 bit capable version, but that the various language RTL
>>> could switch to 64 bit capable versions transparently.
>>
>> With a sufficiently regular naming scheme, a compiler could make
>> substitutions, but I don't know if the current scheme will cope.
>
> If the arguments are simple buffer addresses, then maybe the
> compiler could do something.
>
> But what with more complex data structures like item lists?
>
> A Fortran compiler could add a 64 to the function name called and
> could pass a 64 bit descriptor instead of a 32 bit descriptor for
> a string. But I can't imagine it changing all the addresses
> in an item list from INTEGER*4 to INTEGER*8.
>

It could if there was a SDL definition for the itemlist and if the SDL
definition contained information that the field was an address instead
of a longword.

As an alternative, and getting back to the core of the problem (Macro-32
does not have an address datatype so all addresses in HLLs were stored in
unabstracted longwords), if the user's source code defined that field as
an address pointer, instead of a uint32_t (for example), then the compiler
would have more information to work with when deciding whether to generate
32-bit or 64-bit addresses depending on the function name.

This is exactly what happened when badly-written C code was forced to
move from "unsigned long int ptr" to "struct some_struct_def *ptr" when
moving to the 64-bit world. The nice thing about that C code is that it
could be changed in a way that enabled it to continue working in both
a 32-bit and 64-bit environment.

Because of the mixed 32-bit/64-bit address space in VMS, this approach
would be more tricky than in Unix/Windows, but it could still be viable.

Simon.

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

On 2024-01-09, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Tue, 9 Jan 2024 14:32:48 -0500, Stephen Hoffman wrote:
>
>> And again, what you are interested here in has been available for many
>> years via Sector 7.
>
> I?m not sure they did a comprehensive enough job. For instance, I remember
> the previous time this came up, reading between the lines in one of their
> case studies, the original customer scenario mentioned using DECnet, but
> that was missiong from the description of the solution.

DECnet should not be in use in today's security world and a customer
should have been forced away from using DECnet anyway due to external
auditing and security standards.

I do remember what Sector 7 offers as being very complete (within the
limits of moving to another OS) and I don't see how reinventing the
wheel would be a viable commercial option, given what Sector 7 already has.

Simon.

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

On 2024-01-09, Dave Froble <davef@tsoft-inc.com> wrote:
>
> As far as I know, totally 64 bit apps can be implemented on VMS. So, what's the
> problem. The fact that there is also that 32 bit capability hanging around
> should not be a detriment, right?
>

Try using RMS in totally 64-bit mode. Unless there's been further
development since, not everything in RMS had a 64-bit address option.

Simon.

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

On 2024-01-09 6:47 p.m., Arne Vajhøj wrote:
> I don't have a problem with API's expecting 32 bit pointers being present.
>
> I have a problem with the situations where there is a function
> expecting 32 bit pointers but no function expecting 64 bit pointers.
> When one for whatever reason have a pointer to something
> up in P2 space. Allocating memory in P0 space, copy from
> P2 to P0, call function, copy back if necessary and
> deallocate it not elegant.

It looks like the compiler (and linker) will suitably warn, which is good.

--- snip mytest.c ---
/* experimenting with pointers */

#include <stdio.h>

# pragma __pointer_size __save
# pragma __pointer_size 64
char *my64bitpointer = (char *) 0x100000000;
# pragma __pointer_size 32
char *my32bitpointer = (char *) 0x10000000;
void my32bitfunction(char *ptr);
# pragma __pointer_size __restore

char *testdefault1, *testdefault2;

int main(int argc, char *argv[])
{ printf("my64bitpointer's address is %llp\n", my64bitpointer);
printf("my32bitpointer's address is %p\n", my32bitpointer);
testdefault1 = my64bitpointer;
testdefault2 = my32bitpointer;
my32bitfunction(my64bitpointer);
my32bitfunction(my32bitpointer);
}

# pragma __pointer_size __save
# pragma __pointer_size 32
void my32bitfunction(char *ptr)
{ printf("This is my function that requires a 32-bit parameter.\n");
} # pragma __pointer_size __restore

================================
$ cc mytest.c

# pragma __pointer_size __save
..........^
%CC-I-PRAGIGNORE, The pointer size control pointer_size pragma is not
active. Pragma is ignored.
at line number 5 in file DKA100:[test]mytest.c;2

char *my64bitpointer = (char *) 0x100000000;
........................^
%CC-I-INTCONSTTRUNC, In the initializer for my64bitpointer, conversion
of the constant "(char ...)0X0000000100000000" to pointer to char type
will cause data loss.
at line number 7 in file DKA100:[test]mytest.c;2
$ link mytest
$ run mytest
my64bitpointer's address is 0
my32bitpointer's address is 10000000
This is my function that requires a 32-bit parameter.
This is my function that requires a 32-bit parameter.

================================
$ cc /POINTER_SIZE=32 mytest.c

testdefault1 = my64bitpointer;
....................^
%CC-W-MAYLOSEDATA2, In this statement, "my64bitpointer" has a larger
data size than "short pointer to char".
Assignment can result in data loss.
at line number 19 in file DKA100:[test]mytest.c;2

my32bitfunction(my64bitpointer);
.....................^
%CC-W-MAYLOSEDATA2, In this statement, "my64bitpointer" has a larger
data size than "short pointer to char".
Assignment can result in data loss.
at line number 21 in file DKA100:[test]mytest.c;2
$ link mytest
%ILINK-W-COMPWARN, compilation warnings
module: MYTEST
file: DKA100:[test]mytest.OBJ;6
$ run mytest
my64bitpointer's address is 100000000
my32bitpointer's address is 10000000
This is my function that requires a 32-bit parameter.
This is my function that requires a 32-bit parameter.

================================
$ cc /POINTER_SIZE=64 mytest.c

my32bitfunction(my64bitpointer);
.....................^
%CC-W-MAYLOSEDATA2, In this statement, "my64bitpointer" has a larger
data size than "short pointer to char".
Assignment can result in data loss.
at line number 21 in file DKA100:[test]mytest.c;2
$ link mytest
%ILINK-W-COMPWARN, compilation warnings
module: MYTEST
file: DKA100:[test]mytest.OBJ;7
$ run mytest
my64bitpointer's address is 100000000
my32bitpointer's address is 10000000
This is my function that requires a 32-bit parameter.
This is my function that requires a 32-bit parameter.

On 2024-01-09 6:34 p.m., Dave Froble wrote:
>>
>> BASIC ... you got to be kidding, right?
>>
>> If kids wanted to learn programming these days, I would point them at
>> Python.
>>
>
> Bigot alert ....

Outside of UNIX, and beyond VMS, I think BASIC did have a pretty good
run in the 90's and early 2000's, particularly on the Windows desktop
platform.

Visual Basic (classic, producing native applications) was popular in the
90's, especially.

Eventually, .NET came along and they switched Visual Basic over to
producing managed applications, but C# quickly overtook BASIC in
popularity there.

Also, back when MS introduced their scripting host, vbscript was a very
popular language for that. Powershell's introduction is probably what
changed that landscape.

I think Visual Basic for Applications was also popular for macros and
automation within the MS Office suite back in the day. I don't really
know if it still is.

That's all I have to say about that.

On 1/10/2024 1:07 PM, mjos_examine wrote:
> Outside of UNIX, and beyond VMS, I think BASIC did have a pretty good
> run in the 90's and early 2000's, particularly on the Windows desktop
> platform.
>
> Visual Basic (classic, producing native applications) was popular in the
> 90's, especially.

Mid 90's and up to early 00's before business GUI's went all web,
then VB6 was king of business GUI's. VB6 was way more used than
Delphi, Jyacc etc..

> Eventually, .NET came along and they switched Visual Basic over to
> producing managed applications, but C# quickly overtook BASIC in
> popularity there.

C# was the language being pushed as the language to learn. VB.NET
was the language for those already knowing VB. 20 years forward
and VB.NET is niche due to natural change in developer population.

> Also, back when MS introduced their scripting host, vbscript was a very
> popular language for that. Powershell's introduction is probably what
> changed that landscape.

MS only shipped VBScript and JScript. VBS was by far the most popular.
But scripting host was a little bit more programming centric than shell.
Great for traversing file system or registry, but not good for typical
shell operations on files.

(and VBS was also used a lot in ASP Classic)

> I think Visual Basic for Applications was also popular for macros and
> automation within the MS Office suite back in the day.

Especially in Access the VBA often turned into significant
programming - more than macros/automation.

++++

Besides MS there were also other PC Basic flavors. Most notable:
Borland TurboBasic later PowerBasic.

And the open source world got FreeBASIC for Windows/Linux/FreeBSD.
Even though I have never tried it.

Arne

On 1/10/24 6:40 AM, Simon Clubley wrote:
> On 2024-01-09, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Tue, 9 Jan 2024 14:32:48 -0500, Stephen Hoffman wrote:
>>
>>> And again, what you are interested here in has been available for many
>>> years via Sector 7.
>>
>> I?m not sure they did a comprehensive enough job. For instance, I remember
>> the previous time this came up, reading between the lines in one of their
>> case studies, the original customer scenario mentioned using DECnet, but
>> that was missiong from the description of the solution.
>
> DECnet should not be in use in today's security world and a customer
> should have been forced away from using DECnet anyway due to external
> auditing and security standards.
>
..
..
..

Hogwash. DECnet can be made just as secure as any IP communication by
simply using IP transports. A couple of simple examples:

1. Run DECnet phase V. Use DECnet-over-IP, and encrypt it with IPSEC
before it ever leaves your host. This not only encrypts all of your
DECnet traffic but it means that DECnet proxies are now as secure as
your IPSEC profile.

1a. If you are running OpenVMS on x86, TCP/IP Services does not
currently provide IPSEC and Multinet is not yet available. However,
VMware ESXi does support IPSEC. You can configure your ESXi host to do
the encryption for you. You just need to do your DECnet-over-IP traffic
using IPv6.

2. Run DECnet phase IV. Install pyDECnet on any host in your LAN that
supports python (I use a dedicated raspberry pi). This will be your
DECnet router. Isolate DECnet traffic to its own VLAN. All off-LAN
DECnet traffic is encrypted by the pyDECnet host, again, likely using IPSEC.

More security that this is possible. If you have a security requirement
this doesn't meet, let me know.

Mark Berryman

On Wed, 10 Jan 2024 13:40:41 -0000 (UTC), Simon Clubley wrote:

> On 2024-01-09, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Tue, 9 Jan 2024 14:32:48 -0500, Stephen Hoffman wrote:
>>
>>> And again, what you are interested here in has been available for many
>>> years via Sector 7.
>>
>> I?m not sure they did a comprehensive enough job. For instance, I
>> remember the previous time this came up, reading between the lines in
>> one of their case studies, the original customer scenario mentioned
>> using DECnet, but that was missiong from the description of the
>> solution.
>
> DECnet should not be in use in today's security world and a customer
> should have been forced away from using DECnet anyway due to external
> auditing and security standards.

Surely that’s their choice. I thought the point was to make the transition
away from VMS as painless as possible. Others were trying to poke holes in
my claims of minimal pain; now you are trying to add to the pain instead.

Nowadays, the whole Internet is built on the concept of running secure
protocols over insecure channels. Those secure protocols can in turn be
channels for older, insecure protocols--this is not rocket science.

On Wed, 10 Jan 2024 13:07:04 -0500, mjos_examine wrote:

> ... I think BASIC did have a pretty good
> run in the 90's and early 2000's, particularly on the Windows desktop
> platform.

It had a role on 1980s micros, I’ll grant you that. The ability to switch
on and start typing code made for quite a productive environment: type a
statement with a line number to add it to your in-memory program, or
without to execute the line immediately.

Nowadays, Jupyter notebooks offer a more modern environment for such
incremental, even scratchpad-style programming. And Python is a more
modern language without the limitations of BASIC.

On 10/01/2024 20:17, Lawrence D'Oliveiro wrote:
> On Wed, 10 Jan 2024 13:07:04 -0500, mjos_examine wrote:
>
>> ... I think BASIC did have a pretty good
>> run in the 90's and early 2000's, particularly on the Windows desktop
>> platform.
>
> It had a role on 1980s micros, I’ll grant you that. The ability to switch
> on and start typing code made for quite a productive environment: type a
> statement with a line number to add it to your in-memory program, or
> without to execute the line immediately.
>
> Nowadays, Jupyter notebooks offer a more modern environment for such
> incremental, even scratchpad-style programming. And Python is a more
> modern language without the limitations of BASIC.

Have you ever used DEC/Compaq/HP basic?

It is unlike the early home computer Basic. In its day it was a modern
highly structured language - which was of course compiled.

I maintained and developed an ERP system consisting of well over a
million lines of code, which worked well to support our business

--
Chris

On 1/10/24 5:28 PM, Chris Townley wrote:
> On 10/01/2024 20:17, Lawrence D'Oliveiro wrote:
>> On Wed, 10 Jan 2024 13:07:04 -0500, mjos_examine wrote:
>>
>>> ... I think BASIC did have a pretty good
>>> run in the 90's and early 2000's, particularly on the Windows desktop
>>> platform.
>>
>> It had a role on 1980s micros, I’ll grant you that. The ability to switch
>> on and start typing code made for quite a productive environment: type a
>> statement with a line number to add it to your in-memory program, or
>> without to execute the line immediately.
>>
>> Nowadays, Jupyter notebooks offer a more modern environment for such
>> incremental, even scratchpad-style programming. And Python is a more
>> modern language without the limitations of BASIC.
>
> Have you ever used DEC/Compaq/HP basic?
>
> It is unlike the early home computer Basic. In its day it was a modern
> highly structured language - which was of course compiled.
>
> I maintained and developed an ERP system consisting of well over a
> million lines of code, which worked well to support our business
>

It also has some pretty nice features for convenient access to indexed
RMS files. Today one might not choose RMS as the "database" or DEC BASIC
as the language for a new project. But there is some pretty good old
stuff using them that works quite well. DEC BASIC is definitely not a
toy language.

On Wed, 10 Jan 2024 23:28:29 +0000, Chris Townley wrote:

> On 10/01/2024 20:17, Lawrence D'Oliveiro wrote:
>
>> On Wed, 10 Jan 2024 13:07:04 -0500, mjos_examine wrote:
>>
>>> ... I think BASIC did have a pretty good
>>> run in the 90's and early 2000's, particularly on the Windows desktop
>>> platform.
>>
>> It had a role on 1980s micros, I’ll grant you that. The ability to
>> switch on and start typing code made for quite a productive
>> environment: type a statement with a line number to add it to your
>> in-memory program, or without to execute the line immediately.
>>
>> Nowadays, Jupyter notebooks offer a more modern environment for such
>> incremental, even scratchpad-style programming. And Python is a more
>> modern language without the limitations of BASIC.
>
> Have you ever used DEC/Compaq/HP basic?

I think so, yes. It very much tried to emulate the interactive BASIC-PLUS
environment from RSTS/E, as I recall (right down to the “Ready” prompt).

> It is unlike the early home computer Basic. In its day it was a modern
> highly structured language - which was of course compiled.

There is one BASIC that I have heard about, but never used, which sounded
genuinely interesting, and that was GRASS (or ZGRASS, as the Z80 version
was called). It had multithreading and no line numbers. Function bodies
were held in string variables, and interpreted from there. And this was
from 1978.

There are some documents about it at Bitsavers.

> I maintained and developed an ERP system consisting of well over a
> million lines of code, which worked well to support our business

So you got it to work, back in the day. Nowadays, there are easier ways of
achieving the same thing. For one thing, you would have many existing
libraries to draw on, instead of having to write all that code yourself.

On 1/10/2024 6:54 PM, Lawrence D'Oliveiro wrote:
> On Wed, 10 Jan 2024 23:28:29 +0000, Chris Townley wrote:
>> On 10/01/2024 20:17, Lawrence D'Oliveiro wrote:
>>> On Wed, 10 Jan 2024 13:07:04 -0500, mjos_examine wrote:
>>>> ... I think BASIC did have a pretty good
>>>> run in the 90's and early 2000's, particularly on the Windows desktop
>>>> platform.
>>>
>>> It had a role on 1980s micros, I’ll grant you that. The ability to
>>> switch on and start typing code made for quite a productive
>>> environment: type a statement with a line number to add it to your
>>> in-memory program, or without to execute the line immediately.

>> Have you ever used DEC/Compaq/HP basic?
>
> I think so, yes. It very much tried to emulate the interactive BASIC-PLUS
> environment from RSTS/E, as I recall (right down to the “Ready” prompt).

VMS Basic is compiled just like Fortran, Cobol, Pascal and C.

Same is VB.NET.

And PowerBasic.

And FreeBASIC.

>> I maintained and developed an ERP system consisting of well over a
>> million lines of code, which worked well to support our business
>
> So you got it to work, back in the day. Nowadays, there are easier ways of
> achieving the same thing. For one thing, you would have many existing
> libraries to draw on, instead of having to write all that code yourself.

The world has evolved.

Arne

On 1/10/2024 6:28 PM, Chris Townley wrote:
> On 10/01/2024 20:17, Lawrence D'Oliveiro wrote:
>> On Wed, 10 Jan 2024 13:07:04 -0500, mjos_examine wrote:
>>
>>> ... I think BASIC did have a pretty good
>>> run in the 90's and early 2000's, particularly on the Windows desktop
>>> platform.
>>
>> It had a role on 1980s micros, I’ll grant you that. The ability to switch
>> on and start typing code made for quite a productive environment: type a
>> statement with a line number to add it to your in-memory program, or
>> without to execute the line immediately.
>>
>> Nowadays, Jupyter notebooks offer a more modern environment for such
>> incremental, even scratchpad-style programming. And Python is a more
>> modern language without the limitations of BASIC.
>
> Have you ever used DEC/Compaq/HP basic?
>
> It is unlike the early home computer Basic. In its day it was a modern
> highly structured language - which was of course compiled.

You could compile Microsoft BASIC on most of the micros of the 70's
and 80's. And then you had CBASIC on CP/M.

bill

On 1/10/2024 6:54 PM, Lawrence D'Oliveiro wrote:
> On Wed, 10 Jan 2024 23:28:29 +0000, Chris Townley wrote:
>
>> On 10/01/2024 20:17, Lawrence D'Oliveiro wrote:
>>
>>> On Wed, 10 Jan 2024 13:07:04 -0500, mjos_examine wrote:
>>>
>>>> ... I think BASIC did have a pretty good
>>>> run in the 90's and early 2000's, particularly on the Windows desktop
>>>> platform.
>>>
>>> It had a role on 1980s micros, I’ll grant you that. The ability to
>>> switch on and start typing code made for quite a productive
>>> environment: type a statement with a line number to add it to your
>>> in-memory program, or without to execute the line immediately.
>>>
>>> Nowadays, Jupyter notebooks offer a more modern environment for such
>>> incremental, even scratchpad-style programming. And Python is a more
>>> modern language without the limitations of BASIC.
>>
>> Have you ever used DEC/Compaq/HP basic?
>
> I think so, yes. It very much tried to emulate the interactive BASIC-PLUS
> environment from RSTS/E, as I recall (right down to the “Ready” prompt).
>
>> It is unlike the early home computer Basic. In its day it was a modern
>> highly structured language - which was of course compiled.
>
> There is one BASIC that I have heard about, but never used, which sounded
> genuinely interesting, and that was GRASS (or ZGRASS, as the Z80 version
> was called). It had multithreading and no line numbers. Function bodies
> were held in string variables, and interpreted from there. And this was
> from 1978.
>
> There are some documents about it at Bitsavers.

Well, as long as we're bringing up non-standard BASICs. How about
BASIC09.

>
>> I maintained and developed an ERP system consisting of well over a
>> million lines of code, which worked well to support our business
>
> So you got it to work, back in the day. Nowadays, there are easier ways of
> achieving the same thing. For one thing, you would have many existing
> libraries to draw on, instead of having to write all that code yourself.

There were many complex systems written in Microsoft BASIC on things
like the TRS-80. Word Processors, Spreadsheet Packages, Payroll. GL,
AP, AR. etc.

Nobody has ever said that you can't do stuff with BASIC. Only that
better languages came along.

bill

On 1/10/2024 7:02 PM, Arne Vajhøj wrote:
> On 1/10/2024 6:54 PM, Lawrence D'Oliveiro wrote:
>> On Wed, 10 Jan 2024 23:28:29 +0000, Chris Townley wrote:
>>> On 10/01/2024 20:17, Lawrence D'Oliveiro wrote:
>>>> On Wed, 10 Jan 2024 13:07:04 -0500, mjos_examine wrote:
>>>>> ... I think BASIC did have a pretty good
>>>>> run in the 90's and early 2000's, particularly on the Windows desktop
>>>>> platform.
>>>>
>>>> It had a role on 1980s micros, I’ll grant you that. The ability to
>>>> switch on and start typing code made for quite a productive
>>>> environment: type a statement with a line number to add it to your
>>>> in-memory program, or without to execute the line immediately.
>
>>> Have you ever used DEC/Compaq/HP basic?
>>
>> I think so, yes. It very much tried to emulate the interactive BASIC-PLUS
>> environment from RSTS/E, as I recall (right down to the “Ready” prompt).
>
> VMS Basic is compiled just like Fortran, Cobol, Pascal and C.
>
> Same is VB.NET.
>
> And PowerBasic.
>
> And FreeBASIC.

So is BASIC on RSTS/E. You can run it in the interpreter till you
are done debugging and then compile it.

>
>>> I maintained and developed an ERP system consisting of well over a
>>> million lines of code, which worked well to support our business
>>
>> So you got it to work, back in the day. Nowadays, there are easier
>> ways of
>> achieving the same thing. For one thing, you would have many existing
>> libraries to draw on, instead of having to write all that code yourself.
>
> The world has evolved.

Exactly. BASIC also evolved, but better languages have passed it by.

bill

On Wed, 10 Jan 2024 13:06:59 -0700, Mark Berryman wrote:

> 2. Run DECnet phase IV. Install pyDECnet on any host in your LAN that
> supports python (I use a dedicated raspberry pi).

Wow. I had no idea such a thing existed ... and written in Python, no
less. About 23,000 lines of code, for a pretty comprehensive DECnet Phase
IV stack.

On 1/10/2024 8:43 AM, Simon Clubley wrote:
> On 2024-01-09, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> As far as I know, totally 64 bit apps can be implemented on VMS. So, what's the
>> problem. The fact that there is also that 32 bit capability hanging around
>> should not be a detriment, right?
>>
>
> Try using RMS in totally 64-bit mode. Unless there's been further
> development since, not everything in RMS had a 64-bit address option.
>
> Simon.
>

My understanding, which could be totally wrong, is that the major concept of "64
bit" is about addresses.

So, even something using solely 64 bit addresses could still have multiple sizes
of data types. If using RMS, which I mainly do not, one would use the data
types that RMS requires. The concept would be for just about everything, use
what the tool/app/whatever requires.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Wed, 2024-01-10 at 21:28 -0500, bill wrote:
> > The world has evolved.
>
> Exactly.  BASIC also evolved, but better languages have passed it by..

Visual Basic can spawn and hande threads. Used it to great effect for
long running reports.
--
Tactical Nuclear Kittens

On Wed, 2024-01-10 at 23:28 +0000, Chris Townley wrote:
> > Nowadays, Jupyter notebooks offer a more modern environment for
> > such incremental, even scratchpad-style programming. And Python is
> > a more modern language without the limitations of BASIC.
>
> Have you ever used DEC/Compaq/HP basic?
>
> It is unlike the early home computer Basic. In its day it was a
> modern highly structured language - which was of course compiled.
>
> I maintained and developed an ERP system consisting of well over a
> million lines of code, which worked well to support our business

I have also used Visual Basic to maintain and add new features to a
garage forecourt application for dry stock and wet stock for the past
eleven years. Currently I've been made redundant and looking for a new
job.
--
Tactical Nuclear Kittens

On 2024-01-10, Mark Berryman <mark@theberrymans.com> wrote:
> On 1/10/24 6:40 AM, Simon Clubley wrote:
>> On 2024-01-09, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Tue, 9 Jan 2024 14:32:48 -0500, Stephen Hoffman wrote:
>>>
>>>> And again, what you are interested here in has been available for many
>>>> years via Sector 7.
>>>
>>> I?m not sure they did a comprehensive enough job. For instance, I remember
>>> the previous time this came up, reading between the lines in one of their
>>> case studies, the original customer scenario mentioned using DECnet, but
>>> that was missiong from the description of the solution.
>>
>> DECnet should not be in use in today's security world and a customer
>> should have been forced away from using DECnet anyway due to external
>> auditing and security standards.
>>
> .
> .
> .
>
> Hogwash. DECnet can be made just as secure as any IP communication by
> simply using IP transports. A couple of simple examples:
>
> 1. Run DECnet phase V. Use DECnet-over-IP, and encrypt it with IPSEC
> before it ever leaves your host. This not only encrypts all of your
> DECnet traffic but it means that DECnet proxies are now as secure as
> your IPSEC profile.
>
> 1a. If you are running OpenVMS on x86, TCP/IP Services does not
> currently provide IPSEC and Multinet is not yet available. However,
> VMware ESXi does support IPSEC. You can configure your ESXi host to do
> the encryption for you. You just need to do your DECnet-over-IP traffic
> using IPv6.
>
> 2. Run DECnet phase IV. Install pyDECnet on any host in your LAN that
> supports python (I use a dedicated raspberry pi). This will be your
> DECnet router. Isolate DECnet traffic to its own VLAN. All off-LAN
> DECnet traffic is encrypted by the pyDECnet host, again, likely using IPSEC.
>
> More security that this is possible. If you have a security requirement
> this doesn't meet, let me know.
>

I am amused and saddened that whenever I raise this issue, people immediately
assume that I am talking about MITM attacks only and address that only.

The fact is that MITM attacks are only a small part of the attack surface.
Far more common are attacks against the listening services themselves from
connections you initiate, not those you intercept.

For example, in 2) above, how does this address clients on an authorised
VLAN being able to send malformed packets to a server with an inappropriately
fully-privileged EVL listener that has a dodgy message parser built into it ?

TCP/IP (and its higher-level protocols) have been heavily probed and issues
are still being found. Goodness knows what a serious probing of DECnet will
reveal if I can find the following things with a quick probing:

https://groups.google.com/g/comp.os.vms/c/Bjp0hRkSnh4

I also find it amusing that whenever I raise this issue, there is nothing
in the DECnet world that protects data in motion and you all have to
suggest a protocol that came from the rival TCP/IP world instead. :-)

Simon.

PS: I wonder if, 2 years on, whether VSI has got around to fixing those
issues in DECnet Phase IV yet ?

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

On 2024-01-10, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
> Nowadays, the whole Internet is built on the concept of running secure
> protocols over insecure channels. Those secure protocols can in turn be
> channels for older, insecure protocols--this is not rocket science.

Things like SSL only protect data in motion. It does nothing to help
you if the server software on the receiving end of that SSL connection
has a vulnerability within it.

Simon.

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

On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
> On 1/10/2024 8:43 AM, Simon Clubley wrote:
>> On 2024-01-09, Dave Froble <davef@tsoft-inc.com> wrote:
>>>
>>> As far as I know, totally 64 bit apps can be implemented on VMS. So, what's the
>>> problem. The fact that there is also that 32 bit capability hanging around
>>> should not be a detriment, right?
>>>
>>
>> Try using RMS in totally 64-bit mode. Unless there's been further
>> development since, not everything in RMS had a 64-bit address option.
>>
>
> My understanding, which could be totally wrong, is that the major concept of "64
> bit" is about addresses.
>

And that is exactly what I am talking about. Not everything in RMS had
a 64-bit addressing API the last time I checked.

Simon.

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

On 1/11/2024 8:56 AM, Simon Clubley wrote:
> On 2024-01-11, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 1/10/2024 8:43 AM, Simon Clubley wrote:
>>> On 2024-01-09, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>
>>>> As far as I know, totally 64 bit apps can be implemented on VMS. So, what's the
>>>> problem. The fact that there is also that 32 bit capability hanging around
>>>> should not be a detriment, right?
>>>>
>>>
>>> Try using RMS in totally 64-bit mode. Unless there's been further
>>> development since, not everything in RMS had a 64-bit address option.
>>>
>>
>> My understanding, which could be totally wrong, is that the major concept of "64
>> bit" is about addresses.
>>
>
> And that is exactly what I am talking about. Not everything in RMS had
> a 64-bit addressing API the last time I checked.
>
> Simon.
>

Then I have to ask, "so what?"=

If RMS doesn't fit your requirements, then don't use it.

What does it matter how RMS works internally?

Perhaps I'm just the old dog that cannot learn new tricks?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486