Date:         Sun, 2 Oct 2011 14:44:30 -0400
Reply-To:     Arthur Tabachneck <art297@ROGERS.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Arthur Tabachneck <art297@ROGERS.COM>
Subject:      Re: How to input hex from string
Comments: To: Joe Matise <snoopy369@GMAIL.COM>

For the example I showed, leaving of the denominator, I get: -5819 rather
than the correct 23238.  The only thing that should vary on any jpg that
contains gps info is whether the numbers are big or little endian.

Interestingly, the method works correctly for all 1-digit numbers and for
e803 or 1000.

Art
-----
On Sun, 2 Oct 2011 13:01:20 -0500, Joe Matise <snoopy369@GMAIL.COM> wrote:

>What do you get when you run your code?  I get values like that from
>my jpegs (not that exactly but I assume that varies).
>
>-Joe
>
>On Sun, Oct 2, 2011 at 12:43 PM, Arthur Tabachneck <art297@rogers.com>
wrote:
>> Joe,
>>
>> Yes, IBR2. is probably long enough.  The following shows the kind of
numbers
>> I am trying to read.  I know how to do it this way, but not getting the
info
>> from the substr function:
>>
>> data test;
>>  latsec=input("c65a"x,ibr2.);
>>  output;
>> run;
>>
>> That will correctly get the value 23238.
>>
>> Art
>> -------
>> On Sun, 2 Oct 2011 12:14:53 -0500, Joe Matise <snoopy369@GMAIL.COM>
wrote:
>>
>>>First, why are you specifying IBR8.?  I think IBR2. is actually
>>>correct (though 8. probably doesn't hurt anything).
>>>
>>>Second, are you sure the characters are correctly being grabbed?  What
>>>happens with IBR informat (if I understand correctly) is that it takes
>>>the underlying representation of the character (so for 'A' it would be
>>>'41'x or 01000001) and converts it to little endian number.  That
>>>conversion should be easily defined and doable by hand.  I get 65 for
>>>'A' or '41'x, which seems the same as if I use IB. (which if I
>>>understand correctly uses big endian), so not sure where/when they
>>>should be different.  At this point we go off the page of what I know
>>>unfortunately, so if it's getting the correct characters but not
>>>translating it correctly you'll have to wait for one of our mainframe
>>>gurus :)
>>>
>>>-Joe
>>>
>>>On Sun, Oct 2, 2011 at 11:53 AM, Arthur Tabachneck <art297@rogers.com>
>> wrote:
>>>> I must have been sleeping in class when this topic was covered.  I have
a
>>>> set of jpg files that I'm using a regular expression to find the
starting
>>>> location of a particular field.  Everything works perfectly and I am
able
>> to
>>>> get the desired field.
>>>>
>>>> However, since it is an integer represented as hex with little endian
>>>> representation, I also need to use the ibr informat.  The following
>> doesn't
>>>> work correctly:
>>>>
>>>> %let path=c:\art\;
>>>> filename indata pipe "dir &path.*.jpg /b";
>>>> data want (keep=fname lat: lon:);
>>>>  length fil2read fname $80;
>>>>  retain dt_pattern_num  gps_pattern_num;
>>>>  infile indata truncover;
>>>>  if _n_ = 1 then do;
>>>>    gps_pattern_num =PRXPARSE("/\x02\x02\x00\x00/");
>>>>  end;
>>>>  informat f2r $50.;
>>>>  input f2r;
>>>>  fil2read="&path."||f2r;
>>>>  done=0;
>>>>  infile dummy filevar=fil2read RECFM=N lrecl=12000
>>>>    end=done;
>>>>  fname=fil2read;
>>>>  do while(not done);
>>>>    input VAR1 $char12000.;
>>>>    POSITIONL = PRXMATCH(GPS_PATTERN_NUM,var1);
>>>>    latdiv=input(substr(var1,positionL+244,2),ibr8.);
>>>>    latsec=input(substr(var1,positionL+240,2),ibr8.)/latdiv;
>>>>    output;
>>>>    done=1;
>>>>  end;
>>>> run;
>>>>
>>>> Thus, my question is with respect to creating latdiv and latsec, how
does
>>>> one tell sas that the text being captured with the substr function
>>>> represents hex characters?
>>>>
>>>> Thanks in advance,
>>>> Art
>>>>
>>