@LukeDalton - We use full folder paths for our Git repository directories by creating a macro variable that points to the required repo's root directory, then use that macro variable in all subfolder path definitions. Changing to a different repo is as easy as changing the root directory macro variable.   We find that works reliably and transparently for us as long as you are disciplined about using that macro variable. The problem with relative paths is where is the starting directory? If could be a user directory or it could be the folder where your SAS executable is depending on how your SAS installation is configured. ... View more

@Wolverine - I get the impression you are using EG for both running Production jobs where you want to keep SAS logs and also for program development and analytics. If this is the case then an alternative approach could be to move the running of your Production jobs to SAS Management Console. Not only can they be automated with Schedule Manager, SAS logs are produced and saved automatically. Not only that you can trigger automatic emails if the jobs fail so you only need to look at SAS logs if you get an email. We use this approach and it works a treat.   ... View more

@Somu - Thanks for sharing more details of your migration practices. Of course there are many ways of dealing with this depending on your business requirements and IT infrastructure.   In our case it is essential to be able to run the same applications in both our source and target installations in parallel and to check that we get the same results, right down to key datasets being identical or not materially different. That's why we have near real time data transfers and code synchronization.   ... View more

@touwen_k  - Run some tests on your typical datasets using both CHAR and BINARY and compare the compression percentage. Go with the one that provides the highest compression. Compression works in Viya.     ... View more

Did you save it as a UTF-8 CSV to begin with?   Otherwise using the ENCODING option is unlikely to work.     ... View more

@CarleighJoC - This is a timely article! As a SAS administrator I ensure that COMPRESS = BINARY is set by default in all our SAS installations so users don't need to switch it on. Due to the proliferation of external databases defining many columns as strings or large varchars, reading these in SAS can cause massive space blowouts so you really need settings in place to deal with this.  ... View more

When I googled your error I got the following AI response:   ... View more

It's common practice to define Authentication Domains entirely in SAS 9.4 metadata, which is what we have done with our Snowflake connections. Access to SAS metadata is password-restricted and opening Auth Domain user credentials in SAS Management Console just gives you asterisks: IMHO this is at least as secure as the method you suggest as long as the metadata access password is kept secure.   ... View more

You will need to provide more details on whether this relates to SAS 9.4 or SAS Viya and to which SAS scheduler you are referring to. It is entirely possible that scheduled reports could be distributed using SAS code in which case analysing your code and application data are your only options for identifying recipients.   ... View more

SAS server installations include many tools, not just Enterprise Guide. One of those is a web interface called SAS Environment Manager, a dashboard that monitors CPU, memory and disk space collectively across all SAS users.   Also if you are looking to upgrade your SAS installation hardware and probably software, then I highly recommend seeking expert advice. SAS provide a free SAS server sizing service which is most likely available through your SAS Account Manager. ... View more

I'm guessing that your table counts macro uses PROC SQL. If this is the case adding NOPRINT on your PROC SQL statement should stop the LST files being written in the first place. ... View more

@Somu  - My best practice recommendations are as I've stated above. IMHO not having direct connectivity between your source and target installations is problematic and seriously restricts your migration options. How will you transfer programs and data between your installations? ... View more

We are going through a similar SAS upgrade and migration project ourselves currently. Ours is SAS 9.4M2 to SAS 9.4M8 however.   In my experience it is essential to have a full-time network connection between your source and target SAS installations so you can do incremental SAS content updates as well as being able to do parallel runs to confirm and source and target processes produce the same results.   We use SAS/CONNECT and SAS procedures like SAS DATASETS for SAS data migration as it can handle encoding differences. Third party tools can't do this.   We also use our version control tools for migrating SAS programs, namely MS Visual Studio and MS DevOps. We have automated pipelines in DevOps deploying to both source and target SAS installation file systems. This ensures that we keep code bases in sync and ensure we can track any necessary changes required to run the same code on both source and target installations. Given you have 24K programs I suspect there will be an extended period of parallel running while you complete and test your migration. Use of version control tools is the best way of managing this.   I highly recommend trying to keep your source and target installation code as similar as possible while migrating so you can easily test and confirm it produces the same results. Once your migration is complete, then you can start to make greater use of Viya functionality.   In my experience SPK exports should be just about the existing SAS 9.4 metadata migration. It isn't designed for moving 24K SAS programs!  ... View more