Get rid of COBOL levels in datastage Data Set column defs?

[mczern]

I'm creating datastage jobs to land mainframe data in to datastage datasets. I'm reading mainframe data using the Complex Flat File (CFF) transform. I used copybook data files to define columns in the CFF which includes level information. I then produce a datastage data set file which I noticed includes the same level information contained in the CFF. One of the side effects I've come across is that when I use the data set as an input in another job, it propogates the level metadata to the next transform. If I combine this data with non mainframe data sets, that do not contain level information, in a transformer, I now have to ensure every column has a level populated or datastage provides me with a less than meaningful error.

Is there a way to get rid of the level metadata in either the Data Set definition or Transformer stage?

[vivekgadwal]

Is there a way to get rid of the level metadata in either the Data Set definition or Transformer stage?

One way is to export this job as a ".dsx" and perform a "Search and remove" of the line that has "LevelNo=" as the entry. Once they are removed, you could re-import that and it should get rid of those level numbers.

[ray.wurlod]

Do you want to get rid of it, or merely to hide it in the Columns grid?

[vivekgadwal]

merely to hide it in the Columns grid?

Can we do that?

Having these Level numbers outputting to a Sequential File would cause compile problems. That is why I had to remove it in a few scenarios.

[ray.wurlod]

Right click on the Columns grid. The menu thus revealed allows you to customise the appearance of the Columns grid, including what will and will not be displayed.

[mczern]

So you're saying that if you simply hide the column datastage ignores the fact that some columns have level values and some do not? Seems simple enough.

[vivekgadwal]

I am not so sure that merely hiding it means that DataStage would ignore it. Could you please let us know if this worked for you?

[ray.wurlod]

So you're saying that if you simply hide the column datastage ignores the fact that some columns have level values and some do not? Seems simple enough.

Not at all. That's why I asked the original question.

[mczern]

Ok.. I guess it doesn't matter if I get rid of the level column. The more relevant question is...
If I have two inputs, one containing data defined by a COBOL copybook with 3 columns and one containing data defined by a flat file defined by columns in a csv (does not have level information automatically appearing when I import column definitions) with 100 columns.

When I join the two data streams, the three columns from the copybook contain the level (say 02) populated. The 99 other columns from my flat file are empty. If I now run the stream through a transformer, I now have to populate the level column for the 99 columns with 02 to get the job to compile and run. I tried blanking out the 3 columns, but that gave me an error as well.

Is there some process that will allow me to not have to manually populate the 99 columns because 3 columns have a level value?

[vivekgadwal]

Try what I proposed. It is a one time thing, during developing the job, and it will do the trick for you.

[FranklinE]

Is there some process that will allow me to not have to manually populate the 99 columns because 3 columns have a level value?

I had a recent run-in trying to maintain the packed decimal attribute for incoming data on a Cobol copybook format. In working through the table import process, and being easily annoyed, I decided to edit the copybook text file before import and remove group fields or "compress" them away from their individual lower-level definitions.

I suggest you extend that to re-importing your table definition away from the Cobol attributes, if only because it's much easier to recode for 3 columns than for 99. So long as the meta data has it tagged as "Cobol", you won't be able to avoid the level attribute.

[devesh_ssingh]

Frankline..

i did not get you...you mean to edit copy book and re import....if you do so then how would you read the data as its still in cobol format....
i'll add one more point from my experince ...even if u do some opertaion carrying level name if it changes in between then too its generate error..
eg;..
i was doing lookup with source having 05 level and ref also had 05 but one colm in refr had 02 it gave me nightmare to find it....

either have same level throughout or did not have.....

[FranklinE]

My suggestion is based on a practical view. For example, go through the Repository view and open the table properties. On the layout tab, click on the Parallel view. This is how the meta data looks at its basic level.

The record_format line preserves the Cobol attributes you must have. The rest makes no reference to level. As a start, you could copy/paste that to a text file and import from that. Use the "Orchestrate Schema definitions" import category. I just successfully followed those steps. All of the table and column attributes were preserved.

Your comparison view is in the Columns tab of the table properties. Use the right-click menu to edit a row. In your Cobol FD import, you will see attributes on the row's Cobol tab, like level, filled in. In your Orchestrate import version of the table, all of those attributes will be blank.

I hope that helps.

[manuel.gomez]

I was having same problem. As usual, "search" option normally is fastest way to solve an issue

I just tried what you FranklinE described, and worked succesfully. This is saving me a lot of time, thanks very much!

[sarmistha mohanty]

Is there a way to get rid of the level metadata in either the Data Set definition or Transformer stage?

One way is to export the table definition and remove the level numbers and then import it as datastage component .Then you can use this converted table definition for your job , it will work :D :D