About DonH

DonH · ‎08-16-2020

Interesting. I wonder when that changed. I know that, as this blog post says, https://blogs.sas.com/content/sgf/2017/08/02/call-execute-for-sas-data-driven-programming/, that call execute had a timing issue and always used the values set for the macro variables on the last execution of the data step. Looks like SAS enhanced call execute to resolve the values at execution time (something like an implied call to the RESOLVE function).

DonH · ‎08-16-2020

And if the code you want to use is relatively static you can save it in a file (including the macro variable references) and use the dosub routine instead. The difference between them is: dosubl expects as its argument a single character string which is the lines of code you want to execute. dosub expects as its argument a character string whose value is the fileref that points to the code to be executed. Here is that code: filename code 'C:\temp\LetStmtAlternative.sas'; data _null_; input file $ var $ type $; array _char(*) _character_; do i = 1 to dim(_char); call symputx(vname(_char(i)),_char(i)); end; rc = dosub('code'); cards; file1 model Sedan file2 model SUV file3 model Wagon file4 model Truck run; And here is the contents of the file pointed to by the filename statement: options nodate pageno=1 linesize=80 pagesize=30 obs=10; ODS RTF file="C:/temp/&file..rtf"; PROC PRINT DATA=SASHELP.CARS NOOBS LABEL; var &var; where type="&type"; RUN; ODS RTF CLOSE; The advantage here is there is absolutely no quoting issue - you are running the code just like it is %included - but you don't have to generate the %include statement to be passed along for execution.

DonH · ‎08-16-2020

Not sure why you don't want to use a macro. Regardless, you could consider using the dosubl routine instead of call execute. Call execute stacks the statements you pass to it so they run after the data step. The dosubl routine calls them immediately. That allows you to not worry about concatenating the data step variables (as suggested in this very nice alternative) and dealing with where quotes go when constructing the code string. Just use macro variable references instead - and single quotes for the code string, thus preventing resolution during compile of the data step. The array _char is used to load the values of the current row into macro vars. data _null_; input file $ var $ type $; array _char(*) _character_; do i = 1 to dim(_char); call symputx(vname(_char(i)),_char(i)); end; codeline = 'options nodate pageno=1 linesize=80 pagesize=30 obs=10;' ||'ODS RTF file="C:/temp/&file..rtf";' ||'PROC PRINT DATA=SASHELP.CARS NOOBS LABEL;' ||'var &var;' ||'where type="&type"; RUN; ODS RTF CLOSE;' ; rc = dosubl(codeline); cards; file1 model Sedan file2 model SUV file3 model Wagon file4 model Truck run;

DonH · ‎08-01-2020

It is not hard to get the right size. Just define a hash table using a data set with the right variables and length and get the item size attribute. It is not just the number of variables. It also depends on their type/length. And it is repeatable. IIRC (and @hashman can correct me if I am wrong as this is something he researched for our hash object SAS Press book), but if you concern is calculating how much memory is needed across different OS's, the OS dependency is primarily an issue for narrow hash object tables.

DonH · ‎07-31-2020

And there is also a minimum length to consider. I modified the program to use _NEW_ to create the hash instances so I could redefine the same hash object with more variables. Note that the minimum length on my Windows 64 bit machine is 48 - and it does not increase by just adding a new variable to the data portion. 1 data _null_; 2 k = . ; 3 array d(*) $1 d1-d9; 4 declare hash h(); 5 h = _new_ hash(); 6 h.defineKey('k'); 7 h.definedata('d1'); 8 h.defineDone(); 9 OneDataVar = h.item_size; 10 put OneDataVar=; 11 h.delete(); 12 13 h = _new_ hash(); 14 h.defineKey('k'); 15 h.definedata('d1','d2','d3','d4','d5','d6','d7','d8'); 16 h.defineDone(); 17 EightDataVars = h.item_size; 18 put EightDataVars=; 19 h.delete(); 20 21 h = _new_ hash(); 22 h.defineKey('k'); 23 h.definedata('d1','d2','d3','d4','d5','d6','d7','d8','d9'); 24 h.defineDone(); 25 NineDataVars = h.item_size; 26 put NineDataVars=; 27 h.delete(); 28 29 run; OneDataVar=48 EightDataVars=48 NineDataVars=64 NOTE: DATA statement used (Total process time): real time 0.07 seconds cpu time 0.04 seconds

DonH · ‎05-12-2020

Anything that uses _n_ or _error_ or many of the other automatic variables for something other than their intended usage qualifies, by definition, as a Dorfmanism.

DonH · ‎05-12-2020

Thanks @novinosrin. Based on a quick look, it appears you have covered all the bases. I would like to add that @hashman and I were scheduled to present a Sunday morning tutorial at SGF2020. That obviously never happened. But the good news is that our tutorial was selected to be one of the virtual presentations that will be made available to everyone. @hashman and I are working on our recordings of the bits and pieces which the SAS folks will stitch together. It is scheduled to be released as part of what is being referred to as Season 3. Our presentation will be largely based on content from our book and we hope to cover a lot of ground.

DonH · ‎01-30-2020

Thanks @hashman for the reminder about that having to get pulled. I’ll find it and post it as article.

DonH · ‎01-30-2020

Thanks for the question and the tag draycut. A couple of thoughts on this (I have not tried your code yet). First, @hashman and I discovered quite a few things in the documentation that were less than clear. So add this to the list. Next, your observation that you could use the hash object later in your code is not surprising. The non-scalar object h in your example, is actually a pointer to a memory location. It is not a physical structure. So if the load of the data fails, and SAS properly cleaned up on that failure (more on this later), there is no reason why that hash object can't be re-used as long as the structure of the keys and data portion are the same (in your example, X is the only key and the only data item). There are numerous examples in the documentation and the book @hashman and I wrote (as well as here in the community) of such re-use after using the CLEAR method. Given this and returning to the issue of the documentation, it would not surprise me if cleaning up after such a failed load was fixed in a later release and this nuance of the documentation was just missed. And to respond to @novinosrin, there is not an explicit example of this in our book. So if there is a second edition, we could certainly include this. And WRT a Q&A, we can do that right here in the community (note that I tagged this reply using DMHashBook which is a tag @hashman and I use in articles we post here). The issue of reusing hash object pointers is covered in a few places in the book - most notably in the memory management chapter. And creating multiple instances of hash object in the hash of hash chapter. Hope this helps.

DonH · ‎10-30-2019

Part of the point of the book was to provide source material that could be plagiarized.

DonH · ‎10-16-2019

Thanks for the kinds words @novinosrin. And @Amanda3 if you are not ready to buy a book, you might want to consider reviewing the articles that Paul and I (and others) have written related to the book. Just search the communities library using the tag DMHashBook.

DonH · ‎08-31-2019

As a followup to @hashman's spot-on comments, you might want to review the communities article The SET Statement's Compile Time Functions that provides some additional context for why you sometimes see a conflict about numeric for character conflicts when defining hash objects. The key point is that the compiler does not recognize quoted strings as variable names (as @hashman said in his comment). If you never reference the variable that is defined to the hash object that is a quoted string in your DATA step, you get the execution time message Undeclared key symbol . . . If you do reference it elsewhere in your program, the compiler will add it to the PDV at compile time and typically will define the variable to the PDV as a numeric variable. The article above provides some examples.

DonH · ‎08-31-2019

A corollary to @hashman's suggestion about WORK, if you have access to a location with more space, define a libname to it (e.g., a libname like MYWORK) and then use the USER option to have SAS use that location for any data sets that have a one level name. That allows you to use a different location for your temporary data sets without having to update each reference. Just make sure to delete all the SAS datasets you created. If the location only contains your WORK data sets (e.g., by creating a sub-folder in that location with more space), you can simply run something like to delete them all: proc datasets lib=mywork nolist kill; run;

DonH · ‎08-12-2019

There might be a better way. But if you click on properties for the program then select Customize result formats . . . . and then make sure none of the checkboxes are selected, EG won't generate an ODS statement.

DonH · ‎08-11-2019

The article The SET Statement's Compile Time Functions should answer your question. It was written from the perspective of the use of the hash object. But it does explain the dual role of the SET statement (compile time vs. execution time).

Online Status	Offline
Date Last Visited	‎04-05-2024 10:32 PM