View previous topic :: View next topic
|
Author |
Message |
tspr52
New User
Joined: 12 Sep 2006 Posts: 31 Location: Madrid, Spain
|
|
|
|
Dear Colleagues,
I want to multiply a record from the input file like this:
---+----1----+----2----+----3----+----4----+----5----+----6--
AAAEX.PADM.LOAD 5.70K
AAAEX.PADM.LOAD 5.70K
AAAEX.PADM.LOAD.CHMBCK 5.70K
AAAEX.PADM.LOAD.CHMBCK 5.70K
If size is in Kbytes (53,1=K) i need to multiply the number for 1024
The JCL i am currently used for that is the following:
//SORT01 EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTIN DD DSN=&&DCODMS07,DISP=OLD
//SORTOUT DD SYSOUT=*
//SYSIN DD *
OPTION COPY
INREC IFTHEN=(WHEN=(53,1,CH,EQ,C'K'),
OVERLAY=(47:47,6,ZD,MUL,+1024,TO=ZD,LENGTH=3))
What i am receiving is an error SC07 and i am unable to follow up.
Really appreciate any help, pointers. Thanks in advance. |
|
Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008 Posts: 2010 Location: USA
|
|
|
|
1) All your "5.70K" are located at varying positions of input records.
You cannot use fixed position in your compare, and MUL operations.
There is option PARSE in several SORT statements, to handle varying field positions.
2) Format ZD does not handle decimal point; only numeric characters are allowed.
RTFM |
|
Back to top |
|
|
tspr52
New User
Joined: 12 Sep 2006 Posts: 31 Location: Madrid, Spain
|
|
|
|
Hello Sergeyken and many thanks for your reply
All 5.70 k are in the same position. Unfortunately, positions has moved to left before close the post. I add code for paste the screen. Sorry for the inconvenience.
I am going to try with PD instead of ZD.
Code: |
---+----1----+----2----+----3----+----4----+----5----+----6----+----
AAAEX.PADM.LOAD 5.70K
AAAEX.PADM.LOAD.CHMBCK 5.70K
AAAEX.PADM.LOAD.CHMBCK 5.70K
AAAEX.PADM.MENSAJE 5.70K
AAAEX.PADM.MENSAJE 5.70K
AAAEX.PADM.MENSAJE.CHMBCK 5.70K
|
|
|
Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008 Posts: 2010 Location: USA
|
|
|
|
Anyway, ZD doesn't handle decimal point.
RTFM |
|
Back to top |
|
|
tspr52
New User
Joined: 12 Sep 2006 Posts: 31 Location: Madrid, Spain
|
|
|
|
Yes, i am going to change for PD |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
PD won't help. Look at UFF. |
|
Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008 Posts: 2010 Location: USA
|
|
|
|
Quote: |
UFF
Unsigned free format. Decimal digits (0-9) are extracted from right to
left to form a positive number value. All non-decimal digit values in the
field are ignored. A maximum of 31 digits can be provided. When more
than 31 digits are found in the field, the leftmost digits will be ignored. |
With UFF the decimal point in input will be ignored (with any other garbage).
SORT step will not fail, but the result of MUL operation is still wrong... |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Why would the result of the MUL (or a correct MUL, I haven't looked at any actual code) be wrong? |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Although looking at the code, LENGTH=3 is certainly not going to go well.
tspr52,
How do you expect to multiply by 1024 and only end up with three useful digits? What are you trying to do? |
|
Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008 Posts: 2010 Location: USA
|
|
|
|
Bill Woodger wrote: |
Why would the result of the MUL (or a correct MUL, I haven't looked at any actual code) be wrong? |
Because (5.70K * 1024) - in UFF format - will give 583680 as result of MUL. Decimal point is ignored. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
And your point is? SORT knows nothing about decimal places. So what do you do, just not multiply anything, or do your own scaling? A simple EDIT takes care of that, as does just putting the data and assuming there is a decimal place there. |
|
Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008 Posts: 2010 Location: USA
|
|
|
|
Bill Woodger wrote: |
And your point is? SORT knows nothing about decimal places. So what do you do, just not multiply anything, or do your own scaling? A simple EDIT takes care of that, as does just putting the data and assuming there is a decimal place there. |
My point is only - the result of standard operation MULtiplication is incorrect based on the rules of arithmetic. It can, or cannot, be fixed later, of course. But (5.70 * 1024) = 583680 is wrong anyway. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Is there a machine-instruction anywhere, on any chip, which has an actual decimal-point? Are you suggesting that all computer calculations are somehow "wrong" for this lack? |
|
Back to top |
|
|
tspr52
New User
Joined: 12 Sep 2006 Posts: 31 Location: Madrid, Spain
|
|
|
|
Hello i changed my dfsort code like this:
Code: |
//SORT01 EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTIN DD DSN=TMPEX.DATASET.REPORT.SALIDA.R,DISP=SHR
//SORTOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
OPTION COPY
INREC IFTHEN=(WHEN=(53,1,CH,EQ,C'K'),
OVERLAY=(47:47,5,ZD,MUL,+100,EDIT=(TTT.T),47:9X))
|
I am expecting yet s0c7 abend code and i am unable to go up. Any suggestion, please?
[/code] |
|
Back to top |
|
|
tspr52
New User
Joined: 12 Sep 2006 Posts: 31 Location: Madrid, Spain
|
|
|
|
Hello, finally i got it.
Code: |
//SORT01 EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTIN DD DSN=TMPEX.DATASET.REPORT.SALIDA.R,DISP=SHR
//SORTOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
OPTION COPY
INREC IFTHEN=(WHEN=(53,1,CH,EQ,C'K'),
OVERLAY=(45:47,6,UFF,MUL,+1024,EDIT=(TTTTT.TT),LENGTH=8))
|
Any sugestion will be welcome
Thanks and regards |
|
Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008 Posts: 2010 Location: USA
|
|
|
|
Bill Woodger wrote: |
Is there a machine-instruction anywhere, on any chip, which has an actual decimal-point? Are you suggesting that all computer calculations are somehow "wrong" for this lack? |
When one uses a simple digital calculator, it shows (5.70 * 1024) = 5836.80
When trying to use the MUL operation of SORT to do the same, it shows (5.70 * 1024) = 583680
My point is only, that some extra effort is needed to get correct result after MUL. In that case the major issue is, understanding of the problem, and not monkey-style copy-pasting of the code.
Nothing had been mentioned about allowed decimal positions in input data. If decimal point was optional, or its position was varying, it would cause serious problem to fix the result using SORT tools only.
Similar situation is with machine instructions, too. And I know this very well after 30+ years of using stuff from Assembler to ...whatever else.
[/b] |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
sergeyken wrote: |
When trying to use the MUL operation of SORT to do the same, it shows (5.70 * 1024) = 583680
|
No, it doesn't show that. It will choke, badly, on 5.70.
That was the whole point of the question.
If you want to scale one of the inputs but refuse to scale the output, for sure, you'll get the answer wrong.
SORT won't, because it won't scale either the source or the result. The scaling is up to the coder. SORT does the multiplication how it is documented, and it is up to the coder to do anything else they need. |
|
Back to top |
|
|
|