SAS Viya 4 on OpenShift - old dogs and new tricks


If my experience is anything to go by, there’s a sizeable number of customers that still have SAS workloads running on IBM mainframes. Now I have tremendous respect for S/390 (I can still navigate TSO/ISPF et al. and started my IT career programming in PL/AS on MVS and VM), but it seems to me that a significant proportion of customers are keen to modernize these SAS workloads. At a minimum this means moving them off the mainframe and it’s interesting to consider what options exist. Let me return to this topic in a moment (I promise).

This is a significant week for SAS as Viya 4 becomes generally available for OpenShift (at least on VMWare initially) delivered by 2021.1.6. Until now SAS Viya had only been available for the major public cloud platforms (AWS, Azure & Google). This will be particularly relevant for organizations that need to deploy Viya on-premise. Congratulations to the SAS R&D teams that delivered this!

SAS Viya 4 on OpenShift - old dogs and new tricks

SAS Viya 4 on OpenShift - old dogs and new tricks

It's good news for me because I’m working with a client who is looking to modernize an existing SAS workload that today is running on a mainframe. They’ve considered moving this workload to both SAS 9.4 on Windows/Linux and SAS Viya but have chosen Viya. Their decision reflects the fact that SAS Viya is cloud-ready, implements CI/CD and they want the GIT integration that SAS Studio offers for their own application development efforts.

The current mainframe workload is 1000+ user-written SAS scripts in a complex batch suite which runs overnight to populate an Enterprise Data Warehouse. The jobs are managed using Tivoli Workload Scheduler (TWS). Modernization involves moving the scripts to run in SAS Viya.

We’ve been waiting for the GA of OpenShift support to test this out – so let me stress our proposed approach has yet to be validated but assumes the following:

  • Existing mainframe SAS scripts will run unchanged using the SAS Viya Compute engine. This assumes they don’t access mainframe components such as DB2 & VSAM or other mainframe dependencies.
  • Mainframe Generation Data Group (GDG) processing is used today to manage multiple versions of intermediate flat work files which are created, consumed and shared between individual jobs. We’ll need to come up with an alternative method for this.
  • Much of the suite complexity is implemented using TWS. Fortunately, TWS also supports scheduling work off mainframe and has a Linux agent. Our plan is to use this to interact with the Viya CLI sas-viya. Hopefully this means the TWS schedule won’t need much modification beyond adaptation to support the Viya environment.
  • The existing multi-terabyte EDW (SAS files) will need to be migrated from mainframe storage

The plan is to stand-up Viya in the customer’s OpenShift cluster and embark on a POC to validate these assumptions. Once we’ve proved the basics with a handful of jobs/scripts, the next step is to look at performance/sizing to determine the size/nature of a larger environment to accommodate the full nightly batch run.

Before Christmas, we’ll have a better understanding of what is viable and where the challenges lie. If anyone is interested in hearing how we get on, I could provide a progress update in the New Year.


About Author

Paul Gittins

Business Solutions Manager

A seasoned architect with hybrid business and technical skills, Paul encourages clients to adopt new SAS technologies embracing Hadoop, in-memory processing, high-end RDBMS and Cloud. His goal is to persuade client enterprise architects, technologists and data scientists to extend their use of SAS as an enterprise technology, leveraging partners including Teradata, Cloudera, AWS, Google & Microsoft. He has conducted architecture & best practice reviews and consulting engagements in more than 40 countries and has led multi-disciplinary teams to success in large and complex environments.


  1. Vasilij Nevlev on

    Thank you very much for a very interesting blog post. I would love to learn more, please post the updates your progress.


  2. David Suchomel on

    Paul, I know this is an older thread and probably not being actively monitored anymore. I am actually working on a project to migrate from SAS 9.4 to Viya and based on this blog you may be the individual to best speak with about it. The last time I checked the installation documentation, Viya didn't support the newer Kubernetes API or anything higher than 1.21. I believe OCP 4.10 uses 1.22 now too. It would be nice to know which version of OCP will be supported before building out our on premises cluster and preparing for the Viya 4.5 installation later this year.

    Do you happen to know the answer to this question, or possible point me in the correction direction?

    • Paul Gittins
      Paul Gittins on

      David, current system requirements doc here suggest OCP 4.7 and K8S 1.22 is already supported. Support statements evolve every month and I really suggest you discuss this topic with your SAS account team to understand the roadmap. That way you can make more informed planning decisions. I hope this helps.

Leave A Reply

Back to Top