ballardw Tracker

Re: Order list

ballardw — Mon, 24 Aug 2026 15:36:21 GMT

Typiclly SYSCC will be 4 when a WARNING occurs.

There are some interactions with the ERRORCHECK system setting and some specific statements such as LIBNAME , FILENAME and %INCLUDE statements. You should read the online help for SYSCC for details.

These statements are likely just one reason that setting your own global macro variable might be a good idea.

Re: SAS is tooo slow

ballardw — Tue, 11 Aug 2026 02:49:53 GMT

For what very little it may be worth, I noticed that using the USB connection on the front of my desktop is much slower to charge my cell phone than that using one of the ports on the back of the machine as well

Re: proc gradar axis order

ballardw — Tue, 11 Aug 2026 02:46:25 GMT

@palolix wrote:

Yes, but I would like to have the starlines like in the first graph, they look weird in the second graph.

Thanks

They look like they have the radius value you requested to be plotted. If you want to plot a different radius value then you need to provide one. Or remove the values from the plot set close to 0 if I understand what appearance you want.

Re: proc gradar axis order

ballardw — Sun, 09 Aug 2026 03:40:17 GMT

The second graph is using 0 at the center of the graph. So I am not sure what you expecting/wanting that is not occuring.

Re: proc gradar axis order

ballardw — Thu, 06 Aug 2026 22:06:12 GMT

I ran your code as posted and the log for the Gradar part shows:

NOTE: Processing beginning for CHART statement number 1.
WARNING: Negative or zero value encountered for FREQ= variable.
WARNING: These observations are not processed.
NOTE: 27 nonmissing values of texture_label are processed.
NOTE: Radar categories are sorted in the order determined by the
      classification cell corresponding to DM_range=15-20.
WARNING: One or more overlay values is missing.
NOTE: 67846 bytes written to C:\Users\Owner\AppData\Local\Temp\SAS
      Temporary Files\_TD16884_DESKTOP-C36D7SF_\radar.png.
68   quit;

NOTE: PROCEDURE GRADAR used (Total process time):
      real time           0.36 seconds
      cpu time            0.15 seconds

You may want to consider if these warnings about values are affecting the plot.

I am not sure what you want when you say you want the "plot to start from 0". If you want 0 at the center of the plot you will have some lines spike inward has you have values in plot your plot set like 0.94, 1.79 and 1.53 which with the scale of values you show will approach the center. So perhaps a better description of what you actually want for appearance will help.

I will admit that it has been a long time since I used GRADAR regularly, like 1996, and then mostly for windroses as I was dealing with wind directions. Are you sure that you want to use a FREQ variable? There are a few places where non-integer Freqs behave a bit oddly and that may be the cause of the warnings. I also seem to remember that having numeric values was best for controlling orders of appearance.

Re: SAS Support Communities metrics and their trends

ballardw — Sun, 02 Aug 2026 20:43:08 GMT

Another board that I spend time on regularly that has nothing to do with software at all also has seen about an 80% decline in traffic over the past 4 or 5 years.

Maybe YouTube and other sites are just plain sucking up peoples time.

Re: Will this work to partition a large data set into 10?

ballardw — Fri, 31 Jul 2026 22:22:12 GMT

@RandoDando wrote:

I have this code, but I am unsure it will work as intended.


data Part1 Part2 Part3 Part4 Part5 Part6 Part7 Part8 Part9 Part10;
    set LARGE_SET;
    id = mod(_n_, 10);
    if id = 0 then output Part1;
    else if id = 1 then output Part2;
	else if id = 2 then output Part3;
	else if id = 3 then output Part4;
	else if id = 4 then output Part5;
	else if id = 5 then output Part6;
	else if id = 6 then output Part7;
	else if id = 7 then output Part8;
	else if id = 8 then output Part9;
    else output Part10;
    drop id;
run;

Once upon a time we had a graduate student in the shop I worked asked how to split the "large" SAS data set into smaller pieces, though in his case it was to separate individual variables, because when it exported to Excel to do summary statistics the result was taking more than 4 hours. I asked what he was attempting and showed him that asking for the exact same summary statistics he was requesting using SAS with the existing SAS data set executed in 1 min 15 seconds.

Things like this are why we ask what your further processing involves.

Also remember that if the original data set order changes you cannot reproduce the same results if you partition it this way again.

Re: Help formatting dates

ballardw — Fri, 31 Jul 2026 22:13:20 GMT

@Tom wrote:

@RandoDando wrote:
Thanks. I have a followup question: will Proc compare treat two identical date values in different formats as equal?

Yes. The value stored is not impacted by the method you have attached for how to display the value.

An anecdote from data imported from Excel: I have had values that appeared as dates in Excel that had a decimal component that was kept on import. Since the SAS date formats only use the the integer portion you might not see that decimal bit until you try to match the dates and get unexpected results.

IIRC this occurred with an Excel column that contained mixed date only values and datetime values as Excel uses the decimal portion to store time of day information.

Re: "not sorted in ascending sequence" error despite sorting that way in prior step

ballardw — Fri, 31 Jul 2026 03:31:20 GMT

@thomasn528 wrote:
Thanks but no, that's not it. The error message claimed the *prior* nested sort hadn't worked. and had even yielded a differently sized data set!! (as SASKiwi noted.) The "rnd" is listed last, it's needed there, it's the item to be ranked in PROC RANK -- and this step had never malfunctioned before, in dozens and dozens of program runs-times-loop-iterations.

Having re-run the same program on the same data without error this time, this now seems to me to have (indeed) been some kind of resource shortage/malfunction caused by running two demanding programs at the same time on my little pony of a PC.

The highlighted is not what the log shows. It says that the set that Proc Rank attempted to use did not match the required sort. Not that the sort hadn't worked. Pedantic perhaps but there is a difference.

Macros and reusing of same data set names is always something to be a bit cautious of as a failure of one element can leave a data set from a previous run. I often remove "temporary" data sets at the end of a loop so this doesn't occur (and to keep disk space under control sometimes).

Re: proc tabulate with 2 nested variables for columns, 1 sorted ascending and 1 sorted descending

ballardw — Thu, 09 Jul 2026 22:30:34 GMT

@hein68 wrote:

Hello. I wrote some proc tabulate code that is working for me with continuous outcome variables but not categorical outcome variables. I would appreciate any help you can provide. The data is a long file where all IDs have a pre record and some IDs have a post record. Here is the code. I cannot drop it in, sorry.

proc tabulate data=data format=6.1 nosep order=internal;

class group / descending;

class time;

var contvar;

table contvar*(n mean std nmiss),group*time;

run;

How would I get a table with n and % for categorical variables by group (sorted ascending) and time (pre and post) sorted descending?

Thanks!

Since your Proc Tabulate code does not use any variable called ID why do you include " where all IDs have a pre record and some IDs have a post record. " That bit of trivia apparently has no obvious connection to this problem. If you are discussing the role of a variable then name the variable.

If you want Group to be ascending then why did you have the option /descending for the Group variable? The default for class variables is "ascending" but if you have a FORMAT applied to the variable(s) things may appear as if they are not ordered.

Strong hint: provide some example data in the form of a working data step and if your actual data has custom formats applied then the definitions of the formats, or at least enough to work with the example data.

Re: Errors in Importing Excel Data from a Single Worksheet

ballardw — Tue, 07 Jul 2026 16:59:25 GMT

One caution with using Excel files as libraries to read data into SAS: They must be clean.

That means column headings only one cell starting on the first row, all the data in a column the same, i.e. numeric with the same type (all dates, all currency, all simple numbers, no mixing) or character. If the Excel is actually more of a report appearance then likely the library approach will lead to much frustration.

If the Excel has two or more column headings then the column will likely be treated as character. If there are one or more blank cells above the headings you will likely again have the column treated a character (and possibly records with missing values).

At one point in my working career I would say that nearly 20 percent of my work time was cleaning up Excel "data" that the creators could not, or would not, keep consistent in any structure. When the Excel library was introduced in SAS I had one project that it seemed a reasonable solution to the read the frequent files provided. Lasted 3 weeks before the first file change.

Re: Setting the grid in SGPLOT but not setting an upper limit

ballardw — Fri, 26 Jun 2026 00:13:03 GMT

@sbxkoenk might have added that the UNISCALE option allows controlling which axis has the same scale and which are allowed to differ. So the uniscale=column says that that the column variable, the horizontal axis, will have the same interval and tick marks but the vertical axis is allowed to vary between the Panelby variable values.

Re: Macro with PRXMATCH

ballardw — Mon, 22 Jun 2026 05:37:24 GMT

Note that since you are using two different variables as your sources, Lb_lg and Lb your code example quite likely is not returning what you would want because you would require if/then/else structures. consider if lb_lg has a value of .45 and Lb is .5 (given the appropriate other string characters). Do you want Taux to be 0.0045 or 0.005? Without an ELSE between the first and second IF/then the second comparison will reset Taux to 0.005 after it had been set to 0.0045 in the first block.

I would also suggest using these rates as numeric and investigate the SELECT / WHEN comparison structure to get a clearer code for the hierarchy with two apparently similarly ranged variables. Of course if there was only a single variable involved an custom format likely could be used to remove the logic completely out of the data step.

Re: Visitnumber derivation

ballardw — Sun, 07 Jun 2026 23:01:51 GMT

Many users here don't want to download Excel files because of virus potential, others have such things blocked by security software. Also if you give us Excel we have to create a SAS data set and due to the non-existent constraints on Excel data cells the result we end up with may not have variables of the same type (numeric or character) and even values.

You also do not provide any STARTING data at all. As a minimum we would need a working data step that creates a TEST data set that will yield a similar behavior to your problem. The data step code should be pasted into a text or code box, opened on the forum by clicking on either the </> or "running man" icon above the main message window. These boxes will prevent the forum software from reformatting code such as by removing indentation if any was used and has been known to introduce artifacts into code so that it will not run as pasted.

Another advantage to the data step is that we can see the names and properties of variables without even running code. Sometimes that is sufficient to answer some questions.

Something else that would be helpful would be to describe what you want help with. Is it only the assignment of the visit number as implied by your subject is there something involving AVAL because you mention "worst Aval" but do not define that anywhere in the problem. And if that is in the example output you show it isn't labeled so we can't tell.

At which step is your i_need supposed to generated? Since your code doesn't mention that name for a data set the step(s) in question are a bit obtuse.

Also, the "logic" throws out a lot of apparent time intervals but not a clear explanation of what the intervals are used for.

It may not hurt to define what "week" means to you as SAS has some function that are more direct interval calculations. Though I suspect that anything using a changing length and thinking of it as "week" is problematic along those lines.

Without starting data I can see a couple of places that could result in unexpected results.

The most obvious would be having more than one missing ADY value sequentially or identical values of ADY, presumably across whatever PARAMCD is. Which could be occurring on the same date but at different times of day.

Another is where you take the full TEST1 data set and then append records using SET statement. I would almost think that a MERGE on subjid and avistn (or other identifying variables) would make more sense if the purpose is just to add one number.

There are also places that you assign missing to the new_avist and new_avistn variables. Missing is smaller than all other values so the order of processing in the SQL portion of that macro may not be as expected.

Re: From a Learner to a Pro: Real World SAS Debugging Scenarios

ballardw — Sun, 31 May 2026 11:52:02 GMT

In this case if the suggestion is to run Proc Contents then I would say the system is failing way earlier. Such as when reading the data into SAS. If you control the read, such as with DATA step code instead of Import then the Proc Contents should be moot. Or if linking to an external data system they are changing specs on the source data and the read process is not checking early enough.

Symptom in the log:

NOTE: The data set WORK.FINAL has 0 observations.

Root cause:
A WHERE condition is too restrictive or mismatched in data type.

where transaction_date = '01APR2026';

But transaction_date is a SAS date (numeric), not a character value.

How a pro fixes it:

where transaction_date = '01APR2026'd;

Pro lesson:
:white_heavy_check_mark: Always confirm variable types using PROC CONTENTS
:white_heavy_check_mark: Empty outputs are often logic issues, not syntax issues

I spent 10 years working on a government data project where we could not get the contracts people concerned with the data required to report on the activities to be specified as part of the contracts. As a result I had to deal with data "sources" that changed content, layout, file type and access methods as often as monthly. The report pieces had to be rewritten to deal with the data changes frequently because the data was such different.

I especially enjoyed dealing with the files that would have columns change from date to currency or vice versa part way through the file for single columns (really really hate dealing with spreadsheet data sources).

Re: SAS installation blocked

ballardw — Tue, 26 May 2026 17:54:49 GMT

Don't be surprised if you end up having to get your IT staff involved and talking with a SAS tech representative. Some of the policies that organizations have imposed on users may prevent writing to the locations that the SAS install requires.

Re: Converting SPSS .sav data with special symbols

ballardw — Sat, 16 May 2026 20:15:23 GMT

If you have an SPSS install and export the data to SAS with the correct options it should create a SAS program with Proc Format statements.

Then you may be able to modify the format to use the special characters by use of unicode. You might still have issues with seeing the results properly depending on the SAS encoding if that doesn't support the unicode characters.

If you have to rely on the SAS import for SAV files then I suspect the only option will be to write data step code to modify the values to something your system will handle and possibly write a custom formats get the special characters to display using an acceptable font and/or unicode. Which may be long task if there are many of these special values.

Without knowing the required system encoding and font used can't provide anything better at this time.

Re: Find (ctrl-F) and replace (ctrl-H) not reognized

ballardw — Sat, 16 May 2026 20:05:11 GMT

"Stopped being recognized" implies that the key strokes had been recognized before. But that "before" often means that something in your system changed. It may help to describe any recent changes in your system.

Have there been any updates to software recently? And since ctrl-F and H are system keys in many respects system changes count.

Or did you change something and didn't change it back? For example in the SAS display manager the ctrl-F and H brings up a dialog box that has some options such as Find in Code and comments, Find in code only or Find in Comments only. If you set one of those options they persist until changed. So if have set Find in Comments then the find won't find anything in the code section. Or if you clicked on the Match Whole Word or Case options you might not be finding as expected. And the Replace won't work if nothing is found.

I've had keyboard errors such that the proper codes aren't sent to the computer and keyboard models that either require additional key settings or strokes to send standard function key codes.

Also as @ChrisHemedinger mentioned which environment.

Re: Combine the variable values vertically

ballardw — Sat, 16 May 2026 19:46:02 GMT

@NewUsrStat wrote:
Thank you very much for your help. Unfortunately the code that refers to the array does not work. But, anyway, how it become if the value of the variable is repeated identical?

What does "array does not work"?

If code throws an error then provide the log with the code and all the messages. Copy the text from the log then on the forum open a text box in a message using the </> icon above the message window and paste the code.

If the result is not as expected then provide the data used in the form of a working data step and then provide more detail as to the expected result for the example data.

I am afraid that a generic "does not work" is very unhelpful in diagnosing problems.

Re: WARNING: Apparent symbolic reference OUTPATH not resolved. & Physical Path doesn't exist for

ballardw — Tue, 12 May 2026 17:46:42 GMT

To use a macro variable such as &outpath, the & meaning the following is the name of a macro variable, then prior to the use of the variable you should have a statement similar to :

%let outpath = d:\thisfolder; (for Windows) or

%let outpuath= drivemountpointname/thisfolder;

Or possibly other code that does similar with data step and the CALL SYMPUTX option or Proc SQL code with and INTO instruction to write results into a variable named Outpath.

In the case of canned programs from a SAS course this is usually done in either a set up program or there is an instruction to uncomment a bit of code and replace some example text with the path on your system. I would look in your instructions for a %let statement to modify.