data stored in an odd format - question 
Author Message
 data stored in an odd format - question


Quote:

>I'm having a problem figuring out how to move 10 bytes of data that has
>been packed into 5 bytes but was not stored as packed-decimal or binary.
>Let me explain my problem and I hope someone has a solution for me.

>This data is a 10 byte customer key. It was put into a 5 byte field
>similarly to packing it but there is no sign. It's like this:00014
>                                                00290
>What I want to do is extract the number into a 10-byte field so I can use
>the whole customer number as a key to search another field. That is I want
>the number to look like 0000021940 when I get done with it.

how about:

i-o section.
*data in
01 data-in pic 9(10).

working-storage section.
01 data-second-first pic 9(5).
01 counter pic 9(1).
01 dummy pic 9(10).
01 val-out pic 9(1).
01 add-to-val-out pic 9(1).
01 temp pic9(11).
01 temp2 pic 9(1).
01 tempout pic 9(10).

then you perform until the file is ended
read data-in.
move data-in to temp.
multiply temp by 10.
move 0 to temp-out.
move 0 to data-second-first.
        perform p-char varying counter from 1 to 10 by 1
write temp-out.
exit program.
stop run.

p-char.
move data-in to temp.
if counter >5
add 1 to val-out
end-if
divide counter by 5 giving dummy remainder add-to-val-out
add add-to-val-out to val-out.
perform divide temp by 10 val-out times.
divide temp by 10 giving temp remainder temp2.
multiply temp-out by 10.
add temp2 to tempout.

send the check in the mail, hehe.



Tue, 21 Mar 2000 03:00:00 GMT  
 data stored in an odd format - question



Quote:

> This data is a 10 byte customer key.  It was put into a 5 byte field
> similarly to packing it but there is no sign.  It's like this:

> 00014
> 00290

> What I want to do is extract the number into a 10-byte field so I can
> use the whole customer number as a key to search another field.  That
> is I want the number to look like 0000021940 when I get done with it.

05  WS-TMP-PACKED      PIC 9(11) COMP-3 VALUE ZERO.
05  FILLER  REDEFINES  WS-TMP-PACKED.
    10  WS-KEY-PACKED  PIC X(05).
    10  FILLER         PIC X(01).

05  WS-TMP             PIC 9(11).
05  FILLER  REDEFINES  WS-TMP.
    10  WS-KEY         PIC 9(10).
    10  FILLER         PIC X(01).

MOVE input TO WS-KEY-PACKED.
MOVE WS-TMP-PACKED TO WS-TMP.

You can then use WS-KEY.

Note: Technically, the VALUE clause is superfluous, and therefore on IBM
mainframes you can eliminate the first MOVE by redefining the packed key
right in the record.

However, some manufacturers, including, surprisingly enough, IBM, did not
correctly translate packed decimal to ASCII, and on those machines, such
as the IBM RS/6000 and the DEC VAX, you must supply a valid low-order
byte.

Quote:
> If someone has a solution for me to try please email me as I don't read
> the whole list too often.

Ask here, get here.

--
Christopher Westbury, Midtown Associates, 15 Fallon Place, Cambridge, MA 02138



Tue, 21 Mar 2000 03:00:00 GMT  
 data stored in an odd format - question

I'm having a problem figuring out how to move 10 bytes of data that has
been packed into 5 bytes but was not stored as packed-decimal or binary.
Let me explain my problem and I hope someone has a solution for me.

This data is a 10 byte customer key. It was put into a 5 byte field
similarly to packing it but there is no sign. It's like this:00014
                                                00290

What I want to do is extract the number into a 10-byte field so I can use
the whole customer number as a key to search another field. That is I want
the number to look like 0000021940 when I get done with it.

This was put into the file this way by assembler code if that helps any.

Someone suggested trying to tag a character A on the end of the number and
then shift everything to the right 1 to drop the 1 and just leave the C
part of the A character but I can't figure out how to do that either.

If someone has a solution for me to try please email me as I don't read

Thanks in advance.

Melinda

--
Melinda Belleville
University of Kentucky        In memory of John Jerome Garcia
210 Mcvey Hall                  Aug. 1, 1942 - Aug. 9, 1995
Lexington, Ky  40506          "Fare thee well, fare thee well"



Tue, 21 Mar 2000 03:00:00 GMT  
 data stored in an odd format - question


Quote:
>I'm having a problem figuring out how to move 10 bytes of data that has
>been packed into 5 bytes but was not stored as packed-decimal or binary.
>Let me explain my problem and I hope someone has a solution for me.

>This data is a 10 byte customer key. It was put into a 5 byte field
>similarly to packing it but there is no sign. It's like this:00014
>                                                00290

>What I want to do is extract the number into a 10-byte field so I can use
>the whole customer number as a key to search another field. That is I want
>the number to look like 0000021940 when I get done with it.
snip

>Thanks in advance.

>Melinda

>--
>Melinda Belleville
>University of Kentucky        In memory of John Jerome Garcia
>210 Mcvey Hall                  Aug. 1, 1942 - Aug. 9, 1995
>Lexington, Ky  40506          "Fare thee well, fare thee well"


Ok......

01 nice-number pic s9(10)v9 comp-3.
01 filler redefines nice-number.
   05 bad-number pic x(5).
   05 filler     pic s9 comp-3 value +0.
01 your-good-number
    pic [s9(10 ... or 11  or whatever]   [comp-3 or whatever]
move your-stuff to bad-number  move nice-number to your-good-number.

the nice number  is scaled at one decimal to make life simple to
extract the real number you want.

JR

and stir with a Runcible spoon...



Tue, 21 Mar 2000 03:00:00 GMT  
 data stored in an odd format - question

Quote:

> I'm having a problem figuring out how to move 10 bytes of data that
> has
> been packed into 5 bytes but was not stored as packed-decimal or
> binary.
> Let me explain my problem and I hope someone has a solution for me.

> This data is a 10 byte customer key. It was put into a 5 byte field
> similarly to packing it but there is no sign. It's like this:00014
>                                                 00290

> What I want to do is extract the number into a 10-byte field so I can
> use
> the whole customer number as a key to search another field. That is I
> want
> the number to look like 0000021940 when I get done with it.

> This was put into the file this way by assembler code if that helps
> any.

> Someone suggested trying to tag a character A on the end of the number
> and
> then shift everything to the right 1 to drop the 1 and just leave the
> C
> part of the A character but I can't figure out how to do that either.

> If someone has a solution for me to try please email me as I don't
> read

> Thanks in advance.

> Melinda

> --
> Melinda Belleville
> University of Kentucky        In memory of John Jerome Garcia
> 210 Mcvey Hall                  Aug. 1, 1942 - Aug. 9, 1995
> Lexington, Ky  40506          "Fare thee well, fare thee well"


   Is this from an IBM shop? If so, perhaps the programmer chopped of
the low order byte. If the field
   was signed a C or a D should be in low order; if unsigned, an F would
be in the low order byte.
   In an IBM shop, a 10 byte field would pack into 6 bytes.

   Other compilers have their own way.

   Richard Jackson
   Houston, Tx



Tue, 21 Mar 2000 03:00:00 GMT  
 data stored in an odd format - question



Quote:
> I'm having a problem figuring out how to move 10 bytes of data that has
> been packed into 5 bytes but was not stored as packed-decimal or binary.
> Let me explain my problem and I hope someone has a solution for me.

> This data is a 10 byte customer key. It was put into a 5 byte field
> similarly to packing it but there is no sign. It's like this:00014
>                                                 00290

> What I want to do is extract the number into a 10-byte field so I can use
> the whole customer number as a key to search another field. That is I
want
> the number to look like 0000021940 when I get done with it.

> This was put into the file this way by assembler code if that helps any.

> Someone suggested trying to tag a character A on the end of the number
and
> then shift everything to the right 1 to drop the 1 and just leave the C
> part of the A character but I can't figure out how to do that either.

I'm sorry, but you post is not very clear as to exactly how you want to
manipulate the numbers.  I assume they are numeric?  Could you give four or
five examples like this:

WHAT I GOT    WHAT I WANT
0000000000    00000000000000000000
0000000000    00000000000000000000
0000000000    00000000000000000000
0000000000    00000000000000000000
0000000000    00000000000000000000

That would REALLY help!
--
Judson McClendon          This is a faithful saying and worthy of all
Sun Valley Systems        acceptance, that Christ Jesus came into the

(please remove zzz from email id to respond)



Tue, 21 Mar 2000 03:00:00 GMT  
 data stored in an odd format - question

I've seen the format you are talking about on older systems, but usually it
was used to place a data (e.g. mmddyy) into three bytes.  I've been told
that it was called stripped decimal, or stripped packed, and was common on
a line of IBM compatible products from Univac called OS/3.  I cannot verify
this, having never had the pleasure of working on one...

In any case, the suggestion of putting an A character on the end is usable,
as well as about 19 other potential characters.  Our routine for converting
these would go

WORKING-STORAGE SECTION.
01      STRIPPED-VARIABLE               PIC X(5).
01      CONVERSION-INPUT.
        05      INPUT-VARIABLE  PIC X(05).
        05      INPUT-FILL              PIC X(01).
01      CONVERSION-NUMERIC REDEFINES CONVERSION-INPUT
                                        PIC 9(11) COMP-3.
*       NOTE, THE ABOVE VARIABLE IS UNSIGNED
01      CONVERSON-OUTPUT                PIC 9(10).
PROCEDURE DIVISION.
        MOVE STRIPPED-VARIABLE TO INPUT-VARIABLE.
        MOVE ZEROS TO INPUT-FILL.
        DIVIDE CONVERSION-NUMERIC BY 10 GIVING CONVERSION-OUTPUT.

Now, I realize that some other posters have had routines which did not rely
on using a comparatively expensive divide, and did not reinitialize the tag
on the end for each variable converted.  This is just the way we did it,
and it worked.
--
"There's a big difference between mostly dead, and all dead.  Please, open
his mouth."
    Miracle Max, "The Princess Bride"



Quote:
> I'm having a problem figuring out how to move 10 bytes of data that has
> been packed into 5 bytes but was not stored as packed-decimal or binary.
> Let me explain my problem and I hope someone has a solution for me.

> This data is a 10 byte customer key. It was put into a 5 byte field
> similarly to packing it but there is no sign. It's like this:00014
>                                                 00290

------------------ snip -------------------


Wed, 22 Mar 2000 03:00:00 GMT  
 data stored in an odd format - question


Quote:

> 01 nice-number pic s9(10)v9 comp-3.
> 01 filler redefines nice-number.
>    05 bad-number pic x(5).
>    05 filler     pic s9 comp-3 value +0.

The VALUE clause can not be used in a data description entry that has
a REDEFINES clause or is subordinate to a data description entry with a
REDEFINES clause.

What compiler did you use to compile this ??

Quote:
> 01 your-good-number
>    pic [s9(10 ... or 11  or whatever]   [comp-3 or whatever]

Actually, it does make a difference what you put here.

    01 your-good-number pic s9(11) comp-3.

is an answer to the original poster's second question, which is
essentially how to get a shift and round packed.  However, the original
poster's first question specified ten bytes unpacked:

    01 your-good-number pic 9(10).

In this case, there's no sense in using a shift and round packed and then
unpacking when you can just unpack.  Conversely, had the original poster
specified six bytes packed, there would be no sense in unpacking only to
repack.

The great benefit of UNPK is that it does not require valid decimal data
since it is not a decimal instruction like SRP.  Therefore, you can
unpack directly from the buffer without moving to WORKING-STORAGE first.

--
Christopher Westbury, Midtown Associates, 15 Fallon Place, Cambridge, MA 02138



Wed, 22 Mar 2000 03:00:00 GMT  
 data stored in an odd format - question


Quote:



> > This data is a 10 byte customer key.  It was put into a 5 byte field

                                                            ^^^^^^

Quote:
> > similarly to packing it but there is no sign.  It's like this:
> > 00014
> > 00290

> > What I want to do is extract the number into a 10-byte field so I can
> > use the whole customer number as a key to search another field.  That
> > is I want the number to look like 0000021940 when I get done with it.

> how about:

> i-o section.

??

Quote:
> *data in
> 01 data-in pic 9(10).

You have missed the point.

As the original poster clearly stated, the input is a 5-byte field.

In the two-row hexadecimal format, the zone is displayed in the upper row
and the numeric is displayed in the lower row:

    00014
    00290

This is just a more convenient way of displaying X'0000021940'.

The question is how to get "0000021940" from X'0000021940'.

[...]

Quote:
> send the check in the mail, hehe.

It is you who should send a check to the original poster, hehe.

Code that obviously won't even compile, much less solve the problem, has
negative worth.

--
Christopher Westbury, Midtown Associates, 15 Fallon Place, Cambridge, MA 02138



Wed, 22 Mar 2000 03:00:00 GMT  
 data stored in an odd format - question

Quote:

> I'm having a problem figuring out how to move 10 bytes of data that has
> been packed into 5 bytes but was not stored as packed-decimal or binary.
> Let me explain my problem and I hope someone has a solution for me.

> This data is a 10 byte customer key. It was put into a 5 byte field
> similarly to packing it but there is no sign. It's like this:00014
> ,                                                            00290

> What I want to do is extract the number into a 10-byte field so I can use
> the whole customer number as a key to search another field. That is I want
> the number to look like 0000021940 when I get done with it.

> This was put into the file this way by assembler code if that helps any.

Ah, yes, asm370 coders and their danged access to "PACK"/"MVO
 [Pack]/[Move with Offset] combo's !
Pack changes to packed-decimal, of course, and MVO will shift the
field by one packed-decimal digit, left if memory serves, so the
destination field will lack a lower-nibble sign.

What you could do is this:

move the x(5) field to a redefined area of:

05 wk-data-in.
   10 wk-data-in-1        pic x(5) value low-values.    
   10 wk-data-packed-sign pic x    value low-values.
05 wk-data-out  redefines wk-data-in pic s9(11) comp-3.

In the procedure division, write the following:

Move <your packed field as an alphanumeric> to wk-data-in-1.
move x'0f'                                  to wk-data-packed-sign.
* if you're not using Cobol II, then you'll need to do some comp/redef
*    or use special names to get the hex lit
compute <your target field> = wk-data-out / 10.

Next, week, decrypting passwords, using Cobol... :)
==========================
Mike
consultant/contractor [employed]



Thu, 23 Mar 2000 03:00:00 GMT  
 data stored in an odd format - question


Quote:

>As the original poster clearly stated, the input is a 5-byte field.
>In the two-row hexadecimal format, the zone is displayed in the upper row
>and the numeric is displayed in the lower row:
>    00014
>    00290
>This is just a more convenient way of displaying X'0000021940'.
>The question is how to get "0000021940" from X'0000021940'.

ok, use the same program except instead of reading one byte at a time,
read 16 bits, and change the pic size to 5.

but you did seem to miss something. it's not going from 0x21940 to
21940, it's going from 0x29 and 0x14 to something (ie, the bits for
some reason are switched)

since the program which did this conversion in the first place was
assembler, i can guess that it is a big file, so the conversion
program shouldn't be done more than once... unless you have an
excellent compiler.

by the way, does cobol have implicit type casting from hex format to
normal pic 9 format?



Thu, 23 Mar 2000 03:00:00 GMT  
 data stored in an odd format - question

Putting an "A" on the end of a packed-decimal number in most
IBM-compatible
compilers will get you a nice S0C7.  Here's why:

X"0021974083"  is a 5-byte field
x"0021974083C1" is a 6-byte field, but it is not a valid packed-decimal
                   field because your sign nibble is in the wrong place.

IBM packs "F1F2F3F4F5C1" "12345A" into x"0123451c"  [note, it takes 4
        bytes because the field converted is Pic s9(6) not pic s9(5) ]

Quote:

> I've seen the format you are talking about on older systems, but usually it
> was used to place a data (e.g. mmddyy) into three bytes.  I've been told
> that it was called stripped decimal, or stripped packed, and was common on
> a line of IBM compatible products from Univac called OS/3.  I cannot verify
> this, having never had the pleasure of working on one...

> In any case, the suggestion of putting an A character on the end is usable,
> as well as about 19 other potential characters.  Our routine for converting
> these would go



Thu, 23 Mar 2000 03:00:00 GMT  
 data stored in an odd format - question


Quote:

> Putting an "A" on the end of a packed-decimal number in most
> IBM-compatible compilers will get you a nice S0C7.  Here's why:

> X"0021974083"   is a 5-byte field
> X"0021974083C1" is a 6-byte field, but it is not a valid packed-decimal
>                 field because your sign nibble is in the wrong place.

This is true.  However, no one suggested putting the "A" on the end of a
packed-decimal number.

The suggestion was to put the "A" on the end of a zoned-decimal number.
In other words, it is a way to pack the five-byte field, not a way to
unpack it:

     F0 F0 F0 F0 F0 F2 F1 F9 F4 F0 C1

packs to

     00 00 02 19 40 1C

and you can then take the first five bytes and ignore the sixth byte.

I know it _looked_ like someone had suggested appending an "A" to a
packed-decimal field, but that's only because Usenet is like a game of
"telephone" played by 4-year-olds with attention-deficit disorder.

PS. There is a difference between packed data and packed-decimal data.
X"0021974083C1" will _not_ cause a decimal data exception unless you use
a decimal instruction on it.  Neither PACK nor UNPK is a decimal
instruction.  On an IBM-compatible machine you can pack the ten-byte
zoned-decimal number regardless of the byte that follows, as long as
there is one, and conversely you can unpack the five-byte field
regardless of the byte that follows, as long as there is one.  The "A" or
its equivalent is needed only if you want to do decimal arithmetic on the
intermediate field.

--
Christopher Westbury, Midtown Associates, 15 Fallon Place, Cambridge, MA 02138



Thu, 23 Mar 2000 03:00:00 GMT  
 data stored in an odd format - question


Quote:

> 05 wk-data-in.
>    10 wk-data-in-1        pic x(5) value low-values.
>    10 wk-data-packed-sign pic x    value low-values.

Note that you can eliminate the repeated run-time move to
wk-data-packed-sign by setting the low-order byte at compile time:

     10 filler              pic 9 comp-3 value zero.

Quote:
> 05 wk-data-out  redefines wk-data-in pic s9(11) comp-3.

Note that this must be pic 9(11) or the compiler will emit an extra OI.

Quote:
> Move <your packed field as an alphanumeric> to wk-data-in-1.
[...]
> compute <your target field> = wk-data-out / 10.

In CoBOL, if you want to shift right by, say, 8 bits, there's no way to
do it except to divide by 256.  In e.g. C, you never have to multiply or
divide by a power of two because binary shift operations are part of the
language.

Conversely, in C, there is no way to shift right one decimal place except
to divide by 10.  However, the CoBOL language was designed from the
beginning with built-in decimal shifts, so you never have to multiply or
divide by any power of ten.

The original poster was looking for a ten-byte unpacked output, which can
be done without dividing by ten like this:

    05 wk-data-unpack       pic 9(11).
    05 filler     redefines wk-data-unpack.
       10 your-target-field pic 9(10).
       10 filler            pic x.

    Move wk-data-out to wk-data-unpack.

A six-byte packed output can be obtained without dividing by ten like
this:

    05 wk-data-out  redefines wk-data-in pic s9(10)v9 comp-3.
    05 your-target-field                 pic s9(10)   comp-3.

    Move wk-data-out to your-target-field.

--
Christopher Westbury, Midtown Associates, 15 Fallon Place, Cambridge, MA 02138



Thu, 23 Mar 2000 03:00:00 GMT  
 data stored in an odd format - question

Quote:



> >As the original poster clearly stated, the input is a 5-byte field.

> >In the two-row hexadecimal format, the zone is displayed in the upper row
> >and the numeric is displayed in the lower row:

> >    00014
> >    00290

> >This is just a more convenient way of displaying X'0000021940'.

> >The question is how to get "0000021940" from X'0000021940'.

> ok, use the same program except instead of reading one byte at a time,
> read 16 bits, and change the pic size to 5.

> but you did seem to miss something. it's not going from 0x21940 to
> 21940, it's going from 0x29 and 0x14 to something (ie, the bits for
> some reason are switched)

> since the program which did this conversion in the first place was
> assembler, i can guess that it is a big file, so the conversion
> program shouldn't be done more than once... unless you have an
> excellent compiler.

> by the way, does cobol have implicit type casting from hex format to
> normal pic 9 format?

Well, I've proved that I am not sufficiently conversant in C/C++ to be
sure that I understand type casting, but I believe the answer to your
question is a qualified yes.

In COBOL, anytime you MOVE one elementary numeric data item to another
elementary numeric data item, a conversion to the target numeric format
will occur automagically.  This is easy to do because the compiler knows
the formats at compile time.  If the source field contains non-numeric
data, you will get a program check on the IBM mainframe compilers.

If you're doing something {*filter*}, like moving a floating point number to
a display usage number, you can lose data due to truncation (high-order
or low-order), but the target field will be in the correct numeric
format.

I hope that helps.

Arnold Trembley
Software Engineer I (just a job title, still a programmer)
MasterCard International
St. Louis, Missouri



Thu, 23 Mar 2000 03:00:00 GMT  
 
 [ 32 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. to store data in excel format using write to spreadsheet file

2. newbie question: temporarily store data

3. PUT DATA format question

4. data validation and data format

5. data validation and data format

6. Storable file format for a Store Browser

7. Storing a sprase matrix in CSC format

8. Using xpm format to store color images in your tk source files

9. A Date-Time format stored as Days

10. Reading data from a text file to store in a collection

11. Storing REAL data types

12. retrieving stored data

 

 
Powered by phpBB® Forum Software