IBM Mainframe Forum

[shaily]

Hi ,

I need some help in converting a pipe delimited file to a fixed length file in C on Mainframes. If anyone knows any existing utility which can be utilized for the same ?

[enrico-sorichetti]

describe the source of the data, the DCB attributes of the dataset
and post a sample of the data real sample in hex please

usually when asking for a solution using a specific <tool>
the alternatives have already been evaluated!

what if the task could be carried by using an utility like Your sort product ???

[shaily]

Thanks for the reply. Kindly bear with my ignorance as I am new to this forum and to the programming w.r.t mainframes.

The source of data would be a .csv file which has a specific layout of Header,Detail and trailor.

for example :
Header
Record Indicator|File Creation Date
0000|21/03/2011
Detail
0100|ADD|2011/03/21|13:21:00

now this is a pipe delimited file and I need it to be in fixed length file.

[steve-myers]

I'm not sure what us mainframe people would call this data, though I can see why you call it "pipe delimited."

There have been similar topics in the DFSORT area about something similar; I'd look there for possible solutions using DFSORT.

By the way, you stated there is a trailer record, which you have not given us, and you have not told us how you want the output arranged, just as a fixed length record.

[shaily]

Yes just a fixed length file .

Some C program which takes a file.csv as input with some data like:

cat file.csv with 2 records

0000|21/03/2011|123|0100|123-245|21/03/2011|9999|1245
0000|21/03/2011|124|0100|124-246|21/03/2011|9999|1248

where 0000- header , 0100-Detail and 9999- trailer

output would be a fixed length file

[Robert Sample]

In order to have a fixed length output file, someone must specify the lengths allowed for each field. That someone cannot be us, since we don't know the data. Some of the things you need to consider:
1. your sample data has leading zeroes -- is that always the case?
2. Can date fields be 3/1/2011 on January 3rd -- or will they always be 10 bytes with leading zeroes?
3. Your posts are not consistent in the data presented -- one 0100 detail has the word ADD while the other doesn't.
4. One of your posts has a 123 (then 124) after the header date before the detail. Is this field to be ignored, or counted as part of the header or as part of the detail?
5. Will all of the header records have the same data fields and the same number of bytes for each field?
6. Will all of the detail records have all of the data fields? If not, is this represented by two consecutive pipe symbols, or in some other way?
7 Will all of the trailer records have the same data fields and the same number of bytes for each field?

[BillyBoyo]

Assuming the best of answers to all Robert's questions, you have a straigtforward problem.

if data, store in middle part of output record, read next
if header, store in first part of output record, read next
if trailer, store in last part of output record, write output record, read next

Sort of. I'd add some "flags" to check that you always get the data in correct sequence (always header, one data, trailer).
If you have "header-expected", "data-expected" and "trailer-expected" and set them appropriately, and test that when you have each record type it is the one expected. Then you'll know your input file is OK.

When you get end of file, make sure that there is no unused data lying in the output record (ie, header-expected).

You can initialise the output record (set to space, low values, high values, whatever) either when you get a header, or after you have written the output record (when processing the trailer).

As has been suggested, and if Robert's questions have the best answers, you might be able to do this with a SORT (they are remarkable things these days). Ask in the appropriate forum for the SORT that your site has. Note, you will not be sorting the file, just using the SORT package for a bit of data manipulation.