|Just another Perl shrine|
Mysteries of unpack("a", ...)by pspinler (Novice)
|on Jan 03, 2009 at 05:31 UTC||Need Help??|
pspinler has asked for the wisdom of the Perl Monks concerning the following question:
Quick summary: what does unpack ("a4",...) do in comparison to unpack ("L", ...) ?
I have data from a foreign system (IBM z/VM performance history log data) that comes in 1468 byte records, with a mix of EBCDIC encoded characters and numbers in binary format (mostly IBM 390 E format 4 byte floats).
I'm using the following to read records,
my sub decode_record has lots of tidbits like this (multiple calls to unpack() only for my own clarity, until I get this reliably working)
My problem is I'm having problems dealing with those a4 fields I'm unpack()ing, each of them being one of those IBM E format 4 byte floats I mentioned. I'm calling this routine to attempt to parse 'em:
The thing is, I'm getting results like this, which indicates that I don't know what the floop unpack("a4") does. In particular, notice the error messages "isn't numeric" and also the debugging bitstring prints from my bit twiddling, which should result in 7 bits of data, bits 30-25, and and 24 bits of data, bits 23-0. Instead I appear to be getting 7 bits and 8 bits, and they don't appear to match the passed in bitstring in any way.
The 'line 47' in that error message happens to be the first binary operation on the data, '$data & 0x80000000'.
But, if I change unpack ("a4", ...) to unpack ("L"), then I get this, instead:
I'm still doing something wrong here, since my 7bit and 24 bit bitstrings still don't match bits 30-24 and bits 23-0 in the raw data, but suddenly I stop getting the "not numeric" error message and actually see the proper length of bitstrings if not the proper data.
Would some kind soul please enlighten my stumblings?