Paul Gilmartin writes:
I have a colleague who has complained that UNIX callable services
exist in too many variants and should likewise be pameterized. I
imagine he thinks of such as strcpy(1),
strncpy(1), and memcpy(1).
This problem can be viewed differently. C and UNIX suffer from what
Whit
On Feb 11, 2013, at 12:52, Walt Farrell wrote:
>>> Dismayingly, when there are multiple options, the multiplicity
>>> grows exponentially.
>>
>> The MF=M form of RACROUTE is sooo nice for situations like this. I wish all
>> macros had that!
>
> Drat. I was just about to mention that, but you b
Sometimes what one desires and gets are two different things. I like simplicity
in a macros with the passable parameters.
Scott ford
www.identityforge.com
Tell me and I'll forget; show me and I may remember; involve me and I'll
understand. - Chinese Proverb
On Feb 11, 2013, at 2:52 PM, Walt F
On Mon, 11 Feb 2013 10:42:47 -0800, Edward Jaffe
wrote:
>On 2/11/2013 7:59 AM, Paul Gilmartin wrote:
>> On Feb 11, 2013, at 08:37, Bill Fairchild wrote:
>>
>>> In order to make a simple trick like this easy to maintain by someone
else in the future, or even myself (since my intricately detailed m
On 2/11/2013 7:59 AM, Paul Gilmartin wrote:
On Feb 11, 2013, at 08:37, Bill Fairchild wrote:
In order to make a simple trick like this easy to maintain by someone else in
the future, or even myself (since my intricately detailed memory is rather
short-lived), I would want to write so much doc
>> write so much documentation into the code that I would rather spend
>> much less time and write three copies of the macro to make the code
>> triple-pathed.
I can only join the chorus against the "org *-4" (or so) solution.
This is a pandora box and the solution (and the arguments) presented by
On Feb 11, 2013, at 08:37, Bill Fairchild wrote:
> In order to make a simple trick like this easy to maintain by someone else in
> the future, or even myself (since my intricately detailed memory is rather
> short-lived), I would want to write so much documentation into the code that
> I would
[mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Robert A. Rosenberg
Sent: Sunday, February 10, 2013 2:43 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: DSPSERV with SCOPE=?
At 12:34 + on 02/10/2013, esst...@juno.com wrote about Re:
DSPSERV with SCOPE=?:
>Robert Rosenberg wrote
>>Why
Things like that---It is a sort of COBOL ALTER---can be done; but the
result is not reentrant, would be hard to maintain (collateral changes
would be required every time IBM changed the macro's code skeletons),
etc., etc.
Á chacun son goût.
John Gilmore, Ashland, MA 01721 - USA
At 12:34 + on 02/10/2013, esst...@juno.com wrote about Re:
DSPSERV with SCOPE=?:
Robert Rosenberg wrote
Why not just multi-path logic? You pass a flag for the scope in pass_scope
as 0=SINGLE, 4=ALL, 8=COMMON and go:
I actually use a similiar logic now, I was trying to get a single
At 08:43 -0500 on 02/10/2013, John Gilmore wrote about Re: DSPSERV
with SCOPE=?:
For execution-time binding Robert Rosenberg's scheme, or something
very like it, is the only viable one. (I looked at the macro
definition.)
John Gilmore, Ashland, MA 01721 - USA
At 10:01 -0500 on 02/10
The only supported approach to parameterize the SCOPE value at runtime is
brute force,
in your case triple-pathing the code for the three choices you want to
make available.
Peter Relson
z/OS Core Technology Design
For execution-time binding Robert Rosenberg's scheme, or something
very like it, is the only viable one. (I looked at the macro
definition.)
John Gilmore, Ashland, MA 01721 - USA
I prefer to determine the SCOPE specification at execution time.
-- Original Message --
From: John Gilmore
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: DSPSERV with SCOPE=?
Date: Sat, 9 Feb 2013 15:40:37 -0500
The obvious question is that of the binding time of this
-
From: "Robert A. Rosenberg"
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: DSPSERV with SCOPE=?
Date: Sat, 9 Feb 2013 15:32:25 -0500
At 15:53 + on 02/09/2013, esst...@juno.com wrote about DSPSERV
with SCOPE=?:
>I would like to develope a single routine which is passed
>par
At 15:40 -0500 on 02/09/2013, John Gilmore wrote about Re: DSPSERV
with SCOPE=?:
The obvious question is that of the binding time of this requirement.
My scheme is useful at assembly time; Robert Rosenberg's is useful at
execution time.
John Gilmore, Ashland, MA 01721 - USA
Mine, obvi
At 15:53 + on 02/09/2013, esst...@juno.com wrote about DSPSERV
with SCOPE=?:
I would like to develope a single routine which is passed
parameters, but the SCOPE= parameter does not seem to allow a
parameter to be passed.
For Example:
DSPSERV CREATE,
NAME=DSP_NAME
You can use a character set symbols in open code for this purpose, as in
|&scopea(1) setc 'single','all','common'--supported-values array
|&scopesub seta . . . --1|2|3
|&scopevar setc '&scopea(&scopesub)'
|DSPSERV CREATE,
| NAME=DSP_NAME,
| SCOP
When creating a dataspace I want to know if there are any recommendations for
making the SCOPE=SINGLE|ALL|COMMON a variable.
I would like to develope a single routine which is passed parameters, but the
SCOPE= parameter does not seem to allow a parameter to be passed.
For Example:
DSPSE
19 matches
Mail list logo
