I am not getting correct result with the above code ,i am just multipling the value on 1586 an putting in 1589 I am not sure why i am i am getting 0 in the output.Is FS correct in that postions.
Eg:if 1586,3 has 123 then 1589 should have 12300000
paduchuri,
Check the test JCL below and output I get when I run the same job.
Also I don't know what is your input data type but it works with FS. If you could provide Cobol declaration, I might be able to tell you if the FS is correct or not.
paduchuri,
Check the test JCL below and output I get when I run the same job.
Also I don't know what is your input data type but it works with FS. If you could provide Cobol declaration, I might be able to tell you if the FS is correct or not.
paduchuri,
You are using Syncsort, so everything below is a guess since I have DFSort.
FS is optional sign. When I run the same job with 023 as input, I get 2300000. Not sure why you are getting + sign in the output. Does your input data have sign that you are not showing here?
I am not sure SFF/UFF is supported in Syncsort but If you do have leading sign,I would use SFF and convert to ZD. Something like below.
Please also could you tell me the reason TO=FS what is the default datatype ?
I don't have Syncsort manual or else I would point you to the link but TO=FS, would make sure that after the arithmetic operation resultant field is kept in FS(or you could convert other data types as well).
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Code:
OUTREC OVERLAY=(5:1,3,CH,5C'0')
Would be my "guess" as an option for the other solution. Don't think you need the CH, you could probably leave it out (try) and, if you want, maket it ZD, FS, SFF or your choice.
Can't test it myself, but give it a whack if you feel up to it.
Try it on SYMNAMES as well:
Code:
FIVEZEROSTOAPPEND 5C'0'
and
OUTREC OVERLAY=(5:1,3,FIVEZEROSTOAPPEND)
Note, I've dropped the CH here, just so you do get to try it.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Well, that would be true. Thanks.
However, from his sample data, for his three-digit field, I'm extrapolating that he doesn't, and thinking he just stumbled sumwhat onto the FS for his field definition. Really, with a three-digit field and two- or three-digit examples, I don't think there is room for a sign.
What I'm trying to show is the alternative to the "multiply by a factor of 10", which is to stick an appropriate number of zeros on the end of the new field. If he does have the +/-, then it is the other part of the code that I was so unconcerned about, that would need to change.
How he got a sign with your code is an interesting question. I was thinking (guessing, no Syncsort manual, blah, blah) that maybe Syncsort includes a sign by default when going to an FS field (if there is room for it, anyway) and DFSORT does not.
Sorry for only guessing, Frank and Kolusu. Not much use.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
If there's a question somewhere in here about DFSORT, I'd be happy to answer it. Somebody just has to "spell it out" for me so I know what the question is.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Dick, I forgot it had moved :-)
Frank, it was one of those things that started off as a DFSORT question. The WER messages arrived after sqlcode1 had provided a solution. The solution produced a different result between DFSORT and what turned out to be the same code under Syncsort.
TS had started with a data-type of FS while trying to add five trailing zeros to a three-digit field. Along with the multiply, the output was converted TO=FS.
With a 023 test case, multiplied by +100000 and TO=FS, DFSORT for sqlcode1 came up with 02300000. TS, using Syncsort, got +2300000.
At which point I speculated that Syncsort could be putting the + in, if there was space, wheras DFSORT not.
Dick, I forgot it had moved :-)
With a 023 test case, multiplied by +100000 and TO=FS, DFSORT for sqlcode1 came up with 02300000. TS, using Syncsort, got +2300000.
huh? When?
We shouldn't be discussing this but the fact that OP got leading sign is/was because OP failed to provide us with correct test data. He would have leading sign originally in his file. That's why the job with SFF worked for him.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Frank Yaeger wrote:
[...]
Quote:
DFSORT for sqlcode1 came up with 02300000
That doesn't make sense. DFSORT would have a leading blank, not a leading zero. [...]
Yes, sorry about that Frank, sorry sqlcode1. It did come up with a leading blank in sqlcode1's run. TS/OP claims a different result for the other product. End of story.