IBM Mainframe Forum

Hello,

Please post the results of a few tests running the suggested code.

Also, the original post says nothing about having both single and double quotes. . . Suggest at least one of the tests be of the data originally posted. Show some "inputs" and the output from each of these inputs.

I think we have to wait for the original poster to see if the program is even necessary.

Quasar wrote:[b]
01 WS-STRING PIC X(38)
VALUE "aaaaaa,bbbbb,'ccc,ccc',ddd,ee,'ff,ff',".
01 WS-I PIC S9(04) COMP-3

This first is an example of the problem with potentially trying to "de-code" a CSV. You want the double quote, but that causes a compile error. A compiler has strict definitions for what its input can look like. User-entered data which is exported to a CSV does not. So, problem "de-coding" (or de-CSVing) it.

Well, if you have to have the double quote, what do you do?

first-part-of-line pic x(whatever).
opening-double-quote pic x value QUOTE.
text-in-quotes pic x(whatever).
closing-double-quote pic x value QUOTE.
rest-of-line pic x(whatever).

Don't think you'll need the trailing comma.

With comp-3, my advice, always an odd number of digits (so here, 5). Else you end up with half a byte that the compiler might generate extra code for to always keep a value of "0" there (depends on compiler option, see an earlier discussion mentioning TRUNC).

For Manju Venkat, ff the program goes ahead and it needs fields, also import your test data into something which understands CSVs. Like a spreadsheet. If you get the same results, then you are doing well.

Quasar wrote:01 WS-I PIC S9(04) COMP-3
VALUE 0.

Sorry, I only noticed later. This is your subscript. Here, I'd suggest COMP not COMP-3, assuming that the current compiler still prefers subscripts that way. Generate the assembler code. Look at the code for a line where you are using WS-I and see if it generates the instruction CVB.

I haven't looked at your code at all.

Despite all my postings this morning, I'm hoping that the "requirement" will be binned. To me, silly to create a CSV just to deCSV it. Of course, the CSV might be being used for something else already, with no resource to create a seperate text file, or with the requirement that it runs off the exact same file that is used for the other CSV processing.

Also, I seem to keep going on about it, it would be excellent if there was a business date on the first record of the file, and at least a count or something to indicate the last record of the file. Increases the chance of 1) working on the right file and 2) working on all the file. For me this is mandatory. And even more mandatory when taking a file from another system. And yes, I know I can't really have "even more mandatory", but it is a good emphasis.

thanks for your quick reply..i got the logic..