in reply to Re: Re: Re: Re: Unpack for VMS binary files
in thread Unpack for VMS binary files

Yep, your solution works except the time string (in my case) is 32 bytes. Therefore:
$timelow = substr($record,0,16); $timehigh = substr($record,16,32); &quad_to_epoch("$timelow $timehigh");
However,when I print the $Unix_based_time value with print scalar localtime($Unix_based_time), the output starts at 1st Jan 2003 11:00:00 to 23:59:40 and then 2nd Jan 00:00:00 to 10:59:40! The file should start at 00:00:00 Jan 1st and end at 23:59:40 on the same day... Regards, Stacy.

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Re: Unpack for VMS binary files
by Elian (Parson) on Feb 25, 2003 at 22:26 UTC
    The time string can't be 32 bytes. VMS times are quadwords, 64 bit quantites. (Well, 63 bits, since negative times are deltas, but that's a separate issue) The data record format posted in the original node shows it as an 8 byte quantity and if it's in VMS format already, just snag the first eight bytes from the string an throw it in.

    Regardless, as I said before, the code you've posted is wrong. (Which is a separate issue) You can't just go throwing a space between the two variables, nor can you just throw them together and hope for the best when a sub is going to decode the data, especially if it's binary data.. Won't work. The subroutine as written takes a single 64 bit quantity encoded as a VMS quadword time, so if that isn't what you have, you'll have problems. The code you wrote there definitely won't do it.

    Given the original format, just read in the record and pass it to the subroutine, and it should work fine. If you don't want to do that, then:

    $unix_time = quad_to_epoch(substr($record, 0, 8));
    will.
      Yes you are right, theentire string is 32 bytes. I also solved the problem of why the output was starting at 11:00:00 - I was using localtime instead of gmtime. Thankyou all for your help. Stacy.