In this example:

 TEST: PROC OPTIONS(MAIN);

 

    DCL T CHAR(65536);

 

    DISPLAY('LENGTH(T) is ' || LENGTH(T));

 END;

 

The compiler obligingly generates this error message:

 

IBM1299I E CHARACTER extent is reduced to 32767.

 

 

And, when executed, the result is:

 

LENGTH(T) is     32767

 

However, in this example:

 

 TEST: PROC OPTIONS(MAIN);

   DCL T CHAR(DAYSTOMICROSECS(1));

   DISPLAY('LENGTH(T) is ' || LENGTH(T));

 END;

 

we have a situation where the declared size of the string is large, but not "caught" by the compiler.

The value returned from DAYSTOMICROSECONDS will be 1*(24*60*60*1000000) which is quite large.

When I compile and run that (32-bit mode), the results is:

 

   LENGTH(T) is     24576

 

It appears as if the compiler has simply masked the generated value with x'7fff' (to enforce the string limit of 32767?)

If I compile it with LIMITS(STRING(512K)) I get this:

 

  LENGTH(T) is      500654080

 

which would be the bottom 4 bytes of the result from DAYSTOMICROSECS.

 

I've looked through the language reference, but I'm not quite sure of the rules for applying this "clipping", and why

there isn't some kind of runtime error here?

 

This can also be demonstrated with this example:

 

 

 TEST: PROC OPTIONS(MAIN);

 

    VALUE: PROC RETURNS(FIXED BIN(31));

       RETURN (65537);

    END;

 

    DCL T CHAR(VALUE());

 

    DISPLAY('LENGTH(T) is ' || LENGTH(T));

 END;

 

where the result comes back as:

 

  LENGTH(T) is         1

 

When I examine the generated code, the "clipping" simply seems to be an artifact of storing the string's length into a descriptor (which is limited to 2 bytes in the default situation) so that the 4-byte value returned from the function is just dumped into the 2-byte location in the descriptor and that is the value that is used from then on.

I'm surprised there isn't some runtime acknowledgement of this clipping as there is to the compile-time limit.

And, is there something in the language reference that describes how this is to be enforced, and what a programmer can expect?

 

Why isn't the runtime value 32767 instead of 1 in that last example?  Should it be?  If so, why - and, similarly, if not why not?  And, is there a rule in the language reference that details this?  (I'm guessing there is some clause somewhere.... my eyes must have missed it.)

 

 

 

 

Just to add to this, here is an interesting result:

 

This program:

 

 TEST: PROC OPTIONS(MAIN);

 

    VALUE: PROC RETURNS(FIXED BIN(31));

       RETURN (65535);

    END;

 

    DCL T CHAR(VALUE());

 

    DISPLAY('LENGTH(T) is ' || LENGTH(T));

 END;

 

 

generates this output:

 

  LENGTH(T) is        -1

 

a negative length???  With no runtime consequences.

 

 

 

You brought up some valid points.  At the very least, I would expect the run-time to issue some type of message.  Could you open a PMR for this? 

 

Thank you,

Carolyn Phoa-Ting

PL/I Development and Service

Hello there,

 

I reviewed this with our team. Although this is not technically a defect as the length must be less than the maximum or the results are undefined, we agree that a run-time message/error would be helpful.

 

We suggest opening an RFE for this. The request can be to raise a run-time error when the above scenario occurs, either unconditionally, or only when a compiler option (such as check) is in effect. 

 

Thanks,

Carolyn Phoa-Ting

PL/I Development and Service

Have you tried compiling and running:

(FOFL, SIZE):

TEST: PROC OPTIONS(MAIN);

   DCL T CHAR(DAYSTOMICROSECS(1));

   DISPLAY('LENGTH(T) is ' || LENGTH(T));
 END;