Re^2: Perl Unpack Cobol Binary File and Fields

in reply to Re: Perl Unpack Cobol Binary File and Fields
in thread Perl Unpack Cobol Binary File and Fields

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

Comment on Re^2: Perl Unpack Cobol Binary File and Fields

Replies are listed 'Best First'.
Re^3: Perl Unpack Cobol Binary File and Fields by Corion (Patriarch) on May 04, 2020 at 18:18 UTC
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?	[reply] [d/l] [select]
Re^4: Perl Unpack Cobol Binary File and Fields by dbarkho14 (Novice) on May 04, 2020 at 20:02 UTC
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.	[reply]
Re^5: Perl Unpack Cobol Binary File and Fields by Corion (Patriarch) on May 04, 2020 at 20:15 UTC
This suggests that every field is just 2 bytes wide and you have two dummy bytes at the start of your record. Because I get 2020 when I look at the next two bytes as a 16-bit word: `my $data1 = unpack 'n', substr( $str, 2,2 ); my $data2 = unpack 'n', substr( $str, 4,2 );` [download] The data itself looks plausible but are you really sure that you are looking at the correct record?	[reply] [d/l]
Re^6: Perl Unpack Cobol Binary File and Fields by dbarkho14 (Novice) on May 04, 2020 at 21:08 UTC
Re^3: Perl Unpack Cobol Binary File and Fields by soonix (Canon) on May 04, 2020 at 18:55 UTC
`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?	[reply] [d/l] [select]
Re^4: Perl Unpack Cobol Binary File and Fields by Fletch (Bishop) on May 04, 2020 at 19:48 UTC
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` [download] 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.	[reply] [d/l] [select]

In Section Seekers of Perl Wisdom