Date: Mon, 30 Apr 2007 03:56:04 -0400
Reply-To: Peter Crawford <peter.crawford@BLUEYONDER.CO.UK>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Peter Crawford <peter.crawford@BLUEYONDER.CO.UK>
Subject: Re: Checking if macro exists? (Was Re: Macro Quoting)
Hi Robert
thank you for explaining the context of this problem
so, clearly the fileVar= (in)file options do not adequately
allow you to identify the current (in)file source and change it
to what you need!
You seem to be using the KSDS method for data access in the way
others use sas data sets (or RDBMS tables). Clearly SAS software
does not provide equivalent handling for "external files" and
"data sets".
Your promlem is caused in this "external file" context, because
a data step supports only one concurrent source/destination for
external files, and you need to swap to and from other sources.
In the "datawarehousing" style at SI solutions-thinking
demonstrated by proc infomap, I guess their approach might be
to replace each of your inputs with a pre-loaded table (or more
intelligently, a data step view). They would then be able to
use sql multi-table joins, or a data step with multiple set
statements.
I guess that would not be able to replicate what you need.
If I understand your underlying requirements within the existing
features of SAS software, it seems to be the equivalent of
FILEVAR= support extended to support more features of the KSDS
access and/or other (in)file engine features.
Clearly KSDS sophistication exceeds the "single channel" design
model in datastep (in)file handling.
Can we get SAS to treat the sophistication of KSDS access more
like the SAS/Access to RDBMS products?
If there already exists a SAS product SAS/Access to KSDSdata
it seems unlikely they would develop solutions to provide ways
to workaround their own product. However, if the product does
not exist, and there are enough potential customers, it might be
a product SAS Institute could create and licence.
suggest@sas.com provides one channel for such proposals, as for
your original objective .
Another thought:
Although I have no experience of using these, were you aware of
the SAS8+ feature of named (in)file buffers. Through these, you
could have the _infile_ buffers avaliable, at the same time, for
more than one file. I guess that also applies to the _file_
buffer.
The old single-channel design model continues, but your code
could read from or write to, all the buffers.
Good Luck
Peter
On Mon, 30 Apr 2007 09:01:30 +0200, Robert Bardos <bardos2@ANSYS.CH> wrote:
>Peter,
>
>o.k. so let me first talk about the situation where I really,
>really miss what I described earlier on: something similar to
>
> getoptions(linesize)
> options linesize=<modified value)
> some SAS code
> options linesize=<old value>
>
>in the context of PUT/INPUT statements, ie. being able to safely
>direct away from the current destination to a destination which is
>just used to put/obtain a snap of additional information, then
>redirect to the original destination and things are fine.
>
> gettarget('INPUT')
> infile other_destination
> input
> settarget('INPUT',original_destination)
>
>(May I add at this point that I am not interested in any
>workaround solutions. Really. I do know them and even in the
>example that I'm describing I have some sort of a kludge. But it
>doesn't make me happy since it's just that: a kludge, a
>workaround.)
>
>The piece of code I'm talking about here is nowhere near an infile
>statement. It is a %included piece of code that just happens to be
>executed prior to an output statement.
>The whole datastep with all macros (old and new style macros) and
>%includes expanded generates thousands and thousands of lines of
>code.
>
>Here the infile statement (that I can not and *do not want* to
>modify) is not constantly pointing to the same file but to a
>series of different filenames instead. This series of filenames
>can change from execution to execution. They are however all
>processed in sequence in a single datastep. This datastep creates
>a lot of variables and just prior to outputting them to the SAS
>dataset I'm being given control by means of an %include statement.
>In the source file being included there is neither an infile/input
>nor file/put nor output statement. It's just a plain piece of
>logic where I can add code to manipulate the data read so far.
>This point is usually used for either calculating new variables
>based on combinations of other variables or to enrich the data by
>adding information from other sources. Now this "from other
>sources" is my point of interest. The most often used source is
>custom built formats. Formats that are built from other sources.
>Which means, the information is redundant both in the format and
>in the source that was used to build the format. One of SAS's
>strengths however is the richness of data sources it makes easily
>available to the programmer. So when one of the additional sources
>that is to provide additional information to the observation just
>being composed is accessable by means of infile/input logic (as is
>the case with a VSAM KSDS dataset) I want to be able to use that.
>Without any ifs and whens.
>
>I do think that your answer (and a lot of the answers I had been
>given in similar context) do exactly reflect the dilemma: what I
>want to do can be achieved if ... or if ... or if ... ("if
>file/infile option xyz has been used" "if programming standards
>are being followed" "if you have access to the code" "if you pass
>the name by means of macro parameters/variables").
>
>Would there be a reliable independent way of directing away and
>redirecting to file/infile destinations then none of these ifs and
>whens would need to be observed. I could 'just do it' (tm).
>
>BTW: look at the PUTLOG statement. One of the drivers to have it
>was certainly to releave the programmers of constant 'file log;
>put <log message>; file <orig.filename>;' constructs. All I want
>is to be able to determine <orig.filename> by means of a SAS
>function. Remember: *SAS does know this information*. So it would
>be 'peanuts' to externalize it. Everybody would be free to use it
>or not. Those who want to stick to solutions that depend on the
>use of features/conventions could do so happily. But those who
>want a rock solid solution would finally have one.
>
>
>Thanks for the passion, guys, defending the status quo =8)
>
>(This passion being one of the most valued assets of SAS-L)
>
>Robert
>
>
>
>> -----Urspr?he Nachricht-----
>> Peter Crawford
>> Gesendet: Sonntag, 29. April 2007 23:53
>>
>>
>> Hi Robert
>>
>> when adding syntax near an infile statement, I think we
>> should have everything we need, in that context.
>>
>> Are there attributes from a filename statement that are
>> not available to you in the datastep iteration? In a
>> blind macro (one which is not in control of the (in)file
>> information, you could be passed all the information you
>> need, as required parameters of your macro.
>>
>> In your pseudo function you may have a sufficient level
>> of "store" and "retrieve" with resolve(), %sysget() and
>> call symput().
>> I distinguish between data level information and step
>> level information. For data level information which
>> operates at "observation/iteration" level, I expect to
>> use functions. For step level information (declarative
>> statements like retains, attribs and (in)files) I would
>> expect the (compile-time) macro interface to be
>> sufficient ~ unless you have a need to frequently alter
>> the (in)file options like dlm= or filevar=. Since the
>> program author is in control of these I see no need to
>> retrieve these from new sas software features.
>>
>> Are you able to be provide a more specific example to
>> contradict me? I would be very happy to learn
>> what I'm missing here.
>>
>> Peter C
>>
>>
>> On Sun, 29 Apr 2007 15:33:06 +0200, Robert Bardos
>> wrote:
>>
>> >Peter,
>> >
> ---- irrelevant part snipped / rb ----
>> >
>> > I'm honestly surprised. In my opinion being able to
>> > insert at any point in a datastep a sequence of
>> > statements like
>> >
>> > target = gettarget('INPUT');
>> > infile ksds key=...;
>> > input ... ;
>> > rc = settarget('INPUT',target);
>> > input ... ;
>> >
>> > is not at a matter of 'high sophistication'.
>> >
>> > Having the choice between ...
>> >
>> > a) a technique which is supported by the bare bone's language
>> >
>> > ... and ...
>> >
>> > b) having to rely on programming standards or as I would put
>it
>> > "having to depend on other's adherence to programming
>> > standards"
>> >
>> > ... I'll clearly favour the independent and technically robust
>> > solution.
>> >
>> > But somehow I get the impression: that's just me. ;-)
>> >
>> >
>> >Kind regards
>> >Robert
| 
