Date: Tue, 9 Mar 1999 23:58:37 +0000
Reply-To: John Whittington <medisci@POWERNET.COM>
Sender: "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>
From: John Whittington <medisci@POWERNET.COM>
Subject: Re: extracting spflog from dataset
Content-Type: text/plain; charset="us-ascii"
At 22:59 09/03/99 +0000, Peter Crawford wrote:
>The bit you may be missing is the effect of FLOWOVER as an option on the
>infile statement.
>This option directs the input pointer to read (or flow onto) the next
>buffer/line/record, when any input statement, fails to find the required
>field or 'text' on the current line.
Indeed. In fact, as others have pointed out to me, 'FLOWOVER' is actually
the default - so your code would work the same without it. It was the
FLOWOVER functionality (whether explicity coded or implied by deafualt) that
I had overlooked.
>If the infile buffer were automatically filled -before- an input, then I
>should not get this error on the first iteration of the data step
I never suggested that the input buffer would be filled _before_ an INPUT
statement - in the absence of an INPUT statement, I wouldn't expect the file
to be read at all. What I said was that I assummed that an INPUT statement
resulted in the input buffer being filled before SAS 'started looking at'
the contents of it.
>The structure for storage of external files is platform dependant.
>On windows (and unix, I believe) simple text files, like my config file,
>don't have the information about maximum lrecl. But that info is
>available from a data control block (DCB) on mvs (& presumeably OS/390).
>The DCB is the useful source for that info, in respect of any sequential
>file - but only on that platform. It is available before data is read.
Fair enough, but my experience is not of MVS.
>Where a dcb is not available, the two pass process can be fairly
>straight forward - but the expense is the additional pass.
>(pass 1 - identify the maximum record length)
>64 data _null_;
>65 infile "&config" length=recl eof = eod;
>66 retain max_len ;
>67 input;
>68 max_len = max( max_len, recl );
>69 return;
>70 eod:
>71 call symput( 'max_rec', put( max_len, 8. ) );
>72 run;
I think you may have missed the point I was making about the potential
problem with this approach. Your example run of the above code worked OK
because the records were all short, shorter than the (default in this case,
since you have not explicitly coded a LRECL= option) LRECL operational for
that INFILE statement. If you recall, I was responding to your comment:
>On this platform win95, LRECL would allow numbers greater than 32k, to
>be defined, but short of two passes through the input, I don't know of a
>foolproof source for the value necessary to guarantee accomodating the
>extracted records. Has anyone the answer ?
As you know, the default LRECL for Windows is 256. Your above code would
therefore fail to give the correct aswer if the maximum record length were
257 or above, let alone 'above 32K'. My point was that the 'first of two
passes' would _still_ require you to hard code a LRECL= value which was
greater than the maximum conceivable record length - so the nearest to a
general solution you could have would be to code LRECL = 1048576 (i.e. the
maximum permitted under Windows) - which you could just as easily have done
in the one-pass approach.
.. as I said before, I think the only truely 'general' solution to
determining maximum record size, regardless of how large it was, would be to
read data one character at a time, count, and look for record delimiter
characters. However, if the purpose was to obtain a value to assign to
LRECL in a subsequent step, that would be a futile exercise, since LRECL
cannot be set (in Windows) to greater than 1048576, even in the highly
unliekly event that the record length did exceed that figure!
Kind Regards
John
----------------------------------------------------------------
Dr John Whittington, Voice: +44 (0) 1296 730225
Mediscience Services Fax: +44 (0) 1296 738893
Twyford Manor, Twyford, E-mail: medisci@powernet.com
Buckingham MK18 4EL, UK mediscience@compuserve.com
----------------------------------------------------------------
