Knowing when to use what datatype conversion

Post questions here relative to DataStage Server Edition for such areas as Server job design, DS Basic, Routines, Job Sequences, etc.

Moderators: chulett, rschirm, roy

Post Reply
denzilsyb
Participant
Posts: 186
Joined: Mon Sep 22, 2003 7:38 am
Location: South Africa
Contact:

Knowing when to use what datatype conversion

Post by denzilsyb »

Hallo guys

I have 1 record that has been dumped on my PC for transfer from the CFF stage to a flat file. The 'table definition' follows:

Code: Select all

       01  DCLFGL-ACNT.
           10 FGL-ACNT-N           PIC S9(16)V USAGE COMP-3.
           10 FGL-CUST-N           PIC S9(9)V USAGE COMP-3.
           10 FGL-FUND-N           PIC S9(9)V USAGE COMP-3.
           10 FGL-TRADE-UNION-N    PIC S9(9)V USAGE COMP-3.
           10 FGL-SCHEME-N         PIC S9(9)V USAGE COMP-3.
           10 FGL-EMPLR-N          PIC S9(9)V USAGE COMP-3.
           10 FGL-ADMTR-N          PIC S9(9)V USAGE COMP-3.
           10 FGL-CENTR-N          PIC S9(7)V USAGE COMP-3.
           10 FGL-PROD-N           PIC S9(4)V USAGE COMP-3.
           10 FGL-ADRES-N          PIC S9(9)V USAGE COMP-3.
           10 FGL-OPEN-D           PIC X(10).
           10 FGL-CURNT-BAL-A      PIC S9(11)V9(2) USAGE COMP-3.
           10 FGL-LIMIT-BAL-A      PIC S9(11)V9(2) USAGE COMP-3.
           10 FGL-BRAC-ACNT-N      PIC S9(16)V USAGE COMP-3.
           10 FGL-RISK-GRADE-C     PIC X(2).
           10 FGL-RSKGP-IP-N       PIC S9(6)V USAGE COMP-3.
           10 FGL-SIC-C            PIC X(6).
           10 FGL-TITLE-C          PIC X(3).
           10 FGL-INITL-X          PIC X(5).
           10 FGL-ACNT-NAME-X.
              49 FGL-ACNT-NAME-X-LEN  PIC S9(4) USAGE COMP.
              49 FGL-ACNT-NAME-X-TEXT  PIC X(60).
           10 FGL-OBADR-Y          PIC X(1).
I have received this layout from the mainframe and imported it to DS, so there shouldnt be typing errors in the definition. DS imported the definition quite alright.

I need a couple of things resolved for my understanding (knowing that my mainframe knowledge is next to zero)

1. In the CFF stage, when i view the data i get (it seems) binary characters in the DISPLAY columns - is this normal? Do I take care of this in a transform stage?
2. When do I know what conversion transform to use in the sdk supplied? i.e. DataTypeEBCDICPic9. Is there a standard to determine what transform to use when?

I am sure I will have more questions as the discussions go along..
dnzl
"what the thinker thinks, the prover proves" - Robert Anton Wilson
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Re: Knowing when to use what datatype conversion

Post by chulett »

denzilsyb wrote:I need a couple of things resolved for my understanding (knowing that my mainframe knowledge is next to zero)
Thre isn't really alot of mainframe knowledge needed here, more like COBOL knowledge. :wink:

You are seeing 'binary' because of the packed decimal - COMP-3 - fields, and also the one wee COMP one down near the bottom. It's probably also coming in in EBCDIC rather than ASCII, so looking at the 'raw' file is going to be even more confusing.

That being said, the whole point behind using the CFF is so you don't have to worry about stuff like this. It does the appropriate 'conversions' of the data types behind the scenes for you, automagically. For a first whack at this, simply read the file via CFF and write it back out again with a Sequential File stage and see if what you get is readable.
-craig

"You can never have too many knives" -- Logan Nine Fingers
denzilsyb
Participant
Posts: 186
Joined: Mon Sep 22, 2003 7:38 am
Location: South Africa
Contact:

Post by denzilsyb »

Hi chulet

Well, one success..

- column FGL-ACNT-N comes through o.k.
- column FGL-CUST-N comes through as blank (there should be data)
- then i get this warning for FGL-FUND-N

Code: Select all

Invalid sign value in DECIMAL COMP-3 data, first detected in column FGL_FUND_N - NULL data generated.
but a different number comes through none the less.
- from there on i get all kinds of numbers, but none match to the source data
- the column FGL-OPEN-D is supposed to be a date, but it comes through as ???||??||? even after i verify CHARACTER and CCYY-MM-DD in the row metadata

I think the metadata settings need to be tampered with - could DS have made a mistake importing? Nooo.. it all looks right (studying the metadata of the row)

I have left the row length as 0 so that the metadata determines the end of record.

what suggestions have you guys?

... :D i got the date working... how i dont know! :roll:

:idea: the date works if i specify ASCII binary in the CFF. So my source is not EBCDIC as expected.
dnzl
"what the thinker thinks, the prover proves" - Robert Anton Wilson
denzilsyb
Participant
Posts: 186
Joined: Mon Sep 22, 2003 7:38 am
Location: South Africa
Contact:

Post by denzilsyb »

just updating on the PROGRESS here!

It seems DS is having a problem interpreting the following (the FGL-SIC-C column defined above)

Code: Select all

     04444440
     00000000
when we add a filler to the first and last 0, we seem to get the data close to a readable format. the 40 represents a space in COBOL (so i am told). Notice though that the column FGL-SIC-C is defined as [PIC X(6).] which means the leading and trailing 0 must be fillers to DS.

Do you agree?

From this column onward, the data is displayed as garbage. So, we are expecting the data to be displayed properly as soon as we figure out how to handle the above.

any suggestions?
dnzl
"what the thinker thinks, the prover proves" - Robert Anton Wilson
denzilsyb
Participant
Posts: 186
Joined: Mon Sep 22, 2003 7:38 am
Location: South Africa
Contact:

Post by denzilsyb »

unfrknbelievable :shock:

we figured it out. the 40 explained earlier was a matter of Oconv(Iconv(col,'MP'),'MP') and the spaces were revealed.

The leading and trailing 0s were taken care of by changing the length of the column(s) following and including the FGL-SIC-C.

the garbage that followed the FGL-SIC-C was a GROUP native type which we neednt enter because variable length data is stored in there (length and data), of which we only needed the description.

It seems then the devil was in the detail

thanks chulet
dnzl
"what the thinker thinks, the prover proves" - Robert Anton Wilson
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

denzilsyb wrote:It seems then the devil was in the detail
It usually is! Correct display lengths are very critical to making something like this work. Just be glad there were no 'REDEFINES' in there.

Glad you got it straightened out in spite of my minimal helpage. :wink:
-craig

"You can never have too many knives" -- Logan Nine Fingers
denzilsyb
Participant
Posts: 186
Joined: Mon Sep 22, 2003 7:38 am
Location: South Africa
Contact:

Post by denzilsyb »

chulett wrote:Just be glad there were no 'REDEFINES' in there
this is going to be a loooong project...
dnzl
"what the thinker thinks, the prover proves" - Robert Anton Wilson
Post Reply