convert packed CHAR to unpacked DIGIT

Hi,

Input record has a field of size 5 bytes containing packed numbers. But
this field is defined as CHARACTER.

E.g. WS-A    PIC X(5) '1212343455'

My task is to display '1212343455' on a report. Obviously, it requires
converting packed to unpacked numbers.

I tried doing something like this:

MOVE X(5)        TO 9(9) COMP-3.
REDEFINE 9(9) COMP-3 AS 9(10)

Any suggestions/help..? Thanks.

ssb wrote:
> Hi,
>
> Input record has a field of size 5 bytes containing packed numbers. But
> this field is defined as CHARACTER.
>
> E.g. WS-A    PIC X(5) '1212343455' ? ? ? ? ?
>
> My task is to display '1212343455' on a report. Obviously, "NOT SO OBVIOUS
" it requires
> converting packed to unpacked numbers.
>
> I tried doing something like this:
>
> MOVE X(5)        TO 9(9) COMP-3. "A REALLY BAD MOVE"
> REDEFINE 9(9) COMP-3 AS 9(10) ? ? ? ? ?
>
> Any suggestions/help..? "RTFM"    Thanks.
>

Try something like this:
(IBM mainframe COBOLII or later)

01  ws-a  pic x(5).

01  ws-b.
05  ws-a5 pic x(5).
05  fil   pic x(1) value X'0C'.
01  ws-b-c3   redefines
ws-b      pic s9(11) comp-3.

01  ws-c-9    pic s9(11).
01  ws-c-x    redefines
ws-c-9.
05  ws-c-ans pic x(10).
05  fil      pic x(1).

move ws-a to ws-a5
move ws-b-c3 to ws-c-9
display 'this s/b the ans ==>' ws-c-ans '<=='

All the usual caveats and copouts apply.


ssb wrote:
> Hi,
>
> Input record has a field of size 5 bytes containing packed numbers.
But
> this field is defined as CHARACTER.
>
> E.g. WS-A    PIC X(5) '1212343455'
>
> My task is to display '1212343455' on a report. Obviously, it
requires
> converting packed to unpacked numbers.
>
> I tried doing something like this:
>
> MOVE X(5)        TO 9(9) COMP-3.
> REDEFINE 9(9) COMP-3 AS 9(10)
>
> Any suggestions/help..? Thanks.

ssb wrote:
> Hi,
>
> Input record has a field of size 5 bytes containing packed numbers. But
> this field is defined as CHARACTER.
>
> E.g. WS-A    PIC X(5) '1212343455'
>
> My task is to display '1212343455' on a report. Obviously, it requires
> converting packed to unpacked numbers.
>
> I tried doing something like this:
>
> MOVE X(5)        TO 9(9) COMP-3.
> REDEFINE 9(9) COMP-3 AS 9(10)
>
> Any suggestions/help..? Thanks.

If your compiler supports reference modification and the ORD intrinsic,
you could try stepping through the input field one character at a time,
using ORD to find its binary value, dividing that value by 16, and using
the dividend and remainder respectively to index into a table of
hexadecimal characters (0123456789ABCDEF), and moving the results into
the output record.

Louis

Hi  ssb,

Didn't realize you wanted the ans as PIC 9.  Just change ws-c-ans to
pic 9(10).

Regards, Jack.

> Input record has a field of size 5 bytes containing packed numbers.
> But this field is defined as CHARACTER.

> E.g. WS-A    PIC X(5) '1212343455'

If it is packed decimal then it should be defined as PIC S9(9) PACKED
or COMP-3 or similar.  This will occupy 5 bytes.

Or redfine it as:

03  WS-A       PIC X(5).
03  WS-A-Packed REDEFINES WS-A PIC S9(9) PACKED.

> My task is to display '1212343455' on a report. Obviously, it
requires
> converting packed to unpacked numbers.

MOVE WS-A-Packed TO WS-A-Edited

where WS-A-Edited is defined as PIC -(9)9  or similar.

> I tried doing something like this:

> MOVE X(5)        TO 9(9) COMP-3.
> REDEFINE 9(9) COMP-3 AS 9(10)

A REDEFINE gives a different definition to the _same_ area.  A PIC X(5)
and S9(9) PACKED (or COMP-3) can redefine each other as they are the
same size.  PIC 9(10) is a different size and so won't map over a PIC
X(5).

MOVEing a PICS9(9) PACKED to S9(10) will do the unpacking.

Just to clarify, there is NOTHING in the '85 (or '02)  ANSI/ISO Standard tha
t
says you may NOT store 10 (decimal) digits in a 5-byte (character position)
field - with USAGE Packed-Decimal, i.e.

Pic 9(10) Packed-Decimal

*may* require only 5 "bytes".  In fact, there ARE implementations where this
 is
true.

It is ALSO true that many (possibly MOST) implementations require a nibble
(half-byte) for a "sign place holder" even for fields defined withOUT an "S"
that have USAGE PACKED-DECIMAL.

As the original post did not (I don't think) provide any "clue" as to the
compiler or the operating system,

A) we don't know if 9(10) (requiring 5 or 6) bytes (or even 5 1/2) would be
required for this poster

B) whether (given one posted solution) a X'0C' - or X'C0" or X"F0" or X"0F"
hex-something else would help or be required in order to "treat" the input
information as a "valid" packed field.

***

Note:
For some compilers "COMP-6" is the way to define a packed-decimal field with
NO sign-nibble. YMMV

--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1113689508.106446.257390@g14g2000cwa.googlegroups.com... 
> 
>
> If it is packed decimal then it should be defined as PIC S9(9) PACKED
> or COMP-3 or similar.  This will occupy 5 bytes.
>
> Or redfine it as:
>
>    03  WS-A       PIC X(5).
>    03  WS-A-Packed REDEFINES WS-A PIC S9(9) PACKED.
> 
> requires 
>
>    MOVE WS-A-Packed TO WS-A-Edited
>
> where WS-A-Edited is defined as PIC -(9)9  or similar.
> 
> 
>
> A REDEFINE gives a different definition to the _same_ area.  A PIC X(5)
> and S9(9) PACKED (or COMP-3) can redefine each other as they are the
> same size.  PIC 9(10) is a different size and so won't map over a PIC
> X(5).
>
> MOVEing a PICS9(9) PACKED to S9(10) will do the unpacking.
>

ssb wrote:
> Hi,
>
> Input record has a field of size 5 bytes containing packed numbers.
But
> this field is defined as CHARACTER.
>
> E.g. WS-A    PIC X(5) '1212343455'
>
> My task is to display '1212343455' on a report. Obviously, it
requires
> converting packed to unpacked numbers.
>
> I tried doing something like this:
>
> MOVE X(5)        TO 9(9) COMP-3.
> REDEFINE 9(9) COMP-3 AS 9(10)
>
> Any suggestions/help..? Thanks.

While what the others have said is useful and appropriate, are you sure
that the size of the input field isn't six bytes instead of five?

Usually and not necessarily always, packed-decimal fields have a sign
in the rightmost half-byte, whether or not the field was defined as
signed.  Consequently, there may also be another digit in the leftmost
half-byte of the rightmost byte, if indeed the real field size is six
bytes.

Robert

For those who haven't noticed, my proposed solution was designed for
compilers on:

Quote:
(IBM mainframe COBOLII or later)

While any byte value can be used here to provide the missing sign,
prudence dictated the use of X'0C' in the event the field may need
future manipulation.

A divide by 10 would return the packed field to its orig value.

Robert Jones wrote:
> ssb wrote: 
>
> While what the others have said is useful and appropriate, are you
> sure that the size of the input field isn't six bytes instead of five?
>
> Usually and not necessarily always, packed-decimal fields have a sign
> in the rightmost half-byte, whether or not the field was defined as
> signed.  Consequently, there may also be another digit in the leftmost
> half-byte of the rightmost byte, if indeed the real field size is six
> bytes.

I think the original creator of the file didn't want to lose a half-byte on
no stinkin' sign - that is, this is not a "true" packed number. More like a
home-brew "compressed" number.

I'd do it:

01  FUNNY-NUMBER.
02  FUNNY-ORIGINAL  PIC X(5).
02  Filler X Value X'OC'.
01  REAL-NUMBER REDEFINES FUNNY-NUMBER PIC S9(11) COMP-3.

Move ORIGINAL-NUMBER To FUNNY-ORIGINAL.
Compute REALLY-REAL-NUMBER = REAL-NUMBER / 10.