Move a PIC X field to a COMP-3 1

[rv0121]

"I have a defined field called Field-Size PIC X(10)in my input record. I want to move that input field to a comp-3(Field-size-comp PIC S9(10) usage comp-3).

Can i do this with a simple move statement? For example:

MOVE Field-Size TO Field-Size-Comp
Write output-rec.

Or is there some kind of conversion I have to do first?
Thanks in advance.

 

[dhecht]

Redefine the PIC X field.

01 FIELDS.
05 FIELD-SIZE-X PIC X(10).
05 FIELD-SIZE-9
REDEFNIES FIELD-SIZE-X
PIC S9(10) COMP-3.


MOVE FIELD-SIZE-9 TO FIELD-SIZE-COMP.

FIELD-SIZE-9 doesn't need to be signed or packed.

 

[Crox]

Hi,

The length of the field-size-9 is different from the field-size-x. It will be 6 bytes long instead of 10. The last 4 bytes are not defined in the redefined definition. Is that what you want?

Regards,

Crox

 

[CliveC]

You may want to protect against non-numeric data. I don't think that there is any need for a redefines.

IF FIELD-SIZE NUMERIC
MOVE FIELD-SIZE TO FIELD-SIZE-COMP
ELSE
DISPLAY FIELD-SIZE " NOT NUMERIC"
STOP RUN
END-IF

 

[RonaldB]

dhecht,

Crox is right; that redefinition definitely is not going to do the trick. --------
Regards,
Ronald.

 

[rv0121]

I guess what I should have phrased my question better know was can I move a PIC field to a usage comp field. What I have is a flat file that comes in and has a field called Str-size-in PIC X(3). I need to convert this field to a small int Srt-size-out PIC S9(4) usage comp. Can i do this with a simple move statement and get what i need or do i have to convert it first then move it. Again sorry for not phrasing my question corrrectly.

 

[dhecht]

Sorry to differ, but the redefintion will work. although the pic s9(10) is stored as 6 bytes, the picture still remains as shown. PIC 9(5) comp is stored internally as 2 bytes, but this does ot mean comp fields are not coded as PiC 9(2) comp.

In regards to the last post, If the 9 display field is moved to a comp field, conversion will occur from display to comp. Also, for efficiency, to put the field on a full-word boundary, code PIC S9(4) comp sync.

 

[Crox]

On the mainframe, the S9(4) COMP is stored as 2 bytes, S9(9) COMP is stored as 4 bytes and S9(18) COMP is stored as 4 bytes. Less digits means same storage allocation between given upper boundaries here.

SYNC means synchronized, so it is stored on full word boundary. A full word is 4 bytes.

I still don't understand the conversion from pic x(3) into s9(4) comp.

By the way, nowadays you can better define COMP-5 using the newer mainframe compiler instead of COMP. For example: it is not affected by wrong settings of TRUNC.

 

[dhecht]

Crox,

01 FIELDS-IN..
05 STR-SIZE-X PIC X(3).
05 STR-SIZE-9 REDEFINES STR-SIZE-X
PIC 9(3).
01 FIELDS-OUT.
05 STR-SIZE-OUT PIC S9(4) COMP. (OR COMP-5 PER YOUR SUGGESTION)

MOVE STR-SIZE-9 TO STR-SIZE-OUT.

This will work and will convert the data.to signed binary. There may be some zero-initialized high order bytes, but that's transparent to the application.

 

[MarcLodge]

rv0102,
So long as the field you are moving from contains no decimal points, you should be ok to redefine the field as pic 9(?) and move it to the comp field, AFTER checking it to be numeric. If it's not numeric, then you need to report it or similar. If it's got a decimal point in it then you need to decide how to process that in your program (valid/invalid) and if necessary remove the decimal point from the pic x field and move to the comp field (suitably formatted).
Marc

 

[slade]

Hi RV,

To clear away some of the confusion, you might want to phrase your ques something like this:

I have a pic x(3) field containing a value, X'F2F6F0". I want to move this to a COMP field retaining the decimal value 260.

This may not be what you have in mind, but phrasing it something like this will give us a better idea of what you're trying to accomplish with the move and also what the sending data looks like and what you want the receiving data to look like.

Thanx, Jack.

 

[RonaldB]

Jack,

right; i made the assumption when backing up Crox that the X(10) field would contain zoned numeric data; also, in dhecht's example, the X(10) and S9(10) COMP-3 suggests that he expects 10 bytes of alphameric data to map onto 6 bytes of packed-decimal data.
Nevertheless, dhecht, your example would leave the rightmost 4 bytes of the X(10) field unused, at least in a mainframe environment.

RV0121,

please state the format of the data in that X(10) field: is it zoned, packed, binary, etc?
--------
Regards,
Ronald.

 

[SamGoody]

Hi,

I have been reading thru this for quite some time..sort of cofused .. can anyone explain zoned..packed and binary in this context and how it would impact the move statement ? How are they different..i am a novice to cobol and would be great to learn ..

Thanks !

 

[StephenJSpiro]

ZONED DECIMAL is essentially display numeric in EBCDIC (an internal representation code similar to ASCII).
PACKED DECIMAL is essentially a numeric field with only the decimal numeric part of each byte stored in the field. Different computers store it in different ways.
If you do not know what is a BINARY NUMBER, you are not yet ready for programming.

Stephen J SPiro
Member, ANSI COBOL Standards Committee

 

[SamGoody]

Hi Steve,

Thanks for letting me know..I agree that it was pretty dumb for me to add binary part to my question....i guess it was one of those off the board things !!

Thanks for all your help..

 

[Guest_imported]

I have field which is defined as S7(9)v9(2) comp-3.
I know that the formula to check the size of the fields is the (numbe of digits + 1 for the sign)/2. In my case it is 5 hence this fileds will hold 8 byte but will use only 5 ?
what about S9(9) comp. How will it be hold ?

 

[Crox]

Hi,

The S7(9)V9(2) COMP-3 will take 5 bytes of storage.

The S9(9) COMP will fit in a full word which is 4 bytes.

Regards,

Crox

ps. This counts for IBM and compatible environments

 

[slade]

Interesting. Will "S7(9)V9(2) COMP-3" produce a compiler error? I would hope so! It should be "S9(7)V9(2) COMP-3". A typo I'm sure.

Jack