I've been building MTREK, written in fortran, on my community edition
and it compiles fine but complains of no RAN function at link time. It's
hard to believe they left out this intrinsic function, can anyone
clarify this or offer a solution ?
--
House Harris Software.
Making the world a safer place for our products. https://eisner.decus.org/~brown_mi

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/16/2024 12:22 PM, Michael Brown wrote:

I've been building MTREK, written in fortran, on my community edition
and it compiles fine but complains of no RAN function at link time. It's
hard to believe they left out this intrinsic function, can anyone
clarify this or offer a solution ?

VMS Fortran got both RAN and the standard RANDOM_NUMBER:

program randemo
implicit none
integer*4 seed, i
real*4 r1,r2
seed = 1234567
do 100 i = 1,5
r1 = ran(seed)
write(*,*) r1
call random_number(r2)
write(*,*) r2
100 continue
end

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/16/2024 1:54 PM, Arne Vajhøj wrote:

On 6/16/2024 12:22 PM, Michael Brown wrote:

I've been building MTREK, written in fortran, on my community edition
and it compiles fine but complains of no RAN function at link time.
It's hard to believe they left out this intrinsic function, can anyone
clarify this or offer a solution ?

VMS Fortran got both RAN and the standard RANDOM_NUMBER:

      program randemo
      implicit none
      integer*4 seed, i
      real*4 r1,r2
      seed = 1234567
      do 100 i = 1,5
        r1 = ran(seed)
        write(*,*) r1
        call random_number(r2)
        write(*,*) r2
100   continue
      end

With RTL as 3rd option:

program randemo
implicit none
integer*4 seed, i
real*4 r1,r2,r3
integer*4 pas$clock2
real*4 math$random_l_s
seed = pas$clock2() ! hack
do 100 i = 1,5
r1 = ran(seed)
call random_number(r2)
r3 = math$random_l_s(seed) ! mth$random return F float
write(*,*) r1,r2,r3
100 continue
end

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 16 Jun 2024 14:20:10 -0400, Arne Vajhøj wrote:

seed = pas$clock2() ! hack

Wot, no /dev/random? No EGD?

CALL EGD$RAND_BYTES_FILL(NRBYTES, BYTESARR)

NUM = EGD$RANDINT(LO, HI)

IF (EGD$UNIFORM() .GE. 0.5) THEN
... yes ...
ELSE
... no ...
END IF

etc etc

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/16/2024 8:34 PM, Lawrence D'Oliveiro wrote:

On Sun, 16 Jun 2024 14:20:10 -0400, Arne Vajhøj wrote:

seed = pas$clock2() ! hack

Wot, no /dev/random? No EGD?

To my best knowledge: no.

There are something equivalent in OpenSSL.

But even if they had been there, then they provide
cryptographic secure random data while RAN/RANDOM_NUMBER
are just plain PRNG.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/16/2024 9:42 PM, Arne Vajhøj wrote:

On 6/16/2024 9:29 PM, Arne Vajhøj wrote:

On 6/16/2024 8:34 PM, Lawrence D'Oliveiro wrote:

On Sun, 16 Jun 2024 14:20:10 -0400, Arne Vajhøj wrote:

       seed = pas$clock2() ! hack

Wot, no /dev/random? No EGD?

To my best knowledge: no.

There are something equivalent in OpenSSL.

And on VMS x86-64 there should be the new
SYS$GET_ENTROPY.

$ type entdemo.for
program entdemo
implicit none
integer*1 b(10)
integer*4 i
call RAND_bytes(%ref(b), %val(10))
write(*,*) (b(i),i=1,10)
call SYS$GET_ENTROPY(%ref(b), %val(10))
write(*,*) (b(i),i=1,10)
end
$ for/name=as_is entdemo
$ link entdemo + ssl111$lib:ssl111$libcrypto/lib

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/16/2024 9:29 PM, Arne Vajhøj wrote:

On 6/16/2024 8:34 PM, Lawrence D'Oliveiro wrote:

On Sun, 16 Jun 2024 14:20:10 -0400, Arne Vajhøj wrote:

       seed = pas$clock2() ! hack

Wot, no /dev/random? No EGD?

To my best knowledge: no.

There are something equivalent in OpenSSL.

And on VMS x86-64 there should be the new
SYS$GET_ENTROPY.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/16/2024 9:29 PM, Arne Vajhøj wrote:

On 6/16/2024 8:34 PM, Lawrence D'Oliveiro wrote:

On Sun, 16 Jun 2024 14:20:10 -0400, Arne Vajhøj wrote:

       seed = pas$clock2() ! hack

Wot, no /dev/random? No EGD?

To my best knowledge: no.

There are something equivalent in OpenSSL.

Which I believe end up calling Richard Levitte's code
on VMS.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17/6/24 03:54, Arne Vajhøj wrote:

On 6/16/2024 12:22 PM, Michael Brown wrote:

I've been building MTREK, written in fortran, on my community edition
and it compiles fine but complains of no RAN function at link time.

VMS Fortran got both RAN and the standard RANDOM_NUMBER:

That example was very reassuring when it compiled and ran, so I looked
more carefully at my compiler warnings compiling MTREK...


RNDOM = RAN(I1, I2)
..................^
%F90-W-WARNING, The number of arguments is incompatible with intrinsic procedure, assume 'external'. [RAN]
at line number 67 in file SYS$SYSDEVICE:[MBROWN.DEVS.MTREK]mtrekini.for;4

and it is telling me the problem, assumed external because of too many parameters, then it tries to link some external name RAN which isn't
there. I can understand this.

But the question now is why RAN(I1, I2) works on the VAX compiler,and
not on the X86_64 compiler. And what is it doing with those 2 parameters
on the VAX so I can simulate it somehow.


--
House Harris Software.
Making the world a safer place for our products. https://eisner.decus.org/~brown_mi

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 16 Jun 2024 21:42:09 -0400, Arne Vajhøj wrote:

And on VMS x86-64 there should be the new SYS$GET_ENTROPY.

That sounds like the right sort of thing.

Just remember to get the randomness from lots of different sources.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/17/2024 12:09 AM, Michael Brown wrote:

On 17/6/24 03:54, Arne Vajhøj wrote:

On 6/16/2024 12:22 PM, Michael Brown wrote:

I've been building MTREK, written in fortran, on my community edition
and it compiles fine but complains of no RAN function at link time.

VMS Fortran got both RAN and the standard RANDOM_NUMBER:

That example was very reassuring when it compiled and ran, so I looked
more carefully at my compiler warnings compiling MTREK...

          RNDOM = RAN(I1, I2)
..................^
%F90-W-WARNING, The number of arguments is incompatible with intrinsic procedure, assume 'external'.   [RAN]
at line number 67 in file SYS$SYSDEVICE:[MBROWN.DEVS.MTREK]mtrekini.for;4

and it is telling me the problem, assumed external because of too many parameters, then it tries to link some external name RAN which isn't
there. I can understand this.

But the question now is why RAN(I1, I2) works on the VAX compiler,and
not on the X86_64 compiler. And what is it doing with those 2 parameters
on the VAX so I can simulate it somehow.

Are you sure that it is intrinsic and not something picked
up from some library?

What type is RNDOM? Default REAL*4? Or Integer*4?

If INTEGER*4 then my guess would be that:

RAN(I1, I2)

is:

RAN_INT_IN_INTERVAL(LOW_BOUND, HIGH_BOUND)

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/17/2024 6:12 PM, Arne Vajhøj wrote:

On 6/17/2024 12:09 AM, Michael Brown wrote:

But the question now is why RAN(I1, I2) works on the VAX compiler,and
not on the X86_64 compiler. And what is it doing with those 2
parameters on the VAX so I can simulate it somehow.

Are you sure that it is intrinsic and not something picked
up from some library?

What type is RNDOM? Default REAL*4? Or Integer*4?

If INTEGER*4 then my guess would be that:

RAN(I1, I2)

is:

RAN_INT_IN_INTERVAL(LOW_BOUND, HIGH_BOUND)

Example:

$ typ ranfun2.for
program ranfun2
implicit none
integer*4 i, ix, rcount(10)
data rcount/10*0/
integer*4 ran2arg
external ran2arg
do 100 i = 1, 1000000
ix = ran2arg(1, 10)
rcount(ix) = rcount(ix) + 1
100 continue
write(*,*) (rcount(ix),ix=1,10)
end
c
integer*4 function ran2arg(low, high)
implicit none
integer*4 low, high
integer*4 seed
save seed
real*4 temp
temp = ran(seed)
ran2arg = low + int((high - low + 1) * temp)
return
end
$ typ ranfun3.for
program ranfun3
implicit none
integer*4 i, ix, rcount(10)
data rcount/10*0/
integer*4 ran2arg
external ran2arg
do 100 i = 1, 1000000
ix = ran2arg(1, 11)
rcount(ix) = rcount(ix) + 1
100 continue
write(*,*) (rcount(ix),ix=1,10)
end
c
integer*4 function ran2arg(low, high)
implicit none
integer*4 low, high
integer*4 seed
save seed
real*4 temp
temp = ran(seed)
ran2arg = low + int((high - low) * temp)
return
end

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/17/2024 6:12 PM, Arne Vajhøj wrote:

On 6/17/2024 12:09 AM, Michael Brown wrote:

But the question now is why RAN(I1, I2) works on the VAX compiler,and
not on the X86_64 compiler. And what is it doing with those 2
parameters on the VAX so I can simulate it somehow.

Are you sure that it is intrinsic and not something picked
up from some library?

What type is RNDOM? Default REAL*4? Or Integer*4?

If INTEGER*4 then my guess would be that:

RAN(I1, I2)

is:

RAN_INT_IN_INTERVAL(LOW_BOUND, HIGH_BOUND)

But if RNDOM is REAL*4 then my guess would be:

RAN_LONGER_CYCLE(SEED1, SEED2)

Example:

real*4 function ran2arg(seed1, seed2)
implicit none
integer*4 seed1, seed2
integer*4 temp
real*4 dummy
temp = xor(seed1, seed2)
ran2arg = ran(temp)
seed1 = xor(ishc(seed1, 1), temp)
seed2 = xor(ishc(seed2, -1), temp)
end

Disclaimer: I do not know if the cycle from this one is actual longer.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/17/2024 12:40 AM, Lawrence D'Oliveiro wrote:

On Sun, 16 Jun 2024 21:42:09 -0400, Arne Vajhøj wrote:

And on VMS x86-64 there should be the new SYS$GET_ENTROPY.

That sounds like the right sort of thing.

Just remember to get the randomness from lots of different sources.

I've seen the list. It is very long and, er, random.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-06-18 15:49:06 +0000, John Reagan said:

I've seen the list. It is very long and, er, random.

Good.


Might want to officially publish the list, too.


Some past RNG / PRNG / CPRNG shenanigans: https://en.wikipedia.org/wiki/Random_number_generator_attack https://en.wikipedia.org/wiki/RDRAND


For one of the indirectly-related cryptography-related cases, and
particularly a case that fails hard with any re-use: https://frereit.de/aes_gcm/


And a case of interpolating information: https://en.wikipedia.org/wiki/German_tank_problem


For the DEC Fortran RAN extension, check that the compile command is
allowing access to that not-a-pure-function function: https://docs.vmssoftware.com/test-docs/vsi-fortran-for-openvms-language-reference-manual.pdf



--
Pure Personal Opinion | HoffmanLabs LLC

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/18/2024 11:49 AM, John Reagan wrote:

On 6/17/2024 12:40 AM, Lawrence D'Oliveiro wrote:

On Sun, 16 Jun 2024 21:42:09 -0400, Arne Vajhøj wrote:

And on VMS x86-64 there should be the new SYS$GET_ENTROPY.

That sounds like the right sort of thing.

Just remember to get the randomness from lots of different sources.

I've seen the list.  It is very long and, er, random.

Those that want to know what it uses on their VMS x86-64
system should get some hints from:

$ show entropy

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/06/2024 13:15, Simon Clubley wrote:

On 2024-06-18, Arne Vajhøj <arne@vajhoej.dk> wrote:

On 6/18/2024 11:49 AM, John Reagan wrote:

On 6/17/2024 12:40 AM, Lawrence D'Oliveiro wrote:

On Sun, 16 Jun 2024 21:42:09 -0400, Arne Vajhøj wrote:

And on VMS x86-64 there should be the new SYS$GET_ENTROPY.

That sounds like the right sort of thing.

Just remember to get the randomness from lots of different sources.

I've seen the list.  It is very long and, er, random.

Those that want to know what it uses on their VMS x86-64
system should get some hints from:

$ show entropy

And to think that when I was saying several years ago VMS needed this,
people here were making fun of me and trying to claim somehow that VMS
didn't need this in order to be "the world's most secure operating
system"... :-)

I notice BTW that the VSI website _still_ does not have a security
reporting mechanism on its contact page, even after the recent comments
from VSI about security now being a primary focus.

Simon.

https://vmssoftware.com/security/

--
Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-06-19, Chris Townley <news@cct-net.co.uk> wrote:

On 19/06/2024 13:15, Simon Clubley wrote:

I notice BTW that the VSI website _still_ does not have a security
reporting mechanism on its contact page, even after the recent comments
from VSI about security now being a primary focus.

https://vmssoftware.com/security/

Thanks Chris - I was not aware of that and now I look closer I see why.

It's a tiny little link in the footer on the Contact page instead of
being in the main body of the page like everyone else's security
reporting mechanisms. I completely missed it even though I checked the
Contact page before posting.

Feedback sent to VSI about the need to move it into the main body of the Contact page.

Thanks,

Simon.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-06-18, Arne Vajhøj <arne@vajhoej.dk> wrote:

On 6/18/2024 11:49 AM, John Reagan wrote:

On 6/17/2024 12:40 AM, Lawrence D'Oliveiro wrote:

On Sun, 16 Jun 2024 21:42:09 -0400, Arne Vajhøj wrote:

And on VMS x86-64 there should be the new SYS$GET_ENTROPY.

That sounds like the right sort of thing.

Just remember to get the randomness from lots of different sources.

I've seen the list.  It is very long and, er, random.

Those that want to know what it uses on their VMS x86-64
system should get some hints from:

$ show entropy

And to think that when I was saying several years ago VMS needed this,
people here were making fun of me and trying to claim somehow that VMS
didn't need this in order to be "the world's most secure operating
system"... :-)

I notice BTW that the VSI website _still_ does not have a security
reporting mechanism on its contact page, even after the recent comments
from VSI about security now being a primary focus.

Simon.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18/6/24 09:46, Arne Vajhøj wrote:

On 6/17/2024 6:12 PM, Arne Vajhøj wrote:

On 6/17/2024 12:09 AM, Michael Brown wrote:

But the question now is why RAN(I1, I2) works on the VAX compiler,and
not on the X86_64 compiler. And what is it doing with those 2
parameters on the VAX so I can simulate it somehow.

Are you sure that it is intrinsic and not something picked
up from some library?

What type is RNDOM? Default REAL*4? Or Integer*4?

If INTEGER*4 then my guess would be that:

RAN(I1, I2)

is:

RAN_INT_IN_INTERVAL(LOW_BOUND, HIGH_BOUND)

Example:

$ typ ranfun2.for

<insert code here......>

      end

Arne

That was extremely useful code, I think RNDOM is integer, certainly the ran2arg function compiled into it without complaint, and there is no RAN funcion defined in any or the code. I don't know why the RAN with 2 args
works n the VAX.

Alas as far as porting mtrek is concerned that just led to another
problem. seems the the call ERRSET doesn't seem to work(undefined
symbol at link time) under the X86 fortran.

But I think I am very close.



--
House Harris Software.
Making the world a safer place for our products. https://eisner.decus.org/~brown_mi

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/19/2024 11:05 AM, Michael Brown wrote:

Alas as far as porting mtrek is concerned that just led to another
problem. seems the  the call ERRSET doesn't seem to work(undefined
symbol at link time) under the X86 fortran.

But I think I am very close.

ERRSET is not in any recent VMS Fortran manual either.

Google find something for IBM:

https://www.ibm.com/docs/en/essl/6.2?topic=subroutines-errset-essl-errset-subroutine

It should be easy to replace with something just writing out the info.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/17/2024 7:49 PM, Arne Vajhøj wrote:

But if RNDOM is REAL*4 then my guess would be:

RAN_LONGER_CYCLE(SEED1, SEED2)

Example:

      real*4 function ran2arg(seed1, seed2)
      implicit none
      integer*4 seed1, seed2
      integer*4 temp
      real*4 dummy
      temp = xor(seed1, seed2)
      ran2arg = ran(temp)
      seed1 = xor(ishc(seed1, 1), temp)
      seed2 = xor(ishc(seed2, -1), temp)
      end

Disclaimer: I do not know if the cycle from this one is actual longer.

I did an experiment with start seeds 1234567 and 7654321.

I aborted after burning a little over 2 CPU hours.

No cycle detected after 1281 billion calls.

That doesn't prove that cycle will always be longer.

But it does not provide any basis for pessimism either.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20/6/24 03:55, Arne Vajhøj wrote:

On 6/19/2024 11:05 AM, Michael Brown wrote:

Alas as far as porting mtrek is concerned that just led to another
problem. seems the  the call ERRSET doesn't seem to work(undefined
symbol at link time) under the X86 fortran.

But I think I am very close.

ERRSET is not in any recent VMS Fortran manual either.

Google find something for IBM:

https://www.ibm.com/docs/en/essl/6.2?topic=subroutines-errset-essl-errset-subroutine

It should be easy to replace with something just writing out the info.

Yes ERRSET was not standard in the VAX fortran so it seems. For the
purpose of testing I just commented the 2 references to ERRSET out and
hope those errors don't occur.

So MTREK compiles without complaint now, there maybe a problem with the
shared memory block. Shared memory on openvms is new to me, looks very
elegant though. Definitely not working for me yet.

--
House Harris Software.
Making the world a safer place for our products. https://eisner.decus.org/~brown_mi

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

ERRSET is documented in the DEC FORTRAN User's manual. I have the Jan
1993 version for DEC FORTRAN V6.0.
It looks like this is a subroutine for compatibility with PDP-11 FORTRAN systems:

"The ERRSET subprogram determines the action taken in response to an
error detected by the Run-Time Library. The VMS condition handling
facility provides a more general method of defining actions to be taken
when errors are detected (see Chapter 9). ..."

Under notes:

:an external reference to the ERRSET subprograms causes a special PDP-11 FORTRAN compatibility error handler to be established before the main
program is called. This special error handler transforms the executing environment to approximate that of PDP-11 FORTRAN."

Dan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/20/2024 7:54 AM, abrsvc wrote:

ERRSET is documented in the DEC FORTRAN User's manual.  I have the Jan
1993 version for DEC FORTRAN V6.0.
It looks like this is a subroutine for compatibility with PDP-11 FORTRAN systems:

"The ERRSET subprogram determines the action taken in response to an
error detected by the Run-Time Library.  The VMS condition handling
facility provides a more general method of defining actions to be taken
when errors are detected (see Chapter 9).  ..."

Under notes:

:an external reference to the ERRSET subprograms causes a special PDP-11 FORTRAN compatibility error handler to be established before the main
program is called.  This special error handler transforms the executing environment to approximate that of PDP-11 FORTRAN."

It was not in the latest RM but it was in the latest UM.

Under "B.3.2. Compaq Fortran 77 for OpenVMS VAX Systems
Language Features Not Implemented".

:-)

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/20/2024 12:29 AM, Michael Brown wrote:

So MTREK compiles without complaint now, there maybe a problem with the shared memory block. Shared memory on openvms is new to me, looks very elegant though. Definitely not working for me yet.

That stuff has not really changed.

The only thing that I can imagine causing problems is that
the memory needed to be 512 bytes aligned on VAX but 8192 bytes
aligned on newer platforms.

Linking with option:

PSECT_ATTRIBUTE=name_of_your_sect,13

should handle that.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/20/2024 8:23 AM, Arne Vajhøj wrote:

On 6/20/2024 12:29 AM, Michael Brown wrote:

So MTREK compiles without complaint now, there maybe a problem with
the shared memory block. Shared memory on openvms is new to me, looks
very elegant though. Definitely not working for me yet.

That stuff has not really changed.

The only thing that I can imagine causing problems is that
the memory needed to be 512 bytes aligned on VAX but 8192 bytes
aligned on newer platforms.

Linking with option:

PSECT_ATTRIBUTE=name_of_your_sect,13

should handle that.

Add:

SYS$CRMPSC pagcnt argument is is 512 bytes pagelets also
on newer platforms. But it get rounded up to multipla
of 8 KB pages.

So sharedblocksizeinbytes / 512 is fine, but it may avoid
unexpected side effects if sharedblocksizeinbytes is a multipla
of 8 KB.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20/6/24 21:54, abrsvc wrote:

ERRSET is documented in the DEC FORTRAN User's manual.  I have the Jan
1993 version for DEC FORTRAN V6.0.
It looks like this is a subroutine for compatibility with PDP-11 FORTRAN systems:

Under notes:

:an external reference to the ERRSET subprograms causes a special PDP-11 FORTRAN compatibility error handler to be established before the main
program is called.  This special error handler transforms the executing environment to approximate that of PDP-11 FORTRAN."

That certainly does explain it, and why it's not in X86. I just
commented out the ERRSET lines as a quick fix.

--
House Harris Software.
Making the world a safer place for our products. https://eisner.decus.org/~brown_mi

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)