can be 32767 long

Sorry I missed this. So they are variable lenght? In that case you can user infile option TRUNCOVER or the $VARYING informat.

INFILE B62OLD length=length; input REST $varying32767.;

Both $CHAR and $VARYING preserve leading blanks.

_INFILE_ should be the same for fix or variable lenght records.

On Wed, Mar 26, 2008 at 7:24 PM, data _null_, <datanull@gmail.com> wrote: > Column input left justifies the value of REST. Example. > > data _null_; > input a $1-4 @1 b $char4.; > put a $char4. / b $char4.; > cards; > 1 > 2 > 3 > 4 > ;;;; > run; > data _null_; > input; > put _infile_; > cards; > 1 > 2 > 3 > 4 > ;;;; > run; > > produces on the log.... > > 123 data _null_; > 124 input a $1-4 @1 b $char4.; > 125 put a $char4. / b $char4.; > 126 cards; > > 1 > 1 > 2 > 2 > 3 > 3 > 4 > 4 > > 131 ;;;; > 132 run; > 133 data _null_; > 134 input; > 135 put _infile_; > 136 cards; > > 1 > 2 > 3 > 4 > 141 ;;;; > 142 run; > > > > Two suggestions both "should" yield the same result. > > 1) use $CHAR informat. > INPUT @1 Rest $char32767.; > > 2) use _infile_ variable > input; > Then use the special variable _infile_ where you have been using REST. > > > > On Wed, Mar 26, 2008 at 6:46 PM, Michael Bradley <mjmb05@yahoo.com> wrote: > > In z/OS, I have a file whose records can be 32767 long. I need to sort them on an embedded key which I can locate in various positions in the record, by examining the beginning string of the record. When I find a matching string, I know the location and assign it to the sort key variable - the Customer Reference Number (CRN). I can do this correctly for all records that: > > - don't begin with a blank *and* > > - don't have 2 spaces in the front of the record I'm examining > > but if either occurs, the crn is not located in its expected position (because of shifting, lost data, etc.). This is because SAS trims off the leading space, and considers 2 spaces within the record to be the end of the 32K string. > > > > The obvious question is how can I get SAS to accept the entire record as a variable without it trimming or truncating due to double (or more) blanks? > > > > To illustrate the problem, below are seven sample record fragments; imagine they continue for another 32K. > > 9XXXX XXX. HHHHHHHH-III > > 9XXXX XXX: HHHHHHHH-III > > XXXX HHHHHHHH-III > > XXXXHHHHHHHH-III > > 9XXXX XXX. HHHHHHHH-III > > XXXX HHHHHHHH-III > > XXXX HHHHHHHH-III > > > > > > Here are my SAS statements: > > ================================= > > DATA B62OLD ; > > Blanks = ' '; > > ATTRIB Rest length=$32767 crn length=$13; > > INFILE B62OLD ; > > > > Array TblA (7) $ _TEMPORARY_ > > ... > > INPUT Rest 1-32767; > > > > Do i=1 to dim(TBLA); > > If substr(Rest,1,length(tblA(i))) = tblA(i) then > > ... > > ================================= > > > > This results in improperly locating the key in the third obs because the var, REST will not contain the first character, a blank, thus causing the location of the crn to be 1 byte off. > > > > The sixth obs fails because the var, REST, contains only XXXX; the two spaces cause SAS to lose the rest of the record. > > > > I have tried a few different combinations of list modifiers, but to no avail, and the delimiter route doesn't apply. > > > > Any help would be greatly appreciated. But to frustrate its solution, SAS-L and other groups such as TSO-REXX, IBM-MAIN, etc. are considered by my company to be chat rooms, and is blocked by their email service - so I cannot respond to replies in a timely way. And if that's not enough, I can only work on this at home because all other email vehicles are forbidden. > > > > (I know & you know the chat room moniker is bogus, but they're purely within their rights as to how they want it used, so avoid getting riled and wasting your valuable, talented time even considering such silliness.) > > > > Michael > > > > > > --------------------------------- > > Never miss a thing. Make Yahoo your homepage. > > >