Hex Data in File
Dieter
we have some garbage data in our files and some applications crash,
when they try to show this to the display. 3 questions:
how to stop crashing the programs?
how to avoid hex data (less than x'40')
how to clean the data
any ideas??
Dieter
--
"Why do we have to hide from the police, Daddy?"
"Because we use AS/400, son. They use NT."
Sent via Deja.com
http://www.deja.com/
Craig Rutledge
is RPG we are talking about? I would guess the same parm value is
available on create module command.
If invalid data is in a numeric field, this will set it to zero.
I would write a simple program that said *fixpacked, *fixedzoned. Read a
record, followed by an update to that record. If I understand what that
fixnbr parm means, then this should clean up the data by setting the 'bad'
numeric fields to zero.
There is also a *usrctl option on the ALLOWNULLS parm that should allow you
to process and update records that contain null fields.
I have done SQL processing that says if field is null set field to blank to
get rid of null values before RPG processing.
Please note the above is what I think should happen.
As far as protecting the display, You just about have to spin through the
character fields checking each byte for < x'40 and load a blank or some
other character into that position before exfmt/writing the display.
"Dieter" <ben...@my-deja.com> wrote in message
news:958m4l$u2s$1...@nnrp1.deja.com...
B Morris
(for example, the "zoned" value of X'1234567F' would get "fixed" to
X'F2F4F6F0'. FIXNBR(*INPUTPACKED) does set bad packed fields from I
specs to 0.
But I'm afraid that Dieter is having a problem with character data that
is less than x'40'.
Dieter, if you want to replace everything below X'40' with a blank, it's
best to use some translate function (XLATE in RPG), rather than writing
your own loop.
Your 3 questions:
1. To avoid the program crashing, get rid of the bad data (that's the
only way I know of).
2. To avoid hex data below x'40', find out where it's coming from. How
to stop it depends on its source.
3. To clean the data, you could write a program that reads each record,
does XLATE on each field with from data of X'0001...3F' to blanks,
then updates the record. Once the data is clean, add a trigger
program to your file for before WRITE and UPDATE, and clean the
data on the way into the file (or better, send an exception if you
find bad data - you will find out quickly where the bad data is
coming from).
Barbara
Dieter
thanks for your thoughts, I hoped to overlook some better solutions...
In article <3A789D52...@ca.ibm.com>,
B Morris <bmo...@ca.ibm.com> wrote:
> Craig, actually, FIXNBR(*ZONED) keeps any valid digits in bad zoned data
> (for example, the "zoned" value of X'1234567F' would get "fixed" to
> X'F2F4F6F0'. FIXNBR(*INPUTPACKED) does set bad packed fields from I
> specs to 0.
>
> But I'm afraid that Dieter is having a problem with character data that
> is less than x'40'.
that's it - there are characters less than x'40' in char data
>
> Dieter, if you want to replace everything below X'40' with a blank, it's
> best to use some translate function (XLATE in RPG), rather than writing
> your own loop.
I was looking at SQL TRANSLATE, but anyway, I've to do a lot of programming
>
> Your 3 questions:
> 1. To avoid the program crashing, get rid of the bad data (that's the
> only way I know of).
> 2. To avoid hex data below x'40', find out where it's coming from. How
> to stop it depends on its source.
It's coming from some external interfaces to other systems in diffrent
countries with a lot of codepages and character sets.
> 3. To clean the data, you could write a program that reads each record,
> does XLATE on each field with from data of X'0001...3F' to blanks,
> then updates the record. Once the data is clean, add a trigger
> program to your file for before WRITE and UPDATE, and clean the
> data on the way into the file (or better, send an exception if you
> find bad data - you will find out quickly where the bad data is
> coming from).
Re eventing the wheel for every file??? I did'nt even find better solutions
with SQL UDTs.
If there is no better way, then there is something missing in OS/400
and DB2.
thanks a lot Barabara and Craig posting to a question without answer.
Dieter
--
Rolf Mittag
define and fill a table with
* libNam
* tabNam
* colNam
for each table with columns containing hex chars < 40
write an RPGIV that initializes some fields
d blanks 64a inz(*blank)
d hex_less_40 64a inz(x'000102030405 ...')
and then loops thru the table and for each row
c eval stmt = 'update ' + %trim(libNam) + '/'
c + %trim(tabNam) + ' set ' +
%trim(colNam)
c + ' = translate(' + %trim(colNam) +
', ''' + blanks
c + ''', ''' + hex_less_40 + ''')'
c/Exec Sql
c+ execute immediate :stmt
c/End-Exec
Rolf
---------------------------
Dipl.Inf.(FH) Rolf P Mittag
Leipziger Str. 50
D-69214 Eppelheim
Fon: +49 (6221) 76 78 60
Fax: +49 (6221) 76 80 26
eMl: r...@r-m-e-d-v.de
Dieter
rather disapointing, isn't it??
no constraint, no dds keyword, no option on EXFMT, no option on compile
of program or DSPF - only a workaround to fix it!? and the next program
might damage another file!
Dieter
In article <t7in18p...@news.supernews.com>,
--
Charles R. Pence
> rather disapointing, isn't it??
> no constraint, no dds keyword, no option on EXFMT, no option on compile
> of program or DSPF - only a workaround to fix it!? and the next program
> might damage another file!
You don't really describe the error on output, nor the what/how/why the
"bad" data is getting into the alpha field, nor what you really desire
for input nor output; just that you don't want an error. Personally
I view garbage input as the place to concentrate on... since the case
of garbage-in usually yields garbage-out.
If your error is a "data can not be presented at workstation" or
similar text for a CPF5192 message, then assuming the condition
is rare, you could condition the case of XLATE of the data on
receiving that error; XLATE the data an re-present in an error
handler. That is how Query/400 works. Note too... that CPF5192
message may currently effect dumping per setting of system value
QSRVDMP; it may be desirable to CHGMSGD CPF5192 DMPLST(*NONE) if
the message is unmonitored -- and that is your concern. FWiW.
On an LF <besides SQL TRANSLATE, and similar in RPG> there is TRNTBL
keyword. On DSPF there is CHECK keyword. Without knowing that the
data is entered by a DSPF, knowing a keyword or that it is pertinent
to your scenario is merely supposition; you should detail an example
if you want good replies. FWiW I believe UIM automatically replaces
input of under x/40 values with blanks; bad if desirable per "p.s."
noted below.
p.s. All values under x/40 are not bad;;; in the 5250 datastream
they can represent color, reverse image, etc.
Regards, Chuck
All comments provided "as is" with no warranties of any kind whatsoever.
Dieter
In article <3A7A0646...@vnet.ibm.com>,
"Charles R. Pence" <crp...@vnet.ibm.com> wrote:
> Dieter wrote:
> > rather disapointing, isn't it??
> > no constraint, no dds keyword, no option on EXFMT, no option on compile
> > of program or DSPF - only a workaround to fix it!? and the next program
> > might damage another file!
>
> You don't really describe the error on output, nor the what/how/why the
> "bad" data is getting into the alpha field, nor what you really desire
> for input nor output; just that you don't want an error. Personally
> I view garbage input as the place to concentrate on... since the case
> of garbage-in usually yields garbage-out.
we have files originally designed for 5250 input and all worked well,
there is no possibility to put hex data to the alfa fields.
now we have external interfaces putting data to this files, originating
different systems of different countries and one (or some ) of the
programs generating this files and one (or some) of the programs
putting this data to our files are not correct.
And we have users, telling to us that programs crash, or that they
couldn't do their work. And we found out, that we have garbage in
our files causing this problems. In the moment I don't know exactly
which CPF message might have been caused by what data exactly and I am
analyzing what to do to avoid this in the future.
>
> If your error is a "data can not be presented at workstation" or
> similar text for a CPF5192 message, then assuming the condition
> is rare, you could condition the case of XLATE of the data on
> receiving that error; XLATE the data an re-present in an error
> handler. That is how Query/400 works. Note too... that CPF5192
> message may currently effect dumping per setting of system value
> QSRVDMP; it may be desirable to CHGMSGD CPF5192 DMPLST(*NONE) if
> the message is unmonitored -- and that is your concern. FWiW.
>
thats an interesting information; I will check it, whether it meets our
problem - I hope it will.
> On an LF <besides SQL TRANSLATE, and similar in RPG> there is TRNTBL
> keyword. On DSPF there is CHECK keyword. Without knowing that the
> data is entered by a DSPF, knowing a keyword or that it is pertinent
> to your scenario is merely supposition; you should detail an example
> if you want good replies. FWiW I believe UIM automatically replaces
> input of under x/40 values with blanks; bad if desirable per "p.s."
> noted below.
>
> p.s. All values under x/40 are not bad;;; in the 5250 datastream
> they can represent color, reverse image, etc.
Shure, I think that cursor positioning and something like this is much more
worse and maybe it prevents CPF5192 to be displayed in some circumstances.
Chuck, without any doubt the program putting the data to the file has to be
fixed, but shit happens - there will be another program and what I am looking
for is to minimize the failors and I hoped to find a possibility to find a
rule (on field level) to be implemented to the database - and a trigger
program is only a work around for this.
>
> Regards, Chuck
> All comments provided "as is" with no warranties of any kind whatsoever.
>
--