Author |
Message |
Walter S. Ru #1 / 18
|
 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 |
|
 |
robi #2 / 18
|
 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 |
|
 |
glen herrmannsfel #3 / 18
|
 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 |
|
 |
Gunnar Ophei #4 / 18
|
 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 |
|
 |
Walter S. Ru #5 / 18
|
 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 |
|
 |
robi #6 / 18
|
 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 |
|
 |
James J. Weinka #7 / 18
|
 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 |
|
 |
Gunnar Ophei #8 / 18
|
 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 |
|
 |
Robi #9 / 18
|
 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 |
|
 |
John W. Kenned #10 / 18
|
 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 |
|
 |
glen herrmannsfel #11 / 18
|
 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 |
|
 |
Robi #12 / 18
|
 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 |
|
 |
James J. Weinka #13 / 18
|
 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 |
|
 |
Walter S. Ru #14 / 18
|
 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 |
|
 |
Walter S. Ru #15 / 18
|
 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 |
|
|
Page 1 of 2
|
[ 18 post ] |
|
Go to page:
[1]
[2] |
|