PL/I v2.3 Fixedoverflow 
Author Message
 PL/I v2.3 Fixedoverflow

In a PL/I subroutine (two levels below MAIN) I am experiencing a
stubborn fixed overflow unexplained by either data or the environment.
The OS and/or compiler, I know, are the last thing one should suspect.
Nevertheless, I am at my wits end and want at least to rule them out.

The essentials are as follows:

        DCL COST        FIXED DEC(15,7),
        1 SAVED_WORK_AREA     BASED (SAVED_WRK_PTR),  [SAVED_WRK_PTR is passed
parameter]
          5 SAVED_OVERLAY(30),
            10 SAVED_EL_NAME  CHAR(8),
            10 SAVED_EL_TYPE  CHAR(3),
            10 SAVED_EL_RES   FIXED DEC(15,7);

        SAVED_EL_RES(1) =                0.4600000;
        SAVED_EL_RES(4) =               32.0000000;

        COST = MULTIPLY(SAVED_EL_RES(1),SAVED_EL_RES(4),15,7);

        IBM482I  'ONCODE'=0310  'FIXEDOVERFLOW' CONDITION RAISED
           AT OFFSET +000382 IN PROCEDURE WITH ENTRY M120_CALCULATE_COST

PUT LISTs just prior to the MULTIPLY confirm the shown SAVED_EL values,
so there don't seem to be any decimal errors.  Instead of a FOFL, the
result should equal around 17.7, obviously far less than the maximum.

The environment is PL/I v2.3 under OS/390 v2.5 at maint level 9906 and
RSU level 9908.

The PL/I compile parms include CMPAT(V1), SYSTEM(MVS),
LANGLVL(OS,NOSPROG).  The same error occurred under CMPAT(V2).

Any suggestions would be much appreciated.

Thanks in advance...

-Walter Rue



Sun, 25 Aug 2002 03:00:00 GMT  
 PL/I v2.3 Fixedoverflow

Quote:
> In a PL/I subroutine (two levels below MAIN) I am experiencing a
> stubborn fixed overflow unexplained by either data or the environment.
> The OS and/or compiler, I know, are the last thing one should suspect.
> Nevertheless, I am at my wits end and want at least to rule them out.

I think that the implementation maximum has been exceeded.  The
intermediate product will have 14 decimal digits, thus
the most-significant digit "1" in the product will be lost.
Quote:
> The essentials are as follows:

>    DCL COST        FIXED DEC(15,7),
>    1 SAVED_WORK_AREA     BASED (SAVED_WRK_PTR),  [SAVED_WRK_PTR is passed
> parameter]
>      5 SAVED_OVERLAY(30),
>        10 SAVED_EL_NAME  CHAR(8),
>        10 SAVED_EL_TYPE  CHAR(3),
>        10 SAVED_EL_RES   FIXED DEC(15,7);

>    SAVED_EL_RES(1) =                0.4600000;
>    SAVED_EL_RES(4) =               32.0000000;

>    COST = MULTIPLY(SAVED_EL_RES(1),SAVED_EL_RES(4),15,7);

>    IBM482I  'ONCODE'=0310  'FIXEDOVERFLOW' CONDITION RAISED
>       AT OFFSET +000382 IN PROCEDURE WITH ENTRY M120_CALCULATE_COST

> PUT LISTs just prior to the MULTIPLY confirm the shown SAVED_EL values,
> so there don't seem to be any decimal errors.  Instead of a FOFL, the
> result should equal around 17.7, obviously far less than the maximum.

> The environment is PL/I v2.3 under OS/390 v2.5 at maint level 9906 and
> RSU level 9908.

> The PL/I compile parms include CMPAT(V1), SYSTEM(MVS),
> LANGLVL(OS,NOSPROG).  The same error occurred under CMPAT(V2).

> Any suggestions would be much appreciated.

> Thanks in advance...

> -Walter Rue



Mon, 26 Aug 2002 03:00:00 GMT  
 PL/I v2.3 Fixedoverflow

Quote:


>> In a PL/I subroutine (two levels below MAIN) I am experiencing a
>> stubborn fixed overflow unexplained by either data or the environment.
>> The OS and/or compiler, I know, are the last thing one should suspect.
>> Nevertheless, I am at my wits end and want at least to rule them out.
>I think that the implementation maximum has been exceeded.  The
>intermediate product will have 14 decimal digits, thus
>the most-significant digit "1" in the product will be lost.
>> The essentials are as follows:

OK, at the hardware level it is 4600000*320000000=
1472000000000000, and then seven low digits are removed, for a result
of 147200000, or 14.72.  The hardware can multiply with 15 digit multipliers,
and 15 digit multiplicands, for a 31 digit (with the leftmost always 0)
product.  Now you have to look at the PL/I rules for doing the multiply.

-- glen

Quote:
>      SAVED_EL_RES(1) =                0.4600000;                            
>>      SAVED_EL_RES(4) =               32.0000000;                            

>>      COST = MULTIPLY(SAVED_EL_RES(1),SAVED_EL_RES(4),15,7);                  



Tue, 27 Aug 2002 03:00:00 GMT  
 PL/I v2.3 Fixedoverflow


Quote:


>>> In a PL/I subroutine (two levels below MAIN) I am experiencing a
>>> stubborn fixed overflow unexplained by either data or the environment.
>>> The OS and/or compiler, I know, are the last thing one should suspect.
>>> Nevertheless, I am at my wits end and want at least to rule them out.
>>I think that the implementation maximum has been exceeded.  The
>>intermediate product will have 14 decimal digits, thus
>>the most-significant digit "1" in the product will be lost.
> OK, at the hardware level it is 4600000*320000000=
> 1472000000000000, and then seven low digits are removed, for a result
> of 147200000, or 14.72.  The hardware can multiply with 15 digit
multipliers,
> and 15 digit multiplicands, for a 31 digit (with the leftmost always 0)
> product.  Now you have to look at the PL/I rules for doing the multiply.

I think the hardware will allow a 31 digit multiplicand, and this field
will also receive the result.  From the PoP:

"The multiplier length cannot exceed 15 digits and  sign  (L2  not  greater
than  seven)  and  must be less than the multiplicand length (L2 less than
L1); otherwise, a specification exception is recognized.

The multiplicand must have at least as many bytes of leftmost zeros as the
number of  bytes  in  the  multiplier;  otherwise,  a  data  exception  is
recognized.  This restriction ensures that no product overflow occurs."

The rules for multiplication precision in PL/I is p=p1+p2+1, q=q1+q2.  For
(p1,q1)=(p2,q2)=(15,7) it will give (p,q)=(31,14), i.e. within
implementation limits.

PL/I V2.3 generates (for a=multiply(b,c,15,7) where all a,b,c is dec
fixed(15,7):

F8 F7 D 098 D 0C0         ZAP   WKSP.1+32(16),B(8)
FC F7 D 098 D 0C8         MP    WKSP.1+32(16),C(8)
F1 7B D 0E0 D 098         MVO   224(8,13),WKSP.1+32(12)
D1 00 D 0E7 D 0A7         MVN   231(1,13),WKSP.1+47
D2 07 D 0B8 D 0E0         MVC   A(8),224(13)

This should work with the values given.  I cannot see any way this would
raise an overflow condition.

go.



Thu, 29 Aug 2002 03:00:00 GMT  
 PL/I v2.3 Fixedoverflow
Thanks for all your comments so far.  I forwarded Robin's note to the
support person handling this and reran the abend with a SYSMDUMP, which
allowed them to use a certain unnamed diagnostic tool.  IBM then
responded with a PTF for the compiler.

Friday (3/10), with the patched compiler, I recompiled the module that
contained the offending MULTIPLY plus three others, including the two
parent CALLers, but in  rerunning the abend recurred.

So now I am recompiling all the other subroutines, about thirty of
them.  Regardless, I suspect that the real problem is local to the
MULTIPLY and that these other compiles, while perhaps eliminating a
question, will not make a difference (but I would be glad to be wrong).

I'll post again when we make some real progress.

-Walter Rue

Quote:

> In a PL/I subroutine (two levels below MAIN) I am experiencing a
> stubborn fixed overflow unexplained by either data or the environment.
> The OS and/or compiler, I know, are the last thing one should suspect.
> Nevertheless, I am at my wits end and want at least to rule them out.

> The essentials are as follows:

>         DCL COST        FIXED DEC(15,7),
>         1 SAVED_WORK_AREA     BASED (SAVED_WRK_PTR),  [SAVED_WRK_PTR is passed
> parameter]
>           5 SAVED_OVERLAY(30),
>             10 SAVED_EL_NAME  CHAR(8),
>             10 SAVED_EL_TYPE  CHAR(3),
>             10 SAVED_EL_RES   FIXED DEC(15,7);

>         SAVED_EL_RES(1) =                0.4600000;
>         SAVED_EL_RES(4) =               32.0000000;

>         COST = MULTIPLY(SAVED_EL_RES(1),SAVED_EL_RES(4),15,7);

>         IBM482I  'ONCODE'=0310  'FIXEDOVERFLOW' CONDITION RAISED
>            AT OFFSET +000382 IN PROCEDURE WITH ENTRY M120_CALCULATE_COST

> PUT LISTs just prior to the MULTIPLY confirm the shown SAVED_EL values,
> so there don't seem to be any decimal errors.  Instead of a FOFL, the
> result should equal around 17.7, obviously far less than the maximum.

> The environment is PL/I v2.3 under OS/390 v2.5 at maint level 9906 and
> RSU level 9908.

> The PL/I compile parms include CMPAT(V1), SYSTEM(MVS),
> LANGLVL(OS,NOSPROG).  The same error occurred under CMPAT(V2).

> Any suggestions would be much appreciated.

> Thanks in advance...

> -Walter Rue



Thu, 29 Aug 2002 03:00:00 GMT  
 PL/I v2.3 Fixedoverflow

Quote:

> PL/I V2.3 generates (for a=multiply(b,c,15,7) where all a,b,c is dec
> fixed(15,7):

> F8 F7 D 098 D 0C0         ZAP   WKSP.1+32(16),B(8)
> FC F7 D 098 D 0C8         MP    WKSP.1+32(16),C(8)
> F1 7B D 0E0 D 098         MVO   224(8,13),WKSP.1+32(12)
> D1 00 D 0E7 D 0A7         MVN   231(1,13),WKSP.1+47
> D2 07 D 0B8 D 0E0         MVC   A(8),224(13)

> This should work with the values given.  I cannot see any way this would
> raise an overflow condition.

Did you try it with the values that caused the failure?
Quote:
> go.



Thu, 29 Aug 2002 03:00:00 GMT  
 PL/I v2.3 Fixedoverflow
In your original post you stated that you are using PL/I v2.3 on OS/390 V.25.

A reply by Gunnar Opheim shows the object code generated for what would appear
to be a simplified but equivalent problem in which simple scalar variables have
been substituted for members of a complicated array of structures.  However,
although he seems to be using the same compiler version, he does not say which
os/hardware he is running under.

Have you tried generating an object listing for your problem and/or the
simplified abstraction of it?

If you get the same compiled code then you have indeed stumbled upon a deep
mystery.

If, on the other hand, the compiler uses a length of 8 (15 digits plus sign)
instead of 16 (31 digits plus sign) for the multiplicand when compiling for
your os and hardware that would explain why you are getting the fixed overflow,
because the intermediate result for the data values you are using requires 14
fractional places and two integer places for a total of 16 digits of
precision.  In fact, the multiplicand field must have enough complete bytes of
high order zeros to completely contain the multiplier field (even if the
multiplier is zero) or else a data exception will be raised.

Interestingly enough, while Gunnar's compiler/system and the PL/I personal
compiler for OS/2 both produce the result you want and therefore give you
reason to hope that yours can (and perhaps will) be fixed to work the same way,
a careful reading of the description of the multiply built-in function leaves
one scratching one's head:

I have looked a three different versions, and while they all are worded
slightly differently, they all in essence say that

multiply(a,b,p,q)

returns the product of a and b with precision (p,q) and that the computation is
carried out with a precision p throughout and that p must not exceed N, the
implementation defined maximum precision.  For fixed decimal, N is 15.  So it
is not clear that your result actually violates the specifications even though
some implementations seem to deliver more than what has been promised.



Thu, 29 Aug 2002 03:00:00 GMT  
 PL/I v2.3 Fixedoverflow


Quote:

> Did you try it with the values that caused the failure?

Yes.  The result was 14.7200000
No overflow.
As I said, there was no instruction in the generated code that could cause
overflow.

go.



Fri, 30 Aug 2002 03:00:00 GMT  
 PL/I v2.3 Fixedoverflow

Quote:


> > Did you try it with the values that caused the failure?

> Yes.  The result was 14.7200000
> No overflow.
> As I said, there was no instruction in the generated code that could cause
> overflow.

But there appears to be no test for overflow, and there is
needs to be when the truncation from 31 digits to 15 digits
takes place.

Did you have SIZE and FIXEDOVERFLOW enabled?

Quote:
> go.



Fri, 30 Aug 2002 03:00:00 GMT  
 PL/I v2.3 Fixedoverflow

Quote:

> But there appears to be no test for overflow, and there is
> needs to be when the truncation from 31 digits to 15 digits
> takes place.

That doesn't constitute FIXEDOVERFLOW, only SIZE.

--
-John W. Kennedy

Compact is becoming contract
Man only earns and pays.  -- Charles Williams



Sat, 31 Aug 2002 03:00:00 GMT  
 PL/I v2.3 Fixedoverflow

Quote:

>> But there appears to be no test for overflow, and there is
>> needs to be when the truncation from 31 digits to 15 digits
>> takes place.
>That doesn't constitute FIXEDOVERFLOW, only SIZE.

Multiplying fixed decimal(15,7) by (15,7) with a (15,7) product
removes the low 7 digits of the (30,14) product.  This is done
with MVO (move with offset), which, as far as I remember, doesn't
generate fixed overflow.

-- glen



Sun, 01 Sep 2002 03:00:00 GMT  
 PL/I v2.3 Fixedoverflow

Quote:
> > But there appears to be no test for overflow, and there is
> > needs to be when the truncation from 31 digits to 15 digits
> > takes place.

> That doesn't constitute FIXEDOVERFLOW, only SIZE.

FIXEDOVERFLOW occurs when a value of n ssignificantd digits
is assigned to a variable whose capacity is m significant digits,
and m <n.
In this case, the source is 31 digits.  The destination is
15 digits.
There needs to be a test for FIXED OVERFLOW, and there
didn't appear to be one in the code.

SIZE is raised when a variable exceeds the declared size
of a variable but not the implementation size of the variable.
In decimal work, this may occur when an even number of ditits
is declared, and the hardware offers the next highest odd number of
digits.

In this case, SIZE is irrelevant.

Quote:
> --
> -John W. Kennedy

> Compact is becoming contract
> Man only earns and pays.  -- Charles Williams



Sun, 01 Sep 2002 03:00:00 GMT  
 PL/I v2.3 Fixedoverflow
Quote from the Language Reference:

re FIXEDOVERFLOW:

The FIXEDOVERFLOW computational condition is raised when the length of the
result of a fixed-point             arithmetic operation exceeds the maximum
length allowed by the implementation.

re SIZE:

The SIZE computational condition is raised only when high-order (that is,
leftmost) significant binary or             decimal digits are lost in an
attempted assignment to a variable or an intermediate result or in
an             input/output operation. This loss can result from a conversion
involving different data types, different bases, different scales, or different
precisions. The size condition is not enabled unless it appears in a condition
prefix.

SIZE is raised when the size of the value being assigned to a data item exceeds
the declared (or default)             size of the data item, even if this is
not the actual size of the storage that the item occupies. For example, a fixed
binary item of precision (20) occupies a fullword in storage, but SIZE is
raised if a value whose size exceeds FIXED BINARY(20) is assigned to it.

Because checking sizes requires substantial overhead in both storage space and
run time, the SIZE condition is primarily used for program testing. It can be
removed from production programs. For more information on test and production
application programs, refer to the Programming Guide.

The SIZE condition differs from the FIXEDOVERFLOW condition in that
FIXEDOVERFLOW is raised when the
size of a calculated fixed-point value exceeds the maximum allowed by the
implementation. SIZE can be
raised on assignment of a value regardless of whether or not FIXEDOVERFLOW was
raised in the calculation
of that value.

If the SIZE condition is raised and it is disabled, the program is in error.

End of quote.

Note that FIXEDOVERFLOW can only result from performing an arithmetic
operation, whereas SIZE results from an attempt to assign a value to a variable
or an intermediate target.

Note also that the original question that led to this thread involved use of
the MULTIPLY builtin function.  The actual values used in that example will
cause a FIXEDOVERFLOW if the MULTIPLY builtin function is not used.  Here is
the specification for MULTIPLY from the language reference:

MULTIPLY returns the product of x and y, with a precision specified by p and q.
The base, scale, and mode of the result are determined by the rules for
expression evaluation.

  MULTIPLY(x,y,p{,q})

  x and y  Expressions.

  p Restricted expression that specifies the number of digits to be maintained
throughout the operation.

  q Restricted expression that specifies the scaling factor of the result. For
a fixed-point result, if q
    is omitted, a scaling factor of zero is assumed. For a floating-point
result, q must be omitted.

Note that the specification only promises to maintain p (15 in the example at
hand and the maximum allowed for FIXED DECIMAL) digits of precision throughout
the computation.  In fact every implementation that I have personally used
seems to have implemented MULTIPLY so that FIXEDOVERFLOW cannot occur.  In
other words, the MULTIPLY builtin function essentially gives access to the
double length product that results from using the underlying hardware to
multiply two numbers even though this result has greater precision than any
legal PL/I number.  The p and q arguments specify the precision and scale
factor of a legal PL/I fixed point number that is to be extracted from this
result that exists but cannot be legally described in PL/I.

In the example at hand with (a,b,c) fixed decimal(15,7), a=.46; b=32;

c=a*b raised FIXEDOVERFLOW because * applied to two (15,7) operands gives a
(15,14) result (which is of implementation maximum precision and the actual
data would require (16,14) which does not exist in the implementation.

c=multiply(a,b,15,7) does not raise any conditions and gives the correct result
of 14.72.

c=multiply(a,b,8,7) raises the SIZE condition because a significant digit is
lost in assigning the result of the hardware multiply to the intermediate
target of precision (8,7) even though it is going to be assigned to a (15,7)
variable immediately thereafter.

In the original example there are no data values which could cause
FIXEDOVERFLOW but many combinations of values which could raise the SIZE
condition.

The original poster must have been running on a compiler/system with a bug
somewhere since he got a FIXEDOVERFLOW with this data.

A couple of additional possibilities occur to me:

The original poster was running under

The environment is PL/I v2.3 under OS/390 v2.5 at maint level 9906 and
RSU level 9908.

The PL/I compile parms include CMPAT(V1), SYSTEM(MVS),
LANGLVL(OS,NOSPROG).  The same error occurred under CMPAT(V2).

1) do any of these options change the semantics of MULTIPLY, the maximum
precision or any other relevant conditions?  What code is actually compiled
with this combination of compiler options?

2) Has it been established that the FIXEDOVERFLOW actually occurred during the
MULTIPLY builtin function and not somewhere else.  It seems to me that this is
just being taken for granted.  The assembly code that another poster has shown
simply cannot overflow. Maybe we are looking under the lamp post when the keys
are in the dark alley.



Sun, 01 Sep 2002 03:00:00 GMT  
 PL/I v2.3 Fixedoverflow
Re the original problem, I think (hope) this is now finally resolved.

The PTF failure I reported earlier was a case of mistaken identity.
Though I thought the correct(ed) compiler library was in my STEPLIB, in
fact it was elsewhere.  Once we figured that out, the fix worked.  The
PTF is UQ35597, applied to the compiler only.  If anyone needs more
particulars, I can put you in touch the person responsible.

Following is a copy of the LIST option outputs (unwrapped), before and
after.
<<OLD>>
L     4,SAVED_WRK_PTR
LH    9,I            
MH    9,194(0,3)
LR    8,4              
ALR   8,9              
ZAP   WKSP.5+32(16),COST(8)    
MP  
WKSP.5+32(16),SAVED_WORK_AREA.SAVED_OVERLAY.SAVED_EL_RES+19(8)          
ZAP   WKSP.5+40(8),WKSP.5+32(16)  <=== removed after PTF
MVO   WKSP.5+48(16),WKSP.5+32(16)        
OI    2(12),X'80'      
MVN   WKSP.5+59(1),WKSP.5+47              
ZAP   272(8,13),WKSP.5+48(12)            
MVN   279(1,13),WKSP.5+47                
NI    2(12),X'3F'      
MVC   COST(8),272(13)

<<NEW>>
L     4,SAVED_WRK_PTR
LH    9,I
MH    9,194(0,3)
LR    8,4
ALR   8,9
ZAP   WKSP.5+32(16),COST(8)
MP    WKSP.5+32(16),SAVED_WORK_AREA.SAVED_OVERLAY.SAVED_EL_RES+19(8)
MVO   WKSP.5+48(16),WKSP.5+32(16)
OI    2(12),X'00'
MVN   WKSP.5+59(1),WKSP.5+47
ZAP   272(8,13),WKSP.5+48(12)
MVN   279(1,13),WKSP.5+47
NI    2(12),X'3F'
MVC   COST(8),272(13)

Thank you again for your interest and all your comments.  Now, all I
have to do is recompile about 600 modules and autocall relink about 150.

-Walter Rue

Quote:

> In a PL/I subroutine (two levels below MAIN) I am experiencing a
> stubborn fixed overflow unexplained by either data or the environment.
> The OS and/or compiler, I know, are the last thing one should suspect.
> Nevertheless, I am at my wits end and want at least to rule them out.

> The essentials are as follows:

>         DCL COST        FIXED DEC(15,7),
>         1 SAVED_WORK_AREA     BASED (SAVED_WRK_PTR),  [SAVED_WRK_PTR is passed
> parameter]
>           5 SAVED_OVERLAY(30),
>             10 SAVED_EL_NAME  CHAR(8),
>             10 SAVED_EL_TYPE  CHAR(3),
>             10 SAVED_EL_RES   FIXED DEC(15,7);

>         SAVED_EL_RES(1) =                0.4600000;
>         SAVED_EL_RES(4) =               32.0000000;

>         COST = MULTIPLY(SAVED_EL_RES(1),SAVED_EL_RES(4),15,7);

>         IBM482I  'ONCODE'=0310  'FIXEDOVERFLOW' CONDITION RAISED
>            AT OFFSET +000382 IN PROCEDURE WITH ENTRY M120_CALCULATE_COST

> PUT LISTs just prior to the MULTIPLY confirm the shown SAVED_EL values,
> so there don't seem to be any decimal errors.  Instead of a FOFL, the
> result should equal around 17.7, obviously far less than the maximum.

> The environment is PL/I v2.3 under OS/390 v2.5 at maint level 9906 and
> RSU level 9908.

> The PL/I compile parms include CMPAT(V1), SYSTEM(MVS),
> LANGLVL(OS,NOSPROG).  The same error occurred under CMPAT(V2).

> Any suggestions would be much appreciated.

> Thanks in advance...

> -Walter Rue



Mon, 02 Sep 2002 03:00:00 GMT  
 PL/I v2.3 Fixedoverflow
Re the original problem, I think (hope) this is now finally resolved.

The PTF failure I reported earlier was a case of mistaken identity.
Though I thought the correct(ed) compiler library was in my STEPLIB, in
fact it was elsewhere.  Once we figured that out, the fix worked.  The
PTF is UQ35597, applied to the compiler only.  If anyone needs more
particulars, I can put you in touch the person responsible.

Following is a copy of the LIST option outputs (unwrapped), before and
after.
<<OLD>>
L     4,SAVED_WRK_PTR
LH    9,I            
MH    9,194(0,3)
LR    8,4              
ALR   8,9              
ZAP   WKSP.5+32(16),COST(8)    
MP  
WKSP.5+32(16),SAVED_WORK_AREA.SAVED_OVERLAY.SAVED_EL_RES+19(8)          
ZAP   WKSP.5+40(8),WKSP.5+32(16)  <=== removed after PTF
MVO   WKSP.5+48(16),WKSP.5+32(16)        
OI    2(12),X'80'      
MVN   WKSP.5+59(1),WKSP.5+47              
ZAP   272(8,13),WKSP.5+48(12)            
MVN   279(1,13),WKSP.5+47                
NI    2(12),X'3F'      
MVC   COST(8),272(13)

<<NEW>>
L     4,SAVED_WRK_PTR
LH    9,I
MH    9,194(0,3)
LR    8,4
ALR   8,9
ZAP   WKSP.5+32(16),COST(8)
MP    WKSP.5+32(16),SAVED_WORK_AREA.SAVED_OVERLAY.SAVED_EL_RES+19(8)
MVO   WKSP.5+48(16),WKSP.5+32(16)
OI    2(12),X'00'
MVN   WKSP.5+59(1),WKSP.5+47
ZAP   272(8,13),WKSP.5+48(12)
MVN   279(1,13),WKSP.5+47
NI    2(12),X'3F'
MVC   COST(8),272(13)

Thank you again for your interest and all your comments.  Now, all I
have to do is recompile about 600 modules and autocall relink about 150.

-Walter Rue

Quote:

> In a PL/I subroutine (two levels below MAIN) I am experiencing a
> stubborn fixed overflow unexplained by either data or the environment.
> The OS and/or compiler, I know, are the last thing one should suspect.
> Nevertheless, I am at my wits end and want at least to rule them out.

> The essentials are as follows:

>         DCL COST        FIXED DEC(15,7),
>         1 SAVED_WORK_AREA     BASED (SAVED_WRK_PTR),  [SAVED_WRK_PTR is passed
> parameter]
>           5 SAVED_OVERLAY(30),
>             10 SAVED_EL_NAME  CHAR(8),
>             10 SAVED_EL_TYPE  CHAR(3),
>             10 SAVED_EL_RES   FIXED DEC(15,7);

>         SAVED_EL_RES(1) =                0.4600000;
>         SAVED_EL_RES(4) =               32.0000000;

>         COST = MULTIPLY(SAVED_EL_RES(1),SAVED_EL_RES(4),15,7);

>         IBM482I  'ONCODE'=0310  'FIXEDOVERFLOW' CONDITION RAISED
>            AT OFFSET +000382 IN PROCEDURE WITH ENTRY M120_CALCULATE_COST

> PUT LISTs just prior to the MULTIPLY confirm the shown SAVED_EL values,
> so there don't seem to be any decimal errors.  Instead of a FOFL, the
> result should equal around 17.7, obviously far less than the maximum.

> The environment is PL/I v2.3 under OS/390 v2.5 at maint level 9906 and
> RSU level 9908.

> The PL/I compile parms include CMPAT(V1), SYSTEM(MVS),
> LANGLVL(OS,NOSPROG).  The same error occurred under CMPAT(V2).

> Any suggestions would be much appreciated.

> Thanks in advance...

> -Walter Rue



Mon, 02 Sep 2002 03:00:00 GMT  
 
 [ 18 post ]  Go to page: [1] [2]

 Relevant Pages 

1. PL/I v2.3 Fixedoverflow

2. PL/I v2.3 Fixedoverflow

3. plixopt values - pl/i v2.3 LE

4. HOWTO: Install VA PL/I V2.1 on NT4 and W2K

5. PL/I V2.3.0, CICS/ESA V4.1 and LE V1.5.0

6. PL/1 v1.5 and V2.3 run-time libraries

7. Dr. Watson and VA PL/I v2.0

8. VisualAge PL/I V2.0 Announced!!

9. pl/I v1 upgrade to v2

10. FIXEDOVERFLOW vs. SIZE

11. VisualAge V2 and DB2/2 V2?

12. ANN: TclDOM v2.2 and TclXSLT v2.2

 

 
Powered by phpBB® Forum Software