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!

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.