Using ADDRESS in Rexx
Lars Höglund
Pros and cons about using ADDRESS ISPEXEC / ADDRESS TSO / ADDRESS …
The code has a lot of ISPEXEC and TSO commands
Shall I use
ADDRESS ISPEXEC
“TBOPEN….”
ADDRESS TSO
“ALLOC….”
Or
ADDRESS ISPEXEC “TBOPEN…”
ADDRESS TSO “ALLOC…”
Recommendation pls
//Lasse
Bernie Rataj
Hi Lasse,
If the ADDRESS targets are highly mixed, then the ADDRESS {target} {command} form is preferable for all uses to avoid confusion about which {target} is active.
If most commands have the same target, then declare ADDRESS {default-target} at the beginning, and use the ADDRESS {target} {command} for the exceptions to minimize the “clutter”.
Bernie
_________________________________________
Bernie Rataj
Senior Software Developer
Enterprise COBOL & PL/I for z/OS Technical Support
905-413-2857 bra...@ca.ibm.com
From: ispf-...@nd.edu <ispf-...@nd.edu>
On Behalf Of Lars Höglund
Sent: Thursday, November 24, 2022 09:06
To: ISPF discussion list (ISP...@LISTSERV.ND.EDU) <isp...@listserv.nd.edu>
Subject: [EXTERNAL] [ISPF-L] Using ADDRESS in Rexx
Pros and cons about using ADDRESS ISPEXEC / ADDRESS TSO / ADDRESS … The code has a lot of ISPEXEC and TSO commands Shall I use ADDRESS ISPEXEC “TBOPEN…. ” ADDRESS TSO “ALLOC…. ” Or ADDRESS ISPEXEC “TBOPEN…”
ZjQcmQRYFpfptBannerStart
|
ZjQcmQRYFpfptBannerEnd
--
You received this message because you are subscribed to the Google Groups "ISPF discussion list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
ispf-l-list...@nd.edu.
To view this discussion on the web visit https://groups.google.com/a/nd.edu/d/msgid/ispf-l-list/AM7PR03MB65001EBE2B67362AEFAFD98A8D0F9%40AM7PR03MB6500.eurprd03.prod.outlook.com.
lbd...@gmail.com
It doesn’t matter if you only do one action per address. If you’re going to have multiple actions per address then my recommendation is the 1st approach.
Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck
“Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are.” - - - John Wooden
From: ispf-...@nd.edu <ispf-...@nd.edu> On Behalf Of Lars Höglund
Sent: Thursday, November 24, 2022 8:06 AM
To: ISPF discussion list (ISP...@LISTSERV.ND.EDU) <isp...@listserv.nd.edu>
--
Rob Scott
As always with these style questions, there are going to be different opinions.
My 2c :
Unless the REXX exec is trivial, I always put “address XXXX” on every line for the following reasons :
(o) Someone (or maybe you in months/years to come) might modify the EXEC and insert an “address YYYY” somewhere between your original “address XXXX” and your hanging host command buffer statement. The likelihood of this increases as the number of lines increase between each XXXX environment statements
(o) It helps the REXX exec reader/maintainer (who might not be you) easily see the intended receiver of the statement, especially when variable replacements have been used to build the host command buffer.
(o) I have on occasion dealt with three concurrent REXX host environments and have been building up host commands for each, using a namespace prefix on the command buffer aids insanity prevention for example :
address TSO tso_cmd
..
address SDSF sdsf_cmd
..
address ISPEXEC ispf_cmd
(o) I think my distaste for the hanging host environment stems from being burnt by hanging USING statements in assembler subroutines (a topic for another day).
Rob Scott
Rocket Software
From: ispf-...@nd.edu <ispf-...@nd.edu>
On Behalf Of lbd...@gmail.com
Sent: 24 November 2022 14:23
To: ispf-...@nd.edu; 'ISPF discussion list' <isp...@listserv.nd.edu>
Subject: RE: [ISPF-L] Using ADDRESS in Rexx
|
EXTERNAL EMAIL |
To view this discussion on the web visit https://groups.google.com/a/nd.edu/d/msgid/ispf-l-list/016601d90010%2447e0c590%24d7a250b0%24%40gmail.com.
================================
Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
================================
This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy
all copies of this communication. Thank you.
Daryl
On Nov 24, 2022, at 18:37, Rob Scott <rsc...@rocketsoftware.com> wrote:
To view this discussion on the web visit https://groups.google.com/a/nd.edu/d/msgid/ispf-l-list/BL0PR07MB39875162E2967F903EEE5C11B30F9%40BL0PR07MB3987.namprd07.prod.outlook.com.
Frank Clarke
On Nov 24, 2022, at 10:37 AM, Rob Scott <rsc...@rocketsoftware.com> wrote:
To view this discussion on the web visit https://groups.google.com/a/nd.edu/d/msgid/ispf-l-list/BL0PR07MB39875162E2967F903EEE5C11B30F9%40BL0PR07MB3987.namprd07.prod.outlook.com.
Rob Scott
Daryl
“If most coworkers are experienced” can be ephemeral 😊
Rob
To view this discussion on the web visit https://groups.google.com/a/nd.edu/d/msgid/ispf-l-list/69BB45CF-39CF-4AFB-9C51-D34751E44BC2%40yahoo.com.
Paul Gilmartin
> Unless the REXX exec is trivial, I always put “address XXXX” on every line for the following reasons :
NUMERIC before every line? I think it makes the code harder to read.
Some more useful techniques:
o The ADDRESS() function can be used to save and restore a previous
command environment.
o ADDRESS has function scope. I find it useful to wrap a sequence of
commands to a given environment in a function. The caller's environment
is automatically restored on RETURN.
> (o) Someone (or maybe you in months/years to come) might modify the EXEC and insert an “address YYYY” somewhere between your original “address XXXX” and your hanging host command buffer statement. The likelihood of this increases as the number of lines increase between each XXXX environment statements
>
> (o) It helps the REXX exec reader/maintainer (who might not be you) easily see the intended receiver of the statement, especially when variable replacements have been used to build the host command buffer.
>
> (o) I have on occasion dealt with three concurrent REXX host environments and have been building up host commands for each, using a namespace prefix on the command buffer aids insanity prevention for example :
>
> address TSO tso_cmd
> ..
> address SDSF sdsf_cmd
> ..
> address ISPEXEC ispf_cmd
>
> (o) I think my distaste for the hanging host environment stems from being burnt by hanging USING statements in assembler subroutines (a topic for another day).
--
gil
Rob Scott
>> (o) I think my distaste for the hanging host environment stems from being burnt by hanging USING statements in assembler subroutines (a topic for another day).
>PUSH/POP USING should help that.
Absolutely.
Unfortunately some of the code I have had the “pleasure” of supporting/debugging was originally written in the 1980s and has been through multiple devs/L3 with varying levels of competence and attention to detail.
Rob
From: 'Paul Gilmartin' via ISPF discussion list <ispf-...@nd.edu>
Sent: 24 November 2022 16:41
To: ispf-...@nd.edu
Subject: Re: [ISPF-L] Using ADDRESS in Rexx
|
EXTERNAL EMAIL |
--
You received this message because you are subscribed to the Google Groups "ISPF discussion list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
ispf-l-list...@nd.edu.
To view this discussion on the web visit https://groups.google.com/a/nd.edu/d/msgid/ispf-l-list/a61b1cbd-1235-ebf7...@AIM.com.
Paul Gilmartin
> ...
> Absolutely.
>
> Unfortunately some of the code I have had the “pleasure” of supporting/debugging was originally written in the 1980s
> ... and has been through multiple devs/L3 with varying levels of competence and attention to detail.
For which there's little remedy short of HR action.
--
gil
Lars Höglund
Thank You all.
So the conclusion is: it doesn’t matter how You are coding.
There’s no “downside” of type Address in every row except waste of characters
The Address statement as such, doesn’t do anything, or?
//Lasse
To view this discussion on the web visit https://groups.google.com/a/nd.edu/d/msgid/ispf-l-list/MN2PR15MB34057C23742E8F241CA8E59DF10F9%40MN2PR15MB3405.namprd15.prod.outlook.com.
Bernie Rataj
Hi Lasse,
An ADDRESS statement by itself sets the default command environment, ie. the command environment to which strings are sent in the absence of an explicit ADDRESS {target-env} prefix.
The context in which the exec is invoked will also set a default command environment.
Bernie
_________________________________________
Bernie Rataj
Senior Software Developer
Enterprise COBOL & PL/I for z/OS Technical Support
905-413-2857 bra...@ca.ibm.com
https://www.ibm.com/products/cobol-compiler-zos
https://www.ibm.com/products/pli-compiler-zos
From: ispf-...@nd.edu <ispf-...@nd.edu>
On Behalf Of Lars Höglund
Sent: Friday, November 25, 2022 00:37
To: ispf-...@nd.edu
Subject: [EXTERNAL] [ISPF-L] Sv: Using ADDRESS in Rexx
Thank You all. So the conclusion is: it doesn’t matter how You are coding. There’s no “downside” of type Address in every row except waste of characters The Address statement as such, doesn’t do anything, or? //Lasse Från: ispf-l-list@ nd. edu
To view this discussion on the web visit https://groups.google.com/a/nd.edu/d/msgid/ispf-l-list/AM7PR03MB6500C6F5F8E79B21D4A7711E8D0E9%40AM7PR03MB6500.eurprd03.prod.outlook.com.
robhb...@gmail.com
Coming late to the party, but Bernie summarizes how I do it myself. What it didn’t occur to me until now to wonder is whether there’s a timing disadvantage to how you use ADDRESS. Simple enough to write a test REXX and do it ten thousand times in each of several different ways, to find out. But if it makes any difference at all, it would be significant only if there are lots of address changes inside a bunch of big loops.
---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313
/* When a man is getting better he understands more and more clearly the evil that is still left in him. When a man is getting worse, he understands his own badness less and less. A moderately bad man knows he is not very good; a thoroughly bad man thinks he is all right. This is common sense, really. You understand sleep when you are awake, not while you are sleeping. You can see mistakes in arithmetic when your mind is working properly; while you are making them you cannot see them. You can understand the nature of drunkenness when you are sober, not when you are drunk. Good people know about both good and evil; bad people do not know about either. -C S Lewis, _Christian Behavior_ */
From: ispf-...@nd.edu <ispf-...@nd.edu> On Behalf Of Bernie Rataj
Sent: Thursday, November 24, 2022 09:17
If the ADDRESS targets are highly mixed, then the ADDRESS {target} {command} form is preferable for all uses to avoid confusion about which {target} is active.
If most commands have the same target, then declare ADDRESS {default-target} at the beginning, and use the ADDRESS {target} {command} for the exceptions to minimize the “clutter”.
From: ispf-...@nd.edu <ispf-...@nd.edu> On Behalf Of Lars Höglund
Sent: Thursday, November 24, 2022 09:06
Pros and cons about using ADDRESS ISPEXEC / ADDRESS TSO / ADDRESS …
Paul Gilmartin
> Coming late to the party, but Bernie summarizes how I do it myself. What it didn’t occur to me until now to wonder is whether there’s a timing disadvantage to how you use ADDRESS. Simple enough to write a test REXX and do it ten thousand times in each of several different ways, to find out. But if it makes any difference at all, it would be significant only if there are lots of address changes inside a bunch of big loops.
be the cost of the lexical analysis of the "ADDRESS whatever" tokens.
Thanks for raising that concern; to this point the discussion has centered
on legibility and maintainability.
The ISPF manuals are rife with [ADDRESS] {ISPEXEC|ISREDIT}. I find it
tedious; noise rather than signal.
It might be interesting to compare:
ADDRESS ISPEXEC
...
ISREDIT <conmand>
with:
ADDRESS ISREDIT COMMAND
The latter would seem to bypass an extra dispatching step.
--
gil
Frank Clarke
Paul Gilmartin
When CMS XEDIT enters a REXX macro, the initial command environment is XEDIT.
This makes good sense to me because I expect most commands in an XEDIT macro
to be addressed to the XEDIT environment.
When ISPF Edit enters a REXX macro, the initial command environment is TSO.
This makes little sense to me because I do not expect most commands in an
Edit macro (or even the first command, MACRO) to be addressed to the TSO
environment.
What explains this peculiar design?
o Do TSO commands predominate in an Edit macro?
o Was it economy of design, avoiding the need for similar interface
modules for two environments?
o Or was it compulsive "compatibility" with the limitations of CLIST which
lacks the facility to select among multiple command environments?
ISPF under CMS (I haven't used it recently) was even stranger, requiring a
peculiar stutter::
ADDRESS ISREDIT command /* failed with a syntax error. */
ADDRESS ISREDIT ISREDIT command /* succeeded. */
(It may have been a bug; it may have been fixed.
--
gil
Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.
--
You received this message because you are subscribed to the Google Groups "ISPF discussion list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ispf-l-list...@nd.edu.
To view this discussion on the web visit https://groups.google.com/a/nd.edu/d/msgid/ispf-l-list/85bf1822-cb2c-63d6-b4f4-65aac0510068%40AIM.com.
Frank Clarke
--
You received this message because you are subscribed to the Google Groups "ISPF discussion list" group.
To view this discussion on the web visit https://groups.google.com/a/nd.edu/d/msgid/ispf-l-list/85bf1822-cb2c-63d6-b4f4-65aac0510068%40AIM.com.
Paul Gilmartin
> How would ISPEXEC know that it's a macro that it has just been asked to start? The only path I can envision is "I just went through all the command tables, and this command isn't there. I guess it must be a macro," but I expect there are unfillable gaps even there.
I would expect that if the command was entered on an Edit command line
the REXX exec would be started with ISREDIT in SUBCOM of the EXECBLK;
if from a non-Edit ISPF panel, ISPEXEC in SUBCOM of the EXECBLK.
> On Sunday, November 27, 2022 at 11:34:47 AM EST, 'Paul Gilmartin' wrote> ....
> This makes little sense to me because I do not expect most commands in an
> Edit macro (or even the first command, MACRO) to be addressed to the TSO
> environment.
>
> What explains this peculiar design?
>
> o Do TSO commands predominate in an Edit macro?
>
> o Was it economy of design, avoiding the need for similar interface
> modules for two environments?
>
> o Or was it compulsive "compatibility" with the limitations of CLIST which
> lacks the facility to select among multiple command environments?
gil