From Newsgroup: comp.os.vms

In article <10gk6e6$1bcst$3@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-11-29, Dave Froble <davef@tsoft-inc.com> wrote:

Sometimes things don't really change. You count to 10 the same way now as in
1960. (Trivial example)

Are you sure ? I thought maths teaching was heading in a new direction
in multiple parts of your country as shown by this example (which is way
too close to actually being realistic, especially with the "support" >infrastructure from the people around the teacher):

https://www.youtube.com/watch?v=Zh3Yz3PiXZw

You know, Simon, I recall you posting that you were against the
opposition candidate in our last election because you disliked
her laugh. In your own country, Nigel Farage and his party seem disconcertingly close to power, with their ill-advised "Empire
2.0" aspirations; might I remind you that most of the former
members of Empire 1.0 are still trying to recover?

It's very easy to throw stones, but not terribly advisable when
you yourself are in a glass house.

At least stop adding these things as parentheticals onto posts
that _also_ carry technical content.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-12-01, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <10gk6e6$1bcst$3@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-11-29, Dave Froble <davef@tsoft-inc.com> wrote:

Sometimes things don't really change. You count to 10 the same way now as in
1960. (Trivial example)

Are you sure ? I thought maths teaching was heading in a new direction
in multiple parts of your country as shown by this example (which is way >>too close to actually being realistic, especially with the "support" >>infrastructure from the people around the teacher):

https://www.youtube.com/watch?v=Zh3Yz3PiXZw

You know, Simon, I recall you posting that you were against the
opposition candidate in our last election because you disliked
her laugh. In your own country, Nigel Farage and his party seem disconcertingly close to power, with their ill-advised "Empire
2.0" aspirations; might I remind you that most of the former
members of Empire 1.0 are still trying to recover?

I was trying to refer to the following in a good natured way, which are articles discussing the maths problem in the US I became aware of recently,
and which is what drove me to post the above.

https://www.theatlantic.com/ideas/2025/11/math-decline-ucsd/684973/ https://www.latimes.com/california/story/2025-09-23/low-tests-scores-show-math-crisis-began-a-decade-ago-and-worsened
https://apnews.com/article/math-scores-china-security-b60b740c480270d552d750c15ed287b6

How on earth can someone not know how to divide a fraction by two ?

Oh, and the laugh was only a part of it. It was her inability to
act in a way expected of a US president. I believe the phrase I used
at the time was a lack of gravitas, plus her inability to conduct
serious interviews without collapsing into word salad.

It appears some people are beginning to see through Reform, and we also
have the first past the post system. I am hoping that's enough to stop
him from gaining a majority, but our traditional parties (all of them)
need to _seriously_ up their game.

It's very easy to throw stones, but not terribly advisable when
you yourself are in a glass house.

At least stop adding these things as parentheticals onto posts
that _also_ carry technical content.

Did you read the rest of the posting Dan ?

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

From Newsgroup: comp.os.vms

On 12/1/2025 8:37 AM, Dan Cross wrote:

In article <10gg48s$3srom$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:

On 11/11/2025 10:23 AM, Waldek Hebisch wrote:

Defining a function need a several lines of
overhead code. Function calls are more verbose than in other
languages. There are fixable problems, which however may
appear when dealing with real Cobol code. In particular
Cobol support old control structures. In new program you
can use new control structures, but convering uses of old
control strucures to new ones need effort and it is likely
that a bit more effort would be enough to convert whole
program to a different language.

I apologize in advance, but that is idiotic. Any re-write of any non-trivial
application in another language, will never be complete. There will be errors
and things will be lost. IT WILL HAPPEN !!! And when done, what will be
the gains in a sideways move?

I got the impression Waldek was referring to updating programs
written to old versions of COBOL to use facilities introduced in
newer versions of COBOL, though perhaps I am mistaken.

Regardless, this raises an interesting point: the latest version
of COBOL is, I believe, COBOL 2023. But that language is rather
different than the original 1960 COBOL. So even simply updating
a COBOL program is akin to rewriting it in another language.

The Cobol standard has been continuously updated over
the decades. But very few are using the new stuff added
the last 25 years.

For good reasons.

Let us say that a company:
* have a big Cobol application
* want to add a significant chunk of new functionality
* that new functionality could be implemented using
features from recent versions of Cobol standard

Options:
A) implement it in Cobol using features from recent
versions of Cobol standard and have the team learn
the new stuff
B) implement it in old style Cobol, because that is what
the team knows
C) implement it in some other language where the functionality is
common and call it from Cobol
D) implement it in some other language where the functionality is
common and put it in a separate service in middleware tier and
keep the old Cobol application untouched
E) say NO - can't do it

Few will choose #A. #B, #C and #D are simply more attractive.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10gk6e6$1bcst$3@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

Now this is opinion, and really a poor argument. While I detest the verbosity
in most things, that is my choice, not the problem you claim.

Back on topic, COBOL is very verbose, but I also hate way too concise >languages where the language designers don't even allow words like
"function" to be spelt out in full. You read code many more times than
you write it and having cryptic syntax makes that a lot harder to achieve.

Excessive verbosity can be a hindrance to readability, but
finding a balance with concision is more art that science. I
don't feel the need to spell out "function" when there's an
acceptable abbreviation that means the same thing ("fn"/"fun"/
etc). That said, a lot of early Unix code that omitted vowels
for brevity was utterly abstruse.

Something like Ada was designed for readability, and I wish all other >languages followed that example.

Unfortunately, what's considered "readable" is both subjective
and depends on the audience. Personally, I don't find Ada more
readable because they it forces me to write `function` instead
of `fn` or `procedure` instead of `proc`. If anything, I find
the split between two types of subprograms less readadable, no
matter how it's presented syntacticaly. Similarly, I don't find
the use of `begin` and `end` keywords more readable than `{` and
`}`, or similar lexical glyphs. I understand that others feel
differently.

If anything, I find it less readable since it is less visually
distinct (perhaps, if I my eyesight was even worse than it
already is, I would feel differently).

Just waiting for the moment when a newcomer designs a new language which
has syntax resembling TECO... :-)

Or APL.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10gkvoj$1me0l$2@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 12/1/2025 8:37 AM, Dan Cross wrote:

In article <10gg48s$3srom$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:

On 11/11/2025 10:23 AM, Waldek Hebisch wrote:

Defining a function need a several lines of
overhead code. Function calls are more verbose than in other
languages. There are fixable problems, which however may
appear when dealing with real Cobol code. In particular
Cobol support old control structures. In new program you
can use new control structures, but convering uses of old
control strucures to new ones need effort and it is likely
that a bit more effort would be enough to convert whole
program to a different language.

I apologize in advance, but that is idiotic. Any re-write of any non-trivial
application in another language, will never be complete. There will be errors
and things will be lost. IT WILL HAPPEN !!! And when done, what will be
the gains in a sideways move?

I got the impression Waldek was referring to updating programs
written to old versions of COBOL to use facilities introduced in
newer versions of COBOL, though perhaps I am mistaken.

Regardless, this raises an interesting point: the latest version
of COBOL is, I believe, COBOL 2023. But that language is rather
different than the original 1960 COBOL. So even simply updating
a COBOL program is akin to rewriting it in another language.

The Cobol standard has been continuously updated over
the decades. But very few are using the new stuff added
the last 25 years.

For good reasons.

Let us say that a company:
* have a big Cobol application
* want to add a significant chunk of new functionality
* that new functionality could be implemented using
features from recent versions of Cobol standard

Options:
A) implement it in Cobol using features from recent
versions of Cobol standard and have the team learn
the new stuff
B) implement it in old style Cobol, because that is what
the team knows
C) implement it in some other language where the functionality is
common and call it from Cobol
D) implement it in some other language where the functionality is
common and put it in a separate service in middleware tier and
keep the old Cobol application untouched
E) say NO - can't do it

Few will choose #A. #B, #C and #D are simply more attractive.

Yup. This is the thing that few COBOL fans seem to admit (hi,
Bill): they like to point out that most of the complaints about
COBOL are about very old versions of the language, and that most
of them have been addressed in recent revisions. Ok, fair point
maybe, but irrelevant if the code base one is working in has not
been modernized to take advantage of those new facilities.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/1/2025 4:02 PM, Arne Vajh|+j wrote:

On 12/1/2025 8:37 AM, Dan Cross wrote:

In article <10gg48s$3srom$1@dont-email.me>,
Dave Froble-a <davef@tsoft-inc.com> wrote:

On 11/11/2025 10:23 AM, Waldek Hebisch wrote:

Defining a function need a several lines of
overhead code.-a Function calls are more verbose than in other
languages.-a There are fixable problems, which however may
appear when dealing with real Cobol code.-a In particular
Cobol support old control structures.-a In new program you
can use new control structures, but convering uses of old
control strucures to new ones need effort and it is likely
that a bit more effort would be enough to convert whole
program to a different language.

I apologize in advance, but that is idiotic.-a Any re-write of any
non-trivial
application in another language, will never be complete. There will
be errors
and things will be lost.-a IT-a-a WILL-a-a HAPPEN-a-a !!!-a And when done, >>> what will be
the gains in a sideways move?

I got the impression Waldek was referring to updating programs
written to old versions of COBOL to use facilities introduced in
newer versions of COBOL, though perhaps I am mistaken.

Regardless, this raises an interesting point: the latest version
of COBOL is, I believe, COBOL 2023.-a But that language is rather
different than the original 1960 COBOL.-a So even simply updating
a COBOL program is akin to rewriting it in another language.

The Cobol standard has been continuously updated over
the decades. But very few are using the new stuff added
the last 25 years.

For good reasons.

Let us say that a company:
* have a big Cobol application
* want to add a significant chunk of new functionality
* that new functionality could be implemented using
-a features from recent versions of Cobol standard

Options:
A) implement it in Cobol using features from recent
-a-a versions of Cobol standard and have the team learn
-a-a the new stuff
B) implement it in old style Cobol, because that is what
-a-a the team knows
C) implement it in some other language where the functionality is
-a-a common and call it from Cobol
D) implement it in some other language where the functionality is
-a-a common and put it in a separate service in middleware tier and
-a-a keep the old Cobol application untouched
E) say NO - can't do it

Few will choose #A. #B, #C and #D are simply more attractive.

Not really true. The only thing COBOL professionals have, for
the most part, refused to use is the OOP stuff. Some of the
other changes that are within the COBOL model were very welcome
additions. Like EVALUATE. Got rid of a lot of multiple page
IF-THEN-ELSE monstrosities.

bill


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/1/2025 4:23 PM, Dan Cross wrote:

In article <10gk6e6$1bcst$3@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

Now this is opinion, and really a poor argument. While I detest the verbosity
in most things, that is my choice, not the problem you claim.

Back on topic, COBOL is very verbose, but I also hate way too concise
languages where the language designers don't even allow words like
"function" to be spelt out in full. You read code many more times than
you write it and having cryptic syntax makes that a lot harder to achieve.

Excessive verbosity can be a hindrance to readability, but
finding a balance with concision is more art that science. I
don't feel the need to spell out "function" when there's an
acceptable abbreviation that means the same thing ("fn"/"fun"/
etc). That said, a lot of early Unix code that omitted vowels
for brevity was utterly abstruse.

Something like Ada was designed for readability, and I wish all other
languages followed that example.

Unfortunately, what's considered "readable" is both subjective
and depends on the audience. Personally, I don't find Ada more
readable because they it forces me to write `function` instead
of `fn` or `procedure` instead of `proc`. If anything, I find
the split between two types of subprograms less readadable, no
matter how it's presented syntacticaly. Similarly, I don't find
the use of `begin` and `end` keywords more readable than `{` and
`}`, or similar lexical glyphs. I understand that others feel
differently.

If anything, I find it less readable since it is less visually
distinct (perhaps, if I my eyesight was even worse than it
already is, I would feel differently).

Just waiting for the moment when a newcomer designs a new language which
has syntax resembling TECO... :-)

Or APL.

Nothing wrong with APL, if the task is within the languages domain.
But then, I am one of the last advocates for domain specific rather
than generic languages.

bill


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/1/2025 5:46 PM, bill wrote:

On 12/1/2025 4:02 PM, Arne Vajh|+j wrote:

On 12/1/2025 8:37 AM, Dan Cross wrote:

I got the impression Waldek was referring to updating programs
written to old versions of COBOL to use facilities introduced in
newer versions of COBOL, though perhaps I am mistaken.

Regardless, this raises an interesting point: the latest version
of COBOL is, I believe, COBOL 2023.-a But that language is rather
different than the original 1960 COBOL.-a So even simply updating
a COBOL program is akin to rewriting it in another language.

The Cobol standard has been continuously updated over
the decades. But very few are using the new stuff added
the last 25 years.

Not really true. The only thing COBOL professionals have, for
the most part, refused to use is the OOP stuff.-a Some of the
other changes that are within the COBOL model were very welcome
additions.-a Like EVALUATE.-a Got rid of a lot of multiple page
IF-THEN-ELSE monstrosities.

EVALUATE came with COBOL 85. That is not within the
last 25 years.

New features within last 25 years besides OOP include:
* recursion support
* unicode support
* pointers and dynamic memory allocation
^ XML support
* collection classes

Have you seen COBOL code using those?

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/1/2025 8:37 AM, Dan Cross wrote:

I've long suspected (but I admit I have no evidence to support
this) that one of the reasons there is so much COBOL code in the
world is because, when making non-trivial changes, programmers
first _copy_ large sections of the program and then modify the
copy, to avoid introducing bugs into existing functionality.

Copying and modifying code instead of creating reusable libraries
has been used by bad programmers in all languages.

But last century then Cobol and Basic were the two easiest
languages to learn and Cobol was one of the languages with
most jobs. So it seems likely that a large number of bad
programmers picked Cobol. Bringing bad habits with them.

Today I would expect that crowd to pick client side JavaScript
and server side PHP.

There is also something in the Cobol language.

Large files with one data division, lots of paragraphs
and lots of perform's is easy to code, but it is also
bad for reusable code.

It is sort of the same as having large C or Pascal files
with all variables global and all functions/procedures
without arguments.

It is possible to do it right, but when people have
to chose between the easy way and the right way, then ...

Arne




--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/1/2025 8:06 PM, Arne Vajh|+j wrote:

There is also something in the Cobol language.

Large files with one data division, lots of paragraphs
and lots of perform's is easy to code, but it is also
bad for reusable code.

It is sort of the same as having large C or Pascal files
with all variables global and all functions/procedures
without arguments.

It is possible to do it right, but when people have
to chose between the easy way and the right way, then ...

And a long post to illustrate.

$ type m1.cob
identification division.
program-id.m1.
*
data division.
working-storage section.
01 ia.
03 ia-elm pic 9(8) comp occurs 5 times.
01 bia.
03 bia-elm pic 9(8) comp occurs 7 times.
01 xa.
03 xa-elm comp-2 occurs 5 times.
01 i pic 9(8) comp.
01 j pic 9(8) comp.
01 startj pic 9(8) comp.
01 temp-ia-elm pic 9(8) display.
01 temp-bia-elm pic 9(8) display.
01 temp-xa-elm pic 9(8)v9(2) display.
01 temp-i pic 9(8) display.
01 temp-ia pic 9(8) comp.
01 temp-bia pic 9(8) comp.
01 temp-xa comp-2.
*
procedure division.
main-paragraph.
move 3 to ia-elm(1)
move 5 to ia-elm(2)
move 7 to ia-elm(3)
move 6 to ia-elm(4)
move 4 to ia-elm(5)
display "Before:"
perform print-ia
perform sort-ia
display "After:"
perform print-ia
move 3 to bia-elm(1)
move 5 to bia-elm(2)
move 7 to bia-elm(3)
move 6 to bia-elm(4)
move 4 to bia-elm(5)
move 2 to bia-elm(6)
move 8 to bia-elm(7)
display "Before:"
perform print-bia
perform sort-bia
display "After:"
perform print-bia
move 3.3 to xa-elm(1)
move 5.5 to xa-elm(2)
move 7.7 to xa-elm(3)
move 6.6 to xa-elm(4)
move 4.4 to xa-elm(5)
display "Before:"
perform print-xa
perform sort-xa
display "After:"
perform print-xa
stop run.
sort-ia.
perform varying i from 1 by 1 until i >= 5
compute startj = i + 1
perform varying j from startj by 1 until j > 5
if ia-elm(j) < ia-elm(i) then
move ia-elm(j) to temp-ia
move ia-elm(i) to ia-elm(j)
move temp-ia to ia-elm(i)
end-if
end-perform
end-perform.
print-ia.
perform varying i from 1 by 1 until i > 5
move i to temp-i
move ia-elm(i) to temp-ia-elm
display temp-i " : " temp-ia-elm
end-perform.
sort-bia.
perform varying i from 1 by 1 until i >= 7
compute startj = i + 1
perform varying j from startj by 1 until j > 7
if bia-elm(j) < bia-elm(i) then
move bia-elm(j) to temp-bia
move bia-elm(i) to bia-elm(j)
move temp-bia to bia-elm(i)
end-if
end-perform
end-perform.
print-bia.
perform varying i from 1 by 1 until i > 7
move i to temp-i
move bia-elm(i) to temp-bia-elm
display temp-i " : " temp-bia-elm
end-perform.
sort-xa.
perform varying i from 1 by 1 until i >= 5
compute startj = i + 1
perform varying j from startj by 1 until j > 5
if xa-elm(j) < xa-elm(i) then
move xa-elm(j) to temp-xa
move xa-elm(i) to xa-elm(j)
move temp-xa to xa-elm(i)
end-if
end-perform
end-perform.
print-xa.
perform varying i from 1 by 1 until i > 5
move i to temp-i
move xa-elm(i) to temp-xa-elm
display temp-i " : " temp-xa-elm
end-perform.
$ cob M1
$ link M1
$ run M1
Before:
00000001 : 00000003
00000002 : 00000005
00000003 : 00000007
00000004 : 00000006
00000005 : 00000004
After:
00000001 : 00000003
00000002 : 00000004
00000003 : 00000005
00000004 : 00000006
00000005 : 00000007
Before:
00000001 : 00000003
00000002 : 00000005
00000003 : 00000007
00000004 : 00000006
00000005 : 00000004
00000006 : 00000002
00000007 : 00000008
After:
00000001 : 00000002
00000002 : 00000003
00000003 : 00000004
00000004 : 00000005
00000005 : 00000006
00000006 : 00000007
00000007 : 00000008
Before:
00000001 : 0000000330
00000002 : 0000000550
00000003 : 0000000770
00000004 : 0000000660
00000005 : 0000000440
After:
00000001 : 0000000330
00000002 : 0000000440
00000003 : 0000000550
00000004 : 0000000660
00000005 : 0000000770
$ type lib2.cob
identification division.
program-id.sort-i.

data division.
working-storage section.
01 i pic 9(8) comp.
01 j pic 9(8) comp.
01 startj pic 9(8) comp.
01 temp-ia pic 9(8) comp.
linkage section.
01 n-ia pic 9(8) comp.
01 ia.
03 ia-elm pic 9(8) comp occurs 0 to 1000 times depending on n-ia.

procedure division using n-ia, ia.
main-paragraph.
perform varying i from 1 by 1 until i >= n-ia
compute startj = i + 1
perform varying j from startj by 1 until j > n-ia
if ia-elm(j) < ia-elm(i) then
move ia-elm(j) to temp-ia
move ia-elm(i) to ia-elm(j)
move temp-ia to ia-elm(i)
end-if
end-perform
end-perform.
end program sort-i.
****
identification division.
program-id.print-i.

data division.
working-storage section.
01 i pic 9(8) comp.
01 temp-ia-elm pic 9(8) display.
01 temp-i pic 9(8) display.
linkage section.
01 n-ia pic 9(8) comp.
01 ia.
03 ia-elm pic 9(8) comp occurs 0 to 1000 times depending on n-ia.

procedure division using n-ia, ia.
main-paragraph.
perform varying i from 1 by 1 until i > n-ia
move i to temp-i
move ia-elm(i) to temp-ia-elm
display temp-i " : " temp-ia-elm
end-perform.
end program print-i.
****
identification division.
program-id.sort-x.

data division.
working-storage section.
01 i pic 9(8) comp.
01 j pic 9(8) comp.
01 startj pic 9(8) comp.
01 temp-xa comp-2.
linkage section.
01 n-xa pic 9(8) comp.
01 xa.
03 xa-elm comp-2 occurs 0 to 1000 times depending on n-xa.

procedure division using n-xa, xa.
main-paragraph.
perform varying i from 1 by 1 until i >= n-xa
compute startj = i + 1
perform varying j from startj by 1 until j > n-xa
if xa-elm(j) < xa-elm(i) then
move xa-elm(j) to temp-xa
move xa-elm(i) to xa-elm(j)
move temp-xa to xa-elm(i)
end-if
end-perform
end-perform.
end program sort-x.
****
identification division.
program-id.print-x.

data division.
working-storage section.
01 i pic 9(8) comp.
01 temp-xa-elm pic 9(8)v9(2) display.
01 temp-i pic 9(8) display.
linkage section.
01 n-xa pic 9(8) comp.
01 xa.
03 xa-elm comp-2 occurs 0 to 1000 times depending on n-xa.

procedure division using n-xa, xa.
main-paragraph.
perform varying i from 1 by 1 until i > n-xa
move i to temp-i
move xa-elm(i) to temp-xa-elm
display temp-i " : " temp-xa-elm
end-perform.
end program print-x.
$ type m2.cob
identification division.
program-id.m2.
*
data division.
working-storage section.
01 ia.
03 ia-elm pic 9(8) comp occurs 5 times.
01 bia.
03 bia-elm pic 9(8) comp occurs 7 times.
01 xa.
03 xa-elm comp-2 occurs 5 times.
01 n pic 9(8) comp.
01 i pic 9(8) comp.
01 j pic 9(8) comp.
01 startj pic 9(8) comp.
01 temp-ia-elm pic 9(8) display.
01 temp-bia-elm pic 9(8) display.
01 temp-xa-elm pic 9(8)v9(2) display.
01 temp-i pic 9(8) display.
01 temp-ia pic 9(8) comp.
01 temp-bia pic 9(8) comp.
01 temp-xa comp-2.
*
procedure division.
main-paragraph.
move 3 to ia-elm(1)
move 5 to ia-elm(2)
move 7 to ia-elm(3)
move 6 to ia-elm(4)
move 4 to ia-elm(5)
move 5 to n
display "Before:"
call "print-i" using n, ia
call "sort-i" using n, ia
display "After:"
call "print-i" using n, ia
move 3 to bia-elm(1)
move 5 to bia-elm(2)
move 7 to bia-elm(3)
move 6 to bia-elm(4)
move 4 to bia-elm(5)
move 2 to bia-elm(6)
move 8 to bia-elm(7)
move 7 to n
display "Before:"
call "print-i" using n, bia
call "sort-i" using n, bia
display "After:"
call "print-i" using n, bia
move 3.3 to xa-elm(1)
move 5.5 to xa-elm(2)
move 7.7 to xa-elm(3)
move 6.6 to xa-elm(4)
move 4.4 to xa-elm(5)
move 5 to n
display "Before:"
call "print-x" using n, xa
call "sort-x" using n, xa
display "After:"
call "print-x" using n, xa
stop run.
$ cob M2
$ cob LIB2
$ link M2 + LIB2
$ run M2
Before:
00000001 : 00000003
00000002 : 00000005
00000003 : 00000007
00000004 : 00000006
00000005 : 00000004
After:
00000001 : 00000003
00000002 : 00000004
00000003 : 00000005
00000004 : 00000006
00000005 : 00000007
Before:
00000001 : 00000003
00000002 : 00000005
00000003 : 00000007
00000004 : 00000006
00000005 : 00000004
00000006 : 00000002
00000007 : 00000008
After:
00000001 : 00000002
00000002 : 00000003
00000003 : 00000004
00000004 : 00000005
00000005 : 00000006
00000006 : 00000007
00000007 : 00000008
Before:
00000001 : 0000000330
00000002 : 0000000550
00000003 : 0000000770
00000004 : 0000000660
00000005 : 0000000440
After:
00000001 : 0000000330
00000002 : 0000000440
00000003 : 0000000550
00000004 : 0000000660
00000005 : 0000000770
$ type sort.cob
identification division.
program-id.:NAME:.

data division.
working-storage section.
01 i pic 9(8) comp.
01 j pic 9(8) comp.
01 startj pic 9(8) comp.
01 temp-a :T:.
linkage section.
01 n-a pic 9(8) comp.
01 a.
03 a-elm :T: occurs 0 to 1000 times depending on n-a.

procedure division using n-a, a.
main-paragraph.
perform varying i from 1 by 1 until i >= n-a
compute startj = i + 1
perform varying j from startj by 1 until j > n-a
if a-elm(j) < a-elm(i) then
move a-elm(j) to temp-a
move a-elm(i) to a-elm(j)
move temp-a to a-elm(i)
end-if
end-perform
end-perform.
end program :NAME:.
$ type print.cob
identification division.
program-id.:NAME:.

data division.
working-storage section.
01 i pic 9(8) comp.
01 temp-a-elm :PT:.
01 temp-i pic 9(8) display.
linkage section.
01 n-a pic 9(8) comp.
01 a.
03 a-elm :T: occurs 0 to 1000 times depending on n-a.

procedure division using n-a, a.
main-paragraph.
perform varying i from 1 by 1 until i > n-a
move i to temp-i
move a-elm(i) to temp-a-elm
display temp-i " : " temp-a-elm
end-perform.
end program :NAME:.
$ type lib3.cob
copy "sort.cob" replacing ==:NAME:== by ==sort-i== ==:T:== by ==pic 9(8) comp==.
****
copy "print.cob" replacing ==:NAME:== by ==print-i== ==:T:== by ==pic
9(8) comp== ==:PT:== by ==pic 9(8) display==.
****
copy "sort.cob" replacing ==:NAME:== by ==sort-x== ==:T:== by ==comp-2==.
****
copy "print.cob" replacing ==:NAME:== by ==print-x== ==:T:== by
==comp-2== ==:PT:== by ==pic 9(8)v9(2) display==.
$ type m3.cob
identification division.
program-id.m2.
*
data division.
working-storage section.
01 ia.
03 ia-elm pic 9(8) comp occurs 5 times.
01 bia.
03 bia-elm pic 9(8) comp occurs 7 times.
01 xa.
03 xa-elm comp-2 occurs 5 times.
01 n pic 9(8) comp.
01 i pic 9(8) comp.
01 j pic 9(8) comp.
01 startj pic 9(8) comp.
01 temp-ia-elm pic 9(8) display.
01 temp-bia-elm pic 9(8) display.
01 temp-xa-elm pic 9(8)v9(2) display.
01 temp-i pic 9(8) display.
01 temp-ia pic 9(8) comp.
01 temp-bia pic 9(8) comp.
01 temp-xa comp-2.
*
procedure division.
main-paragraph.
move 3 to ia-elm(1)
move 5 to ia-elm(2)
move 7 to ia-elm(3)
move 6 to ia-elm(4)
move 4 to ia-elm(5)
move 5 to n
display "Before:"
call "print-i" using n, ia
call "sort-i" using n, ia
display "After:"
call "print-i" using n, ia
move 3 to bia-elm(1)
move 5 to bia-elm(2)
move 7 to bia-elm(3)
move 6 to bia-elm(4)
move 4 to bia-elm(5)
move 2 to bia-elm(6)
move 8 to bia-elm(7)
move 7 to n
display "Before:"
call "print-i" using n, bia
call "sort-i" using n, bia
display "After:"
call "print-i" using n, bia
move 3.3 to xa-elm(1)
move 5.5 to xa-elm(2)
move 7.7 to xa-elm(3)
move 6.6 to xa-elm(4)
move 4.4 to xa-elm(5)
move 5 to n
display "Before:"
call "print-x" using n, xa
call "sort-x" using n, xa
display "After:"
call "print-x" using n, xa
stop run.
$ cob M3
$ cob LIB3
$ link M3 + LIB3
$ run M3
Before:
00000001 : 00000003
00000002 : 00000005
00000003 : 00000007
00000004 : 00000006
00000005 : 00000004
After:
00000001 : 00000003
00000002 : 00000004
00000003 : 00000005
00000004 : 00000006
00000005 : 00000007
Before:
00000001 : 00000003
00000002 : 00000005
00000003 : 00000007
00000004 : 00000006
00000005 : 00000004
00000006 : 00000002
00000007 : 00000008
After:
00000001 : 00000002
00000002 : 00000003
00000003 : 00000004
00000004 : 00000005
00000005 : 00000006
00000006 : 00000007
00000007 : 00000008
Before:
00000001 : 0000000330
00000002 : 0000000550
00000003 : 0000000770
00000004 : 0000000660
00000005 : 0000000440
After:
00000001 : 0000000330
00000002 : 0000000440
00000003 : 0000000550
00000004 : 0000000660
00000005 : 0000000770

Note that I am not good enough in Cobol to know if this is
all standard Cobol, but it happens to work with VMS Cobol.

I am somewhat skeptical about if any Cobol developers use
the generic style in the '3' example.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/1/2025 8:06 PM, Arne Vajh|+j wrote:

On 12/1/2025 8:37 AM, Dan Cross wrote:

I've long suspected (but I admit I have no evidence to support
this) that one of the reasons there is so much COBOL code in the
world is because, when making non-trivial changes, programmers
first _copy_ large sections of the program and then modify the
copy, to avoid introducing bugs into existing functionality.

Copying and modifying code instead of creating reusable libraries
has been used by bad programmers in all languages.

But last century then Cobol and Basic were the two easiest
languages to learn and Cobol was one of the languages with
most jobs. So it seems likely that a large number of bad
programmers picked Cobol. Bringing bad habits with them.

Today I would expect that crowd to pick client side JavaScript
and server side PHP.

There is also something in the Cobol language.

Large files with one data division, lots of paragraphs
and lots of perform's is easy to code, but it is also
bad for reusable code.

It is sort of the same as having large C or Pascal files
with all variables global and all functions/procedures
without arguments.

It is possible to do it right, but when people have
to chose between the easy way and the right way, then ...

I take it you have never worked in a real COBOL shop.

bill


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/1/2025 6:50 PM, Arne Vajh|+j wrote:

On 12/1/2025 5:46 PM, bill wrote:

On 12/1/2025 4:02 PM, Arne Vajh|+j wrote:

On 12/1/2025 8:37 AM, Dan Cross wrote:

I got the impression Waldek was referring to updating programs
written to old versions of COBOL to use facilities introduced in
newer versions of COBOL, though perhaps I am mistaken.

Regardless, this raises an interesting point: the latest version
of COBOL is, I believe, COBOL 2023.-a But that language is rather
different than the original 1960 COBOL.-a So even simply updating
a COBOL program is akin to rewriting it in another language.

The Cobol standard has been continuously updated over
the decades. But very few are using the new stuff added
the last 25 years.

Not really true. The only thing COBOL professionals have, for
the most part, refused to use is the OOP stuff.-a Some of the
other changes that are within the COBOL model were very welcome
additions.-a Like EVALUATE.-a Got rid of a lot of multiple page
IF-THEN-ELSE monstrosities.

EVALUATE came with COBOL 85. That is not within the
last 25 years.

New features within last 25 years besides OOP include:
* recursion support
* unicode support
* pointers and dynamic memory allocation
^ XML support
* collection classes

Have you seen COBOL code using those?

I have seen and used pointers but not in production code as at 75
I am not finding many places that want me to work. :-)

XML isn't really anything to do with the language it's a file
format. Probably has no place in the language itself.

UNICODE the same thing. It could be done fairly easily with a library
but isn't really anything that COBOL had to have as a part of the
language.

Wouldn't classes fall under OOP. Like other long time COBOL
programmers I never saw where that brought anything to help
the tasks COBOL was intended for. But it is probably great
for people using the wrong language for a particular job.

Now recursion! There's something useful. Have to take a look
at it.

bill


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/1/2025 8:15 PM, bill wrote:

On 12/1/2025 8:06 PM, Arne Vajh|+j wrote:

But last century then Cobol and Basic were the two easiest
languages to learn and Cobol was one of the languages with
most jobs. So it seems likely that a large number of bad
programmers picked Cobol. Bringing bad habits with them.

Today I would expect that crowd to pick client side JavaScript
and server side PHP.

There is also something in the Cobol language.

Large files with one data division, lots of paragraphs
and lots of perform's is easy to code, but it is also
bad for reusable code.

It is sort of the same as having large C or Pascal files
with all variables global and all functions/procedures
without arguments.

It is possible to do it right, but when people have
to chose between the easy way and the right way, then ...

I take it you have never worked in a real COBOL shop.

That is true.

I was with the Fortran people not the Cobol people.

But that does not change that:
* back in those days then there were some people
doing Cobol that should not have - this is widely
known - I believe the not so nice name for them
back then was "list programmers" (I was told about
that by a Cobol programmer when I took the DEC course
VMS for Programmers back in the mid 80's)
* PERFORM of paragraphs is not a good way to
write reusable code

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/1/2025 8:23 PM, bill wrote:

On 12/1/2025 6:50 PM, Arne Vajh|+j wrote:

New features within last 25 years besides OOP include:
* recursion support
* unicode support
* pointers and dynamic memory allocation
^ XML support
* collection classes

Have you seen COBOL code using those?

I have seen and used pointers but not in production code as at 75
I am not finding many places that want me to work.-a :-)

XML isn't really anything to do with the language it's a file
format. Probably has no place in the language itself.

They did:

ISO/IEC TR 24716:2007, Information technology -- Programming languages,
their environment and system software interfaces -- Native COBOL Syntax
for XML Support

I have no idea what it does, so I don't know if it makes any sense.

UNICODE the same thing.-a It could be done fairly easily with a library
but isn't really anything that COBOL had to have as a part of the
language.

Good unicode support require support in both language and
basic RTL.

As an example (I am not claiming that it is good support!!) see C++:

std::string
std::wstring
std::u16string
std::u32string

"ABC"
L"ABC"
u8"ABC"
u"ABC"
U"ABC"

Wouldn't classes fall under OOP.

Classes is part of OOP that was added in Cobol 2002.

Collection classes was added in:

ISO/IEC TR 24717:2009, Information technology -- Programming languages,
their environments and system software interfaces -- Collection classes
for programming language COBOL

I have never seen it used and I do not know how they work. But if it is
like collection classes in most other programming languages, then it
is predefined container classes for list, map/dictionary etc..

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/1/2025 8:44 PM, Arne Vajh|+j wrote:

On 12/1/2025 8:23 PM, bill wrote:

Wouldn't classes fall under OOP.

Classes is part of OOP that was added in Cobol 2002.

Collection classes was added in:

ISO/IEC TR 24717:2009, Information technology -- Programming languages, their environments and system software interfaces -- Collection classes
for programming language COBOL

I have never seen it used and I do not know how they work. But if it is
like collection classes in most other programming languages, then it
is predefined container classes for list, map/dictionary etc..

Refs:

https://en.cppreference.com/w/cpp/container.html

https://docs.oracle.com/javase/8/docs/technotes/guides/collections/index.html

https://learn.microsoft.com/en-us/dotnet/standard/collections/

https://docs.python.org/3/library/collections.html

Arne




--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/1/2025 8:31 PM, Arne Vajh|+j wrote:

On 12/1/2025 8:15 PM, bill wrote:

On 12/1/2025 8:06 PM, Arne Vajh|+j wrote:

But last century then Cobol and Basic were the two easiest
languages to learn and Cobol was one of the languages with
most jobs. So it seems likely that a large number of bad
programmers picked Cobol. Bringing bad habits with them.

Today I would expect that crowd to pick client side JavaScript
and server side PHP.

There is also something in the Cobol language.

Large files with one data division, lots of paragraphs
and lots of perform's is easy to code, but it is also
bad for reusable code.

It is sort of the same as having large C or Pascal files
with all variables global and all functions/procedures
without arguments.

It is possible to do it right, but when people have
to chose between the easy way and the right way, then ...

I take it you have never worked in a real COBOL shop.

That is true.

I was with the Fortran people not the Cobol people.

I did Fortran, too. Often in the same department (and with the
same rules) as the COBOL.

But that does not change that:
* back in those days

Exactly what do you consider to be "back in those days"?

then there were some people
-a doing Cobol that should not have - this is widely
-a known -

Not widely known in the circles I worked in. If I were not a
competent COBOL programmer I would have been eliminated.

I once worked in a government facility. They have strange HR rules.
We had a woman who was totally incapable of writing a coherent COBOL
program. Because it was government she could not be fired. So she
came in everyday and read the newspaper because our boss refused to
let her touch any code.

The only other bad example I came in contact with was work done by
contractors who had no idea how to do COBOL and DBMS. I came in
many years after they had done their damage and fixed it all.
But that was in more recent times. In COBOL's heyday the programmers
were a lot better than most programmers I see today.

I believe the not so nice name for them
-a back then was "list programmers" (I was told about
-a that by a Cobol programmer when I took the DEC course
-a VMS for Programmers back in the mid 80's)
* PERFORM of paragraphs is not a good way to
-a write reusable code

Matter of opinion. In most of the shops I worked we reused a lot
of code. We had librarians who were responsible for maintaining
both the executable and source libraries.

bill


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/1/2025 9:39 PM, bill wrote:

On 12/1/2025 8:31 PM, Arne Vajh|+j wrote:

But that does not change that:
* back in those days

Exactly what do you consider to be "back in those days"?

Let us say before 1995.

Then I guess the segment I am thinking of started to switch
to VB6 and then a few years later ASP and a few years later again
PHP.

-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a then there were some people
-a-a doing Cobol that should not have - this is widely
-a-a known -

Not widely known in the circles I worked in.-a If I were not a
competent COBOL programmer I would have been eliminated.

Programming is a skill like any other skill.

Normal/gaussian distribution.

Few very good.
Some good.
Lot okay.
Some not so good.
Few really bad.

Some of the latter two categories do end up being hired. By mistake,
because the company can not get any other or something else.

What language did those people pick back then?

VB6, ASP and PHP was not invented yet.

They did not have a chance with C++ or Ada. They would never get
anything to compile. Out of the question.

Fortran 77 is also an easy language to learn, but it was mostly
taught in natural science and social science studies. And the people
I am talking about could not pass the math exam for those.

C can be a bit more tricky and was also a bit computer science
and electric engineering oriented at that time, so math exam
again.

They practically had to pick Cobol or Basic.

More jobs in Cobol so most picked Cobol.

Not a problem with Cobol or Basic or the people that were
actually good in those languages.

Just how things work.

Today we have them mostly in PHP.

Not using Laravel and writing OO PHP.

1000 lines long PHP files with SQL execution and HTML output
totally mixed up and wrong indentation etc..

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/1/2025 8:44 PM, Arne Vajh|+j wrote:

On 12/1/2025 8:23 PM, bill wrote:

On 12/1/2025 6:50 PM, Arne Vajh|+j wrote:

New features within last 25 years besides OOP include:
* recursion support
* unicode support
* pointers and dynamic memory allocation
^ XML support
* collection classes

Have you seen COBOL code using those?

I have seen and used pointers but not in production code as at 75
I am not finding many places that want me to work.-a :-)

XML isn't really anything to do with the language it's a file
format. Probably has no place in the language itself.

They did:

ISO/IEC TR 24716:2007, Information technology -- Programming languages, their environment and system software interfaces -- Native COBOL Syntax
for XML Support

I have no idea what it does, so I don't know if it makes any sense.

Ivory tower types have always been shoving crap into COBOL.
Kinda like Ada. Originally an US Air Force idea intended
to replace Jovial and other odd things used for things like
flying jets. Then the committee got hold of it. When the
first release came out the US Air Force refused to use it
even after the DOD Mandate.

UNICODE the same thing.-a It could be done fairly easily with a library
but isn't really anything that COBOL had to have as a part of the
language.

Good unicode support require support in both language and
basic RTL.

Don't agree. COBOL was intended to keep track of money, inventory,
personnel, etc. UNICODE, per se, brings nothing to the table for
any of that. And, as designed, it did support alternate character
sets.

As an example (I am not claiming that it is good support!!) see C++:

std::string
std::wstring
std::u16string
std::u32string

"ABC"
L"ABC"
u8"ABC"
u"ABC"
U"ABC"

Wouldn't classes fall under OOP.

Classes is part of OOP that was added in Cobol 2002.

And the COBOL Community refused to drink the Kool-Aid.
While there may actually be a place for OOP, the work
COBOL was intended to do isn't it. Academia tried to
force it down everyone's throats and were outraged
when some refused. (And took their revenge which is
being felt more and more every day now!!) I know a
number of massive ISes in use today that have been in
use for around a half century that were written in COBOL
and continue to function in COBOL. Lack of OOP hasn't
affected them at all.

Collection classes was added in:

ISO/IEC TR 24717:2009, Information technology -- Programming languages, their environments and system software interfaces -- Collection classes
for programming language COBOL

I have never seen it used and I do not know how they work. But if it is
like collection classes in most other programming languages, then it
is predefined container classes for list, map/dictionary etc..

Which does what for COBOL?

bill


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/1/2025 10:05 PM, bill wrote:

On 12/1/2025 8:44 PM, Arne Vajh|+j wrote:

On 12/1/2025 8:23 PM, bill wrote:

UNICODE the same thing.-a It could be done fairly easily with a library
but isn't really anything that COBOL had to have as a part of the
language.

Good unicode support require support in both language and
basic RTL.

Don't agree.

It does - see C++ examples given.

-a COBOL was intended to keep track of money, inventory,
personnel, etc.-a UNICODE, per se,-a brings nothing to the table for
any of that.

Whether supporting unicode requires language and basic RTL support
is not the same question as whether unicode support is desirable.

But unicode support becomes somewhat desirable when you need to
support all Latin languages and very desirable when you start
supporting non-Latin languages.

Wouldn't classes fall under OOP.

Classes is part of OOP that was added in Cobol 2002.

And the COBOL Community refused to drink the Kool-Aid.
While there may actually be a place for OOP, the work
COBOL was intended to do isn't it.-a Academia tried to
force it down everyone's throats and were outraged
when some refused. (And took their revenge which is
being felt more and more every day now!!)-a I know a
number of massive ISes in use today that have been in
use for around a half century that were written in COBOL
and continue to function in COBOL. Lack of OOP hasn't
affected them at all.

The Cobol code still does what it did when it was written.

But don't expect leadership of the orgs to be happy with
them.

Cost, speed of development, integration with other systems etc..

Collection classes was added in:

ISO/IEC TR 24717:2009, Information technology -- Programming
languages, their environments and system software interfaces --
Collection classes for programming language COBOL

I have never seen it used and I do not know how they work. But if it is
like collection classes in most other programming languages, then it
is predefined container classes for list, map/dictionary etc..

Which does what for COBOL?

Not sure what they would do in Cobol, if they
were actually used.

In other languages they have more or less made arrays
obsolete.

:-)

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <mp73b5Fjl5lU3@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:

On 12/1/2025 8:44 PM, Arne Vajh|+j wrote:

On 12/1/2025 8:23 PM, bill wrote:

[snip]
UNICODE the same thing.-a It could be done fairly easily with a library
but isn't really anything that COBOL had to have as a part of the
language.

Good unicode support require support in both language and
basic RTL.

Don't agree. COBOL was intended to keep track of money, inventory, >personnel, etc. UNICODE, per se, brings nothing to the table for
any of that. And, as designed, it did support alternate character
sets.

Well, taking personnel as an example, people have names, don't
they? Not everyone uses the Latin alphabet, and even for those
that (largely) do, some folks have diacritical marks in their
name and so forth. It's nice to be able to represent those.

Classes is part of OOP that was added in Cobol 2002.

And the COBOL Community refused to drink the Kool-Aid.
While there may actually be a place for OOP, the work
COBOL was intended to do isn't it. Academia tried to
force it down everyone's throats and were outraged
when some refused. (And took their revenge which is
being felt more and more every day now!!) I know a
number of massive ISes in use today that have been in
use for around a half century that were written in COBOL
and continue to function in COBOL. Lack of OOP hasn't
affected them at all.

Maybe, maybe not, but what you are describing is survivorship
bias. It's entirely possible that _some_ COBOL programs might
have benefited substantially from employing some OO techniques;
because they didn't really try, we don't know.

Consider a summarization report for a payroll run that is
sourced from data accumulated over the run. This really isn't
my wheelhouse, but I could well imagine representing the
accumulated state in an object and doing the actual accumulation
via method calls on that object; perhaps part of the process of
accumulation is performing some transformation; that logic could
be centralized in those methods.

One doesn't need to do it that way, of course, but as an
organizational style it's honestly not bad, and would fit very
well into the types of tasks common in the COBOL world.

There's a lot of COBOL out there. Maybe someone's tried this
and decided that it wasn't the best way to go about things. But
that's qualitatively different than rejecting the idea out of
hand because it's an academic exercise in self-abuse.

Collection classes was added in:

ISO/IEC TR 24717:2009, Information technology -- Programming languages,
their environments and system software interfaces -- Collection classes
for programming language COBOL

I have never seen it used and I do not know how they work. But if it is
like collection classes in most other programming languages, then it
is predefined container classes for list, map/dictionary etc..

Which does what for COBOL?

Makes it so that you never have to implement a linked list,
binary search tree, or hash table ever again.

I tend to think of COBOL as a DSL for expressing "business
logic": it's optimized for expressing relatively simple rules
applied over and over again across a large data set. If that's
the case, then a COBOL programmer may never need those things.

But I imagine even COBOL folks like the flexibility of
data-driven designs, for which such things can be useful for
building lookup-tables and so forth.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10gle2k$1q97g$1@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 12/1/2025 8:37 AM, Dan Cross wrote:

I've long suspected (but I admit I have no evidence to support
this) that one of the reasons there is so much COBOL code in the
world is because, when making non-trivial changes, programmers
first _copy_ large sections of the program and then modify the
copy, to avoid introducing bugs into existing functionality.

Copying and modifying code instead of creating reusable libraries
has been used by bad programmers in all languages.

I think it's a little deeper than that.

But last century then Cobol and Basic were the two easiest
languages to learn and Cobol was one of the languages with
most jobs. So it seems likely that a large number of bad
programmers picked Cobol. Bringing bad habits with them.

Today I would expect that crowd to pick client side JavaScript
and server side PHP.

There is also something in the Cobol language.

Large files with one data division, lots of paragraphs
and lots of perform's is easy to code, but it is also
bad for reusable code.

It is sort of the same as having large C or Pascal files
with all variables global and all functions/procedures
without arguments.

It is possible to do it right, but when people have
to chose between the easy way and the right way, then ...

An issue with COBOL is that, given procedures A, B, ..., Z,
written sequentially in source, `PERFORM A THRU Z` means that it
is difficult to see when procedures B, C, ..., Y are called just
through visual inspection since calls to them are implicit; you
really need semantically aware tools to do that. So if you need
to change paragraph D, then you run the risk of implicitly
changing dependent behavior in your system unintentionally. You
might end up violating some assumption you didn't even know
existed; talk about spooky action at a distance.

Most COBOL programs were written before the era of automated,
unit-level testing, so it's extremely unlikely you've got a big
suite of tests you can run to attempt to catch such issues.

I imagine that a this results in a lot of (unnecessary)
duplication.

I have written about this many times.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <mp6kd3Fjl5nU2@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:

On 12/1/2025 4:23 PM, Dan Cross wrote:

In article <10gk6e6$1bcst$3@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

Now this is opinion, and really a poor argument. While I detest the verbosity
in most things, that is my choice, not the problem you claim.

Back on topic, COBOL is very verbose, but I also hate way too concise
languages where the language designers don't even allow words like
"function" to be spelt out in full. You read code many more times than
you write it and having cryptic syntax makes that a lot harder to achieve. >>

Excessive verbosity can be a hindrance to readability, but
finding a balance with concision is more art that science. I
don't feel the need to spell out "function" when there's an
acceptable abbreviation that means the same thing ("fn"/"fun"/
etc). That said, a lot of early Unix code that omitted vowels
for brevity was utterly abstruse.

Something like Ada was designed for readability, and I wish all other
languages followed that example.

Unfortunately, what's considered "readable" is both subjective
and depends on the audience. Personally, I don't find Ada more
readable because they it forces me to write `function` instead
of `fn` or `procedure` instead of `proc`. If anything, I find
the split between two types of subprograms less readadable, no
matter how it's presented syntacticaly. Similarly, I don't find
the use of `begin` and `end` keywords more readable than `{` and
`}`, or similar lexical glyphs. I understand that others feel
differently.

If anything, I find it less readable since it is less visually
distinct (perhaps, if I my eyesight was even worse than it
already is, I would feel differently).

Just waiting for the moment when a newcomer designs a new language which >>> has syntax resembling TECO... :-)

Or APL.

Nothing wrong with APL, if the task is within the languages domain.

Kinda ruining the joke, but....

The language itself is ok. For that matter, as a language TECO
is ok. It's the syntactic and lexical structure of both that
are an issue. Re: APL, what does the little wheel thing do
again?

But then, I am one of the last advocates for domain specific rather
than generic languages.

I don't think that's true. DSLs are more popular than ever.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/2/2025 8:50 AM, Dan Cross wrote:

In article <10gle2k$1q97g$1@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 12/1/2025 8:37 AM, Dan Cross wrote:

I've long suspected (but I admit I have no evidence to support
this) that one of the reasons there is so much COBOL code in the
world is because, when making non-trivial changes, programmers
first _copy_ large sections of the program and then modify the
copy, to avoid introducing bugs into existing functionality.

Copying and modifying code instead of creating reusable libraries
has been used by bad programmers in all languages.

I think it's a little deeper than that.

There is also something in the Cobol language.

Large files with one data division, lots of paragraphs
and lots of perform's is easy to code, but it is also
bad for reusable code.

It is sort of the same as having large C or Pascal files
with all variables global and all functions/procedures
without arguments.

It is possible to do it right, but when people have
to chose between the easy way and the right way, then ...

An issue with COBOL is that, given procedures A, B, ..., Z,
written sequentially in source, `PERFORM A THRU Z` means that it
is difficult to see when procedures B, C, ..., Y are called just
through visual inspection since calls to them are implicit; you
really need semantically aware tools to do that. So if you need
to change paragraph D, then you run the risk of implicitly
changing dependent behavior in your system unintentionally. You
might end up violating some assumption you didn't even know
existed; talk about spooky action at a distance.

That is a classical argument found on the internet.

But I am not convinced that it is critical.

It is all within one file.

$ search foobar.cob thru,through

should reveal if the feature is used.

Unless the file is very long and the code is very ugly, then
I believe it should be relative easy possible to track the
perform flow even in VT mode EDT or EVE.

Most COBOL programs were written before the era of automated,
unit-level testing, so it's extremely unlikely you've got a big
suite of tests you can run to attempt to catch such issues.

I imagine that a this results in a lot of (unnecessary)
duplication.

That may actually have a huge impact.

No unit tests is a common reason not to change any existing code.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10gks0t$1kmd0$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

[snip]
How on earth can someone not know how to divide a fraction by two ?

I think this is discarding all nuance from a complex issue.

Much of what the Atlantic article described, for instance, is
due to the lingering fallout from the pandemic: an utterly
unprecedented event in our lifetimes. Most kids entering
college now had their education (and much of their social
development) severely curtailed, due to circumstances affecting
that entire globe that were completely out of those kids'
control; or that of their parents, for that matter. To ignore
all of that and basically declare, "Americans are igorant" is,
itself, ignorant.

Oh, and the laugh was only a part of it. It was her inability to
act in a way expected of a US president. I believe the phrase I used
at the time was a lack of gravitas, plus her inability to conduct
serious interviews without collapsing into word salad.

Oh please. You regurgitated right-wing talking points at the
time, and now you bemoan that the orange stain won?

And you still did that, knowing full-well the alternative?

This is exactly the sort of shallow, smugly facile "argument"
that got the US into the mess we're in now.

It appears some people are beginning to see through Reform, and we also
have the first past the post system. I am hoping that's enough to stop
him from gaining a majority, but our traditional parties (all of them)
need to _seriously_ up their game.

The same is true in this country. The Democratic party is
failing, utterly and miserably, as an opposition party. But do
you know what does not help? Having folks across the pond lob
these little jabs at those of us who understand all too well the
dire nature of the situation. It's neither funny, when you're
in a situation where people are being yanked off the street and
disappeared into concentration camps while a non-trivial
minority of the population gleefully cheers it on, nor helpful.

It's very easy to throw stones, but not terribly advisable when
you yourself are in a glass house.

At least stop adding these things as parentheticals onto posts
that _also_ carry technical content.

Did you read the rest of the posting Dan ?

I did. And I responded. But I split my response to the
technical part of your post into another response, so as not to
conflate the two topics.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10gn0cq$2d8ve$1@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 12/2/2025 8:50 AM, Dan Cross wrote:

In article <10gle2k$1q97g$1@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 12/1/2025 8:37 AM, Dan Cross wrote:

I've long suspected (but I admit I have no evidence to support
this) that one of the reasons there is so much COBOL code in the
world is because, when making non-trivial changes, programmers
first _copy_ large sections of the program and then modify the
copy, to avoid introducing bugs into existing functionality.

Copying and modifying code instead of creating reusable libraries
has been used by bad programmers in all languages.

I think it's a little deeper than that.

There is also something in the Cobol language.

Large files with one data division, lots of paragraphs
and lots of perform's is easy to code, but it is also
bad for reusable code.

It is sort of the same as having large C or Pascal files
with all variables global and all functions/procedures
without arguments.

It is possible to do it right, but when people have
to chose between the easy way and the right way, then ...

An issue with COBOL is that, given procedures A, B, ..., Z,
written sequentially in source, `PERFORM A THRU Z` means that it
is difficult to see when procedures B, C, ..., Y are called just
through visual inspection since calls to them are implicit; you
really need semantically aware tools to do that. So if you need
to change paragraph D, then you run the risk of implicitly
changing dependent behavior in your system unintentionally. You
might end up violating some assumption you didn't even know
existed; talk about spooky action at a distance.

That is a classical argument found on the internet.

Yes. I myself have been making it for years.

But I am not convinced that it is critical.

It is all within one file.

$ search foobar.cob thru,through

should reveal if the feature is used.

Unless the file is very long and the code is very ugly, then
I believe it should be relative easy possible to track the
perform flow even in VT mode EDT or EVE.

I'm not at all convinced of that in a large code base; call
graphs resulting in such `PERFORM`s can be too big to trace by
hand. And many of these extant COBOL applications are quite
large, indeed.

Most COBOL programs were written before the era of automated,
unit-level testing, so it's extremely unlikely you've got a big
suite of tests you can run to attempt to catch such issues.

I imagine that a this results in a lot of (unnecessary)
duplication.

That may actually have a huge impact.

No unit tests is a common reason not to change any existing code.

I'm sure that it does.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/2/2025 10:46 AM, Dan Cross wrote:

In article <10gn0cq$2d8ve$1@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 12/2/2025 8:50 AM, Dan Cross wrote:

An issue with COBOL is that, given procedures A, B, ..., Z,
written sequentially in source, `PERFORM A THRU Z` means that it
is difficult to see when procedures B, C, ..., Y are called just
through visual inspection since calls to them are implicit; you
really need semantically aware tools to do that. So if you need
to change paragraph D, then you run the risk of implicitly
changing dependent behavior in your system unintentionally. You
might end up violating some assumption you didn't even know
existed; talk about spooky action at a distance.

That is a classical argument found on the internet.

Yes. I myself have been making it for years.

But I am not convinced that it is critical.

It is all within one file.

$ search foobar.cob thru,through

should reveal if the feature is used.

Unless the file is very long and the code is very ugly, then
I believe it should be relative easy possible to track the
perform flow even in VT mode EDT or EVE.

I'm not at all convinced of that in a large code base; call
graphs resulting in such `PERFORM`s can be too big to trace by
hand. And many of these extant COBOL applications are quite
large, indeed.

There are lots of hundreds of thousands or millions of lines of
code applications.

But hopefully not as single file.

:-)

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10gn29j$2d8ve$2@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 12/2/2025 10:46 AM, Dan Cross wrote:

In article <10gn0cq$2d8ve$1@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 12/2/2025 8:50 AM, Dan Cross wrote:

An issue with COBOL is that, given procedures A, B, ..., Z,
written sequentially in source, `PERFORM A THRU Z` means that it
is difficult to see when procedures B, C, ..., Y are called just
through visual inspection since calls to them are implicit; you
really need semantically aware tools to do that. So if you need
to change paragraph D, then you run the risk of implicitly
changing dependent behavior in your system unintentionally. You
might end up violating some assumption you didn't even know
existed; talk about spooky action at a distance.

That is a classical argument found on the internet.

Yes. I myself have been making it for years.

But I am not convinced that it is critical.

It is all within one file.

$ search foobar.cob thru,through

should reveal if the feature is used.

Unless the file is very long and the code is very ugly, then
I believe it should be relative easy possible to track the
perform flow even in VT mode EDT or EVE.

I'm not at all convinced of that in a large code base; call
graphs resulting in such `PERFORM`s can be too big to trace by
hand. And many of these extant COBOL applications are quite
large, indeed.

There are lots of hundreds of thousands or millions of lines of
code applications.

But hopefully not as single file.

I don't see how that's relevant. If a call comes from outside
of a file that results in that PERFORM, you've still got the
same problem. The point is, some very distant part of the
system may be relying on that implicit behavior. You really
have no way to tell.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-12-02, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <10gks0t$1kmd0$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

[snip]
How on earth can someone not know how to divide a fraction by two ?

I think this is discarding all nuance from a complex issue.

Much of what the Atlantic article described, for instance, is
due to the lingering fallout from the pandemic: an utterly
unprecedented event in our lifetimes. Most kids entering
college now had their education (and much of their social
development) severely curtailed, due to circumstances affecting
that entire globe that were completely out of those kids'
control; or that of their parents, for that matter. To ignore
all of that and basically declare, "Americans are igorant" is,
itself, ignorant.

I thought the structural problems had existed for a long time and
that the pandemic had only made more severe the structural problems
which already existed. The Atlantic article talks about the latest
decline starting about 2013.

BTW, I was interested to read about the issues and tradeoffs around
the stopping of standardised testing during the application process
in some higher education establishments a few years ago.

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

From Newsgroup: comp.os.vms

On 12/1/2025 8:49 AM, Simon Clubley wrote:

On 2025-11-29, Dave Froble <davef@tsoft-inc.com> wrote:

Sometimes things don't really change. You count to 10 the same way now as in
1960. (Trivial example)

Are you sure ? I thought maths teaching was heading in a new direction
in multiple parts of your country as shown by this example (which is way
too close to actually being realistic, especially with the "support" infrastructure from the people around the teacher):

https://www.youtube.com/watch?v=Zh3Yz3PiXZw

Now this is opinion, and really a poor argument. While I detest the verbosity
in most things, that is my choice, not the problem you claim.

Back on topic, COBOL is very verbose, but I also hate way too concise languages where the language designers don't even allow words like
"function" to be spelt out in full. You read code many more times than
you write it and having cryptic syntax makes that a lot harder to achieve.

Strongly agree ...

Something like Ada was designed for readability, and I wish all other languages followed that example.

Just waiting for the moment when a newcomer designs a new language which
has syntax resembling TECO... :-)

Save the world, shoot the idiot before it spreads ...
--
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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/3/2025 9:07 AM, Simon Clubley wrote:

BTW, I was interested to read about the issues and tradeoffs around
the stopping of standardised testing during the application process
in some higher education establishments a few years ago.

Nothing wrong with tests. They can be helpful. But let me tell you what is wrong with depending on tests. SOME PEOPLE JUST DON'T DO WELL WITH TESTS!

Case in point. My son always had problems with taking tests. I don't understand it, but that was a problem for him. Does that make him less than those who do well with tests?

Now he is a NRC licensed reactor operator at a nuclear power station. Yes, there was testing, and it was difficult for him. But testing is not how the job
is learned. People actually practiced the job under close supervision before they were trusted to do the job. Perhaps still a type of testing.

Lately, when special operations are required, He is the one called upon, because
he is trusted to perform the job correctly, over most of the other operators.

I guess what I'm trying to say is while tests can be helpful, they are not necessarily the only way of determining competence.
--
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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10h8bgq$k7on$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:

On 12/3/2025 9:07 AM, Simon Clubley wrote:

BTW, I was interested to read about the issues and tradeoffs around
the stopping of standardised testing during the application process
in some higher education establishments a few years ago.

Nothing wrong with tests. They can be helpful. But let me tell you what is >wrong with depending on tests. SOME PEOPLE JUST DON'T DO WELL WITH TESTS!

Hear, hear. Tests are _a_ way to measure progress of a group at
scale, but they're terrible for measuring individual progress.

Let's be honest: we use tests because we haven't figured out a
better way to measure relative progress across a group. But
that doesn't mean that tests are a _good_ way to go about this.

Case in point. My son always had problems with taking tests. I don't >understand it, but that was a problem for him. Does that make him less than >those who do well with tests?

Nope.

Now he is a NRC licensed reactor operator at a nuclear power station. Yes, >there was testing, and it was difficult for him. But testing is not how the job
is learned. People actually practiced the job under close supervision before >they were trusted to do the job. Perhaps still a type of testing.

Lately, when special operations are required, He is the one called upon, because
he is trusted to perform the job correctly, over most of the other operators.

Good for your son; it sounds like he's doing very well for
himself.

I guess what I'm trying to say is while tests can be helpful, they are not >necessarily the only way of determining competence.

100% this.

I served in the Marines with a bunch of folks who were
incredibly smart and talented. A lot of them didn't go to
college or get a university education; some did, but it was a
struggle. A lot overcame some seriously hard backgrounds. One
guy was probably the most intelligent people I've ever met; he
had no inclination to continue his education, as he much
preferred working with his hands (I don't know whether he went
to a trade school after the Marines, though).

Being in the same room as some of those folks was an incredibly
humbling and instructive experience about not judging people on
superficial criteria...like artificial indicators of academic
performance.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Sun, 30 Nov 2025 22:18:07 -0000 (UTC), Waldek Hebisch wrote:

Chris Townley <news@cct-net.co.uk> wrote:

On 30/11/2025 21:09, Arne Vajh|+j wrote:

The selling point is the automatic persistence of global variables:

Why would you want that?

Think database. MUMPS globals really are a non-relational database. Non-persistent database would be of limited use.

Quite easy to do in Python. Being able to implement this on top of more general underlying features is how Python is able to keep its core
language so small.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 11/11/2025 10:50 AM, Arne Vajh|+j wrote:

On 11/3/2025 8:31 AM, Simon Clubley wrote:

What are they moving to, and how are they satisfying the extremely high
constraints both on software and hardware availability, failure
detection,
and recovery that z/OS and its underlying hardware provides ?

z/OS has a unique set of capabilities when it comes to the absolutely
critical this _MUST_ continue working or the country/company dies area.

Note that even though z/OS and mainframes generally have a
good track recording regarding availability, then it is not
a magic solution - they can also have problems.

Banks having mainframe problems are rare but far from
unheard of.

And speaking of.

A lot of banking services were down Monday in Denmark.

Because a bank mainframe was down for 5 hours.

Both the company and the country survived. :-)

As often is the case the root cause was simple and
stupid. A capacity management application took away
the resources needed to process transactions.

Arne



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Wed, 17 Dec 2025 21:19:46 -0500, Arne Vajh|+j wrote:

Because a bank mainframe was down for 5 hours.

How many nines reliability are mainframes capable of?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Hi Arne
I am impressed... :_) where did you read/see this ??

On 2025-12-18, Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 11/11/2025 10:50 AM, Arne Vajh|+j wrote:

On 11/3/2025 8:31 AM, Simon Clubley wrote:

What are they moving to, and how are they satisfying the extremely high
constraints both on software and hardware availability, failure
detection,
and recovery that z/OS and its underlying hardware provides ?

z/OS has a unique set of capabilities when it comes to the absolutely
critical this _MUST_ continue working or the country/company dies area.

Note that even though z/OS and mainframes generally have a
good track recording regarding availability, then it is not
a magic solution - they can also have problems.

Banks having mainframe problems are rare but far from
unheard of.

And speaking of.

A lot of banking services were down Monday in Denmark.

Because a bank mainframe was down for 5 hours.

Both the company and the country survived. :-)

As often is the case the root cause was simple and
stupid. A capacity management application took away
the resources needed to process transactions.

Arne

--
kind regards/mvh

Niels S. Eliasen

Eliasen Consult
Oregaardsvaengevej 1
DK-4720 Pr|ast|+
Tel/Cell: +45 21779590
mailto:niels@eliasen.co
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/19/2025 6:16 AM, Niels S. Eliasen wrote:

On 2025-12-18, Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 11/11/2025 10:50 AM, Arne Vajh|+j wrote:

On 11/3/2025 8:31 AM, Simon Clubley wrote:

What are they moving to, and how are they satisfying the extremely high >>>> constraints both on software and hardware availability, failure
detection,
and recovery that z/OS and its underlying hardware provides ?

z/OS has a unique set of capabilities when it comes to the absolutely
critical this _MUST_ continue working or the country/company dies area. >>>

Note that even though z/OS and mainframes generally have a
good track recording regarding availability, then it is not
a magic solution - they can also have problems.

Banks having mainframe problems are rare but far from
unheard of.

And speaking of.

A lot of banking services were down Monday in Denmark.

Because a bank mainframe was down for 5 hours.

Both the company and the country survived. :-)

As often is the case the root cause was simple and
stupid. A capacity management application took away
the resources needed to process transactions.

I am impressed... :_) where did you read/see this ??

I saw the story on LinkedIn.

But the company has been very honest about it.

https://www.jndata.dk/driftsforstyrrelser/

<quote>
JN Data har natten igennem arbejdet p|N at finde kerne|Nrsagen til driftsudfaldet p|N vores Mainframe. De f|+rste unders|+gelser tyder p|N, at
en forkert kommando i JN Datas kapacitetsstyringsv|arkt|+j var
kerne|Nrsagen til driftsudfaldet. Den forkerte kommando bet|+d, at der
blev tildelt for lidt kapacitet til at afvikle kundernes transaktioner.
Som konsekvens deraf blev services som kreditkort samt net- og mobilbank utilg|angelige for JN Datas kunder Jyske Bank, Bankdata, BEC og Nykredit.
Vi arbejder nu videre med den bagvedliggende |Nrsag til dette for at
sikre, at en lignende fejl ikke kan opst|N fremadrettet.
</quote>

And for those that does not read Danish:

<quote>
JN Data has been working through the night to find the root cause of
the outage on our Mainframe. Initial investigations indicate that an
incorrect command in JN Data's capacity management tool was the root
cause of the outage. The incorrect command meant that too little
capacity was allocated to process customers' transactions. As a result, services such as credit cards and online and mobile banking became
unavailable for JN Data's customers Jyske Bank, Bankdata, BEC and
Nykredit. We are now working on the underlying cause of this to ensure
that a similar error cannot occur in the future.
</quote>

I think it has been in CW as well.

Arne

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 12/19/2025 8:07 AM, Arne Vajh|+j wrote:

And for those that does not read Danish:

<quote>
JN Data has been working through the night to find the root cause of
the outage on our Mainframe. Initial investigations indicate that an incorrect command in JN Data's capacity management tool was the root
cause of the outage. The incorrect command meant that too little
capacity was allocated to process customers' transactions. As a result, services such as credit cards and online and mobile banking became unavailable for JN Data's customers Jyske Bank, Bankdata, BEC and
Nykredit. We are now working on the underlying cause of this to ensure
that a similar error cannot occur in the future.
</quote>

Which is not very technical, but if I translate to VMS in
a "creative" way:

<humor>

mod produser /cpu=00:00:01 /wsmax=10 /wsext=20 /pgflq=100

nice - look at all that free CPU and memory

hmm - why are all the phones rinning?
</humor>

:-)

Arne


--- Synchronet 3.21a-Linux NewsLink 1.2