mvslovers Ecosystem — Architecture Overview

The Big Picture

mvsMF started as a single project: a z/OSMF-compatible REST API that lets you use Zowe Explorer (VSCode/JetBrains) and Zowe CLI with MVS 3.8j. But mvsMF is just one piece of the puzzle — it needs a web server to run on, a filesystem to serve files from, and it's growing a web frontend of its own. That's why we now have multiple projects that work together as two parallel stacks: one for HTTP (mvsMF + HTTPD) and one for FTP (FTPD) — both sharing the same filesystem (UFSD) underneath. Click each box below to learn more.

Architecture

🌐 Browser

📂 FTP Client

⌨️ curl

💻 Zowe CLI / Explorer

HTTP · REST · FTP

REST API

mvsMF

z/OSMF-compatible REST API for datasets, jobs, USS files, and console services. Runs as a CGI module inside HTTPD.

⟩ mvslovers/mvsmf

Web Frontend · In Development

mvsMF Desktop

A browser-based management desktop in the style of the OS/2 Workplace Shell — windows, taskbar, start menu — built entirely on the mvsMF REST APIs.

CGI

Web Server

HTTPD

Lightweight HTTP/1.1 server for MVS 3.8j. Hosts mvsMF as CGI, serves the Web UI and static files from UFS.

⟩ mvslovers/httpd

FTP Server

FTPD

Standalone z/OS-compatible FTP server. Dataset access, JES spool, and UFS file transfers. Functionally complete — looking for testers.

⟩ mvslovers/ftpd

mvsMF — What it does

mvsMF implements the IBM z/OSMF REST API on MVS 3.8j. This means you can use modern tools like Zowe Explorer in VSCode to browse datasets, edit members, submit JCL, and view job output — all on a 1979 mainframe.

It handles four API families: /zosmf/restfiles/ds/* (datasets), /zosmf/restjobs/* (jobs), /zosmf/restfiles/fs/* (USS files via UFSD), and /zosmf/restconsoles/* (console services — issue operator commands and read the hardcopy log).

Clients authenticate with HTTP Basic, or log in once at /zosmf/services/authenticate to get a token (the z/OSMF LtpaToken2) and replay that instead of sending credentials on every call.

mvsMF is a CGI module — it doesn't listen on a port itself. Instead, it plugs into HTTPD, which handles all HTTP protocol work (TCP, Keep-Alive, TLS) and routes /zosmf/* requests to mvsMF.

mvsMF Desktop — In Development

The Desktop is a browser-based frontend that gives you a visual interface for working with your MVS system — no IDE or CLI required. Just open a browser and go. It's modelled on the OS/2 Workplace Shell: overlapping windows, a taskbar, a start menu, and desktop icons — pure vanilla HTML/JS/CSS, no framework, no build step.

A feature-complete Phase 1 proof-of-concept already runs on a live HTTPD/UFS, and work is under way to port it into the production module structure. Programs land one at a time — a Dataset browser (with PDS member editing), a JES2 spool browser, a console, and more — each one just another client of the REST APIs.

The key design principle: the Desktop is a pure frontend that consumes the mvsMF REST APIs. This means it benefits from all the work going into mvsMF (codepage handling, error handling, authentication) without duplicating any logic. HTTPD serves the Desktop's HTML/CSS/JS as static files from UFS.

↗ Try the Phase 1 proof-of-concept

HTTPD — What it does

HTTPD is the web server that makes everything accessible over HTTP. Originally Mike Rayborn's HTTPD 3.3.x, we're evolving it to 4.0.0 with a major cleanup: removing legacy Lua config, embedded FTP, and MQTT telemetry.

Key responsibilities: TCP listener with worker thread pool, HTTP/1.1 protocol handling, multi-codepage EBCDIC↔ASCII translation (CP037 for MVS data, IBM-1047 for USS files), CGI routing to mvsMF, and serving the Web UI's static files from UFS.

Why a separate repo? HTTPD is a general-purpose server — it can host any CGI module, not just mvsMF. Keeping it separate means other projects can reuse it too.

FTPD — What it does

A standalone FTP server for MVS 3.8j, compatible with z/OS FTP conventions. Unlike mvsMF (which runs inside HTTPD), FTPD is its own Started Task (STC) with its own TCP listener — completely independent from the HTTP stack.

Supports MVS dataset access (sequential + PDS), JES job submission and spool retrieval via SITE FILETYPE=JES, and Unix file access via the UFSD client library.

Status: Functionally complete — the core feature set is implemented and the server compiles and links. We're now in the testing and stabilization phase. If you have an MVS 3.8j system and an FTP client, we'd love your help shaking out bugs.

SSI / cross-address-space

Filesystem Server

UFSD

Cross-address-space Unix filesystem daemon. Provides POSIX-like file I/O (open, read, write, mkdir, stat) on MVS via a subsystem interface (SSI). Used by both the HTTP stack (HTTPD + mvsMF) and FTPD.

⟩ mvslovers/ufsd

UFSD — What it does

MVS 3.8j has no Unix filesystem. UFSD adds one — a UFS370 filesystem server that runs as a Started Task and provides file I/O to any address space on the system via the MVS Subsystem Interface (SSI).

This is what makes /zosmf/restfiles/fs/* possible in mvsMF and what lets HTTPD serve static HTML/CSS/JS files. FTPD also uses the UFSD client library for Unix file transfers. Without UFSD, there's no place to store web content or USS files on MVS 3.8j.

Companion tool: ufsd-utils (Go) — creates, manipulates, and uploads UFS disk images from your workstation.

C runtime

Runtime Library

libc370

The reentrant C runtime every project above links against — the standard C library plus the MVS extras that make the rest possible: TCP/IP sockets (DYN75), RACF authentication, JES2 interfaces, VSAM, and SMF. Originally Michael Dean Rayborn's crent370; now the cc370 target libc, maintained by the mvslovers community.

⟩ mvslovers/libc370

build toolchain

Host Cross-Toolchain

cc370

The host-native cross-toolchain — cc370 / as370 / ld370 / ar370, a GCC 3.4.6 fork — that compiles, links and packages every project above entirely on macOS or Linux. The only thing that ever reaches the mainframe is the finished load module. Successor to the old c2asm370 translator.

⟩ mvslovers/cc370

FAQ

Why so many repos?

Each project has a distinct responsibility and can be used independently. HTTPD can serve web pages without mvsMF. UFSD can provide files to any program, not just HTTPD. FTPD is a completely standalone server with its own TCP listener. The Web UI is a pure frontend that only talks to REST APIs. Separating them keeps each codebase focused and testable.

Do I need all of them?

Depends on your use case. For Zowe/VSCode: you need HTTPD + mvsMF + UFSD. For FTP access: just FTPD. For a simple web server: just HTTPD + UFSD. All of them link the libc370 C runtime.

What's the current focus?

HTTPD 4.0.0 (major cleanup), UFSD beta readiness (AP-4a milestone), FTPD testing and stabilization, and the mvsMF Desktop web frontend (a working Phase 1 proof-of-concept). The mvsMF REST API keeps growing too — console services and token-based login landed recently — but most active work is in the infrastructure it depends on and the frontend it powers.

How do I get these programs?

Right now, all projects are built from source. The whole build runs on your host (macOS or Linux) with the cc370 cross-toolchain and mbt (MVS Build Tools); they link the libc370 C runtime, and only the final deploy step uploads the finished load module to MVS. It's a hands-on process, but well-documented in each repo's README. Looking ahead, the goal is to ship everything pre-built as part of the MVS Turnkey distributions (TK5 and friends) and as packages for the MVP package manager — so eventually it'll be a one-liner to install.

Can I contribute?

Yes — and you don't need to be a C programmer. What we need most right now: Testers who can run the software on their MVS systems and report what breaks. Writers who can help with documentation, guides, and tutorials — English isn't the maintainer's first language, so native speakers who can make the docs clearer and more approachable are incredibly valuable. And of course, C, HLASM, Go, and JCL developers are always welcome. All repos are public on GitHub — check the Issues tab or ask in Discord.