You say that this runs:
Here is the code I run
filename m email
to="Ron.xxx@gmail.com"
subject="Test from SAS"
content_type="text/html"
encoding="utf-8"
;
ods _all_ close;
ods html body=m;
proc odstext;
p "test message";
run;
ods html close;
You do not have an ODS HTML CLOSE; in the long program instead using an ODS _ALL_ CLOSE;
There is a chance that the behavior of the _all_ is different with the ODS Close. Easy try would be to insert an ODS HTML CLOSE; after the Proc ODSTEXT; to see if that changes the behavior.
... View more
thanks tom for the solution instead of punching down a newbie and mocking in code language. wasn't able to run the code possibly due to the glitch in sas studio. it is now fixed and running smoothly.
... View more
It feels like "something happened" and SAS overreacted. Backward compatibility was imho always an important selling point for SAS. I believe that it would have been more than sufficient for these functions to be disabled as a default but with some option to enable them - something similar to noxcmd.
... View more
As an aside, you might want to consider use of "not quite a date" variable like your "AccountingYearMonth" with apparent plain numeric values of 202509. Use an actual date value that represents the first day of the month to allow use of the SAS functions that will deal with increments and intervals . You can assign a format to the values that would have a default appearance of YYYYMM.
Your code
accountingYearMonth LE 202509
would become
accountingYearMonth LE "01Sep2025"D
which is, in my opinion, a bit clearer to follow the intent of the code.
SAS understands dates for many of the graphing procedures to do things like place tick marks at month or quarter intervals but graphing something with values like 202509 means a big gap between 202512 and 202601.
Plus the modeling and analysis procedures can use the intervals.
Not to mention simple things like the functions such as Quarter that would let you select a calendar quarter or a minor format change in a report could change the intervals from monthly to quarterly or annually
... View more
hello
thanks to your advices I managed to optimise very much.
I have a column "send date" in the big table so I added a criteria inside the inner join expression to limite the rows that are > of begining of the month.
many thanks.
Nasser
... View more
By any chance do you have one or more macros that includes the code of another macro as part? Something that might look similar to:
%Macro outer (<parameters>);
<some macro code>
%Macro inner (<parameters>);
<inner macro code>
%mend; /*inner macro*/
<other outer macro code>
%mend; /*outer macro */
Such nested compilations could be very obnoxious to diagnose when things get interrupted.
Long shot, but something to consider.
... View more
And the question is what exactly?
Best practice is to post code in a code or text box opened with the "running man" or </> icon above the message window. The text box will prevent the forum from reformatting code and possibly inserting/removing characters resulting in code that will not run or replaces some strings with odd characters such as bullet points.
Actual lines of data should be preceded by a CARDS; or DATALINES; statement with the semicolon.
If your inline data contains semicolons then use CARDS4; or DATALINES4; and end your data section with 4 semicolons.
... View more
@ballardw
I hadn't thought about what a use could be for code like "N=%left(&sam)", but if you are right, or if you are wrong, I think there is probably a better way to handle it.
It is a constant struggle to get people to explain the big picture of what they are trying to do, they only want to talk about the specific coding problem they have, they don't want to get into the big picture. This particular request seems like it is an instance of the XY Problem.
... View more
Just some comments on the example SAS code you posted.
If you want to set a macro variable you don't need to run a data step;
%let imsid=;
You almost never want to use the extremely ancient MISSOVER option or the merely ancient CALL SYMPUT() method. Instead use the modern TRUNCVOER option and the CALL SYMPUTX() method.
The only reason to use MISSOVER is if you want INPUT to ignore text at the end of line that is too short for the informat width being used.
The only reason to use CALL SYMPUT() is if you want the generated macro variable to have leading and/or trailing spaces.
The reasons that example would work using those ancient options/methods is
1) Because you are reading from a card deck the data lines will contain 80 characters even when the number of non blank characters is less than the 14 bytes you are reading.
2) Your usage of the IMSID macro variable most not mind the extra 10 spaces that you stored into the value by using CALL SYMPUT() with a character variable defined to store 14 bytes.
Of course you could also use the ancient NAMED INPUT style of reading data.
/* Initialize IMSID macro variable */
%let imsid= ;
/* Read IMSID from SETUP */
data _null_;
infile setup ;
input @'IMSID=' imsid :$4.;
call symputx('imsid',imsid);
run;
... View more
