Re: Invalid decimal data

You are not very specific about your needs.

I have somewhere an RPG/400 program to _list_ an overview over decimal data 
errors. It reads the file field description, then the
file (all fields read into alpha array, tests/moves it into numeric fields and 
then lists it.

You can easily modify this program to do an update.

Do you want me to find this program? Warning: No guarantee. It is not polished 
for release as freeware.

Henrik
http://hkrebs.dk


> From: "Fisher, Don" <DRF@HeiligMeyers.com>
> To: midrange-l@midrange.com
> Subject: Invalid decimal data
> Date: Mon, 27 Aug 2001 09:17:50 -0400
> Reply-To: midrange-l@midrange.com
>
> We have a series of files, possible all of them, containing invalid decimal
> data in some fields.  The only two ways I can think of to identify them are
> to create an RPG program that will interrogate each field by executing a
> Z-ADD operation and checking the error indicator or to execute an SQL
> statement using each numeric field in the selection criteria.  The statement
> should fail upon encountering invalid decimal data.  The trouble with the
> latter method is it won't allow me to fix the data.  At least I don't think
> so.
>
> Does anyone out there know a more pleasant and convenient way to do this?
>
> Any help, as always, will be greatly appreciated.
>
> Donald R. Fisher, III
> Project Manager
> Heilig-Meyers Furniture Company
> (804) 784-7500 ext. 2124
> Don.Fisher@HeiligMeyers.com
>
>
> --__--__--
>
> Message: 8
> From: "Art Tostaine, Jr." <art@link400.com>
> To: <midrange-l@midrange.com>
> Subject: RE: Hotels At COMMON
> Date: Mon, 27 Aug 2001 09:37:41 -0400
> Reply-To: midrange-l@midrange.com
>
> While I understand why Common needs the bookings, I've heard before that the 
>best possible rate can be had by booking with
whatever
> conference you are attending.  This is almost never true.
>
> Usually AAA rates are better.
>
> _________________
> Art Tostaine, Jr.
> CCA, Inc.
> Jackson, NJ 08527
>
> >
> > I fully understand why some people need to minimize their costs in order to
> > attend COMMON. But I thought I'd take a moment to explain there are some 
>long
> > term impacts if too many people stay outside COMMON housing. When we book a
> > conference, we negotiate the best possible deal with the conference center 
>and
> > the hotels, as a package. In most cities, the hotels and the conference 
>center
>
>
> --__--__--
>
> Message: 9
> Date: Mon, 27 Aug 2001 08:57:32 -0500
> From: Chuck Lewis <clewis@iquest.net>
> To: midrange-l@midrange.com
> Subject: Re: CLRLIB QRPLOBJ?? (was Re: IPL regains storage.......but)
> Reply-To: midrange-l@midrange.com
>
> Well I DEFINITELY saw a BUNCH of PTF objects in QRPLOBJ so sorry Al, no 
>disrespect but
> the PTF process DOES use QRPLOBJ and that is verified by Alexei's earlier 
>post and does
> make sense based on how he explains it. Interesting as I worked on through 
>some more PTF
> per applies Friday evening, 5769999 and 576SS1 seem to not put anything in 
>QRPLOBJ so
> the system must be able to work with them and not find locks or anything. All 
>the PTF
> objects I saw in QRPLOBJ were as a result of Perm Applying Programming 
>Language,
> Performance Tool, Service Director, Client Access, Query, etc. related 
>PTF's...
>
> So Neil, you are OK in your logic :-)
>
> Chuck
>
> neilp@dpslink.com wrote:
>
> > I was basing this on the email from Chuck Lewis where he said he saw a lot
> > of system objects in QRPLOBJ after he permanently applied a lot of PTF's.
> > That sort of surprised me too.
> >
> > ...Neil
>
>
> --__--__--
>
> Message: 10
> Date: Mon, 27 Aug 2001 09:06:38 -0500
> From: Chuck Morehead <cbmorehead@nokuse.com>
> Subject: Re: Invalid decimal data
> To: midrange-l@midrange.com
> Reply-To: midrange-l@midrange.com
>
> Don,
>
> Do you have an algorithm to fix the data?  I.e., how do you determine what
> the value should be?
>
> IIRC, I had a situation where a field was messed up and should have been 0.
> So I could "UPDATE filename SET fieldname = 0 WHERE (fieldname < 0) OR
> (fieldname > 99999)".  This worked because I knew it should not be negative
> and it was a 5-digit zoned decimal field, so 99999 was the largest value it
> could hold.
>
> I haven't used SQL to fix dec data errors in a few years - so I don't know
> what may have changed as to how it handles these errors.  I.e., will the SQL
> command fail when it reads a dec data error?  I'm not sure on newer
> releases.
>
> Chuck
>
> ----- Original Message -----
> From: "Fisher, Don" <DRF@HeiligMeyers.com>
> To: <midrange-l@midrange.com>
> Sent: Monday, August 27, 2001 8:17 AM
> Subject: Invalid decimal data
>
>
> > We have a series of files, possible all of them, containing invalid
> decimal
> > data in some fields.  The only two ways I can think of to identify them
> are
> > to create an RPG program that will interrogate each field by executing a
> > Z-ADD operation and checking the error indicator or to execute an SQL
> > statement using each numeric field in the selection criteria.  The
> statement
> > should fail upon encountering invalid decimal data.  The trouble with the
> > latter method is it won't allow me to fix the data.  At least I don't
> think
> > so.
> >
> > Does anyone out there know a more pleasant and convenient way to do this?
> >
> > Any help, as always, will be greatly appreciated.
> >
> > Donald R. Fisher, III
> > Project Manager
> > Heilig-Meyers Furniture Company
> > (804) 784-7500 ext. 2124
> > Don.Fisher@HeiligMeyers.com
> >
> > _______________________________________________
> > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> > To post a message email: MIDRANGE-L@midrange.com
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> > or email: MIDRANGE-L-request@midrange.com
> >
> >
>
>
> --__--__--
>
> Message: 11
> From: "Phil" <sublime78ska@yahoo.com>
> To: <midrange-l@midrange.com>
> Subject: RE: CLRLIB QRPLOBJ?? (was Re: IPL regains storage.......but)
> Date: Mon, 27 Aug 2001 10:24:05 -0400
> Reply-To: midrange-l@midrange.com
>
> I've seen applications use QRPLOBJ as a persistant QTEMP.
>
> I've never had trouble clearing QRPLOBJ.  I have done it as part of nightly
> backup jobs because QRPLOBJ can get huge if you IPL infrequently (depends on
> what you do on your system).
>
> I don't run into any PTF issues because I only apply *perm in preparation
> for a release upgrade, and I include an IPL with that preparation.  I like
> to deal with as few variables at a time.
>
> my two cents
>
> Phil
>
> > -----Original Message-----
> > From: midrange-l-admin@midrange.com
> > [mailto:midrange-l-admin@midrange.com]On Behalf Of Chuck Lewis
> > Sent: Monday, August 27, 2001 9:58 AM
> > To: midrange-l@midrange.com
> > Subject: Re: CLRLIB QRPLOBJ?? (was Re: IPL regains storage.......but)
> >
> >
> > Well I DEFINITELY saw a BUNCH of PTF objects in QRPLOBJ so sorry
> > Al, no disrespect but
> > the PTF process DOES use QRPLOBJ and that is verified by Alexei's
> > earlier post and does
> > make sense based on how he explains it. Interesting as I worked
> > on through some more PTF
> > per applies Friday evening, 5769999 and 576SS1 seem to not put
> > anything in QRPLOBJ so
> > the system must be able to work with them and not find locks or
> > anything. All the PTF
> > objects I saw in QRPLOBJ were as a result of Perm Applying
> > Programming Language,
> > Performance Tool, Service Director, Client Access, Query, etc.
> > related PTF's...
> >
> > So Neil, you are OK in your logic :-)
> >
> > Chuck
> >
> > neilp@dpslink.com wrote:
> >
> > > I was basing this on the email from Chuck Lewis where he said
> > he saw a lot
> > > of system objects in QRPLOBJ after he permanently applied a lot
> > of PTF's.
> > > That sort of surprised me too.
> > >
> > > ...Neil
> >
> > _______________________________________________
> > This is the Midrange Systems Technical Discussion (MIDRANGE-L)
> > mailing list
> > To post a message email: MIDRANGE-L@midrange.com
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> > or email: MIDRANGE-L-request@midrange.com
> >
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> --__--__--
>
> Message: 12
> Subject: Re: Invalid decimal data
> To: midrange-l@midrange.com
> From: fiona.fitzgerald@notes.royalsun.com
> Date: Mon, 27 Aug 2001 15:13:25 +0100
> Reply-To: midrange-l@midrange.com
>
>
>
> Donald,
>      I came across this when migrating old S/36 files to a 400 machine. In
> that instance, the fields in error were all alphanumeric fields mapping to
> packed numeric fields.
>
> The RPG would bomb out at that point, & I would just note the relative
> record number & UPDDTA
> & correct the entry. Talk about a kludge.
>
> Maybe if the specification had been correct to begin with, I might have
> attempted a TESTN before writing the new records.  But we were led to
> believe that the data all fell into certain categories with defined values.
> Ha ! Tell the users that - nothing stopped them entering gibberish ...
>
> Fiona
>
>
> --__--__--
>
> Message: 13
> Date: Mon, 27 Aug 2001 09:28:43 -0500
> From: Chuck Lewis <clewis@iquest.net>
> To: midrange-l@midrange.com
> Subject: Re: CLRLIB QRPLOBJ?? (was Re: IPL regains storage.......but)
> Reply-To: midrange-l@midrange.com
>
> I agree Phil.
>
> I usually only remember to apply PTF's perm as part of an upgrade :-) and the
> only reason I imagine I even noticed this (PTF objects in QRPLOBG) is that we
> are so cramped for disk space. I was doing the apply early so I could get it 
>out
> of the way for the weekend IPL.
>
> Chuck
>
> Phil wrote:
>
> > I've seen applications use QRPLOBJ as a persistant QTEMP.
> >
> > I've never had trouble clearing QRPLOBJ.  I have done it as part of nightly
> > backup jobs because QRPLOBJ can get huge if you IPL infrequently (depends on
> > what you do on your system).
> >
> > I don't run into any PTF issues because I only apply *perm in preparation
> > for a release upgrade, and I include an IPL with that preparation.  I like
> > to deal with as few variables at a time.
> >
> > my two cents
> >
> > Phil
>
>
> --__--__--
>
> Message: 14
> From: "Fisher, Don" <DRF@HeiligMeyers.com>
> To: "'midrange-l@midrange.com'" <midrange-l@midrange.com>
> Subject: RE: Invalid decimal data
> Date: Mon, 27 Aug 2001 10:23:22 -0400
> Reply-To: midrange-l@midrange.com
>
> That's what I was thinking with the SQL statement, but I seem to remember
> trying this recently and having the statement simply die when the offending
> record was read.
>
> I'll try it again, though.
>
> Thanks.
>
> Donald R. Fisher, III
> Project Manager
> Heilig-Meyers Furniture Company
> (804) 784-7500 ext. 2124
> Don.Fisher@HeiligMeyers.com
>
> <clip>
> IIRC, I had a situation where a field was messed up and should have been 0.
> So I could "UPDATE filename SET fieldname = 0 WHERE (fieldname < 0) OR
> (fieldname > 99999)".  This worked because I knew it should not be negative
> and it was a 5-digit zoned decimal field, so 99999 was the largest value it
> could hold.
> <clip>
>
>
> --__--__--
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) digest list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
>
>
>
> End of MIDRANGE-L Digest
>