Home > Archive > Cobol > July 2006 > Comp-3 data
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| bcarter97 2006-06-30, 6:55 pm |
| 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
| |
| Howard Brazee 2006-06-30, 6:55 pm |
| 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 Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
| |
|
| "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)
| |
| Louis Krupp 2006-06-30, 6:55 pm |
| 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
| |
| Michael Mattias 2006-06-30, 6:55 pm |
| 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
| |
| HeyBub 2006-06-30, 6:55 pm |
| 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.
| |
| SkippyPB 2006-07-01, 6:55 pm |
| 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
| |
| Michael Mattias 2006-07-01, 6:55 pm |
| "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
| |
| Roger While 2006-07-01, 6:55 pm |
|
"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
| |
| HeyBub 2006-07-01, 6:55 pm |
| 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?
| |
| SkippyPB 2006-07-02, 6:55 pm |
| On Sat, 01 Jul 2006 16:40:47 GMT, "Michael Mattias"
<michael.mattias@gte.net> enlightened us:
>"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.
>
>MCM
>
>
Even if the compiler forced word alignment, I believe the slack bytes
would be added before the field in question in storge to force it on
the alignment. It would not effect the size or contents of the
working storage field, only its address.
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
| |
| Michael Mattias 2006-07-02, 6:55 pm |
| "SkippyPB" <swiegand@neo.rr.NOSPAM.com> wrote in message
news:krnfa2p9ad1spi1k6as59m4vg2gt049o8n@
4ax.com...
> On Sat, 01 Jul 2006 16:40:47 GMT, "Michael Mattias"
> <michael.mattias@gte.net> enlightened us:
>
way[color=darkred]
three[color=darkred]
BYTE[color=darkred]
BCD[color=darkred]
>
> Even if the compiler forced word alignment, I believe the slack bytes
> would be added before the field in question in storge to force it on
> the alignment. It would not effect the size or contents of the
> working storage field, only its address.
Yes, that's all correct. However, the original post showed two (2)
consecutive "05" level datanames, and if OP is using "anything other than a
COBOL program (e.g., 'TSO Editor')" to look at the raw data in a disk
file/dataset, the alignment ("slack bytes") is significant. (Best choice
might be something like FileAid ***WITH**** the "use COBOL copylib xxx
option" )
A tutorial on COBOL datatypes may be downloaded from
http://www.flexus.com/download.html ; get file COBDATA.ZIP. While the demo
software is probably on or beyond its last legs (it's MS-DOS software), the
text tutorial is still valid.
--
Michael Mattias
Tal Systems, Inc.
Racine WI
(Author/Contributor of referenced tutorial)
| |
| HeyBub 2006-07-02, 6:55 pm |
| Michael Mattias wrote:
>
> Yes, that's all correct. However, the original post showed two (2)
> consecutive "05" level datanames, and if OP is using "anything other
> than a COBOL program (e.g., 'TSO Editor')" to look at the raw data
> in a disk file/dataset, the alignment ("slack bytes") is significant.
> (Best choice might be something like FileAid ***WITH**** the "use
> COBOL copylib xxx option" )
>
Huh? Are you suggesting (under any conditions on any machine with any
compiler) that two consecutive fields (05 levels) defined as 9(5) COMP-3
have a slack byte between them?
If yes, well....
If not, why bring up the subject of slack bytes at all?
| |
| Michael Mattias 2006-07-03, 7:55 am |
| "HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:12agerjc839jn57@news.supernews.com...
> Michael Mattias wrote:
>
> Huh? Are you suggesting (under any conditions on any machine with any
> compiler) that two consecutive fields (05 levels) defined as 9(5) COMP-3
> have a slack byte between them?
> If yes, well....
Absolutely... because USAGE COMP-3 is "implementor-defined" (PACKED-DECIMAL
is the 'standard') and therefore the total storage on disk is not
guaranteed. ('89 standard, don't know about 2002. Too bad Bill K is on
vacation, he'd know).
As far as PACKED-DECIMAL... I'd have to look that up and right now I don't
feel like doing that. But I believe aligment within a group item is
generally handled with the optional SYNC[HRONIZED] keyword in the USAGE
clause.
But let's be practical.. it costs little or nothing to 'check it out' if it
is of interest, right?
MCM
| |
| HeyBub 2006-07-03, 6:55 pm |
| Michael Mattias wrote:
> "HeyBub" <heybubNOSPAM@gmail.com> wrote in message
> news:12agerjc839jn57@news.supernews.com...
>
>
> Absolutely... because USAGE COMP-3 is "implementor-defined"
> (PACKED-DECIMAL is the 'standard') and therefore the total storage on
> disk is not guaranteed. ('89 standard, don't know about 2002. Too
> bad Bill K is on vacation, he'd know).
>
> As far as PACKED-DECIMAL... I'd have to look that up and right now I
> don't feel like doing that. But I believe aligment within a group
> item is generally handled with the optional SYNC[HRONIZED] keyword in
> the USAGE clause.
>
> But let's be practical.. it costs little or nothing to 'check it out'
> if it is of interest, right?
I think you should really, REALLY take a breath, step back, and re-think the
proposition. In essence, you assert that when presented with a record of the
following form:
00 00 1C 00 00 2C
there is no (easy) way to process the values therein. Further, you claim
there is no (easy) way to even write the record in the first place! By
non-easy, I mean the programmer has to know about slack bytes and manuever
bytes around to get the selected value into a re-defined COMP-3 field.
In my days on machines that had slack-bytes, their presence was virtually
invisible to the programmer and only appeared in WS.
| |
| SkippyPB 2006-07-03, 6:55 pm |
| On Mon, 3 Jul 2006 09:35:21 -0500, "HeyBub" <heybubNOSPAM@gmail.com>
enlightened us:
>Michael Mattias wrote:
>
>I think you should really, REALLY take a breath, step back, and re-think the
>proposition. In essence, you assert that when presented with a record of the
>following form:
>
>00 00 1C 00 00 2C
>
>there is no (easy) way to process the values therein. Further, you claim
>there is no (easy) way to even write the record in the first place! By
>non-easy, I mean the programmer has to know about slack bytes and manuever
>bytes around to get the selected value into a re-defined COMP-3 field.
>
>In my days on machines that had slack-bytes, their presence was virtually
>invisible to the programmer and only appeared in WS.
>
I think you are all going a little astray here. If you look at the
fields as they are stored on a medium (disk, tape) they would be next
to each other, no slack bytes. However, if you were looking at the
fields in storage, aka memory, it is possible due to the way COMP-3 is
implemented that they would not be adjacent to each other. There
could be some number of slack bytes in between them.
The OP never mentioned anything about looking at the fields. That was
my comment and I made the example as if there were no slack bytes.
Michael has just pointed out that if you are indeed looking at the
fields in memory, there could be slack bytes in between the fields.
Regards,
////
(o o)
-oOO--(_)--OOo-
"Now son, you don't want to drink beer.
That's for Daddys, and kids with fake IDs."
-- Homer Simpson
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove nospam to email me.
Steve
| |
| Richard 2006-07-03, 6:55 pm |
|
SkippyPB wrote:
> I think you are all going a little astray here. If you look at the
> fields as they are stored on a medium (disk, tape) they would be next
> to each other, no slack bytes. However, if you were looking at the
> fields in storage, aka memory, it is possible due to the way COMP-3 is
> implemented that they would not be adjacent to each other. There
> could be some number of slack bytes in between them.
If there is a record in an FD and a record in WS and they are defined
using the same group and elementary fields then they had better have
the exactly the same byte layout else a READ INTO or WRITE FROM would
give garbage.
You may get slack bits between fields but should only get slack bytes
between fields that are explicity SYNC or between records (01 levels)
and 77 levels.
| |
| HeyBub 2006-07-03, 6:55 pm |
| SkippyPB wrote:
>
> I think you are all going a little astray here. If you look at the
> fields as they are stored on a medium (disk, tape) they would be next
> to each other, no slack bytes. However, if you were looking at the
> fields in storage, aka memory, it is possible due to the way COMP-3 is
> implemented that they would not be adjacent to each other. There
> could be some number of slack bytes in between them.
Okay, I'm game. How do you GET the fields from an external medium (disk or
tape) to storage? READ INTO obviously won't work. Hmm. Ah, I've got it!
MOVE FD-FIELD-A to WS-FIELD-A
Wait! That won't work either if the COMP-3 stuff is expected to be on some
specific boundary...
Mumble-mumble. How about :
MOVE FD-FIELD-A-GROUP to WS-FIELD-A-GROUP
Yeah, that should cover all the bases!
I'm off to convert all our programs just in case they ever get moved to a
compiler that is positively anal about field boundaries.
On second thought, it would be easier to pick a sane compiler instead.
>
> The OP never mentioned anything about looking at the fields. That was
> my comment and I made the example as if there were no slack bytes.
> Michael has just pointed out that if you are indeed looking at the
> fields in memory, there could be slack bytes in between the fields.
>
Well, yes. The OP had a problem with field truncation. The thread
degenerated...
| |
| Pete Dashwood 2006-07-04, 7:55 am |
|
"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:12aj0gteisno443@news.supernews.com...
> SkippyPB wrote:
>
> Okay, I'm game. How do you GET the fields from an external medium (disk or
> tape) to storage? READ INTO obviously won't work. Hmm. Ah, I've got it!
>
> MOVE FD-FIELD-A to WS-FIELD-A
>
> Wait! That won't work either if the COMP-3 stuff is expected to be on some
> specific boundary...
>
> Mumble-mumble. How about :
>
> MOVE FD-FIELD-A-GROUP to WS-FIELD-A-GROUP
>
> Yeah, that should cover all the bases!
>
> I'm off to convert all our programs just in case they ever get moved to a
> compiler that is positively anal about field boundaries.
>
> On second thought, it would be easier to pick a sane compiler instead.
>
>
>
>
> Well, yes. The OP had a problem with field truncation. The thread
> degenerated...
What would you expect when you get a bunch of degenerates posting to it...
:-)
Pete.
>
| |
| William M. Klein 2006-07-08, 6:55 pm |
| Bill K is back and he says,
1) Anything and everything about COMP-3 is "implementor defined". They CAN do
just about anything with it. HOWEVER, as a practical matter most implementors
introduced it when there was IBM and everyone else, so they did it the say that
IBM did on their mainframes.
2) Packed-Decimal is "processor dependent" and an implementor doesn't need to do
it at all. If they do it, they need to use "radius 10" storage, but I don't
think the Standard ('85 or '02) says much more about it.
3) The biggest "real world" difference that I have seen with "packed decimal"
(not Usage Packed-Decimal) data across implementations has to do with "even
number of digits without S in picture" storage, e.g.
05 How-Big Pic 9(4) Packed-Decimal (or COMP-3)
some implementations FORCE a sign-nibble for X'F' (unsigned indicator) and
others don't. So whether this takes 2 bytes or 3 bytes will vary (with 3 bytes
most common, but not universal).
(See also a medium-common extension of COMP-6 for this type of data)
4) The only other problem that I have heard of is for implementations with NO
"byte-boundary" requirement, e.g.
01 Group1.
05 Field-1 Pic S9(04) Packed-Decimal. (or comp-3
05 Field-2 Pic S9(04) Packed-Decimal.
I believe that there were (and maybe still are) some compilers that allow the
first field to take 2 1/2 bytes and to be followed IMMEDIATELY (in the middle of
a byte) by the second field.
--
Bill Klein
wmklein <at> ix.netcom.com
"Michael Mattias" <michael.mattias@gte.net> wrote in message
news:UC8qg.79560$4L1.65068@newssvr11.news.prodigy.com...
> "HeyBub" <heybubNOSPAM@gmail.com> wrote in message
> news:12agerjc839jn57@news.supernews.com...
>
>
> Absolutely... because USAGE COMP-3 is "implementor-defined" (PACKED-DECIMAL
> is the 'standard') and therefore the total storage on disk is not
> guaranteed. ('89 standard, don't know about 2002. Too bad Bill K is on
> vacation, he'd know).
>
> As far as PACKED-DECIMAL... I'd have to look that up and right now I don't
> feel like doing that. But I believe aligment within a group item is
> generally handled with the optional SYNC[HRONIZED] keyword in the USAGE
> clause.
>
> But let's be practical.. it costs little or nothing to 'check it out' if it
> is of interest, right?
>
> MCM
>
>
>
>
>
>
>
|
|
|
|
|