I am using the CSV file as input and the output file is also CSV file. My requirement is to remove the trailing spaces from each comma separated value.
e.g. Below is the record from I/P file:
"111111, John Parker ,48 STATE RD , ,02747"
Required O/p file record:
"111111, John Parker,48 STATE RD,,02747"
Is there any solution for this in JCL? If not then is there any function in COBOL for this?
I have one solution in COBOL where I will first map the record and then for each field perform below operation-
1. Find no of trailing spaces using INSPECT command
2. Using subscript (1: Length of field - No of trailing spaces) move the field to O/P record
But the issue with this approach is - there are 4 CSV files I am going process and each has its own record format.
Also there are 30 such a fields in each record and millions of records in each file so I need to consider optimization.
Joined: 10 May 2007 Posts: 2455 Location: Hampshire, UK
Not in JCL as JCL does not do data manipulation - it works with Jobs - hence its name Job Control Language. To run your COBL solution you will need JCL. To run any other batch solution you would need JCL. Suggest you LOOK in the DFSORT section for similar solutions and search the forum - which you already did, didn't you? - for something like 'trailing blanks'
Joined: 22 Apr 2006 Posts: 6250 Location: Mumbai, India
Quote:
But the issue with this approach is - there are 4 CSV files I am going process and each has its own record format.
Also there are 30 such a fields in each record and millions of records in each file so I need to consider optimization.
If this is the case, I'd believe that COBOL program is a better solution. Even if you write a SORT application for it - you need to tell SORT all the permutation/combuination you might want to take care about.
What release of zOS and COBOL you are working with? I sould not sound hyperbolic, however, with what you've posted - I'd say "optimization" should be the last thing to consider, at the moment.
Nic,
I tried the squeeze option but PARAMETER 'FINDREP' IS UNIDENTIFIED (May be because the system which I use is not supporting it). Below is the sample CCLIB which I used:
Anuj,
As I am working in service based organization I don't have the access to System details. I was able find below information only...
z/OS 01.13.00
IBM Enterprise COBOL for z/OS 3.4.1
And yes If I found nothing I will use the COBOL for this.
ABC1111,ABC2222,ABC3333,JOHN PARKER ,PO BOX 001 ,CA LMF DEPT ,WARWICK ,RI,00001, ,0000000001,0000000001,A,SABASTIAN JOSEPH ,000001 ,01,SUN DES GARY ,0000001 ,01,MAC Larry ,0000001 ,NORTHEAST ,01,MERRY JACK ,0000008 ,CURTIS JOHN ,0111111 ,
Output which I am getting after executing the mentioned SYSIN card:
Joined: 10 May 2007 Posts: 2455 Location: Hampshire, UK
Silly mistakes are easily done - do 'em most days. Currently my silly mistakes are about 10 a day - cc/cc the lines I want to cut , forget to cut, paste the previous data. Duh!
Joined: 22 Apr 2006 Posts: 6250 Location: Mumbai, India
Welcome to the holy-wolrd of "JCL-syntax-check-tools". JJ, JSCAN, JEM, JCK etc. all are different JCL-syntax check tools. Under the covers they do some 'checks' on JCL per the 'rules' written in them and at your shop FINDREP is not yet included in those rules.
Long story short -- JSCAN at your shop is not up-to-date to anticipate FINDREP yet. But when you SUBmit the Job, SORT knows the behavior of FINDREP and it does not complain you back.