Date:         Sun, 2 Oct 2011 13:01:20 -0500
Reply-To:     Joe Matise <snoopy369@GMAIL.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Joe Matise <snoopy369@GMAIL.COM>
Subject:      Re: How to input hex from string
Comments: To: Arthur Tabachneck <art297@rogers.com>
In-Reply-To:  <201110021743.p92ArWal018948@waikiki.cc.uga.edu>
Content-Type: text/plain; charset=ISO-8859-1

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
>>>
>