Do consider that SAS has a macro variable maximum length limitation which could result in variable-name truncation.  Best to avoid the potential situation, program to write SAS code (with a DATA step) to generate the statements needed to perform the RENAME, reading either DICTIONARY or SASHELP view for determining an input variable list. ... View more

Explore using PROC DATASETS / MODIFY with RENAME -- SAS code can be generated then %INCLUDE, based on the output of a PROC CONTENTS with OUT=  or otherwise manually coded if/where the SAS variable names are known and expected to be present. Scott Barry SBBWorks, Inc. ... View more

Why is the SAS-internal variable order of importance?  Also, the DSD parameter purposefully addresses the condition where you have consecutive delimiters with intention of assigning a blank/null value to the corresponding SAS variable. Scott Barry SBBWorks, Inc. ... View more

Consider that there is nothing unusual (SAS input processing wise) about very long SAS CHARACTER variables - it's all about the LENGTH statement / variable definitions. And with stated condition for different formatted dates in one column, one time-honored approach then is to use DATA / INFILE / INPUT processing to read each column as $CHARn.  and then scrub the date-related / date-time-related columns using assignment statement(s) and the INPUT(....) function, as well as possibly "flexible" INFORMATs for "ANY" date / datetime format handling, though use those with care and with validation logic. Scott Barry SBBWorks, Inc. ... View more

One technique is to have a permanent SAS control/progress tracking member which you would update after each key processing point, and then convert your SAS program to execute as a macro with %IF / %THEN %DO; %* your code goes here; %END; (condition code-piece execution) within the macro.  And at the end, a successful completion would again update the SAS control/progress tracking member accordingly. Scott Barry SBBWorks, Inc. ... View more

The EMAIL macro would generate the EMAIL...invoked iteratively for each EMAIL-recipient from your list (possibly a SAS file/member).  The macro would contain SAS code that likely uses FILENAME and EMAIL engine to generate your EMAILs. A DATA step would be used to drive the CALL EXECUTE processing -- you must use SAS code to build the SAS macro invocation statements as the argument passed to CALL EXECUTE. You have to start with generating / compiling your EMAIL-recipient list, either from an external information source or possibly directly from a SAS file. Suggest you search the Internet with argument "data step call execute invoke macro" for documentation / example references. Scott Barry SBBWorks, Inc. ... View more

Yes, a DATA step could be used to read a file / list with INPUT, then construct the macro-invocation command you mention with the CALL EXECUTE.   Your EMAIL-generation macro would need to take any variable information as the macro variable parameters supplied when your DATA step invokes the CALL EXECUTE. Scott Barry SBBWorks, Inc. ... View more

As has been suggested, review the available SAS functions for data-scrubbing/validation opportunities -- as well, consider using INDEX, INDEXW and setup a DATA step DO/END loop to parse through a list of those "cannot use" characters / data-strings.  Then you might consider storing this "common data-scrubbing code piece" as a %INCLUDE external member/file for re-use. Scott Barry SBBWorks, Inc. ... View more

Consider investigating the merits with using PROC TRANSPOSE as well as DATA step processing to isolate in a separate SAS dataset/member those observations meaningful to your objective (resulting output dataset variable/column subset). Scott Barry SBBWorks, Inc. ... View more

Best to share your SAS program/code and also include the SASLOG in your post-reply. Scott Barry SBBWorks, Inc. ... View more

Also, consider adding some PUTLOG statements in the DATA step to echo back to your SAS log the contributing variable / value combinations.  Also, consider seriously the MERGE behavior and how the files defined on the MERGE statement influence the SAS system behavior, when (already mentioned in a subsequent reply) with same-named SAS variable names. You will be best served by doing some desk-checking (adding the PUTLOG statements) and running a sample controlled-test with a limited data subset.  Or better yet, use a DATA step to generate some sample data observations with known-values and use that to exercise your SAS program/code. Good luck! Scott Barry SBBWorks, Inc. ... View more

Much information is available at the SAS support resources website:  http://www.sas.com/resources/ Scott Barry SBBWorks, Inc. ... View more

Look at using a combination of INTNX function (to reset back to the start-date of the particular week) and a PUT function with the DOWNAME. format to get the "day of week". Scott Barry SBBWorks, Inc. ... View more

Note from the SAS documentation, your CALL EXECUTE will not be executed until the DATA step has been completed (up to the RUN; statement).  And so the macro code cannot be a continuation of the current DATA step.  Given this situation, it will be important to know what SAS statements are contained in your SAS macro for execution. Also you will see the SAS execution logic with this additional diagnostic statement, at least prior to your DATA step: OPTIONS SOURCE SOURCE2 MACROGEN SYMBOLGEN /* MLOGIC */ MPRINT; Scott Barry SBBWorks, Inc. Suggested Google advanced search argument, this topic / post: call execute site:sas.com ... View more