Issue with importing cobol definition

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
senthil_tcs
Premium Member
Premium Member
Posts: 40
Joined: Tue Oct 14, 2008 3:30 pm
Location: London

Issue with importing cobol definition

Post by senthil_tcs »

when i try importing cobol copy book, DS throws error for PIC BLOB and PIC LONG and states invalid string datatype. I understand these datatypes are not supported by DS. I just wanted to check if someone has faced issue with such kind of datatype . If yes please let me know how i can resolve this issue. As this cobol cpy book is created by executing oracle DDL.

Can anyone please help me with equivalent cobol definition for datatype BLOB and LONG which is of Oracle.

Thanking in advance
Sainath.Srinivasan
Participant
Posts: 3337
Joined: Mon Jan 17, 2005 4:49 am
Location: United Kingdom

Post by Sainath.Srinivasan »

That is from Pro*COBOL. It also have features for communication area who is restricted to Oracle.

DataStage supports MainFrame COBOL.

Better check the header files.
senthil_tcs
Premium Member
Premium Member
Posts: 40
Joined: Tue Oct 14, 2008 3:30 pm
Location: London

Post by senthil_tcs »

thanx for the reply.

There is no header file that i am aware of. I have been given this cobol definition file that i was trying to import in DS. As mentioned before this cobol definition is created by executing oracle DDL statements. There are around 50 tables. 4 Tables with datatype BLOB and LONG are throwing error message and unable to import and remaining ones are sucessfully imported.

Can you please explain little more in detail. I used cobol definitions before without any issues but this one is for binary files that's the only difference
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

As you noted, those BLOB and LONG data types are not supported so your best bet is to stay with an Oracle solution, probably PL/SQL.
-craig

"You can never have too many knives" -- Logan Nine Fingers
Post Reply