Why Your Formats Disappear in SAS Viya (And How to Fix It)

It’s a scenario we see often: Your team has just completed a migration to SAS Viya. You’ve successfully lifted and shifted your trusted ETL jobs. You run your code in SAS Studio, check the log, and everything looks perfect. The data is clean, and your custom formats—those crucial definitions that turn cryptic codes like 1 and 2 into “Male” and “Female”—are applying correctly.

Then, you open SAS Visual Analytics to build a dashboard for your executive team. You drag that same column onto a report, expecting to see “Male” and “Female.”

Instead, you see 1 and 2.

Your formats are gone. They exist in your code, but they are invisible to your reports.

Welcome to the “split-brain” reality of the SAS Viya architecture. In this three-part series, we’re going to deconstruct why this happens, how to fix it, and how to build a format strategy that is robust enough for the modern enterprise.

The Tale of Two Engines

To understand why your formats are playing hide-and-seek, you have to look under the hood of SAS Viya. It isn’t just an upgrade of SAS 9; it is a federation of two distinct computing philosophies living under one roof.

1. The Compute Server (The Legacy Anchor)

Think of the SAS Compute Server as the direct descendant of the SAS 9 Workspace Server you know and love. It handles the “traditional” heavy lifting—complex Data Steps, standard SQL, and legacy procedures.

• Architecture: It typically runs as a single process (SMP).
• Format Storage: It relies on SAS Catalogs (.sas7bcat files). These are physical files sitting on a disk. When you run PROC FORMAT, this is where your formats usually go.

2. Cloud Analytic Services (The Modern Speedster)

CAS is the high-performance engine that powers modern applications like Visual Analytics and VDMML. It is designed for massive speed and scale.

• Architecture: It operates entirely in-memory, often distributed across multiple nodes (MPP).
• Format Storage: CAS cannot read standard SAS catalogs. The random-access file operations required to read a .sas7bcat file are too slow and incompatible with CAS’s distributed design. Instead, it requires CAS Format Libraries—structures loaded directly into RAM.

The Invisible Wall

The crux of the problem is that these two engines do not automatically share a brain.

A format created and stored in a SAS Catalog on the Compute Server is physically invisible to the CAS server. Conversely, a format loaded into CAS memory is inaccessible to a legacy batch job running on the Compute Server.

This creates an Architectural Dichotomy:

• Your ETL Process (running on Compute) writes data using disk-based catalogs.
• Your Reporting Layer (running on CAS) reads data using in-memory libraries.

If you don’t explicitly bridge this gap, you end up with a “split-brain” environment where your data preparation team sees one version of the truth, and your reporting team sees another (or just raw codes).

The Old Way vs. The New Way

In the SAS 9 era, we had the luxury of “Create Once, Use Everywhere.” You compiled a format into a catalogue, put it on a shared drive, pointed your FMTSEARCH path to it, and walked away.

In SAS Viya, that simplicity has been replaced by a “Create Once, Deploy Twice” necessity.

• For Compute: You still need those physical .sas7bcat files on a persistent volume.
• For CAS: You need to serialise those formats into a completely different file type (.sashdat or Item Stores), load them into memory, and promote them to Global Scope so all users can see them.

The Path Forward: Synchronisation

This might sound like a step backward in usability, but it’s the price of admission for CAS’s blazing-fast performance. The good news is that you don’t have to manage this double-handling manually.

The industry “best practice” has shifted away from manual management in SAS Environment Manager toward a Synchronised Dual-Target Deployment strategy. This means treating your formats as code—a single source of truth—and using automated pipelines to push them to both engines simultaneously.

In Part 2 of this series, we will open the toolkit and show you exactly how to do that. We’ll cover the technical steps to migrate your legacy catalogs, avoid the dreaded encoding traps (UTF-8 vs. WLatin1), and introduce the CLI tools that make modern management possible.