We are trying to read an EBCDIC column with a PICS9 / Comp3 format and write it to a hash file as an ASCII decimal without success. We have tried several different transformation functions, but all result in a fatal error:
"Attempted WRITE with Record ID larger than table/file maximum..."
We have verified that the data in all columns but the two Comp-3 columns is being processed correctly, and that the error is a result of how we are (not) handling these two columns. We are continuing to work on this but wonder if anyone can offer some insight. Im sure it is an obvious error we are overlooking. Thanks in advance...
Dan
PICS9 - COMP-3 Problems
Unfortunately, if youre using the FTP stage to get the data from the mainframe to DataStage, its doing a character conversion from EBCDIC to ASCII. Various values in the Comp-3 field will come across with different hex values than you want.
We bit the bullet and said, "To heck with it!" I.e., we had the source system (mainframe) files changed to unpacked fields before we FTP-ed them to DataStage. You can probably do this with FileAid, instead of resorting to programming changes. If the field comes across as signed (overpunch on last position), that can be handled with a simple routine within DataStage. I have one if youre interested.
Sincerely,
Brad Vincent
Data Warehousing with a "health"-y spin
Compuware
c/o The Detroit Medical Center
(313) 966-2176
We bit the bullet and said, "To heck with it!" I.e., we had the source system (mainframe) files changed to unpacked fields before we FTP-ed them to DataStage. You can probably do this with FileAid, instead of resorting to programming changes. If the field comes across as signed (overpunch on last position), that can be handled with a simple routine within DataStage. I have one if youre interested.
Sincerely,
Brad Vincent
Data Warehousing with a "health"-y spin
Compuware
c/o The Detroit Medical Center
(313) 966-2176
COMP-3 is BCD (Binary Coded Decimal), not EBCDIC.
This means +123 is stored in a PIC S9(5) COMP-3 field (three bytes) as the hexadecimal x00123C . Is it so easy or did I miss something ?
I hope this helps.
Pascal
Dan Paolini on 29/08/2001 16:30:34
Please respond to datastage-users@oliver.com
To: datastage-users@oliver.com
cc: (bcc: Pascal TONEATTO/FRANCE/PARFUMS_DIOR)
Subject: PICS9 - COMP-3 Problems
We are trying to read an EBCDIC column with a PICS9 / Comp3 format and write it to a hash file as an ASCII decimal without success. We have tried several different transformation functions, but all result in a fatal error:
"Attempted WRITE with Record ID larger than table/file maximum..."
We have verified that the data in all columns but the two Comp-3 columns is being processed correctly, and that the error is a result of how we are (not) handling these two columns. We are continuing to work on this but wonder if anyone can offer some insight. Im sure it is an obvious error we are overlooking. Thanks in advance...
Dan
This means +123 is stored in a PIC S9(5) COMP-3 field (three bytes) as the hexadecimal x00123C . Is it so easy or did I miss something ?
I hope this helps.
Pascal
Dan Paolini on 29/08/2001 16:30:34
Please respond to datastage-users@oliver.com
To: datastage-users@oliver.com
cc: (bcc: Pascal TONEATTO/FRANCE/PARFUMS_DIOR)
Subject: PICS9 - COMP-3 Problems
We are trying to read an EBCDIC column with a PICS9 / Comp3 format and write it to a hash file as an ASCII decimal without success. We have tried several different transformation functions, but all result in a fatal error:
"Attempted WRITE with Record ID larger than table/file maximum..."
We have verified that the data in all columns but the two Comp-3 columns is being processed correctly, and that the error is a result of how we are (not) handling these two columns. We are continuing to work on this but wonder if anyone can offer some insight. Im sure it is an obvious error we are overlooking. Thanks in advance...
Dan
ptoneatto@diormail.com wrote:
> COMP-3 is BCD (Binary Coded Decimal), not EBCDIC.
> This means +123 is stored in a PIC S9(5) COMP-3 field (three bytes)
> as the hexadecimal x00123C . Is it so easy or did I miss something ?
>
We are getting an EBCDIC file in which two of the columns are Comp-3 encoded. We convert the EBCDIC to ASCII and our transforms of simple PICS9 columns seem to be handle correctly. It is only the Comp-3 columns that are not.
Another message indicates a potential problem with the FTP process...
Dan
> COMP-3 is BCD (Binary Coded Decimal), not EBCDIC.
> This means +123 is stored in a PIC S9(5) COMP-3 field (three bytes)
> as the hexadecimal x00123C . Is it so easy or did I miss something ?
>
We are getting an EBCDIC file in which two of the columns are Comp-3 encoded. We convert the EBCDIC to ASCII and our transforms of simple PICS9 columns seem to be handle correctly. It is only the Comp-3 columns that are not.
Another message indicates a potential problem with the FTP process...
Dan
"Vincent, Brad" wrote:
> Unfortunately, if youre using the FTP stage to get the data from the
> mainframe to DataStage, its doing a character conversion from EBCDIC
> to ASCII. Various values in the Comp-3 field will come across with
> different hex values than you want.
Does this only affect Comp-3 formats. Our other EBCDIC->ASCII processing seems fine (I believe we are FTP-ing without the forced ASCII conversion).
> We bit the bullet and said, "To heck with it!" I.e., we had the source
> system (mainframe) files changed to unpacked fields before we FTP-ed
> them to DataStage. You can probably do this with FileAid, instead of
> resorting to programming changes. If the field comes across as signed
> (overpunch on last position), that can be handled with a simple
> routine within DataStage. I have one if youre interested.
Unfortunately, changing the MF is not an option. We will investigate other pre-processing options. Thanks!..
Dan
> Unfortunately, if youre using the FTP stage to get the data from the
> mainframe to DataStage, its doing a character conversion from EBCDIC
> to ASCII. Various values in the Comp-3 field will come across with
> different hex values than you want.
Does this only affect Comp-3 formats. Our other EBCDIC->ASCII processing seems fine (I believe we are FTP-ing without the forced ASCII conversion).
> We bit the bullet and said, "To heck with it!" I.e., we had the source
> system (mainframe) files changed to unpacked fields before we FTP-ed
> them to DataStage. You can probably do this with FileAid, instead of
> resorting to programming changes. If the field comes across as signed
> (overpunch on last position), that can be handled with a simple
> routine within DataStage. I have one if youre interested.
Unfortunately, changing the MF is not an option. We will investigate other pre-processing options. Thanks!..
Dan
> We are getting an EBCDIC file in which two of the columns are Comp-3
> encoded. We convert the EBCDIC to ASCII and our transforms of simple
> PICS9 columns seem to be handle correctly. It is only the Comp-3
> columns that are not.
COMP-3 fields cannot be converted from EBCDIC to ASCII since they are not EBCDIC. They even not use an alphabet. COMP-3 fields need a specific conversion.
Pascal
> encoded. We convert the EBCDIC to ASCII and our transforms of simple
> PICS9 columns seem to be handle correctly. It is only the Comp-3
> columns that are not.
COMP-3 fields cannot be converted from EBCDIC to ASCII since they are not EBCDIC. They even not use an alphabet. COMP-3 fields need a specific conversion.
Pascal
If you are running 4.1 or above you can use the server side Complex Flat File Stage I believe.
-----Original Message-----
From: Dan Paolini [mailto:daniel.paolini@oit.state.nj.us]
Sent: Friday, August 31, 2001 2:11 AM
To: datastage-users@oliver.com
Subject: Re: PICS9 - COMP-3 Problems
"Vincent, Brad" wrote:
> Unfortunately, if youre using the FTP stage to get the data from the
> mainframe to DataStage, its doing a character conversion from EBCDIC
> to ASCII. Various values in the Comp-3 field will come across with
> different hex values than you want.
Does this only affect Comp-3 formats. Our other EBCDIC->ASCII processing seems fine (I believe we are FTP-ing without the forced ASCII conversion).
> We bit the bullet and said, "To heck with it!" I.e., we had the source
> system (mainframe) files changed to unpacked fields before we FTP-ed
> them
to
> DataStage. You can probably do this with FileAid, instead of resorting
> to programming changes. If the field comes across as signed (overpunch
> on
last
> position), that can be handled with a simple routine within DataStage.
> I have one if youre interested.
Unfortunately, changing the MF is not an option. We will investigate other pre-processing options. Thanks!..
Dan
-----Original Message-----
From: Dan Paolini [mailto:daniel.paolini@oit.state.nj.us]
Sent: Friday, August 31, 2001 2:11 AM
To: datastage-users@oliver.com
Subject: Re: PICS9 - COMP-3 Problems
"Vincent, Brad" wrote:
> Unfortunately, if youre using the FTP stage to get the data from the
> mainframe to DataStage, its doing a character conversion from EBCDIC
> to ASCII. Various values in the Comp-3 field will come across with
> different hex values than you want.
Does this only affect Comp-3 formats. Our other EBCDIC->ASCII processing seems fine (I believe we are FTP-ing without the forced ASCII conversion).
> We bit the bullet and said, "To heck with it!" I.e., we had the source
> system (mainframe) files changed to unpacked fields before we FTP-ed
> them
to
> DataStage. You can probably do this with FileAid, instead of resorting
> to programming changes. If the field comes across as signed (overpunch
> on
last
> position), that can be handled with a simple routine within DataStage.
> I have one if youre interested.
Unfortunately, changing the MF is not an option. We will investigate other pre-processing options. Thanks!..
Dan