Quentin Tracker

Re: Downloading a directory of *.sas files

Quentin — Wed, 22 Jul 2026 14:08:40 GMT

Edit: My thinking below is wrong. After reading Tom's post, I now see the error message is about writing Batchfile 7.6.zip, not reading Batchfile 7.6.sas (which likely does not exist).

It looks to me like the OS doesn't want to write the zip file to the same directory you are currently reading from. So Tom's suggestion to write it somewhere else makes sense to me:

filename out zip '/home/u44673568/Batchfile 7.6.zip';

____

So you have a file named Batchfile 7.6.sas in:

/home/u44673568/Meteor Analysis and Data/Camera Network Optimization/NMMA OptModel/OptModel4GMN/Batchfile 7.6

Is that correct?

It looks like SAS is finding the file, when it runs DREAD on the directory, but the INPUT statement can't read the file.

Check the permissions on the file itself:

ls -l /home/u44673568/Meteor Analysis and Data/Camera Network Optimization/NMMA OptModel/OptModel4GMN/Batchfile 7.6/Batchfile 7.6.sas

I think that will show that your SAS job does not have read access to the file itself. If so, you can use CHMOD to change the permissions (assuming you own the file).

Re: Connecting SAS to Snowflake via ODBC using SSO from external browser

Quentin — Thu, 16 Jul 2026 12:56:05 GMT

Hi, did you make any progress on this?

Re: Proc Python

Quentin — Mon, 13 Jul 2026 13:05:51 GMT

@johatc wrote:

Proc Python is now available for SAS 9.4M9 on the following operating environments:

Windows

Windows for x64

64-bit Enabled AIX

Linux for x64

See KB0046084 The PYTHON procedure is available for SAS® 9.4M9 (TS1M9)

Thanks for this wonderful news!!!

@ChrisHemedinger I know this is an old thread, but is it possible to mark @johatc 's answer as correct? Would be good to have this answer up top for the google searches. This is GREAT news that PROC PYTHON is now available to all.

🎉🎉🎉🎉🎉🎉

Re: Change cstars colors in proc gradar

Quentin — Wed, 08 Jul 2026 21:19:29 GMT

I found a new use-case for AI programming with SAS.

Since you didn't provide data, I showed it a picture of your chart, and your SAS code, and it generated sample data:

data longnew;
  length DM_range $10 texture_label $20;
  input DM_range $ texture_order texture_label $ texture_value;
  datalines;
15_20 1 Creamy 18
15_20 2 Dry 13
15_20 3 Mushy 19
15_20 4 None 5
15_20 5 Smooth 12
15_20 6 Stringy 8
15_20 7 Watery 25
20_25 1 Creamy 15
20_25 2 Dry 6
20_25 3 Mushy 20
20_25 4 None 5
20_25 5 Smooth 26
20_25 6 Stringy 8
20_25 7 Watery 20
25_30 1 Creamy 12
25_30 2 Dry 7
25_30 3 Mushy 20
25_30 4 None 5
25_30 5 Smooth 18
25_30 6 Stringy 8
25_30 7 Watery 30
30_35 1 Creamy 8
30_35 2 Dry 8
30_35 3 Mushy 20
30_35 4 None 5
30_35 5 Smooth 13
30_35 6 Stringy 10
30_35 7 Watery 36
<15 1 Creamy 10
<15 2 Dry 24
<15 3 Mushy 20
<15 4 None 5
<15 5 Smooth 10
<15 6 Stringy 6
<15 7 Watery 25
;
run;

And also generated this GRADAR step, which lists 5 values for cstars and wstars. Your code only has two:

footnote1 j=c h=10pt 'N = 502';
title1 j=c h=13pt 'Comparison of textures by DM range for BL516 (relative %)';

proc gradar data=longnew;
  chart texture_label / freq=texture_value
    overlay=DM_range
    starcircles=(25 50)
    cstarcircles=black
    cstars=(aqua red green brown purple)  /*updated*/
    wstars=(2 2 2 2 2)   /*updated*/
    cframe=white
  ;
run;
quit;

Re: Loading SAS Data with Formats to Object Storage Parquet

Quentin — Wed, 08 Jul 2026 13:10:29 GMT

I don't think you can get it to work in 9.4 without external tools (python etc), unfortunately. I thought I head at SAS Innovate a couple years ago that the Duck DB engine would come to 9.4, but, sadly, apparently this is not the case: https://communities.sas.com/t5/SAS-Data-Management/SAS-Connection-to-Duckdb/td-p/949322 .

That said, PROC PYTHON is coming to 9.4M10 (https://communities.sas.com/t5/SAS-Innovate-Presentations/SAS-9-4-M10-Continuing-Support-and-Roadmap-in-the-Era-of-Viya/ta-p/988049 ) so that should provide a way to read Parquet, and lots of other stuff, without leaving your SAS session. You can probably do it now in earlier maintenance releases using PROC FCMP interface to python.

Re: ods excel file

Quentin — Thu, 02 Jul 2026 20:52:54 GMT

This is not how I would recommend structuring the code, there are better ways to solve this problem.

But as I had 15 minutes before leaving for a holiday weekend, and I was enthralled by the Italian, I took your code, simplified it a bit, and made some test data.

The below code I think does what you would want. You can see I pulled the ODS Excel statement outside of the loop, and made a few other changes.

You can play with this, or with this working example, someone else will write a better-designed macro solution for you. This is a common macro problem: read in a control dataset with a list of datasets, and print each dataset.

*make some test data;

data ADDEBITI ;
  set sashelp.class ;
run ;

data POLIZZE ;
  set sashelp.shoes ;
run ;


*control dataset with list of datasets to print;
data Riepilogo_righe_2 ;
  TABELLA='ADDEBITI' ; DIREZIONE='class' ; output ;
  TABELLA='POLIZZE' ; DIREZIONE='shoes' ; output ;
run ;
  

%macro multiple (DATA=,);
  /* Conta quante tabelle ci sono */
  proc sql noprint;
    select count(*) into :ntot
    from Riepilogo_righe_2;
  quit;

  ods excel file="%sysfunc(pathname(work))/foo.xlsx"   ;

  %do i = 1 %to &ntot.;

    /* Prende il nome della tabella i-esima */
    proc sql noprint;
      select LEFT(trim(TABELLA)), LEFT(trim(DIREZIONE)) 
      into :nome, :des 

      from Riepilogo_righe_2
      where monotonic() = &i ;
    quit;

    %put &nome.; 
    %PUT &NTOT.;
    %put &DES.;

    %if %sysfunc(find(&nome, ADDEBITI, i)) > 0 %then %do;
      %put Condition 1 is met;
      /* Add your SAS statements here */


      ods excel options( 
        sheet_name='Addebiti'
      );

      proc print data=&nome.;
      run;
    %end;

    %else %if %sysfunc(find(&nome, POLIZZE, i)) > 0 %then %do;
        %put Condition 2 is met;
        /* Add different statements here */

      ods excel options(
        sheet_name='Polizze'
      );

      proc print data=&nome. ;
      run;

    %end;

    %else %do;
        %put No conditions were met;
    %end;

  %END;

  ods _all_ close ;	

%mend multiple;

%multiple()

SAS Viya Copilot Public Chat Interface

Quentin — Thu, 02 Jul 2026 18:41:17 GMT

SAS Viya Copilot sounds amazing and there is tremendous value in having it integrated into different SAS IDEs / applications.

I think there would also be value in exposing SAS Viya Copilot via a public (free) web chat interface. This would be an opportunity for people who don't have Viya to see how smart Viya Copilot is at debugging SAS code and generating SAS code.

Obviously a chat interface would not be that useful for production use, where you want it to have access to your full code base, etc. But I'm sure talking SAS with SAS Viya Copilot would be an even better experience than talking SAS with Chat GPT or Claude. It would serve as a public advertisement for how great Viya Copilot is, and entice more users to advocate for Viya adoption.

Re: ods excel file

Quentin — Thu, 02 Jul 2026 17:41:36 GMT

Can you please post the log from running the code?

Also please describe the problem you're having. Are there errors in the log? Is the Excel output created but something is wrong about it?

Re: PROC DOCUMENT

Quentin — Thu, 02 Jul 2026 16:31:37 GMT

Glad you found a solution. Curious if you try the AI's code if it will work (even if not optimal for your call execute solution).

I'm using GitHub Copilot in VS code with the SAS Extension. GitHub Copilot automatically picks an LLM. Looks like it used GPT-5.4 mini for my questions.

When I have test data, it will actually write a program, then ask if it can batch submit it. If I say yes, it will run the program, then check the log for errors, and iterate until it gets fixed. Crazy stuff!

Re: PROC DOCUMENT

Quentin — Thu, 02 Jul 2026 13:07:21 GMT

I don't know PROC DOCUMENT well, but I've been playing with AI for SAS coding, so please take below suggestions with a large grain of salt.

AI points to a small typo in your code. This line has a leading backslash you don't want:

SETLABEL \site1\group2\fut1_2 "Future";

but that's probably not the cause of the problem. AI also claims:

That behavior is consistent with PROC DOCUMENT building the tree top-down and resolving paths as it goes. When COPY \work.overview1\Print#1\Print#1 to site1; runs at the top, SAS is touching site1 before the rest of the site1\group1 branch exists. If that copied object changes the current document context or occupies site1 as a node in a way SAS doesn’t expect, later MAKE site1\group1; can be seen as an invalid path. When you move the COPY to the bottom, the full site1 subtree already exists, so the copy lands in a valid destination and the error disappears.

The safe pattern here is: create all parent nodes first with MAKE, then do the COPYs, then SETLABELs. If you want, I can rewrite the block into a clean order that avoids this class of PROC DOCUMENT path errors.

And it then rewrote the code to:

proc document name=work.forreplay(write);

  /* Site 1 */
  make site1;
  setlabel site1 "Site: 1";

  /* Group 1 */
  make site1\group1;
  setlabel site1\group1 "Group 1";

  make site1\group1\past1_1;
  setlabel site1\group1\past1_1 "Past";

  make site1\group1\pres1_1;
  setlabel site1\group1\pres1_1 "Present";

  make site1\group1\fut1_1;
  setlabel site1\group1\fut1_1 "Future";

  /* Group 2 */
  make site1\group2;
  setlabel site1\group2 "Group 2";

  make site1\group2\past1_2;
  setlabel site1\group2\past1_2 "Past";

  make site1\group2\pres1_2;
  setlabel site1\group2\pres1_2 "Present";

  make site1\group2\fut1_2;
  setlabel site1\group2\fut1_2 "Future";

  /* Site 2 */
  make site2;
  setlabel site2 "Site: 2";

  /* Group 3 */
  make site2\group1;
  setlabel site2\group1 "Group 3";

  make site2\group1\past2_1;
  setlabel site2\group1\past2_1 "Past";

  make site2\group1\pres2_1;
  setlabel site2\group1\pres2_1 "Present";

  make site2\group1\fut2_1;
  setlabel site2\group1\fut2_1 "Future";

  /* Copy output objects after the tree exists */
  copy \work.overview1\Print#1\Print#1 to site1;
  copy \work.past1_1\Print#1\Print#1 to site1\group1\past1_1;
  copy \work.pres1_1\Print#1\Print#1 to site1\group1\pres1_1;
  copy \work.fut1_1\Print#1\Print#1 to site1\group1\fut1_1;

  copy \work.past1_2\Print#1\Print#1 to site1\group2\past1_2;
  copy \work.pres1_2\Print#1\Print#1 to site1\group2\pres1_2;
  copy \work.fut1_2\Print#1\Print#1 to site1\group2\fut1_2;

  copy \work.past2_1\Print#1\Print#1 to site2\group1\past2_1;
  copy \work.pres2_1\Print#1\Print#1 to site2\group1\pres2_1;
  copy \work.fut2_1\Print#1\Print#1 to site2\group1\fut2_1;

  run;

ods document close;

It didn't actually run the code (because no test data to create the objects), so definitely could be wrong!

Re: PROC DOCUMENT

Quentin — Thu, 02 Jul 2026 12:39:28 GMT

@SwissC wrote:
Not sure if you see the same but in my view of the page, the code box is not displaying correctly, I did honestly but each line of code on separate lines.

I fixed the code block for you. It's a weird bug in the message interface. Not your fault.

Re: How do I create a data file with specific variables I have computed?

Quentin — Wed, 01 Jul 2026 21:50:23 GMT

@Quentin wrote:

When you say you want the variable s "spit out" you mean you want them included in the output dataset named final?

If so, it looks like you could add them to the keep list here:
data fit(keep=soc crit_typ distance fitval);

You would need to re-compile the macro (submit the code between %macro and %mend) and then call the macro, with the macro call shown at the bottom of your code:

%merge1(cut=30,folder=EAS, client=Dennis test 1, filename=dtest1_jas, var1=battlink, value1=MW, var2=, value2=, clifam1=, clifam2=)

I just noticed there is no %MEND statement in the code you posted. In your real code that should be the bottom of the macro definition.

Re: How do I create a data file with specific variables I have computed?

Quentin — Wed, 01 Jul 2026 18:04:53 GMT

When you say you want the variable s "spit out" you mean you want them included in the output dataset named final?

If so, it looks like you could add them to the keep list here:

data fit(keep=soc crit_typ distance fitval);

Re: Upgraded to VIYA LTS2025.09, now macro code throws an error after 5 years of running.

Quentin — Wed, 01 Jul 2026 16:36:03 GMT

In the code you showed:

%create_state_tab(&next_name);

is definitely calling a macro named create_state_tab.

The question you need to solve is, where is that macro definition stored? It could be in the program you ran, it could be in an autocall library, it could be in a (sigh) compiled macro library that the consultants delivered but don't want you to know what is in it.

First you need to figure out where the macro definition is (should be) and then you can work on figuring out why your current session isn't able to find the definition. Could be something as basic as a different value for the sasautos option. Or maybe a permissions change on the OS.

Re: Update a variable’s value based on the value of another variable

Quentin — Wed, 01 Jul 2026 12:54:13 GMT

You're analyzing a dataset that is actually a report, not data. It's the same problem as your post last week: https://communities.sas.com/t5/New-SAS-User/Add-white-row-before-a-variable-value/m-p/990126#M43967

Do you see any logic you could use to derive have1 from have? I think all you could do is hard code it:

if Class2="Specific_value" then value=5 ;

which is obviously not a solution.

The correct way to create have1 would be to get access to the data that was the source for these counts. Then you can calculate any count you want.

Re: PROC SORT: NODUPKEY - 중복값 제거

Quentin — Tue, 30 Jun 2026 17:24:38 GMT

NODUP, which is and alias for NODUPRECS, has been removed from the documentation but is still useable for backwards compatibility reasons.

Instead of using NODUP, most people recommend using NODUPKEY and sorting BY _ALL_ which can be trusted to give the result that is usually expected.

Re: Capture SQL View Definition for Programmatic Change

Quentin — Mon, 29 Jun 2026 13:50:39 GMT

@Patrick wrote:

@Quentin The views in the target environment must point to the replicated data in the target environment. For this reason they must get re-created.

This environment with replicated production data is then what one can use to create other environment for various Dev & Test purposes and there one can then create links to the replicated data for anything file that doesn't need write access during the Dev or Test activities.

Hope that makes sense.

I think we're talking past each other a bit. I understand the views must be recreated, because views sometimes don't migrate etc. But I think symlinks can help you avoid changing the code that creates the view.

I just played with it, and it worked as I expect. Given a view like you have:

proc sql;
create view test as 
  select * 
  from source.myclass
  using libname source "~/sourcerootpath"
;
quit;

I made a symlink ~/sourcerootpath which points to the target directory. With that setup, I can point the symlink to anywhere on my target server, the view works.

So on your target server, creating a symlink should allow you to avoid updating the view definition to have a different path.

Re: Capture SQL View Definition for Programmatic Change

Quentin — Sat, 27 Jun 2026 21:42:53 GMT

@Patrick wrote:

@Quentin Symlinks are certainly not the solution. A view can be something like select <subset of source columns> from blah.table using libname blah "path to folder". I believe the only way is to re-create the view with a different "path to folder".

Why couldn't symlinks work? I'm assuming on your source server, all your data is sitting buried within one directory tree, e.g.:

/sourcerootpath/Data/Project1/...
/sourcerootpath/Data/Project2/...

And when you copied the files to the target, they went to something like:

/targetrootpath/Data/Project1/...
/targetrootpath/Data/Project2/...

So on the target server, if your created a symlink /sourcerootpath which points to the existing directory /targetrootpath, then all of the original views and code that point to /sourcerootpath would magically work, wouldn't they?

Re: Native conversational LLM chat interface for SAS 9.4 Foundation (SAS Studio / Enterprise Guide)

Quentin — Fri, 26 Jun 2026 18:36:56 GMT

I like this idea, but in a sense SAS has already implemented it. SAS 9 users don't have SAS Viya Copilot. But if you install VS code, and the SAS Extension for VS Code (free, developed by SAS), and Github Copilot, you can connect to tons of LLMs, and ask them to generate code, clean code, even execute code. You get exactly what you want: a persistent chat pane along side your code, that can connect to any LLM. It's definitely worth trying now. VS code can connect to a SAS 9 server or even local PC SAS. I'm sure SAS Viya Copilot is terrific, because it was trained by SAS on SAS. But I'm shocked at how good general LLMs have become at SAS coding. It's day and night vs playing with it a year ago.

p.s. I don't think %Window and %Display are actually macros, but maybe I'm wrong.

Re: Add white row before a variable value

Quentin — Fri, 26 Jun 2026 14:37:10 GMT

Agree, please @NewUsrStat explain why you would want such a dataset. It's clearly a report. Even if you're using this dataset to validate someone else's report, I'm not sure it's a good idea. It's hard for me to come up with a good reason to create this sort of dataset.

If you're truly a New User as your screen name implies, one thing that takes time to learn is that sometimes as a programmer, your boss/statistician/analyst will ask you to do something that makes sense to how they're thinking about the problem, but doesn't make sense to implement that way in SAS. Part of growing into a senior programmer is learning how to identify those issues, and explain/adjust. For example, many analysts want to talk about longitudinal data as if it's in a wide format (one record per patient ID, with score_time1 score_time2 score_time3 etc. It's fine for them to think that way, and sometimes even write requirements that way. They don't need to know or worry that you actually store the data in a vertical format (with variables ID, Time, Score).

I've never worked in pharma (and don't know if you do). But sometimes I feel like pharma programmers often feel stuck programming whatever a spec asks for, instead of interpreting the spec, and suggesting changes to the spec.