Empty/Null value field gets downloaded as Junk value when data is captured into Oracle from iseries

1480 pts.
IBM iSeries
iSeries Data Transfer
When no value has been moved into a particular field in a database, then the field contains Junk value. This by itself does not cause any problem in terms of the working of the application on i series. But when the MIS team tries to download the data into Oracle, then if the file being downloaded contains one of these junk values, then the download fails. The problem is it is extremely tedious to run through all the fields in all the files of the application to identify the existence of Junk values. What we would like to know is if IBM provides any Database scanner that can identify the fields that contain Junk values.

Answer Wiki

Thanks. We'll let you know when a new response is added.

“Empty” fields shouldn’t contain junk values – they should be null if null is allowed or blank or zero.
Somehow you can get corrupt values
columns have been added and the LVLCHK is set to NO
RPG program uses internal field definition which is incorrect

Finding them … what does the junk look like?


Thanks for the Update Phil,

The programs are developed in COBOL and the field’s appears filled with ++++++++++++ sign.

Do revert if you find anything which would help prevent these Junk values.

I’m certainly not a COBOL pert — you might want to repost this with the keyword COBOL/400
Here would be my questions before proceeding
1. ++++ In both both numeric and char fields?
2. Is your application intentinally putting this in the fields?
3. Do the files have this as a default value?
4. Does your application need the ++++++++++ in these fields?
5. Can you do some “post” processing of these files prior to sending them to Oracle?

Scan and entire file (actually 1 member) – DSPPFM – find ++++ this would allow you to scan one file at a time.

I think a CL program + COBOL or RPG could be written which
1. Driving by a file containing the names of files
for each file
2. Overrides the file to an internally defined long record file
3. reads each record in file
4. if record contains +++ writes filename, record #, starting position to an error file or error report
or changes it to spaces(?)

Discuss This Question: 1  Reply

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Yorkshireman
    This is not junk. It is a deliberate, consistent value, therefore, it results from the compiler initialising the field by default, or a value being passed in by an application. I, too am not a Cobol geek. You need to track back to the source of the data, and correct the program - probably by initialising to a valid value. One further thought - you say these are being moved to Oracle. How does it interpret the hex'40' of blank in EBCDIC, or x'00' - Null. It may be the conversion which is faulty. You need to follows Phils suggestion for examining the iSeries data and understand what and where.
    6,085 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: