• Fortran, no RAN ?

    From Michael Brown@21:1/5 to All on Mon Jun 17 02:22:53 2024
    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)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Michael Brown on Sun Jun 16 13:54:20 2024
    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)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to All on Sun Jun 16 14:20:10 2024
    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)
  • From Lawrence D'Oliveiro@21:1/5 to All on Mon Jun 17 00:34:39 2024
    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)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Lawrence D'Oliveiro on Sun Jun 16 21:29:20 2024
    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)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to All on Sun Jun 16 21:52:08 2024
    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)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to All on Sun Jun 16 21:42:09 2024
    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)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to All on Sun Jun 16 21:53:22 2024
    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)
  • From Michael Brown@21:1/5 to All on Mon Jun 17 14:09:51 2024
    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)
  • From Lawrence D'Oliveiro@21:1/5 to All on Mon Jun 17 04:40:13 2024
    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)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Michael Brown on Mon Jun 17 18:12:06 2024
    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)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to All on Mon Jun 17 19:46:40 2024
    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)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to All on Mon Jun 17 19:49:58 2024
    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)
  • From John Reagan@21:1/5 to Lawrence D'Oliveiro on Tue Jun 18 11:49:06 2024
    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)
  • From Stephen Hoffman@21:1/5 to John Reagan on Tue Jun 18 14:12:29 2024
    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)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to John Reagan on Tue Jun 18 18:51:28 2024
    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)
  • From Chris Townley@21:1/5 to Simon Clubley on Wed Jun 19 13:36:42 2024
    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)
  • From Simon Clubley@21:1/5 to Chris Townley on Wed Jun 19 13:14:48 2024
    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)
  • From Simon Clubley@21:1/5 to arne@vajhoej.dk on Wed Jun 19 12:15:35 2024
    On 2024-06-18, Arne Vajhj <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 Vajhj 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)
  • From Michael Brown@21:1/5 to All on Thu Jun 20 01:05:12 2024
    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)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Michael Brown on Wed Jun 19 13:55:45 2024
    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)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to All on Wed Jun 19 16:49:33 2024
    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)
  • From Michael Brown@21:1/5 to All on Thu Jun 20 14:29:42 2024
    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)
  • From abrsvc@21:1/5 to All on Thu Jun 20 11:54:54 2024
    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)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to abrsvc on Thu Jun 20 08:26:15 2024
    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)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Michael Brown on Thu Jun 20 08:23:44 2024
    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)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to All on Thu Jun 20 12:54:47 2024
    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)
  • From Michael Brown@21:1/5 to abrsvc on Fri Jun 21 17:06:46 2024
    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)