Home > Archive > Cobol > May 2006 > FUNCTION vs PROGRAM
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 |
FUNCTION vs PROGRAM
|
|
| Frank Swarbrick 2006-05-22, 6:55 pm |
| I've been browsing through the COBOL 2002 standard and I can't for the life
of me figure out what the difference between the following is:
- a PROGRAM that has a RETURNING clause on the PROCEDURE DIVISION statement
- a (user-defined) FUNCTION that has a RETURNING clause on the PROCEDURE
DIVISION statement
Is it simply that a FUNCTION called as if it were a "defined field" (not
sure what the correct term is here) and a PROGRAM is called using the CALL
verb?
eg,
REPOSITORY.
FUNCTION my-func.
PROCEDURE DIVISION.
CALL "my-prog" USING my-func(my-value) RETURNING my-prog-result
This would call the function MY-FUNC using the argument MY-VALUE. It would
then call MY-PROG using the result of the my-func call as the argument and
returning the result of the MY-PROG call in to the field MY-PROG-RESULT.
I guess that if this is the only difference I have to wonder why the
addition of the FUNCTION-ID was necessary. Why didn't they just allow a
PROGRAM that returns a value (or even one that doesn't) to be called in the
manner that a FUNCTION is now called?
Just wondering...
Oh, and can someone point me to where it states how a function can be
called? I see the factorial example in Appendix D, but I can't for the life
of me find reference to this usage in the main body of the standard.
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| William M. Klein 2006-05-22, 6:55 pm |
| Frank,
This was an issue that I "commented on" during the development of the '02
Standard (and lost).
With some exceptions (see below) if you have a program with a Program-ID (and
End Program) and RETURNING phrase you can use a COPY REPLACING to make a
Function out of it.
Functions are "accessed" by a function-identifier
Programs are accessed by a CALL statement
Programs may have the IS INITIAL/COMMON phrase; functions may not. (Use only
"Local-storage" if you want the equivalent of a program with IS INITIAL).
Chuck may remember, but I can't WHY the committees decided that
- objects can be referenced either by an INVOKE statement or an inline
invocation identifier
while
- Programs need to be accessed by CALL and Functions by Function identifiers
Of course, I think that an OBJECT must have a "returned value" - while this is
optional for a program (so not ALL programs would be valid functions).
--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:4de70nF1acj9cU1@individual.net...
> I've been browsing through the COBOL 2002 standard and I can't for the life
> of me figure out what the difference between the following is:
> - a PROGRAM that has a RETURNING clause on the PROCEDURE DIVISION statement
> - a (user-defined) FUNCTION that has a RETURNING clause on the PROCEDURE
> DIVISION statement
>
> Is it simply that a FUNCTION called as if it were a "defined field" (not
> sure what the correct term is here) and a PROGRAM is called using the CALL
> verb?
>
> eg,
> REPOSITORY.
> FUNCTION my-func.
> PROCEDURE DIVISION.
> CALL "my-prog" USING my-func(my-value) RETURNING my-prog-result
>
> This would call the function MY-FUNC using the argument MY-VALUE. It would
> then call MY-PROG using the result of the my-func call as the argument and
> returning the result of the MY-PROG call in to the field MY-PROG-RESULT.
>
> I guess that if this is the only difference I have to wonder why the
> addition of the FUNCTION-ID was necessary. Why didn't they just allow a
> PROGRAM that returns a value (or even one that doesn't) to be called in the
> manner that a FUNCTION is now called?
>
> Just wondering...
>
> Oh, and can someone point me to where it states how a function can be
> called? I see the factorial example in Appendix D, but I can't for the life
> of me find reference to this usage in the main body of the standard.
>
> Frank
>
>
> ---
> Frank Swarbrick
> Senior Developer/Analyst - Mainframe Applications
> FirstBank Data Corporation - Lakewood, CO USA
| |
| Frank Swarbrick 2006-05-22, 9:55 pm |
| William M. Klein<wmklein@nospam.netcom.com> 05/22/06 12:05 PM >>>
>Frank,
> This was an issue that I "commented on" during the development of the
'02
>Standard (and lost).
Great minds? :-)
>With some exceptions (see below) if you have a program with a Program-ID
(and
>End Program) and RETURNING phrase you can use a COPY REPLACING to make a
>Function out of it.
>
>Functions are "accessed" by a function-identifier
>Programs are accessed by a CALL statement
>
>Programs may have the IS INITIAL/COMMON phrase; functions may not. (Use
only
>"Local-storage" if you want the equivalent of a program with IS INITIAL).
Yeah, sounds like IS INITIAL becomes rather redundant with the addition of
LOCAL-STORAGE.
>Chuck may remember, but I can't WHY the committees decided that
> - objects can be referenced either by an INVOKE statement or an inline
>invocation identifier
> while
> - Programs need to be accessed by CALL and Functions by Function
identifiers
Odd indeed. Even Pascal, which distinguishes between Procedures (no return
value) and Functions (return value), doesn't require a CALL keyword.
>Of course, I think that an OBJECT must have a "returned value" - while this
is
>optional for a program (so not ALL programs would be valid functions).
I don't see that this is true. In fact, the procedure division of an OBJECT
appears to simply be one or more methods, each having its own procedure
division. And even there I don't see why a returned value would be
required.
eg,
SET o TO My-Class::"New" (abc)
INVOKE o "displayInfo" *> or just: o::"displayInfo"
Seems to be to be perfectly valid.
Ah well. In any case, if I had FUNCTIONs avaialble I might be tempted to
use them in all cases and never use "programs". (Can a function be the
first thing called by the operating environment?)
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| Donald Tees 2006-05-22, 9:55 pm |
| Frank Swarbrick wrote:
> William M. Klein<wmklein@nospam.netcom.com> 05/22/06 12:05 PM >>>
>
>
> '02
>
>
>
> Great minds? :-)
>
>
>
> (and
>
>
> only
>
>
>
> Yeah, sounds like IS INITIAL becomes rather redundant with the addition of
> LOCAL-STORAGE.
>
>
>
> identifiers
>
> Odd indeed. Even Pascal, which distinguishes between Procedures (no return
> value) and Functions (return value), doesn't require a CALL keyword.
>
>
>
> is
>
>
>
> I don't see that this is true. In fact, the procedure division of an OBJECT
> appears to simply be one or more methods, each having its own procedure
> division. And even there I don't see why a returned value would be
> required.
> eg,
> SET o TO My-Class::"New" (abc)
> INVOKE o "displayInfo" *> or just: o::"displayInfo"
>
> Seems to be to be perfectly valid.
>
Move property-name of my-object to ...
requires a returning.
Donald
| |
| Richard 2006-05-22, 9:55 pm |
| > I guess that if this is the only difference I have to wonder why the
> addition of the FUNCTION-ID was necessary.
It is a philosophical thing as well as one of practicality.
User defined and intrinsic functions can be used in arithmetic or
character expressions. Expressions can be used in conditional
expressions. Conditional expressions can be short-circuited.
Most procedures pass their results by side-effects (eg setting global
data or returning values in the parameters). If you allowed a procedure
to be executed in a conditional expression then there may be cases
where it is not called and thus the side effects do not result. This
is a bug trap that is dealt with in C (for example) by particular
idioms.
Intrinsic functions do not produce side effects and you should ensure
that user functions also do not.
| |
| Frank Swarbrick 2006-05-22, 9:55 pm |
| Donald Tees<donald_tees@sympatico.ca> 05/22/06 4:50 PM >>>
>Frank Swarbrick wrote:
OBJECT[color=darkred]
>
>Move property-name of my-object to ...
>
>requires a returning.
Yes...what's your point? "move ... to property-name of my-object" does not
require a returning, does it? I was only disputing "I think that an OBJECT
must have a 'returned value'".
Frank
| |
| Frank Swarbrick 2006-05-22, 9:55 pm |
| Richard<riplin@Azonic.co.nz> 05/22/06 5:40 PM >>>
>
>It is a philosophical thing as well as one of practicality.
>
>User defined and intrinsic functions can be used in arithmetic or
>character expressions. Expressions can be used in conditional
>expressions. Conditional expressions can be short-circuited.
>
>Most procedures pass their results by side-effects (eg setting global
>data or returning values in the parameters). If you allowed a procedure
>to be executed in a conditional expression then there may be cases
>where it is not called and thus the side effects do not result. This
>is a bug trap that is dealt with in C (for example) by particular
>idioms.
>
>Intrinsic functions do not produce side effects and you should ensure
>that user functions also do not.
That is an interesting, and valid, point of view. However, if the language
doesn't force this restriction (functions should not produce side-effects),
I'm not sure if it's really a difference that makes any difference. I'll
have to ponder it more, in any case.
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| Donald Tees 2006-05-23, 7:55 am |
| Frank Swarbrick wrote:
> Donald Tees<donald_tees@sympatico.ca> 05/22/06 4:50 PM >>>
>
>
> OBJECT
>
>
>
> Yes...what's your point? "move ... to property-name of my-object" does not
> require a returning, does it? I was only disputing "I think that an OBJECT
> must have a 'returned value'".
> Frank
>
An object does not require a returning to move data into a property. It
does require a returning to get data *from* a property, if there is a
specialized method to do that. If it is simply declared a property,
with no specific method for geting the data, then it does not.
Donald
| |
| Howard Brazee 2006-05-23, 6:55 pm |
| I'm of the opinion that all languages that call functions should do so
in ways that we can easily check to see if the call was successful.
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
| |
| Frank Swarbrick 2006-05-23, 6:55 pm |
| I agree with this post.
:-)
[color=darkred]
I'm of the opinion that all languages that call functions should do so
in ways that we can easily check to see if the call was successful.
| |
| William M. Klein 2006-05-23, 6:55 pm |
| <much snippage>
A method (of an Object) *must* have a returning phrase *IF* it is to be used in
an "inline object invocation", e.g.
Move Object-name :: "Method-name" (Some-parameters) to Wherever
Just as a function must have a RETURNING phrase to be used as a user-defined
function, e.g.
Move <Function> My-Function (Some-parameters) to Whatever
***
To use GET/SET properties either implicit or explicit GET/SET methods must be
specified.
My original statement was in error as page 468 of the '02 Standard shows the
RETURNING phrase of the INVOKE statement as optional, therefore one could INVOKE
a method that did not have a returning phrase.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Frank Swarbrick 2006-05-24, 9:55 pm |
| William M. Klein<wmklein@nospam.netcom.com> 05/23/06 4:40 PM >>>
><much snippage>
>
>A method (of an Object) *must* have a returning phrase *IF* it is to be
used in
>an "inline object invocation", e.g.
>
> Move Object-name :: "Method-name" (Some-parameters) to Wherever
>
>Just as a function must have a RETURNING phrase to be used as a
user-defined
>function, e.g.
>
> Move <Function> My-Function (Some-parameters) to Whatever
>
> ***
>
>To use GET/SET properties either implicit or explicit GET/SET methods must
be
>specified.
>
>My original statement was in error as page 468 of the '02 Standard shows
the
>RETURNING phrase of the INVOKE statement as optional, therefore one could
INVOKE
>a method that did not have a returning phrase.
Could you not use
Object-name::"Method-name"(Some-parameters)
instead of
Invoke Object-name "Method-name" Using Some-parameters
I can't find anywhere where it is stated that this is not allowed.
I also find interesting that storage for the 'returning item' must be
allocated in the "activating source unit". So what would happen if a
program was called (or method invoked) without the RETURNING phrase, but the
program (or method) has the RETURNING phrase specified? This is not a
problem in C, as returning values are, I believe, passed back in registers,
so the "activating source unit" is free to ignore it. Appears this is not
the case with COBOL? Can COBOL not call a C function in the following
manner?
CALL 'socket' USING socket-domain, socket-type, socket-protocol RETURNING
socket-fd
or
MOVE function socket(socket-domain, socket-type, socket-protocol) TO
socket-fd
Or is this where the ENTRY-CONVENTION clause comes in? (Actually, it
appears that that is exactly what that are for. Interesting! I assume that
the CALL-CONVENTION directive could be used similarly.)
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| William M. Klein 2006-05-24, 9:55 pm |
|
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:4djhieF1a1mk9U1@individual.net...
> William M. Klein<wmklein@nospam.netcom.com> 05/23/06 4:40 PM >>>
> used in
> user-defined
> be
> the
> INVOKE
>
> Could you not use
> Object-name::"Method-name"(Some-parameters)
>
> instead of
> Invoke Object-name "Method-name" Using Some-parameters
>
> I can't find anywhere where it is stated that this is not allowed.
>
I usend an incorrect term. The correct term for such structures is:
"Inline method invocation"
According to SR(1) on page 94 of the '02 Standard
"1) Inline method invocation shall not be specified as a receiving operand."
And as I read the rules all data items MUST be either a sending operand or a
receiving operand (or both). Therefore, this can only be used as a sending
item - so it needs a returnd value.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Frank Swarbrick 2006-05-24, 9:55 pm |
| William M. Klein<wmklein@nospam.netcom.com> 05/24/06 3:02 PM >>>
>I usend an incorrect term. The correct term for such structures is:
> "Inline method invocation"
>
>According to SR(1) on page 94 of the '02 Standard
>
>"1) Inline method invocation shall not be specified as a receiving
operand."
>
>And as I read the rules all data items MUST be either a sending operand or
a
>receiving operand (or both). Therefore, this can only be used as a sending
>item - so it needs a returnd value.
You may be correct. The only reason I can see for having this rule is that
each COBOL statement (or so it seems to me) starts with a verb. So
MOVE my-obj::"my-action"(my-parm) TO my-result
starts with the verb MOVE, and
INVOKE my-obj "my-action" USNG my-parm
starts with the verb INVOKE, but
my-obj::"my-action"(my-parm)
would not start with a verb, and I'm guessing would then be contrary to how
COBOL works. Ah well, I can live with it.
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
|
|
|
|
|