I am writing something at the moment that has to process COBOL source.
It parses statements across lines into words and then looks at the
relative positions of Keywords, quotes, and noise to determine whether something is of interest to the process going on.
There's too much to go into here but the above is the gist of it.
One of the critical factors is the the detection and placement of the
word "TO" in a given COBOL statement.
I thought I had this covered but I realized that people can use "EQUAL
TO" as well as MOVE...TO, SET...TO, CONNECT... TO and GO TO...
This got me to reminiscing and I could not recall a single instance, in
50 years of looking at COBOL, where somebody wrote:
"A EQUAL TO B" or even, "A EQUALS B"
Everybody seems to use " = ".
Most people would rather write less than more...
I'm trying to persuade myself that I don't need to trap it because it
isn't worth the effort... (the old: "Where do I draw the line at error trapping?" conundrum...) I would need to make this a special exception
and treat it as a special case. That means adding code (complexity) to something that is already complex... (Although it ISN'T an error as far
as COBOL is concerned, I am using the TO for a specific purpose and this would be an exception for my code.)
I just wondered if anybody here HABITUALLY uses EQUAL TO in preference
to = ?
On 5/15/2017 5:42 AM, pete dashwood wrote:
(Although it ISN'T an error as far
as COBOL is concerned, I am using the TO for a specific purpose and this
would be an exception for my code.)
I just wondered if anybody here HABITUALLY uses EQUAL TO in preference
to = ?
While I have never used EQUAL TO that I can remember, I did work
somewhere once ( a long time ago) where "=" was frowned on (read
not allowed by local standards) and we used EQUAL.
I just wondered if anybody here HABITUALLY uses EQUAL TO in preference
to = ?
I am writing something at the moment that has to process COBOL source.
It parses statements across lines into words and then looks at the
relative positions of Keywords, quotes, and noise to determine whether >something is of interest to the process going on.
There's too much to go into here but the above is the gist of it.
One of the critical factors is the the detection and placement of the
word "TO" in a given COBOL statement.
I thought I had this covered but I realized that people can use "EQUAL
TO" as well as MOVE...TO, SET...TO, CONNECT... TO and GO TO...
This got me to reminiscing and I could not recall a single instance, in
50 years of looking at COBOL, where somebody wrote:
"A EQUAL TO B" or even, "A EQUALS B"
Everybody seems to use " = ".
Most people would rather write less than more...
I'm trying to persuade myself that I don't need to trap it because it
isn't worth the effort... (the old: "Where do I draw the line at error >trapping?" conundrum...) I would need to make this a special exception
and treat it as a special case. That means adding code (complexity) to >something that is already complex... (Although it ISN'T an error as far
as COBOL is concerned, I am using the TO for a specific purpose and this >would be an exception for my code.)
I just wondered if anybody here HABITUALLY uses EQUAL TO in preference
to = ?
This got me to reminiscing and I could not recall a single instance, in
50 years of looking at COBOL, where somebody wrote:
"A EQUAL TO B" or even, "A EQUALS B"
I just wondered if anybody here HABITUALLY uses EQUAL TO in preference
to = ?
On Mon, 15 May 2017 21:42:04 +1200, pete dashwood
<dashwood@enternet.co.nz> wrote:
I am writing something at the moment that has to process COBOL source.
(snip)
I just wondered if anybody here HABITUALLY uses EQUAL TO in preference
to = ?
I suspect a main driver was the existence of print trains that didn't
have some of the special characters. For example, =, <, and > were
omitted from many of the fast 1403 trains/chains (AN, HN).
Omission of those characters from keypunch machines was probably an
issue too.
That being said, I do see it occasionally.
On 5/15/2017 9:49 AM, Robert Wessel wrote:
On Mon, 15 May 2017 21:42:04 +1200, pete dashwood
<dashwood@enternet.co.nz> wrote:
I am writing something at the moment that has to process COBOL source.
(snip)
I just wondered if anybody here HABITUALLY uses EQUAL TO in preference
to = ?
I suspect a main driver was the existence of print trains that didn't
have some of the special characters. For example, =, <, and > were
omitted from many of the fast 1403 trains/chains (AN, HN).
Omission of those characters from keypunch machines was probably an
issue too.
That being said, I do see it occasionally.
I used to write IS EQUAL TO (or simply EQUALS) for that exact reason on
an IBM Series/1 in the early 1980's. The band broke on our printer, and
we had to wait for several weeks to get the part replaced. In the
meantime IBM installed a replacement band that had a much more limited >character set. As I recall it was missing all of the following signs:
= > < ( ) + -
On Wed, 17 May 2017 00:09:08 -0500, Arnold Trembley
<arnold.....@att.net> wrote:
On 5/15/2017 9:49 AM, Robert Wessel wrote:
On Mon, 15 May 2017 21:42:04 +1200, pete dashwood
<dash....@enternet.co.nz> wrote:
I am writing something at the moment that has to process COBOL source. >>>
(snip)
I just wondered if anybody here HABITUALLY uses EQUAL TO in preference >>> to = ?
I suspect a main driver was the existence of print trains that didn't
have some of the special characters. For example, =, <, and > were
omitted from many of the fast 1403 trains/chains (AN, HN).
Omission of those characters from keypunch machines was probably an
issue too.
That being said, I do see it occasionally.
I used to write IS EQUAL TO (or simply EQUALS) for that exact reason on
an IBM Series/1 in the early 1980's. The band broke on our printer, and >we had to wait for several weeks to get the part replaced. In the >meantime IBM installed a replacement band that had a much more limited >character set. As I recall it was missing all of the following signs:
= > < ( ) + -
The relationals were missing on many/most fast trains (all those not
intended to support programming), and the parenthesis were often
missing as well (although less commonly than the relationals). The
plus and minus, OTOH, were on almost all trains, since negative
amounts are a pretty common thing to print. Which is not to say such
trains didn't exist, take the 40-character XN* train, for example, but
then you were limited to the 36 letters and digits, plus comma, period
dollar and asterisk.
On 5/15/2017 5:42 AM, pete dashwood wrote:
I am writing something at the moment that has to process COBOL source.
It parses statements across lines into words and then looks at the
relative positions of Keywords, quotes, and noise to determine whether
something is of interest to the process going on.
There's too much to go into here but the above is the gist of it.
One of the critical factors is the the detection and placement of the
word "TO" in a given COBOL statement.
I thought I had this covered but I realized that people can use "EQUAL
TO" as well as MOVE...TO, SET...TO, CONNECT... TO and GO TO...
This got me to reminiscing and I could not recall a single instance, in
50 years of looking at COBOL, where somebody wrote:
"A EQUAL TO B" or even, "A EQUALS B"
Everybody seems to use " = ".
Most people would rather write less than more...
I'm trying to persuade myself that I don't need to trap it because it
isn't worth the effort... (the old: "Where do I draw the line at error
trapping?" conundrum...) I would need to make this a special exception
and treat it as a special case. That means adding code (complexity) to
something that is already complex... (Although it ISN'T an error as far
as COBOL is concerned, I am using the TO for a specific purpose and this
would be an exception for my code.)
I just wondered if anybody here HABITUALLY uses EQUAL TO in preference
to = ?
While I have never used EQUAL TO that I can remember, I did work
somewhere once ( a long time ago) where "=" was frowned on (read
not allowed by local standards) and we used EQUAL. I think it was
in support of the notion that COBOL was to be read like English
statements.
bill
In article <enth46F338vU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
On 5/15/2017 5:42 AM, pete dashwood wrote:
[snip]
(Although it ISN'T an error as far
as COBOL is concerned, I am using the TO for a specific purpose and this >>> would be an exception for my code.)
I just wondered if anybody here HABITUALLY uses EQUAL TO in preference
to = ?
While I have never used EQUAL TO that I can remember, I did work
somewhere once ( a long time ago) where "=" was frowned on (read
not allowed by local standards) and we used EQUAL.
My experience is similar to Mr Gunshannon's. Just as a matter of elegance '=' conveys as much information as 'IS EQUAL TO' in ten fewer keystrokes
but I've worked on sites that had a Do Unnecessary Work phase... they
usually had a lot of PICTURE IS, too.
DD
Hello pete!
Monday May 15 2017 10:42, pete dashwood wrote to All:
> I just wondered if anybody here HABITUALLY uses EQUAL TO in preference
> to = ?
I don't but have a lot of programs in ACAS written from the 60's onwards
that do. If I have to do any mods to them I do change it but still lots
left.
Same does apply to other long winded variants eg IS EQUAL OR GREATER THAN etc.
End of the day, 'TO' is a noise word if only looking for primary reserved words there are others :)
I bypass them for my tools such as cobxref and in the example you give as they are all reserved words I treat the same as I only look for non
reserved words and where they are in program (e.g., division & section
etc).
Vince
I still come across it regularly. Although I wore a pretty print that takesit out.
I tend to avoid the superfluous use of comma, too.
On Mon, 15 May 2017 21:42:04 +1200, pete dashwood
<dashwood@enternet.co.nz> wrote:
I am writing something at the moment that has to process COBOL source.
It parses statements across lines into words and then looks at the
relative positions of Keywords, quotes, and noise to determine whether
something is of interest to the process going on.
There's too much to go into here but the above is the gist of it.
One of the critical factors is the the detection and placement of the
word "TO" in a given COBOL statement.
I thought I had this covered but I realized that people can use "EQUAL
TO" as well as MOVE...TO, SET...TO, CONNECT... TO and GO TO...
This got me to reminiscing and I could not recall a single instance, in
50 years of looking at COBOL, where somebody wrote:
"A EQUAL TO B" or even, "A EQUALS B"
Everybody seems to use " = ".
Most people would rather write less than more...
I'm trying to persuade myself that I don't need to trap it because it
isn't worth the effort... (the old: "Where do I draw the line at error
trapping?" conundrum...) I would need to make this a special exception
and treat it as a special case. That means adding code (complexity) to
something that is already complex... (Although it ISN'T an error as far
as COBOL is concerned, I am using the TO for a specific purpose and this
would be an exception for my code.)
I just wondered if anybody here HABITUALLY uses EQUAL TO in preference
to = ?
I suspect a main driver was the existence of print trains that didn't
have some of the special characters. For example, =, <, and > were
omitted from many of the fast 1403 trains/chains (AN, HN).
Omission of those characters from keypunch machines was probably an
issue too.
That being said, I do see it occasionally.
On 5/15/2017 9:49 AM, Robert Wessel wrote:
On Mon, 15 May 2017 21:42:04 +1200, pete dashwood
<dashwood@enternet.co.nz> wrote:
I am writing something at the moment that has to process COBOL source.
(snip) I just wondered if anybody here HABITUALLY uses EQUAL TO in
preference
to = ?
I suspect a main driver was the existence of print trains that didn't
have some of the special characters. For example, =, <, and > were
omitted from many of the fast 1403 trains/chains (AN, HN).
Omission of those characters from keypunch machines was probably an
issue too.
That being said, I do see it occasionally.
I used to write IS EQUAL TO (or simply EQUALS) for that exact reason on
an IBM Series/1 in the early 1980's. The band broke on our printer, and
we had to wait for several weeks to get the part replaced. In the
meantime IBM installed a replacement band that had a much more limited character set. As I recall it was missing all of the following signs:
= > < ( ) + -
Back in those days we still relied on printed compiler listings for documentation and they were extremely difficult to read without those symbols.
That being said, I do see it occasionally.I used to write IS EQUAL TO (or simply EQUALS) for that exact reason on
an IBM Series/1 in the early 1980's. The band broke on our printer, and
we had to wait for several weeks to get the part replaced. In the
meantime IBM installed a replacement band that had a much more limited
character set. As I recall it was missing all of the following signs:
= > < ( ) + -
The relationals were missing on many/most fast trains (all those not
intended to support programming), and the parenthesis were often
missing as well (although less commonly than the relationals). The
plus and minus, OTOH, were on almost all trains, since negative
amounts are a pretty common thing to print. Which is not to say such
trains didn't exist, take the 40-character XN* train, for example, but
On Monday, May 15, 2017 at 5:42:10 AM UTC-4, pete dashwood wrote:
[snip]
This got me to reminiscing and I could not recall a single instance, in
50 years of looking at COBOL, where somebody wrote:
"A EQUAL TO B" or even, "A EQUALS B"
From your thread, in February, "Simplifying IFs in COBOL".
< https://groups.google.com/d/msg/comp.lang.cobol/SjLGh9i5nRs/G7pdZTqlBgAJ > -----
Pete's exactly-disliked nested-IF:
IF A EQUAL TO B
IF A EQUAL TO C
-----
[snip]
I just wondered if anybody here HABITUALLY uses EQUAL TO in preference
to = ?
Perhaps Mr Woodger?
I saw a lot of "IS EQUAL TO" in the 70s and I may have
used it a few times myself, before switching to COBOL
on PCs.
There was, until the 90s, a US government FIPS requirement,
which, at the low level, prohibited the use of ">", "<",
"=" and "OR" in relational expressions.
Any programmer who had to code to the low-level FIPS
requirement would have quickly adapted and, perhaps,
continued to write code consistent with that requirement.
In other words, "habituation"!
I am writing something at the moment that has to process COBOL source.Many thanks to all who responded.
It parses statements across lines into words and then looks at the
relative positions of Keywords, quotes, and noise to determine whether something is of interest to the process going on.
There's too much to go into here but the above is the gist of it.
One of the critical factors is the the detection and placement of the
word "TO" in a given COBOL statement.
I thought I had this covered but I realized that people can use "EQUAL
TO" as well as MOVE...TO, SET...TO, CONNECT... TO and GO TO...
This got me to reminiscing and I could not recall a single instance, in
50 years of looking at COBOL, where somebody wrote:
"A EQUAL TO B" or even, "A EQUALS B"
Everybody seems to use " = ".
Most people would rather write less than more...
I'm trying to persuade myself that I don't need to trap it because it
isn't worth the effort... (the old: "Where do I draw the line at error trapping?" conundrum...) I would need to make this a special exception
and treat it as a special case. That means adding code (complexity) to something that is already complex... (Although it ISN'T an error as far
as COBOL is concerned, I am using the TO for a specific purpose and this would be an exception for my code.)
I just wondered if anybody here HABITUALLY uses EQUAL TO in preference
to = ?
Pete.
snipMany thanks to all who responded.
It looks like I don't need to worry about it but there is a part of my
brain that will nag me until I make it "watertight"... :-)
Pete.
On Sun, 21 May 2017 01:14:46 +1200, pete dashwood
<dashwood@enternet.co.nz> wrote:
snipMany thanks to all who responded.
It looks like I don't need to worry about it but there is a part of my >>brain that will nag me until I make it "watertight"... :-)
Is "TO" a noise word in all cases other than the construct ADD A B TO
C D?
On 15/05/17 11:47 PM, docdwarf@panix.com wrote:
My experience is similar to Mr Gunshannon's. Just as a matter of elegance >> '=' conveys as much information as 'IS EQUAL TO' in ten fewer keystrokesThanks Doc.
but I've worked on sites that had a Do Unnecessary Work phase... they
usually had a lot of PICTURE IS, too.
Funny you should mention the old noise word "IS"...
Did you know there was
a Burroughs compiler that allowed "PC" as an abbreviation for "PICTURE"?
On 17/05/17 5:09 PM, Arnold Trembley wrote:
I used to write IS EQUAL TO (or simply EQUALS) for that exact reason onThanks for the response. I don't think 1980 print trains are pertinent
an IBM Series/1 in the early 1980's. The band broke on our printer, and
we had to wait for several weeks to get the part replaced. In the
meantime IBM installed a replacement band that had a much more limited
character set. As I recall it was missing all of the following signs:
= > < ( ) + -
Back in those days we still relied on printed compiler listings for
documentation and they were extremely difficult to read without those
symbols.
to my code, but they certainly are good background as to why people
might use the full words rather than the symbols.
I just wondered if anybody here HABITUALLY uses EQUAL TO in preference
to = ?
On 17/05/17 5:09 PM, Arnold Trembley wrote:
On 5/15/2017 9:49 AM, Robert Wessel wrote:Thanks for the response. I don't think 1980 print trains are pertinent
On Mon, 15 May 2017 21:42:04 +1200, pete dashwood
<dashwood@enternet.co.nz> wrote:
I am writing something at the moment that has to process COBOL
source.
(snip) I just wondered if anybody here HABITUALLY uses EQUAL TO in
preference to = ?
I suspect a main driver was the existence of print trains that
didn't have some of the special characters. For example, =, <, and
were omitted from many of the fast 1403 trains/chains (AN, HN).
Omission of those characters from keypunch machines was probably an
issue too.
That being said, I do see it occasionally.
I used to write IS EQUAL TO (or simply EQUALS) for that exact reason
on an IBM Series/1 in the early 1980's. The band broke on our
printer, and we had to wait for several weeks to get the part
replaced. In the meantime IBM installed a replacement band that had
a much more limited character set. As I recall it was missing all
of the following signs: = > < ( ) + -
Back in those days we still relied on printed compiler listings for
documentation and they were extremely difficult to read without
those symbols.
to my code, but they certainly are good background as to why people
might use the full words rather than the symbols.
Hello pete!
Saturday May 20 2017 14:01, pete dashwood wrote to All:
On 17/05/17 5:09 PM, Arnold Trembley wrote:
On 5/15/2017 9:49 AM, Robert Wessel wrote:Thanks for the response. I don't think 1980 print trains are pertinent
On Mon, 15 May 2017 21:42:04 +1200, pete dashwood
<dashwood@enternet.co.nz> wrote:
I am writing something at the moment that has to process COBOL
source.
(snip) I just wondered if anybody here HABITUALLY uses EQUAL TO in
preference to = ?
I suspect a main driver was the existence of print trains that
didn't have some of the special characters. For example, =, <, and
were omitted from many of the fast 1403 trains/chains (AN, HN).
Omission of those characters from keypunch machines was probably an
issue too.
That being said, I do see it occasionally.
I used to write IS EQUAL TO (or simply EQUALS) for that exact reason
on an IBM Series/1 in the early 1980's. The band broke on our
printer, and we had to wait for several weeks to get the part
replaced. In the meantime IBM installed a replacement band that had
a much more limited character set. As I recall it was missing all
of the following signs: = > < ( ) + -
Back in those days we still relied on printed compiler listings for
documentation and they were extremely difficult to read without
those symbols.
to my code, but they certainly are good background as to why people
might use the full words rather than the symbols.
Must admit I do not recall that as a problem on both ICL and IBM kit.
May be the sites I worked at, spent extra to get the full char set chains
but many had more than one printer on a system?
There again I might be forgetful in this matter.. been a long tome ago :)
As for a reason not to do it - If the punch card service was slow for my >needs (Often) I would go and use a spare machine and key them in myself and >using the abbreviations was a lot less keying :)
I am writing something at the moment that has to process COBOL source.
It parses statements across lines into words and then looks at the
relative positions of Keywords, quotes, and noise to determine whether something is of interest to the process going on.
There's too much to go into here but the above is the gist of it.
One of the critical factors is the the detection and placement of the
word "TO" in a given COBOL statement.
I thought I had this covered but I realized that people can use "EQUAL
TO" as well as MOVE...TO, SET...TO, CONNECT... TO and GO TO...
This got me to reminiscing and I could not recall a single instance, in
50 years of looking at COBOL, where somebody wrote:
"A EQUAL TO B" or even, "A EQUALS B"
Everybody seems to use " = ".
Most people would rather write less than more...
I'm trying to persuade myself that I don't need to trap it because it
isn't worth the effort... (the old: "Where do I draw the line at error trapping?" conundrum...) I would need to make this a special exception
and treat it as a special case. That means adding code (complexity) to something that is already complex... (Although it ISN'T an error as far
as COBOL is concerned, I am using the TO for a specific purpose and this would be an exception for my code.)
I just wondered if anybody here HABITUALLY uses EQUAL TO in preference
to = ?
Pete.
--
I used to write COBOL; now I can do anything...
Hello pete!
Saturday May 20 2017 14:01, pete dashwood wrote to All:
> On 17/05/17 5:09 PM, Arnold Trembley wrote:
>> On 5/15/2017 9:49 AM, Robert Wessel wrote:
>>> On Mon, 15 May 2017 21:42:04 +1200, pete dashwood
>>> <dashwood@enternet.co.nz> wrote:
>>>
>>>> I am writing something at the moment that has to process COBOL
>>>> source.
>>>>
>>>> (snip) I just wondered if anybody here HABITUALLY uses EQUAL TO in
>>>> preference to = ?
>>>
>>>
>>> I suspect a main driver was the existence of print trains that
>>> didn't have some of the special characters. For example, =, <, and
>>> > were omitted from many of the fast 1403 trains/chains (AN, HN).
>>>
>>> Omission of those characters from keypunch machines was probably an
>>> issue too.
>>>
>>> That being said, I do see it occasionally.
>>>
>>
>> I used to write IS EQUAL TO (or simply EQUALS) for that exact reason
>> on an IBM Series/1 in the early 1980's. The band broke on our
>> printer, and we had to wait for several weeks to get the part
>> replaced. In the meantime IBM installed a replacement band that had
>> a much more limited character set. As I recall it was missing all
>> of the following signs: = > < ( ) + -
>>
>> Back in those days we still relied on printed compiler listings for
>> documentation and they were extremely difficult to read without
>> those symbols.
>>
>>
>>
>>
>>
> Thanks for the response. I don't think 1980 print trains are pertinent
> to my code, but they certainly are good background as to why people
> might use the full words rather than the symbols.
Must admit I do not recall that as a problem on both ICL and IBM kit.
May be the sites I worked at, spent extra to get the full char set chains
but many had more than one printer on a system?
There again I might be forgetful in this matter.. been a long tome ago :)
As for a reason not to do it - If the punch card service was slow for my needs (Often) I would go and use a spare machine and key them in myself and using the abbreviations was a lot less keying :)
Same applied if I used the paper tape punch and in both cases for very
small number of changes it was done on a portable punch and it was not that long ago that I can across my one still sitting in a box in my study. Don't know what happened to the card punch machine but it was a little larger and heavier.
Going back to the usage of the comma and the end of a sub clause/s - I was NEVER a user of such as it was sometimes very difficult to tel them apart
on listings and if some errant card punch operator mis-keyed you could
spend hours/days looking for why the program was not working as expected - just because of a period incorrectly typed.
On the job form that was supplied with the Cobol source forms I used, I do seem to recall that mine always had the message that there was NO COMMA'S
in this program along with the coding style used - (see next para). Just to try and make sure they did not mis-key, which was not often at all.
Oh, and all periods written on forms had a circle around them like wise
zero or was it 'O' had a slash thru it to signify that it was one and not
the other.. Think it was the alpha O that did, with the Z having a hypen
thru and the letter 'I' being fully topped and tailed, but it is a lloonngg time ago:)
Remember everything was in UPPER CASE.
Vince
On Wed, 24 May 2017 11:37:22 +0100, "Vince Coen" <VBCoen@gmail.com>
wrote:
Hello pete!
Saturday May 20 2017 14:01, pete dashwood wrote to All:
On 17/05/17 5:09 PM, Arnold Trembley wrote:
On 5/15/2017 9:49 AM, Robert Wessel wrote:Thanks for the response. I don't think 1980 print trains are pertinent
On Mon, 15 May 2017 21:42:04 +1200, pete dashwood
<dashwood@enternet.co.nz> wrote:
I am writing something at the moment that has to process COBOL
source.
(snip) I just wondered if anybody here HABITUALLY uses EQUAL TO in >>>>>> preference to = ?
I suspect a main driver was the existence of print trains that
didn't have some of the special characters. For example, =, <, and >>>>>> were omitted from many of the fast 1403 trains/chains (AN, HN).
Omission of those characters from keypunch machines was probably an
issue too.
That being said, I do see it occasionally.
I used to write IS EQUAL TO (or simply EQUALS) for that exact reason
on an IBM Series/1 in the early 1980's. The band broke on our
printer, and we had to wait for several weeks to get the part
replaced. In the meantime IBM installed a replacement band that had
a much more limited character set. As I recall it was missing all
of the following signs: = > < ( ) + -
Back in those days we still relied on printed compiler listings for
documentation and they were extremely difficult to read without
those symbols.
to my code, but they certainly are good background as to why people
might use the full words rather than the symbols.
Must admit I do not recall that as a problem on both ICL and IBM kit.
May be the sites I worked at, spent extra to get the full char set chains
but many had more than one printer on a system?
Print trains were also usually interchangeable, although operations
would usually try to batch jobs so that the number of changes was
minimized. Certainly if a shop had multiple printers you'd often see
the different trains almost always living in a particular printer,
except in the much less common case when you really had a lot of extra
work of one type (*and* the shop had an extra train of the required
type - I saw a number of shops that had (say) three printers and
exactly three print trains).
The advantage of the more constrained trains was that they printed
fasters. Going from a TN to an AN train would more than double print
speed on a 1403 - although you lost 2/3rds of the possible printable characters.
There again I might be forgetful in this matter.. been a long tome ago :)
As for a reason not to do it - If the punch card service was slow for my
needs (Often) I would go and use a spare machine and key them in myself and >> using the abbreviations was a lot less keying :)
Back in school... There was a room full of keypunches, mostly 029s,
plus a few 129s and a couple of 026s. The major downside to the 026s
(other than the somewhat inferior keyboard), was that a number of the
special characters were *not* on the keyboard (or on the printer for
the interpretation line). OTOH, the multi-punch sequences for all of
the interesting characters were taped to the front of the machine, so
it's not like they were actually hard to enter.
The 026s almost always sat idle, even if the line of people waiting
for a free keypunch machine was out the door and down the hall, just
because most people couldn't deal with the 026s. So I pretty much got
to use a keypunch machine any time I wanted, with no waiting, and
could completely ignore the "half hour" rule even when the place was
busy.
I also made a few bucks selling people programming cards for the
keypunch machines (for programming purposes, mostly nothing but some
tab stops). You'd think people in programming classes would be able
to figure out how to make an 029 program card. The lab eventually put
the drums under lock and key because people kept breaking the read
mechanism by forcing the drum in or out without releasing the locking mechanism first (although I managed to lobby them to still have them available, you just had to ask whoever was managing the lab, and
they'd ask if you knew how to mount the drum).
On Sun, 21 May 2017 01:14:46 +1200, pete dashwoodHell, no.
<dashwood@enternet.co.nz> wrote:
snipMany thanks to all who responded.
It looks like I don't need to worry about it but there is a part of my
brain that will nag me until I make it "watertight"... :-)
Is "TO" a noise word in all cases other than the construct ADD A B TO
C D?
Clark Morris
Pete.
On Monday, May 15, 2017 at 5:42:10 AM UTC-4, pete dashwood wrote:count above)
I just wondered if anybody here HABITUALLY uses EQUAL TO in preference
to = ?
Quick count in the GnuCOBOL FAQ
345 occurrences of ' equal ' (might not be all code sample occurrences)
41 occurrences of ' equal to ' (probably all code samples and included in the
17 occurrences of ' is equal to 'some 30 other language samples in that document).
6 ' is not equal to ' of which 4 are ' not equal to '
Might not be habitual, but not an unheard of development style.
That compares to 985 ' = ', 83 ' not = ' and 14 ' != ' (mixing C, COBOL and
Having given out those nerdy stats, I try and cover lots of different codingstyles in the FAQ, on purpose, to demonstrate the different options inherently available in COBOL.
Cheers,
Brian
On Monday, May 15, 2017 at 7:42:10 PM UTC+10, pete dashwood wrote:converted Cobol code and it became specific to the original code. One parses lines and has to attend to full stops over multiple lines of code.
I am writing something at the moment that has to process COBOL source.
It parses statements across lines into words and then looks at the
relative positions of Keywords, quotes, and noise to determine whether
something is of interest to the process going on.
There's too much to go into here but the above is the gist of it.
One of the critical factors is the the detection and placement of the
word "TO" in a given COBOL statement.
I thought I had this covered but I realized that people can use "EQUAL
TO" as well as MOVE...TO, SET...TO, CONNECT... TO and GO TO...
This got me to reminiscing and I could not recall a single instance, in
50 years of looking at COBOL, where somebody wrote:
"A EQUAL TO B" or even, "A EQUALS B"
Everybody seems to use " = ".
Most people would rather write less than more...
I'm trying to persuade myself that I don't need to trap it because it
isn't worth the effort... (the old: "Where do I draw the line at error
trapping?" conundrum...) I would need to make this a special exception
and treat it as a special case. That means adding code (complexity) to
something that is already complex... (Although it ISN'T an error as far
as COBOL is concerned, I am using the TO for a specific purpose and this
would be an exception for my code.)
I just wondered if anybody here HABITUALLY uses EQUAL TO in preference
to = ?
Pete.
--
I used to write COBOL; now I can do anything...
Lots of detail conversation going on here. I did a Cobol program that
My comment is that Cobol compilers do this complex parsing and it gets verycomplex for every style of expression. It reinforces my view that Cobol is a chameleon language that is highly adaptable to new environments and is under-rated in the modern world.
Greg
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 991 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 126:55:01 |
| Calls: | 12,960 |
| Calls today: | 2 |
| Files: | 186,574 |
| Messages: | 3,265,879 |