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

-- glen

"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.

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

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.

go.

Did you have SIZE and FIXEDOVERFLOW enabled?

--
-John W. Kennedy

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

-- glen

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.

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.

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

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