IBM Mainframe Forum

Hi All,

is there any way we can convert the file into readable format using REXX. Every time if i want the data on a spread sheet i will have use sort cards and then convert them to suitable format and then FTP them to a excel, lot of manual work involved here which i want to reduce by building a tool. Can some one suggest me on the approach i need to follow.


many thanks,
Rakesh MS

I presume you mean 'data set' not 'file'.
What do you mean by 'readable format'?
What is your sort doing?
Assuming you simply want packed decimal fields converted to zoned decimal fields then sort can do that.

Hello,

In REXX, Yes and No; it entirely depends on what you really meant by 'file'. If it is a QSAM dataset, relatively easy - and it is not the 'file' that will be converted, but the data; if it is VSAM, then not so easy - but doable with a bit of additional code; once the data is read, the rest of the data conversion logic remains same as for QSAM.

Out of curiosity:
a. Is the 'file' (and not 'files') being referred to, an output of a COBOL program - as the subject states?
b. Can the COBOL be modified to write another dataset which is a replica of this 'file', but in CSV format AND EDIT masked? This will eliminate the need for *SORT steps (assuming no logical drops are being done here; though it can be easily handled in COBOL itself, at the time of data write)
c. Lastly, if you're reluctant on modifying the data-source COBOL itself (which is relatively easy), then the *SORT can be modified to create a EDIT formatted CSV 'file', as NicC has already stated.

Basically, what you ask - is doable, but you'll have to explain the existing process more clearly with representative data for someone to guide you.

These users thanked the author Aki88 for the post:

rakeshsneha1212 (Mon Apr 17, 2017 12:28 pm)

Thank you both for looking in to this.

yes, it is a COBOL dataset(sequential file). i just did a search a round and got to kow that COBOL copybooks can be converted to CSV and then it can be fed into control card (just like sort card) for COBOL input dataset so it can converted to the readable format(i.e packed to Zoned decimal) and get the final output dataset.


Many Thanks - Rakesh MS

Referring to Aki88's possible solution b, I did just that some years ago in Assembler. I did find that to make a reasonable spreadsheet the data had to be sorted differently than to produce a reasonable printed report.

COBOL copybooks can be converted to CSV

But copybooks are part of the COBOL program - not the data so that statement is rubbish.

fed into control card

More rubbish - you do not feed anything into control cards. Control cardrs are read into the program that they control.

In the first instance what you mean is that you can create another copybook to produce data in a csv format including unpacking the data. The data can then be copied from the syructure defined by the current copybook into this new copybook and then written out to a new dataset in your csv format. Then all you then need to do is send it to your *nix/windows system to be used unless... You may need to send it to your sort process depending what that is doing (which may be what yu meant by the second bit of rubbish).

If that is what you meant then why did you not say so? If it is not what you meant then you need to be more clear and exact in your what you meant.

Hi Nicc,
Apologise on those informal words.

My first initial post was to handle the raw file to the readable format. But after what Aki88 suggested i start looking around for it and then i thought i could convert the cobol copy book to CSV. but please explain me how to achieve this.

I just want to reiterating on my requirement - I am writing a tool to convert any raw cobol dataset to a readable form (Meaning upacked to Zoned). can you please suggest me how to achieve this.

You cannot "convert the cobol copybook to CSV" because a cobol copybook contains cobol program code. CSV means Comma Separated Variables. What Aki88 is suggesting is: using a new copybook in the general format -

add code to your program to populate the structure in the copybook and write it out to your data set (not file, as you keep wrongly calling it). This can then be transferred to wherever your spread shhet is.

These users thanked the author NicC for the post:

rakeshsneha1212 (Mon Apr 17, 2017 3:41 pm)

Thanks Nicc for your reply.

But this is not generic i mean every time i will have to create a new copy book for every different datasets(which has different copy book layout). Can we not make this automated ??

Hello,

rakeshsneha1212 wrote:...But this is not generic i mean every time i will have to create a new copy book for every different datasets(which has different copy book layout). Can we not make this automated ??

Ok, before we really dive into it, let us take a step back and understand few basic things, because we are talking 'automation' here, and going by the looks of this thread we are really not getting anywhere in terms of explaining or understanding the complexity of the problem at hand. You need to understand that EVERYTHING can be done, provided one is able to think of an algorithm - which happens only if we understand the problem first.

Forget REXX, *SORT, COBOL, COPYBOOK etc. for a few moments, ponder and try answering a few questions to yourself:
a. No matter what the source, how do you differentiate between the different datasets (and subsequently their 'comma-separated-layouts') during run-time?
b. If you are able to figure out how you'll go about point- a, then program your code in such a way that --> IF-DS Type-Identified-MOVE-DATA-To-The-Linked-Layout

If you choose COBOL, then you can have all the comma-separated-layouts coded in the program at one go, at different '01' levels (extremely basic structure), OR you can play around different levels - a choice totally dependent on your programming proficiency.

The program (COBOL or otherwise) needs to be (coded) intelligent enough to figure out which layout needs to be populated against which form of data.

Note, that this same concept will be required (if I am not wrong) for almost all structured programming languages, because unless coded, a program will never know where to insert a comma/character. As far as *SORT is considered, I'd recommend you revisit the current constructs and analyze how your site is currently handling the different datasets as on today, as you might be looking at a solution.

These users thanked the author Aki88 for the post:

rakeshsneha1212 (Wed Apr 19, 2017 8:26 pm)