Let us assume for the time being that I have forgotten pretty much
everything I ever knew about COBOL.
Is there a better way of doing this:
inspect "Hello 123 World" tallying ws-digit-count for all
"0", "1", "2", "3", "4", "5" , "6", "7", "8", "9".
I had thought that
01 WS-DIGITS pic x(10) VALUE "0123456789".
01 WS-DIGIT-ARRAY REDEFINES WS-DIGITS.
03 WS-DIGIT PIC X OCCURS 10 TIMES.
...
inspect "Hello 123 World"
tallying ws-digit-count for all WS-DIGIT-ARRAY.
might work, but it doesn't.
The context for all this is ><https://programming-idioms.org/about#about-block-language-coverage>
where I thought I could go through and fill in some of the gaps. At the
rate I'm going the gaps aren't going to be filled soon.
Kind regards,
Bruce aka Bugmagnet
inspect "Hello 123 World"as otherwise you reference a 10 position variable instead of a single position variable.
tallying ws-digit-count for all WS-DIGIT.
My first impression (optical, haven't used tallying in many, many years) would be that you need to use:
inspect "Hello 123 World"as otherwise you reference a 10 position variable instead of a single position variable.
tallying ws-digit-count for all WS-DIGIT.
On 28/01/2021 10:35 pm, Joe wrote:
My first impression (optical, haven't used tallying in many, manyyears) would be that you need to use:
inspect "Hello 123 World"as otherwise you reference a 10 position variable instead of a single >position variable.
tallying ws-digit-count for all WS-DIGIT.
Sadly, the above gives a compiler error, viz
hello.cob:14: error: 'WS-DIGIT' requires one subscript
and having given one subscript the tallying only counts that character.
INSPECT can't tally for NUMERICs... so...
I'm not sure how it would work with a hardcoded string so I turned it into
a passed parameter:
Let us assume for the time being that I have forgotten pretty much
everything I ever knew about COBOL.
Is there a better way of doing this:
inspect "Hello 123 World" tallying ws-digit-count for all
"0", "1", "2", "3", "4", "5" , "6", "7", "8", "9".
I had thought that
01 WS-DIGITS pic x(10) VALUE "0123456789".
01 WS-DIGIT-ARRAY REDEFINES WS-DIGITS.
03 WS-DIGIT PIC X OCCURS 10 TIMES.
...
inspect "Hello 123 World"
tallying ws-digit-count for all WS-DIGIT-ARRAY. might work, but it doesn't.
The context for all this is <https://programming-idioms.org/about#about-block-language-coverage>
where I thought I could go through and fill in some of the gaps. At the
rate I'm going the gaps aren't going to be filled soon.
Kind regards,
Bruce aka Bugmagnet
PERFORM^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
VARYING ndx
FROM 1
BY 1
UNTIL ndx > function LENGTH(TestString)
On 27/01/2021 15:17, Bruce Axtens wrote:
Let us assume for the time being that I have forgotten pretty much
everything I ever knew about COBOL.
Is there a better way of doing this:
inspect "Hello 123 World" tallying ws-digit-count for all
"0", "1", "2", "3", "4", "5" , "6", "7", "8", "9".
I had thought that
01 WS-DIGITS pic x(10) VALUE "0123456789".
01 WS-DIGIT-ARRAY REDEFINES WS-DIGITS.
03 WS-DIGIT PIC X OCCURS 10 TIMES.
...
inspect "Hello 123 World"
tallying ws-digit-count for all WS-DIGIT-ARRAY.
might work, but it doesn't.
The context for all this is
<https://programming-idioms.org/about#about-block-language-coverage>
where I thought I could go through and fill in some of the gaps. At
the rate I'm going the gaps aren't going to be filled soon.
Kind regards,
Bruce aka Bugmagnet
Hi Bruce,
(BTW, thanks for mentioning the Hip Replacement article; PRIMA needs all
the help we can get at the moment... :-))
I did some experiments and decided that INSPECT is NOT the right tool
for this job in COBOL.
On 29/01/2021 10:41 am, docdwarf@panix.com wrote:
INSPECT can't tally for NUMERICs... so...
Righto.
I'm not sure how it would work with a hardcoded string so I turned it into >> a passed parameter:
Great. Thanks. Question answered.
On 1/31/21 9:54 PM, pete dashwood wrote:
On 27/01/2021 15:17, Bruce Axtens wrote:
Let us assume for the time being that I have forgotten pretty much
everything I ever knew about COBOL.
Is there a better way of doing this:
inspect "Hello 123 World" tallying ws-digit-count for all
"0", "1", "2", "3", "4", "5" , "6", "7", "8", "9".
I had thought that
01 WS-DIGITS pic x(10) VALUE "0123456789".
01 WS-DIGIT-ARRAY REDEFINES WS-DIGITS.
03 WS-DIGIT PIC X OCCURS 10 TIMES.
...
inspect "Hello 123 World"
tallying ws-digit-count for all WS-DIGIT-ARRAY.
might work, but it doesn't.
The context for all this is
<https://programming-idioms.org/about#about-block-language-coverage>
where I thought I could go through and fill in some of the gaps. At
the rate I'm going the gaps aren't going to be filled soon.
Kind regards,
Bruce aka Bugmagnet
Hi Bruce,
(BTW, thanks for mentioning the Hip Replacement article; PRIMA needs all the help we can get at the moment... :-))
I did some experiments and decided that INSPECT is NOT the right toolUnless I have badly misunderstood the desired task, I have to ask why
for this job in COBOL.
not?
IDENTIFICATION DIVISION.
PROGRAM-ID. Test-Inspect.
AUTHOR. Bill Gunshannon
INSTALLATION.
DATE-WRITTEN. 1 February 2021 ************************************************************
** Program Abstract:
** < Here should be a general description of
** the purpose/functionality of the program > ************************************************************
DATA DIVISION.
WORKING-STORAGE SECTION.
01 idx VALUE 0 PIC 9.
01 String1 PIC X(32)
VALUE "Hello World ::1234321:: Good bye".
01 Nil VALUE 0 PIC 99.
01 One VALUE 0 PIC 99.
01 Two VALUE 0 PIC 99.
01 Three VALUE 0 PIC 99.
01 Four VALUE 0 PIC 99.
01 Five VALUE 0 PIC 99.
01 Six VALUE 0 PIC 99.
01 Seven VALUE 0 PIC 99.
01 Eight VALUE 0 PIC 99.
01 Nine VALUE 0 PIC 99.
01 Total VALUE 0 PIC 99.
PROCEDURE DIVISION.
Main-Program.
INSPECT String1
TALLYING Nil FOR ALL "0"
One FOR ALL "1"
Two FOR ALL "2"
Three FOR ALL "3"
Four FOR ALL "4"
Five FOR ALL "5"
Six FOR ALL "6"
Seven FOR ALL "7"
Eight FOR ALL "8"
Nine FOR ALL "9".
DISPLAY "Nil: " Nil.
DISPLAY "One: " One.
DISPLAY "Two: " Two.
DISPLAY "Three: " Three.
DISPLAY "Four: " Four.
DISPLAY "Five: " Five.
DISPLAY "Six: " Six.
DISPLAY "Seven: " Seven.
DISPLAY "Eight: " Eight.
DISPLAY "Nine: " Nine.
INSPECT String1
TALLYING Total FOR ALL "0"
Total FOR ALL "1"
Total FOR ALL "2"
Total FOR ALL "3"
Total FOR ALL "4"
Total FOR ALL "5"
Total FOR ALL "6"
Total FOR ALL "7"
Total FOR ALL "8"
Total FOR ALL "9".
DISPLAY "TOTAL: " Total.
STOP RUN.
END-PROGRAM..
One gives you a total of all numeric characters in the string
and the other does it by individual digits. A trivial task for
COBOL.
In article <i7p8qoFde0fU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:
[snip]
PERFORM^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
VARYING ndx
FROM 1
BY 1
UNTIL ndx > function LENGTH(TestString)
This is far too droll... Mr Dashwood, that was exactly the construct I
used in my original attempt...
... but then I thought 'for this operation TestString's length cannot
change so invoking this function for every iteration will degrade efficiency...
... and every XIO will Cost Money and core's a buck a byte... so it's best
to invoke Function LENGTH once, at the top, and stuff the result into a numeric field that's most efficient (in the Oldene Dayse, COMP) for comparisons'.
(old habits and hard deaths, &c)
DD
In article <rv7mqm$k3f$1@dont-email.me>,
Bruce Axtens <snetxa@hotmail.com> wrote:
On 29/01/2021 10:41 am, docdwarf@panix.com wrote:
INSPECT can't tally for NUMERICs... so...
Righto.
I'm not sure how it would work with a hardcoded string so I turned it into >>> a passed parameter:
Great. Thanks. Question answered.
A pleasure, Mr Axtens... and a rather plain example of how responses can change when someone shows their own attempts in code instead of asking 'please do my homework/job'.
DD
On 2/02/2021 06:33, docdwarf@panix.com wrote:
In article <rv7mqm$k3f$1@dont-email.me>,This is the first message from Doc Dwarf which appears in this thread on
Bruce Axtens <snetxa@hotmail.com> wrote:
On 29/01/2021 10:41 am, docdwarf@panix.com wrote:
INSPECT can't tally for NUMERICs... so...
Righto.
I'm not sure how it would work with a hardcoded string so I turned
it into
a passed parameter:
Great. Thanks. Question answered.
A pleasure, Mr Axtens... and a rather plain example of how responses can
change when someone shows their own attempts in code instead of asking
'please do my homework/job'.
DD
my Thunderbird lists.
On 2/02/2021 06:30, docdwarf@panix.com wrote:
In article <i7p8qoFde0fU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:
[snip]
PERFORM^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
VARYING ndx
FROM 1
BY 1
UNTIL ndx > function LENGTH(TestString)
This is far too droll... Mr Dashwood, that was exactly the construct I
used in my original attempt...
... but then I thought 'for this operation TestString's length cannot
change so invoking this function for every iteration will degrade
efficiency...
... and every XIO will Cost Money and core's a buck a byte... so it's best >> to invoke Function LENGTH once, at the top, and stuff the result into a
numeric field that's most efficient (in the Oldene Dayse, COMP) for
comparisons'.
(old habits and hard deaths, &c)
DD
Hi Doc,
My Usenet reader (Thunderbird) seems to be playing up and I never saw
your original response, although I noticed that Bruce referenced it.
Thanks for your amendment; I agree 100% - loading the length once only
is much more efficient (and there was a time when I really cared about
those things.)
I believe a modern optimizing compiler would probably do this anyway,
but it is better for it to be explicit, and I should have made it so.
In my own defence, I was more concerned about getting a VM with an
unused COBOL Compiler into a place where I could run COBOL, so I could
test the code before posting here... :-) Like you say, old habits die hard.
Pete.
On 1/31/21 9:54 PM, pete dashwood wrote:
On 27/01/2021 15:17, Bruce Axtens wrote:
Let us assume for the time being that I have forgotten pretty much
everything I ever knew about COBOL.
Is there a better way of doing this:
inspect "Hello 123 World" tallying ws-digit-count for all
"0", "1", "2", "3", "4", "5" , "6", "7", "8", "9".
I had thought that
01 WS-DIGITS pic x(10) VALUE "0123456789".
01 WS-DIGIT-ARRAY REDEFINES WS-DIGITS.
03 WS-DIGIT PIC X OCCURS 10 TIMES.
...
inspect "Hello 123 World"
tallying ws-digit-count for all WS-DIGIT-ARRAY.
might work, but it doesn't.
The context for all this is
<https://programming-idioms.org/about#about-block-language-coverage>
where I thought I could go through and fill in some of the gaps. At
the rate I'm going the gaps aren't going to be filled soon.
Kind regards,
Bruce aka Bugmagnet
Hi Bruce,
(BTW, thanks for mentioning the Hip Replacement article; PRIMA needs
all the help we can get at the moment... :-))
I did some experiments and decided that INSPECT is NOT the right tool
for this job in COBOL.
Unless I have badly misunderstood the desired task, I have to ask why
not?
IDENTIFICATION DIVISION.
PROGRAM-ID. Test-Inspect.
AUTHOR. Bill Gunshannon
INSTALLATION.
DATE-WRITTEN. 1 February 2021
************************************************************
** Program Abstract:
** < Here should be a general description of
** the purpose/functionality of the program >
************************************************************
DATA DIVISION.
WORKING-STORAGE SECTION.
01 idx VALUE 0 PIC 9.
01 String1 PIC X(32)
VALUE "Hello World ::1234321:: Good bye".
01 Nil VALUE 0 PIC 99.
01 One VALUE 0 PIC 99.
01 Two VALUE 0 PIC 99.
01 Three VALUE 0 PIC 99.
01 Four VALUE 0 PIC 99.
01 Five VALUE 0 PIC 99.
01 Six VALUE 0 PIC 99.
01 Seven VALUE 0 PIC 99.
01 Eight VALUE 0 PIC 99.
01 Nine VALUE 0 PIC 99.
01 Total VALUE 0 PIC 99.
PROCEDURE DIVISION.
Main-Program.
INSPECT String1
TALLYING Nil FOR ALL "0"
One FOR ALL "1"
Two FOR ALL "2"
Three FOR ALL "3"
Four FOR ALL "4"
Five FOR ALL "5"
Six FOR ALL "6"
Seven FOR ALL "7"
Eight FOR ALL "8"
Nine FOR ALL "9".
DISPLAY "Nil: " Nil.
DISPLAY "One: " One.
DISPLAY "Two: " Two.
DISPLAY "Three: " Three.
DISPLAY "Four: " Four.
DISPLAY "Five: " Five.
DISPLAY "Six: " Six.
DISPLAY "Seven: " Seven.
DISPLAY "Eight: " Eight.
DISPLAY "Nine: " Nine.
INSPECT String1
TALLYING Total FOR ALL "0"
Total FOR ALL "1"
Total FOR ALL "2"
Total FOR ALL "3"
Total FOR ALL "4"
Total FOR ALL "5"
Total FOR ALL "6"
Total FOR ALL "7"
Total FOR ALL "8"
Total FOR ALL "9".
DISPLAY "TOTAL: " Total.
STOP RUN.
END-PROGRAM.
One gives you a total of all numeric characters in the string
and the other does it by individual digits. A trivial task for
COBOL.
bill
On Tuesday, February 2, 2021 at 4:53:18 AM UTC+11, Bill Gunshannon wrote:
On 1/31/21 9:54 PM, pete dashwood wrote:.
On 27/01/2021 15:17, Bruce Axtens wrote:Unless I have badly misunderstood the desired task, I have to ask why
Let us assume for the time being that I have forgotten pretty much
everything I ever knew about COBOL.
Is there a better way of doing this:
inspect "Hello 123 World" tallying ws-digit-count for all
"0", "1", "2", "3", "4", "5" , "6", "7", "8", "9".
I had thought that
01 WS-DIGITS pic x(10) VALUE "0123456789".
01 WS-DIGIT-ARRAY REDEFINES WS-DIGITS.
03 WS-DIGIT PIC X OCCURS 10 TIMES.
...
inspect "Hello 123 World"
tallying ws-digit-count for all WS-DIGIT-ARRAY.
might work, but it doesn't.
The context for all this is
<https://programming-idioms.org/about#about-block-language-coverage>
where I thought I could go through and fill in some of the gaps. At
the rate I'm going the gaps aren't going to be filled soon.
Kind regards,
Bruce aka Bugmagnet
Hi Bruce,
(BTW, thanks for mentioning the Hip Replacement article; PRIMA needs all >>> the help we can get at the moment... :-))
I did some experiments and decided that INSPECT is NOT the right tool
for this job in COBOL.
not?
IDENTIFICATION DIVISION.
PROGRAM-ID. Test-Inspect.
AUTHOR. Bill Gunshannon
INSTALLATION.
DATE-WRITTEN. 1 February 2021
************************************************************
** Program Abstract:
** < Here should be a general description of
** the purpose/functionality of the program >
************************************************************
DATA DIVISION.
WORKING-STORAGE SECTION.
01 idx VALUE 0 PIC 9.
01 String1 PIC X(32)
VALUE "Hello World ::1234321:: Good bye".
01 Nil VALUE 0 PIC 99.
01 One VALUE 0 PIC 99.
01 Two VALUE 0 PIC 99.
01 Three VALUE 0 PIC 99.
01 Four VALUE 0 PIC 99.
01 Five VALUE 0 PIC 99.
01 Six VALUE 0 PIC 99.
01 Seven VALUE 0 PIC 99.
01 Eight VALUE 0 PIC 99.
01 Nine VALUE 0 PIC 99.
01 Total VALUE 0 PIC 99.
PROCEDURE DIVISION.
Main-Program.
INSPECT String1
TALLYING Nil FOR ALL "0"
One FOR ALL "1"
Two FOR ALL "2"
Three FOR ALL "3"
Four FOR ALL "4"
Five FOR ALL "5"
Six FOR ALL "6"
Seven FOR ALL "7"
Eight FOR ALL "8"
Nine FOR ALL "9".
DISPLAY "Nil: " Nil.
DISPLAY "One: " One.
DISPLAY "Two: " Two.
DISPLAY "Three: " Three.
DISPLAY "Four: " Four.
DISPLAY "Five: " Five.
DISPLAY "Six: " Six.
DISPLAY "Seven: " Seven.
DISPLAY "Eight: " Eight.
DISPLAY "Nine: " Nine.
INSPECT String1
TALLYING Total FOR ALL "0"
Total FOR ALL "1"
Total FOR ALL "2"
Total FOR ALL "3"
Total FOR ALL "4"
Total FOR ALL "5"
Total FOR ALL "6"
Total FOR ALL "7"
Total FOR ALL "8"
Total FOR ALL "9".
DISPLAY "TOTAL: " Total.
STOP RUN.
END-PROGRAM.
One gives you a total of all numeric characters in the string
and the other does it by individual digits. A trivial task for
COBOL.
Isn't COBOL just great when you want to write an essay ? !!
.
To tally the grand total of digits in PL/I, we'd write
.
s = translate (String1, '0000000000', '0123456789');
put (tally(s, '0');
.
which is 2 lines plus declarations for String1 and S.
.
To tally for occurrences of individual digits:
.
DECLARE String1 character(80) varying;
DECLARE Total(0:9) fixed binary;
DECLARE (I, J) fixed binary;
do I = 1 to length (String1);
do j = 0 to 9;
total(j) = tally (String1, substr('0123456789', j+1, 1) );
end;
end;
put edit ('zero', total(0), 'one', total (1), 'two', total (2), 'three', total (3),
'four', total (4), 'five', total(5), 'six', total(6), 'seven', total (7),
'eight', total (8), 'nine', total(9) ) (SKIP, A(6), F(5));
On 2/02/2021 06:33, docdwarf@panix.com wrote:
In article <rv7mqm$k3f$1@dont-email.me>,This is the first message from Doc Dwarf which appears in this thread on
Bruce Axtens <snetxa@hotmail.com> wrote:
On 29/01/2021 10:41 am, docdwarf@panix.com wrote:
INSPECT can't tally for NUMERICs... so...
Righto.
I'm not sure how it would work with a hardcoded string so I turned it into >>>> a passed parameter:
Great. Thanks. Question answered.
A pleasure, Mr Axtens... and a rather plain example of how responses can
change when someone shows their own attempts in code instead of asking
'please do my homework/job'.
my Thunderbird lists.
In article <i83eioFdiv3U1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:
On 4/02/2021 14:57, docdwarf@panix.com wrote:
[snip]
Move LS-TextParm to Fld1Hi Doc,
Move +0 to Ws-Digit-Ctr
Compute LenFld = (Length of Fld1)
Perform varying sub1 from 1 by 1
until sub1 > LenFld
If Fld1(sub1:1) Numeric
Add 1 to Ws-Digit-Ctr
End-If
End-Perform
--end quoted text
thanks for that.
It gets a bit scary when our thoughts coincide so precisely... :-)
It's all a matter of thought-control mind-beams... or so I think.
DD
In article <i80o8mFrvlmU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:
On 2/02/2021 06:33, docdwarf@panix.com wrote:
In article <rv7mqm$k3f$1@dont-email.me>,This is the first message from Doc Dwarf which appears in this thread on
Bruce Axtens <snetxa@hotmail.com> wrote:
On 29/01/2021 10:41 am, docdwarf@panix.com wrote:
INSPECT can't tally for NUMERICs... so...
Righto.
I'm not sure how it would work with a hardcoded string so I turned it into
a passed parameter:
Great. Thanks. Question answered.
A pleasure, Mr Axtens... and a rather plain example of how responses can >>> change when someone shows their own attempts in code instead of asking
'please do my homework/job'.
my Thunderbird lists.
Horrors! You missed my pitiable posting, the heart of which was:
--begin quoted text:
INSPECT can't tally for NUMERICs... so...
I'm not sure how it would work with a hardcoded string so I turned it into
a passed parameter:
Move LS-TextParm to Fld1
Move +0 to Ws-Digit-Ctr
Compute LenFld = (Length of Fld1)
Perform varying sub1 from 1 by 1
until sub1 > LenFld
If Fld1(sub1:1) Numeric
Add 1 to Ws-Digit-Ctr
End-If
End-Perform
--end quoted text
DD
On 4/02/2021 14:57, docdwarf@panix.com wrote:
Move LS-TextParm to Fld1Hi Doc,
Move +0 to Ws-Digit-Ctr
Compute LenFld = (Length of Fld1)
Perform varying sub1 from 1 by 1
until sub1 > LenFld
If Fld1(sub1:1) Numeric
Add 1 to Ws-Digit-Ctr
End-If
End-Perform
--end quoted text
thanks for that.
It gets a bit scary when our thoughts coincide so precisely... :-)
EXAMPLE 1: (This my preferred solution... just personal preference.)
In C#, using a standard Regular Expression ("\\D" which says: "match on non-digits"):
string s = TestString; //copy the test string as a work string...
// matches all non-digits, replaces them with "" and returns the length.
int digitcount = s.replaceAll("\\D", "").length()
The above leaves the count of numeric digits in the string in
"digitcount". It is kind of "cute" because it removes all the non-digits
and the remaining length is, of course, the count of all the digits... :-)
Please don't say it is hard to read; to a C# programmer it is every bit
as clear as your COBOL is... And it is ONE LINE of code. (OK, 2 if you
count the "set up"...)
EXAMPLE 2:
Even the C# example is not as simple or elegant as this streaming
example from Java:
int digitcount = TestString.chars()
.filter(Character::isDigit)
.count();
On 2/3/2021 7:12 PM, pete dashwood wrote:
EXAMPLE 1: (This my preferred solution... just personal preference.)
In C#, using a standard Regular Expression ("\\D" which says: "match
on non-digits"):
string s = TestString; //copy the test string as a work string...
// matches all non-digits, replaces them with "" and returns the length.
int digitcount = s.replaceAll("\\D", "").length()
The above leaves the count of numeric digits in the string in
"digitcount". It is kind of "cute" because it removes all the
non-digits and the remaining length is, of course, the count of all
the digits... :-)
Please don't say it is hard to read; to a C# programmer it is every
bit as clear as your COBOL is... And it is ONE LINE of code. (OK, 2 if
you count the "set up"...)
s.replaceAll("\\D", "").length()
looks like Java.
Regex.Replace(s, "\\D", "").Length
would be C#.
EXAMPLE 2:
Even the C# example is not as simple or elegant as this streaming
example from Java:
int digitcount = TestString.chars()
.filter(Character::isDigit)
.count();
You can do that in C# as:
int digitcount = TestString.ToCharArray().Where(char.IsDigit).Count()
Arne
The point here was simply to challenge the idea that COBOL is superior
for string handling. It isn't.
On 5/02/2021 13:59, Arne Vajhøj wrote:
On 2/3/2021 7:12 PM, pete dashwood wrote:
EXAMPLE 2:
Even the C# example is not as simple or elegant as this streaming
example from Java:
int digitcount = TestString.chars()
.filter(Character::isDigit)
.count();
You can do that in C# as:
int digitcount = TestString.ToCharArray().Where(char.IsDigit).Count()
Yes, but I believe that is, strictly speaking, a LINQ construct?
In article <i865l9...@mid.individual.net>,.
pete dashwood <dash...@enternet.co.nz> wrote:
[snip]
The point here was simply to challenge the idea that COBOL is superior
for string handling. It isn't.
In most classes I took string-handling was not considered a Business
Oriented function.
On Saturday, February 6, 2021 at 11:45:26 AM UTC+11, docd...@panix.com wrote: >> In article <i865l9...@mid.individual.net>,
pete dashwood <dash...@enternet.co.nz> wrote:.
[snip]
The point here was simply to challenge the idea that COBOL is superior
for string handling. It isn't.
In most classes I took string-handling was not considered a Business
Oriented function.
What?
String handling is part and parcel of "Business Oriented function".
Names, addresses, etc. are routinely handled.
In article <b4d19435-0262-4d1e-a59d-fe016e972d4an@googlegroups.com>,
Robin Vowels <robin.vowels@gmail.com> wrote:
On Saturday, February 6, 2021 at 11:45:26 AM UTC+11, docd...@panix.com wrote:
In article <i865l9...@mid.individual.net>,.
pete dashwood <dash...@enternet.co.nz> wrote:
[snip]
The point here was simply to challenge the idea that COBOL is superior >>>> for string handling. It isn't.
In most classes I took string-handling was not considered a Business
Oriented function.
What?
String handling is part and parcel of "Business Oriented function".
Names, addresses, etc. are routinely handled.
My error and apologies for what appears to be a facile overstatement.
Yes, there are facilities in COBOL that are used to handle strings, most notably MOVE, INSPECT, STRING and UNSTRING. Now think back to *when* I
was taking most classes and the associated '68 Standard compiler,
IKFCBL00.
No Function Length.
No reference modification (characters within a string could not be
accessed by offset and length) unless a REDEFINED work-area was used.
No substring functions unless a REDEFINED work-area was used.
Only the most primitive of concatenation/deconcatenation functions.
No conversions of data types except by data-area.
Folks who worked on a program to parse addresses might be familiar with
(pre '85) COBOL's limitations in string handling.
In article <i865l9Ftqe0U1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:
[snip]
The point here was simply to challenge the idea that COBOL is superior
for string handling. It isn't.
In most classes I took string-handling was not considered a Business
Oriented function.
DD
In article <i88k0dFdrj5U1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
On 2/6/21 2:47 PM, docdwarf@panix.com wrote:
In article <b4d19435-0262-4d1e-a59d-fe016e972d4an@googlegroups.com>,
Robin Vowels <robin.vowels@gmail.com> wrote:
On Saturday, February 6, 2021 at 11:45:26 AM UTC+11, docd...@panix.com wrote:
In article <i865l9...@mid.individual.net>,.
pete dashwood <dash...@enternet.co.nz> wrote:
[snip]
The point here was simply to challenge the idea that COBOL is superior >>>>> for string handling. It isn't.
In most classes I took string-handling was not considered a Business >>>> Oriented function.
What?
String handling is part and parcel of "Business Oriented function".
Names, addresses, etc. are routinely handled.
My error and apologies for what appears to be a facile overstatement.
Yes, there are facilities in COBOL that are used to handle strings, most >> notably MOVE, INSPECT, STRING and UNSTRING. Now think back to *when* I
was taking most classes and the associated '68 Standard compiler,
IKFCBL00.
No Function Length.
No reference modification (characters within a string could not be
accessed by offset and length) unless a REDEFINED work-area was used.
No substring functions unless a REDEFINED work-area was used.
Only the most primitive of concatenation/deconcatenation functions.
No conversions of data types except by data-area.
Folks who worked on a program to parse addresses might be familiar with
(pre '85) COBOL's limitations in string handling.
And the other languages of the day were better?
LISP handled strings better. ALGOL handled strings better. SNOBOL
handled strings better.
Hindsight is always 20/20.
'Use the right tool for the job' is not hindsight.
DD
On 2/6/21 2:47 PM, docdwarf@panix.com wrote:
In article <b4d19435-0262-4d1e-a59d-fe016e972d4an@googlegroups.com>,
Robin Vowels <robin.vowels@gmail.com> wrote:
On Saturday, February 6, 2021 at 11:45:26 AM UTC+11, docd...@panix.com wrote:
In article <i865l9...@mid.individual.net>,.
pete dashwood <dash...@enternet.co.nz> wrote:
[snip]
The point here was simply to challenge the idea that COBOL is superior >>>>> for string handling. It isn't.
In most classes I took string-handling was not considered a Business
Oriented function.
What?
String handling is part and parcel of "Business Oriented function".
Names, addresses, etc. are routinely handled.
My error and apologies for what appears to be a facile overstatement.
Yes, there are facilities in COBOL that are used to handle strings, most
notably MOVE, INSPECT, STRING and UNSTRING. Now think back to *when* I
was taking most classes and the associated '68 Standard compiler,
IKFCBL00.
No Function Length.
No reference modification (characters within a string could not be
accessed by offset and length) unless a REDEFINED work-area was used.
No substring functions unless a REDEFINED work-area was used.
Only the most primitive of concatenation/deconcatenation functions.
No conversions of data types except by data-area.
Folks who worked on a program to parse addresses might be familiar with
(pre '85) COBOL's limitations in string handling.
And the other languages of the day were better?
Hindsight is always 20/20.
On 6/02/2021 13:45, docdwarf@panix.com wrote:
In article <i865l9Ftqe0U1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:
[snip]
The point here was simply to challenge the idea that COBOL is superior
for string handling. It isn't.
In most classes I took string-handling was not considered a Business
Oriented function.
My contention was/is that COBOL is NOT superior at string handling,
prompted by Bill's original throwaway line about it being easy in COBOL.
(As if it were not in other languages... :-) )
docdwarf@panix.com () writes:
In article <i88k0dFdrj5U1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
On 2/6/21 2:47 PM, docdwarf@panix.com wrote:
Yes, there are facilities in COBOL that are used to handle strings, most >> >> notably MOVE, INSPECT, STRING and UNSTRING. Now think back to *when* I >> >> was taking most classes and the associated '68 Standard compiler,
IKFCBL00.
No Function Length.
No reference modification (characters within a string could not be
accessed by offset and length) unless a REDEFINED work-area was used.
No substring functions unless a REDEFINED work-area was used.
Only the most primitive of concatenation/deconcatenation functions.
No conversions of data types except by data-area.
Folks who worked on a program to parse addresses might be familiar with >> >> (pre '85) COBOL's limitations in string handling.
And the other languages of the day were better?
LISP handled strings better. ALGOL handled strings better. SNOBOL
handled strings better.
Most specifically, PL/I handled strings better. We used PL/I programs in our >mostly COBOL GL system to do that sort of thing.
On 2/6/21 2:47 PM, docd...@panix.com wrote:.
In article <b4d19435-0262-4d1e...@googlegroups.com>,
Robin Vowels <robin....@gmail.com> wrote:
On Saturday, February 6, 2021 at 11:45:26 AM UTC+11, docd...@panix.com wrote:
In article <i865l9...@mid.individual.net>,.
pete dashwood <dash...@enternet.co.nz> wrote:
[snip]
The point here was simply to challenge the idea that COBOL is superior >>>> for string handling. It isn't.
In most classes I took string-handling was not considered a Business
Oriented function.
What?
String handling is part and parcel of "Business Oriented function".
Names, addresses, etc. are routinely handled.
My error and apologies for what appears to be a facile overstatement.
Yes, there are facilities in COBOL that are used to handle strings, most notably MOVE, INSPECT, STRING and UNSTRING. Now think back to *when* I
was taking most classes and the associated '68 Standard compiler,
IKFCBL00.
No Function Length.
No reference modification (characters within a string could not be
accessed by offset and length) unless a REDEFINED work-area was used.
No substring functions unless a REDEFINED work-area was used.
Only the most primitive of concatenation/deconcatenation functions.
No conversions of data types except by data-area.
Folks who worked on a program to parse addresses might be familiar with (pre '85) COBOL's limitations in string handling.
And the other languages of the day were better?
In article <i88k0d...@mid.individual.net>,.
Bill Gunshannon <bill.gu...@gmail.com> wrote:
On 2/6/21 2:47 PM, docd...@panix.com wrote:
In article <b4d19435-0262-4d1e...@googlegroups.com>,
Robin Vowels <robin....@gmail.com> wrote:
On Saturday, February 6, 2021 at 11:45:26 AM UTC+11, docd...@panix.com wrote:
In article <i865l9...@mid.individual.net>,.
pete dashwood <dash...@enternet.co.nz> wrote:
[snip]
The point here was simply to challenge the idea that COBOL is superior >>>>> for string handling. It isn't.
In most classes I took string-handling was not considered a Business >>>> Oriented function.
What?
String handling is part and parcel of "Business Oriented function".
Names, addresses, etc. are routinely handled.
My error and apologies for what appears to be a facile overstatement.
Yes, there are facilities in COBOL that are used to handle strings, most >> notably MOVE, INSPECT, STRING and UNSTRING. Now think back to *when* I
was taking most classes and the associated '68 Standard compiler,
IKFCBL00.
No Function Length.
No reference modification (characters within a string could not be
accessed by offset and length) unless a REDEFINED work-area was used.
No substring functions unless a REDEFINED work-area was used.
Only the most primitive of concatenation/deconcatenation functions.
No conversions of data types except by data-area.
Folks who worked on a program to parse addresses might be familiar with
(pre '85) COBOL's limitations in string handling.
And the other languages of the day were better?
LISP handled strings better. ALGOL handled strings better..
SNOBOL handled strings better.
In article <i88k0dFdrj5U1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
On 2/6/21 2:47 PM, docdwarf@panix.com wrote:
In article <b4d19435-0262-4d1e-a59d-fe016e972d4an@googlegroups.com>,
Robin Vowels <robin.vowels@gmail.com> wrote:
On Saturday, February 6, 2021 at 11:45:26 AM UTC+11, docd...@panix.com wrote:
In article <i865l9...@mid.individual.net>,.
pete dashwood <dash...@enternet.co.nz> wrote:
[snip]
The point here was simply to challenge the idea that COBOL is superior >>>>>> for string handling. It isn't.
In most classes I took string-handling was not considered a Business >>>>> Oriented function.
What?
String handling is part and parcel of "Business Oriented function".
Names, addresses, etc. are routinely handled.
My error and apologies for what appears to be a facile overstatement.
Yes, there are facilities in COBOL that are used to handle strings, most >>> notably MOVE, INSPECT, STRING and UNSTRING. Now think back to *when* I
was taking most classes and the associated '68 Standard compiler,
IKFCBL00.
No Function Length.
No reference modification (characters within a string could not be
accessed by offset and length) unless a REDEFINED work-area was used.
No substring functions unless a REDEFINED work-area was used.
Only the most primitive of concatenation/deconcatenation functions.
No conversions of data types except by data-area.
Folks who worked on a program to parse addresses might be familiar with
(pre '85) COBOL's limitations in string handling.
And the other languages of the day were better?
LISP handled strings better. ALGOL handled strings better. SNOBOL
handled strings better.
Hindsight is always 20/20.
'Use the right tool for the job' is not hindsight.
docdwarf@panix.com () writes:
In article <i88k0dFdrj5U1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
On 2/6/21 2:47 PM, docdwarf@panix.com wrote:
In article <b4d19435-0262-4d1e-a59d-fe016e972d4an@googlegroups.com>,
Robin Vowels <robin.vowels@gmail.com> wrote:
On Saturday, February 6, 2021 at 11:45:26 AM UTC+11, docd...@panix.com wrote:
In article <i865l9...@mid.individual.net>,.
pete dashwood <dash...@enternet.co.nz> wrote:
[snip]
The point here was simply to challenge the idea that COBOL is superior >>>>>>> for string handling. It isn't.
In most classes I took string-handling was not considered a Business >>>>>> Oriented function.
What?
String handling is part and parcel of "Business Oriented function".
Names, addresses, etc. are routinely handled.
My error and apologies for what appears to be a facile overstatement.
Yes, there are facilities in COBOL that are used to handle strings, most >>>> notably MOVE, INSPECT, STRING and UNSTRING. Now think back to *when* I >>>> was taking most classes and the associated '68 Standard compiler,
IKFCBL00.
No Function Length.
No reference modification (characters within a string could not be
accessed by offset and length) unless a REDEFINED work-area was used.
No substring functions unless a REDEFINED work-area was used.
Only the most primitive of concatenation/deconcatenation functions.
No conversions of data types except by data-area.
Folks who worked on a program to parse addresses might be familiar with >>>> (pre '85) COBOL's limitations in string handling.
And the other languages of the day were better?
LISP handled strings better. ALGOL handled strings better. SNOBOL
handled strings better.
Most specifically, PL/I handled strings better. We used PL/I programs in our mostly COBOL GL system to do that sort of thing.
On Sunday, February 7, 2021 at 9:37:04 AM UTC+11, Bill Gunshannon wrote:
On 2/6/21 2:47 PM, docd...@panix.com wrote:.
In article <b4d19435-0262-4d1e...@googlegroups.com>,And the other languages of the day were better?
Robin Vowels <robin....@gmail.com> wrote:
On Saturday, February 6, 2021 at 11:45:26 AM UTC+11, docd...@panix.com wrote:
In article <i865l9...@mid.individual.net>,.
pete dashwood <dash...@enternet.co.nz> wrote:
[snip]
The point here was simply to challenge the idea that COBOL is superior >>>>>> for string handling. It isn't.
In most classes I took string-handling was not considered a Business >>>>> Oriented function.
What?
String handling is part and parcel of "Business Oriented function".
Names, addresses, etc. are routinely handled.
My error and apologies for what appears to be a facile overstatement.
Yes, there are facilities in COBOL that are used to handle strings, most >>> notably MOVE, INSPECT, STRING and UNSTRING. Now think back to *when* I
was taking most classes and the associated '68 Standard compiler,
IKFCBL00.
No Function Length.
No reference modification (characters within a string could not be
accessed by offset and length) unless a REDEFINED work-area was used.
No substring functions unless a REDEFINED work-area was used.
Only the most primitive of concatenation/deconcatenation functions.
No conversions of data types except by data-area.
Folks who worked on a program to parse addresses might be familiar with
(pre '85) COBOL's limitations in string handling.
Certainly. PL/I had it all.
On Sunday, February 7, 2021 at 12:15:39 PM UTC+11, docd...@panix.com wrote:
In article <i88k0d...@mid.individual.net>,
Bill Gunshannon <bill.gu...@gmail.com> wrote:
On 2/6/21 2:47 PM, docd...@panix.com wrote:
Yes, there are facilities in COBOL that are used to handle strings, most >> >> notably MOVE, INSPECT, STRING and UNSTRING. Now think back to *when* I
was taking most classes and the associated '68 Standard compiler,
IKFCBL00.
LISP handled strings better. ALGOL handled strings better..
ALGOL [60] had no strings.
On 2/6/21 8:15 PM, docdwarf@panix.com wrote:
'Use the right tool for the job' is not hindsight.
True. And it has always been my mantra. So, if your only or
even primary task is seraching strings than these other languages
might well be the best tool. But business programming involves
a bit more and COBOL still comes out as the best language to do
the job. Not only then, but even now. :-)
On Sunday, February 7, 2021 at 12:15:39 PM UTC+11, docd...@panix.com wrote:
In article <i88k0d...@mid.individual.net>,.
Bill Gunshannon <bill.gu...@gmail.com> wrote:
On 2/6/21 2:47 PM, docd...@panix.com wrote:
In article <b4d19435-0262-4d1e...@googlegroups.com>,
Robin Vowels <robin....@gmail.com> wrote:
On Saturday, February 6, 2021 at 11:45:26 AM UTC+11, docd...@panix.com wrote:
In article <i865l9...@mid.individual.net>,.
pete dashwood <dash...@enternet.co.nz> wrote:
[snip]
The point here was simply to challenge the idea that COBOL is superior >>>>>>> for string handling. It isn't.
In most classes I took string-handling was not considered a Business >>>>>> Oriented function.
What?
String handling is part and parcel of "Business Oriented function".
Names, addresses, etc. are routinely handled.
My error and apologies for what appears to be a facile overstatement.
Yes, there are facilities in COBOL that are used to handle strings, most >>>> notably MOVE, INSPECT, STRING and UNSTRING. Now think back to *when* I >>>> was taking most classes and the associated '68 Standard compiler,
IKFCBL00.
No Function Length.
No reference modification (characters within a string could not be
accessed by offset and length) unless a REDEFINED work-area was used.
No substring functions unless a REDEFINED work-area was used.
Only the most primitive of concatenation/deconcatenation functions.
No conversions of data types except by data-area.
Folks who worked on a program to parse addresses might be familiar with >>>> (pre '85) COBOL's limitations in string handling.
And the other languages of the day were better?
PL/I has always had excellent string handling.
.
LISP handled strings better. ALGOL handled strings better..
ALGOL [60] had no strings.
.
SNOBOL handled strings better.
In article <i8af4c...@mid.individual.net>,.
Bill Gunshannon <bill.gu...@gmail.com> wrote:
On 2/6/21 8:15 PM, docd...@panix.com wrote:[snip]
'Use the right tool for the job' is not hindsight.
True. And it has always been my mantra. So, if your only orSubroutines, Mr Gunshannon. A short while back Mr Svalgaard wrote a
even primary task is seraching strings than these other languages
might well be the best tool. But business programming involves
a bit more and COBOL still comes out as the best language to do
the job. Not only then, but even now. :-)
stunning collection of subroutines in COBOL, ETKPAK.ZIP (still available
at https://www.arnoldtrembley.com/prog.htm (thanks, Mr Trembley!) that allowed for all kinds of 'magic' COBOL wasn't designed for.
For example... exponents. Exponentiation isn't encountered that often in business functions
and COBOL '68 couldn't deal with them in a fashion that
would allow a 2-year programmer to handle a 3:am call. The solution was
to pass the base, the exponent and the results area to a FORTRAN
subroutine and let the Royal Tongue do with ease what the Noble Tongue had difficulty expressing.
Likewise string-manipulation. When the Standards Committee decides that something's 'too much' then data get passed in a call to STRNGIT and the
LISP that's written in deals with it.
Remember the jiggery-pokery that used to be needed to sort a table?
Until the '02 standard allowed for it <https://www.ibm.com/support/knowledgecenter/en/SS6SG3_6.3.0/pg/tasks/tptbl44.html>
there were at least a half-dozen methods I encountered to do this and the easiest was CALL WSTABSRT USING WS-SORTAB-AREA.
On 2/6/21 8:30 PM, Rich Alderson wrote:.
docd...@panix.com () writes:
In article <i88k0d...@mid.individual.net>,
Bill Gunshannon <bill.gu...@gmail.com> wrote:
On 2/6/21 2:47 PM, docd...@panix.com wrote:
In article <b4d19435-0262-4d1e...@googlegroups.com>,
Robin Vowels <robin....@gmail.com> wrote:
On Saturday, February 6, 2021 at 11:45:26 AM UTC+11, docd...@panix.com wrote:
In article <i865l9...@mid.individual.net>,.
pete dashwood <dash...@enternet.co.nz> wrote:
[snip]
The point here was simply to challenge the idea that COBOL is superior
for string handling. It isn't.
In most classes I took string-handling was not considered a Business >>>>>> Oriented function.
What?
String handling is part and parcel of "Business Oriented function". >>>>> Names, addresses, etc. are routinely handled.
My error and apologies for what appears to be a facile overstatement. >>>>
Yes, there are facilities in COBOL that are used to handle strings, most >>>> notably MOVE, INSPECT, STRING and UNSTRING. Now think back to *when* I >>>> was taking most classes and the associated '68 Standard compiler,
IKFCBL00.
No Function Length.
No reference modification (characters within a string could not be
accessed by offset and length) unless a REDEFINED work-area was used. >>>>
No substring functions unless a REDEFINED work-area was used.
Only the most primitive of concatenation/deconcatenation functions.
No conversions of data types except by data-area.
Folks who worked on a program to parse addresses might be familiar with >>>> (pre '85) COBOL's limitations in string handling.
And the other languages of the day were better?
LISP handled strings better. ALGOL handled strings better. SNOBOL
handled strings better.
Most specifically, PL/I handled strings better. We used PL/I programs in our
mostly COBOL GL system to do that sort of thing.
OK, from the Wiki (and we all know the Internet never lies)
Fortran 1954
Lisp 1956.
COBOL 1959
SNOBOL 1962
PL/I 1964
Only two came out before COBOL. Fotran had no strings, not even
true character data as we know it. :-) Lisp did, but it kinda
missed the boat on the readability requirement met by COBOL.
All the others didn't even show up until COBOL was already well
established in the fledgling Business Programming world.
And as time went by and all the languages evolved, COBOL, like
all the others, got better.
Probably the biggest argument against COBOL today is efficiency
and nobody even cares about that any more. In my early days I
used to babysit a program running nightly on an IBM 1401. It
was written in AutoCoder, not COBOL but the point is it took
about 12 hours a day to run. Written in COBOL would likely
have been closer to 24 hours a run. Today, I expect such a
program would run in seconds at best and minutes at worst on
even a PC sized machine compiled with GnuCOBOL. There really
are no valid arguments against the use of COBOL other than
politics.
bill
In article <i8af4cFoouvU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
On 2/6/21 8:15 PM, docdwarf@panix.com wrote:
[snip]
'Use the right tool for the job' is not hindsight.
True. And it has always been my mantra. So, if your only or
even primary task is seraching strings than these other languages
might well be the best tool. But business programming involves
a bit more and COBOL still comes out as the best language to do
the job. Not only then, but even now. :-)
Subroutines, Mr Gunshannon. A short while back Mr Svalgaard wrote a
stunning collection of subroutines in COBOL, ETKPAK.ZIP (still available
at https://www.arnoldtrembley.com/prog.htm (thanks, Mr Trembley!) that allowed for all kinds of 'magic' COBOL wasn't designed for.
In article <ada8fa01-2a4f-4b5f...@googlegroups.com>,
Robin Vowels <robin....@gmail.com> wrote:
ALGOL [60] had no strings.Let's be fair, please. I was using COBOL-68 as a baseline. Did ALGOL-68
have any strings?
From <http://www.rosettacode.org/wiki/Category:ALGOL_68>
In article <ada8fa01-2a4f-4b5f-8908-687327e69f16n@googlegroups.com>,
Robin Vowels <robin.vowels@gmail.com> wrote:
On Sunday, February 7, 2021 at 12:15:39 PM UTC+11, docd...@panix.com
wrote:
In article <i88k0d...@mid.individual.net>,
Bill Gunshannon <bill.gu...@gmail.com> wrote:
On 2/6/21 2:47 PM, docd...@panix.com wrote:
[snip]
strings, mostYes, there are facilities in COBOL that are used to handle
*when* Inotably MOVE, INSPECT, STRING and UNSTRING. Now think back to
compiler,was taking most classes and the associated '68 Standard
IKFCBL00.
[snip]
LISP handled strings better. ALGOL handled strings better..
ALGOL [60] had no strings.
Let's be fair, please. I was using COBOL-68 as a baseline. Did
ALGOL-68 have any strings?
Hello docdwarf!
Sunday February 07 2021 19:10, you wrote to All:
In article <ada8fa01-2a4f-4b5f-8908-687327e69f16n@googlegroups.com>,
Robin Vowels <robin.vowels@gmail.com> wrote:
On Sunday, February 7, 2021 at 12:15:39 PM UTC+11, docd...@panix.com
wrote:
In article <i88k0d...@mid.individual.net>,
Bill Gunshannon <bill.gu...@gmail.com> wrote:
On 2/6/21 2:47 PM, docd...@panix.com wrote:
[snip]
strings, mostYes, there are facilities in COBOL that are used to handle
*when* Inotably MOVE, INSPECT, STRING and UNSTRING. Now think back to
compiler,was taking most classes and the associated '68 Standard
IKFCBL00.
[snip]
LISP handled strings better. ALGOL handled strings better..
ALGOL [60] had no strings.
Let's be fair, please. I was using COBOL-68 as a baseline. Did
ALGOL-68 have any strings?
ALGOL68R yes as on ICL 2900 and 1900 kit circa 1970/80's.
On Monday, February 8, 2021 at 6:50:34 AM UTC+11, docd...@panix.com wrote:
In article <i8af4c...@mid.individual.net>,.
Bill Gunshannon <bill.gu...@gmail.com> wrote:
On 2/6/21 8:15 PM, docd...@panix.com wrote:[snip]
Subroutines, Mr Gunshannon. A short while back Mr Svalgaard wrote a'Use the right tool for the job' is not hindsight.
True. And it has always been my mantra. So, if your only or
even primary task is seraching strings than these other languages
might well be the best tool. But business programming involves
a bit more and COBOL still comes out as the best language to do
the job. Not only then, but even now. :-)
stunning collection of subroutines in COBOL, ETKPAK.ZIP (still available
at https://www.arnoldtrembley.com/prog.htm (thanks, Mr Trembley!) that
allowed for all kinds of 'magic' COBOL wasn't designed for.
For example... exponents. Exponentiation isn't encountered that often in
business functions
ummm. The formula for computing interest is involves exponentiation.
In article <da89ea86-874d-453c-8d1c-76e3cc9f6b67n@googlegroups.com>,
Robin Vowels <robin.vowels@gmail.com> wrote:
On Monday, February 8, 2021 at 6:50:34 AM UTC+11, docd...@panix.com wrote:
In article <i8af4c...@mid.individual.net>,.
Bill Gunshannon <bill.gu...@gmail.com> wrote:
On 2/6/21 8:15 PM, docd...@panix.com wrote:[snip]
Subroutines, Mr Gunshannon. A short while back Mr Svalgaard wrote a'Use the right tool for the job' is not hindsight.
True. And it has always been my mantra. So, if your only or
even primary task is seraching strings than these other languages
might well be the best tool. But business programming involves
a bit more and COBOL still comes out as the best language to do
the job. Not only then, but even now. :-)
stunning collection of subroutines in COBOL, ETKPAK.ZIP (still available >> at https://www.arnoldtrembley.com/prog.htm (thanks, Mr Trembley!) that
allowed for all kinds of 'magic' COBOL wasn't designed for.
For example... exponents. Exponentiation isn't encountered that often in >> business functions
ummm. The formula for computing interest is involves exponentiation.
Do you think that might have been a reason for there having been so many compound interest modules being written in ASM?
DD
docdwarf@panix.com () wrote:
In article <da89ea86-874d-453c-8d1c-76e3cc9f6b67n@googlegroups.com>,
Robin Vowels <robin.vowels@gmail.com> wrote:
On Monday, February 8, 2021 at 6:50:34 AM UTC+11, docd...@panix.com wrote: >> >> In article <i8af4c...@mid.individual.net>,
Bill Gunshannon <bill.gu...@gmail.com> wrote:.
On 2/6/21 8:15 PM, docd...@panix.com wrote:[snip]
Subroutines, Mr Gunshannon. A short while back Mr Svalgaard wrote a'Use the right tool for the job' is not hindsight.
True. And it has always been my mantra. So, if your only or
even primary task is seraching strings than these other languages
might well be the best tool. But business programming involves
a bit more and COBOL still comes out as the best language to do
the job. Not only then, but even now. :-)
stunning collection of subroutines in COBOL, ETKPAK.ZIP (still available >> >> at https://www.arnoldtrembley.com/prog.htm (thanks, Mr Trembley!) that
allowed for all kinds of 'magic' COBOL wasn't designed for.
For example... exponents. Exponentiation isn't encountered that often in >> >> business functions
ummm. The formula for computing interest is involves exponentiation.
Do you think that might have been a reason for there having been so many
compound interest modules being written in ASM?
Doing exponentiation in asm (assuming you mean mainframe assembler and not x86)
is going to be quite the pain in the coding hand - more so especially if you >need to branch into floating point.
I seem to recall exponentiation being available in COBOL-68 but I've no idea >whether one could use any argument other than 0.5 (SQRT) - lol
I remember having to write an assembler "helper" subroutine that would permit >cobol (likely COBOL-68) to call a Fortran routine ... I don't remember
the reason
why calling Fortran directly from COBOL was not working but inserting an >assembler
routine in the middle seemed to allow me to fiddle things appropriately.
ah, the good old days.
In article <rvsn0j$vt0$1@dont-email.me>,
Kerry Liles <kerry.liles@gmail.com> wrote:
docdwarf@panix.com () wrote:
In article <da89ea86-874d-453c-8d1c-76e3cc9f6b67n@googlegroups.com>,
Robin Vowels <robin.vowels@gmail.com> wrote:
On Monday, February 8, 2021 at 6:50:34 AM UTC+11, docd...@panix.com wrote: >>>>> In article <i8af4c...@mid.individual.net>,
Bill Gunshannon <bill.gu...@gmail.com> wrote:.
On 2/6/21 8:15 PM, docd...@panix.com wrote:[snip]
Subroutines, Mr Gunshannon. A short while back Mr Svalgaard wrote a'Use the right tool for the job' is not hindsight.
True. And it has always been my mantra. So, if your only or
even primary task is seraching strings than these other languages
might well be the best tool. But business programming involves
a bit more and COBOL still comes out as the best language to do
the job. Not only then, but even now. :-)
stunning collection of subroutines in COBOL, ETKPAK.ZIP (still available >>>>> at https://www.arnoldtrembley.com/prog.htm (thanks, Mr Trembley!) that >>>>> allowed for all kinds of 'magic' COBOL wasn't designed for.
For example... exponents. Exponentiation isn't encountered that often in >>>>> business functions
ummm. The formula for computing interest is involves exponentiation.
Do you think that might have been a reason for there having been so many >>> compound interest modules being written in ASM?
Doing exponentiation in asm (assuming you mean mainframe assembler and not x86)
is going to be quite the pain in the coding hand - more so especially if you >> need to branch into floating point.
This might be - along with invoking The Auditors - another reason why once
a compound interest module has received sign-off it Doesn't Get Touched. Ever. Period.
(it's even more fun when a business is large enough to have separate
groups of programmers with different rules and standards for hard- versus soft-linking)
I seem to recall exponentiation being available in COBOL-68 but I've no idea >> whether one could use any argument other than 0.5 (SQRT) - lol
My memory of COBOL '68 is different and a quick websearch for the Standard landed me at <https://www.livingcomputers.org/UI/UserDocs/Tops-10-v7-04/6_COBOL-68_Language_Manual.pdf>
which, when searched for SQRT, brought up the text: 'In the following example, the COBOL program CFSQRT calls the FORTRAN subprogram FSQRT to perform a square-root operation.'
Rather... arch of them to call FORTRAN for something that existed in
COBOL, eh?
I remember having to write an assembler "helper" subroutine that would permit
cobol (likely COBOL-68) to call a Fortran routine ... I don't remember
the reason
why calling Fortran directly from COBOL was not working but inserting an
assembler
routine in the middle seemed to allow me to fiddle things appropriately.
A guy I knew ran into trouble at a shop with calling a FORTRAN program
from COBOL '68, the parameters would get all mis-aligned...
... so he wrote the parms to a temp dataset and re-coded the FORTRAN to
read it.
ah, the good old days.
'Great hardships make for later entertainments.' - Aeschylus
On 2/8/21 9:03 PM, docdwarf@panix.com wrote:
In article <rvsn0j$vt0$1@dont-email.me>,
Kerry Liles <kerry.liles@gmail.com> wrote:
docdwarf@panix.com () wrote:
In article <da89ea86-874d-453c-8d1c-76e3cc9f6b67n@googlegroups.com>,
Robin Vowels <robin.vowels@gmail.com> wrote:
On Monday, February 8, 2021 at 6:50:34 AM UTC+11, docd...@panix.com wrote:Do you think that might have been a reason for there having been so many >>>> compound interest modules being written in ASM?
In article <i8af4c...@mid.individual.net>,.
Bill Gunshannon <bill.gu...@gmail.com> wrote:
On 2/6/21 8:15 PM, docd...@panix.com wrote:[snip]
Subroutines, Mr Gunshannon. A short while back Mr Svalgaard wrote a >>>>>> stunning collection of subroutines in COBOL, ETKPAK.ZIP (still available >>>>>> at https://www.arnoldtrembley.com/prog.htm (thanks, Mr Trembley!) that >>>>>> allowed for all kinds of 'magic' COBOL wasn't designed for.'Use the right tool for the job' is not hindsight.
True. And it has always been my mantra. So, if your only or
even primary task is seraching strings than these other languages >>>>>>> might well be the best tool. But business programming involves
a bit more and COBOL still comes out as the best language to do
the job. Not only then, but even now. :-)
For example... exponents. Exponentiation isn't encountered that often in >>>>>> business functions
ummm. The formula for computing interest is involves exponentiation. >>>>
Doing exponentiation in asm (assuming you mean mainframe assembler and not x86)
is going to be quite the pain in the coding hand - more so especially if you
need to branch into floating point.
This might be - along with invoking The Auditors - another reason why once >> a compound interest module has received sign-off it Doesn't Get Touched.
Ever. Period.
(it's even more fun when a business is large enough to have separate
groups of programmers with different rules and standards for hard- versus
soft-linking)
I seem to recall exponentiation being available in COBOL-68 but I've no idea
whether one could use any argument other than 0.5 (SQRT) - lol
My memory of COBOL '68 is different and a quick websearch for the Standard >> landed me at
<https://www.livingcomputers.org/UI/UserDocs/Tops-10-v7-04/6_COBOL-68_Language_Manual.pdf>which, when searched for SQRT, brought up the text: 'In the following
example, the COBOL program CFSQRT calls the FORTRAN subprogram FSQRT to
perform a square-root operation.'
Rather... arch of them to call FORTRAN for something that existed in
COBOL, eh?
Well, the section you found that in is about how to call a Fortran >subroutine, not how to do exponentiation. SQRT was just a easy target.
Para: 5.4.1 on Page 5-6 shows the Arithmetic Operators and at the bottom
of the list are two that can be used for exponentiation.
On Sunday, February 7, 2021 at 2:11:00 PM UTC-5, docd...@panix.com wrote:
In article <ada8fa01-2a4f-4b5f...@googlegroups.com>,
Robin Vowels <robin....@gmail.com> wrote:
[snip]
ALGOL [60] had no strings.Let's be fair, please. I was using COBOL-68 as a baseline. Did ALGOL-68
have any strings?
Yes, ALGOL 68 has strings.
On 2/6/21 8:30 PM, Rich Alderson wrote:
docdwarf@panix.com () writes:
In article <i88k0dFdrj5U1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
On 2/6/21 2:47 PM, docdwarf@panix.com wrote:
In article <b4d19435-0262-4d1e-a59d-fe016e972d4an@googlegroups.com>, >>>>> Robin Vowels <robin.vowels@gmail.com> wrote:
On Saturday, February 6, 2021 at 11:45:26 AM UTC+11,
docd...@panix.com wrote:
In article <i865l9...@mid.individual.net>,.
pete dashwood <dash...@enternet.co.nz> wrote:
[snip]
The point here was simply to challenge the idea that COBOL is
superior
for string handling. It isn't.
In most classes I took string-handling was not considered a Business >>>>>>> Oriented function.
What?
String handling is part and parcel of "Business Oriented function". >>>>>> Names, addresses, etc. are routinely handled.
My error and apologies for what appears to be a facile overstatement. >>>>>
Yes, there are facilities in COBOL that are used to handle strings,
most
notably MOVE, INSPECT, STRING and UNSTRING. Now think back to
*when* I
was taking most classes and the associated '68 Standard compiler,
IKFCBL00.
No Function Length.
No reference modification (characters within a string could not be
accessed by offset and length) unless a REDEFINED work-area was used. >>>>>
No substring functions unless a REDEFINED work-area was used.
Only the most primitive of concatenation/deconcatenation functions.
No conversions of data types except by data-area.
Folks who worked on a program to parse addresses might be familiar
with
(pre '85) COBOL's limitations in string handling.
And the other languages of the day were better?
LISP handled strings better. ALGOL handled strings better. SNOBOL
handled strings better.
Most specifically, PL/I handled strings better. We used PL/I programs
in our
mostly COBOL GL system to do that sort of thing.
OK, from the Wiki (and we all know the Internet never lies)
Fortran 1954
Lisp 1956
COBOL 1959
SNOBOL 1962
PL/I 1964
Only two came out before COBOL. Fotran had no strings, not even
true character data as we know it. :-)
missed the boat on the readability requirement met by COBOL.
All the others didn't even show up until COBOL was already well
established in the fledgling Business Programming world.
And as time went by and all the languages evolved, COBOL, like
all the others, got better.
Probably the biggest argument against COBOL today is efficiency
and nobody even cares about that any more.
used to babysit a program running nightly on an IBM 1401. It
was written in AutoCoder, not COBOL but the point is it took
about 12 hours a day to run. Written in COBOL would likely
have been closer to 24 hours a run. Today, I expect such a
program would run in seconds at best and minutes at worst on
even a PC sized machine compiled with GnuCOBOL. There really
are no valid arguments against the use of COBOL other than
politics.
On 2/6/21 8:15 PM, docdwarf@panix.com wrote:
In article <i88k0dFdrj5U1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
On 2/6/21 2:47 PM, docdwarf@panix.com wrote:
In article <b4d19435-0262-4d1e-a59d-fe016e972d4an@googlegroups.com>,
Robin Vowels <robin.vowels@gmail.com> wrote:
On Saturday, February 6, 2021 at 11:45:26 AM UTC+11,
docd...@panix.com wrote:
In article <i865l9...@mid.individual.net>,.
pete dashwood <dash...@enternet.co.nz> wrote:
[snip]
The point here was simply to challenge the idea that COBOL is
superior
for string handling. It isn't.
In most classes I took string-handling was not considered a Business >>>>>> Oriented function.
What?
String handling is part and parcel of "Business Oriented function".
Names, addresses, etc. are routinely handled.
My error and apologies for what appears to be a facile overstatement.
Yes, there are facilities in COBOL that are used to handle strings,
most
notably MOVE, INSPECT, STRING and UNSTRING. Now think back to *when* I >>>> was taking most classes and the associated '68 Standard compiler,
IKFCBL00.
No Function Length.
No reference modification (characters within a string could not be
accessed by offset and length) unless a REDEFINED work-area was used.
No substring functions unless a REDEFINED work-area was used.
Only the most primitive of concatenation/deconcatenation functions.
No conversions of data types except by data-area.
Folks who worked on a program to parse addresses might be familiar with >>>> (pre '85) COBOL's limitations in string handling.
And the other languages of the day were better?
LISP handled strings better. ALGOL handled strings better. SNOBOL
handled strings better.
Hindsight is always 20/20.
'Use the right tool for the job' is not hindsight.
True. And it has always been my mantra. So, if your only or
even primary task is seraching strings than these other languages
might well be the best tool. But business programming involves
a bit more and COBOL still comes out as the best language to do
the job. Not only then, but even now. :-)
bill
On Monday, February 8, 2021 at 6:50:34 AM UTC+11, docd...@panix.com wrote:
In article <i8af4c...@mid.individual.net>,.
Bill Gunshannon <bill.gu...@gmail.com> wrote:
On 2/6/21 8:15 PM, docd...@panix.com wrote:[snip]
Subroutines, Mr Gunshannon. A short while back Mr Svalgaard wrote a'Use the right tool for the job' is not hindsight.
True. And it has always been my mantra. So, if your only or
even primary task is seraching strings than these other languages
might well be the best tool. But business programming involves
a bit more and COBOL still comes out as the best language to do
the job. Not only then, but even now. :-)
stunning collection of subroutines in COBOL, ETKPAK.ZIP (still available
at https://www.arnoldtrembley.com/prog.htm (thanks, Mr Trembley!) that
allowed for all kinds of 'magic' COBOL wasn't designed for.
For example... exponents. Exponentiation isn't encountered that often in
business functions
ummm. The formula for computing interest is involves exponentiation.
.
and COBOL '68 couldn't deal with them in a fashion that
would allow a 2-year programmer to handle a 3:am call. The solution was
to pass the base, the exponent and the results area to a FORTRAN
subroutine and let the Royal Tongue do with ease what the Noble Tongue had >> difficulty expressing.
Likewise string-manipulation. When the Standards Committee decides that
something's 'too much' then data get passed in a call to STRNGIT and the
LISP that's written in deals with it.
Remember the jiggery-pokery that used to be needed to sort a table?
Until the '02 standard allowed for it
<https://www.ibm.com/support/knowledgecenter/en/SS6SG3_6.3.0/pg/tasks/tptbl44.html>
there were at least a half-dozen methods I encountered to do this and the
easiest was CALL WSTABSRT USING WS-SORTAB-AREA.
docdwarf@panix.com () wrote:
In article <da89ea86-874d-453c-8d1c-76e3cc9f6b67n@googlegroups.com>,
Robin Vowels <robin.vowels@gmail.com> wrote:
On Monday, February 8, 2021 at 6:50:34 AM UTC+11, docd...@panix.com wrote: >>>> In article <i8af4c...@mid.individual.net>,
Bill Gunshannon <bill.gu...@gmail.com> wrote:.
On 2/6/21 8:15 PM, docd...@panix.com wrote:[snip]
Subroutines, Mr Gunshannon. A short while back Mr Svalgaard wrote a'Use the right tool for the job' is not hindsight.
True. And it has always been my mantra. So, if your only or
even primary task is seraching strings than these other languages
might well be the best tool. But business programming involves
a bit more and COBOL still comes out as the best language to do
the job. Not only then, but even now. :-)
stunning collection of subroutines in COBOL, ETKPAK.ZIP (still available >>>> at https://www.arnoldtrembley.com/prog.htm (thanks, Mr Trembley!) that >>>> allowed for all kinds of 'magic' COBOL wasn't designed for.
For example... exponents. Exponentiation isn't encountered that often in >>>> business functions
ummm. The formula for computing interest is involves exponentiation.
Do you think that might have been a reason for there having been so many
compound interest modules being written in ASM?
DD
Doing exponentiation in asm (assuming you mean mainframe assembler and not x86)
is going to be quite the pain in the coding hand - more so especially if you need to branch into floating point.
I seem to recall exponentiation being available in COBOL-68 but I've no idea whether one could use any argument other than 0.5 (SQRT) - lol
I remember having to write an assembler "helper" subroutine that would permit cobol (likely COBOL-68) to call a Fortran routine ... I don't remember the reason
why calling Fortran directly from COBOL was not working but inserting an assembler
routine in the middle seemed to allow me to fiddle things appropriately.
ah, the good old days.
On Sunday, February 7, 2021 at 9:37:04 AM UTC+11, Bill Gunshannon wrote:
On 2/6/21 2:47 PM, docd...@panix.com wrote:.
In article <b4d19435-0262-4d1e...@googlegroups.com>,And the other languages of the day were better?
Robin Vowels <robin....@gmail.com> wrote:
On Saturday, February 6, 2021 at 11:45:26 AM UTC+11, docd...@panix.com wrote:
In article <i865l9...@mid.individual.net>,.
pete dashwood <dash...@enternet.co.nz> wrote:
[snip]
The point here was simply to challenge the idea that COBOL is superior >>>>>> for string handling. It isn't.
In most classes I took string-handling was not considered a Business >>>>> Oriented function.
What?
String handling is part and parcel of "Business Oriented function".
Names, addresses, etc. are routinely handled.
My error and apologies for what appears to be a facile overstatement.
Yes, there are facilities in COBOL that are used to handle strings, most >>> notably MOVE, INSPECT, STRING and UNSTRING. Now think back to *when* I
was taking most classes and the associated '68 Standard compiler,
IKFCBL00.
No Function Length.
No reference modification (characters within a string could not be
accessed by offset and length) unless a REDEFINED work-area was used.
No substring functions unless a REDEFINED work-area was used.
Only the most primitive of concatenation/deconcatenation functions.
No conversions of data types except by data-area.
Folks who worked on a program to parse addresses might be familiar with
(pre '85) COBOL's limitations in string handling.
Certainly. PL/I had it all.
On 8/02/2021 04:40, Bill Gunshannon wrote:.
On 2/6/21 8:30 PM, Rich Alderson wrote:
docd...@panix.com () writes:
In article <i88k0d...@mid.individual.net>,
Bill Gunshannon <bill.gu...@gmail.com> wrote:
On 2/6/21 2:47 PM, docd...@panix.com wrote:
In article <b4d19435-0262-4d1e...@googlegroups.com>,
Robin Vowels <robin....@gmail.com> wrote:
On Saturday, February 6, 2021 at 11:45:26 AM UTC+11,
docd...@panix.com wrote:
In article <i865l9...@mid.individual.net>,.
pete dashwood <dash...@enternet.co.nz> wrote:
[snip]
The point here was simply to challenge the idea that COBOL is >>>>>>>> superior
for string handling. It isn't.
In most classes I took string-handling was not considered a Business >>>>>>> Oriented function.
What?
String handling is part and parcel of "Business Oriented function". >>>>>> Names, addresses, etc. are routinely handled.
My error and apologies for what appears to be a facile overstatement. >>>>>
Yes, there are facilities in COBOL that are used to handle strings, >>>>> most
notably MOVE, INSPECT, STRING and UNSTRING. Now think back to
*when* I
was taking most classes and the associated '68 Standard compiler,
IKFCBL00.
No Function Length.
No reference modification (characters within a string could not be >>>>> accessed by offset and length) unless a REDEFINED work-area was used. >>>>>
No substring functions unless a REDEFINED work-area was used.
Only the most primitive of concatenation/deconcatenation functions. >>>>>
No conversions of data types except by data-area.
Folks who worked on a program to parse addresses might be familiar >>>>> with
(pre '85) COBOL's limitations in string handling.
And the other languages of the day were better?
LISP handled strings better. ALGOL handled strings better. SNOBOL
handled strings better.
Most specifically, PL/I handled strings better. We used PL/I programs
in our
mostly COBOL GL system to do that sort of thing.
OK, from the Wiki (and we all know the Internet never lies)
Fortran 1954
Lisp 1956
COBOL 1959
SNOBOL 1962
PL/I 1964
Only two came out before COBOL. Fotran had no strings, not evenSorry Bill, I can't let that pass. (I wrote Fortran as well as COBOL
true character data as we know it. :-)
while employed by Control Data Corporation).
Fortran recognized string data by putting it in quotes.
It had ONE
string function which was "concatenate". Combining strings was simple
but slicing them up was a bit more problematic.
Lisp did, but it kinda
missed the boat on the readability requirement met by COBOL.
All the others didn't even show up until COBOL was already well
established in the fledgling Business Programming world.
And as time went by and all the languages evolved, COBOL, like
all the others, got better.
Probably the biggest argument against COBOL today is efficiencyNope. Optimizing COBOL compilers ensure that COBOL competes favorably
and nobody even cares about that any more.
with other languages as far as efficiency goes. (And it is kind of
illogical to say "biggest objection" and "nobody cares about it". If
nobody cares about it, they won't object to it... :-)
The real objections are lack of Object support (most modern programmers
don't see COBOL as an OO language, even though these facilities have
been in it for some decades now...), and verbosity. It takes too long to write. Also, it doesn't handle the event-driven paradigm as well as
other modern languages. (They don't handle batch processing as well as
COBOL does, but modern systems are designed to be responsive in real
time and not require batch processing.) https://www.codenewbie.org/podcast/what-is-cobol-and-should-you-learn-it
In my early days I
used to babysit a program running nightly on an IBM 1401. ItSorry Bill, the world has simply moved on. There WAS a time when COBOL
was written in AutoCoder, not COBOL but the point is it took
about 12 hours a day to run. Written in COBOL would likely
have been closer to 24 hours a run. Today, I expect such a
program would run in seconds at best and minutes at worst on
even a PC sized machine compiled with GnuCOBOL. There really
are no valid arguments against the use of COBOL other than
politics.
was a Political argument, but that is no longer true. It has simply been overtaken by events.
There are MANY good reasons why modern languages are more pertinent than COBOL and none of them are COBOL's fault. It was good at what it was
designed for, but the ways we do business now are different than they
were in the 1960s. I cover it in the podcast above. The fundamental
single factor is that networks need Objects and Layers, and modern
languages are better at doing that than COBOL is. You CAN do it in COBOL (especially if you use OO COBOL; but the COBOL community generally
rejected that and the axiomatic result is that, instead of being the top commercial programming language as it was for a couple of decades, COBOL
is fading into obscurity as more and more systems move to networks.
If you listen to the podcast and write down your arguments against
anything I said in it, I'll be happy to debate it here with you. But I'm
not going to write down what was said there as it takes too long. Just
as writing in C# is less verbose than writing in COBOL, so talking is
much quicker than writing... :-)
On Friday, February 12, 2021 at 12:09:29 PM UTC+11, dash...@enternet.co.nz wrote:
On 8/02/2021 04:40, Bill Gunshannon wrote:.
On 2/6/21 8:30 PM, Rich Alderson wrote:Sorry Bill, I can't let that pass. (I wrote Fortran as well as COBOL
docd...@panix.com () writes:
In article <i88k0d...@mid.individual.net>,
Bill Gunshannon <bill.gu...@gmail.com> wrote:
On 2/6/21 2:47 PM, docd...@panix.com wrote:
In article <b4d19435-0262-4d1e...@googlegroups.com>,
Robin Vowels <robin....@gmail.com> wrote:
On Saturday, February 6, 2021 at 11:45:26 AM UTC+11,
docd...@panix.com wrote:
In article <i865l9...@mid.individual.net>,.
pete dashwood <dash...@enternet.co.nz> wrote:
[snip]
The point here was simply to challenge the idea that COBOL is >>>>>>>>>> superior
for string handling. It isn't.
In most classes I took string-handling was not considered a Business >>>>>>>>> Oriented function.
What?
String handling is part and parcel of "Business Oriented function". >>>>>>>> Names, addresses, etc. are routinely handled.
My error and apologies for what appears to be a facile overstatement. >>>>>>>
Yes, there are facilities in COBOL that are used to handle strings, >>>>>>> most
notably MOVE, INSPECT, STRING and UNSTRING. Now think back to
*when* I
was taking most classes and the associated '68 Standard compiler, >>>>>>> IKFCBL00.
No Function Length.
No reference modification (characters within a string could not be >>>>>>> accessed by offset and length) unless a REDEFINED work-area was used. >>>>>>>
No substring functions unless a REDEFINED work-area was used.
Only the most primitive of concatenation/deconcatenation functions. >>>>>>>
No conversions of data types except by data-area.
Folks who worked on a program to parse addresses might be familiar >>>>>>> with
(pre '85) COBOL's limitations in string handling.
And the other languages of the day were better?
LISP handled strings better. ALGOL handled strings better. SNOBOL
handled strings better.
Most specifically, PL/I handled strings better. We used PL/I programs
in our
mostly COBOL GL system to do that sort of thing.
OK, from the Wiki (and we all know the Internet never lies)
Fortran 1954
Lisp 1956
COBOL 1959
SNOBOL 1962
PL/I 1964
Only two came out before COBOL. Fotran had no strings, not even
true character data as we know it. :-)
while employed by Control Data Corporation).
Fortran recognized string data by putting it in quotes.
Until F77, standard FORTRAN had only Hollerith constants and it could
read and write characters only into/from integer / real / complex
variables. There were no character variables. And no strings.
.
Before F77, some non-standard implementations did have CHARACTER
variables.
I believe REAL programmers are polyglot, and that includes COBOL.Whew, so I'm a real programmer after all. I'm not doing ALL the
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 55:54:31 |
| Calls: | 6,651 |
| Calls today: | 3 |
| Files: | 12,200 |
| Messages: | 5,330,761 |