Re: Interpreting Explicit Decimal Numbers
Bob, You should go back and read all of Dave's posts and and the responses. This has all been discussed down to the "jot and tittle". Including the fact that Dave is on z/VSE, not z/OS. Tony Thigpen Bob Raicer wrote on 2/18/22 20:05: Dave -- I'm not clear on what you mean by "precision" and "scale" when you say: "transform a zoned-decimal number with up to 31 digits of precision and up to 15 digits for scale with an external sign and an explicit decimal point into a packed number that is properly aligned." Do you mean "precision" in the same sense as the definition contained in the Rexx documentation included below? Does "scale" mean a scaling factor in the sense of how COBOL defines it with the "P" character in a PICTURE string? That is, each "P" character in the PICTURE string represents a power of 10 (negative or positive, depending upon where the "P" characters appears in the PICTURE string relative to the "9"s in the string) which is to be used as a multiplier on the actual value. For example, PICTURE 999ppp means the actual area in storage for this data item is only large enough to store three decimal digits, but the value is to be interpreted as being multiplied by 10**3. So a value of "123" is to be interpreted as "123000" when used in, for example, arithmetic operations. Perhaps you intend to mean "scale" as the number of decimal digits to the right of an explicitly specified decimal point, where you intend to support up to 15 such digits. I also don't understand where (or how) implied decimal points are specified in your conversion and representation scheme. For what it's worth, why don't you do all (or the majority) of your decimal string validation and manipulation stuff in Rexx? You're already writing Rexx code and doing this in Rexx itself is way easier and, overall, more robust. ::: . Open Object Rexx Reference . V4.2 (2014-01-10) . . 10.1. Precision . . Precision is the maximum number of significant digits that can . result from an operation. This is controlled by the instruction: . . >>-NUMERIC DIGITS--++--;--->< . +-expression-+ . . The expression is evaluated and must result in a positive whole . number. This defines the precision (number of significant digits) . of a calculation. Results are rounded to that precision, if . necessary. . . If you do not specify expression in this instruction, or if no . NUMERIC DIGITS instruction has been processed since the start of a . program, the default precision is used. The Rexx standard for the . default precision is 9. . . NUMERIC DIGITS can set values smaller than nine. However, use . small values with care because the loss of precision and rounding . affects all Rexx computations, including, for example, the . computation of new values for the control variable in DO loops. . . . NUMERIC DIGITS . . Controls the precision to which arithmetic operations and built-in . functions are evaluated. If you omit expression1, the precision . defaults to 9 digits. . . There is no limit to the value for DIGITS (except the amount of . storage available), but high precisions are likely to require a . great amount of processing time. It is recommended that you use . the default value whenever possible . ::: . . z/OS Version 2 Release 4 TSO/E REXX Reference (SA32-0972-40) . . Precision . . Precision is the maximum number of significant digits that can . result from an operation. This is controlled by the instruction: . . . >>-NUMERIC DIGITS--++--;--->< . +-expression-+ . . The expression is evaluated and must result in a positive whole . number. This defines the precision (number of significant digits) . to which calculations are carried out. Results are rounded to . that precision, if necessary. . . If you do not specify expression in this instruction, or if no . NUMERIC DIGITS instruction has been processed since the start of a . program, the default precision is used. The REXX standard for the . default precision is 9. . . Note that NUMERIC DIGITS can set values below the default of nine. . However, use small values with care - the loss of precision and . rounding thus requested affects all REXX computations, including, . for example, the computation of new values for the control . variable in DO loops. . . . NUMERIC DIGITS . . Controls the precision to which arithmetic operations and . arithmetic built-in functions are evaluated. If you omit . expression1, the precision defaults to 9 digits. . . There is no limit to the value for DIGITS (except the amount of . storage available), but note that high precisions are likely to . require a good deal of processing time. It is suggested that you . use the default value wherever possible .
Re: Interpreting Explicit Decimal Numbers
On Feb 18, 2022, at 18:05:07, Bob Raicer wrote: > ... > You're already writing Rexx code and doing this in > Rexx itself is wayeasier and, overall, more robust. > > ::: > . Open Object Rexx Reference > . V4.2 (2014-01-10) > . 10.1. Precision > ::: > . z/OS Version 2 Release 4 TSO/E REXX Reference (SA32-0972-40) > . Precision > .... Which is he using? Do they differ? Is GAAP a requirement? Does either Rexx support GAAP? Does COBOL? Does DFP? -- gil
Re: Interpreting Explicit Decimal Numbers
Dave -- I'm not clear on what you mean by "precision" and "scale" when you say: "transform a zoned-decimal number with up to 31 digits of precision and up to 15 digits for scale with an external sign and an explicit decimal point into a packed number that is properly aligned." Do you mean "precision" in the same sense as the definition contained in the Rexx documentation included below? Does "scale" mean a scaling factor in the sense of how COBOL defines it with the "P" character in a PICTURE string? That is, each "P" character in the PICTURE string represents a power of 10 (negative or positive, depending upon where the "P" characters appears in the PICTURE string relative to the "9"s in the string) which is to be used as a multiplier on the actual value. For example, PICTURE 999ppp means the actual area in storage for this data item is only large enough to store three decimal digits, but the value is to be interpreted as being multiplied by 10**3. So a value of "123" is to be interpreted as "123000" when used in, for example, arithmetic operations. Perhaps you intend to mean "scale" as the number of decimal digits to the right of an explicitly specified decimal point, where you intend to support up to 15 such digits. I also don't understand where (or how) implied decimal points are specified in your conversion and representation scheme. For what it's worth, why don't you do all (or the majority) of your decimal string validation and manipulation stuff in Rexx? You're already writing Rexx code and doing this in Rexx itself is way easier and, overall, more robust. ::: . Open Object Rexx Reference . V4.2 (2014-01-10) . . 10.1. Precision . . Precision is the maximum number of significant digits that can . result from an operation. This is controlled by the instruction: . . >>-NUMERIC DIGITS--++--;--->< . +-expression-+ . . The expression is evaluated and must result in a positive whole . number. This defines the precision (number of significant digits) . of a calculation. Results are rounded to that precision, if . necessary. . . If you do not specify expression in this instruction, or if no . NUMERIC DIGITS instruction has been processed since the start of a . program, the default precision is used. The Rexx standard for the . default precision is 9. . . NUMERIC DIGITS can set values smaller than nine. However, use . small values with care because the loss of precision and rounding . affects all Rexx computations, including, for example, the . computation of new values for the control variable in DO loops. . . . NUMERIC DIGITS . . Controls the precision to which arithmetic operations and built-in . functions are evaluated. If you omit expression1, the precision . defaults to 9 digits. . . There is no limit to the value for DIGITS (except the amount of . storage available), but high precisions are likely to require a . great amount of processing time. It is recommended that you use . the default value whenever possible . ::: . . z/OS Version 2 Release 4 TSO/E REXX Reference (SA32-0972-40) . . Precision . . Precision is the maximum number of significant digits that can . result from an operation. This is controlled by the instruction: . . . >>-NUMERIC DIGITS--++--;--->< . +-expression-+ . . The expression is evaluated and must result in a positive whole . number. This defines the precision (number of significant digits) . to which calculations are carried out. Results are rounded to . that precision, if necessary. . . If you do not specify expression in this instruction, or if no . NUMERIC DIGITS instruction has been processed since the start of a . program, the default precision is used. The REXX standard for the . default precision is 9. . . Note that NUMERIC DIGITS can set values below the default of nine. . However, use small values with care - the loss of precision and . rounding thus requested affects all REXX computations, including, . for example, the computation of new values for the control . variable in DO loops. . . . NUMERIC DIGITS . . Controls the precision to which arithmetic operations and . arithmetic built-in functions are evaluated. If you omit . expression1, the precision defaults to 9 digits. . . There is no limit to the value for DIGITS (except the amount of . storage available), but note that high precisions are likely to . require a good deal of processing time. It is suggested that you . use the default value wherever possible . :::
Re: Interpretting Explicit Decimal Numbers
Thanks for all the advice. I'm still testing, but it appears that the following is going to work for me. You'll notice that this performed routine doesn't reapply the negative sign. Sometimes I want to retain the original sign and sometimes I don't. So, the points from where this routine is performed make the decision as to whether to reapply any negative sign that may be needed or even force a x'F' sign. * === * PPACKVAR DS0H PARSE& ZONED DECIMAL STRING WITH ALIGNMENT * --- * *COMPUTE ALIGNMENT NEEDED (IF ANY) LLC R0,=X'4B' SEARCH FOR DECIMAL POINT LAR1,VARDATA POINT TO KEY DATA SOURCE L R2,SHVVALL SET LENGTH OF VAR DATA LAR3,0(R2,R1) POINT TO SEARCH ENDING LRR4,R3AND SAVE THAT ADDRESS IFR3,(NM,SRST),R1 IF NO MATCH ON DECIMAL POINT LR4,KEY_DECM GET DECIMAL ALIGNMENT NEEDED ELSE ELSE SHI R2,1 MINUS 1 FOR DECIMAL POINT ST R2,SHVVALL REPLACE LENGTH OF VAR DATA SR R4,R3COMPUTE REMAINING LENGTH LA R1,1(,R3)POINT TO CHAR AFTER DECIMAL LR R2,R4COPY REMAINING LENGTH VALUE SHI R2,1 DECREMENT BEFORE EXECUTE EX R2,ADJUST_IT REMOVE DECIMAL POINT IF R2,(EQ,C),KEY_DECM IF ENOUGH DECIMALS FOUND XR R4,R4 NO ALIGNMENT NEEDED ELSE ELSE IF R2,(LT,C),KEY_DECMIF TOO FEW DECIMALS FOUND L R4,KEY_DECMGET DECIMALS WANTED SR R4,R2 CALC. DECIMALS NEEDED ELSE ELSE TOO MANY DECIMALS FOUND S R2,KEY_DECMCALC. DECIMALS TO REMOVE L R4,SHVVALL GET LENGTH OF VAR DATA SR R4,R2 REMOVE EXTRA DECIMALS ST R4,SHVVALL REPLACE WITH NEW LENGTH XR R4,R4 AND NO ALIGNMENT NEEDED ENDIF ENDIF ENDIF ENDIF ENDIF ENDIF * PACK AND ALIGN THE DATA LAR1,VARDATA POINT TO KEY DATA SOURCE L R2,SHVVALL SET LENGTH OF VAR DATA IFVARDATA,EQ,C'-',OR,VARDATA,EQ,C'+' AHI R1,1 SKIP SIGN BYTE SHI R2,1 AND REDUCE LENGTH ENDIF SHI R2,1DECREMENT BEFORE EXECUTE EXR2,PACK_IT PACK VAR DATA INTO WORK FLD WHILE R4,(NZ,LTR),R4 LOOP ON ALIGNMENT NEEDED MP PWORK16,=P'10' ADD 1 DECIMAL PLACE SHI R4,1 DECR. DECIMALS NEEDED WEND LOOP ON ALIGNMENT NEEDED * --- * BRR5 RETURN TO CALLER ADJUST_IT MVC 0(0,R3),0(R1) (SEE FIRST "EX" INSTR. ABOVE) PACK_IT PKA PWORK16,0(0,R1) (SEE SECOND "EX" INSTR. ABOVE) * === * Sincerely, Dave Clark -- int.ext: 91078 direct: (937) 531-6378 home: (937) 751-3300 Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *
