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

Yes, there is a product called SAS/ACCESS Interface to ODBC. You can check if you have it installed and licensed by running this: proc product_status; run; proc setinit; run; However SAS/ACCESS Interface to SQL Server should also work. Did the SQL Server LIBNAME assign without errors or not? Please post your SAS log. ... View more

The first thing to check are firewall rules for the port(s) the ODBC driver is using. Does your SAS server run on Linux or Windows? It's a lot easier to test this on Windows as you can do this all in the Windows ODBC Administrator tool. ... View more

We use ODBC with SQL Server a lot and find it works well. We don't use JDBC at all. In my experience the connection strings are a lot more straightforward. Feel free to try that again if you like.  ... View more

My best guess as to what's happening here is that for some reason your schema setting isn't working and that you are ending up in a default schema with no tables. I'd suggest opening a track with Tech Support to make further progress. Is JDBC the only SAS/ACCESS product you have? Is SAS/ACCESS to ODBC or SAS/ACCESS to SQL Server an option you can try?  ... View more

What does PROC DATASETS report? proc datasets library = PATHNCPP; contents; run; quit; ... View more

Dataset file size is governed by the number of data pages and their size like so: In the above there is one data set page and one data page for a total of two, hence the file size of 128K. Please post the same from your PROC CONTENTS. ... View more

You will find answers to most of your questions in the SAS docs: https://go.documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/hostwin/p16esisc4nrd5sn1ps5l6u8f79k6.htm ... View more

Does the chosen database and schema genuinely have tables in it? If so how long are the tables names? If they are all > 32 characters then SAS can't handle this and will not return any names. Try creating a table <= 32 characters long and see if that works. Open the LIBREF pathncpp in SAS EG or SAS Studio to see if any tables are listed. ... View more

@bitcruncher - Wow catalogs on zOS! Pretty amazing you can still read these after all that time! ... View more

I've never used APM but it is interesting to note that you are getting > 86% compression on the ARTIFACTUSAGEDETAILS dataset. That suggests it contains a lot of empty space. To reduce it in size one obvious thought would be to reduce the history kept. You will need to analyse the dataset in more detail to understand why it has grown so much. Comparing it to an earlier and smaller version would be useful.   ... View more

In my experience cloud latency will depend a lot on the type of network connection you have between on-prem and cloud. Ideally a dedicated cloud private link should provide good performance. We are using such a connection between SAS and Snowflake and performance is very good.   With on-prem to on-prem dedicated fibre connections should be available and latency should not be an issue.       ... View more

I suggest you check your server disks IO performance with the SAS IO Test Utility before doing anything. ... View more