Home > Archive > Cobol > February 2007 > (new) ANY LENGTH in draft Standard
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
(new) ANY LENGTH in draft Standard
|
|
| William M. Klein 2007-02-09, 6:55 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
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Frank Swarbrick 2007-02-09, 9:55 pm |
| 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
| |
| William M. Klein 2007-02-09, 9:55 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"
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.
--
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 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
| |
| Rick Smith 2007-02-10, 3:55 am |
|
"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 2007-02-10, 6:55 pm |
|
"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[color=darkred]
sprintf[color=darkred]
>
> 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".
| |
| William M. Klein 2007-02-10, 6:55 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.
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 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.
--
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>
>
>
>
| |
| Rick Smith 2007-02-10, 9:55 pm |
|
"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.
[color=darkred]
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:12sqjdjij29gc12@corp.supernews.com...
of[color=darkred]
sprintf[color=darkred]
| |
| Frank Swarbrick 2007-02-12, 6:55 pm |
| 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
| |
| Frank Swarbrick 2007-02-12, 6:55 pm |
| 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[color=darkred]
sprintf[color=darkred]
>
>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!
| |
| Frank Swarbrick 2007-02-12, 6:55 pm |
| 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
| |
| Howard Brazee 2007-02-12, 6:55 pm |
| On Mon, 12 Feb 2007 11:35:34 -0700, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com> wrote:
>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
I've worked at several locations that have standards that we pass
parameters via files. Obviously these don't have standard parameter
size limits.
|
|
|
|
|