Cynthia_sas Tracker

Re: SAS® Programming 1: Essentials Activity p103a02.sas Not understanding Table results

Cynthia_sas — Tue, 24 Mar 2026 19:29:24 GMT

Hi: I have worked in enough different editors, that I don't ever use the keyboard shortcuts. I have learned over time to manually edit the code and if the editor does have color coding, then I pay attention to the colors changing as I edit. It is always a good idea to make sure that the statements that are going to run are not accidentally being turned into comments -- one of the things that is revealed by using a SAS editor ; or that you don't have too many or too few quotes -- which is another thing that can cause you issues when you run your code.
Cynthia

Re: SAS® Programming 1: Essentials Activity p103a02.sas Not understanding Table results

Cynthia_sas — Tue, 24 Mar 2026 18:02:35 GMT

Hi:

My suggestion is that you go back and review the section on comments in the lectures. In your screen shot, note how the WHERE statement is green and the RUN statement is also green. That means that BOTH of those statements are essentially comments. So that means your WHERE is not working because it is being treated as a comment. The code for that activity originally looks like THIS:

***********************************************************;
*  Activity 3.02                                          *;
*    1) Uncomment each WHERE statement one at a time and  *;
*       run the step to observe the rows that are         *;
*       included in the results.                          *;
*    2) Comment all previous WHERE statements. Add a new  *;
*       WHERE statement to print storms that begin with   *;
*       Z. How many storms are included in the results?   *;
***********************************************************;

proc print data=pg1.storm_summary(obs=50);
	*where MinPressure is missing; /*same as MinPressure = .*/
	*where Type is not missing; /*same as Type ne " "*/
	*where MaxWindMPH between 150 and 155;
	*where Basin like "_I";
run;

Note that in a regular SAS Editor, like SAS Studio, the 4 WHERE statements should be showing as green, which indicates that each WHERE statement is a comment. So, when you "uncomment" and the code as instructed, you should be running code 4 different times showing only one active (not green) WHERE statement each time. So, this is how your code would look each time -- basically, for each run, you would delete just 1 asterisk at the beginning of the WHERE and that should turn the comment into a regular code color (as opposed to a comment color) -- then you submit the code with only 1 WHERE statement active, review the results. Then go back to the code and re-comment the WHERE you just ran and then uncomment the next WHERE and run the code again. You do this 4 times, with a review of the output each time.

Then at the very end of submitting each WHERE statement and reviewing the output, you have to do one final WHERE. You can either delete the 4 original WHERE statements or leave them as comments in the code when you run your final activity code. The solution to the activity shows only the final WHERE that you need to write:

Hope this clarifies the activity.

Cynthia

Re: SAS OnDemand for Academics: ODS not supported?

Cynthia_sas — Fri, 14 Nov 2025 16:05:11 GMT

Hi: In order to provide concrete assistance, we'd need to see the log of the original code that generated the error and the original log. However, this article https://sas.service-now.com/csm/en/using-the-sas-sg-procedures-or-ods-graphics-with-the-user-system-option?id=kb_article_view&sysparm_article=KB0041619 indicates that some combination of options could cause the error and so it seems likely that when you started over in a fresh session, you may have reset any options that any of your code changed. If it happens again, your best resource would be to capture the full log and either post that or optionally (and possibly more productive in the long run) open a case with Tech Support.
Cynthia

Re: Need help with the SAS badge

Cynthia_sas — Wed, 05 Nov 2025 13:01:46 GMT

Hi:

The usual reason for not seeing the claim this badge link when you open a course happens when a student might accidentally start one of the free trial packages. One side effect of many free trials is that they disable the badge feature. The goal of a free trial is for the student to preview the material prior to making a purchase decision and so a free trial activation can turn off the badge feature. For example, you might have started Stat 1 from the link that is for the stand-alone free class and as long as that was the only activation, the badge would always be there. However, if you accidentally activate one of the free trial packages that also includes Stat 1 as one of the classes, then the free trial has badges turned off and that second activation would override the badge feature in the first activation. As soon as the free trial expires, the badge feature should reappear. There are a few other odd circumstances that could turn off the badge feature. If you need to get the badge feature back sooner, rather than wait for the free trial to end, you can always send mail to elearn@sas.com and ask to have your account adjusted to expire the free trial early. When you send your mail, be sure to let them know all the possible email addresses that you might have used to start training. Sometimes people write with their GMAIL or OUTLOOK emails but take classes under a work or school email.

Cynthia

Re: Using SAs onDemand for Academics: Enterprise Guide - Need clarification about costs

Cynthia_sas — Sat, 18 Oct 2025 22:10:13 GMT

Hi:
If your instructor set up a sponsored course and indicated EG as one of the software choices for the class on the SAS OnDemand server; AND if you used a special code to add your name to his class roster, then you are allowed to use SAS Enterprise Guide at no cost as part of your participation in the sponsored class. The ability to use SAS Enterprise Guide for an academic class, is one of the benefits afforded to University professors for their class(es). There is no charge to the professor or the student for the use of SAS Enterprise Guide on the SAS OnDemand server.
Cynthia

Re: check if the content of a variable is in another variable

Cynthia_sas — Wed, 15 Oct 2025 23:47:38 GMT

Hi:
More information is needed. Why are there duplicates in List A. For example, is there any difference in the 2 occurrences of the name TINTLE or BURGESS in List A? Can you explain how you expect these duplicates to be handled in terms of the lookup? Also, please clarify whether you have 2 separate datasets -- List A with the list of names you want to look up and then List B with the string that seems to contain multiple names that you want to search in. What happens if a row in List B has 2 names -- for example, List B has both Edison and Burgess -- is this a possible scenario? Is there any reason for the unsorted order of the names in List A (in addition to the duplicates)? Is this order important or in need of being kept?
If there was a better description of the structure of your data and the constraints of the data forum members might be able to make more constructive suggestions.
The structure of the data and the code that you have already tried might answer some of these questions. You indicated which functions you'd tried, but the functions don't work in a vacuum. What programming approach did you try? DATA step with IF, DATA step with IF and MERGE, SQL? HASH table? Can you provide more information?
Cynthia

Re: Hello I am trying to understand the different usages and implications of Proc Print, Tabulate re

Cynthia_sas — Tue, 09 Sep 2025 14:44:55 GMT

Hi:
I had a table of comparisons in the Creating Complex Reports paper https://support.sas.com/resources/papers/proceedings/pdfs/sgf2008/173-2008.pdf on page 7. Several of the papers already mentioned discuss differences.
Cynthia

Re: Matching 2 Character Fields

Cynthia_sas — Mon, 08 Sep 2025 22:11:42 GMT

Hi:

I don't think you've provided enough information for a concrete suggestion. In a quick test, using your fake data I created Table A with POLICY and CUSTOMER and then created TABLE B with the same 4 values for POLICY and also created a LIMIT column. I ran a few tests and got matches using both a DATA step MERGE and an SQL join. Table A had POLICY with a length of $9 and B had POLICY with a length of $20. Of course, SAS did give a WARNING about the differing lengths of the POLICY variable in the MERGE where the data set with the length of $9 for policy was listed first.

The code I tested is listed at the bottom of this post. You should be able to run it and prove to yourself that there were matches.

There are 4 steps -- 2 steps with MERGE and 2 steps with SQL JOIN. The POLICY values were the same and the output was 4 rows each time. So I cannot duplicate your observed behavior. There must be something different about your code or your actual data that is causing the non-matches to happen.

Do note the output from PROC CONTENTS after each step. It will make a difference in the output data for the length of POLICY, depending on which table is listed first in the MERGE or the JOIN. Others have suggested sharing more of your actual code and your actual data. I also suggest reviewing the log and reporting the exact warnings or errors you might see there (or even, post the log if it's not too long). However, if the ONLY difference in POLICY is the length, your MERGE or JOIN should work, as illustrated by my examples.

Cynthia

Data A;
Length policy $9;
Infile datalines dlm=',';
Input policy $	customer $;
Datalines;
000718124,1001
000714946,1002
000910934,1003
000901672,1004
;
Run;

Data B;
Length policy $20;
Infile datalines dlm=',';
Input policy $	limit $;
Datalines;
000718124,20000
000714946,30000
000910934,40000
000901672,50000
;
Run;

Proc sort data=A; by policy; run;
Proc sort data=B; by policy; run;

Data both;
  Merge A(in=fromA)
        B(in=fromB);
  By policy;
  If fromA=1 and fromB=1 then output both;
Run;

Proc contents data=both;
Title '1) Data A length $9 listed first in merge';
Run;

Proc print data=both;
Run;
title;

Data altboth;
  Merge B(in=fromB)
        A(in=fromA);
  By policy;
  If fromA=1 and fromB=1 then output altboth;
Run;

Proc contents data=altboth;
Title '2) Data B length $20 listed first in merge';
Run;

Proc print data=altboth;
Run;

proc sql;
  create table sqboth
  as select a.policy, customer, limit
  from a,b 
  where a.policy=b.policy
  order by policy;
quit;

proc contents data=sqboth;
title '3) data a listed first in the join';
run;

proc print data=sqboth;
run;

proc sql;
  create table altsql
  as select b.policy, customer, limit
  from b,a 
  where a.policy=b.policy
  order by policy;
quit;

proc contents data=altsql;
title '4) data b listed first in the join';
run;

proc print data=altsql;
run;

Re: Determine age when DOB is prior to 1960

Cynthia_sas — Thu, 04 Sep 2025 20:01:49 GMT

Hi:

I agree with @PaigeMiller . There's something else happening with your data or your code. Just using some of your data values, I still get the correct values calculated -- even with a date in 1884 thrown in just for additional proof:

I wonder what is in your original data that is causing the problem. As demonstrated with multiple examples, the code should generate a correct results, assuming that the date values used by your functions are actual SAS date values.

Cynthia

Re: Determine age when DOB is prior to 1960

Cynthia_sas — Thu, 04 Sep 2025 17:49:26 GMT

Hi:

I'm not sure what your date_01 variable is. However, testing on age based on today's date, I get these results:

As you can see/subtract yourself, the ages are all correct given the dates both before and after Jan 1 1960.

I used this code:

I suspect that yearcutoff is not your issue because with a 4 digit year, you should not have any issues. And your use of mmddyy10 for the format implies that you have a 4 digit year.

Cynthia

Re: Date format

Cynthia_sas — Wed, 27 Aug 2025 21:45:23 GMT

Hi:

I'm not sure what you want. Remember that a SAS date value is stored internally as a number and a SAS date/time value is also stored internally as a number. The format that you show is only how the variable is displayed in output, such as reports. Without any format being applied, you can prove this to yourself by running this program:

That very large number that is stored internally represents the number of seconds between midnight on Jan 1 1960 and your date/time value. If you already have date/time variables stored in your data, then your assignment statement is NOT applying a format. If you want to apply a format to change the way your variable is displayed, you would use a FORMAT statement or for the PUTLOG statement, you can specify the format after the variable to be displayed in the log. Note the difference between a format with a width of 20 and the format with a width of 18 -- that will give you the 2 digit year you seem to want. Just remember that your assignment statement is NOT storing your date/time value in a readable format --your numeric date/time value is ALWAYS stored as a number.

Perhaps if you could explain a bit more about your data and what you need to do, it would be easier to understand why you think the assignment statement is necessary.

Cynthia

Re: Highlighting cells in PROC REPORT via compute block with call define, unusual results

Cynthia_sas — Tue, 26 Aug 2025 22:13:44 GMT

Hi:

Your original code has a "timing" issue. Think about PROC REPORT as only placing one value on the report row at a time, following the order of the variables in the COLUMN statement from left to right. So on the first data row on the report (after the column headers), the first item that PROC REPORT puts on the report row is the value for ID -- at that point in PROC REPORT timing -- only the value of ID is known. When PROC REPORT puts the ID value on the report row, it hasn't placed VarA or VarB on the report row yet, so it has no visibility or knowledge about what those values are.

In the same way, next, PROC REPORT writes the value of VarA to the report row. Now, in a COMPUTE block for VarA, you can test either the value of ID OR the value of VarA. But, just like before, when PROC REPORT is putting the value for VarA on the report row, it doesn't know what the value is for VarB, so in terms of your comparison in the COMPUTE block for VarA, inside that COMPUTE block, PROC REPORT doesn't have any value on the report row yet for VarB, so the value of VarA can't be compared to VarB because VarB isn't on the report row yet. So it's not the order of the COMPUTE blocks that will make a difference, but changing the placement of the conditional testing until AFTER all the report row has finished being built. That means in the COMPUTE block for VarB, you will have the ability to use your conditional logic because at the point in time when the COMPUTE block for VarB is executed, ALL of the items on the report row have been placed down, so now PROC REPORT knows the values for ID, VarA and VarB. Basically, you can remove the COMPUTE block for VarA, but move the IF statement into the block for VarB. You'll need to change the CALL DEFINE for the VarA IF to be sure that the correct column is highlighted, as shown in the screen shots for results and code below.

Cynthia

Results:

Code:

Re: How do I share SAS codes with other SAS ODA users?

Cynthia_sas — Fri, 15 Aug 2025 13:24:22 GMT

Hi:
Your disk space on the server is only accessible to you. So, there is not a way for you to share your folders with another person.
The easiest thing to do is for you to download the code to your local machine and then from there, either zip or DropBox or GitHub the files.
SAS Studio on SAS Viya for Learners for academic users does have a way to work with GitHub files. However, the last time I checked, SAS Studio on SAS OnDemand does not have GitHub access from your OnDemand account directly.
To download the file(s) you want, just right click on the file and select Download from the drop down menu.
Cynthia

Re: Code window too small in width

Cynthia_sas — Tue, 05 Aug 2025 21:28:05 GMT

Hi:
This is not really an "ongoing" discussion, since the last post before your post was 6 years ago in 2019. The only reason it is still open is that the original poster never indicated that the thread was solved.
At any rate, back in 2019, the version of SAS Studio being used was different than the version of SAS Studio that is current now. It also makes a difference what browser you're using with SAS Studio. Your best resource for this type of question would be work with Tech Support. I've never experienced the type of behavior that you're describing in SAS Studio on the SAS OnDemand server, so I don't have any good suggestions for you. You can contact Tech Support by sending mail to support@sas.com and include your Site ID and version/Operating System information and a description of the issue.
Cynthia

Re: Replace a double hyphen (“--”) with an EN DASH ("–")

Cynthia_sas — Thu, 31 Jul 2025 19:49:22 GMT

Hi:

I am not sure you'll ever see the change in the data viewer in EG. However, based on this example https://documentation.sas.com/doc/en/statug/15.2/statug_kaplan_sect045.htm in the documentation about how to get a large dash in PROC LIFETEST, I used the ODS ESCAPECHAR string (*ESC*){Unicode '2014'x} that they show and the results seemed to work for me in ODS output. Basically, I changed your code to use the ODS ESCAPECHAR string in the TRANWRD function and then used PROC PRINT to send the output to either the default destination or ODS PDF or ODS RTF.

PDF results:

RTF results:

But, when I look at the data in the data viewer in SAS Studio, I see the actual ESCAPECHAR string, which will only be rendered in ODS output, not in the data viewer.

Cynthia

Re: ODS and Reporting options in SAS ODA

Cynthia_sas — Sun, 13 Jul 2025 20:31:30 GMT

Hi:
As previously mentioned, some of the options specified in your code are LISTING only options and are ignored by ODS RTF and other ODS destinations. (HEADLINE, HEADSKIP, SKIP, etc -- all these and others are well documented) . To impact the RTF output, the best option is to use STYLE= overrides that are supported by ODS RTF, ODS PDF and ODS HTML. There have been many previous posts about using STYLE= overrides. And, as previously explained, without data, no one can test or tweak your code.
Cynthia

Re: PROC Export to EXCEL preserves a fake space

Cynthia_sas — Wed, 18 Jun 2025 14:21:55 GMT

Hi:

If this is a new behavior when you change operating systems/editors to create the SAS data, then this is probably an issue you want to raise with SAS Tech Support. They would need to look at all your code and understand the previous operating system/editor versus the current operating system/editor to explain why the difference occurs. You can always open a case with SAS Tech Support by sending mail to support@sas.com .

Cynthia

Re: PROC Export to EXCEL preserves a fake space

Cynthia_sas — Tue, 17 Jun 2025 21:48:50 GMT

Hi:

If you run PROC CONTENTS, you should see that the variable Y has been defined as character with a length of 1 byte. SAS represents missing values for a character variable as a space. This is essentially what your assignment statement is telling SAS to assign to the value for Y.

Just because your assignment statement has

y='' (with the 2 quotes next to each other), in your program it is the same as if you had used

y=' '; (quote space quote). Either way the stored value for Y is a missing value -- or space for the character variable.

That should create Y as a character value with a length of 1. So when the data is exported to Excel, the space character is what fills the cell. You call it a "false space" but in fact, it is a real space and your code assigned the space to Y.

Cynthia

Re: SAS OnDemand not letting me export as CSV or Excel files

Cynthia_sas — Mon, 16 Jun 2025 21:58:57 GMT

Hi Another suggestion is to be sure that your folder path is 100% correct in the right case and spacing. For. example, SAS OnDemand would consider
Data Dictionary (with space)
DataDictionary (no space)
data dictionary (lower case with space)
datadictionary (lower case, no space)
to be 4 separate folder names. Or, myfolders, My Folders, and my folders are all different folder names. Without seeing your error messages, it is hard to just guess what the error might have been. However, one of the most common issues that people encounter with using the SAS OnDemand server is making sure that their folder paths are correct. You can always right click on a folder in the Server Files and. Folders panel and choose Properties to see the full and correct path to use for that folder.
Cynthia

Re: Generating an accumulating column from Data Manipulation 9.4 practice=p202p04.sas

Cynthia_sas — Fri, 06 Jun 2025 14:31:30 GMT

Hi:
Reread the instructions for the practice again and then run a PROC CONTENTS on the pg2.np_yearlyTraffic data table. In the instructions, there is a sentence that says "Notice that the Count column records the number of cars that have passed through a particular location." So, you need to use the COUNT column from the starting data to create totTraffic in this instance. In a different scenario, you might create your own variable, but it is not necessary in this case.
Cynthia