in reply to Perl Unpack Cobol Binary File and Fields

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?

Replies are listed 'Best First'.
Re^2: Perl Unpack Cobol Binary File and Fields
by dbarkho14 (Novice) on May 04, 2020 at 18:08 UTC

    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;

      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?

        Seems like unpack "N" is on the right track but I am supposed to get some records with 425 on them and I did not get any after processing the whole file. FIELD2 is supposed to be the year with 2019 as the value but I am not getting anything close to this. Maybe if you can see how to get 2019 in FIELD2 then all could fall into place. Thanks again for helping. I will keep looking.

      hexdump -c -n 34 sltywk_binary_new 0000000 \0 \0 001 257 \a 344 \0 003 \0 \0 \0 s \0 6 002 267
      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?

        I'm guessing they're octal by some weird default. I was able to make similar output making up a dummy file using that presumption (entering his numbers using hexl-mode in emacs) that produced similar output on OS X with the default /usr/bin/hexdump. I'm partial to od -xa myself.

        $ hexdump -c foo 0000000 \0 \0 001 257 \n 344 \0 003 \0 \0 \0 s \0 006 002 26 +7 0000010 $ od -xa foo 0000000 0000 af01 e40a 0300 0000 7300 0600 b +702 nul nul soh af nl e4 nul etx nul nul nul s nul ack stx +b7 0000020

        Edit: Derp, his \a should of course be 0x07 not \n / 0x0a. I need moar caffeine . . .

        The cake is a lie.
        The cake is a lie.
        The cake is a lie.