Comp-3 data

I've never used comp-3 data before and I need to know if there is a way
to move the following:

05  W-SSN  PIC S9(5) COMP-3.

05 O-SSN PIC 9(9).

Move W-SSN to O-SSN.

I have tried moving the comp-3 field to the numeric field and get
leading zeros in the numeric field.

So in W-SSN I have the number 123456789 comp-3 and I move it to the
numeric field I get 000012345 as the result. Any idea why I dont get
123456789.

Thank,

Billy

On 30 Jun 2006 10:15:47 -0700, "bcarter97" <bcarter97@hotmail.com>
wrote:

>
>05  W-SSN  PIC S9(5) COMP-3.
>
>05 O-SSN PIC 9(9).
>
>Move W-SSN to O-SSN.
>
>I have tried moving the comp-3 field to the numeric field and get
>leading zeros in the numeric field.
>
>So in W-SSN I have the number 123456789 comp-3 and I move it to the
>numeric field I get 000012345 as the result. Any idea why I dont get
>123456789.

How did you get the number 123456789 in a field that can only hold 5
digits?

CoBOL pictures don't care how the number is stored - the size of the
number is the size of the picture.

Posted Via mcse.ms Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.mcse.ms

"bcarter97" <bcarter97@hotmail.com> wrote:
>I've never used comp-3 data before and I need to know if there is a way
>to move the following:
>
>05  W-SSN  PIC S9(5) COMP-3.
>
>05 O-SSN PIC 9(9).
>
>Move W-SSN to O-SSN.
>
>I have tried moving the comp-3 field to the numeric field and get
>leading zeros in the numeric field.
>
>So in W-SSN I have the number 123456789 comp-3

Are you sure?  How can you fit a nine digit number
into a field you've declared as five digits?  On
IBM mainframe, that would generate a 3-byte field.

--
Ron
(user ron
in domain spamblocked.com)

bcarter97 wrote:
> I've never used comp-3 data before and I need to know if there is a way
> to move the following:
>
> 05  W-SSN  PIC S9(5) COMP-3.
>
> 05 O-SSN PIC 9(9).
>
> Move W-SSN to O-SSN.
>
> I have tried moving the comp-3 field to the numeric field and get
> leading zeros in the numeric field.
>
> So in W-SSN I have the number 123456789 comp-3 and I move it to the
> numeric field I get 000012345 as the result. Any idea why I dont get
> 123456789.

Try specifying W-SSN as "PIC S9(9) COMP-3" instead of S9(5).  You're
telling the compiler you've got nine digits, and it will figure out that
it needs to allocate five bytes.

Louis

bcarter97 wrote:
> I have tried moving the comp-3 field to the numeric field and get
> leading zeros in the numeric field.

Look, I haven't written a line of COBOL in more than five years but the
correct answer is...

"You get leading zeros because the PICTURE clause is PIC 9(9), and  this
PICTURE clause specifies a numeric digit 0 to 9 is to appear in each
postion."


On the truncation of the SSN... as Mr. Krupp suggested, your PICTURE clause
on the SSN may be incorrect.  You can't fit nine decimal digits into a PIC
9(5) dataname regardless of usage ["COMP-3" is a USAGE] same as you can't
fit ten pounds of dog crap in a five-pound bag.

MCM

bcarter97 wrote:
> I've never used comp-3 data before and I need to know if there is a
> way to move the following:
>
> 05  W-SSN  PIC S9(5) COMP-3.
>
> 05 O-SSN PIC 9(9).
>
> Move W-SSN to O-SSN.
>
> I have tried moving the comp-3 field to the numeric field and get
> leading zeros in the numeric field.

A field defined as 9(anything) will contain the digits 0-9 only. Never a +
or -, never a blank, never a letter, the digits 0 through 9 only.

>
> So in W-SSN I have the number 123456789 comp-3 and I move it to the
> numeric field I get 000012345 as the result. Any idea why I dont get
> 123456789.

You do NOT have 123456789 in W-SSN. Won't fit. You told the compiler, in the
definition, that the field only had FIVE digits. "123456789" is NINE digits.
You simply cannot fit nine pounds of anything in a five-pound sack.

Go back and look.... how do you think 123456789 GOT into W-SSN? If you have
an instruction that moved that value into W-SSN, the compiler, knowing it
wouldn't fit, truncated the value.

On 30 Jun 2006 10:15:47 -0700, "bcarter97" <bcarter97@hotmail.com>
enlightened us:

>I've never used comp-3 data before and I need to know if there is a way
>to move the following:
>
>05  W-SSN  PIC S9(5) COMP-3.
>

If you were looking at this field in storage, it would look like this:


000
00S

Note: S = Sign.  You are saying W-SSN has only 5 numeric digits. Since
you also specified COMP-3, on IBM Mainframe that will take up 3 bytes
as I've shown.

>05 O-SSN PIC 9(9).
>

In storage, this field will look like this:

SSSSSSSSS
000000000

Note:  S= sign.  If a postive number S could be C or F.  If negative S
will be F for the first 8 bytes and D for the last bye.  In the COMP-3
example, the S will be either a C (postivie) or D (negative).

>Move W-SSN to O-SSN.
>
>I have tried moving the comp-3 field to the numeric field and get
>leading zeros in the numeric field.
>

This is because you are moving 3 bytes packed (5 bytes unpacked) to a
9 byte numeric unpacked field.  By rule the result field will be
padded with leading zeroes as necessary.

>So in W-SSN I have the number 123456789 comp-3 and I move it to the
>numeric field I get 000012345 as the result. Any idea why I dont get
>123456789.
>

It is not possible for W-SSN to contain 123456789.  If, for example,
you move 123456789 to W-SSN, high order truncation would occur and
W-SSN would contain 56789.

>Thank,
>
>Billy

Regards,
////
(o o)
-oOO--(_)--OOo-


SAM: "What's new Normie?"
NORM: "Terrorists, Sam. They've taken over my stomach and they're
demanding beer."
From the US TV Sitcom, "Cheers"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

"SkippyPB" <swiegand@neo.rr.NOSPAM.com> wrote in message
 news:6l7da2tqj7223n0lefkev9khjba14t2mmg@
4ax.com...
> On 30 Jun 2006 10:15:47 -0700, "bcarter97" <bcarter97@hotmail.com>
> enlightened us:
> 
>
> If you were looking at this field in storage, it would look like this:
>
> 000
> 00S
>
> Note: S = Sign.  You are saying W-SSN has only 5 numeric digits. Since
> you also specified COMP-3, on IBM Mainframe that will take up 3 bytes
> as I've shown.

I'm glad you qualified the "3 bytes" with "on IBM mainframe."   While three
bytes is all which is meaningful for this PICTURE and USAGE, it assumes BYTE
alignment... some compilers use WORD alignment in which both binary and BCD
numbers always occupy an integral multiple of 16 bits.

MCM

"Michael Mattias" <michael.mattias@gte.net> schrieb im Newsbeitrag
news:jAxpg.32208$VE1.21441@newssvr14.news.prodigy.com...
> "SkippyPB" <swiegand@neo.rr.NOSPAM.com> wrote in message
>  news:6l7da2tqj7223n0lefkev9khjba14t2mmg@
4ax.com... 
>
> I'm glad you qualified the "3 bytes" with "on IBM mainframe."   While
> three
> bytes is all which is meaningful for this PICTURE and USAGE, it assumes
> BYTE
> alignment... some compilers use WORD alignment in which both binary and
> BCD
> numbers always occupy an integral multiple of 16 bits.
>

Really, which compiler is that ? Alignment has nothing to do with
allocation if that is what you meant.

Roger

Michael Mattias wrote:
> "SkippyPB" <swiegand@neo.rr.NOSPAM.com> wrote in message
>  news:6l7da2tqj7223n0lefkev9khjba14t2mmg@
4ax.com... 
>
> I'm glad you qualified the "3 bytes" with "on IBM mainframe."   While
> three bytes is all which is meaningful for this PICTURE and USAGE, it
> assumes BYTE alignment... some compilers use WORD alignment in which
> both binary and BCD numbers always occupy an integral multiple of 16
> bits.

Not to be picky, but the original poster specified:

05 xxxx
05 xxxx

Assuming three bytes for each, you're not suggesting a slack byte to force
the second item to a word boundary, are you?