I think I goofed up on this. Rereading about the TRUNC option in the book says that it applies only when doing a computation or MOVE _into_ a BINARY (COMP) field. It doesn't say anything about COMP-3 fields. And I can't find anything in any of the manuals about truncating (or not) the high digit on a COMP-3 when the number of digits in the receiving field is even.
On Fri, Sep 6, 2013 at 10:49 AM, Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > And John is right, the zeroing of the high-order nibble does depend on the > compile option TRUNC, so do double-check the value of the TRUNC option that > was used to compile existing programs that use this data definition. Be > especially cautious if the TRUNC option was set differently for different > programs when they were last compiled. > > Peter > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of John McKown > Sent: Friday, September 06, 2013 11:43 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Comp-3 data defintion > > "It depends!". When you define a variable in COBOL as PIC S9(4) COMP-3 (aka > PACKED-DECIMAL). As you said, PIC S9(5) COMP-3 also takes up 3 bytes of > storage. What is actually store in those three bytes in the former case > depends on the TRUNC option. TRUNC(STD) will ensure that the PIC S9(4) > COMP-3 only has 4 digits of data by unconditionally setting the high order > nybble (decimal digit) to zero. I.e. if you do something like 5001 + 5000 > the real answer is 10001. With TRUNC(STD), COBOL will ensure the that value > stored is 0001 (or 0x00001C in hex). IIRC, if you compile TRUNC(OPT) (or > was it TRUNC(BIN)?), COBOL does not insert the code to "zero out" the high > digit and it will be stored a 0x10001C). But when DISPLAY'ed or MOVEd to an > X(4) field, the high digit will be eliminated. > > > So can you have a problem? Well, maybe. If this S9(4) COMP-3 datum is > stored in a data set. And the "wrong" TRUNC option, then the data in the > file might actually have a non-zero high order digit. So when you read the > existing data with the S9(5) COMP-3 definition, that high digit _might_ > suddenly become significant. I'd judge this as unlikely. But being the > paranoid SOB that I am, I would "cleanse" my data to be sure. I _hate_ this > sort of "surprise!!" event. > > > > On Fri, Sep 6, 2013 at 10:22 AM, Ron Thomas <ron5...@gmail.com> wrote: > > > Hello > > > > We have a job in which the input file that is comming has one on the > field > > (Location Number) is defined as X(4). This file is comming from a > different > > system. > > > > Now here in our programs we are modifying the this field to 5 bytes from > > the orginal 4 bytes. We are putting transformation step previous to this > > step and expanding to 5 bytes . We will be removing this process once > the > > other system sends the file with a 5 bye customer number. > > > > So now the issue is in some files the data is stored as s9(04) comp-3 > here > > we are planning to make as s9(05) comp-3. Do we need to apply > > transformations here ? both the data defintions occupy 3 bytes > > > > Is there any chance of data getting corrupted ? if data transformations > to > > be applied then how this can be done ? assume that the loaction number > > starts in the file from 10'th position . > > > > > > Thanks, > > Ron T > -- > > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- As of next week, passwords will be entered in Morse code. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
