Help with converting Mainframe file on iSeries

pts.
Tags:
AS/400
IBM DB2
PC/Windows Connectivity
Hi there, I'm looking for some advice/help on a file that I'm having some trouble with. The file originates from a mainframe, and is sent over to our iSeries (V5R2M0) via Connect:Direct. The file is 3680 Bytes long, comprising of string and compressed numeric data. I have the layout of the file, although it's in a notation I'm not familiar with, Cobol I think it is, which gives me the start and end position of all the fields, and what type they are. My aim is to get this file from the 400 to a PC, with all the fields, in a CSV format, on a monthly basis as it's received. This solution is an interim one, probably lasting for a few months, no longer than a year. What I've done is set up a physical file, defining all 300 or so fields in the file. I then copy the file received in the Connect:Direct library into my own file using the CPYF command with a *NOCHK option. This works fine, all the records are copied, but when I query the file 1 of the fields is unreadable and I get the message "Column B9012 contains replacement character +". This field is defined in the layout file I have as: 211 09 PRRS-S1C-EDITION-NUMBER PIC S9(08) COMP. This means that the field starts at position 211 in the file. The next field starts at position 215, so I've defined my field in the physical file as: A B9012 7P 0 TEXT('S1C-EDITION-NUMBER') All the other compressed numeric fields have the notation COMP-3., whereas this one is only COMP. - I'm not sure what the difference is there. It would seem that the field is a compressed or packed numeric field, of 8, but for it to start at 211 and end at 215 I have to define it as 7 in the physical file. Do you have an idea of what I can do here? At the moment, seeing this field is not essential, after the copy file command I'm just running through the file and setting the value to 0. The next question I have is around Client Access. When I run Query, there are no errors shown in the file. However, when I try to use the "Receive File From Host" facility in Client Access, I get the error "CWBDB0052 - Error occurred during data conversion", but all records transfer successfully. I can't figure out which fields are in error, although from reading on the internet it would appear there may be null values that are causing this. I've switched off the option to display warnings during data transfer, which stops the message occurring. Would there be a problem I'm masking by doing this?

Answer Wiki

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

Hi

Not sure I understand the difference fully, but the ILE Cobol Reference Manual for v5r2 says that COMP is used for representing Packed Decimal values and also that COMP-3 is for packed decimals too. The difference seems to be whether the length is odd or even, COMP-3 seems to be the one to use for odd field lengths.

If you’re not worried about viewing the contents of the field I think I would define the field as four characters instead of packed and convert it manually to numeric if and when I needed to use it.

All the best

Jonathan

============================================================

If this is a mainframe COBOL definition, then I would expect that it should be understood under the COMPASBIN compile option — COMP-as-binary.

Mainframe COBOL generally handles COMP as a binary definition. Under OS/400 and i5/OS, COMP is packed-decimal. IIRC, COBOL compiles COMP as something like “the most efficient numeric handling for this platform”. Traditionally, that was binary on mainframes, but packed on the AS/400 line.

There is no distinction between even-/odd-digits packed.

This field is probably a 4-byte integer that may have as many as 8 digits.

Tom

Discuss This Question: 2  Replies

 
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.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Atgidm
    The best solution for myself in converting non iSeries files to the iSeries that I have been doing for years is to first bring the file to the iSeries into a flat file - a non DDS file that you specify a record length, so in your case 3680. I would go a little bigger just to be safe. Create your PF on the iSeries. I then write a program to read the flat file and using the %subst get each field from the read record and then massage the data the way it needs to be for the PF. Once you write this program your conversion should work when bringing data to the iSeries. I like this way with the program doing the editing on each fld as I have experienced on different conversions you could have a field give you problems one time and have a different be the problem the next time. This way the program takes the data and you edit it and fix it every time it comes in. I hope this helps.
    0 pointsBadges:
    report
  • Nealhudson
    hi - thanks for the replies, it appears that COMP-3 is for Packed Decimal, whereas COMP is for Binary. I've defined the field as 8B rather than 7P, and this has worked to solve the first problem of this field in question. The further problem with Client Access is being caused by NULL values in Hex for the Character fields
    0 pointsBadges:
    report

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.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

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

Following