ballardw Tracker

Re: ERROR: All variables in array list must be the same type

ballardw — Sat, 18 Apr 2026 05:27:29 GMT

@palolix wrote:

Thank you very much for your suggestion.

I changed the variable names as you suggested (FruitWt_Day0 etc) and then modified the code to this but I still get the same errors for the array

Changing the name of the variable does not change the variable type. So if you have a mix of character and numeric values as your error messages says then the change has absolutely no effect. The bit about naming similar variables this way is more helpful starting with reading the data initially and making sure that all the variables of the same group are of the same time. Then analysis or manipulation goes quicker.

Re: How to order a column in a proc freq table by a different variable not being directly analyzed?

ballardw — Sat, 18 Apr 2026 05:23:34 GMT

If you provide some example data in the form of a working data set you might get working code.

One way would be to use Proc Format to create a custom format for the county code variable and apply the format to the code variable in proc freq.

Here is a brief example:

Proc format;
value county_code
1 = 'A'
2 = 'B'
5 = 'C'
4 = 'D'
3 = 'E'
6 = 'F'
;
run;

data example;
  input County_code yes_no $;
datalines;
1 Yes
1 No
3 Yes
5 No
5 Yes
2 Yes
6 No
;

Proc freq data=example;
   table county_code*yes_no;
   format county_code county_code. ;
run;

I didn't bother to put the county name variable in the example data set because the code value is all that is needed.

The format name does not have to be the same as the variable it just makes it easier to keep track of. Note the use of the period at the end of the format name in the format statement. That is how SAS knows that is the format and not a variable.

Formats are a very powerful tool because additional formats can be used with the same data set and variable to get different analysis. For example with something like a county code variable I could create a format that assigns the codes to something like geographic management regions, my state has 6 or 7 depending on whether you are working with Public Health Districts or Education regions for example. Or by some other characteristic such as population size group or density, mean income or just about anything. Then the only change to an analysis is using the format. Proc format can use a data set with codes and such descriptions as well to avoid writing a lot of code such as for Texas which has over 250 counties.

If the codes are character and not numeric the format name in the proc format code needs be prefaced with a $ and when used in a format statement. This is needed because you could have separate formats for a numeric and character values.

Re: GPLOT: Graphing Title, label text not visible after WPS version upgrade

ballardw — Fri, 17 Apr 2026 10:33:50 GMT

I would suggest using one of the SAS supplied data sets such as SASHELP.CLASS or SASHELP.CARS with Proc Gplot using similar options that demonstrates the same behavior. Then show us the complete code from that example.

That way things like the incomplete AXIS1 and LEGEND1 definitions, missing a semicolons, would be addressed and removed as possible sources of a problem.

Also it very often more useful to see the LOG with the notes and any warnings or errors involved with the code.

For example, with your current code shown with the Axis and Legend statements incomplete then possibly the current code did not replace a previous file because Proc Gplot would not actually run with the shown code. The LOG would clear that up. Copy the text from the log, on the forum open a text box using the </> icon above the message window and paste the copied text. The text box preserved formatting that would be removed in the main message window.

Here is an example LOG based on your posted code modified to use a set that exists on my system and a plot statement. Note the syntax errors thrown by the incomplete statements.

21   AXIS1  LABEL = ("test label")
22   LEGEND1 LABEL=("TEST LABEL")
     -------
     22
     202
23           SHAPE=BAR(10pt,10pt)
             -----
             22
             76
ERROR 22-322: Syntax error, expecting one of the following: ;, ',', COLOR,
              INTERVAL, LABEL, LENGTH, LOGBASE, LOGSTYLE, MAJOR, MINOR,
              NOBRACKETS, NOPLANE, NOSTAGGER, OFFSET, ORDER, ORIGIN, REF,
              REFLABEL, SPLIT, STAGGER, STYLE, VALUE, WIDTH.
ERROR 202-322: The option or parameter is not recognized and will be
               ignored.
ERROR 76-322: Syntax error, statement will be ignored.
24   PROC GPLOT DATA=sashelp.class ;
25   TITLE1 "test title";
26        plot height*weight
          ----
          180
ERROR 180-322: Statement is not valid or it is used out of proper order.
27        FRAME
28        LEGEND=LEGEND1
29        HAXIS=AXIS1;

30   RUN ;
31   quit;

Is the image you show as created by SAS or after import into WPS? From your description it seems like you had a process working that changed when your client changed their software. Or did your data change making the graph appear different in the SAS created file?

You may also want to run Proc GDEVICE to get a listing of the current settings of your GIF device driver. It might be that something modified that driver.

Code using the default location of the SAS/Graph devices:

  Proc gdevice nofs catalog= sashelp.devices ;
    list gif;
   run;

and likely result:

GDEVICE procedure                                                          
Listing from SASHELP.DEVICES - Entry GIF                                   
                                                                           
  Orig Driver: GIF                Module:   SASGDDMX  Model:    19999      
  Description: GIF Universal Printer                       Type: PRINTER   
  *** Institute-supplied ***                                               
  Lrows:  43  Xmax:   8.333 IN    Hsize:    0.000 IN  Xpixels:        800  
  Lcols:  88  Ymax:   6.250 IN    Vsize:    0.000 IN  Ypixels:        600  
  Prows:   0                      Horigin:  0.000 IN                       
  Pcols:   0                      Vorigin:  0.000 IN                       
  Aspect:   0.000                 Rotate:                                  
  Driver query: Y                 Queued messages: N                       
                                  Paperfeed:   0.000 IN                    
                                                                           
                                                                           
  OPTIONS                                                                  
                                                                           
  Erase:                   Autofeed:                Chartype:    0         
  Swap:                    Cell:                    Maxcolors:17E6         
  Autocopy:                Characters:              Repaint:     0         
  Handshake:               Circlearc:               Gcopies:     0         
                           Dash:                    Gsize:       0         
  Prompt - startup:        Fill:                    Speed:       0         
         end graph:        Piefill:                 Fillinc:     0         
         mount pen:        Polyfill:                Maxpoly:  3000         
         chg paper:        Symbol:                  Lfactor:     0         
                           Pensort:       N                                
  Promptchars:  '000A010D05000000'X                                        
  Rectfill:     '8000800000000000'X                                        
  Dashline:     'FFFFFFFFFFFC0000'X                                        
  Devopts:      'DDC3A0C809E823C8'X                                        
  UCC:      '0021010A000004010A0000040000000000010001'X                    
                                                                           
  Cback:      WHITE                                                        
  Color list:                                                              
                                                                           
    BLACK          RED            GREEN          BLUE           CYAN       
    MAGENTA        GRAY           PINK           ORANGE         BROWN      
    YELLOW         BISQUE         CORAL          LIME           MAROON     
    DARKGRAY       DEEPPINK       DIMGRAY        NAVY           OLIVE      
    PERU           PLUM           GOLD           THISTLE        HOTPINK    
    INDIGO         KHAKI          LAVENDER       PURPLE         SIENNA     
    SILVER         SKYBLUE        TAN            TEAL           TOMATO     
    VIOLET         WHEAT                                                   
                                                                           
  CHARTYPE RECORDS                                                         
                                                                           
  Chartype Rows  Cols                  Font Name                 Scalable  
       0      1     1   <MTmonospace>                                Y     
                                                                           
  FILE INFORMATION                                                         
                                                                           
  Gaccess:                                                                 
  Gsfname:                        Gsfmode:  REPLACE   Gsflen:       0      
  Trantab:                        Devmap:                                  
  Devtype:    GTERM                                                        
  Gprotocol:                                                               
  Fileclose:  DRIVERTERM                                                   
  Hostspec:                                                                
                                                                           
  HOST INFORMATION

It has been a long time since I played with the Graph devices but this may provide some help.

Re: Sas Program Ods excel options

ballardw — Thu, 16 Apr 2026 06:29:52 GMT

You would need one or more procedures that write output such as Proc Print, Proc Report, a data step with the correct options, a modeling proc, something.

Then there would have to be an ODS EXCEL CLOSE; after the procedures so SAS knows when you are done writing to the file.

Re: ERROR: All variables in array list must be the same type

ballardw — Thu, 16 Apr 2026 06:25:36 GMT

I am going to throw in a style choice that your or your office is made that is making you write more code than is needed for array processing.

By placing the interval measures of 0, 3, 7 (or others) in the middle of the variable name you keep yourself from using the variable list features of SAS.

If the variables were named for example FruitWt_Day0, FruitWt_Day3 and Fruitwt_Day7 you could write the ARRAY statement as:

Array _FruitWt (*) Fruitwt: ;

The colon immediately after FruitWt tells SAS to use all the variables whose names start with Fruitwt. Or if you have other such variables then use Fruitwt_Day: to get only those suffixed with Day.

Have you actually run Proc Contents yet? Or opened the data set and examined ALL the variables used in those array statements? Or actually closely read the LOG? That particular error will only appear immediately after the statement causing the error. Se this example from my log.

187  data junk;
188    set sashelp.class;
189    Array x (*) Name sex height;
ERROR: All variables in array list must be the same type, i.e., all
       numeric or character.
190    array y (*) age height weight;
191  run;

So be reading the log I can tell that one of the variables referenced on the Array X statement has a problem. So it is one of Name Sex or Height. The first two are character and the third is numeric.

As shown by this from Proc Contents:

Alphabetic List of Variables and Attributes
#	Variable	Type	Len
3	Age	Num	8
4	Height	Num	8
1	Name	Char	8
2	Sex	Char	1
5	Weight	Num	8

Re: Format character variables based on their own value

ballardw — Thu, 16 Apr 2026 06:07:49 GMT

I agree with @Tom that several details are missing.

Your bit here:

@NewUsrStat wrote:

...

Moreover the format the variables will take is exactly their value like for example proc format ... "Chemotherapy" = "Chemotherapy" "Transplant" = "Transplant", ....

If you have a data set of values that you expect to encounter you can use that data to make a CNTLIN data set for Proc format. Here is an example using the SASHELP.CLASS data set that you should have.

/* select all the males from the data set and create
a format that will show that text as the label and "Other"
for the females
*/
data example_cntlin;
/* the END = option is to allow conditional creation
of the OTHER statement options as the last entry of the format*/
   set sashelp.class (where=(sex='M')) end=lastone;
   /* key variables that a Proc Format CNTLIN requires are
   Fmtname start (end if there is range of values) label 
   type, C for character here, and since we want to use the 
   OTHER option the HLO variable which may contain other things
   */
   fmtname='F_to_other';
   start=name;
   label=name;
   type='C';
   output;
   if lastone then do;
       /* that is a capital O not a zero*/
       hlo='O';
       /* special text for the Start/end values with Other*/
       start='**OTHER**';
       label='Other';
       output;
   end;
   drop name sex age height weight;
run;

/* use the data set to create the format*/
proc format cntlin=example_cntlin;
run;

/* demonstrate how to use the format created*/
proc print data=sashelp.class noobs;
var name;
format name $F_to_other.;
run;

If you have any questions about what special values in which special variables used by Proc Format for a CNTLIN data set it is pretty easy if you know the options you need. Write a very small Proc format step with the options you need be they ranges, invalues (informats) or whatever. Add on the Proc Format statement the option CNTLOUT=somedataset. The procedure will create a data set with the variables needed and the options.

Caveat: If you have multiple variables in in a single data set that you want to work with you must make sure that the final data set is sorted by the FMTNAME variable as otherwise Proc Format will create and overwrite a bunch of basically one value versions of the formats. It might be best to create one CNTLIN data set per set of values/variable for simplicity sake. Keep the sets in a permanent library. Suggest also writing the Formats to a permanent library using the LIBRARY= option and then adding that library to the FMTSEARCH path so you don't have to recreate the formats each session.

If your clinicians are anything like the ones I worked with you may need to make sure that the spelling is consistent because a value of "Xyz" the format is looking for will not match "xyz". I often fixed that by creating custom informats that used the UPCASE option that would treat all the text as uppercase before comparing to value on the informat and assigning the proper expected values.

Something like this:

Proc format;
   invalue $sometext (upcase)
   'ABC'='Abc'
   'PDQ'='Pdq'
   'JACK DANIELS' = 'Jack Daniels'
   other=_same_;
run;

data example;
  input text $sometext.;
datalines;
abc
abC
ABc
pdq
somethiing
else
;

The CNTLOUT option would show where the UPCASE gets set in the control data set.

Note the use of _SAME_ to copy any unexpected text.

The CNTLIN data set would want the START value to be all uppercase.

If you have known supposedly fixed set of values, such as Clinic names, you could use the _ERROR_ option in the INVALUE to throw an error when an unexpected value gets entered into a data set so the LOG would throw invalid data messages. If you find that one of your clinicians abbreviates or misspells a value consistently you could add that to the Invalue as format has not problems taking multiple input values to the same output.

I used this frequently because one of our contractors would "update" their data system so that things that had been established to report a value as M or F for female would do things such as spell the word out or add a / and the Spanish equivalent. I could modify my informats to accommodate such and keep the original correct values in our data.

I always thought Proc Format was one the hidden gems of data management as long a single variables were involved.

Re: import XPT file into SAS OnDemand Studio

ballardw — Mon, 13 Apr 2026 17:02:15 GMT

@Ok6 wrote:
Thanks but error persists.

Best practice for this forum is to show the code and any messages from the log. Copy the text from the log starting with the code statements submitted that are having an issue through the end of all of the messages associated with the code. On the forum open a text box using the </> icon that appears above the message window and paste the copied text.

The text box is important because the software running the forum will reformat text pasted into the main message window that sometimes reduces the readability or completeness of the diagnostics that SAS often supplies.

In the case of "file doesn't exist" type messages common problems are spelling , case of text, actual location of the file such as attempting to use a local to your computer file where the server running SAS cannot see it. If you show the actual code and messages we can help better. Also, it would be better to start your own thread instead of adding to an older thread. The creator of the thread has options available such as marking an answer correct that others do not. If you do start your own thread you can post a link to this one to reference what has been done so far.

Re: Apply "at least" condition in data step

ballardw — Tue, 07 Apr 2026 10:52:52 GMT

Since it sounds like you need to mark multiple observations (not specified how) it would likely take two or possibly more passes depending on other rules using a data step.

I can come up with at least two different meanings for " flag IDs not in (1st line) that have at least one "Other_trt" entry = "Y". " It would be a good idea to show the desired result to make sure any interpretation we use would be correct for the problem as well as showing the value(s) of any flags set.

Note that there quite a few places where using a numeric 1/0 instead of text Y/N or True/False are much easier to deal with. For example, SAS treats numeric 1 as True or Yes and 0 as False or No so you can SUM a number of values and get the count of Yes values. And the result of a comparison is returned as 1/0 so you don't have to add in logic to assign Y/N. A format can display the text value of "Y" or "N" or other text as desired for reporting for people to read.

If this were my problem I would likely use a separate step with either Proc SQL or possibly Proc Freq to get the desired counts of Other_trt values and merge that result with the DB data set by ID values to add in that Flag.

Re: Help with SAS Macros

ballardw — Sun, 05 Apr 2026 23:33:40 GMT

The warning is coming because you have a value of your macro variable College_id of "A&S" in this line:

proc export data=caa.usf_college_sort(where=(college=%bquote("&college_id"))

I am not sure that the picture of the log that you show actually represents a run from the code shown. There is a bit of text in the picture that reads: " MPRINT (CAGOAL) : WXLX; " just before the Run statement for the Proc Export. There is nothing that you show in the CODE that would generate any such.

So perhaps you have a timing issue of the shown log and the code executed where this picture is from a previous run OR the macro wasn't recompiled after a change.

I might suggest closing SAS and restarting and then running the code, possibly with a reduced input data set to just include the A&S. If you still get the warning then show us the entire log, pasted into a text box just like the code was, including where the macro is compiled. The suggestion of a reduced input data set is to reduce the amount of log needed.

Re: Import Data from Excel - DateTime column has mixed values

ballardw — Sun, 05 Apr 2026 17:21:51 GMT

@Kurt_Bremser wrote:

Save to a CSV file and read that with a DATA step. Both the "real" and character datetime values will appear in the same format, so you can read them with the E8601DT informat.

Disclaimer: I tested the "save to csv" with LibreOffice on a Mac, but I sincerely hope MS Excel will do the same.

Used to have to do this about once a week with my last job and Excel save to CSV usually worked except in the pathological cases of one data source that would have a column with cells that were formatted in Excel as currency for part of the column and then dates for the remainder. In which case the solution was to set the entire column of the Excel source to the proper appearance before exporting to CSV.

Re: SAS Studio (OnDemand for Academics) ODS Error after trying to running Macro??!! Can't print anyt

ballardw — Fri, 03 Apr 2026 18:29:43 GMT

Where is the Macro related code that you ran? I don't see any.

If you are setting the NONOTES and NOSOURCE options then you will lose much of the diagnostic information needed to resolve issues that may be causing problems.

The note about the quoted string in the following indicates that somewhere prior you would likely have had a mismatched quote and the code parser isn't processing things as you think they are.

 1          OPTIONS NONOTES NOSTIMER NOSOURCE NOSYNTAXCHECK;
 2          TITLE;
 NOTE: The quoted string currently being processed has become more than 262 bytes long.  You might have unbalanced quotation marks.

In addition to using options NOTES and SOURCE for debugging you may want to add the option MPRINT show the code actually generated by macros. If you are doing moderately complex macro variable manipulation then SYMBOLGEN is a good option to add and if there are issues with macro logic, i.e. %if that misbehave, add MLOGIC to the options before running macro code.

Re: I'm trying to get BRFSS data into SAS. When I try to import , it says data is invalid

ballardw — Mon, 30 Mar 2026 16:37:27 GMT

Did you download zip files of text or of SAS data sets? I think that if the file contains SAS data sets then unzip and create a library pointing to the folder where the files were unzipped would work.

If the zip contains text files to read then unzip and use the programs to read the files that were likely at the location you downloaded the data sets.

Re: gmap version of maps.counties that uses Connecticut planning regions instead of counties

ballardw — Wed, 25 Mar 2026 20:24:40 GMT

Remember to create a library other than work to store the resulting imported data set or you will have to re-import the data.

Re: Data step on many files with unique names and different variables

ballardw — Wed, 18 Mar 2026 20:10:41 GMT

@NewUsrStat wrote:
I really do not know because only the catalogue was passed to me and the instructions you read were given. I have no access to other codes.

There is a step that you may want to add to this process. SAS Catalogs are usually version dependent. That means that it is possible that an upgrade to SAS will make the current catalog unreadable. Once you have that catalog responding to the FMTSEARCH option you may want to us Proc format to create a data set of the format definitions using the CNTLOUT option. Then at a later date you can rebuild the catalog for a different version using Proc Format and the CNTLIN option pointing to that data set. Having the data set may also be helpful to answer questions about the actual behavior of the formats.

Proc format library=somelib cntlout=alib.formatcontrol;
run;

For example will read the catalog named FORMATS, the default name for a format catalog, in the library that has been defined on your system as Somelib and write the contents to a data set named Formatcontrol in the library defined on your system named Alib. You likely want to write the data set into library other than work for later use. The exact library is up to you.

To recreate the formats use:

proc format library=thatlib cntlin=alib.formatcontrol;
run;

The above code will create the formats in the library named Thatlib, which would need to be added to the FMTSEARCH path to be usable.

Suggestion: I would provide such a control data set and the proc format code instead of catalogs. That way things like operation system dependencies and versions are minimized.

Re: PROC HTTP to access Census Trade data

ballardw — Wed, 18 Mar 2026 19:53:51 GMT

Best practice on this forum is to show us the LOG generated when submitting the code. The exact wording of error or warning messages is important as they often include important clues as to possible solutions.

I suggest that you re-run the code and if the issue persists to copy from the log the code and all messages related to proc http. On the forum open a text box using the </> icon that appears above the message window and paste the copied text.

You don't show a definition for the OUT=resp. Somewhere prior to this you should have a Filename statement creating a reference to a file that the "get" will write to for later processing.

Re: Different ADF test results between SAS and Python

ballardw — Wed, 18 Mar 2026 07:59:50 GMT

Generic question gets a generic response: differences arise from different details in the programming and often the machines the code executes on. Things like number of decimal places maintained internally for computations can easily effect results even when using the same algorithms and just because a statistical test has the same name in different packages there is very likely no commonality at all points in the way the algorithm was programmed.

HOW much difference might be the question that you need an answer to. So perhaps sharing the results in question is place to start.

Also some programs will report the results using different defaults. For instance in a logistic regression with a true/false type outcome one program may default to modeling the "true" value and the other the "false". So same data would tend to report something that looks like a compliment of the other (70% true or 30% false for example).

For serious details you might need to include:

Your data

Your Code for both approaces

The output

The research you question you want answered so we can validate that the SAS (at least) approach is using appropriate options.

Some of the SAS procedures will have a section in the online help called details that may include some of the computation details.

Re: SAS runs slower with each macro call simulated power

ballardw — Tue, 17 Mar 2026 15:26:01 GMT

Are you sure that what you are attempting to get power is not available in Proc Power? Or maybe Proc GLMPower? These procedures have options that let you set multiple things like multiple power and generate needed size N or vice versa.

Are you sending Proc Freq output to the default display? As that gets more output then just doing the display refresh may be part of the issue. I would suggest turning off the display using the Proc Freq NOPRINT option and generate data sets from Proc Freq with the desired output.

It may help to post the code of the macro so we don't have to ask a bunch of "do you have this option enabled/disabled" questions.

Re: How do I obtain frequencies with multiply imputed data using PROC MIANALYZE?

ballardw — Mon, 16 Mar 2026 20:49:26 GMT

What exactly does " I cannot get the PROC MIANALYZE to work" mean? Do you get errors, unexpected output, no output?

It is more useful to post the LOG with any messages generated and the code as the messages often provide details as to what is happening. Copy the step or procedures in question from the log, on the forum open a text box using the </> icon that appears above the main message window and paste the text in the box. The box will preserve the formatting from the log.

Re: Retain leading/trailing spaces while exporting SAS dataset to flat files

ballardw — Sat, 14 Mar 2026 12:49:40 GMT

You will want to repost your examples, input and output both, into a TEXT box on the forum. Open a text box by clicking on the </> icon that appears above the main message window and paste the text. The software of the forum mean that the main message windows will reformat pasted text and replace white space characters which means that we will not see what you want if the examples are pasted into the main message window.

Re: Tick value collision policy in GTL

ballardw — Wed, 11 Mar 2026 02:50:43 GMT

One think you might consider given your example list of tickmarks without any details of the data might be to use a LOG type axis which would change the spacing between the ticks.

SOME value of TICKVALUEFITPOLICY will always be in effect. If you don't specify then you get the default behavior will is going to do what you describe. Maybe using a TICKVALUEFITPOLICY of Rotate or RotateAlways coupled with TICKVALUEROTATION=Vertical , which is going to minimize the width of values displayed on the X axis would reduce the amount of work to select specific values that don't get thinned.

In general the larger the value required to display the less space between integer values.

One way to prevent thinning is to use the range of values in your data, or the plotted subset of the data and do the calculations yourself before setting the value list.

I will give you a simplified version of something I had to do back in the days of SAS 6.08 and early SAS/Graph.

I had data that was read from telemetry daily. Some of the data represented the height of the water column in a rain gauge. The data read was actually a cumulative file, i.e. on one day the file held roughly 24 hours of data, the next day about 48, next 72 and so on until about a weeks worth of data was collected then the loggers were reset. The nature of the rain gauges meant there could be noticeable changes either increases, from precipitation or bugs and birds getting into the buckets, or decreases, when serviced. So the daily graphs that I prepared had to be prepared to deal with as little as 0 change for the 7 day period or as much as spike increases of 15 inches when birds got into the buckets.

I wrote code that examined the range of values for the period and if the value was large enough wrote code to subset the graphs with specified 2 inch ranges of the y axis, each with it's own value list. The 2 inch range per graph was to make sure that we could see the behavior of the column when drastic things weren't happening. If we allowed the whole range to appear as the default then the spikes would make the more typical readings appear flat. I'm sure you have encountered something similar with some data.

Also, you want to determine if the Tick marks are clashing or the Tick Labels. Quite often it is the Label that has an issue and use the options to rotate the text, reduce the size of the text and stagger the text appearance will reduce the conflicts for numbers in the range you show. If using time or date values, a common cause of text long enough to collide then use of a different Format might be in order .

There are enough interactions between the ODS Style, your overrides of style such as text size or font, type of graph template layout (overlay lattice datalattice overlayequated), axis type (discrete log linear time) that just dropping bits of your template can be quite insufficient to tell what will happen.

Look at your LABELFITPOLICY and LABEL POSITION option defaults or settings