Discussion:
PROCEDURE (was Subroutine scope)
(too old to reply)
Bob Bridges
2017-09-28 21:24:32 UTC
Permalink
Raw Message
I never used to use PROCEDURE, but I find I'm using it more and more
casually these days. I think I got tired of discovering that I'd been using
a variable inside a subroutine that was accidentally the same as one in the
main process. For a while I protected myself against that by naming every
variable inside a subroutine with a prefix unique to that subroutine. For
example, if the subroutine is GetMessage, then every variable inside
GetMessage might be named gmtask, gmmsg, gmthis, gmthat, gmetc. That works
alright, but sometimes it's simpler to add PROCEDURE EXPOSE. If the EXPOSE
list is long enough I still go the other way though.

---
Bob Bridges, cell 336 382-7313
***@gmail.com
***@InfoSecInc.com

/* Being famous has its benefits, but fame isn't one of them. -Larry Wall
*/


-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On Behalf Of
Robin
Sent: Tuesday, September 26, 2017 21:02

Interesting question.

I believe the Rexx interpreter does not worry or care where the physical end
of the subroutine is.

You can write instream subroutines with multiple entry points and/or
recursive (be very careful) calls. You can even use the same label more than
once.

Personally, I don't believe I have ever found a need for a PROCEDURE
statement.

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On Behalf Of
Bob Bridges
Sent: September 26, 2017 2:10 PM

I don't know whether "scope" is the right word for this, but I'm writing
something in VBS and suddenly, while I was looking at my "end function"
statement, got to wondering how REXX knows when the end of the subroutine
is.

It isn't the RETURN statement by itself, because I write some subroutines
like this:

/* Is this a valid string? */
IsValid: arg str
If length(str)>8 then return 0
If left(str,1)<>'A' then return 0
Return (verify(str,'0123456789',,2)=0)

Yet it occurs to me that when the REXX interpreter sees a PROCEDURE
statement, it has to know where to stop, so to speak. Is the PROCEDURE
statement good until it sees another label? That doesn't sound right.

I've been doing this many years so I'm not worried about REXX not working
for me if I don't understand it; obviously it handles it somehow. I'm just
curious how. Anyone know?

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Jeremy Nicoll
2017-09-28 23:08:28 UTC
Permalink
Raw Message
If the EXPOSE list is long enough I still go the other way though.
In some of my code I keep groups of related variables in stems, for
example placing 'constants' in c.0this c.0that c.0and c.0other
etc (and then I'll take care never to alter them after I first set
them),
or whatever. I quite often use g. for 'globals' that I want to
expose in a lot of procedures but not all of them, and so on.

Then I might have

procedure expose c. g. happen monitor p. z.

for example. An advantage of this sort of thing is if you group
vars carefully enough in such stems you don't have to keep
changing the expose lists in every procedure whenever you
want to modify the list of vars concerned.

--
Jeremy Nicoll - my opinions are my own.

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Gerard Schildberger
2017-09-28 23:33:08 UTC
Permalink
Raw Message
Post by Jeremy Nicoll
If the EXPOSE list is long enough I still go the other way though.
In some of my code I keep groups of related variables in stems, for
example placing 'constants' in c.0this c.0that c.0and c.0other
etc (and then I'll take care never to alter them after I first set
them),
or whatever. I quite often use g. for 'globals' that I want to
expose in a lot of procedures but not all of them, and so on.
Then I might have
procedure expose c. g. happen monitor p. z.
for example. An advantage of this sort of thing is if you group
vars carefully enough in such stems you don't have to keep
changing the expose lists in every procedure whenever you
want to modify the list of vars concerned.
--
Jeremy Nicoll - my opinions are my own.
That's what the
expose (list)
is for.

(main program somewhere, hopefully near the front of the pgm):

exposeList= 'c. g. happen monitor p. z.'

... later ...

xxx: procedure expose (exposeList)

This means that you only have to maintain one list at one location.
___________________________________________ Gerard Schildberger
Hobart Spitz
2017-09-29 04:03:35 UTC
Permalink
Raw Message
If you don't know, this works. GLOBALS ( or whatever name you choose), as
well as all vars named in it's value, are exposed.

...
Globals = "Fred Joe Sam xx mystem. myotherstem. iratio" /* etc */
...
Fnc: procedure expose (Globals)
...
return
Post by Jeremy Nicoll
If the EXPOSE list is long enough I still go the other way though.
In some of my code I keep groups of related variables in stems, for
example placing 'constants' in c.0this c.0that c.0and c.0other
etc (and then I'll take care never to alter them after I first set
them),
or whatever. I quite often use g. for 'globals' that I want to
expose in a lot of procedures but not all of them, and so on.
Then I might have
procedure expose c. g. happen monitor p. z.
for example. An advantage of this sort of thing is if you group
vars carefully enough in such stems you don't have to keep
changing the expose lists in every procedure whenever you
want to modify the list of vars concerned.
--
Jeremy Nicoll - my opinions are my own.
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Jeremy Nicoll
2017-09-29 07:17:12 UTC
Permalink
Raw Message
Post by Hobart Spitz
If you don't know, this works. GLOBALS ( or whatever name you
choose), as well as all vars named in it's value, are exposed.
...
Globals = "Fred Joe Sam xx mystem. myotherstem. iratio" /* etc */
...
Fnc: procedure expose (Globals)
...
return
I did know. The disadvantage with that, as I see it, is that within the
code
of "Fnc" there's nothing that immediately reminds the programmer that
the disparate collection of vars named in 'Globals' are global.

Whereas, if you use procedure expose g.

you can easily see that g.0this g.0that g.0crocodile ...

are all of that nature.

--
Jeremy Nicoll - my opinions are my own.

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Hobart Spitz
2017-09-29 11:26:45 UTC
Permalink
Raw Message
That's correct. However, variables can change from global to non-global
and/or vice versa. In such cases, you have to go back and add or remove
"g.0" in/from all occurrences. When compared to updating just a single
line, that seems like a much more error-prone effort.

And what if you want to expose a whole stem and all its elements??

On Fri, Sep 29, 2017 at 3:18 AM, Jeremy Nicoll <
Post by Jeremy Nicoll
Post by Hobart Spitz
If you don't know, this works. GLOBALS ( or whatever name you
choose), as well as all vars named in it's value, are exposed.
...
Globals = "Fred Joe Sam xx mystem. myotherstem. iratio" /* etc */
...
Fnc: procedure expose (Globals)
...
return
I did know. The disadvantage with that, as I see it, is that within the
code
of "Fnc" there's nothing that immediately reminds the programmer that
the disparate collection of vars named in 'Globals' are global.
Whereas, if you use procedure expose g.
you can easily see that g.0this g.0that g.0crocodile ...
are all of that nature.
--
Jeremy Nicoll - my opinions are my own.
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
--
OREXXMan

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Bob Bridges
2017-09-29 22:23:22 UTC
Permalink
Raw Message
Hobart, are you saying you might want a variable to be exposed to one subroutine and not to another? Can you give me an example? Seems to me if I put a bunch of "global" values in g.something, I'm unlikely to regret it later.

---
Bob Bridges, cell 336 382-7313
***@gmail.com
***@InfoSecInc.com

/* In most states you can get a driver's license when you're 16 years old, which made a lot of sense to me when I was 16 years old but now seems insane. -Dave Barry */


-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On Behalf Of Hobart Spitz
Sent: Friday, September 29, 2017 07:28

That's correct. However, variables can change from global to non-global and/or vice versa. In such cases, you have to go back and add or remove "g.0" in/from all occurrences. When compared to updating just a single line, that seems like a much more error-prone effort.

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Jeremy Nicoll
2017-09-29 22:47:26 UTC
Permalink
Raw Message
Post by Bob Bridges
Hobart, are you saying you might want a variable to be exposed to one
subroutine and not to another? Can you give me an example? Seems to me
if I put a bunch of "global" values in g.something, I'm unlikely to
regret it later.
In any non-trivial exec (say several thousand lines of code) you are
likely to have different sets of variables exposed to different sets
of procedures.

Eg you might have a whole lot of procedures used in validating the
contents of some data file and building stems full of the validated
data.

You might have another set used in, say, report generation from the
results of something your exec does. The 'globals' for that might be
very different.

You wouldn't expose the vars used by one set of procedures to code
executing in the other routines because if you do, a typo in one part
of the code might affect values stored in vars that ideally should be
isolated from what that code's meant to be doing.

Where this gets trickier is that vars needed by functions/procedures
that are called by f/p that are called by f/p that are called by f/p...
etc need to be exposed in all the f/p higher up the call structure, or
their values never get to the deeply nested routines. So eg any var
you use in general error handling, flags telling whether files are
open (& therefore need closed as you terminate if there's a problem
or at normal end of program) need to be exposed pretty much
everywhere.

--
Jeremy Nicoll - my opinions are my own.

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Bob Bridges
2017-09-29 22:45:07 UTC
Permalink
Raw Message
Oh, now I like that idea! I may try that.

Wait a minute - maybe this is the value of an option I've never before seen the need of. Like this:

nu='0123456789'
lc='abcdefghijklmnopqrstuvwxyz'
uc='ABCDEFGHIJKLMNOPQRSTUVWXYZ'
globals='nu lc uc'
.
.
.
Subroutine: procedure expose (globals)

Then I wouldn't have to put them in g.something, nor name them all glthis and glthat.

---
Bob Bridges, cell 336 382-7313
***@gmail.com
***@InfoSecInc.com

/* It is the mark of an educated mind to be able to entertain a thought without accepting it. -Aristotle */


-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-***@VM.MARIST.EDU] On Behalf Of Jeremy Nicoll
Sent: Thursday, September 28, 2017 19:08

In some of my code I keep groups of related variables in stems, for
example placing 'constants' in c.0this c.0that c.0and c.0other
etc (and then I'll take care never to alter them after I first set them),
or whatever. I quite often use g. for 'globals' that I want to
expose in a lot of procedures but not all of them, and so on.

Then I might have

procedure expose c. g. happen monitor p. z.

for example. An advantage of this sort of thing is if you group vars carefully enough in such stems you don't have to keep changing the expose lists in every procedure whenever you want to modify the list of vars concerned.

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Jeremy Nicoll
2017-09-29 11:40:45 UTC
Permalink
Raw Message
Post by Hobart Spitz
That's correct. However, variables can change from global to non-global
and/or vice versa. In such cases, you have to go back and add or remove
"g.0" in/from all occurrences.
Like all of us, I suspect, I know how I normally code. If I decide that
some var needs to be in eg g. then it's very unlikely that it, needing
to be visible all over the place will cease to be. I do plan how my
execs are structured, what the data structures are going to be etc
before I write the bulk of the code.

If it really needed to be done issuing a change all, in edit is hardly
hard.
Post by Hobart Spitz
When compared to updating just a single
line, that seems like a much more error-prone effort.
And what if you want to expose a whole stem and all its elements??
Any complex exec more than likely already has an expose line like

procedure expose c. data. g. monit. v. ....

and apart from that rather than exposing eg data. explicitly, I
might use

g.0data.

as the stem.


--
Jeremy Nicoll - my opinions are my own.

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO TSO-REXX
Loading...