Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Lots of REXX programs were written in COBOL
35 views
Skip to first unread message
Bob Bridges
Jun 27, 2021, 3:52:23 PM6/27/21
to
Gil's post (see below) on IBM-MAIN reminds me of something I see repeatedly, code written like this:
000_MAIN:
CALL 0100_INITIALIZE
CALL 0200_PROCESS
CALL 0900_TERMINATE
EXIT
0100_INITIALIZE:
CALL 0110_OPEN_FILES
CALL 0120_INITIALIZE_VALUES
...and so on. Obviously this is a COBOL programmer thinking in COBOL.
I don't see any point in ranting against this style of coding. It obviously can run correctly, and I can't see that it'd run any slower or even be harder to understand than my style of REXX coding. I would never write that way, but then I never learned to love COBOL, despite the decade or two I spent using it (and despite its admitted strengths). Mostly when I inherit a program written like this, I sigh -- and if I have to modify it, I add code in my style, but leave the rest of the program alone.
But I'm looking at Gil's code below, and it reminds me that different REXXers have different ideas about capitalization. I've seen a good many REXX programs in which the program instructions and keywords have their initial letter capitalized:
If Pos(mystring,3,2) = "XX" Then Do...
And a few in which they're in all caps. Gil apparently uses all-caps for at least some variable names (though maybe not all; I don't know). I suspect that these folks, too, come to REXX from some other language and are, consciously or reflexively, imposing good coding standards on their REXX programs that they learned elsewhere.
But where? What language(s) are implied by the different styles of REXX code you've seen? My own repertoire is pretty limited; I don't think I've written in more than a dozen or two languages over the course of my career, and I'm dead certain from things I've read here and in IBM-MAIN that lots of you surpass that by heroic bounds.
---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313
/* What's the difference between a bad golfer and a bad skydiver?
A bad golfer goes <whack> "Damn!"
A bad skydiver goes "Damn!" <whack> */
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On Behalf Of Paul Gilmartin
Sent: Sunday, June 27, 2021 14:52
FWIW, I prefer coding
say 'Result =' RESULT
...
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
000_MAIN:
CALL 0100_INITIALIZE
CALL 0200_PROCESS
CALL 0900_TERMINATE
EXIT
0100_INITIALIZE:
CALL 0110_OPEN_FILES
CALL 0120_INITIALIZE_VALUES
...and so on. Obviously this is a COBOL programmer thinking in COBOL.
I don't see any point in ranting against this style of coding. It obviously can run correctly, and I can't see that it'd run any slower or even be harder to understand than my style of REXX coding. I would never write that way, but then I never learned to love COBOL, despite the decade or two I spent using it (and despite its admitted strengths). Mostly when I inherit a program written like this, I sigh -- and if I have to modify it, I add code in my style, but leave the rest of the program alone.
But I'm looking at Gil's code below, and it reminds me that different REXXers have different ideas about capitalization. I've seen a good many REXX programs in which the program instructions and keywords have their initial letter capitalized:
If Pos(mystring,3,2) = "XX" Then Do...
And a few in which they're in all caps. Gil apparently uses all-caps for at least some variable names (though maybe not all; I don't know). I suspect that these folks, too, come to REXX from some other language and are, consciously or reflexively, imposing good coding standards on their REXX programs that they learned elsewhere.
But where? What language(s) are implied by the different styles of REXX code you've seen? My own repertoire is pretty limited; I don't think I've written in more than a dozen or two languages over the course of my career, and I'm dead certain from things I've read here and in IBM-MAIN that lots of you surpass that by heroic bounds.
---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313
/* What's the difference between a bad golfer and a bad skydiver?
A bad golfer goes <whack> "Damn!"
A bad skydiver goes "Damn!" <whack> */
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On Behalf Of Paul Gilmartin
Sent: Sunday, June 27, 2021 14:52
FWIW, I prefer coding
say 'Result =' RESULT
...
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
Frank Clarke
Jun 27, 2021, 5:06:37 PM6/27/21
to
I hate C*B*L, too, but that technique is very useful for segmenting code down to the atomic level. There's a charming benefit to REXX code written this way, in that if you are running in interactive-TRACE mode and you "trace o" at some point, trace turns OFF within that segment and all of its children until you return to the parent segment, where interactive-TRACE will be back ON.
In this way, you can easily bypass huge parcels of code if you know the error you want to watch happen isn't within those sections.
I typically have an A_INIT module from which I handle all the front-end stuff, and as soon as it starts, I "trace o". When the next main segment starts, TRACE is active again.
The deeper you segment your code, the easier is it to debug and the easier it is to fix.https://rexxpertise.blogspot.com/2011/11/zenith-of-tracing.html
https://rexxpertise.blogspot.com/2013/10/retrospective.html
https://rexxpertise.blogspot.com/2011/11/when-trace-just-isnt-enough.html
In this way, you can easily bypass huge parcels of code if you know the error you want to watch happen isn't within those sections.
I typically have an A_INIT module from which I handle all the front-end stuff, and as soon as it starts, I "trace o". When the next main segment starts, TRACE is active again.
The deeper you segment your code, the easier is it to debug and the easier it is to fix.https://rexxpertise.blogspot.com/2011/11/zenith-of-tracing.html
https://rexxpertise.blogspot.com/2013/10/retrospective.html
https://rexxpertise.blogspot.com/2011/11/when-trace-just-isnt-enough.html
Paul Gilmartin
Jun 27, 2021, 5:18:11 PM6/27/21
to
> On 2021-06-27, at 13:52:09, Bob Bridges wrote:
>
> Gil's post (see below) on IBM-MAIN reminds me of something I see repeatedly, code written like this:
>
> 000_MAIN:
> CALL 0100_INITIALIZE
>
> Gil's post (see below) on IBM-MAIN reminds me of something I see repeatedly, code written like this:
>
> 000_MAIN:
> CALL 0100_INITIALIZE
> ...and so on. Obviously this is a COBOL programmer thinking in COBOL.
>
Eek! Or BASIC? Where line numbers were also GOTO/GOSUB targets,
>
which were adjusted by BASIC's RENUMBER command. (Does ISPF
Edit's RENUMBER support that?)
> -----Original Message-----
> From: Paul Gilmartin
> Sent: Sunday, June 27, 2021 14:52
>
> FWIW, I prefer coding
> say 'Result =' RESULT
> ...
>
and minuscule for keywords. But for special variable names
such as RESULT, RC, and SIGL, ... I'll follow the style of
the TSO/E Rexx Ref.
-- gil
Seymour J Metz
Jun 27, 2021, 6:27:35 PM6/27/21
to
I'm fairly certain that my REXX programming style was influenced by my PL/I habits.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: TSO REXX Discussion List [TSO-...@VM.MARIST.EDU] on behalf of Frank Clarke [rexx...@YAHOO.COM]
Sent: Sunday, June 27, 2021 5:00 PM
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] Lots of REXX programs were written in COBOL
I hate C*B*L, too, but that technique is very useful for segmenting code down to the atomic level. There's a charming benefit to REXX code written this way, in that if you are running in interactive-TRACE mode and you "trace o" at some point, trace turns OFF within that segment and all of its children until you return to the parent segment, where interactive-TRACE will be back ON.
In this way, you can easily bypass huge parcels of code if you know the error you want to watch happen isn't within those sections.
I typically have an A_INIT module from which I handle all the front-end stuff, and as soon as it starts, I "trace o". When the next main segment starts, TRACE is active again.
The deeper you segment your code, the easier is it to debug and the easier it is to fix.https://secure-web.cisco.com/14TGKMssLef5O01bHHbnz9tWGSfu2DQQfSf2DEAEckz7T0wjPhLg8sdgEF23Nwg-2C9OrvwolSaurWSDXJjIg2OoV-v4o_PIxpdTPaCXwyx5akCDL7b3LZxP2llyM-WlZmgdS3lwoa37u1XvpdKD1meWeVez35kiNOtpRhtx9_TJvOyDy8Uo44QSjTWza-OQTRm9PCp4bCyjv3Ii9w_JEWhqdHYQOsD3JPFU2KVihaHG_O7TQXAjuGsW4Iw1hB1-RSB-uQKNeSK5x0PRQmfXgNKq7aVjSuO6t63k4kOwkrbdjC2vRKKQGVChjdjWNrGOdFtBmYwHG1X5L93HRffmRO_qc932rpCtRc5YBgTx9Kij8JjrSAVjTGkQVQbKJUeuSpywYMRaWE7tjUvcSfeWYAPF-da-joNeFJA7PNVKU1ls13C9N_-pKMTXGjtXCggja/https%3A%2F%2Frexxpertise.blogspot.com%2F2011%2F11%2Fzenith-of-tracing.html
https://secure-web.cisco.com/1F86eYpbLzAnOi79Bav-g2OPMEVitsraA-qBsaEmsXIt1KCNYzxWGAzYoCC_8oek9u0K6BwjU-ByjVi7YC-BscmpgzzrexacuQffA4G6qKAFHWz4ySlgW0W1OPEinK4to2Zzm3nntNip5ZdXAtc2i1JIcNi_HXU1NtlscnwJnTd0YF-1WIODwmmAh2C7645omNexsAW1oohn4DtRvnzehaaMiA_LqIOoTVV_9LwPbAsL86-mVaK3H8MeVItPVWIshzUGljyrcx__qcUgahQ5GxtbdGE5vcZ2_nljLMF8KL89m0VmpxaG00OcWK32HheDEOWlPohdYjeLXPBsWRVFCR763o18FavK6UvfHteyb5EDz7lhHiU_8-W51n82xCVJJ-M4zEqCLvtEP322xy1i1qjLDkpjeSq8fwR0RmRe2t5qgih7TlSqI9XBbYV49wULx/https%3A%2F%2Frexxpertise.blogspot.com%2F2013%2F10%2Fretrospective.html
https://secure-web.cisco.com/1SMFIw-JXYrEb6Pt6AjDJU5pvbTz9bjFK1VTi4Ut2upnRFu9Afgd_wdSotO6FLmm-VzjDlkXwZBoSF9TV2L4TQJtVVlVabN4JvDTJ_6gW5o2w3BhjdSVwJCAnVPRocE7OQ-RXqWoLTfkXcfRpfMoWXJJcedgdGaBaaH00BD2EQ2zIa6-KV-tYq9x0-ugT-IGdPmaeaMXyiCRECsrlRKSx7DM8qyCeyJHC9ui2s8Sq1KCyvN1oQ7qCf7OGMCGgZ2-JSk5UF3PRCCRQ6saV36nBX40pAKBNHGyVC_I2DV1VXVJVUUPpUCzEtbD7m2Afit3LKOiQXJh-nNABM_rTOFLCSBCzDns8VPsp70tUzKqA0MSdy8PPg2_6TaVqKRP4tEptcI0HCTT6_-4PZBTwsQus7fOxHkPrM1ScHHwgh6yIuhrAJbIpo1fCf38rjpjBEEx0/https%3A%2F%2Frexxpertise.blogspot.com%2F2011%2F11%2Fwhen-trace-just-isnt-enough.html
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: TSO REXX Discussion List [TSO-...@VM.MARIST.EDU] on behalf of Frank Clarke [rexx...@YAHOO.COM]
Sent: Sunday, June 27, 2021 5:00 PM
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] Lots of REXX programs were written in COBOL
I hate C*B*L, too, but that technique is very useful for segmenting code down to the atomic level. There's a charming benefit to REXX code written this way, in that if you are running in interactive-TRACE mode and you "trace o" at some point, trace turns OFF within that segment and all of its children until you return to the parent segment, where interactive-TRACE will be back ON.
In this way, you can easily bypass huge parcels of code if you know the error you want to watch happen isn't within those sections.
I typically have an A_INIT module from which I handle all the front-end stuff, and as soon as it starts, I "trace o". When the next main segment starts, TRACE is active again.
https://secure-web.cisco.com/1F86eYpbLzAnOi79Bav-g2OPMEVitsraA-qBsaEmsXIt1KCNYzxWGAzYoCC_8oek9u0K6BwjU-ByjVi7YC-BscmpgzzrexacuQffA4G6qKAFHWz4ySlgW0W1OPEinK4to2Zzm3nntNip5ZdXAtc2i1JIcNi_HXU1NtlscnwJnTd0YF-1WIODwmmAh2C7645omNexsAW1oohn4DtRvnzehaaMiA_LqIOoTVV_9LwPbAsL86-mVaK3H8MeVItPVWIshzUGljyrcx__qcUgahQ5GxtbdGE5vcZ2_nljLMF8KL89m0VmpxaG00OcWK32HheDEOWlPohdYjeLXPBsWRVFCR763o18FavK6UvfHteyb5EDz7lhHiU_8-W51n82xCVJJ-M4zEqCLvtEP322xy1i1qjLDkpjeSq8fwR0RmRe2t5qgih7TlSqI9XBbYV49wULx/https%3A%2F%2Frexxpertise.blogspot.com%2F2013%2F10%2Fretrospective.html
https://secure-web.cisco.com/1SMFIw-JXYrEb6Pt6AjDJU5pvbTz9bjFK1VTi4Ut2upnRFu9Afgd_wdSotO6FLmm-VzjDlkXwZBoSF9TV2L4TQJtVVlVabN4JvDTJ_6gW5o2w3BhjdSVwJCAnVPRocE7OQ-RXqWoLTfkXcfRpfMoWXJJcedgdGaBaaH00BD2EQ2zIa6-KV-tYq9x0-ugT-IGdPmaeaMXyiCRECsrlRKSx7DM8qyCeyJHC9ui2s8Sq1KCyvN1oQ7qCf7OGMCGgZ2-JSk5UF3PRCCRQ6saV36nBX40pAKBNHGyVC_I2DV1VXVJVUUPpUCzEtbD7m2Afit3LKOiQXJh-nNABM_rTOFLCSBCzDns8VPsp70tUzKqA0MSdy8PPg2_6TaVqKRP4tEptcI0HCTT6_-4PZBTwsQus7fOxHkPrM1ScHHwgh6yIuhrAJbIpo1fCf38rjpjBEEx0/https%3A%2F%2Frexxpertise.blogspot.com%2F2011%2F11%2Fwhen-trace-just-isnt-enough.html
Bob Bridges
Jun 28, 2021, 11:18:11 AM6/28/21
to
I gave the impression that I never do anything like my COBOL example, but I
exaggerate. I do see the value of putting large chunks of code into a
procedure even if it's called only once -- named for example "ProcMain" --
in order to improve the readability of the program. I think someone else on
IBM-MAIN recently said the same thing; Gil, maybe? David Nicoll?
I sometimes do it in desperation, but mostly I avoid it, not because I think
it's a bad idea but sheerly out of habit. In my head, a subroutine is for
organizing code I execute more than once, even though I know about and
theoretically approve of this other purpose. Instead, I break my long
sequences into sections -- rarely more than eight or ten lines long -- that
I think of as "paragraphs", separated by blank lines and headed by one or
more explanatory comments. Sometimes the comments are pretty short; for
example I usually have one headed simply "/* Output. */" that reports on the
results I spent the rest of the time collecting.
But yeah, if for some reason I can't clearly express it all in commented
sections, I will as a last resort designate a subroutine. And when you and
others talk about it, I think "I gotta do that more often".
For multi-part variable names I use PascalCasing rather than camelCasing,
but otherwise I'm with you: I start out doing that for clarity, but if it's
a name I use a lot, sooner rather than later I get sloppy and stop doing it.
And for one-word variables and labels it's all lower case.
/* Cooking tip: If you cook your kale with a little coconut oil, it makes it
easier to scrape it into the garbage. -YS @NYinLS2121 */
-----Original Message-----
From: Arthur T. <tsorexx....@XOXY.NET>
Sent: Sunday, June 27, 2021 22:53
COBOL was neither my first nor main language, nor do I love it. I would not
code like your example. But I do something vaguely similar.
I found that it was easier for me to understand some of my own programs if I
moved some of the setup stuff to a later routine I did, in fact, call
INITIALIZE. That way, the meat of the programming was right up front where
it was obvious.
I dislike using superfluous labels, so I wouldn't code all the
initialization and then be able to search for, say, "MainRoutine:", nor
would I expect someone else looking at my code to figure that out.
And (not counting spaghetti code), I try to modify programs as much as
possible in the style they were originally written. That way, the next
person coming in doesn't have to interpret a mishmash of styles to figure
out what the program is doing.
I will sometimes camel-case my variables so I can understand them. But, once
I've introduced them, I generally get lazy and use them as all lower case. I
generally capitalize my own labels to show me that they're my own, internal
routines on the calling statements. I don't want to learn a language where
variable abc is different from variable aBc, nor one where I have to
remember how some random programmer capitalized a library routine.
--- On 27 Jun 2021 12:52:21 -0700, robhb...@GMAIL.COM (Bob Bridges)
wrote:
>Gil's post...on IBM-MAIN reminds me of something I see repeatedly, code
exaggerate. I do see the value of putting large chunks of code into a
procedure even if it's called only once -- named for example "ProcMain" --
in order to improve the readability of the program. I think someone else on
IBM-MAIN recently said the same thing; Gil, maybe? David Nicoll?
I sometimes do it in desperation, but mostly I avoid it, not because I think
it's a bad idea but sheerly out of habit. In my head, a subroutine is for
organizing code I execute more than once, even though I know about and
theoretically approve of this other purpose. Instead, I break my long
sequences into sections -- rarely more than eight or ten lines long -- that
I think of as "paragraphs", separated by blank lines and headed by one or
more explanatory comments. Sometimes the comments are pretty short; for
example I usually have one headed simply "/* Output. */" that reports on the
results I spent the rest of the time collecting.
But yeah, if for some reason I can't clearly express it all in commented
sections, I will as a last resort designate a subroutine. And when you and
others talk about it, I think "I gotta do that more often".
For multi-part variable names I use PascalCasing rather than camelCasing,
but otherwise I'm with you: I start out doing that for clarity, but if it's
a name I use a lot, sooner rather than later I get sloppy and stop doing it.
And for one-word variables and labels it's all lower case.
/* Cooking tip: If you cook your kale with a little coconut oil, it makes it
easier to scrape it into the garbage. -YS @NYinLS2121 */
-----Original Message-----
From: Arthur T. <tsorexx....@XOXY.NET>
Sent: Sunday, June 27, 2021 22:53
COBOL was neither my first nor main language, nor do I love it. I would not
code like your example. But I do something vaguely similar.
I found that it was easier for me to understand some of my own programs if I
moved some of the setup stuff to a later routine I did, in fact, call
INITIALIZE. That way, the meat of the programming was right up front where
it was obvious.
I dislike using superfluous labels, so I wouldn't code all the
initialization and then be able to search for, say, "MainRoutine:", nor
would I expect someone else looking at my code to figure that out.
And (not counting spaghetti code), I try to modify programs as much as
possible in the style they were originally written. That way, the next
person coming in doesn't have to interpret a mishmash of styles to figure
out what the program is doing.
I will sometimes camel-case my variables so I can understand them. But, once
I've introduced them, I generally get lazy and use them as all lower case. I
generally capitalize my own labels to show me that they're my own, internal
routines on the calling statements. I don't want to learn a language where
variable abc is different from variable aBc, nor one where I have to
remember how some random programmer capitalized a library routine.
--- On 27 Jun 2021 12:52:21 -0700, robhb...@GMAIL.COM (Bob Bridges)
wrote:
>Gil's post...on IBM-MAIN reminds me of something I see repeatedly, code
Jeremy Nicoll
Jun 28, 2021, 12:14:39 PM6/28/21
to
On Sun, 27 Jun 2021, at 22:00, Frank Clarke wrote:
> I hate C*B*L, too, but that technique is very useful for segmenting
> code down to the atomic level.
It possibly relates to a formal program design supplied by an analyst
> I hate C*B*L, too, but that technique is very useful for segmenting
> code down to the atomic level.
where major parts and then subsidiary parts of the program were
numbered. Documentation (if in chapters) might have followed the
section numbers, as might the names of "local" variables in
working storage.
A long time ago I wrote something very complex in COBOL - a bit
like an editor for editing a document to meet a specifc XML DTD,
only in my early 1980s program there was no XML or DTD. There
was though a compiled outline document 'shape' that described a
structure and the attributes of various things within it, which the
editor traversed while allowing the user to edit content.
When it was running, authorised users could access an online debug
facility and in that one could dynamically turn tracing on in any or all
subroutines. Because each of them had a number in its name - which
as its programmer I was intimately familiar with - and because I wrote
the code accordingly - you could eg turn this on for routines 200,250,
400-417 etc. Each routine looked at its (nnn'th) byte in an array of
debug flags.
--
Jeremy Nicoll - my opinions are my own.
Phil Smith III
Jun 28, 2021, 12:31:48 PM6/28/21
to
Jeremy Nicoll wrote, in part:
>A long time ago I wrote something very complex in COBOL
<snip>
>When it was running, authorised users could access an online debug
>facility and in that one could dynamically turn tracing on in any or all
>subroutines. Because each of them had a number in its name - which
>as its programmer I was intimately familiar with - and because I wrote
>the code accordingly - you could eg turn this on for routines 200,250,
>400-417 etc. Each routine looked at its (nnn'th) byte in an array of
>debug flags.
I've written servers in Rexx. At various points, they would do something
similar:
if wordpos('whatever', g._Debug) > 0 then trace ?r
where whatever was the name of the function, or some other critical point at
which I might want to do some tracing. Since one of the things the server
could do was to accept a command that would set the g._Debug global
variable, this enabled tracing of the live system without having to restart
it.
Of course there were cases early on where I said "Dammit, I wish I had one
of those tests right here", but then I'd add it and it would be harmless
until/unless I needed it later. Every subroutine or function had one at the
top, which covered most cases anyway. Worked pretty nicely, especially for
those cases where things had gotten into a weird state that was not
necessarily reproducible after a restart.
>A long time ago I wrote something very complex in COBOL
>When it was running, authorised users could access an online debug
>facility and in that one could dynamically turn tracing on in any or all
>subroutines. Because each of them had a number in its name - which
>as its programmer I was intimately familiar with - and because I wrote
>the code accordingly - you could eg turn this on for routines 200,250,
>400-417 etc. Each routine looked at its (nnn'th) byte in an array of
>debug flags.
similar:
if wordpos('whatever', g._Debug) > 0 then trace ?r
where whatever was the name of the function, or some other critical point at
which I might want to do some tracing. Since one of the things the server
could do was to accept a command that would set the g._Debug global
variable, this enabled tracing of the live system without having to restart
it.
Of course there were cases early on where I said "Dammit, I wish I had one
of those tests right here", but then I'd add it and it would be harmless
until/unless I needed it later. Every subroutine or function had one at the
top, which covered most cases anyway. Worked pretty nicely, especially for
those cases where things had gotten into a weird state that was not
necessarily reproducible after a restart.
0 new messages