I recieve a raw file and i have to load in X sas tables by region. For loading it, we have to read, split, sorting and merging.
I want to program it without having to put the regions manually.
I have something like that:
data entry1 entry2 entry3;
%include 'input format';
array RegionArr ('00','00','00');
when ('01') do;
region(1) = RegionArr
when ('02') do;
region(2) = RegionArr
If final then do;
And here is my doubt how i could pass this array for using later in a do loop for sorting the data
do i to dim(SclArray)
proc sort data = 'entry'&i; --> table work.entry1/2...
by ccc norden ordentra;
proc sort data = region||sclarray(i); ---> rable region01/02/03...
by ccc norden ordentra;
I know that i could make it thinking in other ways but i dont find how to do it.
Investigate using PROC SQL to generate a SAS macro variable containing a unique/distinct list of variable values. Then in a %DO / %END macro code paragraph, iterate through the macro var value list to execute your other SAS code.
Recommended Google advanced search, this topic/post:
proc sql select distinct into macro variable site:sas.com
Usually i could resolve my doubts using google, but this is the first time i'm really really stuck.
So i seen cleary that the only thing that i need is pass this at the end in data step (my boss want to do in this way) array to macro array. I think the rest of the code i could investigate too. I'm not a lazy developer, but i think someone could know this (i preffer giving the tecnics for resolving and not the solution, but i'm a bit desperate)
BUT, BUT, my boss, want to do it in this way So Mr. Barry, do you know any way to pass a local array in a data step to a global array? or the proc sql + into is the only way to do this?
If i can do it only for working i have it, BUT my boss want this way, and it's a really pitty. And as ia said i was invetistigatinv proc execute, but i dont really understand it, i'm new in macroworld.
Message was edited by: Sasvage
Message was edited by: Sasvage
Your use of prhases like "local array" and "global array" are a bit concerning. Can you explain what these references meam, both to yourself and for others?
You have a CALL SYMPUT function to generate macro variables from a DATA step, in addition to what I have already suggested (with DOC reference) using PROC SQL. This will "pass" information from one SAS step to another.
Your scavenger hunt or "puzzle of the day" situations are not amusing to me. I'd rather offer gudance to lead rather than attempt to pull someone with SAS coding practices. Suggest you work with your bad-boy boss to move this concern forward and to some sort of end. Also, the whining is unbecoming even with the bogus emoticons which I detest in these forums where they are a distraction, frankly.
One individual's opinion..at full-throttle, of course.
I know i was not enough polite, but the RTFM actitude doesn't solved nothing for me.
As you said and i finally discovered by myself the calls ymput generate N variables like state1 state2.
And seriusly and it's not a joke, i think you'll be a good boss. I have good one, but my solutions will be good until the next release, it's the kind of flexibility that workers hate.
I will need the proc sql with :into in the future so thanks. I'm not sarcastic, believe me.
I agree with Scott that your use of terms like "local array" and "global array" show a misunderstanding of the fundamentals of SAS -- both about arrays and about macro variables.
A SAS DATA step program allows you to treat a group of variables as members of an array for ease of processing and reference. So these are all valid DATA step array references:
array lovelucy $ fred ethel lucy ricky;
array regsl regsale1 regsale2 regsale3 regsale4;
In a DATA step program you could use a DATA step DO loop to iterate through an array in order to perform some kind of processing.
The SAS Macro facility does NOT have any such construct. Although the Macro facility allows you to build numbered macro variables and although you can use a %DO loop to generate code from those numbered macro variables, there is no such thing in the SAS Macro facility as a "local array" or a "global array". There is only the GLOBAL symbol table and the LOCAL symbol table (if you are using LOCAL macro variables within a Macro program).
Sadly, as with many other knowledge areas, at some point, you do have to "read the manual". If the Macro facility documentation is not attractive, then you will have to read user group papers or books about the SAS Macro facility in order to do what you want to do. It is indeed possible to write a SAS macro program which would iterate through a list of numbered macro variables (one for each region) , generate a PROC SORT and then generate whatever other report code needed to be generated. Some people call this ability a macro "array" because, it acts -LIKE- an array, but technically, the macro facility does not have any explicit %ARRAY statement -- it is unnecessary given the fact that you can use %DO to iterate over a group of numbered Macro variables.
Also confusing in your post is the reference to SCL?? Without knowing the context for using SCL (SAS/AF? BI Java application using Eclipse and SCL with Java beans?) it is hard to even start to talk about passing information from Base SAS to an SCL application, because SCL sometimes uses lists to hold information to be used for processing and that is an entirely separate topic.
I don't understand your parting shot where you said: but my solutions will be good until the next release, it's the kind of flexibility that workers hate
The SAS Macro facility has been around since the early days of SAS and macro programs that I wrote back in Version 5 and Version 6 are still running in Version 9.2 -- the underlying SAS code generated from the Macro programs has changed a bit to take advantage of new features and options, but the Macro facility, itself continues to work like a champ in my opinion.
I see that beyond sas af i'm totally ignorant. I'm hurry for ending this development but i will read your post carefully.
"but my solutions will be good until the next release, it's the kind of flexibility that workers hate"
I can make the development using my methodology, but in the next year or next release i'm going to develop "as the boss says".