Re: Packed decimal and sign nibble
In 78a9dade-c8c5-4d7a-809d-df4db28ff...@comcast.net, on 04/28/2013 at 10:57 PM, Ed Gould edgould1...@comcast.net said: I think the edit mask was 40202020214B2020 (example the 21 forced a period before any numbers) '21'x is significance starter. my memory says (and I might be wrong) that the last character was say a 9C (by inserting a 0F ) it just worked. For either '9C'x or '9F'x, ED will interpret that as a 9 with a plus sign. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
In 5179dcaa.8030...@acm.org, on 04/25/2013 at 08:47 PM, Joel C. Ewing jcew...@acm.org said: An old, old historic convention with punch cards was to use an 11 punch above the rightmost digit on a card for negative numeric fields (which converts that column to represent EBCDIC X'D0' to X'D9) and no zone punch if positive, so PACK applied to bytes from such a field would get a consistent F sign for positive and D sign for negative and the result of the pack could be directly used as a Packed Decimal arithmetic operand. Going the other way, if you knew for certain that the packed number was positive and the sign nibble was F, then UnPack gives the correct EBCDIC character for the rightmost digit without any clean up. Unfortunately results of packed decimal arithmetic use C for positive results, so if unsure how a field was produced, something like an OI of F0 would be required on the rightmost byte for positive values to force a numeric character after an Unpack (or use some alternative unpack method like the Edit instruction). A minor simplification, granted, but being able to eliminate a few instructions is always aesthetically pleasing. What are you eliminating? If some of your data were produced with AP, then you need the code to deal with a C zone. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
Phil Smith wrote: That isn't what I asked, or at least not what I meant to ask: I'm asking about AFTER it's back in packed form, whether most things will care if the sign nibble has changed from unsigned to signed positive. Well, your question was somewhat open-ended, not really SIGNed... grin ;-D About that sign nibble - For myself, if I don't expect to work with negative numbers, then I don't care. Generally I use only one set of numeric formats in a program(s), either signed or not. So if I use, say COMP, then I use COMP only in all programs for all operations. Of course there are unavoidable exceptions, but as John Gilmore said, I don't mix them. (Yes, I see your example...that's, well, just plain strange!) COBOL is indeed plain strange! ;-) Anyway, I'm left with what feels like a Maybe. Which isn't what I'd hoped, but is what I feared. Maybe you could ask more probing questions to clarify this. I hope this discussion, despite all these entertaining drifts, was useful for you. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
On Wed, 24 Apr 2013 11:48:57 -0700, Phil Smith wrote: I'm asking about AFTER it's back in packed form, whether most things will care if the sign nibble has changed from unsigned to signed positive. If you are asking whether packed decimal arithmetic operations will be affected in any way if the sign is F, rather than C (or A or E), the answer is No. All of these values are treated as a positive sign and the decimal operations will behave exactly the same. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
There is in fact an advantage to using a sign value of F, b, instead of C, 1010b in some circumstances. See the programming note midway in the first column of page 8-3 of the current PrOp. John Gilmore, Ashland, MA 01721 - USA On 4/25/13, Tom Marchant m42tom-ibmm...@yahoo.com wrote: On Wed, 24 Apr 2013 11:48:57 -0700, Phil Smith wrote: I'm asking about AFTER it's back in packed form, whether most things will care if the sign nibble has changed from unsigned to signed positive. If you are asking whether packed decimal arithmetic operations will be affected in any way if the sign is F, rather than C (or A or E), the answer is No. All of these values are treated as a positive sign and the decimal operations will behave exactly the same. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FW: Packed decimal and sign nibble
On 24 Apr 2013 14:56:28 -0700, in bit.listserv.ibm-main you wrote: The packed decimal without sign nibble format, which is INPUT in SAS using the PKn format, is certainly not only from the '70s. There are 66 products that MXG Supports whose SMF/similar data records contain numeric data in that format. Which SMF records have packed decimal without the sign nibble. I don't recall that the 14, 15, 17, 18, 26, 30 or 60 series have that weird format. Clark Morris Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer MXG Softtware Merrill Consultants 10717 Cromwell Drive Dallas, TX 75229 ba...@mxg.com http://www.mxg.com - FAQ has Most Answers ad...@mxg.com - invoices/PO/Payment supp...@mxg.com- technical tel: 214 351 1966 - expect slow reply, use email fax: 214 350 3694 - prefer email, still works -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
On Thu, 25 Apr 2013 08:43:49 -0400, John Gilmore wrote: There is in fact an advantage to using a sign value of F, b, instead of C, 1010b in some circumstances. See the programming note midway in the first column of page 8-3 of the current PrOp. Do you mean the note that reads, Programming Note: Since is both the zone code and an alternate code for plus, unsigned (positive) decimal numbers may be represented in the zoned format with zone codes in all byte positions. The result of the PACK instruction converting such a number to the signed-packed-decimal format may be used directly as an operand for decimal instructions. I don't see what advantage you mean, unless you are simply saying that there is no need to adjust the sign bits. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FW: Packed decimal and sign nibble
Clark Morris wrote: There are 66 products that MXG Supports whose SMF/similar data records contain numeric data in that format. What SMF records? Which SMF records have packed decimal without the sign nibble. I don't recall that the 14, 15, 17, 18, 26, 30 or 60 series have that weird format. Neither me. I see in SMF fields like date (0cyydddF) and time (100th of second) for example in packed format. But I'm wondering about SMF21TUS for example which is documented as packed, but layout of contents are not documented. Topic drift: What is the difference between SMF21BRN (unsigned binary) and SMF21BW (binary) in terms of format layout? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
On 4/25/2013 8:01 AM, Tom Marchant wrote: On Wed, 24 Apr 2013 10:38:06 -0600, Steve Comstock wrote: So-called unsigned packed-decimal data is mis-leading at best because it cannot be used in any packed decimal arithmetic or compare operations Unsigned-Packed-Decimal was introduced in the sixth edition of the z/Architecture Principles of Operation, SA22-7832-05, along with the Decimal-floating-point facility. The publication date is April, 2007 I understand, I saw. I'm just saying the term is misleading, not-well chosen. But it is what it is, and it is official, so I'll use the term, but only with a slight snarl on my lips. :-) -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FW: Packed decimal and sign nibble
On 4/25/2013 7:56 AM, Elardus Engelbrecht wrote: Clark Morris wrote: There are 66 products that MXG Supports whose SMF/similar data records contain numeric data in that format. What SMF records? Which SMF records have packed decimal without the sign nibble. I don't recall that the 14, 15, 17, 18, 26, 30 or 60 series have that weird format. Neither me. I see in SMF fields like date (0cyydddF) and time (100th of second) for example in packed format. But I'm wondering about SMF21TUS for example which is documented as packed, but layout of contents are not documented. Topic drift: What is the difference between SMF21BRN (unsigned binary) and SMF21BW (binary) in terms of format layout? Groete / Greetings Elardus Engelbrecht Well, forever, the TIME macro with the DEC option has returned the time in packed-decimal-with-no-sign as: HHMMSSTH in R0 Maybe some SMF records use that output. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FW: Packed decimal and sign nibble
Steve Comstock wrote: What is the difference between SMF21BRN (unsigned binary) and SMF21BW (binary) in terms of format layout? Well, forever, the TIME macro with the DEC option has returned the time in packed-decimal-with-no-sign as: HHMMSSTH in R0 Thanks. I had to read it up and I see this too from TIME macro: The date is returned as packed decimal digits without a sign Maybe some SMF records use that output. Ok. Thanks for your heads-up! ;-) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
Thanks! From: Steve Comstock st...@trainersfriend.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, April 25, 2013 4:18 PM Subject: Re: Packed decimal and sign nibble On 4/25/2013 4:13 PM, Frank Swarbrick wrote: That's useful to know. We communicate with Visa and they use this format for many of the fields in their messages. Currently we use some overly clever COBOL to convert these to DISPLAY (zoned decimal) format. When I have time I'll see if I can write a little asm routine to use CDUTR andCSDTR for this. I guess I would have to follow a CDUTR with a CSDTR to convert it to signed-packed, and then use UNPK (if desired) to get it to zoned decimal. Interesting. Hmm. Maybe ED instead of UNPK, I think. From: Tom Marchant m42tom-ibmm...@yahoo.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, April 25, 2013 8:01 AM Subject: Re: Packed decimal and sign nibble On Wed, 24 Apr 2013 10:38:06 -0600, Steve Comstock wrote: So-called unsigned packed-decimal data is mis-leading at best because it cannot be used in any packed decimal arithmetic or compare operations Unsigned-Packed-Decimal was introduced in the sixth edition of the z/Architecture Principles of Operation, SA22-7832-05, along with the Decimal-floating-point facility. The publication date is April, 2007 -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
In cae1xxdfoflzbbxuvaammpcn2nqn9s46bnd7to8urosko87n...@mail.gmail.com, on 04/25/2013 at 08:43 AM, John Gilmore jwgli...@gmail.com said: There is in fact an advantage to using a sign value of F, b, instead of C, 1010b in some circumstances. If so, you haven't iodentified it. See the programming note midway in the first column of page 8-3 of the current PrOp. If you are referring to The result of the PACK instruction converting such a number to the signed-packed-decimal format may be used directly as an operand for decimal instructions., it applies equally well to 1100 (C) and 1110 (E). In effect, the note says that using F will do no harm, not that it has an advantage. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
On 04/25/2013 07:19 PM, Shmuel Metz (Seymour J.) wrote: In cae1xxdfoflzbbxuvaammpcn2nqn9s46bnd7to8urosko87n...@mail.gmail.com, on 04/25/2013 at 08:43 AM, John Gilmore jwgli...@gmail.com said: There is in fact an advantage to using a sign value of F, b, instead of C, 1010b in some circumstances. If so, you haven't iodentified it. See the programming note midway in the first column of page 8-3 of the current PrOp. If you are referring to The result of the PACK instruction converting such a number to the signed-packed-decimal format may be used directly as an operand for decimal instructions., it applies equally well to 1100 (C) and 1110 (E). In effect, the note says that using F will do no harm, not that it has an advantage. An old, old historic convention with punch cards was to use an 11 punch above the rightmost digit on a card for negative numeric fields (which converts that column to represent EBCDIC X'D0' to X'D9) and no zone punch if positive, so PACK applied to bytes from such a field would get a consistent F sign for positive and D sign for negative and the result of the pack could be directly used as a Packed Decimal arithmetic operand. Going the other way, if you knew for certain that the packed number was positive and the sign nibble was F, then UnPack gives the correct EBCDIC character for the rightmost digit without any clean up. Unfortunately results of packed decimal arithmetic use C for positive results, so if unsure how a field was produced, something like an OI of F0 would be required on the rightmost byte for positive values to force a numeric character after an Unpack (or use some alternative unpack method like the Edit instruction). A minor simplification, granted, but being able to eliminate a few instructions is always aesthetically pleasing. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Packed decimal and sign nibble
Suppose you have values that you're converting between character and packed decimal, in both directions at various times. You're a middleman, so you don't know what the application is going to be using the values for. For a non-negative value, packed decimal could be either positive or unsigned. What do folks usually do? Is it normal for code to actually care? That is, if we say Heck with it, we can't tell, so we'll just mark it positive, is that likely to cause problems? Or is use of unsigned rare enough that this is essentially a non-issue? (Hint: I'd like that last to be the case!) Obviously a sign= value could be passed around with the value, but that kind of metadata isn't in the stream now, so I'd rather not add it. Any and all ideas gratefully accepted... ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
On Wed, Apr 24, 2013 at 7:43 AM, Phil Smith p...@voltage.com wrote: Suppose you have values that you're converting between character and packed decimal, in both directions at various times. You're a middleman, so you don't know what the application is going to be using the values for. For a non-negative value, packed decimal could be either positive or unsigned. What do folks usually do? Is it normal for code to actually care? That is, if we say Heck with it, we can't tell, so we'll just mark it positive, is that likely to cause problems? Or is use of unsigned rare enough that this is essentially a non-issue? (Hint: I'd like that last to be the case!) Obviously a sign= value could be passed around with the value, but that kind of metadata isn't in the stream now, so I'd rather not add it. Any and all ideas gratefully accepted... It depends on how the packed data is used. If comparisons are always done using mathematical operators, then the sign bits will give results as expected. There are some places were the fields might not be checked for sign bits. 1) Sort control cards : SORT FIELDS=(1,5,A),FORMAT=BI 2) Assembler code that uses CLC to compare two packed fields 3) COBOL code that compares group level items with just 1 packed field subordinate. 3.1) 05 WS-PACKED-1 3.2) 10 WS-PACKED-1-1 pic S9(3) comp-3 value +1. 3.1) 05 WS-PACKED-2 3.2) 10 WS-PACKED-2-1 pic 9(3) comp-3 value 1. 3.3) If ws-packed-1 = ws-packed-2 3.3.1) Above will generate a CLC compare. 4) concatenated packed fields that are never used for math 4.1) 01 WS-BANK-KEY. 4.2) 05 WS-BRANCH pic s9(5) comp-3. 4.3) 05 ws-account pic s9(11) comp-3. 4.4) compares done as in 3.3 above. I've seen this used extensively where I currently work. They been on this road for 30 years. In Assembler it was easy to manage. Recently converted to COBOL and this makes for writing odd code. Original design was done to save the expense of CP vs. CLC. Now it is just painful. Sam ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
On 4/24/2013 8:43 AM, Phil Smith wrote: Suppose you have values that you're converting between character and packed decimal, in both directions at various times. You're a middleman, so you don't know what the application is going to be using the values for. For a non-negative value, packed decimal could be either positive or unsigned. Note that character decimal can also be positive or unsigned. PACK and UNPK preserve the sign settings in both directions What do folks usually do? Is it normal for code to actually care? That is, if we say Heck with it, we can't tell, so we'll just mark it positive, is that likely to cause problems? Or is use of unsigned rare enough that this is essentially a non-issue? (Hint: I'd like that last to be the case!) Obviously a sign= value could be passed around with the value, but that kind of metadata isn't in the stream now, so I'd rather not add it. Any and all ideas gratefully accepted... ...phsiii [Note: this is an experiment with Thunderbird, not explicitly setting the Reply-to, so you may need to reset.] -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
Phil Smith wrote: Is it normal for code to actually care? Of course, it is normal. For example, this COBOL statement checks the data (From COBOL manual): If Count-x is numeric then display Data is good Look for NUMPROC compiler option and NUMCLS option for COBOL for example. Try to do a COMPUTE with a character for a nice S0Cx abend. ;-D if we say Heck with it, we can't tell, so we'll just mark it positive, is that likely to cause problems? Yes, you will get problems, especially if you intend to do comparisions + calculations where signs are important. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
Sam Siegel wrote: 4) concatenated packed fields that are never used for math 4.1) 01 WS-BANK-KEY. 4.2) 05 WS-BRANCH pic s9(5) comp-3. 4.3) 05 ws-account pic s9(11) comp-3. 4.4) compares done as in 3.3 above. CLC from left to right? So 12345 wil compare with 12345678901 with result CC = 0 ? Just curious if you don't mind ;-) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
My understanding of the difference between unsigned and signed packed decimal values is that the rightmost sign nibble in a signed packed value is occupied by a digit in an unsigned value. Consider a four-byte value. The hardware interprets a signed value as |d|d|d|d|d|d|d|s|, a precision of 7 decimal digits. and an unsigned one as |d|d|d|d|d|d|d|d|, a precision of 8 decimal digits. They are thus easy to distinguish: the decimal digits are in the sequence , 0001, . . . 1001; and the signs are the [logically] larger four-bit values. Vide pp. 9-2ff of the PrOp. I do not recommend mixing them. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
My COBOL experience dates from the mid 80s, but - I would suggest to always use signed values with comp-3 (packed), and to mark values as positive, that have no explicit sign information And some questions: - is it possible today to have comp-3 values in COBOL, that have no sign nibble? In PL/1, for example, it is NOT possible to do this ... you have the UNSIGNED attribute only for BIN FIXED numeric data, not (yet) for DEC FIXED (CP et al. cannot handle unsigned decimal data). - if so, the generated CLC which compares such packed fields without sign nibbles with fields which have sign nibbles would yield very strange results ... - I believe that you must make sure that CPs are generated for such comparisons, because it's always possible that you get F sign nibbles instead of C for positive signs (after PACK), and they should compare OK - and only CP tolerates different sign nibbles Kind regards Bernd Am 24.04.2013 16:43, schrieb Phil Smith: Suppose you have values that you're converting between character and packed decimal, in both directions at various times. You're a middleman, so you don't know what the application is going to be using the values for. For a non-negative value, packed decimal could be either positive or unsigned. What do folks usually do? Is it normal for code to actually care? That is, if we say Heck with it, we can't tell, so we'll just mark it positive, is that likely to cause problems? Or is use of unsigned rare enough that this is essentially a non-issue? (Hint: I'd like that last to be the case!) Obviously a sign= value could be passed around with the value, but that kind of metadata isn't in the stream now, so I'd rather not add it. Any and all ideas gratefully accepted... ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
On Wed, Apr 24, 2013 at 8:11 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: Sam Siegel wrote: 4) concatenated packed fields that are never used for math 4.1) 01 WS-BANK-KEY. 4.2) 05 WS-BRANCH pic s9(5) comp-3. 4.3) 05 ws-account pic s9(11) comp-3. 4.4) compares done as in 3.3 above. CLC from left to right? So 12345 wil compare with 12345678901 with result CC = 0 ? Comparison is always done on group levels which are the same length. As mentioned, it is painful code. Just curious if you don't mind ;-) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
On 4/24/2013 9:19 AM, John Gilmore wrote: My understanding of the difference between unsigned and signed packed decimal values is that the rightmost sign nibble in a signed packed value is occupied by a digit in an unsigned value. Consider a four-byte value. The hardware interprets a signed value as |d|d|d|d|d|d|d|s|, a precision of 7 decimal digits. and an unsigned one as |d|d|d|d|d|d|d|d|, a precision of 8 decimal digits. No. The hardward does not recognize any such animal as an unsigned packed decimal digit. All packed decimal data carries a sign in the rightmost hex digit; x'A', x'C', x'E', and x'F' are considered to be positive, x'B', x'D' are considered to be negative, x'0'=x'9' are considered invalid and will abend you if you try to use such data in any packed decimal operation. They are thus easy to distinguish: the decimal digits are in the sequence , 0001, . . . 1001; and the signs are the [logically] larger four-bit values. Vide pp. 9-2ff of the PrOp. I do not recommend mixing them. The OP is not considering mixing them but is considering the vagaries of converting between packed and character numeric strings. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
On 4/24/2013 9:19 AM, Bernd Oppolzer wrote: My COBOL experience dates from the mid 80s, but - I would suggest to always use signed values with comp-3 (packed), and to mark values as positive, that have no explicit sign information My sense is the OP is not necessarily working in COBOL; probably Assembler. And some questions: - is it possible today to have comp-3 values in COBOL, that have no sign nibble? In PL/1, for example, it is NOT possible to do this ... you have the UNSIGNED attribute only for BIN FIXED numeric data, not (yet) for DEC FIXED (CP et al. cannot handle unsigned decimal data). No. Comp-3 (or, better in today's COBOL, packed-decimal) data will always have a sign nibble; but if you do not include an 'S' in the PICTURE clause, the compiler adds code to force the sign to always be positive after any arithmetic operation. - if so, the generated CLC which compares such packed fields without sign nibbles with fields which have sign nibbles would yield very strange results ... The compiler generates CLC for compares between unsigned packed-decimal data; if at least one of the comparands is signed, the CP instruction will be used, and works just fine, thank you. - I believe that you must make sure that CPs are generated for such comparisons, because it's always possible that you get F sign nibbles instead of C for positive signs (after PACK), and they should compare OK - and only CP tolerates different sign nibbles Kind regards Bernd Am 24.04.2013 16:43, schrieb Phil Smith: Suppose you have values that you're converting between character and packed decimal, in both directions at various times. You're a middleman, so you don't know what the application is going to be using the values for. For a non-negative value, packed decimal could be either positive or unsigned. What do folks usually do? Is it normal for code to actually care? That is, if we say Heck with it, we can't tell, so we'll just mark it positive, is that likely to cause problems? Or is use of unsigned rare enough that this is essentially a non-issue? (Hint: I'd like that last to be the case!) Obviously a sign= value could be passed around with the value, but that kind of metadata isn't in the stream now, so I'd rather not add it. Any and all ideas gratefully accepted... ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
Fixing some typos in my own response: On 4/24/2013 9:34 AM, Steve Comstock wrote: On 4/24/2013 9:19 AM, John Gilmore wrote: My understanding of the difference between unsigned and signed packed decimal values is that the rightmost sign nibble in a signed packed value is occupied by a digit in an unsigned value. Consider a four-byte value. The hardware interprets a signed value as |d|d|d|d|d|d|d|s|, a precision of 7 decimal digits. and an unsigned one as |d|d|d|d|d|d|d|d|, a precision of 8 decimal digits. No. The hardward does not recognize any such animal as an unsigned packed decimal digit. All packed decimal data carries a sign in the rightmost hex digit; x'A', x'C', x'E', and x'F' are considered to be positive, x'B', x'D' are considered to be negative, x'0'=x'9' are considered invalid and will abend you if you try to use such data in any packed decimal operation. should be: No. The hardware does not recognize any such animal as an unsigned packed decimal data item. All packed decimal data carries a sign in the rightmost hex digit; x'A', x'C', x'E', and x'F' are considered to be positive, x'B', x'D' are considered to be negative, x'0'-x'9' are considered invalid and will abend you if you try to use such data in any packed decimal operation. They are thus easy to distinguish: the decimal digits are in the sequence , 0001, . . . 1001; and the signs are the [logically] larger four-bit values. Vide pp. 9-2ff of the PrOp. I do not recommend mixing them. The OP is not considering mixing them but is considering the vagaries of converting between packed and character numeric strings. John Gilmore, Ashland, MA 01721 - USA -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
Like Steve my first reaction was also that the hardware only knew about signed packed decimal and that unsigned packed was just a software convention; but I looked at z10 Principles of Op, and it explicitly defines both signed and unsigned packed decimal as zArchitecture data formats. In addition to the ancient Move With Offset, which POp mentions as user of unsigned packed, apparently some of the newer Decimal Floating Point instructions (Convert To/From Unsigned Packed) also work with unsigned packed decimal values. Since MVO never really cared about nibble content at all, it seems a stretch to say it represents support for packed decimal, signed or unsigned; but the newer DFP instructions, which actually force/require valid decimal nibbles, are clearly true hardware support for unsigned packed decimal. Joel C Ewing On 04/24/2013 10:34 AM, Steve Comstock wrote: On 4/24/2013 9:19 AM, John Gilmore wrote: My understanding of the difference between unsigned and signed packed decimal values is that the rightmost sign nibble in a signed packed value is occupied by a digit in an unsigned value. Consider a four-byte value. The hardware interprets a signed value as |d|d|d|d|d|d|d|s|, a precision of 7 decimal digits. and an unsigned one as |d|d|d|d|d|d|d|d|, a precision of 8 decimal digits. No. The hardward does not recognize any such animal as an unsigned packed decimal digit. All packed decimal data carries a sign in the rightmost hex digit; x'A', x'C', x'E', and x'F' are considered to be positive, x'B', x'D' are considered to be negative, x'0'=x'9' are considered invalid and will abend you if you try to use such data in any packed decimal operation. They are thus easy to distinguish: the decimal digits are in the sequence , 0001, . . . 1001; and the signs are the [logically] larger four-bit values. Vide pp. 9-2ff of the PrOp. I do not recommend mixing them. The OP is not considering mixing them but is considering the vagaries of converting between packed and character numeric strings. John Gilmore, Ashland, MA 01721 - USA -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
I recommended 'against' mixing signed and unsigned values. There is a route for conversion. I have just tested it, and it works. A decimal floating-point (DFP) value can be converted to unsigned packed using the instruction Convert to unsigned packed and an unsigned packed value can be converted to DFP using the instruction Convert From Unsigned Packed. (Convert To Signed Packed and Convert from Signed Packed instructions are also available. About the rest of Steve Comstock's strange post, I can only suggest that he 1) read or reread the PrOp section I cited and 2) conduct some experiments. Unsigned packed decimal exists, and its y-byte values contain 2y four-bit binary coded digits. For the convenience of others I quote briefly begin extract In the unsigned-packed-decimal format, each byte contains two decimal digits (D) and therte is no sign. /end extract The usefulness of this format is open to question. Its existence is not. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
Hello Bernd, if you compile the COBOL Program with Option LIST you can see clear Assembler which can help you. Best regards Alfred Am 24.04.2013 um 17:22 schrieb Bernd Oppolzer bernd.oppol...@t-online.de: My COBOL experience dates from the mid 80s, but - I would suggest to always use signed values with comp-3 (packed), and to mark values as positive, that have no explicit sign information And some questions: - is it possible today to have comp-3 values in COBOL, that have no sign nibble? In PL/1, for example, it is NOT possible to do this ... you have the UNSIGNED attribute only for BIN FIXED numeric data, not (yet) for DEC FIXED (CP et al. cannot handle unsigned decimal data). - if so, the generated CLC which compares such packed fields without sign nibbles with fields which have sign nibbles would yield very strange results ... - I believe that you must make sure that CPs are generated for such comparisons, because it's always possible that you get F sign nibbles instead of C for positive signs (after PACK), and they should compare OK - and only CP tolerates different sign nibbles Kind regards Bernd Am 24.04.2013 16:43, schrieb Phil Smith: Suppose you have values that you're converting between character and packed decimal, in both directions at various times. You're a middleman, so you don't know what the application is going to be using the values for. For a non-negative value, packed decimal could be either positive or unsigned. What do folks usually do? Is it normal for code to actually care? That is, if we say Heck with it, we can't tell, so we'll just mark it positive, is that likely to cause problems? Or is use of unsigned rare enough that this is essentially a non-issue? (Hint: I'd like that last to be the case!) Obviously a sign= value could be passed around with the value, but that kind of metadata isn't in the stream now, so I'd rather not add it. Any and all ideas gratefully accepted... ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 04/24/2013 11:41:53 AM: From: Steve Comstock st...@trainersfriend.com No. The hardward does not recognize any such animal as an unsigned packed decimal digit. But clever Assembler programmers created such fields. Just this week I worked on an S0C7 because some clever person introduced character data into a packed unsigned field. If you have to deal with these kinds of fields in Cobol, you need: ENVIRONMENT DIVISION. CONFIGURATION SECTION. SPECIAL-NAMES. CLASS packedNosignNumeric IS X'00' THROUGH X'09' X'10' THROUGH X'19' X'20' THROUGH X'29' X'30' THROUGH X'39' X'40' THROUGH X'49' X'50' THROUGH X'59' X'60' THROUGH X'69' X'70' THROUGH X'79' X'80' THROUGH X'89' X'90' THROUGH X'99' . DATA DIVISION. WORKING-STORAGE SECTION. 01. 05 P4V1 PIC V9COMP-3 VALUE ZERO. 05 REDEFINES P4V1. 10 P4NS PIC XX. 10 PIC X. If the packedNosignNumeric fails on a test, we use an Assembler subroutine to convert to character. A clever programmer can do it in Cobol. btw somewhere in this conversation, there was a statement about the character comparison of fields of different lengths. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
On 4/24/2013 10:19 AM, Joel C. Ewing wrote: Like Steve my first reaction was also that the hardware only knew about signed packed decimal and that unsigned packed was just a software convention; but I looked at z10 Principles of Op, and it explicitly defines both signed and unsigned packed decimal as zArchitecture data formats. In addition to the ancient Move With Offset, which POp mentions as user of unsigned packed, apparently some of the newer Decimal Floating Point instructions (Convert To/From Unsigned Packed) also work with unsigned packed decimal values. Since MVO never really cared about nibble content at all, it seems a stretch to say it represents support for packed decimal, signed or unsigned; but the newer DFP instructions, which actually force/require valid decimal nibbles, are clearly true hardware support for unsigned packed decimal. OK, fair enough. I went back to the POO and re-read. Kind of a travesty, in my mind. I consider so-called unsigned packed decimal to be just a convention; as you say, it's support by MVO is really no more than the support MVO has for any arbitrary bit string; and as an operand for the instructions to convert between decimal floating point and packed decimal, the result of CUDTR and CUXTR instructions is found in a register, not in storage. So-called unsigned packed-decimal data is mis-leading at best because it cannot be used in any packed decimal arithmetic or compare operations. It's just a string of hex digits each of which are between x'0' and x'9'. Not related at all to the OP, at any rate. Joel C Ewing On 04/24/2013 10:34 AM, Steve Comstock wrote: On 4/24/2013 9:19 AM, John Gilmore wrote: My understanding of the difference between unsigned and signed packed decimal values is that the rightmost sign nibble in a signed packed value is occupied by a digit in an unsigned value. Consider a four-byte value. The hardware interprets a signed value as |d|d|d|d|d|d|d|s|, a precision of 7 decimal digits. and an unsigned one as |d|d|d|d|d|d|d|d|, a precision of 8 decimal digits. No. The hardward does not recognize any such animal as an unsigned packed decimal digit. All packed decimal data carries a sign in the rightmost hex digit; x'A', x'C', x'E', and x'F' are considered to be positive, x'B', x'D' are considered to be negative, x'0'=x'9' are considered invalid and will abend you if you try to use such data in any packed decimal operation. They are thus easy to distinguish: the decimal digits are in the sequence , 0001, . . . 1001; and the signs are the [logically] larger four-bit values. Vide pp. 9-2ff of the PrOp. I do not recommend mixing them. The OP is not considering mixing them but is considering the vagaries of converting between packed and character numeric strings. John Gilmore, Ashland, MA 01721 - USA -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 04/24/2013 11:41:53 AM: From: Steve Comstock st...@trainersfriend.com No. The hardward does not recognize any such animal as an unsigned packed decimal digit. But clever Assembler programmers created such fields. Just this week I worked on an S0C7 because some clever person introduced character data into a packed unsigned field. If you have to deal with these kinds of fields in Cobol, you need: ENVIRONMENT DIVISION. CONFIGURATION SECTION. SPECIAL-NAMES. CLASS packedNosignNumeric IS X'00' THROUGH X'09' X'10' THROUGH X'19' X'20' THROUGH X'29' X'30' THROUGH X'39' X'40' THROUGH X'49' X'50' THROUGH X'59' X'60' THROUGH X'69' X'70' THROUGH X'79' X'80' THROUGH X'89' X'90' THROUGH X'99' . DATA DIVISION. WORKING-STORAGE SECTION. 01. 05 P4V1 PIC V9COMP-3 VALUE ZERO. 05 REDEFINES P4V1. 10 P4NS PIC XX. 10 PIC X. If the packedNosignNumeric fails on a test, we use an Assembler subroutine to convert to character. A clever programmer can do it in Cobol. btw somewhere in this conversation, there was a statement about the character comparison of fields of different lengths. Sendus interruptus 6.1.6.5.1 Alphanumeric comparisons Operands of unequal size: If the operands are of unequal size, the comparison is made as though the shorter operand were extended to the right with enough spaces to make the operands equal in size. 6.1.6.5.5 Group comparisons A group comparison is a comparison of the alphanumeric character values of two operands. For the comparison operation, each operand is treated as though it were an elementary data item of category alphanumeric of the same size as the operand, in bytes. The comparison then proceeds as for two elementary operands of category alphanumeric, as described in Alphanumeric comparisons in topic 6.1.6.5.1. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
The PrOp says: | There are two signed-decimal formats, | signed-packed and unsigned-packed. This is clear. It is also clear that mixing them combined with data-type punning can lead to disaster. Finally, it is clear that Mr. Comstock is not so well read in the current, i.e., 2008, PrOp as he should be. He and others should do their homework before they pontificate. In one of John McCarthy's favorite apothegms: Do the math or shut up. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
Apropos of this topic, one of our folks tripped across this definition of packed decimal: In this case of logic, the actual decimals are so small they are at the nanometer size. That way you can pack millions of them into one space, and when you are done you have a regular sized decimal. (http://answers.yahoo.com/question/index?qid=20080716072148AA2K2vs) I like it! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
And...there it is, the infamous Gilmore rudeness. This is by definition a professional forum. When you aren't having a tantrum, your responses *do* add value, but then you lose it again. Steve Comstock's post quite reasonably noted that what you found in the PofOp is not what COBOL and friends mean by packed decimal, nor is it what the instructions that work on packed decimal expect. I'd more call this an error in the PofOp than anything else (and plan to RFC it). In any case, your response was, as it so often is, unprofessional. You took yourself off the assembler list because you couldn't bear the thought of comity http://www.merriam-webster.com/dictionary/comity; far be it from me to suggest you do the same here, but be advised that your pissiness makes you look foolish, and is hardly in keeping with the intent or tone of the list. On Wed, Apr 24, 2013 at 1:01 PM, John Gilmore jwgli...@gmail.com wrote: The PrOp says: | There are two signed-decimal formats, | signed-packed and unsigned-packed. This is clear. It is also clear that mixing them combined with data-type punning can lead to disaster. Finally, it is clear that Mr. Comstock is not so well read in the current, i.e., 2008, PrOp as he should be. He and others should do their homework before they pontificate. In one of John McCarthy's favorite apothegms: Do the math or shut up. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
On 4/24/2013 11:01 AM, John Gilmore wrote: The PrOp says: | There are two signed-decimal formats, | signed-packed and unsigned-packed. This is clear. It is also clear that mixing them combined with data-type punning can lead to disaster. Finally, it is clear that Mr. Comstock is not so well read in the current, i.e., 2008, PrOp as he should be. He and others should do their homework before they pontificate. In one of John McCarthy's favorite apothegms: Do the math or shut up. Interesting defensive position, John. Attacking in defense of your fastidiousness. I would not call my posts 'pontificating'; I thought we were having a discussion, some give and take, if you will. I actually had read that stuff about unsigned packed decimal some years ago but decided to ignore it because it was not practical from the standpoint of the audience I work with, z/OS applications developers. Perhaps I was wrong in that perception. Let me put it out now: how many people are using decimal floating point in Assembler? I suppose there are some who use it from a high level language, most likely Java, but I suspect it has not caught on in a big way yet, in any language. Clearly the OP was not including what I think I will start calling 'pseudo-packed-decimal' in his question. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
On 24 Apr 2013 10:26:34 -0700, in bit.listserv.ibm-main you wrote: On 4/24/2013 11:01 AM, John Gilmore wrote: The PrOp says: | There are two signed-decimal formats, | signed-packed and unsigned-packed. This is clear. It is also clear that mixing them combined with data-type punning can lead to disaster. Finally, it is clear that Mr. Comstock is not so well read in the current, i.e., 2008, PrOp as he should be. He and others should do their homework before they pontificate. In one of John McCarthy's favorite apothegms: Do the math or shut up. Interesting defensive position, John. Attacking in defense of your fastidiousness. I would not call my posts 'pontificating'; I thought we were having a discussion, some give and take, if you will. I actually had read that stuff about unsigned packed decimal some years ago but decided to ignore it because it was not practical from the standpoint of the audience I work with, z/OS applications developers. Perhaps I was wrong in that perception. Let me put it out now: how many people are using decimal floating point in Assembler? I suppose there are some who use it from a high level language, most likely Java, but I suspect it has not caught on in a big way yet, in any language. Clearly the OP was not including what I think I will start calling 'pseudo-packed-decimal' in his question. Having read Principles of operation, I agree with your posting. The preferred and arithmetically generated (results of add, etc.) are x'C' and x'D' but the other values are valid signs. I think the COBOL IF NUMERIC tests recognize sign zones based on the NUMPROC option which affects at least how the x'F' value is treated. Unfortunately COBOL STILL does NOT recognize DFP. Talk about IBM not talking to IBM. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
One of the very first bugs I had to find was in a COBOL program written implementing an algorithm to distribute a rounding error back into a set of transactions. The COBOL program, written by another programmer, went into a loop when the remaining error value was negative packed decimal zero. Worked fine if the remaining error arrived at positive zero. I think I was less than a year total employment in the industry at the time. 1981 Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
Thanks to all for the replies. Some comments/followup questions. First, just to be clear: I'm talking about packed decimal with a sign nibble, as the Subject: line says, not the perversion that's just a bunch o' nibbles with no sign. Steve Comstock wrote: Note that character decimal can also be positive or unsigned. PACK and UNPK preserve the sign settings in both directions True-and not being rude (at least, not trying to), but: I don't see how this relates to my question. Or are you suggesting that the character versions could use a + sign in front to indicate that it's signed? Given that this is actually encryption, and a positive value might encrypt to a negative one, that turns out not to work, since +1 could encrypt to -1 and then when we decrypt that, we won't know whether the 1 should be signed or not. Elardus Engelbrecht wrote: Of course, it is normal. For example, this COBOL statement checks the data (From COBOL manual): If Count-x is numeric then display Data is good Look for NUMPROC compiler option and NUMCLS option for COBOL for example. Try to do a COMPUTE with a character for a nice S0Cx abend. ;-D That isn't what I asked, or at least not what I meant to ask: I'm asking about AFTER it's back in packed form, whether most things will care if the sign nibble has changed from unsigned to signed positive. And: Yes, you will get problems, especially if you intend to do comparisions + calculations where signs are important. Other than CLC (which I would argue isn't how you should be comparing packed values), how does it matter? X + (unsigned 5) == X + (+5), no? (Yes, I see your example...that's, well, just plain strange!) Anyway, I'm left with what feels like a Maybe. Which isn't what I'd hoped, but is what I feared. Thanks again, -- ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
Phil: One system I worked on *ASSUMED* all positive numbers (it was a bank savings system) so the assumption (reasonable) was positive. Not sure about other systems. Ed On Apr 24, 2013, at 9:43 AM, Phil Smith wrote: Suppose you have values that you're converting between character and packed decimal, in both directions at various times. You're a middleman, so you don't know what the application is going to be using the values for. For a non-negative value, packed decimal could be either positive or unsigned. What do folks usually do? Is it normal for code to actually care? That is, if we say Heck with it, we can't tell, so we'll just mark it positive, is that likely to cause problems? Or is use of unsigned rare enough that this is essentially a non-issue? (Hint: I'd like that last to be the case!) Obviously a sign= value could be passed around with the value, but that kind of metadata isn't in the stream now, so I'd rather not add it. Any and all ideas gratefully accepted... ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
On 4/24/2013 12:43 PM, John Gilmore wrote: zMan accuses me of 'pissiness'. In fact I posted a neutral technical exposition of the two packed-decimal formats. Mr Comstock responded with, No, inaccurate text. Now he and others are free use words as they please. There is august precedent for doing so. As Lewis Carroll wrote in TtLG, When I use a word, Humpty Dumpty said, in a rather scornful tone, it means just what I choose it to mean—neither more nor less. Still, this forum is [mostly] about zArchitecture machines, and for them there are two packed-decimal formats. My own view of the packed-decimal data type was never enthusiastic and is now very negative. Awww. Storage-to-storage arithmetic was always obscene, but there was a sort of rationale for its use in some business applications: HFP and BFP can yield rounding results that surprise the uninitiated. Mike Cowlishaw's DFP has now dealt definitively with these problems, and any rationale for doing even business arithmetic in anything but DFP has now also been removed. Well, unless you need to work with numeric entities that already exist in non-DFP format, or data that is accessed from programs written in languages that don't [yet] support the DFP format. Of course, those objections are trivial to you, so we'll pass them by. The question how many people use DFP in assembly language is one that I do not really know the answer to. I should guess not many, but that is only a guess, and I myself use it routinely. (It is rather easier to use in assembly language than HFP, and both it and BFP make available conversion instructions the absence of which was the chief obstacle to the use of HFP in assembly language.) Ah, see, now we are talking about something we can focus on objectively, and I'm sure I can learn from you. So, you use DFP routinely. Let me ask, in your code where you use DFP, what format is your data in initially? Does it come to your program in zoned decimal, [classic] packed decimal, binary, HFP, BFP? Or do you only deal with data that is either stored in DFP or data your program defines internally? The way I read the Pops (if you prefer to 'POO'), to get data into DFP, if it is not already in that format, you have to convert from one of these formats: a signed binary integer (fullword or doubleword in a GPR) an unsigned binary integer (fullword or doubleword in a GPR) an eight byte [classic] packed decimal string (in a GPR) a 16 byte [classic] packed decimal string (in a pair of GPRs) an eight byte 'unsigned packed decimal' value (in a a GPR) a 16 byte 'unsigned packed decimal' value (in a pair of GPRs) of course, none of these source formats is available from standard data entry sources (i.e.: keyboards, scanners); ultimately, user data gets into the system by keying or scanning which usually results in character strings in some encoding (most typically EBCDIC). To go from character string to a format that can then be converted to DFP requires, at the least, a PACK instruction. The result there is classic packed decimal, which you could then load into a GPR and thence convert to DFP. Is that the approach you take, then, in your code? Just curious. If there is any significant feeling that I should withdraw from this list too, I am quite willing to do so. It can survive handily without me and I without it. Now now, you're not going to let others dictate your actions are you? Are you a man or a mouse, John? (of course, that may depend on your definitions, as you reference above.) John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Fwd: Re: Packed decimal and sign nibble
Some thoughts: - at our site we too use packed decimal without sign nibble heavily in our ASSEMBLER applications, and we have a macro to deal with those fields (e.g. add a x'0c' at the end to it, just to activate them for computing) - this is old legacy stuff from the 70s. DECIMAL (8,0) UNSIGNED is converted to DECIMAL (9,1) SIGNED this way - very easy. - I could imagine flavors of COBOL and PL/1 which support this, doing the same thing under the cover. DB2 DATE fields are internally structured this way. We had a similar problem with one byte binary length fields - also legacy stuff from the 70s - until PL/1 came up with BIN FIXED(8) UNSIGNED. - If my language of choice doesn't support UNSIGNED for a particular data format and I find in the database or somewhere else fields which are unsigned and I need to work on them, I always will consider them to be implicitly positive (what else?), and so I will convert them to positive signed values of the same type which I can work on with my language of choice. This is what the OP IMHO should do, given the situation, that no real unsigned packed decimal data in COBOL exists. Maybe I got the question of the OP wrong, but I thought that he really talks of UNSIGNED decimal data, and due to my limited knowledge of COBOL, I was not sure if this possibly exists today. Kind regards Bernd Am 24.04.2013 19:26, schrieb Steve Comstock: I actually had read that stuff about unsigned packed decimal some years ago but decided to ignore it because it was not practical from the standpoint of the audience I work with, z/OS applications developers. Perhaps I was wrong in that perception. Let me put it out now: how many people are using decimal floating point in Assembler? I suppose there are some who use it from a high level language, most likely Java, but I suspect it has not caught on in a big way yet, in any language. Clearly the OP was not including what I think I will start calling 'pseudo-packed-decimal' in his question. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
The notion that input data are not in an internal floating-point format, be it BFP, DFP, or HFP, is unarguable. This is also true of binary integers. Indeed there is our at least should always be a distinction between external. displayable|printable values and internal, coimputationally convenient. Some of the input data I work with are in classical engineering notation, e.g., +1.414213256237309504880e+000, Some are external fixed-point, e.g., +1.414213256237309504880, some are external integers, e.g., -5, and some are pairs (a,b) of one of these that represent the complex number a + bi. They are all converted into the appropriate internal format, readily, and stored as such in files or RDBs. Conversions occur only at input and output, display or report preparation. Thus begin extract To go from character string to a format that can then be converted to DFP requires, at the least, a PACK instruction. /end extract is almost aways an entirely correct but unproblematic truism. (There is an ancient model of a computer system that is said to 1) read in an integer augend, 2) add anoither integer added to it, and 3) output the resulting sum; and for such 'systems' many conversions may be intolerably burdensome; but such systems are not really of much interest.) I, and I am not alone in this, find the idea of doing arithmetic on display values absurd. COBOL notionally permits this, but only by sleight of hand. The to-and-fro conversions are hidden away in library subroutines. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
The packed decimal without sign nibble format that I mentioned in my last post is in fact a database format - it was of course not a relational database, but a home grown hierarchical database that predated DB2 and IMS - and it was used in the 70s to save space, because for values that are known to be always positive, it is not necessary to store the sign, and space was of concern in those days. To work with those fields, the sign was added after input, and the arithmetic was done using the normal decimal arithmetic instructions. Although this is not the same situation as of the OP's question, I think that the same procedure could well be appropriate to the OP's problem. BTW: the database exists until today, but today it is implemented on top of DB2. The database records are LONG VARCHARs of DB2, only the keys are translated to DB2 fields and indexes. It was not possible to do a real conversion to DB2 - too expensive. Only from time to time some parts of the database are migrated to real DB2 - step by step. The application last year had its 40th anniversary - still supporting the business. Kind regards Bernd Am 24.04.2013 21:56, schrieb John Gilmore: The notion that input data are not in an internal floating-point format, be it BFP, DFP, or HFP, is unarguable. This is also true of binary integers. Indeed there is our at least should always be a distinction between external. displayable|printable values and internal, coimputationally convenient. Some of the input data I work with are in classical engineering notation, e.g., +1.414213256237309504880e+000, Some are external fixed-point, e.g., +1.414213256237309504880, some are external integers, e.g., -5, and some are pairs (a,b) of one of these that represent the complex number a + bi. They are all converted into the appropriate internal format, readily, and stored as such in files or RDBs. Conversions occur only at input and output, display or report preparation. Thus begin extract To go from character string to a format that can then be converted to DFP requires, at the least, a PACK instruction. /end extract is almost aways an entirely correct but unproblematic truism. (There is an ancient model of a computer system that is said to 1) read in an integer augend, 2) add anoither integer added to it, and 3) output the resulting sum; and for such 'systems' many conversions may be intolerably burdensome; but such systems are not really of much interest.) I, and I am not alone in this, find the idea of doing arithmetic on display values absurd. COBOL notionally permits this, but only by sleight of hand. The to-and-fro conversions are hidden away in library subroutines. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
FW: Packed decimal and sign nibble
The packed decimal without sign nibble format, which is INPUT in SAS using the PKn format, is certainly not only from the '70s. There are 66 products that MXG Supports whose SMF/similar data records contain numeric data in that format. Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer MXG Softtware Merrill Consultants 10717 Cromwell Drive Dallas, TX 75229 ba...@mxg.com http://www.mxg.com - FAQ has Most Answers ad...@mxg.com - invoices/PO/Payment supp...@mxg.com- technical tel: 214 351 1966 - expect slow reply, use email fax: 214 350 3694 - prefer email, still works -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
On Wed, 24 Apr 2013 15:56:26 -0400, John Gilmore wrote: I, and I am not alone in this, find the idea of doing arithmetic on display values absurd. COBOL notionally permits this, but only by sleight of hand. The to-and-fro conversions are hidden away in library subroutines. I notice you never say anything about Rexx. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Packed decimal and sign nibble
In b870629719727b4ba82a6c06a31c291239b5168...@hqmailsvr01.voltage.com, on 04/24/2013 at 07:43 AM, Phil Smith p...@voltage.com said: Suppose you have values that you're converting between character and packed decimal, in both directions at various times. You're a middleman, so you don't know what the application is going to be using the values for. If clarifying the specifications is not an option, I would just use PACK/UNPK and preserve the existing sign[1]. Note that an F zone will be treated as a plus sign in packed arithmetic. This assumes that by unsigned you mean a sign of F. If the customer also has the newer unsigned-packed-decimal format, all bets are off. [1] I'm assuming that you are using signed decimal with the sign in the zone of the low order digit, not in a separate sign byte. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
