(new) ANY LENGTH in draft Standard

Frank (and possibly) others have mentioned the new "ANY LENGTH" clause.  The
re
is initial support (01-level Linkage Section only) in the '02 Standard, but
there is a LOT more in the draft of the next Standard.  For those who might 
be
interested in this feature (and "looking forward to it"), you might want to 
see
a paper that I just submitted to J4 on the MANY (IMHO) problems with the cur
rent
(draft) specification).

See:
http://www.cobolstandard.info/j4/files/07-0025.doc

--
Bill Klein
wmklein <at> ix.netcom.com

William M. Klein<wmklein@nospam.netcom.com> 02/09/07 1:14 PM >>>
>Frank (and possibly) others have mentioned the new "ANY LENGTH" clause.
There
>is initial support (01-level Linkage Section only) in the '02 Standard, but

>there is a LOT more in the draft of the next Standard.  For those who might
be
>interested in this feature (and "looking forward to it"), you might want to
see
>a paper that I just submitted to J4 on the MANY (IMHO) problems with the
current
>(draft) specification).
>
>See:
>  http://www.cobolstandard.info/j4/files/07-0025.doc

Yep.  The 2002 ANY LENGTH stuff (for use only in the linkage section for
passed parameters) is nice.  But the ANY LENGTH stuff in the next proposed
looks to be *very* nice.  Of course your little document there shoots a lot
of holes into it, but there's still a lot of good stuff there.

What seems kind of backwards to me is that they're trying to create a
standard with many new things that no existing compiler has implemented.
Seems like they'd want to actually have some idea how something is going to
be implemented before putting it in a 'standard'.  At least if someone has
already done it you know that it can be done!

I totally agree with you on the restriction of not allowing any-length data
items as a USING or RETURNING parameter on a CALL (or invoke).  Seems like
an obvious thing one might want to do is...

01  ERROR-STRING   PIC X ANY LENGTH LIMIT 100 DELIMITED BY X'00'.
01  FORMAT-STRING  PIC X ANY LENGTH INDIRECT DELIMITED BY X'00'.
01  MY-STRING      PIC X ANY LENGTH LIMIT 100 DELIMITED BY X'00'.
01  MY-INT         BINARY-SHORT.

MOVE ERROR-MSG(X) TO MY-STRING
MOVE ERROR-VAL TO MY-INT
MOVE '%s %d' TO FORMAT-STRING
CALL 'sprintf' USING ERROR-STRING
FORMAT-STRING
MY-STRING
BY VALUE MY-INT
DISPLAY ERROR-STRING

Not sure I have that 100%, but you get the idea.  Does seem an awfully
verbose way of specifying a 'null terminated string', but hey, this is COBOL
after alll...

As far as you can tell does the proposed standard have any way of defining
null-terminated string literals?  I know (or at least I think I do) that IBM
Enterprise COBOL utilizes z'this is a null-terminated string' for this.  So
the above could be maybe

CALL 'sprintf' USING ERROR-STRING
z"%s %d"
MY-STRING
BY VALUE MY-INT

One other thing this reminds me, is does the new standard have any type of
VAR_ARGS type processing for passed parameters?  I know there's the
OPTIONAL/OMITTED stuff, but it seems like you still have to specify
explicitly all possible parameters you might receive.  Using the C sprintf
function as an example, I wonder if COBOL might allow for something
similar.

Frank


---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO  USA

In answer to the 2 questions I see in your note.

In the '02 (and later) Standards, null-terminated literals are done by:
"this is a null-terminated literal" & X"00"

As far as variable number of parameters,  I haven't looked for it recently, 
but
I *think* that "omitted" is the "default" (when using CALL-prototypes) if th
ere
are less than the "normal" number of parameters passed.  Rick may be able to
find this quickly in the document.

--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:534jn2F1pmnneU1@mid.individual.net...
> William M. Klein<wmklein@nospam.netcom.com> 02/09/07 1:14 PM >>> 
> There 
> 
> be 
> see 
> current 
>
> Yep.  The 2002 ANY LENGTH stuff (for use only in the linkage section for
> passed parameters) is nice.  But the ANY LENGTH stuff in the next proposed
> looks to be *very* nice.  Of course your little document there shoots a lo
t
> of holes into it, but there's still a lot of good stuff there.
>
> What seems kind of backwards to me is that they're trying to create a
> standard with many new things that no existing compiler has implemented.
> Seems like they'd want to actually have some idea how something is going t
o
> be implemented before putting it in a 'standard'.  At least if someone has
> already done it you know that it can be done!
>
> I totally agree with you on the restriction of not allowing any-length dat
a
> items as a USING or RETURNING parameter on a CALL (or invoke).  Seems like
> an obvious thing one might want to do is...
>
> 01  ERROR-STRING   PIC X ANY LENGTH LIMIT 100 DELIMITED BY X'00'.
> 01  FORMAT-STRING  PIC X ANY LENGTH INDIRECT DELIMITED BY X'00'.
> 01  MY-STRING      PIC X ANY LENGTH LIMIT 100 DELIMITED BY X'00'.
> 01  MY-INT         BINARY-SHORT.
>
>    MOVE ERROR-MSG(X) TO MY-STRING
>    MOVE ERROR-VAL TO MY-INT
>    MOVE '%s %d' TO FORMAT-STRING
>    CALL 'sprintf' USING ERROR-STRING
>                         FORMAT-STRING
>                         MY-STRING
>                         BY VALUE MY-INT
>    DISPLAY ERROR-STRING
>
> Not sure I have that 100%, but you get the idea.  Does seem an awfully
> verbose way of specifying a 'null terminated string', but hey, this is COB
OL
> after alll...
>
> As far as you can tell does the proposed standard have any way of defining
> null-terminated string literals?  I know (or at least I think I do) that I
BM
> Enterprise COBOL utilizes z'this is a null-terminated string' for this.  S
o
> the above could be maybe
>
>    CALL 'sprintf' USING ERROR-STRING
>                         z"%s %d"
>                         MY-STRING
>                         BY VALUE MY-INT
>
> One other thing this reminds me, is does the new standard have any type of
> VAR_ARGS type processing for passed parameters?  I know there's the
> OPTIONAL/OMITTED stuff, but it seems like you still have to specify
> explicitly all possible parameters you might receive.  Using the C sprintf
> function as an example, I wonder if COBOL might allow for something
> similar.
>
> Frank
>
>
> ---
> Frank Swarbrick
> Senior Developer/Analyst - Mainframe Applications
> FirstBank Data Corporation - Lakewood, CO  USA

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:534jn2F1pmnneU1@mid.individual.net...
[snip]
> One other thing this reminds me, is does the new standard have any type of
> VAR_ARGS type processing for passed parameters?  I know there's the
> OPTIONAL/OMITTED stuff, but it seems like you still have to specify
> explicitly all possible parameters you might receive.  Using the C sprintf
> function as an example, I wonder if COBOL might allow for something
> similar.

I can find no reference in 2002, 200x WD 1.6, or
the candidates for future revision list, mentioning
variable argument lists such as used in C.

If COBOL were to allow for such, it likely would
not make it into a standard until 2016, or so. <g>

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:12sqjdjij29gc12@corp.supernews.com...
>
> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
> news:534jn2F1pmnneU1@mid.individual.net...
> [snip] 
of 
sprintf 
>
> I can find no reference in 2002, 200x WD 1.6, or
> the candidates for future revision list, mentioning
> variable argument lists such as used in C.

After re-reading the Candidates for Future Revision
List (06-0189), I did find a reference:

"33. 98-0471, Interfacing with C: The ANY phrase (Friedman)
any type, repeated: J4 - 32, WG4 - no
for outbound calls only"

I think that "for outbound calls only" should actually
appear after "repeated".

Rick, Frank (and others)
Having now "looked" the 02 Standard has

"8.8.4.1.7 Omitted-argument condition"

to test if an argument was or wan't "passed".  I also found the statement un
der
INVOKE and CALL that says,

"If an OMITTED phrase is specified or a trailing argument is omitted, the
omitted-argument condition for that
parameter evaluates to true in the called program."

which made me think that "trailing paramers" could be omitted - however, I
couldn't (quickly) find where this was explicitly allowed.

I think (but won't swear to it) that what this boils down to is:

1) A "subprogram" (invoked method, user-defined function, whatever) needs to
have a SPECIFIC number of "expected/maximum" parameters; these are specified
 in
the Procedure Division USING statement.  It may have OPTIONAL specified for 
as
many of them (especially trailing ones) as desired.

2) The activating entity MAY either specify OMITTED or leave off "trailing"
optional parameters.

4 The "omited-argument" test lets a submprogram (with OPTIONAL in the Proced
ure
Division USING statement) test which arguments were actullay passed to it.

***

Not knowing C, my guess is that this is definitely LESS powerful than what i
t
has - but is more powerful than what COBOL previously allowed.


--
Bill Klein
wmklein <at> ix.netcom.com
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:12sqjdjij29gc12@corp.supernews.com...
>
> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
> news:534jn2F1pmnneU1@mid.individual.net...
> [snip] 
>
> I can find no reference in 2002, 200x WD 1.6, or
> the candidates for future revision list, mentioning
> variable argument lists such as used in C.
>
> If COBOL were to allow for such, it likely would
> not make it into a standard until 2016, or so. <g>
>
>
>

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:Wrszh.56098$dB4.20488@fe08.news.easynews.com...
> Rick, Frank (and others)
>    Having now "looked" the 02 Standard has
>
> "8.8.4.1.7 Omitted-argument condition"
>
> to test if an argument was or wan't "passed".  I also found the statement
under
> INVOKE and CALL that says,
>
> "If an OMITTED phrase is specified or a trailing argument is omitted, the
> omitted-argument condition for that
> parameter evaluates to true in the called program."
>
> which made me think that "trailing paramers" could be omitted - however, I
> couldn't (quickly) find where this was explicitly allowed.
>
> I think (but won't swear to it) that what this boils down to is:
>
> 1) A "subprogram" (invoked method, user-defined function, whatever) needs
to
> have a SPECIFIC number of "expected/maximum" parameters; these are
specified in
> the Procedure Division USING statement.  It may have OPTIONAL specified
for as
> many of them (especially trailing ones) as desired.
>
> 2) The activating entity MAY either specify OMITTED or leave off
"trailing"
> optional parameters.

That seems about right.

FDIS 2002, page 404, 14.7.1 Parameters,
"The number of arguments in the activating element shall be
equal to the number of formal parameters in the activated
element, with the exception of trailing formal parameters that
are specified with an OPTIONAL phrase in the procedure
division header of the activated element and omitted from
the list of arguments of the activating element."

> 4 The "omited-argument" test lets a submprogram (with OPTIONAL in the
Procedure
> Division USING statement) test which arguments were actullay passed to it.
>
>   ***
>
> Not knowing C, my guess is that this is definitely LESS powerful than what
it
> has - but is more powerful than what COBOL previously allowed.

I think it is more like--less flexible than C.

> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:12sqjdjij29gc12@corp.supernews.com... 
of 
sprintf 

William M. Klein<wmklein@nospam.netcom.com> 02/09/07 8:25 PM >>>
>In answer to the 2 questions I see in your note.
>
>In the '02 (and later) Standards, null-terminated literals are done by:
> "this is a null-terminated literal" & X"00"

Yeah, I thought of this soon after writing my message.

>As far as variable number of parameters,  I haven't looked for it recently,
but
>I *think* that "omitted" is the "default" (when using CALL-prototypes) if
there
>are less than the "normal" number of parameters passed.  Rick may be able
to
>find this quickly in the document.

I believe this is the case, but I would call this "optional" arguments
rather than "variable" arguments.  Each optional argument still needs to be
declared in PROCEDURE DIVISION USING clause of the called program.

Some languages offer a  feature that takes "trailing optional"
arguments, marshalls them in to an array, and passes the array to the called
routine.  That seems pretty  to me.

Anyway...

Frank

---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO  USA

Rick Smith<ricksmith@mfi.net> 02/09/07 9:41 PM >>>
>
>"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
>news:534jn2F1pmnneU1@mid.individual.net...
>[snip] 
of 
sprintf 
>
>I can find no reference in 2002, 200x WD 1.6, or
>the candidates for future revision list, mentioning
>variable argument lists such as used in C.
>
>If COBOL were to allow for such, it likely would
>not make it into a standard until 2016, or so. <g>

Oy!

William M. Klein<wmklein@nospam.netcom.com> 02/10/07 4:21 PM >>>
>Rick, Frank (and others)
>   Having now "looked" the 02 Standard has
>
>"8.8.4.1.7 Omitted-argument condition"
>
>to test if an argument was or wan't "passed".  I also found the statement
under
>INVOKE and CALL that says,
>
>"If an OMITTED phrase is specified or a trailing argument is omitted, the
>omitted-argument condition for that
>parameter evaluates to true in the called program."
>
>which made me think that "trailing paramers" could be omitted - however, I

>couldn't (quickly) find where this was explicitly allowed.
>
>I think (but won't swear to it) that what this boils down to is:
>
>1) A "subprogram" (invoked method, user-defined function, whatever) needs
to
>have a SPECIFIC number of "expected/maximum" parameters; these are
specified in
>the Procedure Division USING statement.  It may have OPTIONAL specified for
as
>many of them (especially trailing ones) as desired.

Yep.

>2) The activating entity MAY either specify OMITTED or leave off "trailing"

>optional parameters.

Yep.

>4 The "omited-argument" test lets a submprogram (with OPTIONAL in the
Procedure
>Division USING statement) test which arguments were actullay passed to it.

Yep.

>Not knowing C, my guess is that this is definitely LESS powerful than what
it
>has - but is more powerful than what COBOL previously allowed.

Yep!  :-)

It's interesting that COBOL has statements that allow an 'infinite' number
of parameters, but it's not allowed for user created routines.
Eg,
DISPLAY one two three four five six seven eight nine ten

Ah well.

Frank


---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO  USA