• Technical issues with VMS BASIC port to x86-64 ?

    From Simon Clubley@21:1/5 to All on Tue Feb 20 18:27:52 2024
    This is NOT a moan about how long it is taking for BASIC to appear,
    and I would request people not turn it into one, at least in this
    thread.

    I am curious, at a purely technical level, about the issues that VSI
    have encountered with porting BASIC to x86-64 VMS and what the issues
    are, at a technical level, that is making the port of BASIC apparently
    much more complex than the other traditional VMS languages.

    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 Craig A. Berry@21:1/5 to Simon Clubley on Tue Feb 20 13:24:09 2024
    On 2/20/24 12:27 PM, Simon Clubley wrote:
    This is NOT a moan about how long it is taking for BASIC to appear,
    and I would request people not turn it into one, at least in this
    thread.

    I am curious, at a purely technical level, about the issues that VSI
    have encountered with porting BASIC to x86-64 VMS and what the issues
    are, at a technical level, that is making the port of BASIC apparently
    much more complex than the other traditional VMS languages.

    I'm pretty sure this has already been explained multiple times. What I
    think I remember is that exception handling and dynamic maps pose some challenges, and there may be RTL dependencies that are somewhat
    different from the other compilers. But I don't think COBOL was easy
    either -- it just has a lot more users and was thus a higher priority.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Simon Clubley on Tue Feb 20 15:41:34 2024
    On 2/20/2024 1:27 PM, Simon Clubley wrote:
    I am curious, at a purely technical level, about the issues that VSI
    have encountered with porting BASIC to x86-64 VMS and what the issues
    are, at a technical level, that is making the port of BASIC apparently
    much more complex than the other traditional VMS languages.

    Most of what has been revealed over the last couple of years relate
    to map/common/psect handling and G2L.

    But I am no longer convinced that Basic is so much late, because
    it is so "much more complex".

    I suspect Basic is mostly so much late, because it was the last to
    do and that there has been found a large number of bugs found in
    the compilers released earlier that has taken most of the available
    compiler resource hours. I simply suspect that Basic has been delayed
    because John and the rest of the team has been busy fixing bugs in
    the C, C++, Fortran and Pascal compilers.

    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 Tue Feb 20 15:33:15 2024
    On 2/20/2024 2:36 PM, mjos_examine wrote:
    On 2024-02-20 2:24 p.m., Craig A. Berry wrote:
    On 2/20/24 12:27 PM, Simon Clubley wrote:
    I am curious, at a purely technical level, about the issues that VSI

    I'm pretty sure this has already been explained multiple times.  What I
    think I remember is that exception handling and dynamic maps pose some
    challenges, and there may be RTL dependencies that are somewhat
    different from the other compilers.  But I don't think COBOL was easy
    either -- it just has a lot more users and was thus a higher priority.

    There has been some information posted over the past 11 months.

    On 2023-03-01 2:13 p.m., John Reagan wrote in Message ID <2f1b5bc7-ee3c-4e9b-8be6-601bef09e868n@googlegroups.com>:
    Don't blow the BASIC issue out of proportion.  It is just that the
    BASIC frontend
    generates GEM symbol table that look "different" than everybody else.  I >>> just haven't had the time (or desire) to change how G2L has to
    operate.  I'd
    rather change the BASIC frontend.  I have other things to do first.
    It is not
    a multiple person-year task.  We have all the real HARD pieces of
    BASIC already
    working.

    On 2023-09-07 9:56 p.m., John Reagan wrote in Message Id <311392ca-9f5d-41e0-b15c-b383d5a682b5n@googlegroups.com>:
    We have resolved one of the difficult issues with BASIC MAP statements
    and can actually pass a significant number of tests.  However, we
    still have
    a few more things to track down before I would say it is useful.

    There are other similar.

    Apr 8, 2022, 9:16:12 AM

    <quote>
    - BASIC is still waiting on an enhancement to our G2L converter. BASIC's
    MAP statement uses
    COMMON blocks in a "unique" way that the converter was not prepared for.
    And the way OpenVMS
    implements common blocks is different than the presentation you see on UNIX/Linux systems.
    (I can really bore you on overlaid PSECTs on OpenVMS vs .comm directives
    in UNIX)
    </quote>

    Jan 25, 2023, 5:16:05 PM

    <quote>
    As I've said before, the issue is COMMON blocks. When I first did the
    design of
    how to convert GEM CIL and GEM symbol table to LLVM, I didn't appreciate the difference in how COMMON blocks are described to LLVM and the UNIX
    environment
    in general. It isn't just BASIC, you can see broken COMMON blocks in the Fortran
    cross-compiler if you look hard enough. The problem is that the BASIC
    MAP statement
    doesn't work right and almost every BASIC program uses MAPs for
    something. I have
    a BASIC cross-compiler. If you don't use a MAP, it probably works
    (although the test
    system doesn't very far without MAP).
    </quote>

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to All on Tue Feb 20 22:28:24 2024
    On Tue, 20 Feb 2024 15:33:15 -0500, Arne Vajhøj wrote:

    (I can really bore you on overlaid PSECTs on OpenVMS vs .comm directives
    in UNIX)

    Is it a namespace issue? Because .comm names live in the same namespace as global symbol names?

    <<https://sourceware.org/binutils/docs-2.42/as/Comm.html>>

    --- 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 Tue Feb 20 18:44:10 2024
    On 2/20/2024 5:28 PM, Lawrence D'Oliveiro wrote:
    On Tue, 20 Feb 2024 15:33:15 -0500, Arne Vajhøj wrote:

    (technically Id did not write that - I quoted John)

    (I can really bore you on overlaid PSECTs on OpenVMS vs .comm directives
    in UNIX)

    Is it a namespace issue? Because .comm names live in the same namespace as global symbol names?

    There are probably multiple differences.

    And a lot of code triggering the problems are probably rather bad code.
    But the expectation for VMS x86-64 is 99.9999% compatibility not 99% compatibility.

    If I remember correctly then the example given in one of these threads
    were a Fortran common block where some part of the data was initialized
    in some code and other part of the data was initialized in other code.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Dorsey@21:1/5 to ultr...@gmail.com on Tue Feb 20 23:21:08 2024
    ultr...@gmail.com <ultradwc@gmail.com> wrote:

    hey simon is comp.os.vms done for or is their another chat site for vms?

    I don't see any reason for anyone to move.

    are they ever going to stop the spam?=20

    Google will FINALLY get their server disconnected in three more days and
    there will be cheering and champagne will be opened and the spam will all disappear! Thank God we have got rid of Google and good riddance to bad rubbish. This newsgroup will be MUCH easier to read without all the Google droppings.
    --scott
    --
    "C'est un Nagra. C'est suisse, et tres, tres precis."

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to All on Wed Feb 21 00:51:05 2024
    On Tue, 20 Feb 2024 18:44:10 -0500, Arne Vajhøj wrote:

    If I remember correctly then the example given in one of these threads
    were a Fortran common block where some part of the data was initialized
    in some code and other part of the data was initialized in other code.

    COMMON blocks don’t allow for initializers.

    --- 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 Tue Feb 20 21:09:51 2024
    On 2/20/2024 7:51 PM, Lawrence D'Oliveiro wrote:
    On Tue, 20 Feb 2024 18:44:10 -0500, Arne Vajhøj wrote:
    If I remember correctly then the example given in one of these threads
    were a Fortran common block where some part of the data was initialized
    in some code and other part of the data was initialized in other code.

    COMMON blocks don’t allow for initializers.

    Data can not be initialized in COMMON, but data in COMMON can be
    initialized.

    I believe the example was somewhat similar to:

    program bad
    integer*4 a(2)
    common /m/a
    call s1
    call s2
    write(*,*) a(1),a(2)
    end
    c
    subroutine s1
    integer*4 a(2)
    common /m/a
    data a(1)/123/
    end
    c
    subroutine s2
    integer*4 a(2)
    common /m/a
    data a(2)/456/
    end

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dave Froble@21:1/5 to All on Tue Feb 20 20:46:35 2024
    On 2/20/2024 6:44 PM, Arne Vajhøj wrote:
    On 2/20/2024 5:28 PM, Lawrence D'Oliveiro wrote:
    On Tue, 20 Feb 2024 15:33:15 -0500, Arne Vajhøj wrote:

    (technically Id did not write that - I quoted John)

    (I can really bore you on overlaid PSECTs on OpenVMS vs .comm directives >>> in UNIX)

    Is it a namespace issue? Because .comm names live in the same namespace as >> global symbol names?

    There are probably multiple differences.

    And a lot of code triggering the problems are probably rather bad code.
    But the expectation for VMS x86-64 is 99.9999% compatibility not 99% compatibility.

    If I remember correctly then the example given in one of these threads
    were a Fortran common block where some part of the data was initialized
    in some code and other part of the data was initialized in other code.

    Arne



    Back in Basic+ there was/is the FIELD operator. It was/is used to dynamically assign label(s) to locations in an I/O buffer. For example,

    FIELD #1%, 2 as Z1$, 8 as Z2$, 20 as Z3$

    The variables then had their descriptors modified to have addresses in the I/O buffer associated with channel #1. After all, what good is I/O unless one can access the data?

    The VAX Basic people really didn't like the operator and the concept. They wanted to have RMS in move mode move a record into a MAP that was NOT accessing the I/O buffer.

    Didn't sit too well with those coming from RSTS. Their (VAX BASIC) response was
    the dynamic map capabilities. What they did to achieve this, I don't know. Maybe that is where the weirdness comes from.

    We didn't use their dynamic MAP capabilities. We were rather happy with working
    in the I/O buffer, and developed software to re-purpose string variables as labels in an I/O buffer. Seemed reasonable to us. Image rundown got rather upset if the string descriptors were not returned to their initial state.

    :-)

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to All on Wed Feb 21 03:27:04 2024
    On Tue, 20 Feb 2024 21:09:51 -0500, Arne Vajhøj wrote:

    I believe the example was somewhat similar to:

    program bad
    integer*4 a(2)
    common /m/a
    call s1
    call s2
    write(*,*) a(1),a(2)
    end
    c
    subroutine s1
    integer*4 a(2)
    common /m/a
    data a(1)/123/
    end
    c
    subroutine s2
    integer*4 a(2)
    common /m/a
    data a(2)/456/
    end

    Looking at the Fortran 2018 spec, section 8.4, it says “A variable, or
    part of a variable, shall not be explicitly initialized more
    than once in a program”.

    Also section 8.6.7 says “A variable whose designator appears as a data- stmt-object or a data-i-do-object shall not be a dummy argument, accessed
    by use or host association, in a named common block unless the DATA
    statement is in a block data program unit, in blank common, a function
    name, a function result name, an automatic data object, or an allocatable variable”.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Clubley@21:1/5 to m6502x64@gmail.com on Wed Feb 21 13:21:06 2024
    On 2024-02-20, mjos_examine <m6502x64@gmail.com> wrote:

    On a non-serious note, Simon all but guaranteed that it wouldn't appear
    in January, by predicting, several months ago, that it would.
    ;-)


    $ set response/mode=good_natured

    I hope you are not suggesting VSI delayed it so that my public prediction
    would be incorrect. :-) :-)

    However, in that good natured spirit, my next prediction is that VSI will
    not release BASIC until at least July 2024. :-)

    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 Craig A. Berry on Wed Feb 21 13:16:18 2024
    On 2024-02-20, Craig A. Berry <craigberry@nospam.mac.com> wrote:

    On 2/20/24 12:27 PM, Simon Clubley wrote:
    This is NOT a moan about how long it is taking for BASIC to appear,
    and I would request people not turn it into one, at least in this
    thread.

    I am curious, at a purely technical level, about the issues that VSI
    have encountered with porting BASIC to x86-64 VMS and what the issues
    are, at a technical level, that is making the port of BASIC apparently
    much more complex than the other traditional VMS languages.

    I'm pretty sure this has already been explained multiple times. What I
    think I remember is that exception handling and dynamic maps pose some challenges, and there may be RTL dependencies that are somewhat
    different from the other compilers. But I don't think COBOL was easy
    either -- it just has a lot more users and was thus a higher priority.


    That's correct Craig. However, those discussions were within the context
    of BASIC being released "shortly" at the time those discussions took place.

    Given the extended delay since those discussions, I was wondering if more deeper technical issues had emerged which had not yet been discussed here.

    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 Feb 21 13:29:04 2024
    On 2024-02-20, Arne Vajhj <arne@vajhoej.dk> wrote:

    But I am no longer convinced that Basic is so much late, because
    it is so "much more complex".

    I suspect Basic is mostly so much late, because it was the last to
    do and that there has been found a large number of bugs found in
    the compilers released earlier that has taken most of the available
    compiler resource hours. I simply suspect that Basic has been delayed
    because John and the rest of the team has been busy fixing bugs in
    the C, C++, Fortran and Pascal compilers.


    That could be the case, with BASIC being a lower priority than the other compilers.

    Of course, it could also be them settling into their new offices. :-)
    Looks like a nice place.

    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 smartbuck on Wed Feb 21 13:25:56 2024
    On 2024-02-20, smartbuck <ultradwc@gmail.com> wrote:
    will novabbs still work after the 23rd? Is this the new way to access comp.os.vms?

    You will have to ask them how they get their news feed.

    You can always setup a news reader and get a feed from Eternal September
    if you have to.

    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 Lawrence D'Oliveiro@21:1/5 to bill on Wed Feb 21 19:42:37 2024
    On Wed, 21 Feb 2024 09:51:18 -0500, bill wrote:

    I wish some of those many COBOL users needed some programming done by
    someone who actually knows COBOL. I'm bored and retirement sucks.

    I thought COBOL programmers had come out of retirement and were making
    money hand over fist.

    So is the “COBOL renaissance” actually over? Is COBOL code finally going out of use?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Simon Clubley on Wed Feb 21 16:05:31 2024
    On 2/21/2024 8:29 AM, Simon Clubley wrote:
    On 2024-02-20, Arne Vajhøj <arne@vajhoej.dk> wrote:
    But I am no longer convinced that Basic is so much late, because
    it is so "much more complex".

    I suspect Basic is mostly so much late, because it was the last to
    do and that there has been found a large number of bugs found in
    the compilers released earlier that has taken most of the available
    compiler resource hours. I simply suspect that Basic has been delayed
    because John and the rest of the team has been busy fixing bugs in
    the C, C++, Fortran and Pascal compilers.


    That could be the case, with BASIC being a lower priority than the other compilers.

    Of course, it could also be them settling into their new offices. :-)
    Looks like a nice place.

    I don't expect many from the compiler team to work out of their
    downtown office.

    Getting into Boston downtown is like getting into
    London city.

    And besides some of them are overseas.

    Arne

    --- 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 Wed Feb 21 18:55:41 2024
    On 2/20/2024 10:27 PM, Lawrence D'Oliveiro wrote:
    On Tue, 20 Feb 2024 21:09:51 -0500, Arne Vajhøj wrote:
    I believe the example was somewhat similar to:

    program bad
    integer*4 a(2)
    common /m/a
    call s1
    call s2
    write(*,*) a(1),a(2)
    end
    c
    subroutine s1
    integer*4 a(2)
    common /m/a
    data a(1)/123/
    end
    c
    subroutine s2
    integer*4 a(2)
    common /m/a
    data a(2)/456/
    end

    Looking at the Fortran 2018 spec, section 8.4, it says “A variable, or
    part of a variable, shall not be explicitly initialized more
    than once in a program”.

    Also section 8.6.7 says “A variable whose designator appears as a data- stmt-object or a data-i-do-object shall not be a dummy argument, accessed
    by use or host association, in a named common block unless the DATA
    statement is in a block data program unit, in blank common, a function
    name, a function result name, an automatic data object, or an allocatable variable”.

    And?

    Instead of reading the specs you should have tried compiling
    the code on your VMS system.

    It compiles and runs fine!

    Yes - it seems to be an extension to the standard. But VMS Fortran
    hast lots of extensions to the standard.

    But let us take a step back and look at a slightly more
    reasonable example.

    $ type soso.for
    program soso
    integer*4 a(2)
    common /m/a
    call s
    write(*,*) a(1),a(2)
    end
    c
    subroutine s
    integer*4 a(2)
    common /m/a
    data a/123,456/
    end
    $ for soso
    $ link soso
    $ r soso
    123 456

    Which may not be good code as it is rather unclear
    where the data initialization happens, but not nearly
    as bad as the code further above.

    And I believe that style is widely used on VMS. BLOCK DATA
    are not often used on VMS. I mostly see them used for writeable
    shareable images - and that is a very special case.

    $ type bad.for
    program bad
    integer*4 a(2)
    common /m/a
    call s1
    call s2
    write(*,*) a(1),a(2)
    end
    c
    subroutine s1
    integer*4 a(2)
    common /m/a
    data a(1)/123/
    end
    c
    subroutine s2
    integer*4 a(2)
    common /m/a
    data a(2)/456/
    end
    $ for bad
    $ link bad
    $ r bad
    123 456

    Is really ugly code. But it worked on VMS VAX 40 years ago,
    so the expectation is that it works on VMS x86-64 today.

    Backwards compatibility can be a real PITA.

    It is possible to ask for stronger standard compliance check.

    $ for/stand=f95 soso

    program soso
    ^
    %F90-W-WARNING, Fixed form source is an obsolescent feature in Fortran 95.
    at line number 1 in file DKA0:[arne]soso.for;1

    integer*4 a(2)
    ..............^
    %F90-W-WARNING, Fortran 95 does not allow this length specification. [4]
    at line number 2 in file DKA0:[arne]soso.for;1

    integer*4 a(2)
    ..............^
    %F90-W-WARNING, Fortran 95 does not allow this length specification. [4]
    at line number 9 in file DKA0:[arne]soso.for;1

    data a/123,456/
    ...........^
    %F90-W-WARNING, In Fortran 95, this DATA statement object cannot appear
    in either a blank COMMON block or a named COMMON block. [A]
    at line number 11 in file DKA0:[arne]soso.for;1
    $ for/stand=f95 bad

    program bad
    ^
    %F90-W-WARNING, Fixed form source is an obsolescent feature in Fortran 95.
    at line number 1 in file DKA0:[arne]bad.for;1

    integer*4 a(2)
    ..............^
    %F90-W-WARNING, Fortran 95 does not allow this length specification. [4]
    at line number 2 in file DKA0:[arne]bad.for;1

    integer*4 a(2)
    ..............^
    %F90-W-WARNING, Fortran 95 does not allow this length specification. [4]
    at line number 10 in file DKA0:[arne]bad.for;1

    data a(1)/123/
    ...........^
    %F90-W-WARNING, In Fortran 95, this DATA statement object cannot appear
    in either a blank COMMON block or a named COMMON block. [A]
    at line number 12 in file DKA0:[arne]bad.for;1

    integer*4 a(2)
    ..............^
    %F90-W-WARNING, Fortran 95 does not allow this length specification. [4]
    at line number 16 in file DKA0:[arne]bad.for;1

    data a(2)/456/
    ...........^
    %F90-W-WARNING, In Fortran 95, this DATA statement object cannot appear
    in either a blank COMMON block or a named COMMON block. [A]
    at line number 18 in file DKA0:[arne]bad.for;1

    Both the INTEGER*4 declaration and the mix of COMMON and DATA
    are not valid per Fortran 95 standard resulting in the warning.

    But with old VMS Fortran code that qualifier is pretty rare.

    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 Feb 21 19:15:30 2024
    On 2/21/2024 6:55 PM, Arne Vajhøj wrote:
    But let us take a step back and look at a slightly more
    reasonable example.

    $ type soso.for
          program soso
          integer*4 a(2)
          common /m/a
          call s
          write(*,*) a(1),a(2)
          end
    c
          subroutine s
          integer*4 a(2)
          common /m/a
          data a/123,456/
          end
    $ for soso
    $ link soso
    $ r soso
            123         456

    Which may not be good code as it is rather unclear
    where the data initialization happens, but not nearly
    as bad as the code further above.

    And I believe that style is widely used on VMS. BLOCK DATA
    are not often used on VMS. I mostly see them used for writeable
    shareable images - and that is a very special case.

    $ type bad.for
          program bad
          integer*4 a(2)
          common /m/a
          call s1
          call s2
          write(*,*) a(1),a(2)
          end
    c
          subroutine s1
          integer*4 a(2)
          common /m/a
          data a(1)/123/
          end
    c
          subroutine s2
          integer*4 a(2)
          common /m/a
          data a(2)/456/
          end
    $ for bad
    $ link bad
    $ r bad
            123         456

    Is really ugly code. But it worked on VMS VAX 40 years ago,
    so the expectation is that it works on VMS x86-64 today.

    Backwards compatibility can be a real PITA.

    It is possible to ask for stronger standard compliance check.

    $ for/stand=f95 soso

          program soso
    ^
    %F90-W-WARNING, Fixed form source is an obsolescent feature in Fortran 95.
    at line number 1 in file DKA0:[arne]soso.for;1

          integer*4 a(2)
    ..............^
    %F90-W-WARNING, Fortran 95 does not allow this length specification.   [4] at line number 2 in file DKA0:[arne]soso.for;1

          integer*4 a(2)
    ..............^
    %F90-W-WARNING, Fortran 95 does not allow this length specification.   [4] at line number 9 in file DKA0:[arne]soso.for;1

          data a/123,456/
    ...........^
    %F90-W-WARNING, In Fortran 95, this DATA statement object cannot appear
    in either a blank COMMON block or a named COMMON block.   [A]
    at line number 11 in file DKA0:[arne]soso.for;1
    $ for/stand=f95 bad

          program bad
    ^
    %F90-W-WARNING, Fixed form source is an obsolescent feature in Fortran 95.
    at line number 1 in file DKA0:[arne]bad.for;1

          integer*4 a(2)
    ..............^
    %F90-W-WARNING, Fortran 95 does not allow this length specification.   [4] at line number 2 in file DKA0:[arne]bad.for;1

          integer*4 a(2)
    ..............^
    %F90-W-WARNING, Fortran 95 does not allow this length specification.   [4] at line number 10 in file DKA0:[arne]bad.for;1

          data a(1)/123/
    ...........^
    %F90-W-WARNING, In Fortran 95, this DATA statement object cannot appear
    in either a blank COMMON block or a named COMMON block.   [A]
    at line number 12 in file DKA0:[arne]bad.for;1

          integer*4 a(2)
    ..............^
    %F90-W-WARNING, Fortran 95 does not allow this length specification.   [4] at line number 16 in file DKA0:[arne]bad.for;1

          data a(2)/456/
    ...........^
    %F90-W-WARNING, In Fortran 95, this DATA statement object cannot appear
    in either a blank COMMON block or a named COMMON block.   [A]
    at line number 18 in file DKA0:[arne]bad.for;1

    Both the INTEGER*4 declaration and the mix of COMMON and DATA
    are not valid per Fortran 95 standard resulting in the warning.

    But with old VMS Fortran code that qualifier is pretty rare.

    Note that VMS Fortran is not unique in accepting that code.

    I have not been able to find a Fortran compiler not accepting
    it by default.

    GFortran:

    C:\Work\Fortran>gfortran soso.for -o soso.exe

    C:\Work\Fortran>soso
    123 456

    C:\Work\Fortran>gfortran bad.for -o bad.exe

    C:\Work\Fortran>bad
    123 0

    C:\Work\Fortran>gfortran -std=f95 soso.for -o soso.exe
    soso.for:2:16:

    2 | integer*4 a(2)
    | 1
    Error: GNU Extension: Nonstandard type declaration INTEGER*4 at (1) soso.for:5:18:

    5 | write(*,*) a(1),a(2)
    | 1
    Error: PROCEDURE attribute conflicts with COMMON attribute in 'a' at (1) soso.for:9:16:

    9 | integer*4 a(2)
    | 1
    Error: GNU Extension: Nonstandard type declaration INTEGER*4 at (1) soso.for:11:13:

    11 | data a/123,456/
    | 1
    Error: GNU Extension: initialization of common block variable 'a' in
    DATA statement at (1)

    C:\Work\Fortran>gfortran -std=f95 bad.for -o bad.exe
    bad.for:2:16:

    2 | integer*4 a(2)
    | 1
    Error: GNU Extension: Nonstandard type declaration INTEGER*4 at (1) bad.for:6:18:

    6 | write(*,*) a(1),a(2)
    | 1
    Error: PROCEDURE attribute conflicts with COMMON attribute in 'a' at (1) bad.for:10:16:

    10 | integer*4 a(2)
    | 1
    Error: GNU Extension: Nonstandard type declaration INTEGER*4 at (1) bad.for:12:13:

    12 | data a(1)/123/
    | 1
    Error: GNU Extension: initialization of common block variable 'a' in
    DATA statement at (1)
    bad.for:16:16:

    16 | integer*4 a(2)
    | 1
    Error: GNU Extension: Nonstandard type declaration INTEGER*4 at (1) bad.for:18:13:

    18 | data a(2)/456/
    | 1
    Error: GNU Extension: initialization of common block variable 'a' in
    DATA statement at (1)

    The soso example works fine default.

    It is definitely not nice that the compiler and linker silently
    drops the initialization of a(2) in the bad example default.

    Old G77:

    C:\Work\Fortran>g77 soso.for -o soso.exe

    C:\Work\Fortran>soso
    123 456

    C:\Work\Fortran>g77 bad.for -o bad.exe
    bad.for: In subroutine `s2':
    bad.for:12:
    data a(1)/123/
    1
    bad.for:18: (continued):
    data a(2)/456/
    2
    Common block `m' initialized at (2) already initialized at (1) -- only
    one program unit may specify initial values for a particular common block

    The soso example works fine default.

    I think this way to handle the bad example is rather appropriate.

    And an even older Watcom compiler for DOS:

    C:\Work\Fortran>wfl soso.for
    Open Watcom F77/16 Compile and Link Utility Version 1.9
    Portions Copyright (c) 1990-2002 Sybase, Inc. All Rights Reserved.
    Source code is available under the Sybase Open Watcom Public License.
    See http://www.openwatcom.org/ for details.
    wfc soso.for
    Open Watcom FORTRAN 77/16 Optimizing Compiler Version 1.9
    Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
    Source code is available under the Sybase Open Watcom Public License.
    See http://www.openwatcom.org/ for details.
    soso.for: 11 statements, 53 bytes, 4 extensions, 0 warnings, 0 errors
    wlink @__wfl__.lnk
    Open Watcom Linker Version 1.9
    Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
    Source code is available under the Sybase Open Watcom Public License.
    See http://www.openwatcom.org/ for details.
    loading object files
    searching libraries
    creating a DOS executable

    C:\Work\Fortran>wfl bad.for
    Open Watcom F77/16 Compile and Link Utility Version 1.9
    Portions Copyright (c) 1990-2002 Sybase, Inc. All Rights Reserved.
    Source code is available under the Sybase Open Watcom Public License.
    See http://www.openwatcom.org/ for details.
    wfc bad.for
    Open Watcom FORTRAN 77/16 Optimizing Compiler Version 1.9
    Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
    Source code is available under the Sybase Open Watcom Public License.
    See http://www.openwatcom.org/ for details.
    bad.for: 17 statements, 59 bytes, 6 extensions, 0 warnings, 0 errors
    wlink @__wfl__.lnk
    Open Watcom Linker Version 1.9
    Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
    Source code is available under the Sybase Open Watcom Public License.
    See http://www.openwatcom.org/ for details.
    loading object files
    searching libraries
    creating a DOS executable

    (and it produces correct results too for both - I just can't copy paste
    from DOSBOX)

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to All on Thu Feb 22 01:52:04 2024
    On Wed, 21 Feb 2024 18:55:41 -0500, Arne Vajhøj wrote:

    Yes - it seems to be an extension to the standard. But VMS Fortran hast
    lots of extensions to the standard.

    And this particular “extension” does not work consistently from one architecture to another. Big surprise?

    --- 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 Wed Feb 21 22:09:35 2024
    On 2/21/2024 8:52 PM, Lawrence D'Oliveiro wrote:
    On Wed, 21 Feb 2024 18:55:41 -0500, Arne Vajhøj wrote:
    Yes - it seems to be an extension to the standard. But VMS Fortran hast
    lots of extensions to the standard.

    And this particular “extension” does not work consistently from one architecture to another. Big surprise?

    The point is that it has to.

    The VMS users are expecting VMS to be VMS.

    They expect every feature present on VMS VAX 40 years ago
    to work today on VMS x86-64 exactly as they did back then.

    Arne

    --- 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 Wed Feb 21 22:22:11 2024
    On 2/21/2024 2:42 PM, Lawrence D'Oliveiro wrote:
    On Wed, 21 Feb 2024 09:51:18 -0500, bill wrote:
    I wish some of those many COBOL users needed some programming done by
    someone who actually knows COBOL. I'm bored and retirement sucks.

    I thought COBOL programmers had come out of retirement and were making
    money hand over fist.

    So is the “COBOL renaissance” actually over? Is COBOL code finally going out of use?

    There are still a lot of Cobol out there. But not so much Cobol
    work, because most of that Cobol code is getting minimum changes.
    If it was getting huge changes then it would be reimplemented in
    something else.

    There has been talk for like 20 years about the problem with
    Cobol programmers retiring and noone left to maintain Cobol code.

    For many years that was a colorful magazine problem not found
    in the real world. Few Cobol jobs and relative modest pay for
    Cobol skills.

    But my feeling is that it has changed in recent years. Increase
    in number of Cobol jobs advertised and salaries moving from low
    to mid level.

    Not related to Covid. There were some temporarily panic when
    old government systems needed to implement new Covid related
    regulation at short notice, but that is long over.

    I suspect that it is really due to math.

    cobol skill demand = constant * (1 - cobol system attrition rate)**time
    cobol skill supply = constant - size of year of cobol trained * time

    with those formulas then at some point in time demand will exceed
    supply. I suspect that it did happen a few years ago.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andy Burns@21:1/5 to smartbuck on Thu Feb 22 11:53:42 2024
    smartbuck wrote:

    will novabbs still work after the 23rd?

    Given that it speaks usenet (not googlegroups), yes

    Is this the new way to access comp.os.vms?

    Well, it's *A* way for people who want a web interface, rather than a
    real NNTP client

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