Phil, Well, AFAIK at least current Enterprise COBOL compilers do not make it easy to process "all significant" PD format. It's not impossible, but it's annoying.
I haven't run across very much of this kind of PD usage in a business application since the retirement of an old multitasking assembler application that I used to support. Not saying it doesn't exist out there in the wild (it does), but not so much in my experience. And as far as I know only assembler "supports" the "all significant" format effectively (MVO is your friend here). I suppose any of the supported HLL's can be coerced into using such data, though how efficiently would be the question in each case. As to why use PD format at all, I suspect in many cases you are talking about file or record formats designed when storage (both in-memory and external) was far more expensive per byte and saving bytes counted for a lot. The fact that the decimal value is readable in a dump is an advantage not to be denigrated. When that call comes at oh-dark-thirty, every minute counts. There is also the PD arithmetic argument. As you point out it doesn't seem likely that applications need arithmetic on SSN's or CC numbers, but wouldn't computing check-digits be one such calculation? Personally, I haven't particularly cared if a positive PD field used "F" or "C" for the sign nibble for a long time. I've been far more concerned about the actual decimal values far more than the choice of sign nibble. I leave the database question to others more knowledgeable than I. HTH Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Phil Smith Sent: Tuesday, February 18, 2014 2:08 PM To: [email protected] Subject: Packed decimal (again!) A while ago, there was a somewhat contentious thread about packed decimal: whether it had to include the sign nybble or could just be all "significant" nybbles, and like that. I don't intend to revisit what the formal definition of "packed decimal" is or should be, but rather would like to understand real-world usage: 1) Do people use the "all significant" variant (e.g., a value of decimal 1234 stored in a halfword, x'1234', as opposed to 3 bytes, x'01234C')? 2) What languages do they use the "all significant" format from, if so? 3) How often do you use the "unsigned" nybble format (x'01234F' for "unsigned 1234")? 4) Which databases (DB2, yes; ADABAS, IMS, IDMS?) support packed decimal, and is it the "all significant" format, or just the "sign nybble" format? One of the meta-questions I'm trying to grok is why you would use packed decimal for things like SSNs. Sure, it's more compact than character; I get that (and we used to care about that, and maybe still do). But in either packed format, an SSN takes 5 bytes, but would fit in a fullword as binary. And you're not likely to be doing assembler EDIT/EDMK/ZAP/things like that on SSNs, so there's no benefit there. Is it that x'123456789C' is easier to read in memory or a dump when looking for SSN 123456789? Geographic prefix analysis (though I kind of thought only the SSA cared about that)? Something else? The same applies in spades to credit card numbers, which you're even less likely to be doing math on, though I suppose there's a bit more prefix analysis or IINs and the like, so maybe x'04000123456789123' for CCN 4000123456789123 might be a bit easier to process. Does COBOL make packed easier to work with? Yes, COBOL isn't my strongest language - "You say that like it's a negative thing", as Woody Allen would put it :) Thanks in advance for any wisdom! -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
