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)

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?

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

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

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