Unless you show us (a hexdump of) your input data, it will be hard to give you meaningful advice.

I haven't had to deal with BINARY type numbers, but I would assume that they are basically just bytes and don't need any special treatment at all? ord should be enough to convert from a byte to the number?

Thanks so much for the reply! Yes my first time with binary fields, I did not think it would be difficult since I had found great examples with COMP -3 fields on this site but I haven't had much luck with mapping these yet

Here is the hexdump of my input file...fixed length of 34 bytes. Please so let me know if my hexdump is not what you need. I am relatively new to hexdump so this might not be what you want.

hexdump -c -n 34 sltywk_binary_new
0000000 \0 \0 001 257 \a 344 \0 003 \0 \0 \0 s \0 6 002 267
0000010 \0 \0 \0 \0 \0 \0 005 E 035 \0 \0 \0 \0 \0 \0 \0
0000020 \0 \f
0000022

I would guess that your PIC(5) means four or five bytes, at least that matches up somewhat well with your data. If we assume the first four bytes, then unpack 'N', substr $str, 0,4 gives 431:

#!perl
use strict;
use warnings;

my $str = "\0\0\1\o{257}\a\o{344}\0\3\0\0\0s\06\o{002}\o{267}";
my $data1 = unpack "N", substr($str,0,4);
print $data1;
[download]

I don't know how to get from the 431 I get to the 425 you get, but maybe the other numbers give a better clue here?

hexdump -c -n 34 sltywk_binary_new
0000000 \0 \0 001 257 \a 344 \0 003 \0 \0 \0 s \0 6 002 267
[download]

My hexdump-fu probably is a bit rusty, but how would hexdump -c give bytes like 257, 344 or 267?

I prefer hexdump -C anyway...

Or better: which variant of the hexdump-tool is this?

See: https://www.ibm.com/support/knowledgecenter/en/SS6SG3_4.2.0/com.ibm.entcobol.doc_4.2/PGandLR/concepts/cpari09.htm

PACKED-DECIMAL and COMP-3 are synonyms. Packed-decimal items occupy 1 byte of storage for every two decimal digits you code in the PICTURE description, except that the rightmost byte contains only one digit and the sign. This format is most efficient when you code an odd number of digits in the PICTURE description, so that the leftmost byte is fully used. Packed-decimal items are handled as fixed-point numbers for arithmetic purposes.

The digits are stored left-to-right as decimal numbers, two digits per byte. The rightmost nybble is a sign indicator ... unless SIGN IS SEPARATE.

https://www.ibm.com/support/knowledgecenter/en/SS6SG3_4.2.0/com.ibm.entcobol.doc_4.2/PGandLR/ref/rpari25.htm

so it turns out mike is a cobol expert. things make a little more sense now. :eyeroll:

See: https://www.ibm.com/support/knowledgecenter/SS6SG3_5.2.0/com.ibm.cobol52.ent.doc/PGandLR/ref/rlddepic.html

The V symbol used in a PICTURE clause indicates the position of an assumed decimal point. This is not present in the data. So, the value 123.45 with PIC 9(3)V99 might appear as $01020304050C. With a different picture, the identical data could be interpreted as 12345, 1.2345, 12.345 and so on.

BINARY, COMP, and COMP-4 are synonyms. Binary-format numbers occupy 2, 4, or 8 bytes of storage. If the PICTURE clause specifies that an item is signed, the leftmost bit is used as the operational sign.

A binary number with a PICTURE description of four or fewer decimal digits occupies 2 bytes; five to nine decimal digits, 4 bytes; and 10 to 18 decimal digits, 8 bytes. Binary items with nine or more digits require more handling by the compiler.

Full disclosure: "if the picture does not specify that the binary operand is "signed," COBOL will automagically disregard two's complement. (However, not the case here.)