Re: [CMS-PIPELINES] Variable field selection

[Paul Gilmartin]

On 2017-05-03, at 14:57, Michael Harding wrote:
>
> ...  Or in your example you could have kept going beyond the 4th
> argument but what's the point, you know they aren't specified.
>
It was just an astonishment (admittedly minor) that for:
X = F(, 'Z' )
in F, "SAY ARG() ARG( ARG(), 'E' )"
prints "2 1", but for:
X = F( 'A', )
in F, "SAY ARG() ARG( ARG(), 'E' )"
prints "1 1" where I'd expect "2 0".  (I just need to read the manual
very carefully.)

On 2017-05-03, at 14:48, Mark Boonie wrote:

> Small quibble -- Rexx does distinguish between a null string and an
> omitted string, to some extent, using the ARG(n, 'E') or ARG(n, 'O') forms
> of the ARG() function.  For example, Arg(4, 'E') returns 0 if the 4th
> argument was omitted, but it returns 1 if it was specified as a null
> string.  For parsing, of course, an omitted parameter is treated the same
> as a null string.
>
One might code, if it matters:
IF ARG( n, 'E' ) THEN Arg.n = ARG( n )
 ELSE DROP Arg.n

> The ARG() function with no parameters returns the number of the last
> explicitly specified argument (even if it was a null string).  As a
> result, there is no way to tell how many extra commas with omitted
> parameters were specified.
>
Yup.

And one can tell whether a subroutine returns a result with
DROP RESULT
CALL SUBR
if SYMBOL( 'RESULT' )=='LIT' THEN DROP X
 ELSE X = RESULT
(assuming that SUBR doesn't have an internal call that sets RESULT
and EXPOSEs it.)

-- gil

Re: [CMS-PIPELINES] Variable field selection

[Michael Harding]

Agree with Alan.  Any unspecified argument is "OMITTED".  Note that z/VM
Rexx, OpenObject Rexx and Regina Rexx all specify Arg() as returning the
number of the last EXPLICIT argument.  That doesn't mean your
subroutine/function can't look for more as long as it can handle their
being null.  Or in your example you could have kept going beyond the 4th
argument but what's the point, you know they aren't specified.

--
Mike Harding
z/VM System Support
/sp


CMSTSO Pipelines Discussion List  wrote on
05/03/2017 01:25:01 PM:

> From: Alan Altmark/Endicott/IBM@IBMUS
> To: CMS-PIPELINES@VM.MARIST.EDU
> Date: 05/03/2017 01:25 PM
> Subject: Re: Variable field selection
> Sent by: CMSTSO Pipelines Discussion List 
>
> > But, I can't provide an "OMITTED" final argument, no matter how
> > many commas or blank lines I supply.
>
> If you mean that REXX doesn't distinguish between a null string and an
> omitted string, that's true.  My programs all use the null string in an
> argument to indicate omission, since that what you get with the ", ,"
> idiom.  So my program can decide it wants the "default" behavior at
> runtime without having to have two different CALLs or function
> invocations.
>
> I like it that way.  :-)
>
> Alan Altmark
>
> Senior Managing z/VM and Linux Consultant
> Lab Services System z Delivery Practice
> IBM Systems & Technology Group
> ibm.com/systems/services/labservices
> office: 607.429.3323
> mobile; 607.321.7556
> alan_altm...@us.ibm.com
> IBM Endicott
>

Re: [CMS-PIPELINES] Variable field selection

[Mark Boonie]

> If you mean that REXX doesn't distinguish between a null string and an 
> omitted string, that's true.

Small quibble -- Rexx does distinguish between a null string and an 
omitted string, to some extent, using the ARG(n, 'E') or ARG(n, 'O') forms 
of the ARG() function.  For example, Arg(4, 'E') returns 0 if the 4th 
argument was omitted, but it returns 1 if it was specified as a null 
string.  For parsing, of course, an omitted parameter is treated the same 
as a null string.

The ARG() function with no parameters returns the number of the last 
explicitly specified argument (even if it was a null string).  As a 
result, there is no way to tell how many extra commas with omitted 
parameters were specified.

- mb

Re: [CMS-PIPELINES] Variable field selection

[Paul Gilmartin]

On 2017-05-03, at 14:30, Michael Harding wrote:

> Too sly, but inventive!
>
> I personally like to code "parse value function() with ."; safe with or
> without a returned value.
>
No, if "function()" returns no value, the interpreter reports a syntax error.

-- gil

Re: [CMS-PIPELINES] Variable field selection

[Paul Gilmartin]

On 2017-05-03, at 14:25, Alan Altmark wrote:

>> But, I can't provide an "OMITTED" final argument, no matter how
>> many commas or blank lines I supply.
> 
> If you mean that REXX doesn't distinguish between a null string and an 
> omitted string, that's true.  My programs all use the null string in an 
> argument to indicate omission, since that what you get with the ", ," 
> idiom.  So my program can decide it wants the "default" behavior at 
> runtime without having to have two different CALLs or function 
> invocations.
>  
No, except for the final argument the ARG( n, 'EXISTS' ) and arg( n, 'OMITTED' )
functions do distinguish between a null string and an omitted string.
Look at the output of the example I supplied.

> I like it that way.  :-)
> 
> Alan Altmark

-- gil

Re: [CMS-PIPELINES] Variable field selection

[Michael Harding]

Too sly, but inventive!

I personally like to code "parse value function() with ."; safe with or
without a returned value.
--
Mike Harding
z/VM System Support
/sp


CMSTSO Pipelines Discussion List  wrote on
05/03/2017 11:39:04 AM:

> From: Rob van der Heij 
> To: CMS-PIPELINES@VM.MARIST.EDU
> Date: 05/03/2017 11:41 AM
> Subject: Re: Variable field selection
> Sent by: CMSTSO Pipelines Discussion List 
>
> On 3 May 2017, 14:30:18, Alan Altmark wrote:
>
> > I have pretty much abandoned CALL in CMS in favor of function calls
with
> > null return values.  The REXX interface to CMS (REXEXT macro)
suppresses
> > any null command, so I can get more creative in the way I call
functions
> > without resorting to syntax crutches like the ones above.  It ensures
that
> > there is never ambiguity in the purpose of a trailing comma.
>
> Or NUCXLOAD a module as 0, 28, and whatever good return codes you get ;-)
>
> Rob
>

Re: [CMS-PIPELINES] Variable field selection

[Alan Altmark]

> But, I can't provide an "OMITTED" final argument, no matter how
> many commas or blank lines I supply.

If you mean that REXX doesn't distinguish between a null string and an 
omitted string, that's true.  My programs all use the null string in an 
argument to indicate omission, since that what you get with the ", ," 
idiom.  So my program can decide it wants the "default" behavior at 
runtime without having to have two different CALLs or function 
invocations.

I like it that way.  :-)

Alan Altmark

Senior Managing z/VM and Linux Consultant
Lab Services System z Delivery Practice
IBM Systems & Technology Group
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

Re: [CMS-PIPELINES] Variable field selection

[Paul Gilmartin]

On 2017-05-03, at 12:30, Alan Altmark wrote:

> On Wednesday, 05/03/2017 at 03:47 GMT, Paul Gilmartin (π) 
>  wrote:
>> Rexx's CALL instruction provides no way to indicate a null
>> last argument.
> 
> CALL XYZ "fun", , "flags", ""
> XYZ: ARG p1, p2, p3, p4
> 
> will provide a null string (length 0) to to both "p2" and "p4" the 
> routine.  You can get away without the trailing "" but only if the next 
> line is empty.  (Or"How to make debug more challenging!")
> 
> I have pretty much abandoned CALL in CMS in favor of function calls with 
> null return values.  The REXX interface to CMS (REXEXT macro) suppresses 
> any null command, so I can get more creative in the way I call functions
>   
This once caused me a problem.  I had crafted a command environment to
which the null string was a meaningful command.  But Rexx suppressed it.
I went to SR, and IBM fixed it (the Reference Manual made no exception
for the null string as a command.)  But IBM said it remains suppressed
for ADDRESS CMS, ADDRESS COMMAND, and ADDRESS XEDIT.

> without resorting to syntax crutches like the ones above.  It ensures that 
> there is never ambiguity in the purpose of a trailing comma.
>  
But, I can't provide an "OMITTED" final argument, no matter how
many commas or blank lines I supply.  (Example not with IBM's
Rexx, but I believe it works the same:
/* Rexx *** */ signal on novalue  /*
   null final argment?
*/
trace R

X =  XYZ( "fun", , "flags", "", , , , )
call XYZ  "fun", , "flags", "", , , ,

return( 0 )

XYZ: procedure
trace N
say arg()
do I = 1 to arg()
say I':' arg( I, 'E' ) arg( I );  end I
say
return( 0 )
/*  */ 

 6 *-* X =  XYZ( "fun", , "flags", "", , , , )
11 *-*  procedure
12 *-*  trace N
4
1: 1 fun
2: 0 
3: 1 flags
4: 1 

 7 *-* call XYZ  "fun", , "flags", "", , ,  
11 *-*  XYZ:
   *-*  procedure
12 *-*  trace N
4
1: 1 fun
2: 0 
3: 1 flags
4: 1 

 9 *-* return( 0 )

-- gil

Re: [CMS-PIPELINES] Variable field selection

[Rob van der Heij]

On 3 May 2017, 14:30:18, Alan Altmark wrote:

> I have pretty much abandoned CALL in CMS in favor of function calls with
> null return values.  The REXX interface to CMS (REXEXT macro) suppresses
> any null command, so I can get more creative in the way I call functions
> without resorting to syntax crutches like the ones above.  It ensures that
> there is never ambiguity in the purpose of a trailing comma.

Or NUCXLOAD a module as 0, 28, and whatever good return codes you get ;-)

Rob

Re: [CMS-PIPELINES] Variable field selection

[Alan Altmark]

On Wednesday, 05/03/2017 at 03:47 GMT, Paul Gilmartin (π) 
 wrote:
> Rexx's CALL instruction provides no way to indicate a null
> last argument.

CALL XYZ "fun", , "flags", ""
XYZ: ARG p1, p2, p3, p4

will provide a null string (length 0) to to both "p2" and "p4" the 
routine.  You can get away without the trailing "" but only if the next 
line is empty.  (Or"How to make debug more challenging!")

I have pretty much abandoned CALL in CMS in favor of function calls with 
null return values.  The REXX interface to CMS (REXEXT macro) suppresses 
any null command, so I can get more creative in the way I call functions 
without resorting to syntax crutches like the ones above.  It ensures that 
there is never ambiguity in the purpose of a trailing comma.

Alan Altmark

Senior Managing z/VM and Linux Consultant
Lab Services System z Delivery Practice
IBM Systems & Technology Group
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

Re: [CMS-PIPELINES] Variable field selection

[Rob van der Heij]

On 3 May 2017, 09:46:27, Paul Gilmartin wrote:

> UNIX utilities struggle with such behavior.  For some:
> o If the delimiter is a blank:
>   - Multiple blanks are equivalent to a single blank.
>   - A trailing blank is ignored.
> o If the delimiter is (e.g.) a comma, multiple delimiters
>   and trailing delimiters indicate empty fields.

The 'word' and 'field' work like that in CMS Pipelines, and
'autofield' behaves like a field in that aspect.

The problem with autofield is more meta-level; it's not about
a trailing delimiter in the program code, but rather in the
data being processed.

I suppose a usage note in the book may be the best approach
to not break existing usage. You can force it either way by
an extra delimiter when it's not there.

Sir Rob the Plumber

Re: [CMS-PIPELINES] Variable field selection

[π]

On Wed, May 03, 2017 at 02:21:02AM -0400, Rob van der Heij wrote:
>
> For the record and for the curious plumbers; the problem that I have with
> it is that a separator at the end of the record is optionally removed,
> which causes surprises for fields relative to the end (e.g. af -1).
> There may have been too much water through the pipe to fix that now.
>
UNIX utilities struggle with such behavior.  For some:
o If the delimiter is a blank:
  - Multiple blanks are equivalent to a single blank.
  - A trailing blank is ignored.
o If the delimiter is (e.g.) a comma, multiple delimiters
  and trailing delimiters indicate empty fields.

Rexx's CALL instruction provides no way to indicate a null
last argument.

In HLASM, using a comma to separate the comment field can
indicate two null arguments to a macro.

-- gil