× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Yes, it would be "fun" to write this from scratch...we used two tools to help us convert from 36 style to 400 style data base files.

TAA tools VALDBF. Worth the price of admission just for this tool if you have a bunch (valmnydbf).

Also, DBU showed bad data fields. Took some paging up and down, but for small files, worked well.

Mike Krebs

----- Original Message ----
From: Thomas Garvey <tgarvey@xxxxxxxxxx>
To: RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
Sent: Friday, June 20, 2008 1:46:30 PM
Subject: RE: Handling decimal data errors at the field level

That's exactly what this program is intended to do.. Find out what's broken
so it can be researched to correct the problem. But having a program hard
halt is not the way to do that.


Best Regards,

Thomas Garvey
Unbeaten Path International
Office: 630-462-3991
web: www.unpath.com

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Barbara Morris
Sent: Friday, June 20, 2008 12:58 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Handling decimal data errors at the field level

Thomas Garvey wrote:

Has anyone had any experience handling decimal data errors at the
field level? I know you can trap for the decimal data error that
happens when a record is read that contains a decimal data error in
one of the field values, and I know you can set the FIXNBR parameter
on the RPG compile to automatically fix numeric values that are bad.
But I want to know which specific field(s) in the record were bad.
It's OK that the compiler will fix them for me, but I want to know which
field(s) in the record were fixed.


I think it's bad that the compiler will fix them for you. FIXNBR and its
evil twin IGNDECERR only serve to hide problems.

There's no way to trap errors on I specs within the program; you could only
get granular information if you read into a data structure.

Once you have your data structure, you can use MONITOR to locate the problem
fields.

read file ds;
monitor;
chkds.price = ds.price;
on-error;
-- report the error with PRICE
endmon;
monitor;
chkds.discount = ds.discount;
on-error;
-- report the error with DISCOUNT
endmon;

Maybe I'm naive to say this, but I think it would be better to let the
program crash on the I spec, find out which I spec it was on from the joblog
or the formatted dump, and then figure out why the file had bad decimal data
in that field. Correct the problem, and repeat, until the file isn't
getting any more bad decimal data.

(I'm sure there are much more direct ways to figure out which fields are bad
in a file. I think even CPYF can do it, if you force it to do a mapping
from packed to zoned, or zoned to packed.)

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.