Data Conversion Errors
george.j.wen@us.abb.com
george.j.wen@us.abb.com
Tue, 20 Nov 2001 11:31:23 -0600
--0__=SQJioom6bTf7xf9tI8ORb6qOaU8H4wnQ8L3ove4ywF4Nk8O6esng6LPJ
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable
Thanks to you John as well as others for your responses,
The error message is reported after running the program directly from m=
y
session. After reading your
response it reminded me that there actually are no numeric conversions =
in the
program; only caclulations.
I went one step further then and removed all 0 value Revenue records fr=
om the
run since the line of code
"tab 124 MARGIN-AMT Percent REVENUE-AMT trailing '-' pic '=AC=AC=AC=AC.=
=AC=AC=AC '" actually
performs a calculation and can produce a division by 0 situation. This=
is what
caused the errors. PH
is forgiving enough and doesn't terminate the run but cites the errors.=
Thanks all for your help.
George
|------------->
|(Embedded |
|image moved |
|to file: |
|pic07582.pcx)|
| |
|------------->
>--------------------------------------------------------------------=
----|
|"Pickering, John (NORBORD)" <PICKERIJ@norbord.com> =
|
|11/20/2001 10:54 AM =
|
>--------------------------------------------------------------------=
----|
To: George J. Wen/NB/USFAC/ABB@ABB_USFAC, powerh-l@lists.swau.edu
cc:
Subject: RE: Data Conversion Errors
Security Level:? Internal
=
George
No real answers. Just a couple of comments.
Are you sure these data conversion errors are happening in the code in =
your
example below? If the items involved are all already numeric then, stri=
ctly
speaking, there is no "conversion". Goofy values might cause calculatio=
n
errors but not conversion errors. Does the rest of your code have any c=
ode
which converts to numeric? How about date based selection or calculatio=
n?
Goofy dates have caused me more grief than arithmetic. Usually PH is pr=
etty
forgiving about calculation errors, simply returning zero and pressing =
on
regardless, so your divide by zero (using percent where revenue-amt is =
zero)
rows shouldn't cause the reported errors. But then I've never used PH o=
n an
AS/400 and I skipped all versions of PH6 on purpose.
The other comment I'd make relates to your comment about "#" symbols. T=
hese
should have nothing to do with calculation or conversion errors. They s=
imply
mean that the result cannot be displayed in the picture that you have
provided, either because the result is too big or you didn't allow for =
a
sign. The lack of "#####" in your output has nothing to do with the rep=
orted
errors.
Regards,
JWP
> -----Original Message-----
> From: george.j.wen@us.abb.com [SMTP:george.j.wen@us.abb.com]
> Sent: Monday, November 19, 2001 12:43 PM
> To: powerh-l@lists.swau.edu
> Subject: Data Conversion Errors
>
>
>
> I'm on PH 6.07F (AS/400) but this question may be gereric enough.
> I'm processing Revenue/Cost lines with a Margin Percent in Quiz.
> Calcs and defines are pretty std. Vis:
> def REVENUE-AMT float*8 =3D GLAA * -1
> def MARGIN-AMT float*8 =3D REVENUE-AMT - SDECST
> *********************************************************************=
****
> Footing........................
> tab 77 REVENUE-AMT Subtotal trailing "-" pic '=AC=AC=AC,=AC=AC=AC,=AC=
=AC=AC.=AC=AC ' &
> tab 94 SDECST Subtotal trailing "-" pic '=AC=AC=AC,=AC=AC=AC,=AC=
=AC=AC.=AC=AC '
> &
>
> tab 109 MARGIN-AMT Subtotal trailing "-" pic '=AC=AC=AC,=AC=AC=AC,=AC=
=AC=AC.=AC=AC ' &
> tab 124 MARGIN-AMT Percent REVENUE-AMT trailing "-" pic '=AC=AC=AC=AC=
.=AC=AC=AC '
>
> I don't get any errors on the report but the statistic cite them:
> records selected : 100
> ** Data conversion errors: 220666
> *********************************************************************=
****
> Revenue Amt Cost Amt Margin Amt Percent
> 34.88 270.00 235.12- 674=
.083-
> 927.75 7,237.11 6,309.36- 680.071-=
> 390.68 3,224.88 2,834.20- 725.453-=
> 971.14 8,559.20 7,588.06- 781.356-=
> 163.89 1,897.75 1,733.86- 1057.941-
> .00 1,560.00 1,560.00-
> .000
> 1,934.97 1,357.24 577.73 29.857
> 580.20 337.58 242.62 41.=
817
> 1,852.05 1,189.65 662.40 35.766=
> This sample contains some of the more unusual lines (warr) in the rep=
ort
> but there are no # signs to indicate data conversion errors and if I
> select to
> avoid getting negative Margin Amt's there's no difference in the resu=
lt.
>
> Anyone have an idea of where to look?
>
> Thank you in advance
> George
>
=
--0__=SQJioom6bTf7xf9tI8ORb6qOaU8H4wnQ8L3ove4ywF4Nk8O6esng6LPJ
Content-type: application/octet-stream;
name="pic07582.pcx"
Content-Disposition: attachment; filename="pic07582.pcx"
Content-transfer-encoding: base64
CgUBCAAAAABBADEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABQgABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAA=
--0__=SQJioom6bTf7xf9tI8ORb6qOaU8H4wnQ8L3ove4ywF4Nk8O6esng6LPJ--