I have an *.csv input file, from which I need to extract several decimal numbers, which can have from 0 to 4 fractional part. An example input file would be:
I need to extract all 3 numeric fields, justify them to the right, fill by the left with zeroes, and truncate to two las decimals, or if the number doesn't has any fractional part, fill it with ",00".
On our shop, the decimal/fractional part separator is the comma "," character
I've been testing with parse and extraction of the fields, wich works perfectly, but I'm having problems with the variable amount of fractional parts, as well as to convert the data to a numeric number
Could you provide an example how to achieve this with dfsort?
2. When finished with #1, try to detect integer part, and fractional part of each aligned field (separated by ',' in your case). Keep in mind to use '00' when no comma found!
3. Extend each fractional part with '0's to the desired 2 digits, align them to the right, append the integer part from left, and extend with '0's at the left.
First off, I think the attitude and the aggressiveness regarding the "you doing my job" is not necesary. Thanks though, for the feedback but honestly, this made my return to this forum after several years not a pleasant experience.
My original question was a simplification of my overall requirement, which does a few more transformations, but the issue at hand was the handling of the decimal and non decimal parts of the CSV final. The final code I posted, which one of my programmers made was heavily dependant on one decimal field present on the position 56 of the input file, which was almost never the case. Thanks to the feedback we managed to make this, which works as expected (for the example). The full sort card has many more instructions, but that wasn't our issue so I'll not post this here
@ojdiaz: I insist you to start doing the whole task step-by-step (as I suggested above), and to CAREFULLY VERIFY ALL INTERMEDIATE RESULTS, before adding the next step to your processing code.
As far as we’ve tested it, step by step it worked as expected. First, we used WHEN=INIT to split the numbers into percentage variables. Then, we employed BUILD to create three fields of 13-character length and aligned them to the left.
Next, we focused on the first field and checked whether it contained a decimal separator (“,”), which indicates a fractional part. If it did, we reformatted it by aligning the numbers to the right, filling the left with zeroes, and completing the decimal part with additional zeroes until we had a 13-character field. We achieved this using the first IFTHEN=COND statement.
Finally, we performed another check in case the field didn’t have any decimal character. In that scenario, we aligned the character to the right, added the comma, and appended two zeroes to complete a full 13-character field.
It seems to be working as I tested it step by step: first the INIT, then the first WHEN=COND, and finally the next WHEN=COND. Checking intermediate results. Which is what I usually do, and I was just looking for some insights or methods to perform this other than what we had at the begining
If you notice any risks, incorrect code, or potential undesired results based on the requirements I posted, please let me know wherE because I can't seem to find it
Joined: 15 Aug 2015 Posts: 1255 Location: Bamberg, Germany
ALTSEQ/TRAN will replace X'40' by X'6B' in the parsed fields. It enables the second PARSE to detect fractional parts (if any). The JFY fixes the latter, or fills up with Zeros when needed.
ALTSEQ/TRAN will replace X'40' by X'6B' in the parsed fields. It enables the second PARSE to detect fractional parts (if any). The JFY fixes the latter, or fills up with Zeros when needed.
Excessive "optimization", such as using ALTSEQ to replace comma characters, or using SIGNS parameter to substitute non-sign characters like a comma, makes the code hard to be understood by a human...
The last issue may be more important than executability of the code by a computer.
Joined: 15 Aug 2015 Posts: 1255 Location: Bamberg, Germany
Of course the code should be understandable/maintainable by humans. That is, keeping the balance of avoiding too many IFTHEN, absolute positions, and on the other hand maybe adding some comments if the provided code is helpful and understood by the requestor.
