If you’ve ever dug into some vintage System/36 code, the kind that still carries the vibe of green‑screen terminals and dot‑matrix printers, you’ve likely run into the classic Workstation ID. Back in the S/36 days, this little tag was the lifeblood of interactive programs: directing jobs, managing menus, tracking users, and keeping everything from spiraling into delightful 1980s chaos.
Jump ahead to today’s IBM i world, and things have definitely evolved.
Modern i no longer revolves around “workstations.” We’ve swapped twinax terminals for virtual devices, network sessions, and APIs that actually make sense. Still, the question remains: how do you figure out who’s running your program and from where?
Short answer
There isn’t a single direct 1:1 equivalent in modern IBM i but the closest matches depend on how you were using it:
- Workstation ID (S/36) → usually maps to:
- Workstation name (device description) on IBM i
- OR job attributes (like job user, job number)
- OR environment/session info (like terminal or IP)
Let’s break it down in practical IBM i terms.
What the S/36 Workstation ID actually was
On S/36, the workstation ID was:
- A unique identifier for the terminal
- Often used for:
- Security or logic routing
- Identifying the user’s session
- Controlling program behaviour (menus, printers, etc.)
Basically: “Who/where is this user sitting?”
Modern IBM i equivalents
1. Workstation device name (closest match)
If you're coming from display files or interactive jobs:
Or in RPG:
device = %subst(%devname():1:10); // in some contexts
More reliably via API/QUSRJOBI.
You’ll typically get values like:
This is the nearest conceptual equivalent to S/36 workstation ID.
2. Job identification (more robust modern approach)
Modern IBM i prefers identifying sessions by job, not just device.
Retrieve with:
You then have a unique triple:
This is far more reliable than workstation ID ever was.
3. User profile (often what you really want)
A lot of old S/36 logic used workstation ID when it really meant:
“which user is this?”
Modern replacement:
Or SQL:
4. IP address / client info (for networked sessions)
If you're modernising to TCP/IP (Telnet, ACS, web apps):
Use APIs or SQL services:
This replaces workstation identity in networked environments.
Key modernisation insight (this is the important bit)
On S/36:
Workstation ID = identity + location + session
On IBM i:
These are split cleanly into separate concepts:
- Device → where
- User → who
- Job → session
- IP → network location
Practical mapping table
S/36 concept | Modern IBM i equivalent | When to use |
|---|---|---|
Workstation ID | Device name | Display file / interactive job |
Workstation ID | Job name/User/Number | Unique session tracking |
Workstation ID | User profile | Security / personalization |
Workstation ID | IP address | Network-aware apps |
When modernising:
Do NOT hard-code device names anymore
Use user profile for behaviour- Use job info for uniqueness
- Use SQL services for modern access
Typical anti-pattern you’ll find:
Replace with something like:
// user-based logic
ENDIF;
Or better yet:
- Move it to a config table
If you're converting S/36 code, when you see IF WSID = 'ABC' then ask yourself (a) Is this about the user? (b) The terminal location? (c) A printer routing rule?
Then map it correctly instead of blindly replacing it.
Bottom line
The closest equivalent to S/36 workstation ID is:
The IBM i workstation device name (DEV)
…but in modern design:
You should almost never rely on it directly