MAINFRAME - TIP OF THE DAY :
When you specified V for RECFM parameter, LRECL value is largest record in the file plus 4 bytes. These four bytes contain the actual length of each variable length record in the file
Programmers Voted for below topics. Please Vote for good Posts.
Thank You! for your feedback. Connecting to the server. Please Wait...
The above should not change the output you get, but there is no reason to change the first portion of your record to its original content. You are "overlaying", so leave the first part of the record alone, put your new zero, then pick up the end of the record - don't specify a length, DFSORT will do "from 29/26 to the end if the record" for you.
You might find a simpler solution with PARSE if you records are tab-delimited.
Joined: 23 Oct 2010 Posts: 107 Location: Chennai,India.
Posted: Fri Aug 17, 2012 12:02 pm Post subject:
Thanks DickDude and William -
Yes I was doing PARSE only in the OUTREC. But the thing is - my input will be having amount fields, when ever zeros coming as an amount value I will be getting that value as 0.00 but if it is greater than zero it will be "xxxxxx.00". In order to make the parse condition consistent I am doing this INREC OVERLAY.
Please see my input -
********************************* Top of Data
in the first row after 0001 the value came as 0.00, but in the second row the value came as "25,000.00". here I want to make my PARSE condition as a consistent one in all the record where I am doing parse in the outrec. _________________ Guru:-)
At a guess, then, you are getting "25,000.00" because your file is being created as a genuine "comma-seperated" file. The double-quotes "protect" the "," in the number.
This would mean that it is not only zero which will give you a problem, but anything less than 1,000 will, as that will not contain a comma either.
"Something" has then "converted" the comma-separators to tabs and not bothered to remove the double-quotes which no longer have a function.
The "neatest" solution would be to get the creation of the file as genuinely tab-delimited. Tab delimiters are often chosen because the tab character, unlike the comma, is unlikely to genuinely appear in plain text data.
Next "neatest" is to change the definition of the output numeric fields so that they do not include the commas.
Next "neatest" would be to change the "fixer-upper-to-tabs" so that it removes the double-quotes.
Next "neatest" is to use PARSE and deal with the number formats yourself.
On the other hand, if you think about it, if that tab-delimited file was going back into a spreadsheet program, there is no problem with the data content one moment being 10.00 and the next "25,000.00". Are you sure that the data actually causes you a problem, or are you only expecting that?
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Cobol Tutorial This cobol tutorial covers most of the important topics like STRING, UNSTRING, COMP, COMP-3.....
DB2 Tutorial DB2 Tutorial focuses on DB2 COBOL Programming. Explains in simple language. Some Chapters are locked, Forum members have free access to these chapters
CICS Tutorial This CICS tutorial covers CICS concepts and CICS Basics, CICS COBOL Programming...
JCL Tutorial This is most popular JCL tutorial from mainframegurukul. It does contain important jcl ....
SORT Tutorial This Tutorial covers all important aspects of DFSORT. Has more SORT examples