compilation error.

Hi,

I am getting the following compilation error when I used
"MOVE FUNCTION LENGTH (INPUT-FIELD) TO VAR-1".

But, if I use
COMPUTE VAR-1 = FUNCTION LENGTH (INPUT-FIELD) it is going smooth.

The filed is declared as VAR-1 PIC X(50).

The severe compilation error I got was as shown below:

"IGYPA3245-S - Numeric function "INTEGER FUNCTION LENGTH" was not
allowed in this context.  The statement was  discarded.

Can anybody tell me what is the problem?

I am using "IBM Enterprise COBOL for z/OS  3.3.1".

TIA.

"arrbee" <arrbee@gmail.com> wrote in message
news:1145865783.188124.31530@t31g2000cwb.googlegroups.com...
> Hi,
>
> I am getting the following compilation error when I used
> "MOVE FUNCTION LENGTH (INPUT-FIELD) TO VAR-1".
>
> But, if I use
> COMPUTE VAR-1 = FUNCTION LENGTH (INPUT-FIELD) it is going smooth.
>
> The filed is declared as VAR-1 PIC X(50).
>
> The severe compilation error I got was as shown below:
>
> "IGYPA3245-S - Numeric function "INTEGER FUNCTION LENGTH" was not
> allowed in this context.  The statement was  discarded.
>
> Can anybody tell me what is the problem?
>
> I am using "IBM Enterprise COBOL for z/OS  3.3.1".

FUNCTION LENGTH is an integer function.

An integer function (or numeric function) can be used
only in an arithmetic expression. (COBOL 85 intrinsic
functions amendment)

The sending field for a MOVE statement may be either
an identifier or a literal. (COBOL 85 standard)

The message is saying, in effect, that an integer function
is not allowed where an identifier or a literal is required.

The problem is that the COBOL 85 intrinsic functions
amendment placed limits on the uses of intrinsic functions
and, as nearly as I can tell, IBM seems to have
conformed to that limit. <g>

arrbee wrote:
> Hi,
>
> I am getting the following compilation error when I used
> "MOVE FUNCTION LENGTH (INPUT-FIELD) TO VAR-1".
>
> But, if I use
> COMPUTE VAR-1 = FUNCTION LENGTH (INPUT-FIELD) it is going smooth.
>
> The filed is declared as VAR-1 PIC X(50).
>
> The severe compilation error I got was as shown below:
>
> "IGYPA3245-S - Numeric function "INTEGER FUNCTION LENGTH" was not
> allowed in this context.  The statement was  discarded.
>
> Can anybody tell me what is the problem?
>
> I am using "IBM Enterprise COBOL for z/OS  3.3.1".
>
> TIA.

What happens if the PIC is 9(50) instead of X(50)?

What might have happened if FUNCTION LENGTH had returned a SIGNED
result?

On 24 Apr 2006 04:04:12 -0700, epc8@juno.com wrote:

>What happens if the PIC is 9(50) instead of X(50)?

Unfortunately, the standard does not require such a big numeric field,
and I don't believe any compiler supports it.

>What might have happened if FUNCTION LENGTH had returned a SIGNED
>result?

You still can't compute a to string, you need to compute to a number.

Posted Via mcse.ms Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.mcse.ms

Howard Brazee wrote:
> On 24 Apr 2006 04:04:12 -0700, epc8@juno.com wrote:
> 
>
> Unfortunately, the standard does not require such a big numeric field,
> and I don't believe any compiler supports it.
>
Oops. Posting before morning coffee :-<.
 
>

No cream or sugar yet either :-(.

> You still can't compute a to string, you need to compute to a number.
>

Yes, I missed the point while looking at the apparent type mismatch. I
also was fooled by seeing examples where MOVE FUNCTION .... TO .....
did work when the function returned a character string.

Still it seems odd that COMPUTE works but MOVE does not when the net
effect is to perform an assignment of an integer value produced by a
function. I guess that a function result has no source field???

epc8@juno.com wrote:
> arrbee wrote: 
>
> What happens if the PIC is 9(50) instead of X(50)?

Another compilation error - PIC 9(18) is the max, AFAIK...

--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          daniel@thebelowdomain         ~
~ _____ /  \      |  ~      http://www.djs-consulting.com     ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

"Who is more irrational?  A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine

Thanks a lot Rick. I believe there are set of rules on the usage of
these functions. I find it simpler by using it then get a compilation
error and finally fix it. It required much knowledge to make use of
these functions. It is not easy.

arrbee wrote:
> Thanks a lot Rick. I believe there are set of rules on the usage of
> these functions. I find it simpler by using it then get a compilation
> error and finally fix it. It required much knowledge to make use of
> these functions. It is not easy.
>
>
Reading before doing is a valid alternative (no matter how seldom it is
used) to trial and error.

http://publibz.boulder.ibm.com/cgi-.../IGY3LR30/7.1.4

Seems like a pretty good place to "start" your research on such things.

P.S.  IBM has some extensions to the '89 Intrinsic Function amendment - but 
does
NOT allow everything allowed in the '02 Standard or as extensions to some ot
her
implementations.

--
Bill Klein
wmklein <at> ix.netcom.com
"arrbee" <arrbee@gmail.com> wrote in message
news:1145941014.402235.290620@u72g2000cwu.googlegroups.com...
> Thanks a lot Rick. I believe there are set of rules on the usage of
> these functions. I find it simpler by using it then get a compilation
> error and finally fix it. It required much knowledge to make use of
> these functions. It is not easy.
>