Fortran, no RAN ?

[Michael Brown]

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 ?

[Arne Vajhøj]

Post by Michael Brown
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

[Arne Vajhøj]

Post by Michael Brown
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 ?

      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

[Lawrence D'Oliveiro]

Post by Arne Vajhøj
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

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
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

[Arne Vajhøj]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

       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

[Arne Vajhøj]

Post by Arne Vajhøj

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

       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

[Lawrence D'Oliveiro]

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.

[John Reagan]

Post by Lawrence D'Oliveiro

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.

[Stephen Hoffman]

Post by John Reagan
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

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

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

[Simon Clubley]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

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
$ 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.

[Chris Townley]

Post by Simon Clubley

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

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
$ 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/

[Simon Clubley]

Post by Chris Townley

Post by Simon Clubley
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.

[Arne Vajhøj]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

       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

[Michael Brown]

Post by Michael Brown
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.

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.

[Arne Vajhøj]

Post by Michael Brown

Post by Michael Brown
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.

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

[Arne Vajhøj]

Post by Arne Vajhøj

Post by Michael Brown
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?
RAN(I1, I2)
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

[Michael Brown]

Post by Arne Vajhøj

Post by Arne Vajhøj

Post by Michael Brown
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?
RAN(I1, I2)
RAN_INT_IN_INTERVAL(LOW_BOUND, HIGH_BOUND)

$ typ ranfun2.for

<insert code here......>

Post by Arne Vajhøj
      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.

[Arne Vajhøj]

Post by Michael Brown
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

[Michael Brown]

Post by Arne Vajhøj

Post by Michael Brown
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.
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.

[abrsvc]

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

[Arne Vajhøj]

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
"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).  ..."
: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

[Michael Brown]

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
: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.

[Arne Vajhøj]

Post by Michael Brown
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

[Arne Vajhøj]

Post by Arne Vajhøj

Post by Michael Brown
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.
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

[Arne Vajhøj]

Post by Arne Vajhøj

Post by Michael Brown
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?
RAN(I1, I2)
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

[Arne Vajhøj]

Post by Arne Vajhøj
RAN_LONGER_CYCLE(SEED1, SEED2)
      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